13 Apr, 2009, David Haley wrote in the 1st comment:
Votes: 0
Dark Gryphon said:
Hi :biggrin:

I'm rather new to the world of MUD-developing, and I noticed - all the "normal" codebases are completely static, requiring you to open them up and write confusing code into badly named functions.

So, I'm building a new codebase - LamaMUD. It is written in Lua, with some C libraries and a C stub loader. Lama, according to Google Translator, means mud in Portuguese - so my codebase's name is mudMUD. :cool:

The design goal of LamaMUD is to be as flexible as possible, while still being a great MUD development framework. To this end, a huge amount of the code is based around a very simple hook implementation. It will also support basic classes (with far too much metatable magic), and a XML database that directly maps onto Lua datatypes. Players and NPCs will use mostly the same code, through inheritence, to a point where an admin can log onto an NPC and control it.

My dream? That one person uses my code to run their MUD.

Cheers,
Dark Gryphon :evil:


I would definitely be very interested to hear more about this! Do you have anything set up where I can read about this? Or would you be willing to talk more about what you're doing? I'm always interested to hear about what people are doing with MUDs and dynamic languages, especially with Lua :smile:
13 Apr, 2009, Dark Gryphon wrote in the 2nd comment:
Votes: 0
Hi David,

The system is currently in a design phase. I am writing code however, mostly to see what works and what doesn't. The simplest hook system I could think of is in the Pastebin right now. I'd say it works similarly to the MediaWiki hook system, if you've ever taken a look at that - except it's Lua-ised.

I have not yet set up a website for the project. I hope to set one up at some point, but only after I've got the very core of the code ready. In the meantime, I'll use these forums to document it's progress. That pastebin thing is cool :cool:

An awful lot of design/coding stuff is in my head, I'm trying to write it all down before I forget! Specifically, I've got an idea for exactly how I will implement the Object database. Another is a very odd idea - descriptionless rooms, the system generates info from a bunch of demi-items that are in the room, such as the sun, wind, etc. So:
Quote
The sun is shining brightly. There is the smell of flowers in the air. There is a bench, which someone has vandalised. Etc etc…

Then you could do:
look sun

and get:
The sun is bright! You are temporarily blinded.

Or some such thing.

I don't intend to implement fights into the system by default - there are so many ways to implement fights, and I'd just end up building a generic fight system like most codebases.

Cheers,
Dark Gryphon
13 Apr, 2009, elanthis wrote in the 3rd comment:
Votes: 0
Funny thing is, that's exactly what AweMUD was meant to be.

Then I realized two very important things:

a) if you don't have a specific MUD in mind while developing your codebase, you'll end up failing to deliver the key features needed to implement _any_ specific MUD. e.g., you end up being directionless, and you never end up making anything truly useful to other developers. That is bad. Design a specific MUD _first_, then write a codebase to support it. If your overall goal is to produce a solid codebase, then keep that MUD relatively simple and small in scale, but still have one none the less.

b) an open source MUD is only complicated by making core feature infinitely configurable through external finals, because all you're doing is adding thousands upon thousands of lines of code and making the user learn several different file formats, languages, and application-specific schemas, and all you've done is made a more complex replacement for the language itself. The second you mention XML files mapping things between C and Lua I know you're on the road to absolute failure. You've gone from needing to understand C and Lua to needing to understand C, Lua, XML, and your specific schema, all for no real benefit that a few lines in the C code couldn't have done in a more readable fashion. Configuration files make sense when you have a single piece of unmodifiable software that needs to allow altering very specific end-user-oriented behavior; it makes very little sense when you want to use it to change software that's meant to be locally compiled and installed for a single instance and in which the configuration is directly related to code and not end-user behavior.

So, when you end up with a MUD codebase that's too complicated and over-engineered to make small changes to _and_ it fails to meet your basic needs for your specific game right out of the box, you have a useless codebase. So, don't make those same mistakes. :) Let the user modify scripts or C code if they need to make extensive behavioural changes (document your code well and write it cleanly!!) and make sure you have a target MUD and its requisite features in mind whenever you hack on the codebase.
13 Apr, 2009, flumpy wrote in the 4th comment:
Votes: 0
elanthis said:
b) an open source MUD is only complicated by making core feature infinitely configurable through external finals, because all you're doing is adding thousands upon thousands of lines of code and making the user learn several different file formats, languages, and application-specific schemas, and all you've done is made a more complex replacement for the language itself. The second you mention XML files mapping things between C and Lua I know you're on the road to absolute failure. You've gone from needing to understand C and Lua to needing to understand C, Lua, XML, and your specific schema, all for no real benefit that a few lines in the C code couldn't have done in a more readable fashion.


I agree to a point. However what I realised was that you can write a /game/ engine entirely separately from the mud. If you keep a clean line between "game" and "engine" then you probably won't need your players or admins to understand any C if you don't want them to - or even XML!

But be careful, the line between game and engine becomes blurred at the hook in points… when does a room become a game object?

Other than that, yes, making a code base that is too complex can put people off. Although to be honest, all the code I've looked at (that's not mine hehe) to date has looked nightmarish. So, anything you can do to make yours better, easier and more readable would be great.

Take a look at Sigma mud (its in early stages of dev yet). They have nice clean code (and puts mine to shame) with XML configuration and the like.

http://code.google.com/p/sigma-mud/

good luck!
13 Apr, 2009, David Haley wrote in the 5th comment:
Votes: 0
Elanthis's point is that while you can design an engine independently from the game, it's rather difficult to do so, and you can end up with something so generic that it doesn't actually let people implement a game without significant modification. If you design the game engine and the game logic separately, it still behooves you to do so with an actual game in mind. There's nothing wrong with writing general code that is applied to a specific instance, but writing general code "in the void" without testing it on practical applications is a nice way of ending up with code that you can't apply.
Elanthis will of course correct me if I'm misrepresenting his point :smile:
13 Apr, 2009, Grimble wrote in the 6th comment:
Votes: 0
Yes, I'm convinced a codebase has to ship with a working game in order to have any chance of being adopted. Two obvious and related reasons for this…

1) Only a fraction of prospective admins have strong software development backgrounds.
2) Tweaking something existing (i.e., from example) is far easier than creating something new.

Make the engine as flexible as you like, but build a working game as well, and provide good step-by-step documentation on how to add a command, add a skill, add a spell, add an effect, add a script, etc. This will make your codebase accessible to a broader base of users, and reward the effort you poured into it.
13 Apr, 2009, JohnnyStarr wrote in the 7th comment:
Votes: 0
I think it all boils down to whether or not you really want others to code or just build. The reality for me is that I have a fixed amount of time that i can devote to coding, so if i really want my mud, my way, and i dont want to be 100 years old by the time i've got it up and running, i have to take the fastest route without comprimising integrity. but thats me, i figure if you want to use 3 languages for your mud, then of course you can, but if i was asked to join a mud project that in depth i would decline, due to the fact that i wouldn't be able to get anything done in a reasonable amount of time.

well, my 2 cents anyway :wink:
13 Apr, 2009, elanthis wrote in the 8th comment:
Votes: 0
Well, let's take your concept of hooks as an example. If I understand, your code works by having a native implementation of a show_room_description() type function that then has a hook, which is either meant to replace or to add to the native code. So, in order to fully comprehend and modify the room description stuff, a developer has to look at and comprehend (1) the original native code, (2) the hook system, and (3) the MUD's specific hooks. On top of that, if the developer wants to make relatively large changes to room description code, your approach essentially asks him to reimplement room descriptions from scratch, and those can actually be fairly complex for some MUDs. If you instead took the route of offering a default script for the user to modify, even extensive changes are easier because then it's a matter of taking a complete and working room description routine and tweaking it; the parts that don't need to change don't need to be wholly rewritten, either.

