Sunday, January 14, 2007

Game or Tool?

This is a slowly aging question: when does a game turn into a tool? We're pretty sure that Half Life II is a game and Garry's Mod is a tool. But where do you draw the line? Is SecondLife a game? A tool? A game when you play it one way and a tool when you play it another? "Creating content" doesn't make it a tool: you're creating content in WoW when you equip a new piece of armor or make a healing potion.

There are lots of places you could draw the line. One interesting one is longevity of content: if the system creates long-term content, it's a tool. If it doesn't, it's not. In the WoW example, what armor you wear is pretty much a short term thing. Even a squad of ten dancing orcs isn't long-term, because eventually it'll break up. But if you can record ten dancing orcs, it is suddenly long-term content...

The only reason I think about these things is because the dichotomy has got to be a false one. There has got to be a method of creating content which is a game, or game which is a method of creating content.

There are tons of tools out there that try to help you create better stuff. In many ways, the march of human progress is measured in improved tools. But as tools get more advanced, they also get more complex to use. I don't mean the amount of skill you need increases, simply that the complexity of the interface increases. A piece of paper and a pencil is something that anyone can understand (although it requires great skill to do great things with). ZBrush is something that even some 3D specialists can't get the hang of - it has roughly ten million buttons and options.

I think this is the true dichotomy between "game" and "tool". Tools have been getting more and more complex interfaces, whereas games haven't. Even the most absurdly complex games aren't actually very complex to use, and games with more complex interfaces have smaller audiences.

Unfortunately, there is an inverse relationship between time to content and complexity of interface. You can write down and draw every single thing that a game can do in a giant tome, like the dark god of all illustrated "choose your own adventure" books. But not only will that actually take longer than creating it with a complex-interface software tool, it also creates a more fragmented, irritating result. This is because simple tools are really only suitable for small amounts of content: you can write a beautiful story on paper, but you can't realistically write a story arc which reacts to the player's preferences using such a simple tool.

But! But!

But Red vs. Blue.

There is a path, if you can tell what I'm getting at. A path where a lot of high-quality content is already there, and a simpler interface is suitable for making it go in specific, fairly simple ways.

Ah, simple stuff, right? Machinima's old news. We already knew that.

What if we take it a step further?

What if we create a bunch of simple tools, each one of which does only a small part of the final system. You already see this to some extent, with specialized tools for 3D modeling, texturing, and animation - even specific tools for modeling people vs structures vs equipment vs clothing...

Then, each tool can access the content created in the other tools. Sort of like choosing a character and set before you start filming your machinima.

Pretty much already exists? Not really at this level, because often they simply say "go make a model in your favorite modeling software", which isn't really an "easy" tool, is it? Plus, they aren't really interactive with other tools in the same way I'm positing. But we're drifting in this direction. We might see further drift in this direction with the advent of Spore, with its three or four interactive simple tools.

But steps into the future are never really enough, because by the time you reach the future, everything is different. Abstraction is critical, or you'll end up with tools that simply can't accomplish what people want to accomplish with them, or at least not easily.

So what about a system for designing simple toolkits and specifying how they interact with each other? To take it a step further, if each of these simple toolkits was a "game" that, as you played it, created content suitable for the other toolkits?

Blaaarrgh!

3 comments:

Craig Perko said...

As Jeff accidentally pointed out, the real difference between games and tools is that tools don't have a magic circle.

Patrick said...

Well, according to your "all games are social" thesis, all games have a fragmented magic circle, so there's no fine line, even a circular one, between games and tools.

Play With Fire had two fairly simple tools, one for assembling blocks into objects, and another for assembling objects into levels. They were both simple enough to use that a half dozen people with varying degrees of technical skill were able to produce over 200 levels in their spare time over a few months. The tools have been released to the public with the game's launch, so we'll see how effective they are at encouraging player creation of content.

I would say the core of PwF's design lies in those tools because they allowed a fairly simple (but fun) dynamic to be extended pretty dramatically with very low resources involved.

Craig Perko said...

Play With Fire's method was good, but very limited. After all, the only real gameplay is rolling around burning stuff up: you don't need to worry about social games, or working infrastructure, or whatever.

On the other hand, magic circles don't have much to do with my "all games are social" idea. As far as I can tell, the two are completely independent...