From ScummVM :: Wiki
Jump to navigation Jump to search


This page is meant as a mini-HOWTO which roughly outlines the steps needed to add a new engine to ScummVM. It does not tell you how to create an engine for a given game; rather it is meant to tell a developer how to properly "hook" into ScummVM.

I will assume that you are at least roughly familiar with ScummVM, and have a recent checkout of our source code repository. Note that it's strongly advised to base your work on the current development version of ScummVM, and not on a release version. This will ease integration of your work.


Essentially, you will have to implement a subclass of the Engine class. Our Doxygen documentation is your friend and should hopefully explain enough about this: Engine class.

You also must hook yourself into the regular ScummVM main build system. Actually, some ports use a custom build system, but their maintainers will usually add your new engine once it has been added to ScummVM.

Finally, you need to make ScummVM aware of your new engine.

Automated Method

There is a tool that automates creating new skeleton engines which works both with make-based systems like *nix/Mac and with Microsoft Visual Studio.

Make-based Systems

Run make devtools/create_engine, then run the devtools/create_engine/create_engine <engine name>, where engine name is the desired engine name.

Visual Studio

If you go to the devtools/create_engine/ folder, you'll see a create_engine.sln solution which you should open and compile. This will create a create_engine.exe executable in the same folder. From the command line prompt, you should then run create_engine with the desired engine name provided as a single parameter. This will create a folder for your new engine as well as set up a batch file in the dists/msvc/ folder with the engine name that you can use as a shortcut to create a ScummVM solution with only that engine enabled.

Common Instructions

Once you've got the skeleton engine compiling, your next step should be to update the placeholder detection entry in detection_tables.h. The easiest way is to choose a file in your game's folder that you think is unique, and change the filename in the detection entry to it. If you then run ScummVM and try to add the game, it should prompt you that an unrecognised md5 for the game has been found, and give you the option to copy it to clipboard. You can do so, and then paste it to extract the md5 and filesize for the file, which can be used to update the detection entry. With this done you should be able to add your game, and run the skeleton engine.

As a second optional step, by default everytime your game starts, you'll get an unsupported game warning dialog appear. If you want to suppress it, locate and open your scummvm.ini file, and find the section added for your game. Then add the following line to it:


Manual Steps

The remainder of this page contains the original instructions for creating an engine from scratch that predate the create_engine tool. They may still be of some use to read if you want to better understand the individual files that make up a ScummVM engine. For this, it will step you through creating a sample "quux" engine.

  1. Add a new directory engines/quux/
  2. Add engines/quux/configure.engine (looking at configure.engine files of existing engines should make it clear what you have to do, Here is more description: configure.engine options ).
  3. Add engines/quux/ (Again, just check out what is done for the existing engines).
  4. Add engines/quux/quux.h and engines/quux/quux.cpp; this will contain your Engine subclass (or at least parts of it).
  5. Add engines/quux/detection.cpp and engines/quux/detection.h; this will contain your game detection entries (see Advanced Detector).
  6. Add engines/quux/metaengine.cpp and engines/quux/metaengine.h; this will contain the plugin interface code (more on that in the next section).

That's it. The difficult part is of course writing the Engine subclass. More on that in the next section!

Important note: Use a C++ namespace for all your work, e.g. "namespace Quux" in this case.

File name conventions

Since of the course of its existence, many people will have to deal with the source code of a given engine (be it to fix bugs in it, modify it to still compile after changes made to the backend code, or to simply add new functionality), it is useful to adhere to various conventions used throughout all engines. Besides source code conventions (see Code Formatting Conventions), this affects filenames. We suggest you use the following names for specific parts of your engine:

ENGINENAME.h Contains your (primary) Engine subclass.
ENGINENAME.cpp Contains at least the constructor and destructor of your (primary) Engine subclass, as well as the implementations of the mandatory (i.e. pure virtual) Engine methods.
detection.cpp Code related to game detection.
metaengine.cpp Contains the implementation of the plugin interface, as described in base/plugins.h.
saveload.cpp Code related to savegames
debug.cpp, debugger.cpp (console) debugger
gfx.cpp (alt: graphics.cpp) Graphics code
sound.cpp Sound code
music.cpp Music code
inter.cpp, logic.cpp, script.cpp Game logic, resp. script/bytecode interpreter

Additionally, the files saved by each engine should be consistent.

  • Saves: If you use the new loadGameStream & saveGameStream methods, these will automatically be created in the form of <targetid>.### (where ### is the slot id). If you want saves to be consistent across all game variants, you should instead provide your own implementation of loadGameState and saveGameState, and create savefiles using the format <gameid>.###.
  • Other files: These should be named <targetid>-<filename> or <gameid>-<filename>. Again the latter when the files can be shared across all variants of the game (an example for these type of files would be when a minigame saves a high score record).

