FightGame · End-to-End Product

Personalized-Avatar Multiplayer Pixel RPG

Upload a reference image, generate a pixel avatar and play as that same character in a shared multiplayer world and skill-card battles.

FightGame shared world with a player and named NPCs — Select a capture to open the original image.

The case in 30 seconds

Problem: Keep one player identity and battle result consistent across online players.
My role: Set scope and system boundaries, coordinate Agents and accept complete playable flows.
Result: Core playability completed: custom avatars, a shared world and a 79-card battle system.
Evidence: Code, automated checks and hands-on desktop, mobile and two-player acceptance.

Playable personalization loop

One reference image becomes one identity across the game.

Select a capture to open the original image.

Six product captures show the complete path: request a custom skin, let the asynchronous generation job finish, then carry the approved avatar into the shared world and battle.

01 · SelectOpen Custom Skin
02 · UploadSubmit a reference image
03 · GenerateWait for the skin job
04 · ReviewConfirm the generated avatar
05 · ExploreUse the same identity in-world
06 · BattleCarry the identity into combat

One identity, three contexts. The generated skin is not a detached demo output; it becomes the active avatar used by profile, overworld and battle views.

The challenge

The difficult part was not producing another game screen. The same player identity had to survive the profile, overworld, remote-player and battle contexts. Two online players also needed to submit different actions but receive one shared, authoritative round result.

I translated the broad game direction into staged systems, set module boundaries and acceptance priorities, coordinated persistent Agent ownership, and reviewed the actual playable flows as the product grew.

Persistent identity and card loadout

Three product decisions

01
Separate intention from resolution
Each player submits a command; the server owns the authoritative round result instead of trusting either client.
02
Keep identity consistent
Profile, overworld, remote-player and battle views use the same player identity rather than disconnected representations.
03
Make mechanical depth readable
A code-verified 79-card catalogue supports limits, elements, counters, statuses and combo setup/payoff while preserving an explainable core loop.

Product delivery map

From a broad game idea to an accepted playable system.

The difficult work sits between the brief and the build: defining what “playable” means, dividing persistent ownership, integrating the parts and sending failures back through the loop.

Client–server productThree connected contexts

01 · IdentityProfile & loadout

02 · PresenceShared world

03 · ResolutionOnline battle

01Client intentPersonalized multiplayer retro game
02Scope & acceptanceIdentity, world, cards and synchronized battle
03Persistent Agent ownersFive bounded workstreams
- Client & interface
- Server & contracts
- Battle & cards
- World & NPCs
- QA & integration
04IntegrateOne coherent client–server product
05Cross-device UATDesktop, mobile and two-player flows
06CorrectReproduce, fix and regress
07Accepted milestoneCore playability completed

↶UAT feedback loop Integration failures return to the responsible workstream until the full flow—not an isolated screen—passes acceptance.

How one round works

Player actions are treated as submitted intentions. The server waits for the required inputs, validates and stores them, resolves the rules and persists the round. Both clients then render the same result.

Player ASubmit command

→

Server authorityValidate · resolve · persist

→

Both clientsRender one outcome

Hands-on acceptance

My UAT correction loop

I personally tested the complete flows. When an Agent-delivered feature looked finished but failed inside the product, I turned the failure into a specific correction cycle.

When multiplayer results differed across devices, I recorded reproduction steps, expected and actual results, and screenshots. I routed the defect to the responsible Agent, then repeated cross-device regression after the correction before accepting the playable flow.

01ObserveSee the failure in context
02ReproduceMake the defect repeatable
03AssignRoute it to the right owner
04FixCorrect the bounded cause
05Re-testCheck the flow and regression
06AcceptDecide what is actually ready

Mechanical breadth

A complete 79-card system makes tactical depth inspectable.

The complete collection board shows all 79 cards at once: 40 Common, 30 Uncommon and nine Premium cards across Rare, Epic and Legendary tiers. Together they support deck limits, elements, counters, statuses and combo setup/payoff.

Complete FightGame collection board showing all 79 skill cards by rarity — Complete collection board79 cards · one inspectable system40 Common · 30 Uncommon · 9 Premium across Rare, Epic and Legendary tiers.View full collection ↗

Contribution

What I owned

Product direction and staged priorities
System and Agent ownership boundaries
Review of multiplayer, battle, cards, identity, map and interface results
Playable-flow acceptance and correction decisions

What Agents accelerated

Substantial client, server and tooling implementation
Tests, contract checks, documentation and handoffs
Module debugging and integration corrections
Authorised deployment and operational tasks

Status and boundary

The core-playability milestone was completed.

A later phase covering tournaments, live streaming and operations was planned or partially scaffolded, but the client did not commission that expansion.

This case does not claim public launch, production readiness, revenue, user count or verified business impact. The selected captures use an ephemeral guest identity and contain no wallet address, credential, client material or transaction data.

Next case

Four Agents. One shared timeline.

Continue with Niulai Squad, a four-Agent system with a validated technical baseline and ongoing operations.

View next case All projects