Основной код поведения в игровых длл, если нужны действия определенного рода - то есть параметры энтити. Например - игрок входит в некую зону - охранник падает мертвым. Три энтити. Сама зона (func_trigger),пусть имя ее будет zone, scripted_sequene (сама энтити-аниматор), пусть будет имя anim, и барни (monster_barney), имя оставим родное. Заходим в свойства zone, ищем там параметр "set target" - что запускать, пишем в нем anim, при желании можно заковырять иные параметры, типа задержки выполнения set target. В свойствах anim пишем в set target model - barney, в set target animation - имя анимации, пусть будет barney death. Готово, вы великолепны. Это я описал примерно, за названия энтить и их параметров ответственности не несу за давностью лет.
Про сорс напишу позже. Там еще вкусняшка добавилась.

Вроде это делается через Path Following System. Т.е. банально через ранее заданные для каждого уровня точки в пространстве.

Это полноценный (хоть и примитивный) AI, никаких триггеров уровня не используется.
https://github.com/ValveSoftware/halflife/b.../roach.cpp#L188

Нуууу... Судя по тому, что я видел в метрошном SDK, демоны у 4A летают так, как описал RedMagic. Ну а вообще, вспомни чёртовы вертолёты в сталкере.

Так же как например вертолёты. Немношко костыльно, но реализовать летунов в хрее можно. Помню в YaE летающих монстров, хотя там тоже сетка.

Правду говорят что ИИ тараканов из первой халвы продвинутее ИИ ботов в современных играх. У них в активностях даже разновидность искуга есть: от света и от существ.



Интересно какой "ИИ" у ворон в сталкере. Тупо кружить над ГГ? Вот чего, а сидящих на засохших деревьях (и крышах/антеннах) и взлетающих от резкого звука (или когда приближается ГГ) ворон сталкеру не хватает.

Idle



Scared

Ты мне напомнил историю, которая была связана у меня с "Банзаем". У меня в стартовой кат-сцене иногда на близком расстоянии от камеры пролетает ворона. И один мой друг, видя это, каждый раз радовался, когда она пролетала, думая, что я специально её "запрограммировал", чтобы придать динамики сцене.

На самом деле получилось получилось это по глупой причине: мы пытались заспавнить ворон нормальным способом, но они не спавнились. В итоге пришлось идти костыльным путём, спавня их на расстоянии пяти метров от актора. В итоге удачно совпало с положением камеры в кат-сцене

RedMagic
Не удержался.
Idle



Scared

Можно отключить конпеляцию лайтмапов и собирать уровень за 10 минут. Картинка конечно беднее станет на оригинале, но если накатить какие-нибудь крутые шейдеры с SSAO и другими плюшками, то станет лучше.


Безусловно, это круто. В сталкере понемногу собирается внутриигровой "редактор" - уже есть нормальный редактор дин. погоды, Редпихтон и abbramcumer вроде делают внутриигровой редактор путей и логики (скрины вроде не выкладывал?), я делал редактор освещения (который в принципе может перерасти с редактор игровых объектов).


Да.

Кстати, ИИ сетка может и потянет. Её можно расположить поверх вторым слоем, в многоэтажных зданиях она так и расположена (но связанна с основной). Помню однажды запускал Болота с кастомным террейном - все НПС ходили в воздухе по старой ИИ сетке.

А вот насколько это сложно реализовать из-за технических ограничений движка - это уже другое дело. В XRay чтобы сделать что-то подобное надо лепить своих костыли поверх старых костылей и костылями погонять.

К тому же не уверен насколько ИИ сетка вообще оправдана в воздухе. Там препятствий мало, можно и на триггерах ИИ слепить: возле высоких объектов типа деревьев поставить запретные зоны (или детектить рейтресингом пути самого монстра), а атаковать только если все кости ГГ видны. Ну а чтобы летающие враги не сталкивались в воздухе друг с другом можно каждому сделать разные высоты полета (не столько ради физики, столько ради красоты, чтобы они кучкой не толпились).

