pushing befor major changes
This commit is contained in:
@@ -0,0 +1,83 @@
|
||||
# Chatting with GPT:
|
||||
|
||||
I think that I will modify some of how I am doing things. We will have the game do things differently. We will have a main loop that will process events and then we will use delta time and a `game speed` variable to control things.
|
||||
|
||||
Here is my newly defined API:
|
||||
|
||||
|
||||
# API
|
||||
|
||||
|
||||
Transport: WebSocket
|
||||
Encoding: JSON
|
||||
Direction: Bidirectional
|
||||
|
||||
Every message has:
|
||||
|
||||
```
|
||||
{
|
||||
"type": "...",
|
||||
"domain": "...",
|
||||
"request_id": integer
|
||||
"payload": {}
|
||||
}
|
||||
```
|
||||
|
||||
## Message types:
|
||||
|
||||
|
||||
### `hello`
|
||||
|
||||
- Direction: Client --> Server
|
||||
- Purpose: initiates the connection and has authentication
|
||||
- Behavior:
|
||||
- Must be responded to immediately
|
||||
- Response must be an `update` type with a full update (domain `all`)
|
||||
|
||||
### `query`
|
||||
|
||||
- Direction: Client --> Server
|
||||
- Purpose: request read-only data
|
||||
- Behavior:
|
||||
- Must be responded to immediately
|
||||
- Does not mutate server state
|
||||
- Response must be an `update` type with the requested domain
|
||||
|
||||
### `command`
|
||||
|
||||
- Direction: Client --> Server
|
||||
- Purpose: Request a state change
|
||||
- Behavior:
|
||||
- Server validates the command immediately
|
||||
- If the command is valid the server applies the command and acknowledges with an `event` with the resulted action.
|
||||
- If invalid the server responds with an `error` and includes the command and an error message.
|
||||
|
||||
### `update`
|
||||
|
||||
- Direction: Server --> Client
|
||||
- Purpose: Deliver the game state to the client
|
||||
- Behavior:
|
||||
- For a full state update (ie player login) the `all` domain is used. Otherwise it is a subdomain.
|
||||
- Used as a response to `hello`, `query`.
|
||||
- Full updates are sent periodically for client synchnorization.
|
||||
|
||||
### `event`
|
||||
|
||||
- Direction: Server --> Client
|
||||
- Purpose: Notify the client of events
|
||||
- Behavior:
|
||||
- Represents something that *happened*
|
||||
- Not a full state snapshot
|
||||
- Can not be requested by the client
|
||||
|
||||
### `error`
|
||||
|
||||
- Direction: Server --> Client
|
||||
- Purpose: Report a failure to process a `query` or `command`
|
||||
- Behavior:
|
||||
- Does not mutate state
|
||||
- Describe why the request failed.
|
||||
|
||||
## Notes
|
||||
|
||||
**The server is authoritative for all game state. Clients may not infer or simulate authoritative outcomes beyond visual interpolation.**
|
||||
Reference in New Issue
Block a user