PDA

View Full Version : Plans for the future, part 1: AngelScript



Saffith
01-20-2016, 02:40 PM
A lot of details about ZC 3.0 have yet to be decided, but at least one thing is settled. All of the objects in the game - Link, enemies, weapons, items, and probably more - will be removed from the program code and converted to scripts. This isn't just a matter of making the engine more versatile; I believe it's the only viable way forward. However, ZScript is not remotely up to the task, and so it's going to be abandoned in favor of AngelScript (http://www.angelcode.com/angelscript/).

First of all: no, this does not mean losing backward compatibility. In fact, that's one of the primary reasons for doing this. ZScript won't be available in new quests, but it will continue to work in existing quests.

And secondly: no, you won't have to learn to work with scripts to make simple quests. A default set of items, enemies, etc. will be loaded up automatically. You won't even notice they're there.


It's pretty well known now that the game's code is a mess. Just as a random example, here's the main update function for phasing Wizzrobes.
-=SPOILER=-
guys.cpp is about 14,000 lines, and that's far from the worst of it.

We can't keep all of this code as it is. It's an absolute nightmare to make any substantial changes, and it depends on a lot of infrastructure that's just as bad.

But we can't rewrite it, either. I don't just mean that we're not capable of doing so, although that may well be true (I've tried and failed more than once). Rather, if we rewrite everything, we'll break a lot of quests. We've had many problems with this already - some quest depends on a bug, or the exact pixel where a collision is checked, or some other obscure quirk, and so a seemingly innocuous change breaks it. ZScript makes matters worse. It has direct access to a bunch of variables and would see changes in how they're used, so rewriting things without breaking existing scripts is virtually impossible.

The plan, then, is that the existing code will be converted from C++ to AngelScript with minimal changes. The behavior won't change at all, ZScript won't see any difference, and all we have to do to keep it working in the future is continue to provide the same script interface. This will be implemented invisibly in 2.60. From 3.0 on, these scripts will only be used for backward compatibility; new quests will use a separate set of scripts written from scratch.

Why switch to AngelScript for this instead of continuing to work on ZScript? Quite simply, it would be a lot more work with no added benefit. ZScript would need a complete overhaul to be capable of doing what we need, and the end result would be about as big a change from the current language.

Why not update ZScript so it can work alongside AngelScript? Again, a lot of work for little benefit. But more than that, keeping existing scripts working is a major design consideration, which would entail keeping a lot of the issues we want to get away from. Partial compatibility might be less work, but it's also harder to justify the effort in the first place, and it and would create confusion regarding what works and what doesn't.

Does this mean you'll have to learn a whole new language from scratch? Not really, no. AngelScript and ZScript are both based on C++, so their syntax and behavior are generally very similar. There will certainly be some differences, but if you already know ZScript, you won't have to learn everything all over again. You can see some examples from other programs here (https://github.com/OpenVSP/OpenVSP/tree/master/examples/CustomScripts), here (http://www.e-nuts.net/en/genetic-algorithms), and here (http://www.bluecataudio.com/Doc/Product_PlugNScript/#ScriptingBasics).


I felt this was a big enough change to warrant a public announcement, but I want to emphasize that it's more an implementation detail than a radical new direction. If you're not a scripter, all of this barely affects you. If you are, the changes are comparable to what they would have been anyway. There are a lot of details still to be worked out, but I'll answer any questions as best I can.

Tamamo
01-20-2016, 04:39 PM
Sounds like a plan, only thing missing is ffcs.
How are we gonna handle that monster?

Gleeok
01-21-2016, 11:20 AM
I see there now a fixed class for scripts.. ;_( Can't we just get rid of it once and for all?


Sounds like a plan, only thing missing is ffcs.
How are we gonna handle that monster?

Burn them with lighter fluid. :)

ZoriaRPG
01-21-2016, 11:36 AM
I'll say this, the effort in making a ZScript scripting interface for AngelScript, to me, seems worthwhile, and I might even be conned, or forced into making that a thing. I'll lose my sanity bonus to Spellcraft in the process, but my madness modifier will potentially compensate. In short, I would prefer to see the existing syntax preserved, as a user option, allowing for ZScript expansion in the process, or the users already accustomed to it. .

Gleeok
01-21-2016, 12:02 PM
I could start a ZScript to angelscript conversion utility. Not sure what the total coverage would be but it's doable. Maybe just have it read from a text file containing all the tokens to replace? ..not sure. Most of the syntax is the same anyhoo.

Tamamo
01-21-2016, 04:11 PM
Burn them with lighter fluid. :)
I completely agree. Let's just burn them.

