I foolishly promised I would resume my posting of tech stuff on this blog, so I suppose I better own up to that.
You are playing some amazingly addictive game on your iOS device when commuting home. Let’s say it’s a Mario clone.
As you arrive home, you want more of this gaming goodness. So you switch on your television and use AirPlay to continue the game on your TV, controls on your iOS device, via your Apple TV or other AirServer hosting, TV connected, device.
Now your good friend Bob comes by (you forgot to lock the door, so he walks straight in). Obviously this game is too good to put down, so in stead you instruct Bob to buy a copy of it. Bob pulls out his android phone, jumps on your wifi, downloads the game and starts playing.
At one point in Bobs game he sees this funky spinning portal in the level and opts to tap it. And poof! Bobs character is sucked into your game on the TV.
Unfortunately Bob is a terrible player of this game and ruins your score, but it was pretty cool to try this game in multiplayer mode.
The above scenario may sound complex to set up, but like so many other cases, it is just a nice combination of simpler bits. So let’s look into how we enable something like this in our (Unity based) game.
First up, AirPlay support was recently added to Unity and I posted a gist to help people get started with it.
Secondly, we need to host a network game pretty much all the time, so that others may join any ongoing session at any time. Of-course you might want to provide an opt-in/out setting for networked play in your game. Just remember that we are only enabling this feature for local network play – not internet play like Journey did it.
For information on how to easily set up this network game, see the talk I did at Unite 12 in Amsterdam: “Unity, Network Code, and You” – the example provided for the built-in networking is quite relevant to the above example. You can find the talk linked from the video section of this site.
So with those parts in place, we just need a bit of glue – namely the broadcasting of games on your local network. This gist deals with just that:
Let’s go over the interface for this gist:
kBroadcastGroup and kBroadcastPort are effectively shared keys we use to facilitate broadcasting communication between game instances. Broadcasting happens by way of multi-casting – an IP protocol feature allowing peers to send one package to multiple unidentified receivers. This is why our shared keys are in the form of an IP address and a port, though their value is completely arbitrary – all that matters is that both broadcaster and receiver use the same keys.
m_BroadcastTimer and kBroadcastDelay control how often m_BroadcastSocket will send out the broadcast message generated by GetBroadcastBytes.
This covers the transmission part of the broadcast functionality. The following gist deals with receiving the broadcast message:
Like with the broadcaster, kBroadcastGroup and kBroadcastPort are used with the same values to make sure we are listening on the same multi-cast setup as the broadcaster.
m_SeekerSocket is the socket on which broadcasts will be received – just like you would on any other reception socket.
And that is all there is to it. I hope you found it useful.