Основная задумка

Про бенчмаркинг приложений, движков и различных программных систем писано множество книг, статей и туториалов.

Вот что выдает нам старушка Википедия на сей счет:

Тест производительности, бенчмарк (англ. benchmark) — контрольная задача, необходимая для определения сравнительных характеристик производительности компьютерной системы.

Но что, если мы подойдем к вопросу бенчмаркинга игровых движков немного с другого боку? Все игровые движки и SDK для разработки игр (да и не только) часто рекламируют себя как очень интуитивные и легко усваиваемые инструменты. Нам продается простота в освоении, потрясающая кривая обучения и входа, демонстрируются легковесные и красивые примеры, где один экран кода будучи запущенным творит какую-то чудную магию. Так вот, готовясь к грядущему мероприятию Ludum Dare, я в очередной раз решил оглядеться и посмотреть, что предлагает "рыночек" простому Емеле — тому, кто в геймдеве без году неделя. То есть одна из групп людей той самой ЦА, которой продаются эти самые потрясающие качества лёгкой усваиваемости движка.

Что если мы… попробуем пробенчмаркать себя при работе с различными движками для написания игр? Да, да, то есть свою производительность труда на них. Буквально возьмём несколько из них, запрёмся в пещере с ноутбуком, интернетом и секундомером да и запишем все свои результаты в аккуратную табличку, а затем попробуем сделать какие-то выводы. Параллельно отметим, что понравилось, что удивило или напрягло в работе с тем или иным движком.

Про бенчмарк

Итак, объекты тестирования — три игровых движка. Здесь наверное стоит как-то более-менее формально (насколько это вообще возможно) описать свою "конфигурацию" (да-да, как в случае с типовыми результатами бенчмарка пишут конфигурацию железа, где делали прогоны, описание бенчмарка и так далее).

"Конфигурация" или О себе

Я — Java-developer. Опыт промышленной разработки 5+ лет. Также в работе немного писал на JavaScript, Lua (совсем-совсем капельку), shell. Образование высшее техническое. Дизайнерских курсов не проходил, гейм-дизайну не обучался, лишь сам ярый поклонник различных PC-игр. Последний год увлекся созданием простейших компьютерных игр.

Про задачу

Тестовой задачей был выбран проект клона игры Doodle Jump. Я уверен, многие знают или играли в неё, это очень прикольная и очень раскрученная игра под Android.

Регламент будет такой:

1. Под каждый движок отводится 4 часа времени. Сюда входит как изучение, ознакомление, ковыряние в носу, попытка написать прототип, отладка игры, вообщем полный цикл создания игры.
2. Каждые полчаса, в небольшой перерыв, я попробую зафиксировать, что было проделано, чтобы как-то корректировать свою работу, намечать дальнейший план работ, делать пометки, записи и так далее.
3. Перед стартом опробования каждого движка мы попробуем декомпозировать проект игры на составляющие элементы дабы присвоить им условные единицы. Таким образом, мы замерим свою "производительность" разработчика игры для каждого движка в попугаях и сможем сравнить результаты не на словах, а на хоть каких-то цифрах.

Декомпозиция игры на составляющие

В очень абстрактном и верхнеуровневом виде я вижу себе составляющие компоненты игры так:

1. Игрок (спрайт, поведение прыжка, реакция на нажатые кнопки)
2. Объекты на уровне: платформы, враги и т.д.
3. Физика: скорость прыжка игрока, ускорение свободного падения, платформы должны обрабатывать коллизию только если на них прыгнули сверху и пропускать игрока сквозь себя, если он пересекает её с нижней стороны платформы.
4. Процедурная генерация уровня: инициализация и добавление в уровень (в произвольные места, но с некими правилами и ограничениями) на лету новых платформ и врагов, создавая для игрока завлекающую игровую ситуацию
5. "Камера", следящая за игроком, покуда он продвигается вверх по уровню. Камера должна удерживать игрока в области видимости для игрока и постепенно "подпрыгивать" с ним, отображая новые платформы, появляющиеся в области рендеринга (в области видимости камеры)
6. Механизм срабатывания Game Over. Игрок проигрывает, если он достигает нижнего края видимой области (после того как хотя бы один раз уже прыгнул)
7. Начисление очков игроку. Будем просто обновлять счетчик высоты игрока. Обновлять будем счетчик по последней достигнутой платформе (та, от которой он оттолкнулся последний раз)
8. HUD: отображение прогресса игрока. Отображение высоты.

