Roadblocks in the path of tSage

Those of you who have been following the IRC channels will know that I made some real progress in the disassembly of the tSage engine, used by the Ringworld - Revenge of the Patriarch game, as well as several others. I hadn't really gotten into any of the game logic, but I'd made great strides in decoding the image formats and graphics display, so much so that my engine on Scummvm-misc could display test dialogs, as well as the right-click game dialog with proper highlighting and everything. Sample screenshots below:





However, given the perversity of life, I should have known better than to announce on the channel that I was making real progress. :(. Because as I was getting into the game execution logic, I began to realise just how complicated they made the engine. Whilst using C++ has it's advantages from the perspective of RE, since it does group related functions close together with the variables they use, in this case, they seemed to go overboard with it.

A preliminary look at the main event loop of the game shows they implemented a stack of "action objects" - multiple independent event handlers can be registered and control swapped form one to the other. I'm not sure, but I presume that this is to allow for things like cutscenes, where standard game operation is superseded.

For even more complexity, they went with a class hierarchy for the action objects which is at least four levels deep!.
The classes, as far as I've been able to determine, are as follows:

• They have a core 'SavedObject' class, which has some internal logic for registering each object instance in a central list. I presume this is for automating saving and loading.
• A child class which I'll call "SmartPointer". This class seems to encapsulate a pointer to a secondary object, and provides core logic for 'fixing' up the pointer reference. I can't be sure yet, but there's a lot of 'fixup' code in the engine, which I presume handles restoring pointer references between objects when a savegame is loaded, and all the objects are re-constructed. This class also implement a basic virtual table of processing and dispatch methods that automatically defer to the foreign object if one is set
• Yet another child class which introduces basic event manager functionality amongst other things
• A concrete fourth child class which seems to further override some of the event manager functionality, and is what gets added to the game's "action list".
  

As you can imagine, all this makes it somewhat different to understand what the blazes is going on. I've also examined the engine from some other points, such as scene loading, and even that seems to be overly complex, with method calling method - they really went in the direction of generalised/generic functionality, with the result that the code seems to be much more complex than it should otherwise need to be.

</whinge>

In any case, the tSage engine was only meant to be a part-time RE effort for when I needed a break from the MADS engine. I did somewhat get carried away with it for the last few weeks, but that was only because the areas I was looking at proved so easy to reverse engineer. Now that I'm running into more complex code, I've decided that the break's over, and I'm returning to work on the MADS engine again. For that, at least, the code seems somewhat simpler, even if it can be a pain to run in the DOSBOX debugger because the segments keep getting shifted around in memory. ;)

For those of you who are Ringworld fans, don't worry, I'll still be working on the engine. It's just there won't be as rapid a progress on it as I'd recently hoped.

Working on Rex Nebular

The Scummvm-misc listing welcomes the new work in progress Dark Seed 2 engine by DrMcCoy. It looks very promising.

I've returned to spending a lot of my time working on the disassembly of Rex Nebular, and implementing it's functionality into the M4 engine. It's likely going to be an extended process, because the game engine is unbelievably complex. It likely comes from the MADS engine being designed as a generic game engine rather than just for single games specifically.

For example, I only just last night disassembled some of the code associated with displaying messages. Any given message is represented by a unique 'Message Id', which in turn loads a message resource that can contain an entire series of control elements for formatting dialogs. A sample message resource for looking at the curtains in the starting room is as follows:

[title25][sentence].Wincing at the "Drapes Of Wrath", you swear
to use them to light the fire when
you burn your ex-decorator at the stake

I'm dreading how complicated the actual script interpreter is going to be. :P

New SourceForge project - Scummvm-misc

It's been a busy month. As those of you who follow the mailing list will be aware, I finished work on an engine module called Gargoyle over a month ago, that allows the playing of Infocom z-code text adventure games. Unfortunately, the consensus was that it really didn't fit in with the ScummVM theme of point and click adventure games. So I created a new project on SourceForge named Scummvm-misc to host the project. But I'd been so busy that I've only now had time to create a proper homepage for the project.

See Scummvm-misc for the project's new website. Rather than just create a project specifically for Gargoyle, I decided to keep the project name generic.. Gargoyle isn't the first non-point 'n click adventure engine, and there may be more in the future. ScummVM provides such a solid base for creating games that can run on multiple systems, I figured it would be good to keep track of other such engines.

The index page I've created also lists all the other publicly known ScummVM engines that are either in development or for which work has stalled. Anybody in the future who'd like to start work on any new engine, and wants the source to be publically available, is welcome to share SVN space on the project.

Finally, two screenshots from the later Infocom games, that used a combination of graphics and text:

Cruise for a Corpse Complete

After many months of work, the Cruise for a Corpse engine plays the PC version of the game all the way through without any bugs.. I was also able to figure out and implement music and sound effects as well, although currently only the PC Adlib player is supported.

The Amiga and Atari ST versions of the game will probably play all the way through, although music and sound effects handling will need to be implemented for them.. I'll leave it up someone else more familiar with those systems to take care of that sometime in the future.

It's when you're diving into fixing and extending engine code like this, the old maxim 'The devil is in the details' comes to mind. Even the smallest mis-print or mistake in the code can cause errors that are hard to track down. It's actually kind of a relief that, as far as I know, it's all over and done with now.

