glob2-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [glob2-devel] Priority


From: Leo Wandersleb
Subject: Re: [glob2-devel] Priority
Date: Mon, 27 Mar 2006 01:34:07 +0200
User-agent: Mozilla Thunderbird 1.0.7 (X11/20050923)

this all looks like micro-management. i don't want to control the order in wich buildings are set up. they should be constructed in a way the union of all ordered buildings gets set up as fast as possible.

Kai Antweiler wrote:
I want a system that is intuitive.
I would like a system that does what I want.
There be shall no need to tell it explicitly what I want.
At least the user should understand why the computer behaves the way
it does - even if he has no experience with computers.
In most cases things like that are hard to implement, but here it is
suggesting.
By constructing buildings in the order in which they get ordered we
could achieve that last point.
But for a really intuitive system we would have to care about the most
frequent special cases:

1. If I order two buildings in very distant locations I would expect
that the globs near the one building work on the one and the globs
near the other work on the other - even though I have ordered one of
them before the other.
Any divergent behaviour would be silly and therefore the fault of the
program - since I (as the user) would never have requested the computer
to do anything silly. ;-)

2. Let's say I have ordered three buildings and recognise that
the second construction site is not as well placed as I thought.
I want to an easy way to destroy this second building and order
a new one with the same  building priority/queue position  as
the one I destroyed.
Maybe after destroying a building we should automaticly go into
"(this kind of) building placement mode".  If the user orders his
first building without leaving this mode, it gets the priority of
the original building.  Further buildings will be handled normally.
The same should be used for: abort upgrading / upgrade.

3. If just one of the resources is not reachable, the user should be told
and the other buildings that have access to all their resources should
be prefered.
(Buildings which can't be finished should get the least workforce.)

4. Buildings that will look like they will be finished soon, might
increase their priority.
(This one might look weird to the user, therefore I'm not sure about
it.)

5. Maybe some work on alliance buildings could be implemented.  These
should get lower priority.

6. Since I prefer a queue system, a playlist kind of queue rearranging
interface might be useful to handle all minor discrepancies.
But I don't think this is necessary.
This would require a way for the user to distinguish between different
buildings of the same kind.  Maybe numbers put on the construction sites.
If this can't be implemented efficiently, it shouldn't be implemented at all.
Furthermore this must not become to powerfull.
An intuitive system which can easily be beaten by micromangement, isn't
worth much - excect for beginners.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]