Перейти к содержанию

F2: Заметки о новом движке.


Jordan

Рекомендуемые сообщения

Приветствую.

 

Хотел бы поделиться мыслями по идеальному движку для fallout2 и Arcanum (очень схожи).

Теоретическая часть + примеры кода и т.д

 

Приглашаю, к дискуссии. Пишите свои мысли, идеи и т.д Главная идея, максимальная простота реализации.

 

Тема будет обновляться, добавляться мысли, код и т.д

 

1. Ресурсы игры взять оригинальные. Frm файлы(хранится вся графика), dat собственно контейнер для gzip файлов(распаковываются zlib).

Скрипты только конвертация, в скриптовую систему нового движка. Карты также.

 

2. Не тянуть легаси, не делать совместимость с текущими форматами, только описанными в 1 пункте.

 

 

1.Хочу начать со скриптовой системы. Без ее реализации движок мертв, для игрока.

 

На мой взгляд, реализовать скриптовую систему на том языке на котором пишется движок(C++). В своих наработках я реализовал так.

 

Есть 2 класса.

 

1. Critter

2. Script

 

Данные классы ссылаются друг на друга.

 

Теперь возьмем пример загрузки карты. За карту отвечает class Location.

 



class Critter
{
public:


private:
  Script * script;
};


class Script
{
public:
  virtual void MapEnter() = 0;
private:
  Critter * critter;
};


class Location
{
public:


private:
  std::vector<Script*> scripts;
};


 

При загрузке карты, проходим по массиву scripts и вызываем функцию MapEnter, вызывая ее в наследуемом скрипте. Остальные действия работаю по такому же принципу.

 

Пример скрипта.

 



class Tester: public Script
{
public:
  void MapEnter();
private:
  Critter * critter;
};


//Если сила > 5 добавить нож в инвентарь.
void Tester::MapEnter()
{
  if (critter->Stat(Stat::Strength) > 5)
  {
    critter->Inventory.AddItem("Knife");
  }
}


Общая идея думаю, понятна. Не нужно писать свой движок для скриптов, парсер, транслятор и т.д (встраивать все это в движок).

Решение лежит на поверхности. Система гибкая, простая в реализации. Не нужно писать лишние инструменты.

 

Если сравнивать со скриптами ф2 отличия, лишь косметические, ну скобочки, ну void и стрелочки.

Ссылка на комментарий

На мой взгляд, реализовать скриптовую систему на том языке на котором пишется движок(C++)

----

Это фейл.

 

Движок должен читать форматы f2 без всякой ручной конвертации.

Далее даже писать не о чем.

Ссылка на комментарий

По реализации карта-объекты по правилам ООП.

Карта должна содержать все объекты т.е. их массив, объекты в которых есть класс скрипт.

Сама карта дожна содержать класс своего собственого скрипта, а не массив указателей всех скриптов от других объектов.

Как ты понимаешь класс объект является общим для всех остальных, т.е криттер должен наследоваться от объекта.

Ссылка на комментарий

По реализации карта-объекты по правилам ООП.

Карта должна содержать все объекты, в которых есть класс скрипт.

Сама карта дожна содержать класс своего собственого скрипта, а не массив указателей всех скриптов от других объектов.

 

Собственно да. Объект в том числе и карта содержит указатель на скрипт. Так как скрипт можно повесить на любой объект.

 

При реализации critter_p_proc карта должна проходить каждый раз карту и вызывать метод по массиву указателей скриптов.

void Location::Update()
{
  script->MapUpdate(); //обновляет себя вызывая метод MapUpdate ее скрипта

После обновляем скрипты всех объектов

  for (size_t i = 0; i < scripts.size(); i++)
  {
    scripts[i]->MapUpdate();
  }
}

Critter создается кодом. Location->Manager->GetCritter("Имя прототипа", "Имя скрипта")

 

Мы говорим об одном и том же.

На мой взгляд, реализовать скриптовую систему на том языке на котором пишется движок(C++)

----

Это фейл.

 

Движок должен читать форматы f2 без всякой ручной конвертации.

Далее даже писать не о чем.

 

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

Ссылка на комментарий

Кажется тебе просто нужно в юнити реализовать то что ты хочешь.

Там вроде как можно в 3д как с 2д работать, просто натягивая текстуру на спрайтовые квады, плюс там скрипты на c# это в разы проще чем с++.

Или вообще взять другой готовый 2d движек и писать конверторы.

Смысл от твоего движка? если он не совместим с оригиналом, просто убить время на возью с кодом.

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

Но смотри правде в глаза, что как альтернатива для fallout востребован движек не будет.

Ссылка на комментарий

Кажется тебе просто нужно в юнити реализовать то что ты хочешь.

Там вроде как можно в 3д как с 2д работать, просто натягивая текстуру на спрайтовые квады, плюс там скрипты на c# это в разы проще чем с++.

Или вообще взять другой готовый 2d движек и писать конверторы.

