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. SauceCodeFr
SauceCodeFr

SauceCodeFr

@SauceCodeFr

Chat Follow Unfollow
0
Reputation
6
Posts
1.2k
Profile views
0
Followers
0
Following
Joined 17 May 2020, 10:22 Last Online 4 Jun 2020, 09:55

  • Profile
  • More
    • Continue chat with SauceCodeFr
    • Flag Profile
    • Following
    • Followers
    • Topics
    • Posts
    • Best
    • Groups
SauceCodeFr Follow

Posts made by SauceCodeFr

RE: Manually changing the sessionId / persistent character

Why overriding sessionId by forcing yours ? Just add another variable send via the state or message, something like userId. Session should be volatile, but user id should be persistent.

posted in Questions & Help • 26 May 2020, 15:17
RE: Manually changing the sessionId / persistent character

This behaviour is normal, a session id means not an id attribued to your user, just an id attribued to his session. If you want to keep an id across browser restarts you must implement authentication !

And store data assigned to the user email address or something. You may also want to use https://docs.colyseus.io/server/authentication/ for retreiving user informations. But it need to store this in another database than your room state.

posted in Questions & Help • 24 May 2020, 10:27
RE: Manually changing the sessionId / persistent character

Hi !

If your room is set to autoDispose = false (https://docs.colyseus.io/server/room/#autodispose-boolean) the state is kept, so can keep your character data in. And then with a reconnection, the data can be retreived with the session id.

but the data will still be lost if the Room is closed and you cant change that... A room is a temporary instance of your game, thats why you should store your informations on a dedicated database :)

posted in Questions & Help • 23 May 2020, 08:10
RE: Store data in a Quadtree

Hi !

I have done HashMaps but not Quadtree, however I think this is possible as you can nest objects into custom structure, I did not tested but recursivity may not be a problem.

Something like (not tested, just a draft) :

import { Schema, type } from "@colyseus/schema";

class Node extends Schema {
    @type([Node])
    nodes = new ArraySchema<Node>();
    
    @type([Entity])
    entities = new ArraySchema<Entity>();
}

class MyState extends Schema {
    @type(Node)
    node: Node = new Node();
}

On each Node you may have 4 child Nodes, each nodes can have 0 to many Entity. It may be a good idea to write a NodeManager attached to the State for building and update the tree !

posted in Questions & Help • 23 May 2020, 08:05
RE: Adding / Removing Schema fields during runtime

Okay I am working on something !

The solution may be having a global hashmap of Component detached from Entity objects. It allows us to group the Component types in the State and send them as group. Not sure it will works but, at least i will try this :)

I will keep updated the work on this thread.

posted in Questions & Help • 18 May 2020, 13:20
Adding / Removing Schema fields during runtime

Hi,

I am working on a opensource ecs game engine and I wanted to replace the current custom network management with Colyseus !

But, ECS means that my game is composed by several Entity that can have 0 to many components. A Component is assigned to an Entity by putting him into a Entity.components object holding them by their names.

I am not very familiar with the Schema aspect, how can I bring this data structure into Colyseus ?

Idea 1 :

Define types during runtime with defineTypes, something like :

const entity = new Entity() // Entity extends empty Schema
entity.addComponent(new MyComponent()) // MyComponent extends Schema with data structure

// The second line will run this :
schema.defineTypes(entity , {
  MyComponent: MyComponent
});

But, well ... Schema defines types in object prototype (https://github.com/colyseus/schema/blob/master/src/annotations.ts#L283) not instance ... so it will not work as each Entity instance may have different Components.

Idea 2 :

Sending maps of Components for each Entity (preferred solution as I already have a Entity.components attributes.

class Entity extends Schema {
    @type({ map: Components})
    components = new MapSchema<Components>();
}

But again I think it will not work because the engine will store different Component data structures. Examples : PositionnableComponent with x, y, angle, HealthComponent with current, maximum, etc ...

posted in Questions & Help • 17 May 2020, 10:56

© 2023 Endel Dreyer