Archives For April 2014

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.

APB Postmortem

Click through to a bigger version so you can actually read the text.

During the development of APB we had a whiteboard in our kitchen/break area on the third-floor of Realtime Worlds offices that served as a bit of a community scratch-pad for daftness. This particularly entry was started by me after we shipped but just prior to our investors pulling the plug and plunging the company into administration. The contents are contributions from all the development staff who worked on APB. We also had a “What Went Right?’ board which is sadly consigned to the mists of time.

The complaints can be broadly broken down into three areas Design, Business and Production. All opinion from here on is my own and comes with the caveats that everything happened at least three years ago and I’m writing from my own specific perspective. I worked on APB for five years as a Software Engineer specializing in Gameplay by the end of which I was probably doing a job closer to that of today’s Technical Designers.


“What IS APB?”
“No clear vision”

I think this is key, naturally, because I wrote the first question! The project went under at least two major shifts of focus in the five years I worked on it but only had one (bad) prototyping period. The creative vision was extremely woolly and the end result is a mediocre third-person shooter surrounded by some odd and mismatching features. Each time we refocused we should have sat down and reprototyped the new “vision” extensively both to get a firm idea of what we wanted to make and also to know what we needed to build. This lack of cohesive and shared creative vision has been the scuppering of a whole bunch of projects I’ve been a witness too.

“Overwhelming arrogance across the board in the face of criticism.”
“‘As Designed’ and ‘Post Launch'” – Unpopular ways to close design defects.
“It’s not that type of game.” – A phrase often uttered in the face of criticism.

In my experience I’ve not seen very many development teams who weren’t very aware they were making a lemon. APB’s was no exception and our bug database teemed with obvious design flaws and people voiced criticism of the game even before we had a whole load of beta testers giving us very valuable feedback. Internal feedback is too easily dismissed and by the time we got external feedback we were basically too busy fixing defects and optimizing the game to make any sweeping changes. In hindsight the writing was on the wall for the company about 6-8 months before APB shipped. The key take away here is that criticism and how you use it should be the defining factor in how you should shape your game. That doesn’t mean you need to respond to everything people say or implement their suggestions but study the root causes of what is being complained about and look for ways to improve the experience. The very worst thing you can do with criticism is ignore it. One of the games main critics in the development team actually went on to be Lead Designer for the successful GamersFirst reboot.


“Not understanding what makes people pay money for online games.”
“Not enough value to pay an on-going fee.”

I actually think this criticism is wide of the mark. GamersFirst demonstrate very obviously that there is a viable business model for APB as they’re still running it three years later! Sadly it’s not the one we chose to use. Plus we made ourselves look foolish by telling people the game wouldn’t have a subscription and then having a subscription option as part of the business model.


Very simple, we didn’t market the game we had made, we marketed an ideal. If we didn’t have a design vision we had a very clear vision we marketed which was essentially GTA online. We setup elaborate videos, had tightly scripted demos run through by our ‘Publisher QA’ that involved shooting to miss a lot. If we had successfully made that game we’d probably be rolling around in piles of money and I’d be writing a very different blog!


“Software Engineering versus Games Development.”

I spent a lot of my first year at Realtime Worlds exhaustively writing Requirements, Specification and Designs for everything I made. To the point where I’d have to send documents out for review and sign off. I’d get revisions back for rework with no substantive disagreement in them other than grammar use! It was a colossal waste of time and resources as well as being a known about and demonstrably bad practice for software development. Documentation isn’t a terrible thing but Big Design Up Front (BDUF) is. This will be a reoccuring theme.

“Not enough iterative development/prototyping.”
“No #1 focus on fun gameplay.”
“No focus on core gameplay.”

Its no accident that I’m a big fan of making things to prove they work and learn about the problem space. APB was very instructive about the problems that can be created by designing something, implementing it and then calling the results done and good. BDUF strikes again and in this case made worse by being in siloed teams. At one point the Gameplay Engineering team I was on had a pretty tricky working relationship with our Game Design team! This is not a conducive setup to making a good game! Cross-functional teams that are genuinely collaborative just work much better. The sense of shared ownership and ability to rapidly iterate on something make for better games and a shorter development time.

A consequence of siloed teams that couldn’t iterate is that our core game never got much love or attention. Sometimes it also felt like people didn’t consider it a problem. For example the first thing suggested by one of the senior designers to work on after the game shipped wasn’t an improvement of the core mechanics but a Zombie themed mode! After APB launched along with a bunch of other people I put together a proposal about how we could improve the core game. We proved the effectiveness of a cross-functional team freed from the constraints of bureaucracy by improving the core experience an awful lot. Sadly only a small part of this made it out before Realtime was shuttered and a lot of the work we did was incorporated into the first few released of APB: Reloaded.

“Hierarchical Management Structure.”
“Branching by Team rather than Feature.”

At first these two don’t seem related but they have the same root cause. As the reliance on BDUF and siloed teams suggests we had a deeply old-school approach to development right down to running the closest thing to a waterfall methodology I’ve actually seen in the wild. Hence why we ended up branching by team rather than feature and had a overly heavy management approach. I won’t labor the point because the problems associated with this approach were well documented decades before we used it. The solution is to become more agile.

What Went Right?

