(moving away from the bowl analogy to a house analogy): The current house doesn't just have holes. It has structural water damage. The foundation has to be replaced. Every addition you make to the current house adds more stress on the already overtaxed foundation and floor jacks are having to be installed to keep the whole thing from collapsing. Even just fixing problems in the walls causes stress on the foundation because you are screwing around with loadbearing structures. While it is possible to replace the foundation of a house, it is easier and cheaper in the long run to bulldoze the whole thing and lay down a new, properly waterproofed foundation and build a new house on top of that.
State of Zelda Classic 2.5
DarkDragon wrote:In addition to taking a very long time, a complete rewrite probably wouldn't be compatible with current quests.
The only thing we would have to address from the outside is the Allegro packfile format. Given that there's no restrictions on Allegro's usage, stealing that code would be a trivial matter.
Compatibility in every other respect could be taken cared of during the development process.
But once ZC 2.5 is out, we can use that program for all quests. The new ZC's after don't have to be compatible with old quests. As if you wanted a compatible version for old quests, you download 2.5. If you want to make new quests you make it with 3.0 or whatever. It is kind of like this:
What if nintendo keep doing backwards compatibility with there systems. The wii would be able to play NES, SNES, N64, Gamecube etc. that is just too limiting as it is hard to add things without screwing up there compatibility. So since 2.5 is the version where it is to play the other earlier quests, have that the compatibility version, then move on after that without worrying about old quests messing up. Because old quests are to be played on the platform it is meant for ie. 2.5.
Not sure if you understood, but yeah, I'll shut up. lol
I was saying more that maybe it shouldn't be, not that it couldn't be. Continuing DN's analogy, each .qst file is a polaroid of the house, with a post-it attached to it saying, "new house *must* look exactly like this from this angle." Problem is, peering closely at the photo, you can see the water damage in the basement, termites crawling all over the walls, shingles missing from the roof, etc. Building a new house to match the old photos isn't a problem. But building a new one that's structurally sound on the inside, yet looks like shit from every outside angle? That's the trick.
If you will, it's a question of whether you want something like OS X, which is a complete rewrite of (and incompatible with) OS 9, or Windows Vista, which is almost perfectly compatible with XP, but some might argue a scant improvement.
Shoelace wrote:What if nintendo keep doing backwards compatibility with there systems. The wii would be able to play NES, SNES, N64, Gamecube etc. that is just too limiting as it is hard to add things without screwing up there compatibility.
Strictly speaking, the Wii does play all those, and a bunch more to boot.
But, in general, what exactly is causing the "structural damage" in ZC? Is it backwards compatability with 1.90, 1.92bwhatever.0, 2.10? Or, compatability with the NES? Or, what?
Dark Nation wrote:While it is possible to replace the foundation of a house, it is easier and cheaper in the long run to bulldoze the whole thing and lay down a new, properly waterproofed foundation and build a new house on top of that.
How long of a run are you speaking?
<speaking type="hypothetically">
If you're going to start over, you have to do it properly. You have to sit down, and think of what, exactly, you're trying to do.
Are you creating a Zelda-style engine? Well, that's what we have now.
Or, do you want to create a generic, 2-d engine? Depending on how you do this, you can get away with a graphics engine, a sound engine, and a script engine, and call it a day.
But, either way, you need goals. Even if you are going for ZC 3.0, a total rewrite from the ground up.
Then, once you have the goals, you need to design your program. How does it work? How much stuff is hard coded/customizable? How much stuff is accessible to scripting? What type of scripting do we need? What colour depth? What resolution? What operating systems? Are some items built in, or are they all scripted? Is there such a concept of items from the engine's point of view? Etc, etc, etc...
Then, once all of that is settled, can you begin to code. But, even as you write, you realize that... oops, design facet X is very difficult to get to work with facet Y. Ok, well, if we change X, are there any goals that cannot be accomplished? What about Y? Maybe we can change the goal... But, that affects Z. Cyclical revisions ad nauseum.
</speaking>
I'm directing this at the people saying "Rewrite!", since I've been burned by not paying attention to these details.
I cannot say whether or not the rotting foundation in the basement can be fixed, since currently I'm restricted to peeking in the window. All I'm saying is that you should think carefully before renting that bull dozer.
But building a new one that's structurally sound on the inside, yet looks like shit from every outside angle? That's the trick.
You mean like making the code work perfectly but looking at the code is a eye sore?
pkmnfrk, the issue is that everything is entwined with other stuff thus making it not easy to do anything without screwing something else up. Rebuilding the exact same thing but from the ground up and making sure nothing depends on something else, will be better overall for fast development, less bugs and the code will be much more pleasurable to work with. The end result, will be something that sports the same degree of compatibility and features while being a ton easier to manage and code with.
franpa wrote:You mean like making the code work perfectly but looking at the code is a eye sore?pkmnfrk, the issue is that everything is entwined with other stuff thus making it not easy to do anything without screwing something else up. Rebuilding the exact same thing but from the ground up and making sure nothing depends on something else, will be better overall for fast development, less bugs and the code will be much more pleasurable to work with. The end result, will be something that sports the same degree of compatibility and features while being a ton easier to manage and code with.
What I'm trying to say is this:
If you want features, and want them now, the codebase is going to be ugly.
If you want a clean codebase, and still want a new features and bugs fixed, it's going to take a long time.
If you want a clean code base, and still want frequent releases, then each release is going to be incremental or buggy.
(The features/bugs aspect has a triangle of its own, but it's irrelevant here)
DarkDragon wrote:
If you will, it's a question of whether you want something like OS X, which is a complete rewrite of (and incompatible with) OS 9, or Windows Vista, which is almost perfectly compatible with XP, but some might argue a scant improvement.
As long as you can be sure that the new ZC isn't as crappy as OS X.
There is one thing I do have to say about the house, and it's not the exterior. The shrubbery around it is getting a bit too wild and the fencing deters onlookers too much, leaving curious pedestrians guessing on what the certain parts of the house look like, or even finding a pathway to the house.
So, if a new house is built, it's going to need a serious landscaping redesign around it, where pedestrians can see everything that gives them an idea of what it looks like to their own extent.
I say that the rewrite should be completely incompatible with previous releases, focused slightly more toward power and user expansion without outright removing the fundamental staples of the 2D Zeldas. (basic arsenal, map engine, real-time battling) Call it Zelda Pro or something. It's high time we turn this heavily modded NES into an SNES. (after V2.50, of course) Or I guess turn a shack with a million non-regulation expansions into a nice middle-class house.
Can't the house bowl be broken into individual parts, said parts fixed one by one, and then rebuilt? Seems like it'd work better than trying to fix it as a whole. Of course, not broken down into molecules, but like in big enough chunks so that the total number of parts isn't outrageous for a team of like 6 people (unless I counted wrong, I just guesstimated)
Because while rebuilding the bathroom, I might move a few pipes, and when we put it back together the faucets might spew natural gas.
I was implying rebuilding everything back exactly, but instead of using half-rusted pipes and eroded bricks, you'd fix them (codes can be fixed no matter what, rusted pipes and bricks can't, to an extent... bear with me here), and replace.
Ebola Zaire does have a point though. When different people work on different parts, you get different techniques. After everything was finished, you'de have to have one last person go through and make sure all the gas pipes connect to gas pipes and water pipes to water pipes, adding extra pipe to connect where need be.
Think of it like taking four individually designed puzzle pieces, then having someone add extensions and cut notches to make them into fit. This, however, tends to be a weaker structure.
If you compare strengths of something molded from solid plastic and something made of smaller pieces and connected, the solid molded version is usually stronger. Less stress points.
Similar with a program: if everyone works on their own individual parts, and they put them together at the end, the program tends to function at less than optimum because people didn't know what other people were doing, and failed to take advantage of others work, so everything is that less integrated, and different parts can't take advantage of the strengths of other parts because they were built in a vacuum, instead of in parallel.
Mind you, this is a worst case scenario, in which the devs don't consult with each other at all. Still, I think it's best if everything is done as a team. Divide and conquer might work for a patching up of parts of ZC, but a ground-up build should not be built in parts.
(Wow, I think I just burned through three metaphors and returned to "program"😉
To be honest, I'm all for a new house to play around in, but I would like to see 2.5 finished beforehand. I'd rather live in a leaky, yet stable house while I wait for a new house to be finished, rather than wait out in the rain while the new house is built
The only problem is, since ZC is a strictly fan-based, off-the-clock project, a complete rebuild (Metaphor not implied) would take forever. Development as is takes long enough, and we've got, what, 4 or so core programmers? I can only guess how long it would take for ZC to reach this state in a rebuild, assuming more current Zelda features aren't added in the process
Which brings up a question; Should a Zelda Classic rewrite occur, what would be the plan? Follow the original intention as a Legend of Zelda clone and add on from there? Or create a more modern, general Zelda game maker? Or even rebuild Zelda Classic to matching current features, with easier ways of adding more?
Maybe you guys need to get Bob Villa in here to determine whether it's a fixer-upper or not, and to asses the damage. There's nothing a few thousand pounds of duct tape can't fix imo. :P
As for re-writing an entire Zelda 1 clone that's been in development for 9 years, I'm assuming you guys are talking post 2.5/2.6 here. I've got to ask though, was the reason of a re-write simply to port this project away from allegro, or to upgrade it or create a new game engine? To make everything more customizable by the user in the same way it behaves currently, or something more modern? Perhaps to increase both power and accessibility, or mainly for the sake of making it easier to fix bugs?
It seems to me that right now ZC is like the six-million dollar man....exept we don't have that kind of money. What we've got is saran wrap, popsicle sticks, heat-shrink tubing, and a cafeteria full of first-graders - and we've just run out of tater tots. 😛
As for re-writing an entire Zelda 1 clone that's been in development for 9 years, I'm assuming you guys are talking post 2.5/2.6 here. I've got to ask though, was the reason of a re-write simply to port this project away from allegro, or to upgrade it or create a new game engine? To make everything more customizable by the user in the same way it behaves currently, or something more modern? Perhaps to increase both power and accessibility, or mainly for the sake of making it easier to fix bugs?
I believe it is so they can undo all there wrong doings since getting access to the code and making it easier to fix bugs 😊 it also opens up the ability to port the program to another engine but that may break backwards support. (hence most likey post 2.5)
So, we're currently living in a shack that's had so many additions and extensions that it's about to collapse under it's own weight.
We should invest in some good heavy concrete pillars to hold it up for a while, to keep it lasting for a while while we build a new, huge, well put together, above all cohesive house.
(Heh, this is fun)
I personally, would love to help with a rewrite. I'm sure the engine needs it, and I'm sure that it could be done in a reasonable time frame.
However, you have to understand that "reasonable time frame" means 2-3 years before it gets back to an equivalent level of... uh... featureness.
However, Gleeok, gentlemen, we can rebuild it. We have the technology. We have the capability to make the worlds first bionic Zelda engine. Zelda Classic will be that engine. Better than it was before. Better, stronger faster.
[SIZE="4"]THE[/SIZE]
[SIZE="5"]SIX MILLION[/SIZE]
[SIZE="4"]DOLLAR ENGINE[/SIZE]
I would help with the rewrite. I don't think I could deal with the map engine, but if I knew a little more C++, I could probably deal with the UI. So I can make the doors and windows. That leaves the foundation, garage, kitchen, shed/workshop, utility lines, and bedrooms to be made by others.
Personally, I'd rather deal with Java due to flexibility and portability. On the other hand, C++ is more powerful and is faster. So are we going to build the new house with pine or cedar, like before?
And for backwards compatibility, will we just not allow any T-Model cars to park in the garage, or will we make a special machine down the street that rebuilds those T-Models as Volkswagen Beetles?
However, you have to understand that "reasonable time frame" means 2-3 years before it gets back to an equivalent level of... uh... featureness.
Thats the kind of time frame I would expect, DD, DN and Jman2050 all have a decent idea of what to do and have improved in coding ability since the good ol' days. I'm not sure about you _L_, since you seem to have done mostly bug fixing (yes the community did shun you into just bug fixing, i am aware of that) and as such, you have been fixing what others have done instead of adding your own work.
franpa wrote:I'm not sure about you _L_, since you seem to have done mostly bug fixing (yes the community did shun you into just bug fixing, i am aware of that) and as such, you have been fixing what others have done instead of adding your own work.
Where the hell were you at that time when _L_ started his developing duties and added tons of his new stuff that made ZC buggier than it had ever been? There's a good reason why _L_ is only fixing bugs nowadays you see.
You know what? I think maybe we should have started the rewrite all the way back at 2.10, before it would get massively bloated. Right now our priority is to exterminate all the major bugs and release the last Z1-based ZC version once and for all.
The original Zelda Classic was meant to be a simple clone of Z1. Look at where we've taken it. I'm not bashing anybody; all I'm saying is that the developers have far strayed from that original purpose, which can be interpreted as either bad or good.
On the bright side, ZC hasn't been this stable for a long time. Aside from quest corruption, there are very few other bugs. I think we're actually close this time.
And as a potential dev for the rewrite, I would like to make the editor and engine about as user friendly as a Mac, while maintaining power like Linux. (for the longest time, it has been more like Windows because of all the annoying bugs and bloat) I was the one who made the original mockup for the current Large Mode, remember? I don't mean to be arrogant, but now you know what I'm capable of designing.
Sorry to open this again, but it's just a suggestion. If we did have to use a certain library, I say that GTK+ would be the best one to use mainly because it is accepted on most major OSes, which doesn't mean having to convert large sections of code just for one OS, and it is public and kept current. Also, with it's multi-window support, ZQ's tools can be separated into separate windows, meaning that we no longer have to keep anything to a to certain size and scale; we could even go further and give those windows separate processes ala Google Chrome. One example is that you don't have to keep the same 4x14 combo window size, but adjust it to your liking. Also, tiles can be preloaded and kept in separate pages, such as different types of architecture and and regional foliage. No longer do we have to go through several pages just to find one tile!
Finally, the support of add-ons; while not making the whole script public, but instead providing a skeleton for an add-on, ZQ can be expanded greatly. This way, we can keep optional tools separate, in which the beginner has the basics, while the more advanced user can add a script editor to expand the dimensions his game can take.
The player is designed to be basic, much like Game Maker's; all it does is read the file, and executes the scripts associated with objects. Debug provides warnings and errors, accessable through a passworded(for security and to discourage cheating, of course) dev console, which is set through the quest file.
Can I please just request a link to the beta version. I hear it has an enemy editor, and many new features.
You mean this?
Wow thanks
Say, can this one, unlike it's predecessor have tilesets imported?
You could import tilesets into ZQuest since, like... The dawn of time. 😉
I know what Pryex meant. There is a know bug in 2.10 that would not allow you to import graphics packs. Files with a .zgp extension.
I'm pretty sure you can do that with this version now.
beefster09 wrote:And as a potential dev for the rewrite, I would like to make the editor and engine about as user friendly as a Mac, while maintaining power like Linux. (for the longest time, it has been more like Windows because of all the annoying bugs and bloat) I was the one who made the original mockup for the current Large Mode, remember? I don't mean to be arrogant, but now you know what I'm capable of designing.
Oh god no...
I seem to be the only person who dislikes large mode, so I'm most likely alone in this opinion, but...
If the person who designed that atrocity is now going to have a huge say in redesigning every aspect of ZC? The entire project is doomed.
Linkus wrote:Sorry to open this again, but it's just a suggestion. If we did have to use a certain library, I say that GTK+ would be the best one to use mainly because it is accepted on most major OSes, which doesn't mean having to convert large sections of code just for one OS, and it is public and kept current. Also, with it's multi-window support, ZQ's tools can be separated into separate windows, meaning that we no longer have to keep anything to a to certain size and scale; we could even go further and give those windows separate processes ala Google Chrome. One example is that you don't have to keep the same 4x14 combo window size, but adjust it to your liking. Also, tiles can be preloaded and kept in separate pages, such as different types of architecture and and regional foliage. No longer do we have to go through several pages just to find one tile!Finally, the support of add-ons; while not making the whole script public, but instead providing a skeleton for an add-on, ZQ can be expanded greatly. This way, we can keep optional tools separate, in which the beginner has the basics, while the more advanced user can add a script editor to expand the dimensions his game can take.
The player is designed to be basic, much like Game Maker's; all it does is read the file, and executes the scripts associated with objects. Debug provides warnings and errors, accessable through a passworded(for security and to discourage cheating, of course) dev console, which is set through the quest file.
GTK is a fantastic GUI toolkit... just make sure that the installer also puts GTK onto a Windows system when it installs automatically, or you'll get major problems with people coming onto the forum saying "OMG how do I get ZQ to workz!?"
ZC has long outgrown its skin and it would really be better to dump the bulk of the current code and start working on something completely new.
Also, why can't the new project be open source? I understand that with the current ZC we're under agreement with Phantom Menace to keep the source code unreleased to the public, but with the rewrite there's absolutely no excuse. The only programs that ever benefit from being closed source are ones whose only goal is to suck money out of your wallet, and for christ's sake I hope that isn't how the new project will be...