SmaugMuds.org - Viewing Topic: Affects

Affects - Overhauling the system

< Newer Topic :: Older Topic >

Pages:<< prev 1, 2, 3, 4 next >>

#41 Jun 22, 2009, 2:42 pm

Kayle
Nibelungen

GroupAdministrators
Posts885
JoinedMar 21, 2006 WWW

So I'm going to pose a couple of questions, and I'd like serious answers if I can get them.

1. What is an affect?

2. What do they do?

3. What should they do?
.........................
Owner/Coder Coder
Malevolent Whispers Star Wars: The Sith Wars
{Development Phase - Not accepting players} {Open Alpha - Players welcome, but with frequent changes to core systems.}
IMC2 Contact: Kayle@MW IMC2 Contact: Kayle@SWTSW

#42 Jun 22, 2009, 7:02 pm

Conner
Sorcerer

GroupMembers
Posts821
JoinedMay 8, 2005 WWW ICQ AIM Yahoo MSN GT

Wow, tough questions. Mainly because of how broad they are.

1. What an affect (a effect?) is might be definable as something that effects characters or objects in the game other than spells. On the other hand, some might argue that they only impact characters or that spells should be included too, but I can only give you serious answers regarding my own opinions.

2. All sorts of things. Invisibility, for example, hides you from sight and makes it easier to avoid some aggressive mobs. While being poisoned weakens you slowly over time, and fireshield gives you a retalitory strike in combat. Plus all the others.

3. I'm not sure how to answer that one.

Sorry, best I can do as the first responder to your query. .........................
-=Conner=-

Administrator/Coder Primary SysOp
Land of Legends The Castle's Dungeon BBS

http://tcdbbs.zapto.org/mud/nwlightninglol1.jpg

telnet://tcdbbs.zapto.org:4000 telnet://tcdbbs.zapto.org:23

#43 Jun 22, 2009, 8:05 pm

Kayle
Nibelungen

GroupAdministrators
Posts885
JoinedMar 21, 2006 WWW

I was more referring to the code aspect, but good answers anyway.

.........................
Owner/Coder Coder
Malevolent Whispers Star Wars: The Sith Wars
{Development Phase - Not accepting players} {Open Alpha - Players welcome, but with frequent changes to core systems.}
IMC2 Contact: Kayle@MW IMC2 Contact: Kayle@SWTSW

#44 Jun 22, 2009, 8:56 pm

David Haley
Sorcerer

GroupMembers
Posts830
JoinedJan 29, 2007 WWW

(In the below, read "is" as "should be IMO". :wink:

)

An effect is any kind of modification on a character's state (where "state" is the collection of "game-play values", such as stats, resistances, etc.). This can include setting an "active skill" flag on a character, such as "this character is currently affected by sanctuary" This modification can be transient (i.e., will expire after an event or timed delay) or permanent (i.e., doesn't go away normally). In other words, an effect is anything that modifies (affects) a character's normal state.

There are several ways of representing this in code. The straightforward "object oriented" way is to have some kind of generic effect that doesn't actually do anything, but that notes when it times out, perhaps where it comes from (e.g., which character or object is responsible for this effect?), etc., basically all things common to all effects. Then you specialize this effect into categories:
- effects that add to stats (str, con, ...), resistances, HP, mana, ...
- effects that add skill numbers
- effects that enable skills (...?)
and so on.

It must be decided if effect, err, effects are 'cached'. SMAUG takes the approach that when you apply an effect to a character, it goes and modifies actual values, such that if the effect is not removed completely properly, you can end up with a "lingering" effect whose state changes persist even though the effect itself is gone. This is Very Bad.
Another approach is to separate base values from modifier values, and to perhaps cache the modifier values so that you don't need to recompute them every time you ask for the character's strength, but to recompute them occasionally e.g. on character load, save, etc. In this way, you get the efficiency gains, but you ensure that your character's base values are stable. This is Much Better, because a bug in your effects code will not permanently mess up characters.