Here, only use the <gameid> scheme if you are absolutely sure that such files can be shared across all (that is every game platform, every game language, every game patch version, every game release, etc.) versions. If you are not sure whether this is the case, then stick to the <targetid> based scheme.

Subclassing AdvancedMetaEngine

Let's implement the plugin interface:
You'll have to create a custom AdvancedMetaEngine subclass. This provides the information and functionality related to the engine that can be used by the launcher without loading and running the game engine, which includes defining keymaps and achievements, listing savegames, and instancing the engine. You'll also have to create a custom AdvancedMetaEngineDetection subclass. This provides the information related to detecting games, which is always included in the main ScummVM executable regardless of whether or not the engine is enabled.

The following example illustrates this. It contains the necessary fundamentals of the details of the games and the code to create the engine, as well as REGISTER macros that register the meta engine with ScummVM. For the Quux example, If you create an empty file named quux.txt, the engine will detect it.

Subclassing Engine

The example code below gives a simple example of an engine. It contains a few important points

  • It initializes the screen at a given resolution
  • It creates a debugger class and registers it with the engine framework. Currently it's only a skeleton defined in quux.h. For a full game, you'd implement it in it's own debugger.cpp and .h files
  • It has a simple event loop
  • It also demonstrates how to read and write savegames

Miscellaneous important: If you end up using the ScummVM GUI manually in your game (g_gui and stuff) you have always to call g_gui.handleScreenChanged() if you received a OSystem::EVENT_SCREEN_CHANGED event, else it could be that your gui looks strange or even crashes ScummVM.

For opening files in your engine, see the how to open files page.

Infrastructure services

Header file common/scummsys.h provides services needed by virtually any source file:

  • defines platform endianness
  • defines portable types
  • defines common constants and macros

Moreover, it deals with providing suitable building environment for different platforms:

  • provides common names for non-standard library functions
  • disables bogus and/or annoying warnings
  • provides a lean environment to build win32 executables/libraries

The common directory contains many more useful things, e.g. various container classes (for lists, hashmaps, resizeable arrays etc.), code for dealing with transparent endianess handling, for file I/O, etc. We recommend that you browse this a bit to get an idea of what is there. Likewise you should familiarize yourself with graphics and sound; for example we already have decoders for quite some audio formats in there. Before you roll your own code for all sorts of basic things, have a look and see if we already have code for that, and maybe also ask some veterans for advice.

Common portability issues

There are wrapper around number of non-portable functions. These are:

 max() -> MAX()
 min() -> MIN()
 rand() -> use Common::RandomSource class
 strcasecmp() / stricmp() -> scumm_stricmp()
 strncasecmp() / strnicmp() -> scumm_strnicmp()
 strrev() -> scumm_strrev()

Also we have predefined common integer types. Please, use them instead of rolling your own:


Additionally ScummVM offers way of recording all events and then playing them back on request. That could be used for "demoplay" mode. But to ensure that it will work for your engine, you have to register your RandomSource class instance. See example engine below.

True RGB color support

If you need to support more than 256 colors in your game engine, please refer to the truecolor API reference page for specifications and initialization protocol.


The copy of this code could be found at

Example: engines/quux/quux.h

#ifndef QUUX_H
#define QUUX_H

#include "common/random.h"
#include "common/serializer.h"
#include "engines/engine.h"
#include "gui/debugger.h"

namespace Quux {

class Console;

// our engine debug channels
enum {
	kQuuxDebugExample = 1 << 0,
	kQuuxDebugExample2 = 1 << 1
	// next new channel must be 1 << 2 (4)
	// the current limitation is 32 debug channels (1 << 31 is the last one)

class QuuxEngine : public Engine {
	// We need random numbers
	Common::RandomSource *_rnd;
	QuuxEngine(OSystem *syst);

