Dominion's balance

Chapel

One of the cards in the Dominion base set is considered slightly better than most: the Chapel. Some simply say This is the best card in the game.. Others suggest that Chapel is very overpowered and should cost more. Vaccarino, Dominion's designer, is quite present on board game forums, and has stepped up to answer players' suggestions. Surprisingly, he admitted himself that Chapel is the most powerful Dominion card relative to its cost. This is the occasion to glean interesting tidbits about game balance!

First, since both players can buy the same cards, poorly balanced cards don't make the game unfair, [...] but they do make the game worse. It seems that as long as an unbalanced card makes the game fun, it should stay (and probably be tweaked).

Let's start with adjusting the cost. If Chapel cost more, it would be much weaker, and would not be used at all. This would reduce the number of options available in the game. Since it's more fun to have more options, increasing the cost is not a good solution. Ideally, everything gets played sometimes, and the only weak cards are those that are overrated. That is why to keep the metagame and discussion interesting, Vaccarino would rather avoid commenting himself.

This does not mean that overpowered cards are better than underpowered cards: if a card is so strong it is unavoidable, then cards that do not combo well with it will never be played, which is a waste. When using Chapel, a lot is left up to you. This provides a lot of diverse game play, which means Chapel has a strong play value, and the game benefits from it overall. As they progress, players learn using Chapel in new ways, which is a long-term rewarding experience:

1. why would I ever buy this when Witch isn't out?
2. trash your Estates with it and just have one dead card instead of three
3. trash your coppers [and estates] with it, and get a thin deck
4. is Chapel / Militia better so I can hurt other Chapel decks, or should I go Chapel / Spy to ensure trashing 4 cards
5. Chapel / Throne Room / Remodel

Another player suggested nerfing Chapel from trashing 4 cards to only 3 cards. Vaccarino seems to agree: in general, overpowered or underpowered cards can only be fixed by changing what the card does, not by changing their cost. But during playtesting, Chapel with "trash up to 3" was way slower than trashing up to 4, and Vaccarino couldn't win with it.

And this is how Chapel stayed at trashing up to 4 cards for a cost of 2 coins.

Playtesting

The play space of Dominion is quite big: there are around 10^15 possible combinations of 10 cards among the 157 available as of 2012. Therefore not all combinations of cards can be checked during playtesting. Since games get played way more than they get playtested, there may be some card combos that go unchecked until release. If a single card is overpowered, it is quite easy to spot and will be fixed. Two-card combos happen more rarely, so if one of them is overpowered, it may not be spotted as easily, but will also matter less. As for overpowered three-card combos, the Dominion developers aren't necessarily finding them. But if one happens during a game, and a player figures it out, it is highly unlikely that the player will face these three cards again in another game.

Playtesting can also reveal interesting/core design ideas. For example, Vaccarino was worried that drawing your whole deck would be bad. Soon [he] realized it was in fact fun.

The deck-building card game genre

Dominion ripoffs or deck-building card games?

Here is a quick list of games that resemble Dominion in some ways.

Year	Name	Theme	Description
2007	Race for the Galaxy	Space and planet exploration	Deck-building, but does not rely as much on engines as Dominion or Magic do. There are no interactions between players (no stealing cards or throwing dead cards in the deck of others).
2008	Dominion	medieval	Some interactions between players. Solid engine/combo mechanics.
2009	Thunderstone	dungeon-exploration, medieval fantasy	Cards include medieval fantasy heroes, items, locations, or monsters. With the adequate items, heroes can kill monsters and level up (ie card upgrade), making it easier to progress through the dungeon. For some, This is like Dominion, only even more fun.
2009	Tanto Cuore	cutesy Japanese maids	The art borders on ecchi and may offend prude people. Design-wise, each player can place maids in their private quarter to trim their deck, but in doing so, they expose themselves to attacks from other players. The game also features private maids giving special powers every turn. Some Dominion players consider the game refreshingly different, but compared to Dominion, not as much effort was put into balancing [and] playtesting.
2010	Puzzle Strike	relatively abstract: breaking gems	Seems less inspired by Dominion than Tanto Cuore or Thunderstone are. Tokens have replaced cards: tokens can be bought and sent in an opaque bag to draw from, rather than an actual card deck. Heavily PvP-oriented: players throw gems in front of each other, and when 10 gems have been placed in front of a player, s/he loses.
2010	Ascension	dark fantasy	System of two currencies (rune and power). Victory points are kept visible on the mat. Some players have reported that synergy is more a mater of luck than anything.
2011	Quarriors	medieval fantasy	Inspired by Dominion and maybe by Puzzle Strike as well. Instead of cards, players buy dices, and instead of a deck, players use an opaque bag to draw dices from. The base game seems to have been popular enough to be followed by 4 expansions and a bunch of promo cards.
2011	Nightfall	vampires and werewolves	Cards can be chained by color and between players, not just during a player's turn. Players throw wounds at each other, the equivalent of Dominion curses in that they clog the victim's deck, but they also determine the winner (the player with fewer wounds win).
2011	Battle of Gundabad	Orc warriors, suitable for 12 year-olds?	A $2 iPhone game considered a blatant ripoff of Dominion because the cards are exactly the same, just named differently (e.g. BoG's Paralyze is Dominion's Cutpurse, Warmongering is Laboratory, etc.). Each level of the campaign mode features a particular set of cards to teach a particular combo to the player. Yet the game does not feel very polished. The lack of deck-building card game for iOS made some realize that BoG stepped in to fill the void and could maybe persuade someone to pick up the Dominion license and put out a licensed, polished product. And indeed, the current official Dominion iPhone app features a campaign mode. Thanks BoG?

Lessons learned about innovative mechanics:
Given this small list of deck-building games, Dominion clearly pioneered the deck-building card game genre. Even though it seems difficult to draw the line between a ripoff and an original game of this new genre, each game brought something new to the table. I only wish designers tried to explore this vast and uncharted design space more aggressively, rather than keeping 80% of Dominion and branching from there.

Lessons learned about the themes:
As Tom Vasel says, apparently most deck-building games [...] have to be fantasy-themed. While the deck-building mechanics are great, the medieval/medieval-fantasy theme is dull and lifeless. It may be that deck-building designers go for a medieval theme to avoid frustrating MtG/geek players, their target audience. Some hardcore nerds may still be in love with medieval/medieval-fantasy themes, but I think a lot of non-gamers find the medieval theme trite and/or associate it with nerds. Thus some non-gamers may be more reluctant to try Dominion, Thunderstone, or Ascension than, say, Bang!. Deck-building card games need more original themes like Tanto Cuore's maids, or they will remain like MtG, an amazing game stuck in a nerd niche.

Copyrights and publishers

In June 2011, Dominion's designer, Vaccarino, reported that Rio Grande Games (RGG), the publisher of Dominion, had asked a contractor, Goko, to develop and run an online version of the game for mobile phones and web browsers. And of course, Goko wants the free isotropic Dominion server to shut its doors before they launch their product.

Goko's Dominion launched in August 2012, but technical problems caused the Goko game platform to close its doors and go back to beta. As of December 2012, Goko is back online, out of beta. The Goko version has a nicer UI than isotropic, but does not seem to provide the expert features isotropic offers (e.g. game logs). Also, one can play Dominion on Goko for free using the basic set, but expansions must be purchased with real money. Isotropic is still up and running.

Lessons learned: an online version of Dominion should have been released as soon as possible. Ideally, RGG could have determined Dominion was a hit before or around the release of the first expansion, by mid 2009. But RGG had other priorities (non-digital board games!), and as they kept waiting, people 1) bought an unpolished iPhone clone (BoG), and/or 2) felt more and more entitled to play Dominion for free. Board game publishers really need to start considering digital publishing up front and more seriously. There is a demand for it!

