Nescio

Yes, it is: art/actors/structures/carthaginians/palace.xml

Yeah, that would be great, provided no unnecessary zeroes are added (e.g. 2.000 or 0.200 instead of 2 or 0.2).

Yes, but the footprints are already larger than the actor itself, e.g. spart temple:

Apparently 0 + 0.2 + 0.2 + 0.2 = 0.6000000000000001 and 0 − 0.1 − 0.1 − 0.1 = 0.30000000000000004: Rounding everything to the nearest integer won't work for me, because trickle changes in my 0abc mod can be as low as 0.005.

As you can see the numbers under “Resource Trickle:” are quite ugly; they ought to be 0.59, −0.34, and −0.31. Is there a way to hide those trailing zeroes and nines? Also, the line-break ought to occur before the minus, not after.

Foundation size is footprint / 4, right? I get somewhat different numbers: kush temple amun: 32×62 → 8×16 pers ishtar gate: 40×17 → 10×4 pers taçara: 40×24 → 10×6 rome army camp: 40×40 → 10×10 rome temple mars: 24×44 → 6×11 spart temple: 19×37 → 5×9 And wonders: athen, mace: 28×58 → 7×15 brit, gaul (ought to be replaced, because pre-Celtic): circle, r=30; obstruction 55×55 → 14×14 cart: 29×59 → 7×15 iber: 43×43 → 11×11 kush: 48×66 → 12×16 maur: circle, r=31; obstruction 57×57 → 15×15 pers (ought to be replaced, because pre-Persian): 62×62 → 16×16 rome: 46×54 → 12×14 sele: 29×59 → 7×15 spart: 35×64 → 9×16 To summarize: wide: 10×4, 10×6 long: 5×9, 6×11, 7×15, 8×16, 9×16, 12×14, 12×16 square: 10×10, 11×11, 14×14, 15×15, 16×16 (maybe also add 12×12 and 13×13 to complete the sequence) If you have time, perhaps you could write a trac page on how to create additional foundation sizes in the same style? It's not unlikely that future wonders will have different dimensions (e.g. Terra Magna chin wonder: 48×43 → 12×11)

Also, we might have a look at how similar entities are called in similar games: Age of Empires, Age of Kings, Age of Mythology: town center Cossacks: town hall Empire Earth: settlement → town center → capitol Rise of Nations: small city → large city → major city Perhaps 0 A.D. has chosen Civ/Civic/Civil Centre deliberately to differentiate itself; I don't know; having a phase-related name (village center → town center → city center) instead could be nice as well.

Reducing their building time is not a bad idea. For comparison: Kushite barracks: village phase, 150 wood, 150 stone, 150 s, 2000 health, six unit types Blemmye camp: town phase, 100 wood, 100 metal, 200 s, 1000 health, one unit type Nuba village: town phase, 100 wood, 100 metal, 200 s, 1000 health, two unit types [EDIT]: here you go: https://code.wildfiregames.com/D1863

Anyway, it's not just about spelling (-re or -er), but also about vocabulary (sidewalk, pavement, or footpath).

Apparently en-GB-oxendict is the correct tag, according to http://www.iana.org/assignments/language-subtag-registry/language-subtag-registry I'm not sure it's worth it; we don't have en_AU or en_CA either.

en_GB is available under translations, yes; en_US is the game's default language.

True, but in principle reviews can be done by non-team members. Getting more people engaged in the development process can be helpful in the long run.

No. The primary difference is that Oxford spelling uses -ize (because -ιζειν) and British uses -ise.

Personally I favour Oxford spelling, which is distinct from American, British, Canadian, and other national varieties, and is used by international organizations such as the United Nations and by numerous scientific publications. But yeah, 0 A.D.'s style guide says we should use American spelling.

