I’m working on a little game project. I emphasize that it’s a little project because a lot of consideration has been made to keep it as simple. I want to downplay its significance so it keeps me happy enough to work on it without the added burden of spectral expectations.
I’m working on it with Richard Falla, a friend and co-worker of mine who I’ve also worked with on different commercial projects in Toybox. During one lunch time, Richard, Terry, and I discussed how many 5 year-old kids we could take out before we got taken out ourselves. This light-hearted pondering over violence on little kids captured our interest, and became the basis, the seed, of this game.
At first, we were both decided on doing it as a top-down or isometric sprite-based 2D game. I had been working with Construct 2 for some time doing an RPG experiment (read: Shelved project) and thought it would be a good place to start. Richard drew up some animated sprites for me to test with and although I got something rudimentary thing working, I quickly realised something. The concept of Zombots was getting a mob/crowd of zombie robot kids attacking the player. C2 did not have anything — that I knew of — related to crowd-based pathfinding and AI that I can employ readily and be able to tweak as needed. I wasn’t interested — nor qualified — in coding a scratch-built AI pathfinding system in a C2 (HTML5) JavaScript environment, I quickly lost interest and gradually let the game scuttle up The Shelf.
Then some months later, Richard and I went back to talking about it. Unity cropped up in our conversation because I had dabbled in Unity before — as had Richard — and I was quite aware of its NavMesh/pathfinding features. I knew that among all of the other game engines out on the playing field, Unity would arguably have the most user-friendly implementation (for my coding background, that is). But would we get the 2D/illustration-like feel in 3D? In the absence of any real solution in C2, or similar game makers, and that Unity was freely available for personal use, we decided ‘why the hell not?’ Like I said, I had only dabbled in Unity never having enough reason to dig further. But this time, the momentum seemed to keep building.
Richard provided a proxy character model that I rigged it in AdvancedSkeleton; I did some idle and run animations, exported it via FBX, and from there, things progressed smoothly. Richard pointed to me a Unite conference tutorial on game-making which reflected many aspects of what we intended our own game to be. (Looking at it now, however, it doesn’t seem that similar.) I followed the tutorial most of the way, and more than a refresher course, I got to understand better how things worked in Unity.
I must admit, however, that this game isn’t the kind of game I’ll be picking up on Steam. I tend to play games like The Division, or Splinter Cell, or something with a serious theme, or something retro. For those who know me, a zombie game — be it robotic or organic zombots — of all things, wouldn’t be readily associated with me. But I think that’s what makes me less invested and more methodical in my approach. I see the game as a big program full of yet-undiscovered bugs, as a simple but (hopefully) entertaining system of ropes and pulleys. I can approach this game from a purely technical standpoint, and a purely creative one, because my own desires doesn’t get in the way.
I’ve been documenting my progress in a private developer’s diary, and perhaps after the alpha is ready, I’ll be more encouraged to make different aspects of the development more public. As it is, I’ve never done a game before, so the only professional claim I have to this is the fact that I’m working in 3d, and working with code; that being the case, I keep my enthusiasm to myself to prevent it from leaking out. It’s like keeping the warmth in by not opening the window.