Thread: [Opentnl-general] Server vs Client objects
Brought to you by:
mark_frohnmayer,
s_alanet
From: boB G. <boB@Gage.net> - 2005-05-23 12:00:29
|
I'm having some issues with ghosted objects. In all the examples a world object, say a Player class that has TNL::NetObject at the base of its inheritance tree, has the same object on both server & client sides, meaning that the client has local methods that do server operations and vice-versa. This results in a lot of methods of the form { if (isServer) { ... } else { ... } } Since we have separate teams developing server and client code it also means that both teams are inside the same files a lot, leading to a lot more CVS conflicts than "normal." ( whatever that is :) It would be preferable for us to have TNL play with abstract classes, with each application defining a final descendant, including all server|client-specific code at that level. By default, TNL appears to require the same object on both sides of the connection, but is there a way to allow each application to have their own class that TNL plays with as the parent class?? ( much like the masterserver example uses an 'interface' class that each side descends it's own connection class from ). Or did I have something completely different going on when I decided we couldn't define both ServerGame and ClientGame descended from a common Game object that TNL does all its magic on? :-) Thanks in advance! boB |
From: Mark F. <ma...@ga...> - 2005-05-23 14:38:00
|
It would be possible to have Player PlayerServer PlayerClient If the client executable does a TNL_IMPLEMENT_NETOBJECT of the PlayerClient class and the server does a TNL_IMPLEMENT_NETOBJECT of the PlayerServer class, then ghosts of PlayerServer objects will be constructed on the client as PlayerClient objects. This is NOT recommended - it merely takes advantage of the knowledge that all class names are sorted alphabetically in order to generate mapping ids. You could also have a class named Player in the client executable, and one in the server and just have different definitions for each class. boB Gage wrote: > I'm having some issues with ghosted objects. In all the examples a > world object, say a Player class that has TNL::NetObject at the base > of its inheritance tree, has the same object on both server & client > sides, meaning that the client has local methods that do server > operations and vice-versa. > > This results in a lot of methods of the form { if (isServer) { ... } > else { ... } } Since we have separate teams developing server and > client code it also means that both teams are inside the same files a > lot, leading to a lot more CVS conflicts than "normal." ( whatever > that is :) It would be preferable for us to have TNL play with > abstract classes, with each application defining a final descendant, > including all server|client-specific code at that level. > > By default, TNL appears to require the same object on both sides of > the connection, but is there a way to allow each application to have > their own class that TNL plays with as the parent class?? ( much like > the masterserver example uses an 'interface' class that each side > descends it's own connection class from ). > > Or did I have something completely different going on when I decided > we couldn't define both ServerGame and ClientGame descended from a > common Game object that TNL does all its magic on? :-) > > > Thanks in advance! > boB > > > > ------------------------------------------------------- > This SF.Net email is sponsored by Oracle Space Sweepstakes > Want to be the first software developer in space? > Enter now for the Oracle Space Sweepstakes! > http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click > _______________________________________________ > Opentnl-general mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opentnl-general |