A longer suggestion (scripting, GUI, UI)

[splattergnome]

Many new suggestions for using the new features (item editor, new SFX, FFC) have been tossed aside because Zelda Classics scripting capabilities either already can or will soon be able to duplicate the wished effects quite easily. However, this causes a potential problem of a two-class society of Zelda Classic: the people capable of scripting, and those who don`t. My following suggestions aim at trying to reduce the breach:

An important tool in Zelda Classic in the future will be script templates which users will trade amongst themselves. However, many new users may be overwhelmed at opening the script files and editing variable values (even if it is commented well). This is why I have a relatively simple addition which will allow templates to be even easier for new users (and have other side-benefits for script-savvy people):

Scripts should be able to define custom names for each of the variables. Under the pertinent menus in Zelda Classic (for example for items in the item editor, or for FFCs... or whatever new possibilities will arrive) there should be a "details" or an "attributes" tab. In there, all of the inherent variables of the script/combo will be listed, along with the custom names defined in the script. The values can be easily edited in this tab for each.

The benefits:

When using generic templates, other users can easily modify important values from within the editor/FFC attribute screen without having to revert to the scripts. This allows people to fine-tune, and new users to see what they can change or not. Another possibility would be the ability to reuse scripts for multiple combos/items, just changing the important variables.

An example in action: in a future edition of ZC, the standard swords use the "sword" script which define their function. In the script, the d0-d9 variables defining range, damage, amount of hearts neccessary for shooting, and so on are defined. That way, the same script can be reused, and the "attributes/details" tab in the item editor would list the variables along with their names. If a script hasn´t had any of the variables defined/named, it would just have the empty variable name. People wouldn`t have to change the actual script, since they would see (rough example:)

d0 [damage] - 1
d1 [range] - 1
d2 [shoot distance] - 4

And so on. Another example would be if someone created a script for an item which simply plays an SFX, costing a certain amount of rupees. He creates the script using variables naming the amount of rupees and the SFX number - defining them with names ("cost" and "sfx number"). After setting up the items to use that script, the attributes tab would display:

d0[cost] - (whatever is defined, or 0)
d1[sfx number] - (whatever)
d2[undefined] - 0

And so on.

This would encourage people to create modular scripts which just have to have a few attributes changed, make small changes easy, and would make everything user-friendly to users who don`t want to take the jump into scripting. This is a rough example, yet I think it is would be useful, and would provide a unified way to create menus for changing data (like sword strengths, fairy healings, ect) while using the script structure which will become more and more important. (idontknow actually provided inspiration to this - trying to make his idea for a sword editor more universal and script compatible).

I hope that this was an understandable and useful suggestion.

splatty

[_L_]

I don't see why we need to alter the user interface in order to encourage scripting neophytes to use modular scripts, or for scriptwriters to make them. As long as the scriptwriters provide easy instructions for modifying their scripts (and write their scripts such that modifiable constants are prominently displated), there shouldn't be any problem.

See: my Custom Miniboss of the Week #1 (http://www.armageddongames.net/showthread.php?t=93195), in which I include detailed instructions for importing Red Aquamentus into one's quest*. Though, while I tried to make sure that all of the modifiable lines were at the start of the script, I eventually ran out of registers - meaning one of the instructions is "change the number at line 51".

*Though I wouldn't recommend it at the moment, as I'm planning on updating its damage flash simulator to match that of CMotW #2.

[splattergnome]

It would help those who absolutely want to have nothing to do with scripting have an easy interface to alter pre-existing scripts - and it wouldn`t cause any major changed of the existing UI or the way scripts function.

The thing is this: I am no stranger to scripting languages (I even wrote one of my own in Delphi/Pascal for a small game project), but I can see that many people are scared off by it - among them many good Zelda Classic quest designers. I am all for the expansion of the scripting abilities to encourage new functions and flexibility for ZC - but on the other hand, I want it to remain simple enough for neophytes to learn to make their own quests and not get overwhelmed (as if learning the current interface wasn`t enough - it could use a revamp for more user-friendliness). And the additional interface would also profit people who want to script - they wouldn`t have to change every constant they define by hand in the script if they can change it in-program in dialogs.

An example: it is possible to simulate the Lost Woods maze using similar-looking rooms and warps, so in essence the maze function can be considered deprecated. Yet it is nice to keep it inside ZC not only for backwards-compatibility, but to offer another simpler alternative for beginners (and it does save map screens). I think Zelda Classic should continue offering -alternatives- and -possibilities- for people of all ability, a mixture of flexible scripting to create anything people wish to imagine... and hardcoded alternatives for speed, efficience, and ease-of-use.

splatty

EDIT: This is not intended to be a slam on your work - I read through your example scripts and found them very well done and commented, and I hope you further serve the ZC community well. :) I am just worried about creating a potential barrier which may prevent people from creating good and fun quests.

[Tygore]

I agree that the classic, user-friendly ZQuest interface should not be abandoned simply because of the advent of scripts. Many people, myself included, were/are drawn to ZC because of ZQuest's ease of use, yet complexity of customization. Of course, scripting will always remain an optional addition, but I do agree that we shouldn't forget to play with the old toys because of the new shiny ones, to make a (admittedly poor) analogy.

That being said, however, there are somethings that non-scripters simply will not be able to do. The purpose of scripts is to offer a second level of customization deeper than what the Graphical Editor provides. While I agree that ease-of-use is a good thing, we obviously must keep in mind the limitations of ZQuest.

[splattergnome]

My suggestion for adding labels/captions/names to variables and having all of the instance variables listed in a dialog is based on a similar system utilized by 3d Game Studio. I have not actually tested this program myself, but it is a 3d game creation system with a C-like scripting language of its own. It also includes a selection of script templates for all types of objects and events - and allows people to easily customize the variables (or constants, as you wish) in a dialog box. You can see a version of it *here (http://coniserver.net/FLASH/DemoProjectManager.htm)* at the "configuration" section. The difference would be instead of a custom dialog for each script - it would just list the local inherent variables of the script object (item, ffc, ect) along with the label/constant/name for each one.

In effect, it would just be a new dialog to change existing constants - and nothing much more. But I believe that it would help new users utilize the new public templates which will inevitably be created easily. A small but useful step to reduce people`s fears of scripts. :)

But then again I might just be confusing. :)

splatty