нет, я про сами сценки. Что-то вроде визуального программирования или как в сталкаче всё ручками да скриптами?


Там много чего с воронами связано... какая-то функция MakeMeCrow, которая вызывается при создании любого существа...

buffy,
В сорсе добавилась возможность, называемая Input/Output. В основном - те же яйца, но в профиль.

Позволяет, открыв последний объект в цепочке не заибаццо, пытаясь понять, что на него влияет.
Поясню на примере.


Это Output - то есть открытая энтити влияет на несколько.
Условие одно: При загрузке карты этот logic_auto делает:
Принудительно спавнит первую энтити без задержки.
Выключает вторую энтити без задержки, и включает следующий триггер с задержкой в 4 секунды.

Input то же самое, но указывает на то, какая энтити подала сигнал текущей открытой.
Удобнее "кодить", при этом все возможности хл1 из моего поста выше остались.

А разве они там не "на земле", с т.з. движка?

Аи. Курить видео Марфи Блека. Плейлист "халф-лайф фактс".
Или можно скачать hl sdk, там клиентка открытая, изучай на исходниках.

Также как вертолёт и Дизелевская лодка ;D

Кстати, а какие вообще "энтити" есть в сталкере?
И как у них с.. эм.. использованием в других целях.
В голдсрк/сорсе я могу допустим, с помощью энтити "дверь" реализовать как дверь, так и горизонтальную платформу, как в кваке, так и "вращающийся свет" (в том же Vampire: The Masquerade- Bloodlines так были реализованы вращающиеся на ветру вывески). Или же могу использовать ее, как лифт.

Janice Polito, Entities - это например в CryEngine xml пакеты (набор конфигов, заготовок), что то похожее на префабы.
В Сталкере?... ну если и есть то в UI немного похожее (туториалы как пример или характеры).
Всё ручками, в блокноте, копипастом из имеющихся образцов.

Да их куча - спейс рестрикторы, мобы, предметы и т.д. Каждая из них имеет ещё кучу дочерних, типа - рестриктор - аномалия, смарт террейн и т.д.

Для каждого типа объекта есть свои, написанные ПЫС модули логики, например для физ. объекта можно создать дверь, ворота, проиграть анимацию и т.д. Есть общие параметры логики, те же задержки, получения сюжетных инфопорций, вход в зону, состояние объекта (видимость, сколько жизни и т.д.).

Дизель, Таки не совсем. В ку-подобных движках обычно немного иначе.
Попробую опираться на базовые понятия, чтобы постараться захватить и CryE.
Вот смотри, допустим есть базовый объект для добавления на уровень статических моделей. Это энтити.
Есть объект, добавляющий звук. Тоже энтити. Есть объект, отвечающий за добавление НПС. И это тоже ентити.
Просто у них куча параметров, например, для статической модели поменять саму модель (в современных движках это уже идет наподобии инстанса в коде), звук, его параметры, типа ревербрации, и т.п. Оружие, модель, тип поведения НПС. Ну ты понял, надеюсь.
В мире ку-подобия префабы уже более комплексные и включают в себя несколько энтити, формирующие для игрока объект, со статическими функциями. Например, помнишь ли ты в хл1 автоматы для напитков? Сами браши автомата (кстати да, в мире халфы брашевые энтити - определенного рода модели, даже называются б-модели, в первокваке это, например, аптечки), энтити, обрабатывающая нажатие кнопки use от игрока, функция спаунящая энтити-напитки, энтити, обрабатывающая звуки, энтити света от автомата, и передняя стенка, обрабатывающая дамаг от игрока, которая инициализирует спец.звуки и спавн кучи напитков.


