Are you looking to produce a generic LD game engine, or is it more of a LD game wrapper for which you write a custom game module in C? The difference, to me, is that the first approach might not require the ROMs directly, whereas the second surely would. In the first case, one would describe in a meta-language, the sequence of turns, percentage chances, required/optional controller moves, etc. The engine would digest them and process them as a native file. In the second case, there might be a processor-level code emulator that was shared amongst games with similar innards, then a game-specific module that would depend on the arcade-CPU-emulator, but send display/LD control events up to the LD game engine.
The first approach would only really be useful for those games like DL and SA that have been throughly disassembled and documented. In fact, they could probably be mostly done by a Perl script that reached into the ROMs and digested the existing tables that the original arcade game itself uses. Throw in some attract-mode code and you'd have a game very close to the original. You could even throw the DLE and SAE "upgrade" ROMs at them and get the desired results. This is kinda like what we did in the old days with the Scott Adams and Infocom adventures - wrote our own engines to use the original data files.
The second approach is more like a modular Daphne - take a Z-80 or 6502 or 68000 (American Laser Games) emulator, turn it into a library, then attach a DL-specific, or SA-specific, or Mad Dog McCree-specific module that knows what the I/O looks like to translate the direct accesses into events that get passed up to the engine as LD-seek or MPEG-display events. Presumably, joystick/keyboard events would be handled at the engine level and passed down as I/O events, a-la Amiga's Intuition loop - events are injected into a queue by whomever, and removed by a different whomever, so that nobody has to know details of the other - just that part A produces events generated by the player pushing on stuff and part B produces display events generated by the code in the ROMs detecting certain conditions or lack of player-movement events. In this model, A probably consumes events inserted by B and vice versa.
Adding a "real" scoreboard for DL and SA (one of my personal favorite things about Daphne) is a matter of writing a scoring event consumer/client that sits in the queue after B sends scoring events, but before A consumes them. This scoreboard client could either remove events from the queue or leave them in place so that you would see scores both on the PCs screen or not. In fact, this scoreboard client could remove the event from B and insert its own event so that the engine could know that there _is_ a real scoreboard out there and to not worry about displaying score data if the player is using an MPEG file, for example.
Using an input event loop in this manner allows you to not have to code for special cases - you set up a chain of events, and as long as you see the expected events, it doesn't matter how they go t there or not - easy to describe, easy to document, easy to test. Lots fewer "if/else" clauses, too. Less work to extend functionality.
Comments?
-ethan
P.S. - since there's LD-drivers for the Sony LDP-1500 for AmigaVision, I wonder how hard it would be to write a DL emulator based on the event chain from the DL ROMs... I could do it, but then who could run it?
<font size=-1>[ This Message was edited by: Ethan on 2002-03-25 09:48 ]</font>