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

[Joe Wells]

Kai Antweiler <address@hidden> writes:

> I reply only to some points.

Me too, I won't reply to all your replies.

>> The documentation (this is mainly the Wiki pages) inconsistently uses
>> "globuls", "globules", "globs", and "units".  It would be better to
>> use just one of these words throughout to reduce user confusion.
>
> True.  The usability guys said something similar last year - about
> the tutorial I think.
> I prefer "units".  But "globs" is good too.

If there were a definite decision by the group of the preferred
official term, then someone could implement the changes.

>> I've seen mentions of the "fog of war" option on the Wiki, but I can't
>> find any place to turn this option on or off.  Help?
>> 
>> I have seen a mention of a "discovery" option.  What is this?
>
> Do you mean our todo page?
> http://www.globulation2.org/wiki/Todo

I don't remember where I saw this (wiki, forums, or mailing list
archives).  What I saw gave me the impression that the writer was
stating the option existed.

> Well, to answer your question  for of war is always on.

Thanks!  That solves my confusion.

> And I don't know of any discovery option.

Okay.

>> Overall, it
>> seems that it could be much better for human players to be based on an
>> AI with human intervention at key points.
>
> Yes!  I think I proposed this a couple of times.
> This is my absolute favorite glob2 wish.
> Finally someone who agrees with me.

Well, the idea is to reduce the micromanagement.  The individual
globules are fully AI-driven, but one still must fiddle with the
placement and settings of numerous buildings, flags, and areas.

Apparently one can already today get part of the effect of this by
allying with an AI.  But how do you do it properly?  The idea would be
to start with just one hive shared between the human and the AI, as
though they were really just one player.  It would be nice if there
were clear instructions on how to do this and/or a nice interface to
request this to be set up.  And it would be nice if there was some way
to tell the AI not to make certain choices or interfere with some
things.

>> (simultaneously with all other displays).  This could be done by
>> adding another column at the right for the graphs.
>
> I would like different movable windows as in freeciv, that you can
> place wherever you like.

There is support for this in either Qt or some additional toolkit that
KDE has built on top of it.  A nice example is the Gwenview image
viewer, which allows you to rearrange its panes fairly arbitrarily.
You can make any pane an independent window if you want, or you can
dock them in the main window in arbitrary tiled arrangements.  You can
stack several panes in the same location in which case they
automatically get tabs to switch between them.  Apparently Gwenview
merely uses some toolkit features to implement the vast majority of
this.

I think GTK+ used to have some support for at least some of this kind
of thing, but I think that support was either removed or deprecated
(and hence may be becoming buggy) due to the GNOME project's emphasis
on good defaults and simplicity over configurability.

So if one were to switch to either Qt or GTK+, this might be an
argument in favor of Qt.

>> It would be nice if there were also graphs for the percentage of
>> globules at each skill level.
>
> Maybe we could allow the user to decide what statistics he wants to
> see in that little space.

That would be nice, but my (unclearly stated) point is that currently
only about half of the space in the graph pane is used so there is
room for one or two more graphs.

>> When a globule's destination changes (e.g., because something has been
>> forbidden or used up), the old path continues to be shown on the
>> screen.
>
> The shown pathes are just a hack.  We don't know the pathes when a glob
> starts working.  We just know how the glob can get closer to his aim
> in this turn.  I think we have to live with that, partly because of
> cpu resources, but also because of changing environment and traffic.

Well, my (unclearly stated) point is that the destination being shown is
often wrong.  I understand that any straight lines won't generally be
able to show the actual direction the globule will go next.

>> It would be nice to be able to have buildings be automatically
>> upgraded to the next level as soon as there were enough workers with
>> the skills to upgrade it.
>
> One worker is enough.

True.  My (unclearly stated) point is that one might want to wait for
a number of workers.  This is especially the case if the building to
be upgraded is the only school.  You usually wouldn't want to start
upgrading it to the next level with only one qualified worker.  :-)

>> It would be nice if starting or upgrading a building would
>> automatically place a clearing area for the needed space, instead of
>> forcing one to do this by hand.  Right now one can not pick a building
>> site or ask for a building to be upgraded until all resources are
>> cleared from the necessary area.
>
> Yes, Leo thought about this.  This would be really nice.
> But not with clearing area, because they perform poorly - or have they
> improved?

No, the clearing areas haven't improved.  :-(

However, clearing areas together with clearing flags work better than
either alone.  The clearing flag will summon the workers, and the
clearing area will help get the shape right and compensate for the
circularity of the region covered by the flag.  Once workers have
arrived due to the flag, they will usually bump into the locations
covered by the clearing areas even if they are not covered by the
circular region.  This allows avoiding to make the flag circle too big
or needing to make multiple small flag circles.  Workers also seem to
prefer clearing the locations in clearing areas over other locations
in the circle of the clearing flag.

