Очень интересно
Напиши гайд по использованию, не хочется продираться через тысяч дебри кода
Тебе нужен гайд по конфигам или именно по классам в коде? На их написание (Вики) уходит довольно много времени, плюс код довольно динамичен сейчас и быстро меняется, от чего надо править Вики.
Этот проект никак не связан с этим тредом. Я его читал, но там вообще уже перешли на псевдоабстракции, место решения проблемы.
Я же пытаюсь пока написать рыночную систему с покупкой продажей предметов и оказания услуг за эти предметы.
По классам гайд нужен. Это хорошо что ты такую штуку запилил, но без документации она никому не будет нужна
>любителей квестов
Я правильно понял, что это будет текстовый квест?
Зачем тогда Godot?
Или это фреймворк?
А так, задумка амбициозная, сам примерно похожим страдаю, но я бы рекомендовал начать с одного персонажа, а уже потом масштабировать на целый город, если получится.
Впилил биржу
https://gitlab.com/mdchs/dsystem/-/merge_requests/3
Пока не тестил как работает, могут быть баги. Выложу, когда персонажи будут что-то производить и выкладывать на биржу излишки. Пока что биржа будет абстрактной (покупать можно будет через любые расстояния). В дальнейшем привяжу время покупки к местоположению поставщика.
Я буду дополнять документацию постепенно. Но пока что это все в сыром виде и использование строго запрещено, так что я по-поводу документации пока что не сильно парюсь.
- Вы можете использовать мой код в своих играх, т.к. в игре
разделен UI и Игровая логика. Это позволит легко использовать свою графику, включая 3Д с минимальными изменениями. Если Вас устраивает текущий стиль, Вы можете просто использовать свои картинки/диалоги в конфигах.
- Вы так же можете дорабатывать код вместе со мной, в зависимости от потребностей.
- Вы так же можете создавать персонажей и писать диалоги в конфигах (но желательно чуть позже, когда проект архитектурно стабилизируется) для моей игры.
Что касается проекта, то это не совсем текстовый квест. Я просто очень плохо умею работать с графикой, поэтому выбран стиль текстовых квестов - 2д комнаты, 2д персонажи. Ближайший аналог - Валет Плетей, но с более "реалистичным" миром. Возможно, я устану придумывать персонажей, и просто сделаю его переиздание под свой лад.
Что будет отличать игру от квеста?
- Динамически меняющийся мир (хотя бы частично).
- Боевая/Постельная система в виде мини игр.
- Экономическая система.
- Система отношений с персонажами.
- Обыск разных объектов и т.п.
В центре игры будет город на перепутье миров, связанных с ним кучей порталов. Основной смысл существования города заключается в караванах, проходящих из одного мира в другой или останавливающихся на этом перепутье, чтобы обменяться разными вещами.
Правда, не все так сладко. Все что попадает в город из других миров начинает гнить и разлагаться с большой скоростью и лишь мистическая пудра может помешать этому на время, если обработать ей предмет или употребить внутрь. Благодаря таким свойствам она и стала основной валютой в городе.
Эту пудру добывают святые мужи из Церкви и обменивают на рожденных в этом городе детей, ибо право появления на свет в этом городе избавляет от проклятья разложения и предмету или существу уже не требуется пудра для выживания.
Вначале игры вам предстоит выбрать героя, который либо попадет, будет проживать или был рожден в в этом городе. От этого будет зависеть сложность игры. Ему придется использовать все доступные методы для получения власти в этом городе, либо потерпеть поражение без средств к существованию, встречаясь с существами с разных планов.
В ситис скаилаинс вполне живой город. У каждого балванчика свой дом, своя работа/учеба, свои маршруты к этим местам и походы по магазинам.
Ты за ними следил? Ты уверен, что у каждого и это не просто толпа сгенерированная?
Да. Ты можешь любую псину переименовать в Карасика, отследить где живет и где гуляет, а потом через некоторое время отыскать ее снова. Пока жива, никуда не пропадет, все также ходит с тем же хозяином.
Может быть сохранена только переименованная псина. Сколько таких можно переименовать?
Если выбирать между "сохранять только переименованных" и "сохранять вообще всех", имея цель создать симулятор города, гораздо проще будет выбрать второе, потому что первое будет трудно отлаживать, чтобы скрыть от игрока обман.
Главная проблема всех этих симуляторов толпы в том, что не все осознают, что человечку на экране НЕ НУЖНО обрабатывать что-то там каждый грёбанный кадр. Ему вообще не нужно заниматься самостоятельным сканированием местности, он может получать сигналы к действию от глобальных систем.
Хороший антипример: Яндере Симулятор. Яндередев в силу своей... специфической психики не осилил проектирование на достаточном уровне, из-за чего его виртуальные школьники каждый кадр спрашивают у таймера, сколько времени, чтобы определить, что им в данный момент нужно делать. Любой знакомый с геймдевом программист скажет, что можно было сделать рассылку сообщений "пора поесть", "пора на урок" и т.п. от таймера к школьникам, или хотя бы сократить частоту проверок до одной проверки раз в несколько секунд или даже минут. Даже если ты хочешь чтобы было рЕаЛиСтИчНо, реальные люди смотрят на часы, допустим, раз в полчаса или раз в час, за исключением особых случаев, т.е. даже ИРЛ люди не смотрят на часы непрерывно (даже на "внутренний таймер" мозга, который неточен). Вот если таких ляпов не допускать, то проблем с оптимизацией будет в разы меньше.
Алсо не забывай, что "обрабатывать логику пешехода" не равно "двигать пешехода по карте". Текущее положение пешехода может вычисляться только когда игрок смотрит на конкретный участок карты, в остальное же время в мозгах пешехода есть только точки А и Б маршрута, время начала и скорость движения, которые, естественно, не нужно часто изменять. Пока игрок смотрит на одну из улиц, пешеходы на сотнях других улиц просто не существуют, а их мозги бездействуют, ведь они находятся в предсказуемом движении и не требуют никаких постоянных корректировок.
>Что будет отличать игру от квеста?
>- Динамически меняющийся мир
Вообще, я делал акцент на "текстовый". В текстовых играх все эти динамически меняющиеся миры и всё остальное было реализовано ещё в прошлом веке и неоднократно. При этом графики там, разумеется, не было совсем. Но делать текстовые игры всё же сложнее, чем простые графические, т.к. игра вынуждена взаимодействовать с игроком через диалог, а с пониманием и синтезом адекватной речи у программ до сих пор проблемы. В результате ты ограничен неким подмножеством естественного языка, то есть простыми командами по схеме "действие предмет цель", а осмысленного диалога с персонажами без заскриптованных деревьев сценария вообще не выйдет, либо персонажи будут напоминать питомцев, понимающих 3.5 команды. Короче, создать симуляцию людей на базе одного только текста сложнее, чем делать графический симулятор ничего не говорящих людей.
В той же ГТА пешеходы выглядят намного живее и разумнее, хотя с ними и нельзя разговаривать, а вот любые чат-боты рано или поздно выдают свою бестолковость и непонимание реальности. Т.е. пешеход на улице Лос Сантоса понимает, когда кто-то открывает стрельбу, боится её и убегает от неё, и это делает его живым. А чат-бот не понимает банальных вещей, которые ему пытаются объяснить, независимо от количества нейронов в его GAN мозгах...
>мистическая пудра
Во-первых, довольно странный и сложный лор. Ты бы сделал для начала симулятор ограниченного города, в который никто не может попасть и из которого никто не может выбраться, прежде чем приделывать параллельные миры, караваны и связанные с этим механики...
Во-вторых, будет ли "мистическая пудра" наркотиком? Название намекает же. Во многих произведениях часто такое встречается, что внезапно открытое вещество, имея множество чудодейственных свойств, начинает использоваться как наркотик, что служит одним из движущих сюжет элементов мира. Ну там мафия, нелегальная торговля, постоянные стычки с полицией, целые районы обдолбанных и потому агрессивных нищих, внезапные толпы агрессивных "зомби", сносящих всё на своём пути и т.д. Вот это я понимаю - пудра. А у тебя она пока не имеет никакого смысла. Ну да, предметы "гниют" без пудры, и что? С тем же успехом они могли не гнить, или их нужно было упаковывать в коробки, или в этом мире просто было очень жарко и нужно было охлаждать свои товары. Смысла в магической пудре ноль, она чувствуется совершенно лишней.
>стала основной валютой в городе
Если это расходный материал, который ещё и достать очень трудно, хреновая из него валюта... Смысл в такой валюте? Любые фантики подошли бы на эту роль с тем же успехом. Да, этой пудрой важно владеть, но для обмена она вряд ли годится. Если тебе нужно обработать ящик пудрой, ты не можешь использовать пудру для покупки ящика, ведь тогда тебе нечем будет его обрабатывать, логично? По сути, цена ящика возрастёт в пару раз: часть пудры достаётся продавцу, часть ты тратишь на обработку ящика. С точки зрения игрока получается, что никакой разницы по сравнению с обычной покупкой нет, так зачем этот элемент лора нужен?
Наверное, зря придрался, делай что хочешь, но если бы я играл в такую игру, у меня бы обязательно возникли эти вопросы и негодование нелогичностью мира/поступков героев. Типа, ладно, тебе постоянно нужны какие-то магические расходники, но почему ты должен отдавать их за предметы? Почему они не додумались печатать банкноты, или монеты из драгметаллов отливать, или какой-нибудь магический биткойн могли изобрести. Нет, нужно торговаться с помощью порошка, без которого ты сгниёшь заживо и вместе со всем ценным лутом...
> почему ты должен отдавать их за предметы? Почему они не додумались печатать банкноты,
Потому что они гниют, очевидно же!
Вот смотри, твоя сила зависит от твоего оружия, брони, телосложения. Но если у тебя нет пудры, то у тебя нет ни оружия, ни брони, ни мышц. Все сгнило. Очевидно, что самым важным товаром является то, что позволяет сохранить твои пожитки и тебя самого. Если бы хлеб мог хранится вечно и был маленьким, то люди бы использовали хлеб место валюты.
Суть валюты в том, что она:
1) Не должна мочь добываться всеми
2) Не должна добываться легко, чтобы медленнее инфлиироваться
3) Или должна тратится с той же скоростью, что и добывается, чтобы не инфлиироваться.
Всем этим критериям пудра подходит.
> Но делать текстовые игры всё же сложнее
Что конкретно с проблематикой диалогов, то я знаю об этой проблеме. И я знаю как бывает, когда сделано просто куча кнопок "дать/спросить" и т.п. Я думаю, я смогу решить эту проблему.
>Я думаю, я смогу решить эту проблему.
Много вас таких думало, потом по весне проекты побросали...
>Потому что они гниют
Они гниют потому что ты так придумал, а я спрашиваю, зачем ты придумал какую-то пудру и механику гниения предметов без обработки пудрой? Во многих играх жанра выживание даже еда не способна гнить, то есть ты буквально тонны тортов можешь наготовить и потом несколько лет питаться этими тортами, они будут свежими как в первый день. А у тебя гниёт буквально всё... Зачем?
Ладно бы ещё пудра была своеобразным наркотиком, чтобы замутить какой-нибудь детектив/полицейский/криминальный боевик, избитая тема, но всё же конфликт серьёзный. А тут какие-то гнилые бомжи пудрой обмазываются чтоб притормозить своё гниение.
>Если бы хлеб мог хранится вечно
Проблема пудры в том, что это РАСХОДНИК. Если я правильно понял, всем понаехавшим жителям нужно ежедневно втирать в себя эту пудру, а предметы так и вообще все осыпать ею. Только местным не нужно тратить пудру на своё тело, но без неё они останутся голыми и безоружными бомжами. В результате пудра очень быстро тратится даже если ты ничего не покупаешь, а на какие деньги ты будешь покупать пудру, если у тебя все товары портятся без неё?
Ты вроде писал, что детей обменивают на пудру, потому что дети не гниют, а какая скорость производства детей? Даже если ты за одного ребёнка цистерну пудры получишь, её тебе надолго не хватит, даже если не будешь ничего покупать, а покупать ты будешь как минимум еду. К тому же местных детей могут производить только местные, а как быть понаехавшим? Что они могут обменивать на пудру, когда у них этой самой пудры не осталось и всё сгнило? В результате всё равно все сдохнут и останутся только голые местные на совершенно пустой асфальтовой площадке, на которой раньше был город.
Да и вообще, если в этом городе настолько херово жить, то почему в него едут из параллельных миров? Жили бы себе нормально и про пудру даже не знали, что им там помешало? Должны быть какие-то супер жестокие условия жизни в параллельных мирах, чтобы смириться с риском сгнить заживо, истратив последнюю горсть драгоценной пудры, которую никак не получить обратно, или даже случайно рассыпав её - пудра же, не соберёшь рассыпанную.
Если за ребёнка платят очень много пудры, которой хватит на несколько месяцев, то тот, кто продает ребенка хотя бы в нескольких штуках в месяц получит власть и богатство. Как только он ее получил, он может скупать женщин бомжих, осыпать их пудрой и делать из них производителей детей, чтобы получать ещё больше пудры. Соответственно, мы играем в том состоянии, когда эти связи уже налажены.
Все гниёт потому что в этом мире расы и объекты разных планов. Тут могут быть и космические десантники и демоны и племя дикарей. Чтобы уровнять их в этой метавселенной, их обмундирование должно гнить, дабы предоставить им равные возможности с представителями других рас.
Не гниют не дети, а все что было рождено в этом мире. Те понаехавшие могут сделать ребенка и он не будет гнить. Но они будут.
Соответственно, создание большого количества детей >> больше богатства >> больше убервафлей и топовых вещей. Но естественно, эти основные источники дохода уже попилены, и никто не будет хотеть терять власть и деньги создавая себе конкуренцию в этом бизнесе.
В этот город едут для того, чтобы переместиться из одного плана в другой. Например космодесантникам очень нужно перевезти броню т83 в мир племени папуасов. Но портал туда пока не открылся и надо ждать. Поэтому космодесантники приезжают в этот город, и сдают часть своего товара по дешевке, чтобы получить пудру и обмазываться ей пока не откроется портал. Иногда порталы не открываются вообще, и тогда можно либо вернутся в свой/чужой мир, либо обосноваться в городе, либо сгнить когда кончится пудра.
Позволить себе вернутся в свой мир могут не многие, тк за товар уплачено и часто в кредит. Более развитые торговые империи давно имеют свои посольства/диаспоры в этом городе, чтобы решать такие вопросы.
Любого прлхожего можно переименовать и следить за ним. Поиграйте да проверьте.
Так, пол дня сегодня выносил всякую статистику. Конечно, это все довольно примитивно, но!
Теперь предметы в зависимости от самого дешёвого рецепта или наличия трейдовой заявки или по уровню качества могут высчитывать свою цену.
Соответственно, если на рынке стоимость составляющих повысилась с 5 до 6 монет, то стоимость всех производных автоматически вырастет.
Так же существует такой параметр как маржинальность, это количество заявок которые надо решить персонажам по отношению к предметам решающим эту проблему на рынке. Если разница между этими значениями велика, то стоимость будет уменьшена/увеличена.
Теперь предметы в зависимости от самого дешёвого рецепта или наличия трейдовой заявки или по уровню качества могут высчитывать свою цену.
Соответственно, если на рынке стоимость составляющих повысилась с 5 до 6 монет, то стоимость всех производных автоматически вырастет.
Так же существует такой параметр как маржинальность, это количество заявок которые надо решить персонажам по отношению к предметам решающим эту проблему на рынке. Если разница между этими значениями велика, то стоимость будет уменьшена/увеличена.
Да уж, сложный сеттинг. Про толщеходы и то проще было, хотя там вроде даже химические элементы анон придумывал.
>делать из них производителей детей, чтобы получать ещё больше пудры
Я так понимаю, сеттинг чисто про рабство и ради рабства? Не вижу смысла завязывать всё на торговле детьми, кроме удовлетворения фетиша на работорговлю лолями... Просто предупреждаю, что сегодня СЖВ даже в СНГ имеют большую силу, если захочешь публиковаться в Стиме - говном закидают же. Можно троллить геев и смеяться над трансами, но стоит затронуть тему работорговли и тем более с участием детей - тебя в твою пудру и перемолят же вместе с твоей игрой. Даже фреймворком пользоваться не захотят, типа, дурная репутация.
>портал туда пока не открылся и надо ждать
Хм, если порталы так долго остаются закрытыми, что нужно, скажем, неделю провести на промежуточной станции, где ты рискуешь умереть из-за эффектов этой станции, и подождать в своём родном мире ты не можешь (потому что в него портал открывается в совсем другое время), то стоит ли вообще направляться в тот другой мир? Подумай сам, люди уже давно могут построить колонию на Луне, но никому это нахрен не нужно - риски высоки, а пользы никакой, все интересные учёным эксперименты делают на МКС или с помощью беспилотных кораблей. Это просто идиотизм, рисковать жизнью и всем имуществом ради перехода в другой мир, когда в твоём мире живётся не так уж плохо. Т.е. повторяю, чтобы твоя вселенная работала и существа из разных миров стекались на твою гниющую станцию посередь бесчисленных миров, жить в этих самых мирах должно быть намного херовей, чем гнить заживо.
Гораздо логичнее было бы, если бы этот мир был чем-то вроде оазиса в пустыне - жизнь в нём идеальна и прекрасна во всём, поэтому существа из других миров открывают порталы в него и путешествуют через него в другие миры, но задерживаться там нельзя чисто из-за местных законов (за нарушение которых полагается дезинтеграция), иначе понаехавших станет слишком много. Т.е. вся жизнь стремится к лучшим условиям для жизни, никто не захочет попасть в мир, где жить намного сложнее, чем в твоём собственном. Должна быть весомая причина, зачем кто-либо пользуется порталами с такими опасными последствиями. Ну, скажем, если родной мир существа целиком и полностью уничтожается, и он вынужден в роли беженца ожидать очередь в новый мир в таком вот дерьмовом, опасном и жестоком распределителе...
Не читал всю ветку, но путешествие между мирами можно использовать для торговли. То есть, всегда в популяции найдутся те, кто готов взять больше риска для большей же награды.
Если бы у нас аборигены Амазонки владели золотом, то многие были бы готовы пешком пробираться сквозь заросли, чтобы впарить им бутылку водки за 5 грамм.
Ну ладно, туземцев можно и просто исстребить, зато если бы были лунатики, у которого в избытке условного гелия-3, но мало произведений искусства, то можно было бы устроить обмен и корабли летали бы туда-сюда. А из-за дополнительных правил, можно и парочка населённых пунктов образовалось бы.
Ты оцениваешь опасности по себе. На самом деле у нас множество зарабатывает и на военной деятельности. Прутся незнамо куда, чтобы заработать 300к в месяц в какой нибудь пустыне.
Вот то то и оно, что от луны пользы никакой. А вот съездить пограбить индейцев с золотом и вернутся назад, это выгодно.
Я бы думал и над космическим сеттингом и ещё над чем, но космос никому не нравится. А планетскейп нравится всем.
>космос никому не нравится
А как же космические симуляторы? Их довольно много. Вот в космических рейнджерах была симуляция всех NPC - где летают, что делают, какое отношение имеют к игроку и т.д. А игра культовая, между прочим.
Ну, с торговлей всё понятно, непонятно только в чём прикол пудры для игрока. С точки зрения игрока какие-нибудь внезапные вулканы или ещё что-то такое было бы более интересным риском, чем гниение и необходимость владеть какой-то пудрой против гниения.
Представь ММОРПГ, в которой все персонажи ежесекундно получают -1 урона, и поэтому вынуждены периодически пить лечебные зелья, чтобы мочь уйти подальше от спавна. Экономика вся строится вокруг торговли лечебными зельями: меч стоит 2 зелья, щит 3, доспехи 10; за шкуру кролика дают одно малое зелье, а за шкуру медведя сразу 5 больших, и т.д. В чём фан для игрока от такой механики? Да, в лоре можно прописать "этот мир проклят и все находящиеся в нём гниют заживо, поэтому вынуждены поправлять здоровья целебными зельями, которые стали на вес золота и потому используются вместо валюты". Но в чём практический смысл для игрока? Одно лишь неудобство - вместо классических золотых монет жизненно важный расходник.
Ладно, не важно, сама идея интересная, просто странная.
В каком месте она культовая? Ну типо в снг на нее дрочат, а за пределами? Кстати игра кал имхо.
Я не заставляю игрока пить зелья. Пудра будет у него просто автоматически исчезать.
Что это даёт.
1. Не позволит копить миллион предметов в инвентаре.
2. Симулятор выживани, без унылых "попей/поешь/поспи"
3. Тк предметы нельзя долго хранить, то их будут максимально быстро продавать, что ускорит рост ВВП этого города, а значит уменьшит издержки на производство убервафлей и они появятся на рынке без участия в этом игрока.
4. По сути это тоже самое, что нет денег на еду и ты умираешь от голода, без голода. Т.е. можно кормить нпс пудрой, чтобы они не погибли. Т.е. можно у нпс попросить что-то в замен.
Добавлена биржа.
На биржу можно выставлять предметы. При выставлении предметов на биржу, они исчезают из инвентаря.
Можно покупать предметы с биржи. При покупке денежные средства будут перечислены владельцу заявки.
Можно отменять заявки, тогда Вы получите все предметы назад.
Исправлена неприятная циклическая зависимость.
Теперь таски выдаются на сутки
Добавлены методы для взаимодействия с новым функционалом.
Добавлены статистики: по количеству предметов на рынке, по количеству персонажей которым нужен предмет такого качества
Добавлены возможные требования по реагентам предметам
Вынесены рецепты от предмета
Персонажи научились: Продавать предметы, покупать предметы, искать предметы для удовлетворения нужд, использовать предметы.
Следующие обновления будут связаны с улучшением документации, и переписыванием блока тасков. Он хуево расширяем.
Я столкнулся с тем, что персонажу может понадобится произвести предмет. И чтобы его произвести, ему нужно купить реагенты. Но текущая система тасков не позволяет ему накидать себе кастомных, только получить ежедневные, что делает её говном.
Так же нужно каким-то образом набрать начальную статистику по выполненым таскам. Или так же переписать взаимодействие с ней к хуям. Её проблема в том, что когда персонаж появился, требования к приобретению предметов у него константные, поэтому все персонажи побегут покупать дешевое маспо на рынке, что лорды, что крепостные. Брать эту информацию из конфигов не хочется. Все же не хочется заваливать конфиг непонятными числами.
Обновить конфиги. Сейчас они неудобны, не выдают ошибки. Заполнение конфигов должно приносить радость и детям и взрослым.
На биржу можно выставлять предметы. При выставлении предметов на биржу, они исчезают из инвентаря.
Можно покупать предметы с биржи. При покупке денежные средства будут перечислены владельцу заявки.
Можно отменять заявки, тогда Вы получите все предметы назад.
Исправлена неприятная циклическая зависимость.
Теперь таски выдаются на сутки
Добавлены методы для взаимодействия с новым функционалом.
Добавлены статистики: по количеству предметов на рынке, по количеству персонажей которым нужен предмет такого качества
Добавлены возможные требования по реагентам предметам
Вынесены рецепты от предмета
Персонажи научились: Продавать предметы, покупать предметы, искать предметы для удовлетворения нужд, использовать предметы.
Следующие обновления будут связаны с улучшением документации, и переписыванием блока тасков. Он хуево расширяем.
Я столкнулся с тем, что персонажу может понадобится произвести предмет. И чтобы его произвести, ему нужно купить реагенты. Но текущая система тасков не позволяет ему накидать себе кастомных, только получить ежедневные, что делает её говном.
Так же нужно каким-то образом набрать начальную статистику по выполненым таскам. Или так же переписать взаимодействие с ней к хуям. Её проблема в том, что когда персонаж появился, требования к приобретению предметов у него константные, поэтому все персонажи побегут покупать дешевое маспо на рынке, что лорды, что крепостные. Брать эту информацию из конфигов не хочется. Все же не хочется заваливать конфиг непонятными числами.
Обновить конфиги. Сейчас они неудобны, не выдают ошибки. Заполнение конфигов должно приносить радость и детям и взрослым.
1. Легко ограничивается по весу/объёму/количеству предметов. Никого не смущает, когда персонаж не может уместить в своём рюкзаке/доме больше какого-то количества предметов.
2. "Попей/поешь/поспи" понятно всем, и когда говорят о симуляторе выживания, подразумевают именно это. В классических шутерах тоже можно умереть, но их ведь не называют симуляторами выживания. К тому же тебе всё равно придётся вводить механику питания и сна, если ты хочешь сделать жизнь персонажей более правдоподобной, даже у инопланетян должен быть источник энергии и период отдыха.
3. Вот это уже весомый аргумент. Хотя я не разбираюсь в экономике и не понял, как гниение всех вещей ускоряет производство убервафлей для игрока, и почему нельзя просто сократить задержки на производство, ты же полностью управляешь симуляцией.
4. У тебя персонажи будут с "реалистичным поведением", но не будут нуждаться в питании обычной пищей? Чем они вообще занимаются, кроме обмазывания пудрой и производства новых детей?
А визуализация всех этих процессов какая-нибудь есть? Или ты только код пишешь и на практике его не проверяешь? Я бы в первую очередь сделал какую-нибудь визуализацию города/жителей...
4. Они будут нуждаться в выполнении своих задач, которые перед ними поставил бог псевдорандома, а так же задач которые они сами себе поставили, чтобы выполнить основные задачи, которые им поставил день.
1.2. Вес объем и остальное - это все не интересно. Ограниченный инвентарь лишь накладывает неудобство игроку. Как и поешь, поспи. А вот взятие в аренду предметов - это новая механика.
Визуализация происходит в логе. Лог сренькает тем, что делает персонаж.
Испытываю неудовлетворение от того, что годоторазрабы не посмотрели мой код и архитектуру.
Конфиги обновлены и стали более понятны пользователю. Теперь парсинг конфигов в лог возвращает нормальные ошибки.
Работа с конфигами ещё будет продолжаться, но сделал основные шаги для того, чтобы можно было начать ими пользоваться сторонним людям.
Работа с конфигами ещё будет продолжаться, но сделал основные шаги для того, чтобы можно было начать ими пользоваться сторонним людям.
Переписываю чарактер контроллер на псевдо-гоап.
>Реалистичное поведение персонажей
>маня-фантазии девственника о том, как должны вести себя тян
Проиграл что-то.
Мои тян, как я хочу, то и реализм!
########
Быстрый экскурс в ГОАП дает такой алгоритм как видим по скрину, он не написан:
Каждый Персонаж обращается к гоапконтроллеру с просьбой "посчитай мне как добыть этот объект" (сейчас там только предмет).
1. Гоап контроллер оббегает все возможные экшены, которые дают предмет и те отвечают ему, возможно или нет и помещает все ответы "возможно" в массив.
2. Все ответы "возможно, но нужно ещё кое что" ищут аналогичным способом возможность найти это что-то ещё.
- Если найдено, то возвращаемся вверх по древу и проверяем ещё раз на поиск "чего-то ещё". Если все ок, идем далее вверх по древу.
- Если не найдено, то уничтожаем ветвь.
3. Берем ветку действия с минимальной ценой и это и есть ответ.
4. Регулируем веса переходов между действиями в зависимости от характеристик персонажа, чтобы получить разнообразные характеры.
########
Предлагаю завести Твиттер и срать отдельными предложениями туда, а здесь писать только развёрнутые мысли. Там ты и желающих поучаствовать больше найдёшь, и к Хуану приблизишься. Авось даже начнут ретвитить из-за того что ты именно на Godot делаешь, а не на каком-нибудь мейнстримном движке. Не забывай срать #тегами и @тегать нужных людей.
Тегнул.
По коду со скриншота:
1. Зачем предупреждения заглушаешь?
2. Отделяй ":" пробелом от последующих слов.
3. "->", по-моему, нужно окружать пробелами.
4. Поменяй GOAP на Goap, капс плохо читается.
Последнее не я придумал, читал в каком-то стайл гайде, но ссылку сейчас точно не найду - не помню вообще, чего это касалось. Суть в том, что капс лучше использовать только для констант, а длинные аббревиатуры (2+ символов) в именах всего остального писать как одно слово.
А то сейчас у тебя такая каша:
>ЖОАПА ктион Селект
>ЖОАПА ктион Пеймент
>ЖОАПА ктион Вейт
>ЖОАПА ктион Ворк
Аж глазам больно на эти ЖОАПЫ смотреть.
По алгоритму ничё сказать не могу, слишком абстрактно)
>По коду со скриншота
5. Названия функций GDScript должны быть в формате snake_case, а у тебя ЖОАПФинд() какой-то возник.
Алсо, почему код в репозитории давно не обновлял?
Хорошо бы какой-нибудь путеводитель по коду, что куда и зачем... Я забулдился в каких-то странных коротких скриптах про какие-то операторы, для чего они нужны?
Обычный КемелКейс для названий классов. Для названий переменных юзаю сейк_кейс. Таков кодстайл в нормальных местах.
Код в репо давно не обновлял, потому что я все ещё на гоаповском алгоритме. Возможно я уже делаю что то не то, не совсем гоап, но ориентировочно будет работать. Пока спокойно строит планы вида:
- чтобы поработать нужно выбрать рецепт
- выбрали рецепт
- чтобы поработать нужны ресурсы
- найти ресурсы с помощью покупки/найти ресурсы скрафтив/украв/убив/
Операторы - это неожиданно паттерн токенизации для языков программирования. В конфиге мессаджей можно указывать условия для появления диалога, вот там на эти условия создаётся кондишен, который чекается при переборе сообщений. Выглядит как {@i:name} ==. 'Вася'. Кондишеном будет в этом случае equal, те сравнение и два операнда ({@i:name} и Вася), тк сравнение это бинарная операция. Где @i означает @ - персонаж, i - interlocutor, те собеседник. Это динамическая переменная которая меняется в зависимости от того, с кем ты в диалоге. Один операнд как ты понимаешь функция, другой константа.
>КемелКейс
По моим наблюдениям, чаще это называют PascalCase, а camelCase чаще упоминают при написании с маленькой буквы.
В любом случае,
https://en.wikipedia.org/wiki/Camel_case#Programming_and_coding
>Programming identifiers often need to contain acronyms and initialisms that are already in uppercase, such as "old HTML file". By analogy with the title case rules, the natural camel case rendering would have the abbreviation all in uppercase, namely "oldHTMLFile". However, this approach is problematic when two acronyms occur together (e.g., "parse DBM XML" would become "parseDBMXML") or when the standard mandates lower camel case but the name begins with an abbreviation (e.g. "SQL server" would become "sQLServer"). For this reason, some programmers prefer to treat abbreviations as if they were lowercase words and write "oldHtmlFile", "parseDbmXml" or "sqlServer". However, this can make it harder to recognise that a given word is intended as an acronym.
>In terms of camel-cased identifiers, this has a greater impact on identifiers that include short words and especially acronyms. For example, consider the acronym ID found in the identifier kIOuterIIDPath. Because of the run of uppercase letters, the task of reading kIOuterIIDPath, in particular the identification of the word ID, is more difficult.
Короче, предлагаю писать Goap в названиях классов и goap в названиях функций, так проще воспринимать код. Хотя ладно, твоё дело...
>для названий классов
Так у тебя там PascalCase в ключах Dictionary. Я использую snake_case в ключах... Погоди, ты чего, потом будешь все эти ключи по именам сравнивать с именами классов? Это же строки. Ты ИИ пишешь для симуляции целого города, а не для умного чайника, тебе нужно выжимать максимум ресурсов из компьютера, не загружая его работой со строками. Нужно использовать максимально эффективные структуры и по возможности избегать строк.
>{@i:name} ==. 'Вася'
А зачем тебе такой код писать? Ты хотя бы экономику отладь, а диалоги можно и не делать вообще, сделать как в майнкрафте чисто менюшками, как будто за глухонемого играем.
Похуй, значит PascalCase.
> и по возможности избегать строк.
В диктах лежит GDScript. Соответственно это просто ссылка 8 байт, которую я буду сравнивать с другими ссылками по 8 байт. Кстати, инта в годоте тоже 8 байт. Это не строки.
> А зачем тебе такой код писать?
Код такой нужно писать для динамических диалогов.
>ссылки
Ясно, не знал, что так можно.
>динамических диалогов
Статические/вручную составленные примеры диалогов уже есть? А то без подробных тестовых образцов делать парсер с интерпретатором бесполезно, потом обязательно обнаружишь какие-нибудь недостатки или баги и придётся снова всё переделывать.
Собственно, хочется посмотреть, какие диалоги ты собираешься реализовать, как они для игрока будут выглядеть.
>на игровом движке Godot
> для любителей квестов и визуальных новел
Защо? Много квестов и визуальных новел на годоте люди делают?
> Ближайший аналог - Валет Плетей, но с более "реалистичным" миром.
Читал маняфантазии автора Валета Плетей по поводу его magnum opus Туманы Вечного Рима? Вроде идея та же, направление ты какое другое выбрал.
Да, маняфантазии Хантера. Но это все маняфантазии, и им надо передать логичность и гемплей, а не броски кубов.
На самом деле на годоте адекватно можно делать только квесты и визуальные новеллы (см Депонию). В остальном пока что там шейдеры так напилены криво, что нормальную графику там не сделать. Большие, реально большие игры тоже нет, так как типы гдскрипта не позволяют. Возможно на шарпе, но там тоже будут трудности с ними.
Там есть пример в конфиге простенький.
По сути динамичностб диалогов задаётся переменными.
Например:
- Привет, друг!
- Уга-Уга! (Орк = тру)
- Освободи попугая! (Пират = тру)
- Ударить ножом (в инвентаре ножей >0)
И на каждую фразу диалога можно написать с десяток разных фраз с разными условиями.
Ты скажешь, но это не полная генерация и в конце концов найдется два персонажа, которые будут одинаково разговаривать или фразы будут абсолютно похожи. Да, это так. Но это можно скрыть либо объемом текста, либо отсутствием текста, либо эффектами.
Отсутствие текста - это простой вариант, где персонаж показывает тебе 10-15 заданных эмоций, желательно милых, и ты придумываешь что ему не нравится. Короче эффект котика. Для игр с симами пойдет, для игр сюжетных не пойдет.
Объем текста - это вариант для упорных, т.е. забить несколько тысяч (на самом деле сотен) фраз на фразу привет и ни один игрок не встретится с похожей фразой.
Эффекты текста - это дополнительное средство. Кто то может пропевать слова и вы в тексте проооопеваете их, дублируя гласные. Кто то в конце всегда добавляет "пупсик", кто то шипелявит или шипит или проглатывает буквы или переставляет слова в тексте по алфавиту. Все это легко кодируется и является по сути множителем количества фраз.
>Много квестов и визуальных новел на годоте люди делают?
Нет желающих @ нет и игр.
А чтоб желающие были, нужен агрессивный маркетинг, чтобы перебить агрессивный маркетинг юнити (её уже даже в мобильных гиперкизуальных ассетфлипах рекламируют - типа "приходите делать игры, у нас скидки на ассеты").
>Депония
Разве она имеет отношение к Godot? У неё какой-то свой движок. Даже если там внутри и есть куски Godot, то это была какая-то очень древняя версия движка, 2012 год же.
>шейдеры так напилены криво
Тебе лень свои написать?
>типы гдскрипта не позволяют
А с ними-то что не так?
>- Привет, друг!
>- Уга-Уга! (Орк = тру)
>- Освободи попугая! (Пират = тру)
>- Ударить ножом (в инвентаре ножей >0)
Ну... Неплохо, наверное. Но я бы рекомендовал вместо буквальных фраз писать конфигурацию по категориям:
Действие: [приветствие]
Реакция 1: [приветствие]
Реакция 2: [агрессия]
Реакция 3: [игнорирование]
А уже что будет приветствием - дело десятое. Просто все эти вариации фраз на самом деле лишь декорация, суть - в категории. Категории могут разворачиваться уже по параметрам, которые ты перечислил:
[желание прогнать]:
[гопник] - эээ, слыш, ушол с нашего района!
[пират] - рррр, прочь с дороги, сухопутная крррыса!
и т.д.
Во всяком случае, в своей игре именно такую систему диалогов планирую, хотя мне не нужно вариативности.
>это не полная генерация
Всё в порядке, полную генерацию можно только с помощью специально обученных нейросетей сделать. Естественные языки слишком сложны для осмысленной генерации текста вручную разработанными генераторами (проходил уже это).
>найдется два персонажа, которые будут одинаково разговаривать или фразы будут абсолютно похожи
В этом нет совершенно никакой проблемы. Реальные люди имеют, на самом деле, сильно ограниченный словарный запас, общаются часто по шаблонам и зачастую повторяют (неосознанно) фразы, которые услышали где-то. Дети вообще всё за родителями повторяют, если очень внимательно за собой наблюдать - заметишь, что твоё поведение как будто склеено из кусочков поведения твоих родителей, воспитателей, друзей и т.д. Абсолютно уникальных и независимых людей просто не существует, мы все склеены из распространённых кусочков, просто комбинация кусочков у всех разная и этих кусочков чрезвычайно много, вот и создаётся иллюзия "уникальности".
С шейдерами годота жду массивов и рекурсий. Без них сасао сглаживание не сделать.
По типам очевидно жду инт32/инт16, интовые вектора, позитив инты и типизированные массивы. Починку циклических зависимостей в ряде случаев. Ну и интерфейсы были бы не плохи, что уж там.
Депония имеет отношение к годот. Там просто дописали его опенсорс немного.
Что касательно неуникальности, то проблема игр в том, что как только ты видишь повторяющуюся фразу - ты знаешь где ты ее ранее в игре видел. А вот в случаях с реальными людьми, видимо их речь и тон делает фразы разнообразнее и это выглядит для нас новой информацией.
>интовые вектора, позитив инты и типизированные массивы
Да, это нужно. Но я бы предпочёл не готовые типы, а создание любых кастомных типов по тому же принципу, что в Pascal и Ada.
Примеры из Ada:
https://www.adaic.org/resources/add_content/standards/12rm/html/RM-3-2-1.html
>type Column is range 1 .. 72;
Это целочисленный тип, со значениями от 1 до 72.
https://www.adaic.org/resources/add_content/standards/12rm/html/RM-3-5-7.html
>type Mass is digits 7 range 0.0 .. 1.0E35;
Это тип с плавающей точкой, до 7 значимых цифр, от 0.0 до 1.0Е35.
Ещё в Ada есть субтипы - они не требуют обязательной конвертации для присваивания друг другу, тогда как типы требуют обязательной конвертации (нельзя присвоить 1 float-у или 1.0 int-у, будет ошибка).
Но, конечно, строгая типовая система сложна в реализации и наверняка будет замедлять интерпретатор, т.к. придётся делать автоматические проверки на границы типа и т.д.
Ещё хотелось бы отдельную фичу для записей/структур, но как я понял, в GDScript для этого используют классы и никто на это не жалуется... ну и ладно, хотя записи/структуры быстрее и компактнее классов.
>ты знаешь где ты ее ранее в игре видел
Ну знаю и знаю. И что дальше?
>речь и тон делает фразы разнообразнее и это выглядит для нас новой информацией
Ах, если бы. Никакой новой информации. Дома я очень часто "слышу в голове" фразу, которую родственники скажут через секунду - это не телепатия и не ясновидение, просто тысячу раз уже слышал в похожих ситуациях. Т.е. в бытовом плане люди говорят одними и теми же фразами, просто потому что от них никто не требует говорить как-то иначе (программист требует от бота рандомно менять фразы). "Новую информацию" ты можешь получить только от незнакомого человека, но потом и он превратится для тебя в заезженную пластинку. Если внимательно за собой наблюдать - обнаружишь, что даже твои собственные мысли и фразы в той или иной мере повторяются из года в год. Люди просто не запоминают, что думают и говорят, если не ведут дневник или иные подобные записи.
Короче, нечего требовать от игровых ботов того, что сами люди толком не выполняют в реальной жизни. Игрок, погружаясь в мир игры, прекрасно осознаёт ограниченность ботов, и будет рад любой интерактивности вместо линейных сценариев, а полностью реалистичных диалогов от игр сегодня никто не ждёт (хотя уже были демонстрации с нейронками, но там бессмысленные чат-боты с 3Д аватаром в игровом мире).
gitlab.com/mdchs/dsystem/-/merge_requests/4/diffs
Вроде осознал дзен и допилил до чего-то работоспособного.
И так, моя версия ГОАП:
Существует 3 объекта, вокруг которых все крутится:
- Память
- Агент
- Экшн
Каждый экшн может вызывать другие экшены и самого себя.
Если экшн не может сделать действие, потому что ему чего-то не хватает (например предмета), он вызывает все экшены которые могут это дать.
Если эти экшены не асбстрактные (меняет данные в агенте), то в этот момент создается копия агента и памяти, и отправляется в этот экшен. Если экшен вернет успех, то копия превратится в реальную Память и Агента.
Если экшен абстрактный, просто вызываем действие и работаем с ним в своей памяти.
Что это позволяет делать:
- Выстраивать планирование по добыче какого-то объекта на огромные дистанции по действиям.
- Отсутствуют баги планирования вида:
1) Выбор из первого и второго действия. Первое действие стоит 10 единиц, для его реализации требуется действие за 15 единиц. Второе действие стоит 15 единиц. Т.к. выстраивается весь план, то цена будет посчитана полностью и выбреется второе действие.
2) Бот хочет создать супер-меч. Он собирает для этого реагенты. Для создания меча осталось пару действий, но его здоровье снизилось до 50% и он побежал лечиться и забыл о том, что делал супермеч. Планирование полностью выполняет свою функцию планирования - добычу какого-то объекта игрового мира.
Вроде осознал дзен и допилил до чего-то работоспособного.
И так, моя версия ГОАП:
Существует 3 объекта, вокруг которых все крутится:
- Память
- Агент
- Экшн
Каждый экшн может вызывать другие экшены и самого себя.
Если экшн не может сделать действие, потому что ему чего-то не хватает (например предмета), он вызывает все экшены которые могут это дать.
Если эти экшены не асбстрактные (меняет данные в агенте), то в этот момент создается копия агента и памяти, и отправляется в этот экшен. Если экшен вернет успех, то копия превратится в реальную Память и Агента.
Если экшен абстрактный, просто вызываем действие и работаем с ним в своей памяти.
Что это позволяет делать:
- Выстраивать планирование по добыче какого-то объекта на огромные дистанции по действиям.
- Отсутствуют баги планирования вида:
1) Выбор из первого и второго действия. Первое действие стоит 10 единиц, для его реализации требуется действие за 15 единиц. Второе действие стоит 15 единиц. Т.к. выстраивается весь план, то цена будет посчитана полностью и выбреется второе действие.
2) Бот хочет создать супер-меч. Он собирает для этого реагенты. Для создания меча осталось пару действий, но его здоровье снизилось до 50% и он побежал лечиться и забыл о том, что делал супермеч. Планирование полностью выполняет свою функцию планирования - добычу какого-то объекта игрового мира.
>создается копия агента и памяти
Представляю себе, какие лаги будут с более-менее большим числом агентов. Ты стресс-тесты проводил?
>Первое действие стоит 10 единиц, для его реализации требуется действие за 15 единиц.
Вообще-то ПЕРВЫМ будет действие за 15 единиц, а действие за 10 единиц получается вторым. Либо нужно обозначать это как действие за 25 единиц, если его нельзя выполнить по частям.
>Для создания меча осталось пару действий, но его здоровье снизилось до 50% и он побежал лечиться и забыл о том, что делал супермеч.
Ты тоже забудешь всё, что делаешь, и побежишь в больницу, если тебе отрубит руку каких-нибудь станком. Да даже если срать приспичит, ты побежишь срать, а не будешь доделывать начатое в куче собственного говна.
Если твои боты доводят все планы до конца несмотря ни на что - это неправильные, нереалистичные люди. ИРЛ люди всегда переключаются на экстренные задачи, и лишь после их решения возвращаются к менее важным. "Крафтить супермеч" должно иметь меньший приоритет, чем экстренное "заделать дырку в своём теле, из которой хлещет струя крови".
Алсо это не "баг планирования". Баг - это когда ты описал одно поведение (2+2=4), а на деле получается совсем другое (2+2=5). В твоём случае ты просто реализовал собственное видение поведения, которое отличается от общепринятого.
Лагов не будет, потому что нормальные люди используют пул объектов.
Что касательно действий за 15 единиц вначале или за 25. так дела не делаются. Предположим, у тебя задача:
- накопить 500 монет.
Есть пусть - пойти работать на дядю. - 15 единиц
Путь два - самому делать стулья и продавать. 10 и 20 единиц.
Ты предлагаешь не обсчитывать весь граф, а сагрегировать действие сделав его за 30 единиц. Но ведь если персонаж хочет посидеть, он тоже может сделать себе стул. На это тоже делать экшн? А ещё хочет подарить стул любимой бабушке - тоже отдельный экшн? В общем, логика с объединением действий мне не ясна.
Что касательно того, что первое действие стоит 15 единиц. Естественно нет. Я уже перевернул граф и читаю его задом наперед.
Что касательно механизма планирования. Важно разделять планирование и "желание" бота. Планирование - это построение маршрута до конкретного события, предмета. Выбор этого предмета - желание. Когда боту отрубит руку, он получит новое событие на желание (побежать в больницу), построит его план реализации (взять свою руку, сесть в такси, доехать до больницы, отдаться в руки врачу) и поставит этому плану высший приоритет и начнет выполнять это желание. Но не забудет о том, что чуть с более низким приоритетом у него есть крафт убер меча. Объединение этих двух функций в одну и делает игровых ботов такими тупыми. С тобой никогда не бывало, что бот видит врага, подбирает меч, а потом видя куст малины бросает меч на землю и берет серп, совсем забыв о противнике? В Скайрим не играл? Вот там примитивная версия гоапа, которую даже не замаскировали нормально.
>нормальные люди используют пул объектов
Ты сам-то читал что пишешь?
>в этот момент создается копия агента и памяти, и отправляется в этот экшен. Если экшен вернет успех, то копия превратится в реальную Память и Агента.
Т.е. даже если у тебя целая сотня резервных объектов в пуле создана заранее, тебе всё равно нужно время на копирование огромной кучи данных о конкретном агенте и его памяти.
>самому делать стулья и продавать. 10 и 20 единиц
Во время планирования данные два действия суммируются и воспринимаются как одно за 30, хотя и являются отдельными шагами, которые можно выполнять по отдельности, если нужно. Глупо говорить о "планировании", если твоё планирование видит только одно действие за 10, которое не ведёт к достижению цели, и сразу же выполняет его, не зная о существовании второго шага за 20.
>взять свою руку, сесть в такси
Это оффтоп, но ИРЛ нужно не просто "взять свою руку", а поместить её в холод: саму руку в чистый герметичный пакет, а этот пакет в пакет со льдом. Так выше шансы, что она не начнёт гнить до момента, когда хирург сумеет пришить её обратно. Хотя некоторые органы и ткани могут оставаться жизнеспособными до 2-3 суток после прекращения кровоснабжения... Если делаешь симуляцию млекопитающих, такие нюансы стоит учитывать. А, ну и не забыть наложить жгут на то место, из которого хлыщет кровь.
>С тобой никогда не бывало, что бот видит врага, подбирает меч, а потом видя куст малины бросает меч на землю и берет серп, совсем забыв о противнике? В Скайрим не играл?
Нет и нет. Но я некоторое время играл в Oxygen Not Included. Там нужно вручную настраивать приоритеты действий всем жителям, выбирать приоритеты задач... По ощущениям, мне так и не удалось справиться с управлением колонией. Боты зассали колонию мочой, ставишь высший приоритет на уборку мочи и объявляешь красную тревогу, а они вместо уборки мочи бегают по совершенно другим делам, игнорируя свою же ссанину. Я уж не говорю о том, что у меня каждая колония завалена мусором, который просто никто не хочет убирать в ящики, хотя ящики стоят буквально перед мусором и ничто не мешает взять и положить мусор в ящики - нет, нужно заниматься делами с пониженным приоритетом... А местный специально обученный на уборку дворник с монобровью делает что угодно, кроме уборки всего этого дерьма в ящики. Потом колония задыхается без кислорода...
Даже если у меня целая сотня объектов, память в оперативе уже выделена. Я просто копирую в ней данные. Как делается копия копия данных в оперативной памяти, я надеюсь ты знаешь.
Естественно подсчитывается сумма весов всех действий до результата. Но это все разные действия. И за первым действием может быть десяток действий вторых, а за каждым вторым ещё десяток. А так как действия меняют положение вещей у агента, то нужны копии агента для каждого случая. Мы можем говорить про оптимизацию, и что можно копировать не все данные, а в новом агенте иметь ссылку на старого агента и записывать только изменения. Но суть та же - для каждого действия - свой агент.
За установку приоритетов должен отвечать иной механизм, чем за планирование. Тогда все будет хорошо.
Сделан SoulsController и TaskTrackerController:
gitlab.com/mdchs/dsystem/-/merge_requests/5
Первый отвечает за нужды персонажа. Его цель - создавать суточные потребности всем персонажам.
Второй отвечает за обработку потребностей всех персонажей. Более того, объекты TaskTracker, которые он обрабатывает имеют возможность хранить несколько Task, поэтому задачи возможно откладывать и создавать из них цепочки.
Следующее обновление будет посвящено:
- полировке проекта
- исправлению мелких недостатков
- документации
После этого будет создаваться базовый контент чтобы:
- протестировать бизнеслогику продукта
- вытащить требуемый пользователю проекта функционал в конфиги
- продемонстрировать возможности функционала
Не стесняйтесь создавать issue на гитлабе или в треде по желаемому функционалу проекта или багам.
gitlab.com/mdchs/dsystem/-/merge_requests/5
Первый отвечает за нужды персонажа. Его цель - создавать суточные потребности всем персонажам.
Второй отвечает за обработку потребностей всех персонажей. Более того, объекты TaskTracker, которые он обрабатывает имеют возможность хранить несколько Task, поэтому задачи возможно откладывать и создавать из них цепочки.
Следующее обновление будет посвящено:
- полировке проекта
- исправлению мелких недостатков
- документации
После этого будет создаваться базовый контент чтобы:
- протестировать бизнеслогику продукта
- вытащить требуемый пользователю проекта функционал в конфиги
- продемонстрировать возможности функционала
Не стесняйтесь создавать issue на гитлабе или в треде по желаемому функционалу проекта или багам.
>действия меняют положение вещей у агента, то нужны копии агента для каждого случая
>действия меняют положение вещей
Почему меняют? И почему важно это изменение сбрасывать?
Просто представь как ты ИРЛ создаёшь 100% клона себя, смотришь как он делает работу. Если он фейлится - убиваешь его и стираешь себе память о нём. Если он делает всё успешно - убиваешь себя. Эффективное планирование, говоришь? Почему бы тогда просто не брутфорсить все задачи, клонируя персонажей прямо в игровом мире, чтоб они плодились и размножались, на каждую задачу по персонажу...
Не, я не спорю, возможно, это единственное рациональное решение, но просто звучит очень странно. Какой-то функциональный подход, где все переменные иммутабельны и нужно создавать новую каждый раз...
>или багам
А тестировать-то как?
Потому что когда персонаж покопал руду и положил это в инвентарь, он уже не текущий персонаж, а персонаж пошедший по копке руды. ПЕго отличие, что у него в инвентаре есть руда. Потом этот чувак делает себе меч и это уже другой чувак, у которого нет руды, но есть меч. Потом он убивает Рошана на МИДе. Если рошан убит, он говорит своему прошлому, что все ок, прошлое говорит другому прошлому и тд. А по другой ветке пошла история о том как персонаж этот меч украл и тоже убил Рошана. Потом берутся веса, выбирается меньшее и выполняем его в реальном мире.
Оптимизация присутствует в виде выбора изначально наивно дешёвого пути. Его вес запоминается и если что то весит больше, то оно скипается не досчитываясь до конца. Оптимизации по записи изменений пока не присутствует. Прежде чем оптимизировать, надо начать лагать.
Тестировать можно выкачав проект с гита, посоздавать персонажей в конфигах, посоздавать им профессии, посмотреть что срется в лог. Если тестировку вы видите иначе, сообщите об этом.
Полировка началась, но не закончена.
gitlab.com/mdchs/dsystem/-/merge_requests/6
- Изменение названий классов с окончанием Primary на окончание Data для
- Теперь считывание тэгов с конфига не зависит от пробелов до и после знака равенства (=).
- Новая константа &m обозначающая money.
- Теперь проверяется обязательность заполненности якоря для тега &m и @p
- Если какой-то предмет имеет якорь &m - он является платежным инструментом мира. Все цены перерасчитываются относительно его цены. Нельзя создавать заявки на аукцион для таких предметов.
- Qualities и Priorities приобрели собственные классы и валидацию при считывания из конфига.
- Появилась валидация первого символа Якоря (для персонажей - @, для предметов - &, для сообщений - М и т.п.)
- Убрана возможность продавать, покупать, закрывать заявки из глобального класса, т.к. они уже присутствовали в классе персонажа.
- Перенесена возможность узнавать цену предмета на рынке в класс предмета.
- Мелкие фиксы и переносы ответственности.
gitlab.com/mdchs/dsystem/-/merge_requests/6
- Изменение названий классов с окончанием Primary на окончание Data для
- Теперь считывание тэгов с конфига не зависит от пробелов до и после знака равенства (=).
- Новая константа &m обозначающая money.
- Теперь проверяется обязательность заполненности якоря для тега &m и @p
- Если какой-то предмет имеет якорь &m - он является платежным инструментом мира. Все цены перерасчитываются относительно его цены. Нельзя создавать заявки на аукцион для таких предметов.
- Qualities и Priorities приобрели собственные классы и валидацию при считывания из конфига.
- Появилась валидация первого символа Якоря (для персонажей - @, для предметов - &, для сообщений - М и т.п.)
- Убрана возможность продавать, покупать, закрывать заявки из глобального класса, т.к. они уже присутствовали в классе персонажа.
- Перенесена возможность узнавать цену предмета на рынке в класс предмета.
- Мелкие фиксы и переносы ответственности.
>покопал руду и положил это в инвентарь, он уже не текущий персонаж, а персонаж пошедший по копке руды
Так откуда руда берётся, если эта копия не в реальном мире действует, а просто рассчитывает вероятность завершения? Или ты гоняешь полную симуляцию, чтобы вычислить возможность выполнения задачи тем или иным путём?
Я хочу сказать, что ИРЛ люди не вычисляют полный путь до цели с точным определением успеха. Они пробуют, ошибаются, исправляют наделанное. В случае успеха стараются повторять действия, в случае неуспеха стараются избегать повторения действий. Конечно же, у нас есть воображение, с помощью которого мы можем довольно грубо смоделировать некоторые будущие события. Но никто не моделирует все свои действия на 10 шагов вперёд, не проживает мысленно следующую неделю с точностью до минуты. И тем более редко удаётся реально предугадать исход событий, потому что наше воображение никогда не имеет полной информации о мире и событиях, которые предстоят впереди.
Как человек в той же игре делает тот же меч? Он смотрит инструкции, видит там "для крафта меча нужна руда, руду можно добыть в пещере такой-то". Человек не знает, что ждёт его в пещере, не знает, сможет ли он реально скрафтить меч из той руды. Он просто идёт в пещеру и пробует добыть руду, потом пробует скрафтить меч. Если у него это получилось - он будет делать так каждый раз, пока не обнаружит случайно более короткий/дешёвый/эффективный маршрут.
Аналогично с кражей. Откуда человеку знать, удастся ли ему конкретная кража или нет? Может там вообще меча не будет, а будет какой-нибудь лук или щит. Или его поймают на краже, если в том месте окажутся стражники, о которых он заранее ничего не знает. В любом случае человек попробует украсть меч, и по результатам будет корректировать своё поведение - продолжать воровать как прежде, делать это по-другому или раз и навсегда покончить с воровством.
Вот это было бы реальной симуляцией человека. А у тебя сейчас боты действуют подобно шахматной программе, которая брутфорсит все возможные ходы, чтобы через брутфорс вычислить наилучший следующий ход. Проблем с таким подходом сразу куча:
- это не симуляция человека, это брутфорс;
- брутфорс всегда затратнее других алгоритмов;
- чем сложнее мир/правила игры, тем выше затраты на брутфорс и ниже вероятность быстро найти подходящий вариант.
Также с твоим планированием есть проблема неожиданных преград. Если по какой-то причине бот, выполняя "успешный" план, не сможет выполнить какой-то пункт, он, судя по всему, снова начнёт брутфорсить все варианты, чтобы найти альтернативу. Это усиливает нагрузку на систему, но самое главное - в реальном игровом мире это будет происходить регулярно, потому что и игрок, и боты будут друг другу мешать. И если ботов ты можешь сгруппировать так, чтобы они всегда всё знали друг о друге (что тоже неправильно с точки зрения как производительности, так и правдоподобности симуляции людей), то предсказать действия игрока и их последствия ты не можешь.
Или я неправильно понял твои конечные цели и тебя полностью устраивает и брутфорс, и все его особенности.
Я гоняю не симуляцию, а сохраняю результат каждого действия. Потому что если герой выучит рецепт ковки меча, он сможет сделать меч, а если не выучит - не сможет. И этот выбор аффектит другие последующие действия, которые может делать персонаж.
Планирование отличается от реального мира как раз таки тем, что после планирования до реальных действий прошло время. Соответственно, если мы хотим украсть меч, то во время кражи может случиться непоправимое - у персонажа уже не будет меча. Тогда придется уничтожить весь план и формировать новый.
Любое планирование в системах где из любого состояния можно перейти в любое всегда является брутфорсом в алгоритмизации на сколько мне известно. Тебе всегда надо будет оббегать почти весь граф для достижения результата. В моем подходе представлена оптимизация, о которой я писал выше, что позволяет проходить не все пути. То что ты говоришь о определенных действиях, которые персонаж запоминает - это является просто коррекцией весов графа. Это пока не сделано, но вполне реалистично.
Так же хочу отметить то, что твое утверждение о нагрузке на систему ничем пока ещё не подкреплено. Это мнимая нагрузка. В любой игре у тысяч объектов меняется свойство position по 60 раз в секунду и ничего не происходит. Здесь же будет 25 раз в 10минут обновлятся агент. И это без упарывания в оптимизацию.
Опрос:
Пытаюсь разработать новую систему конфига для сообщений, которая была бы понятна даже без профильных знаний или чтения документации. Хотя бы частично понятна.
Один вариант текущий, другой - свежий.
Если кто-то действительно хочет помочь советом, сейчас самое время.
Изменения в последнем коммите:
- ещё немного улучшена валидация чтения конфигов, а так же количество и качество ошибок.
- перенесен конфиг Порталов в конфиг Локаций. Это устраняет избыточность и упрощает редактирование конфигов.
- в рецептах появилась возможность указывать минимальный требуемый опыт для крафта, опыт за крафт и количество предметов полученных за один крафт. Боты учитывают эти параметры.
Пытаюсь разработать новую систему конфига для сообщений, которая была бы понятна даже без профильных знаний или чтения документации. Хотя бы частично понятна.
Один вариант текущий, другой - свежий.
Если кто-то действительно хочет помочь советом, сейчас самое время.
Изменения в последнем коммите:
- ещё немного улучшена валидация чтения конфигов, а так же количество и качество ошибок.
- перенесен конфиг Порталов в конфиг Локаций. Это устраняет избыточность и упрощает редактирование конфигов.
- в рецептах появилась возможность указывать минимальный требуемый опыт для крафта, опыт за крафт и количество предметов полученных за один крафт. Боты учитывают эти параметры.
https://gitlab.com/mdchs/dsystem/-/merge_requests/6
Добавил документацию прямо в код. Вроде везде, где возникали самые непонятные места. Хотя все это субъективно.
Я все ещё ожидаю помощи Анонима с формированием принципа конфига диалогов. Это необходимо для того, чтобы перейти к фазе наполнения контентом. Без этого получится, что после изменения парсинга конфига нужно будет переписывать весь конфиг, что множит работу в 2 раза.
Добавил документацию прямо в код. Вроде везде, где возникали самые непонятные места. Хотя все это субъективно.
Я все ещё ожидаю помощи Анонима с формированием принципа конфига диалогов. Это необходимо для того, чтобы перейти к фазе наполнения контентом. Без этого получится, что после изменения парсинга конфига нужно будет переписывать весь конфиг, что множит работу в 2 раза.
>2.png
Слишком много мешающегося бойлерплейта.
Простые диалоги растягиваются на несколько экранов.
>1.png
[[Частокол][][из][][квадратных][][скобочек]]
Что мешает просто использовать JSON? Код на 2.png внешне очень напоминает JSON. Тем более что в Godot уже есть встроенный импорт и экспорт JSON.
>понятна даже без профильных знаний или чтения документации
У тебя там дохрена @тегов, пока они есть, без документации этот код не понять. Можно только догадаться, что @p - это игрок, а @p:name - имя игрока. Всё-таки чаще в таких языках пишут целиком %player_name% или что-то в этом роде, если хотят сделать код понятным для переводчиков.
Да и сама структура вызывает сомнения. Отступы - это вложенные ветки диалогов? А если мне нужно сделать очень длинный диалог? Не могу же я делать стопицот отступов, чтобы потом разбираться, где же я неправильно отступил.
Да, отступы это ветка диалогов, их вложенность друг в друга, как конструкция if в питоне. Я пока придумал только такой вариант. Жсон все растянет в бок названиями переменных, а скролинга в бок ни у кого нет на мышке.
Про лес левых скобок я знаю, и уберу его. Это все и так понятно.
С тегами то все ясно, они пока есть в коде в controller/config.gd
Доку там обвяжу.
Как тебе такой вариант? Он выбирает лучшее из первого подхода и из второго.
Пока что не ясно с конфигом сообщений, делаю не менее важный мелкий функционал https://gitlab.com/mdchs/dsystem/-/merge_requests/6
Ченджлог:
- добавлена панель переходов между локациями и её функционал
- добавлены методы для работы с переходом между локациями
- поправлен баг с использованием класса LocationData место LocationCalled
- поправлены баги с дефолтными параметрами при обращении к GOAPAgent
- поправлен баг, когда персонаж игрока загружался место персонажа на локацию
- добавлен примитивный Dashboard для кнопок
Ченджлог:
- добавлена панель переходов между локациями и её функционал
- добавлены методы для работы с переходом между локациями
- поправлен баг с использованием класса LocationData место LocationCalled
- поправлены баги с дефолтными параметрами при обращении к GOAPAgent
- поправлен баг, когда персонаж игрока загружался место персонажа на локацию
- добавлен примитивный Dashboard для кнопок
Начал заниматься "Вещами" и Навигацией на сцене.
https://gitlab.com/mdchs/dsystem/-/merge_requests/6
Для того, чтобы расположить точки для персонажей или вещей в игре, требуется поместить в конфиг картинку с альфаканалом(?) и нарисованными внутри него прямоугольниками разного цвета.
На основании разных цветов будет подобран предмет, который располагается в комнате или будет создана пустая точка для появления персонажа. Размеры прямоугольника будут определять размеры камеры при старте диалога или действиях с этим предметом на этой сцене.
Если у вас есть идеи для ввода информации через конфиг получше - напишите об этом. Просто вводить координаты камеры, её размер и точку расположения предмета мне показалось полной залупой, когда гораздо проще нарисовать на отдельном слое эти квадраты прям над изображением и сохранить в папку.
Скорость обработки изображения около 44мсек с последующей выдачей всех цветов и координат Ректов. Можно ужать и до 30.
Ченджлог
- добавлен номер строки в ошибку при парсинге конфигов
- добавлена загрузка изображений персонажам, в комнату, вещам
- написана обертка над File в годот, позволяющая возвращать каретку к началу строки и всегда знать номер строки
- проверка наличия файлов png в конфигах
- добавлен класс Stuff под предметы, которые будут распологаться в комнате
- написан обработчик поиска квадратов в изображении
https://gitlab.com/mdchs/dsystem/-/merge_requests/6
Для того, чтобы расположить точки для персонажей или вещей в игре, требуется поместить в конфиг картинку с альфаканалом(?) и нарисованными внутри него прямоугольниками разного цвета.
На основании разных цветов будет подобран предмет, который располагается в комнате или будет создана пустая точка для появления персонажа. Размеры прямоугольника будут определять размеры камеры при старте диалога или действиях с этим предметом на этой сцене.
Если у вас есть идеи для ввода информации через конфиг получше - напишите об этом. Просто вводить координаты камеры, её размер и точку расположения предмета мне показалось полной залупой, когда гораздо проще нарисовать на отдельном слое эти квадраты прям над изображением и сохранить в папку.
Скорость обработки изображения около 44мсек с последующей выдачей всех цветов и координат Ректов. Можно ужать и до 30.
Ченджлог
- добавлен номер строки в ошибку при парсинге конфигов
- добавлена загрузка изображений персонажам, в комнату, вещам
- написана обертка над File в годот, позволяющая возвращать каретку к началу строки и всегда знать номер строки
- проверка наличия файлов png в конфигах
- добавлен класс Stuff под предметы, которые будут распологаться в комнате
- написан обработчик поиска квадратов в изображении
Забыл добавить. 4900 разных персонажей загружаются за ориентировочно 6 секунд. Это наверное довольно долго, хотя не думаю, что кто-то понапишет столько информации в конфиг.
>отступы это ветка диалогов, их вложенность друг в друга, как конструкция if в питоне
Насколько глубокие конструкции ты тестировал?
>Жсон все растянет в бок названиями переменных
Это если продолжать делать "как if в питоне". В JSON переносы строк и тем более отступы не являются обязательными. Хоть в одну строку весь код пиши. Но лучше в первую очередь избавиться от избыточной вложенности структур.
>скролинга в бок ни у кого нет на мышке
Вроде есть такие мышки, с наклоном колёсика вбок. А у меня драйвер мышки A4Tech имеет программную фичу: если скроллить в правой части окна, скролл будет не вертикальным, а горизонтальным, это очень удобно и много где помогает. Но с кодом всё куда проще, в текстовом редакторе можно нажимать home/end для быстрого перехода в начало/конец строки и ctrl вместе со стрелочками для быстрого перехода курсора по словам (ctrl+-> - следующее слово, ctrl+<- предыдущее слово, попробуй, очень удобно).
>Как тебе такой вариант?
По-прежнему куча непонятных тегов и значимых отступов. Что случится, если пользователь потеряет отступ? А если допустит незаметную ошибку в теге?
Вообще, я бы лучше делал процедурную генерацию диалогов, она должна лучше сочетаться с симуляцией жизни. У тебя пока что я вижу только что-то уровня диалогов NPC из РПГ игр, которые нужно полностью вручную записывать. В результате вместо
>Реалистичное поведение персонажей
получатся те же болванчики, что есть в тысячах РПГ. Ничего реалистичного в таких ветках диалогов нет.
Что касается формата описания простых разветвлённых диалогов, то тут лучше обратиться к классическим текстовым играм и их движкам. Я в них особо не разбирался, но движков для текстовых игр много и они должны иметь достаточно удобный синтаксис. Сам я пробовал писать движок для интерактивной книги, получилось что-то типа этого:
#страница текст
@страница ответ
Где вместо "страница" пишется номер страницы. Формат очень простой и не предполагает никаких условий: ты просто выбираешь свой ответ и движок отображает страницу с соответствующим номером. На базе этого легко написать интерактивную книгу, где есть только развилки (без инвентаря, предметов и т.п.). Намного позже я пробовал делать сложную тестовую игру-симуляцию, но описывал мир прямо в коде, быстро запутался и забил на тот проект.
Блин, ты совершенно не описал будущий геймплей, из-за чего я долго не мог понять, о каком изображении идёт речь и зачем его как-то размечать прямоугольниками. Так бы и сказал с самого начала, что делаешь поинт-н-клик квест с диалогами. А то я ломал голову, то ли у тебя текстовый квест, то ли 2Д с видом сверху как в РПГ...
Ты регулярно отчитываешься о куче нововведений в коде (в которые, мне кажется, никто не вчитывается), но не показываешь ничего визуального. Неужели нечего показать? Тем более раз ты делаешь основу для графического квеста и уже даже изображения размечаешь.
>идеи для ввода информации через конфиг получше
Т.к. делаешь на Godot, решение очевидно, странно, что ты сам не додумался: делаешь tool скрипт, который позволяет разметить прямоугольники поверх изображения в 2D редакторе, потом автоматически сохраняет их в JSON или в свои параметры, которые сохраняются в tscn. Это намного удобнее рисунков, т.к. не нужно опираться на внешний редактор, нет риска неправильного распознавания (случайно закрашенные пиксели, сглаживание и т.п.), гораздо более компактное хранение данных, очень быстрая загрузка и т.д. К тому же количество данных не будет зависеть от разрешения размечаемого изображения. Всегда старайся делать утилиты, подходящие инструментам, с которыми работаешь, чтобы не было кучи костылей. А то у тебя и свой формат вместо встроенного JSON, и теперь вот зачем-то распознавание прямоугольников на картинке (надеюсь, не с помощью нейросети, лол?), когда можно во встроенном редакторе всё визуально разметить... Ты вообще Godot открываешь, или прям так в блокноте код пишешь?)
Я сделаю возможность ссылок и все будет норм. Условно говоря ты где то описал якорь М50 и потом можешь сувать его как переменную в любой диалог.
Мне приходится делать поинт энд клик квест. На самом деле у меня просто разбивка по комнатам. В комнате могут быть предметы, персонажи. Это может быть и 3д и 2д. Я хотел сделать красивое 3д внутри, но тогда комьюнити будет сложно развивать проект собственными доработками.
Что касаемо "размечаю в движке годот". Вот скачал ты экзешник моей игры. Рядом папка конфиг и ссылка на всякие файлы в нем. Поиграл в игру. Хочешь сделать свою локацию или персонажа. И что, качать годот?
>разбивка по комнатам
Почему не тайловый 2D опенворлд?
>комьюнити будет сложно развивать проект
Если сравнивать большие картинки-фоны из квестов и 2D тайловые карты из ретро РПГ, то тайловые карты в разы проще и создать новую может любой новичок, а для картинки-фона нужно быть художником или заказывать у художника.
>И что, качать годот?
А в чём проблема? Годо - не юнити и не уе: весит очень мало, работает на любом компьютере и даже в браузере (и даже на смартфонах, тестовые билды давно есть, хотя неудобные и глючные), для использования не нужно нигде регистрироваться или платить. Даже в официальном руководстве есть рекомендации по поддержке модов - предполагается, что моддеры будут использовать Годо. К тому же тебе никто не мешает включать редактор Годо в комплект своей игры, MIT лицензия это позволяет. Не вижу никаких проблем. Тем более что моддеры - не простые игроки, они привыкли к трудностям и для них освоение Годо будет наименьшей из проблем.
>Хочешь сделать свою локацию
Чтобы создать свою локацию для графического квеста, сначала её нужно нарисовать. Повторюсь, для этого нужно быть художником, иначе получится говно. Тем более если ты хочешь чтобы новая локация была похожа на имеющиеся - далеко не каждый художник сможет "попасть" в заданный стиль. Вот если бы ты делал тайловые карты, тут было бы меньше проблем - моддер мог бы использовать уже имеющийся тайлсет для создания новых карт/комнат, примерно как на РПГ Мейкер. Кстати! Для создания тайловых карт совсем не обязательно использовать Годо, есть, например, редактор Tiled: https://www.mapeditor.org/ - я видел ассеты для импорта карт из него в Годо. Т.е. можно предложить игроку создать карту в Tiled, это должно быть проще, чем разбираться в Годо. Или можно даже сделать внутриигровой редактор тайловых карт, это не так уж сложно...
По МР https://gitlab.com/mdchs/dsystem/-/merge_requests/6
Ченджлог:
- исправлено неправильное определение номера позиции ошибок в ряде случаев
- добавлены "точки" в локацию
- добавлена поддержка Stuff в локации
- в зависимости от того, на какой персонаж точке, его анимация меняется в зависимости от stuff
- переписан парсер сообщений
- поправлен интерфейс диалога (его верстка)
> Почему не тайловый 2D опенворлд?
Потому что я не хочу делать опенворлд. Да и тайловый опенворлд сам по себе подразумевает комнаты.
Для того, чтобы вставить картинку-фон, нужно спереть её с гугла. Для того, чтобы вставить персонажа - надо спереть его с гугла, вырезав альфаканалом.
Редактор тайловых карт мне не интересен, т.к. я не делаю данжен кроулер.
> А в чём проблема?
В том, чтобы качать какую-то приложуху, очевидно же. Но в одном ты прав, конфиги надо генерить самому для того, чтобы увеличить скорость парсинга. Т.е. убрать валидацию. Но для этого требуется под каждый конфиг написать собственную приложуху по созданию персонажей/локаций/предметов и т.п, которая при сохранении будет засовывать все файлы и т.п. в нужные места. Для тех, кто поумнее, есть гит и открытый код.
Ченджлог:
- исправлено неправильное определение номера позиции ошибок в ряде случаев
- добавлены "точки" в локацию
- добавлена поддержка Stuff в локации
- в зависимости от того, на какой персонаж точке, его анимация меняется в зависимости от stuff
- переписан парсер сообщений
- поправлен интерфейс диалога (его верстка)
> Почему не тайловый 2D опенворлд?
Потому что я не хочу делать опенворлд. Да и тайловый опенворлд сам по себе подразумевает комнаты.
Для того, чтобы вставить картинку-фон, нужно спереть её с гугла. Для того, чтобы вставить персонажа - надо спереть его с гугла, вырезав альфаканалом.
Редактор тайловых карт мне не интересен, т.к. я не делаю данжен кроулер.
> А в чём проблема?
В том, чтобы качать какую-то приложуху, очевидно же. Но в одном ты прав, конфиги надо генерить самому для того, чтобы увеличить скорость парсинга. Т.е. убрать валидацию. Но для этого требуется под каждый конфиг написать собственную приложуху по созданию персонажей/локаций/предметов и т.п, которая при сохранении будет засовывать все файлы и т.п. в нужные места. Для тех, кто поумнее, есть гит и открытый код.
По МР https://gitlab.com/mdchs/dsystem/-/merge_requests/6
- пофикшен баг когда не учитывалося параметр INTERACTION у Stuff
- Теперь предметы имеют изображение и ссылаются на тайл-мапу в конфиге
- Поправлен парсинг сообщений, функций и условий. Добавлены ошибки, если таковые возникают.
- Парсинг сообщений стал гораздо проще
- Парсинг сообщений стал поддерживать создание ссылок на сообщения
- Добавлена визуализация инвентаря.
- пофикшен баг когда не учитывалося параметр INTERACTION у Stuff
- Теперь предметы имеют изображение и ссылаются на тайл-мапу в конфиге
- Поправлен парсинг сообщений, функций и условий. Добавлены ошибки, если таковые возникают.
- Парсинг сообщений стал гораздо проще
- Парсинг сообщений стал поддерживать создание ссылок на сообщения
- Добавлена визуализация инвентаря.
Для интересующихся дравколами. Годот делает 11 дравколов на этой восхитительной картинке при открытом инвентаре!
А я напомню, что пасфайндер в таком случае (при открытом инвентаре) делал огромные пропуки. Сказать вам какой движок у пасфайндера?
>при открытом инвентаре
>огромные пропуки
Пропуки в инвентаре могут быть по массе разных причин, не зависящих напрямую от рендерера или числа дроуколлов. Игре может быть нужно подгрузить какие-то данные (с диска или с сервера), вычислить какие-то значения, сгенерировать спецэффекты и т.д. Разумеется, хороший разработчик оптимизирует открытие меню инвентаря насколько сможет, но игры делают не только программисты и часто доступа к хорошему разработчику у команды разработчиков просто нет, а желание сделать игру - есть. Так что нет смысла винить игровой движок общего назначения в том, что какая-то команда разработчиков ниасилила сделать быстрый интерфейс инвентаря в своей игре.
К тому же, ты делал стресс-тесты своей реализации? У тебя там всего 3 предмета, явно без каких-либо параметров и спецэффектов, пока что просто неоткуда взяться пропукам (у меня 3D сцена в Годо на 10к+ дроуколлов не "пукает", что уж говорить о твоих квадратиках).
Демонессу сам нарисовал или украл из интернетов?
Слушай, поскольку ты явно хочешь сделать эротическую игру, предлагаю тебе задуматься о Live2D: нужен либо линк с оригиналом, либо эмуляция средствами Годо. Статичными картинками сегодня уже никого не удивишь, статичные анимации тоже вызывают мало интереса, а вот процедурные/интерактивные анимации - это топ, всем 2Д визуальным новеллам/графическим квестам/симуляторам свиданий нужно, ящитаю. Насколько мне известно, Live2D портирована в Unity и вроде бы даже Ren'Py (не уверен), а вот про Godot ничего не слышал. Единственная проблема, Live2D - платный проект с закрытыми исходниками, было бы идеально написать опенсурс реализацию подобной штуки, хотя бы очень простую.
Если интересно как работает Live2D: там по факту не 2D, а полноценный 3D рендер - трёхмерные плоскости с натянутыми фрагментами аниме-тянки движутся в пространстве кодом, что создаёт эффект подвижной плоской картинки с соответствующими искажениями. Работает, к сожалению, только для отдельных ограниченных ракурсов, но, тем не менее, выглядит шикарно.
Я и сам несколько лет планировал этим заняться, но рисую я до сих пор криво (потому что редко пытаюсь, опыта мало), да и просто лень, там слишком много разных фич нужно поддерживать. Однако эта технология за последние годы стала очень популярна, особенно благодаря витуберам, так что будет плюсом для любой 2D игры.
Мое решение выдержит и миллион предметов в инвентаре. Это не проблема. Но так как в игре не будет миллиона предметов, я даже это тестить не буду. Помню в 3.3 делал через панельки или кнопки инвентарь, пропукивало на 50 панельках. Как в пасфайндере.
Демонесу рисовал сам. Но выглядит она конечно ещё херово.
Что конкретно live2d, то меня пугает лишь то, что конечный пользователь не сможет модифицировать продукт контентом, тк реализация слишком сложна от "украл картинку с Гугла".
В общем, если ты разработаешь приложение на гдскрипт, которое генерит такие модели, мой проект может поддерживать твою технологию.
Как я ее вижу:
- пользователь загружает изображение многослойного персонажа.
- пользователю на загрузку изображения генерируется много плоскостей.
- пользователь может:
A) Вращать их по осям х,y
Б) Перемещать по осям х,у
В) Привязывать слои друг другу
Г) Выставлять их позицию по z для z-index.
Вышеназванными действиями он может пользоваться, чтобы создать трек анимации.
После он сохраняет модель, перекладывает в папочку игры.
Для считывания сохраненного файла нужно разработать модуль, который восстанавливал бы плоскости и создавал animation player с анимациями пользователя.
В принципе все. Это готовый конечный продукт, который даст примерно ту же самую картинку что и лайф2д.
Ориентировочное время на разработку 1 месяц.
>реализация слишком сложна от "украл картинку с Гугла"
Я не понимаю, зачем ты ориентируешься на тех, чей предел - это "украсть картинку с Гугла". Они тебе донатить не будут и вообще даже не упомянут тебя, если сделают и релизнут свою игру на основе твоей. А просто так для самого себя... Кому это вообще нужно? Школоте какой-нибудь, фотки порноактрис в игру вставлять? Странно ориентироваться на такую ЦА.
Более того, я уверен, большинство вообще не захочет ничего никуда вставлять. Поиграют в базовую версию игры и удалят. Те же, кто захочет допиливать твою игру собственным напильником, будут не против осваивать необходимые инструменты и технологии. Но чтоб такие желающие нашлись, аудитория должна быть сильно больше 3.5 анонов. Намного чаще люди используют готовые моды, если их достаточно просто найти и установить.
>animation player с анимациями пользователя
>ту же самую картинку что и лайф2д
Преимущество Live2D - интерактивность. Персонажи следят за касаниями/курсором, реагируют на жесты и т.д. Это не простые анимации. Также я погуглил эту тему - основным компонентом служит 2D меш, который в Годо хоть и есть, но пока создаётся лишь через код, т.е. потребуется делать свой редактор мешей.
>Ориентировочное время на разработку 1 месяц.
Лол, я если и буду делать что-то подобное, то только для себя/своего проекта, без дедлайнов и лишних зависимостей. Была как-то мысль совместить грубые 3D модельки с 2D аниме-интерпретацией...
3D сильно отличается от 2D. Очень сложно добиться желаемой стилизации в 3D. Вот, что говорят об этом разработчики Live2D: https://youtu.be/YrLnF7CQ8Ac
Поэтому я тебе и предложил создать инструмент на годо для сборки моделек аналогичных life2d. Я готов вместе с приложением поставлять редакторы файлов конфигов, если они просты и удобны. Россказни про аудиторию которая вставляет картинки слишком преувеличены. Ты отсекаешь огромный пласт игроков гуманитариев, которые хотят писать диалоги, а не заниматься всем этим моделингом.
Я согласен, что есть ещё версия с 3д и я ее рассматриваю. Но делать какие либо модели это довольно трудозатратно. Я подумаю о том, чтобы изменить 2д на 3д через пару десятков продуктовых циклов проекта. Данные с интерфейсом у меня конечно разнесены, но я то один.
Кажется рисовать у меня начало получаться лучше
Добавлен лучший стул в игровой индустрии.
А вообще, мр https://gitlab.com/mdchs/dsystem/-/merge_requests/6 слит. Основные правки которые я хотел сделать на этой итерации - сделаны. Возможно, даже большие, чем планировалось.
Надеюсь всем была удобна документация в коде.
Теперь переходим к стадии создания базового контента.
Результатом этой стадии будет обучающая миссия для игра. Будет необходимо соблазнить персонажа с помощью диалоговой системы. В рамках этой стадии я должен буду написать всю игру на своих конфигах, а что не сможет быть реализовано через конфиги, реализовать так, чтобы могло быть реализовано через конфиги.
А вообще, мр https://gitlab.com/mdchs/dsystem/-/merge_requests/6 слит. Основные правки которые я хотел сделать на этой итерации - сделаны. Возможно, даже большие, чем планировалось.
Надеюсь всем была удобна документация в коде.
Теперь переходим к стадии создания базового контента.
Результатом этой стадии будет обучающая миссия для игра. Будет необходимо соблазнить персонажа с помощью диалоговой системы. В рамках этой стадии я должен буду написать всю игру на своих конфигах, а что не сможет быть реализовано через конфиги, реализовать так, чтобы могло быть реализовано через конфиги.
Красиво, но подучи анатомию. Даже если она монстро-девочка, с таким длинным животом (промежуток между грудной клеткой и тазом) она скорее всего сложится пополам или будет иметь серьёзные проблемы с позвоночником.
Почитал README - всё описано лучше, чем здесь, молодец.
>отсекаешь огромный пласт игроков гуманитариев, которые хотят писать диалоги, а не заниматься всем этим моделингом
Для таких нужен генератор персонажей. Для генератора персонажей нужно нарисовать или смоделировать большое количество "запчастей": туловища, головы, глаза, рты, носы, уши, причёски (цвет можно настраивать свойством modulate CanvasItem или albedo SpatialMaterial), множество частей одежды и прочее. С помощью генератора ты можешь процедурно генерировать всех персонажей или позволять игроку вручную настроить каждого персонажа в его городе. Конечно, 2D накладывает ограничение на генератор - все персонажи будут в одной позе и в одном ракурсе, т.к. для каждой позы и каждого ракурса нужен свой набор спрайтов. Но в любом случае это позволит любым "гуманитариям" в пару кликов создать собственного персонажа - или, если точнее, смоделировать своего оригинального персонажа (ОС) в твоей игре. Такая функция намного ценнее простой возможности вставлять статичные картинки. В качестве референса поищи различные игры жанра "одевалки", а также "генераторы персонажей" (это почти одно и то же).
>модели это довольно трудозатратно
Существует множество генераторов 3D персонажей, некоторые из них бесплатны. Если ты предпочитаешь аниме-стиль, тогда попробуй, к примеру, это:
https://vroid.com/en/studio
https://youtu.be/2gfEpSW-pvw
https://store.steampowered.com/app/1486350/
Эта программа ориентирована на 2D художников и позволяет создавать 3D персонажей без изучения 3D пакетов. Модели можно бесплатно использовать в том числе в своих играх. Подробности я пока не изучал (лень было, депрессия и желание всё делать с нуля без посторонней помощи), но отзывы у неё крайне положительные. Помимо прочего модели из неё используют для V-туберов, так что использование моделей из неё как бы сразу поднимает твою игру на один уровень с современными онлайн-идолами... если тебя привлекает популярность и всё такое.
Ну и, естественно, полноценную 3D модель будет намного проще использовать на Godot, чем реализовывать свой инструмент типа Live2D. Да, конечно, у Live2D много преимуществ... но в условиях ограниченных возможностей 3D из генератора всё же намного доступнее. Главное не бросай практиковаться в рисовании, это тоже пригодится в любом случае (у опытного 2D художника преимущества в 3D по сравнению с теми, кто совсем не умеет рисовать).
Да, я знаю. Ещё мне не нравятся толстые линии. Но пока не знаю как от них уйти, тк рисую мышкой.
Про генераторы персонажей я так же в курсе. Но это огромный пласт работ. Сейчас моя цель протестировать и доработать базу кода, которая написана ранее. Рисовать объекты я начал только чтобы самому было приятно видеть демку, ну и потому что после работы мозг отказывался думать на тех часть.
В дальнейшем это все выпилится. Я все ещё надеюсь, что смогу перейти в 3д, потому что тогда будет возможность давать игрокам бродить по "комнатам" и все щупать на более интересный манер.
Ну я явно могу заявить, что слои работают, привязка персонажа к точкам тоже.
Так, я считаю, что это просто идеальная покраска. А вот с лицом че-то не вышло.
Как минимум, потому что глаза у людей не занимают 75% ебла.
Тут глаза занимают максимум 10%. С этим вроде все норм.
>мне не нравятся толстые линии
А мне наоборот, нравятся. Люблю контурные рисунки.
>не знаю как от них уйти, тк рисую мышкой
Создаёшь холст раза в 4 больше необходимого, рисуешь как получится, потом сжимаешь до заданного размера. Все мелкие ошибки станут незаметны или полностью пропадут. Это как отойти от картины на расстояние и перестать различать отдельные мазки.
>В дальнейшем это все выпилится
Жаль, лучше оставь под свободной лицензией CC, вдруг кому-нибудь пригодится.
>надеюсь, что смогу перейти в 3д
Если тебя удерживает только сложность создания персонажей, что мешает использовать вместо них плейсхолдеры или уже готовых бесплатных персонажей (в т.ч. из генераторов)? Статичные объекты (мебель и т.п.) в 3D делать одно удовольствие.
>с лицом че-то не вышло
Слишком вытянутое в области носа - глаза на лоб лезут, при том что голова наклонена вперёд - лоб должен выглядеть больше, чем анфас. Глаза разной формы ещё, но по моему опыту форма и симметрия глаз не так сильно важна, как базовые пропорции лица, потеряешь пропорции - получится или инопланетянин, или человек с тяжёлыми мутациями. Ориентируйся на пикрил и вообще почаще поглядывай на чужие качественные рисунки в желаемом стиле.
Меня останавливает то, что все остальные проекты я релизил в 2д. Плюс надо найти качественные 3д модели. Плюс пока не ясно как подстраивать высоту персонажа в 3д под рост другого персонажа. Короче этим надо сидеть и отдельно заниматься. И если в 2д я отрисую это довольно быстро (уже 2 персонажа готовы, осталось пару локаций с объектами) в тч где то через неделю у меня будет приятный глазу полный графический прототип, то с 3д я даже не знаю сколько буду парится с тем, что вид плейсхолдера меня раздражает.
Все графические файлы лежат в Гите. Если вдруг когда-то случится фазовый переход в 3д, то под все файлы выложу Фотошоп версию.
Что касаемо холста в 4 раза больше, то я так и делаю. Но все равно пока что выходят неудачные решения. Хотя для 4 персонажа которого я в жизни рисовал, думаю другого результата ожидать не стоит.
В общем ладно, поглядим что будет. Сейчас важно доделать минимальную графику, потом начать пилить диалоги, окажется что не хватает десятков функций и возможностей, их допиливать, параллельно думать о системе постельных сцен и боевой системе. Это явно будет не тупое закликивание, я такое не люблю. Вероятно успешно завершить постельную сцену в игре будет сложнее, чем завести женщину в реальной жизни
Вроде лицо поправил. По крайней мере оно не так сильно меня раздражает. Вот вещи ещё не получаются. Все эти складки и текстуры надо делать как-то иначе, нежели моим кривым способом.
осталось с мужскими ногами чото сделать
А чем мужские ноги от не мужских отличаются? Видишь - чулочки ведь есть!
они немного понежнее и менее волосатые
>как подстраивать высоту персонажа в 3д под рост другого персонажа
Эмм, что? В 3D используются единицы измерения. В Godot единица измерения равна одному метру. Если у тебя персонаж ростом 160 см, он будет ростом 1.6 единиц. В Блендер точно такая же система измерения, так что с экспортом Блендер -> Годо проблем нет. Если ты нашел где-то модель, которая ростом, скажем, 3 единицы (3 метра), то есть два основных способа:
1. В Блендере отмасштабировать (хоткей S) модель так, чтобы она была желаемого роста (на панели по хоткею N будут размеры модели под надписью Dimensions, рост - это Z). Потом можно применить масштаб - хоткей ctrl+A -> Scale. Применение масштаба возвращает масштаб модели к (1;1;1), смещая все вершины меша. Если масштаб не применять, после экспорта в Godot в поле Transform масштаб будет отличаться от единичного.
2. Можно прямо в Godot изменить масштаб импортированной модели через поле Transform - Scale. Главное чтобы значения всех осей были одинаковыми. Рост - ось Y. В Godot нет автоматического отображения габаритов, можно только по bounding box из кода узнать габариты, но это не точно (я не проверял). Так что просто поставь рядом две модели - одну с точно известным размером и другую неправильного размера - и подгоняй Scale.Y неправильной модели под правильную на глаз. Короче, лучше прямо в Blender всё сделать...
>Хотя для 4 персонажа которого я в жизни рисовал, думаю другого результата ожидать не стоит.
Для такого маленького опыта и работы мышкой у тебя очень хорошие результаты. Некоторые годами рисуют уродцев даже с графическим планшетом и десятками/сотнями сделанных рисунков, а у тебя с самого начала вполне неплохо... если не срисовываешь (копирование - отдельный навык, копировать обычно намного проще, чем рисовать, некоторые с самой первой попытки неплохо копируют чужое, но это не помогает им рисовать самостоятельно).
>Вероятно успешно завершить постельную сцену в игре будет сложнее...
Хардкорный геймплей неуместен в порноиграх, особенно в постельных сценах. Люди покупают/скачивают такие игры чтобы подрочить, а не чтобы мучиться с прохождением и постоянными проигрышами. В идеале геймплей должен быть "одноручным" (ну ты понял). Даже если ты планируешь отдельный упрощённый режим, имеет ли смысл делать хардкорный геймплей? То же порно на фоне будет только отвлекать внимание от геймплея и раздражать. Но что-то совсем простое не обязательно делать, можно сделать что-нибудь вроде:
- на тянке рандомно появляются точки/фишки;
- нужно успеть нажать на них курсором мыши;
- успел - повысил возбуждение тянки;
- не успел - понизил возбуждение тянки;
- кликнул в неправильном месте - ещё сильнее понизил;
- при максимальном возбуждении тянка ловит оргазм.
Т.е. с одной стороны в это можно играть одной рукой, дроча другой, а с другой - это не простое "далее, далее, далее", а игра на реакцию и внимание, для прохождения которой нужно быть достаточно быстрым и внимательным, иначе финальную сцену не увидишь. Алсо это ближе к реальному процессу (точки - эрогенные зоны, клики - стимуляция) и позволяет симулировать индивидуальность разных тянок (эрогенные зоны в разных местах и с разной чувствительностью - бонусами к параметру возбуждения, разный максимальный уровень возбуждения, разные штрафы за ошибки и т.д.).
ъъъъъъ сломал мне мозг своим видео.
Слышать green needle полегче, чем brainstorm
>Слышать green needle полегче, чем brainstorm
Серьёзно? А я вообще грин нидл услышать никак не могу. Только брейнсторм, брейнсторм, брейнсторм. Пробовал разными способами, даже закрывал глаза и повторял про себя грин нидл - всё равно слышу брейнсторм. По-моему это какая-то разводка. Или это что-то уровня того платья, которое у всех разных цветов видится?
Ну всё, из-за тебя теперь тут будет обсуждение этого видео.
Ты не понял. У модели 1.6 партнёр по сцене 1.9. задача - задать положение тазов и лиц персонажей на одной высоте с помощью анимации без привязки к росту.
Что касательно сложности, то мне кажется это самое важное в порно игре. Мужчина - это охотник. Ему не интересно охотится на лёгкую добычу. Главное, чтобы цель была ясна, и была возможность где то потренироваться на жирухах. Он будет влюблен больше всего в ту мадам, у которой сложность s+++. Все эти "покликай", это от лукавого и оставьте их флешиграм.
одинаково слышу оба слова
зато есть мотивация нарисовать норм ноги
в какую сторону девка крутится?
Это как пикрилейтед. Наверное, звук так обфусцирован, что мозгом может быть воспринят так или так. Где-то около подсознания надо положить слово, которое собираешься услышать. Но если сознательно пытаешься обмануть себя, то подсознание это всё-равно знает.
Кроме green needle или brainstorm можно услышть green storm или brai' needle.
Получается, что это звучит как-то так: grei nnn dlll rm
Первая часть может быть воспринятя как green-nee или brain. Во второй части говорится dlll, но на его середине создаётся storm.
>как пикрилейтед
Да, как этот:
Слова отдедены шипящим звуком. Он становится S в Storm Nee в Needle. Green и brain в примере уже достаточно похожи звучат. Как и torm и dle. Смешивать можно как угодно и даже слышать жругие слова. Green storm, grain needle, breen shindle. И тому подобное.
>У модели 1.6 партнёр по сцене 1.9
>задать положение тазов и лиц персонажей на одной высоте с помощью анимации без привязки к росту.
Ва... ват? Ты предлагаешь поставить тянку на табуретку? Или ты про постельную стену, когда один персонаж лежит на другом?
Думаю, такое решается привязкой к ключевым точкам и инверсной кинематикой. Если важно, чтоб совпали промежности - модели ориентируются по промежностям. Если лица - по лицам. Если нужно и то, и другое, одна модель будет вынуждена сгибаться... Тут-то и понадобится инверсная кинематика - глянь в официальных примерах Godot, там был пример реализации для рук персонажа (хоть и не очень выглядит). Если вкратце, то инверсная кинематика позволяет тянуть скелет за крайнюю кость к цели, и все остальные суставы будут автоматически подстраиваться. Главное тут найти/сделать "решатель" (IK Solver), остальное будет относительно просто (задаёшь две точки - за которую тянем и к которой тянем, остальное происходит автоматически).
>Мужчина - это охотник
Половые стереотипы давно пора выбросить из головы. Не ради каких-то там транс-извращенцев... ради себя и всех, кто в эти стереотипы от природы не вписывается, а таких много.
>Ему не интересно охотится на лёгкую добычу
Угу, именно поэтому все сидят на порносайтах, а в Яндекс картинках так популярны запросы на эротику, хентай, секс и прочее. Это ведь так сложно - делать интернет-запросы и смотреть картинки, намного сложнее, чем, например, пойти снять шлюху. Мужыг ахотнег, мужыг ахотытся, мужыг добыват хорошый картынка, грр!!1 Про дофамин и систему подкрепления пояснять, или сам разберёшься?
>Он будет влюблен больше всего в ту мадам, у которой сложность s+++.
Ты либо школьник <13, либо асексуал, либо, даже не знаю, бумер-импотент-девственник (настоящий волшебник!). Все дрочат на свои кинки/фетиши, и плевать на сложность, а лучше чтобы сложности вообще никакой не было. Генки? Цундере? Яндере? БДСМ-госпожа? Рабская шлюшка? Робот? Огромные бидоны? Гигантская жопень? Татуировки? Конечности монстра? Морда и шкура животного? Необычная кожа? Раздутый живот? Изнасилование? Гипноз? Расчленёнка? Проглатывание заживо? Список можно продолжать бесконечно, просто зайди на любой сайт с NSFW картинками. Если чувак видит, что в твоей игре есть тянка с чем-то, что его привлекает больше всего (маленькая неко-горничная цундере с рабской татухой и огромным ошейником, как пример из абстрактного исекай-аниме) - он будет добиваться её любой ценой, но завышенная сложность его только разочарует. Говорю по опыту, почти пару лет играл в одну игру про коллекционирование самок человека, повышение сложности добило и без того угасающий интерес, и не только у меня, а привлекательность той или иной тянки измерялась исключительно наличием у неё того, что меня привлекает, а не сложностью добычи. Возможно, у тебя всё совсем не так, но как-то не верится.
Я говорю про взаимодействие персонажей с разным ростом, да.
> Почти пару лет играл
> Угасающий интерес
Если игроки подарят пару лет жизни моей игре, я буду счастлив. Большего мне не надо.
Ну чтож, новые изменения в МР:gitlab.com/mdchs/dsystem/-/merge_requests/7
Ченжлог:
- добавлены новые изображения персонажей, локаций, предметов для демо
- добавлена валидация и оповещение через сообщение в лог об ошибке выполнения функций из конфига
- ещё раз переписан парсер сообщений назад на табы, т.к. без табов оказалось не удобно
- персонажу добавлены новые функции для конфига
- добавлен main конфиг, где можно выставить начальные параметры игры
- возможность выключать интерфейс и интеракцию с предметами в локации
- небольшие валидационные работы с конфигами
Найденные недоделки:
- Отсутствует обработка интеракции со STUFF
- Боты планируют и выполняют функции, даже когда это не нужно
- Отсутствуют пулы объектов под кнопки и иной интерфейс
- Отсутствуют требования по наличию STUFF в локации в рецептах.
- Отсутствует конвертация полного маршрута во время
- Отсутствует функция запоминания объектов в диалогах
- Отсутствует возможность отключить функционал, типа GOAP-системы. Для обычных квестов он совсем не нужен.
О диалоговой системе.
В текущей версии представлен простой диалог с персонажем, после которого он уходит, приводя на сцену другого персонажа. В конфигах так же добавилась возможность создавать комментарии, чем я и воспользовался, максимально постаравшись описать вам процесс создания диалога.
Ченжлог:
- добавлены новые изображения персонажей, локаций, предметов для демо
- добавлена валидация и оповещение через сообщение в лог об ошибке выполнения функций из конфига
- ещё раз переписан парсер сообщений назад на табы, т.к. без табов оказалось не удобно
- персонажу добавлены новые функции для конфига
- добавлен main конфиг, где можно выставить начальные параметры игры
- возможность выключать интерфейс и интеракцию с предметами в локации
- небольшие валидационные работы с конфигами
Найденные недоделки:
- Отсутствует обработка интеракции со STUFF
- Боты планируют и выполняют функции, даже когда это не нужно
- Отсутствуют пулы объектов под кнопки и иной интерфейс
- Отсутствуют требования по наличию STUFF в локации в рецептах.
- Отсутствует конвертация полного маршрута во время
- Отсутствует функция запоминания объектов в диалогах
- Отсутствует возможность отключить функционал, типа GOAP-системы. Для обычных квестов он совсем не нужен.
О диалоговой системе.
В текущей версии представлен простой диалог с персонажем, после которого он уходит, приводя на сцену другого персонажа. В конфигах так же добавилась возможность создавать комментарии, чем я и воспользовался, максимально постаравшись описать вам процесс создания диалога.
>Следить за состоянием кодовой базы можно здесь:
>gitlab.com/mdchs/dsystem
>No license. All rights reserved
А ты планируешь добавить свободную лицензию типа MIT? А то пока что мы даже компильнуть твой код не можем, получается, только смотреть.
>Если игроки подарят пару лет жизни моей игре
Для этого игра должна быть либо достаточно сложной песочницей (майнкрафт, дварфы, скайрим, гта и т.п.), либо иметь механики, эксплуатирующие дофаминовую систему человека (лутбоксы, пачинко, ежедневные задания, любая "халява", кланы, соревнования между игроками и многое другое). Проще говоря, либо игрок естественным путём увлекается твоей игрой и/или модами к ней, либо подсаживается на неё как на цифровой наркотик.
Я никогда не добавлял лицензии MIT. Как это делать?
Сложность песочницы нарастёт со временем.
>Я никогда не добавлял лицензии MIT. Как это делать?
В GitLab? Понятия не имею, в доках не нашёл. В GitHub:
https://docs.github.com/en/communities/setting-up-your-project-for-healthy-contributions/adding-a-license-to-a-repository
Пытался сделать запоминание переменных. Но возникли естественно проблемы с скобками внутри скобок. Есть конечно возможность добавить ещё больше костылей, но я думаю красивее будет взять свой самописный язык программирования на с# и перенести его на gdscript для парсинга условий и действий. Ну, а что, довольно быстро я вырос из примитивного конфиг парсера, который был написан по-быстрому из лени.
Ставить ради него моно годот не хочу.
Ставить ради него моно годот не хочу.
>Пытался сделать запоминание переменных
>свой самописный язык программирования
А зачем, если Годо уже имеет скриптовый ЯП GDScript, простой и доступный для новичков? При том для GDScript есть куча учебных материалов и официальной документации на все случаи жизни, а по твоему языку ты будешь писать всё сам с нуля. Хочешь что-то проще GDScript? Но что-то проще будет иметь ограниченные возможности или будет менее удобным для создания сложных систем. А если будешь расширять возможности, рано или поздно получится так, что твой ЯП дублирует функциональность того же GDScript, но работает медленнее и поддерживается одним только тобой.
Имхо, лучше просто хорошо задокументировать API своих классов и выкладывать игру в виде исходников с приложенным шаблоном экспорта (без билда в pck), чем изобретать лишний велосипед и потом учить игроков этим велосипедом пользоваться.
Да, мне нужен урезанный язык для диалогов, умеющий считать цифры и выполнять функции. Мне не нужен gdscript в этом случае, так как он не будет являться удобной обёрткой над объектами.
Мой яп и так будет дублировать функциональность любого языка программирования, ТК он высчитывает условия, и вызывает функции. Разница в том, что он подстроен под диалог персонажей и работает для более быстрого написания диалогов, а не кода с нуля.
- сжаты файлы
- перераспределена ответственность на хранение ссылок на интерфейс
- полностью переписан парсинг вызова функций и условий
- сделано сохранение/получение переменных
- добавлена возможность отключать TASK и NEED контроллеры в main.ds
- message теперь возвращают ошибку корректно останавливая загрузку программы
Язык представляет из себя набор следующих возможностей:
- получение/сохранение переменной
- вызов функции
- проверка условий
Блоки остались те же.
Внутри текста мы можем начать выполнение функции с помощью {} и написать там один вызов функции выдающий значение.
В блоке if: мы должны написать одно условие, которое скажет, есть такой вариант ответа или нет.
В блоке do: мы пишем перечисление через точку с запятой всех действий, которые будут выполнены в случае выбора игроком этого действия или прочтения его игровым персонажем.
Поддерживается умножение, сложение и вычитание.
Поддерживаются скобки.
Поддерживаются операторы больше, меньше, равно, не равно.
Поддерживаются битовые операции AND, OR, NOT
Поддерживаются битовые константы false и true, целые числа.
Текущие недоработки, которые пока не трогаю, чтобы в них не увязнуть:
- Отсутствие ошибок в названиях функций (их наличие).
- Отсутствие проверки возвращаемого значения. Есть вариант фатала, т.к. у вас может оказаться случай 5 == true.
- Пулы объектов отсутствуют. Но пока что работает шустро, так что не к спеху.
- перераспределена ответственность на хранение ссылок на интерфейс
- полностью переписан парсинг вызова функций и условий
- сделано сохранение/получение переменных
- добавлена возможность отключать TASK и NEED контроллеры в main.ds
- message теперь возвращают ошибку корректно останавливая загрузку программы
Язык представляет из себя набор следующих возможностей:
- получение/сохранение переменной
- вызов функции
- проверка условий
Блоки остались те же.
Внутри текста мы можем начать выполнение функции с помощью {} и написать там один вызов функции выдающий значение.
В блоке if: мы должны написать одно условие, которое скажет, есть такой вариант ответа или нет.
В блоке do: мы пишем перечисление через точку с запятой всех действий, которые будут выполнены в случае выбора игроком этого действия или прочтения его игровым персонажем.
Поддерживается умножение, сложение и вычитание.
Поддерживаются скобки.
Поддерживаются операторы больше, меньше, равно, не равно.
Поддерживаются битовые операции AND, OR, NOT
Поддерживаются битовые константы false и true, целые числа.
Текущие недоработки, которые пока не трогаю, чтобы в них не увязнуть:
- Отсутствие ошибок в названиях функций (их наличие).
- Отсутствие проверки возвращаемого значения. Есть вариант фатала, т.к. у вас может оказаться случай 5 == true.
- Пулы объектов отсутствуют. Но пока что работает шустро, так что не к спеху.
>может оказаться случай 5 == true
Так это же нормально. В том же GDScript всё, что не ноль - истина, ноль - ложь. Видел такое ещё в нескольких языках, это популярно. Проблема в неявном преобразовании типов, в строго типизированных языках для такого трюка нужно сделать Boolean(5), только тогда оно будет равно true. Но, думаю, для простого языка неявное преобразование нормально и удобно.
Это не нормально. Это лишь вызывает у людей диссонанс.
Сегодня было не много времени, но:
Добавлена:
- агрегация сообщений. Теперь можно создавать пустое сообщение, которое будет мгновенно скипаться, но действия в указанные в нем все равно будут выполнены.
- поправлен баг с назначением переменной от @i. Теперь, когда переменная будет взята, это будет тот самый старый персонаж, а не новый. (хотя походу я сделал новый баг, который будет вызывать фаталы в функциях)
- теперь привязку сообщений можно указывать в одну строку через точку с запятой
Добавлена:
- агрегация сообщений. Теперь можно создавать пустое сообщение, которое будет мгновенно скипаться, но действия в указанные в нем все равно будут выполнены.
- поправлен баг с назначением переменной от @i. Теперь, когда переменная будет взята, это будет тот самый старый персонаж, а не новый. (хотя походу я сделал новый баг, который будет вызывать фаталы в функциях)
- теперь привязку сообщений можно указывать в одну строку через точку с запятой
Поправил баги связанные с назначением переменной.
Поправил другие мелкие недоработки.
Начал писать диалоги, юзая свою же мессадж систему. Писать диалоги оказалось сложнее и трудозатратнее, чем программировать или рисовать. Для этого действительно нужно желание и способности.
В ходе написания диалогов выяснилось, что наиболее простым способом делать разветвленные системы - это реакции на события.
Т.е. по сути мы имеем описание, когда персонажу больно, радостно или нужно представить свое имя и описываем в другом блоке миллион возможных действий, которые он на это может сделать, отсеивая их в зависимости от их характеристик.
Поздравляю, Вы великолепны, и теперь сконкатенировав сообщение, где персонаж испытывает это событие с этой "группой" сообщений по-поводу этого события, Вы в любой момент получаете перечень реакций.
Т.е. по сути, все диалоги превращаются в описание как можно большего количества разных событий, и внутри этих событий реакцию на них.
Так же, я достиг того момента, когда пора вводить Знания персонажа. Это простые величины, в виде "Знаю его имя", "Знаю где находится рынок" и т.п, которые отвечают на простой вопрос "Да" или "Нет". Но хотелось бы сделать это оптимизировано, но и гибко одновременно. Сейчас я над этим много думаю. Вероятно, это будет смесь одного словаря с битовыми картами у каждого персонажа. По словарю мы найдем номер элемента в битовой карте и сможем работать в битовой карте конкретного персонажа.
Поправил другие мелкие недоработки.
Начал писать диалоги, юзая свою же мессадж систему. Писать диалоги оказалось сложнее и трудозатратнее, чем программировать или рисовать. Для этого действительно нужно желание и способности.
В ходе написания диалогов выяснилось, что наиболее простым способом делать разветвленные системы - это реакции на события.
Т.е. по сути мы имеем описание, когда персонажу больно, радостно или нужно представить свое имя и описываем в другом блоке миллион возможных действий, которые он на это может сделать, отсеивая их в зависимости от их характеристик.
Поздравляю, Вы великолепны, и теперь сконкатенировав сообщение, где персонаж испытывает это событие с этой "группой" сообщений по-поводу этого события, Вы в любой момент получаете перечень реакций.
Т.е. по сути, все диалоги превращаются в описание как можно большего количества разных событий, и внутри этих событий реакцию на них.
Так же, я достиг того момента, когда пора вводить Знания персонажа. Это простые величины, в виде "Знаю его имя", "Знаю где находится рынок" и т.п, которые отвечают на простой вопрос "Да" или "Нет". Но хотелось бы сделать это оптимизировано, но и гибко одновременно. Сейчас я над этим много думаю. Вероятно, это будет смесь одного словаря с битовыми картами у каждого персонажа. По словарю мы найдем номер элемента в битовой карте и сможем работать в битовой карте конкретного персонажа.
За сегодня сделал лишь знания.
Конечно полностью оптимизировать не получилось, но может это и не беда.
В общем-то, теперь в диалогах персонаж может получить ЗНАНИЯ. Это утверждение, вроде Знаю Азбуку, Умею Считать. Отличие от Профессии в том, что знание - это единичный факт, который никак не прокачивается и лишь дает доступ к диалогам, где этот факт используется.
Естественно так же поддерживается функция проверки знания чего-либо у персонажа.
Конечно полностью оптимизировать не получилось, но может это и не беда.
В общем-то, теперь в диалогах персонаж может получить ЗНАНИЯ. Это утверждение, вроде Знаю Азбуку, Умею Считать. Отличие от Профессии в том, что знание - это единичный факт, который никак не прокачивается и лишь дает доступ к диалогам, где этот факт используется.
Естественно так же поддерживается функция проверки знания чего-либо у персонажа.
Новый небольшой апдейт расширяющий функционал.
МР: gitlab.com/mdchs/dsystem/-/merge_requests/10
- Добавлена панелька визуализирующая сообщения. В неё можно передать имя заголовка и текст сообщения.
- Добавлены в конфиг с предметами TYPE, USAGE_CALL
- Добавлена возможность "применять" предметы. При применении предмета или ВЕЩИ выполнятся все функции, указанные в USAGE_CALL. В конфиге есть пример книжного шкафа, при нажатии на который выдается текстовое сообщение на экран.
- Добавлен новая лексема "Текст". Теперь парсер функций может читать слова через пробел с помощью стандартной лексемы для всех языков программирования - тексту между кавычками. Возрадуемся.
МР: gitlab.com/mdchs/dsystem/-/merge_requests/10
- Добавлена панелька визуализирующая сообщения. В неё можно передать имя заголовка и текст сообщения.
- Добавлены в конфиг с предметами TYPE, USAGE_CALL
- Добавлена возможность "применять" предметы. При применении предмета или ВЕЩИ выполнятся все функции, указанные в USAGE_CALL. В конфиге есть пример книжного шкафа, при нажатии на который выдается текстовое сообщение на экран.
- Добавлен новая лексема "Текст". Теперь парсер функций может читать слова через пробел с помощью стандартной лексемы для всех языков программирования - тексту между кавычками. Возрадуемся.
Ну че там, куда ты на месяц пропал?
Не на месяц, а всего 20 дней. Я делал диалоги. И понял, что диалоговая система моя прекрасна, но диалоги я написать не могу. Я пробовал разные варианты по поиску диалогмейкера, но они не увенчались успехом. Поэтому я доработал код токенизации, сделал из него свой язык программирования на годоте для игры, написал простенький генератор подземелий покоторому можно гонять гг и драться с монстрами с помощью скриптов, но в по разбушевались украинцы на Донбассе и отвлекли меня от разработки.
Вот такие дела.
И вообще, э-игры чет меня не вставляют. Я написал много полезных наработок, но вот как дело касается сюжета и контента, я конечно попадаю в ступор. Тем более с э-играми, где нужно его делать одной рукой.
Все ты мертв?
> Я делал диалоги. И понял, что диалоговая система моя прекрасна
Покежь протокол!
>но в по разбушевались украинцы на Донбассе и отвлекли меня от разработки.
Сейчас уже утихли.
Похоже не покажет...
Эх, а жаль. Я всё ещё в поисках идеальной диалоговой системы.
>в поисках идеальной диалоговой системы
А что тебе конкретно нужно от такой системы?
Сам я хотел бы сделать процедурные диалоги, т.е. что-то вроде чатботов, только с фиксированным набором фраз. На мой взгляд, любые ветвящиеся диалоги как у ОПа - тупик.
ИМХО в симс самая адекватная система абстрактных диалогов.
> А что тебе конкретно нужно от такой системы?
А вот собсна это я и обмозговываю уже некоторое время:
> На мой взгляд, любые ветвящиеся диалоги как у ОПа - тупик.
Ищу инновационные подходы.
Что ты имеешь в виду? Там же нужно палить по иконкам, о чем говорят симы, чтобы выстроить грамотно диалог. Иначе можно слить все отношения.
А разве в Симс можно общаться с симами? Я думал, там все диалоги чисто декоративные, якобы симы "общаются"...
>Ищу инновационные подходы
Предлагаю такой. У персонажей есть внутреннее состояние (настроение, физиология и т.п.), контекст - ситуация, в которой они сейчас находятся, и память - записи о прошедших ситуациях. В зависимости от этих параметров они выбирают фразу из некоторого ограниченного набора фраз. Игрок тоже выбирает любую фразу из ограниченного набора фраз, которые могут понять персонажи. Каждая фраза влияет на контекст, память и состояние персонажа. В результате никаких явных "рельс" диалога нет, каждый персонаж действует по ситуации, в зависимости от собственных потребностей, воспоминаний и окружающей обстановки. Это, конечно, не позволяет задать жёсткий сюжет (рельсы), но зато могут возникать самые разные сюжеты за счёт эмерджентности.
Т.е. каждая фраза выбирается в зависимости от набора параметров и действует каким-то образом на какой-то набор параметров. Сами фразы строить нет смысла, если ограничиться простыми фразами, то все варианты (комбинации возможных действий и предметов в игровом мире) можно будет перебрать вручную.
> Предлагаю такой.
Я над таким размышлял, но для меня это слишком сложно, у меня не вышло построить удобочитаемую беседу. Получался какой-то тупой чат-бот из нулевых, который пять секунд назад говорил о квесте, а спустя секунду говорит о погоде.
>А разве в Симс можно общаться с симами? Я думал, там все диалоги чисто декоративные, якобы симы "общаются"...
Я не очень понял, что ты под этой фразой подразумеваешь. Симы не ведут прямо осмысленное для игрока общения на уровне реальных диалогов. Однако все остальные аспекты имитируются удачно, они реагруют эмоционально на реплики собеседника, улучшают или ухудшают мнение о нем.
Мне кажется если доработать такую систему, добавить больше негативных модификаторов, такие как характер, социальные навыки, внешка и положение в обществе может получится лучшая система в играх.
>они реагруют эмоционально на реплики собеседника, улучшают или ухудшают мнение о нем.
Я видел видео, как они на своём симлише что-то "говорят", но несут ли эти реплики смысл, кроме изменения настроения?
Пример осмысленной реплики:
— В %место% лежит пострадавший, кто-нибудь, помогите ему!
— (собеседник эмоционально напрягается и бежит помогать пострадавшему, либо расстраивается и проходит мимо - в зависимости от характера и текущего списка дел)
Пример имитации реплики:
— (сделать вид, что говоришь, понизив настроение собеседнику)
— (собеседник тупо расстраивается)
Как видишь, разница принципиальна - в первом случае это действительно общение (даже если на основе шаблонов), а во втором случае это только имитация общения.
>который пять секунд назад говорил о квесте, а спустя секунду говорит о погоде
Вот поэтому нужно хранить КОНТЕКСТ. Как, по-твоему, все эти GPT нейронки так ловко генерируют текст и не сходят с темы? Потому что их кормят не только последним вопросом, но и всем диалогом до этого, т.е. контекстом. Человеческий мозг тоже каким-то образом хранит контекст, сбрасывая его по таймеру (~15 минут) или при определённых условиях (переход в другую обстановку, комнату). Наверняка часто замечал, как "теряешь мысль" при слишком долгом обсуждении или забываешь, что хотел сделать, когда переходишь в другую комнату - контекст сброшен и заполнен новой информацией, есть ощущение утраты каких-то данных, но каких - неизвестно. Так и боту нужен контекст, без него он будет скакать по темам от реплике к реплике.
>Защо? Много квестов и визуальных новел на годоте люди делают?
Если не ошибаюсь сейчас инди игра в стиле Римворлда как раз на годоте делается
>Как видишь, разница принципиальна - в первом случае это действительно общение (даже если на основе шаблонов), а во втором случае это только имитация общения.
В первом случае у тебя побуждение к действию(симы это тоже могут, если им сказать или происходит экстренная ситуация)
Во втором случае , как раз таки диалог. Обычный диалог. Один что-то сказал, а другой отреагировал. В жизни большинство диалогов такие. Пошутил смешную шутку - у человека +настроение и _отношение к тебе. Оскорбил - у человека -отношение и может завязаться драка.
>инди игра в стиле Римворлда
Какая именно? Римворлд настолько популярен, что у него уже несколько клонов.
>Пошутил смешную шутку - у человека +настроение и _отношение к тебе.
>Оскорбил - у человека -отношение и может завязаться драка.
Это имеет смысл только если отношения поддерживаются и все произошедшие события как-то сохраняются. Если чат-бот в ответ на оскорбление пишет тебе "тьфу на тебя, я обиделась", а буквально через минуту уже не помнит никакого оскорбления и продолжает безостановочно болтать на любые темы - это не общение, а именно что имитация общения.
ЗАЧЕМ шутить, оскорблять, что-то рассказывать, пытаться объяснить и т.д., если всё это не влияет на собеседника глубже, чем сиюминутные реакции? Ну вот собеседник посмеялся и ЗАБЫЛ сказанное, что это тебе даст? Что это ему даст? Ничего. Это пустая трата энергии на имитацию бурной деятельности. В игре такая имитация может привлекать внимание, но только до тех пор, пока не осознаешь, что человечки в игре слишком тупые и на самом деле ничего не понимают и не запоминают, а только имитируют понимание путём изображения сиюминутных реакций.
>В жизни большинство диалогов такие.
Если большинство населения - идиоты, это не значит, что разработчики ИИ (даже игрового ИИ, если игра не про идиотов) должны буквально создавать искусственного идиота по образу и подобию необразованного некультурного скота. Представь себе, есть люди, у которых из-за повреждений мозга совсем перестаёт функционировать запоминание, в результате чего они превращаются в своего рода чат-ботов без памяти - что ты ему ни скажешь, он ничего не запомнит, для него время остановилось в момент повреждения мозга и больше ничего не происходило (субъективно). Но это не значит, что чат-бот без памяти - это полноценный человек, и чего-то лучше него создать невозможно. Можно, можно и нужно, если мы хотим развиваться, а не деградировать, хихикая над человечками на экране, изображающими бурную деятельность, которой в действительности у них нет.
>Какая именно? Римворлд настолько популярен, что у него уже несколько клонов.
Извини, я был уверен, что написал название. https://store.steampowered.com/app/1857090/Norland/
Этот проект создан на игровом движке Godot для любителей квестов и визуальных новел.
Вам предстоит прожить некоторое время в городе полном женщин и завоевать их интерес всевозможными способами.
Особенности:
- Реалистичное поведение персонажей к которым нужен собственный подход
- Множество разнообразных локаций, профессий, активностей
- Множество путей достижения целей, включая товарный дефицит, коварство, убийства и подкуп.
- Создавай свою империю, выкупая локации и оборудование.
- Поддержка модификаций
Текущее состояние разработки: стадия написания систем и архитектуры. Следить за состоянием кодовой базы можно здесь: gitlab.com/mdchs/dsystem.