GM Executables Explained

There has been a lot of interest regarding how Game Maker creates and runs executables, and some possible alternatives, as evidenced by numerous topics regarding this issue posted in the GMC.  In addition to a few knowledgeable and informative posts, there has been a lot of speculation and noise.  A large part of the confusion is a basic misunderstanding of the processes that happen between the pressing of the “Publish game” button and the start of the created game.

In this piece, I will attempt to explain GM’s handling of executables in as much of a non-technical, understandable fashion as possible.  In addition, I will list the pros and cons of compiling your game before runtime, or translating it automatically into an entirely different language.

GM Executables

A Game Maker executable currently consists of two items – your data, or what is actually interpreted and executed, and the runner (written in Delphi), which carries out the actual execution. This is why an empty game still takes up around 2 MB of space – the runner executable is automatically included in every GM .exe.  Without this, your games could not run.

Your data consists of all your code and resources in an encrypted format.  However, this encryption is liable to be cracked, which is what decompilers exploit when extracting your data.  Because your data is wholly contained in GM’s executable, and because it needs to be in a format that can be interpreted by the runner, it can also be “interpreted” by humans, with the help of an outside program.  Smarty explains:

Because the game executable always contains the game data, and because the runner must know how to decrypt that data, essentially a game executable will always be a case of “here is the locked box, and I’ve hidden the key somewhere under it”. YYG could provide a new encryption, but it would only be a matter of time before someone breaks it again.

So why include the data in the first place?

The current method that GM employs in creating an executable version of your game is designed to ease the development process as much as possible.  If you’ve ever had a syntax or other error that halted game operation, you were graced with a nice error message detailing not only what the error was, but where.  In order for this process to occur, the application must have its source code available and accessible.  Without the source code, GM could only tell you that an error occurred somewhere in your code.  Debugging then becomes a much more intensive process.

When a user first publishes their game, their encrypted data and the runner are combined into one executable file.  In order for the game to run quicker, the data is “first parsed into bytecode,” as Smarty explains:

There’s a lot to say for what that means, but let’s make an easy analogy: when I want you to “jump 3 times on your left foot and 3 times on your right foot” I could just shout that to you, or we could have an appointed signal, e.g. waving, so that we don’t lose time by you listening and intepreting what I just said. The engine works in the same way – at runtime it converts the GML script (scripts are always a method to give complex computer processes a syntax meaningful to humans, but computers do not need them) into bytecode, which are series of so-called tokens (the signals) and their parameters. At runtime, it’s faster at executing bytecode than trying to read the GML syntax.

But this is not the same as compilation, Smarty stresses.  Compiling an application involves parsing source code into a machine-readable bytecode, so that it is accessible at a lower level, and thus, slightly faster.  However, your machine lacks the error reporting abilities of a custom-built runner.

After your source code is parsed and your game begins, the runner starts interpreting your game code.

“A runner is basically a bunch of if-else statements. If it sees a particular token [instructions given by your code], it does something,” explains Yourself.

Alternative #1 – Compiling your entire game

A suggestion commonly put forth is to compile the entire game itself, as opposed to letting the already-compiled runner interpret your code.  Your resources would be protected, and it does lead to an increase in speed, but “[you’ll] lose all the ease of use,” as Yourself explains.  As mentioned above, the type of error reporting used by Game Maker would not be possible.

In addition, Game Maker would have to become “a compiler itself.”  This is an enormous and costly undertaking, requiring the writing of instructions that would parse every GM function into machine code.  The benefit/cost ratio would be minimal.

Alternative #2 – Compiling the runner in a different language

As mentioned above, the runner itself is written in Delphi.  When YoYo Games announced that it was being rewritten in C++, wild speculation arose as to whether enormous speed increases would be seen, or even if GM games would now be compiled.  However, both those claims have been debunked, as there is little speed advantage between Delphi and C++, and creating compiled games would not be possible if the runner was simply rewritten in C++.

So why is the runner being rewritten?

“Just portability. Compiled languages don’t have any significant advantages over one another when it comes to speed,” explains Yourself.  In addition, the Glog post announcing the move details YYG’s reasoning:

We’ve really done this work as a start of our program to have Game Maker apps running on other platforms….NOT to see if we can find advantages on Windows.

Alternative #3 – Parsing your game into another language’s bytecode

Another alternative that has been discussed recently is to compile your code into another language’s bytecode, and run your game as an application written in that language.  Among the many benefits put forth would be portability.  A program that compiles to JVM bytecode could be run on any program that has the Java Virtual Machine installed.

However, this is an extremely non-trivial process.  As mentioned above, a specific compiler would need to be written that takes into account every single GM function, and parses it into another language’s bytecode.  This is possible (along with a one-to-one translation of your code into another language), but the cost of undertaking such a project is extremely high.


Despite the speculation surrounding different methods of compiling GM games, one must always remember that, as with anything, there are always trade-offs.  In order to gain more speed, a game developer could program in C++ (or, according to the age-old meme at the GMC, in assembly).  However, a great deal of ease-of-creation is forfeited.  With C++, the drawing area must be rendered manually, as opposed to simply changing an object’s coordinates and seeing it dutifully move across the screen.  The reason Game Maker exists in its current form is to allow for easy, quick game creation or prototyping.  Sacrificing this ease of use makes Game Maker essentially useless, as making Game Maker games work could be as difficult as coding in C++.  At that point, one would be better off simply coding in C++.

Simply put, sure, it’s possible to make Game Maker run faster by compiling it before runtime, or by coding games in a format that makes the more conducive to increasing run speed.  But sacrificing this ease-of-use would be pointless.  If speed is enough of an issue, it may be time to learn another language.  But if you want to create games in a matter of hours instead of days and weeks, Game Maker is the best option.

C++ Runner, GMac, & iPlay update

Almost certainly the result of recent criticisms toward the company, the official glog has been updated twice for the first time in about a month to give progress updates on the current Game Maker related projects.

The glog’s latest post announces that a (limited) private beta of the C++ runner should be available sometime next week. The post also hints to indicate that there are no definite plans to release the C++ runner in the near future even if it works well now and throughout beta testing. Also, for those of you debating whether GM versions will in fact be available for other devices and operating systems, The post refers to Game Maker running on “other platforms” as a plural, almost certainly guaranteeing at least plans for other systems.

Lastly (and somewhat unfortunately), the Mac port of Game Maker has pretty much come to a dead stop for now. Sandy says they’ve “hit a barrier with teh Lazarus toolset” and that very little progress (if any) has been made on the Mac beta. So in other words, don’t expect a beta anytime soon (even though it is already a few months late).

In other news, YoYo Games managed to keep their word this time :). The Firefox 3 compatible Instant Play plug-in (being referred to as iPlay on this site) is now available for download on the YoYo Games website.

Runner & Maker Info

According to a recent post by Sandy Duncan, Game Maker 8 will most likely be re-written in C++, making development for multiple platforms much easier. For now they are simply working on re-writing the runner and porting the ‘maker’ to Mac.

The main goal with the C++ runner is to essentially copy all the functionality of the current runner. When that has been accomplished, additional functionality may be added such as the ability to obfuscate the code, making decompilation of executables much more difficult. The main reason for using C++ Sandy says is for its portability, and not so much for increased performance.

Sandy also notes that there is only a “slight chance” the C++ runner will run games ‘faster’. Since the C++ runner was announced, this ‘chance’ was one of the main reasons the community has been so supportive of the idea.

C++ Runner Beta Slated for February

Sandy at YoYo Games has announced in a recent blog post that a beta of the the C++ runner is scheduled for February, 2008. A Mac beta is expected to be available before the end of this year.

YoYoGames is also planning to require registration for new Game Maker downloads. This is ostensibly to provide better demographics on Game Maker users in order to improve Game Maker.