Recently Krystian, Fabricio Rosa Marques and me had a game design discussion session, intended as warm-up for our planned podcast. Unfortunately most of the recording was gone for technical reasons (good thing we did that test), and I want to bring up the main topic we talked about in that session.
The topic was The Role of the Designer: Iterative Design vs. Production Phases.
It wasn’t that condensed in our verbal discussion, mind you. I brought it up as a big, fuzzy question out of dissatisfaction in my current game project and process, where iterative design led (and is still leading) to a big amount of “waste” – stuff that has to be implemented for evualation but ended up being unused.
Fabricio’s main argument was that Iterative Design IS an indispensable tool for design, Krystian also pointed out that the teaching simply omits to tell you that you might feel like crap as a designer and lose confidence when throwing away your stuff over and over again.
Basically I agree with them and it’s good to hear affirmation (any of you out there feeling stupid when producing more stuff that doesn’t work than working solutions, drop me a line 
. My point besides the natural self-doubt (YMMV) is that this process can be problematic when not working alone, which is most of the time, either with a team (e.g. development studio) or with the client.
I feel strongly about this, especially in regards to the team environment, because the same kind of dissatisfaction with the own process was one of the main reasons that made me leave active studio development and start my current formal design education. I’m not regretting it, but still having that dissatisfaction is a major blow.
Whether in a game design job last year or in my current 1-man-job, iterative design feels like reacting and losing direction when the game never turns out to be what one forsaw and conceptualized.
What I’m also missing is to see how “finding the game” can be applied to the studio environment in a synergetic way.
Is the initial plan the vision – as in Keeper of the Vision, also often compared to the role of movie directors? Is that a useful comparision at all?
If in games, the initial concept seldom works out, how can the designer lead the pack without being the ‘creative proposing changing ideals’ (who’s all talk) and causing wastes and costs for the whole team when iterating? Especially when the team is more capable of walking the walk (improve the game by iterating), how can it be avoided that the designer is pushed back to the “artist” role? (which always included information design, certainly. But still.)
Today I stumpled upon this line “…separation between the designing phase and the implementation phase…” (via), which points out an important part of the problem. You can’t alway separate the implementation phase because that is part of the design process, of finding the solution.
To cope with multi-million productions, the games industry proposes prototyping with a small team until the core game is right before generating all the production values. But the biggest problem of this approach is that it scales down poorly. The smaller the production, the less cost you save with this approach. Or the less you have the opportunity to actually have this sandbox phase (as in my last game design job on a licensed PSP title with <1 year time frame).
If you’re an indie / a freelancing 1-man-shops producing Flash games, ‘prototyping’ might be all you do until release, with each prototype taking as much effort as the final version.
In this case, how do you justify all the overhead to the client, aren’t we supposed to know our stuff? If the result greatly differs from the early concepts (”saying one thing in the beginning and delivering something else at the end), how’s that for our credibility?
How to convince the client to pay for all the process when the result seems little compared to the efforts? And how to predict the cost, not only for quoting but also to estimate the amount of work so the indie can plan his life?
Well, I am a strong supporter of "iterative driven design". At least, as I read your post, it maybe does make sense in every area. I did mostly webdevelopment in the last month, and there iterative-driven design is god. Because the whole project (that is much closer to the audience) can move into a totally different direction. And this is not a fail, but a success than, if it turns out to work.
The problems you write about here seem to me like a failed implementation of iterative-design. If you are throwing away content all the time, where do you learn from the mistakes? Implementation is not meant, to do stuff, in order to to have to make no desicions. It basically is about enhancing.
And as you came along with the freelancers and indies. For me personally each game is an iteration. With the goal clear in mind: Getting better and better and stronger.
No matter what methodology you use, have have to make (sometimes painful) desicions. Put the fun back into iteration. Apply it right.
Aargh. Please correct the first sentence: it maybe does make *not* sense in every area.
Good point. We mentioned that in our discussion as well – the fact that iterative design is common and successfull in web design. I see now that the difference is that websites are largely static interfaces compared to games. So you can prototype them easily with screenshots and whatnot. Doing changes is easy as well.
In games, what you want to get down is not the interface but the overall game idea. It's a highly abstract and dynamic thing you are designing. When a prototype fails, it's difficult to salvage your work from that because a small change might require a fundamentally different approach. Also, it's not easy to do mockups as a lot of the experience comes from the actual implementation and the dynamics of the actual game.
Hi Martin, thanks for the feedback.
I'm not talking down iterative design if that's how I came off in the original post.
I also omitted other insights and arguments by Krystian and Fabricio, partly because there wasn't a clear cut answer and, thus, I don't want the post to sound conclusive.
I do have the feeling, like you observed, that I'm not getting enough out of my iterations.
The waste would be game mechanics I constructed to model certain real-world processes. I suspect that some of the candidates would do fine without the requirement of being realistic (I mean actually realistic as in "true to the real circumstances"). Game mechanics need to be complete to a certain extend so you could judge the emergent qualities, so every other try needed big parts rebuilt or even built from scratch, hence the waste.
After these failures, the latest realization is that the scope of simulation might be off, causing the models to repeatedly fail as a whole and therefore hard to incrementally improve.
Interesting discussion here. I wonder, why Krystian is seeing websites only as "static interfaces". From my POV, they are socio-technological environments, connecting people and information. But that's something different here…
For games: I could imagine an interesting experiment in doing games in iteration (maybe we should set this up as a project). Start at zero, and than iterate, no matter in what direction. Just enhance at every step: Prototype – not fun? Put the fun back in. Game Machanics sucks? Create something better. Grafics do not fit the storytelling? Make it work somehow… This could be even more interesting, if many extremely different people are involved into that project. Just don't try to make a RPG (for example) from scratch, but let it be a bastard, mixed out of everyting.
Ah, @yu: I am not talking about changing the game-mechanics at a alomost finished project.
Websites & Static: Ok, let me clarifly. Obviously websites do have a lot of interactive and dynamic quailities. But the interaction you have with a website is often quite simple –
1. you click
2. you get a page of content
3. repeat
And it's the same for every website. So it's easy to prototype, for example with mockup screenshots and power-point.
Games are much more dynamic, often require constant input and give dynamic feedback on your input. There is often no way to properly portotype the, without actually coding the mechanics.
I got your point Krystian. But I think you underestimate the "complexity" of web-projects, while you do worship games as "king" of complexity.
I don't see it like that. For me both are highly dynamic in nature. Essence of agile is, that you do not have to care about every single detail beforehand, because they turn out to be different in the end.
Read i.e. this: http://gettingreal.37signals.com/ch06_Rinse_and_Repeat.php
Anyway, still like the discussion!
Geez, that was a short article. You could have quoted it here.
And 37 Signals is a web company. So for example, when doing a game, you can't really have "things you care about later". The whole system need to be there. It's different in web development. Also, in web development, things like usability can work as a guideline. Applying usability on games doesn't work out so well as we have written already in numerous articles.
For a more detailed model, try this. This guy actually developed games AND applications:
http://lostgarden.com/2006/04/managing-game-design-risk-part-i.html
Finally, I don't mean to belittle web development. Quite the opposite. I think it's a great advantage to be able to use those powerful techniques. I think we might learn a lot of lessons for game design there. But having done quite a few projects in both, I strongly disagree with you: there is a big difference and already told you why I think so.
Just stumpled upon this Eurogamer article with thatgamecompany's Jenova Chen. He said Flower's development was
"…50 per cent under feature", "100 per cent over schedule" and "400 per cent fail".
Not saying my game is comparably innovative, but seeing similar development experiences by one of today's most prominent game innovators is soothing.
Btw, I'm very much looking forward to their Post Mortem on Flower on the GDC Europe in Cologne. Just have to somehow afford the 180€/200€ for a student pass (wtf!?).