Comments 79
И все таки стиль "щанакодим" в наше время моветон за пределами самопального движка.
Unity по сути принес в массы data-driven описание игровых объектов и префабы в целом. Если посмотреть на движки из прошлого, то можем заметить что в GoldSrc/Source датадривена вообще не было (за исключением того, что энтити вручную описывались в vdf-файле программистами вместе со всеми полями), префабы можно было поставить только в рамках редактора уровней и только до сборки уровня. В самом движке префабов не было.
В UE2/UE3 насколько я помню полноценных префабов тоже не было, было какое-то подобие и все наследовались от CActor.
В GTA тоже многое хардкодилось за исключением конкретных кейсов (места спавна машин, их характеристики), более того, хардкод был в одном большом скрипте main.scm.
Боюсь вас огорчить, этот стиль сейчас расцвел как никогда, ибо нет уже у дизайнера никаких ограничений, что позволяет творить лютую дичь и никак за это не огребать. Как ни странно старые кодовые базы намного чище по архиктере, идеям и реализации.
Unity по сути принес в массы data-driven описание игровых объектов и префабы в целом. Если посмотреть на движки из прошлого, то можем заметить что в GoldSrc/Source датадривена вообще не было (за исключением того, что энтити вручную описывались в vdf-файле программистами вместе со всеми полями), префабы можно было поставить только в рамках редактора уровней и только до сборки уровня. В самом движке префабов не было.
А можно пояснить смысл выделенных слов? Можно, конечно, все ответы найти самостоятельно, но хочется послушать и... начальника транспортного цеха. ;-)
Data-driven, когда поведение и структура игровых объектов описываются не в коде, а во внешних объектах текстовых или бинарных.
Префаб (prefab, prefabricated, predefined factory object) это заранее собранный "шаблон/заготовка" игрового объекта, со всеми или частью компонентов, готовый как-то создать, не обязательно это объект сцены, может быть все что угодно.
Энтитя (Entity) - некоторая сущность игрового движка, обычно созданная в сцене
VDF (Valve Data Format) key-value формат Valve для их движков
Да, чёт сам прочёл коммент, не совсем понятно может быть на первый взгляд.
В общем суть в том, что есть две системы префабов: истинная, как в юнити, и не совсем.
Истинная предполагает что описание объекта самодостаточное (сериализует иерархию, компоненты и их поля вместе с ссылками) и любой префаб может быть создан из игровой логики в любой ситуации. Это труъ подход последние лет 10-15.
Не-истинная же может предполагать некоторое подобие префабов, но часто они работают только в рамках редактора уровней (а значит движок о них вообще может не знать), в то время как в коде условная машинка все равно собирается вручную из колес, элементов кузова и т.п
Обожаю ваши статьи. А вот что вы думаете про языки программирования? Наверняка при использовании C++ у вас возникали мысли, "а хорошо бы чтобы была вот такая возможность в языке" или "а хорошо бы чтобы вот это в языке было иначе". Думаю, такие мысли возникают у всех программистов, именно из реального опыта, из реальных потребностей.
А почему нет? Если есть какие-то важные объекты и особенности работы с этими объектами, то должен быть и подходящий под них язык программирования. Разве не так?
Спасибо. Язык программирования это инструмент, разные инструменты под разные цели, касательно плюсов в целом я доверяю комитету, потому что люди там сидят намного умнее и опытнее меня, и было бы странно им что-то советовать. А если что-то и не нравится, то это решается отдельным макросом, хедером, системой, либой, движком и тд
Иногда язык не должен позволять делать вообще все, что вздумается программисту. Сам C++ в этом плане довольно свободный и позволяют сделать одно и то же множеством способов, попутно отстрелив обе ноги...
Рассказ про фазу-1 напомнил мне, как Эрик Липперт сошёл с ума и начал ругать DDD. Поскольку ругать DDD без передёргиваний бесперспективно, он взял то, что в терминах статьи можно назвать гипотетическим кодом движка фазы-1 и начал смаковать все проблемы этого подхода (когда отношения между героем и его мечом описываются наследованием). Хотя описываемая им RPG’шка это оцифровка настолки, и применение DDD даёт классы «таблица с карточкой персонажа», «таблица с карточкой оружия», «игровой мастер» и «кубик». Короче, ему в комментариях насовали написали, что нормальные люди так игры не пишут.
Что касается фазы-3, мне кажется интересной одной идейка. (Я, возможно, стучусь в открытую дверь). Помню, моё первое детское впечатление, когда я читал код Duke’а и Doom’а: боже, сколько таблиц! Там, по-моему, даже ГСЧ был таблицей-массивом. Так вот, с одной стороны, вынос всего и вся в джейсончик это, конечно, хорошо, поскольку код не надо перекомпилировать каждый раз, когда Ваня-Джон-Вапур решает поменять баланс. С другой стороны, зачем в рантайме тратить время на загрузку, валидацию, удаление дубликатов, сортировки, сборку и т.п.? Это всё можно было бы написать кодом. Если бы consteval поддерживал крутые штуки, хе-хе. В общем: было бы круто писать так, чтобы весь период разработки данные шли в конфигах, писались дизайнерами в редакторе JSON’а, и грузились в рантайме со всеми проверками-сборками-сортировками-нормализациями. Но потом, перед релизом, переключаешь конфиг проекта, и тот же код выполняется при сборке, типа, на этапе препроцессинга, над полученными тяжким трудом внешними файлами с конфигами и даёт аналог встроенных массивов и вызовов конструкторов. А затем компилятор уже это всё оптимизирует. Может даже, генерирует один memcpy BLOB’а.
Вот как-то бы универсально переключаться, чтобы один и тот же код мог выполняться и как рантаймовый загрузчик-обработчик дата-файлов, и как часть препроцессинга. Тут, наверно, нужно специально заточенный ЯП? Или идея полная хрень?
Достаточно написать генератор с++ из json и запускать перед билдом. И почему бы не брать бинарный json (MsgPack, CBOR)?
Куда более важная проблема — отсутствие hot reload в большинстве языков. Из тех, что помню, таковой есть в dart/flutter, что сильно ускоряет разработку под мобайл, котлин и java. Остальные языки, AFAIK, hot reload из коробки обошёл стороной, и приходится городить вручную перезагрузку dll.
Что Вы имеет в виду под "hot reload"? Загрузка кода библиотеки во время исполнения?
Не просто загрузка, а перезагрузка уже работающего кода. Как всякие сетевые класслоадеры в Джаве.
В С++, кстати так тоже в теории можно делать… И некоторые программы так и делают и, даже, с другим программами - но почему-то(почему? :) ) с ними борются!
Когда-то очень-очень давно, эта возможность вполне себе была широко распространена, и называлась "оверлеи".
Памяти было физически мало, своп ОС не умела, и если программе надо было больше - вместо участка старого кода загружался оверлей, библиотека с новым.
А почему бы и нет? Прочитал файл в память по адресу ХХХ, передал управление на ХХХ+header_size.
Просто потом проблемы с памятью как-то решились, про оверлеи забыли, а вы вот им новое применение нашли.
Делайте.
Visual Studio давно умеет перекомпилировать код у запущенной програмы. Правда, не всегда срабатывает, есть ограничения.
Достаточно написать генератор с++ из json и запускать перед билдом
И будет два кода, которые надо синхронизировать. И по отдельности отлаживать. И написать генератор (желательно без ошибок).
Я бы предпочёл что-то вроде следующего. Пишем… за отсутствием у меня фантазии — ключевое слово concept, а именно concept CharacterConcept, в нём указываем маппинг полей JSON на поля структуры и остальные настройки, например, сортировку. Этот концепт можно скормить шаблонному загрузчику из стандартной библиотеки, и он, руководствуясь им через рефлексию (или ещё как-нибудь), произведёт загрузку. А можно просто написать:
#ifdef RELEASE
#import "Characters.json":CharacterConcept(g_Characters)
#endif
и получить готовый массив прямо при компиляции. Кроме того, этот массив можно скормить полноценной функции (без ограничений consteval), которая сделает всё, что только хочется, независимо от того, вызвана она при загрузке или препроцессинге.
Возможно, синтаксически это несколько наивно, но суть вы поняли. Мне бы хотелось брать всё лучшее из обоих миров: ресурсных дата-файлов и компайл-таймовых возможностей. Причём, даже не для игры. Разве не круто, когда компилятор (линкер) проверяет, что ни в одной локализации не забыт используемый ресурс, но сам ресурс лежит в таблице и вы его правите удобным табличным редактором?
Я бы предпочёл что-то вроде следующего.
Это эквивалентно. Просто у вас "генератор C++ из... <что там у нас есть>" встроен невидимым для вас образом в компилятор (и эту часть тоже кем-то написана, "желательно без ошибок")
json - это, напоминаю Javascript Object Notation. Зачем что-то изобретать, если можно напрямую работать с первоисточником? Осталось самая малость - просто малопусенькая: написать компилятор Javascript в машинные кода :)
А буква X в слове AJAX означает XML, только об этом уже никто не помнит. Боюсь, даже то, что человек помнит само слово AJAX, уже выдаёт в нём не первую молодость. «Говорю об этом со всей молодёжной прямотой!» Короче, JSON это де-факто стандартный язык разметки данных, независимо от ЯП. Но заменить на что-нибудь экзотическое будет как раз в духе C++.
Идея вполне себе рабочая. Более того, уже реализованная, например, в языке программирования JAI от Джонатана Блоу, на котором он разрабатывает свои игры. Правда, сам язык пока находится в закрытом тестировании.
Спасибо, наконец я понял зачем может быть нужен constexpr, который так активно пихают в язык.
Спасибо, отличная статья. Последние полгода вайб-кожу свою первую в жизни игру, и уже наступил почти на все перечисленные грабли. А ведь я ещё даже не прикрутил туда никакой графический движок, только HTML и логика на Typescript! Хоть данные догадался вынести в JSON-конфиги... Зато уже можно грабить корованы!
UE2, JadeEngine, CryEngine, OpenSpace... Не в движках дело, а в творчестве.
Я часто замечал ещё одну печальную тенденцию, как человек который делает утилиты для игр.
Компании (и инженеры в них), которые делают или допиливают движки слишком поздно начинают задумываться об интеграции движка/игры с редакторами.
Из последнего - пришлось пару лет назад чинить производительность в некоторых местах редактора, одного из упомянутых в статье культового движка. И очень уж бросались в глаза места где решения принимались по принципу:
Пока производительность не важна, потом оптимизируем, лишь бы получить mvp
Сейчас куча задач по движку, давайте эту часть редактора отдадим на аутсорсинг или джуно-мидлам, пусть учатся, заодно и задачи закроем
Давайте наймём сеньоров, которые шарят в [framework_name] и сделают хорошо. Но «всё выкинуть и переписать» - это джуновский подход, мы так делать не будем, поэтому делайте костыли в тысячи строк, которые точечно решат некоторые проблемы, и, если повезет, не сильно ушатают редактор.
Да да, у нас редактор не запускается в debug сборке в принципе, потому что десяток лет назад, в п.1 мы внесли несколько UB и ключевые компоненты висят на соплях. И ещё куча аналогичных проблем.
Либо ещё ситуация, которую встречал в двух разных, никак не связанных между собой студиях:
Кладем болт на проектирование тулзов, ведь главное супер крутой и производительный движок, и хорошие программисты
Получаем пачку несвязанных инструментов. И чтобы поменять текстуру на объекте, дизайнерам надо запускать 2-3 программы и прогонять сверху питоновский скрипт.
Дальше так жить нельзя, давайте изобретем универсальный фреймворк, для разработки тулзов, который будет правильно интегрирован с движком и каждая команда будет самостоятельно и успешно делать всё в рамках единой концепции
Дизайнеры продолжают пользоваться старыми тулзами, ругаться на что они практически не поддерживаются в угоду нового супер-пупер-редактора, который либо ещё слишком глючный либо ещё не поддерживает все фичи старых редакторов.
Менеджмент начинает давить на команду тулзовиков, просить меньше думать об архитектуре, качестве кода и производительности, в угоду скорейшего выпуска mvp.
Ну и приходим к очередной итерации того, что было написано вначале.
Справедливости ради, кое как работающий движок сегодня намного лучше, чем идеальный движок когда то там.
Перестраивать едущий поезд на ходу весьма крутое умение
Давайте выкинем и перепишем, говорили они, это займет пару месяцев. Прошло три года, старый движок все еще крутится на серверах, а половина команды ушла лечить выгорание)
Дизлайк за кликбейтный, не отвечающий содержанию заголовок. Не хватает кармы для диза статьи, поэтому написал комментарий. Спасибо за внимание.
А как же “истинные конструкторы” вроде годота и роблокса? Живут и здравствуют! Но там сама изначальная идеология - взывная генерация мегатонн говноигр на говнокоде.
Просто мысль - может так и надо людям-то? В массе.
Если посмотреть на Роблокс, то он где-то на стыке фазы 1 и 2. Как будто они сперва сделали движок на ООП (для середины нулевых это было норм), потом начали прикручивать к нему ECS, но прикрутили не до конца. То есть там есть как базовые классы (если хочешь создать предмет который может лежать в инвентаре - наследуйся от узла Tool), так и сущности (хочешь чтобы у объекта было hp и он получал урон от лавы или стрельбы - добавь ему сущность Humanoid, при этом само название сущности это по сути костыль и заточка игры изначально под бегалку-стрелялку).
Описывал свой опыт ковыряния в его движке для помощи сыну в статье https://habr.com/ru/articles/954936/
В итоге там смесь из того и другого, еще и приправленная явно легаси-структурой с какими-то совершенно произвольными корневыми узлами дерева объектов, явно созданными когда-то давно под какие-то конкретные игры/задачи и ставшие с тех пор обязательным костылем.
Видел примерно такое же но в работе с CRM. Окончательный вывод я бы так сформулировал - всё время идёт работа по передаче бизнес-логики в "формат понятный человеку бизнеса/дизайна" во всякие условные xml файлы и/или нодовые стили программирования. Но суть то проекта не меняется и всё равно это и есть исполняемый код. По сути программа перестаёт писаться в условном C# а начинает писаться на какомто жутком франкенштейне который в основном выдумали люди не имеющие к программированию никакого отношения. И пишется людьми не обученными программированию. В итоге они наступают на все грабли которые только можно, повторяют все самые элементарные ошибки которые до них совершали создатели компиляторов-интерпретаторов и архитекторы проектов. А так как они вообще к программированию никакого отношения не имеют то и ошибки эти они не видят а когда видят то не понимают а как исправлять не знают. Это примерно таже история когда разделяют руководство и профессионалов когда руководят люди не понимающие что делают а профессионалы полностью отстранены от руководства. Так называемый "эффективный менеджмент". Инкапсуляция это красивая и нужная концепция но это не повод применять её везде и на максимальных настройках.
жутком франкенштейне который в основном выдумали люди не имеющие к программированию никакого отношения.
Да нет, выдумывают как раз люди, к программированию отношение имеющие. Только ползучим образом. "А давайте сделаем так, что вот сюда можно не просто значение вписать, а шаблон/формулу и будем его интерпретировать." - это так программисты мыслят. И "загоним логику в XML, превратив его в текст программы" - тоже.
Тут, правда, отдельным пунктом идет "визуальное представление логики", которое тоже все портит. Почему то считается, что "нормальному пользователю" легче понять эту лапшу коннекторов, чем просто текст.
Если вы программист, и к вам каждые 10 минут подходит менеджер, который просит передвинуть текстуру на пару пикселей - вам проще сделать ползунок, чтобы менеджер сам все двигал как ему хочется. без вашего участия.
Немного не так. По типу менеджер просит "сделайте так чтобы я сам мог расписать (если оплата в полном объёме то документ на проводку в 1С если меньше то третий отдел без исполнения а если с превышением то в 5ый отдел с пометкой !запрос информации! и на исполнение 1С)" это чтобы вас всё время не дёргать когда чтото по мелочи надо изменить. А по сути он создаёт новый язык программирования при этом не имея о их создании ни малейшего понятия.
После чего постепенно вообще все становится написанным на таком вот "менеджер мог сам расписать". Одновременно двигаясь в сторону, что на практике не может и не захочет.
Вообще, современным языкам, похоже, не хватает внятно оформленной концепции "единица компиляции/интерпретации с ограниченными правами". Чтобы эти самые менеджеры/пользователи могли сразу на целевом языке писать, но не могли написать лишнего.
Как раз все эти public private protected это попытка в ту сторону... Ну и минимальные знания всё равно нужны. В школе бы вместо пений/рисований добавили бы основы ООП и правила чистописания для кода тем более информатики там сейчас реально много но она вся слишком общая логические операции всякие и системы исчисления - нулевая база. Да ещё бы преподавали бы там не на отцепись. Сейчас в школе только русский язык и литературу с историей можно выучить остальное по остаточному принципу дают. Ну ещё и ИИ этот - уже и непонятно на самом деле кто и что писать будет и к чему вообще следующему поколению готовиться...
Как раз все эти public private protected это попытка в ту сторону...
Эти - просто про чистоту кода.
И потом что что бы программисты системы ни написали, менеджер (которому тоже права редактирования кода выдали) - все равно может библиотечными функциями работы с файлами пользоваться - на них же все публичные.
Я про что-то вроде этого (условный код, очень грубо)
sandbox
config
default policy deny
allow import reports.* orders.*
allow execution "список функций"
import "какой-нибудь модуль с утилитными функциями"
code
include "Тут путь до модуля, который редактирует условный менеджер"
После чего этот самый менеджер в своем коде может модулями работы с заказами пользоваться, с отчетами - и больше ничем.
А если попробует - его код просто не скомпилируется.
А если работает только с тем, что выдали - скомпилируется и успешно в очередную версию приложения автоматикой поставится.
в школе только русский язык и литературу с историей можно выучить
У меня огромные сомнения по поводу истории как минимум. Если человек сам не интересуется историей, от школьного курса в голове только какая-то каша останется, густо приправленная случайным набором дат.
В школе бы вместо пений/рисований добавили бы основы ООП и правила чистописания для кода
Да ладно — они, вон, правила правописания для русского языка осилить не могут — а Вы всё туда же...
по сути он создаёт новый язык программирования
Ну вот кстати частая ошибка в том, что за набором условий мы сразу пытаемся разглядеть логику и будущий язык программирования - новый, простой и удобный для менеджеров.
Хотя по факту это всего лишь описания бизнесовых правил по типу "ну так вот сложилось". Менеджерам ни какой такой язык нафиг не сдался - для этого у них вообще-то есть программисты. Поэтому попытки здесь что-то наперед формализовать делают только хуже.
программа перестаёт писаться в условном C# а начинает писаться на какомто жутком франкенштейне который в основном выдумали люди не имеющие к программированию никакого отношения. И пишется людьми не обученными программированию. В итоге они наступают на все грабли которые только можно, повторяют все самые элементарные ошибки которые до них совершали создатели компиляторов-интерпретаторов и архитекторы проектов. А так как они вообще к программированию никакого отношения не имеют то и ошибки эти они не видят а когда видят то не понимают а как исправлять не знают. Это примерно таже история когда разделяют руководство и профессионалов когда руководят люди не понимающие что делают а профессионалы полностью отстранены от руководства. Так называемый "эффективный менеджмент".
Эко Вы сейчас по вайбкодерам проехались!
"Любой язык конфигурирования стремится стать тьюринг-полным языком программирования." (с) Не знаю чей
А где же ответвление от четвертой стадии? Который "Если у нас все равно язык программирования получился, то давайте возьмем не тот, что у нас получился, а какой-нибудь из существующих"?
Или я плохо читал и в статье такой вариант тоже описан?
Такого варианта нет. Т.к. на четвёртой стадии так, обычно, никто не делает. Это закладывается сразу в нулевой, ну на худой конец - в первой. На четвёртой разве что сменить уже существующий могут.
Вообще, это настолько дорого что так не делают. Кажется, это уже произошло с cdpr? Там стало не хватать старых разработчиков, понимающих их движок, и компания решила просто переехать на UE, т.к. это проще для новых сотрудников.
Одна из движущих сил цикла, кстати, которая в статье, вроде бы, не затронута - страх перекомпиляции. Нужно поведение объекта(или даже не объекта) изменить? Можно тупо код подправить. Но нет, обязательно все вынесут в конфиг. Потому что перекомпилировать и перезапускать приложение (или, еще хуже, большую систему) - долго и утомительно. А на пользовательской стороне часто вообще невозможно.
А инкрементальная компиляция для кого?))
А инкрементальная компиляция для кого?))
Она не поможет, если код уже опубликован в распространяющей платформе, заверен разными подписями, проверен на 'не злит ли он антивирусы' и так далее. Если его менять - это же все заново проделывать надо. А конфиг - можно быстренько подправить и тот же самый бинарник его без всей этой бюрократии съест.
Вынос в конфиг это грамотное разделение контента и логики. Программист не должен собирать билд каждый раз, когда геймдизайнер меняет базовый урон от меча
Программист не должен собирать билд каждый раз,
Правильно, это должна делать система сборки и, если возможно, рантайма. Скомпилировать исходник с константами - это доли секунды, так-то. А вот сделать так, чтобы они реально работать начали и это было быстро - ну, тут все систематически грустно.
Главное следить, чтобы конфигурация не стала Тьюринг-полной! Чтобы геймдизайнер не брал на себя функции программиста. Типы урона с вызываемыми им соответствующими эффектами - вполне нормально захаркодить.
Студия, которая десять лет прожила на г...коде это Mojang и оригинальная Java-кодовая база Minecraft, которую сообщество и сами разработчики в шутку называли "нельзя удалять строки", но это не помешало игре стать самой продаваемой в истории.
понял значит вы не осилили впринципе подход вокселей
в целом как я понял вы программист прикладного уровня, у вас страдает описание => всего, буквально вам всего не хватает в каждой статье, нет ни одного адекватного примера из раздела геймдев снизу вверх, вы наверху, как будто тот самоуверенный геймдизайнер где, чтобы он ввёл хотелку надо сделать много чего.
почему так? я сужу по вашему контенту, вам важнее форма подачи, но не конкретность, хотелки обзора фишек могут обгонять теоретическую базу, и мы скатываемся в контент коих миллионы всега была, а должно было быть по другому, обзор снизу вверх, где видно, что вы вообще хотели, и о чем вы пишите.
Речь в тексте шла о качестве кодовой базы и о том, что грязный код не помешал Minecraft стать самой продаваемой игрой. При чём тут "подход вокселей" мне не очень понятно, это спор с тезисом, которого в статье не было.
Если у Вас есть конкретный пример "геймдева снизу вверх", которого, по-вашему, тут не хватает, приведите его, разберём.
Первый программист пишет то, что решает задачу конечного пользователя: бизнес-логику, приложения, код поверх движка. Второй пишет то, на чём это работает: ОС, драйверы, компиляторы, рантаймы, сам движок. Вот только у второго тоже есть пользователь, и это первый. Так кто из них прикладнее?
На просторах интернета слышал такую байку про "всё есть объект" и наследование. Жил-был специализированный авиасим - военные вертолетчики в нем тренировались. И вот приходят к разработчикам австралийские вояки - всё у вас с симом хорошо, всё нравится, только допилите нам в сим кенгуру. Те пасутся стадами, при звуке вертолета начинают разбегаться, чем демаскируют вертолет. Мы, мол, пилотов специально на этот момент треним. Разработчики почесали в репе, как бы попроще запилить фичу и пришла им в голову светлая мысль - дык эти кенгуру один в один пехота - те тоже разбегаются рассредотачиваются при виде вертолета. Отнаследовались, настроили свойства и т.д.... На тесте кенгуру успешно разбегаются как задумано - красота. А потом перегруппировываются и вдогонку пролетевшей вертушки выдают залп из ЗРК %) Чем дело закончилось не помню - то ли парабеллум ЗРК отобрали, то ли заряды к ним.
О, какая древность! Чуть ли не с фидошных времен помню. Интересно, есть ли хоть какая-то фактическая основа под байкой.
В том варианте, что я читал, кенгуру добавили просто для реалистичности, что значит "пилотов специально на этот момент треним" в контексте совершенно непонятно, тренируют летать шепотом, что ли?
залп из ЗРК
ЧУЖИЕ КОММЕНТАРИИ НЕ ЧИТАЙ @ СВОИ КОММЕНТАРИИ ПИШИ
Другой вариант байки:
В Германии отработка пуска противорадарных ракет на Торнадо. А в это время один полицейский гаишник хвалился другому новым сканером скорости и навел на пролетавший этот Торнадо. А-ля как сцена в Такси 2.
Ну и противорадарнаяя ракета стартанула и навелась на полицейских гаишников.
Майнкрафт - живое доказательство того, что бизнесу вообще плевать на чистоту кода) Если твой джава-костыль генерит миллиарды долларов, это уже не костыль, а капитальная несущая конструкция
Первый CryEngine был полу-data-driven: большая часть сущностей описывалась в Lua скриптах, уже были доступны префабы как группы объектов (которыми художники crytek походу не пользовались, так как этот функционал появился поздно).
Но многие вещи ещё были захардкожены (типо некоторых интерфейсов сплеш скринов загрузки уровней, которые в два счета переносятся в Lua). Видимо многое еще подтягивалось с прошлых итераций движка/проектов на нем, и было некогда/лень это дело модернизировать.
Я не настоящий программист, но статья очень понравилась. Но кажется это всё относится не только к 3D движкам, а любым объемным проектам и не только программным.
Чтоб проект развивался нормально - должен быть человек который держит в голове всё. Пусть объектов много и иерархичность выручает. Но! Обратные связи и горизонтальные связи всё запутывают и сложность проекта стремительно растет (видимо квадратично от количества объектов/смысловых единиц).
---
Свинья с парабеллумом это прекрасно!
Есть движки, которые сразу начали с четвертой стадии, что продиктовано спецификой жанра: кастомный DSL для визуальных новелл упрощает создание игры, поскольку предметная область узкая и хорошо изучена, а сценарий удобнее писать как текстовый скрипт.
Но когда на таких движках делают ВН с геймплеем, начинаются страдания и боль - инструментов для отладки/профилирования нет, заточенность под ВН мешает в разработке сложного UI и геймплейных механик.
Чтобы все было сделано классами, надо иметь
GameObject, он же GodObject, который знает всё обо всех. И есть второй Бог, он жеGameLevel, который передаётся повсюду и тоже знает всё. Сейчас всё связано со всем, наш ГоблинВожак знает как работает солнце в небе, потому что солнце тожеGameObject
А что мешает спроектировать GameObject таким образом, чтобы не было связей между логически не связанными между собой объектами?
Есть такие игры...
Их код просто ужасен, костыль на костыле, куча хитрых багов, в архитектуре сам черт ногу сломит. Баланс кривой, а ассеты в полном беспорядке.
Их называют "выпущенные в релиз"
Все там будем…