Game architecture in Defold

Questions
1

Hi everyone,
let me start by thanking the devs and the community for being so helpful (this is my first post but I used the forum to get some answers before ).

I’ve got a couple of questions regarding best practices for laying a decent game architecture.

At it’s core Defold works with the messaging system and that is made clear in the example projects.
Let’s take the “Roids” sample game. Scriptwise almost every communication between objects is made with messages, sometimes the message is even sent to the same script to handle simple tasks like disabling the GO itself.

Now, for a game prototype I’m working on I was using modules to handle shared data and functionality (game manager, inventory, language manger for localization, etc).

What do you say is the best approach? Relying on messages for almost everything or using Modules to handle game logic? I get that every approach has it’s pros and cons (modules cannot hot reload for example) and I also get that the Roids game being an example may be using messages for everything so that the messaging pattern is well explained to new users.

Let’s take an inventory system for example:
a) I could have a stateful module handle the data, require it where I need it and access it’s functions (say calling an addToInventory() for example)
b) Have an inventory GO with a script and send a message to do the same.

Can we discuss a little on what’s best and why? (even tho I’m expecting a lot of “it depend” and “both equally works” hehe)

Thanks a lot.

PS: I, like many others, wish for strings to be passed as properties. Just to display the name of an item it’s being a pain :smiley:

3 Likes
2

For my game I use both in the following fashion:

Modules are sources of truth, where I keep shared state. (And sometimes shared code)

Messages are short, contain very little data (they’re limited to 256 bytes anyway) and just represent intents.

To keep my messaging sane, I made a dispatcher module. Instead of dispatching messages directly to specific scripts, I call the dispatcher and it dispatches the message to each script that subscribed to that message id. This way I can decouple scripts from each other much more.

Finally, most of the game logic is happening in scripts, many and limited in scope (the dispatcher approach really lets you split up scripts easily since you just need to subscribe to the same messages as the other script), unless something is too big or clearly a separate abstraction, in which case I put it in a module.

13 Likes
3

Good recommendations from @dapetcu21! I like modules for complex logic (makes it easy to write tests). Using scripts have the big advantage of being able to be hot reloaded (yes, modules can be hot reloaded but is tricky).

4 Likes
4

Thank for the answers guys, I will keep experimenting with the engine. I really like it, let’s hope I manage to make something decent with it :wink:

3 Likes
5

It’s also good to keep in mind that functions are first class citizens in Lua. Use them as keys or values in tables, pass them as arguments to functions and create function closures to encapsulate state. All super powerful and useful when creating game logic and systems.

4 Likes