Game world objects on server and client

[Threshold]

Hi,

obviously persisent game world objects on the server need to implement the ManagedObject interface.

The game world objects of my app are the same on client and server (besides that I don't need them persistent on the client).

Should I use the same game world object (as ManagedObject) in my client or is there better solution?

Also how would you replicate the server objects to the client?

Greetings from Vienna

[endolf]

Hi

I share some of my game objects, the way I've done it is to have an interface that is implemented by both the ManagedObject version and the normal client side version, the ManagedObject just delegates to a real object (the one from the client) that it holds a reference too (Java reference, not SGS ManagedReference). The client side object then only needs to extend serializable to be able to store it in the server. By using an interface, I can also treat all the server side objects the same as if they were client side in utility classes, I only have to know when it comes to storing reference to then in other classes that SGS uses.

HTH

Endolf

[tigeba]

I believe the generally accepted approach for this would be an event based system for handling the updates.  Lets say you had a server side object like:

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16   17

SimObject implements ManagedObject, SimEventListener {    private HashMap values;   public String getValue(String name){...}   public void setValue(String name, String value){    //setting values here would generate SimEvents and update the server side model  }   public void event(ClientSimEvent e)   {    // changes to the client proxy would get sent here, where the model  // object in the simulation would get updated if the server decides it is ok, and fire off an update to the client proxy   } }

You might create a client side object that would be something like this

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16   17

[code] SimObjectProxy implements SimListener {    private HashMap values;   public String getValue(String name){...}   public void setValue(String name, String value){     //This would generate an event to the server, the model would be updated there and   // the simulation would send the new value if things were ok  }   public void event(SimEvent e)  {     // This method receives events generated server side and updates your client proxy model } }

The idea is that the server would always validate changes to the simulation side, and that you have the ability to control the amount  and priority of updates that the client receives.  Ideally, the client object and the simulation object would implement the same interface.[/code]

Games published by our own members! Check 'em out!

[Jeff]

In terms of replicating and/or tying the objects together, the Wonderland people have built a distributed object system on top of Darkstar for their use.  You can check their site since Wonderland is an Open Source project.

Be aware though that such a system does *not* deal with the fundamental issues of communciation delays between client and server and how you handle those.

[endolf]

Sorry, I missed 1/2 the question

In terms of sharing the classes, I use a delegate pattern as above, but the actual data is all application dependant. If you do not need high throughput rates (it's all point and click rather than twitch based like an FPS) then you can go even further and like tigeba suggested, create objects that make requests across the network under the covers, which return values as events like tigeba suggests.

If you are in a twitch environment where every millisecond lag counts, then you will need to be a lot more clever, you'll want to use the channels in SGS, broadcast player object updates and update client side cached objects, you'll also need some method to hide (as much as possible) the inevitable network lag.

If you give us some more details about what you are trying to achieve, someone might be able to give you a firmer answer.

HTH

Endolf

[Threshold]

Thanks for your replies!

If you give us some more details about what you are trying to achieve, someone might be able to give you a firmer answer.

OK I have a "Character" class on the server and client that represents the players' characters. It has some attributes (name, skills, experience points, position) which values are changed on the server when the clients sends valid actions. The updates should be replicated to the clients (also to clients that don't "own" a character, if they have a character that "sees" the other)

Can you give a code example on how you would declare the classes in your solution endolf?

tigeba, I understand your solution for replication, except I don't know how the client and server classes' common interface fits in.

If I use a interface, what about the common attributes of the SimObject? Wouldn't it be better to have a base class which stores that data?

1   2   3   4

SimObject extends SimObjectBase implements ManagedObject, SimEventListener {    .. }

Or maybe that's what you (endolf) mean with using a reference to a real object:

1   2   3   4   5

SimObject implements ManagedObject, SimEventListener {    SimObjectBase data;    .. }

[tigeba]

Threshold,

I was kind of thinking along these lines.  The client proxy is truly a stupid object, and does not really know anything about the simulation, and really, probably shouldn't because anyone using your client is gonna have access to it.  The common interface idea was just to present the illusion of using the same set of features for a given object on the client and server.

Lets say you have Player object, it might have an inheritance tree like

SimObject -> Actor -> SimPlayer

And your proxy object might be

ProxyObject -> SimPlayerProxy

SimPlayer and SimPlayerProxy might both implement  Player, which would have stuff that was mostly related to being a player, but would not contain details about the simulation that the client shouldn't know. 

[Jeff]

FWIW this is much like how the Wonderland distributed object system works.  You define matched sets of player/serve objects and fields they share.
When the setter is invoked on one of those fields, it propagates a duplicate setter call to the server and to all the other player instances in other peoples machines.

But the illusion of  "shared objects" only goers so far since not everyone is going to get that setter called simultaneously th\anks to net latencies.

[Threshold]

Thanks tigeba, I think I get it

Jeff, do you mean the lg3d-wonderland project at https://lg3d-wonderland.dev.java.net/ ?
It that's the one, I need to contact them for access to their cvs server (which keeps asking me for a pwd when I try to checkout the source).

[Jeff]

yup thats it

I've got no hand in how they run their community so, yes, you will need to contact them directly.

Cheers

JK

Games published by our own members! Check 'em out!

[karmaGfa]

Jeff, do you mean the lg3d-wonderland project at https://lg3d-wonderland.dev.java.net/ ?
It that's the one, I need to contact them for access to their cvs server (which keeps asking me for a pwd when I try to checkout the source).

I tried 2 minutes ago, and there is no problem getting the sources.
What CVS request you is the login/password of your account on java.net.