The Alchemist’s Handbook

Fight enemy after enemy by combining your attacks and exploit their elemental weaknesses. Grow your arsenal of attacks and upgrade them to brave the toughest challenges!

The Alchemist's Handbook is my fourth game jam game and as always, it was held in the wonderful city of Hanover at the SAE institute! This time, my friend Theia joined again and I collaborated with some teammates from previous game jams:

Hai Lam from the previous year joined again with her superb artistic skills, and Luke helped out once more with his Unity knowledge. Another artist who goes by Koa'Rynn was also part of the team, so we could deliver greater artistic output than usual.

Jonas wanted to chime in with some music as usual, but he actually injured his hand on the first day of the game jam and couldn't really participate. So while he technically was part of the team, this time around the game had no music or sound effects, as we didn't want to resort to downloaded assets.

Together, we managed to create a pretty fun game, even if the balancing is a little off and it's very hard to even reach the final stage - I actually feel bad for Hai Lam because her wonderful dragon illustration will only ever rarely be seen!

Idea

This time around, the topic was "Curiosity". There were a few teams who based their submissions around cats (as in "curiosity killed the cat"), and two featured the Mars rover Curiosity. However, I wanted to base a game around the concept of discovery.

I also wanted to make a game with an RPG battle system, so we decided to make a Darkest Dungeon-style game where you fight enemy after enemy using attacks that take the form of cards.

There are multiple ways in which the curiosity theme is present in The Alchemist's Handbook:

• Figuring out the enemies' weaknesses and jotting them down in the eponymous handbook
• Exploring the different combo attacks and their effect on combat
• And finally, the narrative aspect of the alchemist driven by their own curiosity exploring deeper and deeper in the dungeon, ever curious which monsters they might encounter next

Combat

I'm actually quite proud of the combat system, but it only allows for one enemy to be present simultaneously. Otherwise, I would have to implement a system for the player to select a specific enemy to attack, and I felt this would make the game more complex than it needs to be.

Accordingly, the game is split into four stages with their associated enemies:

Goblin -> Skeleton -> Elemental Mage -> Elemental Dragon

The player has to defeat each enemy before moving on to the next stage. This means that

Elemental Attacks

There are six damage types available in the game: The physical Slash, Stab and Bash, and the elemental Fire, Ice and Electricity (Volt). You might recognise these from earlier Atlus games such as Persona 3 or especially the Etrian Odyssey series, which I was directly inspired by.

Each damage type has an attack card associated with it: Sword for Slash, Lance for Stab, Hammer for Bash and Elemental orbs for the elemental attacks. At the start of every playthrough, you are assigned three of these cards at random, with which you will have to fight the first enemy. After you defeat an enemy, you are presented with a choice of three more random cards, out of which you can pick one. If you don't have that card yet, it is added to your arsenal to expand your damage type options, but if you already have the attack for that type, it is upgraded to deal more damage instead! This allows for different styles of play: Either you try to get as many damage types as possible to be able to exploit any weaknesses the enemy might have, or you specialize into one damage type and upgrade that attack as much as possible to overpower enemies regardless of their weaknesses - as long as the enemy is not immune to your favored damage type!

However, because such a simple system will get boring quickly, we decided that you don't attack with a single attack card, but rather a combination of two cards. This adds the ability to perform special combo attacks: First freezing the enemy with an Ice attack and then bashing the frozen enemy with your hammer deals more damage than performing both individually. Try to find all six combo attacks!

Finally, to distinguish the three elemental attacks, we decided on the last day to implement some basic status effects: Fire attacks might burn the enemy, dropping their attack power. Ice attacks could freeze them, making them more vulnerable. And Volt attacks might paralyze the enemy, for a chance to skip their turn in combat. Realistically, this was probably too ambitious for such a short time, and the status effects are quite buggy...

Accessibility

One clear trend I've noticed after creating four games is that I focused more and more on making them easy to access.

Flower Defense was a downloadable .exe for Windows and could only be played with a controller. While this allows for fun controls with the sticks, it also means that there's quite a bit of setup involved in getting the game to run. You need to download the game, install it on your PC, get a controller, probably charge the controller or find a cable, and then hope that it plays nicely with your system. Hardly any of my friends that I showed the game to wanted to go through this lengthy process so not many people played the game.

