Game objects in the World Foundry system are free to move about within a three-dimensional world. An object's movement can be controlled in one of the following ways:
The object can be assigned a fixed path. Paths can be created using the Keyframer section of 3D Studio.
The object can be assigned to follow another object.
The object can control its own movement by running a Script.
The object can be controlled by the Physics subsystem of the World Foundry engine. Objects under the control of the Physics system move in response to gravity, drag, surface friction, and other parameters, much like an object in the real world. All of these parameters can be assigned by the game designer on an object-by-object basis.
The Physics system strives to make objects move in a realistic way, including preventing solid objects from passing through each other. It uses information from another subsystem to do this. The Collision subsystem notices whenever two objects collide with each other and reports collisions to other subsystems of the runtime engine. (For example, the Physics system uses collision data to prevent solid objects from moving through each other; Activation Boxes are triggered by collisions with other objects; Room loading and unloading is triggered by checking collisions between Room boxes and the Main Character object; etc.)
To support collision processing, each object created is assigned a Collision Box; this is a rectangular box which completely contains all points and polygons of the object. The Collision system compares the collision boxes of different objects and sends messages to other game subsystems whenever two collision boxes overlap. Because collision processing requires a large number of collision box comparisons for every frame of gameplay, there are a few constraints which are necessary to keep the game's speed acceptable. When comparing collision boxes, the Collision system first checks the Collision Interaction table to eliminate checks between classes of objects which don't physically interact. Also, collision boxes are always "axis aligned", meaning that the sides of the boxes are always perpendicular to the X, Y, and Z axes, even when the object appears to rotate.
Particularly when creating paths, designers should understand the basic way that the Collision system operates: Because video games are by their very nature frame-based, all calculations having to do with motion must be performed in discrete "chunks" of time. When processing collisions for the frame about to be displayed, the collision system must consider not just where every object is now, but also all of the places every object has been since the last frame. (Otherwise, objects could fly right through walls by simply moving fast enough that they completely pass through the wall between one frame and the next.) So, to detect collisions for an object, we take the object's Collision Box and "stretch" it to encompass where the object was last frame, where it's going to be this frame, and all of the volume of space in between.
Because most subsystems of the World Foundry runtime engine run asynchronously with respect to the video refresh rate, the system will degrade gracefully when the number of objects in a level becomes too large to process all of them in one video frame time. (On some systems, all calculations must be performed before the next video frame starts displaying, or the system breaks. World Foundry allows the extra processing to continue, drawing the next frame as soon as it becomes available. This means that the game will always run at the maximum speed that it can, limited by hardware performance and the current processing load.) The upshot of this is that the amount of time which passes between frames can (and under Windows 95, does) vary as the game runs. If a designer places a fast moving object on a circular path, for instance, the object can sweep out a large area in between frames (especially if the level is complex enough to bring the frame rate down). This can cause the collision system to "miss" collisions when the path between "where it was" and "where it's going" is not a straight line. In general use this does not happen, but designers do need to be aware of this particular case.
Controlling Physics Behavior
When an object is under the control of the Physics subsystem, it will behave as if it were a real object in response to external forces acting on it. For example, it will fall in response to gravity until it hits something which blocks its motion; it can move across the floor in response to joystick input, accelerating and decelerating as dictated by the surface friction of the object it rests on, etc. The way that an object responds to these forces is determined by values from its Object Attribute Data, or OADs . All object classes which can be controlled by the Physics system have a Movement page in their OADs, with designer-tunable numbers for all physics behaviors.
This number ranges between 0 and 100, and determines this object's collision priority. When two objects collide, the Physics system looks at this number to decide which object must get out of the other object's way. For example, if a moving block with mass=100 hits a character with mass=50, the block will continue moving on its original course while the character will be pushed away from the collision. (The default value is 75.)
This parameter has two possible values, "Anchored" and "Moveable". If set to Anchored, this object is fixed in place and will not move (this is useful for fixed objects like walls and floors). Note that an Anchored object will never be controlled by the Physics system, making most of the other values on the Movement OAD page irrelevant.
Can Swing From
This parameter can be set to FALSE or TRUE. When set to TRUE, characters will be able to grab this object and swing from it like a pole. (Note: This feature is quite specialized and there are a number of caveats associated with its use. Please see Swinging From Poles for more information.)
At End Of Path
This parameter is for objects which follow a preset path, and controls what the object will do when the end of its path is reached. Possible values are:
Ping-Pong. This will cause the object to move back and forth along the path indefinitely.
Stop. At end of path, the object will stop dead and stay there forever.
Jumpback. This will cause the object to "jump" back to the beginning of its path and continue moving. For example, to make an object move in a continuous circle, a path is constructed with the 3D Studio keyframer. If the beginning point and end point of the path were put in the same location, the object would seem to pause. By leaving out the last keyframe (leaving a gap in the circle) and selecting Jumpback, the object's motion will be smooth and continuous.
Delete. At end of path, the object will delete itself entirely from the world.
Derail. At end of path, the object will switch to physics-based behavior. If the Movement page values are typical, the object will probably just begin falling until it lands somewhere.
Warpback. Much like Jumpback, except that the object will "teleport" from the endpoint back to the beginning without occupying any space in between. For example, say you'd like to create an object which moves across a room over and over again, such that it looks like a stream of objects moving past. If Jumpback were selected, the object would collide with anything that happened to be in the way between the end and beginning of the path. Selecting Warpback prevents this.
This number is a speed, expressed in meters per second, determining how fast the object will move along the path created for it in the 3D Studio keyframer.
Path Initial Keyframe
This number selects the keyframe number (assigned in 3D Studio) to use as the starting point when this object begins moving. (Usually set to 0, for the first frame in the path.)
Object To Follow
This entry is a reference to another object (by name). This object will follow the object named.
This entry is also a reference to another object. This object will follow the object named above (Object To Follow); the position of this object relative to the Follow object will be the same as the offset between the Follow Offset object and the Object To Follow object.
This entry specifies a mailbox number; scripts can write to this mailbox in order to turn this object's movement on and off at any time. (For example, a pathed object can be made to move along its path only when some other condition is true.)
Similar to Movement Mailbox, this entry specifies a mailbox which can be written in order to start and stop the object's animation.
This entry specifies a mailbox which can be used to turn the object's visual representation on and off.
This entry is a coefficient, ranging from 0.0 to 1.0, which determines the object's "slipperiness". A value of 0.0 will give a totally frictionless surface, while 1.0 results in Virtual Velcro. (The default value is 0.95.)
This entry is a value in meters per second squared, which determines how fast the object will fall under the pull of gravity. (Note that this is assignable on a per-object basis, rather than a single number for the entire world.) The default value is 9.8, which is what Earth uses.
This entry is also in meters per second squared, and determines how "hard" the object will jump upwards in response to a Jump input (from a physical joystick or from a script). The default value is 18.0.
Jumping Momentum Transfer
This entry is a coefficient which determines how much of an object's forward momentum will be translated into upward momentum when the object jumps. A value of 0.0 will cause a running jump and a standing jump to have equal height, while a value of 1.0 will cause the object to jump much higher when moving forward. The default is 0.50.
This number is an acceleration, in meters per second squared, that is applied to the object in response to any of the four joystick directional inputs. The default value is 1.0.
This number is similar to Running Acceleration, but is applied when the object receives joystick input and is in the "ducking" position to crawl under another object. The default value is 0.50.
This number is a coefficient which determines how fast an object slows down when the joystick is released. A value of 1.0 will make the object slow to a stop immediately, while 0.0 will make it "skid" for a long distance first. (Note that the Surface Friction of the object this one is resting on has an effect too: No amount of Running Deceleration will stop you from skidding on an icy floor!) The default value is 0.90.
This number is similar to Running Acceleration, but is applied when the object is freely falling through space. Some game designers like to give players the ability to "steer" from side to side while falling (even though this is impossible in real life). If you prefer to leave the player at the mercy of ballistic flight, just set this number to 0.0. The default is 1.0.
Horiz Air Drag
This coefficient determines how much drag the object will experience while flying through the air. A value of 0.0 will really extend the ground distance covered by those running jumps, while 1.0 will turn the air into a thick liquid. The default is 0.25. (Note: Air Drag can be tuned to be different in the horizontal directions vs. the vertical direction; see next entry.)
Vert Air Drag
As with Horiz Air Drag, this number affects drag in the vertical direction. A value of 0.0 will make objects fall freely, while 1.0 will result in an "I've got a parachute" effect. The default is 0.25.
Max Ground Speed
This entry is a speed, in meters per second, which the object will not be allowed to exceed while running across a surface. The default is 10.0.
Max Air Speed
This is the maximum possible speed for this object while moving freely through the air. The default is 10.0.
Fall Anim Threshold
This entry is a speed, in meters per second, which is used for animation control. When the object has a downward velocity that is equal to or greater than this value, the object's FALL animation will be played. The default is 2.0.
This number controls how fast the object turns to face a new direction in response to joystick input. A large number, say 100, will cause the object to "snap" quickly to new joystick directions, while a value of 5 will cause the object to turn more realistically. The default is 5.0.
This number is a speed, in meters per second. If this object collides with another at this speed or greater, the object's STUNNED animation will be played. (For example, you might want to penalize players for running head-first into walls. This number is also applied in the vertical direction, so it can be used to determine how hard a player can fall to the ground before becoming stunned.) Note that if Stun Threshold is set to a value greater than Max Ground Speed, the player will never be able to run into anything hard enough to become stunned; similarly for Max Air Speed. The default value is 2.5.
This number is a time, measured in seconds, which determines how long an object will remain in the STUNNED state after hitting something faster than its Stun Threshold (see above). While stunned, the object will play its STUNNED animation, and will not respond to joystick inputs. The default is 1 second.
This entry is a height, in meters, of the tallest thing that this object can "step over" without slowing down. For example, a player character with a Step Size of 0.25 meters will be able to run up a flight of stairs at full speed, provided that each stair step is less than 0.25 meters tall. An obstacle 0.30 meters tall would block the object (unless it chooses to Jump over, of course). The default value is 0.55 meters.
Moves Between Rooms
This is a TRUE or FALSE value, used to control allocation of texture map memory. Objects which are free to move out of the Room they start in must have this flag set to TRUE; all other objects should select FALSE. (For more information about Room layout, see .)