Leaderboard

I've spent quite some time analyzing the effect of gcPreserveCode on memory usage and performance. In the previous measurements, we have seen a 13.5% performance improvement in the non-visual replay when gcPreserveCode is enabled. I've also checked memory usage there, but it was only the size of the JS heap reported by SpiderMonkey. If SpiderMonkey needs more memory with gcPreserveCode that is not part of the JS heap, we wouldn't have seen it there. So one of the first things to do is comparing total memory usage: Here you see a graph of the total memory usage during a non-visual replay of 15000 turns with preserving JIT code and without (both v31). The measurement in blue will be explained later. There's one sample all 5 seconds. As expected, the keepjit graph (green) is a bit shorter because it runs faster. In the end of the replay, keeping the JIT code needs 76 MB or 24-25% more memory. This is just the non-visual replay, so the percentage looks less scary with a real game where much more memory is needed for loading models, textures, sound etc. It's not only important what effect the gcPreserveCode setting has during a game, but also what effect it has when playing several games in a row. The JIT code is kept on the compartment level (might partially be zone level, but that's the same for this case in practice). We create a new compartment when we start a new game and destroy the compartment when we end it. This means we don't keep simulation JIT code for more than one game. The same is true for the NetServer in multiplayer games, for random maps and for GUI pages. Also we can run a shrinking GC at any time, which throws away all the JIT code and associated information. The third graph (in blue) shows an additional memory measurement when a shrinking GC is called all 500 turns and gcPreserveCode is enabled. It confirms that calling a shrinking GC really frees the additional memory used for JIT code and associated data. I would have expected it to have more or less the same negative effect on performance as the default settings, but actually it looks like the performance is as good as with keeping the JIT code for the whole game. It's a bit dangerous to conclude that from this single measurement though. I've not been especially careful about other programs runnings on the system and it's just one measurement. I've also worked on fixing some problems with the new tracelogger in v31. I've shown some tracelogging graphs in the past already. It not only gives information about how long JS functions run and how often they are called, but also engine internal information like in which optimization mode they run and how often they had to be recompiled. Among other information you can also see how long garbage collection and minor GCs took. The tracelogger wasn't really used for such large programs like 0 A.D. so far, so it had a few bugs in that regard (correct flushing of log files to disk for example). Some of them are fixed in even newer versions or scattered across different bugzilla bugs, waiting to be completed, reviewed and committed. Together with h4writer who helped us in the past already and who is the main developer of the tracelogger, I've managed to backport the most important fixes to v31. In addition, we discovered a limitation with large output files and he has made a new reduce script that can be used to reduce the size of the output files. Now that the new tracelogger is functional, it can be used to further analyze the effect of gcPreserveCode. The following diagrams are made from Tracelogger data. They show how long different code runs in the different levels of optimization. Code starts running in the interpreter, which is the slowest mode. After a function has run a few times in the interpreter, it starts to get compiled to baseline code (BaselineCompilation) and then runs in Baseline mode. The highest level of optimization is IonMonkey. TL stands for Tracelogger and can be ignored because it's only enabled when the Tracelogger is used. So basically the higher the IonMonkey part, the better. Interpreter should be close to 0%. I've added everything >=1% to the diagram and left the rest out. V31 (no gcPreserveCode, no shrinking GCs) V31 with gcPreserveCode v31 with gcPreserveCode and shrinking GCs all 500 turns The Tracelogger data matches the results from the performance measurement. Using gcPreserveCode without a shrinking GC obviously gives better results than with shrinking GC from the Tracelogger perspective. The difference is quite small though and probably doesn't justify the increased memory usage. Also the memory graphs indicate that there's probably not a big difference between these two modes (but this would need to be confirmed with additional performance measurements). The Tracelogger results from the default mode without gcPreserveCode are much worse (as expected). The code runs much less in IonMonkey, more in Baseline and even quite a bit in interpreter mode. The code gets garbage collected and throw away way too often and thus has to be recompiled more often, resulting in more compilation overhead and more time running in less optimized form. Conclusion My conclusion based on these results is that using gcPreserveCode together with a regular shrinking GC seems to be a good compromise between memory usage and performance. It might be worth to confirm that the shrinking GCs really don't have a significant (negative) effect on performance with additional measurements.

Hi Prodigal Son! About giving ideas and feedback, I think it would be great, during the development of your mod, to find a way to share some changes, in order to include them in the main game. I don't know whether it would be a huge additionnal work for you to generate patches, but it would be too bad if your implementation of distinctions between civs was impossible to add to the main game. Good luck for this mod!

