i noticed Raylin's rules for making RPG's, and thought it was a good idea to have the same for platform games. This thread is for people who don't think they can handle a full-on RPG yet, but are beyond programming small games and are looking for something more intensive. since i personally don't have many rules for platformers, the thread is titled as omnimaga's, in the hope that the community can contribute. so, in no specific order:

1) Plan out your character's limitations. Can they jump? If so, how high and how far? Do they have any special abilities e.g. lasers or shields? - nemo

2) If you have enemies, make sure you have an idea of what their AI will do. Keep it as simple as possible, without being ridiculously easy. A good example of elegant but effective AI is ztrumpet's Exodus. - nemo

3) Make sure you compress your maps! there are many different compression algorithms out there. if you are a beginner to compression techniques i suggest you start out with a simple one like Run Length Encoding, explained here and implemented in TI-Basic here. However, if you're programming in TI-Basic, your map loading will take a hit on speed. This rule is more for Axe and ASM programs. - nemo

4) Know how many tiles are in your tilemap before you write a decompression routine. figuring out decompressing can be a pain. if you know how many tiles are in your tilemap and their specific properties, once you write a decompression routine, you won't have to worry about it again. - nemo
 
5) Write a tilemap editor if possible. it'll save you a lot of time when developing levels. - nemo

6) I've always found the physics engine in a platformer to be relatively simple, and save it for last. however, if you aren't sure what type of physics you'll have, i suggest playing around with the code in builderboy's physics tutorial to get some ideas of how to implement basic physics. - nemo

7) Make sure that you make your gravity constant EXCEPT when you are touching the ground. However, the only exception to this rule is Raylin's game, gRaViTy. In that game, in order to gain speed, Raylin made the gravity constant throughout and had the player object determine whether to stop or not. - Raylin

8 ) JUMPING ENGINE FIRST! - Raylin

9) For BASIC programmers, make sure key detection is responsive enough. IN the first version of Exodus that I tested (that was never posted in public) as well as in Deep Thought's Insanity platformer games, when pressing a key, it took an entire frame before responding. This leads to frustration when trying to jump/land on small platforms, as you always end up moving one step further, not moving at all, not jumping at all and falling in the pit. Although speed cannot be helped all the time, try to make sure key detection for movement/jumping is done at the right place in your program (preferably immediately before the sprites are being moved). - DJ Omnimaga

Added this to the tutorial thread.

Wow nice. I would have to disagree that 3 is essential, though. In some case, the programmer will want his maps to display instantly or close. With compression, this is impossible in BASIC. Also, compressing 350 maps one by one is long and tedious, not to mention if some of your maps use boolean logic for certain tiles (like treasure chests), then compression is out of the question.

Imagine how slow Metroid II Evolution would have loaded with compressed maps. My goal was 2 seconds loading between maps.

As for 6 I agree with Builderboy. Without his help, I would never have managed to fix Supersonic Ball physics. I tried everything I could.

That said, if you use ASM/Axe for maps, you gain a big advantage of map data size, so compression may not be as essential as if your maps were in BASIC (especially matrices). Otherwise I challenge the person who wants to compress all 300+ Metroid II Expansion Set maps without adding more than 1 second on map loading and with preserving of the boolean logic used in some maps. This is all the maps: http://www.omnimaga.org/index.php?action=dlattach;topic=1726.0;attach=908;image

EDIT: 9) For BASIC programmers, make sure key detection is responsive enough. IN the first version of Exodus that I tested (that was never posted in public) as well as in Deep Thought's Insanity platformer games, when pressing a key, it took an entire frame before responding. This leads to frustration when trying to jump/land on small platforms, as you always end up moving one step further, not moving at all, not jumping at all and falling in the pit. Although speed cannot be helped all the time, try to make sure key detection for movement/jumping is done at the right place in your program (preferably immediately before the sprites are being moved).

Plan ahead all the tiles you will use if you use compression.  It may take a while, but adding in tiles later (I added the crumbling block in Exodus almost too late) is a pain. 

edited in the new rules.

6 is more of a preference for me, but i thought i should add it so people could find builderboy's physics tutorial if they were having troubles. true DJ, in BASIC it's harder to  compress maps and keep speed than in axe/asm. i edited that in (:

edit: i'll attempt to compress the metroid II maps, but no promises there. it'll be hard.

Oh doN't worry too much about the Metroid II challenge, it was more because in the past, many people complained that I should add compression to the game and they did not understand it would increase loading time considerably, so since then I put that challenge up. The challenge required the person to only rely on xLIB+BASIC.

wait for it.......HOLY NECROPOST BATMAN!

I need to make a Jumpman level editor very very soon!

Advice on key detection: Have the drawing code immediatly after the key detection, like in the following:

Getkey->K
Text(-1,R,C,"_
C+12(K=26)-12(K=24->C
C+96(C<6)-96(C>96->C
Text(-1,R,C,N