Game Maker 7 Pro Price to Increase

Sandy Duncan announced on the YoYoGames glog today that the price for Game Maker 7 Pro will increase in February due to the ever changing value of currencies.

No specific prices were mentioned in the post, but Duncan did however say that customers in the UK will be the most affected by the price change. Duncan noted that the value of the euro had dropped by almost 50% since the last time YoYo Games had evaluated it, which means that the price of Game Maker could potentially jump to double of what it is right now.

On a side note, Sandy Duncan  noted in the comments of the article that work on Game Maker 8 has not yet started.

YoYoGames Help Desk Performance

Sandy Duncan has said on the official YoYoGames Glog that the Help desk on YoYoGames has been answering 95% of submitted help tickets within 24 hours, which has improved drastically in the last two weeks.

Mr. Duncan also said that using Softwrap for DRM in Game Maker 7 is “high on [his] list of ‘things we should have done differently'” but its not going to change any time soon. This brings up past rumors that Game Maker 8 (or future versions of 7) might not include Softwrap or any DRM at all.

GMAC Beta – Signup now

Announced today on the YoYo Games glog was the upcoming private beta program for the highly anticipated Mac version of Game Maker.

The testing will start out as a closed private beta that users can signup for by e-mailing with their contact details, GMC and YYG usernames. The beta program is due to begin by the end of next month and it may be some time before a public beta or final version will be out.
The YoYo Games team is currently looking for those who have a Mac running OS X Leopard, Windows only users need not apply. As for hackintoshes and emulators, it couldn’t hurt to try but I doubt there will be any promising results.

Sandy Duncan also commented to say that although the Mac port should run well on UNIX based systems such as those running BSD, there are no current plans to provide support for UNIX or Linux at this time.

GM for Mac – Soon…ish

In Sandy’s latest post on the official YoYo Games glog, there has been some discussion about the on-going Mac version of Game Maker that was first expected to be released as a beta way back in March.

According to Sandy, he has an alpha version of the software running on his mac right now and it’s ‘going very well.’ Apparrently there are still a few bugs that need to be worked out with the Lazerus team before its release, but Sandy hopes that it will be available soon (as a beta), possibly as early as next month. He does however say ‘don’t quote me on it’, so no guarantees at this point.

As we understand it, the Mac version will be identical to the Windows version of Game Maker in every way except that the former will lack support for third party extensions and DLLs as these run only on Windows. What this means is most games built to run on Macs will run fine with the Windows counterpart, but some games built for Windows that do use the extensions and DLL functionality won’t run on macs. There is no information at this point on whether an equivalent functionality will eventually be built-into the program for mac users.

It is also unclear whether each GM program will allow you to create binaries for both Windows and Mac or whether you will need to physically have a Mac and Game Maker for Mac to create a Mac version of the game (or vice versa). The licensing of the software also has not yet been revealed, there is still speculation as to whether the purchase of 1 license will grant use of both GM for Windows and Mac or whether users will have to purchase each software package separately.

InstantPlay Now Vulnerable to Decompiling

InstantPlay tab of the decompiler.

InstantPlay tab of the decompiler.

This morning an update to the GM Decompiler was released, this time with the ability to decompile InstantPlay games and extract GM7 extensions from games. The update also defeats some methods devised for protecting games from the old decompiler (typically using a hex editor to tamper with the PE).

InstantPlay decompiling automatically detects games you have used via InstantPlay, which are stored in a folder under My Documents. Users are presented a list of games detected and the rest is automatic.

Version two of the infamous decompiler is by the same author (Clam), and includes the same vengeful message about GMK encryption (which was designed to defeat third-party projects).

GMNews and Scorptek do not endorse copyright infringment. This news posting is for informational purposes, and links to the decompiler will be deleted.

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.

GM TV Startup Wars

Recently there has been a trend of users starting up or planning Game Maker based TV/video services.

aracnoX is looking for support for a ‘YYGTV’ network where viewers can play games, and “watch pivot animations or flash animations”. How exactly this is classified under ‘TV’, we’re not too sure.

Another user, Ariodas, wants to use the already popular ‘GMTV’ name for a Game Maker application that will essentially work like a TV set-top box allowing you to view other user’s Game Maker TV channels.

Users are going as far as to claim their own channels on these TV networks, one user reportedly saying, “GM Tutorials? Chanel 23 Please.”

But it’s not just Game Maker tv shows that are starting up, YouTube is also becoming flooded with Game Maker tutorial videos almost every hour of the day (see below).

It is uncertain whether this sudden increase in GM video services is the result of inspiration from the latest GMTV Episode 4 by Dan Eggers.