Anyway, I plan to spend the rest of my vacation time (I'm on holiday until the 22nd) getting in some R&R, and some more generic mucking around on ScummVM - this will probably include some time spent working on the MADS disassembly, so people can look forward to further work on Rex Nebular in the near future. :)

Foray into Cruise for a Corpse

Hello everyone. It's been a while since my last blog posting.. I really should get into a better habit of posting updates more often.

Having largely finished adding Discworld 2 support to the ScummVM Tinsel engine some months ago, rather than immediately returning to work on MADS, or some other project, I decided to take a detour and work on the existing 'Cruise' engine, which plays the game 'Cruise for a Corpse'. This was an existing incomplete engine in the ScummVM SVN, which had been languishing for a while without any significant progress being done.

Having been working on it since late February, it's now in a somewhat cleaner and more stable state than it was previously. A lot of bugs have been fixed, and I've also done a lot of cleanup of the code as well, such as giving structure variables more proper names, fixing up variable types, etc.

I'd originally hoped to have reached a milestone of having played the game all the way through to the end before I made this blog posting, but my debugging practices almost demand that I fix these bugs before carrying on with the game.. those remaining bugs tend to be annoying buggers.. I'm currently grappling with two really nasty ones:
* I've got an animation of a moving handle in the engine room that is drawn incorrectly for only two of it's frames.. it could be a problem with the transparency mask for the image, but all fixes I've tried so far screw up the decoding/display of every other image in the game.
* There's a bug in the path-finding code code that's particularly noticeable in the area below the top deck, in that you can walk through walls directly from one exit to another.

I was really on a roll up until I discovered those bugs.. I had reached the 1:30pm segment (the game is divided into time segments that only advance once you've done certain actions) and had fixed several crashing bugs, and was hoping the end of the game was in sight. Now it will have to wait until I've fixed these bugs.

I'm hoping to get Cruise to a nicely completable stage soon. The only other major remaining area in the game after that, apart from some minor ones like getting the game speed exactly the same as the original, will be the sound support. I was given a suggestion that I might be able to copy and paste the code from the previous version of the engine (cine), but whilst the formats seem similar, and I was able to get some sound playing in my experiments, the sounds played are incorrect.

As I've always been on record as saying, music handling is my least favourite area to work in. I may try some further experiments to get it working, and if i still have trouble, I may simply drop it completely, and leave it to anyone else who might be interested in taking it up in the future. At least they'll have a more solid game base to add onto.

On a final note, my holidays for this year were severely delayed, so I'm still looking forward to a month's holiday at some point. I anticipate some productive time spent happily disassembling and implementing games for ScummVM. :)

Discworld 1 Demo support added to SVN

Whilst it's nowhere near as spectacular as adding support for Discworld 2, the latest SVN code now supports the original Discworld 1 Demo.

This demo is somewhat interesting in that it was built at an early stage during the development of the first game. As such, it used a more primitive version of the source code used in the final game. Luckily, it didn't prove too hard to cross-reference a disassembly of the demo executable and identify commonalities between it and the DW1 v1 source code, and from there work out what had changed.

The demo version I used during development was downloaded from Adventure-Treff.

There were actually two demos released for DW1 - this first one contained only the two 'rooms'.. the Fishmonger's and Alley, and the single objective of getting the belt buckle. Please note that this version does not have any sound.

The second demo released apparently contained most of Act I, and featured full voices and SFX. If anyone knows where a copy of that version can be located, I'd be interested in making sure that that version also works with our Tinsel engine.

Discworld 2 support added to SVN

Well, it's been a little over three months since my last posting, and now my current efforts are finally complete.. as of last night, Discworld 2 support has been committed into the ScummVM trunk.

First things first - setup instructions will probably be added into the main README shortly, but for those of you who just can't wait to get it up and running need to do the following steps:
copy the contents of both CDs into a folder on your hard disk, and rename the ENGLISH.* files on both CDs into ENGLISH1.* and ENGLISH2.* respectively. That goes for other foreign language versions the same, with whatever the language name being.

Remember that Discworld 2 isn't officially supported by ScummVM yet. To play it, you'll need the latest daily build from at least 2/12/08, or build it yourself. We also don't have a Discworld category under the ScummVM Bug Tracker, so any issues would be best discussed in the IRC channel or on the forums.

Special thanks go to DrMcCoy, who pitched in and implemented the changes to the sound/music handling for Discworld 2. Also to the rest of the team who participated in the Discworld 1 development, who provided the occasional code additions and testing during integration of the Discworld 2 code.

In case anyone's been wondering about my progress on the M4 engine, well, my apologies, but wouldn't you know that barely a few days had passed after my last blog posting when we got the Discworld 2 source. So I never really had a chance to delve much further into the graphics system like I said I would. Never fret, though, it's still a long term goal to finish disassembling Rex Nebular and start adding support for it, although I'll probably put it on hiatus again if the team gets given the source code for any other game that needs implementing. As fun as reverse engineering is for me, it's nice to work on a project where you can see rapid results from your work.

What's next for me? Now that the code's been publically released, I plan to move onto adding support for the Discworld 1 demo. I've already been spending some off time working on a disassembly of the executable, cross-referencing methods against the Discworld 1 source, and it shouldn't be long before I can start adding demo-specific code to the Tinsel engine.

Oh, and of course, I've still got copies of LittleBigPlanet and Fallout 3 on the shelf waiting to be played. They've been calling out to me in the middle of the night, saying 'Play me, play me', but I've been firm.. I wasn't going to play them until Discworld 2 was finished. Now that it has, I expect to spend some quality time this Christmas traversing the wasteland, and blowing the crap out of stuff. :)