Evidence at a glance
The Same Game, with a Different Identity
In a post dated October 21, 2026, Simon Willison introduces Panache, a French-language fork of Battle Drones, which he released the previous day. Panache is a real-time strategy game for mobile and browser, set in France around 1900. Willison says Battle Drones was released under the Apache 2.0 license, and describes Panache as recasting it in a Belle Époque steampunk world with an animated intro. This is not a new RTS built from scratch, but a new expression of an existing project.
The changes focus on what players notice first when they encounter the game. Panache places the original game’s units and setting inside a French historical fantasy. Its description names airships, steam-powered fardiers, armored ships, automata in kepis, and a walking fortress called Gargantua. The French names and period setting are not just explanatory labels. Together, they give the fork a recognizable identity.
The case is useful to technical teams precisely because the transformation is striking without being presented as a gameplay revolution. Willison says the changes are mostly aesthetic rather than changes to the game’s mechanics, and that the music has also received a French twist. That brings the discussion back to a distinction that is easy to blur: a game can look like a different product without becoming a different game in its strategy, controls, or rules.
A License Opens the Door, but Does Not Do the Work
Here, the Apache 2.0 license means that Battle Drones can serve as a starting point for someone else’s work. Compared with a project that can only be watched or discussed, an open license makes a fork a practical option: an adapter can develop a version around the existing project instead of waiting for the upstream team to accept a theme proposal. Panache shows that this route was actually taken.
A license provides permission, not a guarantee of adaptation quality or speed. The available account does not say exactly which code or assets Panache changed, how its development was organized, how it will handle upstream updates, or which parts of the project were easiest to replace. The mere fact that a fork appeared soon after release is not enough to conclude that Battle Drones has an architecture naturally suited to reskinning. Nor does it establish a delivery timeline other teams can reproduce.
For maintainers, that distinction has practical consequences. Clear licensing is an important first step if a project is meant to invite community adaptations, but the experience also depends on replaceable assets, understandable code boundaries, and guidance on how to run and modify the project. Panache’s description does not answer those engineering questions. It does, however, warn against treating “openly licensed” and “easy to change” as the same promise.
The Visual Evidence Is Concrete; Gameplay Evidence Is Not
The easiest evidence to verify so far is visual. The blog compares the original Battle Drones models with their Panache replacements, and calls out the change to the Goliath design. Alongside the airships, steam machinery, and walking fortress in the game’s description, these models make the adaptation concrete. The difference shows up in the appearance of individual units and in the broader sense of period and place.
Sound and the opening sequence also contribute to the new identity. Panache adds an animated intro, while the music is described as having a French style. A browser play link means the project is not limited to still images or a written pitch. For a small game fork, these player-facing details can establish a shared expectation of the world before someone enters a battle.
But visible changes are not evidence that the experience has been redesigned. The material provides no account of altered rules, combat pacing, strategic choices, or player feedback, and it includes no evaluation data. It is reasonable to say that Panache substantially reshapes presentation. It is not reasonable to infer changes to tactical depth, play time, or audience from that alone. For product judgment, acknowledging this evidence boundary is more useful than inventing a new gameplay claim on the project’s behalf.
Teams Can Learn from the Route, Not Copy the Conclusion
For a technical lead, Panache is not a validated method for engineering a fork. It is a useful adaptation example: an upstream project is released under an open license, another creator takes it as a base, then develops a distinct expression through language, theme, art, music, and an intro sequence. This route helps explain how an existing project can quickly look different. The available account does not establish the cost of each step, the collaboration model, or the technical challenges involved.
A team considering a similar adaptation should separate its evaluation into two questions. First, are others legally allowed to continue modifying the work, given the license and the conditions attached to the assets? Second, is the project technically suited to modification, given how assets are organized, where module boundaries sit, and how maintenance is handled? Panache offers a clear clue about the first question and very little evidence about the second. One successful fork cannot take the place of an engineering review of a different project.
The most dependable conclusion about Panache is narrow, and useful for that reason: an open license can let someone build on an existing game and make a cultural and visual adaptation that is quickly recognizable, but a visual refresh does not automatically amount to gameplay innovation. Maintainers who want adaptations to change the play experience must separately establish whether the code, assets, and rules leave room for that work. Readers trying to describe what changed should call Panache an RTS fork centered on a new theme