Making Games in Game Maker: Some General Guidelines

For years, Game Maker has been the most popular game-making development kit used by MFGG members. It's not perfect, but it's still relatively intuitive and affordable for new users, while powerful enough to meet the needs of more experienced developers. In spite of GM's lenient syntax requirements and its ease in building executables, there are still some best practices worth following.

This tutorial isn't intended to guide you through every question you might have while getting started. Instead, this guide focuses on pitfalls commonly encountered by GM users. These guidelines are worth heeding, especially since many of these same principles apply to other programming languages as well.

Appearance

• Steer clear of the boring built-in GM logo for your games! Instead, give your game a unique logo, such as one from the many icon packs available on MFGG. Better yet, you can create your own logo with one of the assorted free icon-making utilities. Be careful when using unusual icon dimensions, however, as some are incompatible with GM.
• Likewise, don't use the default loading screen - it tends to be associated with hastily-assembled games. Display your game's logo or concept art, or do away with the loading screen altogether, especially if your game loads quickly.
• If you're going to add an F1 help screen to your game, please choose a font that's reasonably high-contrast and easy to read.

Coding

• Don't use Drag & Drop. It might be more intuitive for new GM users, but you'll quickly realize that DnD has many severe limitations, and that converting DnD to proper GML can be time-consuming. Use the "Execute Code" box to input all your code, learn the basic GML functions, and you'll have a much easier time in the future.
• Use commenting! Explain the code you write. You don't need to add a comment to every line of code, but do take the time to explain anything that might be confusing, especially scripts, parents, variables, complex collision systems, and external DLLs. Your personal coding style might make sense to you, but proper commenting will make collaboration much easier if you ever share your work with a friend - or if you put your game on the back burner for a few months and later forget how everything works.
• Give descriptive names to all variables. Avoid using vague names like "kk" or "myvariable", and do spell-check them before copying them all over your source!
• Make your code easy to read. Use proper tabbing, especially when using If statements. Trust me - it doesn't take long for untabbed code to become impossible to understand (the old Hello Engine 3 is a glaring example of this). Similarly, don't be afraid to use white space to separate sections of code.
• Be sure to initialize all variables, usually in the Create event of an object. While GML doesn't require you to declare variables when you first use them, failure to initialize variables can cause errors depending on the settings, and it makes debugging a bigger hassle than it has to be.
• Limit your use of global variables. If possible, try to initialize them all in a single object (for example, the title screen) so it's easier to manage them.
• Making a habit of using semicolons at the end of your statements is highly recommended. If you plan to move on to more professional languages, you should be prepared for proper syntax such as this to become a requirement.

Performance

• Generally speaking, all room speeds should be set to 60 FPS. Lower framerates tend to appear jerky, while higher framerates offer no real advantage (and depending on the complexity of the game and your PC's processing power, you might not be able to attain speeds faster than 60 FPS anyway).
• If possible, choose the same screen resolution in every room, especially when using room transition animations. Changing resolutions often causes temporary graphical glitches.
• Always destroy endless-spawning objects when they exit the room or view. A good example of such an object would be Bullet Bills. If you don't, the number of instances will continue rising, which will eventually cause lag.
• Don't use the .WAV audio format for background music. .WAV files are fine for small sound effects, but if you use this format for music, your executable will quickly grow to enormous sizes and consume a lot of memory while the game is running. Larger MP3 files can also cause bloated file sizes.
• Be careful when using Step events, which are very useful but are interpreted every step (usually 60 times per second) of gameplay. Needlessly complicated Step events have serious lag potential. Especially troublesome are Step events for frequently-used objects (like blocks), as seen in the original Ultramario Engine.
• Large rooms with many objects can lag. While proper use of instance deactivation and proper coding habits can improve performance, it's a good idea to split up rooms if they grow too large or possibly make a large parent object for certain collision usage.

Advanced performance optimization

• Use synchronization to avoid tearing may help your game graphics run smooth. If your game doesn't have any graphical tear, disable it.
• If an object does not require precise collision, turn it off in the sprite that the object is using.
• Using slash (/) may be convenient for coding, but it actually takes a tiny bit more processing power than multiplying. For example:

the slower code:

o_object.x = var_1/8 + sin(var_2)/cos(var_2);

to speed it up:

o_object.x = var_1*0.125 + tan(var_2);

• Like the Game Maker manual says: "If you have a covering background, make sure you switch off the use of a background color." That frees a bit of graphic memory.
• When setting variables in other objects, the with statement can be a faster alternative to using a bunch of statements that look something like o_player.hspeed = 2;
• Always close externally loaded files and dlls when their jobs are done. This prevents memory leaks.

Resource Management

• Just as it's important to choose descriptive names for your variables, giving game resources good names (with proper spelling!) is highly recommended.
• Use prefixes to avoid giving overlapping names to resources. For example, instead of giving the name "Goomba" to both the sprite and object of everyone's favorite traitorous mushroom, adopt a standard naming scheme along the lines of "spr_goomba" for sprites and "obj_goomba" for objects. Different programmers use different naming systems, but whatever you do, choose a style and stick with it.
• Organize your resources into folders. Larger, more complex games can easily accumulate thousands of objects, sprites, and sounds, so failure to organize these resources is guaranteed to result in a huge mess.

Security

• GM-made executables can easily be decompiled by those possessing the proper tools. Using the GM Anti-Decompiler tool greatly increases the difficulty of reverse-engineering a game's source code. Better yet, if you use the accompanying Compressor application that's included with the Anti-Decompiler, you can cut the size of your decompile-proof games by a megabyte or more. Always keep backups of your .GMK file if you use these tools, however!
• GM's built-in save system has a number of faults, but one worth noting is its system of dumping the contents of the entire game's memory into the save files. The values written to these files can be viewed and edited with a hex editor or even Notepad, so if you're concerned about cheating, be sure to use a more secure save mechanism.
• Games made in GM are also vulnerable to memory hacking from cheat engines. Some games, like The Purple Coin, have implemented a system to prevent such hacking - which is worth considering if you're making a game with online play or online high score tables.