Yeah, another “I wanna build a MUD” thread, or not.
I'm not looking for an easy hookup to crank out a MUD by next week. I plan to start by actually learning programming. Well, relearning, as I used to do a little programming in C about 10 years ago. I've done virtually nothing with computers since, but I'm sure it's like riding a bike...you never forget how to fall off, right? :P
I have a variety of motives for wanting to develop a MUD, but with a 6000 character limit for posts, I can't list them all here.
There are a few things that I want to be able to do that I haven't seen in any other MUDs. I'm not sure if these things aren't possible, designers just haven't done them, or I just haven't seen it. I'm trying to conceptualize these elements not as a “it would r0x0rs to have laser beams coming out of my eyes”, but whether it is possible to get a computer to do these things considering the limitations of a programming language and the MUD as a construct. Obviously, I'm not looking for an explanation of how to do these things right now. I merely want to know if (down the line) they're reasonably possible and/or if how I'm thinking about these things is how I should be thinking about them.
Space within space
One thing I want to do is kind of a “rooms within rooms” effect. It will be a cyberpunk setting in a not-so-distant future city surrounded by a wasteland. So, if we split the region into “sectors”, each one of those sectors is a chunk of wasteland. One of these sectors would be the city itself. The city is further divided into (city) blocks. On these city blocks are structures (buildings), which will contain multiple rooms. So, there's kind of a fractal spatial effect (at least within the city). If you're in a room in a building, you're also on a city block, in a sector on the map. But one can be on a block without being in a “room”, or in a sector without being within a city.
I'm sure this is a cumbersome endeavor, but there are certain system elements that will rely on this distinction (movement/travel, communication, etc.). For example, PCs will have a communication device that will let them communicate while working a job, but the range will be limited.
Time after time
That probably won't make sense, but you gotta love a Cindi Lauper reference. Anyway, I have an idea as to how I want to handle the passage of time, but it may not be doable.
First, there's overland travel. Within interior structures, I don't mind PCs being able to zip from room to room. It's a matter of seconds and not important. For exterior travel, it's a different situation. Essentially, I want there to be a “lag”, so to speak, when traveling between city blocks or wasteland sectors. Nothing too long, but enough where it can matter on certain jobs where time is an issue. Where I see the potential complication is in where the PC “exists” during a transitional moment, and most importantly what s/he can do during a transition (and how that might affect the transition). So, a PC could take out an item or drop something without interrupting the transition, but if s/he decides to get into a fight, that would/should cancel the move.
And this brings us to fighting. I've thought about how I'd want to handle combat. When a fight starts, all combatants will be entered into a queue based on their initiative. Actions they take will have a simulated time value which will determine when they can act again. In short, time mechanics will be a little Final Fantasy-ish. In a sense, PCs in combat will be in two “places” at once...the actual (virtual) geographic location and within this constructed combat space. But this brings me to my next topic.
Being in two places at once
It isn't just with combat that PCs will have to be in two places at once. The VR/hacking element will function similarly. A PC hacker will be in such-and-such room in such-and-such building (in a virtual physical sense), but will also be on the net (in a virtual sensory sense). Even though a PC will be in a room with exits to other rooms, a PC on the net is essentially rooted to that spot. Not only that, but s/he will be too engrossed in the virtual environment to be able to interact in his/her physical environment. So, when I think about a MUD, I see objects and I see spaces. One object, one space, no problem. With these situations it's like there is one object in multiple spaces with varying capacities. It sounds like the kind of thing that would give a computer an aneurysm. I might have had one just thinking about it. :)
The room is moving
I'm still trying to conceptualize how I would handle vehicles (esp. with multiple passengers). The only thing I can think of is to treat them like “rooms” that can move. Keep in mind that vehicles would also be affected by transitions like PCs traveling on foot. However, maneuvering a car is going to be different than “maneuvering” one's body.
The way I'm thinking about how I would go about these things could be totally off the mark. I just want to know at this point if what I'm conceptualizing is beyond what a MUD can do.
Anyway, I'm assuming that the first step is to relearn C, though maybe I should be learning C++ instead? Also, I read some guides on the web, and some of them suggest learning Java (which I really know nothing about) rather than C or C++. Other guides I've read suggest spending time as a builder on other MUDs to help you develop your chops. I know I'm nowhere near that point, but if I can figure out how to get that far, that probably means I'm doing something right, no?
So, can anyone point me in the right direction? Thanks.
|
![[Go to top]](/images/gototop.gif){kind=small}
top