Alpha 16 Wishlist/General discussion

[Lion.Kanzen]

Nothing I haven't had the time to work on it, and for the past few months 0 A.D. won't even compile any more (thanks to OS X Mavericks being difficult, making progress impossible on my side). The patch you are referring to would help nomadic units that can transform from building to unit and back. As those are not yet to be found in the main game (nor any mod I'm aware of), this patch resides in the backlog for now. Previously it had been moved from Alpha 13, to 14, to 15, without too much progress. It can be picked up and worked on if the need arises. In short, I wouldn't put it back on the list for the next Alpha unless someone volunteers to work on this.

its nice feature, that why I was ask, it's very nice feature for gaming. We can ask sanders or Mimo, Itms. They can work in this one.

[Guillaume57]

If we felt particularly crazy, we could use square root tables to eliminate the computational load at the expense of memory.

I totaly agree. I've only done some coding a long time ago, but that was a basic that I've learn to reduce time calculation for such thing like tables of sinus, cosinus, etc...

And I do thing also it could drastically increase performance for such thing.

[niektb]

Nothing I haven't had the time to work on it, and for the past few months 0 A.D. won't even compile any more (thanks to OS X Mavericks being difficult, making progress impossible on my side). The patch you are referring to would help nomadic units that can transform from building to unit and back. As those are not yet to be found in the main game (nor any mod I'm aware of), this patch resides in the backlog for now. Previously it had been moved from Alpha 13, to 14, to 15, without too much progress. It can be picked up and worked on if the need arises. In short, I wouldn't put it back on the list for the next Alpha unless someone volunteers to work on this.

It would indeed fit in a mod. Our Millennium A.D. mod is going to implement nomads and it would perhaps fit in other civs as well.

[Lion.Kanzen]

Or this one.

http://trac.wildfiregames.com/ticket/21

------------------------

It would indeed fit in a mod. Our Millennium A.D. mod is going to implement nomads and it would perhaps fit in other civs as well.

And fit with various mods.

There is a list with features with patch , it's good to spy be to implement some.

This very good one.Trading Waypoints (2-parter)

http://trac.wildfiregames.com/ticket/2116

Gather version informations into the config files

http://trac.wildfiregames.com/ticket/1207

http://trac.wildfiregames.com/ticket/2118

Currently, there is a boolean splashscreenenable config option that allows the user to not see the "splash screen" at startup. That's fine if the content of the splash screen never changes, but if we want to post an update in a new release, it would be more flexible to have an integer value to compare instead of a boolean. (Even more flexible would be a way to stream news and content into the game e.g. notifying of a new release, and maybe we should think about that for the future)

Edited December 31, 2013 by Lion.Kanzen

[dvangennip]

This feels best at place here, as it is a response to the comment right below, although it might need its own thread.

This means that to optimize, beyond the pathfinder, we could mainly:

-find a brilliant new way to compute integer square roots.

I happened to come across this piece on Wikipedia on methods for computing square roots. I gave it a try in C++ and compared it with the function currently used in 0 A.D. (its own isqrt64 implementation) and std::sqrt. In my simple test code it turns out to be faster, much faster (sqrt_approx functions). And even the standard library sqrt function appears to be much faster, so it seems there might be room for improvement:

Testing different square root implementations.SPEEDstd::sqrt     = 0.28508isqrt64       = 1.26607sqrt_approx   = 0.085709sqrt_approx64 = 0.114492

It is an approximation, so the speed improvement comes at a cost of accuracy (see the spoiler below; although any error is stable and may matter less in a game situation compared to a true simulation). The error can be adjusted by manipulating an extra variable, and should generally be around 4% (the list below omits any correction as it gives worse results for small numbers). I haven't been able to try in the game code by adjusting source/maths/sqrt.cpp, but that should be easy to do. Even then, these faster functions may not be usable due to the need for stability across platforms/processors/etcetera. The currently used isqrt64() and this approximate function are both based on bit shifting so perhaps that is more stable across systems.

As I didn't test anything in game, I haven't made a ticket/patch for this. However, if the approach seems promising I'll do that.

ACCURACY

columns = std::sqrt | isqrt64 | sqrt_approx | sqrt_approx64

sqrt(0) = 0 | 0 | 0 | 0
sqrt(1) = 1 | 1 | 1 | 1
sqrt(2) = 1 | 1 | 1 | 1
sqrt(3) = 1 | 1 | 1 | 1
sqrt(4) = 2 | 2 | 2 | 2
sqrt(5) = 2 | 2 | 2 | 2
sqrt(6) = 2 | 2 | 2 | 2
sqrt(7) = 2 | 2 | 2 | 2
sqrt(8) = 2 | 2 | 3 | 3
sqrt(9) = 3 | 3 | 3 | 3
sqrt(10) = 3 | 3 | 3 | 3
sqrt(11) = 3 | 3 | 3 | 3
sqrt(12) = 3 | 3 | 3 | 3
sqrt(13) = 3 | 3 | 3 | 3
sqrt(14) = 3 | 3 | 3 | 3
sqrt(15) = 3 | 3 | 3 | 3
sqrt(16) = 4 | 4 | 4 | 4
sqrt(17) = 4 | 4 | 4 | 4
sqrt(18) = 4 | 4 | 4 | 4
sqrt(19) = 4 | 4 | 4 | 4
sqrt(20) = 4 | 4 | 4 | 4
sqrt(21) = 4 | 4 | 4 | 4
sqrt(22) = 4 | 4 | 4 | 4
sqrt(23) = 4 | 4 | 4 | 4
sqrt(24) = 4 | 4 | 5 | 5
sqrt(25) = 5 | 5 | 5 | 5
sqrt(26) = 5 | 5 | 5 | 5
sqrt(27) = 5 | 5 | 5 | 5
sqrt(28) = 5 | 5 | 5 | 5
sqrt(29) = 5 | 5 | 5 | 5
sqrt(30) = 5 | 5 | 5 | 5
sqrt(31) = 5 | 5 | 5 | 5
sqrt(32) = 5 | 5 | 6 | 6
sqrt(33) = 5 | 5 | 6 | 6
sqrt(34) = 5 | 5 | 6 | 6
sqrt(35) = 5 | 5 | 6 | 6
sqrt(36) = 6 | 6 | 6 | 6
sqrt(37) = 6 | 6 | 6 | 6
sqrt(38) = 6 | 6 | 6 | 6
sqrt(39) = 6 | 6 | 6 | 6
sqrt(40) = 6 | 6 | 6 | 6
sqrt(41) = 6 | 6 | 6 | 6
sqrt(42) = 6 | 6 | 6 | 6
sqrt(43) = 6 | 6 | 6 | 6
sqrt(44) = 6 | 6 | 6 | 6
sqrt(45) = 6 | 6 | 6 | 6
sqrt(46) = 6 | 6 | 6 | 6
sqrt(47) = 6 | 6 | 6 | 6
sqrt(48) = 6 | 6 | 7 | 7
sqrt(49) = 7 | 7 | 7 | 7
sqrt(50) = 7 | 7 | 7 | 7
sqrt(51) = 7 | 7 | 7 | 7
sqrt(52) = 7 | 7 | 7 | 7
sqrt(53) = 7 | 7 | 7 | 7
sqrt(54) = 7 | 7 | 7 | 7
sqrt(55) = 7 | 7 | 7 | 7
sqrt(56) = 7 | 7 | 7 | 7
sqrt(57) = 7 | 7 | 7 | 7
sqrt(58) = 7 | 7 | 7 | 7
sqrt(59) = 7 | 7 | 7 | 7
sqrt(60) = 7 | 7 | 7 | 7
sqrt(61) = 7 | 7 | 7 | 7
sqrt(62) = 7 | 7 | 7 | 7
sqrt(63) = 7 | 7 | 7 | 7
sqrt(64) = 8 | 8 | 8 | 8
sqrt(65) = 8 | 8 | 8 | 8
sqrt(66) = 8 | 8 | 8 | 8
sqrt(67) = 8 | 8 | 8 | 8
sqrt(68) = 8 | 8 | 8 | 8
sqrt(69) = 8 | 8 | 8 | 8
sqrt(70) = 8 | 8 | 8 | 8
sqrt(71) = 8 | 8 | 8 | 8
sqrt(72) = 8 | 8 | 8 | 8
sqrt(73) = 8 | 8 | 8 | 8
sqrt(74) = 8 | 8 | 8 | 8
sqrt(75) = 8 | 8 | 8 | 8
sqrt(76) = 8 | 8 | 8 | 8
sqrt(77) = 8 | 8 | 8 | 8
sqrt(78) = 8 | 8 | 8 | 8
sqrt(79) = 8 | 8 | 8 | 8
sqrt(80) = 8 | 8 | 9 | 9
sqrt(81) = 9 | 9 | 9 | 9
sqrt(82) = 9 | 9 | 9 | 9
sqrt(83) = 9 | 9 | 9 | 9
sqrt(84) = 9 | 9 | 9 | 9
sqrt(85) = 9 | 9 | 9 | 9
sqrt(86) = 9 | 9 | 9 | 9
sqrt(87) = 9 | 9 | 9 | 9
sqrt(88) = 9 | 9 | 9 | 9
sqrt(89) = 9 | 9 | 9 | 9
sqrt(90) = 9 | 9 | 9 | 9
sqrt(91) = 9 | 9 | 9 | 9
sqrt(92) = 9 | 9 | 9 | 9
sqrt(93) = 9 | 9 | 9 | 9
sqrt(94) = 9 | 9 | 9 | 9
sqrt(95) = 9 | 9 | 9 | 9
sqrt(96) = 9 | 9 | 10 | 10
sqrt(97) = 9 | 9 | 10 | 10
sqrt(98) = 9 | 9 | 10 | 10
sqrt(99) = 9 | 9 | 10 | 10

sqrt_test.cpp.gz

sqrt_test.cpp.zip

Edited January 1, 2014 by dvangennip

[wraitii]

I can't unarchive the file, it gives me something that looks still compressed.

I agree that using an approximation instead of an exact result would be sensible for the pathfinder, though.

[dvangennip]

I can't unarchive the file, it gives me something that looks still compressed.

I agree that using an approximation instead of an exact result would be sensible for the pathfinder, though.

Weird. I added a zip file now, hope that works.

Perhaps an approximate method can be added alongside the more precise one for when speed trumps accuracy. I'm not sure in which circumstances the square root function is used, priorities could differ in some cases.

Edited January 1, 2014 by dvangennip

[wraitii]

That worked.

I think your approximation isn't applicable to our case because we need the result to have no variations over any system, and using float doesn't achieve that. However this might be replicated using fixed, so if you can update, it'd be to consider.

[Romulus]

Definitely some archers with a reasonable range. Could probably increase the range for javelins too

I quite liked the composite bowmen in AOE

That's about the length of an English longbow in the Medieval era. Bows in ancient times were shorter.

And because this is 0 A.D taking art seriously....

And for those that love the Kataphractoi side of life

Few examples

Edited January 3, 2014 by Romulous

[Lion.Kanzen]

Mauryan archer need little bit of more range.

-----------------------------

How difficult it's implement the others victory condition, we have 2. It's possibly dhow score and then do a victory condition per score?

[LordGood]

well I just got the SVN

cavalry got terrifying

and Carthage got a huge buff with that mercenary tech (might be a little much)

I'm glad units can't just walk backwards and avoid damage. That enough on its own would make a pretty solid release imho

[scroogie]

I've also posted some profiles/traces on another thread if more info is required. Regarding the isqrt, if I remember correctly the new pathfinder patch drastically reduced the number of calls there. Afaik the current one still uses vector lengths which obviously requires a lot of sqrts.

[Romulus]

Second wish for the coming alphas because this one won't come soon is the ability to put soldiers on walls and on wall towers along with ballista/catapult units.

[Lion.Kanzen]

Second wish for the coming alphas because this one won't come soon is the ability to put soldiers on walls and on wall towers along with ballista/catapult units.

I asked this in another topic. check Features list.

check this one.

http://trac.wildfiregames.com/wiki/GameplayFeatureStatus

Edited January 3, 2014 by Lion.Kanzen

[newcivs]

well I just got the SVN

cavalry got terrifying

and Carthage got a huge buff with that mercenary tech (might be a little much)

I'm glad units can't just walk backwards and avoid damage. That enough on its own would make a pretty solid release imho

yeah!!

thanks!

and i love Carthage, many technologies for many units"14 types"

* Iberian Calvary

* Celtic Calvary

* Italiote Calvary

* Citizen Calvary

* Numidian Calvary

* Elephants

* Archer

* Javelinist

* Samnite Sowrsman

* Celtic Swordsman

* Slinger

* Spearman "holipite-style on 1º punic war, spearman on 2nd"

* Holipite "champion"

* Ballista

* Scorpio

* Birreme

* Trirreme

* Quinquereme

[dvangennip]

I've also posted some profiles/traces on another thread if more info is required. Regarding the isqrt, if I remember correctly the new pathfinder patch drastically reduced the number of calls there. Afaik the current one still uses vector lengths which obviously requires a lot of sqrts.

Thanks for the info. My proposed sqrt function doesn't actually work with 64 bit integers as input, so for now it's off the table.

Still, I found that for a 10k sample of input values (logged from actual gameplay) the std::sqrt function gave exactly the same results as isqrt64 (and is 4.5x faster). I had my test code calculate sum of squared errors and it gave 0 for the current isqrt64 implementation versus std::sqrt. If that outcome equality holds true for all other relevant platforms it may be better to use std::sqrt instead, assuming its implementation is faster on all relevant platforms.

I won't be able to test this myself (as I only have access to 64bit Intel Macs), but I attach my code and input samples file for anyone willing to do so. If the sum of squared errors for isqrt64 is higher than 0 anywhere (I set std::sqrt as the baseline), it can't be used due to potential out-of-sync issues. At the very least compiling for 64bit and 32bit gives the same results on my system.

Edit: perhaps this is better fitted in a trac ticket, so it's not lost. I'll do that later.

sqrt_test_with_samples.zip

Edited January 4, 2014 by dvangennip

[Radagast.]

First post. Followed 0 A.D. for some time now. ... and it's brilliant. Never seen a history simulation (how I call it) before - it's the first real history simulation attempt ever made. And it is genious, always using the 0ad.dev version for UNIX operating systems and it's really wow (unless you don't save as then the AIs stop working (both the no-longer-supported qBot as well as the Aegis - the Aegis is more vulnerable for saving issues and not even produces units any more but remember that I'm using a development version, so it's even more impressive that it works that well - and it does!!). Keep going, this is already really big and a worldchanger like open source is. (I'm into open source even though I'm working for open source hardware projects usually.)

So here my wishlist: (apart of the 0A.D. official part 1 feature list: http://trac.wildfiregames.com/wiki/GameplayFeatureStatus)

I don't like:

• Females being attacked ... this really is a no go - even historically the greatest barbarians (that in reality not really were barbarians anyway, only were called like this as everyone called the 'other' barbarian) did not attack females without reason, once capturing is ready please change that to capturing.
• Allies don't help you!
• Enemies don't get more friendly - no matter how much tribute you pay. One always has to change sides to change the diplomatic status.
• If the aggressiveness of units (military) is set to stand-ground all is fine. Unfortunately once the defensive (2nd most defensive option) status is chosen, foreign units are attacked even though those don't attack own units.
• Building complex wall systems is ... complex. (Yet it is brilliant!)
• Walls can't have units ontop. (see: http://trac.wildfiregames.com/ticket/797)
• Buildings shoot arrows even though they are ungarrisoned. (That is unrealistic and I doubt that this is necessary. If you want a building to be defended, garrison it - just like the real thing. : -)

What is outstanding next to a lot of other brilliant features of 0 A.D.:

• Historical accuracy.
• Units can repair allied buildings, heal allied units, even build in allied territory, can harvest food for the ally, can protect allied units, ...
• Catapults are just like the often wished Nomad features. It's possible to deploy and undeploy them, so that basic nomadic feature indeed already exists.
• Units automatically help on the next due task (building another building after finishing the own building task).
• Units are dressed realistically - and gain experience.
• Walls and Doors - even lockable. : -)

What I wish (and even plan to work on once I get around all the how it works and have finished studies and some of the opensourceecology and reprap and blender projects):

• Soldiers should shield females in case of a war. Also, heroes and leaders should be shielded by a special guard. Guarding is possible from Alpha 15 up, so new would be to have units 'absorb' arrows and other attacks.
• Growing trees? (Animation? low priority)
• Trees should seed themselves.
• Animals should get children, the population dynamic can be as easy as a Fibonacci row for the beginning - or we look for a proper scientific paper. Also, hunting animals (carnivores) should decimate populations they eat and vegetarian animals should decimate the ever-growing plants.
• Buildings and complete countrysides should fall under growth of all sort of plants and trees - resulting in a decay just like the outposts do.
• Weather and seasons interchanging.
• Day and night alternating. In the night some torches and lanterns lighting up.
• Physics engine for making possible to craft own technological innovations instead of the fixed technological improvements (probably combine it, e.g. research metal crafting first before being able to construct arbitrary leader-defined machines of which most will proof physically useless -- until the right innovation/invention was made). This way, civilizations could evolve by assembling new siege structures, improve walls for defences, et cetera - of course such innovations should not have to much influence - and should affect all civilizations within reach (even enemies) too, that means if one civilization invents a new siege structure that works, that should become available to all cultures just like it is in reality. For example the nuclear bomb was among others made possible by Wernher von Heisenberg, and still all the high powers (many countries) with the adequate means worked on it (perhaps make the technological innovation researchable once a physical accurate system, e.g. a cannon was invented and tested by one civilization). Otherwise if breakthroughs like new clothing is not available as researchable option to other peoples, it is impossible to balance the simulation - imagine a tank crushing the spartans, that's just too unrealistic. Breakthroughs have range and reach the farther the more advanced the civilizations become.

Cavalry run walk toggle Why manually? To automate this decision is important. What effect in combat does it have?
Capture building/ female animals/
Improve formations
A lot of new tech , specially in early phase, nobody likes play in early stage.
Nomad mode? (Catapults already have functionality like this!?)
Farming new gameplay. (more precisely?)
Implement new shortcuts (not important, can be setup with local.cfg - or probably not provided by the API?)
New cheats I prefer historical accuracy and an automatic ecosystem instead.
New auras Isn't it better to have this done more generically? So perhaps attach Aura to all Champion units and heroes and make the strength of the Aura depending of the stats and health of the hero/champion. High military stats, high Aura influence. Low health, higher aura influence in surrounding units (the royal guards trying to save their leaders) and a lower range/reach of Aura instead. Perhaps even introduce a citizen moral depending on how often they are raided, how often own buildings are crushed, food level and the season and the summer harvest amount.

What I can foresee for the distant future is having commanders assigned to armies/units and giving those commanders independant control in warfare. This means, they can decide formations and regroup their personnel according to the tactics of the opposing force. This will propably be even harder to implement than the proposed ecosystem for mushrooms, animals and plants.

Edited January 4, 2014 by Hephaestion

[LordGood]

You can imagine with so many factions, the art department has a lot of ... inertia

[Enrique]

Hello Hephaestion! welcome to the forums and thanks for your feedback.

To address some of your points:

- You will be able to capture women (IIRC the only possible unit to capture along with buildings) But capturing is not yet implemented

- AI enemies/allies is being improve over time and will have more diplomacy options/decisions in the future

- "Auto guard" could be a possibility, but is up to discussion if that should be managed with micro-management or not. Regarding soldiers guarding women, there's a "alarm" bell in the dev. version that makes women automatically garrison in the nearest building. (haven't tested it myself though)

- IIRC, growing trees is no longer planned. Only food will be an infinite resource to gather in the map. We want to make trading more important (as it was in those times too) in the late game, which will provide you the resource you need as long as you have traders traveling between markets/docks. There is some development on upgrading how trading works that will make things easier to choose which resource to gain through trading. Also keep in mind how many years take a tree to grow up, and in 0AD we don't have "ages" but rather city phases which don't take so long to develop.

- Animal herding functionality still being discussed how it will work. But we plan making corrals useful and reflect that and probably add animal reproduction and extinction in the map areas (not decided yet I think)

- Weather/season changes and daynight cycle plus torch/fire spotlights seems to be out of scope. We had a skillful developer who was working on add deferred lighting to 0AD (groundwork for this features to happen) but sadly he disappeared

- Your tech system sounds cool to me and something that could even suit the game, but I think the tech system is already tightly implemented and would be hard to change such a big gameplay feature in the current state of the game.

- Cavalry and infantry run/walk means run/charging. Units will have stamina and will be able to run/charge to the enemy with double right-click. Cavalry, chariots and elephants will have a big bonus damage impact when charging (apart of the speed bonus of course)

- Nomad mode I think is not working on buildings yet, and I don't think is planned. That suggestion seems to fall under the "mods" section

- Your commanders suggestion seems way too difficult and sounds something that micro-management should take care of.

Maybe I'm not right in all my points but I think is an approximation of how things are at the moment (of course not all of them will be on A16 )

[Radagast.]

Thank you Primus Pilus, I value your words. I now have a better grip on the state of the simulation.

- Then after the introduction of capturing we can change the default behaviour of own unit when foreign females penetrate own territory to capturing instead of killing (what seems really rude to me and I am quite busy in stopping my units by standground to keep save the foreign females of this ignoble death.

- What would be great is to make the other civilizations diplomatic attitude more friendly towards one another if you help the enemy constructing his buildings (what works, my units have successfully built a civic center for an enemy [Thebes / i.e. currently hellenistic fraction]. Also tribute should lift the moral of the enemy civilization and should make them more friendly towards the tribute paying civilization.

- "Auto guard" could be a possibility, but is up to discussion if that should be managed with micro-management or not. Regarding soldiers guarding women, there's a "alarm" bell in the dev. version that makes women automatically garrison in the nearest building. (haven't tested it myself though)

- I realised this feature some time ago and it works brilliantly - it's the way I save my females usually unless the situation is hopeless and more resources are required for recruiting more soldiers. In this case an option to surrender to stop the slaughter would also be quite nice. Imagine, you could be the vasall of the enemy for some time ...

Instead of Auto guard we could use Aura - just like with the Heroes:

My humble self wrote: So perhaps attach Aura to all Champion units and heroes and make the strength of the Aura depending of the stats and health of the hero/champion. High military stats, high Aura influence. Low health => higher aura influence in surrounding units (the royal guards trying to save their leaders or (new) the soldiers in the surrounding of the females being alarmed and changing its mode from e.g. standground to offensive ) and a lower range/reach of Aura instead. Perhaps even introduce a citizen moral depending on how often they are raided, how often own buildings are crushed, food level and the season and the summer harvest amount.

Alternatively why not use the aura of the women they have for making the male citizens work more intense. I read that this is already implemented. So if a female citizen in the surrounding of civilian soldiers looses health by an attack this would lead to alerting the males instead of increasing their productivity. The problem here will be to track the loss of health. It's not enough to simply analyse the state of the health. So when a woman looses health thereafter a check for soldiers in the surrounding has to be made: Store last activity, make them attack the source of attack that was responsible for the woman loosing helath shortly previously.

- Weather/season changes and daynight cycle plus torch/fire spotlights seems to be out of scope. We had a skillful developer who was working on add deferred lighting to 0AD (groundwork for this features to happen) but sadly he disappeared

Oh no, this is so sad. This is such an important feature - imagine the flair it had if you knew that it's going to get dark soon .. toches lighting up and your non-busy units litting a campfire for surrounding units ...
then suddenly the weather turns rainy and your units clear the fields and your intelligence tells you, a big army camps outside your walls and an attack is eminent. What will you do, will the weather change just in time to make your skirmish troops more effective again. (I believe rain and mud gives ranged units an advantage.) .. okay, I'm getting off focus now.

- Cavalry and infantry run/walk means run/charging. Units will have stamina and will be able to run/charge to the enemy with double right-click. Cavalry, chariots and elephants will have a big bonus damage impact when charging (apart of the speed bonus of course)

I get the point, double click is a good solution. I also can imagine implementing a commander giving this order independantly. Say, is it possible that from one unit other units can be influenced? As there are formations already working quite well I think this commander-like influence on charging/non-charging can be issued analogously. (I.e. if the own units have completed the formation and (perhaps better or?) the commanding unit realizes the enemy is near enough for the soldiers' available stamina a command for charging is issued automatically. It could even be implemented using the Aura influence of a hero, something like a second aura. That is, the second Aura increases as the confidence for attack raises -- once this Aura value is high enough, it does no longer only increase the morale of surrounding units but also changes their advance mode to 'charging mode'.)

- Nomad mode I think is not working on buildings yet, and I don't think is planned. That suggestion seems to fall under the "mods" section

I read in the Feature Status overview that this seems to be planned and I think that an easy solution would be making all buildings full-fledged units (the same category as the catapults are). Catapults can be packed and unpacked already - and the nomad feature requires exactly that.

Your notes to the timescale also make sense, of course a tree could not grow that quickly. Trade is important and I already like how this is solved. qBot and Aegis build markets too, so that works really good.

[wraitii]

Actually, running/charging wil probably not be done with stamina, but it's not completely decided yet.

[Radagast.]

Oh my god, an AI half-god reads this thread. I have to figure out how to add to the AI development.

Do we have an alternative for using the stamina? Will stamina decline with working hours too? Would fit to the night day cycle. So units would rest at night unless the alarm bell has been rung.

The at the beginning of this thread mentioned 'update notification' must not be streamed, or? It's enough to check for a newer Version on 0 A.D. startup, no? For me personally as I use development builds anyway this notification looks not important. The package manager automatically detects updates of 0ad.dev . And a check for a newer version now and then is no problem.

Ah, I forgot two things:

• Is the simulation speed of 0.5 x normal enough? After reaching some complexity of the civilizations .25 (1/4 of normal speed) would be better. As a nice side effect the lower the speed the more fluently the simulation.
• The other idea is to create a moat - either as building ... or preferably to have 'diggers' (units) that can carve out arbitrary amounts of ground earth or mountains. To have the earth as heap next to the moat would be cool too - perhaps even make the earth transportable for blocking enemy roads. Okay, I'm starting to dream now. That's not doable for now for sure.
• Just for me to remember this idea and implementation if I have too much time: Make walls climbable, that is create generic animation that works for all units and make reaching the top of the walls possible this way. Then the walls only can be left to the inner of the country the walls defend once all units on the walls are defeated. Then the units climb down the towers. The defending units can lock the walltower doors so that enemy units have to jump loosing half of their health in the process.
• Also make setting buildings on fire possible.

This night I also came up with another idea:

• Javelins and arrows should be limited. Each arrow could cost one piece of wood, each javelin two pieces of wood and one metal. For the future there could be support units that transport javelins, arrows and water automatically to frontier units.
• Is adding water as resource a bad idea? Water could then be used to put off fires or to mix hot oil to defend walls and towers. Water also could restore some stamina, so support units will automatically bring water to the frontlines just like the javelins and arrows.
• Or is making spears break after heavy use at the frontline a bad idea? In reality there was heavy piercing until all spears were broken, when a secondary weapon came to use and the two frontlines started rather pushing until a breakthrough occurred. (Hence most units died once panic made the way or in a rout or while fleeing the enemy, just like it still is nowadays to a certain degree.)

The camera restriction also is too high an angle I think - it gives a much greater impression if setting the camera restriction endpoint lower, so that it feels more like you are in the middle of the happening. Currently in the incredible developer overlay restriction has to be deactivated. Especially in combination with the focus on units this gives a great impression!

0 A.D. has so much potential! And it is already incredible. With all that factions, even Thebans being planned, I really believe you, that there is a lot of inertia - so changes/additions should be careful with being as generic as possible and should neither render produced artwork useless nor must it create escalating maintenance and adaption work. This is why dynamic solutions look so more appealing to me than static ones. But whom am I telling that. Excuse my enthusiasm.

Edited January 5, 2014 by Hephaestion

[Stan`]

Oh my god, an AI half-god reads this thread. I have to figure out how to add to the AI development.

Do we have an alternative for using the stamina? Will stamina decline with working hours too? Would fit to the night day cycle. So units would rest at night unless the alarm bell has been rung.

The at the beginning of this thread mentioned 'update notification' must not be streamed, or? It's enough to check for a newer Version on 0 A.D. startup, no? For me personally as I use development builds anyway this notification looks not important. The package manager automatically detects updates of 0ad.dev . And a check for a newer version now and then is no problem.

Ah, I forgot two things:

• Is the simulation speed of 0.5 x normal enough? After reaching some complexity of the civilizations .25 (1/4 of normal speed) would be better. As a nice side effect the lower the speed the more fluently the simulation.
• The other idea is to create a moat - either as building ... or preferably to have 'diggers' (units) that can carve out arbitrary amounts of ground earth or mountains. To have the earth as heap next to the moat would be cool too - perhaps even make the earth transportable for blocking enemy roads. Okay, I'm starting to dream now. That's not doable for now for sure.
• Just for me to remember this idea and implementation if I have too much time: Make walls climbable, that is create generic animation that works for all units and make reaching the top of the walls possible this way. Then the walls only can be left to the inner of the country the walls defend once all units on the walls are defeated. Then the units climb down the towers. The defending units can lock the walltower doors so that enemy units have to jump loosing half of their health in the process.
• Also make setting buildings on fire possible.

This night I also came up with another idea:

• Javelins and arrows should be limited. Each arrow could cost one piece of wood, each javelin two pieces of wood and one metal. For the future there could be support units that transport javelins, arrows and water automatically to frontier units.
• Is adding water as resource a bad idea? Water could then be used to put off fires or to mix hot oil to defend walls and towers. Water also could restore some stamina, so support units will automatically bring water to the frontlines just like the javelins and arrows.
• Or is making spears break after heavy use at the frontline a bad idea? In reality there was heavy piercing until all spears were broken, when a secondary weapon came to use and the two frontlines started rather pushing until a breakthrough occurred. (Hence most units died once panic made the way or in a rout or while fleeing the enemy, just like it still is nowadays to a certain degree.)

The camera restriction also is too high an angle I think - it gives a much greater impression if setting the camera restriction endpoint lower, so that it feels more like you are in the middle of the happening. Currently in the incredible developer overlay restriction has to be deactivated. Especially in combination with the focus on units this gives a great impression!

0 A.D. has so much potential! And it is already incredible. With all that factions, even Thebans being planned, I really believe you, that there is a lot of inertia - so changes/additions should be careful with being as generic as possible and should neither render produced artwork useless nor must it create escalating maintenance and adaption work. This is why dynamic solutions looks so more appealing to me than static ones. But whom am I telling that. Excuse my enthusiasm.

I'm not sure a piece of wood per arrow is a good idea. Because if you think about it its wood logs going out of trees so an archer myself i can tell you can make a lot of arrows from a log. So maybe 10 per log or something like that.

I read somewhere that it was planned to make carry. Can we do something like the settlers V ? Where units can interract with the building. So for example they can climb a ladder or dig in the wall etc ? Also about the mine maybe the good idea would to make units able to garrison in it fill their inventory and get back with the appropriate ressource.

I have another question, why isn't any kind of money in the game ? It could be like the settlers (yes i love that game) each turn, 2minutes for instance, each unit pays a tax.

[Radagast.]

In foreign times I think the people did not pay in terms of money but rather in terms of goods. Of course, at the market, the people pay with money/gold coins or other seldom materials or exchange goods. As the citizens don't harvest money, but food and other resources, they cannot pay duties to the protecting elite or government in terms of money. So I think taxes in form of money are out. And currently units don't have consumption, so all gathered resources are payed to the leading units corresponding to a tax of 100 percent.

I prefer the introduction of surrender and being a vasall for a certain amount of time. In this period almost all goods will go to the conquering units and the state will change to neutral or ally or 'forced ally' until your country is freed from the occupying units either by your allies or by a rebellion started once you 'think' you have enough soldiers or regained a good enough strategic position (or both). Or you choose to stay on the other side because it's hopeless (what will fury your former allies).

Once units have the need to buy other things, a money system will make sense. Good you introduced it into the discussion, it made me think about the role of money in Ancient worlds and I hope someone knows more about that than my humble self.

I read somewhere that it was planned to make carry. Can we do something like the settlers V ? Where units can interract with the building. So for example they can climb a ladder or dig in the wall etc ?

This is an animation I would need for storming defending walls anyway. The question is, how generic can the solution be. If the animation has to be recreated for each faction that is not favourable. Usually animations/rigs can be fit onto several objects/meshes. But no idea how it is here in 0 A.D..

Carrying goods is already available and the main work will be the graphics work I think to make more goods carriable. Or did you mean by 'to make carry' something different?

Also about the mine maybe the good idea would to make units able to garrison in it fill their inventory and get back with the appropriate ressource.

This looks like a cosmetic/graphics change: Exchange the heap of metal with a mine and make people garrison into it or at least disappear shortly and come back again with goods.

I'm not sure a piece of wood per arrow is a good idea. Because if you think about it its wood logs going out of trees so an archer myself i can tell you can make a lot of arrows from a log. So maybe 10 per log or something like that.

Good point.

Edited January 5, 2014 by Hephaestion

[LordGood]

I think some of this stuff belongs on the suggestion thread. This is the alpha 16 wishlist, which would mean shorter term goals that are actually reachable with the limited manpower (and possibly funds) we have right now.

a lot of these suggestions would require a lot of work, testing, and re-balancing

even something as simple as a 'mine' building could consume the entire art department's output for months, and that's depending on availability