Friday 2 December 2016

Sprint Update - 02.12.16 - Workshop til you drop

Hello hello!
This sprint has been all about the behind-the-scenes:  stuff you would never know about while playing the game.  Just as well you are reading this blog then, eh!  We got a whole lot of release planning done and have our road map to alpha defined with greater granularity, at least for an agile project that is! ;P  We have done some early spring cleaning by upgrading our version control servers (in fact, entirely renewing them) and in project terms, we have mainly been working on our platform abstraction, Steam Workshop integration, and cleaning up some of our old props that were using materials inefficiently.

Now as an overview, that may all sound a little dull, but we promise there are some gems in here - especially if you are a fellow game developer running a similarly sized project.



Steam Powered!

You may have gotten the hint above, and in previous blogs…we have been selected for release on Steam and will be coming to an Early Access download near you sometime next year! 
This has obviously been a long-term plan for us for some time, but it’s not the done thing to shout about until it’s locked down. We have been having fun messing around with the SDK and Steams tools, and figured now is as good as any time to announce this!  So it’s official - you won’t only be able to buy Off Grid on the Windows store!  Hooray! :P

Platform Abstractions

When making a game that you are hoping to target different platforms with, you’re going to have certain systems and logic that are specific to certain SKUs (a SKU can be seen as a different variant of the game code, for example:
Steam and DRM Free are different SKUs).
This is where coding up an abstraction is not only useful, it is vital. It not only helps to separate logic between SKUs cleanly, but also massively reduces the maintenance cost of adding a new SKU down the road.  We’re planning on supporting three SKUs at launch: Steam (Win/Linux/macOS) - DRM Free (Win/Linux/macOS) - Windows Store (Win).

We have a number of features that need abstraction:  modding support, achievements, and cloud saving, as well as basic system level things like the game being minimised and Steam overlay.

Focus on Modding

Modding has been our biggest focus this sprint - and we’re working really hard on its implementation at present.

On Steam, users will be able to upload their mods via the game client or an external tool and subscribe to mods as they would with any other game-supporting workshop.

We’ll also support the idea of local mods - these are mods that exist in a local folder that the game checks at launch. This will allow users to play and enjoy mods from non Steam sources and test mods they’re making before uploading to Steam.

At the end of this sprint, we managed to successfully upload a custom mission for the game, subscribe to it via workshop, and then download and play it in the game client!
Here’s a (rough) temporary interface showing the list of missions and their sources:

As you can see above, we have the two first levels which are coming from the local streaming assets folder and the third level, which is coming from Steam.
Here’s what it looks like in Steam workshop!

Super exciting stuff! :D

Vertex Colouring

If you remember our post from May, you’ll know we’ve planned on converting to vertex colours for a long time - too long.  We’ve decided to finally get it done!

Using a handy blender script that makes the process much faster, we’ve managed to power through the first ~60 props. We’ve still got some more to go, but it’s starting to look like a much cleaner workflow for us. We’ll probably open source our blender script in the future, keep an eye on Harry’s twitter if you’re interested.


Asset Bundles

We use Unity’s AssetBundle system for our modding support. This sprint we spent some time investigating the different options available when building asset bundles.

Platform Compatibility

According to the Unity documentation, bundles should be cross compatible between standalone platforms (Win/Linux/macOS). We did, however, come across some fun issues when putting that to the test.

The main issue we found was that a lot of the materials were missing, which caused objects to render as magenta.  With a bit of prodding and searching, we managed to track down the cause of the issue.
Unity has a list of “Always Included Shaders.”  This means they are always provided with the currently built platform in a format specific for the required graphics api(s).

When Unity builds asset bundles and finds an asset depending on a shader, it will check against the always included list. If it finds the shader there, it will simply set up a reference to the shader. Then when it’s loaded, it will use the shader in whatever format it currently exists. If, however, it doesn’t find it in the always included list, it will compile the shader for the current build platform.
Now that’s been fixed, we no longer have any bright pink skies… shame, really!

Compression

Let’s chat a little bit about compression in Unity’s asset bundles and why it matters to us working on Off Grid.

Unity supports three levels of compression: Uncompressed, LZMA and LZ4
The main factors we’ve been investigating have been the build time of the bundle and their resulting size.

Here’s how long it takes to build all the bundles we’ve currently got in the project:

As you can see, it’s a fairly significant increase. There’s no reason that we can’t locally use uncompressed bundles for testing purposes though.
When it comes to file size, we’ve seen a really nice reduction on one of our levels:

Considering that these asset bundles will be part of the mods being downloaded via Steam workshop, it’s important that we don’t cause users to download any more data than needed.
We’re planning on using LZ4 for our mods as it’s a good balance of file size, build time and memory usage, however, we might investigate the idea of a debug build users can make whilst testing to avoid the longer build times. More info soon! :)
You can find more information on the Unity documentation site here.

Broken clouds and running version control in them

During our last sprint we ended with the exact situation you never want to see with your version control server… we ran out of space.  A quick emergency clean up of old history freed enough space to keep us going, but the server never was the same again. Most likely, some corruption of files happened and freeing space afterwards wasn’t enough to fix that.

Anyway, that’s a server we’ve had running from the very start of the project, so it was several Perforce versions behind, and wasn’t necessarily set up in the best possible way in the first place. In addition, Perforce has added some interesting features like their Streams system which seemed like they could be really helpful for us.

After few minutes spent wondering what kind of work we’d need to do to move the server to a bigger cloud server instance, update Perforce, fix any database corruption and whatever might have been going on with the old set-up, it became clear that a fresh start might be the better option.
So fresh start it was, and in addition to adding features, Perforce has actually improved the install process as well.  Last time we just got a binary executable and the most minimal instructions for how to test if it actually runs, but setting it up as a daemon on the Linux server was up to us to figure out. This time, they had a proper software repository for Ubuntu, and the packages actually set up the server daemon as well.  Overall a much better experience this time, you could almost think about calling this “user-friendly”!  :)

About a day’s work later, we had the new server up and running, and development streams set up for our main project, the level editor, and the sound project. And compared to the old server, things were actually running, not slowly crawling…


Of course things are never that smooth, there’s always some unexpected problems.  In this case, it was the way Perforce deals with line endings in text files between Windows and Unix/OS X systems. And how it decides if a file is a binary file or a text file in the first place. Long story short, be aware that binary FBX files can still sometimes be recognised as text files, and you need to specifically configure Perforce to treat them as binary data instead of text so it doesn’t try to do line ending conversion on them… (I guess we never had this issue before simply because this happened to be the first time anybody tried submitting a FBX file to our project from a Mac).


So, long story short, version control is important; don’t let your server run out of space; and our set-up of Ubuntu Linux server running Perforce in Amazon EC2 instance is still great option for version control for larger Unity projects, as long as you are comfortable with running a Linux server and reading through Perforce reference documents to set everything up!

Monthly bug raid

As always, we made our way through some bug fixing and dealing with other less-than-optimal systems in the game:
  • The game trailer was playing at double speed in some situations. Turns out if you trigger the Play() command on MovieTextures in Unity, every time you do it, the playback speed is doubled. It’s an interesting feature I’m sure someone would find some great use for, but for our purposes we decided to just make sure it can only be triggered if the video is not already playing.
  • Player getting tasered didn’t end/restart the level.  Quick fix for once!  This was just a question of us moving different mission & level loading scripts around previously, and never connecting the player tasered event back to anything.
  • Camera transition between follow camera and player control. Yeah. Actually the lack of transition. When the player started moving the camera, it would snap to the position it was in the last time it was controlled by the player, rather than starting the movement from its current position. This has been frustrating for anyone playing the game since the very first prototype.  It is fixed now, and we probably should have looked at this properly a long time ago, as it was fixed by a single line of fairly basic vector maths.  At least sometimes the complicated-looking problems actually end being quick and easy fixes!


There might be a city…

Let’s just say that we have plans for actual progression from one mission to the next, for a city, and for many other things.  And let’s then say that we might have done some design work on how these things might be built…
You’ll have to wait a bit, but we should be able to start actual work on them in the next sprint or two, and we’ll tell more details at that point, so exciting stuff to come!

Til the next time,
Pontus, Rich, and Harry.

No comments: