Game Maker - создание игр | HellRoom Games

Подборка правил по оптимизации проектов, проверенные на собственной "шкуре". К каждому пункту прилагается логическое обоснование, актуальность для разных версий GM и значение прироста производительности. Указанные тестовые данные могут отличаться в связи с разной сложностью кода и различными платформами (GMS). Для теста брались простые конструкции типа repeat (1000) {a=10;}. В любом случае, каждый может проверить эффективность на себе, о чем рассказано в последнем пункте статьи.
Некоторые значения прироста производительности могут показаться слишком ничтожными, но при больших количествах таких "мелочей" это может стать достаточно заметным. Привычка формировать код сразу удобным и эффективным - хорошая привычка.

1. Лесенка из условий.
  Разбивать условия, объединенные логическим оператором && (and), на несколько последовательных условий.
Пример:  Почему работает: при первой записи программа проверяет все условия в любом случае. Вторая запись уменьшает количество проверяемых условий - не всегда проверяются все условия, а, как минимум, одно.
  Актуально: для GM8.1 и ниже, и старых версий GMS. В новых версиях GMS разницы нет благодаря Short-Circuit, опция в Global Game Settings - General.
  Прирост: происходит в определенных ситуациях и зависит от сложности условий.

2. (следует из предыдущего) Ступеньки лесенки условий.
   При проверке составных условий на первое место ставить такие условия, которые реже всего будут истинными.
  Почему работает: условие реже всего выполняется, значит, следующие за ним условия будут тоже реже выполняться. Сокращается количество проверяемых условий.
  Актуально: всегда и везде.
  Прирост: происходит в более частых определенных ситуациях.

3. Сокращение количества операций.
  ^{[здесь был еще неэффективный код]}
  При проверке условий, то есть логических переменных, не сравнивать их еще раз с логическими константами. Другими словами, сокращать количество выполняемых операций.
Пример:  Почему работает: используется уменьшение количества операций, производимых в действии. Например, if life=true - здесь операция сравнения переменной с true лишняя (аналогично с if (life=true)=true), можно сократить, взяв лишь значение самой логической переменной.
  Актуально: всегда и везде в разной степени.
  Прирост: GM8.1-: +11%. GMS: +2%.

4. Лучше готовый результат, чем снова функция.
  Если в одном коде предполагается неоднократное использование одной и той же функции (например, instance_nearest) с одними и теми же аргументами, то запишите ее результат в переменную, а при использовании обращайтесь к этой переменной.
Пример: Кстати о переменных: если в коде необходимо использовать дополнительные переменные (как target), но которые впоследствии не потребуются (в качестве локальных переменных объекта), используйте временные переменные, как это показано в коде выше.
Если вспомогательные переменные всё-таки нужно сохранить на некоторое время вперёд или для других событий, после чего она не будет нужна - обнуляйте ее значение (особенно касается строковых переменных).
  Почему работает: обращение к готовому числу намного проще, чем выполнение функции. Представьте, что point_distance - это формула Корень(Квадрат(х2-х1)+Квадрат(у2-у1)). Очевидно, что взятие готового числа будет выполняться быстрее, чем выполнение этой функции.
Временные переменные, определяемые словом var, существуют только в выполняемом скрипте и уничтожаются при завершении скрипта, таким образом освобождая память.
  Актуально: всегда и везде.
  Прирост: GM8.1-: +15%. GMS: +30%.

5. Совершенствование структуры.
  Если есть возможность не использовать скрипты - не используйте скрипты. Если можете перевести кнопки в код - переводите. Если выполнение определенных действий не особо важно для того, чтобы их выполнять в шаге - выполняйте их в циклически заводящемся сигнале (раз в 2 шага, раз в секунду, но не каждый шаг).
Есть еще такие функции, которые не обязательно выполнять в шаге (или рисовании, что то же самое), а достаточно выполнить один раз. Особенно часто встречается функция draw_set_font, указанная в рисовании. Ее можно выполнить один раз в создании, как и некоторые другие функции, которые "что-то устанавливают", а не "выполняют (рисуют)" - draw_set_color, draw_set_halign, draw_set_circle_precision и другие со словом set.
  Почему работает: выполнение скрипта в шаге (например) происходит медленнее, чем просто код в шаге. По некоторым источникам, вызов скрипта в 5 раз медленнее использования обычного кода ^{(не подтверждено)}.
