Small Scale Architecture

iByte

I would like to multiplayer enable some of the Unity games Iam working on. I have been mulling over the best way to approach multiplayer in general. Here are the basic scenarios I can see in my game (sports related) with a primary target of iPhone/IPad.

In an perfect world

Small multilplayer teams up to 6 players per team and two teams per match.

LOCAL - Local device, local player picks one team (we'll call it home team), controls one or more players on that team, the rest of the team and opposing team (away) is AI driven. Server (controling process is on local device).

PEER - Local device, local player picks one team, controls one or more players on that team, the rest of the team is AI driven (on local device). Remote device (away team), remote player controls one or more palyers with rest of team AI driven (on remote device). Server (controling process is on local/hosting device).

REMOTE SERVER- Each player connects to a standalone server via game lobby, enters a game, picks one team, controls one or more players on that team, the rest of the team is either comprised of other network connected palyers or AI driven on server). 6 players per team /12 players per game. Server should be able to host more then one game. It would be nice to have an option for the server to render a spectator view of the game (home PC to TV) , that way players could use their devices as more of a controller and watch the game on a larger display device when multiple people are playing at one location.

Okay so I just descibed my pipe dream...

I understand Photon/Neutron is designed to handle the REMOTE SERVER piece but I am not sure how to architect the local and PEER portions so the things are not radically different from a players perspective.

Thanks for any input....

iByte

dreamora

you would have to use an alternative library or sockets for these two cases, as there is no such functionality.

Photon requires that the server is always part of the equation.


As a unity user, the more or less natural way for these two modes would be using not network at all but instead fallback to a sendmessage alike approach for example or a similar message manager you developed yourself so you can handle the communication for the ai and the different players in a similar style just without the networking.

you will need such a thing potentially anyway to handle all the stuff thats meant to go through the network in a structured way so if you develop such a network manager you could make it a more general "message manager"

iByte

@Dreamora,

PEER mode would require networking stack as two devices are going head to head. Since Unity iPhone now supports network stack that is the thing to use then. I think from a client perspective it would be nice to have a common access method(s) and let some backend (message) manager decide where the request is going to be directed.

Is there a big performance penalty to run all request through sockets even if the requests all stay local. I know it's a bit of a waste but it could simplify things couldn't it?

iByte

dreamora

Networking was always available, you just required to use the TCP / UDP socket till 1.6

though in your case you can not use unity networking anyway, as you want local peering likely without an enforced access point inbetween you are required to use bluetooth. Apple does not offer adhoc networking

iByte

HI I should have said head to head (over wifi) vs PEER. I think I want to stay awy from bluetooth for now at least.

dreamora

there is no head to head without bluetooth at least unless your minimum OS requirement isn't 3.1 because thats the OS in which local Wifi was added to the GameKit.
For any device on 3.0, you only have Bluetooth available without a Wifi Access Point accessable to both

But thats kind of OT, I think we should continue this talk either on the unity board or you could alternatively visit the apple dev board for more information on it (the gamekit xcode example should give you a good headstart)