Leaderboard

0 A.D. in Print (19/Jul/05) web.archive.org

For alpha 25, archer elephants were given 2 population per elephant and this makes them really bad in a cost/power relationship. I think the 2 population should stay, but they should be given a fire rate bonus for each rank up. This would be a good way to represent the extra archers that visually appear on rank-up. Considering this would be a substantial buff, perhaps it makes sense to add some XP to rank ups, but this could be determined in testing. rank 1: 1 second rank 2: .5 second rank 3: .333 second This would mean that extended battles with a few elephant archers would yield dividends in the long term, but big masses would get killed and not be as effective. rank 3 elephants would also be something for an enemy to prioritize in battle, so a mauryans player would want to keep them alive. From a balancing and realism perspective, I think it makes good sense and offers a functionally unique unit.

Hello team I was wondering... Athenians and Macedonians are the only remaining factions to share buildings. Are there any plans to create a new set of buildings for either of them?

In fact, I think it should be lower, or in other words, pikeman should have lower protection for long-range weapons than spearmen.

It's not planned as in there is no one currently working on it, but if someone wants to work on that it is welcome.

I think the champion's armor and attack should be slightly higher than the maximum armor and attack that a citizen soldier of the same type can get from combat experience or a blacksmith. The positioning of Cataphracts and chariots needs to be adjusted in the later alpha, they should be very different units from the general cavalry spearmen or cavalry archers.

whey i use open source system like for example matrix clients and not discord: The Discord communications system requires running a nonfree client program. The program reportedly collects lots of data about users. Discord insists on tracking users. If a user connects through a VPN, Discord demands that user provide a phone number. Discord locks accounts that don't have associated phone numbers. do we learn form the past?I respect of course if it has to be like that. most important friend etc. but if you see a possibility. please think twice if possible

Thank you and to all the developers for giving us this great game!

Thank you for your effort on this! I must say this Design Document rather looks like an result of one? It looks more as an implementation of a design than a design itself? But I could be mistaken. For a DD I would expect more something along the lines of the tail of this post:

