I guess I can see what you mean, but goto commands seem to be a major part of the scripting as whole. Just look at the Game Corner in FireRed, every person there uses a goto command to share a reused part of the script.
The reason higher level languages can leave out goto commands and such is because the effect can be gained by using loops and functions and whatnot, but that isn't exactly as feasible with the scripting format used by the games.
I plan to add in while loops as well as functions (in fact, I'm right in the middle of doing so). However, you can still use those commands. You can call and goto as long as you know the offset. If you compile a script, you can call/goto it if you know the offset, but I'm making no plans to include dynamic offsets and such. You can just use a function, an if or while statement. However, if I think of a way to do it in Python syntax (I have to stick to it very closely, due to my implementation), I will try and add them. Maybe I can allow you to mark certain locations and jump back to them?
Additionally, I plan to allow integration with other things. For example, I plan to include automatic ASM routine insertion. So maybe I'll allow integration with a more traditional script. But that's not for now. I first want to get a fully functional version of this first. I am making every effort to make sure no features are left out. This is designed to be a superset of the existing scripting language after all.
I would recommend to keep the Games' Script Engine's syntax.
So use
textbox (u32 text, u8 callstdevent)
instead of
question (u32 text). This will make things more easier if you add commands or things like that.
A "script" could look like this:
function:
textbox (new String("Hello World"), 2);
exit();
That would be an authentic and efficient way of handling with scripts and using a good scripting language.
I don't quite understand why this is better. The thing is, these functions are created in a separate Python module - adding functions is trivial. For example, here is the implementation of the message and question functions (In Python)
@register
def message(string, keepopen=False):
out = []
out.append(script.Command.create('preparemsg', string.value))
if keepopen:
out.append(script.Command.create('callstd', 4))
else:
out.append(script.Command.create('callstd', 6))
return out
@register
def question(string):
out = []
out.append(script.Command.create('preparemsg', string.value))
out.append(script.Command.create('callstd', 5))
return out
As you can see, the function implemented in Python takes the same arguments as the function in the script. If then interprets the arguments and returns real script commands that will be the commands compiled in the final script. It's trivial to add your own commands: all you do is write a function like this, and add the register decorator, and the function will be usable in a script.
That isn't even the game engine syntax though. A message is made by preparemsg, followed by callstd. So XSE already abstracts that. All I'm doing with the question command is hiding that callstd call.