Шапка: https://hipolink.me/godothread
Предыдущий: >>992896 (OP)
Архивный: >>985261 (OP)
Я бы не ответил. Щас-то в контексте допёр, да там бы провалил бы. Да ещё и за 20 секунд. Не, сто процентов провалил бы.
И пихать тебе палец если ты опять задоджил работу над своей игрой.
Сейчас я это сделал натыкав Спотлайтов в линию (красное на пике), но это всрато, их конусы пересекаются, свет получается неравномерным и все такое. Подошел бы дирекшнл лайт, но у него я не вижу никакого контроля дистанции, он всегда освещает всю сцену.
Нейронки говорят либо так, либо шейдеры на дирекшнл накладывать. Штош.
Как-то так? Пик релейтед.
Попробуй с кулмасками поиграться, как показано. Онимлампочки и кубы забиндены на второй слой. земля под ними осталась на первом. Как видишь, цветные лампочки не освещают землю.
Почитай тут
https://forum.godotengine.org/t/any-way-to-somehow-recreate-area-lights-in-godot/58335/2
То есть совет видимо запечь в блендере или годоте.
Вообще вспомнил что в 3ке чел делал Area lights, но не помню как.
https://github.com/danilw/godot-utils-and-other/tree/master?tab=readme-ov-file#graphic_demo_3d
Ну и если нужен интерактив, то в бокс можно добавить Area которая будет детектировать входящие туловища и добавлять им вижуал инстанс 2, а при выходе убирать.
В уе и юнити есть бесплатные тун шейдеры. Где взять бесплатный тун шейдер на гадот?
Вообще из коробки встроенный.
Но навороченые cel shaders и обводки тебе уже накидали.
Но самый мощный я видел у китайца. Это порт Gulity Gear X. Не помню как находил, но точно скачивал когда-то.
>Это порт Gulity Gear X
На видриле? Оно точно не выглядит как у арксистем. На видриле будто бы весь свет нарисован на текстурах вручную. У арксистем он отбит частично геометрией, частично динамичен.
В гилти гире пока что самая мощная манямэ стилизация из актуальных игр. За ними гнаться бессмысленно. Уровня мисайда будет достаточно для начала.
- Есть клавиши перемещения WASD и клавиша открытия инвентаря TAB, все подключены к своим action в input_map
- Есть обработка нажатия, для перемещения стоит Input.is_action_pressed(), для инвентаря Input.is_action_just_pressed()
В чём суть, когда нажаты любые сочетания двух клавиш перемещения или одна клавиша (направления вверх, вниз, влево, вправо, влево-вверх, вправо-вверх, вниз-вправо), обработка нажатия инвентаря Input.is_action_just_pressed() работает, но когда выбирается направление ВЛЕВО-ВНИЗ (AS), обработка не срабатывает, как будто я ничего не нажимаю.
Пробовал менять клавишу в input_map на другие и на клавишах обычных букв всё работает, но конкретно на TAB - нет, что с этим можно сделать, кроме как поменять клавишу?
>is_action_just_pressed
>WASD
По документации - is_action_JUST_pressed возвращает true только когда юзер нажал кнопку. Нажал - как единичное событие, соответственно код под is_action_JUST_pressed сработает тоже один раз. Если тебе нужно обрабатывать зажатие как продолжающееся действие, "пока юзер держит W", то нужен is_action_pressed.
> (AS), обработка не срабатывает, как будто я ничего не нажимаю
Надо же, у меня такая же фигня! Вот сходи, проверь https://en.key-test.ru/
Да, я и написал что wasd обрабатываются is_action_pressed, а инвентарь is_action_just_pressed
>>1001155
Это получается фича конкретно системной обработки клавиш? Ну капец теперь, кто и зачем это придумал, спасибо, видимо, не смогу так сделать
>для перемещения стоит Input.is_action_pressed()
Лучше используй Input.get_vector(), сразу нормализованный Vector2 получишь.
>когда выбирается направление ВЛЕВО-ВНИЗ (AS), обработка не срабатывает
Это нормально, это физическое ограничение клавиатуры (если у тебя не механика).
>что с этим можно сделать, кроме как поменять клавишу?
Ничего не делать. Игроку не нужно нажимать сразу 3 клавиши в большинстве игр. Тем более что открытие инвентаря - это однократная операция, которую делают в спокойной обстановке, т.е. персонаж будет неподвижен (тем более если инвентарь ставит игру на паузу). В любом случае, твоя игра должна позволять сменить раскладку клавиатуры, и если кому-то нужно нажать сразу 3 клавиши, а его клавиатура ограниченная, то он сможет сменить раскладку в настройках игры.
>>1001173
>Это получается фича конкретно системной обработки клавиш?
Это "фича" в проводке и прошивке твоей клавиатуры.
>кто и зачем это придумал
Это придумали ради экономии в мембранных клавиатурах. Я вот могу нажать QWER UIOP - аж 8 клавиш одновременно, но вот нажать QAS, WAS, EDS, WSD и многие другие комбинации у меня не получится - две первые кнопки блокируют нажатие третьей. Потому что на мембранной клавиатуре проводки, идущие от клавиш к чипу, как-то по-особенному пересекаются, и чип не может прочитать все клавиши независимо друг от друга - нажатие одной клавиши блокирует чтение нажатий клавиш на той же линии. В механических клавиатурах, как я читал где-то, обычно нет такого ограничения, потому что там проводки клавиш распаяны независимо друг от друга, поэтому можно нажимать что угодно в любом порядке. Но большинству пользователей такая свобода всё равно не нужна, тем более в играх, и поэтому ты раньше об этом даже не догадывался.
>видимо, не смогу так сделать
А зачем тебе вообще зажимать 2 кнопки движения + открытие инвентаря?
> Лучше используй Input.get_vector(), сразу нормализованный Vector2 получишь.
О спасибо, буду использовать
> Это "фича" в проводке и прошивке твоей клавиатуры.
Спасибо большое, я бы до такого не додумался сам
> А зачем тебе вообще зажимать 2 кнопки движения + открытие инвентаря?
Думал сделать, чтобы инвентарь игру на паузу не ставил, и им можно было на ходу пользоваться
>на мембранной клавиатуре проводки, идущие от клавиш к чипу, как-то по-особенному пересекаются, и чип не может прочитать все клавиши независимо друг от друг
Пиздец, экономия на спичках.
>на ходу пользоваться
Terraria так делает... Но позволяет в настройках выбрать, ставить на паузу или нет. И позволяет забиндить любое действие на любую клавишу (на смартфонах там вообще собственный виртуальный контроллер собрать можно). Правда, там редко бывает чтобы A и S были зажаты одновременно. У тебя игра с видом сверху?
Имхо, лучше просто позволить игроку самому настраивать раскладку (биндинг клавиш). И добавлять/использовать действия рационально (чтобы у тебя не было несколько разных действий с одним смыслом "использовать", когда достаточно было бы всего одного на все ситуации - слышал такую критику о какой-то игре). Тогда никаких проблем не будет.
> ставить на паузу или нет
Думал без паузы это в принципе сделать, допустим, на бегу открывать инвентарь и лечить кровотечение бинтом из инвентаря, но в целом это не так критично конечно
> У тебя игра с видом сверху
ага
> лучше просто позволить игроку самому настраивать раскладку
Ну это база, да, но мне срочно хаха
>экономия на спичках
Я неправильно выразился, вряд ли это из-за "экономии", скорее ограничения технологии. В мембранных клавиатурах у тебя две тонких пластиковых плёнки с распечатанными на них проводками. Когда нажимаешь на клавишу, ты продавливаешь верхнюю плёнку, создавая контакт с нижней. Из-за этого, возможно, приходится ограничивать число проводков и их расположение, чтобы они не замыкались когда не нужно. Но клавиатура выходит намного дешевле за счёт использования этих мембран.
В механической клавиатуре жёсткая печатная плата, на которой может быть распаяно что угодно в несколько слоёв как на любой обычной плате. Или вообще проводками можешь соединить и свой контроллер запрограммировать. Но и выходит всё это удовольствие намного дороже - т.к. датчики все индивидуальные, в отличие от одной общей мембраны.
Картинки из интернета.
Не понимаю, как отлавливать _on_input_event() двух Area2D, если они пересекают друг друга?
А, нашёл проблему и решение:
https://github.com/godotengine/godot/pull/75688
>get_viewport().physics_object_picking_sort = true
>get_viewport().physics_object_picking_first_only = true
Дело в том, что пересекающиеся Area2D получают сигнал ввода в произвольном порядке. Поэтому, в отличие от Control, положение Area2D в дереве сцены не влияет (по умолчанию) на то, какая из них будет обработана первой. Простой вызов set_input_as_handled() не меняет ситуацию, т.к. неизвестно, какая нода получит сигнал первой. Сортировка позволяет этого избежать.
На 750ti тянет. На встройке интела запускал, но не помню как там было
>>1001022
Там моделька рипнутая из GBF versus что ли, и источники света там есть которые привязаны к персонажу и светят на него, а есть внешний, вроде только один может быть активен. И там динамическое.
Вот его бложик, но что то сейчас не открывается без китайской реги. Хотя файлы можно скачать (там пароль написан). Емнип в посте были исходники шейдера. Где то в хламе на жестком диске наверное они у меня валяются...
https://zhuanlan.zhihu.com/p/390781757
Делаю 2D top down RPG, до этого основательно ковырял UE и Unity, но Годот понравился больше всех. Первый - слишком тяжелый для моих задач, второй - показался архаичным, очень неприятно с ним взаимодействовать во всех смыслах и за него еще деньги просят...
В моем случае после перехода на Годот очень ускорилась разработка проекта, появилась радость от взаимодействия с движком
> Какого жанра игру разрабатываете?
3D стелс-экшон-адвенчуро, резиденталик
> С какими трудностями столкнулись?
Главная трудность - моя лень.
Делаю 3д топ даун паззл-приключение с механикой времени и прочей мишурой. БОльшая часть кода написана, механики сделаны, простенький (а мне больше и не надо) ИИ сделан, боевка сделана, сюжет написан, даже сейвы давно сделаны ненавижу блять сейвы.
Целюсь и на десктоп и на мобилки, регулярно проверяю работоспособность на андроиде. Мобилки накладывают довольно жесткие требования к производительности, особенно по 3д, - периодически приходится отказываться от желаемого графона и хитрить со "smoke and mirrors", что иногда работает в мою пользу и придает игре узнаваемый вид и некий шарм.
Туплю по дизайну левелов, паззлов и диалогов. Создание красивого И функционального кусочка уровня, проходящегося за 5 минут, занимает у меня месяц блять. И это, помимо требований к производительности, моя основная трудность. Раньше еще с созданием ассетов страдал, сейчас придрочился.
Игра уже выглядит как игра. Сделанные области в состоянии, пригодным к релизу. Но работать еще дохуя. Надеюсь в этом году хотя бы демку выкатить.
>Делаю 2D top down
Братюня. Почти все мои релизнутые игры - top down.
>2D top down RPG
оно видимо само както приходит когда движок открываешь
я пока ковыряю свою хуйню
основные сложности - это необходимость переключаться между различными несвязанными задачами в процессе разработки в соло (типа покодил, пособирал анимации, повозился со звуком, порисовал спрайтов, пописал сюжет) - все это сильно выматывает, особенно когда садишься с одной целью типа добавить какуюнить механику, но тебе нужно вместо того чтобы кодить переключаться и пиздовать разбираться со звуком или рисовать, а это ты делать не хотел.
Еще хотелось бы заняться какимто другим проектом, в другом жанре но тут ебашить лютейшая ЛЕНЬ и я конечно хочу попробовать сделать булетхел, внку или сурвайвор, но мне так сука лень думать и гуглить как реализовывать какието базовые кор вещи для таких проектов
Делаю мультиплеерный джедай лайк экстракшен экшн от третьего лица.
>С какими трудностями столкнулись?
Трудностей много, в последнее время занимался синхронизацией мультиплеера, почему-то при смерти игрока не всегда сигнал регистрируется. Ещё расчлененку которую хотел не получится всунуть, придется делать обычную. Ещё кингдом кам второй вышел и на завод вчера пришлось пиздовать устраиваться, придется игрой ток по выходным заниматься. В общем пиздец.
Ого! Любопытный проект. Очень много играл в Jedi Academy в свое время. На ней еще не так много лет назад жил и процветал глобальный мод MovieBattles 2, там боевка вообще космическая. Лучше нигде не видел. Чекнул, вроде до сих пор игроки есть, если захочешь вдохновиться/рефы собрать - https://servers.moviebattles.org/ (Порог вхождения невероятно высок)
Путь разработчика тернист, но не будет обижен тот, кто не отступил. Взять крутую идею из игры прошлого и дать ей новую жизнь - отличный план, успехов тебе Вот бы еще Oni (2001) кто-нибудь воскресил
> основные сложности - это необходимость переключаться между различными несвязанными задачами в процессе разработки в соло
А для меня это одна из хороших сторон соло разработки. Устал работать с кодом - пошел на чилле делать ассеты, устал от этого - пошел анимациями заниматься и так далее
> выматывает, особенно когда садишься с одной целью типа добавить какуюнить механику, но тебе нужно вместо того чтобы кодить переключаться и пиздовать разбираться со звуком или рисовать
Почему так? Программирование и вовсе вещь абстрактная, главное хотя бы примерно понимать, какой у тебя контекст
Можно разбивать по дням - день кода, день ассетов
>Почему так?
ну я и делю по дням
дизморалит как раз внезапная необходимость переключаться
например когда заметил какуюто ошибку в спрайтах и нужно все бросать и идти переделывать
>нужно все бросать
Кто-то стоит рядом и заставляет под дулом пистолета? Жил этот корявый спрайт и поживет еще пару часов-дней. Запиши в список дел и продолжай работать над чем работал, потом наберешь с десяток корявых спрайтов и все разом поправишь.
ну так оно и копится, ты же видел видос, там полно косяков в том числе в визуале
это все мелочи которые не сильно влияют на мотивацию, но им свойственно накапливаться, только и всего
в какойто момент негатив от процесса превышает интерес и я дропаю проект, досадно конечно, но геймдев в целом одно из многих недоразвитых моих хобби, я к этому всему нормально отношусь
Порноигру.
Из сложностей реально могу выделить связку моделей с фронтендами. Имею в виду что-то вроде View и Model в MVVM, MVC или MVP. Очень много ломается у меня на промежуточных этапах. Еще невероятно сложно работать со всем, что как-то связано не с тактами процессора, а с человеческим временем. Всякие анимации, твины и синхронизации штук. Если в крации, то считать математику и писать алгоритмы мне весело и легко, а когда дело доходит до того, что нужно игроку это показать где-то кроме консоли, начинается боль и тоска. Это что касается технической части. А по наполнению сложно диалоги выдумывать и работать с визуалом. Рисовать, дизайнить, красить модельки.
>С какими трудностями столкнулись?
Депрессия, отсутствие смысла...
Воу, ты здесь. Я думал ты давно ушёл. Обожаю твою карлицу. А смысл? Вон в АААА треде подбери подходящий. Или давай вместе придумаем ИТТ?
>>1001725
Предлагаю типичный коллектотрон и любой минимальный сюжет, привязанный к собиранию предметов. Жанр нишевый, но до сих пор всотребованный.
А я предлагаю пилить нетипичный жанр. У анона на видосах есть крюк-кошка, сбор ресурсов для крафта, кнопки, сундуки. И горячая жопастая карлица. Анончик в двух шагах от хита, который сделает его богатым и знаменитым. Нужно только придумать карлице историю и геймплейно рассказать её.
gd скрипт заебись, дока подробная, инфы дохуя, шарп нинужен
GDScript достаточно для 99.99% твоих идей. У него всего одна проблема - низкая производительность, которая проявляется, если тебе нужно перемолотить >100000 чисел за один кадр, что нужно крайне редко и только в определённых жанрах игр. В остальном производительности хватает. Зато удобный редактор, быстрое прототипирование, лёгкое редактирование, плотная интеграция в ядро движка, много обучающих материалов, широкая поддержка сообщества (плагины и т.п.).
Если нужна производительность, лучше выбирать C/C++ - это эффективнее C#.
Роль C# в Godot - удобство для переходящих с Unity/MonoGame и т.п.
>>1001725
>Воу, ты здесь. Я думал ты давно ушёл.
Да, ушёл, но кроме попыток разработать игру у меня нет продуктивных увлечений.
>Обожаю твою карлицу.
Чем она тебе нравится? Это сырой прототип, его нужно будет сильно переделать, если я когда-нибудь доведу игру до релиза. И она не такая уж низкая... только бёдра широкие и голова увеличена под "стиль аниме" (лицо лень пока доделывать, просто представьте большие аниме-глаза).
>в АААА треде подбери подходящий. Или давай вместе придумаем
У меня полно идей/концептов, не в них дело. Смысла не вижу, потому что я всегда хотел сделать игру, в которую мне самому будет интересно играть долгое время - в буквальном смысле, а не "вот если бы кто-то такое сделал". Проблема в том, что как игрок я так называемый "исследователь" (explorer): мне доставляет удовольствие изучать игровые миры и механики, экспериментировать с ними и всё такое, и я теряю интерес к игре, если она больше не может доставить то, чего я ещё не знал.
Поэтому я так сильно увлекаюсь процедурной генерацией (создание контента самой игрой по заданным правилам, чтобы нельзя было предугадать события, даже если давно играешь), но сделать интересный процедурный генератор оказалось намного сложнее, чем я рассчитывал, тем более что я знаю его правила (знаю, чего ожидать). Делать статичную карту, статичный контент, тем более сюжет - мне совершенно не интересно. Как реализовать "эмерджентность" (чтобы сумма частей давала что-то, чего нет в составляющих её частях) я не знаю.
Мне всё равно, если я никогда никакую игру не доведу до релиза. Не хочу вываливать "абы что, лишь бы выложить". Если получится что-то, что меня надолго зацепит, хотел бы обновлять и поддерживать много лет подряд, но до сих пор ничего достаточно интересного не получилось.
>>1001738
>собиранию предметов
Да, в концепте сильный акцент на коллекционирование, но мне совершенно не интересно собирать заранее известные предметы в заранее известных местах статичной карты. Вот я и застрял на процедурной генерации интересного мира, без которого механики не взлетают.
>>1001744
>богатым и знаменитым
Это неинтересно, я игру интересную хочу, для себя... Иначе зачем это всё.
Для каких-то историй (линейных/нелинейных) в этой концепции есть место, но их нет смысла сейчас писать, если сама концепция в целом не взлетает (для меня лично, как основного игрока).
Впрочем, меня также расстраивает, что мой проект не имеет ни одного шанса стать широко известным по сравнению с аналогами по жанру и сеттингу. Даже если сделаю интересную игру, раскрутить её нереально, если у тебя не целый штат художников, аниматоров и специалистов по спецэффектам... Графика, всё-таки, продаёт игру широкому потребителю (даже если игра полностью бесплатная).
Где взять модельку годотки в норм качестве и с цел шейдером?
https://sketchfab.com/3d-models/godette-rigged-dd05b69799a2438e97c90d166f6e416a
https://sketchfab.com/3d-models/godette-chan-5e5dd8978e21431f992dee953c11558d
100500 лет в гугле. Целл шейдинг шейдером сделаешь.
чето всратые надо 3д научиться быстренько и сделать вам нормальный
>я всегда хотел сделать игру, в которую мне самому будет интересно играть долгое время - в буквальном смысле, а не "вот если бы кто-то такое сделал"
Тогда ты вляпался, пчел. Говорят же - не делайте игру мечты. Пока вы ее делаете она вас заебет, интерес угаснет, игра мечты превратится в игру-рутину. А в лучшем случае вы ее настолько знать будете, что игроком в нее быть уже не сможете.
Мне нравится другой подход - получать кайф от того, как я вижу/представляю как в мою игру играют другие. Вот тут я ебну игрока ловушкой, вот тут он, возможно, посмеется с диалога, вот тут он будет страдать. Это как наблюдать за колонией петов-муравьев. Смотришь как они ползают по новому аквариуму, изучают то, что ты им дал, носят-жуют, строят, с чем справляются, с чем нет. Когда я смотрел летсплеи своих предыдущих игр, которые делали мелкие ютуберы, это был 10 из 10 экспириенс.
> Тогда ты вляпался, пчел. Говорят же - не делайте игру мечты.
А мне наоборот стало гораздо легче работать, когда переключился на игру мечты. Мотивация, желание работы очень выросли, радостно как-то. Раньше шел на компромиссы, пробовал работать в неинтересных для меня жанрах, и это была пытка. Просто нужно быть сдержанным в своих мечтах. Но у меня не игра-симуляция, а нарративная игра. Да, спустя сотни часов разработки и плейтестов я буду знать все от и до, но получу огромную радость, когда другие игроки смогут пережить этот нарративный опыт
братаааааан, какая жиза, пиздец
начал рисовать боссов себе, набросал концепты, сел рисовать под анимирование и анимации и задушился, пойду поиграю во чтонибудь или лучше вообще отдохну от пеки недельку, потом со свежей головой сяду рисовать
Последний раз я покупал игры году эдак в 2005, и тогда они стоили 70 рублей за диск, а на диске могло быть много игр
Ну так и не жалуйся, что игры говно. Ты игры не покупаешь, а покупают пидарасы при бабле, и пидарасы при бабле заказывают музыку. Хочу, говорит, чтобы бабы были страшные мужеподобные, сделой. И деньги швыряет в разраба.
>Блеее, оказывается самое сложное не игру сделать, а нарисовать нормальные ассеты...
Авторы халвера и майнкрафта передают привет.
Не выебывайся и делай игру про кубы.
Да я фан-игру делаю, там кубами не отделаешься, иначе будет неузнаваемо (разве что если абстрактный стиль выбрать). Кстати об этом, насколько велика вероятность, что меня взъебут валвы за фан-игру по TF2? Бесплатную канеш, но в мире копирастов это вроде не смягчающее обстоятельство. И насколько толерантны к такого рода играм на итчио читай: не снесут ли автоматом через 10 минут?
>И насколько толерантны к такого рода играм на итчио
Из-за фан-игры по ФАНКО ПОП у итча недавно домен отняли.
В прошлом месяце выпустил фан-игру на итче, полет нормальный. Там даже отдельный тэг для такого есть.
> их нет смысла сейчас писать, если сама концепция в целом не взлетает (для меня лично, как основного игрока)
Я вот этого не понимаю. Наверное мы с тобой действительно мыслим по разному. Для меня истории и геймплей тесно переплетены и я создавая геймплей одновременно создаю историю, которая этим геймплеем реализуется, затем, продумывая историю дальше, я нахожу идеи для развития геймплея.
Например. У этой тян на видосах есть некий реактивный баллон на спине, из которого вылетает струя, когда ты разгоняешься. Не знаю, сам ты это делал или скачал, но просто наблюдая за этим баллоном я уже напридумывал у себя в голове идей, как этот баллон крафтить, откуда он взялся, как он встроен в экономику, какие есть стратегии его прокачки. Если это начать подробно расписывать уже будут несколько длиннопостов. Плюс возникают такие уже побочные сюжетные вбросы типа, на одном из островов хижина в которой чертёж мощного реактивного ранца, но чтобы его собрать нужно отправиться вот туда, туда, и еще туда. Поговорить с тем, помочь этой, побороться с теми. То есть просто от одного взгляда на видос сформулировался в голове целый диздок.
В США есть понятие fair use:
https://en.wikipedia.org/wiki/Fair_use
Если ни копейки не берёшь с игроков, не просишь пожертвования и т.д., то можешь любые ассеты из оригинальной игры брать без разрешения. По идее.
Конкретные нюансы нужно изучать, но если ты, для примера, хочешь визуальную новеллу сделать, то нет проблемы использовать скриншоты из оригинала... Огромное количество роликов на ютубе сделаны так, используя оригинальные модели из TF2 в SFM.
Немного сложнее если ты делаешь онлайн-шутер: получается, ты пытаешься перетянуть игроков. Но существует TF2 Classic и Valve их оставила в покое (проблема была в использовании утёкшего кода).
Но если всё же хочешь сделать 100% оригинальные ассеты узнаваемыми, совет: что делает персонажей узнаваемыми? Повтори самые яркие элементы, всё остальное убери. Запоминающиеся персонажи на практике состоят из небольшого числа элементов, комбинация которых делает их уникальными. Если повторишь эти элементы, то персонажи останутся узнаваемыми даже в стиле Майнкрафта.
Итчио никакого отношения к этому вопросу не имеет. Выложенную игру удалят только если получат DMCA, конкретно от сотрудников Valve. В противном случае причины удалять твою игру у итчио просто нет.
Недавний конфликт итча был вызван тем, что DMCA направили хостеру, а админ на хостере поленился и автоматическая система удалила домен по таймеру. Наверное, не помню точно. Т.е. итч быстро на DMCA среагировал, а хостер не справился с автоматикой. Однако, причина была в DMCA от правообладателя. Конкретно в твоём случае инициатива за Valve.
TL;DR: Valve безразлична твоя игра, в худшем случае вежливо попросят удалить и итч её просто удалит. Но вероятность крайне мала, даже если оригинальные модельки из папки игры скопируешь.
Два чаю. Геймплей и нарратив неразрывно связаны, тоже так подхожу к разработке. Да и играть в игры, где одному уделено сильно больше внимания, чем другому, я не могу (конечно, не без исключений). Скажем, ВНки или симуляторы меня не интересуют вовсе
Скоро релиз кандидаты пойдут.
Я не безыгорный, у меня уже есть 4 место на одном из ТВГ. Так что этот гештальт я закрыл. Фдисятке и ниибёт.
Маладца, можешь умирать со спокойным сердцем нет, иди ебашь.
Вот в том и интерес - сделать игру, что не надоест.
>представляю как в мою игру играют другие
Представляю, как игроки ничего не понимают и не справляются - жалуются, ругают меня, ненавидят...
>>1001945
Повезло тебе, раз чётко представляешь "игру мечты". Зачастую мои фантазии слишком расплывчаты, чтоб реализовать их, или реализация не оправдывает мои ожидания и мотивация стремительно улетучивается.
>>1002066
>реактивный баллон на спине
Не баллон, а барабан лебёдки типа пикрил. Просто поленился рисовать трос, отложил на потом. Сбоку вылетают типа искры/пыль из двигателя лебёдки.
Крафтить лебёдку не нужно, это основное средство перемещения. Разве что апгрейды к ней добавлю...
>мощного реактивного ранца
Нет, никакого джетпака и даже вингсьюта не будет. Подобные механики убивают фановый геймплей с верёвкой. Для наглядных примеров, гугли критику вингсьюта в игре Spider-Man 2, а также (частично) критику Oppressor Mk II из GTA Online.
Есть такой мем, "игроки оптимизируют фан из игры":
>Optimizing the fun out of games refers to players choosing strategies that prioritize efficiency and success over enjoyment, often leading to a less engaging experience. Game designers face challenges in creating experiences that encourage risk-taking and fun, as players may gravitate towards safer, more boring tactics instead.
В чём фан прыжков с верёвкой? Ты летишь по дуге, с минимальным контролем траектории, не зная точно, получится ли добраться: ты непрерывно рискуешь сорваться в пропасть или разбиться о препятствие. Траектории интересные и тебе в кайф их нарезать, возможно, пытаться провернуть какой-то "трюк". Эффективность отходит на второй план - динамика перемещения компенсирует его неэффективность.
С джетпаком ты просто зажимаешь кнопку "лететь", летишь по прямой. В худшем случае у тебя топливо закончится, но обычно оно бесконечное. Разбиться невозможно, ошибиться негде, а главное - наиболее оптимальная траектория, тупо по прямой. Да, это эффективно, но не эффектно, и очень скучно, ведь перемещение наиболее предсказуемое, рутинное.
Теперь самое интересное: если в игре реализованы одновременно оба способа, какой выберут игроки? Внезапно, игроки выбирают скучный способ и потом жалуются, что игра слишком скучная. Почему они не выбирают фановый способ? Потому что он не такой эффективный, как скучный. Кажется, что это некий парадокс, но это реальная психология игроков.
Я всё это не просто так расписываю здесь. Вот ты описываешь способ создать механики из сюжета, хвастаешься, что, мол, у тебя на ровном месте
>сформулировался в голове целый диздок.
Но ты не предусмотрел, что джетпак будет унылым убийцей фановой механики с верёвкой. Ты просто притянул за уши джетпак лишь бы что-то притянуть. Наверное, эту ошибку и большие компании делают (Rockstar с их супер-тачками, убивающими фан от базового геймплея игры), но это не делает её менее фатальной для геймдизайна игры. Особенно инди.
В общем, что я хочу сказать? Несложно выдумывать миллион "гениальных" идей типа "сделать джетпак и раскидать по миру квесты для его крафта". Сложно соединить эти идеи в чёткий геймдизайн, отбросив несочетающиеся механики, квесты, истории и т.д. Механика джетпака не работает с верёвкой тупо по определению - и поэтому её быть не должно, и нет необходимости выдумывать квесты про джетпак.
Вот поэтому я не спешу наваливать кучу рандомных механик, историй и прочего. Сначала нужно базовые механики реализовать, на которых я давно застрял... Декорации определить. Если декорации (острова) чрезвычайно скучные, то механики не работают. Та генерация мелких камней между крупными вышла внезапно интереснее, чем я оценивал изначально; соответственно это повлияло на механику верёвки (восприятие, ограничение расстояния/скорости). На удивление, даже такие простые на вид элементы геймплея тесно друг с другом взаимодействуют.
>С джетпаком ты просто зажимаешь кнопку "лететь", летишь по прямой. В худшем случае у тебя топливо закончится, но обычно оно бесконечное. Разбиться невозможно, ошибиться негде, а главное - наиболее оптимальная траектория, тупо по прямой. Да, это эффективно, но не эффектно, и очень скучно, ведь перемещение наиболее предсказуемое, рутинное.
Ты в первый элекс поиграй. Я после него какое-то время вообще не мог представить игры без джетпака.
>меня взъебут валвы за фан-игру по TF2?
Валвы не нинтенда. Они в неё ещё и поиграют всем офисом.
Но на всякий случай ты можешь спросить лично у Габена. Он на почту отвечает, говорят.
>>1001834
>не делайте игру мечты. Пока вы ее делаете она вас заебет, интерес угаснет
Хм. Я это как-то иначе вижу. Да, я делаю игру, в которую мне же самому было бы интересно играть - но
а) Не для того, чтобы в неё играть, а чтобы поделиться своим интересом с другими;
б) В играх, в которые мне играть не интересно, я не разбираюсь, так что я выбираю делать что-то в рамках своей компетенции;
в) Сделать "как для себя" - это значит наилучшим образом, не на отъебись, а чтоб себе же любимому результат понравился.
> в первый элекс поиграй
Пацаны, не надо, не делайте этого, достаточно первых минут видоса глянуть
https://www.youtube.com/watch?v=rfbO8sNgwgk
где видно, что там джетпак с небольшим запасом топлива.
Это можно было сразу написать.
Делайте игры, пацаны, не отвлекайтесь.
>Валвы не нинтенда
https://gamerant.com/counter-strike-go-cs-classic-offensive-mod-blocked-steam-valve/
Тоже пытаюсь с нейронкой подружиться. Ты какую используешь, локально ее у себя развернул?
Моего железа недостаточно для локалки. Просто в вебе, дипсик р1 и гпт о3-мини. Обычно сразу обоим вопрос закидываю.
локальные 7b, который в ollama, вообще бесполезные бредогенераторы, которые генерируют бред даже по самым тривиальным вопросам. локальные модели не годятся ни для чего, кроме сочинения порноисторий и классификации текста.
как бы так не вышло, что половина таблички - выдуманная чушь
> Просто в вебе, дипсик р1
А какая вариация дипсика р1? Их там много подвидов
>>1002225
> локальные 7b, который в ollama, вообще бесполезные бредогенераторы
Развернул у себя на ПК через LM Studio R1 Distill Qwen 32b и DeepSeek Coder v2 Lite Instruct. Веб версии не изучал, до этого вообще с LLM не работал. Выдают осмысленные ответы, ошибки иногда если и происходят, то из-за того, что превышен предел контекста
>>1002228
> как бы так не вышло, что половина таблички - выдуманная чушь
Справедливо. В любом случае не нужно ответы нейронки за правду принимать, всегда нужно перепроверять все. Часто помогает найти правильное направление, и этого достаточно по сути. Нужно понимать, что это просто инструмент
>А какая вариация дипсика р1? Их там много подвидов
Вижу только две - с галкой deep think и без. Пользуюсь с галкой.
А это бесплатно, без регистрации и смс? Если так, скинь ссылку, пожалуйста. Интересно сравнить ответы моего локального Дипсика и этой веб версии
> скинь ссылку, пожалуйста
Ашотакое? Твой локальный ИИ не может тебе скинуть ссылку?
deepseek.com, я под гугловским аккаунтом зашел, бесплатно. Иногда падает от дудоса и перегрузок.
Спасибо. Протестил, на маленьких вопросах работают практически идентично, слегка отличается стиль изложения, но сущностная часть одинакова. А вот с большими вопросами и парсингом файлов локальная версия справилась лучше. В моем случае, у нее втрое больше размер контекста (он задается вручную в зависимости от железа). То есть, нейросеть больше переменных учитывает при ответе. На практике это означает, например, что она может проанализировать класс, втрое больший того, что может проанализировать бесплатная веб версия. И еще работает быстрее веб версии. Но полагаю, будь у меня среднестатистическое железо, локальная версия была бы не сильно круче
> будь у меня среднестатистическое железо
И тут мы возвращаемся к печальной реальности.
> возвращаемся к печальной реальности.
Реальность такова, что веб версии хватит на подавляющее большинство юзкейсов. А учитывая, что она еще и бесплатная, то те, кто сидят на слабом железе, почти ничего не теряют. Так что вперед делать игры!
Тем не менее мы-то с тобой оба прекрасно понимаем, что без мощного железа успешные игры сделать не выйдет. Максимум пиксельные топдауны на итч.
Если речь про 3D - то да, ты прав. В 2D контексте согласен лишь частично. Все-таки на слабом железе можно справиться и самому, если хватит скилла нарисовать графику или есть возможность привлечь художника. Взять тот же Project Zomboid, как пример. Или Rimworld. Или Prison Architect
Хотя если ОЧЕНЬ захотеть, можно на слабом железе и 3D игру разработать - стилизованную под PS1. Относись как хочешь, но спрос на это есть, и покупают. Недавно вот от разработчика Dusk игра вышла: https://store.steampowered.com/app/2512560/Butchers_Creek/
> Спасибо. Протестил, на маленьких вопросах работают
>>1002242
> 12:56:42
И как вам это всё удаётся, у меня дипсик как лежал, так и лежит.
3д инди тоже хороши. Для меня идеалом 3д-в-одно-ебало являются Short Hike и Tunic. Ну, практически в одно ебало - минус музыка.
Уверен что не блок? В списках РКНа дипсика нет, но все бывает. У меня он до состояния твоего скрина ни разу не падал, максимум бот отвечал про недоступность.
Будет забавно, если он прямо на deepseek.com пытался заходить, а не по полному адресу https://www.deepseek.com/
Что-то мне подсказывает, что так оно и есть :^)
Пидарас. Смейся, смейся, мразь. Написали
>>1002242
> deepseek.com
Я и скопипастил. 30 лет уже как приставка www не обязательна. Расскажи мне, какой я тупица.
Да ладно тебе, не трясись. Никто тебя тупицей не называл, все мы тупим иногда
Она неправильные ответы даёт. Вот оцените скриншот. Она должна была всего одно предложение в ответ напечатать и мы бы вместе заплакали, обнявшись.
Здесь обсуждалась польза LLM чатботов в качестве помощника в геймдеве (на Godot), а не абстрактного собутыльника из твоих влажных фантазий. Даже не понимаю, к чему ты это решил запостить, чтобы что? Пошутить захотелось? Не вижу ничего смешного.
Хочешь, чтобы она отыгрывала робота, лезла к тебе обниматься - так и попроси. Лучше на английском, разумеется. К теме треда это никак не относится.
По моему опыту, она правильно обработала запрос, ответила в соответствии с её системным промптом.
Ошибка в запросе. http://en.wikipedia.org/wiki/GIGO
Не могу понять какая нода имеет приоритет при срабатывании инпута.
Аноним
09/02/25 Вск 15:02:03
№
122
>Чота много карточных игр
Даже слишком. Не боитесь что как с vampire survivors будет, когда на фоне успеха оригинала вылезло столько подражателей, что ниша быстро переполнилась?
Тебе не нужен рейкаст, просто используй сигналы:
https://docs.godotengine.org/en/stable/classes/class_collisionobject2d.html#signals
Сигналы будут приходить на скрипт карточки под курсором мыши или пальцем на сенсорном экране. Аналогично сигналам на Control, но с небольшим отличием: Area2D не сортируются по умолчанию.
Алсо, сигнал input_event реагирует на это:
https://docs.godotengine.org/en/stable/classes/class_viewport.html#class-viewport-method-set-input-as-handled
Но если нужен только первый объект сверху, тогда physics_object_picking_first_only будет достаточно.
Алсо, т.к. мы говорим о CollisionObject2D, вовсе не обязательно использовать Area2D: input_event также приходит на остальные физические объекты в 2D. Наверное, для карточной игры это не так важно...
>>1002617
Помогло, хотя сцена у меня концептуально проще: большая Area2D и мелкие Area2D поверх неё. Мне необходимо было отловить сигнал с мелких раньше большой, но сигнал приходил рандомно. Я погуглил, попробовал решение - всё заработало. Но я даже не пробовал бросать рейкасты, т.к. это бессмысленно.
>>1002671
>ниша быстро переполнилась
А что это меняет? Если человеку нравятся пасьянсы и он хочет сделать свой пасьянс, в чём проблема? Большинство игр ничего не приносят независимо от выбранного жанра - их делают ради удовольствия. В отличие от сюжетных игр, в пасьянсы можно играть бесконечно долго, поэтому как минимум один игрок найдётся - сам автор игры. А раз игра интересна её автору, то и другим может быть интересна... Имеет смысл опубликовать, вдруг кто-то ищет именно её.
Делайте игры для себя, и тогда в них гарантировано будет кто-то играть - как минимум вы сами, но раз вы выбираете свою игру, значит, в ней что-то особенное.
Вот сюжетным играм плохо приходится - зачем мне покупать сюжетную игру, если я могу весь её сюжет бесплатно прочитать на её фанатской Вики? Лол. Да летсплей посмотри и всё, самому играть не нужно...
Да что уж там, в 2д можно просто самому сравнить x,y координаты мыши, там не надо хитрых проекций. Только воспользоваться методом камеры чтобы учесть возможные масштабирование и прокрутку. И уже самому разослать сигнал всем картам.
Зачем изобретать велосипед на костылях, если ты пользуешься готовым движком, где уже есть всё необходимое для решения твоей задачи?
Ты ещё предложи свой тайлмап изобретать:
>Если нужны только тайлы, можно просто рисовать картинки вызовами графического API, не полагаясь на специально предназначенные для этого ноды...
Сначала сделай игру, потом оптимизируешь.
Затем, что в движке есть только средства для обычных задач (кликнуть по одному предмету), а если ты будешь собирать такую механику, то это как раз у тебя будет костыль.
Если привести аналогию, ты хочешь построить клумбу из шин, но у тебя есть только готовые машины, и ты закапываешь их целиком по землю чтобы торчали только колеса.
Что сделать проще прямо сейчас, то и делай.
Если будешь слишком много думать о потенциальных возможностях в будущем, то никогда не сдвинешься с места в настоящем. Сделай что-нибудь, что-то простое, потом будет намного проще переделать - если нужно, поскольку обычно не нужно (идея просто не работает).
Вот input_event использовать легко. Его и используй.
Проще всего привязать к курсору body, и вызывать у него get_overlapping_areas().
>Если ни копейки не берёшь с игроков, не просишь пожертвования и т.д., то можешь любые ассеты из оригинальной игры брать без разрешения.
Поэтому разных модеров подвешивают за яйца, как только они хотят взять текстурки из разных игр.
>Хочу начать заниматься тем, что будет приносить удовольствие
>получилось ли у вас лично заработать денег
>Хочу начать заниматься тем, что будет приносить удовольствие, а не перекладыванием джисонов.
По-моему там предложение в 10 раз выше спроса, судя по вкладке новое в стиме.
>делай порно игоры, точно не прогадаешь
А выкладывать куда?
> Я работаю быдлокодером на петухоне на галере. Хочу начать заниматься тем, что будет приносить удовольствие, а не перекладыванием джисонов.
Без дохода вкатываться в фуллтайм геймдев и стать успешным - то же, что сорвать джекпот в лотерею
> Скажите, получилось ли у вас лично заработать денег в инди?
Пока еще в процессе разработки первой игры. Долгострой, фуллтайм разработка два года уже, сдаю квартиру в аренду и живу на эти скромные деньги. Что получится - не знаю, для меня главное попытаться
Советую тебе попробовать параллельно основной работе что-нибудь поделать. Скорее всего, таски быстро закрываешь, и времени много. Так придет понимание, интересно ли тебе заниматься геймдевом в целом. Если да - тогда уже думай, как перестраивать свою жизнь
>Скажите, получилось ли у вас лично заработать денег в инди?
Заработал 101 бакс.
Нет, инди геймдев слишком маловероятен для основного заработка. Поэтому моя основная тема - вебдев.
Он вряд ли 1.0 версию запилить для стима, иначе надо монетизировать. На самом деле конкуренции ноль, если хорошая игра.
>>1002734
f95, itch, patreon, boosty, sb и т.д
0.1 бесплатно везде, след патчи платные, байтя на подписку на патреоне\бусти\сабскрайбере. Рекламишься в реддите, пишешь остальным порноделам и если есть аудитория репостите друг друга если игры похожего жанра.
Люди годами так получают деньги даже не выпуская игру.
https://www.youtube.com/watch?v=ke5KpqcoiIU&t=11s
Юнькам уже забросил. Слышал Брекейс их любимый тутор, они оценят. Алсо жду очередной наплыв ньюфагов на форумах и реддитах.
Речь про 3D? Возможно, графика, стилизованная под PS1 и boomer shooter-like (Dusk, Iron Lung, Hrot). Возможно, это подвид лоуполи, но чаще всего там граней еще меньше, чем в среднестатистическом лоуполи. Текстурирование куда важнее. П>>1002831
люс можно использовать billboarding (2D спрайты в 3D мире)
Есть, называется стилизованный лоуполи.
Про любой, на самом деле. Со спрайтами проблема - их нарисовать надо. А 3д примитивы я непосредственно в годоте накидать могу, и при грамотной цветовой палитре оно выглядит сносно. Тут на втором пике >>1002831 текстур вообще нет.
Тут от твоих умений зависит. Мне проще 2D спрайт сделать, чем красивую лоуполи 3D модельку. Если отталкиваться от лоуполи, то вариант на втором пике >>1002831 правда неплох. Там, кажется, помимо контрастных цветов еще и cel shading используется. Для игры с изометрической или какой-нибудь еще отдаленной перспективы норм. Если от первого или третьего лица - не факт, что красиво будет, надо чекать. В любом случае, текстурировать PS1/boomer shooter модельки довольно просто, так что все осуществимо. Имхо в инди важна стилизация и общее графическое направление проекта, и сегодня руки совсем развязаны. Если у разработчика есть вкус и время поработать над ассетами, можно сделать приличную графику для любого жанра. Главное, чтобы было интересно (и играть тоже)
Вот, например, ретро survival horror в 2024: https://store.steampowered.com/app/1996010/Crow_Country/
Это я к тому, что сегодня, будучи инди разработчиком, можно добиться приличной графики в игре любого жанра. И это не будет стоить космических усилий, нужно просто искать возможности
Классно! План по арту для переката перевыполнен. Но ты не останавливайся, лору развивай.
По этому поводу у них пердаки перегорели ещё 9 месяцев назад, когда он ожил в нашем лагере.
Рад, что пригодилось. Останавливаться - ни в коем случае! Во мне уже пробудился спортивный интерес: насколько далеко удастся зайти, учитывая, что первую версию тренировал на всего лишь одной картинке? Буду иногда присылать что-нибудь в тред
>Crow_Country
Охуенно. Похоже на то, что делаю я. Надо пройти, поворовать идеи. Спасибо.
https://studio.blender.org/projects/project-dogwalk/
>стиль, с которым работать быстрее-удобнее
Зависит от твоих навыков. Что тебе удобнее? На мой взгляд, лоупольки без текстур и так самое простое... Главное разобраться в инструментах - количество полигонов значения не имеет, если генерируешь их математическими формулами и модификаторами.
Недавно зародился стиль, называемый "AI slop": генеративным ИИ создаётся нечто непонятное и используется без дополнительной обработки. Если позиционировать свою игру как "slop", тогда всё, что требуется - это промптить и вставлять арт в движок. Естественно, это нишевый стиль, на любителя, но он имеет право на жизнь, как лоуполи с пиксель-артом. Главное - использовать одну и ту же нейронку, строго фиксировать гиперпараметры и промптить в очень определённом стиле, чтоб арт был однородным.
Можно поспорить, что генеративный ИИ лучше, чем ассетфлиперство. Потому что ассетфлипер ограничен имеющимися у него моделями и по определению не способен (не хочет) приводить их в единообразный, согласованный стиль. Генеративный ИИ же, по идее, генерирует всё в одном стиле, поэтому он лучше в контексте визуальной целостности для новой игры. Приблизительно как костыли лучше, чем ползать.
Но понятно, что это чисто на любителя, как граффити какие-нибудь, или пластилиновая/бумажная графика.
>>1002832
>графика, стилизованная под PS1
>Текстурирование куда важнее
Рисовать текстуры сложнее, чем лепить меши. Кто пробовал хэндпейнт текстуры, понимает, насколько сложно добиться приличной, стабильной картинки. Лоупольки без текстур - это геометрические фигуры, ничего проще них нет (разве что генеративный ИИ).
>>1002834
>Со спрайтами проблема - их нарисовать надо.
В 2D тоже можно обойтись примитивной геометрией. Векторная графика имеет крайне низкий порог входа: можно рисовать шедевры самой дешёвой мышкой.
>>1002871
>проще 2D спрайт сделать, чем красивую лоуполи
Тут нужно ещё принимать во внимание возможность рендерить лоуполи с любой стороны и анимировать скелетом в 3D. Скелеты в 2D сложнее, ограниченнее, выглядят неестественно и поэтому проигрывают 3D. Поэтому, возможно, вложиться в 3D лоуполи лучше.
>Если от первого или третьего лица - не факт
Нормально всё, видел достаточно таких игр.
Что?
Игра грю хорошая вышла на годоте, можете опускать юнити и анрило чмонек, когда они вас подъябывают, что на годоте игор нет
>>1003177
https://store.steampowered.com/curator/41324400-Is-it-made-with-Godot/#browse
Открываете top sellers и наслаждаетесь. Для меня было неожиданностью что даже вебфишинг, который из каждого утюга лезет, на годоте оказался.
Стимдб не всегда детектит движок. Многих популярных игр из списка куратора тут нет. Но как дополнительный список неплох.
Ты ненормальный?
У меня СЕО майндсет просто https://store.steampowered.com/app/1388770/Cruelty_Squad/
Не позволяй графическому стилю обмануть тебя, это один из лучших иммерсив симов современности
Это уровень Ван Гога. Многие просто не считают его художником, тем не менее сейчас он стоит бешеных денег.
С сайта. Стим обновит ее невовремя, да и еще там что-то по другому, не помню, установки C# шаблонов нет что ли.
Не нужно загружать версию из Стима. Как и в случае с Блендером, это привнесет больше проблем. Загружай с сайта последнюю стабильную версию - 4.3. Совсем скоро выйдет 4.4, сможешь легко на него перейти. Из основных изменений - появится UID система для ассетов, подобная Unity
У Годота две версии - с поддержкой C# и без. Если делаешь что-нибудь серьезное, то Шарп нужен. Но для большинства простеньких игр можно и на gdscript, он похож на Питон, и очень легко осваивается
Так говорят сишарп нинужон, прогать гдскрипте же? Кстати, иде для написания кода в комплекте идет?
Сишарп не нужен, я просто к тому что в стим версию сложнее что то доустанавливать.
ИДЕ для гдскрипта в комплекте.
Ах да, самое важное - под что делать игры, от этого зависит выбор версии.
Я попробовал 4-ку, и ВСЕ ЕЩЕ считаю что для веба и мобилок лучше оставаться на 3, ДАЖЕ при том что там меньше аддонов и надо js-либу под звук. 4-ка это чисто под проект мечты на пека-консоли с АА+ графоном.
В течение месяца-двух, скорее всего. Уже beta3 билд, потом будут rc билды - release candidate. И потом уже релиз, когда все будет протестировано. Можно бету уже сейчас использовать, но новичку не стоит
> Если делаешь что-нибудь серьезное, то Шарп нужен.
Не согласен.
Если делаешь что- нибудь серьёзное, нужно писать компилируемый модуль на с++, всё остальное прекрасно покрывается гдскриптом. Шарп туда завезли для утят, чтоб не крякали. Шарп по сути такой же модуль на крестах с подключённым дотнет-рантаймом. А если нет разницы, зачем тащить дотнет туда, где достаточно чистого си?
Нет, не согласен.
Фирма наконец сделала официальный менеджер пакетов для венды. Ладно, забей, подрастёшь узнаешь.
Алсо, за день перенес проект с 4 на 3. Закинул модельки, вручную пересобрал сцены, заменил контроллеры-аддоны-шейдеры на аналоги.
> Если делаешь что- нибудь серьёзное, нужно писать компилируемый модуль на с++
Если речь про трудновычислимые задачи, тяжелую математику, огромные генерации - да, так и есть
> всё остальное прекрасно покрывается гдскриптом
В gdscript даже нет интерфейсов. Как и IDE с отладкой. При работе над масштабируемыми проектами - это необходимость
> Шарп туда завезли для утят, чтоб не крякали
> А если нет разницы, зачем тащить дотнет туда, где достаточно чистого си?
Нездоровый максимализм. Исходя из твоей логики, почему бы не использовать love2d, Defold на .lua? Зачем Годот и gdscript? Это еще проще, а модули на C/C++ можно написать тем, кому это необходимо
Любому, кто работал с по-настоящему большими проектами, должно быть очевидно, что C# -> gdscript. С таким мнением и останусь, а ты можешь остаться со своим. Не будем срамить наш прилежный тред
> кря интерфейсы, кря масштабирование
Абсолютно не убедительно. Остаюсь при своём.
>нет интерфейсов
Можешь объяснить и расписать когда и зачем они тебе в последний раз понадобились в годоте?
> Абсолютно не убедительно. Остаюсь при своём.
Пожалуйста. Тебя никто не заставляет пользоваться тем, что тебе не нужно. В треде высказались, почему Шарп использовать нецелесообразно, я высказался почему целесообразно. Каждому следует решить самостоятельно, исходя из своих запросов и проекта, над которым ведется работа
>>1003371
Очевидный, возможно, до неприличия академический пример интерфейса. Работаю над 2D top-down RPG, в игровом мире множество интерактивных объектов, которые могут получать урон: персонажи, предметы персонажей (которые или на них надеты, или лежат в инвентаре, или выброшены на землю), динамические объекты окружения (деревья, двери, различные контейнеры, в которых находятся предметы), динамическое окружение, привязанное к тайлам (лед, заросли, магические барьеры) и много что еще. Все из перечисленного может получать урон. Единожды реализовав интерфейс ITakeDamage (и метод TakeDamage), имплементировав его в необходимых классах, я добьюсь единообразной реализации данной механики для всех упомянутых объектов. При необходимости можно переопределить TakeDamage в любом из классов. Это очень гибкая структура для системного подхода. Теперь, когда персонаж замахивается мечом, я могу просто считывать все объекты, которые встречаются по траектории удара и наносить им урон. По аналогии у меня реализованы лечение/починка и перемещение любых динамических объектов. Это стандартная практика в играх
Интерфейсы - классическое понятие в программировании и куда глубже того, что я описал. Это лишь частный наглядный пример
>множество интерактивных объектов, которые могут получать урон
https://www.youtube.com/watch?v=74y6zWZfQKk
Интерфейс зачем для этого? TakeDamage() просто в каждом классе делай и все. Такое чувство, без наезда, просто так показалось, что ты сам особо не понимаешь зачем нужны интерфейсы, ну вот, типо, делают их и я делать буду. А надо или не надо это уже не мое дело, бест практикс
Вернее в каждом классе, где тебе он какой то измененный этот метод нужен, а так по дереву наследования у самого родителя реализовал и все
Интерфейс и композиция - разные понятия и нужны в разных ситуациях. Ничего не мешает использовать их совместно. В больших проектах, чаще всего, они так и используются. И мой не исключение. Я же нигде не утверждал, что игнорирую композицию и другие практики. Но и интерфейсы использую. Меня попросили дать пример - я дал пример. Хватит видеть в этом красную тряпку и пытаться выяснить, какой подход лучше и кто прав, а кто нет
>winget install godot
Не поставишь ты так, зачем обманываешь новичка?
>Если делаешь что-нибудь серьезное, то Шарп нужен
Если привык к шарпу, то шарп нужен. В остальном - только лишняя ёбля с зависимостью, увеличение размера билда и лишняя зависимость.
>gdscript, он похож на Питон
Сто раз говорили, что из похожести там - разве что отступы. Нет же, обязательно найдётся умник, не знающий оба языка одновременно, но задвигающий, что они похожи.
В гдскрипте больше от луа, чем от питона так-то.
>Гдскрипт нет IDE с отладкой
Что. За. Хуйню. Ты. Несешь?
https://docs.godotengine.org/en/stable/tutorials/scripting/debug/overview_of_debugging_tools.html
Брейкпоинты, вкладка дебаггер показывает стек вызовов, локальные, глобальные переменные, содержимое объектов.
Вкладка Remote. Показывает все дерево сцены.
Десятки аддонов на любой чих - позволяющие рисовать стрелочки-векторы и любые данные, консоли.
В принципе это и не особо нужно потому что учитывая легкость годота, это прямо на лету добавляется - кидаешь Label и пишешь в нее, прикрепляешь ноду со стрелкой и поворачиваешь как надо. Пиздец.
В 4-ке добавили expression evaluator, в 3-ке вроде нет, или был плагин похожий.
Что такого надо нахуевеврить чтобы таких возможностей отладчика не хватало? Я не представляю. Или это какой то особый вид Debugger-Driven Development? Написать дичь а потом смотреть что в переменных оказалось? Так лучше головой сначала думать.
> Сто раз говорили, что из похожести там - разве что отступы
Вопрос дискуссионный. Буквально в документации сравнивают gdscript с Python: https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/gdscript_basics.html
В lua даже опционально статической типизации нет. Все скриптовые языки схожи.
Энивей, вот же делать тебе нехуй, кроме как до такой мелочи доёбываться. Лучше бы игрой своей занимался, чем пукал в пустоту.
Естветсвенно они похожи. Нет, не только отступы, но и основными конструкций. Например for i in range(10): и прочее. match x: case 5: pass. Только тролль будет говорить что они непохожи, когда у них большинство основных конструкций общие.
Конечно есть фичи которые есть только в питоне (как распаковка a,b = func() ) и есть фичи только гдскрипта как сигналы. Но это уже то что навернуто поверх основы.
Традиция такая. Дать новичку удочку, чтобы с рыбой он разобрался сам.
> winget install godotengine.godotengine
Тебе гдскрипт удалили и уже Visual Studio накатывают или откуда столько желчи? Спок.
Освободи свой разум. Тебе нужна концепция интерфейса, а не реализация интерфейса из C#. Он там нужен потому, что C# компилируемый язык и все должно быть объявлено заранее и нет динамической утиной типизации.
https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/gdscript_advanced.html#duck-typing
В гдскрипте проверка на интерфейс была бы что то вроде obj.has_method("TakeDamage")
Или можно какой нибудь линтер сделать, когда ты пишешь var Interfaces="IDamageable, IWalkable" и он плагин пройдется по скриптам и проверит наличие нужных функций, причем это можно не использовать в релизе.
А про компоненты писали в прошлом треде, ведь твой интерфейс нужно вписывать в какой то класс, значит ты на каждого врага пишешь новый класс и даешь ему имя, даже если у них одинаковое поведение, а на компонентах этого не нужно, поведение описано в компонентах (и системах их обрабатывающих) а само наличие компонент и определяет итоговое поведение юнита, просто у этого класса не будет имени, будет сущность которая получает урон и ходит (может быть стражник, может собака)
По существу ответ будет, чего именно "нет" в дебаггере? Не люблю голословных пиздаболов просто.
>Лучше бы игрой своей занимался
Лежу с температурой, пытаюсь персонажа рисовать. Художник из меня херовый, немножко порисую - и лезу на двач сраться.
>в документации сравнивают
ctrl+F Python: 4 (четыре) упоминания:
1. It uses an indentation-based syntax similar to languages like Python
2. GDScript is entirely independent from Python and is not based on it.
3. These operators have the same behavior as C++, which may be unexpected for users coming from Python, JavaScript, etc.
4. The self variable is always available and is provided as an option for accessing class members, but is not always required (and should not be sent as the function's first argument, unlike Python).
Ух вот же ж сравнили так сравнили! Прямо лоб в лоб.
> Лежу с температурой, пытаюсь персонажа рисовать. Художник из меня херовый, немножко порисую - и лезу на двач сраться.
Желаю поскорее выздороветь. Сраться необязательно. Твою позицию услышали, она имеет право на жизнь, ровно как и отличная от твоей. Ничего ужасного здесь не написали, просто два разных подхода к одной проблеме, и оба правильные
>>1003539
У меня просто установлено через scoop, и пара версий через godot manager https://github.com/eumario/godot-manager/releases
Но я бы не стал новичку советовать эти два варика. Там подводных много.
Бляя ты заебал.
Это не просто похожие языки, это почти одинаковые языки.
Мне кажется, получение урона - плохой пример:
>персонажи
Должен красочно упасть на землю в лужу крови и превратиться в "контейнер" или разбросать лут.
>предметы персонажей (которые или на них надеты, или лежат в инвентаре, или выброшены на землю)
Должны заменить себя на "мусор", либо исчезнуть, освободив ячейку инвентаря или экипировки.
>динамические объекты окружения
Сильно зависит от типа объекта:
>деревья
Оставляют пень и разбрасывают лут (брёвна), либо заменяются сгоревшей версией, дропающей уголь. Возможно, просто исчезают, если лут не нужен...
>двери
Заменяются сломанной версией или исчезают.
>различные контейнеры, в которых предметы
Исчезают, разбрасывая вокруг себя предметы. Или превращают предметы в мусор, затем выбрасывают.
>динамическое окружение, привязанное к тайлам (лед, заросли, магические барьеры)
Здесь ты обращаешься к тайлмапе, а не к отдельным тайлам, и уже тайлмапа определяет, что ей делать.
>>1003447
>Интерфейс и композиция - разные понятия
А что, если ты хочешь реализовать неуязвимость? Получается, нужно делать проверку if not immortal. Компонентный подход позволяет просто удалить обработчик урона и ВНЕЗАПНО персонаж перестает получать урон. С интерфейсами в ООП так нельзя:
>actor.gd:
>var health: Health
>func make_immortal() -> void: health = null
>weapon.gd:
>func hit(target: Object) -> void:
>_ var health := target.get("health") as Health
>_ if health: health.take_damage(damage_value)
Т.е. композиция более гибкая, чем интерфейсы.
Далее ты можешь реализовать, например:
>class_name HealthActor extends Health
>class_name HealthItem extends Health
>class_name HealthChest extends Health
И они все будут взаимозаменяемы.
А после того как познакомился с типаж-ориентированным ООП - нет возврата уже к класс-ориентированному ООП.
Представьте себе, типажи + компоненты на структурах. Но в годоте такое будет не скоро.
Хотели трейты сделать же. Кто-то из знающих людей что-то говорил про УЖЕ ВОТ-ВОТ после 4.4, нужно только потерпеть
>возврата к наследованию
Насследование удобнее компонентов в прототипах. В большинстве случаев дробление кода на 100500 независимых компонентов только вредит проекту.
Я как-то попытался разделить контроллер на 4~5 компонентов-состояний конечного автомата, но не получилось восстановить исходное поведение, а перемещаться между 5 скриптами сложно. Так что выбросил компоненты-состояния - пока не нужно расширять контроллер (в текущем прототипе).
Сейчас мне нужно одну систему с нуля практически переделывать из-за того, что мне приходится менять несколько отдельных скриптов ради одной мелочи...
>типаж
Как это вообще гуглить по-английски?
Я знаю, что есть альтернативы классовому ООП, но, насколько мне известно, эти альтернативы устарели и больше не используются (аналогично старым ЯП). Например, видел ООП в языке Ada - неудобно...
>на структурах
Избыточное ограничение. Методы Dictionary бывают чрезвычайно полезны; от "структур" никакой пользы. Внутреннее устройство тебя волновать не должно...
Мне кажется, ты просто озабочен преждевременной оптимизацией. Тогда просто пиши игру с нуля на C...
>познакомился с типаж-ориентированным ООП
Познакомь и меня. Что за зверь?
>Traits
Так это одно и то же практически:
>Traits differ from interfaces in that traits can provide both method signatures and full method implementations, while interfaces typically only define method signatures without any implementation. Additionally, traits allow for more flexible code reuse and can include state, whereas interfaces are primarily used to enforce a contract for classes.
Как это ведёт к полной бесклассовости в ООП?
Мне казалось, ты имеешь в виду отказ от обычных ключевых слов типа "class", а также понятия "метод", которые приняты в типичном классовом ООП.
>>1003648
Мне кажется, он имеет в виду это:
https://github.com/godotengine/godot-proposals/issues/6416
> Как это ведёт к полной бесклассовости в ООП?
Так там же написано. Ты уверен, что знаешь английский?
> traits allow for more flexible code reuse and can include state, whereas interfaces are primarily used to enforce a contract for classes
> Мне казалось, ты имеешь в виду отказ от обычных ключевых слов типа "class", а также понятия "метод", которые приняты в типичном классовом ООП.
Да, я именно это имею ввиду.
> godot-proposals/issues/6416
Там какой-то дурачок намешал в кучу всё подряд.
В типажовом ООП сущности не extends а implements. Щас накатаю приблизительный псевдокод.
> не extends а implements
А, окей, недочитал, implements он туда тоже намешал.
>Там какой-то дурачок намешал в кучу всё подряд.
Так-то это основной разработчик гдскрипта.
Что-то типа JavaScript?
В JavaScript ты можешь в любой момент добавить совершенно новое поле и метод к любому объекту. Практически то же самое, что Dictionary. Хм... Вроде возможно и в GDScript провернуть через Callable?..
В любом случае, это не избавляет от классов. Ты объявляешь класс, который включает в себя набор характеристик (traits). А уже потом создаёшь новый экземпляр класса. Ты можешь, конечно, добавлять характеристики в рантайме (как поля в Dictionary), отказавшись от создания новых классов, но в чём преимущество? По-моему, это только недостаток - невозможность объявлять классы до экземпляров.
Сначала придумали объекты, потом классы. Классы необходимы, чтобы создавать объекты по шаблону. Кажется, классы - просто улучшение системы типов.
Можно еще про partial class почитать. Но шарпыненужоны в пролете, конечно. Может через пару годиков вымолите у Хуана что-нибудь похожее.
>Traits
И зачем для этого какая то отдельная сущность, которая и так есть в утиной типизации?
...придумал наглядный пример.
Вот у тебя есть код:
>var number: int = 0
0 - это объект, а int - это класс (тип).
В бесклассовом языке у тебя только одно число - 0.
С классами можно записать в number любое число.
Так что отказываться от классов нерационально.
>зачем для этого какая то отдельная сущность
Вот, для примера, мой код: >>1003615
>actor.gd:
>var health: Health
>func make_immortal() -> void: health = null
>weapon.gd:
>func hit(target: Object) -> void:
>_ var health := target.get("health") as Health
>_ if health: health.take_damage(damage_value)
С поддержкой GDScript можно было б сделать так:
>actor.gd:
>implements Health
>func make_immortal() -> void: unimplement(Health)
>weapon.gd:
>func hit(target: Object) -> void:
>_ object.take_damage(damage_value)
Т.е. просто чтоб запись короче была, как я понял.
На счёт unimplement сомневаюсь, это возможно?
>>1003685
https://youtu.be/LtmdRmJtJHc
Давно так не смеялся.
Ну так вот - надо на компе запустить хром, на мобилке включить опции разработчика и USB debugging, подключить кабелем, и вуаля, компьютерный хром показывает мобильный хром включая рендер с вкладки и консоль.
Те ассеты, которые каждый месяц раздавали в Анриле, сконвертнулись в Standard лицензию на fab.com. А она не запрещает их использование в других движках, лол.
(Нюансы с теми что делали сами эпики - они вроде дополнительно ограничивали лицензией; надо смотреть в других не ограничивал ли автор тоже; и второе - там какие то условия что нельзя делать на них редакторы/генераторы, результат которых потом пользователь сможет экспортировать. То есть в игре можно, а вот кастомный уровень которым игрок может поделиться - под вопросом.)
Вот тут так же товарищ считает - https://www.reddit.com/r/unrealengine/comments/1i7lq6w/fab_assets_in_godot/
Ого, можно легально перелить терабайты этой хуйни в юнити и годот? Ну кроме той, которая про игровую логику. На ёбаных блюпринтах.
Все так. А если у тебя не веб игра, то таким же образом на мобилке ремот дебаг запускается. На годоте оч удобная мобильная разработка.
Ну вот на первый взгляд да. Я не юрист конечно. Вот тут например пишут
https://forums.unrealengine.com/t/megascans-license/2081542
Что даже Quixel полученный через анрил (не через их сайт), который раньше был под UE-only лицензией, если сейчас перескачать, то он пойдет под Standard FAB лицензией.
Есть неоднозначности например про модельки из Paragon, потому что раньше они прямо говорили что это только для UE. Но сейчас то там тоже Standard Fab. Я бы на всякий случай не трогал эпиковское.
Еще пишут что в лицензии ограничение на доход в $100.000, но так же пишут что это распространяется на момент "забирания" бесплатного ассета, то есть если забрал когда был ньюфагом, а потом разбогател, то вроде как не появляется ретроактивно обязанность платить роялти.
На реддите полно post mortem разборов. От себя добавлю такое: почти все игры, за разработкой которых я следил, смотрел девлоги и думал "ого, этот чувак очень крут, офигенная идея и реализация, мне не сравниться" - почти все они спустя год после релизов имеют <50 ревью в стиме. Я считаю это провалом.
Авторы стардью валлей, андертейлов и вебфишингов выиграли лотерею. Чего там, обычная лотерея разумней чем геймдев-с-мечтой-взлететь, ведь лотерея не требует от тебя 2-3 года нонстоп въебывания за пекой.
Але, это тред по годоту, причем тут твои истории о которых невозможно молчать
>>1004102
Этим игорём был толщход во вселенной наоборот.
>>1004105
Нет, увы, я в сердцах удалил все файлы.
На реддите не сижу, потому не знал. Спасибо, что поделился (и своими наблюдениями тоже)
Историй успеха там по-прежнему больше, или они просто в топе благодаря лайкам, но все равно много любопытного материала для чтения. Буду проверять иногда
>>1004102
Спасибо тебе, но решение одно - придумать новую концепцию. Проблема в том, что я осознанно отказался от важной механики, которую ожидают увидеть в каждой игре жанра. Мне казалось, ее можно заменить другими механиками. Но это не сработало, некоторые жанры просто по определению должны иметь определенные наборы механик, иначе сломают весь игровой цикл
>>1004105
Исходники может прислать? Чтобы наверняка
Энивей, моя история - еще одно напоминание, что нужно не забывать показывать свои задумки другим людям. Все, кто поиграли в мой прототип (13 человек), указали на одну и ту же проблему. Да и я сам о ней догадался, когда собрал механики воедино. По отдельности механики могут быть прекрасными, а в сумме - не работать
Да да, конечно, и скринов не осталось, и бэкапов, и набросков, и файлы не восстановить.
Короче очевидный вброс.
>тратили месяцы или даже годы
>Жаль, что никто не любит рассказывать
Вот видео на эту тему, поясняет суть работы:
https://youtube.com/watch?v=kMDe7_YwVKI
Главное: «fail faster, follow the fun».
1. Делай прототип как можно скорее.
2. Прототип не фановый? Изменяй его.
3.а. Чуешь фан? Фокусируйся на фане.
3.б. Совсем ничего не выходит? Бросай.
4. Повторяешь с пункта 1 до успеха.
Планировать ВСЁ заранее - рецепт провала.
>>1004074
>Очень долго думал о игре
>полугода проработал в таком режиме
>Выявил слабую сторону проекта
Ты попал в ловушку избыточного планирования.
>думаю, что делать дальше и делать ли вообще
Что тебя максимально привлекает в твоей игре?
Сфокусируйся на том, что тебя в ней привлекает.
>>1004103
>Але, это тред по годоту
Это тред годотеров. Тёплый, ламповый, твой.
Алсо, он точно на Godot работал, я видел видео.
>>1004116
>толщход во вселенной наоборот
А в чём там проблема-то? Норм концепция.
>я в сердцах удалил все файлы.
Ну и дурак. Я все свои неудачи сохраняю.
Впрочем, не страшно, это же только прототип.
>>1004124
>осознанно отказался от важной механики
У тебя ж главная механика - копание в Толще, не?
Поиграй в аналогичные игры, их уже несколько...
>иначе сломают весь игровой цикл
Такого не бывает. Цикл либо есть, либо его нет.
Игровой цикл Толщеходов (как я его помню):
1. Закапываемся в Толщу.
2. Ищем цель - полость в Толще.
3. Пробиваемся к ней на толщеходе:
- уворачиваемся от уплотнений,
- торпедируем противников.
Всё это с помощью радара.
4. В полости (планета наоборот):
- выполняем квесты (сюжет?),
- ремонтируем толщеход,
- заправляемся и т.д.
5. Повторяем цикл с самого начала.
По сути это поводная лодка, только подземная.
>указали на одну и ту же проблему
Какую проблему-то? И почему не исправил?
Я лично не вижу проблем в этом концепте.
>механики могут быть прекрасными, а в сумме
Бред. Фановые механики фановы всегда и везде.
>>1004134
Не трогай его, он наш шиз - местный олдфаг.
Сожалею ему, мне нравился концепт его игры.
Вряд ли кто-то другой вспоминает толщеходы...
>просто делай прототип
>просто делай фан
>вот видишь, эта игра стала популярной, потому что ее разработчик просто делал фан!
да не работают эти простые советы от диванных экспертов. хватит повторять эту чушь.
работают, просто идет естественный отбор и выстреливают единицы благодаря удачно сложившимся случаям.
у древнего степашки могли быть каменные яйца не чувствующие боли, охуенно полезная фича. но она не спасла от пасти саблезубого тигра. а рамзанчик с мягкими чувствительными яичками успешно осеменил прото-гориллу, пока степашку хавал тигр, и вот мы здесь
>благодаря удачно сложившимся случаям
Нет, на самом деле есть чёткие причины успеха, но большинство инди даже не пытается эти причины проанализировать и использовать в свою пользу. Банальным маркетингом мало кто занимается, ЦА исследовать - вообще не про инди. Цепляются за "гениальную" идею и получают унылый проект...
>каменные яйца не чувствующие боли
>полезная фича
Абсолютно нет. В современном мире рождаются с мутациями, предотвращающими ощущение боли. Большинство таких людей умирает в детстве - тупо убиваются, потому что не видят опасностей. Яйца сверхчувствительны потому, что их слишком легко изуродовать - т.е. организм требует их защищать ("незащищённость" важна для охлаждения тканей). Видишь, даже тут не "удача", а чёткие причины.
>>1004240
>да не работают эти простые советы
А ты пробовал? Если ты не чувствуешь фан от своей собственной игры, это не значит, что никто фана не чувствует от своих игр. Просто ты делаешь фигню и вцепился в неё, вместо того, чтобы отпустить или радикально переделать во что-то фановое.
Сложнее всего делать игры для ЦА, в которую ты не входишь. Т.е. ты не видишь в чём фан для твоей ЦА. Поэтому инди должны делать игры, в которые они предпочитают играть, а не просто что-то популярное.
Работают отлично, проверенно. Что нихуя не работает - нафантазировать себе диздок и пытаться его реализовать один в один. Во-первых ты можешь делать идею, которая играется как унылая хуита, во-вторых ты регулярно станешь упираться в хуевые или технически сложные решения и упорствовать в их реализации, потому что диздок требует. Создание игры - органический процесс.
Справедливости ради, проблема не в диздоке, а в
>реализовать один в один
>упорствовать в их реализации
Дизайн-документ называют "живым документом" - поскольку может и должен меняться по ходу дела. Совсем без какой-либо документации/записей по проекту тяжело, ибо всего в голове не удержишь.
Всё ещё жду объяснений >>1004074, что именно не получилось сделать в его "вселенной наоборот"... Концептуально его задумка вполне играбельная, и множество похожих проектов пришли к успеху, в особенности стоит отметить Deep Rock Galactic - там несколько другой фокус геймплея, но общая идея - "забуриться до полости -> исследовать -> повторить".
Как говорят, мало придумать интересную идею - обязательно нужно интересно реализовать.
>арт освоил на приемлемом уровне
Для прототипа арт обычно совсем не нужен...
Мог чисто на серых кубах сделать и отлаживать.
Пиши, если что не получается, может, поможем чем.
> Всё ещё жду объяснений >>1004074, что именно не получилось сделать в его "вселенной наоборот"...
>>1004364
> Пиши, если что не получается, может, поможем чем.
Мне нужен контроллер персонажа 3D привязанный к двум видам гравитации, точечной (в полостях) и осевой (в толщеходе). Без этого невозможно реализовать ключевые механики. Сам я не осилил. Чат боты не помогли.
В общем я понимаю что нужно сделать, но когда дело доходит до кода, руки превращаются в лапки. Ранее я адаптировал шаблон из ассетстора RigidBody Planetary Physics Correct Stand Up https://godotengine.org/asset-library/asset/159 но всё это осталось на трёшке. После четвёрочных свистелок в трёшку возвращаться не хочется. Целиком чужой код переписывать не стоит.
Точечная это видимо та что притягивает к точке, а осевая что это? Ну ок а что если просто суммировать два вектора?
Отталкивается от оси. Кабина толщехода вращается, и центробежной силой создаёт тяготение в невесомости Толщи (там невесомость).
> Ранее я адаптировал шаблон из ассетстора RigidBody Planetary Physics Correct Stand Up
Вот что получилось.
Здесь точечная гравитация. Всё отталкивается от центра к краям. Эффект охуенный, бежишь по бесконечному хомячьему колесу. В конце выпадаем в дырку, чисто по приколу. Саундрек - белорусы.
Ну окей первая мысль, вроде в Area3D есть точечная гравитация. Значит ты можешь изкоробки добавить две точечных гравитации, одну для полости, вторую для оси. Осевую двигать по линии в проекции игрока (грубо говоря x=y=0, z=player.z считая вдоль оси движения кабины
Так эти гравитации вряд ли вообще вмесе работать будут. Типа пока ты внутри кабины ты ходишь по ее зоне, когда выходишь ходишь по гравитации пустоты.
Ну да, планируется, что они будут работать по очереди. Но это не отменяет того факта, что нужен контроллер поддерживающий оба варианта.
Так а что надо то? Звучит так что все будет работать само - точечная гравитация притягивает ригидбоди. если же контроллер на кинематике то у тебя своя функция гравитации, пишешь чтобы она притягивала в сторону точки/оси, ну и разворачивала вдоль вектора. Точечную гравитацию пустоты при входе в кабину отключаешь, имитирующую осевую включаешь. Вроде ничего особенного от контроллера для "поддержки" этого не нужно.
Всё верно. Я точно так же и думал. На словах все легко и просто. Тем не менее, до сих пор не могу сделать.
Кстати, доброе утро всем!
>Кстати, доброе утро всем!
Проснулись потянулись, пошли делать игры.
>пошли делать игры.
Скорее срать в тред ии высерами и говнотекстами про c#. Никаких реальных результатов от жителей этого треда за пару лет так и не было
Действительно. Мы же тебе про результаты нашей работы не рассказываем, а значит их нет
Вот тут Godot 4, любая гравитация, CharacterBody3D:
https://github.com/Ivorforce/Godot4-Custom-Gravity
Жаль, я не разбираюсь в векторной математике...
Не понимаю, откуда люди эти формулы берут...
> Жаль, я не разбираюсь в векторной математике...
> Не понимаю, откуда люди эти формулы берут...
Такая же фигня.
Ну, щас посмотрим, спасиб.
Го пересматривать урок Годонье по трансформам, повторенье мать ученья https://www.youtube.com/watch?v=UwHIgAAGB0s
>Ничего полезного
А что тебе ещё нужно?
Есть вариант просто разделить полости и толщеходы на отдельные сцены:
1. Нажал E на шлюз толщехода -> затемнение -> ты внутри толщехода.
2. Нажал E на шлюз изнутри -> затемнение -> ты снаружи, в полости.
3. Нажал E на шлюз, не доехав до полости -> "здесь нельзя выйти".
Тогда у тебя может быть 2 отдельных контроллера персонажа.
>>1004558
>кучу нод
>Make local
А зачем?
>>1004566
У меня ни ютуб не работает, ни онлайн-скачиватели видосов...
Ну у новичков и вкатунов конечно нет, а некоторые тут 3-4 игры в год выпускают.
Опасная игрушка диавола ежжи. Я так полдня баг искал. А оказалось я правил отдельную сцену и забыл что ее копию сделал make local подсценой игровой.
>А что тебе ещё нужно?
Да он мутнит что то. Ему каждый раз несколько рабочих вариантов накидывают а ему все не то.
> все не то
Ну да, все советы относятся либо к плоской модели окружения, либо классическая гравитация с планетами. А нужна инверсная система. Моего скудного умишки не хватает. Я кое-как нашел где минус поставить в планетарном шаблоне для трёшки и на этом всё. В четверке аналогичных шаблонов нет, а имеющиеся не работают с минусом.
>правил отдельную сцену и забыл что ее копию сделал
У меня Godot регулярно ошибается с обновлением параметров сцен, которые используются в других сценах. Редактирую скрипт, изменяя параметры по умолчанию, запускаю игру - НОЛЬ изменений. Каждый раз забываю про этот баг редактора и пытаюсь править свой код. Потом вспоминаю, иду в совершенно другую вкладку, нажимаю кнопку "вернуть по умолчанию" и всё работает. Вот почему так? Почему редактор сохраняет старые параметры по умолчанию, если они даже не были изменены ни разу? Т.е. в tscn файле изначально нет никаких записей. А он берёт и сохраняет УСТАРЕВШИЕ значения... Единственный надёжный способ обойти эту проблему - закрывать все лишние сцены, чтобы при следующем запуске игры они считывались с диска, а не перезаписывались.
Не знаю, исправили ли в 4.4, но не хочется проверять (а то опять что-нибудь сломаю).
>>1004640
Он явно ленится изучать математику и программирование. Списывает свою лень на "скудный ум", а на деле наверняка нетерпеливо копипастит и не читает документацию. Все через это проходили... Всегда хочется по-быстрее увидеть свои гениальные идеи вживую с минимальными затратами...
>>1004648
>гравитация с планетами. А нужна инверсная система.
Просто ставишь минус перед вектором ускорения и должно сработать наоборот.
>для трёшки
>В четверке
Там не так много отличий между версиями. Основное API осталось без изменений, все изменения достаточно понятны даже для новичка. Просто читаешь документацию и понимаешь, как перенести старые скрипты на новую версию. Я все свои старые скрипты с 3 перенёс на 4 без проблем.
Может, тебя смущает переход с KinematicBody на CharacterBody3D? Там просто вынесли аргументы функции в свойства класса, чтобы лишний раз не дёргать. И ещё что-то перенесли на класс выше по дереву наследования, но это не так важно. С RigidBody3D вообще ничего не поменялось, физическое API давно стабильно и над физикой в движке долгое время никто не работал.
Я бы тебе сделал пример кода... Но я сам плохо разбираюсь в векторной математике и поэтому у меня не получается лаконично развернуть Node3D, получается какой-то хаос.
> Я бы тебе сделал пример кода... Но я сам плохо разбираюсь
Так что ждём дальше.
Для защиты проекта Godot можно использовать шифрование. Вот некоторые шаги:
Сгенерировать ключ. Обычно используется 256-битный ключ. 1
Собрать редактор Godot Engine и шаблон экспорта. Для этого нужно использовать команды scons platform=<platform> для редактора и scons platform=<platform> target=template_release и scons platform=<platform> target=template_debug для шаблона экспорта. 1
Установить пользовательский шаблон. Для этого нужно открыть «Проект» — «Экспорт» — «Добавить платформу» и указать в этом поле пользовательский шаблон. 1
Экспортировать проект. Перейти на вкладку «Шифрование» и убедиться, что включён переключатель «Encrypt the exported PCK». Заполнить фильтры для включения файлов и папок, если оставить их пустыми, ничего не будет зашифровано. Заполнить ключ шифрования тем же, что использовался во время компиляции. 1
Также можно изменить исходный код Godot Engine, чтобы защитить проект от декомпиляции. Для этого нужно открыть файл core/io/file_access_encrypted.cpp и изменить функцию open_and_parse, которая отвечает за шифрование и дешифрование файла .pck. 13
Следует учитывать, что защита кода в открытом исходном коде не является идеальным способом, и существуют инструменты, которые могут помочь в декомпиляции. 13
https://godot.community/topic/35/protecting-your-godot-project-from-decompilation
и попутно
Ты не умнее авторов денувы. Нейронка тем более.
А денуву ломают.
Если игра запускается, это значит что ключ поставляется вместо с игрой, то есть буквально зашифрованное и ключ расшифровки лежат в одном файле. Да это задержит ненадолго.
Некоторые пишут свою систему, чтобы, если стандартную взломают, то с их еще дольше возились.
Дальше уже писать на C++ и там пользоваться спец приемами. В том числе шифрующие оперативную память.
Еще один вариант - делать все что можно на сервере, а игроку показывать по сути гуй с кнопками. Например в шахматах ты хоть обдвигайся неправильно или наспавни сто ферзей - сервер будет отбрасывать то, что не соотвествует его состоянию. (Но отсюда же и сложность - игроки будут бугуртить, если сервер глючит например после рассинхрона и показывает им ложные контролы)
>>1004699
Краем глаза читал, что денуву никогда не ломали. Ломали те игры, которые забыли защитить - выложили дебаг билд или типа того.
>>1004648
Я тоже попробовал сделать, за 15 минут не вышло, за час еще не совсем, но уже близко.
Вот ещё прикольный вариант, тут и цилиндры, и сферы:
https://godotengine.org/asset-library/asset/546
>>1004694
>защиты проекта
Защиты от кого? Кому твой говнокод захочется трогать?
Лучшая защита от пиратства - опенсурс лицензия на гитхабе.
Ещё ни разу не видел опенсурс игры на пиратских трекерах.
>>1004700
>делать все что можно на сервере
Ненавижу такое. Когда ты умрёшь, твоя игра умрёт с тобой...
Если только все исходники сервера игры сразу в опенсурсе...
>денуву никогда не ломали
Просто никому не сдались все эти "АААА"-говноподделки.
>уже близко
Поделись хоть, чего добился?
Я вижу этапы этой проблемы так:
1. Направление притяжения - это пока не важно, пускай будет такое:
>var gravity := -global_position.direction_to(Vector3.ZERO)
2. Развернуть персонажа ногами в сторону притяжения.
Вообще без понятия, как это делать "правильно", я могу только так:
>look_at(gravity)
Но нужна какая-то жёсткая математика, ибо look_at постоянно делает что-то не то, что нужно.
3. Развернуть Input.get_vector() в плоскости движения персонажа...
ВООБЩЕ без понятия - гуглил примеры, ничего не понял.
Какие-то Vector3.cross(), а что, зачем, почему - не ясно.
4. Подвинуть персонажа. Бессмысленно это делать без решения пунктов 2-3.
Короче, если кто-то нашёл простое решение 2-3 без багов и глюков - полдела, считай, сделано.
Все эти туториалы по векторной математике ничего толком не объясняют...
Я понимаю, что Vector3.cross() даёт вектор, перпендикулярным двум другим - И ЧТО ТЕПЕРЬ?
Что с этими векторами делать-то? Каким магическим образом перпендикуляр тут поможет?
Очень расстраивает такое. Математики специально так сложно придумали?
Да попозже поделюсь, когда побольше проработаю, отходил от компа.
> Развернуть Input.get_vector() в плоскости движения персонажа...
Это почти во всех контроллерах есть. Используют basis.transform.z который является направлением вперед. Например у меня сейчас
velocity = (transform.basis.z input_dir.y + transform.basis.x input_dir.x).normalized() * speed
> look_at постоянно делает что-то не то
Look_at получает второй параметр, направление вверх, по умолчанию это буквально Vector.UP. Потому что просто посмотреть - имеет бесконечное число решений. Ты можешь посмотреть на дверь прямо, а можешь наклонив голову к плечу - поэтому и нужно уточнение.
Иными словами вместо look_at(dir, Vector3.UP) можно использовать look_at(dir, -gravity).
Или в других контроллерах выравнивают по полу. Тогда там что-то вроде look_at(dir, normal)
И еще есть нюанс что второй вектор не может быть 0, надо следить за этим.
Могу традиционно посоветовать эти туториалы (постоянно чтот то из них пригождается) https://kidscancode.org/godot_recipes/4.x/3d/3d_align_surface/
>Vector3 v_z = p_target.normalized();
>Vector3 v_x = p_up.cross(v_z);
>Vector3 v_y = v_z.cross(v_x);
>basis.set_columns(v_x, v_y, v_z);
Ну и как это понимать? Сделали 3 вектора, перпендикулярных друг другу и... и что это? Откуда разворот-то здесь?
Я понимаю, что собрали новый базис, но не понимаю, почему он "смотрит на цель", как к этому вообще пришли?
>>1004727
>Это почти во всех контроллерах есть. Используют basis.transform.z
А зачем? Абсолютное большинство контроллеров - это симулятор ходьбы по плоской планете...
У меня обычно примерно такой код:
>var dir := input.rotated(angle)
>var direction := Vector3(dir.x, 0, dir.y)
Получил ввод @ развернул на угол, зачем прибегать к Basis? Имхо, мой код проще понять...
Вопрос в том, как теперь direction переложить на произвольную плоскость в пространстве?
Пробовал умножать на локальный/глобальный базис - получается какая-то рандомная фигня.
>просто посмотреть - имеет бесконечное число решений
В чём проблема выбрать ближайшее решение к тому, что уже есть (Transform)?
>Ты можешь посмотреть на дверь прямо, а можешь наклонив голову к плечу
Если голова не наклонена - не наклоняй. Если уже наклонена - сохрани наклон. В чём проблема?
Ну т.е. вот у меня Node3D уже наклонена, а look_at() берёт и обнуляет мой наклон. Зачем? Почему?
Другая проблема с look_at() в том, что я без понятия, что совать в up, когда у меня target == up...
Я много чего перепробовал, но всё это выглядит как костыль. Должно быть элегантное решение...
>посоветовать эти туториалы
Да, читал сколько-то месяцев назад вроде, но не запомнилось ничего.
Моя главная проблема - я не знаю, как это всё решать, кроме как брутфорсом:
1. Набрал случайную комбинацию операций (на компьютере или в уме).
2. Вышло нечто хотя бы отдалённо напоминающее нужное решение?
3. Если нет - внести N случайных правок в порядок операций.
4. Повторять 2-3 до более-менее подходящего решения.
Подозреваю, что математики решают задачи иначе, но я без понятия, как. Какой у них алгоритм?
Наверное, мне проще будет написать генетический алгоритм для решения любых задач с векторами...
1. Вручную вводим примеры преобразований A -> B (обычно легко, даже нарисовать могу).
2. Запускаем генетический алгоритм, который оценивает успех преобразователей A в B.
3. Через сколько-то поколений будет формула, преобразующая A в B согласно примеру.
Тогда компьютер будет брутфорсить формулы вместо меня...
Извините за нытьё, сильно наболело за эти годы.
Двачую каждое слово.
У меня такая же ситуация.
Вчера вечером после пинков ИТТ я таки открыл годот и попытался хоть что-то набросать. Ничего толкового не получилось, но зато я узнал, что в четвёрке допилили класс бывшего KinematicBody, который теперь CharacterBody, и он теперь подвержен гравитации Area. И ещё есть теперь метод get_gravity() который собирает результирующую гравитацию в текущей точке, опрашивая все влияющие объекты.
>>1004727
> туториалы
Глянем
>>1004705
> прикольный вариант
Прикольный, но трёшка.
>>1004704
Попробуй 4 года сидеть и тупить над проектом.
>У меня ни ютуб не работает, ни онлайн-скачиватели видосов...
Прокси не пробовал?
https://cdn.youtubeunblocked.live/_ru/?__cpLangSet=1
Делюсь. Говнокод в наличии. Несколько часов на фигню и багфиксы потратил, правда.
Идея такая - использовать встроенные Area для гравитации.
Начнем с того что в самом проекте я убрал гравитацию и вектор гравитации в 0.
Скачал ассет кинематик контроллера (не стал делать на ригид)
Собственно есть 2 Area. Одна имитирует отталкивающий шар.
Второй с кастомной гравитацией цилиндра. Для отладки на видосе видно оранжевую ось.
Сначала тестировал чтобы она притягивала.
Эта ареа вызывает всем пересекающимся с ней физ телам функцию set_custom_gravity если она в наличии. Тут есть место для оптимизации. Соответственно обе Area влияют только когда тело внутри зоны
У контроллера есть два режима, скажем так 3д платформер автоориентированный вдоль кастомной гравитации. И свободный полет.
Долго возился с прыжком, пока не понял что код отпущенных клавиш вместо торможения перекашивал вектор прыжка, поэтому важен порядок компонентов.
Словил какой то странный баг move and slide который сильно дергал на несколько метров. Возможно это из за грубой поверхности кольца, это CSG с 64 гранями, возможно Годот считал что там что-то скользит по стенам, не знаю. На этот случай у меня костыль, если скорость резко скакнула, отменить такое пердвижение и округлить с предыдущим.
Камера была в контроллере, но я немного переделал, когда на земле это spring arm, когда в космосе просто вращение всей капсулы
Код align взят с kidscancode
В коде куча ошибок с вычислениями, я сейчас вижу что в одном месте умножаю на массу вместо массы в квадрате, а в другом умножаю все на 2000 просто потому что... так что там просто подогнаны приятные веса, это ненаучный подход конечно.
Помогите аэродинамично влиться в геймдев.
Вот этот прием используется
https://www.reddit.com/r/godot/comments/jwyqzd/procedural_mesh_generationdeform_with_collision/
Готового нет, если ты только вкатываешься хз получится ли у тебя.
А не, нашел готовый аддон. Забыл про него, а ему уже 2 года
https://godotengine.org/asset-library/asset/1794
https://github.com/cloudofoz/godot-deformablemesh/
Дерзай, ждем шедевр.
>CharacterBody, и он теперь подвержен гравитации Area. И ещё есть теперь метод get_gravity()
Ну кста не всегда это хорошо. У меня на тройке в первой игре гравитация игрока отличалась от всего окружающего физона, потому что иначе то ригиды были слишком резкие, то перс слишком плавный.
>>1004694
Но зачем? И, тем более, нахуя?
>CharacterBody, и он теперь подвержен гравитации Area. И ещё есть теперь метод get_gravity()
>Ну кста не всегда это хорошо. равитация игрока отличалась от всего окружающего физона
Слои вроде позволяют разделить.
стоит поковырять или нахненужон?
Зачем нужен редот когда есть блазия няшечка? >>1000900 →
Тут обсуждали >>999062 →
TL;DR - мертв. 3 его разработчика еще разосраться успели из-за денег, 2 съебали в Блазиум. Оставшийся видимо ноускилльное дно.
Вкратце: Лучше потрать время на разработку игры, а не на изучение форков, анон
С ликбезом: Редот - еще один форк, коих уже, наверно, с десяток наберется. Просто он появился, грамотно обернув в свою пользу негативный инфоповод, когда коммьюнити менеджер Годота облажался в Твиттере. Разработчикам это все не интересно, они игры делают, а не отстаивают что-то перед незнакомцами в соцсетях. Все адекватные люди эту историю полностью проигнорировали, а те, кому почему-то не все равно - в знак протеста перешли на Редот, который просто мерджит все коммиты Годота, а своего практически ничего не добавляет. Там один идейный человек, на котором все держится, а адекватные разработчики продолжают развивать Годот и делать на нем свои игры
Получается, ты за 8 часов сделал больше, чем я смог за несколько месяцев.
>гравитация игрока отличалась от всего окружающего физона, потому что иначе то ригиды были слишком резкие, то перс слишком плавный
Там разница не в гравитации, а linear_damp:
https://docs.godotengine.org/en/stable/classes/class_rigidbody3d.html#class-rigidbody3d-property-linear-damp
В проекте по умолчанию значение равно 0.1. Данное свойство упрощённо симулирует трение о воздух, т.е. у больших объектов значение должно быть больше. Однако, CharacterBody3D по умолчанию не имеет подобного свойства - ты сам должен его сделать.
Если у RigidBody3D будет linear_damp = 0.0, тогда их симуляция падения будет +/- равна CharacterBody3D. Возможно небольшое отклонение, т.к. функции у них сложнее и ошибки float, очевидно, накапливаются...
Также есть angular_damp, чтобы объект замедлял вращение. С 0.0 объекты вращаются бесконечно, стандартное значение 0.1. Потенциально это может влиять и на скорость свободного падения...
Нет, скорее всего у него все объекты по 1 килограмму. Самая распространённая ошибка жалующихся на физику.
>все объекты по 1 килограмму
Но вес никак не влияет на скорость падения... В вакууме объекты падают с одинаковой скоростью независимо от массы. Разница наблюдается только благодаря трению о воздух - которое симулируется исключительно через linear_damp/angular_damp.
Масса RigidBody3D влияет только на столкновения с другими RigidBody3D: более тяжёлый объект сильнее отклоняет более лёгкий объект и наоборот, но только в случае столкновения. К CharacterBody3D масса при столкновении отношения не имеет, поскольку либо столкновения не происходит (CharacterBody3D тупо останавливается перед RigidBody3D), либо RigidBody отлетает от CharacterBody3D как от StaticBody3D, т.е. объекта с бесконечной массой (неподвижного).
> Идея такая - использовать встроенные Area для гравитации.
Тоже отталкиваюсь от этой идеи.
> Второй с кастомной гравитацией цилиндра.
> ызывает всем пересекающимся с ней физ телам функцию set_custom_gravity если она в наличии
А можно код в раржпег? Или на пастебин?
Или доделывай всю остальную игру, а мы просто поиграем.
>что там с редотом?
Игнорируй политические форки, от них нет толку.
>>1004798
>есть блазия
Политический форк политического форка, лол.
>>1004809
>коммьюнити менеджер Годота облажался
В чём? Всё правильно сделали. Просто время было неудачное и весь твиттер в целом - яма со змеями.
- Облажался с твитом? Нет, всё правильно твитнул.
- Облажался с банами? Нет, всё правильно забанил.
- Облажались с разбаном? Нет, кого надо разбанили.
Вся эта ситуация никак на Godot не сказалась, ибо проблема в определённой категории людей, что изначально не заинтересованы в Godot. И люди эти в целом токсичные агрессоры. Т.е. никакой ошибки менеджера не было, ведь жопная боль каких-то посторонних людей - не ошибка, а их нормальное, привычное им состояние - повод всегда найдут.
Поэтому у этого форка не было будущего - ведь его создали из-за несуществующей проблемы. Лучше изучать практические форки, как у Zylann (воксели).
Если вдруг кто-то сделает что-то полезное где-то в политическом форке, и это будет нужно для Godot, разработчики Godot могут забрать это к себе - при условии, что форк сохраняет MIT лицензию. Но, как правило, в форках занимаются чепухой или чем-то чрезвычайно специфическим - Godot это не нужно.
Так что не парьтесь и качайте официальный Godot.
> с кастомной гравитацией цилиндра.
> вызывает всем пересекающимся с ней физ телам функцию set_custom_gravity если она в наличии
Так я его там на пиках и видосах показал. Ну держи проект если хочешь
https://anonymfile.com/gzb20/gwell.zip
контроллер там изначально на базе аддона https://godotengine.org/asset-library/asset/3591
Но как я сказал, там код кривой и математика кривая.
Я теперь и не уверен надо ли там гравитацию умножать на массу или массу в кв.
12-15 строчка точно правильные. Они и считают перпендикулярный (кратчайший) вектор от персонажа к оси. Это зеленая линяя которая тянется к оранжевой оси.
Потом я подумал что может быть гравитация наоборот должна работать по другому. Обычная то гравитация уменьшается с ростом расстояния. Я просто вычитаю нормальную гравитацию от сферы вместо того чтобы прибавлять как обычно. Но может быть нужна именно обратная гравитация, которая сильно прижимает к земле, но слабеет при взлете и приближению к центру полости. Иными словами, f = gravity(-dist) не то же самое что f = -gravity(dist).
У меня не скачивается. После 45 секунд появляется кнопка и вместо скачивания постоянно открывает рекламу.
>слабеет при взлете и приближению к центру
Лол, я бы на это забил - у него вся суть игры в этих полостях - что-то вроде обычного action adventure. Существенная разница в гравитации будет, если в геймплей добавить что-то летающее (самолёт), или диаметр полости примерно равен высоте прыжка.
В случае с цилиндром толщехода очевидно, что реалистичное зависание в центре обязательно будет мешаться геймплейно. Практически никто не делает реалистичную гравитацию в космосе, т.к. это будет вызывать раздражение у типичного игрока.
> у него вся суть игры в этих полостях
Вообще-то не совсем, но даже в полостях можно много механик сделать.
> реалистичное зависание в центре обязательно будет мешаться геймплейно
Вообще-то часть полостей являются освещёнными куском первичной материи, которая ведет себя как микрозвезда. Лететь к микрозвезде на самолёте это скажем так, икаровский [роскомнадзор]. Однако в достаточно крупных полостях в небе могут вращаться вокруг центральной микрозвезды на орбитальной механике несколько каменюк, и это уже планеты наоборот-наоборот. Ну не совсем планеты, так, астероиды.
Часть полостей без микрозвезды, так называемые тёмные полости, там будет не до полётов - это хоррор-локации, населённые чудовищами.
> Я сейчас пытаюсь разобраться и не понимаю, как, почему, для чего? Поясните?
Причём тут сцены?
У тебя есть нода MeshInstance3D, например, но как нода, она меша не содержит. Меш цепляется к ней как ресурс, в соответствующем поле в инспекторе. Об этом тебе и говорили. Осознай что есть меш? Это файл на диске. Это данные, которые следует с диска загрузить.
Ты можешь так же делать свои кастомные ресурсы, например, элементы инвентаря, они как ресурс прекрасно хранят "бизнес-логику" предметов. Чтобы создать предмет в сцене, например, выкинув его из инвентаря, ты уже создаёшь ноду-префаб, олицетворяющую предмет на сцене, и у этого префаба будет поле для предмета, в которое ты скопируешь дропнутый предмет. При подборе обратное действие: предмет-ресурс копируется из поля визуального предмета в список инвентаря, визуальный предмет уничтожается.
Ну и разумеется, поскольку это ресурсы, ты можешь организовать средствами движка файловую базу данных со всеми этими предметами.
> gwell.zip
Кто смог скачать, перекиньте на другой сервис, у меня с этого не качается!
>>вся суть игры в этих полостях - action adventure
>Вообще-то не совсем
Ты цитату обрезал и не так понял? Я имел в виду стандартный геймплей экшн эдвенчуры: почти исключительно 2D движение в 3D декорациях. В принципе, не обязательно даже свою гравитацию делать, если твои полости имеют диаметр >1 км. Делаешь скайбокс/шейдер на плоской карте.
>можно много механик сделать.
С этого и нужно начинать - какие механики от игры требуются, что нужен переход между двумя видами гравитации? Ты там джетпак хочешь сделать и чтоб залетать внутрь толщехода на джетпаке как пчела?
>Лететь к микрозвезде на самолёте
Если она горячая - там должен быть колоссальный диаметр полости. Если полость мелкая, то свечение наверняка из-за какой-нибудь люминесценции, т.е. "микрозвезда" на самом деле прохладная.
>вращаться вокруг центральной микрозвезды на орбитальной механике несколько каменюк
Во-первых, такие астероиды лучше не делать через RigidBody3D, т.к. гарантированно будут глюки; делай StaticBody3D. Во-вторых, для такой сцены наверняка понадобится колоссальный (по меркам видеоигр) диаметр, который будет конфликтовать с физикой. Примерно с диаметра 8 км начинаются проблемы с вещественными числами одинарной точности, т.е. потребуется как минимум компилировать с double. Однако даже с double физические движки плохо переваривают огромные объекты. Много проблем.
Короче, мне кажется, ты хочешь физически точную симуляцию, где она скорее всего окажется слишком дорогой и недостаточно стабильной для игры. Много физических песочниц изобретают свой собственный физический движок для их конкретных симуляций.
>как, почему, для чего? Поясните?
Английский знаешь? Читай документацию:
https://docs.godotengine.org/en/stable/tutorials/best_practices/node_alternatives.html
https://docs.godotengine.org/en/stable/tutorials/scripting/resources.html
И так далее, по ссылкам в документации ходи.
Вкратце, как я это понимаю:
1. Потомки Node: то, для чего ТРЕБУЕТСЯ:
- строгая иерархия нод в дереве сцены;
- графика, физика, UI, ввод с клавомыши;
- сохранение параметров на диск и загрузка;
- в большинстве случаев - уникальные данные.
2. Потомки Resource: то, для чего ТРЕБУЕТСЯ:
- сохранение параметров на диск и загрузка;
- в большинстве случаев - одинаковые данные.
3. Потомки RefCounted: то, для чего ТРЕБУЕТСЯ:
- считать ссылки (reference) на самих себя;
- самоуничтожаться, когда ссылок нет.
4. Потомки Object: всё остальное.
Помни, что дерево наследования такое:
Object -> Node -> ...
Object -> RefCounted -> Resource -> ...
Другими словами:
Resource - это счётчик ссылок + сериализация.
Node - это дерево сцены + сериализация.
Выбирай то, что тебе удобнее, но не более того.
> твои полости имеют диаметр >1 км
Меньше.
> не так понял?
Да, ХЗ, надо уточнить что именно я не понял в том что ты понял о том, каковой будет моя игра? Ты просто очень уверенно её описываешь, впору уже и мне поучиться у тебя геймдизайну.
> какие механики от игры требуются, что нужен переход между двумя видами гравитации?
Механики объяснены сюжетом, сюжет объяснён механиками. В полостях мы перемещаемся, собирая ресурсы, созерцая виды полостей изнутри. В тольщеходе, чтобы не висеть в невесомости (потому что между полостями невесомость), кабина вращается, создавая искусственное тяготение.
> Если она горячая - там должен быть колоссальный диаметр полости.
Не должен. Во вселенной наоборот и физика наоборот. Микрозвёзды реальны. Светят, греют. И не излучают радиацию!
> такие астероиды лучше не делать через RigidBody3D, т.к. гарантированно будут глюки; делай StaticBody3D.
Ага. И двигать статики по орбитам, да? Разумеется на удалении будут вовсе не физикбоди двигаться, а просто меши.
> с диаметра 8 км начинаются проблемы
Да, на таких диаметров придётся что-то думать с трюками и лодами.
Хз, у меня не было рекламы. Попробуй эту
https://wormhole.app/NJJy64#PprnHXoUDVYbIvlvZe5k_A
Забрал, спасибо.
Но изучать буду уже завтра.
Всем добра и любви!
>очень уверенно её описываешь
Да ты тут несколько лет её описывал, я запомнил. Концептуально мне она понравилась когда-то, вот и запомнил, но делать самому вообще не хотелось. Да, видение у нас отличается, но всё же.
Возможно, я что-то не так запомнил, или ты сам недостаточно точно описывал в прошлом. Но в те времена ты не упоминал полёты внутри полостей.
>поучиться у тебя геймдизайну
Ну, у меня прототипы есть, в которые мне приятно поиграть время от времени... И я не удаляю их от внезапного различия фантазии с реальностью.
>кабина вращается
Это лор, а не механика. Вопрос в том, зачем тебе бесшовный переход между кабиной и полостью? Я представляю шлюз в космическом корабле или в подводной лодке. Посмотри, например, GTA Online: подводная лодка по сути неподвижное здание, всё перемещение состоит из череды телепортаций, и физическое "тело" лодки не зависит от "интерьера". Подобные упрощения важны для стабильности.
>Во вселенной наоборот и физика наоборот
Тогда ты можешь запросто сделать и так, что якобы горячая звезда не сжигает тебя. Вопрос тут в другом: зачем жителям полости нужны полёты? Тем более в полости диаметром меньше 1 км (маловато будет).
>двигать статики по орбитам
Как, по-твоему, делают двигающиеся платформы в платформерах? Это статикбоди на фиксированных маршрутах. Реалистичная орбита стабильна, её не обязательно симулировать в реальном времени.
Алсо, если ты хочешь встать на такой астероид:
CharacterBody3D <-> AnimatableBody3D: терпимо.
CharacterBody3D <-> RigidBody3D: полный пипец.
С RigidBody3D <-> RigidBody3D тоже проблемы...
Т.е. для стабильности тебе нужны статикбоди.
Есть один трюк, как подружить всё это, но нужно сначала определиться, нужны ли игре RigidBody3D.
С чего бы? Просто пишешь дополнительный код который контролирует и сглаживает косяки.
>Просто
>код который контролирует и сглаживает косяки
Если б это был простой код, то он уже был бы в физическом движке - для всех, из коробки.
Разработчики движка сделали вот этот класс:
https://docs.godotengine.org/en/stable/classes/class_animatablebody3d.html
Специально для ситуаций типа "CharacterBody3D стоит на чём-то, что движется".
И нет, это не проблема Godot - в Unity с её Nvidia PhysX те же проблемы.
Упомянутый трюк, чтобы решить большинство возникающих проблем: когда игрок наступает на RigidBody3D, его физическое тело телепортируется в определённое место с секретной скрытой (невидимой) StaticBody3D версией подвижного тела, которая повторяет его форму, но остаётся неподвижной. Визуальная моделька (с камерой) игрока движется в локальной системе координат RigidBody3D, копируя движения физического тела в системе координат неподвижной копии. Если игрок покидает подвижное тело, всё возвращается в нормальный режим. Этот трюк позволяет более-менее стабильно избежать 99% проблем с физикой, позволив игроку двигаться по поверхности движущегося RigidyBody3D.
Естественно, это весьма специфичное решение, которое не выйдет масштабировать для всех ситуаций, поэтому из коробки в Godot его никогда не будет - каждый делает сам под свою игру. Плюс создание статичной копии увеличивает нагрузку на движок, в зависимости от сложности подвижной модели.
Алсо, движение по орбитам малого радиуса всё сильно усложняет в плане физического взаимодействия. AnimatableBody3D неплохо справляется только с линейным движением, на поворотах CharacterBody3D будет неизбежно соскальзывать с него. Лучше десять раз подумать, прежде чем ввязываться в это...
Речь в том числе про Jolt, если что. У него меньше косяков, но эта проблема фундаментальная.
>StaticBody3D версией подвижного тела, которая повторяет
>создание статичной копии увеличивает нагрузку
Забыл сказать, не обязательно делать их точными копиями. На самом деле, основная нагрузка на движок идёт от сложных RigidBody3D, тогда как StaticBody3D практически бесплатны, пока с ними никто не взаимодействует, и могут иметь существенно более сложные формы коллизий. Таким образом, можно сделать простенький RigidBody3D для обработки движения и столкновений с другими простыми объектами, а секретный StaticBody3D сделать сколь угодно сложным для взаимодействия с CharacterBody3D. Визуально игрок не заметит разницы, пока что-то не столкнётся с более грубым RigidBody3D (скорее всего будет выглядеть как столкновение с невидимой стеной, сквозь которую игрок свободно проходит).
Т.е. это не только вопрос стабильности движения, но и производительности игры.
> я не удаляю их от внезапного различия фантазии с реальностью
Щас бы воспринимать шутеечки уровня /б/ всерьёз.
> зачем тебе бесшовный переход между кабиной и полостью?
Во-первых, бесшовность это современность. Уже лет 5 как на игры с экранами загрузки смотрят свирепо и с недоумением. Кроме того, бесшовная игра не означает что все локации загружены одновременно. Запускается анимация открытия гермодвери - и в фоне грузится локация. Пока толщеход стоит на месте, то гравитация никуда не переключается, очевидно. Садишься в кресло пилота и запускается анимация запуска машины, соответственно здесь происходят все переключения, ловко спрятанные от игрока.
> подводная лодка по сути неподвижное здание
Именно так, кабина толщехода будет отдельной лобби-локацией, которая по сути будет прятать переключение между полость-локациями. Никакого реального движения огромной горнодобывающей машины здесь проектироваться не будет, просто потому что мы этого ничего согласно лору видеть не можем.
> якобы горячая звезда не сжигает тебя
Как же ты прицепился к этому. Придётся подробнее пояснять. Первичная материя (ПМ, тёмная материя наоборот, светлая материя) представляет собой хрупкий, твёрдый, белый светящийся кристалл, в котором сконцентрирована энергия, сконцентрирована большая часть массы, заполняющий собой всю Вселенную. Но гораздо более важно другое. По правилам лора бесконечная ПМ обладает бесконечной же гравитацией (или настолько большой, что не поддаётся измерению). Тем не менее никого не расплющивает, потому что бесконечность равномерно распределена со всех сторон. Полости в ПМ создают гравитационный градиент. Слишком мелкие пустоты влияния не оказывают, например, толщеход посреди тоннеля в толще слишком мал для Вселенной и внутри него невесомость. Потому нужно вращением кабины создавать искусственное тяготение. Однако в крупных пустотах начинается эффект, при котором от пустоты отталкивается вся вторичная материя (ВМ, вещества таблицы Менделеева-Наоборотского). При этом от центра полости отталкиваешься сильнее всего. К ней невозможно приблизиться. Догадываешься уже, что я напишу дальше? Белая дыра! ПМ ведёт себя иначе. Поскольку она обладает большей частью массы вселенной, она наоборот, оказавшись в пустой полости стремится занять одно из двух энергетически выгодных положений, либо прилипнуть к внешней кромке, либо упасть в центр полости. Между этими двумя крайностями ПМ пребывает в собственной невесомости. Мелкие кристаллы ПМ убийственны. Их нельзя трогать - моментум в море. Разряд в миллионы вольт поджаривает как котлету. Что уж говорить о фрагментах диаметром в сотни метров, висящие в центрах полостей. Возникающие внутри силы заставляют их излучать энергию, которая впитывается в толщу на кромке. Микрозвезда не может упасть из центра на кромку, но может излучать энергию, пока не испарится.
У этого механизма есть ещё один полезный эффект. Добытые в толще кристаллы несмотря на свою огромную массу и плотность, внутри полости выровнены по тяготению и пребывают в невесомости. Притягивать их начинает либо у кромки, либо у центра. Поэтому невозможно силами простых смертных оторвать от толщи крупный фрагмент. Просто масса огромна, ты его просто не поднимешь. Поэтому используются мелкие камешки, которые быстро испаряются и которые надо часто менять. Таким образом, если нагрузить летательный аппарат достаточным количеством рассыпухи из мелких кристаллов, они мало того что будут давать энергию для работы двигателей, так ещё и "антигравитацию". Но в центр он всё равно не долетит. Пока его конструкционные материалы отталкиваются от центра, его ядро из энергокристаллов всё сильнее притягивается. В какой-то момент аппарат просто разорвёт, ядро упадёт в центр, а обломки аппарата упадут к кромке. Кромка, я напоминаю, укрыта слоем грунта и пород из вторичной материи. Кромку мы не видим, и приблизиться к ней можем только закопавшись в глубину. Поэтому у поверхности полости энергокристаллы всё еще висят в собственной невесомости.
Существуют так же полости, в которых по всему обьёму рассортированы каменюги с ядром из ПМ, представляющие собой летающие острова, по которым скачет жопастая карлица на крюке-кошке, но это уже совсем другая история.
Смотри, я считаю физический солвер просто сложной формулой, в которую не лезу.
Что влияет на происходящее? Входные данные, сама формула, результат на выходе.
В программировании-математике есть и другие функций, которые не определены для всех аргументов.
Например, atan2 это обертка на arctan, которая учитывает разные изначальные ситуации.
Другой пример - snap to pixels, когда можно использовать полученные результаты с плавающей точкой, а потом округлять их до целых координат.
То есть ты можешь манипулировать входными данными (менять что-то в форме, менять координаты объектов) до рассчетов, и ты можешь корректировать результаты после того как их посчитал движок.
В этом примере >>1004751 упомянута ситуация когда происходит резкий рывок на несколько метров. Может быть ошибка в моем коде, может быть неудачная форма коллайдера к такому приводит, может ошибка внутри физики. Выяснять это займет дни. Поэтому я написал простейший костыль в несколько строк. Потому что я знаю какие я хочу наложить ограничения на результат - ограничить максимальную скорость. В принципе это всегда полезно в игре с физикой, наложить лимиты на линейную и вращательную скорость объектов. Именно потому что в компьютерной симуляции часто бывают ситуации когда какое-то значение приближается к нулю, а потом где-то на это число делят и получается скорость близкая к бесконечности.
Вот о чем я говорю. Это может быть простое решение для конкретно твоей игры, потому что ты знаешь какие в ней могут создаться ситуации. А общего решения, которое вставят в сам движок, может и не существовать вовсе.
Как разработчик, всегда будь командиром компьютера, а не рабом его встроенных функций. В данном случае физический поддвижок - просто инструмент который выполняет рассчеты которые нужны тебе в твоей игре, а не какой то бог который решает как все работает а ты лишь подстраиваешься.
> Никакого реального движения огромной горнодобывающей машины здесь проектироваться не будет, просто потому что мы этого ничего согласно лору видеть не можем.
По лору в подводной лодке тоже не видят что в ней снаружи, но это же самое интересное что могут предложить компьютерные игры, "вид снаружи" туда, куда в реальности не заглянуть. Поэтому же в играх любят и всякие статы, характеристики, шкалы здоровья. Мало интересно играть в стратегию которая бы точно симулировала только как ты сидишь за столом и получаешь текстовые донесения, интереснее видеть все, иногда и отключая туман войны, чтобы видеть что там происходит и получить представление.
>бесшовность это современность
@
>запускается анимация запуска машины
>будет отдельной лобби-локацией
>Никакого реального движения
Т.е. шов есть. Так что мешает поменять контроллер персонажа?
Думаю, два разных контроллера - оптимальнее, чем один универсальный...
>Придётся подробнее пояснять
>По правилам лора
Тебе не кажется, что ты слишком глубоко в свой лор забурился? Лор игры не должен мешать фану игрока. Если окажется, что ходить по поверхности "звезды" - это фаново, что будешь делать? Многие игры с лавой дают возможность получить неуязвимость к лаве, потому что бегать по лаве - фан. Можно ограничить эту возможность по времени или по сюжету, но не стоит ограничивать это лором, когда у тебя ещё игры толком нет, чтобы такое заранее запрещать. Игра - это не экранизация книги, а интерактивный опыт, и дизайнить его нужно исходя из опыта игрока (тебя, твоих друзей, усреднённого игрока из целевой аудитории), а не из какого-то лора. Самые успешные игры клали болт на свой собственный лор, позволяя игроку творить почти что угодно. Игрок хочет пробурить небеса? Пожалуйста - вот тебе бур, вот небеса, иди бури. А лор в свою очередь адаптируется под игрока: если игроки хотят бурить небеса и получают от этого безудержный ФАН, значит небосвод каменный и бурится, а всё остальное значения не имеет. Если ты запрещаешь игрокам делать что-то из-за того, что у тебя по лору что-то там не поддаётся бурению (потому что ты так сказал), то ты рискуешь сделать унылую игру. Почему, мистер Аноним, почему? Во имя чего?
>каменюги с ядром из ПМ
>летающие острова
Не, херня идея.
>>1005405
>физический поддвижок - просто инструмент
Который АЖТРИСЁТ, когда ты в него вводишь неизвестные заранее данные.
>ты знаешь какие в ней могут создаться ситуации
Это возможно только в игре, где шаг в сторону ступить нельзя без катсцены.
Не работает твой проект.
Я не он, но твоя проблема в версии движка. Скачай 4.4:
https://godotengine.org/article/dev-snapshot-godot-4-4-beta-3/#downloads
С версии 4.4 ресурсы юзают uid:// вместо res://, так что 4.3 их просто не видит.
В 4-ке есть ##, показывается при наведении мыши. При автокомплите показывается сигнатура, типы аргументов
А да, правда, я делал в самой последней бете, не в курсе был что проект предыдущими не откроется, хорошо что узнал, на будущее.
По идее открыть можно как то, отредактировав tscn в блокноте наверное убрав все uid чтобы они перегенерились
Вот здесь в подробностях:
https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/gdscript_documentation_comments.html
Вкратце:
- начинаешь с ## на каждой строчке;
- описание класса - через пустую строку:
>## Вкратце о классе
>##
>## Подробнее о классе
- описание функции - перед её заголовком;
- есть BB-коды как на дваче (RichTextLabel);
- можно добавить @deprecated и @experimental;
- можно открыть как встроенную справку (F1);
- можно видеть как всплывающую подсказку:
- - при наведении на строчку кода в редакторе;
- - при наведении на поле в инспекторе нод.
Но я недавно обнаружил досадный баг: если сбросил кэш проекта (в папке .godot), то твоя документация перестаёт распознаваться, пока ты не сохранишь скрипты проекта повторно. Также иногда она не обновляется почему-то, или с долгой задержкой.
Некоторые поля отображаются "нет документации", некоторые - не отображаются, пока не напишешь комментарий к ним. Как я понял, это типа скрытие приватных полей, но я не помню, что считается "приватным": по идее, то, что начинается с "_", однако некоторые поля с "_" в любом случае отображаются.
В общем, нюансы есть, но лично мне нравится.
>хорошо что узнал
Когда открываешь проект из ≤4.3 версии в 4.4, тебя встречает специальное окошко (пишу по памяти):
>Теперь ресурсы ссылаются через uid:// вместо res://. Ссылки обновятся после сохранения ресурса, но в большом проекте это будет долго делать вручную. Желаете автоматически пересохранить всё сразу? Пересохранение может занять несколько минут.
>[ пересохранить ] [ нет ] [ узнать больше ]
В общем, делай бэкап перед открытием в 4.4.
>отредактировав tscn в блокноте, убрав все uid
Этого недостаточно. Как я понял:
1. Раньше все ссылки на ресурсы были res://. Но перемещение файла (за пределами редактора, т.е. из файлового менеджера ОС) часто ломало эти ссылки.
2. Потом ввели uid://, чтобы автоматически фиксить потерянные файлы. Но res:// всё ещё оставались, т.е. сломанные uid:// восстанавливались через res://. Нестабильность и неполная поддержка мешала полностью принять эту новую систему.
3. Теперь (после реализации uid для всех скриптов) они считают систему uid:// стабильной и поэтому избавляются от res:// в ресурсных файлах (включая .tscn). Удаление uid:// приведёт к поломке файла, и восстанавливать res:// в версиях ≤4.3 неоткуда.
Т.е. тебе придётся вручную возвращать res://. Проще восстановить предыдущую версию из бэкапа/гита.
Да не, вроде пути в tscn к res:// на месте, по идее они писали что как fallback все равно работает. А в скриптах я ничего сам про uid не писал. А перетаскивать файл в скрипт я не пробовал.
>пути в tscn к res:// на месте
>как fallback все равно работает
И правда, ща проверил - res:// на месте.
Ну, тогда не знаю, в чём его >>1005575 проблема.
Но опять же по моим представлениям она и не должна распространяться с проектом, реимпорт должен делаться на месте другим. Может там надо реимпорт просто прокликать
>>1005761
Спасибо. Смотрю питоно-подобноые докстринги, типа:
"""
Описание
"""
Тоже ест. Но в автокомплите пока их не вижу. Штош, буду через решетки.
А это вроде не коммент, а просто многострочный литерал, который ничему не присвоен. Некоторые языки такое не запрещают, просто это ничего не делает.
>не запаковал папку .import
Её не нужно передавать, всё импортируется само.
>>1005842
>4.4->4.3 путь не особо часто будет встречаться
Естественно. Просто стабильного релиза не было.
>>1005845
>питоно-подобноые докстринги, типа:
>"""
>Описание
>"""
Нет, это обычные String, это не комментарий:
https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/gdscript_basics.html#literals
Не рекомендую использовать как комментарии.
>>1005857
>аргументы функций описать
Вот так можно:
>## Функция делает то-то и то-то.
>## [code]аргумент[/code] должен быть таким-то.
>func имя(аргумент: тип) -> тип:
Тег [code] включает inline подсветку кода, подробнее:
https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/gdscript_documentation_comments.html#bbcode-and-class-reference
Алсо, можно такие комментарии делать:
>func имя(
>аргумент1: тип, # комментарий
>аргумент2: тип, # комментарий
>аргумент3: тип # комментарий
>) -> тип:
Но в документацию эти комментарии не попадут.
>>1005886
Что ты имеешь в виду? Это троллинг?
>>1006029
А я наконец-то сегодня первый день без температуры. Сука 5 дней к ряду - я её сбиваю, а через пару часов опять вверх ползёт; до 38+-0.2 доходит и останавливается. Чуть голову от подушки приподнял - кружится. Делать ничего продуктивного вообще невозможно было, лежал полудемал и стримы по КСД2 слушал. Сегодня наконец-то это всё говно закончилось, я воспользовался нарисовавшимся свободным временем, открыл старый недоделанный проект и решил всё-таки доделать. Щас вот кушаю, решил в тредик заглянул.
Всем крепкого здоровья, годаны.
>до 38+-0.2 доходит и останавливается
Фигня же... Я с 39+ геймдевил, самый бодрячок прёт. От 40+ идеи крутые.
>открыл старый недоделанный проект и решил всё-таки доделать
Молодец, успехов.
>>1006072
Потому что его предназначение - добавлять в String стену текста без "/n".
Как-то начал делать простейший симулятор своей вайфу (мой персонаж, никто кроме меня не сделает). Почти без графики, просто кнопки и текст. Что-то похожее я накидал за пару часов в Twine и решил, что продолжать лучше в Godot. Я хорошо знаю как всё что нужно сделать в Godot и картинки тоже могу нарисовать сам, так что технически проблем нет... Только и мотивации нет. Даже поскорее собрав прототип, установив на телефон и ежедневно с ним взаимодействуя хотя бы минуту, как-то не могу себя заставить работать конкретно над этим проектом. А грандиозные, нереализуемые моими усилиями идеи никуда не делись...
В целом, мне нравится работать в Godot, писать код на GDScript. Но заставить себя работать над чем-то - всегда тяжело. Не помогает даже "просто открыть проект и смотреть на него", я вообще редактор больше не закрываю, висит на фоне... Кто-нибудь испытывал такое? Чем компенсировали? Совсем всё бросать не хочется.
>Как-то начал делать простейший симулятор своей вайфу
Покажи
Там нечего показывать - заглушка на заглушке.
И я не планирую её публиковать - это проект для себя.
> Недооцениваю масштабность своих идей. Но что делать? Простые игры вообще не привлекает делать, я пробовал - как-то не тянет продолжать.
> А грандиозные, нереализуемые моими усилиями идеи никуда не делись...
> Но заставить себя работать над чем-то - всегда тяжело.
Хорошее решение - разбить свою амбициозную идею на несколько проектов, каждый из которых реализует какую-то его часть, а каждый следующий - сделанное в предыдущем и новую часть большой задумки. Так и прогресс будет ощущаться, и работать будешь над тем, что интересно
Сгенерил картинку, по картинке 3д. В итоге 5.5мб модель, 130к вертексов. На аналогичную у меня вручную выходит до 2к вертексов.
Хоппа сделана нейросетью Trellis и в ней всего 22к вершин. Попробуй в блендере в режиме edit (tab) нажать a (select all) - f3 - merge by distance, это склеит продублировавшиечя вершины. Дальше уже decimate но он конечно дырки делать только в путь. Или dissolve vertex вручную.
Также у меня сложилось впечатление что на это больше влияет процесс extract glb, чем сама генерация. Там же какие то настройки тоже есть.
В Trellis есть параметр на сокращение количества вершин.
> кристалл, который собирает ГГ
> создать модельку из нейросетей
Ну разве что интереса ради если. Уж кристаллы-то можно и в блендере наштамповать. И 3,5 полигонов, вместо 130К!!!
> На аналогичную у меня вручную выходит до 2к вертексов.
Лолшто? 2К на кристалл? Это троллинг такой?
Можешь поверх еще сабдив накинуть, и смело приписать еше две "А" к своему графению.
Я в ахуе от того, как нас держали за лохов все 90е. Сука, блять, пока на западе играли в первую плойку, нас кормили китайским клоном NES из 80х. Сука, аж трисёт.
>130к вертексов
>2к вертексов
18 вершин.
>>1006507
>Лолшто? 2К на кристалл? Это троллинг такой?
Он пытается раскрыть потанцевал 5090 в 4K...
Будет 29 фпс в апскейле нейронкой 360p=>4K.
На самом деле от 2к вершин нихуя ему не будет, на вертексы уже всем похуй по большей части. Для ААА дерева в лесу 30-50к трисов это прям супер-супер средненько, не вах какой графений. Но с другой стороны дереву эти трисы реально нужны, потому что органика хитровыебанная, а вот кристаллу(который по определению является каким-то сечетанием примитивов)там уже хз нахуя.
>нас кормили китайским клоном NES из 80х. Сука, аж трисёт.
главное, что мы выросли и все осознали в какой ситуации были и чего нельхя допускать
Деревья тоже можно экономичнее, органику можно гнуть в вертекс шейдере и кору выпячиывать в фрагментном.
Нафик она нужна, поздние годы 2д пиксельарта >> кривое раннее недо3д
А на удалении деревья должны заменяться на САМОЗВАНЦА)) Вчера видос английский с яндекс-нейроозвучкой смотрел. Самозванца, хехе.
Сетку покажи. Впрочем, даже без сетки можно сказать, что
>22к вершин
Слишком много для такого рода модельки персонажа:
- детали одежды нарисованы на меше,
- волосы слиплись в один цельный кусок,
- глаза нарисованные, нет детализации лица.
Так что там очень много лишних полигонов.
Пикрилы: чего можно добиться с 1~3k треугольников.
Алсо, считать нужно треугольники, вершин обычно меньше.
>>1006684
>на вертексы уже всем похуй по большей части
GPU всё равно тормозить будет, если сцена избыточно сложная.
>Для ААА дерева в лесу 30-50к трисов это прям
ААА - это про объём бюджета. Деньги жечь - не игры делать. Смекаешь?
Т.е. если нанять говноделов - они тебе даже за $1 млрд из говна вылепят.
Или школоту нанять за $1 млн, а $999 млн себе в карман - тоже ААА будет.
За примерами далеко ходить не надо:
GTA 5, 2013 год, $265 млн - рулит до сих пор.
Cyberpunk 2077, 2020 год, $400 млн - говно.
Т.е. бабла сожгли больше, а качество - хуже.
Импостеры уже прошлый век, ща в анриле наниты типа. Пока сыровато, но шаг в нужную сторону. Убрать рутину с 3Д-шника(создание лодов, рендер импостеров и.т.д) и переложить на плечи машины. Теперь 3Д-шник делает мидпольку дерева в спидтри и все, впродакшн.
> ща в анриле наниты типа
А у нас в годоте реймарщинг.
Марширующие лучи, как я вчера тоже кстати смотрел) там же))
Ты его игру видел? Она там в колесе бегает. Упала, бедненькая...
>>1006767
>ща в анриле наниты типа. Пока сыровато
Говно эти наниты. Они позиционируются как волшебная палочка для говноделов, улучшающая производительность всех их говнодельских ассетфлипов, а по факту (бенчмарки) они только снижают производительность - при чём всем, не только говноделам. UE5 вообще убивает геймдев по мнению многих игроков, но это для другого треда тема, мы вообще-то в Godot-треде...
>создание лодов
Чем это отличается от автоматических лодов? Правильно - тем, что наниты сжигают больше циклов процессора, пытаясь "оптимизировать" меши в реальном времени по кусочкам, а меши громадные и всё это дело превращается в неиграбельный ассетфлип, который обязательно нужно рендерить в сниженном разрешении и потом растягивать картинку нейросетями, размазывая мыло по экрану. Зато бедные торидэшники, работающие, видимо, за считанные копейки, наконец-то могут вздохнуть спокойно и какать в редактор своими каками. А что там об этом игроки думают - никого в ААА не волнует, ведь их поделки сегодня покупают даже реже, чем инди-игры. Лол.
Пока индустрия пытается выжать больше бабла с меньшими затратами, они так и будут продолжать лепить неиграбельное говно, которое адекватные игроки скипают и продолжают играть в очередной пиксельный 2D платформер/рогалик/ферму от инди. Инди, который хочет сделать 3D, должен равняться на других инди, а не на говноделов, сжигающих сотни миллионов чужих бабок на совершенно никому не нужный продукт (часто выезжающий только за счёт франшизы/старых годных игр серии, которую они выкупили, чтобы обмазать говном).
>>1006772
>А у нас в годоте
Automatic LOD в Godot 4 - как наниты, только для здоровых людей:
https://docs.godotengine.org/en/stable/tutorials/3d/mesh_lod.html
Добиться то можно, только я то проверил что будет если просто несколько раз нажать кнопку сделать хорошо перегенерить, так чтобы результат устраивал. Что не устраивает так это UV развертка, ей пользоваться невозможно, но у меня там есть идея + я хочу освоить StableProjectorZ
Я оказывается неправильно запомнил, было 15к на выходе нейронки (22к это у врага-комара), после merge vertices 2,6к что вполне радует.
В смысле 22к тоже на выходе из нейронки, после редьюса там 3,9к. Там проблемы с крыльями, такая простая форма получила сложную сетку которую надо переделывать. Из забавного, он с лапками и подхватился миксамо.
Переделывать надо. Я конечно видел всякие гайды но сам еще никогда не моделил. Ну там где кольца глаз, рта должны быть под анимации.
В любом случае еше до НГ я считал что нейронки не могут в примлимое 3д, а тут практически геймреди.
>Что не устраивает так это UV развертка, ей пользоваться невозможно
С такой сеткой тоже работать сложно, если захочешь отредактировать.
>>1006929
>сам еще никогда не моделил
Тогда советы:
1. Сразу используй модификатор Mirror (лишнюю сторону удалишь).
2. Постарайся сохранять четырёхугольники и петли (loops) на меше.
3. В местах изгибов при анимации полигонов должно быть больше.
>тут практически геймреди
...для гиперказуалки с зафиксированой далеко от моделек камерой.
Да, я туториалы смотрел и советы эти слышал, спасибо, сам просто не делал руками еще
>>998261 →
>Потому что думающие, преисполнившиеся люди, свободные, не скованные ограничениями, кроме объективно существующих еще не реализованных функций, творцы, креативно ищущие способы эти ограничения покорить или обойти, архитекторы, стоящие выше взаимозаменяемости офисных винтиков.
>Опенсорс - это желание дарить в ответ. Дарить коммиты в коде, дарить знания об устройстве. Это как свободные каменщики или мужики в деревне собирающиеся помогать друг другу строить дом.
>Поэтому в комьюнити годота когда кто-то показывает, что он сделал - то чаще отвечает как, дает ссылку на репозиторий, показывает бесплатный видеотуториал. А не пишет, это я сделал покупайте за $8.99 а чтобы узнать как покупайте курсы.
>самый живой на всем гд
Да. Какие-то проблемы?
> Почему?
Потому что сначала ты работаешь на тред, а потом тред работает на тебя.
Сижу на бете 4.4, использую Jolt. Заметил, что физический движок не пытается вытолкнуть тело, если тело или хотя бы один из его коллиженшейпов находится полностью внутри другого тела:
1. RigidBody3D, состоящий из двух CollisionShape3D, и один из них забрался внутрь StaticBody3D. Теперь RigidBody3D трясётся на одном месте и никак не может вылезти из StaticBody3D.
2. RigidBody3D/CharacterBody3D целиком залез внутрь StaticBody3D. Теперь он может двигаться по внутренней/нижней стороне StaticBody3D, но выбраться наружу никак не может.
Я встречал что-то похожее в разных других играх, старых и новых, так что это вряд ли вина конкретного физического движка. В некоторых играх можно выскочить, активировав какого-нибудь питомца, дверь или что-то подобное, чтобы анимация персонажа передвинула его наружу. Или совершить суицид через меню паузы. Или телепортироваться в сторону за игровую валюту/в ущерб игровому счёту. Но всё это какие-то костыли.
Понимаю, нужно заранее проверять, куда спавнишь объекты. Но если объект двигался очень быстро и из-за скорости влетел внутрь другого тела? Или ещё что-то такое произошло, всего не предусмотреть. Какой способ решения этой ситуации был бы наиболее безболезненным для игрока? Всё-таки обидно терять ресурсы или убивать своего персонажа из-за глюка физики в игре, а бесплатный телепорт слишком легко абузить. Слишком сильно ограничивать возможности (скорость, ускорение) тоже как-то не очень хочется, хоть и понятно, что ограничения нужны.
Спавнить внутри коллайдера это точно не вариант. Это надо проверять через get_overlapping_bodies и искать в радиусе подходящее место.
Если говорить про движение, я слышал про такой способ ставить внутрь коллайдера еще 1 коллайдер поменьше. Сам не пробовал. Да и звучит расточительно.
Чтобы не влетать во что то быстро, то я писал выше - я лимитирую скорость персонажа после рассчетов физики.
Сейчас еще хочу попробовать вариант с пружиной. Не знаю как, но за персом будет летать привязанный цепью невидимый объект, и если перс влетел а предмет нет, то по идее резинка должна выдернуть перса обратно.
Может быть это можно сделать проще. Как в том же примере с цилиндрической гравитацией выше. Сделать всем статик боди зоны выталкивания с нужным направлением. Включаться они могут только когда игрок внутри них, так что жрать они много не будут. Нагенерить их можно тулскриптом автоматически.
>бесплатный телепорт слишком легко абузить
В ммо которую я играл, бесплатный телепорт заряжался полминуты (то есть под уроном такое не выйдет) и "откатывал" тебя в место где ты безопасно был, например раз в 5 минут делался слепок твоей позиции (тут может быть нюанс с движущимися платформами). И имел кулдаун минут 30, или 15, не помню уже. То есть при желании его можно было разок другой заабузить, например вылезти из пропасти в которую упал или срезать возвращение обратно после ответвления. Но не то чтобы что-то поломное. Но там если застрял конкретно то застрял и уже через смерть, так как на гейммастерах быстро стали экономить и они перестали приходить (а на старте игры могли придти и рестартануть зависшего рейдбосса или заглючивший сундук).
слепок твоей позиции (тут может быть нюанс с движущимися платформами)
И уже запертой дверью в какую либо комнату
>проверять через get_overlapping_bodies
Как проверка перед спавном - так и надо делать, но этот метод есть только у Area3D. Если что-то где-то уже застряло на глазах у игрока (например, на игрока свалился тяжёлый объект и выпихнул его сквозь пол или стену за пределы игровой зоны), игра об этом "не знает" и не может ничем помочь, если, конечно, не облепить всё вокруг Area3D. Было бы хорошо иметь датчик вхождения у PhysicsBody3D, а не только у Area3D, но этого почему-то нет (скорее всего, ради оптимизации?).
>ставить внутрь коллайдера еще 1 коллайдер поменьше
Ты имеешь в виду коллайдер StaticBody3D? У движущихся объектов основная проблема как раз когда они слишком маленькие для их скорости - проскакивают мимо/сквозь препятствия. В теории у физических объектов может быть свойство (safe_)margin, которое как бы создаёт "оболочку" чуть больше основного коллайдера, но это свойство не во всех движках поддерживается.
https://docs.godotengine.org/en/stable/classes/class_characterbody3d.html#class-characterbody3d-property-safe-margin
https://docs.godotengine.org/en/stable/classes/class_shape3d.html#class-shape3d-property-margin
>лимитирую скорость персонажа после рассчетов физики
Хочется быстрое, динамичное движение... Вообще, можно просто увеличить скорость симуляции (число тиков) физического движка, чтобы один шаг движения был короче. Но тогда нагрузка возрастёт, особенно если физических объектов много.
>вариант с пружиной
Если у тебя RigidBody3D, то лучше попробуй сначала переключить эту настройку:
https://docs.godotengine.org/en/stable/classes/class_rigidbody3d.html#class-rigidbody3d-property-continuous-cd
Для CharacterBody3D такой фичи вроде бы нет (нужно смотреть настройки проекта), но можно попробовать это:
https://docs.godotengine.org/en/stable/classes/class_physicsbody3d.html#class-physicsbody3d-method-test-move
Правда, не уверен, с каким шагом оно работает... Если не поможет, тогда есть ещё это:
https://docs.godotengine.org/en/stable/classes/class_shapecast3d.html
Это как рейкаст - гарантированно пересекается, но бросает форму вместо точки. Т.е. сначала кидаешь рейкаст/шейпкаст впереди персонажа, потом двигаешься. Таким способом делают быстро движущиеся физические снаряды (ракеты и т.п.), которым недостаточно "телепортироваться" - нужно проверить всё на своём пути.
>Включаться они могут только когда игрок внутри них
Для этого придётся повсюду Area3D натыкать. Собственно, проблема в том, что датчик проникновения в какую-то область есть только у Area3D, а PhysicsBody3D может только о столкновениях с поверхностью сообщать. Если ты сталкиваешься с его поверхностью изнутри, то это просто "столкновение"... Если только вручную нормаль столкновения оценивать:
https://docs.godotengine.org/en/stable/classes/class_kinematiccollision3d.html#class-kinematiccollision3d-method-get-normal
Нужно проверить, в какую сторону будет смотреть нормаль, если персонаж оказался внутри большого StaticBody3D и ходит по его внутренней поверхности (с обратной стороны потолка, если смотреть снаружи).
>Было бы хорошо иметь датчик вхождения у PhysicsBody3D, а не только у Area3D
Прикрепляешь Area3D детектор к PhysBody, можно в своем слое.
Вот двачую. Не могут анончики мыслить композиционно. Им дерево нод дали, композируй, нет, не хочу, хочу в наследовании функционал тащить.
Я все еще на буллете, у меня выталкивает. Более того, одна из фич моей игры. лул.
>С какими трудностями столкнулись?
Ебучая необходимость постоянно РАБотать, править здоровье и заниматься 100500 других дел. На разработку игры сил и времени не остается.
Как следствие настроение, которое скачет в диапазоне апатия-раздражения, и ощущение подбирающегося кризиса среднего возраста
/thread
>>1001721
>>1001426
болваны, тред не об этом
хотите жаловаться на жизнь - делаете это в /b или /psy
иначе будут репорты
Мне похуй, вахтер. Я тут редко пишу, так что когда в след раз зайду в тред, бана уже не будет
Я не могу делать игры, мне плохо, больно, нудно. Хочется, знаете ли, господа, чего-то эдакого, распахнуть крылья и взлететь. А не вот это вот всё.
Сижу пытаюсь вкурить в AI.
Спросил у нейронки, она предложила в общем-то всё то же, что и в интернетах пишут. Utility AI с весами, древовидная система, интеллект на основе задач. В принципе, у меня как раз и реализовано что-то типа первого варианта. Но пока что приходится каждому врагу индивидуально настраивать поведение, и я не очень понимаю, как от этого перейти к более гибкой системе, чтобы можно было просто расставлять врагов на уровне, не залезая каждому в мозги.
Так что вот, да, делаю.
Один ресурс на всех врагов, внутри вся логика (через if). Настройка для каждого через экспортные переменные. Где не прав?
Хорошим ии в играх сейчас и не пахнет. Какой сложности поведения ты хочешь добиться?
>Хорошим ии в играх сейчас и не пахнет
Вот начнут подключать ЛЛМ - порядок будет. Еще поплачешь с того, как тебя в скайриме медведь унижает.
Тут нужны будут жесткие ограничения, ибо даже рпг - это красивая рельса в обертке псевдовыбора. Сиречь - аттракцион. А так то дело хорошее. Только как-то тупо, что со времен первого FEAR людишки ничего лучше не осилили
Последний бета билд, дальше - кандидаты не релиз!
>Прикрепляешь Area3D
>>1007218
>мыслить композиционно
Про оптимизацию слышали?
А для этого надо делать чанки/стриминг. Ты же в любом случае будешь оптимизировать коллайдеры чтобы они подгружались только рядом с игроком, иначе они у тебя так же будут жрать ресурсы, и побольше чем Area
Всё правильно посоветовала:
>Utility AI с весами, древовидная система
Универсальное решение, как мозги людей.
>индивидуально настраивать поведение
Зачем? Что именно ты в них настраиваешь?
Utility AI - список доступных действий и связанных проверок. Поведение NPC не задаётся алгоритмом, вместо него оценка полезности (utility) конкретного действия (или стратегического решения, и т.д.).
Одна и та же система универсально решает любую доступную ей задачу для любого NPC. Настраивать индивидуально нужно только если ты хочешь, чтоб персонажи имели предпочтения: тогда ты меняешь множители функций полезности и они принимают различные решения в одинаковых ситуациях.
Например, у персонажа есть датчики:
- параметр голода;
- обнаружение еды.
Доступные действия персонажа:
- приготовить новую еду;
- разогреть готовую еду;
- съесть ближайшую еду.
Utility System персонажа:
1. Голод и рядом есть еда => съесть ближайшую еду.
2. Голод и рядом нет еды => приготовить новую еду.
3. Голод и рядом нет еды => разогреть готовую еду.
Действие 1 не сработает, пока не сработает 2 или 3 (исключение: кто-то оставил готовую горячую еду, поэтому действиям 2/3 срабатывать уже не нужно).
Эта система сработает в любом персонаже, но:
1. У Алисы множитель у действия 2 выше, чем у 3.
2. У Боба множитель у действия 3 выше, чем у 2.
Таким образом, мы видим игровую ситуацию:
1. Алиса и Боб зашли на кухню.
2. Алиса начинала готовить еду.
3. Боб разогревает уже готовую.
4. Потом каждый ест свою еду.
5. На кухню зашёл Вася и съел готовую еду Алисы.
Конкретно в Godot реализовывать Utility System, я думаю, лучше как отдельную Node. Потому что ей необходимо получать информацию из множества независимых источников => нужно соединять её множеством сигналов с другими нодами.
Действия можно абстрагировать от системы:
Brain: UtilitySystem
- Action1: UtilityAction
- Action2: UtilityAction
- Action3: UtilityAction
Когда тебе нужно выбрать действие, UtilitySystem проходится по UtilityAction, собирает и сортирует результаты вычислений, и выбирает лучшее из них (альтернативы: рандомное из лучших; рандомное в зависимости от полезности каждого действия).
Можно добавить иерархию, другие алгоритмы и т.д.
>>1007506
>Вот начнут подключать ЛЛМ
У LLM много проблем в текущем виде.
>как тебя в скайриме медведь унижает
Во-первых, LLM для этого плохо подходит.
Во-вторых, роль медведя - красиво проиграть.
>>1007516
>FEAR
Там GOAP, это другое. Utility System - из The Sims 1.
У GOAP много проблем по сравнению с Utility System.
Пропиши стандартные веса и меняй их только если создаёшь новый класс врага. Мелкие отклонения добавляешь процедурно, через функцию рандома.
Если у тебя стрелялка, у тебя в любом случае будет несколько десятков одинаковых болванчиков, и все отличия заключаются в используемом ими оружии, "элитности", случайных отклонениях.
Алсо, если параметров много, и неизвестна заранее лучшая комбинация, но известен исход боя - можно организовать reinforcement learning, который будет подгонять множители (веса) в зависимости от того, насколько успешно действуют твои NPC.
Если ты пытаешься организовать работу отряда из нескольких юнитов, то проще сделать один общий менеджер, раздающий им приказы.
Если не знал, у @export есть значения по умолчанию.
Также можно сохранять фрагменты сцен как сцены и редактировать параметры нод вложенной сцены, т.е. сохранять настройки куска сцены и потом менять, не нарушая зависимости от исходного файла на диске (правой кнопкой по ноде - Editable Children).
>Пропиши стандартные веса
Где ты найдешь стандартные веса? В каком то справочнике по игровому балансу?
>Что именно ты в них настраиваешь?
Один враг должен патрулировать местность от этой до этой; при виде игрока - пару секунд потупить, после чего нырять вон в то укрытие и оттуда открывать огонь; игрока потерял - идти в точку, где последний раз видел; если и там не нашёл - возвращаться на исходный патруль.
Другой должен сидеть на посту и не ходить; при виде игрока - стоять насмерть, стрелять прямо с места.
Третий при виде игрока должен бежать со всех ног, искать любое доступное укрытие, а отстреливаться только если зажали в угол. Но бежать вооон в ту комнату - запрещается.
И таких вот сценариев поведения - до жопы. Я реализовал каждый из них в отдельности, составляя по кирпичикам: у каждого болванчика есть 2-3 вида поведения с условиями, каждое поведение состоит из простых движений типа "двигаться направо до координаты Х", "присесть". Но как их объединить во что-то целостное, чтоб каждый раз кирпичики не складывать, вот тут чота теряюсь.
Ты тактическую головоломку делаешь что ли?
Коридорный шутер с кучей уникальных сцен?
Думаю, сначала нужно было игру описать...
>враг должен
Ничего он тебе не должен... Тьфу, то есть, ты, видать, ошибся с выбором алгоритма. Utility System крайне полезна, когда ты заранее не знаешь, чем все твои солдатики будут заниматься: просто выпускаешь их толпой или по одному и они сами разберутся, как им поступать, в зависимости от обстановки и своего собственного состояния здоровья/экипировки.
Если ты делаешь линейный аттракцион с полностью предсказуемым поведением, то ты можешь просто иерархические конечные автоматы заюзать и всё: задаёшь им набор состояний и условия перехода и запускаешь выполнение, тип музыкальная шкатулка. Интеллектом в автоматах и не пахнет, но множеству игрушек отсутствие интеллекта не мешает.
https://duckduckgo.com/?q=hierarchical+fsm+in+godot
Основной недостаток (H)FSM в том, что переход в следующие состояния жёстко задан дизайнером. Достоинство Utility System, соответственно - все переходы между состояниями разрешены в любом направлении и система сама решает, когда и куда переходить в зависимости от обстановки. Но, как я понимаю, тебе нужен предсказуемый порядок, так?
Примеры:
1. Патрулирование. Если замечен игрок - п.2.
2. Стрельба из укрытия. Если игрок потерян - п.3.
3. Поиск игрока. Если не нашёл игрока - п.1.
1. Ожидание. Если замечен игрок - п.2.
2. Стрельба. Если игрок пропал - п.1.
1. Ожидание. Если замечен игрок - п.2.
2. Побег в укрытие. Если игрок нашёл - п.3.
3. Стрельба. Если игрок пропал - п.2 (?).
Как видишь, на конечных автоматах описанное тобой поведение лаконично и будет просто описать кодом. Однако такой подход недостаточно гибкий, если тебе необходима нелинейность поведения многих юнитов в относительно непредсказуемой обстановке.
Есть аддоны для FSM, где даже визуальную лапшу натягивать можно как в визуальных шейдерах. Но большинство предлагает просто нодами в дереве.
>сценариев поведения - до жопы
Может, ты просто выбрал неудачный жанр/дизайн. Большинство игр имеют очень ограниченный набор возможностей для NPC - часто только небольшое количество "классов" NPC: пешеход (убегает), коп (патрулирует), сторож (стоит на месте) и т.д. Либо замахнулся на то, что в соло займёт много лет.
>чтоб каждый раз кирпичики не складывать
Так, а что тебе важнее - прописывать поведения по строгому линейному сценарию ("пойди туда и сделай такое и так-то"), или дать ИИ свободу искать какое-то подходящее под текущую ситуацию решение? Utility System ищет решение для текущей ситуации. GOAP - составляет долгосрочные, 100% выполнимые планы. Reinforcement Learning ищет оптимальное поведение, доставляющее максимальное удовольствие в среде. Строгий линейный сценарий - это область (H)FSM, но "складывать кирпичики" тебе почему-то не хочется.
Вообще, можно комбинировать подходы:
0. GOAP планирует глобальную стратегию, если она требуется в твоей игре. Типа руководит войсками. Но возможно также использовать Utility System.
1. FSM для поведения классов юнитов. Описываешь несколько возможных классов и переиспользуешь, например: патрульный, медик и т.д. Все состояния и переходы зависят от класса юнита, но фиксированы.
2. Некоторые из состояний FSM включают в себя специальную Utility System, чтобы поведение юнита получилось гибким и разнообразным, например, в столкновении с игроком. FSM переводит юнит в агрессивный режим, а Utility System определяет конкретный момент времени, чтоб прикрыться и выбросить гранату в сторону игрока.
3. Можно оптимизировать Utility System через RL, симулировав поведение игрока другим юнитом.
Если работы слишком много, то, возможно, у твоей задумки слишком большой масштаб для тебя...
Никакой магии нет, даже нейронку обучать (какой-то особенной задаче на приемлемом уровне) тяжело.
>сначала нужно было игру описать
2д-шутан с видом сбоку. Типа Noita, но без процедурной генерации и в сеттинге "под реализм".
>можешь просто иерархические конечные автоматы заюзать и всё
Ну вот щас у меня двухъярусный конечный автомат, где общий паттерн поведения (мирный, тревога, бой) выбирается на основе весов, а внутри паттерна действия выполняются последовательно или рандомно.
В принципе, этого уже достаточно, играется весело, поведение врагов достаточно разнообразное. Проблема в том, что я изначально написал эти мозги так, что их надо слишком сильно править для каждого конкретного солдатика. Модульно, где паттерны это ноды - дети AI-ноды, а у них свои дети - отдельные действия. Щас переписываю на одну единственную ноду, чтобы
а) солдатика можно было без каких-либо правок воткнуть в любое место уровня, и он бы там сам разобрался, что ему делать,
б) если захочу особое поведение - настроить его парой галок в инспекторе.
А да, кстати. Если промотаешь, с чего всё началось. Там анон спрашивал, что делаете, ну я и поделился своим. То есть, это не "помогите подскажите", а "щас вот работаю над такой задачей, ищу пути решения". Так что ты, возможно, зря так расстарался.
Посидел вечерок в блендере с этой проблемой
Придумал так - у нас есть говноUV от нейронки. И делаем в другом слое еще одну UV развертку которая нам уже нравится. Пользуемся smart UNWrap-ами, разрезаем грани расставляя Seam, склеиваем юзая Stitch
Потом геометри нодами мы расплющиваем нашу в модельку в плоскость с формой хорошей UV. А рендерим ее используя старый UV! (ортографической камерой с отключенным освещением)
И хоппа, мы провернули фарш и полуавтоматически перерисовали полигоны текстуры под новое расположение.
Даже получилось что-то вроде реалтаймого редактора не разобрался как в бленедере автоматизировать рендер->запечение текстуры из шейдера->переиспользование этой текстуры на вход заново
body_entered детектит физикс боди, такие как статик/кинематик/ригид. Содержание сцен Platform из твоего скрина непонятно - может они у тебя не физикс боди, а ареа2д - для их детекта нужен сигнал area_entered
Чушь какая-то. Зачем такая интеграция в Годот, когда его можно в обычном терминале использовать? Автор изобрел велосипед с квадратными колесами
А для игры это не сработает, потому что игроку самому нужно разворачивать у себя сервер и нейронку, что занимает очень много ресурсов (видеопамяти)
> Зачем такая интеграция в Годот
Чтобы нейронка сразу генерировала ресурсы в проект, а не твои ответы текстовые.
Ты, похоже, даже не глядел на код автора из видео. Все, что он сделал - подключение к локальному серверу, хостящему LLM, напрямую из Годота. Там нет никакого функционала для генерации ресурсов и каких-либо иных действий. Содержательная часть видоса отсутствует. Тот, кто хочет идею довести до конца, в данном видосе не нуждается, а такие как ты, не понимают даже, что в нем происходит
> Ты, похоже, даже не глядел на код автора из видео.
Блин, угадал. Я другой видос досматривал, а этот запостил на потом. Штош, извините за говноту.
Rotate тоже надо делать с дельтой, иначе с разным фпс будет разное вращение.
У физ тел есть поле velocity.
Ну бля. Заебала эта дельта ебаная. Почему нельзя в движке поставить галку, "веди себя одинаково с любым фпс"?
>>1007795
Нах дельта вобще нужна. Почему ее нельзя вшить по умолчанию? Нахуй кому-то разное поведение, которые будет зависеть от кол-ва фпс на экране. Что за бред епта
У physic_process относительно стабильная дельта, делай там, либо на твинах.
Вшить куда? Вшить как?
Вот простейший код с дельтой:
func _process(delta: float) -> void:
bomb.position.y += SPEED * delta
bomb.effect += 1
bomb.effect %= NUM_EFFECTS
bomb.time -= delta
if bomb.time <= 0: bomb.explode()
А теперь вопросы:
1. Изменится ли место взрыва бомбы, если у игрока винда начнёт фоном проперживаться, пытаясь выкачать обновления? А если без дельты?
2. Как движок должен догадаться, где тебе нужна дельта, а где не нужна?
>2. Как движок должен догадаться, где тебе нужна дельта, а где не нужна?
Везде нужна. Какие подводные камни? Серьезный вопрос.
И, с другой стороны, как я должен догадаться где движку нужна дельта, а где нет? Почему move_and_slide сам дельту вшивает, а rotate_y - нет?
>как я должен догадаться где движку нужна дельта, а где нет?
Никак. Движку дельта не нужна. Она нужна ТЕБЕ. Хер тебя знает, что ты там этим ротейтом ротейтишь и зачем. Одно дело физику посчитать, совсем другое - ты делаешь A += B и только сам знаешь, что это и зачем.
>Везде нужна.
А вот нихуя. Вообще совсем ни капельки нихуя.
var texture = load(path)
$Sprite.texture = texture
А этот не показывает:
var img = Image.new()
var err = img.load(path)
if err == OK:
var imgTexture = ImageTexture.new()
imgTexture.create_from_image(img)
var sprite_node = $Sprite
sprite_node.texture = imgTexture
$Sprite.texture = imgTexture
как заставить второй работать?
load не умеет загружать из внешних папок. Пытаюсь через create_from_image загружать изображения которые находятся не в папке ресурсов.
>А этот не показывает:
>var img = Image.new()
>var err = img.load(path)
нада
var err = img.load_from_file("user://цп.png")
Ну и
https://docs.godotengine.org/en/stable/tutorials/io/data_paths.html
Потому что например ты создаешь где-то вспомогательную ноду для рассчетов и пишешь ей rotate_y(90) потому что хочешь повернуть объект на прямой угол. А он тебе повернет на 1,503 градуса, классно
Итс овер, даже грустить уже сил нет
Круто, обязательно заюзаю аналог когда вывалят в опенсорс или бесплатный доступ и сделаю еще больше игр.
Вам бы только найти повод для грусти. Это просто модель, которая генерирует исключительно видео геймплея. Можно сказать, Lora-стиль видеоигрового геймплея для ИИ, что генерируют видео
Грустью игру не сделаешь, заряжайся позитивом и работай. Кто хочет сделать игру - тому нет преград
Опытный, уже всё знающий, может быстро нажать кнопку.
Новичок задерживает курсор на секунду, видит подсказку.
Подсказка не мешает нажимать, выделять другую кнопку.
Подсказка выводится анимацией чтобы быть заметной.
Подсказки есть как для кнопок, так и для категорий.
Кружочек в углу виден только если есть подсказка.
Как же всё-таки приятно работать с UI в Godot...
Очень приятно выглядит. Идея хорошая и интуитивная. Новый игрок, не зная, за что отвечает некоторый пункт меню, остановится на нем, чтобы попытаться осмыслить картинку. И по таймингу как раз появится текст. Выше предложили не сдвигать сам блок, но на мой взгляд, все правильно: так текст центрирован относительно центра экрана, читать приятнее, не нужно наклонять голову вбок
> даже грустить уже сил нет
Наконец-то нейросеть сделает мне игру про толщеход во вселенной наоборот. Даже самому делать ничего не придётся.
Ты же не наклоняешь голову вбок, чтобы читать текст который в инспекторе редактора справа.
Ты прав. Однако я хорошо знаю, что там и где располагается, плюс я хорошо знаю язык, с которым работаю и мне не нужно сильно вчитываться
Гипотетический пример: игрок не знает английского и решил поиграть, текст уезжает вбок, он пытается вчитываться и понимать
Пример на моем опыте: одни из последних RPG, в которые играл, это трилогия Shadowrun. Там весь текст уходит вправо, и мне, как человеку, хорошо знающему английский, при встрече профильных или редких для языка слов приходилось иногда вчитываться, чтобы осознать, о чем идет речь. Шея болела ужасно, это оставило очень плохие впечатления (кстати, в последние годы в играх жанра почему-то мода на сдвиг текст вправо появилась)
А чем тебя напрягает то, что иконка смещается влево, чтобы центрировать текст по центру?
Текст будет центрирован, а иконка не будет слишком "прыгать"
> Гипотетический пример: игрок не знает английского и решил поиграть
Так делай же локализацию сразу.
Если тебе приходится поворачивать голову, ты слишком близко сидишь перед экраном, к игре это имеет мало отношения.
Расскажи об этом своим игрокам, если таковые будут. Центрирование большого количества текста относительно чего-то, кроме центра экрана, плохо влияет на читаемость и раздражает пользователей. Именно поэтому в большинстве игр и софте основная рабочая область центрирована по центру и там же и располагается, а по бокам выбор инструментов или малозначительные вещи. Возьми ту же IDE и посмотри, что там где находится и относительно чего центрировано. Автору фидбек дал, а он сам уже решит, что с ним делать. Он достаточно умен, чтобы понимать такие очевидные вещи и сразу сделал центрирование по центру
98% этих игр - текст. Вторая буквально называется книгоходитель.
>Чего злобный такой?
"ПОШЁЛ НАХЕР МУДИЛО" - вот так был бы злобный. А там хз где ты злобность нашёл, вроде ж нормальный конструктивный пост без наездов.
Придумал ещё вот какой абстрактный в вакууме пример:
a += 1
b += 3
c = a + b
d += c * delta
Спрашивается: как объяснить умному движку, где тут дельта нужна, а где нет?
>>1007889
Круто, только лично я бы на раскрытие текстового окошка поменял бы транзишон тайп. Нынешняя (это TRANS_SPRING или TRANS_ELASTIC?) выглядит слишком дёргано на таком коротком тайминге. Как по мне, TRANS_BACK смотрелось бы чище, тем более в других анимациях как раз этот тип у тебя использован же.
>текст раскрывать справа
Я пробовал, вроде... Но есть нюансы (долго перечислять). Вообще, сейчас это не важно, позже можно будет поменять без проблем. Делал это меню как универсальный компонент (типа встроенных Control), чтобы можно было использовать в разных системах игры (и не только этой). Сегодня вот занялся рефакторингом, а то там логика реакции на клик была свёрнута в непонятный клубок - теперь стало лучше. Логику подсказки накидал за несколько минут чисто чтоб оценить концепт "подсказки с анимацией, которые не мешают использовать меню по назначению, но бросаются в глаза новичку с первого взгляда".
Но задумка была "привлечь внимание к всплывающей подсказке", так что сдвиг иконки вбок более чем оправдан, на мой взгляд, типа "подвинься, я тут тоже важна". На нажатие/выбор это никак не влияет, т.к. выбор зависит только от сектора круга непосредственно под курсором мыши. В реальной игре можно добавить настройку для отключения этой анимации и/или подсказок.
По моему опыту, UI игр часто страдает от "баннерной слепоты" - когда игрок не замечает элемент UI, рассматривая его как визуальный шум, декорацию. Часто замечал за собой такое - тыкаюсь в новую игру и не замечаю какой-нибудь текст, загнанный в угол экрана, где мне чётко говорят, что я должен делать. Толку от такой незаметной подсказки мало... Впрочем, также я слышал мнение, что игра должна быть интуитивно понятной без навязчивых подсказок. Наверное, всё сильно зависит от жанра игры.
>>1007893
>Очень приятно выглядит. Идея хорошая и интуитивная.
Правда? Спасибо. Думаю, "приятность" там за счёт анимации. Анимации любой UI делают намного приятнее. Жаль, что в большинстве игр UI слишком "жёсткий" - практически не реагирует на взаимодействие.
>не нужно наклонять голову вбок
Лол, это ирония? У меня там весь текст набок наклонён. Это типа стиль такой... перекошенный. Возможно, подсказку лучше всё-таки выровнять, но это тоже потом легко поменять, если что.
>>1007898
>Анимировал твинами?
Да. Можно и на AnimationPlayer сделать, но с твинами такое проще выходит.
>>1007899
>Шея болела ужасно
Может, у тебя сверхширокий монитор или ты слишком близко к нему сидишь? Или слишком долго. Причин может быть масса, обвинять игру за такое как-то немного странно. Хотя поддержка играми сверхшироких дисплеев важна:
>почему-то мода на сдвиг текст вправо появилась
Плохо, если так. Это раньше квадратные экраны были, сейчас один монитор может быть как два 16:9 (т.е. буквально 32:9). Игровой интерфейс должен учитывать такие сверхширокие мониторы, размещая информацию (шкалу здоровья, подсказки и т.д.) близко к центру экрана, и при этом учитывать, что у кого-то до сих пор может быть 16:10 или даже ещё меньше по ширине (если этого не учитывать, то интерфейс молча уезжает за границу экрана).
>>1007901
>иконка не будет слишком "прыгать"
Этот резкий "прыжок" ощущается так из-за TRANS_BOUNCE...
>>1007905
>Возьми ту же IDE
IDE отличаются от игр тем, что могут растянуть свой UI на весь экран без каких-либо последствий, и вообще не сильно париться о UI/UX, если программа важная и нужная. Для игр же расстояние между отдельными элементами UI важнее всего, и ощущения от использования критичны.
>понимать такие очевидные вещи и сразу сделал центрирование по центру
Лол, на самом деле это как бы поведение по-умолчанию... Хотя раньше я экспериментировал с открытием вложенных субменю вокруг сектора надменю (видео скидывал сюда в мае-июне), и в результате менюшки могли даже уезжать за границу экрана. Это было прикольно в теории, но, побаловавшись с ними, я решил, что пока что лучше сфокусировать их все в одном месте, даже если они перекрывают друг друга. Сдвиг кнопки-иконки в центр - это тоже такая "прикольная фишка" системы меню - субменю теперь зависят от этой фичи (на видео не видно, но "кнопка категории" может быть центральной кнопкой субменю, занимая место круглого "(X)" по центру - мне казалось это крутой фичей), а описание просто приклеено к этой иконке через контейнеры и убрать его куда-то будет не так-то легко. Короче, рефакторить надо, чтобы всё это разделить и сделать более свободным. На данный момент я даже не могу дизайнить эти меню в редакторе сцен (WYSIWYG) - оно полностью генерируется из кода по структуре данных, что значительно ограничивает их гибкость как универсального модуля. А у меня столько разных идей/планов было на это меню...
В общем, расположение по центру - по сути, случайное стечение обстоятельств (но мне понравилось, как это выглядит).
>>1007910
Согласен, в подобных играх альтернативы "весь текст лентой сбоку" просто нет. Куда ещё его загнать? Вниз экрана тоненькой полоской на всю ширину? Читать узкую ленту сбоку проще, чем широкую снизу. А над головами персонажей не стали отображать, наверное, чтобы не выглядело как мобильная гиперказуалка, плюс история реплик может быть важна для выбора опций. Главное, чтобы эта лента с текстом не уезжала на самый край какого-нибудь супер-игрового 32:9 с изгибом вокруг головы на 180 градусов.
>>1007921
>Нынешняя
Каждый раз забываю, что именно мне нужно, и в этот раз использовал TRANS_BOUNCE...
>TRANS_BACK
>как раз этот тип у тебя использован же
Глянул код - и правда. Как ты угадал? Я-то уже совсем забыл, что я там использовал. Наверное, нужно как-то где-то сделать себе "стандарт анимаций в проекте", чтобы не задумываться каждый раз, какую функцию использовать в новой анимации.
Всем спасибо за ответы, интересное обсуждение, много мыслей пришло.
Поправил анимации + добавил блюр...
Как вы боретесь с желанием писать "оптимальный" код?
Внезапно осознал, что в прошлом году пытался сделать эти меню "оптимально", экономя на спичках, и в результате код получился трудночитаемым, а встроить в него что-то новое невозможно без переписывания кучи кода по-новому. Зачем я это делал? Эти меню никогда не будут существовать в огромных количествах, можно было бы просто накидать отдельных нод.
Скорее всего, на меня повлияло то, что в некоторых играх меню очень сильно тормозят, но я даже не знаю, от чего они там (на других движках) тормозят - может, там кто-то XML с диска при каждом открытии меню читает, парсит, и заново создаёт все UI объекты - мало ли у кого какие костыли. В Godot нужно сильно постараться, чтобы типичный игровой UI начал тормозить.
> Как вы боретесь с желанием писать "оптимальный" код?
Не пишу никакого вовсе, но то я, не будьте такими как я.
Может мои познания устарели, но наклоненные шрифты это зло, поскольку дизайнер редактируя шрифты расставляет хинты чтобы он хорошо и четко смотрелся. Я сам правда не смотрел долго на проги где был бы наклоненный текст, и не знаю будут ли от этого сильно вытекать глаза.
> Используйте VisibilityEnabler
Будьте мужиками, блеать.
Я не хочу осваивать шизо-Блендер просто для того, чтобы модели делать.
Выбери LOD. Выбери LOD Range. Выбери LOD Ноду в 3-ке. Выбери Visibility Parent в 4-ке.
Что это за мусор?
Ты что предлагаешь модели рисовать через код?
Совсем что ли упоролся уже?
Лоды чисто визуальные. VisibilityEnabler еще по физике и процессам.
Я создаю через CSG меши и их булевые операции прямо в движке. Потом перегоняю в обычный мешинстанс плагином. Но у меня стиль подходящий, хз чего там у тебя.
Так load() и image.load() это разное, разве нет?
И я изображения открываю через диалог open file.
Какой вопрос такой и ответ.
Для серьезного создания моделей тебе понадобится блендер
Для простых штук - CSG и конвертировать их в OBJ. Но так что угодно ты не сдедаешь и остается вопрос с текстурированием - UV развертку то как то редактировать придется.
Да и много чего еще.
Ну а дальше захочется что-то делать с вершинами. Какой-то инструмент добавить типа скульптинга. Или array вдоль path. Ну вот там без surfacemeshtool никак. А там и поймешь что это совсем не страшно, что все модельки это просто несколько массивов чисел.
Так есть хоть одна адекватная альтернатива Блендеру на сегодня, без шизофрении или точно нет?
И нет смысла и пробовать другие тогда а сразу нужно окунаться с головой в шизу?
В моём текстовичке "тридэ редакторы" 42 программы для моделирования. Часть из них уже мертвы вместе с разработчиками, но более половины ещё работает.
Без понятия. Есть всякий платный софт типа zbrush, substance painter, maya, houdini.
А с чего ты решил что в блендере какая то шиза? Это шиза к примеру? >>1007742
Мне он легко дается после годота, потому что понятны концепции.
Сможешь ли ты сделать настолько крутую 3D графику, что "средняя поебота - Годот" не вывезет ее?
Многие аноны мыслят теоретическими понятиями и уже воображают себя настолько крутыми, что аж сам движок станет им препятствием
Просто сделай игру в соответствии с реалистичными ожиданиями. Плохому танцору ноги мешают
https://youtu.be/24Dho0ITq6w
https://youtu.be/n1Lon_Q2T18
Лучше сделаешь? Если да, тогда уже думай, что движок может стать тебе препятствием
Средняя поебота это ты. Скиллов ноль, денег ноль, желания учиться ноль а понты нарезаешь как охуевший. Хртьфу.
Вот видишь, что бывает когда мусор не прибран - анончики сагрились.
>Поправил анимации + добавил блюр
Стало заебись.
>Как ты угадал?
https://raw.githubusercontent.com/godotengine/godot-docs/master/img/tween_cheatsheet.webp
>Как вы боретесь с желанием писать "оптимальный" код?
Приучаю себя к хорошим паттернам. Пишу чистый читаемый код, сразу же оформленный и сразу же с комментами. Давно уже нету проблемы попыток в оптимизацию, потому что паттерны уже достаточно оптимизированы, а больше на скриптовом языке и не имеет особого смысла.
Так там из полноценных игр только недо Побег из Таркова.
Очерденой закос под Сталкер и даже не Метро.
Спасибо. Правильный код будет:
var image = Image.load_from_file(path)
var texture = ImageTexture.create_from_image(image)
$Sprite.texture = texture
>только
Так там только часть.
https://www.youtube.com/watch?v=zLY7aTRl0Ow
Анон с нулевым скилом размышляет о своем месте в игровой индустрии в качестве игродела. Видит себя в роли жертвы глобального невежества. Хочет конеурировать с играми первого эшалона.
Бляяя... Бамплимит уже. Посидите пока в этом. У меня куча дел.
>гта 7
3д говно не предлагать, минимум 4д. И за 20 минут плиз. Очень надо. Вам что, жолко что-ли?
И где бесплатные и открытые ресурсы брать?
Чтобы хуяк-хуяк и в продакшн.
Да, кому как не безыгорному анону с двача опускать все игры, выпущенные на движке за целый год... Ты, конечно, сделаешь что-то, что круче всех этих проектов вместе взятых.
>>1008211 (OP)
>>1008211 (OP)
>>1008211 (OP)