If you're going for a true object-oriented approach, just replace "hook" with "method" of course. The basic Room object's show_description method can just be modified by the developer, and if they need a special room with special logic, they can override as they see fit.

If you plan on supporting rooms with individual overrides to the display logic, it may be worthwhile to explore breaking the room description logic into several methods/hooks in that case, too, e.g. a show_room_title, show_room_description, show_room_objects, show_room_exits, etc. That way specific rooms don't end up needing to reimplement the whole display logic either, they can just replace the bit they need (or extend it by calling the parent's method in addition to the new code).

That's all a fair bit harder if you're implementing the built-in room description in C/C++ and then expecting scripts to only be used for user overrides. My suggestion is to just not do that – the native code should deal with just the core management stuff, and put anything and everything that may be overridable by the user into those clean, documented, modifiable scripts. If you're extending a native codebase you may need to make some concessions if you don't want to make super huge changes, but that's just not an issue if you're starting from scratch.

My core point is that when your project is a set of code that is meant to be heavily modified by the user, there's no reason to have a separation between the "core native code" and the "user editable code." It's not like the MUD engine will be installed by a system administration to some central location and then 50 different users will be writing scripts and config files meant to be consumed by that single shared binary: each MUD operator is going to locally install the code, build it, and modify it if necessary. You don't need to force the developer to use an add-on system because he has full access to modify the core however he wants.

Therefor the best approach is to just make the core as easy to grok and easy to modify as possible rather than adding layer upon layer of abstraction. That actually makes the code easier to modify without extensive coding time or experience than heavy abstraction, it cuts down the amount of work you have to do for the core code, and it results in a better engine overall.

Otherwise, you're essentially just reimplementing AweMUD (literally: your design looks almost identical to what I already did), and AweMUD basically ****ing sucks. And that's only partly because I was young and dumb when I wrote most of it – it's really mostly just because I tried to make a super-generic system implemented half as "don't need to modify it" C++ code combined with a hook system to a script language for overriding/extending the native code. The end result was native code that still lacks a ton of important features for a real MUD, half-assed scripts, and the whole thing is a pile of crap that I've been spending months and months on just trying to get to a state where I'm not embarrassed by it, much less to a point where I think of it as ready for other people to start trying to use. I'd be really sad if you ended up learning the same hard lessons I did through the same long, painful way I had to. :)

Also, to back up staryavsky: the absolute most important thing – THE MOST IMPORTANT THING – for you to give to the target game designers is a very solid set of tools. The core code is honestly almost irrelevant, it could be absolute shit and it wouldn't matter. If you provide a powerful graphical OLC environment that requires relatively little scripting to create large, dynamic worlds, then you will have created the best MUD engine the world has ever seen. The same goes for all other game engines, graphical or textual. Tools are king. Map editors, entity editors, the script language, etc. Good tools are by far the hardest thing to write, too, especially if you yourself are not an experienced game designer. It's hard to know that a game designer may want, for example, a tool that can calculate the average, minimum, and maximum monster levels graphed against the average treasure distribution for a given area so that he can figure out if he needs to increase or decrease either the difficulty or rewards of the area and by how much. Or that he may want to graph the number of pure-combat vs pure-trap vs pure-magical encounters/challenges within an area so that he can tell if he's hitting the target theme accurately enough or if an area is going to favor one type of class over another too much. Or that he may want to be able see paths through an area with different criteria like shortest path, least-combat path, least-traps path, etc. to determine if a non-linear area is too complicate or too easy to get through with or without a map.

Games that provide the designers with powerful and comprehensive tools generally come out as fantastic games. Games that require the game designers to pretty much work with a simple model/map editor and a script language usually end up being buggy, short, frustrating, and on top of it all take 4x as long to develop as the games with good tools.
13 Apr, 2009, Sandi wrote in the 9th comment:
Votes: 0
elanthis said:
Therefor the best approach is to just make the core as easy to grok and easy to modify as possible rather than adding layer upon layer of abstraction. That actually makes the code easier to modify without extensive coding time or experience than heavy abstraction, it cuts down the amount of work you have to do for the core code, and it results in a better engine overall.


