Once all the frames of the droid were put into Game Maker it was very simple to get the droid set up and animating.
To do this I used 2 objects – one for the animating part of the droid, and one for the numerals. This is then placed on top of the animating first object to give the effect that it is the complete droid on screen but it gives the option of having separate functionality, like switching out to hi-res images for the top animation as an example.
Here is the frame Objects sprite animating – all 8 frames are on a continuing loop.
I have opted not to have the animation cycling right and then back to left again as the original game did it the same way.
The next object created was a sprite with all the numeral combinations. Another positive effect, although mostly redundant with modern computers, is that this way would have saved a lot of space in graphics data when creating the original game, as the droid head and body would not have been duplicated 23 times for each of the robots. It wasn’t done this way to get the same memory saving, however, as the amount saved would be trivial. I’d estimate less than 1k in total. But on a C64 you could write a game of the time in that, even if it was very minimal.
After this we make the code link the two objects together to make our completed droid, as modeled by the influence droid himself, Mr. 001.
And after this, the droids number is easily changed by using the the sprite frame index because the 24 images used to represent the droid numbers have been stored as one animating sprite image which doesn’t actually animate.
So there is no need to swap out any actual objects as the sprite frame index is just switched to the new droid number, which is referred to in the code by using a macro table to save trying to remember all 24 droid numbers.
This is all present within the code ready to go, once we have the transfer game completed – which Tony is working on at present.