So, what is actually an Operation in Photon?

Fratyr

Hey guys,

Sorry for the silly question. I promise to gather all my questions and correct answers later into one thread to help newcomers like me understand the basics of Photon ;-)

So, I've got a really good working prototype of a server on Photon and a basic Unity3D client that talks to the Server.
It was built from the examples on cjrgaming.

The client can: Connect, send request, establish and send encrypted request
The server can: Create peer, receive operation request, send operation response or event to the client, as well, my small addition was:
If a game has a lot of operations, you don't have to use a huge switch case statement, but rather, I have divided operations into categories (Classes) and I invoke them by using delegates and dictionary.

I will post a working examples of it when I feel like it's ready to be posted, but now, to my actual question.. (Sorry for the long post, I had to explain what I know and what I have so far):

What is actually an operation sent from client to the server?
Or an Event raised by the server to client (all clients at once?)?

At first, I was thinking that each operation is particular user flow in the game. For example, operation code "1", means a Player X wants to shoot Player Y, do something.
But then, I realized, that you cannot put all your game logic in only 255 operations, as per byte limit, without extending it to short int or something.

Then I found out that there's a channelID as well, which can be different on the same operation code request... which means for me, an operation code is not a user flow, but a data stream of the same/similar actions between client and server, and the channelID can be used to differentiate between requested operations to be calculated on the server.

Then...! I realized (oh dummy me), that there's parameters sent from client to server and vise versa in a dictionary, which adds another layer of possible user flows.

So.. now I suppose to understand things, but they just confused me even more.

Can anyone briefly explain the purpose of operation/event/channelID?
For example, if you do a small multiplayer game, what you will use to make user (game) flows, like -> A Player hitting a target, player picks up an item in the world, player sends message. Would you use unique operation code for each of this flows, or you group your operations by meaning and use channels to differentiate between requests, or even here, you use same channelID for many user flows and differ them with some ID inside parameters?

Hope I made any sense, well.. I have C# and Unity friends to help me with coding and learning, but hell.. no one knows how to use Photon!

Thanks a lot guys, for time, at least, for help if any!

[Deleted User]

Hi Fratyr,

I would like to redirect you to our decumentation: http://doc.exitgames.com/v3/photonclient. Did you have a look at these pages?

This part of the decumentation is not going into detail, but it may help to point out some parts of the key concept.


If you have any further questions, please ask.


Tim

Fratyr

Hi Tim,

Thanks for you answer.
Yes, I went thru the docs on this website, and many other forums I could find.

There's no answer to my question.

f.e, a piece from your docs:

OperationCode: a single byte to identify an Operation (to minimize overhead). (byte)LiteOpCode.Join equals 90, as example.

That's all about operation codes, but why you can have only 255, what is an operation itself etc... is missing.

The documentation on this website is... allow me to say it like that: "feeds us a fish, but never teaches us to catch a fish"

So all the MMO, Lite/Lobby examples are great, but very bad explained.

By the way, code examples on your website look cut apart from the right side... take a look at the long line of code out there.

Thanks

Kaiserludi

Have a look here:
http://doc.exitgames.com/v3/overview/basics

http://doc.exitgames.com/v3/overview/basics wrote:

Operations
An Operation is Photon's equivalent to a remote procedure call. Photon clients use Operation calls for anything they want to get done.

Operations and all of their parameters are defined in the server side Application as needed. Clients can call any Operation by setting up a Hashtable with keys and values fitting the Operation's conventions. The client and server frameworks take care of serialization, transfer and deserialization.

Each Operation can also provide a result. This is one way to provide a client with requested data. Of course, the result can be skipped which saves bandwidth.

Operation calls and results are a thing between one client and the server. The other clients won't know about these.

"but why you can have only 255"
You quoted the answer yourself: "to minimize overhead"
You can not have more than 256, because this will be by far more than enough for most games and we wan't to avoid to have to send an additional byte for the opCode for every op, when 1 byte is enough for reasons of operation-size optimization.

In the case that you really need more different operations than 256, then you can just for example use opCode 255 for a whole bunch of different operations, by just sending your own opCode inside the payload, so that you can do something like this:

switch(opCode)
{
case 0:
    // this is op 0
    break; 
case 1:
    // this is op 1
    break; 
// case for ops 2-254 would come here
case 255:
    switch(opCode2+255)
    {
    case 255:
        // this is op 255
        break; 
    case 255:
        // this is op 256
        break; 
    case 257:
        // this is op 257
        break; 
    // more ops come here
    }
    break; 
}

Tobias

Channel
In Photon, channels are used to split up communication into several sequences of operations and events. In a single channel, all operations and events are in order.
http://doc.exitgames.com/v3/overview/glossary

So, channel IDs give you some control about the sequencing for operations and events. Example: You exchange position updates and shots and have a chat in parallel. You could (but don't have to) separate the chat from the actual gameplay data in another channel. If a chat message is lost, it won't affect positional info dispatches. If it were in the same channel / sequence, then a lost reliable chat message must be received before further position updates can be dispatched.

Fratyr

Thanks a lot guys
You're giving a me a good progress... I document all the things I learn and what they do, I see people dying to get explanation of how Lite or other Demos work.. So educating might be a good way to learn by myself

Btw, what is "Protocol.AllowRawCustomValues = true" ?
Is it something related with OpCustom operations, whether to allow them or not?