Project I

>

Ok, I caved. The allure of Unity was just too great, and I couldn’t help myself as the grand ideas came flooding into my head. I began a brand new project with relatively tame concept but the grander target of creating a complete, standalone application game. Welcome to the world Project I! I want to stay focussed for this one, so we might go more Dev-diary style for a while…

Blog Unity

There are a tonne of tools out there that are making it easier and easier to create rich, detailed virtual experiences. These tools now target not only game design, but also a wide variety of other tools that are utilising virtual environments for all sorts of different projects, from ergonomic assessments in manufacturing to virtual experiences in things like architecture and beyond.

There are many aspects to making a 3D environment feel complete, and a key one of these is world physics. The type and depth of the way that different objects react to each other is something that drives the tactility, or how your world ‘feels’. There’s something universally appealing about throwing a heavy cannonball at a wall of blocks and watching it collapse. And so this week I explored ways to do collision detection in a little game.

[video of ball knocking a wall down]

I’d done some basics of this in my solar system project previously, but spherical collisions are easy as they are basically just comparing the distance of 2 objects with their radius. Since collisions can get rather complicated I thought I’d just abstract this out to a library. There were a couple of contenders, namely cannon.js and ammo.js. I ended up going with ammo on the grounds that its documentation seemed to be a bit more complete, although it was far from ideal. I found a type library for it that was ported directly from bullet, the C# library that ammojs is copied from. While the types themselves are all there, there were no descriptions at all, and so it was a bit frustrating to try and work out what values like sx and kvst were actually referring to. Fortunately, the bullet source code has comments inline for most of these, so at least there is a lookup for it somewhere.

[video of something using ammojs]

However, I didn’t get very far with this approach. This really had nothing to do with the library, but to do with the typical tendency I have - like many developers - to follow the latest shiny thing dangled infant of me. This took the form of a short course that thrust itself at me titled “Unity for web developers”. I don’t think I could have authored a title that sparkled more if I tried.

This led me into previously uncharted territory, this time using C#. I’d had previous experience using C++ so I had some experience (see my excursion into GTAV modding), but they aren’t identical and there are a few extra things C# offers that I needed to learn. But besides that, the Unity engine makes things just so easy. Collision detection, for one, comes as standard, as do renderers that support lighting, dynamic shadows and reflections, and an all-round easy-to-use approach. The documentation is also so much more complete than the previously cobbled-together architectures that I was using. The main deal-maker was that Unity has WebGL as a build target, so I could develop in Unity and then port to the web and - in theory - just drop the finished app into a web page.

I often find online courses to be rather slow, so I cranked things up to 2x speed and set off. We started with a template project that had a bunch of things predefined, but these were all auxiliary things like textures, materials, etc. The one thing I didn’t have a grasp on by the end was the event handler, but a quick look into the editing UI and I was able to get a good grasp on how to use things. Pretty quickly the app had taken shape and I was already going off-piste with editing material properties and aspects of the game that were more in line with the creative ark I like to follow.

After just 4 hours I had a fully-functioning, fully-deployed version of the game running in my browser. Yep, in Just. Four. Hours. Admittedly the design of the game was simpler, but we’re taking a fully complete 3d environment with lighting and reflections, camera movement, post processing and a properly functioning game loop.

And so, I hooked up my build to the site here. What you’ll instantly notice is it is cripplingly slow to load. It’s also a bit buggy in that it tends to like loading many instances of itself onto the page at once, which is rather frustrating, and something I’ll need to try to fix in the future EDIT: Now fixed! Also, for readers not on a Chromium-based browser, you’ll probably just get a bunch of errors, since the way unity uses WebGL in it’s builds means that Firefox and Safari throw a tantrum. And let’s not talk about mobile…

So at this stage I’m a little unsure how to proceed. Unity projects also build to mobile and desktop apps, which all work much better (although I can’t show that on here). So I’m torn between building things that work locally and are easy to build, or things that I can put on the web, which is a frustrating conundrum indeed…