Login
User Name:

Password:



Register
Forgot your password?
Vote for Us!
auth_update crash
Dec 23, 2017, 10:15 pm
By Remcon
check_tumble
Dec 18, 2017, 7:21 pm
By Remcon
parse description bug
Dec 15, 2017, 10:08 pm
By Remcon
Couple bugs
Dec 12, 2017, 5:42 pm
By Remcon
Bug in disarm( )
Nov 12, 2017, 6:54 pm
By GatewaySysop
LoP 1.46
Author: Remcon
Submitted by: Remcon
LOP 1.45
Author: Remcon
Submitted by: Remcon
LOP Heroes Edition
Author: Vladaar
Submitted by: Vladaar
Heroes sound extras
Author: Vladaar
Submitted by: Vladaar
6Dragons 4.3
Author: Vladaar
Submitted by: Vladaar
Users Online
CommonCrawl, Yandex, Bing

Members: 0
Guests: 13
Stats
Files
Topics
Posts
Members
Newest Member
478
3,708
19,242
613
bastian
Today's Birthdays
There are no member birthdays today.
Related Links
» SmaugMuds.org » General » Coding » Elysium Custom Codebase
Forum Rules | Mark all | Recent Posts

Elysium Custom Codebase
< Newer Topic :: Older Topic >

Pages:<< prev 1, 2, 3, 4 next >>
Post is unread #21 Jun 25, 2009, 9:54 am
Go to the top of the page
Go to the bottom of the page

David Haley
Sorcerer
GroupMembers
Posts903
JoinedJan 29, 2007

:nod: That's pretty much what I did Quix. The connection objects have their own I/O buffers. Since it was line-based, whenever a line terminator came in, the line was broken off and sent to (what is basically) a callback function. Characters would (essentially) handle the callback event by sending it to the command interpreter.

Were I to redo this, I would make the callback more explicit, as well as add additional hooks for examining the actual byte stream, so that one could easily implement a telnet handler on top of it, for example, or use other protocols as you alluded to a few times.
       
Post is unread #22 Jun 25, 2009, 4:28 pm
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,639
JoinedJan 1, 2002

Since the topic well and truly drifted right off the edge of the affects overhaul, the custom codebase discussion is over here now. Hopefully a clean break even since things seemed to shift rather suddenly.
       
Post is unread #23 Jun 26, 2009, 1:05 am
Go to the top of the page
Go to the bottom of the page

Kayle
Off the Edge of the Map
GroupAdministrators
Posts1,195
JoinedMar 21, 2006

Hmm... Can we call the codebase by it's name? Maybe? Please?

Elysium. It's not that hard.. is it? :P
       
Post is unread #24 Jun 26, 2009, 10:25 am
Go to the top of the page
Go to the bottom of the page

Quixadhal
Conjurer
GroupMembers
Posts398
JoinedMar 8, 2005

Kayle said:

Hmm... Can we call the codebase by it's name? Maybe? Please?
Elysium. It's not that hard.. is it? :P


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!

Well, anyways, time for my next suggestion since Kayle hasn't told me to go away, yet. :)

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.

Anyways, I encourage you to at least use plain old integer maps to remove the need to "translate" vnums, as that's a very low cost and easy to do thing. If you want to shift away from the vnum model, the above are a couple of ways to do it, but I'm sure you could think up plenty more.
       
Post is unread #25 Jun 26, 2009, 11:40 am
Go to the top of the page
Go to the bottom of the page

Kayle
Off the Edge of the Map
GroupAdministrators
Posts1,195
JoinedMar 21, 2006

Hmmm. I hadn't really thought about that. I might have to look into this further. Maybe even pester FearItself over at AvP for some pointers since he converted his entire mud to use a system similar to this.
       
Post is unread #26 Jun 26, 2009, 12:26 pm
Go to the top of the page
Go to the bottom of the page

6Dragons
Fledgling
GroupMembers
Posts48
JoinedNov 23, 2008

Kayle said:

Wow, I really stirred up the hornet's nest with that reply. :P

