The aim of this article is to show those users who wish to port games made with previous versions of GameMaker (7.0, 8.0 and 8.1) onto the newer GameMaker:Studio the initial steps necessary. As such, it covers some of the major changes made between versions, and gives some workarounds that can be used to fix any issues that these changes have caused.
However, before getting started, it is worth noting that porting games made with previous versions of GameMaker onto GameMaker:Studio will be more difficult the more complex the game you are porting. the differences between versions stack up the more complex your code base, so it may be that it is better to finish your game in the previous version and keep your GameMaker:Studio for new projects only.
Importing Your Game Into GameMaker:Studio
Actually adding your game to GameMaker:Studio is a simple case of using the Import dialogue. So, from the main splash screen, choose the Import Tab, and then from the Filter Options (at the bottom right of the tab) you can select the legacy file format required. now just browse to the folder location and import the game.
You can also perform the same action from the main IDE using the File drop down menu and selecting Import Project. Again you will need to select the file type to filter from the dialogue to see the legacy files supported.
When you import your game, you may get an error window popping up to inform you of any missing extensions (see below). Closing them will return you to the GameMaker:Studio IDE and before doing anything else, you should click the green "Run The Game" button to see how the port has gone.
If the game is fairly basic then you should have no problems and it will run as before, however this is very much a "best case scenario". The expected result is that you will be presented with a list of Compile Errors telling you that certain functions or scripts are unknown to the IDE.
How large the list is will depend on many factors, but you will have to fix everything that appears here for your game to run correctly on GameMaker:Studio. This is made easier to work on by the fact that you can click on each individual error and it will automatically open the object or script that has the problem, giving you easy access to the problem code.
As for fixing the issues themselves, that will depend greatly on what the error is and the way your game is structured, but the rest of this document outlines the initial and most common ones and gives you a starting point to get them fixed.
The first errors that you may get will be related to any extensions that you have used in your game, with a pop up window informing you of the extension that is missing. Now, fixing this will depend on the type of extension that was used, as well as the target platform you wish to target your game at.
The target platform issue is an important one, as GameMaker:Studio's focus is cross-platform game development. This means that extensions using dlls (dynamic link libraries) can only be used on the standard Windows export, so if you are planning to port your game to (for example) Android, you cannot use any dll based extensions.
NOTE: Even on the Windows target, you may not be able to use dlls if you are planning on releasing to the Steam Workshop. Valve considers these a security issue and will not permit any game using dlls to uploaded.
This is a difficult one to work around, especially if you plan to go cross-platform. The solution will depend on what the dll actually did in your game... If it was for something like 3D (eg: GMOgre.dll) then you may not be able to continue. However for things like pathfinding, encryption, certain graphics effects (like shaders) etc... Most of these can be done in GameMaker:Studio using the built in functions.
Bare in mind that GameMaker:Studio compiles to native code, unlike previous versions which required a runner, so if you chose a dll to help performance issues, then the normal GML way of doing it may now be a perfectly valid option, and GameMaker:Studio now has encryption functions, shaders, buffers and a host of other features that can be used to substitute many of the commonly used dlls for legacy versions.
Many extensions are simply based on GML and use the existing functions to create more complex functions that are easier to use. These GML extensions can also use constants to extend the built in constants list. No matter whether the extension added constants or added functions to GML, these can still be used on all target platforms, since they will be compiled into the native code for your game.
What you will need to do is add them back into your game using the extension editor in the GameMaker:Studio IDE. To do this you will need to right-click on the Extensions asset from the resource tree on the left, then select Add Existing Extension from the pop up window. This will then show the extensions editor. Clicking the Install button, will then take you to a file explorer where you can browse to the extension and add it to GameMaker:Studio.
Once that has been done, selecting the extension from the list on the right and clicking the arrow button will add the extension to your game, placing it in the "Active packages" section. Clicking on Okay in the editor will close its window and add the necessary extension functions and constants to your game, each of which can now be accessed from the Extensions asset in the resource tree. They will also be colour coded in the code editors and shown in the list of available functions and constants (you can check these from the Scripts drop down menu at the top of the IDE).
GameMaker 8.0 and 8.1 introduced Triggers to the event list. These were basically boolean checks that you could customise as events, with the idea being that they would give newer users to the product a help bridging the gap between code and DnD. However the Trigger Event has been obsoleted in GameMaker:Studio for performance reasons and due to the fact that it didn't really help much and actually confused many users.
So what if you have used Triggers in your game? Well the easiest thing to do is convert the triggers into Scripts and then call them from the appropriate Step Event. To do this you can go into the trigger in GM8.1 and select the "Use Code Editor" button.
This will open the trigger code in the editor and from there you can save it out as a txt file (click the Save icon at the top). Now, in GameMaker:Studio, you should create a new script asset in the resource tree, and give it the name of the Constant you defined for your Trigger in GM8.1. This will be the script handle for calling the script in GameMaker:Studio. Now simply load the text file into the code editor by clicking the Load icon at the top of the window.
In your game, you will now need to go through each of the objects that used this trigger and call the script in the appropriate Step Event, placing the code after the check. For example, taking the trigger "trig_room_edge" shown in the image above above, you would have something like this in the Regular (Middle) Step Event once you have imported it as a script into GameMaker:Studio:
x = room_width / 2;
y = room_height / 2;
In this way you can conserve all your triggers as scripts and build up a library of them which can then be used in later games you create (as you could with triggers).
GameMaker:Studio no longer supports built in transitions of any kind, meaning that any transitions you set using the Room DnD actions (from the Main Action Set 1 tab) will not be shown. This is not necessarily game breaking, but it does mean that you may have to think about coding your own transitions, using a controller object along with sprites, shaders and surfaces to create your graphical effect.
Also note that the four special functions and the constants that they used to control transitions in code are also obsolete and will have to be removed from your game for it to run.
While most of the DnD Actions from the object tab remain, there have been a few removed from GameMaker:Studio due to them being incompatible with all target platforms, inefficient, or causing unacceptable overhead when being called. Below you can find the list of these actions (along with the Action Tab they can be found on) and a brief suggestion of what to do to replace or workaround the job they did in previous versions.
- Rooms (Tab Main1) - These still function as before but without any type of transitions (see above section).
- Timing (Tab Main2) - The Sleep action has been removed. This blocks the runner and will cause most OS to think the game has crashed. To get around this, you will need to make your own pause system or use alarms (for example).
- Info (Tab Main2) - Splash screens, including the Game Information splash window, can no longer be shown for the same reasons that the Sleep action has been removed (see above). To get around this, please see the Obsolete GM7 GM8 Functions And GameMaker-Studio article, the section headed Messages and Splash Screens, or you could also use the new Open URL action to open a web page and use that to display any information required.
- Score (Tab Score) - There is no longer any option to draw the built in highscore table. This means that you will have to draw your own using code. See the section headed Messages and Splash Screens in the Obsolete GM7 GM8 Functions And GameMaker-Studio article for further information.
- CD (Tab Extra) - All functions relating to to the CD have been removed from GameMaker:Studio. These are now obsolete and of little or no use to a cross-platform tool, especially given the way technology has advanced.
- Drawing (Tab Draw) - Nothing has been removed from this action set, but a new action, Draw Self, has been added. This action will draw the current objects sprite with all the built-in values - colour blend, alpha, scale etc... - just as it would if the Draw Event had no code and was default drawing.
Importing And Adding Game Assets
GM8 and GM8.1 had their own proprietary format for saving and loading game assets using the *.gmXXX file type (EG: spr_Fish.gmspr). In GameMakerStudio this has been removed and these files are no longer compatible, mainly due to the fact that the *.gmx format makes it completely unnecessary. You may need to load them into an older version of GameMaker and then save them as *.png or *.txt format files to later load into GameMaker:Studio.
You should also be aware that the ability to create resources like sprites and backgrounds using code has been removed, and a number of functions for adding or changing resources in-game have been changed. For further information please see the Dynamic Functions - Game Assets section of the article Obsolete GM7 GM8 Functions And GameMaker-Studio.
For previous versions of GameMaker the exact order of events have been well documented and many users have made games where certain things must happen at certain times based on this. In GameMaker:Studio this is not the case. You can only be assured of the order in which very specific events will occur, while all others may vary depending on the game state, the code, or even the platform being targeted.
Below is the list of those events that will always fire in the same order:
- Create Event of all instances
- Instance Creation Code of all instances (Note! This is the opposite of legacy versions of GameMaker where the creation code fired BEFORE the create event)
- Game Start Event (this will only be run in the very first room of the game)
- Room Creation Code
- Room Start Event of all instances
From then onwards, the only events that will run every step in the same order are the Step Events themselves:
- Begin Step Event
- Step Event
- End Step Event
Treat Uninitialised Variables as 0
Due to the way GameMaker:Studio is built, this functionality simply no longer works, and if you relied upon it in your games, then you will find multiple errors associated with it when porting over. Using it was quite honestly extremely bad practise, as all it did was hide nasty bugs that would eventually cause you issues further down the line.
This means that you will need to go through your entire project and in the Create Event (or wherever necessary) initialise these variables yourself. This is good practice anyway, and not only gets you used to thinking about variable usage (and what is local/global/instance based), but how much memory your using for these variables as well. On top of this, it will save you time in the long run, particularly when you debug as you KNOW what variables exist and you will no longer "miss-type" one without getting an error and wonder why things aren't working.
Due to the nature of GameMaker:Studio, you will find that even once the above issues have been dealt with there will probably be further compiler errors reported when you test your game. These issues are more than likely due to obsolete functions. GameMaker 7.0 and 8.0/8.1 have a number of functions that take over the main game loop (like show_message() for example), or that are incredibly inefficient (particle deflectors, for example) and these have been removed in GameMaker:studio to permit maximum compatibility over all the new target platforms.
What does this mean for you when porting your game? Well, it means that you are going to have to try and work around these functions, either replacing them with new alternatives (like show_message_async()), re-writing your game code in other ways, or simply by removing them altogether.
You can find a complete list of all the obsoleted functions here:
And for further help with converting these functions to GameMaker:Studio, please check the following article: