Leaderboard

Not sure whether this was ever shared with the team before, but we had a fairly robust documentation platform in place for this project. http://wiki.sciondevelopment.com/ The domain expires in February, but if you think you guys can get some usage out of this, I can afford to renew the name and continue maintaining the site. If you're interested, feel free to adapt the content to your current needs; it sounds like the project has come a long way.

Hey scythe !! Hope you still follow this topic; as I asked you in irc days ago, what about continuing sbb? After about 30 "real" matches in a17 there are a few points to mention/discuss: - champions. need. more. health. - buildings need more pierce armor. Its ridiculous, how 8 archers can tear down a building thats in progress or a few more archers can destroy eg a tower. (which damage do archers to a stone tower in reality? Imho: nearly none.) - rams are op now compared to catas. Need less pierce armor too, or champs more health, as said above. Or units generally dealing more hack, dunno. - That skirmcav auto-micro needs discussion too. All ranged units should get this feature, or, what I personally would prefer: no auto-micro at all. - Ptolemies are clearly op in earlygame. Its nearly impossible to defend their raids in first gameplay minutes without own eco going downhill. Also in lategame, that hero that increases pikemen health 40% during his lifetime is ridiculous. Give him an aura, or nerf the percentage. No balancing, but generally: 2v2 multiplayer are nearly impossible due to huge lag, compared to a16/15/early sbb. Afair leper told me that the lag might be related to the new FOW/mirages. If so, it might be worth to undo the new FOW, imho. I would prefer smooth gameplay to laaaaag and scouting.

I'm watching as do the buildings look like Mesoamerican buildings, you see what I failed yet(My English is very bad) And I made a building that has nothing to do with mod

Recently I put some effort into researching the creation of more realistic looking mountain and today I would like to publish my first results: As you can see, I focused on the middle and didn't bother too much about the sides. What do you think of this? Where and how could it be improved?

Hello, My name is Veronica and I am preparing my master thesis on localization of open-source video games. I am interested in the l10n process of 0 A.D. and I need the help of any developer of the game to complete a short survey for my study. The survey is mainly about the l10n process, programming languages and translators recruitment. Please, help me! Best, Veronica S.

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:)

It doesn't mean you need no women. They're still 25% better at farming and cheaper. Celts have weak structures, so a potential choice of better defense sacrificing a little farming efficiency doesn't seem bad to me. Anyway I'm not currently trying to fix the core game's imbalances, I'm trying to add some extra historical/gameplay flavor and see how it works before focusing on balance. Btw I've set up the github repo. Is anyone willing to test the first changes with me? You'll need SVN, downloading this (download zip) and unzipping it into binary/data/mods of your SVN installation.

The northernmost border of the Seleucid Empire, separating it from the steppe tribes and as far north as Alexander's army ever reached. It's my first 0 A.D. map, nothing very fancy as of visuals, as that's not my forte and the steppe biome doesn't help much, but I believe it plays pretty well. The AI seems to like it as well, it was tougher to beat compared to other maps I've played on SP. I also noticed an AI glitch while testing it. On one of the matches the AI built many defense towers across the northern edge of the map, while obviously none could invade it from that side. The forum won't let me upload one of the two map files, so I guess there should be some other way sharing it. Thanks to niektb for explaining how to place skirmish entities. Edit: Thanks again, map added. Jaxartes River (2).zip

Making my first changes, thanks to everyone who helped me grab the basics Started tailoring the current game for more unique factions with small changes in civ-specific bonuses and techs for now. First is Carthage. So far I have: Made Exploration a civ bonus instead of a tech. It now gives by default +20% line of sight to cavalry, traders and ships making them better at scouting and monitoring trade routes and waters.Made Colonisation a civ bonus instead of a tech. It now gives by default -20% build time to Civic Centers, Houses and Temples, making them better at expanding and working well with their champion units trained at the temple.Reduced Temple cost to 300, 400 seemed too high.Ship Armor and Construction Speed upgrades now available at both docks, to remove their inexcusable naval handicap.Fortified Barracks tech available at the fortress for 1000 stone, increasing Fortress and Barracks hp by 30%. Inspired by their construction of strong fortifications housing barracks, stables and even war elephants.Mass Production tech available at the fortress for 500 food, 500 wood, 250 metal, reducing siege weapon construction speed by 25%. Inspired by their tendency to construct large numbers of siege weapons (was actually more common for defensive purposes, could be charged if ballista towers are implemented).Exact numbers on techs and bonuses will need testing. More changes to come. Btw I'm also thinking of removing/heavily altering or replacing with civ-specific tects the Fortress techs reducing siege weapon costs. I don't see them as very useful in their current state due to a low effect for low-massability units and high costs. Thoughts?

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.

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

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.

I also like to play zoomed out, and I agree that, in some maps, the level of distance fog is a bit annoying and I'd like to be able to reduce it.

Wonderful, I got it. I can now edit maps with SVN atlas and run them with Hannibal as mod in release. Thanks.

In svn, there were some changes in simulation/components/GuiInterface.js, so you should update the mod to make it work properly with svn (although it should seem ok as long as you only have AI players). Otherwise, I use it from time to time to test Petra, and it is quite useful, thanks.

Does it.. eat people off of ships? Please?!

I think we'll have some form of trigger editor, now that we have triggers, but did it actually work pre-Alpha? A lot of things were implemented pre-OS, then were removed when the simulation was reimplemented by Philip, etc. Did you try loading maps from anywhere in Atlas? That was broken for years until A16(?), because maps are loaded through the VFS, which is mapped to only a few real directories on your computer. The old file dialog was misleading that way, you couldn't really open or save anywhere. http://releases.wildfiregames.com/