I'm looking for a way to connect a tablet to a game made in Unity. I need a couple different things:

1. The tablet should have the ability to display information from the game that is running on the pc. For example, if the game is a racing game - I want to display the gauges on the tablet, showing the speed, rpm's, etc.
2. The tablet should be able to be used to control the game (even if it needs to be limited controls). This could be anything from a menu system that controls the games settings, to actually controlling the game. Again, as an example: if it's a racing game, the tablet needs to be able to control the vehicle, albeit it may need to be limited depending on the complexity of the games controls.

I've not had a lot of luck looking into this, and was curious if anyone knows of anything they could point me to or something to get me started down the right path. Thanks for the help!

_WeirdCat_ said:
dunno, you should use udp protocol i dont recommend tcp

No, thats just wrong. TCP is perfectly fine, and its the thing of choice if you want to send data that has to arrive. So for something like “I click that button on the tablet, the PC should do something" you send a TCP-request. If you do it with UDP the reuest could just drop, and you have pretty much have to implement a TCP-like wrapper where you send messages back and forth until you are sure that your request got through. (which can be something you want for very specific, complicated scenarios but certainly not here)

UDP you would use for messages which you do not require to arrive. If you send updates of players position between server and client, and those messages are send 30 times per frame, it doesn't matter if two of those drop. Thats UDP.

_WeirdCat_ said:
Then with tcp youll see noticeable lag, someone can say no theres no lag but there is this, and it can ruin the gameplay

While UDP can be faster than TCP, saying the TCP equals lag and UDP equals no lag is just plain false. Again, if you need a message to arrive you have to send it with UDP until it arrives. So if you have a connection that drops a lot of messages, you will see the pretty much same lag with UDP that you will with TCP as you have to just implement TCP-like message sending anyways.

I really don't know why you have that idea that TCP automatically equals lag, but you are wrong. A game can ran lagless with TCP, I've done multiple of those. You can even use both TCP and UDP for sending must-arrive messages on TCP and the data-intensive broadcast-updates via UDP so you get the best of both worlds.

Networking is a big impact in performance regardless what you are using. TCP and UDP are quite similar in performance in relation to the timeframe you are monitoring. Human reaction time is supposed to be not that huge and even a really skilled secretary just is able to hit 150 buttons per second at max. This are 7 ms while a game running on 100 FPS has round about 10 ms update loop. This is quite insane!

Assuming you eliminate all outer circumstances like a bad Wifi connection, complicated Network infrastructure and your wife/man is not downloading an ESO update of 100 GB (why Zenimax, why??) on the same time, you should achieve a good response time anywys regardless if you're using UDP or TCP.

Why is TCP considrred to be slow? Because it has these streaming character that messages are like binary streams send in the same order they are placed onto the socket buffer from an application. So you ensure that everything is send and in the right order. UDP is different, it is just fire-and-forget approach for broadcasting messages in the whole network to find the game server your friend hosted in your local LAN-party. This lets assuem people that TCP is slower (which is true) but not significant slower perhaps.

However, TCP has the benefit to be safer in case of recognizing connection loss but you could acieve this also with UP by simply tracking the timestamp of packages that arrive at your target. If packages are not received for certain time, assume a connection loss.

However, in the end the data matters and how you are handling them. Sending 100 GB of data in a synchronous way has a significant lower performane than using a thread-pool/ IOCP on Windows and if you block the thread to process the message for several milliseconds before starting a new receive call will also cause a performance loss

Would it make a difference on the networking front if the tablet can have a wired connection to the PC?

Bluetooth might be an option as well, never really looked into it on phones/tablets, but I know some controllers use it (e.g. I use it to connect my XBox One controller to PC), as well as audio etc. I think bandwidth is the main issue depending on what you are doing.

I think anything in the LAN environment should be fairly acceptable, its still going to be faster than any sort of full game streaming (LAN and certainly internet), and probably its not the sort of competitive game where people will chase every millisecond.

If using WiFi, make sure you have a way to “pair” devices that doesn't break if multiple players are on the same network, such as letting them select which to connect to if multiple are detected.