PDA

View Full Version : About the scripting system in Zq



Chl
10-31-2006, 05:38 PM
Hello
I've seen alot of scepticism about the scripting system on this board and I can understand it. There's reason people use an editor to make things and that's because they don't know anything about programming, me included.
I'm not saying that the scripting should be removed, it's a very useful feature to have, but it could be made alot easier to use.
So I'm wondering if it is possible to program a system like the one they use for the editor in Starcraft and Warcraft 3?
For those who haven't seen it, the system works like this. The programmers have allready done all the coding, you just have to select the commands and enter the values. It can look like this:


-TRIGGER
Link enter room 1.

-ACTION
Play sound ding.wav
Create Key in room 2.
Disable this trigger.

END

All those lines have been choosen from a list and the names in blue are all the things the user have to change manualy by either selecting an item from a library or enter some text or number.
Personaly, I think this system is super easy to use since no scripting knowledge is required and it's just as powerful as pure scripting.

That's what I wanted to share about my thoughts of the scripting in Zq. What do you guys think?

C-Dawg
10-31-2006, 06:13 PM
This is a poor idea, for four reasons.

(1) A C language derivative is far more powerful than any pseudo-language that you might come up with, while being just as hard to learn. The only difference between C and StarCraft's trigger system is that you code using the mouse instead of typing. It's the same thing, people. They've just built the syntax into a limited series of pull-down menus instead of letting you type it. This is cumbersome and vastly limits what you can do with the code.

(2) You want a non-C based scripting language? Check out, oh, EVERYTHING ELSE in ZQuest. Using screen animation, tiered secrets, combo animation, and other tricks and hacks that people have built up over the years, you can simulate pretty much anything you want. But, of course, it's much more cumbersome and ultimately more time consuming than coding.

(3) There is no need for individuals to learn C if they don't want to. (Although you should; think of it as an educational opportunity.) There are going to be plenty of coders out there hard at work making scripts you can apply to your own quest using the simple "point and click" interface you're after.

(4) As I understand it, the developers are basically building a compiler from scratch to get ZScript working. C compilers are widespread, documentation is accessible, and the developers are familar with the language. Making something up would compound their problems and make it more difficult to create a working ZScript system.

I'm amused that anyone could be so intellectually lazy that they're actually scared of having the option to code if they want.

cbailey78
11-02-2006, 12:57 AM
I'm amused that anyone could be so intellectually lazy that they're actually scared of having the option to code if they want.

HEY NOW! Don't you be insulting quest designers by calling them lazy! That's not very nice to say. Alot of people are not into programming including me and you got to respect that.

I LOVE Chl's idea alot. It does make the system alot more easy and faster to program. Just like in RPG Maker 2003 where It has the pre-scripted commands that has alot of commands to choose from. This idea will make the quest designers progress ALOT faster!

Saffith
11-02-2006, 03:00 AM
It's much less powerful, though. The current system can do a lot more than that could.
In any case, if there's enough demand for a simpler language, someone can always write a compiler for it. It just wouldn't be built into ZQuest.

DarkDragon
11-02-2006, 08:15 AM
Go for it, absolutely! You'd just need to write a compiler that produces as output ZASM, and I'd be happy to integrate it into ZQ for you.

Dark Nation
11-02-2006, 08:25 AM
It's a workable idea, as DD said. Theoretically, one could make a BASIC, Pascal, o even FORTRAN compiler (or a Starcraft-style trigger system) for ZC. All they'd have to do is make it export ZASM code. However, such a thing is a very large undertaking, not one the current developers could tackle right now.

Nicholas Steel
11-02-2006, 08:46 AM
wait for the current script engine to become stable before mentioning other script engines etc..

Chl
11-02-2006, 06:00 PM
I'm amused that anyone could be so intellectually lazy that they're actually scared of having the option to code if they want.

Well, I wanted, with my suggestion, that the option to script in Zq should be made available to more users.
You know, learning a scripting language is not an easy thing to do and for most people it's not an option.
Atleast with this suggestion the option to script will actually be an option for more people, even for those who deosn't know the scripting language.
(And I didn't say that you should remove the current system in favor of my suggestion. They both could be used.)

That you are insulting me for a suggestion that would make Zq easier and more open for the average user (and with that, hopefuly, attracting more people) is to me simply astounding and will only give Zq a bad reputation.

beefster09
11-02-2006, 06:36 PM
I will do something like this when I know enough programming. I'll make an external compiler. The main problems for me are:
I don't know a whole lot of the Zscript language
I don't know how to do WinLib programming with Euphoria (it's a language).
I don't want to pay to get the Euphoria .exe compiler. (Just for accessability)

I could probably work my way around the second two for now, Albeit it would be harder to use than pressing buttons.

DarkDragon
11-03-2006, 12:41 PM
A couple of thoughts -
first, I believe it's been shown that the warcraft scripting language is Turing complete, in which case in that sense it is no less powerful than C. I personally don't believe it would be as useful in this case since many FFC special effects require very precise movement and timing described by complicated mathematical expression, but don't be discouraged by the nay-sayers.

second, I'm not sure what exactly Winlib or Euphoria is, but I want to make it clear that I'm only willing to integrate a compiler into ZQuest if it's written in C/C++, or can be statically linked against C/C++ code. I'll be happy to discuss a precise interface once someone has a compiler which is nearing completion.

Revfan9
11-04-2006, 10:04 PM
...Not having the option to script is just plain ridiculous. Heck: I learned how to script in under an hour (not counting time waiting for questions to be answered through the forums). Besides the simple fact that you do not want to use Zscript (which is perfectly fine), there is not a single reason why you cannot learn Zscript.

