Сообщений в теме: 591

[listener]

XEPOMAHT007

Здесь речь идет не о RAGE 2.0, а, скорее 3.0, как бы не все 4.0

IV был далеко не первой игрой на RAGE. До него были LCS/VCS и TableTennis.
Их можно рассматривать как первые эксперименты, в которых обкатывались базовые идеи. В Stories обкатывался стриминг и новые форматы карты, в TableTennis появился .rpf и memory manager

С выходом IV, окончательно зафиксировались форматы моделей. grcTexture, grcIndexBuffer, grcVertexBuffer и т.д. используются во всех последующих играх практически без изменений (даже добавление поддержки DX11 серьезно изменило только grcShaderEffect).
grmModel, rmcDrawable, phBound, crAnimation также менялись крайне незначительно - добавлялись новые примитивы к коллизиям, типа кодирования анимации и прочие небольшие мелочи. в fragType добавилась поддержка одежды. Так что, ничего революционного не было.

Что менялось радикально, так это форматы карты. Если IV и MP3 используют формат GTA III, без концептуальных изменений (формат - в первую очередь, не формат хранения, а подход: "координаты объектов -> коллизии -> модели") ), то карты MC:LA являются развитием того, что появилось в LCS/VCS (заранее подготовленные сектора, со всеми фиксированными моделями). В RDR используется комбинированный подход.
Впрочем, карты тоже разобраны, так что это не должно стать проблемой.

SILENT_Pavel
Зачем? Чтобы было. Есть и сейчас народ, который делает моды на VC. Но это не отменяет того, что все хотят добавить к названию мода слово RAGE :-)

Я предполагаю, что большую часть контента просто так выдернуть не удастся. Лошади - это как раз показательный пример: RAGE в IV не поддерживает quadraped-ов, так что нормально перенести не удастся. Максимум - можно попробовать смапить на biped-а, и отключить поддержку euphoria.

Что я ожидаю увидеть в новых форматах, так это 64-битные fixup-ы. Есть также вероятность, что atArray/pgArray/atHashtable переведут на 32-битыне индексы.

[XEPOMAHT007]

то карты MC:LA являются развитием того, что появилось в LCS/VCS (заранее подготовленные сектора, со всеми фиксированными моделями).

Если именно эта "продвинутая" консольная система карты будет использоваться в GTAV, то моддинг подобной штуки будет очень осложнён следующими факторами:

1. Карта коллизий и карта отображаемых игровых моделей - 2 совершенно разные и независимые друг от друга карты. Простой маппинг будет не возможен, как и редактор типа MEd'а. ГТА4 спасло то, что там есть формат коллизий, привязанных к моделям, который отлично подходит для конверсий из старых гта (но я чего-то не видел, чтобы моддеры его активно юзали в олдскул конвертациях).

2. Имён моделей и текстур не будет совсем. Вместо них хэши (в ЛСС например получилось восстановить 97% имён, если в гта5 будут использоваться какие-нибудь абырвалги, то их имена восстановить будет сложно) или идентификаторы ресурсов, уникальные только в рамках одного IMG-архива (а если таких архивов будет штук 50, то у многих может сложиться путаница).

3. Отдельных моделей и текстурных архивов не будет - все ресурсы будут храниться в одном файле типа *.wrld и, соответственно, так и подгружаться из архива. При этом такой ресурс будет содержать всю видимую игроком часть игрового мира, находящегося в определённом квадрате. Соответственно, чтобы отредактировать подобную вещь, нужно будет работать с целым куском карты, а не просто с 1-й моделью.

4. Следует из п.3, а именно, чтобы добавить на карту какой-нибудь объект, придётся загружать и добавлять этот объект на большое количество секторов карты, из которых он должен быть виден игроку. Ну а если это ЛОД - тогда придётся добавлять его в почти все сектора (или 1 раз добавить в общий кэш типа *.lvz, если повезёт). То же самое с текстурами.

