I am getting quite some feedback on my SPUTM-like interpreter for the Commodore 64 so I thought to summarize here what my plans are.
Firstly, I have no plans to develop Monkey Island 2 for the Commodore 64. As with my work on “Integrator 2012” and “The Last Ninja Construction Kit” (video link), I am trying to facilitate the effort of writing new point-and-click graphic adventures for the Commodore 64 that would look and feel like some of the ones produced by LucasArts a few years back. For that purpose I am developing a number of components that would surely be useful for putting together a SPUTM-like interpreter (which I referred to as “SCUMM mockup” too). I feel such development to be funny and that’s why I am doing it.
Here are current download links for my effort (same version as the one published on CSDb):
Here’s a video of what’s available to players so far:
On top of that I finished the sprite clipping code, i.e. the code that cuts off bits from sprites that should be covered by the foreground. What that means might be clear by looking at a (yet unfinished) image that shows the overall clipping mask:
The code itself is inspired to the one from John Twiddy’s LN serie.
However, before I can use the sprite clipping code I have to write and test a “zone split” sprite multiplexer, similar to the one used in Turrican/Turrican II on the Commodore 64 for boss fights (remember the huge “fist” trying to squash the main character?). The reason is that I need far more sprites on the screen than available through the VIC-II hardware, which is feasible provided that certain conditions are met. I won’t go too technical with that.
After the sprite multiplexer is finished I might release a demo in which Guybrush walks around on his own “initiative”. After that I need to work at the walking routines, specifically how to get Guybrush from point A to point B. In theory this is quite simple to do but it is important for me to try and write intuitive PC tools to facilitate setting up of the information required for routing Guybrush through obstacles (in a similar way I addressed editing requirements in The Last Ninja Construction Kit).
When that is finished I will finally look at packaging the data into a single file and rearranging the code in an interpreter fashion. The code will just need pointing to a file which will be parsed in order to know what graphics need to be rendered, what extra objects and sensitive areas need to be added, what tune needs to be played, what messages shown, etc.
I am positive that the interpreter and data for a single location will comfortably fit into the Commodore 64’s RAM. As for disk usage, mass storage solutions will definitely be required in presence of bitmap graphics, e.g. USBhost-64.
As per the huge memory taken by sprites, that’s not a concern for me at all. Similarly to what John Twiddy did with his LN serie, I am packing my sprites and only keeping a minimum amount of them in RAM. In fact, I can mirror them on the fly in order to provide mirrored versions (e.g. only sprites for walking to the right will need storing as walking to the left uses the same sprites mirrored horizontally). This also means that packed sprite data does not need to reside in the limited memory bank currently addressed by the VIC II on a Commodore 64.