[glob2-devel] additional feedback on Globulation 2 (long, with many topics)

[Joe Wells]

Dear Globulation 2 gurus,

I have played more games and have another batch of feedback and ideas
for the wonderful game Globulation 2.  I hope you will find my
comments helpful.  Please feel free to ask me questions because I
probably haven't made some of my comments clear enough.

Once again, I have organized my comments into sections because there
are too many.  My comments are below.

Unfortunately, after this, I think I probably need to set Globulation
2 aside for a few months.  The real world intrudes.  :-(  I probably
won't be able to stop myself from doing a little bit of Globulation 2,
but I hope I have some discipline.

-- 
Joe

======================================================================
Flags, areas, and building work assignments:

I think a big decrease in the amount of micromanagement could be
achieved by replacing the maximum number of requested workers for each
building/flag by a priority number.  The idea would be that glob2
would calculate the number of available and eligible globules for each
kind of service and would divide them among the buildings/flags in
proportions according to the priority.  For example, if every building
and clearing flag had priority 10, then this would be equivalent to
giving them all the same number of assigned workers in the current
system, except that the precise number would automatically be adjusted
up and down as globules are born, killed, halt work to get fed/healed,
etc.  Based on my experience, I think this would dramatically reduce
the number of adjustments the player needs to make during play and
would give them more time to think about strategy.  In battles, I
think this would make an enormous improvement in the effectiveness of
war flags, because it would allow more easily shifting warriors from
one part of the battle to another and you wouldn't have to spend
precious time trying to calculate how many warriors you have of each
level in order to set the number of requested warriors correctly.
This would automatically adapt to the changing number of available
warriors as the battle rages and new warriors come and go to and from
hospitals and inns and new warriors come out of the hive.  Changing
from maximum assigned workers to priorities would also make it
possible to add some global controls over strategy.  For example, if
you noticed too many of your globules starving, you could adjust a
control that gave more priority to supplying inns, and this would have
the same effect as individually visiting each inn and increasing its
priority.  These global controls could work similarly to the way the
priority controls on a hive currently determine the proportion of
production devoted to each kind of globule.

It would be helpful if there were a flag that summons workers even if
there is nothing to clear.  I have wanted to try to force a worker
migration to another island to have a surplus of workers there, and
there seems to be no easy way to do this.  I think it might be better
to rename clearing flags to "work flag" and change things so that if
you turn off all of the kinds of resources to clear, workers will come
regardless.  (It would be good of course to keep the current behavior
that if clearing is requested and all resources are cleared then
workers do not get assigned.)

It would be nice to have a kind of area that allowed harvesting of an
area provided the last resource was not taken.  So harvesting would be
allowed if the resource was 2/5, 3/5, 4/5, or 5/5.  An AI can do this
easily by creating/removing forbidden areas depending on the amount
remaining of a resource, but it is too micromanage-y for a human to be
able to do.  (Or maybe the amount of resource on a location should
affect the probability of it spreading to the next location, so that
there would be benefits from allowing a resource to be higher than
1/5?)

======================================================================
Bugs and possible bugs:

BUG:  In 0.8.22, upgraded buildings will often (always?) get their
assigned workers knocked back down to 1.  If I remember correctly,
this happens for the upgrading, and again when the upgrade is
completed.

BUG?:  Some clearing flags don't seem to ever get assigned workers.
If I delete them and recreate them, then suddenly they start getting
workers.  This might be happening to clearing flags once they pass a
certain age.  It is not really clear.  This issue might be new in
0.8.22, but I'm not really sure about it, because I often had trouble
getting workers to clearing flags in older versions.

BUG?:  If you upgrade a building that will become larger due to the
upgrade, and while waiting for globules to exit the building and the
larger area a resource grows on the larger area, then it seems that
the upgrading is silently canceled!  It seems to me that it would be
much better if the upgrade were not canceled and the building status
indicator showed that it was waiting for the area to be cleared.

BUG?:  The 0.8.22 .tar.gz file didn't have any maps or campaigns in
it.  I used symbolic links to the maps and campaigns from my installed
.deb for 0.8.21.  However, it would be better if users did not need to
install 0.8.21 to use 0.8.22, and if users did not have to figure out
on their own where to put the files.  If not having the maps and
campaigns in the .tar.gz file is desired, then it would be good if
this were at least documented on the Wiki with pointers to a file
containing the maps and campaigns and installation instructions.

BUG?:  0.8.22 seems slower than 0.8.21.  Maybe this is just the issue
with using a lot more memory?  It is not clear.

BUG?:  There are numerous abuse possibilities with building sites!
The most impressive that has occurred to me so far is filling a region
(perhaps the whole map?) with wall sites with the requested workers
set to zero.  You get 1 hit point per location for free!  Nothing can
grow on the location.  You get told when enemy warriors attack your
building sites.  You can get rid of the building sites whenever you
want to move through them (and then recreate them after you pass
through).  If any AI ever used this it would be unbeatable by a human
because it could do it much more effectively than a human.  A weak
partial solution would be to forbid setting the requested workers of a
building site to zero.  Or allow it, but then delete the building site
if the zero workers setting persists for more than a few seconds (in
case the user makes a minor mistake while adjusting things).  Of
course, this is only a partial solution because you could still make
the construction sites in some place inaccessible to your workers to
prevent workers from spending time on them (possibly surrounding the
building sites with forbidden areas to accomplish this).  And it is
still abusive to be able to get a hit point and fill a location at an
arbitrary distance from your other units at no cost.  The only fully
correct solution that I can see is to make building sites that have
not yet had any resources supplied have no real existence: zero hit
points, workers/warriors can walk on them (and enemy units don't even
see them), resources can grow on them, etc.  This would be a larger
change and would obviously take a lot more time to implement.

======================================================================
Globule behavior and gradients:

Globules carrying the same kind of resource (for
constructing/supplying a building) or seeking the same service
(food/healing/training) or seeking to do the same kind of work
(clearing or war/exploration flags with level requirements satisfied
by both globules) that are closer to each others' destinations should
swap destinations.  In addition to the obvious direct benefit of
getting the globules to their destinations more quickly, this would
also reduce traffic jams (which can get quite bad).  I don't know how
to calculate this _both_ efficiently _and_ optimally.  The simplest
way to calculate it is to compare every pair of globules carrying the
same kind of resources.  For each such pair of globs, call them X and
Y, look up X's current location in Y's destination's gradient, and
look up Y's current location in X's destination's gradient.  If X is
closer to Y's destination, and vice versa, then they should swap
destinations.  Unfortunately, comparing all pairs is inefficient
because there will be too many pairs because the number of pairs grows
extremely fast.  To make it efficient would need some heuristic for
deciding on which pairs to actually compare.  Perhaps this heuristic
could focus on regions with bad traffic jams.  Even picking some pairs
randomly to compare (and swap destinations if appropriate) might make
a big improvement in globule performance.  (By the way, a fully
optimal solution to rearranging destinations might in theory have to
consider also triples, quadruples, etc.  That's probably way too
difficult to even consider implementing.)

Obviously, explorers should follow a gradient based on exploring
unknown and/or not-recently-seen locations.  The main difficulty with
this is how to prevent all the explorers from going to the same
destination.  I suggest the following idea.  Calculate some reasonable
gradient for which locations would be good to explore.  (I will
suggest one below.)  Then, for each explorer, make a copy of this
gradient.  Flip the copy (i.e., consider 0 to be high and 255 (or
whatever the highest possible value is) to be low).  Raise the
location of each _other_ currently-exploring (i.e., not seeking
food/healing or assigned to a exploration flag) explorer by some
amount (e.g., 10).  (It is important that we don't do this for the
explorer the gradient is for, because that would be likely to destroy
the information about the unexplored thing that the explorer is
currently "seeking".  The way I propose to do it will lower peaks that
are in some sense "assigned" to _other_ explorers.)  Apply the
gradient algorithm to make the gradient valid again.  Then flip the
resulting gradient (undoing the first flip).  (Flipping doesn't have
to modify the numbers for each location; you just switch which
direction you consider up or down.)  I think this should do a good job
of getting distinct explorers to explore distinct parts of the world.
Comments?  Is my idea any good or does it suck?

A similar idea to what I suggest above for a gradient for explorers
might also be used to avoid danger for any type of globules (including
also explorers).  The exact same idea might not produce the right
results, because it would be important to ensure that destinations
remain peaks, and some danger may be acceptable.  But hopefully,
something could be done that would create something resembling a
proper gradient, which would therefore not have the problem of
globules getting stuck in a loop like some earlier suggestions for
handling danger by using multiple gradients.

Anyway, here is my suggested gradient for explorers (which must be
combined with the above idea to avoid sending all explorers to the
same place).  First, establish as top priority unknown locations that
are distance 2 away from a pair of known adjacent locations which are
of distinct travelabilities (i.e., some globules can travel on one of
the known locations but not the other, for example, a boundary between
sand and water, or a boundary between sand/grass and a resource).
Next priority are any other unknown locations distance 2 away from any
known location, with corners being preferred (i.e., an unknown
location is preferred if it is 2 away from known locations in
directions that are at 90 degree angles, and in opposite directions
are more unknown locations).  Next priority below that (probably _way_
below) are not-recently-seen locations that are 2 away from recently
seen locations.  (In the information recorded about what is not
recently seen, do we know how long it has been since the location has
been seen?)  Simply make a proper gradient after establishing these
priorities.

I think glob2 currently only uses 8-bit gradients.  Some things might
be improved by using gradients that allow more distinct values (e.g.,
maybe the limit to 8 bits is part of the problem with explorers not
being able to find food when far away from home?), but moving to
16-bit gradients would obviously be quite wasteful of space.  I think
that 9-bit gradients could be implemented fairly efficiently, as
follows.  Store the bottom 8 bits for every location the same way as
it is currently done.  Store the top bit for each location in a
separate bit vector (i.e., 8 bits packed in each byte).  I think the
cost of retrieving the value for any location should not be too bad.

Actually, I have no idea how gradients are internally stored in glob2.
It is conceivable that one could take advantage of the fact that
adjacent values in a fully calculated gradient differ by at most one
to store it more efficiently.  This would be mainly useful for
gradients where the cell values are not frequently adjusted in place.
In the most extreme case, one could store just one value at the upper
left of the gradient.  Then the leftmost position in each row other
than the first could be determined by two bits that tell whether they
are the same, higher, or lower than the value in the cell above them.
And then for each cell other than the leftmost in a row there could be
two bits to say how the cell differs from its left neighbor.  This
would take at most 2 bits per location regardless of how many distinct
values the gradient could contain.  To speed up random access to the
gradient, one could store full values every 8 cells or so.  Actually,
when using a gradient to decide where a globule will move, you don't
care what the value of a cell is, merely how it differs from its
neighbors.  This could be efficiently determined if each cell used
four bits to say how it differed from its neighbor on the left and its
neighbor above.  I don't know whether the implementation complications
of any of the ideas I have just mentioned would be worth the space
savings.

Before moving toward a building to feed/heal/train, a globule books a
place in the building.  However, for extreme long distance trips, this
sometimes is wasteful, because it can leave the slot in the building
unused for a long period of time.  It _might_ perhaps be better if
globules sometimes moved toward (one or more) buildings they wanted to
use and did not try to book a place until they were sufficiently
close.  Perhaps this distance could be derived from the estimated time
to arrive and the estimated time for a globule (i.e., some _other_
globule) to get served by the building?

======================================================================
Issues with visual indicators (or their lack):

So I was getting lots of workers starving even though they are near to
inns with lots of spaces and food.  I then realized that this is
because workers don't go to an inn unless it both has an empty place
and (already!) a corresponding item of wheat.  (By the way, it would
be good if this fact were documented.)  Unfortunately, it is hard to
visually inspect the current GUI to see this problem.  If you look at
the white and black dots on the right of the inns, you will see black
spots indicating there are spaces.  If you look at the yellow dots on
the left of inns, you will see wheat.  Maybe the inns are not full of
wheat, but you see wheat.  So you think you are happy.  But you are
not!  You have to _subtract_ the white spots on the right of the inns
from the yellow spots on the left when inspecting the yellow spots,
because what you want to know is how much _uncommitted_ wheat there is
in inns.  A possible solution would be to change the color of dots
corresponding to _committed_ items of wheat, so that one can easily
visually inspect how much uncommitted wheat there is in the inns.

When holding the left mouse button on a building/flag to see what
globules are serving it (does this work for flags? if not it should),
I often can only find some (or even none) of the assigned globules
(unless perhaps there is a bug in the indicated number of assigned
globules).  So I think that when doing this it would be helpful to
move the viewport if that would show more of the assigned globules
together with the building/flag.  In addition, it would help if
off-viewport globule locations were indicated somehow in the mini-map
(maybe flashed?).  Perhaps even everything else should be dimmed so
that the assigned globules can be seen more easily.

Related to the above point, it would be nice if the feature to show
assigned globules were extended to allow also easily seeing which
globules are going to a particular building to get fed/healed/trained.
The distinction could be indicated by using a different color circle.

Further related to the above two points, it would also be nice if one
could ask for the globules assigned to a building/flag to always be
indicated as long as the building/flag was selected.  I'd rather not
have to hold the left mouse button down for this.

The current mini-map is very helpful in that it shows the whole world.
However, it is very small and it is hard to see details, especially on
a 512 by 512 map.  It would be nice to be able to expand the mini-map
(obviously only temporarily) to the whole screen to see more detail.
This would also make it easier to drag the viewport indicator to a
precise location, which is more difficult on larger maps.

It would be better if the Control-Space command told you the kind of
the event whose location it has just moved the viewport to.  Also,
Control-Space should be documented.  (Documenting the behavior of
Control-Space is a bit difficult because it is a bit weird.
Basically, glob2 remembers the most recent location of each of 5 types
of events: globule under attack, building under attack, building
finished, own unit converted to enemy, and enemy unit converted.  The
Space key moves the viewport to the most recent event (regardless of
the kind of event).  Control-Space moves the viewport to the most
recent event of the next kind than the kind of the event of the last
location moved to by either Space or Control-Space.  The "next kind"
is determined in a way that cycles through all of the kinds of
events.)

======================================================================
AIs:

To help understand the AIs, it would be nice if there were an easy way
to watch AIs play against each other as a spectator.  It would also be
nice if it were possible for such a spectator to see the world from
the point of view of each AI.

What does "Numbi" mean in the name "AINumbi"?  Similarly, what does
"Castor" mean?  What does "Nico" mean?  Etc.

Can "AINumbi" please be renamed to "AIPathetic"?  :-)  In my brief
experience, "AINumbi" often dies before it even encounters an enemy.
An AI this pathetic deserves a name that will properly explain to the
player just how weak and hopeless it is.

