Apple Game Frameworks and Technologies: Distance calc could be simpler for this point of the book (p 54)

The very top line of page 52 is let distance = hypot(pos.x-player.position.x, pos.y-player.position.y). As the text below the code snippet explains:

This code uses another built-in function, hypot(), and some math to calculate the speed value based on where the player node is currently located and where it’s headed. The hypot() function uses a bit of trigonometry to calculate the distance between the two points.

The two points in question are the player sprite’s position and the position you tapped on. hypot is taking the 2d distance between the two points, but the player sprite is constrained to only move horizontally – on a single dimension. We could easily compute the distance along only the x axis.

The use of hypot adds some complexity and introduces a subtle bug to the movement. If you tap one inch to the right of the player sprite on the same Y level as it (so on the platform just right of it) the sprite moves over at the speed we expect. But if you tap one inch right of the player sprite, but at the top of the screen, then the sprite moves over much slower than the previous time. That’s because the diagonal from the player at the bottom of the screen up to the top of the screen is longer than the straight line distance when we tapped just to the right. This longer distance computes that we need more time to move that far. But since we are constrained to moving only along the X axis we end up moving the same distance either way. Just faster one way versus the other.

At this point in the book it might be simpler, easier to understand, and more accurate to just compute the distance with:

let distance = abs(pos.x - player.position.x)

3 Likes

Hi, David.

Thank you for the suggestion.

I considered using that simpler solution as I was writing this chapter, but I ultimately decided to use the one you see in the book. I did so for the following reasons:

  1. The variation in speed when tapping on the platform versus tapping above it is marginal. Actually, most players probably wouldn’t notice the difference. I’m impressed you caught it. :grin:

  2. Later in the book, the player controls are modified to use an attached controller-knob (for lack of a better term), which also removes the ability to tap the screen to move, consequently removing the minor speed consistency issue.

  3. Readers will likely want to apply this technique to their own games, which may include a character that has a full range of motion. That being the case, I wanted to use this solution, here, because new developers may not know about the hypot() function whereas the abs() function is more common. To be honest, this reason was the primary motivating factor.

After reading your comment, I considered adding a note somewhere about using abs() as an alternative, but this being an already complex topic, I don’t want to muddy the waters. I may, eventually, add a note, but for now, I’m going to leave it as-is.

Thanks again for all of your recent comments. I appreciate your help in making this book a valuable and acurate resource.

2 Likes