...или почему игровые движки всегда заканчивают одинаково.
Вы задумывались когда-нибудь о том, что самый дорогой движок в индустрии написан так, что его проще выбросить и написать заново, чем понять и починить. Или что самая успешная студия десять лет жила на коде, который сами авторы называли «отколбашенным» и в русском языке есть более подходящее понятие, начинается на г... заканчивается на ...код. А правильный с точки зрения архитектуры движок умирает в безвестности, потому что деньги у компании на его развитие закончились. Если не узнали примеры, то в конце статьи будет пояснение.
Любой движок, на котором есть "живые" игры проходит через четыре стадии: «хоть как-то, работает», «работает, но стыдно показать», «не стыдно показать, но никто не знает как работает», и «работает на отдельном языке, который мы сами же и придумали». Потом круг замыкается, и начинается новый виток истории, потому что команда осознает, что дальше так жить нельзя.
Сразу оговорюсь, что это во многом пересказ чужих мыслей, докладов с GDC, лекций про паттерны, и общение с коллегами из больших студий. Отсылка к словам и блогам двадцатилетней давности тут не для ностальгии, а для дела, потому что в интернете информация живёт недолго, блоги нулевых уже наполовину выпилены, а выводы пятнадцатилетней давности до сих пор актуальны до неприличия.
Архитектуру и дизайн всегда делают разные люди
Первое, что стоит понять про игровые движки, так что архитектура движка и его дизайн (в смысле "проектирование систем") это не синонимы, а архитектор с проектировщиком это реально разные должности и разные люди и тогда получается хорошо, но иногда их совмещает кто-то один бородатый и получается как получается, как в том анекдоте... что если вести девушку и целовать машину, то оба дела делаются плохо.
Потому что архитектура, это про процессы и результаты, а дизайн систем почти всегда про решения и связи. И главное в работе дизайнера это не написать хорошо вместо плохо, дизайн начинается там, где оба крайних варианта хорошие, но тянут в разные стороны, тогда у выбора будут далекоидущие последствия, которые аукнутся года через три. А в первом прототипе движка обычно все плохо, и дизайнер тут обычно катится рядышком пятым колесом, активно мешая команде. Работа дизайнера сделать так, чтобы по всем осям разработки получалось минимальное сопротивление при написании кода и создании контента. Код и контент находятся на разных полюсах разработки, поэтому очень часто это сложно, иногда невозможно.
Гранулярность: гибкость <───────●──────> простота Связанность: несвязанность <──●───────> запутанность (направо не ходить) Гибкость: приложение <─────●──────> библиотека Связность: удобство <───────●──────> ортогональность
Потому что силы, которые тянут ползунок туда или сюда, почти никогда не про программирование, а про деньги и людей: cколько у вас программистов, сколько артистов, кто кому платит зарплату и кто на ком будет экономить. Архитектор же проектирует систему систем, и ему нет дела до вас, денег и людей... конечно, если это хороший архитектор систем.
Паттерны не про язык программирования
Маленькое лирическое отступление. «Паттерн» часто переводят как «шаблон», но шаблон это жёсткая форма, не допускающая вариаций и прижившаяся в русском языке. В английском для разных описательных частей и вариаций разработки применяют несколько слов, что значительно разнообразит и речь, и контекст понимания, и собственно доклады на конференциях.
Такие разные паттерны
pattern не фиксирует форму, а описывает силы (forces) и то, как они разрешаются, оставляя конкретную реализацию открытой. GoF унаследовали слово, но слегка выхолостили смысл и их паттерны куда ближе к шаблонам.
template жёсткая форма с дырками для подстановки. C++ template будет предельным случаем, когда инстанцирование детерминировано, вариаций тут нет, только по типу-параметру.
idiom как низкоуровневая, языко-специфичная конвенция («RAII», «CRTP», «copy-swap»). Устоявшийся оборот речи в конкретном языке, и ближе всего к лингвистическому смыслу слова как узнаваемый оборот.
blueprint это план, который надо выполнить буквально, т.е. инженерный чертёж.
archetype как прообраз, из которого варианты порождаются через отклонение, а не через подстановку. archetype ближе к «видению», чем к шаблону, но в другую сторону и это скорее источник решение, а не сеть похожих решений.
motif используется как повторяющийся элемент, узнаваемый, но без претензии на «решение проблемы». Больше распространен в музыке, но и в технической документации я тоже его встречал при описании систем.
schema абстрактная структура данных/отношений, из области баз данных и больше не про решение проблемы, а про форму организации данных.
convention договорённость, ничем не мотивированная кроме соглашения нескольких людей («naming convention»).
paradigm на порядок выше по уровню абстракции, целый способ мышления (ООП, функциональщина).
Многие эти слова в русском комьюнити заменяют на одно "паттерн". Менять терминологию, конечно, уже поздно, но в голове держите что вместе с паттерном надо читать и контекст, где это слово применяют. Когда говорят "паттерны проектирования", то обычно вспоминают GoF с их фабриками, синглтонами и прочим зверинцем, но почти всё оттуда это design for change, то есть мы уже внутри картинки мира «как нам это программировать» и эти паттерны больше template, blueprint и idiom, нежели сами паттерны.
Но как бы ни хорош был архитектор и дизайнером, угадать масштаб будущей катастрофы с первого раза почти невозможно, поэтому большинство стартует с того, что любовно называют быстро(тут другое слово)-кодингом, он же «кодим как в 1999-м», а потом начинается самое интересное, потому при кажущемся просторе развития, путей по которым идут движки всего четыре. В жизни любой студии, которая пишет свой движок (назовем это Фаза-0), наступает момент «а давайте сделаем конструктор», и мы переходим в Фазу-1...
Все есть объект...
Здесь обычно есть наколбашенный код одной-двух игр, где там всё сделано классами. Чтобы все было сделано классами, надо иметь GameObject, он же GodObject, который знает всё обо всех. И есть второй Бог, он жеGameLevel, который передаётся повсюду и тоже знает всё. Сейчас всё связано со всем, наш ГоблинВожак знает как работает солнце в небе, потому что солнце тоже GameObject
class GoblinLeader : public Goblin { /* параметры + поведение */ }; // иерархия примерно такая: // GoblinLeader -> Goblin -> Enemy -> AiObject -> MoveableObject -> GameObject
Программист про гоблина-вожака тоже знает всё, кто он (это зашито в наследовании), какой он (значения полей) и что делает (код методов) и это хорошо. Но "кто" и "что-делает" слиплись намертво, потому что класс это данные плюс код в одном флаконе, и это плохо.
Фаза-1 очень кривая, зато работает, и работает долго. На тему GodObject есть прекрасная байка из "Блицкрига" от самих разработчиков, когда в какой-то момент нейтральные свиньи отнаследовались от боевого юнита и, увидев врага, патриотично лезли за оружием, которого у них не было, а патроны к нему были из-за неиниченной переменной, а так как оружия у них было, то они массово нулпоинтерели и крашили игру. Починили краш, выдав свиньям парабеллум, но забрав патроны, т.е. проинитив переменную в 0.
В этой байке весь смысл фазы-1, когда весь движок живёт наследованием от одного класса, и баги лечатся наследованием же. Дальше начинается фаза-2 «дальше так жить нельзя», но как я уже сказал, она может отстоять по времени очень далеко. Настолько далеко, что могут пройти годы, пока команда найдет в себе силы, время и деньги для перехода в фазу-2. Можете посмотреть на Wargaming с его более чем десятью лет в проде, кучей игр под все платформы, еженедельных апдейтов... и как они сами признают, движок находится все еще в фазе-1, полёт нормальный.
... но не все можно объектом сделать
Наконец набирается критическая масса «так жить нельзя» и выделяется команда, которая начинает наводить красоту. Появляются модули, менеджеры, стройные классы, появляется динамика и вместо жёсткого наследования начинаются вопросы «а есть ли у объекта компонент с таким именем?».
GameObject* player = scene.findGameObject("Player"); if (!player->hasComponent("ControlComponent")) player->addComponent(new ControlComponent()); player->update();
GameObject худеет до контейнера компонентов, связность кода падает, связанность систем растет. Когда связность падает это всегда хорошо, а плохо то, что взамен прилетает обилие приведений типов, поиск подобъектов руками, умные указатели повсюду (потому что отличить целую сущность от её части теперь невозможно) и messaging, это такой механизм который позволяет вам сообщить объекту что он уже мертв, а как он будет мертв и кто его удалит решает уже другая система. А самый треш, как обычно, всегда оседает в системе GUI, фраза "так исторически сложилось", как раз больше всего про GUI.
Обычно фаза-2 занимает около года или двух, потому что её делают программисты. Год, на самом деле, это очень-очень мало для того чтобы мигрировать большой проект, и чем меньше по времени оказась фаза-2, тем лучше код был перед чисткой. Для примера у Unreal миграция заняла почти 7 лет, с 2007 года, когда они объявили, что будут двигаться в сторону конфигов-кода, до 2014 года, когда это всё наконец заработало.
... но можно сделать конфигом
А дальше начинает происходить магия, на которую уже не в силах повлиять программисты, которые её написали. Если у нас уже есть описание объекта в данных, зачем вообще держать класс GoblinLeader в коде? Уберём. Пусть объект собирается из внешнего файла.
// больше нет класса GoblinLeader, есть описание { "GoblinLeader": { "EnemyComponent": { /* ... */ }, "MoveableComponent": { /* ... */ }, "BossComponent": { /* ... */ } }} // ^ в файл уехали не только константы, но и сам рецепт сборки объекта
Тут обычно приезжает грузовик с граблями и оказывается что описание простого окошка уехало куда-то в XML и теперь этим XML заведует Ваня-Джон-Вапур, которому тоже надо платить деньги, а он за эти деньги будет писать координаты в XML. И Ваня-джун-программист становится внезапно техническим-художником, а вся красивая ООП-модель приложения уезжает в метамодель оконной системы, которую настраивают другие люди и приложение, с точки зрения программиста, становится чужим и незнакомым.
Программист теперь не знает «кто», и гоблина-вожака в коде нет, есть его отдельные части, и даже эти части не полные, а собираются из каких-то других частей. А для кода отрисовки вожак и вовсем ничем не отличается от камня или свиньи, и вполне может хранить парабелум без патронов, или даже патроны без парабелума отдельно и без желания скрашить игру. Зато гейм-дизайнер собирает из компонентов то, что программист и не задумывал, и чинит свиней без программиста, а иногда и быстрее него.
Характерным признаком приближения к фазе-3 будет момент, когда вы знаете компоненты по отдельности, смотрите на что-то в игре и искренне не понимаете, как дизайнеры вообще ухитрились это собрать. С организационной стороны студия в этот момент делится на отделы, обрастает спринтами, митингами и зонами ответственности, за которые никто не хочет браться, потому что «это в чужой зоне» и появляются отдельные профессии вроде верстальщика интерфейса, тестировщика монстров, CI-инженера и технического-дизайнера для уровней и локаций.
И здесь, в этой фазе, заканчивается программирование, код на C++ и начинается полёт фантазии дизайнеров, за что все так любят Unreal. Но взамен прилетает куча проблем и вопросов как этот полет поддерживать. Как сериализовать? Как отлаживать логику, уехавшую в данные? Как мержить два конфликтующих файла настроек уровня? Все вопросы, на которые в мире чистого C++ давно были ответы, приходится решать заново.
А еще вылезает обязанность, которую ненавидят абсолютно все программисты без исключения - переписывать за геймдизайнерами эту логику обратно на C++, когда те что-то запороли, либо у них не работает, либо работает адски медленно. И получаются позиции вроде технических-дизайнеров, то есть слономухов, потому что выделить это в отдельную специальность невозможно, а переписывать чужой плохой код (а чужой код всегда плохой) никто добровольно не пойдёт.
... через свой язык программирования
Круг замыкается, теперь весь игровой код вынесен из движка, а сам движок превратился в виртуальную машину, а вся игра стала просто контентом и остается дать геймдизайнерам возможность создавать контент самим, без участия программистов.
ScriptEngine::ExecuteScript("GoblinLeader"); // "GoblinLeader" файл, где описаны и параметры, и логика поведения, плюсового кода 0.001%
Признак начала этой фазы узнаётся, когда компания снова пытается сблизить программистов и дизайнеров, появляются технические геймдизайнеры и программистам предлагают самим верстать окна. Но программисты хотят писать скрипты текстом, желательно умеющим всё то же, что C++, плюс то, чего он не умеет, а геймдизайнеры хотят окошки, ползунки и визуальное программирование. Перевешивает обычно та идеологиия, кого в команде больше: где в команде программистская культура, там делают через скрипты, где больше арт, там хотят компоненты.
... data-driven неизбежен
Совершенно нет. Это, наверное, главное, что стоит унести из всего текста и сам смысл data-driven это введение новых, обычно не-программистских специальностей, которые для маленькой команды, где сплошные программисты, будет просто вреден. Программисты будут долго и дорого поддерживать построенную вавилонскую башню, которая окупается только масштабом.
Если для окупаемости игры хватает трёх программистов и кода соответствующего качества, то у вас и будет три программиста и код соответствующего качества. И это нормально. Ранние состояния App Store, гиперказуалки, эпоха появления домашних ПК - всё это были примеры, где наводить data-driven-красоту было оверкиллом. К тому же сейчас не 2006 год и можно взять Unity, Unreal или Godot и использовать их хоть как data-driven-конструктор, хоть в чистом "щанакодим" стиле. А уж устроить кашу можно что в коде, что в данных... это вообще любимое занятие начинающих команд.
... to be continued
Двадцать лет назад умные люди уже описали этот путь от объектов к данным и обратно к языкам. Можно было бы подумать, что сейчас все давно пишут «как в фазе 4», но в реальности живые компании сидят на всех четырёх фазах одновременно, и это нормально, потому что фаза диктуется не модой, хотя и модой тоже... (вот ECS стал таким каргокультом), а деньгами и составом команды.
Унификация инструментов, общие движки, визуальные скрипты: всё это никуда не делось, но магия программирования из мира тоже не исчезла и программисты по-прежнему нужны, и игровые, и движковые, и технические, и ui, и скриптовые, и звуковые... и черт-еще-знает-какие.
Колесо Грегори продолжает крутиться и следом за желанием собрать всю игру на визуальном языке придёт желание получить производительность, а за ним появится желание лучше управлять схемой данных, и где-то на этом витке снова захочется свой DSL, или blueprint, или daslang и всё неминуемо начнётся с начала.
Материалы
Scott Bilas, A Data-Driven Game Object System, GDC 2002. Доклад по архитектуре Dungeon Siege, откуда вообще пошла мода на ECS в разработке. Слайды до сих пор лежат в открытом доступе на https://www.gamedevs.org/uploads/data-driven-game-object-system.pdf
Mick West, Evolve Your Hierarchy, Cowboy Programming (2007). Как деревья наследования упираются в стену и превращаются в композицию компонентов. У него же в блоге есть разбор, как продавать эту идею менеджменту, может кому пригодится. https://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/
Adam Martin, серия Entity Systems Are the Future of MMOG Development, блог t-machine.org. Про переход от компонентов к чистому ECS (entity как ID, компонент как чистые данные).
Niklas Gray, Building a Data-Oriented Entity System, блог Bitsquid/Autodesk Stingray (2014, несколько частей) Разбор движка, который реально живёт в фазе data-driven, с цифрами по производительности. https://www.gamedeveloper.com/programming/the-story-behind-the-truth-designing-a-data-model
Mike Acton, Data-Oriented Design and C++, CppCon 2014. Идеологический полюс, противоположный ООП-иерархиям. https://github.com/CppCon/CppCon2014/blob/master/Presentations/Data-Oriented Design and C%2B%2B/Data-Oriented Design and C%2B%2B - Mike Acton - CppCon 2014.pptx
Jason Gregory, Game Engine Architecture (книга). Глава про game object model, где как раз сравниваются inheritance-based, component-based и data-driven подходы как последовательные стадии одного и того же выбора. https://www.gameenginebook.com/
Tony Albrecht, Pitfalls of Object Oriented Programming, GDC Australia 2009. Прямая критика ООП с точки зрения производительности. https://www.gamedevs.org/uploads/pitfalls-of-object-oriented-programming.pdf
Bjarne Rene, Component Based Object Management, Game Programming Gems 5. Инженерный взгляд на ECS.https://gameenginegems.com/gemsdb/book.php?id=7
Борис Баткин/C. Макеев, Component-oriented design on consoles. Стоит глянуть для понимания как устроен современный WarThunder. https://github.com/SergeyMakeev/ecs + https://daslang.io/
З.Ы. Так вот, обещанное пояснение про первый абзац.
Самый дорогой движок, который проще выбросить, чем понять и починить, это CryEngine, точнее его форк, на котором Крис Робертс уже больше десяти лет пилит Star Citizen и сотни миллионов долларов краудфандинга ушли не в последнюю очередь на то, чтобы переписывать движок под себя. Даже движок (движок, не сама игра) GTA VI оценивается индустрией "всего" в 220M$, почти в два раза дешевле чем Star Citizen.
Студия, которая десять лет прожила на г...коде это Mojang и оригинальная Java-кодовая база Minecraft, которую сообщество и сами разработчики в шутку называли "нельзя удалять строки", но это не помешало игре стать самой продаваемой в истории, после Тетриса конечно :)
А архитектурно правильный движок, который умер потому что у компании кончились деньги на его развитие - это Bitsquid, позже переименованный в Autodesk Stingray с чистой data-oriented архитектурой с самого начала, о которой до сих пор с придыханием пишут в блогах матерые игроделы. Был закрыт в 2018-м, потому что рынок массово ушёл в Unity и Unreal, а идеальная архитектура без реальных проектов никому оказалась не нужна.
Комментарии (84)
NeoCode2
16.07.2026 21:06Обожаю ваши статьи. А вот что вы думаете про языки программирования? Наверняка при использовании C++ у вас возникали мысли, "а хорошо бы чтобы была вот такая возможность в языке" или "а хорошо бы чтобы вот это в языке было иначе". Думаю, такие мысли возникают у всех программистов, именно из реального опыта, из реальных потребностей.
OlegZH
16.07.2026 21:06А почему нет? Если есть какие-то важные объекты и особенности работы с этими объектами, то должен быть и подходящий под них язык программирования. Разве не так?
dalerank Автор
16.07.2026 21:06Спасибо. Язык программирования это инструмент, разные инструменты под разные цели, касательно плюсов в целом я доверяю комитету, потому что люди там сидят намного умнее и опытнее меня, и было бы странно им что-то советовать. А если что-то и не нравится, то это решается отдельным макросом, хедером, системой, либой, движком и тд
ksbes
16.07.2026 21:06Да-да. Вот и получаеются скрипты на программе на движке на “макрсах и хедерах” на языке на платформе на системе машиных комманд на микроязыке процессора. Я никакой уровень абстрации не забыл?
Я если что - без претензий, я програмист высокого уровня … Но тенденция!..
Qwest_Prozto
16.07.2026 21:06Иногда язык не должен позволять делать вообще все, что вздумается программисту. Сам C++ в этом плане довольно свободный и позволяют сделать одно и то же множеством способов, попутно отстрелив обе ноги...
Belarus
16.07.2026 21:06Иногда язык не должен
А иногда должен - каждый язык устроен под свой тип програмиста.
ImagineTables
16.07.2026 21:06Рассказ про фазу-1 напомнил мне, как Эрик Липперт сошёл с ума и начал ругать DDD. Поскольку ругать DDD без передёргиваний бесперспективно, он взял то, что в терминах статьи можно назвать гипотетическим кодом движка фазы-1 и начал смаковать все проблемы этого подхода (когда отношения между героем и его мечом описываются наследованием). Хотя описываемая им RPG’шка это оцифровка настолки, и применение DDD даёт классы «таблица с карточкой персонажа», «таблица с карточкой оружия», «игровой мастер» и «кубик». Короче, ему в комментариях
насовалинаписали, что нормальные люди так игры не пишут.Что касается фазы-3, мне кажется интересной одной идейка. (Я, возможно, стучусь в открытую дверь). Помню, моё первое детское впечатление, когда я читал код Duke’а и Doom’а: боже, сколько таблиц! Там, по-моему, даже ГСЧ был таблицей-массивом. Так вот, с одной стороны, вынос всего и вся в джейсончик это, конечно, хорошо, поскольку код не надо перекомпилировать каждый раз, когда Ваня-Джон-Вапур решает поменять баланс. С другой стороны, зачем в рантайме тратить время на загрузку, валидацию, удаление дубликатов, сортировки, сборку и т.п.? Это всё можно было бы написать кодом. Если бы
constevalподдерживал крутые штуки, хе-хе. В общем: было бы круто писать так, чтобы весь период разработки данные шли в конфигах, писались дизайнерами в редакторе JSON’а, и грузились в рантайме со всеми проверками-сборками-сортировками-нормализациями. Но потом, перед релизом, переключаешь конфиг проекта, и тот же код выполняется при сборке, типа, на этапе препроцессинга, над полученными тяжким трудом внешними файлами с конфигами и даёт аналог встроенных массивов и вызовов конструкторов. А затем компилятор уже это всё оптимизирует. Может даже, генерирует одинmemcpyBLOB’а.Вот как-то бы универсально переключаться, чтобы один и тот же код мог выполняться и как рантаймовый загрузчик-обработчик дата-файлов, и как часть препроцессинга. Тут, наверно, нужно специально заточенный ЯП? Или идея полная хрень?
RigelGL
16.07.2026 21:06Достаточно написать генератор с++ из json и запускать перед билдом. И почему бы не брать бинарный json (MsgPack, CBOR)?
Куда более важная проблема — отсутствие hot reload в большинстве языков. Из тех, что помню, таковой есть в dart/flutter, что сильно ускоряет разработку под мобайл, котлин и java. Остальные языки, AFAIK, hot reload из коробки обошёл стороной, и приходится городить вручную перезагрузку dll.
OlegZH
16.07.2026 21:06Что Вы имеет в виду под "hot reload"? Загрузка кода библиотеки во время исполнения?
ksbes
16.07.2026 21:06Не просто загрузка, а перезагрузка уже работающего кода. Как всякие сетевые класслоадеры в Джаве.
В С++, кстати так тоже в теории можно делать… И некоторые программы так и делают и, даже, с другим программами - но почему-то(почему? :) ) с ними борются!
JBFW
16.07.2026 21:06Когда-то очень-очень давно, эта возможность вполне себе была широко распространена, и называлась "оверлеи".
Памяти было физически мало, своп ОС не умела, и если программе надо было больше - вместо участка старого кода загружался оверлей, библиотека с новым.
А почему бы и нет? Прочитал файл в память по адресу ХХХ, передал управление на ХХХ+header_size.Просто потом проблемы с памятью как-то решились, про оверлеи забыли, а вы вот им новое применение нашли.
Делайте.
Belarus
16.07.2026 21:06Visual Studio давно умеет перекомпилировать код у запущенной програмы. Правда, не всегда срабатывает, есть ограничения.
ImagineTables
16.07.2026 21:06Достаточно написать генератор с++ из json и запускать перед билдом
И будет два кода, которые надо синхронизировать. И по отдельности отлаживать. И написать генератор (желательно без ошибок).
Я бы предпочёл что-то вроде следующего. Пишем… за отсутствием у меня фантазии — ключевое слово
concept, а именноconcept CharacterConcept, в нём указываем маппинг полей JSON на поля структуры и остальные настройки, например, сортировку. Этот концепт можно скормить шаблонному загрузчику из стандартной библиотеки, и он, руководствуясь им через рефлексию (или ещё как-нибудь), произведёт загрузку. А можно просто написать:#ifdef RELEASE #import "Characters.json":CharacterConcept(g_Characters) #endifи получить готовый массив прямо при компиляции. Кроме того, этот массив можно скормить полноценной функции (без ограничений
consteval), которая сделает всё, что только хочется, независимо от того, вызвана она при загрузке или препроцессинге.Возможно, синтаксически это несколько наивно, но суть вы поняли. Мне бы хотелось брать всё лучшее из обоих миров: ресурсных дата-файлов и компайл-таймовых возможностей. Причём, даже не для игры. Разве не круто, когда компилятор (линкер) проверяет, что ни в одной локализации не забыт используемый ресурс, но сам ресурс лежит в таблице и вы его правите удобным табличным редактором?
inkelyad
16.07.2026 21:06Я бы предпочёл что-то вроде следующего.
Это эквивалентно. Просто у вас "генератор C++ из... <что там у нас есть>" встроен невидимым для вас образом в компилятор (и эту часть тоже кем-то написана, "желательно без ошибок")
ksbes
16.07.2026 21:06json - это, напоминаю Javascript Object Notation. Зачем что-то изобретать, если можно напрямую работать с первоисточником? Осталось самая малость - просто малопусенькая: написать компилятор Javascript в машинные кода :)
ImagineTables
16.07.2026 21:06А буква X в слове AJAX означает XML, только об этом уже никто не помнит. Боюсь, даже то, что человек помнит само слово AJAX, уже выдаёт в нём не первую молодость. «Говорю об этом со всей молодёжной прямотой!» Короче, JSON это де-факто стандартный язык разметки данных, независимо от ЯП.
Но заменить на что-нибудь экзотическое будет как раз в духе C++.
Scrawach
16.07.2026 21:06Идея вполне себе рабочая. Более того, уже реализованная, например, в языке программирования JAI от Джонатана Блоу, на котором он разрабатывает свои игры. Правда, сам язык пока находится в закрытом тестировании.
Belarus
16.07.2026 21:06Спасибо, наконец я понял зачем может быть нужен constexpr, который так активно пихают в язык.
mSnus
16.07.2026 21:06Спасибо, отличная статья. Последние полгода вайб-кожу свою первую в жизни игру, и уже наступил почти на все перечисленные грабли. А ведь я ещё даже не прикрутил туда никакой графический движок, только HTML и логика на Typescript! Хоть данные догадался вынести в JSON-конфиги... Зато уже можно грабить корованы!
Sazonov
16.07.2026 21:06Я часто замечал ещё одну печальную тенденцию, как человек который делает утилиты для игр.
Компании (и инженеры в них), которые делают или допиливают движки слишком поздно начинают задумываться об интеграции движка/игры с редакторами.
Из последнего - пришлось пару лет назад чинить производительность в некоторых местах редактора, одного из упомянутых в статье культового движка. И очень уж бросались в глаза места где решения принимались по принципу:
Пока производительность не важна, потом оптимизируем, лишь бы получить mvp
Сейчас куча задач по движку, давайте эту часть редактора отдадим на аутсорсинг или джуно-мидлам, пусть учатся, заодно и задачи закроем
Давайте наймём сеньоров, которые шарят в [framework_name] и сделают хорошо. Но «всё выкинуть и переписать» - это джуновский подход, мы так делать не будем, поэтому делайте костыли в тысячи строк, которые точечно решат некоторые проблемы, и, если повезет, не сильно ушатают редактор.
Да да, у нас редактор не запускается в debug сборке в принципе, потому что десяток лет назад, в п.1 мы внесли несколько UB и ключевые компоненты висят на соплях. И ещё куча аналогичных проблем.
Либо ещё ситуация, которую встречал в двух разных, никак не связанных между собой студиях:
Кладем болт на проектирование тулзов, ведь главное супер крутой и производительный движок, и хорошие программисты
Получаем пачку несвязанных инструментов. И чтобы поменять текстуру на объекте, дизайнерам надо запускать 2-3 программы и прогонять сверху питоновский скрипт.
Дальше так жить нельзя, давайте изобретем универсальный фреймворк, для разработки тулзов, который будет правильно интегрирован с движком и каждая команда будет самостоятельно и успешно делать всё в рамках единой концепции
Дизайнеры продолжают пользоваться старыми тулзами, ругаться на что они практически не поддерживаются в угоду нового супер-пупер-редактора, который либо ещё слишком глючный либо ещё не поддерживает все фичи старых редакторов.
Менеджмент начинает давить на команду тулзовиков, просить меньше думать об архитектуре, качестве кода и производительности, в угоду скорейшего выпуска mvp.
Ну и приходим к очередной итерации того, что было написано вначале.
Qwest_Prozto
16.07.2026 21:06Справедливости ради, кое как работающий движок сегодня намного лучше, чем идеальный движок когда то там.
Перестраивать едущий поезд на ходу весьма крутое умениеSazonov
16.07.2026 21:06Это пока эффективный менеджмент и руководство не захотят начать спасать ситуацию путём продажи бизнеса или выхода на биржу.
А потом «внезапно», после независимого аудита, выясняется что говнокода (пусть и прекрасно работающего в продакшене) больше чем кода. И что люди, которые изначально делали очень крутые решения уже давно свалили, просто потому что им не подымали зарплату, мол зачем, если всегда можно нанять новых. И после такого аудита начинают ходить слухи, мол дешевле переобучить всех на анрил, чем продолжать поддерживать на плаву то что есть.
И самая главная проблема - кривая обучения работы с движком улетает в космос и если просто новой команде захотеть делать игру на таком движке, то это оказывается дороже, чем написать и движок и игру с нуля (а лучше - взять что-то более стабильное и документированное).
Так что если движок где-то работает, то это вовсе не означает что он хороший и может быть кем-то еще переиспользован.
Современный геймдев это почти всегда поиск компромиссов между стоимостью, качеством и скоростью разработки.
Joolg
16.07.2026 21:06Давайте выкинем и перепишем, говорили они, это займет пару месяцев. Прошло три года, старый движок все еще крутится на серверах, а половина команды ушла лечить выгорание)
johnriderr
16.07.2026 21:06Дизлайк за кликбейтный, не отвечающий содержанию заголовок. Не хватает кармы для диза статьи, поэтому написал комментарий. Спасибо за внимание.
ksbes
16.07.2026 21:06А как же “истинные конструкторы” вроде годота и роблокса? Живут и здравствуют! Но там сама изначальная идеология - взывная генерация мегатонн говноигр на говнокоде.
Просто мысль - может так и надо людям-то? В массе.
JediPhilosopher
16.07.2026 21:06Если посмотреть на Роблокс, то он где-то на стыке фазы 1 и 2. Как будто они сперва сделали движок на ООП (для середины нулевых это было норм), потом начали прикручивать к нему ECS, но прикрутили не до конца. То есть там есть как базовые классы (если хочешь создать предмет который может лежать в инвентаре - наследуйся от узла Tool), так и сущности (хочешь чтобы у объекта было hp и он получал урон от лавы или стрельбы - добавь ему сущность Humanoid, при этом само название сущности это по сути костыль и заточка игры изначально под бегалку-стрелялку).
Описывал свой опыт ковыряния в его движке для помощи сыну в статье https://habr.com/ru/articles/954936/
В итоге там смесь из того и другого, еще и приправленная явно легаси-структурой с какими-то совершенно произвольными корневыми узлами дерева объектов, явно созданными когда-то давно под какие-то конкретные игры/задачи и ставшие с тех пор обязательным костылем.
ksbes
16.07.2026 21:06Напоминает мне древние консоли, где все игровые объекты отрисовывались как 2 “ракетки” и “мячик” - т.к. были “отнаследованы” от “базовой игры” в тенис (той самой, зелёной).
ch1971
16.07.2026 21:06Видел примерно такое же но в работе с CRM. Окончательный вывод я бы так сформулировал - всё время идёт работа по передаче бизнес-логики в "формат понятный человеку бизнеса/дизайна" во всякие условные xml файлы и/или нодовые стили программирования. Но суть то проекта не меняется и всё равно это и есть исполняемый код. По сути программа перестаёт писаться в условном C# а начинает писаться на какомто жутком франкенштейне который в основном выдумали люди не имеющие к программированию никакого отношения. И пишется людьми не обученными программированию. В итоге они наступают на все грабли которые только можно, повторяют все самые элементарные ошибки которые до них совершали создатели компиляторов-интерпретаторов и архитекторы проектов. А так как они вообще к программированию никакого отношения не имеют то и ошибки эти они не видят а когда видят то не понимают а как исправлять не знают. Это примерно таже история когда разделяют руководство и профессионалов когда руководят люди не понимающие что делают а профессионалы полностью отстранены от руководства. Так называемый "эффективный менеджмент". Инкапсуляция это красивая и нужная концепция но это не повод применять её везде и на максимальных настройках.
inkelyad
16.07.2026 21:06жутком франкенштейне который в основном выдумали люди не имеющие к программированию никакого отношения.
Да нет, выдумывают как раз люди, к программированию отношение имеющие. Только ползучим образом. "А давайте сделаем так, что вот сюда можно не просто значение вписать, а шаблон/формулу и будем его интерпретировать." - это так программисты мыслят. И "загоним логику в XML, превратив его в текст программы" - тоже.
Тут, правда, отдельным пунктом идет "визуальное представление логики", которое тоже все портит. Почему то считается, что "нормальному пользователю" легче понять эту лапшу коннекторов, чем просто текст.
Qwest_Prozto
16.07.2026 21:06Если вы программист, и к вам каждые 10 минут подходит менеджер, который просит передвинуть текстуру на пару пикселей - вам проще сделать ползунок, чтобы менеджер сам все двигал как ему хочется. без вашего участия.
ch1971
16.07.2026 21:06Немного не так. По типу менеджер просит "сделайте так чтобы я сам мог расписать (если оплата в полном объёме то документ на проводку в 1С если меньше то третий отдел без исполнения а если с превышением то в 5ый отдел с пометкой !запрос информации! и на исполнение 1С)" это чтобы вас всё время не дёргать когда чтото по мелочи надо изменить. А по сути он создаёт новый язык программирования при этом не имея о их создании ни малейшего понятия.
inkelyad
16.07.2026 21:06После чего постепенно вообще все становится написанным на таком вот "менеджер мог сам расписать". Одновременно двигаясь в сторону, что на практике не может и не захочет.
Вообще, современным языкам, похоже, не хватает внятно оформленной концепции "единица компиляции/интерпретации с ограниченными правами". Чтобы эти самые менеджеры/пользователи могли сразу на целевом языке писать, но не могли написать лишнего.
ch1971
16.07.2026 21:06Как раз все эти public private protected это попытка в ту сторону... Ну и минимальные знания всё равно нужны. В школе бы вместо пений/рисований добавили бы основы ООП и правила чистописания для кода тем более информатики там сейчас реально много но она вся слишком общая логические операции всякие и системы исчисления - нулевая база. Да ещё бы преподавали бы там не на отцепись. Сейчас в школе только русский язык и литературу с историей можно выучить остальное по остаточному принципу дают. Ну ещё и ИИ этот - уже и непонятно на самом деле кто и что писать будет и к чему вообще следующему поколению готовиться...
inkelyad
16.07.2026 21:06Как раз все эти public private protected это попытка в ту сторону...
Эти - просто про чистоту кода.
И потом что что бы программисты системы ни написали, менеджер (которому тоже права редактирования кода выдали) - все равно может библиотечными функциями работы с файлами пользоваться - на них же все публичные.
Я про что-то вроде этого (условный код, очень грубо)
sandbox config default policy deny allow import reports.* orders.* allow execution "список функций" import "какой-нибудь модуль с утилитными функциями" code include "Тут путь до модуля, который редактирует условный менеджер"После чего этот самый менеджер в своем коде может модулями работы с заказами пользоваться, с отчетами - и больше ничем.
А если попробует - его код просто не скомпилируется.А если работает только с тем, что выдали - скомпилируется и успешно в очередную версию приложения автоматикой поставится.
ManulVRN
16.07.2026 21:06в школе только русский язык и литературу с историей можно выучить
У меня огромные сомнения по поводу истории как минимум. Если человек сам не интересуется историей, от школьного курса в голове только какая-то каша останется, густо приправленная случайным набором дат.
Wesha
16.07.2026 21:06В школе бы вместо пений/рисований добавили бы основы ООП и правила чистописания для кода
Да ладно — они, вон, правила правописания для русского языка осилить не могут — а Вы всё туда же...
funca
16.07.2026 21:06по сути он создаёт новый язык программирования
Ну вот кстати частая ошибка в том, что за набором условий мы сразу пытаемся разглядеть логику и будущий язык программирования - новый, простой и удобный для менеджеров.
Хотя по факту это всего лишь описания бизнесовых правил по типу "ну так вот сложилось". Менеджерам ни какой такой язык нафиг не сдался - для этого у них вообще-то есть программисты. Поэтому попытки здесь что-то наперед формализовать делают только хуже.
Wesha
16.07.2026 21:06программа перестаёт писаться в условном C# а начинает писаться на какомто жутком франкенштейне который в основном выдумали люди не имеющие к программированию никакого отношения. И пишется людьми не обученными программированию. В итоге они наступают на все грабли которые только можно, повторяют все самые элементарные ошибки которые до них совершали создатели компиляторов-интерпретаторов и архитекторы проектов. А так как они вообще к программированию никакого отношения не имеют то и ошибки эти они не видят а когда видят то не понимают а как исправлять не знают. Это примерно таже история когда разделяют руководство и профессионалов когда руководят люди не понимающие что делают а профессионалы полностью отстранены от руководства. Так называемый "эффективный менеджмент".
Эко Вы сейчас по вайбкодерам проехались!
inkelyad
16.07.2026 21:06"Любой язык конфигурирования стремится стать тьюринг-полным языком программирования." (с) Не знаю чей
А где же ответвление от четвертой стадии? Который "Если у нас все равно язык программирования получился, то давайте возьмем не тот, что у нас получился, а какой-нибудь из существующих"?
Или я плохо читал и в статье такой вариант тоже описан?ksbes
16.07.2026 21:06Такого варианта нет. Т.к. на четвёртой стадии так, обычно, никто не делает. Это закладывается сразу в нулевой, ну на худой конец - в первой. На четвёртой разве что сменить уже существующий могут.
inkelyad
16.07.2026 21:06На четвёртой разве что сменить уже существующий могут.
Ну так я именно про это. "У нас гадость получилась, под которую средств разработки нет и которую месяц новички учат. Давайте какой-нибудь LUA или вариант Python возьмем."
ksbes
16.07.2026 21:06Так в том и дело что меняют LUA на С#-скрипт, например. Своя самописка обычно настолько глубоко пустила корни в “ядерном” коде движка - что её от туда хрен вытащишь! Особенно на 4-й стадии, где даже думать о том чтобы дыхнуть в сторону “ядра” - страшно.
Qwest_Prozto
16.07.2026 21:06Вообще, это настолько дорого что так не делают. Кажется, это уже произошло с cdpr? Там стало не хватать старых разработчиков, понимающих их движок, и компания решила просто переехать на UE, т.к. это проще для новых сотрудников.
inkelyad
16.07.2026 21:06Одна из движущих сил цикла, кстати, которая в статье, вроде бы, не затронута - страх перекомпиляции. Нужно поведение объекта(или даже не объекта) изменить? Можно тупо код подправить. Но нет, обязательно все вынесут в конфиг. Потому что перекомпилировать и перезапускать приложение (или, еще хуже, большую систему) - долго и утомительно. А на пользовательской стороне часто вообще невозможно.
monobogdan
16.07.2026 21:06А инкрементальная компиляция для кого?))
inkelyad
16.07.2026 21:06А инкрементальная компиляция для кого?))
Она не поможет, если код уже опубликован в распространяющей платформе, заверен разными подписями, проверен на 'не злит ли он антивирусы' и так далее. Если его менять - это же все заново проделывать надо. А конфиг - можно быстренько подправить и тот же самый бинарник его без всей этой бюрократии съест.
Joolg
16.07.2026 21:06Вынос в конфиг это грамотное разделение контента и логики. Программист не должен собирать билд каждый раз, когда геймдизайнер меняет базовый урон от меча
inkelyad
16.07.2026 21:06Программист не должен собирать билд каждый раз,
Правильно, это должна делать система сборки и, если возможно, рантайма. Скомпилировать исходник с константами - это доли секунды, так-то. А вот сделать так, чтобы они реально работать начали и это было быстро - ну, тут все систематически грустно.
ksbes
16.07.2026 21:06Главное следить, чтобы конфигурация не стала Тьюринг-полной! Чтобы геймдизайнер не брал на себя функции программиста. Типы урона с вызываемыми им соответствующими эффектами - вполне нормально захаркодить.
Jijiki
16.07.2026 21:06Студия, которая десять лет прожила на г...коде это Mojang и оригинальная Java-кодовая база Minecraft, которую сообщество и сами разработчики в шутку называли "нельзя удалять строки", но это не помешало игре стать самой продаваемой в истории.
понял значит вы не осилили впринципе подход вокселей
в целом как я понял вы программист прикладного уровня, у вас страдает описание => всего, буквально вам всего не хватает в каждой статье, нет ни одного адекватного примера из раздела геймдев снизу вверх, вы наверху, как будто тот самоуверенный геймдизайнер где, чтобы он ввёл хотелку надо сделать много чего.
почему так? я сужу по вашему контенту, вам важнее форма подачи, но не конкретность, хотелки обзора фишек могут обгонять теоретическую базу, и мы скатываемся в контент коих миллионы всега была, а должно было быть по другому, обзор снизу вверх, где видно, что вы вообще хотели, и о чем вы пишите.
dalerank Автор
16.07.2026 21:06Речь в тексте шла о качестве кодовой базы и о том, что грязный код не помешал Minecraft стать самой продаваемой игрой. При чём тут "подход вокселей" мне не очень понятно, это спор с тезисом, которого в статье не было.
Если у Вас есть конкретный пример "геймдева снизу вверх", которого, по-вашему, тут не хватает, приведите его, разберём.
Первый программист пишет то, что решает задачу конечного пользователя: бизнес-логику, приложения, код поверх движка. Второй пишет то, на чём это работает: ОС, драйверы, компиляторы, рантаймы, сам движок. Вот только у второго тоже есть пользователь, и это первый. Так кто из них прикладнее?Jijiki
16.07.2026 21:06Скрытый текст
исходя из вашей глубины обзоров обсуждать вертикальную V без горизонтальной V не имеет смысла, да и плюс надо видеть структуру минимального запускаемого примера! поэтому получается, мы можем трактовать, как уб словесное обсуждение (просто словами), то что упрощенно можно показать, в подверждении того что вы хотели сказать прикрепляя свои примеры - свой взгляд, чтобы за вашими тезисами были не как говорят слухи про "вот говорят, что у майнкрафта был плохой код в 2010 году", ну говорят и? ну и пусть говорят, сдесь и сейчас в статье вы перечисляете движки или игры, но своего примера - своего взгляда не показали!
нету вашей линии, вашего ответа на всё это, лично вашего взгляда, потомучто мы не на экзамене, где повторить сарафанку это самоцель, нет это не цель, должны быть критерии какие-то, что конкретно в тех движках, что конкретно в коде майнкрафта не так, и я думаю вы не расскажете об этом, вы среди прочего прилинковали ссылки на конференции, но те конференции придерживаются правила чистоты своих рассуждений, по крайней мере тех, что я смотрел, там нет воды, нет мне показалось, там есть какая-то конструктивщина. А в примере как создать обьект какая конструктивщина, если условных нюансов дофига! А вы показываете на голубом глазу какой-то там из наивных. Попробуй догодайся, что вы имели ввиду.
VADemon
16.07.2026 21:06https://youtu.be/vXaWOJTCYNg сказ о том, как mojang unit-тесты для себя открыли. Если нужна дата, сами найдете, когда внутри бинарников API появилось.
Это примерно отражает культуру разработки компании. Если считать по таксономии автора, Minecraft до, примерно, 1.13 (2018) пребывал в первой фазе. 1.13 - первая версия, от которой можно смело считать переход на (частичный) data-driven подход. Data packs того же толка нововведения. А отсутствие хоть сколько стабильного modding API чем назвать? Если ядро настолько нестабильно, что даже Forge и т.п. за всё время стабильную прослойку не написали? Кульминацией этого цирка стал Fabric, где захукать чей-то код на свой страх и риск сделали нормой.
но своего примера - своего взгляда не показали!
По-моему автор уже столько всего нагляделся, что остается только покуривать в сторонке и грести вперед к релизу в меру сил. Иными словами - единственно верного подхода не выходит.
Antohin
16.07.2026 21:06На просторах интернета слышал такую байку про "всё есть объект" и наследование. Жил-был специализированный авиасим - военные вертолетчики в нем тренировались. И вот приходят к разработчикам австралийские вояки - всё у вас с симом хорошо, всё нравится, только допилите нам в сим кенгуру. Те пасутся стадами, при звуке вертолета начинают разбегаться, чем демаскируют вертолет. Мы, мол, пилотов специально на этот момент треним. Разработчики почесали в репе, как бы попроще запилить фичу и пришла им в голову светлая мысль - дык эти кенгуру один в один пехота - те тоже
разбегаютсярассредотачиваются при виде вертолета. Отнаследовались, настроили свойства и т.д.... На тесте кенгуру успешно разбегаются как задумано - красота. А потом перегруппировываются и вдогонку пролетевшей вертушки выдают залп из ЗРК %) Чем дело закончилось не помню - то липарабеллумЗРК отобрали, то ли заряды к ним.ManulVRN
16.07.2026 21:06О, какая древность! Чуть ли не с фидошных времен помню. Интересно, есть ли хоть какая-то фактическая основа под байкой.
В том варианте, что я читал, кенгуру добавили просто для реалистичности, что значит "пилотов специально на этот момент треним" в контексте совершенно непонятно, тренируют летать шепотом, что ли?
axel_pervoliajnen
16.07.2026 21:06Другой вариант байки:
В Германии отработка пуска противорадарных ракет на Торнадо. А в это время один полицейский гаишник хвалился другому новым сканером скорости и навел на пролетавший этот Торнадо. А-ля как сцена в Такси 2.
Ну и противорадарнаяя ракета стартанула и навелась на полицейских гаишников.
Joolg
16.07.2026 21:06Майнкрафт - живое доказательство того, что бизнесу вообще плевать на чистоту кода) Если твой джава-костыль генерит миллиарды долларов, это уже не костыль, а капитальная несущая конструкция
LiamBlue
16.07.2026 21:06Бизнесу не плевать на последствия хорошего/плохого кода. Когда там начинается долгая морока с добавлением фич, постоянные глюки, когда команда выгорает и увольняется.
И наоборот, когда хороший код позволяет внедрить интересные фичи, невозможные с плохим кодом.
JediPhilosopher
16.07.2026 21:06Но это надо долго обосновывать. И подсчитывать. И последствия взвешивать. Если цена экономии недели на добавление типичной фичи - год на переписывание всего с нуля, то оно того не стоит.
StreamThread
16.07.2026 21:06Первый CryEngine был полу-data-driven: большая часть сущностей описывалась в Lua скриптах, уже были доступны префабы как группы объектов (которыми художники crytek походу не пользовались, так как этот функционал появился поздно).
Но многие вещи ещё были захардкожены (типо некоторых интерфейсов сплеш скринов загрузки уровней, которые в два счета переносятся в Lua). Видимо многое еще подтягивалось с прошлых итераций движка/проектов на нем, и было некогда/лень это дело модернизировать.
Daddy_Cool
16.07.2026 21:06Я не настоящий программист, но статья очень понравилась. Но кажется это всё относится не только к 3D движкам, а любым объемным проектам и не только программным.
Чтоб проект развивался нормально - должен быть человек который держит в голове всё. Пусть объектов много и иерархичность выручает. Но! Обратные связи и горизонтальные связи всё запутывают и сложность проекта стремительно растет (видимо квадратично от количества объектов/смысловых единиц).
---
Свинья с парабеллумом это прекрасно!
ilih
16.07.2026 21:06Есть движки, которые сразу начали с четвертой стадии, что продиктовано спецификой жанра: кастомный DSL для визуальных новелл упрощает создание игры, поскольку предметная область узкая и хорошо изучена, а сценарий удобнее писать как текстовый скрипт.
Но когда на таких движках делают ВН с геймплеем, начинаются страдания и боль - инструментов для отладки/профилирования нет, заточенность под ВН мешает в разработке сложного UI и геймплейных механик.
Rafael
16.07.2026 21:06Чтобы все было сделано классами, надо иметь
GameObject, он же GodObject, который знает всё обо всех. И есть второй Бог, он жеGameLevel, который передаётся повсюду и тоже знает всё. Сейчас всё связано со всем, наш ГоблинВожак знает как работает солнце в небе, потому что солнце тожеGameObjectА что мешает спроектировать GameObject таким образом, чтобы не было связей между логически не связанными между собой объектами?
SadOcean
16.07.2026 21:06Есть такие игры...
Их код просто ужасен, костыль на костыле, куча хитрых багов, в архитектуре сам черт ногу сломит. Баланс кривой, а ассеты в полном беспорядке.
Их называют "выпущенные в релиз"
monobogdan
И все таки стиль "щанакодим" в наше время моветон за пределами самопального движка.
Unity по сути принес в массы data-driven описание игровых объектов и префабы в целом. Если посмотреть на движки из прошлого, то можем заметить что в GoldSrc/Source датадривена вообще не было (за исключением того, что энтити вручную описывались в vdf-файле программистами вместе со всеми полями), префабы можно было поставить только в рамках редактора уровней и только до сборки уровня. В самом движке префабов не было.
В UE2/UE3 насколько я помню полноценных префабов тоже не было, было какое-то подобие и все наследовались от CActor.
В GTA тоже многое хардкодилось за исключением конкретных кейсов (места спавна машин, их характеристики), более того, хардкод был в одном большом скрипте main.scm.
dalerank Автор
Боюсь вас огорчить, этот стиль сейчас расцвел как никогда, ибо нет уже у дизайнера никаких ограничений, что позволяет творить лютую дичь и никак за это не огребать. Как ни странно старые кодовые базы намного чище по архиктере, идеям и реализации.
OlegZH
А можно пояснить смысл выделенных слов? Можно, конечно, все ответы найти самостоятельно, но хочется послушать и... начальника транспортного цеха. ;-)
dalerank Автор
Data-driven, когда поведение и структура игровых объектов описываются не в коде, а во внешних объектах текстовых или бинарных.
Префаб (prefab, prefabricated, predefined factory object) это заранее собранный "шаблон/заготовка" игрового объекта, со всеми или частью компонентов, готовый как-то создать, не обязательно это объект сцены, может быть все что угодно.
Энтитя (Entity) - некоторая сущность игрового движка, обычно созданная в сцене
VDF (Valve Data Format) key-value формат Valve для их движков
monobogdan
Да, чёт сам прочёл коммент, не совсем понятно может быть на первый взгляд.
В общем суть в том, что есть две системы префабов: истинная, как в юнити, и не совсем.
Истинная предполагает что описание объекта самодостаточное (сериализует иерархию, компоненты и их поля вместе с ссылками) и любой префаб может быть создан из игровой логики в любой ситуации. Это труъ подход последние лет 10-15.
Не-истинная же может предполагать некоторое подобие префабов, но часто они работают только в рамках редактора уровней (а значит движок о них вообще может не знать), в то время как в коде условная машинка все равно собирается вручную из колес, элементов кузова и т.п