Having implemented most of these at some time or other, I see this as an interesting challenge that could help authors expand their collection of snippets for possible future use.
The initial list of ideas does seem a little biased towards parser-based games, but that doesn’t mean that choice-based authors can’t attempt it and vice versa.
The only thing I’d suggest is that each challenge should have a set of requirements (just as in software development) so that anyone participating knows exactly what’s required. As an example:
- Implement a rope.
- The rope is a portable object, so it can be picked up and dropped.
- The rope can be tied to an object and untied from the same object.
- The rope can only be tied to tieable objects.
- Tieable objects can be fixed in place or portable.
- The rope conceptually has two ends.
- If a rope is tied to an object, then that leaves the other end of the rope free.
- If one end of the rope is tied to an object that is fixed in place:
- The player can hold the other end of the rope or drop it.
- When holding the other end of the rope, the player can move to an adjacent room.
- When holding the end of the rope in an adjacent room, the player can return to the original room, but cannot move any further away without dropping the rope.
- If the rope is tied to a portable object:
- The player can hold the tied object and/or the other end of the rope or drop either.
- If the tied object is held, then both the object and the tied rope move with the player.
- If the other end of the rope is not held when the player moves, then the other end of the rope is left behind.
- If the other end of the rope has been left behind, the player can return to the room with the other end of the rope and it will still be there. Alternatively, the player can move to a different room and the other end of the rope will drag behind so that it is now in the room that the player just left.
- If the player is holding the end of the rope, but not holding the tied object and the player moves, then the behaviour is the same as above, except that the tied object and the end of the rope are reversed.
- The second end of the rope can be tied to another tieable object in the same room as the first tied object or an adjacent room.
And so on.
I’m not even sure if I’ve captured what you had in mind, hence the importance of clear and explicit requirements. I think the requirements should also specify the grammar to be used (for parser-based games) and whether implicit actions are to be implemented. For example TIE ROPE TO POLE and TIE POLE WITH ROPE should probably be synonymous, but if the player types TIE ROPE, should it implicitly deduce that it’s the pole that’s to be tied? Similarly, if the player types TIE POLE, should it implicitly deduce that it’s to be tied with the rope?
As you can see, even writing the requirements is a challenge. Having implemented several ropes (including a variation of this one), I can assure you that ropes are a real challenge, so it’s interesting that this was the first one on the list.