Столкнулся с такой ситуацией что близы используют свои типы файлов про которые сложно найти информацию. с мпкью архивами уже в общих чертах разобрался. но осталось ещё несколько. к примеру расширение dun, amp cel и т.п. кто какую информацию об этих и других форматах имеет скиньте, ссылки там, примеры структуру. в общем кто что знает.
Там сам исправлю когда за компом буду. просто сейчас у меня не редактируются такие большие сообщения. всё что больше 2000 символов обрезается. что меня не устраивает.
Но ведь сделал так что квестовые доп уровни различаются от сложности и класса. а для этого как я понял нужно было как раз составлять дун файл. или всё проще делалось?
Количество кадров - 4B Список смещений данных кадров от начала файла - по 4B каждая запись. Первое число указывает в точку непосредственно после этого списка, последнее - на конец файла. Соответственно, количество записей на 1 больше количества кадров. Данные кадра: Пять чисел по 2B - именно здесь я и не разобрался. Первое число - всегда 10 (000A), по крайней мере во всех файлах, которые я разбирал. Остальные числа - скорее всего, какие-то смещения от начала данных кадра, йз что означают. Иногда этот ряд чисел оканчивается нулями. Есть догадки? После них идёт непосредственно изображение. Внешний цикл снизу вверх, внутренний слева направо. Способ кодировки мне известен благодаря (почти) полному совпадению оного с тем, что в DC6 DiabloII: (*)Берём 1B-число со знаком (X). Если X отрицательное, далее следует ряд прозрачных пикселей в количестве -X. Если положительное - далее следует ряд индексов палитры в количестве X штук, которые понятно что означают. Потом опять переходим к (*). Таким способом кодируется каждая горизонтальная строка отдельно. ЗЫ С большими изображениями (если они вообще есть) я это не проверял. В DC6 они дробятся на куски не более 256x256.
Бесценная информация. на выходных из за её незнания запоролся с контекстной инфой в мире. для того чтобы знать куда её отображать (ровно над картинкой, с выравниванием по середине) мне нужно знать прямоугольник в который рисуется картинка. ширина известна, икс и игрек известны, а вот как брать высоту? обязательно по всему кадру пройти чтобы её вычислить? или она где то в явном виде есть?
Добавлено (2011-07-06, 07:39) --------------------------------------------- В тх2 саб отрисовки кадра разобран но тот кто разбирал не оставил ни единого коментария потомкам и там всё сделано указателями. что не слишком читаемо. надо будет перейти на работу с индексами массива вместо этого.
- или она где то в явном виде есть? Похоже, что нет. Если нет в экзешнике или в других файлах. Если так, можно "по-быстрому" пройтись по кадру. Есть ли среди cel большие изображения (чтобы хотя бы один из размеров был больше, напр., 256)? Вот бы разобраться с этой пятёркой чисел в заголовке кадра, и, скорее всего, удобный конвертер cel-bmp создастся почти самостоятельно. На основе моего конвертера dc6. А то я тут прочитал, как вы вносите в игру картинки для уников... Забивайте шурупы молотком, а не микроскопом!
Я тоже прихуел от такого набора действий который можно избежать. было бы время и желание написать спец редактор.
Добавлено (2011-07-06, 08:28) --------------------------------------------- Но пока писать его некому. я в армии, дд занят переездом.
Добавлено (2011-07-06, 08:34) --------------------------------------------- Чтобы не мучиться с цел анимацией в тх2 планируется использовать 3д модели. хоть это и не меньший гемор зато можно создав одну модель получить её вид с любого количества сторон.
Добавлено (2011-07-06, 08:35) --------------------------------------------- Но это ещё нескоро.
И что характерно, тот самый CelMaker либо копирует заголовок кадра однокадрового файла в заголовок кадра в создаваемом файле, либо везде вставляет числа 10;0;0;0;0 (без "Has Header" и с ним соответственно). Интересно, эти числа вообще нужны? ... Проясняется. Оказывается, это смещения не от начала данных кадра, а от начала его заголовка. Поэтому первое число всегда 10 (длина заголовка). А я тупил Скорее всего, они указывают на начало кода определённых горизонтальных строк. Проверяю и думаю дальше. Возможно, скоро до cl2 доберусь. Забивайте шурупы молотком, а не микроскопом!
Cl2 используются в д2 и выше. какие у них новые возможности, преемущества? есть ли смысл в их использовании?
Добавлено (2011-07-06, 11:38) --------------------------------------------- И с форматом дун файлов можешь посидеть, разобраться? не всё же чужими редакторами пользоваться. может получится их развить, расширить...
И с форматом дун файлов можешь посидеть, разобраться? не всё же чужими редакторами пользоваться. может получится их развить, расширить...
Это шутка была? Если нет, то с dun мне придётся разбираться прям совсем наугад. Ну если только мне кто-нибудь накатит Ulmo's DUN Edit с пачкой примеров... Ладно, потом. Забивайте шурупы молотком, а не микроскопом!
Дизасемблированный код или грязный код на си по работе с ними могу дать.
Добавлено (2011-07-06, 12:45) --------------------------------------------- Код то есть, другой вопрос что не зная принцип цел файлов я смотрел на код отрисовки кадра и офигевал. привык к картинкам имеющим ширину и высоту и рисующихся слева направо сверху вниз. а тут снизу вверх ещё и кусками то прозрачными то цветными. без поллитры не разберёшьси. так же и с дун. зато трн просто как чайник. 256 байт соответствующие тому на что заменить каждый цвет.
Добавлено (2011-07-06, 12:47) --------------------------------------------- Ещё и какие то асн или как то так файлы называются. я даже без понятия в какой области они используются и что делают...
Кадр делится на блоки по 32 строки, та самая пятёрка чисел указывает на начало данных каждого блока. Сейчас думаю, как надёжнее определять ширину картинки. Многие файлы из objcurs2 не хотят признаваться моему алгоритму. Меня ещё запутало то, что TDG показывает немного не то, что на самом деле. И такой вопрос: вот когда делаем картинку для уника, нужно перетыкивать цвета из верхней половины палитры в нижнюю. А верхнюю половину в принципе можно использовать? Забивайте шурупы молотком, а не микроскопом!
Ширина там как то надёжно вычисляется и передаётся аргументом сабу отрисовки. как до кода доберусь могу скинуть код или написать принцип как это делается. сейчас без понятия, просто использовал готовое. про палитры не в теме. вопрос к мордору или кому нибудь кто рисовал картинки для тх1
верхняя для цветов подземелий используется на каждом уровне подземелья грузится своя палитра. где верхняя половина меняяется от уроня к уровню, а нижняя - всегда остается неизменной
Кстати, забыл сказать: я вот обещал сделать конвертер на основе своего BMP-DC6, но с DC6 всё проще. Для работы с CEL нужен именно удобный инструментарий. В общем, . Надеюсь, к моменту изготовления продукт будет актуальным. Конвертер (втч пакетный), просмотрщик, менеджер кадров - работы минимум на 2 дня . И ещё по поводу палитры: прозрачный цвет - это последний? Правильно ли я понял, что для независимости палитры от уровня нужно использовать цвета в диапазоне 7F..FE? (7F как чёрный, а FF нельзя, тк прозрачный) По поводу вычисления ширины картинки не беспокойтесь: появилась идея, которая выжмет из файлов CEL всё, что возможно. Правда, конкретная реализация пока в облаках. И в связи с этим повторяю вопрос: насколько большие изображения бывают в TH? Забивайте шурупы молотком, а не микроскопом!
После перерыва почти в месяц я снова взялся за CELMgr и добавил парочку функциональности. Теперь не работают только Merge, Import и Export в окне списка CEL и Copy/Move All в окне списка кадров. Хотя ради любопытства можно в эти кнопки потыкать Напоминаю, что делать код безглючным старался только я, остальные его даже не писали . Поэтому, как говорится, AS IS...
Добавлено (2011-10-03, 10:41) --------------------------------------------- Уже давно делаю DUN-редактор, и появился такой вопрос: поддерживает ли экзешник изменение размеров карты? Тб если размеры города сделать не 48x48, а 49x46, можно ли будет заставить это работать? Конечно, в TH2 это в любом случае можно будет сделать, но я за то, чтобы в окончательном TH2 использовались более стройные и гибкие форматы файлов, чем тот фейспалм, что творится там сейчас. В общем, стоит ли сейчас тратить время на изменение размеров карты?
Больше максимальных размеров можно только в Тх2 после апдейта, а если меньше то любых размеров можно. Только с изменением карты куча возни с размещением порталов, входов в подземелья, точек появления персонажей и точек появления после смерти. В тх2 нужно дун заменить на более удобный формат в котором будет предусмотрено размещение входов и скриптов.
Добавлено (2011-10-04, 20:54) --------------------------------------------- Кстати о скриптах. Как их организовать? Кто занимался созданием сценариев на картах? СтарКрафт, морровинд, герои? Как это организовано в других местах и как организовать в тх2?
В Старкрафте тупо куча триггеров на все случаи жизни (можно проверить количество ресурсов, зданий, определённых юнитов, времени от начала игры, гибель квестового героя...). Всё перечисленное можно проверять также не для всей карты, а для определённой области на оной вплоть до клеточки 1х1). Например, кампания кончится, только если убить определённого героя определённым образом на определённом месте, иначе респаун убитого. Или герой разорился и при этом не осталось ни одного раба. Или стандартное завершение в мультиплеер-замутах: игрок проигрывает, если у него в подчинении не осталось ни одного здания (и пусть хоть армия у него в подчинении при прочих равных не нагибаясь вынесет всю карту — нужна ну хотя бы ракетная вышка). Что ещё... Вот запустил редактор, из экзотических условий: нажатие на кнопку определённым юнитом, уход в невидимость, выход из невидимости, истечение наперёд заданного таймера (начало которого можно в свою очередь повесить на очередной триггер), NUCLEAR LAUNCH и так далее до полного упора. Короче стандартный if-then, даже без else, с начальным наперёд заданным стандартным набором условий и реакций. Причём реакции могут быть тоже ЛЮБЫМИ, вплоть до экстерминатуса всей карты или наоборот ковровой застройки (как-то на одной фанатской кампании нарвался на раш фотонками изнутри уже укреплённой базы, всем было весело). В стандартных кампаниях почти всё шло по таймеру, даже если он не показывался на экране, и/или количеству юнитов и ресурсов у игрока. В общем, как вы наверно уже поняли, я серьёзно занимался стариком в своё время, обращайтесь.
Кстати, о первом DeusEx. Там скриптование было вообще зачаточным и в большинстве случаев сводилось к перемене свойства «Альянс» у героев, спауну оных, телепортации с окрестных крыш, куда герой в здравом уме без читов не полезет (хотя они иногда начинали оттуда постреливать...). Девяносто пять же процентов триггеров представляло собой невидимый неосязаемый нефизический объект и висело в воздухе в определённых местах (их срыв происходит, когда герой пересекает заданный ранее радиус) и отвечает за получение сообщения от командования, набор опыта за исследование, подгрузка следующей/предыдущей локации etc. Если что непонятно, объясню подробнее.
Добавлено (2011-10-04, 21:44) --------------------------------------------- Например, такая цепочка: JC вводит код на клавиатуре. Запускается анимация опускающегося моста. Триггер, находящийся рядом с игроком, палит новый физический объект внутри себя, и меняет параметр Enabled (щас не помню как он точно называется) другого триггера с False на True. Триггер просыпается и обнаруживает героя внутри себя (в радиусе его действия — вся карта). Происходит срыв, и jc получает пулю в лоб от внезапно ставшего враждебным снайпера. Если остановить мост раньше времени, введя тот же код, ничего не произойдёт.
Ясно. Какие предложения тригеров есть для тх? Для квестов и не только. Из тех что уже есть и те которые интересно добавить. Как сделать теперь я понял. Делаем набор всевозможных тригеров. Затем добавляем их. В основном цикле проверяем срабатывание активированных триггеров и при срабатывании выполняем действие.
Ну, собственно, зачатки скриптово-триггерной системы в игре есть и сейчас. Одни ловушки чего стоят: триггер в чистом виде же. Расширять их можно, например, установкой «сигнализаии»: меня всегда раздражало, что мигание пентаграммы на озорной вечеринке у Лазаря всего лишь косметический эффект. Можно насовать таких кнопочек по всему подземелью, с тем чтобы при приближении к ним, например, сбегалась шобла со всей локации. Можно расширять морфинг подземелий, двигать стены, поднимать/рушить решётки. Собственно это всё тоже было у Лазаря. Можно делать как в Думе 3, или вообще в Сириус Сэме издёвка была: поднимаешь пилюльку на +1 здоровья и получаешь спаун ПОЛЧИЩ монстров в окружающее пространство. Это что навскидку, так-то нафантазировать очень много можно...
Какая-либо доля реализации уже есть? Если нет, могу предложить кое-что другое. На ваше усмотрение, конечно.
Во внешнем файле будет скомпилированный интерпретируемый код; каждому нужному объекту дать сколько нужно места для триггеров, в них записывать через редактор (связанный с компилятором) или средствами скрипта точки входа в скрипт. Отдельно указать точки входа для общеигровых событий. Если точка входа равна 0xFFFFFFFF, ничего не делать. Итак, попробуйте угадать, что это означает:
Такой страшный синтаксис - чтобы не особо мучиться с созданием компилятора. Можно и лучше, но дольше. Массивы val хранят числа, массивы obj - указатели на строки и объекты. Технически различаются тем, что последние хранятся в игре как указатели, а в файле - как индексы/смещения, поэтому нужна дополнительная работа над ними при сохранении и загрузке. ЗЫ Многое в этом направлении уже обдумано. Я написал только часть идеи.
Пока реализации нет вообще. Сейчас я могу только обдумывать и обсуждать. То что ты написал пока непонятно. Это реально объяснить более простым языком? Или к примеру с картинками, схемами.
1) Предисловие Помимо прочего, на форуме я предложил прикреплять триггеры к объектам, а не объекты к триггерам, как это обычно делают. В другом проекте (неигровом) это было идеальным решением и отлично сработало, но насколько это применимо к Diablo, я не задумывался. Это выгодно, когда каждый объект делает что-то своё, реагируя на многие события, затрагивающие его. Diablo к таким случаям совсем не относится. Так что продолжаем вносить предложения и совместно выявлять их недостатки и избытки (известная личность мне подсказывает, что это называется "мозговой штурм"). Кстати, я ещё побаиваюсь, что всё это уже придумано до меня, и читать это будет пустой тратой времени.
2) Техническая сторона Повторяю: не пытайтесь связать нижеследующий текст с моим сообщением на форуме.
Запуск триггеров: Чтобы почём зря не гонять компьютер по поводу выполнения триггеров (мало ли чего захочется моддеру), можно делить триггеры на группы. Какой триггер в какую группу - решает моддер с помощью скрипта. Работает так: вот, например, ударили монстра. ДО ТОГО, КАК ПРИМЕНЯЮТСЯ ПОСЛЕДСТВИЯ, эти последствия рассчитываются (нанесённый урон, факт попадания, факт блокировки, ...), данные заносятся во временный массив, и немедленно начинается поиск триггеров. Допустим, мы решили, что 8 групп на триггер типа GetHit хватит на всех. Берём значение однобайтового поля "TrigGetHit" монстра и пробегаемся по его битам. Если находим бит "1", переходим к поочерёдному запуску триггеров в соответствующей группе. И лишь когда выполнены все триггеры во всех заявленных группах, применяем последствия. Так эти последствия можно менять средствами скрипта до того, как о них будет известно: ... Бой с убером, здоровья остаётся один удар против одного удара, глад успевает первым опустить топор на ногу убера и... ПРОМАХ!!! И вылезает сообщение: "А ведь мог бы и попасть :b"... А триггер такой: находится в одной из вызываемых групп GetHit для убера; прекращает своё выполнение, если таймер заморозки этого триггера не истёк; также выходит, если засчитан промах; выходит, если нанесённый урон меньше текущего здоровья убера; выходит, если случайное целое число из диапазона 0..1 равно 0; меняет "не промах" на "промах"; выводит сообщение о состоявшемся былинном отказе; запускает таймер заморозки триггера на 3 секунды; выходит. С момента начала запуска триггера программа занимается исключительно триггером. Триггер завершается при очистке стека вызовов или при вызове скриптом соответствующей функции. Паузы организуются с помощью таймеров. Триггеры предлагаю организовать в виде связанного списка, содержащего точки входа в общий для всех триггеров интерпретируемый код. Если покажется полезным, можно добавить идентификатор и/или флаг включенности триггера. И ещё кое-что: нужно добавить возможность управлять порядком следования триггеров в группе. И ещё кое-что: отдельно, вне групп, должны быть "системные" триггеры, отвечающие, например, за генерацию уровня.
Данные: Как написано выше, при срабатывании события перед проверкой групп триггеров происходит запись предварительных результатов события в буфер, чтобы потом их можно было изменить (например, чтобы можно было случайно ударить топором монстра, находящегося тремя этажами ниже). Если триггер что-то изменит, следующие триггеры будут работать с изменёнными данными. Достаточно одного общего буфера для всех событий, тк пока используются данные одного события, другие события не обрабатываются. Локальные переменные не нужны. Для глобальных переменных используем два массива с размерами, указанными в заголовке файла скомпилированного скрипта. Почему именно два - потом объясню. Нужен ещё массив для объектов, созданных в редакторе и участвующих в скрипте. Один массив. Для каждого объекта нужно предоставить возможность цеплять по два массива к этому объекту. Тб два поля для массивов и два поля для количества элементов в них. Память под эти массивы отхапывается по приказу скрипта. Почему именно два массива - сейчас объясню. Итак, почему два массива. Игру надо будет сохранять. И если числа можно записывать в файл напрямую, то с объектами проблема - в массивы очень желательно записывать указатели на объекты. Поэтому числа сохраняем напрямую, а для каждого элемента массива объектов нужно предварительно найти тип и номер объекта в игре. К объектам также относятся переменные с текстовым значением.
Файл скрипта: Всё хранится в одном файле. В заголовке должны быть прописаны размеры вышеописанных массивов и стека вызовов, строковые постоянные, точки входа для триггеров к "системным" событиям, ну и ещё что-нибудь. Далее идёт код. Точки входа отсчитываются от начала кода. (Здесь должен быть синоним слова "код") интерпретируется так: Берём сколько нужно байт для получения номера действия, из массива по этому номеру берём указатель на обработчик действия (даааа, вот работёнка будет программистам проекта - составлять таблицу этих указателей). Далее в коде следуют параметры, которые могут быть непосредственными значениями, строковыми константами (смещение с начала таблицы, см. ниже), объектными константами (индекс в массиве указателей, см. выше), переменными (индекс переменной в массиве) или функциями (номер функции, указатель на обработчик получаем аналогично). У функции тоже бывают параметры. Итак: обработчик действия/функции получает управление и начинает хватать параметры из следующих байтов кода. Если встречает функцию, передаёт управление ей, (где-то здесь была рекурсия), вторая функция возвращает значение, а первая после этого продолжает собирать параметры. Как только все параметры собраны, начинается их обработка. То есть результат компиляции этого: action(a,b,func1(5,c,func2(),d),"abc",^leoric) устроен так: action v.a v.b f.func1 i.5 v.c f.func2 v.d s.0 o.18 где v., f., i., s. и o. - признак того, чем является аргумент (переменная, функция, непосредственное значение, строковая константа, объектная константа). Имеется в виду, что строка "abc" стоит первой в таблице строк, а указатель на Леорика - девятнадцатый в массиве. Логичная последовательность байтов получилась? В общем, при такой организации и код интерпретируется не слоупоком, и компилятор писать не особо сложно. Можно ещё приколоться и сделать так, чтобы функция могла возвращать несколько значений (тб у одной и той же функции могут быть два аргумента подряд, возвращающие координаты точки, а может вместо них быть одна функция, сразу возвращающая обе координаты). Но при этом придётся добавить стек параметров. В том самом "неигровом проекте" я именно так и сделал. После кода идёт таблица строковых констант.
3) Конкретности
Дополнения к геймплею: Если вдруг ещё никто не додумался, можно ввести объекты, активируемые оружием. Здесь надо решить, делать событие "объект активирован ударом" или оставить эту идею для воплощения средствами скрипта. Можно не связывать проходы друг с другом, а делать проходы односторонними. Можно, например, организовать "волшебную лестницу", ведущую себя по принципу не 2<->1, а 1->2->3->1. В Lamentation Sword был такой портал.
Действия: Изменить точку назначения межуровневого прохода Имитировать удар с заданными уроном, типом, точностью, ...
) Приложения
О моём сообщении на форуме: Там был представлен код, который с вероятностью 1/16 делает сундук пустой ловушкой, бросающей фаербол на открывшего. Если фаербол попадает в стенку, всем игрокам даётся сообщение, что вам, мол, ничего не сделалось, а открывшему сундук - что на тебя, мол, никто не обиделся.
5) Послесловие
Число 4 мне не нравится. Поэтому пусть здесь будет 5 разделов. Жаль только, что это не оригинальная шутка...
Так лучше? ... Хм... Действительно лучше Забивайте шурупы молотком, а не микроскопом!
Вопрос по поводу области применения триггеров. Где предлагаешь их использовать, а где статический скомпилированный код? Я изначально думал ограничить область применения триггеров квестами. Это упростит создание новых и редактирование старых. А в ловушках и других местах в них смысла не вижу. ИМХО ненужное усложнение.
А возможные квесты, в которых используются ловушки и другие места? Для начала можно сделать минимум. По крайней мере мой вариант реализации полностью поддерживает добавление функций, даже перекомпилировать скрипт не придётся. Забивайте шурупы молотком, а не микроскопом!
Уже было в ветке тх2 обсуждение новых квестов. Получается замкнутый круг. Составители квестов хотят ориентироваться на то какие тригеры можно использовать при составлении квестов, а составители тригеров наоборот хотят знать какие тригеры потребуются для реализации квестов, а какие не будут востребованы. Ну и без руссификации от квестов для русскоязычных никакого проку не будет.
Сначала над русификацией по любому надо работать, а уж потом и над всем что с ней связано (легенда для каждого оружия, квесты и т.д.), а то один Мор поймёт в чём там замес
События: убит монстр; подобрана вещь; открыт сундук; использован объект; истёк таймер; вход в зону и выход из зоны (мб не обязательно игроком?); переход между уровнями.
Сценарные действия/функции: добавить/удалить запись (список квестов); запустить/остановить таймер; изменить время таймера; создать монстра; убить монстра; действия для награды (вещь в инвентаре/вещь на земле/опыт/статы/магия); изменить карту (реализация - вставить в текущую карту содержимое будущего аналога DUN, ориентируясь на метку на карте); имитировать использование магии (вот такая вот подлость нам от Зала костей).
Системные действия/функции: безусловные и условные прыжки; вызов подпрограммы / возврат; вызов подпрограммы для каждого объекта, удовлетворяющего условию (да, вещь реализуется нехотя, но полезная); циклический вызов подпрограммы (хотя можно и без этого обойтись); арифметика; присвоение; сравнение чисел/объектов; добавить триггер; удалить триггер; включить/выключить триггер (если сделаем); что-нибудь для изменения порядка следования триггеров (йз что именно); включить/выключить группу триггеров для определённого объекта (если идея выживет); обратная связь; указатель на последний объект, созданный скриптом.
Ну а в далёком будущем попробуем сделать из игры игровой движок. Обсуждаем!
ЗЫ: какие впечатления от того, что я расписал по вопросу реализации? Забивайте шурупы молотком, а не микроскопом!
Darbundudrator, ты может удивишься, но я помню про твою прогу CELmanager. до сих пор не разобрался в ней. обязательно разберусь с ней и дам ОС тебе. вообще, хочется сказать, что мне приятно видеть такую активность как в твоем случае. если пожелаешь, я с радостью тебе выставлю ранг участника развития ТН(2) на форуме
Ну блииин! Я буквально сегодня весь день составлял такой же список на бумажке. Ладно, продолжу в том формате, в котором сообщения выше
Ещё событий: создан голем/гидра; покинул заданный радиус (так можно обрушивать решётки, отрезая пути к отступлению); задел кого-то радиусом света (сейчас по этому триггеру активируются монстры — почему бы его не расширить); применена определённая магия (см. ниже). Заметка на полях: сейчас гидру или ТП используют как фонарик, причём монстры не активируются. Считать багом или фичей? Также триггеры можно вешать на резкое поднятие базовых (к примеру, два подряд спектральных эликсира) и/или текущих (мощной шмоткой) статов. Ещё события: лучник загнан в угол (милишники ломанутся на подмогу!),
Сценарные события: разрушить/восстановить стену (например, сделать наконец двоякоиспользуемые рычаги). Теперь отвлечёмся. Меня давно настораживало (с точки зрения реализма), что монстры совершенно не реагируют на мочилово в их тихих и тёмных подземельях. То, что они отстают, ладно: заебало бегать за этим недоумком, и вообще они тупые. Но хотя бы минимальный интерес к армагеддону в соседней комнате должны же проявлять. Если не боссы, то по крайней мере их свита («шестёрку» на шум послать — великое дело). Отсюда, скажем, можно сделать тотальный сбор как по трубе после применения магии Апокалипсиса. Это позволит сделать её чуть подоступнее и/или значительно усилить, потому что игрок будет знать, что потустороннему зову, раздающемуся при этом по всему лабиринту, не в силах противостоять ни один босс и через две минуты вся эта шобла ломанётся к нему. На другую магию массового поражения можно реагировать не так, но всё же взрывы файрболов через стенку, наверное, всё-таки слышны-)) Ещё события: добавить хм понстрам; добавить хп последнему ударенному монстру; воскресить босса/свиту.
Предложения к морфингу карт: сделать островки и мосты между ними (передвигаемые рычагом) Предложения по движку: ввести патруль, шатающийся по лабиринту просто так. Для-ради прикола — в качестве пасхалки, при совпадении каких-нибудь редчайших действий, загнать монстра в портал в деревню вслед за героем и вообще, по легенде монстры расползлись по всем подземельям, используя те же самые лестницы, по которым ходит герой. Понимаете, к чему это я?.. Но это совсем уж навряд ли, я понимаю. Так мы договоримся до того, чтоб встать у дверей церкви и ждать, пока к тебе приползёт Дьябла с самого низу .
Отсюда, скажем, можно сделать тотальный сбор как по трубе после применения магии Апокалипсиса. Это позволит сделать её чуть подоступнее и/или значительно усилить, потому что игрок будет знать, что потустороннему зову, раздающемуся при этом по всему лабиринту, не в силах противостоять ни один босс и через две минуты вся эта шобла ломанётся к нему.
Т.е. одни апокалипсисом собираем всех, а потом ещё несколькими - добиваем :-) Фарм этажа за пару минут получается :-)
1) Формальность? 2) Если и вступать в TH Team или что-нибудь подобное, то непосредственно перед периодом активного участия, а сейчас получается "непосредственно после". Я "как раз вовремя" начал погружаться в учёбу. Похоже, моё участие ограничится форумом (поэтому вы будете видеть меня здесь немного чаще ). По крайней мере, DUN Editor я пока оставил в покое.
Quote (Коул)
лучник загнан в угол (милишники ломанутся на подмогу!)
Успеют? Забивайте шурупы молотком, а не микроскопом!
Может и формальность. Не обязательно вступать в команду когда что то активно делаешь. Я лично поделал немного за 3 месяца а сейчас в армии и теперь только активно болтаю, ищу информацию, мнения и т.п. Думбрингер в свободное время мучает 3д движок. Со временем на него наверно перейдём. Дд раньше делал сервер, сейчас взялся писать документацию. Никто никуда не торопится. Каждый что то делает не спеша когда есть время и желание. Вот если бы проект приносил доход и стал основной деятельностью, то ситуация была бы иной, а пока так. Мордор с тх тим улучшает первую часть, а пару человек паралельно работают над второй.
Добавлено (2011-10-09, 10:19) --------------------------------------------- Может и формальность. Не обязательно вступать в команду когда что то активно делаешь. Я лично поделал немного за 3 месяца а сейчас в армии и теперь только активно болтаю, ищу информацию, мнения и т.п. Думбрингер в свободное время мучает 3д движок. Со временем на него наверно перейдём. Дд раньше делал сервер, сейчас взялся писать документацию. Никто никуда не торопится. Каждый что то делает не спеша когда есть время и желание. Вот если бы проект приносил доход и стал основной деятельностью, то ситуация была бы иной, а пока так. Мордор с тх тим улучшает первую часть, а пару человек паралельно работают над второй.
Добавлено (2011-10-09, 22:16) --------------------------------------------- У кого есть какая нибудь информация о заполнении таблицы палитр? Это массив из 16 палитр из 256 чар цветов. Сейчас в ней критическая ошибка. Без доп данных о её составлении неясно что же творится. Куча циклов в которых выполняются куча непонятных действий. Если чем то поможет, скину код заполения таблицы когда он станет более читабельным
Добавлено (2011-10-10, 17:28) --------------------------------------------- И к мордору вопрос по поводу Ии монстров. Как у них устроен выбор действий? Какая есть на тему информация? Когда буду с ними копаться, потребуется.
надо, не?
Скорее всего, они указывают на начало кода определённых горизонтальных строк. Проверяю и думаю дальше. Возможно, скоро до cl2 доберусь.
. 
. Поэтому, как говорится, AS IS...
.
). По крайней мере, DUN Editor я пока оставил в покое. 
