Re: [sfbol-planning] Design issues

[Devlyn D. <de...@ya...>]

Well, I think the original inspiration for this
project was to port SFB (that is certainly what
attracted my attention and participation :)  So I
think that whatever we do, we should keep the goal of
porting SFB in mind.  

That being said, I think to get the most 'bang for our
buck' we should build something that is well-defined
for using with other systems.  It might not be a bad
idea to do as you suggest and break the system down
into it's component pieces and see where the game flow
is.  I'm sure we'll find that SFB has many
similarities to other wargames in terms of game flow.

Also, my vote is for a strong server solution, if that
is feasible.  The reason being is that it would seem
to be easier to maintain and it allows for a wider
range of clients.  I imagine our initial client will
have a feel very similar to the pen and paper version.
 But I can also imagine a day when someone creates a
really cool open-gl client with 3D ships for either
SFB or another game.  As long as we have a
well-defined communication protocol we should be able
to have many types of clients and in different
languages.

The request-reply system you mentioned for the server
sounds reasonable.  In fact, that sounds like it would
work for other games as well.  Let's face it, every
game is going to have some sort of Sequence Of Play,
it just happens that SFB has very extensive SOP. 
Maybe for the generic engine there should be a hook to
load the game-specific SOP module.  The server would
then load the SOP module and get it's timing and
request-reply system from the module.  Whatever is in
the SOP module will be the backbone for the game.  

-Dev




--- sfb...@cy... wrote:
> 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
> 
> 
> _______________________________________________
> sfbol-planning mailing list
> sfb...@li...
>
http://lists.sourceforge.net/lists/listinfo/sfbol-planning



__________________________________________________
Do You Yahoo!?
Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger. http://im.yahoo.com