Ремейк героев, ... Опции

[Vade Parvis]

Да, тоже верно. Легкий инструментарий помогает не только "неумехам", но и облегчает работу более профессиональным людям. Кроме того - "неумехи" получают инструмент для того, чтобы сделать первый шаг...

[fireman]

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

[Kastore]

Миша-то свалил пропал...

[Misha Khorovodov]

Миша-то свалил пропал...

Да, тут я, Kastore the Warlock, тут. Просто молчанием выражаю своё согласие с Docent Picolan: без программистов «сей диспут ничто иное как переливание из пустого в порожнее, беседа исключительно гипотетическая». Есть два возможных варианта в данной ситуации: либо на форуме в данный момент нет толковых программистов, либо они не вполне осознают своё счастье. Настоящего программиста просто коробит необходимость изворачиваться, используя заведомо тупую программу (тут я вполне понимаю желание Гиппокамуса и Арсения переписать экзешник). Программист из принципа сядет и перепишет её, как надо, чтобы не нужно было извиваться всем телом, обходя ее баги. Истинное творчество – заставить машину работать так, как ты считаешь это нужным. Применительно к нашему случаю, истинное наслаждение продвинутого программиста – это не создание кампаний, магий, и т.п. – всё это нужно оставить геймерам, для этого есть фан клубы и форумы, а потому это должно быть технически просто и доступно для любого – пусть экспериментируют свободно. В принципе на сегодняшний день нет большой проблемы даже для создания эффективного набора 3D утилит для быстрого создания юнитов. По большому счету, все геройские города - суть одно и то же, меняется лишь обертка. Любой программист это понимает. Потому истинное наслаждение для него – создать достойный АИ, чтобы заочно выигрывать у тысяч human gamers.

[Vorek]

а нафига это human gamers? задача компа красиво отдаться... на предел сил игрока. в игры где комп реально умнее будут рубиться только хардкорщики - потому что не стоит тратить на игру слишком много времени.

[Docent Picolan]

среди геройцев в основном как раз-таки любители сравнительно сильного АИ, которого они (геройцы), к сожалению, так нигде и не увидели..

[Misha Khorovodov]

задача компа красиво отдаться...

Хорошо сказано, только красиво отдаваться на предел сил игрока – это большое искусство и без должного интеллекта, увы, оно не доступно. Лично мне приятно побеждать на грани невозможного, когда всего лишь одно неверное действие может стоить поражения. А любители «мясных» карт и лихого крошилова всегда имеют оригинальный АИ и чит-коды.

[CrackedMind]

Да кто же мешает для хардкорщиков сделать доп. опцию. Было бы время и желание

[MasterOfPuppets]

задача компа красиво отдаться...

Прямо продажная женщина какая-то...

[hippocamus]

Майнд, и как это сделать?
Редактор, люди, ждите-ждите, я от него не отказался, но сами понимаете, работа сильно заторможена обстоятельствами СИе есть женитьба, переселение в другую страну и посвящение в священный сан.

[Misha Khorovodov]

Ну наконец-то нашел тех, кто реально пытается переписать экзешник (без малейшего желания обидеть Гиппокамуса и его команду ). Теперь можно излагать конкретные сображения в ответ на вопрос CrackedMind: «Чем можешь помочь?» Может быть некоторые из этих соображений покажутся элементарными, но я не знаю на какой стадии находится разработка группы Openheroes в настоящее время и потому начну с самых азов.

Поскольку ремейк предпологает сделать всё с нуля, то логично начать с разумной организации самих баз данных. Чтобы не было напрасных споров, сразу разъясню, что я имею в виду. Базы данных Героев делятся на 3 основные группы:
1. Предметы. Сюда входят юниты, объекты на карте и сами герои. Каждый предмет – это отдельная база данных, которая включает в себя параметры предмета, его анимацию, озвучку и тексты.
2. События. Сюда входят:
a. Воздействия, изменяющие параметры и местоположение предметов (выстрелы, магии, артифакты и эвенты). Каждое воздействие – это отдельная база данных, которая содержит алгоритм воздействия, параметры, анимацию, озвучку и тексты.
b. К событиям относятся также сообщения на экране в ходе игры. Они могут быть связаны с каким-либо действием игрока, моментом времени, эвентом или другим сообщением (диалоги).
3. Поля (карты). Сюда входят: карты приключений, поля сражений и собственно города.
Обозначим все эти базы данных одним термином «элементы игры».

