Creating a game with Godot Engine - Ep.2 - Project organization
In this second article we will start to get into details, starting with project organization. We will see a way to keep your project clean and readable as it grow, and make it simple to use with a Version Control System (VCS) like Git or Mercurial. (source code)
Disclaimer: the following article represents one way to do it and, it may not be the best way. Please adapt this technique using your best judgement.
Starting with a good and logical organization will help you grow you project faster and easier. Faster because when you are in the creation process you don't want to loose time to understand what goes where. Easier because when you want to implement a new element you can reuse the same logic as other elements of the same category.
The basic of project organization is having a well designed folder structure, and most importantly, a structure that you understand. The following tree list is an example of structure simple enough that most people should be able to start with:
<root>: contains all the folders and files of the project. Should be named after the project name. Should be the root of your local VCS repository, if you choose to use a VCS (highly recommended, with a service like Github or Bitbucket).
- assets: contains all the original medias (sprites, textures, 3D models, musics, sound effects, ...) before importing them into Godot as resources. It is important to separate this from your source code for many reasons: most of software have their own project files that you have to export first, like PSD to PNG; Godot has its own importing formats, like for textures; Some media are build from many files you would want to store, and version, separately. It is also a good idea to split it into subfolders per media type and/or media, example: /assets/musics/intro-music/ or /assets/sprites/player/. In the demo project, you can see an Inkscape project file called master-1.svg which is used to export multiple PNGs. I didn't used subfolder because it is a very basic project.
- releases: contains your project as it will be distributed to the end users. It is the export result of your Godot project. Should contains subfolders for each platform you are planning to support.
src: contains the source code and resources of your Godot project. Should be the root of your Godot project, i.e. contains the "engine.cfg" file. The following subfolders are categories of entity where you will store the different element of your project. They should cover most of the needs for a basic project.
- actors: contains an actor per subfolder. An actor is a "smart" entity, like the player character or enemies with some sort of AI.
- areas: contains an area per subfolder. An area is a static element which is used to create levels' map. For most of 2D games an area would be a TileMap.
- fonts: contains fonts used to display text in your project. It is a good idea to store them in one location to avoid duplication. Protip: try to limit the number of fonts you want to use.
- levels: contains a level per subfolder. A level is where you are assembling all the other elements to create gameplay.
- lights: the way 2D lights are working in Godot is texture based, so a good idea is to store those textures in one location to avoid duplication.
- objects: contains an object per subfolder: An object is an interactive entity, like a door or a chest. Most of the time, the interaction is done through an actor. An object is also something which can move around, like a ball.
- screens: contains a screen per subfolder: A screen represents a mode your project can be in, like main menu, settings or game. Splitting your project into screens is also an easy way to implement multiple User Interfaces (UI).
Once your folder structure is ready, you have to use it properly if you want it to be efficient. A good way to do it is to established a naming convention and a standard file structure for each element. In the following list, I will try to give you some hints and best practices to help you start on this topic:
- Global elements, like the project entry point or singletons, should be placed directly inside the src folder. This will be discuss more in details in the next article.
- When creating an element a subfolder should be added to the proper category and named after the element it contains, like player, ball_emitter or level1. Inside this subfolder you should create a scene and attach a GD script to this scene, in order to get the basic file structure to start implementing the element.
- It is important to use the same name when creating the element scene and GD script, like actor_player.tscn or actor_player.gd.
- It is a good practice to put the category inside the scene and GD script filename using this format: <category>_<name>.<ext>. This way when the project becomes larger, and multiple files are open in the scene editor or script editor, it makes it easier to keep track of what you are editing.
- It is a good idea to only use lower case and alphanumeric ASCII characters. Underscore, '_', should be used as a separator, no space. This way you insure a broader compatibility and possibly avoid some weird errors later on.
- If you want to have common features for elements of one category, you can create a GD script directly inside the category folder, using abstract in the name to remember that it is not to be used directly, like abstract_<category>.gd. Then using the inheritance feature of GD script, you can make each element of the category inherit from it using extends "../abstract_<category>.gd".
What is next?
In the next article we will speak about general considerations including, project settings, user settings, singleton and project entry point.
Written by Olivier on Thursday October 13, 2016comments powered by Disqus