-------- Message d'origine --------
Objet: Architecture questions
Date: Sun, 28 Apr 2002 14:57:26 +0200
De: Sebastien Marchal <jojo.marchal@...>
I have looked at the code, and I have some concerns about the fact
that we are strongly binding the game to a game play that is not yet
(Do we know this is going to be fun ???). For instance,
- player state is not hidden behind an interface, although it is
simple, we might get into something more complex.
Should we make that an interface, possibly emebedded ?
Soldier class should be an interface also: I can thinck of
soldier plugins with different behavior. This also reduce the
binding of the
soldier implementation with the rest, which could be needed if
we do AI on the side.
For instance, we will have 'toon leader', 'team leader' ...
- 'us' and 'them' (ie: only 2 teams). I don't see much of a limitation
in allowing, at least in the general code, more than 2 teams.
So, we should leave
the door open, even if we don't do it. So we should have 'us' and
'many them' (not necessarly ennemies though). Because this will have
very deep consequence everywhere (like networking code).
- Very complex constructors that can fail big time. A constructor
in an object in an 'unkown' state. And there is really no way
that I know to
pass the failure to the caller without resorting to some
exception system or have
an attribute somewhere that say the object is 'good' or 'bad'
And personnaly; I dont' want to allow any 'bad' object to arrive
Anybody knows how CS handles this in detail (2 stage
- What are the 'tokens' that are part of the thing and affect it ?
This is difficult
to define has this force to finalize the game play ... A token
is anything real
in the game environment. So we definitively have defined
'soldier', 'toon leader',
'bot', 'captain', 'door'. What else ?