Sprint Update - 15.04.16 - Showing off and being secretive

Top secret dev stuff

A lot of this month has been spent working on things we are under NDA over so can’t mention too fully yet.. but the time will come… and there is plenty of other interesting happenings to talk about.

What we did do…

Well, we finished up with the UK Games Fund and demoed progress so far at their event as part of London Games Festival last week. That went really well and it was great to meet some of the other devs that are part of the UKGF first round, many of which are making some very exciting things.
Shoutouts to our UKGF cohort co-conspirators, including Andrew Roper from Spilt Milk Studio, Billy Thomson and Martin Livingston from Ruffian Games, Andreas Firnigl from Nosebleed Interactive, Jon Olive from Mixed Immersion, Olly Bennett from Cardboard Sword. It’s going to be great to see where each of the titles from these devs are in 6 months time.



Intros and Interactions…
We have been working on the intro and tutorialising the first interactions in the game with snippets of story. This has been fairly experimental but we are already yielding some good results, we now have the game switching between interactive and cutscene animation comfortably…

We also haven’t wasted any time getting all the assets in place and ready for the rest of the implementation of the intro..

We have…Assets in abundance!

Completed mocap cleanup
We completed all the mocap and assets cleanup and imported them into the engine, everything is working as expected and setup for implementation, and looking good, even if we do say so ourselves!

Audio for the intro
This month we worked closely with our sound designer, Jonas, to set up all the interactive calls for the intro sequence in Wwise our sound engine.
Fingers crossed, with all the prep done we will be ready to go at it all guns blazing as soon as the new build of the engine comes in.

Simpler levels, more complicated systems to load them…

Moving things away from levels
Since many of the things we have in the game either depend on things we can’t give away for licensing reasons, or refer to other components with such dependencies, we’ve had to make sure the level scenes include only what’s absolutely necessary for building the levels, and everything else had to be moved away. Thanks to Unity’s recent support for loading multiple scenes at the same time, we could just use scenes for this separation. So, the level scene is pretty much just floors, walls, props, lights, and a few special objects used for setting up the mission, character spawn points and that kind of thing. Everything that is shared between all the levels, and the things that actually control the game, are in a shared ‘Utilities’ scene.

In addition to being pretty much required for us to be able to give away easy tools for building levels, this also has the additional benefit of making the level cleaner and easier to work with. As a modder, or player making your own levels in Off Grid, you don’t need to worry about our camera rig, or setting up different components on the player character correctly, or all the things related to our user interface controllers or inventory system. In fact you’ll never even see those in the LevelKit, we’ll just make sure all those things get loaded and set up automatically when you load your custom level in the game. Nice and simple!

Things are often more complicated than they sound
Well, simple in theory. Setting everything up for this required quite a bit of work on the game itself, none of our systems were built to work like this, partly because multi-scene support didn’t even exist in Unity until few months ago. So we’ve spent the last months figuring out what needs to be moved to somewhere else, what needs to be changed, and the correct order for loading things and setting everything up.

The biggest challenge was getting every system to find their dependencies, and to do it at the right time when those dependencies actually exist in the game. When everything was within a single scene, we could just connect all the dependencies by hand, and do the last bits of set up when Unity started the level, trusting that everything we need is already there.

However, now that scripts and components that need to communicate are in different scenes, references between them can’t be made beforehand because the different scenes are loaded at different times. The UI doesn’t even exist when the level geometry is loaded, and all characters, networks and other things get created even later than that. On top of that, all the scripts themselves needed to be separated as well. Any code included in the LevelKit can’t directly refer to anything else in the game as sorting out the dependencies to include all of the game’s required code in the LevelKit would, be a nightmare! SO we’ve written interfaces to allow things to communicate while breaking those dependencies.

So now, the level scene (made by anyone using the LevelKit we provide) only has the actual level geometry, plus some simple MissionObjects used as spawn points and other story & mission tasks, and a simple object we named MissionSetup where you can set up your mission Lua scripts.
All characters, networks and other things that are specific to a mission but don’t need to be included in the mission scene itself are only created once the game is loaded.

…and everything else, including our game systems, camera setup, inventory management, the actual mission system, sound engine stuff etc. is in the Utilities scene. Something you as a player or modder never have to worry about!

Here’s how it works (in simple steps)
In the flash of the last milliseconds of a loading bar…

• The Menu scene loads the mission scene (and then unloads itself)


• The MissionSetup script in the level scene loads the Utilities scene


