Add value input to emitter so that newly emitted object can wirelessly recieve the value
It would be really useful if we can input any wire into the emitter. This would then get fed to the newly emitted object. Could then be recieved either by a tag perhaps or another new logic chip. Some kind of "Emitted" logic chip.
The use case:
Imagine you want to emit a ball and specify a color for each copy of the ball.
It is possible to do this at the minute with variables or wireless chips.. but a built in mechanism would be great. Considering emitting is such an important feature of Dreams (for complex tasks) it would be good to give smoe more power here.
If there was a new "Emitted" widget.. it would also be cool if the "Emitted" widget had an input. This could let us speak (send pulses) back to the emitter!
So an emitted object could emit. Do some stuff and then when its finished pulse back to the emitter. The logic that then emitted the instance can carry on executing!
Yeah your right I agree! Ideally Dreams could do with some kind of “class” or “object” system. So we get new widgets instead of using the emitter. Something like “class constructor” widget. But realistically an emitter is basically the same as this. So maybe just a rename to “initialiser” would be enough?
But yeah really hope MM add something along these lines in the future.
It's alright, you didn't come across as a know it all at all. Sounds like you know what you are talking about when it comes to the programming side of things.
Thanks for the examples, helps me picture exactly what you have in mind and how it might function in game. Is definitely an interesting idea.
Built in ways to help with a more object orientated approach for systems and logic would be great so you wouldn't have to completely design and make elaborate systems yourself eating up a lot of resources.
It is just it sounds a bit unintuitive and bespoke achieving this by routing signals through an emitter. I think the benefits of modular design also apply to the games tools. The more flexible and multi use they are the better as they can be combined in multiple ways achieving varying results.
But yeah I agree that programming this in game probably wouldn't be that difficult, I'm coming more from a more game design point of view.
Lol yeah I don’t mean to come across as known it all, just trying to put my point across in the hope that ears at MM might hear it.
So yeah my idea would be that the new “emitted” widget could be placed on anything that wants to be emitted. So for example let’s say a canon ball. Now when the canon emits the canon ball, it will fire a one time signal. This signal is whatever was fed into the emitter upon the time of emit. Within the emitted object Dreams would fire the localised signal and all “emitted” widgets within the object would trigger. So only the object just being emitted would receive the signal.
It would require zero wireless zones or opportunity for signals to blend (as already covered).
Internally I could picture it just doing some kind of search within the chips belonging to the emitted objects for “emitted” widgets. A relatively cheap operation to perform! I mean (again not meaning to sound like a know it all) the Dreams wireless signals currently do something like this for global signals. Those have no zone so it doesn’t involve checking expensive things like “does thing exist in zone”. It would just be some kind of internal lookup for all wireless signals in entire scene, by name. So the only difference really in theory would be instead of searching globally and for a named wireless signal, it would search in the emitted object and for all “emitted” widgets.
If we had this idea of the “emitted” widget to read info about a newly emitted object, Dreams could also provide a unique ID to the “emitted” widget. This would be a number generated by Dreams which is guaranteed to be unique. Very useful for stuff like games based on grids/inventories/simulations and more!
You could do other stuff with the "emitted" widget. You could let any emitted widget object speak to all objects emitted by the same emitter. Simply by having an input on the "emitted" widget. Dreams would then send this signal to the emitter it came from. The emitter would then redirect(broadcast) that signal to all objects it has emitted. The "emitted" widget would then have a "broadcast" output.
An example could be maybe something like path finding or some kind of processing logic. Maybe you have emitted 10 enemies in your game that have to be punched 5 times to be destroyed. You want to communicate to all other enemies that you have been punched 5 times. So when this happens you signal via the broadcast input. The other enemies can then respond when they recieve a signal. Now they all change their logic so that they run away scared!
Obviously this can all be done be done now in Dreams but it most certainly would be hard coded. You would also face a limitation if you wanted multiple seperate groups of enemies. For that you would have to create copies and variants of logic with the wireless signal names tweaked. With my proposed method you would simply create another emitter and then all communication is localised to it!
With a mechanism for emitting objects, communicating and identifying.. you can simply make the elements in your game dumb, waiting to respond to messages!
Ok enough rambling on by me .. cya!
I understand the benefits of OOP and agree it is better for flexibility and robustness. I always try to design things with a modular approach.
To address your points individually:
No attached wires to the child: This is undisputed so is not relevant.
Wireless signals blending/overlapping: I agree, that could cause issue. I don't think your idea is the ideal solution to that though.
Objects working in different scenarios: Again, this is not disputed. That is the idea of modular design. Even with a modular system it still may have dependencies on other systems. I don't understand how an emitter relaying a signal will resolve that.
It is pointless for us to keep going back and forth at this point. You seem like a very knowledgeable person and we are in agreement on the end result, just not the means to it.
What I am curious about though is how would this actually function in game. Would the signal connected to the emitter broadcast to all of the child objects? If so then wouldn't you still need to process or filter that signal on a per object basis?
So it adds more functionality because you are not tied to using a single set of named wireless signals. You add more flexibility (functionality) because there are no attached wires upon creation. You add functionality because you can emit from multiple sources at once without any issue of wireless signals getting blended. You add functionality because you can emit without wireless zones overlapping.
Your right, you still have to physically do some setup of the emitted thing. But that’s a good thing. The child... the emitted object is in charge to do as it decides with the arguments provided to it by the emitter. The benefit is because there is no hard link to the thing creating it, we could literally make “RPG item” object that has some cool logic in it to make it work in 20 different games. Then in each of the twenty games we can emit that RPG item with different parameters to customise how we want the item. Sure you could replicate that wireless emitter, freeze signals and nest of other logic twenty times for every game... but well that’s a highly unmanageable experience.
Imagine trying to release something like that as a reusable assist in the Dreamiverse. It’s just not gonna work for most people. “Hey put this chip here, make sure that wireless zone is exactly there... have that exact wireless signal name”. It just kinda closes doors to some things being shared. With a proper interface via the emitter, it’s standardised and simplified. It makes it so you can release it and people will instantly know how to emit it. All you need to do is label your emitter input nodes in a self explanatory way. (E.g “item color”)
Okay, I understand what you are saying and it does make sense.
I don't have any experience with programming but am familiar with modularity and self contained systems. Subroutines, modules or encapsulation as you called it in programming.
I don't understand how allowing the emitter to directly pass on a value would add any more functionality then what can already be done with Transmitter/Receivers, Trigger Zones and Variables.
As the wire carrying the value is plugged into the emitter it is not part of the emitted object and therefore is an external data source (From the objects perspective) and so isn't a single encapsulated system, you still need logic (subroutines) to process that data.
So either way you will need multiple encapsulated systems working together to achieve complex behaviours like you discussed (loot/item drops) to work efficiently and be robust. It is normally better to use more modular systems in general as opposed to fully integrated ones as they are more dynamic and multi purpose.
Yeah that’s how I do it too (with freeze logic and wireless transmitters) but this method does not replicate what I am suggesting. I am suggestion a technique which separate the emitted object from the object that emits it. No wires. No wireless emitter zones. No exclusive gates. Or any magic like that. Pure and simple OOP style encapsulation.
The emitter can already do some form of object setup (setting speed, rotation, etc) so why not expand on this.
So as with all things in Dreams, if MM just added a few more construct/core type features to the logic it would open up the possibilities available to all. It would increase the quantity of reusable things on the Dreamiverse and it would make the emitter logic far far far more efficient on the thermo.
In class-based object-oriented programming, a constructor is a special type of subroutine called to create an object. It prepares the new object for use, often accepting arguments that the constructor uses to set required member variables
The reason is because if it was all controlled via the emitter rather then separate widgets... it lets us create reusable objects more easily. If there is a generic widget you can put in your object being emitted, then you separate the logic from the initialisation.
So why is that good? It’s all about encapsulation. Let’s say we want to emit a loot drop. We could simply pipe a value into the emitter. This value could set what the item drop is, it’s cost/value, etc. All the emitter cares about is emitting the object and telling the object what it should be. Now the item uses the emitted widget and sets it self up. It doesn’t care what scene it is in. It doesn’t care if a wireless signal exists. It doesn’t care who or what it was emitted from. It just does what it is told by the emitter.
So now you could have enemies emitting loot upon death. You could have a player emitting loot when they drop an item. You could have a fountain spewing items out. Each time the emitter is in charge!
Currently to replicate this in Dreams you would have to do funny business with wireless emitter zones or with exclusive gates or some kind of fudge. While they work, you end up having to hard code things and it can be prone to hard to find bugs.
Finally, the method I suggest is a bit like constructors in “real” programming.
So you want to send a signal to emitted objects, why does it need to go through the emitter? Can't you use a Transmitter and Receiver?
If you don't need your emitted objects to be dynamic a really efficient way to get varying properties on a per object basis is to change the source on the fly. Each instance will reflect the state of the source the frame it was emitted.
Right--so really you want to send a value that's frozen for that instance, yeah?
I do that using a signal manipulator's freeze setting, myself. It's a touch fiddly to set up if you're not familiar with how things work, but it works how you'd like it to.
True yup but it’s not quite the same.
That would mean if I wanted to emit the the same object from multiple emitters then they are all infact tied to one set of logic. So you can’t create modular things.
If it was directed through the emitter then we can gain some OOP (object orientated) style logic and can reuse our emitted objects for many different tasks. The emitter would then be in control of how an emitted object acts. I could for example pass a "mode" value to the emitted object. When it is mode 1 it will glow. Mode 2 will rotate.. Mode 3.. and so on. Obviously I could create 3 emitters and have three separate things to emit.. but then what if wanted it to glow and rotate!
You can wire directly into and out of the object-to-emit, and turn on "emit with wires" on the emitter. Sounds like that will do what you want?