Good Times with Shaders

Another month has passed! I feel like I’m getting in to the swing of writing these blog posts. Since the last episode I’ve done a lot of work on the game visuals and especially in the UI.  So without further ado here’s the change notes for this month’s dev work:

• Created Unit animations for walking and idle states

• Added palette swapping on units to support configurable skin tones and hair colors

• Added a Pause Menu

• Created a custom font

• Migrated all the in-game fonts

• Revamped every UI in the game

• Controller support + input glyph support

• New loading screen

• Fog of war & weather presets

• Learned Blender

• Rebuilt town wall sections using Blender

• Integrated YarnSpinner for better dialogue scripting

• Downloaded Fmod

A friend asked me how I get so much done and the secret is to be consumed by the project every waking moment.

Ok starting things off I created walking and idle animations for our core 5 classes (Yeoman, Acolyte, Scion, Wretch, and Chevalier) so now those classes have walking animations when they’re moving around the map and slow idle animations to give the game a bit of motion while they’re just sitting around. Prior to this change I was using a static sprite render on the unit game object for all units. In order to get all the animations hooked up and on their respective units, I had to make prefabs for each unit class and set up animation controller overrides.

Prancing Horsey

I was starting to hit a problem doing the animations, which is that up until this point each unit image was hand made, meaning I had separate images for enemy yeoman and friendly yeoman. But I was struggling with the idea of having to create 3-4 animations for every unit for every shirt color, for every skin tone, for every hair color, for every weapon (yes we have specific weapon art)  This was just too much.  So I did some research and ended up creating a shader that will palette swap the unit art for shirt color, hair color and skin tone, meaning my possible combinations decreased significantly.

The way it works is that we have 8 or 9 “greenscreen” colors defined that just happen to have the 9 lowest Red values of any colors in our game’s palette. So the shader sorts all colors by R into an array and if it wants to render a color it does a simple lookup as to whether to swap out the color or not.  I then generate a 1x256 texture that contains the target colors for a unit based on the selected hair, skin, and shirt color and the shader swaps to those colors. It’s all very fancy.

Green screen Landsknect

Changing gears I had a goal from last time to revamp all the UI in the game, which I did! It was a lot of UI.  Early in the project I had made very simple UIs partly because I wasn’t comfortable with the system yet and partly because I didn’t know what kinds of information I’d need to present.  So I have been wanting to go back and update a lot of them. Especially the equipment select and action preview screens needed a lot of work.
I got to take advantage of our fancy new progress bars from MMF_Feel and overall I think the clarity of the game has improved significantly.  The full list of UIs that I updated are:

• Pause Menu (new)

• Battle Prep menu

• Equipment Management menu

• Promotion Menu

• Battle Participation menu (unit select)

• Unit Inspection menu

• Unit info menu (top corner panel)

• Game Log

• Terrain Info Menu

• Objective Info Menu

• Equipment Selection Menu

• Action Preview Menu

• Loading Screen

About 95% of all the UI in the game got at least a small update.

Speaking of the loading screen, this got a big overhaul. It was kind of a placeholder screen before but I wanted to do something cool with it. I saw someone on Bluesky post a while back “what’s the point of making your own game if you don’t build a sick loading screen?” and that stuck with me.

The loading screen is actually another custom shader that interpolates between the “sketch” image and the final painting.  It only has one set of images right now but I’m in the process of painting a bunch more.

Along with my great UI revamp I swapped all the game’s fonts and ended up creating a custom font just for the game!  I realised that I had spent a lot of time making sure that the UI was pixel perfect but that I was cheating when it came to fonts, so I really needed to get fonts that would render at the same pixel density as the rest of the game. I picked up a pack of fonts which I use for the Heading font and the small text, but I didn’t have a good one for the medium headers.

Showing off Rathdrum Serif

I did some research and found this tool online for creating custom pixel fonts and after a few days trial and error I ended up creating an 11 pixel font I’m calling Rathdrum Serif.

Along with the font work came controller support and input glyphs. I had some stuff in old builds that was just kind of a placeholder, but I got a pack of input glyphs from Kenny assets and added them to my emoji system.  I was already pretty well set up for controller support and all the input hint text auto detects the most recently used input device and changes to that set of glyphs.

The last big feature of this month was fog of war and weather presets. A lot of classic fire emblem games have night time or fog levels where you don’t know where the enemy is until they’re right in your face.  So this was on my feature list from day 1. Each unit has a radius of visibility they have and there are also game board objects that can give or remove visibility as well. This will allow me to hide the inside of a sealed room even during the daytime preset.  This was the third custom shader of the month as the fog is a large texture that fills in based on the visibility of the tile below it. Those tiles are stored in a small generated texture with 1 pixel = 1 tile.

