Pull to refresh

Comments 51

Да здравствуют свои велосипеды, ибо это прекрасно! :)
Если бы ты был программером, а не дизайнером, то тебе было интересно писать именно движок.
Те 41% своих движков лишь показывают, что unreal и unity не покрывают всех потребностей.
Может нужно что-то более низкоуровневое и гибкое?
Ниже уровень -> выше порог входа -> больше затраты времени.
все кому нужен ниже порог входа и меньше затрат времени ради свистоперделок, уже выбрали unreal, unity, cocos итд итп
Или показывают, что проект начался ещё до того, как Unity вообще появился.
Unity появился больше 10 лет назад. Большинству проектов столько времени и близко не нужно.
Ну а все же — яркий пример использования популярного движка это PUBG. Там они сами криворукие или движок все же не такой хороший, как позиционируется? Игра из топа Steam и онлайна в 3кк человек очень резко скатывается, буквально за полгода в 1кк. Неужели даже изрядно подзаработав нельзя было пригласить экспертов из команды разработки движка? Мне кажется они так делали, просто ничего исправить не вышло… Хотя кто знает.
эксперты из команды Unreal сделали свой pubg — Fortnite.

Да да, и bluehole (pubg) даже судиться пытались, что абсурд. Но все же — анрил хорош и универсален или только если ты его разработчик? :)

Я смотрел пару разборов, почему PUBG тормозит.
У меня сложилось впечатление, что там не движок виноват, а полное отсутствие настройки.
Вот один из моментов youtu.be/oup3dSeGAhM?t=303
Они даже защиту от спидхака не включили, хотя она ещё до PUBG была прямо в движке. Всего-то нужно включить защиту и поменять пару цифр для настройки, я в своей игре это сделал за 5 минут. Что уж говорить про остальное…
Там они сами криворукие или движок все же не такой хороший, как позиционируется?

Не в том дело криворукие или нет, что бы сделать что то качественно нужно ВРЕМЯ а бизнесу нужно здесь и сейчас и потому ставят жесткие временные рамки, так как сотрудники на зарплате, нужно платить оренду и т.д. деньги на все это идут а прибыли нету, вот и приходится жертвовать качеством чтобы быстрее сделать итоговый продукт, это сама по себе порочная система и вряд ли из этого есть выход.

Неужели даже изрядно подзаработав нельзя было пригласить экспертов из команды разработки движка?

Не думаю что таких высокоценных экспертов кому либо делегируют посторонним компаниям.
Учитывая тенденцию на монетизацию всего и вся у разработчиков PUBG — я думаю, что они просто жадные и руководствуются тем, что если играют и в кривое, то зачем нанимать людей, которые могут починить одно, но при этом сломать другое.
Думаю там очень много работы для целой команды профессионалов.
Я полностью поддерживаю тему разработки своих движков. Плюсы таковы вы делаете то что надо.
Видать вы их не писали.
Проблемы

1 Баги.
Не просто баги, а Куча постоянно появляющихся багов. Движок живой и постоянно допиливается, откуда эти животинки постоянно лезут.
А у тебя нет комунити из 100к юзеров которые за день выловят 99% проблемных мест.

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

3 Новые фичи движка
Даже обычный вывод текста — это жуть на сколько сложно, если тебе надо сделать не абы как, а с хорошей производительностью.
Что уж говорить о прикрутке физики, аи, скелетов и т.д.

4 Кроссплатформенность
На каждую платформу надо найти спеца, обучить движку, потратить кучу времени на согласование с уже наработанным.
И каждая новая платформа обязательно выставит такие требования которые ну никак не хотят работать с требованиями от тех платформ что уже работают.

5 Сотрудники
Невозможно нанять людей уже знающих твою платформу, поэтому надо учить, а нет ни нормальной доки, ни комунити где сотрудник может поискать ответы.
Поэтому надо отвлекать остальных сотрудников, причем первый месяц вообще постоянно.
Любой грамотный программер понимает, что знания по этому домострою (в отличии от известных движков) ему нигде не пригодятся, и поэтому потребует весьма высокой оплаты.
А не грамотные просто не разберутся в коде.

Короче в 99% случаев, свой движок, это дорого, долго и бесперспективно.
Может одному и сложно делать, но не забывай что это дешевле компании по бюджету, но дороже по времени, за то прокачка опыта и следующий продукт будет качественее если будут учитывать прошлые ошибки.

Сейчас много фреймворков для графики упрощающие создание движка, там по сути все за тебя написано.
отбросить чужой игровой движек, что бы возится чужим графическим движком…
как-то это не кошерно
Все графические фреймворки простые, единственное надо делать под себя, к примеру в штате больше разработчиков знают Lua с C++, следовательно для удешевления разработки будут к движку прикреплять интерпретатор Lua (LuaJIT в частности). Это касается всего процесса разработки игры и параллельно движка.

Тебе не придется изучать на другом движке методы и скриптовый язык, если ты можешь написать свои методы на своем любимом языке.
image
Вы не учли один важный плюс — можно вытрясти бОльший бюджет из инвестора и успешно его освоить.
Отвечу как человек, перешедший (с кучей ругани) с кастомного движка на Unity.

1 Баги

В Unity много багов. Очень много. Эти баги не фиксятся годами. «Комунити из 100к юзеров» тут играет отрицательную роль: нужно больше времени на обработку сотен репортов от юзеров, по делу и не очень. Если у вас нет $100K для приобретения исходников движка или спеца по реверсингу, вы обречены. Если не верите, попробуйте свернуть игру в Hearthsone (AAA-игра от Blizzard на Unity) на iOS-устройстве, рвзверните и посмотрите на белые квадраты вместо текста.

2 Доп инструменты

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

3 Новые фичи движка

Программисты на Unity привыкли искать готовые решения в Asset Store. Эти решения в 50% случаев не работают, а в 90% случаев работают не так, как надо.

Пример. Не далее как неделю назад прикручивал логин через Google Play Games, нашелся стандартный плагин. Одним из требований гейм-дизайнеров являлся тихий логин на старте без показа попапов. Каково же было мое удивление, когда вызов метода silentSignIn() показал мне окно с подтверждением авторизации! При этом код, который я несколько лет назад лично писал для проекта на кастомном движке, работает корректно до сих пор. В итоге я потратил несколько дней на то, чтобы отказаться от стандартного решения в пользу кастомного.

Что касается производительности, с ней в Unity все ужасно. Многие решения делаются на скорую руку, лишь бы успеть за рынком. Если не верите, попробуйте глянуть в дизассемблированный код, там много интересного.

4 Кроссплатформенность

Как ни странно, возникают серьезные проблемы при выходе новых платформ. Когда я портировал игру на Nintendo Switch, версии Unity под нее отсавали от основного релиза на пару месяцев, крашились при любом удобном случае, а 50% функциональности движка в принципе не работала (и не работает до сих пор). В итоге дошло до того, что мне пришлось патчить скодегененный il2cpp-код, иначе игра не запускалась в принципе (это решение так и ушло в продакшн). И тут опять мы возвращаемся к проблеме $100K.

5 Сотрудники

Я пособеседовал нескольких Unity-программистов. Так вот, их уровень порой просто за пределами добра и зла. Часть людей хочет около 150-200к, но даже не представляет, что есть асимптотика и чем структуры отличаются от классов. Доступность движка для новичков ведет к подавляющему снижению общего уровня грамотности.

И да, в Unity нет нормальной доки.
Все те же самые проблемы (на самом деле гораздо больше, в разы больше) будут и в своём движке, только его нужно писать, поддерживать и править самому или тем самым сотрудникам, которые не отличают класс от структуры, вместо того, чтобы доверить всё большой, опытной команде, которая специализируется на написании движка.
Для меня Unity давно стал показателем некачественной игры. Конечно есть пара хороших (например Pillars Of Eternity), но в основном — качество не очень. И даже у хороших проектов, которые переходили на Unity наблюдаю регресс. Например Shadows: Heretic Kingdoms был на модифицированном Ogre (Ogre Карл) и был вполне неплох, а новый Shadows Awakening — перешли на Unity и поглядите на этих эпилептических мышей. Life Is Strange 2 — резко повысились требования на ровном месте. Проблемы с загрузкой — компилится очень много шейдеров, если у драйвера нет кэша — то это надолго. В общем, складывается впечатление, что хорошие проекты на Unity — не благодаря, а вопреки (и ниже качеством чем было, если с чего-то перешли).

Есть еще всякие мелочи — заставляют ставить в систему MediaFeaturePack, чтобы декодировать h264. Серьезно? А в движок встроить декодер никак? Да тот же ffmpeg поддерживает и аппаратное ускорение.
Ох, насколько же движки больная тема. Смотришь на Unreal и не знаешь, что с ним делать. С одной стороны, куча инструментов, сообщество, готовое решение 80% всех возможных задач. С другой стороны, тесная интеграция с Physx, трудности с использованием сторонних библиотек и невозможность встраивания в ПО без переписывания самого движка.
после id tech 4 ничего в опен сорс не отдали, инструментария для моддинга игр не выпустили, кроме как для Rage.
И это очень печально. Когда-то Тим Виллитс рассказывал, как получил работу в id во многом благодаря ориентированности Кармака на открытость и вовлечению, поощрению компанией создания контента со стороны. Уже тогда можно было заметить, что сам Виллитс не очень-то разделяет взгляды бывшего патрона, но сейчас это стало очевидно всем.

Удивительно, конечно, как изменились времена. Десять лет назад id спокойно выпускала Quake 4 SDK с примерами SP- и MP-модов, карт, model и texture reference'ами, а теперь стараются всё максимально огородить, запретить и непущать. Какой и кому от этого прок? Сами же лишают себя кучи годного и при этом бесплатного контента.
А так, может быть народ наваял бы ремейк RtCW
В сложившихся условиях любой движок — это трата времени. Это только кажется, что мы делаем только то, что надо. На самом деле в процессе прототипирования игры хочется попробовать разные варианты, в случае готового движка — это как раз-два, а в случае своего — это месяцы работы на мусорную корзину. Я серьезно. Я делал игры без движка. И делал свой движок. Это печаль. Статья длинная, а вывод один — если у вас нет кучи денег, чтобы не жалко было потратить их впустую, даже не стоит начинать. Ну а если вы индивидуальный разработчик… Думаю и тут ответ очевиден. Хоть Unity и Unreal — не очень, но выбора особого нет. К тому же кто мешает потратить свою творческую энергию на крутые плагины для Unity?
Удваиваю. Есть еще понятие как стоимость владения. Т.е нужно в стоимость вкладывать не только время разработки движка, но и стоимость его доработки, фиксов и т.п на все время существования проектов, основанных на этом движке. Т.е посыл статьи — «пишите отдельный движок под каждый проект, максимально подходящий для этого проекта, причем на максимально удобном языке для всех, кто будет его саппортить», а это означает 100500 движков внутри одной конторы и на каждый нужно содержать команду, которая знает как оно работает внутри. Это просто не работает. По этой причине все больше и больше контор отказывается от своих велосипедов (потому что дорого) и переходит на unreal / unity.

Скажем, в соседнем офисе сидят люди, которые делают движок. Каждый, кто пытался исправить баг в универсальном движке, то есть написать в багтрекер Unity или Epic, знает, что лучше даже не начинать. А если разработчики сидят в соседнем офисе, то вы можете к ним обратиться и решить вопрос за 15 минут.

Опять же — чтобы были разработчики по соседству — их нужно постоянно оплачивать, а фиксы для движка одной игры, выпущенной 3 года назад могут иметь нулевой приоритет перед всеми новыми играми, выпущенными на чем-то другом.
По поводу фиксирования багов в больших движках. Не знаю, как в unreal, но юнитекам отправляю баги регулярно и они их чинят, пусть и с задержкой в 2-6 месяцев. Да, чем дальше (после прихода нового CEO), тем становится хуже первая линия саппорта по регистрации тикетов. Просто начинаешь прямо требовать, чтобы убрали эту обезьяну и передали тикет квалифицированному специалисту — помогает. В форме фидбека есть встроенный фильтр «swear words», приходится довольно долго подбирать синонимы :)
Законспектировал статью:
Разработка своего движка оправдана, если

1. Особые возможности игры тяжело реализуются на существующих движках, но легко пишутся с нуля (пример с Майнкрафтом)

