Design of Base.tscn Scene
In this section I’ll quickly explain how the “Base.tscn” scene is organized and also how all of it’s children in “Main.tscn” works as well, such as the spheres that you can push around and the elevating platforms.
The text above the ramps are simply text objects from Blender converted to meshes. They tell the angle of the ramp below it in degrees.
These are here for the testing of the attenuation of walking on slopes and walking on slopes that are considered walls (“MaxFloorAngleRad” in “Player.gd”).
This is for testing the movement of a somewhat low-res terrain. This is important when doing slope speed attenuation as on a ramp like this as one polygon on the ramp may have quite a bit different slope angle to the next polygon, causing a weird effect wherein the player randomly slows down and speeds up while walking up the ramp.
This may be mitigated by modifying the exponent of the “pow()” function at the end of “Slope_AffectSpeed()” function to give a smoother angle to speed falloff.
It’s just a big hemisphere that looks cool.
For testing jumping and walking in confined space that angle into a impassable space between them at one end. To see if there are collision errors.
There are two curved walls, one on the floor and one in the air near the floating bridge. The one on the floor has a dark metal material.
This ramp is for testing walking up a slope that gradually curves into a wall and seeing if there are any errors. The only problem is that the character tries to walk up the slope that is too steep even if he can’t walk on it. It isn’t a huge problem though, and it’s not unrealistic. If you were to try walking up a steep slope quickly you would get up a little ways and start sliding back down.
The floor is actually 4 boxes. This is for testing walking on a floor that is made of several elements. When passing over from one floor section to another there are no errors, so that’s a good sign of well designed collision detection.
This group of boxes and objects is just for testing random geometry, stairs, a ramp, and a couple of tiny bridges between some of them. It’s also for testing jumping in a confined space, as when you walk under the little bridges you can try to jump but you’ll fall right back down.
This exist for the same reason that the objects and boxes in the NE corner do.
The big curved floating object is for testing how the player walks on in confined curved space. The only problem I’ve had is when the player in under the overhang near the end of the object. He tried to step up onto some of the geometry there, for some reason. It’s not game-breaking, though.
This is so that the an elevator that goes up can have a destination.
These are here for testing the shadows.
This is for testing a big ramp. The big problem with this is that since the ramp is a little ways away from the invisible wall, the player character can fall between the ramp and the wall. When this happens, the player doesn’t really fall between them as the space is only about 10 cm. Even so, when this happens the physics engine doesn’t count the player as being on a floor, but instead as being on a couple of walls, not allowing the player to get back on the ramp. I might work on this, I might not. It seems important.
These are here to keep the player from falling off the sides and to also test pushing a quick moving object through them, such as the blue sphere with Godette trapped inside.
I’ve had a problem with the blue sphere being pushed through it at somewhat moderate velocities. Then I made the walls thicker and the problem persisted. I also tried using primitive collision shapes provided by Godot and they didn’t work either. I was also enabling and disabling continuous collision detection on each example. I guess CCD doesn’t work right now, as of Godot 3.0.2. Oh well.
These are for testing platforms that have tiny steps on them and seeing if the character tries to walk on the tiny steps instead of the bigger step. The player actually does walk up the tiny step, but it doesn’t cause any issues such as getting stuck on the tiny step or what not.
These objects have “elevator.gd” attached to them.
This script simply has one functions in it, “TouchFunction()”.
It first checks to see if the animation player child node is playing any animation. If it’s not then it plays the “Lift” animation of that node.
This is used by simply touching the node with the player character, and all the activation is taken care of in “player.gd”.
These objects have “Sphere.gd” attached to them. This script has just one function in it, “UseFunction()”, which pushes the sphere around according to where on the sphere the player is looking at, and pushes with a force according to it’s mass set in the node properties.
It first set’s up two Vector3 variables, “Pos” and “Impulse”. Then it set’s up a floating point variable called “Impulse_Mul” and set’s the impulse amount according to the object’s mass as set in the node’s settings. “Pos” is the position on the sphere that the impulse will be applied to. “Impulse” is the direction and magnitude of force of the applied impulse. “Impulse” is multiplied by “Impulse_Mul”.
It then gets the player node and also the player’s camera node and puts them into a variable.
Now it makes variables “x”, “y”, and “z” and puts the direction normal that the player is facing inside them. “x” and “z” say how much the player node is looking at the x and z axis and in what direction. “y” says how much the camera node is looking up and down, basically. If I tried to use the camera’s normals I couldn’t get the “x” axis is register as anything other than “0”. I’m not sure why.
After this we set up a Vector3 variable that says in what direction the player is looking.
Here’s the final part where we set everything up to do our “apply_impulse()” on the sphere. We set the “pos” variable according to the player’s “Use” ray cast intersection position. Now here’s the confusing part: we do this in global space but relative to the sphere. So we take the ray cast intersection point and subtract the sphere’s global position from it to get the relative position of the ray intersection.
The picture show the basic reason why we use global space. If the we used local space and the object rotated, like the sphere, whenever we tried to “use” the sphere the point would be incorrect even if we converted it to global space using “to_global()”.
Now the impulse variable needs to be set. It just gets our previous Vector3 variable that holds the direction the player camera is looking and multiplies that by the force multiplier (“Impulse_Mul”).
Then we simply apply the impulse with “apply_impulse()”.