Dominion's ecosystem

Without going into too many details, Dominion is a medieval-themed deck-building card game designed by Donald Vaccarino. The base set was released in 2008 and received a bunch of awards. A total of 8 expansions have been following, released every 6 months. Most of the cards of the 8 expansions were already designed and bundled in sets since 2008.

In Dominion, the optimal strategy depends on which cards are already in your deck, what the other players do, what cards are available to add to your deck, and a small amount of (somewhat controllable) luck. The game has been so carefully tuned and playtested that some reviewers consider it too safe and overbalanced, overdesigned and overdeveloped. Dominion's balance is so interesting that it deserves an article in itself.

Looking at the complex interactions between cards, Dominion reminds of Magic the Gathering. For example, expert players talk about engines, a concept similar to Magic's deck types, but (I'd say) deeper. In fact, the MtG analogy is not surprising, given that Vaccarino is a veteran MtG player who pitched several design ideas to the MtG designers in the late 1990s.

After having played around 100 games, Dominion also reminds of Chess: it has traditional openings, annotated games, and a vocabulary very game-specific (e.g. greening or stalling). Dominion is a very deep game.

Expansions

Of the 8 Dominion expansions, some have been received more favorably than others. For example, Alchemy is the third expansion. It adds potions, a new currency, and not too many people enjoy playing just Alchemy games. On the other, the fourth expansion is called Prosperity, and it adds a lot of over-the-top cards: compare, for example, Market from the basic game to Grand Market in Prosperity. This expansion is certainly the most well-received.

The lesson here seems to be: make more awesome versions of what exists already, and adding extra currencies like Potions makes the game more complicated, but not necessarily more fun.

Dominion's unofficial ecosystem

A lot of unofficial projects emerged around Dominion. For example, a card set constructor helps you determine which cards to pick for your non-digital game(s) with friends. An AI simulator enables experts to polish their strategies by scripting basic AIs and running thousands of games between those AIs. The AI is provided from external files, and the returned graphs plot the average number of points earned per turn against the number of turns. As an example, this technique was used on the basic set of the first Dominion. There are also fan-made expansions, a zombie retheme, and a stand-alone program to play Dominion by yourself against AIs.

Since at least 2010, an online server called isotropic has been running Dominion games online. Its interface is very simple, and a lot of players have been enjoying the fact that it is free and of relatively good quality. Vaccarino has even been using it to playtest his expansions with select players. Along isotropic, there used to be councilroom, a website used to measure various statistics about Dominion cards from isotropic game logs. A lot of expert players seem to have enjoyed the stats reported by councilroom. And there used to be a free iPhone app that allowed people to play Dominion online with other people, but it was discontinued in April 2012.

Dominion generated dozens of projects run by motivated fans. How could a game publisher channel these fans? And how much control should be exerted?

Game modes and MVC, part 2/2

This article follows a high-level architecture overview of two pygame projects. In this article, I show why it is difficult to engineer a game in modes when following MVC, and suggest two ways of solving the problem, detailing their pros and cons.

MVC and modes: cross-cutting concerns

-	Menu mode	Game mode
Models	None	World, Inventory
Views	MenuWidget	WorldRenderer, HUD
Controllers	MenuController	CameraController, HUDController

MVC vs modes

In the previous article, I showed two veteran pygame developers using two different techniques to implement modes in their game. Shandy Brown uses a main controller (view) that relays events to its sub-controller(s) (sub-view(s)), so that when the mode changes, only the sub-components inside the main controller (view) change. The event manager is still sending events to the same main controller (view). This approach starts with MVC as a basis, but mode switching has to be implemented in both the controller, the view, and possibly even in the model. In short, the logic for switching between modes is scattered in each of the MVC components. This is called a cross-cutting concern.

On the other hand, Joe Wreschnig first assumes a state machine to handle the game modes. Then, in each mode, there may be an MVC. This is just another way of looking at the previous cross-cutting concern: each mode has to implement an MVC. There is an easy object-oriented answer: a Mode abstract class, with a list of models, views, and controllers as attributes, such that when a mode is created, it directly starts with an MVC structure. But now we have coupled the mode logic to the MVC logic, and this tangling is typical of cross-cutting concerns.

And this is how we end up with two ways to look at the same problem: either per MVC component (horizontally in the table nearby), or per mode (vertically in the table).

Any silver bullet?

I'm not completely sure, but I think object-oriented programming can not solve this problem by itself. Aspect-oriented programming aims at answering those problems, and there are some aspect libraries in Python. However, some Python programmers argue that Python is a dynamic language with powerful introspection mechanisms, and this allows for decorators and monkey patching to do the work just fine. I have not tried any of these solutions (although decorators seem quite interesting). Rather, I want to keep my code simple and readable, and I try to mix the previous two approaches in one, aware that there is no silver bullet. Let us look at the pros and cons of each approach.

The first approach involves a central event manager, main model, main view, and main controller. The single event manager makes debugging relatively easy, since all events have to go through a central point. However, since the main view and the main controller forward messages to their sub-components, there is no single point of control in a given mode anymore. There is another advantage of keeping the MVC at a higher level than the mode management: the view implementation can switch at any time in development from pygame to pyglet or panda3d.

There are also disadvantages. The first happens in an event manager with pubsub: let's say the HUD widgets in the view subscribe to the main view for ScoreUpdateEvent. The main view itself must subscribe to ScoreUpdateEvent from the central event manager. When the view changes mode, it should unsubscribe from ScoreUpdateEvent from the event manager, but should still subscribe to tick events. This means unsubscribing happens per event, and not per component. Thus, the view should memorize which events it subscribed to in the previous mode, and unsubscribe from each of them. This is awkward. Another architectural problem shows up when, say, a model component tries to create a controller component. The new controller component will have to subscribe to the model event broker. This is bad: there is a now controller in the model.

In the second approach, the mode state machine is central, and each mode implements its own event manager and MVC. Unlike the first approach, there is a single entity managing mode transitions, which is a good point. Another advantage is that sub-components do not need to unsubscribe from the central event manager: they stay subscribed to their mode's event manager until the mode is killed. But this has the drawback that the mode state machine must subscribe to each mode's event manager to be able to receive events for mode switching. Moreover, each mode now has its own model. For simple menu modes, there is no model, so it's not a big problem. But the config menu may change some values that the game may need to know about. It seems that data can be exchanged between modes only through 1) events, 2) init arguments, or 3) config files. A last disadvantage is the fact that there is no central place where the view is: each mode has a view, so switching from pygame to pyglet will require updating all the modes.

Conclusion

After giving a try to the first approach, I did not like having to unsubscribe to the event manager. So I went with the second approach: each mode has its own event manager and clock. I think that each mode having its own context is actually a good thing: a game instance should not need anything that is not in a config file or too big to fit as an argument or attribute of an event. For example, if the character selection mode returns the character name as a string, it passes it as an attribute of a GameStartEvent, so that the game instance can determine which character to play with. And finally, to fix the problem of changing from pygame to pyglet, my views exist in their own files, not with the mode's controller or model.

Links

• Using a stack for managing game states
• More on screen stacks
• Shandy Brown's MVC tutorial
• Joe Wreschnig's Angry Drunken Dwarves
• AOP libraries for python
• Python code for a view brokering events to its sub-components

Game modes and MVC, part 1/2

Following a previous article about MVC and event managers, I look at how two veteran pygame developers are using MVC and/or event managers, in particular with respect to switching between modes (e.g. menu vs game vs config).

Example 1: Fool The Bar

