#AltDevBlogADay

Finishing projects are difficult at the best of times. Finishing personal projects, those we do as a hobby and for fun, can seem impossible. How many times have your started working on an exciting new game or demo, just for your motivation to drop after a few months, and the project to fizzle out (often giving its place to another fun new idea for a game)? I can personally recall a dozen or more. I have, in this process, found certain road blocks which seem to come up time and again. Some of these you might already be familiar with, and in most cases they are common sense anyway and nothing profound. My hope is that by putting these down in written format, first and foremost I myself can become more conscious of them and become more consistent in finishing the games I start to work on.

Please keep in mind that this is written from the perspective of a programmer. Of course as programmers we often have notions of grandeur (especially in the beginning of a project) and like to take on everything, which leads me to the first challenge…

1st Challenge: The Art Deprivation

This one is probably the number one reason I have dropped projects. A lack of good art, mostly visual, but also audio. The problem is that after a while of programming, you start getting tired of looking at the same gray box representing your main character, or the old Quake 3 rocket launcher. At this point one of two things can happen: 1) You find yourself searching “free tree 3D model” on your favorite search engine, or 2) You load up a 3D modeling program, or photoshop, and start having a go yourself. The problem with the first approach is, even though in the beginning it can be a good idea to just find whatever you can as place holders so you can write your code, they often don’t work well in the long run. You might find great art for some aspects, but not others. And you usually end up with inconsistencies: for example a low poly count, cartoony house model, sitting on top of a photographed grass texture… it just doesn’t fit. The problem with the second approach doesn’t need to be expounded on…let’s just say there is a reason I stuck with programming. Don’t get me wrong though, I think every game programmer should at least try and play with game art and get a feel for how they’re created. But it’s easy to spend hours and hours working on something that ultimately doesn’t look very good and can discourage you.

The Solution:
Collaborate, collaborate, collaborate. Yes this has many of its own challenges, but ultimately irreplaceable. Not only is working with an artist a great way to get your game looking as it should, it can create an awesome motivation loop. You are motivated to code more game features, as you see great and consistent art come in, and the artist is motivated to create better / more works as they see their creation come alive in the game. Ideally you want to work with an artist that you know in person, but there are also tons of people out there on places like Genesis3D (which most of the community at the time was using for FPS games). It really only became possible because of contributions from an artist which I connected with on the Genesis3D forum.

Tomb of the Necromancer

2nd Challenge: The Grand Plan

This obstacle arises on two levels. The first level is the design of the game itself. It’s so tempting to want to make the next half life with dynamic global illumination, 12 weapons, and ragdoll physics. I’m not going to talk much about this one because it really comes down to being honest with yourself and your resources.

The second level has to do with the design and structure of the code. This one really has taken me some years to appreciate and understand, not only on my personal projects, but also professionally. See, more often than not as developers we like to have a beautifully structured system, with all components and subcomponents laid out, communication between parts of the code streamlined. We like to build pluggable systems with lots of interfaces. We like to sprinkle design patterns and well known data structures wherever we can. I used to find this one of the more fun aspects of the beginning phases of development. But then we start coding. And we start to realize that at every step of the way we are running into issues that we hadn’t thought of, or incorrect assumptions we had made. We find ourselves having to either put in hacks here and there to go around our initial design, or having to make significant changes to that design. In a way not only are we trying to solve the problem, but we are fighting against a monster (the design) which we created in the first place.

The Solution:
I guess if had to summarize “agile development” (as overloaded as that term is) in a sentence it would be: Write enough code to do the job, no more, no less. Every line of code should correspond to an actual feature. The idea is to have a design that is constantly changing and improving to accommodate new features. I have myself debated against this with people, and even though I still think there are situations where you need to step back a little and do more design up front, for the most part I have seen how practical the approach is. It’s conducive to…well…agile development, keeps your code much simpler and easier to read, and ultimately keeps your motivation high because you are writing more functional code.

Unnecessary?

3rd Challenge: The Tunnel Vision

Have you ever banged your head against a problem way longer than you should have? There is a voice inside you that’s saying: this isn’t worth it, it’s good enough, let’s move on. But there is a stronger voice that says: I can’t let this problem defeat me, I have to keep going.

This is the classic tunnel vision. Getting pre-occupied with a specific problem or feature to the point that you lose track of the big picture and the significance of that one feature in context of the whole game.

The Solution:
Give yourself a time limit. If I say I’m going to work on this fur shader for 3 evenings, I better bet sure on that third evening I’m wrapping up and cleaning things up so that I have something functional, if limited, by the end. Remember you can always come back and improve a feature, but as far as overall motivation goes, it’s better to keep the whole project moving forward.

4th Challenge: The Wheel

This is another built-in challenge for many programmers which we must constantly fight against. It’s this idea of purism, and wanting to do everything from scratch. Writing your own rendering engine, writing your own physics system…you almost feel like cheating every time you use someone else’s code (actually I have a very similar feeling whenever I use a pre-recorded loop in a piece of music). Of course every time you do choose to re-invent the wheel, you are committing a whole lot of time in development and testing which does not directly move your specific game forward.

The Solution:
Don’t get me wrong. I absolutely think every game programmer would benefit from writing some of these systems. I learnt an incredible amount from writing my first BSP tree, first CLOD terrain, first particle system, … I think the solution here is to decide what your goal is. If your goal is to learn a new technique or understand it better, you should absolutely write it. But if your goal is to make a complete game, you should be writing exactly that: your game. Not the engine, not the audio system, but your game. So you should use as many resources as possible to make that easier.

5th Challenge: The Overprotective Parent Syndrome

The game you’re working on, especially if it’s something you’ve been doing solo, is like your child. You attend to it lovingly, often at ridiculous hours of the night, you grow and nurture it, you enjoy playing with it even if it’s not really fun, and sometimes you get angry with it and you call a time-out for a while. As such, sometimes you become overprotective of the project, not wanting anyone to see it until it’s perfect and reflective of what you had originally envisaged. There is always a bug to fix, a character to add, and an art piece to replace. You end up telling people about what the game is going to be, rather than showing them what it is.

The Solution:
One of the greatest motivators is human feedback. Dare I say both positive and negative. Showing your game to friends and even letting them play with it will give you a sense of progress which no amount of code check-ins will do. And even though you are probably not going to implement every piece of feedback you get, this is still a great way to keep objective. Anyone who’s ever worked on a piece of art (which a game in many ways is) knows that after a while of staring at or listening to something over and over again, you start losing objectivity about how it is really perceived. A fresh pair of eyes or ears are always helpful.

One of my earlier games was a written on a CASIO graphics calculator which we had to use in high school. The game involved maneuvering a dot through an ever narrowing path of obstacles. I remember how sharing an early version of it with a few friends and watching them play it under their desks during class, really motivated me to improve it and share it with others!

6th Challenge: The Surfing Fail

This one is really subjective and vague but I’m going to throw it out there. With all of my projects I have sensed that motivation and progress seem to come in waves. You start off with a good pace and make good progress for a while but it seems to slow down and potentially come to a stand still. But if you put in the effort and just get those blocking problems ironed out, you usually go into another phase of good progress and motivation. The key is to accept you are going to hit these tough spots and just keep moving, be it at a slow pace.