Game of Design

This interview with Valve’s Doug Lombardi highlights Left 4 Dead’s AI Director, which I hadn’t heard of. Dynamic spawning is the first step towards the procedural storytelling I’ve been working on for the last couple of years. Finally some of this stuff is getting published.

Yes, dynamic procedural storytelling might ultimately never work. But, if you’ve played a pen and paper RPG you know it probably can. I’ve run these ideas through enough projects and models to feel it’s one of the next big story game revolutions, and these kinds of interviews get me all excited.

I know, I should write about it. Give me some time.

I’m in a defining mood this year, apparently.

For a long time I’ve thought there were two kinds of games, and they were approached in construction two completely different ways. Mechanics games are the mechanics driven, repeatable, shorter games, like Poker and Tetris, that derive their design from some new concepts. They are easy to spot - their PR tends to focus on these exciting new interactions. Story games are driven by their flavor. They are experience based, have a narrative arc and an ending, tend to steal their mechanics from mechanics games and polish them up. Their PR tends to focus on their characters and setting. Pretty much every big game you’ve ever heard of - Grand Theft Auto, Halo, World of Warcraft, Axis and Allies - is a story game. For a long time, I’ve thought this distinction was useful for the same reason that the PR is different - it helps you identify where you have to focus and what you have to succeed with.

But as time has gone on, this distinction has become less and less, well distinctive. It seems like the biggest distinguishing factor is no longer story or gameplay, it’s money. If your budget is over $500,000, you’re probably a story game. Portal by all rights should have been a mechanics game. It wasn’t. The prequel Narbacular Drop was. Portal was the polished up, story driven version, and it was awesome. We all loves us some story games. But we in the video game industry have lost something that still drives the majority of the market today. People love their simplicity, their mechanics exploration, and their replayability as well. Puzzle Quest, Bejeweled, and Solitaire are popular for a reason too. In a sense, story games are trying to transcend the medium, but in the process we can lose sight of where we started.

But we’re getting better. The key decision point I watch is when that “The End” screen disappears and we’re back at the main menu. If we’ve done our jobs well, story and mechanics together, players will pick “New Game” again every time. The ritual that has defined games for thousands of years.

Update: This blog reminded me of Soren’s Smart vs. Adversarial AI, and how it ties back into these concepts.  I’m thinking his Smart/Fun is directly tied to story games and Adversarial/Good is tied to mechanics games.  This model shifts most multiplayer games into the mechanics genres, which I think is all right.  Look at multiplayer game advertising.

(If you missed it) - a survey of the Top 10 most popular emotions while playing games. Fantastic work Chris. I had a lot of trouble understanding Bliss. I thought I got it, but realized later that I was really thinking of Contentment. I wonder where I experience Bliss over Contentment, if at all?

I can tell you I didn’t experience many of these emotions playing Devil May Cry 4 over the weekend. I got a whole different suite - Frustration, Anger, Bemusement, Boredom, and Sadness. Apparently not for me. Is there a survey of most common negative emotions somewhere as well?

Warning! AI Engineering Content Ahead!

I’ve been distracted all week, but I’ve been thinking about this long enough. Chris gave, in my opinion, the best talk at GDC 2008 and I’m a bit ashamed that I haven’t seen more serious consideration from the AI community about his hypothesis (the exception being here, thanks Dave!). There’s a summary of the talk here. I think he made 3 main points:

1. There are different categories of problems, which I’ve talked about before.
2. AI should be the most useful tool we have to make games. (I actually don’t agree with this. Games are primarily competitions, and many of the games we love best have no AI at all. However, that said, I do think AI is the most useful tool we have to interact with the player. AI, however, along with user interface and mechanics, is the communication between the designer and the player, and AI has the capacity to be the most detailed and most contextual.)
3. Identifying the building blocks of AI will allow us to create artistic AIs.

