Ken Lobb FDG 2014 keynote

Ken Lobb designed Golden Eye and Killer Instinct in the 90s. Here are notes from a keynote he gave at the FDG 2014 conference.

Having an extensive knowledge of games is mandatory for game designers, because they provide a common vocabulary to talk about games.

In the late 80s, teams rolled their own tools. Nowadays, AAA teams still have the not created here problem and waste a lot of time reinventing the wheel. That's why indies using Unity or Unreal can save on costs and take a bite at AAA.

The most important tool in game development is the game build, because it is how the game improves, little by little. Next comes the schedule, ie what to do next. Finally comes the spec and docs, because they change all the time. Microsoft has the process mastered. In fact, Microsoft is too good at planning: they always ship what they speced, and not exactly what they should create. The industry in general, and Microsoft in particular, sign games that cost way too much money.

Difficulty: games have shifted from lose vs win, to win vs big win vs epic win. now in call of duty, high kd ratio is winning. dying is not too bad. before in golden eye, die means restart whole 10min level. now, focus on positive reinforcement rather than punishment.

Major game design issues:

• Tutorials are hard to build right. Should players be reminded of mechanics they may already know, or should they instead be taught from scratch? The Zelda series have great tutorial design: they simply give the player the tool, and teach by giving more and more difficult challenges that require using that tool. Achievements can also encourage a particular behavior.
• Cheating is OK. 90% of Xbox players are also on a second device when they play. Players use Youtube, watch Twitch, and look for cheats and FAQs all the time. Procedurally-generated or randomized content can curb this practice down, but a real solution may involve the game itself showing tips or videos from the players who passed an obstacle to those who are stuck.
• Making a game noticed on app stores/platforms is difficult. Advertising and charts do not target particular players. Word of mouth is more effective, but how does it start? Maybe app stores could recommend games to hardcore players, which would trickle them down to their friends? [This may have an answer: according to Wooga, it takes $250k to reach the first spot on the App Store]

The social strategy game genre

Here is a quick list of games that resemble Clash of Clans in some ways. Some wargame mechanics may date back from RPGs of the 90s, such as Age of Empires, or even from tabletop wargames of old. These old games are off-limits.