Безусловно, есть смысл заархивировать все базы данных в один большой файл - объединенную базу данных, типа *.lod , но не надо их смешивать, объединяя параметры в сводные таблицы. Гораздо эффективнее иметь унифицированные (т.е. одного формата) базы данных для каждого типа элементов (юнитов, героев, объектов, магий, артифактов и тд.). Во-первых, это позволит безболезненно вводить новых юнитов в игру, особенно взятых с сайта. Большинство из нас уже имеет свою собственную конфигурацию Героев и если сейчас, импортируя чей-то новый город, загрузить себе чужие crtraits.txt, twcport.def, cprsmall.def, cranim.txt и тд, то с собственной конфигурацией Героев можно распрощаться.

Имея разделенные базы данных (БД), можно будет передавать друг другу новые элементы (юниты, магии, города...) в виде законченных баз данных (параметры + файлы озвучки + анимации + иконки), полностью готовых к использованию, которые легко внедрить в игру – просто ввел БД нового юнита в свою объединенную базу данных и готово! - тут же видишь его в редакторе карт и соотвественно в игре. Редактор карт должен брать список всех элементов игры (юнитов, объектов, городов и тд.) из той же объединенной базы данных, что и экзешник. Таким образом, для введения в игру нового юнита или города достаточно создать или импортировать его БД, запаковать его в свою объединенную базу данных (типа *.lod) и потом просто поместить новый элемент на карту.

Во-вторых, поскольку ведение новых элементов в игру абсолютно не отразится на собственной конфигурации, это сделает программу более стабильной, потому что базы данных будут независимы друг от друга. Если экзешник не найдет базы данных (БД) указанного юнита, он должен показать белый квадрат вместо этого юнита и по умолчанию принять его параметры равными 1 (1 атака, 1 жизнь и тд.), чтобы игра не висла. Если анимация не указана – она просто пропускается, если воздействие не описано – оно просто принимается равным нулю. Программа никогда не должна останавливаться и зависать.

Сводные таблицы нужны только для удобства балансировки, да и то в виде отдельной утилиты, но об этом дальше. Для создания и изменения БД, нужны простенькие редакторы. Для наглядности я тут за пару вечеров слепил макет редактора юнитов.

При запуске редактора, он обращается в объединенную базу данных и выводит в список всех имеющихся юнитов по номерам, именам и принадлежности к городам. Итак, открываешь редактор, пишешь номер юнита и кликаешь «Показать». Если юнит с этим номером существует, показываются все его данные, если же нет – тогда все поля останутся пустыми и ты знаешь, что надо его создавать. Тут никаких трюков и скриптов – просто заполняешь все поля, жмешь «Сохранить» и всё! Редактор записывает готовую БД в отдельный файл в той форме, которую установили кодеры для экзешника. Кодеры в принципе не обязаны придерживаться существующей сегодня формы записи данных. В новом экзешнике они могут использовать любую другую удобную им форму и потом просто конвертировать все существующие данные в эту новую форму.

Фактически данный макет - это действующий интерфейс, в принципе ему нужно прописать соотвествующие обращения и он станет полноценным редактором. Сейчас для примера он показывает базу данных U0014 – Юнит номер 14.
Макет редактора юнитов

Базовая идея редактора – максимальная автоматизация, то есть практически все списки (юнитов, магий и тд.) заполняет сам редактор из объединенной базы данных. Имена соотвествующих файлов иконок, озвучки и дефов редактор тоже прописывает сам по шаблону. Если при нажатии кнопки «Показать», окошки иконок, озвучки и дефов окажутся пустыми, нужно создать недостающие файлы, положить их в нужную папку или запаковать в общий файл (типа *.lod) и опять кликнуть на просмотр юнита. Программа никогда не должна зависать.

[Qwertyus]

Идея хорошая, может стоит всё же новую тему открыть? Т. к. эта всё же посвящена вполне конкретному "творчеству" конкретных людей. Думаю, не стоит это смешивать...

[Bisik]

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

[Vorek]

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

но под такое - надо все переписывать...

[Misha Khorovodov]

Bisik, а вот это по-нашему!
По правде говоря, чтобы помочь, вовсе не обязательно быть программистом. В этом проекте огромное количество работы не только для них, но и для людей, разбирающихся в тонкостях игры и имеющих навыки логического мышления. Не дело всю работу валить на двух-трёх кодеров, чем больше людей поддержит – тем быстрее будет готово. Например, уже сейчас желающие могут продумать структуру и функции других редакторов с учетом своего опыта создания модов: редакторов магий, артефактов, сообщений (текстов и диалогов), эвентов и т.д. Лично у меня уже есть проработанный вариант редактора городов.

