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!
Wednesday, November 28, 2007
Parsing, Schmarsing
(Hi, I'm James, and I'm one of the developers on PyMUD. I had Steven add me to the blog so I could insert my occasional quips about why Python is awesome, Steve Jobs needs to stop wearing blue jeans, and occasionally update on the project's progress)
Who would've thought writing a MUD would involve so much parsing?
Parsing user input to commands. Parsing world data. Parsing configs. It kind of just exploded, and soon we ended up with a 1000-line parsers module to handle the world and items XML. It got to the point of being so scary neither Steven or I wanted to touch it. Finally, we've begun cleaning it up, and I've already cut off nearly 250 lines. But hey, at least it's Python. I don't even want to think what this amount of parsing would've been like in a non-dynamic language.
After more than a year of quiet, we're finally advancing towards our Alpha 3 milestone. Items are functional for the most part, but the major stopping point before release is having a character class system. The code cleanup task is helping us get familiar with the code again, fix any bugs we may happen to run into, and prepare for the class / ability system.
Addendum by Steven:
As James pointed out, the parsers are probably one of the most important parts of the PyMUD system. We have an entire (huge) parsing module dedicated to extracting Object (NPC, Ability, Room, Item) data from the game's XML scripts. This is the one he was referring to. In addition to the sprawling XML parser, we have more parsers for user input and for parsing server configuration files. The latter is easy, more or less. The former is one of the more complex aspects of the system, and actually forms a basis for the entire NetChat Py-Client.
Both crucial parsers work fine in their current form, but they're becoming a bit of a mess to manage. Both need to be looked at a little more before we're comfortable plunging onward into the wilderness that is new content.
Who would've thought writing a MUD would involve so much parsing?
Parsing user input to commands. Parsing world data. Parsing configs. It kind of just exploded, and soon we ended up with a 1000-line parsers module to handle the world and items XML. It got to the point of being so scary neither Steven or I wanted to touch it. Finally, we've begun cleaning it up, and I've already cut off nearly 250 lines. But hey, at least it's Python. I don't even want to think what this amount of parsing would've been like in a non-dynamic language.
After more than a year of quiet, we're finally advancing towards our Alpha 3 milestone. Items are functional for the most part, but the major stopping point before release is having a character class system. The code cleanup task is helping us get familiar with the code again, fix any bugs we may happen to run into, and prepare for the class / ability system.
Addendum by Steven:
As James pointed out, the parsers are probably one of the most important parts of the PyMUD system. We have an entire (huge) parsing module dedicated to extracting Object (NPC, Ability, Room, Item) data from the game's XML scripts. This is the one he was referring to. In addition to the sprawling XML parser, we have more parsers for user input and for parsing server configuration files. The latter is easy, more or less. The former is one of the more complex aspects of the system, and actually forms a basis for the entire NetChat Py-Client.
Both crucial parsers work fine in their current form, but they're becoming a bit of a mess to manage. Both need to be looked at a little more before we're comfortable plunging onward into the wilderness that is new content.
Friday, August 31, 2007
Okay, I'm serious this time
Honest. I'm installing Ubuntu for the sole reason of providing myself with a comfortable developing environment. James and I have been brainstorming for a week, and are ready to finally tackle the behemoth that is old, bad code, idling away for over a year now. After a weekend of cleaning, development will get back on track.
Thursday, March 01, 2007
Dead? Of course not!
How can I be? Still working on that feature!
Yes, I know I'm not funny.
This project is by no means dead, it's just hibernating. James and I are going to get right on it as soon as class simmers down a little. Worry not, my loyal readers!
Not that I have loyal readers, but I do like talking to myself.
Yes, I know I'm not funny.
This project is by no means dead, it's just hibernating. James and I are going to get right on it as soon as class simmers down a little. Worry not, my loyal readers!
Not that I have loyal readers, but I do like talking to myself.
Subscribe to:
Posts (Atom)