ZunTzu: A Possible Evolution of the Project
Posted: 22 Aug 2026, 09:34
Recently, I found myself unable to use the computer and yet had some free time to think. I was subsequently able to get back to using it and tried some interesting experiments. I've tried to summarize the fruits of these reflections and experiments, as they relate to ZunTzu, in the following text:
ZunTzu: A Possible Evolution of the Project
Introduction
ZunTzu was built around a simple idea—one that remains remarkably valid today: reproduce the experience of playing a board game on a computer without turning the game into a computer game.
The map remains a map. The counters remain counters. Players move them, build stacks, roll dice, draw cards, and apply the rules just as they would around a physical table. The software provides the table and the tools needed to use it, but it does not attempt to replace either the players or the game's designer.
In my view, this philosophy is one of ZunTzu's greatest strengths and should remain at the heart of any future development.
In recent years, however, advances in artificial intelligence and software development have made it possible to imagine capabilities that would have been extremely difficult—or simply impossible—when ZunTzu was originally conceived.
The idea is not to abandon ZunTzu's original philosophy, but to extend it.
The goal could be to create a platform capable not only of reproducing a paper wargame digitally, but also of adding, on an optional basis, capabilities that the physical medium cannot provide, or can provide only through cumbersome procedures.
The result could be significant: making the enormous legacy of board wargames produced over the past sixty years more accessible, playable, and open to experimentation.
1. The Fundamental Principle: Preserve the Game
The project should begin with one non-negotiable principle:
ZunTzu should not turn a board wargame into a computer game.
The historical model, rules, tables, units, sequence of play, and design choices must remain those of the original game's designer.
The software should intervene primarily where the digital medium offers possibilities unavailable on the physical tabletop, or where it can free players from mechanical tasks without taking decisions away from them.
In other words:
Automate the workload, not the decisions.
Players should, of course, be able to choose how much automation they want. ZunTzu's traditional mode of play should remain available.
2. A Modular System
The new capabilities should not form a single mandatory system.
Each Game Box could specify which modules it supports, and players could choose which ones to activate whenever appropriate.
One game might use only ZunTzu's traditional features. Another might add Fog of War. Another might use both Fog of War and logistics. A more advanced Game Box might also contain a formalized description of its rules and support a digital assistant or opponent.
This modular approach would also allow the project itself to evolve gradually.
3. Fog of War
One of the inherent limitations of traditional wargaming is the difficulty of fully representing battlefield uncertainty.
Two players sitting across the same map inevitably know a great deal that the actual commanders would not have known.
Dummy counters, blocks, inverted counters, and other mechanisms have attempted to reduce this problem, but a digital environment makes a fundamentally different solution possible.
ZunTzu could maintain a true state of the battlefield while simultaneously showing each player only the perceived state available to that player.
An enemy unit might therefore be:
completely unknown;
detected but unidentified;
partially identified;
fully identified;
known only by its last observed position.
Reconnaissance, intelligence, and concealment could thus become genuine elements of play without requiring referees or cumbersome procedures.
4. Assisted Logistics
Logistics is another example of an essential aspect of warfare that many wargames are forced to represent in simplified form.
The problem is not merely one of simulation design. A detailed logistical model can impose so much bookkeeping on the player that it interferes with the enjoyment of the game.
A digital system could instead manage the production, accumulation, transportation, and consumption of supplies automatically.
The player would continue to make the important decisions: which fronts to prioritize, where to establish depots, which offensives to support, and which units can temporarily operate with fewer resources.
The computer would handle the calculations.
The system would need to be configurable because logistics cannot be represented in the same way in tactical, operational, and strategic games.
At the operational level, actual supply points might move through road, rail, and maritime networks. At the grand-strategic level, supply might instead be represented primarily as an economic cost of military operations.
5. Command and Control
Command could also be represented through a simple, optional module without introducing systems that fundamentally alter the original games.
Units could be assigned to headquarters and receive limited penalties—for example, reduced movement—when operating beyond their command range.
It should also be possible to change the assignment of units from one headquarters to another during play, according to the rules established by the individual Game Box.
The purpose would not be to simulate every detail of the chain of command, but to introduce, at relatively low cost, an element that is often absent from traditional games.
6. Multi-State Graphic Objects
The traditional front/back counter paradigm could be expanded through multi-state objects.
A counter could have not merely two sides, but an arbitrary number of representations:
Full Strength → Reduced → Disrupted → Exhausted
or:
Operational → Damaged → Heavily Damaged → Destroyed.
The same principle could apply to fortifications, airfields, installations, markers, cards, and other graphic elements.
It should also be possible to distinguish an object's primary state from independent attributes. A unit might simultaneously be reduced, out of supply, and already moved without requiring a separate graphic image for every possible combination.
7. A New Game Box Editor
The evolution of the system would require a more powerful visual editor for creating Game Boxes.
Maps, counter sheets, cards, and other components could be imported and configured graphically, reducing the need to edit XML files manually.
As far as possible, the editor should also support importing and updating existing Game Boxes.
Preserving the enormous amount of work already contributed by the community should be a priority.
8. From the Rulebook to a Rules Model
This could become the most important innovation in the entire project.
Modern AI models are capable of analyzing complex texts and transforming information expressed in natural language into organized structures.
We can therefore imagine a Hybrid Game Rules Editor.
The Game Box creator provides the original rulebook. The AI analyzes it and proposes a structured representation covering, for example:
sequence of play;
unit types and attributes;
movement;
terrain effects;
stacking;
zones of control;
combat;
tables and modifiers;
supply;
victory conditions;
special rules and exceptions.
The AI should not be treated as infallible.
Every proposed rule should be available for review, modification, or rejection by the Game Box creator and should, whenever possible, retain a reference to the section of the original rulebook from which it was derived.
The principle should be:
AI proposes — human validates.
The result would be a Rules Model: a representation formal enough to be interpreted by the computer, yet readable enough to be reviewed and corrected by a human being.
9. AI Teacher, Assistant, and Referee
Once a Rules Model exists, one of its first applications could be implemented even before attempting to create an artificial opponent.
ZunTzu could become a teacher of the game.
A new player could ask:
“What can I do during this phase?”
or:
“Why can't this unit cross this hexside?”
and receive an answer based on the actual situation on the map and the relevant rule.
Different levels of assistance could be offered:
Observer — intervenes only when asked.
Assistant — points out possible mistakes and omissions.
Tutor — actively explains the rules during play.
Referee — checks actions and, if requested, prevents illegal ones.
This could dramatically reduce one of the greatest barriers to entry in wargaming: the need to absorb lengthy and often complex rulebooks before being able to actually play.
10. A Digital Opponent
The next step would be to use the Rules Model to create an AI Opponent.
The AI would not need to handle every mechanical detail directly.
A deterministic engine could verify legal moves, calculate paths, apply modifiers, resolve combat tables, manage supply, and perform other procedures.
Artificial intelligence could instead focus on decisions:
assessing the situation;
defining objectives;
developing a plan;
concentrating forces;
managing reserves;
evaluating risks and opportunities.
The architecture could therefore separate:
Rules Engine — what is possible
from
AI Player — what is desirable.
This distinction would reduce errors, computational costs, and dependence on external AI models.
11. An Opponent Capable of Learning
The AI could also retain a memory of previous games.
It would not necessarily be necessary to continuously retrain a neural network. It might be sufficient to record positions, decisions, strategies, and results.
The AI could then learn which strategies produced good results and which consistently failed.
If the player wished, it could also adapt to that player's individual style.
A digital opponent could therefore do more than repeat a predefined set of procedures: it could gradually improve through experience.
12. AI vs. AI
Once an AI Player exists, both sides could be placed under computer control.
This would open two very different possibilities.
The first would simply be to watch a game being played.
The AIs could play at normal or accelerated speed and, when asked, explain their decisions.
An observer could pause the game and ask:
“Why did you abandon this position?”
or:
“What alternatives did you consider?”
The second possibility would be to use the game as an experimental tool.
Hundreds or thousands of games could be run automatically to study the distribution of outcomes.
Specific conditions could also be changed and the results compared:
Strategy A → 1,000 simulations
Strategy B → 1,000 simulations
Naturally, these results would not directly represent what would have happened in historical reality.
They would represent what happens within the historical model created by the wargame designer.
That distinction is essential, but it does not make the experiment any less interesting.
13. The Wargame as a Laboratory
This capability could provide a new way to explore the enormous intellectual legacy embodied in historical wargames.
Two games covering the same campaign may produce different results because they embody different judgments about mobility, logistics, force quality, command, or victory conditions.
Running large numbers of simulations could help make these differences visible.
The wargame could therefore become not only a game, but also a tool for exploring the consequences of the assumptions built into its model.
14. A Progressive Project
A vision of this scale should not be approached by attempting to build everything at once.
The project could proceed through successive stages.
Phase 1 — ZunTzu Enhanced
Modernize the digital tabletop, introduce a new graphic editor, Fog of War, multi-state objects, and initial optional features.
Phase 2 — ZunTzu Rules
Define the Rules Model, build the Hybrid Rules Editor, and introduce AI-assisted rulebook import.
Phase 3 — ZunTzu Assistant
Develop the Teacher, Assistant, and Referee functions, together with automation of the most cumbersome procedures.
Phase 4 — ZunTzu AI
Develop the digital opponent and game-memory capabilities.
Phase 5 — ZunTzu Simulation
Introduce AI-vs.-AI play, multiple simulations, replays, statistical analysis, and counterfactual experimentation.
Each phase should produce something useful in its own right. The success of the project should therefore not depend on immediately reaching the final stage.
15. Before Building: Prove the Concept
Before undertaking a major software project, it would be wise to build a limited proof of concept.
A wargame of moderate complexity could be selected, its rulebook provided to the AI, and an experiment conducted to determine whether a Rules Model can be created—with a reasonable amount of human intervention—that correctly represents at least:
movement;
terrain;
stacking;
zones of control;
combat;
sequence of play;
victory conditions.
The first objective should not be to create an AI capable of winning.
It should be much more modest and, at the same time, decisive:
Can a machine understand a rulebook written for human beings well enough to complete a legal game through a human-validated model of those rules?
If this experiment succeeds, one of the greatest uncertainties surrounding the entire project will have been resolved.
16. Why Start From ZunTzu?
A completely new system could, of course, be built.
But ZunTzu possesses something that would be difficult to recreate: a philosophy exceptionally well suited to this project, an existing and functional platform, a community of users, and, above all, a library of Game Boxes built over many years.
The goal should therefore not be to replace ZunTzu.
If technically possible, and if the community considers it worthwhile, the goal should be to continue and extend its original idea.
Compatibility with the existing legacy should be one of the project's primary objectives.
17. An Invitation to the Community
What has been described here is not yet a defined software project.
It is a proposal for discussion.
Some of these features are relatively straightforward. Others will require research, experimentation, and probably solutions that we cannot yet foresee.
Before writing large amounts of code, we need to determine whether the community considers this direction desirable, which features should have priority, and what skills and experience can be brought together.
Programmers would obviously be needed, but not programmers alone.
We would need wargame designers, Game Box creators, experienced players, interface designers, people familiar with artificial intelligence, and, above all, people willing to experiment and identify the cases in which the model fails.
It would be particularly valuable to discuss these ideas with Jérôme, because any evolution of ZunTzu should begin with an understanding of the design choices and philosophy that shaped the original program.
Conclusion
For decades, board wargaming has produced thousands of models of historical conflict, many of them of extraordinary depth.
Many are difficult to play today not because they have lost their value, but for very practical reasons: they require space, time, an available opponent, and the effort required to learn complex rules.
A new generation of ZunTzu could address all of these limitations at once:
the digital tabletop removes the problem of space;
the AI Opponent addresses the problem of finding an opponent;
the AI Teacher lowers the barrier to learning;
automation reduces the burden of procedures and bookkeeping;
Fog of War introduces something a shared physical tabletop cannot fully represent;
AI-vs.-AI simulation makes it possible to explore the model in entirely new ways.
Technology should not replace the wargame.
Instead, it could allow the wargame to finally do some of the things its designers have always wanted it to do, but which the physical tabletop, cardboard counters, and the players' available time made impractical.
If this idea proves technically feasible—and that is precisely what needs to be tested—it could offer ZunTzu not merely a new version, but a new reason to exist.
And it could offer the wargaming community something even more important: a way to carry the enormous legacy it has built in the past into the future.
ZunTzu: A Possible Evolution of the Project
Introduction
ZunTzu was built around a simple idea—one that remains remarkably valid today: reproduce the experience of playing a board game on a computer without turning the game into a computer game.
The map remains a map. The counters remain counters. Players move them, build stacks, roll dice, draw cards, and apply the rules just as they would around a physical table. The software provides the table and the tools needed to use it, but it does not attempt to replace either the players or the game's designer.
In my view, this philosophy is one of ZunTzu's greatest strengths and should remain at the heart of any future development.
In recent years, however, advances in artificial intelligence and software development have made it possible to imagine capabilities that would have been extremely difficult—or simply impossible—when ZunTzu was originally conceived.
The idea is not to abandon ZunTzu's original philosophy, but to extend it.
The goal could be to create a platform capable not only of reproducing a paper wargame digitally, but also of adding, on an optional basis, capabilities that the physical medium cannot provide, or can provide only through cumbersome procedures.
The result could be significant: making the enormous legacy of board wargames produced over the past sixty years more accessible, playable, and open to experimentation.
1. The Fundamental Principle: Preserve the Game
The project should begin with one non-negotiable principle:
ZunTzu should not turn a board wargame into a computer game.
The historical model, rules, tables, units, sequence of play, and design choices must remain those of the original game's designer.
The software should intervene primarily where the digital medium offers possibilities unavailable on the physical tabletop, or where it can free players from mechanical tasks without taking decisions away from them.
In other words:
Automate the workload, not the decisions.
Players should, of course, be able to choose how much automation they want. ZunTzu's traditional mode of play should remain available.
2. A Modular System
The new capabilities should not form a single mandatory system.
Each Game Box could specify which modules it supports, and players could choose which ones to activate whenever appropriate.
One game might use only ZunTzu's traditional features. Another might add Fog of War. Another might use both Fog of War and logistics. A more advanced Game Box might also contain a formalized description of its rules and support a digital assistant or opponent.
This modular approach would also allow the project itself to evolve gradually.
3. Fog of War
One of the inherent limitations of traditional wargaming is the difficulty of fully representing battlefield uncertainty.
Two players sitting across the same map inevitably know a great deal that the actual commanders would not have known.
Dummy counters, blocks, inverted counters, and other mechanisms have attempted to reduce this problem, but a digital environment makes a fundamentally different solution possible.
ZunTzu could maintain a true state of the battlefield while simultaneously showing each player only the perceived state available to that player.
An enemy unit might therefore be:
completely unknown;
detected but unidentified;
partially identified;
fully identified;
known only by its last observed position.
Reconnaissance, intelligence, and concealment could thus become genuine elements of play without requiring referees or cumbersome procedures.
4. Assisted Logistics
Logistics is another example of an essential aspect of warfare that many wargames are forced to represent in simplified form.
The problem is not merely one of simulation design. A detailed logistical model can impose so much bookkeeping on the player that it interferes with the enjoyment of the game.
A digital system could instead manage the production, accumulation, transportation, and consumption of supplies automatically.
The player would continue to make the important decisions: which fronts to prioritize, where to establish depots, which offensives to support, and which units can temporarily operate with fewer resources.
The computer would handle the calculations.
The system would need to be configurable because logistics cannot be represented in the same way in tactical, operational, and strategic games.
At the operational level, actual supply points might move through road, rail, and maritime networks. At the grand-strategic level, supply might instead be represented primarily as an economic cost of military operations.
5. Command and Control
Command could also be represented through a simple, optional module without introducing systems that fundamentally alter the original games.
Units could be assigned to headquarters and receive limited penalties—for example, reduced movement—when operating beyond their command range.
It should also be possible to change the assignment of units from one headquarters to another during play, according to the rules established by the individual Game Box.
The purpose would not be to simulate every detail of the chain of command, but to introduce, at relatively low cost, an element that is often absent from traditional games.
6. Multi-State Graphic Objects
The traditional front/back counter paradigm could be expanded through multi-state objects.
A counter could have not merely two sides, but an arbitrary number of representations:
Full Strength → Reduced → Disrupted → Exhausted
or:
Operational → Damaged → Heavily Damaged → Destroyed.
The same principle could apply to fortifications, airfields, installations, markers, cards, and other graphic elements.
It should also be possible to distinguish an object's primary state from independent attributes. A unit might simultaneously be reduced, out of supply, and already moved without requiring a separate graphic image for every possible combination.
7. A New Game Box Editor
The evolution of the system would require a more powerful visual editor for creating Game Boxes.
Maps, counter sheets, cards, and other components could be imported and configured graphically, reducing the need to edit XML files manually.
As far as possible, the editor should also support importing and updating existing Game Boxes.
Preserving the enormous amount of work already contributed by the community should be a priority.
8. From the Rulebook to a Rules Model
This could become the most important innovation in the entire project.
Modern AI models are capable of analyzing complex texts and transforming information expressed in natural language into organized structures.
We can therefore imagine a Hybrid Game Rules Editor.
The Game Box creator provides the original rulebook. The AI analyzes it and proposes a structured representation covering, for example:
sequence of play;
unit types and attributes;
movement;
terrain effects;
stacking;
zones of control;
combat;
tables and modifiers;
supply;
victory conditions;
special rules and exceptions.
The AI should not be treated as infallible.
Every proposed rule should be available for review, modification, or rejection by the Game Box creator and should, whenever possible, retain a reference to the section of the original rulebook from which it was derived.
The principle should be:
AI proposes — human validates.
The result would be a Rules Model: a representation formal enough to be interpreted by the computer, yet readable enough to be reviewed and corrected by a human being.
9. AI Teacher, Assistant, and Referee
Once a Rules Model exists, one of its first applications could be implemented even before attempting to create an artificial opponent.
ZunTzu could become a teacher of the game.
A new player could ask:
“What can I do during this phase?”
or:
“Why can't this unit cross this hexside?”
and receive an answer based on the actual situation on the map and the relevant rule.
Different levels of assistance could be offered:
Observer — intervenes only when asked.
Assistant — points out possible mistakes and omissions.
Tutor — actively explains the rules during play.
Referee — checks actions and, if requested, prevents illegal ones.
This could dramatically reduce one of the greatest barriers to entry in wargaming: the need to absorb lengthy and often complex rulebooks before being able to actually play.
10. A Digital Opponent
The next step would be to use the Rules Model to create an AI Opponent.
The AI would not need to handle every mechanical detail directly.
A deterministic engine could verify legal moves, calculate paths, apply modifiers, resolve combat tables, manage supply, and perform other procedures.
Artificial intelligence could instead focus on decisions:
assessing the situation;
defining objectives;
developing a plan;
concentrating forces;
managing reserves;
evaluating risks and opportunities.
The architecture could therefore separate:
Rules Engine — what is possible
from
AI Player — what is desirable.
This distinction would reduce errors, computational costs, and dependence on external AI models.
11. An Opponent Capable of Learning
The AI could also retain a memory of previous games.
It would not necessarily be necessary to continuously retrain a neural network. It might be sufficient to record positions, decisions, strategies, and results.
The AI could then learn which strategies produced good results and which consistently failed.
If the player wished, it could also adapt to that player's individual style.
A digital opponent could therefore do more than repeat a predefined set of procedures: it could gradually improve through experience.
12. AI vs. AI
Once an AI Player exists, both sides could be placed under computer control.
This would open two very different possibilities.
The first would simply be to watch a game being played.
The AIs could play at normal or accelerated speed and, when asked, explain their decisions.
An observer could pause the game and ask:
“Why did you abandon this position?”
or:
“What alternatives did you consider?”
The second possibility would be to use the game as an experimental tool.
Hundreds or thousands of games could be run automatically to study the distribution of outcomes.
Specific conditions could also be changed and the results compared:
Strategy A → 1,000 simulations
Strategy B → 1,000 simulations
Naturally, these results would not directly represent what would have happened in historical reality.
They would represent what happens within the historical model created by the wargame designer.
That distinction is essential, but it does not make the experiment any less interesting.
13. The Wargame as a Laboratory
This capability could provide a new way to explore the enormous intellectual legacy embodied in historical wargames.
Two games covering the same campaign may produce different results because they embody different judgments about mobility, logistics, force quality, command, or victory conditions.
Running large numbers of simulations could help make these differences visible.
The wargame could therefore become not only a game, but also a tool for exploring the consequences of the assumptions built into its model.
14. A Progressive Project
A vision of this scale should not be approached by attempting to build everything at once.
The project could proceed through successive stages.
Phase 1 — ZunTzu Enhanced
Modernize the digital tabletop, introduce a new graphic editor, Fog of War, multi-state objects, and initial optional features.
Phase 2 — ZunTzu Rules
Define the Rules Model, build the Hybrid Rules Editor, and introduce AI-assisted rulebook import.
Phase 3 — ZunTzu Assistant
Develop the Teacher, Assistant, and Referee functions, together with automation of the most cumbersome procedures.
Phase 4 — ZunTzu AI
Develop the digital opponent and game-memory capabilities.
Phase 5 — ZunTzu Simulation
Introduce AI-vs.-AI play, multiple simulations, replays, statistical analysis, and counterfactual experimentation.
Each phase should produce something useful in its own right. The success of the project should therefore not depend on immediately reaching the final stage.
15. Before Building: Prove the Concept
Before undertaking a major software project, it would be wise to build a limited proof of concept.
A wargame of moderate complexity could be selected, its rulebook provided to the AI, and an experiment conducted to determine whether a Rules Model can be created—with a reasonable amount of human intervention—that correctly represents at least:
movement;
terrain;
stacking;
zones of control;
combat;
sequence of play;
victory conditions.
The first objective should not be to create an AI capable of winning.
It should be much more modest and, at the same time, decisive:
Can a machine understand a rulebook written for human beings well enough to complete a legal game through a human-validated model of those rules?
If this experiment succeeds, one of the greatest uncertainties surrounding the entire project will have been resolved.
16. Why Start From ZunTzu?
A completely new system could, of course, be built.
But ZunTzu possesses something that would be difficult to recreate: a philosophy exceptionally well suited to this project, an existing and functional platform, a community of users, and, above all, a library of Game Boxes built over many years.
The goal should therefore not be to replace ZunTzu.
If technically possible, and if the community considers it worthwhile, the goal should be to continue and extend its original idea.
Compatibility with the existing legacy should be one of the project's primary objectives.
17. An Invitation to the Community
What has been described here is not yet a defined software project.
It is a proposal for discussion.
Some of these features are relatively straightforward. Others will require research, experimentation, and probably solutions that we cannot yet foresee.
Before writing large amounts of code, we need to determine whether the community considers this direction desirable, which features should have priority, and what skills and experience can be brought together.
Programmers would obviously be needed, but not programmers alone.
We would need wargame designers, Game Box creators, experienced players, interface designers, people familiar with artificial intelligence, and, above all, people willing to experiment and identify the cases in which the model fails.
It would be particularly valuable to discuss these ideas with Jérôme, because any evolution of ZunTzu should begin with an understanding of the design choices and philosophy that shaped the original program.
Conclusion
For decades, board wargaming has produced thousands of models of historical conflict, many of them of extraordinary depth.
Many are difficult to play today not because they have lost their value, but for very practical reasons: they require space, time, an available opponent, and the effort required to learn complex rules.
A new generation of ZunTzu could address all of these limitations at once:
the digital tabletop removes the problem of space;
the AI Opponent addresses the problem of finding an opponent;
the AI Teacher lowers the barrier to learning;
automation reduces the burden of procedures and bookkeeping;
Fog of War introduces something a shared physical tabletop cannot fully represent;
AI-vs.-AI simulation makes it possible to explore the model in entirely new ways.
Technology should not replace the wargame.
Instead, it could allow the wargame to finally do some of the things its designers have always wanted it to do, but which the physical tabletop, cardboard counters, and the players' available time made impractical.
If this idea proves technically feasible—and that is precisely what needs to be tested—it could offer ZunTzu not merely a new version, but a new reason to exist.
And it could offer the wargaming community something even more important: a way to carry the enormous legacy it has built in the past into the future.
