The Keeper of the what? The Role of the Designer: Iterative Design vs. Production Phases.
This Blog has moved to
http://www.gamedesignreviews.com/.
This particular Page has moved to
http://gamedesignreviews.com/scrapbook/the-keeper-of-the-what-the-role-of-the-designer-iterative-design-vs-production-phases/.
If you are a recurring visitor, please update your bookmarks & rss feeds. We apologize for the inconvenience.
9 comments:
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!?).
Post a Comment