Amazon.com Widgets Dev Diary 7: Short Term Vs. Long Term
Yac on September 22nd, 2008

A point I have emphasized a few times already over the few short weeks is rapid prototyping. I find it’s very important to be able to make quick and visual progress on the game in order to keep myself motivated, and to provide quick turnarounds to a designer when a new feature is requested or a new idea is hatched. This emphasis on what is important now has allowed me to progress certain parts of this project rapidly. As I mentioned last week, I hadn’t implemented a matrix math library up to that point because I hadn’t needed it up to that point. It wasn’t worth me spending a day on a technology I didn’t need when I could progress a different area of the project that would have a larger immediate impact. One day’s work doesn’t sound like much, but these things add up.

Unfortunately, one can’t implement an entire game this way. There are certain areas that require thought and careful planning. When you are building a physics system whose key characteristics are that it needs to be fast and handle many, many objects, you can’t just throw something together as you go along. You will need to take some time and implement things correctly. You have to think long-term about how the components will fit in, and how each decision will impact the performance of your system.

One of the big challenges so far on this project has been balancing the short-term and long-term needs. I wanted to be able to move quickly and try out new ideas, but investing in the technology and architecture gives my project long term flexibility and efficiency. It is better to invest a week to setup an effective debugging framework, then to spend three weeks trying to resolve bugs that could have been fixed in a few days with the proper tools.

Focusing on this balance is important for me. Every week when I take a look at my backlog of tasks and plan my workload, I strive to maintain this balance.  It allows me to move my project forward while improving my codebase. I can produce prototypes and try new ideas every week, from which I draw a sense of accomplishment which keeps me motivated.

Balancing long term and short term needs goes beyond just coding or development, and this will be a subject I will be returning to often throughout these diaries. It affects almost every area of game development, not just coding. Does a company invest in its employees, in their welfare, in their professional development, in their happiness and job satisfaction, or does it make them crunch to get the latest title out, working long hours and making them miserable. The short term gains are clear, you get the game out on time. The long term gains aren’t always so obvious, but a company can gain a lot by taking the long view, by setting themselves up as an attractive employer.

Another way of looking at it: is it better to sacrifice the quality of a game to get it out on time and meet your sales target for the quarter or year, possibly affecting the long term value of the IP, or is best to delay a release and invest more up front to improve the game, and the long term benefits to be drawn from it.

In my opinion, the balanced approach is best. You should never completely sacrifice one for the other, but aim to maximize to the benefits of both.

Work Done Last Week

I implemented a matrix class and a transform structure to allow me to easily rotate. I had to dive deeply into 3D math once more, a subject I simply loathe. Every time I encounter it I have to refresh my memory. Each time it sticks a little better than the last time, thanks to the awesome book, and my good friend Dave (a 3D math wizard).

I’ve also spent time experimenting with different game play ideas, which yielded some cool results, spurning both more ideas to consider, and more physics issues to worry about.

Work Planned This Week

Is it boring to repeat again this week that I will be doing more experimenting with game play ideas and improving the physics simulation, without going into details? Yes, it probably must be. I’m sorry. I really wish I could share more details or talk about something cooler. I’m gonna rack my brain to come up with some sort of interesting discussion for next week’s post.

Related posts:

  1. Dev Diary 2: Unit Testing
  2. Dev Diary 12: Design Vs Technology
  3. Dev Diary 39: The Hunt for an Artist
  4. Dev Diary 1: Introduction to Project Brody

One Response to “Dev Diary 7: Short Term Vs. Long Term”

Trackbacks/Pingbacks

  1. Dev Diary 8: The One about Motivation

Leave a Reply

You will be able to edit your comment after submitting.