Giving players a reason to return to levels

#1

I think it would be cool if players had a reason to return to levels once they have more abilities. There could be objectives that can only be accomplished with certain skills. Obviously we’d need to have a way to not confuse basic players with those goals when they are unachievable, maybe if the goals changed based on the items that the player has in his inventory. Then on the map screen there could be an indication if all currently achievable goals had been met. Or maybe they aren’t actually goals that ever show up, just things that are on the map but unreachable so a player has to remember to return to the level. (Possibly a note when you first gain an ability that allows a repeat about the possibility to improve an earlier solution.) Here are a few examples that I thought of:

The construction hammer could start with only the ability to build fences. Then at some point you pick up instructions for the fire-trap that you equip along with the hammer, or possibly it is just an improved hammer. Winding Trail & Kithgard Gates are examples where the hero can escape by just building a fence, but later return to build fire-traps and actually defeat the enemies and earn the bonus. I’m picturing maybe having a hero in a cage in Kithgard Gates so if you defeat all the enemies you unlock a new hero.

Another use of fire-traps could maybe be to blow up a section of a wall opening a passage to something.

I could also see maybe some of the really early levels having a spot that you can’t reach with simple movements, but once you get the moveXY boots you can get to them. (or if you realize that you can use moveRight(3).

Oh, and maybe an enemy on an early level that you don’t know the name so the only way you can kill him is by having the glasses to get the name of the nearest enemy. For example on “True-Names” there could be a bonus objective hidden behind the Dungeon Door that requires killing a nameless enemy.

Ooo, what about a level that has an enemy that is across a chasm so he can only be killed from range, or even a target that when hit from range drops a bridge so a player comes back when he has a bow.

I guess probably most levels could have some form of a hidden objective that gives players a reason to return once they have more abilities.

#2

I like all these ideas, but I’m worried that even if you don’t list the goal, if it looks like there should be something else you should be able to do, players will get stuck trying to do it before it’s ready. After we have time to introduce the mechanic of being able to go back and do bonus objectives in earlier levels, then it will make sense, but before then, players will be confused.

One idea is to put these things in the earlier levels, but hide or deemphasize them if the player is missing certain capabilities. So an extra nameless enemy could be invisible if the player doesn’t have findNearestEnemy in her API.

#3

Could the enemy only be hidden if the player doesn’t have an item that grants findNearestEnemy? That way if they haven’t equipped the item, but they do possess it, the bonus objective is still there?

#4

What if the goal on a level was something like these:
“Return with better weapons to rescue Reynaldo”
“Return once you can build a bridge to the treasure chest”
“Return once you can blow a hole in the wall to rescue Thaktor”
“Return to release the prisoners once you can shoot a bow”
“Return once you have found more armor and can survive the gauntlet”

#5

That could work, but the current goal interface will explode if we make goals that are that long. Maybe we can work out the wording, though, or tweak the goal view UI. I’ll work on it.

#6

A potential simpler method might be to use the current system of the player receiving a reward for completing the code in under a certain number of lines.

This would mean that as players learnt new and more efficient methods of solving problems, they would go back to earlier levels in hopes of getting the same end result but with less lines as they gain tools for their toolbox.

However this would require levels being designed in such a way that meant that they were flexible for players to improve on the lines of code used and would be hard to implement.
Just thought like sharing my thoughts.