No art, no animation, no physics. A text adventure is pure content and structure, which makes it an excellent project for focusing on writing and data design.

1. Rooms, items, and state

A room has a description, exits to other rooms, and items. An item can be taken, examined, used. The world is data; the engine is small.

text-adventure.txt
Build a text adventure engine. World defined in JSON, not code.

- Rooms with descriptions, exits, and items.
- Items with descriptions, whether they can be taken, and what using
  them does.
- Player state: current room, inventory, flags for things that have
  happened.
- A parser handling: go/n/north, take/get, drop, look/examine/x,
  use X on Y, inventory/i, and help.
- Unknown input gets a helpful response naming what it didn't
  understand, not "I don't know that word".

Then show me how I'd add a puzzle where an item unlocks a door.

2. The parser needs to be generous

The classic frustration is knowing what to do and not knowing the phrasing. Accept synonyms freely — examine/x/look at, take/get/pick up. Ignore articles. Handle abbreviations for directions.

When it genuinely doesn't understand, say which word was the problem. "I don't know how to 'frobnicate'" is far better than a generic refusal, because it tells the player the rest of their sentence was fine.

3. Flags for everything that happened

A single state object of named flags — hasKey, doorOpened, metTheOldMan — is how puzzles work. Conditions check flags; actions set them.

Keep it flat and named clearly. This is the part that becomes unmanageable if you improvise it.

4. The writing is the game

The engine is a weekend. The game is the descriptions, and they're what people remember. Every room should reward examining things that aren't puzzle-critical.

Watch someone play and note every command they try that fails. That list is your synonym table, and it's the difference between charming and frustrating.