Single Player FPS Part 6

In this part, we’re going to add a main menu and pause menu, add a respawn system for the player, and change/move the sound system so we can use it from any script.

This is the last part of the FPS tutorial; by the end of this, you will have a solid base to build amazing FPS games with Godot!

Let’s get started!

Adding the main menu

Firstly, open up Main_Menu.tscn and take a look at how the scene is set up.

The main menu is broken up into three different panels, each representing a different ‘screen’ of our main menu.

Feel free to expand all the nodes and see how they’re set up. Remember to keep only Start_Menu visible when you’re done, as that’s the screen we want to show first when we enter the main menu.

Select Main_Menu (the root node) and create a new script called Main_Menu.gd. Add the following:

Most of the code here relates to making UIs, which is outside of the purpose of this tutorial series. We’re only going to look at the UI related code briefly.

Let’s look at the class variables first.

• start_menu: A variable to hold the Start_Menu Panel.
• level_select_menu: A variable to hold the Level_Select_Menu Panel.
• options_menu: A variable to hold the Options_Menu Panel.
• testing_area_scene: The path to the Testing_Area.tscn file, so we can change to it from this scene.
• space_level_scene: The path to the Space_Level.tscn file, so we can change to it from this scene.
• ruins_level_scene: The path to the Ruins_Level.tscn file, so we can change to it from this scene.

Now let’s go over _ready

Firstly, we get all the Panel nodes and assign them to the proper variables.

Next, we connect all the buttons pressed signals to their respective [panel_name_here]_button_pressed functions.

We then set the mouse mode to MOUSE_MODE_VISIBLE to ensure whenever the player returns to this scene, the mouse will be visible.

Then we get a singleton, called Globals. We then set the values for the HSlider nodes so their values line up with the mouse and joypad sensitivity in the singleton.

In start_menu_button_pressed, we check to see which button is pressed.

Based on the button pressed, we either change the currently visible panel, quit the application, or open the Godot website.

---

In level_select_menu_button_pressed, we check to see which button is pressed.

If the back button has been pressed, we change the currently visible panels to return to the main menu.

If one of the scene changing buttons is pressed, we fist call set_mouse_and_joypad_sensitivity so the singleton (Globals.gd) has the values from the HSlider nodes. Then, we tell the singleton to change nodes using its load_new_scene function, passing in the file path of the scene the player has selected.

In options_menu_button_pressed, we check to see which button is pressed.

If the back button has been pressed, we change the currently visible panels to return to the main menu.

If the fullscreen button is pressed, we toggle the OS‘s full screen mode by setting it to the flipped version of its current value.

If the vsync button is pressed, we set the OS‘s Vsync based on the state of the Vsync check button.

---

Finally, lets take a look at set_mouse_and_joypad_sensitivity.

Firstly, we get the Globals singleton and assign it to a local variable.

We then set the mouse_sensitivity and joypad_sensitivity variables to the values in their respective HSlider node counterparts.

Making the Globals singleton

Now, for all this to work, we need to create the Globals singleton. Make a new script in the Script tab and call it Globals.gd.

Add the following to Globals.gd:

As you can see, it’s quite small and simple. As this part progresses, we will keep adding more complex logic to Globals.gd, but for now, all it is doing is holding two class variables, and abstract defining how we change scenes.

• mouse_sensitivity: The current sensitivity for our mouse, so we can load it in Player.gd.
• joypad_sensitivity: The current sensitivity for our joypad, so we can load it in Player.gd.

Right now, all we will be using Globals.gd for is a way to carry variables across scenes. Because the sensitivities of our mouse and joypad are stored in Globals.gd, any changes we make in one scene (like in Options_Menu) will affect the sensitivity for the player.

All we’re doing in load_new_scene is calling SceneTree‘s change_scene function, passing in the scene path given in load_new_scene.

That’s all the code needed for Globals.gd right now! Before we can test the main menu, we first need to set Globals.gd as an autoload script.

Open up the Project Settings and click the AutoLoad tab.

Then select the path to Globals.gd in the Path field by clicking the button (..) beside it. Make sure the name in the Node Name field is Globals. If you have everything like in the picture above, then press Add!

This will make Globals.gd a singleton/autoload script, which will allow us to access it from any script, in any scene.

Now that Globals.gd is a singleton/autoload script, you can test the main menu!

You may want to change the main scene from Testing_Area.tscn to Main_Menu.tscn so when we export the game the player will start at the main menu. You can do this through the Project Settings, under the General tab. Then in the Application category, click the Run subcategory and you can change the main scene by changing the value in Main Scene.

Adding the debug menu

Now, let’s add a simple debugging scene so we can track things like FPS (Frames Per Second) in-game. Open up Debug_Display.tscn.

You can see it’s a Panel positioned in the top right corner of the screen. It has three Labels, one for displaying the FPS at which the game is running, one for showing on what OS the game is running, and a label for showing with which Godot version the game is running.

Let’s add the code needed to fill these Labels. Select Debug_Display and create a new script called Debug_Display.gd. Add the following:

Let’s go over what this script does.

---

In _ready, we set the OS_Label‘s text to the name provided by OS using the get_name function. This will return the name of the OS (or Operating System) for which Godot was compiled. For example, when you are running Windows, it will return Windows, while when you are running Linux, it will return X11.

Then, we set the Engine_Label‘s text to the version info provided by Engine.get_version_info. Engine.get_version_info returns a dictionary full of useful information about the version of Godot which is currently running. We only care about the string version, for this label at least, so we get the string and assign that as the text in Engine_Label. See Engine for more information on the values get_version_info returns.

In _process, we set the text of the FPS_Label to Engine.get_frames_per_second, but because get_frames_per_second returns an integer, we have to cast it to a string using str before we can add it to the Label.

---

Now let’s jump back to Main_Menu.gd and change the following in options_menu_button_pressed:

to this instead:

This will call a new function called set_debug_display in our singleton, so let’s add that next!

---

Open up Globals.gd and add the following class variables:

• canvas_layer: A canvas layer so the GUI/UI created in Globals.gd is always drawn on top.
• DEBUG_DISPLAY: The debug display scene we worked on earlier.
• debug_display: A variable to hold the debug display when/if there is one.

Now that we have the class variables defined, we need to add a few lines to _ready so Globals.gd will have a canvas layer to use (which we will store in canvas_layer). Change _ready to the following:

Now in _ready, we create a new canvas layer, assign it to canvas_layer and add it as a child. Because Globals.gd is an autoload/singleton, Godot will make a Node when the game is launched, and it will have Globals.gd attached to it. Since Godot makes a Node, we can treat Globals.gd like any other node with regard to adding/removing children nodes.

The reason we’re adding a CanvasLayer is so all our GUI and UI nodes we instance/spawn in Globals.gd are always drawn on top of everything else.

When adding nodes to a singleton/autoload, you have to be careful not to lose reference to any of the child nodes. This is because nodes will not be freed/destroyed when you change the active scene, meaning you can run into memory problems if you are instancing/spawning lots of nodes and you are not freeing them.

---

Now we need to add set_debug_display to Globals.gd:

Let’s go over what’s happening.

First we check to see if Globals.gd is trying to turn on the debug display, or turn it off.

If Globals.gd is turning off the display, we then check to see if debug_display is not equal to null. If debug_display is not equal to null, then Globals.gd must have a debug display currently active. If Globals.gd has a debug display active, we free it using queue_free and then assign debug_display to null.

If Globals.gd is turning on the display, we then check to make sure Globals.gd do not already have a debug display active. We do this by making sure debug_display is equal to null. If debug_display is null, we instance a new DEBUG_DISPLAY_SCENE, and add it as a child of canvas_layer.

---

With that done, we can now toggle the debug display on and off by switching the CheckButton in the Options_Menu panel. Go give it a try!

Notice how the debug display stays even when you change scenes from the Main_Menu.tscn to another scene (like Testing_Area.tscn). This is the beauty of instancing/spawning nodes in a singleton/autoload and adding them as children to the singleton/autoload. Any of the nodes added as children of the singleton/autoload will stay for as long as the game is running, without any additional work on our part!

Adding a pause menu

Let’s add a pause menu so we can return to the main menu when we press the ui_cancel action.

Open up Pause_Popup.tscn.

Notice how the root node in Pause_Popup is a WindowDialog; WindowDialog inherits from Popup, which means WindowDialog can act like a popup.

Select Pause_Popup and scroll down all the way till you get to the Pause menu in the inspector. Notice how the pause mode is set to process instead of inherit like it is normally set by default. This makes it so it will continue to process even when the game is paused, which we need in order to interact with the UI elements.