With the weather presets I was playing around with the game’s lighting and the walls in the city tileset have never respected the lighting in the game.  They were created by attaching sprites to the outsides of a unit cube primitive, so each one is actually 6 draw calls. I knew I’d need to change this. I started trying to build them out with Crototile3D but just kept bouncing off of it. No offence to the tool, I think it’s very cool but just couldn’t get in the flow.  I decided to take a shot using Blender and had a lot more success, I was able to migrate all the Tudor walls in the game and now they light correctly and are much more efficient to render. I need to do some more complex shapes for the door and some other doodads around the map so wish me luck!

Showing off lighting on these Tudor walls.

Finally to round things off I had a couple integrations. I decided that I am going to use YarnSpinner to help manage cutscenes and I started that work by replacing the existing dialogue manager with one that is backed by Yarn Spinner as a proof of concept. I just finished that today (as of the writing of this blog) and it seems to be working great. I also downloaded Fmod and started to integrate it but got scared.  I am going to be working with a very cool composer (you heard it here first) and he wanted to use Fmod so I’m going to sit down with him and make sure I get it set up the way he wants it.

For December, I think I will focus on polish. I have a nice lil bug list going at the moment and will try and bring in some additional art/animations before cutting another demo by year’s end. I also need to take the time to really dig into the game story which I’ve been neglecting for fun programming tasks, but sigh I guess I’ll go write some stuff.

Until then.

Cooking with Gas

It has been a fructuous month for game dev in my household. Starting off the month strong I made an appearance at Nexus and had some great chats with people in the Irish game dev community. Lots of great presentations, got some great feedback on the game, and a huge motivational boost. So maybe it’s no surprise that looking at my task list I made for last month’s dev blog I can say I’ve accomplished ¾ of them! I’ve added the following to the game:

• Buff & Debuff spells

• Active effects (like poison or heal over time)

• Class abilities

• Unique abilities

• Positional abilities (bonus for being near eachother)

• Additional terrain effects

• Conditional terrain effects (like how a closed door is impassible)

• Conditional actions (like opening a door)

• Lots of consumable items using all these new effects

• Weapon proficiency (and the framework for support conversations)

• AoE spells and attacks

• Battle Objectives ( not just kill everyone)

• Pause menu

I even threw in a few features not listed like:

• Integrate MMF_Feel library and migrate attack animations to use it.

• In-world health bar and status icons.

• Add a downed / revival mechanic for units that hit 0 hp

• Refactor the Unit.cs class and pull out a ton of logic into static utility classes

• Switch game balance to using a true level vs a display level system.

• Switched all the game’s fonts

Showing off the new unit info panel and new fonts

Oh where to begin? The month started with a lot of big and scary refactors. I completely re-wrote the combat and action system to leverage MMF_Feel as our main animation system which allows me to time and position sprites, movement, sounds, particles, and floating text with a lot more precision than before. It was a lot of hard coded guts getting ripped out and replaced with what is probably even more code just in new places.  The overall effect is that my side of things is a lot cleaner, and I have a lot more control over the animations so in general they feel a lot juicier and more impactful.

A side effect of integrating MMF_Feel is that I can use it for UI as well :) so the progress bars got a huge style boost and I was able to bring in some very nice tween animations for the unit info panels that slide in and out. I still have on my list to revamp a bunch of the older UIs and I’m excited to bring this new library of functionality to them.

A large number of completed features all tie in to the same system, which is Status Effects. I started by implementing a basic status effect system where a unit can get stacks of a given effect, at a specific trigger point that effect activates and a stack is removed. Then I tied those into some lifecycle events of the turn, so start/end of turn, before/after combat, on damage and on heal. I have some basic status effects in the game, poison/burn (damage over time), regen (heal over time) and stat buffs and debuffs (might up / might down).

Ylsse showing off all her abilities

Of course, had to make some new UI to show off all these cool effects and also added them to the unit info panel so you can see them at a glance.  The next feature, which I dubbed Active Effects originally, was easy to add on to this system. After some back and forth settled on Unit Abilities as the name for this system. They are effects which are permanent and come from either the unit’s class, or their weapon, or are unique to that unit.  A good number of these active effects create “silent” status effects in order to affect gameplay.

Some good examples of this are:

• Luigi’s Temper ability

• If Luigi takes damage he gives himself 2 stacks of Might Up (offensive boost)

• Aleyt’s Regeneration ability

• Aleyt always has 1 stack of Regen (heal over time)

• Yeoman Class’s Buddy System ability

• If two or more Yeomen end their turns next to each other they all get a stack of Guard Up (defensive boost)

Unclear if these will stay in the game exactly as implemented for now but I’m enjoying playing around with them.

