411 replies to this topic

[Gleeok]

Yes, but I've worked with zc's code and let me tell you it's not pretty. But here is my real point: Go to AGN and count the number of bug threads just for enemies alone over the last year or two. Completely ridiculous if you ask me; and now you want the exact same types of things hard-coded like zc has them yet still be able to change everything about them? That makes no sense to me. I can't imagine how many bugs this would cause also. What's that saying? Those who forget the past are doomed to repeat it.

My main point from this (besides stupid long development time) is anything hard-coded you cannot change. Period. Whereas if you could click some 'enemy' tab somewhere, scroll to 'Octorock' then click 'edit enemy script', you have complete control over all aspects of changing that enemy's properties, movement, behavior,etc. ..The down side to this is that even though you have no trivial limitations to what you want to do, you need a basic understanding of scripting to do it. A solution to this might be having the enemy script inherit the properties from the base Enemy class, which is exposed as a GUI-interface and no scripting is required there. To put it another way; zc is 'hard-coded', ie; you cannot change basic functionality of simple things like, say, player walking speed ...sword combo attacks... items usable in water.. enemy movement... EXP gained by whatever.., but, if all game objects and interactions were "soft-coded", not only would/could they work the same, but you'd have the option of changing them. ...Also now that I think about it, if this is the case, I suspect there would be things like a MegaMan quest kit before a Zelda: ALTTP one, just by virtue of how much easier it would be to make. ..and the community could help fix bugs instead of *****ing about them! ..XD

Anyway, another thought: Zscript to me is actually way more complicated than need be and has a horribly clunky way of interfacing with the editor. Any sane scripting engine should be waay easier to use. ..I made all this sound like GameMaker >_>, which is funny since I hate GameMaker. :bleh:

But perhaps we can have the best of both worlds by allowing script files to be loaded and present their own configuration interface in the editor. For example, an enemy script, instead of starting with "open the script in notepad and change the following variables: speed, HP, ..." could be loaded as a file and then a dialog box doing the exact same thing pops up. This would give us "ZQuest plugins", perhaps they could somehow even integrate into the menus and so on (I'm thinking of firefox plugins here.)

That sounds like a very interesting concept. I'm not too savvy on plug-ins (or GUI designing for that matter) but if the GUI loads it's data from scripts, does that mean it would inversely use an algorithm to convert that data back into a engine script class again, which would run as bytecode etc. or be interpreted et al, when the game is run? Pretty nifty and simple concept; Would simplify the internal update methods greatly as everything ends up using a script in the end result regardless of if it was auto-generated or it was hand coded! ..Unless I misunderstood what you were referring to?

Edited by Gleeok, 21 June 2010 - 09:52 PM.

[lucas92]

So basically we want something similar to Open Zelda BUT with more built-in things so people could use the editor without scripting at all, just using scripts as Zelda Classic allow....

I'm saying this because if we could reuse code and some stuff (if there's no problem with that) to recreate an another and yet user-friendly tool.

[Bourkification]

But perhaps we can have the best of both worlds by allowing script files to be loaded and present their own configuration interface in the editor. For example, an enemy script, instead of starting with "open the script in notepad and change the following variables: speed, HP, ..." could be loaded as a file and then a dialog box doing the exact same thing pops up. This would give us "ZQuest plugins", perhaps they could somehow even integrate into the menus and so on (I'm thinking of firefox plugins here.)

You win. This could be the best approach. Combining my idea for the different script packages with the interface of 2.5.

[Nathaniel]

We can discuss all the fine details about the new program all we want until the cows come home, and disagree about it equally as long, but we can't forget what is most important: getting there in the first place. Right now while 2.5 is still in the works, it is just talk, and ultimately what exactly is done is completely up the the developers. They don't need to listen to outside feedback, but will if they choose to. So lets cut to the chase, as I have a proposal for it all. Bear in mind that it is just a proposal.

To consider the idea of open sourcing all future versions of ZC, against the wishes of ZC's founder, and perhaps even against the owner of Armageddon Games (I don't know his stance, if it matters), both of whom are no longer actively involved (or involved at all) in the making of ZC: The following would need to happen to cut all strings that hold the future of the program hostage:

