Action/Adventure Series Episode 1 - Getting Started in Godot

Welcome to the first episode of our action/adventure game series! Throughout this series, we’ll be creating a 3D action/adventure game in the style of a beloved classic: The Legend of Zelda: Ocarina of Time.

Our goal for this episode is to cover enough of the fundamentals that you’ll be able to setup a simple 3D scene, along with a basic version of our player “character” that we’ll be building upon in future episodes.

First things first, we need to get our hands on the software needed to make a game. For this series, we’ll be using Godot, a free and open-source1 game engine that’s a great fit for both beginners and experienced developers.

What is Godot?

Godot is a type of program called a game engine. This is set of tools and software that allow you to jump into creating your game, rather than having to build everything from scratch.

Downloading GodotJump to 1:04

We can get the engine from Godot’s website by clicking the “Download Latest”2 button on the home page. When you get to the download page, you’ll see two options. The first option is the one we recommend for this series, with the second option (the .NET one) being an alternative for those looking to use C# for scripting. Either version supports GDScript, but the .NET version requires the .NET SDK to be installed before you can use some of its features3.

Wait, Why?

We’ll be focusing on GDScript for this series, which is Godot’s built-in scripting language. The reason we’ve chosen to use it over C# is that it integrates more seamlessly with Godot’s feature set and is much easier to get started with.

That said, C# is a more mature and powerful language that’s used broadly in the game development industry. It does have a steeper learning curve, but if you’ve decided you want to learn C# instead — don’t worry! The concepts we cover in this series will still be relevant to you and we’ll be providing the C# versions of any code we write in GDScript.

After you’ve downloaded the ZIP file, extract it to a location of your choice using whatever tool you prefer. Godot doesn’t require installation and is a self-contained executable4, so you can run it directly from the extracted folder.

Creating Your First ProjectJump to 2:33

When you first open Godot, you’ll see the “project selection” screen. This is where all your recently opened game projects will be listed and where you can create new projects. When you’re first starting out, it’s normal for this list to contain the “corpses” of experiments and abandoned projects.

To create a new project, you can click the “Create” button in the top left area of this window. This will present a dialog where we can configure the settings for our new project — most importantly, the name we want to use and the location where we want to save it on our computer5.

We’ll leave the other settings as the defaults for now. If possible, make sure that the “Version Control Metadata” option is set to “Git”6 and that the “Edit Now” checkbox is checked.

Opening our project for the first timeJump to 3:09

When you first create and open your Godot project, you’ll be greeted by the Godot project editor interface. It might look a bit overwhelming at first with all its panels, buttons, and options, but don’t worry — we’ll introduce you to the most important parts as we go along.

One of the first things to understand about Godot is that there is always a scene loaded in the editor, even if it’s completely empty and hasn’t been saved yet. You can think of a scene as a container that holds all the parts7 for a specific part of your game. This could be a level, a character, a menu screen, or even just a single object like a treasure chest.

This modular approach has several advantages:

1. Keeps your project organized and manageable.
2. Allows you to reuse elements across your game.
3. Makes collaboration easier when working in teams.
4. Helps with performance by only loading what’s needed.

Scene Files

Godot scenes are saved with the .tscn extension, which stands for “text scene.” They’re actually text files that describe the structure of your scene.

Crash Course on Navigating in 3DJump to 3:29

If you’re new to 3D software, then moving around in the “3D viewport” may feel a bit strange at first. Here’s a quick guide to help you get started.

Orbital Rotation

Hold and drag the mouse to rotate around the center point that the viewport is focused on.

Panning

Hold shift+ while dragging the mouse to move the camera left, right, up, and down.

Zoom In & Out

Use to or hold Ctrl+ while dragging the mouse to zoom the camera in and out.

First-Person Mode

Hold and drag to rotate your camera, then use the wasdqe to move around. If you hold shift while moving, you’ll move faster.

What are these lines in the viewport?Jump to 4:23

When you first look at the 3D viewport, you’ll notice three colorful lines that intersect. These are called axes8 and they represent the “3 dimensions” that make up 3D. These lines in particular represent our “global” or “world” space dimensions.

Each of these lines is color-coded to represent a different direction in 3D space, and each axis has its own name and direction that it represents. The point at which all three axes meet is called the world origin9. This is the point where all coordinates are measured from, and it’s represented as the value (0, 0, 0).

