Archives For game development


Last week I took part in the fifth GBJAM. A popular game jam that pays homage to Game Boy games but allows for modern sensibilities to creep in. Initially I had no plans to take part but a developer on the newly formed Icelandic Gaming Industry Slack mentioned it. Soon I and a handful of others decided to join in. The basic format gives you ten days to make a game. There are two significant constraints, a four color palette and a ‘pixel resolution’ restriction of 160×144. After the ten days are up competitors then rate one another’s games.

In the end I spent around 16 hours making Void-Dogs and finished in 82nd place out of 402 entries which I’m pretty pleased with!


I’ve been working pretty much continuously for 12 years making games and playful things. My emotional makeup is such that I really invest in the thing I’m making at any one time so I find it hard to juggle multiple creative projects at once. I don’t have the headspace for it. As such I’ve found it hard to work on sideprojects. I’ve made things during both my recent paternity leaves as good contiguous blocks of “free” time. Development time was “luckily provided” thanks to Autodesk laying a bunch of us off in August. Since then I’ve been working for two hours a day on a small game called What Now Earthman?. But that is still a big project I won’t complete for the foreseeable future. So I was already motivated to make something smaller in scope. The GBJAM popped up as a good enough answer.


Void-Dogs took sixteen hours in total to finish. I started a day late but I don’t think that made any real difference. I started off working two hours per day but eventually did a little more from Wednesday onwards. In general it was quite a relaxed affair tucked around child care. Void-Dogs was made in Unity which is probably my favourite engine for making a myriad of games and prototypes quickly. I task tracked with lists on graph paper. I wrote all the code and made all the art and SFX by myself but found some Creative Commons music to use as a soundtrack. My main source of inspiration was the game Space Harrier but I wanted something that involved a little less spraying bullets directly forward. After a bit of brainstorming I came up with the concept of “skydiving in space” and went off to work! You can download and play the result here.

The most interesting technical challenge was creating the sense of depth and motion with a limited resolution. In the end I actually opted to use a perspective camera and Unity’s particle system to create some ‘dust’ that gives the impression of hurtling through space. Another important addition was the use of a ‘sine wave’ shake script I wrote some time ago. I initially intended it for cameras but it works just as well applied to other objects and captures that never still motion of a skydiver falling at terminal velocity, not realistic but it feels good.


All the asteroids and players are positioned in 3D space with one unit equal to one pixel. This let me simply calculate the depth into the camera where I would get pixel perfect rendering. I initially tried rendering the sprites moving through space directly but the resolution makes for ugly pixel artifacts as sprite pixels pop in and out across real pixel boundaries. This wasn’t an unexpected problem, it’s part of the reason you see games like Space Harrier do 3D by changing sprite sizes (also hardware optimised sprite rendering). Moving to this approach required a bunch of labor to make art assets but is much better visually and thematically. In the end all the sprites sit on the ‘focal plane’ and are represented by colliders and transforms moving through 3D space. I then switch sprite depending on depth and reposition the sprite correctly on the focal plane to simulate the perspective of the camera. Everything is then snapped to the nearest pixel to allow for fluid motion without pixel artifacts.


Unlike the above image the colliders actually ended up being boxes and pushed back behind the sprite. It seems obvious in hindsight but it felt all sorts of wrong with the collision as it was above. The inner collider is for the asteroid itself and the outer collider is the zone for the proximity bonus.


What went well?


My art drew a lot of positive comment and was a reasonably highly scored feature of the game placing 54th in that category. As someone who only started making game art again when I went on paternity leave this felt pretty good. Even more so as I hadn’t made any pixel art or pixel art animations for games before. A lot of this I credit to time spent sitting down cranking out bad vector art for What Now Earthman? it’s getting better but I learnt a lot in the three months I’ve been drawing semi-regularly. I’ve got a much stronger understanding of color theory, shading and other basics than I ever did before. On top of which I learnt that good art takes time (duh!) and not to try to rush through making something. Even a game as simple as Void-Dogs contains a surprising amount of art and it took perhaps half my development time to make it all. Including remaking art for the page.


I ended up with my highest placement ranked 48th for the gameplay. I’m pretty pleased with the gameplay mechanics I added and how they work together. There are three essential layers. First the asteroids arriving in patterns forcing the player to dodge through waves of obstacles. Second the player scores more points for flying in proximity to the asteroids adding a risk-reward mechanic for people that find the dodging gameplay simple adding a layer of mastery. Third other divers will arrive next to you and fight for a short amount of time, the only means of killing them is to hit them with a laser bolt that stuns them and have the splat into an asteroid. This sets up a complex timing problem for the player to solve whilst dodging asteroids and incoming laser fire. These were strong fundamentals to build a fun game on and the feedback I’ve received seems to agree.


The AI itself is a simple steering behavior that has a target, avoids the player and asteroids then occasionally fires towards the player. It’s surprisingly good at hitting you!


I carefully managed my scope throughout the project. Mostly in the classic manner of frontloading the risky items I hadn’t done before. I also kept a Kanbanish working list also meant I could rearrange and remove tasks easily as I went along. I pretty comfortably worked through to the weekend when the days are taken up by looking after a boisterous three year old and two month old! Then I managed to snatch enough time to pull things together and enter my submission with quite a bit of time to spare even if it wasn’t time I couldn’t use on my entry!


