I was ambitious in my goals last week, but it’s paid off. I’ve got a preliminary title screen, scenario selection, and a whole lot more under the hood.

I started by moving away from JSON Schema. Sounded good on paper, but I found myself in an anti-pattern, fighting the Godot way of doing things. I have now formally structured into classes (which I had before) and Godot-managed resources (instead of dynamically creating them at runtime).

I made some solid progress towards adding more content this week, providing a scaleable foundation.

• Added a new device and card combo with a new mechanic (evade)
• A global persistent player now exists, along with an abstracted file-based configuration
• The engine now supports multiple opponents with a dynamic layout and repositioning
• Added deck counters such as draw, discard, and spent
• Added hover hints to improve ease of use and improved internal naming for debugging
• Controller Focus is much more complete and user friendly, including sticky targeting
• Intents are smaller, more accurate (off by one), and have a shader effect
• Mouse controls are cleaner on the backend and less buggy
• Implemented a JSON schema for all my data types, facilitating adding more content
• GUT was broken in CI, which I didn’t notice because it was failing silently
• Removed some clutter and old prototypes from the codebase (they’re still in Git)

Sticky targeting is important to me from a usability perspective; I want the game to be smart about minimizing the amount of effort the player needs to put into performing actions. For example, if there are two opponents, you aim at the second and attack, then defend yourself, then go back to attack, assume they still want to attack the second opponent. Same goes for using cards; don’t default to the first card, default to the nearest card of the same type, else the closest card. This is supposed to be a strategy card game, not a clicker.

Mouse interactions are staying; I’ve been focused on adding natural controller navigation. There’s a lot of controller interactions that we take for granted that when implemented cleanly just feels natural, but that hides a bit of a mountain of helpful logic. I’ve been thinking about it this way; the player wants to know what card they’re looking at, which card is selected, and what target that card is going to. Practically, hover the card they chose, highlight when selected, then choose a target. It’s also valid to want to choose actions elsewhere on the screen, like configuring a game mechanic or opening a menu. Godot has some built in helpers for knowing which button is closest… but not everything is a button.

I’m making some solid progress on my new game now, and I find myself getting distracted as I start tweaking the content. This is a good thing; it means that I’m getting a lot closer to a vertical slice that I can put in front of people and ask for their opinions. Some major changes from last week:

I’m incredibly excited about what I did in the past week; I now have a working frontend for the core card battler mechanic! Previously, I had modeled an entire conflict from start to finish, including several mechanics and end states, but it was running in isolation and practically executable only as unit tests. A picture is worth a thousand words, and boy were those logs verbose. There were several challenges in connecting the frontend.