Game Physics

All matter in this universe follows certain laws of motion. Similarly in a game, these laws can be simulated by the variables to the equation can be changed to add the excite factor to the game.

The physics engine that will be utilized to develop the game is the 3D Game Studio 7’s in build physics library. As such, there will not be a need to use other third-party physics libraries (also called physics engine) such as PhysX, Havok, TrueAxis, Novodex and Ogre.

However, there are several issues that need to be taken care of while working with the physics engine,

• Entities need to be registered as physics objects to enable collision detection
• Only MDL and WMB can be physics objects

Motion & Projectile Physics

Motion revolves around the three Newton’s Laws. Things to observe in moving objects include the inertia, gravitational force and friction.

In real-life situations, objects moving up-hill will require more energy and hence move slower. Similarly, these motion physics will be considered for application to in-game objects that require motion. Below is a simple example that describes such motion through the use of a C-Script that is usable with the 3D Game Studio 7 Engine.

Referenced from Lite-C Workshop 19 physics engine:

ph_setgravity (vector(0, 0, -386)); // set the gravity

phent_settype (ball, PH_RIGID, PH_SPHERE); // set the physics entity type

phent_setmass (ball, 3, PH_SPHERE); // and its mass

phent_setfriction (ball, 80); // set the friction

phent_setdamping (ball, 40, 40); // set the damping

phent_setelasticity (ball, 50, 20); // set the elasticity

phent_addtorqueglobal (ball, ball_speed); // add a torque (an angular force) to the ball

For implementation of projectiles, calculations will be based on Newton’s First Law 1 of Inertia.

Quote from Wikipedia:
“If no net force acts on a particle, then it is possible to select a set of reference frames, called inertial reference frames, observed from which the particle moves without any change in velocity. This law is often simplified into the sentence “An object will stay at rest or continue at a constant velocity unless acted upon by an external unbalanced force”.

Therefore actual realization of the projectile feature will follow the subsequent flow,

Combat Physics

This can also be classified as collision physics. When two physics objects collide, both would have a collision response. Also, a different response will be produced if a physics object collided with a non-physics object. Likewise, different collision response occur no matter which object collides and requires variable adjustment. Shown below is a block of collision response codes that simulate such response.

Referenced from a Lite-C example: Enemy moves back when hit by player with sword

ACTION enemy_dummy {
my.shadow = on;
my.entity_type = 2;
my.enable_scan = on;
WHILE (1) {
IF (my.hit_by_player == 1) {
my.move_x = player.move_x;
my.move_y = player.move_y;
my.move_z = player.move_z;

c_move(my,nullvector,my.move_x,use_aabb | ignore_passable | glide);
IF (player.animblend == blend || player.animblend < attack_a || my.animblend > attack_f) { my.hit_by_player = 0; }
}
IF (player.animblend >= stand && target_enemy == my && player_lock_on == 0) && (player.animblend < attack_a || player.animblend > attack_f) { target_enemy = null; }
IF (target_enemy == my && vec_dist(my.x,player.x) > 200) { target_enemy = null; }
wait(1);
}
}

Damage dealt is calculated differently when a target is hit differently on different parts of its model/mesh.

The damage count will be higher on vital area such as, the head region. This is where 2 hits are enough to dispatch a target regardless of its remaining life points, except for the case of the final boss character.

Hits on non-vital areas will require about 4-5 hits to successfully take down a target with full life points. However, the exact damage roll will be dependant on the “Damage rating” of the weapon being used divided by the target’s armor bonus.

Formula 3:
Life Span = Current Life Span – (Weapon damage / armor)

Shown below is a simple flow of how the combat physics will be implemented.

Sight Physics

The developed AI should have around 160 degrees wide-horizontal of line of sight. Additionally, the visual distance should vary according to the brightness of the scene. Thus when the A.I turns, its visual angle turns together with it and as long as the player falls within this range he will be spotted.

Reference from: http://www.kirupa.com/developer/actionscript/trig_multiple_axis.htm

Formula 1, rotation around x axis
y = Math.cos (angleAroundXAxis)*radius; Angle = 160 degree, Radius equal distance
z = Math.sin (angleAroundXAxis)*radius; Angle = 160 degree, Radius equal distance

Light & Sound Physics

Light can be manipulated by objects so shadows are cast, light is reflected, refracted, diffused, scattered or faded. All these are automatically computed and done in 3D Game Studio when the correct properties are set.

Footstep sounds would allow the player to know if there is an enemy patrolling nearby. A sports car zooming pass the player will have a Doppler effect whereby sound stacks. An effect of water dripping in an empty hallway would produce an echo. All these would require sound physics in play.

To enhance the ambience of an underground military facility, the in-game sounds should be echoed, thus these sound effects will be twice as loud. As such, the respective sound traveling distances are also doubled.

For implementation, the previous formula 1 used in Sight Physics can still be applied in Sound Physics as well, since sound also travels in a sphere-liked vibration.

Formula 2, Sound Distance Traveled
Sound Distance Traveled = Loudness x (Base Distance of 20)

The following shows some common in-game sounds and the respective loudness level.

Sound	Loudness Level
Water puddle	1
Sword hacking	2
Gun firing	5
Opening of door	1.2
Kicked a can	1.5
Running around	1.5

Ragdoll Physics

Some objects have bendable parts. It would be necessary to set up rigid bodies with constrains. Constraint types include the hinge, ball, slider and wheel that have the purpose of restricting abnormal object shape from occurring as well as encouraging the flexibility of object.

The ragdoll physics can be applied to entities that may have been thrown away by an explosion or fallen from a certain height.

Building the skeleton for the object could be challenging. Simulating the movement that goes along with the skeleton could prove even more challenging. Ragdoll physics is not only applicable to the human biped body or the animal multiped body, but also applies to any type of machinery.

However, this can be done by using Verlet integration. This technique uses the connection of arbitrary point between 2 character bone (e.g. knee, elbow) via some simple constraint to simulate the movement of bone joint.

Collision Detection

Examples of two collision systems are Axis Aligned Bounding Box and Oriented Bounding Box. We would use OBB as it is more accurate and it works with any level.

Collision hulls should match the mesh as accurate as possible. Although 3DGS does not provide the exact shaped hull, we still can make use of multiple small hulls to fit the mesh. These are organised using hierarchical bounding volumes like OBB trees.

A problem to take note here is when the object move faster than the frame rate would result in missing frames. Furthermore, it might result a missed collision detection when the two objects overlap over a certain range.

There are different intersection tests for different objects. We would choose the appropriate tests for the appropriate objects. For example when a bullet hits the wall, the plane-ray intersection test is executed.

Here are example codes of collision detection in Lite-C,

Referenced from Lite-C Workshop 18 entity movement:

Moves object in the X and Z axis,
c_move(me, nullvector, vector(15 * time_step, 0, 4 * time_step), GLIDE);

Points and move object towards relative direction with wind resisting in Y axis,
c_move (my, vector(3, 0, 0), vector(0, -1, 0), GLIDE);

Points and move object towards relative direction while pulling object in Z-axis,
c_move (my, vector(5, 0, 0), vector(0, 0, -2), GLIDE);

Points and move object towards relative direction,
c_move (my, vector(15 * time_step, 0, 0), nullvector, GLIDE);

As presented, by executing the c_move instruction, collision detection is automatically in play.