Какой игровой движок выбрать?
Посоветуйте, пожалуйста, игровой движок для разработки 2D игр под android (возможно в будущем и на windows). Важным критерием является цена. В следствие чего (и не только) были отброшены такие варианты, как Construct 2, GMS 2 и Clickteam Fusion 2.5. Слышал про unity и совсем недавно узнал про gudot.
Попробуй взять Godot. Правда, я им не пользовался, но я пользовался Unity. Unity - это хороший движок, но у него есть ряд проблем, с которыми вы не хотите разбираться, когда садитесь делать игру. С ними можно справиться, если вы уверены, что не будете совершать ошибок.
1) Unity - неоптимально использует ресурсы компьютера, вы можете заметить это, запуская простенькие вроде бы поделки у себя на машине. Иногда, она начинает греться. Не всегда. Просто какие-то разработчики учитывают встроенные проблемы движка, а какие-то нет. В частности:
1 - а) Unity как бы обещает, что все данные хорошо кэшируются, но это не так. "Брать" камеру или трансформ объектов (даже из-под скрипта самого объекта через this) достаточно дорого. Лучше не делать это больше одного раза, и сохранять все нужные ссылки.
1 - б) Многие методы, которыми новичкам предлагают пользоваться на практике, и которые выглядят "правильно" с точки зрения подхода к разработке, тоже очень дорогие. Find, Instantiate - как примеры. Тут нужно идти на ухищрения. С тем же кэшем после Find; некоторые объекты не инстанировать в рантайме, а держать где-нибудь за сценой в выключенном состоянии. Те, которые всё же правильней инстанировать - не удалять, а сохранять ссылку и убирать за сцену и т.д.
1 - в) Асинхронная загрузка ресурсов на практике не такая уж асинхронная.
Если всего этого не знать, и не знать, что с этим делать, скорее всего вы выдадите лагающее дерьмо вместо лампового продукта. Особенно, если речь идёт об мобильных устройствах!
2) В Unity неудобная вёрстка UI и работа с анимациями.
3) В Unity нет нормальной работы со строками из коробки. Скорее всего вам придётся писать вс1 самостоятельно, или вкладывать деньги в плагины.
4) Нет сохранений или паузы.
Про Godot не знаю, но что-то чекал немного. Вроде бы там всё это есть. Наверняка имеются свои подводные камни, но я бы вас поостерёг. Либо, если всё-таки решите браться за Unity - учтите существующие проблемы заранее. Погуглите другие. На самом деле всё решаемо и не так уж страшно. Кошмаром это становится, когда выясняется уже на ходу, когда особо некуда "разворачиваться".
Ээээ, не надо на UI гнать. Он офигенный. Я 90% ui собираю в редакторе без использования кода. Просто нужно собирать так, как было задумано его разработчиками - и никаких проблем не будет
Сижу на юнити несколько лет, указанные проблемы кажутся притянутыми за уши по большей части
1 - а) Насчет Camera.main ты прав, а вот взятие трансформов, ригидбоди и других встроенных в юнити компонентов работает быстрее, чем взятие своих компонентов. Возможно кэширование ещё быстрее, но там итак достаточно быстро, чтобы об этом не думать
1 - б) Find в самом обычном подходе заменяется синглтонами, а частый instantiate пулами объектов. Только почему-то о синглтонах большинство туториалов начальных молчит, сам не понимаю почему (да, они так себе, но в тысячу раз лучше, чем GameObject.Find
1 - в) Не сталкивался с такой проблемой, ничего не могу сказать
2) Никогда с этим проблем не было, дело вкуса?
3) Тоже проблем не было, не понял откуда взялись
4) Time.timeScale можно для простой паузы использовать, но соглашусь, что тут проблема, что нельзя таймскейл не глобально устанавливать, а насчет сохранений - непонятно что ожидалось. Я создаю свои врапперы для данных, которые сериализую в json, сохраняя на диске/сервере. Есть вроде ассеты, которые позволяют прям сцену целиком сериализовать, но это как-то совсем жестко по-моему. А для совсем простых и быстрых штук есть PlayerPrefs
А почему верстка уи неудобная? Юнити же вроде подгружает напрямую psd прям со слоями, а годот - там надо экспортить через другие форматы, атласы собирать и т.д.