Independent project · Playable prototype
UA Force: a browser game, built to be played
A Ukrainian arcade action game with destructible levels, historical heroes and two-player online co-op. An ongoing experiment in turning an early team concept into a public product through AI-assisted development and hands-on playtesting.
Ukrainian-language game · Cartoon combat and mature humour
The idea
What if Ukrainian cultural and historical figures became larger-than-life action heroes? UA Force combines recognisable characters such as Taras Shevchenko and Lesya Ukrainka with distinct weapons, special moves and exaggerated pixel-art combat. Its Ukrainian identity shapes the characters, language, music and humour.
The concept began with a team. I returned to our early notes and existing creative materials, then directed a new browser implementation. The first goal was simple: open a link, start playing, invite a friend.
What you can play today
The free prototype runs without an account. It has single-player missions, destructible terrain, boss encounters, rescuable heroes, weapons with magazines and automatic reloads, character abilities, summonable allies and driveable tanks.
Online co-op supports two players through room codes or invitation links. Keyboard and gamepad controls share an action model with experimental mobile touch controls. The game also includes contextual interaction prompts, pause menus, an in-game bug-report entry point and initial gameplay measurement.
My role and the development workflow
I lead product direction: shaping requirements, choosing priorities, testing actual gameplay with a gamepad and translating player feedback into concrete changes. Development is AI-assisted: coding agents support implementation, and generation tools support creative assets. I own the product decisions and hands-on acceptance of the result.
My responsibility is to decide what should ship, what still feels wrong and what needs another iteration. Earlier team ideas and materials remain part of the project’s origins. UA Force complements my commercial React and TypeScript work with a very different kind of interactive product.
Challenge 1 — one authoritative world
The runtime uses TypeScript, Canvas 2D and Vite. Input, world simulation and rendering are separated. In online play, one browser is the host: it owns enemies, damage, terrain destruction, pickups and level events. The guest sends actions and receives state snapshots.
PeerJS provides the WebRTC connection layer. Signaling, STUN and a TURN fallback help establish connections across networks. This avoids a dedicated game server for the prototype, but it is not a server-free system. Single-player remains usable independently of the online service.
Challenge 2 — a tap can disappear between ticks
A short jump or ability press can happen entirely between two network updates. Sending only the input state at the next update loses that action. The implementation buffers one-shot actions until the network tick consumes them, while movement continues to use the current state.
This is a small but important product lesson: a connection can look healthy while the controls still feel broken. Testing has to include what a player actually does, not just whether packets arrive.
Challenge 3 — three input methods, one game
Keyboard, gamepad and touch feed the same gameplay actions. On mobile, the left stick handles movement and the right-side buttons handle combat and interaction. Losing focus or cancelling a touch clears held inputs.
Fullscreen is optional and requested through a user action. If orientation locking is unavailable, the game can still run in a landscape browser tab. Mobile controls are experimental: physical Android and iPhone compatibility and performance still need broader playtesting.
Shipping, evidence and limits
The public game is hosted on Cloudflare Pages. Source history, design notes and reproducible checks are kept with the project. Automated checks cover simulation and input behaviour; browser checks cover menus and responsive controls.
Two-browser and forced-relay connection checks are useful evidence, but wider network reliability still needs playtesting. Host migration, matchmaking and online accounts are outside the current scope. Analytics has recently been added; learning where players get stuck is the next step.
Where it goes next
The next iteration is driven by playtests: improve connection reliability, validate touch controls on real devices, refine character abilities and keep pixel art and sound consistent. New themed missions and story scenes will follow, with more characters introduced as their gameplay becomes ready.
The aim is a stronger small game first. Broader multiplayer features and infrastructure should follow evidence that players want to keep coming back.
A few seconds of co-op
Two players, one battlefield. This short clip was captured from the current browser prototype using two connected clients on a Mac. It is gameplay footage, not a concept animation.
7 seconds · Muted by default; sound is optional.