For those who still care, Anyuzer posts that he doesn’t play games for the people, does some soul-searching, and then says in a bit of revelation, “I come for the game, and stay for the people”. Which as Raph points out, is already considered dogma amongst us.

But the real interesting discussion to me is Dundee mouthing off once again, this time on the topic of implementation of design, and more specifically, how the current way the industry works – doesn’t. A snippet:

The main problem I have with designing the systems first, then adding content to them, is that sometime the content cannot make the system entertaining. You can come up with some really elegant systems design. It looks balanced on paper. This guy does a lot of this, and a little of that. This other guy does a little of this, and a lot of that. But what if that just isn’t very fun?

Nailed it in one. This brings up an excellent excuse for me to bring up again one of the really interesting articles I’ve stumbled across recently, “Developers Missing the Whole Point” by Walter Kim on Ludonauts. While he places too much emphasis on story (I think ’story’ is overrated, but I’m just saying that to get a rise out of people), what he talks about is an excellent look under the hood of why our games are getting less fun. Money quote:

People on the assembly line of Porsche production may not have to talk to each other all that much, but you can bet that the designers that figured out the size and shape of each and every part of the car, did. Yet many level designers for videogames appear to be forced into a position more akin to assembly line workers, when there’s essentially no equivalent position in game development. Unlike assembly line production and car design, there is no production in videogame development that does not result in a game design decision.

Bingo.

Usually, development teams are divided up into Programming, Art and Design, each of which will have its own lead. This reinforces the seperation between Systems and Content – programmers do systems, and designers and artists do content after the programmers are done. We build schedules that reinforce this – it doesn’t matter WHEN the designers fill the system with content, just so long as they do so after the programmers have coded the system. If something is wrong, usually the coders have moved on to the next line item in the schedule. When teams were small, this was less noticeable, but now that teams are huge, its difficult to know what’s happening on another part of the project.

This situation is bad for a number of reasons. The first and foremost is that coders don’t really feel bought into the system, because they aren’t really helping to carry the ball over the goal line. The second is that, if the designers find that how they use the system provides an inferior experience, they have to go back to the Powers That Be and ask for more coding gruel.

There are a couple of ways around this. One is to let designers code, usually in some sort of limited script language. As Dundee notes himself, this way can lie madness:

Not that this approach doesn’t come with its own terrible, terrible consequences. There is an entire list of days I rue.

Not to put too fine a point on it, but designers often don’t know the best way to code something. They often don’t know or understand coding standards. They don’t always understand how things fit into a larger structure. They often don’t know how to code tricky engineering problems adequately – I remember UO once getting one-minute lag spikes because a designer had done the guild roster sorting poorly.

And of course, designers who can code are the ones who try to reach for the brass ring, implementing features without UI or polish. We can’t ask for code, and so we’re forced to implement our mad visions with the limited tools and capabilities given to us. Are you playing a slot machine where the results all come out in the chat window? A political system where every command is a slash command? Your mob transform into another monster, with a noticeable flicker in between? I’ll bet a designer wrote that.

Another solution, and one I’ve had success with in the past, is what I call ‘Strike Team’ development. This was a development term that I first heard about in an article about how Squaresoft develops their Final Fantasy projects (an article I can no longer find). The article answered the immortal question “How come Square can have a 200 man team make great projects, whereas my 20 man team can barely agree on where to go to lunch?”

So break up the design-programmer-artist pigeonholes, and instead build teams based on features. Two programmers, one artist and one designer are the Combat Strike Team -their job is to be sure that the total experience of Combat is the best it can be – fun, fair and polished. As such, content and systems are developed together, iteration is expected, art, programming and design are all bought into the final result, and everyone sings Kumbaya at the end.

Are there problems with this solution? Most certainly. Chief among them is that it’s very fluid and difficult to schedule, and the guys with the bags of cash like things that fit neatly into MS Project. But fundamentally, something as elusive as ‘fun’ is something that defies nice little hourly increments.