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.
Related
We are implementing a chat application using Pubnub and in a short span of time, the number of channels for each user has reached into hundreds. In order to improve performance, I need the listChannels method to return channels in the most recently used first order rather alphabetical order which is of not much use to me.
I am hitting one roadblock after another and I very seriously considering ditching Pubnub altogether as it is creating more problems than solving them for me. Please help me with this.
Channel Groups were not implemented with what you had in mind. But you can keep a local list most active channels. Everytime the user publishes to a channel or receives a message or whatever your requirements are, just update this list.
I had an idea tonight. Its about developing a game on Alexa where she is telling you a Story and you are the Player who is able to direct the Story in any way he wants to with the decisions he can make.
So an example would be:
[Some Story] .. where do you want to Go:
Pub for 50$
Hotel for 100$
Stay outside for freue
And the User can now decide where He wants to stay and then the Story continous and for example if you stay Out you get robbed and if you Go to the Pub you wake up with headache the next day.
So my question is how am I able to realise this in a smart way so the decisions can affect the Story Line.
My First thought was to Store the complete Story in a 2d String Array to Jump around different Stories but if this becomes a bigger there must be another way.
And I need to be able to Store the Point where I Stopped. Yet I have no idea of how to die this.
You can store the story and the user's progress in a database, either by writing an Alexa skill which sends requests to an Amazon Lambda function you would write or a custom web service you would write. Check out this documentation for how to get started writing Alexa skills.
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'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.
I'd like to have something in my app that is just like Twitter but not Twitter. Basically it will be a place people can submit messages and do not need an account. They only way they can submit is through the app. I want other app users to see the submitted messages nearly immediate. I believe push notification can do that sort of work but do I need push notification for this? How does Twitter do it?
-- EDIT --
After reading some of the responses, push might be what I need. People will be submitting messages to my server often. If someone is watching the feed, they might see one new message per minute depending on the query they are using. I'm thinking to go with a MySQL database, (which allows switching to cheaper non Windows servers w/o much hassle) and push notification. Are there any reasons those won't work for my scenario?
You only need push notification if you want the app to be able to receive new messages while closed.
Here's a rough description of one way to do this:
Your app sends a message via HTTP Post to your server.
Your server stores the message in a database, using the iPhones unique ID as an identifier.
Your app connects to the server frequently, asking for new messages.
If there are any new ones, the server hands the message to the app, which displays it.
This is approximately what twitter/iphone twitter apps do.
Your choices are fairly binary:
Use push notification
Use Polling
With Push Notification:
You control when you contact your users... Heavy Load means you can slow updates down to avoid taxing your infrastructure
Contrariwise, you have to push to clients that may not even be there anymore (And thus may need some sort of register model), high load may mean that clients don't get immediate update
You can leverage things like Amazon's EC2 to give you more processing power
Unless you're out of capacity, users are almost certain to be receiving updates as they happen
To pick up messages missed while offline, the SERVER needs to know what message was last successfully received, store older messages and forward many all at once
If you choose to use polling:
You must have a stable address to be polled
You need the ability to have lots of quick query connections checking for new data, then returning that data if required.
If your application becomes popular enough you may find you don't have enough resources
If your resources are taxed your application will go down, rather then just slow down
You don't need to register clients and keep track of their on/offline state
Parallelizing on the fly is a bit trickier
To pick up older messages, the CLIENT needs to know when they last received a message and then request the server send any message since that time
Both can be fast, but they come with different bandwidth and processing profiles. I prefer push for everything that's real-time.
Might want to take a look at XMPP.
Twitter doesn't really push events out to the iPhone in realtime. It's more like polling by the various clients.
If you really want instantaneous for the last mile you'll want to use push.
Twitter uses lots of servers and raid arrays to handle the load of millions of people posting 140 character messages. Twitter clients log in and request a list of updates for all of the people the user is following within a certain time frame.
Push wouldn't be a good candidate for this because it does not persist the "tweets". It is simply a notification mechanism. There is a text messaging app on the App Store (called Ping!) that relies completely on push notification for sending text messages. This seems to work fine, but if the developers are keeping track of the messages, it is all done on their servers. In their case push makes sense as you want to alert the user of a new message. In the case of a twitter clone, however, it would probably just annoy users if they got a new notification every time someone tweeted.
In the end you're better off just implementing it server side and then developing an iPhone client that logs in and retrieves the latest tweets for the people the user is following.