ZC Development Proposal

Before I begin with the proposal proper, let me offer some motivation. What elements are essential to ZC's success in the future? Many ideas have been discussed about what features are most important for a hypothetical "ZC 3.0," and while new features keeping ZC fresh are important to its success, they are not as critical as the following two pillars:

1. Ability to play all existing in the Quest Databases.

Put simply, the quest databases are the most valuable assets the project has right now. The ability to create your own quests is extremely important to ZC and its community, but I'd argue that the #1 draw for new users, by far, is the ability for them to download ZC and then play hundreds of Zelda-like games created by fans, many of them of quality rivalving the official Nintendo SNES and GB games. If ZC development stopped completely, ten years from now someone might still discover the binaries and the quest databases, and rekindle interest in the project.

Therefore the ability to play old quests is paramount no matter what direction ZC development takes. Any plans that do not maintain backwards compatibility of quests (especially for the ZC player) are non-starters.

2. Portability to modern computing devices.

This is another obvious requirement: if ZC doesn't run on modern operating systems, or is temperamental/difficult to deal with on these operating systems, nobody can play any quests and the project is doomed in the long-term. ZC needs to be built on top of libraries are that as portable and future-proof as possible. (I want to carefully distinguish here between ZC having a robust and portable *back-end*, and ZC having an old-school 8-bit user interface. The two are completely separate issues, and while some might argue that the user interface in ZC and, especially, ZQuest, could do with a modern makeover, that's not what I'm talking about in this item.)

So what's the punchline? These days, a "modern operating system" doesn't mean Windows 10 (although I do have trouble running ZC on Windows 10 without tinkering with command-line switches, which is not a great state of affairs). It means Android, iOS, or even better, the browser, including the mobile browser.

---

So, my proposal is the following: clean up the ZC source and increase its portability to the point that it becomes possible to run the ZC player in the browser. This project, if successful, would allow us to put a "play it now" button on the quest databases, so that users on all manner of devices could play the custom quests right there in their browser. If we want Zelda Classic to regain mainstream visibility and attract new users, this has to happen, and it will only get harder the longer the delay.

And this is not as crazy of a proposal as it might sound. Projects like quakejs demonstrate the feasibility of porting natively-C++ games of the complexity level of Zelda Classic to JavaScript on the browser. But, I'm also aware that this is far from a trivial task. The main challenges I foresee are the following, with the toughest listed first:
- Allegro must be replaced by a more portable back-end. SDL is the obvious choice here, as it already is well-supported by the Emscripten C++-to-JavaScript compiler.
- ZC must be optimized to run at a reasonable speed in the browser. It also has to fit within JavaScript's allowed memory footprint (a little bit over 1GB), which I don't think is a problem for most existing quests, but is a limit we should keep in mind before we insert any additional feature bloat into ZC.
- ZC currently uses hardware bitmaps, multiple threads, and other miscellaneous low-level features that are not supported by JavaScript. These will have to be stripped out and rewritten.
- All of the above has to be done without completely breaking ZQuest (and, I suppose, ROMview). If ZQuest also runs in the browser, that's great, but I think getting the player to work is far more important, so that it's OK is ZQuest remains a desktop-only app.

---

So how do we go about doing this? Forking the current code and starting a complete rewrite will not work: it is too big of a task to complete in one go. Instead, I propose working incrementally towards the goal of porting to the browser. I envision the work proceeding in three phases:

Phase 0: Get Current Development Efforts on Track (time frame: a few weeks)
To be honest, even after reading the ZC development threads here and at PureZC, I'm not quite sure what the current development vision is. Before any new work can begin, our existing resources need to be organized. In particular:
1. As ZoriaRPG mentioned in the other thread, the repository needs to be cleaned up, with a reasonable branch structure, a modern build system, instructions included for how to build the source, etc.
2. The management of the project needs to be clarified. Who has access to the main repository? What is the procedure for adding or removing "core developers"? How are new features proposed, discussed, and approved? What is the procedure for code review of patches submitted by the main developers? Outside developers? Where and how should users submit bug reports? Etc.
To be clear, I don't mind if the answer to several of these is "Gleeok decides and rules with an iron fist." This is much better than developers working independently and at cross-purposes!

