On Thursday this week, we had a playtest session in which people tried out the level I am currently working on. The goal was to observe people playing the game to discover pain points in the level design and the game mechanics. From this playtest, I received 8 detailed responses. The most apparent issue was that I had made the level too difficult; the distances between the grapple points were far too large. As a result, the level became much longer to complete than anticipated. The problem was that I had designed the level's difficulty around my own skill level, not around the skill level of the average player of our game. Additionally, the level’s difficulty ramped up too quickly and did not give players enough time to acclimatize to the grappling mechanic. Subtle issues with the design arose too. A few players were unable to figure out the crate on pressure pad mechanic. This was due to me applying my own affordances about crates being placed on buttons that I had developed from playing many other games. Not everyone that plays our game will make that connection. The image on the pressure pad is footprints which perhaps does not clearly communicate that the crates could be placed on the pressure pads too. Mechanically, the biggest problem is the grappling hook. This is because player’s easily lost control of where they were aiming the grapple swing, causing them to spin out of control. This causes death, frustration and makes the levels last longer than they should do. I sat down with Uncharted 4 over the weekend to analyze how this game handles its swinging mechanic without letting players spin out of control. The 3 core observations I made were:
Currently while grappling in our game, a player can hold LS forward and the forward force will not reduce over time. After a time, the player will settle in place, appearing to hover in front of the grapple point. To fix this, I had to ensure that a forward force would only be applied when the player is behind the grapple point and a backward force would only be applied when in front of the grapple point (relative to the camera). Initially, I used the player’s velocity as the normal vector (with y as 0) of a plane and used dot product to determine whether the grapple was in front or behind the grapple. However, this gave undesirable and inconsistent results. I then decided to use the cameras forward vector (with y as 0) as the plane normal and this gave much better results (assuming that the player is swinging towards and away from the camera). That swinging change worked nicely but the bigger issue still persisted; it was still too easy to spin out of control of the grapple. I tried slowing the player down by adding drag until the player’s movement direction was close enough to the input direction taken from the controller. This felt horrible. I experimented with modifying the configurable joint of the grapple to lock angular movement about the grapple to one axis. I then set the axis of rotation as the camera’s right vector (with y as 0). This gave a smooth and stable swing in which the swing direction is controlled by the camera. The changes are definitely an improvement. I let someone play the game who had major trouble with the grappling before and now they can finish the level much easier. Whether or not the grappling will continue to use the mouse to aim is not finalized, however, and will need to be determined through more testing.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. Archives
September 2017
Categories |