quantumstate

Yes, the AI gets information about every entity in the game. I not sure that rotation is there currently but it could easily be added. What is more tricky is actually using this information sensibly.

You have used a weak equality check so null, 0, ""and false will be changed to undefined, is that intentional and why would you want that to happen? If it wasn't intentional then you have basically inserted a null operation (though from a quick search we do seem to have some of these checks in the entity.js file already).

Currently AI's are run as part of the game simulation. This means they run on every machine that the game is being played on. So by using a network game with AI's it would be identical to a single player game but with added syncing. So unless we redesign how the AI system works this si pretty pointless.

It isn't in svn yet. If you want to test it you will have to apply the WIP patch from http://trac.wildfiregames.com/ticket/786 and recompile the game.

I didn't fix the no resources warning. I left that because it needs fixing properly, currently running out a resource type will cause the queues to start getting blocked and the AI won't play well. I still can't get that Sicilia error, I just tried on a clean svn. Can you get the whole of interestinglog.html and see if there are any other errors? Also if you could put warn(uneval(type)); in gamestate.js at line 41 that would be helpful I think.

Can you test this again. I can't reproduce it, I think my recent changes have fixed it.

Thanks for the report, it should now be fixed.

Hi, welcome to the forums. AI is my main area of interest here so I will be looking forward to seeing what you come up with. I will be curious to see how far you can push the agent idea. I have just started trying to introduce more of this style into qBot, (the new worker.js is the only example so far, I'm hoping to add military sometime). My view is that this isn't particularly well suited to RTS AI's as a whole, the resources are inherently centralized and when fighting you want your whole army acting in a coordinated manner (based on practically all military theory for non guerrilla warfare). Hence I have decided on a single central planner system for qBot. This is mainly guesswork though, hopefully your AI will surprise me .

This information is basically available to the AI. There are two different concepts of a unit attacking. The UnitAI controls each unit, and is now exposed to the AI's, so you should be able to use a combination of UnitAIState and UnitAIOrderData to work out what target a unit is attacking or trying to attack. You can read simulation/components/UnitAI.js for details. This won't tell you directly which units are attacking a unit, this information isn't stored by the game, but you could construct it yourself. Secondly there is a set of events sent each turn to the AI's, this is found in this.events if you are inheriting from the baseAI and contains a new set of events every time OnUpdate() is called. This will have an event for every time one unit does damage to another in an attack. You would again need to do some manipulation to get this information into the form you want. Thanks, I have fixed this now. Edit: The updating entity collections handle updates to properties, not just unit creation/death, this will be especially important when we have unit conversion happening since most of the time you filter by owner. There isn't an real optimization currently, but if it runs too slowly then I was thinking of adding a hierarchical system to help with filtering.

I had branched the common-api-v2 code before the saved game serialization was implemented for AI's so was missing some functions from the base,js file. This should be fixed by commit 11522.

Returning the number of foundations +1 is not intended, however I am looking at the function and it looks fine to me. [b]GameState.prototype.countFoundationsWithType = function(type) { var foundationType = "foundation|" + type; var count = 0; this.getOwnEntities().forEach(function(ent) { var t = ent.templateName(); if (t == foundationType) ++count; }); return count; };[/b] It is just meant to count the number of in progress foundations.

Yes, read the unit template xml files (public/simulation/template/...) for more details .

The AI stuff is completely separate so won't help you with this. I would take a look at StatisticsTracker.js in the components folder, it is pretty similar to what you want to do.

We already have attack dogs for the celts, they are trained from the kennel. Hero's should do similar stuff to what you mentioned but the aura bonuses aren't implemented yet.

That is an AoE 1 rise of rome unit table. It won't be too much help for 0 A.D. http://trac.wildfiregames.com/wiki/Unit_Summary_Table is more useful but is a bit out of date and we have unit attack bonuses now which aren't shown in that table. Relish, I think that looking for AoE2 strategy articles would be helpful, 0 A.D. is pretty similar in style, citizen soldiers are the biggest strategic change in my view, plus the lack of implemented technologies (though this will change).

I had been thinking it would be nicer to have programming effort concentrated on a single official bot, I don't know what you think about it. The main problem I guess is that AI's can have such a variety of implementation that people might want to take differing approaches like we have previously. To some extent this could be helped by modularizing carefully and allowing multiple module implementations to coexist. I have found being in charge of my own bot quite nice though since you decide what you think is best and do it without having to consult people etc. Plus having multiple bots has a competitive element which can help drive development. I think these are outweighed by the duplication of effort and working collaboratively is nice as well. If we did this then we could just name it someone pretty generic like AI Bot. These are just my thoughts though, I won't object to anyone not wanting to do this.

Here is an example of how to use the new API. The new API is almost completely backwards compatible with the old one with the only breaking change being the removal of ownEntities. if (!this.allWorkers){ var filter = Filters.or(Filters.byMetadata("role", "worker"), Filters.byMetadata("role", "militia")); this.allWorkers = gameState.getOwnEntities().filter(filter); this.allWorkers.registerUpdates() } When filtering from an existing entity collection the new collection will inherit the filters of the parent. This will make this.allWorkers contain an entity collection of all units with a role of either worker or militia which will be efficiently updated. For the updating collections to work you should use the filters provided by Filters. The special ownEntities case has been removed since this is easily implemented using Filters.byOwner. qBot's gamestate.js gives examples of how this new system could be used

That is looking pretty nice.

I am away for the next week, the conversion to the new api still isn't complete yet, it is mainly the military area that still needs some changes. Some ideas for things which could be implemented: #1258 needs looking into. My recent changes have probably broken the test case though so it might be better to pick out an older revision and use that. May be quite tricky to debug since it is very rare. Limit the number of workers gathering from each resource, so that we don't get idle units because they can't all fit round a mine. Make gatherers gather from resources based on their gather rates. So females should gather from farms and citizensoldiers should focus on mining and wood, etc. It should read the values from the templates for flexibility. One idea is to keep the code as it is now and then put in some code to swap a pair of units when this would give more efficient gathering. Related to the previous idea is to get units to deposit resources they are carrying. This saves wasting resources when a unit changes tasks. Do you mean terrain analysis stuff like http://www.wildfiregames.com/forum/index.php?showtopic=15764&pid=235859&st=0entry235859 ?

This should be working soon after the healing patch has been applied. This should happen by Alpha 10.

That sounds like the bug I am experiencing. I am afraid of breaking stuff when upgrading system libraries though.

I have collected a few references from around the web and put them below, (lots of pictures so they are in a spoiler). To get extra height you can lower the entire map to the lowest possible and then add a bit of height to land areas. By default the terrain seems to start about halfway up so you gain a lot of range this way. If you look at my references you see that the area is pretty bumpy and forested, so you should definitely avoid creating a plateau like you have now. Cliff don't need to be as high are you have made them and they can be less steep as well, this will improve the look of the texture since it is less stretched. I made a rough mockup to see what might be possible, a screenshot is in the spolier. Some things I found were that the Mediterranean rock, shrub grass combinations work nicely for the kind of cliffs in the area, I also added some bushes to the slopes. There are lots of trees in the references. Though be a bit careful since too many trees cause issues, if you can use actors instead of entities on the inaccessible areas this will help. I found setting the suns angle to be fairly low helped to see the shape of the land much better, it is easy to experiment to find something that works well once you have a few basic hills on the map. I did all of the shaping first, then went and textured the area and then added trees and bushes, this helps make everything look natural since you can put cliff texture on the steepest bits etc.

JuBot is not being maintained very actively. It is likely to be kept compatible with the game for a while but the main author Jubal hasn't been around for a while and I don't know of anyone else interested in working on it. The qBot gamestate is likely to change in the near future as I do more work to convert to the new api. If you want to switch to the new api it would be good to switch, otherwise it probably won't be of much benefit.

Thanks, this is fixed now. I should remember to run the tests before committing.

This is great.