ZC Development Proposal

[ZoriaRPG]

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.

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?

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.

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.