odalman

Fixable with a client/server architecture (a lot of work to implement and somewhat more bandwidth use) or streaming (some work to implement, huge bandwidth use, need for advanced graphic hardware and power to run it for each player on the server side, probably lower graphic quality due to some lossy compression, and some lag). For now, just play with full vision to make it equal for all players. I assume that you mean many wall sections built from a turret. Easily fixable by requiring a minimum angle between them. I assume that you mean for example the "lethal deathboat" with 17 catapults. Could probably be fixed with some effort. I assume that you mean infinite food from corrals or fields combined with bartering in the market. This gives infinite resources, limited by the time the market needs for the barter rate to regenerate between barters. Seems like a feature. If it can somehow be done instantly it is a bug and probably fixable. Another issue on the list is unit dancing to avoid projectiles. That should be fixed with a more realistic unit motion model involving acceleration and direction change. This requires quite a lot of work and should probably have the highest priority among the major fixes. For now, someone could implement a user-interface mod that spreads out attacks in time. For example, if a user selects 20 archers with attack rate of 1 Hz and clicks to attack a nearby enemy unit, his user interface could send an attack command for each of them with 50 ms between them. That should make it harder to avoid projectiles. Seems like a feature that lets the player focus more on higher level strategic issues and makes the game less of a clicking contest. Of course, those who want a clicking contest should play against each other and not the rest of the players.

Rules only enforced by honesty have certainly been considered previously. For example players not looking at (and listening to) things that should be hidden from them in Widelands was discussed back in 2003-2004. It is trivial to modify such a game to see and hear everything. In just an evening, someone familiar with C++ but not with the 0 A.D. code can check out SVN, figure out which dependencies are needed and install them, get it all built, look around the code and find the places that need to be modified, change and test until it works. (Some things in the game might be hidden from the user by code written in JavaScript and would need some extra effort to modify.) The linked wiki page discusses how this could be solved by a client-server architecture, like FreeCiv has, and how much bandwidth might be needed. An idea not mentioned there is a hybrid approach, where a set of trusted servers run the simulation in parallel like 0 A.D. does now, and each can act as a server for clients nearby on the network. That could for example keep intercontinental network traffic low, while using more bandwidth on the shorter routes to the users, enforcing incomplete knowledge of the game state. Another approach that was not considered back in those years, was streaming the game (video and audio to the client, input back to the server). That would use immense amounts of bandwidth, which is actually available in many places nowadays, while enforcing incomplete knowledge and preventing many kinds of client-side game automation (like autotrain or logic to make units do something useful when they become idle), which some might consider to be cheats.

Which is the effect of the Theatron? I find different percentages. And are only Macedonians limited to building 1 only? theater.json:5: { "value": "TerritoryInfluence/Radius", "multiply": 1.2 } theater.json:7: "auraDescription": "Structures +20% territory influence radius.", civs/athen.json:98: "Special": "The Hellenization civ bonus. Building a Theatron increases the territory effect of all buildings by 25%." civs/mace.json:88: "Special": "The Hellenization civ bonus. Building a Theatron increases the territory effect of all buildings by 25%. Build limit: 1." civs/spart.json:93: "Special": "The Hellenization civ bonus. Building a Theatron increases the territory effect of all buildings by 25%."

Now that YouTube stopped sending notifications for subscribed channels, it is important that we post new videos here so that we can get notifications from here instead. Here are a couple of videos that were released after YouTube's change, which some therefore might have missed:

I would not expect snapping towards a building when holding the preview near it. I would only expect it to snap away from the existing building (or terrain that can not be built upon) when the preview is placed over it. That is such an obvious thing to do so no modifier key or option should be needed. Keep it simple!

Found the patch, wiki page and a forum post with screenshot of 0 A.D. on POWER9.

Building placement is frustrating (for me and for people I have watched playing in online videos). The problem is, that as soon as the building preview (which follows the mouse cursor) is moved slightly over an obstacle, it turns red (which means that it is not allowed to place the building there). To fix this, the preview should snap to the closest position next to the obstacle. This should only happen when there is a slight overlap.

Simulation-side short-distance patrolling enables automation of dancing right now. But so would UI-side patrolling, which would not be too difficult to implement, but may require low network latency to work. Of course, automated dancing countermeasures could also be implemented UI-side. But a more appealing fix would be realistic unit movement (acceleration, kinetic energy) in the simulation. I recall someone mentioned testing this, but gave up because it made formations difficult.

I agree that the starting meat animals should be goats, sheep or pigs. That would be a quick and easy fix. Domestic poultry could be something that we just imagine exists at the houses and are below the game's scale of simulation. The chickens could be reused as wild animals in a suitable biome, like the peacocks. It makes more sense to use cavalry to collect wild birds because they are far away and spread out. The actual meat gathering should be equally fast for women and cavalry. The advantage for the cavalry should be the mobility.

