Navigation

  • Recent
  • Tags
  • Users
  • Search
  • Login
Colyseus
  • Login
  • Search
  • Recent
  • Tags
  • Users

Documentation GitHub

We're migrating to GitHub Discussions. This forum does not accept new registrations since April 6, 2023.
  1. Home
  2. TeeTeeHaa
  3. Best
  • Profile
  • More
    • Continue chat with TeeTeeHaa
    • Flag Profile
    • Following
    • Followers
    • Topics
    • Posts
    • Best
    • Groups

Best posts made by TeeTeeHaa

RE: Async authoritative turn-based multiplayer in scope for Colyseus? (sovled)

I really like Colyseus and use it for my games with synchronous gameplay. For the game you described, with asynchronous gameplay, I personally would not use Colyseus.

Small definition of terms to avoid misunderstandings:
"synchronous gameplay" means players who are online and playing see each other and can interact with each other instantly.
"asynchronous gameplay" means players go online and play independently from each other, comparable with physical board games with a turn order for players.

If I would make a game which has asychronous gameplay and which has a game client (frontend) and game server (backend) being implemented in JavaScript or TypeScript and the game server is running on node.js...

...I would make the game server a simple HTTP server receiving requests over HTTP POST including "stringified" JSON objects and again sending back "stringified" JSON objects as HTTP responses. As hillarious as it might sound I would start with the "hello world" example on the website of node.js (see here) and start building the game server from there (actually I already did exactly that myself). The game client would simply do HTTP POST requests to the server, with all data required for the game, for example authentication or gameplay inputs, in the POST-part of the request, nicely wrapped as JSON object. The game server would process those requests and send the game state back, again as JSON object. Especially at the beginning of a JavaScript/TypeScript project using JSON is great because it is so simple. Later, if the game gets bigger, either because of growing amount of data or growing amount of players, the JSON could be swapped against something else, for example BSON or MsgPack.

In this scenario any "event" is initiated by the game client and the game server only reacts to those. If this scenario must be extended because the game server wants to initiate an event, for example because one player wants to send a chat message to the another player who might currently be registered as "online", the simplest way would be to use long polling. A friend of mine currently makes an asynchronous game just like that and it is working really good, probably because of the simplicity of the used network technology.

Maybe an asynchronous game can even be made with Colyseus, but from what I know about Colyseus it is not a good fit.

posted in Questions & Help • 2 Jun 2021, 12:06
preventing client from creating rooms on the server

If your server is fully responsible for the creation and deletion of rooms and the matchmaking of players into them and...
if your server will give the client a room reservation in some way and...
if your client will only connect to the server with a room reservation using client.consumeSeatReservation and...
if you want to prevent any client from ever creating a room on the server and...
if you do not mind to use a dirty workaround...

...you can override the private (D'OH) property exposedMethods of the Server class:

const gameServer = new Server();
const tempServer = gameServer as any; // force access to private property by casting to any
tempServer.exposedMethods = []; // override property with empty array to not expose those methods anymore
gameServer.listen(port);

Yes, it is dirty, it might break in the future, it might not work for you, but it works perfectly for me and it made me giggle maniacally.

posted in Questions & Help • 2 Jun 2021, 21:37
Documentation improvement suggestions

https://docs.colyseus.io/server/client/#sendtype-message

send(type, message)

I suggest not to call this "type" because "type" has a meaning in JavaScript/TypeScript (pun intended, proving my point). Maybe call it "messageId", similar to "roomId" or "clientId".

//
// sending message with string type
//
client.send("powerup", { type: "ammo" });

//
// sending message with number type
//
client.send(1, { type: "ammo"});

Regarding { type: "ammo" } I suggest not to call this "type" because of the very same reason and because it currently can be mistaked for the "type" mentioned above. Maybe call it "poweruptype" or "category" or any other synonym for "type".

class MyMessage extends Schema {
  @type("string") message: string;
}

const data = new MyMessage();
data.message = "Hello world!";

client.send(data);

Why does client.send have no "type" (in the sense of "messageId") as the first parameter?

https://docs.colyseus.io/client/room/#onmessage
C# example

class PowerUpMessage {
  string type;
}

room.OnMessage<PowerUpMessage>("powerup", (message) => {
  Debug.Log ("message received from server");
  Debug.Log(message);
});

/**
 * Handling schema-encoded messages:
 */
room.OnMessage("powerup", (message) => {
  if (message is MyMessage)
  {
    Debug.Log ("MyMessage type has been received");
    Debug.Log(message);
  }
  else if (message is AnotherMessage) {
    // ...
  }
});

In both room.OnMessage functions there actually is a "type" (in the sense of "messageId") as first parameter.

In general I am missing TypeScript examples in the client documentation. In the server documentation there are plenty of those.

This being said the whole documentation is quite good in my opinion. Nevertheless there are some details which could be clearer, for example those mentioned here.

posted in General Discussion • 13 Feb 2021, 22:44

© 2023 Endel Dreyer