First off, I want to thank you all for your immense patience as I know it has been a long while since we have given an update on things! We have been hard at work with all sorts of new features & improvements, and I hope to update you on as much as I can!

Initial Playtests

We are thrilled to have an open signup to playtest our early build of TurnTide Tales, and it has been super helpful in our quest to make a great game. From feedback on the world, battle mechanics, difficulty, controls, and for getting an overall feel of the interest level in the project, it has been invaluable for our entire team. While we know not that many people have played through everything available in its entirety, we are still absolutely delighted that they could play any of it and enjoy it!
There are currently builds of the game available to play on Windows, Mac, and Linux. While it does take a few extra steps, you can even install it on Steam Deck and enjoy the playtest on the go! If you are interested in giving the game a try, check out our Discord to sign up, or just to hang out with our small community, some members of which also have great projects of their own you should check out! Scan the QR code below or go to: discord.gg/VWr8hwvSFU

Playtest Results and Minor Bugfixes

With our initial build we showcased at GodotCon last year with a hands-on demo, and with the various dev releases since then, our playtesters have brought some important bugs, issues, and unintended features to our attention. We have since made some control changes within battles to help improve the experience, and have dealt with some specific bugs that prevented certain battles from working as expected, among other smaller fixes. We are still working on some visualization and game flow improvements to help address some of the known issues with enemy units, camera angles, and UI, but we had a few critical pieces in the works already that we wanted to finish before getting to everything else.

Strap in, because things are about to get a bit technical!

Dev Tools and Technical Updates

Dev Console

One of the first things we added after GodotCon was a proper dev console! Thanks to the great Godot community, we were able to find a nice base for this feature in the Limbo Console addon made by Limbonaut. This console is accessible to us developers and playtesters alike by pressing the `/~ key while in-game, and thanks to the addon’s extensive feature set, it is capable of hosting context-dependent commands each with their own documented behaviors.

We have fleshed out the console with a number of commands that let us do things such as quickly teleport around the islands, give our character super speed and mega jumps, outfit our units with new equipment on-the-fly, and plenty of other similar actions that we use to test the mechanics of the game more efficiently. This has been a huge help on my end specifically as I can travel the islands quickly to check out map changes, get to battle locations, and test some of the new balance changes across them.

CI/CD Pipeline + MacOS & Steam Deck Support

To aid with the process of actually compiling & releasing the builds of our game, we put a continuous deployment system in place for our game’s code repository. With the help of Barichello’s godot-ci script as an initial frame of reference, we were able to fully automate the cycle of building the project for each OS under a clean environment, packaging the builds up, and pushing them to our itch.io playtest page. For those that are curious, our current CI/CD setup relies on separate git branches that we push to to trigger the pipeline when we feel we’ve reached a good point of progress.

When we first built our game for GodotCon, MacOS builds were fully off the table due to some incompatibilities within our compiled addons (notably the WIP Godot 4 version of DijsktraMap which we use for graph-based pathfinding) + other factors of the project. But after some fixes to those addons as well as the addition of our new pipeline, we are now able to build natively for MacOS! It may be in the minority of operating systems that players will typically use, but we’re happy that it’s available as an option regardless.

In a similar vein, while Steam Deck play was technically possible before via the Linux build, some related project updates have made true Steam Deck releases more viable (and much easier to test), and we have fixed several partial incompatibilities that would have made it less approachable on that platform before. We still know of a few oddities/bugs here and there but we’re confident that we’ll be able to support a good experience on the Deck going forward!

Project Structure Overhaul

The largest singular update ever made to TurnTide Tales is one that players will not notice; we completely reworked our project’s directory structure, and have put some important tools in place to help us keep things organized.

As the scope of our game is quite large, we had started to notice some issues when it came to navigating our initial file structure, so finding a solution was high up on our priority list as to avoid increasing our technical debt over time. Our previous project directory was largely built around a split by file type - we had a separate folder for assets, one for shaders, another for materials, and even more for other types of resources, scripts, and scenes. We initially chose & kept with this structure due to general recommendations and prior success on smaller projects, but in practice it didn’t scale well.

While we had felt our original structure was well thought out early on, the more assets we added, the less sense it made. This was made especially clear after a recent development shift where more of our other team members started working directly on & referencing the project source, it just made sense to simplify, rework, and restructure things for everyone’s benefit.

After thinking about why the project was becoming a burden to work with, we figured out that it was largely due to the aforementioned file type split. At a small scale, this can work really well - if you have a certain shader to look for, you can find it quickly & easily just by opening up the shaders folder. But at a large scale this flattened list becomes tedious to navigate. To deal with this, we of course added in subfolders to split each of these files into conceptual groups, but as our project grew, we found ourselves maintaining multiple sets of subfolders across each file type, so there was a lot of repetition going on.

The solution we arrived at was to reframe the structure completely; instead of splitting by file type, we would split by domain. This means that the primary file navigation method is to first search by a high-level idea, concept, or feature, move onto more specific sub-categories, and then find the specific file(s) that belong to that specific idea/feature. This means that when we need to work on a part of our game, we usually just need to filter down by feature just one time to get access to all the files we need, rather than repeating that process across several different root folders.

Getting to this structure was a ton of work (also because of many little refinements, consolidations, renames, and cleanups along the way), but has already been well worth it! To give an example: In an older version of our code, working on a single in-game prop could have involved opening up a .glb model file in `assets`, a .tres material in `materials`, a .gdshader shader in `shaders`, an inherited .tscn scene in `scenes`, and a behavior .gd script in `scripts`, each under any number of subdirectories, whereas with the new structure each of those files can be found in one directory under something like `game/entities/props/my-prop`. It took some iteration for us to land on a structure we really liked, but in the end we found one that works well, with some top-level folders for common things like `addons`, `editor_tools`, `showcases`, and `tests`, as well as our main `game` folder that contains all the in-game code.

Overall this restructure totaled 3000+ file changes for over 90,000 total changes across 70 commits according to our GitLab project tracking! Along with the main file restructuring, we also took this opportunity to update our Godot version (to 4.6), and we even built our own custom project addon that allows us to assign fully custom icons, colors, and descriptions to our folders. Here’s a sneak peek at what that looks like!

Resource Registries + Save File Improvements

Along with the main structure changes, we decided to make use of the relatively new Godot addon YARD (Yet Another Resource Database) by Elliot Fontaine. This takes the form of a lightweight database that works natively with Godot resources, providing convenient table-based editing, and with it we can easily & efficiently access registries of resources like items, weapons, equipment, quests and a lot more. We even made use of this to overhaul our battle prop system to provide project-wide default stats per-prop, all editable through a single table!

This ties back into the main project restructuring: because of the overall scope of our game, we wanted to make sure to build out some of our backend tooling in order to help the project scale more easily. In this case, we used registries to switch over nearly every old instance of hard-coded file paths/UIDS to registry lookup keys, which allowed us to even update our save file format to use these keys for more robust saves & future migrations! Not only was Sam able to integrate it into our new structure, he was able to add some custom advanced settings features and became a contributor to the public YARD repo.

Initial Camera Work for Cutscene Tools

While we are still a little bit out from building in-engine cutscenes, we know we are going to need a fairly robust set of camera controls to support them, and similar visual framings for other parts of the game. So we decided to move forward with building out some of the basics in order to have repeatable footage across multiple builds of the game. To date, we have put together 3 separate custom WIP addons that are intended to work together to make this type of work easier to manage - one for easier visualizing & editing of positional data on resources, one for easier synchronizing of nested scene data in the Godot editor, and the main one for all of the camera shot controls & effects that will be used in the editor and in-game (assisted by the Phantom Camera addon).

As soon as we finish up these camera features, not only will be be able to use them to make rudimentary cutscenes and world overviews for the demo, we’ll also be able to use them to put together some cool side-by-side video comparisons (which could be a wonderful addition for our Devlogs) and trailer recordings. Here’s a sample of what some of the current tools look like in the main editor window, with a visualization for a preset camera path + a preview window that shows the camera view as it moves along that path.

Battle System Multithreading and Tooling

As we continued to build out/update more battles, including the massive one in Fort Surftrail, we began to notice even more hitching and stuttering when our enemy pirates would take their turns, in some cases freezing the screen for more than a full second at a time. This was already a known issue, and somewhat expected as turn based strategy games do require quite a few computations due to the numerous actions each unit can make (especially since many of our computations aren’t optimized yet), but nonetheless we were a bit surprised to see it get this sluggish already. We’ve known for a while now that as the complexity would grow, it would become more and more important to support multithreading for our enemy units to push the calculations off of the main thread, and so we have been working on doing just that.

While early on we knew our initial node-based navigation system would work well enough for smaller battles, we endeavored to get multithreading working in anticipation for future battles, but at the time we found a few critical flaws in the system that would make it untenable to support without a serious overhaul… so that was postponed until now. One of the biggest issues to work through was how we saved, synced, and updated data across our game objects, which in a single-threaded architecture worked just fine, but would cause undefined behavior across multiple threads. We have started reworking this structure to decouple game objects and better define where game state is stored in a way that should allow us to effectively multithread our existing calculations without the threads clashing unexpectedly. Along with these critical changes, we’re also taking the opportunity to rework our editor tooling for these nodes to make the design & editing of battles much easier overall.

Battle Changes

That's right, new balance changes to battles! In our initial playtest build, many of the attacks were very similar in that they were generally just scaled damage and stamina values relative to other attacks. Now there are multiple different styles of attacks you can do, each with different trade-offs. In our early playtests we noticed that players tended to hold back and use melee attacks less frequently than ranged attacks, so to incentivize the player to be a bit more aggressive, all melee attacks now cost less stamina and do more damage than their ranged counterparts.

Not only have we added some variation to attacks, we have also been discussing and trial running some other changes to the battle look and feel. Over the last year we have been playing through the battles repeatedly to nail down the basics and make sure we are happy to add more of the features we want. After quite a bit of discussion, we landed on a decision to increase the size of the individual nodes that are traversable, leading to fewer nodes to move between overall, and making movement a bit less granular. This is because while playing the battles, we noticed that there were quite a few turns in which both players’ units were simply traversing the battlefield and not doing much else. By increasing the node size we are hoping to get the player into the action much quicker and make each turn more impactful.

This does reduce the number of options for specific places the character will be able to move to, but we believe this will greatly cut down on the bulk of “dead locations” that are nothing but a place for the characters to move through with no standout tactical significance. Ideally, each node within a battle should have some aspect that distinguishes it from its neighbors, but in the current battles it’s clear that this just isn’t the case. We’ve already tested this size increase internally on a couple of test battles and have found that it met our expectations well, leading to a more interesting gameplay loop overall, but it will take a bit of time to rework all of our existing battles with this updated design philosophy in mind!

Visual Changes

A great deal has changed to the Breezy Isles and even more is happening behind the scenes for a major graphical overhaul. Below you will find a few screenshots/gifs to a few of those changes, but we will be putting out another update in the near future covering the changes that will alter even these recent visuals in a majorly positive way. We hope to share the new updates soon but we want to make sure we get every shader, texture, and model in a state that is the best it can look (while still being performant)!

And that covers the bulk of our update for now! Along with the various upcoming visual updates, there are a ton of other game features & mechanics that we plan on diving deeper into in with our future devlogs, so keep an eye out! And there are a couple upcoming events that you should keep an eye out for as well…

Places We Will Be!

This year we will be attending a few conventions to show off the demo, connect with developers, and hopefully hang out with some of our lovely community members! Here are two of them that we can confirm our attendance at:

With all of that said, I hope you enjoyed this long overdue update! See you next time we come to shore!

(Hopefully sooner then last time!)

In our first development log we gave a brief overview of the characters, world, and gameplay that we are creating. Today we want to give a bit more information on our combat system and what you’ll be able to expect when facing down the enemies of our tumultuous trio!

Spread across our open world are various areas where combat can occur. Depending on the context of the battle, they may start when the player gets close, or after a cutscene, or even on a simple button prompt, but either way you should always be prepared for a fight!

Once you have entered combat, your perspective will shift to give you a slightly better view of the battlefield and the tactical grid will appear. First off, you’ll need to place a number of your crewmates within the deployment area that is highlighted. Each visible space is a ‘node’ that you can later move to, shoot at, or swing a sword towards, among other options, but only the highlighted nodes can be occupied by your units. Once you are happy with their placement you can start the battle!

Each battle is turn-based, and a turn consists of any number of different actions & events that could spell the end of your journey or lead to a glorious victory! On a team’s turn, each crew member can perform a limited number of actions up to the maximum allowed by their Stamina bar. You can choose to use all of your stamina to move to an advantageous location on the battlefield, go all in on attacking and fire your pistol as many times as you can, or mix it up with any combination of attacks, moves, using items, or special options in the Order menu. Different actions consume different amounts of stamina, and we have plans to introduce additional forms of limited resources intro the fray, so you’ll have to make your moves count!

Attacking allows you to choose from different attacks for each weapon and an enemy (or object) to attack. Once each is selected, you will enter into a short minigame that can lead to bonus damage if you do well. Don’t worry; you will still do a base amount of damage even if you miss the timings! The mini game consists of a path of points that you have to hit at just the right moment, very similar to some rhythm games you might’ve played before. Each attack will have a slightly different path, and some weapons may even provide special attacks that will test your abilities!

Moving your units is quite simple. Once you select the option, you'll be able to select and move to any space within movement range that is not currently occupied or blocked by another unit or object.

Items can range from one time use healing items, bombs, and battle-changing equipment. Items will have many different uses and they can be found all over the map. Whether you heal yourself or your crewmates, light some cover on fire to drive the enemy out into the open, or create cover of your own to block line of sight, items are powerful tools to fill out your arsenal. 

Orders are special abilities that are based on the character, and are influenced by your position on the battlefield and the objects around you. Fire cannons located about the battlefield, use character specific-abilities like picking up cover objects, or call for backup from your crew below deck to turn the tides of battle in your favor!

While much of this is still a work in progress, we are so excited to have shared this with everyone as we continue to push forward. Our aim is to have fun, dynamic battles that still allow a great deal of depth in their strategy, and allow players to freely experiment with team composition, unit skills, and equipment builds to their hearts’ content.

In other news, we will be headed to GodotCon 2025 in Boston, Massachusetts! We are thrilled to announce we will be a part of the showcase held there, and anyone who comes to the convention will have a chance to give TurnTide Tales a try! We hope to see you there!

By ‘celestial void’, we of course mean the much anticipated GMTK 2023 Game Jam, and by ‘we at ComfyMitten’ we mean ‘we at ComfyMitten’. Taking on this challenge represents an exciting step for us all, much like how a child might feel riding a bike with training wheels for the first time. First, we go around the block with this Game Jam - then, we take off the training wheels, slap a lawnmower motor on that bad boy, and tear off toward the sunset with the future release of our very first game!

It’s easy to see a blank page just getting started like ours, and think “who are these newbies”? In reality, this group is composed of a small team of very talented artists (who I have the privilege of working alongside), which has been active for over a year now! Sleeping, dormant, until the moment to raise our heads arrived.

And now it’s here - wish us luck! And, if you would be willing to, check us and the other amazing creators in this contest out here: https://itch.io/jam/gmtk-2023

The ComfyMitten Team