Difference between revisions of "MTropolis"

From ScummVM :: Wiki
Jump to navigation Jump to search
(Mention companies that used/owned mTropolis)
 
(7 intermediate revisions by 3 users not shown)
Line 3: Line 3:
|name=mtropolis
|name=mtropolis
|developer=
|developer=
|companies=Various
|companies=[[mFactory]], [[Quark]]
|usedBy=[[mTropolis/Games|Dozens]]
|usedBy=[[mTropolis/Games|Dozens]]
|dateAdded=August 5, 2022
|dateAdded=August 5, 2022
|release=
|release=2.7.0
}}
}}


'''mTropolis''', (pronounced like the English word "metropolis"), was a multimedia creation tool by '''mFactory'''. It had a userbase of a few thousand during the mid-to-late 90s but was outcompeted by Macromedia's [[Director]]. A few games were built on mTropolis with high profile titles including ''Obsidian'' and ''Muppet Treasure Island''. Though mTropolis lent itself to the development of HyperCard-like point-and-click games, the tech was a fully-featured multimedia project creation suite that was used for various niche projects.
'''mTropolis''', (pronounced like the English word "metropolis"), was a multimedia creation tool by '''mFactory'''. It had a userbase of a few thousand during the mid-to-late 90s but was outcompeted by Macromedia's [[Director]]. A few games were built on mTropolis with high profile titles including ''Obsidian'' and ''Muppet Treasure Island''. Though mTropolis lent itself to the development of HyperCard-like point-and-click games, the tech was a fully-featured multimedia project creation suite that was used for various niche projects.


==Games targeted by the engine==
==Games==
See [[mTropolis/Games]].
See [[mTropolis/Games]].


Line 25: Line 25:
* mTropolis v1.1.2: December 16 1996
* mTropolis v1.1.2: December 16 1996
* mTropolis v1.1.3: September 5 1997
* mTropolis v1.1.3: September 5 1997
* mTropolis v2.0 Beta 3: December 2 1997 (Save-disabled public beta)
* mTropolis v2.0 Beta 3: December 2 1997 (save-disabled)
* mTropolis v2.0: March 1998
* mTropolis v2.0: March 1998
===Demo Versions===
Save-disabled demo versions of mTropolis were distributed on some CD-ROMs.  A mTropolis 1.1 demo was distributed on the cover CD of the MacFormat Issue 47 (February 1997) issue, and a mTropolis 2.0 demo was distributed with MacFormat Issue 63 (May 1998).  There appears to also be a demo version on a mTropolis Developer's Guide CD-ROM published by Ventana Media.
While saves are disabled in these versions, exports are fully functional, making them useful for reverse-engineering the export format.
==Running Unknown mTropolis Titles Using Boot Scripts==
The mTropolis engine can attempt to boot unknown mTropolis titles using a boot script.  The boot script indicates what plug-ins to load and provides a virtualized file system workspace to simulate the post-installation state of a title that uses an installer.  Boot scripts are valid C++ code and are designed to be easily transferrable to the boot.cpp file in the mTropolis engine source code to add support for a new title.
To add a boot script, create a text file named "mtropolis_boot_mac.txt" to boot a Macintosh title, or "mtropolis_boot_win.txt" to boot a Windows title.  You must choose one or the other even for a cross-platform title, since the mode determines how resources are loaded from the player application/executable.
You must also include a player executable, which must be co-located with a "resource" or "mPlugIns" directory if it includes one.
===Virtual File System===
The virtual file system consists of a "physical" path space and a "virtual" path space.  The game always loads from virtual paths.  By default, there is a physical path mount point named "fs" that corresponds to the game directory, and nothing in the virtual space.  If, at the end of the boot script execution, there are no junctions, then one is created that links the "fs" physical path to the virtual root path.
Populating the virtual space otherwise can be done via junctions.  A junction maps a path in the virtual space to a path in the physical space.  For example:
addJunction("MyDir", "fs/SomeDir");
... will make the engine act as if there is a directory named "MyDir" that contains the contents of the directory named "SomeDir" in the game directory.
Note that Windows boot scripts must use "/" as the path separator and Macintosh boot scripts must use ":" as the path separator.
===Boot Script Functions===
addPlugIn(plugIn);
Adds a plug-in.  The plug-in must be one of: kPlugInStandard, kPlugInMTI, kPlugInObsidian, kPlugInSPQR
addArchive(archiveType, mountPoint, archivePhysicalPath);
Adds an archive.  Archive type must be one of: kArchiveTypeMacVISE, kArchiveTypeStuffIt, kArchiveTypeInstallShieldV3.  "mountPoint" point is the prefix that the archive becomes accessible under in the physical file space.  "archivePhysicalPath" is the physical path of the archive file.  For example, if you do: addArchive(kArchiveTypeStuffIt, "installer", "fs:Some Game Installer"); ... then that will create a mapping of physical paths starting with "installer:..." to the files inside of the file named "Some Game Installer" in the game directory.
addJunction(virtualPath, physicalPath);
Maps a file or directory in the virtual path space to a file or directory in physical path space.
addSubtitles(linesFile, speakersFile, assetMappingFile, modifierMappingFile);
Adds subtitle files.
addExclusion(virtualPath);
Removes the file or directory specified by "virtualPath" from the file system mapping.  You can use this to remove files that are causing problems, such as main segments for titles that include multiple main segments (which are not yet supported).
setResolution(width, height);
Sets the resolution to run the game at.  If this is not specified, then the boot code will attempt to determine it using the main segment.
setBitDepth(bitDepth);
Sets the bit depth to run the game at, and report to the game's scripts as the bit depth.  Bit depth must be one of: kBitDepthAuto, kBitDepth8, kBitDepth16, kBitDepth32.  If this is not specified, then the boot code will attempt to determine it using the main segment.
setEnhancedBitDepth(bitDepth);
Sets the bit depth to actually run the game at, if possible.  You can use this to run a title at a color depth better than what the title would allow.
setRuntimeVersion(runtimeVersion);
Sets the runtime version of the game.  Version must be one of: kRuntimeVersionAuto, kRuntimeVersion100, kRuntimeVersion110, kRuntimeVersion111, kRuntimeVersion112, or kRuntimeVersion200.  In particular, you should use this to fix 1.1.2 games not loading by setting this to kRuntimeVersion112, since 1.1.2 broke compatibility with the 1.1.1 plug-in object loader in a way that can't be auto-detected.