5. Для того, чтобы например заменить текстуру, придётся вычислять координаты сектора, в котором сидит фейс, несущий данную текстуру, а потом по координатам находить сектор, в нём находить идентификатор текстуры и программно прочёсывать весь IMG-архив для поиска всех дубликатов. Естественно, если текстура не будет найдена в IMG, то её нужно искать в кэше ресурсов, при чём визуально. Естественно, если подгрузить в 3Д Макс кусок карты с выбранной текстурой, то её можно очень быстро найти.

6. Большой размер модов на карту и их не совместимость, т.к. придётся выкладывать именно модифицированные куски карты, а не только голые модели с текстурами.

7. Монстр, содержащий все главные dat-ресурсы в бинарном виде, GTAGAME - основные грабли моддинга. Особенно когда под него выделяется определённое количество оперативы.

Весь этот вышеперечисленный "консольный кошмар гта-моддера" присутствует в сториесах, если он повториться в ГТА5, то весь некс-ген-моддинг окончательно прекратиться (народ продолжит моддить старика Саныча). Я думаю, что ГТА5 всё-таки сделают мультиплатформенной, поэтому такой шняги там не должно предвидится. LCS и VCS в этом отношении тупиковая ветвь эволюции платформы, возникшая на фоне тонны ограничений консоли PSP по эмуляции игры с открытым миром от консольных извращенцев.

[listener]

XEPOMAHT007
Замечательно! Я осознал, что моддинг stories, действительно ужасен.
Межет быть, стоит рассказать, как это устроено в свежих версиях RAGE ?

[XEPOMAHT007]

Межет быть, стоит рассказать, как это устроено в свежих версиях RAGE ?

Расскажи, думаю многим будет интересно. Лично я кроме ПС-версии GTA4 с RAGE-м больше нигде не сталкивался.

Можно даже тему "про это" создать, чтобы не флудить в теме Опена4.

Сообщение отредактировал XEPOMAHT007: 07 May 2013 - 14:51

[listener]

Я думаю, что начать лучше здесь. А если получится что-то большое - вынести и потом можно.

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

(здесь должна быть какая-нибудь подходящая цитата из Сун-Цзы, но на память не вспоминается, а специально копаться - влом)

В чем состоит отличие open world игр от "традиционных"? Почему 32+4MB памяти было достаточно для 36 km^2 SanAndreas, а 2-3km^2 FarCry или Batman:AC еле-еле влезают в возможности current-gen? Как в R* собиратся уложить 200 km^2 в текущие возможности?

Ответ прост и очевиден: требуется отказаться от загрузки всего игрового пространства и работать только с его видимой частью. У этого "простого" решения есть ма-аленький побочный эффект: традиционный подход к геймдеву оказывается неприменимым.

Графика, из основы основ, внезапно становится наименеее приоритетной вещью. Куда-то туда же смещается и физика, а на первое место выходит asset management. Это хорошо видно на примере любой RAGE-based игры, где стриминг+memory manager занимают больше кода, чем графика и физика вместе взятые и потребляют гораздо больше CPU.

Мало добиться того, чтобы была доступна та часть мира, где находится игрок. Требуется еще и обеспечить, чтобы та часть, куда он намерен переместиться - тоже была доступна. Для этого применяется механизм предсказаний, который патается заранее подгрузить сопряженные зоны в зависимости от положения игрока внутри текущей зоны, вектора его скорости и установленного бюджета на память и модели. Чтобы окончательно усугубить ситуацию, нужно отметить, что требуется еще и выдерживать порядок загрузки: сначала карта, потом коллизии и только после - модели (сначала low-detail, потом high-detail, потом - текстуры к ним). Этот порядок очень важен: лучше упереться в непрогруженныую модель, чем оказаться в ситуации, когда col-model здания возникает вокруг игрока.

К сожалению, тот механизм, что используется в GTA, был разработан, исходя из возможностей PS2 и, в современном мире справляется плохо. При больших скоростях перемещения, даже топовый PC не справляется с загрузкой большого количества разнородных ресурсов (временами, это хорошо видно). Решается эта проблема очень просто: все статические объекты сектора собираются в один или два ресурса, обрабатываемых атомарно. Эффект такой оптимизпации можно легко увидеть в MC:LA, где можно перемещаться по городу на скоростях порядка 300 km/h, без какой-либо видимой подгрузки ресурсов (даже если они подгружаются с медленного DVD).

