What fanatical pragmatism is

Fanatical pragmatism involves pursuing the optimal product as cost effectively as possible, without cutting corners.  For anything non-trivial, see if there is an existing solution that can solve the problem.  For games, this involves using a 3^rd party engine, particle system, etc wherever possible.  It’s about solving the problems that need to be solved, in the cheapest way possible.

It’s good for developers as focuses them on completing as much as possible, as quickly as possible.  It’s also good for the business as it means the problems the business exists to solve are solved as cost effectively as possible.

What fanatical pragmatism isn’t

It is not about cutting corners to get to a solution faster.  Nor is it about ignoring long-term goals to reach short-term goals faster.  Fanatical pragmatism is not “cowboy coding” (rather it’s tangential to it) and it’s more about solving the businesses needs for the least cost than just getting things done quickly.

How scrum fits in

It fits in perfectly with agile development practices, particularly Scrum.  Scrum is a discipline-agnostic framework that gives developers the freedom to work within their own specific style.  For this reason, fanatical pragmatism works hand-in-hand with extremely short sprints and meeting changing customer demands.  It acts on high-level sprint planning (deciding what goes into a sprint) as well as low-level, day-to-day development such as exactly how to solve the tasks for a given sprint.  For this reason it can be embraced by both developers and management alike.

Some general rules

Some general rules I’ve found myself following recently:

• Broaden your knowledge.  I’ve spent the last couple of years running a software company focussed on web applications.  I’ve picked up a lot of skills that I’ve been able to transfer over to game development (and vice versa).  The broader your knowledge, the large the pool of resources you can draw from to solve problems.  The jack of all trades is the master of fanatical pragmatism
• Focus on the goal.  The key to keeping pragmatic is always looking at where you are heading.  Every decision from day-to-day task assignment to strategic planning should focus on where the team is heading.  All efforts should be in driving the team towards their ultimate goal(s).

Some general software development rules:

• Separate your concerns.  A big part of why MVC works so well for a game engine is that it keeps the obvious concerns (e.g. gameplay vs. rendering) separated from each other.  This keeps each person on the team focussed on their part of the problem domain and helps to reduce complexity as the software grows in size
• Clean Interfaces.  Keeping loosely coupled systems is a great way of isolating your code so that any mistakes made, or changes needed can be done with the least amount of hassle in the future
• Build strong architecture where it’s needed.  For some large, complex system’s it’s important to spend the time up front designing the architecture for the system.  This gives everyone a foundation to build upon.  This should only be done in rare situations though.  It’s easy to get caught in the trap of doing lots of big design up front, however fanatical pragmatism calls for this only when absolutely necessary, and enough information is known.

Conclusion

So that’s fanatical pragmatism in a nutshell.  Share your thoughts on the topic and let me know how you work best in achieving your goals.  I’m constantly evolving the way I work and I’m always looking for the best way to solve problems so please leave a message with your best practices.

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?