Суп /gd'ч, суть такова.

Сейчас пишу тулзы для редактора эффектов, это то что будет давать возможность изменять переменные или запускать шаблонные скрипты, тем самым можно будет реализовать всякие прикладные эффекты типа изменения кол-ва здоровья, для реализации аптечек, или всякие потребляемые вещества которые будут влиять на базовые параметры актераNPC. Всякие бонусы оружия или предметов будь то броня которая дает +4 к силе или вкусный хлеб который дает -10 к голоду и +10 к здоровью,все это делается с помощью системы эффектов и по мимо изменения переменных, она так же использует систему условий, с помощью которой можно задавать условия ограничивающие или дополняющие влияние эффектов.
Например сумрачная аптечка которая дает +30 здоровья - обычно, и +60 здоровья, если выполняется условия времяСуток = ночь, или портвейн777 который дает эффект +50 к зависимости от алкоголя и +15 к здоровью - обычно ,и +1 к зависимости, и +15 здоровью если условия Удача >=50; выполняется.

Самые внимательные и матерые олдфаги могли заметить схожесть с различными Creation Kit'ами которые клепает "беседка" из года в год, это сходство не случайно, т.к. мне условно нужна схожая механика, я в лучших традиция, не нарушая EULA произвожу инженерный анализ тулзов доступных мне редакторов. Это относиться не только к тулзам беседки, так-же я гляжу в тулзы движка FIFE и прочего, жадно изучая доступные туториалы, что дает мне туманное представление о строении того или иного обьекта математическая абстракция. Ну ты понял я, просто смотрю редактор предметов в том-же G.E.C.K'е вижу что предметы имеют - имя, вес, звук при падении и прочие тривиальные параметры, которые я анализирую на актуальность и востребованность в своем проекте, перегоняю-адаптируя в c# В пошаговых изометрических играх, да и вообще в играх, очень много таких вещей которые как-бы являются определяющими жанр или каким-то принятыми тенденциями- у почти всех NPC, во всех играх есть очки здоровья, почти во всех пошаговых играх есть очки действия, в рпг есть диалоги и т.д Таким образом я экономлю много времени и получаю представления о архитектуре проекта, так и живем.
На текущий момент у меня есть доступные тулзы для редактора классов актеровтупо шаблон базовых параметров класса позволяющий экономить время не вбивая параметры которые должны наследоваться классом,например есть класс "тоннельные торговцы", у них всех есть одинаковые навыки[харизма, бартер] и они все могут торговать с игроком и допустим торгуют только 3 категориями товаров, благодаря этому можно просто казать что актер тоннельный торговец и не ставить галочки, писать циферки., тулзы для редактирования фракций В этом определяем как взаимодействуют актеры между собой и всякие определяющие параметры типа рангов - запах ,дух,слон,черпак, имена этих рангов для разных видов полов (есть только два) и типы взаимодействия и модификатор этого взаимодействия, например есть фракции "тоннельные крысы" и фракции "тоннельные торговцы", между ними взаимоотношение = враг, а модификатор этого отношения равен 15, далее при встрече одних с другими они определять друг друга и путем простых вычислений( рангмодификатор) выстроят алгоритм действия, например если есть крыса низкого ранг условно 2 из 8, в таком случае актер получит значение ( рангмодификатор)=(2*15)=30, и в зависимости от того что указано в AI пакете, произведет атаку или если там указано что атаковать можно только врагов с фактором >100 ничего не сделает.Тем самым можно не только сделать взаимоотношения между NPC человечными/реалистичными, но и сделать более умный AI который будет использовать фракцию и ранг для оценки цели, в случае когда их несколько например, и нам хочется что-бы AI нападал не на пешок, а на королей, что в некоторых случаях более рационально..Так-же есть редактор предметов, но пока только для одного типа -патронов, все это есть в видео в одном из бампов, если интересно как это выглядит визуально. В следующем посте распишу подробней за архитектуру и что собираюсь делать дальше и о GOAP и в целом AI, а так-же может проясню за так скажем roadmap.

