gudo

Renewable resources has been discussed before here, but I want to bring it up again and in more depth. Even discussion on whether or not it's a good thing to include is welcome.Specifically, I want to discuss ways it could actually be implemented. I have an idea of my own that I've drafted up, but would love some comments on it. Abstract: This is a rough writeup of my proposal to create a more dynamic natural world. In short, we create an AI for gaia. The AI will spawn units and trees in as realistic manner as possible, and control the movements of animals to simulate their natural behavior. The goals of this project are twofold: *Renewable Resources - Gaia will spawn animals and trees in a reasonable manner. Logged forests should eventually regrow, and animal populations should eventually recover from hunting (assuming there's any left). *Realistic Animal Behavior - Lions should hunt deer and travel in packs. This post will focus on first part. Step 1: GUI Support for a Gaia AI Gaia is already allocated a player id, so we can just create an AI that does everything we want Gaia to do, and assign it to control Gaia. At a minimum, we could just assign it to be the default AI and leave it at that. (see /mods/public/simulation/data/player_defaults.json) Preferably, there'd be a way to assign/unassign an AI to Gaia in game. I'm thinking a check-box "Active Gaia" by "Reveal Map" and "Teams Locked" in the game creating screen. Checking the box would assign GaiaBot (or whatever the AI is called) to Gaia, and unchecking it would unassign Gaiabot. Default behavior would be unchecked, or "off." As an additional consideration, GaiaBot would somehow have to be concealed from the players, lest the accidentally assign it to play a real civ. We would then write the bot to do whatever actions we wanted Gaia to do. Step 2: Establishing Population Limits for Fauna We can't spawn fauna simply as a fraction of the existing fauna. While it would lead to exponential growth (which we expect to see in real populations) we run into the problem of maximum population. Growth that's proportional to existing population simply never quits growing. Having 2000 deer on your map would certainly cause performance problems. Additionally, in the real world, there's a finite amount of resources available for population growth. Our GaiaBot will need to establish population limits and use equations to control growth in such away as to not violate those limits. Further down in the thread, I will post a brief overview of mathematical population modeling and link it here for those interested. Step 2.1: Population Limits for Fauna 2.1.1 Possible Exceptions GaiaBot will not compute population limits for Fauna with the parent template "template_unit_fauna_herd_domestic" Population Limits for predators would initially depend on the number of prey. Later, once the bot is more sophisticated and can have predators actually hunt, the population limit will be based off the kills they make. 2.1.2 Calculating It is up the map creator/RMS to decide what constitutes a reasonable number of animals for a given map. As such, at the start of each map, as it's first action, GaiaBot will simply count each animals of a given type. That value is then stored as a variable limiting the population of each animal of that type, i.e. var deerpopcap = (relevant code); //The population cap for deer. Step 2.2: Establishing Population Limits for Flora 2.2.1 Possible Exceptions GaiaBot will not compute population limits for Flora that provide food (berry bushes, apple trees) 2.2.2 Calculating Once again, we leave establishing a reasonable limit to trees to the map creator/RMS. However, GaiaBot doesn't care about the type of tree. We simply tally the total number of trees and store it. Step 3: Establishing Growth Rates For a somewhat in-depth analysis on why these formulas were chosen, see my later post on modeling populations. For both flora and fauna, the growth rate is: Rate of growth = k(Pop)(1-Pop/Cap) Where Pop is the current population of a species and Cap is the population cap for that species (i.e. deerpopcap) k is an arbitrary constant that is used to fine tune the rate. If we want something to spawn faster, give it a large k. (note also that a sufficiently large k could shoot a population over it's population limit. This would cause a die-off.) We can add terms to this equation if we like, to simulate say, a threshold for survival (if the population ever falls below said threshold, we slowly go extinct.) After inputting the proper values for each species, we add the result to another variable (continuing with deer as an example, we'll call it deergrowth) which will then be used to determine how many we spawn. "deergrowth" holds the fractional remainders of previous operations, so we don't loose, say half a deer. Say for example, we've been running GaiaBot for awhile and deergrowth is == .53. After running a rate of growth calculation for deer, we get a result of 4.32. This is then added to deergrowth for a total of 4.85. Step 4: Spawning Entities Step 4.1: Spawning Fauna Let's do an example: Our deergrowth variable is at 4.85. GaiaBot will then choose 4 random deer and order each of them to train one more deer. 4 is then subtracted from deergrowth. Placement of the new deer will obey the spawning code set up for <TrainingQue> (that is to say, it will be adjacent to the animal and will respect passability class.) We'll have to add the <TrainingQue> tag to each class of fauna, with the ability to train itself (I've done a quick and dirty hack with deer, it works.) Step 4.2: Spawning Flora Regarding the number of flora to spawn, it's easy. If, say treegrowth == 2.34, then we spawn 2 trees. As far as the placement is concerned... I'm not so sure that <TrainingQue> is the best way to do it. Eventually, we'd wind up with dense, impassible forests. For some maps, this might be just fine. For others, not so much. Perhaps we could do it by tree type? Evergreens, say would use <TrainingQue> resulting in thick, dense pine forests. Palms would use some other method. Step 5: Additional Features Currently, players can't order fauna to move (meaning Gaia can't order Fauna to move.) There needs to be a way for Gaia to do this. According feneur, players will need to be able to order animals around, so it's a needed feature anyways. Comments on Sections 1: Philip tuned me on to other ways of spawning units in game (scripted system component to be exact) but as the eventual goal of my proposal also requires moving animals, I think AI would be the best way to do it. Also, this seems to be the way requiring fewest changes to existing code. In fact, only the game setup screen should need changing (oh yeah, and all the gaia templates. Still possibly simpler than adding a new component.) Disabling renewable resources would also be a synch. 2An alternative method for generating population limits would be to have them specified by the map designer or RMS and stored in the map file itself. This would make the bot simpler, and allow the map maker slightly more control. 2.2This assumes we regenerate flora. Maybe growing trees back is too game breaking? That's the whole point of the thread! Also applies to 4.2

War with the Romans was the poor idea, the internal fighting just made their bad position worse. When you consider not just the size of force, but also the training and ability each belligerent was able to bring to the fray; it's no wonder each of the wars proved disastrous for the Hebrews. Fanaticism improves neither your logistics, nor strategy. Sure, a small portion of your ability to fight is your will, but when all sides are willing, it's the tangible that matters. Do you have more troops than your opponent? (No.) Do you have better weapons than your opponent? (No.) Do you have better technology? (No.) Better freedom of movement? Better leadership? When you consider it like this, the question "Do the Hebrews have a chance?" becomes "How badly will they loose?"

Once the game goes gold, somebody will probably do it. Could be pretty good too, there's always something about playing the underdog Jaimele - I wouldn't hold your breath for it Hebrews to be included as a civ in the vanilla game. Maybe a few Atlas only units and buildings, but probably not a whole, multiplayer playable civ. The main problem with including them is probably the size of their holdings. Consider the size of the Roman Empire or the size of the Achaemenid Empire. To be sure, the Hebrews had (and still make) a huge and lasting impact on global affairs. But at the time, they were just another ethnic group.

Oh ninja'd. I was getting a screencap of this. But yeah, try a constant orientation. I believe the angle that Mythos recommends and Jubot uses is 3/4*pi (.75pi).

Herd/Domestic animals shouldn't run. Wild/hunted animals should. Remember how sheep were slaughtered in one hit in AOE 2? 0AD should try and be like that. Prehaps create a slaughter animation (shared across all units, different than their attack animation) to reflect that. IMO, hunting never had that big of an impact on any RTS game I've played, not even the AOE series (unless, of course, the scenario railroaded me into it.) And honestly, isn't agriculture not just a hallmark, but a pre-requisite for civilization?

The choking problem is much better than it was, yeah. Still, it's slower than it could be. Now I'd say the economy needs work in the mill placement dept and which specific resources to gather. The mill placement code is really strange. I noticed that after a while, Jubot just spams mills everywhere. I think this is because of the way the building list works. Once it's built all the barracks and towers on the list, it has nothing to build but mills. Also, it could stand to place a few more earlier in the game. As for the other point, the chief problem is that workers are told to gather whatever is closest to them when they should be tasked to gather what's closest to the drop point. Not really sure how you'd go about fixing those, but as far as the economy side of the AI is concerned, that's what I'd try to take care of next.

That's odd, I've never seen Jubot do that. But then again, farms are kind of weird that way. Have you tried using Splitbot though? There's clearly something going on with it that's not happening with the other bots.

Splitbot, for some reason or another, places foundations in locations where they can't actually be constructed (i.e. trying to build a house that is half inside a stone mine.) I think SplitBot may not actually consult the collision map when deciding where to place structures.

So I think I've figured out why Jubot was so slow that one time. 1) It's getting choked on wood. After a good long while, it had 600 food, 80 wood, 4000 stone and 6000 metal. Metal and stone should be put at a slightly lower priority. Now that I'm thinking about, it would probably be best if there was a way to give different resourcing priorities depending on your civ. Since Iberians are metal heavy, and the Hele want lots and lots of wood and stone. Maybe also a check that would pull workers off of a given resource when stocks get too high... 2) Jubot LLLOOOVVVES berries. Instead of building farms after the berries and chickens next to the civ center were gone, it sent gatherers about 30 seconds one way to an apple tree. Though this was probably because it didn't have the wood for farms. Still, even when it did, Jubot wasn't building enough farms. I'm not sure whether a better solution would be to teach the bot to build farmsteads, or make farms slightly more important. Actually, if you could teach calvary to be hunters, that would be pretty great. 3) Did you remove the (I think it was 4 minute) timer on the military agent that prevents it from launching attacks "too often"? If it's still there, it should be shortened for sure. Jubot still seems pretty relaxed. Especially now that there's retreating so each attack doesn't mean all the units can be considered lost the moment they go marching off. Anyways, I like the military behavior, especially the retreating. Is that new? Cause I've never noticed it before.

