Player Research and Engineering for a Strategy Game

Before changing the battle turn system, I checked how players rated each option in comparable games.

Result: a matched study of 31 games shaped the battle turn decision, and a pathfinding fix I directed made a benchmark about 81% faster. After a false speedup, I adopted a rule that times every change against its starting version, and a week of changes measured that way made the simulated game day about five times faster.

The project

I work on an in-development historical strategy game planned for commercial release. My part covers two things: the player and market research behind design decisions, and leading the engineering, which a team of AI coding agents builds under my direction. The game's details stay private until launch, so this page covers the methods.

Should the battle turn system change?

Strategy games resolve battles in three main ways. Each side takes a full turn, units alternate one at a time, or both sides plan at once and resolve together. I wanted to know how players rated each approach before committing to one, and I asked for a matched comparison.

Research agents gathered Steam review scores, SteamSpy owner estimates, SteamDB peak players, and BoardGameGeek ratings for 31 games. The raw medians favored alternating activation at 88.1% positive, against 84.7% for full side turns and 82.0% for simultaneous turns. A few blockbusters drove that gap.

So I limited the comparison to games with 2,000 to 14,000 reviews. Alternating still led at 87.6%, with simultaneous turns at 83.2% and side turns at 81.0%. Widening the band to 35,000 reviews kept the same order. With three or four games per group, genre and turn system can't be fully separated, so I read the gap as a direction. About 185 player comments, coded into praise and complaint by theme, filled in why.

The decision: drop simultaneous turns, since their appeal depends on a human opponent, and build a prototype of alternating activation so play can settle it.

The Steam market study later rechecked these numbers from the API. Steam's positive share matched this desk study within 1.0 point for all 22 turn-based titles.

What gets a Reddit post noticed

I studied about 45 posts from three solo developers of historical strategy games to see which ones gained traction.

A question in the title drew 24 comments.
Naming a game people already know drew 89 upvotes.
Leading with what the viewer sees beat a brand-first title, 69 upvotes to 40.
The same clip drew 69 upvotes framed as a small story and 2 framed as a feature note.
About one post a week per subreddit worked best.

Forty-five posts is a small sample, and the write-up says so. I treat these as working rules to test.

Directing the engineering

I lead the engineering through AI coding agents. I designed the workflow they run under, set concrete goals so the work doesn't drift into long detours, and step in when they go wrong.

The workflow. Work is classed by uncertainty, blast radius, and reversibility. Separate agents research, plan, build, and review. No more than four run at once, and each piece of work gets at most two review passes. Progress ledgers survive context compaction, and MCP integrations connect the agents to the game editor, Blender, and a map composer I conceived. I told the lead agent to "decide as CTO, record decisions," and it logged about 288 numbered decisions in under two weeks.

Fixing slow pathfinding. I caught the agents' pathfinding searching the entire route graph on every query. More threads wouldn't fix it, and I told them why: "Thread count cannot fix 140 queries at 1.3 s each." The agents replaced per-pair shortest paths with one bounded breadth-first search per army and added pruning. A 23-query benchmark fell from 39,338 ms to 7,628 ms, about 81% faster, and capital selection dropped from 10.72 s to 2.09 s.

A speedup that wasn't. I set targets for the simulated game day with every AI faction active: from a start of about 8 seconds, 1.0 second to accept, 0.5 as the goal, 0.2 as the stretch. One attempt was a stage that ran AI decisions in parallel. It passed every correctness check and review, and it made the day slower, from 7.9 to 21.9 seconds. A fix brought that down to 13.0 seconds, still about 65% slower than the original. Later comparisons were made against an old checkpoint instead of the version the change started from, so for about 31 hours the loss read as a gain. On one thread the stage cost 28.7 to 32.5 seconds a day against 7.9 for the original, and all 14 cores made it only about 1.25 times faster, because it copied the whole campaign state for every decision and started every cache empty. I started the root-cause analysis, had the agents audit their own session threads, and adopted the rules that came out of it. Every speed change is timed against the version it started from, on two fixed seeds, must leave the game in an identical end state, and is not merged if slower. A parallel version proves its one-thread cost against the original before it gets more threads, worker threads share read-only input and keep the original's caches, and long test suites run once, on the final version. It's the lesson an A/B test teaches: a comparison is only as good as its control.

Making the day faster, measured that way. The next change, moving the AI's development forecast into native C++, cut the day 34 to 36%, from about 8.0 to 5.1 seconds. Other changes over the same stretch built the AI's shared data once per day instead of once per faction, moved the AI's economic ledger into native C++ as well, finalized each day's state once, and shared unchanged data between one day and the next. My own idea was to review each family of AI decisions on its own cadence of 1, 7, 28, or 84 days, with events waking a family early. That was 11.5% faster on its own, and I accepted its three-year outcomes after reading them: more treasury held and about a fifth fewer treaties. Campaign route search then became the first piece moved into a native C++ module under an architecture I set: the script layer orchestrates, and native code owns the data and does the heavy work in batch calls, the way Python works with NumPy. The agent raised compile time as the cost of moving more of the simulation native. I overruled that from experience: compile time is small when changes are large, display changes sit outside the native code, and AI changes earn more from a faster runtime than they lose to compiling. In under a week the day went from about 8 seconds to 1.47 and 1.57 seconds on the two test seeds, and 272 and 293 ms without the AI. The first and last readings came under different machine conditions, so "about five times faster" is a rough figure. Each step along the way was timed against its own start.

Cutting slow tests. I challenged the long test runs: "do we need these long probes?" The gates moved to targeted test suites with a 600-second watchdog. A process review a week earlier had found that 18 of 22 tactical AI test fixtures passed without exercising the behavior they claimed to test.

A fair test for generated art. For the 2D art, I set a blinded protocol: a brief frozen before launch, A/B review with a sealed answer key, ties going to the current best, and stop rules fixed in advance. Across 17 waves and 21 art slots, only 2 challengers beat the incumbent.