From 04351652a8ec6661e91570560af19a09249fbe8a Mon Sep 17 00:00:00 2001 From: sadpmpk Date: Sun, 1 Jan 2023 10:37:48 -0500 Subject: [PATCH] Update 'Step 1: Scene, Systems, and Input Handling' --- ...-Scene%2C-Systems%2C-and-Input-Handling.md | 27 ++++++++++++++----- 1 file changed, 20 insertions(+), 7 deletions(-) rename Step-1%3A-Scene%2C-Systems%2C-and-Actions.md => Step-1%3A-Scene%2C-Systems%2C-and-Input-Handling.md (68%) diff --git a/Step-1%3A-Scene%2C-Systems%2C-and-Actions.md b/Step-1%3A-Scene%2C-Systems%2C-and-Input-Handling.md similarity index 68% rename from Step-1%3A-Scene%2C-Systems%2C-and-Actions.md rename to Step-1%3A-Scene%2C-Systems%2C-and-Input-Handling.md index d5e24c3..8599a0b 100644 --- a/Step-1%3A-Scene%2C-Systems%2C-and-Actions.md +++ b/Step-1%3A-Scene%2C-Systems%2C-and-Input-Handling.md @@ -1,4 +1,4 @@ -Now that the component and entity are basically implemented with a manager, the next step actually use them. +Now that the component and entity are basically implemented with a manager, the next step is to actually use them. # Scenes In a game, there would be many _Scenes_, such as main game loop, main menu, pause screen, etc. Each Scene has its own logic, systems, key handling, and entities. The lecture uses OO design approach to implementing Scenes. It introduces a BaseScene interface class where it would contains common Scene function and data. Subsequent Scenes will derived from the BaseScene to implement Scene-specific logic. @@ -40,22 +40,35 @@ typedef struct LevelSceneData ``` As seen above, these data fields are specific to the LevelScene. The LevelSceneData is then set as the Scene `scene_data` pointer during initialisation. # Systems -As mentioned before, systems are functions that describes the interactions of components and/or entities. Systems can vary between Scene to Scene. In this implementation, a system is a function pointer that takes in a pointer to a base Scene class and returns nothing. Using the Scene class, Scene-specific data can be accessed via the `scene_data` pointer, while the entities and/or components can be access via the `ent_manager` field. +As mentioned before, systems are functions that describes the interactions of components and/or entities. Systems can vary from Scene to Scene. In this implementation, a system is a function pointer that takes in a pointer to a base Scene class and returns nothing. Using the Scene class, Scene-specific data can be accessed via the `scene_data` pointer, while the entities and/or components can be access via the `ent_manager` field. +``` +typedef void(*system_func_t)(Scene_t *); +``` During the loop, the systems are executed in a linear order. Therefore, the **order** of the systems added to the Scene is important. -# Key Handling and Actions -As per the lectures, Actions are introduced as interface to the physical controls used. The buttons/keys/motions of the physical inputs are translate into these Actions via a defined mapping that is registered during runtime. +# Input Handling +## Actions +As per the lecture, Actions are introduced as interfaces to the physical controls used. The buttons/keys/motions of the physical inputs are translated into these Actions via a defined mapping that is registered during runtime. -Actions can performed different things for different scenes. E.g. the Up action in a main menu would move the selection pointer upwards, while that may cause the player to jump in a gameplay scene. +Actions can perform different things for different Scenes. E.g. the Up action in a main menu would move the selection pointer upwards, while that may cause the player to jump in a gameplay scene. -Therefore, Scenes must also implement what Actions would do for that scene under `action_function` field. +Therefore, Scenes must also implement what Actions would do for that scene under `action_function` field. The action function is also a function pointer: +``` +typedef void(*action_func_t)(Scene_t *, ActionType_t, bool); +``` +In the implementation, an action has two states: either pressed or released. This is the last input of the function pointer. A hold is just pressed sustained for multiple frames. + +Having Actions implemented allows for replay system implementation as described in the lecture series. However, this is not considered at this early stage of implementation. + +## Key Handling +The game will be implemented will keyboard in mind, as per the original game. Raylib provides functions to detect key presses and releases. One nice function is the `GetKeyPressed` function which gives the keys pressed (not hold) for the frame. Internally, Raylib maintains a queue for the key pressed. However, it does not have a corresponding function to detect key releases. To deal with this, a separate queue is used to maintain the key already pressed in order to check for releases. In the implementation, the keys that are pressed previously are checked for release. Then, it will check for any new key presses. A snippet for this logic can be seen in `scene_test.c` ``` struct sc_queue_32 key_buffer; -... + for (size_t i=0; i