Archive for the ‘Uncategorized’ Category

Mastering Dart by Sergey Akopkokhyants – Book Review


Summary 3 out of 5

Mastering Dart CoverThere are not many Dart books published yet but there is some good information collected in this book. I disagree with some of the content, but chapters are a good length and have decent summaries.

I would recommend it only for experienced developers that are healthily skeptical about things claimed to be “good practice” and “high performance” throughout the book.

To be fair the blurb on the site also warns it requires some experience, but I surmise for different reasons.  The book feels like it is imposing Java and enterprise ideals on Dart. Dart does not need all that baggage – even if the language itself enables it. To an impressionable mind this book could encourage some poor engineering choices.

For example it uses object composition examples based on real life concepts – an inexperienced programmer might take that literally… modeling for real life rather than for how data is best represented and manipulated. There are no warnings about the cost of using reflection, how either type of optional parameter makes life harder for Dart and Javascript VMs, costs of object instantiation or the different types of function calls presented. There are many places throughout the book a novice could be mislead down a very poorly performing path.

There are English language errors throughout. Catched rather than caught, angel rather than angle. There are a few phrases that sound conversational and a little out of place. It sometimes made reading a little jarring.  I believe these issues could be solved with another editorial pass, but this version lacks polish.

The book redeems itself back to three out of five when the reader has confidence to ignore the overtly enterprise style code. The language features and packages presented in later chapters were more useful.

I have an e-copy of the book from Packt and read it entirely on a Kindle Paperwhite.  The main text was typeset quite nicely and with the smallest font on my Kindle Paperwhite the code samples mostly fit on single lines.

Disclosure: I was given a review copy by Packt:

Let me introduce you to Gameduino


What is a Gameduino? It is an Arduino based gaming device that is a mixture between a science experiment and a classic gaming micro. It provides the kind of platform I grew up with (Oric-1, Acorn Electron, ZX Spectrum, C64, etc.) but with modern touches (USB, VGA, coprocessor).

I supported the Gameduino Kickstarter project and my reward was recently sent to me by the creator of the project, James Bowman. The community around this device so far is small but friendly. It includes electronics and programmers buffs from all kinds of backgrounds.

The Kit

One of the things that struck me when I first opened the box was how exposed everything seems! At some point I would like to either buy a case or mod something to hold the device; but as I have just moved from the UK to the Austin area in to a little apartment, I do not have the tools to fashion something myself just yet.


Here you can see the interfaces of the board. The ArduinoUno has a connection for USB and another for power. The Gameduino board provides a VGA connection and audio jack. The final board is a Joystick shield from SparkFun.


I put a pen in shot to give a sense of scale to the pictures.


The boards communicate to each other via pins and slots which can be seen in the picture above. The shields are designed in such a way that plugging things in the correct way feels natural. On my kit, the audio jack and USB are stacked directly in a way that makes it impossible to push the board all the way home; however, the pins are long enough that it does not matter.

After I constructed the device, the next thing I wanted to do was sit on the sofa with it and play on the television. After asking a few questions on the Gameduino answers forum I decided to try and use sixteen feet of VGA, USB and audio cable. I skipped buying a power supply as my television has a USB port – so I could buy a USB extension cable that is cheaper, less bulky and more generally useful.

Despite the length of the cable and low power draw of Gameduino, it works nicely (well for me anyway!) over that distance. So when playing the Gameduino, it only needs to be connected to the television – though granted via three cables. During development I use the laptop USB for both power and data transfer, while the TV acts as my screen.


Above you can see the boot screen of the Gameduino (which is on the right side of the Kinect under the television). It also plays a nice chord on startup.


ArduinoUno (source)

Processor ATmega328 8-bit microcontroller
Clock Speed 16 Mhz
Flash Memory 32KB – 0.5KB used by boot loader

Gameduino (source)

Resolution 400×300 – Compatible with any standard VGA monitor (800×600 @ 72Hz)
Color 512 colors, processed internally at 15-bit precision
Background graphics 512×512 pixel character background. 256 characters, each with independent 4 color palette. Pixel smooth X-Y scroll (wraparound)
Foreground graphics Sprites are 16×16 pixels with per-pixel transparency. Each can use 256, 16 or 4 colors. Four-way rotate and flip. 96 sprites per scan-line, 1536 texels per line. Pixel perfect sprite collision detection.
Audio Stereo. 12-bit frequency synthesizer. 64 independent voices 10-8000 Hz. Per-voice sine wave or white noise. Sample playback channel.
Memory 32 KB – addresses are 15 bit, last bit indicates read or write (via SPI interface)
Coprocessor J1 Forth CPU. 16-bit internal bus, 8-bit memory interface. 50 MIPS. Direct access to entire Gameduino memory. Executes code from set 256 byte range. Machine instructions very close to Forth. Single-cycle 16×16 bit multiply, plus barrel shifter. Fast, efficient stack machine.


I wanted to get back to basics a little bit. My favorite language these days is C# but for a long time it was C++.

I believe constraints can force creativity in some interesting ways. Necessity is the mother of invention after all. The Gameduino is constrained with its specification, though has many interesting quirks I look forward to learning about. For example, the co-processor needs instructions in Forth!


Practicing skills and learning new things is always more interesting when trying to accomplish something rather than just going through exercises. I plan to have a little game of my own running on it in time. I have not got that far yet, but below is a sneak peak.


Jan Boon has written an excellent emulator “gdemu” that provides a pretty good simulation of the hardware that has been allowed me to develop in Visual Studio without deploying to the Gameduino each time. I forked it on google code, but as I am also teaching myself git and git flow I imported that over to github.

I have started to get used to the processing based environment provided for Arduino. Projects are called sketches and basically include all the c/c++ source and header files in a folder. It is an IDE that provides a way to compile and upload your program, plus serial monitor which is helpful for sending debug messages. I do not think there is a way of stepping through code on the device without more hardware though.

My aim is to try some test driven development with the Gameduino now I have explored it a little. Ideally I would like my own project to be built and deployed to the device via a single line on the command line or a double click of an icon… I am not there yet though.

If anyone has any Gameduino projects to share or has worked on similar devices, please say something in the comments. It would be nice to know that people are reading this!

Further Reading

Gameduino site




Micro Talks


This is a quick write up of my thoughts about the micro talk format, its use in Lionhead’s "Creative Day" and the talks organized by IGDA Austin held at historic Studio 6A (home of Austin City Limits show).

The "Micro Talk" format

Every participant is given ten minutes to talk. A time keeper near the front of the stage flashes up cards when the speaker is near the end of their session so they can wrap up the talk. There is also a longer message for when a speaker goes over that limit.

