wowgetoffyourcellphone

Indeed. Now needs defined what constitutes a "foundation." Give a bullet point list.

Indeed, my approach, believe it or not, despite allowing for massive battles would only actually have the player controlling maybe 20-30 actual combat entities. Entities being the operative word here, since each of these "entities" represents a battalion of 20-24 soldiers. Add in about 25-30 citizens and maybe 30 or 40 slaves and other support units, and you're only maintaining 100 actual entities in the game. Meanwhile, you actually get the feel for real ancient combat through the use of large armies in battalions, formations, charges, and all the rest. Absolutely! I've reduced unit speed and more importantly reduced vision range considerably in DE. This would carry into any gameplay proposal as well. I agree this is a huge huge problem for the game's current mosh pit combat, and probably one of the many reasons that AOE games have such similar looking units. With my proposed battalion system this particular problem is all but eliminated. You mention Warcraft 3, which is basically a hybrid RTS-RPG. A battalion system is essentially this. Each battalion is like a unit from WC3. You pick the class of battalion, which has different bonuses and penalties and abilities. You can upgrade each battalion to be different, much like its own character. Imagine a "battalion" of 5 elephants. This is akin to a character that you can improve with better armor, better weapons, towers, pikes/archers, even a squad of support soldiers [a real thing that happened; war elephants almost always had escort troops], officers ["zooiarkhoi"], noisemakers [bells around their necks, scares enemy cavalry]. You can do similar things with a battalion of Celtic warriors [naked-> clothed-> armored; karnyx; noble officer; etc.]. A battalion of Companion Cavalry. A battalion of Roman Hastati. A battalion of Greek Hoplites. A battalion of Persian Chariots. etc. Weapon-switching becomes easier with battalions. Stances [reduced to 3] and formation [reduced in number as well] control becomes easier. All those cool things about ancient combat becomes easier. Economics. You can still have multiple resources, but perhaps streamline how you assign gatherers to harvest those resources. Imagine this: Build a Storehouse next to some trees. Click one button once, and that storehouse trains 10 slaves who immediately start gathering the nearby trees once complete. Slaves* are your primary gatherers, while your Citizens are your builders and traders**.

Heh, yeah, feel ya there.

I think the general vision for the longest time had been: Age of Empires 2 + citizen soldiers + territories Boom done. But many see some gameplay problems with that as well as a huge missed opportunity to build something more interesting. Hence all the broken mods and bloodbath gameplay threads. In the end I think just voting on each feature individually as had been done in the past misses some of what Prodigal and Thorfinn are talking about, which is coherence. Imho best way would be to have a small number of self contained gameplay proposals that are widely regarded to be coherent and fresh. When you have these 3 or 4 self contained proposals then you can choose one and tweak from there. Experience has taught us that debating individual features ad nauseam is folly. Each feature has to fit within a whole for a complete and coherent experience. So choose an overarching theme or idea, like: "0 A.D. aims to give the player the satisfying experience building and maintaining an ancient empire, through resource harvesting, city building, and conquest through iconic ancient combat." Gather up a handful of gameplay proposals which more or less fulfill your thematic statement, and choose the one which you think most carries out the potential of the premise.

True. Then perhaps set the length to whatever is maxly* possible for 720p. *eh hem

Including a wider variety of units is why core game should look at DEs mercenary camp feature. In it, I provide Persia with Kardakes hoplites, Mercenary Greek hoplites, Kardakes skirmishers, and Scythian Horse Archers. I was thinking of closing one of their unit type gaps by possibly including Nubian Swordsmen too. The Anatolian Skirmisher citizen soldier in the game could cover the Lydian Skirmisher you mention, though I am sure that unit needs reskinned and propped for accuracy.

The gif is obviously posted in jest since I have previously admired your work and other posts. Perhaps you don't understand the sheer amount of blood spilt over this single issue over the many years. The only answer is modding so you can demonstrate your ideas, else you just start the 50th thread where good ideas go to die.