RayTwitty, ну вот, пример дверь. Что, вставив эту энтити, при минимуме усилий я смогу сделать в сталкере? Смогу ли я заюзать ее, как поезд, хоть в стиле Fallout 3 Train?
Просто в халфах энтити больше описывают функцию, которую они делают. То есть они более абстрактны.
Еще пример. Func_pushable - толкатель. В халфе была использована, как конвейер, как платформа для распрыжки из Хена, может быть установлена перед НПС, с проигрыванием анимации "игрока оттолкнули от двери".

RayTwitty, Janice Polito, есть такое - я не туда полез.

Janice Polito, с дверями не всё так просто. Нет - нет - нет. На дверях ты ни куда не едешь, хоть 100 энтити вставь.

В Сталкере - очень важную роль в поведении объекта играет класс, и то при совпадении скелета и анимаций, конфигов, если этого требует класс.

Нет конечно, дверь это дверь Для поезда тебе скорее всего нужно будет взять машину и переделать её логику под работу поезда. Флинт делал:

Дизель, Да все мы в этой теме лезем "не туда".
Лично мне сдк сталкера оставил анальные шрамы ввиду отсутствия документации и тем, что постоянно слал меня натрибуквы к AlexMX.

Очень зря, что разочаровался. Я всегда готов вернуться в x-ray. Движок своеобразный - даже сложнее немного чем CE, но он того стоит.
У меня шрамов не меньше от него - поверь. Единственный минус - это геморой с компиляцией локации, но я уже научился делать максималку без гемороя, в тот момент когда уже был по-уши в CE312.

Дизель, я до сих пор пытаюсь вернуться. И даже частично правлю свою любимый кордон * из 114-54 билдов в тридэ реакторе, но мне не хватает усидчивости, учитывая даже подход GSC к моделлингу.


*Мой ТСС - это смесь обливион лост и сталкера периода крыма, приправленная скетчами 2002 года, перемешанная в блендере с пикником. То есть футуристичный сеттинг 2099+ года, кибер-импланты, соседствющий совок (привет, самосбор, лол), и с атмосферой в стиле system shock 1-2.

RayTwitty, это плюс , или минус для дженерик модостроителя в вакууме?
Если что, я уже давно не вхожу в комьюнити халфодвижков.
Рад, что ты смог в дискуссию почле моего хейт спича

Я думаю, есть просто два разных подхода к написанию подобных "энтити" - либо у нас есть одна большая сущность, к примеру физ. объект из которого мы можем сделать и простую бочку, и поезд со сложной логикой, либо много разных сущностей, которые более менее охватывают большинство задач. В том же сталкере можно написать свой модуль логики, например для работы с краном (у Флинта на канале есть) и потом его использовать в разных местах. Проблема в том, что нужно постоянно дергать С++ программиста, чтобы тот давал скриптеру возможность доступа к базовым объектам в движке, на основе которых он уже может писать свои объекты. Иной раз проще напрячь С++ прогера, чтобы тот сразу в движке написал нужный функционал и не париться со схемами))

Т.з.?

dPlayer, точка зрения.

Я конечно умолчал о том, что и half-life затронул UE4, типа есть подобные проекты.

Могу ли я поинтересоваться, а почему на gameru.net за все эти годы не начал делать half life 2 episode 3?
Мод, который предполагает логичное завершение того, что было показано ранее....

Может потому что гм это по сути одно комьюнити?

Ruw, *шутка про сталкер на удк и край энжине*
Вот именно поэтому.


Как человек, быдлокодящий под юнити, скажу так Юнити говно - хорошего прогера, особенно на с++, особенно за жрат идею найти сложно. У меня в окружении таких нет.

Надо бы тут прояснить за системы Энтий\Сущностей\Entity. А то у каждого какое то свое представление о нем, постараюсь максимально простым языком.
Во первых правильно это называется Entity-Components-System.

