Player movement in Umibozu

Context

As part of this course, my group  has to develop a 2d shoot them up derived from a concept document made another group of students.  Our game  is a top down shooter where you drive a boat in a mist shrouded sea in search of a mythical monster from Japanese folklore(named Umibozu) armed only with a light to pierce the fog and a harpoon. The stated aesthetics of the concept is to create an atmosphere of mystery and constant (moderate) threat.  In this little article I will discuss some of the thoughts that went into designing the player movement for that game.

Vertical scroll versus Free movement

In the original concept document, the player would progress in one direction vertically and use the horizontal axis to dodge enemies and pick up power-ups. This reproduce how movement is used in many shooter (most bullet hell game have a similar movement verb). However, we felt it was not the best possible player movement for this game. Instead, we had gave the player the ability to rotate the ship around and to propel themselves forward or backward, in addition the camera follows the player so the ship is always in the center of the screen , pointing up. This let the player move in all direction and enable two things : first, the player can now explore the game world rather than simply traversing it. Second, and more importantly, it lets the player getting lost. Both these elements greatly enhance an experience revolving around a mystery and hidden danger while also creating new challenges for the player to overcome.

movement screen
Example of now possible trajectory(and collision)

Physics

After the initial, rough movement feel of the earliest builds of the game, I’ve started thinking about how exactly should react to input to best serve the core gameplay, i.e dodging threats that emerge from the mist when revealed by the ship’s spot light. I came to the conclusion than giving the boat a limited maneuverability , if done properly could enhance the play experience. I decided to give the boat a great deal of inertia, turning would not instantly change the player’s direction of movement like it did in early build. The result was, to my opinion a bit more interesting , as it gives the player a choice to make. Going fast make it difficult to stear clear of threats in front of the player , like reefs and rocks, however being to slow would make them vulnerable to enemy attacks. The more sluggish controls also enable the gameplay to focus on dodging without the game becoming a bullet hell, which would likely be heavily dissonant with the aesthetic the game aims at.

Unfortunately something was very off about it and I quickly realized what it was. One would expect to be dragged more heavily by water if one’s boat did not align with the direction of movement. I then incorporated a simple operation (attempting to simulate even closely the behavior of a real ship seems utterly pointless here) that augment drag depending of the angle between the direction the boat pointed to and velocity. It allows player to take sharper turns and also acts as an emergency break on top of backward thrust, creating an optional layer of possible mastery of the game.

Conclusion

I will probably come back often to movement during development to tweak it. It is after all, the most used verb in this game and therefor should receive at least as much (and in this case I believe, more) attention than the shooting mechanic.

 

 

 

 

About Nicolas Basil Gerard

2017 Programming