Phase 1: Wean The Current Code Off of Allegro Utility Libraries (time frame: 1-2 months)
The code current relies on several Allegro utility libraries that could be removed or rewritten, without needing to add any additional libraries, and without removing the core Allegro graphics backend. These include
- the packfile system
- the fixed-point arithmetic handling
- memory management
- some of the GUI code (jwin) which can be converted to using a wrapper around core Allegro functionality
Other aspects of this phase not related to replacing Allegro features:
- creating some system for automatically testing old quest compatibility, to ensure development does not break these quests (for example, by implementing a "quest demo" playback system, which checks that the same commands entered into the same quest result in the same final game state before and after each change).
- avoiding adding any new features which ties ZC more closely to Allegro, or to its current GUI or hardware backend.

Phase 2: Replace Allegro with SDL (time frame: 6 months)
This will require
- replacing all I/O and bitmap operations with SDL equivalents. This is easier the more of the GUI code can be wrapped during Phase 1, but there's no point beating around the push: this part will be long and involved.
- rewriting the sound library to use SDL_mixer instead of the current hodge-podge of external music libraries.
- replacing jwin with Saffith's GUI library?

Phase 3: Complete The Port (time frame: 3 months?)
Once Allegro has been replaced with SDL, there will still need to be miscellaneous cleanup necessary before ZC can run successfully online. Here are some issues I anticipate, though I'm sure there are others that will crop up over time:
- switching to LLVM instead of MSVC/gcc
- modifying the handling of the filesystem to allow for online play
- optimizing the rendering or script engine, as necessary, to ensure reasonable frame rates.

---

If you have read this far, thanks! I'm interested to know your thoughts. I feel very strongly about the need for this kind of port in order for ZC to stay vibrant in the future. While I'm not currently an active developer, I am willing to work on at least Phase 1 (single-handedly, if necessary), but I don't want to do anything without extensive discussion with the existing developers.

Quote:

---

Originally Posted by DarkDragon

Before I begin with the proposal proper, let me offer some motivation. What elements are essential to ZC's success in the future? Many ideas have been discussed about what features are most important for a hypothetical "ZC 3.0," and while new features keeping ZC fresh are important to its success, they are not as critical as the following two pillars:

1. Ability to play all existing in the Quest Databases.

Put simply, the quest databases are the most valuable assets the project has right now. The ability to create your own quests is extremely important to ZC and its community, but I'd argue that the #1 draw for new users, by far, is the ability for them to download ZC and then play hundreds of Zelda-like games created by fans, many of them of quality rivalving the official Nintendo SNES and GB games. If ZC development stopped completely, ten years from now someone might still discover the binaries and the quest databases, and rekindle interest in the project.

Therefore the ability to play old quests is paramount no matter what direction ZC development takes. Any plans that do not maintain backwards compatibility of quests (especially for the ZC player) are non-starters.

2. Portability to modern computing devices.

This is another obvious requirement: if ZC doesn't run on modern operating systems, or is temperamental/difficult to deal with on these operating systems, nobody can play any quests and the project is doomed in the long-term. ZC needs to be built on top of libraries are that as portable and future-proof as possible. (I want to carefully distinguish here between ZC having a robust and portable *back-end*, and ZC having an old-school 8-bit user interface. The two are completely separate issues, and while some might argue that the user interface in ZC and, especially, ZQuest, could do with a modern makeover, that's not what I'm talking about in this item.)

So what's the punchline? These days, a "modern operating system" doesn't mean Windows 10 (although I do have trouble running ZC on Windows 10 without tinkering with command-line switches, which is not a great state of affairs). It means Android, iOS, or even better, the browser, including the mobile browser.

---

So, my proposal is the following: clean up the ZC source and increase its portability to the point that it becomes possible to run the ZC player in the browser. This project, if successful, would allow us to put a "play it now" button on the quest databases, so that users on all manner of devices could play the custom quests right there in their browser. If we want Zelda Classic to regain mainstream visibility and attract new users, this has to happen, and it will only get harder the longer the delay.

