First game in Unity: 4) Mutations

With the basic game mechanics working, the game needed some fleshing out. A single level without anything other than the player, the target, a single enemy, and a goal was all very well and good as a proof of principle setup, but certainly no more than that. There needed to be some more challenging features and other gizmos that added to the gameplay, things to both help and hinder the player. And how long was this game going to be anyway? I didn't have any grand plans for making the next Final Fantasy rival just yet, but I also wanted something more than the briefest flash in the pan. That wouldn't be any fun for me as the creator or for anyone else as the player.

Looking at the single square plane that I had representing my game world at the time, it seemed about the right size for a self enclosed single level, so I didn't want to change that. The project was feeling more like something that should be a puzzle game in an enclosed space rather than an adventure game in an extended landscape, and it seemed like a good idea to have the camera at a fixed angle with the full plane completely in shot at all times. New levels would be cast on new planes of the same size, rather than be in some adjacent area that the player must travel to. Considering the size of the full game at the same time, I imagined extending that plane into a cube, which could rotate and have a different level on each side. Without using any one side for more than one level, that would then cap the game at six levels, which seemed like a good target number for a first game. That would be enough to get my teeth into, without going overboard.

This vision presented itself with its own set of tangent tasks. Having the cube placed and rotating nicely, getting to all sides one-by-one, was a well defined problem but one that had its own nuances in order to best solve. I became well acquainted with Unity positioning and rotations by this exercise, finding out the quirks of how angles are handled by the engine. It wasn't quite as straightforward as I imagined, actually, and I ended up writing my own code that would keep track of angles turned in each axis frame-by-frame, ensuring that the rotation ended up spot on each time. I didn't want there to be some gradual drift with each motion, causing the top face to slowly move away from being exactly flat. Any effect like that probably wouldn't have been noticeable with only six levels, and so only five rotations from beginning to end, but I still wanted to be sure. Again, this was all partly for my education, and having a mathematical background means I can't help but consider these details. Plus, they're fun to work out. The approach may not have been entirely warranted and it may not have led to the best possible method, but such things are learnt in time. The knowledge gained from solving any problem all goes into the pot for helping to solve future problems, both in the approach and in the detail.

Having set all characters and gameplay aside for a while, I ended up getting a pretty smart looking cube rotation method. One turn about one axis, another turn about another axis, then back to the first, and so on, until all cube sides had their turn on top. Each rotation happened at a button press, ready to be swapped out by some level-clear signal I would later come up with. After getting comfortable with all that, I then indulged in developing a little bit of intro animation, with the cube rotating in towards the camera from the distance at the very start of the game. Yes, not the most important thing to do at that point really, seeing as I didn't have any proper levels made, but it was an easy win on the back of the cube rotation work I'd done up to then, and was a satisfying addition that started to make the project feel like a proper game.

At this point, the cube itself almost seemed to be a character in its own right in some ways. After all, the intended characters were basic geometric shapes as well. It was certainly the most striking aspect on the screen at any rate, especially with the intro sequence. I realised that the original idea of considering the good and bad guys as angels and demons, hence the working title "AngelRush" that existed at that point, was perhaps more or less outdated already, seeing as I hadn't found any appropriate character models and had decided on spheres instead, for use with an overall geometric look. And so the project had its next set of mutations with its name.

The short-lived "AngelRush" (which is stashed on my list as a future title) then became "Cube", but I really wanted something a bit more funky, and so "Cube" soon became "Qube", because spelling tinGz in KraZy wAize is kül. I then found out that a real game developer had already beat me to that one, and actually the game looked pretty nice and maybe another one for the to-do list. What next ... let's try "Queb", which I could sort of see as being read "Cube" myself, but the first non-me person to see it pronounced it "Kweb". Dang. Definitely don't want "Kweb". Alright, one more try. Let's just pile on the abstraction and go for "qb". Vowels and uppercase are overrated these days anyway. Looks neat. Rotationally symmetric "q" and "b" if lowercase sans serif, ooh, I like it. Okay, so some people will say "queue bee", some people will say "qub", some will say "huh?!". But never mind. To me, it's said "Cube", and I think it looks pretty snazzy.

And with that, the environment had taken on a life and a name of its own, and came to embody the spirit of the game itself. By not locking things down too hard at the outset, the game was free to evolve in this way in all aspects throughout development. Questions led to solutions that inspired mutations that drove iterations, and so on until the game told me that it was ready, rather than the other way around.