We’ll be diving way deeper into working with 3D space coordinates in future episodes, so don’t worry if this doesn’t make sense yet.

The meanings can change

The color coding and directionality of these axes are conventions, not hard rules, and they can vary between programs. You’ll often hear this referred to as the “right-handed” coordinate system, where the X-axis points right, the Y-axis points up, and the Z-axis points forward.

On the other hand, Blender uses a “left-handed” coordinate system where the Y-axis points forward and the Z-axis points up and down.

In the top right corner of the viewport, you’ll notice a little widget that lets you switch between different views of your scene. By default, the 3D viewport renders using a “Perspective” projection mode.

When clicking on the circles in the widget, you can snap to different orthographic views like “Top,” “Front,” and “Right.” These views are useful for precise positioning when you need to align objects perfectly.

So clicking on the circle with “Y” in it will give you a top-down view of your scene in the orthographic view mode. This is because we’re looking from the +Y direction downwards towards the world origin.

Let’s talk about nodes and the scene treeJump to 5:22

At the heart of how Godot works is the concept of nodes. Think of nodes as the building blocks of your game — every element, from characters to cameras to menu buttons, is a node of some kind.

Nodes exist in a type of data structure called a tree10, which we specifically refer to as the scene tree. Trees are used to organize data in a hierarchical way, meaning that each node in the tree might have a parent node and can have zero or more children. If a node has no parent, it’s called a root node.

One important thing to understand is that even if a node is the root of a scene, that doesn’t necessarily mean it’s the root of your entire game. Scenes can be instanced within other scenes, creating complex hierarchies that help organize your game’s structure.

In addition to their hierarchical structure, nodes also store data, which we call properties. These properties define the node’s characteristics, like its position, size, or other custom values. Nodes also have code associated with them, which we refer to as the node’s behavior or “what the node actually does”.

We can see the nodes in our scene using the Scene Tree panel on the left side of the editor. This panel shows a hierarchical view of all the nodes in our current scene, allowing us to select and manipulate them easily.

Let’s get practical by adding our first node to the scene — a simple Node3D which will serve as a container for our 3D objects.

An intro to whiteboxingJump to 6:24

Before we dive too deep into creating our game world, let’s talk about a concept that’s crucial in game development: whiteboxing11.

Whiteboxing is essentially the process of creating a rough draft of your level using the fastest, simplest approach possible. Think of it as sketching before painting - you’re laying out the fundamental structure without worrying about textures, lighting, or fine details.

The goal here is to get a sense of scale, layout, and spatial function without getting bogged down in details that might change later. This is especially important since you might need to make major changes or even scrap entire sections as you test and iterate on your gameplay.

Almost all games start with some form of prototyping like whiteboxing, especially 3D action games where scale, spacing, and timing are critical to how the game feels. Even blockbuster titles with multi-million dollar budgets start this way.

In later episodes, we’ll provide pre-made assets to save you time, but we wanted to introduce this concept now because it’s such a fundamental part of the game development process. Plus, understanding how to quickly build simple environments will give you the tools to experiment with your own ideas outside of our tutorials.

Finding the node to start our level whiteboxJump to 7:11

Now that we have our empty scene with a root node, let’s start building our level. The first step is to select our root node in the scene tree, then right-click on it and select “Add Child Node” from the context menu12.

This brings up the node browser, which might look a bit overwhelming at first glance. This window displays all the different types of nodes available in Godot. On the left side, you’ll see a categorized list of nodes, while the right panel shows a description of whatever node you’ve selected.

Time-Saving Tip

Notice the “Recently Used” and “Favorites” sections at the bottom left of the node browser. Godot keeps track of nodes you use frequently, making them easier to find next time. If there’s a node you find yourself using often, you can click the star icon to add it to your favorites for even quicker access!

Don’t worry about memorizing all these node types! There are dozens of them, each with their own specific purposes and behaviors. Just learn the ones you need as you go along. Think of this as a toolbox - you don’t need to know how to use every tool right away.

Many of these nodes also inherit functionality from other nodes (we’ll explore this concept in our next episode), which means they share common features while adding their own unique capabilities.

How nodes are categorized by colorJump to 8:13

