colyseus / docs Goto Github PK

View Code? Open in Web Editor NEW

10.0 7.0 67.0 19.92 MB

Documentation for Colyseus

Home Page: https://docs.colyseus.io

HTML 100.00%

colyseus documentation

docs's Introduction

Colyseus Documentation

Documentation for Colyseus.

This project uses Markdown for documentation which is compiled with mkdocs.

Install and setup

pip install -r requirements.txt

Development

mkdocs serve

Docker

docker run --rm -it -p 8000:8000 -v ${PWD}:/docs lucidsightinc/mkdocs-material

docs's People

Stargazers

Watchers

Forkers

wenish austinkelleher amitport bastaware kylechallis lavren1974 oualidaj stanfrag matteo-peronnet alexanderson1993 macboy012 fiblan digimbyte hottredpen damian-pastorini kmadorin zielak minviable jcjveraa jinzt elyx0 mikaldev hishammubarak 8bitskull tunglt1810 parhamzare adelnorberg steditor jakapps liangxudongsun hacker-linner banool wangpengju hugosteixeira a1xon formatcvt cocosgames ngokevin wac925 staff0rd xu-pixel theprogrammerjerry charlies1103 leechanghaevan mathiaskandelborg lpsandaruwan sajibsrs longnt-mirabo aj-modz game-frame yacinekadri cakuki tamanidamani francislavoie mobyjames keshav2010 bcjordan tejaboy metiscoda flock-games f2l2pe fabryz marcobrunodev avatus bartduisters zulivan andrek25

docs's Issues

Room example fails to build with Typescript

The example here https://github.com/colyseus/docs/blob/master/docs/server/room.md#example-room doesn't build with Typescript. The error I get is

Argument of type '{ map: typeof Player; }' is not assignable to parameter of type 'DefinitionType'

which occurs on the line

@type({ map: Player})

I'm not sure if this is required but I can fix this by changing the Player class definition to extend Schema:

export class Player extends Schema {
  x: number = 0.11;
  y: number = 2.22;
}

Construct3: switching event sheets may interrupt "On change" conditions

Need to document this limitation

(Requested by @Alaadel)

Deprecate a field of Schema in javascript

In the doc only typescript format is given.
How about it in javascript?

`schema-codegen` input fileName with wildcard

follow the docs:

docs/docs/state/schema-callbacks.md

Lines 326 to 334 in aefbf8f

    
           ### Example: Unity / C# 
        
           Below is a real example to generate the C# schema files from the [demo Unity project](https://github.com/colyseus/colyseus-unity3d/blob/aa9a722a50b2958ce01785969cd8ecb8aee24fd0/Server/package.json#L12). 
        
           ``` bash 
        
           npx schema-codegen src/rooms/schema/* --csharp --output ../Assets/Scripts/States/" 
        
           generated: Player.cs 
        
           generated: State.cs 
        
           ```

the codegen/parser dose not support wildcard yet:

https://github.com/colyseus/schema/blob/4b7410dd8f700ffc671af91802cac346de77bdf4/src/codegen/parser.ts#L228-L272

Documentation for Command Pattern is lacking in justification

https://docs.colyseus.io/best-practices/command-pattern/

> Why?

Models (@colyseus/schema) should contain only data, without game logic.
Rooms should have as little code as possible, and forward actions to other structures

The 'Why' section does not sufficiently explain to me why I should care about this. I see no issue with my schema containing game logic, as you have not told me why that is a bad thing. I also haven't been convinced that rooms should have as little code as possible. Why? Is the code all sent to and from the clients in every patch update? That seems impossible, and easy to fix deeper in the code.

Given no real justification for why to bother with the command pattern, and no real examples showing how it improves code cleanliness, this recommendation just seems like an opinionated way to structure your code.

If these are just Colyseus best practices, they should be better justified to the people the documentation is asking to do extra work. If these are meant to be "Accepted and understood best practices for Typescript in General", please link to external documentation supporting and further explaining the concepts.

