Sunday, September 17, 2006

Game Design With Balls

[Game Design]

I remember my first frustration with being "taught" to play soccer. I said, "Why do we need rules? Can't we just kick the ball around?"

Today I was at a picnic at Lake Burley Griffin, where I had the opportunity to observe that same casualty of maturity in action. A group of six boys under the age of nine were kicking a soccer ball around with a older friend, who was maybe 14. Play proceeded for about a quarter-hour, until the older boy stopped the ball with his foot and declared that his side was winning.

Much has been written about the evolution of play behaviour. Chris Bateman has an article on the concept of paidia that's well worth reading; dealing with the pattern of play that results from children encountering an environment and experimenting with the objects in that environment. When a child encounters a new play space for the first time, they don't ask, "What am I supposed to do?" They simply do things, and see what results.

So why do we so rarely build games that way?

The dominant paradigm of contemporary game design is top-down design. Creation starts with imagining a challenge scenario that will be electronically simulated, with one or more implicit or explicit goals built in. We decide we're going to replicate the experience of flying a lone spaceship through the heart of an alien fleet, that we're going to do it in the form of a 2D scrolling shooter, and that the goal will be to complete all the stages of the game and survive. Or we're going to replicate a Tolkien-esque fantasy milieu and the goal will be to save the world by means of defeating the evil overlord.

It's a given - that's the normal way to design games, today. But it's nothing like how we did it as children. I don't recall ever designing a game for my sister and I to play by saying, "Let's play something where the aim is to get an object into a goal defended by an opponent." We said, "Let's play a game using this ball." We'd get the ball, we'd kick it or throw it around, and we'd start to get a feel for what was easy to do in the environment, what was challenging but possible, and what was too hard to achieve. And slowly, some or all of the things that were challenging would become the explicit goal of the game.

I had the same experience during my brief time as a modder. I spent hours designing levels for Doom, Duke Nukem 3D, and Aliens v Predator 2. Never did I start from the perspective of designing a gauntlet for players to run. I always was drawn in by the challenge of creating an interesting environment, and then making a game out of it.

A couple of house-moves back, I replicated the house I was living in as an AVP 2 level. I think anyone who's ever played with a level editor probably tries that at some stage. It was a pretty decent replica, as these things go. I had heaps of fun just running around the building from the perspective of an alien, crawling on ceilings, bouncing around on the roof, scuttling down hallways. Eventually I decided it would be even more fun if I was a colonial marine and the house were surrounded by various types of alien, which I had to fend off in a desperate last stand, counting every valuable round of ammo as the hordes closed in. It started to actually look like a game, but that certainly hadn't been the plan from day 1.

So often when I play a game today, and decide that I don't like it, I'm left with the perception that it was a great idea that was sadly short on enjoyable gameplay. And it's a one-way street. As a gamer, you're rarely left complaining that a game had fantastic gameplay but poor story or graphics. And when you do, it still doesn't stop you playing the game.

So if gameplay's so important to the success of a game, why don't we design that way? Just create an environment, with objects you can interact with, and let the play develop. Eventually someone will put their foot on the ball and tell us who's winning - let's let it be someone who's already enjoyed the game enough to care.

4 comments:

Jey said...

An interesting read.
Bloody bossy kids! :P

Chris said...

I suspect the answer to your question 'why do we do it this way?' is that this is the only form of project management the majority of the games industry knows. Big companies are seldom if ever agile, and consequently they expend a tremendous amount of effort maintaining a planning process which regulates development, but simultaneously straight-jackets it.

This is one of the many reasons why I feel the indie market is important - because on a small budget one can start with play and *then* make it into a game. At least on paper. :)

However, I must point out that some Japanese companies prototype then start over 'from scratch'. This allows them to see what works in the prototype and build on this for the main game. Although slightly costly, I think this is not a bad approach.

Thanks for getting the round table rolling, so to speak. :)

Oh, I just noticed you link to me but I haven't reciprocated. Now fixed.

Best wishes!

Greg Tannahill said...

Huzzah! Thanks for the linkage, Corvus & Chris.

I've never really played with Digg to see what it was all about. May have to invest some time to see how to make it work for me.

Chris - I think a bottom-up development model may actually have some benefits for the industry, particularly for budgeting. Building play-first means that if you suddenly run over-budget or past deadlines, you can wrap things up quickly and still have something very playable. If you try to do the same thing to a game built the other way around you'll likely end up with something which is, to paraphrase Miyamoto, "a bad game forever".

Anywho, thanks for the comments! I've got a whole pile of sidebar updates in the works which I'll hopefully get to before I leave for TGS. There's a couple of places like Gaming Hobo who are giving me linkage who are certainly worth getting something in return.

Anonymous said...

I really like your approach!

In a way, you can see things like this happening with Second Life and Google Earth.