Pull to refresh

Comments 58

Unreal Blueprints очень удобен (удобна, удобно?) для прототипирования, чтобы глянуть на сколько хорошо выглядит бумажная идея.
Unreal, Unity, Cryengine и Ogre 3D — это графические движки. Не понимаю, почему Огр в статье как-то отдельно рассматривается?
Разница между движками уровня Unreal и Ogre в том, что первые изначально напичканы всякими IDE редакторами моделей, сцен, материалов.
Нельзя просто так перейти с одной графической библиотеки на другую. Всегда придётся переписывать ту часть, которая отвечает за вызов функций из библиотек. И это минимум, а если другой рендер ещё требует другой формат описания объектов, то руки в ноги и вперёд конвертировать. То есть, разницы нет между использованием Unreal или обычной библиотеки рендера.
Unreal, Unity, Cryengine и Ogre 3D — это графические движки.

Unreal, Unity, Cryengine это как минимум не только графические движки, там ещё и звук и физика и управление насчет Ogre 3D без понятия.
Unreal, CryEngine, Unity выросли из обычных графических движков. Ogre3D как был графическим движком так им остаётся, но для него создаются отдельно всякие редакторы сцен и всё то, что в том же Unreal есть в комплекте.
Unreal вроде бы никогда не был чисто графическим движком, он сразу был игровым движком. насчет остальных утверждать ничего не стану.

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

Молодые разработчики используют движки потому, что они учат их, как делать вещи. Расширяют горизонты возможного. Все это можно написать руками, если ты уже знаешь, что именно нужно писать. Это как в магазине, когда ты приходишь совершенно без идей, что же тебе хочется есть, но нагуливаешь аппетит, ходя вдоль полок и раздумывая — а съел бы я вот это и это, а какие они на вкус,… и в конце концов заканчиваешь с целой корзиной еды! А то и двумя и тремя! Если же тебе сразу сказали бы — составь список покупок, фиг бы ты чего купил. То же самое и с движками, и вообще с любым софтом. Софт — это твой учитель в первую очередь, и во вторую уже всё остальное вроде качественно сделанной функциональности или готовых быстро применимых решений.

В результате получаются игры похожие одна на другую. Мне кажется раньше игры были интереснее потому, что сначала прорабатывалась идея, а потом думали как её реализовать, а сейчас и правда как в магазине, набирают полуфабрикаты и пытаются что-то состряпать по быстому.
Тут весьма двоякое отношение. В первую очередь, для обучения, стоит именно что всё перепробовать. Начать с какого-нибудь фреймворка (без редакторов сцен и даже понятия игровой сущности) типа LibGDX/Love2d/PyGame, и мутить на нём крошечные прототипы игрушек типа змеек/3-в-ряд/тетрисов или уже чего посложнее (но ненамного). Навелосипедить на нём себе основных инструментов, поглядывая на движки, чтобы понять как это работает в движках. А после этого, начать ковырять сами сторонние движки. В таком случае, объём знаний получается более-менее полным, появляется знание проблем тех или иных движков, и когда можно — получается сэкономить время-деньги воспользовавшись движком, а когда не нужно — можно и руками всё накатать на фреймворке/наборе библиотек.

У того же Джоэла Сполски есть статья про дыры в абстракциях, и подобный подход позволяет их заранее изучить.
UFO just landed and posted this here
Ну, на фреймворке можно как раз без особого обучения вызвать несколько функций:
— загрузить картинку;
— нарисовать её на таких-то координатах;
— в игровом цикле проверить, если на него кликнули мышкой (aabb) или нажали
какую-то кнопку, то вызвать какую-то логику.
И на этом же простейшем aabb или чём-то аналогичном — сделать маленькую top-down-стрелялку вжжж-пиу-пиу, обновляем координаты пуль из массива пуль и коллидируем с противниками из массива противников (например). Очень просто, вся внутренняя кухня прямо перед глазами и есть позитивные подкрепления. Я так на баловстве с Love2d вылез в программисты :)
Подумайте дважды, прежде чем использовать игровые движки

И трижды, прежде чем не использовать.
А ещё авторы движков сделали за вас самую грязную и нудную часть работы: обеспечили кроссплатформенность. Попробуйте собрать кроссплатформенную игру хотя бы уровня тетриса даже из кроссплатформенных библиотек — и через пару недель вам уже и не захочется программировать, настолько упаритесь. Движки же решают эту проблему, пусть даже ценой чудовищного перерасхода ресурсов и необходимостью подстраиваться под самую тухлую из поддерживаемых платформ.
Кроссплатформа — чуть ли не самое простое с чем придется столкнуться при реализации своего движка.
Релизил проект на своем движке под Win/Mac/Linux/Android/iOS — SDL закрыл подавляющую часть проблем.
Дольше всего провозился с platforms specific features, типа обласных сохранений и ачивок, но даже они не были сложными в реализации, т.к. каждый game store делает максимально простое API, понимая что чем проще API будет, тем активнее оно будет использоваться.

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

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


На SDL делал.
Проблем не было.
Не понял о чем вы.

Мягко говоря, странная статья )
Этот пост на reddit не является идеальным примером разумных контраргументов против постоянного использования движков, но я считаю, что непреодолимое желание их применения немного отдаёт фанатизмом.

А я считаю, что непреодолимое желание людей использовать транспортные средства, вместо ходьбы пешком, немного отдаёт фанатизмом. Да в общем-то, и прямохождение, вместо ползания уже фанатизм. Только низкоуровщина, только хардкор!!! )))
Ну так никто же не предлагает совсем отказаться от транспорта. Предлагают не использовать его для того, что бы переместиться из комнаты на кухню. Ну и напоминают, что на обычном транспорте в космос не улетишь.
Ну такое себе. Решение больших бизнес задач и зарабатывание докулиарда денег, с помощью анрилов и юнитей, сравнить с перемещением по квартире, можно с натяжкой. Дело конечно хозяйское, если конечная цель запилить очередной велик, ради бога. Но с помощью движков, нормальные люди, обычно зарабатывают. Что-бы забить гвоздь не надо изобретать молоток. Надо лишь выбрать подходящий.
Ладно, расшифрую. Никто не против использования готовых движков, если нужно реализовать йет эназер ординарный шутер от первого лица. Но если хочется сделать что-то новое — там, графика нормальная, сеть, или еще что — то анриал/юнити в большинстве случаев будут лишь ограничивать.
А перемещение по квартире было про исользование тяжелых движков для совершенно технически тривиальных проектов, таких как 2D-платформеры и т. д.
Писать красоту с нуля, при текущем уровне технологий, дабы достичь недостижимого, сегодня, в мире, могут позволить себе единицы — небожители ). Так как, конечным критерием выбора стека, была, есть и останется цена удовольствия. Мы же говорим, скорее о нас, простых смертных. И вот тут уже, никто в здравом уме, не будет велосипедить. Ибо даже нищебродский доход в 10К грин/мес с проекта, в короткие сроки, легко и непринужденно отправляет в топку, саму мысль о самописном движке. Ибо позволяет, как минимум, поддерживать штаны небольшой команды, в рабочем состоянии. В случае же с самодельной свистоперделкой, придется ждать, страдать и кормить «зажратых» кодеров, совершенно неопределенное время. А гарантировать, всего лишь возможность, того, что все будет отдаленно напоминать, поставленную цель, могут, только «зажратые» кодеры. Их, кстати еще найти надо. Для того, что-бы убедится в этой простой истине (что велосипед дорогое удовольствие), достаточно один раз оплатить разработку проекта из своего кармана. В общем, тут, как говорится, вам шашечки или ехать? Как-то так, ИМХО.
А кто предлагает с нуля писать? Даже в статье говорится — возьмите готовые библиотеки и соберите их вместе, а где нужно что-то исключительное — сделайте сами. И как человек, имеющий к этому дело некоторое отношение, не понимаю, что тут такого небожительного. Да, на такую работу нужен приличный специалист — но так то любую нетривиальную работу хорошо может сделать только приличный специалист.
Ну и конечно если по финансам маленькая инди-команда — это потолок, то вряд ли стоит делать что-то грандиозное, не спорю. Но тогда Вы и не получите ничего грандиозного (в техническом плане), выйдет просто очередная игра на анриале/юнити.
Даже в статье говорится — возьмите готовые библиотеки и соберите их вместе, а где нужно что-то исключительное — сделайте сами
Да, Вы батенька, оптимист! ))) Говорю Вам, как человек имеющий, самое непосредственное отношение к вопросу.
Но тогда Вы и не получите ничего грандиозного...
Грандиозное конечно хотят все, по большому счету, но вот позволить себе, могут немногие.
… выйдет просто очередная игра на анриале/юнити.
Так это и есть конечная цель, среднестатестической конторы. Выпустить проект и заработать. И что-бы было быстро, дешево и сердито. ) Будет ли проект успешен, сегодня, в первую очередь, решает не разнеможные графоний и фичи, рынок уже перенасыщен всем этим. Сегодня решает маркетинг. Это немного грустно, но это реалии. Так что «велосипеды», это удел либо любителей-энтузиастов, либо представителей с Олимпа. Тем, что посерединке, между ними, некогда фигней страдать. ) У них задачи и цели другие.
выйдет просто очередная игра на анриале/юнити

