glob2-devel
[Top][All Lists]
Advanced

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

Re: [glob2-devel] Re: hidden forbidden areas for buildings


From: Joe Wells
Subject: Re: [glob2-devel] Re: hidden forbidden areas for buildings
Date: Sat, 13 Oct 2007 01:51:54 +0100
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux)

Leo Wandersleb <address@hidden> writes:

> Joe Wells wrote:
>> See this message for a detailed proposal that also solves many other
>> problems:
>> 
>>   http://lists.gnu.org/archive/html/glob2-devel/2007-04/msg00781.html
>
> i agree on most of what you write

By the way, see also the discussion in the month of May at this URL:

  http://lists.gnu.org/archive/html/glob2-devel/2007-05/msg00009.html

Unfortunately, the mailing list archive splits the thread into two
pieces, one for April and one for May.

> (paving area is missing ;)

You are correct.  I think the idea of paving areas is mostly
orthogonal to my proposal.  If paving areas were added, my proposal
could be easily adjusted to handle them.  But it doesn't need paving
areas.

> it is long. i didn't read it when you first wrote it.

Yes, I know, you wrote that already back in April, and I took your
complaints into account in revising the proposal.

> i don't see much special about your proposal.

I'm curious: What do you mean by that?  Do you not think the 9
separate advantages I list are “special”?

> for example it is
> inconsistent when you first say it would be possible to go from one
> state to any other but then always talk about current state switching
> to be desired state after certain steps.

I'm not sure what you mean by this.  The “states” are CLEARING,
SHOOING, GROUNDBREAKING, CONSTRUCTION, USE, and EMPTYING.  Not all
states can go directly to any other state.  For example, in state
CLEARING (clearing resources for enlarging the building), the next
state will be either SHOOING (telling the workers/warriors to get out
of the way so the building site can be enlarged) or USE (in case
upgrade/repair is canceled).

Do you mean “level” instead of “state”?

> your "state machine" so is neither well documented

I'm not sure what you mean by this.  It seems to me that the state
machine is actually quite precisely documented.  The only way it could
be significantly better documented is if it was running C++ code.

> nore do you tell how one would control such a building.

I haven't specified the user interface.  Suggestions are welcome.

> do i have an inn button with a dropdown to decide on the level of
> the inns to be constructed?

That's a nice idea.  There may be a better interface.  For example,
late in the game, one probably wants any new barracks to be built
immediately to the highest possible level, but it is still useful to
build inns to level 1 initially.  I'm not sure what the best interface
is to make this easy.

> or do i build L1 and can directly upgrade twice?

I imagine for buildings and building sites that there could be a
“desired level” slider with a “confirm construction/repair” button
next to it.  After pressing the “confirm construction/repair” button,
this button would change to “cancel construction/repair”.  (Whether
“construction” or “repair” appeared would depend on whether the
desired level was different from the current level.)

> how do i tell the count of clearers?

Depends on how complicated you want the user interface to be.  My
specification allows the possibility of having the number of workers
depend on the state and level and for this to be changed for each
building.  I'm not sure what the best user interface for this is and
I'm not sure the user interface should allow complete flexibility.  We
could use something like the current settings interface for assigning
the number of workers for construction level L buildings of type B,
but I don't really like that interface.

-- 
Joe




reply via email to

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