Technical Test / Gameplay Prototype

Avatar of Nature

A portfolio-first Unity 6 vertical slice: a readable elemental boss encounter built from a technical test, with interruptible attacks, stagger, weak points, summons, and automated gameplay regression.

Role
Gameplay Programmer / Designer
Period
Prototype in progress
Scope
Algorithms · Gameplay systems · Encounter design · QA automation
O(n) list serialization
2 boss phases
15 automated gameplay checks
0 / 0 errors / warnings at checkpoint

Overview

This is the public case-study page for a Saber Interactive gameplay-programming test and the resulting portfolio prototype. The Unity project lives in a separate repository so the implementation, build, and documentation can evolve independently from the portfolio presentation.

The prototype is intentionally small and focused: it demonstrates readable gameplay, sound encounter design, clean client-side logic, and fast iteration rather than production-scale framework work.

The important part is the progression: a conventional algorithmic task became a playable experiment in how systems communicate intent to a player.

Test brief

The test is structured around three parts:

  1. Serialize and deserialize a doubly linked list with Prev, Next, Rand, and Data in better than O(n²) time, without standard serialization and without adding fields to the source classes.
  2. Explain recent games from a gameplay perspective and communicate the design reasoning clearly.
  3. Build a first- or third-person boss-fight prototype with two phases, a stationary boss, readable attacks, weak points, and a playable build.

Part 1 — Linked-list serialization

The solution assigns each node an index during a first pass and stores a Dictionary<ListNode, int> mapping. The serialized representation keeps each node’s data and the index of its random reference, using -1 for null.

Deserialization happens in two passes:

  1. Create all nodes and restore the sequential Prev/Next links.
  2. Resolve Rand references through the stored indices.

This keeps the algorithm at O(n) time and O(n) auxiliary memory. O(log n) is impossible for a complete serialization because every node must be read and written at least once; linear time is the optimal bound.

The implementation is deliberately explicit: a stable intermediate representation, two reconstruction passes, and no changes to the source node classes.

The complete source, tests, format notes, and edge-case verification are available in the linked-list serialization case study.

Part 2 — Gameplay analysis

This section will document the selected games, the mechanics that stood out, and the design vocabulary used to explain why they work: gameplay loop, player agency, encounter pacing, feedback, risk/reward, and the relationship between mechanics and presentation.

The examples I use are Wuchang: Fallen Feathers, Helldivers 2, and ARC Raiders. They cover three different lessons: readable boss combat, emergent multiplayer, and the live-ops reality that follows a strong core loop.

  • Wuchang: Fallen Feathers — pattern reading, timing, stagger, and vulnerability windows.
  • Helldivers 2 — simple rules such as friendly fire and stratagems producing emergent co-op situations.
  • ARC Raiders — a strong PvPvE/extraction core, plus the challenge of sustaining progression, content cadence, and retention after launch.

The goal is not to list games for keywords. It is to show that gameplay decisions can be observed, described, and translated into implementable systems.

Part 3 — Avatar of Nature boss fight

The boss is a stationary elemental avatar. A face appears above the arena and selects the next elemental attack. The player can damage the boss during attacks; filling the stagger meter interrupts the current attack and exposes weak points for a short high-damage window.

The core loop is:

Element selection
        ↓
Readable telegraph
        ↓
Player dodges and deals damage
        ↓
Stagger fills and interrupts the attack
        ↓
Weak points open
        ↓
Short vulnerability window
        ↓
Next cycle or Phase 2

Planned attack language:

  • Earth: spikes emerge from marked ground zones.
  • Wind: a force pulse pushes the player and tests positioning.
  • Fire/meteor: impacts are telegraphed from above and create temporary danger zones.
  • Shockwave: the player avoids a travelling wave by leaving the ground.

Phase 2 increases pressure through faster timing, attack combinations, Meteor Rain, and a summon intermission using the existing HoverBot and Turret enemies. The boss remains stationary; the encounter becomes dynamic through arena pressure, interruption, and changing priorities.

What the player is meant to understand

The boss fight is built around a simple communication loop:

  1. The arena announces an attack.
  2. The player reads the telegraph and chooses movement or damage.
  3. Sustained damage fills stagger and interrupts the pattern.
  4. Weak points open for a short, high-value window.
  5. Phase 2 adds pressure without changing the rules underneath.

Verification is part of the feature

The encounter includes a runtime Gameplay Test Bot and pure state assertions. The bot performs real aiming, shooting, jumping, damage, stagger, weak-point, phase-transition, summon, combo, and death checks. Test-only hooks are isolated and documented rather than hidden inside production behaviour.

The current showcase checkpoint is repeatedly verified in Play Mode. The goal is not just “the boss appeared once”, but a reproducible report:

AVATAR_BOSS_GAMEPLAY_TEST: PASS
Console: 0 errors / 0 warnings

This is the part I would carry into production: every new attack or phase should be easy to add, easy to observe, and hard to regress silently.

Implementation approach

The Unity project starts from FPS Microgame on Unity 6.3 LTS (6000.3.11f1). Existing player, camera, weapon, health, damage, projectile, and feedback systems are reused where they fit. New gameplay code is added incrementally and verified after each milestone.

The development workflow uses Unity MCP through a local server where available, with Git checkpoints and explicit Play Mode/Console verification after every gameplay milestone.

Status

The playable boss showcase is implemented in AvatarBossShowcase.unity. The next presentation pass is visual capture: a short video showing the telegraphs, stagger break, weak points, Phase 2, summon intermission, and boss death.