sanderd17

I think there are many possibilities. If I focus on Greek gods (which we know best, in particular the olimpians), we could see the following possibilities: Zeus: A bit too general to put in statsPoseidon: god of the seas: faster and stronger shipsHera: Empower women: give them better attack/defense statsDemeter: Gather grain a lot fasterApollo: perhaps the most supernatural of the gods. Could improve some stats for healers, temples or auto-healing.Artemis: Better hunting stats, and lower unit training time (goddess of hunt and fertility)Hephaestus: A blacksmith: units get stronger weapons and armourAthena: Goddess of strategy and wisdom, maybe stronger or faster-to-construct buildings, not sure if that relates. Maybe better tools (like siege engines) would be appropriate too.Ares: God of war, so I guess just upping a few battle statsAphrodite: Shorter training time for all unitsHermes: also a rather supernatural god. I can see some interesting things like bringing soldiers back from the death, but it's rather different from the current techs and auras we have now. Maybe we could also focus on his protection of travellers and trade.Dionysus: basically the god of the festivals and alcohol. Not sure how to put this into positive stats.So if we pick a few gods per civ, there are certainly enough possibilities for Greek and Roman civs. For other civs, it might be more difficult to find.

The pathfinder is still being worked on, slowly. If there are no further problems with it, it should be releasable soon (A19 or A20 maybe). However, don't expect too much from the first versions of the new pathfinder. It will also need to grow.

Yes, it's ready for a new, super-fast pathfinder, so we can have super big maps with a good height difference.

To get the same design over and over again, you can edit the map xml by setting a seed. See the Roman Sandbox xml for examples, search for "seed". It might take a bit of work to find the right seed, but when you found it, it's as easy as copying the seed. For making your own units, that's called modding. Units are made out of different props (helmets, shields, weapons, ...), and you can edit those with the actor editor, or by editing the XML directly. See http://trac.wildfiregames.com/browser/ps/trunk/binaries/data/mods/public/art/actors/units for all different units and their looks.

1. There are no ages in 0 A.D., but city phases. Similar to 0 A.D. being a time that never existed, so it lets you fight civilisations from different periods, the time also doesn't proceed when you build up your city. If anything, the CCs could grow when phases are researched, as bigger cities get bigger townhalls, no matter in what time it was. 2. There's already a barter option in the market. There you can exchange one good for the other. Your workshops seem to do the same, making one of them useless. 3. 9 monuments per civ is a lot. That means you request 108 models from the artists. If the resources are away from your CC, it's because the map maker meant it this way. Sending out your worker units makes them more vulnerable, thus can make a game more fun (it all depends on what sort of games you like, and what the map maker likes of course). 4. Icons are just part of the GUI. They should represent their meanings with what we currently picture with it. Like the town bell is a bell icon, even if they might have used trumpets or other instruments in the past. In-game art must represent reality as close as possible, GUI art must represent actions with icons we currently understand. So the two hands together is easy to understand, and works well. The staff with a snake might indeed be harder to understand. If you know improvements, you can always propose them. 5a. Yeah, maybe they could have a better aura, and make them more useful. But we must make sure they don't get overpowered either. 5b. I think altars aren't needed when you can build temples. We really shouldn't add buildings without distinctive meaning. 5c. Alliances are a choice of the player, not something forced on the player. So if two players agree, they can become mutual allies. 6. Temples have a healing aura already, it could be extended to other stats for sure. And I like your choosing-a-god example. You could choose a god in a temple, the it takes a few resources and some time to activate the god, after which a certain civ bonus is granted.

EDIT: instructions added to the top post

Warlord, it's not very clear what you mean. Do variations change just because we update something on the game? Btw, random variations are supposed to be random, so they bring more life in the game. However, you can manually select the random seed of a unit of you edit the map xml. So if you have found the right seed one, tog can just copy it over and over. I believe by default the entity id is taken as seed.

