On 2/5/06, Bradley Arsenault <[EMAIL PROTECTED]> wrote: > **Upgrading and repairing** > This was my first module. My first behaviours. And frankly, the code > has changed very little since. When I first made it, I got it right, > for once. I had spent plenty of time working on the upgrading system > when i first started nicowar. Since then, some of its behaviours have > more or less become useless because the surrounding enviroment has > changed, although I do know that its original behaviours where best. > > I don't have the time to explain everything else tonight, expect the > completion of htis email in around 10-12 hours when i've slept. > Ok its 10 hours later, i'm refreshed, and ready to finish explaining. Upgrading and repairing is done via 4 turns. The first turn, it decides if it wants to start upgrading or repairing a building, and if so, it does so. The first part of this algoirhtm builds up sections of statistical information, such as how much construction of each building type is going on. Next, it goes through all the buildings it possesses, sorting out ones that the game forbids it from upgrading or repairing, and clumps them all into one large vector. Lastly, it performs a "weighted random shuffle" (line 1255) on the list, so it naturally upgrades some buildings before others, but still with an accent of randomtivity. It then decides how much construction it should be doing. This is given by deviding the total number of buildings for each building level (level 1, level 2, level 3), by 5 (line 1252). So, in turn, with 10 level 1 buildings, 15 level 2 buildings, and 5 level 3 buildings, it will set its maximums to repair 2 level 1 buildings, upgrade 3 level 1 buildings to level 2 or upgrade 3 level 2 buildings, and upgrade 1 level 2 building to level 3, or be repairing one level 3 building. It sends this information to the unit module so that the module knows how many units it needs to make. It then enters its main loop, where it starts construction on buildings untill it runs out of units available. 90% of the time, it will not have enough units available, and this loop will exit almost instantly.
On the next turn, it updates existing constructions. On this turn, it doesn't spend as much time creating statistical information, but instead just finds out how many units it has available, and goes right into the main loop. The main loop is composed mainly at looking at existing construction, and seeing it it can assign more units to the construction, given it has more available. It will also stop cosntruction if it has not enough units to proceed, but this never happens anymore, a result of the usage of "unit manager", could be pronounced as a design flaw. The other two turns are composed of removing buildings that finished beeing upgraded/repaired, or where destroyed during construction, and updating buildings that are no longer pending construction (meaning that there waiting for the building to be empty of units, and waitinf for units to clear the area around the building so it can expand). **Exploration Management** This is the second oldest module I created, I started itright after the completion of the upgrade/repair module. Despite popular belief, the exploration module does do explorer attacks, however in common practice that has never happenned and the code has remained untested for months. The explorer module starts by figuring out if it wants to make any new explorer flags. It allows itself no more than 4 flags (line 1275) at a time. It then goes through the various "zones" in the map, looking for the "zone" with the highest number of hidden squares, but still has atleast 1 visible square. It also takes into account the distance of the zone from the center of the map, so that in naturally puts explorer flags around its home base. It then goes through the zones, best to worst, creating new flags on zones that don't already have flags on them, and not making any mroe than 4 (line 1275) flags. Ingenioussly, there is an "update" turn that finds flags that have been created and stores their gids in their assocciatted record, and destroys flags that have no hidden spaces in them. The other two turns just decide if the ai should be attacking with explorers, and send the number of explorers the module is using to the unit module. **Inn manager** So small, yet so important, the inn manager performs things very simplisticly. Its first turn is comprised of recording the amount of food in the inns. It keeps a record of how much food the inn had in the last 10 (line 1294) turns. So it keeps a fairly recent average, but an average none the less. On the next turn, it will go through each inn, and assign a certain number of workers to it depending on the average amount of wheat needed to fill it devided by 3 (line 1296). So for every 3 wheat the inn is from beeing full, another unit is assigned. This approach doesn't handle the fact that some inns are farther from ressources than others very well, but has the advantage of being clean, simple, and effective. **Tower controller** At this point where onto the simple modules untill I hit the explanation of the unit module and how it causes problems. Well, the tower module is extremely simple. On its one turn, it looks at every building, and assigns 2 (line 1301) units to every tower not under construction. **Building Clearer** Also very simple. On its two turns, it goes through all of the buildings, and adds clearing area arround (line 1401) all buildings that aren't under construction. It removes padding from all buildings that where destroyed, or have gone under construction. **Happiness Handler* On its one turn, this module will turn on inn view agaisnt every opponent that has inn view turned onn against them, and against every opponent who has a worse average fruit rating then he does. **Farmer** This one is a bit more interesting. Its currently disabled in the cvs version, but normally, it would put restrictecd zone over wheat, wood, and algae in certain patterns (line 1407). The different patterns are given at lines 1197 to 1200 AINicowar.h. **The unit manager** The unit manager was a good idea. It looks like a good idea. And it allways will seem to be a good idea. However, it is a bad idea if not done properly, and I have failed to find any good way of using it. The unit managers task is simple: to manage units. To try to keep all tasks running fully. It keeps track of 3 arrays of numbers from every other module. It also keeps track of "tasks", or buildings and how many units are assigned to them at what levels. All the other modules send in their "demands" for units, which is essential for good management. Those numbers provide the maximum number of units the module is going to use based on the attributes of the unit its asking for, such as warriors with level 3 in attack strength or workers with level 1 in harvesting. The modules can then go about their buisness. When it coems time for them to find out how many units are available, they ask the unit manager. The unit manager does a few things to try to keep the balance among units. First of all, its gets the number of available units with the desired properities. It then iterativly goes through each of the buildings that have been recorded to have units assigned to them, and if those buildings aren't full enough, it will take out some of the units from the oens that are "free" that will begin working on that building. It then goes through the modules, looking at every one that is "requesting" units with the same properties. The units go to the module that is using the lowest percentage of units based on the number it wants to use. If the module that gets the units happens to be the same module that is asking for the number of units available, the manager happilly gives the units too them. >From this description, you are probably wondering "well it sounds perfect what could go wrong?". Its very difficult for me to get into the pecularites of the unit manager without getting into the exact implementation. Things such as what to do when the units aren't going to be used yet, because the building is waiting to be empty to start being upgraded, so the units have to be "reserved" during this waiting period. Or perhaps how the number, since it is always 0, the upgrade module will never stop constructing a building, because it will never be "short" of units, because the unit module will tell it thats its trying its best to keep the buildings in question fully active. The unit module is simple, but hard to perfectr, extremely hard, so If anybody has suggestions on how to do a unit manager effectivly, one that handles all cases for glob2 (which is a complex game), or how I could do without a unit manager, be my guest. **Finish** If you read all this far, thankyou, your support and criticism is appredciatted. _______________________________________________ glob2-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/glob2-devel
