Please Don't Distribute Games in These Ways

RinkuHero — Fri, 21 Nov 2008 16:30:47 -0700

I don't like to make too many negative posts, but here's a list of the funniest things I've heard recommended in the Game Maker Community forum, Distributing Games subforum.

- Burn a handful of copies of CDs with your demo on them, and leave them in places where somebody might discover them.

- Sell games to trick-or-treating kids who come to your door on Halloween.

- Sell games outside by standing outside of grocery stores and trying to sell them to whoever passes by. "Games, fresh games!"

- Give copies of your games to game stores, and ask them to sell them for you.

- Put 100 Game Maker games on one CD which are normally available for free and sell that.

- Come up with a good idea for a game, make an example of it in Game Maker, and sell it to a big company for millions, and let them distribute it for you.

None of those will work very well.

Annoying Game Maker Habits

RinkuHero — Thu, 20 Nov 2008 22:29:26 -0700

These are the three most annoying misuses of the Game Maker engine to me. If you use Game Maker, please avoid these!

- Stretching the game to full screen. Why do people do this? Can't they see how bad it looks? Either make your game run in a window, or run in real full screen mode with a resolution change, don't stretch it to fit the full screen, because that causes all kinds of distortion and blurriness problems. It also makes games run much slower.

- Using GM's built-in sound capabilities instead of using a .dll. This often produces scratchy sounds, delays when loading sounds, and other problems. It also only supports MP3, MIDI, and WAV -- the first two of which you probably shouldn't be using in a game anyway: MIDI because it sounds pretty awful, and MP3 because it's illegal to use them in a game that gets more than 5000 downloads without a license and because OGGs are superior in terms of video quality to file size. Good sound dll's to use with GM games are bass.dll, fmod.dll, or supersound.dll.

- Not using external resources. Optimally all or nearly all of a game's resources should be external and loaded on startup or on use. Keeping all of a game's resources inside the .exe leads to huge load times and massive overuse of RAM, for no real benefit at all. Some people do it to avoid other people having access to their game resources, but if someone really wanted access they could just use the decompiler anyway.

7 Game Maker Tips (for experienced users)

RinkuHero — Wed, 19 Nov 2008 07:00:02 -0700

Since a lot of my readers probably come from Game Maker communities, I thought I'd write up some tips for that game engine. This is especially geared toward people with some familiarity with Game Maker and GML, and not intended for people new to the engine.

1. GML Console

A lot of people say never to use execute_string(), because it's so slow -- and they're right, but one good use of it is to create a "console" window for debugging purposes: a window which you can bring up to type in some code and have it be executed, without having to exit the game, change the code, and then restart the game. Sure, you could accomplish the same thing by running the game in debug mode, but the game runs slower in that mode and sometimes you weren't really intended to debug anything but want to change a variable on the fly to do some balance tweaking or something. This is fairly simple to set up, here's how to map it to the F11 key (this is what I used in this post's screenshot):

if key_check(vk_f11) execute_string(get_string("Command?",""));

2. Difference Between Directions

Finding the difference between two directions (Game Maker uses a wrapping 360 degree direction system) is common enough that I've used it in every game I've made for it, yet Game Maker gives you no easy way to find that out. So here's what I use; the two arguments are simply the two directions to find the difference between:

var ret_result;
ret_result = abs((argument0 mod 360) - (argument1 mod 360));
if (ret_result > 180)
ret_result = 360 - ret_result;
return ret_result;

3. Nearest Objects

Game Maker comes with functions to find the nearest object or the furthest object of a certain type to a certain position, but often you want the second-nearest or the third-nearest instead, especially when you're searching for the nearest object of the same type as the object calling the function, because the absolute nearest would be the object itself, and Game Maker would just give you that as the nearest object of that type. This comes up often enough that I wrote a script to deal with this problem, here it is. Make sure you create the global.priority_id data structure in the game's initialization somewhere.

// geo_nearest(x,y,object,number)
ds_priority_clear(global.priority_id);
with(argument2) ds_priority_add(global.priority_id,id,point_distance(x,y,argument0,argument1));
repeat (argument3 - 1) ds_priority_delete_min(global.priority_id);
if (ds_priority_empty(global.priority_id))
then return (noone);
else return (ds_priority_find_min(queue));

4. Homemade Collisions

If you code your own collision routines instead of relying on Game Maker's, make sure to check for collisions on the *next* step after the current one, rather than just the current one. I.e. use speed, direction, and current location to calculate where every object will be next step, and prophylactically deal with collisions before they happen. I find this prevents objects getting stuck in each other. Another important thing to keep in mind is that when you're doing bullet collisions and bullets are of a sufficient speed, and objects sufficiently small, the bullets may jump right over their target, and not register as collisions. To avoid this, either have the bullet check for a line collision (with a line parallel to the bullet's movement), or just check a few spots between a bullet's current and previous position.

5. Arrays of Script Identifiers

You can use names of scripts without parenthesis as identifiers for that script, and then use script_execute() to call that function. This may seem useless, but imagine you have an AI set up, where an NPC or an enemy can be in a variety of "states" depending on the current conditions, and have different behavior depending on that state. If each state has a distinct number, you could create an array of script identifiers, so instead of having a complex switch statement for its step event, you could simply use something like "script_execute(AI_step_script[AI_state])" to run the appropriate behavior script for its current AI state.

6. Families of Objects

Game Maker is very object-oriented. The GML language itself isn't an object-oriented language, but Game Maker objects inherit behavior from parent objects, so it's a good idea to use object inheritance. At first you might think that child events overrule parent events -- for instance, if both a child object and a parent object have a step event, only the child's would be run. But then I learned about the "call event" drag and drop icon and the event_inherited() function, and it's amazing how I got along without them. For complex games I recommend setting up a large "tree" of inheritance for your games: one object that refers to all objects, then large families of objects under that, and so on down to distinct subtypes; think of it as a taxonomy.

7. "With"

The with() construction is probably the most underestimated aspect of GML. Using it, you can cycle through every object of a certain type and perform some code as if you were within that object. You can also use "other." inside of a with() construction to refer to the object which set up the with() construction. You can even nestle a with() within a with(), and can even do with(other) to backtrack outside of the with() construct -- as you you're making a hole in a hole. If you keep a nice taxonomy of objects (see #6), remember that using with() on a parent object will also refer to all of its child objects, which can be useful. There are a multitude of nice ways to use with() constructions, I could make an entire post on these varied uses of with(), and perhaps I will eventually.

game maker