	Common::Error run() override;
	bool hasFeature(EngineFeature f) const override;
	bool canLoadGameStateCurrently() override { return true; }
	bool canSaveGameStateCurrently() override { return true; }
	Common::Error loadGameStream(Common::SeekableReadStream *stream) override;
	Common::Error saveGameStream(Common::WriteStream *stream, bool isAutosave = false) override;
	void syncGameStream(Common::Serializer &s);

// Example console class
class Console : public GUI::Debugger {
	Console(QuuxEngine *vm) {
	virtual ~Console(void) {

} // End of namespace Quux


Example: engines/quux/quux.cpp

#include "common/scummsys.h"

#include "common/config-manager.h"
#include "common/debug.h"
#include "common/debug-channels.h"
#include "common/error.h"
#include "common/events.h"
#include "common/file.h"
#include "common/fs.h"
#include "common/system.h"

#include "engines/util.h"

#include "quux/quux.h"

namespace Quux {

QuuxEngine::QuuxEngine(OSystem *syst)
	: Engine(syst) {
	// Put your engine in a sane state, but do nothing big yet;
	// in particular, do not load data from files; rather, if you
	// need to do such things, do them from run().

	// Do not initialize graphics here
	// Do not initialize audio devices here

	// However this is the place to specify all default directories
	const Common::FSNode gameDataDir(ConfMan.get("path"));
	SearchMan.addSubDirectoryMatching(gameDataDir, "sound");

	// Don't forget to register your random source
	_rnd = new Common::RandomSource("quux");


QuuxEngine::~QuuxEngine() {

	// Dispose your resources here
	delete _rnd;

Common::Error QuuxEngine::run() {
	// Initialize graphics using following:
	initGraphics(320, 200);

	// You could use backend transactions directly as an alternative,
	// but it isn't recommended, until you want to handle the error values
	// from OSystem::endGFXTransaction yourself.
	// This is just an example template:
	//	// This setup the graphics mode according to users seetings
	//	initCommonGFX(false);
	//	// Specify dimensions of game graphics window.
	//	// In this example: 320x200
	//	_system->initSize(320, 200);
	//FIXME: You really want to handle
	//OSystem::kTransactionSizeChangeFailed here

	// Create debugger console. It requires GFX to be initialized
	Console *console = new Console(this);

	// Additional setup.

	// Your main even loop should be (invoked from) here.
	debug("QuuxEngine::go: Hello, World!");

	// This test will show up if -d1 and --debugflags=example are specified on the commandline
	debugC(1, kQuuxDebugExample, "Example debug call");

	// This test will show up if --debugflags=example or --debugflags=example2 or both of them and -d3 are specified on the commandline
	debugC(3, kQuuxDebugExample | kQuuxDebugExample2, "Example debug call two");

	// Simple main event loop
	Common::Event evt;
	while (!shouldQuit()) {

	return Common::kNoError;

bool QuuxEngine::hasFeature(EngineFeature f) const {
		(f == kSupportsReturnToLauncher) ||
		(f == kSupportsLoadingDuringRuntime) ||
		(f == kSupportsSavingDuringRuntime);

Common::Error QuuxEngine::loadGameStream(Common::SeekableReadStream *stream) {
	Common::Serializer s(stream, nullptr);
	return Common::kNoError;

Common::Error QuuxEngine::saveGameStream(Common::WriteStream *stream, bool isAutosave) {
	Common::Serializer s(nullptr, stream);
	return Common::kNoError;

void QuuxEngine::syncGameStream(Common::Serializer &s) {
	// Use methods of Serializer to save/load fields
	int dummy = 0;

} // End of namespace Quux

Example: engines/quux/detection.cpp

#include "base/plugins.h"
#include "engines/advancedDetector.h"
#include "quux/quux.h"

// Here is the right place to set up the engine specific debug channels.
// The list must be terminated by the DEBUG_CHANNEL_END macro
static const DebugChannelDef debugFlagList[] = {
	{ Quux::kQuuxDebugExample, "example", "this is just an example for a engine specific debug channel" },
	{ Quux::kQuuxDebugExample2, "example2", "also an example" },

namespace Quux {
static const PlainGameDescriptor quuxGames[] = {
	{ "quux", "Quux the Example Module" },
	{ "quuxcd", "Quux the Example Module (CD version)" },
	{ 0, 0 }

static const ADGameDescription gameDescriptions[] = {
		AD_ENTRY1s("quux.txt", 0, 0),
} // End of namespace Quux

class QuuxMetaEngineDetection : public AdvancedMetaEngineDetection {
	QuuxMetaEngineDetection() : AdvancedMetaEngineDetection(Quux::gameDescriptions, sizeof(ADGameDescription), Quux::quuxGames) {

	const char *getEngineId() const override {
		return "quux";

	const char *getName() const override {
		return "Quux";

	const char *getOriginalCopyright() const override {
		return "Copyright (C) Quux Entertainment Ltd.";

	const DebugChannelDef *getDebugChannels() const override {
		return debugFlagList;


Example: engines/quux/metaengine.cpp

#include "quux/quux.h"
#include "engines/advancedDetector.h"

class QuuxMetaEngine : public AdvancedMetaEngine {
	const char *getName() const override {
		return "quux";

	Common::Error createInstance(OSystem *syst, Engine **engine, const ADGameDescription *desc) const override;

Common::Error QuuxMetaEngine::createInstance(OSystem *syst, Engine **engine, const ADGameDescription *desc) const {
	*engine = new Quux::QuuxEngine(syst);
	return Common::kNoError;


Example: engines/quux/

MODULE := engines/quux
	metaengine.o \
# This module can be built as a plugin
# Include common rules 
include $(srcdir)/

# Detection objects
DETECT_OBJS += $(MODULE)/detection.o

Example: engines/quux/configure.engine

# This file is included from the main "configure" script
# add_engine [name] [desc] [build-by-default] [subengines] [base games] [deps]
add_engine quux "Quux" no