(Доберусь до работы - попробую продолжить)

[Lego]

Интересно. А есть какая-нибудь инфа (статья) про такую концепцию asset management'а?

Можно даже тему "про это" создать, чтобы не флудить в теме Опена4.

+1

Сообщение отредактировал Lego: 08 May 2013 - 05:56

[listener]

С отдельной темой - я надеюсь, что какие-то части из того, что я пишу, войдут в roadmap по OpenV.
Опять же, как показывает практика - продуктивнее что-то описать в общей теме и потом перенести полезные куски, чем создавать отдельную и пытаться в нее что-нибудь вымучить

Увы. Если бы про такое были статьи или книжки, то, на фоне общей популярности open-world-ов, их не использовал бы только ленивый.

Накопанные концепции, до этого, выкладывались в закрытые разделы. Пост, с которого пошло активное ковыряние ресурсов, датирован сентябрем 2008г. Отчасти, это объясняет, почему ничего не получилось из SparkIV - как только aru отстранился от проекта, просто не нашлось людей, которые понимали бы концепцию ресурсов.

Концептуальный барьер заключается именно в понимании подхода: почему RSC устроен так? для чего он устроен так? как их читать и писать с минимальными накладными расходами? Если есть ответы на эти вопросы - нет никакой разницы в работе с .xtx (отдельная текстура, даже не texture dictionary), .wft или .xcs (city sector в MC:LA) - все упирается только в описание внутренних объектов (в среднем, порядка 50 объектов). (Мы же джедаи - для нас размер не имеет значения)

(Я, изо всех сил, стараюсь сдерживать внутреннего тролля, но в этот раз удержаться - выше моих сил. Чуть выше говорилось о прискобной судьбе моддеров stories. По моим наблюдениям, .lvz по сложности не превышает .wft. Если бы кто-то (не будем тыкать пальцем) не занимался пропагандой традиционных татаро-монгольских ценностей, а потрудился расписать структуры, то проблем с .dtz/.lvz не было бы никаких. Вообще.)

Прежде, чем вернуться к ресурсам, стоит остановиться на внутреннем устройстве карты в GTA.
Есть центральная точка карты (начало координат). Вокруг нее строится три QuadTree, описывающих размещение объектов.
Программно, это три объекта: CIplStore, CPhysicsStore и CBoundsStore. Первый, как следует из названия, связывает игровое пространство с секторами карты, второй - с col-modelями статических объектов и третий - с col-modelями динамических объектов. Задача этих классов - анализ положения и скорости игрока в пространстве и выдача запросов к стримингу на соответствующие ресурсы, которые требуются сейчас или могут потребоваться в ближайшем будущем. По мере загрузки секторов карты, определяется, какие модели на ней находятся и выдаются запросы на загрузку этих моделей.
(динамически создаваемыми объектами занимается скриптинг и CPopulation)

Такая система была сделана для GTA III, немного переделана для VC и, осталась с минимальными изменениями в SA, IV и MP3. Очевидный недостаток ее в том, что одна операция загрузки сектора приводит к нескольким десяткам (если не сотням) запросов на подгрузку отдельних ресурсов.

При использовании RW, это было не так критично: накладные расходы на пост-обработку загруженной модели были достаточно высоки, и, за это время, успевал загрузиться следующий ресурс. С новой системой ресурсов все радикально изменилось. Накладные расходы на чтение RSC достаточно малы на PC и ничтожны на 360-ке (за счет того, что не требуется копировать ресурсы в видеопамять). Для них не требуется больших непрерывных кусков памяти. За счет этого, укрупнение ресурсов резко уменьшает накладные расходы. (я не думаю, что нужно объяснять разницу между одним объектом с целым сектором карты и несколькими сотнями отдельных моделей, коллизий и текстур).

