naming a function
by rennie moffat · in Torque Game Builder · 09/03/2009 (5:28 pm) · 5 replies
Hi, I am just studying the lovely little code of the cameraMount behaviour (@ bottom), which works great. What I am wondering is about the last line of code, in the ScheduledMount Function. With the following function.
I can not find a a "scheduledMount" function/method in the core of Torque Script. There is a "mount" tho with all the variables as seen attached to the sceneWnidow2D. My question is, how variant can one get with naming a function? For instance could this have been called PlayerCamera(%this), or are both "scheduled" and "mount" crucial to TGB being able to understand the code?
FULL CODE:
function CameraMountBehavior::scheduledMount(%this)
{
echo ("It's on!");
sceneWindow2D.mount(%this.owner, %this.xMount, %this.yMount, %this.mountForce, true);
}I can not find a a "scheduledMount" function/method in the core of Torque Script. There is a "mount" tho with all the variables as seen attached to the sceneWnidow2D. My question is, how variant can one get with naming a function? For instance could this have been called PlayerCamera(%this), or are both "scheduled" and "mount" crucial to TGB being able to understand the code?
FULL CODE:
//-----------------------------------------------------------------------------
// Torque Game Builder
// Copyright (C) GarageGames.com, Inc.
// Camera Mount Behavior
// By Jeremy L. Anderson
// Thanks to Magnus Blikstad and Joe Rossi
//-----------------------------------------------------------------------------
if (!isObject(CameraMountBehavior))
{
%template = new BehaviorTemplate(CameraMountBehavior);
%template.friendlyName = "Mount Camera to This";
%template.behaviorType = "Effects";
%template.description = "Mounts the camera to the current object.";
%template.addBehaviorField(xMount, "X location in target to mount to.", float, 0);
%template.addBehaviorField(yMount, "Y location in target to mount to.", float, 0);
%template.addBehaviorField(mountForce, "Strength of mounting. 0 = rigid", float, 0);
}
function CameraMountBehavior::onAddToScene(%this, %scenegraph)
{
%this.owner.schedule(1000, "scheduledMount");
}
function CameraMountBehavior::scheduledMount(%this)
{
echo ("It's on!");
sceneWindow2D.mount(%this.owner, %this.xMount, %this.yMount, %this.mountForce, true);
}About the author
My thanks to Garage Games and the Garage Games Community combined with owned determination I got one game up, Temple Racer and I am looking to build more interesting, fun games for the mass market of the iOS app store.
#2
I just did not know if a function needed to have some type of core language in it's title.
Thanks!
09/03/2009 (7:24 pm)
yes ok, I just did not know if a function needed to have some type of core language in it's title.
Thanks!
#3
Regards,
Marcus
Placement financier
10/05/2009 (5:01 am)
Hmm. Hope i could help you. I'm also new to the forum so i was digging stuff i could learn from.Regards,
Marcus
Placement financier
#4
That said, IMHO you should choose names that will make immediate sense when you read them, even if six months or a year has passed since you last looked at them. The name should reflect what the function does, not how it does it. The idea is that, when you're writing code that calls your function, you want to be thinking about the new code you're writing, not about the code inside the function.
We (i.e. programmers) refer to this concept as "thinking at different levels of abstraction." It's like looking at different map scales - when you're looking at a global map, you won't see city streets. When you're looking at a city map, you won't see country names. At each level, you're only thinking about what's relevant to that level.
10/05/2009 (10:01 am)
The scheduledMount() method will be called as a result of your own code calling the schedule() method in onAddToScene(). You're the one calling scheduledMount() (albeit indirectly), so technically speaking you can name it just about anything you want. I think it has to be only letters and numbers, and begin with a letter.That said, IMHO you should choose names that will make immediate sense when you read them, even if six months or a year has passed since you last looked at them. The name should reflect what the function does, not how it does it. The idea is that, when you're writing code that calls your function, you want to be thinking about the new code you're writing, not about the code inside the function.
We (i.e. programmers) refer to this concept as "thinking at different levels of abstraction." It's like looking at different map scales - when you're looking at a global map, you won't see city streets. When you're looking at a city map, you won't see country names. At each level, you're only thinking about what's relevant to that level.
#5
10/05/2009 (11:56 am)
Thanks Sherman. I agree and will be going over your post.
Nate Gertsch