Кнопки работают медленнее, чем код, и к тому же могут выполнять лишние действия (для замены спрайта достаточно одного sprite_index=sprite, а кнопка выполняет еще два дополнительных действия). Между вызовом скрипта с помощью кнопки или в коде разницы нет.
Вынос действий из шага в сигнал: то, что проверки выполняются не каждый шаг, а реже, уже само говорит за себя.
  Актуально: во всех версиях Game Maker в разной степени.
  Прирост: Не скрипты: GM8.1-: +22%. GMS: +10%. | Не кнопки: GM8.1-: +80%. GMS: минимальный. | Сигнал: зависит от периода, всегда ярко выражен.

6. Стандартные события.
  Для управления желательно использовать стандартные события клавиш, вместо проверки кода в шаге (keyboard_check). Аналогично со столкновениями с дополнительным эффектом улучшения производительности, когда столкновения не происходит (а код продолжает в это время проверять).
  Почему работает: стандартные события обрабатываются быстрее, чем код в шаге.
  Актуально: во всех версиях Game Maker.
  Прирост: Управление: GM8.1-: +66%. GMS: +60%. | Столкновения: GM8.1-: +38%. GMS: +30%.

7. Формирование спрайтов.
  Отключать точную проверку столкновений у спрайтов, если нет в ней особой необходимости.
Обрезать лишнюю пустую рамку вокруг спрайтов.
  Почему работает: при точной проверке столкновений необходимо создавать маску по очертаниям спрайта. Если ее выключить, то берется прямоугольник, либо вписанные в него круг или ромб (можно сравнить с пунктом 4, только этот графический. Понятно, отчего эффект).
Лишняя рамка вокруг спрайтов увеличивает объем потребляемой памяти спрайтом и проекта в целом. В совокупности с точной проверкой, увеличивается и время создания точной маски.
  Актуально: GMS.
  Прирост: GM8.1-: минимальный. GMS: +19%.

8. Лучше switch, чем else if.
  В ситуации, при которой различные действия должны выполняться в зависимости от значения переменной (например, проверка оружия и выполнение соответствующего выстрела), используйте switch вместо if {} else if {} else if ....
Пример:  Почему работает: один switch выполняется быстрее, чем несколько if.
  Актуально: для всех версий Game Maker в разной степени.
  Прирост: GM8.1-: +20%. GMS: +5%.

9. Объекты -> тайлы -> частицы.
  Объекты, которые никаким образом не взаимодействуют с другими объектами, заменяйте их на тайлы. Если эти объекты появляются во время игры и движутся, заменяйте их на частицы, выбрав им в качестве формы собственный спрайт.
  Почему работает: объект - более активная сущность, чем тайл или частица. В постановке этого пункта уже сказано чем: проверками столкновений с другими объектами, а также созданием локальных переменных, проверкой других событий.
  Актуально: для всех версий Game Maker.
  Прирост: Частицы vs Объекты: GM8.1-: +46%. GMS: +970%. | Тайлы vs Объекты: GM8.1-: +15%. GMS: -3%.

10. Сборка мусора в проекте.
  Если у вас в проекте появились ненужные объекты, спрайты, скрипты, комнаты или прочие ресурсы, не спешите их удалять. Создайте папку для этих объектов и перемещайте их туда. А позднее вместо того, чтобы создавать новый ресурс (объект, спрайт, скрипт, комнату), можно будет использовать старый и ненужный.
Проверяйте скачиваемые движки путём создания нового ресурса. Если появившийся порядковый номер значительно превосходит количество данного ресурса (script338563, а скриптов от силы тысяча-полторы), значит, движок создавался без соблюдения этого правила.
  Почему работает: каждый ресурс требует определенного имени (более всего похожее на id объектов, index) в проекте, к которому можно будет обращаться. После удаления ресурса, этот id всё же остается в проекте и, во-первых, увеличивает размер проекта, во-вторых, замедляет процесс компиляции и увеличивает время запуска проекта, в-третьих, возможно, точно так же действует и на производительность игры - замедляет ^{(не подтверждено)}.
Избавиться от "устаревших" id ресурсов позволяет экспорт всех ресурсов в чистый проект.
  Актуально: GM8.1 и ниже.
  Прирост: действует только на размер файла проекта и игры, длительность компиляции и запуска. Производительность в игре не затрагивается.