Для простоты назначим каждой составляющей по одному баллу наших попугайских единиц измерения. Итого, максимум — т.е. полная играбельная версия проекта, равен 8 баллам.

Ниже будут приведены ассеты использованные в отображении. Это собственноручно нарисованные (я не художник, как вы можете заметить) спрайты персонажа и платформ размерами 64x64, формата *.png.

И также приведу пару блок-схем:

1. Так будет реализован расчет "пола" для игрока (помните, с прыжком вверх, экран смещается, и вылет за край экрана — означает пригрыш)
   
2. А так мы расчитываем и с каждым тактом обновляем вертикальную скорость (y_velocity) и координату y игрока, на неё влияют два фактора: ускорение свободного падения (GRAVITY) и платформы, при достижении которых, игрок отталкивается с восстановленой полностью скоростью
   
3. Алгоритм расчета горизонтальной скорости, как и прочие механизмы были оставлены за рамками статьи.

Кстати, у меня до сих пор остались вопросы:

1. Как все таки лучше реализовать слежение камеры за игроком? Пока что она будет привязываться к вертикальной координате последней, самой высокой платформы, что смог достичь игрок, таким образом, такая платформа оказывается в нижней части видимой области, и мы видим новые куски генерируемого уровня.
2. Сам алгоритм генерирования платформ. По моей задумке это будет некая "фабрика платформ", которая в каждый такт игрового цикла (dt) знает самую высокую платформу, существующую на уровне и с случайным значением высоты (некий порог, не больше высоты прыжка игрока, но и не меньше определенной доли от его высоты, чтобы платформы не лепились вплотную одна друг к дружке) добавляет новую платформу на уровень, когда игрок продвинулся. Здесь также интересен вопрос нарастания сложности игры, каким образом должен меняться режим генерирования этих платформ.

Я был бы очень рад вашим идеям, лайфхакам и предложениям в комментариях и ЛС по этим двум несомненно гейм-дизайнерским вопросам.

Про движки

Были выбраны три кандидата с очень интересными особенностями применительно для меня. Итак, ниже в табличку сведены параметры, которые будет полезно иметь в виду при анализе результатов своих испытаний.

Итак, видим, что подборка довольно интересная. Интересная она тем, что мы будем иметь дело с разными сочетаниями наших качеств и характеристик движков. И посмотрим, что зарешает в конце: движок, в котором я уже немного набил руку, прокачанный ЯП или совершенно свежий и новый для меня движок с многообещающими фишками, но совершенно не освоенный, да к тому же не на основном моём языке разработки.

Почему не Unity/Unreal Engine/Other Awesome Engine etc.?

Многие бы возможно удивились, почему, я не пошел стандартным путём, да и не взял самые распространенные флагманы современности: Unity либо Unreal Engine? Я бы сформулировал свои соображения так: я хочу выстроить очень простую, минималистичную и крошечную игру. С парой игровых элементов, составляющих игровую механику, одним играбельным персонажем, простой генерацией уровней и без спецэффектов либо очень условных спецэффектов, как на старых аркадных автоматах. Так вот, образно выражаясь, моя задача — это нарисовать красный круг на черном квадрате, а для этого мне предлагается взять Photoshop. Попросту говоря, набор фич, режимов и возможностей Unity отпугнули меня. На данном этапе я хотел бы понимать каждую деталь своей игры.

Лучше всего это дают простые и маленькие движки, с ограниченным набором возможностей, возможно не с лучшим тулингом и экосистемой, но в простоте и ограниченности тоже есть своя красота. Имея всего лишь ограниченный набор инструментов — а в случае с Love2D ваш инструмент — это ваш код и более ничего, вы фокусируетесь на фане, на написании чего-то прикольного, оживлении персонажа или окружения игрока. Уже более усложненные движки расширяют ваш выбор, и написание кода плавно перетекает в множество вещей: написание скриптов (кода), связывание скриптов, мапирование ассетов, добавление конфигов, переопределение конфигов, подмешивание сторонних плагинов, написание скриптов и конфигов под сторонние плагины, множественные клики по дюжинам и дюжинам диалогов и окон… Скажем так, я пока что ещё побаиваюсь таких навороченных и несомненно продвинутых и мощных движков для разработки игр. Ну а ещё я не хочу заново вспоминать C#/JS/C++ и писать на них.

