A co-op zombie shooter needs more than two players and a rising enemy count. It needs one shared objective, clear jobs for each player, and a short decision window where ammunition, repairs, and progress compete. This guide turns that premise into a compact prompt sequence and a hand-resolved three-wave route.
The example, Dead Air at Beacon Four, is a fictional design exercise. No prompt was run, no playable build or co-op session was supplied, and the numbers below are not tested balance data. Use them as a paper contract to adapt, then verify against a real build before describing results.
Start with one shared objective
“Two players shoot zombies” leaves the generator to invent the reason they stay together. Give them a common task that connects combat to a visible outcome: charge an emergency beacon, keep a gate standing, and reach one extraction point together. That creates three linked questions for a first prototype: who spends ammunition on each threat, what can the pair do between waves, and what state counts as a team win?
Keep the proposed first build deliberately small: one rain-soaked relay yard, one fixed carbine per survivor, three short waves, one beacon, one gate, and one rescue truck. Both players share a screen and use separate generic gamepads in the design assumption. Left stick moves, right stick aims, the trigger fires, and Interact operates the beacon or revive. This describes a fictional control plan; it is not a claim that a particular tool supports local co-op or networking.
Lock the core rules before describing the horde
Write down starting state, costs, timing, and reset before asking for scenery. A small table exposes rules that adjectives such as “tense” or “cooperative” cannot settle.
| System | Proposed first-pass rule | What the prompt should request |
|---|---|---|
| Survivors and weapon | A and B each start at 3 health, 2 loaded rounds, and 4 reserve rounds. Each carries the same semiautomatic carbine. A shot consumes one loaded round; one hit defeats one 1-health walker. | Show both players’ health and ammunition, and keep the weapon fixed. A miss still spends the shot but deals no damage. |
| Waves and pressure | Three 20-second waves spawn 2, then 3, then 4 basic walkers. Each surviving walker deals 1 gate damage at wave expiry, then leaves that encounter. | Make the wave timer and remaining targets legible. State that ties in the shortest path to a survivor go to A. |
| Shared objective | The steel gate begins at 5/5. The beacon begins at 0/3. The team wins only after Wave 3, beacon 3/3, and both survivors in the truck zone. | Keep gate integrity and beacon charge visible as separate state values. One player alone in the truck is not a win. |
| Intermission | Each 8-second safe interval gives each survivor one action: charge, reload up to 2 from reserve, or patch 1 gate point up to 5. At most one beacon charge is earned per interval, even if both choose Charge. Choices resolve together. | Specify simultaneous resolution and the one-charge cap. A second Charge choice has no effect. |
| Down and recovery | At 0 health, a survivor is down for 10 seconds. A partner within 2 metres can hold Interact for 2 seconds to restore exactly 1 health and clear the timer. Each survivor can be revived once per run; a later down after that allowance fails the run. | Request the range, hold time, health restored, timer effect, per-player allowance, and failure condition explicitly. |
| Restart | Restart returns to Wave 1 with health 3 each, gate 5, beacon 0, magazines 2 each, reserve 4 each, no down timers, and both revive allowances unused. | Ask for a full reset. Do not let ammunition, gate damage, beacon charge, or revive flags leak into the next run. |
These numbers make a prompt inspectable; they do not prove the game would feel fair. For example, a 20-second wave requires readable targets and enough time to make a decision, but only an actual build can reveal whether the movement speed, spawn spacing, and firing response support that timing.
Trace charge, reload, and repair across the wave loop
The intermission is where the shared objective becomes a team decision. Charging advances extraction, reloading restores future shots, and patching protects the gate. The design caps beacon progress at one charge per interval so both players cannot finish the objective with a duplicate action.
| Beat | Actions and result | Ammo A / B | Gate | Beacon | Health A / B |
|---|---|---|---|---|---|
| Start | Two players enter the yard; no shots fired. | 2+4 / 2+4 | 5/5 | 0/3 | 3 / 3 |
| Wave 1 | Two walkers spawn. A and B each hit one; both are defeated. | 1+4 / 1+4 | 5/5 | 0/3 | 3 / 3 |
| Intermission 1 | A charges once. B reloads one round. | 1+4 / 2+3 | 5/5 | 1/3 | 3 / 3 |
| Wave 2 | Three walkers spawn. A and B each hit one; one remains and deals 1 gate damage at expiry. | 0+4 / 1+3 | 4/5 | 1/3 | 3 / 3 |
| Intermission 2 | B charges once. A reloads two rounds. | 2+2 / 1+3 | 4/5 | 2/3 | 3 / 3 |
| Wave 3 | Four walkers spawn. Each survivor defeats one; two remain and deal 2 gate damage. | 1+2 / 0+3 | 2/5 | 2/3 | 3 / 3 |
| Intermission 3 and extraction | A charges once. B patches 1 gate point. Both then enter the truck zone. | 1+2 / 0+3 | 3/5 | 3/3 | 3 / 3 |
The arithmetic is simple enough to audit: each shot removes one loaded round; the one remaining Wave 2 walker removes one gate point; two remaining Wave 3 walkers remove two; the final patch adds one. The beacon gains one point in each of three intervals. No survivor is hit in this authored route, so health stays at 3/3 and neither one-use revive allowance is spent. This paper trace does not simulate pathfinding or real-time aim; those parts need an implementation and observed run before anyone can claim they work.
Use a staged prompt sequence
Do not ask one giant prompt to invent rules, build the arena, balance the waves, and polish the result at once. Separate the work so a missing rule can be corrected before it becomes a confusing visual or interaction.
1. Ask for a rule and state contract
Design a fictional same-screen local co-op top-down twin-stick zombie shooter called Dead Air at Beacon Four. Before adding art, return a compact state table for two survivors, one relay yard, three 20-second waves (2/3/4 one-health walkers), one fixed carbine each, health 3, magazine 2, reserve 4, gate 5, beacon 0/3, and an 8-second safe intermission. A fired shot always consumes one round; a hit defeats one walker; every walker remaining at a wave boundary damages the gate once and leaves. Each player may charge, reload up to two rounds, or patch one gate point in an interval; simultaneous choices resolve together and the team gains at most one beacon charge. Include down/revive, both-player extraction, defeat, and complete restart rules. List ambiguities instead of silently inventing a mechanic. This is a design request, not a claim that a build exists.This prompt asks for an explicit state model first. If the reply changes the one-charge cap, makes the reserve shared, or lets a survivor restart with a used revive flag, resolve the conflict before requesting the scene.
2. Request only the first playable slice
Using the agreed table, request one playable arena with two same-screen players, one identical carbine each, a gate, an amber beacon, three escalating waves, an 8-second intermission, and one extraction zone. Show health, loaded and reserve ammo, gate integrity, beacon charge, current wave, and remaining time with readable feedback. Implement the specified simultaneous intermission choices, 10-second down timer, 2-second revive within 2 metres restoring 1 health, one revive allowance per survivor, gate-zero failure, and a restart that resets every listed value. Exclude campaigns, bosses, weapon upgrades, redirects, extra arenas, and online play. Return the controls and a short checklist for inspecting the states; do not report an unobserved test as complete.A focused request limits moving parts, but a generated result still needs inspection. If the actual workflow offers a playable result, compare its visible controls and state against the contract rather than assuming every requested mechanic was implemented.
3. Revise one mismatch after a real observation
After I provide an actual action and observed state, compare it with this expected state: [paste the exact wave/intermission row]. Change only the rule or feedback responsible for the mismatch. Preserve the other player’s state, gate, beacon, ammo, and timing. Return the changed rule, the expected before/after values, and one repeatable check. If there is no observed run attached, do not invent a failure or claim this check passed.This third prompt is intentionally conditional. In this package there is no observed run to paste, so it remains a template rather than a completed iteration. Keep that distinction when publishing a tutorial: a hand-resolved example can teach what to inspect, but it cannot stand in for a test result.
Check the interaction, not just the enemy count
Once a real build exists, check one observable state at a time. These are planned acceptance checks, not results. Record the input, expected change, and observed value so that a correction stays narrow.
| Planned check | Expected result | What a mismatch would reveal |
|---|---|---|
| Both players choose Charge in one interval. | Beacon increases by only one. | The team charge cap or simultaneous resolution is missing. |
| Fire with an empty magazine. | No shot is created; ammo remains zero. | Input feedback or the shot-cost rule is unclear. |
| Reload at 1 loaded / 4 reserve. | At most two rounds transfer, leaving 2 loaded / 3 reserve. | The transfer amount or reserve limit diverges. |
| Let one walker remain at wave expiry. | Gate falls by exactly one, then that encounter’s walker leaves. | Wave-boundary cleanup or damage is being applied twice. |
| Down a survivor and revive within range and time. | Hold Interact for 2 seconds within 2 metres; restore 1 health and clear the 10-second timer. | The target, range, duration, or recovery state needs correction. |
| Down the same survivor after their allowance is used. | The run fails immediately. | The per-survivor revive flag is not persistent. |
| Finish Wave 3 with the beacon charged but one player outside extraction. | No win until both enter the truck zone. | The shared completion condition is incomplete. |
| Restart after damage and a revive. | Wave 1, health 3 each, gate 5, beacon 0, magazines 2, reserve 4, and both revive allowances unused. | Some run state leaked across the reset. |
Do not call an interaction “tested” because its prompt mentions it or because a concept image shows its feedback. A test needs an actual build, repeatable input, and observed output. Until then, label the table as a plan.
Use the general survival page as a scoped starting point
The current official AI Survival Game Generator page describes a broad survival-planning workflow: limited supplies, readable environmental pressure, a safe objective, and recovery from mistakes. Those are useful ingredients for shaping a first survival brief. The page does not establish zombie-specific rules, two-player controls, same-screen co-op, or networking. Keep those mechanics in your own design contract and inspect what a current result actually supports.
For a broad product starting point, use the AI survival game page. The source route is current, but this article’s candidate Blog path is provisional and its entry-source slug is only local attribution. Confirm the accepted Blog URL and reconcile the slug before publication. Do not infer that the page created this example or supports its co-op systems.
Make one revision from an observation
When a playable result is available, compare the first state mismatch with the rule table. If a wave leaves two walkers but damages the gate three times, inspect the wave-boundary event before changing enemy speed, player health, and the beacon together. Change one cause, replay the same case, and record the new state. That keeps a useful iteration tied to evidence.
With no playable result supplied here, the responsible next step is to treat the fictional loop as a paper-ready specification and the checks as unrun. Adapt the values, request a focused first slice, and only then replace the placeholder with measured observations. Add a boss, campaign map, or weapon build after the baseline two-player loop is visible and inspectable.
Frequently asked questions
What makes the first wave cooperative?
Give both players one shared objective and enough simultaneous choices to matter. In this fictional example they defend one gate and charge one beacon, while each can aim at a separate walker. The design does not assume either player’s exact input implementation; controls and team behavior must be inspected in a real build.
How should the first three waves grow?
Change one readable pressure value at a time. The example starts with 2 walkers, then 3, then 4, while keeping each walker at 1 health and the wave at 20 seconds. Those counts are proposed paper values, not measured difficulty. A real prototype would need repeated checks for spawn spacing, time to aim, and gate pressure.
Should both players share ammunition?
This design gives each survivor a separate magazine and reserve so one player’s shots do not silently spend the partner’s resource. A shot always costs one loaded round, and reload transfers at most two rounds. Shared ammunition is another possible design, but the first prompt should choose one model and show its before-and-after values.
What happens when a survivor is downed?
In this proposed rule set, zero health starts a 10-second timer. A partner within 2 metres holds Interact for 2 seconds; success restores exactly 1 health and clears the timer. Each survivor can be revived once per run, and a later down after that survivor’s allowance is used fails the run. This is a fictional design rule, not a tested feature.
Does a prompt guarantee online co-op?
No. A prompt is a request, not proof of an implementation. The official product page supports only a broad survival-planning context; it does not establish zombie-specific gameplay, local co-op controls, or online networking. Inspect an actual current result before describing features, and do not claim that this fictional example has been generated or tested.
