Saturday, 28 January 2017

Sprint Update - 27.01.17 - Voron-Oi-Oi-Oi

Hello folks!  We hope you have had a good start to 2017 and are fully recovered from the post holiday slump! It has been a pretty busy start to the year for us. We have built a whole new system for mission selection, added new characters and missions, and all the while been busing doing release planning and following up on biz dev.

We rigged up a new character and have been working up some new content.
There is a fantastic python script available to take the standard Rigify add-on in blender. It gives you the ability to to switch between the tools needed for animating in Blender and alternatively stripping the export down to just what is needed for importing into Mecanim for setting up with Unity’s humanoid system. We won’t say any more but if you use Rigify and Unity this will make your life sooo much easier!

You can grab the script from here:


The LevelKit has had a bunch more time put into in this sprint and is becoming more and more user-friendly.
The LevelKit tools are more aware about which level is currently being worked on which provide lots of user friendly interactions.
Some examples of new features/fixes are:
  • Creating new levels from a template

  • Building asset bundles no longer requires pointing to the correct folder each time

  • The game now support’s (in the editor) the ability to scan the LevelKit folder for levels, this means that updates to levels in LevelKit are now immediately testable

New levels

We’ve been working on two new levels recently, the first is the workplace of the protagonist and the second is a shipping yard / harbour.
Both contain some really interesting hacking interactions that we’re looking forward to showing off.
Setting up these levels has required adding some new props into the LevelKit that you’ll be able to play around with including:
  • Mesh fencing

  • Flood lights

  • Security barriers

  • A water tower

  • Rubbish Bins!

AI Activity Action

We’ve started work on a new type of AI behavior for NPCs, called the activity action, it allows the user to set up a series of actions that an NPC can do in a given scene.
For example we’re working on a secretary NPC that has actions for working at their desk, using the phone, organising files and checking the fax machine.

These actions can be setup in the level editor and then marked up in the levels Lua script.
We’re planning on providing lots of animations for characters to use at activity points, so hopefully modders should be able to create activities that match the character they want to create.

Mission progression

This one’s bit of an obvious feature for a game, but because of the way how we want to support modding and user-made content, and having them fully integrate with the content we are making, it still took a bit of thinking to figure out how to actually build a progression from mission to the next one, and how to set that up on the technical side with our mission definition files and everything else.

Drawing some inspiration from our Goal-Oriented Action Planning - based AI setup, we ended with the idea of each mission having a list of preconditions that need to be fulfilled for that level to become playable, and a list of effects that completing the mission will have (which can then fill the preconditions for the next mission to unlock). We then start by loading all available mission definition files from the disc and compare their preconditions with the game progress state from your game save file to figure out which missions are available to play a the moment.

This should give us a flexible enough way to determine both linear progressions from one mission to next, and also as complicated branching mission progressions anyone might want to create. Even better, it allows any user-made content to easily define when the custom missions happen in relation to our main story line.

For consistency’s sake, we also decided to convert our mission definition files from JSON to Lua syntax. And at the same time added support for all kinds of extra information, including when and where in the game world each mission should take place.

Designing a City Designer

Talking about game worlds, that’s actually something we’ve been missing this far, apart from the individual game levels of course. We’ve always had a plan to create a city for the game to happen in, and with the mission system sorted out we felt now is the right time to deal with this as well. The only complication is of course that our mission system and modding support pretty much means we don’t really know how many cities we actually need to fit all the missions in…

That kind of threw out the option of just building a city beforehand, since we didn’t really feel like just hoping that nobody tries to add more missions than we can fit in the existing city. Which means we needed a way for the city to grow dynamically based on the missions added to the game. Instead of creating a city, we needed something that can create new cities for us as needed!

We came up with a fairly simple plan; we’ll create a point for each mission/city district we need, then some points for ocean (if there’s harbour district, we need there to be ocean and coastline as well…), and finally some extra points to fill the map around our city with some countryside. Then we’ll just divide the map into regions based on those points, and turn it into a 3D object for the player to look at.

Well, some complications there.  First, we needed a nice way to create the map regions based on those points. To do this we decided to create Voronoi diagram from the points. It defines areas closest to each point, and just happens to work really well for the kind of map tiles we wanted to have. Definitely worth looking at for all kinds of random generation, and especially useful for all types of maps. They are actually something we’ve planned to use to visualize Mesh network coverage in our city as well.

The second problem was making sure all the points we use for map creation are not just randomly based, but instead fairly evenly spread across the map area so we can get relatively same sized city districts, but still with enough randomness that they don’t just end being squares on an even grid. Turns out the Voronoi diagrams are useful here as well, namely using something called Lloyd’s algorithm. Which is quite simple in the end, you start with a set of random points and create Voronoi diagram from them. Then you figure out the center points of each Voronoi cell, and use them to create another Voronoi map. And repeat the same process again and again until the result looks like what you’d want to get. Each iteration moves the points slightly apart from each other, over time spreading them evenly across the area.

