Update 'Step 2: Player, Movement, and Collision'

Step-2%3A-Player%2C--Movement%2C-and-Collision.md

@@ -1,4 +1,31 @@
-# Player Movement
-# Collision System
+Once the Level Scene base is ready, it's time to add in the Player entity and some semblance of a level.
+# Player Entity
+A player entity (and most entities) composes of a BBox component and a Transform component. The Transform Component describes the position, velocity, and acceleration of the entity, while the BBox component describes the bounding box of the entity. Both of these components will be used for collision detection later.
+## Player Movement
+In the original game, the player movement is fairly simple and straightforward. These are the possible movements which have to be implemented:
+- Move left and right on ground
+- Can crouch on ground and move
+- Can jump once (standing or crouching) if possible
+- Can swim in cardinal direction
+- Can jump out of water
+For this implementation, I've opted to use acceleration for movement. This is not true in the original. I believe the original uses instant acceleration (directly modifying the velocity). The latter allows for more precise platforming. However, I find that acceleration is slightly easier to deal with. To allow better control of the player, the acceleration is set to a high value and the velocity is capped. This allows for a near-instant maximum velocity.  
+
+Two forces are applied to the player typically:
+- Gravity: Constantly downwards. Does not apply if player is on the ground (cancelled out by normal force by the ground)
+- Frictional force: modeled to be velocity-dependent and is consistent across ground and air movement. This is to avoid the player being faster in the air and therefore being more predictable with jumps.
+If the player is swimming:
+- Gravity: same as before
+- Upthrust: Some factor of gravity. In the original game, the player naturally floats upwards. Thus, upthrust is set to be higher than gravity.
+- Frictional Force: now consistent in all direction
+## Movement Update
+The movement update is a simple forward Euler method.
+
+# Collision System Part I
+With the introduction of a player, the collision system should be implemented as well. In the original game, the game is set up as with a grid-like system. Therefore, the implementation will follow suit. This part of collision system to mainly focus on collision with _solid tiles_. Entities collision handling will come later.
+
+This isn't the first time I've deal with collision. In fact, I've always thought how collisions are handled in game for years. Past implementations of mine in the past worked but not quite satisfying.
+
+To keep it simple, the only collision shape to deal with is **Axis-Aligned Bounding Boxes (AABB)**. This should be sufficient as the original game does not introduce slopes or any more convex shapes.
+
 ## Broad Phase
 ## Narrow Phase