I’ve completed development to satisfy my second requirements Haiku. When the player reaches the door, they win, and the game is reset to its original state.

Verse 1:2

Walk across the room.
That door looks awfully nice.
I just won the game.

W, A, S, D keys move the character. Depending on browser and operating system, you may need to click on the game before the controls will work.

In order to meet this goal, I had to rough out the physics system just enough to get the player character moving around. I opted for a force-based interface into the physics system; each step action instructs the physics system to apply a force to the player entity in the appropriate direction, rather than directly changing the player's position or velocity. The physics system deals with all of the consequences from there on.

Unfortunately, after the first step there is leftover velocity that results in the player flying across the screen. Nothing is slowing the player down. I considered a few different ways to handle this.

  1. Remember the previous step and apply an opposing force before stepping again
  2. Scrap force-based physics altogether in favour of just instructing the physics system to move an object from A-to-B
  3. Implement friction

Option #1 is not very attractive for many reasons. Rather than working with the here and now, we're making decisions based on previous actions. Any changes that occur between the original step and the new step have to be taken into account when determining if a counter-force must be applied, and how much force to necessary.

Option #2 was tempting, as it mirrors my previous Roguelike work more closely. However, working only with forces instead of velocities or actual positions ensures that the physics remains black boxed. This is inconvenient in some ways, but that is far outweighed by the benefit of keeping physics decoupled from the rest of the code base. Previous projects have demonstrated that physics are particularly apt at latching themselves onto everything around them once you decide to open them up.

That leaves me with option #3; as an entity moves across a surface, friction is applied. I'm currently tracking velocity as an integer, so the one tile velocity of walking is rounded to 0 by friction after one calculation. This puts me in a great position to implement a couple of features. The character can run by applying more force per action, and icy surface jut needs a low friction coefficient. I've set my next goal with this in mind. Testing out how the physics implementation handles different situations will tell me whether or not I made the right choice.

Verse 1:3

In quite a hurry,
but the ice is treacherous.
The walls are not soft.