11. Самостоятельные тесты.
  Некоторые ситуации в коде разрешаются разными приёмами, которые могут отличаться производительностью. Если она важна для вас, проводите тестирование этих способов, выполняя код repeat (1000) {приём} в шаге или похожим способом.
 Почему работает: проверено на себе.
  Актуально: всегда и везде.
  Прирост: измеряется самостоятельно.

Автор: Fantom.
Запрещается копирование данной статьи без ведома и согласия автора.

_{UPD 11.11.2014: проверена актуальность всех пунктов, подкреплены цифрами.}

Отличная статья  sm_respekt

Первый код из пункта 3 можно выбросить - на низком уровне (ассемблер), операции сравнения двух чисел сводятся к следующему
Даже если допустить, что для jl\jg флаг "нуля" не проверяется, то разница в скорости выполнения все равно будет невероятно малой велечиной, по сравнению с временем, потраченным на интерпретацию кода. С этой точки зрения, если удалить из кода все пробелы, то это даст гораздо большее преимущество чем замена >= на >

От себя:
Операторы выполняются быстрее чем функции в GM.
Таким образом,
будет выполнен быстрее чем
хоть и даст идентичный результат.
P.S.: логика работы битовых смещений в GameMaker очень искажена. Я не советую использовать их без предварительной проверки, если вы работали с ними в каком-либо другом языке программирования.

Статья интересная, но насколько эффективна такая оптимизация? Что она дает, насколько меньше загрузка ЦП? Не думаю что очень велика (хотя могу ошибаться)

Зависит от проекта, то есть нагрузки. Естественно, если предполагается участие большого количества объектов, то лучше оптимизировать. Тем более если планируется работа не только на самых последних новинках супер прокачанных компьютерах.

Вот "отзыв" из темы Оптимизация (http://forum.hellroom.ru/index.php?topic=1336.msg11305#msg11305):

Ясно всё.
Ну, моим проектам это не грозит, у меня у самого комп 6 летней давности...

Вот такие вопросы по оптимизации:

1) Влияют ли на что нибудь скобки? Учитывая только 1 операцию, с 2 и более без них никак :)
Пример:
if (x<y)   или   if x<y

2) Нужно ли ставить then после if (x<y)?
Пример:
if (x<y) then break;   или   if (x<y) break;

3) Нужно ли ставить { } после if (x<y) then?
Пример:
if (x<y) then break;   или  if (x<y) then { break; }

Результат будет одинаковый, а скорость выполнения? Проект очень тяжелый, таких операций куча.

Молодец, FanTom, статья отличная, но почему она не в в том разделе?
Или в том?

хм, 5 и 6 пункты как будто противоречат друг другу  :hm:
10 пункт еще актуален для GMS?

скобочки ставьте, then не ставьте, фигурные скобки ставьте.
без скобочек и со скобочками разница в производительности будет совершенно не заметна, но скобочки дают гораздо более читабельный код и меньшее количество багов, как следствие.
а then он избыточен, то есть он дублирует фигурные скобки {} (GML поддерживает синтаксис различных языков, в том числе си и паскаль; скобки - из си, а then из паскаля и смысла писать одно и то же, нет).

Все три пункта вряд ли каким-либо образом действуют на производительность.
1. Ставить или не ставить скобки при одном условии - кому как удобно. При двух и нескольких условиях их тоже можно избежать, если условия несложные.
2. then не нужен, добавлен, возможно, для тех, кто изучал Паскаль.
3. Фигурные скобки при одном действии тоже кому как удобно, можно ставить, можно не ставить (всегда ставлю), но
еще раз повторюсь: then и фигурные скобки - не взаимозаменяемые понятия. then служит, так сказать, для перехода от условия к действиям. Фигурные скобки (аналог begin end Паскаля, которые тоже присутствуют в GML) позволяют выполнять несколько операций при выполнении условия.
Пример:

---

Добавлено: Январь 17, 2013, 13:43:21
Не вижу противоречий. :errm:

я бы уточнил в таком случае: фигурные скобки заменят then, а вот then фигурные скобки не заменит.

Надо бы это в шапку добавить, полезное замечание.

И еще вопросик:
На счет ; немного не ясно. Если в каждом присваивании x = 1 ставить ; в конце, это на что то влияет? Или можно оставлять просто x = 1 вместо x = 1; ?

ни на что не влияет. лучше ставить везде, где надо.

---

Добавлено: Январь 17, 2013, 14:18:13
5. ... Если можете перевести кнопки в код - переводите.
6. Для управления желательно использовать стандартные события клавиш, вместо проверки кода в шаге (keyboard_check)

