Requirements for multiplayer pack

I am brainstorming for the requirements for a multiplayer pack for PlayCanvas. Here are some I’ve thought of. Your requirements are welcome! Please respond!

public messages routed to all connected players (broadcast, throttled)
protected messages routed to a few connected players (guilds, groups, rooms)
private messages routed to one player (peer to peer)
message types: text, image, whiteboard/model, application dependent, DOM, anchor
Stored messages, time to store

Location, Orientation, Voice, Video, Audio, Screen sharing, application dependent, animation

Design messages with property sheets
Hook up message types to JavaScript functions
Hook up input events to send out messages

Game Play:
Location, Orientation, Collisions
Turn Taking:
Various sequential turn taking
Various parallel turn taking
Late join, early leave

Game setup:
Finding a game instance

High score chart, statistics for multiple players


Hi @yottzumm.
Multiplayer world is very unique for each case. The reason why web is not full of multi-purpose solutions for actual gameplay logic - is that each case, require unique approach and changes by project basis.

Saying that, there are basic concepts like server-client networking model, and peer-to-peer, and those can be implemented in simple example and showcased, but still this will change for different project again.
So in networking world, most of stuff has to be understood by a developer, and examples in fact wont help too much without try-and-fail from developer himself.

As well the approach for a logic in multiplayer game very differs from classic web applications logic type, and requires of thinking in totally different angle here. Like messages you’ve described, most web games have one type of messaging system with server, the rest depends on client application to act differently on those messages. Building DOM hooks or some other stuff - fair enough, but that is very different for all different cases.
Public/protected/private etc, again is very up to game logic to implement and do.

I recommend reading into direction of: dead reckoning, server-client networking model, authoritative server networking politics, websockets, webrtc. In gamedev context of course.

1 Like

@max. I agree that multiplayer pack is difficult. We might gain some insight if we look at the multiplayer aspect of Orwant’s Extensible Graphical Game Generator. I was kind of imagining some kind of protocol designer and protocol handler designer. Obviously, JSON and XML apply here, along with templating for protocol design, if we want to deal with a text protocol (which may be highly dangerous). So instead, I might lean towards object-capabilities and vats. Webkeys might come into play.

I don’t think we need to reinvent the wheel here. There are many multiuser and multiplayer systems we can learn from. We don’t have to solve the problem all at once. Instead we can provide an expanding set of tools. The popularity of multiuser tools like auctions, trading, forums, and chat might show a way forward to start adding to our toolbox. Documents like EGGG and my paper might show us how to have a synchronization toolbox. Basically it just takes someone to sit down with some requirements and then design and code it. Stating that the requirements are too broad isn’t helpful. What is helpful is defining the requirements for multiplayer for YOUR games. If we don’t have YOUR requirements, then we can’t design or code anything. Technologies like client server, web sockets and webrtc aren’t requirements. What if I was considering named data networking?

1 Like

Sorry if my post was harsh. I’m a bit of a dirtbag. My wife told me to say that. @max I’m sorry but your post upset me. I’m ready for the icebucket challenge now. If you don’t want to share your requirements that’s okay with me :slight_smile:

@max I’m trying to your extract your requirements. You want dead reckoning in a common place which is protected from the players?

Once we get a list of requirements, we can prioritize them so I can deliver those which will provide the most developers the most benefit. For example, if providing a messaging layer isn’t important, because there are other ways to do that, then it won’t get implemented in the first pass. That’s why YOUR requirements are important. If I don’t know what the community wants in the way of multiplayer support…guess what? It won’t get implemented unless you do it yourselves.

If someone has a requirement for looking at various types of move, turn, step, or phase taking and doesn’t have the time to look into the mechanisms for this, I would be willing to at least spend the effort to take your requirements and turn them into an API design which we can comment on before I or we implement the design. And we aren’t going to do this in a vacuum either. We will solicit possible designs from other gaming communities to see if they’ve already done something. That’s the beauty of open source, we get as many eyes looking at the problem as we can. We look at others code to see if we can improve it.