With Murder at the Great Exhibition and Daydreamer, I opted for a web version of the game - after all more and more people have Mac devices and I'm not about to pay $99 every year for a Mac developer license which allows me to build Mac executables. Plus, having the game playable in the browser removes one more hurdle in that players don't need to download and install the game anymore. However, both games were controlled via keyboard input, meaning that they're impossible to play on mobile - unfortunate considering that everyone pretty much always has their phone with them, but not many people carry their laptops around 24/7.

For The Alchemist's Handbook, I decided that the game should be controlled purely through mouse interactions, meaning that it can finally be played on mobile platforms as well. This is because screen taps are considered clicks by Unity - perfect for a game jam game where you can't really afford to spend even an hour or two setting up separate controls for mobile.

Lessons Learned

This game jam taught me quite a bit about game development - more than the previous ones.

One thing is how to implement decorative animations, such as the attack animations in this game. During the first night, I implemented the basic combat system using an event-driven combat "engine": The game waits for the player to make their choice, calculates the damage dealt, checks if the enemy is defeated, calls a function that determines the enemy's attack, calculates damage to the player, checks for game over, and then prompts the player for their input again. If you simulate player input using a function that picks an attack at random, it's possible to resolve hundreds of rounds of combat in a single second, since it's all done using direct function calls without wait times in between. On the second day, we had to add animations to all parts of this combat simulation. This poses a whole new set of challenges:

Some attack animations should be longer than others, so it's impossible to just set the animation time to a specific amount of milliseconds. Because of the combat system, it's also impossible to simply pick an animation based on the chosen damage type, since different combinations of cards require different animations - and if there is no combo available for the chosen cards it should just play the two normal attack animations sequentially.

Hai Lam introduced me to the wonderful DOTween plugin, which can be used to create simple animations for interpolating between different values. I used this extensively in the UI animations, but in the short time we had, I just focused on the UI animations while Luke did the attack animations.

He used a different approach, in which he hard-coded the character movements and associated animation frames to specific animations, which he then associated with the possible card attacks. However, we especially had problems with the elemental attacks: The animation consists of shooting a Fire-/ Ice-/ Electricity-Ball at the enemy and this was implemented as an actual moving object in 3D space originating from the player's position and moving towards the enemy. The problem was that the end of the animation was determined using an actual collider object on the enemy's sprite that detected the ball. If some part of the animation glitched, either by the player or enemy not being in the correct space when starting the animation, a previous animation not finishing correctly, or the player's device being too weak and skipping frames, the ball could miss the enemy completely! This meant that the animation would never finish and the game effectively soft-locked.

Fixing animation problems such as these took up a significant part of our time on Saturday and precious hours on Sunday close to the deadline of the game jam. In a game jam, the short time frame means that you can't develop perfectly robust systems and often don't have time to refactor anything you have built. But your code quality should reach a sweet spot where it's just barely good enough to last until the third day before the code starts falling apart - and with this animation system, we had trouble after less than one day.

For next time, I know to spend more time setting up robust systems before diving into creating the actual animations. I'm thinking of creating an asynchronous messaging system where every step of the combat engine creates an animation object that plays animations until finally calling an "animationFinished" method, continuing to the next step of the animation engine. And as a backup to protect against soft-locks, there should be a timer that automatically finishes an animation and returns the player and enemy to their designated spots after a few seconds have passed without the animation finishing naturally.

Finally, I was also sad that we spent so little time optimizing the game difficulty that even with perfect play you are unlikely to even reach the later enemies unless the random card drops were in your favor. This meant that hours of Hai Lam's hard work on the enemy sprites was essentially wasted effort because hardly anyone would reach the mage and dragon stages. A shame, considering her talent for 2D art! Next time, I want to make the earlier stages easier, ensuring that the player reaches the last stage almost every time, and ramp up the difficulty on the final fight. This ensures that the player gets to experience every part of content in the game!

Final Thoughts

While we didn't really hit the theme of curiosity all that well, I'm still quite happy with how the game turned out!

The combat system was especially fun to program, and using DOTween for UI animations was a blast!

This will probably be my last game jam for a while, and I hope you have fun playing it!