Saffith
01-21-2016, 05:15 PM
I see there now a fixed class for scripts.. ;_( Can't we just get rid of it once and for all?
I don't think we can; things are just too fragile. We can separate it from Allegro, though, and I don't intend for it to be part of the interface for new scripts at all.

Tamamo
01-23-2016, 11:06 AM
Someone forgot the glue. *Fixed*
Anyways, I've been reading up on the documentation for angelscript. Looks pretty snappy guys!
Gleeok Saffith
Also this is just volunteer work, but I'm willing to rewrite guys.h if need be.

ZoriaRPG
01-24-2016, 09:23 AM
I could start a ZScript to angelscript conversion utility. Not sure what the total coverage would be but it's doable. Maybe just have it read from a text file containing all the tokens to replace? ..not sure. Most of the syntax is the same anyhoo.


This is what I was thinking. Just scan ZScript like the lexer does, seek tokens, and identifiers, and make new code as a cross-compiling operation. AngelScript supports whatever language interface you'd want, via plug-ins, so this sould be possible. Even arrays, and strings should convert: Just look for the correct tokens, and change them to a declaration as needed.

What I worry about, is type conversions. TBH, I abuse the ZScript typecasting to death, and not having that will break more than 50% of what I made to date. It would be nice to add some automated typecasting to AngelScript, to preserve this ZScript feature; as from what can tell, it doesn't already have anything like that.

Actually, we could probably rewrite the output of the present lexer, to make AngelScript, instead of ZASM.

Gleeok
01-27-2016, 11:27 PM
Do we plan on supporting waitframes()? I just realized if waitframes aren't a thing then there may not be a compelling reason to pool script contexts.

ZoriaRPG
01-27-2016, 11:53 PM
Do we plan on supporting waitframes()? I just realized if waitframes aren't a thing then there may not be a compelling reason to pool script contexts.

Saffith already said that the Waitfrme() instruction is planned as supported, and unchanged, on PZC.

Saffith
01-28-2016, 01:51 AM
Only in new scripts, though. Since the current ones are directly translated from C++, they won't use it.
I'm expecting to use a totally different interface for new scripts, which may mean a separate set of classes. Not too sure yet how it'll work out, really.
Edit: Then again, there are a lot of things in LinkClass that call advanceframe()... I'm not sure how that's going to work.

Tamamo
01-28-2016, 02:38 PM
Saffith
Okay what's going on first you say we're rewriting everything in angelscript, now you say we're not. o_O

Saffith
01-28-2016, 03:53 PM
It's being translated with minimal changes AND rewritten. The rewritten versions are separate and will be created later.

Gleeok
01-28-2016, 10:10 PM
So wait, if scripts are going to use a separate interface why bother moving built-in enemies again?

Tamamo
01-29-2016, 10:27 AM
<_<

This is why I drink Gleeok, cause the two devs don't know what the other one is doing.
Communication is a must if your this is gonna be open sourced Saffith.

Gleeok
01-29-2016, 10:50 AM
I have no idea what's going on right now. I took a break for a while after the gtk gui and now there's flying cars and talking dogs and shit. @[email protected]

...and what exactly does ZC need with a starship?!

Tamamo
01-29-2016, 11:15 AM
I feel your pain gleeok.

Saffith
01-29-2016, 02:01 PM
How is this not something we've discussed?
Whatever. We don't have to do this. I really don't care that much.

Gleeok
01-29-2016, 09:43 PM
I probably just forgot. >_> ...Which is why you're in charge of the enemies anyway. They're such a mess in general it's pretty easy to get confused, in my defense.

I mainly want to get a script processor in with some preprocessor support and allow ZC to compile scripts on the fly. The whole cycle of open zquest->compile scripts->save->load in zc->enter cheat->goto screen->test script->tweak script->repeat process is really annoying.

After that I don't know. Maybe replace ffcs with screen scripts or something.

ZoriaRPG
01-29-2016, 11:36 PM
I probably just forgot. >_> ...Which is why you're in charge of the enemies anyway. They're such a mess in general it's pretty easy to get confused, in my defense.

I mainly want to get a script processor in with some preprocessor support and allow ZC to compile scripts on the fly. The whole cycle of open zquest->compile scripts->save->load in zc->enter cheat->goto screen->test script->tweak script->repeat process is really annoying.

After that I don't know. Maybe replace ffcs with screen scripts or something.

I wouldn't replace ffcs, primarily because they could be very useful if implemented right. Really, they could be mini, self-contained global events that only run when referenced.

Compilation never bothered me though. I'd think that true JIT compiling would be (1) problematic to fairly implement, (2) a deviation that lends toward incompatibility, (3) slow, and (4) prone to user-error.

Frankly, ZQuest needs a proper IDE, built in to its interface. I sort of want to do that for ZScript, but it would be an insane amount of work, and I certainly wouldn't want to do it to a branch of code that is phasing out its scoped interface. :p

Also, I pretty much realised that both you, and Saffit are doing your own things, and that the end-result is sort of mashed together. This mates, is why keeping logs, at least, is important, with light docs as to what you do, have done, will do, want to do, have planned, found impossible, and so forth. This project is pretty much going to require that sort of logging.

That, or a never-ending Skype-group with all the coding participants in one place.

Tamamo
01-30-2016, 12:11 AM
we can't anyways Gleeok just hates ffcs period.

Gleeok
01-30-2016, 12:41 AM
I wouldn't replace ffcs, primarily because they could be very useful if implemented right. Really, they could be mini, self-contained global events that only run when referenced.

Compilation never bothered me though. I'd think that true JIT compiling would be (1) problematic to fairly implement, (2) a deviation that lends toward incompatibility, (3) slow, and (4) prone to user-error.

Frankly, ZQuest needs a proper IDE, built in to its interface. I sort of want to do that for ZScript, but it would be an insane amount of work, and I certainly wouldn't want to do it to a branch of code that is phasing out its scoped interface. :p

Also, I pretty much realised that both you, and Saffit are doing your own things, and that the end-result is sort of mashed together. This mates, is why keeping logs, at least, is important, with light docs as to what you do, have done, will do, want to do, have planned, found impossible, and so forth. This project is pretty much going to require that sort of logging.

That, or a never-ending Skype-group with all the coding participants in one place.

When you have a project that multiple people work on you really don't want to be working on the same thing, or sometimes even the same files. It's already complicated enough without having conflicts that can create bugs. It's not like it's random or anything. We've thought about updating the scripting engine and removing allegro for a long time. It's mostly straight-forward except in this case where I kind of forgot what's going on with the enemies. My bad.

When I say 'replace' ffcs I'm talking about a more general mechanism for scripts to create scripts and handle game related stuff. For example: How many times have you created an ffc that has NO COMBO data set because you just want a script to run. I'm guessing lots. ;) Also there would not be 32-per screen limit and there would be no memory or runtime overhead for scripts that you do not create.

