views:

380

answers:

4

I am looking to make a networked board game based on Risk in C++. My idea was to have a central server which hosts a game lobby where users can connect and make/join games. The Observer pattern seems attractive in this case, since I could host all the game model/logic on the server, and the clients would just be observers to this and display the current game state using a view.

My first question: Is this approach possible? Most of what I've heard/thought is that the clients have their own game models. However I'm thinking for a game that's not computationally intensive, a single model hosted by a server would have advantages (no out of sync issues, prevents cheating, etc.).

My second question: How would I go about implementing the Observer pattern over a network? Since I can't make a direct method call over the network, I would need some kind of easy way to simulate this using data. Would there be more advantages using a "pull" (observer requests updates to game data) or "push" (server pushes out new updated data to all clients) approach?

A: 

It seems that you're using the Observer pattern for a dual purpose. You're game clients will be "observing" the server, but that's not all. they'll also be transmitting player information back to the server. So they're really doing more than observing. Maybe just use the basic client/server paradigm and don't worry about the "design pattern". Or, if you want a design patterned approach maybe look at the mediator pattern where the server is the mediator. Personally, I'd stick with client/server approach.

Sorry, I know this doesn't answer you're specific questions, but just take it as food for thought.

nathan
Is this not the case with any GUI though? The GUI gets user input and sends it to the model, but the GUI also acts as a view to the model using the Observer pattern.
MahlerFive
True, some GUIs use the observer pattern to update display state, and use other means to update user information. Some actually use the mediator pattern to separate the UI from the underlying logic.
nathan
+1  A: 

If you really want to do it this way, make your concrete observers also implement the proxy pattern. The proxy deals with sending/receiving data, basically translating a local method call into a remote method call.

Since you're dealing with asynchronous data, you might want to look up a variation of observer called "publish/subscribe". The observations in that are made by the concrete observers listening for events, and then raising events when they need to communicate. Receipt of data, for example, could raise an event.

You could also look into remoting, which is sort of what you're trying to do here. Though it may be a bit too heavy weight for what you're trying to do.

Nathan
A: 

For your first question: Yes, it is a model used by every client-server games.

For your second question: The "push" approach is better in terms of timed synchronization and bandwitch. Use a RPC library (Remote Procedure Call) to simulate the function calls. If you are using C++, I recommend Raknet. If you are using Java, I recommend Jnag or the proto-buffers.

Vincent
A: 

From your problem statement, it seem that you need to implement Distributed Observer Pattern or Distributed Publish / Subscribe. PubSub is a messaging paradigm and can be easily implemented with a MOM (Message Oriented Middleware) - ( see RabbitMQ, ActiveMQ, OpenMQ) where the MOM does the heavy lifting.

XMPP can also serve your purpose right(see XEP-0060). All you need is a Jabber server and a C++ XMPP library (gloox is a good one and supports XEP-0600).

You might also be interested in pubsubhubbub.

agupta666