To develop STASIS, Chris used Visionaire Studio: http://www.visionaire-studio.net/?lang=enThis 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.
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.
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.