Server/Client Confusion
by Robert Blanchet Jr. · in Torque Game Engine · 02/05/2003 (5:20 pm) · 3 replies
I'm in the process of developing a sensor network type class which is responsible for maintaining a series of lists which contain clients. These lists are in special groupings, such as by team, by sensor visibility and so forth.
As part of the anti-cheating measures I'm taking, I've been looking into ways of preventing complete access to these various lists from the clients.
Part of the way to do this was I was going to make the Sensor Network class completely server side and create a client side manager class which would recieve what the client can see from the Sensor Network class.
My question is, I don't understand how the engine is specifying what classes are server side, client side, or both. I've traced through the code and I'm well aware of the calls to isServerObject() and isClientObject() which do seem to clear up the issue a bit however one problem that keeps haunting me is the following code and code related to it:
What seems to be happening here is the engine is instanciating two of everything, one for the client, and one for the server, and true and false is telling the constructors whether its a client or server object.
What I'm mostly confused about is why it's done this way. To me it would seem that if the engine is in the process of creating the server, then instanciating a client scene graph and a client scene root is unneccessary and wasteful, especially since it appears that these two objects are never freed at any point during the time the server is running.
So I'm still left back at square one regarding my original question. How can I make sure my class is server side only, and that the client isn't instanciating a copy of the object even though the client would never use the object? Worse yet, how do I know the client isn't duplicating the data through the object that should be server only?
As part of the anti-cheating measures I'm taking, I've been looking into ways of preventing complete access to these various lists from the clients.
Part of the way to do this was I was going to make the Sensor Network class completely server side and create a client side manager class which would recieve what the client can see from the Sensor Network class.
My question is, I don't understand how the engine is specifying what classes are server side, client side, or both. I've traced through the code and I'm well aware of the calls to isServerObject() and isClientObject() which do seem to clear up the issue a bit however one problem that keeps haunting me is the following code and code related to it:
gClientSceneGraph = new SceneGraph(true); gClientSceneRoot = new SceneRoot; gClientSceneGraph->addObjectToScene(gClientSceneRoot); gServerSceneGraph = new SceneGraph(false); gServerSceneRoot = new SceneRoot; gServerSceneGraph->addObjectToScene(gServerSceneRoot);
What seems to be happening here is the engine is instanciating two of everything, one for the client, and one for the server, and true and false is telling the constructors whether its a client or server object.
What I'm mostly confused about is why it's done this way. To me it would seem that if the engine is in the process of creating the server, then instanciating a client scene graph and a client scene root is unneccessary and wasteful, especially since it appears that these two objects are never freed at any point during the time the server is running.
So I'm still left back at square one regarding my original question. How can I make sure my class is server side only, and that the client isn't instanciating a copy of the object even though the client would never use the object? Worse yet, how do I know the client isn't duplicating the data through the object that should be server only?
#2
You could also could check to see if a server connection exists when the object is created, but T2 sensor objects took the first approach.
02/05/2003 (9:30 pm)
Most objects don't care if they are being run on the client or the server. In your case, the thing to do would be to hard code your sensor object to always run it's queries on the gServerSceneGraph. If someone creates a sensor object on the client it doesn't do them any good as the server scene graph is empty on the clients.You could also could check to see if a server connection exists when the object is created, but T2 sensor objects took the first approach.
#3
I think you mis-intrepreted what I was trying to achieve with the Sensor object. I'm not trying to determine whats visible and whats not on a object bases and sending that information to clients. I'm trying to establish whats visible and what is not visible on more abstract terms, in the case of the game I'm developing those terms are what team is every player on and whether or not to draw a friend or foe indicator over their heads. Fairly simple actually. I'm just trying to make sure that it is done in a manner that hides information from the client that the client shouldn't know.
Tim,
Thanks for the reply. It makes a little more sense now that I think about it after being away from it for awhile. I think what confused me the most was the fact that both server and client scene graphs were being created even though the user is just a server or just a client.
02/05/2003 (10:33 pm)
Jarrod,I think you mis-intrepreted what I was trying to achieve with the Sensor object. I'm not trying to determine whats visible and whats not on a object bases and sending that information to clients. I'm trying to establish whats visible and what is not visible on more abstract terms, in the case of the game I'm developing those terms are what team is every player on and whether or not to draw a friend or foe indicator over their heads. Fairly simple actually. I'm just trying to make sure that it is done in a manner that hides information from the client that the client shouldn't know.
Tim,
Thanks for the reply. It makes a little more sense now that I think about it after being away from it for awhile. I think what confused me the most was the fact that both server and client scene graphs were being created even though the user is just a server or just a client.
Torque Owner Jarrod Roberson
You might want to dig thru the code a little more and think thru this a little more.
Think about the scenario where another player is stepping back and forth from behind a wall. It would be wastefull to try and have the server create and destroy the clients ghost object on every frame where the object became obscured.
Just think about a player looking around really fast . . . the network traffic is going to be ridiculous if the client has to rely on the server to do all the visiblity tests. And the server will have to be doing the work of every connected computer, it gets unmanageable and unrealistic really quickly.
What you are trying to do breaks the law that says "pre-mature optomization is the root of all evil".
Tribes2 has proven pretty hack proof, and if you are LUCKY enough for your game to get more popular than Tribes2 AND popular enough to attract the real hard core hackers that will try and create cheats, deal with it at that time rather than spending valuable development time trying to code around something that might never happen.