>> There are many difficulties when using the checkerboard pattern for
>> making forbidden areas for farming.  Placing the pattern correctly is
>> quite delicate.  If one accidentally uses the pattern one location
>> away from where one should, the pattern gets completely messed up and
>> one has to make several mouse trips to the right area selecting
>> different tool options to clean up the mistake.  What would be better
>> would be to use solid patterns but have an option that caused turning
>> the area _on_ for locations whose x and y coordinates summed to an odd
>> number and _off_ otherwise.  Then one would could quickly drag the
>> tool across a large area to set up the checkerboard pattern.
>
> True.  So when we place one pattern next to another one it will not
> stupidly be set, but set aligned to the former - ensured by differencing
> between even and odd fields.

Right.  I have often started two separate checkerboard patterns that
eventually grow to meet as the farms grow and at the boundary half of
the time they don't meet correctly.

> We should do it.

Hurray!

>> I need an area that means "clear this if it is forest, protect this if
>> it is wheat".  Otherwise I spend too much time micromanaging the
>> areas.
>
> User set area traits.  Ok.  We have enough colors.

I'm not sure what the user interface would look like.  I basically
want all of the settings I can make with clearing flags, but combined
with the ability of areas to specify the precise region easily.

>> It would be nice to have clearing areas/flags which made their
>> resources preferred for building purposes rather than caused the
>> resources to be chopped down and thrown away.
>
> No, this sound like micromanagement.  The globs should know which
> resources they want.

Well, my (unclearly stated) point is that it would be nice if when
globules needed a tree, they would be willing to go a bit further to
chop down a tree from a clearing area, and when a globule chops down a
tree in a clearing area, it would be nice if the globule tried to find
a place that needed a tree before discarding it.  What I am imagining
is a kind of clearing area where the speed of clearing is not as
important as using the resources well.

Anyway, this idea is less important because it seems relatively rare
for resources to be so tight that one can't afford to simply slash and
burn Brazilian rain forest style.  :-)  Not an ecologically good
message, but when you're out for world domination these things are
less important.  :-)

>> When a building is set to X workers, and X is more than the number of
>> resources needed to finish construction/repair/upgrading, then it
>> seems that some worker effort and resources often ends up wasted.  It
>> is very tedious to have to micromanage the number of workers assigned
>> to a building as the building nears completion to keep this from
>> happening.  It seems like it ought to be possible to auto-reduce the
>> number of workers assigned to a construction site so that the number
>> of workers is limited by the amount of resources still needed for the
>> construction.
>
> I think our goal is to not having to tell a building how many workers
> it should use for construction, but to give it a priority value so that
> it can negotiate this with the other buildings.

Well, my (unclearly stated) point is that for high priority buildings,
one is willing to waste some resources and (more importantly) globule
effort/time, but for low priority buildings it is better not to waste
globules' time bringing resources that will then end up being
discarded.  Right now, one can do this by micromanaging the number of
assigned workers, but I don't want to micromanage at that level.  I
just want to say whether it is more important to finish the building
quickly or more important to not waste workers' time.

>> BUG:  If the disk is full, glob2 will happily save a game as an empty
>> file on the disk without warning the user at all that the saving
>> failed.
>
> One note:  I think there is no stable defragmentation for any unix
>            filesystem.  You must always leave enough space free or
>            your filesystem gets heavily fragmented.

By the way, I've never experienced the amount of fragmentation of my
disk on any Unix computer to have any significant effect on my usage
at all.  There are good reasons for keeping some spare disk space
(e.g., being able to get complete glob2 core dumps!), but I don't
think avoiding fragmentation is a strong reason.

>> glob2 (version 0.8.22) uses 1.2 gigabytes of memory just to edit a 512
>> by 512 map!
>
> Is this with cached memory, or only what is really used.
> Try to use the "free" command to estimate how much is really used.

The virtual memory used is about 1.6 gigabytes.  Shortly after loading
the map it reports around 1.2 gigabytes resident, which I assume means
that other programs running on the machine needed to quickly reclaim
about 0.4 gigabytes just to keep running.  Basically everything else
on my machine gets paged or swapped out during the process of loading
the map, which takes quite some time.

In comparison, glob2 version 0.8.21 uses about 80 megabytes virtual
memory and about 60 megabytes resident memory to edit a 512 by 512
map.  This is a memory usage increase of about a factor of 20.  The
difference shows in that it takes just a couple of seconds to load a
512 by 512 map with the older version, but up to a minute for the
latest version.

By the way, glob2 version 0.8.21 can't see any maps I've created with
glob2 version 0.8.22, and glob2 version 0.8.22 can't see any maps I've
created with glob2 versions 0.8.21 or 0.8.16.  The maps simply don't
show up in the list of available maps for editing or playing.  glob2
version 0.8.22 seems to have no trouble seeing the maps that came with
the 0.8.21 .deb, because those are the ones I'm using now.  It's just
the randomly generated maps that I created that seem incompatible.
Are they supposed to work across versions 0.8.16, 0.8.21, and/or
0.8.22?

-- 
Joe