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

Я заметил, что многие крупные и известные разработчики игр часто разрабатывают свои собственные движки. Примеры включают Valve, Crytek, Ubisoft, Epic Games и Square-Enix.

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

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

Существует несколько причин, по которым студия может «строить» вместо «покупать» свои технологии:

• Устаревшие технологии; студия, возможно, начала создавать свой собственный набор инструментов до того, как для него существовало жизнеспособное промежуточное программное обеспечение.
• Особые требования; студия может иметь определенный набор требований, который не очень подходит для существующего промежуточного программного обеспечения или
• Бюджетные проблемы; студия может быть не в состоянии оплатить расходы или договорные обязательства существующего промежуточного программного обеспечения.
• «Не построенный здесь синдром»; Техническое руководство студий может быть осторожным (разумно или неоправданно) в отношении технологии, которую они не создавали, и поэтому не до конца понимают.

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

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

Для других технология может быть основой успеха. Например, студии, которые создают MMO, обычно должны сами создавать эту инфраструктуру, потому что это имеет решающее значение для их успеха (а существующее промежуточное программное обеспечение, как правило, не подходит, по крайней мере для более крупных «AAA» -типов).

Обратите внимание, что некоторые из перечисленных вами студий (в частности, Crytek и Epic) перестали пытаться доминировать непосредственно на игровом рынке и почти наверняка сделали гораздо больше в качестве поставщиков промежуточного программного обеспечения, чем разработчиков игр.

как сказал Джош Петри :

« Не построенный здесь синдром» ;

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

Я тестировал различные типы игровых движков, API рендеринга и тому подобное, в частности, Ploobs, UNITY WaveEngine, XNAFinalEngine, Love, Ogre и т. Д., И многое другое ... Я хотел начать писать игры - я скачал много, ища хороший удобный и хорошо документированная точка входа ...

Моя проблема, однако, была в то время, когда я понятия не имел, что происходит под двигателем. Я хотел хорошего контроля, и я хотел рамки, которые я знаю, как тыльную сторону моей руки. Мне пришла в голову идея «ЭЙ! Я думаю, что единственный способ узнать, как это работает и понять это, - это попытаться создать свой собственный движок целиком и полностью с нуля. Большая часть моей истории программирования была связана с веб-технологиями и решениями для обработки». - это была совершенно новая игра с мячом для меня.

Что я и сделал в итоге.

Поэтому я решил установить XNA, так как я уже знал C #, и начал думать о том, как или с чего мне начать. Мне нужна идея

Я решил, что, несмотря ни на что, я пойду прямо в 3D .

Разобраться с основами было круто - спрайт, но по мере того, как я прогрессировал, я обнаруживал новые барьеры и препятствия - моим первым реальным было ограничение партии . Моя цель состояла в том, чтобы создать игру, которая в любой момент могла бы отображать как минимум 10000 объектов в окне просмотра.

Я приступил к новому пути реализации Шейдерных инстансингов (и изучил HLSL, пока я там занимался), я отказался от встроенных в XNA объектов Model и Effect, чтобы вместо этого написать свои собственные замены. Сначала у меня были проблемы с пониманием потоков VBO; Я ломал вещи - я выходил в интернет, задавая вопросы об инстансинге, и продолжал, пока я, наконец, не понял, что делает GPU. Это окупилось; теперь у меня было более двадцати тысяч тестовых объектов, масштабирующихся в моем окне просмотра после пары дней отладки моего VBO с помощью PIX (dxsdk).

Теперь у меня было «некоторое» представление о том, как работают конвейеры рендеринга, но это еще не было сделано - я закончил тем, что создал свое собственное игровое состояние, камеру, пост-эффекты и объекты-сущности, отодвинув их от XNA Content Pipeline, создав собственный загрузчики (личная неприязнь к объекту XNB), создали сложную цепочку геометрии с сортировкой по глубине и разделенным состояниями, а также имели экземпляры спрайтов и текста, которые проецировались на игровую сцену.

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

Теперь мой двигатель был в основном стабильным и почти законченным. Он не идеален: скрипты честные, а графический интерфейс совсем не великолепен. Но я все еще любил это. Тысячи строк кода, ресурсов и мультимедиа спрятались в частном git-репозитории объемом 2 ГБ, и все головные боли, которые мне пришлось пережить, пытаясь сделать такой тип разработки, которого я никогда раньше не делал. Каждое препятствие, которое я преодолел, было извлеченным уроком и облегчением.

Я снял почти все, что хотел в нем.

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

Этот проект все еще находится в моем репозитории GIT.

Мой второй проход по написанию нового движка (на этот раз на MonoGame) проходит хорошо. Когда что-то ломается, это легче исправить. Меньше беспорядка. Я надеюсь публично показать мою игру где-то в этом году, потому что я, как правило, слишком привязан к своему коду.

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

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

Абсолютная ключевая причина для написания вашего собственного движка (и меня удивляет, что никто еще не вызвал это) для отладки .

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

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

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

Здесь есть очень хорошие ответы, но они упускают один важный дополнительный момент.

Многие из сегодняшних лицензируемых двигателей начинались как специализированные двигатели .

Давайте возьмем Unreal в качестве примера, потому что он такой вездесущий.

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

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

Дело в том, что это проблема курицы и яйца. Каждый бит промежуточного программного обеспечения, который вы можете лицензировать, начинался где-то, и он часто вообще не начинался как промежуточное программное обеспечение (иногда оно даже не было написано с намерением стать промежуточным программным обеспечением, и его текущий статус фактически является случайностью ). Люди пишут свои собственные движки, потому что в конечном итоге кто-то должен писать движок, а сегодняшний выделенный движок может стать лицензируемым промежуточным программным обеспечением завтрашнего дня.

Существуют и другие причины, по которым студия может «строить» вместо «покупать» свои технологии:

• Новые платформы : новая мобильная ОС, консоль или контроллеры. Подумайте о leapmotion, Google Glass и т.д.
• Новая игровая механика и / или внутриигровые редакторы : подумайте о СЭЗ, несколько лет назад (2D против 3D)
• Отсутствие хороших бесплатных редакторов игр с открытым исходным кодом . Отсутствие хорошей документации на существующий источник старых игр
• Эволюция инструментов в студии toolchain (или добавление новых)
• Цены на двигатели и лицензионные войны

Я также согласен с конкретными запросами / потребностями, а цены на двигатели и лицензионные войны вынуждают некоторые студии внедрять некоторые движки.

Хорошие мотивы «купить» или «использовать» другие двигатели:

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

Историческая причина (в основном).
Что связано с ценообразованием.

Каждая игра, которую вы видели в Unreal или CryEngine в последние годы, должна была платить огромную сумму денег. Особенно, если вы хотите получить исходный код (т.е. вы хотели UE, а не только UDK.)

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

• Вы увидите гораздо больше игр, использующих как UE4, так и CryEngine.
  Хотя они не будут ААА-играми, какими они были.
• Пользовательские требования и потребности для каждого проекта не исчезнут.
  См. Движок Warhammer40k / COH в Relic или тот, который генералы использовали в EA.
  Таким образом, даже если кто-то может позволить себе двигатели большего размера, он не обязательно предлагает лучший выбор.
• На рынке есть и другие. Как Единство.
  Людям нравится его простота в использовании, высокая производительность и огромный запас ресурсов.
  Разумеется, Unity может развертываться практически на любой платформе.

Так что да. Потребности, цены в прошлом и тому подобное.

А как насчет организации команды?

За отладочными материалами стоят документация и поддержка, а не код, потому что в конце я не хотел, чтобы моя сборочная группа касалась кода моего собственного движка. Это может быть беспорядок.

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

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

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

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

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

Мой ответ отличается от существующих, поэтому я добавляю его, хотя уже поздно:

Если вы возьмете пример Valve из вопроса или серию «Ведьмак», процесс будет таким:

• Лицензировать двигатель
• Модифицировать / адаптировать движок к вашей цели
• Выпусти игру и заработай деньги
• Создать собственный движок для следующей игры

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

мой учитель программирования сказал нам, используйте только API / методы / классы / функции, которые вы знаете, как построить

потому что, если вы не знаете, как его построить и используете чьи-то рабочие шансы, вы не знаете, как это работает, и когда вы не знаете, как что-то работает, то вы гораздо более склонны к ошибкам и проблемам, а также к стенам путаницы

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

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

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

и иногда текущий игровой движок может не дать мне гибкости в том, что я собираюсь сделать, или даже, может быть, он дает вам такую ​​возможность, но это очень трудно сделать, потому что игровой движок фокусируется на физических силах как на основном источнике движения и манипуляции объекты в игре

во всяком случае, я надеюсь, что я дал понять, на что я пытался указать