[-empyre-] Games, histories and preservation

[Jim Andrews]

> ahah, it's good to know that poor programming was at fault and not
> Director itself. i've seen several time-broken pieces made in that
> program and guessed that something must have been very wrong with the
> way Director dealt with time.
>
> >
> > But - yes!  it's precisely this problem that makes emulation/
> > reconstruction difficult.  Even i don't really remember what some of my
> > early works looked like!
> >
>
> funny that in these cases it's time itself that needs conserving. time
> will eat itself etc..


in well-programmed work, time is engineered. with a knowledge of what will
change over time and what will remain the same. a consciousness about time
in the piece. not leaving it up to the defaults of the software.

so of course that knowledge also involves a realization that eventually,
regardless of how well-engineered it is, it won't be running any more.

but that doesn't make it any more futile than other pursuits. that
eventually won't be running anymore either.

however, these things do take time to emerge.

some work, you can see it is built to last. other work, you can't tell for
some time. and some is obviously not going to last.

looking at the code is one of the ways to tell how robust it might be.
robust code is engineered with a knowledge of computer science and best
practices.

i worked on a preservation project at http://vispo.com/bp concerning
programmed, kinetic work by the poet bpNichol from 1983. he was not a
programmer. it was simple programming. and there's an emulator available for
the apple iie. so it was relatively doable.

but if an artist-programmer knows how to program and does something much
more ambitious, they'd better really be on their game concerning best
practices and documentation if they want it to stand a chance of surviving
beyond their own work on the program.

ja
http://vispo.com