Tuesday, November 8, 2011

What Makes Strategy Games Exciting?

The following is a rough recollection of a talk I gave at the San Francisco IGDA’s Pecha Kucha night on October 19, 2011. I don’t have a recording of the talk, so this is a composite of my notes and what I said, to the best of my memory. As a result, this piece is a bit more conversational than my typical writing style.


Pecha Kucha is a format where the speaker presents twenty slides of twenty seconds each, and the slideshow automatically advances. The challenge to the speaker is to present his or her points in a concise manner. It’s a difficult but rewarding format!


Hi, I'm Evan Jones. I work for Lolapps, where I'm a gameplay programmer on Ravenskye City and a designer on an unannounced project. Today I want to talk about strategy games - particularly the difference between what's fun and what's exciting, and the threads in common between Chess, Starcraft, and League of Legends.


There are lots of games like go that are fun and deep, but they aren't really that exciting. And I feel like there's something that separates a game like go from a game like Starcraft. I don't think it's the graphics or the sounds or the fact that one’s in real time. I think it’s in the design of the game itself. (In this talk, I’m not going to cover asymmetrical games or score-based games.)


So what do we mean when we say “exciting?” In short, drama creates excitement. And in order for drama to work, you need there to be active, sustained conflict with an uncertain outcome. Take Peggle, for example. It’s not the least bit exciting while you’re aiming a shot - it’s only when the ball is in motion, and the outcome is uncertain, that the drama happens.


So the first thing an exciting game needs is an incentive to conflict. The game has to encourage the two sides to begin fighting as quickly as possible. Why? Waiting around for something to happen is boring. What’s important is that the game itself has to provide the reason for the conflict by having a disadvantage to standing still. It can’t expect the players to charge into each other just because.

In chess, the opening moves of the game place players in direct, immediate conflict. All your good pieces start out behind a wall of pawns, so you have to move the wall forward. And you start the game close enough that you’re fighting the other player as soon as you move the pieces forward.

In Starcraft, you have to scout your opponent as quickly as possible to find out whether you’re getting rushed or not. And then you have to destroy your opponent’s scouts as quickly as possible so you can get back to building in secret. Either way? You have to build a small army immediately. This jump-starts the conflict.

In League of Legends, you’re weak in the beginning of the game and you need to gain experience to level up; otherwise you’re going to fall behind really fast. The game automatically sends units out to the middle of the map that provide experience points. So you have to go out to the middle of the map - and that’s exactly where your opponents are going to be.

An antipattern to this rule is Final Fantasy Tactics. The reason why FFT is exciting is because the AI is aggressive for no good reason. It doesn’t need to be; it just is, because threats create drama. In a multiplayer match, players play much more conservatively, and it’s less interesting.


The second thing an exciting game needs is increasing entropy of game state. In other words, the farther along the game gets, the more likely either side should be able to win. This works both ways: the player who is behind should have a higher chance of winning too the farther along the game goes. Why is this important? You want the game to end with an explosive finale, not a slow trickle - it creates more memorable endings.

In chess’s early game, the king is totally protected and both players have lots of powerful pieces. But as the game goes on, it gets harder to protect your king because you have fewer pieces to defend it. But it’s likely the other player is in the same boat, so the odds of one of you being able to set up a checkmate increases.

In an early game fight in Starcraft, both players might go into the battle with 10 units. If it’s a close fight, the winner might escape with 2 units: no big deal. But in a late game fight, where both players go in with 100 units, even if it’s a close match, an army of 20 units is enough to do serious damage, causing the end of the game.

In League of Legends, the penalties for losing a team fight increase over time. In the early game, if one team gets wiped, the other team can push a bit in their favor, but they’re still weak and the wiped team will respawn soon. In the late game, both teams are nearly godlike, and if one of them gets wiped, not only are the respawn times longer, but the surviving team is strong enough to take out the main objective without any resistance.

An antipattern to this rule is Civilization. Maybe it’s the nature of what it’s trying to mimic, but Civilization starts out in an unstable state and gets more stable over time. Near the end of the game, you really have a good idea of who has a decent shot of winning and how. It gets really difficult to change things.


The final rule is that an exciting game needs to be winnable from behind. This means that the losing player needs to be able to win without first becoming the winning player. At the moment both players know who is going to win, the drama ends, and the game becomes boring. How do you accomplish this in a game’s design? Detach your victory condition from your means of accumulating power.


