This one just came to mind as I was writing about Oasis. One thing we should also look into is the scalability of the MUD. For example, adding things like triggers, assemblies, quests, factions and other things that are loaded at startup is a task in and of itself. You need to track down all the corresponding parts that do loading and change them. Perhaps a more modular approach to this, where adding in a new loading sequence just means adding a couple lines of code in a specific spot to reference the rest of your code. Also, adding of new zone commands is, to put it bluntly, tricky. I remember when I was doing my Zone Mazes command how much of a pain it was, and how it confused people as to where it was supposed to go. If this section could be improved a bit, it would make things much simpler. Next, is skills/spells. As it stands, there is a maximum number and then a 'cutoff point' and if you end up needing more, you have to renumber the whole darn thing and that may throw off objects in your database, as suddenly, the skills are all renumbered. What I started to do was number my skills as SKILL_START + 1 and such, and then reference them by the + number. This means if you wanna add more room, just change the SKILL_START number. And when I save them, I save them as a skill, number 1. This also allows for easier adding in of multiple types of skills. On mine, I have skills, spells, proficiencies, and broad skills (kinda like feats in D20) I am also looking at adding in a couple more. This idea may be radical, and require a completely different vein of thinking, but if its possible, it would also help....splitting structs.h into separate files that deal with each element of the MUD. That way if you have to add something to character structs, it only recompiles files that need it. If you change rooms, it only recompiles those files. This, however, creates problems with co-dependency....But its a thought. And finally, I would like to see certain elements, like color coding/MSP/MXP support considered so that if you wanted to add them in, it would take less work. Possibly even have a framework set up for them so that you can easily take care of them. What I mean is that have it so that if I have embedded color codes, or embedded MSP codes, if the player DOESN'T want them, the MUD is able to filter them out. If the filtering is set up within the original code, it will make it much simpler for people to add onto it. That's enough of my wishlist. Hopefully it has given you some things to think about. -- Now with PGP Encryption! Ask for your public key TODAY! -- +---------------------------------------------------------------+ | FAQ: http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html | | Archives: http://post.queensu.ca/listserv/wwwarch/circle.html | | Newbie List: http://groups.yahoo.com/group/circle-newbies/ | +---------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 06/25/03 PDT