Clamp player inside the bounds of a moving camera?

#1 Set its world limit behavior to clamp would be the easiest I think. That way the player object can not leave the world limit.
If you set that to the viewable area (can be done in the editor), you should get the expected behavior.

#2

Quote:
Set its world limit behavior to clamp would be the easiest I think. That way the player object can not leave the world limit.
If you set that to the viewable area (can be done in the editor), you should get the expected behavior.

Actually, that won't work, because the world limits are based on the origin of your scene (a static point), and he wants the player to stay within a fixed distance from a moving point (the camera).

I'd simply do a distance check from the player's position to the camera position each update, and make sure it remains within the fixed distance. At that point you can either force the player to "scoot closer", penalize him, or whatever your game mechanics dictate.

#3 We've also done this by modifying the world limits of the player by the camera area whenever the camera moves. Worked like a charm. :)

#4 I wanted to clarify--the world limit is based upon a static point, not necessarily the scene origin. However, there isn't a built in mechanism for it to auto-update, you would have to do it yourself, like Thomas mentions.

From a performance perspective, it's probably just slightly faster to tie the world limits to the camera instead of doing a script based distance check, unless your camera is -constantly- moving to an extent that the world limits would change every single frame--in that case it's probably very equal.

#5 I'm looking at world limits that actually change quite a lot. The camera is either moving or not moving, plus it can be at different levels of zoom (remember Samurai Showdown, how the camera would zoom in and out? Like that). So literally, the player needs to be always clamped inside the 'viewable area' of the live camera. (Except, of course, for cinematic sequences, where the camera is viewing something else that is off the screen where the player is located).

#6 I'd go with the world limits check. It's much easier and much more efficient, even if you're doing it every tick. It would amount to reading and assigning a couple values, versus explicitly calculating and resolving penetration and then modifying velocity dynamically based on however the character was moving at the time.

#7 I seem to recall hearing that Torque engines all have some flakey problems when doing very frequent schedules / checks on a script-level per tick. Is this something you guys would reccommend I do engine level ONLY, or something I could just do from script?)

(Then again... is it even possible to have something occur per-tick on the script level? I thought that only the engine really had access to the ticks...)

#8 There is a callback to your scenegraph every tick that you can hook into and distribute ticks to your objects if you need a per-tick update. Name your scenegraph in the level builder and then set up a function on that namespace called onUpdateScene. That function will be called every tick.

If there is inherent flakyness in doing script updates every tick, I haven't heard of or experienced it. Out of curiosity, where did you get this information?

#9 Heck, I honestly couldn't tell ya, Thomas. I've been working with Torque for so long and asked so many scripting related questions... I just remember it popped up a couple of times in the past in responses I was given.

onUpdateScene... good information! Thank you very much, I'll make use of that!

#10 Cool. I wasn't ruling out the possibility. If you run into anything like that please let us know.