Pull to refresh

Comments 27

Спасибо, почерпнул для себя недостатки сценографа, взял на карандаш ECS-подход.

Отдельное спасибо за открытый исходный код, думаю, многим пригодится.
Но ведь фактически вы переизобрели unity с ее компонентным подходом (ну или Ogre). Если вы изучали ее когда делали анализ готовых решений — неужели это было не очевидно? И почему «Также мы понимали, что на C# мы не сможем выжать максимум из устройств» если вы изначально выходили на iOS, а там MSIL прогоняется через AOT и получается нейтивный код? Что будет если вы захотите выйти на другие платформы? Например, на тот же SmartTV как один из необычных и интересных вариантов.
Unity, как раз таки тот вариант когда компоненты могут быть полиморфны. Тоже хороший подход, однако, мы пошли дальше. ECS это больше возможностей для производительности на современном железе.

Свой движок это плюс. На некотором железе как выяснилось мы появляемся быстрее Unity. Возможно потому-что Unity уже очень большой, и неповоротливый.

Производительность Unity, это отдельный вопрос. Не исследовал его детально, но из того что слышал, от коллег по цеху, люди сталкиваются с проблемами особенно на Android.
К сожалению, Unity далеко не панацея, и не серебряная пуля в геймдеве. Как верно заметил binaryzebra, некоторые исправления приходится ждать месяцами, даже когда речь идет о пустяках. Для меня это было особенно остро, когда они внедрили нативное 2D. Халтурная имплементация Box2D в версии 4.3, которую поправили спустя много месяцев.

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

Естественно, если квалификация программистов все это позволяет.
Ну мне видится основной смысл статьи так — «мы посмотрели сторонние ассеты для террейна, они нам показались сырыми и поэтому мы решили написать свое двигло полностью». Немного несоизмеримые вещи. То же самое и с остальными готовыми решениями типа ue. Когда говорят «вот были бы исходники, все бы быстро поправили», то обычно забывают о том, насколько большой зоопарк устройств юнити поддерживает в плане костылей вокруг багов в дровах и железе. Например, вся 4 мажорная версия в каждом апдейте содержала workaround-ы для самсунгов и тегр, а так же интегрированных решений от интела. Обеспечить такое же количество гарантированно работающих девайсов с учетом их косяков — это практически нереально в случае своего двигла. Понятно, что для варгейминга это мелочи, но это скорее исключение чем правило.
Выбор технологии это был серьезный вопрос, который поднимался несколько раз в процессе разработки. Подходили к нему тоже достаточно серьезно. Просто не формат статьи детально про это писать, ситуация 3 года назад, это не ситуация сейчас, и конечно сейчас надо смотреть на выбор технологии по новому.

Но если по ситуации на 3 года назад то было вот так:

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

— UE3 — не был доступен публично для лицензирования, он появился где-то уже через год нашей разработки. Цена UE3 для приватного лицензирования, была приличная. Так же как и UE4 сегодня, без 5% от gross revenue.

— Ни в одном из этих движков тогда не было нормального UI, а для нашей игры, это было критично.

Сейчас ситуация другая, однако все равно на текущий момент Unity и UE4 обладают рядом недостатков, которые люди решают в своих движках. Есть вполне резонное обоснование.
3 года назад, Unity для мобильных был очень сырой.

3 года назад юнити фактически отличалась только отсутствием mecanim и штатной 2d-рендера/физики, что в случае танков как мертвому припарка. Ну да, не было теней на мобилках, как и железа, способного тянуть такое. Все остальное до сих пор замерло в развитии примерно на уровне 3.х версии (как раз актуальной 3 года назад) и поменяется только в 5-ке. Относительно вменяемый гуй тоже уже был — Ngui (тогда 2.х ветка, сейчас 3.х), который и сейчас дает прикурить штатному гую, запиленному на его основе.
Не хочу спорить, но фраза выглядит черезчур голословной.
Спасибо за интересную статью, я уже наверное с месяц поиграл в Блитз, но не играю в основном потому что Блитз нереально жрёт батарейку, даже стоя на зарядке в 1А телефон умудряется садится достаточно быстро. Планируется ли что-нибудь в этом направлении?
Да, постоянно оптимизируем. Большой проект очень для мобильных платформ, количество задач и проблем огромно :-) работаем над всем, по приоритетам. Одна из основных это производительность, и батарея.
А что у вас во фреймворке делает Box2D?
Ну движок то не только 3Д, но в детстве и 2Д, как я понял из статьи. Так же на гитхабе есть Scene2D, что как бы намекает. Надеюсь автор поста разъяснит.
Когда-то давно, делали казуалочки. Для них и использовалось.
То есть у вас там не всё, что в движке — необходимо? Будете вырезать?
Пока не планируем. Код который не используется, автоматически вырезается на линковке. Если будут желающие сделать казуалочку, им пригодиться.
Раньше поддержка 2D была в 2-х видах, UI и Scene2D. Сейчас активно будем поддерживать UI, Scene2D пока нет необходимости.
У вас там столько всего, что страшно становится. Внешние зависимости я так понимаю являются частью проекта.
Откуда начинать собирать вообще неясно.
Если инструция какая — нить может?
Инструкции выложим в ближайшее время, сейчас активно переходим на cmake, чтобы стало проще с зависимостями. Сейчас можете пробовать собрать TemplateProject. Для смелых ResourceEditor. Это редактор сцен.
Жаль что ссылки на Artemis не работают. Надеюсь что временно.
Подход ECS необычен и очень симпатичен.
Этот подход более известен как data-oriented design. Data-driven было про то как меняя данные можно менять всю игру не трогая код.
Обязательная ссылка на то где все описанные проблемы расписаны: research.scee.net/files/presentations/gcapaustralia09/Pitfalls_of_Object_Oriented_Programming_GCAP_09.pdf
Очень хорошая статья, там также более детально расписано то что я лишь вкратце осветил, по оптимизации.
Кстати, в 2d я пришёл приблизительно к той же схеме. Никакой прямой реакции на действия пользователя — только изменение модели данных, а уже за ней изменение отображения.
Вообще чем больше open source движков от крупных компаний тем лучше, ну уж точно не хуже ;) А писаки про священную корову на c# уже достали, ну норм она, никто не спорит.

Но для open source нету самого главного! Простого и вменяемого «get started» и маломальского мануала. Без этого исходники эти похожи на кучу кода, которые в чьих-то руках могут превратиться в очень хорошую игру, но другие с ними ничего не сделают.

И еще странно… Почему зависимости лежат в проекте? Они тоже изменялись?
Может для статистической линковки?
Get Started — будет. Не обещаю что скоро :-) но обещаю что будет.
С зависимостями сейчас думаем как это сделать лучше. После перехода на cmake, думаю станет проще.
Выложить движок в опенсурс и подать в суд на студию, которая его начала использовать — профит. В очередной раз убеждаюсь, что ВГ — редкостная помойка, которую еще поискать надо.
Sign up to leave a comment.