It’s been a while since our last development update, but there’s a good reason for that… (And it’s not just the holidays we spent recovering from last year and doing a bit of research and planning). Be warned, though, this is going to be a long post!
Christmas is a time for modding “research” (and sharing of course)
We have been aiming to open up Off Grid to modders in as many ways as is possible and manageable for a small team like ours, and so the sprint over the Christmas break seemed like a good time to do some “research” by messing about in some of our favourite moddable games made by small(ish) teams.
We had a gander at games like
Kerbal Space Program, and
Cities:Skylines, who develop using Unity and have opened up a huge amount of their C# API to modders, but also, more interestingly,
KSP and
other titles are using Unity itself as the level editor for players (due to it being free to download and use - why build your own?!). As far as data and code modding goes, we started small with a tool mod for
Starbound (making the most powerful hammer in the known universe seemed like an important contribution to make ;P) and built up to looking at the quest, codec and dungeon modding structure to see what the good folks at Chucklefish have opened up with JSON and Lua for players to tell their own stories through missions and content.
Happily enough, it would seem the .xml data structures we are using already to store things like NPC personalities and the in game hackable DataPoints (text messages, emails etc.) will hopefully lend themselves quite nicely to a similar approach, and so next sprint we went into for January has been partially targeted at implementing a first pass at Lua scripting for character interactions with the aim of them being moddable… but I suppose we are getting ahead of ourselves…
UK Games Fund
We’d better start with the big news. We recently received a grant from the
UK Games Fund to further develop our game prototype. This of course meant some of what we had planned for January needed to go on hold, and instead, we needed to sit down and think through the best ways to use that money. We decided we’ll use it to build some of the missing things that require the most help from outside of our small two-man company, setting things up for level editing & modding support, and dealing with our interactive story introduction and tutorial, which will require good amount of animation, motion capture, and of course sound…
Updating the tech
To get started with this plan we realised it’s time to get our tech up to the latest versions. We’ve been in limbo with the old Unity 4 this far, as we knew the upgrade would require roughly a week of rewriting and refactoring of code due to the way Unity does some things changing significantly. The upgrade also required us to update the sound engine we are using, Wwise. And to do that we needed to get our sound designer to come along and make sure everything is still working like it should.
So, now that’s done, we are running latest Wwise, compatible with Unity 5, and also with the support for building audio for Linux. On top of that we also got our sound banks changed to a better compressed format, shrinking the game builds from around 1.2GB down to less than 400MB. That’s going to make things a lot easier to send over the Internet…
With Wwise up to date we finally had a chance to look at Unity itself. Moving things from one major game engine version to next one isn’t the simplest of tasks, and there are limits to what Unity’s automatic migration tools can do. We ended creating a separate copy of the project and testing different approaches to figure out the exact route we’d need to take to get everything running. A few days fiddling, hours of carefully reading through Unity’s change lists and a couple of tries later, thousands of compile errors in our Unity console had narrowed down to few warnings and things were good to go on the main project.
The main hurdle was dealing with any plugins we had around, sadly Unity doesn’t have much for package management or version control for them yet, so lots of the upgrades were a question of searching for any plugin files, deleting it from the project and importing it back again, moving things around by hand, and generally just guessing and trying until they were all running again.
There were also plenty of new changes from Unity’s side, inverse kinematics needed to be handled in different way so our character controller scripts needed a bit of reorganising. There were a good few simple fixes, things like level loading, and how transparency is handled in shaders, had changed and just needed us tickling a few lines here and there. However what created a bit more difficulty was that the way fog is handled is quite different now, and the shader effect we used for our data view relied on reading Unity’s fog settings to fade the data view out over distance. With a bit more research we now have new version of that shader, this time just calculating the distance from camera to which ever vertex it’s drawing on screen. Seems to look even better than what we had before so that was definitely worth having to rethink the effect and shader mechanics.
…and of course the light and lightmaps changed, as did navigation and occlusion culling and everything else. So all of those systems had to be re-tweaked and baked again to get things moving and looking like they should.
So after all that, things are now more or less up and running with the new engine version, and we are finally able to benefit from all the new features and improvements in Unity 5. There are a few issues that still need ironing out, the small differences in physics require adjusting things here and there, and we’ll probably want to redo our lights and take a better look at our camera settings at some point. But we’ll get those sorted out over time, and new Unity features like multi-scene editing are already making our life easier. And of course things will only get better when we have time to update our rendering setup and other camera effects to get all the benefits of Unity 5’s new lights and visuals.
(And with the sound engine up to date we can now finally make the Linux builds *WITH SOUND* that we’ve been promising all this time. That alone makes the upgrade worth it…)
Lua everywhere
Our old mission system relied on a bunch of custom C# code all around various objects and components in the level - a quick and dirty prototype hack essentially. Not the best setup even from our point of view, but completely impossible for doing any level editing support. The plan was to restructure all that into a single script, but to make things even better we decided to build it with the future modders and level creators in mind.
We always had the plan of using Lua scripts in data to allow triggering custom behaviours and reactions when the files are sent to different characters and devices. So if there’s going to be Lua support in the project, why not build the level & mission scripts around it as well? After all it’s an easy-to-read way of defining any data and at the same time a very flexible language for scripting even complicated mission progressions.
We’ve used another Lua integration package before, but for
Off Grid we ended up picking up the very nice
MoonSharp. Setting things up was a breeze, and we now have the first version of Lua-based mission scripting working. The long-term plan is to also allow defining most of the character spawn locations, items and data used in levels etc. in the same file, so that’s what we’ll try to get running this next month.
Oh, and while doing that, we also got the Lua support for any network devices in the game done. So DataPoints now have the option of pointing to a Lua file as well, and when any NetDevice receives the file it can run the Lua script to trigger different things. That has already ended up being part of the new way missions are running, but we’ll definitely find more interesting ways of using the feature (TROJAN anyone?!). And obviously connecting that with the AI to trigger character behaviours is on the plans as well, although we’ll have to see if it gets done in the next sprint as part of the level editing/modding work or if we’ll have to work on it a bit later.
Setting up a story
Hopefully the test base for the Lua and modding features will be (at least partially) building the interactive intro with the modding tools. Those of you who have played the early incarnations of the demo will remember the little storyboard/animatic at the beginning. Well, here it is in the flesh, sitting in Unity and waiting to be brought to life!
We spent a some of this last sprint setting up the Apartment scene, cleaning up models and lighting it. there is still a long way to go, but it’s great to see this new scene starting to take shape, we can’t wait to throw some code on all the objects in here!
…and then some small stuff:
Encrypting data files will now automatically generate proper encrypted-looking content, with all the PGP version tags and such in place. This means we don’t have to type all that random stuff by hand any more, and of course it’s also required for any dynamically-created data, like the procedural text messages we are sending to our NPCs…
That’s it for this time, we’ll be back in a month’s time, hopefully with some more news about how our level editing & modding tools and intro/tutorial scene are coming along!
