[sfbol-planning] Design issues

[<sfb...@cy...>]

I just wanted to throw this out for discussion.  With this focus on an extendable game engine, should we focus more on that aspect and not design the sfbol portion until it's finished?  Which should be our primary goal?  I totally agree that an  extensible framework would be the best way to go, but maybe, for the first couple iterations, focus on the sfbol gameplay, then revise the design of the server side once we have a better grasp of the general gameplay flow.  On the other hand, there are definite advantages to creating an extensible framework first, completely defining the interfaces to game modules, and building the sfbol portion to fit that.  I can see the benifits to both ideas.  This kind of relates to my next thought.

One design issue that has been somewhat of a stumbling block has been how to structure the client-server relationship.  For sfbol, it seems like a request-reply type setup would work best, with the game server requesting information from the clients at the time required by the sequence of play.  chat would flow freely, of course.  Would this be the best setup for a generic game engine?
Or perhaps the server should be extremely thin, only handling the setup of 'chat rooms' for games, and forwarding any messages to the game modules, letting the game modules do everything else.  In that case, the server could handle different types of games with one instance.  Should the 'bullpen' environment, where people can see what games are running and create and join them, be handled by the server itself, or by game modules?

One thought I had (and these are coming to me as I type, so please bear with the rambling) was that there could be a generic client that would connect to the generic server providing a 'bullpen' environment.  When the user selects a game, or creates a game, of a certain type, the generic client would look for the appropriate jar's for the game, and offer to download them if they are not present.  In a way, this is kinda like the MPlayer service.  Alternatively, there could be a separate client for each type of game and the server would be dedicated to that type of game.  In that case, each game module would be responsible for providing the means to create and join games.  

I'll keep thinking.  Maybe I'll do up some diagrams to help visualize things.

Aaron

-- 
"Great spirits have always found violent opposition from mediocre minds"
Einstein