elanthis said:
Games that provide the designers with powerful and comprehensive tools generally come out as fantastic games. Games that require the game designers to pretty much work with a simple model/map editor and a script language usually end up being buggy, short, frustrating, and on top of it all take 4x as long to develop as the games with good tools.


Almost seems like a contradiction there. :wink:


Your call for tools raises the spectre of WYSIWYG HTML editors. While the tools you mention would indeed be useful to a designer, I shudder to think what the output of tools meant for the incompetent might be.
14 Apr, 2009, elanthis wrote in the 10th comment:
Votes: 0
Not contradictory at all. These are very well known and widely circulated "facts" anyone who's been to a GDC would know. :p

Game design tools shouldn't just be fancy drag-n-drop editors that put code together. That's fucking useless, just like a WYSIWYG webpage editor. A scripting language IS A TOOL and it isn't meant to be replaced by other tools. The game editors should make scripting for a game engine much easier, but they would still rely on the user writing code for anything outside the game engine's default behavioral norms, as well as rely on the scripting language being well-designed and well-fitted to the domain, on the API exported by the host application being well-designed and easy to understand and use, and the template/skeleton/default code being easy to grok and modify.

A MUD editor would include a map-view for laying out areas, graphical forms for designing objects and NPCs and rooms, various report generation tools, and of course a script editor. The difference between a poor MUD editor and a good MUD editor comes down to the specifics of the UI design and the MUD itself. A MUD that doesn't let you attach scripts to individual objects but instead requires global hooks that override all objects would result in a far worse editor, because the editor is constrained by the design of the MUD. If such an editor wanted to allow the user to compose per-object script overrides, it would at some point have to compile those down into a single global-override script. It could make this very painless and easy for the end user, but at some point someone is going to try to edit the resulting global script and bitch about partly-generated code, possibly just because debugging at the point becomes a nightmare unless the editor also includes a full script grammar validation engine, API call validation, and maps MUD line number errors back to individual object scripts (which may be impossible if the server is running an old copy of the generated script). All of those problems would exist solely because the engine design is weak and not because the concept of an editor is broken.
14 Apr, 2009, flumpy wrote in the 11th comment:
Votes: 0
David Haley said:
Elanthis's point is that while you can design an engine independently from the game, it's rather difficult to do so, and you can end up with something so generic that it doesn't actually let people implement a game without significant modification. If you design the game engine and the game logic separately, it still behooves you to do so with an actual game in mind. There's nothing wrong with writing general code that is applied to a specific instance, but writing general code "in the void" without testing it on practical applications is a nice way of ending up with code that you can't apply.
Elanthis will of course correct me if I'm misrepresenting his point :smile:


Ah ok, I guess that makes sense. Yes I agree entirely.

Without an end goal in mind, you cannot make sure your engine supports everything.

However, you should not MAKE your engine support everything, but push the details to the scripts. As long as you have correct and well documented hooks you'll be fine.
14 Apr, 2009, flumpy wrote in the 12th comment:
Votes: 0
elanthis said:
Not contradictory at all. These are very well known and widely circulated "facts" anyone who's been to a GDC would know. :p

Game design tools shouldn't just be fancy drag-n-drop editors that put code together. That's fucking useless, just like a WYSIWYG webpage editor. A scripting language IS A TOOL and it isn't meant to be replaced by other tools. The game editors should make scripting for a game engine much easier, but they would still rely on the user writing code for anything outside the game engine's default behavioral norms, as well as rely on the scripting language being well-designed and well-fitted to the domain, on the API exported by the host application being well-designed and easy to understand and use, and the template/skeleton/default code being easy to grok and modify.


