Projectiles

It seems tumblr delete 3 of the 4 posts to your projectiles script.

I’ve noticed that when using physically simulated projectiles, frame skipping tends to occur, in which the projectile will be in front of the object for one frame, then behind it for the next frame, thus no collision has actually happened. Games like CoD use Rays to project from the gun, then do collision at the point of damage, which is a great effect to use in small map games. Whereas games like Battlefield in which the maps are large and Time On Target as well as gravity become an issue to players, they slow the bullet down substantially, which eliminates frame skipping, but makes the game slightly unrealistic. I propose having physically simulated projectiles where gravity and Time On Target are present, but have them project a Ray in front, about the same distance between the points of the projectile in each frame, so if anything comes in contact with it between frames, the bullet can do it’s damage, then add a bullet destruction effect at the point of contact with the Ray. Physically simulated bullets, minus the frame skipping.

Movement System Explaination (8/???)

The way I handled adherence to a surface was pretty simple:

  • If the player is moving along a level plane or up a slope, the player simply follows the slope.
  • If the player is moving down a slope, the Z-displacement is replaced with a maximum incline.

There is a flag which determines if the Z-displacement is overwritten: this is to prevent “hopping,” when the slope-sensing ray detects a shallow incline before the player is actually touching it. The flag is unset when going up a slope and when the player is seen to be touching a level slope: the latter case is determined by the angle and distance of the slope-sensing ray. The length of the ray must be half the height of the player object, and the surface must be level.

Running over something like the top of a steep roof isn’t likely to go as expected. Player’s do a small hop, when going uphill to a level or downward slope. Since the system requires physical touching to work, the “ramp”-effect will most likely cause a player to fall alongside a ramp rather than travel down it (at higher speeds, anyway).

By the way, the maximum incline was determined by the following steps:

  1. Make a vector of (1, 0, -1), which is a 45-degree slope.
  2. Normalize it.
  3. Take the Z-value, and multiply it by whatever speed being applied.

Movement System Explaination (3/???)

It should probably be stated that lateral and vertical movement are entirely separate from each other. The most they intersect is when the horizontal displacement is shifted to align with a plain.

Oh! On that note: it’s best to use a capsule instead of a cone because the dull bottom allows a slope to be detected before moving off a precipice. If a cone was used, there’d have to be a safeguard put in place to make sure the player didn’t go flying off the top of hills on account of registering as airborne.

Just thought you ought to know all that.

Movement System Explaination (1/???)

Okay, see this?

image

Don’t lie. I know you do. It’s the player’s primary body, in this game. Take a Capsule metaball, rotate it sideways in Edit Mode, and make it into a mesh. Easy as pie. The body finds what it’s standing on via the Touch sensor, which is actually a terrible idea because it would mean that even touching walls and ceilings would count as grounded: to alleviate this, a capsule is parented to a cylinder set to the Sensor physics-type for double-checking.

image

Isn’t that cute? And it works.

There’s a small script that executes within the capsule that triggers with the cylinder’s own Touch sensor as well as the capsule’s own:

from bge import logic, events
from mathutils import Vector

c = logic.getCurrentController()
o = c.owner

touch = c.sensors['Touch']
slope = c.sensors['Slope']
grounded = touch and slope

if touch.positive:
    o['grounded'] = False
    for obj in slope.hitObjectList:
        if obj in touch.hitObjectList:
            o['grounded'] = True
            break
else:
    o['grounded'] = False

o['touch'] = touch.positive
o['slope'] = slope.positive

Pretty simple, right? If the cylinder and capsule are touching the same object, then the player is standing on something. In theory, this allows for players to potentially jump off of each other in mid-air, but that’s badass so we won’t consider it a bug.

I’ve got work in an hour, so we’ll call it a wrap for now. See ya around…

image

… you sexy fuckers. ♥