Allowing multiple "Multiplayer" plugin instances

As always, I never know how "small" a change might be, and will ask as feature request, but on the tiny hopeful chance that it's a simple tweak for Scirra:

Having the ability to add more than 1 "Multiplayer" object.

Would it be as simple as Scirra flagging this plugin as a plugin that can add multiple instances? If so, I YEARN for this! If not and issues occur, feature request it is.

May I politely ask if Scirra could test behind closed doors, chuck Multiplayer as a multi-instance object type, just to roughly see if two coexisting Multiplayer instances do load, see if theres overlap issues with 2 or more instances, and if it's really as "straightforward" as that (I can only hope!), I'd loveeee LOVE to see this as an addition.

If it does work suprisingly easily, I can ASSURE you I will set much time aside and will beta test the heck out of it and try to find any issues or crossover issues.

I'm a huge fan of the multiplayer plugin and use it extremely often and am trying to reach great achievements with what we have.

---Below is more explaination as to why---

The reason I felt to ask on forum first, is, I seem to recall a friend had managed to tweak the old C2 multiplayer to allow multiple instances, and no issue was reported and they progressed far and they succeeded in making some of the systems I will list below. They reported no cross-issues between the 3 multiplayer instances, and it worked exactly like I hoped.

I keep thinking of ideas to implement into my game and making the online mutliplayer aspect very ambitious. I can get quite far in current state, but lots of "Disconnect and reconnect to different system" sorta thing - Plus inability to have two ongoing systems (E.g. can't be in a public online game AND have a one-to-one "Whisper/DM" or "Party Chat" or "Friend Chat" if you group up).

I think this could open some avenues for:

1) MMO-style login server systems, usually having a "Login Server", "Channel Server", and "World Server". (Not saying MAKING AN MMO and such, but the theory of that system could be done, as a remained connection to each of those is required (e.g. the Login Server can send a "kick" which kicks from ALL servers connected to if the player was banned or something).

2) An overarching "Alert" server, for the game dev to sent out status notes, such as "Server reboot in 10 minutes", much like is seen in online-based games such as Team Fortress 2, or MMOs again (NOT Trying to make an MMO here!)

2) Enabling true "Whisper/DM" in a game (as we know currently we must feed chat messages to HOST, so cannot whisper without host also receieving this).

3) Buddy system - Have a buddy list, can request to chat to a buddy (and thus the buddy server pings the player B buddy for a chat request), and also block list. In current 1-instance Multiplayer, if in an online game, you cannot view or interact with the buddy list.

4) Data retrieval - If someone wished to make a VPS server that sends back some data from a database or from stored C3 data, could act as an excellent middle-man for this, with all the comfort of designing it with C3 rather than traditional methods.

5) Some games have group chats, like chat to all, chat to party, chat to guild, etc. Currently impossible to do privately since messages reach host every time.

6) More of a "benefit" for someone attempting something like this in its current state, but currently I foresee the issue right now I may encounted without multiple "Multiplayer" instances, is: "connect/play game/disconnect/connect to different connection settings/Use it/disconnect/connect elsewhere/chat to friend/disconnect/join online game/disconnect/wish to view some stats from a VPS server that the dev setup with C3 running, connect there/disconnect/join online game.

And many more. It legitimately excites me to think of a world with "Yep, add many multiplayer plugins", I see myself renaming them to the appropriate system it looks after.

I know exactly what you're all thinking - "Do it the right way, use node/PHP/SQL etcetc.". I do intend to use a hybrid of traditional elements, especially for sensitive data such as login credentials, but to be able to manage most of these smaller gameplay-wise systems with a front-end I've designed in C3, would be like another level of high power in C3 that would make me race to implement all sorts of systems that interconnect. I am a slow learner and I guess would need to research for a huge amount of time and seek advice to learn and accurately implement these traditional elements, but oh man, if it could be done in C3, it'd be a literal dream.

I know a few others that wish to go beyond with ambitious multiplayer systems, they also agree and wish for this (such as the old friend that solved this in C2 - but of course it's never ideal to modify an existing addon from Scrirra).

If this took Scirra a milisecond to implement, then WOOHOO, but if not, feature request it goes.

Even if we did this, I'm not sure it would be sufficient for all those use cases - if you want something like a private message channel to multiple users, or different levels of group chat, then you need a dynamic number of Multiplayer instances. Even if you can add more Multiplayer instances, then how many do you add? Then setting up your event sheet to be able to manage them as if they were an array sounds complicated.

Things like an "Alert" server that just sends a global message out every now and then would be a relatively simple case for a WebSocket connection to a custom server - re-using Multiplayer for that seems a bit overkill.

Another option is to run the host on a traditional headless server - it's not especially straightforward to set up, but then you have better privacy as things like private messages are routed via a generic server rather than a player's machine. Even with the host being a player, it's possible to set up an encrypted messaging system between two peers so the host still can't read their messages, but that's a fairly complicated cryptography case. (Maybe the Cryptography plugin could help...)

So I think if we wanted to do this properly, the single Multiplayer object alone would have support for connecting to multiple rooms simultaneously. I think that would be a pretty complicated change to make though. Even if adding multiple Multiplayer objects is straightforward, in the long term there will probably still be a need for truly dynamic room joining, and so there'd still be a need for the proper multiple simultaneous rooms support; then if we did implement that, we're left with a messy design, as there is no longer any need for multiple Multiplayer instances but we're stuck with that short-term measure for backwards compatibility reasons. So with a long-term view, I'd rather do this the proper way, even if it's more difficult. It's always tempting to choose the easy option, but it can make a mess in the long term, and we'll still be here dealing with that.

Thank you Ashley, very thoughtful and insightful reply.

I was locked-in on the idea of using C3 all the way, but the note about WebSockets has swayed me - Not familiar but have been looking into this now.

I've read almost every page of the Construct documentation, but failed to ever pay attention to the WebSocket section - I did not know you could send/receive binary data this way!

I can still see desire for "private messaging" being p2p, but this isn't an absolute necessity, considering we have options to encrypt and such - There could be a viable path here.

I think I can get very far with what I was hoping to do, with a combination of Multiplayer & a WebSocket server - Since could be in a Multiplayer game, but utilise a WebSocket server for a few extra features whilst the multiplayer game continues to run.

Thank you!

EDIT: For anyone reading this that also is curious about WebSocket servers, be mindful it's not something you can just setup in C3 or anything - It requires a server, and requires networking knowledge on setting this up and such. Worth learning about but be mindful it may be a lot of learning to do, depending on your IT knowledge. construct.net/en/make-games/manuals/construct-3/plugin-reference/websocket

fongka2 - you haven't explained your use case, so it's not clear if you really need this or if there is some other better way to achieve it. For example with the limited alias length, it seemed to me using a message was a better way of achieving that - there was no need to store that data in the alias. Perhaps the same is the case here, but it depends on what you're trying to do. This is why our feature request guidelines include providing an explanation of these things - otherwise you're not really making a convincing case for a feature.

I often push back on feature requests, and the main reason is we perpetually have about 5 year's worth of work on the feature requests tracker, and so it's unlikely that we will be able to implement any specific request very soon, so it's important to establish that the idea really is important and doesn't have any good workarounds. Another reason is often when you dig in to what people are trying to achieve, there is already a solution, or at least some kind of workaround. So it's important to properly understand feature requests - and that sometimes means pushing back on them and asking questions - to avoid ending up spending our limited time on features that weren't really needed.

fongka2 - you haven't explained your use case, so it's not clear if you really need this or if there is some other better way to achieve it. For example with the limited alias length, it seemed to me using a message was a better way of achieving that - there was no need to store that data in the alias. Perhaps the same is the case here, but it depends on what you're trying to do. This is why our feature request guidelines include providing an explanation of these things - otherwise you're not really making a convincing case for a feature.

I often push back on feature requests, and the main reason is we perpetually have about 5 year's worth of work on the feature requests tracker, and so it's unlikely that we will be able to implement any specific request very soon, so it's important to establish that the idea really is important and doesn't have any good workarounds. Another reason is often when you dig in to what people are trying to achieve, there is already a solution, or at least some kind of workaround. So it's important to properly understand feature requests - and that sometimes means pushing back on them and asking questions - to avoid ending up spending our limited time on features that weren't really needed.

Multi Multi player, can you implement it for us? The benefits have already been explained by the OP. hope it will be accepted and updated quickly. I'm ready to release this game but it's quality is currently very poor through iframes. If there were multiple plugins, this game would amaze the world.

(or maybe allow entering multiple rooms simultaneously)