Hi. I’m a game developer who has been using Godot for about 1–2 years purely as a hobby. I don’t have a portfolio yet, and I’ve never finished a full project — only a few small ones. Because of this, I’ve been wondering what the fundamentals of project management are.
One of the biggest questions I have is: what do professional developers do when they start a new project?
Personally, I usually start by creating folders for everything — organizing assets, scripts, and so on. Then I move on to game design, coding, and art. But when it comes to a project that’s meant to be released, I get confused about configuration settings.
Some people say you should handle all the configuration first and then build the game around it, while others say that’s the wrong approach. So, what do you do? Do you set up configuration first, or focus on game design before anything else? Or do you have a completely different workflow?
Usually you start with an idea then it can be mockup, concept art, documents, or pitching… You want to make it exist as soon as possible and solve as many problems as possible early.
So opening Godot is the last thing you want to do when starting a project, unless there are good reasons to start from here. There are no rules.
Making folders might be a bit too early because each game is different you might want a folder at the root named monster or spaceships just because it could be the main channel to enrich the experience you are building. I believe that’s why it’s common to see scripts and levels/maps at the root because it tends to be the main channels to enrich the player experience.
If you are not confident with art and/or design, or you don’t want to start with that (you just want to make a game that is complete)
I recommend trying making retro game clones; like snake, tetris or anything that speak to you and sounds reasonable.
Once you got a clone in hands, you can try to add, remove or change mechanics & art to see what happens.
Disclaimer: I haven’t made a single game in my life. But I have 20+ years experience as a professional software developer. So, this is a development-centric answer. I’ll assume that you have already figured out what you want to make, and now are getting to the “doing” part.
My advice is - first, get it off the ground. I don’t know with what you start (that’s probably a personal preference), but just get things moving and make the first files. Basic art, few lines of code, “hello world”, whatever. Give the project a starting point.
Then, when you have a few things set up and feel like it’s starting to go somewhere (like, after a days work or so), add what you have to a git repo and push it to Github or whatever (as a backup).
Now that you have git, you have safety and freedom. You don’t need to set everything up perfectly at the start, because git allows you to refactor and shuffle things around later, all the while knowing, that if you screw up, you can always rollback to a known good state. Commit often, push everything to remote.
Use branches if you feel like it - or don’t. Early in a project (and even later, if you work alone) branching isn’t really needed much. Branching mostly becomes useful when lots of stuff is going on at the same time.
And then, well - move along and do what makes sense. Most of the time you can’t predict what you’re going to need anyway. So instead of trying to gaze deeply into the crystal ball and providing for every possibility upforont, just embrace the fact that you can refactor later as needed.
I can’t even remember how I started my project in the slightest.
Just start with a simple design doc of how you want your game to play. Then, just start. There’s really no wrong way to open or start a project, honestly.
I actually started prototyping the feel for my current game first in Godot.
Then as I got more ideas, Id expand things bit by bit.
My one regret is not having structured my folders sooner.
(so dedicated folders for scenes, scripts, audio, etc.). But also sub-folders for things you know will have many additions (scenes/ props, scenes/traps, etc.)
The main advantage is obviously clarity, but you can also just find stuff quickly and dont have to guess where the related files are. For me it helps if I dont think I need something anymore. So its super easy to maintain your game folder to be lean and clean.
Yes, that is essential. Once you get the hang of Github it really is a two minute job at most to set up. I cannot tell you the amount of times this has saved me since I started using it. And 30 seconds at the end of each day uploading changes via github desktop is nothing.
For me there are two very clear and distinct phases. Prototyping and Production. During prototyping I start making the game with the first main game scene. As for configuration, initially hardly any at all. Variables for player settings say, just put them in the player node. When suddenly the camera needs to know where the player is, stick in an export var to the player node.
Once the prototype is done, the game is fun, the mechanics are all identified, etc etc (and that does not mean fully working or beautiful with perhaps one level hard coded in), it is time for the production build. This is different, and needs some planning. For that I start with the configuration now that I know what I am building. I know what information needs to be accessed via saved files, resources, which stored in data store singletons etc.
So during prototyping, everything is quick and dirty. During production build, everything is strictly neat and beautiful so that maintenance in the future is easier, but more importantly for me, I can then branch off a mobile version, a pc version etc more easily, and maintain them. At this point I also start adding dev docs to it, explaining to my future self why something does this or how this works etc.
From my work experiences, I can tell you that every company approaches all this differently and there is no single answer to any of it.
As a quick follow up question, and something I still waver on.
At the moment I put all the art and scripts and resources for a component in that components folder.
Previously I put all the art into an art folder (subdivided of course), all the scripts in another and all the resources into another etc.
Now each approach seems to have benefits and drawbacks. I would be really interested to hear how other people structure their folders. (Perhaps this should have been a separate thread).
Again, I haven’t built a single game, but thinking about it now… Why not both?
So, there are going to be some “things” in your game which will be quite isolated from the rest of the code. Kind of “components”. For example, your player. Each enemy/trap. Maybe some objects you can interact with. Etc. I’d keep those each in their own folder - scene, script(s), art, etc. When you want to work on them, it will be handy that all the related things are together. And those files will rarely be used outside of the component anyway. There shouldn’t be many files per component, but it you see that they’re starting to pile up, you can add subfolders.
Then you’ll also have some more generic pieces that are used all over the place and not connected to any single component. Levels, background art, music, tilemaps, etc. For those you can create your generic “art”, “levels” etc. folders.
And, the best thing is - if you use both git and UID references, you can later reshuffle the files as you see fit. I doubt there’s a “one size fits all” approach out there, and as your project grows it’s only normal to realize that you need to clean up and reorganize every now and then.