Leaderboard

To me the main argument pro having infinite farms is that it removes micromanagement in the late game: when you have to manage up to 300 units it can make a big difference if you have to go back to your farmers to make sure that your farms haven't run fallow. It could of course be slightly lessened with a reseed queue like in AoK:TC, but you would still have to keep checking back to make sure it wasn't empty. Another way to do it would of course be to make the reseeding automatic, however that would remove the direct control from the user (minor issue true, but infinite farms doesn't have that issue). A question: do you actually want to influence the game or just argue a theoretical point? If the latter that's fine, but you have to forgive others for understanding it as being about the actual game and argue accordingly. If the former it would be beneficial to your cause if you would allow the discussion to be relevant to the game and not just include the arguments you personally deem relevant. I'll say what I've said before and most likely will say again: This is a game, not a simulation. Or in other words: We have to consider things both from a historical point of view and a gameplay point of view, and it's the latter which is predominant. And just to illustrate that it's not just my own personal opinion allow me to quote from the official vision document that has been guiding 0 A.D. for years: and more specifically: Now, I'm not a native English speaker, so allow me to deconstruct the above sentence. "The point laymans terms", I assume you mean "The point in layman's terms", which definitely is understandable, but seeing as you argue about language it merits being mentioned. "The point [...] is the way we interact in a strategic way against either AI or humans." So in other words, the point of your arguments is that we interact strategically with either AIs or humans and that it's important to you that this interaction is historically accurate?

Is this good ?

I took my sweet time putting the recording together, but I don't think I want to work on this anymore xP

I'm opening this up after reading some more discussion about farms and obstruction sizes. It seems like the consensus in the team is that farms should be bigger, so they're harder to defend. We also discussed making farms depend on terrain and have more profitable and less profitable terrain for farming (see this). I believe the fundamental issue with our farms is that they are large buildings with an obstruction. Making them larger means you will be able to build them in even fewer places, which is annoying. So what's the solution for organic-looking farmlands? Make farms smaller, and limit them to one worker. If our farms were, say, 2x2 tiles, we could plot many around and it would be able to look pretty good (particularly if the decals extend a bit), the fields would actually look occupied by workers (instead of just going around), and it would still take up a lot more size. Then we can add fancyness such as irrigation auras or stuffs like that if we want.

This may be useful for the game, but I rather create an off-topic thread so that Off-Topic can be a repository for scholarly research and studies. Below is an excerpt of the full article. It seems that Ptolemy IV's war elephants are inbred African Savannah Elephants. For the full article, see the source below: http://www.igb.illinois.edu/news/war-elephant-myths-debunked-dna

I open this topic. With Wikipedia article. Mining in Europe has a very long history. Examples include the silver mines of Laurium, which helped support the Greek city state of Athens. However, it is the Romans who developed large scale mining methods, especially the use of large volumes of water brought to the minehead by numerous aqueducts. The water was used for a variety of purposes, including removing overburden and rock debris, called hydraulic mining, as well as washing comminuted, or crushed, ores and driving simple machinery. The Romans used hydraulic mining methods on a large scale to prospect for the veins of ore, especially a now obsolete form of mining known as hushing. It involved building numerous aqueducts to supply water to the minehead where it was stored in large reservoirs and tanks. When a full tank was opened, the wave of water sluiced away the overburden to expose the bedrock underneath and any gold veins. The rock was then attacked by fire-setting to heat the rock, which would be quenched with a stream of water. The thermal shock cracked the rock, enabling it to be removed, aided by further streams of water from the overhead tanks. The Roman miners used similar methods to work cassiterite deposits in Cornwall and lead ore in the Pennines. The methods had been developed by the Romans in Spain in 25 AD to exploit large alluvial gold deposits, the largest site being at Las Medulas, where seven long aqueducts were built to tap local rivers and to sluice the deposits. Spain was one of the most important mining regions, but all regions of the Roman Empire were exploited. In Great Britain the natives had mined minerals for millennia,[6] but when the Romans came, the scale of the operations changed dramatically. The Romans needed what Britain possessed, especially gold, silver, tin, and lead. Roman techniques were not limited to surface mining. They followed the ore veins underground once opencast mining was no longer feasible. At Dolaucothi they stoped out the veins, and drove adits through barren rock to drain the stopes. The same adits were also used to ventilate the workings, especially important when fire-setting was used. At other parts of the site, they penetrated the water table and dewatered the mines using several kinds of machine, especially reverse overshot water-wheels. These were used extensively in the copper mines at Rio Tinto in Spain, where one sequence comprised 16 such wheels arranged in pairs, and lifting water about 80 feet (24 m). They were worked as treadmills with miners standing on the top slats. Many examples of such devices have been found in old Roman mines and some examples are now preserved in the British Museum and the National Museum of Wales.[7] The poin of this is give new whole form to extract metal and stone may be to the game, how you know Stanilas started to create eye candy buildings( and props)that give new proprieties or not to the gameplay. And if we had a building to garrison miners to work " under the ground" and give some bonus. That can be more faster minig or more amount of metal but more slower mining. But what the advantages of this? Less units in map moving around because they are garrison in this building. Can work like farms but with non visible units or may be an animation( a single one loop). Best management(micro) of this like your farming you focus in war more than extracting minerals and resources.(advanced phase) one per scenario to give some player fighting for great resource space.

And how would that help you improve? I think from what I can tell that you have a good set of skills already, so I suggest you see this as a chance to develop them further

One important point of the discussion was the fact that some people was saying that they don't like farms being worked near CC

Ah, ok. That makes sense. Thanks!

Also, eyecandy stuff is made to be placed in the scenario editor. So it's nice if there are many small eyecandy pieces, so the scenario designer can choose the placement of those things. Else you get too many repetition over the different maps. I don't know if you mean this as a single eyecandy object, but IMO, it would be better to split it up in a few.

Sorry, I don't understand this sentence. Can you reword it? I fail to see what is especially unrealistic about infinite farms. As other people have mentioned real farms do have a tendency to be infinite as long as you keep a bit of last years crop to replant. They definitely don't continuously consume wood. We have to sacrifice realism in a very large number of ways in order to make a playable RTS game. (glaring examples are gathering some berries in order to have a woman magically appear after 30 seconds). I was arguing in my previous post against your argument that infinite farms are unbalanced. The strategy you mentioned in the first post is not viable vs a skilled opponent. Infinite farms are not unbalanced, many other games have implemented infinite resources.

It looks more like a Age of Empires inspired drawing, very nice though.

Being closer to the upgrade means there's less work left to do and the risk of unacceptable problems showing up is reduced. Although staying on version 1.8.5 is probably not too bad at the moment, it will become a big show stopper if we later figure out there's no way around upgrading. I think it's quite likely that we will be forced to upgrade sooner or later. If we base fundamental design decisions on v1.8.5, the work required for upgrading will increase the longer we wait. If we upgrade now, there's still the chance that SpiderMonkey will change in a way that requires big architecture changes. That's bad, but keeping track of what's happening there and maybe having a chance to influence it is still much better than continuing using v1.8.5 without having any idea of what's changing in future versions. That could help us avoiding some pitfalls. Unfortunately it's not as easy as quickly reading some changelogs with each SpiderMonkey release. I'm quite sure we wouldn't know about the changed relation between compartments and global objects if I didn't work on the upgrade. I've tried raising the SpiderMonkey developers' awareness about library embedders. It won't stop them making big changes if they think it's necessary for Firefox, but I hope they will try to make it as easy as possible for us to prepare for it. I really see some change there. For example they have started to provide supported standalone SpiderMonkey versions on a regular schedule. Also they expect the API to become more stable soon. I'm not completely convinced about this but I still thought it's the most acceptable solution to stick with SpiderMonkey and try to keep our version as close to the development version as possible (by upgrading SVN to ESR releases and keeping a dev-branch and syncing it about once every week). I partially agree here. I don't believe in promises of theoretical performance improvements anymore. On the other hand I expect the GC performance to be much more universal and less dependent on the scripts than JIT compiler performance. I think we currently have enough bigger problems than GC performance to work on. On the other hand we won't be able to completely avoid GC hiccups in the main thread with v1.8.5. Wraitii has some good points too IMO. For me the main argument is really avoiding to be stuck with an old and "frozen" version without preparing our engine for future changes.

Awesome work LordGood. Composition and colors are very appealing. I wonder if they can be separated in two or three layers to make them scroll like the main menu now to give some 3D-depth impression.

You can unwrap parts of the model that aren't unwrapped yet without affecting the ones already unwrapped and still being connected. This is achieved by selecting all the vertices that you don't want to modify in the UV image editor, and hitting "P" to "pin" those vertices. Once pinned the parts that you don't want to be modified, just select all and unwrap as always, the pinned parts will be in the same place, and the parts that are not pinned will be nicely unwrapped and connected to the rest of the UVs. Puedes mapear partes del modelo que todavia no han sido "unwrappeadas" sin afectar las que ya estan mapeadas en la textura y hacerlo de modo que esten conectadas. Esto se consigue seleccionando todos los vertices que no quieres modificar en el UV editor y pulsando P, para clavar los vertices. Una vez que esten clavados los que no quieres que se modifiquen, selecciona todos y haz un unwrap como siempre. Las partes clavadas seguirán en el mismo sitio y las que no están clavadas se "unwrapearán" manteniendo la conexion con el resto de partes.

Nice animations! So far, the only ones that I think needs more work are the walking animation (has some harsh movements when placing the feet) and the attacking animation, which doesn't looks to me like it's attacking. Overall, nice work so far!

As regard to the fifth suggestion, I'd like a stance option available to archer formations (some civs only!, and pure archer formation?): "Pin them down" or "Area Interdiction" where a whole area is aimed with raining arrows. The archer would be as vulnerable as if ordered "Stand your ground" (I figure it takes time to abort this stance and start moving again as a formation).This stance would be available only to advanced?, elite and champion archer units. I figure that non eligible units in the formation wouldn't participate to the computing.The selection of this stance (or formation type?) would change the cursor into a target and the player would move this target in a roughly sectoral area defined by a min and max distance, and an angle counted from the direction the formation faces.The max distance would be lesser than the normal max distance. The area is not customizable, only placeable, although it would be a bit larger the larger the formation is. (The benefit from a large archer formation would be the "rain" density however.)Then, each archer would shoot N arrows consecutively (animations) and the total arrow number (known in advance by the engine) would be evenly affected a coordinate set in the sectoral zone. Or better, it would define an impact density, the same for the whole targeted area.After a mean delay (arrow flying to the target), each enemy (and allied) unit is checked against the impact density, possibly scoring more than one hit. Larger units have more chances to be hit (cavalry, siege). Special formations protect well against these volleys (and even tight formations should provide a slight protective bonus). The computing being a special case one, it would be possible to alter the piercing armor of all the units in the area (that would be normally used against aimed arrows) and then compensate it with a formation bonus. Other said, one can figure that a shielded unit not able to effectively use its shield against raining arrows (because engaged in mêlée, not trained, not in formation, etc.) would have a lower piercing armor for that computing only.After N individual shots or N volleys, the formation is dismissed or changes to "Stand your ground", and cannot use "Pin them down" again before a cool-down timer has expired. I don't know how to prevent a player from immediately re-ordering this attack. Maybe a temporary flag on each archer unit could prevent it to be grouped again or if grouped, to be counted in the impact density computing?

I'll give it a look. There's an issue currently, the AI gets stuck on farms, it's because of this morning's changes, I'll fix it tomorrow.

Possible civ emblems: Winged Bull and Star of Shamash https://upload.wikimedia.org/wikipedia/commons/2/2c/Human_headed_winged_bull_facing.jpg https://upload.wikimedia.org/wikipedia/commons/c/cd/Shamash-sun-symbol.svg Map of the Assyrian empire: https://upload.wikimedia.org/wikipedia/commons/c/c1/Map_of_Assyria.png Here I have a preliminary rough outline of the Assyrian civ profile.

Oh yeah, I'm considering building a mid-range desktop fairly soon

I think it's a bit too soft for a wolf attack. I think wolf attacks are very similar to dog attacks (or war dogs aren't animated either though). Normally, a dog-human attack starts with the dog jumping up on his hind legs, trying to grab an arm, and then trying to tear the human down (using his weight, and trying to get down on his front legs again). You can let the wolf move a bit, as long as he starts and ends on the same position, it will look good enough.