Has anyone published a working multiplayer game?

Hey all,

So was wondering if anyone has published a game (specify platform pls) using C2's multiplayer feature, and had it working with no issue.

I really doubt that, since most can't make it work. For some reason people can't connect to each other.

Scirra says it might because of firewall / ports or NAT setup. But i don't get the idea then... People should never have to open ports and so on to play online browser games.

It sucks

xanxion - While I agree that people shouldn't have to open ports to play multiplayer games its not uncommon for games to have support documentation stating that ports may need to be open for proper usage if you're router is blocking them (rare but it happens).

The WebRTC implementation is actually a thing of beauty from a developer stand point. Because most (more like all) routers will block "anonymous" internet requests from unknown ip:ports making it impossible for two browsers (or two of anything for that matter) to connect to each other with out each specifically sending a request on that same port. (servers are different because those ports are open as they are expecting anonymous requests)... but web pages work the same way... my server couldn't just send you webpage you didn't request. Your router will block the anonymous port 80 message I'm sending you from my ip because you didn't originate the request on your machine for that port. When you type an address in the browser and click enter you send a request out on port 80 (usually) thus notifying your browser that you're allowing a response on that port from the ip i sent the request to.

I'm generalizing this but the devs at google found a back door to this security process by spoofing requests from each computer (browser) to each other thus causing your router to see that YOU sent a request to some guys computer on a specific port and even though he blocked your request he attempts to do the same thus opening both routers to each end to internet traffic from each other so long as its on the same port they both sent the spoofed request on. To set all this up, first both computers need to get some sync info (ip of the peer and port to use) which is where the signalling server comes in to coordinate this transaction to get both routers on each end to allow communication between pair and setup the data channels. After which a websocket is opened between the two so the connection stays open (web page request close the connection after receiving data back from the server).

So any way try not to talk so negatively about something that is extremely complicated and really is a masterpiece of network communication that for all intent a purpose is still relatively beta as google/firefox/IE and others are still working and developing WebRTC standards.

Ashley - I would however like to ask your thoughts on what I think I found is a bug (race condition) in the WebRTC signalling process that fails to establish a connection when a race condition occurs where ICE candidates are received and data channels are attempted to be opened before the RemoteDescription is completed on both ends.

I wrote my own WebRTC module and signalling server i use for a website that sets up a chat rooms and lobby's (eventually will be used for my games ) and I noticed a what i think is flaw in the signalling process (not yours.. but the actual implementation). In some cases the peer|host will send ICE candidates to each other before the offer|answer process is complete. This causes the host to attempt to open the data channels before com is ready. Its rare but I noticed it happen when JavaScript was running slow on one machine (cursor freezes for a sec while the CPU is doing something) and watching the debug console as ICE candidates were recieved before the offer|answer process was complete and the connection process stalls and fails.

I over came this by adding one more step where I store all ICE candidates received on both host and peer side and then after the host has received an answer from the peer and completed the RemoteDescription process the host then sends an "answer-accepted" message to the peer through the signal server at which point both host and peer now add the ICE candidates they stored from each other and allow future ICE candidates to be added right away. Once ICE candidates are added, that's when the host attempts to open the data channels between himself and the peer. By forcing this process to be last I get 100% connect rate now where as before it would fail some times. For me this made a difference in improving stable connection setup between slower and faster computers and is something I think you may want to look into.

I really doubt that, since most can't make it work. For some reason people can't connect to each other.

Scirra says it might because of firewall / ports or NAT setup. But i don't get the idea then... People should never have to open ports and so on to play online browser games.

It sucks

Webtrc is still in its early stages and has a fair amount of bugs. The non connection can be a number of things, I must add most not related to scirra. The fact that we have access and are able to use this cutting edge stuff shows how far ahead scirra/construct2 are ahead of the competition.

Sure it isn't full proof currently, but ashley has repeatedly said over and over that this is an advanced feature and not for the faint of heart.

As with all new things... give it some time to iron out - Then this is going to rock.

Well then, if its so great and cutting edge, i can't wait to see some multiplayer games actually being released.

For now, all i see is people can't connect to each other properly. I think this multiplayer plugin was implemented way to early. I dont care how cutting edge it is, or how advanced if its not working in general for most users/players.

And about opening ports for playing online games? this is not the 90's.. You might have needed to in old games like Red Alert and so on. But we are in 2015, try playing some online multiplayer games.. I haven't opened ports for that in years, lol.

I'll try not to rage about this to much, but considering the problems with everything like Mobile, Multiplayer, Performance, Exporters. All of that combined.. Argh..

Our own data vindicates what we've read elsewhere: about 90% of users can successfully make peer-to-peer connections. So actually most users can make connections, and a minority cannot.

The main reason the minority cannot is because of stupid network-address-translation (NAT) middleboxes on the Internet. Basically IPv4 addresses more or less ran out years ago, and the workaround is to hide multiple separate devices on different ports behind a single IP address. The NAT box figures out which ip:port combinations go to which devices. However there are lots of ways of doing this, and not all of them allow direct peer-to-peer connections.

In principle, peers ask a STUN server for what their ip:port looks like from the outside Internet, because they don't know themselves when behind the NAT. Basically it's a simple "tell me my IP address" request. The STUN server sends it back, the signalling server exchanges the ip:port for each peer, then they try to connect to each other. However here's an example of one kind of particularly annoying NAT: a large office where say 1000 computers are actually hidden behind not just one IP address, but 5 different IPs, which are chosen semi-randomly for each connection. So a peer from that office asks the STUN server for its IP address, it returns one of the 5 IP addresses, that is sent to another peer, then it tries to connect to them but the NAT chooses a different IP out of the 5, and the connection fails. There are a few other kinds of NAT that break peer-to-peer connections in similar ways.

