User Tag List

Page 4 of 7 FirstFirst ... 2 3 4 5 6 ... LastLast
Results 31 to 40 of 67

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

  1. #31
    Administrator DarkDragon's Avatar
    Join Date
    Oct 2001
    Posts
    6,228
    Mentioned
    70 Post(s)
    Tagged
    0 Thread(s)
    vBActivity - Stats
    Points
    11,025
    Level
    31
    vBActivity - Bars
    Lv. Percent
    8.16%
    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.
    I'm not aware of Solarus, though I played Megazeux back in the day, which also was a fully-scripted engine on top of which all of the game elements were built. It's a very tempting model, especially to us computer scientists who will abstract anything given the slightest temptation.

    However! I will warn you that I traveled quite a distance down this path 5-6 years ago when we were first pondering the idea of a full remake, and an "everything-scripted" Zelda remake would require a **lot** of thought and pre-planning to have any hope of success. Just think of what a Link script would have to look like, so that he correctly transitions between all of his possible states in LoZ -- walking, attacking, hurt, dying, rafting, on a ladder, warping, etc etc etc) -- and responds correctly to user input and world interaction in all states. I don't know how Solarus is built to manage the complexity, but I'd imagine a sophisticated message-passage system (perhaps along the lines of, but far more elaborate than, MZX's system) of some sort would be needed.

  2. #32
    The Timelord
    QDB Manager
    ZC Developer

    Join Date
    Oct 2006
    Location
    Prydon Academy
    Posts
    1,396
    Mentioned
    112 Post(s)
    Tagged
    1 Thread(s)
    vBActivity - Stats
    Points
    4,760
    Level
    21
    vBActivity - Bars
    Lv. Percent
    68.7%
    Quote Originally Posted by DarkDragon View Post
    I'm not aware of Solarus, though I played Megazeux back in the day, which also was a fully-scripted engine on top of which all of the game elements were built. It's a very tempting model, especially to us computer scientists who will abstract anything given the slightest temptation.

    However! I will warn you that I traveled quite a distance down this path 5-6 years ago when we were first pondering the idea of a full remake, and an "everything-scripted" Zelda remake would require a **lot** of thought and pre-planning to have any hope of success. Just think of what a Link script would have to look like, so that he correctly transitions between all of his possible states in LoZ -- walking, attacking, hurt, dying, rafting, on a ladder, warping, etc etc etc) -- and responds correctly to user input and world interaction in all states. I don't know how Solarus is built to manage the complexity, but I'd imagine a sophisticated message-passage system (perhaps along the lines of, but far more elaborate than, MZX's system) of some sort would be needed.
    You should certainly have a look: http://www.solarus-games.org -- The default quest is rather impressive, and the quests made to date are shaping up nicely. it uses Lua, and TBH, my main complaint is that you need to manually configure absolutely everything with Lua scripts, at present. The map design tools are outstanding though, and it runs in the Z3 style.

    It's also open source, and @Christopho has no qualms discussing it in depth, should you want to inquire.

  3. #33
    The Timelord
    QDB Manager
    ZC Developer

    Join Date
    Oct 2006
    Location
    Prydon Academy
    Posts
    1,396
    Mentioned
    112 Post(s)
    Tagged
    1 Thread(s)
    vBActivity - Stats
    Points
    4,760
    Level
    21
    vBActivity - Bars
    Lv. Percent
    68.7%
    Quote Originally Posted by Moosh View Post
    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.
    Unfortunately, only time will tell. AFAIK, the present plan doesn't call for ZScript deprecation for a jolly long time. I'm mostly uncertain if it's even plausible to do such a major rewrite, and not break the universe in the process. We have so many compatibility rules as things stand, that implementing all of them in a rewrite is simply...madness.

    The hope is that when ZC3 is a thing, and a new language is implemented, quests with ZASM tables will still work, most of the time.

    It won't be the 'next version' though. Somewhere down the line, certainly, but not next. That, and I may be mad enough to continue supporting 2.xx stuff after it is officially deprecated. We'll see in a few years how much steam I've left.

  4. #34
    Is this the end?
    ZC Developer
    Saffith's Avatar
    Join Date
    Jan 2001
    Age
    41
    Posts
    3,389
    Mentioned
    178 Post(s)
    Tagged
    6 Thread(s)
    vBActivity - Stats
    Points
    6,430
    Level
    24
    vBActivity - Bars
    Lv. Percent
    69.57%
    Quote Originally Posted by DarkDragon View Post
    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.

    Quote Originally Posted by ZoriaRPG View Post
    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.

    Quote Originally Posted by Moosh View Post
    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.

  5. #35
    Administrator DarkDragon's Avatar
    Join Date
    Oct 2001
    Posts
    6,228
    Mentioned
    70 Post(s)
    Tagged
    0 Thread(s)
    vBActivity - Stats
    Points
    11,025
    Level
    31
    vBActivity - Bars
    Lv. Percent
    8.16%
    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).

  6. #36
    The Timelord
    QDB Manager
    ZC Developer

    Join Date
    Oct 2006
    Location
    Prydon Academy
    Posts
    1,396
    Mentioned
    112 Post(s)
    Tagged
    1 Thread(s)
    vBActivity - Stats
    Points
    4,760
    Level
    21
    vBActivity - Bars
    Lv. Percent
    68.7%
    Quote Originally Posted by Saffith View Post
    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.

  7. #37
    Is this the end?
    ZC Developer
    Saffith's Avatar
    Join Date
    Jan 2001
    Age
    41
    Posts
    3,389
    Mentioned
    178 Post(s)
    Tagged
    6 Thread(s)
    vBActivity - Stats
    Points
    6,430
    Level
    24
    vBActivity - Bars
    Lv. Percent
    69.57%
    Quote Originally Posted by ZoriaRPG View Post
    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.

  8. #38
    The Time-Loop Continues ZC Developer
    Gleeok's Avatar
    Join Date
    Apr 2007
    Posts
    4,815
    Mentioned
    259 Post(s)
    Tagged
    10 Thread(s)
    vBActivity - Stats
    Points
    12,933
    Level
    33
    vBActivity - Bars
    Lv. Percent
    23.44%
    Quote Originally Posted by DarkDragon View Post
    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).
    I just wanted to point out that this is exactly what has happened since you left. The simple fact that you don't see any users saying things like "Works only with XXX version of ZC" anymore I think proves this. :) In fact, I've been sorta semi-retired from general bug-fixing for some time due to the fact that it has remained stable. :)

    The worst bugs currently (I believe) are from Windows 10 DirectX layer, Windows 10 drivers, and/or general Windows shenanigans. For example; someone said that ZC mega-lags unless they are playing a youtube video in the background. Stuff like this.
    This post contains the official Gleeok seal of approval. Look for these and other posts in an area near you.

  9. #39
    Administrator DarkDragon's Avatar
    Join Date
    Oct 2001
    Posts
    6,228
    Mentioned
    70 Post(s)
    Tagged
    0 Thread(s)
    vBActivity - Stats
    Points
    11,025
    Level
    31
    vBActivity - Bars
    Lv. Percent
    8.16%
    Excellent!! Historically this wasn't always the case, and I'm sure the quest authors greatly appreciate it.

  10. #40
    The Timelord
    QDB Manager
    ZC Developer

    Join Date
    Oct 2006
    Location
    Prydon Academy
    Posts
    1,396
    Mentioned
    112 Post(s)
    Tagged
    1 Thread(s)
    vBActivity - Stats
    Points
    4,760
    Level
    21
    vBActivity - Bars
    Lv. Percent
    68.7%
    Quote Originally Posted by Gleeok View Post
    I just wanted to point out that this is exactly what has happened since you left. The simple fact that you don't see any users saying things like "Works only with XXX version of ZC" anymore I think proves this. :) In fact, I've been sorta semi-retired from general bug-fixing for some time due to the fact that it has remained stable. :)

    The worst bugs currently (I believe) are from Windows 10 DirectX layer, Windows 10 drivers, and/or general Windows shenanigans. For example; someone said that ZC mega-lags unless they are playing a youtube video in the background. Stuff like this.
    (Emphasis, mine.)

    Bah? I have win10 installed, and I've tested ZC and ZQuest, encountering no such issues. It must be either a video driver conflict, or some kind of malware in that case?!.

    Neither ZC, nor ZQuest seem to run differently on Win10, than they did on Win7, on this hardware.

    Quote Originally Posted by Saffith View Post
    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.


    I don't know what any part of that means.
    I think you had implied in the past that something I had done didn't have proper abstraction? I just want to make certain that setter/getter functions that return something like bool throttleFPS aren't a problem.

    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.
    Oh, I have. I can't even get people to sign in here, that have accounts to make flipping bug reports. They send them to me, over Skype, and ask me to file them.

    This is precisely why I've been pushing for bug and dev forums on Pure, as pretty much everyone who could be discussing these things, getting involved, and reporting issues is over there. ---->

    I don't actually enjoy relaying everyone else's concerns, you know; nor being left to defend their interests solely. They should just stop being lazy, and sign up, or sign in here, but you know, that isn't going to happen. I'm sort of tired of being the gopher for every complaint, problem, and general issue, too. For my own purposes, I an always crank out a version of ZC that does what I need it to do, and not worry about it.

    Frankly, assuring people that everything they made isn't going to abruptly break in the very next ZC version shouldn't be my full-time job.

    Quote Originally Posted by DarkDragon View Post
    Excellent!! Historically this wasn't always the case, and I'm sure the quest authors greatly appreciate it.
    2.50 stability is assuredly, highly praised, and regarded. I remember the fun of 2.10 crashing randomly, if I wanted to view the space-bar-map, or 2.5 betas eating save files. things like that are why I abandoned ZC for a few years, particularly when it seemed as if future dev (then) was going no-where.

    Incidentally, this is why I fear things being stagnant, now; as I know people tend to leave when they feel as if nothing new is forthcoming. I certainly did, in 2006/7.

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
About us
Armageddon Games is a game development group founded in 1997. We are extremely passionate about our work and our inspirations are mostly drawn from games of the 8-bit and 16-bit era.
Social