After creating the map cells, we just define all cells below certain line as ocean, and above it as land. Then we pick a tile in the center of the map, on the sea shore, and assign the first mission to it. After that we lop through the rest of the missions, one by one, and try to find a place for it next to existing city districts based on few rules. All the districts/missions should be on land, and as you’d expect, harbour district needs to be next to ocean. For every mission taking place in other parts of the city we try to find a map tile with the same district type, so that we end with larger districts in our city instead of just scattering them all around the map randomly.

Turning the math into a map

With all the required map, district & mission data created, we still need to turn everything into something that’s visible to the player. Time to create some polygons!
The basic concept of displaying 3D objects is that you have a list of points in 3D space, and then another list that tells the order in which you want to use those points to create triangles, which your computer’s graphics card can then display on the screen.

The Voronoi diagram code we use gives us the corner points for each map tile, and we could easily add another set of points slightly above those, plus one at the center of the map tile. After some pen & paper sketching to figure out the correct order to list all those triangles (each triangle needs to be listed in clockwise order since that tells which side of the triangle is the front, and which one is the back), we finally had a map on the screen!

A city wouldn’t really be much without some buildings, but the Voronoi code came in handy here as well. We just use the same method to create a bunch of random points inside each city tile, and then add buildings at those positions. In the long run we’ll create different sets of buildings for each city district, but for now some random cubes worked pretty well…

That’s the city part sorted out, the only remaining part was making it work as useful part of our user interface, displaying the available missions and allowing the player to select them from the map instead of the missions list we’ve used thus far. This ended being fair bit simpler than we expected, Unity includes a Physics Raycaster component you can add to your camera to allow the user interface & event system to interact with 3D objects. That would have already worked for mouse & keyboard controls, but we needed a nice way to navigate between map tiles with a gamepad as well. This could have ended being pretty complicated, but we realised that with some creative use of the Selectable class Unity uses for it’s own UI buttons, we could actually make our map tiles work with the automatic navigation Unity’s own Button objects have! All of the code for Unity’s UI components is available in BitBucket, definitely worth checking out when doing any custom user interfaces with Unity!

In the end we also had to do some maths to make sure our map tile & building heights scale correctly based on how big the map tiles are (as that depends on how many missions there are), and to make sure camera positioning and movement are scaled as well. And then of course a decent amount of UI redesign to go with the map and mission information. And now we actually have a city in the game!

Other stuff

Switch to Unity’s new Cinematic Effects
We’ve had some issues with one of the camera effects included in Unity and OpenGL. And since that’s an effect we absolutely need to use for our HDR lighting/rendering to work correctly, it’s been a serious obstacle for the Mac & Linux versions of the game. Luckily Unity is working on a new postprocessing effects stack, which is available to download already. While it’s not fully complete yet, it seemed like it would be worth a try. And it definitely was, even though some of the features might still change the stability and performance are great, as is the workflow for setting up postprocessing configurations and even switching them on basis.

Custom emissive shaders and casting light around them
We are using our own shaders for pretty much everything in the game, for sake of supporting vertex colours and to save the data needed for our data view effect. If you are using Unity’s Standard shader, there’s a dropdown box with the option to enable emissive materials to cast light to other objects when baking your lightmaps. We definitely wanted that to happen, but it turns out enabling it for custom shaders (even ones using Unity’s Standard lighting model) isn’t quite that easy. The option isn’t available as a compiler keyword or anything simple like that. However, after a good bit of reading through the source code for Unity’s included shaders, we found a way to display that option by using a custom editor for your materials. Bit more complicated than what we’d expected, but at least it works now!

Meeting and Greeting 

Essex Game Dev Meet Up
With thanks to James Batchelor from, we had the opportunity to meet up with other indies and games industry folk in Essex last week.  There were a few familiar faces from our usual co-working days in east London, but we were blown away at the numbers that turned up.  When you’re working outside of a big city it is easy to feel a bit off on your own - it was great to meet others in a similar boat and expand our local network.   We look forward to the next one, James!
Indie Bootcamp
Creative England and Microsoft asked us in for a PR, finance and publishing workshop alongside our other Microsoft Greenshoots cohorts this week.  If you haven’t been in, Microsoft’s Paddington offices are swiiiiiiiish.  Oh how we wish we had one of those giant 100 inch touch screen monitors at our disposal!  Drooling aside, we appreciated the sessions organised for us:

• Stefano Petrullo of Renaissance PR helpfully reviewed timelines and promotional milestones to work to in the run up to our alpha release, and hammered through the importance of consistent messaging.  We hear ya, Stefano!

• Harvey Elliot of Playstack spoke on access to finance, covering Playstack’s own publishing and investment fund, as well as the many other options available to devs like us.  He was a fountain of useful information - many thanks, Harvey!

• Colin Macdonald, Game Commissioner for Channel 4, was our final speaker, who gave his top tips for pitching to publishers.  He reinforced the importance of a well oiled elevator pitch - a truly useful exercise.  Safe to say we’ll be greasing our squeaky bits.

The other great part of the day was spending a bit of time with other devs, sharing challenges, and seeing their games in progress!  Check em out:

Ground Shatter Games
Needs More Robots
Burning Arrow - The Other 99 is currently in early access on Steam!
Fallen Tree Games

And that’s all for now, folks!

No comments: