Thanks! I’ve always been a big fan of games in the Commandos style, and that’s really the kind of game I’m aiming for here: a small top-down tactical stealth game where movement, visibility, guard behavior, interactions and planning are the main focus. I should also mention that this is my first time working with Godot, so I’m sure I haven’t done everything the “right” way, but I’ve been doing my best and learning as I go.
I’m also using the project as a way to learn how to structure a game so it can grow without turning into a pile of tightly coupled scripts.
When I say “clean architecture”, I mostly mean keeping responsibilities reasonably separated, avoiding unnecessary dependencies, and trying not to hard-code one system around one specific level or object. I’m not trying to build some huge abstract framework, though — I actually want to avoid over-engineering as much as possible.
A good example of what I mean by reusable systems is the door system. A single door scene, with its own script, can support open, closed and locked states, use different textures, and then be instanced many times throughout a level. Each door keeps its own state and behavior, so opening or locking one doesn’t affect the others. That’s the kind of reuse I’m aiming for: build the behavior once, then use the same scene in different places with different configuration.
The same general idea applies to interactions, cursor states, dialogs, movement states, and eventually the guard AI.
I’m also trying to keep input handling centralized through Godot’s InputMap, instead of having hard-coded keys scattered through different scripts. That should make things easier to maintain and eventually makes key remapping much simpler too.
For reuse, I mainly mean reuse within this game — across different levels, doors, guards and interactions. I’m not really trying to make a general-purpose framework for several unrelated games. If some systems are useful in another project later, that’s a nice bonus, but it’s not the main goal.
I’m also trying to only generalize things when I actually have a reason to. I’d rather have something simple and understandable than create a complicated abstraction just because it might be useful someday.
The guard AI will probably be the next big test of this approach. I’m planning states like idle, patrol, suspicious, investigate, chase and search, while trying to keep perception, navigation and decision-making separated enough that they can be extended without rewriting everything.
So I guess the short version is: I want to make a Commandos-style stealth game, but I also want the project to stay easy to extend. If I add another level, door, guard or interaction, ideally I should be able to reuse what’s already there instead of copying code or creating special-case logic every time.
