glob2-devel
[Top][All Lists]
Advanced

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

Re: [glob2-devel] proposed state machine for the building life cycle


From: Joe Wells
Subject: Re: [glob2-devel] proposed state machine for the building life cycle
Date: Tue, 01 May 2007 17:33:26 +0100
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)

Thanks very much for your comments, Kai.

"Kai Antweiler" <address@hidden> writes:

>> 4. Abuse of construction sites is impossible, because the building
>>    does not occupy any space until the first resources are supplied.
>
> Fine.  In this case building sites should not be allow to become attack
> targets until the first resource has been delivered.
> And the construction time ban after an attack should also be removed.

Agreed.

> Are you (or your enemy) allowed to build a second building at the same space,
> before the first resource arrives?

Actually, yes.  There is nothing in my proposal which forbids this.

You're even allowed to place building sites on top of known buildings.
If you do so, your bogus building site will immediately disappear when
it hits the check in state CLEARING for “If ... a conflicting building
is found”.

> If yes:
>  Which one will be build?  I suggest the building that gets the first
> resource first.

That is the intention of my proposal.  Looking at it now, I realize
some wording needs to be inserted to make that clear.  I'll clean it
up.

> (or a random (synced random) building if both get the resource at
> the same time.

Right.

> If no:
>  We can prevent the enemy from building buildings, if we scatter the whole
>  map with construction sites.  In this case the enemy should be allowed to
>  attack, and the time ban should stay in glob2.

This won't be necessary, because building sites will not be able to
prevent other building sites.

>> The proposed new system is as follows.
>> 
>> Each building B has several adjustable values associated with it: its
>> type (B.buildingType), its state (B.constructionState), two levels
>> (B.currentLevel and B.desiredLevel), and its number of requested
>> workers (B.requestedWorkers).  During ordinary use, B.currentLevel ==
>> B.desiredLevel.  It is only during the construction/upgrade/repair
>> process that B.currentLevel can differ from B.desiredLevel.  Each
>> building also has two sets of resources: its construction resources
>> (all the resources used so far to build and upgrade it), and its
>> supply resources (the resources gathered for ordinary use of the
>> building).  While in any state, as hitpoints are lost due to damage,
>> the construction resources of the building are reduced appropriately.
>
> I don't know this part of glob2.
> Maybe you need also B.assignedWorkers and B.customer and
> B.requestedConstructionWorkers?

Huh?  I'm sorry, but I don't understand.

>> There is a table Work such that Work(T,S,L) gives the number of
>> workers to use for a building of type T in state S at level L.  (For
>> the state USE (see more on this state below), Work(T,USE,L) should
>> only be non-zero for buildings that need workers to supply them during
>> ordinary use.)
>
> What is the difference to B.requestedWorkers and Work(T,S,L)?

Work(T,S,L) is used to initialize B.requestedWorkers when B moves into
a new state.  But the user should be allowed to adjust this value by
hand after the initial setting.

>> There is a table Area such that Area(T,L) gives the space used by a
>> building of type T at level L.  It must be the case that Area(T,0) is
>> the empty area for every building type T (i.e., zero-level buildings
>> occupy no space).
>
> Amount of space, or a space pattern, or a list of fields on the map?

This is not specified in this proposal.

It probably should be a space pattern relative to the building's center.

> Hopefully Bradley finds time to implement it in a few month.

That would be nice.

-- 
Joe




reply via email to

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