Douglas Adams' Starship Titanic would be a cool addition. It's like a mixture of AGI text input with the Feeble Files' technique of fake 3D through use of still pictures and video files. (There is no actual proper 3D in the game, which makes it more ScummVM than Residual.)
I think (without too much expierience, so I may be wrong) that this would be a relatively easy game to include. The graphics just works like:
still picture ---> still picture with video on top ---> video
And I know that no-one will work on a game's engine unless it's of personal interest to them. I just wanted to bring Starship Titanic up.
Graxer wrote:Douglas Adams' Starship Titanic would be a cool addition. It's like a mixture of AGI text input with the Feeble Files' technique of fake 3D through use of still pictures and video files. (There is no actual proper 3D in the game, which makes it more ScummVM than Residual.)
I think (without too much expierience, so I may be wrong) that this would be a relatively easy game to include. The graphics just works like:
still picture ---> still picture with video on top ---> video
And I know that no-one will work on a game's engine unless it's of personal interest to them. I just wanted to bring Starship Titanic up.
As always, the largest chunk of work when adding a game is not the game's resources (i.e. backgrounds, sprites, sounds etc), but the actual game logic itself
md5 wrote:As always, the largest chunk of work when adding a game is not the game's resources (i.e. backgrounds, sprites, sounds etc), but the actual game logic itself
... which would appear to be fairly hard-coded into the game.
md5 wrote:As always, the largest chunk of work when adding a game is not the game's resources (i.e. backgrounds, sprites, sounds etc), but the actual game logic itself
... which would appear to be fairly hard-coded into the game.
which means that there is almost no chance of getting support for it in scumm, i would imagine.
md5 wrote:As always, the largest chunk of work when adding a game is not the game's resources (i.e. backgrounds, sprites, sounds etc), but the actual game logic itself
... which would appear to be fairly hard-coded into the game.
which means that there is almost no chance of getting support for it in scumm, i would imagine.
Not necessarily. You would "just" need to find someone dedicated and willing enough to work on it as it's a very arduous task.
clone2727 wrote:Not necessarily. You would "just" need to find someone dedicated and willing enough to work on it as it's a very arduous task.
You mean "reverse engineer the whole thing from play experience", right?
I think he means "reverse engineer the whole thing from decompiling it, graphing out and studying all the functions/opcodes, and rebuilding them from scratch".
clone2727 wrote:Not necessarily. You would "just" need to find someone dedicated and willing enough to work on it as it's a very arduous task.
You mean "reverse engineer the whole thing from play experience", right?
I think he means "reverse engineer the whole thing from decompiling it, graphing out and studying all the functions/opcodes, and rebuilding them from scratch".
KuroShiro wrote:
I think he means "reverse engineer the whole thing from decompiling it, graphing out and studying all the functions/opcodes, and rebuilding them from scratch".
I guess disassembling rather than decompiling though ;-).
Sorry for continuing off-topic, but for me this is kind of an interesting question.
If you rewrite the logic yourself, it may take longer but you are sure you CAN finish. The process may be less challenging but also a lot less frustrating. The result is also cleaner and easier to maintain and fix.
If you go for disassembly there is no guarantee of anything because the thing may be just too complex to figure out.
Giving up after months of frustrating work is not a nice prospect.
Or lat least, so it seems to me. I am by no means an assembly expert, so maybe I am just not knowledgeable enough.
KuroShiro wrote:
I think he means "reverse engineer the whole thing from decompiling it, graphing out and studying all the functions/opcodes, and rebuilding them from scratch".
I guess disassembling rather than decompiling though .
Indeed. Been a while since I've done any programming.
And I would imagine that trying to reprogram a game engine just based on gameplay experience, with no knowledge of the engine internals (especially one with a lot of hard-coded logic) would border on impossible.
It is possible, though quite difficult; and you must be very, very, *very* precise and controlled to make sure you don't miss any details etc. And even then it's quite likely that you missed some little nuance, which can hurt the overall thing badly, in ways you may not have forseen.
Anyway, the Exult project started out, AFAIK, mostly based on this approach.
fingolfin wrote:Anyway, the Exult project started out, AFAIK, mostly based on this approach.
Considering how approximate the gameplay of Exult was in the early days, you're probably right. I think actually working out usecode came much, much later on.
Usecode is only part of the story for Exult. It did support Usecode early on, but many things, e.g. the combat system, involve many parameters and behaviors which are *not* encoded into usecode scripts. I.e., they were hard coded.
.
