I'm finally ready to admit that this project has died. Don't despair, though! We're simply starting over.
Python's freeform nature and rapid development was enticing at first, but it has simply become too hard to maintain. We're migrating to C# and the .NET framework, and embracing a web interface over supporting telnet. Keep up to date at the new site.
Sunday, July 26, 2009
Sunday, January 27, 2008
Update
James and I took a short (okay, long) break starting in the middle of December, but we're easing ourselves back into work now. We took a peak at the combat system last week, and realized that the Combat class at some point had been completely gutted (most of it was missing, and one function simply stopped halfway through). So, we rewrote it. Combat theoretically works now, I believe, or at least it's getting there. The problem is that the "fight" command from the old ScriptManager framework no longer exists. Once that's written we can reimplement spawning.
Hey, and then, maybe we can get started on new content! Hurray!
Hey, and then, maybe we can get started on new content! Hurray!
Monday, December 17, 2007
Parsing, redux
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.
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.
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)