159 replies to this topic

[wraitii]

Yeah, I'm having economic problems for some reason, I'm looking into this. I'm not sure at which point I failed that, but it happened.
Thanks for the report anyway, I'll look into that.

[Mythos_Ruler]

wraitii, on 01 March 2012 - 07:59 AM, said:

Yeah, I'm having economic problems for some reason, I'm looking into this. I'm not sure at which point I failed that, but it happened.
Thanks for the report anyway, I'll look into that.

I noticed Marilyn wasn't expanding like she should be, so I revealed the map and saw she had only built one house and no new units after 10 minutes of play. I set the game so I could control all the units when I saw one of her female citizens moving back and forth near a berry bush. I saw that she had her full amount of of food, so I attempted to force the female to drop the food off at the Civ Centre. The moment I tried to get her to go back to the CC she went back to the berry bush and continued her dance. She would not drop her resources off. It took be a very long time and many clicks to get her back to the CC to drop off her food.

[wraitii]

That's a weird problem, but I have reasons to think it's no more, because I changed a few stuffs and mainly made units depositing their resources before changing task much better.
There's also a rare pathfinding related bug where units can get stuck around a tree, or around a unit if there are too many workers, but I'm unsure how to fix that...
Last but not least, it appears she didn't build enough workers... I tweaked priorities, and now she's much better at resource gathering in the early game. Will playtest a bit and release a newer version.

[wraitii]

Allright, newer version here, that should fix bugs with the economic aspect of things.
Download link

A few screenshots, not related to the actual update:

[wraitii]

I just found a rather major -and- idiotic bug: Marilyn didn't build female villagers before starting to farm, which can cause resource collecting lag. Fix this by going in economy.js, and putting the line (791 or192)

this.trainMoreWorkers(gameState, queues);

out of the if condition.

Edited by wraitii, 01 March 2012 - 02:44 PM.

[JuliusColtranePille]

marilyn shall be included in the upcoming alpha right?

i think it should... if it hasn't any major bugs anymore

[wraitii]

My opinion is that it is nowhere near good enough to be the default bot, since qBot is really efficient, and I'm not sure it's ready to be an "additional" bot yet, though I don't know when Alpha 9 will be released.
Also, Mythos: some persons read the IRC logs . But yeah, the name sucks.

[Mythos_Ruler]

I have nothing but respect for Marilyn Monroe.

[Pureon]

Any updates/fixes?

I see you're using IRC now btw

[wraitii]

I've been working on a Corsica vs Sardinia map for the past two days, it's fairly hard to do correctly, so not much for now since the March 1 update. I believe I've made Marilyn attack the strongest enemy and that's about it.

[wraitii]

Okay, I'm back on this, I'll give a look to water stuff, but now I'm implementing a basic optimized A* for path calculation.

[wraitii]

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.

[historic_bruno]

Isn't there something like that already in qBot? I thought it used the data in the obstruction map for randomizing its attack routes.

However, since it's such a common task for AIs to want random paths (instead of always the optimal one), maybe it should be part of the pathfinder API. I've lost track of whether Philip's current pathfinder design is uniform cost or not, but changing the cost of certain tiles would be one way of changing the path. His optimizations might require uniform cost.

[quantumstate]

historic_bruno, on 10 March 2012 - 11:11 PM, said:

Isn't there something like that already in qBot? I thought it used the data in the obstruction map for randomizing its attack routes.

However, since it's such a common task for AIs to want random paths (instead of always the optimal one), maybe it should be part of the pathfinder API. I've lost track of whether Philip's current pathfinder design is uniform cost or not, but changing the cost of certain tiles would be one way of changing the path. His optimizations might require uniform cost.

qBot does have a very basic pathfinder built it. It currently uses gradient maps which should be less efficient that A*. It gets away with this by rarely calling that pathfinder (once for every attack launched).

The jump point search requires uniform cost (though binary cost is a more accurate term) so I think that the new pathfinder will have this. Current qBot just inserts blockers, which should be enough for fairly advanced AI.

I had also been playing with a crazy pathfinding idea which would in theory be really fast. I may never actually manage to finish it however.

[wraitii]

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.

Edited by wraitii, 11 March 2012 - 02:15 PM.

[quantumstate]

wraitii, on 11 March 2012 - 08:47 AM, said:

Yeah, qBot's got a system using gradients to do that, which while very efficient, I found a bit too inflexible.

What are you trying to do with the pathfinder? The gradients aren't particularly efficient for the current usage (I was planning to use thing is a more fancy way) but should be identical to A* unless you are using non uniform terrain weights.

[wraitii]

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.

Edited by wraitii, 11 March 2012 - 09:23 AM.

[wraitii]

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.

Edited by wraitii, 11 March 2012 - 02:16 PM.

[wraitii]

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.)

[Pureon]

Sounds good. Looking forward to it!