What is this?
Expenditure is a Gwent-style card game where players must defend against an invading force using a limited number of troops. Each battle forces players to strategically spend their available troops, but any units used are permanently lost, adding a layer of resource management and risk-reward strategy to the gameplay.
I worked closely with Maile Sakamoto, who handled the visual design and art for the project, while I focused on game design and programming. We opted to use Godot 4.5 as our development engine because of my familiarity with it and its artist-friendly workflow. This decision allowed us to quickly iterate on mechanics and visuals while maintaining a smooth collaborative process between design and art.
Inspiration/Reference
Gwent from The Witcher 3 was the main inspiration for this project. From the very start, I knew I wanted to create a card game, and Gwent was the first game that came to mind.
The part that inspired me most about Gwent is its limited pool of cards available throughout a match. I loved how the game allows for strategic choices, such as deliberately losing a round to encourage the opponent to use more of their cards. This idea of balancing risk and resource management directly influenced the design of Expenditure, where every troop spent is lost permanently and every decision matters.
Gwent: The Witcher 3
When designing the space portion of the map, Galactic Conquest from Battlefront II served as a significant inspiration. I spent a lot of time playing it in the past, and its approach to space maps has always stuck with me. Whenever I think about space-themed levels in games, this is the first reference that comes to mind. Its design influenced both the layout and the visual presentation of the space section in my game.
Star Wars Battlefront II
Design
Physical Prototype
One of the interesting things about designing a card game is how easily parts of it can be tested in person. To figure out features and balance while also managing scope, we played a few prototype games using card sleeves.
These in-person playtests were invaluable for iterating on specific cards and identifying which mechanics or features did not work as intended. The main takeaway was learning the right number of unique cards needed to keep gameplay engaging. Having too few cards made the game feel repetitive, but including too many would have required too much additional art and production work, which was not feasible given the project scope at this stage. This process helped guide both design decisions and priorities for the digital version of the game.
Early Sketches
Following the playtests, we sketched out potential mechanics to better visualize how the game could play. These sketches were useful for breaking down other necessary elements, including how many lanes the player would need and how the galactic map could be structured.
One idea we discussed was a base system that would act as a form of lives. Each planet under defense or captured from the enemy would have bases that provide a defender’s buff. When a life is lost, the corresponding buff would disappear, adding strategic depth to planet management. Although this system was not implemented in this version of the game, I believe it has potential and could be revisited once the stellar map and space portion of the game are more fully developed. This mechanic would help create a stronger connection between resource management and strategic decision-making on the galactic scale.
Rules and Goals
Each player starts with 2 lives.
Losing a round results in the loss of one life.
The objective of each round is to accumulate the highest total point value on the board by the end of the round through strategic placement and timing of cards.
Game Loop:
At the start of the game, each player draws 10 cards.
Players alternate turns, playing cards until one chooses to pass or runs out of cards.
Hands are not replenished during the round, making every card choice meaningful. Players can employ tactics like playing low-value cards or deliberately losing a round to force the opponent to expend stronger cards, adding layers of strategy and decision-making to the game.
Unique Mechanics
The game features a total deck of 100 cards shared across matches. Each card that is played during a round is permanently removed from the deck, making resource management and strategic card use critical.
Players can explore and travel to different planets to gather resources, which can be used to build or improve their deck. This adds a layer of progression and encourages planning for future matches, as the deck evolves based on both card usage and resource collection.
Card Deck
The card deck is responsible for constructing the actual cards whenever they are drawn. When a card draw happens, the deck looks up the card’s information in the card database. This database is organized as an array of dictionaries, with each dictionary using the card name as a key and storing all of the card’s data.
The deck then goes through each value in that dictionary, building the full card from its stored attributes. Once the card has been constructed, it is added to the player’s hand. This setup keeps the card data centralized and makes it easy to update or expand the card pool without changing the underlying systems
Card Anatomy
The cards themselves are just empty templates. They start out with a base image, background, board, and generic text. Scripting wise, the cards hold empty variable that get filled when the card is generated. These variables hold information like its type, name, what card lane it is currently in, and its abilities.
Other Systems
Other noteworthy systems include the card manager, which handles detecting and handling when a card is interacted with. Interactions include hovering over a card and disabling input from the card after it has been played.
The battle manager is another significant system. It detects when the game is finished, the turn order, and the Enemy AI.
Card abilities are generated from a script that is loaded when the card is spawned.
Prototype 1
For prototype 1, we had a tight deadline to meet to show off our game, and part of that included having a trailer. The goal was to have a vertical slice ready to show off.
Board Layout
This prototype is a vertical slice of gameplay that was meant to be critiqued. This also meant a lot of semi-polished art was added to part of that.
When it came to the board, we knew we didn't have enough information displayed. The simplicity of the early board felt a lot clearer because the information was easier to process, but overall was boring to look at.
With the new art added, the board was immediately more interesting to look at, but it became hard to clearly know what card needed to be played where. In the end, this became more of an art test and was something to be changed in the future.
Card Tech
Another area of concern was card readability. The card gets bigger when hovered on, but there is not a lot of room on the board to allow for the highlights to be big enough in a visually aesthetic way.
We got feedback in this area. Looking back at how some other games do it, such as Gwent, they have a dedicated section on the board for big versions of the card to be displayed. This surprisingly saves more room on the board because you don't need to have more room on the board to highlight the card to be readable.
Trailer Improvements
When it came to the trailer, it was hard to visually show the game mechanics because we were so early in development. Also, card games inherently don't visually translate well in trailers unless you show lots of VFX.
This stage of development was too early for VFX, so I tried to compensate in the trailer with lots of cuts and prioritized card movement for visual interest.
With critique, the cuts were too much and it was agreed that this was a good start for a trailer but updating it would be required in the future.
Remember to Back Up!!!
The weekend before Prototype 2 was to be completed, my hard drive quit working. Of course I had everything I needed for the project on it and nowhere else. After taking it to a repair shop, here is the bill...
Luckily I had a back up that was about 90 percent complete, but learn from my mistakes. Back up your stuff!!!!
I did lose some things because of that but more on that later.
Prototype 2 (WIP)
Board Changes
The board had a major readability update. A large card now shows itself on the left side of the board. These help a great deal with readability, allowing the player to make proper decisions when playing cards.
Scores and health are now properly labeled. This is still an area that needs to be worked on, but what has been added is already a vast improvement.
Before
After
This prototype is more of a work in progress, with only minor changes after recovering from losing part of the project.
Data Loss
After recovering part of the project, there was one section that was completely lost and that was the ship section. I've decided that at this point it isn't worth rebuilding until more progress and polish is put into the card game itself. I felt that area was explored too early, and was going to be left on its own for a while anyway.
Final Thoughts and Improvements
This was an interesting challenge and I am pretty happen with the results. Programming in Godot reminds me how much I love Godot. It's just one of the programs that does what you tell it to do with no problem.
This was my first time making an electronic card game and I learned a lot. I am used to making action games and I had to change a lot about the way I think about game design and trailers when making this game.
There are some parts of the game I would like to refactor. Sometimes when working linearly you add features that are hard to expand upon, and I would like to improve those hopefully in the near future.