PackMaster

Solar Stone Games

An in-game screenshot of the combat screen.

  • Pack and load!

    In a world shattered by an unknown catastrophe, the surface has become an uninhabitable wasteland. Civilization has retreated underground, where remnants of the old world linger in forgotten subway tunnels. These tunnels are a labyrinth of danger, inhabited by corrupted mechanical foes and hiding relics that serve as humanity’s last hope for survival.

    Control a robot through randomly-generated tunnel layouts, accumulate items through shop purchases or loot rooms, and engage in tactical turn-based combat using everything you’ve picked up to your advantage!

    • GAME GENRE: 3D Turn-Based RPG

    • ENGINE: Unity 2022.3.1f1

    • PLATFORM: Android

    • TEAM SIZE: 6 Members

    • DURATION: 13 Weeks

    • ROLE(S): Combat Programmer

  • PackMaster is on Itch.io as of December 5th, 2024!

    PLAY IT HERE: https://solarstone-games.itch.io/packmaster

    • Created a turn-based combat state machine that uses a grid-based item inventory selection system 

    • Defined modular behavior patterns for enemies to attack and heal based on their assigned level 

    • Added custom-recorded sound effects to weapons and enemies that play on attack calls

    • Developed a shop system where players can exchange their accumulated gold for weapons

CODE SNIPPETS

The Battle State Machine - PackMaster

This video is an extensive examination of the Battle State Machine script featured in the roguelike turn-based RPG, PackMaster.

METHODS AND REASONINGS

Backpack Inventory Grid Selection

When our team decided upon using a grid-based inventory system, we decided to come to a decision on how to best select the grid cells. Our team deliberated on many types of data collections we could use to denotate which cells were selected in combat-based situations, but ultimately, I decided to implement a queue system.

Due to the “First In, First Out” principle of the queue, I believed the system could quickly return which cells were first selected. This became a very resourceful way of checking whether or not a cell could be selected or deselected, as a new selection would clear the queue and replace the previously-selected cell in the queue with the new selection.

Coupling this logic with item storage within queues meant that any cells occupied by an item would be grouped together and added to the queue. Then, with a new item selection, those newly-selected cells would fit cleanly into the queue once it was cleared of any previous item cell data. Thus, item selection through queues became efficient and readable in combat.

Battle State Machine Enemy Difficulty Settings

To ensure battles had more strategy than entering with a strong grid and blowing past all opposition, difficulty options were proposed all throughout the game’s lifespan. Creating a difficulty setting at game start did not support our system of map generation, so it had to be tied directly to combat and the units residing within.

To help define combat difficulty for units, I decided to focus on a stat I created out of an arbitrary sense of completion and reapplied it to gameplay: the Level stat. At first, levels were purely cosmetic, as there was no experience system for the player until much later and enemy levels did not particularly affect anything. This changed when the idea of having enemies heal themselves was brought into the battle equation. I decided to use the unit’s level in the equation to determine healing; the healBenchmark float is set to the quotient of the enemy’s level and a flat value of 25f. If a randomHealChance float generated each enemy turn returns a value less than healBenchmark and the enemy has reached a point where they can heal themselves, they will elect to heal instead of attack. Therefore, to make more difficult units, our team would be able to raise the levels of given enemy types to ensure they would have more chances to heal themselves.

The team also decided to use the enemy’s level to determine spawn rates. If the enemy’s level exceeded a certain quota, a wider range of enemies become selectable through the spawning index. This meant the game would progressively increase in difficulty as the player naturally became accustomed to systems. Our team believed this would incentivize replay value as players tried saving resources for grids strong enough to best these new faces.

Shop System

As a combat designer, I felt that the shop system could be tailored to strategic combat opportunities. In the shop system, the items for sale are only listed by price instead of by name. This intentionally vague element in the system would make players carefully consider the gold they spend, as players would need to build experience with the game to know which items in the shop match the prices listed. This rewarded returning players with an advantage gained through their own experiences, thus allowing them to feel empowered and growing alongside their robotic character avatar.

Keeping sold item names vague was also something we felt incentivized different strategies involving gold earned from runs. It was our perception that players who would want to learn as much about items as they could right away would feel galvanized to spend more and learn which items fell into specified price ranges. Conversely, players who wanted to save their gold for more opportune moments would feel more incentive to conserve their gold and focus more on item room drops for weaponry.

KEY TAKEAWAYS

PackMaster was my first turn-based RPG developed in Unity. While helping to produce this game, I learned of many different aspects to working on a team.

Firstly, I learned the process of how to create a turn-based combat system by prioritizing state machine logic. Having a structured plan on how to define states for the battle’s beginning, the player’s turn, the enemy’s turn, and the battle’s end helped rapidly hasten the game’s development and mechanic implementation. From there, coroutines to transition between states of battle were implemented, and it allowed me to look at other functions of programming.

Secondly, I learned there is nothing to be ashamed of in asking for help from other teammates. I felt less prepared in aspects of the game’s development that were tangential to the state machine logic. However, in many aspects with the shop system I needed help working with, I was afraid to ask for it because I felt as though the team would quickly grow tired of my requests. I did not want others thinking of me as too reliant on others’ work to coast by or needy to the point everyone had to stop what they were doing to lend a hand. This was a huge mental roadblock for me as a developer, but through the kindness of my team and open-mindedness of the leads of each department, I learned that teamwork is about communicating areas of difficulty. Being able to do so freely without overthinking my team’s perception of me helped not only my own self-esteem as a developer but also the team’s ability to get more done, contrary to what I feared.

Thirdly, I learned that it is also acceptable to designate tasks of my specialty to others on the team. Working under a Lead Programmer was an illuminating experience, as many of the adjacency bonus methods implemented in combat used item logic I myself did not establish. However, I was able to learn from the way the logic was structured and worked with it to a point I felt comfortable with the end result, even making some weapon adjacency bonuses myself.

Fourthly, I learned that work towards sound design needs careful consideration and future proofing. As a Combat Designer, I implemented and recorded lots of sound effects to juice up the system. However, I admittedly added many of these functions to be played without considering which audio sources they coincided with. This caused the volume slider functions to become inconsistent with scaling some of the game’s sounds appropriately. This was eventually corrected, but it caused a lot of time to be taken away from the systems we wanted to add more to, causing us to scrap some planned items. In the future, I will definitely lay out more solid groundwork for audio design, especially pertaining to the combat system the core gameplay loop centers around.

PackMaster has been released to Itch.io as of December 4th, 2024.

To be brought to its webpage, click here!

Previous
Previous

RockStars! (WIP)

Next
Next

Prize Fighter