Multiplayer is coming!

0 favourites
From the Asset Store
The fear of darkness is coming "DARK HORROR MASTER"
  • 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

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

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

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • 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).

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

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

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

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

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)