Week 7 - Player Movement

Initial Implementation

At the very start of this project, I knew that the player would be controlling an object travelling across the screen from left to right at high speeds. However, I did not know exactly how I would approach this. Two options were considered:

1. Simulate horizontal movement. Have the player remain stationary, but throw objects at them from off screen and scroll a background to give the illusion of movement. I thought this might be more efficient and neat rather than having the player literally moving though space.
2. Do actual horizontal movement. This was the more straightforward option, and ended up being the one I went with, as simulating physics, giving a sense of speed and travel were all much more achievable. With regards to the camera scrolling, I thought it would be a perfect situation to make use of Cinemachine's dolly track camera feature, which has worked out well.

There was some uncertainty over if the player's projectile should be able to accelerate and decelerate, and boil down the game to just steering. I eventually decided to allow control over horizontal movement to make the game more engaging (only controlling the vertical axis might be boring), and to give the player a better sense of what speed they were travelling at.

With this first build, none of the objects in the game are very complex or have detailed behaviours. The player object moves, chunks of debris are manually placed at random points along the route and given a random speed and rotation, and the planet at the end does nothing at all.

I implemented some basic particle effects for the projectile trail, when the projectile is at top speed, and when it crashes into the planet. For the moment, the player bounces off the chunks of debris instead of crashing - this is something I may or may not keep.

Player Feedback

After the first round of playtesting, feedback typically fell into four areas:

1. Vertical movement has no speed limit
2. Vertical wrapping for player projectile unnecessary/too easy
3. Difficulties reaching end of level
4. Insufficient indication of speed

Soon after building and uploading the initial version of the game, I became aware of the lack of speed limit on the player's vertical steering, and how this could be exploited to achieve and exceed top speed. Soon after the playtesting had started, I immediately began work on fixing the issue, however the second point of feedback convinced me to remove vertical wrapping altogether rather than introducing a max steering speed. So the removal of vertical wrapping addresses two main points of feedback in a way which I'm happy with and makes the game more challenging (including vertical wrapping was an afterthought anyway).

Thirdly, there were players who had trouble finishing the level, and felt the steering speed was too slow to be able to avoid obstacles effectively. The only thing I have changed to address this is to increase the camera offset so that the player's projectile sits closer to the left edge of the screen as opposed to the middle - giving players more time to see and react to oncoming obstacles. However the relatively slow steering is intentional and forms a core component of the game's difficulty. In fact, at later stages of the game I intend for the player to be able to spend some money to launch a missile instead of a regular asteroid, with the missile having the advantage of more responsive steering.

Finally, the insufficient indications of how fast the player is going. At this early stage, there are no background and no decorative foreground objects to orient the player in the level. Something like this will be implemented, alongside certain visual and sound effects to not only show to the player that they are travelling quickly, but to make the buildup and maintenance of speed feel satisfying.