In Fool The Bar, an MVC tutorial by Shandy Brown last updated in 2011, a central event manager publishes all the events it receives to the model, the main controller, and the main view. There is a pub/sub in place, but all components subscribing to the event manager receive all the events. The GameStartRequest event is used to switch from the main menu mode to the game mode.

The main controller subscribes to the event manager for all events, and forwards all of them, except the events like GameStartRequest that cause mode changes, to its single current subcontroller. Thus the subcontroller does not subscribe to the event manager, but only publishes to it. And when a GameStartRequest event is fired, the main controller switches its subcontroller from SimpleGUIController for the menu, to MainBarScreenController for the game.

Each subcontroller has its own input mapping. When the SimpleGUIController is active, if the user pushes the DOWN arrow key, the controller fires a GUIFocusNextWidgetEvent. When the MainBarScreenController is active, in game mode, pushing the DOWN arrow key does not fire any event.

Similarly, when the main view receives a GameStartRequest from the event manager, it switches from the menu mode to the game mode. But when the main controller has only one subcontroller active at a time, the main view can have multiple subviews active for one mode. For example, the game mode requires both the MainBarScreen (where the game is displayed) and the MainGUIView (where the HUD with score and possible actions is displayed) to be active at the same time. Thus the main view acts as an event manager for its subviews: subviews subscribe to the main view, and the main view relays events from the event manager to its current subviews. When the mode changes, the main view kills all its current subviews, and instantiates the new subviews.

Example 2: Angry Drunken Dwarves

Angry Drunken Dwarves is a 2004 falling-block puzzle game by Joe Wreschnig. It does not really follow MVC: instead of having distinct models, views, and controllers, modes simply stack up on top of each other. For example, when the player pushes the "Play a game" button, the button's callback stacks the character select mode on top of the main menu mode. When the player has selected a character, the character select mode returns with the selected character, and the callback starts the game mode, passing the character in argument.

Each mode instantiates its own event manager, but unlike Fool The Bar, the event manager is directly polling pygame.events for keyboard or click events. When a component decides that the previous mode should be brought back, such as when the game is over and the main menu should be brought back, that component sends a QuitEvent to pygame.events.

Balance of Power - Crawford 1986

Notes from Balance of Power, a book by Chris Crawford published in 1986.

Games vs simulations

Games differ from simulations in three ways. First, games carry an artistic message, with unquantifiable concepts and feelings. Second, games simplify reality: they only keep the conflicts inherent in the situation, and unlike in real life, they provide clear and emotionally satisfying resolutions to those conflicts. Yet games maintain a level of realism appropriate to the audience. Finally, games are accessible; there is no need to study the manual.

Balance of power, in short

The player controls one of the two superpowers, the USA or the USSR, during the Cold War. Each turn, both superpowers send money, weapons, troops, or diplomatic pressure onto other countries to trigger insurgencies, coups d'etat, or Finlandization favorable to them. For example, the USSR can send money to Cuba.

If a superpower contest the actions taken by the other superpower, then a crisis testing the player's brinksmanship follows. Either the player stands firm on its ground (whether s/he was contesting or not), and brings the crisis one DEFCON level higher, ie one step closer to World War III and a nuclear holocaust, or s/he pulls back. For example, think about the Cuba missile crisis of 1962.

When a superpower stands firm and wins the crisis, it gains prestige points. A minor country such as Nicaragua is worth 2 points, while a country like East Germany is worth 200 points. The further down in a crisis a superpower backs down, the more it loses prestige. When the highest DEFCON level is reached, the game is lost for both players.

The game ends after eight turns. The superpower with most prestige points win.

Balance of insurgencies

Insurgencies consist of rebels trying to take over the government of a minor country. The strength of any armed faction is measured from its number of soldiers and its number of weapons. If 100 government forces share 1 weapon, then the government's power should be low, and a superpower providing a couple weapons would really increase its strength. Similarly, 1 government force with 100 weapons should be weak. Thus, the strength of an armed faction is the harmonic mean of the number of soldiers and the number of weapons. It is optimal when each soldier has a weapon.

Balance of crises

Nastiness is a game-wide variable; it describes how slippery taking actions in the world has become. When nastiness is high, the AI is more likely to contest the player's actions, start crises, and refuse to back down. Nastiness increases after each crisis or military intervention of a superpower, and decreases slowly every turn.

Pugnacity is a superpower variable; it describes how trustworthy the superpower is considered by minor countries. Pugnacity increases when the superpower is aggressive and wins crises, and decreases when a superpower backs down in crises. If a superpower backs down late in a crisis, it loses a lot of pugnacity.

Combined, nastiness and pugnacity amplify the amplitude of missteps; an error in judgement can cause the end of the game. This is exactly what Crawford was trying to convey about brinksmanship.

Event managers and MVC - part 2

I wrote about MVC and event managers in January. Here's more!

Ordering of tick events in the game loop

A traditional game loop follows roughly this pattern:

• process inputs on model (keyboard, mouse, network rcv)
• process tick on model (update each entity and the world)
• tick the renderers (graphics, sound, network send)
• eventually wait for next frame, and repeat

Problem: Let's start with a simple event manager that does not make any difference between the inputs, models, or renderers. In other words, the event manager has no clue about MVC. Then, two annoying things happen. First, and most importantly, the event manager could publish a tick event generated by the clock to the model first, to the controllers second, and to the views last. It's as if we were running a different loop: tick the model, process inputs, and render. Since inputs need a whole frame to be processed on the model, the controls may feel laggy to the player (33ms lag at 30 FPS). This is terrible in twitch games like FPS or fighting games. Second, the dispatching of events could be non-deterministic: in one frame, controllers are ticked first, while in another, models are ticked first. The lag to process player commands would be random, and they may not be able to adapt to it.

Solution: We need an event manager that follows the game loop described above. Poll the controllers first, and send the events they generate right away on the model, views, or other controllers that subscribed to those events. Then tick the model and publish any resulting events right away. And finally, send the tick event to the views.

Implementation: the original simple event manager had a dictionary mapping each event type to a list of callbacks. The simple event manager was not differentiating between tick events and other events. Now, we need to distinguish between tick and non-tick events. And for tick events, we must distinguish between controllers, models, and views. This results in a set of controller callbacks, another set of model callbacks, and a third set of view callbacks for the tick events, and the usual dictionary mapping each non-tick event type to a list of callbacks.

Events that generate new subscribers

Problem: We're sending a tick event to the model. The model happens to create a new creature in the game. Let's say that the data of this creature needs to be updated every simulation step, so it should subscribe to the tick event as a model. However, the event manager is currently iterating on the set of model entities currently subscribed to be ticked. And in Python, when a set is iterated on, it can not be modified. I'm also guessing that lockless sets do not belong to the standard library of most programming languages, so this problem may not be unique to Python.

Solution 1: Before starting to process the tick event on the models, make an empty set. This set will store the callbacks of each model entity that started to subscribe to the tick event during this current frame. So we call this set new_callbacks. Our newly-created creature will be put in that set by the event manager when it subscribes to the tick event. When the event manager has finished iterating on the usual set of model entities, it makes a copy of new_callbacks, and replaces new_callbacks by an empty set. Then, the event manager iterates on the copy set, ie our new creature. If the creature spawns 3 minions at the first tick of its existence, the event manager will store the 3 callbacks from the minions in new_callbacks. Then, when the event manager is done with processing the copy, it adds the copy's callbacks to the usual set. Then, it replaces the copy by new_callbacks, and ticks the 3 minions. This can go on until both new_callbacks and the copy set are empty. Then, all old and new models have been ticked. Below is the output I'm expecting:

Created controller
Created model
Created view
---- Clock tick 0
Ticked controller
Ticked model
Created boss
Ticked boss
Created minion
Ticked view

The code does not exactly output this: the view is ticked before the boss is created. Oh well ... :-)

