Featured Blog | This community-written post highlights the best of what the game industry has to offer. Read more like it on the Game Developer Blogs or learn how to Submit Your Own Blog Post
A large update discussing rework, AI, Spellcasting and editor tools.
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.
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 any of its usable (has enough mana) attacks or abilities.
If this case is met, but the distance between the player and enemy is less than y, the enemy will make a random decision to either move backward to increase distance (up to, but not beyond y), or to attack.
If the distance between the player and enemy is equal to y, the enemy will always attack.
If the distance between the player and enemy is greater than y, but the enemy has seen or been attacked by the player within x turns, the enemy will attempt to move closer to the player.
While moving along the calculated path to the player, the enemy will always favor movement over turning, if available. It will do this by first favoring forward movement.
To favor forward movement, the enemy will calculate a new path from the cell in front of it to the player. If this path is shorter, it will move forward. If this path is longer, or the same distance, it will follow the original path.
Enemies may have an option for sidestepping. They will always favor this strafing over turning if it has been enabled for a given enemy.
This process will continue until either x turns have passed without it being attacked or seeing the player, in which case it will return to an unalerted state, or until it is within range of the player again and can attack.
While in the injured state, the enemy will check if it is dangerously close to the player. If so, it will make a random decision to flee, or heal (if available). The enemy will remain in the injured state for at least x turns (unless it has healed itself beyond the injury threshold), but not more than y turns.
If it is not within a dangerously close range, the enemy will always heal if available. Otherwise, it will move away from the player.
When leaving the injured state, if it has seen or been attacked by the player within x turns, it will return to the alerted state—otherwise, it will return to the unalerted state.
I have to say that with all of the practice I’ve gotten in lately, and my new workflows, I feel like I’ve just come out of a learning plateau, and am reaching a new skill level with programming and game development.
I’ve been spending nearly all of my recent development time working on my enemies.
This and the following two sections will deal with the details of that.
The first thing I did was rework my enemy AI, again with my cubes.
I feel like my new system is much more robust, as I’m able to get a wide variety of behaviors just by modifying a few values in Unity’s inspector.
I’m able to make my enemies favor ranged combat or close quarters (or any combination of the two), physical or magical attacks, determine how often they’ll heal themselves, and how likely they are to cast buffs on themselves during or in preparation for battle. I’m also able to dictate how aggressive they are by setting the chance that they’ll become injured and retreat during battle, and for how long they’ll pursue the player. I’m also able to dictate how well they can see. All of this without ever (hopefully) having to touch the AI code again (except for bug fixes).
This system relies on a simple state machine in which the enemy can be Alerted, Unalerted or Injured. In each of these states, the AI will choose how to behave based on their preference for a particular behavior.
You can see more about this system in the pseudo-code and UML shown in the above section.
I’ll show a short video of the AI in action in the next section, but for now, have a look at the variables exposed to the inspector which determine an AI’s behavior:
My goal with my magic system is to allow myself to make everything as generic as possible so that I can easily create new spells without writing additional code, by easily adding status effects to spells, being able to reuse the same visual effects for different spells, setting whether the spell is a projectile or has an immediate effect, or combining/linking any number of spells or visual effects.
The system itself is pretty difficult to explain. Suffice to say I use ScriptableObjects, prefabs and Animation Events, and can just work within the Unity Editor to make new spells. Also, I can just drag spells into an enemy’s spell list to give them the ability to cast them.
The system itself is pretty much done (with the exception of making status effects actually dosomething), but I’ve yet to put any legitimate visual effects in. Just differently colored spheres for now.
Here’s a short video showing how customizable I’ve made spells (I have hopes of letting the player create spells while playing as well):
One thing I would like to point out that I think is kind of cool is the ‘Blood’ Magick type. This type of spell costs health instead of (or in addition to) mana to be able to cast. I see these spells being used heavily by warrior type players who have a lot of health to spare, but maybe don’t have enough mana to be proficient spellcasters.
And, here’s a video of my enemy displaying how it behaves, and how changes in its values modify its behavior.
Note that the different balls are placeholder for different spells, and the green thing is a placeholder for a physical projectile, like an arrow.
Don’t mind the bugs.
Along with all of this planning and trying to ‘do things right’ (if there is such a thing), I’ve been working on getting all of my stats set up, and having them actually be meaningful.
The need for this came out of creating the status effect portion of my spell system, which needed stats to be defined (or at least a shell of them) in order to work.
I’ve broken my stats down into three categories:
Primary/Governing stats: These determine all secondary base stats, and base proficiencies with tertiary stats. Very D&D-ish.
Secondary stats: Anything directly tied to primary stats. Health, Mana, Carrying Capacity, etc.
Tertiary/Skill Stats
Weapons & Armor (Dual wield, Ranged Weapons, Heavy Armor, etc.)
Magick (Proficiency in different types of Magick)
Other (Things like lockpicking, etc. If I decide to put them in the game)
The Player, enemies and NPCs all have a common set of stats, and then, of course, some that only apply to a certain character type exist only where necessary.
Nothing overly exciting here, except that I created my first custom inspector in order to make modifying stats easier.
Here’s a before and after:
This inspector lets me modify governing stats and see how it affects everything else. It also allows me to easily modify all stats and quickly restore a character’s health or mana at run time. Hopefully this saves me some time in the future.
That’s it for me. Stay tuned for more!
PS: We’ve got a new team member, but I’ll wait for him to introduce himself!
Read more about:
Featured BlogsYou May Also Like
.png?width=300&auto=webp&quality=80&disable=upscale)
