OpenGothic - опенсорсная реализация движка Готики2

[Try]

OpenGothic​

О пакете Описание Технологии Совместимость Командная строка

• 
  Ресурсы портала: World of Gothic.ru
  Страна разработчика: Норвегия
  Платформа игры: Кроссплатформенный (Gothic I Classic, Gothic I Sequel, Gothic II Classic, Gothic II NoTR)
  Тип обновления: github-release
  Рабочее название: OpenGothic
  Версия пакета: 1.0.1878
  Язык: Независимо от языка
  Вес: 108 МБ
  Статус: Бета (тестирование)
  Дата релиза: 16.07.2019, 22.01.2023
  Дата обновления: 04.10.2020
  Авторы: Try
  
  
  Последний год понемногу после работы пилю свой собственный ремейк оригинальной Готики.
  Пакет работает по принципу замены оригинального *.exe-файла, движок считывает оригинальные текстуры, модели, скрипты из папки игры.
  
  
  
• 
  Основной игровой процесс завершен, вы можете завершить первую главу за любую гильдию, а также пройти весь контент дополнения.
  
  Что уже работает:
  • Квесты
  • Диалоги
  • Ближний бой
  • Лук
  • Интерактивные объекты(наковальня, рунный стол и т.п.)
  • Инвентарь
  • Прокачка(кроме взлома)
  
  Скриншоты:
  
  
  
  
  
  
  
  Еще скриншоты: Try/OpenGothic
  
  
  
• 
  Используемые технологии:
  Vulkan - графика
  OpenAL(модифицированный) и tsf- звук
  Bullet - физика
  ZenLib - чтение ассетов оригинала
  
  
  
• 
  Совместимость с пакетами расширений скриптов, движка:
  • Поскольку реализация полностью самостоятельная, совместимости с плагинами, сделанными с использованием SP/Union/AST/Lego/Ikarus/G2EXT - нет и быть не может.
  • Не ожидайте, что мод DirectX11 будет работать, так как технически это не мод. Но графика из коробки уже подтянута до современного уровня.
  
  Совместимость с модами:
  Изначально планируется полная совместимость с "обычными" модами(скрипты + контент).
  • Модификации поставляемые в виде *.mod-файлов и созданые стандартными средствами ГМДК1 и/или ГМДК2 должны работать без проблем, так как они содержат только игровой контент и скрипты.
  • Модификации созданные с помощью UNION/AST-SDK или любых других скриптовых и движковых расширителей НЕ будут работать, так как оригинальные движки Gothic НЕ совместимы с движком OpenGothic в двоичном формате.
  
  Список поддерживаемых функций дедала в вики проекта: Try/OpenGothic
  
  
  
• 
  Аргументы командной строки:
  

  -g - указать каталог игры Готика
  -nomenu - пропустить главное меню
  -w <worldname.zen> - загрузка мира; newworld.zen по-умолчанию
  -save <q> - запуск с быстрого сохранения
  -window - оконный режим
  -rambo - уменьшает урон игрока до 1hp
  -v -validation - включить режим проверки Vulkan

  
  
  

Ссылки:
Github: Try/OpenGothic
Ссылка на стабильный бетта-билд: Try/OpenGothic
Ссылка на nightly билд: AppVeyor

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

Запуск:
cmd> Gothic2Notr.exe -g "C:\Program Files (x86)\Path\To\Gothic II"
Для правильной работы на Windows, может, понадобится установить Vulkan-runtime: LunarXchange

Интересно узнать мнение о проекте, работает/не работает; если не работает - просьба прикладывать файл crash.log

 

[KirTheSeeker]

Помимо этого, в идеале, хочется еще сделать совместимость с irkarus/lego/union, чтобы моды могли работать

Это был бы прорыв, на мой взгляд.

 

[IdeaGen]

KirTheSeeker, да и без этого был бы уже прорыв.

 

[Gratt]

Помимо этого, в идеале, хочется еще сделать совместимость с irkarus/lego/union, чтобы моды могли работать

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

 

[Try]

C Union главная проблема, это пожалуй то что на входе будет *.dll, с нативным кодом и как ему навернуть песочницу, да так чтобы и под Liunx, и под MacOS, и под x64 абсолютно непонятно.
С Ikarus/LeGo ситуация тоже сложная, но не фатально. У них есть "замечательные", основанные на баге движка оригинала, функции:

MEM_ReadInt, 
MEM_WriteInt
CALL__thiscall

с помощью которых креативщики ковыряют память процесса, подменяют функции/методы, дергаю api Windows и так далее.

С моей стороны есть 2 варианта:
1. родить им 32х битную песочницу, со своей виртуальной памятью и маппингами (не хочу)
2. заложится на то, что модеры не пользуются WinApi и прочим, ограничиваясь только готовыми Daedalus функциями. Список функций: OpenGothic compatibility initiative · Issue #29 · Lehona/LeGo

 

[Goth_Man]

и как ему навернуть песочницу, да так чтобы и под Liunx, и под MacOS, и под x64 абсолютно непонятно

