Testing the Teleport
|
Extending last week’s post, the teleport is being developed further in our 2D shoot ’em up game. First, the implementation of the teleport was fixed. Unity’s rotation axes don’t use the Cartesian Axes reference point, but starts on the positive y axis instead. The teleport now uses basic trigonometry to calculate the radius from the player and confines it to the maximum radius, set in the inspector. We had also begun playtesting the teleport. The lack of any indication of the maximum teleportation distance made it unclear where you’d end up, as a player, after teleporting. Our initial solution was to have a shadow of the player appear where they would be repositioned to, when holding down the teleport button, only to teleport when they released it. Us developers now found it easy to predict the relocation of the player. Game testers new to the game found it unnatural to hold down the teleport button before initiating the teleporting action. We made the design decision to keep an indication present at all times and keep the shadow as an extra feedback, coupled with the effect of the player replacing the shadow and gradually becoming opaque. To address the limited indication, we decided to repurpose the crosshair to convey the teleporting distance by confining it to the teleporting radius. The mouse could still move anywhere on the screen and the absolute position was difficult to ascertain. The issue was solved by adding a second crosshair, which showed the mouse’s position on the screen. It was made into a smaller size, and rotated 90 degrees to provide it with distinctive features and a different appearance when overlapping with the other cursor. In order to assist the player track both crosshairs simultaneously, the larger would be closer to the player and be intended for the teleport and the smaller would represent the mouse’s position on the screen and be intended for aiming. The player’s shots reference the lantern, the front end of the broom, whilst the teleport references the player’s center causing the shots to diverge from the teleport’s crosshair and disorienting the player’s aim when shooting. Aesthetically, it seemed to clutter the screen, the larger crosshair felt obtrusive and the smaller crosshair felt irritating . We backtracked and went with one crosshair within the teleportation radius, this time using the mouse’s relative position, or velocity in other words. If the crosshair was at the maximum radius, it wouldn’t register any movement further than that and as soon as the mouse was moved in the opposite direction it would start moving in that direction. It provided the player with the ability to teleport and quickly adjust their fire from the new position. However, the aiming felt counterintuitive with the mouse, reducing aim and requiring non-stop concentration. We saved the code for the, hopeful, intent of supporting other forms of input. Once again, we returned to a previous concept, slightly altering some of the design choices. Instead of the large crosshair being used to teleport and the smaller crosshair to aim, we inverted them and changed the color of the smaller one. The result can be seen in the image. Player’s instinctively used the large crosshair to aim and laid notice to the smaller crosshair in their peripheral vision. A minor issue regarding the cooldown popped up. The player had no indication when they could teleport again. Through scripting effects, the crosshair vanished when activating the teleport ability, reappeared a short amount of time before it would be ready to be used again and made a full rotation before ending the cooldown. A scaling effect was also later added to the end to make it stick out and attract the player’s attention the instance before becoming ready. In some cases the player would want to teleport as soon as the teleport was ready to be used again but would release the button a few frames prematurely and end up getting damaged. To prevent that from happening we flagged the input and teleported the player once the teleport became ready. In conclusion, the teleport went through different forms, rules and variations before we decided on the interpretation shown in the image and previously described before it became intuitive enough to be implemented as a core mechanic. Playtesting had an enormous impact on the final outcome, not only that of third party testers’, but that of the developers’.  |
