A CLEAN SLATE, I’VE CREATED A MONSTER, WORKING MY MAGIC, PREPARING FOR THE FUTURE
Originally posted on fidelumgames.wordpress.com
Strap yourselves in. This is going to be a big one. And hang in there. There’s some good media part way through.
A CLEAN SLATE
Since my last post, I let myself get a bit out of hand as far as staying disciplined goes.
I had made some decent progress, and had some cool things to show off, but most of what I was showing was only superficial progress. The things I’m talking about are environments, enemies (actual animated models, not just cubes) and some UI stuff.
The problem with these things is that they were all parts of incomplete systems.
In one of my earlier posts, I wrote:
“…I decided that, although the game is still in a super early state, I owed it to myself to add a bit of polish and replace my cubes with one of the assets I acquired.”
This was a mistake, and led to me falling back into my old habits of sitting down to a development session and asking myself, “what do I want to work on today? What would be cool?”
The result of this workflow was getting a given feature ‘good enough’, making it look cool, and then moving on to something else with the intention of returning to the feature I had just ‘completed’ in order to finalize and polish it.
The problem with this was that I would often go too long before returning to that feature (if I did at all), and forget the mental model required to finish the system properly. I basically wound up with a bunch of fragments that didn’t fit together.
This quickly became overwhelming and really sucked my motivation away.
What I really owe myself is to not add any polish until the game is ready for it.
Luckily, things have been slow at work lately (until today), and so I’ve been left mostly to my own devices. Without any project work to complete, they let me work on pretty much whatever (as long as it’s somewhat related to what we do there), and since Unity is part of the skill set I use on a regular basis at work, I was able to justify working on my own game in order to increase my proficiency with Unity.
God how I wish that was the norm. Working all day long on something I love really makes the time fly.
Some day.
Anyhow, with all of this time to work on The Wayfarer, I decided it was the perfect time to throw away everything I’d done so far and start over, with a new mentality. This might seem like a bit of a waste, but I’ll be able to reuse some of what I’ve done, and consider the original work as a prototype.
The most important thing I’ve been doing is forcing myself to plan everything (except for the smallest tasks) before I even open Unity.
This prevents me from sitting down and asking that awful question “what do I want to work on today? What would be cool?”. Instead, I ask myself, “where did I leave off? What needs to be done today?”
My new workflow goes something like this:
Look at my task list (something I never had before, but to which I adhere strictly to now) and see where I left off. If a task is in progress, pick up where I left of. If not, move on to the next item, adding to the task list as required.
These tasks break down essentially into two categories: planning/design and implementation/development, and both groups take up about the same amount of time.
Before I write a single line of code, I establish my algorithms in my GDD in plain English (which feels strangely similar to coding).
Then, I draw an activity diagram based on the algorithm, identifying any logic flaws along the way and revising the algorithm as required.
Finally, after all of that is done, I move on to actual coding–simply translating the algorithm and diagram to code.
All of this might seem like overkill (and it does feel like a pain in the ass sometimes), but it’s all worth it in the end, and makes writing the code so much easier. Not only that, but my code is cleaner, more robust and more easily expanded upon.
Way fewer headaches now.
For those of you interested, here’s one of the plain English pseudo-code examples taken right from my GDD, and the corresponding activity diagram (these are for enemy AI):
Enemies will have the ability to make the following decisions:
Patrol
Wander
Pursue
Retreat
Engage
Melee
Ranged
Magic
There are 3 base states which an enemy can be in, which will determine available decisions:
Unalerted
Alerted
Injured
If an enemy has not seen or been attacked by the player, it will be in an unalerted state and will always either Patrol or Wander, unless it has seen or been attacked by the player within x turns.
Patrolling will always occur if patrol points exist for the enemy, otherwise it will wander.
If the enemy has seen or been attacked by the player within x turns, it will be in an alerted state.
In the alerted state, regardless of whether the enemy can currently see the player, it will always ‘know’ the player’s position, unless x turns pass without it seeing the player, in which case it will return to an unalerted state and continue to either patrol or wander.
While in the alerted state, the enemy will first check if its health has dropped below the injury threshold. If it has, it will randomly decide whether to heal (if available), continue engaging, or transition to the injured state.
If the enemy is still engaging, it will check if it is within a certain range of the player (a range it will consider to be dangerously close to the player). If it is and it has any available defensive buff spells whose effects are not currently active, it will perform a random check as to whether it should cast the buff or perform another action.
If it decides to perform another action, it will check if it is facing the player and if it has a clear line of sight within a range of y, where y is the longest attack range of an
