Well, I’m casting about for ways to deal with some annoying weaknesses in Inform. I want to provide the simplest possible structure, in an extension, for animating any number of independent graphics elements using the glulx timer. Graphic elements are implemented as objects, and different kinds of elements can have different properties; it’s the properties that define how they are drawn. There are probably fifteen or more possible properties to act on (colors, scaling parameters, etc.), and properties of the window can also be animated (origin coordinate, background color).
That’s a lot of potential complexity, but for simple animations, procedural rules (“add 10% to the scaling ratio of the object each frame until it reaches 100%”) suffice, while switch statements can work for animations that can’t be described procedurally, e.g.:
if the current frame is:
-- 1: now the origin coordinate of the bunny is {12, 12};
-- 2: now the origin coordinate of the bunny is {200, 95};
-- 3: now the origin coordinate of the bunny is {66, 230};
But try to do any more in that same animation, and you hit a wall: Inform won’t let you provide multiple instructions on the same line of a switch statement. This doesn’t work, for example:
if the current frame is:
-- 1: now the origin coordinate of the bunny is {12, 12};
now the origin coordinate of the carrot is {200, 95};
-- 2: now the origin coordinate of the bunny is {200, 95};
now the origin coordinate of the carrot is {66, 230};
-- 3: now the origin coordinate of the bunny is {66, 230};
Even if it did work, that method would start to get cumbersome: Multiple objects and multiple properties of each of those objects might be changing in the same frame, and I don’t really want the author to have to type “now…” phrases for each object-property combination needed.
A generalized record or hash might be appropriate for this kind of thing, but aside from the “combination” type, which is not yet available at the I7 level–and may never be–there is no such thing in Inform. Lists aren’t a solution, since you can’t have multiple types in the same list.
And that leaves tables (though I am open to other solutions!–let me know!). As long as an author can use only the columns he needs, tables can be relatively compact. For example, the following table performs three different operations on two graphic entities, sliding a cover image in from the left and painted text (the title) in from the right, while at the same time swapping out the letters in the title:
Table of Cover Animation
frame object origin text-string
1 Cover-image {-200, 20} --
1 Title-slug {800, 30} "A@7D^arkz"
2 Cover-image {-100, 20} --
2 Title-slug {700, 30} "A@rd^arkz"
3 Cover-image {0, 20} --
3 Title-slug {600, 30} "A@rdvarkz"
If anyone has made it this far and doesn’t find convincing my justification for focusing on tables – please feel free to post! I’m happy to consider other ideas. (Note that the drawing by properties scheme is set in stone, though…)
In the actual extension, the kind of compact, semi-automated animation I’m discussing will be just one of several options. There will also be some prepackaged procedural animations of varying complexity, and the author will also be able to supply her own rules.
Wow, this is great–thanks Emacs! I do wish that this was a feature that Inform/NI provided, because even with this code, authors will need to do some mild bookkeeping if they want to add new properties. That’s not such a big deal, but I hate having to require those kinds of tasks. I’ll need to figure out how to add some optional columns that aren’t properties (for callback functions, among other things), but this ought to work. Thanks again!
–Erik