And this is not as crazy of a proposal as it might sound. Projects like quakejs demonstrate the feasibility of porting natively-C++ games of the complexity level of Zelda Classic to JavaScript on the browser. But, I'm also aware that this is far from a trivial task. The main challenges I foresee are the following, with the toughest listed first:
- Allegro must be replaced by a more portable back-end. SDL is the obvious choice here, as it already is well-supported by the Emscripten C++-to-JavaScript compiler.
- ZC must be optimized to run at a reasonable speed in the browser. It also has to fit within JavaScript's allowed memory footprint (a little bit over 1GB), which I don't think is a problem for most existing quests, but is a limit we should keep in mind before we insert any additional feature bloat into ZC.
- ZC currently uses hardware bitmaps, multiple threads, and other miscellaneous low-level features that are not supported by JavaScript. These will have to be stripped out and rewritten.
- All of the above has to be done without completely breaking ZQuest (and, I suppose, ROMview). If ZQuest also runs in the browser, that's great, but I think getting the player to work is far more important, so that it's OK is ZQuest remains a desktop-only app.

---

So how do we go about doing this? Forking the current code and starting a complete rewrite will not work: it is too big of a task to complete in one go. Instead, I propose working incrementally towards the goal of porting to the browser. I envision the work proceeding in three phases:

Phase 0: Get Current Development Efforts on Track (time frame: a few weeks)
To be honest, even after reading the ZC development threads here and at PureZC, I'm not quite sure what the current development vision is. Before any new work can begin, our existing resources need to be organized. In particular:
1. As ZoriaRPG mentioned in the other thread, the repository needs to be cleaned up, with a reasonable branch structure, a modern build system, instructions included for how to build the source, etc.
2. The management of the project needs to be clarified. Who has access to the main repository? What is the procedure for adding or removing "core developers"? How are new features proposed, discussed, and approved? What is the procedure for code review of patches submitted by the main developers? Outside developers? Where and how should users submit bug reports? Etc.
To be clear, I don't mind if the answer to several of these is "Gleeok decides and rules with an iron fist." This is much better than developers working independently and at cross-purposes!

Phase 1: Wean The Current Code Off of Allegro Utility Libraries (time frame: 1-2 months)
The code current relies on several Allegro utility libraries that could be removed or rewritten, without needing to add any additional libraries, and without removing the core Allegro graphics backend. These include
- the packfile system
- the fixed-point arithmetic handling
- memory management
- some of the GUI code (jwin) which can be converted to using a wrapper around core Allegro functionality
Other aspects of this phase not related to replacing Allegro features:
- creating some system for automatically testing old quest compatibility, to ensure development does not break these quests (for example, by implementing a "quest demo" playback system, which checks that the same commands entered into the same quest result in the same final game state before and after each change).
- avoiding adding any new features which ties ZC more closely to Allegro, or to its current GUI or hardware backend.

Phase 2: Replace Allegro with SDL (time frame: 6 months)
This will require
- replacing all I/O and bitmap operations with SDL equivalents. This is easier the more of the GUI code can be wrapped during Phase 1, but there's no point beating around the push: this part will be long and involved.
- rewriting the sound library to use SDL_mixer instead of the current hodge-podge of external music libraries.
- replacing jwin with Saffith's GUI library?

Phase 3: Complete The Port (time frame: 3 months?)
Once Allegro has been replaced with SDL, there will still need to be miscellaneous cleanup necessary before ZC can run successfully online. Here are some issues I anticipate, though I'm sure there are others that will crop up over time:
- switching to LLVM instead of MSVC/gcc
- modifying the handling of the filesystem to allow for online play
- optimizing the rendering or script engine, as necessary, to ensure reasonable frame rates.

---

If you have read this far, thanks! I'm interested to know your thoughts. I feel very strongly about the need for this kind of port in order for ZC to stay vibrant in the future. While I'm not currently an active developer, I am willing to work on at least Phase 1 (single-handedly, if necessary), but I don't want to do anything without extensive discussion with the existing developers.

---

While all this sounds intriguing, I can't really imaging being able to properly support existing quests, given all of the eccentricities that we already need to support, in merging to a new back-end. I would frankly think that a port to JavaScript should be an alternative, that permits browser play, at the sake of some compatibility loss, if a user wishes to pursue that route, while a mainstream binary is still usable.

