After havin much fun with the GMTK Game Jam a few weeks ago I decided participate in another Game Jam. Looking at itch.io I found that the Brackeys Game Jam 2025.2 was popular and starting soon.

The Theme - Risk It for the Biscuit

This Jam’s theme was Risk It for the Biscuit. The theme was announced in the late evening in my timezone, so I thought of a game whilst lying in bed. The first idea I had was to implement the game Risk but my mind drifted to the games Oh Dear and Euchre and how I could put my own unique spin on it.

For those unaware Oh Dear is similar to Oh hell.

A Voronoi Adventure

I ventured first to see the feasibility of the Risk idea. I read a Reddit post where someone was using a Voronoi diagram for their strategy game. I found a shader that generated the diagrams quite easily. However after looking into using generating textures to pass in the coordinates into the shader I decided that my other idea might be easier.

“Researching” Trick Taking Card Games

Of course I needed to do some research into trick-taking games, I only knew of 500, Oh Dear and Euchre. After spending a few hours deep diving into Wikipedia I realised that I had spent several hours now and had no real progress to speak of.

Making the Game

I used Godot yet again as it is what I’m most familiar with.

Basic Idea of the Game

So the game is a rouge-like bidding trick-taking game where as you progress you gain triumph powers that either give more points or help you form a better hand. The trick-taking side of things comes from Euchre, so there is a trump suit decided by the turned up card and bowers. I simplified the bidding system of 500, you only bid once and not of the suit. The winning bid is awarded the turned up card rather than a kitty. Taking from Oh Dear I wanted to ensure at least one player failed to meet their bid. To fit the theme I decided on no extra points for tricks taken so you are incentivised to bid higher and risk more score.

Shader

Many Fold Time Attack suffered for lack of aesthetics. Without even a working game I delved into chucking a bunch of shaders together to give a properly mosscore look. The vignette, grain and fog on a dark green background quite tickles my aesthetic instinct. Mixed with SCP-x5x (Outer Thoughts) it comes to a nice and sombre feeling.

Godot Resources are Great

In Jonas Tyroller’s video he doesn’t say it explicitly but explains that the MVC architecture is good for game development. Godot resources can be used quite easily to form the Model portion of this architecture. The levels, decks and triumphs are all defined using resources and the parameters can be easily edited in the Godot editor.

Now I saw this video after I had already started so my View and Controller are mushed together in a mess.

Making the Core Game

This went pretty straight forward, wrote a bunch of bugs and the trick-taking mechanism. Then fixed those bugs, usual software stuff.

I found it annoying that I had to constantly re-parent the cards as they moved between the different areas as needed for the game. I ended up having the same information twice, one in an array in the script and the other in the node graph. The node graph is difficult to iterate through in a script, but nodes need to be in it to be displayed. This might be mitigated somewhat if I had properly separated out the view from the control in my architecture.

I also originally made the resource attribute public, this lead to a lot of code to manage the left bower. After properly encapsulating the resource attribute and putting getters and setters around everything, even how trivial 99% of them were, I was able to easily query the suit of the left bower and get the correct answer. This eliminated a few vexing bugs.

Triumphs

Whilst making the game I had a notepad where I jotted down some ideas for triumphs. These either gave you points or enabled you to modify your hand. I used the visitor pattern, each triumph would have a resource that described it, then that resource would be composed of other resources that derived from TriumphAction that would be passed the game-state to modify in some way. These actions were visited when a player selected the triumph to be used. This enabled me to be able to add and test a triumph in around 15 minutes.

It annoyed my that I was never 100% sure when writing to the game-state object if I was modifying the original or only overwriting my local reference. I really don’t like languages that try to hide value vs reference from the programmer. Makes me want to go back to c++ with my trusty std::shared_ptr<T> - or even just const T&.

Level Design

Trying my best to have good software engineering practices from the beginning enabled me to have variance between levels without spending much extra time.

I originally had about half the levels with a score-par but this proved to be annoying as you could still win the match but get game-over. The only level with a score-par now is the first, and it is trivial to attain.

Tutorial

After watching some youtube one evening of people explaining pitfalls of game design I realised that my “How to Play” page was wholly insufficient. Other people haven’t grown up playing trick-taking games, strange I know, so they wouldn’t already intuit how to play. I was afraid that I’d have to implement some complex system of tutorials, I have never created one before so it was extra daunting. Never the less, the game needed one. I’m happy with the system I designed, there are points in the main state-machine of the game where tutorials can be injected. There is a tutorial manager with a list of tutorials and if an injection point the tutorial’s type matches the point’s it will be displayed. There are two kinds of tutorials, one where the player has to manually dismiss it before proceeding and one that will disappear when the player takes an action. This works quite well as the state machine of the game is limited and strict. I’ve allowed the player to take any legal action, but the tutorial explains how to make the best one - so if the player wants to be successful they need to read.

Problems With Godot

Godot is really good, you should probably use it but I am having doubts if it’s correct for me. I also experienced instability during development. This lead me to ditch the use of @tool scripts - which is unfortunate.

There is also a bug in version 4.4.1 where if you have auto playing music on the web build it will crash when played on Firefox.

Thoughts

Overall I’m quite happy with the result. I’ve had lots of fun creating it, solidifying lots of previous learning along the way and learning a few new things too. I put the game on my phone and find myself playing it here and there - even if the buttons are a bit small.

The Game

You can find it on itch.io: