Building UA Force: the prototype was only the beginning

An idea worth returning to

UA Force started as a team idea: Ukrainian historical and cultural figures, absurd action abilities, destructive environments and a strong sense of place. When I returned to it, there were already notes, discussions and creative materials. The task was to recover that intent and turn it into something we could actually play.

The browser made the first release straightforward to share. A friend could open a link on a computer without installing a game or creating an account. Mobile support came later as an experiment, not as a promise that every phone would work immediately.

The first useful milestone was a public link

It was tempting to keep adding systems before showing anything. Instead, the working single-player build became the base for a free public prototype. That made feedback concrete: people could point to a ladder, a weapon, a sound or a connection failure they had just experienced.

AI tools helped implement code and generate creative material throughout development. They made iteration faster, but accepting a generated result was never the same as validating it. My work was to keep the product direction coherent, test it directly and keep requesting changes until the behaviour matched the intent.

A weapon can work and still feel wrong

Some early weapons fired too continuously and reached too far. A sniper weapon that cleared everything along a line was technically an attack, but it erased the decisions that should make different characters interesting. The iteration introduced meaningful magazine sizes, automatic reloads, firing cadence and range.

The same distinction appeared in movement. A tank needed separate jump and enter/exit actions. A player on a ladder needed to be able to jump away at any moment. These details were easiest to find with a gamepad in hand. They changed the experience more than another item on a feature list would have.

Co-op exposed a different class of problems

The multiplayer goal was deliberately small: two friends in one world. One browser simulates that world and the other sends inputs. Single-player should remain usable even when the online connection does not work.

Then a friend could create a room but could not connect. A code on screen was not proof of a usable session. The work expanded to network traversal and a TURN fallback. Another subtle problem required buffering short button presses between network updates, so a quick jump or ability tap would not disappear.

Pixel art needs a consistent visual language

Generated assets did not automatically belong together. A sprite could look good in isolation and still clash with the game. Feedback about mismatched styles led to reviewing ability effects and sprites as one visual system.

The same was true of audio. Generic electronic effects were poor substitutes for characterful attacks, audible enemy reactions and a balanced mix. Music that worked in the main menu became irritating when repeated during play. The direction became clearer: separate menu and gameplay moods, refine sound feedback and judge assets in motion, in context.

Touch controls widened the testing problem

Adding a virtual stick was only the start. Movement, shooting and jumping need to work together; cancelled touches must not leave a button held; rotating the device should not strand a player in a fight. Fullscreen and orientation APIs also have to fail gracefully.

The implementation shares gameplay actions across keyboard, gamepad and touch, and pauses with a rotation prompt in portrait mode. Browser and input tests help, but they do not replace physical Android and iPhone playtests. That remains an explicit next step.

What I am taking into the next iteration

The project now has a public demo, room-based co-op and an initial feedback and measurement loop. It is still an early prototype. I want to understand whether players reach a satisfying moment, whether they can connect with a friend and where they leave. It is too early to turn a few visits into a success story.

Next come focused playtests, better reliability and more consistent character feedback, followed by themed missions, story scenes and additional heroes. I would rather make the next few minutes of play stronger before promising a much larger game.

The lesson I want to carry into web product work is practical: shipping creates evidence, and evidence should change the next decision. A feature list describes what exists. Watching someone use the product reveals what actually works.