Добра Вам, уважаемые читатели!
У инструмента по созданию игр Scirra Construct 2 уже довольно много пользователей. Всё чаще среди них я встречаю тех, кто разочаровался в данном конструкторе, пытаясь сотворить игру под мобильные платформы.
Причина разочарования зачастую одна и та же: крайне низкая производительность на целевых устройствах. Чаще всего игроделы пеняют это на недостатки самого Construct 2, и приходят к заключению, что Construct 2 и мобильные устройства - вещи несовместимые. Однако это не совсем так. Есть определенные сложности, но так же есть и пути их решения, о чем я тут и расскажу.
1. Спрайты и анимации.
1.1. Старайтесь избегать больших спрайтов. Статичную картинку 1024х1024 правильней будет порезать на более мелкие 256х256 куски.
1.2. Вместо нагромождения однотипных спрайтов используйте Tiled Background или TileMap, это значительно сэкономит ресурсы.
1.3. Не перегружайте анимации кадрами. Человеческий глаз скорей всего не увидит 60 кадров бега персонажа со скоростью 60 кадров в секунду. Порой хватает и 12 кадров со скоростью 12 кадров в секунду.
1.3. Избегайте программного изменения размеров спрайтов. Т.е. если вы загрузили в проект спрайт 512х512, а в игре Вы привели его к размеру 128х128, то имеет смысл изменить сам спрайт в редакторе спрайтов, а не масштабировать его в игровом редакторе.
1.4. Делайте Crop анимаций, для более плотной упаковки в атласы при экспорте. Старайтесь приводить их к размерам 16х16, 32х32, 64х64, 128х128 и т.д. Спрайт размером 129х129 будет восприниматься как спрайт с размерностью 256х256.
1.5. Большое количество спрайтов на экране приведет к сильной загрузке мобильного процессора. Старайтесь держать их количество в районе 60.
1.6. Не вращайте спрайты. Поведение Rotate сильно снижает производительность.
2. Настройки проекта.
2.1. Pixel Rounding. Округление значений размеров и положений до запятой. Выбор этой опции увеличит производительность, однако потеряется точность. Пример: Спрайт не сможет принять положение х=250.545, у=343.212, он примет положение х=251, у=343.
2.2. Sampling. Для увеличения производительности используйте опцию Point. Однако это не подходит для некоторых игр т.к. уберет сглаживание картинки. Идеально для пиксель арта.
2.3. Clear Background. Ставим опцию на NO. Отключает заполнение canvas белым фоном.
2.4. Force own texture на всех слоях ставим NO. Иначе каждый слой будет использовать свою собственную, отдельно отображаемую текстуру.
3. Поведения.
3.1. Старайтесь избегать стандартные поведения, которые зачастую можно реализовать и прописать в коде собственноручно. Поведения несут в себе довольно много параметров, которые Вы зачастую не используете, но которые обрабатываются и проверяются при выполнении кода.
3.2. Однако не стоит относиться с фанатизмом к выше сказанному и в ручную прописать к примеру поведение физики Box2d.
4. Физика.
4.1. При экспорте через сервис CocoonJs, выбирайте опцию "Accelerated Physics" в объекте CocoonJs. Однако в свете постоянных изменений ускорителя, иногда могут появляться баги.
4.2. Используйте как можно меньшее кол-во граней в полигоне объекта. Идеал - 3 грани, терпимо - 8 граней, жесть - 20+ граней.
4.3. Избегайте взаимодействия физических объектов с иными поведениями. К примеру не правильно будет крепить физическое тело на Set XY и вращать его поведением Rotate и двигать поведением Платформер. Используйте возможности самой физики для этих целей.
5. Текстовые объекты.
5.1 Вместо объекта Text используйте SpriteFont. Это значительно снизит потребление ресурсов.
6. Группы, проверки, прочие хитрости.
6.1. Разбивайте события на группы. Отключайте неиспользуемые в данный момент времени группы событий. Это избавит от множества ненужных проверок и повысит производительность. К примеру незачем каждый тик проверять: "Прошел ли удар по персонажу", если игра стоит на паузе. Или так же не имеет смысла проверять нажата та или иная кнопка, если вовсе нет нажатия по экрану:
6.2. Уменьшайте количество событий, выполняемых "Every Tick". Некоторым событиям достаточно выполняться каждые 0.1-0.5-1 секунду, а не 0.016.
6.3. Не забывайте, что любое событие без тригеров, изначально выполняется Every tick. пример: событие Is Player overlaping Finish-> Set Victory to 1, каждый тик будет проверять "Не пересекает ли Игрок объект Финиш". Достаточно поставить перед этим событием Every 0.5 seconds и количество проверок уменьшится многократно.
6.4. Не забывайте ставить в событиях, требуемых единоразового выполнения Trigger once while true. Пример: Is Player.X<20 -> Set LVL_START to 1, при значении координаты Х игрока выше 20, каждый тик переменная LVL_START будет принимать значение 1. При постановке Trigger once while true событие будет выполнено единожды.
6.5. Частицы. Они создают огромное кол-во спрайтов, которое тормозит систему. Старайтесь либо избегать их использования, либо держать их количество в пределах 10-20 одновременно отображаемых.
6.6. Использование любых WebGL эффектов. В данный момент их использование напрочь убивает производительность.
6.7. Слабый мусоросборник. Старайтесь избегать частого создания-уничтожения объектов. К примеру падающие снежинки. Неправильный путь: создать снежинку сверху, уничтожить её по достижении низа, создать новую снежинку сверху и т.д. Правильный путь: Создать снежинку сверху, по достижении низа вновь переместить её наверх.
Соблюдая все эти моменты можно добиться довольно хорошей производительности даже на слабых мобильных устройствах. Приятного всем игростроения!
Автор: Ivan korobko
Источник: http://gcup.ru/ | 
