modifiersstill feels clunky, but it's an easy way to see what custom fields need to be examined and used.
common_objectsis mostly so items can be grouped (
modifier: [groupable]) (imagine the
rosehas 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. :)
datacould probably hold default player state and beginning info too now that I think about it
description, but instead be objects with a
descand add a
visible(modifier) objects? Then paths would just be objects. Add
nodescmodifier and you're all set for having it act like normal.
pathsarray 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
pathin the object gives the room.
modifiers seem more composable...
yaml locked: key: to: unlockedunder the consume state transformation listing
format-friendly strings, and proper state changing