Во вторых а что это вообще значит и чем подход отличается от простого подхода описания сущности сразу в объект\класс.
В классическом подходе программист описывает сущность и фактически она становится уникальной своего вида и никак не совместимой с другими. Что бы описать взаимодействия с другими сущностями придется хардкодить в этой сущности описание других сущностей и то как и что он может делать с ними. Да это проще но накладывает огромное количество ограничений.
В ECS системе все строится иначе:
Изначально программист описывает базовые компоненты\components . По сути это классы\интерфейсы в коде если тут есть программисты. Ну например список компонентов:
-компонент ПОЗИЦИЯ(x,y,z)
-компонент МОДЕЛЬ
-компонент ЗВУК
-компонент ПЕРЕМЕЩАЕМАЯ_ПОЗИЦИЯ (расширение ПОЗИЦИЯ)
- и много других компонентов которые реализуют только что то узкоспециализированное и свое уникально неповторяемое.
Дальше программист пишет системы\systems. Система обрабатывает только свои компоненты. Опять же для программистов тут это банальный цикл обрабатывающий только свои компоненты. Грубо говоря например СИСТЕМА_ПОЗИЦИЯ. Она обрабатывает только свои компоненты ПОЗИЦИЯ и ПЕРЕМЕЩАЕМАЯ_ПОЗИЦИЯ. Что то с ними делает и т.д. Тут в общем реализации логики компонентов.
И наконец сами сущности\entity. Это такая пустышка в которую набивают компоненты\components. По итогу например нужно сделать сущность ВОРОНА, значит включаем в нее как минимум 3 компонента ПЕРЕМЕЩАЕМАЯ_ПОЗИЦИЯ , МОДЕЛЬ, ЗВУК. И вот уже есть уникальная сущность но при этом все другие сущности с легкостью знают что с ней можно сделать т.к. они обращаются к компонентам а не самой сущности.


Во третьих а нафиг оно вообще было придумано и так усложнено? Причин самой концепции довольно много но вот главные:
-с таким подходом гарантируется "слепое" взаимодействие сущностей между собой. Т.е. им вообще пофиг что там за сущность но они точно знают что она может и как с ней взаимодействовать. В классическом подходе такое не прокатит и если позже захотят добавить помимо ВОРОНА новую сущность ЯСТРЕБ то придется описывать ЯСТРЕБ, всех с кем он может взаимодействовать и у каждой сущности которая сможет с ним взаимодействовать логику для этого.
-еще один важный момент, весь этот подход автоматически дает базовое распараллеливание кода т.к. самих систем стало много ну системы ФИЗИКА\ЗВУК\СЕТЬ и т.д. В классическом подходе все будет обрабатываться только в одном общем цикле что принесет лишь боль и тонны кода гвоздями прибитого друг к другу.
-т.к. систем опять же много это обеспечивает чистый код т.к. все системы изолированны и не вмешиваются друг в друга в прямом смысле. Образно говоря "спагетти" кода практически не будет.
-сам подход ECS автоматически дает гибкость как для программистов так и для дизайнеров в будущем. Дизайнеры без кода могут создавать новые сущности такие какие им нужны прямо в редакторах например или упрощенной системой скриптования. Тут еще такой момент что если некоторая сущность которую делают дизайнеры часто используется то программисты могут очень просто сделать сущность в коде а дизайнеры уже просто будут добавлять готовую сущность без натыкивания в нее компонентов. С другой стороны дизайнеры могут(опять же скрипты или в ином виде) создавать локальные сущности префабы\prefab в редакторах.
-достигается огромное разнообразие сущностей т.к. компоненты могут быть добавлены\убраны\заменены хоть во время игры так и в редакторах. Аналогично с взаимодействиями сущностей, дизайнер может очень просто "наскриптовать" очень сложные сцены из кучи взаимодействий и они будут уникальны.

