Game Architecture - Revision history

Foonix: Note what happens if there is no IPriorityOverride. Add ThermalBehavior.

2025-07-23T12:00:43Z

Note what happens if there is no IPriorityOverride. Add ThermalBehavior.

← Older revision		Revision as of 14:00, 23 July 2025
Line 45:		Line 45:
	At the top level, game updates are driven by the [https://docs.unity3d.com/Manual/ExecutionOrder.html Unity game loop update order]. However, most updates in the game are not driven directly by Unity. Instead, most view objects register for updates from GameInstance, and most sim object register for updates from SpaceSimulation. SpaceSimulation registers its self with GameInstance to receive updates, and in turn drives updates for all sim objects.		At the top level, game updates are driven by the [https://docs.unity3d.com/Manual/ExecutionOrder.html Unity game loop update order]. However, most updates in the game are not driven directly by Unity. Instead, most view objects register for updates from GameInstance, and most sim object register for updates from SpaceSimulation. SpaceSimulation registers its self with GameInstance to receive updates, and in turn drives updates for all sim objects.

	Objects registering for updates from GameInstance must implement at least one of IFixedUpdate, IUpdate, or ILateUpdate interfaces. They may optionally implement IPriorityOverride to control the order in which they are called with respect to other updates.		Objects registering for updates from GameInstance must implement at least one of IFixedUpdate, IUpdate, or ILateUpdate interfaces. They may optionally implement IPriorityOverride to control the order in which they are called with respect to other updates. If there is no IPriorityOverride, the priority is treated as -1.

	Updates are run in ascending order of priority (lowest to highest).		Updates are run in ascending order of priority (lowest to highest).
	{\| class="wikitable"		{\| class="wikitable"
	! Component !! IPriorityOverride !! IFixedUpdate? !! IUpdate? !! ILateUpdate? !! other !! Sub-process		! Component !! IPriorityOverride !! IFixedUpdate? !! IUpdate? !! ILateUpdate? !! other !! Sub-process
			\|-
			\| ThermalBehavior \|\| N/A \|\| ❌ \|\| ✅ \|\| ✅ \|\| \|\|
	\|-		\|-
	\| UniverseModel \|\| 0 \|\| ✅ \|\| ❌ \|\| ❌ \|\| \|\|		\| UniverseModel \|\| 0 \|\| ✅ \|\| ❌ \|\| ❌ \|\| \|\|

Foonix: Use unicode icons

2024-09-13T12:15:58Z

Use unicode icons

← Older revision		Revision as of 14:15, 13 September 2024
Line 1:		Line 1:
	=== The Sim and the View ===		= The Sim and the View =
	The game is divided into two conceptual layers, the "sim" and the "view." The sim layer contains all objects that exist anywhere in the game, visible or not. The view is only objects close enough to the player to be visible. Both layers can be access globally under the current `GameInstance`		The game is divided into two conceptual layers, the "sim" and the "view." The sim layer contains all objects that exist anywhere in the game, visible or not. The view is only objects close enough to the player to be visible. Both layers can be access globally under the current `GameInstance`

Line 41:		Line 41:
	SimulationObjectView has a property called Model that always points to the corresponding sim object.		SimulationObjectView has a property called Model that always points to the corresponding sim object.

	=== Game update order ===		= Game update order =

	At the top level, game updates are driven by the [https://docs.unity3d.com/Manual/ExecutionOrder.html Unity game loop update order]. However, most updates in the game are not driven directly by Unity. Instead, most view objects register for updates from GameInstance, and most sim object register for updates from SpaceSimulation. SpaceSimulation registers its self with GameInstance to receive updates, and in turn drives updates for all sim objects.		At the top level, game updates are driven by the [https://docs.unity3d.com/Manual/ExecutionOrder.html Unity game loop update order]. However, most updates in the game are not driven directly by Unity. Instead, most view objects register for updates from GameInstance, and most sim object register for updates from SpaceSimulation. SpaceSimulation registers its self with GameInstance to receive updates, and in turn drives updates for all sim objects.
Line 47:		Line 47:
	Objects registering for updates from GameInstance must implement at least one of IFixedUpdate, IUpdate, or ILateUpdate interfaces. They may optionally implement IPriorityOverride to control the order in which they are called with respect to other updates.		Objects registering for updates from GameInstance must implement at least one of IFixedUpdate, IUpdate, or ILateUpdate interfaces. They may optionally implement IPriorityOverride to control the order in which they are called with respect to other updates.

			Updates are run in ascending order of priority (lowest to highest).
	{\| class="wikitable"		{\| class="wikitable"
	! Component !! IPriorityOverride !! IFixedUpdate? !! IUpdate? !! ILateUpdate? !! other !! Sub-process		! Component !! IPriorityOverride !! IFixedUpdate? !! IUpdate? !! ILateUpdate? !! other !! Sub-process
	\|-		\|-
	\| UniverseModel \|\| 0 \|\| 1 \|\| 0 \|\| 0 \|\| \|\|		\| UniverseModel \|\| 0 \|\| ✅ \|\| ❌ \|\| ❌ \|\| \|\|
	\|-		\|-
	\| WaterInitPerFrameAction \|\| 0 \|\| 0 \|\| 0 \|\| 1 \|\| \|\|		\| WaterInitPerFrameAction \|\| 0 \|\| ❌ \|\| ❌ \|\| ✅ \|\| \|\|
	\|-		\|-
	\| OceanUpdateAction \|\| 1 \|\| 0 \|\| 0 \|\| 1 \|\| \|\|		\| OceanUpdateAction \|\| 1 \|\| ❌ \|\| ❌ \|\| ✅ \|\| \|\|
	\|-		\|-
	\| PhysicsSpaceProvider \|\| 1 \|\| 1 \|\| 0 \|\| 0 \|\| \|\|		\| PhysicsSpaceProvider \|\| 1 \|\| ✅ \|\| ❌ \|\| ❌ \|\| \|\|
	\|-		\|-
	\| ClearWaterDepthAction \|\| 2 \|\| 0 \|\| 0 \|\| 1 \|\| \|\|		\| ClearWaterDepthAction \|\| 2 \|\| ❌ \|\| ❌ \|\| ✅ \|\| \|\|
	\|-		\|-
	\| FloatingOrigin \|\| 2 \|\| 1 \|\| 1 \|\| 0 \|\| \|\|		\| FloatingOrigin \|\| 2 \|\| ✅ \|\| ✅ \|\| ❌ \|\| \|\|
	\|-		\|-
	\| HandOfKraken \|\| 2 \|\| 1 \|\| 1 \|\| 0 \|\| \|\|		\| HandOfKraken \|\| 2 \|\| ✅ \|\| ✅ \|\| ❌ \|\| \|\|
	\|-		\|-
	\| DrawLandBasedWaterAction \|\| 3 \|\| 0 \|\| 0 \|\| 1 \|\| \|\|		\| DrawLandBasedWaterAction \|\| 3 \|\| ❌ \|\| ❌ \|\| ✅ \|\| \|\|
	\|-		\|-
	\| RigidbodyBehavior \|\| 3 \|\| 1 \|\| 1 \|\| 0 \|\| ~~Can change priority! ExecutionPriorityOverride =~~ 4 ~~if the vessel object is also a Part~~ \|\|		\| RigidbodyBehavior (vessels) \|\| 3 \|\| ✅ \|\| ✅ \|\| ❌ \|\| \|\|
			\|-
			\| RigidbodyBehavior (parts) \|\| 4 \|\| ✅ \|\| ✅ \|\| ❌ \|\| \|\|
	\|-		\|-
	\| KerbalBehavior \|\| 5 \|\| 1 \|\| 1 \|\| 1 \|\| \|\|		\| KerbalBehavior \|\| 5 \|\| ✅ \|\| ✅ \|\| ✅ \|\| \|\|
	\|-		\|-
	\| SpaceSimulation \|\| 6 \|\| 1 \|\| 1 \|\| 1 \|\| IViewActionQueue \|\| UniverseModel.UpdateSimObjects() (unordered)		\| SpaceSimulation \|\| 6 \|\| ✅ \|\| ✅ \|\| ✅ \|\| IViewActionQueue \|\| UniverseModel.UpdateSimObjects() (unordered)
	\|-		\|-
	\| CelestialBodyProxy \|\| 10 \|\| 0 \|\| 1 \|\| 0 \|\| \|\|		\| CelestialBodyProxy \|\| 10 \|\| ❌ \|\| ✅ \|\| ❌ \|\| \|\|
	\|-		\|-
	\| PartBehavior \|\| 40 \|\| 1 \|\| 1 \|\| 0 \|\| WaterManager.IWaterDetectObject \|\|		\| PartBehavior \|\| 40 \|\| ✅ \|\| ✅ \|\| ❌ \|\| WaterManager.IWaterDetectObject \|\|
	\|-		\|-
	\| PartBehaviourModule \|\| 50 \|\| 1 \|\| 1 \|\| 0 \|\| \|\|		\| PartBehaviourModule \|\| 50 \|\| ✅ \|\| ✅ \|\| ❌ \|\| \|\|
	\|-		\|-
	\| ViewController \|\| 50 \|\| 0 \|\| 1 \|\| 0 \|\| \|\|		\| ViewController \|\| 50 \|\| ❌ \|\| ✅ \|\| ❌ \|\| \|\|
	\|-		\|-
	\| VesselBehavior \|\| 150 \|\| 1 \|\| 1 \|\| 1 \|\| \|\|		\| VesselBehavior \|\| 150 \|\| ✅ \|\| ✅ \|\| ✅ \|\| \|\|
	\|-		\|-
	\| UniverseView \|\| 500 \|\| 1 \|\| 1 \|\| 0 \|\| \|\|		\| UniverseView \|\| 500 \|\| ✅ \|\| ✅ \|\| ❌ \|\| \|\|
	\|-		\|-
	\| TimeWarp \|\| 1000 \|\| 1 \|\| 0 \|\| 0 \|\| \|\|		\| TimeWarp \|\| 1000 \|\| ✅ \|\| ❌ \|\| ❌ \|\| \|\|
	\|-		\|-
	\| DrawOceanAction \|\| 2001 \|\| 0 \|\| 0 \|\| 1 \|\| \|\|		\| DrawOceanAction \|\| 2001 \|\| ❌ \|\| ❌ \|\| ✅ \|\| \|\|
	\|-		\|-
	\| WaitWaterDetectionAction \|\| 2002 \|\| 0 \|\| 0 \|\| 1 \|\| \|\|		\| WaitWaterDetectionAction \|\| 2002 \|\| ❌ \|\| ❌ \|\| ✅ \|\| \|\|
	\|}		\|}

Foonix: /* Game update order */

2024-09-13T12:04:36Z

Game update order

← Older revision		Revision as of 14:04, 13 September 2024
Line 46:		Line 46:

	Objects registering for updates from GameInstance must implement at least one of IFixedUpdate, IUpdate, or ILateUpdate interfaces. They may optionally implement IPriorityOverride to control the order in which they are called with respect to other updates.		Objects registering for updates from GameInstance must implement at least one of IFixedUpdate, IUpdate, or ILateUpdate interfaces. They may optionally implement IPriorityOverride to control the order in which they are called with respect to other updates.

			{\| class="wikitable"
			! Component !! IPriorityOverride !! IFixedUpdate? !! IUpdate? !! ILateUpdate? !! other !! Sub-process
			\|-
			\| UniverseModel \|\| 0 \|\| 1 \|\| 0 \|\| 0 \|\| \|\|
			\|-
			\| WaterInitPerFrameAction \|\| 0 \|\| 0 \|\| 0 \|\| 1 \|\| \|\|
			\|-
			\| OceanUpdateAction \|\| 1 \|\| 0 \|\| 0 \|\| 1 \|\| \|\|
			\|-
			\| PhysicsSpaceProvider \|\| 1 \|\| 1 \|\| 0 \|\| 0 \|\| \|\|
			\|-
			\| ClearWaterDepthAction \|\| 2 \|\| 0 \|\| 0 \|\| 1 \|\| \|\|
			\|-
			\| FloatingOrigin \|\| 2 \|\| 1 \|\| 1 \|\| 0 \|\| \|\|
			\|-
			\| HandOfKraken \|\| 2 \|\| 1 \|\| 1 \|\| 0 \|\| \|\|
			\|-
			\| DrawLandBasedWaterAction \|\| 3 \|\| 0 \|\| 0 \|\| 1 \|\| \|\|
			\|-
			\| RigidbodyBehavior \|\| 3 \|\| 1 \|\| 1 \|\| 0 \|\| Can change priority! ExecutionPriorityOverride = 4 if the vessel object is also a Part \|\|
			\|-
			\| KerbalBehavior \|\| 5 \|\| 1 \|\| 1 \|\| 1 \|\| \|\|
			\|-
			\| SpaceSimulation \|\| 6 \|\| 1 \|\| 1 \|\| 1 \|\| IViewActionQueue \|\| UniverseModel.UpdateSimObjects() (unordered)
			\|-
			\| CelestialBodyProxy \|\| 10 \|\| 0 \|\| 1 \|\| 0 \|\| \|\|
			\|-
			\| PartBehavior \|\| 40 \|\| 1 \|\| 1 \|\| 0 \|\| WaterManager.IWaterDetectObject \|\|
			\|-
			\| PartBehaviourModule \|\| 50 \|\| 1 \|\| 1 \|\| 0 \|\| \|\|
			\|-
			\| ViewController \|\| 50 \|\| 0 \|\| 1 \|\| 0 \|\| \|\|
			\|-
			\| VesselBehavior \|\| 150 \|\| 1 \|\| 1 \|\| 1 \|\| \|\|
			\|-
			\| UniverseView \|\| 500 \|\| 1 \|\| 1 \|\| 0 \|\| \|\|
			\|-
			\| TimeWarp \|\| 1000 \|\| 1 \|\| 0 \|\| 0 \|\| \|\|
			\|-
			\| DrawOceanAction \|\| 2001 \|\| 0 \|\| 0 \|\| 1 \|\| \|\|
			\|-
			\| WaitWaterDetectionAction \|\| 2002 \|\| 0 \|\| 0 \|\| 1 \|\| \|\|
			\|}

Foonix at 12:02, 13 September 2024

2024-09-13T12:02:11Z

← Older revision		Revision as of 14:02, 13 September 2024
Line 29:		Line 29:
	\|}		\|}

	=== Accessing a view object from a sim object ===		== Accessing a view object from a sim object ==

	A view object (if it exists) can always be looked up using a global dictionary ModelViewMap in SpaceSimulation.		A view object (if it exists) can always be looked up using a global dictionary ModelViewMap in SpaceSimulation.
Line 37:		Line 37:
	Note, some components have convenience accessors that act as a shortcut to getting the view object (if it exists.) For example, any sim object that is a vessel (I.E. it has a VesselComponent) and has an active VesselBehavior should have objVesselBehavior set and pointing to the corresponding VesselBehavior.		Note, some components have convenience accessors that act as a shortcut to getting the view object (if it exists.) For example, any sim object that is a vessel (I.E. it has a VesselComponent) and has an active VesselBehavior should have objVesselBehavior set and pointing to the corresponding VesselBehavior.

	=== Accessing a sim object from a view object ===		== Accessing a sim object from a view object ==

	SimulationObjectView has a property called Model that always points to the corresponding sim object.		SimulationObjectView has a property called Model that always points to the corresponding sim object.

			=== Game update order ===

			At the top level, game updates are driven by the [https://docs.unity3d.com/Manual/ExecutionOrder.html Unity game loop update order]. However, most updates in the game are not driven directly by Unity. Instead, most view objects register for updates from GameInstance, and most sim object register for updates from SpaceSimulation. SpaceSimulation registers its self with GameInstance to receive updates, and in turn drives updates for all sim objects.

			Objects registering for updates from GameInstance must implement at least one of IFixedUpdate, IUpdate, or ILateUpdate interfaces. They may optionally implement IPriorityOverride to control the order in which they are called with respect to other updates.

Foonix at 11:16, 13 September 2024

2024-09-13T11:16:14Z

← Older revision		Revision as of 13:16, 13 September 2024
Line 2:		Line 2:
	The game is divided into two conceptual layers, the "sim" and the "view." The sim layer contains all objects that exist anywhere in the game, visible or not. The view is only objects close enough to the player to be visible. Both layers can be access globally under the current `GameInstance`		The game is divided into two conceptual layers, the "sim" and the "view." The sim layer contains all objects that exist anywhere in the game, visible or not. The view is only objects close enough to the player to be visible. Both layers can be access globally under the current `GameInstance`

	When an object is created, it must first be created in the sim. The sim persists data and is what is stored in a save game. Generally, the sim layer does _not_ involve any Unity data (`GameObject`, `MonoBehaviour`, etc). The main object for managing the sim is `UniverseModel`		When an object is created, it must first be created in the sim. The sim persists data and is what is stored in a save game. Generally, the sim layer does _not_ involve any Unity data (`GameObject`, `MonoBehaviour`, etc). The main object for managing the sim is `UniverseModel`.

	~~<code>~~		The two layers are tied together by `SpaceSimulation`, which binds sim and view objects together, provides mappings between them, and provides common operations such as spawning vessels.
	~~GameManager~~.~~Instance.Game.UniverseModel~~
	~~GameManager.Instance.Game.UniverseView~~
	~~</code>~~

	Sim objects ~~_rougly_~~ mimic how Unity objects work. That is, there is a base object type `SimulationObjectModel` that represents a "blank slate" object, and then the object must be decorated with one or more `Component` classes to be able to do anything.		* GameManager.Instance.Game.SpaceSimulation
			* GameManager.Instance.Game.UniverseModel
			* GameManager.Instance.Game.UniverseView

			Sim objects ''rougly'' mimic how Unity objects work. That is, there is a base object type `SimulationObjectModel` that represents a "blank slate" object, and then the object must be decorated with one or more `Component` classes to be able to do anything.

	When a view object is needed, a corresponding `SimulationObjectView` (`KerbalMonoBehaviour`) is created and populated with `Behavior`s that correspond to the sim object. View objects are unity `GameObject`s that connect the sim layer to the Unity game engine.		When a view object is needed, a corresponding `SimulationObjectView` (`KerbalMonoBehaviour`) is created and populated with `Behavior`s that correspond to the sim object. View objects are unity `GameObject`s that connect the sim layer to the Unity game engine.
Line 27:		Line 28:
	\| RigidbodyComponent \|\| RigidbodyBehavior \|\| represents physical properties (torque, thrust, inertia, etc) of a part or vessel. Vessel rigidbodies represent averages or other aggregation (eg, moment of inertia) of all of the part rigidbodies owned by the vessel.		\| RigidbodyComponent \|\| RigidbodyBehavior \|\| represents physical properties (torque, thrust, inertia, etc) of a part or vessel. Vessel rigidbodies represent averages or other aggregation (eg, moment of inertia) of all of the part rigidbodies owned by the vessel.
	\|}		\|}

			=== Accessing a view object from a sim object ===

			A view object (if it exists) can always be looked up using a global dictionary ModelViewMap in SpaceSimulation.

			<code>SimulationObjectView simulationObjectView = Game?.SpaceSimulation?.ModelViewMap.FromModel(simulationObject);</code>

			Note, some components have convenience accessors that act as a shortcut to getting the view object (if it exists.) For example, any sim object that is a vessel (I.E. it has a VesselComponent) and has an active VesselBehavior should have objVesselBehavior set and pointing to the corresponding VesselBehavior.

			=== Accessing a sim object from a view object ===

			SimulationObjectView has a property called Model that always points to the corresponding sim object.

Foonix at 10:27, 13 September 2024

2024-09-13T10:27:22Z

← Older revision	Revision as of 12:27, 13 September 2024
Line 1:	Line 1:
		=== The Sim and the View ===
		The game is divided into two conceptual layers, the "sim" and the "view." The sim layer contains all objects that exist anywhere in the game, visible or not. The view is only objects close enough to the player to be visible. Both layers can be access globally under the current `GameInstance`

		When an object is created, it must first be created in the sim. The sim persists data and is what is stored in a save game. Generally, the sim layer does _not_ involve any Unity data (`GameObject`, `MonoBehaviour`, etc). The main object for managing the sim is `UniverseModel`

		<code>
		GameManager.Instance.Game.UniverseModel
		GameManager.Instance.Game.UniverseView
		</code>

		Sim objects _rougly_ mimic how Unity objects work. That is, there is a base object type `SimulationObjectModel` that represents a "blank slate" object, and then the object must be decorated with one or more `Component` classes to be able to do anything.

		When a view object is needed, a corresponding `SimulationObjectView` (`KerbalMonoBehaviour`) is created and populated with `Behavior`s that correspond to the sim object. View objects are unity `GameObject`s that connect the sim layer to the Unity game engine.

		{\| class="wikitable"
		\|+ Common Components
		! Sim Component Name !! View Behavior Name !! Description
		\|-
		\| CelestialBodyComponent \|\| CelestialBodyBehavior \|\| Represent stars and planets. Provides data such as atmospheric drag, gravity, ocean levels, buoyancy data, PQS data, and terrain colliders.
		\|-
		\| VesselComponent \|\| VesselBehavior \|\| Vessel (or EVA'ing kerbal) global data, such as target, aggregate mass information, etc.
		\|-
		\| PartComponent \|\| PartBehavior \|\| Data about individual parts. Fuel storage, kerbals on board, etc. Parts are normally owned by a vessel, but can be free floating (orphaned) such as debris or discard fairings/decouplers.
		\|-
		\| PartOwnerComponent \|\| PartOwnerBehavior \|\| A part owner has a 1:1 relationship with `Vessel` and is a list of parts owned (1:many) by that vessel. Data about individual parts (mass, direction, rotation, etc) is aggregated by the Owner.
		\|-
		\| RigidbodyComponent \|\| RigidbodyBehavior \|\| represents physical properties (torque, thrust, inertia, etc) of a part or vessel. Vessel rigidbodies represent averages or other aggregation (eg, moment of inertia) of all of the part rigidbodies owned by the vessel.
		\|}

Foonix: Blanked the page

2024-09-13T10:00:56Z

Blanked the page

← Older revision		Revision as of 12:00, 13 September 2024
Line 1:		Line 1:
	~~<nowiki>=== The Sim and the View ===</nowiki>~~

Foonix: initial

2024-09-13T09:59:39Z

initial

New page