Alright, I'm going to start by saying god damn you people talk alot, You've turned what I had hoped to be a quick post into something that's going to take me HOURS to finish. Just to prove my point. It's 8:31pm EST when I'm writing this first sentence.
Now, on to the juicy innards.
I know I've already responded to these, but I felt the need to revisit them
1) Design your game with OLC in mind from the start. If you can, make the OLC system as modular as possible, so people can use it via commands (like smaug), via menus (IE: oasis), or even via a GUI using ZMP or something of that sort.
I love to be able to make things online. My goal is to have it so that short of adding actual functionality or new item types or what not that you can do it all from in the game. Languages, Spells, Abilities, Rooms, Mobs, Objects. I want as much as possible to be creatable from inside the world. When you add Lua into the mix, if people were particularly inclined EVERYTHING could be OLC. Entire systems could be written in the scripting engine if people were so inclined.
That said, my plan is to provide both a command line interface, and then via a toggle in some kind of player config command, an option to switch from command line to menu based editing. As for the GUI using ZMP, I'm not sure about this yet for a couple reasons. One, I haven't decided on how to store information like areas, etc. Flat files are by far the easiest for portability. But for things like Web-Based building, MySQL or similar would be better but less portable. So.. I dunno. Maybe have support for both and have a toggle somewhere in the Makefile or the MUD to specify which to use. *shrug* Still too early to make a call about that.
2) Try to make use of the concept of a "thing" wherever you can. One of the problems that's always plagued DikuMUD is that there are hard-and-fast rules about rooms/objects/mobs, and they're all special cases. If you think about it, a room is just a container whose environment is the zone. A zone is just a container whose environment is the world. A sword is a container whose inventory is sized 0.0 and has no enterances or exits.
Seriously, think about that. If you can derive all physical objects in the game from a single "thing" class, and put most of your physical properties there, you will be able to do all kinds of things later on that would need a bunch of special case code now.
Like I said before, I'm all for a good inheritance model. But at the same time I worry that too much OO design, might make a steep learning curve for those that pick up Elysium for their MUDs. And at the same time, I can't help but think about all the joys of having an OO design. For instance, there was a discussion on IMC not too long ago about the way Object Values are done, and that an OO approach to that would be a much more flexible system. Instead of having a field of 5 or 10 values that all item types use. Make the item types themselves have their own fields that are available to be set based on the type of item. Poor example, but I'd have to scour the IMC logs to find the actual discussion. Davion was the one that pointed this out though, so if he pops his head in over here sometime and reads this thread, maybe he'll be able to elaborate on that.
3) Mobs and players should be interchangable! I can't tell you how many times I've cursed the Diku folks for having their data structures be different. If you make them the same, it's dirt simple to switch control from an AI script to a command interpreter. That lets people choose how they want to handle things at the game layer... if you want named NPC's to show up in the who list, done. If you want players to become NPC's when they log off... done.
Related to this... split the body structure away from the control structure. If you can just create a new body and swap pointers, things like polymorph/possession/reincarnation, all become simple.
The first part of this one, I understand and agree with almost completely. But the second part I'm not sure I'm wrapping my head around completely. Are you saying have a field on the class that points to whether the Mob control system is in control, or whether an external connection is in control? A little more detail into what you meant might help me understand.
4) Don't limit yourself to TELNET. Sure, you'll want to code a telnet state machine to be compatible with most current users out there. Just don't limit things to only line-mode, or make it impossible to add SSH support later. Make it easy to add ports for other services, as you may find yourself wanting them later.
Well, a good telnet state machine won't be hard to come by, I'm likely going to make use of the LibTelnet stuff that Elanthis released not so long ago over at MudBytes. As for adding SSH support, I wouldn't even begin to know where to start for that anyway. But once I have a solid foundation going, if you wanted to add support for SSH and maybe update it to be easy to add ports for other services I wouldn't object.
5) Integrating Lua is fantastic. I would suggest embracing that language and if people want support for mprogs or similar, they can alwasy write Lua code to handle it.
I probably covered this before but originally I was looking at embedding Lua in Smaug as a replacement for MudProgs. Since then, and after many discussions with FearItself@AvP, I've decided that being able to write actual game logic outside of Progs is a must have. I want to have the ability for immortals to be able to write commands, or even entire systems in Lua if they wanted to, in addition to just writing scripts for their mobs to be diverse and active.
Yes, but it gets that Beatles song stuck in my head... Elysium Fields, which makes me think of Strawberry Fields, and now (hopefully) you hear it too... Muahahahaha!
I'm gonna pretend I'm old enough to get your reference, and just smile and nod so you feel better. *smiles and nods*
The traditional Diku model for handling in-game things is to assign them a "vnum". This stems back to the fact that the original Diku team didn't understand advanced data structures, and were working in the hostile environment of C. So, under those conditions, the two easiest to use were arrays and lists.
If you've worked with the original, you know that everything is loaded at boot time from a small handful of files, tinyworld.wld and friends. The rooms (and everything else) are loaded into arrays that are allocated by one big fat malloc() call and there was no "OLC". Instead you counted rooms quickly by doing a grep for the "#XXX" lines, then did a malloc and read the file, start to finish, stuffing the data into the array slots as you went.
Now, because one boot to the next might change as you edited the file, you needed a translation from the "rnum" (array index) to the "vnum" used in the files.
In C++, we have std::map. If you use an integer to index your map, it becomes a sparse array, which is what vnums really wanted to be. So, if you have vnums 3001, 3002, and 15007, your map is only 3 elements in size. Wonderful!
But wait, there's more! If you order now, you could receive the idea of using a string identifier that's built of a combination of the zone ID + the room/mob/obj ID. Thus, instead of assigning vnums to zones, you'd just enumerate them as "12:3000" or even "Grasslands:3000".
There's another option though... you could eschew the idea of using vnums and instead use identifiers. Using a string as your index, you could call your rooms "orc23", "bigrock", "A maze of twisty passages", or even "/zone/smurf village/rooms/gargamel_castle".
The last would place you more in the LPMUD camp, but it's perfectly feasable, even if you don't use actual files and directories as storage.
Attempting to break this up into smaller pieces was a pain in the ass, so I gave up.
Anyway, I was going to venture away from vnums anyway. And instead venture into the realm of virtual IDs. FearItself@AvP has a fantastic looking implementation that I'd like to mimic. I attempted to get an example but was unable to find one. Or get ahold of FearItself to get one from him.
Maybe sometime later I'll actually get one and touch on this subject again.
Perhaps if you hate smaug code to the point you don't want to work with it, I know
you didn't use that exact termiology, maybe someone else should take over smaugfuss? Good luck with the codebase from scratch, you got the talent to do it.
Just because you don't like working with something doesn't mean you stop. If you don't like your job, do you just quit and go without? No, just because I don't like the way Smaug is written doesn't mean I'll stop working with it. Just like Samson never stopped working on SmaugFUSS while working on AFKMud, I'm not going to stop working to make this as good as it can be with all it's flaws just because I'm writing Elysium.
* Area files which are flexible and don't collapse if one byte is out of place. Like how the KEY/VALUE system FUSS uses works.
Agreed. If you use files, they should be as easy to parse as possible, and I'd even go so far as to say one value per key (IE: split attributes up into str/dex/con/etc... easier upgrading and no "magic" ordering to remember).
I'm completely in favor of this one.
* The ability to read existing file formats, or a loosely attached utility command that will convert from other formats into Elysium format.
Yep, either way works. A converter is slightly less intrusive since you don't need the extra conversion code hanging around the game server (especially if flat files aren't even used).
My plan was to actually get the base into a connectable state with at least very basic rooms, objects, and mobs and then begin to think about either having something like AFKMud's areaconvert command, or just have a converter program available on the side. But, I'm not very good with the GUI side of C/C++ so I dunno how I'd work that one.
* Some sort of plugin architecture. So you can drop compiled modules in and the game will load them on demand, without rebooting. With the ability to UNload them on demand as well. Useful for things like IMC, fancy OLC protocols, etc. AFKMud has the partial ability to do this with DO_FUNs but those are usually pretty well isolated to begin with. Systems like exist in Wordpress for example. I honestly don't know how feasible this even is in a MUD.
Loading isn't too bad, the dlsym system can be expanded to handle that. Unloading is slightly trickier, since a dispatch table entry to a function that gets unloaded is a time bomb. If the Lua engine is robust enough, some things could be implemented that way, which would be dynamic.
I'm all for Modularity. And actually this sort of thing was suggested on IMC the other day. Not sure in the slightest how to accomplish it, but it will most assuredly be on my list of things to at least research if not do.
* A command structure that's based on permissions. Your level should have nothing to do with this. Builders should get commands useful for building. PR/Enforcement people should get commands useful for that. Someone being level 108 should not mean they get to ban people and modify half the areas in the game, unless someone on the admin team specifically wants that.
That's one I've been advocating for YEARS. I would probaby do this as a set of groups (using std::set perhaps). If your character/account has the "builder" flag, you get this group of commands... if you have the "admin" flag, you get these other commands... having one doesn't imply the other.. so an admin might be able to kick people or snoop them, but not use OLC.
You might even want to have a "player" group, so new characters could have a restricted set of commands... just keep the system flexible enough so every command requires one group, and every player can belong to more than one. A player with no groups at all might only be able to quit.
I'd been planning on doing just this. But I haven't decided on exact specifics for the release version of the base. for MW, There will be 65 levels total. 60 of which will be Player levels, but we have a sortof D&D 3rd Edition inspired Multiclassing thing going on that's a tad hard to sum up in a few words so we won't go into that. But 5 of them will be the Immortal levels. Each level will have several permissions settings in addition to the level. But you won't need the level in question to receive the permissions for that level. For instance, a very trusted 61 could be given level 64 admin perms or something. This might be wrong, I can't find my notes on these atm.
* ANSI wilderness that's actually more useful than just pretty colors. The ability to cut wood, mine gold, plant crops, build houses, and have all of this dynamically stick to the game past reboots. If a custom game client is involved, make the ANSI look better with a custom font that produces actual symbols for trees, grass, water, etc.
I'll omit the word ANSI and agree with everything else.
Some folks really like an ANSI wilderness with no descriptions, and having that possible is a must-have nowadays. I'd also like it to be flexible enough to take that same wilderness and render it as normal rooms though.
Essentially, think of old strategy games like conquer or empire. Give rooms properties for resources that can be found with the right tools and/or skills. Make the property system flexible, so adding a new one doesn't require redoing the world files, just initially there are no "candy wrapper" nodes until you start adding that property (or have a script do it).
I'm still a bit torn on this one. On one hand I like the diversity an overland system gives, but at the same time I hate it. So.. I dunno about this just yet. If I/we manage to get the modules system into a defined shape, I wouldn't be opposed to someone writing a module to handle overland. On the flip side, I really like the idea of being able to have the ANSI Overland rendered as regular rooms too, but that might get taxing memory wise if the maps were large.
* Rivers with actual currents. I doubt this needs explaining. Smaug sort of has this, but the system by which you'd mimic it is unwieldy and also doesn't work on an ANSI map between zones.
DikuMUD had this, or at least WileyMUD does. It is a bit of a kludge though. Very similar to the falling code for air rooms, and the teleport code for teleport rooms.
Sounds like a good idea, but how would one determine where the current would flow? that would kindof require coding in some sort of elevation determining stuff and what not wouldn't it?
* Randomly generated zones. The MMO folks refer to them as instanced zones. Best used as filler in an ANSI map system.
Actually, instancing is seperate from generated. You can instance a zone that's identical to any other instance, or you can randomly generate a zone that is public. I agree that both should be feasable. Instancing lets you do private dungeon crawls for a group, and is a great way to avoid kill steals and camping. Random content generation is also nice for missions to "go kill 50 ogres", and helps keep the bots out. You can certainly use both at once, if you like.
This was something that I had planned to at least attempt. Both the instancing of areas, and randomly generated areas. But I'm so lost on how to even go about accomplishing it.
* Combat with locational body part damage, limb regeneration, etc.
I agree. Just make sure you can fall back to non-limb-based for those who hate it. The more modular we can make combat, the easier it is to change things without cursing the developers for intertwining everything and its brother into fight.c.
Hmmm.. I don't know that locational damage had ever been discussed when we were talking about how to design MW's combat engine, but.. Uh.. MW's Combat System Idea Description
can be viewed here. Hmm. Since I just linked to that one, I might have to move some of the other Idea descriptions into a publicly visible forum that people other than MW staff can see. Well, Samson can see them all right now if he were to go to the Sovereigns > Discussions forum and browse through.
* OLC that doesn't suck. Hard to quantify, but the current mixtures between command driven and menu driven OLC are all hard to work with. Perhaps some form of web based point & click system would work. Might entail needing to have area files stored in a DB instead of flat files. There was talk recently somewhere about a tile based map system, this would be one hell of a cool thing to have.
For this one, it would be easier if the game data were in SQL. Either way though, you probably don't want to edit live data via the web, so either a test port or an export of the live data (to be re-imported later).
My goal is to have an OLC that doesn't suck. But we'll see.
See earlier point in response to Quix's first idea post.
* Scripting language. Lua, Python, Ruby, whatever. Perhaps if tied in properly with a plugin/modular system you could have the ability for people to pick and choose which ones they want and perhaps even multiple systems.
I'll actually advocate sticking to one, and for just one reason. Passing data back and forth from C/C++ to an embedded language is a pain. It's supposedly less of a pain in Lua than Python, but still a pain. I think it's probably wise to do it really well for one langauge, rather than trying to juggle all the various transforms between Python -> C++ -> Lua -> C++ -> Ruby you might have if multiple scripting engines all want to poke at the same data.
Yeah, I'm only going to have support for Lua. Having more than one would be a pain in the ass to keep up with, just like having MudProgs AND Lua in SmaugFUSS would have been a pain in the ass.
* Proper guilds/clans. Right now this stuff is mostly window dressing and is used almost exclusively for pkill tracking. Got me as to what specifics this should involve other than allowing a sufficiently powerful guild/clan to erect a hall somewhere.
Tie into this with player owned housing, giving people the ability to describe things, for a fee (perhaps).
No idea how to make these properly either.
* Player crafting system. Expanding on the ideas I already implemented for AFKMud's Diablo inspired system. Take it beyond just stuffing runes and stones into slotted weapons. Make it possible to mine ore (tie in to maps) and smith your own gear from nothing.
Hmm. *takes a moment to review the Tradeskills thread on the MW site to see if it's worth moving....* Eh, Why not. So, this is the idea for MW: MW Tradeskill Idea Description
* Player owned shops. Perfect tie-in to the above. Players could take the crafting system to the next logical level and go into business selling the stuff they're making, giving people an incentive to go find stuff to do that with.
Hadn't thought about this, but I don't see why that couldn't be done too.
Something else I thought of - bug logging that gives a backtrace with actual readable function names and line numbers. dunno how that works with scripting, but with the C++ core it's a pain in the ass to see a junk backtrace with some random address and offset.
Yeah, that may be a challenge to tackle very early on. I've seen C versions (most of which ONLY work in linux, using backtrace() and backtrace_symbols()), but C++ does this funky symbol name mangling thing to try and allow namespaces in a way that things linked against C libraries can still deal with.
No idea how to go about this, but if someone wants to come up with a way to do it once I get a tangible workable foundation going they're more than welcome to.
Alright, well, due to my incredibly short attention span this took far longer than even I thought. XD But.. there. it's all responded to.. I think. [Time of Completion: 12:04AM EST]