Ask ยท Reports

Council Transcript: Naval Auto-Battler MVP

Generated: 2026-07-07 13:07:51 Europe/Berlin

Original Question

Council this. I'm getting idea to create mobile game with React Native. A 2D platformer that battles naval ships, armed cruiser and air crafts, vehicles can be customized and equip with different weapons and armors. At first it will be a simple battle of group versus group 1 vs group 2, user will be able to select up to 5 vehicles for each groups and run an automated battle. Every vehicle will have HP based on original design plus the armor they will be equipped with, and attack damage based on their default plus equipped weapons.

Framed Question

The user is considering creating a mobile game in React Native. The game idea: a 2D platformer-style battle game involving naval ships, armed cruisers, aircraft, and possibly other vehicles. Vehicles can be customized and equipped with different weapons and armor. The first version would be a simple automated group-vs-group battle: group 1 vs group 2, where the user can select up to 5 vehicles for each group, then run an automated battle. Each vehicle has HP based on its base/original design plus equipped armor, and attack damage based on its default attack plus equipped weapons.

The core decision: Is this a good concept and scope to pursue as an initial mobile game project, and how should the user shape the MVP so it has a realistic chance of becoming fun, buildable, and testable?

What's at stake: Choosing a scope that is too broad could stall development before the game becomes playable. Choosing a scope that is too simple could produce an auto-battle spreadsheet without a compelling hook. The user needs clarity on risks, MVP focus, and the first concrete validation step.

Advisor Responses

The Contrarian

The fatal flaw is trying to make "naval platformer auto-battle customization" all at once. That is not an MVP; it is three different hard problems stapled together: combat simulation, progression/customization balance, and readable 2D action presentation. If you build all three before proving fun, you will likely produce a confusing stat sandbox.

The biggest risk is that automated group-vs-group battles remove player agency. If the player only picks five units, equips items, then watches numbers resolve, the fun must come from prediction, surprise, and post-battle learning. That means the battle must be extremely readable. "Why did I lose?" has to be obvious within seconds. If aircraft, cruisers, armor, weapons, range, speed, targeting, and terrain all exist early, nobody will understand the outcome, including you.

The MVP should not be a platformer yet. Start with a 2D side-view auto-battle lane: two teams, max 3 units each, no vertical platforming, no aircraft, no free movement complexity. Use maybe three unit archetypes: tanky cruiser, fast torpedo boat, long-range carrier/artillery ship. Give each one one weapon slot and one armor slot. That is enough to test composition, counters, and readable combat.

Your first validation step should be ugly and fast: build a deterministic battle simulator with replay visualization. No menus, no progression, no inventory economy. Create 10 preset loadouts, run battles, and ask: can a player predict matchups, understand losses, and want to tweak the lineup for a rematch? If not, more vehicles and customization will only hide the problem.

The First Principles Thinker

You are not deciding "is this game idea good?" You are deciding whether you can discover one repeatable moment of fun before drowning in vehicles, weapons, armor, aircraft, factions, UI, balance, and content.

The MVP should not be "naval auto-battler with customization." That is already too many systems. The first principles version is: two small teams enter, the player makes one meaningful pre-battle decision, the simulation produces a surprising but understandable outcome.

Cut it to 3 unit types and 3 equipment choices total. Example: cruiser, carrier, destroyer. Equipment: cannon, torpedo, armor. No aircraft as separate controllable units yet. No platformer movement yet unless it directly affects combat readability. "Platformer-style" is probably a distraction; if the battle is automated, the real game is composition, counters, positioning, and watching outcomes.

Your first validation build should be ugly and deterministic enough to test: pick 3 ships per side, place them in lanes or distances, press battle, watch 30 seconds. The hook must be visible in that loop. If players immediately say, "run it again, I want to try a different lineup," you have something. If they say, "cool stats," you have a spreadsheet.

