Best posts made by endel

Hi @veggis,

You may store the room reference on those specific entities by using @nosync.

Example:

import { Room, Client, nosync } from "colyseus";

export class Player {
  x: number;
  y: number;

  @nosync client: Client;
  @nosync room: Room;
  
  constructor (client: Client, room: Room) {
    this.client = client;
    this.room = room;
  }

  sendSomething (data: any) {
    this.room.send(this.client, data);
  }
}

This way, the client and room properties won't be synched to the client-side.

Hope this helps. Cheers!

Hello there!

This is the first game I'm publishing a game on my own in the stores. I'm very excited! Hope you like it!

• Type Type Multiplayer (iOS)
• Type Type Multiplayer (Android)

I highly recommend using react-native for mobile apps. I've managed to develop this in 16 days using it + Colyseus.

Game description:

Compete in real-time with other people around the world, and type as fast as you can!

1. Type the phrases as fast as you can!
2. Hundreds of inspirational & fun phrases to type in.
3. Daily, weekly and monthly high scores available.

Currently, there are only phrases in the English language. New languages coming soon!

wow, that's insane @doorbash 👏👏👏
thanks a lot for sharing!

Hey there,

The version 0.8.0 of the server and all clients have been released!

From now on, the minor version number of the server and clients should match for compatibility. Once the server has all the planned features to be considered 1.0.0, the major version should match for compatibility instead.

Changes on 0.8.0

• Introduced authentication support. (See docs, #49, #110)
  • Introduced new verifyClient(client, options) step during user connection
• Support for graceful shutting down clients and rooms (#107, #108)
• The "bad checksum" error should be gone forever!
• Using notepack.io instead of msgpack-lite, which is faster and supports toJSON on serialization level. (see discussion)

Releases:

• colyseus@0.8.0
• colyseus.js@0.8.0
• colyseus-unity3d@0.8.0

Special thanks to @seiyria and @oyed on this release, you guys rock <3

Hi @Burjee-Bataa,

If you're using Server (single-process) you can take a look on how it's being done here: https://github.com/derwish-pro/colyseus-monitor?files=1

For ClusterServer it's more complicated. Each process have it's own instance of the MatchMaker class. The master node access a limited amount of data (via memshared, search for "memshared" on this file, you'll see what's available) just to be able to forward connections to the right process.

One suggestion when using ClusterServer is to keep track of your spawned rooms through the public events (https://github.com/gamestdio/colyseus/wiki/Room-handlers#listening-to-room-events-outside-the-room-scope), and consume the data as you need.

Cheers!

@Burjee-Bataa this should do:

var room = client.join("room_name");
// ...
room.leave();

Hey @Burjee-Bataa, are you using the latest version of the server? (0.8.9)

This error started to occur after upgrading the WebSocket module (ws@3.3.3), more info: https://github.com/websockets/ws/issues/1256

There are already couple of "error" events registered to avoid this problem on the server.

@rscata I see. Thanks for the explanation. I've tested the code below and it works as you described.

Server-side

maxClients = 4;

onInit (options) {
  // identify when a new room is being requested
  this.create = options.create || false;
}

requestJoin (options) {
  if (options.create) {
    // creating a new room
    let allowed = (options.create == this.create);

    // this room is not being "created" anymore.
    this.create = false;

    return allowed;

  } else {
    // joining an existing room
    return this.clients.length > 0;
  }
}

Client-side

// creating a new room
let room = client.join("poker", { create: true })
room.onJoin.add(() => { /* created! */ })

// joining an existing room
let room = client.join("poker")
room.onJoin.add(() => { /* joined! */ })
room.onError.add(() => { /* no rooms available? */ })

I feel it should be easier to achieve this, though.

For next versions of Colyseus, I think it's important to know when a room is being created or is an existing one during onInit / requestJoin (like we're doing ourselves on this.create)

Let me know if you have any question. Cheers!

Hi @talothman, I've just tried it out and it seems to be working fine.

Are you running the "demo server" locally? https://github.com/gamestdio/colyseus-unity3d#running-the-demo-server

If you still have an error after having the demo server running, could you provide the stack trace?

Cheers

Looking through the documentation, it would seem that the general method is taking in commands from the clients and having the server updated across the network.

That's right! Usually, the clients send commands and the server calculates what's necessary for movement and all.

What if instead of commands, I pass in positional data from the client and have the server update that.

Nothing stops you from doing this. It's not particularly recommended since the clients will be dictating the final data. In an authoritative server, the server should tell the rules to avoid hacking.

Is Colyseus a good platform for the example mentioned?

Probably. I haven't seen a VR application using Colyseus yet, but it should be totally feasible. Maybe Photon could be a bit easier since its client for Unity is way more mature than Colyseus' is at the moment.

Cheers!

Hi @rscata,

As I mentioned in this other thread, the chat example is not a good example of how to implement a chat on Colyseus.

You'd be better off keeping the messages outside the room's state, and broadcasting them using this.broadcast(data) instead. This way is totally up to you how to sync the ephemeral messages.

Hope this helps!

Hi @DillonHemphill,

Sorry, for some reason when you install colyseus.js it's grabbing the latest alpha version, which is still under development.

The latest working versions are:

• colyseus.js@0.8.4 (client)
• colyseus@0.8.15 (server)

Cheers

I've just fixed the latest tags from both client and server to be the right ones. Sorry for the inconvenience! :sweat_smile:

Hi @funkmeisterb,

You can use the send(client, data) method: http://colyseus.io/docs/api-room/#send-client-data

The message will arrive in the onData signal in the client-side.

(This signal is going to be renamed to onMessage on version 0.9.x, I'll write and share a guide on how to migrate once its ready!)

Hi @Carlos-Montesino,

Sorry, the c3addon zip file I've uploaded was corrupted. I've just fixed it here: https://www.construct.net/br/make-games/addons/111/colyseus-multiplayer

Cheers!

@rscata alright! One thing that is not intuitive in this version is that you can only see the error messages and stack traces if you turn on DEBUG=colyseus:errors

DEBUG=colyseus:errors npm start

Hi @takaaptech,

I recommend using MongoDB, since you wouldn't bother about creating a schema for your tables.

You can either use the barebones mongodb driver, or use a high-level abstraction for it, such as mongoose. Both are quite simple to set up and use.

Cheers!

Hey @takaaptech, Node has native support for Promises, you don't need to get any additional package/plugins in order to work with them. Cheers!

Hi @Kinrany, thanks for checking out the project.

Is Colyseus that?

AFAIK these platforms you mentioned will provide servers and resources to host your game. When using Colyseus it will be up to you where to host the server and scale it (if necessary). 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.

it also seems to include extra features

The major feature of the framework is having the entire state of a game session being synchronized automatically from the server to all connected clients. This works great if your game state is not too big. Otherwise it's recommended to broadcast/dispatch events instead of using the state.

Couldn't matchmaking be built on top of state synchronization, as a separate library?

In theory, yes. Currently, we haven't seen a use case for this. Most games need to have multiple sessions, and matchmaking comes along with it.

Does it include client-side prediction?

Not at the moment. I believe client-side prediction is not easily pluggable in a way that the framework abstract everything for you. It depends on the type of game you're making. Most HTML5 games out there don't use client-prediction at all. I'd love to have this if possible, though.

What are the assumptions this framework relies on

The assumptions are basically: your game can have multiple game sessions going on at the same time; You'll need to write all game logic on server-side by yourself; You'll need to update the client's visual state as events arrive from the server.

what are the limitations?

The limitations really depend on the kind of game you'd like to build and the number of concurrent clients you'll have. The framework is still being tested and evolved to support as many scenarios as possible.

Cheers!

That's pretty cool @GuillaumeLe, thanks for sharing.

The purpose of your tool looks similar to the monitoring panel I've released yesterday! (https://github.com/gamestdio/colyseus-monitor)

Maybe we can combine the features somehow. Cheers!