As far as docs go I probably wouldn't read them anyway. :P

Tamamo
01-30-2016, 10:14 AM
ZoriaRPG
Github is more then enough of a collaboration resource in itself. If you use it right that is.
Gleeok
So he's the one who screwed me out of rewriting the enemy code you promised me. Good, now I know who to tie up in a spiderweb cocoon and feed to my babies tonight. Just kidding. Also open the ZC Dev forum to everyone already, my god what are you two waiting on, me to tell you to do it?
Saffith
You should just put me in charge of angescript stuff if you don't care then.

SUCCESSOR
01-30-2016, 02:25 PM
ZoriaRPG
No more Skype Talk, quit advertising that shit on agn ZoriaRPG or as an retired moderator I will have to slap your wrist. Github is more then enough of a collobaration resource in itself. If you use it right that is.
Gleeok
So he's the one who screwed me out of rewriting the enemy code you promised me. Good, now I know who to tie up in a spiderweb cocoon and feed to my babies tonight. Just kidding. Also open the ZC Dev forum to everyone already, my god what are you two waiting on, me to tell you to do it?
Saffith
You should just put me in charge of angescript stuff if you don't care then.

Take it down a notch. Please do not presume to think how staff may or may not intervene. No one here has any right to restrict free speech that doesn't violate our TOS. Mentioning skype is no more advertising than you mentioning all your furry/anime crap.

