quantumstate

Welcome, thanks for uploading the video. Looks like we need to teach the AI about unpacking siege .

Cloning the look would definitely come under being a derived work. If people want to work on this they can easily make it a mod, keeping things seperate from 0 A.D.

AOE was the first proper PC game I played as well.

I would say that for the simplest solution all entities would be kept and terrain height would be averaged. Obviously some manual cleanup would be needed.

Unfortunately this falls into the legally problematic category so shouldn't be put into the game.

I might join this in about a week when I get modern computer access back. To makes things faster we need a map merging tool, then we could all make the map at once.

This is low priority but shouldn't be too difficult technically since Ben already did the work to allow changing LoS for techs. It would be a nice little feature.

Here is one. http://www.hiveworkshop.com/forums/attachments/map-development-202/70340d1259315323-age-empires-1-aoe.jpgv

Ah, good memories . Would be an awesome mod.

Yes, that is what I was thinking. This is linked with capturing structures within enemy territory. Since structures will by default lose loyalty when not in the owners territory, captured enemy structures would by default lose loyalty as soon as they are captured. This is undesirable for the reasons given above, since the player has the units who can capture the building those units must logically be able to prevent the captured building from reverting to the former owner. I think garrisoning should definitely do this but am unsure if non garrisoned units should also have this effect as long as they are within a certain radius. This is a fair point, I am still not completely convinced though. There are quite a few details to work out in this section. What loyalty should a newly captured building have? What happens if multiple players are contesting a structure? My proposal is how Company of Heroes works, immediately flipping is how C&C Generals does it. The gaia ownership signifies contested ownership where neither player has control over the structure because they are fighting for it. I think how you say matches more closely with the original design for this though. The kick point is fairly arbitrary, I guess 0% makes sense. I was just copying the health one which kicks earlier so that the building doesn't fall down on top of the units, but for loyalty that doesn't apply. I like systems of diminishing returns. e.g. 5 captured camels give a 10% reduction, 10 give a 15% reduction, 15 give a 17.5% reduction etc. This gives a bonus cap of 20% (or whatever we choose) but additional captures always mean something.

I agree with Pedro's idea for animals. I'm not sure about vision range, that might be too large a distance, but that is a minor detail. The original idea is to have capturing as the primary way of non siege units dealing with buildings. This means that capturing should happen with any amount of health. Loyalty needs to interact with territories, the current damage for out of territory structures should be changed to a loss of loyalty, this is basically capture by the gaia player. Neutral structures within a territory would be gradually captured. I think a player should be able to prevent loss of loyalty using garrisoning, so you could capture an enemy building and then keep it, even though it is in their territory. I am starting to think that ths is essential because otherwise you have a silly situation where a structure is captured but then you are unable to prevent loss of ownership until you lose control of the structure and then use nearby units to recapture it restarting the whole cycle. Should nearby non-garrisoned units prevent loyalty loss? One idea I had for capturing is that buildings must switch to a gaia state while being captured. So a structure would be owned by player 1 and have 100% loyalty. Then player 2 comes along with an army and starts the capture process. Loyalty decreases down to 0% at which point the structure becomes neutral, owned by gaia. Now it starts gaining loyalty for player 2 but is still owned by gaia. Until it reaches 100% loyalty when it now belongs to player 2. This would prevent rapid ownership changes between two factions fighting over a structure. The effect of garrisoning is interesting. One option would be to have garrisoned troops make capturing slower, and have the garrison kicked out when the structure reaches something like 10% loyalty (this happens with health currently). This is the simplest approach. Otherwise there could be an idea of storming a structure. Units could have a certain storming ability, so there could be specialist units useful for defending or attacking garrisoned structures. The defenders would have some sort of bonus, this could depend on the type of structure as well and even structure health (e.g. use a battering ram to "knock the doors down" and then it becomes easier to capture). This adds quite a lot more complexity to the game play though. There will need to be some difference in animation so that ranged units can capture, firing arrows to capture is silly. One question is how to deal with differences in unit speed, should a woman in the process of being captured be slowed down or stopped? Otherwise infantry will have difficulty capturing, though perhaps this is desirable behaviour. As long as capturing is slow enough I don't think a cooldown would be needed. With the short range of capture an army of sufficient strength should kill attackers trying to capture it. Capturing should only be viable when there is a large difference in strength.

Welcome. We generally use the trac ticket system to manage things, which Lion linked to. Generally people roughly pick tasks which they would like to work on. External contributors are expected to post a patch with a trac ticket which should be reviewed by a team member (though recently we have been struggling to review things very fast). Irc is a good place to go (quakenet #0ad-dev) to ask questions about development. There is a high level overview of the features that we want on the wiki at http://trac.wildfiregames.com/wiki/GameplayFeatureStatus .

We could implement flattening without influencing the passability. This would lead to some visual inconsistency with units walking up unusually steep slopes.

These look pretty nice. Thanks for posting them.

How did I miss them? The apparently arbitrary genre ordering on the vote page probably didn't help (I have tried in two different browsers and it doesn't seem to be randomized for each user).

They seem to have a slightly different definition of low poly to me .

I came across these, would they be suitable for the game? http://www.blendswap.com/blends/plants/low-poly-foliege/

They seem to be sitting on the result. From an optimistic point of view "Real Time Strategy" is 6th in leading genres and we are the only game in it. All of the genres above have lots of games in them.

I have made a small increase to cavalry speed, along with increasing their combat strength.

Thanks for posting your ideas. They seem quite well thought out. The problem with ideas like number 1 is that every time you make units smarter the less direct the players control of them becomes. Since units are never smart enough implementing these things must be done with great care to not be more annoying than the thing that is being solved. This is a particularly annoying issue though and should be implemented, it should be approached with care though. We already have an implementation of the multiple building training. We use the system of duplicating your orders between all buildings. So fi you select 5 barracks and click the spearman button you will train 1 spearman from each barracks. I see no reason to change the implementation and prefer the way we do it to starcraft. Our GUI doesn't fit very well with showing the queues under the unit portraits. This is because we display multiple selected units as one portrait with number. This makes sense because the game is designed to have large numbers of units so we need a compact way of displayed large selections. Changing this for buildings is inconsistent which is not ideal. it does seem like a nice idea though, it would be good for garrisoning as well. Perhaps we can come up with another way of displaying the information. This is a planned feature. The current best method is to select everything, then control-click the unit icons to remove unwanted selection. Or set up better control groups before the battle. I would find this feature helpful. The main concern with this one is that if we add too many buttons to the GUI it takes up more room and overloads the user with too many options. One possibility would be to relegate this to hotkey only, or if we think it is important enough buttons could be added. Perhaps we can have a toggle-able advanced UI panel for users who want masses of buttons. A bit off topic and speculative is to add support for UI mods, I believe world of warcraft has may of these, so you could install addons to add these little GUI tweaks, this would let users decide for themselves what they want and allow people to distribute them separately from the main game distribution. This idea is exactly the kind of thing that this would be good for.

This would be unlikely to cause a desync as long as you only translate the UI text, however it is a horrible idea and should not be done. There are much better ways to doing translation.

I believe that our engine would give a friendly error message instead of crashing. I think there is a limit of 64000 vertices allowed per model.

The video was nice, but I was hoping you would zoom in a bit so I could get a better look at the buildings. The mod looks great.

A gear would be good. It is definitely meant to be an AI config window.

Thanks for looking into the technical side of this. With translation part of the reason we have been holding back is because the game is still changing rapidly so translations will go stale rapidly. We were planning to wait a while before starting the translation work.