This third point is the most controversial, but the most insightful and the most ambitious. Can we find a basic set of building blocks for AI? Nobody seems to know. Obviously, it’s a hard problem, because it hasn’t been solved yet. And maybe that’s because it’s just not true. But I think it’s still worth examining critically. Let’s assume it’s true, that there is such a basic set. What would such a set look like? It should model “data” in a “code” system. Given my experience, it seems logically that decision-making (picking your prioritizes at any given point in time) will be our”code”. So what could be our “data”? It would have to be adaptable to the situation, reflect the personality of the character, and allow the designer to construct a set of interactions from it. Like:

• Stats. A questioner brought this up and it was a strong point. Most RPGs use stats to drive the game. Ultima 4 famously extrapolated it out to moral virtues.
• Game state. Stats are just basically game state, and game state is the core of most games. I’m pretty confident that if stats is the right direction, it will ultimately end up using the larger game state as well. Unfortunately, this doesn’t give us a lot of direction on the “code” way to go, and makes characters look a lot more like gameplay then AI.
• Actions or Behaviors. Concrete things the AI can do are another direction we could go in. This implies a “code” language to control them, which is usually script or a complex AI, but it might work. Actions are pretty tricky to imagine as a pure data set though, because they usually involve conditional logic, and have a close history with our friend the finite state machine.
• Goals. The current meme in AI engineering might work too. It’s a bit higher level then behaviors, but they are discrete controllable things. The concern I have is that in practice goal switching and control seems to be very primitive in modern games. This might be a sign it’s the right direction though.
• Objects. The Sims, for the most well known example. Objects that describe how they are used are already understood in the data-code model and are easily extensible. In this example though, Game State is usually used to set the priorities between objects.
• Animations and Motions. On an even smaller level, almost every character is seen through it’s motions. I have a hard time conceptualizing this data as AI, because there’s so many other things that can cause motion that don’t impart an AI. A player-controlled car for example. But if you broaden your definition of an AI, then there are pretty specific designer-created rules that specify when these motions occur, so they could be a core set. Unfortunately, it doesn’t seem like it simplifies anything.
• Others? Then we get down to the crazy list. Colors in the world? Sounds? Player Inputs? What else could be out there?

Of this list, it seems like Game State is the most obvious contender, since it’s a defining building block for many of these options. But it still opens up a lot of worms. How can we have a common game state given that most games are completely different? Is it really unique on a per-game basis? Or is there some sub-set of game state, like health for example, that is part of the basic art of AI? What would a tool for reacting to game state look like? I can imagine a lot of sliders and bars, maybe tweaking and tuning on a stage, until you get something that emergently looks right. We do this in test levels for AI already, so to speak. But that seems better for something like Objects or Behaviors and Goals model then it does for Game State.

This does make it seem, as I contemplate this problem, like there’s a set of underlying data and structures that really shouldn’t influence the art of AI construction at all. You could argue the triangle has the same problem in Modeling, relying on a host of 3D mathematically concepts and definitions like “point”. But I think that is a bit inaccurate - triangles really are the basic data structure of graphics and modeling. If we want to use that model as a guide, then we really should try and follow it.

I don’t know what’s next. It’s these kinds of logical loops that I think have caused others to back away from these ideas. But it seems like a fruitful area of investigation, and if I was doing AI middleware I’d be thinking a lot about this problem. What do you think?

I was going to start a page to compile some of the specialized Starcraft knowledge I’ve learned over the years, stuff that missed on the outdated battle.net page.  Unfortunately the wordpress.com software doesn’t seem to support linked page as well as say, google sites or a traditional wiki.  Does anyone have a recommendation on some way I could integrate this as a subpage into my blog?  Or a site that’s already doing this that I could contribute to?

So, after visiting “or” in Game Grammer last week, I’ve become more convinced “or” exists. There are lots of games that are complete enough and encompassing enough to be considered “or”s. World of Warcraft is a good example. It’s hard to argue that raiding and social play is not a fundamental part of the game, if not more fundamental then the leveling. But I’m still not clear on the value added.

In the most common cases, “or”s seem to add variation, very similarly to “with”s. The main difference is that “with”s are subtler and more optional - “or”s represent a broadening of the variation grey area next to “with”s. Many of these “or”s are not optional if you want to have the presented game experience, and they have the production and polish to show for that. But because there is limited focus in most products and they are not optional (World of Warcraft excluded), they seem to drag the overall quality of the game down. e.g. if you have both required combat and required vehicle levels in your game, both of them have to be easy and accessible enough that every potential player can complete them to continue. This is one of the reasons I think puzzle games may have struggled so much - puzzle games essentially are a sequence of “or” games strung together because the puzzles rarely build on learned skills over demanding new ones.

