* Text adventures are a case where it is really advantageous to separate the declaration and definition of objects, since cycles are ubiquitous. For C, consider X-macros, tentative definitions (not in C++, sadly), and using the section attribute to make the list implicit (or if you don't want to rely on compiler voodoo, just output the index during another pass).
* It may be useful to distinguish several ways an object belongs to a location: on top of, contained in, held by, equipped by, integral component of, death drop of. Additionally, "has never been moved [by player? by code]" is often desirable to record.
* Backwards ownership is fine for savefiles and initialization, but during runtime it can be useful to cache lists in the other direction. A dict may be worth it in a few places if your adventure gets big enough, but linear search is fine for a long time (and makes e.g. conditional passages easier; you should simply check that every conditional transition is eventually followed by an unconditional one with the same tag. To ensure conditions are handled uniformly, transitions with multiple names should canonicalize first).
* For C statically-allocated arrays within a struct initializer, we've been allowed to write `(T[]){t1, t2, t3}` for a quarter century now. There's no need to name the separate objects.
* It is very useful for the runtime to support the notion of "overlays" - used for things like menus which can use surprisingly similar logic to rooms. Saves should only ever look at the main game layer.
* Relative directions are very interesting, but tricky to add to a game.
What I wish I had was an example of a game that is complete enough to be interesting but not too big, to be used when porting to a new engine.
* Text adventures are a case where it is really advantageous to separate the declaration and definition of objects, since cycles are ubiquitous. For C, consider X-macros, tentative definitions (not in C++, sadly), and using the section attribute to make the list implicit (or if you don't want to rely on compiler voodoo, just output the index during another pass).
* It may be useful to distinguish several ways an object belongs to a location: on top of, contained in, held by, equipped by, integral component of, death drop of. Additionally, "has never been moved [by player? by code]" is often desirable to record.
* Backwards ownership is fine for savefiles and initialization, but during runtime it can be useful to cache lists in the other direction. A dict may be worth it in a few places if your adventure gets big enough, but linear search is fine for a long time (and makes e.g. conditional passages easier; you should simply check that every conditional transition is eventually followed by an unconditional one with the same tag. To ensure conditions are handled uniformly, transitions with multiple names should canonicalize first).
* For C statically-allocated arrays within a struct initializer, we've been allowed to write `(T[]){t1, t2, t3}` for a quarter century now. There's no need to name the separate objects.
* It is very useful for the runtime to support the notion of "overlays" - used for things like menus which can use surprisingly similar logic to rooms. Saves should only ever look at the main game layer.
* Relative directions are very interesting, but tricky to add to a game.
What I wish I had was an example of a game that is complete enough to be interesting but not too big, to be used when porting to a new engine.