Multiplayer is coming!

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.

There is a flaw in this that goes way back in gaming history, and here's a simple dogma for gaming.

If people want to cheat, they will. No matter your implementation. Even MMOs with a massive team and server side monitoring have cheats. Don't design your game around cheaters, focus on the rest of the good folks.

> 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.

There is a flaw in this that goes way back in gaming history, and here's a simple dogma for gaming.

If people want to cheat, they will. No matter your implementation. Even MMOs with a massive team and server side monitoring have cheats. Don't design your game around cheaters, focus on the rest of the good folks.No I know that. I've seen it go wrong, before (when I was the cause...), but even a little anti-cheat can go a long way. This is especially true of competitive games. Co-Op? Who really cares. But if your multiplayer implementation is meant to provide friendly competition, and your game is even minutely popular, cheating can cause people to simply drop out. You don't want to shy players away from your product because of other unruly people.

> 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.Yes, you can, but it's not as easy as using a server, and often games will provide little to no anti-cheat whatsoever. In a p2p system you often have a host and a client(s) - or at least from what I've learned in my classes - and if you figure out who is the host, and you are it, you can do pretty much anything unless you have a server to check it.

And good luck with anti-cheat using Javascript. There are client-heavy games that have succeeded in preventing cheating, but the only ones that come to mind are Flash games such as RotMG, which uses an insane AS3-specific obfuscation that JS will never have.

I'd agree that you could properly design a game to prevent the majority of cheaters, but the degree you could achieve is limited by using JS or using C2 for web-browser games.

The size of Construct 2's runtime might actually work to its advantage here. Hacking small, custom-written games is often easy - there might just be global variables with your score or position or whatever in them, and once you've found them, game over. However C2 has tens of thousands of lines of JS, all making up a fairly large framework that tends to store things buried fairly deep in lists and tree structures. Even pretty printing the code and running it through dev tools is a pretty daunting task. It's also possible to "protect" variables by keeping multiple copies of them in different places, but modified in some way (e.g. converted to a string and reversed). Then you can check for modifications if the variable doesn't match up with the copies. Combine that with a large and complicated obfuscated engine and it would probably be tricky enough to keep out casual scripters. And then, only the host can mess around with things - and if you're playing with a cheating host, I guess you can just find someone else to play with.

And good luck with anti-cheat using Javascript. There are client-heavy games that have succeeded in preventing cheating, but the only ones that come to mind are Flash games such as RotMG, which uses an insane AS3-specific obfuscation that JS will never have.o competent engineer will think a third-party anti-cheat solution is appropriate to an online game. You have things like GameGuard, PunkBuster, valve's VAC and blizzard's warden but all they do is create parallel markets for cheats. Cheating countermeasures must be integrated in your game's architecture.

Even if client-side anti-cheating solutions were a good idea - and they are not - there are no technical reasons preventing you from deploying your own JS-based obfuscation that runs circles around AS3 solutions - heck, you'll probably make a ton of money if you can do it.

Games like League of Legends have no anti-cheat programs - you can run cheat engine right along with it and it won't ever complain. Yet there are no cheats for LoL (except rudimentary tools that can't even be considered cheats). Meanwhile, gunbound has had decades of cheat signature collection and has tried many anti-cheat providers, but it's still a festival of aimbots and hackers. Why do you think that is? One word: architecture.

> ...snip...n a p2p system you often have a host and a client(s) - or at least from what I've learned in my classes - and if you figure out who is the host, and you are it, you can do pretty much anything unless you have a server to check it.ot at all. P2P simply means you allow clients (aka peers) to connect to each other. Like I said many times before in this thread, a server-client architecture can be achieved easily in a p2p solution, but not the contrary - hence Ashley saying server-based is a subset of p2p.

Besides, who said if you're the host you have free reign to cheat? Games like Warcraft 3 use that architecture and you cannot simply "cheat" the quantity of gold or wood you have: if you attempt to, the game desyncs and kicks you out (thus ending the game).

I'd agree that you could properly design a game to prevent the majority of cheaters, but the degree you could achieve is limited by using JS or using C2 for web-browser games.hat makes you think JS is inferior to anything else? Clients are self-contained, in order to cheat in a properly designed "pure" p2p game, you'd have to find a way to modify the code in the remote clients, which would require attacks of a magnitude far greater than simple game hacking. That is the same in all games, regardless of programming language. Making the game in C++ (for instance) would change nothing.

