Author Topic: Trying to understand playmaker in a Multiplayer environment (photon)  (Read 7393 times)


  • Playmaker Newbie
  • *
  • Posts: 41
    • Midnight Tinkering
Hi Swift_illusion,

I think you are indeed confused with the network "view" system and what a playmaker global means in a multi player context. I also think that you are confusing Global Events and Global Variables, they do use the same "global" word, but in our case, this is very misleading unfortuntly ( I think global events should be simply called events, and that events should be made "public" for other to see them, not "global").

-- A playmaker global, synched over the network, is something that can not be used to define a property that belong to a particular player. Because there will be several players, EACH of this player would share the same value, because the global variable IS syncehd over the network.
-- A playmaker global, NOT synched over the network, is NOT fine neither, because all players are prefab so they work the same, and they would ALL try to access the same global, so imagine storing the name of your player in a global... you create the room, fine, the global string has your name, if someone else, joins, the global gets overwritten with the name of the new player that joined the room... not good.
A global variable synched over the network should only be used to represent a property of the environment in general, not something that is meant to be specific to the running instance ( a player, an enemy, etc etc).

Now,  A Global Event is necessary even within a player Prefab, and even within the multi player envirnoment because, to communicate between Fsm, Global Events are necessary. You can fire a Global event to a very specific Fsm, this is not "global" as "everyone will get it", it's a "public" Event as "I am listening to a Global Event is someone wants to communicate with me".

If these concept are not fully grasp, We need to discuss this more, on another thread, because this is core to playmaker and how Fsm are built.

Now, for your example, completely remove global variables from your thinking process ( for now ).

-- keeping "state" as you describe it: Study how the animation of the character is handled in the demo, this is very much how I would suggest you implement your character state as well.

   1: the current animation playing for the player is stored as an integer, 1 if for idle, 2 walking, 3, running, 4 jumping.
  2: this integer is stored in the "variable synch repository" Fsm of the player in variable "Animation (synched)"
  3: In "Animation synch" Fsm
       IF this player is mine, then I MUST set Animation (synched)
       IF this player is NOT mine, then I MUST read that value and FORCE this player to match the animation integer

So, for states it would be the same, have an integer ( integer are smaller than strings, so they are more efficient to stream over the network then strings, but you can use string if it is easier for you to begin with, not a problem)
make that state variable synched over the network, and have a fsm responsible for either setting that state or reading that state AND force it to reflect that state.

If you don't understand this, I think I will do the following:

 Extend the demoWorker with a weapon. I am thinking that the best way to illustrate fully your dilemma would be to let the player drop a "mine" ( no pun intended (no "PUN" intented) :) ), or let's call it a bomb.

Ok, as the user drops a bomb, this bomb would explode if another player touch it, if you touch it it doesn't explode. This would totally illustrate the "is mine" concept, because the bomb would be instanciated by the same application instance as the player ( I hope you are following me here), the bomb belongs the player. so when a player would hit the bomb trigger, the bomb would check that the player "is mine" or not, if it is not, then it means it's another player, and BOUM.

 In short: A player and ALL objects instanciated over the network by the same running instance ( by running instance, I mean "running application")  would respond to "is mine" to true in that running instance.

I hope I did not wrote any nonsense, it's late here :) I think your question is very important to many to properly grasp how to build multi player apps. So I am really willing to get to the bottom of this and be as clear as possible. So do not hesitate to quote and ask for clarification where you require it.



Firstly thank you once again so much for the knowledge you are taking the time to share! However
"If these concept are not fully grasp, We need to discuss this more, on another thread, because this is core to playmaker and how Fsm are built."
Regrettably I do have quite a few things I need to ask/confirm/expand on so I took your advise and posted
this in help as I agree it would be helpful for others who are having the same problem and might find
solutions here.

