NEW MUSIC (OBSCURITY)
Originally posted on FidelumGames.WordPress.com on October 1st, 2017
Here comes Obscurity!
This was the first song I made for The Wayfarer. I actually did intend to do something a bit (a lot) brighter, but at times you really can’t really control what comes out. 
And since I liked how it sounded and felt, I kept doing it until it was ready. And I’m glad I did.
If all goes as planned, during the next week I should be getting a new pair of stands for my Behringer Truth B2030A monitors. After that I can direct these studio monitors correcly, which should have a positive impact to mix quality. For now they have been positioned strongly asymmentrically, so they are next to useless during mixing, and 99% of the work has been done with headphones. That 1% is the last rouch check if there are any frequencies that come through in piercingly strong way.
Can’t wait to have them.
BR
Mika Pilke
HURRAH! MILESTONE #1 REACHED
Originally posted on FidelumGames.WordPress.com on October 13th, 2017
First off:
YAY!
I’ve reached my first major milestone in the development of The Wayfarer. My enemies (as far as behavior goes) are complete! They still need to be replaced with proper models and given the ability to die (along with dropping loot, etc.), but all of the AI and related systems are complete and, as far as I can tell, mostly bug free.
I think that, in order to stay motivated, it’s important to celebrate these small successes, so last night I had a few drinks, and today I’m writing this post and giving myself a pat on the back (good job, me).
So why did I decide that this was my first major milestone?
In my development experience thus far, one of the hardest and most frustrating things I’ve found is the difficult and delicate act of creating and maintaining complex interconnected systems.
All of the individual items I’ve completed so far for my enemies (attacking, spellcasting, navigation, stats, decision making, editor tools, etc.) have not been overly difficult to implement individually. Sure, there were some challenges, but nothing too major. The real challenge is making all of these things fit together in a way that they all still work, and doing so in a way that makes sense and doesn’t cause terror when thinking about having to change something.
The reason I’m considering this to be my first major milestone is because all of the features mentioned above, even though they’re all individual systems, are now combined into a larger closed system. This means that I know each individual system works, and I know they all work together, and the stress of having to make that a reality is gone! Moving forward, I can start working on smaller systems again (like player actions, looting, inventory management, levelling, etc.), which is a quicker, simpler and more carefree process than integrating said systems.
Of course, once those individual systems are done, I’ll have to integrate them into another closed system, thus reaching another milestone. But, to keep myself realistic, and to prepare myself for the difficulties to come, I do realize that once ‘closed’ system number two is complete, I’ll have to connect it to closed system number one.
I have no experience working with systems on this scale, so this is a huge learning experience for me, and I don’t know what to expect. Part of me is expecting the worst, another part is optimistic and hopeful that I’ve paid my dues in terms of keeping the code clean and sensible, and should reap the benefits when the time to integrate comes.
Anyhow, I’m super pleased and happy at the moment, and can’t wait to start working on new features again. Hopefully things go smoothly for the next little while and these posts will start getting a little more frequent.
This was a huge hill to climb, and I’m glad to be at the top of it (even though I can see the top of the much larger hill in the distance).
SQUISHING MAGICAL BUGS
During most of my last five or so development sessions, I felt I was making very little progress.
I had my spell system pretty much complete, but the process for creating new spells had become too in depth and complicated, so I had to redesign some things and make some pretty major changes.
Originally, I had been using ScriptableObjects for my spells, and while it was cool, and made me feel like a ‘real game developer’ to be able to create a spell by clicking Asset>Create>New Spell in the Unity editor, it just wasn’t practical for my purposes.
I wound up sticking with trusty ol’ prefabs in the end. While the new system isn’t as generic as the old one (visual effects are now part of the actual spell prefab), it’s much more friendly and maintainable, and I’m able to create new spells in a matter of just a minute or two (not counting VFX creating time).
Reworking this system was fairly straightforward. What really sapped my motivation and frustrated me was a bug that I just couldn’t squash.
Many of the spells in the game will apply buffs to the caster, or to the caster’s enemy. These buffs have the ability to fortify or weaken any stat that exists in the game, and, when being used by an enemy, who the buff is being cast on (self or enemy), is important.
I’ve designed my AI in such a way that, after it has decided to cast a spell, it chooses one at random, filtering out any spells that aren’t available to be cast. I’ve defined a spell that’s unavailable as one which:
- Has a range less than the distance between the caster and the target
- Costs more mana than the caster has available
- Added a buff to the caster which is still active
The most important item on this list, in terms of the bug I’m about to describe, is number 3. I don’t want my enemies ‘wasting’ a turn by casting a buff on themselves which they’re already benefitting from. However, enemies are fully ably to cast the same buff on the player multiple times.
The caveat with this, however, is that I don’t want multiple buff casts on the player from the enemy to stack. Instead, I want a re-casted buff to reset the remaining turn duration of the buff on the player.
The exact opposite was happening–the buff was stacking leading to a spell which should cause a -2 to strength to be able to cause a -10 (or whatever other number) instead. Additionally, this was causing the player’s stat to increase when the buff wore off.
This was a relatively small bug, but it drove me absolutely bonkers. Like I said, I spent somewhere around five sessions trying to fix it, getting little else done.
Here’s the original method which caused the problem:
public void AddActiveBuff(Spell spell) {
foreach (StatusEffect buff in spell.StatusEffects) {
if (!IsBuffActive(buff)) {
activeBuffs.Add(buff, spell.Duration);
stats.AddStatModifier(buff.stat, buff.amount);
} else {
activeBuffs[buff] = spell.Duration;
}
}
}
Can you spot the error?
I’ll give you a hint: I use a Dictionary to store my activeBuffs, where they key is a StatusEffect object (the contents are unimportant), and the value is an integer representing the number of turns remaining for the buff.
I fiddled with this friggin’ thing forever. I changed how I stored my activeBuffs, considered adding some polymorphism to my Spell class, creating multiple arrays to store the data–all kinds of things. In the end, I commented out a single line on a whim, and found the problem:
public void AddActiveBuff(Spell spell) {
foreach (StatusEffect buff in spell.StatusEffects) {
if (!IsBuffActive(buff)) {
activeBuffs.Add(buff, spell.Duration);
stats.AddStatModifier(buff.stat, buff.amount);
} else {
//activeBuffs[buff] = spell.Duration;
}
}
}
Yep. One line of code. Seems to always be the cause of these tricky bugs.
Because my spells are prefabs, the StatusEffect objects attached to them are instances belonging to the instance of the Spell when cast. Therefore, because the key in my activeBuffs Dictionary is an instance of a StatusEffect (something I overlooked, foolishly thinking that two separate but identical StatusEffect instances would be equal), I was adding a new entry to the activeBuffs Dictionary with the above commented line, rather than just resetting the duration of the existing entry.
Of course, when I discovered this, I shook my head, and solved the problem in about thirty seconds by comparing buff names rather than objects:
public void AddActiveBuff(Spell spell) {
foreach (StatusEffect buff in spell.StatusEffects) {
if (!IsBuffActive(buff)) {
activeBuffs.Add(buff, spell.Duration);
stats.AddStatModifier(buff.stat, buff.amount);
} else {
foreach (StatusEffect activeBuff in activeBuffs.Keys) {
if (activeBuff.name == buff.name) {
activeBuffs[activeBuff] = spell.Duration;
}
}
}
}
}
Once that was done, I was able to move on to fixing another small bug with my custom Stat inspectors, decide not to make another change regarding how buffs decay (a concern caused by the bug) and add a small piece of code that ignores the turn system when the player is not in combat (allowing for quicker exploration).
Once those items were done, I suddenly realized that I had actually reached my first milestone and the frustration and lack of motivation I had been experiencing transformed into excitement and vigor.
One more time:
YAY!
WHAT’S NEXT
With that cumbersome set of tasks out of the way, what’s next?
Well here’s what my task list has to say:
| 1.3. Milestone 1 Wrap Up – Complete Basic Turn Based System | In Progress |
| 1.3.1. Refactor and clean-up existing code | |
| 1.3.2. Document all existing features – UML, GDD, Code Comments | |
| 1.3.3. Celebrate! | In progress |
| 1.3.3.1. Have a few drinks (YAY!) | Complete |
| 1.3.3.2. Celebratory blog post | In Progress |
Yes, this is actually on my task list. These things are important!
But, more technically, here’s what the rest of my task list looks like at the moment.
| 1.4. Player Combat Actions | |
| 1.4.1. Attacking | |
| 1.4.1.1. Melee | |
| 1.4.1.1.1. Create Placeholder Weapon | |
| 1.4.1.1.1.1. Attack Animations | |
| 1.4.1.1.1.2. Damage Enemy | |
| 1.4.1.1.1.3. Ranged (Spear, etc.) | |
| 1.4.1.2. Ranged | |
| 1.1.1.2.1. Create Placeholder Weapon | |
| 1.4.1.2.1.1. Define how moving projectiles affect turns | On Hold/Tentative |
| 1.4.1.2.1.2. Projectile Animation | |
| 1.4.1.2.1.3. Magic | |
| 1.4.1.2.2. Casting Animation | |
| 1.4.1.2.2.1. Implement | |
| 1.4.1.2.2.2. Dual Wield? | On Hold/Tentative |
| 1.4.1.2.3. Define how the player will use dual wield (Attack both at once, choose which hand, etc.) | On Hold/Tentative |
| 1.5. Define item types (Consumable, Weapon, Armor, Quest, etc.) | |
| 1.5.1.Define item script heirarchy | |
| 1.5.2.Determine item commonalities and differences | |
| 1.5.2.1. Create item hierarchy | |
| 1.5.2.2. Weapons | |
| 1.5.2.3. Create Weapon Scriptable Object | |
| 1.5.2.3.1. Make Weapons equippable (through editor) | |
| 1.5.2.3.2. Share common animation based on type | |
| 1.5.2.3.2.1. Practice with Infinity Weapons | |
| 1.5.2.3.3. Practice with Mesh Effects | |
| 1.5.2.3.4. Integrate Infinity Weapons and Mesh Effects | |
| 1.5.2.3.5. Procedural Weapons | |
| 1.5.2.3.5.1. Experiment with Infinity Weapons texture generation and Blend Shapes at Runtime |
I made these items quite a while ago now, so the list will change before I actually start working, but this will give you a general idea of what I’ll be working on.
The On Hold/Tentative items are ones that might not be needed, or that I have yet to fully decide to include in the game.
POSSIBLE NAME CHANGE
The last thing I’ll mention is that I’m considering changing the name of the game. I really like the title The Wayfarer; I think it sums up what the experience is essentially about. However, performing a search for the title, it seems too common a name.
The first page of Google alone is filled with restaurant pages, and there are even a couple of games already existing with names similar to The Wayfarer.
On the other hand, performing a search for my last game Pixel Zombie Shooter brings it back as the top result, and The Wayfarer has a much larger online presence than Pixel Zombie Shooter as far as all of the blog posts, Youtube videos, etc.
So, I think that if I’m going to change it, I should do it sooner rather than later. What are your thoughts? Anyone with marketing experience want to chime in?