I would assume it's the same for all peers except the one in that case if you use Reliable Ordered

Multiplayer Tutorial pg.10

Ashley describes it as holding other messages back until it can complete the communication on that one message and says it's perfect for chat. If there are intricacies with it that we need to know -like how the ordered method of 1 message affects another message with a different ordering, if it's a different tag or same tag- hopefully he can enlighten us.

With reliable ordered, you're going to have it so that:

P1: Sends message at 11:25:32.500 (first)

P2: Sends Message at 11:25:32.550 (second)

P1: MESSAGE

P2: MESSAGE

P2: MESSAGE

P1: MESSAGE

However, since it's reliable ordered, Peer 3 will see what Peer 1 sees(Assuming it reaches the host at the same order and time difference). IRC works the same way and there's no way to prevent what Peer 2 sees, but he's the only one to see it. If there is enough time between, Peer 2 would receive the message before sending his and wouldn't have a difference

I am curious though if Reliable Ordered applies to the tag or the message system as a whole.

Honestly most player wouldn't be bothered with disconnecting and reconnecting their controller. I have mine plugged into the back of my computer and it's staying there. This means if I have to rely on that gimmick I won't be playing your game.

A better option would be pressing a button to disable/enable controller input, and then based on what state it is, treat it like you already do for disconnects/reconnects. This can be a button you press on the keyboard/controller to switch between the states.

This way the controller stays plugged in, you get your intended mechanic, and you don't have to have an issue with how the browser handles controllers.

You can still provide the option for them to disconnect/reconnect if they wanted to use that, but it being a requirement is detrimental to player interaction

It works way better now, however there are still issues sometimes between browsers. Unsure if it was the connection not completing sometimes due to connectivity or browser.

delgado

I'm not at my C2 computer often during the week so I won't be able to look at it, but all the information you need to know is in the Real-Time Multiplayer example. Just look at the events and see how it sends input to the host.

If you see on the PEER object that it has a variable called "inputs" that is synced, and when the Not-Host pushes a button, it moves it locally AND sends that input to the host. That input is read by the host and makes your character move on his end. Since you're playing the same game it syncs up fine 90% of the time.

The left click action spawns lasers and such so that would be the best way to figure out how to make them see it, and you can use the same information to see how it processes being hit. Since it's basic it revolves around the PEER object so it won't give the most optimal way to handle secondary objects like the wall being destroyed, but it's all the same system so you can just make the wall sync or receive a message to be destroyed.

My first assumption I'd treat it like how player-damage is treated from the laser, but there might be a method that uses less bandwidth (unless sync only sends data when it changes, then it'd probably be pretty sweet)

delgado

I don't have a capx. Use the Real-time Multiplayer example from C2

Also from you're image you're giving them actions locally, but not telling the host what you're doing

What you need to do is send a variable to the host that when the host receives the variable and then does the same action base on what variable it receives and transmits that action to the other peers. The example has this already coded into it.

You need for the local action to trigger only the object that's associated with the local player's PeeID.

Once you do that, you need to have the input you use to be transmitted to the host. If you check out the PEER group on the multiplayer demo, you can see what it does VS what the server does.

For the multiple zones, you could group them in a sector -which is the server- where you keep track of a lot of people. In the end it'll be the same data transmitted and received.

Although that has everything riding on one host and if that goes down it affects everyone. I know it's a beta now but reconnection and shoving everyone back in the same room without losing too much might be an issue with a larger playerbase. Splitting it up among different server zones would provide more stability. Especially if only 1 instance had a crash in 1 zone you could accommodate for that. If you split all that up into different rooms, you could potentially do that by ending connection to one and then enabling to another based on layout variables telling you which room to go to.

Although it is possible to do all that without 2 servers and that there might be more specific things like websockets that would be better for implementation for a centralized global chat, the execution of the product may not want to rely on a central server other than the signaling one for connections. This offsets the load and as long as there's a host you could have a global chat on one object connection, and have the game on another object connection. This way no matter who's the host (if dev controlled or random peer), it'll have dynamic scailability, allowing more people to talk and play, as well as help organize groups of players easily.