Pure gold dust this, very insightful. I guess tho that the "code for anything outside the game engine's default behavioral norms" needs to be called by the game tho? How would this best be done to prevent the problems you mention?

elanthis said:
A MUD editor would include a map-view for laying out areas, graphical forms for designing objects and NPCs and rooms, various report generation tools, and of course a script editor.


So an entirely separate but complementary system that sits on top of the mud engine/code base? This isn't really the mud its self tho is it. It's like having windows explorer sitting on top of the file system letting you do nice things to the code easily, but also allowing "command prompt" sometimes to edit things.

elanthis said:
The difference between a poor MUD editor and a good MUD editor comes down to the specifics of the UI design and the MUD itself. A MUD that doesn't let you attach scripts to individual objects but instead requires global hooks that override all objects would result in a far worse editor, because the editor is constrained by the design of the MUD.


By "global hooks" are you specifically talking about the hooks that Dark Gryphon mentions in his exposition? How do "oo" hook methods fit into this?

elanthis said:
If such an editor wanted to allow the user to compose per-object script overrides, it would at some point have to compile those down into a single global-override script. It could make this very painless and easy for the end user, but at some point someone is going to try to edit the resulting global script and bitch about partly-generated code, possibly just because debugging at the point becomes a nightmare unless the editor also includes a full script grammar validation engine, API call validation, and maps MUD line number errors back to individual object scripts (which may be impossible if the server is running an old copy of the generated script). All of those problems would exist solely because the engine design is weak and not because the concept of an editor is broken.


That does sound messy. So basically are you advocating an OO approach to his "gobal hook" solution?

You've certainly given me some food for thought with groovymud. Now I've not only got to think "end mud functionality" but also how to allow users to build in non script environments. I'll add it to the list.

As an anecdotal insight into this problem, I once was a trial creator on the mud Nanvaent. I could see that creating each room would be a boring and labourious task (one of the reasons I never really progressed to a real cre). I asked the question of one of the Lords at the time why they didn't have an editor such as you described.

His answer was that you end up with boring, unexciting "virtual area" type locations, that all look and feel the same. He also said that if each room is individually scripted then the creator can put all his effort into creating that individual room rather than the area layout. I tend to agree. Text games are not like graphical games on any level. Care and attention to detail need to be given to each and every room description, MOB and action. Blindly building massive, unexciting clone rooms will really not interest a mudder who takes time to explore, read, try everything and appreciates the imagination put into the descriptions of a MUD area.
14 Apr, 2009, flumpy wrote in the 13th comment:
Votes: 0
elanthis said:
My core point is that when your project is a set of code that is meant to be heavily modified by the user, there's no reason to have a separation between the "core native code" and the "user editable code." It's not like the MUD engine will be installed by a system administration to some central location and then 50 different users will be writing scripts and config files meant to be consumed by that single shared binary: each MUD operator is going to locally install the code, build it, and modify it if necessary. You don't need to force the developer to use an add-on system because he has full access to modify the core however he wants.


Apologies for posting slightly out of order but I read this second :D

I need to pick you up on that point just slightly. I believe there is absolutely a need to have a separation between core code and user editable code. Especially if you are using a compiled language such as C++ or Java. No one wants to restart the entire mud just because you want to change the description of a room, or add a new area. That would be quite annoying. Nor do I want to have to call javac or gcc every time I add a new bit of code, and have builders mess up when their code doesn't compile and take down the mud because they spelt something wrong.

This was the CORE reason I picked groovy to do groovymud, and why I used it over a pure Java mud engine like coffee mud (although I have no actual creator experience running coffee, I just hava a reasonable understand of Java).

However I probably was labouring under the misaprehension that groovy would somehow be "easier" to write than pure Java. So that idea for me has been squashed and I can now look at things slightly differently.

