The Ebonheim Chronicle

Development Blog for Chronicles IV: Ebonheim

It's been a really wonderful week of getting my combat system into the hands of interested parties! I want to take some time to pontificate on the last 14 months as well as talk about the future.


Slow and Steady

I had largely given up on personal game development over the last few years. It really just demanded so much of my time and never ended in anything but disappointment. I also now have far more commitments throughout the week than I ever have before so it really started to feel like there was just no room for it anymore.

So when I was bit with the bug of this game, it was time to employ some new strategies.

This biggest difference between this project and every other attempt at making games in my life has been a fairly tight budget for time to work on it. There's a lot of life that's been happening and so I can't just go and dump 80 hour weeks into it. I've had to learn how to cope with the knowledge that large systems are going to potentially take weeks and that there's going to be fairly big gaps where I don't really get to touch it.

Once I began to make my peace with it, I found a much healthier relationship with my side project. I always coded and designed with the expectation that something might not come together for a while, and optimized for prioritizing systems that I immediately need rather than dumping large times into theoretical architecture. I also haven't, so far, burned completely out on the immense feature list by burning the candle on both ends week after week.

The fact that I could take a few months off and play Dwarf Fortress or get distracted with Tears of the Kingdom and still just come back and keep going with it is a testament to a better relationship with the work.

The Combat System Milestone

Early into the project, I identified that the scope was just enormous and had so many ideas going on. I knew it was too much for a single person to accomplish in any reasonable timeframe but also I knew that this was largely a hobby project for my own curiosity; something to tinker with in the evenings.

As I became more excited about the overall design that was brewing, I decided to break it into completable chunks to make progress somewhat realistic to track. Knowing at the time that I was prone to abandoning projects and could very well never see this dream completed, I wanted to design standalone games that would have ~80% overlap with the final vision. If I never completed the game, at least I'd have something to show for it.

At the heart of Chronicles' design is the tile-based combat. The initial elevator pitch was “Nethack, except with Disgaea-like tactics abilities, and Into-the-Breach's perfect turn information.” I also employed the health and stamina system that I had designed for a previous unseen real-time dungeon crawling project which fit perfectly into the gridded turn-based environment.

Regardless of how big the world is or how the character progression works out, the central heart of the game's success to me was making the combat fun. I hate kiting enemies into hallways in roguelikes and wanted something better. So if I couldn't make that elevator pitch work, there wasn't much use in continuing the project.

And so I wrote out the essential pieces necessary for making a standalone “Combat-Puzzles” game where each level you had to use your abilities to defeat the enemy formation. I forbade myself from thinking about shops, and world maps, and faction turns, and equipment, and instead focused on an asset-defined combat actions system for creating complex abilities, UI for turn result messaging, and creative enemy AI.

By far the biggest success of this way of doing a milestone is that I had to make an actual game around the combat so splash screen, menus, tooltips, and audio. I had to do a ton of shell architecture to actually present the combat to players so being forced to do that this early in the process was extremely beneficial!

Playtesting

I wanted to get feedback on whether or not the combat was fun from people without needing the larger structure to be defined. I was really self-conscious about the demo just coming off as a weekend game-jam game and I wanted to clearly denote that it's building toward a larger goal. I tried to call it a mechanics playtest more often than calling it a demo because felt weird to solicit feedback from something that is only tangentially related to the final product.

To help get feedback in this specific context, I solicited volunteers to playtest via a google form and then I chose to publish to a password-protected itch page, only sending out access to people who volunteered to help test. To me this encouraged participation from people who have been following this blog or otherwise have a personal interest in the project. This helped me with feeling anxious about people not understanding the goal of the release and it helped me organize and track feedback and issues.

I wanted to create a direct line of communication to people, so that I could address their individual needs and encourage sharing any thoughts. A big thing that helped a ton in this respect was to provide a list of feedback concerns and questions on the itch page. Nearly everyone who responded with feedback directly addressed those points! It was extremely effective to include those prompts!

I'm so incredibly thankful to the wonderful people I've gotten to meet and interact with this week!

Replays

I've designed my game with functional determinism in-mind and one of the big gets out of that is that it's easy to record user inputs in a game session and then simply replay them on my own copy of the executable.

The replay files are a compressed format including mouse movement and semantically-named game inputs all attached to frame-counts. By running the same version of the game with the same asset stack, I can replay those inputs and watch the player's session seamlessly. And since it's running the actual game I can

  • Hit break points in the code to track down bugs
  • Rewind to previous game states
  • Live-hotpatch the running code with Live++
  • Start playing myself from any point

This is enormous not just for focus testing but also for fixing bugs. I can see a bug in a replay and implement a fix for it all without restarting the program!

The final piece that made this perfect is including OpenSSL and DropBox's API to automatically upload the .chrep files to my DropBox for review. Naturally, I made sure to include a disclaimer at the top of the demo allowing the player to opt-out of the automatic upload. This system worked like a dream with replays from playtesters popping up on my DropBox within hours of sending out copies!

Often, by the time a tester had sent me their feedback email I already watched their session and could directly tie their experience to their feedback as though I had been standing behind them.

Cross-Platform

I recently posted about using Zig's build system to create cross-compilation targets for other platforms. This cost me nearly two weeks in mid-October but it wound up being a huge success! Although I could never get the auto-upload to work on those platforms, plenty of volunteer testers from Mac and Linux reached out to me manually sending me their replays.

I now have a simple batch file in my repo for building Windows, Mac, and Linux game versions all from Windows! M1 Macs coming soon!!