Nice changes to Jubot there Jubal I just ran some tests with qBot and Jubot. Jubot certainly has an early advantage, but I couldn't seem to induce it to attack... I haven't looked very hard at the code though so I'm quite sure what Jubot looks for before starting to attack. As far as qBot goes though, it got stuck. It tried to train lots and lots of Greek Calvary, but ran out of metal after just 10 units. qBot doesn't currently assign workers to mine for metal and it doesn't change it's plans when it runs out of resources. So it just sat around, not making anything till Jubot finally killed it.

Welcome Steggy! Berkeley you say? You haven't by chance heard of the Berkeley Overmind have you? Or the Undermind for that matter... Anyways, there's a list of all current AI player projects in my signature. Jubot is the default player, distributed with 0 AD. Both it and qBot are based off the same "TestBot" architecture. SplitBot and RootBot both have different and unique architectures. You can read more about them all in their respective threads. Instead of working on a specific bot, or making one from scratch, you might want to solve some general problems. For instance, there's no way (as far as I know) for the AI to learn it's under attack. Fixing that might be fairly involved. Also, nobody's implemented any sort of defensive behavior yet.

Yeah, it really is pretty dumb, I wouldn't waste time on it either. Well, the basic idea is to spawn citizen soliders with the "worker" role. The AI should then treat them just like women. However, we'll give them a new metadata class "canattack" and start if off with "yes". The military manager will be looking for units with "canattack" == "yes" and once it finds enough, will sort them into a squad, change the role from worker to solider, clear out the subrole, and set canattack to "isattacking". Later, when the military manager is done with them, we can have it reset the units role to worker, and change canattack back to "yes". For the short term though, there should be a way for the economy manager to find idle workers and change their role to worker. This way, citizen soldiers spawn as workers, and can be re-tasked by the military manager. When they go idle, we re-task them again as workers. Once re-assignement issues get fixed, we can remove the code that makes them workers. There's still a bit of work to do to see if it's even do-able, but I can't see why it wouldn't work.

