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

[Kai Antweiler]

> Here is a suggested state machine for the building life cycle.  This
> proposal solves a number of problems with the previous system:
>
> 1. Clearing is automatically requested for new buildings and upgrades
>    that will make larger buildings, saving the user from the pain of
>    setting clearing areas and flags before starting construction.

Good.


> 2. The user can request direct construction to any desired level
>    without stopping at the intervening levels.

Good.


> 3. This proposal solves the bug where upgrading is silently canceled
>    when resources grow on the larger area needed before all the
>    globules are out of the building and out of the larger area.

Fixing a bug - good.


> 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.
Are you (or your enemy) allowed to build a second building at the same space,
before the first resource arrives?
If yes:
 Which one will be build?  I suggest the building that gets the first
resource first.
 (or a random (synced random) building if both get the resource at
the same time.
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.


> 5. Visually distracting forbidden/guard/clearing areas are removed
>    from the areas occupied by buildings.

OK.


> 6. This proposal has a clean, precise semantics which is likely to
>    lead to fewer bugs (e.g., it would probably have helped avoid the
>    repair crash bug in glob2 version 0.8.22, because the desiredLevel
>    and currentLevel values are tracked separately).

Good.


> 7. In the new system, all of the different levels of a kind of
>    building are now considered to have the same type, whereas in the
>    previous system, they are all different types.  This will make it
>    easier to develop new features.

This is part of 6.


> 8. There is no need to repair before upgrading (is there now?), as the
>    needed amount of resources will be calculated correctly.

There is now.  There upgrade button won't show until the building
has full health.


> 9. Attempts to build on unsuitable territory (which can happen when
>    requesting a building site on undiscovered territory) are properly
>    cleaned up once the unsuitability is discovered.  (In the previous
>    system sometimes a forbidden area is left behind.)

Good.


> This proposal has benefited from comments by Eli Dupree, Leo, Kai, and
> Xylix.

Very good ;-)


> 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?


> 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)?


> 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?


> A new building B starts with B.constructionState = CLEARING, with
> B.currentLevel = 0 (meaning the building does not yet exist), with no
> resources (construction or supply), and with a target level
> B.desiredLevel≥1.

OK.


I skimmed over the rest of your mail and it made sense to me.
Put the concept to our wiki.  Hopefully Bradley finds time to implement
it in a few month.
--
Kai Antweiler