Let me start with an OT. Stupid editor lost my wip post only because I wanted to see if I can disable this stupid hotkey colliding with my text-editing habit (Shift-Control to select whole words). Of course, while implementing fancy Ajax hocuspocus, no-one thought about making user data sacred. How about auto-save when switching to “Settings”? I don’t see Word losing of my words when I go to Options. Take that for mimicking desktop applications, Ajax!
OK back to my original post.
I was reading the recent post at Humanized about iterative design and partly it just reminded me of the development of Legend of Kay.
Before I dive into my reflection, let me make clear that the critique is not about badmouthing my former team at Neon (we did Legend of Kay together). Considering that I was an integral part of the design team – if I may say so -, contributing to a fundamental fighting mechanic, some levels and of course refinement of most of the character designs during modeling (which was my main job), I’m really not in the place to blame anyone.
“To blame” is the wrong word anyway: Legend of Kay turned out not bad at all – having a better meta-score than Killzone 1 (stupid example, being different genres and all, but the PS3 song just came to mind). If anything, it’s about putting my experience and what I’ve learned in the recent years into words and, well, about reflection.
So, shall we?
…the problem statement “Design a better car” isn’t very good: it’s too abstract. Iterating a solution with a problem like this won’t get you anywhere, because the solution won’t be converge to anything in particular. There are too many ways that “better” can be interpreted. [...] Simply put, you don’t know when you are done because “better” is too open ended.
For Legend of Kay, the problem statement was often “make it cool”. But what’s cool? In case of the fighting system, it was stated that it should be “something like Soul Calibur but accessible” and “kinda like Zelda”. But we all failed to detect (or only to mimic, I can’t speak for the other members whether they did detect) that the key was balancing the move set properly.
[...]“good enough” and I stopped searching [...] This is a pitfall to be careful of in iterative design. It is easy to iterate, get to a place that is suitable, and stop iterating.
This is, in my view, what happened to us. We put a lot of efforts into making the control tight while having the animations look cool AND fit the control. It wasn’t a small feat by ifself – heck, it was our first major PS2 work (and, to my limited knowledge, to date still the only German developed, published 3rd person action console game. If I’m mistaken, please correct me, by all means). So, it felt like a big accomplishment and being something not every game at that time achieved, it was “good enough”.
Of course we had enough other production issues so it’s not like we could have done better if we “simply knew better” or “tried harder”. I mean we did tried and paid attention to have varied moves and enemies, but it is true that we didn’t iterate our problem statement much, at least in this case.
In retrospect, I would say that more should have been done in making each move count, gameplay-wise, by differentiating them a little bit more, by having enemy behaviour correspond to different move(s) and by carefully combining those enemies (and environments, winning conditions, additional goals etc.) to further create and tweak challenges.
This post possibly won’t be very comprehensible to anyone but the Legend of Kay team, but like I said: it’s mostly to help me reflecting.
PS. why the hell does the blockquote mess up all my following paragraphs? I only used the buttons provided by the editor, no manual editing. Grrrr…
Haha, the Paragraph about Killzone made me laugh! ^_^
Great article! I wonder why you put it in the Scrapbook, it would work well in Game Design Reviews.
The article opens up a problem: how to figure out what you should do? I mean, if you start with “build a better car”, how do you know where to add limitations to evolve the problem statement? I guess, most of the time there will be some technical limits (budget, technology) but if you focus too much on that you end up building stuff just because it is easy. I guess you need some kind of “compass” to guide you in your sear ch for the perfect problem statement. A kind of “vision”.
The whole topic is somewhat similar to the presentation about Advanced Prototyping by Chaim Gingold and Chris Hecker I like so much. You can’t really prototype anything when you have no precise idea what you want to achieve.
Btw, I’ll fix the blockquote thing as soon as I get my notebook. It seems like the template is fucked up.
Oh yeah and your article reminded me of a moment when I was working with Daniel Renkel on Excit. It was a game with a pretty well defined problem statement – it was a clone of an existing game after all.
When the first real prototype version was running, we had a telephone discussion about the “feel” of the game. Up until then, we thought that the player would look at a level, figure out the solution and then move the avatar. We called that something like “Think, Think, Move, Win”. However, the movement of the avatar turned out to be so much fun that we have decided to make it a more prominent part of the game by encouraging a different player behavior. One, where the player would figure the solution of a level while moving through it. We called it “Move, Move, Think, Move, Win”.
I thought it was quite amazing how much room for design there was even though the problem statement seemed so rock-solid at first. I also did enjoy the way we approched the “feel” of the game.
Thanks for the feedback.
I’m definitely (btw I HATE how people write “definately”) a think-as-I-go-type of guy. Maybe spoiled by Zelda where the puzzles mostly just flow. One reason I don’t like playing chess. Or RTS. Too much planning involved.
Regarding Scrapbook vs. Reviews. Well it started as a quick thought and more of a personal reflection, during and after writing I just didn’t think about re-categorizing it. It’s kinda borderline in this case I think. How about merging both blogs (if technically possible at all) to avoid this kind of confusion (and an extra decision before posting)?