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

[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.

[Tamamo]

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.

[ZoriaRPG]

Oh, right. I was being somewhat polite, there: 'everything she wanted to do was rejected'.

i.e., You wanted to do things, and we all went into bicker mode, every time.

[Saffith]

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

I'm just not sure that's feasible for everything. For sprite types, for instance, if we want to replace the fixed-point coordinates with floating-point, the current script engine won't work with that at all.
I don't know. It probably doesn't make sense to worry about it too much at this point, anyway.

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 disagree with any of that. I would like there to be a 2.60 (or 2.55, or whatever), and I'd like to start the branch as soon as 2.50.3 is complete. I'm already leaning toward abandoning the current rewriting effort and doing it more gradually, starting there. But the current codebase is so messy and so fragile that we're greatly limited in what we can actually do in the way of incremental upgrades without breaking a lot of existing quests, and what I absolutely do not want to do is make it worse by adding unmaintainable features and exposing more internal behavior.

and insofar as deprecating ZScript, the community opinion has been unfavourable to this outcome.

Who? Where? You keep saying that, but I haven't seen any evidence of it. There've been some questions and some uncertainty, but I haven't seen any real opposition to it from anyone except you.

We do however, have people willing to work on 2.55, and 2.60.

That's great, but we need more than willingness. Several people were willing to work on 2.50, and now it's an unmaintainable mess of spaghetti code.

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.

We just can't say at this point. I think updating a quest would mean removing all ZScripts and updating enemies, items, etc. to the new versions, but maybe not.

[ZoriaRPG]

I'm just not sure that's feasible for everything. For sprite types, for instance, if we want to replace the fixed-point coordinates with floating-point, the current script engine won't work with that at all.
I don't know. It probably doesn't make sense to worry about it too much at this point, anyway.

I certainly wouldn't. I'm not even sure what benefot thee would be to that conversion, to be frank. Changing from the present fixed format would sure break everything though, which is why I haven't been in favour of suggestions to do anything of the sort. I had an idea for allowing fixeds in the script lanuage, but I pretty much abandoned that after i determined just how obscene it would be to implement, versus its usefulness.

I did have ideas for how to convert the hardcoded enemies, to scripted enemies, with reasonable transparency, but no-one seemed keen to hear them out in full.

I don't disagree with any of that. I would like there to be a 2.60 (or 2.55, or whatever), and I'd like to start the branch as soon as 2.50.3 is complete. I'm already leaning toward abandoning the current rewriting effort and doing it more gradually, starting there. But the current codebase is so messy and so fragile that we're greatly limited in what we can actually do in the way of incremental upgrades without breaking a lot of existing quests, and what I absolutely do not want to do is make it worse by adding unmaintainable features and exposing more internal behavior.

Which of my routines haven't included at least some layer of abstraction, in your eyes? The return functions? That's the sort of thin that can be updated at a function level, at any time, and they work in precisely the same manner as every other return function.

Who? Where? You keep saying that, but I haven't seen any evidence of it. There've been some questions and some uncertainty, but I haven't seen any real opposition to it from anyone except you.

Well, of course not. It hasn't been discussed on a public forum, where we have most of the userbase... :p

It comes up in chat, every single time this topic is broached.

That's great, but we need more than willingness. Several people were willing to work on 2.50, and now it's an unmaintainable mess of spaghetti code.

That's valid, certainly. I fret that any attempt to clean it up is likely to (initially) do more harm, than good, as well...but there are really three options, as I see things:

1. People work together on the individual, incremental updates; you take what you can get.
2. You end up with a core version, several forks, and community splintering that the present minimal userbase cannot maintain.
3. You have a stalled project, that goes nowhere for years.

We seem mostly to be in mode 3, from that list.

[Saffith]

I did have ideas for how to convert the hardcoded enemies, to scripted enemies, with reasonable transparency, but no-one seemed keen to hear them out in full.

First I've heard of it. I was doing that, and it seemed to be working fine, but then we stopped doing that. Maybe for a reason, but I don't even know anymore.

Which of my routines haven't included at least some layer of abstraction, in your eyes? The return functions? That's the sort of thin that can be updated at a function level, at any time, and they work in precisely the same manner as every other return function.

I don't know what any part of that means.

Well, of course not. It hasn't been discussed on a public forum, where we have most of the userbase... :p

Well, tell them to come to the forums. I'm not accepting secondhand complaints. I really don't like you being the representative of some horde of anonymous users.

[DarkDragon]

That's great, but we need more than willingness. Several people were willing to work on 2.50, and now it's an unmaintainable mess of spaghetti code.

In particular, are there developers that are willing to focus on fixing bugs, and refactoring code, rather than cram in more new features?

Debugging and maintenance is extremely unglamorous work, but is what ZC needs right now (and has needed since 2.12, to be honest).