Another system that piggybacked on the status effects is Weapon Skill. As a unit uses a specific weapon type over and over they gain a silent XP in that weapon, at certain thresholds that levels up and they get a passive bonus when using that weapon type. So rank D in swords grants the user +1 damage with sword weapons. The XP and tracking was new, but under the hood these give the player an Ability, which in turn gives them a silent status effect, which increases their stats in combat.

In-world health bars

The culmination of all this status effect and ability work came with the implementation of AoE attacks and spells.  This is a big departure from original fire emblem and even the modern games don’t do a ton in this space. But I was really interested in trying to increase the value proposition of buffs and debuffs. So having them affect multiple targets and last multiple turns seemed like the way to make that happen. There are a bunch of supported shapes but my favorite is the laser, which hits every square between the source and target.

Enemy Yeoman about to get lasered

Next I picked up another refactor that had been on my plate for a while, which was to split out tile gameplay properties from tile visual properties. I had, in my arrogance and naivete tied everything about a tile to a single enum, TileType. But this quickly became a problem with low walls and hills where we wanted a tile that looked like plains, but had defensive properties. So I was able to split it out and even was able to add some prefab overrides to my map editor so I can quickly override certain tiles with common effects (like closed door, hill, etc).

The crew hanging out between the terrain info panel and the objectives info panel.

Shifting gears I was a bit intimidated to start in on the work to expand the available actions to a unit. The action system we had was some of the earliest code in the game and took a long time to get working. Up until this point all our supported actions followed the same flow: Move -> select action -> select item -> select target -> preview - > do the thing.  And I was going to mess with that. I knew that I would need to do this kind of thing for Doors and Chests, where you have an action that is sometimes available based on your position, and the action doesn’t affect another unit. The flow for these new actions is Move -> select action -> select target -> do the thing. So thankfully no new steps!

Finally pulling it all together I finished off the month implementing a very cool feature I’d been thinking about for a while. In old Fire Emblem games it’s not uncommon to have to restart the whole battle because you make a mistake. In later game they’ve added a time-rewind mechanic to lessen the impact of a simple mistake. I had thought I would implement something similar even in my earliest design documents.  But in the mean time as I’ve developed this game and played through other SRPG titles for research, I kind of feel like the time-rewind is a cop-out. Either you don’t have many rewinds so you end up with the same problem, or you have a ton of rewinds, so you can use them with abandon and none of your decisions have repercussions.

Tybalt is down, this is not a drill!

I wanted something in the middle, so I’ve added a “downed” status to player units. When your unit hits 0 health they become downed.  Downed is a special kind of status effect and when you remove the final stack of it, the unit is truly dead. (Permadead dead). But while a unit is downed you can spend an action to rescue them, which sends them back to camp. They keep any XP they gained this battle, and they aren’t dead, they’re just out of the fight.  All of the systems implemented this month played a key role:

• The conditional location-based actions.

• The status effects

• The action animations (and hit animations)

Looks like someone’s about to be rescued.

That’s a lot of stuff and some of these deserve maybe their own whole blog posts.  Maybe I’ll start doing some mid-month features where I can deep dive one of these more fully. But I’m not committing to it. You didn’t just read me committing to doing more things.

So after all that, here’s what’s remaining on that original “all of q4 milestone” list from last month:

• UI revamp for some of the oldest menus and UX

• Early skeleton campaign system

• New battle tileset: Town (art and assets for battles in a town)

Granted some of these are big, ambiguous, items (laughs in early campaign system) but at times like these all we can do is add more stuff to the to-do list! Stuff like:

• Walking and Idle animations for base classes

• Fog of war (can’t see into buildings you haven’t opened yet)

• Night missions!

• New Main Menu Art

• Polish, so much polish.

Yeoman off for a stroll.

I am aiming to have a vertical slice for this game in the springtime so I’m going to slowly be shifting away from new features and into polish, quality of life fixes and visual updates. Still plenty of new features to go before we get there.

Until then.

Milestone In the Bank

This is the first of our monthly dev blog posts, and it’s a big one!  At the time of writing this I’m preparing to send out a Friends & Family playtest build, so I’m doing all the last minute preparations and playtesting for that. This demo represents the culmination of a 4-month milestone (although I prefer to think of it as my Q3 milestone).

The original milestone demo was all about the core of the game, moving units on a grid, using attacks and items, taking damage.  It was playable but very spartan.

Screenshot from my original demo build

Since that build the theme of this milestone has been “Persistance.”  And I’m proud to say I’ve taken the game a long way from a group of hardcoded units on a hardcoded map, to a much more robust and data driven game. The changenotes for this milestone include:

• Created a map editor tool (and maps!)

• Integrated map editor improvements back into main game

• Unit XP gain and level ups

• Unit class promotion

• Unit equipment selection

• A persistent roster of units to select from