Actually an awful lot. A lot of the technology in APB has still yet to be surpassed. The level of customization was outstanding, not many games ship with a music sequencer! There was a decent niche game under the baggage of a bunch of poorly integrated systems that the GamersFirst guys appear to have made into a sustainable free-to-play business. There are a bunch of triumphs against adversity in any failed project and APB was too choked full of talent for that not to happen.

When you start to make a prototype one of the first decisions you have to make is which medium to use. This might seem like an easy decision to make, just pick your preference and roll with it but I think there are a few more subtleties to it born our from my experiences of the various mediums. I want a prototype to demonstrate that the game idea I’ve had is good, that I and my team are capable of building it and that there aren’t a bunch of crazy unknown issues lurking to catch us out down the line. It also shouldn’t take too long to build, otherwise we’re just making the game. Ideally I want the lowest cost solution that gets me sufficient information and that differs per project.


Digital prototypes are ideal for video games, right? After all we’re trying to make a digital game?

Well yes and no. Certainly making a real videogame as a prototype will get you the most accurate information about the game you intend to make. The largest issue for developing a digital prototype is cost. It’s by far the most expensive option. Firstly because it’s much more complicated to make a digital game. Secondly because the expectations in terms of acceptable production values are higher particularly if you want to test the prototype with real people.

As such we only really want to use digital prototyping when the other methods wouldn’t work. In reality this boils down to interactivity and how close the prototype will resemble the final game. The more realtime interaction the game or feature requires the more you would have to abstract that interaction for it to work as a paper or whiteboard prototype. That abstraction comes at the cost of real knowledge about the game since we’re no longer dealing with the game as it is going to be played.

Another danger with digital prototypes is disappearing down the rabbit hole and not limiting your development. It’s extremely tempting to keep working on an idea for a video game once it exists despite things not really working. “If only I had <feature d> then it’ll be good… *three months later*… if only I add <feature x> then it’ll be good.” To avoid this feature creep you need regular evaluation of the prototype with decision makers. You also need to accept failure. It’s a good thing to find out your idea is not viable quickly. This can be a problem with the other mediums as well but in my experience videogame developers understandably get caught up much more easily in their chosen medium.

For example a team of five of us worked for three months at CCP to make a multiplayer prototype of some potential avatar based gameplay for EVE Online. In essence you explored an extremely dangerous environment as a group in order to salvage ‘awesome stuff’. We could have prototyped this quite easily on paper as a boardgame in much less time but you would lose quite a lot of the feeling we were attempting to create in being confined and exposed to danger as a group. Plus we wouldn’t have come across some of the technical challenges we faced when implementing it. This all fed into the final proposals we made to the Executive Producer of EVE who canned our project because we didn’t have the man power to produce it. A good decision and a good result for the prototype.


Paper is awesome, nearly aprototypingnyone can make a game just using their imagination, paper, scissors and a pen.

Paper works best for prototyping game systems that work at a slightly slower rate than most twitch games. However there are often system in games that actually work in a way that’s easy to translate into the turn-based mechanics of card and board games. The problem then becomes abstracting the twitch elements from the game in such a way as you can be confident that you are modeling the rest of the game correctly. The more integral the twitch gameplay is to the game the less this is acceptable and the more attractive a digital prototype will look. Even if the game works at a pace that is amenable to turning into a board or card game you still might need to simplify it to be fun as a game in that format. People are less capable at complex maths than computers, even a slight increase in complexity of a game system makes turns drag, the game hard to understand and hard to pick up. This can be a good revelation though as very often in games we want people to be able to intuitively understand their systems and those with too many hidden variables become increasingly hard to fathom. Further simple systems that still produce the required ‘simulation’ or feature are much easier to maintain and balance.

The image on the right is an example of a card prototype I made for a revamp to the hacking mechanics in EVE Online. The system as it stood involved a skill check on a timer and after a designer defined amount of successes you had hacked the item in question. Very simple and worked well but it was also deathly boring. In revamping the game system I reimagined it as a simple ‘procedural death labyrinth’ and as the system was turn based it was very easy to represent as a card game.

Actually making and iterating on a series of prototypes was done over a couple of weeks and involved my entire team plus a couple of game designers from other teams. We also playtested the game with a variety of other people in our office not only to get feedback on the game system but to spread understanding of what we were going to build. Once we were pretty happy with the gameplay we had prototyped we quickly moved on into actually making the system. There was a really short timescale to make this game system and I credit the vast majority of the success of the game system with players to the time we spent prototyping right at the beginning. It gave us the confidence to power into implementation with a strong, shared vision that we knew would work despite the full digital version only really coming together in the last week or two.


To me Whiteboards are the place to design and prototype details in a Just In Time fashion. They are great for quick, collaborative sessions where you are trying to build a shared picture of what the intimate details of the immediate work are. Most of the time I’ve used them as a way of explaining an idea through a series of pictures or a diagram that can be changed to show the state of the game you are currently talking about. This can be particularly useful to work through several different ideas quickly in order to pick the most viable for a first attempt at implementation. They are also really good for collaboratively designing UI.

However using a whiteboard is also the most approximate form of prototyping. Very often you’re not exploring the game system itself but how it appears and works from the point of view of the end user. They should be used liberally but in support of other forms of prototyping rather than instead of them.