Zork: http://almy.us/image/dungeon.jpg http://www.thezorklibrary.com/zork123.php | Beginners' IF: http://ifdb.tads.org/viewlist?id=3qb4ujaf5nqz5mp8 http://ifdb.tads.org/viewlist?id=dqbqekz1zkxw5u1 (Play On-Line in the top right)
modifiers
still feels clunky, but it's an easy way to see what custom fields need to be examined and used. common_objects
is mostly so items can be grouped (modifier: [groupable]
) (imagine the rose
has that) in inventory without full comparison of the object. I don't know how we should handle groups with members of disparate states. Probably just keep them ungroupable. Also, this should be able to keep game state in a separate (YAML?) file that's pretty much a delta so we don't have self-adjusting worlds. I don't think we'll need to be adding new rooms dynamically in game. :)
data
could probably hold default player state and beginning info too now that I think about it
description
, but instead be objects with a path
modifier. Rename description
to desc
and add a shortdesc
for visible
(modifier) objects? Then paths would just be objects. Add nodesc
modifier and you're all set for having it act like normal.
paths
array would then hold directions -> objects, and you'd get automatic ensurance of locked doors staying locked and the player not being able to bypass them by doing a different command. Should be simpler. Then path
in the object gives the room.
type
. modifier
s seem more composable...
yaml
locked:
key:
to: unlocked
under the consume state transformation listing
format
-friendly strings, and proper state changing