Making an Isometric Game


To develop STASIS, Chris used Visionaire Studio: amazing tool allowed him to create it by himself, with no in-depth programming knowledge.

When we started on full time game development we made the decision to move over to Unity. I’ve used Unity for many years for client work in the 3D industry, and we assumed that the flexibility of this immensely powerful application would facilitate a better game. This choice also meant that Chris could work on producing the graphics and I’d work on implementing them in the engine programmatically. This is the same partnership arrangement that we’d used in our previous careers – so it seemed like the right way to go.

As a programmer, I’m always keen to implement everything myself and rewrite the engine from scratch (to some degree). This time, I chose not to fight the way Unity works and do things the Unity way.


Start of technical babble.

CAYNE’s isometric framework is simple in implementation.

A key insight into the process of making this game so rapidly was to separate the graphics from the scene events and the managers.

To begin, we check the config.ini setup. We then load an ENGINE scene (this ENGINE scene also contains all of the engine logic for the game). ENGINE stays resident for the entire game and holds all of the managers as well as the GAME STATE setup.

This is great because dialogue, music and some sound effects can exist over scenes, so if the player loads a new room then the music doesn’t end abruptly but carries on seamlessly. This applies to dialogue as well.

Once the ENGINE has loaded, it will then check the GAME STATE and load the correct scene. Interestingly, Unity have made this process even easier with 5.5+ so I assume this is now the default workflow.

An important hint for developers is to work out how to store and manage the ‘game state’ early on. Don’t leave saving and loading until the end of the development cycle – CAYNE loads and saves the state constantly and because we did this early on, we could make sure that it was working correctly. In a game that relies so heavily on subtle variable changes this was a godsend. In an adventure game, if a single state or value is off then the entire game may break!

Each scene contains its own path-finding graph, the graphic and scene décor. This along with an event script that manages all events in this particular area. The event script is crude and doesn’t contain any management code – it only contains logic for the scene. The actual managers exist on ENGINE so when each scene loads it checks in with the ENGINE and recalls the game info it needs.

Doing this separates the managers from the specific scenes, which allows us to make game wide changes on a few scripts and have them affect the entire game.

Furthermore, input is managed at a higher level which means that the path-finding solutions are handled on the ENGINE. In fact, Hadley doesn’t even exist in the scene itself, she exists at a higher level and is merged into the scene at run-time and out of the scene once the player loads a new one. This further accentuates our philosophy of separating the graphics (scenes) from the meat of the game engine.

We can then decorate the scene and add detail inside the Unity editor, which is where Unity excels. We found this rapidly allowed the testing of an effects look and feel. Don’t feel compelled to build your own game editor – once you do things the Unity way, you’ll see how powerful this engine really is. I feel for a graphics heavy game that this is the best approach.

In terms of the scene itself, CAYNE is a 2D game. What we mean by this is that each area is a 2D pre-rendered scene produced in 3D Studio Max. Hadley is 3D, which allows us a far superior animation than we could achieve in STASIS.

We stuck with 2D for two reasons: first and foremost, Chris is a 2D artist and this is where he excels. 3D environments require a lot more design input into the game engines as well as substantial low poly modeling.
Secondly, there is a certain magic that still exists in 2D. Every room in the facility is handcrafted and each item or element is deliberately placed in the design. To achieve this in the engine, we have used Unity’s UI Canvas tool. An image is loaded in the Canvas and scaled correctly. We then load a custom Shader, that only accepts shadows, which has Hadley cast a 3D shadow onto a 2D plane to further integrate her into the scene.

What the scene actually looks like 🙂

I found that Unity’s built in Nav Mesh was not suited to a node specific game. Hadley needed to walk to exact locations on the node grid and the Nav Mesh didn’t work well for this. I liken it to hitting a nail with a bazooka – Nav Mesh seems like overkill so we build our own simple Dijkstra based solution.