Today, the map format changed to allow bigger mountains. Game versions from now on won't be able to read old maps, and older game versions won't be able to read new maps. To convert from A18 maps to A19 maps, you should just run the python script here: http://trac.wildfiregames.com/browser/ps/trunk/source/tools/mapcompatibility/a18_to_a19.py?format=txt (can also be found under source/tools/mapcompatibility/a18_to_a19.py if you have the SVN version). There are more complete instructions per OS below. Converting from A19 maps back to A18 is also possible, however, this will create bad results when your hills are actually bigger than the A18 limit. If you have any problems, please drop by on the chat: https://kiwiirc.com/client/irc.quakenet.org/0ad-dev Instructions for Windows First make a backup of your existing map files. We're not responsible for lost maps. Install python 3.x for your OS: https://www.python.org/downloads/windows/ Open the command prompt, and go to the python installation directory. For example: cd "C:\Python34"Then run the script (depends on where you stored the maps and the script): python "C:\Users\UserName\0AD\source\tools\mapcompatibility\a18_to_a19.py" "C:\Users\UserName\0AD\binaries\data\mods\public\maps\scenarios\mapName.xml"Now you should be able to open your maps with Atlas again, and it should look just the same as before, but give you the ability to make higher mountains. Instructions for Linux Install python 3 as usual on your OS. Then open the shell and go to the directory of the script. For example (depends on where you put the script): cd "~/0ad/trunk/source/tools/mapcompatibility/"And run the script with python3. For example (depends on where you stored the map): python3 a18_to_a19.py "~/0ad/trunk/binaries/data/mods/public/maps/scenarios/mapName.xml"Now you should be able to open your maps with Atlas again, and it should look just the same as before, but give you the ability to make higher mountains.

Our formations are actually entities (like units or buildings), however, they have no model attached, and are thus invisible. So making them visible for selection would be as simple as attaching a shifted model (currently the location of the formation is at the centre), and modifying some code so you don't select the formation itself, but its members instead.

You know you can also use double click to select all units of the same type in your screen, and triple click to select all units of that type and the same rank, and using Alt and one of those to select them in the world? I agree with niektb on the right click issue. Right click is generally used for giving commands (with modifier keys to give alternative commands), while left click is used to select. So it would be best if you could stick with a left click, probably together with a modifier key.

Should be fixed in http://trac.wildfiregames.com/changeset/16472 I also fixed some other things, like changing ownership to gaia might leave gaia-targetting range queries, and starting with a 0 arrow count didn't activate the BuildingAI ever (so also not if a tech modified the arrow count). I hope it works now.

It's a bug, but it's pretty simple to fix. However, my SVN is a bit dirty now (even saving a diff takes ages), so if anyone else can solve it, that'd be great.

AFAICS, the minrange is applied in the Attack component, but the BuildingAI doesn't re-define the range queries. So new towers you build should have the modified min range, or if you change ownership or alliance of the tower. Can you confirm that?

Not for now, the water plane is flat now. But maybe in the future, there could be a number of different water planes, or even a water height map.

Ok, then I'll go with that scenario If you have a proposal for an influence (preferably expresses as mathematical formula), that's welcome. But I think that inverse proportional isn't too bad. 50% damage will make it a lot faster to capture, but the damage gets transferred to the new owner. And as repairing takes a long time, the players who first damage their buildings a lot before capturing will also be more vulnerable for a counter-capture. So instead of two choices: capture or destroy, you'll have a complete spectrum of choices.

Reaction from leper: The health decay should be replaced with a capture points decay instead. This would indeed make more sense IMO

Compiling it yourself should give us a hint of the issues, or could fix it right away. Currently, historic_bruno is the only dev still around with a Windows XP computer. And he's also one of the few devs with an Apple computer, so that also involves solving a lot of platform-specific issues. So don't get your hopes up high for getting this solved soon. Since the game still seems to run on Windows XP, I think our system requirements are correct in that respect (there have been many releases with broken Apple support for Atlas too). If it appears that the game stops working on Windows XP, the most likely thing we'll do is just changing the system requirements. Note however that you don't have to buy a new computer to keep running 0 A.D. You can also install a lightweight Linux distribution on your computer

Did you give your map a name in Atlas? If not, it will show up as "unnamed". Also, be sure to set the filter to "all maps", and look both in the skirmish and scenario selection. If that doesn't work, can you say us where you saved the map? Maybe the path is wrong.

