This post is the first in a trip down memory lane, looking at how the Esther Drifters project got to where it is today.
In the last post I hinted that I’m under no illusions that this project is a massive undertaking for a single developer – especially one who works full time, has a family, and a long back log of video games I want to play – let alone build! Ten diverse levels of gameplay, assets, and story? I must be mad.
But here I am anyway.
So, where does one begin with a project of this magnitude? How do you get from “nothing” to “everything”?
From the very beginning, of course.
Long before the name “Esther Drifters” came about, the project was known as “Concept X”.
“Concept” because it was a new concept I was trying out, and “X” because I already had one broken Unity project called “Concept” and I needed to name the new game something!
I’ve been thinking about the finished game for a number of years, but when I began, I pushed all dreams of pretty graphics and polished animations out of my mind, and replaced it with a simple mantra.
If it ain’t fun with rubbish graphics, it ain’t gonna be fun with good graphicsMe
I decided to begin with a simple ‘whitebox’ prototype to prove the cover-based gameplay, and slowly build up from there.
Looking at git, my first commit was on Tuesday 9th January 2018, and a day later I recorded the first gameplay video.
As you can see… there’s really not much going on there.
In this build, the player can right-click to have their blue capsule move around the Nav Mesh, automatically avoiding any obstacles. Meanwhile, the ‘enemy’ capsules will be moving randomly from point to point.
For anyone that’s stumbled across this blog and is watching the video and thinking to themselves, “Really? I could knock that together in no time at all!”, you’re absolutely right! That is the whole point!
The idea is to start somewhere. Break some ground. Lay a foundation. Commit something. Produce a build. Show it to your friends. Once you’ve done something, hell, anything, you can start telling people you’re a game developer.
Now that you’ve begun, the next step is easier. Simply build on what you’ve done.
Cover, States, and Commands
I produced the second video few days later on January 14th 2018, and visually there’s almost nothing new going on, but under the hood a lot has changed.
By clicking on the side of any cube, the player’s blue capsule will move into “cover”. The enemy AI no longer moves randomly, but responds to the players position, attempting to put themselves into a safe cover position – that is, one where the cover is between themselves and the enemy.
This piece of functionality is the very core of almost every other aspect of the game. Since then it’s been tweaked and adjusted dozens of times, but the basics and the code at the foundation have remained relatively unchanged.
By the time the January 14th video was recorded, I’d also built the core systems that governs player and AI behaviour alike – the State Machine and the Command System. The full implementation of these systems will be the subject of an in-depth technical blog post, but at a very high level, all behaviour for the player and enemy AI is described in a number of “State” classes. For example, while moving, actors are in the “Moving” state, while in cover they are in a “Cover” state, etc.
Moving between these states is handled by a system of “Decisions”, which are pieces of code which examine the state of the game and if certain criteria is met, they will return a new State to be activated.
As a player, input actions like clicking the mouse or pressing a button will issue a “Command” to the selected actor. The data structure for an Actor’s commands is a little odd – sometimes it behaves like a queue, other times it behaves like a stack. These Commands are used as part of the Decision making process of the State Machine and can trigger State changes. When a Command has been fulfilled, then it is removed from the Actor. Enemies work in exactly the same way, but rather than being issued by an input device, the commands are issued by an “AI Director”.
Again, this is core functionality that went in very early. The code was – and still is – pretty ugly and messy, but it worked. That became a second mantra for my development process:
Don’t let perfect be the enemy of good.Voltaire
Rather than getting bogged down in making the code aesthetically pleasing, I hammered out something that worked and moved onto something new. Only when messy or poorly structured code became problematic would I spend time on fixing it. The goal, as always, was progress progress progress.
The First Arena
The final video for this blog entry comes from the end of January 2018 – the project is now three weeks old at this point.
You’ll see from the video that the game is still butt-ugly, but has moved from the single white square plane to a crude arena built entirely of Unity’s default cubes, flattened, stretched and rotated to create ramps and floors.
Arguably the most important feature of the game is now present – shooting, and how shooting interacts with cover.
In short, when shooting, if your target is behind valid cover, it is impossible to hit them. Conversely, if your target is out of cover, it’s impossible to miss. If you pay close attention, you can spot projectiles curving in mid-air Wanted style to chase down their victims. It wasn’t for almost two years that enemies started missing the player!
From the start, I’ve wanted to create an illusion of chaos in battles. Bullets whizz past the player, sparks fly and smoke fills the arena, while in reality the player is safe as long as they’re positioned well. I want to create space for the player to pick their moves carefully without having to panic and micro-manage their units. I still haven’t quite captured this feeling yet, but a future blog post will take a closer look at the steps I’ve tried to bring this feeling to life.
The End of the Beginning
A journey of a thousand miles begins with a single stepLao Tzu
If you’re an aspiring game developer and you head to any game development forum, and post your grand idea for the next great MMO that you’re going to build single-handed, you’ll probably get laughed at.
Even pitching a project like mine will probably raise a few eyebrows if you’re an amateur just starting out (like me).
And honestly, that’s probably the right reaction.
I don’t know if I’ll ever manage to finish this project, but as I’ve mentioned a few times already, the goal isn’t the destination – it’s the journey. Hopefully this blog post has demonstrated that no matter how big or grand your plans are, the starting point looks pretty much the same. Start out small.
Prototype a single mechanic, and then another and another. Tweak, polish, experiment. Don’t worry about how bad your code is (yet), or how crude the art is. Just keep on going, and before you know it, you’ll be well on your way to be a game developer. It won’t be long until you can post screenshots and gameplay videos to those same forums, and people will start raising their eyebrows for an entirely different reason.