It goes along way in collaborating to be patient ad understanding. There will be a great deal of transition before there is a solid plan and smooth cooperation. Let's not make things harder than they already are.

ZoriaRPG
01-31-2016, 07:40 AM
When you have a project that multiple people work on you really don't want to be working on the same thing, or sometimes even the same files. It's already complicated enough without having conflicts that can create bugs. It's not like it's random or anything. We've thought about updating the scripting engine and removing allegro for a long time. It's mostly straight-forward except in this case where I kind of forgot what's going on with the enemies. My bad.

When I say 'replace' ffcs I'm talking about a more general mechanism for scripts to create scripts and handle game related stuff. For example: How many times have you created an ffc that has NO COMBO data set because you just want a script to run. I'm guessing lots. ;) Also there would not be 32-per screen limit and there would be no memory or runtime overhead for scripts that you do not create.

As far as docs go I probably wouldn't read them anyway. :P

I wholeheartedly agree, but I'm not sure where that came from... That applies most to closed projects though, as with open projects, especially on Git, you can compare changes submitted by multiple people, and utilise whatever parts of them you wish. It creates an ever-outward-spiralling changelog; and it is absolutely a pain in the arse.

Anyhow, this is why I usually limit participants on projects that are extremely complex, or I make everything modular as hell. If you want to glimpse what I've been doing for the last three years...

https://github.com/ZoriaRPG/RPG_zh/tree/0.97-Alpha-Development

Lots of files there. Thank goodness I have a documentation volunteer for all of that mess. Sort of like you do for this, except that I can never get a full, straight answer, when I need one to do any real work on internal code docs. :p

No complaints about a new object that allows that kind of thing, as long as classic ffcs are retained. I'd also advise prebuffering the classic ffcs only on screen loads to solve the mem issue, but we both know how complex that would be. Warps are the real problem. I have ideas on how this could work, but it's not high priority for me.

Between you and Saffith, you probably don't need such documentation, bur if you want people to contribute to this, we pretty much need those types of reports, to know what the flidd is going on. I glanced through some of the AngelScript stuff, but I have no idea how much is actually working, what works at all, or how much is in use, and not there as a placeholder, and what is next on the agenda. :confused_white:

Really, a simple plain text file that lists wat's working, not working, planned, and paused, would be good. Some list of what aspects need assistant / contrib coders, would also be good. Otherwise, multiple people will be working on the same things, out of sheer ignorance.


ZoriaRPG
No more Skype Talk, quit advertising that shit on agn ZoriaRPG or as an retired moderator I will have to slap your wrist. Github is more then enough of a collaboration resource in itself. If you use it

Did I really need to put a <sarcasm> tag in my remark; because a Skype dev group would, while amusing, be so fundamentally flawed and impractical, as to be worthless, for something like this. That's why I said 'neverending'. Do you know how many messages you end up with, having only four, or five participants, after a month or two? It's flipping sickening. :sick:

Sorry if you took that literally. Also, I know that neither Gleeok, nor Saffith use Skype, and I know that you don;t either...so, again, did I need a visible <sarcasm> tag, as i can always tack those on all over the place.

On another note, if Microsloth keep ruining it, I may shift messaging paradigms too, or move to an open-source client for it. I already can't run it on any of the OSX systems that I use, or to which I have access, which ruined one nice feature of being able to run it on a remote machine, and use VNC to log in and chat. They're such a bunch of tossers...

I do second the motion to make the dev forum public.

Tamamo
01-31-2016, 09:59 AM
ZoriaRPG
One facepalm away from the apocalypse hey chummer? But I'm with you we need a changelog before things spiral out of control and we start overwrite one anothers changes. I'll set one up in the New Dev Forums, by the way that's all we're getting. As those forums will always remain locked to Admins and ZC Devs only.

