Godot allows you to create 2D and 3D games from a unified interface. The feature set of Godot is quite impressive.
Before you start planning your game, please consider this generalisation:
- 75% of all game projects experience problems due to an overambitious scope and feature creep.
- 65% experience delays.
- 35% experience code testing problems.
- 30% of all projects get cancelled.
- 25% go over budget.
In other words, constrain your “hysterical optimism“. Your project will run into problems, so manage it accordingly:
- Start the project small.
- Define a clear scope and strict constraints.
- Archive ideas that fail to satisfy the constraints to avoid the distraction. This way they’re there for your next projects.
- Avoid elaborating ideas that satisfy your constraints, as the context and needs are likely to change by the time you’re ready to implement them. Add them as user stories to you to-dos.
- Remember that the last 20% takes 80% of the time.
Games are not finished, they are abandoned.
As a creative endeavour a game might never be or feel finished. It’s a decision you’ll have to make. Having a clear scope will help you know when you are ready to ship.
On this site I will exclusively use GCScript, which is the dynamically typed scripting language native to Godot.
You should avoid S.T.U.P.I.D. while striving to write S.O.L.I.D. code. Considering that game development always takes more time than expected, you’ll want to write stupid code. Follow the principles of DRY and KISS.
Pivoting is extremely common when developing games, so an agile approach to your game projects makes total sense.
There is no global scope or namespace in Godot, and no dependency injection. Everything is a node organised as trees. To decouple nodes and code Godot deploys the observer pattern using signal emitters and receivers.
In summary our approach should be:
- Write stupid code so it can be understood years later. Don’t write fancy or “clever” code.
- Strive to make the code self-documenting (descriptive naming).
- Avoid external dependencies. Store resources locally.
- Let a reasonable amount of paranoia guide you; asserts are often more valuable than a comment.
- Coding lazily is often both smart and economical. Only do what is needed, avoid speculating about the future.
- Avoid tight coupling by using signals.
- Ensure single responsibility for all functions.
- Strive to avoid duplicating functionality.
- Capture your ideas as they come, but avoid spending time on fleshing them out. After all, most ideas usually do not make it into the game.
- Develop small and frequent playable increments that you use to gather feedback from playtesters early and often.
Customising the Editor
Visit the Editor settings, if you haven’t already, to customise the editor. Setup your text wrap preferences, and so on.
You might want to enable Type Hints in the Godot Editor Settings. Search for “hints” and enable “Add Type Hints”.
Now I think it’s time to meet GDScript!