==Resources==
==Resources==

Latest revision as of 06:43, 3 June 2024

mtropolis
Engine developer
Companies that used it mFactory, Quark
Games that use it Dozens
Date added to ScummVM 2022-08-05
First release containing it 2.7.0

mTropolis, (pronounced like the English word "metropolis"), was a multimedia creation tool by mFactory. It had a userbase of a few thousand during the mid-to-late 90s but was outcompeted by Macromedia's Director. A few games were built on mTropolis with high profile titles including Obsidian and Muppet Treasure Island. Though mTropolis lent itself to the development of HyperCard-like point-and-click games, the tech was a fully-featured multimedia project creation suite that was used for various niche projects.

Games

See mTropolis/Games.

History

mTropolis was released to the public at 1995's Macworld Expo in San Francisco. The mTropolis "authoring system" was designed for Mac System 7 and supported both 68K and PowerPC CPUs. Despite the Mac-centric development ecosystem, runtimes or "playback systems" were available for Mac and Windows. A web target and accompanying Netscape plugin was also developed.

mFactory's assets were purchased by Quark in 1997 who released mTropolis v2.0 in 1998. This was a final update and the end of all support for the product. A usergroup attempted to purchase the mTropolis IP and possibly make it open-source but negotiations fell through.

Versions

  • mTropolis v1.0: January 1995
  • mTropolis v1.1: May 1996
  • mTropolis v1.1.1: October 10 1996
  • mTropolis v1.1.2: December 16 1996
  • mTropolis v1.1.3: September 5 1997
  • mTropolis v2.0 Beta 3: December 2 1997 (save-disabled)
  • mTropolis v2.0: March 1998

Demo Versions

Save-disabled demo versions of mTropolis were distributed on some CD-ROMs. A mTropolis 1.1 demo was distributed on the cover CD of the MacFormat Issue 47 (February 1997) issue, and a mTropolis 2.0 demo was distributed with MacFormat Issue 63 (May 1998). There appears to also be a demo version on a mTropolis Developer's Guide CD-ROM published by Ventana Media.

