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?
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?
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.
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.