@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
I'd love to see the Defold client evolving to eventually support all major LUA platforms, such as the ones you suggested, and löve2d.
The problem currently is the platform-specifics of WebSocket implementations, basically. Defold has its own WebSocket client that works for them, CoronaSDK also has one made by the community - which AFAIK it doesn't work with binary data.
@Apollo144 do you know if Gideros have a WebSocket client?
Cheers
Thanks for the detailed answer!
AFAIK these platforms you mentioned will provide servers and resources to host your game. As Colyseus is just a networking framework, it also doesn't provide any kind of game logic out of the box. You'd need to implement everything by yourself.
Right, both platforms are also social networks, and I don't need that. (Though BYOND doesn't host the servers.) A networking framework is exactly what I'm looking for.
This works great if your game state is not too big.
How big is too big?
I've seen the splitting and filtering views feature. It seems like a must-have for a networking framework, not only for performance, but also for cheating prevention purposes.
Currently, we haven't seen a use case for this. Most games need to have multiple sessions, and matchmaking comes along with it.
My (hypothetical) use case is a ss13-like: every server uses their own fork of the game code with minor tweaks, and the servers can have up to a hundred players and are barely ever full.
Not at the moment. I believe client-side prediction is not easily pluggable in a way that the framework abstract everything for you.
Wait, do you run the game code on the client at all?
Client-side prediction can depend on the game, but all games could benefit from changing the local state immediately. And many games aren't performance-bound on the client by the size of the local game state and can handle recalculating several game states every time the server sends something unexpected. Right?
Hi @kchecker,
With the recent release of the Defold lua client, it should be pretty straightforward to support Corona SDK too. (we used to have a client for Corona SDK in an early version)
The major concern is reusability of the core "classes". Every LUA-based platform uses its own plugin/module system with makes it harder to reuse code.
I was thinking of two approaches:
Having a single repository for all LUA-based clients (Defold, CoronaSDK, maybe love2d?), and having a script that creates a ZIP file containing the necessary files to run on each of these platforms.
Having a separate repository for each LUA client and use git submodules for shared libraries (such as MessagePack and FossilDelta). Unfortunately, the "download zip" feature from GitHub does not include git submodules in the final archive.
Cheers!
Hi @Burjee-Bataa, I'm wondering what's your use case? Why would you need to create empty rooms beforehand?
Creating and selecting the right room which clients should connect to is responsibility of the framework. The room instance will be created automatically as soon as the client ask to join in it. You may choose to not dispose them automatically if you'd like to (through autoDispose property).
@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.
