Defold message passing discussion

Sure, and the documentation answers them:

  • There are a few tutorials that go through them in a step-by-step practical manner
  • Manuals in a descriptive manner
  • API docs in a barenbones techical manner

I would love to have specific feedback as to where we have documentation holes, the docs are lacking, unclear or otherwise up for improvement.

1 Like

The docs are specifically lacking in the answering of these questions. These are the primary concerns of anyone considering the use of an engine, after considering the rendering (visuals and audio), the concerns become architecting logic.

How do I structure my game world and its objects within Defold, and how are events propagated to me and my code, and how do I send notifications, requests and commands?

The answers to the above questions are the constant conceptual framework inherent to architecting a game within any combination of engine and language. It is THE most important understanding required to DO the making of a game in any engine and language. Yet it’s the part most engines start and spin slowest at when articulating, and most programming languages are most compromised in addressing (all puns intended).

I’ve identified the four things that most rapidly provide this information to a new user (I think) so as to most rapidly get them thinking in a Defold way, can you please attempt to answer them, in the bluntest form, as I think this is the fastest possible way to massively improve the introduction process to USING and THINKING in the Defold way.


  1. Where are scripts, game logic and event handling housed in Defold?

  2. How do I activate a method on an object in Defold, from another object or housing of game logic?

  3. How do I get a value of Object_A from another object, or anywhere in game logic?

  4. How do I set a value on Object_A from Object_B or from anywhere else in the game logic?

1 Like

The intent of the “Getting started” tutorial is to get a new user with some prior knowledge in programming up to speed with how to construct a simple game in Defold. We also have the “Magic Link” tutorial that digs a bit deeper and structures a more complex game. Either one of those answers your four questions. You can also find the answers to you questions in the manuals, but I think currently the tutorials gather this information better.

The “Magic Link” tutorial is specifically built differently from a “schoolbook OOP” approach where you would mix data and logic in your objects. Instead it tries to separate these concerns and makes use of message passing as a higher level logical construct. Some new Defold users tend to mix data and logic in their objects and use message passing to send data across the codebase and we try to advice against that.

What we don’t have is a tutorial that requires no prior programming knowledge, but that is in the plans.

Not tutorials. WORDS in a sentence.

Just because I’ve relaxed my (somewhat arbitrary) restriction to 3 sentences doesn’t mean I’m suggesting tutorials are better than sentences in a paragraph that instantly familiarise a reader with the concepts, constructs and paradigms.

Tutorials aren’t teaching, nor are they manuals. They’re exercises to be done once understanding and wisdom has been imparted, to demonstrate application and usage.

I’m going to say this last thing and then step away from this topic as I don’t think I’m being helpful and I know I’m not learning anything useful by reading it.

I’ve spent maybe 30 hours using Defold (if I’m being extremely generous about my usage). My entire experience with message passing has been:

  1. Read the first 1/3-1/2 of the documentation when I was attempting to use it for the first time to learn the function parameters and it immediately making sense.
  2. Wishing Lua was Javascript because I’m more familiar with that and so I was treating Lua tables like JSON and I shouldn’t have been. I tried to use hashed strings as a key into an object and turns out that doesn’t jive so well.
  3. Randomly reading the rest of the documentation and learning I could construct an address through a variable instead of directly passing it which allowed me to clean up some ugly code.
  4. Just now when I thought of another way I can utilize message passing and remove some redundant data inside an object which I hope I remember when I wakeup from sleeping off this hangover. Edit: nevermind turns out I already cleaned that code up.