I don't feel that allowing multiple multiplayer objects is a bad thing, although I do understand that it may make people forget that websockets exist when they have perfectly fine uses. Perhaps a mention of them and demonstration of their use along with a disclaimer about too much traffic = bad or w/e for relying on the WebRTC stuff for everything, especially if you are hosting it locally. I do feel it's at least a quick start in getting things working, as playerDB stuff on the C2 engine would be laggy for hundreds of players, but for a few players it wouldn't show it's bottleneck and be acceptable. If programmed around that, that limitation can be avoided (although doesn't let you expand and get more people, just scale the operations of what you have)

If multiple connections/objects do come in, I know I'd set up a chat connection for the chat and lobby, and have another connection for the game rooms

It's impossible to write software without relying on third parties. All modern software development requires relying on additional libraries written by other people. It is actually quite a difficult challenge to write some software that does not rely on any third party code, and it would look something like a custom-written OS that boots to a DOS-like prompt and would not really do anything useful. A native exporter would just rely on different third parties. In particular I'd anticipate buggy graphics drivers as a particular weak point of native platforms; browser vendors to a lot to work around driver bugs where possible in their engines, and where not possible the GPU blacklist ensures things at least work. (While the resulting poor performance can be frustrating, the alternative often means maddeningly mysterious crashes and glitches that can totally ruin the game, so slow but working is actually the better option.) Then there's OS fragmentation (very problematic particularly on Android), compilers/development tools to rely on, more OS-level libraries that may have various issues, and so on. So I don't really agree that a native engine relies any less on third parties at all; it just relies on different technologies, and that doesn't prevent you from getting screwed by the crappy work of some other vendor, graphics drivers being the perfect example of that.

This is way too true.

The major problem we have is HTML5 support across the board is still a very young endeavor and has issues. It gives another platform -one that's implemented on all the other platforms- to distribute a product. It's a standard people can go to that should work the same across all devices, as it's requirements makes it virtually a device on it's own. Once the platforms have enough support in a user agent program that supports HTML5 and implements it well, the complaints should be on par with native programs.

But since it's new it'll have issues getting things as the intent is for stability and speed, and not just optimization. The more support means more speed so going a safe and standard way gets them a significant speed increase in the end anyway.

A good thing to look at is the rise of DirectX vs OpenGL. DirectX was this MS product that was about graphical rendering and such, and like the XBOX people dismissed it at first. For a while it was worse than OpenGL as many cards were optimized for it over the new DirectX. The DX platform grew by having better documentation and worked with the hardware developers -along with having money to back it- to get it to become what has been years as the better and more optimized platform.

If you look at HTML5 we're in the beginning stages still and an optimized user agent that renders HTML5 would have performance similar to native in the end. DirectX did that to the "user agents" (Video Cards), but they had enough money. The web isn't a singular thing, so once more people start adopting, more people will have a demand and in the end that demand is worth more than money.

To test it you just need 2 windows open. Each window is it's own session.

If you test the chat demo without modifying it (or modify just the game name to make your own private room), you can verify if it works for you or not.

Yeah I wasted like a day or so myself until I did that, trying to figure out how I went wrong since a function kept going off every tick and then suddenly it came to me, seemed backwards, but it works and I can't simplify it more so :D

You need to add an instance variable to the entity you change the animation on

In sight> Do stuff + set variable to 1

Not In sight + Variable=1 > Do stuff, set variable to 0

This makes it when they are not in sight, that it checks for that variable, and if that variable is 1 (because it was set when they were in sight), then it does stuff and sets the variable to 0

Since the variable is 0 for that entity next tick, it does not trigger the not in sight actions again. This makes it so it leaves whatever you had set, set.

This is essentially how the Trigger Once condition works, except you're coding it in-engine for specific entities.