Game-A-Week 3: Basic Turn Based Combat Game

The Game

From October 24th 2023 to October 28th 2023, I worked on a simple game for my one week challenge that is meant as a learning exercise for learning how to code turn-based combat, which is new to me. This game can be played on itch.io. I chose to do a turn-based game rather than an idle game as the scope is smaller, while still allowing me to get more comfortable scripting menu-based gameplay.

Through it, I got more comfortable with the concepts of balancing gameplay for it, as well as the different coding challenges presented with interacting with a menu UI for a gameplay that plays in a sequence rather than real-time reaction.

I have also since found an online community that was dedicated on the goal of making games in a one week deadline, which supported my Game A Week challenge. A community like this is a good outlet to share my work and get some appropriate feedback, as well as play other people’s games that were also made in only a week. It suits me well as I otherwise do not like to use much social media.

What Went Well?

Scoped down to fit meet the learning goal of getting comfortable with just turn based combat

I originally had ideas for implementing dungeon crawling and shop screens with inventory management, but I chose to scope down so that I can be comfortable with just turn-based combat first.
I knew I could expand upon the core concept and implement dungeon crawling and inventory systems in a future week instead. This worked out good and allowed the game to be finished on time.

I was able to integrate the RexUI Plugin, reading docs and examples, in a usable way, after understanding the pure basic of a UI button system

I was able to understand the documentation for Phaser’s RexUI Plugin here and use it for my prototyping.
I originally experimented with using my own button system but I noticed that to do layout and margin system so child entities like text and the button graphic would scale and be positioned correctly itself can be a full project.
So I chose to use a suitable and popular open source plugin library to handle that so I can focus on just turn-based combat

Serialized enemy data at startup and decent balance

On the last few hours before publishing, I was able to modify the enemy data from a json file and add changes to the combat system and stats to make the game more balanced.

I did all turn-based logic myself without looking up a tutorial or example

This is good for a first attempt because it allowed me to practice my problem solving skills coding a new system for the first time, by breaking down what a turn-based combat system needed into its steps.
Being able to do something complete new to me like this without needing a step-by-step guide shows my growing maturity and independence in my programming abilities, and is a good boost of confidence
Of course, once I rewrite my systems and have something working and polished, it can be worthwhile to study other examples out there to see potential room for improvement.
Studying other people’s code for a similar system only after attempting it myself, however, allows me to have a deeper understanding of the topic that would allow me to make better judgements over what approaches work for the project I am working on, as I can see whether the differences in my own instinct to solve the problems might be better than the common standards.

What Could Have Been Better?

Code structure was really messy when prototyping, making it bug prone and hard to modify

Some mistakes include having the enemy slot in the combat screen and the enemy themselves be the same data, making it hard to swap in different enemies when resetting the encounter screen or having bugs with the cursor of the currently selected enemy.
This made it difficult to load in different enemy types per encounter as I was not confident in being able to debug it without writing additional tests and refactoring my code.
I think this problem is also acceptable as it was my very first time doing turn based combat, so having something that works to this state is already pretty good, since the code is still in a relatively readable and easy to modify state that I can still rewrite and refactor it to be less brittle.

Should use an event system to manage chain of commands in relation to the text box

I neglected to use event systems to emit events during certain commands, such as taking damage or attacking an enemy.
This meant that it was easy to make mistakes and bugs when chaining together the sequence of function calls and setter/getter functions for data, especially without proper encapsulation. This can lead to bugs such as enemies taking damage but not having their health bar being updated properly.
An event system with proper encapsulation can allow multiple sources of damage to be forced to still go through the same procedure in the same order, and having a centralized place in the code to handle scripting for stuff like, changing of enemy sprites or taking damage. This avoids bugs where one piece of code might accidentally subtract damage directly from the health, while the correct code is supposed to go through a sequence.
It also would allow bugs involving the synchronization of game state with the crawling text box on the top to be easier to debug and avoid.

What have we learned that we can apply moving forward?

We can do another turn-based combat prototype with what we have learned, keeping in mind creating an event manager

With what I have learned, it would be wise to experiment with rewriting a bit of this code in a separate project with support for multiple enemy types, alliances and even having multiple player characters.
Choosing to do this after there is a playable build of the current approach is wise as now I have something concrete to replicate and iterate upon in the new code too. It was wise to still finish a fully playable gameplay loop with the current code, instead of abandoning it, before attempting a rewrite

Implement debugging and prototyping tools that allow customizing encounters and stats at runtime, with hot reloading and hot saving

One tool that would have been very helpful is being able to create enemy encounters, modify their stats, and modify the player’s stats on the fly during runtime in order to better experiment with the balance of the game.
This can be done in JavaScript with gui libraries like the old dat.gui or newer ones like Tweakpane or lil-gui

Get comfortable with loading data at runtime rather than at the start

This is more of a web development thing, but I need to also be able to load data dynamically when needed or in the background to not only reduce loading times when the number of assets required increases, but also to allow dynamically editing and saving assets at runtime (such as in the case of modifying stats of objects during playtesting). There are some example posts on how to do it in Phaser using lazy-loading.

Add polish and sound effects

When revisiting turn-based combat and improving on it, once we get more organized code, implementing sound effects and animations that fit the enemy type is a good next step.