We’ve talked so far about goals mostly in terms of specific objectives which you’ve placed in specific places for the character to reach. But what if the systems in your game interact in such a way that the player ends up needing to do something which you did not specifically design or anticipate.
First of all, something I want to address. As the designer, even if something emerges from the system rather than being explicitly put there, you still can have some awareness of it and anticipate common (and uncommon) emergent events that are possible from your system. You can have an overall awareness of the possibility space defined by your ruleset, and thus most emergent objectives can be prepared for. You might not know exactly when they will emerge, but you can have a good idea of what they’ll be when they do.
For instance, if you put an ammo system in your game, you can expect that a potential situation that might emerge is the player running out of ammo. At this point, their goal is to find more ammo.
Knowing this, you can create challenges around goals which the player may or may not need depending on the circumstances. The way these differ from optional challenges is that, in certain situations, they cease to be optional, and become necessary for the player to make progress.
Early on in Super Metroid, there’s a series of rooms where the goal is a device that will refill your missiles. Blocking the player’s progress is a door which must be opened with missiles. If you are at full missiles, this side-challenge is basically useless to you. If you aren’t at full missiles, it gives you a small reward but is all-together optional. If you don’t have enough missiles to open the door, this challenge becomes a necessity.
One of the largest examples of this sort of design is the curse mechanic in Dark Souls (before they patched an easier solution into the game). Some enemies inflict a “cursed” status ailment. If they manage to completely curse you, you are at half-health until you can become uncursed. There were only a couple of ways to do this and they both involved massive treks through dangerous areas with only half health. The player had been given an goal through a system in the game, and the designers put that goal behind obstacles. The designer doesn’t know that the player is necessarily going to be cursed, but they know that if the player does get cursed, they’re going to have a challenge ahead of them.
The moral of this story is that, as the designer, you should be aware of the needs the player might be given by the system you’ve designed. You can use this awareness both to insure that the player never gets completely stuck by making what they might need available to them, and also allows you to create challenges around those needs.
As a final note, this also accounts for the level-design feature of the “boss fountain”. This means either putting a lot of items up right before a boss, or putting an object that spawns a constant stream of low-teir enemies which drop items, so that the player can replenish their stocks before a major fight. Remember, you might not know what exactly the player needs at any given time, but you know the sorts of things the player will need in general.