Wednesday, 3 May 2017

Off Grid Sprint Update 03.05.2017 - #Winning

Our favorite part of April?  Bagging the Game of Show Award at Bonus Stage!  It was pretty sweet to take part in the coolest new indie games showcase to start - but to take home a prize?!  Awesome. 
We even got a trophy!




That was a great start to the month, but so, so much more has happened since then.  We’ve worked hard on improving the stealth element of gameplay, added to our level kit architecture, worked hard on the save system, and have gotten busy making more levels.  Read on through for all the nitty gritty and make sure you get to the end - there’s even more good news!  :)


Hiding in darkest corners

We’ve been concentrating our work on the data & hacking mechanics and modding tools for the past year or so, but as we are shifting more towards content creation and building levels, it was time to bring some of our original design ideas back to the table so we’d be able to make sure they are in place when we start designing new environments.

We’ve been describing Off Grid as a “3rd person stealth & hacking game,” but the stealth side has been fairly minimal, mostly just a simple line-of-sight check and relying on making sure you are crouched behind an obstacle to keep out of sight of the enemies.  There’s no advanced cover mechanics or anything like that.  However, we’ve always imagined the player hiding somewhere under desks and in dark corners when doing the hacking.  Much of the action in the game happens at night time, so there should be plenty of dark corners to hide in.  We just needed the “dark” part of that equation to actually make some difference…



And now it does!  The latest addition to the player’s app arsenal is a light level monitoring app, and the guards and CCTV cameras etc. will now require sufficient amount of light to see the player, so finding a pitch back corner somewhere to hide in practically makes the player invisible, just like you’d expect.

This one took a bit of figuring out, as we rely on baked lights across the levels to provide smooth bounced lighting, and also plan for user-made levels and environments which means however the light/shadow mechanic was done, it needed to be something that’s as simple as possible for the players to set up in levels. Setting up shadow volumes or triggers around the levels to mark the dark areas was out of the question - we needed a way to sample the actual light of the level around the player.

Luckily, that’s pretty much the same problem Unity (and ourselves) needs to deal with to allow the bounced, baked lighting in the environments to light up player and other moving characters.  They solved it using LightProbes, which sample the baked light around the level, and then the moving objects an interpolate their lighting based on nearby LightProbes.  We needed the LightProbes for the actual character lighting purposes anyway, and lucky for us, Unity’s API allows us to access that sampled data from code.

Even better, we can simplify things a bit compared to what the game engine needs for actual lighting.  While the most realistic option for our light/shadow mechanics would be to check the light level from the observer’s point-of-view, to check if the side of the player the guard sees is lit or not, that would have made it more difficult for the player to figure out whether the character is hidden or not.  So, instead of that, we decided to settle on the generic light level around the player, ignoring the direction, as that allows us to easily communicate the hidden VS not hidden state to the player.  When reading the spherical harmonics data from the LightProbes, we can actually ignore most of the detail, and just grab the first harmonic, which gives us a nice overall light level from all directions.  No need to worry about the directions or test things from the guard’s perspective.




The last piece was making it easy to get the LightProbes placed across the levels in enough detail for them to catch the nice dark corners.  If it were just us doing the levels, we could have just enforced some design rules of our own to make sure we have probes where we need them, and then placed them by hand (pretty tedious task as there can easily be hundreds of them around the levels, but still doable).  Off Grid is moddable, so with players making their own levels, we wanted to remove that tedium along with the testing & learning required to figure out where the probes are needed, and instead provide some kind of automated tool for the task.

The simple option would have been to just create a grid of proves across the levels, say one meter across from each other to all directions. However, many of the probes would just end up inside walls or in other places where they are either completely useless, or not quite where we’d need them to be. So we needed something that takes the actual environment into account.

Unity has a feature called NavMesh, which is used by the AI to figure out where the walkable areas of the levels are, and to plan their navigation across the environments. The NavMesh can be created more or less automatically, and will pretty perfectly match the scene.  Just what we needed!  We built a tool that reads all the corners of the NavMesh, then figures out the center points of all the polygons the NavMesh is built form, and calculates their center points.  Next, we add duplicates of all these points a bit higher up, about meter above the character’s head.  Then, we check though all these locations and merge together any that are way too close to each other to make any difference.  Finally, we just drop in some LightProbes, one in each location.  And everything can be done with a click of a button!