Max has stated that he hasn’t seen a lot of support for multiplayer requirements in the general community. I on the other hand, have seen some multiuser implementations that might work well for some games ( Let’s hear what other people have run into.

Thanks, and sorry for being a dirtbag.

1 Like

Perhaps I need to work on being a more motivational speaker. If someone hadn’t figured out what the requirements were for PlayCanvas, then the software wouldn’t be here today. I suspect that some of them were like, we’d like to do something like that software, but do it in JavaScript, so we could put it on the web. That’s what we want to do with multiplayer requirements…put working multiplayer systems on the web. We want to develop expertise so WE will be the ones people come to when they want to put a multiplayer game on the web, web mobile devices, etc. If we ultimately contribute to PhoneGap instead of PlayCanvas because OUR requirements push us in that direction, I don’t see a problem with that. We can probably create an equivalent WebGap for web browsers which will put our requirements on the Web. I for one, do not feel intimidated about working with the community to create extensions for web browsers, as long as we have a good requirements and design.

If you want to go play with websockets because you don’t like requirements. That’s fine. Your system will do websockets. Meanwhile we’ll be making the web a true multiuser and multiplayer system.

Here’s something else. If you’d like me to come up with a design all on my own, and then you will throw tomatoes at it, that’s okay too. Likely, I’ll say, where were you when we were discussing requirements? THEN you’ll come up with requirements, rinse and repeat. So far, I’m working on dead reckoning and securing the games from clients.

Here’s a sample API. CreateCapability() is a server function which returns a capability to create a piece. createPiece() takes the capability and creates an piece at an initial position and location or error if the capability has been revoked. softMove() moves the piece to an new position and orientation based on what the server thinks is reasonable. stuck() moves the piece to a safe place after the server determines and logs that it is stuck. If the piece or client or IP address reports too many stucks or raises it’s health too much or creates too many pieces, it may be penalized for cheating.
update() gets position, orientation, health, damage, score and place for a piece from the server. removeCapability gets a capability to remove a piece from the server. If the capability is returned to the server in the remove function, the piece gets removed{}, failure(){});
capability.createPiece(initial_position, initial_orientation, initialHealth, initialDamage, initialScore, initialPlace, success(piece){}, failure(){}, error_func(error){});

piece.softMove(position, orientation, health, damage, success(position, orientation){}, failure(position, orientation){}, error_func(error){});

