Game Maker to Game Dev

You should always, always do things you are passionate about. That's the only thing which will keep you going when it gets frustrating.

 

When programming the 2600 you must keep it's limitations in mind:

1. 128 bytes of RAM. Yes, there are more & more carts which can get beyond this boundary; but it's tough to use that extra RAM for "working" storage. Don't forget that 128 bytes has to include space for stack usage.

2. Very limited graphics capabilities: each line has a 20 bit playfield, two 8 bit sprites, and three 1 bit objects. Yes it is possible to go reuse those elements on a single line, but there are still limits in what can be done. Which leads to...

3. 76 CPU cycles per line. Each graphics trick, from changing sprite colors to repositioning sprites & HMOVE tricks to asymmetric playfields to 48 bit sprites, requires CPU cycles and often precise timing. Combining tricks increases complexity and often leads to code bloat with multiple kernel routines to handle each case and combination. Which leads to...

4. 4K address space. Yes, bankswitching can get you beyond this, but you only have 4K to use at any time. And though it's often possible to make the space/speed tradeoff, there are limits to how much space you can throw at the problem.

5. Color and sound. You have a choice of 128 muted colors and two channels of LFSR sound with limited frequency selection. Yes, it is possible to generate PCM audio, but it requires a lot of ROM space and CPU time during the display.

 

Other general advice:

1. Dream big but start small. Get something working first the build on it. Small incremental changes will keep you going.

2. Don't try to create the final version first. Don't try to create the "ultimate" display kernel at the beginning - do something as simple as possible.

3. Build around the display kernel. The kernel is the most time and timing constrained code. The rest of your game should be written with the kernel in mind.

4. Be prepared to start over. You will almost certainly rewrite the kernel more than once in order to incorporate new features which will probably mean rewriting large chunks of other code.

5. Make backups, lots of backups. Not only because you may need to undo something you just broke, but you may need to go back to an idea you discarded.

6. Make notes & comments - lots! Document all design decisions and any tricks, even stuff you didn't end up using. You'll inevitably end up asking yourself "why did I do that?", so leave yourself the answer.

7. Cycle counting isn't just for the kernel. Know how long your other routines take.

8. Start with a plan - figure out the basic gameplay and where the 2600's limits are going to impact you most.

9. Playtest, not just yourself, and then listen to the feedback. Also test on a real system, not just an emulator.

10. Steal ideas then make them your own. See what others have done and also learn from their mistakes.