gudo

Interesting idea... I've been messing around with ideas for purple or neon green but it's clear to me I need a bit more practice w/atlas. I'll do a portion after NOXAS1 does his.

I don't think towers should contribute to territorial gain at all. Or any defensive structure for that matter. If they did contribute when built outside your territory, people would just build rows of them on the frontier, then another row on the new frontier, etc. We'd just end up with maps full of rows and rows of towers and walls. They're cheaper than civ centers and fortresses, once technology and phases are in play they could be build sooner too. They can garrison units, heal units, and kill units. Essentially, making defensive structures add to territories would make everyone "turtle to expand." Fortresses could be an exception because of their importance, but that just seems to shift the problem. I'm not linking the feel of dynamic territories that much to be honest... The only way I see them working is by implementing settlements as the only places to build civ centers, and by making another settlement like entity (call it a "strategic location" or something) that must be built on to expand your borders. Honestly, the best option IMO is to 1) make it so that only civ centers and fortresses expand territory and 2) implement settlements and 3) make Fortresses and Civ Centers only buildable on settlements. That way, instead of wall and tower spam, we actually create valuable positions that must be contested in order expand.

Updates? I've been keeping an eye on your google code page and I've noticed you've got a bit of work done. Any chance of a playble release soon?

Wait, I'm confused. Are territory borders dynamic?

Suppose I control two adjacent territories. May I construct a building directly on top of the border?

If you want my two cents, I'd suggest avoiding modifying the common API files (common-api/base.js class.js, etc) You see, there's no way to be sure that your changes will make it into the source. There's a ton of problems with this. Mainly the risk that your changes will break other bots and incompatibility with other common-api changing bots (RootBot for example.) Note though, those common-api's could still use a bit of development. If you want to make changes to the source, go ahead and register on trac and submit a ticket/patch. Are there any pre-compiled files that I could just throw into my install so I can try your bot out?

Have you considered applying for a spot on the team? You could help provide proper mac support.

Hey Christian. Something you should do is keep an eye on the 0AD RSS feed and set up a translated feed on your site. The RSS is pretty low volume so translating shouldn't take much work at all.

I would suggest you put shallow, crossable water in the river between players 1 and 6. Since we don't have a proper bridge. Also, it's possible to make a bridge, you have to get creative. Here I have a little river. I've gone ahead and put two "other/bridge_hele" over it. Clearly though, they ain't bridges. Now then, what you'll want to do is raise the land between the bridge pieces, smooth it out, then pain it an appropriate texture. It'll look just like a bridge! Somewhere, Mythos_Ruler posted a picture of a bridge using roman props and it looked great... Can't seem to find it though and my bridge looks terrible! Well, forgive the 3 minute hackjob It'll take a bit of practice, but that's how it's done. Like I said, the other option is to make the water shallow enough to cross on foot.

Hmmm... You're not using the modified common api's that rootbot uses are you?

If flying units are working, and walking units are working, can we get units that do both? The pegasus springs to mind...

Hmmm... You know, I don't think this is such a good idea. Territories are already going to grant a huge bonus for owning them (chiefly, you can build buildings there) making resourcing and military operations much easier. Allowing your max population to rise directly proportional to the number of territories you have is overkill. Suppose you're playing a 1v1 with 4 territories. Both you and your opponent get two of them, then you manage to take one of theirs. Now you have three territories, and they only have one. That means that your max population is three times larger, in addition to the other advantages you now hold. Not only can you now raise an army three times larger than they can, but you can also replace units faster. There's simply no way your opponent could win with odds 3:1 in your favor. A much better solution is just to put limits on the number of population increasing buildings. Say: 10 houses max (across all territories) 1 civ center/territory max 1 fortress/territory max This way, when you get a new territory, you wouldn't be able to say, double your max pop, but you could build another civ center and fortress and raise it by 20 (or however much they give.) In the above scenario, your opponent would never have to face 3:1 odds, but you still get a population advantage (in addition to resourcing, etc.)

