I enjoyed taking part in the latest Three Moves Ahead Podcast, on which we discuss where the strategy genre is headed in the coming years. Needless to say, things are changing.
Really?
Well, at least it beats those Evony ads…
AI and Designers Discussion
Before my GDC panel this year, AI & Designers: Mind the Gap, we did a preliminary e-mail thread as a warm-up. For readers who couldn’t make it to the conference (or to the panel itself), our back-and-forth might give a little taste of what the discussion was like. Of course, some of the questions were only ultimately answered during the panel itself, but it’s still worth a read for developers interested in the topic.
Here’s the cleaned-up transcript:
Soren Johnson: So, GDC – and our looming panel – is about three weeks off, so I figured it might be a good idea to do some pre-panel chatting to help get our ideas rolling. My original thoughts for this panel come from my own experience as a designer and an AI programmer. Essentially, I’ve always enjoyed being able to do both jobs at the same time because there is just so much overlap between the two. If I was only an AI programmer, I feel like I would get frustrated with designs that are impossible for an AI to handle. And if I was just a designer, I would regret not having total control over how the AI performs because that is a core part of the user experience. However, most of the industry separates these two roles, and I am curious how well it works. It seems like one of the two sides would always be dominant, depending on the make-up of the particular companies and probably to the detriment to the game. So, how has this tension worked (or not) for your teams? What are the best ways to manage this process? Any horror stories from past projects? Other thoughts?
Tara Teich (AI Programmer, Double Fine): There were two areas of interest for this topic to me. The first was the issue of the different mindsets of designers and programmers. Frequently, the issues I’ve had have come into play because designers and programmers come to the table basically speaking a different language. A designer asks for feature X and the programmer goes “oh, ok, great” and goes off to implement it. The result isn’t what the designer was asking for at all! Basically, designers think of the experience of the player, programmers think of the how of implementation and they’re not always the same thing.
The second was about planning for change. A good AI programmer will know that designers are GOING to change their mind and will build space into their system for as many aspects of it to be changed or even reversed as possible. But if the programmer doesn’t do that, every new request from design results in a frustrating complete re-write of the system.
Alex Hutchinson (Creative Director, EA Montreal): My favorite part of the job is collaborating with engineers as I see the overlap between design and engineering as the heart of what makes games unique and special. I also think that it’s the path to getting more than either side could do on their own – my new way of working is basically to very clearly articulate the ‘why’ of a feature, then have no more than a couple pages where I try to work out the actual nitty gritty of the design. My goal with that is to have basically 80% of the idea clearly articulated, then I hand over ownership of the feature to the engineer, and we have regular discussions about it and eventually the goal is that they present it back to me and they’ve not only filled in the remaining 20% but added another bunch of stuff themselves, so we get more (hopefully) than if they’d done it on their own, or if I’d written down a hermetically sealed spec doc.
That said, it also relies on both sides being smart, easy to work with and fond of collaboration not dictation, so it’s based on people IMO.
Soren: Have you, or anyone on the list, experienced much with trying to put the AI parameter tweaking or simple algorithmic mods directly into the hands of the designers? It seems this would go hand-in-hand with building a flexible AI system instead of one overly specialized, like you mentioned. However, something like this was attempted in Spore before I came on-board, and we eventually ripped it out because there were just too many gotchas for the designers to trip over because the interface separating them from the code was too weak. I imagine it could work though, but I wonder if it would be worth the overhead of worrying about all the edge cases that probably will never be hit.
One question I always find interesting is whether a design idea should be judged separately from the AI’s ability to use it. Apparently, DoW2 is having issues with this as their AI doesn’t seem to be able to handle many of the special abilities available in the game that ARE still fun for the humans. With Civ, I was constantly resisting features like this – I avoided paratroops, invisible units (spies, submarines, hidden nationality units like privateers) – because I felt that the time spent on building AI to handle these special cases would be better spent on just the core AI problems. To me, it was just literally a cost/benefit tradeoff decision. However, I’m not sure if I made the right decision as players love these type of units. (and, inevitably, whatever units I cut were added by the looser expansion teams…) So, when does the plus of a player enjoying a tricky feature outweigh the minus of a hobbled AI?
Tara: One of the choices I’ve made on occasion is to just make it look “good enough.” If you have an element that is really fun in multiplayer, and your game is very multiplayer-centric, then leave that feature in, and just make it look like the AI is utilizing the feature. I’m not sure what the DoW2 issues are, I’d be interested in looking at the examples, but sometimes something is fun to the player not because it’s effective but because it’s unique. And just seeing the AIs utilizing that feature and looking like they are “having fun” with it is sufficient from a player experience POV.
In terms of Soren’s earlier question about just handing the knobs and tuning parameters to the designers, I’ve found that to yield mixed results for similar reasons that you cited. Too many knobs means they have to completely understand the underlying mechanics of the system instead of just being able to tune in the harder/easier dial that they really wanted. I found for RTS games they really liked to give input on which units the AI would build and in what order, which type of battles the AI would prefer to fight, but the specifics of how to fight that battle, which builder should create the unit etc was up to me. Fun. 😀
Adam Russell (AI Lecturer, Derby University): Sorry for the delay in responding! I too am fascinated by the complex interplay between game AI engineering and gameplay design. I agree with you Soren that it’s very difficult to separate them cleanly and that’s what makes it such a fascinating area for me. As a programmer, I loved being given the chance to influence the game design through my AI architecture even though I couldn’t pretend to be a true game designer. The key issue for me is if both “sides of the fence” are in fact contributing to the game design (for example an 80/20 split as Alex suggested), how do we reconcile or align their contributions so they’re not pulling in different directions or contradicting each other? One way of looking at that is as shares on a linear spectrum of design scale: “Designers plan down to this level of granularity, AI fills in the rest of the details.” But both AI and design must consider game-spanning features in their own different ways, so the scales sort of conflict.
Another way of looking at it that I find very appealing is if we try to make the contributions orthogonal to each other: “Designers request diverse experiences of these kinds, AI builds a systematic infrastructure that knits it together into a logical whole.” Then for me it becomes about what representations the AI should offer to design, and the AI almost becomes a foundation or a space in which the design can move. Of course, that space should ultimately be built for the design, so there is kind of a circular process here. Design lays out the themes that give rise to the AI foundations which then defines a space within which they can do design.
For me this all goes back to Tara‘s point about the disciplines speaking two different languages. It’s frustrating but good that they speak two languages, because that gives them orthogonal concerns which can coexist. But it’s an ongoing challenge to keep the experience designs anchored in the AI framework, and the AI framework driven by the need to deliver key experiences. In my view both sides must give up ownership of certain issues which are best answered by the other. AI programmers must give up the desire to reduce everything to one generic system of moving parts (because this undermines the uniqueness of the experience design), and game designers must give up the desire to control experiences down to a very high level of granularity (because this undermines the robustness of the underlying AI frameworks).
I suspect this problem is less acute in strategy genres than in my area of action-adventure character AI. It seems that strategy designers are reasonably close to the mindset of AI programmers because they think in a very holistic way about game mechanics, whereas a lot of action-adventure designers have pretensions toward recreating experiences from linear media such as film, which conflict badly with AI systems (e.g. “make it so that they always do this when the player enters the room at that moment”).
On the other hand, that similarity of mindset in the strategy genre might be a recipe for trouble, given what I said earlier about the need for orthogonality? I don’t know because I really have no development experience in the strategy genre.
Josh Mosqueira (Creative Director, Ubisoft Montreal): The DoW2 examples are, I think, legacy from the same issues we had on Company of Heroes (both games use the same tech). Ability use was something that always dogged us, so much so that for CoH we scripted all that behavior into the missions. For MP, it was tricky. When to pick it, how to use it without being too effective. In the end, we lived by a Tara’s mantra… it doesn’t need to be perfect, it just need to be good enough.
Now, whether to keep or axe a feature based on how well the AI can use it… that’s a tricky question. Speaking purely as a designer, I’ll always err on the side that having cool units and abilities like paratroopers and invisible subs add to the gameplay. I agree with Tara, as long as the AI looks “good enough” when using these units I think it’s a win-win. Then again, I take a very player-centric POV. I rather have as many cool toys as possible.
Now a question… what designer/programmer assumptions do you guys run into all the time while working on AI?
The one I do quite often is that the AI should be “hard” and punishing.
It’s an attitude I get often… that only “hard AI” is fun. I get this from designers and programmers. Whenever I say, “the player should be able to predict the AI” the reaction is “where’s the challenge in that?” To which I answer that while we may think we don’t want predictable AI, we need to give the players enough cues so that they can make “smart” decisions to beat the AI (without making them too transparent). I love Halo for this. Why do we always want to punish the player to prove our AI is smart?
This is something I spend a lot of time working on, understanding what the function the AI serves in the game. For me it has to be more than just challenge because if that was just it, then the Gombas in Mario Brothers, or the waves of Space Invaders are all we need.
I like to think that AI is our greatest tool to control the dramatic pacing of the game, but if you ask me, it’s our greatest storytelling tool. No, I am not talking AI actors but using AI to craft a proper intensity curve that has the right peaks and valleys to create an experience where the player feels like a bad ass (the peaks), and when he’s scrambling and being reactive (the valleys – which make the peaks that much sweeter).
Basically, the AI should be seen as the players’ “event coordinator” or “party planner.” In other words, it’s not the cut-scenes or powers that make a game fun, it’s the AI. AI is in charge of the player’s morale. When people talk about their game experiences, say with Half-Life 1, everyone remembers when they first time they run into the marines and how they used cover. The “oh shit” moment defined the player’s narrative of the sequence. Powerful stuff.
Maybe I feel this way because I’ve worked on too many games were the AI is brutal towards the player and it’s a knee jerk reaction. I’ve been guilty of being too hard on the player. But part of me does think that for AI to evolve we need to shift its function from being only about challenge and obstacles.
For example, take this great article on Game AI: http://www.bit-tech.net/gaming/2009/03/05/how-ai-in-games-works/1. There is nothing in there about what the role of AI in games is. Granted, the article is about “How Game AI Works” but this is something I always find I run into. We tend to focus on the details (effective use of cover, believable reactions, smartness) that we lose sight of the real intent – fun.
Which brings me to the topic of collaboration. Not being a programmer, I won’t pretend to know how best to design an AI. What I focus on is trying to convey to the programmers what the intent for the AI is, how does it add to the game experience and what things I want to be able to tune to control the intensity curve. I know that for every variable I get to tune, there are dozens of knobs that the AI programmers have to implement and tune themselves, which is why I like focusing on how the AI impacts the player’s experience. How should it react, how should it challenge the player, how does it look smart without being too smart.
Alex: Yeah, I agree with the drive toward punishment as being a big problem – often people seem to confuse AI that will ‘destroy you’ with AI that is ‘good.’
I know that Sims 3, for example, is working on a big system where AIs can form long-term goals, such as ‘own a mansion,’ then build a plan, then step through all the behaviors that lead up to that goal. So the sim will pick up the paper to get a job, go to work for X period, buy only essential goods, save their cash, get promoted by working hard, focus only on important relationships, and then eventually buy the mansion. And when you describe it to a player it sounds amazing, but the problem is it’s essentially invisible to the player – they won’t see this glorious narrative, they’ll only see a few outcomes. My argument is you could have either scripted it, or made it semi-random and to the player, it’s the same system. The AI engineers obviously argued with me on that, but unless you’re going to invest in a strong system for showing the player the plan and the execution of the plan, it’s not interesting IMO.
Similarly, in action games, engineers are arguing with me at this very moment that they should do the ‘smart’ thing, and take cover appropriately, never expose themselves, sprint to new cover when their cover is breached and what that would essentially do is remove any chance for the player to win in a fun manner. If I flank an enemy, I want him to react in shock, show me that he knows his cover is breached, and then essentially let me shoot the crap out of him. If he flees and I miss him, I am no longer having fun.
I think the essentially point for me, as Josh points out, is that AI is there to support the player experience, not to be ‘good AI’ whatever that means, in and of itself. 🙂
Josh: That’s one of the issues I have with working on AI… if the player cannot see how the AI works, then it doesn’t really matter how “smart” it is. I hear you on the cover deal, Alex, I am having the same arguments here.
As a former infantry sergeant, I know the smart thing to do is to move from cover-to-cover and use concealment. Thing is, if a player cannot “see” all that fancy leap-frogging, then it doesn’t matter. It’s just frustrating. This is why I always argue we don’t want “smart” AI, we want reactive AI. The AI needs to react to the player in a way where the player can, by mastering the game, predict the AI’s reaction and feel like a bad ass when they flank and AI position. A common thing I get is for an AI programmer to show him some cool behavior using a top-down camera, but then when I ask to see it from the game’s default POV, I have to break his heart and show him that I can’t see it so I cannot appreciate the clever cover-seeking AI.
While this is very true of action games, it’s also true for RTS games. It wasn’t until we added a ton of barks (about 20K lines) to the Squad AI system for Company of Heroes did people really start to appreciate it. Before speech went in, a common comment was “the AI looks too chaotic, not sure what they are doing.” Then when we added speech, the reaction to the same system was “Man, that’s cool, they’re covering each other and, look, that guy is trying to lay down suppressive fire.”
It’s all in making sure that the hard work that goes into AI can be appreciated by the player.
Tara: The one place where a lot of that smart cover behavior is successful is when you have friendly teammates. When you’re in the lines with them and you see them doing the leapfrog behavior, that’s great. But you’re totally right, without dialog for them to say what they’re doing, to the player it still probably wouldn’t parse well.
Soren: I definitely appreciate the limits of “hard” as opposed to “fun” AI. The thing is, they both have their place, depending on what type of game you are making. For symmetrical strategy games, the game should still be fun/challenging once players have mastered the systems. Many strategy games fall down on this front (listen to Tom Chick talk about how Empire: Total War loses interest once the player masters the mechanics here) as the challenge for the player is just learning how to juggle multiple plates, not actually engaging an AI as an equal player. On the other hand, I was painfully aware from developing Civ that we don’t want our AI playing cutthroat games like a human would (i.e. being willing to backstab the player at any time just because it suited them). It’s a tough problem, but at the very least, I think it is important that they AI be able to handle all the game options in a symmetrical setting because strategies are often good or bad only relative to the choices of your opponents. (If the AI never uses submarines, I don’t need to build any cruiser to see them.) Of course, for asymmetrical games, like most shooters, the purpose of the AI is quite different, and it is irrelevant if the AI can use all the abilities the player has.
Josh: Excellent. Controversy!
Well, not really since I agree. It’s a conundrum, especially for symmetrical games as you mention. The AI needs to be deep enough so that it provides the right challenge for your 5th, 50th and 500th game.
How do you all handle how saleable you want the AI to be? Granted, not so much an issue in action games, since most AI does not live for more than 30 seconds and you can use tuning to handle challenge, but you’re right, for strategy game this is a balancing act.
On CoH we tired (and failed) at making the AI more “efficient” and ruthless as a game went on, but that didn’t work out. It was too obvious you were playing an AI, because human opponents, even our hard-core professional players didn’t play that way.
Tara: Could you elaborate on what you mean by “efficient and ruthless” and why that was a failure?
I worked on real-time strategy AI for about 5 years, so I’m curious to hear your perspective on it. My philosophy was always to make the AI as hard as I could make it because it still wasn’t gonna be as good as a human. Then add difficulty levels that crippled it on the easier levels and give it some perks on the higher levels because making a non-cheating AI that’s better than a human… well, I don’t think we’re there yet. Partially because it makes no sense trying to encode things by writing complex AI that players figure out from intuition when we can just “cheat” and get the answer in one line of code.
Soren: Let’s phrase the issue a different way – especially in light of our specific topic of designers and programmers. What was the reason that the CoH AI ultimately failed? Was it a lack of AI resources or time? A flawed development approach? Or was there anything about the design that was out of step with what the AI programmers could reasonably accomplish? And if so, how much of the core game experience would you be willing to change if it meant a more robust and interesting AI?
It’s ok if the answer is “not much” or “that wasn’t really the issue”, but I want to take a stab at figuring out how to prevent the AI ultimately failing in future projects. How could the designers and programmers collaborated better in this case so that a better conclusion could have been reached? Or is this problem just intractable?
Alex: There’s also the secondary issue of all the other departments – as hinted in Josh’s email, I think bad animation or bad audio can also kill the AI. You could have a strong design and a great implementation, but if it isn’t communicated then it’s going to fail. In several recent focus tests (and this is more applicable to action games than strategy games), I’ve seen people say the ‘AI was bad on this level’ and the problem was actually a bad or missing animation. Players often confuse and overlap the feedback with the function.
Gaming Made Me
The writers of Rock Paper Shotgun just finished a series on what games made them gamers. For the final installment, they asked developers and other critics to contribute their own stories. I wrote one up although my examples tend to show how I became a designer, not necessarily a gamer:
Legacy of the Ancients: Although heavily influenced by the Ultima series, LotA was a lot more accessible and had an interesting twist – no experience points! A few quests rewarded the player with better attributes, and equipment of could be upgraded, but I never had to wander the wilderness gathering up XP from hapless monsters. After slogging through all of Bard’s Tale over a period of months, playing LotA was a revelation to me. The focus was on exploration and adventure, not grinding, so much so that as soon as I beat it, I sat back down and finished it again in under eight hours. I learned from LotA that we don’t need to make players “earn” their fun with camouflaged treadmills.
Seven Cities of Gold: I was a Spanish conquistador discovering the New World – except it wasn’t the Earth that we already know. Instead it was a new one, randomly generated inside my computer – different enough to surprise but similar enough to feel real. Further, the suggestive allure of my Commodore 64 spinning for multiple minutes creating new continents and mountain ranges and river valleys was immense. It was the future, and I knew it. I learned from Seven Cities that the best game content didn’t need to be hand-written.Adventure Construction Set: I finally got to make a world of my own! Too bad it’s locked away on a floppy somewhere in my parent’s basement, but the experience of building my own little game definitely made me dream of doing it for real someday. More importantly, ACS showed me the value of a data-driven design – new games could be built entirely on top of a fixed code-base. The design space was defined by which parameters could be altered, which raises an interesting question I am still trying to answer about who it the primary author of a game – the programmer who exposes the variables or the designer who fills them in?
The Stanford Lecture Slides
A couple months ago, I had the privilege of talking to a group of Stanford freshmen about the potential of games to matter, not just to a mainstream audience but to academia itself, as a medium as valuable as any other. To their credit, they asked fantastic follow-up questions, which pushed me on many of my assumptions and helped me think through my reasoning. Thus, I’m sure I could do a much better job on this topic the next time around (got to work in the ReDistricting Game, for one thing). Until then, here is the promised link to the slides if anyone wants to peruse them.
GD Column 6: Asynchronicity
The following was published in the March 2009 issue of Game Developer magazine…
One of the first things that separated video games from board, card, and parlor games was real-time interaction. The computer could handle all the details and challenges inherent in allowing two (or more) people to play the same game at the same time. Indeed, despite the name, the first multi-player video games may have had their roots more in sports than in games. Pong, after all, was inspired by table tennis. These early experiences were inherently synchronous, meaning that the players experienced the game together, at the same time, on the same machine. Since then, the synchronous format has been the default model for multi-player video games, and – with the arrival of online gaming – this same experience could be enjoyed even by people who were not necessarily in the same location.
The synchronous model is so deeply embedded in the standards and traditions of the industry – think Doom, StarCraft, Madden, EverQuest, and so on – that few designers consciously consider that synchronous play is simply a design choice. Another option exists – asynchronous play, meaning multi-player games that can be experienced in bite-sized chunks at different times for each player. The board-game world provides examples of games which can be played using this format, such as play-by-mail chess or wargames. The most successful game for this format is clearly Diplomacy, the classic game of back-stabbing, which rewards secret negotiations and hidden pacts difficult to achieve in a synchronous format. Indeed, with the appearance of the Web, a number of unofficial sites have sprung up giving players a moderated, asynchronous Diplomacy experience online.
One of the reasons Diplomacy works so well as an asynchronous game is that the turns are executed simultaneously. In other words, unlike sequential games like chess, in which players take turns performing actions, all moves in Diplomacy are done at the same time. Players submit their orders secretly to a gamemaster who then handles all interactions and conflicts according to the carefully crafted rules. This format is ideal for an asynchronous experience because all players get to make a decision every single turn. More traditional board games, from Risk and Monopoly to Carcassonne and Ticket to Ride, would slow down to a painful crawl in asynchronous play because the vast majority of turns are spent waiting for other players to make their moves. Thus, asynchronous play favors a specific style of game mechanics, ones which minimize waiting and keep players involved as much as possible.
Games for Real People
Asynchronous games hold a number of advantages over their synchronous counterparts. To begin, the time pressure of a standard turn-based game is eliminated. No more are 4 or 5 other gamers sitting around a table, waiting for the slow player to make up his mind. Instead, a player could take an hour deciding what to do without negatively impacting the flow of the game. Furthermore, asynchronous play allows multi-player gaming – still the richest, most engaging experience available – to fit the schedule of regular people with busy lives and unpredictable free time, across multiple time zones. Few adults can afford the total devotion required to participate in a five-hour, 40-man MMO raid. In contrast, an asynchronous game can allow a large group of friends to play together as long as each player can find 15 minutes per day to check the game. In Diplomacy, the English player can submit her moves in the morning, and the French can do it at night – or vice-versa – whatever works best for each one.
Indeed, the ideal online asynchronous game goes a step further than Diplomacy, which can still hang if one player neglects to send in a turn, by moving to a real-time format in which the game progresses regardless of an individual player’s specific actions. In fact, fantasy sports games follow exactly this model. Once a league is initiated, scores are tabulated each day of the season whether players log-on or not. However, the players are all full participants in their league whether they check their teams once every other week or hit the waiver wire multiple times per day. The strength of this model can clearly be seen by the astounding popularity of online fantasy leagues, with at least 30 million North American players in 2007, according to a study by the Fantasy Sports Trade Association. (In fact, a case could be made that fantasy sports are the most popular form of multi-player gaming in the world.) Players with different commitment levels can play together and still enjoy the experience – a statement which definitely cannot be made about your typical RTS.
Looking to the Web
Few good examples of asynchronous gaming exist for AAA retail video games, besides some play-by-email modes for older strategy games. For Civilization 4, we created a PitBoss (“Persistent Turn-Based Server”) option which allowed large games of up to 32 players in which players could log-on at any time to execute their turns. Combined with simultaneous movement and a 24-hour turn timer, epic games of Civilization were finally manageable thanks to the asynchronous format. One could also say that World of Warcraft‘s focus on solo content is a form of asynchronous play, in that players could finally participate in a traditional MMO without needing to juggle the logistics of managing a raid schedule or looking for a pick-up group. Furthermore, Leaderboards and Achievements are also a form of asynchronous interaction layered on top of traditional single-player or synchronous multi-player games, enabling a extra level of socialization for gamers across multiple sessions.
However, most of the innovative asynchronous games exist on the Web, a platform already built upon asynchronous interactions. Many Facebook games, like Wordscraper (née Scrabulous), manage the persistence of simple turn-based games while using the social networking aspects of Facebook to make it easier to challenge one’s friends. Games can be played between two friends over a few hours or a few months – whatever matches their level of commitment. Asynchronous MMOs exist as well, such as Mob Wars and Knighthood on Facebook or Nile Online and Travian on their own sites.
All of these games allow players to grow and develop some entity within a larger world, for prestige or challenge or the simple pleasures of levellings. In Nile Online, for example, players control a city on the banks of the Nile, each one with a unique resource, such as cedar, gold, or oil. As the cities grow, they begin trading with nearby players to acquire the resources they need – perhaps bronze for sculptures or emeralds for jewelry – or to sell their own excess goods for a profit. Eventually, players can see their cities rise in the global rankings or create great Monuments for further renown.
Meaningful Interaction?
The challenge with these asynchronous MMOs is that, while they do have some of the advantages of a multi-player environment, they tend to feel more like a less predictable single-player game. Player interaction is fairly light as most of mechanics focus simply on developing one’s own domain, without much concern for the neighbors. Allowing meaningful interaction between players is a challenge because, by definition, the system can only assume one player is logged-on at a time. If one player could wipe out another player’s city, what if the latter player is asleep? Would it be fun to wake up and discover all of one’s hard-earned progress destroyed without a chance to counter the attack?
Thus, most of the games include options to lessen the impact of other players’ actions. In Travian, for example, a player can build a Cranny which automatically protect her resources when another player ransacks the town. However, these mechanics are ultimately self-defeating; player interaction is either meaningful or it is not. If zero-sum mechanics, like resource raids, are too powerful and negate the advantages of asynchronous play – the ability to set one’s own play schedule – then the developers should focus on the parallel competition mechanics of the game instead, building a Wonder first or achieving economic dominance.
One asynchronous web-based game which tries to solves this problem while keeping meaningful zero-sum mechanics is Duels, a fantasy-themed MMO in which characters level up by fighting one another. The system is asynchronous because players do not actually need to be online when their characters fight. Instead, a warrior might challenge a wizard to a duel, which is only played out when the wizard actually accepts the challenge later that same day. The advantage is that while the conflict and interaction is meaningful, the players themselves can still play the game at whatever pace they prefer without worrying about looking for games in the lobby or rage-quitters spoiling the battles. However, the problem is that, because players can be offline when combat occurs, no meaningful decisions actually occur during the duel itself. Thus, combat is a “black box” which takes in two characters and spits out a result. If a good game should be a series of interesting decisions, Duels paints itself into a corner by taking control away from the player.
Native Asynchronous Play
Truth to be told, asynchronous games are still in their infancy from a design perspective. Their future is promising as the potential audience for asynchronous multi-player games is much great than the potential audience for synchronous ones – although anyone who can find time for synchronous games can find time for asynchronous ones, the opposite is not true. The challenge is, instead of aping mechanics from established synchronous games, finding game mechanics native to the format itself, ones which make sense only in an asynchronous world. The best example of such a game is Parking Wars, a Facebook game in which players earn money by parking for an extended period of time on another player’s street. The trick is that if a car is parked illegally, then the owner of that street can steal all the money the car had earned by handing out a parking ticket.
Thus, the best strategy is knowing what times one’s friends are less likely to be checking their streets for illegally parked cars and using that knowledge to earn money. The counter-strategy, of course, is to check one’s own street at unexpected times to catch one’s friends trying to do the same. Thus, the game cleverly uses the actual time players are off-line as the game’s content. Unlike the mechanics of the other asynchronous games mentioned previously, the rules behind Parking Wars could not work at all in a synchronous environment. Designers of future asynchronous games should follow this precedent – the time has come to stop retrofitting synchronous mechanics into an asynchronous shell and to find the format’s native voice.
Great Trip Interview
GameSetWatch recently posted an interview with the always interesting Trip Hawkins, founder of EA, 3DO, and Digital Chocolate. Here’s a good quote on the difference between the core gamer (who buys PC/console games) and the social gamer (who plays Web/Facebook games):
I think the hardcore gamer wants to pay for the game, and if they can, they like to pay for it once. And then they want the game to be really deep, really immersive. They want to play it for hours and hours, and they want to really master it.
And if they happen to be playing with other people, they want to beat them. They want to compete, and they need to win. I think for that hardcore gamer — and of course, I am one — for me that part of gaming has always been about wanting to prove that I’m competent. You know, I don’t want somebody to beat me because they spend more money on virtual items, right?
And also, I don’t want to feel like I’m stupid, so I don’t want to pay every month. I think I should be able to buy the game and just play it once, you know? Switch to this omni gamer, somebody that’s really not that competitive about it. They don’t have the time to spend a lot of time on a particular game. They don’t want to be overwhelmed about it.
They kind of like it to be free. They’re much more interested in the potential social connections they’re making with other people. And when they make those social connections, they don’t want to have somebody come in and crush them that’s viciously competitive.
They want to have it be a much more casual experience. And that is the audience that’s more likely to pay for the virtual items when they decide that the items give them style or allow them to be more competitive without having to make the time investment.
Of course, that’s something that really irritates the [World Of] Warcraft customer, and that’s why it’s such a battle for Blizzard, trying to figure out, “Well, what do we do about the fact that Warcraft is so successful. We’re attracting this more mainstream audience that doesn’t want to spend all the hours doing gold farming in the game. They want to just go buy some gold and get on with it.
The Case for Piracy
Ha-ha, just kidding. I’m not going to be arguing for piracy, but I do want to make one observation about how our industry is dealing with this issue. Some commentators have been talking recently about the massive piracy afflicting the launch of Demigod. According to Stardock’s Brad Wardell, of the 140,000 connections to the main server during the game’s first week, only 18,000 were by legitimate customers. This ratio compares favorably (or is that unfavorably?) with the 90% piracy rate reported by the developers of World of Goo. I don’t want to comment on the viability of various DRM schemes, but – needless to say – unless a game is server-based (WoW, EVE, EverQuest), piracy is a bracing reality for game developers. However, I have an unscientific theory about the root of the problem:
For any given game, only around 10% of players are ever willing to purchase an original retail product.
Obviously, this proposition holds up for PC gaming, but I believe the same is true for console gaming (housemates sharing a copy, renting from Blockbuster over a weekend, friends loaning each other games, grabbing a cheap used copy from Gamestop) and even board games (one gamer buying a copy for a group of friends). This reality is immutable – if DRM was perfect, the percentage would go up somewhat, but it would never come anywhere near 100%. Too many games exist for consumers to afford even a small percentage of them, and – more importantly – players’ individual interests in a specific game are always on a continuum. People on one extreme found a website about their favorite game while gamers on the other end might play it only once on a random Tuesday night at a friend’s house.
The interesting thing about this percentage is that it mirrors another important percentage – the number of players willing to pay money on so-called free-to-play game usually hovers near 5-10%. (RuneScape, a F2P example on the higher-end, has reported figures around 12%.) The important thing about the free-to-play movement is that the business model turns the theory I posited above into a founding principle. In fact, the smartest F2P games use a dual-currency system so that the 5-10% cash-rich players can subsidize the time-rich ones. Ultimately, this model works because a place exists for everyone on the continuum, from gamers who just want to dip a toe to ones willing to drop thousands on microtransactions. Launching a traditional retail game and hoping to change your “piracy conversion” rate is fighting the current; launching a free-to-play game built from the start with multiple levels of player commitment is sailing with the current.
Christopher Tin Inteview
Here’s a good interview with my friend Chris where he talks about his experience with Civ4‘ s Baba Yetu and his upcoming album, Calling All Dawns. Must have been fun to record in Abbey Road! Here’s a good quote:
Liontamer: You’ve actually been to Video Games Live performances at both the Hollywood Bowl in LA and The Kennedy Center in DC. How often have you able to attend shows within the tour? As part of the regular composer meet-and-greets there, do you have any memorable stories of meeting with fans or fellow composers?
Chris: I try to attend the California ones; the only exception is the Kennedy Center show, which I thought was too good of an opportunity to pass up. On the whole, though, I don’t have a lot of time to be going to a lot of the concerts. As for stories from the Meet And Greets, my favorite is when I was sitting between my friend Soren Johnson (designer for Civ IV, currently on Spore) and Will Littlejohn (Guitar Hero). Will turned to us and said, “Hey guys, we just wanted you to know that while we were working on Guitar Hero, during all our lunch breaks we would play Civ IV.” To which Soren replied: “That’s funny, because during all our breaks on Civ, we would all play Guitar Hero!” That was a great little moment, and I think it speaks well to our close-knit community.
GD Column 5: Sid’s Rules
The following was published in the January 2009 issue of Game Developer magazine…
Most game developers are familiar with Sid’s dictum that “a good game is a series of interesting choices.” In fact, my co-columnist Damion Schubert started his recent article on player choice (October 2008) by referencing this famous quote. However, over the course of his career, Sid has developed a few other general rules of game design, which I heard him discuss many times during my seven years (2000-2007) at his studio, Firaxis Games. As these insights are quite practical lessons for designers, they are also worthy of discussion.
Double it or Cut it by Half
Good games can rarely be created in a vacuum, which is why many designers advocate an iterative design process, during which a simple prototype of the game is built very early and then iterated on repeatedly until the game becomes a shippable product. Sid called this process “finding the fun,” and the probability of success is often directly related to the number of times a team can turn the crank on the loop of developing an idea, play-testing the results, and then adjusting based on feedback. As the number of times a team can go through this cycle is finite, developers should not waste time with small changes. Instead, when making gameplay adjustments, developers should aim for significant changes that will provoke a tangible response.
If a unit seems too weak, don’t lower its cost by 5%; instead, double its strength. If players feel overwhelmed by too many upgrades, try removing half of them. In the original Civilization, the gameplay kept slowing down to a painful crawl, which Sid solved by shrinking the map in half. The point is not that the new values are likely to be correct – the goal is to stake out more design territory with each successive iteration.
Imagine the design space of a new game to be an undiscovered world. The designers may have a vague notion of what exists beyond the horizon, but without experimentation and testing, these assumptions remain purely theoretically. Thus, each radical change opens up a new piece of land for the team to consider before settling down for the final product.
One Good Game is Better than Two Great Ones
Sid liked to call this one the “Covert Action Rule,” a reference to a not-altogether-successful spy game he made in the early ’90s:
The mistake I made was actually having two games competing with each other. There was an action game where you break into a building and do all sorts of picking up clues and things like that, and then there was the story which involved a plot where you had to figure out who the mastermind was and what cities they were in, and it was an involved mystery-type plot. Individually, each part could have been a good game. Together, they fought with each other. You would have this mystery that you were trying to solve, then you would be facing this action sequence, and you’d do this cool action thing, and you’d get out of the building, and you’d say, “What was the mystery I was trying to solve?” Covert Action integrated a story and action poorly because the action was actually too intense – you’d spend ten minutes or so of real time in a mission, and by the time you got out, you had no idea of what was going on in the world.
In other words, even though both sections of the game were fun on their own, their co-existence ruined the experience because the player could not focus her attention on one or the other. This rule points to a larger issue, which is that all design choices only have value in relation to one another, each coming with their own set of cost/benefit trade-offs. Choosing to make a strategic game also means choosing not to make a tactical one. Thus, an idea may be “fun” on its own but still not make the game better if it distracts the player from the target experience. Indeed, this rule is clearly the reason why the Civ franchise has never dabbled with in-depth, tactical battles every time combat occurs.
However, sometimes multiple games can co-exist in harmony with each other. Sid’s own Pirates! is an example of a successful game built out of a collection of fighting, sailing, and dancing mini-games. However, these experiences were always very short – a few minutes at the most – leaving the primary focus on the meta-game of role-playing a pirate. Each short challenge was a tiny step along a more important larger path, of plundering all Spanish cities or rescuing your long-lost relatives.
Another example of a successful mix of separate sub-games is X-Com, which combined a tactical, turn-based, squad-level combat game with a strategic, real-time, resource-management game. As with Pirates!, what makes X-Com work is that the game chose a focus – in this case, the compelling tactical battles between your marines and the invading aliens. The high-level, strategic meta-game exists only to provide a loose framework in which these battles – which could take as long as a half hour each – actually matter. One doesn’t fight the aliens to get to manage resources later; instead, one manages resources to get to perform better – and have more fun – in future battles.
Do your Research after the Game is Done
Many of the most successful games of all time – SimCity, Grand Theft Auto, Civilization, Rollercoaster Tycoon, The Sims – have real-world themes, which broadens their potential audience by building the gameplay around concepts familiar to everyone. However, creating a game about a real topic can lead to a natural but dangerous tendency to cram the product full of bits of trivia and obscure knowledge to show off the amount of research the designer has done. This tendency spoils the very reason why real-world themes are so valuable – that players come to the game with all the knowledge they already need. Everybody knows that gunpowder is good for a strong military, that police stations reduce crime, and that carjacking is very illegal. As Sid puts it, “the player shouldn’t have to read the same books the designer has read in order to be able to play.”
Games still have great potential to educate, just not in the ways that many educators expect. While designers should still be careful not to include anything factually incorrect, the value of an interactive experience is the interplay of simple concepts, not the inclusion of numerous facts and figures. Many remember that the world’s earliest civilizations sprang up along river valleys – the Nile, the Tigris/Euphrates, the Indus – but nothing gets that concept across as effectively as a few simple rules in Civilization governing which tiles produce the most food during the early stages of agriculture. Furthermore, once the core work is done, research can be a very valuable way to flesh out a game’s depth, perhaps with historical scenarios, flavor text, or graphical details. Just remember that learning a new game is an intimidating experience, so don’t throw away the advantages of an approachable topic by expecting the player to already know all the details when the game starts.
The Player Should Have the Fun, not the Designer or the Computer
Creating story-based games can be an intoxicating experience for designers, many of whom go overboard with turgid back stories full of proper nouns, rarely-used consonants, and apostrophes. Furthermore, games based on complex, detailed simulations can be especially opaque if the mysterious inner workings of the algorithmic model remain hidden from view. As Sid liked to say, with these games, either the designer or the computer was the one having the fun, not the player.
For example, during the development of Civilization 4, we experimented with government types that gave significant productivity bonuses but also took away the player’s ability to pick which technologies were researched, what buildings were constructed, and which units were trained, relying instead on a hidden, internal model to simulate what the county’s people would choose on their own. The algorithms were, of course, very fun to construct and interesting to discuss outside of the game. The players, however, felt left behind – the computer was having all the fun – so we cut the feature.
Further, games require not just meaningful choices but also meaningful communication to feel right. Giving players decisions that have consequence but which they cannot understand is no fun. Role-playing games commonly fail at making this connection, such as when players are required to choose classes or skills when “rolling” a character before experiencing even a few seconds of genuine gameplay. How are players supposed to decide between being a Barbarian, a Fighter, or a Paladin before understanding how combat actually works and how each attribute performs in practice? Choice is only interesting when it is both impactful and informed.
Thus, in Sid’s words, the player must “always be the star.” As designers, we need to be the player’s greatest advocate during a game’s development, always considering carefully how design decisions affect both the player’s agency in the world and his understanding of the underlying mechanics.