Archives For game design

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.

Spoiler Alert: I’m absolutely going to ruin bits of the game in this post if you care about such things. All the spoilers are below the fold though.

I recently spent several hours playing through and thoroughly enjoying The Vanishing of Ethan Carter by The Astronauts. It’s a really interesting game to me because the designers are really trying to build on previous narrative games to explicitly improve storytelling in the medium. I’m going to attempt to take a critical look at the game trying to keep in mind the 4-Layers approach developed by Adrian Chimielarz of The Astronauts and Thomas Grip of Frictional Games. You can see Adrian Chimielarz speak about his approach to pushing storytelling in games in this presentation from the Digital Dragons conference this year. It’s super interesting and well worth taking the time to watch.

Continue Reading…

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?

Art in Prototypes

July 14, 2014 — Leave a comment

There is a persistent myth circulating in the videogames development community that you don’t want good art in a prototype. To me this is like saying you don’t want spaces, punctuation and paragraphs in a draft piece of writing. It’s simply not true and removing good art from a prototype hurts a games readability as much as removing punctuation does with good writing. What a prototype actually needs is the minimum amount of art for the game to be visual and aurally readable, and aesthetically pleasing. If your prototype doesn’t have these qualities you are actively making it harder for anyone playing or watching your game to understand and appreciate the design underneath.

Your Art does not have to be Complex!

This persistent myth seems to spring from AAA development where content has become increasingly complex and laborious to create so “no art” is a hyperbolic description of how much simpler things need to be. Prototyping is supposed to be a quick process of getting a minimal version of the core game to a decent quality. In this situation simplicity is king. If we look towards Indie games there are plenty of art styles that are extremely simple yet easy to understand and aesthetically pleasing. Thomas Was Alone is a clear example of a very straightforward art style which is supremely readable but still aesthetically pleasing.


Thomas Was Alone


Obviously Thomas Was Alone is a reasonably simple platformer but this is the final production quality art and it’s simpler than most prototypes! There is a lot you can learn from looking at games with minimalist art styles that translates into more complex styles, for example the way in which the characters are highlighted against the background to improve readability. This walk-through of an update to the Summoner’s Rift map in League of Legends demonstrates this really well.

More complex games are going to require more complex art to retain readability. One way to ensure readability is to make sure silhouettes are distinct. Low-poly, flat-shaded models create silhouettes as well as high-poly models with huge detail in their texture maps. Levels can be “grey-boxed” and minimally dressed to keep visual hints in place. In many ways we’re trying to boil down the art to the essentials required to explain and sell the game.

It also might be the case that you need nearer production quality assets (to give a good indication of final visual design) for example if you want to show the prototype off to investors or the general public. In this case it’s often worthwhile keeping simple assets for as long as possible so you can target the time-consuming art work to the parts of the game that will provide the most benefit.

Re-use Existing Assets

Re-use existing assets to get you going. For example Left 4 Dead was initially prototyped with the Counterstrike models and skins. I’m not certain exactly what they did but simple animations for attacks and zombie walk cycles are the sort of thing I would think about adding immediately. When I was prototyping new avatar gameplay for EVE Online we reused all sorts of assets from EVE and even some that had been created specifically for cinematic trailers. Similarly some of the assets used in the EVR prototype came from EVE.

There are also lots of digital asset stores that will sell ready made assets for games. Jump on them.

It’s important when buying or re-using assets to make sure that you’re keeping the visuals as coherent and readable as possible. Otherwise the assets are probably detracting rather than adding to the prototype.

Juice It

Art isn’t just assets, it’s the whole gamut of feedback and your prototype should feel as good to play as you hope the final version will. Simple programmatic techniques can breathe life into static assets. A bit of scaling and tweening can turn a sprite into a character.

But Keep Focus

Art in games needs to be complementary to the gameplay. The focus of a prototype is experimenting with and proving out the gameplay of what will hopefully become a full game. Art can make a game with mediocre mechanics into a good game but at this stage we want the art to play a support role in enabling the player to be able to understand and appreciate the game.

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.