Wasteland Hero (2024)

Lion Studios

My Role:

Systems Designer, Level Designer, Economy Designer

In Wasteland Hero, my main responsibilities were to design and configure core game mechanics, meta systems, and game levels.

During the project’s development, my main notable contributions were:

Designing and configuring the Enemy Spawn. I worked with the lead engineer to create an editor in Unity, allowing me to configure each level’s enemy waves, spawn locations, and the ability to scale enemy strength.
Creating the layout for the game’s levels. I worked with our 3D artists to pick game assets for creating game environments based on top-down 2D mockups. I placed enemy spawn data in the environment and made adjustments to ensure the player, in-game rewards, and enemies behaved as expected.
Designed and configured all weapons and equipment. I created detailed data spreadsheets that contained all the player equipment data and calculators for measuring and balancing purposes. With these tools and data sheets, I balanced each piece of in-game player gear and the gear upgrade trajectories in the upgrade meta-system.
Designed and configured the game’s meta systems, such as the equipment upgrade system, hero stats and milestone system, and the player upgrade system.
Designed and configured the enemy design. I created and balanced the enemy attributes and worked with our concept artist on enemy archetypes and concepts.

Of all the projects I worked on at Lion Studios, this was the one I was by far the most hands-on with the Unity engine. Due to the large scope of the project, I performed a lot of game balance and tweaks in the editor, adjusted UI text and other visual elements, imported data sheets, modified game assets, made adjustments to the game environment and enemy placements, and integrated game sound-effects to free up the environment artist, UI artist, tech artist, and the engineers to focus on more complex tasks.

Project Process & Breakdown

Pre-Production:
Wasteland Hero was the first Action/Arcade-based game I have worked on. My project manager had found strong signals in the success of auto-combat games where inventory management was where the player had agency. Games such as Bacon’s Revenge and Bag Fight - where the player character automatically fights the enemy waves with no player input. Only between waves is when the player can take action in the form of equipping or merging gear for higher power scores and picking special perks. My job was to research these games and figure out how we could create a game utilizing the same core mechanics while also differentiating ourselves from the source. We decided to take the core concept of these games (which were all 2D) into the 3D space and gamify the inventory system further. We wanted to focus more on the loot and inventory system, where players could sell and trade more items between waves in hopes of better gear to drop to create an almost slot machine-like experience.

Several game systems that all feed into the player’s power level in the core game loop

Designing the balance sheets:
I knew a majority of the design work would be in balancing the various game resources; Hero stats, gear stats, enemy stats, level rewards, in-level temporary boosts, and so on. I designed spreadsheets that contained all this information and created formulas that let me quantify each item parameter in relation to the rest of the game items. For player gear, I quantified the value of parameters like attack power, number of projectiles, AoE, DoT, weapon range, cooldown, armor value, size, and so on. Starting with the basic Pistol weapon of ‘common’ rarity, I gauged the “gear score” per inventory slot it took up. The rarity of an item would scale the expected “gear score” further.

When gauging player and hero stats and in-level upgrades, I created a calculator that let me simulate various upgrades or player states in order to balance the power of upgrades. This helped me gauge the value of things like crit %, crit damage %, attack speed, and attack power in relation to each other, and how it would affect the player’s damage per second.

Enemy parameters were actually the easiest ones to balance since enemies only had to be balanced relative to the player and gear, and this was mostly done through playtesting. With some experimentation, I found a nice balance where players could expect to fight off 5-20 basic enemies at any given time and scale them based on that assumption. Tougher enemies were balanced accordingly and tweaked through playtesting.

