Day 3

Following yesterday's priority list, I added more monsters to the scene. Since the monster script was made with modularity in mind, it was simply copy pasting existing prefabs (the rats) and changing their icons and ATK and DEF values. While balancing, I ensured that the player gets a sense of progressive advancement—fighting easy enemies early on then allowing room to experiment with tougher enemies as they upgrade their ATK and DEF. For example, the crab enemies with low ATK but high DEF which requires multiple hits, or glass cannons like the ghost who die fast but punished the player more harshly.

I then modified combat so that killing blows don't damage the player to reduce the grindy requirement of having to recover health every once in a while (which would have meant I had to make a health recovery feature). To ensure a clean gameplay loop, I needed monsters to respawn so that the player could endlessly grind for money and upgrades. However, I had set strict design choices for myself in terms of zone sizes, and the curremy map was already getting increasingly crowded with the shop and monsters.

I needed to expand the map to fit all the planned features. I wanted to incorporate some themes within the zones, such as caves for spiders or beaches for the crabs. I started with the crabs as they were next in monster difficulty. While searching for assets, I found that the Tiny Battle pack that I was using primarily did not match a lot of the other packs as this was a more arena/gladiator style map with sand as a ground base. Luckily, the jam allowed for the editing of existing packs. I took the river assets from Tiny Battle and recoloured the grass to match the sand of Tiny Battle and got myself a usable shoreline asset that is compatible with the existing map.

Editing the tiles took longer than I expected, so I decided to ditch the different themed zones like the caves and dungeons to focus on mechanics instead lol.

Now that there were multiple zones, the camera had to move between zones to allow the player to be trackable at all times. The easy solution was to have the camera always centered with the player, but I wanted a Zelda-style camera system where the camera showed a fixed zone and perspective each time. While making the zones, I had multiple cameras to show how each zone would look visually while select ones were enabled. Initially, I considered a script that would toggle the camera based on location using colliders, but this would prevent the transition animations that I had in mind when travelling between zones. Instead, I used the existing cameras as position anchors, and made a script that moved the main camera to these anchors when the player enters a new zone.

However, I made a mistake when designing the map and measuring the camera zones, allowing the player to move off-screen as the transition zones and camera sizes don't match up perfectly. I fiddled with the camera, hoping I could mask the mistake by widening the perspective, but it made the map look weird instead. I tried to change the movement script so that it would try to force movement on the player to move into a visible area while transitioning, but that introduced more problems than solutions (at this point, the movement script still had several bugs), so I spent some time remodelling the entire map to match whatever was working at this point.

I decided this was the time to address the still broken movement script, especially the bug regarding the monster collisions. There were 2 major issues at the moment:

1. When the player holds down the movement input, the bumping effect is "suppressed" and could cause clipping
2. Each collision would slightly move the player off the grid, causing long-term misalignment with the map.

The latter is rectified by clamping the landing position of the player post-bump into something divisible by 0.5f, aligning with the grid coordinates. The former was trickier as the bumping logic used coroutines at the moment, which I had little experience using (and was basically pushed towards by a friend who said this was a use case for it). After several hours of debugging, experimenting, and googling, I gave up using coroutines entirely and decided to refactor the entire function using Lerp instead. No more issues afterwards.

The game now is nearly complete with its core gameplay loop, except for a way for endless grinding. I needed a method for players to continuously grind monsters for money, which meant either newly spawning monsters or respawning existing ones. I wanted to have rogue-like element to the game at first, but I was running out of time and had little experience with random-spawning mechanics and scriptable objects, so I decided on the respawning option. I made a MonsterManager script which kept track of every MonsterClass game object on game start and stored its data (position, starting values, HP) in a list. I then made a Fountain GameObject that reused the shop logic. Instead of giving the player upgrades, the Fountain will respawn all monsters and reset its values when interacted with.

With one hour remaining, I decided to settle for the current build and started publishing it on Itch. While Unity was building the project, I set up the Itch page, and hastily came up with a title which I think summarises the game well enough. I did not have screenshots and couldn't take more as Unity was compiling at the moment, so I opened Figma and used the assets to make a quick thumbnail. After compiling, I hurriedly uploaded it to Itch as a playable web game, only to realise the build broke.

This is why you set aside some time aside for last minute issues.

I checked the camera settings, readjusted them according to the web dimensions, and tried to build again. But seeing as compiling the project was faster than I expected, I decided to add a few features that would improve the game. I made a quick UI panel and a Sign GameObject that, when interacted with, toggled desired UI elements. I made one to explain how the fountain worked, and one bounty board to show all the monsters and their stats. Since it was heavily rushed, I wasn't aiming for anything pretty, but some explanation is better than none. I also reskinned the sign with a blacksmith-looking NPC for the shop to better communicate the different buffs and prices for the upgrades.

I wanted to display the text as a table, so I used Obsidian to make one since it supported markdown text, but it didn't translate very well into Unity.

I then added audio FX for the different available interactions, picked a BGM that I had lying around since I had no time to actually find them online (sorry Toby Fox, I hope you'll turn a blind eye for this). Implementing them was easy since the code was built around calling functions, so I just inserted the audio calls in between the regular triggers.

One more recompile, and the project is complete, with 5 minutes to spare.