1. Set a deadline for when all 2.5 development comes to an end and thus an official release of it is made, and set it ASAP. This needs to be done. Period. It is so long overdue, words can't possibly express it enough. Development beyond 2.5 is all just talk until this is done. If it was up to me, I would set a deadline for December of 2010. Bring this to an official finish before we enter yet another year. If there are still bugs to crank out by then, who cares? Release it as official anyway. Chances are it will be several more years if we wait for it to be nearly bug free. By then nobody would care anymore. The current situation is a crutch to the future of the program, and will continue to be as long as 2.5 is still being worked on.

After the deadline and the official 2.5 release:

2. Rename the program. The program is being redesigned from the ground up anyway, something the developers generally agree needs to be done, so it is not as if the program itself is being stolen away from Phantom Menace. But you can't steal the exact name either. Use what you can legally get away with, such as a slight tweak in the name, such as "Pure's Zelda Classic" (if there is a move to PureZC) or "Zelda Classic Deluxe", with the words Zelda and Classic being most emphasized when presented. It is essentially a brand new program, rather than simply a newer version of an old one. Despite the rename, continue to give credit to Phantom Menace for the original idea of the program, thus as to what the new one is based on, out of the respect that he clearly deserves.

3. Leave Armageddon Games. Go with a different gaming label. To avoid trouble with Nintendo, the new gaming label should be nonprofit. Any surplus revenue, if it exists, would be strictly for the funding of the program and the upkeep of the gaming label's official web site. As for the current label, Armageddon Games is a very poorly managed gaming company (if you claim it to be managed at all, beyond the bare necessities), mainly due to loss of interest among those who are responsible for running it. The AGN website is a shipwreck, due to frequent attacks and gross neglect. The developers must have a new home and official site for the program, where they can continue to do what they do best with minimal disruptions and strong administrative support. It can either move to the currently most active ZC site, PureZC, to another ZC site that already exists, such as ZCRealm, or to a brand new site. Either of those solutions would be significantly better than the current situation, despite the work involved in such a move. Wherever it goes, all development would happen there. The front page of the new site would have to act as an official and permanent replacement for the currently broken one, zeldaclassic.com, which is probably now under lists for sites to continuously attack. With a program name change, there would no longer be a need to continue using the old domain.

[Cameron]

Yes, but I've worked with zc's code and let me tell you it's not pretty. But here is my real point: Go to AGN and count the number of bug threads just for enemies alone over the last year or two. Completely ridiculous if you ask me; and now you want the exact same types of things hard-coded like zc has them yet still be able to change everything about them? That makes no sense to me. I can't imagine how many bugs this would cause also. What's that saying? Those who forget the past are doomed to repeat it.

My main point from this (besides stupid long development time) is anything hard-coded you cannot change. Period. Whereas if you could click some 'enemy' tab somewhere, scroll to 'Octorock' then click 'edit enemy script', you have complete control over all aspects of changing that enemy's properties, movement, behavior,etc. ..The down side to this is that even though you have no trivial limitations to what you want to do, you need a basic understanding of scripting to do it. A solution to this might be having the enemy script inherit the properties from the base Enemy class, which is exposed as a GUI-interface and no scripting is required there. To put it another way; zc is 'hard-coded', ie; you cannot change basic functionality of simple things like, say, player walking speed ...sword combo attacks... items usable in water.. enemy movement... EXP gained by whatever.., but, if all game objects and interactions were "soft-coded", not only would/could they work the same, but you'd have the option of changing them. ...Also now that I think about it, if this is the case, I suspect there would be things like a MegaMan quest kit before a Zelda: ALTTP one, just by virtue of how much easier it would be to make. ..and the community could help fix bugs instead of *****ing about them! ..XD

