Sure, and the documentation answers them:
I would love to have specific feedback as to where we have documentation holes, the docs are lacking, unclear or otherwise up for improvement.
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.
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 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:
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)
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.
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.
I was referring to googling more examples of ppl & engines using message passing/event queues. Please feel free to do this too 
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:
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.gui.get_node("foo"), I was left with a ton of questions about where and what is happening exactly:Where does
guilive and what does it have access to? Can it see me?
Where is it getting
foofrom exactly? I know its in the scene graph of the gui that thisgui_scriptis 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 sameguias the previous example searching in a different place? or is it actually a differentguientirely?
If store that
guiin a global variable, then access it from a different.gui_scriptscript and make the same call, what will happen?
If I write
selfinside anupdate, what am I referring to? The game object? the component? something else? When does the code outside the game object hooks run?
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!
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.
@NSCharles and @codecloak, thanks for your experience summaries. They give me some ideas on how to improve the docs.
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.
Disclaimer: I have not read all the posts, since there were a lot of them
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.
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)
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.
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
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!
Oh, yeah, almost as good as “multiple game objects”!