[edit] Also I concede there may be no reason to separate engine and editable code if (and only if) your entire mud is written in an interpretable language (performance aside)[/edit]
14 Apr, 2009, Sandi wrote in the 14th comment:
Votes: 0
Grimble said:
Yes, I'm convinced a codebase has to ship with a working game in order to have any chance of being adopted. Two obvious and related reasons for this…

1) Only a fraction of prospective admins have strong software development backgrounds.
2) Tweaking something existing (i.e., from example) is far easier than creating something new.

Make the engine as flexible as you like, but build a working game as well, and provide good step-by-step documentation on how to add a command, add a skill, add a spell, add an effect, add a script, etc. This will make your codebase accessible to a broader base of users, and reward the effort you poured into it.


It's hard to disagree with this from a DIKUish perspective, but I feel obliged to point out that MUSHes have been shipping with one room and one god character for almost two decades, and there's more of them than, say, ROM derivatives.

MUSHes are also a working example of separation between the underlying C server and the embedded scripting language. Not a fair comparison, perhaps, as we're basically talking about solo projects here, and MUSHes have had hundreds of very keen eyes pouring over their code for a long time, but they do prove that it can be done, and strongly suggest that more many folks who want to make a game, it's a Good Thing.
14 Apr, 2009, Cratylus wrote in the 15th comment:
Votes: 0
flumpy said:
This was the CORE reason I picked groovy to do groovymud, and why I used it over a pure Java mud engine like coffee mud (although I have no actual creator experience running coffee, I just hava a reasonable understand of Java).


cm is really worth looking at closely.

http://www.zimmers.net/home/mud/grinder....
14 Apr, 2009, Pedlar wrote in the 16th comment:
Votes: 0
Dark Gryphon, I have been working on a C++/Lua Mud for the past 2-3 weeks or so, C++ handles my socket, and then all the mechanics and stuff are in Lua, Id be intrested in seeing your project succed so if you wondering of any tricks with Lua, hit me with a message on here.

Currently My MUD has a fully working Nanny, Rooms, Mobs, Players, and I even designed a scripting feature to run Lua SandBoxed inside of Lua for mobs progs and such. and alot of other little things.
14 Apr, 2009, Dark Gryphon wrote in the 17th comment:
Votes: 0
In rough order, and trying to answer everything…

elanthis said:
if you don't have a specific MUD in mind while developing your codebase, you'll end up failing to deliver the key features needed to implement _any_ specific MUD. e.g., you end up being directionless, and you never end up making anything truly useful to other developers. That is bad. Design a specific MUD _first_, then write a codebase to support it. If your overall goal is to produce a solid codebase, then keep that MUD relatively simple and small in scale, but still have one none the less.


Thanks for this! I have been thinking about precisely what I want my MUD to be though. There are so many worlds out there, ready for use. As an example, Elizabeth Haydon's Rhapsody and Prophecy books, which I like very much, describe a brilliant world, almost completely ready for use in a MUD.

elanthis said:
an open source MUD is only complicated by making core feature infinitely configurable through external finals, because all you're doing is adding thousands upon thousands of lines of code and making the user learn several different file formats, languages, and application-specific schemas, and all you've done is made a more complex replacement for the language itself.


Hmm? Users will be programming purely in Lua. There will be NO file formats that they ever need to touch - only objects.

elanthis said:
The second you mention XML files mapping things between C and Lua I know you're on the road to absolute failure. You've gone from needing to understand C and Lua to needing to understand C, Lua, XML, and your specific schema, all for no real benefit that a few lines in the C code couldn't have done in a more readable fashion.


You've got me wrong here. I'm going to write the code that saves Lua objects to files, in C. This is mainly to get around Lua's typing complexities. Using some sort of XML API between C code and Lua code would be crazy.

Grimble said:
Yes, I'm convinced a codebase has to ship with a working game in order to have any chance of being adopted. Two obvious and related reasons for this…

1) Only a fraction of prospective admins have strong software development backgrounds.
2) Tweaking something existing (i.e., from example) is far easier than creating something new.

