[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [glob2-devel] additional feedback on Globulation 2 (long, with many
Re: [glob2-devel] additional feedback on Globulation 2 (long, with many topics)
Sat, 07 Apr 2007 09:38:09 -0700
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.
> 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
> 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
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
> 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
> 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
> 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
> 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.
> 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
Do not be afraid to joust a giant just because some people insist on
believing in windmills.