Let me first say, that an affects revision for SmaugFUSS is out of the question. To make it work in a non-klutzy way, is going to be way more work than anyone here needs to be devoting. I don't want to waste months on reworking this, only to have to turn around then and update a whole lot of snippets to work with the new system. If people want to see a new base that works similarly to Smaug with a better design, sure, I'm willing to work on it. But like David said, it's not fast. And it is by no means a simple task.

I'm with David. The license has always bothered me, because the way it's worded it makes it seem like your work can never be your own. I'm currently debating restarting my Elysium codebase from scratch. If there's enough of a demand, I'd be more than willing to release it once it's closer to completion.

The more I dig through the code, the more I realize what a convoluted mess the innards of Smaug are. And the more it makes me sick of working with it. The Affects are a perfect example. Something this basic, shouldn't have needed to be interwoven into everything. And I'm really tired of things like this, and they're everywhere in Smaug.


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.
       
Post is unread #27 Jun 26, 2009, 12:45 pm
Go to the top of the page
Go to the bottom of the page

ayuri
Magician
GroupMembers
Posts239
JoinedJun 13, 2008


Quixadhal said:


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".


I hope not to step on any toes here, but you may also want to talk to Caius about that as well. I know his project has nearly the same format as zone_id:room/obj/mob ID.
       
Post is unread #28 Jun 26, 2009, 12:59 pm
Go to the top of the page
Go to the bottom of the page

David Haley
Sorcerer
GroupMembers
Posts903
JoinedJan 29, 2007

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?

He didn't say he didn't want to work with it at all ever again. This started because he doesn't want to put so much effort into a particular piece of the code, that just happens to have its tendrils everywhere. Eventually, "fixing" the stock source starts meaning, essentially, rewriting the codebase.

I still think the problem is one of a mission statement. What do you think the FUSS project is meant to do Vladaar? I'm not really sure myself, but I think that fixing fundamental design issues is probably outside the scope.
       
Post is unread #29 Jun 26, 2009, 1:00 pm   Last edited Jun 26, 2009, 1:04 pm by 6Dragons
Go to the top of the page
Go to the bottom of the page

6Dragons
Fledgling
GroupMembers
Posts48
JoinedNov 23, 2008

Yah your prob right there. Fundamental design flaws aren't really bugs, and shouldn't
be messed with for smaugfuss. Smaug is what it is, flaws and all. I love it, cause it
is what I started with. Doesn't mean I don't change it a lot for my game, but I think he
is on the right track if he dislikes it so much that he doesn't want to work with it.
       
Post is unread #30 Jun 26, 2009, 1:13 pm
Go to the top of the page
Go to the bottom of the page

Quixadhal
Conjurer
GroupMembers
Posts398
JoinedMar 8, 2005

Oh, one other idea that I though of last night and just remembered.... it's one I've expressed before.

Diku-type muds load everything into memory at boot time and then make duplicates of them to use in the game. Typically, the version that was read-in from a file is called a "prototype", and the instances that end up in the hands of players are clones. Quite often, mobs and objects will have variable stats or fields which may change/decay over time. There's even a "strings" command to customize specific clones.

Ok, so in most Diku codebases, you might want to use the OLC system to modify a single instance of an object, rather than a bunch of hand-tweaks with strange seldom-used commands. However, they don't make it easy to specifiy that you're editing the clone vs. the prototype. They also confuse the issue by having a "prototype" bit which doesn't seem to really be what it sounds like it should be.

My suggestion is to give every object an identifier (if you're using vnums, that's it). Then give every object an extra identifier field for its clone number. Why?

If you have an instance ID, you can always know that instance ID 0 is the master copy. So, you can point the very same set of tools at the template OR any copy to change it. It also lets you disambiguate objects when there are a whole pile of them in one place. You can know if someone ever discoveres an equipment dup bug, since you'd never normally have two things that have the same vnum AND the same id. It also gives you way to quicky see how many of a thing have ever been created. If you know the highest longsword to exist is 17622, but the highest battle axe is 2453, either longswords are more popular or the mobs that carry them are killed far more often.
       
Post is unread #31 Jun 26, 2009, 1:29 pm
Go to the top of the page
Go to the bottom of the page

Quixadhal
Conjurer
GroupMembers
Posts398
JoinedMar 8, 2005