The advantage with the method as specified in the wiki is three fold. First, and least important: it's more realistic. There are some older posts somewhere in the forum where people say they didn't like gold-based trading because it was kinda silly. Second, and most importantly, the "value" of a gold based diminishes with increased useage. Say we have a route between two markets that nets 50 gold per trip, and we want to buy wood. Wood starts off at 50 gold for 100 wood. So the first trip is worth 100 wood. But after we buy that first batch of wood, the price increases to say 55 gold/100 wood. So our second trip (still 50 gold) is now only worth 90 wood. The third batch being 60 gold/100 wood now means that the third trip is only worth 83 wood, and so on. We wind up with routes giving a constant supply of gold, but rising costs of resource purchasing. It makes the "value" of the route decrease. Third, and I'm probably wrong on this one, is because the plan doesn't call for "infinite" resources per map. If you want to buy wood from the market, it has to come from somewhere. Some other player has to have wood for sale.

Tickets: #23 - relating to barter #30 - relating to trade Looks like two different terms and mechanics for similar processes. I believe this is all the wiki has to say on the topic.

Personally, I prefer a resource/economy management system similar to the way Stronghold handled it. It's such a relief not having to micro the workers. All I have to do is make sure that my bakeries are in the right position. Somewhat related, https://code.google.com/p/castlesand/ is a GNU GPL v2 remake of the original KnM game. It's under active development and just released their multiplayer demo. Very much worth checking out.

Oh! Beat me by a few seconds! Anyways, seems to me that this glitch limits the functionality the same as the dev console mode does. You can direct units to gather, build, etc. However, any structure you try and place belongs to you. Additionally, you can select one of your buildings and an enemy building of the same type. Any unit you attempt to train is trained at your building. So you can't spend the enemies resources at least. Fun facts: You can shift+select an animal and issue a move order. The animal doesn't move, but all of your units will dash to the animal's location, as though they were trying to get in formation.It's a super fast way to move troops around.

Eh, could work. Might be a bit annoying to have to click three times to get to the "previous" stance. It would be great if, like Homeworld, stances were linked to some hotkeys. So whenever you pressed, say, F4, the selected unit would go to agressive. F5 would put them in Stand Ground, etc.

Rush timer sounds good to me. If any of your troops enter a newly colonized province, they take massive damage. Any of your structures in said providence are either destroyed or converted. This would not only give the new opponent some breathing room, but would also give them fog of war cover. You may know where they spawned, but you wouldn't know what they're doing or what their faction is. Adjusting the balance would be fairly easy, just increase or decrease the length of the rush timer. Another option would be to have them spawn with extra soldiers (say 3 women and 25 Hopolites) or give them a construction/training boost (for the first 5 mins, you build and train at double speed and half cost.) Probably some combination of all three would be the way to go though. Give them a bit of breathing room to start, but you don't need to wait five mins for them the get up to speed.

Oh yeah! Sounds awesome. It would work best once territories are implemented I think. Once a player is destroyed, we respawn all the resources that were there, and turn on a short rush timer.

I was testing out rootbot vs jubot with a little .bat echo off cls echo Ready to vs. pause pyrogenesis -quickstart -autostart=Oasis -autostart-ai=1:jubot -autostart-ai=2:rootbot I discovered much to my suprise that I could issue orders to player 1's units. So I wound up going from just sitting and watching to offering "suggestions" to jubot (he's got a bad habit of building things with my gatherers.) It's actually pretty fun. I had a ton of fun experimenting too (i.e. how much of an improvement do we get when jubot places drop sites intelligently?) It's a cool, interesting way to play. You should give it a try I also remember back in AOE II, it was possible to have multiple players control the same side (player 1 and 3 share control of the same units) some of my friends and I would have a great time playing that way. Are there any plans to support this type of shared unit control in the future? I sure hope so. Related, I've been trying to get this going with a 4 player ffa on a random map, but I can't seem to get the proper commands. Here's what I'm using. echo off cls echo Ready to vs. pause pyrogenesis -quickstart -autostart=latium -autostart-ai=1:rootbot -autostart-ai=2:rootbot autostart-ai=3:jubot autostart-ai=4:jubot -autostart-players=4 -autostart-random=-1 -autostart-size=256 -writableRoot It fails to generate the random map and spits out the following error. ERROR: JavaScript error: maps/random/latium.js line 421 TypeError: civEntities is undefined @maps/random/latium.js:421 ERROR: CMapGeneratorWorker::Run: Failed to load RMS 'maps/random/latium.js' Is there any way to specify each players civ in the command line?

