Development Cycles Growing

Making THE OCTOBER GAME: Rehersal

If there’s some programming structure or technique that I’m unsure about, I’ll write a quick app to test it. As the development process goes on, this becomes harder since I need to test more complex things. This means direct work on the app slows down as tests get more involved. As far as I know, there’s no way around this, except to get more development experience.

For instance, I spent the whole day building a full set of menus to validate the current app structure. In the process I discovered a few things:

  • a menu screen that didn’t make sense
  • several forgotten screens
  • a new way to reduce repeated code

Which is great. But I also wanted to test loading and saving game data. Doh! Now I’m faced with the choice of where to direct my efforts. On the one hand, doing these test apps can save me from making a design or coding decision that’s hard to rewind from. On the other hand, I could spend the whole rest of the month doing these instead of moving forward on THE OCTOBER GAME. That’s partly why I picked a project with such a tight deadline. It helps me resist the urge to work out every detail in advance. That urge is based on uncertainty and giving in to it will kill the momentum of a project.

I’ll strike a balance between reasonable prudence and analysis paralysis by only working on these sidetracks for a day or so. Then it’s back to direct work like art asset creation or composing game music.

This entry was posted in process, traps and tagged , , . Bookmark the permalink.

Comments are closed.