Смысл от твоего движка? если он не совместим с оригиналом, просто убить время на возью с кодом.

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

Но смотри правде в глаза, что как альтернатива для fallout востребован движек не будет.

 

Я не отрицаю, справедливость твоих слов. До востребованности движка еще далеко)) Но, обратная совместимость усложнит реализацию.

 

Не факт, что юнити проще.

Ссылка на комментарий

Решил вообще не делать совместимость со старыми форматами игровых ресурсов. Сейчас делаю конвертер map2xml и frm2bmp. При установке движка, надо будет запустить конвертер файлов. Графика будет храниться в bmp формате лёгком для редактирования.

 

На ssl буду натравливать int2ssl и также конвертировать в cpp код. Прото файлы так же в xml. В карте будут храниться не число прото файла из .,lst файла. А название прото.xml Так же отдельные моды будут находиться в своих каталогах и не будут конфликтовать между собой. Это все на вскидку.

Ссылка на комментарий

Bmp это бородатый формат, к тому-же без альфа канала.

 

Я конвертирую при помощb SDL2, думаю да лучше что бы сохранял в png.

 

 

Вот первый блин комом))

 

dfdsfd.jpg

 

Офсеты кадров, размер кадров хранить в xml файле, для каждой картинки.

 

Пример.

 

<Sprite>

  <Orientations>6</Orientations>

  <Frames>8</Frames>

  <Frame>

    <PosX>56</PosX>

    <PosY>73</PosY>

и т.д

  </Frame>

</Sprite>

Добавить создание xml и еще предусмотреть вариант сшития fr0, fr1 и т.д

 

Как только будет готова тулза, буду выкладывать с исходниками.

Ссылка на комментарий

Все хотел спросить что используешь в качестве мультимедиа, оказалось банально sdl2.

Думал что-то оригинальное или иное.

 

Я чисто для себя пишу, LDL, то же самое что SDL, но типа сверх маленькая библиотека. Это так для развития кругозора. Пока только под винду.

 

Да SDL2 простой и кроссплатформенный. 

Ссылка на комментарий

Что такое LDL?

Little direct media layer. Типа как SDL Simple direct media layer. Есть версия на моем гитхабе, но старая версия. На моём пк более новая, но пока только под Винду.

В идеале, было бы здорово написать движок ф2 с новыми ресурсами от фанатов. Например юнитов и графику из соноры, и из Невады. Что бы можно было выкладывать саму игру и копирасты не могли домогаться. Короче не пиратствовать. Я просто не знаю, реально ли заменить оригинальный контент фанатским. На мой взгляд это хороший вариант и нет проблем с распространением и графику можно использовать в лучшем качестве.

Ссылка на комментарий

Мои каракули.

 

https://github.com/JordanCpp/LDL

 

SFML щупал. Не помню почему SDL2 выбрал.

Мои каракули.

https://github.com/JordanCpp/LDL

SFML щупал. Не помню почему SDL2 выбрал.

Все живое но давно не обновлял.

Ссылка на комментарий

Выводить графику через SetDIBitsToDevice() - кажется это будет очень тормознуто для игры.

 

посмотри вот это https://github.com/kvakvs/hge - этот движок действительно little (реализация DirectX9)

Ссылка на комментарий

Продолжаю, публиковать свои мысли по устройству движка.

 

1. Поддержка модулей(модов). Что то похожее было в игре Arcanum

 

У каждого мода будет отдельный каталог с одинаковой файловой структурой. Модули могут подключаться или отключаться. В ресурс менеджере, у каждого мода будет свой префикс мода + путь до ресурса. Так же глобальные переменные. Можно будет создать свои карты, монстров, графику а при игре выбрать основной модуль Fallout2 + BestMod. Будет доступна комбинация.

 

2. Прототипы, конфиги и карты хранят относительный путь до ресурса(относительный путь + имя ресурса) 

Пример "Fallout2\proto\tiles\ground2.xml" В зависимости от типа, будет добавляться окончательный путь. Вроде "C:\Games\Fallout 2\fallout2\proto\tiles\ground2.xml" В самом xml файле будет указано имя art\tiles\ground2.frm и требуемые свойства.

 

3. Прототипы криттеров. 

 

Криттер будет состоять из базового файла + файл характеристик.

 

Пример

 

Базового прототипа

<Critter>
  <Stat>
    <Strength>5</Strength>
    <Perception>5</Perception>
    <Endurance>5</Endurance>
    <Charisma>5</Charisma>
    <Intelligence>5</Intelligence>
    <Agility>5</Agility>
    <Luck>5</Luck>
  </Stat>
  <Skill>
    <SmallGuns>15<SmallGuns>
    <BigGuns>15<BigGuns>
    <EnergyWeapons>15<EnergyWeapons>
    <Unarmed>15<Unarmed>
    <MeleeWeapons>15<MeleeWeapons>
    <Throwing>15<Throwing>
    <FirstAid>15<FirstAid>
    <Doctor>15<Doctor>
    <Sneak>15<Sneak>
    <Lockpick>15<Lockpick>
    <Steal>15<Steal>
    <Traps>15<Traps>
    <Science>15<Science>
    <Repair>15<Repair>
    <Speech>15<Speech>
    <Barter>15<Barter>
    <Gambling>15<Gambling>
    <Outdoorsman>15<Outdoorsman>
  </Skill>