А на последний пункт то как эту систему реализуют. В классическом виде в конечном счете всеравно приходят хотябы к базовым возможностям ECS но это как правило оказывается костылями из за неполноценности. Если изначально идут по пути ECS то ее могут сделать полноценной так и частичной отбросив что то. Так же эту систему в обязательном порядке дополняют уже своей уникальной реализацией системы взаимодействий, ну к примеру в движке сорса это система ввода\вывода input\output , в том же юнити это язык c# и т.д.

Минусы у этой системы тоже есть:
-вводить новые системы на поздних этапах гораздо сложнее. Тут важный момент что именно новые, а заменить систему довольно просто. Скажем сменить физический движек или звуковой
-логику работы систем и их взаимосвязь друг с другом(между системами) тоже сложнее реализовывать чем классический единый цикл на всю игру.
-реализовать что то чего не умеют компоненты невозможно или крайне сложно\костыльно.

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

jamakasi, а где вывод или заключение? В Сталкере есть эти самые сущности?
Непонятно. Оценка за сочинение: 3 (не раскрыта до конца тема).

В сталкере, как таковой ecs, нет. Самая лучшая параллель для понимания. ECS это как лего, куча деталей которые подходят друг к другу и из них можно собрать огромное количество домиков, при этом в любой момент можно заменить любую деталь или даже взять кусок домика и прилепить его на другой. Без ecs, как в сталкере, ты можешь отлить из такого же пластика готовый домик или домики а дальше развлекаться только путем пилы\напильника\паяльника(lua в сталкере) и пытаться что то менять в конструкции, да это геморойно и не удобно но в целом можно получить что то особенное чего не получится в ecs но таких вещей очень мало.

И всё равно модинг С.Т.А.Л.К.Е.Р.а лучше, не смотря на все костыли. Кстати, про модинг халвы я узнал из этой темы, до этого думал что на основе халвы только проф. студии что-то лепят.

Не знаю с чем связано, но в HL проще с реализацией новых геймплейных фишек по сетевому коду. Там есть чёткое разделение на клиентскую и серверную часть. Сервер рулит AI, просчётом движения, хитрегом, инвентарём и т.п., а клиент - это чисто front-end с отрисовкой моделек, анимаций, GUI, I/O и т.п.
Есть hl.dll (server) и client.dll (капитан очевидность). В столкире какая-то каша с распределением ресурсов на серверные и клиентские, или я ошибаюсь?

В HL связанно с ECS о чем я выше писал, т.е. нет спагетти кода и все четко разделено. В сталкере как раз таки каша\спагетти и почти все перемешано что хрен разделишь нужное от ненужного.
Еще кстати интересный момент по движку сорса как пример. У него изначально даже сингл на клиент-серверной архитектуре работает, единственное там для локального игрока\сервера использует этакий "pipe" чтобы не гонять трафик через localhost но в тоже время сервер остается полноценным и к нему могут подключаться кто угодно =) Такой вот хитрый ход. Изза этого же кстати всегда в МП адекватно почти все работает из сингла, т.е. ИИ, физика, скрипты и т.д.

Ну у столкира тоже есть клиентские и серверные объекты в сингле, просто там полный винегрет, как ты и писал. Ходит оно через localhost или нет - я не знаю.

На данные движки сообщество разное. Не нужно забывать, что Халва — это больше Запад. А Хрей — это больше РФ. Что тут после этого обсуждать? Ментальность все-таки разная. Хотя *** и там хватает, но даже у них есть такое качество как целеустремленность. Ребятишки уже давно в рынке живут. И у них уже нет тех быдло-манер (по крайней мере они скрываются, на деле есть), которые есть в РФ (и кое у кого на данном ресурсе) — умри ты сегодня, а я завтра на твоих костях..

А вообще, получилось смешно. Я внимательно прочитал всю тему..

Вот в Хрее/Сурсе какие-то говно-модели. Это пишут те, кто вообще моделировать не умеет. У нас тут проблемы с моделями, там полигоны как-то неправильно ложатся, отражаются, съедаются движком/СДК, просто где-то похерились. Ну вот что сразу рисует воображение? Ну кто-то, видимо, смастерил 3Д-модель на 10К полигонов (это *** по меркам игр даже в нулевые), старался. Детализация — блеск, до микрона рассчитывал. А на выходе моделька как-то побилась, то ли самим Хреем, то ли его СДК. А где модели-то? Где 3Д-модели хотя бы на 100 полигонов?

И текстуры какие-то не такие. Но это пишут те, кто даже одной и в паинте не малевал. Импотенты поговорили о тонкостях секса? Очень смешно.. Потому что ладно если кто-то из вас сделал текстуру, которой завидовал бы сам Шишкин. Заправил ее в Хрей/СДК, а они ее отобразили до блевоты. Вот тут было бы уместно разорение, ибо сколько я мучился, пока ее рисовал. Но вы ведь никаких не рисуете.. Какая тогда вам разница, какой движок, если заправлять туда своего все равно нечего..

Много бессонных ночей вы делали анимацию, все просто супер. А заправили в Хрей/СДК — все ужасно. Сплошное дерево, если вообще не отрыгнул. Так ведь? Поднимите мне веки, покажите мне эти анимации. Я не говорю о новых 3Д-моделях, скелетах и прочей. Не надо, с этим уже все понятно. Вот старая модель/скелет, но движуха уже другая — у меня кабан в носу ковыряется возле костра, вот какую я анимацию сделал. Где она? Лишь убожество Хрея мешает "расправить плечи".. Я понимаю..

Физика.. Нет повести печальнее на свете. Уродовался, но засеял свою карту всякой мелочью. Захожу, а физика не та, не такая она, что в жизни. Пнул стул, а он полетел не так/не туда/не полетел/вылетел в систему. А на деле? Где можно посмотреть на убожество физики? Я скачаю и посмотрю. Рискну предположить — там же, где и на новые 3Д-модели в целом..

Освещение. Оно в Хрее нормальное, кто бы что не говорил (про Сурс не скажу, я его в глаза никогда не видел). Было бы что освещать (дальше см. про модели)..

С визуальной стороной (которая и выводится на экран) все уже понятно. Нечеловеческие усилия, дубовость, и много чего еще. Остается добавить лишь несколько слов о цветовой гамме в кадре. Оставалось бы, если хоть кто-то понимал, что это вообще такое. Ну кто рисует текстуры, те понимают. (дальше см. про текстуры). Аналогично — настройка сцены, освещения, красный-зеленый-синий и многие другие непонятные вещи. Художнику, конечно же, развернуться негде, инструмент не тот.

Ну и код. Кто мешает (или мешал) переписать классы, добавить методы, ну или еще как-то обозначить себя в коде? Конечно же, в совершенстве владеющим программированием мешает только и исключительно дубовость кода. Вот в Сурсе, конечно, все не так. Там есть где поработать. Хрей и рядом не стоял..

Не будем больше, а то оффтоп получается.. К выводу..

Для игроков с Запада Сурс и Халва просто роднее. Привычнее. Там больше 3Д-моделлеров, больше художников, больше программистов. И у них есть хоть какая-то стимулирующая причина тратить свое время. У Сталкера ничего этого нет. Нет даже в штучном количестве ни аниматоров, ни моделлеров, ни художников — ни хрена. Даже простого правильно сделанного скайкуба — и это придется искать. И непонятно, зачем это нужно, что это вообще даст взамен. Помимо этого, своих художников и программистов там берегут, защищают и заступаются. А не гнобят, как не буду перечислять кого в Сталкере. Как следствие, визуальная картинка какой была 10 лет назад, такой она и будет. Как бы вы не мучились с кодом, "графоном", шейдерами и так далее. С другой стороны, собственно, художник и должен быть основным заказчиком ваших "движковых правок". Это ему нужно, потому что сцену он сделать-то сможет (смоделировать и затекстурить чем-нибудь, что не в СДК делается, если что), но ее еще нужно будет как-то запускать. Вот для этого и нужен движок, который будет оперировать ассетами. И который может быть необязательно Хреем, кстати.

И тут ты такой вываливаешь свои работы, которым позавидуют все присутствующие. Или балабольщик?

Как будто статью из газеты 1993 года прочёл.


Что ты такое, Chrizantema???

Chrizantema, соглашусь по большинству пунктов, но...



...с этого улыбнулся.

Кстати да, моддинг на Half-Life - это продолжение моддинга на Quake. Так что народ уже знал, что такое GldSrc и с чем есть этот движок. + полноценный SDK вышел вместе с игрой.

Плюс HL проще в плане гейм-дизайна и структуры кода. Там без исходников движка моддеры пилили такое, что сейчас на XRAY не всегда могут с исходниками.

Да практически все неправильное выражение: большая часть игровые движки потомки кваки. Это не новость.

Не вижу анрил энджина. Ах да, он же не долбится в бсп, кому такое нужно.

Ого так у нас ещё и анрил подключился в дискуссию? Ты мне лучше скажи, искрей был на чём-то базирован или с нуля писался?
PS:поправил пост выше

Просто скомпилировали библию диявола.

ZazziCenko, кто с нуля пишет движки? Возможно только у н-видиа и майкрософта есть что то глобально-новое, остальные базируются уже на готовых библиотеках.

Он ещё 1998 году, или раньше начал писаться, или в 98 уже что-то было рабочие?. Хотя квака на него повлияла. Кстати, старое название XRay "белая рысь". А реально, XRay на чем то базировался?, да не, скорей всего с нуля писался, тогда современные движки были закрыта насколько я знаю.

А при чем тут анрил, да у него тоже в основе BSP, вот только bsp это просто алгоритм, так вот в анриле он знатно модифицирован и сделан с нуля, просто другая реализация. Аналогично ECS, это просто алгоритм который каждый реализовывает так как хочет и со своими оптимизациями\улучшалками.
Goldsrc\source это прямой наследник реализации BSP кваки\дума.
Анрил просто реализованный с нуля алгоритм BSP уже со своими фичами. Вот и вся разница.


Есть мнение что в основе какраз был квейк. Вот только почти весь код использовался только как основа или заглушка который переписывался с нуля под требования. Что в общем то обычная практика до сих пор, если есть что сложное то взять готовое, дальше из за лиц. политики переписать его собственной реализацией под требования.

Это не название иксрея, это такая небольшая компания была.


Во времена ДОСа движки писали с нуля, без всяких директисков и опенглов. И в GSC люди имевшие такой опыт работали, но не над иксреем.


Если даже на чем-то и базировался, это что-то уже давно кануло в лету.

Modera, Движок тоже тогда так назывался "белая рысь"("white lynx"). А в билде 749 использовал много контента из квейка.
ЗЫ
Я вот тут всё хочу спросить, как там Метро на счёт модинга, или всё убого, т.к. всё в движок зашито.

NanoBot-AMK, самый оптимальный вариант модинга для бывших сталкачей - это CE2 с игровым кодом. Желательно сразу искать команду, так как одному скучно.

Метро - неизведанная земля на счёт моддинга. Документации нет, инструментов нет, всё возможности движка неизвестны.
Преимущества перед иксреем есть, например возможность редактировать уровень без перекомпиляции или отражения.
Недостатки тоже есть, метро это рельсовая игра, движок под неё заточен, понятно каких фишек сталкера там не хватает.

Но это только 2033. Кто знает что там в ластлайте или редаксе, может там даже есть рабочий мултиплеер который просто ещё никто не запустил. А ещё скоро exodus выходит.
В общем, если любишь изучать чужие программы без исходников, то там точно есть на что взглянуть.

Да, давай не будем тут оффтопить и пойдём в другую тему.