Friday, 30 May 2008 reading list 3

On one hand browsing through these threads reminds me of when I first read them as they were posted in university on monochrome terminals in a neglected computer room in the corner of the engineering buildings. Doing so is inspirational, reminding me of many things my fellow programmers and I wished to implement in the MUD we worked on at the time.

However, on the other hand most of the topics are kind of depressing. Not because they remind me of the things I want to program for my current pet project, but haven't. Rather because pretty much every thread seems like a futile reiteration of other threads, most likely by the same posters. An exercise in repeated procrastination. I can feel myself finding it hard to make notes on each thread as I do more and more.

A common factor of these threads, is that more often than not, Physmud pops up within them. The way it is described by its author, paints it as one of the deepest most complex codebases ever written. Unfortunately, while it sounds interesting and is painted as an implementation of some of the more advanced concepts (non-room-based, dynamically generated descriptions, ...), word is that it is vapourware.

1997-01-10: Specifications for Wear Location System

Mainly of interest for the initial post which is a detailed description of a ... wear location system.
1997-02-24: Stock muds considered harmful
A long thread, but a classic. Starts with the suggestion that all the stock MUDs are bringing the rest down.
Design of a good MUD (was Stock MUDs, etc)
Touches on experience, levels and skills. How to handle character health. Downtime, what your character does when you quit. Then some more on classes.
Telnet NOW! Campaign / Interaction in combat / Quests
Starts off with something boring to do with telnet, then veers into where MUDs are going.

Eventually it comes on track and starts covering combat. Effect of the rate at which text is displayed to the player. Proximity and room sizes. Manual action versus automatic reactions. Limb-based systems. Realistic fighting topics, from Japanese fighting techniques to practicality of armour. Magic in combat. Damage types. Size of combatants. Relative descriptions based on the viewer. The practicalities of combat in Braveheart. Armour class and damage.

Next it veers to quests. Static, dynamic or templated. Replayability. Players sharing solutions. While this is an interesting topic, my personal preference is that solutions don't end up making the same mistake Oblivion did with its dynamic content being at the expense of believability.
1997-04-20: The State of Muds
Starts with some subjective thoughts on the future of MUDs.

Next a proposal is made to band together and create and uber-codebase. I don't know about you, but I work on my personal project because it interests me - I get to choose the language it is written in and where it is heading theme and featurewise. Working on other people's ideas in my spare time doesn't sound like much fun, and the chance of the commonly agreeable concepts being appealing I would expect to be low.

Mike Sellers chimes in with a point which matches my interests, that "
the biggest overarching weakness is that the simulations and world-mechanics remain shallow". The thread continues to debate realism and game simulation/world-mechanics.
1997-04-06: Ideas for the betterment of muds...
Starts off with the subjective opinion that sound was what was missing from MUDs. A protocol to add it. Then a general MUD protocol.
Stock muds: the my-way highway
Yet another thread to do with stock and scratch MUDs. Hard to pin down what it covers as I got bored and lost focus while reading it. Gets to a point where it starts going into programming related details, near the end. Maybe something to do with concurrency.
Threats in a MUD
Relates to adding excitement to the game, through posing threats of various kinds to the player and their activities. Threats from interaction with the environment. More detailed gameplay, in the direction of simulation/realism.
Experience based on reality...
Suggests rethinking at what experience is used for. Moves onto skill system discussion. The effect of botting.
1997-05-02: Combat system Design
Avoiding round-based combat. "To hit" factors. A good discussion of room-based and other alternative spatial approaches. Skill systems and experience. Death. Player rights.
DESIGN: Coordinate systems, etc
Body types; swarm, gas, blob, etc. Coordinate system area creation.
RP mud naming restrictions going a bit too far
Should characters be forced to name their characters with real names? Should nickname-like names be allowed as character names? Introduction systems in passing.
DESIGN: Original themes, running muds
Original themes. Implications of the room-based spatial model on play experience.
Room based VS ???
Short thread on the alternatives to the room-based spatial model.
The Failure of Mud Evolution
Starts off as someone requesting help compiling the Circle codebase, then branches into discussion about the failure of MUDs to evolve. Touches on licensing disputes (Medthievia), advanced MUD codebases, stock MUD suckage, inclination of given MUD types (diku, LP, ..) to quality levels. Advantages of build able to directly build things like HTTP and FTP servers into your MUD.
EVE Online has had a built in web server from day one and it has been extremely useful as an interface for game masters, game designers, programmers and more. It was simple and fast to write a web page which worked with your feature you implemented in some way.
The pluses and minuses of using LP as a MUD programming environment.
1997-08-12: ADMIN: Update of stock/scratch analysis
Another attempt at breaking down the advantages and disadvantages of stock and scratch MUDs respectively. I didn't bother to note the original thread because.. I don't remember, but it probably devolved into bickering and flaming. This also devolves into more of the same. Although, at the end, there's some discussion of advanced codebases.
Redefining the room
More discussion of variation from the room-based spatial model. Dynamic generation of descriptions.
Player Rights
This isn't the first thread on this topic I encountered. There were several others, several years back, but I skipped them. This is one of those worthless topics which are subjective and more often than not are unproductive (like stock vs. scratch).
Is it mine yet?
Whether a MUD codebase is yours if you make enough changes. Meanders a bit into bickering. Then to the theft of codebases outright, then people deriving from them (Godwars).
A topic I identify with, but from the opposite perspective. I worked on an LP based codebase with some friends and we released it as the Sorrows mudlib. More than once, we got people who took our hard work, made some nominal changes to some of the higher level systems and claimed that they had changed so much that it was completely their own work.

As someone who had done the bulk of the work rebuilding an existing codebase (the Discworld LP mudlib) from the ground up, the difference in the work we did that, to the superficial work the adopters had made to our resulting work, was an order of magnitude.

I would say it is never yours, but always a derivative work of what you based your work upon. As we considered our mudlib to be a derivative of Discworld mudlib, their work was a derivative of our mudlib and always would be.

Discussion of combat systems. Armour, damage, participant size, limb-based.
Current position: December 24th, 1997.

1 comment:

  1. Hi Richard,

    I totally agree with your opening statements. I started mudding in the winter of '96 at university, and remember knowing about the capabilities of most of the codebases back then, and seeing what people wanted to achieve with them. As a programmer, I knew these things were often not impossible at all.

    Now I read posts on Top Mud Sites and so on and realise that so little has been achieved, with people still asking for the same absent features that were asked for a decade ago. Perhaps this is really just because muds lost their critical mass of players and implementers, and therefore lost development momentum. Perhaps the commercial games fixed these issues, but I guess I wouldn't hear about it since their players don't tend to post publicly.

    It doesn't help that the mud community, if wishing to start with something working and familiar, is mostly lumbered with 15 year old codebases written in C or some arbitrary scripting language. You could probably completely rewrite a DIKU mud in Python in a week, but this fact seems lost on most people, so coders are doomed to get bogged down in string parsing routines and manual linked list management instead of writing great games.

    I think there's still plenty of mileage in text-based multi-player games. I just have to find some spare time to do the work to prove that this is true.