Is Multiplayer/online possible with Construct 2?

One of the hardest problems is like Velojet says you need an authoritative server to prevent cheating. However C2's architecture does not lend itself easily to that - even with a good WebSocket plugin (and even assuming it had UDP support) you might have to hand-code a server for your game, and multiplayer programming is pretty tricky on top of that.

Given we have a community of people who are trying to avoid traditional programming, do you think that would still be useful at all? If you had to code a serverside? If so, we could still make some of the clientside plugins (like WebSocket) to provide official support for that. However we wouldn't be able to help much with writing serversides, it would probably be too complicated to write any kind of simple step-by-step tutorial for it.

We'll always have to hand code our own servers, and people who cannot grasp code aren't able to grasp the requirements behind multiplayer (servers, databases, caching, network issues, clustering, dead reckoning, cheat prevention, etc). There isn't any tool in the market able to simplify server coding as much as construct simplifies game development, and besides a "MMORPG MAKER", I don't think there is demand for one such tool.

That being said, I'd love to see an official multiplayer plugin from scirra, though HTML5 isn't ready for it yet - for now it's best that those plugins be made by the community (we're doing great with what we've got, I've been able to implement multiplayer in everything that didn't require a real time element).

C2 could export javascript, and node.js server is running javascript code, so it is not impossible to create server logic by C2 (event sheet + plugin system).

But it need a lot of time to create this exporter which has not canvas render I thought. The C2 development team still has a lot of items at TODO list.

If it's possible I'd rather see a plugin where the client side handles all of the game logic, and the server only handles the initial connection security (eg: a pre-defined password in C2 before export and) forwarding of messages to all other clients.

This way the server could pretty much be a static script that people drop in a public webfolder (eg: DropBox) and point their client to.

This is similar to my CC game Pixel People Online, the server can do some things but it's actually the clients that are all telling each other what's going on. The only thing I didn't like was that messages were sent to everyone, so on each client they had to first check to make sure it wasn't their own message that was received.

If it's possible I'd rather see a plugin where the client side handles all of the game logic ...

That would seem to impose severe limits on the complexity/fun of the game - what if two clients use their internal logic to come up with opposing outcomes (e.g. who has got to a waypoint first)? This is one reason why most serious multiplayer games need an authoritative server.

> If it's possible I'd rather see a plugin where the client side handles all of the game logic ...

That would seem to impose severe limits on the complexity/fun of the game - what if two clients use their internal logic to come up with opposing outcomes (e.g. who has got to a waypoint first)? This is one reason why most serious multiplayer games need an authoritative server.

I'd set up a fake "server"/host who decides how the game plays. Sure, they could potentially mod their own server traffic, but on a whole that will happen regardless of anti-cheat protection in my experience anyway.

The other players send what they try to do, and then the player who is acting host will send back actual data the other clients adapt to.

I'm certain that as long as it can be done from events/built-in to Construct 2, it will be very useful and worth the time to put a multiplayer plugin like that. Sure, allow third party plugins and advanced servers still, but basic multiplayer has to be possible.

... the player who is acting host will send back actual data the other clients adapt to ...

Doesn't that give the player host an unfair/unacceptable advantage? What happens in the situation I posed: what if two clients use their internal logic to come up with opposing outcomes (e.g. who has got to a waypoint first)? (Keeping in mind of course that the data from the player/client will necessarily have taken longer to get to the player/host.)

Jayjay

Yet-another Multiplayer Demo , this system put all game logic on client, server only do broadcasting message.

But it has limitation.

• designer need to sync the game status by itself, it might be complex,
• few security since server only do broadcasting.
• can not put "big world" (like BrowserQuest) in the client side since server might have more computing power then client.

If it's possible I'd rather see a plugin where the client side handles all of the game logic

I'm afraid in practice this is not a workable idea. It's very tempting because it could do a lot to simplify the design of multiplayer games in Construct 2. The reason it wouldn't work though is because cheating would be totally rampant.

If you trust what the client tells you it's done, it could take a mildly technical person a few minutes to figure out what packets are sent outbound when you shoot someone (or complete some objective), then create a keyboard shortcut that does it over and over again (e.g. one key to kill everyone in the level instantly). In short, if your game reaches any level of popularity whatsoever, it will promptly be ruined by widespread unrestricted cheating.

While you could risk this yourself with your own plugin/networking architecture, we could never officially support a system designed that way. Anyone who tried to make a serious game would get totally burned by it, and we don't want to be responsible for that happening.

