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.
Bye,
Jean