ну это уж слишком, зачем так-то жестко разваливать? это же удар ниже пояса. даже не знаю теперь как отмыться от такого позора. "обычная игра на анриле/юнити" — боже как я до этого докатился! пойду качать nvidia sdk и гуглить аудио библиотеки. вот прям чувствую, сразу все изменится


( ;-p )

Большинство крутых инди последнего времени без проблем реализуются на UE и Unity. Собственно инди, которые бы вылезали за счет супер особенной технической реализации(типа MInecraft) единицы. Остальное крутое по другим причинам.
Ну а не инди вообще обсуждать смысле не имет, эта статья не про большой геймдев.
Лет пятнадцать в одной статье по игрострою встретил мысль: «самая плохая идея для начинающих — начинать разработку игры с написания собственного движка». Думаю, она по-прежнему актуальна.
Подавляющее число людей, которые делают игру на своем движке не доходят до делания собственно игры.

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

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

На gamedev.ru гуляет легенда о том что те, кто пишут с нуля 3д движки, сходят с ума. И там еще был список из форумчан которые реально легли в дурку и скриншоты их наработок достаточнр
о неплохие

Эээ. Живу на gd.ru года так с 2004 и не помню такой тему. Можно ссылку?

P.S> Я сам писал 3д движки с нуля, может я просто спятил и от меня тему скрыли, чтобы я не травмировался?
UFO just landed and posted this here

Свой движок писать прикольно и весело. А потом в игре появляется UI, и веселье заканчивается.

Почему? UI это очень весело.
На своем движке можно легко делать прикольные штуки.
Например, вот из статьи Игра за 14 дней [Для тех, кто годами собирает команду, но так и не сделал прототип]

Меню слайдер. Сделал легко и просто. Не все движки позволяют такое просто сделать.
Честно говоря, не вижу что сложного в меню слайдере? На юнити это реализовывается достаточно легко даже с помощью базового UI пакета.
Покажите мне пример, где просто взяли и написали игру, и не использовали сторонние движки. Да, команда из 20+ человек и не коммерческие проекты мимо.

Треугольник вывести просто, а как чуть углубляешься то всё.

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

Из очевидного Minecraft, из неочевидного — почти все инди до 2014 года.
Голословное утверждение. Особенно учитывая что до 2014 многие популярные инди использовали XNA или тот же Unity. И наверняка многие другие забытые сегодня движки.
Тот же Game Maker, Multimedia Fusion 2 (Five Nights at Freddy, I wanna be a Guy), OGRE, Torque и наверняка что-то ещё.
Учитывая как мне насрали в карму люди явно не понимающие ничего в геймдеве, но имеющие своё очень убежденное мнение — я не стал продолжать разговор, пока статья была актуальна и через неё ходила толпа идиотов.
Но тема интересная, поэтому вот вам ресеч с указанием статистики по движкам:
www.reddit.com/r/gamedev/comments/8s20qp/i_researched_the_market_share_of_game_engines_on
Большая часть сейчас на движках. При этом огромное количество игр на кастомных.
super meat boy — вот тут можно почитать, почему люди решили писать свой движок — habr.com/ru/post/332984
Там только одна причина указана, почему свой движок. Какой-то мифический полный контроль кода и ошибок. При этом там же пишут что когда её зарелизили на ПК, багов был очень много.
Тем не менее, у них все получилось, и игра оказалось вполне интересной
Извините но херь высосанная из пальца.

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


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

В засчиту Unity скажу то, что в нём предусмотрена переработка графического конвейера. В традиционном рендере есть Command Buffer, которым реально полностью убрать систему освещения и написать свою. Плюс у меня есть статья, где я костыльно улучшал освещение, модифицируя встроенные шейдеры (на этом принципе, а возможно даже на и моих наработках, реализован ассет Next Gen Soft Shadows). В новых версиях разработчики пошли дальше и сделали программируемый рендер конвейер, который можно полностью переписать, и в нем из коробки реализованы красивые штуки уровня Unreal.


Это все про рендер, то есть про самую требовательную для ресурсов и для многих критичную часть. Резюмирую: все можно переделать под себя или даже заменить полностью.


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


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

Ещё одна интересная тема для холиваров: «Почему разработчики выбирают для своего проекта заведомо убогий движок вместо классного?»
Define: убогий.
Многое зависит от прямости рук разработчика тоже.

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

Sign up to leave a comment.

Articles