Update 'Step 1: Scene, Systems, and Input Handling'

Step-1%3A-Scene%2C-Systems%2C-and-Input-Handling.md

@@ -6,7 +6,7 @@ Now that the component and entity are basically implemented with a manager, the
  Unfortunately, once again, C does not have such convenience. So, I have to emulate it somewhat. The implementation will also have a base Scene struct. Subsequent implemented Scene will need to contain a Scene field and a Scene-specific data field.
  
  The base Scene struct looks like this in `scene.h`:
- ```
+ ```c
  struct Scene
 {
     struct sc_map_64 action_map; // key -> actions
@@ -23,7 +23,7 @@ Now that the component and entity are basically implemented with a manager, the
  Note that in the base Scene struct, it holds a pointer the scene-specific data.
  
  As a starter, the LevelScene struct, which is where the gameplay takes place, is implemented as such in `scene_impl.h`:
- ```
+ ```c
  typedef struct LevelScene
 {
     Scene_t scene;
@@ -41,7 +41,7 @@ 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 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.
-```
+```c
 typedef void(*system_func_t)(Scene_t *);
 ```
 
@@ -53,7 +53,7 @@ As per the lecture, Actions are introduced as interfaces to the physical control
 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. The action function is also a function pointer:
-```
+```c
 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.
@@ -61,17 +61,17 @@ In the implementation, an action has two states: either pressed or released. Thi
 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.
+The game will be implemented with 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`
-```
+```c
 struct sc_queue_32 key_buffer;
 
 for (size_t i=0; i<sz; i++)
 {
-	int button = sc_queue_del_first(&key_buffer);
+    int button = sc_queue_del_first(&key_buffer);
     ActionType_t action = sc_map_get_64(&scene.scene.action_map, button);
     if (IsKeyReleased(button))
     {
@@ -85,7 +85,7 @@ for (size_t i=0; i<sz; i++)
 }
 while(true)
 {
-	int button = GetKeyPressed();
+    int button = GetKeyPressed();
     if (button == 0) break;
     ActionType_t action = sc_map_get_64(&scene.scene.action_map, button);
     if (!sc_map_found(&scene.scene.action_map)) continue;