Indie Game Development Hurdles
This month we are going to look at the obstacles that can break a game development project. The first thing that comes to my mind is... the complexity of the job, what else? I have said it before and I'm going to repeat it again: being a game developer is a complex, difficult task - it's much easier to be a salesman, for example, and the pay is probably better if you are working in sales. Nevertheless, I don't know of any sales person who has awakened his / her neighbors in the middle of the night with his / her "YES! It works!" series of shouts. If you like living on the edge, you could either try bungee jumping or game development - the differences are minor.
Let's get back to the hurdles, though. It's extremely important to have good relationships with your team members. Remember that you won't get any payment for your work until the game is done, so it's easy to lose motivation along the way. The "we're a team working towards a common goal" feeling is what we're aiming at. Working with your team remotely makes the things a bit more complicated; you can't meet with the other guys and just hang out with them, eat a pizza, brainstorm in the same room, etc. We're losing a good part of the fun, but that's how it works when you are teaming up with people from around the world.
Another thing that could break your project is the lack of a design document. The details might be in your head, but if they aren't written on paper, the other team members can't follow your design. Make sure to set up a broad set of tasks, broken down by categories. As an example, if you are a level designer and you're creating a new level, you will want to have the following tasks (just an example):
- 2D design / level sketch;
- Concept art;
- Additional, needed props (models, sprites, etc);
- Actual level design;
- Performance optimization.
Then, you will want to estimate the durations for each one of the tasks. If a particular task will take you more than 1-2 weeks, you might want to split it into several sub-tasks.
It's time to set up project milestones now. It's a crucial part of the process, because it gives the team something to strive for. Milestones are practically pre-release versions of your game, with an agreed upon set of features. Third-party developers are paid by the publishers when milestones are delivered; this isn't the case when you are an indie game developer, though. Bringing in a lot of people from the very beginning isn't always a good thing; their enthusiasm can vanish because they don't have too many specific tasks to take care of. This explains (partially) why we've lost some of our artists, so we had to reconsider our milestones - always make sure that you've got a backup plan in place. Having an initial design that only highlights the major features of the game is a good idea; as your team grows, you will be able to add more and more of those tiny details you've always wanted in your game.
On the other hand, this is an issue I'm struggling with each time I'm creating a game: don't over polish your game! If you're like me (the obsessional type) you will want each one of the game aspects to shine. This is not a bad thing, but it prevents you from bringing your game to an end. I'd mention another similar obstacle here: feature creeping, the tendency of making the game better and better by adding more and more exciting features to it, revamping the graphics, and so on. It's a good goal, but it will postpone the release of your game forever. There's a saying in the game development industry: "Ship it!"; at some point you are going to need to wrap the game up and get it out, so that you can move on to your following game(s). Important hint: having a prioritized feature list offers great possibilities in case that you decide to dump some of the features.
What happens near completion? Most team members will be exhausted, after working without pay for many months (or even a year or two). Nevertheless, knowing that 95% of your game is finished will give you the drive to move on. An important, and yet most times overlooked thing is to test the game extensively. Yes, you know that you have to get the red key in order to open the red door, but maybe you can simply jump over the red door, a "feature" that wasn't planned and destroys your design. A few fresh pairs of eyes might work wonders here. Other problems could appear because some of the already implemented features don't work anymore; a new piece of code has damaged parts of them.
Crunching, the extended periods of overtime, is what happens when the team is approaching the deadline set for a milestone, but the light at the end of the tunnel is still far away. Short term crunching can increase the productivity of the game, but adds stress, fatigue and so on. I've been through crunch time many times and I can tell you for sure that it won't double your productivity. In fact, as crunching continues, the productivity drops at a constant rate. On top of that, the developers tend to make more mistakes, so the quality of the game suffers.
Finally, the game release brings on one of the least desired parts of the development process - maintenance. Most consoles have nearly identical hardware, but PCs are of a such great variety that they can lead to numerous hardware and software conflicts. The developers will try to take into account the usual PC configurations, but they will never be able to anticipate how their game will run on all the PCs in the world. The programmers will wait for a period of time, in order to get as many bug reports as possible, and then they will start working at a patch. This might take days, weeks or months to develop and sometimes include a few new features, in order to entice other people to buy the game (or to make the existing customers even happier).
Developing your own game is a great adventure, but it's a difficult one. Your first game won't be perfect - few games are; nevertheless, if it entertains your customers you have accomplished your mission. And it's always better to have a less-than-perfect, finished game, instead of having a on-the-road-to-perfection, not finished game.
What is happening with our "Full game" community project? Some of the team members have retired, so we'll get to split the royalties among fewer people ;). We are creating a public game demo that will (hopefully) be out in a few months. Meanwhile, take a look at these fresh screenshots - we've got a real game running here, guys!
Fortress level by Pavle
New Main Menu code by RedPhoenix
