don't click here

Kid Chameleon - Stage 5

Discussion in 'General Sega Discussion' started by saxman, Mar 29, 2010.

  1. saxman


    Oldbie Tech Member
    I've been pondering the possibility of doing a fifth stage for Kid Chameleon to add an extra 25 levels to the game since there are enough empty map slots in the ROM to support it. I have done a little test run over the past couple of days with my KC level editor, and here's a map I came up with:

    To run the new map, use the PAR codes 100000:006A and 10016E:45FF. Do a soft reset after enabling these codes and when you go to begin the game, it should take you to the brand new map I created.

    It's mostly complete, aside from a few minor details (like detailing the rocks.) I am curious what you think of the difficulty, how you like the design, and so on. This is just one map I'm considering for a stage 5 add-on to the game. The maps are intended to be, for the most part, more challenging than any of the maps currently in the game, or as challenging as stage 4 at the very least.

    If anyone likes this idea, I think I'd like to get a team of level designers to create maps for a stage 5 project. It all depends on how many people are interested in doing this.

    BTW: The editor is available at
  2. qiuu


    Tech Member
    Blue Ball & Blocks
    I gave your level a try; I like that it supports multiple paths, neither of which is easy though. I was lucky enough to barely manage it on my first try still, but had a few more playthrough trying to explore the level.

    I see you updated the editor; I like the block panel you added. It'd be pretty convenient if it was possible to switch between the block panel and a level tile panel of a similar fashion (the space would suffice), allowing to put level tiles the same way as blocks. Currently having to adapt the index of every single tile is a bit tedious.
    If I'd get around to making some levels, it'd very likely be only a very few from me though.

    If you can give a short documentation of the .kcm format, it'd likely be not too much work for me to incorporate this into the disassembly, so the .kcm files in the folder would just be assembled into the ROM. Might be a bit more flexible, though your approch inserting everything at the end in binary seems to work as well for mere level insertion.

    I'm currently in a hurry, so that's it for now.
  3. saxman


    Oldbie Tech Member
    Here's the format for the header:

    Code (Text):
    1. ------------------------------------------------------------------------------
    3. ------------------------------------------------------------------------------
    5.   byte id[4] = { 'K', 'M', 'A', 'P' }
    7. This identifies the file as an authentic KCM file.
    9.   byte compatability = 0x80
    10.   byte map_version
    12. If compatability is less than 0x80, then the compatability and map_version
    13. bytes don't actually exist and the file read position should be changed back
    14. to 4. Bits 0-6 are reserved in the compatability byte and should remain 0. The
    15. map_version byte is used to help keep compatability with outdated versions of
    16. the KCM file format. At this time, this byte should be 0.
    18.   byte map_size_x
    19.   byte map_size_y
    21. Map size is measured in screens (that's 20 blocks per single X screen, and 14
    22. blocks per single Y screen.) The upper 2 bits of map_size_y are used to add
    23. additional rows to the Y size. These are added in sets of 2, so you can extend
    24. the Y size by 2, 4, or 6 rows.
    26.   word map_theme
    28. The map_theme defines the theme to be used by the map. The lower nybble of
    29. each byte is used to do this. Both nybbles should match. Theme 0 is unused,
    30. but 0x1 through 0xA can be used. These themes are labeled as follows: sky,
    31. ice, hill, isle, desert, swamp, mtn, under, forest, and urban. The map_flags
    32. is used to define any special "features" in the map.
    34. The other nybbles are used as flags to put special "features" in the map. The
    35. nybble of the first byte (big-endian order) makes the map a chase scene if the
    36. nybble is 8. The other nybble can have the following effects for values from 1
    37. to 3: storm with hail, storm without hail, and lava shooting up.
    39.   word player_x
    40.   word player_y
    41.   word flag_x
    42.   word flag_y
    44. These words are used to define the X and Y positions of the player and the
    45. end-of-level flag. Maps with no flag have the flag moved outside the map area.
    47.   word ptr_tiles_front
    48.   word ptr_blocks
    49.   word ptr_tiles_back
    50.   word ptr_enemies
    51.   word ptr_platforms
    52.   word ptr_lava
    54. These are pointers to various data types in the KCM file. The value of the
    55. ptr_tiles_front will determine how many of these pointers (and subsequently,
    56. how many data types) exist in the KCM file. If ptr_tiles_front points to the
    57. location after it, then pointers from ptr_blocks through ptr_lava don't exist.
    58. Pointers are absolute (e.g. based on offset 0 in the KCM file) and should be
    59. read as little-endian. The size of each data type is based on the value of the
    60. pointer for the next data type. Wherever the data begins for a data type is
    61. where the previous data type is cut off. The last data type runs to the end of
    62. the file.
    Now the tile layout is a simple uncompressed, byte-for-byte store. The block layout however is condensed. For block layout, a byte of 0x80 of higher is a block. When a block is defined, there's four bytes that follow that contain the parameters for that block. If the byte is less than 0x80, that tells how many empty block spaces there are. Enemy layout is identical to that of the ROM, except the header in that only contains 7 bytes (3 words for defining the enemy art to be loaded, and 1 byte to define how many enemies there are.) Background layout too is stored exactly as it is in the ROM.

    Platform and lava layout information should be ignored for now since I haven't figured out how I want to store the format yet.

    The problem you may run into is that block layout must be condensed, but in the format KC uses. Trying to go around it and use data that is bloated will result in a memory overflow on some levels. You'd have to write some code to condense the block layout.