So what’s the lesson here? Be very careful adding “or”s to your game. If you can, find a way to tie them into the core game mechanically (”and”s) or make them optional (”with”s). If you can’t, recognize you’ve bitten the bullet and consider dumbing down at least one of your “or”s so that it’s not a barrier to entry and is easy to polish. And try again to tie it mechanically back into your main “core”, even if it’s just score or money. If you don’t try something early, you might find yourself dumbing all of your “or”s down instead of all but one.

Freerice.com is an interesting game, particularly in light of me highlighting Questionaut before. Not because Freerice is for charity (I have no confirmation whether it is real or not), but as an example of how taking a rather banal but important skill, studying vocabulary, and making it fun. A broad challenge set tailored to each player, a satisfying reward, simple presentation with direct usability, fast replayability, and a game with multiple skill dimensions (related words and good guessing skills really help!) make this game stand out again. We had quite a good time playing co-op too. What more can you ask?

Hi, my name is Exploration. People love me, but I can’t seem to find my mechanics. Can you help me?

Leave no stone unturned!

Elephant, meet room. Room, elephant.

Because here it is.  Based on what I just said, you could say my career in Game AI is built around a bad problem. Here’s how I see it:

1. Most of the most successful games have little to no AI
2. True AI takes years of engineering, design, and art work
3. Enemies in most games are dead within 5 seconds.   Sometimes 15 seconds.
4. … and a lot of them were scripted to do something non-AI in that period anyways.

It sure fits the description of a bad problem. But this isn’t black and white.  There are several ways that games have approached this to turn it into a good problem:

1. Many games, like Halo, have readable, memorable AI that stands out (as long as most people don’t end up only playing multiplayer)
2. Middleware and shared technology are making AIs easier to create every year.
3. You can always fake it instead.

I live in the realm of faking it.  Fake, fake, fake. And then push the designers to fake it even more.  When you’re design doesn’t really need True AIs running around and you can get work done faster another way, you can be on the beach that much faster.  Mmmm…. the beach.

Faking it here is exactly what I was referring to as coming at bad problems sideways.  Yes, as most people think of AI, AI in games is a bad problem.  That’s why we have not seen many great AI revolutions in games, despite what Chris Hecker (and I) might like.  AI is a wicked problem, but in most game designs, it’s also a bad problem. Most AIs just flat out don’t need to able to pass as a member of Facade or even The Sims. Turning it into a good problem has always been the AI engineer’s challenge, and we’ve all recognized their work in the games that have memorable characters, enemies and allies. But ultimately, the best way to turn this into a good problem for all games is through shared technology, techniques, and software.

This isn’t the topic I have been meaning to write about Chris Hecker’s talk. But it dovetails into that nicely. If the challenge is to solve this wicked problem so it becomes a good, addressable problem, then I’d like to take a few guesses at what that future would look like.

Chris Hecker coined a comparison at GDC 2008 this year, what I call Simple, Tricky, and Wicked problems.  In a similar vein I’ve coined a comparison of my own: good and bad problems.  Just as some problems are easy or hard to solve, some problems are important to solve and some aren’t.  Or rather, some problems are worth solving and some aren’t.  It was worth solving “rewinding gameplay” for Prince of Persia because it significantly improved the game.  Strict design control of hundreds of characters is a bad problem. Bad problems aren’t bad design decisions, necessarily. Rather, they are production problems that can led to more work then the problem is worth to the game.  AI Engineers run into this all the time, because a lot of AI work is concentrated on it just not looking bad.  As a team member, being able to identify where coming at a bad problem sideways or avoiding it all together is a valuable learned skill.  The more you can look at a design and identify the good problems to solve - the problems where you get a huge audience payoff vs. the problems that no one will notice the effort - the better your product will be.  I claim exponentially better.