</Critter>   

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

<Critter>
  <Base>Human.xml</Base>
  <Stat>
    <Strength>-3</Strength>

  </Stat>
  <Skill>
    <Speech>+30%<Speech>
  </Skill>
</Critter>  

Удобно создать базового скорпиона и от него наследоваться, создавая новые виды. 

 

Есть вопрос как поступить с отображением. Как будет выглядеть криттер. То ли в базовый добавить, то ли дать возможность менять в наследуемом.

 

4. Общая структура файлов. Опишу на примере. Допустим нам нужно добавить новый город. Мы не делаем как в ориг ф2. Регистрировать нигде не нужно. Просто создаем карту допустим NewReno.map(внутри xml) + NewReno.txt(внутри xml) где будет содержаться информация в каких координатах на карте мира расположить информацию и т.д 

 

При загрузке игры. Движок сканирует каталоги с файлами и по описанию подгружает. Этим достигается отсутствие регистрации ресурсов в явном виде. Что способствует совместимости модов.

Изменено пользователем Jordan
Ссылка на комментарий

Етп убирай подсветку в коде, ничерта не видно твои каракули.

Кстати что у тебя за любовь такая к xml? он же, его структура ужасна для человеческого восприятия. Красавица и чудовище))
Тем более предполагается их редактировать, если бы он просто хранил данные...
Простой ini формат выглядит легким красавцем по сравнению с перекаченным уродцем.

Ссылка на комментарий

Етп убирай подсветку в коде, ничерта не видно твои каракули.

 

Кстати что у тебя за любовь такая к xml? он же, его структура ужасена для человеческого восприятия. Красавица и чудовище))

Тем более предполагается их редактировать, если бы он просто хранил данные...

 

Убрал подсветку. В xml я не использую атрибуты, якоря и остальные фичи. Только данные. Любви нет, просто формат без фич, только с поддержкой тегов, прост в парсинге. И я уже написал парсер для него. А главное текстовый формат, никаких бинарников, легко конвертируется и правится, руками или другими тулзами. Как вариант конечно можно и json заюзать, но я остановился на xml.

Простой ini формат выглядит легким красавцем по сравнению с перекаченным уродцем.

 Я думал, про ini файлы и для pro файлов вполне подходит. Но мне нравится универсальный вариант xml для всех данных. Xml поддерживает древовидную структуру, которая иcпользуется для карт.

 

Пример.

<Location>
  <Elevation>
    <Floor>
      <Tile>00000001.pro</Tile>
      <Tile>00000001.pro</Tile>
      <Tile>00000001.pro</Tile>
...
Ссылка на комментарий

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

 

Хорошее предложение, в ближайщее время реализую для F2. :-)

 


Yaml - зебест (похож на json без всяких лишних скобок).

 


Xml поддерживает древовидную структуру, которая иcпользуется для карт.
Для карты xml хорошо подходит, но не в случаях где потребуется обильное ручное редактирование (моддинг).
Ссылка на комментарий

Возобновляю работу. Защитил магистерскую диссертацию. Раскидал дела. Появилось время на хобби.

 

Проганье на JS не интересует, намучился с ним когда на фронте был. Сейчас в основном работаю бэкенд разработчиком. 


вебпорт где-то видел, но он видимо задохся раз не всплывает.

 

Игра

http://ajxs.github.io/jsFO/

 

Сам проект

https://github.com/ajxs/jsFO

 

 

Как миниум прикольно. И можно посмотреть реализацию определенных вещей.

Ссылка на комментарий

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

Хорошее предложение, в ближайщее время реализую для F2. :-)  

 

Yaml - зебест (похож на json без всяких лишних скобок). 

Для карты xml хорошо подходит, но не в случаях где потребуется обильное ручное редактирование (моддинг).

Получилось реализовать наследование характеристик?

Ссылка на комментарий

Получилось реализовать наследование характеристик?

Нет конечно. :-)

Это нужно создавать отдельный тип прото файл, аля .prx в котором и будет реализоваться эта наследовательность ввиде +/- . геморройная вещь в общем в реализации когда нет исходников движка.

Ссылка на комментарий

Для публикации сообщений создайте учётную запись или авторизуйтесь

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйте новый аккаунт в нашем сообществе. Это очень просто!

Регистрация нового пользователя

Войти

Уже есть аккаунт? Войти в систему.

Войти
  • Последние посетители   0 пользователей онлайн

    • Ни одного зарегистрированного пользователя не просматривает данную страницу
×
×
  • Создать...