PDA

View Full Version : A way to eliminate feature bloat and new bugs, using ZScript?



Dart Zaidyer
12-18-2006, 05:34 PM
Lately there's a lot of back-and-forth talk of "we don't need new features, only a stable release" and "yes we do need features, but they will have to be debugged". Either way, bugs are still popping up as the devs continue to tweak the ZC engine.

So, I was thinking. Maybe this is a long-shot, but wouldn't a nifty solution to the "feature bloat" issue just be to include some of them as a standard package of ZScripts that comes with ZQuest?

That way, the only real features the programmers would need to hard-code into the engine are ones that add more power to the scripting such as better command/control (Also, direct usage of tiles directly from the quest's graphics as an option, instead of creating a jillion combos) and a way to attach ZScripts to something that Link can hold in his inventory. This would be a perfect solution to "new" weapons and abilities and interface features; quest authors who know nothing about scripting would only need minimal effort to assign a script, adjust it to their tastes, and then be happy that it just works. How'd you like an Ice Rod that freezes monsters and interacts with existing combo types in a certain way? Maybe Link could be carrying an invisible item that allows him to press "A" to pick things up or talk to people? We've already seen the Roc's Feather and Sidescroller gravity as scripts before they were hard-coded features. Don't tell me it's not a viable option.

This could even cut down on bugs that would otherwise be introduced into the engine by hard-coding such things.

Moresco
12-18-2006, 05:59 PM
I like the idea, personally. I'm not a developer though, I can't say how difficult a task that is. I believe AGS works that way, but I can't be 100% positive.

splattergnome
12-18-2006, 06:32 PM
While I am generally for the idea (since it offers people flexibility in altering the "standard package"), I can see at least one major mark against the plan: speed. ZASM takes time to run, and since many ZScripts are called several times a second, they do slow down the program a bit, since ZScript has to be interpreted. Now while this is not making a major dent yet, imagine how it will be down the road when there will be a hundred different counters and checks running at the same time, and the like.

ShadowTiger
12-18-2006, 07:29 PM
I have a pentium II 300 MHZ machine with 256 MB Ram and a vicious overbite. If ZC begins to lag untolerably for me because of this thread, I'm going to haunt you when I die. :p

The_Amaster
12-18-2006, 07:49 PM
Ditto for me and my 6 year old GX100 with barely enough ram to run an electric toaster. Already some of the FFC rooms cause quests to lag.

*b*
12-18-2006, 10:14 PM
You should also take into account that some people know shit about scripting, especially anything like adding different effects for weapons or making Link jump properly. It's a good idea, but it only opens those features up to a portion of the ZC community, while the rest of us are forced to rely on them for features

To be honest, I had a feeling this would come up the very moment ZScripting was announced...

Dart Zaidyer
12-18-2006, 10:34 PM
...Which is why it's important to have a way to define certain important parameters for a script whenever you assign it, without ever having to touch the code. To a quest author, this would seem like a routine job of entering numbers or assigning graphics to use, just like many other portions of ZQuest.


I have a pentium II 300 MHZ machine with 256 MB Ram and a vicious overbite. If ZC begins to lag untolerably for me because of this thread, I'm going to haunt you when I die.
Are you also running Windows 3.1? Because I think it's terribly unsupported these days, much like your hardware. In fact, more programs ought to bend over backwards to avoid breaking compatibility.
Get real please. This is 2006.

Nicholas Steel
12-18-2006, 10:39 PM
...Which is why it's important to have a way to define certain important parameters for a script whenever you assign it, without ever having to touch the code. To a quest author, this would seem like a routine job of entering numbers or assigning graphics to use, just like many other portions of ZQuest.


Are you also running Windows 3.1? Because I think it's terribly unsupported these days, much like your hardware. In fact, more programs ought to NOT bend over backwards to avoid breaking compatibility.
Get real please. This is 2006.

programs should at the moment be designed for a minimum of a p4... and 128mb of ram due to this being whats needed by most new things anyways...

Dart Zaidyer
12-18-2006, 10:51 PM
It's called sarcasm.

Frankly, I'm shocked that since the announcement of open beta testing, the result has been nothing but bitching and moaning about every new and exciting thing that comes along in Zelda Classic. Here I am, offering a solution to appease that sentiment in hopes that it wouldn't curtail progress, but so far I'm not getting any positive feedback, let alone anything constructive.
I'm fully convinced that if the devs actually took your conservative ludditism seriously, ZC would never go anywhere, and kids would still be suggesting that we add the Roc's Feather, NSF support and Spin Attack. Or chests.

Nicholas Steel
12-18-2006, 11:00 PM
i fully agree that they should stop and release a stable version... cutting off any of the extremely buggy things as they'll take to long to debug prior to releasing a stable version and should somehow incorporate a patching scheme into zelda classic where they can just patch the product -.-' as this would annoy less people and would just be more ideal.

Eliwood
12-19-2006, 02:03 AM
While I am generally for the idea (since it offers people flexibility in altering the "standard package"), I can see at least one major mark against the plan: speed. ZASM takes time to run, and since many ZScripts are called several times a second, they do slow down the program a bit, since ZScript has to be interpreted. Now while this is not making a major dent yet, imagine how it will be down the road when there will be a hundred different counters and checks running at the same time, and the like.

Now, I can't say I know what's going on under the hood, but the overhead in interpreting scripts can be offset largely through smart programming by minimizing the heavy calculations in the scripting and pushing that back to the native code.

One advantage to Zelda is the fact that the map sizes are limited, so even if global entity-to-entity collision detection were used as opposed to spatial partitioning (basic technique to only check local collisions), it wouldn't be too bad I'd imagine. How many rooms/maps have 64-128 non-tile sprites on screen at a time?

koopa
12-19-2006, 01:44 PM
Are you also running Windows 3.1? Because I think it's terribly unsupported these days, much like your hardware. In fact, more programs ought to bend over backwards to avoid breaking compatibility.
Get real please. This is 2006.

Considering that ZC is not 3D-opengl-2000x1000screenresolution-verycopmlicatedAI but a relatively "small" program, I think it's only fair if it shouldn't require 2Gig of ram and the latest dual core processor.

I'm against putting all new features into Zscript for three reasons:

1) It should be possible to make quests wthout scripts like you always used to be able to (see the discussion that came up when Zscripting was first introduced), moreover without having to miss half the cool features.

