next »

[robotbard]

The original post is below, but here are a couple of the latest screenshots:


(full res: https://imagedelivery.net/2UL_jcamevOG_DnxYVt9CA/f07ea349-4ad3-4d7b-ef62-151158872700/public)




Hello, everyone! Welcome to the devlog for our untitled roguelike game mixing deck-builder, autobattler, and tactical RPG elements, in which you build and upgrade a fantasy team while fighting a series of battles on an isometric grid map, a la Final Fantasy Tactics or Fire Emblem. Proper development began November 15th.

I found an incredible design and art partner in Hari (hariedwin.com) while prototyping a different game idea with the same aesthetic, so despite being in development just a month, this game already has a beautiful set of animated job sprites:



Battles

I will dedicate the next devlog to a deeper dive of the battle system, which is the entire focus of development right now. The short version is this:

• You spend mana to move your units or cast their spells during the Strategy Phase.
• You gain mana through autobattler-like fighting in the Combat Phase. In this phase, enemies and then allies act in a random order to attack a random target in range or move into range of a target.
• Combat alternates between Strategy Phase and Combat Phase until all allies or all enemies die.

Here’s some footage from the prototype.

At the start, you deploy your team on the map:



You fight in automated combat to gain mana:



Here’s a tank spell that repositions enemies:



And a nuke from the Sorcerer:



Only the tileset, background, and non-cube sprites are Hari’s art specifically created for the game. The effects, UI, and icons are all (incredibly useful) assets from itch and will be replaced over time.

The Flow of a Run

Like all roguelikes, you start each run from nothing and make the best of the random choices you’re given. You get a couple random units, then fight increasingly difficult battles to fill out your party with new members and more powerful or synergistic abilities. Like so:



Building on the Tactical RPG Genre

I have a complicated relationship with the tactical isometric RPG genre (and I’m thinking about the JRPG variety, like FFT, Fire Emblem, Disgaea, etc.). There’s a lot to love:

• Team building and job discovery is fun.
• Growing your party from wimps into gods is satisfying.
• The heat of battle often presents interesting choices and opportunities to outmaneuver enemies and feel smart.

But even in the genre greats, things get in the way of the fun:

• You don’t have many combat options in the early game, so early battles are not exciting.
• The beginning and end of battles suffer from dead time. Beginning turns you’re just moving into range of the enemy, and late turns you’re playing out a won battle.
• The minutiae of isometric battles gets boring. Selecting the move tile and attack target for everyone every turn is not engaging.

My goal with this game is for each run to feel like you’ve skipped to the middle of a tactical RPG, right after your team-building and combat options have really opened up.

Building on the Roguelike and Autobattler Genres

I love deck-building roguelikes, and I love autobattlers. Drafting is fun! You find a build, make the most of what you’re given, and choose when to commit to a strategy or pivot to a new one. In general, they offer high input randomness and low-but-not-zero output randomness (shout out to Ben Brode for his wisdom on this topic at GDC: https://youtu.be/HjhsY2Zuo-c?si=Tl6aeD1eoFChG7jN&t=1886).

Some drafting deck-builders have you draft units in addition to spells, and unit drafting is at the core of autobattlers, but in all of these games the units you draft (almost always) have a singular identity – they only do one thing! To change strategies, you must replace your units.

I want to explore the design space of two-level drafting in a roguelike. At the first level, you draft your units’ jobs, and at the second level, you draft your unit’s abilities. I think of this as a modification of deck-building draft mechanics: unit abilities are “cards” and jobs define what “cards” are in the draft pool. This creates the opportunity for jobs to fill different roles in combat, or fill the same role in different ways. This also allows you to change the playstyle of your units as your strategy evolves. Perhaps your Scholar needed to focus on shielding allies at the start of the run, but after drafting a couple tanks you decide to pick up abilities for her to manipulate your team’s cooldowns or mana.

The flexibility of jobs becomes another input to drafting decisions and a lever for balance. As a player, do you draft the Ranger, who gels with your build and could fill the attack damage carry role if you find the right abilities, or do you draft the Executioner, who definitely fills the AD carry role but doesn’t exactly synergize with your team? And as the game designer, how powerful or situational do I make the Ranger as a carry, given his flexibility to provide utility or support?

A big inspiration for this flexible job design philosophy is Dota 2, which has a unique approach to balance in the MOBA space. It has pure AD carries, spell-casters, bruisers, and supports, but many Dota 2 heroes could play 2 or 3 or 4 roles depending on the meta and the surrounding team composition. For example, Naga Siren has been played as both a hard carry and hard support, depending on the items built and abilities leveled. Other examples are Sniper, Nature’s Prophet, Luna, and Weaver – there are tons! In a genre as min-maxed and competitive as MOBAs, that’s an achievement. Flexibility isn’t a numerical stat, but it is a lever for balance regardless.


Next in Development

It’s critical that the threat zones of the Combat Phase are readable at a glance. We will be experimenting with some visual elements to communicate who on the player’s team is in danger, and who is not. A design goal of the battle system is making the Strategy Phase and the Combat Phase flow together seamlessly, and more information is needed on the map or in the HUD to make good decisions during the Strategy Phase.

Even with Dragoon selected and Stone Warden hovered in this screenshot, it’s not immediately obvious that your Dragoon is threatened by lethal damage next Combat Phase:




That’s bad! Every Strategy Phase, you as the player should be reading the map and making decisions about how to manage threats to your party. Do you spend your mana now, or save up for a more powerful spell or combo next turn? Perhaps you shield a weak team member in range of two enemies, or perhaps you disarm the enemies. Maybe there’s nothing you can do except pray that those enemies attack a stronger ally in range instead. This phase is not random, and you are in complete control, but your resources are limited.

Every Combat Phase, you should be tracking how the battle is playing out. Were your prayers answered by RNG or did that weak team member get killed? Did a ranged team member kill the only enemy in range of one of your melee units, causing them to miss out on potential damage? The randomness of the Combat Phase combined with the smaller maps force you to take risks and play to your outs. If you’ve played Teamfight Tactics, you know how addicting it is to watch an AI team attempt to carry out your game plan.

My hope is that the interplay between the indirect player influence of autobattlers with the more direct influence of targeting abilities in a tactical RPG creates a compelling combat loop.

That's it for today! We hope to have another post up soon.

[Tangleworm]

This is looking really cool! The art is so charming, and the design of focusing on just the fun parts of a tactical battle is very cool. Looking forward to seeing this grow!

[robotbard]

The devlogs stopped, but development did not! Hari and I have been iterating on the idea of a roguelike with tactical RPG combat, and the game transformed significantly along the way. Team and ability drafting is still very much at the core of the game, but other core ideas have changed. With a much clearer direction, it’s time to restart the devlog.

You’ll see some incredible new art from Hari in this post, and he’ll be dropping by to share more work in progress soon.

The Combat System

This post will mostly focus on the combat system, almost all of which has changed. Here are some new screenshots of combat (unfortunately downscaled to fit the page size).

Lieutenant targeting the skill Rescue (higher res: https://imagedelivery.net/2UL_jcamevOG_DnxYVt9CA/3b582d9c-a97c-4a93-0487-8b1d4497f000/public):


Select and hover states in battle (higher res: https://imagedelivery.net/2UL_jcamevOG_DnxYVt9CA/3da7a286-64ad-4eef-79f0-48e279c65c00/public):


Originally, the idea was for combat to be split between the “strategy phase,” in which the player commands their team to use abilities, and the “combat phase,” in which enemies and allies both attack each other automatically. While there is certainly a game to be made with that idea, it had two problems:

• It conflicted with the varied active and passive ability mechanics we wanted to design. In the old system, a lot of player effort was spent attempting to play around the chaos of the next combat phase and its dozens of potential outcomes, even for the simplest of enemy designs. The result was more like solving a statistical puzzle than tactical combat.
  
• The combat phase was difficult to preview. Every unit on the board, including the player’s team, had X potential actions with Y potential targets. Some passive abilities triggered on events like attacking or taking damage, creating endless branches of potential results. Both potential and definite damage could be calculated based on the current map state, but those numbers became meaningless to the player due to their wide ranges.
  

There were several iterations of the combat phase to preserve these autobattler elements, but they were not particularly fun or strategic. The early iteration shown in the first post also included a shared mana system, in which player team members generated 1 of 3 different mana types to spend from a global pool. That idea was terrible and was scrapped.

Hari and I went back to the drawing board and created several combat systems before landing on this new direction. Combat is now designed to include many of the staples of the tactical RPG genre:

• The player has full control over their team’s actions.
• Units gain mana individually to spend on their skills.
• Units have a free basic movement action available every turn.
• Units can either use a free basic attack action, or one or more of their skills.
• Each unit has persistent stats in addition to their health, movement range, and attack range: Power determines the damage dealt by their attacks and is used to amplify some skills, and Mind is used to amplify most skills.
• All health, damage, etc. numbers were increased to make fractions and percentages meaningful.

Some mechanics are influenced by the roguelike deckbuilding genre:

• All skill and passive descriptions have rich text and are heavily tooltipped, referencing relevant mechanics.
• There are no individual team turns. The player controls their entire team in any order, then the entire enemy team takes their actions.
• Buffs and debuffs like Regen, Poison, and Thorns are persistent and stackable.
• The Shield buff acts the same as Block in Slay the Spire and similar games, expiring at the start of the turn. All temporary buffs do the same, like temporary stat or defensive boosts.
• Temporary debuffs all expire at the end of the turn.

You can see the new stats in the battle HUD here, along with a unit's passive description when hovering it (higher res: https://imagedelivery.net/2UL_jcamevOG_DnxYVt9CA/1c3b3bf2-a51f-42c3-66ab-2c360293f800/public):


One of the primary original goals of the combat system was to reduce garbage time and the minutiae of battle. My personal fear of busywork turned out to be mostly unfounded due to the small map sizes. Dead turns are extremely rare, if they ever occur at all. Still, we’ve designed the flow of battle to make executing your intentions as easy as possible:

• A unit’s basic attack is mutually exclusive with its skills each turn. Most turns, each unit does one thing before or after moving, but skill combos are possible if you save up mana.
• The buttons for selecting actions are overlaid directly on top of each unit on the map, making hover -> click interactions easy. You do not need to click a team member, move your mouse to another area of the screen, and click a button there. See this in action:

Ability Mechanics

Each player team member has a unique passive ability that interacts with the combat system in some way, giving them identity outside of their stats and skills.

Some examples:


Some are mechanically simple, like Executioner, and some require more planning to use effectively, like Spellblade, who swaps offensive buff values every time she uses a skill. Enemies have up to 2 passive abilities, which is a topic for another devlog.

Skills, or active abilities, are the primary reward of winning battles throughout a run. At the end of each fight, the player is presented with a draft offering a set of random new skills (higher res: https://imagedelivery.net/2UL_jcamevOG_DnxYVt9CA/d8e90e98-82c3-4f98-dec3-5ffd2a1b3b00/public):


The draft pool pulls from several skill sources:

• Unique skills available only to each character.
• Skills available to all characters within a faction (Haven, Tower, Cult)
• Skills available to all characters within a role (guardian, assassin, support, artillery).

All skills are currently weighted equally, but eventually skills will have a rarity value to influence how frequently they appear in the draft. Skill design space is the payoff for our change in direction, but despite more than 70 skills being in the game, we’ve got a lot more to create.

Text formatting uses current stat values to turn this base skill description…


..into this skill description in combat, based on the current stats of the actor:


Skills do not use minor percentage differences, like “x0.8 Mind” or “0.7x Mind”; we instead stick to the multipliers 1, 1.5, 2, and 3, plus easy fractions (½, ¼) where appropriate.

Skill descriptions in combat change dynamically to reflect the state of the game. Many skills trigger the actor to attack and show the damage dealt based on their current Power:


Skills that depend on targeting instead of stat values are previewed on the map but not within description text. For example, Gauntlet could command different enemies and allies to attack depending on the actor’s position and the enemy targeted:


You can see the Gauntlet previews changing based on the allies in range of the target:


An entire post could be dedicated to the art assets and code infrastructure required to format keywords, game data, and numbers into text using Godot’s RichTextLabel (which I have a love/hate relationship with), as well as the challenge of clearly and concisely explaining complex skill logic - Gauntlet probably still falls short of that goal.

We have much more to share about enemy design and AI, scenario design and generation, combat interactions, skill previews on the map, ongoing UI design efforts (this is difficult!), and the many iterations of stats we’ve gone through. Until next time!

[Tangleworm]

The art's looking great and cohesive! It's interesting to see how you approached tooltip text generation, especially for scaling values. Laying that foundation really saves a lot of time in creating unique skills.

[robotbard]

Thanks, Tangleworm! Text formatting is turning out to be much easier than deciding the phrasing for the skill descriptions themselves. That's been my final test for seeing if a skill is well-designed or too bloated.

Here are some other recent changes.

The opening character select screen has been filled with Hari’s gorgeous full-size portraits:

(full res: https://imagedelivery.net/2UL_jcamevOG_DnxYVt9CA/f07ea349-4ad3-4d7b-ef62-151158872700/public)


And the overlay when selecting a character has been fleshed out with their details. Some examples:


(full res: https://imagedelivery.net/2UL_jcamevOG_DnxYVt9CA/f17e64a1-a07d-4c9f-c1b1-a954b8427300/public)


(full res: https://imagedelivery.net/2UL_jcamevOG_DnxYVt9CA/e2714d4b-c708-4af3-28b5-869a3689c000/public)


(full res: https://imagedelivery.net/2UL_jcamevOG_DnxYVt9CA/e1ad1b26-3d1f-4aeb-60c5-9d0897292700/public)


We’ve also been experimenting with using targeting arrows to improve the clarity of skill targeting in battle, especially for two-step targeting and movement skills.

For example, here is Sorcerer targeting Chain Lightning, which bounces off the first target to deal damage to another:


And here is Priestess targeting Spirit Dance, which is a double-dash that grants Regen to her allies at each step:



It’s still rough, but it’s adding clarity in particular for enemy turns, making their range and target selections easier to understand as it happens.

We've got a lot on our checklist to be playtest-ready, but the flow of a run is coming together. We should have more to share of what happens between battles soon!