First time to use Godot and making from macro-level editor to managing screen flow


Hello, this is Creta.
This will be my first post since creating this project page.

To briefly introduce myself, I'm a C# programmer working with Unity.
I also have basic knowledge of web development and once briefly worked with RPG Maker MV.
One of my projects, DOWNFALLEN, can be played on my itch.io page.

I'm assuming you're familiar with the project information from the main project page.

Project Vision

This project was started with the hope of becoming the foundation for White Spirit, which will be my long-term vision.

White Spirit was created with Unity and had a somewhat established development environment for content creation,
but due to limitations in implementing physical mechanisms, I began to look into Godot, which is also a WYSIWYG tool but allows for changing the physics middleware.

The Project's Foundation?

This project focuses on the following vision:

  • Create a small and simple game since it's my first time using Godot
  • Focus on building an environment where desired content can be easily created (in-house tooling)
  • Test mechanisms that require user verification for White Spirit in the long term

So even after completion, I'm considering creating a version with experimental systems for White Spirit in the long run.


As this is my first time using Godot, I plan to write devlogs to document what I've learned. Thank you for your support.

Establishing a Content Development Environment for Project Stations

First, I decided to establish the foundation for a content creation tool that can easily add and manage macro-level locations called Stations.

To develop in-house tools, I needed to understand the characteristics of the Godot editor.


When developing addons to extend the editor, we use something called EditorPlugin.

It has a _has_main_screen() -> bool: function, and by inheriting and returning true, I learned that I could add an item representing my addon to the top.


The editor made it incredibly easy to create the desired UI layout using scenes.

This is because, as far as I know, the Godot editor is in the same environment as Godot itself, so theoretically, all nodes can be modified just like in the game.

There was no reason not to use it, so I did, and it's working well.


This is how I'm currently using it. The image shows some Korean text, but the left side is the Stations list, the right side is the Areas list within a Station, and the popup in the center is a right-click menu with an option to "Play from here..."

With the editor created, I needed to understand the game system, and further, the scenario flow, which is the core of the software, and establish an environment to manage the actual game flow.

Building the System Based on User Scenario Flow


Since games are ultimately software, I believe it's important to understand the user perspective scenario flow and build the system accordingly.

The image shows a simplified flow, with many parts omitted, but it gives you an idea of what it looks like.

First, I decided to group Bootloading and Loading together and create a system called LoadWorkerManager to handle all long tasks asynchronously and manage screen transitions for loading.

After building the system, I implemented bootload tasks for both production and play testing, anticipating the need to handle game play flow.

Then, I used the CommandLineParser package to process play test options through execution arguments, allowing desired preparations when entering commands in the command line execution.

Note that I mainly use C# when using Godot, except for tools.


I wanted to be able to prepare with desired start arguments when arbitrarily starting a play test from the tool.

I implemented this by directly inputting the editor/run/main_run_args option in the "Project Settings" as shown in the image, then triggering the play test through EditorInterface.play_custom_scene, and finally erasing the entered value.

It was seems to have worked as intended without any issues.

As soon as preparations were complete, I decided to create a loading screen using Godot's node-based shader development tool, Visual Shader.

I implemented screen transitions and created test LoadWorkers that randomly increase progress for testing.

I was pleased with how the transitions worked as I wanted.


The most impressive feature I found while using Godot's animation tools was the onion skin functionality.

I often think it would be great if Unity had something like this too.

With both shaders and direction completed, I implemented and tested basic LoadWorkers necessary for game start preparation.

Everything seems to be working well.


This concludes the first devlog.

In the next one, I plan to develop a SessionManager to track player's gameplay information.

This feature will include the ability to save/load items related to gameplay, and during testing, the goal is to enable quick save/load functionality.

I'll see you in the next devlog.

Leave a comment

Log in with itch.io to leave a comment.