Solution 2: Solution 1 involves 3 sets and is quite convoluted, but there is simpler (and more dangerous!): using a data structure that is not locked when iterated on. In Python, this means using a list instead of a set. However, it's not the perfect data structure for the job: if an entity happens to subscribe twice to an event, the entity will receive the event twice. Most likely, your entities only need to be ticked once per frame, so if a bug causes an entity to act twice faster than expected, you'll know where it might come from. That's why modifying a list while iterating over it is not recommended.

Bots for load-testing

A list of MMOs, MOBAs, and FPS games that have been load-testing using bots.

TERA

Koo, 2010, How to support an action-heavy MMORPG, slides

Their system to load-test a shard is called Sisyphus, and runs 1500 clients per machine. The behavior of the bots is based on the behaviors from real players (probably from alpha). A WAN simulator is used between bots and realm servers; the average latency is set to 200ms. A high-performance machine and a "dedicated line" were needed.

EVE

Press, 2011, Orchestrator: A post-mortem on an automated MMO testing framework, slides

EVE started to make a thin client from its game client in 2010. Orchestrator is the tool they use to load-test and integration-test their architecture and code. Orchestrator does not send one script to each client, proxy, and server. Instead, it runs a single master script, and tells them, as they progress in the test, what the next operation is. The test can be stopped right when a client reports a bug, not until everything scheduled has been sent.

OpenSim

Lake, 2010, Distributed scene graph to enable thousands of interacting users in a virtual environment, paper

The limitations we have encountered with avatar scaling during these experiments have been in getting enough hardware to generate the load of over 1000 clients and the limited physics simulation capabilities of a single thread on the scene server.

League of Legends (allocating games to servers)

Delap, 2010, League of Legends: Scaling to millions of ninjas, yordles, and wizards, video + slides

• Load-testing in a realistic setup: more than 50 machines with the same spec as those in production
• EC2 is a good tool, but the network is not reliable, so careful not trying to fix problems that only happen in the test setting.
• With thousands of clients, logs may not be the best way to gather test results.

League of Legends (chat)

McArthur, 2011, Building the chat service for League of Legends, slides

Dozen of EC2 machines, each running 5-9k bots. Each bot is an XMPP chat client (they used the Smack API). Load-testing is useless without proper modeling.

Crysis 2

Hall, 2011, A Programmer's Post-mortem Crysis 2 Multiplayer, slides

They wanted to check the frame rate with lots of moving entities, and detect bugs or gameplay issues. They used automatic testing. "Lots" of bots are run for 10 minutes per level to stress-test the builds. The bots do random actions like walking, jumping, or shooting.

Gears of War 3

Weilbacher, 2012, Dedicated Servers in Gears of War 3 Scaling to Millions of Players, slides

Their bots are clients without renderer and user input. They run automated bot matches to check the performance of their server platform. For Gears 2, they used to run 2.5 games per core in 2009. For Gears 3, they run 7 games per core in 2011.

Guild Wars 2

Patrick Wyatt, a lead programmer on Guild Wars and Guild Wars 2, discourages using bots: bot's behavior differs too much from actual users. Instead, he recommends recording live play data, and replay it on the server to fix bugs or check the load.

Dead MMOs closing their eyes on private servers?

There are many MMO server emulators out there. Some private servers are run for profit, and when it is the case, the official and legal operator of the game can sue for disgorged profit, as was the case in Blizzard vs Scapegaming in 2009. Interestingly, out of the $88M Scapegaming had to pay, $3M came from disgorged profit (the private server was running micro-transactions), and $85k came from statutory damages for copyright infringement. Some private servers are run for fun and do not even accept donations. In the case of Ragnarok Online, Gravity used to send cease-and-desist letters to the private servers with the largest number of players. Servers with a dozen players did not seem worth the hassle.

Both WoW and RO are still running. However, the policy towards private servers seems to change when the MMO is discontinued by its legal operator. For instance, SWG closed in December 2011. SWG had an emulator called SWGEmu. In August 2012, the president of SOE unofficially supported SWGEmu: well officially I have to say it's bad. but that's officially. SOE or LucasArts could have been copyright trolls, but instead, they have decided to close their eyes on private servers. Maybe we can expect the same from Blizzard when WoW dies?

Agile game dev (5/5) - Keith 2010

Agile game development with Scrum, Clinton Keith, 2010

Part V - Getting started

Read the series: 1/5, 2/5, 3/5, 4/5, and 5/5.

Myths and challenges of Scrum

To prevent endless development without focus, the product owner should hold his vision.

Scrum is a template/framework, not a formal development process. It fosters continual improvement and transparent practices. It also promotes change, but any method introducing change should be reversible and incremental, and its impact should be measurable.

Agile has a lot of meetings because communication must happen. Plus, sprint review, planning, and retrospective meetings only take at most a whole day every 2-4 weeks, and the daily scrum should be timeboxed to 15 mins. So precious time is not wasted in excessively too many meetings.

Developers get tired and less motivated after prolonged periods of overtime; this becomes obvious when velocity is being tracked.

Working with a publisher

Problems: traditionally, publishers tie a detailed plan and schedule to their contract with a studio. The publisher is relieved: the responsibility to generate profits has now passed from their hands into the hands of the studio. Several problems arise:

• When they have problems, studios won't tell publishers by fear that publishers stop the contract. The game is playable only in alpha, and by then it is too late to fix it. Millions of dollars are wasted, and studios and publishers don't trust each other anymore.
• Publishers ask for minimum required feature sets such as "3 playable levels, AI attacking players, and online gameplay". Quality can not be defined in a contract, so developers rush for features ignoring quality.
• For business, marketing, or portfolio reasons, publishers can impose decisions on their first-party studios. These studios, feeling like they have lost sovereignty, do not want to collaborate with their publisher anymore.

Solution: transparency and collaboration to build trust.

Transparency: Following the Cerny method, studios and publishers must agree on conditions for entering prod. Pre-prod should result in production plans detailing metrics that measure cost, such as the number of people-days required to produce a level. Prod forecasts and metrics should be part of every release deliverable. Studios should also list all known risks and how much control they have on them, so that the publisher is not surprised when an expected risk happens, and eventually helps solving the risk. To that extent, the publisher should attend release planning meetings.

Collaboration happens by having a product owner on both sides. Both owners measure ROI based on the velocity of the team and the value and cost of features. They adjust the scope by prioritizing the product backlog, and can decide to extend the release date.

The publisher-side product owner is the bridge between the studio and the publisher's execs, marketing, and sales departments. He also reviews and plays each sprint build and attends release meetings. He takes care of the release goals (ie epic user stories) while the studio's product owner is in charge of the release plan (ie which user stories make it for the release).

Milestones define when the publisher funds the team, and when the team delivers a game. Funding and deliverable milestones can match, but the deliverable milestones should not be too detailed. Both parties should agree on a date range for entering production rather than an actual date: the range width will decrease as uncertainty decreases.

The publisher can opt for a kill-gate model: the studio builds 4 game concepts for a first milestone. The publisher funds 2 for pre-prod, and finally funds only 1 for production. Everyone wins: publishers reduce risk and get a game of higher quality, and teams gain development knowledge.

Launching Scrum

Progressing in Scrum is like progressing in martial arts: people start apprentice, become journeyman, and finally master.

The apprentice stage takes 3 to 12 months. Developers learn Scrum's basics: adjusting to sprint pacing, understanding that "done" includes polishing, decreasing the time spent maintaining a working build (= better tools and practices), reporting to the team rather than to the scrum master, and focusing on value rather than on tasks.

The journeyman stage takes a couple years. Journeyman developers:

• are collocated,
• use TDD,
• collaborate tightly with QA,
• create 1 polished level rather than 3 incomplete levels in 1 sprint,
• measure their velocity,
• use story points to estimate release plans,
• belong to well-established communities of practice,
• avoid hardening sprints,
• learn to adapt the basics of Scrum to the situation.

For instance, a team is facing the following problem: when a character walks, sound should be played, but animators submit their work late, and sound designers have to rush in to make the character fit in the sprint. This results in poor sound effects. To solve this problem, a team of apprentices would place a cut-off date 5 days before the sprint end for animators to submit their work. This would give enough time for sound artists to keep the quality high. However, the animators do nothing for the last 5 days, and their velocity is reduced. A journeyman team would have the animators deliver animation mockups right from the start of the sprint, so that sound artists can add their art quickly too. Thanks to better tools, animators iterate and update their animations throughout the sprint seamlessly for sound artists.

The master stage is never-ending. Only teams with good chemistry, in control of their methods, with strong emergent leaders, experts, and visionaries, all collaborating. Some master teams abandon sprints for continuous Kanban.

Company-wide adoption can happen progressively through a beach-head team of volunteers who decide to try out Scrum. They should be given an easy set of tasks to complete because a lot of management issues will be raised. After a couple releases, Scrum can spread to the company. The beach-head team can be split into 2 or 3 teams, filled until full with developers to teach Scrum to. Pro: The non-beach-head team members learn Scrum quickly. Con: the beach-head team has just been broken, and they may have liked to stay together. Alternative: keep the beach-head team intact, but have some of its members work 50% as Scrum coaches for other teams.

Agile game dev (4/5) - Keith 2010

Agile game development with Scrum, Clinton Keith, 2010

Part IV - Agile disciplines

Read the series: 1/5, 2/5, 3/5, 4/5, and 5/5.

Programming

Flexibility is essential to not waste time during development. Over-architecting can not take into account all the possibilities from the start.

XP includes TDD and pair-programming. TDD maintains stability when refactoring happens. It works best when accompanied by a continuous integration server. Pair-programming helps junior coders learn the ropes and decreases the time spent surfing the web or checking emails: when someone else sits next to you, you don't dare.

Debugging and QA happen throughout development. Bugs transform into stories, and make their way in the product backlog. Their priority is decided by the owner based on the magnitude of the consequences.

Optimization should also happen throughout development to be able to reach the shippable definition of "done". Example of a definition of "done" not for shippable but to be able to see the fun in the game: 50% of frames run at 60+ FPS, 95% at 30+ FPS, and the level loading time should not exceed 1 min. Spikes can be used to explore optimization techniques if need be.

Art and audio

Teamwork in a cross-disciplinary team turns artists who deliver art into art-specialized developers who deliver an experience. Artists generate assets ranging from textures, and models to sounds and music. To make their assets, artists rely on tools. If artists work in purely artistic teams, they observe an unavoidable tradeoff between the cost of making assets and their quality. In a cross-discipline team, tools and practices are continuously being improved, hence quality may increase while cost decreases.

Art QA is performed all along by the whole team. To test their assets in-game, artists need a build that is relatively stable. The quality of assets can be verified manually in-game and/or automatically by tools. Often, assets have to be approved by the art director to be considered "done". To save time to everyone, an evident "art director approval" column can be added to the Kanban board.

Pre-prod is really important because it is when production costs are learned. 50% of production costs come from level production. These costs can be estimated by building a vocabulary (ie patterns) of simple levels and their mechanics. Artists should also know, before entering production, the constraints and budget: how many bones per character, how many polygons on the screen, which character behaviors and motions are necessary, etc.

Game design

The roles assumed by designers are varied. Since designers represent players, senior designers can assume the role of product owner, provided they take into account cost and ROI. In teams, designers should go in teams where they know the domain: designers with UI/UX skills go to the HUD team, and senior designers to the core gameplay team.

The design document should not be too detailed. It should be updated daily with what becomes known about the game. It should not try to answer the unknown, because the only way to answer unknown features is to try them in-game. The design document also holds the vision for the game. Designers in cross-disciplinary teams relay this vision to their team and filter and adapt ideas generated by the team.

Designing from "parts on the garage floor" happens when parts are developed separately and integrated 2 weeks before shipping. The resulting game is very different from the vision, but it is too late to fix or polish.

Set-based development is preferred to point-based development. Point-based development consists of iterating each discipline in isolation from the others. For instance, the designers want the feeling of a seamless world. They think that contiguous locations could be streamed from the disc, so they go ahead with their design without asking the programmer if it is actually possible. The next build shows it is not possible with the current engine. Designers also learn that artists did not have the appropriate tools to bake streamable assets. They abandon the idea.
In set-based development, disciplines share their possibilities and constraints. In our previous example, designers would ask around whether it is possible to stream scenes to provide a seamless world experience. They get feedback from programmers, who decide to update the engine to support streamable scenes, and from artists, who request tools to bake streamable assets.

QA and producer

QA in traditional development processes happens in post-alpha, when minor tweaks and polishing are possible, but major defects can not be fixed. A studio culture that considers bugs to be part of making games does not help. Agile changes this.

In production, white-box testing can be performed in-house every day. QA takes care of regression testing on the build, developing testing tools, and testing pipeline changes. Each agile team already does QA to improve its practices, especially with TDD. Yet at the beginning of prod, teams can contain one tester to increase the quality of testing. In a team, testers help define "done" and the CoS for the stories. They also help the team keep a consumer eye on gameplay. If smoke-tests can take care of what can be automated, testers can still conduct walkthroughs to assess usability, playability, challenge, pacing, and the level of polishing.

In post-prod, or even at the end of production, testing and tuning ramp up. Pools of testers can be shared between teams. Bug-tracking repositories can replace sprint boards. QA can also organize playtest sessions using local university students or local game shop customers.

Producers in scrum can take the role of scrum master, but should never micro-manage. They can also be (co-)product owner, taking care of licensing, outsourcing, and publishing issues. They also plan resources.

Read more:

• McConnell 2004, Code Complete
• Beck 2004, XP explained
• McGuire 2006, Game design with agile methodologies (online)
• Poppendieck 2003, Set-based development (online, ch2 p26)
• Irish 2005, Game producer's handbook

Agile game dev (3/5) - Keith 2010

Agile game development with Scrum, Clinton Keith, 2010

Part III - Agile game dev

Read the series: 1/5, 2/5, 3/5, 4/5, and 5/5.

Video game project planning

The minimum required feature set are the must-have stories. For an FPS, they may be: 8-12 hours of story, shipping for Christmas, advanced NPC AI, or online gameplay.

Publishers require early concepts.

Any game development has the following 4 phases. During the concept phase, ideas are generated iteratively until the green light of the publisher. In pre-prod, typical levels and assets are created iteratively to estimate the value of the minimum feature set (which mechanics are fun, which artistic themes are interesting) and cost (hours, license fees, skills, or technology). Production relies on the knowledge acquired during pre-prod to build, at the lowest cost, the 8-12 hours of content. Production is pipelined, ie mass-produced like in a Ford factory. Post-production deals with polishing.

The production debt is the amount of work that needs to be done in production right after going out of pre-prod.

Production is assembly-line work/pipeline, there should be no starvation. This pipeline model does not fit well with the sprint model: imagine a sprint centered on a particular theme such as a dragon boss. Modelers in the team would spend the first week making the model, then animators would spend the next week animating it, but modelers would have no work to do. Each specialty end up working only a fraction of the sprint - this is not good.

Solution: lean practices, and more particularly a Kanban board. In a Kanban board, tasks flow from the left-most column to the right-most column as they progress throughout the pipeline. To pipeline the creation of characters, each discipline (e.g. modeling) should pass a task to the next discipline (e.g. animation) on its right on the Kanban board every week. Much like any assembly line, when being part of a prod pipeline, the developer can only spend a limited time on a task, otherwise he will slow everyone down.

