8
\$\begingroup\$

Typically in game development, linear development (waterfall model) is riddled with obstacles that drain the programmer's sanity (game turned out horrid, can't redesign). Enter iterative design. Iterative design allows for prototyping of various possibilities in the play space. Unfortunately, it has a major catch. As soon as a project increases in size, iterations become tediously long killing off the main advantage: rapid results.

How can one shorten design iterations for large scale projects?

\$\endgroup\$
  • 1
    \$\begingroup\$ I remember reading this article about the strategies Daniel Cook's company used to increase their game success rate. They did something similar to an iterative design where a single programmer or small team would prototype a host of game concepts - something very cheap and fast to do - before choosing which ones to pool expensive resources into. What you can take away from this strategy is that the iterative workflow works, if only to prune away the pieces that won't work. \$\endgroup\$ – JPtheK9 May 31 '15 at 3:36
  • \$\begingroup\$ Iterations are time boxed, so their length is dictated by how frequently you can get feedback. Iterations are not supposed to become longer. That is waterfall. \$\endgroup\$ – Fuhrmanator Jun 3 '15 at 4:08
  • \$\begingroup\$ this is a programmers stackexchange topic. \$\endgroup\$ – v.oddou Jun 4 '15 at 1:26
4
\$\begingroup\$

I think good infrastructure can help this. One example is having a nice, easy to use data system that engineers can easily expose new data through, and that designers can quickly alter data and see their results. Another good one is having a scripting language - like lua - that gameplay programmers, and even designers, can use to quickly prototype things in.

Also, having a nice art / asset pipeline that is easy to use and easy to get assets into the game.

Basically, remove obstacles to people doing their jobs and streamline their workflows.

Unfortunately, off the shelf solutions for those things don't really exist (even in popular game engines, these aren't all really solved problems), which means that you are going to have to invest some engineering time to get this agility. So, sadly, the answer is you have to spend time to make it so you can work quickly, which sort of defeats the purpose. Once you spend the time though, things go great. If you can re-use your work for future projects, the dividends are even better.

\$\endgroup\$
  • \$\begingroup\$ +1. So no cutting corners in game development, but they become easier to round with experience. :) \$\endgroup\$ – newton1212 May 31 '15 at 13:54
  • 2
    \$\begingroup\$ Yes, although I've heard people argue the exact opposite - cut all the corners when prototyping, just to get it done. Then when you are done with prototyping and have something good, throw all your work away and make it correctly. Its a tough question, to answer (: \$\endgroup\$ – Alan Wolfe May 31 '15 at 15:15
3
\$\begingroup\$

Timeboxing means iterations don't get longer

You ask how to shorten iterations. But that implies they are taking more time, which implies you're not applying time boxing. In any iteration when complexity starts to weigh more (or you have other unforseen setbacks), you don't change iteration length. You instead descope the incremental addition you planned at the start of the iteration. Some iterative methods suggest doing this assessment at the middle of an iteration (before it's too late). Read more about what OpenUP suggests:

Manage objectives When a team is falling significantly behind, or critical problems occur that prevent the team from meeting the iteration objectives, it may be necessary to descope work to ensure that the team delivers a useful product increment by the end of the iteration, while maximizing stakeholder value. Work with the team and stakeholders to revise the Iteration Plan and, as necessary, reduce the emphasis on less critical tasks by postponing them to a subsequent iteration. In rare cases, if the iteration objectives still seem impossible to meet, the team might consider terminating the iteration or reformulating the iteration to a new objective.

If you look at the first chart you can see that added value is less at later iterations. This means iterations still take as long as before, but maybe there's less new functionality (relatively) within each iteration.

As you say, iterative's strength is to reduce risk by getting feedback frequently. It sounds like you're talking about project complexity dogging you down on the later iterations? I don't agree this is a weakness of iterative. It's a weakness of badly managed complexity.

Theoretically, you put the projects biggest risks up front. This means you have a very unstable project, but as you manage the big risks, it is supposed to stabilize. Complexity, of course, is one of the risks.

Scripting languages and automated processes help reduce the risk of complexity, which can be called "accidental" complexity (and is discussed in another answer). Highly iterative yet complex projects (Chromium is a good example, even if it's not a game) have lots of infrastructure to manage complexity. Take a look at https://www.chromium.org/developers for lots of examples of things like coding advice to the BuildBot.

Risk reduces over time What this figure doesn't show is the project stability, which probably looks something like this:

Project becomes more stable over time

Until the technical risks are well understood, you're dealing with simple prototypes

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.