There is a developer’s console in CAYNE. You can access it by holding shift and hitting tilde ~ This allowed me to test CAYNE at run-time (even outside the Unity editor). It also allows jumping to any scene, adding inventory items, testing music and even interfacing with the game state and variables.

You can access this by holding down SHIFT and pressing Tilde (~)

End of the technical babble

We finished CAYNE in just 11 months from concept to completion. We did spend an additional 3 months testing it and getting all of the bugs squashed. Testing it on 3 platforms (Windows, Linux and Mac) has gotten a bit tiresome but it allowed a day one launch.

We’ll be using the exact same framework for BEAUTIFUL DESOLATION. We plan on adding further enhancements like characters that walk around the scene, as well as foliage, colored shadows, day/night cycles plus many other features to make the world feel alive. Producing CAYNE allowed us to iron out most of the implementation issues and will let us get right to the fun stuff immediately.

Read More


During pre-production we decided that we wanted to create a unique look for DESOLATION. Due to the real-world appeal we wanted to achieve, we felt that the design should be grounded in reality.

I’ve always been fascinated by the idea of film miniatures. The incredible model work on early films has always given me a sense of wonder. I’m the guy who watches the hours of features on the Bonus DVD.


Working in a post apocalyptic world gives us SO many incredible opportunities to work with miniatures. It starts with an idea. These can be as simple as a scribble on a napkin or a more complex 3d recreations of the scene we’re going to create. These concepts then allow us make educated decisions about what we need to create and the final locations we’re going to put our model in. Once we have an area fleshed out it’s off to the model shop!


Model kits are combined in unconventional ways in a ‘kit bash’ fashion. Paint is then applied with an airbrush, including additional details and weathering. We also include a destructive phase – that involves matches and a hammer (you’d want to see this!) – and then more paint.


How exciting it is for us that we get to use actual locations in South Africa for our game? The locations could be as simple as an interesting construction site, or a pristine beach. The human brain has a difficult time distinguishing the scale of an object if there is nothing familiar to compare it to. Knowing this rock could become a building sized boulder, and a sand eroded cliff can become a mountain range.

While BEAUTIFUL DESOLATION is only seen from an isometric angle, the model is scanned in 360 degrees giving us even further freedom when putting the scene together.


All of these photos are taken into our software which then outputs a dense 3D model and texture generated from the photographs.

This ship (above) and its surroundings have over 10 million polygons! To put that into perspective, a normal AAA game character will have around 40 000 polygons.

Once this has been set up, additional details to provide the needed scale are added. Grass, water, and other natural elements are placed, and any story elements are integrated into the scenes. From there it gets painted over and taken into Unity where another detail pass of 3D objects, particles, and finally lighting through the use of normal mapping ties it all together.

Every image contains a piece of Africa – a moment that we have captured forever.


Read More

“Looks like you mashed some poor fellas dog, sarge”

I fell in love with Blizzard the first time I saw the Starcraft introduction movie. It perfectly encapsulated the world that they had crafted. The marines weren’t just sprites, they had character!

When we initially started thinking about how to present the world of BEAUTIFUL DESOLATION we wanted to do a film style trailer. This trailer needed to show the fantastic developments The Penrose brought, as well as the journey into a post apocalyptic future. We needed to create a variety of visceral scenes that told the back story to BEAUTIFUL DESOLATION.

The first step was creating a script that would dictate how best to tell this tale in a few short minutes. Once we had the script in place, I put together a very quick pre-visualization animatic. This allowed us to adjust and rework the timing before the detailing and rendering process was undertaken.

We took extra time to add in detail that may not be the focal point, but without these, the scenes wouldn’t have been as well rounded as they needed. This included different operating systems and applications on the varied monitors – also note the tiny logos of each competing corporation.

80’s logo ideas
Computer interfaces for background displays

Post apocalyptic Africa was achieved using matte paintings. This technique involves a painted image that is projected over 3D geometry, allowing movement through a seemingly still painting.

The final video is the result of hours of work and shows the quality we’ll be showcasing in BEAUTIFUL DESOLATION.

Read More