Post-mortem - DWA - My GD experience for my first finalized prototype

[el_kloklo]

Thank you very much for your comments, I will try to clarify my points.

@Silver-Streak

@el_kloklo

• Behaviour cannot accesses to other behaviours (even same type), making them very, very, limited

Agreed. Extensions in general (including functions and not just behaviors) being hyper-focused on being portable, rather than allowing extensions to interact more directly with the project if they’re meant to be private extensions, has always felt extremely frustrating or limiting.

There was a lot of conversation about this back in the day but the general viewpoint was that having another way for extensions to behave, at the same time as the variable system was changing, would cause too much confusion in the newer developers at the time. There was also a lot of thought that custom objects would solve for some of this, but those are still much more complex (and portability focused) than just letting the behaviors see each other and the project itself. I hope this gets re-evaluated at some point.

I will submit a feature request here, I have no big hopesm but I think there is way to improve without jeoparding the closed portability concept.

@Silver-Streak

@el_kloklo

• Group management have lots of bugs (variables, naming of object, …)

I’d probably need examples to comment on this more specifically, but I know a ton of work has been done on object groups over 2026 and specifically the past few months, so I wouldn’t be surprised if some of the underlying feeling here has since been resolved.

As far I have experienced, the issue related to array and structure is still present, and if you rename an object it disappear form your group.

@Silver-Streak

@el_kloklo

• Some issue/limitations which are known should be clearly documented, for instance that “only once” will not repeat for each object of a loop.

This specific example in the wiki (which is the documentation) has included guidance around trigger once and per-instance behavior for years. Although it has been expanded upon with alternatives in the last year-ish. If you have other examples that might be more specific it could be helpful on contributors or the devs on getting them updated.

For this kind of thing, I would have expected this to appear clearly in the GDevelop engine Event creation, when I select this condition.

@Silver-Streak

@el_kloklo

• Instance selection and research in editor not easy, particularly in level with lots of instance

I would have agreed with this one last year, although this one should have become easier lately, they made the instance panel much more condensed so there’s less scrolling, and added a search too.

Well, the things is that if you have lot of instances stacked, it is very hard to pick the one you want. You select at best, a large group of instance, and you cannot unselect object which are not in front (Z), or only as a square selection. Maybe by multiple selection, the instance list could be reduced to the select object list. I will submit here also a feature request.

@Silver-Streak

@el_kloklo

• Behaviour object don’t have array

Do you mean in the properties or as a variable in your extension? Extension variables should support arrays just fine, as far as I can see.

The type “array” or “structure” is not in the list of the possible type for behavior properties for an object behavior.

@Silver-Streak

@el_kloklo

• There is no way to create static string or number for the event sheet, meaning that you are very prone to typo issue when managing string

If you mean string variables, this is generally true for all engines, and I’m not sure how you’d solve this otherwise. You generally do not parse a variable’s value into a type ahead, because the variable’s value can change at any time (especially via events).

If you mean something else I’m not sure what you’re meaning here.

To be clearer, I use in other language something like in C:

static enum interaction_types = {
 None=0;
 Hide=1;
 Push=2}

When you call your value, you cast interactions_type.Hide in a variable of type interactions_type for instance. This way, if the typo is wrong, you directly have a compile error called at the right line, so you don’t have to search around where you have a typo error. And unity had it too, it even gave you a choice list for the property if you used the enum type.

@Silver-Streak

@el_kloklo

• Positionning is not easy to manage where outside the base layer

Not sure what you mean here either. Can you add more context?

Positioning is the same on every layer. Unless you mean the camera position? Each layer has a unique camera, which is generally the same on all 2D engines. Usually you just sync up the camera positions if you need things to be placed the same on those layers. Might be misunderstanding what you mean, though.

I had issue when trying to create custom object inside 2D fixed UI at position based on the position of an object base layer. I scratched my head a while, and I had to use a workaround to set the new object on another layer than the fixed UI, I cannot say now what was made wrong.

@Silver-Streak

@el_kloklo

• Linking have no ID or tags

Yep, agreed that having some way to categorize an object link could be helpful.

I will put a feature request too here.

@Silver-Streak

Either way, congrats on your prototype!

Thank you very much for your comment.