Saruman

Есть и другие модули еще более печальные чем вормантаун Единственный годный модуль, который по-настоящему нашёл место в наших онлайн-игрищах - это The lost dungeon of souls. Он конечно тоже задуман в первую очередь как сетевой модуль - одному игроку там будет и сложно, и скучно.

Всем спасибо за поддержку и ответы! Концептуально как сделать задуманное уже ясно - отчеты об эспериментах с редактированием карт по мере прогресса закидываю в топик World Editor - маловато будет в моддинг-подфоруме. Сейчас подходит пора крупномастшабных экспериментов с использованием автоматизации. Вырезать часть основной карты, склеить её с доп.картами подземелий и многоуровневых зданий проблемой не будет. Сложнее, по крайней мере с моим текущим пониманием, будет взять только нужные для этой карты скрипты и диалоги. Подозреваю что их номера зашиты где-то в .mob-файлах, но готовой спецификации по теме я пока не нашёл, поэтому нужно экспериментировать, редактируя объекты в WorldEd и сравнивая начальный и конечный файлы в hex-редакторе. В принципе т.к. все диалоги/скрипты в рамках модуля уникальны, то в случае если продуктивные результаты заставят себя долго ждать, можно упаковать их все целиком в каждый из планируемых модулей, но это уже уровень Седрика Эпплби, а не клана Колеса и уж тем более Вендигрота Появились также мысли насчёт самих модулей, раз их создание выглядит уже более-менее реалистичным. Первое - это то как вписать одиночный сюжет в рамки мультиплеера, учитывая что система диалогов далека от, скажем, SWTOR. Идея следующая - каждый из модулей начинается со встречи с Вирджилом, который "выбирает" Живущем первого, кто с ним поговорит. Остальные сюжетно получаются также выжившими в крушении Зефира. В классическом варианте они примыкают к Живущему и Вирджилу и образуют тем самым классическую dungeon crawl party. Соотетственно сложность подземелий и сюжетных разборок нужно будет подстроить соответствующим образом чтобы это было интересно и не превращалось в overkill. Также нужно будет подредактировать скрипты/диалоги чтобы НПС принимали только одного игрока за Живущего, но при этом всяческие сайд-квесты могли выполняться кооперативно. Для этого, например, Вирджил будет давать игроку, первому вступившему с ним в разговор в начале модуля репутацию "Живущий", и соотвественно Рука Молоха и т.п. будут реагировать только на него. Кстати насчёт последних была также мысль попробовать добавить через них non-cooperative режим, когда игрок, не ставший Живущим, может быть завербован Рукой для убийства игрока-Живущего, и модуль заканчивается, если Живущий погибает от рук этого персонажа. Но такое пойдет в продакшн только если уже совсем будет нечего больше делать. Еще одна идея - сделать мини-концовки, взяв нужные слайды из оригинальной концовки игры. Так, если первый модуль будет заканчиваться прямо перед Тарантом, то в конце может быть показана судьба Туманных холмов и живущего в них алхимика (а в случае реализации non-coop режима - еще и при убийстве Живущего). Идеи есть, а модуля пока нет - это не есть хорошо. Надо добавить угля в топку котла моего парового движка.

То же самое получилось совершить и со стенами - смещение для них оказалось 75 байтов для X и 79 байтов для Y соответсвенно. Попробовал вручную перенести сектор с находящимся в нём домом: переименовал .sec файл сектора с учётом его новых координат, пропатчил все координаты статиков в файле с учётом переноса в соседний сектор (на 64 по Х), результаты на скринах ниже. Теперь нужно поэкспериментировать с остальными статиками и распознаванием типа статика (верифицировать соображения Криптона), которое будет необходимо для автоматизации патчинга координат.

Начал с простого - взял пустую "водную" карту и начал смотреть на координаты простых статиков типа "дерево". Для них нашлись координаты (по всей видимости 4 байта длиною, как описал Криптон) со смещением в 71 и 75 байтов соответственно от первого байта статика со значением 77. Манипуляции с этими значениями закономерно привели к тому, что статики "поплыли" в нужном направлении, и при изменении значения на n*64, n ∈ N оказывались в соотвествующих n секторах выше/ниже/левее/правее. Теперь предстоит поэкспериментировать с более сложными статиками типа стен, но достаточные для первых скриптовых экспериментов на Питоне или типа того результаты уже близко.