А пилить поддержку (хотя бы частично) со стороны Union нельзя?

 

[MaGoth]

А пилить поддержку (хотя бы частично) со стороны Union нельзя?

это не имеет смысла, движки же разные..

 

[Try]

А пилить поддержку (хотя бы частично) со стороны Union нельзя?

это не имеет смысла, движки же разные..

Интересно, насколько много модов пользуются C++ плагинами на Union? И если пользуются, то в каком виде.
Интересуюсь потому, что тут фактически 2 проблемы:
1. Запускать *.dll через подобие VM это технически очень сложно
1.*. Запускать *.dll как есть получится только на win32, и то с оговорками
2. Допустим не *.dll, а pyhon/daedalus скрипт - в таком случае нужно как-то эмулировать структуру классов оригинальной Готики

 

[N1kX]

Новый Баланс требует полностью Union - потому что все функции написаны через него, также там расширены (унаследованы) ориг классы и пр.
Неофобновление требует Union для плагинов, но он не обязателен - эти же плагины можно поставить в любой другой мод.
Будущие 2 польских мода - История Хориниса и Хроники Миртаны тоже будут требовать Union
Как-то так. Пока что 4 мода (3 мода)

 

[MaGoth]

Интересно, насколько много модов пользуются C++ плагинами на Union? И если пользуются, то в каком виде.

Ну, Никс выше правильно написал, многие моды пользуют Юнион как платформу исправления багов оригинала и/или в виде юзания плагинов и тд и тп..
Модов использующих Юню по полной, очень мало, основная проблема это заставить поляков и немцев пересесть на него.. у первых подвижки есть в этом моды Хроники и История(оба в разработке).. с немцами сложнее, но думаю перелезут, хоть и нехотя и скрипя всем чем можно.. как выйдут первые полноценно толковые моды на Юне..
кстати, Оутфейс тоже полностью на Юне пилится, так-что формально уже 5/4 модов..

Интересуюсь потому, что тут фактически 2 проблемы:
1. Запускать *.dll через подобие VM это технически очень сложно
1.*. Запускать *.dll как есть получится только на win32, и то с оговорками
2. Допустим не *.dll, а pyhon/daedalus скрипт - в таком случае нужно как-то эмулировать структуру классов оригинальной Готики

честно говоря хз, как тут может быть..
тут опять же две проблемы и два разных двига..
и должно быть два взаимных пересечения между этими проектами, Юня должен поддерживать твой двиг, а Твой двиг должен поддерживать все форматы и полноценную работу модов на том же уровне реализации как это делает ЗенГин..
я только такой способ подружить их вижу, но даже это будет очень сложно, кмк...
но здесь тебе Gratt, а пинать надо по вопросам взаимных причесонов..

 

[Gratt]

но здесь тебе @Gratt,а пинать надо по вопросам взаимных причесонов..

Если ты нас с Try посадишь на зарплату 10 инженеров Apple, тогда можно написать виртуальную машину. А так это все бред, проще переписать логику плагина под другой движок, чем пытаться адаптировать неадаптируемое (ГитХаб как сказки на ночь). Расширители в первую очередь юзают именно адресное обращение к конкретным структурам данных. Куда оно будет обращаться в новом движке?? Я бы еще понял, будь это декомпиляция, как GEngine. Он хотя бы структурно схож с зенгином.

 

[MaGoth]

Если ты нас с @Try посадишь на зарплату 10 инженеров Apple, тогда можно написать виртуальную машину.

гы, кто бы меня на нее посадил, не там ищешь..

а то что их маловероятно подружить это и так понятно было, но вдруг..

 

[Try]

А так это все бред, проще переписать логику плагина под другой движок

Ну, нет - не совсем. Проблема в том, что разработчики модов не захотят поддерживать обе платформы одновременно, им проще буде наклеить табличку "Работает только под <подставьте движок>".

Расширители в первую очередь юзают именно адресное обращение к конкретным структурам данных

Если они так делают, значит у них нет ничего другого
Идеальный для меня вариант, это если будет высокоуровневый api с ::get / ::set, вместо ковыряния памяти. И без нативного кода, разумеется.
Не знаю: поздно ли уже менять направление проекта. Если пока, есть только 5 модов, то наверное можно.

План Б:
Могу чисто на своей стороне взять что-то типо GitHub - wfeldt/libx86emu: x86 emulation library и разруливать адреса через перепись mmu... - но это та еще жесть.
Ну и производительность тоже пойдет лесом, если эмулировать инструкции процессора.

 

[Gratt]

Идеальный для меня вариант, это если будет высокоуровневый api с ::get / ::set, вместо ковыряния памяти. И без нативного кода, разумеется.
Не знаю: поздно ли уже менять направление проекта. Если пока, есть только 5 модов, то наверное можно.

