GDevelopApp / GDevelop-extensions

Repository of behaviors, actions, conditions and expressions to be used in GDevelop for creating games
https://gdevelop.io
MIT License
131 stars 52 forks source link

Extension Best Practices #70

Closed tristanbob closed 3 years ago

tristanbob commented 3 years ago

➡️ See the checklist of the best practices here ⬅️


Original discussion:

I have realized that the scene variables used in my extension are not locally scoped inside the extension. Instead, they share the same space that all scene variables share. This means that some of my simple names for scene variables could collide with something that the GDevelop user has assigned.

1) Can you provide guidance on how variables should be named when used inside an extension? Someone gave an example that looked like this: "_MyExtensionMyVariableName"

2) Is there any way to delete temporary scene variables that were used in an extension? (These should still follow the naming convention to prevent accidental overwriting and deletion)

4ian commented 3 years ago

Can you provide guidance on how variables should be named when used inside an extension? Someone gave an example that looked like this: "_MyExtensionMyVariableName"

That's a good convention, also if you can put most of the variable inside a single structure variable with the name of your extension (and an underscore in front of it), that should greatly reduce the risk of conflicts.

This means that some of my simple names for scene variables could collide with something that the GDevelop user has assigned.

Yes, that's the risk. If you see an extension that uses a fairly obvious/common variable name, let me know and feel free to submit an updated extension.

Is there any way to delete temporary scene variables that were used in an extension? (These should still follow the naming convention to prevent accidental overwriting and deletion)

There is no easy way to remove a variable outside of a structure, which is kind of per design (in a game you avoid creating and destroying variables too much if you can). I think it's ok because it's giving at least one hint in the debugger to the end user that this variable was created and used - so you must be careful about not using it.

I think the proper answer to this would be to add support "extension variable" (with actions/conditions/expressions for variables scoped to extensions). With this, no more risk of conflict at all. I've created a card for this here: https://trello.com/c/CWL7Z9jB/463-add-support-for-extension-variables

That's the cleanest solution. In the meantime, let's be sure to use variables with a long prefix to avoid collisions :)

tristanbob commented 3 years ago

I like your solutions, both short-term (unique names or a single structure with child variables) and long-term (variables that only exist inside the extension).

Thanks!

4ian commented 3 years ago

Closing this as we have the checklist now :)