Jump to content
  • Advertisement
Sign in to follow this  
hpox

Object-Oriented Networking and MVC

This topic is 4814 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

There's a lot of info on the net about simple straightfoward networking such as sending bytes, strings and numbers, Client to Server. But where's the info about networking in an object-oriented approach? I found some stuff but it's either too vague or too heavy. RPC is ancient, Java RMI seem insecure and CORBA is overhead happy. I just read about these solutions so my opinions are probably inacurate. Is there a way to network programming that is light and OO? I just can't seem to wrap my head around an MVC architecture and the network tools we have: Let's say it's a simple turn-based wargame. My client have a View (GUI) and a Controller. My server is the Model and it have an interface for receiving commands from the controller and have all the domain objects that represent the real-world objects of the game. The View in the client observe the domain objects (which are observable) The client call a method moveArmy(Army, TargetZone) on the Game (server-side), the Game modify the domain objects. Ok, first of all, if the objects are server-side, how can the Client have references to the objects? When the object are modified, they will have to notify the View via the Observer interface. That works perfect in a non-network, but since the View is located on the client, it's a remote object. So the client needs to serve it's View by implementing a Remote Interface or something like that? Last question. Is Object-oriented networking used in games much or is it still procedural with very tight coupling between server and clients? Obviously, the advantage of OO here is that once the network module/architecture is done, programming the game is a breeze and everything is very flexibe/extensible. I should "Just Do It!" and figure it out by making mistakes... If you have any answers, please post. I'll update with info as I figure this out. [Edited by - hpox on June 14, 2005 8:33:21 PM]

Share this post


Link to post
Share on other sites
Advertisement
One view of the world is that everything is objects, and you use (synchronous) method calls to change state. That seems to be what you're looking for, and it really doesn't work that well for real-time distributed simulations.

Another view of the world is that objects in a simulation are state that the simulation evolves on the server, and the role of the clients is to provide input to that evolution, and display the results of the evolution. Implementing that view in an "OO" way typically means that the clients have proxy or ghost instances of the object classes, and there's some protocol that makes sure that user input makes it across, and state divergence makes it across the other way to get displayed. The objects for networking are then actual objects/interfaces that the game objects use explicitly to get the behavior they want, rather than being some "implicit" or "hidden" mechanism.

Of course, the narrower you can make the interface to networking, the better, because it'll be easier to program for your model.

Share this post


Link to post
Share on other sites
Good post, thank you. The first view is what I was looking for yesterday when I posted this thread. The second view is totally in line with what I managed to design on my whiteboard later using my understanding of OO. I wasn't sure about all the "duplicated" domain objects on both the client and the server but with Proxy, it make sense.

What's important here is a solid interface/protocol between the server and client.

Share this post


Link to post
Share on other sites
Quote:
What's important here is a solid interface/protocol between the server and client.


And, specifically, that this protocol is asynchronous (using messaging) rather than synchronous (using method calls).

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!