I already thoought of all that
Current implementation is 200 bytes per screen. Each screen is concatenated together. The tilemap is 24x16 nibbles (could be expanded to a full byte later), each containing the ID of a 4x4 sprite (ID 0 is nothing, ID 1 is a block, etc.). There is also special IDs such as spikes, teleporters, enemy spawner, moving blocks, save booths, etc. If current pixel belongs to a special block, it makes you die (move to latest save booth)/save game/move in a direction/teleport/etc. They have arguments before the tilemap, together with pointers to {left,right,top,bottom} screens. Compression is planned. Everything but the tilemap are 8 or 16 bit, while the tilemap is 8 bit (4 if I have 16 objects or less).
I already have pixel-by-pixel collision detection already working, it works fine. If current tested pixel belongs to an ID 1 block, the character can't move in the specified direction. There is also collision detection for the screen borders, if you reach the bottom, for instance, you get warped at the top of the screen specified by the pointer to the bottom screen in the level data.
For gravity, well you can only move left, right and change the gravity upside-down. The character can't jump. There should also be moving plateforms and blocks that speed up/slowdown you.
For map design standards, well there shouldn't have a lot of puzzles and enemies in the same screen, it should look like the PC game.
Full specification with the correct order coming later
Show Posts
