Found sort of a solution - use RegisteredHandler's create event to subscribe to the room's event.
The changes can be found here.
I wanna make an important note here:
Creating an async main method in index.ts and awaiting gameServer.register was crucial.
Hi endel, thanks for your reply.
You're right but the delta time is computed for the tick of room.setSimulationInterval, not clock.setInterval if I understood that correctly.
e.g.
//clock.start() is called indirectly and ticking starts:
this.setSimulationInterval(deltaTime => {
[...] //let's say deltaTime is about 15
});
this.clock.setInterval(function() {
[...]
//the deltaTime of this closure should be about 2000
//but instead this.clock.deltaTime is about 15 since it's computed at the tick of setSimulationInterval
}, 2000);
So each setInterval should have its own deltaTime since it has its own refresh rate.
I found the options / parameters :)
In case anyone else makes the same mistake, you can pass options/parameters into a Room when you call
Server#register(name, handler[, options]) - see http://colyseus.io/docs/api-server/
I'm still wondering about the first part of my question regarding Timeline - is that part completely left up to me to implement (with the exception of snapshots being taken in Room#setState)?
Thank you,
Nick
I know this topic is 3 months old, but I have found a workaround so if anyone searches for this they will have an answer.
The reason your unit test is not working is that WebSocket is not globally installed when you run it in say Jest for example.
A quick work around would be to define it globally.
// npm install ws
const globalAny: any = global; // This way we don't get an error in TypeScript saying WebSocket is not a defined property on global
globalAny.WebSocket = require('ws');
Also, it appears as though the colyseus.js client makes use of the window.local storage object. A quick polyfill you could do would look something like this
globalAny.window = {
localStorage: {
getItem: () => {},
setItem: () => {}
},
};
(Replied on GitHub: https://github.com/gamestdio/colyseus.js/issues/42)
Hey @karneaud, when using :anything, starting with :, it will generate a wildcard regular expression, that's why both listeners are being triggered.
You have two alternatives on this situation, which are:
Listening to direct properties
room.listen('pullPosition/position', (change) => {
console.log('position attribute has changed', change.value);
});
room.listen('pullPosition/hold', (change) => {
console.log('hold attribute has changed', change.value);
});
Remember that if position is a vector, you'd need to listen to its deep variables such as x and y, by using listen('pullPosition/position/x') and listen('pullPosition/position/y'). You can also use the wildcard method for this, using the same example below.
Listening to every attribute, and check which one has changed in the change.path
room.listen('pullPosition/:attribute', (change) => {
console.log(change.path.attribute, 'has changed to', change.value);
});
@endel @shortid
There is also a case for using interpolation on the client-side, not just prediction.
In the case of the Source engine (e.g. Counter Strike), there are buffered patches on the client side.
Ex. Client receives state update N, it buffers the update and instead interpolates between N-1 and N (this mitigates packet loss issues from UDP - the engine has settings to allow buffering of multiple updates in more unstable network conditions)
https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking
Edit: Then client side prediction is layered on top of this to make user-controlled objects feel more responsive.
Edit2: Even though Colyseus uses TCP on the client side, it still could be beneficial to use interpolation on the client side
(with only one buffered update, as multiple buffered updates won't really accomplish anything on TCP) as otherwise the enemies would get stuck in one place on the screen for waiting for the next update. There's also a case for using dead reckoning / extrapolation, but it has issues as well.
Thanks endel for the response.
The AI agent is built by multiple teams and the goal of this exercise would be to make the different agents compete against each other. So enforcing a language restriction on different teams is not an option. Further the standard implementations of the AI/ML libraries are more easily found in python than in Javascript. For the same reasons I am trying to separate the clients and the game server implementation.
If anyone has this issue and you are trying to use multiple join / left rooms like I was doing, make sure to always be joined in one room.
In my case I was leaving one room before join the next one, so I moved the oldroom.leave() action inside the newroom.onJoin() and now everything works fine.
Note, this was happening randomly at the beginning until I overloaded the room onInit with data, then I got the issue all the time because the second room was delayed on load.
Best,
[SOLVED]
Thanks @endel but as i am making card game i need to have options for client to choose whether to create a room ( private table ) or join the room ( if there is no room available then auto create room with)
Hi @holyxiaoxin, it looks like this.broadcast() would be better on this case. Then the message is broadcasted instantly. You can retrieve the message using the room.onMessage signal from the client-side.
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,
Thanks for answers and recommendations. My aim was to avoid crashs due to the bugs I haven't discovered yet, or any undefined action client made that could make the whole server(all the other rooms) crash.
As an answer to @endel, errors that I have come across so far was thrown from timeout callback functions so putting try catch to onJoin might not help :) .
