51 replies to this topic

[ctrl-alt-delete]

Is there any way of getting the DS SDK?

The trickiest part of porting ZC to a new platform is its reliance on Allegro. The first step would be to port Allegro, or strip Allegro out of ZC entirely.

You're missing an epic conversation on #purezc concerning this.

(Would you need the SDK to develop it as homebrew? If so, I'm sure it's available.)

[Radien]

*reads announcement* Hmmm. Interesting. I hope this does indeed ensure ZC's survival, rather than create a mass of splinter programs. Having multiple versions of an editor/player program like this would be a mess. Despite the many versions of the program, a large part of its appeal is compatibility.

Regarding passwords: I am unhappy about the plans to remove password support. At this point I think it's very likely that I will not use any version of ZC beyond 2.50, mostly for that purpose. I have spent countless hours on my quests, and I want the ability to decide who I allow to dissect my work.

For a long time now, all I have wanted in ZC has been stability. If the slow creep of "feature bloat" continues (or speeds up) after ZC goes open-source, then 2.50 will be where I stay, permanently.


Now, one important thing I want to emphasize to everyone making suggestions in this thread:

As far as I can remember from all my time on the forums and on staff, merging PZC and AGN was never officially proposed. (Edit: it looks like LTM and Nick talked about the possibility at some point, but it didn't get much further than that.) I know many PZC members have wondered why this can't be done, but when you say "I vote for" or "I'm all in favor of," well... I'm sorry, but you don't have the authority to initiate that.

PZC often acts as a pseudo-democracy in its day-to-day runnings, but it's still all owned by one person, and if a merger were ever considered, that matter would be between WildBill and Warlord. Neither of them seem to want it to happen, so it's off the table. I know it sounds like a good idea to many of you, but in the end, it's a pipe dream.

(I also think it would be a bad idea if it ever WERE being seriously considered, personally. It amounts to overcoming huge obstacles, all over a matter of semantics.)

[ctrl-alt-delete]

*reads announcement* Hmmm. Interesting. I hope this does indeed ensure ZC's survival, rather than create a mass of splinter programs. Having multiple versions of an editor/player program like this would be a mess. Despite the many versions of the program, a large part of its appeal is compatibility.

Regarding passwords: I am unhappy about the plans to remove password support. At this point I think it's very likely that I will not use any version of ZC beyond 2.50, mostly for that purpose. I have spent countless hours on my quests, and I want the ability to decide who I allow to dissect my work.

For a long time now, all I have wanted in ZC has been stability. If the slow creep of "feature bloat" continues (or speeds up) after ZC goes open-source, then 2.50 will be where I stay, permanently.
Now, one important thing I want to emphasize to everyone making suggestions in this thread:

As far as I can remember from all my time on the forums and on staff, merging PZC and AGN was never officially proposed. (Edit: it looks like LTM and Nick talked about the possibility at some point, but it didn't get much further than that.) I know many PZC members have wondered why this can't be done, but when you say "I vote for" or "I'm all in favor of," well... I'm sorry, but you don't have the authority to initiate that.

PZC often acts as a pseudo-democracy in its day-to-day runnings, but it's still all owned by one person, and if a merger were ever considered, that matter would be between WildBill and Warlord. Neither of them seem to want it to happen, so it's off the table. I know it sounds like a good idea to many of you, but in the end, it's a pipe dream.

(I also think it would be a bad idea if it ever WERE being seriously considered, personally. It amounts to overcoming huge obstacles, all over a matter of semantics.)

Removing password support? Where was that?

A true merger was never considered. PZC becoming an official forum was talked about, but plans fell through.

[NoeL]

Awesome! Very excited to hear it's going open source - hopefully someone tech savvy can get allegro working on MIPS so I can one day get a ZC player running on the GCW Zero!

Another thing that excites me about the move to open source is that people will be able to make stand-alone binaries for their quests. This'll make it much easier to showcase quests to people that aren't familiar with the player, and people will even be able to SELL their quests (provided they make their source code publicly available (a requirement under the GPL) and don't use Nintendo's or any other copyrighted assets (because that would be very bad!)). I think we're likely to see a stripped-down release, with all Nintendo content removed and a name change, making it more of a Zelda-style "Action Adventure Game Maker". Maybe not from the ZC devs themselves, but someone will do it.

[SUCCESSOR]

... people will even be able to SELL their quests (provided they make their source code publicly available (a requirement under the GPL) and don't use Nintendo's or any other copyrighted assets (because that would be very bad!)).

It will not be acceptable for ZC to be for sale in any way. No one wants to see that happen. I assume you are talking about making a branch of ZC without Nintendo's IP that uses custom graphics, sounds, etc and sells quests? First of all who would pay for something they can get for free, that should be free, and is meant to be free? Second it makes ZC look bad. Finally it could bring legal trouble on ZC. The program is a Zelda Fan game built for and to emulate Zelda 1 quests. Selling content for it is a bad idea.

[NoeL]

Sorry, I didn't make myself clear when I said "sell their quests". People don't sell Zelda Classic (i.e. the thing people can get for free), they sell a custom build of the Zelda Classic player (that's not called "Zelda Classic", obviously) that's integrated with a specific quest they made themselves (neither of which would be available for free, unless the author decides to freely distribute it as well as selling it (why?)). The package (integrated quest + custom ZC build) they're selling would need to be stripped of all Nintendo's stuff, obviously - you shouldn't need to "assume" that given I stated that pretty clearly. I don't see how it makes ZC look bad, and as long as you're not using Nintendo's assets there's nothing illegal about it. It's not illegal to make a game that has similar mechanics to another game. And "bad idea" or not, once it's made open source you don't have control over what people will do with it - including whether or not they want to sell their creations.

I should repeat, just to make myself clear and make sure the kids that don't understand copyright law don't get themselves into trouble, you CANNOT sell your works if they contain any copyrighted material! This means ALL of your graphics, sound effects, music, fonts, characters, maps - including those in the ZC player - need to be original or public domain. You CANNOT sell a "Zelda" quest, and you'd be strongly advised to keep anything Zelda-related - including the name - out of your product. If you're not sure whether or not your game is legal, better to be on the safe side and release it for free. Selling involves all sorts of taxes and things, so best to stay clear until you know what you're doing.

EDIT: Also, don't sell quests that require the official Zelda Classic player to run, even if it's all original content. Keep Zelda and Zelda Classic as far away from your game as possible.

Edited by NoeL, 23 October 2012 - 07:35 AM.

[DarkDragon]

Regarding passwords: I am unhappy about the plans to remove password support. At this point I think it's very likely that I will not use any version of ZC beyond 2.50, mostly for that purpose. I have spent countless hours on my quests, and I want the ability to decide who I allow to dissect my work.

Password support isn't being removed and probably won't ever be.

The issue with quest encryption is more subtle, and boils down to the following paradox: in order for anyone to play your quest, ZC must be able to read in all of your quest data. How can you allow ZC to read in the data, without allowing a random user to do the same?

Zquest won't let a random user open your quest if they don't know the quest password, but the password check can be circumvented (as the devs sometimes do when a user forgets their password) by using the same workaround that ZC does to read the quest without a password. Once we release the source code, if we didn't take steps to prevent it, any user could create their own version of Zquest that skips the password check completely. (In fact even now anyone with enough dedication and a good debugger could do that.)

To make it a little bit harder to strip out the passwords from quests, the entire quest file itself is encrypted. By keeping the decryption key closed, we will be making it harder for third party programmers to modify the source code to open old quests without their passwords. Not impossible, of course: as I said above, quest passwords are fundamentally insecure, since ZC must have a backdoor to read the quest and play it -- but not significantly easier than it would be now, from studying the leaked source code and doing a bit of debugging.

Edited by DarkDragon, 23 October 2012 - 09:44 AM.

[Moosh]

Regarding passwords: I am unhappy about the plans to remove password support. At this point I think it's very likely that I will not use any version of ZC beyond 2.50, mostly for that purpose. I have spent countless hours on my quests, and I want the ability to decide who I allow to dissect my work.

ZQuest passwords are sort of like a wall made of nilla wafers. There are so many ways to crack them open that pretty much the only requirement is wanting to open the quest. If someone actually wants to open your quest and rifle through it, they can. Even if removing password support was a thing, it really wouldn't change anything. Say I opened your quest and went digging through it. What would I do? Certainly not rip tiles or other things from it. I might take a peek at the script buffer to see what's going on there. I might look at your map setup out of curiosity. I might get a chuckle out of a couple design choices, but who would be there to hear it? Quests aren't like anuses; if someone decides to probe yours, you won't feel a thing.

[SUCCESSOR]

Your quests have never been secure. There is a reason you are strongly suggested not to use the same password for quests that you do for other services like Facebook and e-mail. Passwords in quests have always been in place to prevent casual users from stealing. That will still be in place. Now, like it always has been, any one with a lot of desire and a little know how can get around it. The same will be true with Open Source Zelda Classic. I and a few others have been debating whether the effort should be taken to remove the encryption code at all and just release the source as a whole. No one is talking about removing the encryption system from quests completely. Our centralized community makes it very difficult to steal someone's work. Anyone doing so would face ridicule.

[Moosh]

Your quests have never been secure. There is a reason you are strongly suggested not to use the same password for quests that you do for other services like Facebook and e-mail. Passwords in quests have always been in place to prevent casual users from stealing. That will still be in place. Now, like it always has been, any one with a lot of desire and a little know how can get around it. The same will be true with Open Source Zelda Classic. I and a few others have been debating whether the effort should be taken to remove the encryption code at all and just release the source as a whole. No one is talking about removing the encryption system from quests completely. Our centralized community makes it very difficult to steal someone's work. Anyone doing so would face ridicule.

This. This right here. This is the thought that I wanted to formulate in that rambling monstrosity back there. Thanks for finding it for me, SUCCESSOR.

[Xenix]

As far as the password support removal goes, there is a workaround. Since ZC will eventually become open source, I could see the possibility of ZQuest being reprogrammed to open quests in a different way. This way would involve splitting the quest into separate files according to what they are (tiles, combo data, etc.) and would be organized into a folder that has the quest's name on it. This would be known as the developer copy. Now, when you go to release a demo or a full quest, these separate files would be compiled into a single file that cannot be opened in ZQuest but can be opened in the player. You could make this file the actual .qst file and just remove ZQuest's ability to open .qst files.

Edited by Sepulcher, 23 October 2012 - 03:49 PM.

[MoscowModder]

Hey, that's a pretty cool idea! Somewhat inconvenient for the designer, but it sounds promising.

So basically, I take it, it's a compiler for ZC quests.

[Xenix]

Hey, that's a pretty cool idea! Somewhat inconvenient for the designer, but it sounds promising.

So basically, I take it, it's a compiler for ZC quests.

Exactly. You're absolutely correct on that MoscowModder! Is it really that good of an idea? If so, then SWEET! I thought about this while I was about to fall asleep in one of my college classes. I seem to come up with my better ideas when I am on the verge of mental collapse.

You see, the way it would open the files when they are not compiled is it would have a single file that is opened that points ZQuest to the things to open. That way, you wouldn't need to open each file individually just because they are separate.

Edited by Sepulcher, 23 October 2012 - 04:07 PM.

[Saffith]

There's really no way to do that, though. ZC and ZQuest use the same data; you can't make quest loading code that would work with one but not the other.

[MoscowModder]

Well, we're talking about a potential complete re-write here. Don't you think we could make a system that not only has two different methods for editing and running but is also optimized for each?