The core risk is not React Native. The risk is premature content. Do not design fleets. Design one combat rule that creates interesting tradeoffs. For example: armor beats cannons, torpedoes punish armor, carriers pressure slow ships. Build that triangle first. Everything else earns its place only if that loop is fun.

The Expansionist

This concept gets interesting the moment it stops being "ships with stats" and becomes a vehicle-combat sandbox players can understand at a glance. The upside is not just one auto-battler; it is a modular war-machine builder. Ships, aircraft, submarines, turrets, armor plates, missiles, carriers, drones, repair modules: the long-term content surface is huge.

The MVP should lean into that upside early. Do not start with many vehicle types. Start with one battlefield fantasy that proves the hook: "I built this fleet, pressed battle, and the outcome made visual sense." Five ships per side is enough. Give each ship 3-4 equipment slots, not endless customization: weapon, armor, utility, special. The special slot is where the game can become memorable: torpedo spread, smoke screen, fighter launch, shield pulse, repair burst, kamikaze drone.

Your first version should not be balanced like a spreadsheet. It should create readable drama: missiles arcing, armor absorbing, one fragile glass-cannon ship deleting a tank, aircraft forcing anti-air choices. If players immediately ask "what if I swap this weapon?" you have something.

The adjacent opportunity is an async fleet-builder: players share fleet codes, challenge friends, run tournaments, and watch replays. That is much bigger than a local battle sim.

First validation step: build a 2-minute prototype battle with 6 premade units and 8 equipment items. No menus beyond team selection. Test whether people rerun battles to experiment. If they do, expand customization.

The Outsider

This concept is too blurry right now. "Naval ships, cruisers, aircraft, other vehicles, weapons, armor, group battles" sounds exciting to the creator, but to a new player it is unclear what the actual game is. Is it about building fleets? Watching tactics resolve? Counter-picking enemy loadouts? Collecting vehicles? Without that clarity, you risk building a stats simulator with boat skins.

The MVP should not be "up to 5 vehicles, many vehicle types, customizable gear." That is already too much. Start with one battle format: 3v3 naval-only auto-battle. No aircraft yet. No terrain complexity yet. No large equipment catalog. Use maybe 4 ship classes: destroyer, cruiser, battleship, carrier-like support if needed. Each class needs a readable combat identity.

The hook should be visible counters, not raw numbers. Example: torpedoes beat heavy armor, flak beats aircraft later, armor beats light guns, missiles punish slow ships. The player should look at an enemy lineup and think, "I can outbuild that."

First validation step: build a paper/prototype battle simulator with ugly UI and 12 predefined ships. Let the player pick 3 ships per side, press battle, and watch 30-second fights. The test is simple: after losing, does the player want to change their lineup and try again? If yes, continue. If no, do not add more vehicles. The fun must come from decisions, not content volume.

The Executor

Build the MVP as a deterministic battle simulator first, not a "mobile game" yet.

Monday morning: make one ugly React Native screen with two teams, max 3 ships per side, a `Start Battle` button, and a scrolling combat log. No aircraft. No platforming. No real-time controls. No shop. No campaign. If that log is not interesting after 20 battles, the bigger version will not save it.

Your first playable loop should be:

1. Pick Team A and Team B from 4 vehicle types.

2. Add 0-2 equipment items per vehicle.

3. Press battle.

4. Watch 30-90 seconds of automated combat.

5. See who won and why.

The fun has to come from readable tradeoffs: destroyer is fast but fragile, cruiser is balanced, battleship hits hard but slow, carrier summons aircraft or long-range pressure later. Weapons should create counters, not just bigger numbers. Example: torpedoes punish armor, AA counters aircraft, heavy cannon beats cruisers, repair armor helps slow ships survive.

Do not start with custom vehicle building. Start with presets plus a few equipment slots. Customization becomes valuable only after the player understands the baseline units.

The validation step is brutally simple: make the combat log version in one week. If you cannot get yourself to run "just one more battle" after tuning numbers, stop or redesign. The first milestone is not graphics. It is proving that team composition creates surprising, explainable outcomes.

