Sprint Update 04.9.2015 - Experiments and future content

Hello there, long time no talk!

We’ve been away on our summer holidays, Pontus headed back to Finland to catch up with family, and rich got married for the second time (to the same person). We’ve had some contract work to do to keep the wolves at bay, but fret not we have been continuing away on off grid development in the background! and so here is an overdue catch up on what we’ve been up to…
Rich took the opportunity to use some of the time for getting back in tune with a pencil and paper and wrote the first draft for the Off Grid script. As you may know we have had the premise and the major characters fleshed out for some time but the new script ties together all the current designs for future levels and features with a coherent narrative, and pretty much lays out the entire player journey for the main story missions. This has been really helpful already for working out what to prioritize in the next levels we are prototyping, and what the player journey for the game is in relation to the character’s development.

Screenwriting for games development is about the most fluid process you’ll come across. It seems to vary from developer to developer, and game to game. We have always opted for the approach of developing the core game first and letting the mechanics and player experience drive how the story evolves, in a sot of feedback loop, so essentially a lot of toing and froing between what is working gameplay wise and how that influences what makes sense from a narrative perspective. This latest development helps us turn a corner in terms of content planning. In our experience the best way to tutorialise a game like Off Grid is to have any instructions the player has to digest be embedded in the character interactions and therefore, ultimately, the overall storyline and motivations are key in this. Now that we have a rough character/player journey mapped out we can approach the tutorials in the initial levels with a bit more narrative confidence, and be happy that character interations are genuinely purposeful and lead somewhere. Next task is implementing some of this in the levels we have already prototyped and the playable intro. This leads on to one of the coming things we are pushing forward, we’ve been piecing together a lo-fi mo-cap pipeline to help up the animation fidelity and save us time. This is something we should have some nice results from in the coming months so we’ll have some fun stuff to show you, coming soon!

Procedural level prototypes

Our goal has always been to have some procedurally generated levels or a level editor included in the game, and over the summer we spent some time doing a bit of prototyping about level generation just to see what kind of technical & gameplay issues we’d run into.

Without further planning, we just picked the simplest possible way of doing it, using fixed size room tiles we designed beforehand, as being able to tweak and design the individual rooms would give us more control over them and allow us to design more interesting content than what a fully procedural approach would create. Here’s how it goes:

• We start by selecting a random room tagged as a start room.


• Next we go through any entry points (doorways and such) in that room, create a list of rooms with matching entry points and pick a random one & spawn it in the level.


• After that we pick each of those rooms, and go through their entry points and repeat the same steps.


• Once the desired room count has been reached, we’ll continue backwards through the list of rooms that still have doorways leading nowhere, and pick matching rooms for them, only this time instead of picking a random suitable room we’ll instead select the one with smallest number of entry points.

Of course any room created needs to check for any surrounding tiles to make sure the entry points match in every direction. Each room can have any number of entry points, with 9 possible locations per wall (left, center, right, and three different heights). Of course, at least one doorway is required.

We also added spawn locations in each room for randomly instantiating in different props, NPCs, and other stuff for even more variation. Each room deals with it’s own spawns as soon as the room is created.

Ultimately, the same setup can handle any level size and any amount of rooms, and works for both interior and exterior levels. For example rather than defining entry points, we could have a list of blockages instead. Or anything else that needs to match with surrounding tiles, like ventilation shafts for some traditional stealth gameplay…

Problems

As you’d expect things aren’t quite that simple in the end. We did run into a bunch of issues to be solved, both game design-related and Unity engine limitations.

First, it turned out that Unity 5’s realtime global illumination (GI) isn’t quite realtime. Procedurally generated or run-time-instantiated meshes can’t be lit using GI. So the only option would be to build a separate scene with all the possible configurations of tiles, bake their lightmaps, and then when building the level at run-time selecting tiles with matching lightmaps on them. However this would quickly turn into insane amount of work, and also loads and loads of duplicated assets in the game.

LightProbes won’t help us either, while they can deal with meshes generated and instantiated at run-time, they can only store light data that exists around them when they are baked. So a good solution for small prop meshes and characters, but a no-go if the level itself is procedurally generated.

Second, there is a similar issue with Unity’s NavMesh which needs baking as well. At least that one could be sorted by having offmesh links at each entry point and then baking a separate NavMesh for each room.

On the game design side, as always with procedurally generated content, making sure everything both makes sense (no corridors leading nowhere etc) and is as interesting to the player as possible, can be difficult.

We’ll also need to come up with a nice way to create suitable patrol routes for our guards, making sure they give the player interesting challenges without making it too easy or too difficult to find routes past the guards. And same goes for level objectives as well.
That’s pretty much everything for this time, apart from a little further planning and design work on how the data and networks are handled in game, and some time spent on figuring out the navigation and AI for adding some drones to outdoor spaces in the game..

Hopefully we’ll squeeze another sprint post in before the end of the month, but if not, we are heading to EGX again in a few weeks time and are busy prototyping a new level to show off. If you are planning on being there come and seek us out, it would be great to show you some of the new things we are throwing in!