If everyone is reluctant to commit anything, then nothing gets changed. It's not about any specific proposal getting accepted, it's about the general fear and lack of gameplay changes; the last one I remember was rP21285, over a year ago. Furthermore, the primary responsibility for checking, testing, and fixing ought to be with the reviewer(s), not the committer. I know that currently the person who commits something typically reviews it as well, but in person A can propose a patch, person B review it, and person C commit it. What do you mean exactly? An updated design document is useful for outlining a general vision and listing what's in game (resources, civilizations, structures, units), but it's less relevant for balance and actual stats. Besides, it ought to be a guideline, not a dogma; opinions can change over the years. Regardless, tweaking can (and should) be done without a design document; e.g. rams are too strong vs units; let's give halve their base damage and give them a 2× bonus vs structures slingers are too effective; let's give them pierce damage instead of crush rome_hero_maximus.json aura is too powerful (structures and units +1 armour globally); let's change it to a 80~m range aura wonder food cost doesn't make sense; let's remove it and double the wonder's stone cost unit U is considered too weak, it currently has X health; let's increase it to Y; it turns out Y is too much; let's change it to Z etc. Again, if something turns out not to be a good idea, it can be changed and reverted. You never know if it's not tried out. There is no harm in experimenting.

Yes, I mean get them committed, and that's currently where the problem is. E.g. D1761 ( poll and discussion ) or D1762 ( poll and discussion ).

In that case we would get `template_structure_civic_civic_center.xml` and `template_structure_civic_civic_center_military_colony.xml`. Also, civic centre has apparently (https://en.oxforddictionaries.com/definition/civic_centre) different meanings in British (area with municipal buildings) and North American (sports and entertainment complex, e.g. https://en.wikipedia.org/wiki/Columbus_Civic_Center) usage. Functionally, the 0 A.D. entity is not just a civic structure, but also defensive (garrisonable, shoots arrows), economic (resource dropsite), and military (trains soldiers). So if these templates are to be renamed, we might as well look critically at what they should be called.

Frankly, I don't quite understand this reasoning. Balance isn't perfect at the moment, never was, and I doubt it'll ever be; nor does it have to. And even if balance were perfect, there would still be plenty of room for gameplay mods. Anyway, most values in game seem to be rather arbitrary; replacing one arbitrary value with something less arbitrary could be considered an improvement. And if something doesn't work out, it can be reverted or changed again. Establish some simple and clear procedure, e.g.: identify a problem suggest a solution make a patch on phabricator and a tiny gameplay mod which contains only the exact change(s) launch a couple of test games, for different maps, map sizes, civilizations, number of AI players, etc. find other people to discuss, play-test, approve, or review your proposal get someone to implement the patch Only the last step requires a team member, everything else can be done by others. Just let the game evolve.

It would be nice if there were some clear procedure to get simple gameplay changes implemented. 0 A.D. has greatly improved over the years and a lot of content has been added, but when it comes to gameplay, fundamentally the status quo has hardly changed. @borg-'s and other mods do much more than just a few balance tweaks and are therefore not straightforward to implement. Overhauling everything at once is not necessarily a good idea. Doing it in small steps is preferable, because then it's easier to explain what has changed and why. For instance, the last stat tweak of rams was 3 years ago (18735); since then it has been frequently pointed out that rams are still too powerful, yet nothing has changed so far.

Don't use tinypng.com or similar services; what it does is convert 24-bit (i.e. 1677216) colours into 8-bit (i.e. 256) colours, which means you lose information. By contrast, the `pngcrush` command only removes unused file data.

Fix what? The Mauryan hero auras work as they're supposed to. PS Thank you for the new structure foundation sizes!

You mean the player colours as defined in simulation/data/settings/player_defaults.json? That's very easy to modify; you can also use diplomacy colours (customizable under Settings/Options/In Game). However, it won't make much of a difference if a texture hardly contains any player colour.

People are free to create mods with enhanced textures, but I don't think it's a good idea to include two versions in the main distribution; the art/textures/skins/ folder is already close to 1 GB. There must be cleverer options; cf. Unit Silhouettes.

Related, player colour for Persian elephants (back) is clear at a single glance, for Kushite elephants (front) it's not:

Keeping only one version of identical actors makes sense; less duplication. You might want to have a look at Carthage's Iberian mercenaries too; currently it's a bit inconsistent: simulation/templates/units/ – Actor cart_cavalry_swordsman_gaul_b.xml – celts/ cart_cavalry_swordsman_iber_b.xml – carthaginians/ cart_infantry_javelinist_iber_b.xml – iberians/ cart_infantry_slinger_iber_b.xml – carthaginians/ cart_infantry_swordsman_gaul_b.xml – carthaginians/