Комментарии 27
Всё детство писал (а поначалу просто D&D'шил через встроенный инструмент FlowGraph) моды для Crysis вплоть до третьей части, и статья попадает в самую точку по движку CryEngine, судьба у которого была почти напрямую связана с Crysis. Как известно, авторитарная политика Цевата Йерли почти угробила игру, во второй части сделав ставку не на масштабные коридорные локации, а на сюжет (который страдал очень плохой "обратной совместимостью" между частями, в основном из-за найма андерграундного писаки, критикующего всё подряд и "нитакогокаквсе"™, хотя это был его первый дебют в игровой индустрии) - что в итоге оказалось ошибкой, которую как-то пытались исправить в третьей части. Игнорирование многочисленных коммьюнити, которые просили не "глушить" инструменты модификации игры, тоже было ошибкой... Об этой ситуации ниже.
В первой части игры и CryEngine 2 соответственно, нужно было NPC посадить в транспорт, и лишь затем можно этот транспорт заставить ехать. Да, оптимизации в этом плане было почти ноль, но дружественность к моддеру, логичность использования сущностей в движке, сумасшедшая поддержка Drag-n-Drop и восхитительный FlowGraph (хотя не он первый, и аналогичные инструменты чуть позже во всех популярных движках) сделали свое дело - во многих странах, начиная с 07-х гг., у движка выросли большие сообщества, изучавшие его и делавшие поделки разной степени безбашенности. А уж про ремейки Сталкёра на CryEngine 2 можно говорить часами — это были десятки, если не сотни попыток. Да, в основном там обещали "грабить корованы"©, но как же было весело! Так прошло мое детство, поделка за поделкой, от встроенного FlowGraph до DLL'ок на C#/C++ и интерфейсах Flash. Там даже лицевую анимацию можно было сгенерировать по звуковому файлу!
Затем у Цевата Йерли начинается "звездная болезнь", а от притока бабла ему затмило разум... Ну, видимо, человек такой вот, "с гнильцой", так сказать. Лично мне он неприятен, как был неприятен и совету директоров, который пытался его сместить (и у них получилось). Ну, а на 2 части началось закручивание гаек. Руководитель студии весьма нелогично посчитал, что модификации для Крайзиса 2 части могут подождать, и поэтому выпустил SDK для этой части на полтора года позже. До этого файлы игры были шифрованные (пусть дешифратор и выпустили почти сразу), и не было нормальных инструментов для работы по ним. Фич в этом SDK было меньше, новых сущностей и подавно мало, часть функционала решили скрыть за пейволлом. Что за пейволл? Об этом ниже.
И тут, во времена второй части и третьей версии движка (и немного до нее), CryTek решили не вполне правильным методом "причесать" сообщество моддеров, и они опубликовали свой сайт - CryDev.net, который и поныне напоминает перекати-поле. Для сравнения - в России было первое в мире по популярности и количеству юзеров сообщество - CryMod.net и еще парочка площадок помельче. Alex626, лидер сайта, пытался договориться либо о слиянии площадок, либо о федеративной сети моддеров и взаимной поддержке. У CryTek было свое видение сообщества разработчиков, которым давалось минимум документации и минимум фич в обрезанной третьей части в Free версии движка. Без ассетов сообщество мало что могло сварганить, и российская площадка первое время была лучше по популярности. Они просто кинули мододелов Крайзиса, которым не дали возможность автоматом привязать движок к игре и модифицировать его как вздумается? Впрочем, такую возможность дали, но поздною
Затем, после провала третьей части, закономерного позднего релиза SDK (когда бабла состричь уже не удавалось) и странностей в виде судебных тяжб с разработчиками Star Citizen количество разработчиков на CryEngine уже версии 5 (CE 5) стало в разы меньше сообществ других популярных движков. А кому охота копаться в технологии с минимумом документации, очень маленьким количеством специалистов и еще и возможностью получить неадекватный иск от разработчика движка? Вот в этом и есть причины низкой популярности CE. Вдобавок, модифицировать файлы оригинальной третьей части игры стало сложнее - непонятно, почему они так сделали? Ведь начинающему моддеру надо дать легкий для освоения инструмент, а затем тот сможет ступенчато превратиться в полноценного разработчика! Вот тебе и новые кадры, и бОльший рыночек, и большое сообщество вокруг твоей технологии! К сожалению, HQ Крайтека было без разницы.
Итог? Что имеем... Судьба игры и движка была сильно связана. Игнорирование геймплейных достоинств первой части игры, упор на почти никак не связанный с историей сюжет, игнорирование потребностей моддеров, создание оторванного от игры сообщества — это уже реальная крышка в гроб франшизы... Но движок-то они спасут, одумаются? Многие ведь одумались? Или они повторят судьбу Нокии, которая почти 1-в-1 с судьбой CryEgnine? Надеюсь, что всё будет отлично, и всё наладится. И я надеюсь, что вернусь когда-нибудь к любимому FlowGraph, и снова открою страницу любимого форума CryMod.net с тысячей непрочитанных сообщений.
Насколько я помню, Star Citizen использовала особую версию движка, полностью 64-битную и в которой все координаты (включая графические) в doble, а не float, как в обычных движках. так что говорить о том, что они используют "стоковый" дижок не совсем корректно.
Я не игровой разработчик, и опыт работы с движками у меня минимальный (тыкал блюпринты в UE), но кто имеет профессиональный опыт работы с UE и с Unity, объясните пожалуйста понятным языком, почему "UE для ААА, а Unity - для инди"? Дело в языке программирования, который сложен в освоении (С++), умении работать с рендером, чем-то ещё? Не так давно общался с разработчиком, имеющим большой опыт работы с Unity, он сказал что C# и С++ это почти одно и тоже, но в C# больше сахара, и потому на нём проще писать. Этот "сахар" - решающий фактов для инди? Предположим: я хочу изучить с нуля программирование и движок для инди-геймдева. Мне почти со 100% посоветуют Unity (или RPGMaker/Gotod), сказав что "там С#, и вообще всё легко и просто" (не смотря на то, что при запуски Unity после UE у меня сложилось прямо противоположное впечатление, по крайней мере по первому восприятию). Однако, находятся люди, которые наоборот топят за UE, и говорят что он намного лучше для инди, т.к. "там из коробки всё есть, и вообще там графика лучше". Очень часто вижу дисскусии, где люди (профессионалы или нет) весьма убедительно джанглируют аргументами в духе "У меня на UE все есть для работы, а тебе нужно доплачивать за плагины, лох, ЛООХ!1" или "UE - отстой, блюпринты для инвалидов" и тому подобное, и поэтому выяснить истину, прочитав статью/посмотрев видео для не-профессионала в этой сфере практически невозможно. Что определяет такую функцию как "возможность движка в 3D игры, или почему на Unity пишут в основном 2д-рогалики-платформеры"? Прошу знающего, адекватного человека (не-фаната определённого движка) пролить свет истины.
Для красивой и производительной картинки, особенно в 3D, в Unity надо затратить намного больше сил чем в UE.
Кстати почему-то не упомянут Unigine, это считай произвоидительность UE + на выбор C# или С++ (полноценный, а не обрезанный как в UE), сообщество только не очень большое.
>Для красивой и производительной картинки, особенно в 3D, в Unity надо затратить намного больше сил чем в UE.
Почему? С чем это связано? Я не понимаю. Всё дело в рендере или... или в чём? В каких-то "багах" самого двигла?
Unity с нуля делает "мультяшную" графику, Unreal с нуля ближе к фотореалистичности.
В UE4 вполне полноценный C++, просто там очень много макросной "магии" в API движка. А так особых ограничений нет.
Никакой разницы, всё зависит от моделей и шейдеров, особенностей отрисовки(кастомная в т.ч.). В производительности так же вопросы, т.к. не смотря на то, что лучшие/новые решения по графике чаще появляются раньше в Unreal, но с некоторым запозданием с теми же цифрами появляется и в Unity.
Возможно!(и даже весьма сомнительно), что в Unreal проще работать с AAA графикой, дабы добиться лучшей производительности. Но от спецов по графике я слышал, что и то, и другое, так себе решения - надо делать рендер с 0 под конкретные нужды игры.
Не имею профессионального опыта, скажу, как новичок, который пробовал Unity, Godot и UE4.
Размер движка. UE4 просто огромный. Надо скачать 12гб (что довольно не быстро для клиента Ростелекома с ADSL), на диске он будет занимать чуть меньше 30гб. Собрать из исходников ещё сложнее (мне не хватило старого SSD на 90гб, который я заботливо для этого освободил).
Поддержка IDE. В UE4 огромное количество макросов, подсказки по которым мне смог показать только Rider (но он хочет денег, даже от новичков и инди с нулевым бюджетом на разработку). VS Code и VS2019 с макросами вообще никак не помогали, с тем же успехом можно набирать код в блокноте. Для VS2019 есть Visual Assist, но он тоже не бесплатный :-(
Сложный API. Что в первую очередь будет делать новичок? Лично я полез делать Character Controller. Вроде UE4 в этом плане лучше всех, из коробки есть ACharacter, который умеет ходить/плавать/летать/приседать, умеет взаимодействовать с физикой и даже мультиплеер уже поддерживает. Но вот возможности бегать (или ложиться, например) нет. Кажется, что недостающую возможность можно очень легко и быстро реализовать. Для этого надо расширить два класса UCharacterMovementComponent и ACharacter. Наследуемся от UCharacterMovementComponent и офигиваем: получившийся класс унаследовал целую кучу переменных и методов от всей иерархии наследования, в которых новичок просто утонет. Официального гайда по расширению функционала контроллера персонажа нет, но я, как новичок продвинутый, решил поглядеть исходники, чтобы добавить режим бега, по аналогии с режимом ходьбы (банальное увлечение maxWalkSpeed в рантайме триггерило античит и персонажа телепортировало назад в режиме мультиплеера). Открываем UCharacterMovementComponent.cpp и офигиваем второй раз: 12к строк кода и это если не открывать исходники базовых классов, которые выше по иерархии. Много ли новичков умеют читать чужой код, да ещё и в таком объеме? Я умею, но как добавить дополнительный режим передвижения (без костылей) быстро сообразить не смог, ибо режимы передвижения перечислены в enum и задачка расширять функционал этого класса явно не для новичка. В защиту UE скажу, что в Unity встроенный Character Controller просто ужасен и его лучше писать с нуля: с физикой никак не взаимодействует, коллбек OnControllerColliderHit выделяет память в куче при каждом вызове, на форуме самой Unity можно найти сообщения от разработчиков от 2015 года, что этот контроллер был временным решением и они делают новый (его можно найти на GitHub'е, но он заброшен с конца 2019). Также UE единственный (из троицы) использует полноценное наследование, в Godot наследование не настоящее, в Unity его вообще нет и мы пишем обертки (MonoBehaviour) над стандартными компонентами.
Game Framework. Для новичка это именно минус. В Unity/Godot новичок создаёт пустую сцену, запускает и видит черный экран. Далее добавляет камеру, снова запускает и видит свою пустую сцену, а в Unity может ещё и подвигать камеру в scene view, пока сцена запущена, т.е. все логично и очевидно. UE в аналогичной ситуации магическим (для новичка) образом сам добавит дефолтный pawn (с летающей камерой) в сцену. Как новичок, я бы хотел видеть Game Framework в виде подключаемого плагина, но как не новичку мне очень не хватает подобного фреймворка в Unity/Godot, где производится изобретать собственные велосипеды.
Размер билда. Как новичок и инди-разработчик я вряд-ли смогу запилить полноценный проект с качественными моделями/текстурами/анимациями/сюжетом, поэтому в качестве целевой платформы лучше всего подходят мобильные устройства, где можно обойтись простыми low poly style моделями и простым/отсутствующим сюжетом. Будут ли довольны пользователи размером в 100+ мб в игре, в которой нет ни навороченной графики, ни длинного сюжета с озвученными диалогами?
Я не топлю за Unity или Godot, в обоих движках есть вещи, которые лично мне не нравятся. У Unity закрытые для простых смертных исходники, писать можно только на C# (подключить C++ либу можно, но вызывать её код можно только из C#). Unity использует форк Mono двухлетней давности, будут ли они переходить на dotnet6 неизвестно. Многие штуки, которые в UE бесплатны, надо покупать у сторонних разработчиков. Качество кода сторонних плагинов просто ужасно, спасибо сайтам, на которых можно скачать платные плагины и посмотреть за что просят несколько десятков баксов. Я не видел ни одного плагина для рантайма, у которого был бы оптимальный код, который приятно читать, многие не понимают разницы между полем и свойством и постоянно дёргают вычисляемый геттер вместо того, чтобы сохранить результат в локальную переменную (самое популярное Vector3.normalized, особо упоротые вызывают 3 раза по отдельности для x, y и z), не догадываются, что умножение на 0.5 быстрее деления на 2 и т.д. Да что там сторонние разработчики, если даже в самой Unity используется camelCase для public полей и свойств, а почти все обучающие материалы приучают не пользоваться инкапсуляцией, назначая сериализуемым полям модификатор public. Считаю, что в плохом качестве игр виноват не движок, а кодеры, которые C# только в Unity видели.
Godot развивается странно и медленно. Мне непонятно, зачем надо пилить собственный физический движок вместо того, чтобы обновить bullet до актуальной версии и глубже его интегрировать(прикрутить многопоточность, например). Методы для физических запросов странные: есть понятный raycast, а есть странный cast_motion, который можно использовать с любым примитивом(sphere, box, capsule, convex), но который возвращает массив с двумя дистанциями (безопасная дистанция до столкновения и дистанция, на которой произойдет столкновение), хотя я бы хотел знать точку попадания, нормаль, объект, с которым произошло пересечение. Баги не исправляют годами: колеса (VehicleWheel) не крутятся и не поворачиваются, если находятся в воздухе (не касаются земли); строгая типизация в gdscript не работает(вываливается ошибка), если из скрипта_1 ссылаться на скрипт_2, а из скрипта_2 ссылаться на скрипт_1(в моем случае в скрипте_1 был метод, который принимает аргумент типа скрипт_2, а скрипт_2 пытался вызывать этот метод из скрипта_1, на GitHub баг висит с 2018 года, обещание пофиксить переносили от версии к версии, сейчас обращают исправить в 4.0). Писать на GDNative тот ещё квест, проще форкнуть движок и расширять движок модулями.
Считаю, что UE4 лучший движок на рынке. Но им трудно пользоваться из-за его размеров. Будь бы у него такой же простой и безопасный API, как у Unity/Godot, то в сторону Unity я бы даже не смотрел.
Я бы еще добавил папу камней в сторону godot. На нем пишу уже несколько лет. Перешел с Unity и XNA.
class_name - это по факту просто глобальный макрос делающий preload скрипта. И вся надежда на gdscript 2.0, в godot4. Либо юзать C#. Моно кстати туда можно любое прикрутить, если разобраться со scons.
Но в защиту скажу, что его исходный код читается на одном дыхании.
Реально читать исходник годота проще, чем какой нибудь xna и уж тем более ue4. С++14-20 без метамагии из макросов и минимум шаблонизации. Но минус. Нету своего GC или аллокатора с пулингом памяти. От сюда для движка операции instance или new очень дорогие и постоянно обращаются к куче. Обходить эти проблемы приходится самостоятельно, контролируя создание и уничтожение узлов в ручную, большими пулами.
Добавлю что киллер фича движка в том, что анимируется и интерполируется - все. Буквально все. Ты из коробки можешь анимировать буквально любой объект и любое его поле. А встроенные инструменты позволяют делать анимации и скелеты в 2д, не хуже чем в Spine. В 3д страдает fbx формат, т.к. их фбикс экспортер саморисный и весит пару килобайт. А так тоже, экспортируй что угодно. А при грамотной игре с вьюпортами, можно хоть медиум делать с параллельными мирами.
А написание чарактер-контроллера с нуля, с блэкджеком и физикой занимает при опыте 5 минут, буквально.
Это опенсорс и у них мало аудиторов PR. Исправлений багов много, 1000+ не закрытых PR, но их все тупо изучить не успевают. Опенсорс все таки. Я сам лично два критичных бага закрыл в версии 3.х. И теперь время от времени, сам исправлюсь баги и шлю PR с исправлениями.
Движок дает идеальный минимум фундаментального инструмента, из которого собрать можно что угодно. Хоть авиасимулятор, хоть ММОРПГ. Тот же сторонний физический движок легко можно интегрировать в движок игровой. Заходим в исходники modules/bullet и сразу видно, как реализована их физика. Оно юзает общую абстракцию PhysicsServer. (Аналог PhysicsSystem в ECS парадигмах). И по аналогии напиши хоть 10 разных физических движков, по сути реализуя абстрактное API и все.
Но это пока что самый удобный движок, на котором я могу делать гиперказуалки, все возможные 2Д и простые 3Д лоу-поли игры, без геммора и десятков помошников. И вес билда в 9мб при определенных стараниях не может не радовать. Меньше чем у cocos2d-x
Вооот, это уже больше похоже на нечто конструктивное. Хотя, отзыв от какого-нибудь профи был бы очень кстати всё-равно. Только скорее всего, они такой ерундой не интересуются, у них работы полно)
банальное увлечение maxWalkSpeed в рантайме триггерило античит и персонажа телепортировало назад в режиме мультиплеера
Нет, если делать это со стороны сервера, а не клиента. Собственно, именно так все и делают уже очень давно и эпики в том числе называют это оптимальным путем.
Хм... Значит я был очень близок к цели)
Моё решение было задать maxWalkSpeed сразу равным скорости бега, а в рантайме при ходьбе уменьшать (при беге восстанавливать) эту скорость. Но мне показалось, что такое решение "плохо пахнет".
Павну задать два параметра. Хотьбы и бег. А контроллер должен только контролировать, а не увеличивать скорость. Сервер получает информацию об контроллерах. Будь то AI или игрок. Он должен вызывать методы, которые меняют скорость уже самого павна на те или иные параметры. Тем самым контроллер не должен менять параметры напрямую. Его лишь задача задать направление контролируемого павна и сообщить ему, что игрок нажал кнопку бега, тем самым переключая вектор ускорения с хотьбы на бег уже на стороне сервера, который уже задан в павне. А не пытаться модифицировать вектор ускорения напрямую.
Интересно было бы посмотреть на статистику по движкам среди успешных или хорошо оцененных игр, т.к. на том же Unity полно проходных, а то и откровенно мусорных проектов.
Это как раз из-за его распиаренности и кол-ва обучающих материалов. Многие просто пробуют себя именно на этом движке, попутно заливая свои проекты в стим.
Думаю, что на том же Unreal таковых игр намного меньше, т.к. его в качестве движка для обучения берут заметно реже и качественных проектов в процентном соотношении получается больше, чем у Unity.
=) как человек который судил игры на девгаме, хочу сказать что сейчас инди треша который делается на анриле, гораздо больше чем раньше и иногда больше чем сделанного на юнити, другой вопрос что не все игры доезжают до релиза. И если брать среди релизнутых игр, то наверное да, там будет превалировать юнити.
Инди-разрабы часто пытаются уходить в чистые блюпринты, не используя С++? Или там по другим аспектам косяки идут в играх? И да, как много было "пиксельных-2d-платформеров" на движке UE на девгаме, который вы судили? Любопытно было бы узнать.
Очень много блупринтов. Чуть ли не 90% контента в UE4 маркете - это блупринты, кривые и косые. Когда нужен реально С++, по факту не так часто. Если это не ААА или АА проект.
UE4 почти не имеет вменяемого инструмента для 2Д. По сути там псевдо-2д, которое работает в 3Д сцене и не имеет главных 2Д фишек. Слои отрисовки. Полигонные спрайты, а не чистые картинки. 2Д скелеты, 2Д физики, деформация спрайтов и т.д. и т.п.
Познакомился с парой проектов на UE4 и в принципе, проекты дохнут из за отсутствия мотивации. Гейм-разработка, это кода 10-15% по факту. Очень. Даже не так. ОООООООЧЕНЬ мало людей знают игровые паттерны. Не говоря уже о том, что каждый третий пытается сделать убийцу сталкера, но не владеет даже базой в линейной алгебре. Вон парень выше писал, об сложности расширения контроллера для бега. Хотя подход изначально не верный. Контроллер - это контроллер. А движением должен заниматься Pawn, получающий команды от контроллера.
Хотя UE4 учит лучше всего геймдезайниров оптимизации. Ибо если налепить в сцену в тупую 100500 мешей. Какой бы крутой движок не был, его никто не вывезет. Надо изучать лоды, спекать свет, использовать фейки и т.д.
Юнитисты же наглухо забывают про геймдезайнерскую оптимизацию из за чего сцена с лесом и травой тупит как не в себя. Начинают присобачивать Burts и другие сложные штуки, которые по факту агрегируют логику игры и векторизуют ее. Хотя вся проблема, что нужно было асинхронный код писать, а они всю логику лепят в Update. А память алочат по мере надобности, а не блоками, для плавности. От чего реалок постоянно дергает ОС за добавкой или освобождением, напрягая GC либо пока оно не сожрет возможный максимум.
По Unity. Вот насчёт DOTS(Burst) в целом соглашусь, работа ради работы, фактически попытка! сделать очень крутой велосипед. И это в тот момент, когда просто выкинули вполне рабочий инструмент для мультиплеера, когда не работают многие дополнительные инструменты в Unity, т.к. не поддерживаются или изначально с багами, хотя справка может говорить иное. Да даже инструментов для async они не стали делать. И чую, опять придётся ждать переезда на новый .Net(которым уже все остальные C# разработчики пользуются) лет 5. Большинству разработчиков хватило бы нормальной работы Update в виде async-ов. Даже в сильнонагруженных проектах мне этого бы хватило.
А вот с памятью не соглашусь. Выделение памяти можно контролировать, но надо хорошо понимать язык C# и процессы. В норме, память выделяется только в момент загрузки/переходов.
2д игр стало меньше в целом, платформеры были, но мало, на анриле может парочку припомню.
Насчёт бп - да, собрать прототипные фичи на основе ассетов и блупринтов гораздо проще чем в юнити. Анрил большими скачками наращивает экосистему вокруг себя, и сейчас можно довольно быстро найти нужные тебе реализации каких то вещей в бп, много уроков и тд.
Тут недавно расстроило состояние ортографической проекции камеры(Свет и динамические тени не работают от слова совсем и по багтрекеру ясно, что это AS DESIGN), так что 2д и аля 2д не для анриала.
Unity — самый популярный игровой движок? Обзор движков, на которых делают игры для Steam