Отдельно, стоит отметить процесс сборки таких ресурсов. Он получается, опять же, проще, чем представялется.
Здесь в дело вступает memory-manager. Он устроен так, что на любой ресурсный объект, вне зависимости от сложности этого объекта, можно вызвать метод дефрагментации и получить после этого готовый ресурс. При этом, в процессе сборки объекта, отдельные его части можно импортировать из чего-то, сильно напоминающего openFormats. Повторюсь: сложность экспорта ресурса не зависит от того, собираем ли мы отдельную текстуру или целый city sector.

(надо немного поработать, а потом можно и продолжить)

[listener]

Продолжим.
В следующей части возможны ашипки. Я потом перепроверю, но это будет, не раньше, чем я приду с работы и доберусь до ресурсов.

Одна из проблема GTA была в том, что все содержимое .ide и .ipl загружалось на старте.
Следствием такого подхода было то, что загрузка получалась достаточно долгой (за счет разбора текстовых файлов) и загруженное оставалось в памяти до выхода из игры.

Если с первой проблемой как-то пытались бороться (использовать precompiled .ide в Bully и .ipl => .wpl в IV), то вторая проблема, в общем случае, не решалась. Подход был прост и прямолинеен: если есть статическая модель, используемая в одном и только в одном месте - для чего ей собственное имя и отдельный описатель? Предельный случай такого подхода, мы видим в MC:LA, где на весь город существует единая collision model, а статические объекты интегрированы по максимуму в city sectors. Поскольку перемещаться по этому городу можно только на транспорте, не требуется большой детализации col-modelи, что позволяет удержать ее размер в рамках разумного.

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

Маленькое лирическое отступление. Я люблю работать из командной строки. Двадцать пять лет практики, позволяют выполнять самые разные операции быстро (намного быстрее, чем это можно сделать из GUI). Более того, скорость работы в связке командная строка+FAR несравнима с тем что может предоставить GUI.
В этом стиле, я люблю писать небольшие вещи, компилировать их (при необходимости) из командной=же строки и тут же запускать. Трудно сравнивать по затратам создание проекта в MSVC и нажатие Shift+F4, даже если потом, вместо F5 придется набирать cl -MD -Ox somefile.cpp
При этом, я прекрасно осознаю, что если проект превысил ~1000 строк или десять файлов - затраты на создание проекта в VS вполне окупятся и, с ростом проекта окупятся многократно.

На этом, с лирическим отступлением покончено и пора переходить к лирическому наступлению. Изначально, OpenIV (если я ничего не путаю), делался, как менеджер игровых архивов. потом к нему добавлялось все больше и больше просмотрщиков и конвертеров ресурсов. Может быть хватит кипятить пора сделать следующий концептуальный шаг и превратить его в полноценную IDE? Это позволило бы избежать проблем с комплексными ресурсами: если такой ресурс оформлять как проект, состоящий из отдельных моделей - размер ресурсов перестанет быть проблемой. Кроме того, можно было бы заодно сделать проекты, выдающие на выходе OIV и еще больше упростить жизнь и процесс моддинга.

(финальная часть про карту RDR будет после того, как я доберусь до дома)

[listener]

Итак, мы дошли до самого интересного - до RDR.
Мне трудно сейчас даже предположить, сколько из RDR войдет в V, потому что он совсем другой.
"Совсем" - означает, что RDR отличается от IV больше, чем GTA III отличался от GTA2

Я предполагаю, что при написании RDR одной из задач была чистка исторического мусора. Как следствие - там нет CEntity. Вообще.
И всего, что от него унаследовано - тоже нет. Нет CPed, нет CObject и CVehicle - тоже нет. вместо этого, есть понятие actor, который, в зависимсоит от назначенных обработчиков, может быть человеком, животным или транспортным средством. Как следствие - все, что связано с actor-ами ни капли не похоже на то, что было раньше.

Но это касается только игровой логики. Принципы работы с картой остались те же: точно также у нас есть игровое пространство, точно также оно поделено на сектора... Разве что формат был сильно почищен.

