Variable Ghosting Distance
by James Lupiani · in Torque Game Engine · 07/03/2003 (10:04 pm) · 3 replies
First off, my goal is to allow GameBase-derived objects in my game have different levels of emission and detection for my sensor system. Ideally I'd like to alter the distance at which other objects detect a given target, so that some may be stealthier than others.
My current sensor system is client-side, and is based on searching through the ServerConnection group for ghosted items of interest. To simplify things and reduce the chances of cheating, what I thought I'd do is alter the ghosting distance. After some experimentation, I discovered the simplest way to do this was change the visibleDistance property of the map. However, that won't work in the end, especially with terrain. I'd like the sensors to detect things beyond the visual threshhold, and at different distances. Based on some experimentation I did a few months ago, I think I can change this property on a per-object basis in ::onCameraScopeQuery (in ShapeBase for instance). What I keep getting confused about is the perspective of this function. Is it called when the engine wants to see if the object being called is visible from the point of a given camera, or is it when the engine wants to determine how far the object can see?
If it's the former, I suspect I should be able to change this so that the object is only updated/detected by another when it's within the query's visibleDistance--i.e. the target controls its detection threshhold. If it's the latter, the object sensing controls the detection threshhold.
And finally, does anyone see any glaring oversights on my part?
My current sensor system is client-side, and is based on searching through the ServerConnection group for ghosted items of interest. To simplify things and reduce the chances of cheating, what I thought I'd do is alter the ghosting distance. After some experimentation, I discovered the simplest way to do this was change the visibleDistance property of the map. However, that won't work in the end, especially with terrain. I'd like the sensors to detect things beyond the visual threshhold, and at different distances. Based on some experimentation I did a few months ago, I think I can change this property on a per-object basis in ::onCameraScopeQuery (in ShapeBase for instance). What I keep getting confused about is the perspective of this function. Is it called when the engine wants to see if the object being called is visible from the point of a given camera, or is it when the engine wants to determine how far the object can see?
If it's the former, I suspect I should be able to change this so that the object is only updated/detected by another when it's within the query's visibleDistance--i.e. the target controls its detection threshhold. If it's the latter, the object sensing controls the detection threshhold.
And finally, does anyone see any glaring oversights on my part?
About the author
Programmer for Sickhead Games
#2
07/04/2003 (12:50 pm)
Just a word of caution. This won't reduce cheating, especially if someone knows or has access to the engine source. Setting up a simple SimSetIterator will allow someone to iterate through all objects in the scene graph, scope out the PlayerObjects, and allow them to get the information about every client in the game, regardless if they are in the scene or not.
#3
Robert: I'm not quite sure what you're getting at. My point with cheating was to ensure that the server is always the authority on whether an object is visible or not, rather than the client simply ignoring ghosted objects outside its range. Judging by the docs and source, the scoping process is done on the server side (gServerContainer) where a NetConnection exists for each client. The ServerConnection group on the client side is only updated with objects the server chooses to ghost to it. When they're out of range, the ghosts are removed from the ServerConnection unless they're set GhostAlways. If the client were hacked, they still wouldn't have authority over the server as to what objects are in scope. Right?
07/04/2003 (2:17 pm)
Ben: That's a good point/idea. I'll take a look and see how well it works.Robert: I'm not quite sure what you're getting at. My point with cheating was to ensure that the server is always the authority on whether an object is visible or not, rather than the client simply ignoring ghosted objects outside its range. Judging by the docs and source, the scoping process is done on the server side (gServerContainer) where a NetConnection exists for each client. The ServerConnection group on the client side is only updated with objects the server chooses to ghost to it. When they're out of range, the ghosts are removed from the ServerConnection unless they're set GhostAlways. If the client were hacked, they still wouldn't have authority over the server as to what objects are in scope. Right?
Associate Ben Garney