Alexey Gulev

Классная статья, спасибо!

Чаще всего именно так и есть.Часто слышу мнение "все сдк издателей под юнити, никто работать с вами не будет". Пару лет назад мы пришли к издателю с игрой и ему так она зашла (и показатели, конечно), что они написали для нас свое СДК без проблем.

Поэтому я тоже склонен считать, что игра первична в данном случае.

Вопрос не только в оптимизации, а еще и в работе над тасками последней мили.
Я уже выше в комментах писал, что оптимизация под тот же html5 таргет на среднее устройство, это как оптимизация для слабого устройства нативно.

Еще к таскам последней мили относится работа по встраиванию различных СДК. На Defold я могу собрать игру со всеми нужными СДК 1 раз, и затем просто править логику интеграции уже ничего не пересобирая и стримить код и ресурсы в плеер с компьютера (об этом в комментах выше тоже писали). т.е. если я сделал ошибку при интеграции плагина, мне не нужно пересобирать билд под таргет платформу (ios/android) я просто фикшу баг, жму cmd+b, выбрав как target запущенную игру на телефоне, и она перезапускается там.

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

Когда у нас есть бинарник движка (в случае андроида еще и dex + res), то aab или apk собирается на машине разработчика.
Именно поэтому разработчику не нужно об этом думать. Он просто получает результат.

Мой геймдизайнер собирает билды в пару кликов (ну или из редактора собирает на устройство, как на таргет платформу, просто стримит ресурсы с компа), чтобы что-то потестить именно на устройстве.

2. Во первых на старых девайсах, а во вторых с html5 у unity совсем беда. По в html5 билде (грубая аналогия). А это очень неплохо так растущая платформа и для небольших студий иногда может быть куда интереснее и стабильнее, чем высоконкурентный мобильный рынок. Не говоря уже про стим и т.д.

Про Tiny согласен. Мало того, что медленно, так и не очень дружелюбно к разработчику. И как я уже сказал, это не тоже самое, что один и тот же проект собрать под все. На нем нужно брать и с нуля писать игру.

У меня нет опыта разработки на Solar2d и LÖVE.
Знаю только что у Solar2d довольно слабая поддержка html5 (знаю это от разработчиков, что перешли на Defold из-за этого) и что там API и подходы ближе к подходам Flash (Flixel/Phaser) за что его некоторые любят.

Про LÖVE слышал очень мало и ничего сказать не могу.

День добрый, я увидел вопросы в вашем комментарии

Как и любой другой кросс-платформенный движок?

Да, на сегодняшний день любой движок позволяет собрать игру под любые платформы. Но собрать не всегда означает, что она будет работать вменяемо. Я не уверен, удалось ли все донести мысль правильно, но основная месть была в том, что:
1. Это делается в один клик без дополнительных действий (не нужны СДК, другие аде и т.д. один раз скачал движок и собираешь игру под все)
2. Что важнее, что производительность под все платформы будет на высоком уровне, что очень важно для html5 проектов, особенно на мобильных устройствах (что я специально и подчеркнул). т.е. просто собрать, чаще всего, не достаточно. Нужно чтобы конечный пользователь мог в это играть с комфортом на любом среднестатистической устройстве.

Но в Unity большая часть тормозов и лагов НЕ из-за кода, отвечающего за логику.

Да, дело не в логике в 99% случаев. Думаю тут я точно не так донес мысль. Под подходами я имел ввиду не только написание логики, но и то как устроен движок и к каким подходам он в итоге "склоняет". Пара примеров:
- Defold статический движок, буферы под объекты выделяются заранее и создание/удаление объектов ничего не стоит на стороне движка (кроме логики в компонентах скрипт, которые пишет сам разработчик).
- GUI компонент дает простые инструменты разделения по слоям с простыми правилами, следуя которым накосячить с батчингом будет тяжело (даже если разработчик им не следовал, то добавить слои довольно быстро и просто)
- У ресурсов всегда есть четкий владелец, что делает менеджмент ресурсов довольно простым (загрузил объект с нужными ресурсам, выгрузил объект и ресурсы выгрузились)
и т.п.

Ну и вопросы производительности, все-же, стоит всегда поднимать для самого слабого "звена". В данном случае, я рассматриваю html5 на довольно средних, но очень распространенных мобильных телефонах. Если на них все хорошо, конечно и на других устройствах все будет отлично.

Тут отмечу, что я не говорю, что Defold лучше Юнити. Но он решает другие проблемы, которые Юнити если и решает то совершенно другими средствами, вроде отдельного project tiny, что уже и не совсем тот-же движок и требует отдельного написания игры с нуля.

У нас в комьюнити у многих есть игры на Мобаил + web платформа (Яндекс игры или poki, например). Это довольно удобно. Есть истории когда игра не зашла на мобильных платформах, люди пошли попытать удачу в web т.к. портировать в веб просто и быстро и нашли свою аудиторию там, отбив проект.

Рекомендую обратить внимание на Defold. 
На нем можно легко делать игры и под социальные сети и под mobile из одного проекта, не заморачиваясь переписываниям и получая отличную производительность. 
Как раз обсуждаем статью в чате: https://t.me/DefoldEngine

Очень милый арт!

Ураааа, Flazm вернулся!!!!

Кстати, а почему не упомянули сайт ребят? http://one-dream.info/
Странно, что сайты других проектов есть, а сайта тех, о ком заголовок статьи - нет...

Молодцы! Очень очень рад за ребят и от всей души поздравляю!

Уже играл в демку и занес денег, классная игра.