Difference between revisions of "TsAGE/TODO"
Dreammaster (talk | contribs) m (Reworked sound TODOs, and removed old bug I haven't been able to replicate) |
Dreammaster (talk | contribs) (Added a section on how the savegame format could be reworked) |
||
Line 1: | Line 1: | ||
This is a list of things that could still be done for the Ringworld game: | This is a list of things that could still be done for the Ringworld game: | ||
=== Possible Enhancements === | |||
Present in the original game | * Add sound support for sound cards other than Adlib, such as Roland | ||
* Rewrite the savegame mechanism | |||
Currently the savegame code works similiar to the original, in that every object derives from a 'SavedObject' base, which is registered in a master list when objects that derive from it are instantiated. So the saving code essentially loops through the objects one by one to have each save their data in turn. The trouble with this it when loading a savegame, it relies on all the objects registered in the list to have been instantiated in the exact same order; which may not be the case if the savegame is loaded in another system, or even which an executable compiled using another compiler, since the fields of a given class are guaranteed to be created in the same order. | |||
A lot of this could be resolved by replacing this with a manual hierarchnical saving of data, where the overall Globals object would explicitly call the synchronize method of all the objects within it, and they each explicitly call the method for the objects they contain, and so on. Whilst this would handle the majority of the save process, there is one remaining issue, that of pointer handling. | |||
In many places in the engine there are pointers to other objects. The Sequence (Cutscene) manager can, for example, take in pointers for the characters the cutscene applies to. Currently these are handled by storing the index in the list of instantiated objects of the object the pointer points to, and then doing a lookup doing savegame restore. Because of this, it will be very difficult to get rid of the existing savegame mechanism without coming up with a good way to represent the same information. Perhaps giving any object that can be pointed to a unique Id, and having a lookup list of only those Ids. This might ensure savegame restore would work, and allow them to be portable. | |||
=== Present in the original game === | |||
* Scene 2320: After being told to look for the Explorer I was able to construct the arms for the dolphin. I didn't even know I would need that! | * Scene 2320: After being told to look for the Explorer I was able to construct the arms for the dolphin. I didn't even know I would need that! | ||
* Scene 4000 (or maybe 4045): If you tell the chief to show you the Tech, Miranda will say "Quinn, it's a simple force field regulator", even if she's not in the room with you because she's stuck with Rock. (Update: This is apparently a bug in the original interpreter as well, but could perhaps be fixed in ScummVM?) | * Scene 4000 (or maybe 4045): If you tell the chief to show you the Tech, Miranda will say "Quinn, it's a simple force field regulator", even if she's not in the room with you because she's stuck with Rock. (Update: This is apparently a bug in the original interpreter as well, but could perhaps be fixed in ScummVM?) | ||
Line 13: | Line 22: | ||
* Scene 6100: At the end, texts are not skippable, it looks wrong | * Scene 6100: At the end, texts are not skippable, it looks wrong | ||
Game status | === Game status === | ||
* Floppy version: Completable. | * Floppy version: Completable. | ||
* First wave version: Completable. | * First wave version: Completable. | ||
* CD version: Completable. | * CD version: Completable. |
Revision as of 11:27, 23 June 2011
This is a list of things that could still be done for the Ringworld game:
Possible Enhancements
- Add sound support for sound cards other than Adlib, such as Roland
- Rewrite the savegame mechanism
Currently the savegame code works similiar to the original, in that every object derives from a 'SavedObject' base, which is registered in a master list when objects that derive from it are instantiated. So the saving code essentially loops through the objects one by one to have each save their data in turn. The trouble with this it when loading a savegame, it relies on all the objects registered in the list to have been instantiated in the exact same order; which may not be the case if the savegame is loaded in another system, or even which an executable compiled using another compiler, since the fields of a given class are guaranteed to be created in the same order.
A lot of this could be resolved by replacing this with a manual hierarchnical saving of data, where the overall Globals object would explicitly call the synchronize method of all the objects within it, and they each explicitly call the method for the objects they contain, and so on. Whilst this would handle the majority of the save process, there is one remaining issue, that of pointer handling.
In many places in the engine there are pointers to other objects. The Sequence (Cutscene) manager can, for example, take in pointers for the characters the cutscene applies to. Currently these are handled by storing the index in the list of instantiated objects of the object the pointer points to, and then doing a lookup doing savegame restore. Because of this, it will be very difficult to get rid of the existing savegame mechanism without coming up with a good way to represent the same information. Perhaps giving any object that can be pointed to a unique Id, and having a lookup list of only those Ids. This might ensure savegame restore would work, and allow them to be portable.
Present in the original game
- Scene 2320: After being told to look for the Explorer I was able to construct the arms for the dolphin. I didn't even know I would need that!
- Scene 4000 (or maybe 4045): If you tell the chief to show you the Tech, Miranda will say "Quinn, it's a simple force field regulator", even if she's not in the room with you because she's stuck with Rock. (Update: This is apparently a bug in the original interpreter as well, but could perhaps be fixed in ScummVM?)
- Scene 5100: After stunning one of the flesheaters, the other one runs away. If you stun the one on the right, the other one hides on the far left of the scene. Even though you can't see it, you can examine it and touch it. The descriptions you get are the same as for the stunned flesheater. Apparently, the game doesn't make any difference between them.
- Scene 5300: If I escape this room and are recaptured (by falling into the pit again), Quinn says "Was it something I said?", etc. This happen until Quinn drinks the potion, so it looks a bit weird when it's not the first time.
- Scene 6100: If I allow the probe to get too damaged, it leads into a conversation between Quinn and Seeker. The mouse cursor is shown here (present in the original) and the cursor movement is much jerkier than usual. (This jerkiness is also present when successfully reaching the destination with the probe.)
- Scene 6100: At the end, texts are not skippable, it looks wrong
Game status
- Floppy version: Completable.
- First wave version: Completable.
- CD version: Completable.