piece.stuck(success(position, orientation){}, error_func(error){};

piece.update(success(position, orientation, addedHealth){}, collision(position, orientation, damage){}, order(place){}, die(position, orientation, score, standings){}, error_func(error){};

piece.removeCapability(success(remove_capability){}, failure(){}, error_func(error){};
remove_capability.remove(success(){}, failure(){}, error_func(error){});

comments? Other game engines to look at for this sort of thing? I need to look at the PlayCanvas API for position and orientation, if this seems like an okay first thing to work on.

Hi @yottzumm,

Ignore @max he a grump who thinks everything should be custom written. :wink:

I think there are definitely some ideas in networking that can be shared across games. Personally, I would separate the requirements in to the types of games. Then work on a manageable implementation of one area. Rather than trying to spec out a complete system which covers all possibilities.

For example:


  • Authoritative
  • Non-Authoritative


  • Realtime
  • Turn-based

I suspect that these four combinations are different enough to be almost separate implementations. If we start with the simplest of the four: Turn-based, Non-authoritative these are some of the requirements:

  • Client (A player who connects is a client)
  • Room (All clients are placed into one room and only one room)
  • Message (A message can be exchanged between Clients in a room)
  • Event (An event is raised at certain times, JoinRoom)

I’m sure there is much more, but my strategy would be to make a basic implementation and pull out the specifications from there.

1 Like

This looks like a good writeup for authoritative servers. Any others? Gafferon Games

I am thinking I should have client events like onupdate() onheal() ondamage() oncollision() onorderchange() ondie() onerror() onroompurge() onroomready() onmessage() onturnbegin() onturnend() score() onpowerplay() oncounter()-- others?

Thus the server should have functions like update() heal() damage() collide() orderchange() die() error() roompurge() roomready() message() turnbegin() turnend() score() powerplay() counter()

We should have server events like onmove() onshoot() onslash() onpowerplay() oncounter() onquit() onclientjoin() onclientpart() onmessage() onturnbegin() onturnend()

Thus the client has functions like move() shoot() slash() kick() overpower() counter() quit() join() part() message() begin() end()

Here is the idea I have for a basic, skeleton server, part of which was taken from that might be filled in in the authoring tool, and default stuff may be added for physics (which is almost beyond my charter). I’m not sure of the license of Can be used in PlayCanvas, or will we have to roll our own?

var app = require(‘express’)();
var http = require(‘http’).Server(app);
var io = require(‘’)(http);

app.get(’/’, function(req, res){

function Multiplayer() {

Multiplayer.prototype = {
clientmessage: function(msg) { io.emit(‘servermessage’, msg); },
clientmove: function() {},
clientshoot: function() {},
clientslash: function() {},
clientpowerplay: function() {},
clientcounter: function() {},
clientquit: function() {},
clientturnbegin: function() {},
clientturnend: function() {},

io.on(‘connection’, function(socket){
socket.on(‘clientmessage’, Multiplayer.prototype[‘clientmessage’]);
socket.on(‘clientmove’, Multiplayer.prototype[‘clientmove’]);
socket.on(‘clientshoot’, Multiplayer.prototype[‘clientshoot’]);
socket.on(‘clientslash’, Multiplayer.prototype[‘clientslash’]);
socket.on(‘clientpowerplay’, Multiplayer.prototype[‘clientpowerplay’]);
socket.on(‘clientcounter’, Multiplayer.prototype[‘clientcounter’]);
socket.on(‘clientquit’, Multiplayer.prototype[‘clientquit’]);
socket.on(‘clientturnbegin’, Multiplayer.prototype[‘clientturnbegin’]);
socket.on(‘clientturnend’, Multiplayer.prototype[‘clientturnend’]);

http.listen(3000, function(){
console.log(‘listening on *:3000’);

Here is a basic implementation of a client, the skeleton may be filled in with the authoring tool. The jquery code comes from, and may be replaced. The rest is mine, and should be implemented. We’ll have to add namespaces to clean it up, but comments are welcome.
function Player() {

Player.prototype = {
servermessage: function() {},
serverupdate: function() {},
serverheal: function() {},
serverdamage: function() {},
servercollision: function() {},
serverorderchange: function() {},
serverdie: function() {},
servererror: function() {},
serverroompurge: function() {},
serverroomready: function() {},
serverscore: function() {},
serverpowerplay: function() {},
servercounter: function() {},
serverturnbegin: function() {},
serverturnend: function() {}
var socket = io();
socket.emit(‘clientmessage’, $(’#m’).val());
return false;
socket.on(‘servermessage’, Player.prototype[‘servermessage’]);
socket.on(‘serverupdate’, Player.prototype[‘serverupdate’]);
socket.on(‘serverheal’, Player.prototype[‘serverheal’]);
socket.on(‘serverdamage’, Player.prototype[‘serverdamage’]);
socket.on(‘servercollision’, Player.prototype[‘servercollision’]);
socket.on(‘serverorderchange’, Player.prototype[‘serverorderchange’]);
socket.on(‘serverdie’, Player.prototype[‘serverdie’]);
socket.on(‘servererror’, Player.prototype[‘servererror’]);
socket.on(‘serverroompurge’, Player.prototype[‘serverroompurge’]);
socket.on(‘serverroomready’, Player.prototype[‘serverroomready’]);
socket.on(‘serverscore’, Player.prototype[‘serverscore’]);
socket.on(‘serverpowerplay’, Player.prototype[‘serverpowerplay’]);
socket.on(‘servercounter’, Player.prototype[‘servercounter’]);
socket.on(‘serverturnbegin’, Player.prototype[‘serverturnbegin’]);
socket.on(‘serverturnend’, Player.prototype[‘serverturnend’]);

say I noticed that script tags weren’t shown when I included them. does that mean I can include javascript to be run on someone else’s browser? Not a good idea for a forum :frowning: Looks like it’s ignored. Good!

I think the next step may be adding functionality to the server, either for turn taking or physics, dead reckoning etc. what do people think should be next?


Just wanted to share some generic APIs I’ve worked with in the past for multiplayer. Maybe you ll get some architecture ideas from them as they are widely used

One is Photon Server

And the other one is Smartfox Server

The Valve / Source Engine documents are a great place to learn about designing multiplayer servers:

Say I started with the JavaScript client API for SFS2X. What other functionality would people want in a multiplayer server? See:

Hi guys,

I am a noobie here, but have been very impressed with with the PlayCanvas projects I have seen to date. Well done everyone!!!

I am very interested in seeing a multiplayer framework (or several to accommodate different styles of games) being utilised for this platform.

Just wondering what the status is on such a development. E.g., are there any examples of multiplayer games using play canvas etc.?



Hey @uqsbolla,

Check out Tanx:

(project link)

(play link)

It uses Node.js for the server and will definitely help you get started with multi player game development.

1 Like

Hello @yottzumm.

Are you interested in starting with a basic game, and working up from there? The Tank game that @vaios pointed out may be a good place to start. I’m just trying to get something up and working now but I’d love to support multiple players from different sites. Now the game will support two players (mainly to test the performance. . .but I’m a full screen type of guy :smiley: )

You can see my progress in another thread, “Wanted to share my progress” (Wanted to share my progress thus far).

We could add a team room, or melee mode, chat between teams, and obviously game updates. As we develop we could attempt to make it as generic as possible so that others could benefit from it.

Please let me know.