Unidades lusitanas junto a los edificios en los que se reclutarían; (Cuando me den los modelos de los caballos , añadiré sus texturas , algunos autores clásicos citan que tanto los guerreros como sus monturas , tenían a a veces" Pinturas de guerra" , por eso en algunos modelos los caballos tendrán dichas pinturas) (Reclutados en ;"cuarteles") 1. Lancero ;----------------------------------------(Scortamareva) 2.Hondero ;-----------------------------------------( Trokalobutiam ) 3. Espadachín ;-------------------------------------( Caetranan ) 4.Escaramuzador raso ;----------------------------( iovanan ) 5.Arquero ;-----------------------------------------(Aecandus) (Reclutados en ;"galería de tiro") 1. Arquero ;-----------------------------------------(Aecandus) 2.Hondero ;-----------------------------------------( Trokalobutiam ) 3.Escaramuzador raso ;----------------------------( iovanan ) (Reclutados en ;" Castro de élite" ) 1. Noble;--------------------------------------------------( Arimo ) 2.Emboscador;--------------------------------------------(iabarannta) 3.Mujer guerrera;----------------------------------------( Petanim Kori) 4.Bandolero lusitano;------------------------------------(Epones wulti) (Reclutados en ;" castro vettón" ) 1. Lancero vettonón auxiliar( con lanza); ------------------------(Scortamareva Secias) 2.Hostigador vettonón auxiliar(con venablos);---------------------(iovanan Secias) 3.Jinete auxiliar Vettón(con laza);---------------------------------(Epones Secias) (Reclutados en ;"establos" ) 1. Jinete lancero ;----------------------------------------------------( Epones Pretre ) 2. Jinete escaramuzador ;--------------------------------------------( Epones Aeiste ) 3.Bandolero lusitano;-------------------------------------------------(Epones wulti) (Reclutados en ;" centro urbano") 1. Mujer;---------------------------------------------(Nurim) 2. Lancero ;----------------------------------------(Scortamareva) 3.Hondero ;-----------------------------------------( Trokalobutiam ) 4.Jinete Escaramuzador ;---------------------------( Epones Aeiste ) (Reclutados en ;"Mercado ") 2. Comerciante;----------------------------------------------------(Muitiom) (Reclutados en ;"Santuario ") 3'1. Sacerdote;-----------------------------------------(Sintamo ifadem) "Anciano santo" 3'2.sacerdotisa;----------------------------------------( Deiwos ampilua ) "Sirvienta de los dioses" /o/sacerdotisa. (Reclutados en ;" Taller de asedio") 1.Ariete ;------------------------------------------------------(Rueti kori) 2.Escalas;(escaleras)----------------------------------------(darna parami Kori) 3.Guerrero Lanzador de rocas;----------------------------(Aecandus Karno Kori) (Tuve una errata antes ,No es "Darna" sino "darna". (Reclutados en ;" embarcadero") 1.Balsa pesquera ;--------------------------------------------------(Longo ) 2.Balsa de guerra;--------------------------------------------------(Lango kori) 3.Balsa de Cauceno(héroe);----------------------------------------(Lango Kaikainos) (Reclutados en ;" factoría púnica") 1.Navío mercante fenicio;------------------------------------------(Lango muitiom secias) 2.Navío militar cartaginés ;-----------------------------------------(Lango kori secias) (Reclutados en ;"Fortaleza") 1.Viriato ;--------------------------------------(Virilos ) 1.Púnico ;--------------------------------------(Apimano) 3.Cauceno;-------------------------------------(Kaikainos ) (solo los modelos de jinetes) Disculpen las molestias*

This. Consensus governance inevitably tends toward conservatism and policy gridlock (sometimes punctuated by episodes of violent identitarianism). If you can't get everyone to agree to do something, then the one thing you can agree to do is nothing. The Romans understood this, which is why they permitted the office of Dictator to be instituted during moments of crisis. Maybe this project needs a Balance Dictator? If you are looking for a policy proposal, here's what I would do if I were Princeps: First, a counsel of the most active developers should be convened to discuss candidates and appoint the balance dictator. Whoever they pick will then get 2 years to enact any balance overhaul plan they think is necessary, without any obligation to consult with the council of active developers or anyone else. To do this the dictator would for their 2 year office exercise a non-negotiable discretion to summarily approve or block any changes to the 0 AD development codebase and design documents, without any binding responsibility to defend or explain their reasons. At the end of their 2 year office, the active developers or the community at large would vote whether to revert the dictator's balance contributions, and/or whether to elect a new dictator or extend the current dictator's office for another term. If no one can agree to enact such a plan (or any reasonable alternative), or if the dictator or other parties violate the terms of the concord, that'd be viewed that as strong evidence that the current design is effectively locked in. In that case the active developers should adopt a binding resolution to spend the next two years excising any problem/unfinished features from the work and release it at the end of that period... as 0 AD Beta 1! But that's just my 2 cents. There are obvious risks to investing too much authority in one person. Even if the person with absolute power is a perfect saint, you risk alienating anyone anyone with a good faith difference of opinion about the direction of the project. But at the end of the day you are not trying to run a country here, you are trying to make a world-class video game. People don't need to be happy with the development process for the project to be successful, just the end product. P.S. "I love democracy..." /Palpatine.gif

Sorry but all this talk of GOLD is premature as it DOES NOT EXIST as a resource in the main game there is only Metal,Wood,and Food.Metal includes all metals so it's an abstraction not realistic and adding more micromanagement to mines is just tedious time wasting for no purpose but geek points. Enjoy the Choice

That info is from 8th Century. They must have changed... Siege weapons Edit "During the siege of Hermopolis in the 8th century BC, siege towers were built for the Kushite army led by Piye, in order to enhance the efficiency of Kushite archers.[61] After leaving Thebes, Piye's first objective was besieging Ashmunein. He gathered his army after their lack of success so far, and undertook the personal supervision of operations including the erection of a siege tower from which Kushite archers could fire down into the city.[62] Early shelters protecting sappers armed with poles trying to breach mud-brick ramparts gave way to Battering rams.[61] The use of the battering ram by Kushite forces against Egyptian cities are recorded on the stele of Piye" https://en.m.wikipedia.org/wiki/Military_of_ancient_Nubia """Then they fought against "The Peak, Chest of victories"...Then a battering ram was employed against it, so that its walls were demolished and a great slaughter made among them in incalculable numbers, including the son of the Chief of the Ma, Tefnakht....""" — Victory Stele of Piye.[63]

During the Iron Age, in the ancient Middle East and Mediterranean, the battering ram's log was slung from a wheeled frame by ropes or chains so that it could be made more massive and be more easily bashed against its target. Frequently, the ram's point would be reinforced with a metal head or cap while vulnerable parts of the shaft were bound with strengthening metal bands. Another type of ram was one that maintained the normal shape and structure, but the support beams were instead made of saplings that were lashed together. The frame was then covered in hides as normal to defend from fire. The only solid beam present was the actual ram that was hung from the frame. The frame itself was so light that it could be carried on the shoulders of the men transporting the ram, and the same men could beat the ram against the wall when they reached it.[3] Many battering rams possessed curved or slanted wooden roofs and side-screens covered in protective materials, usually fresh wet hides. These hide canopies stopped the ram from being set on fire. They also safeguarded the operators of the ram against arrow and spear volleys launched from above. A well-known image of an Assyrian battering ram depicts how sophisticated attacking and defensive practices had become by the 9th century BC. The defenders of a town wall are trying to set the ram alight with torches and have also put a chain under it. The attackers are trying to pull on the chain to free the ram, while the aforementioned wet hides on the canopy provide protection against the flames. By the time the Kushites made their incursions into Egypt, around 715 BC, walls, siege tactics and equipment had undergone many changes. Early shelters protecting sappers armed with poles trying to breach mudbrick ramparts gave way to battering rams.[4]

By the time the Nubians made their incursions into Egypt, around 715 BC, walls, siege tactics and equipment had undergone changes, mostly influenced by developments in the Asiatic East. Early shelters protecting sappers armed with poles trying to breach mud-brick ramparts gave way to battering rams. Enclosures were still erected, preventing surprise attacks, but raised platforms from which the town could be showered with missiles, which decreased the advantage the defenders had on their tall ramparts as we find from Piye's siege of Hermopolis in Egypt: Behold, [he] besieges Heracleopolis, he has completely invested it, not letting comers-out come out, and not letting goers-in go in, fighting every day. He measured it off in its whole circuit, every prince knows his wall; he stations every man of the princes and rulers of walled towns over his respective portion. http://www.touregypt.net/featurestories/siegewarfare.htm probably on wheels. Other can be more like this.

The goal would be to make them competetive with skirmisher dps which is more reasonable for the cost and population space. On second thoughts your values are probably better.

As mentioned at https://wildfiregames.com/forum/topic/77438-looking-back-on-the-balancing-strategy/, a new design document is required. This is my proposal for a design document. If the community approves of this, it could be adopted and design documents could be revised for the civilisations. This is a design for the general gameplay, not for any civilisations. Most elements will remain the same, I've only mentioned elements that could change or which need to be clearly defined. All features which require mechanics not yet added to the game are highlighted in red.

you are right when you say that clear and throughout design is a good thing when developing software. this is something 0AD lacks. but don't let you be distracted by it. that level of design comes right before implementation, and should be the product of the dialogue between the developers who are currently working on that issue, and the community (in a corporate setting, that would be called customer oriented - also consider the Agile statement that working software is more important than comprehensive documentation, and that responding to change is more important than following a plan). if you put design too much before development, than you are building on quicksand: even the most polished design may prove ineffective or brocken in the end, for whatever reason you couldn't foresee. a design document should indeed look much more alike what hyperion proposed, and finally, it would be very useful if really adopted by the team and its management: I can see here that people are still confused about what civ differentiation should achieve, what level of micro should be required, how good is rock-paper-scissors design, what's should it be the purpose of territory, what level of snowballing is best, why some tactics are considerd abusive and some aren't, etc...

When will we allow livestock to be stolen like in the age of empires? I think this has a great influence on joining the nomads in the future. Would you like to start working on a patch or mod now?

IMO, what makes a good design document is that the design document + the technical documentation of the engine and and any other development tool + any good encyclopedia should give enough information for any competent developer to deliver the completed product. Yes, that does not usually require specifying exact unit stats or civilizations to include, but that is because this information is implied by the more general descriptions of the gameplay and the scope of the project given by the design doc. On the other hand though sometimes is is necessary (or maybe a better word is proper) to get into specifics. The most useful thing the design doc can do is let you detect problems before you go to the trouble of actually writing code. That is easier to do when systems are described directly. (This is why I suggest describing counter cycles in detail, we know that this is a hard thing to get right. Being specific about them makes it easier to to spot any contradictions and logic holes before someone has to start interpreting the intent into working code. Their job is hard enough already.)

If we make chariots, and cataphracts more unique, then they will be strengthened and it will be necessary to change the training method.

Lower the experience and increase the health bonus received per level.

I disagree, but you should be wary, sure. If you always assume the worst thats prejudice, and with prejudice you will bring out the worst surely. I wholeheartedly hate generalisation.

Estoy planeando Xianbei, Yanzhei...y los obvios Hunos para la segunda parte.

But the player pays for them?

One could try "!Animal".

Thanks for your effort! Really appreciated.

Buenos días o tardes: -Es muy buena publicidad , para aquellos/as que no hablen español les resumiré que este Youtuber dice ; -Es muy buen juego , que él hizo este vídeo para que llegue a más gente e invita a colaborar en el desarrollo , anuncia que es gratuito ,anima a la gente a jugarlo , felicita la fidelidad histórica y explica las mecánicas del juego , como el área cultural de los edificios entre otras cosas. Disculpen las molestias*

@Stan` @wowgetoffyourcellphone Today, I tested the SVN26824 and when I loaded the map, the error appeared. ERROR: JavaScript error: gui/maps/MapCache.js line 25 JSON.parse: expected ',' or ']' after array element at line 6 column 5 of the JSON data getMapData@gui/maps/MapCache.js:25:73 getFilteredMaps@gui/maps/MapFilters.js:52:32 getAvailableMapFilters/<@gui/maps/MapFilters.js:15:9 getAvailableMapFilters@gui/maps/MapFilters.js:14:23 checkMapTypeChange@gui/gamesetup/Pages/GameSetupPage/GameSettings/Single/Dropdowns/MapFilter.js:35:20 onSettingsLoaded@gui/gamesetup/Pages/GameSetupPage/GameSettings/Single/Dropdowns/MapFilter.js:19:9 onLoad@gui/gamesetup/Controllers/GameSettingsController.js:98:4 SetupWindow@gui/gamesetup/SetupWindow.js:61:11 init@gui/gamesetup/gamesetup.js:47:18 onPress@gui/pregame/MainMenuItems.js:99:13 performButtonAction@gui/pregame/MainMenuItemHandler.js:77:9 pressButton@gui/pregame/MainMenuItemHandler.js:63:10

https://trac.wildfiregames.com/changeset/26825

well, while I agree that the economic value of these units makes them a little harder to balance, there would certainly be other things people complain about if there were no CS units. In my opinion, CS balance is quite good this alpha, aside from pikes. The nerf pikes received seems appropriate to me. Honestly, at least in recent history, most complaints are over champions (esp. fire cav) and merc cav. yes, and I think the attack ground aspect of this adds an amount of skill to the fights you described. In 0ad, the "death balls" you described are enabled by the meatshield meta. Currently, using fast units with high dps (swordcav) are really effective if you can avoid spears. This can be almost as devastating as siege in AOE2. For infantry battles, you can even use archers or slingers to manually target ranged units past the meat shield, although this is difficult. I think we could add attack ground to essentially represent a volley, which would more effectively deal damage to ranged units and avoid overkill. This would in theory result in more movement or perhaps formation usage. Not a lot of people agree with my idea here, but I think the answer to the meat shield meta should be something skill based.

people are going to get excited about this. Mayans..Japanese...Nomads...

What I think about is how not to add new types of resources. To be honest, it is not impossible to use a warehouse as a recycling point.

@Stan` This is really well done presentation. Excellent travail.

Gaugamela it wasn't a little more arid terrain?

This would be good, yes. I'll update the proposal to reflect this. The eventual design document should include this, certainly. However, for this proposal I'm only listing any features that I think should be changed or which I think need to clarified. This sounds like a good idea, but I'm not sure if it really fits in the general design document. This could be done along with the pages for the individual civilisations, but I think the overall design document should describe how the game should play in general, not the specifics of civilisation design. I will add the information about viable counters, thank you. Perhaps, but I'd like to keep this issue as centralised as possible for now. I have tried to avoid adding anything too controversial, so I don't think that should be too much of an issue at the moment.

THERE IS NO SUCH THING AS GOLD AS A RESOURCE IN THE MAIN GAME. Enjoy the Choice

Right. Because of the citizen-soldier concept, any cost adjustments or any stats changes, such as speed, have an economic impact. Without the c-s concept, these aren't such an issue. It's one of the reasons I got rid of it in DE (plus soldiers randomly chopping trees in the middle of a battle due to mis-click, lol).

good point. I think we can and should take inspiration from game-mechanics of other games such as those, but we should not just port them over just because those games are more popular. For example, "arson" attack mechanic from aoe3 and 4.

You can progress economically with the res that starts in p1, but players already do venture away from their base for metal mines, extra berries, hunt and sometimes a preferred woodline. Restrictions 1,2, and 6 would do nothing but bring frustration to building the base. I could not image playing with these artificial and uncomfortable rules. The other things such as auras sound nice but I would be worried about having too many auras as I think I heard this contributes to performance issues. There are frequently mercenary rushes, border skirmishes, cavalry harassment, and the occasional all out attack in p2. P2 does have way to take out buildings, but no siege. Keep in mind that destroying the cc is not the only way to deal damage. This game is, in fact, not AoE3 and not Age of Mythology. I can't understand why you want to make 0ad into those games.

I think the way the roles are divided are pretty good and logical and is something that makes 0AD more unique imo. It takes some time to learn the differences for new players but learning is not a bad thing. You wouldn't hire a mercenary to collect wood, they are hired to fight. Champions are proper combat units, surely you wouldn't send your best trained men to work in a mine. You would send lower class citizens to do that job. Not saying it's perfect though but i think the role dividing for units should stay.

I think moving (most) heroes to the CC would integrate them a little bit more into the game. I know it's a simple change, moving them from the fortress to the CC, but I'm thinking about the psychology of the player, seeing the Hero there in the training panel from the outset, instead of 15 mins later when they build a fortress. Honestly, I'd really push for something along the lines of DE's hero choices, but I know that's too radical (!!!) for the current crop of stakeholders. You almost need a whole new set of players and developers in order to propose significant improvements, because all of the current stakeholders are so wed to the status quo. Don't say I'm wrong, when even simple changes are controversial.

To be honest, I think the call to for a design document isn´t rooted in practical purposes. I would consider the hope that a design document provides misleading. You might think that things get done once it is clearly put in a design document, but issues don´t magically solve itself when there is a design document. I expect any design document to quickly get stale. So rather than saying this is the design document, It would be probably better to set goals for the next 3 alphas and count how much has been achieved to reach these goals. There was some talk about faction differentiation, but what have the discussion since A24 delivered? Hoplite tradition and moving possibly kush pyramids to p1. You can´t say we should achieve this goal and just wait until it is achieved.