Avitium is a card battler/turn-based RPG made for Windows and Mac. It was developed from August 2024 to May 2025 in collaboration with Iwo Kmiecik (art direction, art and design, technical art) and Kisa Rodriguez (narrative design and production) as our senior capstone project for the BFA Game Arts program at Pratt Institute. Solanum was an early prototype version of this project that we expanded into the full game of Avitium.
As the game designer and programmer, I was responsible for designing and implementing the combat, a tricktaking minigame, the dialogue system, pathfinding system, and camera and cutscene systems, as well as UX design and implementation.
Avitium is available for purchase on itch.io and is coming soon to Steam.
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 right corner of the cards). The player has a deck of 20 cards which automatically shuffles once all cards have been drawn into the hand.
Avitium's combat system was originally developed during the development process of Solanum, which served as an early iteration/tech demo developed in 5 weeks during my junior year that would become the fountain for Avitium.
The original 5 week prototype focused primarily on functionality over visuals and used a class system instead of a full deckbuilder. The art director for the project and I later spent an additional 3 weeks specifically dedicated to UI/UX, which led to the wireframe used for Avitium, though the UI art underwent a substantial overhaul when Avitium entered active development.
The cards underwent a substantial redesign because we received feedback that the visual hierarchy on the original cards was confusing, and that it was unclear which number represented damage vs. AP cost. We also changed the positioning and size of the health bars, as we realized that it was unclear which HP bar belonged to the player vs. the enemy with different camera angles.
The cards used for Avitium feature the AP cost in the upper right corner and the damage in the card description to more closely mirror card designs featured in modern trading card games, which are more recognizable and intuitive to players. Additionally, we color coded the cards themselves in Avitium, which enables the player to have a better understanding of cards in the enemy's hand.
The cards have two sides, one of which is used for the combat and the other of which is used for an alternate tricktaking gamemode that also provides further narrative to the game. As a reward for winning tricktaking matches, the player receives new cards that they can add to their deck. The deck can be pulled up and examined at any time during the game.
The idea of having a card-based minigame that played into the narrative was an idea we had had since the beginning of development. However, the earliest incarnations of the game didn't use tricktaking, but instead used a typing system where the enemy would play a card and the player would have the chance to respond with a card that beat the enemy card's type, and then combo on top of that card using specific other card types.
Instead of points, this system used a stress meter, where the player was intended to keep the enemy at a certain level of stress (but not max out the meter) in order to "win" the conversation. Feedback indicated that this system was too confusing, so it was later replaced with a tricktaking system which uses the general category or "suit" of the card in place of its element.
Switching to suits also led to the color coding of cards (orange for physical, purple for magical, and green for nonviolent). Though the cards are still linked to their combat versions, we removed all information other than their tricktaking value and dissociated tricktaking value from base damage (which it was previously tied to) in order to clarify gameplay and make it more interesting numerically.
Integrating narrative into the tricktaking games was easily the most challenging part for us and is the subject we'd return to if we continue development on the game. The solution we ended up reaching is that whichever character leads a hand makes a statement regarding their belief on a certain subject, and subsequently whoever wins more rounds (and therefore leads more hands) wins the game on a gameplay perspective and the argument from a narrative perspective. Each conversation has unique player and enemy dialogue.
Avitium has 5 chapters of main story content, which required the design and development of a dialogue system that would have a visually distinctive appearance and also could be used to control character and camera movement during cutscenes. The dialogue system was implemented with Ink and made extensive usage of the tagging system in order to achieve those goals.
The original UI used for Avitium's dialogue was much closer to that of visual novels. However, we felt that this obstructed the screen too much, and that the textbox was very large relative to the text present in any given statement (which also could not be increased due to large chunks of texts being overwhelming to the player).
We took inspiration from other 3D RPGs with similar overhead perspectives for our final dialogue, which took a more vertical approach and also enables the player to scroll back and read through previous dialogue in the same conversation if they've missed something.
Avitium also has an explorable 3D world that consists of two different environments. The character moves via point-and-click controls and is followed by an orbital camera, which is the primary camera used for gameplay. Specific cameras are used for combat and certain cutscenes. Transitions between cameras were handled using Cinemachine.
The pathfinding system is used to control the movement of both the player character and other characters during and between cutscenes. The player character moves freely, whereas movement of other characters is based on setting locations for them to travel to. Their current destination to move to is assigned during runtime through Ink tags, and likewise their destinations have triggers on them that enable them to ready their next conversation and continue the story.
Very early on in the project, I initially programmed a pathfinding system myself, but we decided to switch to using the A* Pathfinding Project so that I could take advantage of its extra complexity and save time to dedicate to implementing other parts of the game.
The A* Pathfinding Project has significantly more detailed node setups relative to the system I had programmed and also easily dealt with several problems I could foresee being an issue down the line (for example, grids that aren't purely horizontal), so this ended up being the right choice in the end. We set up colliders to allow the player and NPCs to traverse between maps and used Unity's layer system to distinguish between the ground and obstacles that the player should not be able to walk through (furniture, bushes, walls, etc.).