Learning to code

I’ve been involved with the game industry for over 16 years but I have a confession to make. I can’t draw and I can’t code. Sure I have mad skills as a marketer/project planner and (hopefully) as deep a level of understanding of game mechanics as any designer can boast. But when it comes to actually making something on my own, I’m hopeless.

Don’t get me wrong I’m far from technically illiterate and have had many a detailed discussion on the finer points of software architecture with lead developers; but always as a theoretical level. The trouble is I found out early on that I was never patient or observant enough to be a decent coder or artist (two skills I still believe the best proponents of each specialisation must embody). I just don’t know the syntax.

I’m an ideas man. I think therefore I am. But it comes to the point where that isn’t enough and earlier this year I decided enough was enough. Time to get making my own ideas.

It’s not going to be a surprise to learn that the acquisition of Applifier by Unity focused my attention on what I needed to learn. But I hope this piece will apply to you whatever platform you want to use.

First things first I had to decide what I wanted to make. I thought about this a lot (probably too much) and eventually realised that most of my ideas were way too complex. Then I saw Timberman from Digital Melody. A game so incredibly simple yet fun. I could make that I thought. I even thought I could add something to it by making it 3D. But that was as far as I got.

I decided to take a week off, downloaded Unity as well as a whole bunch of books on Kindle and sat staring at the screen. I had a decision to make. Do I learn a scripting language like C# or Java Script or do I use a visual scripting tool like uScript or Playmaker. This is quite a personal decision. I’ve dabbled with Basic, Python and a very light touch of Java script but always as a copy/paste coder. Whilst I might have an understanding of the existence of Functions, Variables and Classes understanding how to use them was a struggle.

After some pretty impressive progress using Playmaker I found I could make some basic cubes disappear and reappear. However, I couldn’t make them do this endlessly. Nothing to do with any limitations in Playmaker. The problem I was having was that I didn’t know enough of what the tool could do to be able to fix the things I wanted to do.

Now it’s at this point I could have given up. Sure I’d given it a try but I was determined to plough on. There were so many alternative ways to approach the problem. So many sources of great information out there from YouTube tutorials, sample projects etcetera. it was almost too much.

I decided to try one of the projects on the Learn section of Unity’s website. The Space Shooter project wasn’t going to help me with my Timberman variation directly, but it did show me get me to go straight to the code, in this case C#. Something which I found worked well for me; but it raised another problem: My accuracy as a typist was letting me down and I didn’t know enough to be able to work out where I was going wrong. I was suffering the Dunning-Kruger effect, I was too incompetent to know how incompetent I was.

Again this was a point where failure seemed inevitable. However, I decided to try another approach and hired a friend, Byron Atkinson-Jones from Xiotex to teach me in a day. We started from a blank sheet. With him taking me through from basic principles and by breaking each part of the game into individual steps.

We made each cube into logs from the Tree, we saw the effect of how they dropped and how physics made these bounce just enough to make the game play different from the inspiration. We slowly built a unique game from the pieces of lessons I had already learnt with new lessons learnt by having a skilled person present. But it was still my game. And it was fun.

That isn’t the end of the journey of course. I’ve worked through other tutorials and found that at each stage by starting with a clean sheet and persevering I have discovered layers of connections building up. The more variety of sources and projects the more this effect seems to grow. Each time I got stuck I moved on to the next project and before I knew it I had an answer for what might be going wrong in the previous one.

I was lucky enough to attend the Unite Training Day in Seattle last week as well and this again helped build on what I have learnt, exposing me to the new UI tools at the same time as being surrounded by hundreds of others in the same boat as you.

Of course it’s one thing making a tutorial and a different thing making your own thing, however, now I feel I have a greater understanding of what to look for when something goes wrong and how to identify functions which might help me do something my imagination wants to see happen in a game. It’s a tremendous feeling to be able to make something yourself but I have no illusions as this is just the start of the Journey.

My knowledge is just starting. However, what I think was important is the realisation that there is so much support out there now to suit all kinds of learning styles and it’s the combination of tools from books, video, tutorials, web repositories, the help of friends, etcetera. which make it so much easier to make real and sustained progress. I just have to keep at it.

There is no better time to make games, and there are so many tools to help you unlock your imagination. The benefits can be tremendous for anyone not least as it helped me as a designer work out if my idea was really fun or not.

But it’s still a worthwhile exercise even if it’s just a way to help you become familiar with logic or so you can better understand the jobs of coders or artists. As a result of my experience I decided to encourage my daughter to start working on one of the Unity tutorials – I can’t wait to see what she comes up with.