Приличный редактор героев есть в редакторе карт. Кстати, сам редактор карт тоже вполне годится (особенно после того, как его доработал Sergroj ), нужно лишь изменить его обращения, чтобы он брал списки элементов игры из объединенной базы данных. Тогда карта будет указывать экзешнику какие элементы использовать в данной игре. Таким образом, сначала надо оптимизировать базы данных, а потом заниматься экзешником.

Если хочешь, для начала качни себе демо версию какого-нибудь редактора Visual Basic, например NeoBook 5 из neosoftware.com Он очень простой, ты, я думаю, без труда разберешься. Компилировать он тебе не даст, но позволит оформить свои идеи в виде проекта. Потом можешь кинуть его мне, я его скомпилирую и тогда ты сможешь выставить его на форуме для обсуждения. Всё просто, для тех, кто хочет делать

Vorek, для тех случаев, когда номера загружаемых элементов совпадают с существующими номерами в твоей объединенной базе данных, введена опция «Загрузить постороннюю базу данных юнита для корректировки и введения в объединенную базу данных» (смотри раздел «Общее»), чтобы изменить номера новых юнитов перед вводом в игру. А переписывать всё равно придется, раз ремейк затеяли

Qwertyus, мне честно говоря всё равно, в какой теме постить – главное, чтобы дело сдвинулось с мертвой точки. Если какие-то программисты поддержат эту идею, можно открыть новую тему. Впрочем, я не силен в технологии разработок идей на форуме, может и правда лучше уже сейчас ее открыть. Но тем не менее, вижу, что сейчас каждый сидит со своим «творчеством» в своем собственном углу форума, а воз, как говорится, и ныне там. Ребята, хватит гоняться за личной славой, давайте наконец соберемся ради общего дела. Чего делим? Проект-то некоммерческий

[Qwertyus]

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

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

Что мы получим засчёт этого: намного более простую систему подготовки новых кадров для любого монстра (да и вообще, любого объекта игры). В любой момент можно будет добавить ему дополнительные кадры анимации, не переделывая при этом старых. Засчёт того, что каждый кадр сможет использовать полноценную палитру из 256 цветов, новые анимации смогут быть более красочными. Сама модель монстра должна представлять собой, к примеру, zip-архив, в который будут упакованы отдельные кадры монстра + таблично-текстовый файл, описывающий игре принцип использования этих кадров для проигрывания той или иной анимации (стойка, движение, атака и т. п.). В этом же файле должны содержаться указания на скорость проигрывания той или иной анимации. В него же или в другой файл должны быть помещены все сведения о параметрах монстра, его принадлежности к какому-либо городу, особых умениях и т. д. и т. п. Насчёт используемых монстром звуков - думаю, их нужно только прописать в файле "модели", но не включать их туда - звуковая база должна быть отдельной.

Могу расписывать дальше, но хочу узнать мнение сведущих людей - можно ли использовать в игре движок, который бы понимал анимации 8-битных кадров с разной палитрой и считывал бы данные не из тупых лодов и дефов, а из обычных папок и zip-архивов. Неплохо было бы ещё предусмотреть масштабируемость кадров - т. е. если сейчас кадр монстра представляет из себя прямоугольник 450*400 точек, то нужно, чтобы можно было использовать и кадры с более высоким разрешением. То, что нужно будет для этого перепаковать заново все ресурсы игры - это пустяк по сравнению с теми плюсами, которые мы получим в итоге.

[trntrn]

to Qwertyus
Да если какой-то из проектов движков таки доберется до финишной черты, то в нем конечно будет поддержка форматов отличных от def. Скажу больше - в наше время значительно проще поддерживать полноценные 32 битные изображения чем возится с палитрой.
Что касается спрайтов в высоком разрешении - технически поддержку сделать можно. проблема в том что в Героях 3 уже есть огромное количество прекрасного арта - перерисовать его в высоком разрешении видится непосильной задачей. А половинчатые решения - одни спрайты в высоком разрешении, другие "растянутые" - думаю никого не устроят.

[Kastore]

Нет шобы что-то Кастору написать, Миша. Я же жду от вас новостей!

[Vorek]

разработка на Делфи - не поленился бы помочь... вообще, язык этот прост и силен - да и графических движков для него много, например (рискуя навлечь ругань професионалов) GLSsceen... Постоянно дополняеться, расширяеться, есть поддержка... да и прост он - особых возможностей не предоставляет, но нам то их и не надо... Более того - мы сможем одинаково юзать и спрайты и 3D модели! (подгружая их под нужным углом)

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

Насчет форумной разработки - нужен ведущий програмист, который распишет структуры данных итд итп...

[fireman]

Vorek - если хочешь помочь есть http://hippocamus.forum24.ru/ .Напиши там.

Вообще многое,что тут написали уже давно решено.