But some tasks take more time than others. For instance, it has been estimated that it takes 2 weeks to complete the modeling of a character, 3 weeks for the animation, and 1 week to add the character's audio effects. So the character asset ideally spends a total of 6 weeks in the pipeline. This is called the cycle time, although definitions differ. But once the pipeline has been filled, a character is done every week. This is called the takt time, or production rate. In our example, to reach a takt time of 1 week, the team should have 2 modelers, 3 animators, and 1 sound effects engineer. To prevent starvation, task buffers between columns can be put in place, but they increase the cycle time (because tasks end up spending a couple extra weeks in the buffer columns).

Teams

Teams are usually cross-disciplinary (e.g. 2 designers, 3 programmers, 2 graphics artists, and 1 sound artist), self-managed, and self-organized. Yet the lead developers manage planning and resource allocation. They also mentor and review the team members so that they can improve their practices.

Working 100% on a few features is better than working 25% on many because it gives a sense of accomplishment. But it is not always possible (e.g. when 4 teams share an audio effects engineer).

Shared infrastructure teams provide low-level support that multiple games rely on. They are not always cross-disciplinary. For instance, the team working on the foundation of the engine may be entirely composed of engineers. Such teams should keep in mind their users: most of the time, they are other developers. These teams have their own product backlog, sometimes longer sprints taking into account in-house support and maintenance, and their product owner should be an exec (e.g. the CTO for the engine team).

Meeting-wise, scaling Scrum happens during the Scrum of Scrums. This meeting is attended by 1-3 members from each team, and is moderated by one of the scrum masters. Mike Cohn gives advice on the agenda and frequency of this meeting, but it's usually weekly or bi-weekly. The goal is to discuss a backlog of shared impediments, and eventually trade specialists such as a mo-cap technician between teams. Specialist-swapping requires some planning to avoid overlapping demands between teams. Another way to approach specialists consists of having them stay in their team, but dedicate only one half of their task points to their team, and the other half to support/advise other teams.

Vision-wise, if there are too many teams for 1 owner, then there should be a lead owner and a few owners, each in charge of a domain such as UI or AI. The owners should meet frequently to keep their vision in sync.

If the sprint dates of 5 or more teams coincide, then a single owner can not attend the sprint review meeting of all the teams. Pros: teams can swap members and gain a more holistic view of the build. Con: there must be an additional owner, risk of diluted vision.

Communities of practice gather developers from the same discipline, such as graphics or AI. Those meetings happen weekly or bi-weekly. In those meetings, developers share progress and information to avoid duplication of effort. For instance, no 2 teams should have their AI engineers develop their own engine on their side: they should first talk about it in their community of practice to see if other teams have coded the engine already.

Read online the chapter about teams.

Faster iterations

Development iterations suffer from overheads such as compilation, delays to propagate the tuning of a variable (need to recompile the whole game to change the HP of 1 monster), asset baking (transforming objects from the format they were created in to a format that the platform can import directly into the game), bug fixing, or administrative issues. Agile aims at reducing this overhead, as measured by automated baking/compiling tools, and plot it every day to see if changes are effective. Solutions to reduce iteration time include fixing bugs, improving asset creation tools, upgrading development machines, or being able to hot-load assets or edit parameters in game.

Tests: With small commits, the team can find which commit introduced bugs by running tests. Much like the increasingly demanding definitions of "done", there are increasingly demanding test strategies. Continuous testing happens at the order of the minute, and includes: the build compiles, passes unit tests, and passes asset validations. Hourly tests include passing platform smoke-tests (loads and starts running) or loading a level without crash. Daily tests include running a scripted bot play-through, or a QA play-through. QA can play through the daily build twice a day for 30 min. Everyone understands the stability and of a build by its file name and date: "MyGame_20120727_smoke".

Assets should be compressed when transferred between SVN repos. If bandwidth becomes limiting, either pre-transfer builds and assets overnight to those who need them, or buy more bandwidth!

Read more:

• Poppendieck 2006, Implementing lean software development
• Ladas 2009, Scrumban
• Larman 2009, Scaling lean and agile
• Crispin 2009, Agile testing
• Lakos 1996, Large-scale C++ software design

Rewards, pacing, and dopamine

Rewards and pacing

There is something mysterious when people read through 1000 pages of Cryptonomicon, a 1999 novel from Stephenson, or through the thousands of pages of Martin's A song of ice and fire. What keeps people reading? Here are some rewards that both authors use throughout their books:

Reward	Pacing	Description
Character progression	Randomly (but fits the story)	The protagonist learns new skills, grows up, meets love, learns a lesson of life, or gets rich. We care about this character's well-being because we empathize.
Action and passion	Every 3-10 pages	When stuck in difficult situations, the reader knows that the hero can not die, so she asks herself: how is the hero going to get out of this alive? (Except sometimes, main characters actually die, leaving us in shock). The same applies for romantic scenes, where we wonder not if, but how it's going to work out between two characters.
Story progression	Every 10-30 pages	Right from the start, the authors put under the reader's nose a bunch of questions: what is happening, why is this guy so mysterious, and so on. The reader wants to know the answers, so she keeps reading until answers are provided, along with new mysteries to figure out.

Looking at blockbuster action movies such as The Bourne Ultimatum, the same kind of pacing emerges: action scenes are followed by the protagonist learning about his past. Then the plot moves on, the character meets new people, finds himself new tasks to do, and back to action scenes.

These rewards and pacing also echo those found in games and mentioned in a class on game balance from Ian Schreiber: gains in character power, discovery of new areas, and progression of the story are rewards to be used at irregular intervals to keep the player engaged. So reading books, watching movies, and playing games seem to provide similar rewards.

Dopamine

Let's dig down to the physiological level of rewards. Most of the articles dealing with the physiological response of gaming revolve around addiction. For instance, a 2012 NY Times article reports that Zynga helps addict millions of people to dopamine, a neurochemical that has been shown to be released by pleasurable activities, including video game playing, but also is understood to play a major role in the cycle of addiction.. To that, the Zynga co-founder replies: Given that we're human, we already want dopamine. And that does not calm things down. So let's look at a less controversial topic: the physiological response of reading. This is not a survey of the field, but rather some picks from a few Google searches - nothing very serious.

First, according to Farland, a current writer, the dramatic structure of stories (exposition - action - climax - denouement) matches the bio-feedback of hormones such as dopamine, adrenaline, and cortisol. He says: As a person "hunts" for clues, or for a way out of a problem, the brain rewards the person by releasing dopamine as a reward. [...] When you reach the climax of the novel, [...] you reach the climax of your emotional exercise. When the story ends [...] your stress is released. The adrenaline and cortisol stop flowing.

As notes from a psychology class on stress can tell us, cortisol is the key hormone of stress. Adrenaline is the hormone that tells our body to be alert. And finally, dopamine is in charge of rewarding our brain.

So what happens when we start reading? Some have guessed that we are having pleasure because reading is a tough task, and our brain rewards us for completing such a hard task. This seems confirmed by a 2001 study who showed that transitioning from rest to reading produces the same increase in dopamine concentration as transitioning from rest to memory-intensive tasks (something cognitively demanding). Although, a 2000 study seems to reject this hypothesis. Something that might be worth investing is whether reading a microwave-oven manual generates as much dopamine as reading an exciting short story where the action starts right from the start.

It may actually be more complicated: the dopamine concentration could actually not indicate our pleasure, but our expectation of pleasure: dopamine motivates us, increasing our energy and drive and compelling us to engage in the pleasurable activity. If everything is as nice as the brain predicted, dopamine levels remain elevated. If things turn out even better than the brain hoped, dopamine levels are increased; we engage in the pleasurable activity even more vigorously. If, on the other hand, the activity is less pleasurable than we thought it would be, dopamine levels plummet.

Back to games

So, what can we conclude about games? First, much like movies and books, reward us by generating dopamine when we succeed at a difficult cognitive tasks such as a head-shot in an FPS, or a successful Chess trap. That is pretty close to fiero, and in fact, Bateman already suggested in 2008 that fiero is a cocktail of epinephrine and dopamine. So, nothing brand new here.

Perhaps more interesting, long-term enjoyment seems to require the dopamine to yo-yo - which is bad. Let us assume that our brain produces dopamine by expecting a nice event. Then when our brain is done with those nice events, the dopamine level will decrease. That would be a horrible yo-yo if there were only one kind of event, but books, movies, and games, have at least three: action, story, and character events. So alternating events and interweaving them in such a way that our brain is always on the lookout may keep dopamine, and pleasure, at high levels instead of making it yo-yo.

There might be a few gotchas, though. First, the magnitude and the lifespan of the dopamine burst depends on a lot factors. Grinding monsters for a drop is only pleasurable so long as the brain is expecting that item to drop. After a couple days, the dopamine is all gone, and it's just boring. Some studies should investigate the average magnitude of an "achievement unlocked!", or the lifespan of a boss kill or a level up.

Second, dopamine bursts may not stack. The brain may be too busy expecting a story progression event that it may ignore, or even worse, be displeased, by a character progression event: it was not expecting it! This limitation does not seem cognitive, but rather emotional, so maybe people with higher EI could stack expectations and dopamine bursts more easily than indifferent people who say "it's just a game"?

Third, and to finish as we started, with books: Stephenson and Martin alternate their character viewpoints chapter after chapter, possibly to keep the reader's attention. By the way, they rarely handle more than 7 characters at the same time, since 7 is a magic cognitive number. These changes in views often cut short the action, so the reader may get frustrated, or even vexed for being tricked to continue reading by the exact same three mechanisms every chapter. It is interesting to know why people keep reading those long books, but that last reason is exactly why I stopped.

Agile game dev (2/5) - Keith 2010

Agile game development with Scrum, Clinton Keith, 2010

Part II - Scrum and agile planning

Read the series: 1/5, 2/5, 3/5, 4/5, and 5/5.

This part should be dealing with Scrum and agile in general, but in the book, a lot of the examples are actually drawn from game development.

Actors

The team is often collocated, and members organize themselves as they want. Scrum teams are made of 6-10 people. There should be designers, programmers, and artists in the team.

The scrum master is not a manager, but rather a sheep dog. She makes the bridge between the stakeholders, who talk about ROI or budgets, and the developers, who talk about gameplay, art, or engineering. She educates the team to scrum by reminding them that they own the product, and that debugging/polishing must happen throughout the sprint. She also facilitates planning by preparing meetings and monitoring progress. And she also puts problems to the front stage so that anyone in the team can help in solving them: bugs, dev pipeline stuck, buying a tool, or administrative issues. The scrum master is usually not a developer, and handles 2-4 teams at a time. In the game industry, the role of scrum master is often taken by producers or senior/lead developers.

The stakeholders are the customers. In the game industry, they are the publisher(s), marketing, sales, IP owners, the studio management, but also the players.

The product owner is the voice of the customers to the team. He knows the market, so his vision for the game is trusted, and he has the final word on the priority of the features to be developed. Increasing the priority of features with most value and low cost is how he maximizes the ROI for the customers. He plans releases (date and features in them) and contributes to sprint planning and sprint reviews. He regularly asks the top execs for advice (e.g. the CTO for technical feasibility). Examples of illustrious product owners include Miyamoto and Sid Meier.

User stories

A design document does not indicate which features are of highest priority. Moreover, updating it quickly is difficult. And finally, it does not communicate value to everyone. Instead, agile uses a product backlog, which is basically a list of features (called PBIs) prioritized by the product owner, with input from the team, domain experts, and stakeholders, before each sprint. The product backlog of a console game contains 300-500 stories, while an iPhone game 100-200.

PBIs are also called user stories. They take this form: "As a [role] I want [goal] so that [benefit]". Role can be "player", but can also be an artist using a tool, or a programmer using a continuous integration server. The more detailed the role, the better: "FPS expert player", "Healer", or "proficient 3DSmax designer". Everyone should be able to understand the story and see its value. For instance, "As an audio programmer, I want a checkbox to control the boolean bLooping" should instead be "As an audio programmer, I want to control the looping background sound effects." Stories are collected and estimated during a workshop attended by the team and moderated by the owner. They can also come from marketing and/or focus groups at the start of the project. Good stories show the qualities listed in INVEST:

Quality	Example
Independent	"As a player, shooting a door makes it explode with wooden particles" and "As a player, shooting a window makes it explode with glass particles" are dependent because they require the same tech. Combine them: "As a player, shooting props makes them explode with shards".
Negotiable	"As a driver, I want to see water spray when driving over water" does not harness the team's creativity. Who knows, maybe mud effects could be more appropriate. Replacement: "As a driver, I want to see effects when driving over various surfaces", and eventually add the CoS "Over water, there should be a water spray."
Valuable	"As a designer, I want all the rigid bodies that are near each other to be grouped into the same cluster" does not show value. Add "so that the game can run at 30 FPS" and everyone gets it.
Estimable	The owner should be able to estimate risk and whether the value of a story is worth its cost. When he does not know, he asks for a particular sprint called a spike to gain knowledge. Example of story in a spike: "As an owner, I want to see a video of the fighting mechanics on iPhone".
Small	Break down large tasks into small ones. Eventually group tasks worth less than an hour into a single one.
Testable	Use CoS, or a lead developer can approve stories by saying "OK, level 1 is fun", but that's subjective. A definition of completeness also helps: "the character model has been mocapped, rigged, textured, and tested in game".

Epics are large stories that require more than a dozen hours to implement. They are broken down in smaller stories as their priority increases and they are moved up the product backlog. Using "hours of work" to estimate a story size is not appropriate: teams work at different speeds, so "10 hours of work" for an experienced team may actually mean 30 hours for a team of beginners. Moreover, a story has to be broken down into developer tasks. In the end, tasks are the ones being estimated using points. The number of points completed per sprint by the team is called velocity, and it is tracked by the scrum master. Velocity is useful to gauge if a project is on time, and if changes to practices are effective.

Velocity and points are used to track progress on a burndown chart, where a flat line shows stagnation and a steep decline shows progress. The team can see their efficiency at processing tasks over the sprint, and determine if they are going to make it by the end of the sprint.

The burndown chart is usually hung in the war room, a room where the team holds its daily scrum meeting. It does not have chairs, otherwise people would be tempted to sit on them and not talk - hence the name stand-up meeting. In the war room, there is also a task board on which 3-by-5 cards are hung to show tasks and their progress. Cards are good because they can be customized, color-coded, hung on a side-wall, etc.

The release plan is a subset of the product backlog, detailing the release date and the release goals (in terms of stories). Like in the product backlog, the stories at the bottom of the release plan have low priority and have not been broken down. Stories are grouped together in goals and themes that can be tackled by the team in a single sprint.

The conditions of satisfaction specify the tests that a story should pass, ie the definition of "done" for that sprint. For instance, "As a player, I want to see enemies react when shot" can have CoS written at the back of the story's 3-by-5 card like "when shot in the head, knock-back; when shot from the right, shift left". The definition of "done" can take multiple predefined levels, such as "Runs on dev machine", "Runs on all platforms", or "No memory leak". The magazine demo usually has a demanding "done": fun and challenging, no large memory leak, no missing asset, and a clean UI. It may require a sprint dedicated only to polishing, called a "hardening sprint". The debt induced by a sprint is the amount of work remaining to reach the shippable definition of "done" after the sprint is over. When definitions of "done" are stricter, ie closer to the shippable "done", there is less risk of debt. Hardening sprints reduce debt at the expense of time.