I'm not sure if most ZC users today would be interested in using a web browser for it, but I suppose that's generational. I really have no idea there, but in any case, I think that the timeframes in your outline are rather unrealistic. A port out of allegro, with our present developer resources, will likely take two years, not six months. I don't know a blasted thing about modern JS, and it's something that TBH I've avoided like the plague; and browsers in the future are more likely to slowly drop support for JS, as they did Flash, because of its inherent vulnerabilities.

Above all else, that is what would worry me about this. It's no more of a guarantee to future usefulness than porting to allegro 5, which is still supported, and runs on both desktop, and mobile platforms, natively.

Quest memory footprints and ZC RAM usage could possibly exceed 1GB, but IDR if I've personally experienced that. I've certainly come close though. Much of that could be cleaned up with new memory management, but really the present lack of any motivation towards a future goal has stalled things for a year.

Something else to consider, is the shift toward things like ARChon, whereby you could run an Android-native ZC binary in Chrome. Likewise, mobile devices are as much the future of a programme as anything else, and browser play on mobile devices is pretty lacklustre. In general, Android devices forward the browser to an app for almost everything, and web browsers on mobile devices see far less use than all the other net apps. To me, ZC as a net app makes the most sense, and AG5 would do that; and AG5 would be the easiest port, with the least compatibility loss.

It's still a huge undertaking, that requires far more people than are now involved. If we had a dozen people working on this, sure, why not; but we don't.

Above all this, floats the same issue that haunted AM2R. Don't get too big for your britches. It's good to ensure that ZC stays in use, but if you turn it into a web software platform, then you also need to support the bandwidth infrastructure, which means you need to generate revenue. Who will pay for that, and how?

Don't forget audio packs when you consider this. The audio package for Quest 744 is 95MB in size, plus the 5MB quest file. If one user a day plays it, that's 36GB per year. Consider that if this was a popular service, you could have 100 users on it a day, or 3.6TB a year, just to support 'streaming' that quest. Streaming backbones are hideously costly, however you approach them.

We can't commercialise ZC, and we certainly can't rent out the work product of the questmakers. That model not only isn't viable, it also isn't legal, so, before worrying about a deployment model, it's important to consider the long term maintenance upkeep, and if it's even plausible to consider such a thing. Then, the takedown notice issue arises, too. Staying 'low-profile' and 'home made' is a major factor in why ZC is still alive today, too; thus if you make it too popular, you could demolish it in the process.

Quote:

---

I don't know a blasted thing about modern JS, and it's something that TBH I've avoided like the plague; and browsers in the future are more likely to slowly drop support for JS, as they did Flash, because of its inherent vulnerabilities.

---

