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

[donkyhotay]

On Sat, 2007-04-07 at 08:15 +0100, Joe Wells wrote:
> 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.
the game allows for preset worker values. Check within settings and make
certain that all your buildings are just set to 1
> 
> 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)?
> 
> 
> _______________________________________________
> glob2-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/glob2-devel
-- 
Do not be afraid to joust a giant just because some people insist on
believing in windmills.