Nice looking bot you got there. I did some testing and it plays well. I would slightly lower the priority on food and slightly raise it for wood though. On the tests that I did with it, qBot stocked tons of food but was consistently bottle-necked by wood shortages. As far as non-trivial changes go though, I found that placing a mill and farmstead (on the line between your civ center and your opponent's, roughly 40-45 tiles away from your own) gave the AI quite the boost, more-so than using your citizen soldiers to gather. Sure, it's not the most intelligent way to place a mill, but it's better than Jubot's method and certainly better than nothing. No clue how you'd do that though. Speaking of Citizen soliders, I've been poking around in the code and I think I've found a way to get them to gather and build too. I'll give it a shot over the weekend and post a patch on the off-chance I get it working. Again, nice bot. Keep up the development!

Having a small effect on each unit under the influence of a given aura was also the way that DoW did things, and I quite liked it. It would probably be more difficult than the suggestion in the first post but much better. I don't think it would hurt immersion if there were some small effect that told you if an aura was active. For what it's worth, I would prefer an effect on each under the influence of the aura over an effect on the unit emanating it,

Little info dump here: Trac has all kinds of nifty links in the wiki, check the following for information for artrists http://trac.wildfiregames.com/wiki Also, if you dig around in the Design Document some, there's Civ profiles with info on all the units for each civ plus what they're supossed to look like, etc. Not much in the way of the Persian ram though... http://trac.wildfiregames.com/wiki/Civ%3A_Persians#SIEGE But there is enough info for a image search! On a related note, will the Assyrian Ram be the one with the tower? It would be pretty cool, like a mix between a normal ram and the Hele siege tower. Certainly a unique unit.

Nice bot, I spectated a Split vs Root vs Ju match and Splitbot won Keep up the good work. Also, that Wordpress plugin sounds pretty nice. Just a heads up, Ticket #951 makes max pop avaliable to an AI player. Now you can teach SplitBot to stop building houses when it's pop limit = max pop Credits to quantumstate.

I would love it too if we could get things like ditches and what-not. Personally, I would love to see a type of barrier that's just angled log spikes stuck in the ground, all facing the same direction with two or so feet between the logs. Infantry could pass between the gaps going both ways, but Calvary couldn't (or could only go one way.) Anyways, until there's some sort of drag-n-drop or other wall placement improvement, placing the new barriers would continue to be a pain and probably never used. On the topic of multiple types of barriers, the UI needs a bit of a redesign when it comes to building icons, something like this concept where buildings are separated by type (military vs economic vs special.) If we're going to have like, four or five wall/palisade/ditch/barrier types, then they really should get their own category (and Special buildings should get sorted into whichever other category they belong.)

Loving the new Cart trireme! Easily the best ship in the game!

Turns out, I have to make a trip this weekend, I won't have time to finish my section of the map. If anyone wants to do a portion, feel free. I'll do my bit after them. Otherwise, I'll have my section done on Tuesday.

Hooray! That's the right file I'll Purple now.

I suspect the problem might be that Atlas is saving the map someplace strange. There's a threads about atlas saving maps in weird places, if at all. I don't have access to an ubuntu box, so I can't really help you find where your version of Migration might be saved. I looked through the tickets for Atlas and didn't see any tickets for strange save behavior...

Huh. I deleted the version of migration I had, used that one and got the same results. meta data says that file hasn't been modified in 3 days... One of our computers is doing something screwy

Uh-oh. Are you sure you uploaded the right version? That one looks like SMST's, it doesn't have any of your changes

Looks good. Just don't make it so hilly that buildings can't be placed. I would like to work on purple before you do blue.

The only recommendation I would make is to change up the trees a bit. See how the previous portion did little stands of six or so trees? You should do that, instead of having a bunch of individual trees. It'll look more cohesive, and be better from a player's stand point (I hate picking off individual trees, but going after stands makes it worth my time.)