siggame / cerveau Goto Github PK

Here is the error it produces (personal information expunged)

...\Cadre-MegaMinerAI-Dev\Cerveau\gameplay\lobby.js:288
        client.gameSession.clients.removeElement(client);
                          ^

TypeError: Cannot read property 'clients' of undefined
    at Object.Class.clientDisconnected (...\Cadre-MegaMinerAI-Dev\Cerveau\gameplay\lobby.js:288:27)
    at Socket.socketListenerOnClose (...\Cadre-MegaMinerAI-Dev\Cerveau\gameplay\client.js:60:25)
    at emitOne (events.js:77:13)
    at Socket.emit (events.js:169:7)
    at TCP._onclose (net.js:469:12)

1. Run Cerveau outside of a git repo
2. You'll get the following printed to the screen:

fatal: Not a git repository (or any of the parent directories): .git

The next line will be correct:

[18:37:41.856]  Lobby @ 12164  Updater Warning: Error trying to use Git, is it installed on your system?

Not a huge issue, but should be investigated what is printing that, and remove/fix it.

Apparently on Mac OS X gamelog files are not generated. Logs are using the --log arg, but even though no errors claim to happen no files are dumped in output/gamelogs according to @takaaptech in siggame/Joueur.lua#2. Basically run two lua clients against each other playing checkers. We expect a gamelog to be generated. Instead none get output.

As I don't have access to this OS, could someone with an Apple machine check this out? takaaptech theorized that maybe the game session thread process was not properly sending data back to the main thread.

I'm more than willing to sit down with any devs to sort this out.

Currently the gamelog api is as follows:

host/gamelog/gameName/gameSession/[epoch]

While, that's cool, because theoretically someone could poke through gamelogs via session, that's not realistic. All the other siggame apps using this endpoint will have the identifier they need to grab a gamelog.

So instead move the gamelog api to:

host/gamelog/filename

where filename is the name of the file (without the .json.gz) in the output/gamelogs directory. Hell we might be able to just expose that folder and set the HTTP Response header's Content-Encoding: gzip so we just dump those bytes on them. That would be ideal.

Basically the current way is over-complicated for no reason.

For easier deployment via things like, jenkins, arena, etc, it will be far easier to inject environmental variables than writing a json file.

So migrate that to the following superb package: https://www.npmjs.com/package/dotenv

Collise is already doing so, so this is more complacent with their design paradigms.

The function used to handle 50-move rule using internal check for actual threefold rule which forces both the simplified and non simplified threefold rule to be followed else trigger a draw for full threefold rule disguised as a 50-move draw.

It is untested beyond Node.js 4 LTS, 6 is supposed to be the next LTS, so we should start migrating. Plus there's all those cool ES6 features!

Currently the arg parm visualizer-url is an option.

However we can expect the visualizer will exist at vis.megaminerai.com now.

So have that be the default value, and allow them to override it should they want to.

Currently the server will claim 0-0 and 0-0-0 (using zeroes) are illegal moves for designating castling.
both zeroes '0' and the capital letter 'O' should be acceptable ways to designate castling SAN notation.

The implementation could be as simple as replacing '0-0' and '0-0-0' (zeroes) with 'O-O' and 'O-O-O' on the server side before continuing with validation logic.

I expect AI implementers to google how to implement SAN notation, and the top links for 'chess SAN' either only mention using zeroes, or only mention the alternative of using capital letter 'O' as a sidenote:

https://en.wikipedia.org/wiki/Algebraic_notation_(chess)#Castling
Castling is indicated by the special notations 0-0 (for kingside castling) and 0-0-0 (queenside castling).

While the FIDE Handbook, appendix C.13[5] uses the digit zero (0-0 and 0-0-0), PGN requires the uppercase letter O (O-O and O-O-O).

   +-----------------+
 8 | r n b q k . . r |
 7 | p p p p b p p p |
 6 | . . . . p n . . |
 5 | . . . . . . . . |
 4 | . . . . . . . . |
 3 | . . . P . N P B |
 2 | P P P . P P . P |
 1 | R N B Q K . . R |
   +-----------------+
     a b c d e f g h
