First game in Unity: 2) The basics

One of the first aspects I knew that I wanted for my first game was to have two central characters, with one being directly controlled by the player and the other tagging along. I'm not exactly sure why this thought came about, possibly because I was playing "Nier: Automata" on PS4 at the time, or possibly because "Ico" on PS2 is one of my all-time favourite games, both of which have a similar aspect to them. Unlike those games, however, the next idea I had was to have the non-controlled character, let's call them the "target", be somehow corrupted by an enemy character. When corrupted they would no longer follow the player, instead wandering off on their own into potential danger. The idea would be to save the target, to lead them to a safe zone before they become irretrievably lost somehow. That seemed like a neat central idea and one that I could run with, and importantly I knew that would be fairly doable with the knowledge gained from the "Create With Code" course that kicked off my Unity learning.

Fleshing that out a bit with some theme I could mentally latch on to, I considered the scenario of the player as an angel, the enemy as a demon, and the target as some earthbound resident who will either be guided to the light or fall into the darkness, as it were, depending on whether or not the player manages to save them or the demon manages to corrupt them beyond salvation, respectively. Keeping things simple, I considered having a small play area surrounded by a void into which the target would fall if they wandered too far, and with some shining patch of light that provided a goal for the player to lead them to. With such a setup, I would then be able to make a bunch of various layouts and puzzles that the player would have to work through in order to lead the target to the goal and clear the level, allowing for various challenges with various levels of difficulty. And, most importantly for any creative endeavour yet to produce any output (book titles, band names, world domination plans etc.), this little project of course needed a funky name. How about "AngelRush"? I'm not sure how, but I cooked that one up pretty quickly and didn't dwell on it too much, in order to just get down to trying to make the thing. And so to making the thing I got down.

Even though it's the first thing to be noticed by players, and quite often the main selling point of a game, aesthetic is often the last thing considered by developers when designing functionality and gameplay, other than as a theme to keep in mind. The characters in my little game all started out with simple little capsule bodies, and with simple little capsule noses added soon after so that I could tell what way they were facing. Blue for the player, yellow for the target, and red for the enemy of course, especially as I was considering them as some kind of demon. Have you ever seen a blue demon? No, didn't think so. Got to be red. Basic player control was initially added as a direct start/stop response to arrow key presses on/off, but I then moved to a physics based approach that applies actual force calculations to a character, taking into account their attributed mass and shape and so on. Any entity can have its position and rotation locked in any direction with given Unity toggle switches, which makes it straightforward to keep the characters upright at all times if that's what's needed, and in my case it was. After sticking with the physics approach for quite a while, I actually returned to the direct start/stop approach as it was simply more responsive and actually felt and looked more natural for how I was implementing it. The physics approach was too slippy, and the characters would scoot around the play area as if on an ice rink, and I chose not to keep tuning things until it was just so to stop that from happening, as the original approach was already acceptable.

That was perhaps my first important lesson, and one I would happily state first and foremost to other beginners - try not to perfect things in one go. Whatever it is that you're trying to implement, you'll likely either want to change at some later point in time, or drop completely, or will find better ways of implementing thanks to solving other problems as part of the overall journey. Get some part working well enough, then move on to the next part. Once a full set of ingredients is in place, then return to each in turn and reiterate if still needed. Trying to keep some forward working momentum and not getting stuck tweaking can be a challenge, especially if you do have a specific idea in mind, and there's certainly something to be said for sticking with a problem until it yields. Learning how to balance that attitude with the need to get a project done is a skill in itself, and one that is continually being learnt as experience is gained. Same with any other creative process. Is that sauce not quite tasty enough and could do with some tweaks to the spice, or does the pasta actually need to go on now? Are the sentences in that essay not quite as well cut into paragraphs as they could be, or are there other points that need writing first? You've got to consider all tasks during development and call it all done at some point, and that may not exactly be the last supper you're whipping up or the next world changing treatise you're compositing. Then again maybe it is, but still the sub-issues will likely best be served by the cycle of iteration, driven by the underlying forward momentum of the project as a whole. Tastiness beyond compare shall be upon them come that supper, and the world shall be cast in light anew by the glowing text of that page. But until then, those capsule guys need some more excitement in their own lives, so let's return to help them out.

With some character control in place, the basic mechanics for a full working game was as follows. The target starts out stationary, without a care or a goal in their little square world except the sight of the terrifying unfathomable void surrounding them. The enemy, with as much menacing demonic intent as can be conjured by a red capsule with a cute button nose, makes a beeline for the target. If the enemy touches the target, then the target starts moving in a random direction until they reach the edge and find out how good Unity's gravity physics is. Once the target is corrupted, then the enemy makes a beeline for the player and generally becomes a nuisance. If the player touches the target at any point, then the target starts to follow the player, who understands that the shiny patch of light looks more appealing than the darkness and sensibly leads the target there, the successful achievement of which wins the level and calms their heart. The forces of good triumph once more. Take that demon capsule.

These rules can be fully formed and applied to the characters with only a few lines of code, and although those basics were simple enough to implement, the effect of seeing it working as a starting point to a first game was really rewarding. There was instantly a gameplay dynamic, some kind of life in what was happening on screen, and it was more fun than it perhaps should have been to just play around with nothing more than that for a while. For anyone else it would have been pretty boring, I'm sure, but as the creator, it's extremely rewarding to have some vision and then see it in action after working it all out, however small it may seem. Game creation is one arena that provides that kind of experience, and the act of creating in and of itself becomes a game. The micro problems are your enemies, the macro problems are your levels. And the big nasty problems, well, they're your boss fights. With this state of things in the bag, I could happily declare the game of game creating, level 1, as clear. The project was on its way.