Total immersion in a tech puzzle that’s over your head.
That’s part of the Packt induction policy. Even those in an editorial role are expected to do battle with some code to get a feel for why we make the books we make.
When I joined the commissioning team I’d heard rumours that the current task involved frontend web development. Now, English major I may be, but I’ve been building sites since the first time my rural convent school took away our paper keyboards and let us loose on the real thing. (True story.) I apprenticed in frames and div.gifs thankfully lost in the Geocities extinction event. CSS or Java? Maybe Sass or JQuery? I was smug. I was on this.
Assignment: “This is Unity. Build a game. You have four days.”
Hang on. What?
The last time I wrote a computer game it was a text adventure in TADS. Turns out amateur game dev technology has moved on somewhat since then.
There’s nothing like an open brief in a technology you’ve never even installed before to make you feel cool and in control in a new job. But that was the point, of course. Four days to read, Google, innovate, or pray one’s way out of what business types like to call a “pain point”.
So this is a quick précis of my 32-hour journey from mortifying ignorance to relative success. No, I didn’t become the next Flappy Bird millionaire. But I wrote a game, I learned some C#, and I gained a new appreciation for how valuable the guidance of a good author can be as part of the vast toolkit we now have at our fingertips when learning new software.
My completed game had a complicated narrative.
Day one: deciding what kind of game to make
“Make a game” is a really mean instruction. (Yes, boss. I’m standing by that.) “Make an FPS.” “Make a pong clone.” “Make a game where you’re a Tetris block trapped in a Beckett play.” All of these are problems to be solved. But “I want to make a game” is about as clear a motivation as “I want to be rich”. There are a lot of missing steps there. And it can lead to delusions of scale. Four whole days? I’ll write an MMO! I wasted a morning on daydreaming before panicking at lunch and deciding on a side-scroller, on the reasonable logic that those have a beginning, a middle, and an end.
I knew from the start that I didn’t just want to copy and paste, but I also knew that I couldn’t afford to be too precious about my plans before learning the tool. The sheer volume of information on Unity out there is overwhelming. Eventually I started with a book on 2D Games in Unity. By the end of the day, I had a basic game. It wasn’t my game, but I’d learned enough along the way to start thinking about what I could do with Unity.
Day two: learning the code
By mid-morning of day two I’d hit a block. I don’t know C#. I’ve never programmed in C. But if I wanted to do this properly I was going to have to write my own code. Terry Norton wrote us a book on learning C# with unity. For me, a day out working with one clear voice explaining the core concepts before I experimented on my own was exactly what I needed.
Day two was given over to learning how to build a state machine from Norton’s book. State machines give one strong and flexible control over the narrative of a game. If nothing else ever comes from this whole exercise that is a genuinely cool thing to be able to do in Unity. Eight hours later I had a much better feel for what the engine could do and how the language worked.
Day three: everything is terrible
Day three is the Wednesday of which I do not speak. Where did the walls go? Everything is pink. Why don’t you go left when I tell you to go left? And let’s not even get started on my abortive attempts to simultaneously learn to model game objects in Maya.
For one hour it looked like all I had to show for the week’s work was a single grey sphere that would roll off the back of a platform and then fall through infinite virtual space until my countdown timer triggered a change of state and it all began again.
This was an even worse game than the Beckett-Tetris idea.
Day four: bringing it together
Even though day three was a nightmare, there was a structure to the horror. Because I’d spent Monday learning the interface and Tuesday building a state machine, I had some idea of where the problems lay and what the solutions might look like, even if I couldn’t solve them alone. That’s where the brilliance of tech online communities comes in, and the Unity community is pretty special.
To my astonishment, step-by-step, I fixed each element with the help of my books, the documentation, and Unity Answers. I ended up with a game that worked.
I cheated, obviously. On Friday I came in early and stole a couple of extra hours to swap my polygons for some sketched sprites and add some splash pages. Now my game worked and it was pretty. Check it out:
Green orbs increase speed, red slow you down, the waterfall douses the flame. Complex.
It works. It’s playable. If I have the time there’s room to extend it to more levels. I even incidentally learned some extra skills (like animating the sprites properly) and particle streams for extra flair.
Bursting with pride I showed it to our Category Manager for Game Dev.
He showed me Unicorn Dash. That game is better than my game.
Well, you can’t win ’em all.
