Basically I want make a social game like poker, in which multiple players gets connected.
But I don't want server side interaction.
So my idea was to make one person's browser acts like server and other acts as client.
Person A's browser will hold the data( client side DB) and communicate with person B via web sockets or something.
I am not sure if two browsers can some how connected with sockets. Either web sockets(HTML5) or any flash plugin which can help to IP to IP connection. Is it possible somehow?
As of now I am not even sure how users will connect for starting the game. I may need to put server for initial connection.
Currently you cannot do this with web browsers because they cannot act like a server. It will probably be possible in the future though: Chrome is experimenting with a Socket implementation (this is an experimental feature in Canary releases that is disabled by default). Node.js has already (partially) been ported using chrome.socket.
With Flash, it is possible to create p2p multi player games since version 10, but you still need a central server to setup the initial connections between players. There's a library for it here: http://www.flashrealtime.com/p2p-game-lib/.
Be aware that p2p multi player games make it easier for players to cheat, because the authority lies with one or multiple players, and not with a central server.
It's not possible for a browser to accept a websocket request so a server is necessary for you to handle such a request. For how to set up a websocket server, I recommend socket.io that is based on node.js. It's very easy to use and it's only javascript that is a language that web developers get used to.
Related
Is there a way to stream a video and audio on a website just to the clients, using a camera installed on the server - for instance, like youtube does ?
I've started reading webrtc, but if I use webrtc I should create a stun/turn server and other things, which for one way stream I think is not necessary (this is just my understanding of the things..) because I don't need anything from the clients, literally, neither their video, or audio..
So is there a way to achieve this using html5, streaming just in one direction:
server (camera) -> clients
Is there something about this out there, or should I stick with webrtc ?
I'm going to explain a possible solution for this scenario, there might be others, but I hope mine gives you a rough idea of how you could do it and a start point to explore more about the amazing possibilities of WebRTC. Please let me know if something is not understood.
So, WebRTC is a free, open project that provides browsers and mobile applications with Real-Time Communications (RTC) capabilities via simple APIs. Sweet, that is: WebRTC has a quite good browser support (not in every browser though, Safari just started supporting it a month ago with Safari 11). But in this case we want to use WebRTC in the server side. At the end of the day we can still think about peer-to-peer real time communication, where one of our peers is the server.
I don't know if you are familiar with Node.js, but I recommend you to write your Server app with it (<3 Javascript!):
There are a few libraries that wrap WebRTC functionality to be used in the server side, like node-webrtc and node-rtc-peer-connection.
But I recommend you to to take a look at electron-werbrtc, since
the others might be using deprecated methods or be incomplete.
electron-webrtc runs a headless Electron client in the background to
use Chromium's built-in WebRTC implementation. So with it you should
be able to access the Camera in your server and create a stream to be
served to the other peer (the browser).
All above would be the WebRTC related tasks, in this case: streaming video peer(server)-to-peer(browser).
Now, let's talk about signaling process, stun and turn.
Signaling: imagine now a scenario peer-to-peer with 2 browsers, they want to establish a direct connection and stream video and audio between each other. But they don't know each other, like if I don't know your home address, I can't send you a letter. So they need a service that helps them know each other, so they can have the other's IP. This should be done by what is called "a signaling server". If somehow you know the other peer IP, you wouldn't need a signaling server.
STUN/TURN: the scheme above works perfectly in a local area network where each peer has its own IP address and there are no firewalls and routers between them. But otherwise, you can have peers behind a NAT or firewalls, and then your signaling server won't be able to make both peers to discover themselves. If you have peers behind a NAT, you'll need a STUN server, and if you have peers behind firewalls you'll need a TURN server. This is a bit simplified, but I just want you to have the general picture of when you might need STUN/TURN servers.
To better understand Signaling, STUN and TURN, there is a very graphic article that explains them perfectly.
Now, for your scenario:
I think you prob don't need STUN/TURN servers and also you prob don't need to implement the signaling process, because the browsers that are supposed to receive the stream from the server will know that server address, right? So they can establish a WebRTC connection with it.
EDIT: it is likely that you will need to implement some sort of handshake between the server and the clients (browsers), so this will be the signaling process. This is not part of WebRTC and this is why you need to implement it yourself. As I said, it is the way 2 peers can discover each other, but they also exchange information as their local media conditions, like codecs, resolutions they can handle, etc. For your case, your signaling server could be hosted in the same server you use to strea: you can build a small node.js app that runs there and that manages all the signaling process easily, it is not a big deal. I recommend you to read this article, and specially the section "How can I build a signaling service?". In general all WebRTC articles from that site are very helpful.
Does this make sense to you? I think with it you can start digging a little bit more and see if with this is enough or you need to implement more stuff. Hope it helps!
I can go to the webpage https://open.spotify.com and select songs that are then immediately played on my desktop spotify application. How does this work? I could imagine a scenario where the webpage sends a request to a server which then tells my desktop application to play, but the website and my application seem too in sync. Sure the web is fast, but the song time counters are perfectly in sync and there is no lag when I click play.
I guess they could do something clever with syncing the song time counter, but I'm wondering if they're dong something even more clever: not using a server at all.
So the real question: Is there a way to have direct communication between a webpage and an application running on the client?
The mechanism is described on How does the Spotify web browser button interact with the Spotify app?. When you install Spotify's desktop application, a process called SpotifyWebHelper runs in the background. This process acts as a local server and receives requests from open.spotify.com to interact with the current playback. As you see, there is a way to communicate a web site and a local application.
It's worth noting that there is an increase concern by browser vendors about this mechanism (see https://bugs.chromium.org/p/chromium/issues/detail?id=378566) and it will stop working at some point in the future. A more future-proof solution could be based on a proxy service that gets requests from the web page and updates your application, and viceversa. Web sockets are a good candidate for this. Although the proxy, acting as a state management service, introduces some delay, it also allows for some other use cases: eg you don't need to have the application installed on the same machine on which the web page is browsed, and one could for instance control a mobile client.
I'm creating a game with HTML5 and javascript, but am having trouble finding a way to get networking working.
What I want is for one instance of the game to listen on a Websockets/http stack, while the other instances connect to it.
So far, I'm yet to find any way of doing it that doesn't require additional plugins or online services. (ie: Flash or silver light opening the socket and pumping messages back - Something that isn't acceptable for mobile, or an online server like Player.IO, which while much better than Flash, wouldn't work for Wifi networks that are disconnected from the Internet)
While the latter option is a compromise I'm willing to make, I was wondering if it's one I need to make, or if I could survive without it.
Well, if I understand what you are trying to, hope to be right.
Client One:
Plays game, listens to incoming data from Client Two
Client Two:
Plays game, connects to Client One
I'm guessing it's a P2P game? If this is the case, I think you want to look at WebRTC.
Otherwise, peer-to-peer is not really possible unless you run a mediator service that both clients connect to and handle it as a dispatcher.
I'd like to build a 2-player turn based game with an authoritative server to manage the game state/logic. The flow I have in mind is something like:
Players are subscribed to a unique game channel (via pubnub/pusher/something similar)
Players submit their turns over HTTP directly to the game server
The server runs the game logic and publishes the result to the game's channel (which both players are subscribed to)
The client handles the response and renders the outcome
matchmaking kind of confuses me though. Any suggestions?
Is that the "right" way of using a pub/sub service in this scenraio? Is there a better approach (something other than polling the server constantly)?
This is a heated topic at our office! I've been using PubNub as an authoritative game server using creative choice of channel names. It works like this:
Run a node.js server (doesn't have to be node; can be anything) that serves your content, and also acts as an authoritative entity.
When a client connects, generate a UUID (can be done either server-side or client-side) and have both the client and server listen on that channel (something like "my_game_[UUID]").
Because no other clients know this channel name, the client and server can communicate freely on this channel.
The server can talk to everyone, and clients can perform secure actions through the server and communicate with each other using an "unsecure" vanilla pubnub channel.
Your proposal sounds great and is the "right" way. The challenge you face is shared from the beginning of the computer epoch, where synchronizing data is a requirement between multiple devices such as a mobile smartphone. Polling is SLOW and expensive (and does not make sense for a large number of players). Multiplayer games is a great example need to pair players and provide game rooms. Your solution is to:
Create a Game Lobby, where players can create game rooms and join game rooms.
Create an Auto-Pair of players (Quick Join) [Recommended]
You may solve this technical challenge with products such as Socket.IO and some other open source options. However you want to just build your game rather than focus on deploying a Node.JS server and hooking it up to Express.
Instead use a Cloud Service like PubNub, PusherApp or Beacon Push. Utilize the Pub/Sub API to synchronize users in a multiplayer environment easily.
What is a good framework to build a multiplayer game in Actionscript?
I want to create a multiplayer 2D shooter like Asteroids on the Blackberry Playbook; my main concern is latency - a shooter wouldn't be fun if the bullets are super-jerky and unexpectedly hit people.
I'm guessing that a UDP-based framework would be the best. Can anyone point me to the right direction?
There are many things you can use off the shelf but the basic setup is very simple but you have a few options.
The most common is server push, things like Flash Media Server, LiveCycle Data Services from Adobe or other tools like SmartFoxServer can do this. With this setup the server saves the connections to everyone that connects to the server and passes or "pushes" applications state to the people connected every time the data changes in the application.
Another option is called long pulling, this can be done with any web server really. How this works is the data stores the state of the application, when the application starts it calls the server, when it responds the client calls the server again.
There are a few other ways to do it but these are the most common. But this has nothing to do with protocol like HTTP, UDP, AMF, XMPP, or whatever else. The protocol is the format that the data is sent. With these out of the box servers they normally output a few of these but the fastest formats are binary like AMF but not always the best, there are advantages to each, because each gives you different features for keeping track of things.
If you are talking about have a game that takes over the world that has millions of users then you need to think about scaling and what happens when you need two or 100 servers and how do they talk to each other. But for now keep in mind that the more the server does the slower it will get, if you are sending small amounts of data it will be able to handle more users. Stick with making one efficient server and worry about that later if you get there.
You also need to thing about what server side programming language you want to mess with if any. Some services don't let you do anything, these normally cost money and don't do as much. Adobe likes Java but there are servers that output all of these protocols in most every language. My favorit lately has been Node.js a super fast way to run JavaScript on the server. Node.js has a built in HTTP server but it is just as easy to create a simple server that sends basic text through a Socket or XMLSocket. A server like this will easily handle many thousands of users. There are many games that use Socket.IO and if you want to see a simple example of what I'm talking about you can check out this.
Assuming you want to use Flash/Flex and not Java (Blackberry/Android) or native SDKs for Playbook -
There is a book as an inspiration: http://www.packtpub.com/flash-10-multiplayer-game-essentials/book it uses Pulse SDK at the server side. But you could use an own sockets-program on the server side. I use Perl as TCP-sockets server (sends gzipped XML around) in a small card game but this wouldn't work for your shooter.
Flash does not support UDP out of the box
But there is peer-to-peer networking protocol RTMFP in the upcoming Flash Media Server Enterprise 4 (price is out of reach for mere mortals)
So your best bet is to buy an Amazon-service for RTMFP then you can pay-per-use and stay scalable...
You can either do a constant post/get request with the server to get data for the game, but for a multiplayer shooter i'd surgest SmartFoxServer: http://www.smartfoxserver.com/
Out of the box, Adobe AIR supports UDP through datagram packets.
http://help.adobe.com/en_US/air/reference/html/flash/net/DatagramSocket.html
I couldn't find a particular networking API for flash, but perhaps you can build one. Libgren is open source and you can use that for reference.
You can also look into RTMFP though it's focus is on transmitting audio/video and some messages (through TCP I think).