If you cache things, you need to have methods that are called when an effect is added to and removed from a character. (If we wanted to get fancy, these could also act on objects -- and maybe even entire rooms! -- but that would require more object orientation in the general codebase.)
If you don't cache things, you need to figure out how to get the values one way or another, which would mean tagging effects with enough data that the CHAR_DATA methods would know how to extract the appropriate data.

FWIW, I think that a good approach is to cache things on separate variables, such that the base variables stay "safe". Then, when you ask for a character's current value for X, you return base_X + modifiers_X.

--

Using an architecture where an effect is basically just a modification of state, a whole lot of things can be represented very generically. For example, racial effects can be stored as any old effects, with no expiration and perhaps a "permanent" flag set (so that they can't be canceled by dispels, for instance). Any thing that modifies game-play values can be represented the same way. .........................
David Haley
Head Coder, Legends of the Darkstone
BabbleMUD Project
http://david.the-haleys.org

#45 Jun 22, 2009, 9:07 pm

Kayle
Nibelungen

GroupAdministrators
Posts885
JoinedMar 21, 2006 WWW

That was a most wonderful answer. Would you mind logging on MW so I can pick your brains a bit about this before continuing on my self-destructive path to rewriting/writing from scratch this (new) system? Or would you prefer I attempt to formulate my thoughts into a cohesive mass and relay it in a somewhat readable format here? XD .........................
Owner/Coder Coder
Malevolent Whispers Star Wars: The Sith Wars
{Development Phase - Not accepting players} {Open Alpha - Players welcome, but with frequent changes to core systems.}
IMC2 Contact: Kayle@MW IMC2 Contact: Kayle@SWTSW

#46 Jun 22, 2009, 9:33 pm

Metsuro
Apprentice

GroupMembers
Posts68
JoinedSep 2, 2006

OK I have some dumb questions here... Why are there several different types of affects and such. Shouldn't an affect be anything that changes that state of an object or mob be an affect good or bad regardless of the median used to do it? Whats the difference from a spell adding poison to you vs a knife to the back?

#47 Jun 22, 2009, 10:36 pm

Kayle
Nibelungen

GroupAdministrators
Posts885
JoinedMar 21, 2006 WWW

Well, You must have already headed to bed, so I'll attempt to formulate my incohesive thoughts into a cohesive mass of text for you to read while you're at work not working when you're supposed to be working.

DavidHaley said:

An effect is any kind of modification on a character's state (where "state" is the collection of "game-play values", such as stats, resistances, etc.). This can include setting an "active skill" flag on a character, such as "this character is currently affected by sanctuary" This modification can be transient (i.e., will expire after an event or timed delay) or permanent (i.e., doesn't go away normally). In other words, an effect is anything that modifies (affects) a character's normal state.

Well, this pretty much meshes with my view on the subject as well. And contributes to why I have such an issue with getting this system underway. I just can't find a place to begin, and even when I do, I can't get my thoughts in order, and then lose said starting place from indecisiveness.

DavidHaley said:

There are several ways of representing this in code. The straightforward "object oriented" way is to have some kind of generic effect that doesn't actually do anything, but that notes when it times out, perhaps where it comes from (e.g., which character or object is responsible for this effect?), etc., basically all things common to all effects. Then you specialize this effect into categories:
- effects that add to stats (str, con, ...), resistances, HP, mana, ...
- effects that add skill numbers
- effects that enable skills (...?)
and so on.

Let's look at how I'd started to combine the two separate affects structs into one:

Code:

/*
 * An effect. (Spelled properly.)
 *
 * So limited... so few fields... should we add more?
 *
 * Updated and reworked. - Kayle 6/22/09
 */
class effectData
{
private:
   effectData( const effectData & );
   effectData &operator = ( const effectData & );   

public:
   effectData(  );
   virtual ~effectData(  );

public:
   std::bitset< ? > bitvector; //Can't remember what exactly is stored in the EXT_BV bitvector; field of AFFECT_DATA....
   const char *durationFormula;
   const char *modifierFormula;
   short location;
   short type;
   int durationTimer;
   int modifier;
};

Now, Should that be further broken down into something that differentiates between the different types of effects? Or perhaps, is scrapping the existing implementation entirely and starting completely from scratch a better option?

DavidHaley said:

It must be decided if effect, err, effects are 'cached'. SMAUG takes the approach that when you apply an effect to a character, it goes and modifies actual values, such that if the effect is not removed completely properly, you can end up with a "lingering" effect whose state changes persist even though the effect itself is gone. This is Very Bad.

Agreed. I've always hated the fact that characters can get "corrupted" from a mishap where an affect wasn't properly removed.

DavidHaley said:

Another approach is to separate base values from modifier values, and to perhaps cache the modifier values so that you don't need to recompute them every time you ask for the character's strength, but to recompute them occasionally e.g. on character load, save, etc. In this way, you get the efficiency gains, but you ensure that your character's base values are stable. This is Much Better, because a bug in your effects code will not permanently mess up characters.

I like the idea, but wouldn't this require changing a *lot* of code?

DavidHaley said:

If you cache things, you need to have methods that are called when an effect is added to and removed from a character. (If we wanted to get fancy, these could also act on objects -- and maybe even entire rooms! -- but that would require more object orientation in the general codebase.)
If you don't cache things, you need to figure out how to get the values one way or another, which would mean tagging effects with enough data that the CHAR_DATA methods would know how to extract the appropriate data.

FWIW, I think that a good approach is to cache things on separate variables, such that the base variables stay "safe". Then, when you ask for a character's current value for X, you return base_X + modifiers_X.

I think you lost me on this part. So bear with me. I think I get the gist of it. You think that all modifiers to stats should be stored in a separate variable, instead of the base value. But I thought Smaug already did this? At the very least with Str, Dex, etc. since they have a perm_ and mod_ field for each of them.

DavidHaley said:

Using an architecture where an effect is basically just a modification of state, a whole lot of things can be represented very generically. For example, racial effects can be stored as any old effects, with no expiration and perhaps a "permanent" flag set (so that they can't be canceled by dispels, for instance). Any thing that modifies game-play values can be represented the same way.

I like this, but how (from an in-game perspective) would you go about adding the flags to the effects themselves?

.........................
Owner/Coder Coder
Malevolent Whispers Star Wars: The Sith Wars
{Development Phase - Not accepting players} {Open Alpha - Players welcome, but with frequent changes to core systems.}
IMC2 Contact: Kayle@MW IMC2 Contact: Kayle@SWTSW

#48 Jun 22, 2009, 10:38 pm

Kayle
Nibelungen

GroupAdministrators
Posts885
JoinedMar 21, 2006 WWW

Metsuro said:

OK I have some dumb questions here... Why are there several different types of affects and such. Shouldn't an affect be anything that changes that state of an object or mob be an affect good or bad regardless of the median used to do it?

Now you see why this whole overhaul came to the surface to begin with.

Metsuro said:

Whats the difference from a spell adding poison to you vs a knife to the back?

Nothing. There isn't one. Unless you have a system for different poisons, in which case a spell adding poison would be a magical poison, where the knife to the back probably has a more natural origin.... >.> .........................
Owner/Coder Coder
Malevolent Whispers Star Wars: The Sith Wars
{Development Phase - Not accepting players} {Open Alpha - Players welcome, but with frequent changes to core systems.}
IMC2 Contact: Kayle@MW IMC2 Contact: Kayle@SWTSW

#49 Jun 23, 2009, 7:32 am

David Haley
Sorcerer

GroupMembers
Posts830
JoinedJan 29, 2007 WWW

Yes, I went to bed almost immediately after that post, sorry. :tongue:

Kayle said:

Well, You must have already headed to bed, so I'll attempt to formulate my incohesive thoughts into a cohesive mass of text for you to read while you're at work not working when you're supposed to be working.

I don't know what you're talking about. :blues:

Kayle said:

Let's look at how I'd started to combine the two separate affects structs into one:
...
Now, Should that be further broken down into something that differentiates between the different types of effects? Or perhaps, is scrapping the existing implementation entirely and starting completely from scratch a better option?

Personally I never really liked how the effects combined modifiers and bitvectors. It meant that applying an effect forces you to check several things at once. My proposal -- splitting each kind of effect into a separate class or something like that -- means that you can't have an effect that adds invisibility and increases dex by two, but, well, you can always create two effects. Or, if that's not acceptable for some reason, we could have an effect type whose role is to contain other effects, like a packaged effect or something.
I like keeping things simple when possible. We're not memory constrained such that we need to combine as many structures as possible. It would make life saner to have clear, understandable structures, even if it means using a few more bytes per effect.

Kayle said:

DavidHaley said:

Another approach is to separate base values from modifier values, and to perhaps cache the modifier values so that you don't need to recompute them every time you ask for the character's strength, but to recompute them occasionally e.g. on character load, save, etc. In this way, you get the efficiency gains, but you ensure that your character's base values are stable. This is Much Better, because a bug in your effects code will not permanently mess up characters.

I like the idea, but wouldn't this require changing a *lot* of code?

Yes. But we're already changing a ton anyhow. And this can be done very cleanly (from an API perspective) if we're willing to throw in some object orientation.

Sometimes I feel like when you start fixing these fundamental design issues, it's almost like writing a new game. Except if you did that you wouldn't have the stupid license requirement anymore...

Kayle said:

I think you lost me on this part. So bear with me. I think I get the gist of it. You think that all modifiers to stats should be stored in a separate variable, instead of the base value. But I thought Smaug already did this? At the very least with Str, Dex, etc. since they have a perm_ and mod_ field for each of them.

Sure, those do, but there are lots of other things, like HP, resistances, skills, AC, damroll, ...

Kayle said:

I like this, but how (from an in-game perspective) would you go about adding the flags to the effects themselves?

You mean like with OLC? I dunno, I haven't thought hugely about it; I guess you would do it not too differently from how things work now. I tend to avoid designing things around OLC, because you can always write OLC to do the right thing, but having a broken underlying mechanism is annoying everywhere.

Metsuro said:

Shouldn't an affect be anything that changes that state of an object or mob be an affect good or bad regardless of the median used to do it?

Yes; the medium doesn't matter much. The different kinds of effects here are just about the, well, effects that effects can have, without caring about where they actually come from. I agree with you (and Kayle's point too) that poison from a knife is the same as from a spell, unless you have other things like sensitivity to magic poison etc. etc. .........................
David Haley
Head Coder, Legends of the Darkstone
BabbleMUD Project
http://david.the-haleys.org

#50 Jun 23, 2009, 11:19 am

Kayle
Nibelungen

GroupAdministrators
Posts885
JoinedMar 21, 2006 WWW

I find myself wondering if this is a worthwhile endeavor. On one hand, Effects would be properly named, and easier to work with. But on the other hand this is going to require rewriting and reworking a good deal of the core Smaug code. So I have to wonder, is it going to be easier to just deal with the many flaws of the system, or literally start trying to rework and revamp the system. Like David said, if we're going to rework something this fundamental, we might as well be writing a new codebase. .........................
Owner/Coder Coder
Malevolent Whispers Star Wars: The Sith Wars
{Development Phase - Not accepting players} {Open Alpha - Players welcome, but with frequent changes to core systems.}
IMC2 Contact: Kayle@MW IMC2 Contact: Kayle@SWTSW

#51 Jun 23, 2009, 2:43 pm

Conner
Sorcerer

GroupMembers
Posts821
JoinedMay 8, 2005 WWW ICQ AIM Yahoo MSN GT

Upon further thought, and seeing the direction you're taking with this, I'm inclined to agree that it sounds like you're talking about an undertaking that, even for those just trying to keep up with the FUSS changes rather than downloading a fresh copy after the fact, it's not going to be able to make a snippet easily. In fact, after converting FUSS to use g++, adding the weather revamp, adding this.. other than it being a derivative by virtue of having started with Smaug, it's already trying to become a whole new codebase. Maybe this one is more of a bite than we should be trying to chew? .........................
-=Conner=-

Administrator/Coder Primary SysOp
Land of Legends The Castle's Dungeon BBS

telnet://tcdbbs.zapto.org:4000 telnet://tcdbbs.zapto.org:23

#52 Jun 23, 2009, 2:49 pm

Samson
Scaly but Handsome

GroupAdministrators
Posts3,347
JoinedJan 1, 2002 WWW

I'm inclined to agree with Conner's assessment at this point. If fixing the system becomes more of a large scale core overhaul, it's not worth the hassle. The same thing is probably true of the conversion of the reset system, but I think that's probably about the limits of what can be done without totally breaking everything in sight. Overhauling the affects the way that seems to be described now would more or less break everything. .........................
PDNS-Admin | Top MUD Sites | Arthmoor MUD Hosting Services | The Truth About Medievia: A Saga of Code Theft.

"The past was erased, the erasure was forgotten, the lie became truth." -- George Orwell, 1984

#53 Jun 23, 2009, 3:33 pm

Quixadhal
Conjurer

GroupMembers
Posts265
JoinedMar 8, 2005

Agreed. It would be a significant enough change to perhaps need to come up with a new name for the codebase. That's NOT saying it shouldn't be done, just that one needs to decide what it IS that makes something "Smaug".

My own little foray into reworking ROM into RaM showed that there seem to be two clumps of people interested in the project. One group wants everything to remain 99% the same, to the point that snippets could still be applied. The other wants to rework everything so it makes more sense and works better. Alas, the two goals are not compatible.

Soooo, you can't make an omelette without breaking a few eggs. I think overhauling the systems is a good idea, and would be useful. I think it would still remain "Smaug-like". It would probably NOT be "Smaug" or "SmaugFUSS". I'd propose the name "Arkenstone" or perhaps "Erebor", as one came from Smaug and the other was his home.

.........................

http://i302.photobucket.com/albums/nn96/quixadhal/EVEBanner.png

#54 Jun 23, 2009, 5:26 pm

Metsuro
Apprentice

GroupMembers
Posts68
JoinedSep 2, 2006

Well as I see it, we can not do this and complain about the system and just try to keep patching the old worn tire. Or we can spend the money(time) and buy the new one, and then redo some of the old snippets to work in the new system. Do we want to make the base fun and enjoyable or just something we can deal with and suffer as we just fester in a pool of poor design. Alot of the old snippets and such dont work without changing them in some way, should we let this limit the growth of the base? Its alot of work for one person to do yes... Saddly I don't have the skill to be of much help, but I'd be glad to offer some time up or something. But something like this I think needs to be done to make smaug maintain its easy of use and still be fun for new people to jump into, even if it means not only do we have to rework this, but maybe go through the old snippets and start updating them to fix both problems? Its alot of work but why not?

-- Sorry sometimes its hard for me to make sense, it sounds alot better in my head then when I try to explain or talk about things... so sorry if I sound repetitive and annoying...

#55 Jun 23, 2009, 5:59 pm

Conner
Sorcerer

GroupMembers
Posts821
JoinedMay 8, 2005 WWW ICQ AIM Yahoo MSN GT

Metsuro, I think Quixadhal's on the right track here with this. If we make the changes as proposed, at this point it'd probably be better to just start with a clean slate altogether and end up with something that's Smaug-like without the license issues nor the hassle of trying to make all the old parts fit with the new engine, to continue your analogy. If we're honestly just trying to Fix Up the old Smaug Source, this may be beyond our scope and it's certainly not going to be something most admins (let alone a beginning coder) are going to be able to just plug in like a typical snippet but if Kayle and David want to pursue this as a starting point for a new codebase that's already written in C++ instead of C and uses Kayle's weather code and happens to also incorporate the same snippets that SmaugFUSS does, I would think that they could easily dispatch the Smaug license (and possibly even the older licenses as well) and would probably have a pretty strong following. The ideas they are talking about are very good ones, just not really reasonable for FUSS without altering so much that we're forced to admit that we're no longer just cleaning the code. Especially once you consider the impact on all the other systems that the changes they're talking about will have. This is going to be tied into spells, special weapon properties, racial traits, ...by the time you get done following the path they're currently on, pretty much everything will have been altered. As an added bonus, if they do this as a new codebase they could also "fix" traps and some of the other things we've discussed recently as well by using what they percieve as good design from the beginning instead of trying to rework everything within the confines of the design that Thoric had started us with.

In a nut shell, Metsuro, I'm not saying that I think it's a bad idea at all, just that it sounds like it'd be way beyond the scope of the FUSS project. .........................
-=Conner=-

Administrator/Coder Primary SysOp
Land of Legends The Castle's Dungeon BBS

telnet://tcdbbs.zapto.org:4000 telnet://tcdbbs.zapto.org:23

#56 Jun 23, 2009, 6:21 pm

Metsuro
Apprentice

GroupMembers
Posts68
JoinedSep 2, 2006

But creating a new base, are we referring from complete scratch, or just relabeling this after the large changes. Wouldn't still be a derv since it started out as smaug, even though its changed a bit from the original wouldn't it still have to follow the license agreements? You cant really just remove parts and redo them and call it an original work can you?

#57 Jun 23, 2009, 6:25 pm Last edited Jun 23, 2009, 6:26 pm by Samson

Samson
Scaly but Handsome

GroupAdministrators
Posts3,347
JoinedJan 1, 2002 WWW

Conner, I think it's pretty obvious at some point that we went beyond "just fixing" and have been making improvements along the way. The reset system back in 1.6 was an example of that. Still justifiably a fix, but at the same time it did significantly rework an existing system into something it was not. The same happened with the weather code. However none of these has actually caused significant breakage of the codebase. Even the trap reform wouldn't be a significant breakage, mainly because the existing system is already broken.

Affects are not broken per se. But they are fairly clutzy and poorly designed. The problem here is that fixing them to not be either of these would be a huge significant breakage of a lot of other things, as you pointed out. They're deeply tied into a lot more than resets or weather was. Mobs, objs, rooms, spells, skills, races, classes, deities, etc. It's a pretty fundamental core system.

Right now we're already in a situation where actual legit fixes have rendered many snippets unusable without updates. Mostly const fixes. A few issues with reset fixes. But there's plenty of other things that have changed over time that old snippets will run into. There are ALOT of snippets though and not a lot of people with time or motivation to want to update them. There's a few snippets that are no longer applicable because they got absorbed as features because they themselves were fixes to broken systems.

We may well be on the brink of having FUSS morph into a legitimate derivative work of Smaug. I'm not sure what at this point would push it over the edge, but we're almost certainly right there.

@Metsuro: I'm not sure the majority of us is interested in wanting to start a new base from scratch. I sure am not. Too much time involved in that. I'd have to figure that for practical purposes this would become a derived fork, much like AFKMud, and would of course be required to follow the licenses. We're not run by the Locke's of the world here. We actually obey what we're expected to obey.

.........................
PDNS-Admin | Top MUD Sites | Arthmoor MUD Hosting Services | The Truth About Medievia: A Saga of Code Theft.

"The past was erased, the erasure was forgotten, the lie became truth." -- George Orwell, 1984

#58 Jun 23, 2009, 7:04 pm

Conner
Sorcerer

GroupMembers
Posts821
JoinedMay 8, 2005 WWW ICQ AIM Yahoo MSN GT

Metsuro, I refer you to:

David Haley said:

Sometimes I feel like when you start fixing these fundamental design issues, it's almost like writing a new game. Except if you did that you wouldn't have the stupid license requirement anymore...

along with:

Kayle said:

Like David said, if we're going to rework something this fundamental, we might as well be writing a new codebase.

So, yes, we are talking about actually starting over frm scratch if it came to that. Alternatively, as Samson suggested it would also be possible to do this as a new fork still under the previous licenses but with a new name to distinguish it as a different derivative codebase.

Samson, you've got some well laid out excellant points there. We really did cross the line of "just fixing" things up awhile back. On the other hand, I'm not sure we didn't also already become a derivative quite awhile back as well. Either way, I think we're talking about, ultimately, too big a fundamental set of changes for us if only for the sake of those who are trying to adapt existing muds to keep up with our fixes, let alone for all the related fixes we'd have to develop to compensate for this one big fix. :wink:

.........................
-=Conner=-

Administrator/Coder Primary SysOp
Land of Legends The Castle's Dungeon BBS

telnet://tcdbbs.zapto.org:4000 telnet://tcdbbs.zapto.org:23

#59 Jun 23, 2009, 7:17 pm Last edited Jun 23, 2009, 7:19 pm by Metsuro

Metsuro
Apprentice

GroupMembers
Posts68
JoinedSep 2, 2006

Conner said:

Metsuro, I refer you to:

David Haley said:

Sometimes I feel like when you start fixing these fundamental design issues, it's almost like writing a new game. Except if you did that you wouldn't have the stupid license requirement anymore...

along with:

Kayle said:

Like David said, if we're going to rework something this fundamental, we might as well be writing a new codebase.

So, yes, we are talking about actually starting over frm scratch if it came to that. Alternatively, as Samson suggested it would also be possible to do this as a new fork still under the previous licenses but with a new name to distinguish it as a different derivative codebase.

When David said wouldn't have to follow the license agreement was meant as in if they started completly from scratch not just changing the system. Right now were talking about just changing a port, what I believe David was trying to say was if we do something this huge, might aswell start 100% from scratch on a new codebase. So given that the system is a change it'd still be subject to the current smaug license.

Edit: ok so I totally misread what you posted Conner... Im such douche heh...

#60 Jun 23, 2009, 7:44 pm

David Haley
Sorcerer

GroupMembers
Posts830
JoinedJan 29, 2007 WWW

I think this is kind of an interesting crossroads for the FUSS project, actually. For a while, it was just fixing bugs. Then a lot of the bugs were fixed, and people started to want improvements, or "feature fixes" -- not actually fixing bugs, but fixing things that didn't behave quite right, or at least not in a terribly sane manner. And so the reset, weather, etc. changes came to be.

But eventually, as you start fixing "features" of the codebase, you run into things that are truly broken (while still not being literal "bugs", but just bad design decisions), but that fixing such things would take a very considerable amount of work. In fact, it starts requiring so much work that you're ripping out huge chunks of the codebase and replacing them with entirely new code.

Personally, I really don't like the license associated with all of this -- it feels like whatever you do you're giving away to somebody else. At least if you do your own thing and release it as open source, you can still do whatever you want with it yourself (e.g. open a for-pay server, or not have to have stupid arguments about accepting donations, or whatever).
Besides, after changing enough fundamental design decisions, you basically are writing the large components of a new codebase, you're just doing it incrementally.

So, in my opinion, the FUSS project will eventually have to decide if its goal is to fix bugs and "feature bugs", or if it also wants to address real design flaws in the code to make the system as a whole easier to work with. Obviously, the latter entails a huge amount of work, and -- to be completely honest with everybody here -- it seems to me that there are relatively few people, if indeed any at all, really motivated to actually do said work. Sure, we all want it to be "better" in some abstract sense, but the practical value seems to be underappreciated.

Of course, starting from scratch means incurring a huge cost, and is not an easy undertaking by any means. I wouldn't recommend it seriously to the vast majority of the community. Heck, even with myself, the idea of sitting down to write a new codebase is reason for trepidation: it's an awful lot of up-front work until you actually have a running game that people can connect to and play normally.

Anyhow, enough of this rant for now: just thought I'd throw this out there. .........................
David Haley
Head Coder, Legends of the Darkstone
BabbleMUD Project
http://david.the-haleys.org