solanum

solanum is a card battler turn-based RPG made in unity initially in the span of five weeks, with an additional three weeks dedicated to UI/UX, in collaboration with iwo kmiecik, kisa rodriguez, and tea maxwell. i was responsible for designing the gameplay of the combat segments and programming for the entire game, with a particular focus on combat and enemy AI. i also was responsible for implementing ink and building out the narrative system, as solanum bounces between visual novel-style narrative segments and turn-based card battler combat, as well as designing ux wireframes and designing and implementing UI/UX-related interaction design. the player's deck is determined by which of the four classes they choose at the beginning of combat. each deck has its own strengths, weaknesses, and stat layout. solanum also features a type system, which is split into attacks (physical and magical, further divided into striking and slicing for physical attacks, and fire, water, earth, and wind for magic attacks), healing, and special cards. the player's deck has 20 cards total, with a 5-card hand that repopulates at the end of their turn. both the player and enemy have a limited amount of AP (capped at 5) which determines how many cards they can play in a given turn, as each card has an AP cost, and the player/enemy's AP cannot go below zero.

solanum features two boss fights (king aurelio and knight camilla) depending on which ending the player chooses at the end of the narrative segment. king aurelio's deck is more magic-oriented, whereas knight camilla's deck is more physical-oriented. subsequently, king aurelio falls more into the glass canon archetype, whereas knight camilla is more of a traditional tank, making certain classes more effective against each boss. i programmed an enemy AI that could have a deck and stat layout plugged into it that would therefore work for any given enemy as long as there was an existing deck and stat layout for it, which took the form of scriptable objects. the enemy AI's hand populates in the same manner as the player's, and it determines which card to play based on its HP (prioritizing healing cards if its HP is low), current AP, and base damage or healing value of the cards.

postmortem

we overall felt very satisfied with solanum as a game. solanum was my first go at programming a combat system or enemy AI, so building out the combat system to the extent that it exists in-game was a fairly large accomplishment, especially given the class system. our largest point of dissatisfaction with the combat system was the prevalence of a few outstanding bugs that we were not able to fix before the project deadline, namely some issues with enemy AP usage where the enemy will occasionally play every card in its hand despite the obvious AP limitations. additionally, the usage of a visual novel format to convey narrative was largely implemented in response to the short development timeframe; with a longer development timeframe, we would have preferred to have an overworld with interactible characters placed throughout and cutscenes in its place.

iwo and i also continued to develop solanum as the final for our game UI class (hence the additional three weeks spent dedicated to UI/UX). this allowed us to put considerably more time into developing a more polished UI for the game than we'd had for any other project. i handled wireframing and the majority of the implementation of UI/UX into unity, whereas iwo was responsible for UI art and additional programming assistance on the implementation of certain motion design elements on the main menu. this also entailed extensive usage of dotween pro for motion design and some smaller plugins for circular lists, which were used in the combat screen. feedback on the UI/UX at the end of the semester was largely that while the UI/UX was satisfactory, it could have been pushed further aesthetically to fully match the UI/UX from games we were referencing (hollow knight, dark souls, etc.), so a second pass at the UI would have focused on stronger art direction.

going forward, kisa, iwo, and i elected to continue building off of solanum for our senior thesis game (while also leaving the current iteration of solanum as a finished, standalone game). plans for the senior thesis game that we were not able to achieve in solanum include using a full deckbuilder system instead of a class system to determine the player's deck, a built out and populated overworld with pathfinding-driven click-and-point movement and cutscenes in place of visual novel segments, and an overall overhaul for the narrative and story in general.