Which application base for 'incidental' multiplayer?

Edax

Being new to Photon, I'm not intimately familiar with the differences between Lite and the MMO application frameworks; Hopefully this is the correct venue in which to ask for guidance from those who are.

I have a game in mind that involves some persistent world data, and multiple players possibly affecting that world data, but at no point are the players directly interacting with each other. The multiplayer aspect would be confined to buying or selling game items on a common marketplace, and sending mail to each other. They will play by the same rules (Unity 3d clients connect to an authoritative server which holds the game logic and processes all move requests from players), and on the same basic world maps/geometry, but they won't see each other on those world maps (like you would if you ran past someone in a zone in EQ or WoW). Essentially, everyone will be playing a persistent single player game together, and can trade items and send mail. No other player to player interaction, not even chat. If it helps to compare it to a game you know, it's probably closest to the model/requirements of something like Farmville (but no, it isn't another bloody Farmville).

My dilemma: On the face of it, the MMO skeleton appears to provide for things that this game will have no need for (world regions, interest management), and it feels like I'd need a separate instance of the world for every player if I choose to build this from the MMO... so I look to the Lite example. It appears to want all players to be inside of rooms to facilitate communication between them, which I don't think I need since the players don't ever need to communicate with each other. Events in Lite look to be sent to everyone in the room, which means I can't just toss everyone into one room if I want to have very many players and not be sending a ton of unnecessary updates (most game events that the server generates will only affect a single player). It seems similarly wasteful to create a new room per user, but I don't know if this is true or not. That's about where I run into my crossroads as to the best way to do this in Photon.

If it's recommended that you develop from one of the provided application templates, which would be the better to start with, and what scale of modification is each going to require? (I understand that Photon will inherently handle neither the persistence of data nor my game logic, I'm speaking strictly of Photon) Or, is this the unlikely case of a game that fits outside of the models Lite and MMO were intended for, so I ought to roll my own from scratch?

What I don't want to do is waste time, having started from the wrong code-base. Any assistance from Exit Games or the community would be most appreciated.

Edax

In case anyone else is given pause by the same thing, all of the 'low-hanging' documentation gave me the impression that every event was forwarded to all peers in a given room. What's less than obvious is the ability to call an overload of LitePeer.OpRaiseEvent with a list of specific actors. This mostly solves the problem as described above.

I understand that it's not probably all that efficient to do for large groups of players, but in my case it will amount to a single int for one player's actorNumber. Is it in any way bad form or inefficient to do so, or just not really mentioned much because it's not called for as much as the use of room-wide events?

Assume that players aren't generating room-wide events, and so are only getting sent responses to their own operations, and server-generated events to update only their state. Am I likely to run into Photon-specific (or any other) issues if I use a single room to hold all the players on each game server, and loadbalance them with a master server as per your provided extension of Lite? I didn't see a figure for an upper limit on users per room, but I'm guessing that hardware or other factors would limit this before Photon did. Also, will Photon efficiently batch multiple events/responses for a single player if they occur between Service calls, or is that something I will have to manage?

Kaiserludi

If there is no interaction between players, for what exactly do you want to use Photon then? For item trading and mails?
In that case I would use Lite and just let everyone join the same room, as stuff like interest-management based on the distance between players doesn't make much sense, if players can't see each other anyway. Everyone should be able to trade and mail with everyone else technically. However it makes sense to inherit from Lite on the server side and to overwrite Lites behavior in your subclass to not send events, which inform all players in the room, if another player leaves it. You have not use for this feature in your usecase and with potentially thousands of players in the same room that would only create a lot of unneeded traffic.
Players could send send ingame mails and do the thetrading both via opRaiseEvent() with only the actorNumber of the target player in the targetActorList.

This sounds a lot like you want something like an ingame-ebay.
Using Photon therefor is a bit like hunting wild animals by using fusion bombs - it's just over the top, as a http-webserver would do, too.

Philip

Hi Edax,

MMO is definitly not what you wan't.
The all-in-one-room approach doesn't really make sense for you - a room is designed to process one message after the other which is not what you want.
The one-room-for-each-player could be used and probably wouldn't be to bad performance & memory wise its all quite slim - but its a hassle you don't really need.
For loadbalancing you don't really need our roombased aproach - which brings players together on one machine - you don't care on which machine players endup as long as thy are loadbablnced - so any of the classic loadbalancing aproaches (dns-round-robin, connection-based, ...) we'll do for you ...
And as long as there really is no synchronous interaction with each other I'd say you're better off starting from scratch
which will give you the least complex base - have a look at http://doc.exitgames.com/photon-server/ ... -tutorials.

Messages you get on the peer are processed one after the other which simplifies a lot during development (peers are processed in paralell) but as long as they don't access shared resources you shouldn't run into multi threaded issues.

Also, will Photon efficiently batch multiple events/responses for a single player if they occur between Service calls, or is that something I will have to manage?

Not sure what you mean on the server if you wan't to be responding quickly on further requests of the same client while a long running call is being made you would have to run that async / on a separate thread.

Edax

Thank you both for your input. I realize that this is a bit like "hunting wild animals with fusion bombs" (though I'd have said Photon torpedos :P), but your system came so highly recommended, and is applicable to an upcoming project that's much more suited to traditional uses of Photon. It may very well be overkill, but I'm taking this opportunity to learn to leverage it.

Looks like I was just mistaken about what I thought were limitations of Photon. In the same way that it wasn't clear that you could raise events that would only be dispatched to a single peer, I didn't realize that a peer didn't need to be in a room at all. It did seem kind of inflexible, but that's a common enough trade-off for simplicity or ease. Most of my questions have stemmed from trying to fit my design into a room-based paradigm, but it's good to know that too is optional. Aside from the features we've covered that I don't need, is anything basic and core to Photon functionality lost by not confining my players to rooms?

Philip wrote:

Also, will Photon efficiently batch multiple events/responses for a single player if they occur between Service calls, or is that something I will have to manage?

Not sure what you mean on the server if you wan't to be responding quickly on further requests of the same client while a long running call is being made you would have to run that async / on a separate thread.

Was just curious what happened if, for example, a client sends an operation to server and it has a response to send back, but game logic has also generated some other event for that client, during the same interval between Service calls. Does the client get one packet with both pieces of information in them (assuming they're both small enough to fit into one packet) or does the server send them both separately, or is this behavior up to me to govern? Either way, knowing more about the system, it doesn't look like that will be much of an issue. Thanks again.