Pathfinder isn't related to vision range. But vision area calculation is a whole different algorithm. Currenlty, that algorithm is highly optimised by using the circle symmetry. It can quickly estimate the border tiles (row per row) without many calculations, and then mark all tiles in between as "visible". By going away from that circle-shaped vision, the calculations will be a lot heavier, so it would slow down the game. I'm not saying that a non-circular vision range isn't possible, but we should try to get rid of the existing lag before introducing features that are guaranteed to add more lag.

@Enrique: I think 50% is a bit early. But apart from that, killing, expelling or converting garrisoned units on capture is all possible. It's just a small difference in code, so this can be decided after playtesting. Since capturing is an attack on its own, the unit wouldn't be able to perform other attacks meanwhile, so it can't defend against incoming attacks. Health decay should indeed stay active when captured. It will be hard to keep track of which buildings were captured or what, so players might have difficulties understanding why some buildings don't decay and others do. @Wijtmaker: I'm not sure about the female capturing stuff. It seems too much trouble for the cheap units we have. About replacing a building with the equivalent for that civ, that's often not very simple. Like Carthagians have two docks, so nobody can capture Carthagian docks and they can't capture others? Similar to some civs that have their heroes coming from other buildings (fortress, CC, special building, ...), or what about the population difference per house? The only really generic buildings seem to be blacksmiths (though without technologies, not worth a lot), dropsites and outposts.

I thought an agreement was reached on the difference between capturing (active) and converting (passive). Units are too cheap and too easy to create to capture with a command. So this is only about capturing buildings.