2. Движка нет (сюда включаем случай, когда он недоступен по финансовым причинам)
автор же в статье описал — платформа для телевизора )
или для дешевых телефонов (правда, как продавать такие игры — разве что по соглашению с вендором, который хочет оснастить свои черно-белые телефончики новым монохромным хитом)
В любом случае, для таких платформ можно взять готовый код, сделав лишь специфические платформенные функции.
Главную то причину не указали. Если вы делаете игру в прицелом на 8-9 значную прибыль в долларах, то стоимость лицензирования становится абсурдно велика и намного дешевле нанять армию сеньоров и написать свой.
Когда игры на новом движке появятся, тогда и оценим труды. С нетерпением ждём.
В своем движке я столкнулся с интересной проблемой: UI компоненты делались по мере надобности, а не методом «реализовать все возможные контролы с всеми возможными вариантами использования». В итоге код каждого контрола переписывался много раз, кое-где оброс костылями, а всякие Progress Bar вообще не вошли в библиотеку и каждый раз реализуются по-разному. И, как водится, без юнит тестов.
Уже отлично видно, что это огромная самовыкопанная яма и выбраться из нее можно только если таки сделать шаг назад и таки сделать отдельно библиотеку базовых компонентов и тесты для них. Может даже попробовать имитировать частично UI стек готовых решений, а-ля wxWidgets или QT.

Может кто-то встречал гайдлайны «базовые UI компоненты и какими свойствами они должны обладать»? Или может имеет опыт и желание заняться чем-то таким? :)
Я сейчас как раз этим занимаюсь, пока выходит, что достаточно всего одного типа с вложенными дочерними компонентами, с возможностью скролла и переопределяемым поведением при нажатии. Скроллбар в таком случае — просто список с 1 элементом, который перемещается в границах родительского. Кроме скроллбара, таким образом легко получаются контейнеры для элементов, горизонтально и вертикально скроллящиеся одномерные и двумерные списки, кнопки, просто спрайты. По UX и API ориентируюсь на Android, чтобы сделать похожим на другие платформы — нужно просто текстурку поменять.
А чем не устраивают готовые nuklear, ImGUI?
Есть еще основы типа github.com/randrew/layout
Можно очень красивые интерфейсы сделать на этих штуках. А всякие красивости на шейдерах.
wxWidgets можно сразу выкинуть, на маке отрисовка текста через CTLineDraw и тормозит.
QT можно, если размер не важен, но если сами будите пересобирать — можно больше времени потратить.
Готовые не устраивают тем, что есть уже свое рабочее решение, на нем написано сколько-то игр и впиливать вместо него что-то совершенно чужое, на другом языке смысла нет.
Но смысл есть выбрать какую-то готовую GUI библиотеку за эталон и привести свое решение к аналогичной архитектуре, вплоть до совпадающих методов. Банально, можно будет и чужие редакторы подключить, и просто на чужом опыте многие подводные камни пройти.
Я о том и говорю, что в случае собственных UI фреймворков, разработчики часто реализуют лишь то, что надо их проектам, а условия иногда меняются и мы получаем игры, где в поле ввода нельзя вставить текст из буфера, списки без быстрого поиска, тексты без поддержки стилей и т.д.
Очень интересно послушать сколько своих движков написали программисты этой компании, и сколько проектов они выпустили на них. Судя по статье у вас большой опыт в этом деле.
Как я уже говорил, мы делали браузер, который занимает 2.5 мегабайт памяти, там есть JavaScript-движок, который проходит все тесты.

Вот про это следующую статью, будьте добры.
к черту статью, пускай сразу дают ссылку на дистрибутив
Ох, прекрасно помню я этот доклад. А еще помню девочек на Вашем стенде, которые на мой ответ «Unity разработчик» ответили «Фу, Юнити, он же такой забагованный, а вот у нас свой движок!.»

Так вот, если у Вас есть ресурсы на свой движок — прекрасно. А для подавляющего большинства, в том числе и себя, я не вижу смысла заниматься этим. X-Ray с 1998 по 2011 GSC так и не довели до ума.
А конференция была отличная, уважение Александру Хруцкому и команде.
Видимо, свой движок сразу без багов пишется. :)
И правильно!
Зачем в него писать баги, а потом их долго вылавливать??!
Девочек мы все любим не за их мнение о движках… ;-)

Про X-Ray стоит послушать самих создателей X-Ray, которые теперь в 4A. По их же словам, под новые требования, например стриминг, проще написать новый, чем править старый. А судя по последнему Метро, в движках они что-то понимают.
А что такое «маленькая c», если не секрет?
К черту причины. Как к вам устроиться? =)
А какое направление вас интересует?
Пишите на почту job@socialquantum.com С удовольствием пообщаемся!
Sign up to leave a comment.