Как я уже когда-то говорил, так уж сложилось, что комьюнити Game Maker в основном состоит из любителей, для которых создание игры на этом движке порой является первым опытом в программировании в целом. Поэтому при написании кода людьми часто допускается множество ошибок, которые в результате кочуют из исходника в исходник, от игродела к игроделу. Мне доводилось работать со множеством чужих исходников; да и самому писать кучу кода, в том числе плохого кода (даже по меркам GML), поэтому я бы хотел поделиться своим опытом и предостеречь начинающих программистов от распространенных ошибок. В этой статье приведены 7 советов по улучшению качества вашего кода (почему 7? Да потому что мне лень придумывать 11).

Соблюдайте стандарты оформления кода!

GML – это, конечно, тот еще мутант. Но это не должно помешать вам соблюдать хотя бы основные стандарты оформления кода. Да-да, я говорю в первую очередь о табуляции. К сожалению, очень часто люди копи-пастят код из каких-нибудь уроков или исходников, а в процессе теряется форматирование кода. И в итоге получается какая-то лапша, равномерно распределенная по левому краю. Не надо так. Определенно, в GM8 не самый удобный редактор кода и имеет некоторые проблемы с табуляцией. Но вам ничего не стоит потратить минуту, чтобы вручную расставить табы! А в проектах на GMS и выше вообще должно быть стыдно не ставить табы, так как там редактор кода проапгрейжен и никак не препятствует нормальным отступам.  
Ну и конечно пару слов о фигурных скобках. Обычно я расставляю их без переноса на новую строку (эдакий JS-стайл):
[code]if (a == b) {
}[/code]
И, как вы могли заметить, я очень люблю выделять условие скобками. Делать это в Game Maker, конечно, необязательно. Но это делает код более читаемым (собственно, во многих ЯП это стандарт)

Выделяйте локальные переменные!

Если для какого-то куска скрипта необходимо ввести новую переменную (например, итератор для цикла), не засоряйте память объекта и объявляйте переменную локально для скрипта.
Делается это очень просто:
[code]var variable;[/code]
В GMS и выше можно вообще сразу же присвоить значение переменной в строке с инициализацией, что очень удобно:
[code]var variable = 32;[/code]

Избегайте глобальных переменных!

Не используйте цикл repeat!

Вообще цикл repeat юзабелен, когда вам надо выполнить строго определенное количество действий без дополнительных условий и итераторов. Но такие ситуации встречаются не так часто. И обычно я вижу цикл repeat там, где должен быть for:
[code]
// Например, такую конструкцию …
var i;
i = 0;
repeat 10 {
    i += 1;
    a[i] = i;
};

// Лучше заменить на цикл for
var i;
for (i = 0; i < 10; i+=1) {
    a[i] = i;
}[/code]

(Если хотите) не ставьте нижнее подчеркивание!

Я сам очень любил так делать, потому что это выглядит довольно красиво в контексте GML. Но когда приходится писать много кода, понимаешь, что постоянно ставить нижнее подчеркивание не очень удобно. Гораздо приятнее использовать названия в стиле Паскаля:
- Любая переменная начинается с маленькой буквы, но при этом каждое последующее слово в этом названии начинается с большой:
oPlayer (вместо o_player), timeToStart (вместо time_to_start)
- А вот название функций (скриптов в GM) должно называться с большой буквы:
Move(), ResetParameter()

Не избегайте ООП!

А теперь немного продвинутых советов. Несмотря на то, что в GML вроде как и есть объекты, реализовано ООП в нем ну очень криво. Для каждого объекта приходится выделять отдельный нод (который, в терминологии GML так и называется – объект), в коем уже понамешано довольно много часто абсолютно ненужной логики, замедляющей работу программы. Поэтому продвинутые пользователи ну очень боятся использовать лишние объекты в своей игре. И это приводит к плохому и неудобному коду.
Например, нам нужно реализовать инвентарь. И у каждого предмета в этом инвентаре должно быть несколько параметров. Совершенно очевидно, что удобно для такого случая создать некоторую сущность с несколькими полями:
[code]
// Create oItem
name = "none";
cost = 0;
sprite = sDefault;[/code]
И в дальнейшем добавлять в наш инвентарь вещи следующим образом:
[code]var item;
item = instance_create(0, 0, oItem);
item.name = "Plumbus";
item.cost = 300;
item.sprite = sPlumbus;

array[0] = item;[/code]
На основе родительского объекта oItem можно создать множество дочерних объектов (например, oWeapon, oArmor, oDrink) и реализовать в них какую-то дополнительную логику, уникальную для того или иного объекта. Например, добавлять к ним уникальные поля, не свойственные другим. Или реализовать пользовательские события, которые бы вызывались при активации итема (что очень сильно разгрузило бы Step для инвентаря):
[code]if (пользователь_активировал_предмет) {
    with (items[selected]) event_user(0);
}[/code]
Но вместо всего этого счастья зачастую создают несколько отдельных структур данных:
[code]item_name[0] = "Plumbus";
item_cost[0] = 300;
item_sprite[0] = sPlumbus;[/code]

Определенно, когда нам надо лишь только вывести на экран содержимое, такая реализация может даже показаться более лаконичной и предпочтительной. Однако, как только появляется дополнительная логика и необходимость расширения, начинается свистопляска, так как работать с десятком массивов строк и цифр не так уж и просто:
- вместо лаконичных событий, приходится обвешивать Step кучей и кучей if’ов.
- хочешь поменять местами предметы в инвентаре? Или просто удалить что-то? Будь добр, обработай сразу 3 массива (а может быть и 10, или даже 20).
- хочешь дополнить код? Переписывай и правь множество отдельных кусков кода (не забудь про if’ы в Step)
По сути, это очевидные преимущества объектно-ориентированного подхода, который крайне полезен при разработке игровой логики. Game Maker предоставляет мало возможностей для написания качественного удобного кода, так что не стесняйтесь использовать то, что есть. И не переживайте особо за производительность. Она не просядет значительно даже от сотни таких вот объектов.

Используйте списки!

Очень язык чесался написать об этом в предыдущем пункте. Но вынесу это сюда. В отличие от ООП, здесь никаких продвинутых знаний не требуется. Более подробно о списках я уже писал в предыдущей статье. Однако, чтобы вам не приходилось куда-то лезть, вот вам основные преимущества использования списков вместо массивов:
- возможность удаления элементов без дополнительной логики
- возможность отслеживания количества элементов без дополнительного счетчика
- возможность вставки в любое место списка

[code]
// Инициализация списка
list = ds_list_create();

// Добавление строки в список
ds_list_add(list, "Sample Text");

// Перебор списка
for (i=0; i<ds_list_size(list); i+=1) {
    show_message(list[! i]);
    // или show_message(ds_list_find_value(list, i)) для GM8
}[/code]