8 HABITS OF HIGHLY EFFECTIVE GAME PROGRAMMERS
by Erik "Wazoo" Yuzwa

Professionally, 2003 year was a milestone year for me for one reason: I finished my first game. After years of calling myself a "game developer" I could finally say that yes, indeed, I have made a game.

Big whoop, right? If you are among those who have yet to get a title under your belt, it is a big whoop. And it is for those of you are very close to finishing that first game that I offer my humble insights to perhaps help move you into the "yes, indeed, I have made a game" category.

The first game is an elusive entity to most, diving and twisting out of range like that annoying (last) TIE fighter eluding your bursts of laser and screwing up your shot percentage in the process. But once completed, it feels even more satisfying than completing that game that's been on your hard drive for ages, or that one level which just refuses to let you pass.

With a kindly nod to Stephen Covey’s Seven Habits Of Highly Effective People, which is a decent read by the way, I present the 8 Habits of Highly Effective Game Programmers. While the following are in no particular order, I believe they do all contribute to the final product, as well as improve the chances of you actually finishing your first (or any) project.

1. Every journey begins with the first step. If you're just starting out and have yet to finish anything, then refuse the urge to make the next killer MMORPG, or FPS, or similar. Rather, start with a well-known clone project, such as Tetris or Asteroids just to get your feet wet with game programming. Even the most seasoned of veterans had to start somewhere, and while they may now look upon their earlier projects with a degree of chagrin as to the programming/design decisions they made, at least decisions were made. Most successful companies and individuals begin small. The key is to begin.

2. Realistic time management. Whether you're a seasoned game veteran or a beginning programmer, we're all constrained by the same unchangeable constant: time. Regardless of whether you have access to a TARDIS or other trans-dimensional vehicle, you must create a schedule timeline for your project. My recommendation is to carry a notebook with you during a typical week or month, jotting down a note or two on what you're actually doing and when. This way you'll be able to sit down and see an average day in your life, and what takes up most of your time. From there, you can then plan a realistic window within which to work on your game. However, once you decide on the target work window, for example, every morning for 2 hours starting at 5am, then stick to the schedule. Take the phone off the hook, set up the VCR, and get someone to tape your brother’s wedding. If you make this work window a regular habit, then you can keep your game work concentrated and focused.

3. Lurk but avoid camping. Everyone needs help programming their game, and obviously nobody is perfect. So, when you hit a wall in your project, don't waste too much time banging your head against it. Rather, use the internet in all its game programming newsgroups glory to try and find a solution to your problem. While you’re on search and lurk patrol, however, make sure you keep focused and concentrated on your specific problem. Don't waste your valuable time contributing to a senseless newsgroup topic -- which is better, OpenGL or Direct3D? You want to keep your work within your targeted time window as focused as possible. If you do end up posting some topics to get help, be sure to be very courteous and polite to those who respond, even if they decide to post flame bait. Not every topic/thread needs to be debated ad-nauseum.

4. If you fail to plan, you plan to fail. Consider this common sports mantra, which can likewise be applied to game programming (or programming in general). Although you might get extremely excited about a new project, take a step back and analyze your idea in detail before you begin to do any programming. There are loads of resources available on the internet for creating a good game design document. Find them. If you find that you have trouble even finishing a design document, then perhaps your idea wasn't quite as good as you thought. This practice can save you countless hours of development time, as once you begin the actual programming of your game, you can quickly speed through any roadblocks that might have stopped you without a design document. By creating an overview document of your game, you'll be able to quickly see which modules you need to create and when. With a finished design document, you will also be better able to gauge your time effectively. Another bonus of a design document is the ability to curb the urge of scope creep. Rather than adding in some new weapons or enemies at the last minute (which ends up destroying any notion of balanced gameplay), stick to the plan.

5. Source control is force control. You've got your detailed design document done, you're halfway through implementing your game, and suddenly a power grid in Ohio fails and the whole of North America is in blackout. By the time you get back to your project, you realize you've lost several modules of code which took you several weeks to create and test. Rather than taking your anger out on Ohio, download and get familiar with a source control system such as CVS. There are more than enough tutorials and beginner books on the subject, so don't be afraid to spend a day or so just getting familiar with checking in/out files and creating branch versions of your project.

6. Follow Stroustrup, then betray him. As you gain more experience developing your own game, you'll begin to see that most of your code is the same throughout every project. Rather than mundanely creating this same code every time, design some objects using C++ which you can easily port from project to project. Keeping your game as modular as possible also creates an environment which promotes module testing. When you create a new object or module, test it thoroughly to weed out any surprises. It's much easier to test out a single module rather than wait to integrate it with your game system. But, bear in mind, all the object-oriented design in the world won't help you if your game just won't work (or only works very slowly). Follow the object-oriented methodology as much as possible, but don't be afraid to bend the rule book during your project development if needed. Some developers get caught up in designing the "perfect hierarchy", but more often than not, those same developers have no finished products using them.

7. Stay the course. Inevitably, there will come a time during the project where you will be sick and tired of what you're working on. You will be sick to death of testing the same AI procedures, or following graphics pipeline code from its introduction into the pipeline all the way out through to your rasterizer to try and figure out why your lighting code works on NVIDIA architecture but not ATI's. It's at these dark times when you will think of starting something new to relieve the boredom, or, in complete frustration, giving up the project altogether. I would urge you to not listen to this inner voice of dissent and doom, but, instead, to rise to the challenge. If you seek your fame and fortune within the world of programming, then nothing shows up better on a resume than completed projects. Stick to your work window timeslot and just keep on plugging away at your project until completion.

8. Establish a dictatorship, then silence your opponents. If your first project is a group effort, then decide who will become the project leader and quell any dissenters. Working in a group can be both a rewarding and disastrous experience. Although that's probably the subject for another article entirely, I will add that smaller teams tend to work best with a dictatorship. If everyone has an equal say, and all decide that they have the better direction for the project, then leave the team as, in the end, you risk accomplishing nothing.

Hopefully these "habits" will help you find that quiet time to sit down and blast through the final walls that are between your current source code and your first game! If you have any feedback or comments, feel free to send them to me at "wazoo AT wazooenterprises DOT com".