View Single Post
Old 04-08-2008, 03:14 PM   #17
shadowfyr
Senior Member
 
Join Date: Oct 2002
Posts: 310
shadowfyr will become famous soon enough
Re: What do you think happened to LPmuds?

I think part of the problem is that there really isn't a *usable* stable core you can start with when using LP. I don't know of anyone personally that didn't modify damn near everything from the combat code to the inventory management for players, to the spell/skill lists, etc. By the time you debug the stuff that didn't work well in the original library and add it stuff that isn't cookie cutter code, the odds of you having anything *remotely* similar to anyone else's code is nearly non-existent.

Imho, to do what LP intended, and at the same time have a solid reusable code base, there needs to be a core library that works for "everyone", which won't change much, unless its to fix bugs, **but** which also allows enough flexibility to do significantly different things, if you want to. To take an example from OSes, you might have a core library with "default" behaviors for how a window works, which doesn't need to be changed for most uses *but* you could then skin the window, and/or alter a lot of its behaviors, if you wanted to. So, in mud terms, this means you have the "base" combat system, but if you want to, you tack on an override to that, so that certain mobs behave via your "new" system. By isolating things such that they only effect those npcs, items, etc. that "need" the new code, your new whatzit becomes plugable, not something that is unusable to everyone else. At worst, you might need to have your DB, or how ever you store player, and other, data, add some extra records for "that" feature, but the core library remains intact, the main data remains intact, and the result becomes something you can drop into any world.

This is in contrast to what has been described as the current method, which rewrites the entire system of functions and calls, such that changes to one feature cascade into ever other feature, rapidly making the code non-reusable for everyone else running the driver. Imho, a system that modularizes things from the ground up, with some level of independence between modules and data storage for them, is *bound* to be easier to debug too. Far fewer cases where changing a bit of code in one part of a library turns out to effect 90 other things, because someone threaded each one into the other so completely that they are now all interdependent.

Mind you, modularizing is *bound* to be more work to a) get working right, and b) keep people from screwing up with existing practices. lol
shadowfyr is offline   Reply With Quote