Resourcefulness vs Resources

May 27, 2009

You Don’t Need More Time, Staff, or Money

Developers often wish that they had more time, personnel, or expensive development tools, believing that these are the keys to producing a better game. Any project could be made with more of those things. More importantly, any project could also be made with considerably less of those things.

There’s a common misconception that given unlimited resources, unlimited time, and unlimited headcount, some sort of incredible game would inevitably result. I reject this notion entirely. My proof? Wii Sports is a much better game than PS3’s Lair – by critical reception or sales numbers, even though there were about one-fifth as many people tied up in its development. There are obviously some huge projects that come out well too – I’m partial to Oblivion by Bethesda – but there are more than enough smartly made small projects and offensively spoiled huge projects to provide evidence that more money, more time, and larger headcounts are not the recipe for success.

Order of Operations

Given that every project is developed with finite resources, Order of Operations is always an important part of making the most out of what’s available. It’s a key difference between how indie developers work – mostly out of necessity – versus how large companies operate.

When anything changes about a project’s plans, some previously made assumptions become disrupted and need to be rethought. No change goes without rippling effects to the rest of a project’s design. The important thing is that where possible, we’re mindful of how those changes (a.) trash or thrash work we’ve already done (b.) are free because they only trash or thrash planned work that we haven’t actually done yet (and c.) might increase need for resources by creating additional user expectations or introducing new unsolved questions.

Awareness of Relevant Decision Space

Consider this graph from some of my old materials:

The project’s time passes from left (start) to right (finish), and the vertical thickness of blue corresponds to how many decisions must be made before the project is done. The project is born with one decision (to make a game), followed by a few others (what’s the focus? which platform? which genre? why?), into the explosion of questions that are answered actively during development (how to program certain features, how graphics will look and how the sounds will sound). The project ends when one final decision is made (is it done?), closing its Relevant Decision Space. If the game needs an update/patch, it’s pretty simple to visualize another bubble swelling up then tapering down to nothing somewhere to the right.

Divergent vs. Convergent Processes

The main reason I share this graph is to illustrate one very particular distinction: the difference between Divergent and Convergent processes. “Divergent” refers to decisions that increase the number of decisions that will need to be made before the project can be considered finished; “Convergent”, by contrast, refers to decisions that decrease the number of decisions that will need to be made before the project can be considered finished. The terms refer to whether they cause the height of the blue line to diverge (move apart) or converge (draw together).

A project early on in the pre-production or design phases is overwhelming Divergent decisions: we should make a game, it should have 27 levels, we need 8 types of weapons, it’ll take place part of the time on Mars and part of the time in Hell.

A project in the production or finaling phases of development is mostly a series of Convergent decisions: no more work on that level it’s good enough, cut that enemy type it’s going nowhere, we need to stop adding features, cut the characters and story elements out entirely, the manual should include the phrase “random full-body explosion” because dude that’ll be hilarious, and let’s call this game done.

Minimum Work Required for Completion

The vertical height of a slice from that Relevant Decision Space graph represents how many decisions are left to be made before the game can be considered done. How much you’ve expanded out by Divergent decisions, therefore, indicates exactly how far you have to swim back to shore if you start getting tired, hungry, and seasick.

At any given point in a project – but especially in the second half of development – considering the minimum number of Convergent decisions that you must make to call the game done is the way to know when you need to outlaw Divergent decisions. If you wait until the very last minute to do that, though, you rule out the possibility of exploring Divergently any interesting gameplay ideas that emerge late in development.

Many Types of Convergent Decisions

Note too, that as illustrated in the graph, there is more than one way to cause the RDS to converge. Deciding that the work isn’t worth doing, from an RDS perspective, is equivalent to actually doing it. Cutting a level, weapon, item, or feature entirely immediately closes every questions that was going to come up in the process of developing it.

That said, scope cutting isn’t a perfect solution, especially since people often leave necessary elements for later – menu systems, ending sequences, or elements required to tie the project up and call it done. One way smart developers stay ahead of this is by knocking those elements out when there are still resources to spare, which enables working closer to the last minute on the more exciting and creative optional elements. Then if time or money becomes an issue, those features can be cut immediately, and the consumers will never be the wiser (unless you promised them co-op multiplayer in a magazine interview years ago. hypothetically.).

Mostly for Projects with High Level Design

As a disclaimer, this way of thinking is considerably less relevant when developing a sequel, clone, or port of an existing game. When the high level questions have already been answered (what’s this about, what are the fundamental behaviors), and it’ s mostly an exercising in replacing the content from an existing game with different weapons, levels, items, and units, then there are far fewer decisions that might risk switching from birch tree to redwood; attention gets spent instead on placing leaves and posing branches. Or, put another way, it’s like the difference between writing for seasons one and two of a television show – trying to define how that universe operates, and what the character’s personalities are like – versus writing season six, by which point you’re just struggling to not alienate or confuse viewers who know as well as the writers do precisely how the characters ought to act in most situations.

Unfortunately, this difference is also why developers that seem to have plenty of experience making several other projects (often starting from whatever work they could find – i.e. making sequels, clones, or ports) run an equally high risk of making these mistakes mindlessly (but with added confidence!) when working on their first original projects.

Oak Trees Grow From Small Seeds

We get frequent reminders from the indie geniuses at and elsewhere that it’s entirely possible to do great things with a small team – even working alone in some cases – spending no money and working in tiny time frames. Take a look at what they do, and take an interest in how they do it. They’re resourceful because they have to be, but having a budget or experienced team is certainly not a good reason to get lazy about making the most out of it.

(Originally posted as Vol. 2 Sec. 2)

Este artículo está disponible en español. Traducción por cortesía de Andrés de Pedro.

Learn and practice team game development with Gamkedo Club.
Membership worldwide. Professional support. Proven process.

Subscribe by e-mail to receive weekly updates with Gamkedo.Community interviews and YouTube training videos for game developers!

All contents Copyright ©2018 Chris DeLeon.

Site production by Ryan Burrell.