In this video, we're going to discuss
how we organized the final game project files
and how you want to organize your own games in general.
A game like this is going to take lots of files.
You're going to need need to browse the game's code and change it many times.
You want to split it into folders and files that make sense,
so that after six months of development, after one year,
you can still find the scripts that you need to fix.
You can find where is the code for pickups for the character,
et cetera, easily
and that everything makes sense.
The way we approach it at GDQuest,
is we typically have one directory for each scenes.
Everything that has to do with the interface is in the interface folder,
or for a given game system or standalone component.
For example, everything that's player-controlled
goes into this robot directory, that's the player's robot.
Why? Because this one can work on its own.
We can run it into a scene with the spells, with the movement.
We don't need a level to test that everything is working.
When working on the robot,
we put all the files in there, which we can easily drag and drop
into the inspector, and so on.
That's the robot.
There are cases that are more complex, like the mobs in this game.
The player has enemies that are those mobs.
And in there, you will see multiple subdirectories.
In this case, each of the mob inherits from a base scene
and script, Mob.gd.
In those cases, we will typically put the base class,
the mob class here, into the main directory mobs.
And for every entity that inherits from it,
we make as dedicated directory.
For example, the sword here.
The reason we do that is that typically, mobs will tend to grow.
At first, you will just have one or two sprites probably,
then you will start to add visual effects,
you will start to add unique sounds to each of the mobs,
those kinds of things.
And so the number of files in the directory may grow.
We keep one directory for each of the mob.
The shield, the dummy, the bomb, etc.
This makes them fairly easy to browse.
You may notice that you have a couple more files in this directory.
This is everything that might be shared by various monsters.
Whenever something's shared, we move it up a directory.
In this case, it's the damage sound, the death sound for monsters,
and this cannon which is a gun that can shoot the bullets
that we have in a separate folder.
In this game,
both the player can shoot projectiles using spells,
and the mobs, thanks to this cannon scene that we have here.
We decided to have the bullets, the projectiles, as a separate directory.
We decided that the mobs, the player could use them,
but also you could use them as part of a trap.
For example, if you want to walk on a pressure plate that triggers bullets.
Next, we have the pickups that the player can grab.
Those allow you to get a spell,
but you can also regain health, and you could use them
for temporary boost for the player or something like that.
It's a mechanic of its own, which is why it has its own folder.
The props are not too important there
all the small things that can be shared by the levels.
You have the shadow that both the monsters and the player use,
the sky for the background.
It's everything that didn't fit in another directory.
One thing we do sometimes in our projects,
instead of calling this props, we'll call this common.
And those are all the files that we intend to reuse
about anywhere in the game.
This could be generic sounds, generic sprites or reusable scripts.
There's one last folder that's very important in this project,
it's the room's directory.
This one has all the procedural levels' rooms,
as you can see.
Each of them extends from base room.
Because each of the room is just a scene and it's self-contained,
we decided not to make extra subdirectories for them.
They are all next to the base room,
and we can use all of these in our procedural level generator.
We also have the test room in there that we use only to test the game
and for development, there we just put pickups,
or put spells, enemies,
just to test that the mechanics are working.
You can see how we have a fairly flat folder structure for this project.
Meaning that you have quite a few folders at the root of the project,
and you don't have too many subfolders.
This is something we recommend, it makes it easy to open the folders
and get a Godot sense for the code structure.
This is something we recommend over nesting folders too much.
That would be having the robot,
and then inside the bullets and the spells, nested into one another.
Because then it makes it a bit harder to browse your game files.
There are two more important things here.
First, we have folders
that directly represent our game structure.
We have bullets in the game, so we have a bullets' folder.
We have mobs in the game, so we have a mobs' folder.
And the related code is contained in there.
You have people who will use and recommend always the same structure.
Say they will have an interface folder, a level entities' folder, a player folder,
and those kinds of things, and they will use it for every game.
And I don't recommend that because it's not as clear
what the game is about
and where you will find all the files as this.
Bullets, user interface, mobs,
robot could be player or character, or something like that.
But pickups, room, spells,
it's pretty explicit where you will find the code,
the sprites, and the scenes,
for each of the game mechanic.