This one’s so important that I’m dedicating two slides to it. Take Star Wars, for example. When it gets down to the final battle, the drama comes from the fact that both sides are getting closer to their victory conditions. By the end of it, each side is literally seconds away from winning! It would be boring if the rebels won by gradually whittling the Death Star down.

In chess, even if you’re in a really powerful position, you never feel truly safe because one check can lead to a sequence of forced moves that cost you the game. Imagine if chess’s victory conition were eliminating all of the opponent’s pieces. This is actually harder to do than capturing only the king, and intuitively one might think that more capturing equals more drama. But it’d be boring, because the drama ends long before the game does! (Try it if you don’t believe me.)

In Starcraft, there are plenty of tactics that allow players with small armies to inflict big damage. Getting invisible units before your enemy gains the ability to detect them. Building defensive cannons outside the enemy base and encroaching on their territory. The net result? Even if you have the stronger army, if you’re building up against the wrong kind of threat, you lose.

In League of Legends, the losing team can backdoor their way to victory. The backdooring player says “I’m not going to fight the enemy team; I’m just going to march into their base and destroy it before they show up.” In this way the losing team can win even while controlling less power on the field.

An antipattern to this rule is Risk. Like many games that follow a tug-of-war pattern, this game gets really boring near the end. The reason is that as both players develop a critical mass of units, neither player gets closer to winning because the cost of engagement is too high. So players have a tendency to turtle up and do fewer things.



So, thanks everyone for listening! (And thank you for reading!) Make sure to follow me on Twitter @chardish.

Tuesday, June 28, 2011

Life (Cached)

Sean Cooper recently ran a challenge at Lolapps to create the fastest version of Conway's game of life in Flash that we could. Of course, he first showed us his version which uses a convolution filter, but that's not what this challenge was about. The idea was to figure out how to make AS3 both perform and display as fast as possible. Of course I immediately found someone else's Pixel Bender version but after playing with that I went my own route to see what I could do in pure AS3.

For the impatient, you can view an animation which helps to explain the concept or jump straight to the result.

Pretty quickly, the discussion I was a part of moved towards the possibility of caching. After getting the initial naive version of Life finished, I let the caching idea bounce around in my head and finally came up with an idea. Since (basic) life has only two states per pixel, alive or dead, these map trivially to bits. Taking an arbitrary rectangle of the map and reducing it to a simple integer then is easy. Additionally, operations on this section can be done via bitshifting and bitwise operations, which tend to be extremely fast. Unfortunately, the uint in AS3 is only 32 bits long, so this limits the size of the "chunk" we can put into a single uint, but then again 2^32 would be a lot of states to possibly store and/or calculate. I also found that if I try to make a Vector. 2^30 long, Flash hangs, then crashes.

Let's assume for now that we're going to deal with Life in 3x3 cell chunks. I'll explain why later on. We'll start with a 9x9 set of cells:

A 9x9 section of cells

Then break that up into 3x3 chunks of cells.

3x3 chunks

Let's look at the center chunk:

The center chunk

The simple life rules make each cell depend on its immediate neighbors in every direction.

  • If a cell has less than 2 live neighbors it dies (or stays dead) due to loneliness.
  • If a cell has 2 live neighbors it stays as it is, dead or alive.
  • If a cell has 3 live neighbors it is alive in the next iteration (dead cells come alive, live cells stay alive).
  • If a cell has 4 or more live neighbors it dies of overcrowding.

To run these rules for a single cell we need the ring of cells around it to calculate its next state. In the same way, to calculate the next state of a 3x3 set of cells we need the ring around it, making the chunk we need to look at a 5x5 chunk of cells.

5x5

This is what ultimately limits the size of the chunks we can easily cache. 5x5 cells mean we need 25 bits to make them into a uint. 5x6 would make 30 bits and a simple array that big crashes Flash.

Now that we've established the basics of what we need it's just a matter of figuring out how to efficiently calculate, store, and retrieve the values.

We'll store the state transitions in a simple vector of uints. The index will be the current state and the value is the next state. For the current state we take the 5x5 chunk, turn the pixels into bits, then put them together to make a uint.

5x5 as bits, the top-left is the least significant bit (2^0)

= 9870129

Now we have the center chunk's current 5x5 state as a uint. 9870129 will be the index into the state transition map. Now we need the state that this will become after the rules are applied.

The next state

Note that the ring around the 3x3 chunk is all empty. Since what we're calculating for is the 3x3, that's all we care about. We needed the 5x5 to be able to say what the 3x3 became and in the result we store the uint with only the 3x3 chunk filled out.

Result bits

= 4194688

