Multiplayer is coming!

Discussion and feedback on Construct 2

Post » Tue Jan 28, 2014 5:33 am

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.weiterer2014-01-28 05:33:50
B
4
Posts: 19
Reputation: 663

Post » Tue Jan 28, 2014 8:07 am

As @lennaert mentioned @weiterer:
[quote]you can extend a nodejs server with webrtc :) [/quote]

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.
New to Construct ? Where to start

Image Image

Image Image

Please attach a capx to any help request or bug report !
Moderator
B
292
S
115
G
96
Posts: 7,293
Reputation: 70,769

Post » Tue Jan 28, 2014 8:20 am

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.
ImageImageImageImage
B
62
S
19
G
51
Posts: 633
Reputation: 30,826

Post » Tue Jan 28, 2014 9:31 am

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.


@datapadwolf, 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.
Who dares wins
B
57
S
17
G
21
Posts: 1,878
Reputation: 19,572

Post » Tue Jan 28, 2014 12:24 pm

[QUOTE=weiterer] 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 cant 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.[/QUOTE]Ugh, 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.[QUOTE=weiterer]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.[/QUOTE]And you'll still be able to do that with a p2p architecture, but you also gain the benefit of not HAVING to have one.[QUOTE=weiterer]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.[/QUOTE]You 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.[QUOTE=Kyatric]Sure for a "AAA expert commercial product" this might not cut it. [/QUOTE]
I don't see why it wouldn't cut it.[QUOTE=DatapawWolf]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.[/QUOTE]You 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.[QUOTE=lennaert]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.[/QUOTE]You 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.[QUOTE=lennaert]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.[/QUOTE]WebRTC is a new standard designed to avoid said slowdowns and offer performance.
B
36
S
8
G
8
Posts: 532
Reputation: 6,903

Post » Tue Jan 28, 2014 12:43 pm

[QUOTE=DatapawWolf] 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.[/QUOTE]

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.
B
70
S
24
G
19
Posts: 1,757
Reputation: 17,614

Post » Tue Jan 28, 2014 6:36 pm

[QUOTE=Silverforce] [QUOTE=DatapawWolf] 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.[/QUOTE]

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.[/QUOTE] 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.

[QUOTE=Fimbul] [QUOTE=DatapawWolf]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.[/QUOTE]You 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.[/QUOTE] 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.DatapawWolf2014-01-28 18:38:12
ImageImageImageImage
B
62
S
19
G
51
Posts: 633
Reputation: 30,826

Post » Tue Jan 28, 2014 6:46 pm

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.Ashley2014-01-28 18:47:11
Scirra Founder
B
397
S
236
G
88
Posts: 24,420
Reputation: 194,549

Post » Tue Jan 28, 2014 7:06 pm

[QUOTE=DatapawWolf]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.[/QUOTE]No 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.
[QUOTE=DatapawWolf][QUOTE=Fimbul]...snip...[/QUOTE]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.[/QUOTE]Not 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).[QUOTE=DatapawWolf]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.[/QUOTE]What 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

[QUOTE=Ashley]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.[/QUOTE]The 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.Fimbul2014-01-28 19:12:47
B
36
S
8
G
8
Posts: 532
Reputation: 6,903

Post » Wed Jan 29, 2014 3:42 am

Fimbul, I beg to differ. Im 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.

Im 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.
B
4
Posts: 19
Reputation: 663

PreviousNext

Return to Construct 2 General

Who is online

Users browsing this forum: No registered users and 14 guests