Building River Strike with AI: From an Apache Model to a Playable River-Valley Campaign

Building River Strike with AI: An Apache Combat Game Devlog · Jason Guo · 2026-09-06 · River Strike, Game Development, Unity, Blender, AI Collaboration

An Apache helicopter flies down a river valley. The mouse aims its cannon, and anti-aircraft guns fire from the banks. Seen in isolation, the scene already looks like a game. Keep playing, though, and other questions emerge: Where do the rounds actually come from? Can a bridge block a missile? What changes after a base is destroyed? And where do you restart after being shot down? Those questions have shaped my recent work on the river-raid project. The directory still carries that name; the game is now called River Strike . I have been working with Codex on the implementation, building and revising models in Blender, and checking the results inside Unity. The work has gradually shifted from adding visible objects to making the visuals, controls, and consequences agree. This is a development account as of September 6, 2026. The project now has a three-chapter campaign, stage saves, equipment choices, a macOS build, and a development film. It is still evolving. These milestones are not a release announcement. Start with what the player does in the valley River Strike is an arcade-style flight combat game built around a steady advance along a river. The helicopter moves forward with assistance while the player controls lateral movement, altitude, and aim. Slowing down or hovering briefly gives the player more time to deal with a target. Keeping that scope clear matters: a personal project needs to spend its attention on decisions players make repeatedly, rather than start by building an enormous world. During an encounter, the player watches the terrain ahead, nearby fire, cannon heat, and the remaining missiles. The cannon has no total ammunition limit, but it overheats. Missiles are limited and require a lock. Holding the fire button is no longer an answer to every situation. Approach angle, distance, and time to cool down each have a purpose. Slowing and hovering fit into the same rhythm. With the default controls, Ctrl slows the aircraft and Q provides eight seconds of hovering, followed by a recovery period. Hovering buys aiming time, but also means spending longer under enemy fire. That is the tradeoff I want to preserve: a helpful control still needs to be judged in the situation where it is used. Actual footage from the three-chapter campaign iteration. Mission, radar, aircraft, and weapon information occupy the four corners. The aircraft shown belongs to that stage of development; its appearance was revised later. Rebuilding the Apache: a successful import can still look wrong The helicopter is the object the player spends the most time looking at. It also provides the clearest example of what went wrong during this iteration. A model can import successfully, display its materials, and spin its rotors while still looking awkward. The cockpit was one such problem. Part of the forward fuselage obscured the tandem cockpit, and the transitions between the glazing, nose, and rear body did not feel convincing. Changes to the forward body height, cockpit volume, and connecting shapes made the two cockpit sections easier to read from common viewing angles. The tail took a wrong turn too: an assumption about how the landing gear should line up on the ground produced an excessively long tail-wheel support, which looked particularly strange in flight. After comparing the model with reference photographs, we abandoned that assumption. The tail boom was lowered and tapered, the fin and tail rotor moved with it, and the tail wheel returned to a compact mounting assembly. The main wheels, hubs, engine housings, stub wings, weapon mounts, and rotor details were also revised. Correcting the overall relationships mattered most. Adding rivets to the wrong proportions would only produce a more complicated mistake. This work also preserved editable Blender source files. Model generation, export, and in-game inspection became a repeatable sequence. A later cockpit or landing-gear adjustment should not depend on deciphering an unexplained final asset. The Apache revision from September 6, rendered in Blender to inspect structure and proportions. This is a model render, not a gameplay screenshot or a survey-grade reconstruction. Inspection has to return to the player's camera Blender and Unity use different coordinate conventions. An inconsistent forward direction, rotation axis, or part center can turn a correct-looking preview into a reversed aircraft, misplaced parts, or a rotor spinning around the wrong point. The main rotor, tail rotor, and cannon also need independent movement; combining everything into one object for a convenient export would defeat that purpose. I therefore broke inspection into concrete checks: does the model hold together from the front, rear, and side? Does it face the right way after import? Do both rotors turn around the correct locations? Is the muzzle still attached to the articulated cannon? Finally, how does it look through the normal chase camera? In a flight game, the rear view players see repeatedly can matter more than a beautiful front-facing showcase image. Give firing a clear chain of cause and effect The most basic combat change was to make the cannon turn toward the aim point and launch rounds from its actual muzzle. Missiles also depart from alternating left and right mounts. This affects more than close-up appearance: the aim line, shot direction, and obstruction rules need to agree. Missiles acquire visible targets in front of the aircraft and turn gradually in flight. They do not casually switch to another target after launch. Bridges are excluded from automatic target acquisition, but still block projectiles. Riverbanks, water, buildings, bridge structures, and sandbags stop rounds from passing through. Tree canopies remain visual objects, avoiding repeated collisions with foliage that would be difficult for the player to judge. Fast projectiles introduce a problem a screenshot will not reveal. Checking only their position at the end of each frame can put a round in front of a wall in one frame and behind it in the next, without recording a hit. Collision checks now follow the entire segment of travel. The point is consistency from the player's perspective: an obstacle that appears to stop a shot should actually stop it. Once the hit rules were more dependable, the feedback deserved attention. Cannon tracers became short, readable gold-white streaks. Explosions were separated into flash, fire and fragments, and lingering smoke. Rotor, weapon, and interface sounds received separate treatment. Players should be able to see and hear whether they hit something and where damage is coming from, rather than rely on a score changing in a corner. An effects inspection frame. Base destruction was triggered to examine fire, fragments, and smoke in isolation; this image is not evidence of an unaided mission completion. Make the river, roads, and bases affect the fight A river valley can easily become a pleasant background corridor: the helicopter advances, trees and buildings slide past, and targets sit on either side. To make those places worth observing, the environment needs to support both navigation and combat. The banks were rebuilt with continuous terrain transitions, shallows, wet sand, rocks, shrubs, and changes across the water surface. Boats travel along the channel, use the central passage when approaching bridges, and leave wakes that fade behind them. Pausing stops boats, water animation, and combat together. These small details make the motion on screen obey a shared sense of time. On land, bridges connect to approaches and roads, while bases occupy riverbank platforms and higher ground. The current layout contains 24 anti-aircraft sites, 46 guns, and 11 regional bases. The counts are not a completion criterion. What matters is that threats come from different elevations, bases have understandable relationships with the route, and players have reasons to choose where to approach first. Facilities now have specific consequences. Destroying an ammunition facility removes some nearby anti-aircraft threats. Radar and other facilities can slow local anti-aircraft fire. Heliports actually launch reinforcements, and destroying one early prevents subsequent launches. Supply and maintenance locations can restore resources. Targets therefore suggest an order of action: the easiest thing to hit may not be the most useful thing to destroy first. That connection changes the experience more than another batch of buildings would. An ammunition depot that only plays an explosion is a target. If destroying it changes the defenses along the next stretch of the route, it gives the player a reason to reconsider the approach. The paused tactical map pairs locations with their effects: the supply port restores resources, while the garrison affects nearby patrol attacks. The player can review their value before resuming flight. Turn a long route into a three-chapter campaign Early project documents described a longer single mission. The current structure has three chapters centered on breaking through a garrison, attacking ridge radar, and reaching the command area. Each chapter has a main objective, optional actions, and stage saves. The design aims for roughly four to six minutes per chapter. How long actual players need is a question for later playtesting. Chapters also make the cost of failure clearer. After being shot down, the game explains the cause and allows a retry from the saved stage. Progress can also be continued after quitting. Previously destroyed facilities need to be restored correctly, and loading a save must not grant their rewards again. These are unobtrusive details, but they directly affect whether someone wants another attempt. Equipment choices provide another reason to retry. Cooling equipment improves sustained fire but increases fuel consumption. Auxiliary fuel and stronger armor improve endurance or survival at the cost of some mobility. Precision and area-effect missiles have different carrying capacities. These configurations should support different approaches instead of simply increasing every number together. I also added training that advances through actual player actions. Lateral movement, altitude changes, the cannon, missiles, slowing, hovering, and evasion each require the corresponding action before the lesson progresses. A list of keys on the starting screen does not establish that a new player understands how to use them. Reading the interface is part of combat The interface received a number of repairs. Mission information, radar, aircraft status, and weapon status occupy separate corners. Ground clearance, upcoming terrain warnings, and incoming-damage direction help explain the immediate situation. Route progress is shown separately from the main objective, so reaching the end of the flight path does not imply the mission is complete. Menus need to survive ordinary back-and-forth use too. Pausing to change a setting, returning to flight, retrying after a loss, and alternating between mouse and keyboard navigation must not leave input focus stranded. Audio channels can be adjusted separately, text can be enlarged, and mouse sensitivity, flashes, and camera shake can be changed. Controls can also be rebound. These improvements rarely sit at the center of a promotional image, but they determine whether someone opening the game for the first time can get started. If finding controls or interpreting status takes too much attention, the combat never gets a fair chance. Working with AI still requires judgment In this iteration, I supplied goals and pointed out problems in the visuals and controls. Codex helped implement and revise them; Blender and Unity made the results observable. Whether that loop moved forward depended heavily on how specific the feedback was. “Make the helicopter look better” is difficult to judge as finished. “The fuselage hides the tandem cockpit,” “the tail wheel looks like an overlong stalk,” and “the cannon fire is hard to see from the normal chase view” lead to identifiable changes in models, cameras, and checks. Reference images provide a basis for judgment, but the result still has to be inspected in the game itself. AI can expand an implementation quickly. It can also carry a mistaken assumption a long way, just as quickly. The tail-wheel revision was a reminder that refining details will not automatically correct a bad premise. The creator has to stop, describe the intended result again, and accept that completed work may need to be rebuilt. That is also why handoff notes and inspection records have become useful creative tools for me. They explain why a change happened, which version has been superseded, and what remains unverified. The next conversation needs to continue from the actual state of the project, rather than repeatedly repair the same issue or treat an old conclusion as a current fact. What has actually been verified The September 5 campaign records show complete automated runs through all three chapters on standard difficulty, taking approximately 4 minutes 11 seconds, 4 minutes 11 seconds, and 3 minutes 56 seconds. Those runs used normal damage, physically launched rounds, limited missiles, and cannon heat. They did not give the helicopter invulnerability or replenish its armor along the way. Saves, retries, facility-state restoration, duplicate-reward prevention, and training also received separate checks. Those records support a limited but useful conclusion: the campaign at that point could be completed under its rules. They do not establish that a new player will finish in the same time, and they cannot replace human feedback on difficulty, fatigue, or enjoyment. Casual and challenge difficulty checks covered combat segments; that should not be described as complete acceptance testing across every difficulty. After the September 6 aircraft revision, further checks covered multiple views, materials, rotors, the cannon, and related combat effects. I would not describe the previous day's complete campaign run as a fresh full-campaign test of the latest model. Keeping that distinction makes it clear what later testing still needs to cover. A development film, and the next questions to answer The project also produced a 180-second English development film covering gameplay, model revisions, weapons, the valley, mission structure, and retries. Its sources include both the ordinary chase camera and shots arranged for filming, with automated controls; some failure scenes are controlled demonstrations. The source notes record those distinctions. The film presents development progress, not proof of an unaided complete playthrough. The most useful next step is to have people who were not involved in development start from the training and play. When they are first shot down, can they explain why? Are the benefits of optional facilities clear enough? Do cannon cooling and limited missiles create interesting choices? Does playing three chapters in succession become repetitive or tiring? More models, more targets, and more automated checks cannot answer those questions on their own. River Strike has grown from a helicopter that can fly and fire into a campaign that can be learned, approached through different targets, failed, and retried. The lesson I want to carry forward is to bring each change back to one question: do the things the player sees, the actions they take, and the results that follow add up to something coherent? Source note: This article draws on the project's documentation, handoff notes, model-revision records, campaign checks, and film source notes available as of September 6, 2026. Images are actual project renders and inspection captures. Captions identify material from different development stages.