I'll start with global events as I believe I understand what your trying to speak of here most.
Because when using global events, you are sending them to specific objects for that object to read it.
However what I'm not sure about is, if you have 2 instanced characters, if you have an event sending to
"Event target : Game Object
Game Object : Use Owner"
Will that event be read by every instance of that object? Or does it in the multiplayer area still understand
when it is it's 'own' object, a.k.a if you send a global to another FSM on your character object to turn it
green, the other 'characters' won't read that event?

About global variables, from what you have explained along with looking at the photon character again
observing with what you have tried to explain, would you instead use an FSM to 'store global variables'?
So instead of reading/writing to a global variable, you would instead get/send variable changes to a single
FSM like the 'variable synch repository' FSM on the photon character?
So basically between every 'action' I wanted my player to take, I would add this 'is mine?' check before
it, and set or get the data?

If you may find the time at some point your 'mine' or 'bomb' (puns are always puns no matter how unintended :D)
example that would be a great addition to the demo and would really help expand the reference of
photon view being used and would be greatly! appreciated :)!..

Hopefully I'm starting to get a grasp of this? Or am I still not quite understanding the multiplayer environment?
Also, does this mean the entire game would need to be developed in the multiplayer environment, as from what
I understand it's going to be a massive addition of changes necessary to work in the environment.
Also if you know, does running the demo with yourself chosen as the Photon host consume bandwidth?


  • Administrator
  • Hero Member
  • *****
  • Posts: 15500
  • Official Playmaker Support

OK, let starts :)

global events:

no, sending an event using "send event" action or indeed any actions as you know them will not send that event to other instances in the multi player environment, for this you need to use the photon action called "Photon View RPC Broadcast Fsm Event To Player"

the notion to learn here is RPC, Remote Procedure Call, and this is something specific to multi player scenes.

Playmaker do not send the event as is, instead it relies on this RPC protocole to "transfer" the event from one instance to another ( the player target) and fire the event from there.

Is that clearer? So to turn a player green. Implement on your player prefab an global Event "TURN GREEN" and set its material to green or something, then use this RPC broadcast action and send the event "TURN GREEN" to another player, only HIM will receive that call and thus only him will turn green.

ALL of this is illustrated with the chat system. When you want to send a chat to a specific player, you type the text and send click on the name of the player, it will use that broadcast action and call "CHAT RPC CALL" and it will also store the text you entered in the event data, so that when that user you are writing too receives this event, it can get the text you wrote and read it on his screen.

Yes, you got that right. the Is Mine action is central to multi player environment and objects controlling over the network. Because you are writing only one object, the script must make the difference itself, The other solution would be make that check once on awake and swap components, for example an "owner component" and a "slave component" so that within that you know you are a slave and don't ask any more iif you own that or not. I would not recommand this however for a very good reason, it duplicates processes and will make it very difficult to maintain, instead implement the fact that you are indeed in a multi player environment and embrace it, this is like trying to build a 3d scene and ignoring transforms and how they work... you will have a tuff time :)

now, not "every" action will require this, for example you might not want to synchronize everything, typically all the personnal management ( for example when the player wants to view his weapons, or do secondary animation that are of no interest to other players). So it is important to first sit down and write down what exactly your player will do and how that affect other instances, meaning, what do we see from other players. for example jumping, you might be in a game where jumping is important for the user to evolve but totally irrelevant for other players to see, so don't synchronize that, do not implement a system that will make sure that when you jump, everyone sees that you jump.

Does that make sense?

I must first finish the documentation, then I will make that bomb system, meanwhile study carefully the chat system, this is the right feature to study for what you are trying to do, extrapolate on the fact that the chat can send information to a specific user, or ALL ( including you) or Others.




  • Playmaker Newbie
  • *
  • Posts: 41
    • Midnight Tinkering
Can't thank you enough!
That's definitely made it all clearer, and I'll be sure to take a better look at the chat system.
Thank you very much for taking the time to clarify all this, hopefully I should be able to
get a grip on it now with what I hope to be a better understanding of it, and make progress :)

Ahh of course, goodluck with all the documentation! It all looks great so far, so keep up the good work :)!
I look forward to looking at that bomb demo in the future :)