With all that said, I still don’t know what your confused about. I am also making an incredibly simple game and simply my not be running into the issues that @NSCharles or @baturinsky mention. You’ve yet to actually state an issue with message passing beyond the concept of the paradigm itself (try some external reading on the subject in general instead of this engine’s specific usage: http://gameprogrammingpatterns.com/event-queue.html)

  1. See sicher’s answer above. I actually started from the Magic Link tutorial and I couldn’t be happier with it (though there is a logic bug in their “touch” calculation that assumes the Y offset matches the X offset)
  2. You pass a message. Also, I think you can call it directly if you have a reference to the object and want to couple your objects in that way (I’ve not actually tried this one yet as I haven’t had the need).
  3. go.get() read http://www.defold.com/manuals/properties/ or http://www.defold.com/ref/go/#go.get:url-id
  4. go.set() read http://www.defold.com/manuals/properties/ or http://www.defold.com/ref/go/#go.set:url-id-value

Small aside: I apologize if I sound like a bit cantankerous in my response here. I’ve got a headache from this hangover and I can’t sleep so probably not in the best state to be involved in a discussion.

4 Likes

What’s lost is the context this started in. I saw 3D being considered as the next feature-feature, meaning designed to bring and engage new users.

In response to this new feature work I wrote this: Teaser Fridays and Roadmap talks

“Please make messaging elegant before working on 3D”.

I have made a subjective call that messaging is not elegant within Defold.

The manual and documentation supports my claim, it’s miles long and all over the place in attempting to describe the different types of messaging, and eventually resorts to tutorials.

I’m sorry to hear it won’t be made elegant, and can’t be modified. That’s in the above thread.

In the context of making things that make Defold more attractive and more popular (the actual originating thread), the next thing to do about messaging is to communicate it better to potential new users.

That’s possible, I believe. I’m just not the right person to begin that initiative as I’m not sure I fully understand it, certainly don’t fully understand the design criteria, wasn’t the designer, don’t work for King or Defold, nor do I think I’m any good at writing.

2 Likes

I was referring to googling more examples of ppl & engines using message passing/event queues. Please feel free to do this too :slight_smile:

2 Likes

If I may be so bold as to chime in here, I started using Defold about a month ago, here are some things I would have really loved to see in my first few days/hours:

  1. I found the concept of message passing in Defold easy enough to grasp, but I struggled with the specifics of addressing for a couple of days.
  • A deeper explanation of URLs, especially how they are (or rather, really aren’t!) related to the hierarchy in collections.
  • Getting hold of, and handling, URL objects. I spent a lot of time trying to infer or deduce the URLs of other objects without “hard coding” them before realizing that they are really supposed to be used that way.
  • URLs for GUI scripts weren’t immediately obvious.
  1. Message Passing in Architecture, it’s pointless to fight the engine and try and do things the way you would in other engines, but some alternatives would be really appreciated.
  • How to achieve behaviors/patterns which we may already be familiar with in other paradigms - perhaps some very common system elements throughout game development (e.g. the stuff in this thread: Events & Callbacks).
  • If its suited for messaging, how can we tackle it? if it’s not suited for messaging, whats the alternative?
  • What situations would you recommend using messaging for, what would you recommend avoiding.
  • “Cleaning up” the messaging pattern, with things like the handler table @Ragnar_Svensson mentions.
  1. Execution context for scripts (and gui scripts!), Lua is partially at fault for this for being a free spirited hippy of a language. :slight_smile:
  • I’ve been using the engine for a month and i’m still not 100% clear on the execution context of a specific game object script.
  • In Unity for instance, MonoBehaviour methods are called via reflection (eww :smiley:), and conceptually the components can be thought of to sit in a set somewhere, each referring to the same GameObject. Knowing this, when I write “GetComponent<Foo>().blah()” in Update, I know where the component, blah, and Foo are, and I know how and when Unity will call Update.
  • In Defold, when I wrote something like gui.get_node("foo"), I was left with a ton of questions about where and what is happening exactly:
  • Where does gui live and what does it have access to? Can it see me?

  • Where is it getting foo from exactly? I know its in the scene graph of the gui that this gui_script is attached to, but where is that and how is it stored? Why are gui scripts “inside” the gui component? Why are GUIs not a part of the collection hierarchy?

  • If I call gui.get_node("foo") from a different script, is that the same gui as the previous example searching in a different place? or is it actually a different gui entirely?

  • If store that gui in a global variable, then access it from a different .gui_script script and make the same call, what will happen?

  • If I write self inside an update, what am I referring to? The game object? the component? something else? When does the code outside the game object hooks run?

  • These are things that I wanted to know when I was learning the engine. I know that these may seem unrelated to messaging, but I feel that it’s important to know where the boundaries are when writing messaging code - A does not know the context of B when sending a message to it: so what happens if A sends a message, then modifies gui? is B going to explode or be unaffected?

No 1. and 3. can be easily fixed by more documentation (or maybe if I was a bit smarter they wouldn’t be an issue at all :slight_smile:) but mainly, I think 2. would be really nice.

The truth is that anyone with even a small amount of experience can figure out how to store a map of registered listeners, but seeing a few clear, succinct examples of how someone with a lot of experience in the messaging world approaches different architectural problems would really help!

6 Likes

This isn’t about me.

Proving me wrong, helping me with particular insights (or showing my failings) doesn’t help potential new users considering Defold. The original context of this thread is that of features that market, promote or otherwise increase the popularity, acceptance and use of Defold.

I think making messaging elegant (and therefore easier to understand) is the single greatest way to increase Defold adoption, usage and growth. More users using a more elegant messaging make ever more products that attract ever more Defold users. Etc.

Please remember the above when reading anything I’m writing in this thread.

Given the messaging can’t be significantly changed (made elegant, by my criteria), the only way over this barrier (to a future of ever more happy and productive new users) is better education of how messaging (the most important part of programming) works in Defold.

Pedagogically speaking, I think you need to think of messaging the way (the majority) of others do, and then consider explaining the capabilities of messaging within Defold, in the Defold way, within this context.

To that end, I’ve identified and articulated 4 questions that (I think) help the common new (potential) user come to terms with how Defold deals with messaging, game logic and events in the SHORTEST and EASIEST way.

Answering those questions well leads (I believe) to happy users.

Tutorials are not a shortcut to understanding, they’re a last resort. EVERY SINGLE TIME!!!

Tutorials are not the easiest way to impart knowledge, either. They take great effort to make and even more to gain knowledge and wisdom from. And they’re very specific. Tutorials are often used by programmers because they struggle with thinking in terms of many others, preferring others to think in their terms and unique circumstances. Aside from being incredibly selfish, this isn’t generally helpful to sharing with, education of, or informing many. It just removes the need to think empathetically about a mass. If you point to a tutorial to answer any of these four questions, you’re missing my point, completely.

Generally helpful learning materials are generally written overviews that provoke and answer common (and) general questions leading to general insight and common understanding. This isn’t subjective, it’s a fact of life and learning.

I’ve posited the four most common and general questions of game programming messaging, that I can think of.

There might be others. These might not be the best four questions.

1 Like

@NSCharles and @codecloak, thanks for your experience summaries. They give me some ideas on how to improve the docs.

2 Likes

Given the extraordinary insight in @NSCharles post, if you have time, @h3annawill), could you give a personal (or general) expression of your broader thinking on experience coming to and into Defold’s way of thinking.

