greenpix / lycan Goto Github PK

The management REST API does not produce valid json when there's an error which would make writing a UI on top of it rather annoying. I think we could return instead something like:

{
    "type": "error",
    "message": "ERROR: invalid id 0: Invalid length; expecting 32 or 36 chars, found 1"
}

Similarly if an API is always expected to return a response in case of success we could have something like:

{
    "type": "success",
    "message": "Monster spawned with id '234234'"
}

Right now, even if they are configurable, there is little control possible over how an Instance is executed once is it launched.

An idea would be to have a special debug mode that would extend greatly what a client could do. For example, this client could for example manually control the tick rate and "speed" (with a command like "execute like a 50ms tick had happened), see the calculation of hitboxes done by the server etc.

I think this would greatly improve automatic testing, with unit-tests like "put 2 entities next to each other, make one attack and verify the collision & damages work as expected".

Some functions currently return a Result<..,String>, and should have a proper Error type.

The current one behaves a bit like really dirty, manual promises, whereas they could most likely be improved a lot.

When a client disconnects from the game in the middle of a "tick", the server will print a lot of error messages.

It seems to come from the fact that when transmitting updates, send_message() will see the client disconnected and queue a disconnect commands that will be executed much later. As send_message() is called a lot, it will queue many disconnect commands. The first one will succeed, and next ones will print a (harmless) error message because the client is not found.

Hi.

I tried to build lycan yesterday using what I believe was the latest version of rustc (I use rustup update then rustup default nightly). The build failed because of one of its deps. I cannot recall which one and I am and I am not in the position to try again for now, but as soon as I have more detail to give, I will do.

In the meantime, I post this issue as a reminder and a disclaimer.

The README is missing a requirements section that would contains:

• the Rust version required.
• the external dependencies required not fetched by cargo (such as OpenSSL, are they any others?)

Part of the network is still TODO, basically all cases that don't happen with the official client (so a malicious client could make it crash easily)

Right now Lycan starts the server, and then the management API.

Maybe we could do the opposite, and have the management API owning one (or several, although this is not the objective and might be tricky) instances of a Game (and associated instances).

The good part is that we could easily have some /restart API calls, that would reinitialize the server, and it would also probably make testing a bit easier ...

Any thoughts?

Switch the code to use angles instead of just directions.

The API for player movement can then be limited to only include 8 directions.

Right now Lycan is always expecting proper authentication for clients, but at start-up inserts a few well-known values as valid playerId/token pairs.

This has a couple of limitations, such as not being able to connect twice with the same character without rebooting the server (which then makes it difficult to have a long-lived "toy" server)

I was thinking about adding a command-line parameter that would disable authentication checks, and accept the connection even when the token is incorrect.

An alternative could be to make clients aware of the management API (which would then need to be accessible from all clients, which may not be trivial), and make them add their own tokens before attempting to connect.

In either case, we may need to implement checks in Lycan to avoid 2 players connecting with the same UUID (although depending on how clients are implemented, the likelihood of generating randomly the same UUID twice is negligible).

Right now Lycan does a weird thing for entities persistence (quick&dirty): it fetches scripts and entities from a simulation of a REST API using a python web server, but when it needs to serialize them, it will write directly in the filesystem at the exact position where the web server will serve the files ...

Altogether it brings persistence, but I would prefer to simplify things and make a clear, full filesystem backend (with a command-line parameter). We would then add other backends as we see fit (gjanajo, sqlite etc.)

It will also touch a part of the code that is currently extremely ugly, which is probably a good thing ...

Right now the network protocol is very (too?) simple: the client connects, sends the playerId/token, and if the authentication succeeds is connected to the game (otherwise he is kicked).

Maybe a small handshake would make sense at the beginning, where the server would at least present some useful information such as:

• version
• is authentication enabled? (see #29)
• is it in debug mode? (see #28)
• maybe the tick rate?
• ... probably other information

The current double_iterator implementation will yield both (&mut a, &mut b) and (&mut b, &mut a). This is rather counter-intuitive and not good performance-wise.

It could also be generalized and potentially moved to its own crate.

Right now it is a completely dumb n^2 algorithm, which could be greatly improved.

Some variables (such as the "attacking" one tracking attack cooldown) still use "ticks" which should be changed to "seconds". Other variables may not be in their correct units either