Index of /~abo/projects/wilr/

Warlpirri Interactive Learning Resource Project
===============================================

This was a Macromedia Director project developed Primarily by Wendy Baarda.
I (Donovan Baarda) did some work on scripting and integrating the final
movie player from the multitude of movies and casts. Documentation of my
work on this project can be found online at;

http://minkirri.apana.org.au/~abo/projects/wilr/

A diary and mbox format mailbox of correspondance relating to my
contributions to this project can be found in the swf directory. Various
historical files and media can be found in the arc directory. The Macromedia
Director files can be found in the wendy directory.

The "wilr-aui" projectors that run the program on Windows or Mac can be
found in the "movies" directory. It can be installed to hard disk by copying
the entire contents of the "movies" directory into a suitable directory.
Saving of user scores does not work when the projectors are run directly off
the CD, only when running off a writable hard disk.


Guidelines for Macromedia Director Projects
-------------------------------------------

After battling through trying to clean up movies created by Wendy, the
following guidelines have become apparent. Mostly they relate to reducing
duplication. Duplication is bad, because it spreads stuff all over the
place. This means you spread mistakes everywhere, so when you fix or improve
it, you have to fix it everywhere it was duplicated, and often you miss
places. Unfortunately, Macromedia Director seems to encourage duplication,
so you have to actively work at avoiding it in the short term to reap the
long term benefits.

Rule 1) Never copy cast members! The Edit;Copy menu item is off-bounds when
manipulating casts. If you need to use a cast member in another
movie, move it into an external library and link that library.

Rule 2) Don't copy behaviors and modify them! If you find yourself copying
and slightly modifying large behaviours, instead think about what it is that
is different and try to make one behaviour handle all the special cases.
Either that or factor out the common parts of the behavior into a movie
script and call it from the specialist behaviour.

Rule 3) Before you put a cast member into a library, check that it doesn't
already exist! That includes in other external libraries. If you find that a
member already exists for that purpose but is not as good, replace it, don't
just add it. This means the other movies will benefit from the new improved
version. Make sure you put the replacement cast member into exactly the same
spot as the old one.

Rule 4) Give cast members meaningful and unique names! This makes it much
easier to refer to them in scripts, and helps you realise when you are about
to duplicate something.

Rule 5) Never delete anything from an external library! It is nearly
impossible to know if that cast member is used or not in any of the movies,
and deleting it will break them. This rule makes the other rules about
avoiding duplication even more critical, because once you break them, you
can't fix it. However, the one exception to this rule is when you _want_ to
break things and are prepared to go through all the movies and fix them.

Rule 6) put related cast members into the same cast library. The idea of
breaking casts up based on media type is bad, because it means they
libraries are not self-contained and break easer when the other library gets
changed (as with the faces.cst loops and sounds from snd tija.cst). This
means fancy scripts should be in the same library as the cast members they
manipulate.

Rule 7) Don't write piddly little behaviours again and again and again. I
know you didn't use Edit:Copy, but the result is the same. Instead put the
behaviour in a cast library and drag-n-drop it where you need it. Most of
these behaviours are already in the scrip.cst. Even if they are simple,
sometimes you find a better way to do it, and it's much easier to change it
once in a library than 50 times all over the place.

Rule 8) don't write scripts that refer to sprites (or anything else) by
number. These scripts are so fragile they shatter with the smallest prod,
even if you think it is unrelated. Use "me.spriteNum" instead. The other
benefit of this is makes the behaviour re-usable because you can drag it
onto any sprite and it will work.

These simple rules will save much heartache and time later on. In the short
term they will force you to think harder about casts and scripts, but in the
long term you will have less that needs fixing, and fixing things will be
easier.