We rely on ScriptableObjects to drive the data in the game. Get familiar with them by checking out the Event System page. We use ScriptableObjects that we call Event Channels to connect GameObjects between themselves, with Managers, and across scenes. The event system is the backbone of the game's architecture. Actions and Conditions can access MonoBehaviour components on the host GameObject, to drive its parts (good examples are the Animator, the CharacterController, or particle systems).įind out more in the specific State Machine page. Then, once in Play Mode, is powered by a MonoBehaviour present on the character itself, which first kicks off the first State, and from then it plays back Actions (which can run upon entering or exiting a state, or per-frame) and evaluates Conditions to determine which state to move to next. This State Machine is first composed with a series of interconnected ScriptableObjects (found in ScriptableObjects/StateMachine/) which act as the editor-time data. State machineĬharacters in the game are powered via a community-made Finite State Machine (FSM) solution. Think of them like Singletons, except we don't use the Singleton pattern but an event-driven architecture to have these scripts listen to specific in-game events and react to them. Scripts that end with -Manager and -System are MonoBehaviours which take care of entire parts of the game. To create a new Location scene, check out the related page. You can find them in the folder /ScriptableObjects/SceneData/. These bits of data are passed around and contain the reference to the Unity Scene file, in addition to some useful data like a descriptive Location name, and more. On top of the native Unity scenes, we have a data layer made of ScriptableObjects called SceneDataSO. (this diagram is also available on Miro for bigger text) If the player returns to the main menu, MainMenu is loaded again and all the Location scenes are unloaded, as well as Gameplay.This contains gameplay UI and other managers that only have a reason to be in Location scenes. In addition to these, a permanent Gameplay scene is always loaded for as long as the player is in gameplay. When gameplay begins the loading system will load/unload what we call Locations.This houses all the main menu UI, settings, and allows to begin gameplay. Right after the Initialization scene has given control to PersistentManagers, MainMenu is the first real scene loaded.If you ever start the game from any other Unity scene, there is a little editor-only hack (a Prefab called EditorInizialization) that will load PersistentManagers and other important scenes, so that these scripts are present. PersistentManagers is a scene that is never unloaded throughout the whole game, and houses the managers which perform across-scene operations like playing audio or loading new scenes.At this point the scene Initialization unloads itself. This scene is almost empty, except for a script that loads the scene PersistentManagers and then requests the loading of MainMenu. The game always begins in a Unity scene called Initialization.Scene loading and unloading is all done by a SceneLoader script living in a scene called PersistentManagers (see below). We use additive scene loading in the game to allow having multiple scenes loaded at the same time. This page is designed to give you a quick overview of the game architecture.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |