Defold message passing discussion

[Ragnar_Svensson]

It’s different to other platforms because it satisfies the 5 requirements I outlined in the other post. To my knowledge no other platform chose to solve the same set of requirements, so it’s of little surprise that ours is different. On the other hand, it’s quite similar to http. This thread was started about criticising the design, and you can only do that in the light of what is being solved.
Now you have moved on to how well it is described and documented, which is a separate discussion. I agree that we should do a better job at this, but you also have to understand it’s a lot about familiarity. The documentation we have works for some users, and it doesn’t work for others, depending on their preconceptions and previous experience. Let’s take your explanation of the postal service messaging as an example. The description is heavily based on your own familiarity with that system. You didn’t describe:

• How you actually post the mails (mail boxes, locations, and times when they are emptied)
• Envelopes and allowed weights of the content
• The expected time to delivery around the world
• How stamps work (how many you need, where to get them)
• Care-of addressing
• Street numbering
• P.O. boxes

In fact, the real world postal service is many magnitudes more complex than message passing in Defold, because it needs to deal with the real world. But it’s still a lot more familiar to everyone, which makes it require less description. That’s not about elegance, it’s about different problem domains and familiarity.

So message passing, at its core, will remain pretty much exactly as it is. It might be changed slightly (like the loose discussion about callbacks), which might have significant improvements on usability. It can and should be described better in the docs, which is an ongoing process.

[deeeds]

You’re putting words in my mouth.

The original sentiment was “Please make messaging more elegant”, NOTHING MORE!

I didn’t start this thread, it was branched by someone else. Where the conversation goes from a branching may well require another branching.

I was asked to provide my suggestions for how to improve it. I didn’t design Defold’s messaging, nor the system it’s housed in, so I wouldn’t dare presume to know how to make it more elegant, I simply recognise a lack of elegance and an innate complexity of the final design and its use. This is more than apparent by both the initial reactions of new users and the documentation’s attempts to describe it.

I can’t change the experience of others but by finding and assisting in crafting a better expression of what Defold messaging is.

So I asked for a description of Defold messaging in 3 sentences that stands on its own. Nobody has come close to it, nor contrasting it with the most common forms of well known messaging constructs in other languages and engines.

That’s a problem or symptom of inelegance, complexity, uniqueness or blends therein. I doubt it’s that it’s not well understood, aa a few people have come to understand it quite well, and you’re the originator of it.

So we’ve got to one point in our conversation, recognising Defold messaging is either inelegant, complex, unique or a blend of 2 or 3 of these qualities.

You’ve now chimed in to say it won’t be getting more elegant, it’s impossible to redesign it, and the only change being considered is to add some callback functionality that I know nothing about.

So the importance of explaining it simply, briefly and clearly really is a chief concern for popular success of Defold, since the messaging itself is inflexible.

Given this thread has some people that consider architecture and understand the messaging, this is a great place to start work on a vastly better description and introduction to Defold messaging. Look at the extraordinarily good articulation of @NSCharles and the wonderfully succinct use of powerful language by @h3annawill (probably a designer).

[deeeds]

Perhaps asking to have messaging described in 3 sentences wasn’t the most helpful way to inspire ideal articulation of Defold Messaging for all and sundry.

Let’s start with some more granular thinking that’s pertinent to how many newcomers might be thinking when they first peruse Defold:

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

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

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

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

[sicher]

This is more than apparent by both the initial reactions of new users and the documentation’s attempts to describe it

Can you elaborate on this, please? I write a lot of our documentation and is really interested in getting specific feedback on how to make it more clear. It’s hard for us who knows the engine well to know how a newcomer thinks about our stuff so if you think there are apparent problems I would love to hear it.

[deeeds]

I think the biggest problem is that you’re not “message passing” as everyone with programming experience thinks of it in an OOP world. And it really is an OOP world… because the operating systems and their frameworks are all made with it. OOP is not just a programming paradigm, it is THE programming paradigm. Anyone in love with Erlang needs to understand that Yes, I’m teasing you, in particular, SWEDEN! (please take this as the failed attempt at humour it is, it’s not meant with any degree of viciousness @Pkeod ).

Message, in modern colloquial 00P meaning, is actually calling a function of an object that’s not self. This might be more accurately named “method invocation”, but programming’s community is leaving any common sense use of language behind. So this is what the majority think is messaging.

Objective-C was the best at this because it was the closest we had to an extrapolation of the ideas of Smalltalk, so could legitimately claim that method invocation was messaging.

Message passing in Defold is much more like sending mail, because you send data without any hope of a return or surety of receipt, nor expectation of action from the receiver upon reading the data sent. That’s why I used the metaphorical example of the sending of a letter, as that’s much closer to the ideas of Defold messaging than current thoughts on message passing in the majority of the programming world.

The ramifications of this massive change in the architecture of messaging (and its meaning) need to be conveyed to a new user so they can calibrate their brain and perception of Defold, and begin to conceive of how they’d articulate and architect gameplay and logic within Defold.

[sicher]

Message passing in Defold is much more like sending mail, because you send data without any hope of a return or surety of receipt, nor expectation of action from the receiver upon reading the data sent. That’s why I used the metaphorical example of the sending of a letter, as that’s much closer to the ideas of Defold messaging than current thoughts on message passing in the majority of the programming world

And to me, the way you post messages in Defold makes this distinction very clear. It is apparent (to me) that you are not invoking functions or methods.

We try to be explicit in the manual that Defold is not OOP in the sense people from C++, Java etc might think, but I’m sure it can be done better. How would you approach this pedagogical problem?

[deeeds]

I’d really prefer the thoughts of @NSCharles and @h3annawill, as I think they know it far better than I do, and write better than I do.

I’d also (personally) very much like to see how @baturinsky would describe Defold messaging and game logic conception and creation from his personal experience and perspective. I think his vision might be the closest to a general consideration of the differences it has with all other common approaches and thinking.

And your direct thoughts. When you’re blunt, you’re a very good writer. Can you answer my above four questions?

[deeeds]

I’m also really keen to see what @Mathias_Westerdahl writes about conceiving of and articulating in a Defold way, when he has a keyboard in front of him.

[sicher]

And your direct thoughts. When you’re blunt, you’re a very good writer. Can you answer my above four questions?

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.

[deeeds]

Where are scripts, game logic and event handling housed in Defold?
How do I activate a method on an object in Defold, from another object or housing of game logic?
How do I get a value of Object_A from another object, or anywhere in game logic?
How do I set a value on Object_A from Object_B or from anywhere else in the game logic?

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?

[sicher]

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.

[deeeds]

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.

[codecloak]

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)

Where are scripts, game logic and event handling housed in Defold?
How do I activate a method on an object in Defold, from another object or housing of game logic?
How do I get a value of Object_A from another object, or anywhere in game logic?
How do I set a value on Object_A from Object_B or from anywhere else in the game logic?

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.

[deeeds]

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.

[Mathias_Westerdahl]

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

[NSCharles]

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.

2. 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.

3. Execution context for scripts (and gui scripts!), Lua is partially at fault for this for being a free spirited hippy of a language.

• 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 ), 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 ) 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!

[deeeds]

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.

[sicher]

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

[deeeds]

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.

[h3annawill]

@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.