Research, writing rules, and UI copy for a history game
I have a background in history, so I started contributing to Statecraft: Israel, an open-source strategy game. I researched the history with sources, turned it into game data, wrote guidance and AI skills for other contributors, and rewrote player-facing copy. So far that's 20 merged pull requests.
A game where every claim needs a source
Statecraft: Israel is a turn-based strategy game about running the country starting in 1948. It's a simulation built on real people, events, places, and political decisions. Historical claims need sources. Sensitive events need care. And the UI has to explain unfamiliar systems without dumbing down the history.
The repo was moving fast: game design, Unity code, historical content, English and Hebrew, and public releases. The problem was bigger than any one string. Contributors and AI agents needed a shared way to research, write, check, and talk about the game.
My history background helped. I know how to go from archives and official sources to conflicting accounts and open questions, and then decide what the game can actually say.
Contributor guidance first
My first big contribution didn't add anything to the game. It made the repo easier to contribute to. I added agent guidance, a writing guide, instructions for specific AI tools, reusable skills, templates, and validation scripts.
That made everything after it repeatable. Nobody has to figure out sourcing, voice, or project context again in every PR. Contributors and AI agents start from the same rules and the same trusted sources.
From research to game data
I wrote public research on the New Economic Policy, the Knesset vote on talks with Germany, the 1955 election, the 1948 war, the road to Suez, and the Sinai Campaign. I also checked the sources behind the quotes used in the trailer.
The notes don't just list facts. They separate what's verified, what's a lead, where sources disagree, and what's still unknown. So you can see the uncertainty before anything turns into game data or copy.
Then I put the research into the game: Third Knesset and 1955 election data, with source references and tests that check the new records fit the simulation.
- 1QuestionWhat's missing, historically or in the game
- 2SourcesRead, compare, and record evidence
- 3Research noteSeparate facts, conflicts, and gaps
- 4Game contentTurn reviewed material into game data
- 5Player experienceExplain choices and what happens next
Making the game easier to understand
Before writing any standards, I audited the UI as it existed. That turned into a 49-term glossary, six shared conventions, and English and Hebrew UI-writing guidance based on the actual game, not generic style advice.
Then I used it in shipped UI changes. The save warnings now say what changed and what to do next. The How to play content explains unfamiliar training terms, ties facilities to outcomes, and says when worker changes take effect. My draft Hebrew stayed marked for native review instead of being passed off as final.
I also built skills for UX writing and for sourced video scripts, with templates and checks. They make good calls easier to repeat, but source review, native-speaker review, and maintainer approval still happen in the open.
See the work
Everything is public: the original proposals, review comments, revisions, tests, and merges.
What I learned
In an open, AI-assisted project, content design is a lot more than UI strings. Here it covered which sources to trust, how contributors work, agent instructions, checks, game data, translation, and release notes.
Doing it in public also kept the lines clear. Maintainers decided what merged. Native speakers had the final say on Hebrew. Open historical questions stayed open. AI sped things up, but it was always obvious where a person still had to make the call.