I think the two different perspectives of these two wonderful writers (and thinkers) might make for a truly epic guide to marketing and documenting Defold.

@NSCharles, thank you. I feel a lot less alone. Most everything you wrote I’ve experienced when reading through and attempting to understand how to use and think in the Defold way. Many of these questions remain unanswered, probably because I’m too dense to figure out or find the answers.

@deeeds It is clear from this thread that the Defold team is highly conscientious and likely already aware of any superficial issues I might raise. Furthermore, If I hold the full context of their goals, I can find little fault with the documentation. I also happen to agree with their goals.

To provide actual assistance I’ve decided it’s best to become a ‘bug-hunter’; to start contributing to the “bootstrap data”; and on gaining a more complete understanding, produce educational material which I think will be suitable for those lacking the pre-requisite knowledge or approach.

11 Likes

@h3annawill You find nothing to agree with (or add to) in @NSCharles contribution above?

Disclaimer: I have not read all the posts, since there were a lot of them :slight_smile:

My main problem area with the messages is the url part. We’re using a lot of proxies and factories and sometimes it seems like I can’t get the address right.

1 Like

I think you’re presenting your perspective as that of the average user approaching the engine. However, the quote above makes it clear that you’re bothered by message passing in Defold because you have a fundamental misunderstanding of the programming terminology.

Message passing, in modern colloquial OOP meaning, is absolutely not defined as calling a function on an object other than itself. Calling a function on another object is called method invocation.

Objective-c might be clouding the issue here, because all of its method invocations are implemented under the covers as message passing. This is a side effect of the language’s roots, but this is not the norm. None of C++, Java, C#, JavaScript, or Lua do this.

I would bet money that anyone coming from C++, Java, C#, JavaScript or Lua would not interpret the phrase “message passing” to mean “method invocation”. They would likely interpret it as something akin to the post office analogy mentioned above, which is exactly what it is.

Don’t believe me? Read the first two sentences of the wikipedia article on Message Passing

(PS: Oops, didn’t realize how old this thread was, I probably shouldn’t have posted)

4 Likes

It’s good that this discussion is brought to the top of the pile again! Defold is different and message passing might be hard to grasp, but once you get the hang of it and understand how it is supposed to be used it’s actually very nice.

2 Likes

I have a comment about this. I’m sure there are a lot of tutorials about messaging, but one feature that would speed things up is an autocomplete object tree browser thingy to find the appropriate target for a message, generating and autofilling the url

1 Like

This is an interesting idea. It could work for absolute URLs where you specify socket, path and fragment. It would be more difficult for relative URLs since scripts can be attached to multistrong textple game objects.

Wow! I want some of those! :slight_smile:

7 Likes

Oh, yeah, almost as good as “multiple game objects”!

1 Like