Making of Ogazuhl: Part 9

Attaching scripts to nodes

I will assume that you already downloaded and looked at the script “” from the tile movement Godot Project I posted on Opengameart.

ATTN: You may have tried to play the scene and found that Godot is throwing an error at you. That is because of me being sloppy and calling one function “rotate”, while the same function is “reserved” by Godot for rotating objects. An updated and fixed script will be provided at the end of this post.

Now is the time to copy it from that project into our Godot Project with the dungeon level. For example, put it into “scenes/dungeon/brunstom” folder. Then open the scene (“”test_room”), locate the camera node and select it.

On the right side of the editor, at the very bottom you will find “Script” menu, click to unfold it.


Then drag and drop the “” script into the “empty” slot.

NOTE: Pay attention to an additional set of parameters that appeared on the top part of the Inspector. Those came from the script, namely from exported variables. More on this later.

Defining Actions

If you play the scene, you will end up with the camera view of the dungeon, but it won’t respond to the keyboard commands. When you look into the script you will see that the commands/actions that the script expects are

  1. “ui_step_forward”
  2. “ui_step_back”
  3. “ui_step_right”
  4. “ui_step_left”
  5. “ui_rotate_left”
  6. “ui_rotate_right”

These actions are defined and mapped to keyboard keys in the project settings. Go to Project -> Project Settings and click to the “Input Map” tab. There you may see a list of available actions and keys attached to them. There are no action from the list above and will fix that now by adding new actions.

In the Action field enter “ui_step_forward” and click “Add”


At the bottom of the action list a new action will appear with the name “ui_step_forward”. To associate with it  keyboard keys, controller buttons or other input device signals press “+” on the right, then select type of the input device (“Key” for our case) and then press keyboard key you want to correspond to “step forward” command. Let’s use WASD scheme and press w (no need to Shift key).


Repeat the steps for the remaining 5 actions, assigning S to step back, A to step left, D to step right, Q to rotate left and E to rotate right. Then press Close.

Now if you play the scene you will see that camera responds to your commands and you can move around the dungeon. Congratulations!

Adjusting Movement Parameters

The parameters that control camera movement come from script, with some of the most important ones exported and shown in the top of the Inspector.movement

First of all, let’s fix the size of the step from 3.7 to 3, since this is the size of the floor tile. Second of all, let’s reduce the Move Period to 0.5 to make the camera move faster. Save and play the scene.

The default values for these parameters are defined in the script, namely in the part where we “export” variables:


If we change them here to more sensible values, we won’t have to adjust anything in the Inspector.

I suggest you play with parameters, look at the script again and perhaps read online documentation for Godot about scripting.


The scene with the test room and camera with the movement script (correct and tested version) can be downloaded from here.


Making of Ogazuhl: Part 8


Before we move on to the scripting/animating part of the game, I want  to let you, the reader, know that

  1. I am not a professional programmer.
  2. I am not an expert in Godot. On the contrary, for me Ogazuhl was first of all a learning experience.
  3. I am not a professional artist or game designer.

Given that, take all my advices with a grain of salt. I may not provide the best solution or way to implement a feature in a game.

Animation and Scripting in Godot

Both scripting and animation part of Godot Game engine are quite flexible and relatively simple. In some cases it is possible replace one with another.

Say we want to move an object in a game when a button is pressed. We can create an animation for that object and call that animation when the button is pressed.

Alternatively, we can write a script that responds to the button press and changes the object’s position in time explicitly.

A nice introduction into scripting in Godot is available on the official site.

Moving Player Around

The approach I chose for Ogazuhl is based on explicitly controlling the object (e.g. camera). The reason for that is that before Godot I tried different game engines and it is easier to port code/algorithm than an animation.

The idea behind tile-based motion is sketched out in my post here.

The more or less complete code and Godot 3 – ready scene is available on my Opengameart submission page.

What I do recommend is downloading the scene, fire it up in Godot. Play around and read the code trying to understand what it does. (Look for “” script in the “scripts” folder)

Next time I will go through it and comment.


Making of Ogazuhl: Part 7

Preparations for Moving Around

The previous part guided you through the creating of a simple test dungeon room:


Now it is time to add a camera that will show the room during the game.

With the “test_room” root node selected, press “+” Add Node and search for Camera. Then double click on it and it will appear in the editor, most likely in the spot you did not want it to be.

Using the translation gizmos (the set of reg-green-blue axes) shift it up (it should be at the origin with x=0 and z=0 by default) along Y-axis to a reasonable height.


With the camera selected, click on the “Preview” check box in the top left corner of the 3D view to see what Camera will show during the game. Alternatively, press “play scene” button, right of the “stop play” icon in the top right part of the Godot Editor


When a new window appears, it must show part of the dungeon room that the Camera is capturing.

While the scene is running, you can press whatever buttons on the keyboard, but camera won’t move, since we did not tell it how to respond to the user input. This will be our next step — scripting.


You can grab the test room with the ceiling and the columns and the camera here.

Making of Ogazuhl: Part 6

Godot Scenes

Scene is a powerful way of building complex game elements from well-controlled smaller elements. Good introduction into the roles of scenes is provided in the official documentation. We will use already available scenes — created during steps 1-5 — to build a dungeon room.

In the Godot Editor’s menu go to “Scene->New Scene” and when an new empty scene open choose the root node to be 3D Scene. Let’s save it immediately as “test_room.tscn”. It is a good idea to rename to top 3D node accordingly (i.e. test_room).



Under the Scene tab of the scene tree, above the “test_room” node, click on “+” sign and look through different things (nodes) Godot offers by default. There are LOTS of them, but definitely not enough to make every game.

This is why we can add other scenes as elements of the tree in our new scene. Neat!

Click on the “chain” sign (on the right of the “+” sign) and in the Search line enter “floor”, then select “brunstom_FloorTile01.tscn” and click open. The “test_room” node will have a child — “Scene Root”, representing the floor scene. We should have renamed the scene root of the floor scene to a more meaningful name. Do it as an exercise.

Duplicate and Snap

A quick way to build a room is to start with a single floor tile and then duplicate it many times. Each copy then should be moved around. The good news is that each floor tile is 3×3, and the default units of length in Godot is 1m. This allows us to use “Snap Mode”. To activate it press “y” button while mouse is in the 3D view window of the Godot Editor. You will notice  “magnet” icon going blue:


Select a floor tile node in the scene tree and press Ctlr-D to duplicate, then in the main window drag the gizmo’s arrow where you want the new tile to go. Repeat as many times you think you need.

NOTE: You can select a GROUP of elements in the scene tree and duplicate them all at once!


(HINT: If you go into “View” menu on top part of the main 3D view and uncheck “View Origin” and “View Grid” you will end up with similar image is above).


Let’s stay organized and not pollute the test_room node with ALL elements at once. Instead, select the root node (top element of the scene tree — test_room) and add a standard Godot Spatial node. Remember — this time it is “+” button, not “chain”.

Rename the new node to “floor”, then select ALL floorTile0X elements (hold Shift) and drag them onto “floor”. Alternatively, right click to open a menu and select Reparent. Choose “floor” and click “Reparent” again.


In a similar way we create walls. But first, lets create “wall” spatial node under “test_room” to stay organized. With this node selected, press “add scene (chain icon)” and search for “*wall01.tscn” scene.

You will see that it is placed not in the correct place and moving it with snap does not align with the floor. We can fix that if we adjust the Transform of this newly added scene.

In Inspector unfold “Transform” and change “z” to -1.5. Remember that our floor tiles are 3×3, while the wall tile falls right in the middle. So we need to move it 0.5 of floors size — 1.5.

Again, you may see that wall node has not the best name — “Scene Root”. It is always a good idea to name the root node of the scene properly. At his points you know how to fix that.

After you duplicated a couple of wall and aligned them nicely, using snap mode, you will need to duplicate one more wall and rotate it 90 degrees around Y axis (this is the “vertical” axis in Godot). Then adjust its transform by a step or two of 1.5 and then duplicate again.

After all manipulations we will have the minimalist “floor”+”walls” dungeon room.


At this point you should be able to add ceiling to the room, and — with some manipulations of the Transform — columns.

Next we need to add camera or something, which can move around.

Making of Ogazuhl: Part 5

Godot Import Options

Once the **.dae file is detected by Godot Editor it is automatically imported. If you take a look inside the folder “scenes/dungeon/brunstom/floor” you will find three files there: **.dae, **.material, **.import.

The **.dae file is the one we exported from Blender. **.material is the Godot Material that is created based on **.dae (and therefore **.blend) file. The third file with the **.import extension is the text file that Godot uses internally to keep track of various parameters used to import a resource (3D model in this case). This file is not shown in the Godot Editor.

An extensive list of import options is explained in official documentation. Here I will quickly mention the most relevant ones. But first, before changing the import option for the 3D model, let’s copy the missing texture image into the folder “scenes/dungeon/brunstom/floor”. Godot will detect a new file and the next time you visit Godot Editor it will import the image.

Select the “brunstom_floorTile01.dae” file in the Editor and then select the “Import” tab  in top left part.


In the “Animation” section uncheck the box, as we do not have any animation for this model. If you keep it checked, the model will have an empty animation player attached to it every time you would use it. When done, click “Reimport”.

Handling Material

Select “brunstom_floorTile01.material”, and then either double-click on it or right click and choose “Open” in the context menu.

On the right and Inspector will appear with LOTS of settings for the material of the floor. Only two will be of importance to use now: “Albedo” (that is regular color, diffuse color) and “Roughness” (it controls how glossy the surface of the object is).

Set roughness to the maximum (1.0). For Albedo, locate the texture image in the Filesystem tree on the left side and drag and drop into the “Texture” slot of the “Albedo” section.


Floor Scene

Now we will create our first proper Godot resource which we will be able to re-use anywhere. Double click (or right-click and then Open) the “brunstom_floorTile01.dae” file. Godot Editor will try to open a new 3D scene with the floor tile in the center.

When the editor asks you how to open the resource, choose “New Inherited” since we do not want to mess with the DAE file, but instead use it to create a new resource



All going well, you will have a new scene that looks similar to what you saw in Blender “Shading” tab:


Save it a new scene in the proper folder. (Ctrl-S) Here is the file system structure with our first “bundle” of resources all in one place:


Image Import Parameters

One final step is adjust the import parameters for the floor texture. The same options should be used for the walls and ground textures.

Select the image resource in the editor. Then select the Import tab in the top left part of the editor. Locate the “Anisotropic” option and check the box and hit “Reimport”

According to the official documentation: “When textures are near parallel to the view (like floors), this option makes them have more detail by reducing blurriness.”

I checked, it does help indeed.

Congratulations, we made our first 3D scene in Godot.


If you repeat the steps outlined in the parts 1-5 for the wall, ceiling, and column models, you will have a basic set of scenes from which we can assemble a decent dungeon level.

You can download all of the scenes ready for Godot here.


Making of Ogazuhl: Part 4

Modifying Blender Model

The floor of the dungeon we will build will have a size of 3×3 meters. The model will have a single texture for color (so called diffuse texture or albedo texture) and a single material.

It is also a good practice to name everything (meshes, materials, textures) in a telling and consistent way.


In blender, with the floor tile selected enter dimensions of the model to be  3.


When you change the size the scale will change and we must apply new scale to avoid weird behavior when we import the model. So, in menu

Object -> Apply -> Scale.

Object Name

In the object tab change the name to “brunstom_floorTile01”, same for the mesh.


In the material tab change the name of the material to “brunstom_floorTile01”.

We will also use the new approach to materials, which is becoming default in Blender. With the material selected click “Use Nodes” and in the “Surface” drop-down menu select a “Diffuse BSDF”.


(In the figure above note the scale is 1.0, size is 3, in the scene tree — top right — the object name is “brunstom_floorTile01”, same as the material. Material type is “Diffuse BSDF”)

UV unwrap

The model is already UV unwrapped, but we must check that it is acceptable and the image for texture is there. In the top part of Blender window locate “UV Editing” tab and click on it. The window will split into to, with the left part dedicated to UV editing. Make sure that the correct viewing mode is selected for the left part (see bottom left corner of the window):


In the right side of the split select the model and press Tab to go into “Edit mode”, or select this mode in the menu in the bottom part of the right side. All going well, you will see the outlines of the model in the UV window:


We need to “assign” an image to the UV unwrap. In this model the image has been already assigned so we just need to select it from the list. The list appears when you click on the picture button in the center of the left window (on the left, next to “+New” button)


When you do that the UV window will show both the mesh outline and the image. You may need to zoom out a bit to see the whole picture. If the way the mesh is unwrapped and matches the image looks OK to you  then you can proceed with the final step — checking how the model looks when textured.


In the top part of the Blender window, there are several tabs, including “Shading”. If  “Shading” is not there, do this:

  1. Make sure that you are not in the editing mode.
  2. Find the [+] sign at the right edge of the tab area, click and select “General->Shading”

You will end up in a “Shading” tab, which looks complicated but we only need the center two windows. Right now the “Diffuse BSDF” shader/material has no image assigned to it and the floor model is grey.

In the top menu of the bottom window select “Add->Texture->Image Texture”, and place the new window not far from the “Diffuse BSDF” window.

NOTE: you may want to zoom in the area of the lower window and pan around, holding the middle mouse button.

In the “Image Texture” window click on the “image” icon (left of “+ New” button) and select the “floorTile01.png”

Finally, connect the yellow circle of the “Image Texture” window (Color output) to the yellow circle of the “Diffuse BSDF” window (Color). Then zoom in the top window to see how the tile looks.


It is time to save the file and all the changes (actually, saving frequently is a good idea, to avoid loosing changes if Blender crashes). Let’s save as “brunstom_floorTile01.blend”.


WARNING: As of now, Blender 2.8 complains about “Better collada” plugin is not compatible with this newest version of the program. I assume  it will be fixed soon, so trying to install it is recommended anyways.

Make sure you have installed the “Better Collada Exporter” plug in and that it is enabled.

We will do a simple export (for more advanced and detailed instructions look here).

Go to “File->Export->Collada”. In the saving menu I prefer to uncheck exporting animation and check “export only selected” (make sure the floor tile was selected before exporting).


Copying Collada Model Into Godot

Now you can copy the model into the designated folder (“scenes/dungeon/brunstom/floor”).

When you open your project, Godot will automatically import the model and you will see the model and new material “brunstom_floorTile01.material”.


Next time we will check how the import went, adjust some parameters and will add textures.

Making of Ogazuhl: Part 3

Starting Out

Having installed Godot, Blender, and GIMP we are ready to start. Next thing is to create a new Godot Project. It is well explained here, so I will omit the details.

By default Godot Editor opens in 3D view and suggests that you create a new Scene, showing a choice in the left side of the window.


Even small projects can quickly become messy, unless you keep your stuff organized. Official documentation have some suggestions for your project organization. In short, try thinking which resources should go together and try to keep them in the same folder. This way they will be “packaged” or “bundled” in a natural way. Most likely these resource in a bundle will be part of the same scene.

For example, if you will have an treasure chest in your game then you may place it’s 3D  model file in the same folder as textures, scripts that define it’s behavior, and possible sounds. It will make it easier to locate all chest-related resources, and also will make it easy to copy the “package” into another project, if needed.

With this in mind let’s create a folder in our project (I will call the project Ogatut) where we will have be storing all our scenes. The first scene that we will create will be a dungeon floor, so the resulting folder structure will be like


Note: You can create a “scenes/dungeon/brunstom/floor” folder structure using File Manager of OS and Godot will automatically adjust project structure.

Importing a Model

There are tons of Blender models on the web and kilograms of good ones. However, most likely they do not directly fit into your project for one reason or another: too many polygons, not textures, ugly UV unwrap, scale is all wrong, model uses tricky modifiers etc. Or you may need only small part of a large model, as we will need now.

This is why it is important to be familiar with Blender to a certain extent. Some time ago Blender made a leap forward in terms of its rendering engine, user interface and the way the materials are handled. It means that if you find a model made in older version of Blender you will most likely have to adjust it before exporting to Collada.

Let’s start with a ZIP file with Brunstom dungeon models. If you find a “floor/models/floorTile01.blend” file and open it in Blender you will end up with a gray square staring at you:


I suggest you play around with it. Check its dimensions, scale, material assigned to it. Explore which textures are available:


Next time we will adjust the settings to our needs and export the model for Godot.

The Making of Ogazuhl: Part 2

Getting Started

This post is for people who would like to follow along the development and would like to tinker with the resources.

This is not an easy task — but not a terribly hard one — since it requires some familiarity with Blender, GIMP, Inkscape and Godot. It is recommended to be proficient enough in those tools to be able to open and at least slightly modify the work done by others. There are plenty of resources for each of the mentioned programs.

All programs are available for GNU/Linux, Windows, and MacOS.



If you are eager to get started, and want to play around with the models of dungeon elements you can go to my Blendswap page and download the “Brunstom” dungeon set. It contains everything you may need to assemble a complete single level of a dungeon (there are no stairs there).

As is, the set is not super useful for Godot, as this is a signle **.blend file. The game engine is more comfortable working with Collada file format, and it is better to import one element by one.


Godot and Blender

Godot and Blender are friends. However, you can not just drag and drop blender file into Godot Editor and start using a new resource. You have to do some preparation work first, as nicely explained here.

After you copied the required files into a plugin folder of Blender, you will have a way to export Blender models into Collada format (from **.blend into **.dae) which Godot will happily pick up. Specific example will follow when we start creating a dungeon in a Godot Editor.

Installing Blender, GIMP, and Godot (Inkscape is optional) and setting up Blender to work with Collada exporter from Godot is pretty much all set up you will need.

Of course, you will need to down load the models for the dungeon, as mentioned earlier.

This will get you started.

The making of Ogazuhl: Part 1


Recently I finished my first 3D game, called Ogazuhl (see this page). It is a rather small game, developed in 30 days for a game jam. Most of the resources — some of them mine, some made by other members of OpenGameArt site — used to make the game were already available. This allowed me to focus on learning how to use the game engine Godot.

I want to share some knowledge of this engine that I gained while developing the game. Hopefully, someone will learn a thing or two from my experience.

There are a plenty of tutorials available on Godot. What my posts will cover is the development of an actual game, including making game design decisions.

Why Godot?

It may seem that there are many free/open source game engines available today. Some are purely 2D, some are for 3D, some both. As of now, Godot stands out due to it’s rich set of features, pretty advanced editor, good support of 3D models made in Blender, decent documentation, easy scripting language, to name just a few reasons. I can not say much about it’s performance or cross-platform support (tested only Windows and GNU/Linux — looks good in version 3.1)

If you are looking for a game engine to get started with game development I can say that Godot is your safe bet. Later, you may want to move to Unreal’s of the world, but as a first step it definitely will do. It did work for me.

On 3D.

Ogazuhl is mostly a 3D game (there is a 2D part — turn based combat). In some sense it is a side-project coming from my Dungeonmore effort. I wanted to create a framework+resources for a canonical grid-based dungeon crawler for a while. For that past several years I have been working on my Blender skills, making resources which I then shared on OpenGameArt and Blendswap. This is still very much a work in progress, but I am happy with the results.

Although Ogazuhl is a 3D game, this will not be the focus of my post. The main goal is to demonstrate how a game — a simple one — gets made.