|
From: Devlyn D. <de...@ya...> - 2001-09-26 20:56:34
|
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 |