Бенчмаркинг Емели

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

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

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

Тест производительности, бенчмарк (англ. 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) знает самую высокую платформу, существующую на уровне и с случайным значением высоты (некий порог, не больше высоты прыжка игрока, но и не меньше определенной доли от его высоты, чтобы платформы не лепились вплотную одна друг к дружке) добавляет новую платформу на уровень, когда игрок продвинулся. Здесь также интересен вопрос нарастания сложности игры, каким образом должен меняться режим генерирования этих платформ.

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

Про движки

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

Движок	ЯП	Опыт в движке (0 — никакой, 1 — есть опыт и несколько простых написанных игр, 2 — движок освоен вдоль и поперёк	Опыт в ЯП (0 — никакой, 1 — есть опыт и хорошее знание и понимание синтаксиса, идиом языка, 2 — профи по данному ЯП
Defold	Lua	0	1
Love2D	Lua	1	1
FXGL	Java	0	2

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

Почему не 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.
А ниже лог того, что было сделано в контрольные точки:

№	Time	Comment
1	30m	Просмотрен 1 тутор, пара вводных описаний редактора, опробован тестовый проект (кодирование обработчика нажатий, чтение доки обучающего проекта)
2	1h	Добавлены некоторые модификации в тестовый обучающий проект. Наверное, пора браться за свой проект и пытаться реализовать хоть что-то там?
3	1h 30m	Сделан прыгающий человечек (спрайт с поведением). Неплохо! :)
4	2h	Пора добавить управление. А также Пора добавить платформы и коллизии? Добавлено управление и платформа, но увы, обработку коллизий не успел..
5	2h 30m	Коллизии! Нужно, чтобы человечек умел запрыгивать на платформы и далее уже отталкиваться от них вверх. Что ж. Коллизии есть, но пока механика работает криво :)
6	3h	Ура, Коллизия есть и кажется она верная. Попробовал разместить несколько копий платформ.
7	3h 30m	Теперь надо бы подумать об плавающей камере, плывущей вверх и вверх, покуда игрок запрыгивает на новые более высокие платформы. Не продвинулся, а лишь закопался в тонкостях прикручивания камеры… Похоже с наскоку и так просто настроить камеру не получается.
8	4h	HUD. Вывод текущей высоты игрока над полом.

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

Скрытый текст

0-1h

1-2h

4h

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

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

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

№	Time	Comment
1	30m	Настройка проекта, создание базовых обработчиков, создание класса игрока (каркас с пока ещё не работающей логикой прыжков и гравитацией)
2	1h	Сделана фабрика, отрисовывающая платформы, сделан прыгающий человечек. Ура!
3	1h 30m	Попытка прикрутить библиотеку hardoncollider. Фрустрации, связанные с тем, что дока на официальном сайте написана по устаревшей версии, поиски актуальной доки, прикручивание коллизий. Пока что коллизии не реализованы
4	2h	Коллизии есть, но они кривые :(
5	2h 30m	Коллизии сделаны, немножко есть недочеты, но в целом — норм. Попытка прикрутить камеру, отслеживающую игрока, следуя его прыжкам вверх. Пока не очень удачно..
6	3h	Есть генерация платформочек, но коллизии по-прежнему глючат и хромают :(
7	3h 30m	Реализовано определение Game Over — определение, что игрок упал за нижний край видимой области. Реализовано начисление очков — т.е. отображение в левом верхнем углу последний взятой высоты
8	4h	См. ниже под таблицей то, чего удалось достичь по истечении 4 часов разработки клона Doodle Jump на движке Love2d.

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

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 часа!

  
  

№	Time	Comment
1	30m	Изучено пара туториалов. Базовый API и структура цикла игры. Научился отрисовывать спрайты, двигать объекты, отображать и обновлять HUD. Начато вкручивание коллизий в игру.
2	1h	Есть прыгающий квадратик с телом коллизии (Bounding Box) и "умеющий отталкиваться от пола" (т.е. есть определение нижней границы экрана)
3	1h 30m	Заложена основа фабрики по созданию платформ (PlatformFactory.java). Кажется, получилось даже "приручить коллизию" и удалось добиться отталкивания персонажа от платформы. Это несомненно успех для нового движка и при опыте в полтора прочитанных GitHubWiki-туториала на месте.
4	2h	Немного доработал коллизии с платформами, но все же до сих пор багованно и не идеально. Довольно быстро удалось сделать слежение камерой, опять же, оно тоже немного резкое и топорное, но отшлифовка плавности останется за рамками бенчмарка и опыта с FXGL в частности. Также, не составило труда дописать код фабрики генерации платформ, чтобы платформы генерировались на приемлемом случайном расстоянии от последней сгенерированной платформы. И код генерирующий их по мере продвижения игрока также был интегрирован в основной игровой цикл. Довольно неплохой прогресс, как по мне.
5	2h 30m	Ну что же. К этому моменту фактически вся игра уже готова. Реализованы все базовые составляющие. И даже отшлифован и доработан напильником правильный механизм отталкивания игрока от платформ (вау!), чего не было достигнуто идеально с предыдущими двумя движками. Возможно, здесь уже сказался накопленный опыт и интуиция, не спорю. Также был немого подтюнен рандомайзер расчета позиций для новых платформ, так как при предыдущих параметрах появлялись абсолютно недостижимые платформы, что вело к Game Over.
6	3h	Реализована еще одна ключевая фишка Doodle Jump (та, что была за рамками основного задания) — если игрок выпрыгивает за левый или правый край уровня, он появляется с другой стороны с сохранением своей скорости (импульса). Эта геймплейная фишка очень ключевая составляющая Doodle Jump; то, что делает игру разнообразной и цепляющей помимо других элементов. Также быстро была накидана функция сброса игры (Reset) и накидан код врагов и вражеского AI. Пока что это ещё не в игре, а на уровне прототипа.
7	3h 30m	Реализован алгоритм случайной генерации врагов на уровне. Он совсем не идеален, но это уже добавляет элемент фана и вызова игроку. AI врага, если его можно назвать таким громким словом прост — враг просто курсирует слева-направо и обратно, достигая края экрана, он просто меняет свое направление движения. Такой вот незатейливый враг у нас.
8	4h	Реализована стрельба по врагам. Если снаряд сталкивается с врагом — враг и снаряд исчезают. Таким образом, игрок может прыгать дальше без потенциальной помехи. Стрельба реализована так, что игроку разрешается множественная стрельба, все ограничено лишь производительностью движка и пальца игрока над кнопкой Space.

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

Скрытый текст

0-1h

1h-1h 30m

2h 30m (Фактически здесь реализованы все основные элементы игры)

3h 30m

4h

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

Benchmark Score: 8

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

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

Движок	ЯП	Опыт в движке (0 — никакой, 1 — есть опыт и несколько простых написанных игр, 2 — движок освоен вдоль и поперёк	Опыт в ЯП (0 — никакой, 1 — есть опыт и хорошее знание и понимание синтаксиса, идиом языка, 2 — профи по данному ЯП	Benchmark Score	Строк кода
Defold	Lua	0	1	5/8	166
Love2D	Lua	1	1	7.5/8	701
FXGL	Java	0	2	8	582

Также, ради любопытства и дополнительного контекста, я добавил еще к данным бенчмарка число строк кода, которые я намолотил самолично разрабатывая игру (то есть исключен код используемых библиотек). Удивительно, но факт, многословная 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.