Немного подытожу мою мотивацию при выборе движка ссылкой на вот это видео, где автор как мне кажется буквально снял у меня с языка то, что я пытался сформулировать словами сам себе и окружающим все это время: https://www.youtube.com/watch?v=JH8xwNOQ0TM

Defold

Defold — кроссплатформенный движок от компании King.
Поддерживаемые платформы:

• Html5 (WebGl)
• Android 2.3 (API level 9)+
• iOS 8.0+
• Windows Vista+
• OSX 10.7+
• Linux

Любопытный факт, что компания King принадлежит "холдингу" Activision Blizzard.
В движке меня привлек язык разработки — Lua, поддержка кучи платформ для билдов игры, а также сам дистрибутив их собственной IDE кроссплатформенный — можно поставить и на Linux в том числе. Это меня и подкупило при выборе между Defold vs. Corona SDK.
А ниже лог того, что было сделано в контрольные точки:

Ниже, в спойлере, упрятано немного gif-анимаций, отображающих прогресс по времени:

Итог, бенчмарк-баллы:

1. Игрок (спрайт, поведение прыжка, реакция на нажатые кнопки) (V) Yes
2. Объекты на уровне: платформы, враги и т.д. (V) Yes
3. Физика: скорость прыжка игрока, ускорение свободного падение, платформы должны обрабатывать коллизию только если на них прыгнули сверху и пропускать игрока сквозь себя, если он пересекает её с нижней стороны платформы. (V) Yes
4. Процедурная генерация уровня: инициализация и добавление в уровень (в произвольные места, но с некими правилами и ограничениями) на лету новых платформ и врагов, создавая для игрока завлекающую игровую ситуцаию (X) No
5. "Камера", следящая за игроком, покуда он продвигается вверх по уровню. Камера должна удерживать игрока в области видимости для игрока и постепенно "подпрыгивать" с ним, отображая новые платформы, появляющиеся в области рендеринга (в области видимости камеры) (X) No
6. Механизм срабатывания Game Over. Игрок проигрывает, если он достигает нижнего края видимой области (после того как хотя бы один раз уже прыгнул) (X) No
7. Начисление очков игроку. Будем просто обновлять счетчик высоты игрока. Обновлять будем счетчик по последней достигнутой платформе (та, от которой он оттолкнулся последний раз) (V) Yes
8. HUD: отображение прогресса игрока. Отображение высоты. Опционально, кажется в оригинальной игре никаких индикаторов прогресса нет. (V) Yes

Benchmark Score: 5/8

Love2d

Это очень минималистичный, но достаточно мощный и гибкий движок для создания прототипов. В целом, при должной сноровке, он даже годится для публикации полноценных игр на рынок. Есть несколько удачных вдохновляющих примеров. Навскидку, Раз и Два.

Вообще, по данному движку рекомендую очень годную серию туториалов с Хабра, которая меня подстегнула и дала мощный толчок в освоении этого движка, дам только ссылку на первую часть, далее можно будет с неё попасть на остальные части: Создание игры на Lua и LÖVE — 1

Итак, ниже приведен лог того, что было сделано в контрольные точки:

Подсчитаем "производительность" движка:

1. Игрок (спрайт, поведение прыжка, реакция на нажатые кнопки) (V) Yes
2. Объекты на уровне: платформы, враги и т.д. (V) Yes
3. Физика: скорость прыжка игрока, ускорение свободного падение, платформы должны обрабатывать коллизию только если на них прыгнули сверху и пропускать игрока сквозь себя, если он пересекает её с нижней стороны платформы.
   (V) Yes/(X) No // *Реализовано, но не совсем идеально, с существенными огрехами. Я бы поставил здесь 0.5 баллов за выполнение пункта.
