{"id":269,"date":"2009-11-25T07:11:07","date_gmt":"2009-11-24T21:11:07","guid":{"rendered":"http:\/\/www.doolwind.com\/blog\/?p=269"},"modified":"2009-11-25T07:11:07","modified_gmt":"2009-11-24T21:11:07","slug":"pragmatic-game-development","status":"publish","type":"post","link":"https:\/\/www.doolwind.com\/blog\/pragmatic-game-development\/","title":{"rendered":"Pragmatic Game Development"},"content":{"rendered":"

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

Leverage existing technology<\/strong><\/p>\n

Game developers have a bad habit of re-inventing the wheel.\u00a0 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.\u00a0 We need to swallow our pride and use technology someone else has spent time and money creating.\u00a0 Our core focus is making games, not game technology.\u00a0 Let the experts handle the technology for us.<\/p>\n

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

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

Aim Small<\/strong><\/p>\n

Projects always grow over time, sometimes uncontrollably.\u00a0 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.\u00a0 Ordering features by this ratio and cutting features from the bottom of the list when time runs out.<\/p>\n

Feature creep is a killer on projects of all sizes.\u00a0 By keeping milestones short we minimize the opportunities for us to diverge too far from our main goal.\u00a0 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.<\/p>\n

Build what you need, not what you think you need<\/strong><\/p>\n

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

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”.\u00a0 If we do this for all our features, we won’t create our first game, let alone the next five.\u00a0 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.<\/p>\n

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

It’s done when people are happy to pay for it<\/strong><\/p>\n

A game is never going to be perfect.\u00a0 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.\u00a0 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.<\/p>\n

It’s easy to fall into the trap of not wanting to release the game until it’s perfect.\u00a0 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.\u00a0 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.<\/p>\n

It is often better to cut a feature to give time to polish the existing gameplay which leads me to my next point…<\/p>\n

“We’ll do that in version 2”<\/strong><\/p>\n

Release early and release often.\u00a0 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.\u00a0 Plan to give away free (or cheap) “expansions” of core gameplay pushing the development of these features back until after initial release.\u00a0 This has a number of key benefits:<\/p>\n