Building a Straw Boat Tactics Prototype with OpenGame

Borrowing Arrows began with a small question: could we turn a familiar story into a playable browser prototype by discussing, generating, testing and revising it inside OpenGame Studio?

After eight generated versions, we stopped at a short 3D river encounter. It has planning, boat movement, enemy volleys, straw capacity and a real return journey. It is a practical test of the website's workflow, with rough edges still visible.

Play Borrowing Arrows: Misty River. Use a desktop keyboard and mouse. The game opens in Chinese and includes an English toggle.

Turning a story into a decision

The idea comes from the straw-boat stratagem in Romance of the Three Kingdoms: lure enemy arrows into straw-covered boats and bring them home. Our current, capacity, warning times and damage rules are gameplay adaptations.

The early versions offered a few actions such as drumming, turning and retreating. They could produce wins and losses, but the feedback was clear: clicking through those actions did not offer enough to play with. Adding background text helped explain the situation without solving that design problem.

We then tried direct boat control. Position and heading began to affect what happened, but steering alone still did not communicate the pleasure of arranging a clever trap.

The final direction was to give the player time to plan.

What the playable version does

Press M to freeze the encounter. Click the water to place a ghost destination, then hold A or D to choose a heading. Executing the order sends the real boat there and turns it into position. The ghost is a plan, not a teleport.

Gold rings show where enemies can hear the drum. Pressing Space in range makes archers commit to the sound position before firing. Present a straw-covered side to catch arrows, while accounting for the current. Each side can hold 16 arrows; the goal is to sail home with at least 24 and an intact hull.

The player can also steer manually with W, S, A and D. Each enemy group's volley has a recap showing catches, splashes, hull damage and arrows blocked by full straw.

What actual play changed

Testing exposed problems that a successful generation status could not reveal. One version's visible hull disagreed with its movement and collision orientation. Another used large rectangular mist sheets. The first planning version could sail past its destination and circle instead of arriving, while its toolbar covered important water and boat details.

We returned these observations to the same Studio conversation. The last repair made arrival work in our tested route, moved planning controls to the bottom, replaced the mist sheets with soft-edged wisps, and updated the HUD before showing volley results.

All game generation and revisions were requested through the website. We downloaded the original bundles for inspection and records; we did not replace the website's output with a locally written game.

A completed test run

Our final run was recoverable rather than perfect. The first lure collected 12 arrows without hull damage. After changing sides, the next caught only three and sent most arrows into the water. We moved into fog, lowered alert and collected another six, taking one point of hull damage. One more lure added seven.

We then physically sailed home with 28 arrows and five of six hull points. Returning with zero arrows correctly produced a shortfall. Restarting during an arrow sequence restored empty straw and full hull without delayed damage from the previous attempt.

These observations verify specific behavior. They do not establish an ideal route, a measured first-play duration or broad player appeal.

What the experiment demonstrated

Across eight builds, this experiment used 80 Studio Credits. The last design iteration and its repair took about 17 minutes 33 seconds of combined server task time. That figure excludes discussion, inspection and playtesting; it is not total production time or a promise for another project.

OpenGame produced a playable 3D prototype and supported repeated changes through the same website conversation. Human feedback remained necessary to decide whether the actions were interesting and whether the visual feedback matched the rules.

The finished slice still has limitations. Current compensation is hard to judge in advance, the enemy shore has limited visual expression, and recap cards can obscure the boat just after a volley. We stopped with enough evidence to evaluate the experiment rather than continuing to polish it indefinitely.

You can try the prototype, read the earlier Clean Break production case, or start your own idea in OpenGame Studio.