Member Discussions

I'm thinking of starting a new mud system from scratch (more IF/Sim based than most Muds, with RPG elements). I'm intending on using C# (.Net) and running on a Windows 2003 Server.

Now, I know I've just opened myself up to a flame-a-thon, but I chose this platform over c++/java because I know it better and (in my role as a professional programmer) have seen various tools and methedologies that could make 'from scratch' development a lot faster.

Some of the massivly multiplayer games use sql-based back-ends for all their entity data and sometimes their mob locations, which seems like a good idea. I'd thought that I'd have MSSQL2000 (or newer) or Oracle 9 or MySql in the background at any rate - it's actually not that important which one, as it's just a data connector anyway.

I've been looking around at the differet code bases for muds and noted that most of them are C++/Linux based, some with half-supported ports to windows & mac. There don't seem to be many exclusivly windows based systems for what appears to be (mostly) security scare related reasons. From what I've experienced of Windows 2003 server and of properly secured web applications in .Net, this isn't as much a problem.

Before I take the next step and start transferring all my notes and designs into peliminary code, I'd like to get a feel for what the development community and mudders in general feel about developing in .Net, and what kinds of walls I'm going to hit.

I am developing my own mud from scratch in VB.NET. SQL 2000 back-end. I have about 500k in source code and it's working really well. My server is all command-line of course and uses standard telnet clients, no GUI stuff.

Of course, once it goes live and real people play it, we'll see how well it works. But writing from scratch has been a blast.

I started it in C#, but switched to VB.NET because I code faster in it.

Good luck.

(Comment added by AdamMil on Tue Jun 15 15:13:55 2004)

It has been a blast, however I did just finish 2 days of bashing my head against the wall implementing the wordwrapping and "more" scrolling text functionality. It's easy to take that kind of low level stuff for granted until you write it from scratch yourlself, heh.

I've been tinkering with the idea for some time, but the only major roadblock I'm at right now is in the scripting department. Having embedded Ruby into my current codebase, I am not at all fond of regressing to either VB or JScript.Net. And C# is far too heavy-weight for my scripting needs even if it does form the backbone codebase. There is the Ruby/Net bridge, but it looks a bit unfinished.

So I have a few questions to anybody that's done something similar: I could drop to unmanaged code, but would the dueling GCs pose a problem? Any special considerations? This is my first time working in such a "managed" platform, so I don't really want to proceed until I understand that the magic happening behind my back won't stab me.

Actually, not so much security as stability.

Windows has some issues that make it difficult to write long-running applications on anything short of a dedicated server, and even then it requires some careful management.

The biggest show stopper I know of is the truck-sized holes in the memory protection subsystem. In most unix-like systems, an attempt to access memory outside the assigned address space of your process results in a segmentation fault. This is unpleasant, but helpful in debugging those runaway pointer problems. Under the windows memory protection system, reads are allowed pretty much anywhere, and writes to areas such as those shadowed by video memory are NOT protected (because it would slow down game performance).

Now, if you're using C#, VB, or Java, pointers won't cause crashes... but the result of sloppy object handling will instead cause memory leaks as you lose track of memory references, but they can't be garbage collected.

Other issues involve leaks at the DLL level. Microsoft has created a pretty substantial system, with an enormous number of layers, and let's face it, the more complex a system is, the more bugs it will have. When you compile something to use DLL's, often those DLL's are what leak memory. When your application exits, the leaks from those entities are NOT returned to the free pool. In some cases, a new instance of the driver will create a new instance of the DLL data segments, thus leaking even more memory with each run. That means if you don't actually reboot the whole server periodically, you may run out of ram even if your code is as tight as a sealskin boot.

So, I'd put it as a question of priorities. If you want to use the language and/or technology you are familiar with, use windows and deal with the management issues of having to reboot things to keep them running smoothly.. how often depends on how much hardware you want to throw at it. Linux/BSD/Solaris won't require the same level of maintenance of the server environment (if you don't feel the need to apply every security patch on earth (IE: have a firewall), uptimes of years are not unusual), but then you're committed to using more traditional technologies like java/C++/python/etc...

PS: Don't use mysql. If you're familiar with oracle or SQL Server, mysql will drive you mad with how much it lacks. Postgres is a more reasonable choice, as it actually handles things like foreign keys and stored procedures (although not nested transactions yet... sigh).

it's inspiring to know that i'm not the only one "out there" who wants to try out .net as a mudding language. I'm aware of some of the issues that one can have writing for windows such as the dll nightmare, but i'm fairly used to dealing with that :)
The interchangability of vb.net and c# is handy, too. be great to play your game if/when it's ready!