Awesome.

Hey Kujoe, what differences have you been seeing?

As far as I know there is no difference at the moment between the two.

Huh! Ah ok, yeah I had no idea about that. Definitely seems like a bug. Nice work with that, I'm sure you just saved me some trouble down the line.

Edit: I just went back and checked the manual again and it does say at the end of sync variables that it doesn't work for text instance variables. So I guess it's working as intended. Still good to know.

Re the 255 limit, I tested this as well and it worked for me (just had the host sync a number variable and increase it as time went on). Was able to exceed 255 in chrome. What browser are you using to test?

Any time,

Shouldn't affect the sync whether the object is on screen or not. I am guessing you have an event that isn't triggering because the pick condition fails for whatever reason. It's always frustrating dealing with bugs like this but it is good experience in the long run. Stay determined

No worries Steve.

I think Ashley mentioned it was by design (families not being able to sync variables but I could be wrong).

If you tried syncing the sprite itself and the instanced variable (not the family variable) and still no go then that is weird. I just double checked the ghost shooter demo to be sure, there is more than 3 synced variables actually - and it is working properly there.

Recreating the problem in a minimised cap.x and then seeing how your project code is different once the issue is resolved is an awesome way to squash bugs though.

The host will destroy all objects on the end of layout, but say the peer switches to a new one before the update from the host to destroy is received. In that case the synced objects can carry over into the new layout at the position they were in. In my experience it is a bit random so best practice is to wait a little bit to make sure it goes through by manually destroying them first.

Any easy way to number your enemies would be with an instanced variable "EnemyNumber" and a global variable (number). Call it "EnemyCount".

On the host side whenever you create a zombie, add one to EnemyCount and then set the EnemyNumber variable to the global variable.

On the peer side (if you dont want to sync the variable) you could use the "On Created" system option and use the same technique. Might need to double check this works every time, not sure if there is potential variance with the order objects are spawned using the sync method with a large number.

Hey mate sorry for the slow reply.

What you need to do is, before switching a layout have the host destroy all instances of synced objects (this means the peer has to wait a little bit for the update to get through as well once it is destroyed on the host). Otherwise they can carry over and at times you will have 2 of the same object (I'm guessing this is the cause of your x,y issues but couldn't be sure without looking at your project).

If you refer to the ghost shooter multiplayer demo, you see you have 3 variables synced - health, kills and deaths. Once synced As long as you are only manipulating those variables on the host side it should be working. Remember you can always bring up the debug and find your zombie objects and check the individual variables for each when dealing with problems like this (will let you know if you have duplicates).

I'm not sure that you can sync variables for the family object itself (I think i remember reading something a while back, its not something I have tried anyway). If you are doing the above correctly then syncing the zombie object instead may solve the problem.

Let me know how you go.

No worries mate, a pleasure.

You could sync the power-up and use the host to determine the collision, that would avoid the problem of both of them picking it up - but there will still be times where the peer sees them self pick up the object first but they don't have it (since it goes by what the host sees). There isn't really a perfect solution for peer to peer (other than designing the game around the shortcomings) but it is a small price to pay for a server-less gaming experience.

Sounds good for the peer. The challenges you face with this style is collisions. Things like, if you are allowing your peer to move without the host authorizing it and the peer walks over a powerup while the host has done the same thing - who actually picks up the item? Do they both get it?

Build the game around the limitations for the best experience.

If that proves to be too much of a problem in the long run what you can do is use the sync with inputs method and add on top of that the peer also has it's own movement (I mentioned that the peer fights for control but with a low latency environment this can be enough to feel like there is no lag on the peer side while maintaining a persistent game state between the two).

Keep up the good work mate, I look forward to seeing a demo

That isn't too bad for that many enemies. The readings come out in bytes so its 1.5 to 3kb per second, seems reasonable to me. A quick bit of research and I found world of warcraft typically uses around 4 times that amount.

The distance between the players is the biggest concern. You can simulate latency in the multiplayer object, just make sure only to trigger it on the host side.

Just out of curiosity, how do you have your peer movement set up? 1500 inbound seems a bit high compared to using the sync with client input method (the way it is set up in the ghost shooter demo).

Not that it is necessarily a bad thing mind you.

It is really quite simple once you start playing around with it. There are good examples in the ghost shooter and pong demo.

Basically on the start of layout you sync objects between the host and peer (playing with the precision to see what you can get away with) and from that point forward those objects will react for the peer as they do for the host.

For this mini example lets use 'position only'. Once this is done the host can instruct zombies to move and the position will be maintained on the peer side. If the peer tries to have events moving enemies they will constantly be fighting the control of the host's position (and losing). The peer can however still manipulate animations and variables from their side with this setup. Just note that these wont be shared so you will still need the peer to send MP messages when needed to the host letting them know of changes and vice versa.

You can also sync variables but for the sake of this example lets just leave it at position only. Not much bandwidth needed for updating X and Y positions with today's internet.

I said it to someone else recently but playing with the demos that are provided is the best way to familiarize yourself with what you can do imo. Change variables etc. See what breaks and what bends.

Regarding the distance check, Yeah if you want more than one zombie to share the event you need a for each.

Code it up any way you like (there is a lot of different ways you could approach it) but when in doubt remember that the debug button is your friend. You can go into 'profile view' and see how your logic fairs. Taking up a good percentage of your cpu (time to make some adjustments). If not then I personally wouldn't worry too much.

Oh ok, I thought you were having both the host and peer do their own pathing.

I would think it wouldn't be a problem unless you are syncing over 20-30 enemies at a time, I haven't tested that many though.

I guess if you were dealing with potentially hundreds you could clump some together and sync a group as one object, breaking them up again when you needed to. Hopefully it wont be an issue for you.