@mdotedot now to think of it. Perhaps static/02-state-handler.html does not work for you because you don't use haxe rc2 to compile server. Thing is that haxe prior to rc2 will still compile the js server code but it will be ES5 javascript. Code generated in this way does not work with states for example; perhaps I need to add some compilation error for this case.
So you need to be sure that js got generated with ES6 features with classes and all that. Check generated index.js - it should contain classes, something like this: class server_rooms_StateHandlerRoom extends colyseus_server_Room
This week I've worked on :
Player in Seat - ServerSide
TurnBased RoomType: NextTurn, isTurn
MasterPlayerID for Client Side logic Room Type
Lock Mechanism
The lock mechanism was flawed by not release locks and to not compare clientside grid with serverside grid.
CLIENT
For example when the client pushes a block from position 25 to 15 it will need to send 15=0,25=2,35=1000 to the server and request a lock on them:
grid[15]=0; // free space
grid[25]=2; // block
grid[35]=1000; // playernr
SERVER
Server receives the lockrequest (15=0,25=2,35=1000)
It checks his own grid if the positions match the client request lock. If the grids are out of sync it will send an error back.
The client will then request a complete grid from the server as it is apparently behind.
If the server grid position matches the requested lock positions a lock will be attempted: (pseudo-code)
attemptposition=new Array();
isOK=true;
for each lockposition{
if(isOK && gridlock[lockposition] == 0){
gridlock[lockposition]=time;
attemptposition.push(lockposition)
}else{
isOK=false;
// there is a lock on one of the
for(each attemptpositon p) gridlock[p]=0;
}
}
When the server was able to lock all gridpositions it will send a success to the client
CLIENT
The client will do a grid request if the return state was an error.
The client will send the changed data to the server when it was success, otherwise it will not do the move as there was/is a lock.
SERVER
When server receives the griddata it will set the new grid values and afterwards set the lockpositions to 0-time.
After each request the server checks the gridlock table if the currenttime - locktime > 2 seconds .. when it finds one it will reset the lock.
CLIENT
Sends unlock to server.
A room with four player-bots ran for over 4 hours and still they were in sync.
Next I will need to figure out how to do classes with overloading / inheritence in TypeScript.
I want all the room types to share code that are common in all rooms.
For instance I need PlayerInSeat, PingTime, getPlayersInRoom etc.. code in all typescript rooms.
@usamasermad yes, you should ensure the Client connection is open before performing a ReJoin. If you're going to instantiate a new Client, make sure it has the same client.id as the one who initiated the first connection to the room (https://github.com/colyseus/colyseus-unity3d/blob/master/Assets/Plugins/Colyseus/Client.cs#L66)
Awesome @halome, it's looking good! Another option would be MatterJS: https://github.com/liabru/matter-js
Good luck with your project! Don't hesitate if you need any help with Colyseus here!
Hey @rscata, I've just released a new version (colyseus@0.8.13, see release) which adds the isNew parameter on requestJoin. With this version you'd be able to achieve the same result by having this implementation:
// ...
maxClients = 4;
requestJoin (options, isNew) {
return (options.create && isNew) || this.clients.length > 0;
}
// ...
@endel said in colyseus.js: server error: registeredHandler.klass is not a constructor:
Or by exporting the room usin
I'll try it the week end and come back to you later.
Thx for the help so far.
Hi @endel thanks for you quick reply, as you said... yeah.. too many issues already LOL
I'll go for the database option to persist the data between room changes, I'm working on it now, the idea is to save the player progress > leave the room > join the new room > re-authenticate the user with the data in the session and reload the progress.
I though it will be too expensive in terms of server response time, but keep a room or persist too much information in the presence could end up been even more expensive than just hit the DB to get the data.
Best,
Hey @merhawie,
Are you calling client.join() after the onOpen signal, as described here? https://github.com/gamestdio/colyseus.js#react-native-compatibility
@umen we have 3 servers now (each droplet of DigitanOcean 1 vCPUs 1GB / 25GB Disk), each server can keep about 500-600 users, but it's depends on logic of your server.
@endel I was looking at this in a tired state, but im pretty sure i had fully updated client and server. Ill double check what i was seeing and if i still have an error I'll open an issue on the github. Thanks for the response.
@Carlos-Montesino, i've tried your endpoint (wss://carmenproject.herokuapp.com) but it is not working properly.
the "please wait" text is not destroyed. it seems that it is cannot join any room.
@endel So, I got this working by calling gameServer.matchMaker.create("game", {}); after registering (I only do this on the second process).
It seems that the you are only subscribing to presence when the room is created. There is no knowledge that a registered handler is registered within presence. So, I have manually created the room on startup.
This probably is not the best way, but it works for now while you can think about how we would want to solve for making the other game servers aware that a room is registered but not yet created.
A colyseus + DB with authentication would be the ideal example IMO
something like the existing tic tac toe example with a simple user creation (DB) and login (authentication) would be enough
and it would be all someone needs to make a complete multiplayer game experience
@lezanardi
function setEnumerable(object) {
let private = {};
for (let key in object) {
Object.defineProperty(private, key, {
value: object[key],
enumerable: false,
writable: true
});
}
return private;
}
Will return the passed object with all the items non-enumerable.
I have no idea if we do not have access to "getAvailableRooms". If we did then you could simply have the client make that call every few seconds or minutes to get a fresh list.
