wraitii

About that... How "possible" would it be to allow the AI to initialize before the start of the game (ie during the creating map" part)? That woul allow for some slow calculations such as terrain analysis to be noticeable.

Well, I'm not really using entity collections since I was never sure how they worked... Mainly the "entity" class, afaik. I like most of the changes planned so I'll likely upgrade when it's released and I get time (thoough I'll be on holidays again by that time, so I'll have, well, time)... Is the "UnitAI further support" going to be implemented? That would be a huge argument in favor of upgrading for me. (reading your qBot post, looks like yes). Anyway, thanks for the support

A little further progress report, I've begun coding... The classes implemented to store and count buildings and units are basically done, though I'm adding new functions as I need them. It's fairly interesting, since it allows to do a lot of counting in a faster way, and it's also more dynamic (units are no longer hardcoded, which would help with mods, scenario, or new civilizations ultimately). I'm now working on having everything work with the new system, and changing everything I'll need to change, which is a lot. Not sure how long it's going to be.

I believe to do this efficiently you'd need three classes inheriting from a "basic sound manager"... -A "music" class would deal with musics... It would support pauses, fade ins, fade outs, and presumably only use one "Stack". -An "ambient" class which would perhaps have an "ambient" sound looping, and occasional animal sounds or things like that (2/3 stacks at most) -An "effect" class which would deal with short effects: GUI sounds, unit sounds, … They should be played immediately or not at all. I dunno how many "stacks" you'd need for that, probably a few to support simultaneous effects.

I'm supporting Jericho too, if a new wall system is made... Not sure about Jerusalem, it's a bit too religious for my tastes, particularly given the timeframe (no christians nor muslims back then)...

Getting Judas and Jesus out of the way. Though "0 AD Alpha X Jesus" comes really close to perfection .

Indeed, it works perfectly, thanks Geek377.

There is a problem in 0ad, it's that if a unit chases another unit at the exact same speed, they will chase each other seemingly forever. Bad. And ranged units sometimes, to try to get "in range", will move forward,start attacking, realize the enemy is inbound, retreat, and repeat. Ranged units, if chased, should be faster than melee units, and should know how to get a "comfort zone" that would give them enough time to fire and not be attacked.

I'm fairly sure even a 1% opacity layer would make it clickable while still having the transparent effect.

Yes. It wouldn't be a problem if the circle was full, but as it stands now, the transparent parts in the middle are unclickable.

This is minor, but you should change the icon. if it's put on the desktop, you have to aim for the icon, because if you click on the void, it won't select it, which is a pain.

Yeah, there are two kinds of problems here: -One, the case where something is unreachable but the AI asks to gather it anyway. In this case, the AI has no way of knowing that, and thus can't react. My best guess at fixing it would be to send to the AI an "unreachable_destination" event that would give the ID of the unit. Then the AI can process it (I dislike having UnitAI do that itself for the AI, as it can be too unpredictable/not react as wanted). -Two, the "lone tree on the map with 50 villagers around" case. This is specific, it happens to qBot and Marilyn when chopping for wood. Sometimes, workers surround the tree, and then a new wave of workers surround the first wave, and so on, until everyone is stuck around the tree. Again, in this case, there is the "short term" solution of having an "unreachable_destination" event, but also a more long term solution which should, imo, be implemented: We need a way for the AI to know what a unit (entity at large) is targeting. This way, we could count how many units are gathering from a tree/attacking a unit. This can only be done efficiently at the unitAI level, because the player AI is fairly "abstract", and acts a lot like a player. Sometimes, units react autonomously because of unitAI, and right now the AI can't know that, so it might get stuck. Therefore, the UnitAI must store the target (I studied that script a bit, I imagine it would be "fairly" easy to do and pass to the AIs). I also suggested an optimization: when setting a unit to a new target, add this unit to a list on the targeted entity, and remove it when it's unassigned from that entity. This would allow to, by checking from a tree, know how many units are gathering it, instead of having to recount every time.

That would work too, FeXor, though as Quantumstate said not now... But it implies you have to loop through every worker unit every time you want to know. I think doing this in the engine would be more efficient and more elegant, since it "basically" should only involve a putting stuff in a variable instead of looping through entities, counting stuff, returning the result. If it's done at the "UnitAI" level, it would also make it easier to make sure no case have been forgotten, I think. The UnitAI definitely needs improvement with AI Interface, however.

What could also help to solve such thing would be to have the game register entities interacting with each other. When clicking on a tree, the "tree" would remember the ID of the unit assigned to it until it's no more, so the AI can know at each time how many units are working on a resource. This could also be useful for attacks. It sorta can be hacked in by the AIs using metadatas, but it's not nearly as efficient.

That's actually nearly impossible to prevent given how the AI/UnitAI/Pathfinding is currently implemented. These issues, imo, could be solved by the improved pathfinding Philip is working on, and some sort of "target_unreachable" event for the AIs.

It is a known issue on Mac OS X. I'm afraid You're going to have Alpha 10 to play with sound. Meanwhile, you can listen to the music while playing.

Allright, further progress report: I'm basically settled on what architecture I'm going for... I think it should prove fairly solid and I don't think it's up to much change. I however have a ton of work right now, so I have no idea of when my "feature-equivalent" rewrite will be finished. (it's not a complete rewrite, I'm merely reorganizing stuff, but I'll also clean up the code, make stuffs more coherent, and add a few things.)

Given there are many oases, you might want to go for more realism, and make the surroundings of the Oasis more Bushy with a few big trees, and perhaps small forests on the sides near the player. The oasis would ideally look more like this:

Anyway, to further press the "progress report" thing: I'll likely reconsider some of the current Marilyn implementation. The need for distinction between the economic and the military manager is getting scarce, since the latter does very little, I think the queue manager could be upgraded to deal with "needs" on a more global scale (particularly for the forthcoming technologies), and the tactics manager should be implemented better, I'll have to consider it. The defense manager could also certainly use a overhaul, as well as the attack manager, but that's not as high on my priority list. I'm scrapping my former to-do list here. After much thoughts, I now think the priority would be to make the AI more self-aware before considering complex attack plans, or overseas invasions. As it stands now, the AI is almost completely oblivious to itself, a very bad situation indeed. It builds units it can build, but it's not aware if it's got 1 or 10 barracks, things like that. This would make it hard to actually implement complex decisions, which happen to be a requirement to really improve on Marilyn now. edit: this might be subject to change, but I think I might go for a "self-manager", a "plan manager", and a "defense manager". The self would deal with economy (assigning villagers, things like that), aftermaths of attacks (rebuilding destroyed things), consider starting plans (building plans, house plans, unit support plans, attack plans, scouting plans, technology plans, whatever plans), things like that. Sort of an AI HQ. Then the plan manager would deal with all the plans (might split the attack and the scouting plans from that, at least once they're started), so it would have an easy way to centralize resource needs, and the defense manager would be an overarching manager that would simply check for attacks and create plans accordingly if needed (tower building plans, walling plans, "putting units there to check" plans,…). Again, subject to change, but I might keep an "enemy watcher" plan, that would keep track of enemy units and buildings and strategies, and would be used by the rest. And an "micromanaging" manager, that would deal with petty things like actual attacks.

I didn't look into the code, if they only rely on bwapi for the initial phase, it should be fairly updatable, but if there are more calls, indeed it could be "easier" to simply recreate everything. It could also be more suited to 0 A.D., which has you said has more open-ended maps. I'm also unsure whether Starcraft has water... I've never played it, but this would require two different settings in the algorithm I guess. I think it's the way to go for the AIs though, because chokepoints could really be useful, particularly for pathfinding and strategic defense. (0 A.D. also has some "open-ended with chokepoints" type map, such as Oasis, where the behavior of the algorithm would have to be tested.

I can't recall the reason I started doing that. I think it was because of water maps, which I wanted to detect... And then I got a bit carried away, I guess. I also wasn't sure how the gradient method behaved in purely concave maps, and to be perfectly honest, I'm not sure I get how the code works. But as it stands now, the A* implementation I tried is far from perfect (well, it works, fairly well even, but it's too slow on big crowded maps. And I'm really not sure it's the right way to go, as you've seen in the other post, there are likely better ways to do chokepoint detection, and thus path finding). It'd make an efficient flood fill, if that's needed.

Yeah, qBot's got a system using gradients to do that, which while very efficient, I found a bit too inflexible. I do agree however that simply using "artificial blockers" should be enough to have paths that are not optimal ( an alternative I considered was dynamically targeting X° from the actual target, as to do a spiral movement, but it's not exactly fast to compute.) Ultimately, I think the better system for an AI would be to have a knowledge of chokepoints, something like this: "start from TC. Go to chokepoint 1. Go to chokepoint 2. From there, the field is open". Perhaps with some sort of "degree of liberty" to try and overturn the enemy. Some sort of very very abstract pathfinder, relying on the C++ implementation to actually move.

I've been trying for the past couple days to implement a convincing system to detect chokepoints in Marilyn, and failed. Searched the internet, and found this paper, which suggest a freely available API already exists, coded in C++, to deal with exactly such things. Any chance this could get into 0 AD? Adaptability can be a concern, but given the input received, I think it shouldn't be too hard to adapt.

Okay, some progress report... A javascript A* is either too laggy, or way too slow to finish to be any purpose on a large map, even with serious optimizations. I'll likely keep it to detect islands and things like that, but I'll have to use something else for Chokepoints. As soon as Philip as finished the Pathfinding work, it'd be really useful to have access to some sort of C functions in that regard.

Adding on the Idea;.. Perhaps these skirmish maps could have a few "variations", abit like how Oasis has 10 versions. You'd make 3/4 slightly different versions on Atlas that would get loaded randomly, just so that it's not too boring.