This book explains everything you need to know about game security - I highly recommend it

And then, only the host can mess around with things - and if you're playing with a cheating host, I guess you can just find someone else to play with.he clients can do their own verifications to see if the other peers (including the host) might be cheating. In that case(excluding certain kinds of cheats like bots), only the developer would be able to cheat.

Fimbul, I beg to differ. I�m not a game developer, I work with servers and datacenters for a living so I actually know when I tell you that most people want servers for their games and p2p has all type of troubles for data connections unless your requirement is just for 2 persons and packets are low on bandwidth.

Not only I see people asking this all day but like I explained before, even Microsoft switched Skype off from p2p. Most people using Voip which is going to be similar to game requirements, also use a middle server, usually a voip provider, and do not usually call from machine to machine.

On the Google presentation they even explain for WebRTC, you will need a server to handle multiple connections because its just the nature of it once its scales.

This may work wonderful for someone playing chess with another party, but not if you want to connect 100 players together playing the same game at the same time. The network will start to drag the slowest link of all.

Its not correct than p2p is the shortest path either because that is not how networks are deployed worldwide.

Example, a player in Chile connecting to someone playing in Brazil will not connect via the mainland continent, their connection will travel to the US and then back creating an increase of 2 times the latency as opposed to just finishing the connection in the US. One nice example is that almost all South America is connected via Miami as a central hub, and usually for most countries there their connection will travel to the US and then back to the destination country.

In this small example case if your target is Latin America or have players there you would have a server in the US and it will be faster for everyone vs players connecting with each other.

This is also the reason why Dallas in the US is so huge in terms of datacenters, because companies like to host their servers on a middle ground in terms of distance. Same latency to LA or New York.

If your market is locally then p2p will work great, but not if your players are connecting from all over the world.

Even if they are local players (same city, state, etc) you will not achieve high bandwidth outputs with p2p, it will work for a couple of players tops because each user needs to stream their connection up to the network, and even in countries with high Internet speeds this is usually very low. Example, last time I was in Germany on a residential ISP connection download speeds for a 25 MBPS connection, only had tops 1 Mbps upload, now try connecting all your players via 1 Mbps. For a small game that only sends positions this will work fine, but it will cause problems as players increase. Now most games only send a few details, like position, score, etc, but still if latency sucks in one user it will drag the whole game down, this means all players.

On real live games this means suffering connection drops, slow games, etc.

Is that all worth?

In particular because setting up a server is so cheap and you will need to host scores, registrations, and probably a website anyway for your game.

I�m not against P2P but if P2P worked for most things we would not have datacenters and servers today. P2P like its name says is peer to peer, and is usually designed for person to person. I imagine someone developing a game will need more than just a couple of players, that is the idea of multi-player. If you are creating a big multiple player game there is no way P2P will ever work.

If you only need to test it with a coupe of people or are playing with friends, then this will work just fine.

The size of Construct 2's runtime might actually work to its advantage here. Hacking small, custom-written games is often easy - there might just be global variables with your score or position or whatever in them, and once you've found them, game over. However C2 has tens of thousands of lines of JS, all making up a fairly large framework that tends to store things buried fairly deep in lists and tree structures. Even pretty printing the code and running it through dev tools is a pretty daunting task. It's also possible to "protect" variables by keeping multiple copies of them in different places, but modified in some way (e.g. converted to a string and reversed). Then you can check for modifications if the variable doesn't match up with the copies. Combine that with a large and complicated obfuscated engine and it would probably be tricky enough to keep out casual scripters. And then, only the host can mess around with things - and if you're playing with a cheating host, I guess you can just find someone else to play with.

If you are sending files to the user, something like ioncube will protect at least something.

But for open code like HTML5 games usually are, a server side is the only way to protect the game, just like no one would allow users to view your asp or php code that runs on the website. The server side option is the only realistic option that can potentially avoid some of this cheating problems.

People who host their own servers are usually the biggest cheats.

Could do like Minecraft servers and charge a fee to let people cheat.

I think the biggest step will be to produce a game, that's even worth to cheat in :-D

