“CardsGrid” is a coop tactics card game prototype that I am solo-developing. Much of the mechanical inspiration comes from D&D grid-based combat but instead of spell slots and dice players have cards. Development wise… I’m not an artist so for now, the assets for this prototype are a bunch of polygons and texts which allows me to focus on the game design and the technical implementation.

Coop Specific Mechanics

The big challenge of this prototype is that I want it to be a coop-first-designed game. Coop card games are few and far between so I’ve had to get creative with my problem-solving for things like UI and reasons for the players to coordinate with each other.

One example is card rewards. Normally in modern deck builders players get card rewards at the end of the encounter but in CardsGrid players have the opportunity to get card rewards during the encounter if they work together with their coop partner. The clip below shows that if both players have hit an enemy unit before it dies then both players get a card rewarded to them.

Code Structure

I’m using an observer pattern for the overall code structure with my gameboard being my overall observer. This puts a lot of the information holding and connecting dots on the gameboard but it allows for things like my units and cards to be much more lightweight and focused on their purposes which also means they are more easily customizable.

Cards

Cards themselves are a collection of empty nodes saved as a scene waiting to be filled with meta data from a card resource.

The variables set up for cards are as shown in this picture below.

Most of this is standard strings or integers but the unique parts of CardsGrid are the selection shapes and effect shapes. Select shapes and effect shapes hugely determine the personality of a card in CardsGrid. Take this “Cone of Chilly” example below. The player is able to select a grid cell within the cardinal directions of their player unit. Once the player selects a cell within the select shape to use the ability on an effect shape is applied relative to the selected cell. Tactically this gives play reason to position your units that maximize your effectiveness.

I also have plans for allowing the upgrading of cards down different paths further changing their personalities and allowing for different playstyles.

Implementation-wise, I already have many selection and effect shapes defined and can easily add more because I made them 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 the players and the AI. They are quite complicated with pathfinding and decks but encounter design-wise I’ve again tried to keep it simple on myself and expose variables to customize units quickly when designing out a new encounter. In the exposed variables below you can see that I can swap out what decks units start, their turn order initiative, or their visual appearance.

Decks are nested under units since every unit (even the AI) is playing cards. The decks are quite complicated code-wise as all the visuals for the cards in a players hard are determined here. Design-wise I kept customizing decks simple and quick. Similar to how the cards are set up decks can load a resource letting them now what starting cards they use. These deck resources are simply a list of card resources that I can adjust in a drop down menu or 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. I knew I would be making a 2D game and I didn’t need anything as powerful as Unreal Engine so I decided to stick with Godot to keep things simple and it’s been great. I haven’t used Godot for any large team projects but for a small team or solo projects it’s extremely capable and easy to use, and I highly recommend it.

Work Tracking

While 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 set up a timeline or overall schedule for the project yet as I am focusing on finding the fun right now and scrapping things that aren’t fun. I do have a simple kanban-like board where I am keeping track of what I’m doing and what I plan to do next. At some point when I find myself in a position where I mainly focused on building out content I’ll set up a proper roadmap but for now, this has been effective enough at keeping me accomplishing tasks each day.