Внимание! часть информации не проверна. Возможны ошибки
Роль .ipl занял .xsi. (sagSectorInfo) В нем описывается регион (от отдельного интерьера, до всей карты). Основное отличие в том, что .ipl не перекрывались, а .xsi накрывает сектор, при этом описания сабсекторов могут выноситься в отдельные файлы (в которых, в свою очередь, могут быть сабсектора), а могут находиться в том же ресурсе. Корневым ресурсом является swAll.xsi, покрывающий всю карту. Он (в той версии, что у меня есть) делится на 106 зон (в других - это число может несколько отличаться, потому что часть зон зарезервирована для DLC). При этом, сабсектора тоже могут перекрываться (главное, что они не могут выходить за границы сектора-родителя).

Предположительно, это делатеся для того, чтобы можно было описывать какие-то блоки на несколько сабсекторв сразу, без промежуточного деления на куски (например, сабсектор с говорящим именем swTerrain.xsi накрывает всю территорию в swAll).

Основное отличие от .ipl - то, что внутри .xsi могут находиться модели и коллизии (для чего это нужно - я скажу, как найду сектора, в которых они есть). В остальном, можно это просто считать новой версией .ipl (и не забывать, что при измении границы зоны, требуется поправить и сектора-родители)

terrain и статические объекты собраны в VolumeData - очень простой объект, который, фактически, представляет собой связку из xdd и xtd.
Разные LOD-ы выносятся в отдельные .xvd. Растительность вынесена в отдельные ресурсы .xsg, в которые я еще не смотрел.

Динамические объекты используют .xft и .xfd, незначительно отличающиеся от тех что используются в MP3


Подводя итоги, можно сказать, что никаких проблем с ресурсами не ожидается, даже если R* полностью перейдут к идеологии, используемой в RDR.
Да, по первости будут большие проблемы со скриптингом, т.к. поменялся принципиальный подход к игровым объектам, но это тоже решаемая задача.

Спасибо за внимание, можно задавать вопросы.

[Chipsman]

картинки




пс: там довольно специфические шейдеры, и поэтому на моих оно что-то рендерит зеленым а что-то желтым)

[XEPOMAHT007]

Подводя итоги, можно сказать, что никаких проблем с ресурсами не ожидается, даже если R* полностью перейдут к идеологии, используемой в RDR.

Ну рокстары всё-таки могут что-нибудь этакое отчудить в ГТА5, не будем гадать. Надеюсь, что извращения из сториесов так и останутся эксклюзивом для сториесов, а опыт оптимизации форматов для открытых миров по типу RDR повлияет на GTAV в лучшую сторону. Как и в случае с GTA SA, Рокстары постараются выжать все соки из PS3, но и поддержку текстовых ipl, ide и остального старья они могут оставить в движке (как и в случае со сториесами, возможно и с GTA4, бета-версия игры использовала штатные для GTA ресурсы, остатки которых можно встреть в GTA3PSP/PS2.IMG архивах, соответственно которые легко можно правиться разработчиками для устранения ошибок при тестировании, и которые после завершения тестов были собраны в то, что мы сейчас и имеем), но и защиту от пиратов и читеров, которая тоже мешает при моддинге, тоже могут сделать похлеще, чем в GTA4 (например в что-нибудь в стиле EA Games).

Кстати, Рокстары где-то обещали, что в GTA5 будет юзаться полноценная система DLC, а не та хрень с эпизодами, позаимствованная наверное у психо-моддеров, когда в одну папку собрали все изменённые файлы и просто переписали к ним пути из оригинальной игры. Посмотрим, что это может быть - мультиплейерные карты (почему бы и нет для GTA, ведь в GTA3 они были, хотя сами карты Рокстары слили только через 10 лет), новые автомобили (по типу давно забытых NFS), оружие, мелкие скриптовые добавки, разная мелочёвка типа новых апартаментов для глав.героев и т.д. всё, на чём можно срубить дополнительную денежку от фанатов игры. Если подобные симс-фенечки будут реализованы Рокстарами, тогда откроется большая дорога для подобных фанатских дополнений, что намного облегчит моддинг и распространение модов (лично у меня нет на компе ни одного мода для GTA4 - давно ещё ставил 1, добавляющий большой остров, игра не поняла это и вылетела при попытке подлёта к добавленной локации, после этого с модами на гта4 не связываюсь, тем более с такими монстрами как GTAIV:SA, которые требуют определённую версию EXE).

