Hey everyone! Hope you've been enjoying the update!

Though I've been mostly spending the last few weeks fixing all the bugs after the release, I have begun work on a pretty significant refurbishing of the game's code behind the scenes.

It's all mostly technical stuff related to the way the battle engine is built, so I figured I would make this month's development log a bit of a deep dive on the technical side!

The What

So what exactly am I working on? I've been poking at the code that does all of the effects when you play a card or a Status activates - things like add Wgt, Fit, Energy, draw cards, etc. In a way, it's pretty much the entire logic of the battle engine.

I haven't made any funky technical charts at all ever since I finished my programming degree, so here's an excuse for me to make one to explain how the game works:

One of the main objects in the game is the BattleParticipant - that's you and the opponent. This object contains all of the info related to a given person in a battle: Wgt, Fit, Energy, cards in the Deck, GY, Hand and so on. BattleParticipant has "methods" - code that can be called to alter those stats (that's the "changeWgt/Fit() "and "drawCards()" in the chart)

When you play a card, pretty much all the card code does is grab the BattleParticipant and call the appropriate method on it to tell it what to do with its stats. All of the actual magic happens inside the BattleParticipant. So when I want to code a new card into the game, it's largely just finding the appropriate method and calling it in the BattleParticipant.

The Why

The old approach I described above is pretty intuitive and straightforward, and it certainly made sense back when I first made what was only supposed to be a simple game with cards that have straightforward effects that activate right away.

The problem with that is: what about cards with fancier effects that need more input? For example, you may have noticed the game doesn't really have any "interactive card effects" such as "Look through your Deck and select a card to add to your Hand" or "Pick between these two things". This isn't really possible with this system where a card can only do its thing, and then immediately return control to the player to play more cards.(The new "Peek" card, though, is one such effect that is already in the game!)

Or what about effects that could really use an animation or a fancy visual instead of just randomly resolving itself? The new "Hand Roulette" card which randomly picks a card in your hand and copies its effect could use something like this for example - an animation where it shows you the card it picked before actually activating it.

Hand Roulette isn't the only card that would benefit from a proper animation of its effect. "Spring Cleaning", which has been in the game since the beginning and discards cards from your GY could use it too, and many others do as well.

As an aside, those aren't the only animations that needed to be worked on: part of this update will also be the addition of miscellaneous animations to the cards in hand.

For a long time now, one big thing that's been sticking out in this game like a sore thumb compared to other games is the lack of small UI animations during the card gameplay.

You play a card? It just instantly cuts to the new hand you have, no animation whatsoever - this is especially jarring when you draw new cards, sometimes it can even make it hard to tell what you actually drew.

It took me a while to get around to this, because I hadn't touched the hand UI code in a while, and back when I first wrote it, I wasn't experienced enough to know how or where to plug in the animation code. Glad to have that out of the way now...

There was one upside to the old wonkiness though: the lack of animations makes the current game feel very fast-paced: you don't have to wait for the game to finish a fancy animation or transition and whatnot. This is a personal gripe I have with some games - long or ostentatious animations can make things feel sluggish and unresponsive sometimes.

Considering that, I'm sure there will be some people who will find the animations intrusive or annoying compared to what they are used to now, so I'll be sure to add an option in the settings that lets people disable these new animations.

The Biggest Problem

Not being flexible enough to add animations is one thing, but another problem came when I added Statuses.

Statuses added a massive new layer of complexity to the game: they can do almost anything, really. Under the hood, there are three main "types of action" a Status can do:

Alter numbers of an effect (e.g. increase all Wgt inflicted by +1).

This one's pretty simple. All I had to do was add an extra step to effects, where the BattleParticipant checks for Statuses that want to alter the numbers and lets them do it before actually going through with it.

Miscellaneous effects that alter game logic (e.g. do not allow refill)

This one requires a bit more bespoke code: an extra check inside BattleParticipant that tries to see if there are any Statuses that "block refill", and if yes, then it overrides the regular behavior.

React to effects or events and cause a new effect of its own (e.g. "At the start of turn do X", "Do Y every time you draw a card")

A vast majority of Statuses use the last one - and it is also the most complicated from an implementation standpoint. How does it currently work in the game code?

Similar to the Alter Numbers code, I added an extra line to every effect and event that checks if any Status wants to activate itself. However, this time, instead of only altering some number, a Status can start up an entirely new effect on its own.

The problem is... what if it gets stuck in an infinite loop? For example, if you have two effects: one that draws a card every time you gain Wgt, and a second that makes you gain Wgt every time you draw a card? They would just activate one another a bunch of times!

This isn't just a technical issue - it's a gameplay problem too. Infinitely activating statuses or buffs don't exactly sound like a balanced mechanic.

The Solution

The fix is pretty clear - just make each status only activatable once per "chain reaction". That means to make a queue of sorts that the effects can add themselves to, and then just have the game go through the queue and activate them one by one.

The word "chain" is pretty accurate here - other card games use something like this too (both paper and digital), sometimes they also call them chains, or you may be familiar with the term stack.

Ok, so that's what we need: some kind of "chain system". The problem is... it's not possible with the current structure of the code: the cards are just telling the BattleParticipant what to do and then it immediately does it. To change that would mean to spend time building a whole somewhat-abstract thingamajig to start using instead.

How does the game handle it currently, then?

The Mess

So... back when I had to implement the Status system with what I had, I ended up just taking the completely garbage route but one that took the least extra work: all reactive Statuses have a "did I already activate myself?" flag that they flip to ON when they activate.

This flag has to be reset to OFF at every spot where a new chain reaction can start - so I just identified those and sprinkled them around manually: when playing a card, when someone's turn starts, and when someone's turn ends.

... yeah, it's not great.

The conclusion...

Which brings us to today, where I'm finally caving in and implementing a proper "effect chaining system".

It does make the code a bit less intuitive to read... I'll certainly miss the old, much simpler way of doing things. These fancy "abstractizations" usually make code much more flexible and powerful, but also much harder to understand at a first glance. But in a way, it also makes me feel pretty cool seeing the game reach a point where it benefits from these kinds of "advanced" techniques.

It's not as if I've only started building it up from the ground now though: like I mentioned earlier, the "Peek" card had to have something similar to this system to be possible. The much older "Rampage" card too:

In fact, this card is what forced me to make a barebones implementation of what eventually became the base of the chaining system I'm working on today.

So what's the takeaway from all this?

Well, for one thing, you can expect to see more animated and responsive card activation effects in the future!

And as for the message to be gained from the behind-the-scenes stuff? Never half-ass things. Read up on the best practices on code architecture. Always put in the time and work to think things through perfectly before actually doing them.

Nah, just kidding.

Messy tacked on code is what ships games, not some nerd spending months trying to figure out what the "most correct and best" way to do it is without even sitting down and typing out a single letter. I certainly would never have started working on the game if I went into it thinking I need to do everything perfectly.

Besides, you can't learn if you never try it at all.

Well then

Ended on a bit of a personal note there, but I hope you enjoyed it nonetheless! As always, thank you for reading and for supporting the project!