FWIW I believe that I want the command pattern, and that I should bother with it eventually, but I've read this doc five times now and am still fighting with myself over what benefit I'm getting from it. Trying to implement it from the start has just confused my Colyseus adoption. I recommend either expanding this doc to better explain the reasoning, and then give better examples. OR to remove this doc from 'best practices' and put it in a more specific 'code cleanliness / Command Pattern' section until it is complete enough to not confuse new users.

'connection' is deprecated.

Hi! It would be nice to do that:
Replace req.connection.remoteAddress with req.socket.remoteAddress

Circular Dependency issue in the Command Pattern Example

Hi There,

I've been reading up the documentation recently (https://docs.colyseus.io/best-practices/)
and came across the best-practices part where it is recommended to adopt the Command-Pattern.

In the example given in the docs for "OnJoinCommand.ts" file,

// OnJoinCommand.ts

import { Command } from "@colyseus/command";

import { MyRoom } from './MyRoom'; // this is missing in the example.

export class OnJoinCommand extends Command<MyRoom, {
    sessionId: string
}> {

  execute({ sessionId }) {
    this.state.players[sessionId] = new Player();
  }

}

and below is the code given
For MyRoom.ts file:


import { Room } from "colyseus";
import { Dispatcher } from "@colyseus/command";

import { OnJoinCommand } from "./OnJoinCommand";

class MyRoom extends Room<YourState> {
dispatcher = new Dispatcher(this);

onCreate() {
 this.setState(new YourState());
}

onJoin(client, options) {
 this.dispatcher.dispatch(new OnJoinCommand(), {
     sessionId: client.sessionId
 });
}

onDispose() {
 this.dispatcher.stop();
}
}

MyRoom imports OnJoinCommand , and vice-versa.

It seems the circular-dependency issue is introduced due to the decision of having generic type Room for class Command (Command)
I saw in previous versions of colyseus docs, instead of taking reference of a room, you could pass reference to the room state instead (see: https://0-13-x.docs.colyseus.io/best-practices/command-pattern/)

Which seems like a better way as it would avoid this sort of circular dependency issue when splitting commands into different module.

But I'm not sure why that approach has been changed (?) now. If you could help suggest some way to avoid this issue ?

Sets don't need at() function, do they?

https://github.com/colyseus/docs/blob/master/docs/colyseus/state/schema.md#setat

Create visual overview of the client-server communication flow

Suggested by @Eeveeboo on Discord:

The documentation should have a visual overview of the system. A visual flow showing the server, client, schema lifecycle.

So I'm seeing this "When using arrays, it's important to use the ArraySchema type. Do not use plain arrays."
Does this apply to all arrays in general? I'm using a temporary array in the middle of a function, should I be converting that over to an arrayschema?

Lines 1221 to 1227 in b718261

    
           class Inventory extends Schema { 
        
               @type({ map: Item }) items = new MapSchema<Item>(); 
        
           } 
        
           const inventory = new Inventory(); 
        
           inventory.set("left", new Weapon()); 
        
           inventory.set("right", new Shield());

Shouldn't it be :

inventory.items.set("left", new Weapon());
inventory.items.set("right", new Shield());

instead of:

inventory.set("left", new Weapon());
inventory.set("right", new Shield());

Clarify `playersByClientId` on onMessage

https://github.com/colyseus/docs/blob/master/docs/server/room.md#onmessage-client-data

	### Example: Unity / C#

	Below is a real example to generate the C# schema files from the [demo Unity project](https://github.com/colyseus/colyseus-unity3d/blob/aa9a722a50b2958ce01785969cd8ecb8aee24fd0/Server/package.json#L12).

	``` bash
	npx schema-codegen src/rooms/schema/* --csharp --output ../Assets/Scripts/States/"
	generated: Player.cs
	generated: State.cs
	```

	class Inventory extends Schema {
	@type({ map: Item }) items = new MapSchema<Item>();
	}

	const inventory = new Inventory();
	inventory.set("left", new Weapon());
	inventory.set("right", new Shield());