Boarding Party

Overview

Boarding Party is a Unity and C# tactical squad and strategy prototype built by a small team. Players plan and queue tactical actions before executing the plan, shifting the emphasis away from real-time micromanagement and toward player intent, tactical planning, and systems thinking.

I had strong ownership of the original core game and system design and implemented several substantial technical subsystems. The project is paused at the prototype stage, and implementation ownership across the wider game was shared.

Core Design — Planning Before Execution

I designed the central planning-to-execution loop and the surrounding gameplay systems. Orders, tactical information, squad behaviour, and execution had to work as a connected model: the player should be able to express a plan clearly, then see the squad carry it out without constant intervention.

Technical Highlights

Hierarchical tactical AI

I designed the hierarchical split between squad-level and minion-level AI and defined most of the gameplay-facing goals, actions, and sensors. As the AI architecture evolved from an initially planned FSM-only approach, I contributed to the decision to combine GOAP planning with FSM behaviour so the system would be easier to expand. The architecture and implementation were shared rather than solely mine.

Multi-mode Cinemachine camera

I designed every camera mode and was the primary implementer of the camera system. I migrated it to Cinemachine 3 and developed it from a locked top-down view into a system supporting free movement, mouse-look, unit and squad orbit, strategic mode, and cinematics.

The work included smoothing, scroll movement, cursor states, crosshairs, runtime mode transitions, major rewrites, and fixes for transition bugs. The challenge was not just adding views, but making several control models transition predictably during tactical play.

Directional tactical threat-map prototype

I designed and implemented a spatial threat-map prototype with eight directional sectors per grid cell. Four-bit threat values were bit-packed and combined with direction quantization, distance calculations, raycast obstruction checks, and debug visualization.

The prototype was intended to inform cover selection, navigation, and more advanced orders. That gameplay integration was not completed, and the available evidence does not establish that AI or pathfinding consumed the threat values.

Geometry-aware NavMesh targeting

Large interactable objects could have a transform origin that was unreachable, unsuitable for interaction, or even on the other side of a wall. I designed and implemented GetBestPosition to inspect the object’s geometry, sample candidate positions around it, project them onto the NavMesh, validate complete paths, compare path distance, and select a reachable interaction target.

Sampling at 20-degree intervals was a deliberate precision/performance trade-off. Caching geometry and results made repeated evaluations substantially cheaper after the first calculation.

Supporting systems and tooling

I designed asymmetric environment knowledge so different teams or players could hold different views of traversability and world state. I contributed the initial team-specific implementation; later integration and refactoring were shared.

I also implemented lightweight runtime performance tooling: an FPS counter with current, minimum, maximum, and average rolling metrics, a keyboard-toggleable overlay, and artificial CPU/GPU load tools for testing game behaviour under degraded performance. Unity Profiler was used separately for root-cause analysis.

Boarding Party used Zenject for dependency injection and included both EditMode and PlayMode tests.

Contribution Boundaries

My strongest ownership was the core game and system design, the camera, the threat-map prototype, and GetBestPosition.

The planning loop and tactical AI combined strong design ownership with mixed or shared implementation. Another team member primarily implemented the squad agent, order distribution, blackboard, formations, tactical order framework, and much of the later GOAP work; my contributions focused on architecture, gameplay definitions, iteration, and debugging.

Other explorations remained deliberately bounded. Partial runtime NavMesh rebakes did not become a completed optimized solution, and destructible or rebuildable environment work remained partial and experimental. I contributed to patrol-point algorithm design, but the planned advanced line-of-sight room clearing was not completed. I designed the weapon system, but the evidence does not support a broad claim that I implemented the full system.

Team Workflow

The team worked in Scrum with sprint planning, daily stand-ups, reviews, retrospectives, and backlog management in Jira, with project and design documentation maintained in Confluence. We used Unity Version Control (formerly Plastic SCM) with a trunk-based development workflow. Planning also incorporated selected SAFe-inspired practices, specifically PI Planning.

Production Learnings

The project also sharpened my production judgement. Its scope grew too large, while 3D introduced dependencies that were difficult to support without a technical artist and made animation a bottleneck. I would now start with a focused vertical slice or MVP and reduce presentation dependencies—potentially using 2D—to prove the planning-and-execution loop before expanding the wider game.