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.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s