You can work around this for the 10%: run a TURN server. This is just a relay - both peers connect to the TURN server, and the server forwards data between them. That brings the total connection success up to something like 99%, but then you have to pay the bandwidth bills for everything running through the server. We already pay hosting fees to run the signalling server and we do that for free, but racking up bandwidth bills for actual gameplay data is a bit beyond what it's sensible to offer for free. So if you're worried about the 10%, you can run your own TURN server.

Another good workaround is run the host on a dedicated server which is not behind NAT. That should also work for a wider audience since some problems come only when both peers are behind NAT, but it still costs money.

That's all more to do with the architecture of the Internet than WebRTC, HTML5 or Construct 2. Native apps are affected identically AFAIK, because it's the same network they're connecting through. This is why we need IPv6!

Well then, if its so great and cutting edge, i can't wait to see some multiplayer games actually being released.

For now, all i see is people can't connect to each other properly. I think this multiplayer plugin was implemented way to early. I dont care how cutting edge it is, or how advanced if its not working in general for most users/players.

I understand your concern. It is a valid issue, especially when about to embark on a large scale project. I know of 4 big games that have moved from c2 to unity based on justifiable concerns.

But, we still develop based on the future promise of what is going to be possible or hold off till it is.

Think star wars starting 3, 4, 5 because he didn't have tech to do 1, 2, 3

Okay, lame example, but there are thousands of cases.

I see ashley went into some depth. Interesting read

I'm developing a realtime multiplayer game at the moment, but I'm using Photon Plugin instead. So far so good... The regular Multiplayer plugin didn't really meet my criteria, as i wanted rooms to stay open as long as there are players inside. I didn't want the game to end if host left the game, and i didn't want to be setting up a server. So far i didn't notice any lag either so I still have my hopes up that Photon will do the trick.

But yet to see how well it performs when i try to make an app out of it. So far it's performing really well, and I be launching a pre-alpha playtests in the next few weeks or so for people to try it out.

Ashley - You didn't respond to my post but I wanted to show you that I can reproduce this error consistently and it might be responsible for some of the connectivity issues your users are having.

Setup:

Host Client: Firefox

Peer Client: Chrome

Add a delay to the peer so that the peer will receive and add ICE candidates before it creates and answer for the host. This occurs very sporadically on its own but by adding the delay to simulate it you will generate the error every time.

Effect:

When Firefox is the host and Chrome is the peer, if Chrome receives an ICE candidate and attempts to add it before generating an answer to the host offer, the connection process stalls and fails. The ICE error will still happen when its Chrome to Chrome and will show in the error console, but the connection process doesn't stall and it still works so its specifically a cross browser compatibility issue on how each handles this event when it happens.

Here's a screen shot of the error console when i simulate this from my WebRTC setup

I fixed this by allowing the ICE candidates to trickle in as normal but I queue them up until after the remoteDescritption has been completely setup and then trigger them to be added and allow any others that are still trickling in to be added immediately. Yes it adds maybe a second or two to the setup time but for increased stability it was worth it. I hope this was helpful for you to see what I was trying to explain and that you decide to patch this for your users.

Thank you

tunepunk

Can you pass on the link to this photon plugin.

How is this plugin different from the regular multiplayer?.

Does it make one of the peers as the host if the original host leaves, or it just leaves the room unclosed, which means it'll only work in games where the multiplayer logic is running on the peers also, and not only the host.

troublesum - based on those log messages it doesn't look like you're using the official Multiplayer plugin. Are you involving your own code or library there? I never saw that issue with the official Multiplayer plugin.

tunepunk

Can you pass on the link to this photon plugin.

How is this plugin different from the regular multiplayer?.

Does it make one of the peers as the host if the original host leaves, or it just leaves the room unclosed, which means it'll only work in games where the multiplayer logic is running on the peers also, and not only the host.

It's quite different from the regular multiplayer as this one uses some sort of "cloud server". There are no hosts or peers per say. Every event sent from your client will pass through the Photon Cloud server, and are sent to the other clients. You don't have to set any host or anything like that. All the actions you do you just transmit them through the photon server, and anyone in the same room will see the updates and you will see theirs as you recieve their events while connected to the room. Even if you are the first one to join the room, you're not really the host, as you can exit any time, and rejoin the room with a new ID. Rooms will stay open as long as there are players inside.

I didn't check all the details yet, and only been messing with it for a week or so. I just downloaded the examples and learned from that, but it's pretty straight forward, and far easier to comprehend and use than the regular Multiplayer plugin. Basically works like this.

1. Connect

2. Join a room (If there is any open with available slots, otherwise there will be one created)

3. Player1 press move button. (player1 moves 6 pixels in that direction)

4. Send event to Photon server. (Event usually contain your ID and anything you want other users to get, like: Player1 move 6 pixels in that direction)

5. Photon sends the event containing the information to all other users in the room.

6. Recievers catch the event, and applies the on their end changes that are sent through the event. (Ex: Player1 move 6 pixels in this or that direction)

That's basically how it works. Without dedicated servers, and no hosts. It's GENIOUS!!!

https://www.scirra.com/forum/plugin-photon-cloud_t125222

tunepunk,

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

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.