Oh yeah, one other thing... you mentioned being able to read SmaugFUSS area files. That's actually something you have a choice on.... you could embed support for that OR you could include a converter application that translates Smaug areas to whatever target format you are using. I have a beastie I wrote for my own game that you could poke at if you want (although it's not pretty).
You might want to consider what you DO want for a storage backend as you get started too. Are you happy with flat files and the loading/saving routines? You could also use an object database and just directly load/save things. You could use a relational database as well. They each have their pluses and minuses. Object databases are simple, but they are a mysterious black box that you can only really interact with via the MUD. RDBMS are powerful and let you do all kinds of statistical analysis (great for balancing!), but you have to plan your data structures and handle writing queries. Flat files are... simple and dirty quick.
If you do go with flat files, you might consider making the format something that would be database friendly, just because if you can easily upload your data to a database, you can run the statistical analysis queries on it -- and you don't need it to be real-time live, to be darn useful.
Oh, by database friendly, I mean sticking to simple key/value syntax. None of this multiple-values per key nonsense!
Attr 3 18 7 12 10 13
David Haley said:
FWIW, I didn't say that a system shouldn't be modular with the ability to add/remove optional features via plugins or things like that. I was saying that the idea of maintaining snippet compatibility as they're currently thought of (as in, go to this line, replace this with that, etc.) is a bad thing for future development.
In fact, I'll make a slightly stronger statement, and say that a good codebase really should support modularity of various features to whatever extent possible, unless it means going through unacceptable contortions.
Also, in an unusual stance for me, I find myself 100% in agreement with David on this one too.
I think the whole concept of "snippets" has held back development of quite a few codebases for years. The fact that people expect snippets to apply cleanly as a diff, and that they won't even do things like run the source through indent for fear that it will break "all the snippets", screams bad mojo to me.
Using C++ means you can't rewrite half the game directly from inside (which is fine, we have LPMUD for that!), and so the idea of having things be module and easy to add at compile time is a good one. However, if the code is written cleanly and has well documented API's, any reasonable programmer should be able to see how to change what they want without needing to pray to the diff/patch gods.
One example that comes to mind is a recent discussion of the "nanny" function, which is simply the plate of spaghetti code that handles what to do with input over the sockets, based on player (or descriptor) state. Right now, DikuMUD's have a very messy function that lets program flow meander up and down a huge case statement. It would be far nicer to write this as a dispatch table, so you simply name your states and call the appropriate function. If that is done cleanly, it becomes easy to add things like an account system, or an extra menu input system.
I hadn't really stopped to think about all the things I'm going to have to write that I'm not very good with. Anything dealing with Strings really. Although, std::string might make things a bit easier...
Strings are a PITA in C, and they're still mildly annoying in C++. Personally, I'd be tempted to write the whole mud in Lua (or perhaps ruby) with an embedded Lua scripting engine.
However, C++ is probably the right choice for a codebase that will achieve a broader audience and it also makes it simpler to convert chunks of existing code (such as the combat system), from your existing game. I use "you" there to refer to the potential adopter, not just you as the author.
So yes, I would go so far as to say to use std::string everywhere, and only fall back to char *'s in those few places you MUST interact with OS routines. In fact, if you can find good public domain socket classes, use them!
I've looked at a couple small C++ codebases (SocketMUD++, Nick Gammon's tinymudserver), and while they all do the job, they also have a lot of C in them. I'm going to guess that means it's not easy to find public domain socket classes, otherwise I can't imagine why anyone would willingly leave ugly select loops at the heart of their main program loop.
Lastly (for now), don't be overwhelmed by the flood of ideas and things to think about. Writing a codebase from scratch is a big undertaking, and you shouldn't write ANY code until you've sat down and at least sketched a bit of a roadmap for yourself. That said, start with the basics. Get a server process running that catches signals and starts up/shuts down cleanly from SIGTERM. Then add config files and command line options, keeping it simple. GNU's getopt() works well for things like "--port 3000". Then add sockets and see if it all still feels modular and clean. If it does, you can head for the command dispatcher and parser, if not... refactor and ponder a bit more.
Because people will ask... you should consider what development environment(s) you plan to support now, at the start. Classic hand-rolled Makefile? Autoconf/configure script generated? MS Visual Studio project files? That last one is probably a pain, but there are Windows folks out there who will ask for it. It's fine to tell them to bugger off (or ask them to provide one), but don't be surprised by it.
Anyways, it should be fun!
Sorry for the book-length posts... we're gonna need our own index if this keeps up!