I agree with all of this, but fortunately writing a program in JavaScript these days does not necessarily require writing a single line of actual JavaScript. Once the code is in a sufficiently portable form (compiles under LLVM, is free of odious external libraries, and doesn't rely on platform-dependent code or hardware) it can be targeted to JavaScript or whatever becomes the next language of the web.

Quote:

---

It's no more of a guarantee to future usefulness than porting to allegro 5, which is still supported, and runs on both desktop, and mobile platforms, natively.

---

I don't want to wade into an Allegro vs SDL debate; my reasoning for choosing SDL comes down to just a single bit: SDL supports Emscripten, and Allegro does not.

Quote:

---

If one user a day plays it, that's 36GB per year. Consider that if this was a popular service, you could have 100 users on it a day, or 3.6TB a year, just to support 'streaming' that quest. Streaming backbones are hideously costly, however you approach them.

---

Quest 744 is an extreme outlier (to the point that even the QDB doesn't include the music pack by default). If ZC's popularity takes off to the point that 100 new users per day are playing Quest 744 specifically, that is a "good problem" and a bridge that there's no point crossing until we get there. (Especially since, as you note, by the time ZC becomes this high-profile it will almost surely have drawn the attention of Nintendo legal.)

Quote:

---

We can't commercialise ZC, and we certainly can't rent out the work product of the questmakers. That model not only isn't viable, it also isn't legal, so, before worrying about a deployment model, it's important to consider the long term maintenance upkeep, and if it's even plausible to consider such a thing. Then, the takedown notice issue arises, too. Staying 'low-profile' and 'home made' is a major factor in why ZC is still alive today, too; thus if you make it too popular, you could demolish it in the process.

---

I don't think I completely buy this argument. It's true that Nintendo could issue a takedown notice at any time (and has done so for fan games even less popular than ZC). This is a good reason to think about segregating the core game code from the Zelda-branded art, music, and gameplay mechanics to as great an extent as possible. But "keep ZC obscure and difficult to use in the hopes that Nintendo leaves us alone" is self-defeating in the long term.

Quote:

---

I can't really imaging being able to properly support existing quests, given all of the eccentricities that we already need to support, in merging to a new back-end

---

I really hope this isn't true. As I argue above, I don't think ZC will survive much past the day that it stops being able to play old "greatest hits" quests.

We missed you around here DD.

I was also wondering how the javascript thing would work until you mentioned Emscripten; now it makes more sense.

To answer the back-end concerns: I've switched various 'multimedia' libraries many times for other hobby projects in the past, sometimes halfway through a project, all without changing a single line of program code. I can drop in an allegro5, SDL, sfml, GLFW, etc. library to a project and all it needs is about 12-20 functions 'wrapped'. That's it. Trust me when I say that none of this really matters. The [only] important thing here is designing a very small concise API that can replace allegro calls directly in ZC; it doesn't matter where it goes after that, and who cares anyway?! ~Open a window; get an OpenGL context; get input; done.

I'm sort of in the same boat as you I suppose DD. Something similar was brought up a couple of years ago and my thoughts now are the same as back then: It's a very large project and I don't have time for it. A complete rewrite is also a large project and I don't have time for that either. However, although I prefer option 2, I can probably only do so much of the same on either, so that's why... I'm willing to work on specific parts of it like, plus anything that I can contribute that coincides with code I either already have or need to write anyway (If that turns out to be anything at all). I believe back then I said the rendering, since I was the only one with OpenGL experience at the time, but sound code should be doable as well, with a gme plug-in as long as SDL_Mixer supports it.

Quote:

---

Originally Posted by Gleeok

We missed you around here DD.

I was also wondering how the javascript thing would work until you mentioned Emscripten; now it makes more sense.

To answer the back-end concerns: I've switched various 'multimedia' libraries many times for other hobby projects in the past, sometimes halfway through a project, all without changing a single line of program code. I can drop in an allegro5, SDL, sfml, GLFW, etc. library to a project and all it needs is about 12-20 functions 'wrapped'. That's it. Trust me when I say that none of this really matters. The [only] important thing here is designing a very small concise API that can replace allegro calls directly in ZC; it doesn't matter where it goes after that, and who cares anyway?! ~Open a window; get an OpenGL context; get input; done.

I'm sort of in the same boat as you I suppose DD. Something similar was brought up a couple of years ago and my thoughts now are the same as back then: It's a very large project and I don't have time for it. A complete rewrite is also a large project and I don't have time for that either. However, although I prefer option 2, I can probably only do so much of the same on either, so that's why... I'm willing to work on specific parts of it like, plus anything that I can contribute that coincides with code I either already have or need to write anyway (If that turns out to be anything at all). I believe back then I said the rendering, since I was the only one with OpenGL experience at the time, but sound code should be doable as well, with a gme plug-in as long as SDL_Mixer supports it.

---

I'll need to read up on Emscripten.

Really, I think we need more time to attract people to develop this thing, before we do anything this grandiose. Of the people who have been doing anything with the source outside the two internal devs, @Tamamo and I have the most comprehension of it, and I for one am not ready to commit to anything in the way of huge rewrites. As I've said before, i think we should try to get some new, fresh stuff out, lure in some more coders who can work on it, and see how things progress.

Beyond that, it doesn't matter to me what back end we use. I do fear that some allegro things mayn't carry over, and that's my largest concern.

i would however, always offer a platform-specific binary. If we can do that for the three main desktop OSes, plus Android and iOS, fantastic. A broswer version should be in addition to these. For one thing, we can;t control browser stability.

I know that ZC crashes have always been a user fear, and browser crashes are pretty common. If we do a browser version, we would really be best off investing in some kind of memory state management, so that if the player crashes, or if the browser crashes, the user can resume where they left off, rather than their last in-game save.

Quote:

---

Originally Posted by DarkDragon

I really hope this isn't true. As I argue above, I don't think ZC will survive much past the day that it stops being able to play old "greatest hits" quests.

---

IDK. There are so many tiny patches to handle quirks from past versions, up to and including 2.50.0, 2.50.1, and 2.50.2 differences, that mapping them all outside of allegro would be a pain. Not impossible probably, but who's going to do it?

Quote:

---

Originally Posted by DarkDragon

I agree with all of this, but fortunately writing a program in JavaScript these days does not necessarily require writing a single line of actual JavaScript. Once the code is in a sufficiently portable form (compiles under LLVM, is free of odious external libraries, and doesn't rely on platform-dependent code or hardware) it can be targeted to JavaScript or whatever becomes the next language of the web.


I don't want to wade into an Allegro vs SDL debate; my reasoning for choosing SDL comes down to just a single bit: SDL supports Emscripten, and Allegro does not.


Quest 744 is an extreme outlier (to the point that even the QDB doesn't include the music pack by default). If ZC's popularity takes off to the point that 100 new users per day are playing Quest 744 specifically, that is a "good problem" and a bridge that there's no point crossing until we get there. (Especially since, as you note, by the time ZC becomes this high-profile it will almost surely have drawn the attention of Nintendo legal.)

---

While there aren't yet a significant number of quests that use huge soundtracks, many now do. Yuurei, Panolopy of Calatia, Isle of Rebirth. The quests that are the most popular these days, often have enhanced music. Really, the lack of it in the past is primarily because users have nowhere to upload it with the quest files. Again, a live play site would need to permit it, and then we might get into copyright issues. Hell, I'm shocked that we haven't yet.

It's something to consider, but I suppose making the system run in a browser, and offering the service, are ultimately separate topics. I remember making an Apple Ii emulator that could run in a browser, and run game images, and that was a Java applet. It wasn't fun, but it was a closed feature; this meaning that only members of the BBS knew it existed at all. It also didn't work too well, as handling images on a per-user basis was a huge pain to get right.

I pretty much laid it out that when a user selected an image, it copied it over to user space, and ran it, so that saving was per-user. We'd need to do that with .sav files.

If we do manage this at some point, I would like to see cooperative/multiplayer net-play as an option.

Quote:

---

I don't think I completely buy this argument. It's true that Nintendo could issue a takedown notice at any time (and has done so for fan games even less popular than ZC). This is a good reason to think about segregating the core game code from the Zelda-branded art, music, and gameplay mechanics to as great an extent as possible. But "keep ZC obscure and difficult to use in the hopes that Nintendo leaves us alone" is self-defeating in the long term.

---

If we were to do this, rebadging it would be wise. That way, the only actual 'Zelda' infringement is from fan-made quests. But again, a solid business model for supporting the bandwidth would be in order.

Quote:

---

Originally Posted by Gleeok

To answer the back-end concerns: I've switched various 'multimedia' libraries many times for other hobby projects in the past, sometimes halfway through a project, all without changing a single line of program code. I can drop in an allegro5, SDL, sfml, GLFW, etc. library to a project and all it needs is about 12-20 functions 'wrapped'. That's it. Trust me when I say that none of this really matters. The [only] important thing here is designing a very small concise API that can replace allegro calls directly in ZC; it doesn't matter where it goes after that, and who cares anyway?! ~Open a window; get an OpenGL context; get input; done.

---

That makes sense. Wrapping Allegro code into a small set of functions (and cleaning up the code a bit in the process) seems like a helpful modification no matter where the project goes, in terms of switching to Allegro 5, or SDL, or what have you. I will take a stab at doing this in the free time I have here and there.

More urgently, though, we need to do something about the status of the repository, and establish standard procedures (if they don't exist already?) for how patches by contributors are reviewed, what standards are expected from the patches, etc. Do you have thoughts on this?

Quote:

---

Originally Posted by DarkDragon

That makes sense. Wrapping Allegro code into a small set of functions (and cleaning up the code a bit in the process) seems like a helpful modification no matter where the project goes, in terms of switching to Allegro 5, or SDL, or what have you. I will take a stab at doing this in the free time I have here and there.

---

We should probably decide if the end goal is going to be rendering on the GPU or not. This affects all the palette code, as well as most of maps.cpp and part of link.cpp.

Quote:

---

Originally Posted by DarkDragon

More urgently, though, we need to do something about the status of the repository, and establish standard procedures (if they don't exist already?) for how patches by contributors are reviewed, what standards are expected from the patches, etc. Do you have thoughts on this?

---

Not really. >_<

I think we need to modify the quest loading routine to handle quest files that aren't binary compatible with it though. So if someone else changes the format of a quest file it will bail out instead of corrupting it 'gracefully'.

Quote:

---

Originally Posted by Gleeok

We should probably decide if the end goal is going to be rendering on the GPU or not. This affects all the palette code, as well as most of maps.cpp and part of link.cpp.



Not really. >_<

I think we need to modify the quest loading routine to handle quest files that aren't binary compatible with it though. So if someone else changes the format of a quest file it will bail out instead of corrupting it 'gracefully'.

---

Quote:

---

Originally Posted by DarkDragon

That makes sense. Wrapping Allegro code into a small set of functions (and cleaning up the code a bit in the process) seems like a helpful modification no matter where the project goes, in terms of switching to Allegro 5, or SDL, or what have you. I will take a stab at doing this in the free time I have here and there.

More urgently, though, we need to do something about the status of the repository, and establish standard procedures (if they don't exist already?) for how patches by contributors are reviewed, what standards are expected from the patches, etc. Do you have thoughts on this?

---

Here's my question: Aside from Gleeok, Saffith, potentially DD, and the three of us doing 2.future, who is even participating at this point? Tamamo bailed. The bloke who did some minor stuff to the dead master branch never joined the forum, and all his changes were cut, AFAIK.

Sorting the repo should be the highest priority. It's not possible to do a push at all at present, because there's no logical candidate set up.

What is 2.future?

Here is a great example about why I have such a bee in my bonnet about maintaining quest compatibility: http://www.purezc.net/forums/index.p...5#entry1012120

@DarkDragon
That's why i've motioned several times to completely and officially separate ZC into two different versions.
A legacy branch for 2.5.x backwards compatibility which we simply keep up to par with the modern day OS, and a rewrite version
I forgot what the internal devs said though.

It's been discussed a lot.

Reasons for a complete rewrite:
- current codebase crufty and difficult to work with
- opportunity to "wipe the slate clean" of poorly-thought-out features that continue to shackle us

Reasons against a complete rewrite:
- nobody can agree on what features it should support ;)
- will take a long time to finish; doesn't benefit quest authors in the meantime
- inertia / quest authors don't want to learn a completely different set of tools


My own opinion has switched back and forth a few times on whether a rewrite is a good idea. My current thoughts are quite strongly against the idea, mostly because if you want a Zelda-like game engine rewritten from the ground up, you can find many projects being developed that are doing that already. The comparative advantage of ZC is its huge database of existing quests, and the pool of users with the knowledge of how to effectively use the existing tools.

Quote:

---

Originally Posted by DarkDragon

It's been discussed a lot.

Reasons for a complete rewrite:
- current codebase crufty and difficult to work with
- opportunity to "wipe the slate clean" of poorly-thought-out features that continue to shackle us

Reasons against a complete rewrite:
- nobody can agree on what features it should support ;)
- will take a long time to finish; doesn't benefit quest authors in the meantime
- inertia / quest authors don't want to learn a completely different set of tools


My own opinion has switched back and forth a few times on whether a rewrite is a good idea. My current thoughts are quite strongly against the idea, mostly because if you want a Zelda-like game engine rewritten from the ground up, you can find many projects being developed that are doing that already. The comparative advantage of ZC is its huge database of existing quests, and the pool of users with the knowledge of how to effectively use the existing tools.

---

While I was in support of the rewrite, though it was with faint hope, I don't think this idea is black and white, or: rewrite or not rewrite. ZC needs refactoring. Every discussion on ZC Dev points to this. I can hardly look at the code and not want to kill myself. It's one of the biggest issues that have kept me from really digging in and learning how to contribute. If it took Zoria a year and a half to get a handle on the code, how do we ever expect to attract a decent amount of contributors?

My idea:
Part 1:
* Maintain ZC 2.5x as bug fix only version that handles quests from all supported versions of ZC from 2.5 and back.
* Allegro 4.4 and any other library updates that are needed and feasible without too much fuss are done for the sake of bug fixes, fullscreen bug, midi bug, etc... that have been long standing issues. Or future OS issues, say Windows 15 Negans ZC like *SPOILER*.
* That's it. No new features. Ever.

Part 2:
* ZC version jumps to 3.0.
* Legacy support is dropped. ZC 3.0 supports only 3.0+ quests.
* Code can be refactored without worry of breaking a back log of quest features\quirks. With an eye on moving away from Allegro.
* Strict faithfulness to NES is dropped. 99% of people don't care if that is how it was on NES. ZC has evolved beyond a Zelda 1 clone. NES faithful quests can be made with 2.5x versions.
* latest ZC 2.5x player is bundled with 3.0 and launched when a pre 3.0 quest is opened.
* development focuses first on improving existing code and adding features that improve the tools/experience ZQ users are accustom to. No crazy, "we need z3 scrolling NAO!" features.

The thing is I'm not convinced people actually want to learn to use a completely new quest authoring system with no support for their old quests and assets. I mean, if people want this, wouldn't they just switch to other engines like Solarus?

Quote:

---

Originally Posted by DarkDragon

The thing is I'm not convinced people actually want to learn to use a completely new quest authoring system with no support for their old quests and assets. I mean, if people want this, wouldn't they just switch to other engines like Solarus?

---

What about my post made you believe they would have to do such a thing? It would still be the ZQ they know and I don't see why it would be impossible to import ZC 2.5 quest files to get it's assets into a 3.0 quest. Transitioning your in-development quest from 2.5 to 3.0 should be as painless as possible. Going from 2.5 to3.0 wouldn't be like switch to another software, and why would it? When I said refactoring I really didn't mean a total rewrite. I meant piece at a time. Changing quest format, reworking Zscript or switching to AngelScript, getting away from Allegro Utilities, reworking historicly problematic items/feature, or stuff like that fisrt. Deeper stuff later on.

Quote:

---

Originally Posted by DarkDragon

The thing is I'm not convinced people actually want to learn to use a completely new quest authoring system with no support for their old quests and assets. I mean, if people want this, wouldn't they just switch to other engines like Solarus?

---

While I can't give a definitive answer, since I don't truly know myself, I'll guess that the reason people like ZC is because it has it's own small community and everything. That is, it's a community small enough where, if you were to release your own content, it had a more higher chance of being noticed. The community also provides fast support.

Then there's the easy to make part. I can pick up ZC and make a quest that's playable from start to end fairly easy, even if it's only a classic quest. ZC also has a lot of freedom, while still being easy to use. On one hand ZC lets you make NES Zelda clones. On the other ZC lets you make masterpieces like Panoply of Calatia, Lost Isle, Banana Blood God,To The Top, and (sigh) Hero of Dreams. ZC is both easy and complex, which allows for one to make the game they desire.

Also, there's the fact that the ZC community is a bit elitist. You can feel empowered by being a part of it. You can also expect quite a bit of consistent content, as the community has both experienced quest makers and up and coming ones.

Finally, TBH I'm a bit scared off by Solarus presenting itself as a generic Game Maker type thing. Keyword: Generic. Zelda Classic has the benefit of being a fan product, used by fans of Zelda. This easily means that the ZC community also doubles as a Zelda Fan community. If AM2R was a generic space marine on distant planet without the Metroid assets, it'd be bland and wouldn't have the fanbase it does now.

...Then again, I don't speak for the ZC community. These are just some of my reasons that I thought of.