jdomantas / ab0f1638-c88f-457d-a5c9-94e8a3d86a24 Goto Github PK

• All types from planned game API are basically (), and functions do nothing.
• No catching up if behind server.
• No input or rendering

Input objects sent by the client:

{
    "frame": 123,
    "input": "random string"
}

Input objects sent by the server:

{
    "frame": 123,
    "new_players": [2],
    "removed_players": [0, 1],
    "inputs": {
         "2": "random string 1",
         "4": "random string 2"
     }
}

Initial world state sent by the server:

{
    "frame": 123,
    "world": "random string"
}

Server currently can panic in a few cases:

• wasm module does not properly export memory
• exports are missing or have incorrect types
• invoking wasm functions trap

For better user experience these should be converted to graceful shutdowns with nice error messages.

API implemented by current test game is rather primitive, and lacks the following important features:

• Actually getting keyboard/mouse input into the game (#14)
• Rendering (#13)
• Out of game UI - for example, for selecting in-game name before joining the game

Also, some nice stuff could be provided at engine level, instead of as libraries that fit within current engine API:

• Configuring key bindings
• UI
• ...

• Wait for clients if client didn't send input (so that they don't ever need to catch up).

Without unit tests, it is harder to make changes to the engine. They would also help people starting understand the codebase better. The tests would also be useful for the game implementation as well, but that is lower priority, as the game is not as well defined.

wasmi seems to perform very poorly - with just 5 players the sample game runs at ~50 fps. wasmer-runtime has a JIT and seems to perform much better.

Would also be a good opportunity to set up some sort of metrics tracking to make such issues easier to spot and debug.

Rendering could be done as simply as adding a wasm function for rendering, which would take world, local player id, and other rendering parameters (screen resolution and whatever), and could invoke a host function that would actually render textures on the screen.

Currently there's no way to get any input into the game.

Note that some unexpected stuff might need to included in player input. For example, screen resolution and aspect ratio are needed for game UI layout. These can be easily given to rendering, because it does not impact simulation determinism. However, interacting with UI elements would require knowing layout in player state update, so same parameters would need to also be given as part of player input. This could be resolved with adding an engine-level API for managing UI layout, but is probably out of scope for MVP.

A few possible ideas on the API:

Don't change any existing things, just add a function (KeyboardState, MouseState) -> Input and use that to construct input objects at client side.

Pros:

• Flexible - game engine can additionally provide goodies like configuring key bindings at client side.

Cons:

• Network messages might become arbitrarily large.
• Game developers need to validate inputs before using them, because a malicious client can construct inputs that have valid types, but with arbitrary values inside.

Completely remove input type: for updating player only give keyboard & mouse data (a. la KeyboardState and MouseState in Monogame).

Pros:

• Don't need to call any custom (de)serialization code for inputs, just sending raw keyboard state over network.
• Don't need to separately call custom code to parse input object from keyboard/mouse state.
• Network messages have predictable size.
• Game developers don't need to validate inputs before using them.

Cons:

• Difficult to customize - for example: input bindings cannot be done at engine level, because once raw inputs are passed into the update function, no local settings can be used for updating.

wasmi doesn't seem to allow accessing module's linear memory unless the module exports it.

This could be solved by adding the needed export before packaging wasm module into game package.

Now that there's a sample game package, we can implement all the machinery required to serve code/assets/other info to clients, and also run the game on the server.

Server and client communicate mostly by serialized values, which are opaque binary blobs. Given that message structure is very simple and strict, binary format seems to be a better fit.

Load game code/info/assets and run game in the browser.

Create a minimal self-contained wasm game that we could run on the client and the server.