Whether it's emulating the benefits of Commodore 64 machine language with Garry Kitchen's Gamemaker, devising a text adventure on the Amiga with HiSoft BASIC 2, trying to concoct speedy character-graphic games in good ol' C64 BASIC or trying to figure out how to make Atari 800 LOGO successfully carry a value from the joystick to an onscreen character, I've always been mesmerized by the half-science/half-art of coding. Adam likes to torture himself by digging a little deeper into his machines: re-tailoring Atari 2600 games or studying 8-bit machine language.
Devising new universes by communicating with our machines has been a fascination of Adam's and mine since we were kids. After years of alternating frustration and success, what can I come up with for the would-be inventor who isn't satisfied with just using, but is leaning rather toward creating?
This is directed toward experienced programmers as well -- it's good to take a step back once in a while and ponder what can be done to make things easier. (Trust me on this. I could use plenty of steps back myself.)
These are not necessarily in order.
Begin a project as freely as possible. Don't structure things right away. Improvise! I'm all for flow-charts and easy-to-follow structure, but sheesh, talk about giving yourself a tedious task right at the beginning of something that should represent a fun creative outlet! Think of that excited feeling you get when you're ready to sit down and start typing-up the recipe for your latest brainstorm. There's nothing that can kill that enthusiasm like turning it into a job from the outset. Start numbering lines or naming procedures, make them do what you want them to -- no matter where in the final execution they're actually going to be called -- and pour your brain onto the screen! You can always go back and re-structure everything, which you're going to wind up doing anyway.
Use comments freely. Whether it's using the REM statement, an apostrophe, a semicolon or some other symbol denoting that the computer should ignore what follows on the current line, you'll love yourself later for making it clear what every section (or line, for that matter) of your code is supposed to do. If you've ever stopped working on a program for a couple weeks and then tried to go back to it, you know what I'm talking about. If you're worried about execution speed (this mainly goes for you fellow 8-bit programmers), remember that you can always take comments out before saving the final product. This tip goes hand-in-hand with the next one:
Study your code. Whether you're returning to a program you postponed a few days (or weeks) ago or you just want a breather to find out where you are, looking at a printout or scrolling screen to take-in the big picture can do worlds of good. There's nothing that can deflate enthusiasm like the need, every time you want to add or change something, to go back and re-learn where in your code you've put everything and what the ramifications of your changes might be. Keep up on your general structure -- another advantage is that debugging gets so much easier.
Don't think paper's obsolete. I find that it's more fun to start coding if I know what I'm coding. I write out everything that I'll need to know, so that I don't turn it into a chore by having to rely on memorization. Do yourself a favor and list every variable in your program and what it does. Pre-designating them in this way -- even open (changing, temporary) variables and flags that you might need -- gets one whole task out of the way, leaving you free to improvise code without hangups, since you can just refer to your notes whenever you need to remember stuff. Sometimes, in addition to commenting in the code itself, I'll write down the line numbers or procedure names and add a brief description that explains what each section's function is. Sprites, sound file names, etc. should all be disclosed. It just eliminates so much drudgerous memory-work later.
Don't be afraid of failure. Failure is part of life. That's all there is to it. Without the possibility of not succeeding at something, how could the actual accomplishments be special? Don't talk yourself out of trying something in your program just because it might not work, or because it could crash everything. That's what backup files are for.
I hope this stuff helps. And I implore you, if you write anything on an orphaned computer (this includes the Amiga), by all means, SEND IT TO US! -- CF