View Single Post
Old 07-30-2010, 07:00 AM   #2
Kylotan
Member
 
Join Date: Jun 2003
Location: Nottingham, UK
Home MUD: Abattoir (Smaug)
Home MUD: ex-Jellybean (Smaug)
Home MUD: ex-Dark Chambers (Merc)
Posts: 174
Kylotan is on a distinguished road
Send a message via ICQ to Kylotan Send a message via AIM to Kylotan Send a message via MSN to Kylotan Send a message via Yahoo to Kylotan
Re: Developing from scratch

Of course it requires more time, initially. But, just as there usually comes a time to trade in an old and creaking car for a new one because fixing it becomes too cost-ineffective, a similar time approaches when you take code that has been hacked at for 20 years and replace it with something cleaner and more maintainable.

Let's not pretend the Diku/Merc family is great code - you and I may know our way around it but it's still a mess, with little heed to the advances made in software engineering over the last 20 years.

In particular next to nobody is coding in plain C these days except those writing OS kernels or code for tiny devices, and for good reason - it's much harder to maintain and extend than a higher level language is. It has a niche role in 2010 and rightly so.

There are many good reasons not to use C for a MUD server in the 21st century. The biggest one is a lack of an actual string type, which makes it an absurd choice for a program that spends 90% of its time pushing strings around. Another one is the lack of container classes. Nobody should be fooling about with #LINK macros and structs filled with next and prev pointers unless they're writing a filesystem or something.

It's not 'sloppy development', it's 'software engineering', making the most of the tools available to you to create the product you want. Seriously, people used to level the same criticisms at those who chose to use C in the 90s instead of writing in assembly. It's an old and tired argument and holds no water these days. Nobody is at serious risk of incurring significant CPU costs on modern hardware for this kind of network-bound application. Our MMO server software can host over 1200 people on one server without going above 20% CPU utilisation, and that's doing a hell of a lot more work per player than almost any MUD would, not to mention having many more players. If you're using significant CPU time for your MUD, in 99 cases out of 100 your algorithm is broken, which means you'd have the same problem in C anyway. Sloppy development is choosing to manage your own pointer-based linked lists in 2010 and needing to keep around a #CHECK_LINKS macro in case you messed up somewhere.

That's not really relevant. Hardly anybody will be doing that, and those who are won't be using Diku as a base. The point is, for a typical text-based MUD running over plain text commands over telnet and playable on a telnet client (or spruced-up equivalent), you don't need to be squeezing out extra performance in C.

We're in an age where people are writing high speed servers in and which can handle much more traffic than any DIKU mud has ever or will ever have to serve, and with the advantages of being superior languages for high level text handling. You could probably host a typical DIKU on your phone these days. Yet still we have people thinking that we need C because every cycle counts.

If someone really wants a Diku-style game, and doesn't care much about adding new features, then sure, there's no point starting from scratch. But your extensibility and maintainability is crippled by comparison. And I do think the mud community has suffered from failing to move beyond the code of the early 90s.
Kylotan is offline   Reply With Quote