Periodic "Simulate" or "Tick" event?
by Jason Cahill · in Torque Game Builder · 02/27/2005 (7:02 pm) · 11 replies
It's a pretty well agreed to pattern in game development that you don't want your input handling to directly alter your game state. It makes for easy samples, but it's not really what you want to do "in a real game." Instead, you want your input handling to "figure out what the user wants" and then a "simulate" method that typically gets called once per frame with the "simulation time" to simulate everything and change the game state. I can't figure out how to get a simulate call or a tick call, or whatever from Torque script.
Here's a perfect example:
I have the keys "A" and "D" mapped to playerLeftDown / playerLeftUp, and playerRightDown / playerRightUp. In those functions I figure out, based on all the possibilities, whether the user wants to move left or right (including properly stopping the user if he's holding down both.
Now, what I'd like to do is during my "simulate" call (the one I'd like to figure out how to have call me), I will update the game state and let the user move left or right. The reason this is important, is because if I want to put constraints on how far the user can move left or right (without hitting anything). I don't want to do this when I'm getting the input, because that won't work. I only get callbacks for "key down" and "key up." I need the simulate call so that half way in between a down and up I can clamp the value.
If anyone knows how to do what I'm talking about, I'd really appreciate some guidance. Thanks!
Here's a perfect example:
I have the keys "A" and "D" mapped to playerLeftDown / playerLeftUp, and playerRightDown / playerRightUp. In those functions I figure out, based on all the possibilities, whether the user wants to move left or right (including properly stopping the user if he's holding down both.
Now, what I'd like to do is during my "simulate" call (the one I'd like to figure out how to have call me), I will update the game state and let the user move left or right. The reason this is important, is because if I want to put constraints on how far the user can move left or right (without hitting anything). I don't want to do this when I'm getting the input, because that won't work. I only get callbacks for "key down" and "key up." I need the simulate call so that half way in between a down and up I can clamp the value.
If anyone knows how to do what I'm talking about, I'd really appreciate some guidance. Thanks!
About the author
#2
This works great for functions that want themselves called, but that's not really the case here. I need a different function called very regularly.
As for the part about .setWorldLimit() for constraining movement: That's what I used in my example, so you are absolutely right for solving that problem. But, what about constraining rotation? There's an example where "simulate" could do the constraints handling, because there doesn't seem to be Max and Min rotation constraints.
02/27/2005 (7:20 pm)
Yeah, I'd thought about using schedule, but that seems heavy handed. It seems like Torque must have a "real" concept of a "simulate" callback or a onTime() callback or something that happens on a regular basis. My understanding of schedule is that it schedules a "one-time call" and that's why you always see it as the last line of a function:function foo()
{
do work;
schedule(2000, 0, foo); // call me again in 2 seconds
}This works great for functions that want themselves called, but that's not really the case here. I need a different function called very regularly.
As for the part about .setWorldLimit() for constraining movement: That's what I used in my example, so you are absolutely right for solving that problem. But, what about constraining rotation? There's an example where "simulate" could do the constraints handling, because there doesn't seem to be Max and Min rotation constraints.
#3
02/27/2005 (7:56 pm)
Wouldn't rotation constraints fall under the category of physics? Thus, you might need the capability to have joints and hinges, etc. Maybe I'm confused, though. :)
#4
onUpdateScene()
Is that what I want? Melv / Josh? What are your thoughts on using this?
02/28/2005 (12:26 am)
I think I'm getting closer. The reference docs mention a callback on the SceneGraph:onUpdateScene()
Is that what I want? Melv / Josh? What are your thoughts on using this?
#5
We do not currently support constraints. Yes, they fall under the category of physics but there's only so much in here at the moment, especially as it's only an EA release.
It's easy to constrain the rotations of objects but I've been looking at the best ways to implement stuff like this in such as way as to not cause too much confusion.
One thing to note is that "schedule" is actually very powerful and is lightweight. It's actually pretty simple to setup an abstract function that allows you to setup regular kicks.
- Melv.
02/28/2005 (1:24 am)
@Jason: This function is called every-frame yes. Just be careful what you do in this callback as it's called every frame and you can hurt your frame-rate really easily.We do not currently support constraints. Yes, they fall under the category of physics but there's only so much in here at the moment, especially as it's only an EA release.
It's easy to constrain the rotations of objects but I've been looking at the best ways to implement stuff like this in such as way as to not cause too much confusion.
One thing to note is that "schedule" is actually very powerful and is lightweight. It's actually pretty simple to setup an abstract function that allows you to setup regular kicks.
- Melv.
#6
Re: constraints, Melv and I have both researched this area ***a lot***. Adding even more advanced physics is not the highest thing on the priority list right now, but it's very fun stuff to work on. So, at least for myself, I'll just treat additional physics coding as a bonus / reward for doing a good job on other stuff. Just wanted to let you know that despite both our interest in this kind of code, the physics already rock, and we probably won't be adding more features to the core physics model any time soon.
02/28/2005 (3:49 am)
Jason, you got it, yep. :) Sorry we didn't answer this earlier, but it's helpful to find the answers yourself sometimes too! Good job.Re: constraints, Melv and I have both researched this area ***a lot***. Adding even more advanced physics is not the highest thing on the priority list right now, but it's very fun stuff to work on. So, at least for myself, I'll just treat additional physics coding as a bonus / reward for doing a good job on other stuff. Just wanted to let you know that despite both our interest in this kind of code, the physics already rock, and we probably won't be adding more features to the core physics model any time soon.
#7
02/28/2005 (4:13 am)
Sorry Melv and Josh, I didn't mean to sound like I was pestering you to add more physics. :) I understand that it's EA, so please don't take my having mentioned it as an implicit insult to the current state of the physics. I love this engine, even as an EA release.
#8
02/28/2005 (4:16 am)
Ah no offense at all Jason. And btw, I think you are doing a really great job so far! It's so fun to see people having fun and doing cool things with the engine already! Really, both Melv and I are so flattered and excited.
#9
Do I need to do something else?
02/28/2005 (8:18 am)
OK. Cool. Glad to see I was on the right path. I was monkeying with trying to hook up this callback, but couldn't seem to get it to ever get called. I'm assuming that all I need to do is add:function t2dSceneGraph::onUpdateScene(%this)
{
echo("Heartbeat!");
}Do I need to do something else?
#10
- Melv.
02/28/2005 (9:41 am)
Try...function fxSceneGraph2D::onUpdateScene( %this )
{
echo( %this.getSceneTime() );
}- Melv.
#11
02/28/2005 (11:23 am)
Duh! Thanks Melv. :-) 
Torque Owner David House
schedule( "2000", 0, "myFunction" );
that runs the myFunction routine every 2 seconds. Then in your input functions, just set some variables so you know what the key states are, then do whatever in the myFunction.
One other thing you might want to look into is the .setWorldLimit() function. Its great for limiting how far an object can move on the screen. You can call this more than once ( like if things are changing in your scene and you have to adjust the players boundaries ).
Hope this helps. I'm sure there are other ways to do what you are after as well.