Leaderboard

The first helicopter has entered full operational status. It features a full range of unique flight capabilities, such as lateral tilting and short range backward movement, and gains altitude during long distance flight. It is also capable of firing rockets and anti tank missiles, and deploying heat decoys. Recording 2026-09-26 005347.mp4

Hello everyone! I’m here to share some more news about my mod, World Rising! Over the past few days, I’ve had to spend quite a bit of time fixing several meshes from the 3D models I created, mainly to make sure the lighting works properly across all objects. There are still a few meshes that need some adjustments, and this work ended up changing my plans a little for the next few days. Since I’m developing the project on my own, I’m trying to follow an approach that I consider very important: create, test, and optimize at the same time. Instead of leaving all the problems to be fixed at the end, I prefer to make some progress, fix what needs to be fixed, study the results, and constantly evaluate what can be improved. One of my biggest priorities is making sure that World Rising remains lightweight, visually appealing, and runs smoothly, even with thousands of assets being rendered on the map in real time. Because of this, I’m reviewing models, meshes, textures, and other elements to find the best possible balance between visual quality and performance. It’s a huge challenge! Especially when working alone on a project of this scale, but we’re moving in the right direction, and little by little, World Rising is taking the shape I originally envisioned. For now, here are a few images from the development process. I’ll be sharing more news and updates soon! Feel free to comment, share your opinions, criticism, and suggestions, and take part in the development. Your feedback is always very welcome! And a special thanks to Stan, who pointed out the mesh issue and helped me notice an important problem that needed to be fixed. Thank you to everyone who continues to follow and support World Rising!

I needed dedicated server for 0ad and I built it: Veredus is an unofficial dedicated server for 0 A.D. and it's out now. No player hosts the match, so it keeps going when someone leaves or has a bad connection(with a timeout). Dropped players get their slot back when they reconnect, and matches carry on after a server restart or killed. Players join with vanilla 0.28 game. An optional companion, the "sidecar", runs AI opponents on the server, lets players rejoin without asking state from player, and records results and replays. The server is free and open source. Code and setup instructions here: https://github.com/victorcrimea/veredus I only have Linux, so I'd really like to hear from anyone who can try it on Windows or macOS: does the server start, can players connect, and does the sidecar build and run? Please post bug reports, suggestions and questions here or as a GitHub issue. Veredus is not affiliated with Wildfire Games. Basically any feedback is welcome.

Turning a fairy tale into reality, humanity has taken to the skies in 0 A.D. (apologies if someone has already done this). Drawing inspiration from World in Conflict, I am adding more realistic helicopter movement, though the takeoff/landing key is my own idea, as World in Conflict required rappelling to disembark. Recording 2026-09-24 231717.mp4

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 https://gitea.wildfiregames.com/josue/0ad/src/branch/strategos/mvp1/docs/strategos 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.

Infantry fighting vehicle on the move A quick update on The Great War mod regarding tracked combat vehicles: as someone who values detail, I prioritize realistic movement. The models now kick up dust and smoke from the ground, leave track marks on the terrain, and of course, feature a powerful, aggressive engine roar. Recording 2026-09-23 144500.mp4

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.

Hello everyone! I’m back with more news and new images from World Rising! =D Over the past few weeks, I’ve made several important improvements to the project. New buildings have been added, new technologies have been implemented and tested, and everything is working very well so far. I also rebuilt all the meshes that needed corrections to ensure that the shaders and lighting work properly. It was a lot of work, but the visual results have improved significantly! Another big addition is the creation of the Yayoi hero Katsuro. With him, we now have 4 of the 5 heroes planned for the ancient Japanese culture, with one hero representing each Era. The 4th Era — the Bronze Age — is now established and working, making the civilization’s progression increasingly complete. I’ve also continued working on the Yayoi economy. Yayoi granaries now produce both food and fibers used for clothing, currently represented by the leather resource in the game. The dynamic weather system has also received some adjustments. Weather events now occur at longer intervals, while rainfall lasts longer. This makes weather changes feel less frequent and more natural, while giving each event a stronger presence during gameplay. World Rising continues to grow step by step. There is still a lot of work ahead, but every new building, technology, character, and system is helping the project develop its own identity. I hope you enjoy the new images! Please keep commenting and sharing your opinions, criticism, and suggestions. Your feedback and participation are always welcome! Thank you all for supporting World Rising!