Make the engine as flexible as you like, but build a working game as well, and provide good step-by-step documentation on how to add a command, add a skill, add a spell, add an effect, add a script, etc. This will make your codebase accessible to a broader base of users, and reward the effort you poured into it.


+1 ftw, to talk in the language of blog commenters across the web. I am more than willing to document, entirely, how to modify every little bit of code.

elanthis said:
Well, let's take your concept of hooks as an example…


Unfortunately, I think you've got my code wrong. Any default behaviour will be separated from my "core" code, and implemented as hooks - that's where most hook systems seem to go wrong. So, to display a room:

hooks["display_room"].run(room);


If you do not want my own display_room code, simply delete that bit of code from a file and implement it yourself. Of course, documentation will be available if necessary - although I tend to find Lua code is self-explanatory.

I have been thinking of doing an object-based approach to hooks. I'm currently thinking of exactly how to do it, in a class-based object-oriented approach.

My core code will consist of - the heartbeat code, the sockets code, the XML database code, and the hooks code. All this code should never need to be modified. Everything else will be implemented as Lua.

I do intend to implement a very cool OLC system, called The Forge. Essentially, it is an area where admin can teleport to, and be given a whole set of commands/tools to create and edit areas, items, NPCs, and anything else. It would be extensible in much the same way as the rest of the game - by hooks - so admin can implement new features.

elanthis said:
Game design tools shouldn't just be fancy drag-n-drop editors that put code together. That's fucking useless, just like a WYSIWYG webpage editor. A scripting language IS A TOOL and it isn't meant to be replaced by other tools. The game editors should make scripting for a game engine much easier, but they would still rely on the user writing code for anything outside the game engine's default behavioral norms, as well as rely on the scripting language being well-designed and well-fitted to the domain, on the API exported by the host application being well-designed and easy to understand and use, and the template/skeleton/default code being easy to grok and modify.


Definitely, +1 once again. It is absolutely useless to have a system that generates mostly un-editable code for you. I hate the idea of GUI builders for this. Nothing should ever generate code for you.

However - I am storing everything as objects. If objects can include Lua code that can be loadstring'd, I suddenly have a very useful OLC system. I can create a new "NPC type", which is actually more like a "class" in standard languages. I can then set a bunch of attributes on him - can anyone else kill him? How much HP has he got? What level is he? Etc etc. Then, I can open up a scripting editor, while still in the MUD, and type in code that explains what the NPC does when someone says something to him, where and when he moves, how he fights, etc.

@All

I'm doing this as a private research project actually - I have no illusions that people will actually use this code. It will be terrible. On top of that, almost all MUDs use Diku or some Diku derivative for their code.

Cheers,
Dark Gryphon
14 Apr, 2009, Cratylus wrote in the 18th comment:
Votes: 0
Dark Gryphon said:
almost all MUDs use Diku or some Diku derivative for their code.


:|
14 Apr, 2009, Pedlar wrote in the 19th comment:
Votes: 0
*pats Cratylus*
14 Apr, 2009, Kelvin wrote in the 20th comment:
Votes: 0
Grimble said:
Yes, I'm convinced a codebase has to ship with a working game in order to have any chance of being adopted. Two obvious and related reasons for this…

1) Only a fraction of prospective admins have strong software development backgrounds.
2) Tweaking something existing (i.e., from example) is far easier than creating something new.

Make the engine as flexible as you like, but build a working game as well, and provide good step-by-step documentation on how to add a command, add a skill, add a spell, add an effect, add a script, etc. This will make your codebase accessible to a broader base of users, and reward the effort you poured into it.

I couldn't disagree more. Look a MUX/MUSH. You start with one room, and maybe one object. There are hundreds of MUX/MUSH out there of every imaginable theme. Some have extremely complex combat systems (BattletechMUX), others are more minimalistic.

The big deal is providing good documentation. If you do that, you can start with something minimalistic, powerful, but easy to grasp and documented.
0.0/20