Analysis Paralysis
Haven’t coded anything in over two weeks now…I’m got hung up on this object parsing stuff. More new questions keep popping up than answers, and I don’t feel like I’m any closer to movement on it than I was two weeks ago. Pretty sure I’m gonna have to use my phone-a-friend on this one. Object parsing, for the uninitiated, is the algorithm that takes an “object spec” and turns it into a collection of matching objects. It’s kind of like the path expansion stuff I did a few weeks ago, only that takes a file spec and turns it into a list of matching files. While this does make the Unix shell friendlier, most commands out in the world operate on objects, not files. Filename is definitely one way to refer to an object, but you could also refer to it with an alternate syntax, like “cat” for id, “Spot” for name, or a custom specifier, like “here:i3” to mean the third item in the command giver’s environment.
At the time I became a wizard, the most widely used object parser was the one build into the Binford Wiztool. There were some earlier wiztools that provided their own standards, but none as powerful as what the BW spec offered. Most wizard commands in the modern EotL use Acme’s OPIE (Object Parser Interface Engine), which is actually a facade for a number of actual object parsing implementations, the most notable of which are a port of the BW parser, and a new parser provided by Acme (Acme Ospec). This unified interface made it possible for wizards to share command objects, while being able to configure their own preferred object spec. This modularity never made it out of the realm of wizard commands, unfortunately. The majority of player commands (both those built into the body and those provided by the world) hardwire their own logic for parsing command line arguments. This is changing in the Gabbo lib, any command that operates on objects should be running its arguments through this new object parsing system. This isn’t to say players will have to learn some complicated object spec just to look at an object; we can adopt a more natural language spec for when someone is running in player mode, like “sword in backpack” versus “backpack:sword”.
Of course, players may get used to the more technical specs they use while in author mode, and prefer to continue using that syntax even in player mode. Is this okay? To what degree should the player be able to control how objects on his commandline are being parsed? Is it ever appropriate for me, as a user, to change how objects are searched as targets for a command? Or should the command have tight control over the types of things coming back to it from a search? How does this actually affect how we’d code something, for instance the tell or look commands? Tell is different than most commands in that it can target people in other rooms. Look is different because you can look at all the room detail descriptions but those don’t resolve as distinct LPC objects.
For OPIE, Zamboni used this idea of “priorities”, but I don’t know if I like it. Basically, the client when it passes the ospec to the parser can specify an ordered list of “priority” tokens to say things like “search the command giver’s current environment, then the rest of the mud”. That feels somewhat constricting, though. What if, temporarily, a player wanted to search for objects using a context that was runtime dependent? As a crazy example, let’s say I coded a camera, that the members of a group could wear and broadcast its video to the rest of the group. So then, for a time, I wanted to make it so that the look command could be used to target any object in any of their environments while these cameras are being worn. What say does the client command and the player have in that whole transaction?
Another knot in this board is figuring what I want from the help system. In my head I have this fantasy where a player knows exactly what help arguments to specify, and when the help page comes up they can tell what a command does, what it operates on, how arguments are specified, what’s providing the command, in what contexts the command is sensible, and anything else that helps them decide what to type next. Still another question: depending on how we implement privacy controls, what role does euid have to play in the internals of the object parsing framework?
Trying to code for all these scenarios would, of course, be crazy overengineered for what we’re trying to do with the game right now, but this is one of those interfaces that could be difficult to change later if done wrong. I should just put in a stub and move on to something else, but even a simple stub requires me to make some determination about what parameters should be passed from the client to the parser. Varargs makes things a little better in that regard but I still don’t feel great about it. Mostly I just wish I had my head wrapped around this thing a little better before I code anything.