Is there a way to use a mobile device as a pad on desktop?

[totallybueno]

Hi there,

a new client wants to make a html game (pretty basic racing game) on desktop browser but using a mobile device (on the same wifi?) as a pad to drive your car... Anyone with experience in something like this? Any way to sync that?

[Jammy]

Just imagine you were building a multiplayer game without the multiplayer. Your mobile device is player 2 and sends controls, your desktop is player 1 and receives controls and updates the screen. You could use either a sever on the desktop as the comms layer or you could try WebRTC and make some form of peer to peer connection. (http://peerjs.com/)

[bruno_]

That's how airconsole works: https://www.airconsole.com/

[Antriel]

AirConsole uses WebRTC/p2p? On their developer info page they mention:

Quote

Auto-scalable infrastructure on Google Servers on multiple continents to handle massive traffic and assure a low latency.

Which suggests standard client-server architecture.

[mattstyles]

webRTC isn't well supported (and probably isn't a natural fit for this) but you'd actually only need REST, the controller could just send requests which the server then handles, you'd just need to associate the controller with another client, of which there would be a number of ways.

In the event that you want the controller to change, maybe change layout or options, then you'd need a way to tell the controller to change, in which case websockets would be best (you could poll, but, most higher level websocket libraries, such as socket.io, have fallbacks to polling in the rare scenario websockets are not supported).

[bruno_]

36 minutes ago, Antriel said:

AirConsole uses WebRTC/p2p? On their developer info page they mention:

Which suggests standard client-server architecture.

Sorry, I was talking about using a smartphone as a gamepad, not about webrtc/p2p

[totallybueno]

2 hours ago, mattstyles said:

...but you'd actually only need REST.

Sorry the noob question here, but, what do you mean? I´d need a REST API?

 

 

[b10b]

AirConsole Latency - worth a read:

https://docs.google.com/presentation/d/1t40cmrv7NT45rRwsJUXqZC2uOmZBS0Cbs9jG1J_Jdzc/edit#slide=id.gd83ddb292_1_76

AirConsole has some degrading network tiers built in, so if WebRTC isn't available it'll fall back to WebSockets, and then down to long polling / HTTP.  On paper it looks very good.  However in practise a Node + socketio (or variation) may work just as well (in many scenarios) and keep 100% of the control (and issues) in your own domain?

But, technicals aside, the challenge with secondary-device-as-controller approach is two fold.  First a decent arcade style game can't afford even a 50ms delay in controller input to visual feedback, let alone 300ms.  Second a touch device is a poor joypad - much worse than a keyboard or actual joypad - so where's the use case?  Such challenges suggest new game genres are a better fit - for example turn based games where the controller shows information not available on the main screen.

[totallybueno]

Yes, I completely agree with your last paragraph, but the thing is that the client wants "to be cool" and wants to let the users play the game with their own smartphone, they say it´s a really good marketing strategy blah blah blah...

Also, the game is gonna be pretty basic, a basic racing car game and the smartphone is just to increase/decrease speed, I don´t even need a really fast answer (yes, anyway, the faster the better, obviously)

It would me much easier to play with a regular pad, a touchscreen or a keyboard but this thing, just to let the player to use they own phone I agree is nice, it makes an easy game something better... I´m just a little bit worried about the best way to implement that.

[bruno_]

22 minutes ago, b10b said:

AirConsole Latency - worth a read:

https://docs.google.com/presentation/d/1t40cmrv7NT45rRwsJUXqZC2uOmZBS0Cbs9jG1J_Jdzc/edit#slide=id.gd83ddb292_1_76

AirConsole has some degrading network tiers built in, so if WebRTC isn't available it'll fall back to WebSockets, and then down to long polling / HTTP.  On paper it looks very good.  However in practise a Node + socketio (or variation) may work just as well (in many scenarios) and keep 100% of the control (and issues) in your own domain?

But, technicals aside, the challenge with secondary-device-as-controller approach is two fold.  First a decent arcade style game can't afford even a 50ms delay in controller input to visual feedback, let alone 300ms.  Second a touch device is a poor joypad - much worse than a keyboard or actual joypad - so where's the use case?  Such challenges suggest new game genres are a better fit - for example turn based games where the controller shows information not available on the main screen.

