Differences

This shows you the differences between two versions of the page.

--- start [2025/11/25 10:06] – diviner
+++ start [2025/11/25 11:22] (current) – diviner
@@ Line 9: / Line 9: @@
 === What is provided ===
-* A complete data-driven [[ECS Data Model]] with [[Entities]] and [[Components]] being the primary way of modeling the software.
+  * A complete data-driven [[ECS Data Model]] with [[Entities]] and [[Components]] being the primary way of modeling the software.
-* Native [[Serialization]] that converts all Entities and Components into compact portable serializable structures.
-* A [[Dependency Injection]] framework that allows building complex, scalable business logic.
-* A [[Message Broker]] serving as the core of the entire architecture, providing dependency inversion support that helps decouple all architectural layers.
-* UDP [[Networking]] support with a highly scalable and performant [[RPC]] infrastructure.
-* [[Input Management]] and [[Game State Management]] providing not only engine agnostic input detection, but also a scalable [[Input Command]] framework and management tooling to manage the complexity of highly interactive projects.
-* [[MVVM]] architectural support that enables the codebase to interface with game engine code in a completely decoupled way.
-* A scalable, robust and performant [[Physics System]] for 3D Rigidbody Physics, offering Raycasting, Collision Events and realtime physics simulations.
-* Portable [[Navmesh Navigation]] through A* Pathfinding for AI Agent movement and collision predictions.
-* FSM based [[AI]] offering highly modular and craftable decision making trees for complex AI agent interactions.
-* Unity plugins that import and extend these portable features for engine interfacing.
-=== What is **not** provided ===
+  * Native [[Serialization]] that converts all Entities and Components into compact portable serializable structures.
-* Server modules. The architecture is created with authoritative servers in mind, providing the ability to write game logic once and have it run both on server and client side without requiring to run the game engine on the server. Since each online game is unique in its own way and requirements, a multi-paradigm server module is not feasible. Architecture adopters are urged to use the architecture to create their own modules tailored to the needs of their games.
+  * A [[Dependency Injection]] framework that allows building complex, scalable business logic.
-* Platform deployment. The architecture depends on 3rd party support for deploying software using its features.
-* Rendering support. If graphics are required as an output, support must be given by interfacing with 3rd party rendering engines (game engines or custom made renderers).
+  * A [[Message Broker]] serving as the core of the entire architecture, providing dependency inversion support that helps decouple all architectural layers.
-* Game Engine integration other than Unity. The architecture was built for use primarily with the Unity Game Engine. Even though its portable nature allows it to interface with other engines too (Godot, custom ones), the necessary adapter code has to be implemented individually.
+  * Chunk based [[Scene Management]] that allows you to create anything from highly detailed single scene experiences, to vast game worlds with asynchronous streamable chunk loading and unloading.
+  * UDP [[Networking]] support with a highly scalable and performant [[RPC]] infrastructure.
+  * [[Input Management]] and [[Game State Management]] providing not only engine agnostic input detection, but also a scalable [[Input Command]] framework and management tooling to manage the complexity of highly interactive projects.
+  * [[MVVM]] architectural support that enables the codebase to interface with game engine code in a completely decoupled way.
+  * A 3D Vector Math Library building on top of System.Numerics.
+  * A scalable, robust and performant [[Physics System]] for 3D Rigidbody Physics, offering Raycasting, Collision Events and realtime physics simulations.
+  * Portable [[Navmesh Navigation]] through A* Pathfinding for AI Agent movement and collision predictions, with dynamic Navmesh stitching and unstitching for streamable or procedural chunks.
+  * FSM based [[AI]] offering highly modular and craftable decision making trees for complex AI agent interactions.
+  * Unity plugins that import and extend these portable features for engine interfacing.
+=== What is not provided ===
+  * Server modules. The architecture is created with authoritative servers in mind, providing the ability to write game logic once and have it run both on server and client side without requiring to run the game engine on the server. Since each online game is unique in its own way and requirements, a multi-paradigm server module is not feasible. Architecture adopters are urged to use the architecture to create their own modules tailored to the needs of their games.
+  * Publishing. The architecture depends on 3rd party support for deploying software using its features.
+  * Graphics Rendering. If graphics are required as an output, support must be given by interfacing with 3rd party rendering engines (game engines or custom made renderers).
+  * Audio Systems. Much like Graphics Rendering, if audio output is required, support must be given through 3rd party libraries.
+  * Game Engine integration other than Unity. The architecture was built for use primarily with the Unity Game Engine. Even though its portable nature allows it to interface with other engines too (Godot, custom ones), the necessary adapter code has to be implemented individually.