There are variations where the time limit is less strict.  Sometimes there is a defined period of time for Q&A that may be filled. I recall as part of my Bachelors degree we had strict time limits and a QA for presentations on projects; so those from an academic background may be familiar with this style already.

Ten minutes is time enough to cover a large subject at a very high level or a very specific topic in detail. This forces focus and sets the pace for all the talks.

For the speaker ten minutes should be relatively easy to fill about something they know about. If anything, reducing things down to ten minutes may be an issue.

For the audience ten minute bite-sized chunks of content should be digestible even if it is something individual members have little interest in.

Creative Day 2011 at Lionhead Studios

A similar format was used for Creative Day at Lionhead Studios.  We did not use the term “micro talks” but that is what the format was at the core (though without the very strict time keeping). Everyone who participated was given a short time to introduce their project and demonstrate it. Some ran under and some ran over but every presentation got part or all of the audience interested. Each team was given a couple of days of studio time to complete their own project (and as much of their own time as they wanted of course).

The Lionhead event has been quite well covered in the industry press. The project I worked on was one of the lower profile ones that just gets a mention in Edge. I worked with developer Pete Coward and musician Kai Chi Chan on a reimplementation of Populous in HTML5, which used a multiplayer server implemented using node.js.  Our proof of concept was implemented in a few days.

The demo itself had a few technical problems due to us trying to improvise a wireless network.  It got a bit overwhelmed by a cinema full of developers trying to connect to it with laptops, iPads and mobile phones… but overall the presentation was well received and the multiplayer capability was demonstrated. We kept things going long enough to show Peter drowning little people by lowering some land in to the ocean, which got a good laugh.

It was an emotionally charged experience presenting to all the talent of the studio – especially considering some of the mind blowing things that were demoed before we were up.  Keep in mind that most of the people presenting were not at all used to being in the public eye. In the relatively safe environment of that cinema full of colleagues, everyone shone. Every single presentation had something interesting to give and add to the day. People really got to know each other better that day.

If IGDA Guildford ever gets going again – meetings in this format should happen.  There are enough people working there to support it!

IGDA Austin Micro Talks (2011-06-25)

My first IGDA Austin meeting was in the micro talk format and provided a great introduction for me to some of the people in the chapter.  The talks took place in a television studio and were recorded – so should end up on YouTube at some point in the future.  See the website for further details.

John Henderson acted as master of ceremonies, introducing each speaker and announcing breaks between the speakers. At the end of the breaks he took the opportunity to introduce some of the volunteers around the hall that were running the event.

Jon Jones opened up the evening with a talk about making yourself more attractive on the job market by differentiating yourself. His example used a character artist portfolio with a few stereotypes that got laughs from the audience. The drive of the talk was to be a little different by thinking creatively and to actively network. Many of his own career advances had come from networking and he said that he pushed himself to get out there. He made special note to try not and make enemies, as you never know how that will come back to bite you later.

Denis Loubet made a presentation about how much luck there is involved in creating a profitable iPhone game. He made his presentation without aid of slides. The message I took away from that was that it was better to prototype an idea and ship early before investing too much, as you can never be quite sure where lightening will strike. Rovio made a few games before their success with Angry Birds.

Sara Jensen Schubert’s session was about using a spreadsheet to balance progression in an RPG. Consistency was highlighted as an imported factor in progression. Second to that was modeling enemy stats close to that of the player to make things easier to manage later on. It immediately reminded me of systems I had seen used around Lionhead that our tools supported. I think Sara and my friends back in the UK, Mike West and Kalev Tait – would have a good talk about their various ideas for balancing.

Fred Schmidt made the case for how awesome Austin is, the history of the area and how the creative industry fuels the economy. There needs to be more engagement across the educational, public and private sectors to better support the many small companies doing amazing things in the area.

Damion Schubert spoke about the power of innovation – where it is useful and when it should be reined in. Innovation can take many forms, from simplification of an idea to something completely new. An innovative game should be explainable in a sentence and have true resonance with the audience. Swing big, make sure the players get to use your innovation and support it through every other element of game play. Remember that an idea is only innovative if it is better, and that it should be less expensive than making a "me-too" product.

"From Startup to Survival" by Quoc Tran was an interesting study in what can make the difference between success and failure in a start up. It boiled down to focus, underdo the competition and release early. Remember that resources are limited and that if cash is a problem, ship sooner. The feedback generated and market position achieved by shipping sooner is more important than a complete feature set.

Carl Canga made a presentation about how important investing for retirement is. Despite the presentation slides not working, Carl went on to make a well rehearsed presentation. It was certainly a sobering talk for me and something I will make a priority as soon as my means allow it.


Presenting and demonstrating things in front of an audience even just for ten minutes may seem daunting but there is no doubt in my mind it is worth it. It is a great introduction to public speaking and one I personally intend to try again. I encourage you to try it out – either at your studio, an IGDA meeting or wherever you can.

The conversations during the breaks at events like these are also invaluable. It is a great way to make friends and eventually introduce people who can help each other out. Get yourself out there!

Never under estimate how important it is to communicate the knowledge you have to other people. What you write or present will never be useful to everyone – but even if you help a few people out, it is worth it.  Why not try writing for #AltDevBlogADay?

About this article

I wrote this in Star Coffee in Round Rock, TX while slowly drinking an iced mocha. It is written from my own notes made in OneNote last night and some others that Danni (my wife) made. While writing this I’m listening to a Blue Grass jam session. I’ve only been in the Austin area for a few weeks – and although I am still adjusting to the baking hot weather it has been a good experience so far. I have no doubt that this place is another great creative hub.

This post was created for AltDevBlogADay:

The XmlSerializer class in C# is asymmetric


C# coders choosing XmlSerializer for their game data beware.  When using the DefaultValueAttribute on members of a class being later processed by XmlSerializer, a perfect copy of an object written may not be read back later.  This post demonstrates the behavior.

XmlSerializer versus DefaultValueAttribute

The DefaultValue attribute is useful for giving hints to the user interface controls, particularly ones that inspect objects such as the PropertyGrid.  It allows objects to be created using their  default constructor then have their default value set later by the control responsible for it.

The XmlSerializer also takes this value in to consideration when writing an xml representation of the object.  If the class member being serialized has a value that matches the value declared by the DefaultValue attribute it skips writing the value all together.  Less written, less to read back – looks good.

XmlSerializer does not restore the value of DefaultValue to a member when reading an xml representation of an object, it uses the default as defined by the member type (null for classes, 0 for integers, etc.). This is the potential source of confusion; you cannot rely on the XmlSerializer to create perfect deep copies of your objects. It does not assume missing xml means “use the default value attribute”. XmlSerializer has implicitly set the expectation on your code to restore the default values from the attributes.


