I worked with the Dirt 5 team during the pre-production and pre-alpha phase of the project. By the time I arrived the team had already settled on the locations for the game, the vehicle types & rough car list, the engine & rendering technology (internally developed), the Playgrounds feature, and the strategy to make the title more ‘sim-cade’ (like Dirt 2 & 3) in nature. The budget and timeline were also fixed, so the overall challenge was to squeeze out any additional creative solutions within quite a tight set of parameters.

My main involvement was leading a brand new design team and getting them to think about how to refine what we had into something that would align with the legacy of Dirt 2 & 3, and the course already plotted by the company. This mainly covered…

• A sponsors system in the career mode that was more developed and leveraged licenses

• The types of challenges needed in Playgrounds & prototyping to prove them out

• How the Playgrounds editor would work

• Considering options for online & split-screen multiplayer design

• The FTUE for the game

• A rough idea of a live-ops plan, and what content would be front-run in the design of the base game

High Concept & Game Hook

The project began in 2014. I saw roguelikes as a growing genre and as a space to innovate with a clear addressable audience. Our concept artist who designed the Mole Mech character, Matthew Beakes, used to play a lot of Spelunky circa 2009 when it was still a free shareware game. This had always stayed with me from the time we first began working together. Once Spelunky became a hit and Rogue Legacy also found success, I felt that there was a demand for increased use of procedural generation within games. Not least because online streaming was starting to take off and the potential for gamers to see varied experiences/runs online was compelling.

I wanted to do something with procedural generation that would give our game a chance of standing out. I am a big believer in really defining the ‘hook’ of a game in order to give a new title a clear strategic direction and marketable value proposition. After some thinking, I found the idea of procedurally generating enemy characters to be interesting. All roguelike games randomise maps & loot but the baddies are always identical. I was keen to try and find a way for enemies to be built out of components, so that there may be differences from run to run in the tactics a player may need to use.

Alongside the core game hook I really wanted to make the game sci-fi in nature rather than fantasy. There were already many ‘traditional’ roguelikes set in stereotypical dungeons filled with monsters and potions: I didn’t think me making another game just like this would be adding much to the genre. To innovate here, I set Underzone 100 years into the future. The player would go through a disaster stricken city where survivors were trapped in bunkers underground. The game play, whilst still being 2D, would take place side-on rather than top-down. This would create the illusion that the player was moving through different cross sections of the giant city whenever they died and a new level was generated.

Core Systems Design

Initially we prototyped the basics of a room based twin-stick shooter in which the player could traverse the ‘underzone’ with their mech character and shoot enemies.

Going from this point to a more comprehensive game design that crystalised the vision of the high concept was a lot of work. While other members of the team worked on art and rendering tasks, I fleshed out the design more fully. This broadly fell into a few key areas…

• Enemy generation & AI

• Player progression

• In-game economics

Player controls (movement, shooting, breaching, ect) required constant balancing and iteration throughout the project.

Tackling the enemy generation was a key challenge as the core USP of the product. We settled on an approach where there would be core archetypes of enemies. As is typical of arcade-shooters, each would have a unique shape and AI/behavior. However, each archetype would also be built out of (proceduralised) components, e.g. a body, fireproof armour, large/small engines and a certain weapon. This ‘genome’ of baddie attributes could then mutate from level to level and run to run, encouraging the player to vary their tactics.

The player progression loop was based upon the core activity of rescuing survivors which accrued XP. This XP could then be spent on a skill tree that would take the player many hours to unlock. Naturally, investing in this metagame improved the odds of survival in future runs.

The in-run economy was based upon collecting ‘salvage’ picked up from dead enemies. This salvage could then be spent at workshops and crafted into different ammo and upgrades. Originally the crafting system was quite complex, with different resources/currencies. However as the game more clearly became about pace and arcade-shooter play, I decided to simplify this system so the player could focus more on action and exploration.

Narrative Design

Based on the success narrative had added to other games on the fund portfolio, the decision was taken to invest in developing a story.

Underzone is predominantly an arcade-shooter, so I did not want to make the story a mandatory part of the game experience. However I did want to add depth to the world fiction and setting.

As the player progresses and spends XP they ‘rank up’. As they do, and then play additional runs, they have the opportunity to collect different narrative ‘nuggets’ (a la Bioshock) that allow them to gradually piece together the conspiracy that led to the disaster within the city.

My starting point with developing a fiction was large amounts of research into present day conspiracies and technologies that may portend the dark, futuristic, backdrop that provided the games setting. This research took me on a journey discovering the links between the Cold War, UFO’s, secret technology, 9/11 and the military industrial complex. Other pop-culture IP’s such as The X Files or Independence Day have harnessed these themes in the past. The difference in Underzone is it looks at the world through the lens of a ‘post-disclosure future’ and the geopolitical tensions that exist in a world that has been forced to ‘grow up’ during the 21st century.

As with the game’s design, I believed in hanging everything around a core ‘hook’. In the case of the narrative this meant asking an ‘interesting’ question with moral implications. That question ended up being: “what are the dangers posed to society/democracy by extreme military secrecy?”.

