6
\$\begingroup\$

Prompt

Suppose we have a little mini-game where you have to avoid incoming obstacles by moving the blob up and down at a constant speed. The blob's x coordinate is fixed and the obstacles will spawn from the right edge of the screen.

The obstacles may vary in size, speed, starting height, spawn interval, angle, etc. (they can overlap). But let us work with just varying height and speed for now. My question is:
If I were to generate the next obstacle with randomised starting height and speed, how can I make sure that the player can still avoid everything?

enter image description here

Example

In the image above, suppose the blob's speed is enough to move him up towards the gap near the top before the obstacles reach his x coordinate, but he's not fast enough to reach the bottom gap in time. So given the current set of obstacles, the blob should move himself towards that gap (possibly with a bit of leeway before the obstacles will actually reach him).

Now consider the next obstacle spawning at the same height as the gap.
This is fine since the blob can still move up or down immediately after getting through the first set of obstacles. But suppose we are unlucky and the random difficulty setting makes it so that the new obstacle is twice as fast and will reach the blob's x coordinate at the same time as the first set of obstacles. Then the whole set of obstacles is regarded as impassable with respect to the blob's current position.
In particular, how can we determine that the first case is OK while the second is not?

Attempt

Intuitively, I am imagining a "live zone" that updates itself as the obstacles move. The live zone defines a (set of) range along the blob's vertical axis in which he can be in at any given point in time in order to make sure that he can avoid the obstacles. By definition, blob must always remain within the zone, otherwise, we will hit an obstacle no matter what. In a sense, the live zone "zooms in" on spaces without an obstacle.

In the above example, we have 2 zones near the top and bottom gaps.

  • The zone narrows as the obstacles approach the blob. The narrowing rate depends the relevant obstacles' speeds.
  • The fact that blob cannot reach the bottom gap in time can be demonstrated with him having to leave the zone he's in.

enter image description here

Let's call part of the live zone that blob is in an "active zone". The goal is then to make sure that the active zone is always non-empty and that it is always possible for blob to stay within that zone. If a new obstacle removes the active zone, we can stop it and let it pick a different settings for the new obstacle. But how would I go about implementing this or is this approach feasible in the first place?

  • Some parametrisation of the obstacle's position based on time or their x coordinate?
  • If we squash the x axis into just a line corresponding to blob's x coordinate, then the live zone is just the complement of the union of all the obstacles.
  • What if there really is no next valid obstacle? No, this cannot be the case since we can just repeat the last spawned obstacle, provided we started with a non-empty active zone.
Improve this question
\$\endgroup\$
6
  • \$\begingroup\$ You can make it work if you go another way. Keep track of obstacles, not blob position. You should spawn obstacles in regard to the closest obstacle that has already been spawned. You have to make sure that the new obstacle is possible to pass after the spawned obstacle or if it's faster otherwise if it's possible to pass current obstacle after the new one. But you should always consider the obstacle that was even before the current one if the new one will have greater speed. Because again, you will need to spawn it in the way that it is possible for B to pass it considering that previous one. \$\endgroup\$
    – Candid Moon _Max_
    Oct 14, 2017 at 23:48
  • \$\begingroup\$ I think that in practice most games like this either just use fixed levels or if there's randomness at all, they use a (relatively) small amount of known passable waves with a blank space which gives the player enough time to get back into the "live zone" when the obstacles start up again. You may have good reasons not to resort to "cheap tricks" like that however. \$\endgroup\$
    – Ryan1729
    Oct 15, 2017 at 5:22
  • \$\begingroup\$ @CandidMoon Ok, so we could work it out and break things down in different cases, but how would I generalise it? \$\endgroup\$
    – Little Pillow
    Oct 15, 2017 at 5:29
  • \$\begingroup\$ @Ryan1729 I understand the appeal and, at the moment, I just tweaked the numbers until it feels "hard enough", so in the end, the game still works to some extent. Then I got to the point where you are not sure if the difficulty settings are allowing impossible situations or if I'm just not good enough. Thanks for the tag improvements! \$\endgroup\$
    – Little Pillow
    Oct 15, 2017 at 5:35
  • \$\begingroup\$ @Ryan1729 I've been thinking and will clarify what I meant a bit with the zone. Originally, the idea is that if blob finds himself outside of the zone, he's doomed, there's no catching up. If there's no obstacle on the screen, then the live zone is the whole of y-axis. If suddenly there's a new set of obstacle covering the bottom half of the screen, the zone is still the same at first. But as the obstacle moves closer, the live zone shrinks from bottom up. This zone's lower bound is the catching up. But then your comment got me thinking again; what if blob's speed > obstacle's speed? \$\endgroup\$
    – Little Pillow
    Oct 17, 2017 at 17:17

1 Answer 1

Reset to default
4
\$\begingroup\$

If the blob has a constant vertical speed, and you know the horizontal speed of the incomming objects, you can use those variables to calculate the minimum and maximum angles the blob can travel to at most in that time frame.

If you then calculate the distance between every two waves of obstacles, you can use that to find an angle that the player can actually travel to in time.

Hopefully this helps

Improve this answer
\$\endgroup\$
2
  • \$\begingroup\$ By angle, do you mean the range along the y-axis that the players can move to? OK, allow me some time to think about this and consider some examples. \$\endgroup\$
    – Little Pillow
    Oct 17, 2017 at 17:30
  • \$\begingroup\$ Yes that's what I mend. With those angles you can calculate the maximum vertical distance the blob can travel in between waves of obstacles \$\endgroup\$
    – sjoerd216
    Oct 18, 2017 at 5:59

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .