binary nightmare #3

Binary Nightmare #3

This month we invite Jim McKerchar to cover some details on how we’re bringing our web content to you, he’ll be detailing some of the challenges that he needed to conquer in order to make our process viable.

I’ll be covering some information about what I am working on at the moment, especially tools that we need to make our game.

Over to Jim...

Bringing Content To The Web

So let’s get back to Mimis for a second. On the face of it, hosting Unity3D WebGL content shouldn’t be too much of a problem. The documentation is good and there are some great examples of how to get up and running. The problem I found is that the documentation assumes Apache is being used as a server. Being a (borderline) hipster, PHP/Apache obviously isn’t “cool” enough so I naturally lean towards more hipsteresque languages when I develop. My preference being Ruby/Postgres (specifically Sinatra/Padrino) running on Heroku. This is where things get tricky…

For starters, we don’t use Apache (we use special cool servers written in Ruby and shiz).

So the .htaccess rewrite rules provided with the Unity WebGL docs can only be used as a guide. Also, Heroku’s architecture doesn’t use a persistent file system (each time a project is deployed to Heroku, the filesystem is recreated, any files that that are uploaded would be overwritten with each deploy) so any uploads have to be stored externally, using one of the many great cloud storage services available. Whilst these points aren’t deal breakers - they did require a bit of thought.

The solution wasn’t actually as complicated as first assumed (rewrites and proxy hell) but in finding this “simple” solution I had to work my way back from the documented solution, starting by looking into which of the servers available would provide the equivalent rewrites to those in the generated Apache .htaccess file; Passenger/Nginx fulfills this requirement. Using a “static” Unity Project stored in /public it was simple enough to replicate these rewrites. However, due to storing the project/asset/loader files in external cloud storage this solution wasn’t going to work without a bit of extra work. For starters, Unity provides two builds of a project (Release and Compressed). Using the provided Apache configuration, both sets of files are uploaded to the server and Apache handles rewriting URLs for requests made to the Release versions so that the compressed versions are served to the browser. Storing all of this in the cloud is certainly possible but will inevitably lead to larger usage costs. Luckily it turns out that I can upload only the compressed build and remap requested urls to their respective cloud locations so Padrino can serve the gzip compressed version of each file directly. Hey, presto I got Unity3D WebGL working… and I didn’t even have to do any complicated Nginx shenanigans (yay’)!!

Except there’s more…

  • UnityConfig.js was the same with each build so we made the decision to remove it from the uploader functionality and serve it directly from /public. However, because Unity needs all files for the project to be in the same folder (accessed via relative URLs) I had to make use of Padrino’s router to catch any URLs which relate to the unity project being requested, and serve the file using send_file.
  • The TOTAL_MEMORY  value that is used in the initialization Javascript (found in the index.html file which is generated when the project is built) IS REALLY IMPORTANT!!!!!  Because the generated index.html file isn’t used (a Padrino controller/view is used), I decided to use HAML (my templating library of choice) template into which any project specific values (TOTAL_MEMORY, URLs etc) can be inserted.
  • Because only use the gzipped files are being uploaded, I needed to unzip them and serve the original file content to the browser. Again relatively easy using Padrino’s router to correctly find the file, and then serve the contents as a string of javascript with it’s content type set to “application/javascript” or as data (content type set to “application/octet-stream”) in the case of the .mem and .data files).

I hope some of this may be useful to you if you are currently trying to figure out how to get Unity 3D WebGL working with a non-standard server setup (see “not Apache”). If you’ve already been through this process and have any advice you’d like to share, please feel free to leave a comment, it’d be nice to hear from you :)

And back to Chris...

Spanners, Hammers, and Sporks

I’ve been lucky that I have been exposed to a bunch of game engines over the years, across the industry, ranging from internal technologies, through to commercial engines.

If there is one thing I have learnt it's that if a tool isn’t adequate for the job, you’ll waste more time fighting it, than you’ll spend fixing it, extending it, or writing a tool that does the desired job.

Unity is no exception really, and as with any engine we’ve a requirement for our own tools so that we can edit and present data as it is needed to both, the engine, and in turn the game. So I’ve been working on a few tools for some time now, so I thought that I would talk about them a little.

So what are the tools and extensions that I’ve been working on? Well the first thing worthy of mention is that Unity, sadly, doesn’t come with a universal solution for the display of wireframe meshes at runtime. I provided a quick solution for the latest version of Mimis (which will be seeing an update to version 1.1 soon), and for our general use here at Wickerman Games, but as is often the case, it won’t be too long before we hit issues where this won’t scale, as our content increases in size and complexity.

So solving this problem is pretty straight forwards, I have a solution, and I’ve already begun building a finalized solution. We feel that there is a gap in the market for our tool (Weave), so we’ll be putting this up on Unity’s Asset Store for a very reasonable price.

The next tool on the list has been in development for a while, and it’s due to the fact that Unity has a shortcoming in regards to curves. The animation system “MecAnim” available in Unity is excellent - but it’s a little heavyweight for some of our needs! Particularly if we just want to manipulate some general float values, whilst there is a stock curve editor that you can integrate into the inspector panel, it is - well it’s lacking nuance, and there are definitely some issues there - no multiple curve editing, the scaling is all kinds of broken, and the presets don’t really work; especially if you want values between certain ranges. It’s likely adequate for most people's needs, but we have some very specific requirements, and fast curve editing, and duplication is something that we need in order to progress with development in a timely manner.

You can think of it as a lightweight animation system specifically for floats, and colours, that can be quickly set up based off of particle effects, audio, and exposed variables. As with Weave, we’ll be making Sinuosity available on the Asset Store for a very reasonable price.

And the last tool on the list is more complicated, and definitely a piece of technology that we have to have for our game, as we’re making RPG’s we’re developing a custom dialogue editing, and relationship graphing tool. I will be covering the design requirements and details over the coming months, but it’s a beast - and in some respects - it’s one of our core technologies, we may package it up for sale, but we’re also considering giving it away as part of a modding toolset.

List of tools in development:

  • Weave - Wireframe Solution.
  • Sinuosity - Unity Curve Editor.
  • Skald - The Storyteller.

I’ll be uncovering the details of these tools and more in future posts. Thanks for reading!


Chris & Jim