Released	Name	Theme	Description
Sep. 2004	Travian	Antiquity	The player can pick one of three tribes: the aggressive Teutons, defensive Gauls, and average Romans. Teuton players usually farm resources from Gaul players. Players can trade resources, message each other, and join alliances. Troops take time to produce, and can be unlocked and upgraded. A hero can equip gear, complete quests, and gain XP in battles. The game ends when a player upgrades a Wonder building to level 100. Premium accounts finance the game and have game advantages over free accounts.
June 2009	Farmville	Farm	Facebook game by Zynga. The player plants crops that grow with time, but wither if not harvested on time. Players can receive crops or animals from friends. In-game promotional campaigns for real-life brands like McDonalds or 7-Eleven. Reached 80M MAU and 30M DAU in Feb 2010.
March 2010	Backyard Monsters	Gory monsters	Facebook game by Kixeye. The design goal was to play an RTS game in short sessions. The game targets a hardcore player segment in several ways. First, the art is unusually gory, bloody, and industrial for a Facebook game, yet it was praised as the prettiest game on Facebook when released. Second, the monetization relies on the players who hate losing and are ready to spend money to gain an advantage. As a result, 85% of the revenues come from selling speed ups, retention is 5x longer than other Facebook games, 97% of the player base are males between 25 and 45, and the average user plays 3-4 session per day for 30 minutes per session on average. They peaked at 4.5M MAU and 1M DAU in Summer 2011.
May 2011	Battle Pirates	Warships	By Kixeye. Peaked at 1.6M MAU and 240k DAU in Q4 2012. The player controls a military island, and can be attacked synchronously, in real-time, by the boats of other players. Watch some gameplay.
Aug. 2011	Edgeworld	Aliens	Facebook game by Kabam. 610k MAU in Dec 2011. The developers did not expect players to be attacking each other for resources.
Sep. 2011	War Commander	Post-apocalyptic	Facebook game by Kixeye. Peaked at 5.2M MAU and 660k DAU in Sep 2012.
Aug. 2012	Clash of Clans	Medieval Norse	One month of soft launch: first released in beta on the Canadian iOS appstore in July 2012, then on all iOS appstores in August 2012. Released on Android in October 2013. Supercell had two goals: adapting the genre for the tablet, and bringing new segments to the genre. The name of the strongest unit in CoC, P.E.K.K.A., reminds of the name of the strongest monster in Backyard Monsters: D.A.V.E.. Some say that CoC is Backyard Monsters with polish. Troops are consumed if they are deployed in battle: even if it stays alive until the battle times out, the player loses the troop for ever. A lot of community management and communication goes on between SuperCell and the players through the forums or Facebook. Depending on where you look, CoC had 8.5M DAU in April 2013, and 4.3M MAU and 2.7M DAU in January 2014.
July 2013	Ninja Kingdom	Medieval Japan	Also called Dojo Mojo. Facebook game by Zynga. The Jade Mine can only be staffed with captured enemy troops, not with the player's workers. Each captured enemy troop generate 1 jade per 24h. If destroyed by an enemy raid, all the jade in the mine is lost. 4.6M MAU and 600k DAU in January 2014.
July 2013	Battle Beach	Modern warfare	The troops are a complete ripoff from CoC. 21k MAU and 9k DAU in January 2014.
July 2013	Jungle Heat	Modern warfare in a tropical jungle	Android game by Mail.ru Games. The troops are a complete ripoff from CoC. 260k MAU and 110k DAU in January 2014.
July 2013	Castle Clash	Medieval Fantasy	Around 20 heroes with different skills. Twelve troops: 3 tiers of power for each of the 4 attack types: heavy (strong against ranged), ranged (beats magic), magic (beats heavy), and heavy anti-building.
Sep. 2013	Amazing Clan War	Medieval Norse	Blatant CoC ripoff by a Chinese company. Even the loading screens have the same layout.
Sep. 2013	Kingdom Clash	Medieval fantasy	Soft launch in Australia in May 2013. 5k MAU and 2k DAU in January 2014.
Sep. 2013	Total Conquest	Roman Empire	iOS and Android game by Gameloft. Soft launch in Canada and New Zealand app stores a month earlier. The troops are very similar to CoC, except they don't seem to fly. 100k MAU and 30k DAU in January 2014.
Oct. 2013	Lord of the Guardians	Forest animals	Three solo campaign modes (normal, heroic, legendary), each with 150 mission. 5k MAU and 2k DAU.
Oct. 2013	Samurai Siege	Medieval Japan	iOS and Android (implemented using Unity). 1.2M installs and 300k DAU when it launched, 100k MAU and 44k DAU in January 2014. Same core units as CoC. Troops and buildings are unlocked through the solo campaign. The campaign has a (mediocre) storyline. Loot items are stolen from other players. When all 6 of them are gathered, they provide an extra army camp (more troops) or a cannon (more defense). Alliance War pits groups of players against each other for 12 hours. This was probably based on the periodic trophy push organized on the CoC forums to break the farming routine.
Nov. 2013	Call to Arms	WWII	Developed by GREE. Soft launch in October. Lets you simulate an attack on your own base.
Nov. 2013	Galaxy Factions	Space	A month of soft launch. 10 heroes and 12 units.
Dec. 2013	Boom Beach	Pearl Harbor	Soft launch in November. Developed by SuperCell. Troops that stay alive at the end of a battle are available in the next battle. The player can direct the units to attack a particular building through flares. Explore the ocean (at a cost) to find islands controlled by NPCs and other players. Attacking a neighbor player also has a cost. Nearby captured islands generate resources for you. The units are inspired from Team Fortress.
Dec. 2013	Dark District	Dystopian futuristic city	Developed by Kabam. 6 months of soft launch, probably because of all the crashes and bugs. Assign your troops a building to attack.
Dec. 2013	Sensei Wars	Medieval China and Japan	Soft launch in New Zealand and Australia in October. Developed by 2k Play. 3D graphics. One hero available from the start. Heroes gain levels and learn skills. There is a skill tree, and skills can be reset by paying the hard in-game currency.

Improving the genre

In-game base building: During the first few weeks, shuffling the dozen-or-so buildings around and trying a new base design is quick and easy. Three months later, the village holds around 80 buildings and there is little room to move buildings around. Since players can't design their base in-game anymore, they turn to unofficial websites where they can share their designs and receive feedback. This is bad because 1) it's a feature needed by the players, and it's missing from the game, and 2) the game developers lose touch with their players.

Community: CoC clones do not have a large community. In fact, very few of them have a community at all. The CoC player community is large, and provides valuable feedback and ideas to SC for free! The recipe is simple: the large amount of player suggestions and feedback is filtered by the community managers who then forward the key parts to the developers. For example, a player sketched out a very convenient in-game base builder in the SC forums on September 11. 20 days later SC released a patch with a simpler version of that player's idea. In my opinion, the community is crucial for innovation and polish, and none of the clones have it.

Innovating the core mechanics: The clones must innovate if they want to have people playing their game. A player wrote: if I had invested a ton of money in Clash of Clans, I would find it unlikely that I would do that again in a game that is so similar. I think there is a spectrum of innovation. On one side, Amazing Clan War is a blatant ripoff of CoC (see the CoC vs Amazing Clan War loading screens below). When your power in the game is all about how much time you have been playing for, why would you switch? Most other clones are heavily inspired by CoC, but add, tweak, or twist a couple elements. Yet the core mechanics remain unchanged since Backyard Monsters! For example, all games have the slow meat-shield troops luring defense buildings and the fast and weak troops targeting resources. On the other hand, the hero skill tree in Sensei Wars, the jade mine of Ninja Kingdom, or the 12-hour inter-alliance war in Samurai Siege are very promising PvP concepts, but they're too shy and peripheral to really matter.

Soft launches: CoC clones follow CoC's formula to launch the game in Canada, Australia, or New Zealand one or two months before worldwide release. But since CoC clones are all about time, soft launches give a head start of a couple months to some privileged players. That is probably why SC had no trouble giving new players 500 gems to catch up when they released the game worldwide. Of course the Canadian players who had started playing during the soft launch were not happy - they missed out on 500 gems! How could a game soft-launch and make everyone happy?

Clash of Clans - polish

SC spent a lot of time polishing CoC. They launched the game in beta only in Canada for exactly one month. I have never heard of such process for other iOS games. As a result, the game has been praised as well-presented and easy to play, with a smooth, clear interface and animations that are packed with character.

The depth of CoC's mechanics is a much-argued topic. When the game came out in mid 2012, a reviewer argued that the actual strategic elements of gameplay are far too lightweight and hands-off to satisfy fans of more traditional strategy games. But another praised CoC's unbelievably high replay value thanks to its varied troops, and distinctive performances of all defensive buildings, walls and traps that generates infinite possibilities for battles. The core of the argument comes from the fact that once a troop is deployed, the player is not in control of it anymore: the unit just behaves according to its AI behavior until it dies or the battle times out (after 3 minutes). In the first few weeks of play, CoC battles feel not precise and even frustrating. But then some players realize that battles are simply about unleashing a horde of troops to overwhelm the enemy. Some even go so far as saying that even a moron with no strategy at all will advance in the game with time. It is true: in the first month, the mechanics are so forgiving that some adults even let their infant playing CoC for fun.

But after a few months of play, I realized that no two units or buildings have the same function or effectiveness in battle. For example, among meat shield units, Barbarians are the cheapest and fastest to train, Giants also fast to train but more costly, and Golems the slowest and most expensive. But these units are actually very different in practice: Barbarians target any building, whereas Giants and Golems only defensive buildings. Giants have five times more DPS per housing space than Golems, and therefore can pierce through walls, whereas Golems need wall breakers to open the path. Even though the most powerful units are usually the most expensive and slowest to train, the behavior of the units in battle allow for dozens of attack strategies. So the game is essentially deceivingly simple, and its complexity grows with time. In my opinion it's great for newcomers and loyal players alike.

A lot of tiny details contribute to the great play experience. For example, the Dragon generates a lot of excitement when it becomes available at TH7. Players can donate troops to each other through their Clan Castle. Dragons can only fit in a Clan Castle level 3 or above. The Clan Castle reaches level 3 at TH6. So if I am TH6, even though I can not produce dragons, I get the thrill of using one through my TH7 friends.

The game also receives patches with new content, bug fixes, and balance tweaks roughly every 50 days. An observer suggested in September 2012 that SC implements super units, in which players emotionally invest to, because these units sell like pop corn in a movie theater. Heroes got introduced in January 2013. Unlike other units, which disappear after being used in battle, heroes stay after a battle and only need to be recharged after a battle. Heroes also provided a sink for dark elixir, a game currency introduced in the same patch.

In my experience, players were not very emotionally invested in their heroes. Getting a permanent hero for the first time generates the same craze as training a new disposable troop such as the dragon. The craze fades off quickly, and heroes are just a way to loot more gold. This lack of emotional attachment may be due to heroes being human-looking. If they were pets with accessories, players may be more emotionally invested.

While the base game was very polished when it hit the app store, each patch released so far has contained a couple bugs. Many of these bugs are graphical and directly observable when launching the game. Clearly, the QA for patches could be more thorough. Moreover, the aesthetic choices for buildings follow too many different styles: lava, electric, diamond, and so on. Players have complained about villages becoming ugly.

Game Architecture and Design - part 2 and 3: Management and Architecture

Game Architecture and Design - parts 2: Management and 3: Architecture, by Rollings and Morris, 2004

Ch9 - Current methods of team management

Several developer stereotypes pose problems.

• Mavericks are skilled and trust no one else.
• Prima donnas know they are the best and consider others as threats.
• Shy guys are ... shy, so they don't always say everything, which reduces the project visibility.
• Sleepers appear nice to their boss, but actually attack the management in their back.
• Jacks of all trades are overconfident and sell themselves too well. They can get overwhelmed.

Ch16 - Current development methods

Two quotes in this chapter exemplify the two main concerns I have with this book:

• Games are less original that they used to be. The authors explain further down that in a dozen years, graphics have improved a lot, but gameplay not as much. I disagree: with the blooming indie scene, and more and more games being made every year, this sentence sounds more like nostalgic bitterness than a constructive remark.
• C++ was considered too slow to be useful for game programming. The authors refer to Michael Abrash and his Assembly skills with so much awe that it gets a bit awkward. I think mentioning Assembly optimizations is worthless, and maybe even detrimental, to a 21st-century introductory book about video games. We have engines and high-level languages now!

Ch17 - Initial design

Tokens are elements of the game directly or indirectly manipulated by the player. Tokenization is the process between game design and implementation. Start with the token interactions and basic state machines, then the token-property interactions, and finally the property-property interactions. Example for Pacman:

Token interactions

	X	X	X
	Pacman death	X	X
	Ghost eaten	X	X

And the state machine for the ghosts.

Token-property interactions

Token	Properties	Hungry	Strong	Eddible	Weak
	Hungry	X	Pacman death	Score++	Ghost eaten
	Strong	Pacman death	X	X	X
	Weak	Ghost eaten	X	X	X
	Eddible	X	Score++	X	X

Ch18 - Use of technology

Game reviewers do not have time, so they give good reviews to the shallowest aspects of games: the graphics, not the mechanics.

Research and development is risky. Why not teaming up with a local university?

Ch19 - Building blocks

A bunch of design patterns useful for game programming. Here's chain of responsibility.

Observer:

Below is State:

Strategy:

And finally, Template:

Ch21 - Development

• Plan for reuse
• Document
• Design then develop
• Schedule ad communicate
• Catch mistakes as you go
• Limit R&D
• Know when it is good enough
• Team ownership/"invisible" management
• No feature creep
• Team solidarity

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

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.

Bottom-up game design

Existing definitions

Adams defined bottom-up game design in 2004 as turning a simulation or a real-life mechanism into a game. It assumes that any process that is subtle or interesting to program is also going to be interesting to play with. If the simulation has too many variables, many of them end up being useless, and this results in possible dominant strategies and the game being dull.

Lopes and Kuhnen redefined bottom-up game design in 2007, as applying a particularly fun gameplay verb or mechanic, complementing it with the appropriate setting, content and story. Developers think first about the elementary game actions, called verbs, that the player can execute (move, attack, ...) and then about the aesthetics (fantasy universe, ...). Examples are games in the Doom series, which were built barely as excuses for the brutal, over-the-top shooting gameplay; the oppressing universe and mood simply fit well with the gameplay.

In 2010, Deleon focused more on the medium constraints with his definition: concept inspired by or chosen partly by its form of representation. For instance, Bubble Bobble is about shooting a ball into balls of similar color, and the little dragons or fruits are merely decorations. Same for Bejewelled. Bottom-up designed games also include games made for particular platforms with limited hardware (like Bogost's games for the Atari 2600).

More theory: ludemes

Ludeme was a term coined by Berloquin or Dawkins in the early 1970s, as a portmanteau of ludic meme, because a ludeme can be found in many (classes of) games. Ludemes are described by Parlett as conceptual elements of the game, most typically equivalent to its "rules" of play. For example, whereas the material piece shaped like a horse and designated "knight" is a component of the game, the distinctively skewed move of a knight is a ludeme of the class "rule of movement". But other types of ludemes also exist. For example, the name, referend and associated connotations of "knight" - those of a chivalric courtier - may be said to constitute a thematic ludeme.

At GDC 2005, Koster presented his vision of a grammar of gameplay, referring a lot to ludemes. For Koster, ludemes are atomic mechanics with at least 2 possible outcomes (e.g. moving a Checker piece to capture, prepare, or force the opponent to capture (which is actually a kind of preparation)), among which at least one is failure (even if failure only means closing some of the player's opportunity doors). Synonyms of ludemes are: verbs (Crawford), choices (Meier), or conflict. Each ludeme involves a UI action (e.g. pressing button). In terms of complexity, Chess is more complicated than Checkers because each of the 6 types of Chess pieces has its own movement and capture ludemes, while all Checker tokens have the same ludemes.

Bottom-up game design in practice

As Lopes and Kuhnen pointed out, designing games with a top-down approach is somewhat of a dark art when it's time for the designer to bridge the gap between the high-level concept (e.g. in terms of experience, emotions and feelings targeted to the player) and the routine tasks of the player (e.g. drawing a card, moving their avatar or attacking). Current game design textbooks such as Adams' Fundamentals or Schell's Book of Lenses, putting forward player-centricity, suggest a top-down approach by focusing on the experience the entire game should convey to the player.

But a player-centric bottom-up approach is also possible. I'm trying here to provide prescriptive rather than proscriptive steps. In the bottom-up process, the designer should ask the following questions:

• What are the elementary actions the player can do? (define the ludemes)
• How can these actions be fun? (feeling of latent power, fiero, schadenfreude, aesthetic pleasure, ...)
• What are the transitions between these actions? (for the ludeme "roll a dice", it is when the dice is rolling)
• How fun are the transitions? (surprise, feeling of progression)
• Sanity checks: how do the actions fit together as a whole? (pointing to shoot in FPS should not be followed by a dice roll, the intense mechanical ludemes of Doom should be matched with horror-aesthetics ludemes such as the lack of light, ...) Does the overall feel of the game match the feeling of all the elementary actions put together? (ludemes should add up, not negate each other)

This process is tentative, possibly flawed, and therefore feedback is most welcome.

21st Century Game Design - Part I

21st Century Game Design, by Chris Bateman and Richard Boon, 2005.

Part I - Games exist primarily to satisfy the needs of an audience

ch1 - Zen game design

Zen Buddhism can not be learned, it can only be experienced. There is no objective perspective on anything. Hence zen game design's tenets: game design reflects needs + there's no single method to design + there exist methods to game design. These methods are:

• first principles: what you want to do -> game world abstraction -> design -> implementation
• clone and tweak: most common method. existing design -> tweak -> implementation
• meta-rules: goal = provoking debate. meta-rules -> design -> implementation
• expressing technology: in teams without actual game designers. technology -> game implementation
• Frankenstein: art or technical materials -> design -> implementation
• story-driven: narrative -> design -> implementation

Participants in the game project: audience, publisher, producer, programmers, artists, marketing/PR, license holder. Example: saving for causal audience is vital; for hardcore audience, it should not break gameplay; for programmers, it's a technical detail; for producer, it's looking at how other games do it.

ch2 - Designing for the market

The commercial success for a medium clears the way for artistic expression, not the way around

A game design is successful when the target audience is satisfied. This justifies the need for an audience model. Existing models: simple distinction hardcore/casual, distinction by genre (but genres are too vague), EA's model, and ihobo's model.

Simple hardcore/casual distinction

hardcore	casual
plays lots of games	plays few games
game literate	game illiterate
plays for the challenge	plays to relax, kill time, and just for fun
segment can be polarized: many can buy the same title	hard to polarize, diverse and disparate

EA's model:

EA's model take-away: do not ignore hardcores because they are the ones pushing a game to broader segments. Corollary: no TV ads are needed if the game is not made for casuals.

iHobo's model:

Evangelist clusters = gaming press, mainstream press, and the 3 million of hardcores in the world. Target clusters = Testosterone (9M players worldwide), lifestyle (30M), and family (90M) gamers.

Design tools for market penetration (aka demographic game design):

• Looking for good gameplay (ie the game being performance-oriented, with stats, clear goals and victory conditions) vs good toyplay (unorganized). Hardcores are driven by gameplay, but lifestyle and family gamers are driven by both.
• Controls should remain accessible for casuals.
• The minimum play session length is usually expressed in terms of the duration of a level or the time between two save points. For casuals, it should be below 15 minutes, but hardcores do not mind core activities of a game taking at least an hour or two. Ex: a typical DotA match takes 45 to 60 minutes, whereas a (small size) Mine Sweeper can take less than a minute. Nintendo games are also famous for allowing the player to quit at any time and provide core activities of at most a few minutes.
• The average play session length is also lower for casuals: they may complete one level at a time, whereas hardcores can aim at 10 levels per play session.
• Play window: total time spent playing the game. The longer the play window, the longer hardcores will spend evangelizing the game. Therefore, despite most of the players not completing the game, content is crucial! The play window can also be extended by introducing hidden features, higher difficulty levels, variety in characters to play with (to increase replayability), and online PVP (although that only works for Testosterone and hardcore gamers).

Phases of penetration: taking the example of The Sims.

1. Hardcore penetration: the game needs challenge, progress, and depth.
2. Hardcore evangelism: the game needs to appeal to the Lifestyle gamer, easy to reach fun, strong marketing, and a strong license.
3. Casual penetration: the game needs fun, toys, short minimum play session.
4. Casual evangelism: the game needs to get the attention of the mainstream press.

ch3 - Myers-Briggs typology of gamers

Assumption: nature of games people enjoy and frequency of play vary with player personality and reaction to situations. The Myers-Briggs model was developed in the 1940s and indicates how an individual would prefer to react to situations in general. See the Myers-Briggs type frequencies in the US. Four pairs of traits:

Type	Opposite type	Game design
Introversion (50% of pop) think then act, needs private time, 1-to-1 communication and relationships	Extroversion (50% of pop) act then think, likes people, deprived when alone	Most games are played by introverts. Extraverts can take long breaks from the game, so provide a todo list for them when they come back to play, otherwise they'll forget what they had to do in their previous play session. Extraverts like DDR because of its performance aspect.
Sensing (70% of pop) live in the present, apply common sense, based on prior experience, likes clear and concrete info	iNtuition (30% of pop) live in near future, new and imaginative approaches, based on theory, comfortable with fuzzy information, seek for patterns)	Learning and problem solving are frequent gameplay elements in many genres. Learning: in tutorials, S will accept linear series of lessons, but N would rather guess by themselves. Problem solving: S will use trial and error, while N will like to use their lateral thinking skills. Therefore, make lateral thinking puzzles (at most) secondary objectives, or allow the player to progress without having completed all of them. Ex: Super Mario 64 only requires 30 stars to unlock new levels. S want simple and usual mechanics, while N won't mind having to guess the rules and a steep learning curve.
Thinking (30% of women, 60% of men) decide from facts and logic, objective, focus on task, think that conflicts are sometimes unavoidable	Feeling (70% of women, 40% of men) decide from emotion, subjective, focus on consequences to people, wish to avoid conflicts	Clear goals for T. Personal encouragement for F, but T may feel patronized. Solution: useful AND aesthetic/fun items are rewards that will satisfy both T and F. Gathering collectibles give goals to T, but should not be a grind. F are motivated and rewarded when they see their actions have impact on the world or other characters. T enjoy receiving critical feedback (a game over with tips), but F will take it personally. Ex: Zelda gives clear goals (good for T), falling or getting hit results in losing half a heart (and not instant death) and Link has an impact on the game world (good for F).
Judging (55% of pop) plan then move, single task at a time, ahead of deadlines, targets and routines to manage life	Perceiving (45% of pop) plan as you go, multitask, work better before deadline, avoid routine and commitment	J want to beat the game (get all the secret bonuses) and complete objectives. P want to improve their abilities, and enjoy the process. For P, goals completed = feedback that they're on track. Non-linear structure is good for P because if they don't like a level, they can try another and keep progressing. J needs to know what to do to progress. Ex: in Tony Hawk or GTA, players need to collect points (good for J) but they can collect them the way they want (various kinds of skate figures or driving/killing missions or sandbox play, good for P).

TJ vs FP: TJ want challenges to overcome (what most current games provide), FP want easy fun (cf Sims or casual games).

Study hypothesis: hardcore player is a 14-28 year old tech savvy male who plays up to 8 games per month. Supposedly, he plays on his own (hence I), is methodological, goal-oriented enjoys conflicts (T), plays games until completion and looks for perfect score/overachiever (J). Previous quantitative work from the Bartle test by Andreasen showed the average hardcore MMO player is IST. Therefore, let's suppose hardcores are IT. Overall, 15% of women and 35% of men are of type IT.

ch4 - DGD1

DGD1 is intended as a tool to aid in market-oriented game design.

Methods: between 2002 and 2004, ask 408 participants (incl 122 women) to answer a 32-question Myers-Briggs personality test, as well as questions on purchasing and playing habits, and do you consider yourself hardcore, casual, or no idea?. Only look at people who play at least one game per year. Survey advertised on hardcore and casual websites/game portals + university students.

Results: clustering gave a sketchy and incomplete result, and FE and SI dimensions did not help to cluster, but 4 clusters appeared anyway: conqueror (TJ), manager (TP), Wanderer (FP), and participant (FJ). Hypothesis rejected: hardcores are found in E and S (and not only I and T). Still, I and N are higher for hardcores and MMO players than casuals. For each of the four types, twice more respondents reported they were casuals than hardcores.

The DGD1 demographic model

Type	Hardcores Desc	Casuals Desc	Progress	Story	Social
Conqueror	ITJ. Want meaningful challenges, strategies and puzzles, want to complete the game. Want lots of content, try to beat themselves. The game is too easy if they don't die at least a few times. Anger, frustration, boredom, and fiero.	ISTJ. FPS and racing games, they play to compete and win. Rely on genre conventions and do not like deviations from the genre. Fiero (although it's oblivious to them) and schadenfreude in PVP, or in GTA for rampages	Rapid advancement: stats in RPG, better gear in FPS	Focus on plot twists/events, not on characters	Online: vocal hardcores from forums and blogs. They also like to win discussions
Manager	ITP. Strategy and tactics. Winning is less important than mastering the game systems: process-oriented, not goal oriented. Conquerors consider them rivals and targets. Patient. Look for challenging but not impossible. Don't look for hidden features but rather refine their current knowledge. Fiero. Civ series.	ISTP. Want familiar settings and realism. Like construction and management games like SimCity. Hate being stuck even if they suck. Hate interruptions and like smooth difficulty curves.	Steady. Give up if no reliable strategy is found quickly.	Plot, not characters.	None?
Wanderer	INFP. Easy fun and toyplay, not challenges. Variety keeps the fun going. Complete levels in aesthetically pleasing ways. Cf Puzzle Bobble/Bust-a-Move: simple controls, bright colors, and actions with direct and satisfying changes to the environment. See also Mario Party and Super Monkey Ball. Need to be able to give up the current task for another different task. May turn to Conqueror or Manager relatives for help. Emotions: finesse, aesthetics, wonder, awe and mystery, but no fiero.	ENFP. Want to accomplish something in the game world without the need for challenges. Games = way to relax. Feeling of progression or else boredom. Lack of market vectors to reach them [although nowadays there's Facebook]	New toys, colorful and imaginative environments	Emotions. Empathy to characters or investment in world/immersion.	Talk about what they like but avoid arguments
Participant	FJ. Games as social entertainment. Cf DDR, The Sims. Little survey data about this group.		Narrative of group of players	Characters and emotions, but in control of them, not just spectator.	Multiplayer, but must face other players in person, not just online (no MMO)

ch5 - Player abilities

Flow = subjects believe they can complete their activity. Subjects have clear goals and direct and clear feedback. Effortless involvement. Goals should be short-term for participant and conqueror, but long-term for Wanderer and manager because they like to figure out the short-term goals themselves.

Caillois' table of the four categories of play helps understand how flow is related to toyplay. In the table, there really is a continuum between Paidia and Ludus.

The relation between the four play styles of DGD1 and Caillois' categories of games

Conqueror Agon	Manager Agon (Alea tolerated)
Participant Mimicry	Wanderer Mimicry (Alea tolerated)

Caillois' table of the four categories of play

-	Agon (competition)	Alea (chance)	Mimicry (simulation)	Ilinx (vertigo)
Paidia (spontaneous play)	Spontaneous races	Counting out rhymes, coin flipping	Masks and disguisement	Children whirling, swinging
Ludus (structured play)	Sports	Betting, lotteries	Theatre	Skiing, mountain climbing

People with high Myers-Briggs Feeling scores prefer avoiding conflicts, therefore they don't like Agon. They're also more likely to like Mimicry since they focus on people. For example, Wanderers appreciate finesse, which is a component of Mimicry. Ilinx resembles immersion, it appeals to everyone.

Temperament theory gives patterns of behaviors, while Myers-Briggs gives patterns of perception or judgement.

Temperament theory

Temperament	Core needs	Myers-Briggs traits	Skills	% of pop
Rational	Knowledge, competence	NT	Strategic: Think and plan ahead, identify the means to achieve a goal, coordinate actions strategically	10%
Idealist	Unique identity, search for meaning and significance	NF	Diplomatic: Resolve conflicts while recognizing individuality, empathy, find similarities through abstraction	15%
Artisan	Freedom to act and ability to impact	SP	Tactical: Read the current content and manage the situation, work out the next step and take action, improvise to overcome problems	25%
Guardian	Belonging and sense of responsibility/duty	SJ	Logistical: Organizing and meeting needs, optimizing and standardizing, protect and ensure safety	50%

Temperament, Myers-Briggs and DGD1

Type	Myers-Briggs traits	Hardcore temperament trait	Casual temperament trait	Flow provenance	Examples
Conqueror	TJ	strategic	logistical	Capacity to see in advance how to address problems (strategic) and iterate/repeat to improve/optimize the solution (logistical). Willingness to fail and repeat	Production of units in RTS, monsters or bosses with patterns (cf Doom monsters)
Manager	TP	strategic	tactical	Planning ahead (strategic) and reacting to rapidly changing situations (tactical). Hardcores like to get lost in their thoughts, ideally without time limitations. Casuals have flow in the action, and need short-term goals.	RTS have both spontaneous maneuvers and long-term strategies. Civ, Chess or puzzles for hardcores.
Wanderer	FP	diplomatic	tactical	Immersion, explicit short-term goals (tactical). Completion of goals is not a big thing, it happens almost as a side-effect of exploration. Give them time to explore.	Platformers (goal is obvious and challenges relatively easy)
Participant	FJ	diplomatic	logistical	Feeling of belonging, toyplay, optimize relationships (logistical) with other characters or players, immerse themselves in social situation	The Sims, Animal Crossing

Casual audience is best approached with familiar settings and content, and with gameplay that revolves around optimization or thinking on your feet (tactical). Hardcores prefer original games that give them a sense of identity (diplomatic), and problems to solve (strategic), e.g. Final Fantasy focuses on story and strategic battles.