Phantom Brigade

Phantom Brigade is a hybrid turn-based & real-time tactical RPG with a timeline-based command system. See the future, predict enemy actions, and plot your counterattack on the timeline! Outnumbered and out-gunned, lead the Brigade through a desperate campaign to retake their homeland.

I closely collaborated with the directors to design, document, prototype, and implement critical features and game content with other team members under strict constraints and deadlines.

• Engine: Unity

• Team: 12 core with 50+ supporting

• Role: Designer, Programming, and Production

• Duration: 4 years since I joined, 9 years in total

• Release: Steam

Content Design

Designing, implementing, and balancing most of the game's content and overseeing its development from L0 to L4 using Google Sheets, serialized YAML files, and in-engine database editing tools.

• Level design of combat arenas

• Sandbox campaign map, flow & progression

• Economy, meta-progression, & upgrade trees

• Character progression

• Equipment crafting

• FTUE and tutorial

• Achievements

• Communicating sprint plans

• Streaming monthly Early-Access updates on Twitch

• Managing and mentoring a junior content designer

Technical Design

Designing, writing specifications, prototyping, and integrating critical gameplay features and tools in collaboration with programmers and artists using C# and proprietary visual scripting language.

• Cinematic cameras

• Overworld character controls and abilities

• Modular equipment & Internal components systems

• Scriptable scenarios and events

• AI behavior trees and targeting profiles

• Organizing and managing community and internal playtests

• Managing, compiling, and analyzing analytics data

• Setting up and managing project documentation

• Assisting with roadmap planning and prioritization

• Improving ticket workflows and setting up content pipelines

Wrote briefs, created level layouts, implemented gameplay elements, and set up spawn points and triggers.

We aimed to create levels that offered full destructibility, allowing mechs to dash onto any structure. Initially, we planned to use these levels as templates for procedurally generating additional content. However, we had to abandon this system due to time and resource constraints, resulting in later levels having more unique characteristics and distinct landmarks.

Development stages

1. Brief and sketch: Creating a concise level outline and a pixel art-style layout, each pixel representing a tile. This step helped establish a visual blueprint that matched the voxel grid in the editor.

1. Greybox: Created a rough pass of the level using a custom WFC voxel level editor. Established the basic structure and layout of the level, providing a solid foundation for further development.

2. Iteration pass: Engaged in extensive playtesting and made necessary adjustments to the level in real-time. Ensured that the gameplay experience was enjoyable and balanced.

3. Set dressing: Added visual elements and set dressing to the level for the initial pass. This step involved incorporating props to enhance aesthetics and immersion. The artist later conducted a final pass to refine the visuals.

Examples of stages for 2 levels

Config files defining retreat zones, spawn points and objectives.

Early vs late in development levels.

Challenge

How to make a static campaign map enjoyable in between playthroughs and throughout a 100h campaign.

Solution

We focused on creating emergence and providing players with the tools to harness it to their advantage, thereby enabling the formation of their own captivating narratives. We achieved emergence by implementing several key elements, including procedurally placed entities, simple entity behaviors, dynamic weather, and dynamically generated rewards.

Procedural entities, while seemingly straightforward individually, can react to the player's presence and trigger events or scenarios upon interaction. By introducing sufficient entities, even these primary conditions combine to generate complex and captivating behaviors, resulting in exciting and unique stories without requiring additional bespoke content. However, this approach only works if you reach a critical mass of content for the emergence to be sufficiently complex to avoid generating repetitive patterns.

Implementing dynamic weather creates an ever-changing environment where players can utilize their abilities to navigate the same spaces in diverse ways. Weather patterns resolve a critical concern by providing players with dynamic areas that can conceal their presence, albeit at the risk of unexpected encounters. This encourages players to deviate from the direct path and venture into unforeseen locations, often leading to the discovery of fascinating side stories.

Including dynamic loot enhances replayability, particularly in the game's early stages. Each run offers players a distinct set of equipment, prompting them to adopt different playstyles. Rather than relying solely on purely random loot distribution, the game intelligently groups loot by factions, allowing players to strategically target specific parts and subsystems as they better understand the game's world at later stages of the campaign. This feature further enriches the gameplay experience and gives players a sense of progression and mastery while keeping the early game fresh.

Congesting the province to capture territory filled with systemic entities.

Using dynamic weather to get past enemy sensors without being noticed.

First Time User Experience

Challenge

How to introduce players to a sandbox game with numerous novel mechanics in a sandbox environment where they could do anything and go anywhere while working with a limited budget that did not allow for a contextual tutorial.

Solution

We tried to drop the players into the open world and see what they would struggle with to discover concepts, mechanics, and content that players did not understand. In some cases, we ended up making mechanics more intuitive. In others, we decided to teach them in a controlled way.

