Something I just figured out.
Use a sphere to prevent sliding down inclines, when using Blender’s “Character” physics-type.
Theory on How to Implement Non-Parented Fixation
- The movement-script, if grounded, will save the collision-point found by the slope-detector, relative to the ground’s center.
- The ground-sensing script will displace the sprite so as to keep the sprite located at the collision point relative to the ground.
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:
- Make a vector of (1, 0, -1), which is a 45-degree slope.
- Normalize it.
- Take the Z-value, and multiply it by whatever speed being applied.
Here’s the Blender-file, by the way~!
Movement System Explaination (6/???)
I’M-A DUMPIN’ MAH MOVEMENT SCRIPTS.
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.