sanderd17

It's all a bit scaled to be viewable. Big things (like buildings) are scaled down, small things (humans and small animals) are scaled up. So I think big animals like elephants are somewhere in between. And about the horses, it's true that there were smaller horses in central Europe, but I think those weren't used for combat. Bigger (imported) horses were preferred. Small horses would be nice for wild animals though (huntables), but due to a general lack of wild animals, they're not made yet.

You can always edit the ticket (including title) to your liking. And for the development part of the website, you mean trac? I don't know if that's very themable, and I don't think our web devs have lots of free time on their hands wrt making a custom theme for it.

Great it's accepted sathyam. About the tickets, please claim them by changing ownership. #1323 looks certainly good. I don't know if #1038 is needed, that could use some discussion I think. #799 is a must for this game, so if you can implement it, thanks a lot. #1044 has just been handled by mimo in a rather good way, although patch reviews are also welcome, you won't be able to code much on this. #1833 and #1709 are related to bigger changes. Ideally, animals should also stay in a certain zone where they were put by the scenario designer. Working on the AI rewrite would probably be a bit too much of work. Adding new features should be easier (and it also gives insight in what the AI code really needs).

http://trac.wildfiregames.com/wiki/ArtDesignDocument#ScaleandProportions For the gameplay, humans are about 2 meters high. Which is far too big, but it's done that way to make sure that units are still easy enough to select, or to see in combat, while you don't need very big maps to place all your buildings.

Also note, there's a big difference between Java and JS (JavaScript). If you ever use google to search how to do something, make sure you end up on pages explaining JavaScript, and not Java. Although it looks similar on first view, there are enough differences to make you pull your hear.

The lag is exactly why we are doing a fundraiser. It requires a lot of full-time attention, and with the fundraiser, we could employ a full time programmer to work on that. So I'd reverse the statement, and say that if you want a lag-free game, you should support the fundraiser.

AI is handled in Javascript (as most of the game logic is). Only graphics, and common cpu-intensive parts are in c++. For the AI, you should look in binaries/data/mods/public/simulation/ai. There you find the different AI logics. Some of the shared functions are also in C++, that are the managers you found.

When you play simulation games in Atlas, you can change the terrain while playing. Also, even in regular games, you can harvest wood, so forests disappear. So caching isn't that easy.

I suggest you play the "starting economy walkthrough" map. Select "demo maps" in the map filter, you'll find it in that list. Try this game (with the tutorial AI) a few times, until you get the hang of building up your economy. If this is too difficult, you can also try the other tutorial map first "Introductory Tutorial", also under Demo maps. Once you have your economy going, you still need to attack though. Currently the best way against the AI is to rush. Aegis won't attack until the 20th minute. So once you have your food and wood going, build some barracks, and produce ranged melee units as fast as you can (training in batches goes faster). When you have 10 units, run to the opposite side of the map to find the enemy (while you keep producing new units, if food production isn't fast enough to keep up, add a new field, if wood gathering isn't fast enough, add some workers there too). If you've found your enemy, try killing as much of his workers as you can, but try to keep out of range of the Civil Centre if possible. This way, the economy of the AI is completely broken, and he won't be able to keep up with you anymore. Of course, this strategy will change in subsequent versions, when game statistics change, and the AI behaves different.

Some of these are easy, like just take the height difference between target and source, apply some formula and use that in the damage calculation. Other ones are more difficult, like determining the "flatness" of a terrain. That's normally comparing the height of n tiles around the unit. If you have to continuously do this for 200 units fighting, you end up with big lag probably. The same for detecting forests.

http://trac.wildfiregames.com/wiki/GettingStarted

Working on some other things too, I don't have too much spare time to think about this. I think it requires someone to implement multiple attacks, and after that, we can start fixing the behaviour. It's a bit difficult to have this discussion in a void for me. I'd need to be able to test things before I decide.

This isn't a minor issue, it's a major usability issue that requires a lot of thinking.

As almost all game mechanics are in JS, switching to a different language is as plausible as writing a new engine. As you see, we have about just as much JS as C++ code: https://www.ohloh.net/p/game_0ad

That choosing between axe and wheelbarrow is intentional. It requires you to make economical choices. Either you choose for faster collecting more wood, or you choose for carrying more wood. If it's a map without a lot of resources (so you have to walk a long way), it's better to use a wheelbarrow to carry more. When you have lots of resources nearby, it's better to just work faster.

Hi Itms (I've also seen your name passing by on trac). Thanks for willing to devote some time to the project. The normal process to become part of the team (and get commit rights), is that you first have to submit some patches (that is, you choose a bug to work on, or find a bug yourself, and fix it). It's also important that you communicate enough with the team (via this forums, or via the 0ad-dev IRC channel on quakenet). When you know your way around the code, your patches are good, and you communicate well, someone will offer you to become part of the team. See the wiki for more info on submitting patches, getting to know the code etc. If you want help, guidance or comments on code, Please drop by in the IRC channel.

Maybe the base could be a bit like the wall base. So not fully covered with spikes, but spikes on the corners. And some bits of wood sticking out at the base. Celts often used wood to make their stone structures more "bendable". I don't know exactly how you'd do that with a round tower though.

We did not want to remove the minimum range. It's just because it caused problems. When a melee unit got into the minimum range of an archer, the archer ran some meters from the melee unit, then turned around, prepared to shoot, and by that time, the melee unit already caught up with him, so the archer had to run again. What we really need is doing better distance calculations that are based on the speed of both units. And better decisions about when to chase and when not depending on the speed difference. We do want mixed units (ranged and melee), but more like the roman kind: throw one pilum, and attack by sword afterwards. So it would only count for some units, while a big part would stay purely melee or purely ranged. I there is a chance it's going to cause too much micro. If archers will certainly loose when fighting in melee, they should run for themselves. The player shouldn't continuously command them to run.

Clayton, this thread is only about random map scripts, not about Atlas. Any relation with this: http://trac.wildfiregames.com/ticket/2114 ? Or with other existing Atlas bugs. If not, can you find a way to reproduce it, and make a ticket in trac?

Aegis does have tech restrictions, and does research techs. Older AIs don't have those restrictions. So if the game is with Aegis, it's very strange.

The first two pictures are no bugs. It's a technology you research. So that becomes available for all workers at once (like your civilisation learns to make iron axes, then everyone can make an iron axe). There's no reason to research it two times, so that button is gone. The third picture indeed is a bug, but when did it happen? Is it after a saved game? Saved games are not supported by AI players. Thanks for mentioning that.

To me, the door looks smaller then the carthagian one. Also note that they need to have the same footprint (for gameplay reasons, they should be equally easy to find a good spot for). Thanks for working on it, it's heading in the good direction IMO

Do you mean you want to do narrating? Or human sounds? Currently, we don't need real voice acting (as you'd see in some introductory movies), as the software can't handle it yet, and the modellers are too occupied with in-game low or medium poly models, and not with high poly movie models. We could use some good narrating on certain occasions (like for tutorial or release videos), so if you want to do that, please send us some examples. And lots of civilisations still need their own voices added, but it could require historians to get the sounds correct.

Can you say which map you are editing (from which one you started), and copy the last 20 or so lines from the map XML file here, so we know if you're adding valid entities.

Nothing changed in that respect. It works best if you unzip the public.zip, so you know where to save the. If you don't unzip the public.zip, you need to make the directories with the exact correct names yourself. It's not in the toolbar, but when you open the terrain sidebar, you have a "ridge" tool, that's the one.