I designed and implemented scenarios and events and spent most of the tutorial messages flowing for the semi-linear section of the campaign specifically dedicated to teaching players the key aspects of the game that they found challenging. This section, which encompasses the first two hours of gameplay, has often been praised in reviews as the most fun section of the game.

Within this collection of events and scenarios, we utilized various techniques to ensure a comprehensive learning experience. One of the highlights was providing players with a supporting unit equipped with unsalvagable advanced gear. This allowed us to keep gear between factions symmetrical, gave us more balancing wiggle room, and allowed players to not only understand the breadth of the game but also gave them a tantalizing glimpse into the multitude of features they could unlock in the future.

Problem

How to create meaningful and not overpowered character upgrades and progression when enemies do not become stronger without changing enemy behavior?

Solution

Give players tactical options rather than making their characters stronger. This will make players feel smarter while preserving the balance between the in-game characters. Even if players technically become "stronger" than the enemies, the feeling of being clever is fun, unlike a raw increase in character power which makes things trivial.

The First iteration of the upgrades focused on improving simple players' stats; This was a mistake as tests revealed runaway effects where the game became too easy, and the upgrades were too abstract to be meaningfully engaging or too granular to be impactful.

During the second pass, I designed upgrades that gave players options for interacting with the world. This gave players tools to form more intricate plans and enjoy the game in a way that suited their play style and made it possible to challenge more dangerous areas of the map without trivializing the risks.

Examples

• Ability to create caches in enemy territory to support deeper excursions or safer retreats if things do not go as planned.

• Launching an autonomous drone to scout that gives players vision data and pretends to be them.

• Calling in reinforcements, the size of which depends on the reputation between PB and Homeguard.

• Radar pings that allow players to see clearly in the middle of the rain storms

• Movement modes that have clear tradeoffs and benefits

Challenge

How do we make the world not only react to player actions but build on their actions, presenting them with new stories that use the player's journey as their underpinning?

Solutions

Events and combat encounters pull information from the game world to determine which content is valid under the circumstances and injects contextual filters into generators that determine which equipment the enemies will have in combat. This solution is quite complex as the more procedural the game is, the better it works, but the less authored content you get and the harder it is to debug and balance.

As you can see from the examples provided, there are many layers to how a single event can unravel, and that is not even considering what equipment and upgrades players have and how they choose to use them on camping and combat maps.

Example of a radio tower event with additional context

Players can intercept radio tower transmission from a radio tower entity in the province. If the tower is hostile, they will likely get a propaganda transmission event that requires them to deal with the radio tower. When attacked, the units that will saw will have equipment based on the enemy faction that controls the region, and their difficulty and quantity will depend on how many enemies are aware of the player's presence in the province. If players sneakily attach the radio tower, the enemies are unlikely to have reinforcement; however, if the player is spotted or the region is contested, the radio tower might get all sorts of reinforcements to bombing runs from nearby airfield locations. Additionally, depending on the weather, players might get a better chance to sneak by on the camping map and more mech heat dissipation on the combat map. Finally, the objective in combat can change from the destruction of the radio tower to its capture depending on the event, and the following events will be based on what players do in combat.

From there, eliminating the previously described tower or its capture will influence if players transmit Home Guard intel, get advanced recon information, or additional events that boost the morale using other entities and interactions that players performed in different events and combat encounters.

Here are some additional examples of events and a scenario without the additional context.

Examples of how event step looks in the game.

We had only several days to design and implement some of the more complex events so I used diagrams to rapidly draft the event structure to act as a support document when communicating with writers and QA.

Visual scripting tools create hundreds of interconnected scriptable events that trigger combat scenarios, tutorial popups, or meta-campaign map consequences. They were developed in collaboration with programmers, writers, and designers.

Configuration of a simple one event: step, visuals, conditional checks, options, and consequences.

Serialized as YAML text files

Challenge

How to create a breadth of meaningful content as a small team on a data-driven project that needs to support a lot of replayability and modding?

Solutions

Multiple solutions need to come together to make this work. They did the job but also had some severe tradeoffs that, in the end, could have been accomplished better.

Nevertheless, some great pieces of content came from this system.

For example:

• Collection of shields and guns with modular visuals and abstract internals assembled to make unique weapon permutations. Mech parts would have subsystems with visuals based on their modifiers. These subsystems would then be connected to a part that would have a base subsystem that gave it some initial stats that the modifiers could then alter. A rifle could have a receiver with a scope that would make the weapon more accurate, while a bigger magazine would give it a higher RPM. This would drive the rifle archetype into sub-archetypes based on the tag constraints for subsystems derived from unit types and factions.

