CardsGrid is a co-op tactics card game prototype that I’m developing solo. Much of its mechanical inspiration comes from D&D’s grid-based combat, but instead of spell slots and dice, players use cards. From a development perspective, I’m not an artist, so the prototype currently uses simple polygon shapes and text assets, allowing me to focus on game design and technical implementation.

Coop Specific Mechanics

The biggest challenge of this prototype is designing it as a co-op-first game. Since co-op card games are rare, I’ve had to get creative with problem-solving around UI and encouraging player coordination.

One example is the card reward system. In most modern deck builders, players receive card rewards only at the end of an encounter. In CardsGrid, however, players can earn card rewards during the encounter by working together with their co-op partner. The clip below shows that if both players damage an enemy unit before it dies, each player is rewarded with a card.

Code Structure

I’m using an observer pattern for the overall code structure, with the gameboard acting as the primary observer. This centralizes much of the information and coordination on the gameboard, allowing units and cards to remain lightweight and focused on their specific roles. As a result, they are more easily customizable.

Cards

Cards are composed of empty nodes saved as scenes, ready to be populated with metadata from a card resource.

The variables configured for cards are shown in the picture below.

Most of these variables are standard strings or integers, but the unique aspects of CardsGrid are the selection shapes and effect shapes. These shapes greatly define a card’s personality. Take the “Cone of Chilly” example below: the player can select a grid cell within the cardinal directions of their unit. Once a cell is selected within the selection shape, an effect shape is applied relative to that cell. This mechanic encourages players to position their units strategically to maximize effectiveness.

I also plan to allow card upgrades along different paths, further evolving their personalities and enabling diverse playstyles.

From an implementation perspective, I’ve already defined many selection and effect shapes, and it’s easy to add more since they’re represented as simple arrays of Vector2s.

Below are two more example of what the code looks like for shapes:

I have these shapes saved to an enum that can I select from in editor to make building a new card quick and easy.

Here are some ideas I have for other crazy shapes and additional mechanics I want to explore down the line.

Units

Units represent both players and AI. While they are complex under the hood featuring pathfinding and decks, I’ve kept encounter design simple by exposing variables that allow quick customization when designing new encounters. In the variables shown below, you can see how I can swap out a unit’s starting deck, turn order initiative, and visual appearance.

Decks are nested under units since every unit including AI-controlled ones plays cards. While the deck code is quite complex, handling all the visuals for the cards in a player’s hand, I’ve kept deck customization simple and quick from a design perspective. Similar to cards, decks load a resource that defines their starting cards. These deck resources are simply lists of card resources that can be adjusted via a dropdown menu or by drag-and-drop in the editor.

Pathfinding for the units is largely based on the A* search algorithm. Here is my commented code below if you are curious:

Why use Godot for my game engine?

Quick note on why I’m building this project in Godot: Godot is an awesome, lightweight, free, and open-source game engine that I enjoy using. Since I’m making a 2D game and don’t need something as powerful as Unreal Engine, I chose Godot to keep things simple and it’s been great so far. While I haven’t used Godot on large team projects, it’s extremely capable and user-friendly for small teams or solo developers, and I highly recommend it.

Work Tracking

Even though this is a solo indie project, that doesn’t mean I’m not tracking my work I do have several years of experience as a producer, after all! I haven’t created a formal timeline or overall schedule yet, as I’m currently focused on finding the fun and cutting what doesn’t work. For now, I’m using a simple Kanban-style board to track what I’m working on and what’s next. Once I shift to primarily building out content, I’ll set up a proper roadmap, but so far, this approach has been effective in helping me accomplish tasks each day.