State of Zelda Classic 2.5

[jman2050]

I going to say this.

Devs, face the truth. The current ZC is unstable because of the lack of understanding its code. Phantom Meanace may have made the first ZC, but he knew how it worked to the best of his knowledge. Now that he's not here anymore, and he left no real archive of the code except the code itself, it's all guesswork for the others on deciding how it works.

At this point, sometimes when the plan isn't understood, and not explained, sometimes we must restart with a representation that does make sense. And this, I must say, is a direction we might as well take; this way, we can pinpoint what causes certain problems, and we know what ends are open and not break others by pure accident.

After all, I know a lot of suggestions made require a whole new engine, and the fact is that you might as well make a new one. You got some parts you can start from, but otherwise it be the only viable chance left to get a stable ZC running. After all, I know some of you want to ditch Allegro anyhow, and go with a more flexible library.

This is actually what precisely what I want to do, except it doesn't come from not understanding the code, it comes from understanding the code enough that you realize that trying to patch things would be more trouble than its worth.

The problems with ZC extend beyond what's reported in the bug forums. I evidently gained some fans by doing everything that the community wanted me to do, but if these years and experience have taught me anything, it's that the problem IS pandering to a fanbase. You want a stable release? Let us do our jobs and it'll get there when it gets there.

Of course, that's just my view of the whole matter, the other devs and I will have to consider what we want to do in the future, especially regarding this build of ZC we're working on now.

[Dark Nation]

The big question is (and it's been raised before): "How good is good enough?"

To completely rid ZC of bugs would probably take a lifetime. Currently, we have 28 critical (corrupt quests/crash the program) and mechanical (make quests unbeatable or make things have to be done in a different way than was intended) bugs. Would releasing after these are fixed be "good enough"?

Also, less than half of the current code was actually written by PM. Much of the code has been heavily modified, completely rewritten, or added outright.

Finally, in regards to patching problems vs. rewriting: A rewrite is necessary at some point. To give an analogy, we need a bowl but we have a sieve. We are currently trying to plug up all the holes in the sieve to make a nice, pretty bowl, but it takes time and sometimes the patches that we have to hammer in place make some of the other patches fall off or break new holes into the sieve that have to be patched as well.

[jman2050]

Finally, in regards to patching problems vs. rewriting: A rewrite is necessary at some point. To give an analogy, we need a bowl but we have a sieve. We are currently trying to plug up all the holes in the sieve to make a nice, pretty bowl, but it takes time and sometimes the patches that we have to hammer in place make some of the other patches fall off or break new holes into the sieve that have to be patched as well.

Along with your question, is it really worth it to keep patching up the sieve when we could be spending our time making a new bowl? and it doesn't even have to be a prettier bowl, it can be the same bowl everyone is used to, except more sturdy and less likely to break. I doubt people would be willing to wait, but like I said, I don't care about that anymore.

[Dark Nation]

Well, we could patch the biggest holes in the bowl (the ones that can cause the bowl to break or allow all of your food to spill out) while leaving the smaller holes and scratches for later, if ever. Then, we can make a new bowl, though it won't hold a small percentage of the things that the old bowl held without modifying those things (the new bowl has nice compartments, perhaps, and some of the more messy items have to be folded neatly to fit in the pretty compartments, maybe).

[jman2050]

I suppose, but will that be worth it? After all, we already have bowls we've given out that don't have those big holes that we created trying to improve it further. Couldn't they just use one of those instead of waiting for something that's only a marginal improvement?

(On a seperate note, this analogy is fun)

[Dark Nation]

Well, one of the problems with our current bowl is that some types of food containing certain ingredients, if taken out of the bowl and placed in the refrigerator, will be free of those ingredients when put back into the bowl: http://www.armageddongames.net/forum...d.php?t=102928

Another issue is that when mixing colors in the bowl, sometimes the bowl will become nonresponsive and not allow you to use it anymore (you have to stick the bowl in the refrigerator after dumping the contents in the trash, then take the bowl out of the refrigerator and putting a new copy of the old contents back in it from the refrigerator.): http://www.armageddongames.net/forum...d.php?t=102921

The bowl also has a food processor built in. Sometimes, if you put a lot of things with the same name into the food processor (egg[0], egg[1], etc.), certain actions with the food processor will cause the food processor (and the bowl) to stop working, forcing the trash/refrigerator remedy above: http://www.armageddongames.net/forum...d.php?t=103734

That's just 3 of the problems.

[pkmnfrk]

I hate to interrupt this Super Bowl, but... I just wanted to point out some parallels in other projects.

I used to be the jman on another project. Though I've since retired from that project, in my time, I shook up the code base quite a bit.

Quite a few bugs were introduced with my new features, but even more bugs were shook out of the carpet. Alas, all of these bugs were attributed to me. The Freedom of that community expressed similar concerns to those in this thread.

Most of the bugs have since been worked out, either by me or by the _L_ and the Dark Nation. (Some bugs haven't, as they are artifacts of having been ported from Dos to Windows with as few changes to the code base as possible... bad idea, but not mine.)

Anyway, a major view during the whole fiasco was that "Why not just start over?". Well, I did just that.

Turns out, replacing 9+ years worth of work takes, well, 9 years. My replacement project never got off the ground, nor have any others, either ports of the original code, rewrites or independent projects. Only the original code base is still active.

Moral of the story: If anyone wants to see a stable release any time this decade, then a rewrite is not in the cards.

[jman2050]

I hate to interrupt this Super Bowl, but... I just wanted to point out some parallels in other projects.

I used to be the jman on another project. Though I've since retired from that project, in my time, I shook up the code base quite a bit.

Quite a few bugs were introduced with my new features, but even more bugs were shook out of the carpet. Alas, all of these bugs were attributed to me. The Freedom of that community expressed similar concerns to those in this thread.

Most of the bugs have since been worked out, either by me or by the _L_ and the Dark Nation. (Some bugs haven't, as they are artifacts of having been ported from Dos to Windows with as few changes to the code base as possible... bad idea, but not mine.)

Anyway, a major view during the whole fiasco was that "Why not just start over?". Well, I did just that.

Turns out, replacing 9+ years worth of work takes, well, 9 years. My replacement project never got off the ground, nor have any others, either ports of the original code, rewrites or independent projects. Only the original code base is still active.

Moral of the story: If anyone wants to see a stable release any time this decade, then a rewrite is not in the cards.

There are cases of it working, so I suppose it depends on the project. Not like I would be doing this on my own anyway, though even working to fix the existing code is difficult with _L_ being the only real active one over the past few weeks.

[The_Amaster]

Well, we could patch the biggest holes in the bowl (the ones that can cause the bowl to break or allow all of your food to spill out) while leaving the smaller holes and scratches for later, if ever. Then, we can make a new bowl, though it won't hold a small percentage of the things that the old bowl held without modifying those things (the new bowl has nice compartments, perhaps, and some of the more messy items have to be folded neatly to fit in the pretty compartments, maybe).

QFT!!! This is exactly what ZC needs. Although if you guys embarked on a new bowl from the ground up we could keep using the old one, that would make the community fanatically mad. If you take maybe the next month or so and all just do what L's been doing these past months, we could have a stable 2.5 that's usable to tide the fans over, and then you could take months or a couple years to rebuild.

[jman2050]

QFT!!! This is exactly what I mean, put far better than the kind of convoluted way I put it.

I find it hilarious that you found an extremely thin bowl metaphor less convoluted than what you said