Game is over. I lost :( because: Made an invalid move ("0-0").

Players should be able to send FEN string requesting a game start in a specific state.

./run Chess --gameSettings "fen=some_fen_list_of_moves_string"

Chess.js natively supports FEN strings, but our framework would need to parse them. It should be easy, just read each move and pipe them as if we are pre-playing a ton of moves.

Hi,
So far, i can setup two AI in a game. And i wonder if Carveau could support Human and Human or Human and AI in game? If yes, how can we implement that? Thank so much!

I broke the game logic porting to TypeScript. Should fix that...

For instance on a 32x16 map, the tile at x,y=0,1 has neighbors:
0,0 tileNorth
1,1 tileEast
0,2 tileSouth
31,0 <--- tileWest

Much of the base framework has matured to the point it should be unit tested.

Here's a vague list of things that would be possible to test:

• Networking I/O
• RESTful API
• Delta parsing/creation
• Matured games like Chess

I think it would be unwise to unit test in development games, as they are evolving so fast we don't necessarily know what to test. However, a known game like Chess could be tested by sending pre-determined moves and ensuring that the game state changes in expected ways.

Unit testing the game server would be tricky as it's only half of the problem. There's also a client you have to connect to do much of anything, and if that is broke the unit tests could break, claiming the game server is wrong.

So, someone should investigate how easy testing is to add, and if it even works reliably.

For example, here is the error generated when sending the string "hi\x04" to the server:

undefined:1
hi
^

SyntaxError: Unexpected token h
    at Object.parse (native)
    at Object.Class._onSocketData (Cerveau\gameplay\tcpClient.js:30:51)
    at Socket.onSocketData (Cerveau\gameplay\client.js:34:18)
    at emitOne (events.js:77:13)
    at Socket.emit (events.js:169:7)
    at readableAddChunk (_stream_readable.js:146:16)
    at Socket.Readable.push (_stream_readable.js:110:10)
    at TCP.onread (net.js:523:20)

When Cerveau gets a SIGINT (Ctrl + C) it should gracefully shut down. That means it should:

1. Disconnect any Lobbied clients with a fatal event, and a message explaining the server is shutting down.
2. Wait for all game sessions to exit, and log them as normal
3. If any more connections come in while waiting to shut down give them the same fatal event as in 1, then disconnect them.

Once all game sessions have exited gracefully Cerveau can shut down too, and no one is forced out of a game.

If another SIGINT is received during this shutdown it should just force shutdown the whole thing.

Note: Node.js exposes an easy hook for the SIGINT event: https://nodejs.org/api/readline.html#readline_event_sigint

https://github.com/mtth/avsc/wiki/Benchmarks

This library claims to be more performant on Node.js for serializing a json structure and converting it to a buffer, something we do every often. So, would this be a speed improvement?

The view and download buttons for games that have been played do not work as expected.
The download has HOSTNAME instead of the actual hostname.
The view has :3080 written twice in the url sent to the visualizer for the log location.

Currently you can GET gamelogs via an HTTP GET Request to /gamelog/:id, and get some Json. cool, makes sense.

You should be able to delete those gamelogs too. This is useful for the arena to clean up the gamelogs directory after it ships them off to the magical cloud land.

So, if a HTTP DELETE Request is made at /gamelog/:id, delete it! Respond with 200 OK if, well, ok.

If a client does something cheesy, like send a string that is a reserved delta merge keyword; disconnect them. It could possibly lead to erroneous gamelogs and the only real reason those strings would be sent is to screw with the game server.

Currently the host name needs to be passed via --host

However that's silly. Connecting clients know the hostname, they had to use it to connect.

So instead send some string replace like %%HOSTNAME%% and enhance all clients to replace that with their hostname. With that done this feature can be removed, and it simplies sending gamelog urls at the end of games.

Recommended to me today by a peer: https://www.npmjs.com/package/tslib

Basically, any dictionary/map made in a game template will not work. The only exception is the gameObjects dict as it is special, hence why it's not been seen as a bug yet.

They work server side, but deltas are not registered, and thus not sent to clients, so state gets out of sync.

On the web interface index, it would be helpful for debugging and competitors seeking games to see the lobbies/sessions that are currently running.

As seen below, some of the later "game settings" are hidden underneath "Active Rooms in Lobby".

Currently, games must be connected to to spectate before the game starts. Now, we should allow spectators to join in progress games.

Hi!
First of all, It is really awesome framework! Thanks so much for bring it to us!
I am trying to setup game server. When i start it, it runs fine
Lobby @ 13799 Found game 'Checkers'.
Lobby @ 13799 --- Webserver running on localhost:3080 ---
Lobby @ 13799 --- Lobby listening on localhost:3000 ---
But when open web server, we have bellow error, please help me, i just on the way to learn node js, thank so much!

TypeError: Cannot use 'in' operator to search for 'data' in null
at Object.compile (/Users/taka/github/Cerveau/node_modules/express-handlebars/node_modules/handlebars/dist/cjs/handlebars/compiler/compiler.js:467:19)
at HandlebarsEnvironment.hb.compile (/Users/taka/github/Cerveau/node_modules/express-handlebars/node_modules/handlebars/dist/cjs/handlebars.js:38:41)
at ExpressHandlebars._compileTemplate (/Users/taka/github/Cerveau/node_modules/express-handlebars/lib/express-handlebars.js:239:28)
at ExpressHandlebars. (/Users/taka/github/Cerveau/node_modules/express-handlebars/lib/express-handlebars.js:124:25)
TypeError: Cannot use 'in' operator to search for 'data' in null
at Object.compile (/Users/taka/github/Cerveau/node_modules/express-handlebars/node_modules/handlebars/dist/cjs/handlebars/compiler/compiler.js:467:19)
at HandlebarsEnvironment.hb.compile (/Users/taka/github/Cerveau/node_modules/express-handlebars/node_modules/handlebars/dist/cjs/handlebars.js:38:41)
at ExpressHandlebars._compileTemplate (/Users/taka/github/Cerveau/node_modules/express-handlebars/lib/express-handlebars.js:239:28)
at ExpressHandlebars. (/Users/taka/github/Cerveau/node_modules/express-handlebars/lib/express-handlebars.js:124:25)

sending an fen string to the game server does nothing. game starts with default state.

Allow players to forfeit if they know they have lost.

Let's say we have the following game object:

Thing:
  attributes:
    numbers: const int[]

then in the game code we create a Thing via a GameManager:

manager.create.thing({
  numbers: [1, 3, 3, 7],
});

We'd expect a new Thing, and it's numbers attribute set to [1, 3, 3, 7]. And that would be the case server side only.

Currently, the clients will not be sent these values, and will think the Thing has an empty array. Thus their states are out of sync.

A work around exists by doing this instead:

const thing = manager.create.thing();
thing.numbers.push(1, 3, 3, 7);

So obviously, something is broken in the game object factory and not registering deltas. Probably around the Delta Array stuff, and probably also around using any too much.