.png)
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.
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
| 🌐 | 🙋 | 
@britown@blog.brianna.town
Chronicles uses 2D tiles like other RPG's but organizes the world into an arbitrary tree of map layers. In the end, every position in the entire game is in the same world coordinate system with all exteriors and interiors existing on the same continuous map..png)
.png)
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.
I wrote