• Saving and loading player progress

• Persistent unit death

• 8+ new classes

• 20+ new weapons and items

• Visual upgrade with post processing effects

• New environment art, portraits, and unit art.

• Clouds!

• Music and SFX

• Improved AI logic

• Main Menu and Loading Screens

• Bug Fixes & More!

The final battle in the new build. My roster is not prepared!

There are two big pieces in here that stand out to me looking at this list. I think I spent a month on the Map Editor and another month on the UI for equipment selection, promotion, and battle participation.  Both of those features were monumental undertakings.

The map editor is a scene within Unity that I “play” in order to place tiles, doodads, and spawn points onto the grid and then the map is serialized and we can load it into the actual game from there.  It was literally making a separate little game that just had a useful output. I decided to do serialized maps because I didn’t want to have a separate unity scene for each battle. I’ve had bad experiences in the past maintaining and updating that large number of scenes. However this does mean that I need to be able to pack and unpack literally everything about a battle.  And adding anything means creating a system to understand it.  But overall I’m happy with my choice. (for now)

The map editor tool with a preview of some content coming down the pipe :)

The pre-battle UI which has all the options for promotion, equipment select and roster select was also a huge undertaking. Each one of these menus has several states they can be in and data needs to pass between the states. States needed to be navigable forwards and backwards and components needed to be reusable. Each of these menus for example feature a unit selection sub-menu, so the flow is

• Select the menu

• Select the unit

• Perform the modification (equipment, promotion, or participation)

I won’t lie, I got stuck a few times and had to re-think my approach. I started trying to make an omni menu that could contain any number of submenus in any order, but the logic to move between it all was too complicated.  So I ended up making that omni menu a shell and adding a layer on top that managed what sub menus we needed and the logic to navigate through. So in some ways each menu is bespoke, but I got to re-use a bunch of UI layout. It’s not a perfect solution, but I think it is a model I’ll try and use when I start on the campaign UI in the future.

Choosing which unit should change their equipment.

The biggest upgrade I think from an outside perspective is the dynamic lighting and post processing effects. It takes the game from a very flat looking experience to a breathing 3d world made up of flat people. I was inspired by the likes of Octopath Traveler and Triangle Strategy who use similar effects in their games, and I hope to stand out from those two titles because of my more vibrant color palette and environments.

So what is next?  Well the theme for this milestone was “Persistence” and I’ve decided that the next one will be “Strategy.” It’s still early days but my goal is to focus on all the things you might do in a battle that aren’t attacking, really filling out the strategic space. My list right now includes:

• Buff & Debuff spells

• Active effects (like poison or heal over time)

• Class abilities

• Unique abilities

• Positional abilities (bonus for being near eachother)

• Additional terrain effects

• Conditional terrain effects (like how a closed door is impassible)

• Conditional actions (like opening a door)

• Lots of consumable items using all these new effects

• Weapon proficiency (and the framework for support conversations)

• AoE spells and attacks

• Battle Objectives ( not just kill everyone)

That’s already quite a list!  And I’d like to tack on a few extra things that aren’t quite on theme but I think are important as well:

• UI revamp for some of the oldest menus and UX

• Early skeleton campaign system

• Pause menu

• New battle tileset: Town (art and assets for battles in a town)

Ok I’m done. Jkjk I’ll think of more.  I’d like to aim for another one of these milestone demo playtests around the end of the year with as many of these features as I can get through in that time.  I’ll be posting updates here every month with what features I've ticked off and which ones are still to come.

Until then.

Humble Beginnings

I am not much of a blogger, but here goes. I started this project the day my son turned 1 year old. I was looking for a creative outlet and an opportunity to try out technologies that I wouldn’t encounter in my day job.  This isn't the first game I’ve attempted to make by myself, but it’s certainly gone on for the longest. Every time in the past I tried to make something completely new, unique, and the perfect distillation of my creative process. And every time, I would get so caught up trying to figure out what the game *should* be that the game never got made.

So this time would be different, I would just make a game I already knew. I thought about different kinds of games that I like playing and two series came to mind. These are games I’ve played over and over, nearly every installment multiple times. I wasn’t about to make a Pokemon clone though.  So here we are. I set forth to make a game that was like Fire Emblem.

When this project stated I didn’t know very much about CSharp as a language, I’d never made pixel art before, I’d never done a lot of things: many of which deserve and may get their own blog post.

We just recently passed the 6 month mark of making this game and it’s come a long way.  Rathdrum is a Strategy RPG set in a renaissance era fantasy world. It features styling and sensibilities of GBA-era Fire Emblem but with modern visuals and game design. Every month I will aim to write one of these where I will go over the accomplishments of this month and my goals for the next. For now though, I’m going to get back to fixing bugs.