Now that we’ve looked at how Pause_Popup.tscn is set up, let’s write the code to make it work. Normally, we’d attach a script to the root node of the scene, Pause_Popup in this case, but since we’ll need to receive a couple of signals in Globals.gd, we’ll write all the code for the popup there.

Open up Globals.gd and add the following class variables:

• MAIN_MENU_PATH: The path to the main menu scene.
• POPUP_SCENE: The pop up scene we looked at earlier.
• popup: A variable to hold the pop up scene.

Now we need to add _process to Globals.gd so it can respond when the ui_cancel action is pressed. Add the following to _process:

Let’s go over what’s happening here.

---

Firstly, we check to see if the ui_cancel action is pressed. Then, we check to make sure Globals.gd does not already have a popup open by checking to see if popup is equal to null.

If Globals.gd do not have a pop-up open, we instance POPUP_SCENE and assign it to popup.

We then get the quit button and assign its pressed signal to popup_quit, which we will be adding shortly.

Next, we assign both the popup_hide signal from the WindowDialog and the pressed signal from the resume button to popup_closed, which we will be adding shortly.

Then, we add popup as a child of canvas_layer so it’s drawn on top. We then tell popup to pop up at the center of the screen using popup_centered.

Next, we make sure the mouse mode is MOUSE_MODE_VISIBLE so the player can interact with the pop-up. If we did not do this, the player would not be able to interact with the pop up in any scene where the mouse mode is MOUSE_MODE_CAPTURED.

Finally, we pause the entire SceneTree.

Now, we need to add the functions to which we’ve connected the signals. Let’s add popup_closed first.

Add the following to Globals.gd:

popup_closed will resume the game and destroy the pop-up if there is one.

popup_quit is similar, but we’re also making sure the mouse is visible and changing scenes to the title screen.

Add the following to Globals.gd:

popup_quit will resume the game, set the mouse mode to MOUSE_MODE_VISIBLE to ensure the mouse is visible in the main menu, destroy the pop-up if there is one, and change scenes to the main menu.

---

Before we’re ready to test the pop-up, we should change one thing in Player.gd.

Open up Player.gd and in process_input, change the code for capturing/freeing the cursor to the following:

Instead of:

We will leave only:

Now, instead of capturing/freeing the mouse, we check whether the current mouse mode is MOUSE_MODE_VISIBLE. If it is, we set it back to MOUSE_MODE_CAPTURED.

Because the pop-up makes the mouse mode MOUSE_MODE_VISIBLE whenever you pause, we no longer have to worry about freeing and capturing the cursor in Player.gd.

---

Now the pause menu pop-up is finished. You can now pause at any point in the game and return to the main menu!

Starting the respawn system

Since the player can lose all their health, it would be ideal if the player died and respawned too, so let’s add that next!

Firstly, open up Player.tscn and expand HUD. Notice how there is a ColorRect called Death_Screen. When the player dies, we’re going to make Death_Screen visible, and show them how long they have to wait before the player is able to respawn.

Open up Player.gd and add the following class variables:

• RESPAWN_TIME: The amount of time (in seconds) it takes to respawn.
• dead_time: A variable to track how long the player has been dead.
• is_dead: A variable to track whether or not the player is currently dead.
• globals: A variable to hold the Globals.gd singleton.

---

We now need to add a couple lines to _ready, so we can use Globals.gd in Player.gd. Add the following to _ready:

Now we’re getting the Globals.gd singleton and assigning it to globals. We also set the player’s global position by setting the origin in the player’s global Transform to the position returned by globals.get_respawn_position.

Next, we need to make a few changes to _physics_process. Change _physics_process to the following:

Now the player will not be processing input or movement input when the player is dead. We are also now calling process_respawn.

We have not made process_respawn yet, so let’s change that.

---

Let’s add process_respawn. Add the following to Player.gd:

Let’s go through what this function is doing.

---

Firstly, we check whether the player has just died by checking if health is less than or equal to 0 and is_dead is false.

If the player has just died, we disable the collision shapes for the player. We do this to make sure the player is not blocking anything with their dead body.

Next, we set changing_weapon to true and set changing_weapon_name to UNARMED. This is so, if the player is using a weapon, it is put away when they dies.

