Design of Main.tscn

This chapter explains the main scene (“Main.tscn”) and its scripts. Each item has the name first and its node type in parentheses.

• Main (Spatial)
  • “Init_Script.gd” is attached to this node.
  • Env_and_Lights (Spatial)
    • WorldEnvironment (WorldEnvironment)
      • Uses the “Main_Env.tres” file in the “environment” folder.
    • Sun (DirectionalLight)
      • Just the main light.
  • Base (Spatial)
    • A instance of “Base.tscn”.
    • Platform_Low (KinematicBody)
      • “elevator.gd” is attached to this node.
      • Has a “AnimationPlayer” node which has a “Lift” animation.
    • Platform_High (KinematicBody)
      • “elevator.gd” is attached to this node.
      • Has a “AnimationPlayer” node which has a “Lift” animation.
    • Big_Sphere (RigidBody)
      • “Sphere.gd” is attached to this node.
    • Blue_Sphere (RigidBody)
      • “Sphere.gd” is attached to this node.
    • ZipBox (KinematicBody)
      • “elevator.gd” is attached to this node.
      • Has a “AnimationPlayer” node which has a “Lift” animation.
    • FloorPlatform (KinematicBody)
      • “elevator.gd” is attached to this node.
      • Has a “AnimationPlayer” node which has a “Lift” animation.
    • SmallStep_01 (StaticBody)
    • Smallstep_02 (StaticBody)
    • Smallstep_03 (StaticBody)
    • BigStairs (StaticBody)
    • BigStairsPlatform (StaticBody)
  • GIProbe (GIProbe)
  • Player (KinematicBody)
    • And instance of “Player.tscn”.

Scripts Inside Main.tscn

There is only one not explained elsewhere.

Init_Script.gd

There is only one global variable in this scene: a bool that says if we want to have collision slide visualizations. If you set this to true make sure you also put in “emit_signal("Coll_Sphere_Show", slide, get_slide_collision(slide).position)” somewhere in “Player.gd”. Check the bottom of this script for a little more information.

After that we have a “_ready()” function. It sets the window title, mouse mode, and unhandled input process.

Then we have a "if" statement checking if we want to have collision spheres. If we do then it sets up a variable for pointing to the player node, a collision sphere array to hold the instance pointers to the collision spheres, and an integer that holds whatever “MaxSlides” is inside “Player.gd”. After that it resizes the collision sphere array to whatever “MaxSlides” is. By default that’s four, so our array would be four elements long. We also have a variable that holds the collision sphere scene so that we can instance it however many times we need.

After this there is a loop that creates instances of the collision sphere scene (“Coll_Sphere.tscn”) according to the amount of slides there are in the player’s script.

In this loop it first creates the instance that we need. Whenever we “instance” a scene, what we are doing is basically just copying it and making a new, independent object of whatever is in that scene. As I said it’s completely independent and has it’s own variables, settings, and whatever else.

The reason that is important is because our next step in this loop is to set the “Array_Element_Number” variable inside the “Coll_Sphere.gd” script that is linked to the instanced scene. Each when setting these variables, each scene has it’s own “Array_Element_Number” variable. It doesn’t copy over from one sphere to the next. We set the number of “Array_Element_Number” according to whatever iteration the loop is currently in. By default, the variables would number from 0 to 4.

After this, we add the instanced sphere to be a child of the current scene, which would be “Main.tscn” in this case, as it is the one that has this script attached to it. Here’s the code:

get_tree().get_root().get_child(0).call_deferred("add_child", Coll_Sphere_Array[x])

Click here to go to the online Godot manual to see how scene trees work.

If that link doesn’t work, then look in the Godot manual for “Scene Tree”. If that doesn’t work, then look for “get_tree()” or “get_root()” and go from there.

One important aspect of this line of code is the “called_deferred()” function. What this does is simply defer the execution of the function named in the first argument to until the current scene is completely loaded, so as to keep the engine from trying to load something that isn’t ready yet.

The first argument of “call_deferred()” is the function you want to execute when everything is done loading, which in this case is “add_child()” without the parentheses. It must be a string. The second argument is the what you want the first argument of “add_child()” to be. If you have another function with multiple arguments just add them in a comma separated list. An example:

call_deferred(“SomeFunc”, 1.2, SomeVar, 5.0)

After that, we finally connect the “Coll_Sphere_Show” signal of the player’s node to the “Coll_Sphere_Show()” function of the collision sphere’s script. Make sure to emit that signal in “Player.gd” somewhere.

The following code, which is an initialization of a temporary variable and a for loop, just sets the initial y position of these sphere instances in 50cm increments above each other, so that the programmer can see them and make sure that things are initializing correctly. It’s not necessary.

After the “_ready()” function we have an unhandled input function. All it does it quit the program when the player presses whatever the “ui_cancel” action is (the “Escape” key by default), and toggles the window into or out of fullscreen whenever the player presses the “Toggle_Fullscreen” action (F4 by default). Note that “is_action_just_pressed()” only gets input once when the button is initially pressed. This works well here as we only want the window to change whenever the player presses the key, but not when it is held down, as that would cause the window to toggle between fullscreen and windowed mode way too much.

Lastly, at the bottom we have the example code you can put into “Player.gd” to show the collision spheres.

Debug Scripts

Here I explain how the two debug scripts work.

Coll_Sphere.gd

This is to be used with an “ImmediateGeometry” node. At the top it has a single global variable called “Array_Element_Number” to be used to say what element index the current instance of this script’s collision sphere inside the collision sphere array is. So if you have a “MaxSlides” of 4 inside the player’s script, then the “Array_Element_Number” at the top of the file represents the slide number to be visualized. Also check the "Init_Script.gd" section on for more information.

“_ready()” makes a sphere and a line going through it. Check the Godot manual or online for tutorials and information about ImmediateGeometry.

The only other thing in here is a function called “Coll_Sphere_Show()” which sets the position of the sphere according to the position of the collision slide referenced in the player script.

What it does is take a slide number and a 3D vector. It checks to see if the current slide number (inside the player script) matches the “Array_Element_Number” set while being instanced in “Init_Script.gd”. If they’re the same it sets the position of the sphere to the current slide collision’s position using an signal.

Pos_Visual_Axis.gd

This is also to be attached to an “ImmediateGeometry” node.

In the “_ready()” section it creates a line primitive that has three lines all intersecting each other in the center. After that it connects “Set_Position()” in this script to the “Render_Pos” signal in “Player.gd”.

In the “Set_Position()” function it takes a 3D vector given when emitting the signal from “Player.gd”, and simply sets the location of the geometry according to the vector given. That’s it.