Games take a lot of time and money to create.  Many companies can’t afford this ever increasing drain on their resources, particularly independent game developers.  Developers need to become more pragmatic in the way they developer their games.  This article describes the steps we’ve been taking to focus on releasing a good game, in the shortest time possible.

Leverage existing technology

Game developers have a bad habit of re-inventing the wheel.  The easiest way to run a game into the ground is to spend all our time creating new technology that already exists in the world.  We need to swallow our pride and use technology someone else has spent time and money creating.  Our core focus is making games, not game technology.  Let the experts handle the technology for us.

For programmers, there are countless engines we can take advantage of from Unity3D to Torque to UDK.  Project managers have access to countless tools to streamline the management process and keep them focussed on running a good team.

Learn to spend money where it’s needed.  Development time costs money.  If a problem has an off-the-shelf solution, we compare the cost of buying this to developing the solution in-house.  Nine times out of ten, it will be far cheaper to go with the former.

Aim Small

Projects always grow over time, sometimes uncontrollably.  We aim to start small, and keep a keen eye out for features that can be cut, checking the cost-to-benefit ratio of everything we do.  Ordering features by this ratio and cutting features from the bottom of the list when time runs out.

Feature creep is a killer on projects of all sizes.  By keeping milestones short we minimize the opportunities for us to diverge too far from our main goal.  If a feature grows in complexity beyond the scope of the initial design we take a step back and re-evaluate whether that feature is necessary given the new estimate on how long it will take to complete.

Build what you need, not what you think you need

Too many developers spend months working on the technology for their next game before starting the game itself.  Sometimes, they never make it to developing the game!  The most pragmatic solution to this is using someone else’s engine.  However, if we must create our own technology then we only create what we need right now.

A trap many developers fall into is thinking “we’ll be using this feature in the next five games, so it’s worth putting a lot of time into it now”.  If we do this for all our features, we won’t create our first game, let alone the next five.  My rule is that I don’t have enough information to make a generalised solution until I’ve implemented it at least a couple of times.

A great way of achieving these goals is adopting an agile development practice.  We are using Scrum for our current game which helps to keep us focussed on creating just enough to reach each sprint/milestone.

It’s done when people are happy to pay for it

A game is never going to be perfect.  I’m not advocating the release of buggy, broken games, but we do need to be practical when deciding whether our game is ready for release.  Creating constant playable builds is the best way to make sure the game is always fun and always meets a pre-determined quality bar set by the team.

It’s easy to fall into the trap of not wanting to release the game until it’s perfect.  After working on a game for months or years, it feels like your baby and you don’t want it out in the real world before it’s ready.  Being pragmatic means making the tough decision of deciding when the time is right to release the game even if you’re not 100% happy with it.

It is often better to cut a feature to give time to polish the existing gameplay which leads me to my next point…

“We’ll do that in version 2”

Release early and release often.  The best way to break the hit-driven nature of the games industry is to break the usual tradition of a big release with minimal updates after.  Plan to give away free (or cheap) “expansions” of core gameplay pushing the development of these features back until after initial release.  This has a number of key benefits:

• Begin to earn revenue sooner
• Drive the initial cost of the game down by releasing additional content in a paid or subscription format (e.g. DLC, in-game assets)
• Valuable feedback on the direction to take the game
• Focus on the bare minimum set of features to sell the game, minimizing feature creep
• Form a closer relationship with gamers by giving them constant updates

Use the highest level of abstraction possible

The higher the level of abstraction, the more time can be spent working on the game, rather than working on technology.  We are happy to give up some of the control over run-time performance for an increase in development speed.  Programmers can use a programming language like C# allowing them to spend time making a fun game, rather than managing memory and resources.  Artists can use a tool like ZBrush to create good looking models more easily and quickly.

Automate

Any repetitive day-to-day tasks should be automated by technology.  From build creation to the art pipeline.  We keep our time focussed on making a better game, not performing menial, repetitive tasks.  Programmers need to get in the mindset of spending a few hours per week working on tools to make everyone’s life better.  A programmer spending a few hours adding a new tool or updating an existing one can save weeks of work for the rest of the team.  Artists can learn batch operations in 3DSMax and Photoshop to help this process

Conclusion

This gives an insight into the ways we are being pragmatic in the development of our game.  By constantly focussing on the final product we make sure our time is spent on the most important tasks at all time.

How pragmatic are you in game development?  Do you have any other tips for minimizing cost and time?