Differences

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

--- start [2025/11/25 10:06] – diviner
+++ start [2026/04/26 06:39] (current) – diviner
@@ Line 1: / Line 1: @@
-====== ECS Architecture Documentation ======
-This is the Documentation for the CREAT3D ECS Architecture. It contains both high level concepts and overview, as well as low level scripting reference and documentation.
 ===== Overview =====
@@ Line 9: / Line 5: @@
 === 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.
+  * Native [[Serialization]] that converts all Entities and Components into compact portable serializable structures.
-* 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.
+  * A [[Dependency Injection]] framework that allows building complex, scalable business logic.
-* [[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 [[Message Broker]] serving as the core of the entire architecture, providing dependency inversion support that helps decouple all architectural layers.
-* 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.
+  * 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.
-* 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.
+  * 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).
-=== What is **not** provided ===
+  * Audio Systems. Much like Graphics Rendering, if audio output is required, support must be given through 3rd party libraries.
-* 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.
+  * 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.
-* 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).
-* 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.