6Dragons said:

Yah your prob right there. Fundamental design flaws aren't really bugs, and shouldn't
be messed with for smaugfuss. Smaug is what it is, flaws and all. I love it, cause it
is what I started with. Doesn't mean I don't change it a lot for my game, but I think he
is on the right track if he dislikes it so much that he doesn't want to work with it.


Let me ask a counter-question. If it's agreed that design flaws are out of bounds, and we see that there aren't many real "bugs" left to fix that are NOT related to design issues... what is left to maintain?

It's hard to be enthusiastic about heading a project where there's nothing to do for months on end, and then a tiny bug is found and fixed in a day, or discussed and determined to be out of bounds, and more months go on.

I would hazard a guess that Kayle likes the way Smaug feels, and the way it acts. Much like a sports car, it looks great and handles great, but maybe when you get under the hood, you start seeing things that make you cringe. You aren't allowed to rip anything major out, and you can't really add anything new either. All you can do, is replace the belts, check the fluids, and keep it running.

At that point, you can either fork a derivative and start doing all the major systems overhauls and rewrites, but still be bound by all the licenses of everything that came before you, or you can make a clean break and build a new car, taking inspiration from all the cool things you saw, and hoping to make it look and feel as cool as the original, but doing it yourself.

Does building your own car mean you aren't allowed to work on anyone elses? I hope not. I would hazard a guess that Kayle can do a good job of maintaining SmaugFUSS while planning and then working on his own Elysium codebase. If bugs actually start piling up and not being addressed, then it'd be time to start getting out the torches and pitchforks.

In any case, I'm throwing ideas here because starting a new codebase is a lot of work. Thinking about all kinds of things early on is the best way to not get stuck trying to do things a particular way just because that's how you've seen it done before. None of this applies to SmaugFUSS, which is why Samson rightly spilt this into a seperate thread. :)
       
Post is unread #32 Jun 26, 2009, 1:40 pm
Go to the top of the page
Go to the bottom of the page

David Haley
Sorcerer
GroupMembers
Posts903
JoinedJan 29, 2007

quixadhal said:

Let me ask a counter-question. If it's agreed that design flaws are out of bounds, and we see that there aren't many real "bugs" left to fix that are NOT related to design issues... what is left to maintain?

Sometimes projects actually *GASP* finish their tasks. :wink:

Seriously: if the mandate is to fix bugs as they are found, and bugs are very rarely found, isn't that actually an indication of having succeeded to a very large extent?

I don't think people should look for things to do just because they've succeeded in their task. When you start doing that, you are no longer working on the same project, but something else entirely.

An appropriate analogy, perhaps:
If your job is to maintain a train so that it works, and you do that successfully, fixing loose nuts and bolts, will you start redesigning its steam engine flaws just because there are no loose bolts to tighten?
       
Post is unread #33 Jun 26, 2009, 1:43 pm
Go to the top of the page
Go to the bottom of the page

Tonitrus
Fledgling
GroupMembers
Posts47
JoinedJun 24, 2009

Kayle said:

The more I dig through the code, the more I realize what a convoluted mess the innards of Smaug are. And the more it makes me sick of working with it. The Affects are a perfect example. Something this basic, shouldn't have needed to be interwoven into everything. And I'm really tired of things like this, and they're everywhere in Smaug.

This has always irked the hell out of me as well. I'm currently resolving that, in fact. I basically wrote functions for all interactions with affect_data and smaug_aff and did a find/replace on all pointer interactions with the structures. When I was confident I'd removed everything, I stripped the structures from mud.h and hid them away in a place only affect.c (where I put the wrapper functions) can see. Naturally I missed a bunch of spots. It's a bit of an annoying change to make, but no more irksome than running through a snippet.

I don't know how the rest of the smaug community would feel about this, but you could have the code for my wrapper functions, if you want (not that they're particularly complex).

(Not to get off-topic, I just saw that quote, and felt like suggesting this)
       
Post is unread #34 Jun 26, 2009, 4:22 pm
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,639
JoinedJan 1, 2002