2) Putting the bugs into Zscripts instead of ZC doesn't solve anything. It does extend the audience with access to the scripts and as such you'd make your quest by downloading not just ZC but a myriad of scripted features/items and somehow bungling them together. I think one official ZC with all relevant features built in is much more desirable. Otherwise, we might as well go open-source and let everyone make his/her own ZC. I don't forsee that happening. But: you're all totally free to add any items/features/scripts you do want to (and can code) at any time.

3) The bugs that ZC already has won't vanish by not adding new ones. We'll still have to take care of them in any case. And if we do make existing features like strings scriptable (as is being done right now) then that'll involve a change to the string system (and there's a pretty nasty bug right now).

Questwizard88
12-19-2006, 02:46 PM
I've already noticed things running much slower than before, even in quests that don't make use of FFCs, etc.. I used to run over 1000fps on my old computerwith the throttle off, and beta 15 only gets me 800 average anymore, and 4500+ on the title screen/intro. This is definitely not a good sign at all.

Moresco
12-19-2006, 06:08 PM
I've already noticed things running much slower than before, even in quests that don't make use of FFCs, etc.. I used to run over 1000fps on my old computerwith the throttle off, and beta 15 only gets me 800 average anymore, and 4500+ on the title screen/intro. This is definitely not a good sign at all.

where are you getting your fps numbers from? those seem crazy high for fps...
my game is running at 60/60 almost all the time.

The_Amaster
12-19-2006, 06:17 PM
1) It should be possible to make quests wthout scripts like you always used to be able to (see the discussion that came up when Zscripting was first introduced), moreover without having to miss half the cool features.
Wait...than why are you against new features? More feature mean more things built in, mean less things that need to be scripted, mean less things to lag.

Eliwood
12-19-2006, 09:27 PM
where are you getting your fps numbers from? those seem crazy high for fps...
my game is running at 60/60 almost all the time.

That means that vsync is turned on, which is a good thing because games that run at unnecessarily high framerates (> 1000 FPS) can choke off keyboard input or audio output, depending on the system of course.