The Production Process developer diary banner

9th October Ė Making a Game

During our recent Q&A sessions, some of you have been asking about the process we go through here when we make a game, so I thought Iíd jot down some notes on how our production process works.

As with most things, it starts with an idea. Inspiration for a game can come from numerous sources. A good game designer will be looking at the world around them and seeing "systems": mechanisms by which things interact with each other. By understanding the systems we see around us every day, we can see how these systems can be adapted into games.

Prototype screenshots from an upcoming game
Prototype screenshots from an upcoming game.
Click here to see a larger version of this image.

Anyone can come up with a game concept here at Jagex; we take ideas from all sources. We have a short two-page document that highlights the core of the idea, why itís fun and why itís commercially a good idea. The concept then gets discussed by the Senior Design Group: a team of senior developers with a lot of design experience. We examine the likely pros and cons of the concept and, if we like the idea, itís pushed forward into the prototype phase of development. Only about 1 in 5 ideas makes it to the prototype stage.

Prototyping comes in two forms: physical and code. Often we start the process by building a physical design for the game. We've done this with miniature figures, hex grids, paper counters, wooden models... you name it. These physical prototypes are used to test out the cornerstone rules of the game and make sure they work. From here we move on to a code prototype and this is where the real work begins. A lot of what we do here is pushing the boundaries of what the Jagex library code can accomplish, so we have to make sure that the game is fun, the rules for the game work and that the code required to create them is possible. On average we discard about 25% of our games at the prototype stage; some may be picked up again later, though.

Prototype screenshots from an upcoming game
Concept art for an upcoming game.
Click here to see a larger version of this image.

Once this prototype is complete and the senior design group have agreed that itís worth taking forward, the design work of the game can begin. Up until this point we've had an idea about how the game will work and we've experimented with the core systems. Now we sit down and design the key elements of the game and write them into a design document. Previously the design was done "on the fly" as part of the work of building the game, but this has proved inefficient for us. We now try to capture as much of the design work as possible early on in the process, but we are aware that there will be changes once ideas we want to implement are examined in a real game.

We then build the game. This simple statement incorporates a lot of work. Graphics and audio work needs to be allocated, performed and scheduled to arrive with the developer at the correct time. We work using build iterations: we add something, playtest it and change it until it works the way we anticipated. Sometimes we need to completely remove elements we've added, because they just didn't work the way we thought they would. And so the game progresses: add, test, refine/reject/replace, test again and so on, until we've got the best result we think we can get.

The last things we do to a game are often the most important. We add the instructions, the tutorial and the Achievements at the end of the process. These are critical elements in the game to get right and we've learned the hard way what can happen when we get it wrong. We also spend a lot of time on polishing the game. Polish is the term the industry uses to describe all the small elements you add to a game that really make it feel like a high quality product. These can be as simple as a transition effect or a button mouse-over, or as complex as CGI video, but these elements really make the game feel finished and superior in quality. The customer rarely notices when polish is there, but they always notice when the polish is absent.

The last element of the process is quality assurance or QA. We are always pressed for time where QA is concerned; we could always do with more testing, but there comes a point of diminishing returns where the game is essentially "good enough" to release. The difference in quality between "good enough" and "perfect" is usually small, but the difference in terms of time is staggering. Nothing ever goes live as perfect as we'd like to make it, but the delay that would be caused in making it perfect would simply be too long.

So thatís a cut-down snap shot of the entire process. Concept - prototype - design - build - revise - build - revise - build etc., etc., etc. - test - release and then back to concept. I hope this has given you a good insight into what goes on here and just how hard the entire team works. Thanks for reading.

Mod Korpz
Head of FunOrb

Back to the top