Architecture in a jam game? I saved a whole heap of time by doing simple things like separating the component implementing the actions of the diver from the component that controls how those actions are used. Both the player and the AI use the same actions. Similarly the components for sprite scaling and screen positioning were written to be easily shared and meant it was trivial to add in scaling for the enemy entering the game. I have a simple Events system I wrote for WNE that drives a lot of the UI update and game flow between objects that should be decoupled as much as possible. All my bullets and asteroids live in object pools local to where they are used and are drawn from them as needed. Finally the stage design is done within a coroutine and a library of helper functions so it looks a little like this:

yield return new WaitForSeconds(2.0f);
yield return new WaitForSeconds(2.0f);
yield return new WaitForSeconds(2.0f);
yield return new WaitForSeconds(4.0f);

yield return new WaitForSeconds(2.0f);
yield return new WaitForSeconds(16.0f);

I’d attribute finishing this game at all to keeping on top of the code design as I went. Then hacking madly at the end! But keeping things neat made the hacks easier to implement.

What went badly?


I’ve done precious little audio work and it really shows in Void-Dogs. My two lowest ratings were for Sound (#100) and Gameboy Feel (#177). My music selection was a big contributor to the latter, it was the best Creative Commons licensed track I could find which didn’t really suit the Game Boy era and slightly bends the rules on Audio as it wasn’t an asset made for the jam. SFX were made using BFXR and whilst I think they are serviceable as placeholders they don’t really hold together or excite. I think rather than taking on yet another task were I to do this again I’d try to pair up with someone that knows what they are doing. Although I’m trying to get a basic handle on how to make better SFX and where to even start with music just to understand the processes.

Stage Design

I was pretty sure at the start of the jam that I wanted to have hand crafted stages rather than trying to create a procedural generation algorithm in such a short space of time. In the end I only had time to make one stage and iterate on it a little bit after some playtest feedback. Finding fun sequences and building them out whilst also trying to deal with the problems with perspective and the screen getting messy was really challenging! To be frank the result is a mish-mash of ideas in a steady progression punctuated with ‘clone’ fights. One of my biggest missed opportunities was not front loading a clone fight. I think many people probably played the game without reaching the first one! My goal was to have a series of escalating stages that lead the player in but this wasn’t really realised.


Could I have done better in the time I had? Perhaps? I look back through my notes trying to find places I wasted time and it’s really hard to say. I think I could have picked either the obstacle dodging or the clone fighting as the focus and doing both was perhaps unnecessary for a jam. Though I do think they compliment one another and was keen to push outside of the shooter norms. Mostly I think I wish I had more free time to put into it or had planned on taking part and done some prep work.

The single biggest thing I didn’t budget time for was setting up the page which took a lot longer than I thought. Presentation matters in terms of first impressions and to get eyes on your game. Annoyingly the Jam entry page misses most of the instructions and theming which was an issue as I’d included the instructions on the site proper. Hopefully most people clicked through to give it a read but players didn’t have too.

Lessons for future Jams?

This was fun and I’d like to do it again when I have some free time, in particular I think the constraints made for a really fun jam format. The biggest takeaway I have is to team up with other people to cover the bits I’m rubbish at. I’d also like to try my hand at just working on the art and design whilst leaving the lion’s share of the programming to someone else. I like the art process, it’s not what I do in my day job and jams feel like a good venue to practice. Then the usual things for game development in general were really validated for me; have a small scope, make something you know how to do, get the game up and running quickly, playtest and iterate.

Lately I’ve been playing a lot of Rust. It’s a great sandbox PvP game but it has some frustrating balancing that makes solo play a chore at times and currently disproportionately favours group play. It got me thinking about the problems with balancing solo play versus group play. So I’m going to to try to expand on my thoughts about the issue through the example of Rust.

To begin with let’s state some premises, these may not be valid for your own vision but I think they are common to most persistent games with PvP:

  • Group play will in general always be superior to playing by yourself.
  • Playing by yourself should be viable without a huge time commitment.
  • Live player interaction is preferred.

In general games tend to balance activities through resource acquisition and the cost in resources of achieving something. Grinding to get materials to build a base and grinding to get materials to raid a base are staples of Rust. Ultimately it’s about optimising the time taken to achieve the desired goal. The problem is that these activities scale really well as you add more people so groups are by far the dominant strategy and quickly significantly out power individuals. Our goal as game designers based on the premises above is to keep the gap between groups and solo players reasonable such that whilst solo players may never challenge giant groups they can enjoy the broader metagame.

One great way of achieving this is balance on an orthogonal axis, skill. Rather than making the game hard by forcing you to spend a lot of time gathering, crafting and building a root to the objective is also available through skill. Rust actually has this in various parts. For example the bow in the game is resource cheap, takes a reasonable amount of skill to wield effectively and can take down kitted out players. It’s suboptimal in comparison to the high resource cost guns in the game but its a viable way to get one that relies on skill rather than time. Outside of systems design there is some great social engineering metagaming that people use to effectively give themselves a leg up.

Whereas the bow is a great example of balancing skill versus time raiding other peoples bases in Rust takes the opposite tack. As it takes a lot of resources and time to construct a base raising has been similarly balanced that destroying a base also takes a lot of time and resources. It’s also much safer with no negative consequences to raid a base whilst the occupants are offline. This isn’t inherently wrong but it does put solo players at a huge disadvantage as group advantages essentially mean they can raid solo players at will with very little chance of there being any repercussion. Part of the issue here is that the only way to successfully raid a base is through destruction. It’s a straight up case of “how much do you want to pay to get the stuff in here?”. Players can optimise this somewhat by intelligently working their way to the bases loot but ultimately there is only a small skill component to raiding in comparison to the massive amount of time sunk in resources. The solution? Well we don’t necessarily want to make bases easier to destroy but adding a skill component seems feasible.

On Code Locks and Key Locks

Currently there are two tiers of doors in Rust. A regular key lock that lets you craft keys from it which take up inventory space and can be given or looted to gain access to a door. A code lock that has a four digit pin that you can share with friends to give them access to the door. It’s worth noting that both can be brute forced with key locks having less combinations but being more laborious to actually try each at present. The former also costs less than the latter. In my time in Rust I’ve used one key lock when I was green but since then nothing but code locks as the advantages of the latter are huge.

The easiest solution I’ve thought of is to remove Code Locks. As noted above keys are physically present items that give you access where as codes are remembered and as such intangible. This puts us squarely in the territory of skill, you must fight to protect your keys or bury them in a stash (a small container that can be buried and only reappears if someone looks at it for a small amount of time) both are vulnerable to interception. This provides a skill based, non-destructive and player interaction based mechanism for solo players and groups to get access to a base. Clearly groups still have an advantage but as with the bow example solo players can also successfully use it against groups. There are a bunch of QoL improvements that would need to be made to make this a good implementation but it demonstrates the idea.

Further solutions could include audible tone differences on code locks that can be overheard, some form of systems based skill test to bypass a code lock (which could be extended to other items), much more expensive code locks and completely different systems targeting other parts of raiding.


When looking at balancing game systems with one another in games that support both solo and group play don’t just consider resource cost adjustments as you’ll be lopsidedly punishing solo players and eventually smaller groups. Instead look at skill based systems that whilst still giving groups an advantage also mean that solo players can still take part without the game becoming onerous.

The entire point of Agile is to maintain flexibility in order to deal with the uncertainty inherent in developing software products. To fully display my biases this goes doubly-so for creating videogames as we’re attempting to hit much more nebulous targets like ‘fun’. Planning is still a necessity for most businesses but rigidly sticking to a plan is not. It’s embodied as this value in the Agile manifesto.

Responding to change over following a plan.

If we’re planning we need to be estimating but we know from research that humans are completely bloody awful at it when there are high degrees of uncertainty involved. We cannot see the future and are kidding ourselves if we think we can. In my experience discussions about estimation tend to go in one of two directions. We have the empiricists or Reality Deniers and the #noestimates crowd or the Oblivious Snowflakes. Broadly speaking the first group think numbers have the answer and the second group is in a really unique situation where they don’t really need to do much if any long-term planning for development.

Denial, something, something, something… river in Egypt.

The Reality Deniers take comfort in models and using data from ‘experimentation’ to generate predictions about the future. There are two problems here; context and the applicability of the model chosen. Context is the game development empiricists Achilles heel. If I run three miles several times a week following the same path in sunny LA does the average of my times translate over to how well I’ll run a mountain marathon in really bad weather? No, very obviously not. Newton’s Laws of Motion don’t apply on the really small-scale and the really-big scale but they do work pretty damn well at the scale the experiments to determine them were conducted at. If you want to use experimental data to create models to predict the future you better be damn sure your context is not about to change under your feet. Which, being videogames development it almost assuredly will.

The second problem is the model. As most people use Scrum and Scrum is about tracking velocity almost all future estimates just linearly extrapolate velocity. The problem is not necessarily that this is wrong just that it’s incredibly unlikely to be right. All sorts of things speed-up and slow-down teams and change the way people estimate for an average to be tracking consistently. Further the velocity of a team coming to the end of a project is going to be very different to one starting off. Primarily because the level of certainty and knowledge about the project increases greatly as it nears completion. Small errors in estimation accumulate into big errors over a long period of time and you can’t really be sure that everything has actually been estimated (we’re going to iterate a lot right?). Anyone who has had to write any multiplayer code knows that extrapolating linearly in the presence of even small accelerations is doomed to give you wildly diverging results.

Combine the two together and I don’t think we even need to look at problems with the experiment setup. We want to estimate an uncertain process, with data from a different context using an overly simplistic model, even dressing up in our +10 Robes of Technomancy this seems stupid. Science is rigorous, this approach is not.


At the other end of the spectrum is the idea that we don’t need any estimates. I called these guys the Oblivious Snowflakes because their position is often unique and they don’t seem to realise it. I actually have a lot of sympathy for this position as it sounds dreamy and has less of a bad accountancy vibe. #noestimates is the idea of continuously shipping a product taken to the next level. These snowflakes aren’t iterating once a month or once a week they’re iterating once an hour and pushing the results out live. Of course you don’t need to estimate anything if you have already shipped a product and are able to work on it blisteringly fast. Well, in the short-term at least until someone with a tiny bit more vision and urrm… planning comes and knocks your product off it’s perch. Sadly for most of us a system of continuous delivery is a very long way from reality and most games require a lot more effort to create a viable product than a web application.

Reality Check

We’re agile… or at least supposed to be. The answer to this tricky conundrum of what to do with longer-term project planning in the face of a fog of uncertainty is damn well written down.

Individuals and interactions over processes and tools.

Customer collaboration over contract negotiation.

In this instance the customer is not the end-user they are the person paying you to make the game. It could be an investor, the representative of a publisher or your executive producer it doesn’t really matter. What they want is assurance that you’re not full of shit and they’d like this signed, in triplicate, in blood with a firm deadline upfront based on any plan you have. This is a risk mitigation strategy for them and your job is to deftly dodge the contract deadline hammer and convince them to work closely with you on a very regular basis to better mitigate the risks involved in development. However we’ll still need a plan but this is not a plan that can be captured in a contract. It must by necessity be iterated on as development continues and new things are learnt. As we progress towards completing a project our plan will become more certain. It also means that we can early out and still do something else if, despite our best efforts, the project is not meeting expectations. Both parties need to embrace the reality of the uncertainty inherent in the beginning of a project and keep plans vague and the uncertainty in them spelled out clearly.

As the project progresses the plan should be routinely revised and the teams developing the game should be meeting and discussing the game regularly with the customer. At a high level a healthy project should see a downward trend in uncertainty over time. Employing schemes like the development lifecycle can be a good way of tracking progress an deal with uncertainty upfront. In short building the project plan is no different to building the product and the people working on it a virtuous cycle of iteration, feedback and adjustment.

Detailed Estimates Are Still Useful

For teams iteration planning there is nothing better than a old fashioned application of numbers. We want to work at a sustainable pace and the only way to do so is to avoid over-committing to the work we are going to do in an iteration. This is why we should prefer shorter iterations. It’s much easier to estimate and plan one weeks worth of work than it is four weeks and we avoid compound error causing massive deviations in our plan. It’s also much easier to estimate the work we are just about to do because we know a lot more about it than it is to think about the consequences of the consequences of that work in a months time. This is also the point that it makes sense to capture uncertainty in the actual task estimate rather than keeping it as a separate concern. Essentially estimates should be a combination of task size and how sure we are that our size estimate is correct. We then drop tasks into buckets and using recent historical data for the team plus a bit of intuition to bring stories into an iteration such that we don’t over commit to the number of ‘buckets’ we got done before.

In most cases it’s essential to do some design work before you can begin implementation. Typically the artifact coming out of this is some form of documentation about the game or feature to be implemented. In traditional games development this usually involves generating a massive tome explaining every facet of the game in detail. This approach is also a massive waste of time for several reasons:

  • It is necessarily incomplete and as such will require revisions as flaws and unexpected problems are found.
  • It is incredibly hard to maintain due to the volume of material and references between elements, even in a wiki system.
  • Being hard to maintain means it gets out of date quickly and loses coherence.
  • No one will read it as they are generally too big, verbose and dense to be used day to day.
  • It’s completely open to interpretation as it’s a description of something rather than a concrete thing itself.

This sort of documentation does have one use. Theatre for managers and publishers. It provides a nice cozy, false sense of security that everything is fixed, known and contains as few risks as possible. Sadly this is usually deleterious to the actual goal of managing project risk.

Why do we design?

To answer the question of “what should agile design docs should look like?” I first need to step back a stage and question why I design things in the first place. The answer I like best is simplicity, the goal of design is to provide the simplest solution that solves a particular set of criteria well. This is not necessarily the most intuitive solution and therefore it is important to spend some time making sure that I understand the problem before we go ahead and implement a solution.

I value simplicity because it usually provides a solution that is conceptually easy to understand for both the people implementing it and the person using the resulting feature. Simple solutions also tend to be robust as they have a low number of moving parts. Simple solutions are easier to modify later to add more complexity if required. Overly complex solutions can be an absolute nightmare to detangle at a later date.

Why do we document design?

If the simplest solution is not necessarily the most intuitive that means I need to be able to communicate the problem, the solution and the reasoning behind selecting the solution to other people. Usually in the case of design documentation that’s to the people implementing it, even if that person is me. It also means it needs to be easily digestible and relevant only to the current context. This is the great failure of monolithic design documentation.

Making an idea easy to question is also a vital part of communication. The creation of a design artifact is emphatically not a hand-off procedure but one part in a continuing collaboration to create a great product.

Agile Documentation

The main measure of progress in Agile is the state of the working product, for games means a playable game. Design artifacts therefore are not a measurable form of progress in themselves. They are however incredibly useful in moving forward more rapidly towards a working implementation. As such design artifacts must be “Just Barely Good Enough” that is they provide enough detail to start implementation with the expectation that design questions will be answered whilst the implementation is in progress. The level of detail entered into and type of design artifact generated really depends very much on the context of what is being designed. However all design artifacts should generally answer three points.

  • What is the Problem Domain?- What problem is it we are trying to solve? What are the goals we want to achieve by solving this problem? Why is this a problem?
  • What is the Current Best Solution? – A description of the solution adhering to the constraint it must be just enough to begin implementation. This could be anything from a photo of a whiteboard sketch through text documents to a mocked up video or animation. All depending on context.
  • Why? – How does the solution meet the goals and sort out the problem we are trying to solve?

We also need to deal with one more issue. Most products including games are broken down into various smaller chunks for implementation and still need documentation about the project in totality to keep things coherent. Particularly in the early concept stages where different avenues are generally being explored. The good news is that this documentation approach is applicable at that level as well. It’s useful to have a simple, easy to digest and question synopsis of exactly what the game is supposed be and how to achieve it. The trick again is to provide just enough documentation to get started and to answer questions as they come up.

Next up how do you go about creating these design artifacts?

Usually when Agile is introduced to people it’s done so with Scrum which is seemingly filled with arcane terms and voodoo ritual. Very often the context behind those rituals and terms is lost and the general advice is to, “do it by the book,” until you understand, before you adapt it. There are a couple of problems with this. Firstly that the context Scrum was developed for might not fit the context you are making games in so rather than enabling you to move faster and make better games you are standing in a corner with your wizard hat on. Secondly Scrum as an introduction obscures some of the elegance behind the Agile Principles, concerned as it is with day-to-day process in service to that elegance.

So let’s cut back to the elegance. In yesterdays post I made a simple re-drafting of the Agile Manifesto to make sense of it for games design/development. Today I’m going to take those re-drafted principles and show how they fit into a simple Agile process.

First a diagram:

simple agile

That’s it. That’s the beating heart of Agile. So simple you can describe it in one sentence. Come up with an idea, make it and try it out to see what it’s like, then use your learning to refactor your idea and processes. So simple it gets repeatedly invented in an intuitive fashion. So simple I can retire this blog forever! Done!

Well not quite, we’ve only managed to deal with a few of the Agile Principles in this loop the rest involve what happens during each stage. Currently we’re hitting:

  • Deliver a playable game frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  • A playable game is the primary measure of progress.
  • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.


We want to keep our ideas lightweight. Over-complicating our ideas too early means wasting a bunch of time both coming up with them and also implementing them. We’ll be refining our ideas over the course of many iterations so starting with a ‘perfect design’ is not going to help particularly as we have not yet managed to evaluate how perfect the design really is! The watch phrase some canny individual coined was “Just Barely Good Enough”.

Ideally we’re keeping these principles in mind:

  • Continuous attention to technical excellence and good design enhances agility.
  • Simplicity–the art of maximizing the amount of work not done–is essential.


Creation is in many ways the ‘easy bit’ where we turn the idea into something playable. The main point to be aware of is that almost every task is going to require some Just-In-Time design. Having whiteboards (or a pad if you’re by yourself) handy is incredibly useful to quickly solve design problems. If you’re creating a videogame then this is also the time to make sure you’re refactoring the code your are working on to keep it simple, elegant and easy to work with. There are lots of ways to make this less painful but that’s outside of the scope of this post.

The principles to keep in mind are the same:

  • Continuous attention to technical excellence and good design enhances agility.
  • Simplicity–the art of maximizing the amount of work not done–is essential.


Evaluation means putting real people in front of your game and have them play it. Ideally you want the audience you intend to release the game to playing it as early as possible (or a close facsimile). At the very least you want some people that aren’t you playing the game to give criticism and feedback. Other developers can be good as they can excuse some of the rough edges of a product in development as well as being able to understand the ruleset and provide critique of the design. If you’re in a company then you’re probably going to have a list of stakeholders responsible for your project who should be playing every iteration and providing feedback. Other excellent although more time consuming methods include using Usability testing methods. For example doing some User Testing, a technique where you watch a players game session and take notes on friction points in the experience.

Schemes like alpha and beta testing, attending games shows, plus funding methods like Early Access also provide a host of willing playtesters. A caveat here is that the quality of the game experience does matter when showing something externally to large groups of people in a manner where there are quality expectations. First impressions count, word of mouth is important and it can be hard to dig a games name out of the toilet if every comment on articles about your game references how rubbish an early version was.

The end result should be a collated list of feedback and some action points to take into the next Ideation phase.

The principles being hit here are:

  • Our highest priority is to satisfy the customer through early and continuous delivery of a quality game experience.
  • Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

The remainder of the principles deal with things like team composition, team management and day-to-day practices that are effective rather than process. They should be kept in mind at all times.

So why is Scrum so complicated?

Well it turns out as you start to use the above process a whole bunch of questions will routinely come up that need to be answered. Some can be answered by reading the Agile principles but others need a bit of cogitating on the best way to handle them.

For example how long should it take to move through the whole loop? According to the Agile Principles:

Deliver a playable game frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Frequently providing a playable game means frequent feedback from stakeholders, playtesters and colleagues. It is the engine of iteration.

So we want to move through the loop pretty quickly, what if our idea is complicated? Well we’re going to have to cut the idea up into chunks we can implement and we’re going to need to work out roughly what order to do them in. But that means we won’t have the “full game” playable for some time? Well we should build a prototype first so we can get early feedback on our complete game design or we won’t worry too much and let the final design fall out in the wash as we receive feedback. Scrum basically provides a ready made solution to a lot of common problems that come up when trying to implement this elegant feedback loop.

Whether you pick an off-the-shelf solution or grow your own from simple beginnings the important thing to remember is that the entire process fails if you don’t keep up the virtuous feedback loop for both the game being made and the processes you use to make it.

Let’s face it the Agile Manifesto is very Software Engineer focused. I’m not sure it’s meant to be but it’s a consequence of the background of the people that wrote it. The principles also explain what but not really why or how the principles directly interact with the manifesto values. It’s also a bit hard to frame in your own context sometimes. This is a bit of an experiment in re-drafting the principles to make sense for game design/development. I’ll highlight the changes I make in bold. The original Agile Manifesto which can be found here.

First the values themselves:

We are uncovering better ways of developing games by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Playable games over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

The first thing to read is the very last sentence. Lots of people read the manifesto and assume that there should be no process and no documentation. The point of the manifesto is that those things are necessary to a degree but should not be the focus as they have a tendency to take over and work against the primary goal of making a particular product.

Why a playable game rather than comprehensive documentation? What about the Design Treatment, the Preliminary Design, the Final Design and all the other ancillary documentation you might produce? The simple fact is that the value of an idea for a game is much better expressed as a game that you can play rather than abstracted into a document. A document is open to interpretation in a manner that an actual demonstrable game isn’t which means that two people can have wildly different ideas about how the end product might turn out without either of them actually being wrong. A design expressed as documentation and a tangible, playable product is there to be critiqued much more directly with far less ambiguity. Further generating comprehensive documentation rather than a product is a big waste of time as we know that we will be making changes as we go along and a big list of things to implement before the game is ‘finished’ often delays critical iteration.

I re-phrased the Agile Principles as:

We follow these principles:

  1. Our highest priority is to satisfy the customer through early and continuous delivery of a quality game experienceThis provides us with the best and most direct feedback so as to shape out product direction. It also means our game is continuously in a shippable state. The value of a game is captured in the quality of the experience.
  2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage. Late changes are a reality of the business.
  3. Deliver a playable game frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Frequently providing a playable game means frequent feedback from stakeholders, playtesters and colleagues. It is the engine of iteration.
  4. Business people and developers must work together daily throughout the project.
  5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. Autonomy, mastery and purpose are the key motivators.
  6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  7. A playable game is the primary measure of progress. We are making a game, if the game is not changing we are not working on it. A feature designed on paper is not a feature that is playable.
  8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  9. Continuous attention to technical excellence and good design enhances agility.
  10. Simplicity–the art of maximizing the amount of work not done–is essential.
  11. The best architectures, requirements, and designs emerge from self-organizing teams.
  12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

The principles were not originally numbered but I’ve done so to keep the discussion brief, it’s not a statement on which of the principles are more important than the others. Never the less there are a few of the principles that are good to call out in groups.

  • Process Improvement: Twelve represents the engine of process improvement within the agile framework, it’s taking an iterative and evidence based approach to improving the working practices of a team with the rest of the principles representing the yardstick by which to measure them.
  • Game Improvement: Seven details the key indicator of progress. The state of the game itself. Combined with Three and One it provides the engine for evaluating and iterating on the game.
  • The Team: Five and Eleven detail who the team is and how they should be managed.
  • Mindset: Eight, Nine and Ten frame the mindset required to work with an agile process with One as the goal.
  • Working Practices: Two, Four and Six detail important working practices that are part of the reality of working on commercial products with many people.

The entire point of the Agile Manifesto is to define a new way of working that is customer focused, iterative and concentrates on making the best product possible by empowering the people that make it. Hopefully this re-write clarifies how this approach fits game design/development and gives people a good starting point for defining their own processes.

Concepting and prototyping allows developers to cheaply explore a design space in order to find the nuggets of gameplay that can be polished to a high sheen. The single biggest issues are the size of this design space and the efficiency with which you can explore it. Roughly speaking we want to explore as much of the design space as possible as quickly as possible. There are two good routes to this; defining good constraints and working in parallel.

Good Constraints

Limiting the size of the design space is something you want to do for a whole variety of reasons:

  • To match company vision and goals.
  • To tackle specific problems.
  • To meet the abilities of the staff you have.

The single most important reason for defining clear constraints is to aid creativity. It’s simply easier to think through choices when they are limited. Constraints don’t need to be externally imposed nor do they need to be shared between teams working on new concepts. They do however, need to be good constraints. So what is a good constraint at this stage in the production lifecycle? It’s a constraint that can act as a quick razor to dismiss ideas. For example:

  • Genre.
  • Functionality requirements.
  • Team size and experience.

Bad constraints are not invalid constraints but ones that are more complex questions where the answers are unclear this early in the project. A good example would be setting a deadline, for example this product must ship within 18 months. There is almost certainly a constraint on the amount of time a project can take to make it to market in a business but estimates of this at an early stage in a project are going to be completely wrong. People deal with unpredictable things that need to fit into a fixed timescale by being extremely conservative, which is probably not something you want at this stage in a project where there should be maximum creative scope.

Go Wide

It’s a truism that it’s quicker to explore a space by splitting up and taking different sections. Double Fine’s Amnesia Fortnight is a good example of how this might work in practice within a small/medium sized company. Likewise Vlambeer  demonstrate that even as a tiny studio by severely limiting the amount of time you spend on a prototype you can hit many different ideas including some that become successes. In an ideal reality concepts should be something that are being developed all the time. Who doesn’t have a book of design ideas juggling around in their head or transferred to paper? Creating a prototype is more time consuming but critically allows a better understanding of how well the proposed idea meets the constraints and how feasible it is for a given team to develop. The more prototypes you can create the better you have explored the space and the more likely you’ll have come across the true maxima in that space. For larger companies it makes sense to have many small teams prototyping at once and as one or more ideas become more concretely ‘the best’ begin to structure those teams around moving them into pre-production. Sadly what you’ll mostly see are a lot of companies that have one small team working on one particular idea without really bothering to more fully explore the design space. This usually results in companies paying lip service to the production lifecycle without really buying into it because there are no real alternatives to the one project in flight.

Ideally what a developer is looking for is for the lifecycle stages to act as a funnel. As the stages are progressed you gain more information about how well the idea meets the constraints and the teams ability to implement it. So as you move through the stages ideas are discarded as they are found wanting.

Game Engine Wars

March 22, 2014 — Leave a comment

GDC has bought with it the exciting news that many companies that make game engines are following in Unity and Game Makers footsteps in an effort to “democratize development” as Unity’s CEO David Helgason puts it. Most are following a subscription model with a variety of price points having been announced. This is great news for developers as access to professional quality features, cross-platform development and increased productivity just got a hell of a lot cheaper. I can get a fully featured game engine with full source for less than I spend on my internet connection per month. That’s pretty crazy.

The main downer I can see at the moment is most companies seem to be competing on cost rather than productivity. Wild eyed developers who see the shiny features and triple-A titles that the engines have powered are already announcing the death of Unity. In truth though the reason you buy an engine off the shelf is to save yourself time and money building, maintaining and improving one of your own. Most games companies are interested in making games not technology. As such cost is only really an issue if you end up spending more money than you save in increased productivity. Even at the indie scale we’re talking about such small number differences (tens of dollars a month) that even a mediocre productivity enhancement in a more expensive product will more than pay for itself many times over. Given the price point differences the cheaper end are really saying to me “look we know our product isn’t great but at least it’s cheap” only the cost saving isn’t radical enough to offset the potential loss in productivity between platforms. For example at this stage Crytek would have to pay me to use their engine over the competition. Their tool is just not as usable, which is not to say it’s a bad engine, because it isn’t, but the UX is just terrible.

Bad UX is a typical problem of internal tools. They are built in an ad-hoc manner to a “just good enough” standard and are often just plain terrible from the perspective of the user. Typically horrors involve choice paralysis, bugs and lack of a well designed workflow that matches users needs. Most companies survive this because they have a huge amount on institutional expertise to guide new users and new projects through the complex maze they inhabit. This knowledge also tends to be tribal, passed on by word of mouth and custom rather than by good documentation. As soon as you can’t rely on this institutional knowledge you are basically screwed and your productivity is going to be very bad until you learn it. This has historically tended to be a big problem facing teams adopting internal technology and is an even bigger issue if you are licensing someone elses technology. The reason Unity currently has far more users than other engine companies who have also had free offerings for some time is simply that their mission has been to empower developers so their product is just easier and better to work with.

I’d also be very skeptical about getting seduced by revenue sharing schemes. 5% gross revenue is an awful lot of money to ask and could well push a developer into making a loss rather than a profit on their game. For example you make a game in one year and sell $100,000 worth of copies. $30,000 of that will go to distribution (e.g. Steam), $5,000 goes straight to Epic (plus the $240 you spent per month) leaving only $65,000 to account for marketing, the creation of the game (you’re going to pay yourself right?) and any profit you want to actually make. For Unity the upfront costs are higher but that 5% cut is gone so rather than costing you $5,240 you are only spending $900. When your margins are slim that’s important.

A Wishlist

So what would I like to see from an ideal commercial game engine?

  • A company that puts empowering developers as their first priority. Without this the project is doomed. The entire mission for any new feature should be to make the UX as good as possible within the other constraints. The tools and code should be extensively documented and that documentation should be easy to search and use. Video tutorials and regular education opportunities would be excellent. Further support for the community is a must as very often people will solve each others problems.
  • A clean architecture for making games. This essentially means that the process of creating a new game entity should not be unnecessarily convoluted nor should the resulting entity be polluted with lots of unnecessary stuff. I’m very much biased towards engines that make use of an entity-component system these days. The architecture should make inter-entity communication simple and event driven. There should be templates for scenes and entities which provide good support for procedural generation. All the engine code should be well tested, by which I mean it’s covered by unit and integration tests further it should be easy to write and run these tests on game code.
  • The engine should be fast. Game developers still want to push hardware particularly on fixed platforms like consoles. This means at the very least the engine needs to be multi-threaded probably with a generic jobs system to make use of the cores that are available on various platforms.
  • The engine should be portable. If it can’t build to consoles, web, mobile platforms, Linux and desktop OS’s then that’s a bit of a deal breaker. Not because you necessarily want to deploy to all those platforms but because having the option means you can should your companies plans change. This is important from the perspective of productivity as porting a project can be an awful lot of work especially if you need to learn a new engine to do so!
  • Iteration times should be blazing fast. Data should be editable on the fly and it should be ludicrously easy to experiment with ideas. It’s even better if code can be live reloaded, usually from script to avoid the pitfalls of compilation where certain cases will force you to tear down everything.
  • It should be easily extensible. An editor you cannot customise is pretty useless. Doubly so if you want to fit it into any sort of Continuous Integration/Deployment or want to implement a more complex build process.
  • Integrated. At a minimum the editor should support various forms of source control. Support for other popular developer tools out of the box would be gravy.
  • Source access. Big, ambitious projects will almost always need to modify the engine internals.
  • Feature rich. This comes last. Shiny features are no good without the above. Unity has amply demonstrated you can have a feature rich editor simply by empowering developers.

Now that these opening salvos in a battle over license cost have been fired we’ll hopefully see a wider war waged on empowering developers with tools that really enhance their productivity.

In this post I’m going to continue setting up some ground work to talk about Agile and Games Development by discussing the Game Development Lifecycle. A lifecycle in this context is the identifiable stages of production a project moves through from initial conception through to shipping (or going live in the case of services). I think the games lifecycle is pretty much divorced from the project management methodology you follow. There are simply several stages a game goes through whether they are explicit recognised or not. Much of what I write below is idealised in order to illustrate what I think the stages are and what happens in them. I’ve also deliberately ignored stuff like marketing as I’m no expert and it’s something so dependent on the chosen business model.

Here we have the lifecycle:


A couple of initial things to note off the bat. Firstly there is no scale to this diagram it ultimately captures the process in a fractal manner. As you decompose a game you still need to go through all of these steps for each component of the design. For example if you are adding a new feature to an existing game you still need to work out if it’s a good idea or not so prototyping is only sensible. The second thing to note is that the transitions and where exactly a game is might not be clear in any particular organisation. Some organisations are very formal, have very specific hand-offs and might even abandon work (but keep the game artifacts made). Others, particularly in smaller teams can be very fluid and the move from prototype to shipped product is a series of refactorings of the game. In my opinion almost all games go through these lifecycle stages and quite a lot of project cock ups come from not respecting the limitations of each stage. For example if a project goes through a sudden large pivot in development during some of the latter stages then it’s behooves people to recognize that they will need to drop back in the game development lifecycle for substantial portions of the game to prove it out again.

Moving from left to right through the stages in the diagram should lead to a firming up of the game ideas. It’s an oft said thing that the initial game concept bears only a passing resemblance to the final game and that’s because ideas are just the starting point. Ideas need to be tested and refined, preferably in the crucible of real player experience. This is one reason why putting a massive amount of time into a monolithic design document before anyone starts making anything is a terrible idea. Moving through the lifecycle stages should also firm up knowledge about when the game will be shippable and the scope of work remaining. For a lot of projects this doesn’t happen though and I think a decent Agile approach that takes some ideas from Lean would help approach the lifecycle stages with the right mindset.


The cornerstone of any project but also the least important part. Ideas are ten-a-penny and it’s the ability to take that idea and build something good from it that is hard. Sometimes the team you have might not be a good fit for making a particular idea or the resources required are unrealistic for what you want to achieve or there is no real market for your idea. There are lots of reasons not to pursue an idea but at this stage many benefit from a little making to gain a better understanding of what might be involved. I’m a firm believer that there is a lot of value in a failed idea and even more value in having a whole bunch of ideas you like in existence as prototypes. Ideas should be given a quick sanity check before moving onto the next stage without getting too involved in details that will likely change further on in the lifecycle anyway.


Lets make a game! In game development it’s the job of a prototype to take the core game ideas and demonstrate that the team is capable of turning them into something fun. This is necessarily messy and exploratory. It’s also an ideal time to stop spending more money on an idea if it seems to be going nowhere. I’ve written at more length on the value of prototyping to both individuals and businesses as well as having spoken about my own experiences. The end result should be an entry in your prototype repository and a decision about whether or not the prototype was deemed a success. Prototypes are also very useful for securing funding to take the game into pre-production as well as validating your game idea by letting real people get their hands on it.


Pre-Production begins when you take a prototype and decide to make it into a complete game. It’s the process of taking the core game ideas, refactoring them and expanding on them to create a meatier game with the view to nailing down most of the game systems and features. As this progresses the underlying technology is generally refactored as well, to make it technically better and suited to the creation of the large amounts of content many games need. The goal of pre-production is typically to end up in a position where the majority of the work remaining is content creation without large changes to game features. Usually this culminates in a ‘vertical slice’ of the game containing every aspect demonstrated at production quality in a ‘one level’ run through. Making a ‘vertical slice’ also exposes the weaknesses in the technology and content creation pipelines that need to be fixed before the game should be put into production. There should be further validation of the game with lots of real people all the way through this process as the game changes and by this point you should have a good idea of the quality of game you are going to put out.


Production is the point where you get hard to work at cranking out game content which is often the most time consuming part. At this point it can get incredibly expensive to make relatively innocuous seeming changes to the game design. For example altering the attributes that define how a character jumps at a late stage might mean you need to rework all the content in your game. Ouch! Ideally people not concentrating on making content or supporting content creators will be fixing defects, optimizing the game, improving the user experience or ‘juicing it‘. Hopefully it goes without saying that you should be putting all this new content in front of real people all the time to validate that it’s fun and works well with the game pacing (e.g. everyone fails then gives up on stage 3, maybe we should fix that).


Polishing is the final step that takes a game from being good to great. It’s adding more ‘juice’, improving the user experience, making sure the game pacing is great using feedback gained from playtesting with real people, squashing as many defects as possible and making sure the game runs smoothly on all targeted platforms. A lot of the time this runs in sync with production as some content is often finished before other parts. Although a bit of time at the end of a project dedicated to making the game much more polished can make all the difference. A word of warning though. Games never feel finished to the people working on them. At some point you just have to stop and put it out into the world.


Champagne or shame this is where the rubber hits the road and your game either crashes and burns or achieves some reasonable commercial success. It’s also the hardest point to reach for all sorts of reasons so it’s quite an achievement to be part of a team to ship something even if it’s not a commercial success.

It’s fantastic to have a game where everyone on the team is involved with multiple aspects of the game; we’re already a team of generalists, with designer-artists and programmer-designers and the like, but the small team fosters an environment where everyone gets intrinsically involved in everyone else’s business, and I think it made for a better game.

Q&A: Hearthstone‘s small-team success at big-time Blizzard

Eric Dodds on Hearthstone Development