 |
|||||||||
|
|||||||||
|
|
Before I get to my ideas for what I'd like to do with Ulysses Agenda, I want to discuss (briefly) what I consider to be a MUD. If you take a quick look through the list of open source, free, and paid MUD servers available, you'll notice that a lot of them follow the same model. They have a database or backing store of some kind (such as binary files, Access Database files, XML, etc) that stores a list of rooms, items, monsters, and maybe quests if you're lucky. The defining characteristic of these MUDs is that they are 100% data-driven, and players can only do things within the confines of those MUDs that is possible within the schema. If you need to add additional functionality , even if that functionality only exists in a tiny portion of the MUD, then you have to modify the entire world schema just to accomodate a small change. What these systems typically look like after being run for a while is a really messy schema with a crapload of empty (null) columns of data that are only used for 10% or less of the MUD's operation.
I am going to offend a lot of die-hard MUD people here, but the games I've described above, in my opinion, do not qualify as MUDs. In a code-driven MUD, such as LPMud (the best and original of which is, of course, Genesis LPMud, where I spent years and years writing code), things are much more flexible. For example, let's say the default MUD engine allows you to walk through "rooms" and you can look around. Now you want to add dynamic weather effects. Sure, in a data-driven MUD you could add data columns that dictate if a given room has weather effects, but then you need to deal with storing whether the room is outside or inside, what kind of weather effect it is, etc. In a code-driven MUD, you could write code that adds weather to a room, and then simply "inherit" the weather code in any room that requires weather, and leave the code out for rooms that don't require weather. One of my favorite creations in LPC (the language that runs LPMud) was a set of elemental demons. When the dynamic weather outside indicated a lava storm, the fire demons' strength grew by 15%. When it was raining, the fire demons' strength was reduced by 15% and the water and ice demons all grew in power by 15%, etc. That kind of dynamic flexiblity and ability to be creative as a programmer and a content developer is impossible in a data-driven MUD.
So how does this apply to Ulysses Agenda? Well, once I got some of the raw mechanics of how network communication might work, and how the client would communicate with peers and the "universe server", I started thinking about content. I wanted to make sure that I would have star ports, planets you could land on, the ability to harvest and trade resources, (obviously) the ability to communicate with, partner with, and combat with, other players and NPCs. All of that sounded pretty cool, but then I thought - what if I want to make quests? What if I want to add a new type of planet later in the game's development? What if I want to build in some kind of "fetch" questing where the cargo holds of ships can store custom items in addition to resources, and obtaining these items and bringing them to certain NPCs will earn the player a lot of experience? I simply cannot do that in a scalable, elegant manner by doing a blind data-driven game. If I have a table in my database for StarPorts and another table for Npcs and so on ... it's just going to get really ugly, really fast if I try and build content for it. Also, I want the users of the game to contribute content. This is the fundamental tenet that separates MUDs from MMORPGS (other than graphics/sound) - MUDs, typically, allow willing and educated users who have reached the top of the game (e.g. level 20 or "wizard level") to actually write code to expand the game, live, while it's running.
I want this for Ulysses Agenda. I want the players of the game to be able to contribute code to expand the universe of their favorite UA server. The code should, of course, be written in C# and uploaded to the server directly from the UA client, similar to the way people used to be able to edit LPC files directly on the server through their favorite telnet client back in the good-old-days of MUDs.
Here's my question to you folks: Do you think this is a good idea, or a ridiculously stupid idea? Should I make Ulysses Agenda a project that hopefully also can be used to teach people C# by using C# to create dynamic, interactive content for the game itself? Or should I just default to a data-driven game and make it more of a turn-based strategy type game?
Thoughts? death threats? compliments? I'd love to hear what everyone else thinks.
Alot of people have thought the MUD world has fizzled since the rize of
contemprorary MMORPGs, but the sales of the zMUD Mud Client have indicated
otherwise. There are a few different projects that have been inspired to
leverage .NET to make a MUD server. I've been working on SharpMUD
(http://sharpmud.sourceforge.net/) for a few years, there is WheelMUD
(http://www.wheelmud.net/), and there is the pretty much defunct TigerMUD.
Bruce, I was never suggesting using Telnet for Ulysses Agenda... It is
already a P2P design... I'm sure I could find some way of allowing modular,
user-created code units to appear within the game.
I think that, ideally, this would be a great platform for muds.
Unfortunately, most people (me included) don't really have the chops to
make this a tangible reality. I find that I craved this, in my own project,
so the way I approached it was to integrate the scripting elements into the
'blind data' structures. While this allows me a very wide degree of
run-time customization, it is still imited by the infrastructure exposed to
the scripting shell. For instance, I could create a new spell type, but I
could not create a new kind of spell casting. The spell would still be
limited to using mana, etc. (Granted, the spell itself has an optional
'script conditional' before casting, which one could use on a 0-mana spell
and then make the script subtract fatigue, or an item, or something)
