Interestingly, nobody has actually asked me the above question yet, but lots have asked me how to do it. However, the two are impossible to discuss separately.
In a nutshell, making a game is the first thing that I have ever come across that genuinely makes me think outside the box and use a wide knowledge-base. This is coming from a man who has studied medicine, studied politics, been an entrepreneur, and worked in the tech and management consultancy industry. The reason is simple: in any job, you only need to engage your brain when you need a workaround. But everything in game development is a workaround. Games don’t replicate true light physics – they fake it, music doesn’t play in our ears when we get into a fight to make it more dramatic, we don’t lose health in real life – we lose limbs, and lets not even get started on projectile physics. In fact, games are workarounds because they are trying to show a world that doesn’t exist.
Let’s take an example. As discussed elsewhere, I decided to wrap some artsy nonsense into every part of this game I could fit it into. One way in which I tried to do that was in choosing the time of day and colour pallet used in levels, with a meaning to each. For the first level, I wanted a daytime scene, with greens and blues. Now, before we go any further, this required a cursory knowledge of colour psychology, colour theory, and visual metaphors as they are used in cinema (none of which I had an interest in before starting this game). In an early version of the level, I had a lovely blue hued granite as my go-to cliff/rock texture. It matched the colour scheme and looked great. Then I added some deciduous trees, which also looked great. Except, together, they didn’t look so great at all. I couldn’t figure out why. I swapped some things around and still the scene was wrong. Then it struck me. Granite rock, in a area where it can occasionally protrude, will not generally allow for the development of soil deep enough for the roots of big deciduous trees. Now I’m sure it does happen somewhere (I can only go by the places I have seen and have not visited the entire world), and I am sure most people think it is silly detail (as I would have if I read this), but yet I knew something was wrong when I saw it. Even if players would not realise the problem, they might, like me, “feel” the problem and they would come away with a sub-par experience. So now I had to consider not just all the colour stuff and metaphors, but also botany and geology, and I had to figure out that they were indeed the problem in the first place. I redesigned the level and it was much better. This is what I mean when I say a wide knowledge base. This said, it’s a challenge and interesting, and when I solve a problem I can take pride in that.
Now to the next bit: how to make games. For the benefit of the uninitiated reading this, there are middleware programs called game engines which allow you to take assets such as your model, sound files, etc., and have them interact in a way which makes them a game. Then you “build” what you have made as an executable file. There are a number of game engines out there (and big studios have their own proprietary engines). The big names are Unity, Unreal Engine, and Cryengine (there is also Lumberyard which is a version of Cryengine). They all have different payment structures, but you can start for free. It seems very daunting at first but there are many tutorials out there and, as with all things, just playing with it will help. We considered all three engines and went with Unity (some people will find that controversial!), and our reasons and experiences are going to be in a follow up post.
So why did I say that how to make games and what it’s like to make them are impossible to discuss separately? Well, putting a character in a room and having him play a sound effect is not making a game any more than chiseling a piece of marble is sculpting. To those that don’t do it, it may seem that way. But the sculpting is done in the mind before any physical work, and the sculptor continues to think as he goes. Making a game, as opposed to a software demonstration, is all of that botany and colour nonsense I referred to (and gameplay of course, but that is still cerebral work). I will admit I underestimated game development at the start, thinking that if I could put pieces together, I knew all there was to know, but that isn’t the case. The good news, ironically, is that because so much goes into making games, everyone can do it. If you have never coded in your life, but you know something about carpentry, or fish, or some other random nonsense, chances are you have a skill that will be useful to the game you make that the next guy doesn’t have. An interest is the only prerequisite.