Ok. Without going into a whole mess of deep discussion, some brainstormy type stuff I'd personally like to see. In no particular order of relevance.

* 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.

* The ability to read existing file formats, or a loosely attached utility command that will convert from other formats into Elysium format.

* 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.

* 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.

* 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.

* 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.

* Randomly generated zones. The MMO folks refer to them as instanced zones. Best used as filler in an ANSI map system.

* Combat with locational body part damage, limb regeneration, etc.

* 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.

* 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.

* 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.

* 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.

* 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.

I'm blanking on more, and I realize all this is pretty high level stuff that won't get done until there's actual places for people to walk around in, or even people to do that. Or even a command system :P But I figure it's better to spit it out now than forget about it when the time comes.
       
Post is unread #35 Jun 26, 2009, 9:10 pm
Go to the top of the page
Go to the bottom of the page

Quixadhal
Conjurer
GroupMembers
Posts398
JoinedMar 8, 2005

Samson said:

* 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).

Samson said:

* 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).

Samson said:

* 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.

Samson said:

* 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. :)

Samson said:

* 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).

Samson said:

* 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.

Samson said:

* 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.

Samson said:

* 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. :)

Samson said:

* 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).

Samson said:

* 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.

Samson said:

* 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).

I totally agree with the player crafting/vending systems. My favorite MMO's have been the few with player-driven economies, and I've always though that the very best gear should come from crafting (using rare materials that have to be obtained via adventurers), and from the epic raid concepts.

Hope that made sense, I wrote some bits a few hours later than others. :)
       
Post is unread #36 Jun 26, 2009, 9:26 pm
Go to the top of the page
Go to the bottom of the page

Kayle
Off the Edge of the Map
GroupAdministrators
Posts1,195
JoinedMar 21, 2006

Sometime tonight or tomorrow I'll hopefully have time to sit down and respond to all these ideas... damn sockets...
       
Post is unread #37 Jun 26, 2009, 10:44 pm
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,639
JoinedJan 1, 2002

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.
       
Post is unread #38 Jun 27, 2009, 6:27 pm
Go to the top of the page
Go to the bottom of the page

Quixadhal
Conjurer
GroupMembers
Posts398
JoinedMar 8, 2005

Samson said:

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.
       
Post is unread #39 Jun 27, 2009, 7:07 pm
Go to the top of the page
Go to the bottom of the page

Kayle
Off the Edge of the Map
GroupAdministrators
Posts1,195
JoinedMar 21, 2006

Damnit, quit talking. :( I'm trying to write a reply and you people keep adding more!!!
       
Post is unread #40 Jun 27, 2009, 9:02 pm
Go to the top of the page
Go to the bottom of the page

Kayle
Off the Edge of the Map
GroupAdministrators
Posts1,195
JoinedMar 21, 2006

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

Quixadhal said:

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.


Quixadhal said:

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.


Quixadhal said:

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.


Quixadhal said:

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. ;)


Quixadhal said:

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.


Quixadhal said:

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*


Quixadhal said:

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. :P 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. :P


6Dragons said:

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.


Samson said:

* 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.

Quixadhal said:

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.


Samson said:

* The ability to read existing file formats, or a loosely attached utility command that will convert from other formats into Elysium format.

Quixadhal said:

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. :P


Samson said:

* 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.

Quixadhal said:

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.


Samson said:

* 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.

Quixadhal said:

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. :P


Samson said:

* 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.

Quixadhal said:

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.


Samson said:

* 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.

Quixadhal said:

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?


Samson said:

* Randomly generated zones. The MMO folks refer to them as instanced zones. Best used as filler in an ANSI map system.

Quixadhal said:

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. :P


Samson said:

* Combat with locational body part damage, limb regeneration, etc.

Quixadhal said:

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. :P


Samson said:

* 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.

Quixadhal said:

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. :P See earlier point in response to Quix's first idea post. :P


Samson said:

* 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.

Quixadhal said:

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. :P


Samson said:

* 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.

Quixadhal said:

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. :P


Samson said:

* 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


Samson said:

* 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.


Samson said:

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.

Quixadhal said:

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. :P

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]
       
Pages:<< prev 1, 2, 3, 4 next >>