Some thoughts about capturing Units should be able to actively capture enemy buildings. Instead of the attack they now do. I propose the following game mechanics, these should work for games with or without teams, and even with asymmetric alliances. Capturable component Capturable buildings have a capturable component, similar to health. By default, all buildings start with a number of capture points, assigned to the owner. For example, a fortress belonging to player 1, starts with 5000 capture points for player 1, and none for the other players (in the example there are 3 players) Cp: [5000, 0, 0] When player 2 wants to capture the building, he tasks units to capture it (equal to the attack command, as buildings shouldn't be attackable by units). Bit per bit, the capture points are shifted towards the second player Cp: [5000, 0, 0] > [4000, 1000, 0] > [3000, 2000, 0] > [2000, 3000, 0] > ... Now say player 1 stops player 2 from completing the capture (f.e. by killing all units that are capturing) before the capture is completed, then the capture points distribution stops changing. There are some different scenarios that can happen now. If player 3 comes along, and also tries to capture the building. Say player 2 and 3 aren't allies, then player 3 takes capture points proportionally to the existing distribution. Cp: [2000, 3000, 0] > [1600, 2400, 1000] > [1200, 1800, 2000] > [800, 1200, 3000] > [400, 600, 4000] > [0, 0, 5000] When all capture of the owner reach 0, player 3 owns the building. On the other hand, if player 2 and 3 were allied, then player 3 would only take capture points from player 1 like this Cp: [2000, 3000, 0] > [1000, 3000, 1000] > [0, 3000, 2000] At that point, the owner has no capture points left, and thus loses the building. The owner should lose the building to who did most work to capture it, in this case, the building gets owned by player 2. Selecting on who did the latest capture operation isn't opportune, as captures can happen simultaneously, so the exact switch point can be rather arbitrary. The owner could also chose to re-win capture points even if the building wasn't completely captured. This is done in the same way as just capturing other buildings. Cp: [2000, 3000, 0] > [3000, 2000, 0] > [4000, 1000, 0] > [5000, 0, 0] Note: I didn't consider Gaia in this context, Gaia buildings are possible, and players should be able to capture from Gaia, so Gaia should simply be player 0 here Statistics Some sort of armour (like in the attack) isn't needed. There's only one way to capture a building, so there's no need to balance the difference with different armour stats. On the other hand, the units will need a separate capture attack, with all details a normal attack has (repeat time, amount of capture points, ...). Effect of garrisoning on capturing Garrisoning should probably help defending the building. I think each garrisoned unit should act like it's constantly re-winning capture points for that building. Keeping siege engines useful Of course, capturing is all neat, but there must be a way to keep siege engines useful. Here I see two possible possibilities. But are based on the principle that siege engines harm the building in a way that makes it easier to capture. For the first possibility, siege engines attack like normal, reducing the health of the building. But the health of the building also relates to how vulnerable it is for captures. F.e. if the building is only at half the health, it becomes double as easy to capture the building. This takes the "harming makes it easier to capture" thing pretty much literally. However, it might make the UI more difficult (having health and capture points for buildings), and it might also make it more difficult to understand and balance. A different result would be that players can capture each others buildings more frequently. If one player damages the building to capture it, it will stay damaged for until the reparation, making it easier for a different player to capture it again. Thus this could result in a more vivid gameplay. For the second possibility, siege engines don't attack to demolish, but instead have very strong capture stats. This could fully eliminate the need of a health component for buildings. It could make the UI cleaner and easier to understand, which also means easier to balance. It could also make translations easier (translating health is really hard when it counts for buildings too IMO). The drawback is that it would probably break the AI harder than the other possibility. As the AI wouldn't be able to check health of buildings anymore. However, such a major gameplay change is expected to need AI modifications anyway. With the second choice however, when re-winning capture points of your own buildings, it would look silly to use siege engines for that (like you're demolishing your own building). So it should be possible to limit siege engines from capturing on buildings you own, and there should probably also be possible to give a bonus to other units, so the lack of siege usage can be compensated. Keeping captured buildings useful Captured buildings should stay useful to some degree, however, they shouldn't allow you to virtually switch civilisations (like getting the sudden ability to reconstruct the entire enemy civ from one captured building). So I propose the following: Buildings should still be able to produce all units they can produce. This reflects that different civilisations often used concurred civilisations in their own army, and of course, concurred people would work for the concurror. A possible exception to this are the heroes. Heroes should probably stick with the right civ. Although there are also stories of heroes who changed alliances.Units should only be able to build buildings from their own civilisation. So if you create a soldier from a captured CC, you won't be able to use that soldier to build a fortress of the enemy.Technologies on captured buildings should be completely disabled. First of all this avoids technical problems where different techs are used for the same purpose (f.e. the Athenian civ has a special town phase tech, and you shouldn't be able to research the town phase twice). But it also reflects the history that many civs stopped developing new technologies when they were concurred. The drawback is that this makes the blacksmith useless as captured building, but that's only a very small issue IMO.All the other things (attack, population bonus, the ability to drop resources, ...) should transfer directly to the new owners.Destroying buildings Destroying buildings should still be possible (f.e. you reached the tower limit, and you want to build more towers towards the enemy). However, it shouldn't be possible to destroy a building right before it's captured. So I propose only if the owner of the building also holds the majority of capture points, he would be able to destroy the building GUI For the GUI, I see it similar to the health bar, but instead of using a green-red bar, the bar should be divided in a number of parts, showing the playercolour partitions instead. As the numbers are also important, they should be showed too in some way, however, I'm not sure if all numbers are needed. It might be enough to show the capture points you have on the building, and which player has the most capture points on the building (so which player will be the next owner if the owner is defeated). That makes it easier than showing an array that can possibly be 9 numbers long, while it still gives you enough information to play the game I think. So, tell me what you think of it, I'm wondering if you consider this a good concept or not.

As you see from the (lack of) activity in this thread, we still don't have a sound leader. So Enrique, as art leader, would probably be the best choice. However, you can also just post them for display on the forums for community review. You probably know the requirements, but most sounds should be rather short (a few seconds), and animal sounds are best when there are a number of variations (else the sound becomes boring), however, it's still important to keep them recognisable.

A bit of dirt would be welcome indeed. Also, when it will be used for the Briton civ, maybe it could use some paint. Most of the half-naked Briton units show some blue body paintings, and as dogs were important to them, I wouldn't be surprised if they also painted their war dogs a bit. But I have no evidence of this.

Not sure what explorers would be, other than our normal units.