Multiplayer is coming!

Think of the co-op fun. *tears*

Any news about multiplayer ?!

I'm preparing a small multiplayer game for the release but of course I'm missing the webRTC logic, can we have some clarifications about this and a new teaser ? :)

Joskin

I'm guessing Scirra took a little break from multiplayer to get the Wii U beta update out

awesome news, hope it�s not a hoax

So my concern is this will be purely p2p. While some people have plenty of uses for this, mostly in app form, I don't have any uses. I need a server implementation. :P

Maybe I could hook up WebRTC to a server? I'm just so confused as to how this will work!

—, you can extend a nodejs server with webrtc :)

DatapawWolf - server-based is a subset of P2P. The server is just a special type of peer.

Yep, I was just about to say that. P2P solutions can implement the authoritative server model, just as long as you find a way to make clients always connect to the "server peer" and recognize it as being an authority, while at the same time making it impossible for other peers to impersonate a server (this is all pretty easy to do).

Well that's good to know. :) Thanks!

Even if it has P2P capabilities that is no the way you want to go.

P2P does not work nicely in games and real time protocols because you can�t expect a certain quality in terms of lag, performance and speed. It may work great if your user A is in the same city as user B but go to hell if user C is in another part of the world with a crappy Internet connection. Microsoft recently killed that P2P features from Skype exactly for this reason, bad calls, dropped calls, etc, and centralized data on servers.

So even if P2P works, you want to connect your players to a central server, its the only way to expect a decent output in terms of speed for your players and quality unless you want to frustrate allot of players.

I don�t see how this is a problem in todays world where you can get cheap VPS for less than 20$ a month or go with some cloud provider.

Finding or setting up your own server is just plain silly easy today and you will have so much more benefits, just use the same server where you are hosting your game.

Well I agree with DatapawWolf as well. I would also prefer an option for pure server to client implementation.

In P2P the server just acts as a hub to connect players together or initiate the handshake connection, but users are not connected via the server after it, but directly passing data between from one user to the other. This creates all types of problems.

I would prefer users connecting to the server only, not with each other.

Maybe it comes with both options.

As lennaert mentioned —:

ou can extend a nodejs server with webrtc :)

So it's already possible to have a server connection through websocket, and it's likely also possible that you'll be able to have a webRTC connexion going through a server anyway.

Also I have to disagree a bit with your previous statement.

Yes, it's cheap to have a virtual server, yes it's "kind of easy" to set up, but tbh, not all games' scope require such a financial/technical/time investment.

Also, there's nothing wrong in designing your game to be p2p between two players only/directly and skipping the server part.

That's what most C2's customers so far were waiting for since they are not devs and don't necessary want/can be asked to learn complex networking.

Also, the promise of webRTC is that a client made in C2 can as well work as a server, and so you can program it all in C2.

Sure for a "AAA expert commercial product" this might not cut it.

For an indy/hobbyist game made for fun/to have fun, it is more than enough.

I suppose the main issue I and others are concerned about is security and cheating.

In a p2p connection, cheating is often as simple as loading up Cheat Engine and changing one or two variables. Obfuscation or no, this is incredibly simple and can take little no nearly no effort.

If you have a server available to verify at least one or two bits of data here and there, you can prevent the majority of cheaters.

Serverless has another major downside:

What about scores or leaderboards ?

User registeration ?

This sort of functionality, which generally goes hand in hand with online multiplayer or game play, will typically not be availble in a pure p2p gaming connection. (you can have scores and names exchanged between 2 p2p players, but not store it for later review or leaderboard purposes)

Ofc, you can have some alternate means, like updating through ajax calls and what not ... but then you would still need a server.

—, the security measures you mention are sound, there is no decent method of checking without a server.

I am curious as to a self host/server implementation.

Having an active socket pumping data back and forth in your browser can causse lots of slow downs.

Especially if your going to try more then two players.

And to anyone saying that setting up such a host on a VPS server is simple, they might want to reponder about the majority of developers who choose construct 2 for its none-necessity for coding skills.

Even if it has P2P capabilities that is no the way you want to go.

P2P does not work nicely in games and real time protocols because you can?t expect a certain quality in terms of lag, performance and speed. It may work great if your user A is in the same city as user B but go to hell if user C is in another part of the world with a crappy Internet connection.gh, no. If you broadcast your data to peers, it will still be faster than sending it to the server only and letting it re-transmit, regardless of where you are in the world. A straight line from A to B is always shorter than a line from A to C and C to B.

Finding or setting up your own server is just plain silly easy today and you will have so much more benefits, just use the same server where you are hosting your game.nd you'll still be able to do that with a p2p architecture, but you also gain the benefit of not HAVING to have one.

In P2P the server just acts as a hub to connect players together or initiate the handshake connection, but users are not connected via the server after it, but directly passing data between from one user to the other. This creates all types of problems.ou are confusing the handshake server, aka. Tracker, with the game server. You always need the tracker, but the game server is optional, and is just a special type of peer.

Sure for a "AAA expert commercial product" this might not cut it.

I don't see why it wouldn't cut it.

I suppose the main issue I and others are concerned about is security and cheating.

In a p2p connection, cheating is often as simple as loading up Cheat Engine and changing one or two variables. Obfuscation or no, this is incredibly simple and can take little no nearly no effort.ou can implement a completely secure game on a client-only p2p architecture (that is, one that has no "hosts" or "servers") - saying you can just "load up cheat engine and change some values" couldn't be further from the truth in a properly designed environment, that'd be the same as claiming you can edit the amount of bitcoins in a wallet or infect a torrent swarm with a malicious file.

Serverless has another major downside:

What about scores or leaderboards ?

User registeration ?

This sort of functionality, which generally goes hand in hand with online multiplayer or game play, will typically not be availble in a pure p2p gaming connection. (you can have scores and names exchanged between 2 p2p players, but not store it for later review or leaderboard purposes)

Ofc, you can have some alternate means, like updating through ajax calls and what not ... but then you would still need a server.ou provided the answer yourself. Ajax calls are more than enough. Why do you think you are constrained to one approach only? When we say serverless it means servers aren't required, not that they are banned.

Having an active socket pumping data back and forth in your browser can causse lots of slow downs.

Especially if your going to try more then two players.ebRTC is a new standard designed to avoid said slowdowns and offer performance.