Дело не в проектах, которые интегрируют Union, а в проектах, которые пользователи ставят по желанию на любой любой угодный им движок или мод. Интеграция тут дело десятое.
Я лично слабо представляю реализацию высокоуровневого интерфейса над ЗенГином, при этом учитывая все его возможности. Текущий АПИ движка, который используется в Union, был выведен программно. Функции, виртуальная таблица, поля и тд были полностью сгенерированы, кроме классов-контейнеров и половины математики. Все АПИ просто физически не охватить здоровому человеку. Да, мы сможем собрать какой-то интерфейс с базовыми функциями, но как только дело дойдет до нюансов (а оно дойдет), придется так или иначе спускаться на более низкий уровень в связи со слишком большой разницы в архитектурах. Ой не знаю...

 

[Gratt]

В общем мой единственный вариант с которым я ещё могу помочь. Нужно реализовать высокоуровневый интерфейс со всеми функциям, которые применимы в обоих версиях движков. А если есть какие-то глобальные отличия, то ну просто спускаться до оригинальных апи (или мб сразу писать альтернативные им функции). Не вижу в этом ничего критического.
То есть основной код это сплошные Фэктори гет сет и тд, а вторичный соответственно уже и хуки, и патчи, и того самого.
А эта вот эмуляция один фиг не гарантирует правильного выполнения процедуры. Была бы это длл имеющая очевидные входы выходы, то ок. А тут 600 структур и в десятки раз больше методов. Вызвать их хаотично в рантайме требует 100% реально исполнения программы.

 

[KirTheSeeker]

В общем мой единственный вариант с которым я ещё могу помочь...

То чувство, когда не будучи кодером от слова совсем, рад читать первое предложение, а потом идёт "что-то на мунспике".

 

[Try]

Прошелся кратко по существующим плагинам.
Фиксы:

1. SpellFx
2. SavesBackupper (?)
3. zAsyncSaveLoad
4. zBugFixes
5. zVfxCollideFix

Фичи:

1. AlterDamage
2. QuickLoot
3. zTorchControl
4. zMarkItems
5. zHumansRemaster
6. zDanglingWeapons
7. zTrollStoneThrowing
8. zSharedItems
9. zSaveZone
10. zInventoryShell
11. zNoFriendlyFire
12. zWispTaker
13. zSpells

Фичи(нативные):

1. zGamePad
2. zWaveMusic
3. zScreenShoot
4. zBrightLight
5. zNoGrass

Плагины, которые фикся zEngine - понятно дело не интересны, нативные фичи можно так или иначе зашить в движок, на моей стороне.
Категория "Фичи" - это то ради чего нужна совместимость. У модеров нет нормальных скриптов, вот они и делают расчет урона на C++.

Нужно реализовать высокоуровневый интерфейс со всеми функциям, которые применимы в обоих версиях движков.

Да, это будет идеально. По форме вижу примерно так:
1. OpenGothic будет уметь новый апи из коробки, а на оригинал будет бекпорт, работающий поверх текущего юниона.
2. Думаю нужно сразу выдать какой-нить популярный скриптовый язык на замену Daedalus, например Python
3. За первое приближение можно взять: OpenGothic compatibility initiative · Issue #29 · Lehona/LeGo. То есть будет api для:
доступа к состоянию Npc, и его инвентаря
базовая 2D(+3D иконки) графика
доступ к вводу (клавиатура, мышь, курсор)

При этом остается небольшой слон: совсем непонятно как тогда быть с "История Хориниса", Возвращением, и другими популярными модами

 

[MaGoth]

При этом остается небольшой слон: совсем непонятно как тогда быть с "История Хориниса", Возвращением, и другими популярными модами

да ни как не быть, при выводе какой либо системы все что ей не подчиняется должно быть удалено, иначе, никакой системы не будет..
вот как-то так...

 

[Goth_Man]

да ни как не быть

Ну или кто моды обновит под текущие реалии, например Возвращение 2.0 пересадить с родного ей не стандартного AST на современный в составе Union? про остальное не в курсе что там в нутре

 

[MaGoth]

Goth_Man, этим ни кто заниматься не будет..

 

[Try]

Выложил сборку 1.0.1311

• Общее
  • Новый формат файлов-сохранений, основанный на zip (#202)
  • Улучшена игровая камера (#198)
  • Добавленна кнопка k, для marvin режима (#194)
  • Marvin режим более не активан по умолчанию
  • AI обучился карабкаться на уступы
  • Множество улучшений производительности на стороне CPU
• Игра
  • Доработана механика ближнего боя (чтобы быть максимально близкой к оригиналу)
  • Добавлена реакция на воровство
  • Оптимизирован расчет оклюзии у звуков
  • Добавлен автоматический перенос строк в диалоги (#189)
• Скрипты
  • Добавлены wld_sendtrigger, zCTrigger.fireDelaySec
  • Добавлен init_global
• Графика
  • Добавлено смешивание анимаций
  • DEFAULT.TGA теперь используется, в случае если текстура не прогрузалась или отсудствует
  • Добавлен эффект ветра
  • Добавлен параметр "толстоты" персонажей
• MacOS
  • Улучшена работа с мышкой