We then make the Death_Screen ColorRect visible so the player gets a nice grey overlay over everything when they have died. We then make the rest of the UI, the Panel and Crosshair nodes, invisible.

Next, we set dead_time to RESPAWN_TIME so we can start counting down how long the player has been dead. We also set is_dead to true so we know the player has died.

If the player is holding an object when they died, we need to throw it. We first check whether the player is holding an object or not. If the player is holding a object, we throw it using the same code as the throwing code we added in Part 5.

Then we check whether the player is dead. If so, we then remove delta from dead_time.

We then make a new variable called dead_time_pretty, where we convert dead_time to a string, using only the first three characters starting from the left. This gives the player a nice looking string showing how much time the player has left to wait before the player can respawn.

We then change the Label in Death_Screen to show how much time the player has left.

Next we check to see if the player has waited long enough and can respawn. We do this by checking to see if dead_time is 0 or less.

If the player has waited long enough to respawn, we set the player’s position to a new respawn position provided by get_respawn_position.

We then enable both of the player’s collision shapes so the player can collide again with the environment.

Next, we make the Death_Screen invisible and make the rest of the UI, the Panel and Crosshair nodes, visible again.

We then go through each weapon and call its reset_weapon function, which we will add soon.

Then, we reset health to 100, grenade_amounts to its default values, and change current_grenade to Grenade. This effectively resets these variables to their default values.

Finally, we set is_dead to false.

---

Before we leave Player.gd, we need to add one quick thing to _input. Add the following at the beginning of _input:

Now, when the player is dead, they cannot look around with the mouse.

Finishing the respawn system

Firstly, let’s open Weapon_Pistol.gd and add the reset_weapon function. Add the following:

Now, when we call reset_weapon, the ammo in the pistol and the ammo in the spares will be reset to their default values.

Now let’s add reset_weapon in Weapon_Rifle.gd:

And add the following to Weapon_Knife.gd:

Now all the weapons will reset when the player dies.

---

Now we need to add a few things to Globals.gd. Firstly, add the following class variable:

• respawn_points: A variable to hold all the respawn points in a level

Because we’re getting a random spawn point each time, we need to randomize the number generator. Add the following to _ready:

randomize will get us a new random seed so we get a (relatively) random string of numbers when we use any of the random functions.

Now let’s add get_respawn_position to Globals.gd:

Let’s go over what this function does.

---

Firstly, we check if Globals.gd has any respawn_points by checking whether respawn_points is null or not.

If respawn_points is null, we return a position of empty Vector 3 with the position (0, 0, 0).

If respawn_points is not null, we then get a random number between 0 and the number of elements we have in respawn_points, minus 1 since most programming languages, including GDScript, start counting from 0 when you are accessing elements in a list.

We then return the position of the Spatial node at respawn_point position in respawn_points.

---

Before we are done with Globals.gd, we need to add the following to load_new_scene:

We set respawn_points to null so when/if the player gets to a level with no respawn points, we do not respawn the player at the respawn points that were in the level prior.

---

Now all we need is a way to set the respawn points. Open up Ruins_Level.tscn and select Spawn_Points. Add a new script called Respawn_Point_Setter.gd and attach it to Spawn_Points. Add the following to Respawn_Point_Setter.gd:

Now, when a node with Respawn_Point_Setter.gd has its _ready function called, all the children nodes of the node with Respawn_Point_Setter.gd, Spawn_Points in the case of Ruins_Level.tscn, will be added to respawn_points in Globals.gd.

Now, when the player dies, they will respawn after waiting 4 seconds!

Writing a sound system we can use anywhere

Finally, let’s make a sound system so we can play sounds from anywhere, without having to use the player.

Firstly, open up SimpleAudioPlayer.gd and change it to the following:

There are several changes from the old version, first and foremost being we are no longer storing the sound files in SimpleAudioPlayer.gd anymore. This is much better for performance since we’re no longer loading each audio clip when we create a sound, but instead we are forcing an audio stream to be passed in to play_sound.

Another change is we have a new class variable called should_loop. Instead of just destroying the audio player every time it’s finished, we instead want to check and see if the audio player is set to loop or not. This allows us to have audio like looping background music without having to spawn a new audio player with the music when the old one is finished.

Finally, instead of being instanced/spawned in Player.gd, the audio player is instead going to be spawned in Globals.gd so we can create sounds from any scene. Now the audio player stores Globals.gd singleton so when the audio player is destroyed, we can also remove it from a list in Globals.gd.

