That solved my problem.
Thanks @endel !
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)?
I recently started implementing Colyseus for my game, which is real time and thus
is potentially a good candidate for lag compensation.
A quick look through the Room class shows that there is a method Room#useTimeline(maxSnapshots)
and that Room#setState(state) takes a snapshot if there is a timeline object.
To use the timeline for lag compensation, I am currently implementing this via Room#onMessage and/or
the simulation interval function. I just want to make sure that I'm not missing something - is there any
implementation or abstract function that I should be using/implementing instead?
Secondly, regarding Room creation: suppose I have a BattleRoom class that implements the core server logic.
Is there a way that I can pass parameters to this BattleRoom in order to instantiate it with different max player
settings, different map selection, or different objectives?
I could see creating subclasses such as FFARoom and TDMRoom to represent different objectives, but if I wanted
to have N different maps, M different objectives, and P different max player settings then I would end
up with NMP different subclasses of BattleRoom and that explodes really fast!
I appreciate your help.
Some additional information - I started this project by rolling my own server implementation and used the
strategy pattern to plug in different objectives such as FFA, and JSON configuration objects to set map
rotation and max players.
I'm sure there's better ways to go about it, I appreciate any ideas or feedback :)
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)
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.