Plans for the future, part 1: AngelScript
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.
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.
Code:
void eWizzrobe::wizzrobe_attack()
{
if(clk<0 || dying || stunclk || watch || ceiling)
return;
if(clk3<=0 || ((clk3&31)==0 && !canmove(dir,(fix)1,spw_door) && !misc))
{
fix_coords();
switch(misc)
{
case 1: //walking
if(!m_walkflag(x,y,spw_door))
misc=0;
else
{
clk3=16;
if(!canmove(dir,(fix)1,spw_wizzrobe))
{
wizzrobe_newdir(0);
}
}
break;
case 2: //phasing
{
int jx=x;
int jy=y;
int jdir=-1;
switch(rand()&7)
{
case 0:
jx-=32;
jy-=32;
jdir=15;
break;
case 1:
jx+=32;
jy-=32;
jdir=9;
break;
case 2:
jx+=32;
jy+=32;
jdir=11;
break;
case 3:
jx-=32;
jy+=32;
jdir=13;
break;
}
if(jdir>0 && jx>=32 && jx<=208 && jy>=32 && jy<=128)
{
misc=3;
clk3=32;
dir=jdir;
break;
}
}
case 3:
dir&=3;
misc=0;
case 0:
wizzrobe_newdir(64);
default:
if(!canmove(dir,(fix)1,spw_door))
{
if(canmove(dir,(fix)15,spw_wizzrobe))
{
misc=1;
clk3=16;
}
else
{
wizzrobe_newdir(64);
misc=0;
clk3=32;
}
}
else
{
clk3=32;
}
break;
}
if(misc<0)
++misc;
}
--clk3;
switch(misc)
{
case 1:
case 3:
step=1.0;
break;
case 2:
step=0;
break;
default:
step=0.5;
break;
}
move(step);
// if(d->misc1 && misc<=0 && clk3==28)
if(dmisc1 && misc<=0 && clk3==28)
{
if(dmisc2 != 1)
{
if(lined_up(8,false) == dir)
{
// addEwpn(x,y,z,wpn,0,wdp,dir,getUID());
// sfx(WAV_WAND,pan(int(x)));
wizzrobe_attack_for_real();
fclk=30;
}
}
else
{
if((rand()%500)>=400)
{
wizzrobe_attack_for_real();
fclk=30;
}
}
}
if(misc==0 && (rand()&127)==0)
misc=2;
if(misc==2 && clk3==4)
fix_coords();
if(!(charging||firing)) //should never be charging or firing for these wizzrobes
{
if(fclk>0)
{
--fclk;
}
}
}
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, here, and here.
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.