Now, I do know a reason why people might not want Zscript: It may turn into another Gamemaker. I do not mean interface wise, but community-wise. Ever tried to ask how to do something in Gamemaker? The answer is always "Code it." Soon (seemingly) the only way to do anything is to learn this (seemingly) super-complex language and to do everything by hand.

beefster09
11-04-2006, 10:12 PM
Forget my previous post then. We can make a quest just as well without coding. You just place tiles, warps and flags and that's really all that is required. We could just have a color-coding system to make it easier to follow and write.

Chl
11-05-2006, 10:02 AM
...Not having the option to script is just plain ridiculous.
Where in this thread did you read that? :confused:



Heck: I learned how to script in under an hour (not counting time waiting for questions to be answered through the forums). Besides the simple fact that you do not want to use Zscript (which is perfectly fine), there is not a single reason why you cannot learn Zscript.

Are you talking to me? In that case, I never said that I don't want to learn how to script, just to make it easier to do.

Revfan9
11-05-2006, 03:25 PM
Look: Any possible way that would make it easier would just limit it's power. If anything, we need to give it more power, and the people who don't want scripts need to just leave the damn thing alone and let us do our buisness.

And whoever said that you can have someone else do it is smoking something. Most people who can script don't want to have to be at the beck and call of thousands of ZC users who are too lazy to learn it themselves. You either learn to use scripts or not use them at all, either one is fine but pick a side goddammit.

cbailey78
11-15-2006, 06:27 PM
And whoever said that you can have someone else do it is smoking something. Most people who can script don't want to have to be at the beck and call of thousands of ZC users who are too lazy to learn it themselves. You either learn to use scripts or not use them at all, either one is fine but pick a side goddammit.


HEY! You need to watch your language, Revfan9! Didn't you learn not to cuss in AGN ZC forums? Plus, you are insulting Chl's suggestion. I don't mean to be a pain to you, Revfan9, but if people don't wanna have to hand-code just to make quest-user's desired effect, Chl's suggestion is the one that it will indeed make it easier and more convenient. I am right with Chl's idea there and I don't wanna have to waste 3/4 of my life learning all those fancy complicated manually hand-coded stuff to make a desired effect.

Grant it, I am very stunning impressed how they made that gravity side-view effect script and I greatly enjoy having that ability to do that, but look how hard and tedious it was to make that work:

// Gravity in sidescrolling areas version 1
//
// g is the downward acceleration of Link.
// terminalv is the maximum falling speed of Link.
// jump is the speed at which Link jumps up.
// To change the jump button, globally replace "Link->InputB."
//

import "std.zh"

ffc script Gravity {
bool UnwalkableAt(int x, int y) {
int x2 = Link->X % 16;
int y2 = Link->Y % 16;
int mask;

if (x2 >= 8)
mask = 1;
else
mask = 2;
if (y2 >= 8)
mask << 2;
return (Screen->ComboS[ComboAt(x,y)] & mask);
}
void run(int g, int terminalv, int jump) {
int fall;
while(true) {
Waitframe();
if (UnwalkableAt(Link->X,Link->Y-1) || UnwalkableAt(Link->X+15,Link->Y-1)) {
if (fall < 0) fall = 0;
Link->Y++;
}
if (!UnwalkableAt(Link->X,Link->Y+17) && !UnwalkableAt(Link->X+15,Link->Y+17)) {
if (fall < terminalv)
fall = fall+g;
Link->InputB = 0;
if (Link->InputUp) {
Link->Y = Link->Y + 1.5;
}
} else if (Link->InputB && Link->Action != LA_HOLD1LAND && Link->Action != LA_HOLD2LAND) {
fall = -jump;
} else {
fall = 0;
}
Link->Y = Link->Y + fall;
}
}
}

It's alot of coding just for a simple effect, huh.

C-Dawg
11-16-2006, 11:16 AM
How is that tedious at all? It's less than one hundred lines of code. That's really damn simple, as are most codes in ZScript.

Sheesh. Remember, once someone actually codes the script, anyone else can happily take it and stick in into their own quests with no more difficulty than tuning your dmap settings. So you all benefit from scripting.

P.S.: OH NO BAD LANGUAGE put the kids to bed

DarkDragon
11-16-2006, 11:19 AM
Moreover, if you put the gravity code into a file, say gravity.z, then adding the gravity FFC to your quest is as easy as a single line importing that file.

_L_
11-16-2006, 01:52 PM
It's alot of coding just for a simple effect, huh.

It is not a simple effect. It is rewriting the collision system so that Link can walk on top of combos and bump his head on the bottom of combos, and allow jumping only when he is walking on a combo, and not when he's holding up an item. That as well as simply falling down.

A "simple" effect would be an FFC that mirrors Link's movement:


ffc script Anti-Mimic {
void run() {
int lx;
int ly;
while(true) {
lx = Link->X;
ly = Link->Y;
Waitframe();
this->X+=(lx-Link->X);
this->Y+=(ly-Link->Y);
}
}
}Ironically, this particular ZScript has more lines of code than its ZASM counterpart:

SETR d0,lx; record Link's position.
SETR d1,ly
WAITFRAME; Let Link move...
SUBR d0,lx; and record his new position.
SUBR d1,ly
ADDR x,d0; apply the change of position to self, in reverse
ADDR y,d1
GOTO 1
QUIT...but its virtue is that it's much easier to follow the algorithm in it, which is an essential quality when dealing with far more complex multiple state scripts and such.