Let’s go over the changes.

---

For the class variables, we removed all the audio_[insert name here] variables since we will instead have these passed in from Globals.gd.

We also added two new class variables, should_loop and globals. We’ll use should_loop to tell whether the audio player should loop when the sound has finished, and globals will hold the Globals.gd singleton.

The only change in _ready is now audio player is getting the Globals.gd singleton and assigning it to globals.

play_sound now expects an audio stream, named audio_stream, to be passed in, instead of sound_name. Instead of checking the sound name and setting the stream for the audio player, we instead check to make sure an audio stream was passed in. If an audio stream was not passed in, we print an error message, remove the audio player from a list in the Globals.gd singleton called created_audio, and then free the audio player.

Finally, in sound_finished we first check to see if the audio player is supposed to loop or not using should_loop. If the audio player is supposed to loop, we play the sound again from the start, at position 0.0. If the audio player is not supposed to loop, we remove the audio player from a list in the Globals.gd singleton called created_audio, and then free the audio player.

---

Now that we’ve finished our changes to SimpleAudioPlayer.gd, we now need to turn our attention to Globals.gd. First, add the following class variables:

Let’s go over these global variables.

• audio_clips: A dictionary holding all the audio clips Globals.gd can play.
• SIMPLE_AUDIO_PLAYER_SCENE: The simple audio player scene.
• created_audio: A list to hold all the simple audio players Globals.gd has created.

Now we need to add a new function called play_sound to Globals.gd:

Let’s go over what this function does.

Firstly, we check whether Globals.gd has an audio clip with the name sound_name in audio_clips. If it does not, we print an error message.

If Globals.gd has an audio clip with the name sound_name, we then instance/spawn a new SIMPLE_AUDIO_PLAYER_SCENE and assign it to new_audio.

We then set should_loop, and add new_audio as a child of Globals.gd.

We add the new_audio into the created_audio list to hold all created audios.

We then call play_sound, passing in the audio clip associated with sound_name and the sound position.

---

Before we leave Globals.gd, we need to add a few lines of code to load_new_scene so when the player changes scenes, all the audio is destroyed.

Add the following to load_new_scene:

Now, before Globals.gd changes scenes, it goes through each simple audio player in created_sounds and frees/destroys them. Once Globals.gd has gone through all the sounds in created_audio, we clear created_audio so it no longer holds any references to any (now freed/destroyed) simple audio players.

---

Let’s change create_sound in Player.gd to use this new system. First, remove simple_audio_player from Player.gd‘s class variables since we will no longer be directly instancing/spawning sounds in Player.gd.

Now, change create_sound to the following:

Now, whenever create_sound is called, we simply call play_sound in Globals.gd, passing in all the arguments received.

---

Now all the sounds in our FPS can be played from anywhere. All we have to do is get the Globals.gd singleton, and call play_sound, pass in the name of the sound we want to play, whether we want it to loop or not, and the position from which to play the sound.

For example, if you want to play an explosion sound when the grenade explodes you’d need to add a new sound to audio_clips in Globals.gd, get the Globals.gd singleton, and then you just need to add something like globals.play_sound("explosion", false, global_transform.origin) in the grenades _process function, right after the grenade damages all the bodies within its blast radius.

Final notes

Now you have a fully working single player FPS!

At this point, you have a good base to build more complicated FPS games.

You can download all the .blend files used in this tutorial here: https://randommomentania.com/freebie-downloads/

All assets provided in the started assets (unless otherwise noted) were originally created by TwistedTwigleg, with changes/additions by the Godot community and TwistedTwigleg. All original assets provided for this tutorial are released under the MIT license.

Feel free to use these assets however you want! All original assets belong to the Godot community, with the other assets belonging to those listed below:

The skybox is created by StumpyStrust and can be found at OpenGameArt.org. https://opengameart.org/content/space-skyboxes-0 . The skybox is licensed under the CC0 license.

The font used is Titillium-Regular, and is licensed under the SIL Open Font License, Version 1.1.

The skybox was converted to a 360 equirectangular image using this tool: https://www.360toolkit.co/convert-cubemap-to-spherical-equirectangular.html

While no sounds are provided, you can find many game ready sounds at https://gamesounds.xyz/