Many of those are just unclarity on my part.
Timing allows floating point. And the language isn't necessarily using any specific time unit; we could be referring to frames, seconds, turns, "story markers" or any other sequenced system you can think of. Relative time, as well, is just a matter of when the script is launched, and there are myriad possibilities in the embedding process for ways to control how things are launched, updated and terminated.
The shot example actually doesn't need @6. I wasn't thinking correctly when I wrote that and figured "one state resulting from this event is getting shot but not dying, the other state is getting shot and dying, let's move them into different time periods." It would probably need @6 if I included a "play anim" thingy(then again, maybe not - it might just add a tween over everything else).
With regards to the function call syntax, there are three things going on here. First of all, there are no function definitions in the program body(that's done in embedding), hence I reuse the type annotation syntax in a different way.
"function!():foo" gives you a named value for iterators. I guess I could do "for function!() in name" or somesuch, but it would break the sigil-heavy thing I have going.
"function?():foo" gives you a named value for conditional results. Recall how in an Algol-type language, you'll say:
But then result()'s output disappears. I'm preserving it because I expect to have a lot of branches of this type:
/* destroy the monsters */
aiIs?(entity) : ai
Player: {}
Pickup: {}
Monster: {
kill(ai)
}
I don't like the latch syntax yet. I'm iffy about the tween syntax. They are similar but different. Latches are indefinite repetitions over time - they get called either every time you step the script, or on some interval of time. This, as well as the way tweens work, is important because, as I said, the nature of time is undefined. You could be incrementing frames, or just fractions of a second. And since you can loop or go backwards in time, sometimes you want a certain thing to repeat until an event occurs to stop it.
@0 (< latcha 2 {pulse("red")}
@1 (< latchb 2 {pulse("green")}
@2 goto(1.9)
%somethinghappened
>) latcha >) latchb
In this example I've set up two latches that can do "flip-flop" behavior(like pulsing a light red and then green) in the background, freeing up execution for other things until %somethinghappened is called, at which point the latches immediately terminate. With a tween this can't be done because the tween needs to know where it ends.