Is it better to save up code changes for a long time, then install them all at once in one mega upgrade?

Or, is it better to routinely install small code changes often?

Assume, for the sake of argument, that either way the same actual amount of code gets installed.

[thelenian]

When we're talking about MUDs, I'd definitely have to say many small code changes are better. If something goes wrong, you want to be able to narrow down the list of upgrades that possibly introduced the bug ASAP. Periodic massive upgrades leave you with tons of possible culprits that you'll need to wade through.

[Nomikos]

I believe it would be best to get in a code change as quick as possible, so as to be able to work with its quirks and get any bugs that might be present out of it, added to the fact that if you have players currently mudding, they will benefit from the change.

Storing up code changes and dropping them all at once would have an effect somewhat akin to dropping a bomb, and if there were an error, you wouldn't know where to start.

Good luck on the coding

Nomikos

[Dre]

Heya,

I choose tons of small updates for a few reasons, but most important is that the players can actually see how much work and effort is put in to it, and they can immediately use the new spells/commands/whatever.

Greetings Dre

[RavenDM]

The above remarks are certainly true for most groups of small tweaks to existing code. I would say the one exception would be a sweeping change to an entire major system.

For example, we recently redid our Feudal system, which involved writing an entirely new server to completely replace the old one, and a bunch of tweaking of other components.

It could have been done as a series of smaller changes to the existing code, but the final product is a lot cleaner because it was done over from scratch.

For a change of this type, it was also easier on the players to swap out the whole thing all at once. That way they don't have to experience the "this is constantly in flux" syndrome, which they may find confusing and irritating. Like ripping off a band-aid, better to get it all done at once.

R.

[Noplex]

There are many factors in when to decide to port code changes over to a game and when not to. Here are a few that I think are the most major ones.

1. How big is the MUD that you are coding for?

By big, I mean player-base. The bigger the MUD is; the less you will want to have more frequent code changes unless of course they are immediate bugfixes. More and more code changes cause more and more bugs; and with a big playerbase, people tend to get ****ed off easily.

2. What kind of change is it?

Would it affect the playerbase alot? If it would, It would probably be better to put it in slowly and gradually, giving people time to adapt.

3. Is it a bugfix?

Bugfixes should always be fixed immediately. I don't care what kind of bugfix it is, a bug is a bug, and can lead to another bug.

4. What is the purpose of the change?

If the change isn't something that is drastically NEEDED by the game; you shouldn't rush it.

5. Test, test, test.

The more time you keep code from entering the game, the less bugs it presents. The more testing, the less bugs. New code always has bugs, and bugs can easily interfear with players; and can create crash-bugs.

[Merrak]

I have had better luck implementing small changes over a brief time... however,,, if you put a big change on a test port (playable bport?), let players test it out some, it would go over better and less bugs

[Grey]

Yeah, small changes at a time are best. Large implementation often leads to bugs that *mysteriously* arise in the strangest places and finding them is often a difficult task.