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 > [email protected] > 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.
_______________________________________________ glob2-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/glob2-devel