I then worked with experienced writer, Hannah Wood, in order to turn the research and direction into a cast of characters and plot. I then managed Pitstop Productions who provided all the voice acting, including casting, that helped bring the narrative to life.

I was approached in 2011 by a client wanting to develop an 'allotment simulator' that depicted rural British life. This was an interesting open-ended design challenge for me in terms of executing on a high-concept and delivering the final design solution. It was also a chance to create an original game for the iPad, which was an exciting new device at this point in time.

At the time, life simulation games such as Farmville were some of the most popular games online. After some mulling over the strengths of Farmville but also the differences inherent in the concept of My Veg Plot, I concluded that ultimately Farmville was all about the quantity of produce yielded: it is essentially a sim of industrialized farming where the player is always rewarded for producing more of something. The key difference with My Veg Plot was the idea of the village vegetable competition (a cliche of old-fashioned British village life). This meant that My Veg Plot was more about the quality of the produce grown, rather than the quantity. This strategic direction then put a spin on my entire systems design treatment in the project.

Like many F2P games in the genre, the player was encouraged to revisit the game regularly to make sure that their crops didn't die. However, when they did they were doing things like making sure they had the correct amount of water (in relation to the procedural weather) and checking the veg for pests and diseases. The better the player becomes at this, the larger and more healthily their veg will grow. This then enables them to win better prizes at the village fete and repeat the game loop more successfully.

I was part of the contracted development team to work on Lego Star Wars: Battle Orders in 2011. This was a game commissioned by Lego to run on the iPhone, and the (then new) iPad.

The game was strategy title for kids in which the player must overrun planets with their ships in order to set up a base on that planet that builds more ships. The (AI) enemy team is also trying to do the same. The goal of the game is to colonize all of the planets to defeat the enemy.

My role on the project was to provide internal management oversight and design all the levels using the Unity v3 engine. I designed all the level layouts on paper first and then built & tested them in the editor. I was looking for different combinations of planet sizes and locations that exploited emergence within the AI, as well as guiding the player into using different tactics as the game progressed. I then sequenced the levels in the correct difficultly order and tested this. Throughout the course of the game I introduced different hazards such as black holes and asteroid fields to keep the game loop fresh and interesting.

It was essential that the game conformed to very strict brand/IP guidelines.

The game was a big hit at the time and went to number 1 in the Appstore around the world.

In 2009 my colleagues at Remode decided that they wanted to 're-invent minesweeper gameplay'. Minesweeper was ubiquitous given its dissemination with Windows, but it never really had any graphical treatment. At this point giving puzzle games different graphical and/or narrative treatments as casual games was a viable thing to do so I was set the task of figuring out how to deliver that.

We hired Matthew Beakes as our artist for the game and he came up with the concept of 'exploding moles' that had overrun a small European village. He was also responsible for the whole whimsical Aardman inspired style of the game.

My role was to direct the project but also to break down the concept at a design level so it could be delivered. This involved all the UX/UI design, level design (using a custom editor) and some scripting.

The production took a total of 9 months and the game was powered by a custom C++/DirectX9 engine.

The game launched on Steam in 2010 (under the now defunct Blitz1up publishing label) and secured two retail publishing deals in North America & Germany.

Rotoblast was a VR game and my final year games project at Plymouth University. The game, including the hardware, was built from scratch in 4 months, part-time, from Oct 2006 - Feb 2007.

I'm still very proud of what we achieved with the project in such a short space of time. Back in the 2000's the games landscape was very different: off the shelf middleware such as Unity and Unreal was not available easily to small teams. Similarly, VR headsets with head tracking were far from ubiquitous and well supported by major tech firms like Oculus or Samsung.

These constraints implied that we had to be very 'clever' with the technology that was available to us and the time we had. The game was written in C++/DirectX 9, so needed to be simple, yet make full use of spatial awareness. The hardware need to frame and contextualise the experience in a way that was accessible for people to understand.

The result was a 'Puzzle Bobble' shooting game that took place in a 3D dome. The chair allowed the player to move 180 degrees through the environment with, as well as shoot the cannon. The head tracking provided intuitive aiming within the game world.

My role on the project was largely building the hardware and managing the team so that the vision for the game was crystallised without any loose ends within our compact timeframe.

The frame for the chair I got constructed using mild steel and an arc welder. A car wheel-bearing provided smooth rotation for the mounted seat above. A pulley system using a cambelt and an appropriately geared down 12v motor then actuated the chair at the correct speed. The motor was then hooked up to a relay system I wired to the pedals I found. For the shooting buttons I hacked a wired game controller and soldered in some chunky arcade buttons that the PC would read as USB input. I then created panels to cover all the innards and provide a safe and professional look for the public. The whole system could be assembled and disassembled for transport.

As a result of hitting our goals with the project we were invited to showcase it at two MCM Expos in Telford and London (UK) during 2007. At the time the Nintendo Wii was just launching and Dance Dance Revolution was very popular: the motion controlled/active-game era was about to begin. However no one had ever really seen or experienced anything quite like we had created. This meant we ended up with quite a crowd and stole a lot of public interest from the Nintendo Wii & DDR booths.

Prior to the MCM Expos I hadn't considered a career in the games industry. However after the project was over I realised that making games was something I wanted to do professionally and had I taken a first step into the field.