Also worth noting that if you scale everything to a factor two, your map is twice as big

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

A mod designed to make the most of 0ad, with many battles with automatic weapons, maps on alien planets, ships and drones. I've had it for a while now but I intend to make it playable in alpha 27. It is only possible thanks to the beautiful animations created by @Alexandermb . I use a lot of AI generated images (https://www.imagine.art/). In addition to ideas and adaptations, especially in mods Delenda Est and Hyrule Conquest.

Special attacks with bombers and nuclear missiles: (slowness is from the capture on the notebook, FPS in the top corner of the video). Gravação de tela de 2026-09-26 01-42-06.webm

I’ve looked at your profile, and I realize that I, an amateur, have been giving instructions to an expert.

Noted, yes after some playtesting also with @Effervescent it was clear that we should make infantry have more agile movements, which is mainly suppressing restrictions on turning. We also had interesting talks about using the new parameter "MaxAngle" to have ranged units in general start the attack prepareTime/animation while turning (they start drawing an arrow while they turn, so it makes micro interesting). I think i did increase the value of pushing a tiny bit, but maybe before reverting I would try to see if you think it's better with the lowered Inertia effects (they are more agile so maybe it would fix it for you). I guess I did set a "stagger recovery rate" very low in the templates So you are right. I didn't, but I should have saw it come. Yes this is one bug that is from this PR obviously, I can address that. The other ones I'm not too sure, the woodcutters getting stuck happens a lot to me in MP. Thank you so much for the feedbacks! I have a much clearer idea of what this PR needs now. Mostly tweaking the templates and fixing the big boys club dances.

@Atrik! I’ve been testing the PR. I haven’t noticed any functional bugs. Everything I’m noticing is related to tweaks for the units values. So I’ll share my impressions of their current behavior. In general, the units feel more “heavy” to me. I find it somewhat appealing, but I think it will all depend on the fine-tuning that’s done. I think some degree of overlapping could also be fine to make unit bumping feel less noticeable. I don’t think civilians and infantry should have such a gradual rotation, at least not when they’re moving individually. I hope I can explain what I mean. I don’t know anything about crowd movement, but I have the feeling that their turns should become wider as the size of the group increases, with this being more of a consequence of them bumping into each other. Maybe civilians could also be allowed to overlap with each other a little more. I’m sharing a few videos showing different situations. Unfortunately, we still can’t test multiplayer, so I did my best to simulate a battle. Woodcutting. Notice the woman on the left who gets stuck and can’t reach her destination, around the end of the video. I’ve never tested this with the vanilla version, so I can’t really compare whether this happens there as well.. Mining brothers: Here I get the feeling that the elephants are trampling the horses. Some horses appear to be standing still while being pushed around, or simply remain stationary, as if they can’t find a path to their targets. The trampling looks interesting, but the horses remain stuck for too long. And the elephants seem to have this infinite pushing loop. I assume you’ve already noticed it. Chopping Wood.mp4

Technically speaking, this mod focuses on the 21st century, the present day, though it prioritizes gameplay over historical accuracy or realism. The factions are fictional, albeit inspired by real world counterparts. If this mod proves successful, I plan to develop subsequent mods set in the gunpowder era. While those would be technically much simpler than this one, I would hope to incorporate historical consultation for them.

0 A.D. 2026-09-23 01-14-26 - Trim - Trim.mp4

A small update to the interface. 0 A.D. 2026-09-23 01-14-26 - Trim.mp4