Gleeok
01-31-2016, 10:15 AM
If it's hard to get definitive answers sometimes it's because we don't know or would have to go through files to find out. DN and some of the older devs knew a lot of the more obscure stuff. :(
The angelscript on the c++ side is a lot of placeholders still. It mostly all works, unless you count the enemies always die after one frame as not working, in which case it doesn't. :P (I spent a minute looking into that but then I got distracted and optimized some stuff instead! roflcopter Fail. --whenever I see a misuse of std::map I turn into Mr.Furious from Mystery Men, which sucks because 99% of all use cases are misuses :( )

If I sound grumpy it's just because I have a lot of personal stuff going on and I literally lost sleep trying to get the open source stuff together before I have to go out of town for a bit, is all.

Tamamo
01-31-2016, 10:19 AM
I'm on it Gleeok, you know I love enemies. And I know that code as well as saffith does. So yeah

Tamamo
01-31-2016, 01:25 PM
Saffith
Is there a reason the constructor for the ASEnemies doesn't reproduce this?


enemy::enemy(fix X,fix Y,int Id,int Clk):
sprite()
{
d = guysbuf + (Id & 0xFFF);

bgSFX=sfxMgr.getSFX(d->bgsfx);
hitSFX=sfxMgr.getSFX(d->hitsfx);
deathSFX=sfxMgr.getSFX(d->deadsfx);

x=X;
y=Y;
id=Id;
clk=Clk;
floor_y=y;
ceiling=false;
fading = misc = clk2 = stunclk = hclk = sclk = superman = 0;
grumble = 0;
yofs = playing_field_offset - ((tmpscr->flags7&fSIDEVIEW) ? 0 : 2);
did_armos=true;
script_spawned=false;

hp = d->hp;
// cs = d->cset;
//d variables

flags=d->flags;
flags2=d->flags2;
s_tile=d->s_tile; //secondary (additional) tile(s)
family=d->family;
dcset=d->cset;
cs=dcset;
anim=get_bit(quest_rules,qr_NEWENEMYTILES)?d->e_anim:d->anim;
dp=d->dp;
wdp=d->wdp;
wpn=d->weapon;

rate=d->rate;
hrate=d->hrate;
dstep=d->step;
homing=d->homing;
dmisc1=d->misc1;
dmisc2=d->misc2;
dmisc3=d->misc3;
dmisc4=d->misc4;
dmisc5=d->misc5;
dmisc6=d->misc6;
dmisc7=d->misc7;
dmisc8=d->misc8;
dmisc9=d->misc9;
dmisc10=d->misc10;
dmisc11=d->misc11;
dmisc12=d->misc12;
dmisc13=d->misc13;
dmisc14=d->misc14;
dmisc15=d->misc15;

for(int i=0; i<edefLAST; i++)
defense[i]=d->defense[i];

bgsfx=d->bgsfx;
bosspal=d->bosspal;

if(bosspal>-1)
{
loadpalset(csBOSS,pSprite(bosspal));
}

bgSFX.startLooping();

if(get_bit(quest_rules,qr_NEWENEMYTILES))
{
o_tile=d->e_tile;
frate = d->e_frate;
}
else
{
o_tile=d->tile;
frate = d->frate;
}

tile=0;

// If they forgot the invisibility flag, here's another failsafe:
if(o_tile==0 && family!=eeSPINTILE)
flags |= guy_invisible;

// step = d->step/100.0;
// To preserve the odd step values for Keese & Gleeok heads. -L
if(dstep==62.0) dstep+=fix(0.5);
else if(dstep==89) dstep-=fix(1)/fix(9);

step = dstep/100.0;


item_set = d->item_set;
grumble = d->grumble;

if(frate == 0)
frate = 256;

leader = itemguy = dying = scored = false;
canfreeze = count_enemy = true;
mainguy = !(flags & guy_doesntcount);
dir = rand()&3;

if((wpn==ewBomb || wpn==ewSBomb) && family!=eeOTHER && family!=eeFIRE && (family!=eeWALK || dmisc2 != e2tBOMBCHU))
wpn = 0;

dummy_int1=0;
}