gudo
-
Posts
238 -
Joined
-
Last visited
-
Days Won
2
Posts posted by gudo
-
-
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...
-
...Personally I favor the only limitation on population being on how many houses you can build per civ center.
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.
-
-
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.
-
My point is, some @#$% like myself could just wait around for the new player to respawn and then kill him off in his infancy for whatever rewards that yields. If someone's empire is massive enough, they could likely maintain this procedure over several deceased players at once as a secondary source of income and @#$%ry. So this raises the question, what mechanisms could we introduce to deter players from taking advantage over new players?
One thought of mine is not only spawning in a random position on the map (let's say we have 60 designated spawn points for a 20 player map in which we've determined there are ample resources and land to allow no player to have an unfair advantage), but not announcing when the new player enters the room.
In this sort of game mode, we need to figure out how to allow players entering mid-game the time they need to develop their economy before a greater faction wipes them out, having been in the game for much longer (and subsequently destroying the opponent that existed before them).
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:rootbotI 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 -writableRootIt 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]
-
If I could give u a little advice, I do not think that fixed positions of farmsteads or slots for farms and similar things will be good idea. After few games online u can predict position of this positions etc.
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.
-
Hmm, is managing wildlife population levels a fun activity for players to engage in? I'd expect any equations would devolve into some trivial guidelines ("always hunt everything except for 5 deer then wait 30 minutes and repeat") that players would look up in a guide, and then the gameplay would consist of panning over the map and counting animals, which sounds pretty tedious to me and would distract the player from the main focus of the game (managing their economy and military). It could be a good component of an ecology simulation game, but we're making an RTS game, and I don't see how a mixture of the two could really work.
(Incidentally I happened to see some documentary recently which rubbished the idea of modelling ecosystems as mathematically stable systems, since they're actually not stable at all - they're constantly changing, and after a sudden disruption they don't return to their original state. I think the programme may have made some potentially dubious claims, but it sounded convincing that stable systems were an inaccurate oversimplification of real life, so it probably wouldn't be "very lifelike"
)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?
-
Hmmm.... You would also want your animal spawning rate equation to take into account the carrying capacity of the map (the max number of animals the map can support) otherwise, you may end up with a map choked to death with animals. (medium sized map can totally support 2^256 deer.) Not only is it unrealistic, it would also cause our game performance to degrade over time. If I can find some old notebooks of mine, I can write up some nifty equations for rate of population growth with the following properties.
If the population is ever above the carrying capacity, the population starves till it falls below capacity. (eg, what happens to the lions when people kill half the deer population.)
The population grows fastest when it is far below capacity (more resources per member of the population) and slowest when it nears capacity (fewer resources per population)
*optional* When the population falls below some critical value, there are no longer enough members to restore the population, it will eventually go extinct.
Determining the carrying capacity at any give time would be easy enough I think. For herbivores, we just take the grazing area and multiply it by some constant (1 acre can support 10 deer. If we have 30 acres, our carrying capacity is 300 deer.) Thus when a player builds buildings, he decreases space and lowers carry capacity. Carrying capacity for predators would be easy too, just relate it to the number of prey items avaliable. So when the prey population decreases, the predator population will fall till there are enough prey to support it.
With four equation\s, I think we could make a very lifelike predator/prey model emerge in the game.
Territories
in Game Development & Technical Discussion
Posted
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.