i do #16 for almost every program i write that takes longer than 48 hours, or programs that have very few "global" variables. in my mind i call them important and unimportant. the tags global and local are more professional though. you also may want to add onto that to have a separate section of variables for subroutines. you don't want to have a subroutine storing values to X and Y and then have it call a subroutine which also stores values to X and Y, unless it's part of the code.

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

i have a small suggestion. could you bold/highlight the calculator models or programming languages for readability?

for a frame,  yes. quigibo already gave a better fix with the pause command.

it's an 8x8 sprite editor. you can save and load up to 3 monochrome sprites, it seems.

i think the rotations will be by 90°. though i would like to see 45° if possible.

you have an X and Y variable that keeps track of the ship the player is placing, right? is there any way to just draw the part of the map the player is at, and the part of the map the player is going to once they press a button?

no, problem meishe! (:

identity(A) creates a matrix A rows by A columns, with every number being 0 except for the diagonals.
so identity(5) creates:
10000
01000
00100
00010
00001

in my trick you have 0identity(, which creates an 8x8 matrix then multiplies it by 0, creating an 8x8 0-filled matrix (:

also, i'm curious: when you have a player move their pieces around, are you drawing the whole map every time they move?