Godot uses a color-coding system to help you quickly identify different types of nodes in your scene tree. This makes it much easier to understand the composition of your scene at a glance.

Blue Nodes (2D)

Blue is used to represent 2D elements. If you’re making a pixel art game with sprites, you’ll be working with many different types of 2D nodes.

Green Nodes (Control)

Green nodes are “control” nodes, used to create UI (user interface) elements. Whether you’re making a 2D or 3D game, you’ll likely have at least a few control nodes for things like menus, health bars, or score displays.

Red Nodes (3D)

Red nodes are for 3D elements. Since we’re making a 3D game, we’ll be working with these nodes the most throughout our series.

There are other colors too. Plain nodes or “data only” nodes might appear in white, while animation-related nodes, like AnimationPlayer , show up in purple. As you work more with Godot, you’ll start recognizing these colors (and icons) instinctively, making it easier to navigate complex scenes.

Adding the node to “ground” usJump to 8:36

It’s time to add something to our empty scene. We’ll start with a simple floor to give our future player character something to stand on. In the node browser, you can use the search bar at the top to quickly find the node we need.

Type “box”13 into the search field, and it should filter the nodes down to the one we’re looking for, which is CSGBox3D . CSG stands for Constructive Solid Geometry, which is Godot’s toolbox of 3D primitives designed for quickly creating levels and objects using simple shapes14.

Once you’ve found the CSGBox3D node, select it and click “Create” to add it to our scene. By default, it will be positioned at the origin (0, 0, 0) of our world — exactly where we want it for now. You should see a simple box appear in your viewport.

This box will serve as our floor, but… it’s a little too small right now.

Transforming objects in the sceneJump to 9:28

This is a good opportunity to segue into how we manipulate objects in our 3D scene. We call these our “transformation” tools, and they allow us to position, rotate, and scale objects in our game world. These tools are essential for building your game environment.

To manipulate objects in the scene, you’ll use these transform15 tools. Each of which is accessible by a keyboard shortcut.

Select Mode

Provides a “combination gizmo” for both moving and rotating objects. It’s often the most convenient option for making quick adjustments without switching tools.

Move/Translate Mode

Displays arrows along each axis, allowing for precise positioning. Click and drag on an arrow to move along that specific axis. The colored squares between arrows let you move on two axes simultaneously16. Hold Ctrl while moving to snap to points on the grid (which are units of 1 by default).

Rotate Mode

Shows colored circles representing each rotation axis. Click and dragging on one of these circular lines will rotate the object around that axis. Holding Ctrl will snap rotations to 15-degree increments for precise angular adjustments.

Scale Mode

Displays handles for scaling along each axis. The squares in between let you scale on two axes at once. Hold shift to scale uniformly in all directions, maintaining the object’s proportions. Hold Ctrl to snap to increments of 1.

These transform tools will become second nature as you spend more time building environments in Godot17. Practice switching between them using the keyboard shortcuts to speed up your workflow.

Turning a box into a floorJump to 11:09

You might be tempted to use the scale tool to stretch our box into a floor shape, but that’s not the best approach here. The actual geometry of a CSGBox3D is defined by its size property, not by its scale property.

While stretching the box with the scale tool might visually give you what you want, it can lead to problems down the road, especially when:

• Working with more complex shapes
• Combining shape nodes using a CSGCombiner3D
• Setting up physics interactions

Why does this matter?

Physics engines can behave unexpectedly if you scale objects instead of changing their actual size. For example, collision detection might not work as expected, or physics calculations could become less accurate. It’s a subtle distinction now, but it’s a good habit to develop early.

In professional game development, it’s considered best practice to keep your scale at 1 and adjust the actual dimensions of objects using their specific size properties. Let’s learn how to do that properly by looking at the “Inspector” panel.

Properties and the inspector panelJump to 11:41

The “Inspector” panel is your gateway to controlling all the details of a node. When you select a node in the Scene Tree, the Inspector displays all of its properties — the data that defines how the node looks and behaves.

Each property has a name18 and a field where you can edit its value. If you’re ever unsure what a property does, you can move your mouse over the name of the property to see a tooltip with a helpful explanation19.

Here’s something interesting: when we use the transform tools we just learned about, we’re actually just changing the properties of the node. You can see this in action by opening the Transform section towards the bottom of the Inspector panel. As you move, rotate, or scale your object with the gizmos, you’ll see these values updating in real-time.

Resetting properties

If you ever make a mistake or want to return a property to its default value, look for the small “reset” button that appears next to modified properties.

Let’s put this knowledge to use by properly resizing our floor.

Changing the size of our floor the “right” wayJump to 12:43

Let’s resize our box to make it look more like a proper floor. With the CSGBox3D selected, find the “Size” property near the top of the Inspector panel.

You have two ways to adjust this property:

1. Directly input values: Type in your desired dimensions. For a decent starting floor, something like (10, 1, 10) works well - that’s 10 units wide, 1 unit tall, and 10 units deep.
2. Use the visual gizmos: You’ll notice some red circular handles appear on your box in the viewport. Dragging these handles adjusts the size visually.

These gizmos will expand the box in the direction you drag, which also shifts the box’s position. This happens because the size values are relative to the position (or origin) of the box20.

If we hold the Alt key while dragging a size handle, it’ll resize the box symmetrically from its center. This keeps the position unchanged while adjusting the size equally in both directions.

For development purposes21, we want the top surface of our floor to be at Y=0 (where the grid lines meet), we need to move it down slightly. The box’s position is at its center, so we need to move it down by half its height.

Select the CSGBox3D node and use the Move tool w to position it around (0, -0.5, 0) — or just type these values directly into the “Position” property in the Inspector. This places the top surface of our 1-unit-tall box exactly at Y=0, with the box extending downward22.

Perfect! We now have a proper floor that’s correctly sized and positioned. Let’s see what our scene looks like when we run it.

Running our project for the first timeJump to 14:09

Let’s see our creation in action! To run your project, click the “Run Project” button in the top-right corner of the editor. This will launch your game exactly as a player would see it if they installed it on their device.

The first time you run your game, Godot will prompt you to select a “main scene”. This is the scene that will be loaded first when someone starts your game. Since we only have one scene right now, go ahead and click “Select Current” to use it.

Wait — there’s another dialog that appeared! Godot is telling us we need to save our scene first. Let’s save our scene as start.tscn in a new folder called “scenes” within our project directory.

Godot’s file system

All of your game’s files will be stored within your project folder. You’ll start to notice that Godot uses “file paths”23 starting with res://. This fancy prefix stands for “resources” and points to wherever your project is stored on your computer.

So what’s a resource?

A resource is a reusable data asset in Godot. Resources can be anything from textures, sounds, materials… heck, our scenes are a type of resource too! Resources can be saved as separate files to be reused across multiple scenes or be embedded directly in a node’s properties.

It’s also worth noting that throughout this series, you’ll hear us use the terms “resources” and “assets” interchangeably - they both refer to the various files that make up your game.

When you finally run the game… you’ll see… well, nothing. Just a plain gray screen. That’s because we haven’t added a way to view our 3D world yet.

Looking into our 3D worldJump to 15:09

That gray24 screen we’re seeing is because we don’t have a camera in our scene. In a 3D game, the camera acts as the player’s eyes. Without one, the engine doesn’t know what to show on screen.

Let’s add a camera to our scene:

1. Select the root Node3D node in the scene tree
2. Right-click and select “Add Child Node” (or use the button)
3. In the search box, type “camera”
4. Select Camera3D from the results and click “Create”

Now we have a camera in our scene, but may not be pointing in a useful direction. Let’s position it to get a good view of our floor. With the Camera3D node selected, use the transform tools to position it above and slightly away from the center of our floor before pointing the camera down slightly25.

Camera Preview

Look at the small preview window at the top of the Inspector panel when the Camera3D is selected. This shows you exactly what the camera is seeing, making it easier to position it correctly.

Let’s try running our game again!

It’s so dark in hereJump to 15:53

When we run our game, we can kind of see our floor, but it’s super dark and all we really see are the silhouettes of our objects. That’s because we don’t have any lighting in our scene yet.

“But I can see everything just fine in the editor!”

That’s because Godot’s editor uses some default lighting and environment settings to help you see what you’re doing while building your scene.

You can toggle these preview settings on and off by clicking the and buttons in the toolbar of the 3D viewport. If you turn them off, you’ll see that our scene is quite dark — just like when we tried to run our game.