I have embedded commented code in the post below that demonstrates the above.  I have also uploaded it to github.

// See Clue class to change demo behavior.
// Uncomment one of the fixes below to observe different behaviors.
// Search for FIX1 or FIX2 to see where the changes have been made.
//// #define FIX1  // Do *not* use DefaultValue attribute, taken in to account serializing but not de-serializing.
//// #define FIX2  // Set default value of variable to same as DefaultValue attribute during construction.

namespace AsymmetricXmlSerializer
    using System;
    using System.ComponentModel;
    using System.Diagnostics;
    using System.IO;
    using System.Text;
    using System.Xml;
    using System.Xml.Serialization;

    /// <summary>
    /// Class to be serialized and demo point for asymmetric XmlSerializer behavior.
    /// </summary>
    public class Clue
        /// <summary>
        /// Comment out DefaultValue attribute and it will succeed.
        /// </summary>
        /// <remarks>Set variable to 'Nothing To See Here'to to work around.</remarks>
#if !FIX1
        [DefaultValue("Nothing To See Here")]
#if !FIX2
        public string text;
        public string text = "Nothing To See Here";

    /// <summary>
    /// Demo program for asymmetric XmlSerializer behavior with DefaultValueAttribute.
    /// </summary>
    internal sealed class Program
        public static void Main(string[] args)
            // If initial value is the same as DefaultValueAttribute for variable declaration,
            // it is not persisted by XmlSerializer.
            Clue clue = new Clue();
            clue.text = "Nothing To See Here";

            // Buffer for writing.
            StringBuilder buffer = new StringBuilder();

            // Don't need namespaces.
            XmlSerializerNamespaces no_namespaces = new XmlSerializerNamespaces();
            no_namespaces.Add(string.Empty, string.Empty);

            // Don't need xml declaration.
            XmlWriterSettings writer_settings = new XmlWriterSettings() { OmitXmlDeclaration = true };

            // Serialise the clue...
            XmlSerializer xml_serializer = new XmlSerializer(typeof(Clue));
            StringWriter string_writer = new StringWriter(buffer);
            using (XmlWriter xml_writer = XmlWriter.Create(string_writer, writer_settings))
                xml_serializer.Serialize(xml_writer, clue, no_namespaces);

            string serialized = buffer.ToString();

            // Show serialised version of the clue...
            Console.WriteLine("Clue text value: {0}", clue.text);
            Console.WriteLine("Clue serialized: {0}", serialized);

            // Deserialise the clue...
            Clue clue_read;
            using (StringReader sr = new StringReader(serialized))
                clue_read = (Clue)xml_serializer.Deserialize(sr);

            // Show clue 2 on console
            // Reset and reuse write buffer.
            buffer.Length = 0;
            using (XmlWriter xml_writer = XmlWriter.Create(string_writer, writer_settings))
                xml_serializer.Serialize(xml_writer, clue_read, no_namespaces);

            string reserialized = buffer.ToString();
            Console.WriteLine("Read Clue text value: {0}", clue_read.text);
            Console.WriteLine("Read Clue serialized: {0}", reserialized);

            Debug.Assert(clue.text == clue_read.text, "Written & read clue's text should match");

 * FIX1: Don't use DefaultValueAttribute.
 * You would want to use DefaultValueAttribute to avoid persisting the
 * default value to the xml representation.
 * Although this does prevent the default value being persisted, on read the
 * DefaultValueAttribute is ignored so the value is never set to that of
 * the DefaultValueAttribute.
 * DefaultValueAttribute is also used for value hints for UI.
 * See:
 * FIX2: Use DefaultValueAttribute AND default value at construction.
 * To use DefaultValueAttribute and have the object be recreated
 * properly when reading it back, you must to explicitly set the
 * default value during construction of the object being read.
 * Using this method means the xml is concise and the object
 * is accurately recreated.

(Cross posted from: )

(Audio Post) Round Table: DLC


I decided to gather a few friends from around the studio to informally discuss downloadable content around a table over lunch. This is the first time I have tried anything like this so please keep that in mind! This is all personal opinion too, not that of our employer.

High level summary of what we discussed:

  • What is your favorite DLC & why?
  • Is DLC on the disk ethical?
  • Discussion around DLC pricing.
  • How can DLC effect game balance?
  • DLC and player status.

The voices you hear in order of appearance:

Thanks to everyone who took part. Special thanks goes to my wife who spent some of her time over the weekend post-producing this. Should I try this again with any luck I will do a better job with the advice she has given me.

Update: The original audio files linked have been updated. Michael Taylor @stomp224 (Audio Designer) kindly offered to clean up the audio some more. Find him at

As with Mike Acton’s audio posts, this comes with no warranty, transcription or satisfaction guarantee!

Orignally posted on #AltDevBlogADay.

Round Table: DLC (Part 1 of 2)

Round Table: DLC (Part 2 of 2)

Do or do not


Assertion is a valuable tool that many languages provide, but recently I have come to think it is used too much and in the wrong places.  I put forward the idea that asserts should not be found anywhere in the main body of your code.  Permanently burying asserts deep inside your code could end up causing more problems than they seek to solve.  Asserts embedded in methods  are useful while debugging, but should rarely be committed to source control.

I extend this thought to other defensive practices like checking for nulls indiscriminately – even where there never should be one.   Sanitization of external data is prudent and necessary, but once things are safely inside your own codebase you have control of the expected range of values and should be able to trust that.

What an assert does

An assert stops execution and flashes up a message when a condition fails.  If there is a debugger attached then if it can it will direct the programmer to the source where the assert fired.  Great for the programmer trying to track something down, rubbish for someone else who has to skip the message (perhaps many times) to do what they are trying to do.

Asserts disrupting workflow for other programmers and disciplines have been mitigated in a few ways.  The following are some more common methods:

  • Builds with asserts turned off
  • Asserts with a concept of levels or categories that can be toggled
  • Assert instance toggle – it will appear once but as well as skip there’s an option to ignore

Crying wolf

Asserts that continually fire create too much noise; unless the game completely falls over then people start to not take any of them seriously.  Just like compiler warnings there is a point where many eyes just glaze over the number and a number above zero becomes an excepted part of life… perhaps even becoming a joke.

Do or do not, there is no try

Yoda: 'Do, or do not!  There is no try'.

Asserts show a lack of confidence of an operation being successful – so much so that a human being should be warned.  It is a developer communicating with themselves and others that at some point something is in a state so dire that normal execution must be interrupted so someone can take a look.  I do not believe having that kind of warning permanently buried and hidden is healthy.  It is preferable to either formally test and handle the situation if it really is expected, or get to the real root of the problem and prevent that invalid state from ever occurring.