4. Процедурная генерация уровня: инициализация и добавление в уровень (в произвольные места, но с некими правилами и ограничениями) на лету новых платформ и врагов, создавая для игрока завлекающую игровую ситуцаию (V) Yes
5. "Камера", следящая за игроком, покуда он продвигается вверх по уровню. Камера должна удерживать игрока в области видимости для игрока и постепенно "подпрыгивать" с ним, отображая новые платформы, появляющиеся в области рендеринга (в области видимости камеры) (V) Yes
6. Механизм срабатывания Game Over. Игрок проигрывает, если он достигает нижнего края видимой области (после того как хотя бы один раз уже прыгнул) (V) Yes
7. Начисление очков игроку. Будем просто обновлять счетчик высоты игрока. Обновлять будем счетчик по последней достигнутой платформе (та, от которой он оттолкнулся последний раз) (V) Yes
8. HUD: отображение прогресса игрока. Отображение высоты. Опционально, кажется в оригинальной игре никаких индикаторов прогресса нет. (V) Yes

Benchmark Score: 7.5 / 8

Java

Пожалуй логичным и закономерным был бы как раз шаг приглядеться к движкам, где язык разработки является тот, на котором у меня больше всего опыта и сноровки, не правда ли? Собственно, интуиция и какие-то внутренние ощущения немного удерживали меня от этого. Дело в том, что еще в студенчестве, я как-то наблюдал, как мучается мой одногруппник с движком jMonkey. Тулинг, работа с движком, документация, все это вместе создавало какую-то не очень приятную картину. Казалось, что движок просто не дает тебе ни шанса подружиться с ним, очень уж его использование выглядело каким-то неприятным.

Но все же, я решил посмотреть, что имеется на сегодняшний день, и я смотрел лишь в сторону движков, которые хорошо гарантируют лишь 2D, мне было плевать на поддержку 3D. Один из движков, Lightweight Java Game Library 3, имеет в своем названии и вводной слово Lightweight. Иронично, но простейшие же базовые примеры на главной странице, длиной в несколько экранов просто отпугнули.

Да, конечно, Java ведь очень многословна, чего ты хотел, скажете вы. Но я знаю, что на ней можно писать очень компактные и очень выразительные вещи. Я видел красивый и компактный API.
И в конце концов, выбор пал на FXGL. Первое время, у меня не было никакого энтузиазма и приятного возбуждения, которое бывает перед началом освоения какой-то интересной штуки или библиотеки. Но уже с первых примеров и кратких страничек документации и примеров, этот движок приятно удивлял меня все больше и больше. В подходе и API, который он предлагал все было логично, понятно и последовательно. Это определенно помогало вам строить четкий и гибкий цикл вашей игры, логику обработчиков, HUD, AI, коллизии, прочие элементы.

Интересные моменты и фишки FXGL:

• Как может намекнуть название, для визуальной части движок использует для рендеринга и компоновки элементов JavaFX API (JavaFX is used as the graphics framework) со всеми его плюшками и анти-плюшками. В целом, я считаю, это неплохое и вполне здравое решение. Таким образом, автор избежал ряда проблем (нет нужды реализовывать и поддерживать свой компонент рендеринга, можно использовать отточенное решение из экосистемы Java). Вот что говорит сам автор в одном из своих первых туториалов, и эта фраза мне очень понравилась:

  
  

  "For most UI objects we simply use JavaFX objects, since there is no need to re-invent the wheel. "

  Но в целом, конечно же вы получаете букет особенностей и каких-то недостатков JavaFX, а также (я не очень осведомлен о деталях), но насколько мне известно, есть какие-то лицензионные ограничения по использованию JavaFX в своих проектах, да и кажется JavaFX идёт и будет идти только в ограниченных поставках JDK (Oracle, возможно ещё какие-то).

  
  

• Тестовый проект, склонированный из репозитория, на основе которого я начал лепить игру, любезно складывает логи в папочке проекта logs/ после каждого пуска игры. Это очень удобно, можно сразу же, из коробки смотреть debug-информацию, очень полезно для диагностики, понимания, где ты накосячил, если вдруг встретил затык в изучении движка.

  
  

• Также (видимо опять же, с базовыми настройками) игра предоставляет всплывающее меню по нажатии клавиши Esc. Тоже приятный бонус, надеюсь, он кастомизируется или как минимум отключается кодом либо конфигами.

  
  

• Здесь наконец-то работает Дебаг! Наконец-то! В Love2D это делать мягко говоря неудобно и неприятно.

  
  

  Лог разработки

  
  

  Ниже приведена краткая сводка моего прогресса, где я кратко отмечал, что было достигнуто по истечении 30-минутного интервала, а также некоторые свои мысли, замечания. Узрите же лог моего сознания за эти 4 часа!

  
  