Fimbul, I beg to differ. I?m not a game developer, I work with servers and datacenters for a living so I actually know when I tell you that most people want servers for their games and p2p has all type of troubles for data connections unless your requirement is just for 2 persons and packets are low on bandwidth. also work with servers, datacenters and clusters, and I can tell you it's looking more decentralized every day, because monolithic servers simply cannot scale.

Not only I see people asking this all day but like I explained before, even Microsoft switched Skype off from p2p. Most people using Voip which is going to be similar to game requirements, also use a middle server, usually a voip provider, and do not usually call from machine to machine.icrosoft moved skype to the cloud. The p2p remains, but now the peers are microsoft's own servers. Even if Microsoft ends up completely centralizing the whole Skype infrastructure, so what? As if Microsoft were the king of good decisions - see Internet Explorer.

On the Google presentation they even explain for WebRTC, you will need a server to handle multiple connections because its just the nature of it once its scales.ou need a server for it to work at all, not just for scaling it.

This may work wonderful for someone playing chess with another party, but not if you want to connect 100 players together playing the same game at the same time. The network will start to drag the slowest link of all.hat? If that were the case, bittorrent would only download at the speed of the slowest peer, and that is clearly not the case.

Its not correct than p2p is the shortest path either because that is not how networks are deployed worldwide.

...snip...

In this small example case if your target is Latin America or have players there you would have a server in the US and it will be faster for everyone vs players connecting with each other.layer A in Brazil connects to Player B also in Brazil via link C in the US (p2p-model)

vs

Player A in Brazil connects to server C in the US, which then transmits data to player B in Brazil (server model)

How is that any faster? Worst case scenario, they are exactly the same. In all other cases, the p2p model is faster.

Besides, like I said three times before, you can mix the models:

Player A in Brazil connects to Player B also in Brazil

Player A in Brazil connects to Server C in the US

Player A sends data to both B and C

Server C sends player A's data to player B

Player B receives the data from player A and, much later, the same data again from server C

In player B's perspective, data received directly from player A isn't trusted implicitly, but is used for interpolation. Data received from server C is authoritative, and is used to determine serious state changes, such as kills, health, etc., and also as a backup should the direct link from A to B fail.

Even if they are local players (same city, state, etc) you will not achieve high bandwidth outputs with p2p, it will work for a couple of players tops because each user needs to stream their connection up to the network, and even in countries with high Internet speeds this is usually very low. Example, last time I was in Germany on a residential ISP connection download speeds for a 25 MBPS connection, only had tops 1 Mbps upload, now try connecting all your players via 1 Mbps. For a small game that only sends positions this will work fine, but it will cause problems as players increase. Now most games only send a few details, like position, score, etc, but still if latency sucks in one user it will drag the whole game down, this means all players.Mbps uplink is more than enough: you could send 10kb packets every 10ms (that is, 100 frames per second) - 10Kb of UTF8 text allows for between 10240 and 40960 characters. Those are insanely high values for a packet, and you could probably get away with something like 128 kbps.

On real live games this means suffering connection drops, slow games, etc.

Is that all worth?

In particular because setting up a server is so cheap and you will need to host scores, registrations, and probably a website anyway for your game.

I?m not against P2P but if P2P worked for most things we would not have datacenters and servers today. P2P like its name says is peer to peer, and is usually designed for person to person. I imagine someone developing a game will need more than just a couple of players, that is the idea of multi-player. If you are creating a big multiple player game there is no way P2P will ever work.

If you only need to test it with a coupe of people or are playing with friends, then this will work just fine.2P is not exclusively person to person, though, it's peer to peer. Must I repeat myself again? A server is just a special type of peer!

If you want to argue with me that you can't possibly program a server in construct 2 to handle thousands of players, then yes I agree, but no one said you had to do that. Fire up node.js, it can talk to c2 just fine.

But for open code like HTML5 games usually are, a server side is the only way to protect the game, just like no one would allow users to view your asp or php code that runs on the website. The server side option is the only realistic option that can potentially avoid some of this cheating problems.id you read what I posted? It makes no difference whether the game is made in HTML5 or C++, and it makes no difference if the game is hosted on a server or on a machine in the client, the architecture is all that matters. If starcraft 2 needed server-side security to prevent cheating, it wouldn't have become the e-sport it is today. If bitcoin needed a server to provide security, it wouldn't be worth over $800 each.

