So Phoenyx has been an absolute machine in churning out new code, and I have been struggling to get caught up. Things are a little tense and hectic right now, because of a lot of RL things. Nothing bad, just lots of...well, stuff. Buying a car, for instance.
The commands table rebuild is done and functioning, and for that all credit goes to Phoenyx. I am deep in the DB module rebuild. It's making progress, just slow-agonizing-painful-I-wish-I-had-more-time progress.
Updates as they happen.
Wednesday, March 26, 2008
Thursday, March 20, 2008
Objects - The Who and Why
Okay, so there's been a lot of talk about "objects" in relation to PurlMUSH. They've been talked about as if they are the greatest thing since sliced bread(they are) and as if they are going to save the world(virtually speaking) and butter toast(not a chance). This is going to be my attempt to communicate what objects are and what they aren't, and why Phoenyx and I are charging forward with the object-oriented banner held high and proud.
So, in typically "me" style, let me make an analogy for you. Let's take a clock radio as our example. Now, 75 years ago, if you had wanted a clock radio, you would have had to make a circuit board. You would have had to solder the components to the board. You would have had to make a case for it. You would have had to fashion buttons. You would have had to connect the wire. And it would have worked. It would tell time, it would broadcast radio stations, it might even have an alarm if you decided that you wanted it to.
Now, if you want a clock radio, you can go down to Sears and buy a pre-built, ready-to-use, no-soldering-required clock radio. This "object" that you just bought would work just fine, right out of the box. It already has all the components of a clock radio, is aware of what it needs to do in order to fulfill its role as a clock radio, and all you have to do is take this "object" and put it wherever a clock radio is needed.
The first clock radio, the one lovingly soldered together and carefully assembled? That's the original code, and the way a lot of code is written. All of the component parts assembled together carefully putting each piece in place. It's functional, maybe not the easiest thing to use, and unless you have a well-made box to put it in, you can see all of its parts. (And who likes to let their parts hang out for everyone to see?)
The second one, the one you bought at Sears? It is the new version of the code on which Phoenyx and I are working diligently. It has everything packaged up into a nice object, with which we can work.
Each "object" will represent an object in the database. In the original implementation, the database was what is called 'an array of hashes'.
So, here's how that worked. An array is a numbered list of items. For example:
A hash is a referenced list. For example, if I was going to make a hash about this blog, it might look something like this:
If you put the two together, you are going to get an array of hashes. So, in the current implementation, I can refer to the name of room #10 like this:
$db[10]{"name"}
The $ tells Perl that it's a variable. Meaning a label that holds stuff. The [10] part tells the code what number in the array to look for. The {"name"} tells it which key in the hash to retrieve the value for. Now, you might ask yourself: But Santiago, this makes so much sense, why would you want to go and change that? Yes, it makes sense, but to a coder, it's cumbersome and in-elegant. Elegance is everything to a coder.
Under the new system, the arrays of hashes and all of that will be contained within an object. And the whole db will be inside one object. So, if we want the name of object #3, we'll do this:
$db->name(3)
Nicer, eh? An object is a piece of data that includes the methods we will need to be able to manipulate or report that data. So, with this object-oriented method, we can do things like the following. Let's say object #12 wants to set an attribute on #3:
$db->setAttr(12, 3, "foo", "You're a foo master!");
And that will set an attribute named foo on #3 with the value 'You're a foo master!". This attribute will be recorded as having been set by #12. Previously, we would have had to do this:
$db[3]{"foo"} = "You're a foo master!";
And that's just to set the attribute. That doesn't take into account keeping track of who set it, when, or anything else. The other nice thing is that setAttr, as a method of the $db object, will know whether #12 is even allowed to set attributes on #3. Previously, the code had to do all the tests for this in the main body of the code. Now, it's a matter of the object knowing how to do it, instead.
Does that mean we don't have to code those tests anymore? No, not at all. They will be built into the object instead of the main code. What it DOES mean though is that our objects will be handling the work load instead of the main body of the code. This will be easier to maintain, easier to manage, and easier to extend.
I hope this helps you understand what some of this rambling has been about. If you don't, e-mail me. :)
So, in typically "me" style, let me make an analogy for you. Let's take a clock radio as our example. Now, 75 years ago, if you had wanted a clock radio, you would have had to make a circuit board. You would have had to solder the components to the board. You would have had to make a case for it. You would have had to fashion buttons. You would have had to connect the wire. And it would have worked. It would tell time, it would broadcast radio stations, it might even have an alarm if you decided that you wanted it to.
Now, if you want a clock radio, you can go down to Sears and buy a pre-built, ready-to-use, no-soldering-required clock radio. This "object" that you just bought would work just fine, right out of the box. It already has all the components of a clock radio, is aware of what it needs to do in order to fulfill its role as a clock radio, and all you have to do is take this "object" and put it wherever a clock radio is needed.
The first clock radio, the one lovingly soldered together and carefully assembled? That's the original code, and the way a lot of code is written. All of the component parts assembled together carefully putting each piece in place. It's functional, maybe not the easiest thing to use, and unless you have a well-made box to put it in, you can see all of its parts. (And who likes to let their parts hang out for everyone to see?)
The second one, the one you bought at Sears? It is the new version of the code on which Phoenyx and I are working diligently. It has everything packaged up into a nice object, with which we can work.
Each "object" will represent an object in the database. In the original implementation, the database was what is called 'an array of hashes'.
So, here's how that worked. An array is a numbered list of items. For example:
- Bob
- Suzie
- Charles
- Diana
A hash is a referenced list. For example, if I was going to make a hash about this blog, it might look something like this:
- Name = Culturing a Purl
- URL = http://purlmush.blogspot.com
- Started = February 2008
If you put the two together, you are going to get an array of hashes. So, in the current implementation, I can refer to the name of room #10 like this:
$db[10]{"name"}
The $ tells Perl that it's a variable. Meaning a label that holds stuff. The [10] part tells the code what number in the array to look for. The {"name"} tells it which key in the hash to retrieve the value for. Now, you might ask yourself: But Santiago, this makes so much sense, why would you want to go and change that? Yes, it makes sense, but to a coder, it's cumbersome and in-elegant. Elegance is everything to a coder.
Under the new system, the arrays of hashes and all of that will be contained within an object. And the whole db will be inside one object. So, if we want the name of object #3, we'll do this:
$db->name(3)
Nicer, eh? An object is a piece of data that includes the methods we will need to be able to manipulate or report that data. So, with this object-oriented method, we can do things like the following. Let's say object #12 wants to set an attribute on #3:
$db->setAttr(12, 3, "foo", "You're a foo master!");
And that will set an attribute named foo on #3 with the value 'You're a foo master!". This attribute will be recorded as having been set by #12. Previously, we would have had to do this:
$db[3]{"foo"} = "You're a foo master!";
And that's just to set the attribute. That doesn't take into account keeping track of who set it, when, or anything else. The other nice thing is that setAttr, as a method of the $db object, will know whether #12 is even allowed to set attributes on #3. Previously, the code had to do all the tests for this in the main body of the code. Now, it's a matter of the object knowing how to do it, instead.
Does that mean we don't have to code those tests anymore? No, not at all. They will be built into the object instead of the main code. What it DOES mean though is that our objects will be handling the work load instead of the main body of the code. This will be easier to maintain, easier to manage, and easier to extend.
I hope this helps you understand what some of this rambling has been about. If you don't, e-mail me. :)
Wednesday, March 19, 2008
SO many updates
Okay, where to start:
Here's a good place. Phoenyx Black is in da hizzouse. There is a co-developer on the PurlMUSH project. Phoenyx is da bomb. Plain and simple. Thanks to his impressive input, PurlMUSH is advancing by leaps and bounds and has a much better chance of being a success now.
Other updates:
The command parser has been rebuilt by Phoenyx and is waiting my rebuild of the DB load routine before we implement. The command parser rebuild is also going to necessitate a reworking of the existing command subroutines.
The idea of the new command parser is that commands will be able to be registered in the system, their aliases clearly defined, permissions, and the function they are to run will all be structured rather than loosey-goosey as it is now. This will also facilitate developers who will be building extensions to the code later on. (@mail, BBS, etc)
What's up with the DB load routine, you ask? Excellent question my friend. I'll tell you.
The DB loading has been officially abstracted. What this means is that:
Here's a good place. Phoenyx Black is in da hizzouse. There is a co-developer on the PurlMUSH project. Phoenyx is da bomb. Plain and simple. Thanks to his impressive input, PurlMUSH is advancing by leaps and bounds and has a much better chance of being a success now.
Other updates:
The command parser has been rebuilt by Phoenyx and is waiting my rebuild of the DB load routine before we implement. The command parser rebuild is also going to necessitate a reworking of the existing command subroutines.
The idea of the new command parser is that commands will be able to be registered in the system, their aliases clearly defined, permissions, and the function they are to run will all be structured rather than loosey-goosey as it is now. This will also facilitate developers who will be building extensions to the code later on. (@mail, BBS, etc)
What's up with the DB load routine, you ask? Excellent question my friend. I'll tell you.
The DB loading has been officially abstracted. What this means is that:
- The main code doesn't care if the DB is in XML, SQL, HTML, or Elle magazine. As long as there is a module in place that will read in the db and return the appropriate set of objects, we're good.
- The db type will be specified in the .cnf file as the dbType parameter.
- Other db types can be added. Want PostgreSQL? NO problem! Want db4? Hell, want db2 data on a magnetic tape? No problem! Build a module that lets Perl access the data source, read in the data and return the appropriate objects and PurlMUSH won't care if you're reading octal values off punch cards.
- XML will become the "default" format for the flatfiles. Because the XML module will be standard "vanilla" PurlMUSH, you will always be able to read an XML flatfile in, and write an XML flatfile out.
Friday, March 7, 2008
Oh, and...
Also created a Google Group for it as well (http://groups.google.com/group/purlmush) so that we can have mailing lists go out and such as that. Don't know if it will ever get used, but it's there.
E-mail the group at purlmush@googlegroups.com
E-mail the group at purlmush@googlegroups.com
Branching out
Okay, so the project now has a GoogleCode page (http://code.google.com/p/purlmush). This will allow for svn, bug tracking, issue reporting.
I'll also post archives of the code there too.
I'll also post archives of the code there too.
Wednesday, March 5, 2008
Version Change
Given the amount of work that I've put into the code so far and how much it differs now from where I originally started, I have bumped the version up from 0.1 to 0.2. That marks it as a 'stable' version...though still Beta because we're pre-1.0. I don't know if I'm going to get to the point anytime soon where I have a third branch on the version number for builds...but I might get there. I will see if there's a way that I can post the code somewhere publicly without having to go to Sourceforge or something like that. I don't know if I'm ready for that kind of exposure just yet.
README
Welcome to PurlMUSH, a different way to do MUSH. This project is a labor of love more than anything else. It is a determined effort to take the robust and functional platforms provided by PennMUSH and TinyMUX and implement them using the Perl programming language. That means that, by definition, it is a proof-of-concept.
Of course, that also means that you can have fun with it, as well. Everything that has gone into the development of this project is based on the idea of code being fun...and something of an obsession as well.
A little bit of history on this project:
- Originally this project was started sometime around 2000 or 2001, when Santiago downloaded and registered a copy of PerlMUD from Boutell.com. Yes, the software was registered, conferring the rights to modify the code on to the Santiago. The idea was tantalizing...a MU*, in Perl. And thus, PurlMUSH was born.
- Help was solicited from a number of people online, most notably Steele from steelemountain.com, who shared Santiago's vision for doing outrageously cool stuff with the code.
- June 2005 - Project was effectively halted when Santiago began the RL trauma of separating and divorcing his wife. The code was lost to the divorce, and has not been seen since. Baby Jesus cried. The code had been some of the best work he had ever done in Perl.
- February 2008 - A new version of PerlMUD was downloaded by Santiago, and he felt the pull and tug of that earlier obsession. He renewed his license with
Boutell.com and began working on the code in earnest. Friends were able to provide server space, and the work began.
A little bit of the vision for what PurlMUSH might become:
- Fully object-oriented code structure, with each db object type having its own corresponding code object. Ideally, Flags and Logging will get OOP'ed too.
- Well-formed and fully compliant XML database flatfile structure.
- Internal systems such as comm/channels, BBS, Places/Mutter, IC time (with configurable ratios), Cron, and whatever other goodies are considered to be 'standard' softcoded systems on MUSHes today. Myrrdin's amazing softcoded systems are the de facto standard for BBS and Cron, there's two standard places and mutter packages out there, and a million things for IC time and other functionality like weather (Keran's *shudder*) or a +wear-style multi-descer (MANY many of these out there). One of the 'standard' and dreaded jobs that goes into starting a MU* is quoting in these very standard bits of code. Why? Projects like Sandbox Globals Project (SGP, again *shudder*) are built around the idea that your game comes with code. Comes with the systems that you need, "out of the box". Insta-MUSH, just add water.
- Easy to setup. Purl doesn't require compiling. You don't have to know a lot of fancy Unix/Linux commands to get your game running. Pretty much, as long as your server is connected to the Internet, has a "standard" installation of Perl (and eventually ActivePerl for Windows), you will be able to have a PurlMUSH up and running in under five minutes. No, seriously. There will be (eventually) a config script that you will run which will query for the necessary bits in the mush.cnf file, the things that won't be "assumed". For example, IP and hostname, file path for the db, etc. Other configuration options can be changed by hand-editing the file. Once you've been through the config script, you type ./Startpurl (or double-click the icon if you're on Windows) and VIOLA! You have a MUSH.
INSTALLATION
Download the code.
Unpack the code - tar jvxf purlmush-###.tar.bz2 (where ### is the version)
Edit the mush.cnf file to suit your mush and environment.
Type: ./Startpurl &
Connect to the host and port you have specified in the mush.cnf file and log in as the God character (default password: lollipops).
HELP
If you need help with PurlMUSH, first off: RTFM. Read the help files. If those don't help, read the blog (http://purlmush.blogspot.com). If that doesn't help, e-mail purlmush@gmail.com and Santiago will answer your query as best he can.
EXTENDING PURLMUSH
Yes, we want to be able to have modules that extend the functionality of Purl. If you have Perl-fu and want to build and contribute modules, please do so. In time, there will be a central repository for submissions, sort of a CPAN for Purl. For now, just e-mail them to Santiago (purlmush@gmail.com).
Good luck, and happy MUSHing!
Of course, that also means that you can have fun with it, as well. Everything that has gone into the development of this project is based on the idea of code being fun...and something of an obsession as well.
A little bit of history on this project:
- Originally this project was started sometime around 2000 or 2001, when Santiago downloaded and registered a copy of PerlMUD from Boutell.com. Yes, the software was registered, conferring the rights to modify the code on to the Santiago. The idea was tantalizing...a MU*, in Perl. And thus, PurlMUSH was born.
- Help was solicited from a number of people online, most notably Steele from steelemountain.com, who shared Santiago's vision for doing outrageously cool stuff with the code.
- June 2005 - Project was effectively halted when Santiago began the RL trauma of separating and divorcing his wife. The code was lost to the divorce, and has not been seen since. Baby Jesus cried. The code had been some of the best work he had ever done in Perl.
- February 2008 - A new version of PerlMUD was downloaded by Santiago, and he felt the pull and tug of that earlier obsession. He renewed his license with
Boutell.com and began working on the code in earnest. Friends were able to provide server space, and the work began.
A little bit of the vision for what PurlMUSH might become:
- Fully object-oriented code structure, with each db object type having its own corresponding code object. Ideally, Flags and Logging will get OOP'ed too.
- Well-formed and fully compliant XML database flatfile structure.
- Internal systems such as comm/channels, BBS, Places/Mutter, IC time (with configurable ratios), Cron, and whatever other goodies are considered to be 'standard' softcoded systems on MUSHes today. Myrrdin's amazing softcoded systems are the de facto standard for BBS and Cron, there's two standard places and mutter packages out there, and a million things for IC time and other functionality like weather (Keran's *shudder*) or a +wear-style multi-descer (MANY many of these out there). One of the 'standard' and dreaded jobs that goes into starting a MU* is quoting in these very standard bits of code. Why? Projects like Sandbox Globals Project (SGP, again *shudder*) are built around the idea that your game comes with code. Comes with the systems that you need, "out of the box". Insta-MUSH, just add water.
- Easy to setup. Purl doesn't require compiling. You don't have to know a lot of fancy Unix/Linux commands to get your game running. Pretty much, as long as your server is connected to the Internet, has a "standard" installation of Perl (and eventually ActivePerl for Windows), you will be able to have a PurlMUSH up and running in under five minutes. No, seriously. There will be (eventually) a config script that you will run which will query for the necessary bits in the mush.cnf file, the things that won't be "assumed". For example, IP and hostname, file path for the db, etc. Other configuration options can be changed by hand-editing the file. Once you've been through the config script, you type ./Startpurl (or double-click the icon if you're on Windows) and VIOLA! You have a MUSH.
INSTALLATION
Download the code.
Unpack the code - tar jvxf purlmush-###.tar.bz2 (where ### is the version)
Edit the mush.cnf file to suit your mush and environment.
Type: ./Startpurl &
Connect to the host and port you have specified in the mush.cnf file and log in as the God character (default password: lollipops).
HELP
If you need help with PurlMUSH, first off: RTFM. Read the help files. If those don't help, read the blog (http://purlmush.blogspot.com). If that doesn't help, e-mail purlmush@gmail.com and Santiago will answer your query as best he can.
EXTENDING PURLMUSH
Yes, we want to be able to have modules that extend the functionality of Purl. If you have Perl-fu and want to build and contribute modules, please do so. In time, there will be a central repository for submissions, sort of a CPAN for Purl. For now, just e-mail them to Santiago (purlmush@gmail.com).
Good luck, and happy MUSHing!
Subscribe to:
Comments (Atom)