Core Loop:
The core loop of the game followed a similar structure to other inventory management action/arcade games: The core idea is sending a hero character into a level where they have to survive multiple incoming enemy waves. The combat itself is automatic, so the player has little to no agency during the fighting segment. Only after the enemy wave has been taken care of, will the player have the ability to loot equipment from a chest, then choose whether to merge duplicate items for stronger items, or equip more powerful gear before starting the next wave of enemies. Other games in this genre are 2D, either top-down or side-scrolling, and enemies would wander onto the screen from the right side. But since we chose a 3D 3rd person over-the-shoulder camera angle, we had to have enemies spawn out of the line of sight. This informed how we had to plan the level design since we needed walls and other obstacles enemies could spawn behind, then walk out from behind to avoid them popping into existence before the player’s eyes. I worked with the environment artist on this by creating basic top-down block-out examples of how we would have enemies spawn and move. When the environment artist had created a layout, I could then take over and make adjustments to the geometry as I created the enemy spawn points and pathing. Another challenge was communicating enemy numbers. While it looked more exciting to see dozens of enemies coming towards the screen, enemies could often block visibility to objects such as tappable boosts and traps. Something that is unfortunately not reflected in the current version available, but that was the next step of the process is adjusting the camera angle to display a more top-down camera. This was especially helpful in showing players where tappable trap objects and boosts were located. However, due to interactable trap objects and boosts being implemented last minute after feedback from internal playtesting that players wanted more to do, the camera adjustments never made it into the build in time to address these issues.

3rd-person camera makes enemies feel more threatening but also obscures the player’s vision of objects in the distance

Inventory System:
The game’s inventory system consisted of a physics-based backpack where items could be moved around and merged with each other. This was one of the ways we wanted to stand out from other games in the genre. Rather than having a specific set of inventory slots, we wanted the actual management of the backpack to feel more playful and resemble inventories seen in games such as the Ultima series, where your backpack felt more like a real backpack. It also lets players reorganize their own pack by stacking items on top of each other or alongside each other.

Items in the inventory are physics-based, making the inventory more playful

Reworking the game’s art direction:

During the game’s development, we showed a game build internally. There was concern from higher-ups that the game’s art style was too high fidelity, and there were concerns over the CPI if we kept the current art style. Since this was a, executive decision made from outside the team, and a decision we all disagreed with, it was incredibly disheartening to hear. Our artists had already rendered, rigged and animated the enemy and player characters and weapon models, but we had to do massive rework to “downgrade” both aspects. Not only did this add several weeks of rework as our concept artist had to redo his concepts, 3D artist redo the models, and animators had to rig and reanimate the models due to the changes, but it was a massive morale blow to the team as we were happy with the current style. After several weeks, we had much simpler enemy and weapon designs, but due to the lost time and the fact that we only had one animator, the project’s overall quality took a hit.

Takeaways:

I learned a lot from working on Wasteland Hero, despite the production challenges and pivots that were made. The project was already very ambitious and challenging to execute to the polished standard we would have liked, and the team had no time to pivot based on player feedback or make post-release adjustments before the market test ended. One of my personal shortcomings was not providing more arguments to support my pushbacks to decisions made from upper management which cost us time we could have used to polish the game and deliver the visual fidelity the team wanted. Pivoting from 2D to 3D was also a very costly decision that I was concerned about at the time, as it presented us with additional design challenges that could have been avoided. Thinking of ways to iterate on successful formulas and breathing fresh air into them is crucial for the success and evolution of games, but it is important to really consider what aspects of a project to innovate on, and which ones should be left untouched. Some of the feedback we got during playtests internally was the lack of player agency during enemy waves. While this is feedback I would normally agree on, in the case of the audience we were trying to reach, this was not an issue, and could potentially work against it, as the core experience these games need to deliver on is the inventory management, and what agency you present to the player during that phase of the game. The combat phase is where players can sit back and watch the result of their choices. These games are often played while doing something else, so forcing player agency can be detrimental to the experience, even if that seems counterintuitive. But imagine if players were forced to constantly interact with an incremental idler game - that would kill the purpose of the game. All things considered I learned a lot, especially getting more comfortable with working in Unity and our Git repository, and in hindsight to push back more and lay out strong arguments against asks and demands I do not agree with.