======================================================================
Map editor interface (comments based on 0.8.22):

It would be helpful to have a control that deletes anything (leaving
only grass, sand, or water), not just things of a specific kind.  A
common need I have for a randomly generated map is to wipe out all
growing things near a starting hive to prevent AI death by overgrowth.

Related to the point just above, the map editor "delete" button only
works on globules and buildings.  It would be less confusing for it to
work on anything that can sensibly be deleted, which includes
resources.

In the map editor, "d" should delete the selected item the same way it
does in the game, for consistency of the interface.  There should also
be a corresponding delete button in the item's status display.  (This
is distinct from the current map editor "delete" button.)

It is confusing that "deleting" sand or water means the same as
"creating" grass.  It seems to me that grass/sand/water shouldn't have
"deletion" as an option, or if this option is allowed and it is
selected then the GUI should switch the selection to "creation" of
grass and flash the new selection to show that is how it is
interpreting "deletion".

"Creating" grass or water on an area that is already that type should
not remove resources on that area.  (I suppose for sand this issue is
irrelevant as there will not already be any resources on sand.)

"Creating" grass/sand/water should never remove globules.  (I suppose
for non-swimming/flying globules creating water under them should ask
whether to delete them or give them basic swimming?)

It would be helpful to be able to drag items around, the way you can
drag flags around in the game.  This feature could even reuse the same
code.  A common need I have for a randomly generated map is to move
the starting hive and workers to a more suitable location (the right
distance from resources to easily access them while avoiding being
immediately swallowed by growth, which is especially important for
not-so-smart AIs).  Right now you have to delete and recreate, which
is tedious (especially if many attributes of the object have been
given non-default values).

In the map editor, it would be nice if the ownership of an item
already on the map could be changed using a radio control in the
item's status display.  Right now, you have to delete an item and
create a new item that is identical except for belonging to a
different player.

======================================================================
Miscellaneous:

The use of the scrollwheel to adjust assigned workers is extremely bad
for people who have a touchpad configured like mine is.  My touchpad
(and the touchpads of many other people) is configured so that a strip
along its right edge acts as the scrollwheel (i.e., like 4th and 5th
mouse buttons).  This means a mistake moving the mouse (really the
touchpad, there is no mouse) can accidentally move the "scrollwheel"
instead.  Because Globulation 2 involves so much mouse movement while
buildings/flags are selected, this means I often accidentally get the
number of workers assigned to some unit completely messed up (often 0
or above 15).  In my case, this means I would really seriously benefit
from being able to turn off the feature that the scrollwheel changes
the number of assigned workers.

What is the difference between "hard pause" (bound to the ScrollLock
key and undocumented (to do: document it)) and "pause" (by default
bound to the p key)?