Вообщем как-ты понимаешь, пока все что есть, это лишь прелюдия перед настоящей еблей, которая начнется при сведении всех концов кода тулзов и внедрения их в игровой цикл. Так что пришло время поговорить о том что будет дальше, о архитектуре и когда я начну писать "Core" код.
Начну с архитектуры, как самые внимательные из вас могли заметить редакторнаписанные мной тулзы написан не для Editor'a в uinty, а для билда все кто писал тулзы Editor'a знают что это не благодарное занятие в Unity на текущий момент, следовательно юнитевский плеер скомпилированный билд, не может будучи скомпилированным добавлять или изменять что-то внутри себя, это очень важный момент, основополагающий при написании архитектуры.
Основываясь на этом и на предполагаемой игровой механики, приходим к ряду решений из которых сейчас затрону лишь часть требующуюся для понимания когда начнется "ебля" и сведения все в единое целое.
Вообщем если говорить о архитектуре, то это все похоже на моддинг, в том смысле что из-за того что мы не можем изменять скомпилированный билд, нам нужно писать код классов так, что-бы мы могли модифицировать и сериализовать их в файл, независимый от билда, с возможностью чтения\записи, и дальнейшей компиляциисборки/десериализации этих файлов внутри скомпилированного билда. С игровыми ресурсами немного иначе, например нам нет необходимости писать парсер для игровых звуков, музыки, тайлов и спрайтов с анимациями, с этими файлами лучше работать внутри unity и добавлять в билд перед компиляцией, заранее сделав анимации, повесив коллайдеры, выставив слои, тэги,добавить все в нужные атласы и т.д. Выходит что мы по большому счету редактируем классы, создавая их копии с различными параметрами, оперируя ресурсами имеющимися в билде моддинг.
В такой архитектуре есть как минусы так и плюсы, но так же есть и необходимость которая продиктована не только возможностями движка Unity, но и предполагаемой механикой RPG..
Так как RPG игры обычно оперируют большим обьемом данных,а эти данные требуется хранить в памяти компьютера, то самое верное решение хранить их на жестком диске а не в оперативной памяти,ну ты и сам знаешь, причем в компонентном виде, имея к ним компонентный доступ, что-бы не заполнять оперативную память и в определенный момент времени аллоцировать в нее только нужные данные. Например есть сцена, сцена состоит из карты проходимости, карты простреливаемости, актеров, предметов,контейнеров и т.д, каждый из этих классов сериальзуется в отдельный бинарный файл на жестком диске, к которому мы можем получить доступ из любого места. Тем самым мы например можем считать карту проходимости и произвести с ней нужный расчет не загружая всю сцену, это простой пример, или мы можем повстречать в игре актера торговца, который путешествует по миру и торгует с игроком и NPC, те товары которыми он располагает хранятся в контейнере класс в котором хранятся предметы(ammo,food,weapons etc...), как инвентарь, но контейнер, этот класс может быть у актеров или обьектов, например шкафчик, холодильник,сейф файл контейнера лежит на жестком диске и мы загружаем его только когда игрок пробует с ним торговать,но допустим что на этот файл ссылается в игре еще и сундук расположенный на какой либо сцене, скажем в доме торговца, тем самым мы может внести реализма, сделав эффект будто торговец хранит свои вещи в сундуке, так как сундук и торговец ссылаются на один и тот же файл контейнера, все изменения в контейнере отразятся на всех кто его использует, это более сложный пример.
По сути это тривиальное решение и отличается оно только реализацией и представляет из себя папку Data с россыпью бинарных файлов внутри.поскольку unity cкомпрометирован и нет смысла делать мастерФайл или шифровать эти данные.Те тулзы которые я сейчас пишу, и компилируют эти самые бинарные файлы которые нам нужно будет обрабатывать в игровом цикле. То есть написать тулзы это лишь половина работы, и основная "ебля" заключается в правильной десериализации производимых ими данных в игровом цикле, в правильности которой можно убедится только написав этот самый игровой цикл игровой цикл -имеется ввиду все то что будет обрабатывать компутер непосредственно в игре и сопряженные для каждого типа данных классы.
Тут и начинается "ебля" где обосраться можно на каждом повороте.
Но происходить все это будет постепенно, и для того что-бы начать этот живительный процесс, нужно написать редактор сцены, с редактором карты проходимости для поиска путей и редактором актеров с не полным инструментарием т.к. для начала нужно просто десириализовать файлы сцен и спавнить на них актера игрока, без AI, звуков, анимаций и всего, только игрок, и сцена с тайлами\спрайтами и возможностью передвижения игрока по ней. На этом этапе обрабатываются и внедряются в игровой цикл тулзы для сцен,актеров,предметов,поиска путей,некоторых эффектов. По мере добавления тулзов в игровой цикл, перечень тулзов будет расширятся, а сама структура цикла меняться, т.к. на данный момент не имею представления о том как точно они будут в этот цикл интегрироваться и взаимодействовать. Хоть я и написал уже 4 тулзы, толку от них пока нет, а не начал я писать с так нужных для начала формирования игрового цикла тулзов сцен и актеров, что-бы проверить всякое, и не кидаться сразу в этот гнетущий пиздец. Но сейчас уже преступаю к этому и надеюсь не обосрусь по дороге.Об этом пока и будет тред.