Долго вглядывался в получающиеся sec-файлы и в ман Криптона: here comes sector objects, which structure is undefined now, but objects can be looked-up by pattern: offset val 0x00 0x77 0x01 0x00 0x02 0x00 0x03 0x00 0x04 0x00 0x05 0x00 0x1c 0x00 0x1d 0x00 0x1e 0x00 0x1f 0x00 0x20 0x00 0x21 0x00 0x22 0x00 0x23 0x00 From each object we can now get following: offset size name 0x0C 2 bytes proto_id 0x34 4 bytes mob_type 0x3A + type_skip*4 - 1 4 bytes x_coord //type_skip see later 0x3E + type_skip*4 - 1 4 bytes y_coord type_skip depends on mob_type: mob_type mob_name type_skip 1 Portal 4 2 Container 4 3 Scenery 5 4 Projectile 5 5 Weapon 7 6 Ammo 7 7 Armor 8 8 Money 8 9 Food 8 10 Scroll 8 11 Key 9 12 Written 9 13 Generic 9 14 PC 11 15 NPC 13 16 Trap 13 17 Bag 9 Заметил, что 77 00 00 00 хорошо работает как маркер объекта - можно безошибочно найти все, не набрав мусора. Однако Криптон пишет, что нулевых байтов должно быть 5, а у меня во время экспериментов появляется только 3. Глядя на то, что должно быть координатами исходя из предложенных Криптоном оффсетов, создается впечатление что объекты в файле записаны в рандомном порядке - в двух соседних идентичных по наполнению секторах у первого объекта не совпал ни X, ни Y. Правда возможно я не на то смотрю - формулу оффсета я считал в десятичных числах, вначале конвертировав первое число, а возможно имелось в виду, что mob_type тоже - шестнадцатиричный и складывать нужно соответственно. Также не исключена кривая запись координат как в случае с координатами в .mob-файлах. Буду пробовать дальше.

Апдейт (почти через год, но лучше поздно чем никогда) по GUID'ам в .mob-файлах: Наткнулся на опен-сорсный исходный код на C# от World Builder для Temple of Elemental Evil, который был построен на модифицированном движке от Arcanum'а https://github.com/13xforever/toee-world-builder. Вот как там запилена генерация GUID'а (файл /src/ToEE World Builder/Helpers/MobHelper.cs): public static void GenerateGuid(out string s_GUID, out byte[] GUID) { var r = new Random(); var generator = new byte[16]; GUID = new byte[24]; s_GUID = "G_"; GUID[0] = 0x02; GUID[1] = 0x00; GUID[2] = 0x00; GUID[3] = 0x00; GUID[4] = 0x00; GUID[5] = 0x00; GUID[6] = 0x00; GUID[7] = 0x00; r.NextBytes(generator); GUID[11] = generator[0]; GUID[10] = generator[1]; GUID[9] = generator[2]; GUID[8] = generator[3]; GUID[13] = generator[4]; GUID[12] = generator[5]; GUID[15] = generator[6]; GUID[14] = generator[7]; for (int j = 16; j < 24; j++) GUID[j] = generator[j - 8]; for (int k = 0; k < 16; k++) { string s_Elem = generator[k].ToString("X"); if (s_Elem.Length == 1) s_Elem = "0" + s_Elem; if (k == 3 || k == 5 || k == 7 || k == 9) s_GUID += s_Elem + "_"; else s_GUID += s_Elem; } return; } Как можно видеть, генерация полностью рандомна, за исключением некоторого шаманства с байтами с 9го по 16ый. Остальной код проекта я не смотрел, но подозреваю, что если при генерации вдруг возникнет GUID, уже существующий у другого .mob-объекта (вероятность чего, по всей видимости, ) - это легко будет проверить по списку всех .mob-объектов в модуле и при необходимости заново его сгенерировать. Предполагая, что данный софт работал (а судя по двум крупным релизам и неоконченной версии 3.0 это так), можно предположить что просто рандомных GUID'ов и проверки на совпадение будет достаточно для копирования .mob-объектов при выполнении copy-paste.

Если получится копировать секторы карты целиком, то одну и ту же локацию можно будет включить во все модули, где она потребуется - вопрос тут скорее в оптимизации "нарезки" по сюжетному смыслу. Например Тарант с его ресурсной базой может высупать стартовой локацией для таких модулей как путешествие в Клан Черной Горы,, путешествие на Остров Отчаяния - так как сюжетная ветка начинается с Бейтса, дающего главный квест. А путешествие в Клан Колеса может начинаться непосредственно внутри их подземного города т.к. там уже есть всё необходимое типа магазинов и оранжереи. Это не все те же умения. Абсолютно согласен. Но еще важнее для меня аспект времени - у меня его очень мало, поэтому я иду по пути "дёшево и сердито". Тем более, что очередной проект портирования появился на горизонте.

