Tom used to be a lawyer. Now he's a game designer. The two have more in common than you think.
Theory: Coding Lessons Learned the Hard Way
If you can’t say with certainty how many times a loop is going to run, it’s going to cause crashes.
There’s a limit to how many statements can be nested before code becomes unreadable. A three-deep nest is OK. Five deep is a lot. Seven is begging for errors.
Comment every function with, at the least, a brief statement of what it’s meant to do and what its arguments are.
Javascript will let you get away with anything. That doesn’t mean you should feel free to do everything. Stick to good form; it might not be interesting, but it will only break in relatively predictable ways.
Learn coding best practices, and force yourself to use them. Formatting, good use of functions, even proper variable naming–all of these will save you time in the long run.
“If you’ve only backed up in one place, you haven’t backed up.”
Don’t set code aside for too long; you’ll forget how it all hangs together, and lose time working back through it from scratch. Keep it current in your mind.
On the flip side, don’t beat your head against a wall. If you haven’t solved a problem over the course of a few hours’ work you’re not going to solve it in that session. Do something else for a while.
Coding involves working on the computer, and that can be distracting–not least because you’ve probably already got a browser window open to look at Stack Exchange or documentation. Be rigorous with yourself about not doing fun stuff when you should be working.
As a game designer you can solve technical problems in two ways: the technical route and the design route. If a technical problem is proving unmanageable, put your design skills to good use. Find a way to change the game so that it’s in line with your technical skills.
