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.
