Has anyone published a working multiplayer game?

Discussion and feedback on Construct 2

Post » Mon May 25, 2015 9:57 am

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.
B
17
S
5
Posts: 144
Reputation: 1,591

Post » Tue May 26, 2015 4:37 pm

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 :P
B
37
S
9
G
8
Posts: 541
Reputation: 8,554

Post » Tue May 26, 2015 6:55 pm

@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.
Last edited by troublesum on Tue May 26, 2015 7:22 pm, edited 1 time in total.
B
20
S
7
G
1
Posts: 221
Reputation: 2,077

Post » Tue May 26, 2015 7:13 pm

@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.
Last edited by troublesum on Tue May 26, 2015 7:24 pm, edited 3 times in total.
B
20
S
7
G
1
Posts: 221
Reputation: 2,077

Post » Tue May 26, 2015 7:19 pm

xanxion wrote: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 :P


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.
You think you can do these things, but you can't, Nemo!
Just keep reading.
Just keep learning.
B
65
S
16
G
9
Posts: 1,429
Reputation: 12,728

Post » Wed May 27, 2015 7:01 am

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..
B
37
S
9
G
8
Posts: 541
Reputation: 8,554

Post » Wed May 27, 2015 10:06 am

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!
Scirra Founder
B
402
S
238
G
89
Posts: 24,644
Reputation: 196,095

Post » Wed May 27, 2015 10:33 am

xanxion wrote: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 ;)
You think you can do these things, but you can't, Nemo!
Just keep reading.
Just keep learning.
B
65
S
16
G
9
Posts: 1,429
Reputation: 12,728

Post » Wed May 27, 2015 3:47 pm

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.
Follow my progress on Twitter
or in this thread Archer Devlog
B
42
S
18
G
19
Posts: 1,058
Reputation: 14,050

Post » Thu May 28, 2015 12:11 am

@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
Image

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
B
20
S
7
G
1
Posts: 221
Reputation: 2,077

Next

Return to Construct 2 General

Who is online

Users browsing this forum: No registered users and 6 guests