[glob2-devel] Re: Full Nicowar behaviour assessment

[Bradley Arsenault]

On 2/5/06, Bradley Arsenault <address@hidden> 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.