Before starting to work on my mod I'd like to get some feedback and discussion on some of it's aspects. The mod would cover the same era as the core game, being by far my favorite in history and at the same time having a solid base to work on. It will probably carry on with the extremely original title of my Warcraft III mod, "Ancient Empires", possibly something like "0 A.D. Ancient Empires". Depending on the final changes decided, my free time and motivation and any possible help I can gather, it might be out soon or take a good while. The goals are: Bringing gameplay closer to Age Of Empires II, while keeping several 0 A.D. mechanics and throw in extra ideas of mine, as well as some from the community and other strategy games.Creating a game with civ attributes and unit roles heavily inspired from history, even more so than in 0 A.D, without overdoing it with complexity and keeping a steady look on balance.Keeping the game slightly macro focused to suit my personal preferences, without totally neglecting micro possibilities.Adding a few extra structures, many more techs and altering how recruitment works quite a lot. Overall the tech-tree should be at least 50% different in the end.Editing a few core mechanics. Ranged units should be weaker and cheaper, buildings tougher but deal less damage (especially garrisoned ones), melee units slightly tougher, cavalry stronger but more expensive and goes on. Workers/builders might separate from soldiers (with very few exceptions) to allow for bigger price/attribute differences without breaking the economic balance and making raiding more important. Territories might be removed. Mercenaries will be completely reworked into a separate, major part of the tech-tree. Big units will be done justice but cost more pop.Population cap might be reduced to 200 to reduce pathfinding lag. If it's done this way, farms might get 1 worker only (with balance changes), to free up more space for military units and keep the combat part of the game almost at the same number of soldiers.Quite a bit more, but let's keep it simple for now. You can find many of them here (not all of those fit with the mod's concept though).Any feedback and ideas are very welcome:)

I think svn is best to use as a working base (the files in the release are in a cached format, not so editable) I suggest you make yourself familiar with the folder structure so you know where you can find the stuff you need (in case you're not). Furthermore the only thing you need to is copy the file you want to change over into your own folder and modify it according your own needs. I've written a tutorial a while ago to help every modder to do his first baby steps, maybe it could be of use: http://trac.wildfiregames.com/wiki/CreatingNewUnits Other useful links: http://trac.wildfiregames.com/wiki/Mod_Layout http://trac.wildfiregames.com/wiki/Modding_Guide The wiki is not always up-to-date but you can always ask on IRC. To host your code and allow others to collaborate it is best to use a github repo.

Hi, I have not seen a post asking this feature ... so I trying : Is it possible to have the "Restart" function in solo mode, and if possible also on random maps. A "Restart" button in the menu (with resign and exit) would be fine, and / or why not in the summary to better compare the differences. This would avoid having to reconfigure the "Game Setup", but especially with a replay exactly the same card (eg to improve its rush, or to claim revenge on "Petra / hard" in the same conditions). If not possible, it's a shame because I find it indispensable to progress efficiently.

(No, I'm not trying to 're-envision' how techs work in 0ad, don't worry!) A while ago, Pureon showcased some of the icons the art team had been working on (http://www.wildfiregames.com/forum/index.php?showtopic=17025) and along with a selection of icons, he also displayed a Tech/Structure tree concept: I liked the idea (as did the commenters in that topic) and so I decided to attempt to implement it - with a little interpretation. After months of on/off development (mostly off than on) and various revisions, I have got it to a point where I'm happy to share it with the community. Here's a screenshot: A live interactable version can be found here: http://s06eye.co.uk/0ad/techtree-v2 And the code is on github here: https://github.com/s0600204/0ad-techtree-v2 Please note that this is no more finished than 0ad is. There are changes to come, efficiency improvements, appearance tweaks and such. But I thought I'd share my progress and get some (hopefully favourable) feedback. Enjoy! Update! It is now possible to see this in-game. See this post for details! Code Updates: 21st October : Tooltip positioning is better. 22nd October : Stats are now loaded from parent templates properly 23rd October : Tooltips now have the same descriptions used in-game; and for units and structures, attack and armour stats are shown where applicable. 3rd December : Three more community mods available for comparison, rewrite much of the data parsing code. 30th March : Big update to mods' simulation data, and modifications to permit aristeia's phase-pair techs

Cavalry now have reduced pierce armor, spearmen deal pierce damage, so they counter them.

This isn't a bad alternative, it's quite a different approach though and not fitting with civ specific discussions.

For a long time 0ad was designed to play on most computers. I think doing that will go against this idea cause we have a lot of integrated graphics players who would'nt be able to run the game. If we do thatthings like suppor only opengl4.3 would appear making 0ad unplayable for most people for little to no benefit. A Three 1280x1024 screen user.

This just makes the early game more confusing for new players for no real gameplay value. Again confusing and requiring extra balance for no real benefit. If some bonus is intended for Macedonian skirmishers, attack or attack speed would do (simulating their fierce northern tribe recruits) without messing with the economic balance The idea on hoplites isn't bad, it's one of the ways to have them different and historical, it could also mix well with existing suggestions. The rest seem more or less like random things popping out of your head, or hard to implement for no real value (last stand - can just make them stronger). That would be the pilum used by swordsmen, not skirmisher javelins. Iberians had heavy javelins as well, before the Romans. I'd make such a thing a tech buffing swordmen's missile damage if pre-charge projectiles are implemented at some point. That should be the case for Persian and Mauryan early units (besides the cost - it should be unit-dependent and the cost differences should be on wood. An average human would eat more or less the same no matter where he's from). As I've told you before.. replacing starting walls with palisades solves only half the issue. Weird wall pre-placement and forced town layouts remain and the desired starting stone fort aspect is lost. I'd say make the civ center a fort. One more default arrow and some extra health and here's the forty-anti rush attribute without many issues. Weaker soldiers don't really fit with Iberians imo and the house bonus is a boring one, unless we really lack bonuses for them or it somehow really fits with some other of their aspects. Your last suggestion on them could prove interesting from a gameplay perspective. Since they are a mostly defensive faction, they are prone to choice by new players and not having to micro veterans in and out of eco would be helpful to them (or to players like myself who almost never bother with that anyway). It could also just not decrease for them instead of increasing. Ptol archers might be a common strategy but it should be removed imo. A mercenary unit, spammable in the village phase and one that wasn't even used by it's faction doesn't seem right. If we want a civ with heavy early metal use for mercs so that this tactic isn't lost, let's have that be Carthage. I'll also repeat that imo mercs should cost metal (their payment) and if full metal is too much, food instead of wood (they'd be fed by army supplies/not wood, and this is not messing with game balance anyway since they both are common resources). They should also train faster than other units overall. I'd say a good farmer civ should have a default farming bonus. Let's keep the econ tech-tree clear.

It would have been much better if you could place the logs here.

This was actually done in Age of Empires 3, where ranged units in melee range would hit things with their weapons instead of shooting them. Musketeers had muskets with bayonets on them, so they did quite well in melee. In the other hand, skirmishers armed with rifles were forced to hit things with their rifles when caught in melee, which was obviously ineffective. It was not only cute, but it was also realistic and it balanced out ranged units caught in melee fights. I mentioned this before in another thread, however I'll say it again. All infantry and cavalry units which were attacking buildings did so by torching the building, NOT by using their weapon. This was also more realistic and it looked better. Even melee units had a ranged attack for siege which was simulated by throwing the torch. Very nice overall. If these kinds of animations could be included in 0 AD, I would love it. It should be doable without too much technical difficulties as far as I know, however it would represent some tedious work. So I agree with you,DMDonahue. However, that is one task that needs to be looked among many, many more.

WIP. Incredible model by the way.

I have not found a ticket in trac, but if this function also interested developers, then it should open one I proposed for the single player and not multiplayer, because as historic_bruno said, it will certainly be more complex and after seeing at work in L4D2, this function can quickly become unbearable (if there is abuse). I do not know how other multiplayer games have incorporated this function, but here's how it works in L4D2 : - A player can't decide alone to restart the game from other players, so it requires a vote where you have a majority of "yes" (which is a good idea). - But it's in the case of a negative vote that can be a problem, because the one who absolutely want restart, surely require another vote. He can't do more than two consecutive times (just to avoid the abuse, time is required before again two votes), but if other players also wanted to restart (who are the minority), then they may also ask again this vote, which logically will be "no", then a second ... Conclusion : we lose long minutes to vote and vote again (not to play), before being forced to exclude the player or players that problem (by voting, again). - However, if the players know each other and speak the same language (which is essential to develop good strategies = we also create a "vocal group" for this, which need headphone and mic ... which could be another feature request for 0 A.D. ), there is no problem and this function "restart" is fine. This is only a feedback, but if you want to integrate this feature in multiplayer, I think it should be activatable (or not, may be by default) in "More Options".

Let's start by saying that I will not go in detail with the well deserved praise to the team and all contributors for the game's development so far, but rather focus on fixes and proposals, instead of mentioning what I like. After testing Alpha 17 a bit ( a few games on both single and multiplayer, as well as a quite deep examination of changes for all units, techs, civs etc), some fixes come to mind first. Mind that I'm not 100% sure on all of them, that would need extensive multiplayer testing which I haven't done. SOME MINOR STUFF: SOME STRANGE STAT ISSUES: OTHER: A BALANCING TEMPLATE UNIT CLASS ROLES GENERAL SUGGESTIONS AND TECH PROPOSALS: CAMPAIGN: FACTION SPECIFICS Trying to make each faction unique through historical attributes. Note that the unit lists I'm mentioning are chosen mostly from a historical perspective, balance and uniqueness for each faction on that field would need lengthy discussions. ATHENIANS The Athenians should have bonuses on navy, expansion, infantry mobility, economy and research, with an expand and defend playstyle. Faster built or cheaper Civ Centers will allow quick expansion (simulating colonization or vassalization of other's colonies) with mobile infantry forces and navies to protect them or raid enemy holdings. Later on, Philosopher units can help the colonies flurish enhancing construction, economy and research, to make up for a slightly weak late game military. BRITONS The Britons should be an offensive civ with relatively cheap and weak (in defense) early units and weaker, faster built (wooden) structures. This makes them a viable booming faction as well. More research needed. CARTHAGINIANS The Carthaginians should have bonuses on naval trade, navy, exploration, expansion, defenses and mercenaries. Locating (with bonused scouting) and securing (with fast built or tough structures) metal deposits, to help them make the most out of their mercenary armies, as well as maintaining naval and trade superiority could be their core direction. GAULS The Gauls should be an offensive civ with relatively cheap and weak (in defense) early units and weaker, faster built (wooden) structures. This makes them a viable booming faction as well. Later on they get access to tougher units and upgrades. IBERIANS The Iberians are the ultimate turtle civ with several defensive bonuses and also specialize at guerilla warfare. Their units are quite varied but their navy is one of the weakest. MACEDONIANS The Macedonians field powerful cavalry, infantry and siege weapons and reliable missile units. A mostly offensive faction at early-mid game, that gets more staying power later on with reforms increasing the survivability of several units. MAURYANS The Mauryans could be an aggressive (rush) civ with weak, cheap and fast trained units, relatively weak and fast built (wooden) structures. This can also allow them to play with a booming playstyle, since cheap citizen-soldiers should give an early economic advantage. Their armies are rather weak with the exceptions of archery units and war elephants. PERSIANS The Persians excel at massing weak, cheap infantry units supported by equally cheap but formidable archers. But what really stands out is their cavalry arm, one of the strongest among all civs. Their structures are strong as well, although a little slower to build. PTOLEMIES The Ptolemies should have a well balanced military, with most troop types and better than average mercenaries, but that shouldn't be the core of their strength, somewhat lacking in champion units and military techs. Farming, research, naval and defense bonuses should make them a booming-defensive faction with a variety of secondary options. ROMANS The Romans might have somewhat weak cavalry, but make up for it with easy to mass tough infantry, strong siege weapons/structures and increasingly good technology as the game advances. SELEUCIDS The Seleucids probably have access to the largest troop variety of all civs, including several elite units and powerful reforms. Their other aspects could stay at average more or less for balance, even though historically they could have many other bonuses and their weaknesses don't translate well in RTS gameplay. SPARTANS The Spartans can be a very unique faction with early available, very limited, super-elite infantry supported by average to poor other units. Late game reforms can provide a reliable, massable unit in Cleomenian Pikemen and improve other troop classes through newly unlocked mercenaries, so that they can stand against other faction's now powerful armies. Helots can be used as a unique worker unit with the best default farming rate (even if slaves are added in general).

Two more games: 0 A.D. Multiplayer: Prodigalson vs SwampGremlin This match starts with some peaceful booming until around 19:45, then the offensive kicks in, resulting in some pretty intense combat around three fronts, with both players focusing on cavalry. SwampGremlin is playing as the Gauls and I'm playing as the Seleucids. There's a little bit of an effort on commentary during the first few minutes before I get absorbed by managing the game. 0 A.D. Multiplayer: Prodigalson & LordigorIIIOfKiev vs theMario & erejum31 A 2v2 with an unexpected twist, having the player considered weaker during team set-up decide the outcome. Myself as the Mauryans, Lordigor as the Iberians, theMario as the Macedonians and erejum31 as the Athenians.

Well, since there is no such thing as dismounting, we can 'imagine' that a dude got off from his horse and kills chicken, but then he shouldn't have the same bonus for hunting which cavalry has. And in general, cavalry shouldn't have hunting bonus much bigger than infantry, since cavalry already has natural advantage in hunting due to their speed and capacity. Afaiu this bonus should reflect their 'skill': men are better in mining, women are better in farming, but why cav hunting skill is 5 times better than inf hunting skill - no idea.