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 well as designing and implementing UX wireframes and interaction design.
Kisa, Iwo, and I later expanded Solanum into Avitium as our senior capstone project.
Solanum is available for download on itch.io.
I created a card battler combat system that provides the player with 5 cards to play as actions each turn. The player can play cards as long as they have at least as much AP (the number in the bottom left corner) as the card costs to play (the number in the top left corner of the cards). The player has a deck of 20 cards which automatically shuffles once all cards have been drawn into the hand. The deck and the players stats are determined by which class they choose at the beginning of the fight.
Solanum's combat system was built out during the initial five week development cycle as a prototype for our senior capstone game, which would later become Avitium. I first built out the deck as a paper prototype physical card game to ensure that the game design was serviceable before going on to implement it in Unity.
Solanum features a type system, which is split into attacks (further subdivided into their own elements), 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 max of 5 action points, which restricts which cards they can play based on the AP cost of those cards.
The player's deck is determined by which of the four classes available to them they choose at the beginning of combat. There are five decks overall, but one of the decks changes between boss fights so that the player does not share cards with the boss. The decks share 10 "base" cards and then have 10 cards specific to their class. Each class has its own strengths, weaknesses, and stat layout.
Solanum uses one enemy AI which can have its deck and stats swapped in or changed at runtime via the use 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.
Which boss the player faces is determined via player choice towards the end of the narrative. Archetypically, we wanted one boss to feel like a glass cannon and for the other to feel more tanky, so I provided one of the bosses with a magic-oriented moveset and lower physical attack/defense and the other with more physical- and defense-oriented moves, as well as higher physical attack and defense, but lower resistance to magic.
Solanum features a two-ended narrative presented in a visual novel format. Dialogue was written in Ink, which I then implemented into the game through the usage of a custom dialogue system.
The decision to present the narrative in a visual novel format was one largely determined by time constraints, given the short nature of the development cycle and focus on getting the combat system working. However, including narrative in the game was important to us, so we settled upon a visual novel format as a lower-scope method of achieving this.
The dialogue system drives the background image, which portraits are shown, as well as scene changes when switching to the final boss fight at the end. Changing the background image and portraits, as well as which side the portraits appear on, were both handled through a combination of Ink's tagging system and scriptable objects that acted as libraries of images that could be searched and loaded in via info provided in the tag.
The dialogue system also makes use of Ink's branching narrative capabilities to enable the game's multiple endings (and multiple final bosses). Using Ink allowed our narrative designer to focus on developing the narrative without having to get too into the engine in order to implement it, as they were simply able to plug the .json file into our dialogue manager for the dialogue to run.