This helmet does not match the other helmets in look or texture. That's why I suggested that. This texture currently looks flat and dull.

2 and 3 seem to be the same issue just manifesting in different ways. I have found out what is happening. If the 'Upgraded' entity inherits from the original entity, then the Viewer only gets the information from the original entity--it doesn't see the upgrade entity as a new entity. If the 'Upgrade' entity parent is a new parent [template_structure_xxx] then the viewer updates the information accordingly. hmm. Can test this in DE by viewing the upgrade units for the Maiden Archer. The Maiden Fire Archer's parent is the Maiden Archer, and thus the viewer does not display the new information. The Maiden Swordsman's parent is a new base template [swordsman instead of archer], and thus the viewer displays the Maiden Swordsman correctly.

Just set the size of the dropdown to 1000. It resizes to the number of civs automatically according to my testing. I am not sure if this can be applied elsewhere too, perhaps the struct tree civ dropdown too, but I haven't tested. I had already fixed it locally, but seriously can't be arsed to push it to git.

No need to make some kind of separate building for the cannon fodder units as all the barracks and archery range units should already just be cannon fodder. The Immortals are already separated by making them only available from the Apadana.

Really? What's the plan?

It would be great to have a highly detailed and textured Blessed Mountain object for the game. Maybe about half this size. Looks incredible though. I can imagine a "siege" scenario where the Romans and Kushites fight over the city.

texture needs some mild roughness and some mild imperfection.

https://kotaku.com/company-of-heroes-was-the-perfect-rts-1791898789

Add some Desert Trading Posts that can be captured. See: Atlas.

Don't know where to start on fixing all the actors. Well, I started, but then realized the gargantuan task ahead and gave up. Unit actors all renamed to a new scheme. All infantry need fixed for carry anims. All new camel stuff. Soon, cavalry will need fixed for the new movement animations. They already all need fixed because variants were moved... Just too much. Motivation completely gone.

I'd say all of these are acceptable colors. Men from Caesar's legions especially would have access to these, though the Coolus would be the most prominent style and still some Montefortino helms here and there.

Ctrl-H has been and always shall be your friend.

The Agen-Port helmet could have an iron variant if you want to model one of those.

I imagine the alpha channelled feather texture will just anti-alias into a smudge in game at a playable zoom. I'm not saying it doesn't look cool tho.

This is unnecessary detail.

Good job on the entity viewer @s0600204! Here are a few things I've come across after its implementation: 1. Error when trying to view a paired tech: ERROR: JavaScript error: globalscripts/Templates.js line 539 TypeError: templateName.split is not a function removeFiltersFromTemplateName@globalscripts/Templates.js:539:9 init@gui/reference/viewer/viewer.js:66:21 showTemplateDetails@gui/session/selection_panels.js:1181:1 g_SelectionPanels.Research.setupButton/button.onPressRight@gui/session/selection_panels.js:804:5 ERROR: GUI page 'page_viewer.xml': Failed to call init() function There is no error when right-clicking erstwhile paired techs in the Struct Tree, only while in-game from the UI . 2. I think right-clicking an 'Upgrade' option, as for the Defense Tower upgrade for Sentry Towers [Stone Towers from Wooden Towers in DE], the viewer should load the information for the upgrade entity, not the source entity. You probably agree. 3. Bug: After 'Upgrading' a unit or building, right-clicking that new unit or building loads the original unit or building's information, not the new information for the Upgraded entity. So, for instance, if I upgrade a tower from Wooden to Stone, right-clicking the new Stone Tower's portrait gives me the viewer panel of the Wooden Tower, not the new Stone Tower and all the stats are for the Wooden Tower. Again though, it's great to see the viewer finally in the game. It'll help a lot of players. Plus, when all the History information is added back in people will enjoy reading about the items in the game. I would suggest a few extended features for the viewer, but I think items 1-3 above suffice for now.

A Nubian/Kush style series similar to Xena would work well. Imagine a Candace forced to abdicate her position by a corrupt priesthood or some other similar premise. So Candace wanders the earth on adventures.