Leaderboard

I've been thinking on how to tackle the attack animation and maybe tearing and shaking would look silly if not close enough to the enemy. Right now im working on idles... sitting, scratching, ball licking... fun stuff lol

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.

That isn't really ideal reference material. I try to google for other, but it's difficult to find anything suitable (and they all seem to be different). I'm done with this one (still needs diffuse texture, but normal map looks OK) helmet.zip

@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 like your proposal a lot Sanderd. My vote is to make buildings easier to capture when damaged. This method could lead to new techs for faster repairing as an example. Units capturing buildings I guess aren't able to fight back while capturing? Capturing a garrisoned building that fires arrows would require a bigger number of units to capture based on this, so Im ok with that. Also enemy garrisoned units will be forced out when ownership drops below 50%? Or garrisoned units will be converted if they aren't ungarrisoned before full conversion? Last question, health decay based on unconnected territory will still be valid for captured buildings? Or at least will be allowed to repair them?

Sorry if this has been discussed before but are there any plans or considerations to implement a 'line of sight' system for ranged units like archers? For example: make it so that archers and ballistae cannot shoot through tall buildings and walls unless standing on higher ground such as atop a cliff or tall hill. Exception will be some stone throwing siege units that shoot in arcs who can shoot projectile over them. I think it will vastly improve the game by adding to realism and making strategic gameplay deeper. It mean walls will become more useful in protecting your units and structures and provide a reason to mount units on walls; and make unit dynamics more varied depending on situations: such as melee units having an edge over archers in built up areas. Of course, that's if the engine can support this. Does it?

Fun fact 10 years ago 0 A.D. originally had only these civs: Celts Hellenes Iberians Romans Persians Carthaginians Two of the civs "branched" into sub-civs (celts - britons, gauls & hellens - sparta & athens). But, this was intended to happen during the game as a strategic choice - not something you decide and set in stone before the game even started. The choice would have shown itself during one of the town/city upgrade phases, and would have affected the hero choices, special structures, and late game technologies. I'm not saying the existing method is bad, just that I personally like the concept better (more strategy, easier to balance) than having dozens of civs that are slightly different from each other to choose from at the start. But... it is no longer my decision to make and hasn't been for years. I'm just throwing the idea back on the table

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.

https://www.youtube.com/watch?v=MwZW3i2KT-s

Here's the improved animation and texture. I used no shading so you can judge the "real color" of the texture here (the earlier shot I think I messed up the material/lighting). Do you think it still needs more dirtyness? http://makeagif.com/i/gEGUgk

The python tool written by wraitii (unitTables.py) doesn't help? It creates a file unit_summary_table.html ... Example attached. unit_summary_table.html

This is a mistake on their part. Like I said, it is all math anyway. It is just as valid to make a hard counter ( a multiplier) to do what you want units to do as to fiddle with other numbers to attempt (and fail) to do the same thing. There is no "win" in spending hundreds of man-hours in making soft-counters work when hard-counters are already there and workable. Only the end product matters The current developerrs certainly have the "direction" they want to take the the combat. It is possible that direction will change when new developers come... current developers seem pretty committed to current thinking, which is why I make my own mod). But if there is good idea I am sure they will consider. They dont communicate much on the forrum. Maybe you can try chat room.

Hmm, looking at full map screenshot makes me believe even more that the game need true mountain meshes. Example:

yeah first we should try these maps and make a list of the potential good maps for multiplayer (I'm really bored of mainland ^^)

http://www.gamersbook.com/News/Article/ID/1954/WarCraft-Armies-of-Azeroth-Trailer-Shows-Alliance-Gameplay

I believe there is not much more to be done. (compared to the screenshot above I did another pass on the grass btw). I must say I really like the visual style of the map. The only thing I'm not sure about is the massive presence of gaia soldiers and buildings (since they're not really smart). Alpine_Mountains_(3).zip Alpine_Mountains_(3)_SVN.zip