И ниже прогресс отображен в виде серии GIF-анимаций с указанием временного интервала, когда это было достигнуто.

Подсчитаем "производительность" движка… А собственно, надо ли нам это делать, если итак понятно, что мы сделали все основные оцениваемые элементы и даже больше? Это был риторический вопрос.

Benchmark Score: 8

Выводы, мысли, идеи

Теперь снова сведем полученные данные в обновленную табличку:

Также, ради любопытства и дополнительного контекста, я добавил еще к данным бенчмарка число строк кода, которые я намолотил самолично разрабатывая игру (то есть исключен код используемых библиотек). Удивительно, но факт, многословная Java здесь не является чемпионом с движком FXGL, судя по всему я обошёлся меньшим объемом кода, чем в проекте на Lua, при этом реализовав больше функционала. Как говорится, шах и мат, аметисты.

Какие выводы мы можем сделать:

1. Надо брать FXGL и идти в бой? Я бы так не сказал. Love2D мне очень полюбился, но на том же Defold можно делать и более мощные вещи, познав его лучше, там больше команда разработки, он дает много преимуществ при публикации игр под различные платформы, в Love2D с этим как-то не очень, последние версии определенно точно не билдятся вот так на раз под все нужные платформы.
2. Это плохой бенчмарк, нужно больше данных. Пожалуй, тут я соглашусь. Обычно ведь делают множество прогонов (сотни, тысячи), тесты могут длиться по нескольку часов. Думаю, порядок использования движков очень сильно повлиял и внес какую-то долю погрешности. Как мне кажется, в самом начале, взяв первый движок, я еще не достаточно сформулировал себе основные алгоритмы, компоненты и все технические аспекты реализации игры как таковой. К третьему подходу, скорее всего, я уже выкристаллизовал основные моменты, алгоритмы всех действующих частей игры и код лился как песня. Это моя версия объяснения таких результатов бенчмарка.
3. Как можно судить по логам и gif-анимациям, я очень плох в коллизиях. Почти во всех движках эта проблема систематически проявлялась. Это значит, что похоже я не сильно понимаю данную область в играх, "математику" процесса и пожалуй мне следует уделить этому отдельное время, поразбираться с примерами хорошей реализации игровых механик посредством библиотек коллизий в движках.

Что это всё дало мне?

Думаю, нужно хоть как-то оправдаться, зачем я делал все это и пробовал замерить и формализовать свой опыт с движками?

Итак:

1. Банально, но опыт. Изучая движки, их подходы и принципы организации элементов, кода, инструментария, подмечаешь лучшее из разных миров. Где-то отмечаешь очень крутую идею инженеров движка, где-то удивляешься простоте и минимализму движка (Love2D).
2. Я давно хотел пощупать что-то более массивное либо иное, чем уже опробованный Love2D, и вот я сделал это. Жму F to pay respect.
3. Проверка суждений и фактов вокруг движков самолично. Я имею в виду, что я пощупал эти три движка, хоть и немного, и теперь в каком-то споре или если меня спросят порекомендовать что-то для разработки простенькой игры, у меня будет своё мнение, подкрепленное опытом (удачным, неудачным, но опытом)
4. Маленький вызов самому себе. Загнав себя в лимит 4 часов я ощутил драйв, мобилизацию ума и тела на производство результата. Этакий мини- Game Jam, разминка перед ним.
5. Контрольные точки! Боже, я сто раз слышал и читал советы о том, что важно задать себе какой-то Roadmap своей задумки, чтобы в конкретные моменты осознавать, как далеко я от играбельного билда. И только сейчас (!) я сподобился накидать себе гранулированный (гранулярный?) план задач с приблизительными ожиданиями по готовности игры. И эти контрольные точки по 30 минут реально хорошо помогали мне в движении к готовому продукту. Прогресс стимулировал и давал силы, неудачи останавливали подумать и пересмотреть подходы к проблеме или перераспределить мысленные и временные ресурсы на доделку ключевых элементов из списка. Поверьте, это своеобразная прокачка в себе лучших навыков менеджера или лида, если хотите! Пожалуй, этот прием я возьму себе на вооружение и для других своих pet-проектов ну и разумеется применю в грядущем 44-ом Ludum Dare.