Peer Reviews

Review 1

1. Strongest: B. It gives the clearest buildable path: deterministic simulator first, 3v3, ugly UI, combat log, no aircraft/platforming/progression. It identifies the real validation test: whether team composition creates surprising, explainable outcomes before visuals or content expansion.

2. Biggest blind spot: A. It gets excited about the long-term content surface too early. Specials, drones, carriers, tournaments, replay sharing, and async fleet codes may be good later, but A risks pulling the user back into scope creep before the core combat loop is proven.

3. What all five missed: They under-discuss retention and input cadence for mobile. An auto-battler MVP needs a reason to come back beyond "rerun battle": short session length, upgrade pacing, opponent generation, saved replays, daily challenges, or PvE ladders. They also miss technical validation of React Native for readable 2D battle presentation: animation performance, deterministic simulation, replay recording, and whether to use a game engine/library like Flame, Godot, Unity, or a React Native canvas/game framework instead of plain React Native UI.

Review 2

1. Strongest: E. It identifies the actual risk: auto-battlers live or die on prediction, surprise, and learning, not just "cool combat." B, C, and D all narrow scope well, but E explains why the MVP must be deterministic, readable, and replayable.

2. Biggest blind spot: A. It jumps to the full fantasy before proving the core loop. Ships, aircraft, subs, drones, tournaments, fleet sharing, and replays may be good long-term, but A underweights the risk that the base battle is not fun or legible. It is product roadmap thinking before prototype validation.

3. What all five missed: none define the player's pre-battle decision loop sharply enough. What exactly does the player inspect, predict, change, and learn after losing? The MVP should include a tiny scouting/build/resolve/review loop, not just combat. Also missing: target audience and session shape. Is this for tactics nerds, idle players, or builder/sandbox players? That choice changes complexity, pacing, UI, and monetizable depth.

Review 3

1. Strongest: E. It names the real risk: auto-battlers only work if prediction, surprise, and post-battle learning replace direct agency. B, C, and D give good scope control, but E explains why the MVP must be shaped around replay comprehension and "I understand why I lost." That is the core design problem.

2. Biggest blind spot: A. A is useful for upside, but it jumps to content, modes, and metagame before proving the battle loop. Fleet sharing, tournaments, submarines, drones, and replays are plausible later, but they can hide the harder question: is watching three units fight actually compelling after five repeats?

3. What all five missed: the player's pre-battle decision interface. They discuss unit counts, archetypes, equipment, and logs, but not how the player forms a hypothesis before combat. The MVP needs a tight inspect-build-predict loop: enemy preview, clear counters, simple loadout choice, battle, replay/log, then immediate adjustment. Without that, even a good simulator becomes passive noise.

Pursue it, but shape the MVP closer to E + B + C: deterministic 3v3 naval-only battles, tiny catalog, visible counters, replay/log, and one-more-battle validation.

Review 4

1. Strongest: E. It names the real design risk: auto-battlers only work if prediction, surprise, and post-battle learning create agency. B, C, and D correctly shrink scope, but E explains why the MVP must be deterministic, readable, and replayable.

2. Biggest blind spot: A. A is useful as a long-term vision, but it jumps to content expansion before proving the core loop. Ships, aircraft, submarines, tournaments, fleet sharing, and replays are upside only after the battle-builder loop is addictive. Its MVP is still too broad.

3. What all five missed: player progression and session structure. They discuss battle rules, unit count, and readability, but not what happens before and after each fight: drafting, upgrading, rewards, loss recovery, run length, matchmaking, or why a player returns tomorrow. The MVP should test one full loop, not just one battle: choose build, watch fight, understand loss, improve build, rematch.

Review 5

1. Strongest: E. It identifies the real risk: the game is trying to make automated combat, customization, and readable action fun simultaneously. That is the hardest design problem. E's MVP is also sharp: 3 units, deterministic replay, one weapon slot, one armor slot. It preserves the core fantasy while forcing post-battle learning.