• The MissionRunner script in the Utilities scene grabs any information it needs from the MissionSetup (all the correct Lua scripts and other things set up by whoever made the level)


• The MissionRunner starts a Lua virtual machine and loads the mission scripts into it.


• The Lua machine then uses that information to spawn in all the characters, items, networks and other things, and sets them up (connecting all devices to the right networks, setting up guard patrol routes and background information etc.)


• Once done with setting up the mission, it then triggers an event called OnMissionStarted


• Pretty much every system in the game is subscribed to that event, and on hearing “OnMissionStarted” now knows the level is set up and all the necessary things exist in it, so they can do their own set up and find what ever other references and dependencies they need (for example a phone will look for networks it can connect to)


• …and then we fade out the black screen and the game starts!

See, simple!

Loading custom scenes
We’ve also worked a bit more on our custom level loading. If you remember from the last month’s dev update (or figured it out from all the above talk about custom levels), we want people to be able to use our LevelKit to create their own levels, then package those into Unity’s AssetBundle files, drop them in a folder and get the game to then be able to find all those levels and be able to load them, for you to play and share with other players.

That’s all working now, although we’ve definitely spent a decent amount of time tweaking things around and figuring out what works and what doesn’t. We ran into some odd random crashes when loading levels, and it seems trying to load too many asset bundles using asynchronous loading crashes about 90% of the time… There’s probably a good way to solve that, but for now we just switched to loading them one at a time. We still have some odd situations where loading levels seems to try to do things in a slightly different order when doing it from AssetBundle compared to just loading the same level directly inside the Unity project. These things are pretty awkward to debug but everything seems to be sorted out now.

…at least as long as the Lua mission scripts don’t have any errors in them. The Lua machine will stop at the first error it encounters, and more than likely that means your mission setup doesn’t complete, so the script never triggers the OnMissionStarted event, most things you’d need in the level don’t get created or connected to each other, and everything just breaks. Of course that’s good indication that you may want to check your Lua script for errors, but it definitely doesn’t sound like the ideal way to handle small syntax errors in mission files! So we’ll need to get some kind of backup system in place, to at least notify the player about the errors and get them back to the main menu screen. That being said, most modding systems in games will refuse to load the game if they face errors in a mod, and direct you to the .log file. We will see if we can be a bit friendlier! :)

Other changes

Better sounding data
We’ve kept our sound designer busy improving things and reorganising the project. As an example, we’ve reworked our data view and the sounds for it, so everything now reacts to analog control from the gamepad, changing both the range of the data view and how it sounds. We also added different sounds for different types of data, so the less important types are more subtle, while the ones you might really want to go and steal are more audible and better highlighted. The data sounds now also are aware of your available connections, so you won’t hear data points from networks you aren’t actually connected to or don’t have access to. And it all takes your field of view into account as well. So you should pretty much hear the data you can see on your screen at that moment, and nothing else (unless the data points are right next to you).

The best thing is we no longer need to listen to the constant annoying beeping from the GPS location pings, which were created by every character in a level about once a second! All that data is still there, but with more subtle sounds and the range/filed of view filtering making sure it’s not all playing at the same time it means that hunting for important day can now be guided by the player paying attention to the environmental audio. Ear hacking, pretty cool!

Fancy graphics stuff
We’re also changing things to better benefit from Unity 5’s improved graphics capabilities. We have now switched everything to use the new deferred rendering, and also changed things to use a linear lighting colour space instead of a gamma-corrected one. With our limited use of textures that was a pretty simple switch, and definitely improved how the game looks with better lights and shadows and more visible detail. We’ll still need to do some tweaking on our lights and camera settings but it’s looking pretty good already.

The only drawback was that the shader effect we used for our data view ended up looking really flat in linear colour space, making it more difficult to distinguish things close to you from the ones further away, and causing the data points & trails to blend into surroundings more than we’d like them to. It was an easy fix in the end, though, as that shader doesn’t use any textures and doesn’t care about (or affect) any of the level lighting, we could just calculate the gamma correction within the shader program itself. You probably wouldn’t want to do that for any shader used in the actual levels, but it works fine for non-realistic visual effects shaders!

And thats it…

Thanks for reading, hope you found some of it insightful, and not too much like some kind of Star Trek-esque technobabble! The good news is with all this work now pretty much done, we will be free to iterate on (and talk more about) content in the coming months!

Catch you next time,
Rich and Pontus