I too didn't see any military activity, though I did notice RootBot creating hopolites and using them as gatherers. Another thing, I'm sure you know, but RootBot doesn't mine any metal. Also, it seems like it assigns nearly everyone to do the same task, and that creates an un-balanced economy. So even though it uses soldiers as gatherers, it still grows surprisingly slowly :/

Do you intend to continue updating your AI once your class is finished?

[EDIT]Never mind...[/EDIT]

Exactly my thoughts. Another thing to consider is "How much effort would this take to code?" Probably more than it's worth. If people making too many farms becomes a serious problem, then we can just the farms with the nerf stick a lot simpler than coding in a mechanism where farms can only be build in a few, certain locations. Another thing to think about with limited farming space is the effect on gameplay and available strategies. If each territory has a limit of three farms, then you can be absolutely sure that each and every player will have all three farms per territory. If they don't, their opponent might and that puts them at a food production dis-advantage. Now suppose one of those players uses a strat that relies on high food cost soldiers, while the other uses low food cost soldiers. With limited farming space, assuming each player has max farms (and why wouldn't they?) We can see that the first player with the food heavy strat is a disadvantage. He can't produce more food than the other player produces, but he needs more than the other player does.

Heh, don't tell my old bosses about that documentary I used to do a bit of population modeling for USA Dept. of Natural Resources relating to sustainable harvests and a tiny bit for some pharma corp. (populations of bacterium vs human cells. Actually very complex because there's hundreds of types of bacteria all competing for a slice of the pie, plus other factors.) In both cases, I was looking at the effects of big disturbances (for DNR, it was clear cutting, for pharma, it was the introduction of antibiotics.) But I digress. I really doubt that players would take a keen interest in managing population levels. There's simply too much other stuff to do, you can't track all the animals, you can't control what the other players will do with the animals and it just plain old sounds boring. I think they'd all adopt a animal management policy like "Just leave a few deer, and they'll come back." IMO, the actual game is too engaging to devolve into a park sim. Anyways, I got home and I looked at my notebooks and I realized that I was thinking far, far, far too complex. (population thresholds, competing species, varied resource utilization, etc.) Like you said, it's an RTS, not an ecology sim ;P The most basic of population models would work great in this game. Rate of growth = k(Pop)(1-Pop/Cap) Pop is the current population. Cap is the carrying capacity of the map, and k is an arbitrary constant used to fine tune the rate of growth. As you can see, when the population ever exceeds the carrying capacity, that second term becomes negative, so we naturally lose some population. Unlike a a more basic equation (say, "population grows by 25%") this means we effectively put a bound on the population. We'll never wind up with 2^256 deer even if we don't hunt for days. Also, the further we are capacity, the faster our population grows. How do we determine our carrying capacity? I was originally thinking we could have it be some function relating to the amount of grazing space, but that's just overkill now that I think about it. It would be better to just flat out define it. ("For large maps, the max deer population is 50. The max elephant population is 10.") For predators though, I think it would be cool if we defined carrying capacity as a function relating to the amount of prey items. ("The carrying capacity of lions is one fourth the current deer population.") Assuming lions ever get AI enough to naturally attack deer, then that right there is all we would need to establish a very realistic predator-prey relationship model. As for where you'd spawn animals, why not have them spawn exactly on top of existing members of their own race, then walk away?