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.

Wednesday, 28 May 2008 reading list 2

A few more..

It occurs to me that the links are not as neatly sorted by timestamp as I wished. Google groups seems to sort the posts by date of last post, at best. And then there's the odd thread where some of the later posts are before the original post which started a thread. Better than nothing, but unfortunate.

1995-04-05: Commercialization of MUD - part 2

This is continued discussion from an initial post about the future of online games. Unfortunately, the initial post seems to be missing from the Google groups archive. RMT is suggested and dismissed, although mention is made of it already happening in some game called Kingdom of Drakkar.
1995-04-06: Commercial MUD Feedback
More discussion of RMT in commercial MUDs. Also a reference to the monthly revenue of a MUD called Jurassic Park in Korea, which supposedly earned $60K USD per month.
1995-07-30: Paradigms for Modeling Physical Space
Relating to a 3D world as a basis for MUD development. Other possibilities come up along the way.
What is the Mud State of the Art?
Something I have always wondered myself. Starts off promising with an array of interesting features listed, but gets derailed into covering various details which aren't really that hard.
Do you use auth/identd?
The idea of being able to get the username of a player, on the machine they logged in from, was quite nice. We logged it on my MUD and found it very useful in dealing with problematic players. However, it was only as useful as long as people logged in from sites they didn't own or have administrative access to.
VRML mudding
Some discussion of the practicality and utility of using VRML to make a graphical MUD. We exposed a VRML representation of our MUD, via our embedded web server, back in the day. Given an agreement on the benefits of text as a game representation, based on the idea that it allowed more free use of the imagination, we dismissed using VRML for play. The consensus in this thread is that it was impractical anyway (required functionality was lacking and bandwidth needs). When we experimented with VRML, it was on the wane. It was a few years after this.
What would *you* pay for an excellent mud?
An attempt at polling the interest in what people would be willing to pay to play a graphical MUD. Goes on to cover what people think of advertising.
Do you think Quake/Doom/etc will end mudding as we know it?
Starts off as one of the atypical valueless topics, that graphical games (i.e. Doom/Quake) will cause the death of their text counterparts. Doesn't ever veer from it. Included just for the sake of completeness.
1996-08-08: shifting economies
Addressing shifting from a npc based economy to a player-driven one. Polls those who have made the shift, with one poster of relevance piping up mentioning Dartmud.
1996-08-11: Rethinking Rooms
More discussion of alternatives to the room-based spatial model. Mentions the problem of viewing one room from another..
1996-08-29: The Future of Muds?
A short but positive thread covering text versus graphical MUDs. Mentions the integration of graphical aids into text MUDs.
1996-09-01: Letting Coders have Players
Should coders be allowed to play the game? The possibility of cheating, the effect of that on the player base. The advantage of being able to see what the players are really doing and hear what they talk about.
1996-07-15: Skill based systems / Rethinking Rooms
This thread veers from skill-based systems to rethinking rooms and back again.

Ways to stop players gaming 'learn through use' skill systems. Lore/in-game knowledge of a character.
Limitations of the room-based model. Grid-based approaches. Technical details of grid-based implementations. Generated room descriptions. Ways to handle exits.
1996-08-19: Realistic MUDs: Mob behavior
Starts with giving NPCs a life, engaging in activities for a reason. Then devolves from this into discussion of existing limited approximations which aren't anywhere near as hard to implement. Wanders into introduction systems. Rumour systems. Adding continuity by doing away with resets.
Developing a graphical MUD in Java / java and dynamic reloading
Some back and forwards about the practicalities of code reloading in Java at the time. Comparisons with LPC, within which this is easy. Class reloading is the main thing that my code reloading module allows for in Python.
Current position: 8th August, 1996.

Sunday, 25 May 2008 reading list

Reading forums like The MUD Connector, MUD Lab, Top MUD Sites and so forth, there are not a lot of posts covering original subjects.

... Are MUDs getting less popular? Allusion to a feature which needs implementing, implicit request for people to design it (or something). Description about yet another MUD programming language which someone is creating, appeal for ideas or comments. ...

I've always wanted to make a set of notes where I can just post summaries of and links to existing discussions on these topics. There's a range of resources, whether the MUD-Dev mail archive or newsgroup posts.

Given a little spare time, this is my initial effort. I am going through the Google groups archive of the newsgroup from the beginning onwards. Not reading the posts at this stage, but making a list of interesting looking threads. It is surprising how few threads of note (excluding crap like bickering over licensing) there are over the early years, 1992-1995 at least.

1992-07-04: Discworld MUDS

Terry Pratchett encouraging MUDs based on Discworld to step forward and be legitimised.
1992-07-31: Admin Burnout and the TMI Dilemma
Several posts which relate to my own MUD development experiences where it is all very well for people to have ideas, but when it comes down to it, you need programmers who are willing to code it.
1992-09-10: Australian MU* ban. Still in effect?
Apparently MUDs were taking a significant proportion of the Australian national link. Interesting note on the overhead of a telnet packet when the protocol is operating in character mode rather than line mode.
1992-10-09: Graphical MUDS?
A poll of what graphical MUDs were available for play, with some allusions to others that were in development (for what that's ever worth).
ATTN: skill based muds
Interesting discussion about skill training through use. Discworld MUD has a system called Taskmaster which was implemented four or five years later than this. Pinkfish from Discworld (David Bennett) can be seen participating in this thread.

EVE Online used to have skill training in this manner, but eventually it was discarded due to the implementational problems it involved in the one-world multi-node environment.

Eggert, who wrote EVE's "taskmaster" system was directly inspired by Discworld's implementation which he experienced as a player in university.
1992-12-03: Skills based systems abuse
Followup discussion on skill advancement through use.
1993-03-12: Magic
Discussion about magic systems.
A new type of player?
Allowing players to login and control NPCs.
Rooms? Who needs them?
Replacing the room-based model with a grid-based model.
Nightmare mudlib 2.4 for MudOS 0.9.16
George Reese makes a post announcing his new mudlib version, listing a range of features it provides. This is analysed by other posters and results in some interesting discussion about schools, guilds and more.
How to permanent character death
Discussion about permadeath. Leads to Alan Cox pointing out that this was the way it originally worked (in MUD1) and it was expensive.
Current position: April 23rd, 1995.