Currently, the state of complex commands like "get", "put", "drop", and "get" (not yet implemented) are terrifying.
That's not even to mention something like the old administrative command "bring".
The reason? Parsing.
Yes, more parsing.
The goal of PyMUD commands are to be as intuitive (in terms of English) as possible, while still maintaining ease of use.
For example, the commands "bring me to the town forum in canticett" is English. It is not easy to use.
"bring me to forum in canticett", the old implementation, is a little less English, a little easier to use, and infinitely more easy to parse.
The problem arises, however, when you try to create intuitive alternatives to a given grammar.
What if, instead of bringing me to a room in a zone, I want to be brought to a player? What then? Why shouldn't "bring me to charlie" work?
It should, or I'm not a PyMUD developer!
The issue here is that "bring me to <room> in <zone>" makes a few assumptions. First of all, that "bring" is followed by "me to", and at some point, the word "in", with two phrases flanking it. That latter part is completely ignored by "bring me to <player>".
Furthermore, what if I want to "bring charlie to forum in canticett".
And what if I want to bring a specific Item, by its unique ID tag, to the location of a specific Door, by its unique ID tag? "bring 35 to 982"?
The plot thickens!
As you can see, this only addresses one command, not even 1/2 of the list up top.
The solution?
Pyparsing!
Pyparsing lets me specify grammars, even incredibly loose grammars like the example above, and in a few lines extract the subject, target, whether it's a Room or a Mobile or what-have-you, all without so much as breaking a sweat. At first I wasn't sure if it was suited to our needs, but the swell guy behind the project was able to point me in the right direct.
This has been a public service announcement.
Monday, December 17, 2007
What a twisted web we weave
No, "twisted" is not a pun. Go away.
As of yesterday, almost all of The Cleaning Fire (tm) has burned its course. We discovered that the "CoinStack" Item in "currency.py" has not yet been visited or scheduled, so it was added to the docket. Aside from that, all that remains is the entirety of "mobiles.py" (cue lightning crash and frightening music).
The problem? The file is a twisted (again, no pun) mess of code. There is little documentation, circular references probably abound, variables are badly named, and code is hacked together.
Tuesday, we vow to fix this, and real progress shall begin anew.
In short:
- Rooms, Zones, Items, Entities (prev. Objects), the World, Bags, Openables, Containers, Exits (merged with Doors) are all clean.
- Mobiles, NPCs, Players, Corpses, EquipmentModels, CoinStacks have yet to meet the flame.
BY FIRE BE PURGED!
In completely unrelated news, I have a potential summer job as well as a potential scholarship for next year, so things are looking slightly brighter than they were yesterday. We'll see how those applications turn out!
As of yesterday, almost all of The Cleaning Fire (tm) has burned its course. We discovered that the "CoinStack" Item in "currency.py" has not yet been visited or scheduled, so it was added to the docket. Aside from that, all that remains is the entirety of "mobiles.py" (cue lightning crash and frightening music).
The problem? The file is a twisted (again, no pun) mess of code. There is little documentation, circular references probably abound, variables are badly named, and code is hacked together.
Tuesday, we vow to fix this, and real progress shall begin anew.
In short:
- Rooms, Zones, Items, Entities (prev. Objects), the World, Bags, Openables, Containers, Exits (merged with Doors) are all clean.
- Mobiles, NPCs, Players, Corpses, EquipmentModels, CoinStacks have yet to meet the flame.
BY FIRE BE PURGED!
In completely unrelated news, I have a potential summer job as well as a potential scholarship for next year, so things are looking slightly brighter than they were yesterday. We'll see how those applications turn out!
Thursday, December 06, 2007
From the Fire, Life
The great purge has begun. It took about two hours to sweep through two classes.
There are fourteen classes to go.
Long story short: "World", as well as "Zone", and all of their dependencies, have been examined, literally, line by line. Anything questionable, anything vague, anything confusing was either removed, renamed, rewritten, or clarified.
It's going to be a long week.
There are fourteen classes to go.
Long story short: "World", as well as "Zone", and all of their dependencies, have been examined, literally, line by line. Anything questionable, anything vague, anything confusing was either removed, renamed, rewritten, or clarified.
It's going to be a long week.
Wednesday, December 05, 2007
One step forward, Two steps backwards.
If you've ever written code, you probably are loathing that piece of code you wrote several years back which you forgot about, but someone pops up and asks you to maintain. Sometimes PyMUD is like that. It's like a shiny car when you look at it one way, then notice the interior's falling apart. After making a major breakthrough with the object ID system, starting a new ORM-based persistence layer for our data, and converting a bunch of commands into abilities, we were feeling pretty svelte. Steven logged onto my machine for some ability testing, and the results were pretty positive.
But one straw broke the camel's back.
It was a pretty simple thing, actually. In implementing "yell", we traverse all open doors to any rooms within a certain radius. So what better to do than to check door.closed ? Obvious, right. Why would we make such an obvious property than to put a boolean True if it's closed?
Of course, it didn't work. Debugging through the code and printing out nearly everything I could, I finally found the problem. door.closed was a string. Where was the boolean we knew existed? door.opened, of course. door.closed is what we show to the user when the door has been closed, meant to be customizable per-door if we want to allow for flavor text. Upon inspecting the Door class, we found several other poorly named properties.
And so, we begin the Great Cleansing Fire. Before we tackle the character class system, we will revisit every class, documenting, removing un-needed properties, and trying to rename things to fit. It's going to cause a good bit of break&fix debug cycles, but it will be worth it in the end.
But one straw broke the camel's back.
It was a pretty simple thing, actually. In implementing "yell", we traverse all open doors to any rooms within a certain radius. So what better to do than to check door.closed ? Obvious, right. Why would we make such an obvious property than to put a boolean True if it's closed?
Of course, it didn't work. Debugging through the code and printing out nearly everything I could, I finally found the problem. door.closed was a string. Where was the boolean we knew existed? door.opened, of course. door.closed is what we show to the user when the door has been closed, meant to be customizable per-door if we want to allow for flavor text. Upon inspecting the Door class, we found several other poorly named properties.
And so, we begin the Great Cleansing Fire. Before we tackle the character class system, we will revisit every class, documenting, removing un-needed properties, and trying to rename things to fit. It's going to cause a good bit of break&fix debug cycles, but it will be worth it in the end.
Tuesday, December 04, 2007
"Exciting New Stuff": Part 1
So, today, we decided it'd be grand if instead of this experience-breaking Object ID garbage:
(ie: "a city guard" <--> "npc#canticett_guard#52"),
that instead, the world itself should maintain a global instance tally. This effectively "tags" every single object, be it room, NPC, item, door, with a unique indentifier in the form of an integer. This allows for a lot of neatness without forgoing the practicality of tracking each object with a unique code; only in this case, the code is now a digit instead of an esoteric string. Using the idroom commmand will now yield something like:
A city guard (28)
Instead of
a city guard : npc#canticett_guard#28
And can be targetted precisely with the shortcut "28", as in, "examine 28". Neat, or so we think.
(ie: "a city guard" <--> "npc#canticett_guard#52"),
that instead, the world itself should maintain a global instance tally. This effectively "tags" every single object, be it room, NPC, item, door, with a unique indentifier in the form of an integer. This allows for a lot of neatness without forgoing the practicality of tracking each object with a unique code; only in this case, the code is now a digit instead of an esoteric string. Using the idroom commmand will now yield something like:
A city guard (28)
Instead of
a city guard : npc#canticett_guard#28
And can be targetted precisely with the shortcut "28", as in, "examine 28". Neat, or so we think.
Monday, December 03, 2007
The Unspeakable, Agonizing Pain
So, I'm almost done porting old-style commands to new-style abilities. At the time of this writing, I just finished "get", "drop", and "put", the most nightmarish of the bunch. There's not really much to say, but this is basically the hump of busy-work being crested. Exciting new stuff is soon to come!
Subscribe to:
Posts (Atom)