Since I went through the work of rolling it out into its own project, I figured I’d at least start a thread here. This was the networking library I was using Ethereal Space to test and had planned to release at some point. I’m hopefully going to be spending an upcoming week integrating this into Mythruna and one of the pre-steps was to properly package it.
Now, all that being said, it is nearly 100% undocumented right now. So it’s probably super puzzling to figure out how to use it. (Though generally, add the EtherealClient to your SM client services and the EtherealHost to your SM server services… then add listeners, etc… which is not a very helpful description in the end.) Only the most intrepid explorers may get anything out of it at this point.
Packaging it was partially for my own benefit since I’m more likely to be ‘clean’ and I may add some docs here and there as I relearn it to integrate it with Mythruna. But in the end, I’m not sure when I will get to documentation because reasons.
which has many open source implementation for client and server
and a server like mosquitto or a cloud service like cloudmqtt could be used as a server
such protocol was developed for IoT, which designed with low overhead taking in mind data from sensors with high frequency
Also it implement a QoS,
1 - fire and forget ( for broadcasting data with high frequency)
2 - Send at least once
3 - Send exactly once.
You are welcome to try. I think you will find that real-time networking a game requires more than just a transport. I also think that EE systems like Mqtt’s goals are different than SpiderMonkey’s.
I actually did a trial before, it was not a game it was more a 3d interface to a concept IoT program, it was monitoring a sensor installed in 3d modeled house, the state of each sensor reported serialized to JSON format over the mqtt text bases protocol
we use jmonkey First person shooter style game to explore a house an check the status of physical sensors, also the physical sensor changes instantaneously update the 3d model.
the good thing of this that we do not need to have our own server, we use cloudmqtt that act as our server.
But I agree with you , I think use case should be more into multiplayer game, I will give it a try soon.
And kind of understand that this has little to do with what Sim-ethereal is about. Even if you have a way to deliver messages then you will have to decide what to send and when.
Sim-ethereal buffers changes to objects within zones and sends only the changes for a particular client, heavily compressed, based on the nature of the data. For example, since positions are zone-relative, the number of bits used to represent the floating point value can be greatly reduced.
Because of the nature of the data, it uses UDP since new data often makes old data obsolete. Normal reliable-over-UDP transports that don’t understand what data they are sending can lose some efficiencies.
Even still, because of the way Sim-ethereal compresses things, it’s possible that a single object update takes only a handful of bits depending on what’s changing at the time. The idea being to pack as many updates in less than (1500 bytes - header size) as possible.
Indeed, what I propose may be not optimum in case if Sim-ethereal , but I imagine other alternative for multi-player game and MMO games.
I do not have enough experience in gaming, so I am trying to check with some with more experience the possibilities and limitation of this approach, and you thankfully give me a nice insights of your hand-on experience
I already working on use case now, in my learning project, i already need to add NPC as experiment I will try to control it using mqtt over internet ( i did it before with small robot ) and I will make a video for it.
It is not exactly the case of mutliplayer or MMO, but it might illustrate the performance and expected limitation
Some approach may be simple in theory but when get in reality it may go far more complex because of the framework limitations, to such dense packing I do not think there is a straightforward way to do such thing with the text based protocol like mqtt,
BTW : I find IBM has interesting show case with mqtt message insight
Yes, and to be clear, the 1500 limit I code to has nothing to do with the framework. It’s an attempt to get message sizes under the common MTU limit so that they don’t get broken up into multiple packets. The more packets there are, the more likely the message never makes it and has to be resent. This is one of the reasons that TCP based messaging will be horrible for real time synching… one little hiccup and you pause the whole channel for up to two seconds.
) and I will make a video for it.