2. Biggest blind spot: A. A is useful for long-term vision, but it is dangerously premature. Ships, aircraft, submarines, drones, tournaments, fleet sharing, and replays all assume the base loop works. It misses that content variety is not the bottleneck; proving one readable, repeatable "I can outbuild that" moment is.

3. What all five missed: distribution and audience proof. They focus on mechanics, but not who this is for, why that player would install it, or what adjacent games prove demand. The MVP should test not only "is one more battle fun?" but also whether the fantasy is legible in a 10-second clip or store-page GIF. If the build/counter/replay loop cannot sell itself visually, a mobile auto-battler will struggle even if the simulator is clever.

Anonymization Mapping

Chairman Synthesis

Where the Council Agrees

The council strongly agrees that the initial concept is too broad for a first build. The first version should prove the combat decision loop, not the whole fantasy of naval ships, aircraft, cruisers, custom vehicles, platformer movement, equipment catalogs, progression, and multiple vehicle classes.

There is also strong agreement that automated battles only work if the player still feels agency. Because the player is not controlling the fight directly, agency must come from prediction, counter-building, readable outcomes, and learning from losses.

Most advisors converged on a 3v3 naval-only MVP with a tiny number of archetypes, simple equipment, deterministic simulation, and a battle log or replay. They also converged on a simple validation question: does the player want to tweak the lineup and run one more battle?

Where the Council Clashes

The main clash is between long-term fantasy and first-build discipline. The Expansionist sees the larger opportunity: modular war machines, special modules, aircraft, submarines, async fleet sharing, tournaments, and replay culture. That is a real upside. But the rest of the council argues that adding these early will bury the only question that matters: is the core build-counter-battle loop fun and understandable?

There is also a small scope disagreement around 5v5 versus 3v3. The council lands on 3v3 for the prototype because 5v5 makes outcomes harder to read. Five units can come later once counters are obvious and the replay system explains why the result happened.

Blind Spots the Council Caught

The peer review round added four important missing pieces.

First, the MVP needs a pre-battle decision interface, not just a simulator. The player should inspect the opponent, form a hypothesis, pick counters, run the battle, review the result, and rematch.

Second, mobile retention cannot be ignored forever. Later versions need a cadence: short sessions, generated opponents, saved replays, daily challenges, PvE ladders, async challenges, or progression. Do not build all that first, but know the prototype is only the core loop.

Third, React Native should be tested pragmatically. Plain React Native UI is fine for menus and a first combat log. For readable animated 2D battles, evaluate Canvas/Skia, a React Native game framework, Godot, Unity, or another game-oriented layer.

Fourth, audience and distribution need proof. Decide whether this is for tactics players, idle/collection players, or sandbox builders. The game should be understandable in a 10-second clip; if the build-counter-replay loop cannot sell itself visually, mobile discovery will be difficult.

The Recommendation

Pursue the idea, but do not start by building the full game. Build a deterministic 3v3 naval-only auto-battle prototype centered on the inspect-build-predict-resolve-review-rematch loop.

Use 3-4 ship archetypes, such as destroyer, cruiser, battleship, and support/carrier-like ship. Use 3-5 equipment options total, such as cannon, torpedo, armor, repair, and anti-air placeholder. Each ship gets at most one weapon slot and one armor or utility slot. Avoid aircraft as independent units, platformer movement, progression, shops, campaigns, large equipment catalogs, and 5v5 battles until the core loop is proven.

The first prototype can be ugly. It should show the enemy lineup, let the player pick a small team, run a deterministic battle, show a combat log or simple replay, and explain the result clearly. The game passes the first test only if the player understands why they lost and wants to change the build for a rematch.

The One Thing to Do First

Build a one-screen deterministic 3v3 battle prototype with a combat log and immediate rematch. Give yourself one week. If you do not personally want to run "just one more battle" after tuning the first counter triangle, redesign before adding content.