ZC [2.future] Development Plans [To-Do]

[Mitsukara]

If it's possible to add Angelsript at whatever pace you want, without dropping support for ZScript, I think that would be fine. But if you drop support for zscript, even if you replace it with a similar language, you are still disenfranchising some of the most active creators. (I wouldn't count myself as such a person, as I'm in the 'disappeared in the 2.10 days and only recently resurfaced' category, but, for my own position in the matter: I've pretty much completed my first full quest, by heavily relying on ZScript. I would not be eager to learn a different language right away; if I'm going to do that kind of thing, I would go off and learn something I can make programs in myself. But I am already working on ideas for a sequel... that rely on my knowledge of zscript to actually function.) Part of what might also happen if ZScript is dropped too hastily, is that many people will simply use 2.5.2 instead of the new version, which undermines the points of your hard work.

So basically, I'd totally be in favor of adding a new language, and even okay with you developing that language while not really expanding ZScript- as long as compatability for ZScript isn't dropped. I think that would be a terrible mistake. Just look at how many of the most popular quests rely on ZScript, you know?

As far as ideas for new features... I'm pretty sure it's already been discussed here, but I still think that splitting up the NPC Script weapon defenses into 10 parts (a separate defense setting for each of the ten LW_SCRIPTs) would be an excellent addition to the enemy editor, because it would make the separate script weapon types more useful, and much more likely to be used. Needing to script a workaround to constantly change NPCD_SCRIPT is silly, and many users don't even bother, or, as I did, encounter bugs in the course of trying to set it up properly. I also think that added the ten EW_SCRIPT weapon types to the default weapons you can set an enemy to have would be a good idea, because this enables users to easily put together enemies in the editor- without ghost- that use new weapon types that they can script global effects for. Lastly, I think one other enhancement the enemy editor could use, that would improve casual usage, is better built-in adjustments for enemy sizes- basically just a means to type in their tile width, tile height, hit width, hit height, draw X offset, and draw Y offset; those are admittedly pretty easy to set with scripts, but I think you'd get non-scripter users potentially making more interesting bosses this way. I don't know if any of these suggestions are really necessary, but they'd be extremely convenient, and reduce the barriers of confusion for those learning the program.

Regarding setting up a dev forum on PureZC... I'm not a terribly active forumgoer myself at either place, but I do think that would greatly expand your user feedback, since this place is definitely sort of a ghost town by comparison (I must admit I only saw this thread because someone else pointed me at it). Another very big problem is Zeldaclassic.com not keeping up with new version releases- this really undermines the point of having that site, doesn't it? I think updating Zeldaclassic.com would be a very good idea for getting more users to notice new versions.... I was using 2.5.1 until August because I had no idea 2.5.2 existed, because it was only posted on the PureZC forums, in a place I missed. Especially since PureZC's own download link also leads to Zeldaclassic.com, instead of the up to date forum posting. So there's sort of some executive/presentation confusion about the whole project....

In any case, I also want to say that 2.50 was an excellent improvement over 2.10. The ability to script new items and enemies is singlehandedly what made me interested again- finally I can have my Cane of Somaria and so many other neat things I wished for as a teenager. Thank you very much for making ZScript in the first place. Also... 2.50 in general, especially 2.5.2, are far, far less buggy and vastly more stable than the old 2.10 or various 1.92 versions. I've experienced almost no crashes myself, on Windows 7, except for when I did silly things like misusing a while loop when I was learning to script.

I look forward to seeing new developments for ZC, and thank you all for your hard work : )

[Saffith]

To be clear here, the goal is to drop support for compiling ZScript; existing quests would continue to work. If backward compatibility weren't a priority, this would all be much easier.

There really isn't a good way to support both languages at once without undermining each of them. Enemies, weapons, and especially Link are all a complete mess, but we can't make any major changes to them without potentially breaking quests that depend on their weird behavior. Replacing them with scripted versions would fix that; their behavior would be part of the quests and unaffected by future updates. Continuing to support ZScript, whether or not the objects themselves were written in ZScript, would mean either keeping a lot of the weirdness we want to get away from or completely overhauling the language (which would be about as big a change as switching).

[DarkDragon]

The ZScript discussion reminds of Houdini, a Blender-like 3D modeling tool that is commonly used in the special effects industry. For many years Houdini was highly scriptable using a DSL called "hscript" with its own syntax and parser, etc. This worked well for a while, but was a barrier to entry for new users and also somewhat of a pain to use since hscript lacked many of the advanced features and conveniences of mainstream scripting languages. At some point SideFX, the company behind Houdini, decided to switch from Hscript to Python. Houdini still supports hscript, but outside of legacy files and assets nobody really uses it anymore.

I imagine the most painless way to move away from ZScript to something like AngelScript would be to use a similar strategy. For a while, both ZScript and AngelScript are fully supported. Fully-scripted items and enemies are slowly introduced that coexist side-by-side with the old hard-coded ones, but new quests created in ZQ use the new enemies by default, and these new features only work with AngelScript. Old quests still play, but authors using ZQuest are increasingly incentivized to switch to the new system.

Another major issue that I see as crucial, is that most users are on Pure, and all of these discussions occur on AGN. While it would be fantastic if they all joined here, realistically that just won't happen. I've tried to motivate people to sign up and participate here, and the common response is 'Why not just make a Dev forum on Pure for us?'.

I'll reiterate that, as it's important: We can't really get user input when we discuss this here, and the userbase is elsewhere. We need a Dev board on Pure.

From what I understand, the Pure staff are reluctant to add one, because AGN staff didn't want it in the past, but now that it's open sourced, we need to remove those objections, and allow a Dev board, with a bug reports board, there. Most of the bugs that we miss are ignored because users don't report them, and they don't report them because they can't do it on PZC.

I guess that's something to discuss with the folks at Pure. I don't know anything about this and don't particularly care to wade in, though I have to say I'm surprised to see that the drama and bickering between the sites continues in 2016 when it seems both sites struggle to get more than a dozen posts per day.

Presumably y'all have set up a core group of developers charged with curating the official repository and binaries. Hopefully you're on the same page about both the short and long-term development goals of the project, and have some centralized place to discuss this. But communication with the community can happen anywhere and in multiple places simultaneously. How to best handle users submitting feature request, pull requests, bug reports etc. is for you (the ZC developers) to decide. Both sites should be making facilitation of ZC development their unequivocal top priority. On the AGN side I can try to help relay any requests or concerns to War Lord (though I know I'm not necessarily much easier to get a hold of than War Lord himself... ) and my understanding is that Gleeok and Saffith have pull at PureZC.

I would like to ask, while you are here, if it would be possible to move, or mirror the Wiki from Shardstorm to AGN, or to a server with a faster data path. I've had many user complaints that it takes forever to load, and this also makes editing it quite a tedious task. I'd also like to update the Wiki software at some point, to add in modern Wiki markup, as it's running a version that doesn't even properly support referencing. ...but all that is best discussed on its own.

Agreed; War Lord and I are already coordinating on doing this.

In essence, while all of these other languages are fantastic on the surface, they don't have much appeal to the people actually using the programme. It is far better to plan out a slow migration, and allow users to gradually adapt to the changes. That's my tuppence worth.

From what I'm seeing in this thread, it seems everybody is on board with gradual change.

[DarkDragon]

Another very big problem is Zeldaclassic.com not keeping up with new version releases- this really undermines the point of having that site, doesn't it? I think updating Zeldaclassic.com would be a very good idea for getting more users to notice new versions.... I was using 2.5.1 until August because I had no idea 2.5.2 existed, because it was only posted on the PureZC forums, in a place I missed. Especially since PureZC's own download link also leads to Zeldaclassic.com, instead of the up to date forum posting. So there's sort of some executive/presentation confusion about the whole project....

Yes, this is a perennial problem. The current ZC lead developer should have access to zeldaclassic.com, but should not be expected to have the time or skills to keep the site maintained. The site needs a webmaster who is competent and active, which is a lot to ask. War Lord is currently working on fixing the site in the short term, so if you know somebody who might fit the bill in the long term, please do encourage them to contact War Lord.

[Gleeok]

There were no plans to remove ZScript immediately from ZC. This is also a practical approach; there's simply too much work to be done first. If the day comes when we have the luxury to either deprecate or rip out ZScript entirely, then it's not going to be a breaking news story by any stretch. The amount of work it would take to get ZScript to the level of angelscript feature-wise is simply ginormous (It [angelscript] has been in development for 10+ years after all). This includes both the end-user scripts and the ease-of-use of working with scripting from within the codebase itself. That said, I personally don't have problem with leaving ZScript intact until the last, if for no other reason than removing it would be at the bottom of my list of fun things to do to spend my time.

[Mitsukara]

To be clear here, the goal is to drop support for compiling ZScript; existing quests would continue to work.

Ooh- in that case, it occurs to me that even if you had people who wanted to continue developing in ZScript after new versions dropped compiling support for it, then you could simply build your quest in an old version and then port it into the new one for release. If that'd even be something people would want to do given the timescales it sounds like you're thinking of for this change. So that does kind of keep options open; rather than making ZScript unusable/obsolete, it would merely gradually reduce the convenience and practicality of using ZScript, so that sounds okay.

(More comedically, I'm picturing someone trying to make some sort of 2.5.2 virtual machine in Angelscript, though... XD )

How to run Zeldaclassic.com is pretty much your guys' call, but.... what might be more reliable, is instead of having a single webmaster that can edit the site, if you instead had a handful of key staff members all have access- such as Saffith, who posted 2.5.2- so that once a new version is done, then they don't have to get in touch with somebody less active to update it. A very small group of the most trusted developers all having Zeldaclassic.com update privileges, sort of like a shared dropbox kinda deal, basically.

the amount of work it would take to get ZScript to the level of angelscript feature-wise is simply ginormous (It [angelscript] has been in development for 10+ years after all).

Oh? That sounds really cool. ZScript is already pretty amazing (for a few examples, I know someone was having some progress making an adaptation of Ys with free-range scrolling and a custom hitbox system; and there's been a lot of amazing items and custom bosses, and special puzzles, and all that good stuff. Being able to move X and Y, do drawing commands- including scaling, rotating, and some limited 3D textured shapes - and turn collision detection for just about anything on/off, goes a very long way), so if Angelscript can do all that kinda stuff and more, that should definitely be intriguing.

I don't suppose Angelscript can mess with screen scrolling behavior and built in Active Subscreens, can it?

[Saffith]

Theoretically, it can do pretty much anything; it's just a matter of making the functions available to it. For scrolling and subscreen stuff, it's more a question of putting those features into the engine. I expect both will happen, but nothing's definite right now.

I'm not really sure what a gradual change would mean. We need to replace the whole sprite class, and continuing to support ZScript after that means making a separate version of the script engine to work with the new classes. Changing the combo system would mean all the scripts using Screen->Combo* or Game->Get/SetCombo* break. Same deal for flags. The whole itemdata type depends on the current weapon implementation. There are all sorts of weird little things; weapon->DeadState, screen flags, the behavior of directions outside the range of 0-7... How far do we go to keep existing scripts working? And if we're okay with breaking scripts, why go to any trouble at all when only the most trivial will keep working?

Maybe it will become clear in time. It's not like this is something that's going to happen overnight.

[DarkDragon]

Theoretically, it can do pretty much anything; it's just a matter of making the functions available to it. For scrolling and subscreen stuff, it's more a question of putting those features into the engine. I expect both will happen, but nothing's definite right now.

I'm not really sure what a gradual change would mean. We need to replace the whole sprite class, and continuing to support ZScript after that means making a separate version of the script engine to work with the new classes. Changing the combo system would mean all the scripts using Screen->Combo* or Game->Get/SetCombo* break. Same deal for flags. The whole itemdata type depends on the current weapon implementation. There are all sorts of weird little things; weapon->DeadState, screen flags, the behavior of directions outside the range of 0-7... How far do we go to keep existing scripts working? And if we're okay with breaking scripts, why go to any trouble at all when only the most trivial will keep working?

Maybe it will become clear in time. It's not like this is something that's going to happen overnight.

Well, those are good questions, but let's look at the case of combos specifically. In my mind the "right" way to implement combos would be to have them all be scripted, with users selecting from a palette of pre-written combo scripts, rather than a palette of hard-coded combos (which is what we have now). How might this be implemented? The first step would be to introduce a "scripted combo" combo that uses AngelScript scripts that do not interact in any way with ZScript. New users who pick up ZQuest make their quests entirely out of these "scripted combos" and are none the wiser that anything else ever existed before, but the hard-coded combos are still supported (for backwards compatibility with old quests). ZScript can try to use Screen->Combo* but these function do not do anything interesting for the new "scripted combos" (I suppose ComboD returns a generic ID indicating that the combo is a scripted combo).

Similarly hard-coded enemies can be replaced with scripted enemies, same thing with items, etc.

[ZoriaRPG]

Well, those are good questions, but let's look at the case of combos specifically. In my mind the "right" way to implement combos would be to have them all be scripted, with users selecting from a palette of pre-written combo scripts, rather than a palette of hard-coded combos (which is what we have now). How might this be implemented? The first step would be to introduce a "scripted combo" combo that uses AngelScript scripts that do not interact in any way with ZScript. New users who pick up ZQuest make their quests entirely out of these "scripted combos" and are none the wiser that anything else ever existed before, but the hard-coded combos are still supported (for backwards compatibility with old quests). ZScript can try to use Screen->Combo* but these function do not do anything interesting for the new "scripted combos" (I suppose ComboD returns a generic ID indicating that the combo is a scripted combo).

Similarly hard-coded enemies can be replaced with scripted enemies, same thing with items, etc.

Honestly, if people want to do a rewrite as ZC v3.x, backward compatibility is going to take a hit one way or another. I was originally in favour of continuing 2.xx development, and allowing a rewrite (3.0) to be clean, possibly working on platform stability in future 2.x updates, and working out some way to make a 2.x quest 'player' in the 3.0 engine, that handles all these quirks directly through new, clean code.

The alternative is a big case statement that reads the quest header, and does A if it's 3.x, or B if it's 2.x, for just about everything.

There's no reason that 2.x has to die for this to work, and there's no reason to abandon the community using 2.x to allow a rewrite. I don't really think tha tthe userbase has ever really been consulted on any of this, and insofar as deprecating ZScript, the community opinion has been unfavourable to this outcome.

An important factor, is that ZC is no longer the only game in town. I'm unsure if @DarkDragon has looked at the Solarus engine. IMO, that is the right direction for ZC3. Every object in Solarus is scripted... If you went that route, and you had easy to use attribute editors so that scripting is not a mandatory requirement to use the flipping thing (note that Solarus does not yet do that, but it's on @Christopho ' s plan), you would have something that can hold up to the test of time.

You could even allow stock Z1 style questmaking, by setting the bitmap scrolling areas to one-screen regions, and adding a scripted subscreen bar. ...but the reality is, that ZC3 should be something that keeps up with the other gamemaking engines, instead of the arcane and antiquated methodologies that it employs at present, and in so doing that, you pretty much relegate old quest compatibility to a side-programme. Other utilities do this. Hell, Apple did it when they came out with OSX, running older programmes in a VM that sort of invisibly ran in the background.

That might be the thing to do, for 2.5 compatibility in the future: Some kind of invisible background process that runs the quest on top of the new engine.

All this not withstanding, in my ehttp://armageddongames.net/showthread.php?97486-ZC-2-future-Development-Plans-To-Do&p=912319#post912319w3stimate, we're five to six years away from such a thing being viable. In the interim, I choose to work with 2.50, adding things that people want, fixing what can be fixed, and trying to smooth out some ruffles. I have yet to see any kind of plan for a rewrite, or ZC3, that I feel is viable; nor have I seen the kind of staffing or dedication it would take to accomplish it. We realistically would need ten or more core developers, and a suite of contributors, or it'll take 12 years, like Solarus, or pretty much 2.5.

We do however, have people willing to work on 2.55, and 2.60. It's possible to keep this thing alive using these resources, while we develop a plan for the future. If you actually need a list of references on why not routinely updating something kills it, I can provide that: History is a good teacher here. Without working on 2.55 and 2.6 as continuations of 2.50--even if that means biting it, and continuing to work on a dinosaur API with a zany assembler that has its own C-type interpreter,--ZC is pretty much a dead duck, as the present userbase will die out, and no new userbase will exist to supplant it.

You also have to take the contributors, and new developers that you can gain, and avoid thwarting ever ambition that they may have, isolating them, and turning them away in the process. I know that @Tamamo pretty much abandoned ZC Dev because everything she wanted to do was rejected; and while I was not in favour of some of it, the same thing is happening with the three of us that are willing to work on this beastie.

[Moosh]

To be clear here, the goal is to drop support for compiling ZScript; existing quests would continue to work. If backward compatibility weren't a priority, this would all be much easier.

There really isn't a good way to support both languages at once without undermining each of them. Enemies, weapons, and especially Link are all a complete mess, but we can't make any major changes to them without potentially breaking quests that depend on their weird behavior. Replacing them with scripted versions would fix that; their behavior would be part of the quests and unaffected by future updates. Continuing to support ZScript, whether or not the objects themselves were written in ZScript, would mean either keeping a lot of the weirdness we want to get away from or completely overhauling the language (which would be about as big a change as switching).

So when updating a quest from 2.5 to whatever version adds AngelScript, would there be a way to remove certain ZScript scripts that are broken? Or are they so incompatible that all scripts would be removed from the file? I'm fine with ZScript support being dropped, but I'm wondering how hard it will be (if it's even possible) to update a 2.5 quest over to the next version.