Good reply! We gave you stuff to read, eh?
I worry that too much OO design, might make a steep learning curve for those that pick up Elysium for their MUDs.
I wouldn't be too concerned. There are still people starting up brand new LP MUDs, and there you not only have to warp your head to the idea of OO design, but you also have to work around the peculiarities of driver-imposed limits that we Diku people never worry about. In an LP, you have a limited number of execution ticks to process whatever you're processing, and then your thread is killed. If you can't finish the job in that limit, YOU have to figure out how to break your task up and schedule a call_out() to pick up where you left off. They also have to deal with recompiling lpc objects on the fly and how to go about updating all the things which inherit them.
In short, design it well and people will use it. Try to make it look (at a code level) like something else, and it'll just be another derivative that people hack a bit and then cry because snippet-foo won't compile cleanly.
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.
Sure. Currently, the Diku model doesn't allow for swapping control around at will. You can, using things like "switch", take control of an NPC, but it doesn't disable their AI routines, it just passes what you type along to the command interpreter, but run with the NPC as "ch" instead of you. Likewise, there's no way to dynamically switch AI routines, or assign one to a player who has gone linkdead.
To take it another step further, the nanny() loop is a big state machine that does junk and flips around states on a descriptor. If you abstract that so every state if just a function call (rather than chunks of an ugly switch statement), you're one step away from a dispatch table. Now, instead of using switch() or if/then/else, instead just store a pointer to the correct interpreter function in the descriptor. If it's not NULL, call it and pass the command arguments in. Done.
Ok, let's move that down a notch. For a player, they'll have a descriptor pointer that points back up to their connection data. An NPC will typically have this be a NULL pointer, since they don't have connections unless they're being controlled (IE: possessed). If you place a command pointer in the player/npc strucutre, it would work just like what I described for the connection/nanny one. The player one would normally point to interpret(), although it might also point to editor(), or something else. The NPC one would normally point to whatever npc AI is normal for that kind of creature (warrior_ai(), orc_ai(), etc). If I charm an orc, you'd store away the old pointer and now it points to charmed_ai(), which may do nothing but try to break the charm every so often... but it would also be a hook for the "order" command to use.
Now, if the orc shaman charmed ME, *I* would be the one who gets their interpreter switched, so now instead of interpret(), all my input goes through charmed_ai(), until the charm wears off. Similarly, if I go linkdead, the game could switch me over to an AI routine that would try to do things to keep me alive until I can reconnect.
It may be that you need both fields... because if your character is AI controlled, you want it to do stuff every so often without you typing. But that's an implementation detail.
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*
Ok, you asked for it! LINK!
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.
I'm also terrible at GUI's... but I wrote a mean C format converter to go from my old DikuMUD format to a text report, PNG map files, or a partial LPMUD conversion. I also wrote one in perl which is better designed, but doesn't work as well. *grin*
* 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.
I think you missed our point on this one.
Players have levels, NPC's have levels, immortals don't have levels. Immortals have responsibilities, and the command structures *NEED* to be grouped logically, and given out according to those responsibilities. Using levels for this is absurd.
I mean, why should a level 103 immortal be able to do OLC but not be able to snoop/kick people, where a level 104 immortal can do both? Maybe you want immortals who can act as sherrifs and snoop/kick people or reimburse people, but don't EVER want them within 20 feet of the OLC commands. By the same token, you don't really want every single builder to have access to snoop, do you?
I know there's that whole "trust" system to dish out commands, but that's not really good either. You don't want to hand out single commands, you really want to grant people abilities which are grouped by function. If I want someone to have goto/trans, I really want them to have "travel powers". If I want them to have medit/oedit/etc, I really want them to have OLC.
Leave the levels alone... let a level 3 immortal fight a level 5 player and lose, there's no reason to link level with permissions. If some admin wants all his staff to have "finished" the game, that's his choice to not hand out permissions to people until they're max level. The code shouldn't influence that, IMHO.
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?
The code I have had a "flow-to" direction... essentially, every few seconds anyone standing in the river would be forced out the exit that flow-to pointed towards.
Elevations would be cool, but also probably unused by 90% of people. *I* would use them to punish people by making a city on a hilltop really hard to attack, because snow + uphill == very slow movement. But I'm evil.