Leo Wandersleb <[EMAIL PROTECTED]> 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 _______________________________________________ glob2-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/glob2-devel
