Member Discussions

Hello mudders/coders. I have decided that the C code for most muds (at least the ones i have looked at) is poorly structured, and has all sorts of security, memory, and performance problems. The purpose of this message is not to whine about the current muds, so if you want to discuss this, contact me. Now, to the point.
I am looking for coders to help me create a new mud from scratch. The mud will be written (and has already been started) in the .NET environment. This means it is acceptable to code in C#, J#, managed C++, VB.NET, or even the latest version of javascript (so far, i've written in C#, but .NET allows for easy language interoperability). My design is different from current muds in that it uses modern programming theories such as inheritance, interfaces, and delegates. Also, each player runs on his own thread; this reduces lag by a large amount, as each command is processed on its own thread and if one person is lagging it will not affect any of the other players. At the time this message was written, there was almost no medium to high level functionality (room classes, item classes, mob classes) However, I have done a lot of the low level coding already (sockets, message queue, database, buffers, and threading), and will continue to constantly work on the MUD. It would be very, very nice to get some help though... I know it's unlikely that any of the available coders know .NET languages, but i have to try. If you are interested, please contact me.
----------------my AIM screen name is Leclerc9
----------------if you do not have aim, download it at
----------------www.AIM.com

Still here? OK, ill explain a little about what I've done so far. Let me begin with the theories that I am basing my code on. These are my commandments so far:
1. A player class may not have write priveleges to external classes. This protects coders from making unnecessary, dangerous, or unreadable code additions. From a players perspective, everything can be done by typing in a message. If something is to be done in the player class, it can go to the messagequeue.
2. Player data can only be changed from within the event handler class. There shall only be one instance of this class, and it shall exist only in the main game loop.
3. There shall only be two static classes that players have access to: the game timer, and the message queue.
4. Every command shall have its own thread.
5. The main loop shall do as few actions as possible. Everything should be done in sub classes. Currently, the loop accepts connections and passages messages from the queue to the event handler.

Ok i gotta get to sleep...

(Comment added by AbstractCS on Tue Aug 19 18:14:03 2003)

================
PLEASE DELETE

Oh...my...God...

-Xeon

I concur.

Hi,
Interesting as your post is, I think it belongs in the 'Mud Staffing Board' since you begin it with 'Now, to the point.I am looking for coders to help me create a new mud from scratch[...]'.

BR,
Fredrik

OOps... didn't realize which section it should go in. Sorry, im new to mudconnector... hope they don't penalize me.

Okay I'll have a stab at dragging this thread kicking and screaming onto the topic.

Each player's command interpreter running on a separate thread sounds like a total synchronisation nightmare to me. The interpreter itself needs to know something about the world in order to parse the more complicated commands, so how can you suggest that this reduces lag for the player concerned? Each interpreting thread will in essence need to lock the game world from the beginning of parsing until the end of the command, to ensure that any relevent objects, scripts, and actors being referred to have not changed or disappeared in the interim, thus making the command invalid.

Basically, every command from the players, and indeed internally from the game world itself, will need to be processed one-by-one in order; so why bother with threads at all? Just stuff each player's commands onto a central parsing queue, and process them one by one on a single thread.

Okay that's enough topic for me. Now for the ranty bit.

I'm f-bleep-ing insulted that you think that just because most of us code muds for fun in languages such as C and Java, that we are automatically ignorant of the last ten years of Microsoft's attempts to change how we write code. Many of the denizens of this forum, myself included, are in full-time employment in this business, we don't just know the catchy buzz words or the rapidly changing rhetoric, we use these new languages and methods of Microsoft's day in day out to earn our bread. I don't know who you are or what you do but all the same I'm going to accuse you of thinking that just because you managed to download some pirate copy of Visual Studio .NET Enterprise Edition from eDonkey, and better yet managed to keep up with the documentation long enough to learn how to transfer your extant coding skills into a new programming language, namely C#, that you believe this gives you the jump on all of us backwater traditional bearded middle-aged Unix types all sitting round our PDP-11s harking back to the good old days when "mud" meant something that Richard Bartle had written and all these pesky common people hadn't heard of the internet yet. You couldn't be more wrong, bucko.

Basically, every command from the players, and indeed internally from the game world itself, will need to be processed one-by-one in order; so why bother with threads at all?

A good thread implementation inside a MUD would use a read and write lock concept. This enables many to be reading from a resource at a time and lock when one thread needs to write to it.

Another aspect of a well-threaded MUD is how it uses locks. Any decent implementation wouldn't lock a whole resource (room,object,mob,etc.) just to modify one tiny part. A good MUD would either be able to create a locking structure which could lock out individual items[1].

In any case, you're typically right about the threads issue with MUDs. It really doesn't provide a whole lot of benefit since MUDs work with interactive data. Threads would be more useful in an program that would send and recieve large packets consistently.

[1] Which then some would say you'd need a lock for both the resource and the item. Bleh.

You talk about security issues but then you want to use something from microsoft to design this mud in.... I didn't think security and microsoft could be used in the same sentance?

And if I might ask could you elaberate on the possaibly security issues that you are referring to with why you don't want to use C for the mud?

(might as well attempt to make this a design thread)

I'm a middle-aged, bearded, grimy old UNIX hacker (ok, so I may not be quite middle-aged and I did in fact just shave (since my boss told me to), and I'm closer to the PFY stage than the prestigious title of 'hacker') and therefore am using Links to skim the Net (actually it's because reinstalling Gentoo with the 2.6_b3 kernel caused my WinXP boot sectors to suffer unrepairable damage), so I can't quote properly (ok, I can, but I don't feel like it.)

Inheritance, interfaces and delegates are not 'programming theories.' Inheritance is an aspect of the object-oriented paradigm, interface is an aspect of the pragmatic programming paradigm and delegates are a design pattern.

Sure, with .Net it's acceptable to code in multiple languages but I think you'll find you will be sticking with one language with another maybe for scripting.

Then your commandments:

1) Objects don't have direct access to other components? Well you-hoo, you've just discovered a cornerstone of OOP.

2) Let me get this straight. You have ONE event handler class..

3) ..And a thread for EVERY COMMAND? I think you may be insane. In a bad way. Have you ever tried to run a threaded .Net program? *shudder* From a design point of view, this kind of 'abstraction' is completely unnecessary, and I would say it's also incorrect (i.e. the analog is not accurate.)

4) You have a thread for every command (!) and you have a main loop?

Geez.

I'll just go recompile now :)

Since everything is derived from an object in C#, it is very easy to use locking. There is a built in "lock" function that has the simple syntax, lock(objectname);.
When writing to a particular part of a structure, you can lock any resource within that structure. This means that the multithreading is perfectly safe, and since two threads can write to the same player object at the same time, the mud will run faster.

When i say security issues, i am talking about the design of the code itself. Encapsulation, by definition, provides security, since objects can only access data they should be able to access.
In the current C code, it is possible to access most structs from many places in the code. This encourages people to make convenient functions at their own leisure, and this causes very big readability and bug vulnerability problems. What if someone makes a mistake in an obscure line of code somewhere in the distant "advance level" function? It would be hard to track, especially if the bug was a run-time logic error...
As for the C part, C is a procedure oriented language. Of course, it is a matter of choice which language to write in, and there are arguments for both procedure oriented and object oriented. In my and most programmer's opinions, procedure oriented programming is only best for a few things, like coding high performance applications.

Object oriented coding can be described as a theory, since it is abstract. Even if you are correct, it is much easier to call them theories than to say Inheritance is an aspect of the object-oriented paradigm, interface is an aspect of the pragmatic programming paradigm and delegates are a design pattern.
Nothing is wrong with having many threads if you use sufficient locking. Multithreading simple commands is not expensive by any means. Thousands of simple threads can run at little cost.
And what is up with everyone going for my throat? I don't ever remember saying anything bad about them...

Whatever do you mean?

No, commands from players do not need to be processed one by one. If a player in room x fights a creature, and a player in room y fights another creature, why should both these actions be done in sequence? Why not do them at the same time?
Synchronization is not a nightmare since C# has easy locking functions.

I was wondering if I was going to get deeply involved in the concepts brought up in this thread. Tried to avoid it, but I just can't resist :P.

Encapsulation, by definition, provides security, since objects can only access data they should be able to access.

Everyone together now... encapsulation is NOT security. Encapsulation is a feature of the OO paradigm as a programmer check, but it is not supposed to fiercely prevent any type of programic hack upon an object. If a programmer cannot abide by it, so what? If they're working with you, drop them. Otherwise, don't worry about them.

In the current C code, it is possible to access most structs from many places in the code.

If you are worried about programmers medeling with the data, place a comment above the structure to say 'DON'T MEDDLE!' or something like that :P. If this technique is good enough for ANSI, I think it is good for the general population[1].

This encourages people to make convenient functions at their own leisure, and this causes very big readability and bug vulnerability problems.

No fact, no proof. All you're giving out is a theory here, which doesn't make your point valid.

[1] I'm not taking into account where people who do this are on your team, which then you drop them.

Even if you are correct, it is much easier to call them theories than to say Inheritance is an aspect of the object-oriented paradigm

If inheritance were a theory, then answer me this. Could you have inheritance without an object-oriented design?

Thousands of simple threads can run at little cost.

Maybe if you have many processors to handle all the overflow, but most of us are not as lucky. A single processor certainly couldn't handle a thousand threads, espically when locking (which would almost defeat the purpose of threads if you weren't going to use some type of concurrency).

And what is up with everyone going for my throat?

.NET, Nuff said[1].

[1] Okay, there is more to it :P. Mostly just in your design is where everyone is getting picky.

Easy lets say player a is killing mob a. Now player b cast a vortex spell and sucks all the mobs in the area to the room he is in. And player b and mob a are in the same area. Now at the same time this votrex was happening player a and mob a where in a fight and player a kills mob a at just after the vortex got the pointer to mob a. Seems how this is threaded technicaly this could happen. How do you think the world is going to enjoy the apples as the vortex now loads a dead extract mob into the room cause when it got the pointer it was ok to use but was slaughted during so.

I just ran a program that had 5000 threads running at the same time on infinite loops. Each thread also was constantly allocating new data... My machine is two gigahertz, and i had no problem at all. I can't say that slower machines wouldnt though...
And about arguing over whether inheritance is a theory.. that is childish semantics. Look up the definition of what a theory is and if you are still not convinced, do a google search on the theory of object oriented programming and be amazed.

Oh, and by the way, if you think my design doesn't work, then talk to me on aim and ill let you connect to my telnet server. Nuff said.

By security i don't mean hacking...
To me, code security means preventing variables within a class from being accessed by other classes that do not NEED to access them. I am not talking about protection from hackers or any of that stuff... pretty much what i am talking about when i say security is encapsulation.

No this couldnt happen because if Player a kills the mob, the thread would lock the entire mob and then delete it. From player b's point of view, the mob never existed.
Why do people say that this design doesn't work when i have already successfully tested some parts of it?

Here is a similar problem concerning race conditions known as The Dragon's Dinner. So how do handle this?

How can it lock the pointer if it's already gotten the OK? By this I mean (using rom function terminology) The vortex starts and as it's looping through the valid players in the area it finds the mob and idk calls some function first like a can_see. Then about the time can see exits the mob gets killed and extracted getting all its varaibles freed and the pointer added to a link list of empty pointers. The vortext then calls act to send a message the mob is leaving that room (but it's already extracted) and then tryies a char_from_room (which it isn't in a room) and char_to_room now bring the pointer that was empty and no where into the room. So are you saying that the second a fight happens the character will be locked to prevent anything from happening? And what about round base fighting lock it and reopen it after each round? And if you lock it how do you play to extract it, if its been locked?

IDK maybe I'm confused on the whole idea here. I'm just seeing a problem with threading each command. And like they said if another player is using those resources isn't it going to lag the next player until it can use said resources? So by that a lagging player will affect other players... Or am I total confused?

Sorry if I have offended you in any way, but I personally have a very low opinion of .NET, especially when it comes to developing applications.
Perhaps I'm just biased, but what I really like about using a language like C/C++ is the fact that it's more portable, and it usually produces faster code, and, how do I put this? It seems to be 'closer' to the hardware.
In my experience, most 'high level' languages generate way too much bloat-code, slowing things down, and in my opinion MUDs need to be as quick as possible, regardless of size. If you can get away with programming you MUD in C, do it.

Threads: Hmmm, wasn't there a post before about someone using a thread for every player and mob slowing things down to a crawl? I'm haven't messed around with C# threads but I imagine the OS has to manage them and will stuff up on too many threads. But I don't know about that.

-TrollEater \../

True: .NET languages are slow, but that is not because of "bloat" code. It is because they use automatic garbage collection.

Muds do not require any great strain on computers. Generally, all the lag is caused by the server sending data slowly to the clients. Therefore, the speed of the internal processing is not an issue (while the speed of sending data is), so C provides no real advantage.