I haven't seen anything mentioned about this game on the forums, by doing a quick search.
From the Wikipedia page, it appears that the game engine was just a specific video player named mTropolis. Doesn't appear that many titles were developed for it either.
As someone who doesn't know anything about the way engines and programs work, is this a difficult one that they developed the game for?
Obsidian by SegaSoft and Rocket Science Games
Moderator: ScummVM Team
-
SnowyThing
- Posts: 3
- Joined: Wed Mar 25, 2009 9:35 pm
I assume you are referring to:
https://en.wikipedia.org/wiki/Obsidian_(video_game)
https://en.wikipedia.org/wiki/MTropolis
Not sure what question you are asking... The reason why they have few games is listed on those pages fairly clearly i.e. the tool went EOL, partly due to various limitations which newer / custom systems transcended.
https://en.wikipedia.org/wiki/Obsidian_(video_game)
https://en.wikipedia.org/wiki/MTropolis
Not sure what question you are asking... The reason why they have few games is listed on those pages fairly clearly i.e. the tool went EOL, partly due to various limitations which newer / custom systems transcended.
-
SnowyThing
- Posts: 3
- Joined: Wed Mar 25, 2009 9:35 pm
-
OneEightHundred
- Posts: 8
- Joined: Sat Mar 19, 2022 5:30 am
Re: Obsidian by SegaSoft and Rocket Science Games
I've been looking in to reverse engineering mTropolis to support Obsidian, so here are some preliminary findings for maybe future use...
Good news: mTropolis data doesn't appear to be compressed or use any sort of complex encoding (except for "mToon" encoding for animations, which I'm not sure of the encoding of), and its feature set is relatively compact. A lot of its assets are just stored as inline files, all of the videos are encoded with Cinepak, and it mostly works via modular object behaviors of which there aren't very many of. It'd probably be possible to reverse engineer its high-level structure without TOO much work and implement its behavior modifiers one at a time.
Bad news: Unlike Director games where XObjects are mostly used for utility functions and basic kit, Obsidian depends on native code extensions for some of its gameplay elements (probably because its scripting capabilities are quite weak). In particular, the code and data for the dictionary puzzles in the first chapter are contained in the "RSGKit" native extension, which is a DLL, so would probably have to re-implement all of them and read the data from the DLL. There are 7 modifiers in RSGKit, 3 related to the Bureau word games, but a few of them it's less clear what they do.
Good news: mTropolis data doesn't appear to be compressed or use any sort of complex encoding (except for "mToon" encoding for animations, which I'm not sure of the encoding of), and its feature set is relatively compact. A lot of its assets are just stored as inline files, all of the videos are encoded with Cinepak, and it mostly works via modular object behaviors of which there aren't very many of. It'd probably be possible to reverse engineer its high-level structure without TOO much work and implement its behavior modifiers one at a time.
Bad news: Unlike Director games where XObjects are mostly used for utility functions and basic kit, Obsidian depends on native code extensions for some of its gameplay elements (probably because its scripting capabilities are quite weak). In particular, the code and data for the dictionary puzzles in the first chapter are contained in the "RSGKit" native extension, which is a DLL, so would probably have to re-implement all of them and read the data from the DLL. There are 7 modifiers in RSGKit, 3 related to the Bureau word games, but a few of them it's less clear what they do.