It seems like everyone uses cavalry to slaughter the chickens at the civic center. It seems very unrealistic and I wonder if any ancient civilization actually did that? So right now realism in 0 A.D. totally ends at 0 seconds into each game. (Yes, there are plenty of other unrealistic things in the game, but this stands out.) It would seem natural to balance the game so that using the women to slaughter the chickens is the best thing to do. It should be a waste to use a cavalry man for that. He should use his greater speed and ability to kill to hunt larger and more dangerous or difficult-to-hunt animals further away and more spread out, and his strength as a man to handle large animal bodies. Women should be at least as fast as men at handling animals as small as chickens. And their slower walk speed should not be a problem at that distance. How could this be achieved? The idea that I came up with is a more numerically explicit division of labour. The idea behind the game seems to be that men do not really want to do light female work and hence do it slowly while women can not really do heavy work and hence do it slowly. Right now, work rates are set per unit type. I would like to classify tasks numerically instead. An example: picking berries/slaughtering chickens/gardening: 1 % heavy, 99 % light (I imagine the heavy work to be carrying the food baskets that the women have been filling.) So having only women doing such work would be a good choice for a player. collecting meat from larger animals: Numbers depend on animal size. Having cavalry hunting them, driving them towards the nearest dropsite, killing them and collecting the meat would be a good choice for a player. A few women could be sent to help gather the meat if the animal ends up dead close to a dropsite. (Women picking berries should automatically switch over to gathering meat from an animal that is killed nearby, to get the meat before it decays. Then they automatically go back to the berries.) cutting wood: 75 % heavy, 25 % light (I imagine the ligth work to be clearing smaller vegetation that is in the way before cutting the big trees, removing small branches and picking up small pieces.) mining: 90 % heavy, 10 % light (I imagine ligth work to be picking up and sorting smaller pieces as well as carrying water and other supplies to the men.) construction work: Numbers depend on construction material (building with more stone is heavier work than building with wood). Work speed for every unit gathering from a resource site should depend on how well the composition of units gathering from that resource site matches the above numbers. So 9 men and 1 woman on a mine should be better than 10 men while 6 men and 2 women on a tree would be better than 7 men and 1 woman. But since woodcutting is mostly heavy work, having only men on a tree would still be reasonably fast and be the best choice if the location is exposed to raids.

I find this interesting and imagine that it is what I remember from Settlers 3 (there are videos online for the young people). It worked with a lot of units on a Pentium II 400 MHz. Units would automatically step aside if another unit was coming too close (quite realistic). Hope to see this in 0 A.D.

I envision that the user gets as much automation as he wants. If he does nothing at all, his player will be computer controlled. So defaults should be sensible. But the user can turn off particular automation features at different levels and try to manage things better manually. (If the player has turned off for example automatic building placement, the automation could still make suggestions, like "now it seems to be a good idea to build a storehouse here, OK?". Of course the user should be able to turn off suggestions as well.) Whether the workers emerge automatically from a civic center, barracks or the resource camp itself is a detail that could differ between factions. It should be automatic in any case. (It would make sense for the resource camp to provide the necessary housing for the workers associated with it.) I watched all the 0ad videos by Tom on youtube and people seem to like playing the game with citizen solders (and I liked watching such games). The "call to arms" feature would work in the Rock–paper–scissors type of system that is Raiding-turtling-booming. To counter raiding, a player would turtle by setting his most exposed resource camps to request citizen soldiers. To counter turtling, a player would boom by setting his resource camps to request cheaper female citizens. To counter booming, a player would raid. The player also has to consider which mix of soldiers a resource cam should request, depending on which kind of rush might come. This system could provide interesting and challenging games. And as I wrote above, the defaults should be sensible. So the composition of workers requested by a resource camp should be automatically set according to how exposed it seems to be to raids. And of course the user should be able to override this.

An idea for slightly more realism: The player never tells a citizen which tree he should chop. The player associates each citizen with a dropsite. He will go there and deposit his armour and wepon. The dropsite sends its associated citizens to a resource site. The player can tell the dropsite in which proportion it should try to collect the different kinds of resources. Or this could be done on a higher (economy-wide) level and more or less automatic/smart. The dropsite would send its slowest-moving citizens to the closest resource sites and the faster-moving citizens further away. The player can mark resource sites (such as trees) for clearing (to get building space). Then the nearby dropsite(s) will prefer to send their citizens there. Otherwise it will send them to the nearest resource site. The player could also mark areas as forbidden for workers (because of danger). When one of the citizens of a dropsite sees an enemy, he shouts to his colleagues and they all go to the dropsite, leave their resources and get their armour and weapon. (So the dropsite would work like a swedish mobiliseringsförråd during the previous cold war.) Associating a citizen with a dropsite may not have to be done manually. A dropsite could automatically suck in an idle citizen. Although the player could set the number (and maybe type) of citizens that a particular dropsite should have.