Об этом и речь - время, скиллы, опыт, execution, project management (если больше одного dev'a). Всё это в свободное от работы время. Никто же не говорит, что создать игру Арканум с нуля невозможно - вполне себе возможно. Но вы вроде и не спорите, что это потребует значительных ресурсов. Я предожил поискать готовый фреймфорк исходя из экономии этих самых ресурсов. Если у вас они есть все и в нужном количестве - то, уверен, всё получится

Возможно я не прав и у вас всё получится, вам виднее

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

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

Горячий привет всем, кому после стольких лет до сих пор интересна такая казалось бы абсурдная тема, как сетевая игра в Арканум Начну с любимого (и возможно единственного внеклубного) мема аж 2002го года по сетевому Арку: "Эй уроды слабо в Arcanum по сети" Ну а если серьёзно, то с связи с очередным моим "возвращением" у меня возникли некие мысли. В прошлом году мною что-то делалось в плане экспорта и копирования кусков карты вместе со всеми объектами на ней. В теории если довести это начинание до конца (на практике это уже было реализовано в своё время Криптоном), то появится возможность создавать небольшие сетевые модули из элементов оригинального мира Арканума. Вы конечно же спросите: зачем и почему? В своё время мною предпринимась попытка перенести весь мир в сетевую игру. Она оказалась не совсем удачной по множеству причин: забагованность движка, не дающая доиграть длинные модули до конца большие размеры файла изменений, передаваемые игрокам, подключающимся по ходу игры (а как мы помним, пока идёт подключение, вся игра встает на паузу) огромный мир при небольшом количестве игроков, не объединённых в одну группу делает геймплей эквивалентным одиночной игре. Урезанной, забагованной одиночной игре. огромное количество времени, требующееся для прохождения и невозможность зафиксировать промежуточный результат (последнее я отчасти компенсировал виртуальной машиной с регулярными снепшотами и авто-накатом предыдущих версий, но это помогало лишь отчасти из-за общей глючности движка). и так далее... Создав для нас Уормантаун, Тройка кагбэ намекнула нам, каков может быть играбельный мультиплеер в Аркануме - классический dungeon crawling. Причем там явно всё было рассчитано на большую группу так как даже вдвоём пройти с 1-уровневыми персонажами модуль весьма непросто. Но если нарезать на такие модули весь мир Арканум, то можно получить: относительно "быстрые" модули, которые будет реально пройти до того как игра посыпется от накопленных ошибок из-за небольших размеров идеально подходят для небольшой группы игроков, при этом могут допускать не только кооперативный, но и конкурирующий режим с/без PvP фактор времени также будет привлекателен для тех, кто был бы рад поиграть, но свободного времени очень мало (например, для меня ) модули можно будет проходить последовательно, кагбэ проходя "уровни" Арканума, и таким образом при желании пройти всю игру. При этом:реализуется в некотором смысле фиксация промежуточного результата набранный персонажем уровень делает возможным прохождение следующего модуля с более высокоуровневыми мобами и боссами при заходе в следующий модуль авто-инвентарь сгенерирует более высокоуровневые предметы и даст технологам их лучшие изобретения, тем самым отчасти компенсировав потерю инвентаря Список можно продолжить, но думаю суть уже ясна. Если будет какой-то интерес со стороны клуба, то займусь этой темой плотнее (чисто для себя смысла делать нет). Естественно, конвертация в сетевую игру будет также подразумевать балансировку сложности чтобы играть было интересно, но в тоже время чтобы пати из 2 игроков могла осилить прохождение. В завершение добавлю, что не смотря на всю его забагованность, в Арканум можно и нужно играть по сети, ведь игра по-настоящему жива, пока в неё продолжают играть.

Можно вопрос - а почему именно Unity?

Привет! Технически это должно быть в принципе возможно - браузерных возможностей сейчас с лихвой хватит чтобы воссоздать уровень геймлея как в Аркануме. НО! Движок с нуля - это очень долго, дорого, ох****о для небольшой команды разработчиков, делающих это в свободное время. Единственный возможный вариант - это готовый движок с очень высокой степенью адаптированности к оригинальному геймплею. Например, технологические схемы, их изучение, сборка предметов из компонент - всё это должно быть как-то реализуемо используя некие готовые компоненты в движке. Поэтому если начинать что-то делать в данном направоении, то первым шагом был бы обзор существующих open-source движков, оценка их совместимости с game assets оригинальной игры, анализ для каждого из них scope of works, необходимых для получения играбельного результата. На основании этого можно было бы судить о том, возможна ли в принципе такая реализация в рамках хобби-проекта.

Можно ссылку? На сайте и на форумах Arcanum-Alive вроде ничего нового нет...