You can see how "solid effect" of "stiffness" impact the boats in the video. You get super cool effects when there are a few ones, but a lot of them result in them taking a lot of time to settle. It's fine for boats as you rarely think of crowds of boats, and I just made a scene for this in the video to show that it works, and still look good for them. But if you have a crowd of infantry constantly wiggling and taking forever to settle, this would look very bad. Hence the spring. Inertia and pushing aren't the same thing. But for navigating on open terrain, this wouldn't change much. However if you try to funnel "solid" physical bodies into a choke-point, they obviously take a while more to achieve the same movement. So if ever we wanted to make cavalry "solid bodies", with this PR it's only just one tweak in their template. But because big crowds of them cost more to simulate and that moving them around take longer if they are in high number, it should be accompanied by an increase of cost/population for example. The pros are that they will have much more realistic charge effects, like you see with elephants, but cavalry have less contact area and are moving much faster, the physic outcome would be different too (like a cavalry can trow fewer infantry units away but at higher velocity). So this is just a balancing change, out of scope. Even without proper "charge", -so just using the old pushing pretty much as it was, the inertia improves physics for cavalry fighting at no additional cost. The cavalry can push away other spread units thanks to it's superior weight, and also push its target by a little - even if ideally it would be more, and the cavalry would be smart enough to take more advantage of it instead of stopping once in front of it's target. Screencast from 2026-09-22 18-44-41.webm

Then it's bad https://gitea.wildfiregames.com/0ad/0ad/wiki/EnglishStyleGuide

