Давайте рассуждать разумно
Я считаю, что не существует готового ответа на вопрос, стоит ли разработчику применять движок. Мудрый разработчик перед выбором технологии оценивает все возможные варианты.
Уровень навыков
Достаточно ли у вас навыков, чтобы эффективно использовать выбранный вариант? Если у вас нулевой опыт в программировании, то придётся многому научиться, прежде чем вы будете готовы создавать игру из набора разрозненных библиотек.
Если у вас нет ни технических навыков, ни интереса к их изучению, то вариантов и в самом деле нет — придётся работать с движком (или убедить кого-нибудь заняться технической частью за вас; удачи вам в этом!).
Есть промежуточное состояние между полным отсутствием навыков и профессиональным уровнем. В основном он находится в стране скриптовых языков: Scratch, Game Maker, Pygame, Unreal Blueprints, LOVE2D и т.д. Все они для тех, кто желает получить определённый уровень технических знаний, чтобы быстро достичь результатов.
Если вы опытный/профессиональный программист, способный уверенно освоить стороннее ПО, то можете воспользоваться этим навыком и решить, насколько минималистичным/максималистичным будет ваш подход (будет ли это исключительно минимальный SDL или же полностью оборудованный Unreal Engine).
Цели разработки
Каковы ваши цели в этом проекте? Технологии должны по максимуму упрощать их достижение:
- Для вас это хобби и больше всего вы хотите вырасти как разработчик? Возможно, вам стоит держаться подальше от Unity и Unreal и смотреть в сторону разработки игр на основе более низкоуровневых библиотек.
- Для вас это бизнес? На таком уровне всё становится намного сложнее. Возможные варианты следует оценивать в зависимости от множества факторов: можете ли вы нанимать людей, знакомых с технологией? Хотят ли эти люди использовать технологию? Соответствует ли она вашим временным рамкам? Есть ли у вас навыки для её эффективного применения? Нравится ли технология вашим художникам/дизайнерам?
Интерес
Если вы больше работаете (или планируете работать) с разработчиками, чем в одиночку, то вам нужно оценить, насколько другие люди заинтересованы в технологии. Если вы работаете со старым движком/фреймворком, который все ненавидят, то вам сложно будет найти для своего проекта мотивированных разработчиков.
Подумайте также над тем, как с технологией будут взаимодействовать художники и дизайнеры. Хотите ли вы создавать инструменты, чтобы догнать по функциональности Unreal? Они неизбежно будут сравнивать возможности движка и собственные. Я слышал, что даже у AAA-студий есть проблема с художниками, требующими наличия функций Unreal, которые пока не реализованы в текущем форке Unreal студии.
Если вы работаете в одиночку, то нужно поддерживать в себе сильную увлечённость проектами. Если вы ненавидите технологию, с которой работаете, то скорее всего забросите работу. Если вы бросите, то все ваши усилия пойдут прахом (за исключением бесценного опыта).
Что они дают вам на самом деле?
У Джонатана Блоу есть удивительно мудрое видео о том, что же на самом деле дают игровые движки. Они решают за вас «простые» проблемы, но потом встают на пути, когда пытаетесь решить сложную проблему, из которых и состоят увлекательные игры.
Да, конечно, вы получаете великолепный редактор, инструменты профессионального уровня и движок, который подошёл тысячам разработчиков, но вы расплачиваетесь за него множеством других аспектов:
- Иногда использованные в нём решения слишком обобщённые: возможно, в вашей игре гравитация применяется совершенно новым образом, но тогда вам придётся сражаться с жёстко заданной системой гравитации Unreal. Возможно, вы создаёте проект со сложной сетевой моделью, и тогда вам придётся полностью избавиться от серверной архитектуры Unreal.
- Иногда решения слишком специализированы: если вы когда-нибудь копались во внутренностях Unreal Engine, то видели, что весь движок пронизан кодом шутера от первого лица. Если вы создаёте игру такого жанра, то отлично. Если же нет, то это будет только сбивать с толку.
- Иногда в движке слишком много всего: это создаёт нагрузку и на мозг, и на компьютер. Выполнение полной симуляции физики твёрдого тела, 3D-конвейера со скелетной анимацией и тремя фреймворка — это абсолютный перебор для 2D-игры. Придётся разбираться, как отключить все эти функции Unreal, удачи вам в этом. Лично я нахожу, что производительность Unreal разочаровывает даже в тестовых мирах с малым количеством объектов.
Вам нужно задаться вопросом: «Что же мне требуется на самом деле?» Избавляйтесь от всего лишнего. Каждая ненужная система — это впустую потраченные ресурсы и время.
Что нужно для вашего проекта?
Технологиями должен управлять ваш проект, если только это не технологическое демо. Если вы создаёте игру, то нужно работать только с теми технологиями, которые оказывают влияние на игру — только с самым необходимым для передачи вашего видения. Если движок предоставляет вам самый быстрый путь для выпуска вашей игры, то это хороший выбор. Но так будет не всегда!
Существуют успешные игры, которым бы послужил плохую службу любой из доступных движков:
- Для Dreams был написан собственный рендерер, упрощающий и ускоряющий интуитивное создание 3D-ассетов.
- В No Man's Sky активно используются совершенно новые способы процедурной генерации. При реализации таких вещей в движке приходилось бы постоянно с ним бороться.
- В Minecraft можно было бы использовать только немногие из возможностей стандартных движков.
Будущее вашей (и нашей) индустрии
При использовании любой технологии стоит задуматься о замыкании. У Джоэла Сполски есть серия статей о бизнес-стратегии разработки ПО, в которой он размышляет о замыкании на продукте. Если вкратце, то его мысль заключается в том, что компании заинтересованы удерживать вас, чтобы вы использовали их продукт, потому что если вы не используете продукт, то они не зарабатывают денег. Мастерами в захвате целых отраслей стали Apple, Microsoft, Adobe и Autodesk, они создают ощущение, что кроме их ПО нет никаких других альтернатив.
Замыкание влияет даже на хобби/соло-разработчиков. У меня есть друг, который постоянно борется с Unity (рушащие совместимость обновления, система прототипирования, навмеш, плохая поддержка 2D...). Он хочет уйти от Unity, но сильно замкнут на этот движок, потому что большая часть его кода (и данных) полагается на Unity API.
Почему движки покупают?
Unreal и Unity управляются требованиями рынка. Их клиенты AAA-уровня при помощи многомиллионых контрактов определяют курс дальнейшего развития движков. Если вы работаете над игрой, структура которой не совпадает с целями этих AAA-игроков, то разработчики движков не будут так же преданно служить вам. Например, двухмерным, процедурным, экспериментальным, воксельным играм и играм с большими объёмами данных почти всегда приходится искать что-то своё.
Чем ярче кажутся функции, тем больше руководство компаний (которое чаще всего не является технарями) стремится использовать движки. Такие возможности, как Blueprints движка Unreal, очень нравятся художникам и дизайнерам, но создают множество проблем программистам. (Это свойственно любым скриптовым языкам; если позволить не изучавшим программирование людям программировать, то результат будет плохим, аналогично тому, как плоха графика, рисуемая программистами).
Действительно ли новые функции упрощают завершение создания вашей игры? На самом ли деле они повышают ценность конечного продукта?
Боритесь с централизацией
Каждый раз, когда одна из студий переходит с собственного движка на Unreal или Unity, компании Epic и Unity набирают в игровой индустрии ещё бОльшую мощь. Поначалу такая централизация может казаться выгодной (у них ведь над движком работают 500 инженеров, отлично!), но через пару десятилетий это станет реальной проблемой. На ум приходит Google: эта компания захватила обширную часть функций, которые люди используют в Интернете, и это стоило им потери большой доли приватности.
Даже на уровне хобби отказ от исследований в пользу Unreal или Unity вредит будущим поколениям движков. Это может повредить даже самому Unreal: если все будут использовать Unreal, то Epic не сможет больше нанять никого для создания нового поколения движка, потому что никто не будет знать, как пишутся игровые движки!
Будущее может быть за открытыми исходниками
Если мы, как индустрия, хотим расти, создавая всё более качественные продукты, то нам нужно больше, а не меньше делиться технологиями.
Я думаю, что индустрия движется в этом направлении, хоть и чрезвычайно медленно. В особенности это свойственно игровым студиям AAA-уровня, которые всё ещё скрывают код своих движков, чтобы получить (воображаемое?) конкурентное преимущество.
- Microsoft сделала в этом направлении огромные шаги. Если меняются даже они, то я уверен, что смогут и другие.
- В лицензионном соглашении Unreal содержится пункт, позволяющий опираться на его код при работе над собственным (проприетарным или свободным) движком. Я думаю, что это большой прогресс.
- Благодаря своей полной открытости и бесплатности большую популярность набирает Godot, и я надеюсь, что если ему дать достаточно времени и поддержки, то он станет конкурентом Unity (а со временем и Unreal).
- id Software (в эпоху Джона Кармака) выпускала полный исходный код с Doom и до Doom 3. У Кармака было множество причин продвигать такое решение. Самая убедительная из них для компаний заключается в том, что это не вредит продажам. Модель shareware, по которой распространялся Doom — разработчик отдаёт движок и продаёт данные — может быть эффективной стратегией и сегодня. Если ваш бизнес беспокоится о том, что конкуренты «украдут» вашу технологию, можете опубликовать свой код уже после того, как за ним выпущена более новая игра (так поступала id). После ухода Кармака id, похоже, потеряла интерес к публикации кода.
Качество ПО
Джонатан Блоу и Кейси Муратори — ярые критики современных практик написания ПО. Их точка зрения заключается в том, что мы создаём надстройки над слоями абстракций так долго, что получаются огромные хрупкие слои ненужного хлама, и это не позволяет нам писать более качественные продукты.
Возможно их философия ближе к идеализму, чем к прагматизму (что обычно приводит к откладыванию сроков выпуска игр), но если она близка вам, то не стоит её игнорировать.
Важны ли вам скорость, качество и элегантность ваших технологий? Многих людей вполне устраивает отрицательный ответ, но некоторые хотят создавать программы более «чистым» способом.
Каковы альтернативы?
Вместо использования движка вы просто пишете игру.
Новички часто думают, что для создания игры им нужен движок. С большой долей вероятности им стоит отбросить такую точку зрения. Начинающие будут впустую тратить время на реализацию бесполезных функций движка, вместо того, чтобы дать игре решить самой, что ей абсолютно необходимо. Только игра должна управлять тем, что нужно от движка (разумеется, в качестве контрпримера можно привести Unity, как образец подхода «движок в первую очередь»; в поддержку такой концепции у Unreal Engine 4 есть Paragon, Fortnite и Unreal Tournament, не говоря уже о десятках лет опыта выпуска бесконечного количества игр в предыдущих версиях движков).
Использование библиотек
Начинать «с нуля» имеет смысл только если вы имеете навык и планируете создать инновацию в конкретном компоненте (или имеете ограничения). Во всех остальных случаях существует множество библиотек для интеграции. Это особенно хорошо, когда вы знаете, что, например, стандартная система физики полностью подходит для требований вашего проекта (особо важно это потому, что для реализации собственной физики нужен большой объём знаний в этой области).
Вот несколько библиотек, которые могут заполнить пробел между работой «с нуля» и использованием полностью готового движка:
- Графика: SDL, SFML, Ogre
- Физика: Bullet, PhysX (которая недавно стала open source — огромная победа!)
- Звук: SDL, SFML
Это лишь очень малая доля существующих библиотек.
Большой плюс в использовании библиотек заключается в том, что он даёт вам наибольшую среди всех вариантов гибкость. Если вы пишете весь код в одном движке, то для его портирования придётся приложить огромные усилия. Если вы пишете игру как коллекцию библиотек, то обладаете большой мобильностью и можете заменять целые подсистемы. Если библиотека не отвечает вашим требованиям, то можно попробовать другую или даже написать собственную замену.
Кроме того, и Unreal, и Unity поддерживают импорт динамически подключаемых библиотек. Это значит, что можно начать работать с библиотеками, а затем перейти на Unreal без необходимости переписывать весь базовый код геймплея, потому что он находится в библиотеке. Чтобы код оказался достаточно гибким для таких огромных изменений, требуется серьёзная продуманность, но я думаю, что для среднего или долговременного проекта оно того стоит.
В заключение
Я представил несколько точек зрения, под которыми можно рассматривать технологии при их выборе. Потратьте пару недель на подробное исследование, и это может сэкономить вам в дальнейшем несколько месяцев работы по портированию или даже годы неудобств.
В конце концов, ваша основная задача — закончить проект. Вам следует приложить максимальные усилия к поиску кратчайшего пути к решению этой задачи. Он может оказаться для вас довольно неожиданным!
Комментарии (50)
olegchir
13.09.2019 13:31+1Молодые разработчики используют движки потому, что они учат их, как делать вещи. Расширяют горизонты возможного. Все это можно написать руками, если ты уже знаешь, что именно нужно писать. Это как в магазине, когда ты приходишь совершенно без идей, что же тебе хочется есть, но нагуливаешь аппетит, ходя вдоль полок и раздумывая — а съел бы я вот это и это, а какие они на вкус,… и в конце концов заканчиваешь с целой корзиной еды! А то и двумя и тремя! Если же тебе сразу сказали бы — составь список покупок, фиг бы ты чего купил. То же самое и с движками, и вообще с любым софтом. Софт — это твой учитель в первую очередь, и во вторую уже всё остальное вроде качественно сделанной функциональности или готовых быстро применимых решений.
rboots
13.09.2019 21:01В результате получаются игры похожие одна на другую. Мне кажется раньше игры были интереснее потому, что сначала прорабатывалась идея, а потом думали как её реализовать, а сейчас и правда как в магазине, набирают полуфабрикаты и пытаются что-то состряпать по быстому.
16tomatotonns
14.09.2019 10:13Тут весьма двоякое отношение. В первую очередь, для обучения, стоит именно что всё перепробовать. Начать с какого-нибудь фреймворка (без редакторов сцен и даже понятия игровой сущности) типа LibGDX/love2d/PyGame. Навелосипедить на нём себе все основные инструменты, поглядывая на движки, чтобы понять как это работает в движках. А после этого, начать ковырять сами сторонние движки. В таком случае, объём знаний получается более-менее полным, появляется знание проблем тех или иных движков, и когда можно — получается сэкономить время воспользовавшись движком, а когда не нужно — можно и руками всё накатать на фреймворке/наборе библиотек.
Egor3f
14.09.2019 19:16У многих быстро пропадает интерес к новому занятию, если они не видят какой-либо результат своими глазами; + важна реакция окружающих (внешнее подкрепление, «молодец сыночек, ты сам помыл пол» / «круто чувак, ты сам сделал игру»). Чем ниже уровень движка / библиотеки, тем более крутая кривая обучения, тем больше нужно времени и сил, чтобы получить осязаемый результат — велик шанс забить на это дело.
Кстати, поэтому для людей, желающих познакомиться с дивным миром программирования, я советую сначала изучать что-то простое и неактуальное, например VB6, затем разобраться в работе программ на низком уровне (Си / Асм), и только третим языком тот, с которым собираетесь работать (js / java / c# / go / ...). Тогда и понимания будет больше, и шанс забить минимальный, и обучение пойдёт проще.
Естественно, вышесказанное относится только к любительским проектам в свободное от работы время. Если у человека / команды уже есть опыт и стоит цель сделать качественный продукт (игру в данном случае) — надо выбирать средство под цель, чтобы не получить очередные «3 в ряд» весом в 200 Мб включая рантайм моно.16tomatotonns
16.09.2019 01:42Ну, на фреймворке можно как раз без особого обучения вызвать несколько функций:
— загрузить картинку;
— нарисовать её на таких-то координатах;
— в игровом цикле проверить, если на него кликнули мышкой (aabb) или нажали
какую-то кнопку, то вызвать какую-то логику.
И на этом же простейшем aabb или чём-то аналогичном — сделать маленькую top-down-стрелялку вжжж-пиу-пиу, обновляем координаты пуль из массива пуль и коллидируем с противниками из массива противников (например). Очень просто, вся внутренняя кухня прямо перед глазами и есть позитивные подкрепления. Я так на баловстве с Love2d вылез в программисты :)
AstarothAst
13.09.2019 14:56Подумайте дважды, прежде чем использовать игровые движки
И трижды, прежде чем не использовать.
Alexey2005
13.09.2019 16:36+1А ещё авторы движков сделали за вас самую грязную и нудную часть работы: обеспечили кроссплатформенность. Попробуйте собрать кроссплатформенную игру хотя бы уровня тетриса даже из кроссплатформенных библиотек — и через пару недель вам уже и не захочется программировать, настолько упаритесь. Движки же решают эту проблему, пусть даже ценой чудовищного перерасхода ресурсов и необходимостью подстраиваться под самую тухлую из поддерживаемых платформ.
AllexIn
14.09.2019 12:47Кроссплатформа — чуть ли не самое простое с чем придется столкнуться при реализации своего движка.
Релизил проект на своем движке под Win/Mac/Linux/Android/iOS — SDL закрыл подавляющую часть проблем.
Дольше всего провозился с platforms specific features, типа обласных сохранений и ачивок, но даже они не были сложными в реализации, т.к. каждый game store делает максимально простое API, понимая что чем проще API будет, тем активнее оно будет использоваться.LifeKILLED
14.09.2019 18:16Справедливости ради стоит заметить, что чаще всего портирование одной кнопкой, как заявлено аторами движков, не работает в том плане, что все равно нужно частично что-то переделывать, оптимизировать, да и platform specific features никуда не деваются. Что-то может сломаться, не сработать на одной из платформ, самописные шейдеры могут не отрисоваться, все это надо отлаживать, а на это нужно время.
AllexIn
14.09.2019 19:06Господа минусующие, не уходите молча. Давайте обсудим. Расскажите, с какими сложностями вы столкнулись. Вдруг их реально победить.
Suvitruf
14.09.2019 19:211) А могли бы вместо этого взять готовый движок и делать, собственно, саму игру, а не вот это вот всё низкоуровневое.
2) Что на счёт консолей?AllexIn
14.09.2019 19:22-11) Не мог. Их не было.
А сейчас могу, поэтому редко пишу что-то свое и в основном работаю с UE4. Ну и в целом речь была не про то, что надо делать своё. Речь была про то, что кроссплатформ далеко не самая сложная часть в разработке.
2) Тогда на консоли залезть просто так было нельзя. Поэтому ничего.
Если же говорить более конкретно — кроссплатформ с консолями «тогда» была почти невозможна: каждая консоль имела свою архитектуру и просто так портировать игру было нельзя. Сейчас же кросплатформа с консолями не представляет особой проблемы.
indiega
13.09.2019 18:02-1Мягко говоря, странная статья )
Этот пост на reddit не является идеальным примером разумных контраргументов против постоянного использования движков, но я считаю, что непреодолимое желание их применения немного отдаёт фанатизмом.
А я считаю, что непреодолимое желание людей использовать транспортные средства, вместо ходьбы пешком, немного отдаёт фанатизмом. Да в общем-то, и прямохождение, вместо ползания уже фанатизм. Только низкоуровщина, только хардкор!!! )))picul
13.09.2019 18:10+1Ну так никто же не предлагает совсем отказаться от транспорта. Предлагают не использовать его для того, что бы переместиться из комнаты на кухню. Ну и напоминают, что на обычном транспорте в космос не улетишь.
indiega
13.09.2019 18:18-1Ну такое себе. Решение больших бизнес задач и зарабатывание докулиарда денег, с помощью анрилов и юнитей, сравнить с перемещением по квартире, можно с натяжкой. Дело конечно хозяйское, если конечная цель запилить очередной велик, ради бога. Но с помощью движков, нормальные люди, обычно зарабатывают. Что-бы забить гвоздь не надо изобретать молоток. Надо лишь выбрать подходящий.
picul
13.09.2019 20:00+1Ладно, расшифрую. Никто не против использования готовых движков, если нужно реализовать йет эназер ординарный шутер от первого лица. Но если хочется сделать что-то новое — там, графика нормальная, сеть, или еще что — то анриал/юнити в большинстве случаев будут лишь ограничивать.
А перемещение по квартире было про исользование тяжелых движков для совершенно технически тривиальных проектов, таких как 2D-платформеры и т. д.indiega
13.09.2019 20:44Писать красоту с нуля, при текущем уровне технологий, дабы достичь недостижимого, сегодня, в мире, могут позволить себе единицы — небожители ). Так как, конечным критерием выбора стека, была, есть и останется цена удовольствия. Мы же говорим, скорее о нас, простых смертных. И вот тут уже, никто в здравом уме, не будет велосипедить. Ибо даже нищебродский доход в 10К грин/мес с проекта, в короткие сроки, легко и непринужденно отправляет в топку, саму мысль о самописном движке. Ибо позволяет, как минимум, поддерживать штаны небольшой команды, в рабочем состоянии. В случае же с самодельной свистоперделкой, придется ждать, страдать и кормить «зажратых» кодеров, совершенно неопределенное время. А гарантировать, всего лишь возможность, того, что все будет отдаленно напоминать, поставленную цель, могут, только «зажратые» кодеры. Их, кстати еще найти надо. Для того, что-бы убедится в этой простой истине (что велосипед дорогое удовольствие), достаточно один раз оплатить разработку проекта из своего кармана. В общем, тут, как говорится, вам шашечки или ехать? Как-то так, ИМХО.
picul
14.09.2019 00:03А кто предлагает с нуля писать? Даже в статье говорится — возьмите готовые библиотеки и соберите их вместе, а где нужно что-то исключительное — сделайте сами. И как человек, имеющий к этому дело некоторое отношение, не понимаю, что тут такого небожительного. Да, на такую работу нужен приличный специалист — но так то любую нетривиальную работу хорошо может сделать только приличный специалист.
Ну и конечно если по финансам маленькая инди-команда — это потолок, то вряд ли стоит делать что-то грандиозное, не спорю. Но тогда Вы и не получите ничего грандиозного (в техническом плане), выйдет просто очередная игра на анриале/юнити.indiega
14.09.2019 08:58Даже в статье говорится — возьмите готовые библиотеки и соберите их вместе, а где нужно что-то исключительное — сделайте сами
Да, Вы батенька, оптимист! ))) Говорю Вам, как человек имеющий, самое непосредственное отношение к вопросу.
Но тогда Вы и не получите ничего грандиозного...
Грандиозное конечно хотят все, по большому счету, но вот позволить себе, могут немногие.… выйдет просто очередная игра на анриале/юнити.
Так это и есть конечная цель, среднестатестической конторы. Выпустить проект и заработать. И что-бы было быстро, дешево и сердито. ) Будет ли проект успешен, сегодня, в первую очередь, решает не разнеможные графоний и фичи, рынок уже перенасыщен всем этим. Сегодня решает маркетинг. Это немного грустно, но это реалии. Так что «велосипеды», это удел либо любителей-энтузиастов, либо представителей с Олимпа. Тем, что посерединке, между ними, некогда фигней страдать. ) У них задачи и цели другие.
LifeKILLED
14.09.2019 18:45выйдет просто очередная игра на анриале/юнити
ну это уж слишком, зачем так-то жестко разваливать? это же удар ниже пояса. даже не знаю теперь как отмыться от такого позора. "обычная игра на анриле/юнити" — боже как я до этого докатился! пойду качать nvidia sdk и гуглить аудио библиотеки. вот прям чувствую, сразу все изменится
( ;-p )
AllexIn
14.09.2019 19:08Большинство крутых инди последнего времени без проблем реализуются на UE и Unity. Собственно инди, которые бы вылезали за счет супер особенной технической реализации(типа MInecraft) единицы. Остальное крутое по другим причинам.
Ну а не инди вообще обсуждать смысле не имет, эта статья не про большой геймдев.
Peacemaker
13.09.2019 18:22Лет пятнадцать в одной статье по игрострою встретил мысль: «самая плохая идея для начинающих — начинать разработку игры с написания собственного движка». Думаю, она по-прежнему актуальна.
AllexIn
14.09.2019 12:48Подавляющее число людей, которые делают игру на своем движке не доходят до делания собственно игры.
LifeKILLED
14.09.2019 18:28Есть еще разные уровни велосипедизма. Можно собирать движок из готовых библиотек, а можно начать с кода инициализации из туториалов по opengl. Или вообще запилить софтверный рендер. Я все три проходил, одну игру даже смог доделать (остальные забаговались), но сейчас слишком стар для этого
Bookvarenko
16.09.2019 08:26У меня так друг
...ушёл из игростроя и открыл два овощных ларька. Теперь солидный бизнесмен.LifeKILLED
14.09.2019 18:52На gamedev.ru гуляет легенда о том что те, кто пишут с нуля 3д движки, сходят с ума. И там еще был список из форумчан которые реально легли в дурку и скриншоты их наработок достаточнр
о неплохиеAllexIn
14.09.2019 19:09Эээ. Живу на gd.ru года так с 2004 и не помню такой тему. Можно ссылку?
P.S> Я сам писал 3д движки с нуля, может я просто спятил и от меня тему скрыли, чтобы я не травмировался?
whitemonkey
13.09.2019 19:59+1Делал обёртку над WinAPI — Стал посматривать на Unreal Engine.
Писал велосипед по формату FBX — Стал смотреть на FBX SDK.
Начал изучать Vulkan API — Чаще стал смотреть на Unity.
Чаще в общем стал смотреть на готовые решения.
Реже стал думать о «Велосипедном движке».
…
mjr27
14.09.2019 08:07Свой движок писать прикольно и весело. А потом в игре появляется UI, и веселье заканчивается.
AllexIn
14.09.2019 12:51Почему? UI это очень весело.
На своем движке можно легко делать прикольные штуки.
Например, вот из статьи Игра за 14 дней [Для тех, кто годами собирает команду, но так и не сделал прототип]
AstarothAst
14.09.2019 17:49+1Если цель «прикольно и весело», то да. А если цель написать игру, то лучше не надо.
blackbird_ru
14.09.2019 13:39Покажите мне пример, где просто взяли и написали игру, и не использовали сторонние движки. Да, команда из 20+ человек и не коммерческие проекты мимо.
Треугольник вывести просто, а как чуть углубляешься то всё.LifeKILLED
14.09.2019 18:31Ну можно вывести не треугольник, а два треугольника, получится квадратный спрайт. Практически готовый графический движок для 2д игр. Иронизирую конечно, но для легких мобилок актуально.
AllexIn
14.09.2019 19:09-1Тысячи их.
AllexIn
14.09.2019 20:31Из очевидного Minecraft, из неочевидного — почти все инди до 2014 года.
blackbird_ru
15.09.2019 04:47Голословное утверждение. Особенно учитывая что до 2014 многие популярные инди использовали XNA или тот же Unity. И наверняка многие другие забытые сегодня движки.
Тот же Game Maker, Multimedia Fusion 2 (Five Nights at Freddy, I wanna be a Guy), OGRE, Torque и наверняка что-то ещё.
prambeat
15.09.2019 11:32super meat boy — вот тут можно почитать, почему люди решили писать свой движок — habr.com/ru/post/332984
blackbird_ru
15.09.2019 11:58Там только одна причина указана, почему свой движок. Какой-то мифический полный контроль кода и ошибок. При этом там же пишут что когда её зарелизили на ПК, багов был очень много.
LifeKILLED
14.09.2019 17:50В целом в статье всё до банального очевидно. Если планируется совсем лютый эксперимент или мобилка — лучше не пользоваться тяжёлым движком.
Но абзац про динамические библиотеки в Unity и Unreal поставил в тупик. Мало того что библиотеки там вообще не для игрового кода ну никак, а для расчетов каких-то жестких или для расширений конкретного движка. Так еще и рассматривается вероятность в серьезном проекте поменять движок в середине разработки. Это как бы ошибка планирования и так делать не надо. Либо это долгострой, в котором на определенном этапе лучше что-то написать заново.
LifeKILLED
14.09.2019 18:07В засчиту Unity скажу то, что в нём предусмотрена переработка графического конвейера. В традиционном рендере есть Command Buffer, которым реально полностью убрать систему освещения и написать свою. Плюс у меня есть статья, где я костыльно улучшал освещение, модифицируя встроенные шейдеры (на этом принципе, а возможно даже на и моих наработках, реализован ассет Next Gen Soft Shadows). В новых версиях разработчики пошли дальше и сделали программируемый рендер конвейер, который можно полностью переписать, и в нем из коробки реализованы красивые штуки уровня Unreal.
Это все про рендер, то есть про самую требовательную для ресурсов и для многих критичную часть. Резюмирую: все можно переделать под себя или даже заменить полностью.
Что касается остального, то если допустим вам не нужна 2д физика, выключаете компонент, и ресурсы попросту не тратятся. Конечно, библиотеки все равно будут занимать в памяти драгоценные мегабайты, но это та цена, которая осознанно платится за удобство кроссплатформенности.
Что касается скриптов, системы объектов и всего прочего, то в самописном движке вы придете к тому же самому. Не знаю как тесно вплетено все в код Unreal и как трудно от этого отойти, но в Юнити можно реализовать кучу разных подходов, систем сообщений, достаточно легко пишутся расширения редактора чтоб сделать удобные тулзы. И даже ярый велосипедист окажется рад перекатиться в эту среду разработки, если приложит минимальное усилие на начальном этапе.
Bookvarenko
16.09.2019 08:19+1Ещё одна интересная тема для холиваров: «Почему разработчики выбирают для своего проекта заведомо убогий движок вместо классного?»
paranoya_prod
Unreal Blueprints очень удобен (удобна, удобно?) для прототипирования, чтобы глянуть на сколько хорошо выглядит бумажная идея.
Unreal, Unity, Cryengine и Ogre 3D — это графические движки. Не понимаю, почему Огр в статье как-то отдельно рассматривается?
Разница между движками уровня Unreal и Ogre в том, что первые изначально напичканы всякими IDE редакторами моделей, сцен, материалов.
Нельзя просто так перейти с одной графической библиотеки на другую. Всегда придётся переписывать ту часть, которая отвечает за вызов функций из библиотек. И это минимум, а если другой рендер ещё требует другой формат описания объектов, то руки в ноги и вперёд конвертировать. То есть, разницы нет между использованием Unreal или обычной библиотеки рендера.
VBKesha
Unreal, Unity, Cryengine это как минимум не только графические движки, там ещё и звук и физика и управление насчет Ogre 3D без понятия.
paranoya_prod
Unreal, CryEngine, Unity выросли из обычных графических движков. Ogre3D как был графическим движком так им остаётся, но для него создаются отдельно всякие редакторы сцен и всё то, что в том же Unreal есть в комплекте.
VBKesha
Unreal вроде бы никогда не был чисто графическим движком, он сразу был игровым движком. насчет остальных утверждать ничего не стану.