Meetings

Meeting	When	How long	Who	Why	Details
Sprint prioritization meeting	Beginning of each sprint	Until the sprint is filled	Team, owner, scrum master, and eventually a domain expert (e.g. network programmer or mo-cap technician)	Prepare the product backlog and identify sprint goals. Establish 2 themed sprints worth of PBI. It is the opportunity for the team to ask questions to the owner and understand PBIs and the vision.	Sprint planning: The PBI "player can jump" can be broken down into the sprint backlog tasks "make jump animations: 10h", "program jumping controls: 5h", "program jump physics: 15h", and "make the sounds for jumping: 2h". PBIs at the top of the product backlog should require less than a dozen hours, and fit in a single sprint. If not, they should be broken down into smaller ones. All the tasks coming from a PBI should fit in one sprint. If not, break that PBI in smaller PBIs. PBIs at the end of the product backlog are vague and need to be broken down and detailed when their time comes. For instance, "online play" may be broken down into "lobby", "capture the flag gameplay", and "multiplayer analytics". If the team overestimated the work to be done, and has finished a few days before the end, call a mini sprint planning meeting and add a couple small PBIs to work on until the end of the sprint.
Sprint planning meeting				Add tasks to the sprint backlog from the product backlog. The scrum master first identifies constraints against the goal such as holidays or engine updates. The team and the owner then discuss the design and implementation of the highest-priority PBIs, break them in tasks, estimate the amount of work for each task, and add those tasks to the sprint backlog until there is work for the whole sprint. The owner has the last word on which PBIs the team should work on for the sprint.
Daily scrum	Daily	15 min, timebox	Team, scrum master	Share progress and impediments. Each team member explains what they've done, what they're going to do, and what is slowing them down.	"I spent 6 hours on that bug and still have not figured it out" calls for more people to look at it.
Sprint review	End of the sprint	~ 1 day	Team, owner, scrum master, stakeholders	Review of the sprint by the owner, who plays the game or watches a demo, and updates the product backlog accordingly. If not satisfied, he decides which features go back to the product backlog (to be worked on again) or are deleted. Not all stakeholders need to attend, but the publisher should be present.	Large projects with many teams should have a single big meeting with everyone. Pros: It saves time for the owner and gives a unifying vision to everyone. Con: the owner may take it as a ceremony since it's rare and there are lots of people. Alternative: the owner can review each team separately. Pros: more casual, detailed, and direct. Cons: more time consuming. When the sprint review is over, productivity won't be 100%, so the team can spend the rest of the day celebrating or playing games.
Retrospective meeting	Just after the sprint review	30min to 3h, timebox	Team, scrum master	Talk about which practices work, should stop, or be tried. The scrum master keeps track of answers and whether things are fixed or not.	"The build server should send an email when the build is broken" gives an action item for the sysadmin/build team. If no sysadmin is in the team, the scrum master should go ask the sysadmin.
Release plan meeting	End of the sprint	4-8h	Team, owner, experts, stakeholders	Discuss epics, story themes, and release goals. Prioritize and estimate stories, set the release date, and select the length and goals of the next 2 sprints.	For each story, everyone raises a card showing their point estimation. Estimations can only take values in {0 (trivial), 1, 2, 3, 5, 8, 13, 20, 40, 100}. People debate and re-vote until everyone shows the same points. Different estimates should not be averaged: this would hide matters that need to be discussed.
Planning poker				Team, owner, and experts determine the workload of a story based on similar stories already completed. Points are used, not hours, because teams have different velocities. Spend a couple minutes per user story.

Miscellanea

The sprint goals/PBIs should not change throughout the sprint. In a way, the team is "locked" on those PBIs for the duration of the sprint, unless the owner asks for a sprint reset. In a sprint reset, the team stops the tasks it was currently working on and calls a new planning meeting. A reset can happen when big goals change, such as when the CEO wants a new feature in 2 weeks to demo the game and raise funds. The team and owner should assess if it's doable, then reset. Resets can also happen when the sprint is running out of time, working overtime is not possible, and the owner does not want to remove lower-priority features from the sprint.

Sprint length: 2-4 weeks, but the owner has the last word. The length should not change too often, otherwise teams can't get used to it. Shorter sprints are appropriate in uncertain contexts such as pre-prod (when customer feedback is frequently required) or for teams new to agile or to working together. In general, 10-20% of sprints should run out of time before they end. If less, it looks like the team is fearing commitments. If more, it means they keep miscalculating, and may not take their commitments or estimations seriously.

Read more:

• Cohn 2006, Agile estimating and planning
• Cohn 2004, User stories applied

Agile game dev (1/5) - Keith 2010

Agile game development with Scrum, Clinton Keith, 2010

Part I - Problem and solution

Read the series: 1/5, 2/5, 3/5, 4/5, and 5/5.

Problems

In the 70s, arcade hardware was expensive, so developers iterated on the software and shipped when high quality. In the 80s, hardware became cheaper, so everyone could ship games without too much investment. Quality consequently decreased. But as games increased in complexity, teams started to require specialists (artists, composers, network engineers), and the software costs exploded. This led to the hit-or-miss strategy: invest only a few man-years in developing a game, ship, and hope for success. Hopefully, one hit would pay for many failures.
Problem #1: the number of man-years (and costs) to make AAA games doubles every 5 years, but the market isn't growing as fast. Moreover, only 25% of the revenues will go to the developer; the rest goes in distribution, marketing, publishing, and licensing fees.
Problem #2: only 20% of games released generate profits, so risk-averse publishers prefer sequels of existing IPs than risky innovation. Yet it is innovation that drives the game industry.

You can only know if your game is fun by play-testing it. Since design, art, and tech requirements emerge as the game is developed and play-tested, waterfall is not appropriate, and maintaining a detailed documentation too time-consuming.
Problem #3: how do stakeholders (developers, publisher, IP owner, studio management, etc.) communicate?

Traditional game development is made of 4 steps: concept, pre-production (aka pre-prod), production, and post-production. Of particular interest are pre-prod and prod. Pre-prod is exploratory, and aims at figuring out the basic mechanics for the game to be fun. Pre-prod can follow a kill-gate model, where several prototypes are started to explore ideas in parallel, and the least promising are "killed" every few months. In production, levels and assets are mass-produced.
Problem #4: how to predict the schedule, budget, and amount of new content to produce from the basics found in pre-prod? Moreover, milestones defined in contracts with publishers prevent developers from adding good features at the last moment, and prevent publishers to ask for new features too. How to accommodate everyone?

Introducing agile game development

Agile is not a silver bullet. It only makes the development process transparent: problems will become obvious, but they still have to be solved. Agile aims at improving communication between the stakeholders: publisher, developers, IP owner, studio management, and so on.

Sprints: Agile game development is iterative. At the lowest level of granularity, an inter-disciplinary team of developers designs, implements, and polishes features during iterations of 2-4 weeks called sprints.

User stories are the agile way to present features so that they communicate value/fun to the stakeholders. For example: "As a player, I want to see enemies react when shot."

Releases: At the highest level of granularity, releases of the game are delivered every 4-8 sprints (2-4 months). Releases focus on major goals such as "online gameplay".

Backlogs: Communication within the team happens through a sprint backlog, and between the team and the stakeholders through a product backlog. User stories are moved up or down the backlogs by the product owner, representing the stakeholders in the studio.