Once this is done for all of the 3x3 chunks, you run it all over again. In order to get the 5x5 you can mask out the bits needed in the neighbors, bitshift them, and bitwise-or them together to get the 5x5 uint to index back into the state transition map. To speed things up even more you can store those masked and bitshifted parts separately so all you need to do is bitwise-or them together to find out what the next state is.

If you made it this far, thanks for reading. Here again is a link to the explanatory demo, which is where the screenshots above came from.

And, finally, the result. The fastest Life implementation I've made thus far. :-) You can press 'r' to switch to another pattern (try resizing to 1440x599) and then again to get a random start state. 'p' pauses the animation. Enjoy!

Click to view the completed application

View the original post.

Tuesday, April 5, 2011

Stop Debating "Games as Art"

We ask the question "are video games art?" We ask it often, and we usually ask it so that we can immediately provide an answer to it. On first glance, it seems to be the pressing question of our medium. We tend to see it as a cry for validation, a question of quintessence, a search for deeper meaning, a desire to justify our existence, a hope for immortality.

It is none of these. The answer to the question is "yes." An explanation is not required.

Truth be told, I don't know when the games-as-art debate began in earnest. Google News shows the mainstream press beginning to discuss the issue around 2000 (no doubt the explosion of cinematically excellent games in the late 90s contributed to the interest in this topic.) Roger Ebert's public campaign against video games as art began in 2005, and his position as an eloquent student of the world's second-newest art medium certainly incensed advocates of the newest, and his ignorant cries that games can never be art brought the discussion to the forefront of the gaming public's attention. The latest salvo comes from Brian Moriarty and his GDC lecture claiming that games are not art by spending much of his time talking about things that are not games, and this, too, sparked another outrage from the gaming community. The debate has raged for many years, and none may know when it will conclude.

What I do know is that if we believe that video games are art, it is vitally important that we immediately cease discussion of this topic.

Games are art, and the sky is blue, and Austria is a country in Europe, and koalas have a vegetarian diet, and pi is the ratio of a circle's circumference to its diameter. To debate games as art is to suggest that the question is worthy of debate. It is not. The people who claim that games are not art have not played games that have spoken to them as art. Their opinions stem from a lack of experience with games. It is not our job to refute them! It is retarding to the critical development of our medium to spend our time defending its legitimacy. The worth of an experience cannot be judged by one who has not undergone it. To claim that games are not art is to judge countless experiences not experienced. To defend games as art is to say that such claims are worthwhile.

It is so very tempting to engage in this debate! I have a great amount of sympathy for those who do. After all, they are doing this because, like me, they love games and want others to love them too. They speak with eloquent words about the way that games have moved them, touched them, called them to examine their lives in different ways, asked them to think critically about topics they had taken for granted. Their words are honest, heartfelt, and true, but they will convince no one that games are art. After all, it was no one's words that convinced them that games are art - that task fell to games, and games alone.

When someone says "games are not art," what they're telling you is "I know without a doubt that there is no art in this room," and that's as ludicrous a claim as it sounds.
When someone says "games are not art," what they're telling you is "I know without a doubt that there is no art in this room," and that's as ludicrous and baseless a claim as it sounds.

Equally alluring is the desire to convince one's opponents that games are art by listing a canon of games that one believes qualify as art. This doesn't work, either, for the very reason that not everyone regards particular works of art in the same manner. Almost all works of art have their detractors, and resting the entire games-as-art issue on the shoulders of one game, or collection of games, practically invites the deconstruction of those games as a counterpoint suggesting that games are not art. Don't do it. The person who believes that games are not art has not played the right games. Neither you nor I know which games will reveal to them that games are art. I'm intentionally avoiding discussing games I feel are art and games I feel aren't, because my lists are different than yours, and I don't want to weaken my position on games as a whole by discussing specific games.

Keep making games! Keep playing them, and keep talking about them, and keep telling your friends about them. Keep sharing stories about the ones that made you laugh and cry, the ones that filled you with joy or happiness or panic or dread. Tell about the time a game made you think, or the time one made you feel a sense of true accomplishment, or the time you felt true pride in your lower-case-a-achievements. Speak about the ones that made you angry and the ones that inspired you. Lament the bad games and sing the praises of the good.

But stop acknowledging any claims that games are not art. Stop talking back to them, too. You don't have time for that. There are more good games to be played.

Evan Jones is a game programmer at Lolapps, an independent game developer in his free time, and a game design enthusiast. You can email him at his first name @lolapps.com. It would make him very happy if you followed him on Twitter @chardish.