If you click the next to the preview toggles, you can customize these settings to your liking. This can be useful for debugging or testing how your scene might look under different lighting conditions26.

For our actual game, we need to add proper lighting which can be done a few different ways. The quickest way to add these is by using those same preview setting buttons. Look for “Add Directional Light to Scene”27 and “Add Environment to Scene”28 buttons.

Types of Lights

There are several types of lights in Godot, each serving different purposes:

DirectionalLight3D is used to simulate distant light sources like the sun, with parallel rays shooting in a specific direction. For outdoor scenes, you’ll typically use this type of light.

OmniLight3D is a light that emits in all directions from a point, like a lightbulb.

SpotLight3D creates a cone of light, like a flashlight.

Once you’ve added the WorldEnvironment node, you’ll see it has a property called “Environment” that holds the procedurally generated sky you configured in the preview settings29. This sky not only gives us a beautiful backdrop but also contributes to the scene’s ambient lighting30.

Now when we run our game, we should see a nicely lit scene with our floor and a sky in the background. Much better!

Starting our player characterJump to 18:28

Now that we have a floor to stand on and can actually see our scene, let’s start working on a player character that we can control.

In Godot, the recommended way to create a character that needs to interact with the physics world is to use a CharacterBody3D node. This type of node communicates with the physics engine to handle movement, collisions, and other physical interactions.

We can add this to our scene by right-clicking on our root node and selecting “Add Child Node”31. In the search box, type “character” and select CharacterBody3D from the list before clicking “Create”.

After adding the node, you’ll notice a warning icon appearing next to it in the scene tree. If you hover over this icon, you’ll see a message saying that the CharacterBody3D node needs a collision shape to function correctly.

The collision shape defines the physical bounds of our character. It’s what the physics engine will use to detect when our character is touching the floor, walls, or other objects.

We should add a CollisionShape3D node as a child of our CharacterBody3D node. Just right-click on CharacterBody3D , select “Add Child Node”, look for CollisionShape3D , select it, and click “Create”.

Oh good — another warning! This new warning tells us that the CollisionShape3D node needs a shape resource. Unlike adding another node, this time we need to create a “shape resource” - a data asset that defines the geometric shape of our collision.

With our CollisionShape3D node selected, look in the Inspector for the empty shape property. It will be “empty” by default, meaning it doesn’t have a shape assigned to it yet. By clicking on it we’ll be presented a dropdown list with some options to create a new shape resource.

Look for the New CapsuleShape3D option to create a new capsule shape to represent our player character.

Why a Capsule?

We’re using a capsule shape for our player character for several important reasons:

1. Boxes have sharp edges, which can cause the player to get caught on corners and edges of the environment
2. Cylinders are better for moving along walls, but still have sharp edges where they meet the floor
3. Spheres roll smoothly everywhere but don’t represent a character’s height well
4. Capsules combine the best of both worlds - smooth all around for easy movement while still allowing for height

This is why capsules are the industry standard for character controllers in most 3D games!

Now we need to position the collision shape correctly. We want the “foot” of our player to be at the bottom of the capsule, touching the floor.

To achieve this:

1. Keep the CharacterBody3D node at the world origin (0, 0, 0).
2. Select the CollisionShape3D node.
3. Move it up by half the height of the capsule32.

This ensures that when the CharacterBody3D is positioned on the floor, the capsule extends upward from that point, simulating a character standing on the floor.

Visualizing our player characterJump to 21:48

If we run our game now, we… still can’t see our player character. That’s because collision shapes are purely functional; they exist for physics calculations but don’t have any visual representation in the game itself.

What you see in the editor (the wireframe outline of the capsule) is just an editor “gizmo” to help you visualize and position the collision shape. That’s not what players will see when they play the game.

Collision vs. Visual

It’s important to understand that a character’s collision shape doesn’t have to match its visual appearance exactly. In fact, it’s common practice in game development to use simplified collision shapes that approximate the character’s form.

This separation serves multiple purposes:

• Performance: Simple collision shapes are more efficient for physics calculations.
• Gameplay: You can make collision shapes slightly smaller or larger than visuals for better gameplay feel.
• Animation: The visual character can animate freely while the collision shape remains consistent.

Let’s add a simple visual representation for our player. We could use any 3D model here, but for simplicity, let’s use another CSG shape.

1. Select the CharacterBody3D node
2. Add a child node, you can use any CSG shape like another CSGBox3D or a different shape, like a CSGCylinder3D
3. Once you’ve added the shape node, select it and adjust its size in the Inspector to fit within the outline of the capsule33

This simple box is just a placeholder for now. In later episodes, we’ll replace it with a proper 3D model and animations. The beauty of this approach is that we can swap out the visual representation without affecting the physics and controls!

Sprucing things up with some colorJump to 23:06

Our scene is coming together, but everything is a bit… bland. Let’s add some custom materials to our player and floor to make them visually distinct and more interesting than just plain white boxes.

Materials in Godot are resources that define how a surface looks - its color, reflectivity, texture, and other visual properties34. We can add materials through (you guessed it) the Inspector panel.

Select either CSGBox3D node (our floor) or whatever CSG shape node you used for the player. In the Inspector panel, look for the Material property and click on it to bring up the dropdown, then select New StandardMaterial3D.

Once you’ve created a new material, you’ll see a variety of properties appear. The only one we really care about right now is the Albedo35 property, which controls the base color of the material.

Material Options

Although we’re keeping things simple for now, you can also adjust other properties like:

• Roughness: Controls how shiny or matte a surface appears. Lower values (closer to 0) make the surface more reflective and shiny, while higher values (closer to 1) make it more matte.
• Metallic: Determines how metal-like a surface is. Higher values create that characteristic metallic sheen. Typically we just use 0 when the surface is not made of metal and 1 when it is.

These properties are part of a system called “PBR” (Physically Based Rendering), which simulates how light interacts with materials in a more realistic way. We won’t focus much on this for our retro-styled game, but it’s commonly used in modern games.

Try creating different materials for your floor and player. For example, you might make the floor a dark green (like grass) and your player character a bright blue or red to stand out clearly against the environment.

Getting our player moving with some codeJump to 25:01

We’ve created a player character and a small environment, which is a good start. But a static scene isn’t much of a “game” yet. To make our creation interactive, we need to add our first bit of code.

In game development, we use code to drive custom functionality or “behavior” — it’s what makes things happen in response to player input or game events. In Godot, code is stored in files called “scripts.”

Each script file has an extension (the part after the dot in the filename) that indicates what programming language it uses. For GDScript, which is Godot’s built-in scripting language, we use the .gd extension.

We can quickly create a script and attach it to our player character in one fell swoop. Right-click on the CharacterBody3D node in the scene tree and select “Attach Script” from the context menu.

This opened the “Create Script” dialog, which allows us to set up our script. Here’s a breakdown of the options:

• Language: Leave this as GDScript (if you downloaded the .NET version, you’ll also see C# as an option)
• Inherits: This shows which node type our script is extending. Leave it as CharacterBody3D for now.
• Template: This is where things get interesting! Godot offers templates that generate starter code for common tasks. We want to use the CharacterBody3D: Basic Movement from the dropdown to get a head start.
• Path: Let’s create a dedicated folder for our scripts. Click the folder icon, create a new folder called “scripts”, and save your file as “player.gd” inside it.

Click “Create” when you’re done, and Godot will generate a script with basic movement functionality.

1extends CharacterBody3D
2
3
4const SPEED = 5.0
5const JUMP_VELOCITY = 4.5
6
7
8func _physics_process(delta: float) -> void:
9	# Add the gravity.
10	if not is_on_floor():
11		velocity += get_gravity() * delta
12
13	# Handle jump.
14	if Input.is_action_just_pressed("ui_accept") and is_on_floor():
15		velocity.y = JUMP_VELOCITY
16
17	# Get the input direction and handle the movement/deceleration.
18	# As good practice, you should replace UI actions with custom gameplay actions.
19	var input_dir := Input.get_vector("ui_left", "ui_right", "ui_up", "ui_down")
20	var direction := (transform.basis * Vector3(input_dir.x, 0, input_dir.y)).normalized()
21	if direction:
22		velocity.x = direction.x * SPEED
23		velocity.z = direction.z * SPEED
24	else:
25		velocity.x = move_toward(velocity.x, 0, SPEED)
26		velocity.z = move_toward(velocity.z, 0, SPEED)
27
28	move_and_slide()

This code might look intimidating if you’re new to programming, but don’t worry! We’re going to break this down in future episodes as we teach you how to read and write code yourself.

Jumping between viewport modesJump to 27:58

When you create a new script using the Attach Script option, Godot automatically switches you to the script editor so you can start editing your code right away. But what if you want to go back to working on your 3D scene?

Godot organizes its interface into different “modes” that you can switch between using the tabs at the top of the main viewport.

2D Mode

This mode is for working with 2D elements, which includes UI controls. If you’re creating a 2D game or working on some kind of UI (like a menu or HUD), this is where you’ll do that.

3D Mode

This mode is for working with 3D objects and environments. This is where we’ve been so far, and where you’ll spend most of your time when building 3D levels.

Script Mode

This is Godot’s built-in code editor. This is where you’ll write and edit your scripts, and it’s a powerful tool for coding in GDScript (but not as useful for other languages, like C#).

Asset Library

This is a marketplace where you can find and download assets made by the community. Th includes pre-made assets and plugins that extend Godot’s functionality.

Quick Script Access

Notice the small “scroll” icon next to our CharacterBody3D node in the scene tree? That indicates the node has a script attached to it. Clicking this icon is a quick way to open and edit that script!

You can also see which script is attached to a node by scrolling to the bottom of the Inspector panel when the node is selected.

As your projects grow more complex, you’ll find yourself frequently switching between these modes. The 3D view for building your environment, the Script editor for writing code, and occasionally the 2D view for creating UI elements.

Testing our first scriptJump to 29:02

Let’s see our code in action! Hit the Play button to run the game and… wait, what’s happening? Our player character is falling through the floor!

This is happening because our script is doing exactly what we asked it to do. If you look at the code, you’ll see these lines:

8func _physics_process(delta: float) -> void:
9	# Add the gravity.
10	if not is_on_floor():
11		velocity += get_gravity() * delta

Our script is applying gravity to our player, causing it to fall downward. The problem is that our floor doesn’t actually stop the player from falling through it yet.

What’s delta?

You might notice the * delta part in the gravity calculation. This is a common technique in game development called “frame-rate independence.” The delta value represents the time elapsed since the last frame, ensuring that our physics calculations work the same regardless of how fast or slow the game is running.

Back in the early days of computing, games were often tied to the computer’s clock speed, which is why some old games run super fast on modern hardware! We’ll dive much deeper into this concept in future episodes.

Stopping our player from phasing through the floorJump to 29:34

To fix our falling problem, we need to make our floor solid by giving it proper collision properties.

The reason we’re falling through the floor is because our CSGBox3D doesn’t have any collision properties yet. Just like with our player character, the visual representation of an object and its collision shape are two separate things in the world of game development.

There are a few different types of nodes in Godot that integrate with the physics engine, each serving different purposes:

• CharacterBody3D for player-controlled characters (what we’re using)
• StaticBody3D for non-moving objects like floors, walls, and other environmental elements
• RigidBody3D for objects that should realistically react to physics (like a bouncing ball or a movable crate)

One approach to fix our floor would be to add a StaticBody3D node as a child of our floor, then add a CollisionShape3D as a child of that. Then we would configure the collision shape to match our floor’s dimensions.

But that’s a lot of work, especially if you’re building a full environment with many CSG shapes. Fortunately, Godot provides a simpler solution.

Just select your CSGBox3D floor node and look in the Inspector for the Use Collision property. Enable this checkbox, and Godot will automatically generate a collision shape that perfectly matches the visual representation of your CSG shape.

Now when you run the game, your player should stand firmly on the floor instead of falling through it. Try moving around with the arrow keys (we’ll customize these controls in a moment) and you should see your character sliding across the floor!

Solving a render bug in GodotJump to 32:59

Windows

This section primarily applies to Windows users experiencing specific rendering issues. If you’re on macOS or Linux, or if your game is running fine on Windows, you can probably skip this section.

It may be shocking to hear, but nobody’s perfect - and since software is written by people, bugs exist everywhere. They can be found in games, game engines, and even your operating system.

While working on this episode, we encountered a visual glitch on Windows that appears to be related to the “Vulkan”36 rendering backend that Godot uses by default on Windows. The issue caused strange visual artifacts when running the game.

The solution was to switch from Vulkan to DirectX 12 (D3D12). If you’re experiencing similar visual glitches, here’s how to change the rendering backend:

1. In the top left corner of the editor, open the “Project” menu
2. Select “Project Settings”
3. In the search box, type “rendering” to filter the settings
4. Look under the “Rendering” section for “Driver/Rendering Method” or “Rendering Device”
5. Find the “Driver: Windows” option and change it from “Vulkan” to “D3D12”
6. Click “Apply and Restart” for the changes to take effect

This change only affects how Godot renders your game on Windows. The game itself remains the same, and this won’t affect how it runs on other platforms.

Debugging Tips

If you encounter other visual glitches or performance issues:

• Try different rendering backends
• Update your graphics drivers
• Check the Godot issue tracker or forums to see if others have encountered similar problems
• Consider that it might be something specific in your project’s configuration

Game development often involves troubleshooting issues like these, so developing your debugging (aka Googling) skills is super valuable.

Customizing our movement inputsJump to 34:00

Currently, we can move our character using the arrow keys because that’s what the template script uses. However, most modern PC games use the wasd keys for movement, which many players find more comfortable and intuitive.

Rather than directly hardcoding specific keys in our scripts, Godot uses an “action” system that creates a layer of abstraction between physical inputs and game behaviors. This lets us:

1. Define meaningful action names like "move_left" instead of referring to specific keys
2. Assign multiple input methods to the same action (keyboard, gamepad, etc.)
3. Allow players to customize their controls without changing all of our code using that action

Let’s set up our own custom movement actions by opening up our Project Settings window, which can be found under the “Project” menu in the top left corner of the editor window37. Once there, click the “Input Map” tab at the top of the window.

Now we’ll create our own custom movement actions:

1. In the “Add New Action” field at the top, type "move_forward" and click “Add”
2. Repeat to add "move_backward", "move_left", and "move_right"
3. For each action, click the button next to it and select "Key"
4. Click the “Listen” button and press the appropriate key:
   • w for "move_forward"
   • s for "move_backward"
   • a for "move_left"
   • d for "move_right"

Controller Support

You can also add gamepad support by clicking the ”+” button and selecting “Joy Axis” or “Joy Button”. This lets you map analog stick movements or controller buttons to the same actions.

When mapping analog sticks, pay attention to the axis number (usually 0 for left stick X, 1 for left stick Y) and the direction (positive or negative).

Now we need to update our player script to use these new actions instead of the default ones. Open the script editor and replace line 19 with what we see below.

var input_dir = Input.get_vector("ui_left", "ui_right", "ui_up", "ui_down") 
var input_dir = Input.get_vector("move_left", "move_right", "move_forward", "move_backward") 

When you run the game now, you should be able to move your character using the wasd keys instead of the arrow keys.

Attaching the camera to the playerJump to 37:23

The final piece of the puzzle for this episode is making the camera follow our player as they move around. In a future episode, we’ll implement a more sophisticated camera system, but for now, let’s go with the simplest solution.

In Godot, when a node is a child of another node, it inherits the parent’s transformation. This means if the parent moves, rotates, or scales, the child will follow along. We can use this behavior to make our camera follow the player.

To do this we just need to go to the scene tree panel and drag the Camera3D node onto the CharacterBody3D node. This makes the camera a child of the player character.

You’ll notice the camera’s icon in the scene tree is now indented under the CharacterBody3D , indicating it’s a child of that node.

Camera Positioning

You may need to reposition the camera relative to the player. Since it’s now a child of the CharacterBody3D , its position is relative to the player, not the world.

When you run the game now, the camera will move along with your player! As you walk around, the camera maintains its relative position, giving you a consistent view of your character and the surrounding environment.

This simple parent-child relationship is one of the fundamental concepts in Godot’s scene system, and we’re going to use it constantly as we build more complex game elements.

Closing thoughtsJump to 38:30

Congratulations! You’ve officially started your game development journey and have come to grips with some of the essentials for working with the Godot game engine!

If you made it this far, you should have a basic understanding of how to navigate the Godot editor, create and manipulate nodes, and write some simple code to get your player character moving around in a 3D world.

We’re already hard at work on the next few episodes, so hopefully you enjoyed this one and won’t have to wait too long for the next one. If you have any questions or feedback, feel free to leave a comment on the video or find us on our Discord .