[НикИТОС]

Если подобные симс-фенечки будут реализованы Рокстарами, тогда откроется большая дорога для подобных фанатских дополнений

Не знаю, конечно, насколько в Rockstar Games и Take-Two Interactive любят деньги, но вполне возможно, что при создании Grand Theft Auto V разработчики будут защищать ресурсы, как только смогут, чтобы брать деньги за игровые пушки и автомобили, вместо того, чтобы давать хоть какую-то возможность модифицировать игру.

И ещё у меня имеется вопрос насчёт OpenIV: почему хранение ключа шифрования в самой программе невозможно, а извлечение его из исполняемого файла игры имеет место быть? Или ключ шифрования — это тоже объект авторского права?

Сообщение отредактировал НикИТОС: 10 May 2013 - 11:03

[GooD-NTS]

[НикИТОС]

Формат звуков Red Dead Redemption тот же, что и в Max Payne 3?

[GooD-NTS]

Формат звуков Red Dead Redemption тот же, что и в Max Payne 3?

Да, формат такой же. Аудио кодек отличается, в смысле в xbox версиях используется не такой как на ПК.

И ещё у меня имеется вопрос насчёт OpenIV: почему хранение ключа шифрования в самой программе невозможно, а извлечение его из исполняемого файла игры имеет место быть? Или ключ шифрования — это тоже объект авторского права?

Потому что распространение чужого ключа подпадает под ряд законов и ограничений, и программу со встроенными ключами легко можно было бы удалить с сайтов по запросу (если бы им это понадобилось). А вот читать ключ из их файла который они сами положили никто вроде не запрещает, да это и не создаёт дополнительных трудностей.

Не знаю, конечно, насколько в Rockstar Games и Take-Two Interactive любят деньги

Rockstar Games и Take-Two Interactive это коммерческие организации и целью их существования является зарабатывание денег. Так что да наверное они их любят

но и защиту от пиратов и читеров, которая тоже мешает при моддинге, тоже могут сделать похлеще, чем в GTA4 (например в что-нибудь в стиле EA Games).

, но вполне возможно, что при создании Grand Theft Auto V разработчики будут защищать ресурсы, как только смогут, чтобы брать деньги за игровые пушки и автомобили, вместо того, чтобы давать хоть какую-то возможность модифицировать игру.

Например в Max Payne 3 используется IronWrapper, самая крутая защита. Но модифицировать игру это никак не мешает. Полностью защищены файлы только от DLC, чтобы ими бесплатно не пользовались те кто не заплатил. Думаю что в GTA V они поступят также, потому что не могу защитить враперовм вообще весь контент, это очень сильно повлияет на производительность.

но и поддержку текстовых ipl, ide и остального старья они могут оставить в движке (как и в случае со сториесами, возможно и с GTA4, бета-версия игры использовала штатные для GTA ресурсы, остатки которых можно встреть в GTA3PSP/PS2.IMG архивах, соответственно которые легко можно правиться разработчиками для устранения ошибок при тестировании, и которые после завершения тестов были собраны в то, что мы сейчас и имеем)

Если GTAV таки будет RDR то ни о кокой поддержки старых ipl/ide можно просто не мечтать, потому что они её не могут оставить, её там просто никогда не было.

[GooD-NTS]

Улучшенный поиск расположения - OpenIV 1.5
Список изменений:
- Обновленный интерфейс
- Тип поиска: По имени ИЛИ По хэшу
- Быстрый поиск из буфера обмена
- Информация о файлах

[GooD-NTS]

[GooD-NTS]

Как импортировать анимации GTAIV в 3Ds Max

openFormats I/O: http://gtamaps.net/f...showtopic=14691

[GooD-NTS]

Improved animation viewer

[GooD-NTS]

Мы только что пофиксили косяк с текстурами в Max Payne 3: