Hello, Im not a native english speaker so sorry for any mistake ahead, with that out of the way
I’m currently making my first game of wich im 100% commited to finish no mather what.
So I’ve been adding more core functions to it (save, pause changing scenes, etc) and discovered at this point the need of use *TimeDelta() in events that are repeated for a gradual effect over something (so its not controled by the fps), having to go back to others things that I thought where ready and fix them took me about half an hour, and from the way I did it, I now know that it was because of the organization (or lack of it) that my project have, so at this stage, (wich I think is still early) having it well organized will help in the future.
So to illustrate the problem and the “solution” I have come to think of here are this images.
The problem is that there are events repeated, or wich share the same function in each external event so I’ve been thinking of making this events affect a group of objets, and them just adding the Enemies, Hazards or Enviromental assets to those groups, like this.
Is there a problem with this kind of organization? Making the behaviors separeted from them seems a bit more logical, so if anyone can share their knwoledge regarding project organization it would be a blessing.
Ideally, everything that is reused should be moved to external layouts, behaviors, functions or external events.
Functions and behaviors are very powerful, but if the reuse is limited, it’s not always worth the effort.
From your last image, your objects seem to share a lot, so it’s probably a good idea for you.
You should look into the Health extension, see how it’s done, see how it works.
Your events screenshot doesn’t help much because I suppose that the player controls are not reused for the enemies.
I think you idea to use groups heavily is a good one, and works well in my experience with GDevelop.
It can be a hassle to remember to add new objects to the correct groups, so you may want to add some debug checking early on that labels each object with it’s groups or just puts a red X on ones without a group, because it can be frustrating to isolate why an object isn’t behaving as expected later on in the development process.
Remember that using groups on the same type of object (sprite, textbox, etc) will allow you to use those object specific methods when selecting via group, but when you mix types you can no longer do so… however you can still access the variables on mixed group objects.
Object/Instance Variables are the most important part of the group based logic as they allow you to treat each object as a node in a state machine. So your “For each object in group” loops will be able to update those objects based on the state they are currently in.
If you are going to have lots of “levels”, I would definitely recommend using a single scene that has all of the objects and logic associated with it. Then use External Layouts for each of the levels you design. This adds a little complication on having to load the correct external layout when the scene begins, but it really helps prevent a lot of redundant scenes that you have to keep in sync.