Having played around with Atlas and a post processor/analyzer/converter post Atlas (https://wildfiregames.com/forum/topic/169808-map-making-support-and-conversion-tool-post-atlas/?do=findComment&comment=762301 ) I thought it might be useful to add a few capabilities to Atlas without actually changing it. My initial concern was the difficulty (for my clumsy attempts of editing) to place walls with segments and turrets properly algined and without gaps. Hence, I started defining a tool that replicates the in-game way of placing walls by dragging and connecting rather than placing individual elements. For this the tool would manipulate the Atlas-generated xml-file and hand it afterwards back to atlas for further editing and final touch. Well, implementing this handover in both directions, Atlas --> tool and tool--> Atlas, certainly allows manipulating other simple things in a kind of co-editing mechanism. Important to note: ATLAS is and will remain the primary tool mastering all the map creation complexity. My tool tries to help offering a few workflows only preserving Atlas' role as the master editor. So currently the workflow can be like this: You define a maps basic parameters, game characteristics, player characteristics etc. - either in Atlas or the new tool (in this case with a handover to Atlas). Then Atlas is used to sculpt the terrain and place landscape items. The tool can read the xml file output by Atlas and visualize both in 2D plan view and in simplified 3D what has been placed where and for which player, listing all elements. If desired, a wall or palisade can be drawn like in the game and gates can be added by simple selection of a wall segment. The tool also allows placing enitites of all kinds selected from a list with little images representing what the entity looks like in game. The game's rules where entities can actually be placed are explicitly applied (e.g. no hous in the ocean or on a cliff slope). Handover back to Atlas for modification/manipulation finalizing, whatever. If finalized, it is certainly possibly to use post-Atlas tool to verify a map works Oh, and finally, I had to find a name for the tool (used to be "prep-Atlas" similar to "post-Atlas"), but then I thought I should be a bit more creative. With a probably a bit to much creativity enhancer made from grapes, I cam up with this silly story: A character in history used and improved historical maps and related all to the legendary King Atlas of Mauretania, said to have been a geographer and astronomer (potentially related/referring to the Greek mythodologic Titan Atlas). This occured many centuries later (in the 1590s) when the Flemish cartographer Gerard de Kremer (Merchant), latinized Gerardus Mercator, came up with a map collection in a book named "Atlas" referring to that King and/or Titan. Our tool also came much later than the Atlas tool and uses its maps and tries to improve a bit. Strictly speaking the name "Mercator" in this context is not at all related to the 0AD timeframe, but, hey, the game calls a roman trader rightfully "Mercator" as well) So here is the first BETA version for people willing to test: mercator-0.9.0.zip README.md CHANGELOG.md

Hi, Let me start by expressing how much I love the unit motions. The inertia aspect bring more depth to the units, and with the newly tweaked values, it's a good balance between realism and unit control ability (also micro). I especially love the turns cavalry make. that really gives the vibes of medieval cavalry going for raids. The unit animation sync needs to be handled though, so that the stop-animation syncs with units stopping, by that's a minor thing. As for the elephants. O.M.G. That thing is so fun to play. Elephants pushing and trampling units is so fun, and I wouldn't be surprised if this changes births a few elephant lovers in-game. The infantry units having different values from cavs and eles makes the most sense to me, tbh. It gives infantry agility, and tighter controls which their qudra-pedal brothers can only dream of. I'll try to recruit more testers for this and see how people feel about this in general, but I for one really love this and hope this gets pushed in the next alpha. Cheers.

I should make an art task for more siege tower models. That way folks can post up some references. If we're going to go through the trouble of creating more siege tower models (which we should), then perhaps each civ's siege tower should look somewhat unique. I also agree to giving it to move civs. We need to make them more useful and less buggy, but that doesn't mean they can't have them yet.

Turns out it was true they actually existed... I love this work, @Eilat. It looks really good!! The dust blowing around when the helicopter takes off is a great detail. Looking forward to seeing the next updates!

In the meantime would it be acceptable for WFG to host one of those dedicated servers ? I'll see if I can try on macOS. Some ideas on top of my head: - Would be nice to have an ansible or docker setup for it so one can create it with all the needed dependencies. - Would also be nice since I assume you set up your own lobby to test to provide a mod that allows switching lobbies. It will split the player base though.

Awesome work @victorcrimea! However, everybody please keep in mind, that we don't allow third-party bots in the official multiplayer lobby, so to use this dedicated server, please either use the direct connection option or a separately hosted multiplayer lobby. Ultimately it'd be great to have such functionality integrated into 0ad itself, so players don't have to go through additional hops to use it.

That’s a thing of beauty; I can't wait to use some air-to-air missiles against those Black Hawks.

The ship movement is really nice, and the inertia makes the collisions feel much more natural. It’s a shame it can’t be tested as a mod, but the demo videos still give a good idea of the changes. Hope more people can compile it and give feedback on the PR.

Recording 2026-09-24 095108.mp4

This seems interesting! Another thought I had when watching the elephant videos (probably unrelated): All soldiers going back to idle at the same time when the elephant dies looks so abruptly, maybe there could be some randomness (like some cheering, some idle) or random delay.

They seem to have acquired them from Romans (possibly built their own with Roman engineers). https://penelope.uchicago.edu/thayer/e/roman/texts/cassius_dio/67*.html https://penelope.uchicago.edu/Thayer/E/Roman/Texts/Cassius_Dio/68*.html#9.5 Surviving evidence seems to point at bolt shooting light artillery rather than stone throwers. Page 86: https://whc.unesco.org/document/204934

Thanks, yes it's better. Calvary movement looks smooth too. In the catapult video those 2 guys walking in circles looks strange, but I guess it has nothing to do with the question here. Yes I want to do that some day when I have more time, thanks for the offer, I will get back to you

Though this is a reply to LeJardind, @Eilat I'll throw some advice in here as well. Maps too small - Not really, the size limit is only for vanilla and can (has been) removed, as Eilat said. Drones - Flying units are doable, if sometimes hacky. Recon is really just a large vision range, and suicide can be accomplished with the DeathDamage component. AI behaviour - Not sure what you mean, but Petra can do lots more than it seems. Jamming Mechanics - Also easy, just give jammers an aura that reduces vision range to 0 (basically removes your units from being controllable). Data-Link - Why? Heavy Artillery - Yeah, that is hard to balance, but a very high cost and reload rate, plus high pack and unpack times go a long way. AA Defences - Just weapons that can only target/are best against aircraft. Radar mechanics - again, vision. MANPADS - Guy with a rocket launcher. Modelling of missile behavior - Why? State-space model - Why? control laws - not sure what you mean.

0 A.D. 2026-09-22 22-30-22 - Trim.mp4

Okey, altough there does not seem to be much interest, I promised it... there is a little tent left, that rome captured and does not decay after destruction of all the rest, and this keeps rome for the engine in a state "Not lost all critical resources". Altough a tent despite a house can not train woman, so it is over for rome. What is special, due to the palms next to the tent it is almost invisible in the mini map.

You are such a gigantic troll But I'll bump on it still, and give some nerdy details. The collisions between units are not indeed like solid bodies that are impossible to overlap, even with this PR, this will remain true for most units. It's more a spring-like push that tries to make units keep distance to each others. This pushing just use a distance-to-center repulsion force. What's introduced here for boats and elephants is a different stronger pushing and that actually take the unit's shape into account. This is why on the video you see that the hulls act like actual solid bodies. However simulating this, is ~x1.5 time costlier then the simple radial spring pushing. So because that, for small units, the difference in visible behavior would be minor, better go with the simple pushing, and use the better one only for big units that get the most benefits from it. A fun fact is that before this PR, all units were treated the same, so you did had still this radial-pushing for boats (the collisions were spring-like and only a small circle at the center of the boat was even acting as the hitbox) but it was still much bigger then for, say infantry. To detect if units were colliding, the map had a grid that allowed each unit to search a limited area where it might be actually colliding with other units. This grid size had to be proportional to the largest pushing unit of the game : boats - who's pushing effects where questionable anyway. Even if you played on mainland map with no ships whatsoever, the grid was sized to work for boats too. And your unit had to check their distance with much more other units they needed to. So you can say that the lag you experience on mainland, was partially due to ships. This along a few other optimizations with the pushing and more resilient obstruction handling, make the PR a performance improvement for common scenarios (yey!).

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'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.

I see I missed quite some posts from before: Indeed, equalising height was important (same reason ships would use towers), but the gangplank (epibathra) was used as early as the Siege of Motya in 398 BC. Indeed, because of the additional weight (another reason I proposed to change this tech to Raw Hides). I think only helepoleis could handle that (the one built at Rhodes was not the only one), or later towers from Imperial Rome (which could anyway spontaneously collapse, like at the Siege of Jerusalem in 70 AD). I also had helepoleis in mind when proposing champion ships and engines, since it would be a powerful siege tower unique to the Macedonians.

These are videos from a current work in progress to implement different forces into unit motions, like inertia, knockbacks and charge attacks! The values would be very customizable in unit templates for mods too! Screencast+from+2026-06-04+23-57-24.webm Screencast+from+2026-06-18+18-01-22.webm Screencast+from+2026-06-18+17-53-13.webm

I edited Part I to deal better with sources (first hidden bit now), and renamed the Delian League civ bonus Naucrary instead of Trierarchy, which could be another tech now. In this part I'm refining a few things regarding infantry and cavalry from Part I, but I'll deal mostly with siege engines. Most things are just name changes or design corrections, although for siege techs, compatibility with other civs would need to be checked (for those cases, in the meantime this is just meant as a record of sourced proposals). Part III will be about naval combat. PART II Things that should be: -Lithobólos (Siege Catapult) should be Lithobolos (Stone Thrower): accents should be removed, as per 0 A.D. nomenclature guidelines (most of the time I'll ignore this, but it should be followed). The present name, besides not being the correct translation, is misleading for the period, given that both bolt shooters and stone throwers were katapeltikon (throw against, basically), or catapults. Actually, in this period, "catapult" is even more often used for bolt shooters, being the first to be invented, and "ballista" used for stone throwers. The name inversion more familiar to everyone started after the 2nd c. A.D. -The Lithobolos torsion-springs shouldn't look like spirals: this makes no physical sense. Although there are a few ancient representations that also portray them incorrectly, there are plenty of representations around showing their correct appearance. -The Arsenal should be called Workshop: arsenals were where various equipment was stored, while "workshop" is used in the literature for what this building is supposed to be. Things that could be: -Athenians could charge when closing in on an attack: that is, be faster, louder and more disorderly than Spartans (stance depending), considering how heavy infantry charged at Marathon, and how psiloi "charged" at Sphacteria. I think it's funny that the caricaturesque static posture of the Spartans in the movie 300 and "shock combat" of the Athenians in the sequel could appear in the game in a less exaggerated way, while having some reported merit to it. -Epilektos (City Guard) could be Athēnaios Epilektos (Chosen Athenian, or less literally and keeping the present idea, Athenian Guard): just renaming them to make them more characteristically Athenian (there are units named similarly after all). It's not just about the name: Athens' Hellenistic infantry relied heavily on mercenaries, except for some elite volunteer hoplites, which seems to differentiate them a bit from epilektoi from other city-states. I thought about Epilektos Ethelontis (Chosen Volunteer), but I didn't want to give the impression that that made up term is an attested one (sometimes one has no choice). -Hippeús (Greek Cavalryman) could be Athēnaios Hippeus (Athenian Cavalryman), and be a lancer: gameplay seems to have resulted in too many things being exactly the other way around as they should be. Athenians avoided getting way too close with cavalry (they would have swords anyway, but usually as secondary or tertiary weapons, after javelins and lance), those tactics came later with the Macedonians (possibly after the Thebans), who in turn have no cavalry swordsmen in the game! -Pródromos (Cavalry Javelineer) could be Athēnaios Prodromos (Athenian Scout): I ended deciding for this name instead of Hippakontistēs (Cavalry Javelineer) since that's not actually attested (but for tournament situations, and after all, most cavalry were expected to use javelins). Although to be prodromos is more of a role that goes beyond just literally scouting, this is also how the corps is referred to (like saying that the Boy Scouts are scouts and more), and they are not mentioned that often for others except Macedonians (being later referred as lancers, as I've quoted before). -Tachunautousa Triērēs (Swift Sailing Trireme) could be an early remarkable ramming ship: it could be less literally and more helpfully translated as "Swift Ramming Trireme". The tachunautousai were the top trireme rating, strongly associated with Athens, for which ramming was their preferred tactic, although also rendered somewhat ineffective by the Hellenistic period, as will be explained in Part III. Their garrison should be reduced, or even completely removed while increasing their population cost to account for optimal performance at all times, which is one of the reasons I proposed somewhere else to extend champions to ships and siege engines. -The Oxybelēs is being represented by an early tension design: the oxybelēs would soon use a torsion mechanism mid-4th century B.C., looking like the present Lithobolos, which would completely supersede the tension design by the end of the 3rd century B.C., according to Mardsen. A further advancement would be the Polybolos, which had a magazine to increase shooting rate (could be just a tech). -The Lithobolos is being represented by a dubious design: this is still quite the controversy, but extremely illuminating, and could be used to differentiate units better. Regarding Roman terms, "the Greek bolt-shooting euthytone thus became the catapulta, and the stone-throwing palintone, the Ballista", from Kinard. Campbell and others state similar things, but what palintone exactly means is still debated: initially in his book he takes the conservative position that it had just to do with the orientation of the springs (hard to see in a game), and was a bigger version, necessary to more slowly transfer energy to somewhat equivalently worthy heavier stones. But a few years later (2011), Campbell takes the "French" position (https://www.researchgate.net/publication/307732119_The_inswinging_theory, by Iriarte), stating that "this solution, at once etymologically elegant and strikingly logical, has come to be known as 'the inswinging theory,' in which the catapult arms point forward when at rest, and are drawn inward during the spanning process", even claiming, when later discussing the onager, that "as in the case of the Hellenistic stone-projector, a brilliantly perceptive French design was sidelined by inferior German and English versions". Figures 3 and 4 in https://sciences.gloubik.info/spip.php?article1600 show both configurations clearly. In addition, palintones would eventually shoot heavy bolts (by changing their sliders), being a more powerful, although complicated, configuration. -Advanced Siege could be Lepides Sidērai (Iron Plates): the present name doesn't say anything, and it was really tricky to connect how the Lithobolos and Ram crush damage could even increase with the same tech, but regarding stone-throwers I read "Heron advises iron-plating any points of stress on the machine", from Campbell, and remembered that his other book stated "it is assumed that the vulnerable tip would have been reinforced with iron plating" regarding later rams. I've found critical point iron-plating references on many manuals while searching for something else. -Siegecraft could be Organopoioi (Mechanicians): also doesn't say absolutely anything. For a construction time bonus, "the art of those who construct the siege machines necessary for war (organopoioi), they too are termed mechanicians", from Sherwood. -Armour Plating could be Ōmon Derma (Raw Hide): to differentiate it better from the Iron Plates proposal, and many recommend for protection and fire-proofing for the big engines over iron-cladding because of weight. -Military Engineers could be Aphaireta Merē (Detachable Parts): to facilitate dismantling and transportation, as recommended in many Artillery Manuals (Belopoiika), this being another of my candidate names for this tech. I also wanted to leave more open the possible addition of Mēchanikoi (Engineers) units to build certain big siege engines in the field, as many have proposed in the past. -Bolt Accuracy could be Odontōtai Choinikides (Toothed Washers): again, the present name handwaves how exactly that would even be achieved. Washers are the discs through where the cords are threaded, their stability being important for consistent aim. To lock them, "teeth" were used after some point, and this was further developed with pin-holes (Trypētai Choinikides (Perforated Washers) could be an additional tech for more siege-oriented civs). I made up these names because these details appear only in archaeology, I think. -Naval Oxybeles could be Marine Catapult, but better if just removed: since not only the oxybeles was used, and to use the same terminology used by Morrison, and not just the same name as in Age of Mythology. Actually I disagree with having this tech at all, one should just have catapults mounted on heavier warships (explained in the coming Part III). Things that could also be considered: -Conscription at the Stable could also be Sitos (Fodder Allowance) or Katastasis (Establishment Grant): better alternatives to what was proposed in Part I, since the Hippeia (Cavalry Class) appeared in the early 6th c. B.C. (before the start of the game), while these are part of 5th c. B.C. Athenian cavalry reforms. -Eleusinia Mystēria (Eleusinian Mysteries), could be a civ bonus: this was an important panhellenic religious cult, and under Athenian control. Temples could give a food trickle, have improved healing aura, or produce units faster, for example, whatever makes sense. -An alternative approach to techs: in https://wildfiregames.com/forum/topic/34903-civ-spartans/page/3/#comment-760784 there was some discussion regarding techs unlocking units, and I ran into this "necessity" when trying to make sense of catapult evolution and how the game presently works, given that engines would look quite different after certain developments. An alternative approach would be to have some techs changing units (besides the usual techs improving them and the less common unlocking them). For siege engines, one would start with the Gastraphetēs, and then the Tension Oxybelēs (as they are right now). After researching a Torsion Springs tech, the Tension Oxybelēs would change to the Torsion Oxybelēs (which should look like a small Lithobolos), and the Lithobolos would be unlocked (which should use the French palintone design previously discussed). Later on the Polybolos (with magazine) could appear (either as an Oxybelēs change or unit unlock), and a final Heavy Catapult could later be unlocked (larger but slower) that could change between large stones and arrows. I know it seems too much, but I'm mentioning it for the sake of catapult clarity and completeness (and for whoever wants to implement things like these in their mod). Other information that might be useful: (All quotes from Sekunda). -Torch-Races for infantry speed bonuses: "we have evidence for three ephebic torch-races before the reform of the ephēbeia in 335, connected with the festivals of Prometheus, Hephaistos and Pan". -I think somewhere I mentioned Athenians would use "A" or "ATH" as shield devices, there's also evidence for an eye, a gorgon, a star and a laurel wreath. -Ephippios (Saddlecloth), Af'Hippou Akuntizonti (Mounted Javelin-Throwing) and Aphippolampada (Mounted Torch-Race) techs to improve cavalry: by 500 B.C. Athens didn't have yet a navy, nor proper cavalry, these were developments from the 5th c. BC. I like the idea of having lots of techs, for the player to think what to choose given different situations, otherwise everything devolves into mindless build/research order memorisation, or worse, just clicking what's affordable. Both should be penalised for a more strategic gameplay. These early techs should make Athens cavalry fast and accurate among Greeks early on, the problem is that the game is quite fast and by the mid game the Thebans, and later the Macedonians, should have better cavalry. In any case, this might be useful at some point for some. -"In Athens, a slave society, it was normal for an individual citizen of sufficient wealth to serve as a hoplite and to have his own personal slave. In time of war, the slave would carry the hoplite’s bedding and rations for him. Usually referred to as skeuophoroi, or 'baggage carriers' in our texts, the slaves would participate in the battle only if an unusual opportunity arose. Their essential role was recognized by the Athenian state". -It's good to bear in mind that, after a few decades where heavy armour seemed to be less common, "in the 360s, Athenian funerary reliefs start to show hoplites wearing muscle-cuirasses and 'Phrygian' helmets", "muscle-cuirass is universal, but there is a large diversity in the arrangement of the groin-flaps and the shape of the shoulder-guards", "some type of enabling legislation must have existed to force the adoption of the muscle-cuirass on the Athenian citizenry who served in the infantry". -"I imagine that the Athenian cavalry had adopted the Boeotian helmet by 362, and this was the reason why the Theban horse who opposed them at the battle of Mantineia painted their helmets white to identify themselves". @Arup, as the self proclaimed biggest worshipper of Athena, let us know what do you think is more worth considering regarding gameplay (although most of my proposals are just renames or design corrections, I think). I guess some points would change how the Athenians actually play, but I think they should be a fairly fast civ for Greek standards, with their decent early cavalry skirmishers, other missile support and swift ramming ships, while also having a solid infantry that, according to the stories, would make a sprint for it if needed. Right now I find it confusingly sword heavy, since neither the Marines nor Sword Cavalry correspond to anything realistic for them, while an eventual lack of swords would balance better with their Long Walls (and swords are really needed, maybe the Athenian Guard could switch between spear and sword, or better, the Iphicratean Hoplite proposed in Part I could switch between long-spear/proto-pike and sword).

nah, I could learn a lot from your work here :D Really cool! Didn't know all this was possible.

Ok nice! You could also bake from highpoly to lowpoly to keep the details in a normal map or bake ao into the diffuse

For Mycenaean heroes there are three options in my opinion: 1 use the (poorly documented) mycenaean figures we know: https://en.wikipedia.org/wiki/Enkhelyawon https://en.wikipedia.org/wiki/Attarsiya https://en.wikipedia.org/wiki/Tawagalawa_letter 2 mantain current mythic heroes 3 generic archetypes (Wanax, Basileus, Lawagetas....maybe religious hero) For mythic heroes we have detailed descriptions of their equipment (although keep in mind Homer mixes elements from bronze age and the later geometric period): https://www.salimbeti.com/micenei/armour5.htm https://www.salimbeti.com/micenei/shields4.htm https://www.salimbeti.com/micenei/helmets4.htm The mod's Egyptians seem to be based Saite period but with some New Kingdom heroes and Sherden guards , perhaps could be rework around a specific period. New Kingdom is of course more popular; although i find the Saite period to be interesting (mostly due to how little known it is, and because of their interactions with classical civilizations like Greece and Persia).

By the way, there's no issue on Gitea for this yet as far as I'm aware. Would you mind opening one?

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