Since server-authoritive models run the game on the server, basically only user input is sent from the client. So cheating is instantly reduced to automating what are legitimate inputs to the game, which in theory a real human could be inputting to their computer anyway. This usually can only provide a slight edge, rather than totally owning a game.

Velojet, as explained it's just as bad as most cheating in games anyway where players can self-host servers or even MMO's with "anti-cheat". A slightly easier way to fix it is to simply not tell the player they are the host, and to try and pick host by best ping.

rexrainbow, ah awesome, and yes I know it's not MMO quality, but I'm thinking of smaller games that people play with their friends rather than massive multiplayer.

Ashley, ah okay I know exactly what you mean, but I think it'd be really important for built-in support for even the most basic of things like online chat, for those who aren't worried about extreme cheating or aren't basing their game around the multiplayer aspect.

It could be like exporting Windows 8 apps instead though, where you go into the exported files and change a value or two to make the server work specific to your game.

Edit: Ah, online chat would be perfect actually, that way people *could* use it to send gameplay messages without much difficulty, but they'll accept that it's not a serious server.

Velojet, as explained it's just as bad as most cheating in games anyway where players can self-host servers or even MMO's with "anti-cheat" ...

I wasn't talking about cheating (I left that to others :). My question was about the management/mediation of gameplay. As rexrainbow points out, having a client/host sync the game status by itself would be complex.

Doesn't that give the player host an unfair/unacceptable advantage? What happens in the situation I posed: what if two clients use their internal logic to come up with opposing outcomes (e.g. who has got to a waypoint first)? (Keeping in mind of course that the data from the player/client will necessarily have taken longer to get to the player/host.)I think most of these problems in theory could be solved with cleaver ideas. For instance, you could have a built in rule on a generic server to use an equal random chance to give priority to one of the user's outcome when there's conflicting data. Although this would not be absolutely fair, it would be acceptably fair and that's what matters for a game.

Even if it's not possible to solve absolutely everything, I think a client side multiplayer would still have it's uses.

Velojet

There still had a simple way to create multi-players game, like the world editor of warcraft3.

Velojet, as explained it's just as bad as most cheating in games anyway where players can self-host servers or even MMO's with "anti-cheat". A slightly easier way to fix it is to simply not tell the player they are the host, and to try and pick host by best ping.

Anti-cheat doesn't work - see gunbound/maple story.

rexrainbow, ah awesome, and yes I know it's not MMO quality, but I'm thinking of smaller games that people play with their friends rather than massive multiplayer.

As Ashley said, if he cannot make it work seamlessly with the same quality as the rest of the product, he'll leave it to third party developers (that's us).

Ashley, ah okay I know exactly what you mean, but I think it'd be really important for built-in support for even the most basic of things like online chat, for those who aren't worried about extreme cheating or aren't basing their game around the multiplayer aspect.

It'd still involve a server, and custom server-side scripting, since p2p html5 tech isn't there yet, and even if it was, we'd have no way of identifying multiple instances of our game without a server.

It could be like exporting Windows 8 apps instead though, where you go into the exported files and change a value or two to make the server work specific to your game.

a value or two or thirty or a hundred thousand...

The only way I see this working is an exporter for node.js that skips drawing - as awesome as I think that would be, the work/benefit ratio isn't as good compared to, for instance, new objects/plugins (deep json parsing, rich text boxes, skinnable form controls, etc), more powerful eventing (custom ACEs, callbacks, widgets, modules, etc), IDE options (collaborative editing, search'n'replace, tiled level editor, AI editor, etc), developer possibilities (Hooking into the interface, plugins able spawn dialogs) or even working on the site (improving the store and the arcade, for instance). Thoughts Ashley?

Fimbul

"The only way I see this working is an exporter for node.js that skips drawing"

I agree. A game world running at node.js server without render is good enough. Other things could be done by 3'rd plugin.

Although node.js might not be fast enough, or have enough library supporting, it is the best choice that it could combine with C2 editor (layout editor + event sheet + plugin system) to create serve without programming (uh, it's still need 3'rd plugins).

... The only way I see this working is an exporter for node.js that skips drawing - as awesome as I think that would be, the work/benefit ratio isn't as good compared to, for instance, new objects/plugins ...

<img src="smileys/smiley20.gif" border="0" align="middle" /> Agreed. There's also the user/benefit ratio. Development of Fimbul's list would IMO benefit far more users than a node.js exporter - and I suspect that those who would make most/best use of such an exporter would be well able to handle the JavaScript coding that it would replace.