The brief
Xandar is a turn-based combat game with NFT-linked roster management on Solana. ArgonTeq Inc hired me on a freelance contract to build the playable MVP from scratch and prove the concept end to end. The deliverable was a working demo with combat resolution, round state machine, roster system, and a trailer-ready visual polish; the timeline was three months.
My role
Solo MVP developer under contract with ArgonTeq Inc, working parallel to my full-time Ideofuzion role. I built every system in Blueprints: round state machine, combat resolution, hero abilities, the unit placement layer, the roster management system, the NFT integration surface, and the UI. ArgonTeq's internal team supplied the character animations; I owned everything else.
After I handed off the MVP, ArgonTeq's own engineers picked up the codebase and built on top of it. Two additional heroes were added on the framework I built as a base.
The hard part
The round state machine. Turn-based combat with a fixed sequence of phases (placement, battle, post-battle resolution, next round) sounds simple until you have to make every transition deterministic and recoverable across edge cases. A hero ability that fires during a battle phase has to apply effects, update health, check for KOs, trigger animations, and resolve before the post-battle phase begins; the post-battle phase has to settle damage, check for win and loss conditions, advance the round counter, and reset the placement layer. Every state transition has its own validation gates, and any one of them being slightly wrong meant the next round started in a corrupted state.
The fix was a single Blueprint state machine owning the full round lifecycle, with each phase as a discrete state that read only what it needed and wrote only to its own scope. Sub-state transitions inside each phase (ability resolution order, animation queue, damage accumulation) ran as their own deterministic sequences before yielding to the next top-level state. The shape is unremarkable in hindsight; getting there in the first build of an unfamiliar genre on a three-month MVP clock is what took the time.
What I built
Round state machine. Single Blueprint state machine owning placement, battle, post-battle, and next-round phases. Deterministic transitions, scoped reads and writes per phase, recovery paths for ability resolution edge cases.
Hero ability framework with inheritance. 6 heroes in the MVP with 3 abilities each (18 abilities total). The ability logic stayed simple by design; the inheritance architecture meant additional heroes and richer ability behaviors could be added without rewriting the framework. ArgonTeq's post-MVP team validated that choice by extending the roster.
NFT-linked roster management with mocked Solana lookup. Built the roster system with the on-chain wallet lookup mocked rather than live, behind a clean integration surface. The interface was real, the data source was a stub. ArgonTeq's team replaced the stub with a live Solana call when the game moved past MVP.
Combat resolution layer. Auto-resolution of unit pathing, target selection, damage application, ability firing, and stable end-state detection. The demo had to look watchable without player input during battle phases, which meant tuning combat timing so matches finished at trailer pace.
Trailer-ready UI and polish. Hero selection, roster view, placement controls, in-match HUD. Polished enough to carry the MVP trailer on the official YouTube channel.
Results
MVP shipped on schedule. Three months of solo development produced the playable demo and the official trailer.
The game is now live on GameSwift (linked above), with two additional heroes added on the inheritance framework I built.
The trailer at the top of this page is the MVP build I delivered to ArgonTeq.
Tech stack
Unreal Engine 4.27
Blueprint
Solana for NFT roster ownership (lookup mocked in the MVP, integration surface built for the post-MVP team to swap in the live call)
Lessons learned
The Solana on-chain wallet lookup was mocked in the MVP build, not live. I built the NFT-linked roster system with a real integration surface and a stub data source behind it. That let the demo run reliably during the trailer shoot without depending on a Solana RPC endpoint, gas costs, or wallet-connect flows; it also gave the post-MVP team a clean swap point to replace the stub with a live call once the project moved past the demo window. The takeaway was that for MVP deliverables with a fixed demo window, mocking the slowest or most failure-prone external dependency while keeping the integration surface real saves the demo and does not cost the production build any architecture work.
