A couple of days ago, while trying to decide on the best and most reusable way to write some programs, I had a conception of what would be my ideal script interpreter. At first it didn't appear to be something in which a person could write a complete, fun game, but now I think it's possible. It won't be a game-specific script, though. This process of making a script has really crystallized the significant parts of each program method and their parameters.

Audio scripting works with some various capabilities. Now to graphics. You might think that simple graphic functions like blitting would be the easiest portion to code. That would be true, until thinking about all the various ways that even straight-blit graphics are used - in single-buffered or double-buffered mode, layered in various combinations, sometimes read from a file straight to the frame but other times read or manipulated off-frame, where ideally they should be tightly packed together and maybe even compressed. Then there are all the conditions associated with choosing the optimal blitting routine and carrying out special blitting functions. I should have expected complexities, though; after all, even 1D audio presents more challenges than it displays.

Creating the network commands later. Asked my old prof for permission to use our little cluster at his school to test the net scripting. Then there's input. If this script is going to support mobile devices, input specs will need to be designed with that in mind.