Has anyone published a working multiplayer game?

> tunepunk,

>

> Going to check it out - thxs. It looks promising.

>

For me it was a no-brainer. My main concern with Peer to Peer or Hosted games, was what if host disconnects or decides not to play/ragequit, there is no game anymore. Those kind of things completely ruins multiplayer gameplay in my view. Hosted games with player created rooms are a thing of the past.

Our games focus on privacy. Family and friends and invite only. The fact that if host disconnects is a bonus. The price structure is very good to, concidering. I see the plugin has some issues though. But the website has enough docs and code to figure it all out - I hope, will have to schedule some time.

Player created rooms are very popular. Who wants to play with strangers that make the gaming experience not enjoyable? Private rooms rock, unless you want to use the strangers as target practice

Both have merit however, depends on end project.

I didn't say private player created rooms are a thing of the past. Just that the whole technology of the host-peer setup is kind of dated in my point of view. And not really desirable in some cases, depending on what type of game you're creating. Maybe there are some benefit in terms of ping times, and maybe better in LAN gameplay or whatnot. I guess photon cloud as a technology can have the same features as host-peer games. First one to join room - Set Player.Host=True ... and close the room if he leaves. Private rooms would also be doable i guess... but anyway. You're rigth depends on the project. But messing around with Photon cloud for a week i can see it's quite versatile.

Ashley - Yah I wrote my own WebRTC client for a completely different web application (I will probably extend it to a C2 plugin for myself in the near future) and this was something I came across during its development. It was rare but often enough I decided to code around it.

What I found was that in rare cases after the host has created the offer it can start sending ICE candidates almost immediately. I would have assumed the peer would have enough time between receiving the offer and generating the answer before receiving the ICE candidates but this wasn't always case. From what I can tell the offer is always received before the ICE candidates since the websocket connection to the signal server is ordered but if sometimes they are received close enough together and they don't give the peer enough time to set a remote description and generate an answer this race condition occurs. Because the peer process of setting the remote description and generating an answer is asynchronous javascript isnt held up and can receive and add an ICE candidate during this time at which point you will get that error as it attempted to add the ICE candidate before completing the answer process. So its an actual race condition that occurs as a result of the trickle ICE implementation in the WebRTC protocol.

Well there's nothing we can do about bugs in the WebRTC protocol itself, you'd need to take that up with browser vendors. However I'd suspect it relates to your own WebRTC client code, since I've never heard of any such issues with C2 multiplayer games connecting to each other. Also it may simply not be important, since I think ICE works by sending multiple candidates over time, and if it successfully connects and another candidate comes in, it may simply ignore that (possibly logging an error in the process).

Pandy,

Here is a working multiplayer game by lennaert