While saves are disabled in these versions, exports are fully functional, making them useful for reverse-engineering the export format.

Running Unknown mTropolis Titles Using Boot Scripts

The mTropolis engine can attempt to boot unknown mTropolis titles using a boot script. The boot script indicates what plug-ins to load and provides a virtualized file system workspace to simulate the post-installation state of a title that uses an installer. Boot scripts are valid C++ code and are designed to be easily transferrable to the boot.cpp file in the mTropolis engine source code to add support for a new title.

To add a boot script, create a text file named "mtropolis_boot_mac.txt" to boot a Macintosh title, or "mtropolis_boot_win.txt" to boot a Windows title. You must choose one or the other even for a cross-platform title, since the mode determines how resources are loaded from the player application/executable.

You must also include a player executable, which must be co-located with a "resource" or "mPlugIns" directory if it includes one.

Virtual File System

The virtual file system consists of a "physical" path space and a "virtual" path space. The game always loads from virtual paths. By default, there is a physical path mount point named "fs" that corresponds to the game directory, and nothing in the virtual space. If, at the end of the boot script execution, there are no junctions, then one is created that links the "fs" physical path to the virtual root path.

Populating the virtual space otherwise can be done via junctions. A junction maps a path in the virtual space to a path in the physical space. For example:

addJunction("MyDir", "fs/SomeDir");

... will make the engine act as if there is a directory named "MyDir" that contains the contents of the directory named "SomeDir" in the game directory.

Note that Windows boot scripts must use "/" as the path separator and Macintosh boot scripts must use ":" as the path separator.

Boot Script Functions

addPlugIn(plugIn);

Adds a plug-in. The plug-in must be one of: kPlugInStandard, kPlugInMTI, kPlugInObsidian, kPlugInSPQR

addArchive(archiveType, mountPoint, archivePhysicalPath);

Adds an archive. Archive type must be one of: kArchiveTypeMacVISE, kArchiveTypeStuffIt, kArchiveTypeInstallShieldV3. "mountPoint" point is the prefix that the archive becomes accessible under in the physical file space. "archivePhysicalPath" is the physical path of the archive file. For example, if you do: addArchive(kArchiveTypeStuffIt, "installer", "fs:Some Game Installer"); ... then that will create a mapping of physical paths starting with "installer:..." to the files inside of the file named "Some Game Installer" in the game directory.

addJunction(virtualPath, physicalPath);

Maps a file or directory in the virtual path space to a file or directory in physical path space.

addSubtitles(linesFile, speakersFile, assetMappingFile, modifierMappingFile);

Adds subtitle files.

addExclusion(virtualPath);

Removes the file or directory specified by "virtualPath" from the file system mapping. You can use this to remove files that are causing problems, such as main segments for titles that include multiple main segments (which are not yet supported).

setResolution(width, height);

Sets the resolution to run the game at. If this is not specified, then the boot code will attempt to determine it using the main segment.

setBitDepth(bitDepth);

Sets the bit depth to run the game at, and report to the game's scripts as the bit depth. Bit depth must be one of: kBitDepthAuto, kBitDepth8, kBitDepth16, kBitDepth32. If this is not specified, then the boot code will attempt to determine it using the main segment.

setEnhancedBitDepth(bitDepth);

Sets the bit depth to actually run the game at, if possible. You can use this to run a title at a color depth better than what the title would allow.

setRuntimeVersion(runtimeVersion);

Sets the runtime version of the game. Version must be one of: kRuntimeVersionAuto, kRuntimeVersion100, kRuntimeVersion110, kRuntimeVersion111, kRuntimeVersion112, or kRuntimeVersion200. In particular, you should use this to fix 1.1.2 games not loading by setting this to kRuntimeVersion112, since 1.1.2 broke compatibility with the 1.1.1 plug-in object loader in a way that can't be auto-detected.


Resources

External Links

Articles

Emulating a 68K or PPC Mac to Run the mTropolis Authoring Software

The authoring software isn't needed to run any games though it may be useful for research about the engine.

Other