Tinytalk Episode 008: Interview with Amberyl
Submitted by javelin on Thu, 2007-07-12 13:48.
Click here to download this episode: 
Click here to subscribe to the podcast: 
Tinytalk is a podcast about MUSHes and other text-based virtual worlds, and the players who play them. In this episode:
- [00:00] Interview with Lydia Leong (aka Amberyl)
Links to stuff mentioned in this episode:
If you have mushing questions you'd like answered, or suggestions for future shows, send email (or audio files) to tinytalk at javelin.pennmush.org. You can also leave a voice message at 206-333-1542.
Tinytalk is licensed under a Creative Commons Attribution-Noncommercial-No Derivative Works 3.0 License .
»
- javelin's blog
- Login or register to post comments
Click 
Eating Our Young
As always, it was a tad odd hearing someone I've known or known of for years. The commentary on the community hit issues I've been preaching for several years. Her insight had more clarity than I've managed to say previously.
Teaching in an enviroment that the player is interested in will always outdo anything on a web site, social game, or other site. Correcting the years of dissuading the ability will take a fundamental shift in the community. Otherwise, the "Preacher" situation will continue until the gray beards are unavailable.
PernMUSH in the earliest days didn't encourage coding directly. It was expected in one fashion or another. It was new, different and anything unusual produced was admired. That was before the days of the project requirements of the "Smiths" as Amberyl mentioned. Admire those days of va-vz.
As PernMUSH matured, coding was encouraged within certain crafts but never discouraged elsewhere. The "psychocoder" element was certainly in place within the Smiths but it wasn't inclusive to that element. Many individuals learned how to code and split off from Pern to code new and interesting systems.
Some Preachers Eating Our Young, Too
Being a later entry into MU-dom (not arriving on the scene until after some of the fragmenting was well underway - circa 1993), my recollection of this time frame seems to differ from the one you describe as well as from the one Amberyl describes. I suppose this is why they say that history is written by the victors. However, I don't think, at this point in its evolution, that the bulk of MU history is being written by the former baby-eaters. Likewise, I'm of the opinion that many of those who preached, but didn't practice, were just as guilty of the 'young eating' as those they preached against.
The people we need to be watching and paying attention to are those who have put their noble belief systems into action in order to overcome those darker days of our shared history. Those who: provide opportunity for others to achieve and/or enjoy, lead by quality example, and do so for the personal satisfaction of having given something good to the community rather than for personal accolade (this path can be very difficult to stay on when the accolades come anyway).
As for the 'need for more public domain code', this is a two-edged sword in many ways...
* On the one hand, who doesn't want free stuff?
* On the other hand, who wants to have their latest work of creative art shredded by the baby-eating puss-leeches of the 'everything must be open source so I can have it too' crowd -- only to have a tophats, handle-bar mustaches, and fancy canes painted on their 'Mona Lisa', by the masses of coders (talented or otherwise) who have never held a paintbrush, simply because the lower right corner has no paint on the canvas?
(this calls to mind stuff referenced in the 'hacking pennmush' stuff on this site: hack when you must, not because you can)
So far, I don't think anyone (certainly not myself) has 'gotten it absolutely right' as to what text-based gaming needs. A swift kick in the arse, perhaps? Dunno. But one thing appears certain - the internet (thanks to the wayback engine) will remember far more of it than some of us ever hoped... or, perhaps, wanted: for better or for worse.
Softcode doesn't seem to need much support
While server hackers certainly get shredded (perhaps because tempers run high when things mysteriously break, or worse still, in the dark old days, crashed frequently), I've not found this to be the case with softcode.
Moreover, people generally seem to expect support from hardcode hackers (unsurprisingly), whereas the expectations for softcode support are fairly minimal. (Most people who download my MudCore globals, for instance, simply use them and never need or ask for support.)
The real problem may be that it can be a pain to package large MUSHcode systems in an easily-installed format, especially if you've got dependencies between your systems (as is often the case for purpose-coded systems).
It usually isn't a pain at
It usually isn't a pain at all for large complex systems.
As long as you code initially with the knowledge that it will be cross-platform, know what versions you wish to work with, and then code modular based systems to 'correct' itself upon installation, it really is a piece of cake.
The installer is no problem at all. To know all the Mush/Mux systems, and all the softcode of the various systems to be able to code around them is what takes the longest time, if that is indeed even one's original intention.
Personally, the biggest issue with softcode, just like hardcode in the years gone by, was crediting those people who's ingenious ideas and thoughts went into the next 'bright and shiny toy' which all too often falls short of the mark.
Credits in Softcode
This truly is an obstacle. One which, for many many years, I tried vigorously to uphold - retaining credit for things such as moral support: 'hang in there, dude. I believe you can do it.'
In the WARPEDcore Manifest, I took the cop-out approach during the introduction - thanks to lots of (unnamed) people. Many times, this is the only option when the list isn't precise (who participated in which conversations which eventually led to such-and-such idea which was used... you get the point).
Similarly, in my toolkit, I still retain my original list of credits (many I can still name from memory: Talek, Octavian, Arathorn, Garthorn, etc.)... but only offline in my personal library. Why? Because all of the code is my own. All of the inspiration to code was my own. Sure, I learned a lot from these people - even got some super inspirational brainstorming from a few of them on a few occasions. But, in the end, I wrote all the code myself and only wrote code that I wanted to write... for my toolkit... and there were over 5 screens of credits for everything from 'this cool idea included in this command' to 'took me out to dinner the night I thought of this other cool idea'. I was including too much, and wasn't able to manage it all properly.
WARPEDcore, however, is designed to explore this idea of 'credit for the sake of credit' in multiple ways. The method I'm hoping will survive this exploration is that which retains credit online at the source (joe user can't erase these credits the same way he/she can wipe credit attributes from an installed object).
Let's face it, in some small way, I owe everything I've ever coded... to someone... in some small way or other. And I'm sure this applies to everyone out there - have you been tracking all of your credits in detail? have you been tracking them at all?
Purpose-building vs. genericism
I suspect that the vast majority of softcoders, though, do purpose-built code -- code designed for a particular game, that's not designed with portability to other games in mind.
I think the community would benefit from as much code in the public domain as possible, as examples as well as working systems that people can simply take and use/modify. But it's difficult to extract purpose-built systems from their original environment, and going to the effort to making things cross-platform is more than a lot of people want to deal with.
I guess my point is that we'd probably see more softcode in the public domain if it were easy to lazily release stuff. ;)
Wiki?
One of the things I've been focusing on with the WARPEDcore is the inclusion of a single-purpose attribute to provide installation commonality across platforms. Specifically the attribute named ~ (tilded). This is all documented elsewhere on this site, so I won't discuss this in too much detail here.
But, it brings to bear a point of potential resolution to a great many dilemmas which are seeming to flow in and out of this conversation -- writing multi-platform softcode.
A few years ago, Ashen tweaked this capability into Rhost.
There is nothing special about the tilde character, per se. It was available, cool-looking, and appropriate as a representative marker for the WARPEDcore.
Yet there is also a softcode philosophy behind its use -- having a dynamic and powerful installation scripting which is multi-platform aware.
(with side-effects enabled)
@wait 0=@set me=~:[create(Foo,10)]... should (if I'm not mistaken) work on every platform... as should...
&ATTRIB [get(me/~)]=<contents>... for all attributes (and by extension, flags, etc.) thereafter.
This is free code. It is a procedure which
* I discovered (created out of my own mind?),
* is, thanks to Ashen's cooperation, presumably cross-platform compatible with all servers
* has been released into public domain, and
* the WARPEDcore has announced that it intends to use
- precisely because it is such an intimate bridge between the respective worlds of softcode and hardcode. This connecting point between the server which provides the tinker toys and the person who makes stuff out of those tinker toys ... this is the beginning of everything else in the world of cross-platform softcoding.
As much right as I had to slap a license on this (knowing the exact circumstances when I first did this - while working on a multi-platform compatible script for testing message propagation through exits and in/out of things and players several years ago), there was a greater import in letting others see and use it.
So, now back to my subject heading...
who wants to make the wiki (having used this one, I know that all edits are tracked - credit for the sake of credit)?
I thought...
Amberyl raised a lot of interesting issues. I was particularly intrigued by the idea of sharing code with the general MUSH community to help give newcomers to the field a frame of reference to tinker with and maybe launch off into their own directions in coding. It's put me in a mind to share much of what we've developed on the jointhesaga.com games over the years!
I'm actually nervous
...to release my code!
I'm not a comp sci guy, and I taught myself everything in softcode (when I started I literally did not understand what an iter() did).
However, I have put my chargen code online, and my goal is to put 100% of my source on my game forums. I'm just hoping when the bug reports start streaming in, they are nice, and not mean.
what game is this Boris? and
what game is this Boris? and where is the forums?
Kudos
I wouldn't stress about publishing it. In the current environment, there are far more consumers than reviewers. You'll probably either get dead silence or complaints about it not working on some platform you didn't intend to support.
Make sure to document it as well as you can and let it go. If the comments overwhelm your time, note the useful ones and state that'll you'll fix it in the next release. Others might send you fixes. Hopefully, they'll be within the design. Incorporate the critical and let the others languish until you have downtime to apply them.
It's not much, but it's a start...
We've just released a couple of coded systems from jointhesaga.com:
* Our monthly RP notables +voting system
* The +speak language system
This link to visit the archives.
Just thought I'd post
Just thought I'd post another link to my own Penn softcode archive, with a variety of globals and suchlike on it, after reading the comments here. It's over at www.talvo.com/pennmush.php. It's perhaps not the best as example code for people wanting to learn to code, but good for people who want something they can install easily and use out of the box.