Thursday 19th: Day 1

I made more progress on day one than was entirely polite. I had prodded at Unity a few times before this, squinting at its impenetrable tangle of components and objects and connections, but never made sense of it.

So I started by following a very straightforward beginner’s project tutorial; a set of seven videos, which made everything just…  click. After that, I finally knew what questions I needed to ask of the search engines — or I had enough grasp of the basics to start hacking. (Clean Code, eat yer heart out!)

I imported the All-Purpose Assault Mech from Project Y4. My goal was to create a miniature arena where you could control the movement of the mech with the mouse, hack ‘n’ slash style. Just a feasibility study, shaking Unity to see what might fall out.

Despite wanting to focus on ultimate basics, the tutorial dealt with some physics guff that ended up revealing an early prototype of the attack system — a few choice collision meshes attached to the AP-AM’s blade hands, which become deadly between frames 5 and 10 of the attack animation, started mashing through destructible cubes.

Friday 20th: Day 2

I was going to follow the second big project tutorial on Day 2, the Third Person Stealth Level, but the demo package turned out to be totally gubbed so I returned to my shonky prototype. I cobbled together some specific character controller scripts from docs.unity3d.com, wiki.unity3d.com and answers.unity3d.com, and the AP-AM began to respond smoothly to my commands. (It’s going to be a mouse control system like Nox but not like Torchlight.) That’s one of the major draws for Unity — it’s pretty mature and widely used, so it’s guaranteed that somebody has already at least attempted to do what you want to do.

I then discovered that the AP-AM’s wonky animations were my fault all along. Well, not quite all my fault — that unstoppable animation bounce Milkshape always forces upon you is rendered into the FBX export, and it turned out that I was actually missing a whole truckload of keyframes for the artillery cannon barrels. This meant that, in the intervening hundred-odd frames, they built up a mega bounce that was making them shoot off into the sky during the walk sequence. Bah. (Not an issue for the original WC3 version because the MDX exporter can be told to ignore the bounce.)

The up-side is that, with a few more duplicate keyframes scattered around, we have flawless export. Considering that was one of the early kickers that made me doubt Unity, with a perfect art pipeline there are no longer any blockers.

Saturday 21st: Day 3

Finally getting my head around the heirarchical structure of Unity and how scripts can interact with each other, I made crates take damage and replace themselves with broken bits on death. It doesn’t sound like much, but it’s beautiful because all I have to do is fart in the general direction of my low-poly meshes and they just work. You don’t even need five different fragment models — just put them in seperate groups in the one model and it’ll deal with them as individual bits.

The one thing that kind of annoys me is that, despite the heirarchical nature of the game world, it is basically impossible to iterate over all of an object’s immediate children. There are things like GetComponentsInChildren, but no actual list of all child objects. Luckily when I wanted to make all the crate fragments fade out it was a matter of cycling through all the MeshRenderers, but it seems like it’d be nice to get the actual gameObjects rather than having to ask for all the specific bits of things all the time.

Ach. Either way, it’s streets ahead of Warcraft III so I’m still floating around in heaven. The heavy integration of physics in Unity is absolutely brilliant, because it means all my shonky death animations can go straight down the pan in favour of the explosive fragmentations I always wanted.

Sunday 22nd: Day 4

The thing that’s so empowering about all this is that it’s not just any old crates that are disintegrating — they’re my crates.

The control mechanism was working beautifully by this point, aside from a few quirks where the mech seems to be able to run onto the tops of the crates (they aren’t sloped so I don’t quite understand), which sometimes makes it fire off into the air. Tthe AP-AM always faces the cursor, right-click walks it forwards (hold the cursor close to walk, far away to run), left-click attacks with one arm and space attacks with both arms. That’s not bad for a three-day-old prototype.

Crates are one thing, but I needed something more. Something that could fight back.

I decided to start with the simplest machine possible in the RDZ Industries archive, the Beta with ram-blades. Basically a pair of legs with a piston attached to it, this thing only needed to walk around and it could steal the physics-based attack system from the AP-AM. It also only needed Stand, Walk and Attack animations, rather than the 20-odd sequences of the AP-AM, so no juggling variations either.

It just heads directly in the direction of the AP-AM when alerted, and it can be easily blocked by obstacles, but it’s just a proof of concept — Unity 4’s free version does include its NavMesh pathfinding system, so enemies will get clever(ish) eventually.

Monday 23rd: Day 5

This little test-bed is going to be a prequel to Project Y4. The AP-AM in its prototypical stages only has the sword arms, so I don’t need to worry about projectiles and explosives just yet. So with pretty much all of that in place, I took Day 5 to start shuffling around bits of user interface in order to create a health meter.

Writing interfaces in Unity seems a bit wonky. The entire interface is drawn from scratch every frame, which, while giving incredible flexibility, means you’ve got nothing to hang on to. The GUI.Button drawing function returns true if the button that… doesn’t exist yet… is pressed…

… Come back WinForms, all is forgiven!

With the aim of turning this prototype into some kind of self-contained 10-minute level, I also started to fiddle with terrain. The AP-AM was developed at Facility ZX48, which is supposedly somewhere in Scandinavia, so out came the snow tile and the terrain editor. A basic challenge not unlike the tutorial from Project Y4 itself, this will walk through all the mechanics so that I can verify they’re working as much as show you how to operate the game.

Tuesday 24th: Day 6

I guess Unity is perfect because it does straddle the gulf between Warcraft mapping and real world. Unlike the seperation of code and level you might expect, everything is built in a scene and prefabs (your actual game elements) have to be generated from there. You can’t build or edit the complex structures required in the project library; you have to drag them into a scene, fiddle with them, and drag them out again.

It works for now because I’m used to working on Warcraft III maps where the entire universe is in one world space anyway. But in the long term, it seems potentially counter-productive, as you start to roll out to more and more levels — more discrete spaces where the framework elements that support the game have to be copied over. I guess we’ll find out soon enough; this is me assuming that it’s even possible to jump between scenes in Unity.

Obviously in trying to turn a loose agglomeration of objects into a game requires some global state, so Tuesday turned its head to that ugly beast. Do I really have to check IsPaused in every single script I’ll ever write? It seems that way — remember, we don’t have direct access to the game loop, we can only hang our components off various bits of it.

Nothing insurmountable here, but it’s best to think about the bigger picture before it’s too late. I’ll be swimming around in this crud for the next few years, so I’d like to get it in roughly the right shape first.

Now I need to think of a name for the project, and a name for my game development studio…

The Verdict

This is what I was made for, isn’t it? This is why I exist?
All right, let’s do this.

JC Denton, Deus Ex