My new AI, people on IRC should know about, may be ready in time for the next release. There are three things that need to be finished before it can play the game: attack, defense, and building construction. Obviously, building construction is the major one. I can cover basic attack and defense in a day, maybe tommorrow if I get enough time. Building construction is somewhat larger ... I probably won't finish that before the release. However, the AI still plays very well with an existing settlement, its control is excellent, it can keep 150 workers with an average starving number of 7, not bad.
The AI is devided into modules. Not litterall modules, as in class AIHelper_Module, but in theorie. A module is a group of functions inside the AI that serve a particular purpose. It is very important that each module is self dependant, the only interaction one module has with another is by inhibbiting factors. Probably the most important factor to make the AI run smoothly is every module telling the swarm control module how many units it needs to do its job, with priorities. Less important factors would be something like the defense module telling the construction and upgrade-repair modules not to do anything in an area that is being attacked. The AI works by using an iteration system. It circles around in a number of ticks, and given times throughout that iteration, it runs certain functions. So the AI remains pretty fast, 80% of the time its returning null. However, isntead of directly returning commands, it puts them in a queue. This allows one function (for one action) to queue up several commands. And at the start of each of the following ticks, it checks to see if anything is in the queue, if so it returns it. Its systems are very statistically based. They always reads in, stores, and recovers statistics. It always records what it does, not permamently, but untill its done doing it. So, unlike the other AI's, it knows exactly what it was doing, rather than figuring it out each time, which is what allows the iteration system to work. I try to minimize threshhold algorithms, and use reletive statistics whenever possible. However, if you examine the code, I don't *always* do this, I haven't had enough time to fine tune the AI. Perhaps the most innovating part of the AI is its configurability. Everything it does, how many units it assigns in certain situations, grid sizes and overlap, is all defined by constants. I try to put as much into constants as possible, this allows, in the future perhaps, the ability of multiple difficulty levels! I thought of 5. There are the general three, easy, medium, and hard. And then there would be training, which would bassically play hard except it never attacks, so it can't win. Would prove very usefull to a new person to try out different things while there getting accustummed to the game. Impossible mode would bassically be the most fine tuned I could get it. Try everything, do everything, attack everything! It is what I'm aiming for right now, the most difficult of AI's. Of coarse, difficult changes would require changes in the gui. Another thing my AI does that may be of interest is use grids. It has a simple, abstracted set of functions for operating on the grid in chunks. For example, the AI will go through each grid sectiont to find one that has the most hidden spaces, then put an explorer flag on that. Andrew thought that using grids may be of use to lighten the load of the wavefront algorithm dramatically. Rather than having a path for each resource and building, just have paths for each section of the grid, and the globs can move between grids. This would allow for section checks as well, meaning if a section hasn't changed, don't recompute it. Last couple of thins I'm going to mention. I try to document the code very well and fully, on each function and member. Hopefully, this will allow other developers to understand the code fully. As of right now, the code does not conform to Glob2 style guidelines. Thats not too hard to fix though, I just change my bcpp settings to use tabs and stuff. As well, I use std::random_shuffle, which doesn't use sync rand. I'm trying to find a way around this, the one apparent solution is to make a RandomNumberFunctor and use it for the random_shuffle, but later I want to do weighted random shuffling, so I'm considering writing my own algorithm implementation. A weighted random shuffle shouldn't be too hard, I've already thought of a way to do it. However it becomes more difficult when you use multiple weightings (say increased weight because a building is an inn, decreased weight because its near enemy warriors). I'll have to do that before the next release. The AI's individual modules are explained on http://www.globulation2.org/wiki/AIHelper. I would welcome any comments. On 11/18/05, Andrew Sayers <[EMAIL PROTECTED]> wrote: > It looks like we're going ahead with another quick release in the next > few weeks, which I assume we'll call 0.8.16. Could people who have code > they would like to see included (which is ready or almost ready for > inclusion right now) speak up? > > Also, we need people to make binary packages of the game. Making a > Linux tar.gz shouldn't be too hard, but is there anyone out there in a > position to make a Windows or Mac release? TMM created an autopackage > version of 0.8.15 a few months ago - can you make one for 0.8.16? > Vincent Deffontaines <[EMAIL PROTECTED]> is registered as having > created/uploaded glob2 into Debian - Vincent, are you still around? Is > there any chance of an update for 0.8.16? > > - Andrew > > > _______________________________________________ > glob2-devel mailing list > [email protected] > http://lists.nongnu.org/mailman/listinfo/glob2-devel > _______________________________________________ glob2-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/glob2-devel
