Зачем писать свой игровой движок?

    В декабре прошлого года, на конференции Games Gathering 2017, мы сделали доклад, в котором рассказали о том, надо ли компаниям, работающим в игровой индустрии, писать собственные движки.



    Unity в условиях многообразия игровых движков



    Зачем в современном мире, в котором существуют такие гиганты, как Unity, делать что-то своё, писать собственные игровые движки?

    Перед вами слайд с данными компании Unity Technologies по использованию различных игровых движков в 2017 году. В следующем году ситуация, как вы понимаете, поменяется. Нас интересует то, чему тут отведён 41%, то есть — движки собственной разработки. Если взглянуть на 5 самых больших компаний, представленных на конференции, то у каждой из них будет свой движок. Получается, что в большей части компаний, представляющих игровую индустрию, используются какие-то внутренние разработки. Далеко не всегда это — самое разумное в мире решение, но это так.

    Из каких базовых технологий могут выбирать компании, задумывающиеся о разработке игрового проекта?

    Армия семи наций



    Пирамиду, которую вы видите на слайде, можно продолжить и вверх, и вниз. Она абсолютно чётко вас ограничивает. Снизу — операционная система, ещё ниже — какие-то базовые технологии. Сверху — аддоны над движками, готовый инструментарий, который поставляют с играми, вроде инструментов Neverwinter Nights. Что бы вы ни делали, вы, так или иначе, оказываетесь внутри этой штуки.

    Предположим, я хочу оказаться на втором уровне этой пирамиды снизу. Однако все пути, в итоге, ведут в верхнюю часть пирамиды. Мы будем использовать и что-то из существующего, но весьма важно и то, что можно видеть в левом верхнем углу верхнего уровня пирамиды, то есть — движки собственной разработки.

    Теперь проанализируем затраты времени, сил и средств, необходимых на разработку игры.

    Назад, к основам



    Если вся показанная на слайде круговая диаграмма — это игра, то движок — это её синий сектор. В идеальном мире, разрабатывая игру, вы можете вынуть этот синий сектор и поставить туда красный, или желтый, или зеленый. Можно одно большое «U» поменять на другое большое «U», или взять некое маленькое «x», и то, что вы выбрали, там тут же заработает. В реальности это не так, но мы должны к этому стремиться. Подобная картина, если речь идёт о реальных проектах, наблюдается в игровой индустрии постоянно. Бывает и так, что вся эта диаграмма занята движком, но это справедливо лишь для каких-то демонстрационных продуктов.

    При этом деньги, время и всё остальное распределяется именно так. Чтобы вы ни делали, вам придётся заниматься еще всем тем, что попадает в зелёную область диаграммы. Она от движка к движку не меняется. В результате, если у вас есть ресурсы, достаточные для поддержки всего процесса работы над игровым проектом, то разработка движка окажется не такой уж и дорогой. Однако если кто-то в компании начинает говорить о разработке собственного движка, он, вероятнее всего, столкнётся с определённым набором возражений. Рассмотрим их.

    Мифический человеко-месяц



    Предположим, вы решили создать собственный движок и сообщили об этом человеку, принимающему решения. В ответ вы услышите примерно то же самое, что можно видеть на слайде: «Делать ты это будешь долго, это очень рискованно, это нерационально, это не поможет нам достигнуть наших целей». Что можно на это ответить? Дело тут в том, что все эти возражения, кроме последнего, не выдерживают никакой критики.

    Долгая разработка движка? Но если разработка с собственным движком пойдёт быстрее, то это — не аргумент. О том, что такое «рационально», пожалуй, вообще никто не знает. Поэтому все эти возражения очень субъективны.

    Последний пункт, касающийся того, способствует ли свой движок достижению целей — это очень важно. Если ваша цель — заработать благодаря получению гранта от Unreal 4, то, наверное, свой движок делать не надо, потому что он не ведёт к этой цели. Если у вас есть цель, в рамках которой вам надо что-то делать на определенных технологиях, то не надо писать свой движок — надо брать то, что есть. Но эффективно использовать готовые движки можно далеко не всегда. Зачем же, всё таки, писать свой движок?

    13 причин почему



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

    • Time to Market — срок вывода продукта на рынок. Это — по-настоящему серьёзно. Половина из тех движков, которые сейчас используются в больших компаниях, разработаны именно потому что в тот момент, когда этой компании надо было быстро быстро занимать нишу, разработать своё было быстрее, чем взять что-то чужое и осваивать это.

    Вот вам история. В одной компании на сайте было задание для программистов, выглядящее примерно так: «Ребята, если хотите у нас работать, напишите пожалуйста «Астероиды», которые должны запускаться на платформе Android без использования внешних библиотек. Мы считаем, что на это вам достаточно 8 часов. Время пошло». Потом время увеличили до 12 часов. Может быть, выглядит это смешно. Сначала я наблюдал за этим, снаружи, потом заглянул в эту компанию и попросил рассказать мне о том, что прислали в виде отклика на это задание. Как оказалось, отбор прошли больше двухсот программ, то есть — эти программы запускались и работали. Это значит, что если вы вдруг захотите издать «Астероиды» для Android, то найдется как минимум 200 человек, которые могут это сделать за 8 часов. Я не говорю, что это можно продавать. Но рассказал я эту историю к тому, что очень часто, собственно, движок — это и есть Time to Market. Скажем, просто потому, что у вас такие маленькие потребности, что вы дольше будете изучать документацию на тот же Unreal, чем просто взять и сделать своё.

    • Lord of the Platform — властелин платформы. Существуют платформы, для которых нет готовых инструментов. Например, STB, set-top box (ресивер цифрового телевидения) — коробочка для кабельного телевидения, которая стоит на столе у каждого третьего американца.

    У Warner имеется 120 миллионов пользователей этой услуги. Если вы пишете туда софт, и игры в том числе, то вы имеете доллар с коробки. Это 120 миллионов долларов в год. При этом кроме вас писать для этой штуки не может больше никто. Потому что там нет DirectX, там вообще ничего нет. Если вы умеете писать программы для STB — то вы властелин платформы, вы имеете эти сто двадцать миллионов долларов в год. Чем не повод писать свой движок?

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

    Можно говорить, что нас интересуют телефоны, но речь идёт о миллионах долларов. Почему бы не писать для других устройств? В результате, есть абсолютно четкие причины это делать.
    Или, например, перед нами новейшие смарт-часы. SDK к ним ещё не вышел, никто не понимает, что с ними делать, а если вы сможете, своими силами, написать для них качественный продукт, то вы, скажем, заработаете по доллару с каждого такого устройства. Если их будет продано два миллиона — то вам достанется два миллиона долларов. Написать это несложно, но для этого надо делать свой движок, потому что чужих нет, а компании-производители таких устройств не будут делать общедоступные движки для разработки под них.

    • Weak but proud devices — малые, но гордые устройства. Если вы делаете игры для мобильных телефонов, собираете хоть какую-то статистику, то вы знаете, что с аппаратным обеспечением у устройств от Apple всё более-менее нормально, а вот с платформой Android — просто беда.

    Половина устройств на рынке построена на базе чипсета Mali-400 от ARM, любой бюджетный телефон это Mali-400. И если вам платят за то, что вы занимаетесь телефонными приложениями, то вы должны писать для этих вот маленьких, но гордых устройств, которые пока уходить с рынка не собираются и уйдут с него очень нескоро.

    При этом в случае с iPhone можно делать хоть какие-то ставки на прогресс. Например, ожидается, что Unreal будет работать под iPhone 10, хотя пока всё это доведут до ума, будет уже какой-нибудь iPhone 12, 15 или 17. А вот в случае с миром вообще в краткосрочной перспективе на прогресс ставить тяжелее. Потому что апгрейд устройств происходит очень медленно.

    Если вы хотите конкурентную картинку, и если это очень важно, вы не идёте на маломощные устройства. Но вы должны учитывать, что все современные движки не очень масштабируются вниз. Если же вы не хотите конкурентной картинки, то, соответственно, учитываете возможности слабых телефонов. Поэтому, если вы находитесь в ситуации, когда вам интересны не самые быстрые устройства, например, вы — единственный дистрибутор где-нибудь в Португалии или в Бразилии, то вам придётся об этом задуматься.

    • Own language for own ideas — собственные языки для собственных идей. Когда вы сами делаете движок — вы можете задействовать эту концепцию. Дело в том, что основная проблема нашей индустрии в том, что домен геймдизайнера — это филология. Он мыслит на обычном языке. Он ничего другого не умеет. А программист мыслит в домене программирования и между ними пропасть. Как результат, некая итерация, которую приходится непрерывно повторять, стоит, например, два доллара. И вы постоянно тратите эти деньги.

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

    • Unique Mechanics = Unique engines — уникальные механики = уникальные движки. Мои знакомые писали Minecraft в пятнадцатом году с использованием Unity. Был ли смысл всё это делать — вопрос открытый. Но движок они выбрали и принялись за работу. Однако движок им, очевидно, очень мешал. Им было тяжело. У них были очень долгие итерации. После того, как мы их проконсультировали, они написали, буквально за три дня, собственный рендер. Причём весь остальной код, ответственный, скажем, за построение мира, естественно, никуда не делся. Просто всё это перестало быть в C#, перестало быть в Unity. И работа закипела. Не знаю, удалось ли им на этом заработать, но главный вывод из этой истории заключается в том, что им изначально не надо было использовать Unity.

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

    • The game is not a render — the game is everything else — игра это не рендер, игра — это всё остальное. Мы об этом уже говорили. Если у вас проблема только в том, чтобы нарисовать что-то, или, скажем, использовать звук, делая многоплатформенную игру, то в рассмотренной ранее пирамиде можно было видеть подобные истории. Если вы говорите: «Я хочу проигрывать звук на трёх платформах», то вам для этого не нужна большая «U» — маленькой «c» будет вполне достаточно.

    Причины для разработки собственного движка мы рассмотрели. Остановимся теперь на том, какие преимущества даёт компании разработка собственного движка.

    Преимущества разработки своего движка



    Рассмотрим преимуществах разработки своего движка, опираясь на основные идеи, вынесенные на слайд:

    • Buying is often better than mortgage — покупка часто предпочтительнее ипотеки. Игровая разработка — это, так или иначе, деньги. Есть способы монетизации, при использовании которых покупка не просто лучше, чем ипотека, а это просто единственно возможный вариант.

    Если кто-то работал на мобильных технологиях, то вы всё понимаете. Если на коробке движка написано: «10 процентов роялти», то это категорически неприемлемо, вы не заработаете столько. У вас может быть прибыль сто процентов, но вы работаете из 2-х. То есть, если у вас есть роялти, то это чисто экономическая причина отказа от движка. А надо сказать что три, точнее — два из самых популярных на сей момент движков — это как раз вопрос отчислений. То есть такой вариант сразу отпадает.

    • Specificity is better than universality in the long term — на длинной дистанции специализированные инструменты всегда лучше универсальных. Очевидно, что универсальность всегда медленнее, она менее производительна и менее специфична, чем специализированные вещи. Движок, написанный под конкретную задачу, справится с ней лучше и быстрее, чем универсальное средство. На длинной дистанции специальные инструменты гораздо выгоднее, чем универсальные.
    • Tools and pipelines are developed within — пайплайны и средства разработки, созданные внутри компании. Любой движок, придуманный людьми вне вашей компании, ориентируется на несколько вещей. Первая — это best practices. То есть ориентируется движок другой компании не на то, как ваш художник рисует, а на то, как рисуют художники, идеальные с их точки зрения. Вполне возможно, что ваши художники рисуют по-другому. У них свой пайплайн и у них это получается.

    У вас есть 2 варианта действий: либо их переучивать так, как положено с точки зрения best practices, либо использовать своё. Есть простые примеры. Предположим, вы говорите: «Мы импортируем 3D-модели». Вы не знаете — что там с той стороны. Поэтому вам нужен промежуточный формат. Промежуточный формат пускай будет FBX. Огрехи FBX все, кто этим занимаются, знают. А вам некуда деваться, потому что вы не знаете, что там будет делаться, вы не будете писать плагины под 450 средств 3D-моделирования.

    Когда вы работаете внутри своей компании, то вы можете реализовать тот самый пайплайн, который у вас уже существует и надеть на него сверху то, чем вы занимаетесь. На самом деле, это очень важно. Дело в том, что всё это имеет отношение ко времени разработки и, как следствие, к стоимости. Поэтому, когда вы разрабатываете у себя, вы можете утилизировать тот пайплайн, который уже есть. Иначе у вас документ, который называется «Правило выгрузки 3D-моделей и создания материалов для художников» будет больше, чем дизайн документ, а это неправильно.

    • Reaction time — время реакции. Речь идёт о времени реакции производителя движка на ваши обращения, о возможности оснащения движка новым функционалом, и об оперативном исследовании новых технологий.

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

    То же касается и предложения нового функционала, если у вас есть на это право. Исследование новых технологий так же упрощается при использовании собственных движков.
    Предположим, ваш программист съездил на конференцию, послушал там лекцию о чём-то новом. Он тут же это попробовал, вы получили представление об этом новом и знаете, нужно оно вам или нет. Вы можете прямо-таки реактивно пробовать что-то интересное из мира науки. А это, кстати, значит, что в компании может быть человек, который будет называться «исследователь». При этом исследованиями можно заниматься и на том же Unreal, поскольку он поставляется в исходниках.

    • Performance — производительность. Игровая индустрия — это всегда производительность. Первый подход достижения высокой производительности заключается в использовании специальных решений. Чем более специфичные решения — тем они производительнее. Второй подход — тоже, кстати, уважаемый, это оптимизация готовых движков. Как именно это будет выглядеть — сильно зависит от этих движков.

    Разработка собственного движка — это не только преимущества. Это ещё и риски. Рассмотрим их.

    Риски, связанные с разработкой своего движка



    Рассмотрим риски сопровождающие разработку и использование собственных движков:

    • Development time — время разработки. Это понятие пересекается с тем, что мы говорили о времени выхода на рынок. Разработка движка может быть и очень долгой, и достаточно быстрой. Но время разработки движка, в любом случае, вносит вклад в общее время разработки проекта. Поэтому это тоже риск. Например, мне известны коллективы, у которых время разработки движка стремится к бесконечности.
    • Terminal cases of vendor-lock — терминальные случаи привязки к поставщику. Это относится не только к большим компаниям, но и к маленьким. Скажем, вы наняли Васю, он написал движок, потом влюбился, от вас уволился, и в том, что он написал, не понимает никто. В результате у вас vendor-lock похлеще Google. Потому что в Google еще можно письмо написать, хотя они и не ответят, а здесь с уходом программиста всё закончилось. В результате — потерянное время на разработку и другие неприятные последствия. Надо уметь избегать этих рисков.
    • Reinvent the wheel — изобретение колеса. Тут дело в том, что мы живём в мире, в котором вы всё равно изобретаете велосипеды. При разработке движка получается перенос велосипедного завода из кода игры в код движка, хотя там им и не место.
    • Closed ecosystem — закрытая экосистема. Всё, что делается внутри компании, принадлежит этой компании. Я знаю кучу компаний, у которых есть что-то вроде своего скриптового языка. Это может быть какой-нибудь XScript, который работает только в рамках их решения.

    Программисты, которые знают эту технологию, по сути, ничего больше не умеют. Это можно считать одним из факторов, помогающих удерживать сотрудников. Поэтому ответ на вопрос о том, хорошо это или плохо, является ли использование собственных технологий риском, зависит от конкретной ситуации. Мы, например, стараемся не использовать концепций собственного изобретения. Например, мне известна одна компания, у которой есть Lua, строго типизированный, с паскалевским синтаксисом. Это можно освоить, но это знание мертвое, как греческий язык. Мы так стараемся не поступать.

    Главный вопрос жизни, вселенной и всего такого



    Рассмотрим очень важный вопрос. Какой ресурс требуется в первую очередь для разработки собственного движка? Ресурс, без которого бессмысленно задумываться о том, надо или не надо делать собственный движок. Ответ на него, конечно, не 42. Вопрос в том — что вообще нужно, чтобы просто хотя бы иметь возможность сказать: «Да, у нас хоть что-то есть, мы можем начать что-то делать». Ответ на этот вопрос заключается в том, что для разработки собственного движка нужны программисты.

    Программисты



    Для того чтобы создать собственный движок, нужны программисты. Если не знаете — погуглите разницу между словами «developer» (разработчик) и «programmer» (программист). Это очень важно. Девелоперы — это основная группа. Игровая индустрия так устроена, что большинство людей в ней программистами назвать нельзя. Извините, но они разработчики. Разработчики не способны грамотно сделать движок. Опять же, если взглянуть на разницу между первыми и вторыми, то разработчики делают игры, а программисты делают инструменты. Разработчики делают продукт, компания зарабатывает за счёт продукта, но инструменты должны быть сделаны программистами, иначе они просто не будут работать.

    С одной стороны, сейчас очень открытый мир. Я, например, знаю код Unreal 4 и CryEngine, он открыт. Все, кто хотят знать, могут узнать код Unity, есть огромное количество соответствующих материалов. Это значит, что этим способен заниматься тот, кто является программистом и читает по-английски. Там нет какого-то rocket science. Но с другой стороны, как выяснилось, программистов, которые читают по-английски, найти очень непросто. Поэтому вы должны знать, где они водятся, должны уметь их набирать, использовать, поощрять. Если вы это умеете, то можно уже и о своём движке задуматься. Если у вас таких людей нет, то у вас всё равно ничего не получится. Примеров тому — тьма. Дело не в том, что есть плохие и хорошие решения. Просто есть такие вещи, которые не могут работать изначально.

    Программистов надо уметь нанимать. Умеете нанимать — можете делать движок. Не умеете нанимать — тогда надо брать что-то готовое. Причём, самое смешное, что когда вы берете что-то готовое, то вам, если вы — большая компания, всё равно понадобится два человека вот из этих программистов, читающих по-английски.

    Если для разработки движка нужны программисты, то у нас сразу же возникают несколько вопросов. Где искать программистов? Как организовывать их работу? На что стоит обращать внимание, размышляя о путях развития игровых компаний?

    Техническая эпидемия



    Сейчас уместно вспомнить ещё об одном аспекте поиска сотрудников, который касается, преимущественно, больших компаний. У таких компаний есть несколько подходов к подбору персонала.

    Во-первых, можно набирать людей, джунов, устраивая интернатуры, и, обучая их внутри компании, каким-то образом растить до нужного уровня. Это — нормальный подход. При этом решается и множество технологических проблем, потому что с человеком, который изначально воспринимает корпоративную культуру и изучает определённые технологии, легче найти общий язык.

    Во-вторых, есть подход, который мы, в принципе, и исповедуем. Как работает кефир? Он всё вокруг превращает в себя. Берёте молоко, кидаете туда кефир — и нет молока, всё превратилось в кефир. У нас это выглядит так: «Ребята, давайте возьмём 5 сильных программистов, это будет внутренний технологический центр». И я всем говорю, что если вы можете себе позволить сделать RnD-отдел, если вы — большая компания — то сделайте. Пускай они даже ничего, с точки зрения денег, полезного не делают. Если компания укрепилась на рынке и перед ней возникает вопрос о том, куда расширяться, то ответом на этот вопрос может стать создание RnD-отдела. Когда компания уже богата, для неё это не потеря денег, потому что она столько денег теряет уже на том КПД, на котором сейчас работает наша игровая индустрия, что расходов на исследования просто не заметит.

    Теперь рассмотрим подход, который заключается в том, что в компании организуют команду, которая делает движок или какие-то другие интересные вещи. Это — работа на будущее. Вы можете проводить собеседования, говорить о том, что вы даёте деньги, у вас интересная задача, вы делаете движок. Вы можете выбирать из соискателей, люди к вам идут, и внутри компании у вас всегда есть такая атмосфера, когда вы человека можете мотивировать, поощрять и в результате достигать поставленных целей.

    У меня, скажем, какие-то модули разрабатываются продуктовыми компаниями, потому что им это надо. То есть, заказана физика, и вместо того, чтобы пилить какие-то свои штуки, мы говорим: «Давайте так. Мы просто придумываем общие интерфейсы, несколько генерализированных, и вы будете это делать». А в рамках типовых задач это очень хорошо. То есть, в принципе, хорошо распространять технологии внутри компании.

    Если компания уже настолько большая, что может себе позволить делать что-то интересное внутри себя, то это окупается даже с точки зрения денег. Поэтому если можете — то пробуйте. Выглядеть это может как угодно — скажем, делается своя ветка Unreal и там перерабатываем всё так, как хочется вам. Я, например, в одной из компаний делал браузер, который помещается в 2.5 мегабайт памяти. И он работал. Зачем — я не знаю, но это было бесконечно интересно.

    Выше мы упоминали о проблеме игровых компаний, которая заключается в организации эффективного взаимодействия программистов и дизайнеров. Остановимся на этой проблеме подробнее.

    Два мира



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

    В игровой индустрии соседствуют два мира. Люди либо ориентированы на решение технологических задач, либо на нарратив. А посередине — кустарщина какая-то. То есть, инструментария практически нет. Слова, слова, слова — бах — код. Опять слова — и опять код. Мы считаем, что требуются инструменты, которые позволяют подключать к тому, что получится в результате работы над игрой, геймдизайнера, менеджера, других сотрудников, не являющихся программистами.

    На слайде можно видеть behavior tree, дерево поведения. В принципе, это штука, просто взятая из википедии, но перед нами её оттуда взял Unreal. Ничего страшного в этом нет. Итак, документация к этому лежит на сайте Unreal, нам было несложно сделать подходящий интерфейс, совместимый с тем, что делается в Unreal. То есть, можно взять любой пример с анриловского сайта экшнов, пример самого поведения, так как формат вполне совпадает, вот так вот переписать, и оно заработает. Это значит, что я облегчил себе жизнь, я не пишу документацию. И таких штук здесь много.

    В примере со слайда что-то происходит, бегает краб, кого-то ловит, в общем-то, это неважно. Внутри программист решает задачи, которые выглядят как «пойди в…», «стрельни в…», «посчитай расстояние» — и всё. Всё остальное поведение написано в этом редакторе человеком, который не имеет абсолютно никакого отношения к программированию. И это работает, в отличие от перевода текста в код. При этом если говорить, скажем, о балансе. Что такое баланс? Это — 15 коэффициентов, которые можно менять. А здесь описано поведение, а не коэффициенты.

    То есть, например, поведение «патрулирование» описано геймдизайнером, а не программистом. Это значит, что мы сделали тот шаг, которого большая часть людей не делает. Они просто пишут в дизайн-документе: «патрулирует». А программист это может перевести 50 разными способами. Что такое вообще патрулирование? А здесь геймдизайнер пишет именно то, что он имеет в виду. И это победа, друзья мои. Именно для этого вам нужны собственные инструменты. Для того чтобы сглаживать переход от вербального определения вашего визионера, который видит игру, так сказать, внутри головы, до программистов. А иначе они перестанут быть программистами, станут девелоперами и всю жизнь будут рассаживать травку.

    Итоги



    Подведём итоги. Мы говорили о поводах писать свой движок. Скажем, если вы смотрите назад, на устаревшие устройства, то это не хорошо и не плохо. То есть, вы хотите, чтобы ваши игры запускались на некоем диапазоне устройств, которые сейчас уже не поддерживаются коммерческими движками. При этом вы хотите современно выглядеть. Как этого добиться? Писать своё.

    Вы хотите владеть платформой? У вас специфический проект, который просто не требует использования универсальных решений? Или у вас, наоборот, очень большой и сложный проект со специфической картинкой? В этих ситуациях, опять же, можно задуматься о своём движке. При этом для того, чтобы сделать свой движок, нужны ресурсы. А ресурсы — это программисты.

    В результате, если вы имеете поводы писать свой движок, и у вас есть ресурсы — берите и пишите.

    Вопросы и ответы

    Вопрос


    Какова стоимость вашего движка, если оценивать её в деньгах и в трудозатратах?

    → Ответ


    Сколько это стоило в деньгах, я, наверное, сейчас не могу сказать. А если говорить о трудозатратах, то это девять месяцев команды из шести человек. Но надо понимать, что это наша последняя разработка, и тут мы целимся достаточно высоко. Я не рассказываю о нашем наборе инструментов, о том, что мы делаем с Lua, или о том, что мы делаем с JavaScript такого, что не делает вообще никто. Мы планируем выпустить в опенсорс пару модулей, которые, если и не перевернут индустрию, то, как минимум, помогут людям осознать — что такое скриптовые языки. Наш предыдущий движок делали два человека четыре месяца. Он — тоже 3D, но попроще, телефонный. Можно быстрее, я уже рассказывал, как «Астероиды» пишут за 8 часов, но это, конечно, далеко от реальности.

    Вопрос


    Сколько времени потребовалось на реализацию дерева поведения?

    Ответ


    Это я могу точно сказать, делалось это совсем недавно. Два человека занимались этим месяц. Но проблема тут шире, чем создание дерева поведения. Дело в том, что экшны у нас пишутся в Lua, занимает это, наверное, дня четыре, а написать редактор на Qt — месяц.

    Вопрос


    Насколько я понимаю, вы используете Lua, у вас есть экшн-система, которую вы изначально написали, а дерево поведения просто дёргает эти экшны?

    Ответ


    Да, так и есть. На самом деле, мы работаем над тем, чтобы вывести это в опенсорс, пишем документацию, систему сборки, примеры.

    Вопрос


    Наша компания имеет очень схожие взгляды с вашими, и проблемы у нас тоже интересные возникают. Хотелось бы узнать — какое у вас соотношение трудозатрат на игру, на движок, на инструменты? То есть, сколько людей, например, работает над движком, над игрой, сколько игр используют один движок?

    Ответ


    У нас сейчас два движка, предыдущая редакция и новая. То есть это не рефакторинг. Это полностью новый движок. Если говорить о трудозатратах, то можно сказать, что компания у нас большая, работает около 500 человек, программистов около 250, 5 офисов. Проектная команда работает над играми. Проект — это некая игра, и ей занимается некоторое количество людей. Команда разработки движка — это отдельный коллектив. Это — тот самый кефир, о котором я говорил, элитные подразделения, там немножко другие деньги и подходы к формированию команд. Сейчас мы немного обгоняем разработку. Две новые игры запущены на новом движке. Это достаточно мучительно, так как разработчикам игры не очень комфортно, потому что они работают в ситуации, когда у них что-то может буквально из-под рук взять и взорваться. И у нас команда движка — это 6 человек. Команды продуктов — это, в среднем, человека по четыре программиста, они не пересекаются.

    Вопрос


    Под движком вы подразумеваете и инструменты тоже?

    Ответ


    Да, у нас есть отдельная команда по разработке инструментов. У нас был очень неудачный пример. Очень плохо разрабатываются GUI-инструменты. Потому что любой нормальный программист считает, что это очень просто. Мы попытались это аутсорсить. Потому что понятно — ты отдаёшь полный интерфейс, у тебя всё есть, ты говоришь: «Создай окно, нарисуй кнопки — и всё». Но эта затея провалилась, поэтому сами делаем, мучительно работаем с Qt, потому что нам важно, чтобы это работало на всех трёх настольных платформах. Поэтому сами делаем. И у нас 6 человек делают и то, и другое, и третье. Но мы всё равно находимся чуть впереди запросов продукта.

    Вопрос


    Реально ли сейчас продать свой движок?

    Ответ


    Нет. Сейчас нельзя продать свой движок. Можно продать экосистему. То есть, работать по схеме «дай мне денег, а я тебе дам движок» нельзя. Обратите внимание на то, сколько у нас компаний имеет собственный движок, и сколько из них движки продаёт. На самом деле — никто из них движки не продаёт. Для начала — это достаточно большая головная боль с точки зрения того, что это надо превратить в продукт. То, что у вас работает внутри компании, никак нельзя продать. Вы должны, как минимум, написать документацию, которую поймут окружающие. Вы должны нанять просто какую-то армию волонтёров, которые будут это дело евангелизировать. И не вполне понятно, что вы с этого получите. А если сделать мобильную игру на этом движке, то вполне можно проснуться миллионером. Поэтому, чтобы такие вещи делать, надо быть фанатом, надо быть уверенным в том, что делаете. Я рассказывал о причинах, которые могут привести к разработке своего движка, а у вас тут — ещё одна причина. Скажем, вы думаете, что сделаете движок лучше, чем Unreal. Если это так — идите на рынок. Но я не думаю, что сделаю лучше, чем Unreal.

    Вопрос


    Я так понимаю, что ваш новый движок — это С++ и Lua?

    Ответ


    Да, C++, Lua и ещё JavaScript.

    Вопрос


    А почему C++? Были ли варианты, или вы чётко знали, что именно возьмёте?

    Ответ


    Смотрите, существует такая мода. Каждый второй, кого встречаешь, говорит тебе: «Golang», или говорит тебе: «Rust». И если бы это было сейчас, я бы в принципе задумался. Но когда ты приходишь в компанию руководителем процесса разработки движка, а было это год назад, тебе надо строить какие-то планы, а так придётся включать в эти планы пункт «Почитать о Go». Тут ведь важна производительность, а на C++ мы достаточно давно работаем, умеем им пользоваться.

    А почему мы используем Lua? Потому что это недооценённый язык, он отлично подходит для встраивания. Почему JavaScript? Потому что так получилось. Потому что на рынке кроме V8 и Webkit ничего нет. А это монстроиды. Как я уже говорил, мы делали браузер, который занимает 2.5 мегабайт памяти, там есть JavaScript-движок, который проходит все тесты. У нас это есть, и вот поэтому — JavaScript. В результате, например, можно брать тех, кто знает JS и писал сайты на React.

    Вопрос


    Скажите, вы дерево поведения используете только для управления поведением, или применяете его ещё для управления игровыми механиками и для продвижения игрового прогресса?

    Ответ


    Сейчас для поведения, но у нас еще есть несколько альтернативных механик. У нас есть ещё, скажем, сети Петри с редактором, а тут проблема немножко другая, которая заключается в том, что сети Петри тяжело объяснить гейм-дизайнеру. Есть ещё какие-то вещи с редакторами, которые позволяют нарисовать, скажем, конечный автомат. И мы пытаемся из этого всего что-то сделать. Мне теперь надо заставить тех людей, которые пишут сценарии, писать это вот в таком вот виде. Так что дерево поведения сработало, а остальное пока ещё в рабочий процесс не вошло.

    Вопрос


    Насколько трудно прогнозировать развитие технологий на будущее? То есть, как сложно предвидеть появление каких-то подводных камней и тому подобных вещей?

    Ответ


    На данный момент я вижу одну проблему. Сейчас интересно выглядит технология WebAssembly. Flash умер. Мы хотим, естественно, издаваться ещё где-то на вебе. Портировать игру, скажем, с Unity на WebGL — это задача, которая не решается нажатием на одну кнопку. То есть сейчас мы смотрим на WebAssembly и пока неясно — будет ли это стандартом, или нет, начинать сейчас с этим работать, или подождать. В мобильных технологиях тоже ничего особенного не происходит. Нет пока каких-то сингулярных взрывов, но если будут — будем готовиться.

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

    Social Quantum

    95,00

    Разработчик мобильных игр

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

                                                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                    Самое читаемое