Development:Structure - Revision history

Librae: /* Game state */

2025-01-06T15:04:01Z

Game state

← Older revision		Revision as of 15:04, 6 January 2025
Line 15:		Line 15:
	==Game state==		==Game state==

	The game is structured to support trustless (except the server), simultaneous multiplayer. The game state is stored as a single '''universe''' structure (<code>rustorion::Universe</code>). Client receives a '''view''' which contains only the information the client is supposed to know. Client sends '''action'''s to the server that contain the information about what the client wants to do on the current turn. When all the players are ready (submitted their actions or it's a timeout), the server processes all the actions (they are designed to be executed independently of each other, so there are no race conditions), performs various updating on the '''universe''' and notifies clients that they can download new '''view'''s.		The game is structured to support trustless (except the server), simultaneous multiplayer. The game state is stored as a single '''universe''' structure (<code>rustorion::Universe</code>). Client receives a '''view''' which contains only the information the client is supposed to know. Views are not intended to be modified. Client sends '''action'''s to the server that contain the information about what the client wants to do on the current turn. When all the players are ready (submitted their actions or it's a timeout), the server processes all the actions (they are designed to be executed independently of each other, so there are no race conditions), performs various updating on the '''universe''' and notifies clients that they can download new '''view'''s.

	In the future, clients might be able to download previous views to browse them at will or use for gathering statistics.		In the future, clients might be able to download previous views to browse them at will or use for gathering statistics.

Librae: /* State Machines */ fix a link

2024-10-06T12:19:02Z

State Machines: fix a link

← Older revision		Revision as of 12:19, 6 October 2024
Line 48:		Line 48:
	# Wait for the other messages, like 'connected', and change your own state accordingly.		# Wait for the other messages, like 'connected', and change your own state accordingly.

	State machines are implemented using the [~~state_machine~~ https://gitlab.com/librae/state-machine] library. The library supports the Tokio and 'futures' crate primitives, the latter are also used by GTK4.		State machines are implemented using the [https://gitlab.com/librae/state-machine state_machine] library. The library supports the Tokio and 'futures' crate primitives, the latter are also used by GTK4.

Librae: /* State Machines */ fix a list

2024-10-06T12:18:37Z

State Machines: fix a list

← Older revision		Revision as of 12:18, 6 October 2024
Line 43:		Line 43:
	Interaction between parts of the game, like network client, server, GUI or CLI is based on state machines. A state machine in that context is an entity which, after being started, manages itself and interacts with others using messages. For example, if you want to use the 'client' machine:		Interaction between parts of the game, like network client, server, GUI or CLI is based on state machines. A state machine in that context is an entity which, after being started, manages itself and interacts with others using messages. For example, if you want to use the 'client' machine:

	1. Start the machine (this launches it in another 'thread', in case of the client, it's a Tokio green thread)		# Start the machine (this launches it in another 'thread', in case of the client, it's a Tokio green thread)
	2. Subscribe to its events (start listening on message channels connected to it)		# Subscribe to its events (start listening on message channels connected to it)
	3. Send the 'connect' message		# Send the 'connect' message
	4. Wait for the other messages, like 'connected', and change your own state accordingly.		# Wait for the other messages, like 'connected', and change your own state accordingly.

	State machines are implemented using the [state_machine https://gitlab.com/librae/state-machine] library. The library supports the Tokio and 'futures' crate primitives, the latter are also used by GTK4.		State machines are implemented using the [state_machine https://gitlab.com/librae/state-machine] library. The library supports the Tokio and 'futures' crate primitives, the latter are also used by GTK4.

Librae: /* State Machines */ new section

2024-10-06T12:18:15Z

State Machines: new section

← Older revision		Revision as of 12:18, 6 October 2024
Line 38:		Line 38:

	Clients authenticate themselves with client TLS certificates to the server. Currently BLAKE3 hashes of the client certs are used, this seems to work but is probably not the best idea.		Clients authenticate themselves with client TLS certificates to the server. Currently BLAKE3 hashes of the client certs are used, this seems to work but is probably not the best idea.

			== State Machines ==

			Interaction between parts of the game, like network client, server, GUI or CLI is based on state machines. A state machine in that context is an entity which, after being started, manages itself and interacts with others using messages. For example, if you want to use the 'client' machine:

			1. Start the machine (this launches it in another 'thread', in case of the client, it's a Tokio green thread)
			2. Subscribe to its events (start listening on message channels connected to it)
			3. Send the 'connect' message
			4. Wait for the other messages, like 'connected', and change your own state accordingly.

			State machines are implemented using the [state_machine https://gitlab.com/librae/state-machine] library. The library supports the Tokio and 'futures' crate primitives, the latter are also used by GTK4.

Librae: refix the link

2024-10-05T10:28:48Z

refix the link

← Older revision		Revision as of 10:28, 5 October 2024
Line 1:		Line 1:
	This article describes the structure of the code of Librae. [The code itself is available on GitLab ~~https://gitlab.com/librae/librae~~].		This article describes the structure of the code of Librae. [https://gitlab.com/librae/librae The code itself is available on GitLab].

	Part of the game engine is called <code>rustorion</code>. It's the older name for the project, and intended to be the name of the engine, when it is fully separated from game logic.		Part of the game engine is called <code>rustorion</code>. It's the older name for the project, and intended to be the name of the engine, when it is fully separated from game logic.

Librae at 10:17, 5 October 2024

2024-10-05T10:17:13Z

← Older revision		Revision as of 10:17, 5 October 2024
Line 30:		Line 30:

	However, there are simplified interfaces for '''Universe''' and '''Universeview''' called <code>rustorion::universe::interface::Universe</code> and <code>rustorion::universeview::interface::Universeview</code>, respectively. These allow for object-oriented, safe examination of data and contain many useful routines. The intention is to use these to prepare the modifications, and later execute them on the storage type after dropping the interface.		However, there are simplified interfaces for '''Universe''' and '''Universeview''' called <code>rustorion::universe::interface::Universe</code> and <code>rustorion::universeview::interface::Universeview</code>, respectively. These allow for object-oriented, safe examination of data and contain many useful routines. The intention is to use these to prepare the modifications, and later execute them on the storage type after dropping the interface.

			==RPC==

			Communication with client is done using [https://gitlab.com/librae/cborpc/ CBOR-serialized RPC]. It's rather haphazardly done using Tokio's example-like length-delimited codecs, and needs to be improved or replaced with something less monstrous than gRPC. Light macro usage might be in order.

			==Authentication==

			Clients authenticate themselves with client TLS certificates to the server. Currently BLAKE3 hashes of the client certs are used, this seems to work but is probably not the best idea.

Librae at 09:46, 5 October 2024

2024-10-05T09:46:43Z

@@ Line 6: / Line 6: @@
 The game is written in Rust. It tries to be pure Rust, but some unique foreign components are still used, most prominently GTK4 for the user interface.
 ==Game state==
@@ Line 18: / Line 24: @@
 IDs are issued sequentially, but then the number is encrypted with Blowfish to ensure there is no leaking information about number of entities in an universe. Because the encryption key is stored in Universe, only Universe can issue new IDs.

Librae: fix a link

2024-10-05T09:40:55Z

fix a link

← Older revision		Revision as of 09:40, 5 October 2024
Line 1:		Line 1:
	This article describes the structure of the code of Librae. [The code itself is https://gitlab.com/librae/librae ~~available on GitLab~~].		This article describes the structure of the code of Librae. [The code itself is available on GitLab https://gitlab.com/librae/librae].

	Part of the game engine is called <code>rustorion</code>. It's the older name for the project, and intended to be the name of the engine, when it is fully separated from game logic.		Part of the game engine is called <code>rustorion</code>. It's the older name for the project, and intended to be the name of the engine, when it is fully separated from game logic.

Librae: Created page with "This article describes the structure of the code of Librae. [The code itself is https://gitlab.com/librae/librae available on GitLab]. Part of the game engine is called `rustorion`. It's the older name for the project, and intended to be the name of the engine, when it is fully separated from game logic. ==Language== The game is written in Rust. It tries to be pure Rust, but some unique foreign components are still used, most prominently GTK4 for the user i..."

2024-10-05T09:36:36Z

Created page with "This article describes the structure of the code of Librae. [The code itself is https://gitlab.com/librae/librae available on GitLab]. Part of the game engine is called <code>rustorion</code>. It's the older name for the project, and intended to be the name of the engine, when it is fully separated from game logic. ==Language== The game is written in Rust. It tries to be pure Rust, but some unique foreign components are still used, most prominently GTK4 for the user i..."

New page

This article describes the structure of the code of Librae. [The code itself is https://gitlab.com/librae/librae available on GitLab].

Part of the game engine is called <code>rustorion</code>. It's the older name for the project, and intended to be the name of the engine, when it is fully separated from game logic.

==Language==

The game is written in Rust. It tries to be pure Rust, but some unique foreign components are still used, most prominently GTK4 for the user interface.

==Game state==

The game is structured to support trustless (except the server), simultaneous multiplayer. The game state is stored as a single '''universe''' structure (<code>rustorion::Universe</code>). Client receives a '''view''' which contains only the information the client is supposed to know. Client sends '''action'''s to the server that contain the information about what the client wants to do on the current turn. When all the players are ready (submitted their actions or it's a timeout), the server processes all the actions (they are designed to be executed independently of each other, so there are no race conditions), performs various updating on the '''universe''' and notifies clients that they can download new '''view'''s.

In the future, clients might be able to download previous views to browse them at will or use for gathering statistics.

==Entities and IDs==

Most things, '''entities''' within the '''universe''', or anything else that implements <code>EntityStored</code> have an '''ID'''. It is an unique identifier of an entity within the storing structure. Using <code>EntityStored::get()</code> and other similar methods you can obtain a reference to the entity by its ID. IDs are used to store links between entities through plain inclusion on a structure, or using types from <code>rustorion::storage::links</code> for more complex relations like many-to-many.

IDs are issued sequentially, but then the number is encrypted with Blowfish to ensure there is no leaking information about number of entities in an universe. Because the encryption key is stored in Universe, only Universe can issue new IDs.