What's Next?

In between responding to testers and writing down notes and fixes, I've been doing a lot thinking about what my next actual development session even looks like.

As I crept closer to the combat demo being finished, I started to taste some of that forbidden fruit thinking about the larger game structure. I'm calling the next milestone “The Early-Game Demo” and is meant to be fairly representative (~80%) of the final product.

As opposed to the combat demo's level structure, this will have the run-based rogue-lite elements and be a showcase for the persistent world. I'm hoping that the full final 1.0 game release someday down the line will essentially consist of the Early Game Demo just with a ton more stuff!

Right now I'm putting my Project Manager hat on to try and build out a roadmap and prioritize all of the systems that need to get built. It's starting to sound like the first major task is replacing the current map system with a world-map grid. More on that another time!

Thank you!

To everyone who has followed my little side-project or gotten anything out of these blog posts! Whether you helped playtest, left a kind comment once, or just smashed that fave button, I really get so much joy sharing this thing with these little corners of internet!

Have a great day! :eggbug:

#gamedev #chron4 #longpost

Wishlist Chronicles IV: Ebonheim! | 🌐 | | | 🙋‍ |

I've spent large chunks of this week thinking about and then the last two days implementing a new build system with the goal of it being easy to get Chronicles running on Linux and Mac!

This was made possible with zig which is not only a language but an entire build system that works with existing C/C++.

After getting the code base to play well with clang, setting up the library linking with zig was a breeze! The entire build system is a single 200-line easy-to-maintain C-like file!

#gamedev #chron4 #zig

Wishlist Chronicles IV: Ebonheim! | 🌐 | | | 🙋‍ |

Something very hard about giving the player perfect information about how a turn will play out is that enemies can go before you in their turn order. This has caused a lot of confusion for testers because you might need to target an ability where an enemy is going to be rather than where they are.

My new idea for communicating this is that if your ability is going to affect an enemy at a position other than where they begin the turn, it shows a ghost sliding into where your ability will affect them.

#gamedev #chron4

Wishlist Chronicles IV: Ebonheim! | 🌐 | | | 🙋‍ |

Edit: The Combat Mechanics Milestone Demo is over, if you'd like to be considered for future playtests, you can email me at britown.cohost@gmail.com

If you'd like to try out the Chronicles IV Combat Demo currently brewing, I made a little form where you can submit your info and receive a copy.

This demo is designed as a smaller game than the full vision. It exists to narrow my scope and also start iterating on feedback from the Big Complicated Combat System.

Still not 100% sure when these will go out (very soon!) but I promised it would be this year and so it shall be!

https://forms.gle/x4Giibsu3WEgScLFA

#chron4

Wishlist Chronicles IV: Ebonheim! | 🌐 | | | 🙋‍ |

I wrote 3 months ago about how this is a particularly hard problem to solve.

For whatever reason I've been possessed to actually try implementing this over the last few days and I finally have something to show for it.

Here, the enemy has a teleport that has just enough range to cross the water and it has a long cooldown. Therefore the highest value path is to walk to the edge first, then teleport across to attack.

This is a dynamic use of the actor's abilities with no scripting!

Enemies are using abilities for the first time!

#gamedev #chron4

Wishlist Chronicles IV: Ebonheim! | 🌐 | | | 🙋‍ |

Sat down tonight to actually try and write a more complete song instead of little test loops using the Chronicles Audio Engine (tldr: 3 square wave channels and a noise generator)

I feel like it went very well! But I'm also completely new to this so any constructive feedback is welcome!!!

#gamedev #chron4 #tracker #chiptune

Wishlist Chronicles IV: Ebonheim! | 🌐 | | | 🙋‍ |

The final bit was getting my instrument editor working, including an interactive volume envelope editor. It works!!

#gamedev #chron4 #tracker

Wishlist Chronicles IV: Ebonheim! | 🌐 | | | 🙋‍ |

Haven't changed these tiles in a year.

Feedback welcome!

#gamedev #chron4 #pixelart

Wishlist Chronicles IV: Ebonheim! | 🌐 | | | 🙋‍ |

Just completed the second major refactor of the actions system[1]. This time the end goal is being able to query the final game state for a lot of complex result data that I've been needing to display in previews but it's been too much of a pain to aggregate.

  1. Here's talking about the first

Because action lists are arbitrarily complex it's actually very hard to answer some specific questions like “what actors did I damage?” Or “who pushed me?” You want to record some events as you iterate but you don't want to write special event code for every action type which is what I was doing and it scaled horribly.

Anyway the new system feels elegant and just works for all cases including future complex cases in my imagination.

This is the endgame I think of this system, it feels really complete now which is good because it's the primary focus of my demo and I'm tired of hacking at it. I'm honestly really proud of myself for making something that is extremely complex and also straightforward to maintain and upgrade. My code tidiness has really saved me from a lot of headaches.

The main result of this is that turn highlighting telling you what your choices are going to do is finally comprehensive and complete.

The exciting future that this enables, however, is that enemy AI behavior can now know things like “Will using this ability here damage my target” so I can build a system where enemies have behavior goals and can use their abilities and check the results against their goals. If you want to read me ranting about enemy behavior in the complex actions system, you can do so here.

#gamedev #chron4

Wishlist Chronicles IV: Ebonheim! | 🌐 | | | 🙋‍ |

It's super easy now to do in-line coloring and icons across all user-facing text in the game 😀

#gamedev #chron4

Wishlist Chronicles IV: Ebonheim! | 🌐 | | | 🙋‍ |