All Activity

->

happened on 22/09/2026 at 12:01 Paris Time

Hi all, I'm Josue (josue on Gitea), a fairly new contributor. I want to share a project I'm about to start, get your feedback before I write code, and later hand you a fork to test and pick apart. The itch Petra is a solid executor. It gathers, builds, places, trains and fights well. But it plays the same linear game on every map, against every opponent: gather, age up, train, attack the nearest Civic Center, repeat. It doesn't use terrain, it doesn't read you, and difficulty is mostly a handicap (gather rate ×0.42 on Sandbox up to ×1.56 on Very Hard, plus some caps). Meanwhile the game ships 51 historical heroes across 15 civilizations: Hannibal, Alexander, Vercingetorix, Leonidas, Fabius Cunctator, Viriathus, Themistocles... and the AI never fights like any of them. Petra's Leonidas doesn't hold a pass. Petra's Fabius doesn't delay. Nobody builds Alesia. The idea Split the bot into hands and head. Hands stay Petra: economy, building placement, gathering, queues, trade and garrison mechanics, the actual battle. The head is new: a small strategy layer that picks a stratagem: wall the choke by the river and wait; build a trade network; garrison the towers along the enemy's approach; strike their army while it's strung out in a pass; fall back. A stratagem enters Petra through one door (Headquarters), which hands it to the manager that already knows how to execute it. The ambush and the Persian trade network go through the same channel. Who picks the stratagem? We write the doctrine, a model judges. Civ doctrine: read from the civ bonuses that already exist as data. Romans fortify, Carthage goes to the sea and to elephants, Persians trade, Spartans hold ground. Hero archetypes: 5–6 playbooks mapped to the heroes: siege builder, ambusher, hammer and anvil, hold the pass, delayer, naval raider. Stages triggered by the game, not the clock: early game follows the civ doctrine; mid game picks a hero and runs their playbook (hero dies → next hero); when heroes run out the AI goes defensive: commerce and fortification. Opponent model: is the other player rushing, booming or turtling? Where is their army heading? Are they weak at sea? This is what changes every game, and it's what Petra has never had. The model doesn't invent strategy. It answers typed questions ("hold, strike or fall back?", "rush, boom or turtle?") with probabilities. That's a classification job, which is why a small model can do it. Free and open, by design The target model is Laya (convaiinnovations/laya on Hugging Face): Apache 2.0, 421M parameters, a classifier that answers typed questions and runs on a CPU (the model card says roughly 200–450 ms per question on CPU; I haven't measured it yet). Optional download (~650 MB). Without it you get plain Petra; nothing changes. No account, no API key, no network, no cost. Multiplayer-safe: only the host runs the model, and its decisions go out as ordinary network commands. Clients don't need the model, lockstep holds, replays replay. This also sidesteps floating-point differences between platforms. One engine change is needed for it: today the server drops commands sent on behalf of another player unless cheats are on (NetServer.cpp), so the host must be allowed to send this one command type for AI-controlled slots. Single-player is unaffected. Mod first: a strategos mod that overlays only the Petra files it touches. Default Petra stays untouched. An honest note on prototyping: to learn quickly which questions matter, the very first prototype uses a hosted typed-question API (TypeSafe's Jev), called from an external Python script through the existing RL interface. That is developer scaffolding only. It will never ship and players will never need it. Both models take the same question format, so swapping to the local model doesn't change the questions. Performance: what it costs Lag is already the most common complaint, and AI plus pathfinding are big parts of it. Today every AI runs on the simulation thread, on every client, every turn. So this has to be designed not to make it worse: The in-engine part is tiny. Petra reads at most one hint per played turn and hands it to a manager it already runs. I'll measure Petra's turn time (the existing PetraBot bot (player N) profiler section) with and without the mod, and publish the numbers. The target is ≤5% overhead. The model never runs on the simulation thread. At 200–450 ms per question on a CPU, running it inline would freeze the host, and in lockstep that means everyone. So questions are asked every few seconds (not every turn), inference runs on a worker thread, and the answer comes back as a command a few turns later. The engine already has a TODO for exactly this pattern (async AI tasks that return after a fixed number of turns, in CCmpAIManager.cpp), and it lines up with the ongoing threading work (#5874). If that helper gets built, Petra's own heavy analysis could use it too. Only the host pays. Clients run nothing extra. The host pays CPU on a spare core, plus the model's memory (roughly 0.5–1.7 GB depending on quantization; I'll measure and publish it). It won't fix lag. I'm not promising a speedup. At best, stratagems replace some of Petra's per-turn strategic scans with a cached decision; that's a side effect, not the goal. How it relates to existing plans From the Gameplay Feature Status and Game Performance wiki pages: Advanced AI is listed as "partially complete" (#973, #3003). The terrain and threat reading here (choke points, the enemy's approach) overlaps #3003 ("Petra should be aware of dangerous areas"). Anything reusable goes upstream on its own. The naval raider archetype depends on #3002 (Petra using ships for warfare), so it comes later. Directional attack bonuses (flanking) aren't implemented, so "hammer and anvil" can only win through positioning and surrounding, not a flank bonus. I'll keep the playbooks honest about what the game actually rewards. "Ambush" here is AI behavior (hold a choke, strike at the right moment). It's unrelated to the concealment mechanic in #3177. Narrative and strategic campaigns were cut from Part 1. A historically flavored opponent in skirmish is a cheap way to get some of that feeling back. How I'll prove it (before anyone gets excited) MVP of the MVP: one map with clear choke points, one stratagem (ambush at the pass), one question (hold, strike or fall back). Three arms on the same seeds: vanilla Petra ambush + a dumb distance rule ("strike when their army is within N metres") ambush + the model Arm 2 vs 1 measures the stratagem; arm 3 vs 2 measures the model. Before any game, the model has to beat the rule on 50–100 hand-labeled game states. If it can't, I'll post that result here too. Roadmap Phase 0: headless Petra vs Petra harness through the RL interface; determinism checked through replays. Phase 1: the hint channel (a new strategos-hint command → Headquarters dispatch). JS only, no engine changes. Phase 2: choke points extracted from the passability grid. Phase 3: the ambush stratagem in Petra. Phases 4–5: rule arm, labeled dataset, model arm; results posted here. After that: the local model on the host, outside the simulation (optional ONNX Runtime dependency, off by default), the small network change above, then more stratagems, civ doctrines, hero playbooks, the opponent model. What I'll share, and what I'm asking I'll share: Everything in my fork, https://gitea.wildfiregames.com/josue/0ad (branch strategos/mvp1): code, match results, replays and the labeled dataset, for anyone to test, reproduce or tear apart. Fixes, as normal PRs, for the RL-interface bugs I run into along the way. #7854 and #7628 look like the first ones I'll hit. I'm asking for feedback from: Petra maintainers: is a single "stratagem hint" entry point in Headquarters acceptable, or would you prefer a different hook? Engine folks: what do you think of an optional ONNX Runtime dependency behind a build flag, off by default? Players and history nerds: which hero should fight how? Which maps have good passes? Everyone: is this a direction the project would consider upstream one day, or should it live as a mod? Either is fine with me. Disclosure: I drafted this post with help from an AI assistant (Claude). The plan and the decisions are mine, and any code will go through the normal review process.

Already ships not going through each other is an astronomical improvement (although realistically, for the more direct impacts the ram would perforate the other ship and reversing would be needed to separate them). I hope the same could be implemented for land units, making their movements more natural and their tactics more relevant.

Screencast+from+2026-09-22+02-47-35.webm Screencast+from+2026-09-22+02-49-43(1).webm Better? Also another demo about cavalry movement now : Screencast+from+2026-09-22+02-53-38.webm

Having people who can compile is important for testing many things. I can help you with that if you want to do it some day

My favorite too Hopefully it can be a good starting point to make naval battles very different then land battles. Right.

Too bad it's not possible to make a mod, unfortunately I don't have it compiled. I like what I see in the videos. The ship's movement looks really natural. The timing in the other two videos might be not 100 percent on point (on the elephant attack too late, on the catapult impact too early?). I think it's nice and I wanna encourage anyone who is able to test it

I haven't even looked at the Romans in vanilla yet

Thanks @Asher! This is great to hear! (read ) Just tried to convert some older maps from the forum (the LegendofMali worked mostly!) but some are just too old and I need to investigate how to still use them.

Seems to work , @Grautvornix

Unfortunately it's mainly modifications to the game engine itself, meaning it's not possible to wrap into a mod. But I can help out by providing a couple of demo videos for you : (I had to compress the videos) Screencast+from+2026-09-21+22-14-52.webm Screencast+from+2026-09-21+22-13-08.webm Screencast+from+2026-09-21+22-11-19.webm For testing you will need to know how to compile the game. Which makes things difficult I'm aware.

I'm excited to hear this is going forward! Is there a way you could provide a mod for easy testing purposes if it's not too much work? That would be awesome.

Sure, but as with many things, that's just an abstraction. No battle represents an actual battle, but a whole conflict, at least in a game like this, and how things are represented is always a decision to be made. A possibility could be for corpses to be robbed to get Loot, and after that for them to disappear fast. This would naturally be more safely done after the end of battles. But I don't know if this has been discussed, nor it seems a priority to me, compared with so many other things. Maybe I'd go 75% for stone and metal, and 50% for wood (or 50% 25% if from a gameplay point of view those are too much): easier to remember, takes into account stone and metal are highly reusable, and the process has to be worth it (this considering they are unbuilt/unproduced as I mentioned, which is part of the balance when compared to just deleting them). Actually, this way to get stone and metal should be an important one (at least realistically), not even Catholic Popes would eventually resist melting Roman bronze statues to make cannons, for example.

@Thalatta You are right - will remove that constraint (also use captured buildings as a quarry). Will also change the refunding stone and metal (50% each) wood (30%). While modifying the mod, I changed the "delete" function of everything: a unit being deleted (killed by its "owner") looses health over time (10s) until it dies (same es when being attacked), as well as any structure/siege/ships being deleted. Here is the latest version 1.4.0 with that logic (I know there is still a way to go). recover-resources.zip README.md

Updated to 1.3.0 (see top of this thread) Extended editing capability Analyze tab lists also treasures and relics if any Re-arranged section on the analyze and edit tabs fo rimproved readability.

Sure, but I just find it funny and it never made sense that you can earn loot in a battle in which no one survives to bring home anything.

Yes, which is why I have told you to at least look at the mod wether it be download and the structure tree, or just on github its self.

Do you also have triarii units? I guess that could be useful not to just lose spearmen.

The game does have "ruins" in many scenarios, which provide stone. The problem would be to take care of a more seamless transition between all kinds of buildings and their corresponding ruins. Maybe later on all these concepts could be unified in a coherent framework, but right now unbuilding/unproducing seems the simplest way. The game already includes Loot from killed units. Realistically, to the victor should belong the spoils, but as you say, in a game like this it's hard to determine when a battle ends, thus individual opportunism is what's accounted for.

I would find it "logistically" more "realistic" and tactically more "interesting" if destroyed buildings, no matter if self-destructed or the enemy's, would turn into "mines" containing the resources which have to be explicitly gathered and brought to one's storehouses. Also a battlefield could turn into "mines" with the "loot", like scouring the field after the battle looking for usable stuff, although it's hard to determine when a battle "ends". Would change balancing heavily against rushers/attackers in far away foreign territory though. Instead of "mines", the resources could also turn into those bonus-/treasure-item-like things, although those don't have to be brought to one's storehouses.

You could check out what we did with <SpecificName>Hastātus</SpecificName> for rome. My understanding is early on they were similar to hoplites in kits and then they evolved into swordsmen. So in p1 Hastatus = spearman and then it is replaced in p2 by Hastatus = swordsman infantry_swordsman_b.xml infantry_spearman_b.xml

Well the game already does it for "hoplites" they have a mixin that allows all hoplites to have phalanx formation. <Identity> <Classes datatype="tokens">Hoplite</Classes> <Tooltip>Hoplites can use phalanx formation</Tooltip> <History>Hoplites were the very symbol of Hellenic prestige and citizenship, armed with a spear and a large round bronze-coated shield known as an aspis. Armor was heavy, with bronze helmets and a cuirass of either bronze or linen, in addition to greaves. Hoplites fought in a tight formation called a phalanx, guarding each other with their shields while they attacked the enemy with their 2.5 meter spear or short iron sword.</History> </Identity> just add a visable class <Identity> <VisibleClasses datatype="tokens">Athenian</VisibleClasses> <Tooltip>A true citizen of Athens.</Tooltip> </Identity>

I think the point could be to keep selectable options limited and uniform among civs, while allowing for actual differentiation and evolution if wanted. I've come across this issue so many times, and one has to end anachronistically simplify things, which could indeed be solved if "a unit can represent more than just the soldiers equipped in the exact same way". For example, the Athenians had hippotoxotai (cavalry archers) substituted by prodromoi ("scouts") in the first half of the 4th c. BC. With the proposal, both could appear, depending on progress, but the icon, or just the "generic" name, could be the same, and quite common for most civs (Mounted Skirmisher could be an option), but the actual model would change (among civs and with progress), have different stats, and the "particular" unit name also be written somewhere, but the "generic" name would tell you basically its function. Other examples I came across just this last week is that Alexander's mounted skirmishers went from javelineers to archers, and his prodromoi apparently from javelineers to lancers. And I guess it would simplify dealing with things like the Roman Army. Regarding mixins, if you can irreversibly upgrade them such that they also change in the buildings that produce them, and show also their "particular" name somewhere, maybe it could work, but those working on it would have a better understanding on why it wouldn't.