Howdy, Stranger!
It looks like you're new here. If you want to get involved, click one of these buttons!
Quick Links
Categories
- 7.8K All Categories
- 11 Help with translations
- 4.2K General questions
- 107 Roadmap
- 358 Game & application design
- 316 Plugins
- 70 User experience
- 75 Marketplace
- 291 Code snippets
- 34 Building a team?
- 269 Suggestions & requests
- 352 Announce your apps made with Gideros.
- 90 Step by step tutorials
- 668 Bugs and issues
- 195 Introduce yourself
- 239 Announcements
- 106 Forum talk
- 404 Relax cafe
Comments
This is what I want to do:
1. Player A subscribes to channel and sends static properties to all players
2. Player B subscribes to channel and sends static properties to all players
3. Player A sends their static properties only to player B
Brainstorming how this could be done with Noobhub I've come up with two (inefficient) options:
Option 1: Player A and B create a new instance of Noobhub and subscribe to it to send this message. This is not ideal because it requires a new connection to Noobhub for all players already subscribed to the channel when player A joins, and they also have to wait for player B to subscribe before they can send the data to be sure they get it.
Option 2: Player A sends their static property to the entire channel. This is not ideal because all players already subscribed to the channel when player A joins will receive redundant data.
Is there a better option I'm overlooking?
If you didn't have to subscribe to a channel to send messages to it all players could have a public and a private channel, and these messages could be sent directly to the private one. In my tests it appears you have to be subscribed to a channel to send messages to it, though.
It uses public and private channels.
Maybe I missed something in your code. Any idea of how to achieve the flow from my previous post?
1. Player A subscribes to channel and sends static properties to all players
2. Player B subscribes to channel and sends static properties to all players
3. Player A sends their static properties only to player B
Or maybe there is a better way for players to share their static properties.
Yes you are still sending it to all users though
But then clients should unsubscribe and subscribe to uniq channel where game interaction should happen. Thats generally called matchmaking.
First, you find out who is up for a game, and then send message "user_XXX_pls_join_uniq_channel_YYY". User XXX joins that channel, and there you go.
Creating another instance of Noobhub is no big deal (I always do that in multiplayer). Nodejs server can handle really high concurrency, up to a million on hi-end hardware and synthetic tests.
Once your game reaches 1M concurrent users, Id say you've known success :-)
Likes: jdbc
I suppose Noobhub is better suited for a set number of players and games with a start and an end, rather than games like Agario, or chats for that matter, that are ongoing and the player count is variable.
Although, private messages would solve this particular issue, as would sending messages without having to subscribe to a channel first. Would either of those changes be a bit tricky technically, or maybe just the wrong thing for this kind of multiplayer backend?
I'm used to multiplayer servers that rely on each message or action being verified by the server. Noobhub appears to be less strict, and allows a message to be sent together with the subscription of the channel.
This means I can send a private message to a player without first having to wait to join the channel.
So for:
"3. Player A sends their static properties only to player B"
I simply do this:
1. Each player is subscribed to a private channel named by their unique ID
2. Player A subscribes to player B's private channel
3. Player A immediately sends their static properties to player B's channel
4. Player A unsubscribes the channel immediately
Because of the way Noobhub works, player B gets the message and all is good in the world. No redundant data is sent or downloaded by clients at any time. Boom!
For now I'm commenting out the code for the other platforms.
Likes: antix
Likes: antix
Personally I don't think there is any need for "__ENDSUBSCRIBE__" but I thought I would ask here in case there are any ramifications I haven't seen.
I'm now working on decoding the JSON strings sent from the client and performing operations on them inside noobhub. The decoding turns out to be rather trivial once you findout that JSON functionality is built into node.js
I was wondering about shortening the start/end strings. My impression was that this is risky, because the sever doesn't see the each individual message, rather it sees a continuous string if data. So if any of your messages contain "BD" or "ED" there would be an issue. Not sure if that's true?
Likes: antix
But shortening the markers is an OK idea, if in your specific case they will _remain_unique_.
Likes: antix
After looking about in the lua code I see that in the enterFrame() function you are searching for "__JSON__END__" from the beginning of self.buffer which is causing the issue. Instead you should search for that at the very end of the buffer (minus the size of the string you are searching for), so in the case of the original noobhub...
Just modify the code as in my post and you shouldn't have any issues.
On the other hand, last time I touched Gideros port was a long time ago...
>> If any client sends __JSON__END__ (or whatever identifier you use) as part of their mesage
Don't send such markers in messages :-)
Or replace markers with your own very unique ones.
Likes: antix
*edit*
With the exception of multiple messages in the buffer I think
Likes: antix