Starting my game port to defold: created a little comparison chart between gm2, godot, and defold. Could you check and clarify what I misunderstand?

Hi in my effort to start porting I made this little chart to help me with basic concepts going from gamemaker2 to godot to defold. Especially the Defold aspects.

This kinda of thing helps me translate what I have down to what I need to do.

Its not super long- just the bare basics.

godot to defold.pdf (28.7 KB)

Thank you for your help.

3 Likes

Yup, looks pretty good. Here’s some additional details that might be helpful:

Mouse Input

  • You’ll get an action_id of nil for mouse movement, which you can check to differentiate it from all other input events. https://defold.com/manuals/input/#trigger-types
  • You also get action.screen_x and action.screen_y for mouse position [link], which is subtly different from action.x and action.y. Basically, x and y are in “GUI space”, and screen_x and screen_y are plain “screen space”, which is not scaled or anything, but depends on the size of your window.

Buttons

  • Button click-checking is easier with GUI nodes, with gui.pick_node to check any node’s bounding box (rotated). To detect clicks on game objects you need your own solution (there are a bunch of forum threads about this).

Scene/Object Hierarchy

This is a bit weird in Defold coming from Godot.

  • In Godot, everything’s a node, your whole game is just a big tree of nodes. A “Scene” is just a “branch” with a single root node and any descendants, and it can be stuck onto the tree of nodes at any point and nested however you like.
  • In Defold, a Collection itself is not a “physical” thing, it’s basically just a name attached to a group of objects. Collections can have any number of objects at the root level. They can be added and nested inside other Collections, but they can’t be added as the child of an object.
    In other words, Collections don’t affect the tree at all, they’re just an abstract grouping of objects.

In Defold, if you save a Game Object file, that is a prototype for a single game object - you can’t give it children in that file. They’re good for simple objects.

In a Collection file, you can have trees of objects, parents and children, however you like. So if you have an object with multiple moving parts to it, you’ll want to use a Collection. You can still spawn instances of Collections just like Game Objects (with a “Collection Factory” component instead of a “Factory” component).


There are also Collection Proxy components. They’re vaguely similar to a Collection Factory, but they’re a different way of loading a collection, almost as if it’s a new “main” collection. You’re not required to use them, the big benefit is that you can pause the proxy, and enable/disable input for everything in it, so they’re nice for separating your “game” from your menus. You don’t need to worry about them right off the start though, they’re easy to swap in later.

6 Likes

Awesome sauce!

I had just learned the gui button system, but this response really helps! Will update my ref chart

1 Like