Currently, AGM has a large number of available nodes. After creating an object, many nodes are automatically added, and each of these nodes comes with numerous properties and functions, which is really great.
However, this also brings a problem: many nodes and functional properties are not currently needed, yet they are all listed there, making the editor interface very cluttered and completely unorganized. Many properties are just displayed without any explanation of how to use them.
We hope it can be as clean and concise as the native scene nodes in GODOT, allowing users to add nodes only as needed. We also need documentation that explains the operation and usage of these nodes.
Thanks for the feedback! From my understanding, the preset nodes on objects are intentional and tied closely to AGMaker’s visual scripting. A lot of the nodes that come bundled (VariableSettings, SwitchSettings, CollisionShape2D, AnimationPlayer, etc) are required for visual script actions and conditions to function. If they weren’t there by default, you’d hit crashes or a pile of debug errors any time an action tried to reference a missing node. Bundling them up front means the visual scripting works out of the box.
It’s kind of a different approach from Godot’s native composition. AGMaker is aiming to lower the barrier for people who aren’t familiar with Godot so they don’t have to figure out which nodes to add and how to wire them together. I know it can make the inspector feel busier, but it’s a tradeoff for a more ‘out of the box’ experience.
For the reasoning behind how GameObjects are set up vs native Godot root nodes, this one is worth a read:
And for the preset scene nodes (SceneLayer, DistantView, etc), this covers what each one is for:
If there are specific nodes or properties that feel unclear after checking those, let us know so we can help.
There is currently a lot of redundancy in the variable properties of objects. For example, BaseSettings contains properties related to character health, attack power, invincibility, etc., and VariableSettings has the same property configurations. Additionally, there are separate settings for TakenDamageSettings (damage taken), InvincibleSettings (invincibility), and FaceDirectionSettings (direction display), the latter of which also appears to be present within the action execution logic. Could these variable properties be consolidated? Furthermore, for custom variables, each one has a large property panel. As the number of custom variables increases, it becomes difficult to view them quickly. Could the display structure be similar to how variables are exported in Godot (Variable Name ----- Type ----- Value)? This would make the understanding and usage paths much clearer.
Thank you for your patient assistance. Wishing AGM continued success!
I don’t think there’s a conflict between BaseSettings and VariableSettings. You don’t need to adjust HP in both places; simply modifying the HP value in BaseSettings will automatically update the variable since they are synchronized. This is intuitive and convenient, making it easier for beginners to understand.
You can think of BaseSettings as a convenient place to set initial values for your objects, while variable values allow you to make adjustments later in the content.
PGM had a similar layout too. If you think of nodes as PGM tabs, we had a Base Settings tab and a Variables tab, which Base Settings updated the Variables as well.
I do think UX is always a WIP with these kind of things though, so we can still hope for a better and better UX in AGMaker.
Yes, the best way to think about the Base Settings vs. Variable Settings is that Base settings are your quick start settings to create the default state of the Object, while Variable settings are what you are actually manipulating to update the Object during gameplay.
It can seem redundant to advanced users, but the Base Settings is needed to help new and light users get things setup quickly.