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!
Sunday, January 27, 2008
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!
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.
Sunday, July 16, 2006
Changes ftw
Forgot to update last night.
Ok, here's the deal. I've fixed a disgusting number of bugs, removed grammatical inconsistencies, added respawning to mobs, added respawning to players, updated command stacking, added command repetition, tweaked item interaction extensively so that it's more intuitive and English, added 'all' and numerical values to the interactions, added (filled) containers to the ItemScript, modularized npcsets and itemsets (previously unique to worlds), and various other cute changes.
Yay!
Tuesday, July 11, 2006
And He's Back
Was just on a one week vacation to the Outer Banks with a good friend of mine. Consequently, I'm now hooked on Lost, but that's neither here nor there. So, hopefully this explains the week-long silence, and I just wanted to announce that I'm back from the beach and ready to rock once more!
Next on my plate is respawn timers!
Friday, June 30, 2006
Tweaks and Such
Well, I didn't make much groundbreaking progress today, but I did make some interesting changes and clean up some code. First and foremost, the 'describe' function of Mobiles is now much more efficient, opting for string formatting instead of concatenation. In theory this is better, heh. Similary I removed all 'bold' formatting from the descriptions, because I found them silly. Furthermore, I added an endurance indicator to the list of things displayed in the primary description. It ranges from being borderline conscious to being perfectly well-rested. That's it for Mobiles.
In terms of Containers, I did a little tweaking such that an indicator of how 'full' it is is appended to the end of the description. This functions like desc/desc2 in Mobiles, only it's not a separate paragraph. This trend will continue for indicators such as 'size' for other Items.
Hurray, magical!
In terms of Containers, I did a little tweaking such that an indicator of how 'full' it is is appended to the end of the description. This functions like desc/desc2 in Mobiles, only it's not a separate paragraph. This trend will continue for indicators such as 'size' for other Items.
Hurray, magical!
Corpses, etc
I'm tired, so this will be a rather summative update. Bags now work after much tweaking to internal mechanics, and basic corpse functionality has been added. Dead mobs/players will spawn a corpse that is filled with their equipment and inventory, and it will decay in 30 seconds unless otherwise specified. Trying to log out with a corpse in the inventory will result in it disintegrating.
The end.
The end.
Monday, June 26, 2006
Containers
At long last, I do think I've hammered out all the bugs. They were incredibly stupid bugs too - modifying item IDs after they were assigned, adding items to the inventory twice, the like. Whatever, containers should WORK. I added two new tickets and reopened another one though, because I'm apparently masochistic. Death needs to be implemented (correctly, with corpses and respawning), being able to put and get variable numbers of items should work, and templating needs to work with containers.
Fin.
Fin.
Friday, June 23, 2006
Zomg, change!
That's right!
Today, I made several huge changes.
Well, more additions, I guess.
First and most importantly - bags and other containers now completely work! In theory!
The only problem is that all of these changes are completely untested, as I have yet to make functionality for scripting bags! Zing!
In addition, from a code standpoint, I added more niceness. The 'player' plugin was split into another 'items' plugin, for code that deals with, well, items. Eventually some commands from 'client' will move there as well. I also added 'put' to the help doc, and cleaned up a little code. In terms of functionality, I moved a lot of code from Door back to Openable, where it was belong, tidied some stuff up, and added a Bag class that extends both Openable and Container (in reverse order). Pity Ruby can't do that. Take that Barnett, multiple inheritance wins. In addition to all this, I added obj_type filters to Container and EquipmentModel, which Room has had for a long time.
Finally, I removed all hope from 'open' and 'close' every functioning on other players. No longer can you open or close other peoples' bags with these commands... yet. I intend to add a Subtlety skill called 'target' that will allow for such features.
Over and out.
Today, I made several huge changes.
Well, more additions, I guess.
First and most importantly - bags and other containers now completely work! In theory!
- Containers are correctly stored in the database, theoretically.
- Containers are correctly pulled from the database, in theory.
- Containers can now have items put in them and retrieved from them, supposedly.
- Containers can now be looked inside of, hypothetically.
- Bags can be opened and closed, if all's gone well.
The only problem is that all of these changes are completely untested, as I have yet to make functionality for scripting bags! Zing!
In addition, from a code standpoint, I added more niceness. The 'player' plugin was split into another 'items' plugin, for code that deals with, well, items. Eventually some commands from 'client' will move there as well. I also added 'put' to the help doc, and cleaned up a little code. In terms of functionality, I moved a lot of code from Door back to Openable, where it was belong, tidied some stuff up, and added a Bag class that extends both Openable and Container (in reverse order). Pity Ruby can't do that. Take that Barnett, multiple inheritance wins. In addition to all this, I added obj_type filters to Container and EquipmentModel, which Room has had for a long time.
Finally, I removed all hope from 'open' and 'close' every functioning on other players. No longer can you open or close other peoples' bags with these commands... yet. I intend to add a Subtlety skill called 'target' that will allow for such features.
Over and out.
Monday, June 19, 2006
A Lull
So, there's been a distinctive of updates over the weekend.
I could make excuses (and I will later), but here's what I accomplished since the last post -
Item inheritance has been tidied up. That's about it. Templates can now be defined, which pass their traits to items. Additionally, templated items can pass their traits down to subitems. Sadly, my progress stops there.
Now for my rationalization!
Friday through Saturday I was busy partitioning my drive and setting up Ubuntu linux. Sunday, I worked all day, just like every week.
So there we have it!
Now I just need to work on making my wireless work on linux.
I mean, making PyMUD work. =]
I could make excuses (and I will later), but here's what I accomplished since the last post -
Item inheritance has been tidied up. That's about it. Templates can now be defined, which pass their traits to items. Additionally, templated items can pass their traits down to subitems. Sadly, my progress stops there.
Now for my rationalization!
Friday through Saturday I was busy partitioning my drive and setting up Ubuntu linux. Sunday, I worked all day, just like every week.
So there we have it!
Now I just need to work on making my wireless work on linux.
I mean, making PyMUD work. =]
Saturday, June 17, 2006
Item Inheritance
As per Andrew's request, I started working on item inheritance today. That is, making item 'templates' that can pass their attributes onto subitems, to save time scripting.
It didn't work out as well as planned, so I reopened the ticket and tried again.
Attempt 2 is splendid, but still requires cleaning up. I'll finish it, commit it, and document it here tomorrow. :)
It didn't work out as well as planned, so I reopened the ticket and tried again.
Attempt 2 is splendid, but still requires cleaning up. I'll finish it, commit it, and document it here tomorrow. :)
Thursday, June 15, 2006
0.8 Completed!
Huzzah! Three cheers!
Our first milestone has been reached and closed a whole 3 weeks early! The rate of progress is truly getting frightening.
So, let's take a look at today's accomplishments.
A new 'users' component was added, with the class UserManager. Now, UserManager is a truly magical entity. It depends on very little other than the existence of the World and Database services, and as such, will be completely reloadable when the time comes to implement... reloadability, heh. Right now it houses all database interactions for logging and logging out, as a web of callbacks. As a coorelary to adding this new component, I tweaked client.py and dialogues.py to use it, in the process abstracting out all database calls.
Now, here's where things get FUN.
Since I had little else to do today, I went ahead and implemented storing and retrieving items from the newer database tables. That is to say, when you log in, your inventory and equipment tables are scanned and loaded in as new items based on unique codes that are assigned when you log out. Theoretically, even nesting items into bags works, though this requires extensive testing.
As another neat aside, I implemented a new 'load' attribute to items on NPCs. The value is a float, which is the percent chance to load an item. Rarer items should always come first in the list, and will close the possibility of other, more common items loading instead.
Cool, eh?
Our first milestone has been reached and closed a whole 3 weeks early! The rate of progress is truly getting frightening.
So, let's take a look at today's accomplishments.
A new 'users' component was added, with the class UserManager. Now, UserManager is a truly magical entity. It depends on very little other than the existence of the World and Database services, and as such, will be completely reloadable when the time comes to implement... reloadability, heh. Right now it houses all database interactions for logging and logging out, as a web of callbacks. As a coorelary to adding this new component, I tweaked client.py and dialogues.py to use it, in the process abstracting out all database calls.
Now, here's where things get FUN.
Since I had little else to do today, I went ahead and implemented storing and retrieving items from the newer database tables. That is to say, when you log in, your inventory and equipment tables are scanned and loaded in as new items based on unique codes that are assigned when you log out. Theoretically, even nesting items into bags works, though this requires extensive testing.
As another neat aside, I implemented a new 'load' attribute to items on NPCs. The value is a float, which is the percent chance to load an item. Rarer items should always come first in the list, and will close the possibility of other, more common items loading instead.
Cool, eh?
Wednesday, June 14, 2006
Wonderful Accomplishments
Aha!
Today, James and I did something absolutely wonderful with the database!
Well, fine, it was mostly James.
But, the point is that we moved to twisted.enterprise for great asynchronous database power! No more of that convoluted pymud.database stuff.
However, the new component is still far too fluid for my liking, as we plan on adding many new features, so I'm hestitant to start storing things in my new SQL tables in the database. Instead, this evening I worked on making Items more useful.
I did! They work!
Now, Items (as well as Races, NPCs, and Modifiers) can directly tweak various things such as attack damage, dodge chance, hit chance, crit chance, hp, mp, ep, etc! This is good!
In addition to this, I added a new Dice class to lib that allows for random numbers applying to stats. Though primarily geared towards attack damage, I foresee many possible uses.
To make use of the new Item possibilities, I went ahead and added a means of connecting Items to NPCS. With the new equipment and inventory tags, you can directly append Items to them! My future plans include allowing random chances associated with a given Item showing up, for rarity purposes.
Over and out for tonight.
Today, James and I did something absolutely wonderful with the database!
Well, fine, it was mostly James.
But, the point is that we moved to twisted.enterprise for great asynchronous database power! No more of that convoluted pymud.database stuff.
However, the new component is still far too fluid for my liking, as we plan on adding many new features, so I'm hestitant to start storing things in my new SQL tables in the database. Instead, this evening I worked on making Items more useful.
I did! They work!
Now, Items (as well as Races, NPCs, and Modifiers) can directly tweak various things such as attack damage, dodge chance, hit chance, crit chance, hp, mp, ep, etc! This is good!
In addition to this, I added a new Dice class to lib that allows for random numbers applying to stats. Though primarily geared towards attack damage, I foresee many possible uses.
To make use of the new Item possibilities, I went ahead and added a means of connecting Items to NPCS. With the new equipment and inventory tags, you can directly append Items to them! My future plans include allowing random chances associated with a given Item showing up, for rarity purposes.
Over and out for tonight.
Subscribe to:
Posts (Atom)