This is an incomplete roadmap of what I'd like to see in FreeSCI in the near future:
- Complete objectification
Syke (i.e. Matt Hargett) has a point about top-down work, of course ... but I am thinking that Glutton (the VM itself) should be converted last. I would rather see things like the resource manager converted first (a bottom-up approach), with Glutton coming in last. If anything in Glutton should be objectified first, it would be the segment manager (which has no direct counterpart in Sierra SCI and is therefore already abstracted from the original semantics).
- Non-reliance on the kernel table (vocab.999 / 999.voc)
This resource is notoriously unreliable, and should not be used. Instead, we should use the ScummVM autodetection mechanism to choose an appropriate built-in kernel table. The other vocabulary resources are generally reliable and should be used to the extent that it makes sense (vocab.997 / 997.voc -- the property name table -- is a good example while vocab.994 / 994.voc is not. The information in 994.voc was meant for a computing era when class information lookups were expensive; they aren't anymore, so using the plain 997.voc will do nicely - FreeSCI does this already, while the reimplemented SCI engine does not).
- Removal of the graphics subsystem
The graphics subsystem is currently incompatible with much of the UI in SCI1 and later, and certain rooms in SCI0. It would be nice here to revert to a plain bitmap-based approach (like ScummVM). However, we want to keep the graphics subsystem around as it is well suited for SCI32; a battery of unit tests is desired to make sure that this remains possible.
- Keeping Glutton around
Glutton currently has problems with strings in some games; a reimplementation is underway (by lskovlun) to rectify this. Some may think that this is a good reason to keep the VM as close to Sierra's as possible (see the recent reimplementation); but I believe that the Glutton VM (if the string fixes turn out to work) would work equally well with SCI1.1 and earlier and SCI32, whereas the reimplementation would have to do something else for SCI32.
- What is this thing about SCI32?
Whereas SCI1.1 and earlier have a 64 kilobyte heap space which is addressable via pointers, SCI32 uses memory handles exclusively. That means that all the string handling functions have been replaced by a single String() call, array handling (which used to be primitives) is now a kernel call Array(), etc. Direct pointer addressing is no longer possible!