• Similarly, the same modifier can be applied to projectiles creating cool things like guided missiles that can penetrate through units and structures like railgun bolts and fragment next to the enemy into laser beams.

Ultimately, we tested different approaches to see if more intricate and procedural armor and weapon configurations would be more suitable. Still, a decision was made to go with simpler designs while absorbing the cost of working with more complex tools due to the limited time required to streamline them.

Units are configured from small building blocks in data due to legacy tools.

Very early prototype for modular equipment with customizable sections

Next iteration introduced stat modifications to each section.

Prototype of how modular equipment could randomly generate every permutation of the part sub subsystems creating unique designs.

Takeaways

Programmers created editor tools based on design specifications, letting me connect, serialize, and deserialize data in the editor at runtime. This allowed me to develop content links based on tag constraints and quickly test what kind of emergent behaviors this data latticework produced when placed in sandboxed systemic environments.

This approach worked well. However, we ran into multiple friction points that stuck with us till the end due to early oversight.

• Data validation became a big issue as many configs and tag relationships became too complex for a human being to track.

• The systems became too generalized, and data became too nested, making troubleshooting challenging.

• Chunks of data became too big to display visually in Unity Inspector.

  These are by no means unsolvable problems, but with our team size, they were too big to solve and were spotted too late to be worth addressing, which barely allowed us to push the game past the finish line.

Some solutions that we could have done if we had the time.

• We did use dropdowns a lot to elevate typos. And we showed final data output results based on generation profiles and inherited data. However, we could have made tools to preview data links and bulk editing tags to make data refactoring easier and less error-prone.

• We could have been more deliberate with our target gameplay before committing to building a robust soliton. Instead, we repeatedly built on top of preexisting solutions, often leading to overengineered tools and data structures due to the requirement of dealing with legacy code and data structures.

• Data could have been more compartmentalized, or other solutions like using preexisting scripting languages like Lua or C# would have made for better, more streamlined solutions rather than creating our visual scripting language and tools.

Challenge

How do we prevent players from spamming actions on the timeline without introducing resource management.

Solution

We did not want players to manage ammunition, so we introduced heat. Something that encouraged places to space out the action without the overhead of pixel hunting and managing and getting bogged down in numbers.

1. The first interaction stunned the mech for a turn if it overheated. This was problematic because standing still is a death sentence in PB, and it wiped out players' plans, which was not fun.

2. Second iterations caused mechs to take a fixed amount of damage every time the mech was overheating. This was better because players could push the mech to get the job done while sacrificing health. However, it made it more powerful, had more value in overheating, and made weapon balance messier.

3. The third and final iteration caused mechs to take any heat above maximum as damage every second. Inherently this is more complicated for the player to parse; however, with some clean UI, players could intuitively gauge that more powerful weapons would cause more damage if overheating, making balancing the mechanic more streamlined.

Analytics

Challenge

How to meaningfully use analytics on a small team.

Solution

I outlined clear specifications for the problems we were trying to solve with analytics and the data we needed to inform actionable solutions. This allowed us to approach analytics in a way that did not just collect data for the sake of it but targeted specific issues.

For example, we were uncertain if players were making meaningful choices about which gear they used, so we started tracking which gear they brought into missions and how many times it was activated. This eliminated the bias of bringing gear because of an empty slot. We wanted to know what gear players were actively using in combat.

With this information, we found out that due to how the prototype of the thruster mechanic worked, it made all thrusters but one redundant; players used the mechanic, but they honed in on the flaw in the thruster system that made one of the thrusters archetypes better than all others no matter what thruster designs we made. This informed how we redesigned the thrusts system, which we verified as fixed using new analytics data from playtests.

Playtests and Analytics

• Wrote specifications for what metrics should be tracked using analytics.

• Collaborated with programmers to implement analytics solutions (Unity Analytics, BigQuery, Custom data-driven heatmap).

• Organized internal focus playtests with different company employees to gather thoughts on the project from different disciplines, such as UI.

• Coordinated with community management to organize playtests with players from the PB community Discord.

• Collated data using custom analytics dashboards.

The screenshot includes some of the dashboards that I have put together to filter and monitor BigQuerry data using Google Looker Studio

Documentation

• Created most of the documentation for the project to provide specifications and disseminate spring plan objectives in an easy-to-understand way.

• Documentation included summaries of features and targeted objectives for the upcoming spring.

• Specifications for each feature and content, including user stories, a list of what should be expected from the feature, and what things will not be included.

• These specifications were written to support the work of all departments, from QA to Art to Programming.

Mentoring Junior Designers

During PB, I mentored a Junior Designer. This involved outlining work, providing feedback, having weekly discussions and quarterly reviews, ensuring the designer felt supported, had clear objectives, and developing a trusting environment to support their growth.