I agree with you, a gamepad is much better to play than a smartphone.

It's good however, for quiz games.

[b10b]

[totor]

@b10b, use case : Live Event, video projection or big screen, people hop in the game with their phone as gamepad. Easy and cheap way to make them interact, you can handle more than 8 people. Sometimes you don't need pro arcade timings.

i am interested too in a airconsole like but without the tie to airconsole.com.

[Jammy]

Would be interested in knowing what you go with. I noticed the games on that air-console don't really take advantage of the phone do they huh.

[mattstyles]

On 2017-6-15 at 4:13 PM, totallybueno said:

Sorry the noob question here, but, what do you mean? I´d need a REST API?

Yes, exactly that, a conventional RESTful api would suffice, so long as you dont need to communicate back to the client, which is impossible with standard connections as the server can not talk to client which means the client would need to poll for any changes. Websockets would let you have two way comms by implementing a duplex connection which would let your server send messages to clients, but it still involves a connection with a server.

WebRTC is a little different and encompasses quite a lot of stuff, a very basic view is that it is a service for creating peer-to-peer connections.

5 hours ago, totor said:

use case : Live Event, video projection or big screen, people hop in the game with their phone as gamepad

I've been at a few events that did exactly this, everyone logged in (i.e. registered themselves with the system, just a username, no actual logging in to something) using a code projected on the screen (to associate with this instance) and answered questions periodically. Can't remember the name of the site running it.

On 2017-6-15 at 4:57 PM, totallybueno said:

but the thing is that the client wants "to be cool" and wants to let the users play the game with their own smartphone, they say it´s a really good marketing strategy

I've done the exact same thing for a client before, it was a technical campaign run over a few weeks aimed at familiarising users with all of their devices and how they can and are used differently, sometimes differently but to achieve the same goal. The 'experience' started on desktop, moved to mobile, then connected the two. It was a neat little campaign and fun enough game in the end.

[totallybueno]

Thanks for the help guys

[Alan Bruce]

I think this could be done with the help of API. If you found any solution, please share with us. Waiting for this.

[ivanix]

Hello,

My online game service, 2n1.club (https://2n1.club), implements what the OP describes.

I currently use webrtc  between the desktop browser (chrome for now) and custom app for both android and ios which has webrtc enabled.

You can use chrome on android, but ios requires a  custom app. Rumors has it that Apple will finally implement webrtc on safari.

Alternative to webrtc,  you can also try implementing a custom bluetooth app that emulates a bluetooth gamepad.

 

[Nesh108]

@totallybueno if your use case is to have the game work on standard LAN networks (i.e. home environments), that's pretty straightforward and can be done in several ways by yourself. Each implementation might take between 30 min and 2 hours, depending on your skills.

It heavily depends on the technology you are using but the general idea is the following

1. Without the user/player having to manually connect the 2 devices: you send some UDP broadcast packets to the network where the device/computer is connected and, from the other device (your choice which), listen for those specific packets. Once 1 is received within the timeout, you read the sender IP and use that for a proper TCP connection.

2.1. With user/player having to connect the two: you got to make them connect to each other by bring the IP address of device#1 into device#2. The purest form is to show them their local IP address (192.168.x.y) and make them input it on the other device. Some cooler ways would be to just show the same information but as a QR code and then make them scan it from the phone.

Basically:

[PC] <--> {router} <--> [Phone/Tablet]

Use UDP for broadcasting and TCP for the actual control. WebSockets (https://stackoverflow.com/a/12407872/1214469)

[mattstyles]

@Nesh108 You can't send UDP from a browser, webRTC can send unordered-unreliable packets but its really really tricky to get it to do so (even agar.io won't touch it, not yet anyway).

[Nesh108]

@mattstyles you are correct. I have misread the question. I will edit my answer.

The "share the IP address" and connect via websocket still works

[totallybueno]

Thanks for your help, guys