Anyway, another thought: Zscript to me is actually way more complicated than need be and has a horribly clunky way of interfacing with the editor. Any sane scripting engine should be waay easier to use. ..I made all this sound like GameMaker >_>, which is funny since I hate GameMaker. :bleh:
That sounds like a very interesting concept. I'm not too savvy on plug-ins (or GUI designing for that matter) but if the GUI loads it's data from scripts, does that mean it would inversely use an algorithm to convert that data back into a engine script class again, which would run as bytecode etc. or be interpreted et al, when the game is run? Pretty nifty and simple concept; Would simplify the internal update methods greatly as everything ends up using a script in the end result regardless of if it was auto-generated or it was hand coded! ..Unless I misunderstood what you were referring to?

Well I'll have to agree with you. I don't have a lot of knowledge about this kind of thing and was doing my best to make suggestions.

This seems to be the way to go.

[Koopa]

Those who forget the past are doomed to repeat it.

If it weren't for the historical implications then that could be the motto for the 'new ZC' - whatever we call it.

For the plug-in system, I was thinking of having something we could call 'meta-commands' in the scripting language. These are like comments to the actual script, but the plugin manager can use them.

For example, whereas nowadays you might start a configurable enemy script with:

CODE

//Enemy HP. Must be a whole number > 0.
int HP = 4;
// Enemy speed. Must be a whole number from 1 to 4.
// 1 corresponds to the speed of the redo octorok, 2 the blue, 4 the octorok on crack.
int speed = 2;
// How often the enemy fires its weapon on average, per second.
// Numbers > 1 make it fire less than once a second.
float fireRate = 4.0;

