I've read all 484 pages of Professional XMPP and read countless forum threads regarding rosters + XMPP and this question is still something I am struggling to solve. I'm looking for insight on best practices, so I at least know which direction to go in.
I'm building a cross-platform (web, iOS & Xbox), turn-based board game. Every player can have up to 100 different matches active at any given moment -- so they could easily skip from one game where it's not there turn to one where it is.
The game will feature a lobby where your list of active games are displayed, along with the name and online status of each opponent for that game (you may have up to 3 opponents, 4 total players per game).
Additionally, each player will have a friends list accessible from a different area which also lists online status.
I am using XMPP behind the scenes, completely transparent to the players, no one will ever sign in with a Jabber client or anything of the sort. I have complete control over how the information is displayed and utilized.
The main aspects I am using XMPP to solve are: notifications when an opponent has made a move, seeing my friends online statuses, and seeing my opponents online statuses, and in-game text chat.
So here's where I start having trouble: obviously your friends list will be contacts in your roster, so you can see their online status. But what about opponents? These are usually random opponents you will only play a single match with and never again -- yet your game with them may last up to 2 weeks.
Keeping in mind that everything is behind the scenes (ex: automatic subscription confirmations, etc) -- would the best course of action be to add each opponent to another group in your roster while the game is in progress and then remove them after the game is complete? That way you get presence notifications when that player is online? Or is this a case where PubSub could be utilized?
I've also considered using multi-user chat so I'd always have access to every users online status without subscriptions, but that seems far from efficient when there could be up to 20k players online at any given moment. Definitely sounds like a battery hog on mobile devices as well.
My other solution is to used share roster lists. Create a roster list for each game and assign that list to each player. Then delete the shared roster list once the game is complete.
I would choose Pubsub here. Of course, this means that you have to do some server side work too.
Send a directed presence to the opponents. This will allow them to see your presence.
I would consider using a multi-user chat for each game, and your own extension to the MUC protocol to handle game-state messages (opponent has made a move). The user can have a roster of their friends at the "global" level, but can still communicate with their opponents (and receive presence) using the MUC level (unless they decide to then add them as a friend).
See also: Advantages of Pubsub versus MUC
I agree that using MUCS (instant) would be better in this scenario. If you need to cleanup pubsub nodes of unwanted subscribers, it will definitely be a pain in the ass.
Related
I'm working on my multiplayer game. The game is about pvp, you can shoot your friends and all stuff like that. I decided to make a score widget, which would show who is better. You might have seen something similar to what I'm talking about in fps games like csgo, valorant, overwatch, etc. Everyone should see the score.
I tried storing variables on servers character pawn. But pawn can be destroyed and score rollbacks to 0:0.
For replicated data that is persistent to respawn, you have two main options with the built-in game framework:
Create your own subclass of AGameState and the replicated data you want in it. There is one Game state and it is replicated on all clients. See what the official wiki (bottom of the page) says about GameState. You can store game-related data in it as total kill count in team deathmatches or team capture points in domination matches.
Create your own subclass of APlayerState and the replicated data you want in it. There is one Player state per player and it is replicated on all clients. See the official API of APlayerState. You can store each players' kill count in it for example or the number of objective a player captured. Make sure data is fed from the server and replicated to clients and not the other way around.
Unreal Engine comes with a powerful Game Framework, make sure to get familiar with it.
I've recently been playing with the new MUC-Sub module in ejabberd - the use case being I need to have WhatsApp-like permanent rooms in my mobile app. Before I go too further into using MUC/Sub, can an ejabberd expert opine on the below concepts please? Is probably a lack of full knowledge of ejabberd on my part, hence the basic questions. Or else do let me know please a good place to start understanding the below better... I did study these two links in detail already (https://blog.process-one.net/xmpp-mobile-groupchat-introducing-muc-subscription/ and https://docs.ejabberd.im/developer/proposed-extensions/muc-sub/). Thanks!
Essentially, if we need an MUC room to stop being destroyed when all users go offline, could we not simply disable that feature - so that the service continues to operate even when participants leave or the room is empty. The service could still be made to continue pointing to the original room participants who joined the room, and in case there is a message sent in the room, the message would get queue up on each participant's stream. If a participant is offline, the message would enter his / her offline messages list (instead of the archive / MAM that MUC-Sub is currently utilizing). Why did we need to rely on the Pub-Sub and MAM model if this problem could have been solved using simply retention of the participant's reference in the room (even after he / she goes offline) and then leveraging the mod_offline module (which should happen automatically).
Am sure there is a fundamental reason here that am overlooking but appreciate if someone can throw some light please!
As the blog post explains, this is not a matter about keeping chat room alive or not. The fact that users cannot receive pushes when offline or when they reconnect, if they do not join again, is because MUC is based on presence. A user that is not present in the room is not an occupant of the room and is not supposed to receive anything.
I recommend you read careful XEP-0045 MUC and MUC Sub blog post again. The issue MUC Sub solves should be more obvious.
If you do that, you will notice that XEP-0045 define the idea of persistent MUC:
Persistent Room
A room that is not destroyed if the last occupant exits; antonym: Temporary Room.
Default in ejabberd is to create the room as temporary when a user joins, but the setting of the room can be changed so that it becomes persistent. In that case, it is not destroyed when the last occupant leave. You need to change room configurations option (same form you used to enable MUC Sub on that room).
You would generally want to combine this option for the room with MUC Sub enabling, so that MUC room are kept around even if no user are present in it.
I would like to create a game mode 2vs2 with our friends. I have no idea where to start off. How can we send them notification regarding some of our friends is looking for party. I think this is probably we would have to take care of through push notification from our server and then once other player joins the room how can we create room properties so that both of us remain in the same team. Do we need to create a private room in that case or what ?
When working with PUN and Photon Cloud, you need to connect to a master server first (PhotonNetwork.ConnectUsingSettings). Then create a room or join existing. PhotonNetwork.JoinOrCreateRoom should work in your case. Players should share same room name before creation or joining a room. Notify them outside Photon by any means you like.
Inside a room, player custom properties can be used to mark which team player belongs to. Assets\Photon Unity Networking\UtilityScripts\PunTeams.cs script goes with PUN package. Use it as is or as a template for your own teams implementation.
Don't forget set max player = 4 when creating a room to prevent extra players getting into room if more than 4 player know its name or via room matchmaking.
Follow doc.photonengine.com for more info, documentations and tutorials.
Last semester we had to develop the game Ludo in JavaScript and HTML/CSS. That was pretty easy. Now we have to develop a backend with GWT (Java) to create a multiplayer game. Sadly, we haven’t got much information on how to develop with GWT and the exercise is quite difficult at the beginning.
At the moment I am trying to create a kind of lobby where different players can join.
My idea was to use some input fields, where the player could enter his name and join the lobby. But I don’t know how to give the other clients the information that a new player has joined.
I created an asynchronous interfaces (RPC) where a player could submit his name to the server (Like this example). This works ok. But how should I share this information? Our docent said we should use JSON to share information’s, but I don’t know how this should help in this situation.
Is there a way to send information’s to the clients? I read a lot and just find to use additional libraries as gwt-comet.
I have really now clue how I could go on. I’m thankful for every help and information!
Greetz
You have two options: push and pull.
"Pull" option:
Other players get required information when they join the lobby and/or do something else. You can also schedule to pull this information periodically (like once every 10 minutes). You can use the same RPC mechanism to get data from server to a client. "Pull" means that a client initiates the request and server responds with the information.
"Push" option:
When a new player joins, the server pushes this new data to all other players. The best solution depends on your game implementation. Comet is a good option, as Jean-Michel mentioned, but it's more complicated and "expensive" from resources point of view. You should use this option if you need real-time status updates for your game.
I would suggest Errai and ErraiBus in particular. From Java perspective you are only sending some events via event bus (observer GoF pattern) and all the magic with Ajax Push is happening behind the scenes.
I am willing to create a two-player quiz game, in real time. For this I need to track when users are on my quiz's page and when they leave it. Basically, I need some kind of lobby, where players gather and from where my script picks two random players who should face each other in the game.
As many players would switch from online to offline in a very short time, I prefer not to use the classic 'update player status to database and then retrieve at a given interval the list of online players'. Currently, I am toying with the idea of using Comet Push, and have studied a little bit PubNub.
The actual quiz game I believe it is pretty easy to solve: use of classic Comet publish() to send answers and subscribe() to check the other user's status. But the thing that bothers me is how do I get that specific list with online users?
I tried to publish() a user_id when a user goes to the lobby, but how do I notify all the other users when this user goes offline? How do I display in the lobby the total number of connected users together with their names?
It's the first time I face Comet and its logic isn't entirely clear to me.
Thank you for your help!
You might want to try out Pusher and our (I work for Pusher) presence functionality. The presence channels let you easily implement room/lobby-style functionality and should meet your criteria.
You get an initial list of users subscribed to the channel when you subscribed
You are informed whenever a user subscribes (enters) and unsubscribes (leaves) the channel (room/lobby)
This way you don't need to implement this functionality yourself. It's part of the solution Pusher provides.