Меня все волнует 10-й пункт. Это действительно так сказывается на размере и быстродействии? Что удаленные id-шники все равно обрабатываются?

Подтверждаю. Лучше ставить.

Кнопки = действия, а действия - это не то же самое, что события. Действия выполняются внутри событий.
Их можно сравнить с тем же условием: событие - это условие ("используйте стандартные вместо Step"), а действие - действие ("используйте код вместо кнопок").

Да, в GM8.0 это точно так, насчет GMS не в курсе.
Ради интереса можешь скачать движок GMogre (http://forum.hellroom.ru/index.php?topic=640.0), примеры в формате gmk, в каком-либо из них добавить новый скрипт, увидишь его номер (~333ооо) :errm: В примере такого количества скриптов нет, значит это количество учитывает и удаленные скрипты.
Затем экспортировать всё в чистый проект и разница в скорости их запуска и компилирования будет очень заметна.

Сильно сомневаюсь (практически уверен, что не), что этот движок с примерами по нему вообще пойдет под GMS.
Надо будет посмотреть айдишники в танкисте.

GMS очищает айдишники после перезагрузки.

Если записывать код из шага в рисование, то сильно ли это повлияет на производительность?

От перестановки переменных сумма не меняется. События всего лишь определяют порядок выполнения кода, производительность от этого не поменяется.
Другое дело, что при этом нужно довольно чётко понимать, что мы делаем. Например, изменение координат других объектов в draw может привести к непредсказуемым дёрганиям спрайтов.

Спасибо за статью, очень познавательно :)

В связи с прочитанным, у меня такой вопрос: допустим, нужно нарисовать гуй, в котором довольно много кода получится в событии draw. Что будет быстрее, оставить весь код draw в одном объекте, контролирующем гуй (в котором помимо draw есть и другие события), или же вынести код draw в, скажем, 100500 1-2 дополнительных объекта, в которых кроме draw ничего не будет?
P.S. код из draw иногда обращается к значениям переменных внутри других событий.

меньше объектов - лучше.
в draw лучше ничего помимо собсно отрисовки не держать (т.е. все расчеты - в step'ах).
в случае ГУИ можно обойтись без объектов вообще - сделать тайлами и организовать их замену через скрипт

Интересует такой вопрос. Какой вариант лучше в плане оптимизации?



С виду кажется, что второй вариант более оптимизованный, но:
В первом варианте действие с переменной выполняется только если условие истинно, во втором же выполняется и условие, и действие переменной, не зависимо от условия (к переменной каждый шаг прибавляется 0).


И второй вопрос.
Есть ли разница использования + и * вместо || и && ?

Т.к. любое число выше 0.5 возвращает true, то условие истинно, но есть ли разница со вторым вариантом? Аналогичный вопрос с && и *

1. Первое лучше, и читается удобнее, чем второй вариант. Следуя второму варианту, рано или поздно появятся такие выражения, в которых не будет понятно, где "главное" равно, а где складываемые (или где левая часть выражения, а где правая) :errm:
Во втором варианте тоже используется сравнение, как и в первом, поэтому у первого меньше нагрузка.
Еще и умножение выполняется. Одна-две операции в первом варианте против трех во втором.

2. || - логическое сложение, && - логическое умножение. Разница в слове "логическое" :xD:
В приведенных примерах (и с умножением если тоже привести) разницы в результате нет, но практика таких выражений опять же может привести к запутыванию кода (обфускация, с одной стороны плюс, с другой минус) и к привыканию. Одно дело - GML это спокойно принимает, другое дело - другие языки не смогут, разрешая выполнять только логические операции с логическими переменными, и ожидая только логическую переменную после if.

Понятно, значит лучше использовать "классические" методы.
Как я понял
Будет так же выполняться быстрее, чем
Ведь else не является сравнением, а всего лишь выполняется при ложном значении условия. Я прав?

Привет всем!

Думаю, было бы хорошо включить в эту тему рекомендации по выбору разрешения для игры и масштабирования с точки зрения производительности.
Например, если планируется работа игры на разных разрешениях экрана (например, на Android), то как следует подойти к выбору размера комнат? Если при масштабировании картинка увеличивается, то как это скажется на производительности? Или как скажется уменьшение? В какой-то из тем обсуждение данного вопроса встречал, но сейчас не могу найти.

Не сочтите за некропостинг, думаю, вопрос имеет прямое отношение к теме и создавать новую нет смысла.