I built the first Rommy Archer proof of concept in five days. The starting idea was simple: stand in one place, shoot a bow and stop enemies from reaching a gate. The project eventually acquired an Egyptian royal archer, lizard aliens and an unfinished pyramid. A perfectly reasonable escalation.
What interested me was the interaction. I wanted the player to reach for an arrow, find the string, pull and release, with a clear reason to do it again. The early gray-box capture shows that beginning. The temple footage and editor views come from later iterations, when I kept pushing the world and the weapon. They show where the experiment went after that first sprint.
Give the hands a job
The first control idea used the right trigger to fire. I changed that to a left-hand bow and a right hand that reaches behind the head for an arrow. Hold the grip, bring the arrow to the bow, nock it, draw back, then release the grip to shoot. That sequence gives each hand a job and makes loading the next shot part of the play.
Draw length needed to matter. A weak pull should produce a weaker shot; a fuller draw should give the arrow more speed, followed by an arc under gravity. Haptic cues acknowledge pickup, nocking and release. Those are small responses, but they help explain whether the thing I just did with my hands actually registered.
I kept the player stationary while the enemies approached. That let me concentrate the prototype on aiming, timing and the space around the bow. I could judge the hand interaction without also designing a locomotion system. The visible approach route supplied distance and anticipation: where is the next threat, how long do I have, and is it worth taking this shot?
Give the gate a reason to exist
I wanted a longer, winding route with obstacles that could hide enemies for a moment. The gate also needed to sit where the player could see the consequences of missing. Moving it sideways made the destination easier to read from the shooting station. A path is doing several jobs here: organizing the composition, pacing the targets and making the next decision visible.
The defense loop grew waves, gate health and breaks between attacks. I later moved away from earning gold for a shop and asked for hovering colored gems that the player could shoot for weapon effects. The reward could use the action the player already knew. One less menu, one more excuse to shoot something shiny.
I also wanted powers to belong to the space. In the temple prototype, holding the arrow tip at the brazier activates flame; a crystal supplies the Sunburst power. Choosing an effect becomes another physical action near the player, so the world can teach a piece of the interface. It is a useful design question for VR: can the place where an action happens help explain the action itself?
An alien invasion still needs art direction
Once the bow and defense idea had something to work with, I pushed the setting toward an Egyptian royal archer defending a temple from lizard-like invaders who had landed on an unfinished pyramid. Sandstone, gold and turquoise gave the assets a shared direction. I used generated references and Tripo models, then brought the assets through editing and optimization into Godot. A reference needed to explain the object and its place in the scene, not just produce an attractive image.
The character sheets made that direction concrete: readable silhouettes, armor and matching front, side and back views. They gave the model work a common reference. Animation and in-game behavior still needed their own checks once those characters entered the scene.
The bow exposed the difference quickly. I rejected a more ornate direction because it still needed a usable grip and a comfortable upright hold. Later feedback called for a slimmer shape and a clearer view around the arrow and sight. In VR, the most decorated object in the scene can also be the object permanently blocking the scene.
I also pulled a scarab idea off the bow and kept it as a possible collectible instead. That was a scope decision as much as an art decision. I could keep an idea I liked without making the weapon carry every idea I liked.
Give AI a task I can actually judge
Codex and the Godot tools helped me build and revise the prototype, while generated references helped me explore its look. My direction still had to be specific enough to evaluate: how does an arrow get picked up, what confirms a nock, what changes when I pull farther, and what can I see through the weapon? Each question gives the next implementation a behavior I can inspect.
The later scope work is a good example. I wanted magnification inside the lens while the rest of the headset view stayed consistent. The implementation uses a separate camera and render surface for that local view, leaving the main XR camera alone. That technical choice follows a creative and UX decision: concentrate attention through the sight without turning the player's whole view into a zoom control.
I also wanted aiming help to explain the shot without steering it for me. The current bow code uses the drawing hand and nock to establish the physical arrow direction, with draw affecting launch speed. Guidance and feedback have to be judged against that action. If the assistance quietly takes over the shot, it changes the game I am trying to make.
The world has to meet the stairs
Looking through the headset gave me a less flattering view of the environment, which was useful. I asked for the walkway to pass behind statues, close its route and meet the stairs, with no exposed gaps or floating pieces. A tectonic fissure with one land crossing also gave the ground enemies a reason to follow the road instead of walking straight to the gate. Checking the player's station and other angles made the layout answer practical questions.
The later builds remain prototypes. There is more combat, world and headset work to resolve, and animation experiments have their own review steps. I keep those separate from the five-day POC. The quick build gave me something concrete to direct; the following iterations made the questions more precise.
What I would build first again
For another experiment like this, I would pick one action the player can understand with their hands, give it a visible consequence and test that loop before expanding the setting. Then I would add the world one decision at a time: a route that changes timing, a power with a physical home, a weapon detail that helps the view. That is the part of Rommy I want to keep: an increasingly strange place built around a simple, readable thing to do. Retrieve an arrow, draw, release. Preferably before the aliens finish their work on the gate.