It’s not perfect, a well-determined level designer placing the probes by hand could probably achieve the same quality results with less LightProbes, but they aren’t too expensive to use, and in this case, the ease of setup for level creators outweighs the cost easily.

All of this is pretty much just a 1st pass at the moment.  We’ll iterate on the details and probably improve our tools over time, and of course, test the actual light levels where the guards should or should not see the player to tweak things until if feels right in the levels.

Tweaks & fixes

Playability on mouse & keyboard
While we’ve had mouse & keyboard controls in place for long time now, we were also hiding the mouse cursor automatically when the game started. This worked fine for in-game controls, but of course not as well for dealing with any menus and dialogue windows. So we’ve now replaced it with a bit more intelligent system that shows and hides the cursor based on if you are actively controlling the game with mouse or a gamepad, and if you are looking at a menu or not.  That should solve any issues and the game is now actually playable with mouse & keyboard as well.

Added quick “close” shortcut for some UI menus
Some of our newer UI menus and windows were missing quick shortcut button for closing the window. That’s sorted out now, and pressing B on gamepad (or whatever button is bound to “Cancel” action on keyboard) should close any UI window.

Optimized version of shader for lamps & other light-emitting objects
We have a fair amount of objects with lamps and LEDs that change their color, or are turned on & off (or blink randomly for nice effect). We decided to optimize these a bit and added a new material (and shader) just for this purpose, using Unity’s MaterialPropertyBlock feature to deal with the color & light emission changes. Not really a visible change for the players, so pretty much just a performance optimization & small change from level editing/modding perspective.

Increased spacing in file inventory to allow for longer file names & descriptions
The file inventory UI was packed a bit too tight so some of the longer file names and descriptions we had were truncated. We increased the spacing between file icons a bit to make space for longer names.

On Grid

In Off Grid, everything has to land on the grid, so to make stairways look consistent, they all have to take into consideration turns, platforms, edges and so on. 
After a few iterations of various parts to make handrails all tie in to each other, a good method was devised and the results are in… we can now scale the highs and lows of industrial buildings!




Some of the other refactoring done this sprint was with the shipping containers, making sure there were no gaps and that larger containers could be made from existing mesh parts quite easily.  With these, there is the chance that some containers could be walked into and explored during gameplay, so the doors can also be in an opened state.




Speaking of containment, to keep a few of the levels secure, we needed to make some barbed fences.  But where there is a will, there is a way to get into any fenced complex - especially when there are a few holes in the system…



Save System

This sprint Harry has been working on a bunch of
interesting systems, the most prominent one being continued work on the
save system.

Saving in games is one of those systems that’s best
done as soon as possible.  Saving for us has been quite a big task (and
we’re not yet completely finished!).

Here’s a list of some of the things that our save system has to handle:
Information about the player state
Position / Rotation
Inventory
Data Inventory

The state of doors
Open/Close state

AI state
Current position / rotation
Current goal
World state

Networked devices
Existing connections
Inventory

Mission Objects
Triggered state (Make sure triggers don’t get triggered more than once if they’re set up not to)

Hackable devices
Give callbacks to Lua to store and load custom state

DataPoints
Connection values (Who created the point)
Position
Contents
Encrypted status
(A lot more state!)

These are only the things we have to save at the moment, in the future it’s likely we’ll have to save a lot more.

Harry
has also been extending the way users interact with MissionObjects in
Lua - modders can now play with the following properties:




We’ve already got a few fun interactions we’re working on with the slerp/lerp functions and had a few issues!

We’ll have some great footage to share in the future, but for the moment we’re keeping some things under wraps.  :)

Level Design

With the large strides being made with the level kit architecture, and the modding tools and functionality within the Lua API, we have be able to start using the tool more frequently ourselves to make first passes on new levels and content.  You can probably guess from some of the previous posts we have made about the art Rob is producing, but one of the levels we are working on is a working harbour.  It’s very early stages at the moment but you can check out a sneak peek below:


Even MORE great news:

Have you heard?!  Harry will be speaking at Develop in July!  Check out his talk in the coding track




Two of our team members have also been accepted as part of the 2017 Bafta Crew Games!  Harry and Rich are looking forward to meeting fellow crew members at the masterclasses and events over the next year. 

And finally - Off Grid is now on Instagram!  Follow us if you haven’t already! 

No comments: