• Introduction
• About this book
• What is Godot?
• Game examples
• Godot components
• Godot Architecture
• Variant and Object
• Nodes and scenes
• Resources
• Making the game
• Project setup
• Structuring the game
• Defining scenes
• Adding mechanics with GDScript
• Managing input
• Exporting games
• Enrich the game with effects
• Animation
• Particles
• Sound

Structuring the game

Godot is structured to maximize your team's efficiency. Every member can focus on one part of the game (interactions, graphics, sounds, etc.) without stepping on other members' toes. A particular effort is made to remove the programmers bottleneck.

Our game story will be simple: a bat will be flying but always falling. We need to help it reach the goal by pressing the space bar which help it go up. The problem is that there are obstacles in the city: buildings are a danger to the bat, and incredibly, even clouds. So when the bat hits one of those, it just loses (we could make it so that hitting an obstacle wouldn't kill but just make it fall a bit or lose points, but as a demo we keep it as simple as possible). When an obstacle is successfully passed, a point is added to the score. And it goes on until the bat loses (nobody is immortal but this bat can be, so if you play too well you might die of dehydration before the game stops).

Based on that description, we need some elements:

• a bat drawing,
• a building drawing,
• a cloud drawing.

Now that we have a project, we will need to populate it. In Godot, the main part of it can be summed up as creating scenes, putting them together, making element interact. So, the way we will work here is create a scene for each individual parts:

• it will help clarify the project,
• it will make elements more reusable,
• it will make elements easier to modify,
• it will give the maximum of liberty in the game structure, particularly to change game design principles if need be,
• as each scene is an independant file, there are less risks of conflicts, particularly relevant when using version control systems for collaborative work.

For that purpose, divide your game in little parts, as little as possible and define how they interact. For example, the game will need a world, which will be composed of several objects including a background and non-players elements, obstacles, enemies, etc.. Each of them may be created as a separate scene, which can themselves be subdivided depending on their complexity. The principle is: do more with less. Which drives to: reuse, reuse, combine. 

Our game will lead us to create a scene for each element that we need to manipulate:

• the bat,
• the building and clouds (apart in different scenes) and a scene to mix them up,
• a scene for points,
• a scene for the UI,
• one for the game level,
• and if required one for the splash screen and one for the game over.

Generally we will need scripts to implement basic functionalities in each scene:

• manage keys, mouse or joystick (here we will use keys),
• change bat position,
• die function,
• what it does when colliding,
• what it does when passing an obstacle.

Building and cloud

• spawn them,
• position them.

GUI

• display the points value,
• provide pausing and quitting functionalities.

This is a basis we can begin with.

 

Organizing your files

Godot relies on the filesystem to organise your assets, and you are free to use any directory layout. Here are a few ideas to guide you:

• Godot will detect any directory containing engine.cfg (even empty) as a game project,
• You can group together files related to a game level (e.g. level1, level2, boss1...) or alternatively by type (sprites, sounds, scripts, etc.),
• Paths are relatives; if you need to move files, you can use the recent Refactoring feature.