Sanitize the data once properly rather than repeatedly sanitizing the same data in the same way throughout the program just in case.  Every time a conditional statement is encountered there is a computational cost associated with that.  A code block could have its own setup and destruction costs – perhaps more so if exception handling is being used.  This may seem like premature optimization but clear concise code is easier to digest for man, compiler and machine.  After all the best kind of processing is the processing you can eliminate – look to improve your algorithm.

Asserts in the middle of a method after a long conditional block could indicate that the method could be broken in to smaller more focused testable methods.  If possible architect so that a method will always succeed in some measure to allow callers to expect the same predictable outcome.  If a function should always return a populated something, use a default something rather than null.   For example use a valid bright pink texture for missing data and log the error rather than just returning null and forcing everything from that point on to check for nulls.

Silent but deadly

A badly written assert may cause a side effect as part of testing the condition perhaps without the programmer even realizing it.  When an assert like that is disabled it causes different behavior between types of builds.

Worse is when an assert expects to be heeded in the same way as exception.  Ignored or absent through compilation options, execution blunders on and states become corrupted, going on to cause unpredictable problems later.  Perhaps that problem will even mask itself as an issue with a completely unrelated system.   In the worst case corrupt data could be persisted, ruining a saved game.

Asserts encourage a codebase that constantly tries to correct itself rather than addressing the real problem.  Methods no longer trust each other to fulfill their remit.  Expectations of callers change from “I should only give it foo” to “I can give it foo, bar or nothing at all”.  Those expectations can virally spread throughout the codebase causing more methods to second-guess each other and bloat.

The truth is out there

Earlier I stated that asserts in the main body of code shows a lack of confidence and are used to try to mitigate bad states.  Used in the context of test functions they serve to communicate an expectation of success.  The tests can be run independent of running the game or application itself and provided with sample of runtime data to consume.  Instead of the same assertions being made in multiple places against the same method scattered across the codebase, an expectation for a specific scenario can be stated exactly once.

Asserted expectations can be gathered in a test suite to form a living document in code that provides examples of use that are easily found.  Compile time can be quicker for coders because tests can be separated out in to different projects – run only during the testing phase of a change and on the build machine.


Asserts in the main body of your code clutter the logic and could be expressed more concisely elsewhere.  Programming too defensively could blur the responsibility of what is being written.  Do not always code “just in case” otherwise callers will start to rely on the defensive parts.  Either set the expectation of a method to always sanitize (and perhaps hint at that extra processing in the name) or fail as gracefully and quickly as possible.  Methods have to be able to trust each other.  Many applications and games are closed systems that have predictable points of failure, only the input from the boundaries should be considered for sanitization.  Failed asserts should be a point of immediate failure – though I would argue there are better ways of indicating failure.

Asserts are very useful for debugging, but be wary of the costs of permanently committing them to the main body of your source code.  Logging error messages and substituting inert values can be far less obtrusive then relying on asserts breaking execution and popping up message boxes.  It is outrageous for a tool that is supposed to run unattended to stop everything waiting for input, just fail and exit.

Asserts do belong in source control when used to formally test methods and when they clearly express specifications.  This kind of living documentation created by asserts is a form of cover fire.  If you cannot separate asserts in to formal test methods to create clear behavior specifications, try and gather them together close to where the bad state will first occur.  Group them close as possible to where an errant call could first appear on the stack, rather than scattering the expectations around deep in the code.  Let the developer see everything that is expected at a glance.  Asserts should help avoid detective work after all!

There are many advantages to taking asserts scattered through your code and creating test suites from them – see my previous article Cover Fire for Coders.

Further Reading

Some other related #AltDevBlogADay articles about debugging and asserts you might be interested in:

Some books you might be interested in:

McConnel, Steve (2004).  Code Complete – 2nd Edition.  Microsoft Press.  ISBN: 0-7356-1967-0 UK Amazon FlagUSA Amazon FlagCA Amazon FlagDE Amazon FlagFR Amazon Flag

Chapter 8 covers the split between debugging tools and effectively handling failure in production code.  It supports quite some things that I advocate in this article in a much more detailed discussion.  One of my favorite quotes from the chapter: “Sometimes the best defence is a good offense.  Fail hard during development so that you can fail softer during production”.

Keith, Clinton (2010).  Agile Game Development With Scrum.  Addison Wesley.  ISBN-13: 978-0-321-61852-8 UK Amazon FlagUSA Amazon FlagCA Amazon FlagDE Amazon FlagFR Amazon Flag

This book covers how spending time eliminating technical debt can help create a more predictable schedule and end up with a more focused, polished game.

[Paul Evans is a central technology programmer at Lionhead Studios.  He has worked on the Fable II, Fable III and other unreleased titles.  You can find him on Linkedin, see other things he has written on his personal blog, and follow him on twitter.  Everything in this article is Paul’s opinion alone and does not necessarily reflect his employers views. Copyright ©2011, Paul Evans.]

(Originally posted for #AltDevBlogADay)

Cats have nine lives


(Originally posted #AltDevBlogADay)


“Oh no I died again!” – not something you generally get to say in real life is it?  Yet gamers readily accept death as a temporary failure state – just a blip towards achieving their goal.  Death has been abstracted in games in many varied ways over the years and in some games abstracted away completely.  It has been used to provoke emotion, to punish,  to teach, to up the stakes or just to increase a score.


But the cat came back the very next day…


Arcades with video games and pinball machines are quite rare now in the UK (now they are full of fruit machines) but are still a good starting point for looking in to players’ lives in games.  Lives in Pinball are represented by identical silver balls – a limited resource per game.  A player may start with three balls and might even win extra balls but eventually the game will end with a score.  Score is used as a measure of success across all of your lives, with each finite reincarnation another chance at increasing the net accomplishment.


Space Invaders sees the player’s ship explode and be replaced with an identical clone  a limited number of times.  PacMan actually shrivels up in to nothing and makes a pitiful whining noise as his little spherical body implodes at the touch of Inky, Blinky, Pinky or Clyde… but another identical PacMan takes his place.  These games are over thirty years old but the themes of credits, lives and scores still permeate throughout modern games in all sorts of disguises.


This kind of death and credit system is useful to monetize failure.  Want to see more of the game?  Well okay then… you have ten seconds to cough up the money and we will let you see some more.  If you do not come up with the money then back to the start for you!  Progression therefore will cost you, mastery of skills and patterns only earned after costly failure.  Is it worth antagonizing a player with this kind of death in games that are not pay-per-play?


Mario and Sonic teach via death.  I cannot believe that these games were designed so that a brand new player could get through the entire game without learning through a fatal kind of trail and error.  Punishment for death can increase from the arcades where you can always bribe your way through a section, because in some games you pay in time instead.  After dying a few times in a row the punishment goes from a pained animation to having to restart an entire area – taking away hard fought progress from the player.  While some players thrive on this type of this type of challenge I would argue this action can be demotivating.  Only a certain kind of player continues on to conquer this, others will just walk away in frustration.


‘Splosion Man has death but you just bounce right back in a glorious  splodey sentient cloud of insanity.  The game has levels and stages to clear and it is not possible to save your progress in the middle of a stage.  The game does offer the player an option to skip to the next stage if you die in a section too many times in a row.  So a frustrated player can skip forward to see new content and get some sense of progress.  I never took up the option… too much gamer pride.  But I did hear something about a pink tutu you have to wear in the next stage if you do!


Games with lives and credits often also keep score, either in terms of points or fastest times.  They promote competition through leaderboards, with players trying to out do each other for bragging rights.


If it bleeds we can kill it (apart from if it is the player)


There is a snowy mountain path continuing to the NORTH.  To the SOUTH a noisy group of villagers carrying flaming pitchforks are closing in on your location.  They all seem kind of angry.  Well apart from the springer spaniel that is wagging his tail furiously.  He seems to think this is the best walk ever.




You tripped over something and fell off the cliff, a whooshing sound fills your ears followed by a very nasty crunching noise.  Breathing heavily and looking up you see the villagers standing where you were laughing.  One shouts down to your broken body “enjoy your trip?”  Another takes your INFRARED SUNGLASSES that fell from your pocket before your tumble and puts them on.  “OOOh INFRARED SUNGLASSES, I’ve always wanted a pair of these! I’m seeing red… oh look at that INVISIBLE TRIP WIRE across the path!”  Rolling your eyes, you promptly expire.




If only the player would have typed USE GLASSES.  Ah well.  It was all great playing that text adventure until you died, then you had to consider if you really wanted to play through all *that* again.  It is like not being able to cheat in a “Choose Your Own Adventure” book.  Part of the reason I like Monkey Island II so much was that you could not get in to that situation.  Sure you could get stuck, but Guybrush could not die (but could certainly embellish the stories he told about it).  The lack of death (but the presence of peril) made the game a very accessible adventure game.


In Fable III, you get knocked down, but you get up again.  There is a price though; you get scarred up and you could lose some experience towards your next guild seal.  This cosmetic toll is unbearable to some – I have known people to quit to the dashboard to avoid the auto save kicking in and saving their character in a knocked out state.  Of course others play well but get knocked out on purpose… because scars are cool and perhaps they like the villagers making negative comments about their looks (just another reason to take the safety off).


The player in these games has one life that is constantly threatened but never ends.  It gives a player license to experiment without fear of a sticky end.  Games where the player cannot die often focus on telling a story rather than keeping score.  They might also have to fight against the perception of being “easy”.


Ouch that really stings


There are a breed of games where death is both an inconvenience and a common occurrence.  Gone are the limits on lives and credits.  A player can retry many different things in different ways without fear of being sent back to an arbitrary check point a designer decided would be a good place to start again.


In Braid, everything fades and pauses… whoops better rewind time to before that death happened.  No penalty really, unless the backwards noise really grates against you.


Crackdown and Bioshock have the concept of clones… so just like Pacman and the hero’s ship in Space Invaders there is always a new vessel for a player to jump in too.  Though in Crackdown & Bioshock the effects of the previous clone are still present in the world.  You literally are a player clone army and in Crackdown II there is actually an achievement rewarded for finding all the ways an agent can die.  Death then can be its own reward.


Demon’s Souls adds a community aspect to death.  Death can come completely out of the blue but blood stains can be used to communicate to other wary players what is in store for them – death is a form of shared learning experience.


Limbo sees the little boy avatar you control dying over and over again with very little game penalty.  I take it back, the deaths are really quite disturbing and stomach churning though I’m sure there are those reading that just think it is funny!  Heck it is probably a good way of acclimatizing to that kind of horror.  Each death is over so quickly and so little ground is lost that it hardly costs any player time at all to die.


These games attempt to limit the frustration of death by placing the player close to the point of failure.  They dust off the player and say “have another go, try something different”.  Many of these games want you to complete them and know that some of the challenges they offer are tough.


No you really are dead


Something that computers and home consoles can do that I have not known in the arcades is the game save.  A precious area of memory where a player can save their progress through the game and return to it at will.  This allows the paradox of a player dying and a game ending, yet able to return to a certain point of time before that happened.  Kind of like Ground Hog Day, where the entire world in unaware that all this has happened before (and all this will happen again).  The player though has hopefully gleaned some knowledge to progress past that sticky point, so perhaps after x amount of times it will actually happen differently!


The downside of this is that the game does not know you played through a section either, so if there are any sections of non-interactive play then a player is doomed to sit through them again and again.  As a player I really, really do hate times where I am forced to sit through sections of the game deemed so essential that I must watch them before interacting again.  Perhaps there is a happy compromise, a separate save file held that indicates if a player has experienced that oh-so-important content once even if they revert to a previous save?


Grand Theft Auto IV and Red Dead Redemption do sometimes have fresh dialogue for retrying a totally failed mission from a checkpoint.  GTA does exact a penalty for death (or at least lack of heath) – the player does not automatically revert to a save but instead ends up in a hospital with the contents of their previously bottomless pockets empty.


Red Dead Redemption did rely on teaching me that I cannot disarm people in story mission duels via killing me off and reverting me to a save / checkpoint.  I really would have preferred disarmed opponents that had to die to have killed themselves rather than gimping the disarm mechanic and killing me in duels.  Being quite a persistent gamer I believed them to just be formidable opponents, so I did try one particular duel over and over again for an hour before I caught on (sigh).


If a player veers away from where the story teller wants them to go, they are killed off and put back somewhere they can make a different choice.  It does become frustrating if that choice is not clear, or if a player sees what they are supposed to do but lacks the skill to do it.  Perhaps worse still, when the player remembers something from several hours ago that would change things now.  Arguably save slots offer redemption for mistakes… at the cost of perhaps many hours of player time.  Multiple save slots also potentially endanger the weight of player decisions.


Should a player be able to decide to “cheat” and turn the pages back, or should that temptation be removed?  Do you trust a player to not replay one part of the story again and again to see all the different outcomes?  Does it even matter if they do?  I don’t think so if the player is having fun, but Mr. Resetti would disagree!


You wear yellow, they wear red


When a hero dies there is a save point or usually a special something that allows them to fight another day.  The same cannot be said of other characters and things the player interacts with in a game world.  You are Captain Kirk, the other characters are red shirts.


Games in the Civilization, Age of Empires and Command & Conquer series reward units that survive many battles with experience.  They reward the player for leadership that keeps the minions alive.   Cannon Fodder also had this but had an extra twist.  Giving my squad names and knowing the penalty of seeing a new grave on the hill at the end of the level made me work just that little bit harder to keep my squad alive (see comments from other gamers on this vid).


Some game’s deaths actually are a vital part of the storyline and they expect the player to accept that.  Characters in The Sims eventually die if you play with them.  Sure you could just switch characters, keep reverting to a save or allow them to continually imbibe from the water cooler of youth but you are always able to let time take its course and eventually death  will come to collect them.  Then they are gone.  Ok, well you might get a ghost hanging around but they are not remotely the same.


Mass Effect makes the player choose life or death for their own team members at points during the game.  Mass Effect  II rewards good leadership and truly knowing the players own team with extra story and different outcomes.  There comes a point where deep knowledge of a the supporting cast strengths and weaknesses can save their lives.


Having a player care about their supporting cast is terrible when it feels unfair (why won’t this healing potion work on them this time… it worked the other thousand times?!)  When done right though it gives a player extra emotional investment in not only the avatar they control but more of the world they are experiencing.


That’s all folks!


I would be very interested in hearing about how you think player death may evolve in the future, more examples of the above and your own personal experiences in the comments.  Many argue games are getting easier – some would say they are becoming more accessible.  A few designers have designed away player death completely in their games.


Death serves a few purposes, but chiefly to either completely end a score attempt or to impede progress through a larger game world.  Geometry Wars understands that smashing down a button lots of times should just let the player try again (a touch many gamers I am sure appreciate).  Other games use checkpoints and saves to snatch failed player actions out of the air as if they never happened; or return a carbon copy of that character back to the world sometimes none the wiser of the predecessors fate.


While writing this blog I asked an open question on Twitter about player and character death.   The many replies even then just go to show what a wide subject this is in both narrative and gameplay.  Grim Fandango, Planescape: Torment and Die2Nite have been suggested to me as games that explore death itself, though that is a topic for a different article.  As a programmer and gamer I believe the way death is handled in a game very much defines how the game feels and plays overall.  I do hope this article sparks off a few interesting conversations.  You may leave comments here or try joining a conversation on Twitter – I suggest the hash tag #PlayerDeath @paulecoyote.



Tweeters that helped me out in no particular order: @DaveFeltham @zackfreedman @lingmops @glamgeekgirl @oOSTVOo @twonjosh @paulnew @acroyear3 @BusterMcFearson @Stomp224 @JurieOnGames @ChrisA9 @ColleenDelzer @Renmauzuo @NaviFairyGG @FatalWebMunki @bjoernknafla @daredevildave


Also many thanks to my lovely wife proof reading this for me several times before I published it.


Paul Evans is a central technology programmer at Lionhead Studios. He has worked on the Fable II, Fable III and other unreleased titles. You can find him on Linkedin, see other things he has written on his personal blog and You can also follow him on twitter @PaulECoyote. Everything in this article is Paul’s opinion alone and does not necessarily reflect his employer’s views, nor constitute a legal relationship.

Cover Fire for Coders


By Paul Evans ( twitter | blog | Linkedin ) – Originally posted on #AltDevBlogADay


You are coding away and suddenly realize that there is a vital piece of new data you need to propagate through the battlefield of your game (or application) for your change.  Your heart sinks… you are going to have to take drastic action.  It will be tricky to safely create and navigate that vital piece of data through the lines.


A complex web of method signatures fill the field like barbed wire between your data and its goal – painful for both friend and foe.  Tracing back from your goal, you come across comments from generals that have trodden a similar path in the past and shudder at their remarks.  Some of them had to do some rather unsavory things, some warn against the consequences of using exactly the method you were thinking of.


You wipe sweat from your brow; is it really worth it to try and guide this plucky new data across such a hideous mine field?  A message from the tower tells you that you have no choice.  Reluctantly you make a plan for the fresh data recruit to cut through the battlefield at a certain point.


Your data makes it through and helps fortify the frontline – it all looks good.  Only three months later does a subtle change you made show up as having a hideous side-effect on the entire outcome of the war.  A halfling managed to make it behind the lines and is causing all kinds of problems.   But your plan was reviewed by one or more generals!  No one saw anything wrong with it!  Until that day when it *all* went wrong and now the Eye of Sauron is focused squarely on you…


If only there was an alarm hooked up… a simple safe guard to indicate there was something amiss.  Find a way to test, this story need not be about you!


Allow time for tests

Managers and leads, please allow time for tests in schedules.  Programmers, include extra slack in estimates for writing them.   There are many reasons why – but it all comes back to your definition of done.  Is “it works for me” good enough?  Is it enough to set things up and assume everything will go to plan?  When is something really signed off?


Scott Evil: Wait aren’t you even going to watch them?  They could get away!

Dr. Evil: No, no, no; I’m going to leave them alone and not actually witness them dying.  I’m just going to assume it all went to plan, what?


Austin Powers versus the Ill Tempered Sea Bass

and Austin Powers escapes.


Benefits of automated testing

For the coder it is like cover fire.  Every test is another sniper covering some small part of the code for you.  If something flashes up in their scope they can immediately warn of some nasty bug lurking.  That regressive bug never gets a chance to get a foothold.  Each extra test watches out over your software at a different angle and cumulatively they become a very useful force.


A well written test reviews your code – not on how you wrote something like a human reviewer might – just against an expected result.  A rational coder can not argue their code is decent if it fails a good test.


Tests form a kind of living functional documentation that any written form can never hope to compete with.  If a test becomes obsolete it is changed to fit a new requirement or even removed entirely.  Anyone that can write code can understand and write the tests.


A good test suite can even aide the gung-ho programmer that is desperate to rewrite a big chunk of code (ahem Alex Evans 🙂 ).  As long as the new code satisfies the integration tests and functionally achieves the same thing – have at it.  But before rewriting create some tests to measure performance, then after the rewrite the new work can have proven value.  If another change in the future reduces performance an alarm bell will go off.


Code passing a good set of tests in a branch can give any coder the confidence that a clean get from source control will result in a successful build of useful software.  That could be a pivotal moment for getting together something presentable for that last minute demo.


If you cannot test something, then it is unlikely that the code in question is fully understood.


But I can’t test


I can’t test because I don’t know where to start… there is just so much already there!

  • Some tests are better than none.
  • Try “Tracer Bullets”[2] to shoot down bugs and introduce tests to your game / application:
    • Create a test that tests the bug and fails.
    • Fix the bug, make sure the test now passes.
    • Commit and resolve.
    • Now if anyone regresses the behavior, your test will catch that right away.
    • Test coverage is cumulative – more bugs fixed in this way increase coverage at valuable pain points.


I can’t test because I don’t know what I expect yet.  I’m still figuring that out.

  • Prototype to investigate the problem domain.
  • It would be helpful to set a time box around the research period (a “spike” [4]).
    • Setting a time limit will allow you to :
      • Step back before going too deep down a rabbit hole.
      • Concentrate on estimating the size of the problem domain.
  • Concentrate on figuring out what to test – the tests are likely to be usable even if the prototype code is not.


I can’t test it because there is no one expected state.

  • Just think creatively while writing the test.  For example :
    • If a test is for randomness, then obviously there is no one predictable state.  But there can be a fitness function that defines how random something should be.
    • If looking for problems in a scene screenshot, perhaps a test could ensure a reserved color used for missing textures is not present.


I can’t test it because I cannot isolate the behavior to test

  • This could indicate:
    • Possibly blurring of responsibility with highly dependent and coupled code (perhaps too general).
    • Code could be reaching through objects, violating the principle of least knowledge.
    • Architecturally a lot of cruft is required to access useful behavior.
    • Code has been added to workaround a prior issue rather than refactored for a new requirement, adding to the cruft.
  • Rework to be testable if you can, try to isolate and retire if you cannot.Rework to be testable if you can, try to isolate and retire if you cannot.


I can’t do all these tests, it would increase build time

  • Keep tests in separate project or solution, you can run them only before committing to source control.
  • Ensure each test does not take long to run, mock where necessary.
  • Partition tests that must run for a long time.  Perhaps only run them on the build server.
  • Partition tests per module so that only particular module and integration tests are executed.   This gives the coder the choice to only run the tests they need.


I can’t write tests, I just do not have the time

  • This one is the hardest thing to overcome if there is no management buy-in to testing.  As a programmer at any level try your best to campaign for more scheduled time.
  • Writing tests gets quicker as a programmer gains experience (just arrange, act and assert one thing in each test).
  • Once tests start proving there are fewer regressions being reported in the bug database, it is an easier sell.  Gather any time saving metrics you can.



To many game developers I am sure tests don’t seem very rock & roll… not something they may have considered to be part of their role in the industry.  So I expect many do not test their work.  Writing elegant tests can present interesting engineering challenges and can be a good way to understand something that is new to you.  There is satisfaction to be had when all your tests pass after a big change, or when you realise a test saved you from an obscure bug or bad design choice.


Testing is no silver bullet, but try to think of it as an investment against that same bug being reopened many times later on.  Wouldn’t you rather spend time on polishing something else then finding and squashing the same bug again?


Further Reading

Clinton Keith’s book is written for game developers that want to think about different ways of prioritizing and scheduling tasks during game development.  It includes many reasons for testing and many interesting stories from the front line.  (For the purposes of disclosure he was also kind enough to acknowledge me for helping him out a little bit).


The other books listed are not specifically about game development but software excellence in general.


[1] Keith, Clinton (2010).  Agile Game Development With Scrum.  Addison Wesley.  ISBN-13: 978-0-321-61852-8

UK Amazon FlagUSA Amazon FlagCA Amazon FlagDE Amazon FlagFR Amazon Flag


[2] Richardson, Jared & Gwaltney, William (2005).  Ship It! A Practical Guide to Successful Software Projects. ISBN: 0-9745140-4-7

UK Amazon FlagUSA Amazon FlagCA Amazon FlagDE Amazon FlagFR Amazon Flag


[3] Martin, Robert C. (2003). Agile Software Development: Principles, Patterns and Practices. ISBN: 0-13-597444-5

UK Amazon FlagUSA Amazon FlagCA Amazon FlagDE Amazon FlagFR Amazon Flag


[4] Pryce, Nat (2010). Growing Object-Oriented Software, Guided by Tests. Beck Signature.  ISBN-13: 978-0321503626

UK Amazon FlagUSA Amazon FlagCA Amazon FlagDE Amazon FlagFR Amazon Flag


[5] McConnel, Steve (2004).  Code Complete – 2nd Edition.  Microsoft Press.  ISBN: 0-7356-1967-0

UK Amazon FlagUSA Amazon FlagCA Amazon FlagDE Amazon FlagFR Amazon Flag


[6] Subramaniam, Venkat & Hunt, Andy (2006).  Practices of an Agile Developer: Working in the Real World. ISBN: 0-9745140-8-X

UK Amazon FlagUSA Amazon FlagCA Amazon FlagDE Amazon FlagFR Amazon Flag


Paul Evans is a central technology programmer at Lionhead Studios.  He has worked on the Fable II, Fable III and other unreleased titles.  You can find him on Linkedin, see other things he has written on his personal blog, and follow him on twitter.  Everything in this article is Paul’s opinion alone and does not necessarily reflect his employers views. Copyright ©2011, Paul Evans.

GDC Online: Writing the Whirlwind (Joseph Staten)


Why I went

Halo is a successful franchise with a loved universe spawning a wide array of products.  I am keenly interested in how he made that vision a reality and what tools were used over more than ten years of stewardship.

First Impression

Obviously a popular talk – the speaker engaged well with the attendees from the start.



  • The place was more important than the plot
  • Creating a believable and engaging setting was the focus
  • Mystery and adventure on an infinite horizon
  • Concept art captured the feel of Halo
    • Feedback: “I don’t know what this game is, but I want to be there right now”
  • Do not start with the plot, start with the place
  • Master Chief was designed to be
    • Simple and iconic – an uncomplicated vessel with not much to dislike
    • Essential straight man – a foil to the chaos (and humor) happening around him
    • Perfect reflection of power projection
    • Fun to play


  • Halo 2 had the best final act that no one saw
  • Perfect storm of over design and over reach


  • All good things should come to an end
  • Take risks to avoid ruts
  • Good structures are built to flex so they can be cut
  • Quick to adjust
  • In ODST everyone felt connected to the story on the team
    • Original idea came from the team (Dan Miller?)


  • Even if you are in a writing role, the entire team are story tellers
  • Writer has to be aware that a story change can have huge consequences for the game
    • Writing a check is easy, cashing is hard!
  • Keep bulleted lists for story problems
  • The most important story notes are created for internal use only
  • Know the strengths and weaknesses of the team.  Work closely with them
  • Big canons
    • Unwieldy and hard to shoot!
    • You are creating collaborators not just fans
    • Make safe pockets in canon where they can play
      • A sandbox for them to play in and expand complementary parts of the universe.  Examples:
        • Red vs. Blue (makes good fun of the craziness!)
        • Halo Wars
    • Tricky… novel “Reach” came first and differs from game “Reach”
  • Hollywood
    • Build it and they will come
      • Do not be offended – they want your *world* not your *words*
      • Do not compromise; the film industry need the game industry as much as the game industry needs them
      • Even though the film never happened, learned a lot from meeting with Peter Jackson
  • Cortana
    • Smart women are sexy
    • Needed someone who could get under Master Chief’s skin
    • Inspiration came from the strong women in the writer’s life
  • Other literature
    • Speaker read “The Hero’s Journey” in college
    • Lessons to be learned
    • ODST non-linear journey
  • Story over plot
    • Story always matters
    • Story can be told without dialogue
    • Keep the story simple
    • Would be great if the world was always there.  Lots of stories to tell rather than just one over a dozen hours.
    • Mute scale
      • Gordon Freeman (Mute)
      • Master Chief (Slightly Talkative)
      • Duke Nukem (Talkative)
  • Writing pipeline
    • Touch type (!)
    • Software
      • Uses OneNote to share ideas across the team
      • Final Draft
      • Excel (started to not cope with the volume)
      • No custom tools he was aware of
    • Used bulleted lists
    • Halo 3 used something like Robovoice for place holder audio
    • Powerful cinematic tools in game
    • Own mocap stage


It was a very enjoyable session.  I am glad I asked the writing tools pipeline question, as there does seem to be a lack of specialist tools for writers in the games industry.

GDC Online: How to create a diverse team and keep it


Donald Harris and Sheri Graner Ray hosted a round table on my last day at GDC Online about diversity in game studios.

Why I Went

The topic sounded interesting to me – diversity in my mind was a given as I have seen the power of mixing people from different backgrounds within the talent melting pot of Lionhead Studios.  Encouraging retention in particular was interesting to me, as people sometimes do not just leave a studio but the entire game industry itself.  I believe some of those leaving would have chosen to stay if there was a better work-life balance; e.g. improved working practices that supported fathers and mothers spending time with their children, rather than have them routinely spending extra hours at the office.  Those reading this blog entry interested in overtime practices and their impact on the workplace should review DeMarco(1999) and Keith(2010), as this topic was not discussed in depth at this round table.

First Impression

The round table discussion started with Donald asking everyone to introduce themselves and to explain what they wanted from the hour.  Diversity was understood by the room in two ways, genetic and skill.  Despite the room being mostly white and male, the entire room did declare interest in diversity in both regards.


The first question after introductions was “why would you want diverse teams?”

Diversity in skills was briefly addressed, with some questioning the value of mixed discipline teams.  Questions about improving communication between artists and coders were asked but never really answered.  The meeting was steered back to people with diverse skills rather than mixed discipline teams.

Personally I can see the value of mixed discipline teams as suggested by some in the industry including Keith (2010 pg.160-161); but in larger studios these disciplines do seem to be organized in to single discipline departments.  The different terminology and ways of communicating between disciplines does make people who can communicate easily with each very useful.

Interestingly during career track talks on Friday this kind of generalist attitude seemed to be under-valued, as graduates were being repeatedly encouraged to be more specialized.  I do wonder if the message of specialization given through career advice both before and after entering the industry could be creating deeper communication silos, thus hindering integration of disciplines in to cohesive cross-discipline teams.

Donald made the point that a modern game set in a city made by a diverse team would be inherently more believable because of the combined cultural knowledge of a diverse team.

Sheri steered the room towards recruitment ideals, clarifying the “how to create a diverse team” part of the title into “where to source skilled diverse people from”.  A side point here quickly resolved is that hiring an under-qualified candidate from a under-represented type of person is counter-productive.  Fulfilling corporate targets based on genetics rather than required skill builds weaker teams and breeds contempt.  The room declared the door was open to candidates with the right skills from diverse backgrounds, but sourcing those people can be difficult.

A grass roots suggestion about working with schools to encourage more diverse candidates interested in developing skills useful to the game industry was quickly discussed but ultimately the room was steered back towards addressing more immediate recruitment.

Places suggested included:

  • College campus
    • Talk to instructors directly, ask for interns
  • IGDA diversity groups
    • Cannot directly advertise, but there are networking opportunities
  • Mod Community
  • Linked in
  • Different types of colleges and universities
    • Architecture School
      • Level designers
    • Art School
    • Business School
  • International candidates
    • Localization & bring knowledge about their own culture
  • Community and customer management candidates
    • Starbucks, PapaJohns, etc
      • Received good customer service while serving studio,  worthwhile interview to represent studio.
    • Customer base
      • Passionate about product, though can be double edged sword
  • Game forums
    • Fans can be recruited in to community management
  • Poaching from other studios
  • Poaching talent from other industries

At one point I did suggest to the room that if working practices were to be improved that mothers and those physically unable to work a full day could be an untapped source of talent, especially if they could job share.

Behavior interview techniques were mentioned, with a split about whether the practice of letting every member of the team spend a few minutes with a candidate being interviewed was good or not.  DeMarco (1999) also advocated using a similar technique.  It was suggested that perhaps this practice is better for smaller teams, though some said that it worked with larger ones too.  An objective set of criteria for questions to be asked by the team if a team interview is done was agreed to be crucial for the practice to be effective.


In the closing minutes the elephant in the room was the word “diversity” itself.  It is a big word that can be quite confrontational (“You’re not diverse… you are BAD people!”).  Someone else said “I hear diversity, I think of lawyers”.  Corporate diversity training was spoken of briefly – some found it comforting, others thought it was just a box ticking exercise providing some kind of metric proving to someone somewhere that a company was diverse.

I found the round table discussion interesting though not quite what I expected  – it focused on recruitment rather than team cohesion and retention.  It was comforting to hear that my experiences working within a diverse team in Lionhead are repeated in studios elsewhere.  From my experience, Lionhead has recruited from many sources. My own recruitment into the studio was from a different industry – I used to create software for libraries and learning centers!  It was good to hear that many other studios also have open minds when it comes to recruiting from different pools and developing talent.


Donald Harris :

Sheri Graner Ray:

Keith, Clinton. (2010).  Agile Game Development With Scrum. Pearson Education, Inc. Amazon UK, Amazon US.

DeMarco, Tom. & Lister, Timothy.  (1999).  Peopleware: Productive Projects and Teams.  Dorset House Publishing Co., Inc.  Amazon UK, Amazon US.

%d bloggers like this: