I recently attended an excellent panel on game narrative by BAFTA’s games arm, featuring such games writing luminaries as Georg Backer, William Pugh, Jennifer Schneidereit and Rhianna Pratchett. It was all-round an extremely worthwhile discussion, and I recommend anyone who’s interested in the subject of writing for games to check it out on YouTube here.

The main thing that I personally took away from the session was that if you want to write for games, then you need to be able to understand how games work, and be able to bring something to the table other than your writing skills.

Now I like to think I know how games work, which is why I write about them so damn much. Years of playing, designing and theorising about games has given me what I hope is a reasonable understanding of what makes a good game different from a bad one. But I don’t know how they actually work on a mechanical level – I can talk a good game, you might say, but I certainly can’t build one from scratch.

Now there are a ton of tools out there that enable people inexperienced with coding to design and build games – but I’ve decided, with my latest novel finally released (oh hey, look, you can buy it here) and more time of my hands to focus on game-related stuff, that I’m going to teach myself to use Unity.

Why Unity? Well, it’s free to use initially, and it also enables multi-platform development across a wide range of devices – many of my frustrations with game development tools I’ve used in the past stemmed from their being locked to a single platform. It’s also the engine behind many of my favourite games of late, from Monument Valley to Kentucky Route Zero, and there’s nothing like emulating your heroes to underpin an adventure into design.

Building a space shooter from a tutorial. I am unreasonably proud of this.

Building a space shooter from a tutorial. I am unreasonably proud of this.

It’s also worth pointing out that when I say I’m ‘teaching myself Unity’, what I’m actually doing is following a range of fantastic tutorials developed by people from the vibrant Unity community. This community is an absolute credit to the platform, and it’s the main thing that makes approaching development as someone with zero programming experience seem like less of an insurmountable obstacle.

So this is the first of what I intend to be a series documenting my experience of learning to develop in Unity from scratch – my Unity adventures.

A good place to start would seem to be outlining my previous experience with game design software; Unity is not my first foray in building games. No, I’ve been trying to rip off Final Fantasy since high school.

My first crack at designing games that didn’t exist in my head or across a series of sheets of A4 paper was pretty early on in high school, when I spent several years working with Enterbrain’s RPGMaker. RPGMaker still exists, and its current version is RPGMaker VX – I’ve no idea what the VX stands for – but when I first started using it the version I had was RPGMaker 95.

I moved up through RPGMakers 2000 and 2003, using cracked copies which were sadly the only way to use the software in English at the time. My goal as a thirteen-year-old designer was similar to the majority of others’ using the platform; to singlehandedly create an RPG that could outclass Final Fantasy VI.

Somewhat (un)surprisingly this enterprise never bore any fruit; it takes quite a lot of work for one kid to construct an entire 60-hour epic and I wasn’t up to the task. I remember there were people around at the time who came close, and I retrospectively doff my cap to them. The scene at the time may have consisted primarily of Final Fantasy obsessed teenagers, but I’ll be damned if there weren’t some pretty great game ideas that came out of it.

I moved on to experiment with both Clickteam’s The Games Factory and a very early version of Gamemaker, which was in pre-version-1.0 public beta at the time. I stuck with TGF, mainly because it was easier to use but also because it was a much more stable piece of software at the time.

Shortly after I started playing around with TGF, Clickteam launched their follow-up software, Multimedia Fusion, which was the first piece of games development software I actually purchased with real money (actually, thinking back, I think my parents bought it as a birthday present, but money still exchanged hands, so it counts).

It was using Multimedia Fusion that I finished and released the only game I ever actually finished and released, a side-scrolling space shooter called Zero Thunder, which, perhaps fortunately, has been lost to the annals of internet ether.

I upgraded to Multimedia Fusion 2 when that released – which, it seems, is still available today – and fiddled around with a variety of projects that never really came to anything. I got on board early with Scirra’s Construct in its free beta version, because it was largely identical to MMF2 but with, at the time, far more powerful graphics acceleration technology.

I can't even make the game run any more, but here's proof that it did exist in some form at least.

I can’t even make the game run any more, but here’s proof that it did exist in some form at least.

With Construct and a small group of friends I built a demo for a game we were calling Halcyon, a platform adventure game in a Prince of Persia vein, which featured in our university end of year show in 2010. Unfortunately the Construct software was not robust enough at the time to build out that demo into a full game – keeping the thing running for more than 5 minutes at the expo was a nightmare – and, with an MA to focus on and real-life stuff to consider, I reluctantly put my game designing on ice.

What you can take from all this I suppose is that I’m not exactly new to game development – I’m familiar with the concepts of design, as well as coding principles like variables, loops and colliders. So while this makes my introduction to Unity a bit less daunting than someone approaching game development completely fresh, one thing I’ve never learned to do is any actual coding, which Unity absolutely does require to get anything moving around on screen.

Some serious ball-on-plane action is going on in my first ever Unity scene.

Some serious ball-on-plane action is going on in my first ever Unity scene.

So far I’m a couple of C# tutorials into Unity’s beginners tutorial series, and it’s coming together – slowly. My previous experience at least means I understand what most of my code is doing, even if I’ve no real idea how to write any of it without copying chunks from Unity’s documentation just yet.

My first impressions of Unity are positive; it’s clearly a professional piece of software, leagues ahead of the hobbyist software I used to use – many of which have now evolved into semi-professional kits of their own. It’s expected, of course, what with Unity being behind what feels like a majority of indie and mobile hits at the moment, but it’s nice to have that level of power affirmed by using the software first hand.

So far I have made a ball roll around on a plane, and I have made a basic space shooter – both taken directly from step-by-step tutorial and so deserving of minimal credit on my part. Still, it’s a start, and I am impressed with how quick and easy it is to get assets moving around and interacting within Unity.

For now I have no solid designs for future projects – I intend to spend as much time as I can afford working through tutorials and searching YouTube for more, but I do have a few concepts I’d like to try out. How I’ll actually start building these things I’m not yet sure, but I’ll be updating this blog with my findings and developments – whether those prove to be successes or failures.

Share this post.