and users would open the script, edit the values and recompile it, we could do something like this (assuming # starts a meta-command)

CODE

#Title Configure Enemy

#Name HP
#Range min:1
#Description The enemy's HP.
int HP;

#Name Speed
#Description The enemy's speed.
#FixedValues
#Value 1 Like red octorok.
#Value 2 Like blue octorok.
#Value 3 Faster than blue octorok.
#Value 4 Like octorok on crack.
int speed;

#Name Rate of fire.
#Description How many times per second the enemy fires its weapon on average.
#Slider min:0.1 max:10.0 step: 0.1
float fireRate;

Which looks and reads similarly, but the plug-in manager can read it too and present a window like this:

CODE

+--------- Configure Enemy ----------+
|                                    |
| HP:           [  1]                |
| Speed:        [1 - Like red .. +]  |
| Rate of fire: |====+--------| 1.0  |
|                                    |
| [OK] [Cancel]                      |
+------------------------------------+

In case it's not clear from the drawing, the first is a text box, the second a dropdown box, the third a slider that shows the current value at the end.

This would allow non-scripters to configure everything in dialog boxes (we can add meta-commands for things like help texts, prevent them from using bad values (like HP = 0) which the dialog box would catch and scripters would only have to learn a very little extra.


This is only a very early and not completely thought-out proposal. But as an indicator of the general direction we could take, it's not too bad.

This would of course take valuable developer time to implement. But, once it's done, scripters (who will be way more plentiful than developers) can not only write and maintain enemy scripts but be involved in the editor's user interface as well, in effect reducing the effort for the developers. Meanwhile, everyone, even those who have never written a line of code and don't want to, can build great quests.

Something similar exists in languages like Java and C# where it's known as "Annotations" (at least for Java). The alternative would be to have two languages, the scripting language for the game proper and a second 'dialog scripting language'. An enemy script could then contain a dialog script that's called when you load it in the editor.

EDIT:
One disadvantage of working hard on a long post is that at least two people will post in while you're writing it.

Nathaniel: In essence you're right, but for two things.
1. I believe the ZC developers decided at one point to complete 2.5, well ... completely, before they thought about any rewrite (or added any more new features), but were well aware the first thing after that is to start again from scratch. I suppose, after all these years of work, to say "here's the final version - it still doesn't work, but that's the best we can do" would not go down brilliantly either. Take into account that a rewrite might well use a completely different quest format anyway (i.e. you can't open 2.5 quests in 3.0) and you then sort of wonder whether to bother with 2.5 at all.
I fully agree about a deadline and that it's taken way too long, but my experience of games is that ones that were rushed-out half finished are the least enjoyable.
2. (and 3.) For an independent rewrite not by the ZC developers, if we do want to really get this off the ground we don't have to wait until 2.5 is out. This thread could be the sign that it's already begun, just still in the planning phase, and coding could start before the summer is over - if we find some developers, that is.

Edited by Koopa, 22 June 2010 - 01:01 PM.

[Nathaniel]

You have a good point there. But as you said: if and only if the developers can be found. That is the ultimate question. If they can't, then all this talk just won't convert to any walk. As for the current developers, you might get mixed reactions to that. Those who wish to continue with 2.5 most certainly can, those who wish to change over to this most certainly can, and those who wish to be involved with both most certainly can too. Ultimately, there will need to be new developers involved in order for both to happen, and this thread has proven that there are people who have expressed interest. They just need a leader and some organization. It always needs a leader.

[Yapollo]

Nathaniel has the priorities right. I may be new here, but I have to agree that it only makes snese that ZC 2.5 needs to be finished first. Plus, the whole aspect of names and ownership need to be considered.

I think there should be a sign-up topic, where the interested provide an e-mail and proof that they can contribute a positive effort to the project. Secondly, after permissions are granted and 2.5's deadline is set, we should organize the volunteers and elect one or more project leaders. Then people can get talking about how to code and name the new project.

Let's not get ahead of ourselves.

[CrystalBlade]

So I haven't been around PureZC much lately but I did notice this thread and I have to say that I like what's going on here. However, I think that it might be a little ambitious, although that doesn't mean it's impossible. Since I've been away from PZC I've learned a thing or two about projects like these so I'd love to be able to help in any way I can.

Even though I haven't been using ZC very much, I've been monitoring the progress of 2.5... it's pretty excruciating. I'm honestly amazed that the developers are still putting so much time into it even though it's been a few years in the making. That's great. Even still, it's obvious that there are some big flaws with the current development. I obviously don't know what goes on behind the scenes but I suspect that the biggest cause of problems is from turning ZC into something that it really wasn't intended to be. I mean, we all know that PM was just trying to recreate Zelda 1 but with the added ability of editing the game. Since then it's become more of a game edior that can recreate Zelda 1 and so much more. And I bet that all of the features that have been added has convoluted the code. Ever since 2.11/2.5, and maybe as early as 2.1, ZC has been trying to be something it wasn't supposed to be.

Just keep that in mind. Before you really start to build this thing, you really need to make sure that you know what you want it to do. The funny thing about ZC in its current state is that it's kind of building games that are this cross between Z1, ALttP, LA and the Oracle series. So really what it seems like we're trying to make is an editor that makes "Zelda-like" games. And I think that would be the best way to "bill" this program, since it wouldn't have to keep a tie to any particular game.

Another point of note; remember when ZC was featured on what used to be TechTV? They liked the program because it was simple. You could download the program and in a matter of minutes you could start building a game; in other words, it had a shallow learning curve. Now you could make the claim that ZC 2.5 is actually quite intimidating, with so many features and scripting. This is something that should be avoided. That doesn't mean that scripting shouldn't be part of the new program, but you should be able to do a lot of stuff without it. There have already been some good ideas in this thread about what to do with that so I'm not going to repeat them.

Finally, I've noticed some confusion about how development would happen if this were to be open-source. The way it would probably work is this: there would still be a core team of developers. However, they wouldn't be the only ones that could write the code; anyone could take part of the code or even write new parts of code and submit them to the core team for addition. The core team would probably add them to some sort of experimental or alpha branch, and from there once you get a pretty good, fairly stable build you can release it as a beta for more testing. Then eventually you get something stable that can be released as the full version. This isn't the only way it has to be but this is how I've generally seen it done. There are a bunch of ways you can streamline this process; programs like git are popular, but places like Launchpad are pretty cool and would provide systems for bug submitting, etc. so it might be worth checking out.

Anyway, this post ended up being really long but I just wanted to say those things. Keep the things that went wrong for ZC in mind and I think you can put out something really solid, if you have the manpower to do it with. Once again I'd love to be able to help in any way I can.

[Lemon]

on all the great sounding plans. It sounds like even more fantastic incentive to get 2.5 polished! (Though it's gotta be close now right? It only crashs like, once every three days for me! )

[Hoten]

This looks like a good step in the right direction, specifically the open source part. The combination of newb friendly GUIs and a powerful scripting core seems very promising. Obviously there remains much to be discussed and planned before a single line of code is typed, so hopefully you guys don't jump the gun in that aspect. I would love to lend a hand, but I am not expierienced in C++, just Java.

[Bourkification]

2. Rename the program. The program is being redesigned from the ground up anyway, something the developers generally agree needs to be done, so it is not as if the program itself is being stolen away from Phantom Menace. But you can't steal the exact name either. Use what you can legally get away with, such as a slight tweak in the name, such as "Pure's Zelda Classic" (if there is a move to PureZC) or "Zelda Classic Deluxe", with the words Zelda and Classic being most emphasized when presented. It is essentially a brand new program, rather than simply a newer version of an old one. Despite the rename, continue to give credit to Phantom Menace for the original idea of the program, thus as to what the new one is based on, out of the respect that he clearly deserves.

3. Leave Armageddon Games. Go with a different gaming label. To avoid trouble with Nintendo, the new gaming label should be nonprofit. Any surplus revenue, if it exists, would be strictly for the funding of the program and the upkeep of the gaming label's official web site. As for the current label, Armageddon Games is a very poorly managed gaming company (if you claim it to be managed at all, beyond the bare necessities), mainly due to loss of interest among those who are responsible for running it. The AGN website is a shipwreck, due to frequent attacks and gross neglect. The developers must have a new home and official site for the program, where they can continue to do what they do best with minimal disruptions and strong administrative support. It can either move to the currently most active ZC site, PureZC, to another ZC site that already exists, such as ZCRealm, or to a brand new site. Either of those solutions would be significantly better than the current situation, despite the work involved in such a move. Wherever it goes, all development would happen there. The front page of the new site would have to act as an official and permanent replacement for the currently broken one, zeldaclassic.com, which is probably now under lists for sites to continuously attack. With a program name change, there would no longer be a need to continue using the old domain.

I was going to suggest renaming the program 'Pure', but it seems that the url 'www.pure.com' is taken by a radio manufacturer.

[Christian]

Meh. All this talk and promises. I'll believe it when i see it.

[Bourkification]

There are no promises being made. This is just gathering ideas for this programs future. There is no point jumping straight into it and starting it without a plan or prior discussions on it. If we do that then the program will just end up like ZC is now, buggy and unstable. We need to learn from the past mistakes. If you want immediate action, then take action yourself. That achieves more than criticising those who try. The future of Zelda Classic should not be dependant on five or six individuals that take interest in it. It should be dependant the entire community banding together, generating ideas, planning and coming up with solutions.

[Gleeok]

Meh. All this talk and promises. I'll believe it when i see it.

Eh, I haven't heard anyone promise anything, just a lot of talking. It's good to get some feedback from these discussions, good or bad, especially considering the frequency of topics about 2.5, 3.0, re-writing, when's it gonna be done, etc. have been popping up lately. The only thing resembling a promise I made is that I'd volunteer to be the OpenGL guy since I have experience with that and it would give me some motivation to finish the rendering library I started way back so I could perhaps put it up on sourceforge or make a game with it ..or something, I don't remember promising though. ..ho-hum.


Personally, I'd like to see it with 32-bit color and a proper alpha channel myself. The ability to almost instantly rip entire sprite-sheets from a snes or playstation game alike without having to spend hours recoloring or dicking around with a palette would just be too cool for school. I sort of feel sorry for you guys that have only worked with 8-bit graphics. Eye candy is so easy.

Also yes. Need moar peeples.