411 replies to this topic

[Lemmy Koopa]

Well that's because Game Maker uses full color and now supports alpha images.

[Plissken]

And why shouldn't ZC also use full color?

[Lemmy Koopa]

I use Game Maker a lot, but I still think ZC is the best for making Zelda games.

Moving to true color would be beneficial, but probably would require rewriting everything that deals with the graphics.

One thing that's good about having palettes though is that you can change colors without wasting space by copying images and recoloring them just to make them a different color.

[Plissken]

Moving to true color would be beneficial, but probably would require rewriting everything that deals with the graphics.

Well...it is a rewrite we're talking about here.

[Beefster]

@JohnStacy: Like I said before, EVERYTHING necessary to make a Zelda clone will be pre-scripted. The point of pulling away from hard coding is to make the engine more modular for power users, like myself, while still making it usable by ordinary users. Support for ZASM would be maintained, and a ZScript compiler will be available. Python is merely an option.

Think RPG Maker XP. That's how ZM should function.
On that note, a snippet-based event scripting system would be very nice-- Something easy for newbies to handle- shown in plain English, but actually stored in #comment delimited Python or something similar.

And yes, ZM would undoubtedly be a fork of ZC with a focus on a clean codebase and modularity. Cross-compatibility with ZC is not a priority, but may be implemented later.

The quest file format will probably shift away from pure binary into something more like a .zip archive or a compressed .iso.

[sigtau]

I would *love* to see ZC made open source and given a proper version control system.

I know the devs are highly against that, but remember that having a proper version control system means that you could have people introduce all kinds of features without f***ing the official builds (non-devs can see the source code, devs can both read and write to the source code repository).

In addition to that, people could check out the source code, make their own builds (share the source code which can be merged into the official source by an official developer--one who has read AND write access to the code repository).

Merging code isn't that hard, either... good version control software can do that entirely for you by looking at the differences between the new build and the old build and literally merging the code changes between the two (seamlessly).

If it were open source, we'd have a lot less problems to worry about.

Edited by TMS, 08 June 2010 - 10:38 PM.

[Lemon]

I would *love* to see ZC made open source and given a proper version control system.

I know the devs are highly against that, but remember that having a proper version control system means that you could have people introduce all kinds of features without f***ing the official builds (non-devs can see the source code, devs can both read and write to the source code repository).

From what I understand most of the devs agree that it should be open source; BUT the creator Phantom Menace wished that it remained closed, and they want to respect his wishes.

[Christian]

If they are not going to make it Open Source, then they can at least search programmers that know a lot more in C++ to advance this program. I've seriously developed a love hate relationship with ZC because of the limitations.

[sigtau]

From what I understand most of the devs agree that it should be open source; BUT the creator Phantom Menace wished that it remained closed, and they want to respect his wishes.

That being said, if and when the dropping of Allegro occurs, it would probably be better off to start off an open source repository then--because it's no longer a derivative of Phantom Menace's work--it's a completely new codebase.

[Bourkification]

Phantom Menace originally wished to keep it closed source because of the password protect system. To be honest, with a re-write, I would think that the password system will be dropped in favour of a better system. And I question why if a re-write did occur why we couldn't make it an open source project. Why should we keep it closed source? Because of what the original developer said 10 years ago? Zelda Classic has changed and developed in that 10 years; expectations have changed. If the developer's really did want to respect Phantom Menace's wishes, then surely one of them (I'm placing bets on Dark Nation) knows how to contact him to ask for permission for it to become open source.

And if that happens and Phantom Menace says no, it's staying closed source, then I don't see why this so very talked about 3.0 can't happen as the first version another project that takes inspiration from Zelda Classic but incorporates these features we all talk about having. A new program, new vision, a new name, built from the ground up.

[Nathaniel]

I don't know all that much about the details of Zelda Classic's relationship with Armageddon Games, but if ZC was to be open sourced, it might have to end up on a different label (which would probably be a good thing, whether necessary or not). I guess that depends on the attitude of War Lord, owner and webmaster of Armageddon Games. Considering the state of their forums, I don't have much confidence in him. He doesn't appear to be around much anymore. Unfortunately, I don't know much about that sort of stuff, let alone owning a gaming company, even in its smallest of proportions. Yeah, open sourcing it would probably mean severing an old partnership that no longer seems to be a healthy one and going with a new one, for development beyond 2.5. But if that is a decision only dictated between Phantom Menace and War Lord, that could prove to make things even more complex.

[Cameron]

@JohnStacy: Like I said before, EVERYTHING necessary to make a Zelda clone will be pre-scripted. The point of pulling away from hard coding is to make the engine more modular for power users, like myself, while still making it usable by ordinary users. Support for ZASM would be maintained, and a ZScript compiler will be available. Python is merely an option.

Think RPG Maker XP. That's how ZM should function.
On that note, a snippet-based event scripting system would be very nice-- Something easy for newbies to handle- shown in plain English, but actually stored in #comment delimited Python or something similar.

And yes, ZM would undoubtedly be a fork of ZC with a focus on a clean codebase and modularity. Cross-compatibility with ZC is not a priority, but may be implemented later.

The quest file format will probably shift away from pure binary into something more like a .zip archive or a compressed .iso.

Then do it. This seems like a pretty good idea. And with that many changes you would have to start all over again. There would be not much use from the old source code. If you want to see someething like this then you have to do it. I don't think the devs are just going to abandon ZC and start on ZM.

You want ZM? You have to start it yourself. Talking about it isn't going to do anything.

[Plissken]

Uh...you realize ALL the devs are talking a rewrite after ZC 2.5 is released right? Beefster is simply putting forth very valid and helpful suggestions.

[Cameron]

Well if that ever happens we should probably call it something different instead of Zelda Classic 3.0 (or whatever version it would be). It would definately be a lot different than the ZC we know now. Plus, then it could be open source because it would *technically* be a different program.

Sorry if I sounded a little harsh earlier.