Besides, no one said you can't have a server.

So,

Fimbul From what you've said, am I correct in saying that I can design a peer that functions as a server using WebRTC?

Then,

Ashely would a Construct 2 app be able to successfully/feasibly function as a server using its upcoming p2p features with WebRTC?

Matter of fact, I do have another question, can/will/does C2 have the ability to interact with MySQL? So say I create a peer server, could I then store/retrieve, say, user data using MySQL?

Would this all (peer server & MySQL) even be worthwhile?

DatapawWolf

the answer is yes.

Put in the IP address in the client version. You host or have a host for the server version. Nothing stops this version from anyone writing a server using C2 code. Once you achieve P2P, you can just set up one pear as a server.

The requirement for coding a server in another language has been the only hurdle for C2 online service. It could be done by anyone to do online. It's just that most C2 devs would rather use C2 to write a server. so we are a go now.

I'm looking forward to brain explosions people are going to have when it's releasef and find the complexity of network games :D

So,

Fimbul From what you've said, am I correct in saying that I can design a peer that functions as a server using WebRTC?es! We'll see what Ashley comes up with - in principle, there's nothing in WebRTC preventing you from doing it all within construct.

Ashely would a Construct 2 app be able to successfully/feasibly function as a server using its upcoming p2p features with WebRTC?he only problem with that is whether you mean a normal server (one of the player is the host) or a dedicated server. Both are feasible with construct 2, but for a dedicated server you'll either have to pair it up with a tracker (that is, a non-construct server responsible for handling handshakes between peers), or Ashley will have to come up with a server-side exporter (maybe node.js?), which is a lot tougher (But I would pay a hefty sum of money for a node.js exporter that could handle application design instead of purely gamemaking - might be a way to expand into the corporate market Ashley? *Wink*Nudge*)

Matter of fact, I do have another question, can/will/does C2 have the ability to interact with MySQL? So say I create a peer server, could I then store/retrieve, say, user data using MySQL?

Would this all (peer server & MySQL) even be worthwhile?nless Ashley makes a node.js exporter (in which case you'd probably have plugin wrappers for the npm database drivers), the only way you'll be able to talk to MySQL is via the traditional method of calls to a webserver. If the "server" isn't publicly available and is just a construct app that you leave open in chrome (quite the flimsy architecture if I may say so), you could design a pretty simple PHP proxy to forward ajax calls to MySQL - it would probably need less than 20 lines of code total.

It would definitely be worthwhile! For more complex games, say MMOs, you'd probably want to ditch construct for the backend though (unless there's that node.js exporter)

Fimbul

Well, you actually kinda have the node.js exporter, thanks to the great guys at node-webkit. Nothing stops you to create a C2 written nw app, that runs in background and acts as a server. Just ignore the webkit part of nw, and use just node.js part. Put that on a pc with a public ip and you're done.

It's not the usual way someone would host and run node.js servers, and i don't recommend to do that, but hey, you can write a fully pledged http (or udp or tcp or etc) server in C2, it just comes with a backpack filled with webkit.

Also, i'm kinda amused with this all fuss about multiplayer coming to C2. It's already here; there are 2 official and about 5-6 unofficial plugins for about a year now (or more?) for creating different kinds of C2 multiplayer games. They are just not called "Multiplayer" and one has to be resourceful in using them.

I'm really glad when anything gets official support in C2, so cheers to Scirra on this announcement.

WebRTC!

can/will/does C2 have the ability to interact with MySQL? So say I create a peer server, could I then store/retrieve, say, user data using MySQL?

Would this all (peer server & MySQL) even be worthwhile?

A nodejs server can be extended with node-mysql.

Also, you can combine techniques.

I combined a socket.io server connectivity with php/mysql/ajax connectivity. (socket.io for player updates and ajax for room and channel control)

I'm looking forward to brain explosions people are going to have when it's releasef and find the complexity of network games :D

amen

What exactly is your point?

You more or less confirmed what I said or misinterpreted what I tried to explain. Between only p2p and only a server side setup, I prefer the last, between both if I need to choose, I would still go with the last, and between a combination of both, of course I would take both to benefit from both of them. It just seem it was going to be one or another, if you can combine both of them, then great.

I was not trying to argue with you.