Добро пожаловать в юбилейный тред любви и взаимопомощи, старый, но не бесполезный!
Шапка: https://hipolink.me/godothread
Предыдущий: >>992896 (OP)
Архивный: >>985261 (OP)
Шапка: https://hipolink.me/godothread
Предыдущий: >>992896 (OP)
Архивный: >>985261 (OP)
>>0919
Я бы не ответил. Щас-то в контексте допёр, да там бы провалил бы. Да ещё и за 20 секунд. Не, сто процентов провалил бы.
Я бы не ответил. Щас-то в контексте допёр, да там бы провалил бы. Да ещё и за 20 секунд. Не, сто процентов провалил бы.
>>0918
И пихать тебе палец если ты опять задоджил работу над своей игрой.
И пихать тебе палец если ты опять задоджил работу над своей игрой.
57 Кб, 191x182>>0909 (OP)
Просочилось
Просочилось
30 Кб, 853x817Есть омнилайты - светят сферой. Есть спотлайты - светят конусом. Есть дирекшнл лайт - освещает всю сцену под указанным углом. Чем можно сделать свет, заполняющий грубо говоря куб?
Сейчас я это сделал натыкав Спотлайтов в линию (красное на пике), но это всрато, их конусы пересекаются, свет получается неравномерным и все такое. Подошел бы дирекшнл лайт, но у него я не вижу никакого контроля дистанции, он всегда освещает всю сцену.
Сейчас я это сделал натыкав Спотлайтов в линию (красное на пике), но это всрато, их конусы пересекаются, свет получается неравномерным и все такое. Подошел бы дирекшнл лайт, но у него я не вижу никакого контроля дистанции, он всегда освещает всю сцену.
>>0930
Как-то так? Пик релейтед.
Попробуй с кулмасками поиграться, как показано. Онимлампочки и кубы забиндены на второй слой. земля под ними осталась на первом. Как видишь, цветные лампочки не освещают землю.
Как-то так? Пик релейтед.
Попробуй с кулмасками поиграться, как показано. Онимлампочки и кубы забиндены на второй слой. земля под ними осталась на первом. Как видишь, цветные лампочки не освещают землю.
>>0933
Почитай тут
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
Почитай тут
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
>>0954
Ну и если нужен интерактив, то в бокс можно добавить Area которая будет детектировать входящие туловища и добавлять им вижуал инстанс 2, а при выходе убирать.
Ну и если нужен интерактив, то в бокс можно добавить Area которая будет детектировать входящие туловища и добавлять им вижуал инстанс 2, а при выходе убирать.
>>1000863 →
В уе и юнити есть бесплатные тун шейдеры. Где взять бесплатный тун шейдер на гадот?
В уе и юнити есть бесплатные тун шейдеры. Где взять бесплатный тун шейдер на гадот?
>>0997
Вообще из коробки встроенный.
Но навороченые cel shaders и обводки тебе уже накидали.
Но самый мощный я видел у китайца. Это порт Gulity Gear X. Не помню как находил, но точно скачивал когда-то.
Вообще из коробки встроенный.
Но навороченые cel shaders и обводки тебе уже накидали.
Но самый мощный я видел у китайца. Это порт Gulity Gear X. Не помню как находил, но точно скачивал когда-то.
>>1005
На видриле? Оно точно не выглядит как у арксистем. На видриле будто бы весь свет нарисован на текстурах вручную. У арксистем он отбит частично геометрией, частично динамичен.
>Это порт Gulity Gear X
На видриле? Оно точно не выглядит как у арксистем. На видриле будто бы весь свет нарисован на текстурах вручную. У арксистем он отбит частично геометрией, частично динамичен.
>>1022
В гилти гире пока что самая мощная манямэ стилизация из актуальных игр. За ними гнаться бессмысленно. Уровня мисайда будет достаточно для начала.
В гилти гире пока что самая мощная манямэ стилизация из актуальных игр. За ними гнаться бессмысленно. Уровня мисайда будет достаточно для начала.
>>1036
Да, соглы.
Да, соглы.
Вопрос к обработке клавиш (input map?), я вообще ничего не понимаю
- Есть клавиши перемещения WASD и клавиша открытия инвентаря TAB, все подключены к своим action в input_map
- Есть обработка нажатия, для перемещения стоит Input.is_action_pressed(), для инвентаря Input.is_action_just_pressed()
В чём суть, когда нажаты любые сочетания двух клавиш перемещения или одна клавиша (направления вверх, вниз, влево, вправо, влево-вверх, вправо-вверх, вниз-вправо), обработка нажатия инвентаря Input.is_action_just_pressed() работает, но когда выбирается направление ВЛЕВО-ВНИЗ (AS), обработка не срабатывает, как будто я ничего не нажимаю.
Пробовал менять клавишу в input_map на другие и на клавишах обычных букв всё работает, но конкретно на TAB - нет, что с этим можно сделать, кроме как поменять клавишу?
- Есть клавиши перемещения WASD и клавиша открытия инвентаря TAB, все подключены к своим action в input_map
- Есть обработка нажатия, для перемещения стоит Input.is_action_pressed(), для инвентаря Input.is_action_just_pressed()
В чём суть, когда нажаты любые сочетания двух клавиш перемещения или одна клавиша (направления вверх, вниз, влево, вправо, влево-вверх, вправо-вверх, вниз-вправо), обработка нажатия инвентаря Input.is_action_just_pressed() работает, но когда выбирается направление ВЛЕВО-ВНИЗ (AS), обработка не срабатывает, как будто я ничего не нажимаю.
Пробовал менять клавишу в input_map на другие и на клавишах обычных букв всё работает, но конкретно на TAB - нет, что с этим можно сделать, кроме как поменять клавишу?
>>1122
По документации - is_action_JUST_pressed возвращает true только когда юзер нажал кнопку. Нажал - как единичное событие, соответственно код под is_action_JUST_pressed сработает тоже один раз. Если тебе нужно обрабатывать зажатие как продолжающееся действие, "пока юзер держит W", то нужен is_action_pressed.
>is_action_just_pressed
>WASD
По документации - is_action_JUST_pressed возвращает true только когда юзер нажал кнопку. Нажал - как единичное событие, соответственно код под is_action_JUST_pressed сработает тоже один раз. Если тебе нужно обрабатывать зажатие как продолжающееся действие, "пока юзер держит W", то нужен is_action_pressed.
>>1122
Надо же, у меня такая же фигня! Вот сходи, проверь https://en.key-test.ru/
> (AS), обработка не срабатывает, как будто я ничего не нажимаю
Надо же, у меня такая же фигня! Вот сходи, проверь https://en.key-test.ru/
>>1156
А теперь, удерживая AS нажми Тав
А теперь, удерживая AS нажми Тав
>>1122
Лучше используй Input.get_vector(), сразу нормализованный Vector2 получишь.
Это нормально, это физическое ограничение клавиатуры (если у тебя не механика).
Ничего не делать. Игроку не нужно нажимать сразу 3 клавиши в большинстве игр. Тем более что открытие инвентаря - это однократная операция, которую делают в спокойной обстановке, т.е. персонаж будет неподвижен (тем более если инвентарь ставит игру на паузу). В любом случае, твоя игра должна позволять сменить раскладку клавиатуры, и если кому-то нужно нажать сразу 3 клавиши, а его клавиатура ограниченная, то он сможет сменить раскладку в настройках игры.
>>1173
Это "фича" в проводке и прошивке твоей клавиатуры.
Это придумали ради экономии в мембранных клавиатурах. Я вот могу нажать QWER UIOP - аж 8 клавиш одновременно, но вот нажать QAS, WAS, EDS, WSD и многие другие комбинации у меня не получится - две первые кнопки блокируют нажатие третьей. Потому что на мембранной клавиатуре проводки, идущие от клавиш к чипу, как-то по-особенному пересекаются, и чип не может прочитать все клавиши независимо друг от друга - нажатие одной клавиши блокирует чтение нажатий клавиш на той же линии. В механических клавиатурах, как я читал где-то, обычно нет такого ограничения, потому что там проводки клавиш распаяны независимо друг от друга, поэтому можно нажимать что угодно в любом порядке. Но большинству пользователей такая свобода всё равно не нужна, тем более в играх, и поэтому ты раньше об этом даже не догадывался.
А зачем тебе вообще зажимать 2 кнопки движения + открытие инвентаря?
>для перемещения стоит Input.is_action_pressed()
Лучше используй Input.get_vector(), сразу нормализованный Vector2 получишь.
>когда выбирается направление ВЛЕВО-ВНИЗ (AS), обработка не срабатывает
Это нормально, это физическое ограничение клавиатуры (если у тебя не механика).
>что с этим можно сделать, кроме как поменять клавишу?
Ничего не делать. Игроку не нужно нажимать сразу 3 клавиши в большинстве игр. Тем более что открытие инвентаря - это однократная операция, которую делают в спокойной обстановке, т.е. персонаж будет неподвижен (тем более если инвентарь ставит игру на паузу). В любом случае, твоя игра должна позволять сменить раскладку клавиатуры, и если кому-то нужно нажать сразу 3 клавиши, а его клавиатура ограниченная, то он сможет сменить раскладку в настройках игры.
>>1173
>Это получается фича конкретно системной обработки клавиш?
Это "фича" в проводке и прошивке твоей клавиатуры.
>кто и зачем это придумал
Это придумали ради экономии в мембранных клавиатурах. Я вот могу нажать QWER UIOP - аж 8 клавиш одновременно, но вот нажать QAS, WAS, EDS, WSD и многие другие комбинации у меня не получится - две первые кнопки блокируют нажатие третьей. Потому что на мембранной клавиатуре проводки, идущие от клавиш к чипу, как-то по-особенному пересекаются, и чип не может прочитать все клавиши независимо друг от друга - нажатие одной клавиши блокирует чтение нажатий клавиш на той же линии. В механических клавиатурах, как я читал где-то, обычно нет такого ограничения, потому что там проводки клавиш распаяны независимо друг от друга, поэтому можно нажимать что угодно в любом порядке. Но большинству пользователей такая свобода всё равно не нужна, тем более в играх, и поэтому ты раньше об этом даже не догадывался.
>видимо, не смогу так сделать
А зачем тебе вообще зажимать 2 кнопки движения + открытие инвентаря?
>>1191
О спасибо, буду использовать
Спасибо большое, я бы до такого не додумался сам
Думал сделать, чтобы инвентарь игру на паузу не ставил, и им можно было на ходу пользоваться
> Лучше используй Input.get_vector(), сразу нормализованный Vector2 получишь.
О спасибо, буду использовать
> Это "фича" в проводке и прошивке твоей клавиатуры.
Спасибо большое, я бы до такого не додумался сам
> А зачем тебе вообще зажимать 2 кнопки движения + открытие инвентаря?
Думал сделать, чтобы инвентарь игру на паузу не ставил, и им можно было на ходу пользоваться
>>1191
Пиздец, экономия на спичках.
>на мембранной клавиатуре проводки, идущие от клавиш к чипу, как-то по-особенному пересекаются, и чип не может прочитать все клавиши независимо друг от друг
Пиздец, экономия на спичках.
>>1199
Terraria так делает... Но позволяет в настройках выбрать, ставить на паузу или нет. И позволяет забиндить любое действие на любую клавишу (на смартфонах там вообще собственный виртуальный контроллер собрать можно). Правда, там редко бывает чтобы A и S были зажаты одновременно. У тебя игра с видом сверху?
Имхо, лучше просто позволить игроку самому настраивать раскладку (биндинг клавиш). И добавлять/использовать действия рационально (чтобы у тебя не было несколько разных действий с одним смыслом "использовать", когда достаточно было бы всего одного на все ситуации - слышал такую критику о какой-то игре). Тогда никаких проблем не будет.
>на ходу пользоваться
Terraria так делает... Но позволяет в настройках выбрать, ставить на паузу или нет. И позволяет забиндить любое действие на любую клавишу (на смартфонах там вообще собственный виртуальный контроллер собрать можно). Правда, там редко бывает чтобы A и S были зажаты одновременно. У тебя игра с видом сверху?
Имхо, лучше просто позволить игроку самому настраивать раскладку (биндинг клавиш). И добавлять/использовать действия рационально (чтобы у тебя не было несколько разных действий с одним смыслом "использовать", когда достаточно было бы всего одного на все ситуации - слышал такую критику о какой-то игре). Тогда никаких проблем не будет.
>>1207
Думал без паузы это в принципе сделать, допустим, на бегу открывать инвентарь и лечить кровотечение бинтом из инвентаря, но в целом это не так критично конечно
ага
Ну это база, да, но мне срочно хаха
> ставить на паузу или нет
Думал без паузы это в принципе сделать, допустим, на бегу открывать инвентарь и лечить кровотечение бинтом из инвентаря, но в целом это не так критично конечно
> У тебя игра с видом сверху
ага
> лучше просто позволить игроку самому настраивать раскладку
Ну это база, да, но мне срочно хаха
>>1205
Я неправильно выразился, вряд ли это из-за "экономии", скорее ограничения технологии. В мембранных клавиатурах у тебя две тонких пластиковых плёнки с распечатанными на них проводками. Когда нажимаешь на клавишу, ты продавливаешь верхнюю плёнку, создавая контакт с нижней. Из-за этого, возможно, приходится ограничивать число проводков и их расположение, чтобы они не замыкались когда не нужно. Но клавиатура выходит намного дешевле за счёт использования этих мембран.
В механической клавиатуре жёсткая печатная плата, на которой может быть распаяно что угодно в несколько слоёв как на любой обычной плате. Или вообще проводками можешь соединить и свой контроллер запрограммировать. Но и выходит всё это удовольствие намного дороже - т.к. датчики все индивидуальные, в отличие от одной общей мембраны.
Картинки из интернета.
>экономия на спичках
Я неправильно выразился, вряд ли это из-за "экономии", скорее ограничения технологии. В мембранных клавиатурах у тебя две тонких пластиковых плёнки с распечатанными на них проводками. Когда нажимаешь на клавишу, ты продавливаешь верхнюю плёнку, создавая контакт с нижней. Из-за этого, возможно, приходится ограничивать число проводков и их расположение, чтобы они не замыкались когда не нужно. Но клавиатура выходит намного дешевле за счёт использования этих мембран.
В механической клавиатуре жёсткая печатная плата, на которой может быть распаяно что угодно в несколько слоёв как на любой обычной плате. Или вообще проводками можешь соединить и свой контроллер запрограммировать. Но и выходит всё это удовольствие намного дороже - т.к. датчики все индивидуальные, в отличие от одной общей мембраны.
Картинки из интернета.
>>0909 (OP)
Не понимаю, как отлавливать _on_input_event() двух Area2D, если они пересекают друг друга?
Не понимаю, как отлавливать _on_input_event() двух Area2D, если они пересекают друг друга?
>>1219
А, нашёл проблему и решение:
https://github.com/godotengine/godot/pull/75688
Дело в том, что пересекающиеся Area2D получают сигнал ввода в произвольном порядке. Поэтому, в отличие от Control, положение Area2D в дереве сцены не влияет (по умолчанию) на то, какая из них будет обработана первой. Простой вызов set_input_as_handled() не меняет ситуацию, т.к. неизвестно, какая нода получит сигнал первой. Сортировка позволяет этого избежать.
А, нашёл проблему и решение:
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() не меняет ситуацию, т.к. неизвестно, какая нода получит сигнал первой. Сортировка позволяет этого избежать.
10,1 Мб, mp4,1920x1080, 0:09
>>1264
На 750ti тянет. На встройке интела запускал, но не помню как там было
>>1022
Там моделька рипнутая из GBF versus что ли, и источники света там есть которые привязаны к персонажу и светят на него, а есть внешний, вроде только один может быть активен. И там динамическое.
Вот его бложик, но что то сейчас не открывается без китайской реги. Хотя файлы можно скачать (там пароль написан). Емнип в посте были исходники шейдера. Где то в хламе на жестком диске наверное они у меня валяются...
https://zhuanlan.zhihu.com/p/390781757
На 750ti тянет. На встройке интела запускал, но не помню как там было
>>1022
Там моделька рипнутая из GBF versus что ли, и источники света там есть которые привязаны к персонажу и светят на него, а есть внешний, вроде только один может быть активен. И там динамическое.
Вот его бложик, но что то сейчас не открывается без китайской реги. Хотя файлы можно скачать (там пароль написан). Емнип в посте были исходники шейдера. Где то в хламе на жестком диске наверное они у меня валяются...
https://zhuanlan.zhihu.com/p/390781757
>>1350
Может он имел в виду что чистил клетку.
Может он имел в виду что чистил клетку.
Давайте обсудим кто что делает на Годоте. Какого жанра игру разрабатываете? С какими трудностями столкнулись?
Делаю 2D top down RPG, до этого основательно ковырял UE и Unity, но Годот понравился больше всех. Первый - слишком тяжелый для моих задач, второй - показался архаичным, очень неприятно с ним взаимодействовать во всех смыслах и за него еще деньги просят...
В моем случае после перехода на Годот очень ускорилась разработка проекта, появилась радость от взаимодействия с движком
Делаю 2D top down RPG, до этого основательно ковырял UE и Unity, но Годот понравился больше всех. Первый - слишком тяжелый для моих задач, второй - показался архаичным, очень неприятно с ним взаимодействовать во всех смыслах и за него еще деньги просят...
В моем случае после перехода на Годот очень ускорилась разработка проекта, появилась радость от взаимодействия с движком
Пока только с двумя проблемами столкнулся: потеря данных в ячейках TileMapLayer и неправильный рендер света. Это уже починили и замерджили в 4.4
>>1401
3D стелс-экшон-адвенчуро, резиденталик
Главная трудность - моя лень.
> Какого жанра игру разрабатываете?
3D стелс-экшон-адвенчуро, резиденталик
> С какими трудностями столкнулись?
Главная трудность - моя лень.
>>1401
Делаю 3д топ даун паззл-приключение с механикой времени и прочей мишурой. БОльшая часть кода написана, механики сделаны, простенький (а мне больше и не надо) ИИ сделан, боевка сделана, сюжет написан, даже сейвы давно сделаны ненавижу блять сейвы.
Целюсь и на десктоп и на мобилки, регулярно проверяю работоспособность на андроиде. Мобилки накладывают довольно жесткие требования к производительности, особенно по 3д, - периодически приходится отказываться от желаемого графона и хитрить со "smoke and mirrors", что иногда работает в мою пользу и придает игре узнаваемый вид и некий шарм.
Туплю по дизайну левелов, паззлов и диалогов. Создание красивого И функционального кусочка уровня, проходящегося за 5 минут, занимает у меня месяц блять. И это, помимо требований к производительности, моя основная трудность. Раньше еще с созданием ассетов страдал, сейчас придрочился.
Игра уже выглядит как игра. Сделанные области в состоянии, пригодным к релизу. Но работать еще дохуя. Надеюсь в этом году хотя бы демку выкатить.
Братюня. Почти все мои релизнутые игры - top down.
Делаю 3д топ даун паззл-приключение с механикой времени и прочей мишурой. БОльшая часть кода написана, механики сделаны, простенький (а мне больше и не надо) ИИ сделан, боевка сделана, сюжет написан, даже сейвы давно сделаны ненавижу блять сейвы.
Целюсь и на десктоп и на мобилки, регулярно проверяю работоспособность на андроиде. Мобилки накладывают довольно жесткие требования к производительности, особенно по 3д, - периодически приходится отказываться от желаемого графона и хитрить со "smoke and mirrors", что иногда работает в мою пользу и придает игре узнаваемый вид и некий шарм.
Туплю по дизайну левелов, паззлов и диалогов. Создание красивого И функционального кусочка уровня, проходящегося за 5 минут, занимает у меня месяц блять. И это, помимо требований к производительности, моя основная трудность. Раньше еще с созданием ассетов страдал, сейчас придрочился.
Игра уже выглядит как игра. Сделанные области в состоянии, пригодным к релизу. Но работать еще дохуя. Надеюсь в этом году хотя бы демку выкатить.
>Делаю 2D top down
Братюня. Почти все мои релизнутые игры - top down.
11,1 Мб, mp4,1152x648, 1:29
>>1401
оно видимо само както приходит когда движок открываешь
я пока ковыряю свою хуйню
основные сложности - это необходимость переключаться между различными несвязанными задачами в процессе разработки в соло (типа покодил, пособирал анимации, повозился со звуком, порисовал спрайтов, пописал сюжет) - все это сильно выматывает, особенно когда садишься с одной целью типа добавить какуюнить механику, но тебе нужно вместо того чтобы кодить переключаться и пиздовать разбираться со звуком или рисовать, а это ты делать не хотел.
Еще хотелось бы заняться какимто другим проектом, в другом жанре но тут ебашить лютейшая ЛЕНЬ и я конечно хочу попробовать сделать булетхел, внку или сурвайвор, но мне так сука лень думать и гуглить как реализовывать какието базовые кор вещи для таких проектов
>2D top down RPG
оно видимо само както приходит когда движок открываешь
я пока ковыряю свою хуйню
основные сложности - это необходимость переключаться между различными несвязанными задачами в процессе разработки в соло (типа покодил, пособирал анимации, повозился со звуком, порисовал спрайтов, пописал сюжет) - все это сильно выматывает, особенно когда садишься с одной целью типа добавить какуюнить механику, но тебе нужно вместо того чтобы кодить переключаться и пиздовать разбираться со звуком или рисовать, а это ты делать не хотел.
Еще хотелось бы заняться какимто другим проектом, в другом жанре но тут ебашить лютейшая ЛЕНЬ и я конечно хочу попробовать сделать булетхел, внку или сурвайвор, но мне так сука лень думать и гуглить как реализовывать какието базовые кор вещи для таких проектов
15,6 Мб, mp4,1624x720, 0:53
>>1401
Делаю мультиплеерный джедай лайк экстракшен экшн от третьего лица.
Трудностей много, в последнее время занимался синхронизацией мультиплеера, почему-то при смерти игрока не всегда сигнал регистрируется. Ещё расчлененку которую хотел не получится всунуть, придется делать обычную. Ещё кингдом кам второй вышел и на завод вчера пришлось пиздовать устраиваться, придется игрой ток по выходным заниматься. В общем пиздец.
Делаю мультиплеерный джедай лайк экстракшен экшн от третьего лица.
>С какими трудностями столкнулись?
Трудностей много, в последнее время занимался синхронизацией мультиплеера, почему-то при смерти игрока не всегда сигнал регистрируется. Ещё расчлененку которую хотел не получится всунуть, придется делать обычную. Ещё кингдом кам второй вышел и на завод вчера пришлось пиздовать устраиваться, придется игрой ток по выходным заниматься. В общем пиздец.
966 Кб, 1024x1024>>1517
Ого! Любопытный проект. Очень много играл в Jedi Academy в свое время. На ней еще не так много лет назад жил и процветал глобальный мод MovieBattles 2, там боевка вообще космическая. Лучше нигде не видел. Чекнул, вроде до сих пор игроки есть, если захочешь вдохновиться/рефы собрать - https://servers.moviebattles.org/ (Порог вхождения невероятно высок)
Путь разработчика тернист, но не будет обижен тот, кто не отступил. Взять крутую идею из игры прошлого и дать ей новую жизнь - отличный план, успехов тебе Вот бы еще Oni (2001) кто-нибудь воскресил
Ого! Любопытный проект. Очень много играл в Jedi Academy в свое время. На ней еще не так много лет назад жил и процветал глобальный мод MovieBattles 2, там боевка вообще космическая. Лучше нигде не видел. Чекнул, вроде до сих пор игроки есть, если захочешь вдохновиться/рефы собрать - https://servers.moviebattles.org/ (Порог вхождения невероятно высок)
Путь разработчика тернист, но не будет обижен тот, кто не отступил. Взять крутую идею из игры прошлого и дать ей новую жизнь - отличный план, успехов тебе Вот бы еще Oni (2001) кто-нибудь воскресил
>>1500
А для меня это одна из хороших сторон соло разработки. Устал работать с кодом - пошел на чилле делать ассеты, устал от этого - пошел анимациями заниматься и так далее
Почему так? Программирование и вовсе вещь абстрактная, главное хотя бы примерно понимать, какой у тебя контекст
Можно разбивать по дням - день кода, день ассетов
> основные сложности - это необходимость переключаться между различными несвязанными задачами в процессе разработки в соло
А для меня это одна из хороших сторон соло разработки. Устал работать с кодом - пошел на чилле делать ассеты, устал от этого - пошел анимациями заниматься и так далее
> выматывает, особенно когда садишься с одной целью типа добавить какуюнить механику, но тебе нужно вместо того чтобы кодить переключаться и пиздовать разбираться со звуком или рисовать
Почему так? Программирование и вовсе вещь абстрактная, главное хотя бы примерно понимать, какой у тебя контекст
Можно разбивать по дням - день кода, день ассетов
>>1530
ну я и делю по дням
дизморалит как раз внезапная необходимость переключаться
например когда заметил какуюто ошибку в спрайтах и нужно все бросать и идти переделывать
>Почему так?
ну я и делю по дням
дизморалит как раз внезапная необходимость переключаться
например когда заметил какуюто ошибку в спрайтах и нужно все бросать и идти переделывать
>>1537
Кто-то стоит рядом и заставляет под дулом пистолета? Жил этот корявый спрайт и поживет еще пару часов-дней. Запиши в список дел и продолжай работать над чем работал, потом наберешь с десяток корявых спрайтов и все разом поправишь.
>нужно все бросать
Кто-то стоит рядом и заставляет под дулом пистолета? Жил этот корявый спрайт и поживет еще пару часов-дней. Запиши в список дел и продолжай работать над чем работал, потом наберешь с десяток корявых спрайтов и все разом поправишь.
>>1553
ну так оно и копится, ты же видел видос, там полно косяков в том числе в визуале
это все мелочи которые не сильно влияют на мотивацию, но им свойственно накапливаться, только и всего
в какойто момент негатив от процесса превышает интерес и я дропаю проект, досадно конечно, но геймдев в целом одно из многих недоразвитых моих хобби, я к этому всему нормально отношусь
ну так оно и копится, ты же видел видос, там полно косяков в том числе в визуале
это все мелочи которые не сильно влияют на мотивацию, но им свойственно накапливаться, только и всего
в какойто момент негатив от процесса превышает интерес и я дропаю проект, досадно конечно, но геймдев в целом одно из многих недоразвитых моих хобби, я к этому всему нормально отношусь
>>1401
Порноигру.
Из сложностей реально могу выделить связку моделей с фронтендами. Имею в виду что-то вроде View и Model в MVVM, MVC или MVP. Очень много ломается у меня на промежуточных этапах. Еще невероятно сложно работать со всем, что как-то связано не с тактами процессора, а с человеческим временем. Всякие анимации, твины и синхронизации штук. Если в крации, то считать математику и писать алгоритмы мне весело и легко, а когда дело доходит до того, что нужно игроку это показать где-то кроме консоли, начинается боль и тоска. Это что касается технической части. А по наполнению сложно диалоги выдумывать и работать с визуалом. Рисовать, дизайнить, красить модельки.
Порноигру.
Из сложностей реально могу выделить связку моделей с фронтендами. Имею в виду что-то вроде View и Model в MVVM, MVC или MVP. Очень много ломается у меня на промежуточных этапах. Еще невероятно сложно работать со всем, что как-то связано не с тактами процессора, а с человеческим временем. Всякие анимации, твины и синхронизации штук. Если в крации, то считать математику и писать алгоритмы мне весело и легко, а когда дело доходит до того, что нужно игроку это показать где-то кроме консоли, начинается боль и тоска. Это что касается технической части. А по наполнению сложно диалоги выдумывать и работать с визуалом. Рисовать, дизайнить, красить модельки.
>>1721
Воу, ты здесь. Я думал ты давно ушёл. Обожаю твою карлицу. А смысл? Вон в АААА треде подбери подходящий. Или давай вместе придумаем ИТТ?
Воу, ты здесь. Я думал ты давно ушёл. Обожаю твою карлицу. А смысл? Вон в АААА треде подбери подходящий. Или давай вместе придумаем ИТТ?
169 Кб, 1126x457
42 Кб, 645x363>>1738
А я предлагаю пилить нетипичный жанр. У анона на видосах есть крюк-кошка, сбор ресурсов для крафта, кнопки, сундуки. И горячая жопастая карлица. Анончик в двух шагах от хита, который сделает его богатым и знаменитым. Нужно только придумать карлице историю и геймплейно рассказать её.
А я предлагаю пилить нетипичный жанр. У анона на видосах есть крюк-кошка, сбор ресурсов для крафта, кнопки, сундуки. И горячая жопастая карлица. Анончик в двух шагах от хита, который сделает его богатым и знаменитым. Нужно только придумать карлице историю и геймплейно рассказать её.
>>1755
ПЛЮСЫ обязательны. Без них смысла лезть особо и нет.
ПЛЮСЫ обязательны. Без них смысла лезть особо и нет.
>>1755
ГДСкрипт основной язык годота.
ГДСкрипт основной язык годота.
>>1755
gd скрипт заебись, дока подробная, инфы дохуя, шарп нинужен
gd скрипт заебись, дока подробная, инфы дохуя, шарп нинужен
>>1755
GDScript достаточно для 99.99% твоих идей. У него всего одна проблема - низкая производительность, которая проявляется, если тебе нужно перемолотить >100000 чисел за один кадр, что нужно крайне редко и только в определённых жанрах игр. В остальном производительности хватает. Зато удобный редактор, быстрое прототипирование, лёгкое редактирование, плотная интеграция в ядро движка, много обучающих материалов, широкая поддержка сообщества (плагины и т.п.).
Если нужна производительность, лучше выбирать C/C++ - это эффективнее C#.
Роль C# в Godot - удобство для переходящих с Unity/MonoGame и т.п.
GDScript достаточно для 99.99% твоих идей. У него всего одна проблема - низкая производительность, которая проявляется, если тебе нужно перемолотить >100000 чисел за один кадр, что нужно крайне редко и только в определённых жанрах игр. В остальном производительности хватает. Зато удобный редактор, быстрое прототипирование, лёгкое редактирование, плотная интеграция в ядро движка, много обучающих материалов, широкая поддержка сообщества (плагины и т.п.).
Если нужна производительность, лучше выбирать C/C++ - это эффективнее C#.
Роль C# в Godot - удобство для переходящих с Unity/MonoGame и т.п.
Я устал делать игру, Гендальф. Мне нужен отдых... долгий отдых...
4,5 Мб, mp4,480x360, 1:42
Попробовал по-другому генерировать "остров" - мелкие камни между более крупными создают узкие ненадёжные "дорожки" для перемещения к ценным ресурсам. Эта идея давно у меня появилась, но почему-то откладывал, а потом вообще забыл об этом.
>>1725
Да, ушёл, но кроме попыток разработать игру у меня нет продуктивных увлечений.
Чем она тебе нравится? Это сырой прототип, его нужно будет сильно переделать, если я когда-нибудь доведу игру до релиза. И она не такая уж низкая... только бёдра широкие и голова увеличена под "стиль аниме" (лицо лень пока доделывать, просто представьте большие аниме-глаза).
У меня полно идей/концептов, не в них дело. Смысла не вижу, потому что я всегда хотел сделать игру, в которую мне самому будет интересно играть долгое время - в буквальном смысле, а не "вот если бы кто-то такое сделал". Проблема в том, что как игрок я так называемый "исследователь" (explorer): мне доставляет удовольствие изучать игровые миры и механики, экспериментировать с ними и всё такое, и я теряю интерес к игре, если она больше не может доставить то, чего я ещё не знал.
Поэтому я так сильно увлекаюсь процедурной генерацией (создание контента самой игрой по заданным правилам, чтобы нельзя было предугадать события, даже если давно играешь), но сделать интересный процедурный генератор оказалось намного сложнее, чем я рассчитывал, тем более что я знаю его правила (знаю, чего ожидать). Делать статичную карту, статичный контент, тем более сюжет - мне совершенно не интересно. Как реализовать "эмерджентность" (чтобы сумма частей давала что-то, чего нет в составляющих её частях) я не знаю.
Мне всё равно, если я никогда никакую игру не доведу до релиза. Не хочу вываливать "абы что, лишь бы выложить". Если получится что-то, что меня надолго зацепит, хотел бы обновлять и поддерживать много лет подряд, но до сих пор ничего достаточно интересного не получилось.
>>1738
Да, в концепте сильный акцент на коллекционирование, но мне совершенно не интересно собирать заранее известные предметы в заранее известных местах статичной карты. Вот я и застрял на процедурной генерации интересного мира, без которого механики не взлетают.
>>1744
Это неинтересно, я игру интересную хочу, для себя... Иначе зачем это всё.
Для каких-то историй (линейных/нелинейных) в этой концепции есть место, но их нет смысла сейчас писать, если сама концепция в целом не взлетает (для меня лично, как основного игрока).
Впрочем, меня также расстраивает, что мой проект не имеет ни одного шанса стать широко известным по сравнению с аналогами по жанру и сеттингу. Даже если сделаю интересную игру, раскрутить её нереально, если у тебя не целый штат художников, аниматоров и специалистов по спецэффектам... Графика, всё-таки, продаёт игру широкому потребителю (даже если игра полностью бесплатная).
>>1725
>Воу, ты здесь. Я думал ты давно ушёл.
Да, ушёл, но кроме попыток разработать игру у меня нет продуктивных увлечений.
>Обожаю твою карлицу.
Чем она тебе нравится? Это сырой прототип, его нужно будет сильно переделать, если я когда-нибудь доведу игру до релиза. И она не такая уж низкая... только бёдра широкие и голова увеличена под "стиль аниме" (лицо лень пока доделывать, просто представьте большие аниме-глаза).
>в АААА треде подбери подходящий. Или давай вместе придумаем
У меня полно идей/концептов, не в них дело. Смысла не вижу, потому что я всегда хотел сделать игру, в которую мне самому будет интересно играть долгое время - в буквальном смысле, а не "вот если бы кто-то такое сделал". Проблема в том, что как игрок я так называемый "исследователь" (explorer): мне доставляет удовольствие изучать игровые миры и механики, экспериментировать с ними и всё такое, и я теряю интерес к игре, если она больше не может доставить то, чего я ещё не знал.
Поэтому я так сильно увлекаюсь процедурной генерацией (создание контента самой игрой по заданным правилам, чтобы нельзя было предугадать события, даже если давно играешь), но сделать интересный процедурный генератор оказалось намного сложнее, чем я рассчитывал, тем более что я знаю его правила (знаю, чего ожидать). Делать статичную карту, статичный контент, тем более сюжет - мне совершенно не интересно. Как реализовать "эмерджентность" (чтобы сумма частей давала что-то, чего нет в составляющих её частях) я не знаю.
Мне всё равно, если я никогда никакую игру не доведу до релиза. Не хочу вываливать "абы что, лишь бы выложить". Если получится что-то, что меня надолго зацепит, хотел бы обновлять и поддерживать много лет подряд, но до сих пор ничего достаточно интересного не получилось.
>>1738
>собиранию предметов
Да, в концепте сильный акцент на коллекционирование, но мне совершенно не интересно собирать заранее известные предметы в заранее известных местах статичной карты. Вот я и застрял на процедурной генерации интересного мира, без которого механики не взлетают.
>>1744
>богатым и знаменитым
Это неинтересно, я игру интересную хочу, для себя... Иначе зачем это всё.
Для каких-то историй (линейных/нелинейных) в этой концепции есть место, но их нет смысла сейчас писать, если сама концепция в целом не взлетает (для меня лично, как основного игрока).
Впрочем, меня также расстраивает, что мой проект не имеет ни одного шанса стать широко известным по сравнению с аналогами по жанру и сеттингу. Даже если сделаю интересную игру, раскрутить её нереально, если у тебя не целый штат художников, аниматоров и специалистов по спецэффектам... Графика, всё-таки, продаёт игру широкому потребителю (даже если игра полностью бесплатная).
4,5 Мб, mp4,480x360, 1:42
Попробовал по-другому генерировать "остров" - мелкие камни между более крупными создают узкие ненадёжные "дорожки" для перемещения к ценным ресурсам. Эта идея давно у меня появилась, но почему-то откладывал, а потом вообще забыл об этом.
>>1725
Да, ушёл, но кроме попыток разработать игру у меня нет продуктивных увлечений.
Чем она тебе нравится? Это сырой прототип, его нужно будет сильно переделать, если я когда-нибудь доведу игру до релиза. И она не такая уж низкая... только бёдра широкие и голова увеличена под "стиль аниме" (лицо лень пока доделывать, просто представьте большие аниме-глаза).
У меня полно идей/концептов, не в них дело. Смысла не вижу, потому что я всегда хотел сделать игру, в которую мне самому будет интересно играть долгое время - в буквальном смысле, а не "вот если бы кто-то такое сделал". Проблема в том, что как игрок я так называемый "исследователь" (explorer): мне доставляет удовольствие изучать игровые миры и механики, экспериментировать с ними и всё такое, и я теряю интерес к игре, если она больше не может доставить то, чего я ещё не знал.
Поэтому я так сильно увлекаюсь процедурной генерацией (создание контента самой игрой по заданным правилам, чтобы нельзя было предугадать события, даже если давно играешь), но сделать интересный процедурный генератор оказалось намного сложнее, чем я рассчитывал, тем более что я знаю его правила (знаю, чего ожидать). Делать статичную карту, статичный контент, тем более сюжет - мне совершенно не интересно. Как реализовать "эмерджентность" (чтобы сумма частей давала что-то, чего нет в составляющих её частях) я не знаю.
Мне всё равно, если я никогда никакую игру не доведу до релиза. Не хочу вываливать "абы что, лишь бы выложить". Если получится что-то, что меня надолго зацепит, хотел бы обновлять и поддерживать много лет подряд, но до сих пор ничего достаточно интересного не получилось.
>>1738
Да, в концепте сильный акцент на коллекционирование, но мне совершенно не интересно собирать заранее известные предметы в заранее известных местах статичной карты. Вот я и застрял на процедурной генерации интересного мира, без которого механики не взлетают.
>>1744
Это неинтересно, я игру интересную хочу, для себя... Иначе зачем это всё.
Для каких-то историй (линейных/нелинейных) в этой концепции есть место, но их нет смысла сейчас писать, если сама концепция в целом не взлетает (для меня лично, как основного игрока).
Впрочем, меня также расстраивает, что мой проект не имеет ни одного шанса стать широко известным по сравнению с аналогами по жанру и сеттингу. Даже если сделаю интересную игру, раскрутить её нереально, если у тебя не целый штат художников, аниматоров и специалистов по спецэффектам... Графика, всё-таки, продаёт игру широкому потребителю (даже если игра полностью бесплатная).
>>1725
>Воу, ты здесь. Я думал ты давно ушёл.
Да, ушёл, но кроме попыток разработать игру у меня нет продуктивных увлечений.
>Обожаю твою карлицу.
Чем она тебе нравится? Это сырой прототип, его нужно будет сильно переделать, если я когда-нибудь доведу игру до релиза. И она не такая уж низкая... только бёдра широкие и голова увеличена под "стиль аниме" (лицо лень пока доделывать, просто представьте большие аниме-глаза).
>в АААА треде подбери подходящий. Или давай вместе придумаем
У меня полно идей/концептов, не в них дело. Смысла не вижу, потому что я всегда хотел сделать игру, в которую мне самому будет интересно играть долгое время - в буквальном смысле, а не "вот если бы кто-то такое сделал". Проблема в том, что как игрок я так называемый "исследователь" (explorer): мне доставляет удовольствие изучать игровые миры и механики, экспериментировать с ними и всё такое, и я теряю интерес к игре, если она больше не может доставить то, чего я ещё не знал.
Поэтому я так сильно увлекаюсь процедурной генерацией (создание контента самой игрой по заданным правилам, чтобы нельзя было предугадать события, даже если давно играешь), но сделать интересный процедурный генератор оказалось намного сложнее, чем я рассчитывал, тем более что я знаю его правила (знаю, чего ожидать). Делать статичную карту, статичный контент, тем более сюжет - мне совершенно не интересно. Как реализовать "эмерджентность" (чтобы сумма частей давала что-то, чего нет в составляющих её частях) я не знаю.
Мне всё равно, если я никогда никакую игру не доведу до релиза. Не хочу вываливать "абы что, лишь бы выложить". Если получится что-то, что меня надолго зацепит, хотел бы обновлять и поддерживать много лет подряд, но до сих пор ничего достаточно интересного не получилось.
>>1738
>собиранию предметов
Да, в концепте сильный акцент на коллекционирование, но мне совершенно не интересно собирать заранее известные предметы в заранее известных местах статичной карты. Вот я и застрял на процедурной генерации интересного мира, без которого механики не взлетают.
>>1744
>богатым и знаменитым
Это неинтересно, я игру интересную хочу, для себя... Иначе зачем это всё.
Для каких-то историй (линейных/нелинейных) в этой концепции есть место, но их нет смысла сейчас писать, если сама концепция в целом не взлетает (для меня лично, как основного игрока).
Впрочем, меня также расстраивает, что мой проект не имеет ни одного шанса стать широко известным по сравнению с аналогами по жанру и сеттингу. Даже если сделаю интересную игру, раскрутить её нереально, если у тебя не целый штат художников, аниматоров и специалистов по спецэффектам... Графика, всё-таки, продаёт игру широкому потребителю (даже если игра полностью бесплатная).
>>0909 (OP)
Где взять модельку годотки в норм качестве и с цел шейдером?
Где взять модельку годотки в норм качестве и с цел шейдером?
>>1798
https://sketchfab.com/3d-models/godette-rigged-dd05b69799a2438e97c90d166f6e416a
https://sketchfab.com/3d-models/godette-chan-5e5dd8978e21431f992dee953c11558d
100500 лет в гугле. Целл шейдинг шейдером сделаешь.
https://sketchfab.com/3d-models/godette-rigged-dd05b69799a2438e97c90d166f6e416a
https://sketchfab.com/3d-models/godette-chan-5e5dd8978e21431f992dee953c11558d
100500 лет в гугле. Целл шейдинг шейдером сделаешь.
>>1827
чето всратые надо 3д научиться быстренько и сделать вам нормальный
чето всратые надо 3д научиться быстренько и сделать вам нормальный
>>1781
Тогда ты вляпался, пчел. Говорят же - не делайте игру мечты. Пока вы ее делаете она вас заебет, интерес угаснет, игра мечты превратится в игру-рутину. А в лучшем случае вы ее настолько знать будете, что игроком в нее быть уже не сможете.
Мне нравится другой подход - получать кайф от того, как я вижу/представляю как в мою игру играют другие. Вот тут я ебну игрока ловушкой, вот тут он, возможно, посмеется с диалога, вот тут он будет страдать. Это как наблюдать за колонией петов-муравьев. Смотришь как они ползают по новому аквариуму, изучают то, что ты им дал, носят-жуют, строят, с чем справляются, с чем нет. Когда я смотрел летсплеи своих предыдущих игр, которые делали мелкие ютуберы, это был 10 из 10 экспириенс.
>я всегда хотел сделать игру, в которую мне самому будет интересно играть долгое время - в буквальном смысле, а не "вот если бы кто-то такое сделал"
Тогда ты вляпался, пчел. Говорят же - не делайте игру мечты. Пока вы ее делаете она вас заебет, интерес угаснет, игра мечты превратится в игру-рутину. А в лучшем случае вы ее настолько знать будете, что игроком в нее быть уже не сможете.
Мне нравится другой подход - получать кайф от того, как я вижу/представляю как в мою игру играют другие. Вот тут я ебну игрока ловушкой, вот тут он, возможно, посмеется с диалога, вот тут он будет страдать. Это как наблюдать за колонией петов-муравьев. Смотришь как они ползают по новому аквариуму, изучают то, что ты им дал, носят-жуют, строят, с чем справляются, с чем нет. Когда я смотрел летсплеи своих предыдущих игр, которые делали мелкие ютуберы, это был 10 из 10 экспириенс.
>>1834
Годно. Намотал на ус.
Годно. Намотал на ус.
>>1834
А мне наоборот стало гораздо легче работать, когда переключился на игру мечты. Мотивация, желание работы очень выросли, радостно как-то. Раньше шел на компромиссы, пробовал работать в неинтересных для меня жанрах, и это была пытка. Просто нужно быть сдержанным в своих мечтах. Но у меня не игра-симуляция, а нарративная игра. Да, спустя сотни часов разработки и плейтестов я буду знать все от и до, но получу огромную радость, когда другие игроки смогут пережить этот нарративный опыт
> Тогда ты вляпался, пчел. Говорят же - не делайте игру мечты.
А мне наоборот стало гораздо легче работать, когда переключился на игру мечты. Мотивация, желание работы очень выросли, радостно как-то. Раньше шел на компромиссы, пробовал работать в неинтересных для меня жанрах, и это была пытка. Просто нужно быть сдержанным в своих мечтах. Но у меня не игра-симуляция, а нарративная игра. Да, спустя сотни часов разработки и плейтестов я буду знать все от и до, но получу огромную радость, когда другие игроки смогут пережить этот нарративный опыт
Блеее, оказывается самое сложное не игру сделать, а нарисовать нормальные ассеты...
>>2000
братаааааан, какая жиза, пиздец
начал рисовать боссов себе, набросал концепты, сел рисовать под анимирование и анимации и задушился, пойду поиграю во чтонибудь или лучше вообще отдохну от пеки недельку, потом со свежей головой сяду рисовать
братаааааан, какая жиза, пиздец
начал рисовать боссов себе, набросал концепты, сел рисовать под анимирование и анимации и задушился, пойду поиграю во чтонибудь или лучше вообще отдохну от пеки недельку, потом со свежей головой сяду рисовать
>>2010
Последний раз я покупал игры году эдак в 2005, и тогда они стоили 70 рублей за диск, а на диске могло быть много игр
Последний раз я покупал игры году эдак в 2005, и тогда они стоили 70 рублей за диск, а на диске могло быть много игр
>>2019
Ну так и не жалуйся, что игры говно. Ты игры не покупаешь, а покупают пидарасы при бабле, и пидарасы при бабле заказывают музыку. Хочу, говорит, чтобы бабы были страшные мужеподобные, сделой. И деньги швыряет в разраба.
Ну так и не жалуйся, что игры говно. Ты игры не покупаешь, а покупают пидарасы при бабле, и пидарасы при бабле заказывают музыку. Хочу, говорит, чтобы бабы были страшные мужеподобные, сделой. И деньги швыряет в разраба.
>>2000
Авторы халвера и майнкрафта передают привет.
Не выебывайся и делай игру про кубы.
>Блеее, оказывается самое сложное не игру сделать, а нарисовать нормальные ассеты...
Авторы халвера и майнкрафта передают привет.
Не выебывайся и делай игру про кубы.
>>2026
Да я фан-игру делаю, там кубами не отделаешься, иначе будет неузнаваемо (разве что если абстрактный стиль выбрать). Кстати об этом, насколько велика вероятность, что меня взъебут валвы за фан-игру по TF2? Бесплатную канеш, но в мире копирастов это вроде не смягчающее обстоятельство. И насколько толерантны к такого рода играм на итчио читай: не снесут ли автоматом через 10 минут?
Да я фан-игру делаю, там кубами не отделаешься, иначе будет неузнаваемо (разве что если абстрактный стиль выбрать). Кстати об этом, насколько велика вероятность, что меня взъебут валвы за фан-игру по TF2? Бесплатную канеш, но в мире копирастов это вроде не смягчающее обстоятельство. И насколько толерантны к такого рода играм на итчио читай: не снесут ли автоматом через 10 минут?
>>2037
Из-за фан-игры по ФАНКО ПОП у итча недавно домен отняли.
>И насколько толерантны к такого рода играм на итчио
Из-за фан-игры по ФАНКО ПОП у итча недавно домен отняли.
>>2037
В прошлом месяце выпустил фан-игру на итче, полет нормальный. Там даже отдельный тэг для такого есть.
В прошлом месяце выпустил фан-игру на итче, полет нормальный. Там даже отдельный тэг для такого есть.
>>1781
Я вот этого не понимаю. Наверное мы с тобой действительно мыслим по разному. Для меня истории и геймплей тесно переплетены и я создавая геймплей одновременно создаю историю, которая этим геймплеем реализуется, затем, продумывая историю дальше, я нахожу идеи для развития геймплея.
Например. У этой тян на видосах есть некий реактивный баллон на спине, из которого вылетает струя, когда ты разгоняешься. Не знаю, сам ты это делал или скачал, но просто наблюдая за этим баллоном я уже напридумывал у себя в голове идей, как этот баллон крафтить, откуда он взялся, как он встроен в экономику, какие есть стратегии его прокачки. Если это начать подробно расписывать уже будут несколько длиннопостов. Плюс возникают такие уже побочные сюжетные вбросы типа, на одном из островов хижина в которой чертёж мощного реактивного ранца, но чтобы его собрать нужно отправиться вот туда, туда, и еще туда. Поговорить с тем, помочь этой, побороться с теми. То есть просто от одного взгляда на видос сформулировался в голове целый диздок.
> их нет смысла сейчас писать, если сама концепция в целом не взлетает (для меня лично, как основного игрока)
Я вот этого не понимаю. Наверное мы с тобой действительно мыслим по разному. Для меня истории и геймплей тесно переплетены и я создавая геймплей одновременно создаю историю, которая этим геймплеем реализуется, затем, продумывая историю дальше, я нахожу идеи для развития геймплея.
Например. У этой тян на видосах есть некий реактивный баллон на спине, из которого вылетает струя, когда ты разгоняешься. Не знаю, сам ты это делал или скачал, но просто наблюдая за этим баллоном я уже напридумывал у себя в голове идей, как этот баллон крафтить, откуда он взялся, как он встроен в экономику, какие есть стратегии его прокачки. Если это начать подробно расписывать уже будут несколько длиннопостов. Плюс возникают такие уже побочные сюжетные вбросы типа, на одном из островов хижина в которой чертёж мощного реактивного ранца, но чтобы его собрать нужно отправиться вот туда, туда, и еще туда. Поговорить с тем, помочь этой, побороться с теми. То есть просто от одного взгляда на видос сформулировался в голове целый диздок.
427 Кб, 1280x720>>2037
В США есть понятие fair use:
https://en.wikipedia.org/wiki/Fair_use
Если ни копейки не берёшь с игроков, не просишь пожертвования и т.д., то можешь любые ассеты из оригинальной игры брать без разрешения. По идее.
Конкретные нюансы нужно изучать, но если ты, для примера, хочешь визуальную новеллу сделать, то нет проблемы использовать скриншоты из оригинала... Огромное количество роликов на ютубе сделаны так, используя оригинальные модели из TF2 в SFM.
Немного сложнее если ты делаешь онлайн-шутер: получается, ты пытаешься перетянуть игроков. Но существует TF2 Classic и Valve их оставила в покое (проблема была в использовании утёкшего кода).
Но если всё же хочешь сделать 100% оригинальные ассеты узнаваемыми, совет: что делает персонажей узнаваемыми? Повтори самые яркие элементы, всё остальное убери. Запоминающиеся персонажи на практике состоят из небольшого числа элементов, комбинация которых делает их уникальными. Если повторишь эти элементы, то персонажи останутся узнаваемыми даже в стиле Майнкрафта.
Итчио никакого отношения к этому вопросу не имеет. Выложенную игру удалят только если получат DMCA, конкретно от сотрудников Valve. В противном случае причины удалять твою игру у итчио просто нет.
Недавний конфликт итча был вызван тем, что DMCA направили хостеру, а админ на хостере поленился и автоматическая система удалила домен по таймеру. Наверное, не помню точно. Т.е. итч быстро на DMCA среагировал, а хостер не справился с автоматикой. Однако, причина была в DMCA от правообладателя. Конкретно в твоём случае инициатива за Valve.
TL;DR: Valve безразлична твоя игра, в худшем случае вежливо попросят удалить и итч её просто удалит. Но вероятность крайне мала, даже если оригинальные модельки из папки игры скопируешь.
В США есть понятие fair use:
https://en.wikipedia.org/wiki/Fair_use
Если ни копейки не берёшь с игроков, не просишь пожертвования и т.д., то можешь любые ассеты из оригинальной игры брать без разрешения. По идее.
Конкретные нюансы нужно изучать, но если ты, для примера, хочешь визуальную новеллу сделать, то нет проблемы использовать скриншоты из оригинала... Огромное количество роликов на ютубе сделаны так, используя оригинальные модели из TF2 в SFM.
Немного сложнее если ты делаешь онлайн-шутер: получается, ты пытаешься перетянуть игроков. Но существует TF2 Classic и Valve их оставила в покое (проблема была в использовании утёкшего кода).
Но если всё же хочешь сделать 100% оригинальные ассеты узнаваемыми, совет: что делает персонажей узнаваемыми? Повтори самые яркие элементы, всё остальное убери. Запоминающиеся персонажи на практике состоят из небольшого числа элементов, комбинация которых делает их уникальными. Если повторишь эти элементы, то персонажи останутся узнаваемыми даже в стиле Майнкрафта.
Итчио никакого отношения к этому вопросу не имеет. Выложенную игру удалят только если получат DMCA, конкретно от сотрудников Valve. В противном случае причины удалять твою игру у итчио просто нет.
Недавний конфликт итча был вызван тем, что DMCA направили хостеру, а админ на хостере поленился и автоматическая система удалила домен по таймеру. Наверное, не помню точно. Т.е. итч быстро на DMCA среагировал, а хостер не справился с автоматикой. Однако, причина была в DMCA от правообладателя. Конкретно в твоём случае инициатива за Valve.
TL;DR: Valve безразлична твоя игра, в худшем случае вежливо попросят удалить и итч её просто удалит. Но вероятность крайне мала, даже если оригинальные модельки из папки игры скопируешь.
>>2066
Два чаю. Геймплей и нарратив неразрывно связаны, тоже так подхожу к разработке. Да и играть в игры, где одному уделено сильно больше внимания, чем другому, я не могу (конечно, не без исключений). Скажем, ВНки или симуляторы меня не интересуют вовсе
Два чаю. Геймплей и нарратив неразрывно связаны, тоже так подхожу к разработке. Да и играть в игры, где одному уделено сильно больше внимания, чем другому, я не могу (конечно, не без исключений). Скажем, ВНки или симуляторы меня не интересуют вовсе
>>2082
Я не безыгорный, у меня уже есть 4 место на одном из ТВГ. Так что этот гештальт я закрыл. Фдисятке и ниибёт.
Я не безыгорный, у меня уже есть 4 место на одном из ТВГ. Так что этот гештальт я закрыл. Фдисятке и ниибёт.
467 Кб, 960x640>>1834
Вот в том и интерес - сделать игру, что не надоест.
Представляю, как игроки ничего не понимают и не справляются - жалуются, ругают меня, ненавидят...
>>1945
Повезло тебе, раз чётко представляешь "игру мечты". Зачастую мои фантазии слишком расплывчаты, чтоб реализовать их, или реализация не оправдывает мои ожидания и мотивация стремительно улетучивается.
>>2066
Не баллон, а барабан лебёдки типа пикрил. Просто поленился рисовать трос, отложил на потом. Сбоку вылетают типа искры/пыль из двигателя лебёдки.
Крафтить лебёдку не нужно, это основное средство перемещения. Разве что апгрейды к ней добавлю...
Нет, никакого джетпака и даже вингсьюта не будет. Подобные механики убивают фановый геймплей с верёвкой. Для наглядных примеров, гугли критику вингсьюта в игре Spider-Man 2, а также (частично) критику Oppressor Mk II из GTA Online.
Есть такой мем, "игроки оптимизируют фан из игры":
В чём фан прыжков с верёвкой? Ты летишь по дуге, с минимальным контролем траектории, не зная точно, получится ли добраться: ты непрерывно рискуешь сорваться в пропасть или разбиться о препятствие. Траектории интересные и тебе в кайф их нарезать, возможно, пытаться провернуть какой-то "трюк". Эффективность отходит на второй план - динамика перемещения компенсирует его неэффективность.
С джетпаком ты просто зажимаешь кнопку "лететь", летишь по прямой. В худшем случае у тебя топливо закончится, но обычно оно бесконечное. Разбиться невозможно, ошибиться негде, а главное - наиболее оптимальная траектория, тупо по прямой. Да, это эффективно, но не эффектно, и очень скучно, ведь перемещение наиболее предсказуемое, рутинное.
Теперь самое интересное: если в игре реализованы одновременно оба способа, какой выберут игроки? Внезапно, игроки выбирают скучный способ и потом жалуются, что игра слишком скучная. Почему они не выбирают фановый способ? Потому что он не такой эффективный, как скучный. Кажется, что это некий парадокс, но это реальная психология игроков.
Я всё это не просто так расписываю здесь. Вот ты описываешь способ создать механики из сюжета, хвастаешься, что, мол, у тебя на ровном месте
Но ты не предусмотрел, что джетпак будет унылым убийцей фановой механики с верёвкой. Ты просто притянул за уши джетпак лишь бы что-то притянуть. Наверное, эту ошибку и большие компании делают (Rockstar с их супер-тачками, убивающими фан от базового геймплея игры), но это не делает её менее фатальной для геймдизайна игры. Особенно инди.
В общем, что я хочу сказать? Несложно выдумывать миллион "гениальных" идей типа "сделать джетпак и раскидать по миру квесты для его крафта". Сложно соединить эти идеи в чёткий геймдизайн, отбросив несочетающиеся механики, квесты, истории и т.д. Механика джетпака не работает с верёвкой тупо по определению - и поэтому её быть не должно, и нет необходимости выдумывать квесты про джетпак.
Вот поэтому я не спешу наваливать кучу рандомных механик, историй и прочего. Сначала нужно базовые механики реализовать, на которых я давно застрял... Декорации определить. Если декорации (острова) чрезвычайно скучные, то механики не работают. Та генерация мелких камней между крупными вышла внезапно интереснее, чем я оценивал изначально; соответственно это повлияло на механику верёвки (восприятие, ограничение расстояния/скорости). На удивление, даже такие простые на вид элементы геймплея тесно друг с другом взаимодействуют.
Вот в том и интерес - сделать игру, что не надоест.
>представляю как в мою игру играют другие
Представляю, как игроки ничего не понимают и не справляются - жалуются, ругают меня, ненавидят...
>>1945
Повезло тебе, раз чётко представляешь "игру мечты". Зачастую мои фантазии слишком расплывчаты, чтоб реализовать их, или реализация не оправдывает мои ожидания и мотивация стремительно улетучивается.
>>2066
>реактивный баллон на спине
Не баллон, а барабан лебёдки типа пикрил. Просто поленился рисовать трос, отложил на потом. Сбоку вылетают типа искры/пыль из двигателя лебёдки.
Крафтить лебёдку не нужно, это основное средство перемещения. Разве что апгрейды к ней добавлю...
>мощного реактивного ранца
Нет, никакого джетпака и даже вингсьюта не будет. Подобные механики убивают фановый геймплей с верёвкой. Для наглядных примеров, гугли критику вингсьюта в игре 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 с их супер-тачками, убивающими фан от базового геймплея игры), но это не делает её менее фатальной для геймдизайна игры. Особенно инди.
В общем, что я хочу сказать? Несложно выдумывать миллион "гениальных" идей типа "сделать джетпак и раскидать по миру квесты для его крафта". Сложно соединить эти идеи в чёткий геймдизайн, отбросив несочетающиеся механики, квесты, истории и т.д. Механика джетпака не работает с верёвкой тупо по определению - и поэтому её быть не должно, и нет необходимости выдумывать квесты про джетпак.
Вот поэтому я не спешу наваливать кучу рандомных механик, историй и прочего. Сначала нужно базовые механики реализовать, на которых я давно застрял... Декорации определить. Если декорации (острова) чрезвычайно скучные, то механики не работают. Та генерация мелких камней между крупными вышла внезапно интереснее, чем я оценивал изначально; соответственно это повлияло на механику верёвки (восприятие, ограничение расстояния/скорости). На удивление, даже такие простые на вид элементы геймплея тесно друг с другом взаимодействуют.
467 Кб, 960x640>>1834
Вот в том и интерес - сделать игру, что не надоест.
Представляю, как игроки ничего не понимают и не справляются - жалуются, ругают меня, ненавидят...
>>1945
Повезло тебе, раз чётко представляешь "игру мечты". Зачастую мои фантазии слишком расплывчаты, чтоб реализовать их, или реализация не оправдывает мои ожидания и мотивация стремительно улетучивается.
>>2066
Не баллон, а барабан лебёдки типа пикрил. Просто поленился рисовать трос, отложил на потом. Сбоку вылетают типа искры/пыль из двигателя лебёдки.
Крафтить лебёдку не нужно, это основное средство перемещения. Разве что апгрейды к ней добавлю...
Нет, никакого джетпака и даже вингсьюта не будет. Подобные механики убивают фановый геймплей с верёвкой. Для наглядных примеров, гугли критику вингсьюта в игре Spider-Man 2, а также (частично) критику Oppressor Mk II из GTA Online.
Есть такой мем, "игроки оптимизируют фан из игры":
В чём фан прыжков с верёвкой? Ты летишь по дуге, с минимальным контролем траектории, не зная точно, получится ли добраться: ты непрерывно рискуешь сорваться в пропасть или разбиться о препятствие. Траектории интересные и тебе в кайф их нарезать, возможно, пытаться провернуть какой-то "трюк". Эффективность отходит на второй план - динамика перемещения компенсирует его неэффективность.
С джетпаком ты просто зажимаешь кнопку "лететь", летишь по прямой. В худшем случае у тебя топливо закончится, но обычно оно бесконечное. Разбиться невозможно, ошибиться негде, а главное - наиболее оптимальная траектория, тупо по прямой. Да, это эффективно, но не эффектно, и очень скучно, ведь перемещение наиболее предсказуемое, рутинное.
Теперь самое интересное: если в игре реализованы одновременно оба способа, какой выберут игроки? Внезапно, игроки выбирают скучный способ и потом жалуются, что игра слишком скучная. Почему они не выбирают фановый способ? Потому что он не такой эффективный, как скучный. Кажется, что это некий парадокс, но это реальная психология игроков.
Я всё это не просто так расписываю здесь. Вот ты описываешь способ создать механики из сюжета, хвастаешься, что, мол, у тебя на ровном месте
Но ты не предусмотрел, что джетпак будет унылым убийцей фановой механики с верёвкой. Ты просто притянул за уши джетпак лишь бы что-то притянуть. Наверное, эту ошибку и большие компании делают (Rockstar с их супер-тачками, убивающими фан от базового геймплея игры), но это не делает её менее фатальной для геймдизайна игры. Особенно инди.
В общем, что я хочу сказать? Несложно выдумывать миллион "гениальных" идей типа "сделать джетпак и раскидать по миру квесты для его крафта". Сложно соединить эти идеи в чёткий геймдизайн, отбросив несочетающиеся механики, квесты, истории и т.д. Механика джетпака не работает с верёвкой тупо по определению - и поэтому её быть не должно, и нет необходимости выдумывать квесты про джетпак.
Вот поэтому я не спешу наваливать кучу рандомных механик, историй и прочего. Сначала нужно базовые механики реализовать, на которых я давно застрял... Декорации определить. Если декорации (острова) чрезвычайно скучные, то механики не работают. Та генерация мелких камней между крупными вышла внезапно интереснее, чем я оценивал изначально; соответственно это повлияло на механику верёвки (восприятие, ограничение расстояния/скорости). На удивление, даже такие простые на вид элементы геймплея тесно друг с другом взаимодействуют.
Вот в том и интерес - сделать игру, что не надоест.
>представляю как в мою игру играют другие
Представляю, как игроки ничего не понимают и не справляются - жалуются, ругают меня, ненавидят...
>>1945
Повезло тебе, раз чётко представляешь "игру мечты". Зачастую мои фантазии слишком расплывчаты, чтоб реализовать их, или реализация не оправдывает мои ожидания и мотивация стремительно улетучивается.
>>2066
>реактивный баллон на спине
Не баллон, а барабан лебёдки типа пикрил. Просто поленился рисовать трос, отложил на потом. Сбоку вылетают типа искры/пыль из двигателя лебёдки.
Крафтить лебёдку не нужно, это основное средство перемещения. Разве что апгрейды к ней добавлю...
>мощного реактивного ранца
Нет, никакого джетпака и даже вингсьюта не будет. Подобные механики убивают фановый геймплей с верёвкой. Для наглядных примеров, гугли критику вингсьюта в игре 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 с их супер-тачками, убивающими фан от базового геймплея игры), но это не делает её менее фатальной для геймдизайна игры. Особенно инди.
В общем, что я хочу сказать? Несложно выдумывать миллион "гениальных" идей типа "сделать джетпак и раскидать по миру квесты для его крафта". Сложно соединить эти идеи в чёткий геймдизайн, отбросив несочетающиеся механики, квесты, истории и т.д. Механика джетпака не работает с верёвкой тупо по определению - и поэтому её быть не должно, и нет необходимости выдумывать квесты про джетпак.
Вот поэтому я не спешу наваливать кучу рандомных механик, историй и прочего. Сначала нужно базовые механики реализовать, на которых я давно застрял... Декорации определить. Если декорации (острова) чрезвычайно скучные, то механики не работают. Та генерация мелких камней между крупными вышла внезапно интереснее, чем я оценивал изначально; соответственно это повлияло на механику верёвки (восприятие, ограничение расстояния/скорости). На удивление, даже такие простые на вид элементы геймплея тесно друг с другом взаимодействуют.
>>2119
Ты в первый элекс поиграй. Я после него какое-то время вообще не мог представить игры без джетпака.
>С джетпаком ты просто зажимаешь кнопку "лететь", летишь по прямой. В худшем случае у тебя топливо закончится, но обычно оно бесконечное. Разбиться невозможно, ошибиться негде, а главное - наиболее оптимальная траектория, тупо по прямой. Да, это эффективно, но не эффектно, и очень скучно, ведь перемещение наиболее предсказуемое, рутинное.
Ты в первый элекс поиграй. Я после него какое-то время вообще не мог представить игры без джетпака.
>>2037
Валвы не нинтенда. Они в неё ещё и поиграют всем офисом.
Но на всякий случай ты можешь спросить лично у Габена. Он на почту отвечает, говорят.
>>1834
Хм. Я это как-то иначе вижу. Да, я делаю игру, в которую мне же самому было бы интересно играть - но
а) Не для того, чтобы в неё играть, а чтобы поделиться своим интересом с другими;
б) В играх, в которые мне играть не интересно, я не разбираюсь, так что я выбираю делать что-то в рамках своей компетенции;
в) Сделать "как для себя" - это значит наилучшим образом, не на отъебись, а чтоб себе же любимому результат понравился.
>меня взъебут валвы за фан-игру по TF2?
Валвы не нинтенда. Они в неё ещё и поиграют всем офисом.
Но на всякий случай ты можешь спросить лично у Габена. Он на почту отвечает, говорят.
>>1834
>не делайте игру мечты. Пока вы ее делаете она вас заебет, интерес угаснет
Хм. Я это как-то иначе вижу. Да, я делаю игру, в которую мне же самому было бы интересно играть - но
а) Не для того, чтобы в неё играть, а чтобы поделиться своим интересом с другими;
б) В играх, в которые мне играть не интересно, я не разбираюсь, так что я выбираю делать что-то в рамках своей компетенции;
в) Сделать "как для себя" - это значит наилучшим образом, не на отъебись, а чтоб себе же любимому результат понравился.
>>2130
Пацаны, не надо, не делайте этого, достаточно первых минут видоса глянуть
https://www.youtube.com/watch?v=rfbO8sNgwgk
где видно, что там джетпак с небольшим запасом топлива.
Это можно было сразу написать.
Делайте игры, пацаны, не отвлекайтесь.
> в первый элекс поиграй
Пацаны, не надо, не делайте этого, достаточно первых минут видоса глянуть
https://www.youtube.com/watch?v=rfbO8sNgwgk
где видно, что там джетпак с небольшим запасом топлива.
Это можно было сразу написать.
Делайте игры, пацаны, не отвлекайтесь.
Как же нейронки выручают. Получаешь ответ на любые тупые вопросы, которые в документации или гугле откапывать по 40 минут. Наконец разобрался со всеми типами освещения и методами работы с их нодами. Аж табличку сравнения мне нарисовали.
>>2213
Тоже пытаюсь с нейронкой подружиться. Ты какую используешь, локально ее у себя развернул?
Тоже пытаюсь с нейронкой подружиться. Ты какую используешь, локально ее у себя развернул?
>>2216
Моего железа недостаточно для локалки. Просто в вебе, дипсик р1 и гпт о3-мини. Обычно сразу обоим вопрос закидываю.
Моего железа недостаточно для локалки. Просто в вебе, дипсик р1 и гпт о3-мини. Обычно сразу обоим вопрос закидываю.
>>2223
локальные 7b, который в ollama, вообще бесполезные бредогенераторы, которые генерируют бред даже по самым тривиальным вопросам. локальные модели не годятся ни для чего, кроме сочинения порноисторий и классификации текста.
локальные 7b, который в ollama, вообще бесполезные бредогенераторы, которые генерируют бред даже по самым тривиальным вопросам. локальные модели не годятся ни для чего, кроме сочинения порноисторий и классификации текста.
>>2223
А какая вариация дипсика р1? Их там много подвидов
>>2225
Развернул у себя на ПК через LM Studio R1 Distill Qwen 32b и DeepSeek Coder v2 Lite Instruct. Веб версии не изучал, до этого вообще с LLM не работал. Выдают осмысленные ответы, ошибки иногда если и происходят, то из-за того, что превышен предел контекста
>>2228
Справедливо. В любом случае не нужно ответы нейронки за правду принимать, всегда нужно перепроверять все. Часто помогает найти правильное направление, и этого достаточно по сути. Нужно понимать, что это просто инструмент
> Просто в вебе, дипсик р1
А какая вариация дипсика р1? Их там много подвидов
>>2225
> локальные 7b, который в ollama, вообще бесполезные бредогенераторы
Развернул у себя на ПК через LM Studio R1 Distill Qwen 32b и DeepSeek Coder v2 Lite Instruct. Веб версии не изучал, до этого вообще с LLM не работал. Выдают осмысленные ответы, ошибки иногда если и происходят, то из-за того, что превышен предел контекста
>>2228
> как бы так не вышло, что половина таблички - выдуманная чушь
Справедливо. В любом случае не нужно ответы нейронки за правду принимать, всегда нужно перепроверять все. Часто помогает найти правильное направление, и этого достаточно по сути. Нужно понимать, что это просто инструмент
92 Кб, 885x746>>2233
Вижу только две - с галкой deep think и без. Пользуюсь с галкой.
>А какая вариация дипсика р1? Их там много подвидов
Вижу только две - с галкой deep think и без. Пользуюсь с галкой.
>>2236
А это бесплатно, без регистрации и смс? Если так, скинь ссылку, пожалуйста. Интересно сравнить ответы моего локального Дипсика и этой веб версии
А это бесплатно, без регистрации и смс? Если так, скинь ссылку, пожалуйста. Интересно сравнить ответы моего локального Дипсика и этой веб версии
>>2239
deepseek.com, я под гугловским аккаунтом зашел, бесплатно. Иногда падает от дудоса и перегрузок.
deepseek.com, я под гугловским аккаунтом зашел, бесплатно. Иногда падает от дудоса и перегрузок.
>>2242
Спасибо. Протестил, на маленьких вопросах работают практически идентично, слегка отличается стиль изложения, но сущностная часть одинакова. А вот с большими вопросами и парсингом файлов локальная версия справилась лучше. В моем случае, у нее втрое больше размер контекста (он задается вручную в зависимости от железа). То есть, нейросеть больше переменных учитывает при ответе. На практике это означает, например, что она может проанализировать класс, втрое больший того, что может проанализировать бесплатная веб версия. И еще работает быстрее веб версии. Но полагаю, будь у меня среднестатистическое железо, локальная версия была бы не сильно круче
Спасибо. Протестил, на маленьких вопросах работают практически идентично, слегка отличается стиль изложения, но сущностная часть одинакова. А вот с большими вопросами и парсингом файлов локальная версия справилась лучше. В моем случае, у нее втрое больше размер контекста (он задается вручную в зависимости от железа). То есть, нейросеть больше переменных учитывает при ответе. На практике это означает, например, что она может проанализировать класс, втрое больший того, что может проанализировать бесплатная веб версия. И еще работает быстрее веб версии. Но полагаю, будь у меня среднестатистическое железо, локальная версия была бы не сильно круче
>>2259
Реальность такова, что веб версии хватит на подавляющее большинство юзкейсов. А учитывая, что она еще и бесплатная, то те, кто сидят на слабом железе, почти ничего не теряют. Так что вперед делать игры!
> возвращаемся к печальной реальности.
Реальность такова, что веб версии хватит на подавляющее большинство юзкейсов. А учитывая, что она еще и бесплатная, то те, кто сидят на слабом железе, почти ничего не теряют. Так что вперед делать игры!
>>2265
Тем не менее мы-то с тобой оба прекрасно понимаем, что без мощного железа успешные игры сделать не выйдет. Максимум пиксельные топдауны на итч.
Тем не менее мы-то с тобой оба прекрасно понимаем, что без мощного железа успешные игры сделать не выйдет. Максимум пиксельные топдауны на итч.
>>2276
Если речь про 3D - то да, ты прав. В 2D контексте согласен лишь частично. Все-таки на слабом железе можно справиться и самому, если хватит скилла нарисовать графику или есть возможность привлечь художника. Взять тот же Project Zomboid, как пример. Или Rimworld. Или Prison Architect
Хотя если ОЧЕНЬ захотеть, можно на слабом железе и 3D игру разработать - стилизованную под PS1. Относись как хочешь, но спрос на это есть, и покупают. Недавно вот от разработчика Dusk игра вышла: https://store.steampowered.com/app/2512560/Butchers_Creek/
Если речь про 3D - то да, ты прав. В 2D контексте согласен лишь частично. Все-таки на слабом железе можно справиться и самому, если хватит скилла нарисовать графику или есть возможность привлечь художника. Взять тот же Project Zomboid, как пример. Или Rimworld. Или Prison Architect
Хотя если ОЧЕНЬ захотеть, можно на слабом железе и 3D игру разработать - стилизованную под PS1. Относись как хочешь, но спрос на это есть, и покупают. Недавно вот от разработчика Dusk игра вышла: https://store.steampowered.com/app/2512560/Butchers_Creek/
34 Кб, 867x426>>2284
Вот этот анончик меня понимает. Долой нейрокал!
Вот этот анончик меня понимает. Долой нейрокал!
>>2278
3д инди тоже хороши. Для меня идеалом 3д-в-одно-ебало являются Short Hike и Tunic. Ну, практически в одно ебало - минус музыка.
3д инди тоже хороши. Для меня идеалом 3д-в-одно-ебало являются Short Hike и Tunic. Ну, практически в одно ебало - минус музыка.
>>2282
Уверен что не блок? В списках РКНа дипсика нет, но все бывает. У меня он до состояния твоего скрина ни разу не падал, максимум бот отвечал про недоступность.
Уверен что не блок? В списках РКНа дипсика нет, но все бывает. У меня он до состояния твоего скрина ни разу не падал, максимум бот отвечал про недоступность.
>>2304
Будет забавно, если он прямо на deepseek.com пытался заходить, а не по полному адресу https://www.deepseek.com/
Что-то мне подсказывает, что так оно и есть :^)
Будет забавно, если он прямо на deepseek.com пытался заходить, а не по полному адресу https://www.deepseek.com/
Что-то мне подсказывает, что так оно и есть :^)
427 Кб, 2397x932>>2306
Да ладно тебе, не трясись. Никто тебя тупицей не называл, все мы тупим иногда
Да ладно тебе, не трясись. Никто тебя тупицей не называл, все мы тупим иногда
Игры мои игры
109 Кб, 864x686>>2521
Она неправильные ответы даёт. Вот оцените скриншот. Она должна была всего одно предложение в ответ напечатать и мы бы вместе заплакали, обнявшись.
Она неправильные ответы даёт. Вот оцените скриншот. Она должна была всего одно предложение в ответ напечатать и мы бы вместе заплакали, обнявшись.
>>2528
Здесь обсуждалась польза LLM чатботов в качестве помощника в геймдеве (на Godot), а не абстрактного собутыльника из твоих влажных фантазий. Даже не понимаю, к чему ты это решил запостить, чтобы что? Пошутить захотелось? Не вижу ничего смешного.
Хочешь, чтобы она отыгрывала робота, лезла к тебе обниматься - так и попроси. Лучше на английском, разумеется. К теме треда это никак не относится.
По моему опыту, она правильно обработала запрос, ответила в соответствии с её системным промптом.
Ошибка в запросе. http://en.wikipedia.org/wiki/GIGO
Здесь обсуждалась польза LLM чатботов в качестве помощника в геймдеве (на Godot), а не абстрактного собутыльника из твоих влажных фантазий. Даже не понимаю, к чему ты это решил запостить, чтобы что? Пошутить захотелось? Не вижу ничего смешного.
Хочешь, чтобы она отыгрывала робота, лезла к тебе обниматься - так и попроси. Лучше на английском, разумеется. К теме треда это никак не относится.
По моему опыту, она правильно обработала запрос, ответила в соответствии с её системным промптом.
Ошибка в запросе. http://en.wikipedia.org/wiki/GIGO
Я делаю 2d карточную игру, в которой можно передвигать карты как отдельно так и стаками (подобно stacklands) столкнулся с проблемой обработки события инпута - событие при одних и тех же вводных дает разный результат. Один и тот же ZIndex и одно и то же положение в дереве, но событие срабытывает на разных картах. Карты сделаны из Area2D проблема возникает когда 2 или более карт прикреплены друг к другу и я кликаю на точку где эти карты пересекаются. Например на картинке я кликаю в одну и ту же точку и "кликнутая" карта всегда разная
>>2616
Даже слишком. Не боитесь что как с vampire survivors будет, когда на фоне успеха оригинала вылезло столько подражателей, что ниша быстро переполнилась?
>Чота много карточных игр
Даже слишком. Не боитесь что как с vampire survivors будет, когда на фоне успеха оригинала вылезло столько подражателей, что ниша быстро переполнилась?
>>2671
Да она и так переполнена. И уже давно.
Да она и так переполнена. И уже давно.
>>2609
Тебе не нужен рейкаст, просто используй сигналы:
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. Наверное, для карточной игры это не так важно...
>>2617
Помогло, хотя сцена у меня концептуально проще: большая Area2D и мелкие Area2D поверх неё. Мне необходимо было отловить сигнал с мелких раньше большой, но сигнал приходил рандомно. Я погуглил, попробовал решение - всё заработало. Но я даже не пробовал бросать рейкасты, т.к. это бессмысленно.
>>2671
А что это меняет? Если человеку нравятся пасьянсы и он хочет сделать свой пасьянс, в чём проблема? Большинство игр ничего не приносят независимо от выбранного жанра - их делают ради удовольствия. В отличие от сюжетных игр, в пасьянсы можно играть бесконечно долго, поэтому как минимум один игрок найдётся - сам автор игры. А раз игра интересна её автору, то и другим может быть интересна... Имеет смысл опубликовать, вдруг кто-то ищет именно её.
Делайте игры для себя, и тогда в них гарантировано будет кто-то играть - как минимум вы сами, но раз вы выбираете свою игру, значит, в ней что-то особенное.
Вот сюжетным играм плохо приходится - зачем мне покупать сюжетную игру, если я могу весь её сюжет бесплатно прочитать на её фанатской Вики? Лол. Да летсплей посмотри и всё, самому играть не нужно...
Тебе не нужен рейкаст, просто используй сигналы:
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. Наверное, для карточной игры это не так важно...
>>2617
Помогло, хотя сцена у меня концептуально проще: большая Area2D и мелкие Area2D поверх неё. Мне необходимо было отловить сигнал с мелких раньше большой, но сигнал приходил рандомно. Я погуглил, попробовал решение - всё заработало. Но я даже не пробовал бросать рейкасты, т.к. это бессмысленно.
>>2671
>ниша быстро переполнилась
А что это меняет? Если человеку нравятся пасьянсы и он хочет сделать свой пасьянс, в чём проблема? Большинство игр ничего не приносят независимо от выбранного жанра - их делают ради удовольствия. В отличие от сюжетных игр, в пасьянсы можно играть бесконечно долго, поэтому как минимум один игрок найдётся - сам автор игры. А раз игра интересна её автору, то и другим может быть интересна... Имеет смысл опубликовать, вдруг кто-то ищет именно её.
Делайте игры для себя, и тогда в них гарантировано будет кто-то играть - как минимум вы сами, но раз вы выбираете свою игру, значит, в ней что-то особенное.
Вот сюжетным играм плохо приходится - зачем мне покупать сюжетную игру, если я могу весь её сюжет бесплатно прочитать на её фанатской Вики? Лол. Да летсплей посмотри и всё, самому играть не нужно...
Если вам надо все объекты в 2д, можно вообще не полагаться на сигналы, а воспользоваться чем-то вроде intersect_point() у Physics2DDirectSpaceState
Да что уж там, в 2д можно просто самому сравнить x,y координаты мыши, там не надо хитрых проекций. Только воспользоваться методом камеры чтобы учесть возможные масштабирование и прокрутку. И уже самому разослать сигнал всем картам.
Да что уж там, в 2д можно просто самому сравнить x,y координаты мыши, там не надо хитрых проекций. Только воспользоваться методом камеры чтобы учесть возможные масштабирование и прокрутку. И уже самому разослать сигнал всем картам.
>>2689
Зачем изобретать велосипед на костылях, если ты пользуешься готовым движком, где уже есть всё необходимое для решения твоей задачи?
Ты ещё предложи свой тайлмап изобретать:
Сначала сделай игру, потом оптимизируешь.
Зачем изобретать велосипед на костылях, если ты пользуешься готовым движком, где уже есть всё необходимое для решения твоей задачи?
Ты ещё предложи свой тайлмап изобретать:
>Если нужны только тайлы, можно просто рисовать картинки вызовами графического API, не полагаясь на специально предназначенные для этого ноды...
Сначала сделай игру, потом оптимизируешь.
>>2703
Затем, что в движке есть только средства для обычных задач (кликнуть по одному предмету), а если ты будешь собирать такую механику, то это как раз у тебя будет костыль.
Если привести аналогию, ты хочешь построить клумбу из шин, но у тебя есть только готовые машины, и ты закапываешь их целиком по землю чтобы торчали только колеса.
Затем, что в движке есть только средства для обычных задач (кликнуть по одному предмету), а если ты будешь собирать такую механику, то это как раз у тебя будет костыль.
Если привести аналогию, ты хочешь построить клумбу из шин, но у тебя есть только готовые машины, и ты закапываешь их целиком по землю чтобы торчали только колеса.
>>2710
Что сделать проще прямо сейчас, то и делай.
Если будешь слишком много думать о потенциальных возможностях в будущем, то никогда не сдвинешься с места в настоящем. Сделай что-нибудь, что-то простое, потом будет намного проще переделать - если нужно, поскольку обычно не нужно (идея просто не работает).
Вот input_event использовать легко. Его и используй.
Что сделать проще прямо сейчас, то и делай.
Если будешь слишком много думать о потенциальных возможностях в будущем, то никогда не сдвинешься с места в настоящем. Сделай что-нибудь, что-то простое, потом будет намного проще переделать - если нужно, поскольку обычно не нужно (идея просто не работает).
Вот input_event использовать легко. Его и используй.
>>2068
Поэтому разных модеров подвешивают за яйца, как только они хотят взять текстурки из разных игр.
>Если ни копейки не берёшь с игроков, не просишь пожертвования и т.д., то можешь любые ассеты из оригинальной игры брать без разрешения.
Поэтому разных модеров подвешивают за яйца, как только они хотят взять текстурки из разных игр.
Я работаю быдлокодером на петухоне на галере. Хочу начать заниматься тем, что будет приносить удовольствие, а не перекладыванием джисонов. Скажите, получилось ли у вас лично заработать денег в инди?
67 Кб, 1022x1024>>2717
>Хочу начать заниматься тем, что будет приносить удовольствие
>получилось ли у вас лично заработать денег
>>2717
Без дохода вкатываться в фуллтайм геймдев и стать успешным - то же, что сорвать джекпот в лотерею
Пока еще в процессе разработки первой игры. Долгострой, фуллтайм разработка два года уже, сдаю квартиру в аренду и живу на эти скромные деньги. Что получится - не знаю, для меня главное попытаться
Советую тебе попробовать параллельно основной работе что-нибудь поделать. Скорее всего, таски быстро закрываешь, и времени много. Так придет понимание, интересно ли тебе заниматься геймдевом в целом. Если да - тогда уже думай, как перестраивать свою жизнь
> Я работаю быдлокодером на петухоне на галере. Хочу начать заниматься тем, что будет приносить удовольствие, а не перекладыванием джисонов.
Без дохода вкатываться в фуллтайм геймдев и стать успешным - то же, что сорвать джекпот в лотерею
> Скажите, получилось ли у вас лично заработать денег в инди?
Пока еще в процессе разработки первой игры. Долгострой, фуллтайм разработка два года уже, сдаю квартиру в аренду и живу на эти скромные деньги. Что получится - не знаю, для меня главное попытаться
Советую тебе попробовать параллельно основной работе что-нибудь поделать. Скорее всего, таски быстро закрываешь, и времени много. Так придет понимание, интересно ли тебе заниматься геймдевом в целом. Если да - тогда уже думай, как перестраивать свою жизнь
>>2717
Заработал 101 бакс.
Нет, инди геймдев слишком маловероятен для основного заработка. Поэтому моя основная тема - вебдев.
>Скажите, получилось ли у вас лично заработать денег в инди?
Заработал 101 бакс.
Нет, инди геймдев слишком маловероятен для основного заработка. Поэтому моя основная тема - вебдев.
>>2733
Он вряд ли 1.0 версию запилить для стима, иначе надо монетизировать. На самом деле конкуренции ноль, если хорошая игра.
>>2734
f95, itch, patreon, boosty, sb и т.д
0.1 бесплатно везде, след патчи платные, байтя на подписку на патреоне\бусти\сабскрайбере. Рекламишься в реддите, пишешь остальным порноделам и если есть аудитория репостите друг друга если игры похожего жанра.
Люди годами так получают деньги даже не выпуская игру.
Он вряд ли 1.0 версию запилить для стима, иначе надо монетизировать. На самом деле конкуренции ноль, если хорошая игра.
>>2734
f95, itch, patreon, boosty, sb и т.д
0.1 бесплатно везде, след патчи платные, байтя на подписку на патреоне\бусти\сабскрайбере. Рекламишься в реддите, пишешь остальным порноделам и если есть аудитория репостите друг друга если игры похожего жанра.
Люди годами так получают деньги даже не выпуская игру.
Вы ждали этот видос 2 года, но теперь вы наконец-то узнаете, как делать 3D ИГРЫ НА ГОДОТЕ
https://www.youtube.com/watch?v=ke5KpqcoiIU&t=11s
https://www.youtube.com/watch?v=ke5KpqcoiIU&t=11s
>>2784
Поржать всем тредом.
Поржать всем тредом.
>>2778
Юнькам уже забросил. Слышал Брекейс их любимый тутор, они оценят. Алсо жду очередной наплыв ньюфагов на форумах и реддитах.
Юнькам уже забросил. Слышал Брекейс их любимый тутор, они оценят. Алсо жду очередной наплыв ньюфагов на форумах и реддитах.
Есть ли визуальный стиль, с которым работать быстрее-удобнее чем со стилизованным лоуполи?
>>2831
Речь про 3D? Возможно, графика, стилизованная под PS1 и boomer shooter-like (Dusk, Iron Lung, Hrot). Возможно, это подвид лоуполи, но чаще всего там граней еще меньше, чем в среднестатистическом лоуполи. Текстурирование куда важнее. П>>2831
люс можно использовать billboarding (2D спрайты в 3D мире)
Речь про 3D? Возможно, графика, стилизованная под PS1 и boomer shooter-like (Dusk, Iron Lung, Hrot). Возможно, это подвид лоуполи, но чаще всего там граней еще меньше, чем в среднестатистическом лоуполи. Текстурирование куда важнее. П>>2831
люс можно использовать billboarding (2D спрайты в 3D мире)
>>2831
Есть, называется стилизованный лоуполи.
Есть, называется стилизованный лоуполи.
>>2834
Тут от твоих умений зависит. Мне проще 2D спрайт сделать, чем красивую лоуполи 3D модельку. Если отталкиваться от лоуполи, то вариант на втором пике >>2831 правда неплох. Там, кажется, помимо контрастных цветов еще и cel shading используется. Для игры с изометрической или какой-нибудь еще отдаленной перспективы норм. Если от первого или третьего лица - не факт, что красиво будет, надо чекать. В любом случае, текстурировать PS1/boomer shooter модельки довольно просто, так что все осуществимо. Имхо в инди важна стилизация и общее графическое направление проекта, и сегодня руки совсем развязаны. Если у разработчика есть вкус и время поработать над ассетами, можно сделать приличную графику для любого жанра. Главное, чтобы было интересно (и играть тоже)
Вот, например, ретро survival horror в 2024: https://store.steampowered.com/app/1996010/Crow_Country/
Тут от твоих умений зависит. Мне проще 2D спрайт сделать, чем красивую лоуполи 3D модельку. Если отталкиваться от лоуполи, то вариант на втором пике >>2831 правда неплох. Там, кажется, помимо контрастных цветов еще и cel shading используется. Для игры с изометрической или какой-нибудь еще отдаленной перспективы норм. Если от первого или третьего лица - не факт, что красиво будет, надо чекать. В любом случае, текстурировать PS1/boomer shooter модельки довольно просто, так что все осуществимо. Имхо в инди важна стилизация и общее графическое направление проекта, и сегодня руки совсем развязаны. Если у разработчика есть вкус и время поработать над ассетами, можно сделать приличную графику для любого жанра. Главное, чтобы было интересно (и играть тоже)
Вот, например, ретро survival horror в 2024: https://store.steampowered.com/app/1996010/Crow_Country/
Ну и приведу аналогичный пример для 2D графики. Сурвайвл хоррор на векторной графике: https://store.steampowered.com/app/382140/SKYHILL/
Это я к тому, что сегодня, будучи инди разработчиком, можно добиться приличной графики в игре любого жанра. И это не будет стоить космических усилий, нужно просто искать возможности
Это я к тому, что сегодня, будучи инди разработчиком, можно добиться приличной графики в игре любого жанра. И это не будет стоить космических усилий, нужно просто искать возможности
>>2813
Классно! План по арту для переката перевыполнен. Но ты не останавливайся, лору развивай.
Классно! План по арту для переката перевыполнен. Но ты не останавливайся, лору развивай.
>>2822
По этому поводу у них пердаки перегорели ещё 9 месяцев назад, когда он ожил в нашем лагере.
По этому поводу у них пердаки перегорели ещё 9 месяцев назад, когда он ожил в нашем лагере.
1004 Кб, 1024x1024>>2877
Рад, что пригодилось. Останавливаться - ни в коем случае! Во мне уже пробудился спортивный интерес: насколько далеко удастся зайти, учитывая, что первую версию тренировал на всего лишь одной картинке? Буду иногда присылать что-нибудь в тред
Рад, что пригодилось. Останавливаться - ни в коем случае! Во мне уже пробудился спортивный интерес: насколько далеко удастся зайти, учитывая, что первую версию тренировал на всего лишь одной картинке? Буду иногда присылать что-нибудь в тред
881 Кб, 1595x975Блендер делает свою вторую официальную игру. На Годоте.
https://studio.blender.org/projects/project-dogwalk/
https://studio.blender.org/projects/project-dogwalk/
>>2911
Нихуя себе, вот это да.
Нихуя себе, вот это да.
>>2831
Зависит от твоих навыков. Что тебе удобнее? На мой взгляд, лоупольки без текстур и так самое простое... Главное разобраться в инструментах - количество полигонов значения не имеет, если генерируешь их математическими формулами и модификаторами.
Недавно зародился стиль, называемый "AI slop": генеративным ИИ создаётся нечто непонятное и используется без дополнительной обработки. Если позиционировать свою игру как "slop", тогда всё, что требуется - это промптить и вставлять арт в движок. Естественно, это нишевый стиль, на любителя, но он имеет право на жизнь, как лоуполи с пиксель-артом. Главное - использовать одну и ту же нейронку, строго фиксировать гиперпараметры и промптить в очень определённом стиле, чтоб арт был однородным.
Можно поспорить, что генеративный ИИ лучше, чем ассетфлиперство. Потому что ассетфлипер ограничен имеющимися у него моделями и по определению не способен (не хочет) приводить их в единообразный, согласованный стиль. Генеративный ИИ же, по идее, генерирует всё в одном стиле, поэтому он лучше в контексте визуальной целостности для новой игры. Приблизительно как костыли лучше, чем ползать.
Но понятно, что это чисто на любителя, как граффити какие-нибудь, или пластилиновая/бумажная графика.
>>2832
Рисовать текстуры сложнее, чем лепить меши. Кто пробовал хэндпейнт текстуры, понимает, насколько сложно добиться приличной, стабильной картинки. Лоупольки без текстур - это геометрические фигуры, ничего проще них нет (разве что генеративный ИИ).
>>2834
В 2D тоже можно обойтись примитивной геометрией. Векторная графика имеет крайне низкий порог входа: можно рисовать шедевры самой дешёвой мышкой.
>>2871
Тут нужно ещё принимать во внимание возможность рендерить лоуполи с любой стороны и анимировать скелетом в 3D. Скелеты в 2D сложнее, ограниченнее, выглядят неестественно и поэтому проигрывают 3D. Поэтому, возможно, вложиться в 3D лоуполи лучше.
Нормально всё, видел достаточно таких игр.
>стиль, с которым работать быстрее-удобнее
Зависит от твоих навыков. Что тебе удобнее? На мой взгляд, лоупольки без текстур и так самое простое... Главное разобраться в инструментах - количество полигонов значения не имеет, если генерируешь их математическими формулами и модификаторами.
Недавно зародился стиль, называемый "AI slop": генеративным ИИ создаётся нечто непонятное и используется без дополнительной обработки. Если позиционировать свою игру как "slop", тогда всё, что требуется - это промптить и вставлять арт в движок. Естественно, это нишевый стиль, на любителя, но он имеет право на жизнь, как лоуполи с пиксель-артом. Главное - использовать одну и ту же нейронку, строго фиксировать гиперпараметры и промптить в очень определённом стиле, чтоб арт был однородным.
Можно поспорить, что генеративный ИИ лучше, чем ассетфлиперство. Потому что ассетфлипер ограничен имеющимися у него моделями и по определению не способен (не хочет) приводить их в единообразный, согласованный стиль. Генеративный ИИ же, по идее, генерирует всё в одном стиле, поэтому он лучше в контексте визуальной целостности для новой игры. Приблизительно как костыли лучше, чем ползать.
Но понятно, что это чисто на любителя, как граффити какие-нибудь, или пластилиновая/бумажная графика.
>>2832
>графика, стилизованная под PS1
>Текстурирование куда важнее
Рисовать текстуры сложнее, чем лепить меши. Кто пробовал хэндпейнт текстуры, понимает, насколько сложно добиться приличной, стабильной картинки. Лоупольки без текстур - это геометрические фигуры, ничего проще них нет (разве что генеративный ИИ).
>>2834
>Со спрайтами проблема - их нарисовать надо.
В 2D тоже можно обойтись примитивной геометрией. Векторная графика имеет крайне низкий порог входа: можно рисовать шедевры самой дешёвой мышкой.
>>2871
>проще 2D спрайт сделать, чем красивую лоуполи
Тут нужно ещё принимать во внимание возможность рендерить лоуполи с любой стороны и анимировать скелетом в 3D. Скелеты в 2D сложнее, ограниченнее, выглядят неестественно и поэтому проигрывают 3D. Поэтому, возможно, вложиться в 3D лоуполи лучше.
>Если от первого или третьего лица - не факт
Нормально всё, видел достаточно таких игр.
>>2831
Зависит от твоих навыков. Что тебе удобнее? На мой взгляд, лоупольки без текстур и так самое простое... Главное разобраться в инструментах - количество полигонов значения не имеет, если генерируешь их математическими формулами и модификаторами.
Недавно зародился стиль, называемый "AI slop": генеративным ИИ создаётся нечто непонятное и используется без дополнительной обработки. Если позиционировать свою игру как "slop", тогда всё, что требуется - это промптить и вставлять арт в движок. Естественно, это нишевый стиль, на любителя, но он имеет право на жизнь, как лоуполи с пиксель-артом. Главное - использовать одну и ту же нейронку, строго фиксировать гиперпараметры и промптить в очень определённом стиле, чтоб арт был однородным.
Можно поспорить, что генеративный ИИ лучше, чем ассетфлиперство. Потому что ассетфлипер ограничен имеющимися у него моделями и по определению не способен (не хочет) приводить их в единообразный, согласованный стиль. Генеративный ИИ же, по идее, генерирует всё в одном стиле, поэтому он лучше в контексте визуальной целостности для новой игры. Приблизительно как костыли лучше, чем ползать.
Но понятно, что это чисто на любителя, как граффити какие-нибудь, или пластилиновая/бумажная графика.
>>2832
Рисовать текстуры сложнее, чем лепить меши. Кто пробовал хэндпейнт текстуры, понимает, насколько сложно добиться приличной, стабильной картинки. Лоупольки без текстур - это геометрические фигуры, ничего проще них нет (разве что генеративный ИИ).
>>2834
В 2D тоже можно обойтись примитивной геометрией. Векторная графика имеет крайне низкий порог входа: можно рисовать шедевры самой дешёвой мышкой.
>>2871
Тут нужно ещё принимать во внимание возможность рендерить лоуполи с любой стороны и анимировать скелетом в 3D. Скелеты в 2D сложнее, ограниченнее, выглядят неестественно и поэтому проигрывают 3D. Поэтому, возможно, вложиться в 3D лоуполи лучше.
Нормально всё, видел достаточно таких игр.
>стиль, с которым работать быстрее-удобнее
Зависит от твоих навыков. Что тебе удобнее? На мой взгляд, лоупольки без текстур и так самое простое... Главное разобраться в инструментах - количество полигонов значения не имеет, если генерируешь их математическими формулами и модификаторами.
Недавно зародился стиль, называемый "AI slop": генеративным ИИ создаётся нечто непонятное и используется без дополнительной обработки. Если позиционировать свою игру как "slop", тогда всё, что требуется - это промптить и вставлять арт в движок. Естественно, это нишевый стиль, на любителя, но он имеет право на жизнь, как лоуполи с пиксель-артом. Главное - использовать одну и ту же нейронку, строго фиксировать гиперпараметры и промптить в очень определённом стиле, чтоб арт был однородным.
Можно поспорить, что генеративный ИИ лучше, чем ассетфлиперство. Потому что ассетфлипер ограничен имеющимися у него моделями и по определению не способен (не хочет) приводить их в единообразный, согласованный стиль. Генеративный ИИ же, по идее, генерирует всё в одном стиле, поэтому он лучше в контексте визуальной целостности для новой игры. Приблизительно как костыли лучше, чем ползать.
Но понятно, что это чисто на любителя, как граффити какие-нибудь, или пластилиновая/бумажная графика.
>>2832
>графика, стилизованная под PS1
>Текстурирование куда важнее
Рисовать текстуры сложнее, чем лепить меши. Кто пробовал хэндпейнт текстуры, понимает, насколько сложно добиться приличной, стабильной картинки. Лоупольки без текстур - это геометрические фигуры, ничего проще них нет (разве что генеративный ИИ).
>>2834
>Со спрайтами проблема - их нарисовать надо.
В 2D тоже можно обойтись примитивной геометрией. Векторная графика имеет крайне низкий порог входа: можно рисовать шедевры самой дешёвой мышкой.
>>2871
>проще 2D спрайт сделать, чем красивую лоуполи
Тут нужно ещё принимать во внимание возможность рендерить лоуполи с любой стороны и анимировать скелетом в 3D. Скелеты в 2D сложнее, ограниченнее, выглядят неестественно и поэтому проигрывают 3D. Поэтому, возможно, вложиться в 3D лоуполи лучше.
>Если от первого или третьего лица - не факт
Нормально всё, видел достаточно таких игр.
>>3177
Что?
Игра грю хорошая вышла на годоте, можете опускать юнити и анрило чмонек, когда они вас подъябывают, что на годоте игор нет
Что?
Игра грю хорошая вышла на годоте, можете опускать юнити и анрило чмонек, когда они вас подъябывают, что на годоте игор нет
>>3178
>>3177
https://store.steampowered.com/curator/41324400-Is-it-made-with-Godot/#browse
Открываете top sellers и наслаждаетесь. Для меня было неожиданностью что даже вебфишинг, который из каждого утюга лезет, на годоте оказался.
>>3177
https://store.steampowered.com/curator/41324400-Is-it-made-with-Godot/#browse
Открываете top sellers и наслаждаетесь. Для меня было неожиданностью что даже вебфишинг, который из каждого утюга лезет, на годоте оказался.
>>3240
Стимдб не всегда детектит движок. Многих популярных игр из списка куратора тут нет. Но как дополнительный список неплох.
Стимдб не всегда детектит движок. Многих популярных игр из списка куратора тут нет. Но как дополнительный список неплох.
>>3268
Ты чо, одна из самых популярных игр на годоте.
Ты чо, одна из самых популярных игр на годоте.
>>3268
Не позволяй графическому стилю обмануть тебя, это один из лучших иммерсив симов современности
Не позволяй графическому стилю обмануть тебя, это один из лучших иммерсив симов современности
Планирую вкатиться. Ставить версию из стима или качать на сайте, где лучше взять годот?
>>3268
Это уровень Ван Гога. Многие просто не считают его художником, тем не менее сейчас он стоит бешеных денег.
Это уровень Ван Гога. Многие просто не считают его художником, тем не менее сейчас он стоит бешеных денег.
>>3301
С сайта. Стим обновит ее невовремя, да и еще там что-то по другому, не помню, установки C# шаблонов нет что ли.
С сайта. Стим обновит ее невовремя, да и еще там что-то по другому, не помню, установки C# шаблонов нет что ли.
997 Кб, 1024x1024>>3301
Не нужно загружать версию из Стима. Как и в случае с Блендером, это привнесет больше проблем. Загружай с сайта последнюю стабильную версию - 4.3. Совсем скоро выйдет 4.4, сможешь легко на него перейти. Из основных изменений - появится UID система для ассетов, подобная Unity
У Годота две версии - с поддержкой C# и без. Если делаешь что-нибудь серьезное, то Шарп нужен. Но для большинства простеньких игр можно и на gdscript, он похож на Питон, и очень легко осваивается
Не нужно загружать версию из Стима. Как и в случае с Блендером, это привнесет больше проблем. Загружай с сайта последнюю стабильную версию - 4.3. Совсем скоро выйдет 4.4, сможешь легко на него перейти. Из основных изменений - появится UID система для ассетов, подобная Unity
У Годота две версии - с поддержкой C# и без. Если делаешь что-нибудь серьезное, то Шарп нужен. Но для большинства простеньких игр можно и на gdscript, он похож на Питон, и очень легко осваивается
>>3304
Так говорят сишарп нинужон, прогать гдскрипте же? Кстати, иде для написания кода в комплекте идет?
Так говорят сишарп нинужон, прогать гдскрипте же? Кстати, иде для написания кода в комплекте идет?
>>3314
Сишарп не нужен, я просто к тому что в стим версию сложнее что то доустанавливать.
ИДЕ для гдскрипта в комплекте.
Ах да, самое важное - под что делать игры, от этого зависит выбор версии.
Я попробовал 4-ку, и ВСЕ ЕЩЕ считаю что для веба и мобилок лучше оставаться на 3, ДАЖЕ при том что там меньше аддонов и надо js-либу под звук. 4-ка это чисто под проект мечты на пека-консоли с АА+ графоном.
Сишарп не нужен, я просто к тому что в стим версию сложнее что то доустанавливать.
ИДЕ для гдскрипта в комплекте.
Ах да, самое важное - под что делать игры, от этого зависит выбор версии.
Я попробовал 4-ку, и ВСЕ ЕЩЕ считаю что для веба и мобилок лучше оставаться на 3, ДАЖЕ при том что там меньше аддонов и надо js-либу под звук. 4-ка это чисто под проект мечты на пека-консоли с АА+ графоном.
>>3319
В течение месяца-двух, скорее всего. Уже beta3 билд, потом будут rc билды - release candidate. И потом уже релиз, когда все будет протестировано. Можно бету уже сейчас использовать, но новичку не стоит
В течение месяца-двух, скорее всего. Уже beta3 билд, потом будут rc билды - release candidate. И потом уже релиз, когда все будет протестировано. Можно бету уже сейчас использовать, но новичку не стоит
>>3319
Скоро, он же сказал.
Скоро, он же сказал.
>>3313
Не согласен.
Если делаешь что- нибудь серьёзное, нужно писать компилируемый модуль на с++, всё остальное прекрасно покрывается гдскриптом. Шарп туда завезли для утят, чтоб не крякали. Шарп по сути такой же модуль на крестах с подключённым дотнет-рантаймом. А если нет разницы, зачем тащить дотнет туда, где достаточно чистого си?
Нет, не согласен.
> Если делаешь что-нибудь серьезное, то Шарп нужен.
Не согласен.
Если делаешь что- нибудь серьёзное, нужно писать компилируемый модуль на с++, всё остальное прекрасно покрывается гдскриптом. Шарп туда завезли для утят, чтоб не крякали. Шарп по сути такой же модуль на крестах с подключённым дотнет-рантаймом. А если нет разницы, зачем тащить дотнет туда, где достаточно чистого си?
Нет, не согласен.
>>3323
Фирма наконец сделала официальный менеджер пакетов для венды. Ладно, забей, подрастёшь узнаешь.
Фирма наконец сделала официальный менеджер пакетов для венды. Ладно, забей, подрастёшь узнаешь.
>>3328
Алсо, за день перенес проект с 4 на 3. Закинул модельки, вручную пересобрал сцены, заменил контроллеры-аддоны-шейдеры на аналоги.
Алсо, за день перенес проект с 4 на 3. Закинул модельки, вручную пересобрал сцены, заменил контроллеры-аддоны-шейдеры на аналоги.
>>3334
Два чаю.
Два чаю.
>>3334
Если речь про трудновычислимые задачи, тяжелую математику, огромные генерации - да, так и есть
В gdscript даже нет интерфейсов. Как и IDE с отладкой. При работе над масштабируемыми проектами - это необходимость
Нездоровый максимализм. Исходя из твоей логики, почему бы не использовать love2d, Defold на .lua? Зачем Годот и gdscript? Это еще проще, а модули на C/C++ можно написать тем, кому это необходимо
Любому, кто работал с по-настоящему большими проектами, должно быть очевидно, что C# -> gdscript. С таким мнением и останусь, а ты можешь остаться со своим. Не будем срамить наш прилежный тред
> Если делаешь что- нибудь серьёзное, нужно писать компилируемый модуль на с++
Если речь про трудновычислимые задачи, тяжелую математику, огромные генерации - да, так и есть
> всё остальное прекрасно покрывается гдскриптом
В gdscript даже нет интерфейсов. Как и IDE с отладкой. При работе над масштабируемыми проектами - это необходимость
> Шарп туда завезли для утят, чтоб не крякали
> А если нет разницы, зачем тащить дотнет туда, где достаточно чистого си?
Нездоровый максимализм. Исходя из твоей логики, почему бы не использовать love2d, Defold на .lua? Зачем Годот и gdscript? Это еще проще, а модули на C/C++ можно написать тем, кому это необходимо
Любому, кто работал с по-настоящему большими проектами, должно быть очевидно, что C# -> gdscript. С таким мнением и останусь, а ты можешь остаться со своим. Не будем срамить наш прилежный тред
>>3343
Можешь объяснить и расписать когда и зачем они тебе в последний раз понадобились в годоте?
>нет интерфейсов
Можешь объяснить и расписать когда и зачем они тебе в последний раз понадобились в годоте?
1,1 Мб, 1024x1024>>3367
Пожалуйста. Тебя никто не заставляет пользоваться тем, что тебе не нужно. В треде высказались, почему Шарп использовать нецелесообразно, я высказался почему целесообразно. Каждому следует решить самостоятельно, исходя из своих запросов и проекта, над которым ведется работа
>>3371
Очевидный, возможно, до неприличия академический пример интерфейса. Работаю над 2D top-down RPG, в игровом мире множество интерактивных объектов, которые могут получать урон: персонажи, предметы персонажей (которые или на них надеты, или лежат в инвентаре, или выброшены на землю), динамические объекты окружения (деревья, двери, различные контейнеры, в которых находятся предметы), динамическое окружение, привязанное к тайлам (лед, заросли, магические барьеры) и много что еще. Все из перечисленного может получать урон. Единожды реализовав интерфейс ITakeDamage (и метод TakeDamage), имплементировав его в необходимых классах, я добьюсь единообразной реализации данной механики для всех упомянутых объектов. При необходимости можно переопределить TakeDamage в любом из классов. Это очень гибкая структура для системного подхода. Теперь, когда персонаж замахивается мечом, я могу просто считывать все объекты, которые встречаются по траектории удара и наносить им урон. По аналогии у меня реализованы лечение/починка и перемещение любых динамических объектов. Это стандартная практика в играх
Интерфейсы - классическое понятие в программировании и куда глубже того, что я описал. Это лишь частный наглядный пример
> Абсолютно не убедительно. Остаюсь при своём.
Пожалуйста. Тебя никто не заставляет пользоваться тем, что тебе не нужно. В треде высказались, почему Шарп использовать нецелесообразно, я высказался почему целесообразно. Каждому следует решить самостоятельно, исходя из своих запросов и проекта, над которым ведется работа
>>3371
Очевидный, возможно, до неприличия академический пример интерфейса. Работаю над 2D top-down RPG, в игровом мире множество интерактивных объектов, которые могут получать урон: персонажи, предметы персонажей (которые или на них надеты, или лежат в инвентаре, или выброшены на землю), динамические объекты окружения (деревья, двери, различные контейнеры, в которых находятся предметы), динамическое окружение, привязанное к тайлам (лед, заросли, магические барьеры) и много что еще. Все из перечисленного может получать урон. Единожды реализовав интерфейс ITakeDamage (и метод TakeDamage), имплементировав его в необходимых классах, я добьюсь единообразной реализации данной механики для всех упомянутых объектов. При необходимости можно переопределить TakeDamage в любом из классов. Это очень гибкая структура для системного подхода. Теперь, когда персонаж замахивается мечом, я могу просто считывать все объекты, которые встречаются по траектории удара и наносить им урон. По аналогии у меня реализованы лечение/починка и перемещение любых динамических объектов. Это стандартная практика в играх
Интерфейсы - классическое понятие в программировании и куда глубже того, что я описал. Это лишь частный наглядный пример
>>3404
https://www.youtube.com/watch?v=74y6zWZfQKk
>множество интерактивных объектов, которые могут получать урон
https://www.youtube.com/watch?v=74y6zWZfQKk
>>3404
Интерфейс зачем для этого? TakeDamage() просто в каждом классе делай и все. Такое чувство, без наезда, просто так показалось, что ты сам особо не понимаешь зачем нужны интерфейсы, ну вот, типо, делают их и я делать буду. А надо или не надо это уже не мое дело, бест практикс
Интерфейс зачем для этого? TakeDamage() просто в каждом классе делай и все. Такое чувство, без наезда, просто так показалось, что ты сам особо не понимаешь зачем нужны интерфейсы, ну вот, типо, делают их и я делать буду. А надо или не надо это уже не мое дело, бест практикс
>>3419
Вернее в каждом классе, где тебе он какой то измененный этот метод нужен, а так по дереву наследования у самого родителя реализовал и все
Вернее в каждом классе, где тебе он какой то измененный этот метод нужен, а так по дереву наследования у самого родителя реализовал и все
Хуя тут кто-то потроллить залетел. Качать стимами-вингетами один-единственный экзешник. Интерфейсы, модули, компиляции, плюсы, огромные генерации, масштабирование. Вообще охуеть. Флаппи берд сделайте.
>>3419
Интерфейс и композиция - разные понятия и нужны в разных ситуациях. Ничего не мешает использовать их совместно. В больших проектах, чаще всего, они так и используются. И мой не исключение. Я же нигде не утверждал, что игнорирую композицию и другие практики. Но и интерфейсы использую. Меня попросили дать пример - я дал пример. Хватит видеть в этом красную тряпку и пытаться выяснить, какой подход лучше и кто прав, а кто нет
Интерфейс и композиция - разные понятия и нужны в разных ситуациях. Ничего не мешает использовать их совместно. В больших проектах, чаще всего, они так и используются. И мой не исключение. Я же нигде не утверждал, что игнорирую композицию и другие практики. Но и интерфейсы использую. Меня попросили дать пример - я дал пример. Хватит видеть в этом красную тряпку и пытаться выяснить, какой подход лучше и кто прав, а кто нет
>>3313
Если привык к шарпу, то шарп нужен. В остальном - только лишняя ёбля с зависимостью, увеличение размера билда и лишняя зависимость.
Сто раз говорили, что из похожести там - разве что отступы. Нет же, обязательно найдётся умник, не знающий оба языка одновременно, но задвигающий, что они похожи.
В гдскрипте больше от луа, чем от питона так-то.
>Если делаешь что-нибудь серьезное, то Шарп нужен
Если привык к шарпу, то шарп нужен. В остальном - только лишняя ёбля с зависимостью, увеличение размера билда и лишняя зависимость.
>gdscript, он похож на Питон
Сто раз говорили, что из похожести там - разве что отступы. Нет же, обязательно найдётся умник, не знающий оба языка одновременно, но задвигающий, что они похожи.
В гдскрипте больше от луа, чем от питона так-то.
>>3343
Что. За. Хуйню. Ты. Несешь?
https://docs.godotengine.org/en/stable/tutorials/scripting/debug/overview_of_debugging_tools.html
Брейкпоинты, вкладка дебаггер показывает стек вызовов, локальные, глобальные переменные, содержимое объектов.
Вкладка Remote. Показывает все дерево сцены.
Десятки аддонов на любой чих - позволяющие рисовать стрелочки-векторы и любые данные, консоли.
В принципе это и не особо нужно потому что учитывая легкость годота, это прямо на лету добавляется - кидаешь Label и пишешь в нее, прикрепляешь ноду со стрелкой и поворачиваешь как надо. Пиздец.
В 4-ке добавили expression evaluator, в 3-ке вроде нет, или был плагин похожий.
Что такого надо нахуевеврить чтобы таких возможностей отладчика не хватало? Я не представляю. Или это какой то особый вид Debugger-Driven Development? Написать дичь а потом смотреть что в переменных оказалось? Так лучше головой сначала думать.
>Гдскрипт нет IDE с отладкой
Что. За. Хуйню. Ты. Несешь?
https://docs.godotengine.org/en/stable/tutorials/scripting/debug/overview_of_debugging_tools.html
Брейкпоинты, вкладка дебаггер показывает стек вызовов, локальные, глобальные переменные, содержимое объектов.
Вкладка Remote. Показывает все дерево сцены.
Десятки аддонов на любой чих - позволяющие рисовать стрелочки-векторы и любые данные, консоли.
В принципе это и не особо нужно потому что учитывая легкость годота, это прямо на лету добавляется - кидаешь Label и пишешь в нее, прикрепляешь ноду со стрелкой и поворачиваешь как надо. Пиздец.
В 4-ке добавили expression evaluator, в 3-ке вроде нет, или был плагин похожий.
Что такого надо нахуевеврить чтобы таких возможностей отладчика не хватало? Я не представляю. Или это какой то особый вид Debugger-Driven Development? Написать дичь а потом смотреть что в переменных оказалось? Так лучше головой сначала думать.
>>3497
Вопрос дискуссионный. Буквально в документации сравнивают gdscript с Python: https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/gdscript_basics.html
В lua даже опционально статической типизации нет. Все скриптовые языки схожи.
Энивей, вот же делать тебе нехуй, кроме как до такой мелочи доёбываться. Лучше бы игрой своей занимался, чем пукал в пустоту.
> Сто раз говорили, что из похожести там - разве что отступы
Вопрос дискуссионный. Буквально в документации сравнивают gdscript с Python: https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/gdscript_basics.html
В lua даже опционально статической типизации нет. Все скриптовые языки схожи.
Энивей, вот же делать тебе нехуй, кроме как до такой мелочи доёбываться. Лучше бы игрой своей занимался, чем пукал в пустоту.
>>3497
Естветсвенно они похожи. Нет, не только отступы, но и основными конструкций. Например for i in range(10): и прочее. match x: case 5: pass. Только тролль будет говорить что они непохожи, когда у них большинство основных конструкций общие.
Конечно есть фичи которые есть только в питоне (как распаковка a,b = func() ) и есть фичи только гдскрипта как сигналы. Но это уже то что навернуто поверх основы.
Естветсвенно они похожи. Нет, не только отступы, но и основными конструкций. Например for i in range(10): и прочее. match x: case 5: pass. Только тролль будет говорить что они непохожи, когда у них большинство основных конструкций общие.
Конечно есть фичи которые есть только в питоне (как распаковка a,b = func() ) и есть фичи только гдскрипта как сигналы. Но это уже то что навернуто поверх основы.
>>3483
Традиция такая. Дать новичку удочку, чтобы с рыбой он разобрался сам.
Традиция такая. Дать новичку удочку, чтобы с рыбой он разобрался сам.
> winget install godotengine.godotengine
>>3498
Тебе гдскрипт удалили и уже Visual Studio накатывают или откуда столько желчи? Спок.
Тебе гдскрипт удалили и уже Visual Studio накатывают или откуда столько желчи? Спок.
>>3404
Освободи свой разум. Тебе нужна концепция интерфейса, а не реализация интерфейса из C#. Он там нужен потому, что C# компилируемый язык и все должно быть объявлено заранее и нет динамической утиной типизации.
https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/gdscript_advanced.html#duck-typing
В гдскрипте проверка на интерфейс была бы что то вроде obj.has_method("TakeDamage")
Или можно какой нибудь линтер сделать, когда ты пишешь var Interfaces="IDamageable, IWalkable" и он плагин пройдется по скриптам и проверит наличие нужных функций, причем это можно не использовать в релизе.
А про компоненты писали в прошлом треде, ведь твой интерфейс нужно вписывать в какой то класс, значит ты на каждого врага пишешь новый класс и даешь ему имя, даже если у них одинаковое поведение, а на компонентах этого не нужно, поведение описано в компонентах (и системах их обрабатывающих) а само наличие компонент и определяет итоговое поведение юнита, просто у этого класса не будет имени, будет сущность которая получает урон и ходит (может быть стражник, может собака)
Освободи свой разум. Тебе нужна концепция интерфейса, а не реализация интерфейса из C#. Он там нужен потому, что C# компилируемый язык и все должно быть объявлено заранее и нет динамической утиной типизации.
https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/gdscript_advanced.html#duck-typing
В гдскрипте проверка на интерфейс была бы что то вроде obj.has_method("TakeDamage")
Или можно какой нибудь линтер сделать, когда ты пишешь var Interfaces="IDamageable, IWalkable" и он плагин пройдется по скриптам и проверит наличие нужных функций, причем это можно не использовать в релизе.
А про компоненты писали в прошлом треде, ведь твой интерфейс нужно вписывать в какой то класс, значит ты на каждого врага пишешь новый класс и даешь ему имя, даже если у них одинаковое поведение, а на компонентах этого не нужно, поведение описано в компонентах (и системах их обрабатывающих) а само наличие компонент и определяет итоговое поведение юнита, просто у этого класса не будет имени, будет сущность которая получает урон и ходит (может быть стражник, может собака)
>>3507
По существу ответ будет, чего именно "нет" в дебаггере? Не люблю голословных пиздаболов просто.
По существу ответ будет, чего именно "нет" в дебаггере? Не люблю голословных пиздаболов просто.
>>3501
Лежу с температурой, пытаюсь персонажа рисовать. Художник из меня херовый, немножко порисую - и лезу на двач сраться.
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).
Ух вот же ж сравнили так сравнили! Прямо лоб в лоб.
>Лучше бы игрой своей занимался
Лежу с температурой, пытаюсь персонажа рисовать. Художник из меня херовый, немножко порисую - и лезу на двач сраться.
>в документации сравнивают
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).
Ух вот же ж сравнили так сравнили! Прямо лоб в лоб.
>>3516
Желаю поскорее выздороветь. Сраться необязательно. Твою позицию услышали, она имеет право на жизнь, ровно как и отличная от твоей. Ничего ужасного здесь не написали, просто два разных подхода к одной проблеме, и оба правильные
> Лежу с температурой, пытаюсь персонажа рисовать. Художник из меня херовый, немножко порисую - и лезу на двач сраться.
Желаю поскорее выздороветь. Сраться необязательно. Твою позицию услышали, она имеет право на жизнь, ровно как и отличная от твоей. Ничего ужасного здесь не написали, просто два разных подхода к одной проблеме, и оба правильные
>>3515
Нормаально так.
Нормаально так.
>>3551
>>3539
У меня просто установлено через scoop, и пара версий через godot manager https://github.com/eumario/godot-manager/releases
Но я бы не стал новичку советовать эти два варика. Там подводных много.
>>3539
У меня просто установлено через scoop, и пара версий через godot manager https://github.com/eumario/godot-manager/releases
Но я бы не стал новичку советовать эти два варика. Там подводных много.
>>3404
Мне кажется, получение урона - плохой пример:
Должен красочно упасть на землю в лужу крови и превратиться в "контейнер" или разбросать лут.
Должны заменить себя на "мусор", либо исчезнуть, освободив ячейку инвентаря или экипировки.
Сильно зависит от типа объекта:
Оставляют пень и разбрасывают лут (брёвна), либо заменяются сгоревшей версией, дропающей уголь. Возможно, просто исчезают, если лут не нужен...
Заменяются сломанной версией или исчезают.
Исчезают, разбрасывая вокруг себя предметы. Или превращают предметы в мусор, затем выбрасывают.
Здесь ты обращаешься к тайлмапе, а не к отдельным тайлам, и уже тайлмапа определяет, что ей делать.
>>3447
А что, если ты хочешь реализовать неуязвимость? Получается, нужно делать проверку if not immortal. Компонентный подход позволяет просто удалить обработчик урона и ВНЕЗАПНО персонаж перестает получать урон. С интерфейсами в ООП так нельзя:
Т.е. композиция более гибкая, чем интерфейсы.
Далее ты можешь реализовать, например:
И они все будут взаимозаменяемы.
Мне кажется, получение урона - плохой пример:
>персонажи
Должен красочно упасть на землю в лужу крови и превратиться в "контейнер" или разбросать лут.
>предметы персонажей (которые или на них надеты, или лежат в инвентаре, или выброшены на землю)
Должны заменить себя на "мусор", либо исчезнуть, освободив ячейку инвентаря или экипировки.
>динамические объекты окружения
Сильно зависит от типа объекта:
>деревья
Оставляют пень и разбрасывают лут (брёвна), либо заменяются сгоревшей версией, дропающей уголь. Возможно, просто исчезают, если лут не нужен...
>двери
Заменяются сломанной версией или исчезают.
>различные контейнеры, в которых предметы
Исчезают, разбрасывая вокруг себя предметы. Или превращают предметы в мусор, затем выбрасывают.
>динамическое окружение, привязанное к тайлам (лед, заросли, магические барьеры)
Здесь ты обращаешься к тайлмапе, а не к отдельным тайлам, и уже тайлмапа определяет, что ей делать.
>>3447
>Интерфейс и композиция - разные понятия
А что, если ты хочешь реализовать неуязвимость? Получается, нужно делать проверку 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
И они все будут взаимозаменяемы.
>>3404
Мне кажется, получение урона - плохой пример:
Должен красочно упасть на землю в лужу крови и превратиться в "контейнер" или разбросать лут.
Должны заменить себя на "мусор", либо исчезнуть, освободив ячейку инвентаря или экипировки.
Сильно зависит от типа объекта:
Оставляют пень и разбрасывают лут (брёвна), либо заменяются сгоревшей версией, дропающей уголь. Возможно, просто исчезают, если лут не нужен...
Заменяются сломанной версией или исчезают.
Исчезают, разбрасывая вокруг себя предметы. Или превращают предметы в мусор, затем выбрасывают.
Здесь ты обращаешься к тайлмапе, а не к отдельным тайлам, и уже тайлмапа определяет, что ей делать.
>>3447
А что, если ты хочешь реализовать неуязвимость? Получается, нужно делать проверку if not immortal. Компонентный подход позволяет просто удалить обработчик урона и ВНЕЗАПНО персонаж перестает получать урон. С интерфейсами в ООП так нельзя:
Т.е. композиция более гибкая, чем интерфейсы.
Далее ты можешь реализовать, например:
И они все будут взаимозаменяемы.
Мне кажется, получение урона - плохой пример:
>персонажи
Должен красочно упасть на землю в лужу крови и превратиться в "контейнер" или разбросать лут.
>предметы персонажей (которые или на них надеты, или лежат в инвентаре, или выброшены на землю)
Должны заменить себя на "мусор", либо исчезнуть, освободив ячейку инвентаря или экипировки.
>динамические объекты окружения
Сильно зависит от типа объекта:
>деревья
Оставляют пень и разбрасывают лут (брёвна), либо заменяются сгоревшей версией, дропающей уголь. Возможно, просто исчезают, если лут не нужен...
>двери
Заменяются сломанной версией или исчезают.
>различные контейнеры, в которых предметы
Исчезают, разбрасывая вокруг себя предметы. Или превращают предметы в мусор, затем выбрасывают.
>динамическое окружение, привязанное к тайлам (лед, заросли, магические барьеры)
Здесь ты обращаешься к тайлмапе, а не к отдельным тайлам, и уже тайлмапа определяет, что ей делать.
>>3447
>Интерфейс и композиция - разные понятия
А что, если ты хочешь реализовать неуязвимость? Получается, нужно делать проверку 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
И они все будут взаимозаменяемы.
После того как познакомился с компонентными моделями, возврата к наследованию просто нет.
А после того как познакомился с типаж-ориентированным ООП - нет возврата уже к класс-ориентированному ООП.
Представьте себе, типажи + компоненты на структурах. Но в годоте такое будет не скоро.
А после того как познакомился с типаж-ориентированным ООП - нет возврата уже к класс-ориентированному ООП.
Представьте себе, типажи + компоненты на структурах. Но в годоте такое будет не скоро.
>>3633
Хотели трейты сделать же. Кто-то из знающих людей что-то говорил про УЖЕ ВОТ-ВОТ после 4.4, нужно только потерпеть
Хотели трейты сделать же. Кто-то из знающих людей что-то говорил про УЖЕ ВОТ-ВОТ после 4.4, нужно только потерпеть
>>3633
Насследование удобнее компонентов в прототипах. В большинстве случаев дробление кода на 100500 независимых компонентов только вредит проекту.
Я как-то попытался разделить контроллер на 4~5 компонентов-состояний конечного автомата, но не получилось восстановить исходное поведение, а перемещаться между 5 скриптами сложно. Так что выбросил компоненты-состояния - пока не нужно расширять контроллер (в текущем прототипе).
Сейчас мне нужно одну систему с нуля практически переделывать из-за того, что мне приходится менять несколько отдельных скриптов ради одной мелочи...
Как это вообще гуглить по-английски?
Я знаю, что есть альтернативы классовому ООП, но, насколько мне известно, эти альтернативы устарели и больше не используются (аналогично старым ЯП). Например, видел ООП в языке Ada - неудобно...
Избыточное ограничение. Методы Dictionary бывают чрезвычайно полезны; от "структур" никакой пользы. Внутреннее устройство тебя волновать не должно...
Мне кажется, ты просто озабочен преждевременной оптимизацией. Тогда просто пиши игру с нуля на C...
>возврата к наследованию
Насследование удобнее компонентов в прототипах. В большинстве случаев дробление кода на 100500 независимых компонентов только вредит проекту.
Я как-то попытался разделить контроллер на 4~5 компонентов-состояний конечного автомата, но не получилось восстановить исходное поведение, а перемещаться между 5 скриптами сложно. Так что выбросил компоненты-состояния - пока не нужно расширять контроллер (в текущем прототипе).
Сейчас мне нужно одну систему с нуля практически переделывать из-за того, что мне приходится менять несколько отдельных скриптов ради одной мелочи...
>типаж
Как это вообще гуглить по-английски?
Я знаю, что есть альтернативы классовому ООП, но, насколько мне известно, эти альтернативы устарели и больше не используются (аналогично старым ЯП). Например, видел ООП в языке Ada - неудобно...
>на структурах
Избыточное ограничение. Методы Dictionary бывают чрезвычайно полезны; от "структур" никакой пользы. Внутреннее устройство тебя волновать не должно...
Мне кажется, ты просто озабочен преждевременной оптимизацией. Тогда просто пиши игру с нуля на C...
>>3650
Так это одно и то же практически:
Как это ведёт к полной бесклассовости в ООП?
Мне казалось, ты имеешь в виду отказ от обычных ключевых слов типа "class", а также понятия "метод", которые приняты в типичном классовом ООП.
>>3648
Мне кажется, он имеет в виду это:
https://github.com/godotengine/godot-proposals/issues/6416
>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", а также понятия "метод", которые приняты в типичном классовом ООП.
>>3648
Мне кажется, он имеет в виду это:
https://github.com/godotengine/godot-proposals/issues/6416
>>3657
Так там же написано. Ты уверен, что знаешь английский?
Да, я именно это имею ввиду.
Там какой-то дурачок намешал в кучу всё подряд.
В типажовом ООП сущности не extends а implements. Щас накатаю приблизительный псевдокод.
> Как это ведёт к полной бесклассовости в ООП?
Так там же написано. Ты уверен, что знаешь английский?
> 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. Щас накатаю приблизительный псевдокод.
>>3666
Что-то типа JavaScript?
В JavaScript ты можешь в любой момент добавить совершенно новое поле и метод к любому объекту. Практически то же самое, что Dictionary. Хм... Вроде возможно и в GDScript провернуть через Callable?..
В любом случае, это не избавляет от классов. Ты объявляешь класс, который включает в себя набор характеристик (traits). А уже потом создаёшь новый экземпляр класса. Ты можешь, конечно, добавлять характеристики в рантайме (как поля в Dictionary), отказавшись от создания новых классов, но в чём преимущество? По-моему, это только недостаток - невозможность объявлять классы до экземпляров.
Сначала придумали объекты, потом классы. Классы необходимы, чтобы создавать объекты по шаблону. Кажется, классы - просто улучшение системы типов.
Что-то типа JavaScript?
В JavaScript ты можешь в любой момент добавить совершенно новое поле и метод к любому объекту. Практически то же самое, что Dictionary. Хм... Вроде возможно и в GDScript провернуть через Callable?..
В любом случае, это не избавляет от классов. Ты объявляешь класс, который включает в себя набор характеристик (traits). А уже потом создаёшь новый экземпляр класса. Ты можешь, конечно, добавлять характеристики в рантайме (как поля в Dictionary), отказавшись от создания новых классов, но в чём преимущество? По-моему, это только недостаток - невозможность объявлять классы до экземпляров.
Сначала придумали объекты, потом классы. Классы необходимы, чтобы создавать объекты по шаблону. Кажется, классы - просто улучшение системы типов.
В C# уже давно (кажется, с версии 8.0) в интерфейсах можно полноценно имплементировать методы, это и есть трейты. >>3404 именно это и описывал, а вы даже не поняли.
Можно еще про partial class почитать. Но шарпыненужоны в пролете, конечно. Может через пару годиков вымолите у Хуана что-нибудь похожее.
Можно еще про partial class почитать. Но шарпыненужоны в пролете, конечно. Может через пару годиков вымолите у Хуана что-нибудь похожее.
>>3666
...придумал наглядный пример.
Вот у тебя есть код:
0 - это объект, а int - это класс (тип).
В бесклассовом языке у тебя только одно число - 0.
С классами можно записать в number любое число.
Так что отказываться от классов нерационально.
...придумал наглядный пример.
Вот у тебя есть код:
>var number: int = 0
0 - это объект, а int - это класс (тип).
В бесклассовом языке у тебя только одно число - 0.
С классами можно записать в number любое число.
Так что отказываться от классов нерационально.
>>3681
Вот, для примера, мой код: >>3615
С поддержкой GDScript можно было б сделать так:
Т.е. просто чтоб запись короче была, как я понял.
На счёт unimplement сомневаюсь, это возможно?
>зачем для этого какая то отдельная сущность
Вот, для примера, мой код: >>3615
>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 сомневаюсь, это возможно?
>>3703
Хорошо, смех продлевает жизнь. Игру сделаешь...
Хорошо, смех продлевает жизнь. Игру сделаешь...
123 Кб, 1280x958Сегодня мне стало интересно, как отлаживать мобильную веб-версию.
Ну так вот - надо на компе запустить хром, на мобилке включить опции разработчика и USB debugging, подключить кабелем, и вуаля, компьютерный хром показывает мобильный хром включая рендер с вкладки и консоль.
Ну так вот - надо на компе запустить хром, на мобилке включить опции разработчика и USB debugging, подключить кабелем, и вуаля, компьютерный хром показывает мобильный хром включая рендер с вкладки и консоль.
Я тут понял забавную вещь.
Те ассеты, которые каждый месяц раздавали в Анриле, сконвертнулись в Standard лицензию на fab.com. А она не запрещает их использование в других движках, лол.
(Нюансы с теми что делали сами эпики - они вроде дополнительно ограничивали лицензией; надо смотреть в других не ограничивал ли автор тоже; и второе - там какие то условия что нельзя делать на них редакторы/генераторы, результат которых потом пользователь сможет экспортировать. То есть в игре можно, а вот кастомный уровень которым игрок может поделиться - под вопросом.)
Вот тут так же товарищ считает - https://www.reddit.com/r/unrealengine/comments/1i7lq6w/fab_assets_in_godot/
Те ассеты, которые каждый месяц раздавали в Анриле, сконвертнулись в Standard лицензию на fab.com. А она не запрещает их использование в других движках, лол.
(Нюансы с теми что делали сами эпики - они вроде дополнительно ограничивали лицензией; надо смотреть в других не ограничивал ли автор тоже; и второе - там какие то условия что нельзя делать на них редакторы/генераторы, результат которых потом пользователь сможет экспортировать. То есть в игре можно, а вот кастомный уровень которым игрок может поделиться - под вопросом.)
Вот тут так же товарищ считает - https://www.reddit.com/r/unrealengine/comments/1i7lq6w/fab_assets_in_godot/
506 Кб, 1631x932>>3771
Ого, можно легально перелить терабайты этой хуйни в юнити и годот? Ну кроме той, которая про игровую логику. На ёбаных блюпринтах.
Ого, можно легально перелить терабайты этой хуйни в юнити и годот? Ну кроме той, которая про игровую логику. На ёбаных блюпринтах.
>>3767
Все так. А если у тебя не веб игра, то таким же образом на мобилке ремот дебаг запускается. На годоте оч удобная мобильная разработка.
Все так. А если у тебя не веб игра, то таким же образом на мобилке ремот дебаг запускается. На годоте оч удобная мобильная разработка.
>>3774
Ну вот на первый взгляд да. Я не юрист конечно. Вот тут например пишут
https://forums.unrealengine.com/t/megascans-license/2081542
Что даже Quixel полученный через анрил (не через их сайт), который раньше был под UE-only лицензией, если сейчас перескачать, то он пойдет под Standard FAB лицензией.
Есть неоднозначности например про модельки из Paragon, потому что раньше они прямо говорили что это только для UE. Но сейчас то там тоже Standard Fab. Я бы на всякий случай не трогал эпиковское.
Еще пишут что в лицензии ограничение на доход в $100.000, но так же пишут что это распространяется на момент "забирания" бесплатного ассета, то есть если забрал когда был ньюфагом, а потом разбогател, то вроде как не появляется ретроактивно обязанность платить роялти.
Ну вот на первый взгляд да. Я не юрист конечно. Вот тут например пишут
https://forums.unrealengine.com/t/megascans-license/2081542
Что даже Quixel полученный через анрил (не через их сайт), который раньше был под UE-only лицензией, если сейчас перескачать, то он пойдет под Standard FAB лицензией.
Есть неоднозначности например про модельки из Paragon, потому что раньше они прямо говорили что это только для UE. Но сейчас то там тоже Standard Fab. Я бы на всякий случай не трогал эпиковское.
Еще пишут что в лицензии ограничение на доход в $100.000, но так же пишут что это распространяется на момент "забирания" бесплатного ассета, то есть если забрал когда был ньюфагом, а потом разбогател, то вроде как не появляется ретроактивно обязанность платить роялти.
Очень долго думал о игре, которую хочу и могу сделать. Параллельно осваивал движок и арт. Чуть больше полугода проработал в таком режиме, наконец-то придумал подходящую концепцию игры. Продуктивность и креатив бьют ключом, движок и арт освоил на приемлемом уровне, доволен своим прогрессом как никогда прежде. Наконец-то собрал proof of concept прототип... и он развалился. Выявил слабую сторону проекта, проблема фундаментальная и неразрешимая, потому что, можно сказать, лежит в его определении. И вот я здесь, сижу с пустотой в груди и думаю, что делать дальше и делать ли вообще. Горькое чувство поражения...
Люди любят истории успеха. Приводят в пример, скажем, разработчика Stardew Valley и остальных, кому удалось сделать свою игру и сразу же найти для нее аудиторию. А я смотрю на их игры, да и игры других разработчиков, и думаю: неужели они до этого не тратили месяцы или даже годы на то, что в итоге не претворилось в жизнь? Просто, чтобы понять, что это не работает и никому не нужно. Жаль, что никто не любит рассказывать такие истории, да и слушать их мало кому интересно
>>4081
На реддите полно post mortem разборов. От себя добавлю такое: почти все игры, за разработкой которых я следил, смотрел девлоги и думал "ого, этот чувак очень крут, офигенная идея и реализация, мне не сравниться" - почти все они спустя год после релизов имеют <50 ревью в стиме. Я считаю это провалом.
Авторы стардью валлей, андертейлов и вебфишингов выиграли лотерею. Чего там, обычная лотерея разумней чем геймдев-с-мечтой-взлететь, ведь лотерея не требует от тебя 2-3 года нонстоп въебывания за пекой.
На реддите полно post mortem разборов. От себя добавлю такое: почти все игры, за разработкой которых я следил, смотрел девлоги и думал "ого, этот чувак очень крут, офигенная идея и реализация, мне не сравниться" - почти все они спустя год после релизов имеют <50 ревью в стиме. Я считаю это провалом.
Авторы стардью валлей, андертейлов и вебфишингов выиграли лотерею. Чего там, обычная лотерея разумней чем геймдев-с-мечтой-взлететь, ведь лотерея не требует от тебя 2-3 года нонстоп въебывания за пекой.
>>4100
На реддите не сижу, потому не знал. Спасибо, что поделился (и своими наблюдениями тоже)
Историй успеха там по-прежнему больше, или они просто в топе благодаря лайкам, но все равно много любопытного материала для чтения. Буду проверять иногда
>>4102
Спасибо тебе, но решение одно - придумать новую концепцию. Проблема в том, что я осознанно отказался от важной механики, которую ожидают увидеть в каждой игре жанра. Мне казалось, ее можно заменить другими механиками. Но это не сработало, некоторые жанры просто по определению должны иметь определенные наборы механик, иначе сломают весь игровой цикл
>>4105
Исходники может прислать? Чтобы наверняка
Энивей, моя история - еще одно напоминание, что нужно не забывать показывать свои задумки другим людям. Все, кто поиграли в мой прототип (13 человек), указали на одну и ту же проблему. Да и я сам о ней догадался, когда собрал механики воедино. По отдельности механики могут быть прекрасными, а в сумме - не работать
На реддите не сижу, потому не знал. Спасибо, что поделился (и своими наблюдениями тоже)
Историй успеха там по-прежнему больше, или они просто в топе благодаря лайкам, но все равно много любопытного материала для чтения. Буду проверять иногда
>>4102
Спасибо тебе, но решение одно - придумать новую концепцию. Проблема в том, что я осознанно отказался от важной механики, которую ожидают увидеть в каждой игре жанра. Мне казалось, ее можно заменить другими механиками. Но это не сработало, некоторые жанры просто по определению должны иметь определенные наборы механик, иначе сломают весь игровой цикл
>>4105
Исходники может прислать? Чтобы наверняка
Энивей, моя история - еще одно напоминание, что нужно не забывать показывать свои задумки другим людям. Все, кто поиграли в мой прототип (13 человек), указали на одну и ту же проблему. Да и я сам о ней догадался, когда собрал механики воедино. По отдельности механики могут быть прекрасными, а в сумме - не работать
>>4116
Да да, конечно, и скринов не осталось, и бэкапов, и набросков, и файлы не восстановить.
Короче очевидный вброс.
Да да, конечно, и скринов не осталось, и бэкапов, и набросков, и файлы не восстановить.
Короче очевидный вброс.
7,9 Мб, mp4,256x144, 12:14
>>4081
Вот видео на эту тему, поясняет суть работы:
https://youtube.com/watch?v=kMDe7_YwVKI
Главное: «fail faster, follow the fun».
1. Делай прототип как можно скорее.
2. Прототип не фановый? Изменяй его.
3.а. Чуешь фан? Фокусируйся на фане.
3.б. Совсем ничего не выходит? Бросай.
4. Повторяешь с пункта 1 до успеха.
Планировать ВСЁ заранее - рецепт провала.
>>4074
Ты попал в ловушку избыточного планирования.
Что тебя максимально привлекает в твоей игре?
Сфокусируйся на том, что тебя в ней привлекает.
>>4103
Это тред годотеров. Тёплый, ламповый, твой.
Алсо, он точно на Godot работал, я видел видео.
>>4116
А в чём там проблема-то? Норм концепция.
Ну и дурак. Я все свои неудачи сохраняю.
Впрочем, не страшно, это же только прототип.
>>4124
У тебя ж главная механика - копание в Толще, не?
Поиграй в аналогичные игры, их уже несколько...
Такого не бывает. Цикл либо есть, либо его нет.
Игровой цикл Толщеходов (как я его помню):
1. Закапываемся в Толщу.
2. Ищем цель - полость в Толще.
3. Пробиваемся к ней на толщеходе:
- уворачиваемся от уплотнений,
- торпедируем противников.
Всё это с помощью радара.
4. В полости (планета наоборот):
- выполняем квесты (сюжет?),
- ремонтируем толщеход,
- заправляемся и т.д.
5. Повторяем цикл с самого начала.
По сути это поводная лодка, только подземная.
Какую проблему-то? И почему не исправил?
Я лично не вижу проблем в этом концепте.
Бред. Фановые механики фановы всегда и везде.
>>4134
Не трогай его, он наш шиз - местный олдфаг.
Сожалею ему, мне нравился концепт его игры.
Вряд ли кто-то другой вспоминает толщеходы...
>тратили месяцы или даже годы
>Жаль, что никто не любит рассказывать
Вот видео на эту тему, поясняет суть работы:
https://youtube.com/watch?v=kMDe7_YwVKI
Главное: «fail faster, follow the fun».
1. Делай прототип как можно скорее.
2. Прототип не фановый? Изменяй его.
3.а. Чуешь фан? Фокусируйся на фане.
3.б. Совсем ничего не выходит? Бросай.
4. Повторяешь с пункта 1 до успеха.
Планировать ВСЁ заранее - рецепт провала.
>>4074
>Очень долго думал о игре
>полугода проработал в таком режиме
>Выявил слабую сторону проекта
Ты попал в ловушку избыточного планирования.
>думаю, что делать дальше и делать ли вообще
Что тебя максимально привлекает в твоей игре?
Сфокусируйся на том, что тебя в ней привлекает.
>>4103
>Але, это тред по годоту
Это тред годотеров. Тёплый, ламповый, твой.
Алсо, он точно на Godot работал, я видел видео.
>>4116
>толщход во вселенной наоборот
А в чём там проблема-то? Норм концепция.
>я в сердцах удалил все файлы.
Ну и дурак. Я все свои неудачи сохраняю.
Впрочем, не страшно, это же только прототип.
>>4124
>осознанно отказался от важной механики
У тебя ж главная механика - копание в Толще, не?
Поиграй в аналогичные игры, их уже несколько...
>иначе сломают весь игровой цикл
Такого не бывает. Цикл либо есть, либо его нет.
Игровой цикл Толщеходов (как я его помню):
1. Закапываемся в Толщу.
2. Ищем цель - полость в Толще.
3. Пробиваемся к ней на толщеходе:
- уворачиваемся от уплотнений,
- торпедируем противников.
Всё это с помощью радара.
4. В полости (планета наоборот):
- выполняем квесты (сюжет?),
- ремонтируем толщеход,
- заправляемся и т.д.
5. Повторяем цикл с самого начала.
По сути это поводная лодка, только подземная.
>указали на одну и ту же проблему
Какую проблему-то? И почему не исправил?
Я лично не вижу проблем в этом концепте.
>механики могут быть прекрасными, а в сумме
Бред. Фановые механики фановы всегда и везде.
>>4134
Не трогай его, он наш шиз - местный олдфаг.
Сожалею ему, мне нравился концепт его игры.
Вряд ли кто-то другой вспоминает толщеходы...
7,9 Мб, mp4,256x144, 12:14
>>4081
Вот видео на эту тему, поясняет суть работы:
https://youtube.com/watch?v=kMDe7_YwVKI
Главное: «fail faster, follow the fun».
1. Делай прототип как можно скорее.
2. Прототип не фановый? Изменяй его.
3.а. Чуешь фан? Фокусируйся на фане.
3.б. Совсем ничего не выходит? Бросай.
4. Повторяешь с пункта 1 до успеха.
Планировать ВСЁ заранее - рецепт провала.
>>4074
Ты попал в ловушку избыточного планирования.
Что тебя максимально привлекает в твоей игре?
Сфокусируйся на том, что тебя в ней привлекает.
>>4103
Это тред годотеров. Тёплый, ламповый, твой.
Алсо, он точно на Godot работал, я видел видео.
>>4116
А в чём там проблема-то? Норм концепция.
Ну и дурак. Я все свои неудачи сохраняю.
Впрочем, не страшно, это же только прототип.
>>4124
У тебя ж главная механика - копание в Толще, не?
Поиграй в аналогичные игры, их уже несколько...
Такого не бывает. Цикл либо есть, либо его нет.
Игровой цикл Толщеходов (как я его помню):
1. Закапываемся в Толщу.
2. Ищем цель - полость в Толще.
3. Пробиваемся к ней на толщеходе:
- уворачиваемся от уплотнений,
- торпедируем противников.
Всё это с помощью радара.
4. В полости (планета наоборот):
- выполняем квесты (сюжет?),
- ремонтируем толщеход,
- заправляемся и т.д.
5. Повторяем цикл с самого начала.
По сути это поводная лодка, только подземная.
Какую проблему-то? И почему не исправил?
Я лично не вижу проблем в этом концепте.
Бред. Фановые механики фановы всегда и везде.
>>4134
Не трогай его, он наш шиз - местный олдфаг.
Сожалею ему, мне нравился концепт его игры.
Вряд ли кто-то другой вспоминает толщеходы...
>тратили месяцы или даже годы
>Жаль, что никто не любит рассказывать
Вот видео на эту тему, поясняет суть работы:
https://youtube.com/watch?v=kMDe7_YwVKI
Главное: «fail faster, follow the fun».
1. Делай прототип как можно скорее.
2. Прототип не фановый? Изменяй его.
3.а. Чуешь фан? Фокусируйся на фане.
3.б. Совсем ничего не выходит? Бросай.
4. Повторяешь с пункта 1 до успеха.
Планировать ВСЁ заранее - рецепт провала.
>>4074
>Очень долго думал о игре
>полугода проработал в таком режиме
>Выявил слабую сторону проекта
Ты попал в ловушку избыточного планирования.
>думаю, что делать дальше и делать ли вообще
Что тебя максимально привлекает в твоей игре?
Сфокусируйся на том, что тебя в ней привлекает.
>>4103
>Але, это тред по годоту
Это тред годотеров. Тёплый, ламповый, твой.
Алсо, он точно на Godot работал, я видел видео.
>>4116
>толщход во вселенной наоборот
А в чём там проблема-то? Норм концепция.
>я в сердцах удалил все файлы.
Ну и дурак. Я все свои неудачи сохраняю.
Впрочем, не страшно, это же только прототип.
>>4124
>осознанно отказался от важной механики
У тебя ж главная механика - копание в Толще, не?
Поиграй в аналогичные игры, их уже несколько...
>иначе сломают весь игровой цикл
Такого не бывает. Цикл либо есть, либо его нет.
Игровой цикл Толщеходов (как я его помню):
1. Закапываемся в Толщу.
2. Ищем цель - полость в Толще.
3. Пробиваемся к ней на толщеходе:
- уворачиваемся от уплотнений,
- торпедируем противников.
Всё это с помощью радара.
4. В полости (планета наоборот):
- выполняем квесты (сюжет?),
- ремонтируем толщеход,
- заправляемся и т.д.
5. Повторяем цикл с самого начала.
По сути это поводная лодка, только подземная.
>указали на одну и ту же проблему
Какую проблему-то? И почему не исправил?
Я лично не вижу проблем в этом концепте.
>механики могут быть прекрасными, а в сумме
Бред. Фановые механики фановы всегда и везде.
>>4134
Не трогай его, он наш шиз - местный олдфаг.
Сожалею ему, мне нравился концепт его игры.
Вряд ли кто-то другой вспоминает толщеходы...
104 Кб, 480x640>>4229
да не работают эти простые советы от диванных экспертов. хватит повторять эту чушь.
>просто делай прототип
>просто делай фан
>вот видишь, эта игра стала популярной, потому что ее разработчик просто делал фан!
да не работают эти простые советы от диванных экспертов. хватит повторять эту чушь.
>>4240
работают, просто идет естественный отбор и выстреливают единицы благодаря удачно сложившимся случаям.
у древнего степашки могли быть каменные яйца не чувствующие боли, охуенно полезная фича. но она не спасла от пасти саблезубого тигра. а рамзанчик с мягкими чувствительными яичками успешно осеменил прото-гориллу, пока степашку хавал тигр, и вот мы здесь
работают, просто идет естественный отбор и выстреливают единицы благодаря удачно сложившимся случаям.
у древнего степашки могли быть каменные яйца не чувствующие боли, охуенно полезная фича. но она не спасла от пасти саблезубого тигра. а рамзанчик с мягкими чувствительными яичками успешно осеменил прото-гориллу, пока степашку хавал тигр, и вот мы здесь
>>4249
Нет, на самом деле есть чёткие причины успеха, но большинство инди даже не пытается эти причины проанализировать и использовать в свою пользу. Банальным маркетингом мало кто занимается, ЦА исследовать - вообще не про инди. Цепляются за "гениальную" идею и получают унылый проект...
Абсолютно нет. В современном мире рождаются с мутациями, предотвращающими ощущение боли. Большинство таких людей умирает в детстве - тупо убиваются, потому что не видят опасностей. Яйца сверхчувствительны потому, что их слишком легко изуродовать - т.е. организм требует их защищать ("незащищённость" важна для охлаждения тканей). Видишь, даже тут не "удача", а чёткие причины.
>>4240
А ты пробовал? Если ты не чувствуешь фан от своей собственной игры, это не значит, что никто фана не чувствует от своих игр. Просто ты делаешь фигню и вцепился в неё, вместо того, чтобы отпустить или радикально переделать во что-то фановое.
Сложнее всего делать игры для ЦА, в которую ты не входишь. Т.е. ты не видишь в чём фан для твоей ЦА. Поэтому инди должны делать игры, в которые они предпочитают играть, а не просто что-то популярное.
>благодаря удачно сложившимся случаям
Нет, на самом деле есть чёткие причины успеха, но большинство инди даже не пытается эти причины проанализировать и использовать в свою пользу. Банальным маркетингом мало кто занимается, ЦА исследовать - вообще не про инди. Цепляются за "гениальную" идею и получают унылый проект...
>каменные яйца не чувствующие боли
>полезная фича
Абсолютно нет. В современном мире рождаются с мутациями, предотвращающими ощущение боли. Большинство таких людей умирает в детстве - тупо убиваются, потому что не видят опасностей. Яйца сверхчувствительны потому, что их слишком легко изуродовать - т.е. организм требует их защищать ("незащищённость" важна для охлаждения тканей). Видишь, даже тут не "удача", а чёткие причины.
>>4240
>да не работают эти простые советы
А ты пробовал? Если ты не чувствуешь фан от своей собственной игры, это не значит, что никто фана не чувствует от своих игр. Просто ты делаешь фигню и вцепился в неё, вместо того, чтобы отпустить или радикально переделать во что-то фановое.
Сложнее всего делать игры для ЦА, в которую ты не входишь. Т.е. ты не видишь в чём фан для твоей ЦА. Поэтому инди должны делать игры, в которые они предпочитают играть, а не просто что-то популярное.
>>4240
Работают отлично, проверенно. Что нихуя не работает - нафантазировать себе диздок и пытаться его реализовать один в один. Во-первых ты можешь делать идею, которая играется как унылая хуита, во-вторых ты регулярно станешь упираться в хуевые или технически сложные решения и упорствовать в их реализации, потому что диздок требует. Создание игры - органический процесс.
Работают отлично, проверенно. Что нихуя не работает - нафантазировать себе диздок и пытаться его реализовать один в один. Во-первых ты можешь делать идею, которая играется как унылая хуита, во-вторых ты регулярно станешь упираться в хуевые или технически сложные решения и упорствовать в их реализации, потому что диздок требует. Создание игры - органический процесс.
>>4324
Справедливости ради, проблема не в диздоке, а в
Дизайн-документ называют "живым документом" - поскольку может и должен меняться по ходу дела. Совсем без какой-либо документации/записей по проекту тяжело, ибо всего в голове не удержишь.
Всё ещё жду объяснений >>4074, что именно не получилось сделать в его "вселенной наоборот"... Концептуально его задумка вполне играбельная, и множество похожих проектов пришли к успеху, в особенности стоит отметить Deep Rock Galactic - там несколько другой фокус геймплея, но общая идея - "забуриться до полости -> исследовать -> повторить".
Как говорят, мало придумать интересную идею - обязательно нужно интересно реализовать.
Справедливости ради, проблема не в диздоке, а в
>реализовать один в один
>упорствовать в их реализации
Дизайн-документ называют "живым документом" - поскольку может и должен меняться по ходу дела. Совсем без какой-либо документации/записей по проекту тяжело, ибо всего в голове не удержишь.
Всё ещё жду объяснений >>4074, что именно не получилось сделать в его "вселенной наоборот"... Концептуально его задумка вполне играбельная, и множество похожих проектов пришли к успеху, в особенности стоит отметить Deep Rock Galactic - там несколько другой фокус геймплея, но общая идея - "забуриться до полости -> исследовать -> повторить".
Как говорят, мало придумать интересную идею - обязательно нужно интересно реализовать.
>>4074
Для прототипа арт обычно совсем не нужен...
Мог чисто на серых кубах сделать и отлаживать.
Пиши, если что не получается, может, поможем чем.
>арт освоил на приемлемом уровне
Для прототипа арт обычно совсем не нужен...
Мог чисто на серых кубах сделать и отлаживать.
Пиши, если что не получается, может, поможем чем.
>>4332
>>4364
Мне нужен контроллер персонажа 3D привязанный к двум видам гравитации, точечной (в полостях) и осевой (в толщеходе). Без этого невозможно реализовать ключевые механики. Сам я не осилил. Чат боты не помогли.
В общем я понимаю что нужно сделать, но когда дело доходит до кода, руки превращаются в лапки. Ранее я адаптировал шаблон из ассетстора RigidBody Planetary Physics Correct Stand Up https://godotengine.org/asset-library/asset/159 но всё это осталось на трёшке. После четвёрочных свистелок в трёшку возвращаться не хочется. Целиком чужой код переписывать не стоит.
> Всё ещё жду объяснений >>4074, что именно не получилось сделать в его "вселенной наоборот"...
>>4364
> Пиши, если что не получается, может, поможем чем.
Мне нужен контроллер персонажа 3D привязанный к двум видам гравитации, точечной (в полостях) и осевой (в толщеходе). Без этого невозможно реализовать ключевые механики. Сам я не осилил. Чат боты не помогли.
В общем я понимаю что нужно сделать, но когда дело доходит до кода, руки превращаются в лапки. Ранее я адаптировал шаблон из ассетстора RigidBody Planetary Physics Correct Stand Up https://godotengine.org/asset-library/asset/159 но всё это осталось на трёшке. После четвёрочных свистелок в трёшку возвращаться не хочется. Целиком чужой код переписывать не стоит.
Спасибо за совет про ноду ремот трансформ пару тредов назад. Удобно. Избежал велосипеда.
>>4393
Точечная это видимо та что притягивает к точке, а осевая что это? Ну ок а что если просто суммировать два вектора?
Точечная это видимо та что притягивает к точке, а осевая что это? Ну ок а что если просто суммировать два вектора?
>>4399
Отталкивается от оси. Кабина толщехода вращается, и центробежной силой создаёт тяготение в невесомости Толщи (там невесомость).
Отталкивается от оси. Кабина толщехода вращается, и центробежной силой создаёт тяготение в невесомости Толщи (там невесомость).
33,7 Мб, mp4,1280x720, 1:45
>>4393
Вот что получилось.
Здесь точечная гравитация. Всё отталкивается от центра к краям. Эффект охуенный, бежишь по бесконечному хомячьему колесу. В конце выпадаем в дырку, чисто по приколу. Саундрек - белорусы.
> Ранее я адаптировал шаблон из ассетстора RigidBody Planetary Physics Correct Stand Up
Вот что получилось.
Здесь точечная гравитация. Всё отталкивается от центра к краям. Эффект охуенный, бежишь по бесконечному хомячьему колесу. В конце выпадаем в дырку, чисто по приколу. Саундрек - белорусы.
>>4404
Ну окей первая мысль, вроде в Area3D есть точечная гравитация. Значит ты можешь изкоробки добавить две точечных гравитации, одну для полости, вторую для оси. Осевую двигать по линии в проекции игрока (грубо говоря x=y=0, z=player.z считая вдоль оси движения кабины
Ну окей первая мысль, вроде в Area3D есть точечная гравитация. Значит ты можешь изкоробки добавить две точечных гравитации, одну для полости, вторую для оси. Осевую двигать по линии в проекции игрока (грубо говоря x=y=0, z=player.z считая вдоль оси движения кабины
>>4422
Конечно могу, бро, конечно.
Конечно могу, бро, конечно.
>>4404
Так эти гравитации вряд ли вообще вмесе работать будут. Типа пока ты внутри кабины ты ходишь по ее зоне, когда выходишь ходишь по гравитации пустоты.
Так эти гравитации вряд ли вообще вмесе работать будут. Типа пока ты внутри кабины ты ходишь по ее зоне, когда выходишь ходишь по гравитации пустоты.
>>4425
Ну да, планируется, что они будут работать по очереди. Но это не отменяет того факта, что нужен контроллер поддерживающий оба варианта.
Ну да, планируется, что они будут работать по очереди. Но это не отменяет того факта, что нужен контроллер поддерживающий оба варианта.
>>4427
Так а что надо то? Звучит так что все будет работать само - точечная гравитация притягивает ригидбоди. если же контроллер на кинематике то у тебя своя функция гравитации, пишешь чтобы она притягивала в сторону точки/оси, ну и разворачивала вдоль вектора. Точечную гравитацию пустоты при входе в кабину отключаешь, имитирующую осевую включаешь. Вроде ничего особенного от контроллера для "поддержки" этого не нужно.
Так а что надо то? Звучит так что все будет работать само - точечная гравитация притягивает ригидбоди. если же контроллер на кинематике то у тебя своя функция гравитации, пишешь чтобы она притягивала в сторону точки/оси, ну и разворачивала вдоль вектора. Точечную гравитацию пустоты при входе в кабину отключаешь, имитирующую осевую включаешь. Вроде ничего особенного от контроллера для "поддержки" этого не нужно.
18 Кб, 480x270>>4430
Всё верно. Я точно так же и думал. На словах все легко и просто. Тем не менее, до сих пор не могу сделать.
Кстати, доброе утро всем!
Всё верно. Я точно так же и думал. На словах все легко и просто. Тем не менее, до сих пор не могу сделать.
Кстати, доброе утро всем!
>>4491
Скорее срать в тред ии высерами и говнотекстами про c#. Никаких реальных результатов от жителей этого треда за пару лет так и не было
>пошли делать игры.
Скорее срать в тред ии высерами и говнотекстами про c#. Никаких реальных результатов от жителей этого треда за пару лет так и не было
>>4512
Действительно. Мы же тебе про результаты нашей работы не рассказываем, а значит их нет
Действительно. Мы же тебе про результаты нашей работы не рассказываем, а значит их нет
5 Кб, 247x71Продолжаю отращивать свой скромный результат
>>4393
Вот тут Godot 4, любая гравитация, CharacterBody3D:
https://github.com/Ivorforce/Godot4-Custom-Gravity
Жаль, я не разбираюсь в векторной математике...
Не понимаю, откуда люди эти формулы берут...
Вот тут Godot 4, любая гравитация, CharacterBody3D:
https://github.com/Ivorforce/Godot4-Custom-Gravity
Жаль, я не разбираюсь в векторной математике...
Не понимаю, откуда люди эти формулы берут...
>>4519
Такая же фигня.
Ну, щас посмотрим, спасиб.
> Жаль, я не разбираюсь в векторной математике...
> Не понимаю, откуда люди эти формулы берут...
Такая же фигня.
Ну, щас посмотрим, спасиб.
Жаль нельзя выделить кучу нод, ПКМ по ним и сразу всем сделать Make local. Сижу тут кликаю по одной.
>>4546
Го пересматривать урок Годонье по трансформам, повторенье мать ученья https://www.youtube.com/watch?v=UwHIgAAGB0s
Го пересматривать урок Годонье по трансформам, повторенье мать ученья https://www.youtube.com/watch?v=UwHIgAAGB0s
>>4546
А что тебе ещё нужно?
Есть вариант просто разделить полости и толщеходы на отдельные сцены:
1. Нажал E на шлюз толщехода -> затемнение -> ты внутри толщехода.
2. Нажал E на шлюз изнутри -> затемнение -> ты снаружи, в полости.
3. Нажал E на шлюз, не доехав до полости -> "здесь нельзя выйти".
Тогда у тебя может быть 2 отдельных контроллера персонажа.
>>4558
А зачем?
>>4566
У меня ни ютуб не работает, ни онлайн-скачиватели видосов...
>Ничего полезного
А что тебе ещё нужно?
Есть вариант просто разделить полости и толщеходы на отдельные сцены:
1. Нажал E на шлюз толщехода -> затемнение -> ты внутри толщехода.
2. Нажал E на шлюз изнутри -> затемнение -> ты снаружи, в полости.
3. Нажал E на шлюз, не доехав до полости -> "здесь нельзя выйти".
Тогда у тебя может быть 2 отдельных контроллера персонажа.
>>4558
>кучу нод
>Make local
А зачем?
>>4566
У меня ни ютуб не работает, ни онлайн-скачиватели видосов...
>>4512
Ну у новичков и вкатунов конечно нет, а некоторые тут 3-4 игры в год выпускают.
Ну у новичков и вкатунов конечно нет, а некоторые тут 3-4 игры в год выпускают.
>>4558
Опасная игрушка диавола ежжи. Я так полдня баг искал. А оказалось я правил отдельную сцену и забыл что ее копию сделал make local подсценой игровой.
Опасная игрушка диавола ежжи. Я так полдня баг искал. А оказалось я правил отдельную сцену и забыл что ее копию сделал make local подсценой игровой.
>>4594
Да он мутнит что то. Ему каждый раз несколько рабочих вариантов накидывают а ему все не то.
>А что тебе ещё нужно?
Да он мутнит что то. Ему каждый раз несколько рабочих вариантов накидывают а ему все не то.
>>4640
Ну да, все советы относятся либо к плоской модели окружения, либо классическая гравитация с планетами. А нужна инверсная система. Моего скудного умишки не хватает. Я кое-как нашел где минус поставить в планетарном шаблоне для трёшки и на этом всё. В четверке аналогичных шаблонов нет, а имеющиеся не работают с минусом.
> все не то
Ну да, все советы относятся либо к плоской модели окружения, либо классическая гравитация с планетами. А нужна инверсная система. Моего скудного умишки не хватает. Я кое-как нашел где минус поставить в планетарном шаблоне для трёшки и на этом всё. В четверке аналогичных шаблонов нет, а имеющиеся не работают с минусом.
>>4639
У меня Godot регулярно ошибается с обновлением параметров сцен, которые используются в других сценах. Редактирую скрипт, изменяя параметры по умолчанию, запускаю игру - НОЛЬ изменений. Каждый раз забываю про этот баг редактора и пытаюсь править свой код. Потом вспоминаю, иду в совершенно другую вкладку, нажимаю кнопку "вернуть по умолчанию" и всё работает. Вот почему так? Почему редактор сохраняет старые параметры по умолчанию, если они даже не были изменены ни разу? Т.е. в tscn файле изначально нет никаких записей. А он берёт и сохраняет УСТАРЕВШИЕ значения... Единственный надёжный способ обойти эту проблему - закрывать все лишние сцены, чтобы при следующем запуске игры они считывались с диска, а не перезаписывались.
Не знаю, исправили ли в 4.4, но не хочется проверять (а то опять что-нибудь сломаю).
>>4640
Он явно ленится изучать математику и программирование. Списывает свою лень на "скудный ум", а на деле наверняка нетерпеливо копипастит и не читает документацию. Все через это проходили... Всегда хочется по-быстрее увидеть свои гениальные идеи вживую с минимальными затратами...
>>4648
Просто ставишь минус перед вектором ускорения и должно сработать наоборот.
Там не так много отличий между версиями. Основное API осталось без изменений, все изменения достаточно понятны даже для новичка. Просто читаешь документацию и понимаешь, как перенести старые скрипты на новую версию. Я все свои старые скрипты с 3 перенёс на 4 без проблем.
Может, тебя смущает переход с KinematicBody на CharacterBody3D? Там просто вынесли аргументы функции в свойства класса, чтобы лишний раз не дёргать. И ещё что-то перенесли на класс выше по дереву наследования, но это не так важно. С RigidBody3D вообще ничего не поменялось, физическое API давно стабильно и над физикой в движке долгое время никто не работал.
Я бы тебе сделал пример кода... Но я сам плохо разбираюсь в векторной математике и поэтому у меня не получается лаконично развернуть Node3D, получается какой-то хаос.
>правил отдельную сцену и забыл что ее копию сделал
У меня Godot регулярно ошибается с обновлением параметров сцен, которые используются в других сценах. Редактирую скрипт, изменяя параметры по умолчанию, запускаю игру - НОЛЬ изменений. Каждый раз забываю про этот баг редактора и пытаюсь править свой код. Потом вспоминаю, иду в совершенно другую вкладку, нажимаю кнопку "вернуть по умолчанию" и всё работает. Вот почему так? Почему редактор сохраняет старые параметры по умолчанию, если они даже не были изменены ни разу? Т.е. в tscn файле изначально нет никаких записей. А он берёт и сохраняет УСТАРЕВШИЕ значения... Единственный надёжный способ обойти эту проблему - закрывать все лишние сцены, чтобы при следующем запуске игры они считывались с диска, а не перезаписывались.
Не знаю, исправили ли в 4.4, но не хочется проверять (а то опять что-нибудь сломаю).
>>4640
Он явно ленится изучать математику и программирование. Списывает свою лень на "скудный ум", а на деле наверняка нетерпеливо копипастит и не читает документацию. Все через это проходили... Всегда хочется по-быстрее увидеть свои гениальные идеи вживую с минимальными затратами...
>>4648
>гравитация с планетами. А нужна инверсная система.
Просто ставишь минус перед вектором ускорения и должно сработать наоборот.
>для трёшки
>В четверке
Там не так много отличий между версиями. Основное API осталось без изменений, все изменения достаточно понятны даже для новичка. Просто читаешь документацию и понимаешь, как перенести старые скрипты на новую версию. Я все свои старые скрипты с 3 перенёс на 4 без проблем.
Может, тебя смущает переход с KinematicBody на CharacterBody3D? Там просто вынесли аргументы функции в свойства класса, чтобы лишний раз не дёргать. И ещё что-то перенесли на класс выше по дереву наследования, но это не так важно. С RigidBody3D вообще ничего не поменялось, физическое API давно стабильно и над физикой в движке долгое время никто не работал.
Я бы тебе сделал пример кода... Но я сам плохо разбираюсь в векторной математике и поэтому у меня не получается лаконично развернуть Node3D, получается какой-то хаос.
>>4639
У меня Godot регулярно ошибается с обновлением параметров сцен, которые используются в других сценах. Редактирую скрипт, изменяя параметры по умолчанию, запускаю игру - НОЛЬ изменений. Каждый раз забываю про этот баг редактора и пытаюсь править свой код. Потом вспоминаю, иду в совершенно другую вкладку, нажимаю кнопку "вернуть по умолчанию" и всё работает. Вот почему так? Почему редактор сохраняет старые параметры по умолчанию, если они даже не были изменены ни разу? Т.е. в tscn файле изначально нет никаких записей. А он берёт и сохраняет УСТАРЕВШИЕ значения... Единственный надёжный способ обойти эту проблему - закрывать все лишние сцены, чтобы при следующем запуске игры они считывались с диска, а не перезаписывались.
Не знаю, исправили ли в 4.4, но не хочется проверять (а то опять что-нибудь сломаю).
>>4640
Он явно ленится изучать математику и программирование. Списывает свою лень на "скудный ум", а на деле наверняка нетерпеливо копипастит и не читает документацию. Все через это проходили... Всегда хочется по-быстрее увидеть свои гениальные идеи вживую с минимальными затратами...
>>4648
Просто ставишь минус перед вектором ускорения и должно сработать наоборот.
Там не так много отличий между версиями. Основное API осталось без изменений, все изменения достаточно понятны даже для новичка. Просто читаешь документацию и понимаешь, как перенести старые скрипты на новую версию. Я все свои старые скрипты с 3 перенёс на 4 без проблем.
Может, тебя смущает переход с KinematicBody на CharacterBody3D? Там просто вынесли аргументы функции в свойства класса, чтобы лишний раз не дёргать. И ещё что-то перенесли на класс выше по дереву наследования, но это не так важно. С RigidBody3D вообще ничего не поменялось, физическое API давно стабильно и над физикой в движке долгое время никто не работал.
Я бы тебе сделал пример кода... Но я сам плохо разбираюсь в векторной математике и поэтому у меня не получается лаконично развернуть Node3D, получается какой-то хаос.
>правил отдельную сцену и забыл что ее копию сделал
У меня Godot регулярно ошибается с обновлением параметров сцен, которые используются в других сценах. Редактирую скрипт, изменяя параметры по умолчанию, запускаю игру - НОЛЬ изменений. Каждый раз забываю про этот баг редактора и пытаюсь править свой код. Потом вспоминаю, иду в совершенно другую вкладку, нажимаю кнопку "вернуть по умолчанию" и всё работает. Вот почему так? Почему редактор сохраняет старые параметры по умолчанию, если они даже не были изменены ни разу? Т.е. в tscn файле изначально нет никаких записей. А он берёт и сохраняет УСТАРЕВШИЕ значения... Единственный надёжный способ обойти эту проблему - закрывать все лишние сцены, чтобы при следующем запуске игры они считывались с диска, а не перезаписывались.
Не знаю, исправили ли в 4.4, но не хочется проверять (а то опять что-нибудь сломаю).
>>4640
Он явно ленится изучать математику и программирование. Списывает свою лень на "скудный ум", а на деле наверняка нетерпеливо копипастит и не читает документацию. Все через это проходили... Всегда хочется по-быстрее увидеть свои гениальные идеи вживую с минимальными затратами...
>>4648
>гравитация с планетами. А нужна инверсная система.
Просто ставишь минус перед вектором ускорения и должно сработать наоборот.
>для трёшки
>В четверке
Там не так много отличий между версиями. Основное 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
Для защиты проекта 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
8 Кб, 759x50>>4694
Если игра запускается, это значит что ключ поставляется вместо с игрой, то есть буквально зашифрованное и ключ расшифровки лежат в одном файле. Да это задержит ненадолго.
Некоторые пишут свою систему, чтобы, если стандартную взломают, то с их еще дольше возились.
Дальше уже писать на C++ и там пользоваться спец приемами. В том числе шифрующие оперативную память.
Еще один вариант - делать все что можно на сервере, а игроку показывать по сути гуй с кнопками. Например в шахматах ты хоть обдвигайся неправильно или наспавни сто ферзей - сервер будет отбрасывать то, что не соотвествует его состоянию. (Но отсюда же и сложность - игроки будут бугуртить, если сервер глючит например после рассинхрона и показывает им ложные контролы)
>>4699
Краем глаза читал, что денуву никогда не ломали. Ломали те игры, которые забыли защитить - выложили дебаг билд или типа того.
Если игра запускается, это значит что ключ поставляется вместо с игрой, то есть буквально зашифрованное и ключ расшифровки лежат в одном файле. Да это задержит ненадолго.
Некоторые пишут свою систему, чтобы, если стандартную взломают, то с их еще дольше возились.
Дальше уже писать на C++ и там пользоваться спец приемами. В том числе шифрующие оперативную память.
Еще один вариант - делать все что можно на сервере, а игроку показывать по сути гуй с кнопками. Например в шахматах ты хоть обдвигайся неправильно или наспавни сто ферзей - сервер будет отбрасывать то, что не соотвествует его состоянию. (Но отсюда же и сложность - игроки будут бугуртить, если сервер глючит например после рассинхрона и показывает им ложные контролы)
>>4699
Краем глаза читал, что денуву никогда не ломали. Ломали те игры, которые забыли защитить - выложили дебаг билд или типа того.
>>4393
Вот ещё прикольный вариант, тут и цилиндры, и сферы:
https://godotengine.org/asset-library/asset/546
>>4694
Защиты от кого? Кому твой говнокод захочется трогать?
Лучшая защита от пиратства - опенсурс лицензия на гитхабе.
Ещё ни разу не видел опенсурс игры на пиратских трекерах.
>>4700
Ненавижу такое. Когда ты умрёшь, твоя игра умрёт с тобой...
Если только все исходники сервера игры сразу в опенсурсе...
Просто никому не сдались все эти "АААА"-говноподделки.
Вот ещё прикольный вариант, тут и цилиндры, и сферы:
https://godotengine.org/asset-library/asset/546
>>4694
>защиты проекта
Защиты от кого? Кому твой говнокод захочется трогать?
Лучшая защита от пиратства - опенсурс лицензия на гитхабе.
Ещё ни разу не видел опенсурс игры на пиратских трекерах.
>>4700
>делать все что можно на сервере
Ненавижу такое. Когда ты умрёшь, твоя игра умрёт с тобой...
Если только все исходники сервера игры сразу в опенсурсе...
>денуву никогда не ломали
Просто никому не сдались все эти "АААА"-говноподделки.
>>4704
Поделись хоть, чего добился?
Я вижу этапы этой проблемы так:
1. Направление притяжения - это пока не важно, пускай будет такое:
2. Развернуть персонажа ногами в сторону притяжения.
Вообще без понятия, как это делать "правильно", я могу только так:
Но нужна какая-то жёсткая математика, ибо look_at постоянно делает что-то не то, что нужно.
3. Развернуть Input.get_vector() в плоскости движения персонажа...
ВООБЩЕ без понятия - гуглил примеры, ничего не понял.
Какие-то Vector3.cross(), а что, зачем, почему - не ясно.
4. Подвинуть персонажа. Бессмысленно это делать без решения пунктов 2-3.
Короче, если кто-то нашёл простое решение 2-3 без багов и глюков - полдела, считай, сделано.
Все эти туториалы по векторной математике ничего толком не объясняют...
Я понимаю, что Vector3.cross() даёт вектор, перпендикулярным двум другим - И ЧТО ТЕПЕРЬ?
Что с этими векторами делать-то? Каким магическим образом перпендикуляр тут поможет?
Очень расстраивает такое. Математики специально так сложно придумали?
>уже близко
Поделись хоть, чего добился?
Я вижу этапы этой проблемы так:
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() даёт вектор, перпендикулярным двум другим - И ЧТО ТЕПЕРЬ?
Что с этими векторами делать-то? Каким магическим образом перпендикуляр тут поможет?
Очень расстраивает такое. Математики специально так сложно придумали?
>>4704
Поделись хоть, чего добился?
Я вижу этапы этой проблемы так:
1. Направление притяжения - это пока не важно, пускай будет такое:
2. Развернуть персонажа ногами в сторону притяжения.
Вообще без понятия, как это делать "правильно", я могу только так:
Но нужна какая-то жёсткая математика, ибо look_at постоянно делает что-то не то, что нужно.
3. Развернуть Input.get_vector() в плоскости движения персонажа...
ВООБЩЕ без понятия - гуглил примеры, ничего не понял.
Какие-то Vector3.cross(), а что, зачем, почему - не ясно.
4. Подвинуть персонажа. Бессмысленно это делать без решения пунктов 2-3.
Короче, если кто-то нашёл простое решение 2-3 без багов и глюков - полдела, считай, сделано.
Все эти туториалы по векторной математике ничего толком не объясняют...
Я понимаю, что Vector3.cross() даёт вектор, перпендикулярным двум другим - И ЧТО ТЕПЕРЬ?
Что с этими векторами делать-то? Каким магическим образом перпендикуляр тут поможет?
Очень расстраивает такое. Математики специально так сложно придумали?
>уже близко
Поделись хоть, чего добился?
Я вижу этапы этой проблемы так:
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() даёт вектор, перпендикулярным двум другим - И ЧТО ТЕПЕРЬ?
Что с этими векторами делать-то? Каким магическим образом перпендикуляр тут поможет?
Очень расстраивает такое. Математики специально так сложно придумали?
>>4726
Да попозже поделюсь, когда побольше проработаю, отходил от компа.
Это почти во всех контроллерах есть. Используют basis.transform.z который является направлением вперед. Например у меня сейчас
velocity = (transform.basis.z input_dir.y + transform.basis.x input_dir.x).normalized() * speed
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/
Да попозже поделюсь, когда побольше проработаю, отходил от компа.
> Развернуть 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/
https://github.com/godotengine/godot/blob/750640cede4741a6a526fa5172a199bbb1ac0758/core/math/basis.cpp#L1047
Ну и как это понимать? Сделали 3 вектора, перпендикулярных друг другу и... и что это? Откуда разворот-то здесь?
Я понимаю, что собрали новый базис, но не понимаю, почему он "смотрит на цель", как к этому вообще пришли?
>>4727
А зачем? Абсолютное большинство контроллеров - это симулятор ходьбы по плоской планете...
У меня обычно примерно такой код:
Получил ввод @ развернул на угол, зачем прибегать к 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 согласно примеру.
Тогда компьютер будет брутфорсить формулы вместо меня...
Извините за нытьё, сильно наболело за эти годы.
>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 вектора, перпендикулярных друг другу и... и что это? Откуда разворот-то здесь?
Я понимаю, что собрали новый базис, но не понимаю, почему он "смотрит на цель", как к этому вообще пришли?
>>4727
>Это почти во всех контроллерах есть. Используют 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 согласно примеру.
Тогда компьютер будет брутфорсить формулы вместо меня...
Извините за нытьё, сильно наболело за эти годы.
https://github.com/godotengine/godot/blob/750640cede4741a6a526fa5172a199bbb1ac0758/core/math/basis.cpp#L1047
Ну и как это понимать? Сделали 3 вектора, перпендикулярных друг другу и... и что это? Откуда разворот-то здесь?
Я понимаю, что собрали новый базис, но не понимаю, почему он "смотрит на цель", как к этому вообще пришли?
>>4727
А зачем? Абсолютное большинство контроллеров - это симулятор ходьбы по плоской планете...
У меня обычно примерно такой код:
Получил ввод @ развернул на угол, зачем прибегать к 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 согласно примеру.
Тогда компьютер будет брутфорсить формулы вместо меня...
Извините за нытьё, сильно наболело за эти годы.
>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 вектора, перпендикулярных друг другу и... и что это? Откуда разворот-то здесь?
Я понимаю, что собрали новый базис, но не понимаю, почему он "смотрит на цель", как к этому вообще пришли?
>>4727
>Это почти во всех контроллерах есть. Используют 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 согласно примеру.
Тогда компьютер будет брутфорсить формулы вместо меня...
Извините за нытьё, сильно наболело за эти годы.
32 Кб, 445x251>>4733
Двачую каждое слово.
У меня такая же ситуация.
Вчера вечером после пинков ИТТ я таки открыл годот и попытался хоть что-то набросать. Ничего толкового не получилось, но зато я узнал, что в четвёрке допилили класс бывшего KinematicBody, который теперь CharacterBody, и он теперь подвержен гравитации Area. И ещё есть теперь метод get_gravity() который собирает результирующую гравитацию в текущей точке, опрашивая все влияющие объекты.
>>4727
Глянем
>>4705
Прикольный, но трёшка.
>>4704
Попробуй 4 года сидеть и тупить над проектом.
Двачую каждое слово.
У меня такая же ситуация.
Вчера вечером после пинков ИТТ я таки открыл годот и попытался хоть что-то набросать. Ничего толкового не получилось, но зато я узнал, что в четвёрке допилили класс бывшего KinematicBody, который теперь CharacterBody, и он теперь подвержен гравитации Area. И ещё есть теперь метод get_gravity() который собирает результирующую гравитацию в текущей точке, опрашивая все влияющие объекты.
>>4727
> туториалы
Глянем
>>4705
> прикольный вариант
Прикольный, но трёшка.
>>4704
Попробуй 4 года сидеть и тупить над проектом.
>>4594
Прокси не пробовал?
https://cdn.youtubeunblocked.live/_ru/?__cpLangSet=1
>У меня ни ютуб не работает, ни онлайн-скачиватели видосов...
Прокси не пробовал?
https://cdn.youtubeunblocked.live/_ru/?__cpLangSet=1
>>4726
Делюсь. Говнокод в наличии. Несколько часов на фигню и багфиксы потратил, правда.
Идея такая - использовать встроенные Area для гравитации.
Начнем с того что в самом проекте я убрал гравитацию и вектор гравитации в 0.
Скачал ассет кинематик контроллера (не стал делать на ригид)
Собственно есть 2 Area. Одна имитирует отталкивающий шар.
Второй с кастомной гравитацией цилиндра. Для отладки на видосе видно оранжевую ось.
Сначала тестировал чтобы она притягивала.
Эта ареа вызывает всем пересекающимся с ней физ телам функцию set_custom_gravity если она в наличии. Тут есть место для оптимизации. Соответственно обе Area влияют только когда тело внутри зоны
У контроллера есть два режима, скажем так 3д платформер автоориентированный вдоль кастомной гравитации. И свободный полет.
Долго возился с прыжком, пока не понял что код отпущенных клавиш вместо торможения перекашивал вектор прыжка, поэтому важен порядок компонентов.
Словил какой то странный баг move and slide который сильно дергал на несколько метров. Возможно это из за грубой поверхности кольца, это CSG с 64 гранями, возможно Годот считал что там что-то скользит по стенам, не знаю. На этот случай у меня костыль, если скорость резко скакнула, отменить такое пердвижение и округлить с предыдущим.
Камера была в контроллере, но я немного переделал, когда на земле это spring arm, когда в космосе просто вращение всей капсулы
Код align взят с kidscancode
В коде куча ошибок с вычислениями, я сейчас вижу что в одном месте умножаю на массу вместо массы в квадрате, а в другом умножаю все на 2000 просто потому что... так что там просто подогнаны приятные веса, это ненаучный подход конечно.
Делюсь. Говнокод в наличии. Несколько часов на фигню и багфиксы потратил, правда.
Идея такая - использовать встроенные Area для гравитации.
Начнем с того что в самом проекте я убрал гравитацию и вектор гравитации в 0.
Скачал ассет кинематик контроллера (не стал делать на ригид)
Собственно есть 2 Area. Одна имитирует отталкивающий шар.
Второй с кастомной гравитацией цилиндра. Для отладки на видосе видно оранжевую ось.
Сначала тестировал чтобы она притягивала.
Эта ареа вызывает всем пересекающимся с ней физ телам функцию set_custom_gravity если она в наличии. Тут есть место для оптимизации. Соответственно обе Area влияют только когда тело внутри зоны
У контроллера есть два режима, скажем так 3д платформер автоориентированный вдоль кастомной гравитации. И свободный полет.
Долго возился с прыжком, пока не понял что код отпущенных клавиш вместо торможения перекашивал вектор прыжка, поэтому важен порядок компонентов.
Словил какой то странный баг move and slide который сильно дергал на несколько метров. Возможно это из за грубой поверхности кольца, это CSG с 64 гранями, возможно Годот считал что там что-то скользит по стенам, не знаю. На этот случай у меня костыль, если скорость резко скакнула, отменить такое пердвижение и округлить с предыдущим.
Камера была в контроллере, но я немного переделал, когда на земле это spring arm, когда в космосе просто вращение всей капсулы
Код align взят с kidscancode
В коде куча ошибок с вычислениями, я сейчас вижу что в одном месте умножаю на массу вместо массы в квадрате, а в другом умножаю все на 2000 просто потому что... так что там просто подогнаны приятные веса, это ненаучный подход конечно.
299 Кб, mp4,460x258, 0:10
Народ. Как реалистично реализовать подобную физику на гойде. В голове варятся разные игровые механики с задействованием данной физики.
Помогите аэродинамично влиться в геймдев.
Помогите аэродинамично влиться в геймдев.
>>4752
Вот этот прием используется
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/
Дерзай, ждем шедевр.
Вот этот прием используется
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/
Дерзай, ждем шедевр.
>>4743
Ну кста не всегда это хорошо. У меня на тройке в первой игре гравитация игрока отличалась от всего окружающего физона, потому что иначе то ригиды были слишком резкие, то перс слишком плавный.
>>4694
Но зачем? И, тем более, нахуя?
>CharacterBody, и он теперь подвержен гравитации Area. И ещё есть теперь метод get_gravity()
Ну кста не всегда это хорошо. У меня на тройке в первой игре гравитация игрока отличалась от всего окружающего физона, потому что иначе то ригиды были слишком резкие, то перс слишком плавный.
>>4694
Но зачем? И, тем более, нахуя?
>>4785
Слои вроде позволяют разделить.
>CharacterBody, и он теперь подвержен гравитации Area. И ещё есть теперь метод get_gravity()
>Ну кста не всегда это хорошо. равитация игрока отличалась от всего окружающего физона
Слои вроде позволяют разделить.
вопрос не по теме наверное, а что там с редотом?
стоит поковырять или нахненужон?
стоит поковырять или нахненужон?
>>4797
Тут обсуждали >>999062 →
TL;DR - мертв. 3 его разработчика еще разосраться успели из-за денег, 2 съебали в Блазиум. Оставшийся видимо ноускилльное дно.
Тут обсуждали >>999062 →
TL;DR - мертв. 3 его разработчика еще разосраться успели из-за денег, 2 съебали в Блазиум. Оставшийся видимо ноускилльное дно.
1,5 Мб, 1024x1024>>4797
Вкратце: Лучше потрать время на разработку игры, а не на изучение форков, анон
С ликбезом: Редот - еще один форк, коих уже, наверно, с десяток наберется. Просто он появился, грамотно обернув в свою пользу негативный инфоповод, когда коммьюнити менеджер Годота облажался в Твиттере. Разработчикам это все не интересно, они игры делают, а не отстаивают что-то перед незнакомцами в соцсетях. Все адекватные люди эту историю полностью проигнорировали, а те, кому почему-то не все равно - в знак протеста перешли на Редот, который просто мерджит все коммиты Годота, а своего практически ничего не добавляет. Там один идейный человек, на котором все держится, а адекватные разработчики продолжают развивать Годот и делать на нем свои игры
Вкратце: Лучше потрать время на разработку игры, а не на изучение форков, анон
С ликбезом: Редот - еще один форк, коих уже, наверно, с десяток наберется. Просто он появился, грамотно обернув в свою пользу негативный инфоповод, когда коммьюнити менеджер Годота облажался в Твиттере. Разработчикам это все не интересно, они игры делают, а не отстаивают что-то перед незнакомцами в соцсетях. Все адекватные люди эту историю полностью проигнорировали, а те, кому почему-то не все равно - в знак протеста перешли на Редот, который просто мерджит все коммиты Годота, а своего практически ничего не добавляет. Там один идейный человек, на котором все держится, а адекватные разработчики продолжают развивать Годот и делать на нем свои игры
>>4976
Чем я за 4 года :с
Чем я за 4 года :с
>>4785
Там разница не в гравитации, а 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. Потенциально это может влиять и на скорость свободного падения...
>гравитация игрока отличалась от всего окружающего физона, потому что иначе то ригиды были слишком резкие, то перс слишком плавный
Там разница не в гравитации, а 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. Потенциально это может влиять и на скорость свободного падения...
>>5042
Нет, скорее всего у него все объекты по 1 килограмму. Самая распространённая ошибка жалующихся на физику.
Нет, скорее всего у него все объекты по 1 килограмму. Самая распространённая ошибка жалующихся на физику.
>>5075
Ты прост дед с черствым сердцем.
Ты прост дед с черствым сердцем.
>>5065
Лебеди суровые на третьей.
Лебеди суровые на третьей.
>>5061
Но вес никак не влияет на скорость падения... В вакууме объекты падают с одинаковой скоростью независимо от массы. Разница наблюдается только благодаря трению о воздух - которое симулируется исключительно через linear_damp/angular_damp.
Масса RigidBody3D влияет только на столкновения с другими RigidBody3D: более тяжёлый объект сильнее отклоняет более лёгкий объект и наоборот, но только в случае столкновения. К CharacterBody3D масса при столкновении отношения не имеет, поскольку либо столкновения не происходит (CharacterBody3D тупо останавливается перед RigidBody3D), либо RigidBody отлетает от CharacterBody3D как от StaticBody3D, т.е. объекта с бесконечной массой (неподвижного).
>все объекты по 1 килограмму
Но вес никак не влияет на скорость падения... В вакууме объекты падают с одинаковой скоростью независимо от массы. Разница наблюдается только благодаря трению о воздух - которое симулируется исключительно через linear_damp/angular_damp.
Масса RigidBody3D влияет только на столкновения с другими RigidBody3D: более тяжёлый объект сильнее отклоняет более лёгкий объект и наоборот, но только в случае столкновения. К CharacterBody3D масса при столкновении отношения не имеет, поскольку либо столкновения не происходит (CharacterBody3D тупо останавливается перед RigidBody3D), либо RigidBody отлетает от CharacterBody3D как от StaticBody3D, т.е. объекта с бесконечной массой (неподвижного).
>>4751
Тоже отталкиваюсь от этой идеи.
А можно код в раржпег? Или на пастебин?
Или доделывай всю остальную игру, а мы просто поиграем.
> Идея такая - использовать встроенные Area для гравитации.
Тоже отталкиваюсь от этой идеи.
> Второй с кастомной гравитацией цилиндра.
> ызывает всем пересекающимся с ней физ телам функцию set_custom_gravity если она в наличии
А можно код в раржпег? Или на пастебин?
Или доделывай всю остальную игру, а мы просто поиграем.
>>4797
Игнорируй политические форки, от них нет толку.
>>4798
Политический форк политического форка, лол.
>>4809
В чём? Всё правильно сделали. Просто время было неудачное и весь твиттер в целом - яма со змеями.
- Облажался с твитом? Нет, всё правильно твитнул.
- Облажался с банами? Нет, всё правильно забанил.
- Облажались с разбаном? Нет, кого надо разбанили.
Вся эта ситуация никак на Godot не сказалась, ибо проблема в определённой категории людей, что изначально не заинтересованы в Godot. И люди эти в целом токсичные агрессоры. Т.е. никакой ошибки менеджера не было, ведь жопная боль каких-то посторонних людей - не ошибка, а их нормальное, привычное им состояние - повод всегда найдут.
Поэтому у этого форка не было будущего - ведь его создали из-за несуществующей проблемы. Лучше изучать практические форки, как у Zylann (воксели).
Если вдруг кто-то сделает что-то полезное где-то в политическом форке, и это будет нужно для Godot, разработчики Godot могут забрать это к себе - при условии, что форк сохраняет MIT лицензию. Но, как правило, в форках занимаются чепухой или чем-то чрезвычайно специфическим - Godot это не нужно.
Так что не парьтесь и качайте официальный Godot.
>что там с редотом?
Игнорируй политические форки, от них нет толку.
>>4798
>есть блазия
Политический форк политического форка, лол.
>>4809
>коммьюнити менеджер Годота облажался
В чём? Всё правильно сделали. Просто время было неудачное и весь твиттер в целом - яма со змеями.
- Облажался с твитом? Нет, всё правильно твитнул.
- Облажался с банами? Нет, всё правильно забанил.
- Облажались с разбаном? Нет, кого надо разбанили.
Вся эта ситуация никак на Godot не сказалась, ибо проблема в определённой категории людей, что изначально не заинтересованы в Godot. И люди эти в целом токсичные агрессоры. Т.е. никакой ошибки менеджера не было, ведь жопная боль каких-то посторонних людей - не ошибка, а их нормальное, привычное им состояние - повод всегда найдут.
Поэтому у этого форка не было будущего - ведь его создали из-за несуществующей проблемы. Лучше изучать практические форки, как у Zylann (воксели).
Если вдруг кто-то сделает что-то полезное где-то в политическом форке, и это будет нужно для Godot, разработчики Godot могут забрать это к себе - при условии, что форк сохраняет MIT лицензию. Но, как правило, в форках занимаются чепухой или чем-то чрезвычайно специфическим - Godot это не нужно.
Так что не парьтесь и качайте официальный Godot.
>>5093
Так я его там на пиках и видосах показал. Ну держи проект если хочешь
https://anonymfile.com/gzb20/gwell.zip
контроллер там изначально на базе аддона https://godotengine.org/asset-library/asset/3591
Но как я сказал, там код кривой и математика кривая.
Я теперь и не уверен надо ли там гравитацию умножать на массу или массу в кв.
12-15 строчка точно правильные. Они и считают перпендикулярный (кратчайший) вектор от персонажа к оси. Это зеленая линяя которая тянется к оранжевой оси.
Потом я подумал что может быть гравитация наоборот должна работать по другому. Обычная то гравитация уменьшается с ростом расстояния. Я просто вычитаю нормальную гравитацию от сферы вместо того чтобы прибавлять как обычно. Но может быть нужна именно обратная гравитация, которая сильно прижимает к земле, но слабеет при взлете и приближению к центру полости. Иными словами, f = gravity(-dist) не то же самое что f = -gravity(dist).
> с кастомной гравитацией цилиндра.
> вызывает всем пересекающимся с ней физ телам функцию set_custom_gravity если она в наличии
Так я его там на пиках и видосах показал. Ну держи проект если хочешь
https://anonymfile.com/gzb20/gwell.zip
контроллер там изначально на базе аддона https://godotengine.org/asset-library/asset/3591
Но как я сказал, там код кривой и математика кривая.
Я теперь и не уверен надо ли там гравитацию умножать на массу или массу в кв.
12-15 строчка точно правильные. Они и считают перпендикулярный (кратчайший) вектор от персонажа к оси. Это зеленая линяя которая тянется к оранжевой оси.
Потом я подумал что может быть гравитация наоборот должна работать по другому. Обычная то гравитация уменьшается с ростом расстояния. Я просто вычитаю нормальную гравитацию от сферы вместо того чтобы прибавлять как обычно. Но может быть нужна именно обратная гравитация, которая сильно прижимает к земле, но слабеет при взлете и приближению к центру полости. Иными словами, f = gravity(-dist) не то же самое что f = -gravity(dist).
>>5099
У меня не скачивается. После 45 секунд появляется кнопка и вместо скачивания постоянно открывает рекламу.
У меня не скачивается. После 45 секунд появляется кнопка и вместо скачивания постоянно открывает рекламу.
>>5099
Лол, я бы на это забил - у него вся суть игры в этих полостях - что-то вроде обычного action adventure. Существенная разница в гравитации будет, если в геймплей добавить что-то летающее (самолёт), или диаметр полости примерно равен высоте прыжка.
В случае с цилиндром толщехода очевидно, что реалистичное зависание в центре обязательно будет мешаться геймплейно. Практически никто не делает реалистичную гравитацию в космосе, т.к. это будет вызывать раздражение у типичного игрока.
>слабеет при взлете и приближению к центру
Лол, я бы на это забил - у него вся суть игры в этих полостях - что-то вроде обычного action adventure. Существенная разница в гравитации будет, если в геймплей добавить что-то летающее (самолёт), или диаметр полости примерно равен высоте прыжка.
В случае с цилиндром толщехода очевидно, что реалистичное зависание в центре обязательно будет мешаться геймплейно. Практически никто не делает реалистичную гравитацию в космосе, т.к. это будет вызывать раздражение у типичного игрока.
Выше кто-то говорил про ресурсы с прикрепленными скриптами вместо полноценных сцен. Я сейчас пытаюсь разобраться и не понимаю, как, почему, для чего? Поясните?
>>5109
Вообще-то не совсем, но даже в полостях можно много механик сделать.
Вообще-то часть полостей являются освещёнными куском первичной материи, которая ведет себя как микрозвезда. Лететь к микрозвезде на самолёте это скажем так, икаровский [роскомнадзор]. Однако в достаточно крупных полостях в небе могут вращаться вокруг центральной микрозвезды на орбитальной механике несколько каменюк, и это уже планеты наоборот-наоборот. Ну не совсем планеты, так, астероиды.
Часть полостей без микрозвезды, так называемые тёмные полости, там будет не до полётов - это хоррор-локации, населённые чудовищами.
> у него вся суть игры в этих полостях
Вообще-то не совсем, но даже в полостях можно много механик сделать.
> реалистичное зависание в центре обязательно будет мешаться геймплейно
Вообще-то часть полостей являются освещёнными куском первичной материи, которая ведет себя как микрозвезда. Лететь к микрозвезде на самолёте это скажем так, икаровский [роскомнадзор]. Однако в достаточно крупных полостях в небе могут вращаться вокруг центральной микрозвезды на орбитальной механике несколько каменюк, и это уже планеты наоборот-наоборот. Ну не совсем планеты, так, астероиды.
Часть полостей без микрозвезды, так называемые тёмные полости, там будет не до полётов - это хоррор-локации, населённые чудовищами.
>>5111
Причём тут сцены?
У тебя есть нода MeshInstance3D, например, но как нода, она меша не содержит. Меш цепляется к ней как ресурс, в соответствующем поле в инспекторе. Об этом тебе и говорили. Осознай что есть меш? Это файл на диске. Это данные, которые следует с диска загрузить.
Ты можешь так же делать свои кастомные ресурсы, например, элементы инвентаря, они как ресурс прекрасно хранят "бизнес-логику" предметов. Чтобы создать предмет в сцене, например, выкинув его из инвентаря, ты уже создаёшь ноду-префаб, олицетворяющую предмет на сцене, и у этого префаба будет поле для предмета, в которое ты скопируешь дропнутый предмет. При подборе обратное действие: предмет-ресурс копируется из поля визуального предмета в список инвентаря, визуальный предмет уничтожается.
Ну и разумеется, поскольку это ресурсы, ты можешь организовать средствами движка файловую базу данных со всеми этими предметами.
> Я сейчас пытаюсь разобраться и не понимаю, как, почему, для чего? Поясните?
Причём тут сцены?
У тебя есть нода MeshInstance3D, например, но как нода, она меша не содержит. Меш цепляется к ней как ресурс, в соответствующем поле в инспекторе. Об этом тебе и говорили. Осознай что есть меш? Это файл на диске. Это данные, которые следует с диска загрузить.
Ты можешь так же делать свои кастомные ресурсы, например, элементы инвентаря, они как ресурс прекрасно хранят "бизнес-логику" предметов. Чтобы создать предмет в сцене, например, выкинув его из инвентаря, ты уже создаёшь ноду-префаб, олицетворяющую предмет на сцене, и у этого префаба будет поле для предмета, в которое ты скопируешь дропнутый предмет. При подборе обратное действие: предмет-ресурс копируется из поля визуального предмета в список инвентаря, визуальный предмет уничтожается.
Ну и разумеется, поскольку это ресурсы, ты можешь организовать средствами движка файловую базу данных со всеми этими предметами.
>>5113
Ты цитату обрезал и не так понял? Я имел в виду стандартный геймплей экшн эдвенчуры: почти исключительно 2D движение в 3D декорациях. В принципе, не обязательно даже свою гравитацию делать, если твои полости имеют диаметр >1 км. Делаешь скайбокс/шейдер на плоской карте.
С этого и нужно начинать - какие механики от игры требуются, что нужен переход между двумя видами гравитации? Ты там джетпак хочешь сделать и чтоб залетать внутрь толщехода на джетпаке как пчела?
Если она горячая - там должен быть колоссальный диаметр полости. Если полость мелкая, то свечение наверняка из-за какой-нибудь люминесценции, т.е. "микрозвезда" на самом деле прохладная.
Во-первых, такие астероиды лучше не делать через RigidBody3D, т.к. гарантированно будут глюки; делай StaticBody3D. Во-вторых, для такой сцены наверняка понадобится колоссальный (по меркам видеоигр) диаметр, который будет конфликтовать с физикой. Примерно с диаметра 8 км начинаются проблемы с вещественными числами одинарной точности, т.е. потребуется как минимум компилировать с double. Однако даже с double физические движки плохо переваривают огромные объекты. Много проблем.
Короче, мне кажется, ты хочешь физически точную симуляцию, где она скорее всего окажется слишком дорогой и недостаточно стабильной для игры. Много физических песочниц изобретают свой собственный физический движок для их конкретных симуляций.
>>вся суть игры в этих полостях - action adventure
>Вообще-то не совсем
Ты цитату обрезал и не так понял? Я имел в виду стандартный геймплей экшн эдвенчуры: почти исключительно 2D движение в 3D декорациях. В принципе, не обязательно даже свою гравитацию делать, если твои полости имеют диаметр >1 км. Делаешь скайбокс/шейдер на плоской карте.
>можно много механик сделать.
С этого и нужно начинать - какие механики от игры требуются, что нужен переход между двумя видами гравитации? Ты там джетпак хочешь сделать и чтоб залетать внутрь толщехода на джетпаке как пчела?
>Лететь к микрозвезде на самолёте
Если она горячая - там должен быть колоссальный диаметр полости. Если полость мелкая, то свечение наверняка из-за какой-нибудь люминесценции, т.е. "микрозвезда" на самом деле прохладная.
>вращаться вокруг центральной микрозвезды на орбитальной механике несколько каменюк
Во-первых, такие астероиды лучше не делать через RigidBody3D, т.к. гарантированно будут глюки; делай StaticBody3D. Во-вторых, для такой сцены наверняка понадобится колоссальный (по меркам видеоигр) диаметр, который будет конфликтовать с физикой. Примерно с диаметра 8 км начинаются проблемы с вещественными числами одинарной точности, т.е. потребуется как минимум компилировать с double. Однако даже с double физические движки плохо переваривают огромные объекты. Много проблем.
Короче, мне кажется, ты хочешь физически точную симуляцию, где она скорее всего окажется слишком дорогой и недостаточно стабильной для игры. Много физических песочниц изобретают свой собственный физический движок для их конкретных симуляций.
>>5111
Английский знаешь? Читай документацию:
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 - это дерево сцены + сериализация.
Выбирай то, что тебе удобнее, но не более того.
>как, почему, для чего? Поясните?
Английский знаешь? Читай документацию:
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 - это дерево сцены + сериализация.
Выбирай то, что тебе удобнее, но не более того.
>>5111
Английский знаешь? Читай документацию:
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 - это дерево сцены + сериализация.
Выбирай то, что тебе удобнее, но не более того.
>как, почему, для чего? Поясните?
Английский знаешь? Читай документацию:
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 - это дерево сцены + сериализация.
Выбирай то, что тебе удобнее, но не более того.
>>5142
Меньше.
Да, ХЗ, надо уточнить что именно я не понял в том что ты понял о том, каковой будет моя игра? Ты просто очень уверенно её описываешь, впору уже и мне поучиться у тебя геймдизайну.
Механики объяснены сюжетом, сюжет объяснён механиками. В полостях мы перемещаемся, собирая ресурсы, созерцая виды полостей изнутри. В тольщеходе, чтобы не висеть в невесомости (потому что между полостями невесомость), кабина вращается, создавая искусственное тяготение.
Не должен. Во вселенной наоборот и физика наоборот. Микрозвёзды реальны. Светят, греют. И не излучают радиацию!
Ага. И двигать статики по орбитам, да? Разумеется на удалении будут вовсе не физикбоди двигаться, а просто меши.
Да, на таких диаметров придётся что-то думать с трюками и лодами.
> твои полости имеют диаметр >1 км
Меньше.
> не так понял?
Да, ХЗ, надо уточнить что именно я не понял в том что ты понял о том, каковой будет моя игра? Ты просто очень уверенно её описываешь, впору уже и мне поучиться у тебя геймдизайну.
> какие механики от игры требуются, что нужен переход между двумя видами гравитации?
Механики объяснены сюжетом, сюжет объяснён механиками. В полостях мы перемещаемся, собирая ресурсы, созерцая виды полостей изнутри. В тольщеходе, чтобы не висеть в невесомости (потому что между полостями невесомость), кабина вращается, создавая искусственное тяготение.
> Если она горячая - там должен быть колоссальный диаметр полости.
Не должен. Во вселенной наоборот и физика наоборот. Микрозвёзды реальны. Светят, греют. И не излучают радиацию!
> такие астероиды лучше не делать через RigidBody3D, т.к. гарантированно будут глюки; делай StaticBody3D.
Ага. И двигать статики по орбитам, да? Разумеется на удалении будут вовсе не физикбоди двигаться, а просто меши.
> с диаметра 8 км начинаются проблемы
Да, на таких диаметров придётся что-то думать с трюками и лодами.
>>5158
Да ты тут несколько лет её описывал, я запомнил. Концептуально мне она понравилась когда-то, вот и запомнил, но делать самому вообще не хотелось. Да, видение у нас отличается, но всё же.
Возможно, я что-то не так запомнил, или ты сам недостаточно точно описывал в прошлом. Но в те времена ты не упоминал полёты внутри полостей.
Ну, у меня прототипы есть, в которые мне приятно поиграть время от времени... И я не удаляю их от внезапного различия фантазии с реальностью.
Это лор, а не механика. Вопрос в том, зачем тебе бесшовный переход между кабиной и полостью? Я представляю шлюз в космическом корабле или в подводной лодке. Посмотри, например, GTA Online: подводная лодка по сути неподвижное здание, всё перемещение состоит из череды телепортаций, и физическое "тело" лодки не зависит от "интерьера". Подобные упрощения важны для стабильности.
Тогда ты можешь запросто сделать и так, что якобы горячая звезда не сжигает тебя. Вопрос тут в другом: зачем жителям полости нужны полёты? Тем более в полости диаметром меньше 1 км (маловато будет).
Как, по-твоему, делают двигающиеся платформы в платформерах? Это статикбоди на фиксированных маршрутах. Реалистичная орбита стабильна, её не обязательно симулировать в реальном времени.
Алсо, если ты хочешь встать на такой астероид:
CharacterBody3D <-> AnimatableBody3D: терпимо.
CharacterBody3D <-> RigidBody3D: полный пипец.
С RigidBody3D <-> RigidBody3D тоже проблемы...
Т.е. для стабильности тебе нужны статикбоди.
Есть один трюк, как подружить всё это, но нужно сначала определиться, нужны ли игре RigidBody3D.
>очень уверенно её описываешь
Да ты тут несколько лет её описывал, я запомнил. Концептуально мне она понравилась когда-то, вот и запомнил, но делать самому вообще не хотелось. Да, видение у нас отличается, но всё же.
Возможно, я что-то не так запомнил, или ты сам недостаточно точно описывал в прошлом. Но в те времена ты не упоминал полёты внутри полостей.
>поучиться у тебя геймдизайну
Ну, у меня прототипы есть, в которые мне приятно поиграть время от времени... И я не удаляю их от внезапного различия фантазии с реальностью.
>кабина вращается
Это лор, а не механика. Вопрос в том, зачем тебе бесшовный переход между кабиной и полостью? Я представляю шлюз в космическом корабле или в подводной лодке. Посмотри, например, GTA Online: подводная лодка по сути неподвижное здание, всё перемещение состоит из череды телепортаций, и физическое "тело" лодки не зависит от "интерьера". Подобные упрощения важны для стабильности.
>Во вселенной наоборот и физика наоборот
Тогда ты можешь запросто сделать и так, что якобы горячая звезда не сжигает тебя. Вопрос тут в другом: зачем жителям полости нужны полёты? Тем более в полости диаметром меньше 1 км (маловато будет).
>двигать статики по орбитам
Как, по-твоему, делают двигающиеся платформы в платформерах? Это статикбоди на фиксированных маршрутах. Реалистичная орбита стабильна, её не обязательно симулировать в реальном времени.
Алсо, если ты хочешь встать на такой астероид:
CharacterBody3D <-> AnimatableBody3D: терпимо.
CharacterBody3D <-> RigidBody3D: полный пипец.
С RigidBody3D <-> RigidBody3D тоже проблемы...
Т.е. для стабильности тебе нужны статикбоди.
Есть один трюк, как подружить всё это, но нужно сначала определиться, нужны ли игре RigidBody3D.
>CharacterBody3D <-> RigidBody3D: полный пипец.
С чего бы? Просто пишешь дополнительный код который контролирует и сглаживает косяки.
>>5272
Если б это был простой код, то он уже был бы в физическом движке - для всех, из коробки.
Разработчики движка сделали вот этот класс:
https://docs.godotengine.org/en/stable/classes/class_animatablebody3d.html
Специально для ситуаций типа "CharacterBody3D стоит на чём-то, что движется".
И нет, это не проблема Godot - в Unity с её Nvidia PhysX те же проблемы.
Упомянутый трюк, чтобы решить большинство возникающих проблем: когда игрок наступает на RigidBody3D, его физическое тело телепортируется в определённое место с секретной скрытой (невидимой) StaticBody3D версией подвижного тела, которая повторяет его форму, но остаётся неподвижной. Визуальная моделька (с камерой) игрока движется в локальной системе координат RigidBody3D, копируя движения физического тела в системе координат неподвижной копии. Если игрок покидает подвижное тело, всё возвращается в нормальный режим. Этот трюк позволяет более-менее стабильно избежать 99% проблем с физикой, позволив игроку двигаться по поверхности движущегося RigidyBody3D.
Естественно, это весьма специфичное решение, которое не выйдет масштабировать для всех ситуаций, поэтому из коробки в Godot его никогда не будет - каждый делает сам под свою игру. Плюс создание статичной копии увеличивает нагрузку на движок, в зависимости от сложности подвижной модели.
Алсо, движение по орбитам малого радиуса всё сильно усложняет в плане физического взаимодействия. AnimatableBody3D неплохо справляется только с линейным движением, на поворотах CharacterBody3D будет неизбежно соскальзывать с него. Лучше десять раз подумать, прежде чем ввязываться в это...
Речь в том числе про Jolt, если что. У него меньше косяков, но эта проблема фундаментальная.
>Просто
>код который контролирует и сглаживает косяки
Если б это был простой код, то он уже был бы в физическом движке - для всех, из коробки.
Разработчики движка сделали вот этот класс:
https://docs.godotengine.org/en/stable/classes/class_animatablebody3d.html
Специально для ситуаций типа "CharacterBody3D стоит на чём-то, что движется".
И нет, это не проблема Godot - в Unity с её Nvidia PhysX те же проблемы.
Упомянутый трюк, чтобы решить большинство возникающих проблем: когда игрок наступает на RigidBody3D, его физическое тело телепортируется в определённое место с секретной скрытой (невидимой) StaticBody3D версией подвижного тела, которая повторяет его форму, но остаётся неподвижной. Визуальная моделька (с камерой) игрока движется в локальной системе координат RigidBody3D, копируя движения физического тела в системе координат неподвижной копии. Если игрок покидает подвижное тело, всё возвращается в нормальный режим. Этот трюк позволяет более-менее стабильно избежать 99% проблем с физикой, позволив игроку двигаться по поверхности движущегося RigidyBody3D.
Естественно, это весьма специфичное решение, которое не выйдет масштабировать для всех ситуаций, поэтому из коробки в Godot его никогда не будет - каждый делает сам под свою игру. Плюс создание статичной копии увеличивает нагрузку на движок, в зависимости от сложности подвижной модели.
Алсо, движение по орбитам малого радиуса всё сильно усложняет в плане физического взаимодействия. AnimatableBody3D неплохо справляется только с линейным движением, на поворотах CharacterBody3D будет неизбежно соскальзывать с него. Лучше десять раз подумать, прежде чем ввязываться в это...
Речь в том числе про Jolt, если что. У него меньше косяков, но эта проблема фундаментальная.
>>5342
Забыл сказать, не обязательно делать их точными копиями. На самом деле, основная нагрузка на движок идёт от сложных RigidBody3D, тогда как StaticBody3D практически бесплатны, пока с ними никто не взаимодействует, и могут иметь существенно более сложные формы коллизий. Таким образом, можно сделать простенький RigidBody3D для обработки движения и столкновений с другими простыми объектами, а секретный StaticBody3D сделать сколь угодно сложным для взаимодействия с CharacterBody3D. Визуально игрок не заметит разницы, пока что-то не столкнётся с более грубым RigidBody3D (скорее всего будет выглядеть как столкновение с невидимой стеной, сквозь которую игрок свободно проходит).
Т.е. это не только вопрос стабильности движения, но и производительности игры.
>StaticBody3D версией подвижного тела, которая повторяет
>создание статичной копии увеличивает нагрузку
Забыл сказать, не обязательно делать их точными копиями. На самом деле, основная нагрузка на движок идёт от сложных RigidBody3D, тогда как StaticBody3D практически бесплатны, пока с ними никто не взаимодействует, и могут иметь существенно более сложные формы коллизий. Таким образом, можно сделать простенький RigidBody3D для обработки движения и столкновений с другими простыми объектами, а секретный StaticBody3D сделать сколь угодно сложным для взаимодействия с CharacterBody3D. Визуально игрок не заметит разницы, пока что-то не столкнётся с более грубым RigidBody3D (скорее всего будет выглядеть как столкновение с невидимой стеной, сквозь которую игрок свободно проходит).
Т.е. это не только вопрос стабильности движения, но и производительности игры.
>>5173
Щас бы воспринимать шутеечки уровня /б/ всерьёз.
Во-первых, бесшовность это современность. Уже лет 5 как на игры с экранами загрузки смотрят свирепо и с недоумением. Кроме того, бесшовная игра не означает что все локации загружены одновременно. Запускается анимация открытия гермодвери - и в фоне грузится локация. Пока толщеход стоит на месте, то гравитация никуда не переключается, очевидно. Садишься в кресло пилота и запускается анимация запуска машины, соответственно здесь происходят все переключения, ловко спрятанные от игрока.
Именно так, кабина толщехода будет отдельной лобби-локацией, которая по сути будет прятать переключение между полость-локациями. Никакого реального движения огромной горнодобывающей машины здесь проектироваться не будет, просто потому что мы этого ничего согласно лору видеть не можем.
Как же ты прицепился к этому. Придётся подробнее пояснять. Первичная материя (ПМ, тёмная материя наоборот, светлая материя) представляет собой хрупкий, твёрдый, белый светящийся кристалл, в котором сконцентрирована энергия, сконцентрирована большая часть массы, заполняющий собой всю Вселенную. Но гораздо более важно другое. По правилам лора бесконечная ПМ обладает бесконечной же гравитацией (или настолько большой, что не поддаётся измерению). Тем не менее никого не расплющивает, потому что бесконечность равномерно распределена со всех сторон. Полости в ПМ создают гравитационный градиент. Слишком мелкие пустоты влияния не оказывают, например, толщеход посреди тоннеля в толще слишком мал для Вселенной и внутри него невесомость. Потому нужно вращением кабины создавать искусственное тяготение. Однако в крупных пустотах начинается эффект, при котором от пустоты отталкивается вся вторичная материя (ВМ, вещества таблицы Менделеева-Наоборотского). При этом от центра полости отталкиваешься сильнее всего. К ней невозможно приблизиться. Догадываешься уже, что я напишу дальше? Белая дыра! ПМ ведёт себя иначе. Поскольку она обладает большей частью массы вселенной, она наоборот, оказавшись в пустой полости стремится занять одно из двух энергетически выгодных положений, либо прилипнуть к внешней кромке, либо упасть в центр полости. Между этими двумя крайностями ПМ пребывает в собственной невесомости. Мелкие кристаллы ПМ убийственны. Их нельзя трогать - моментум в море. Разряд в миллионы вольт поджаривает как котлету. Что уж говорить о фрагментах диаметром в сотни метров, висящие в центрах полостей. Возникающие внутри силы заставляют их излучать энергию, которая впитывается в толщу на кромке. Микрозвезда не может упасть из центра на кромку, но может излучать энергию, пока не испарится.
У этого механизма есть ещё один полезный эффект. Добытые в толще кристаллы несмотря на свою огромную массу и плотность, внутри полости выровнены по тяготению и пребывают в невесомости. Притягивать их начинает либо у кромки, либо у центра. Поэтому невозможно силами простых смертных оторвать от толщи крупный фрагмент. Просто масса огромна, ты его просто не поднимешь. Поэтому используются мелкие камешки, которые быстро испаряются и которые надо часто менять. Таким образом, если нагрузить летательный аппарат достаточным количеством рассыпухи из мелких кристаллов, они мало того что будут давать энергию для работы двигателей, так ещё и "антигравитацию". Но в центр он всё равно не долетит. Пока его конструкционные материалы отталкиваются от центра, его ядро из энергокристаллов всё сильнее притягивается. В какой-то момент аппарат просто разорвёт, ядро упадёт в центр, а обломки аппарата упадут к кромке. Кромка, я напоминаю, укрыта слоем грунта и пород из вторичной материи. Кромку мы не видим, и приблизиться к ней можем только закопавшись в глубину. Поэтому у поверхности полости энергокристаллы всё еще висят в собственной невесомости.
Существуют так же полости, в которых по всему обьёму рассортированы каменюги с ядром из ПМ, представляющие собой летающие острова, по которым скачет жопастая карлица на крюке-кошке, но это уже совсем другая история.
> я не удаляю их от внезапного различия фантазии с реальностью
Щас бы воспринимать шутеечки уровня /б/ всерьёз.
> зачем тебе бесшовный переход между кабиной и полостью?
Во-первых, бесшовность это современность. Уже лет 5 как на игры с экранами загрузки смотрят свирепо и с недоумением. Кроме того, бесшовная игра не означает что все локации загружены одновременно. Запускается анимация открытия гермодвери - и в фоне грузится локация. Пока толщеход стоит на месте, то гравитация никуда не переключается, очевидно. Садишься в кресло пилота и запускается анимация запуска машины, соответственно здесь происходят все переключения, ловко спрятанные от игрока.
> подводная лодка по сути неподвижное здание
Именно так, кабина толщехода будет отдельной лобби-локацией, которая по сути будет прятать переключение между полость-локациями. Никакого реального движения огромной горнодобывающей машины здесь проектироваться не будет, просто потому что мы этого ничего согласно лору видеть не можем.
> якобы горячая звезда не сжигает тебя
Как же ты прицепился к этому. Придётся подробнее пояснять. Первичная материя (ПМ, тёмная материя наоборот, светлая материя) представляет собой хрупкий, твёрдый, белый светящийся кристалл, в котором сконцентрирована энергия, сконцентрирована большая часть массы, заполняющий собой всю Вселенную. Но гораздо более важно другое. По правилам лора бесконечная ПМ обладает бесконечной же гравитацией (или настолько большой, что не поддаётся измерению). Тем не менее никого не расплющивает, потому что бесконечность равномерно распределена со всех сторон. Полости в ПМ создают гравитационный градиент. Слишком мелкие пустоты влияния не оказывают, например, толщеход посреди тоннеля в толще слишком мал для Вселенной и внутри него невесомость. Потому нужно вращением кабины создавать искусственное тяготение. Однако в крупных пустотах начинается эффект, при котором от пустоты отталкивается вся вторичная материя (ВМ, вещества таблицы Менделеева-Наоборотского). При этом от центра полости отталкиваешься сильнее всего. К ней невозможно приблизиться. Догадываешься уже, что я напишу дальше? Белая дыра! ПМ ведёт себя иначе. Поскольку она обладает большей частью массы вселенной, она наоборот, оказавшись в пустой полости стремится занять одно из двух энергетически выгодных положений, либо прилипнуть к внешней кромке, либо упасть в центр полости. Между этими двумя крайностями ПМ пребывает в собственной невесомости. Мелкие кристаллы ПМ убийственны. Их нельзя трогать - моментум в море. Разряд в миллионы вольт поджаривает как котлету. Что уж говорить о фрагментах диаметром в сотни метров, висящие в центрах полостей. Возникающие внутри силы заставляют их излучать энергию, которая впитывается в толщу на кромке. Микрозвезда не может упасть из центра на кромку, но может излучать энергию, пока не испарится.
У этого механизма есть ещё один полезный эффект. Добытые в толще кристаллы несмотря на свою огромную массу и плотность, внутри полости выровнены по тяготению и пребывают в невесомости. Притягивать их начинает либо у кромки, либо у центра. Поэтому невозможно силами простых смертных оторвать от толщи крупный фрагмент. Просто масса огромна, ты его просто не поднимешь. Поэтому используются мелкие камешки, которые быстро испаряются и которые надо часто менять. Таким образом, если нагрузить летательный аппарат достаточным количеством рассыпухи из мелких кристаллов, они мало того что будут давать энергию для работы двигателей, так ещё и "антигравитацию". Но в центр он всё равно не долетит. Пока его конструкционные материалы отталкиваются от центра, его ядро из энергокристаллов всё сильнее притягивается. В какой-то момент аппарат просто разорвёт, ядро упадёт в центр, а обломки аппарата упадут к кромке. Кромка, я напоминаю, укрыта слоем грунта и пород из вторичной материи. Кромку мы не видим, и приблизиться к ней можем только закопавшись в глубину. Поэтому у поверхности полости энергокристаллы всё еще висят в собственной невесомости.
Существуют так же полости, в которых по всему обьёму рассортированы каменюги с ядром из ПМ, представляющие собой летающие острова, по которым скачет жопастая карлица на крюке-кошке, но это уже совсем другая история.
>>5173
Щас бы воспринимать шутеечки уровня /б/ всерьёз.
Во-первых, бесшовность это современность. Уже лет 5 как на игры с экранами загрузки смотрят свирепо и с недоумением. Кроме того, бесшовная игра не означает что все локации загружены одновременно. Запускается анимация открытия гермодвери - и в фоне грузится локация. Пока толщеход стоит на месте, то гравитация никуда не переключается, очевидно. Садишься в кресло пилота и запускается анимация запуска машины, соответственно здесь происходят все переключения, ловко спрятанные от игрока.
Именно так, кабина толщехода будет отдельной лобби-локацией, которая по сути будет прятать переключение между полость-локациями. Никакого реального движения огромной горнодобывающей машины здесь проектироваться не будет, просто потому что мы этого ничего согласно лору видеть не можем.
Как же ты прицепился к этому. Придётся подробнее пояснять. Первичная материя (ПМ, тёмная материя наоборот, светлая материя) представляет собой хрупкий, твёрдый, белый светящийся кристалл, в котором сконцентрирована энергия, сконцентрирована большая часть массы, заполняющий собой всю Вселенную. Но гораздо более важно другое. По правилам лора бесконечная ПМ обладает бесконечной же гравитацией (или настолько большой, что не поддаётся измерению). Тем не менее никого не расплющивает, потому что бесконечность равномерно распределена со всех сторон. Полости в ПМ создают гравитационный градиент. Слишком мелкие пустоты влияния не оказывают, например, толщеход посреди тоннеля в толще слишком мал для Вселенной и внутри него невесомость. Потому нужно вращением кабины создавать искусственное тяготение. Однако в крупных пустотах начинается эффект, при котором от пустоты отталкивается вся вторичная материя (ВМ, вещества таблицы Менделеева-Наоборотского). При этом от центра полости отталкиваешься сильнее всего. К ней невозможно приблизиться. Догадываешься уже, что я напишу дальше? Белая дыра! ПМ ведёт себя иначе. Поскольку она обладает большей частью массы вселенной, она наоборот, оказавшись в пустой полости стремится занять одно из двух энергетически выгодных положений, либо прилипнуть к внешней кромке, либо упасть в центр полости. Между этими двумя крайностями ПМ пребывает в собственной невесомости. Мелкие кристаллы ПМ убийственны. Их нельзя трогать - моментум в море. Разряд в миллионы вольт поджаривает как котлету. Что уж говорить о фрагментах диаметром в сотни метров, висящие в центрах полостей. Возникающие внутри силы заставляют их излучать энергию, которая впитывается в толщу на кромке. Микрозвезда не может упасть из центра на кромку, но может излучать энергию, пока не испарится.
У этого механизма есть ещё один полезный эффект. Добытые в толще кристаллы несмотря на свою огромную массу и плотность, внутри полости выровнены по тяготению и пребывают в невесомости. Притягивать их начинает либо у кромки, либо у центра. Поэтому невозможно силами простых смертных оторвать от толщи крупный фрагмент. Просто масса огромна, ты его просто не поднимешь. Поэтому используются мелкие камешки, которые быстро испаряются и которые надо часто менять. Таким образом, если нагрузить летательный аппарат достаточным количеством рассыпухи из мелких кристаллов, они мало того что будут давать энергию для работы двигателей, так ещё и "антигравитацию". Но в центр он всё равно не долетит. Пока его конструкционные материалы отталкиваются от центра, его ядро из энергокристаллов всё сильнее притягивается. В какой-то момент аппарат просто разорвёт, ядро упадёт в центр, а обломки аппарата упадут к кромке. Кромка, я напоминаю, укрыта слоем грунта и пород из вторичной материи. Кромку мы не видим, и приблизиться к ней можем только закопавшись в глубину. Поэтому у поверхности полости энергокристаллы всё еще висят в собственной невесомости.
Существуют так же полости, в которых по всему обьёму рассортированы каменюги с ядром из ПМ, представляющие собой летающие острова, по которым скачет жопастая карлица на крюке-кошке, но это уже совсем другая история.
> я не удаляю их от внезапного различия фантазии с реальностью
Щас бы воспринимать шутеечки уровня /б/ всерьёз.
> зачем тебе бесшовный переход между кабиной и полостью?
Во-первых, бесшовность это современность. Уже лет 5 как на игры с экранами загрузки смотрят свирепо и с недоумением. Кроме того, бесшовная игра не означает что все локации загружены одновременно. Запускается анимация открытия гермодвери - и в фоне грузится локация. Пока толщеход стоит на месте, то гравитация никуда не переключается, очевидно. Садишься в кресло пилота и запускается анимация запуска машины, соответственно здесь происходят все переключения, ловко спрятанные от игрока.
> подводная лодка по сути неподвижное здание
Именно так, кабина толщехода будет отдельной лобби-локацией, которая по сути будет прятать переключение между полость-локациями. Никакого реального движения огромной горнодобывающей машины здесь проектироваться не будет, просто потому что мы этого ничего согласно лору видеть не можем.
> якобы горячая звезда не сжигает тебя
Как же ты прицепился к этому. Придётся подробнее пояснять. Первичная материя (ПМ, тёмная материя наоборот, светлая материя) представляет собой хрупкий, твёрдый, белый светящийся кристалл, в котором сконцентрирована энергия, сконцентрирована большая часть массы, заполняющий собой всю Вселенную. Но гораздо более важно другое. По правилам лора бесконечная ПМ обладает бесконечной же гравитацией (или настолько большой, что не поддаётся измерению). Тем не менее никого не расплющивает, потому что бесконечность равномерно распределена со всех сторон. Полости в ПМ создают гравитационный градиент. Слишком мелкие пустоты влияния не оказывают, например, толщеход посреди тоннеля в толще слишком мал для Вселенной и внутри него невесомость. Потому нужно вращением кабины создавать искусственное тяготение. Однако в крупных пустотах начинается эффект, при котором от пустоты отталкивается вся вторичная материя (ВМ, вещества таблицы Менделеева-Наоборотского). При этом от центра полости отталкиваешься сильнее всего. К ней невозможно приблизиться. Догадываешься уже, что я напишу дальше? Белая дыра! ПМ ведёт себя иначе. Поскольку она обладает большей частью массы вселенной, она наоборот, оказавшись в пустой полости стремится занять одно из двух энергетически выгодных положений, либо прилипнуть к внешней кромке, либо упасть в центр полости. Между этими двумя крайностями ПМ пребывает в собственной невесомости. Мелкие кристаллы ПМ убийственны. Их нельзя трогать - моментум в море. Разряд в миллионы вольт поджаривает как котлету. Что уж говорить о фрагментах диаметром в сотни метров, висящие в центрах полостей. Возникающие внутри силы заставляют их излучать энергию, которая впитывается в толщу на кромке. Микрозвезда не может упасть из центра на кромку, но может излучать энергию, пока не испарится.
У этого механизма есть ещё один полезный эффект. Добытые в толще кристаллы несмотря на свою огромную массу и плотность, внутри полости выровнены по тяготению и пребывают в невесомости. Притягивать их начинает либо у кромки, либо у центра. Поэтому невозможно силами простых смертных оторвать от толщи крупный фрагмент. Просто масса огромна, ты его просто не поднимешь. Поэтому используются мелкие камешки, которые быстро испаряются и которые надо часто менять. Таким образом, если нагрузить летательный аппарат достаточным количеством рассыпухи из мелких кристаллов, они мало того что будут давать энергию для работы двигателей, так ещё и "антигравитацию". Но в центр он всё равно не долетит. Пока его конструкционные материалы отталкиваются от центра, его ядро из энергокристаллов всё сильнее притягивается. В какой-то момент аппарат просто разорвёт, ядро упадёт в центр, а обломки аппарата упадут к кромке. Кромка, я напоминаю, укрыта слоем грунта и пород из вторичной материи. Кромку мы не видим, и приблизиться к ней можем только закопавшись в глубину. Поэтому у поверхности полости энергокристаллы всё еще висят в собственной невесомости.
Существуют так же полости, в которых по всему обьёму рассортированы каменюги с ядром из ПМ, представляющие собой летающие острова, по которым скачет жопастая карлица на крюке-кошке, но это уже совсем другая история.
>>5342
Смотри, я считаю физический солвер просто сложной формулой, в которую не лезу.
Что влияет на происходящее? Входные данные, сама формула, результат на выходе.
В программировании-математике есть и другие функций, которые не определены для всех аргументов.
Например, atan2 это обертка на arctan, которая учитывает разные изначальные ситуации.
Другой пример - snap to pixels, когда можно использовать полученные результаты с плавающей точкой, а потом округлять их до целых координат.
То есть ты можешь манипулировать входными данными (менять что-то в форме, менять координаты объектов) до рассчетов, и ты можешь корректировать результаты после того как их посчитал движок.
В этом примере >>4751 упомянута ситуация когда происходит резкий рывок на несколько метров. Может быть ошибка в моем коде, может быть неудачная форма коллайдера к такому приводит, может ошибка внутри физики. Выяснять это займет дни. Поэтому я написал простейший костыль в несколько строк. Потому что я знаю какие я хочу наложить ограничения на результат - ограничить максимальную скорость. В принципе это всегда полезно в игре с физикой, наложить лимиты на линейную и вращательную скорость объектов. Именно потому что в компьютерной симуляции часто бывают ситуации когда какое-то значение приближается к нулю, а потом где-то на это число делят и получается скорость близкая к бесконечности.
Вот о чем я говорю. Это может быть простое решение для конкретно твоей игры, потому что ты знаешь какие в ней могут создаться ситуации. А общего решения, которое вставят в сам движок, может и не существовать вовсе.
Как разработчик, всегда будь командиром компьютера, а не рабом его встроенных функций. В данном случае физический поддвижок - просто инструмент который выполняет рассчеты которые нужны тебе в твоей игре, а не какой то бог который решает как все работает а ты лишь подстраиваешься.
Смотри, я считаю физический солвер просто сложной формулой, в которую не лезу.
Что влияет на происходящее? Входные данные, сама формула, результат на выходе.
В программировании-математике есть и другие функций, которые не определены для всех аргументов.
Например, atan2 это обертка на arctan, которая учитывает разные изначальные ситуации.
Другой пример - snap to pixels, когда можно использовать полученные результаты с плавающей точкой, а потом округлять их до целых координат.
То есть ты можешь манипулировать входными данными (менять что-то в форме, менять координаты объектов) до рассчетов, и ты можешь корректировать результаты после того как их посчитал движок.
В этом примере >>4751 упомянута ситуация когда происходит резкий рывок на несколько метров. Может быть ошибка в моем коде, может быть неудачная форма коллайдера к такому приводит, может ошибка внутри физики. Выяснять это займет дни. Поэтому я написал простейший костыль в несколько строк. Потому что я знаю какие я хочу наложить ограничения на результат - ограничить максимальную скорость. В принципе это всегда полезно в игре с физикой, наложить лимиты на линейную и вращательную скорость объектов. Именно потому что в компьютерной симуляции часто бывают ситуации когда какое-то значение приближается к нулю, а потом где-то на это число делят и получается скорость близкая к бесконечности.
Вот о чем я говорю. Это может быть простое решение для конкретно твоей игры, потому что ты знаешь какие в ней могут создаться ситуации. А общего решения, которое вставят в сам движок, может и не существовать вовсе.
Как разработчик, всегда будь командиром компьютера, а не рабом его встроенных функций. В данном случае физический поддвижок - просто инструмент который выполняет рассчеты которые нужны тебе в твоей игре, а не какой то бог который решает как все работает а ты лишь подстраиваешься.
>>5402
По лору в подводной лодке тоже не видят что в ней снаружи, но это же самое интересное что могут предложить компьютерные игры, "вид снаружи" туда, куда в реальности не заглянуть. Поэтому же в играх любят и всякие статы, характеристики, шкалы здоровья. Мало интересно играть в стратегию которая бы точно симулировала только как ты сидишь за столом и получаешь текстовые донесения, интереснее видеть все, иногда и отключая туман войны, чтобы видеть что там происходит и получить представление.
> Никакого реального движения огромной горнодобывающей машины здесь проектироваться не будет, просто потому что мы этого ничего согласно лору видеть не можем.
По лору в подводной лодке тоже не видят что в ней снаружи, но это же самое интересное что могут предложить компьютерные игры, "вид снаружи" туда, куда в реальности не заглянуть. Поэтому же в играх любят и всякие статы, характеристики, шкалы здоровья. Мало интересно играть в стратегию которая бы точно симулировала только как ты сидишь за столом и получаешь текстовые донесения, интереснее видеть все, иногда и отключая туман войны, чтобы видеть что там происходит и получить представление.
>>5402
@
Т.е. шов есть. Так что мешает поменять контроллер персонажа?
Думаю, два разных контроллера - оптимальнее, чем один универсальный...
Тебе не кажется, что ты слишком глубоко в свой лор забурился? Лор игры не должен мешать фану игрока. Если окажется, что ходить по поверхности "звезды" - это фаново, что будешь делать? Многие игры с лавой дают возможность получить неуязвимость к лаве, потому что бегать по лаве - фан. Можно ограничить эту возможность по времени или по сюжету, но не стоит ограничивать это лором, когда у тебя ещё игры толком нет, чтобы такое заранее запрещать. Игра - это не экранизация книги, а интерактивный опыт, и дизайнить его нужно исходя из опыта игрока (тебя, твоих друзей, усреднённого игрока из целевой аудитории), а не из какого-то лора. Самые успешные игры клали болт на свой собственный лор, позволяя игроку творить почти что угодно. Игрок хочет пробурить небеса? Пожалуйста - вот тебе бур, вот небеса, иди бури. А лор в свою очередь адаптируется под игрока: если игроки хотят бурить небеса и получают от этого безудержный ФАН, значит небосвод каменный и бурится, а всё остальное значения не имеет. Если ты запрещаешь игрокам делать что-то из-за того, что у тебя по лору что-то там не поддаётся бурению (потому что ты так сказал), то ты рискуешь сделать унылую игру. Почему, мистер Аноним, почему? Во имя чего?
Не, херня идея.
>>5405
Который АЖТРИСЁТ, когда ты в него вводишь неизвестные заранее данные.
Это возможно только в игре, где шаг в сторону ступить нельзя без катсцены.
>бесшовность это современность
@
>запускается анимация запуска машины
>будет отдельной лобби-локацией
>Никакого реального движения
Т.е. шов есть. Так что мешает поменять контроллер персонажа?
Думаю, два разных контроллера - оптимальнее, чем один универсальный...
>Придётся подробнее пояснять
>По правилам лора
Тебе не кажется, что ты слишком глубоко в свой лор забурился? Лор игры не должен мешать фану игрока. Если окажется, что ходить по поверхности "звезды" - это фаново, что будешь делать? Многие игры с лавой дают возможность получить неуязвимость к лаве, потому что бегать по лаве - фан. Можно ограничить эту возможность по времени или по сюжету, но не стоит ограничивать это лором, когда у тебя ещё игры толком нет, чтобы такое заранее запрещать. Игра - это не экранизация книги, а интерактивный опыт, и дизайнить его нужно исходя из опыта игрока (тебя, твоих друзей, усреднённого игрока из целевой аудитории), а не из какого-то лора. Самые успешные игры клали болт на свой собственный лор, позволяя игроку творить почти что угодно. Игрок хочет пробурить небеса? Пожалуйста - вот тебе бур, вот небеса, иди бури. А лор в свою очередь адаптируется под игрока: если игроки хотят бурить небеса и получают от этого безудержный ФАН, значит небосвод каменный и бурится, а всё остальное значения не имеет. Если ты запрещаешь игрокам делать что-то из-за того, что у тебя по лору что-то там не поддаётся бурению (потому что ты так сказал), то ты рискуешь сделать унылую игру. Почему, мистер Аноним, почему? Во имя чего?
>каменюги с ядром из ПМ
>летающие острова
Не, херня идея.
>>5405
>физический поддвижок - просто инструмент
Который АЖТРИСЁТ, когда ты в него вводишь неизвестные заранее данные.
>ты знаешь какие в ней могут создаться ситуации
Это возможно только в игре, где шаг в сторону ступить нельзя без катсцены.
>>5575
Я не он, но твоя проблема в версии движка. Скачай 4.4:
https://godotengine.org/article/dev-snapshot-godot-4-4-beta-3/#downloads
С версии 4.4 ресурсы юзают uid:// вместо res://, так что 4.3 их просто не видит.
Я не он, но твоя проблема в версии движка. Скачай 4.4:
https://godotengine.org/article/dev-snapshot-godot-4-4-beta-3/#downloads
С версии 4.4 ресурсы юзают uid:// вместо res://, так что 4.3 их просто не видит.
>>5686
Кто-то другой насрал тебе в штанишки?
Кто-то другой насрал тебе в штанишки?
>>5730
В 4-ке есть ##, показывается при наведении мыши. При автокомплите показывается сигнатура, типы аргументов
В 4-ке есть ##, показывается при наведении мыши. При автокомплите показывается сигнатура, типы аргументов
>>5578
А да, правда, я делал в самой последней бете, не в курсе был что проект предыдущими не откроется, хорошо что узнал, на будущее.
По идее открыть можно как то, отредактировав tscn в блокноте наверное убрав все uid чтобы они перегенерились
А да, правда, я делал в самой последней бете, не в курсе был что проект предыдущими не откроется, хорошо что узнал, на будущее.
По идее открыть можно как то, отредактировав tscn в блокноте наверное убрав все uid чтобы они перегенерились
>>5730
Вот здесь в подробностях:
https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/gdscript_documentation_comments.html
Вкратце:
- начинаешь с ## на каждой строчке;
- описание класса - через пустую строку:
- описание функции - перед её заголовком;
- есть BB-коды как на дваче (RichTextLabel);
- можно добавить @deprecated и @experimental;
- можно открыть как встроенную справку (F1);
- можно видеть как всплывающую подсказку:
- - при наведении на строчку кода в редакторе;
- - при наведении на поле в инспекторе нод.
Но я недавно обнаружил досадный баг: если сбросил кэш проекта (в папке .godot), то твоя документация перестаёт распознаваться, пока ты не сохранишь скрипты проекта повторно. Также иногда она не обновляется почему-то, или с долгой задержкой.
Некоторые поля отображаются "нет документации", некоторые - не отображаются, пока не напишешь комментарий к ним. Как я понял, это типа скрытие приватных полей, но я не помню, что считается "приватным": по идее, то, что начинается с "_", однако некоторые поля с "_" в любом случае отображаются.
В общем, нюансы есть, но лично мне нравится.
Вот здесь в подробностях:
https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/gdscript_documentation_comments.html
Вкратце:
- начинаешь с ## на каждой строчке;
- описание класса - через пустую строку:
>## Вкратце о классе
>##
>## Подробнее о классе
- описание функции - перед её заголовком;
- есть BB-коды как на дваче (RichTextLabel);
- можно добавить @deprecated и @experimental;
- можно открыть как встроенную справку (F1);
- можно видеть как всплывающую подсказку:
- - при наведении на строчку кода в редакторе;
- - при наведении на поле в инспекторе нод.
Но я недавно обнаружил досадный баг: если сбросил кэш проекта (в папке .godot), то твоя документация перестаёт распознаваться, пока ты не сохранишь скрипты проекта повторно. Также иногда она не обновляется почему-то, или с долгой задержкой.
Некоторые поля отображаются "нет документации", некоторые - не отображаются, пока не напишешь комментарий к ним. Как я понял, это типа скрытие приватных полей, но я не помню, что считается "приватным": по идее, то, что начинается с "_", однако некоторые поля с "_" в любом случае отображаются.
В общем, нюансы есть, но лично мне нравится.
>>5764
Когда открываешь проект из ≤4.3 версии в 4.4, тебя встречает специальное окошко (пишу по памяти):
В общем, делай бэкап перед открытием в 4.4.
Этого недостаточно. Как я понял:
1. Раньше все ссылки на ресурсы были res://. Но перемещение файла (за пределами редактора, т.е. из файлового менеджера ОС) часто ломало эти ссылки.
2. Потом ввели uid://, чтобы автоматически фиксить потерянные файлы. Но res:// всё ещё оставались, т.е. сломанные uid:// восстанавливались через res://. Нестабильность и неполная поддержка мешала полностью принять эту новую систему.
3. Теперь (после реализации uid для всех скриптов) они считают систему uid:// стабильной и поэтому избавляются от res:// в ресурсных файлах (включая .tscn). Удаление uid:// приведёт к поломке файла, и восстанавливать res:// в версиях ≤4.3 неоткуда.
Т.е. тебе придётся вручную возвращать res://. Проще восстановить предыдущую версию из бэкапа/гита.
>хорошо что узнал
Когда открываешь проект из ≤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://. Проще восстановить предыдущую версию из бэкапа/гита.
16 Кб, 1213x121>>5808
Да не, вроде пути в tscn к res:// на месте, по идее они писали что как fallback все равно работает. А в скриптах я ничего сам про uid не писал. А перетаскивать файл в скрипт я не пробовал.
Да не, вроде пути в tscn к res:// на месте, по идее они писали что как fallback все равно работает. А в скриптах я ничего сам про uid не писал. А перетаскивать файл в скрипт я не пробовал.
Может быть дело в том что я не запаковал папку .import
Но опять же по моим представлениям она и не должна распространяться с проектом, реимпорт должен делаться на месте другим. Может там надо реимпорт просто прокликать
Но опять же по моим представлениям она и не должна распространяться с проектом, реимпорт должен делаться на месте другим. Может там надо реимпорт просто прокликать
Энивей, мне не очень интересно это изучать, так как 4.4->4.3 путь не особо часто будет встречаться. (Только если кто-то заморозил версию для релиза игры и вдруг захотел новый аддон под 4.4?)
11 Кб, 293x330>>5845
А это вроде не коммент, а просто многострочный литерал, который ничему не присвоен. Некоторые языки такое не запрещают, просто это ничего не делает.
А это вроде не коммент, а просто многострочный литерал, который ничему не присвоен. Некоторые языки такое не запрещают, просто это ничего не делает.
>>5841
Её не нужно передавать, всё импортируется само.
>>5842
Естественно. Просто стабильного релиза не было.
>>5845
Нет, это обычные String, это не комментарий:
https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/gdscript_basics.html#literals
Не рекомендую использовать как комментарии.
>>5857
Вот так можно:
Тег [code] включает inline подсветку кода, подробнее:
https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/gdscript_documentation_comments.html#bbcode-and-class-reference
>не запаковал папку .import
Её не нужно передавать, всё импортируется само.
>>5842
>4.4->4.3 путь не особо часто будет встречаться
Естественно. Просто стабильного релиза не было.
>>5845
>питоно-подобноые докстринги, типа:
>"""
>Описание
>"""
Нет, это обычные String, это не комментарий:
https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/gdscript_basics.html#literals
Не рекомендую использовать как комментарии.
>>5857
>аргументы функций описать
Вот так можно:
>## Функция делает то-то и то-то.
>## [code]аргумент[/code] должен быть таким-то.
>func имя(аргумент: тип) -> тип:
Тег [code] включает inline подсветку кода, подробнее:
https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/gdscript_documentation_comments.html#bbcode-and-class-reference
>>5891
Промахнулся тредом
Промахнулся тредом
>>5886
GTA V
GTA V
>>6028
>>6029
А я наконец-то сегодня первый день без температуры. Сука 5 дней к ряду - я её сбиваю, а через пару часов опять вверх ползёт; до 38+-0.2 доходит и останавливается. Чуть голову от подушки приподнял - кружится. Делать ничего продуктивного вообще невозможно было, лежал полудемал и стримы по КСД2 слушал. Сегодня наконец-то это всё говно закончилось, я воспользовался нарисовавшимся свободным временем, открыл старый недоделанный проект и решил всё-таки доделать. Щас вот кушаю, решил в тредик заглянул.
Всем крепкого здоровья, годаны.
>>6029
А я наконец-то сегодня первый день без температуры. Сука 5 дней к ряду - я её сбиваю, а через пару часов опять вверх ползёт; до 38+-0.2 доходит и останавливается. Чуть голову от подушки приподнял - кружится. Делать ничего продуктивного вообще невозможно было, лежал полудемал и стримы по КСД2 слушал. Сегодня наконец-то это всё говно закончилось, я воспользовался нарисовавшимся свободным временем, открыл старый недоделанный проект и решил всё-таки доделать. Щас вот кушаю, решил в тредик заглянул.
Всем крепкого здоровья, годаны.
Несколько лет изучаю Godot, преимущественно 3D. Скопилась куча недоделанных и брошенных прототипов, некоторые более-менее играбельны на мой вкус, но в основном это чисто механики без контента. Понимаю, что всегда берусь за непосильные задачи, потому и забрасываю... Недооцениваю масштабность своих идей. Но что делать? Простые игры вообще не привлекает делать, я пробовал - как-то не тянет продолжать.
Как-то начал делать простейший симулятор своей вайфу (мой персонаж, никто кроме меня не сделает). Почти без графики, просто кнопки и текст. Что-то похожее я накидал за пару часов в Twine и решил, что продолжать лучше в Godot. Я хорошо знаю как всё что нужно сделать в Godot и картинки тоже могу нарисовать сам, так что технически проблем нет... Только и мотивации нет. Даже поскорее собрав прототип, установив на телефон и ежедневно с ним взаимодействуя хотя бы минуту, как-то не могу себя заставить работать конкретно над этим проектом. А грандиозные, нереализуемые моими усилиями идеи никуда не делись...
В целом, мне нравится работать в Godot, писать код на GDScript. Но заставить себя работать над чем-то - всегда тяжело. Не помогает даже "просто открыть проект и смотреть на него", я вообще редактор больше не закрываю, висит на фоне... Кто-нибудь испытывал такое? Чем компенсировали? Совсем всё бросать не хочется.
Как-то начал делать простейший симулятор своей вайфу (мой персонаж, никто кроме меня не сделает). Почти без графики, просто кнопки и текст. Что-то похожее я накидал за пару часов в Twine и решил, что продолжать лучше в Godot. Я хорошо знаю как всё что нужно сделать в Godot и картинки тоже могу нарисовать сам, так что технически проблем нет... Только и мотивации нет. Даже поскорее собрав прототип, установив на телефон и ежедневно с ним взаимодействуя хотя бы минуту, как-то не могу себя заставить работать конкретно над этим проектом. А грандиозные, нереализуемые моими усилиями идеи никуда не делись...
В целом, мне нравится работать в Godot, писать код на GDScript. Но заставить себя работать над чем-то - всегда тяжело. Не помогает даже "просто открыть проект и смотреть на него", я вообще редактор больше не закрываю, висит на фоне... Кто-нибудь испытывал такое? Чем компенсировали? Совсем всё бросать не хочется.
>>6258
Там нечего показывать - заглушка на заглушке.
И я не планирую её публиковать - это проект для себя.
Там нечего показывать - заглушка на заглушке.
И я не планирую её публиковать - это проект для себя.
>>6257
Хорошее решение - разбить свою амбициозную идею на несколько проектов, каждый из которых реализует какую-то его часть, а каждый следующий - сделанное в предыдущем и новую часть большой задумки. Так и прогресс будет ощущаться, и работать будешь над тем, что интересно
> Недооцениваю масштабность своих идей. Но что делать? Простые игры вообще не привлекает делать, я пробовал - как-то не тянет продолжать.
> А грандиозные, нереализуемые моими усилиями идеи никуда не делись...
> Но заставить себя работать над чем-то - всегда тяжело.
Хорошее решение - разбить свою амбициозную идею на несколько проектов, каждый из которых реализует какую-то его часть, а каждый следующий - сделанное в предыдущем и новую часть большой задумки. Так и прогресс будет ощущаться, и работать будешь над тем, что интересно
845 Кб, 1210x901Хотел интереса ради создать модельку из нейросетей. В игре это кристалл, который собирает ГГ. Таких кристаллов на экране у меня присутствует иногда по 100.
Сгенерил картинку, по картинке 3д. В итоге 5.5мб модель, 130к вертексов. На аналогичную у меня вручную выходит до 2к вертексов.
Сгенерил картинку, по картинке 3д. В итоге 5.5мб модель, 130к вертексов. На аналогичную у меня вручную выходит до 2к вертексов.
>>6296
При этом запрос был на лоуполи.
При этом запрос был на лоуполи.
314 Кб, 1064x512>>6296
Хоппа сделана нейросетью Trellis и в ней всего 22к вершин. Попробуй в блендере в режиме edit (tab) нажать a (select all) - f3 - merge by distance, это склеит продублировавшиечя вершины. Дальше уже decimate но он конечно дырки делать только в путь. Или dissolve vertex вручную.
Хоппа сделана нейросетью Trellis и в ней всего 22к вершин. Попробуй в блендере в режиме edit (tab) нажать a (select all) - f3 - merge by distance, это склеит продублировавшиечя вершины. Дальше уже decimate но он конечно дырки делать только в путь. Или dissolve vertex вручную.
>>6296
Также у меня сложилось впечатление что на это больше влияет процесс extract glb, чем сама генерация. Там же какие то настройки тоже есть.
Также у меня сложилось впечатление что на это больше влияет процесс extract glb, чем сама генерация. Там же какие то настройки тоже есть.
>>6296
В Trellis есть параметр на сокращение количества вершин.
В Trellis есть параметр на сокращение количества вершин.
>>6296
Ну разве что интереса ради если. Уж кристаллы-то можно и в блендере наштамповать. И 3,5 полигонов, вместо 130К!!!
Лолшто? 2К на кристалл? Это троллинг такой?
> кристалл, который собирает ГГ
> создать модельку из нейросетей
Ну разве что интереса ради если. Уж кристаллы-то можно и в блендере наштамповать. И 3,5 полигонов, вместо 130К!!!
> На аналогичную у меня вручную выходит до 2к вертексов.
Лолшто? 2К на кристалл? Это троллинг такой?
>>6535
терпи
терпи
>>6535
Я в ахуе от того, как нас держали за лохов все 90е. Сука, блять, пока на западе играли в первую плойку, нас кормили китайским клоном NES из 80х. Сука, аж трисёт.
Я в ахуе от того, как нас держали за лохов все 90е. Сука, блять, пока на западе играли в первую плойку, нас кормили китайским клоном NES из 80х. Сука, аж трисёт.
704 Кб, mp4,400x600, 0:35
>>6665
На самом деле от 2к вершин нихуя ему не будет, на вертексы уже всем похуй по большей части. Для ААА дерева в лесу 30-50к трисов это прям супер-супер средненько, не вах какой графений. Но с другой стороны дереву эти трисы реально нужны, потому что органика хитровыебанная, а вот кристаллу(который по определению является каким-то сечетанием примитивов)там уже хз нахуя.
На самом деле от 2к вершин нихуя ему не будет, на вертексы уже всем похуй по большей части. Для ААА дерева в лесу 30-50к трисов это прям супер-супер средненько, не вах какой графений. Но с другой стороны дереву эти трисы реально нужны, потому что органика хитровыебанная, а вот кристаллу(который по определению является каким-то сечетанием примитивов)там уже хз нахуя.
>>6638
главное, что мы выросли и все осознали в какой ситуации были и чего нельхя допускать
>нас кормили китайским клоном NES из 80х. Сука, аж трисёт.
главное, что мы выросли и все осознали в какой ситуации были и чего нельхя допускать
>>6684
Деревья тоже можно экономичнее, органику можно гнуть в вертекс шейдере и кору выпячиывать в фрагментном.
Деревья тоже можно экономичнее, органику можно гнуть в вертекс шейдере и кору выпячиывать в фрагментном.
>>6638
Нафик она нужна, поздние годы 2д пиксельарта >> кривое раннее недо3д
Нафик она нужна, поздние годы 2д пиксельарта >> кривое раннее недо3д
>>6718
А на удалении деревья должны заменяться на САМОЗВАНЦА)) Вчера видос английский с яндекс-нейроозвучкой смотрел. Самозванца, хехе.
А на удалении деревья должны заменяться на САМОЗВАНЦА)) Вчера видос английский с яндекс-нейроозвучкой смотрел. Самозванца, хехе.
>>6720
На амогуса
На амогуса
>>6720
Государственная машина!
Государственная машина!
>>6303
Сетку покажи. Впрочем, даже без сетки можно сказать, что
Слишком много для такого рода модельки персонажа:
- детали одежды нарисованы на меше,
- волосы слиплись в один цельный кусок,
- глаза нарисованные, нет детализации лица.
Так что там очень много лишних полигонов.
Пикрилы: чего можно добиться с 1~3k треугольников.
Алсо, считать нужно треугольники, вершин обычно меньше.
>>6684
GPU всё равно тормозить будет, если сцена избыточно сложная.
ААА - это про объём бюджета. Деньги жечь - не игры делать. Смекаешь?
Т.е. если нанять говноделов - они тебе даже за $1 млрд из говна вылепят.
Или школоту нанять за $1 млн, а $999 млн себе в карман - тоже ААА будет.
За примерами далеко ходить не надо:
GTA 5, 2013 год, $265 млн - рулит до сих пор.
Cyberpunk 2077, 2020 год, $400 млн - говно.
Т.е. бабла сожгли больше, а качество - хуже.
Сетку покажи. Впрочем, даже без сетки можно сказать, что
>22к вершин
Слишком много для такого рода модельки персонажа:
- детали одежды нарисованы на меше,
- волосы слиплись в один цельный кусок,
- глаза нарисованные, нет детализации лица.
Так что там очень много лишних полигонов.
Пикрилы: чего можно добиться с 1~3k треугольников.
Алсо, считать нужно треугольники, вершин обычно меньше.
>>6684
>на вертексы уже всем похуй по большей части
GPU всё равно тормозить будет, если сцена избыточно сложная.
>Для ААА дерева в лесу 30-50к трисов это прям
ААА - это про объём бюджета. Деньги жечь - не игры делать. Смекаешь?
Т.е. если нанять говноделов - они тебе даже за $1 млрд из говна вылепят.
Или школоту нанять за $1 млн, а $999 млн себе в карман - тоже ААА будет.
За примерами далеко ходить не надо:
GTA 5, 2013 год, $265 млн - рулит до сих пор.
Cyberpunk 2077, 2020 год, $400 млн - говно.
Т.е. бабла сожгли больше, а качество - хуже.
>>6720
Импостеры уже прошлый век, ща в анриле наниты типа. Пока сыровато, но шаг в нужную сторону. Убрать рутину с 3Д-шника(создание лодов, рендер импостеров и.т.д) и переложить на плечи машины. Теперь 3Д-шник делает мидпольку дерева в спидтри и все, впродакшн.
Импостеры уже прошлый век, ща в анриле наниты типа. Пока сыровато, но шаг в нужную сторону. Убрать рутину с 3Д-шника(создание лодов, рендер импостеров и.т.д) и переложить на плечи машины. Теперь 3Д-шник делает мидпольку дерева в спидтри и все, впродакшн.
>>6767
А у нас в годоте реймарщинг.
Марширующие лучи, как я вчера тоже кстати смотрел) там же))
> ща в анриле наниты типа
А у нас в годоте реймарщинг.
Марширующие лучи, как я вчера тоже кстати смотрел) там же))
>>6768
Ты его игру видел? Она там в колесе бегает. Упала, бедненькая...
>>6767
Говно эти наниты. Они позиционируются как волшебная палочка для говноделов, улучшающая производительность всех их говнодельских ассетфлипов, а по факту (бенчмарки) они только снижают производительность - при чём всем, не только говноделам. UE5 вообще убивает геймдев по мнению многих игроков, но это для другого треда тема, мы вообще-то в Godot-треде...
Чем это отличается от автоматических лодов? Правильно - тем, что наниты сжигают больше циклов процессора, пытаясь "оптимизировать" меши в реальном времени по кусочкам, а меши громадные и всё это дело превращается в неиграбельный ассетфлип, который обязательно нужно рендерить в сниженном разрешении и потом растягивать картинку нейросетями, размазывая мыло по экрану. Зато бедные торидэшники, работающие, видимо, за считанные копейки, наконец-то могут вздохнуть спокойно и какать в редактор своими каками. А что там об этом игроки думают - никого в ААА не волнует, ведь их поделки сегодня покупают даже реже, чем инди-игры. Лол.
Пока индустрия пытается выжать больше бабла с меньшими затратами, они так и будут продолжать лепить неиграбельное говно, которое адекватные игроки скипают и продолжают играть в очередной пиксельный 2D платформер/рогалик/ферму от инди. Инди, который хочет сделать 3D, должен равняться на других инди, а не на говноделов, сжигающих сотни миллионов чужих бабок на совершенно никому не нужный продукт (часто выезжающий только за счёт франшизы/старых годных игр серии, которую они выкупили, чтобы обмазать говном).
>>6772
Automatic LOD в Godot 4 - как наниты, только для здоровых людей:
https://docs.godotengine.org/en/stable/tutorials/3d/mesh_lod.html
Ты его игру видел? Она там в колесе бегает. Упала, бедненькая...
>>6767
>ща в анриле наниты типа. Пока сыровато
Говно эти наниты. Они позиционируются как волшебная палочка для говноделов, улучшающая производительность всех их говнодельских ассетфлипов, а по факту (бенчмарки) они только снижают производительность - при чём всем, не только говноделам. UE5 вообще убивает геймдев по мнению многих игроков, но это для другого треда тема, мы вообще-то в Godot-треде...
>создание лодов
Чем это отличается от автоматических лодов? Правильно - тем, что наниты сжигают больше циклов процессора, пытаясь "оптимизировать" меши в реальном времени по кусочкам, а меши громадные и всё это дело превращается в неиграбельный ассетфлип, который обязательно нужно рендерить в сниженном разрешении и потом растягивать картинку нейросетями, размазывая мыло по экрану. Зато бедные торидэшники, работающие, видимо, за считанные копейки, наконец-то могут вздохнуть спокойно и какать в редактор своими каками. А что там об этом игроки думают - никого в ААА не волнует, ведь их поделки сегодня покупают даже реже, чем инди-игры. Лол.
Пока индустрия пытается выжать больше бабла с меньшими затратами, они так и будут продолжать лепить неиграбельное говно, которое адекватные игроки скипают и продолжают играть в очередной пиксельный 2D платформер/рогалик/ферму от инди. Инди, который хочет сделать 3D, должен равняться на других инди, а не на говноделов, сжигающих сотни миллионов чужих бабок на совершенно никому не нужный продукт (часто выезжающий только за счёт франшизы/старых годных игр серии, которую они выкупили, чтобы обмазать говном).
>>6772
>А у нас в годоте
Automatic LOD в Godot 4 - как наниты, только для здоровых людей:
https://docs.godotengine.org/en/stable/tutorials/3d/mesh_lod.html
>>6766
Добиться то можно, только я то проверил что будет если просто несколько раз нажать кнопку сделать хорошо перегенерить, так чтобы результат устраивал. Что не устраивает так это UV развертка, ей пользоваться невозможно, но у меня там есть идея + я хочу освоить StableProjectorZ
Я оказывается неправильно запомнил, было 15к на выходе нейронки (22к это у врага-комара), после merge vertices 2,6к что вполне радует.
Добиться то можно, только я то проверил что будет если просто несколько раз нажать кнопку сделать хорошо перегенерить, так чтобы результат устраивал. Что не устраивает так это UV развертка, ей пользоваться невозможно, но у меня там есть идея + я хочу освоить StableProjectorZ
Я оказывается неправильно запомнил, было 15к на выходе нейронки (22к это у врага-комара), после merge vertices 2,6к что вполне радует.
736 Кб, 1068x849>>6913
В смысле 22к тоже на выходе из нейронки, после редьюса там 3,9к. Там проблемы с крыльями, такая простая форма получила сложную сетку которую надо переделывать. Из забавного, он с лапками и подхватился миксамо.
В смысле 22к тоже на выходе из нейронки, после редьюса там 3,9к. Там проблемы с крыльями, такая простая форма получила сложную сетку которую надо переделывать. Из забавного, он с лапками и подхватился миксамо.
>>6768
Переделывать надо. Я конечно видел всякие гайды но сам еще никогда не моделил. Ну там где кольца глаз, рта должны быть под анимации.
В любом случае еше до НГ я считал что нейронки не могут в примлимое 3д, а тут практически геймреди.
Переделывать надо. Я конечно видел всякие гайды но сам еще никогда не моделил. Ну там где кольца глаз, рта должны быть под анимации.
В любом случае еше до НГ я считал что нейронки не могут в примлимое 3д, а тут практически геймреди.
>>6907
С такой сеткой тоже работать сложно, если захочешь отредактировать.
>>6929
Тогда советы:
1. Сразу используй модификатор Mirror (лишнюю сторону удалишь).
2. Постарайся сохранять четырёхугольники и петли (loops) на меше.
3. В местах изгибов при анимации полигонов должно быть больше.
...для гиперказуалки с зафиксированой далеко от моделек камерой.
>Что не устраивает так это UV развертка, ей пользоваться невозможно
С такой сеткой тоже работать сложно, если захочешь отредактировать.
>>6929
>сам еще никогда не моделил
Тогда советы:
1. Сразу используй модификатор Mirror (лишнюю сторону удалишь).
2. Постарайся сохранять четырёхугольники и петли (loops) на меше.
3. В местах изгибов при анимации полигонов должно быть больше.
>тут практически геймреди
...для гиперказуалки с зафиксированой далеко от моделек камерой.
>>6969
Да, я туториалы смотрел и советы эти слышал, спасибо, сам просто не делал руками еще
Да, я туториалы смотрел и советы эти слышал, спасибо, сам просто не делал руками еще
>>6973
/GD значит GODOT
/GD значит GODOT
>>6973
>>998261 →
>>998261 →
>Потому что думающие, преисполнившиеся люди, свободные, не скованные ограничениями, кроме объективно существующих еще не реализованных функций, творцы, креативно ищущие способы эти ограничения покорить или обойти, архитекторы, стоящие выше взаимозаменяемости офисных винтиков.
>Опенсорс - это желание дарить в ответ. Дарить коммиты в коде, дарить знания об устройстве. Это как свободные каменщики или мужики в деревне собирающиеся помогать друг другу строить дом.
>Поэтому в комьюнити годота когда кто-то показывает, что он сделал - то чаще отвечает как, дает ссылку на репозиторий, показывает бесплатный видеотуториал. А не пишет, это я сделал покупайте за $8.99 а чтобы узнать как покупайте курсы.
Игры мои игры
Ох, игры мои тяжкие!
Как вы решаете проблему застревания игрока/объектов внутри других физических объектов?
Сижу на бете 4.4, использую Jolt. Заметил, что физический движок не пытается вытолкнуть тело, если тело или хотя бы один из его коллиженшейпов находится полностью внутри другого тела:
1. RigidBody3D, состоящий из двух CollisionShape3D, и один из них забрался внутрь StaticBody3D. Теперь RigidBody3D трясётся на одном месте и никак не может вылезти из StaticBody3D.
2. RigidBody3D/CharacterBody3D целиком залез внутрь StaticBody3D. Теперь он может двигаться по внутренней/нижней стороне StaticBody3D, но выбраться наружу никак не может.
Я встречал что-то похожее в разных других играх, старых и новых, так что это вряд ли вина конкретного физического движка. В некоторых играх можно выскочить, активировав какого-нибудь питомца, дверь или что-то подобное, чтобы анимация персонажа передвинула его наружу. Или совершить суицид через меню паузы. Или телепортироваться в сторону за игровую валюту/в ущерб игровому счёту. Но всё это какие-то костыли.
Понимаю, нужно заранее проверять, куда спавнишь объекты. Но если объект двигался очень быстро и из-за скорости влетел внутрь другого тела? Или ещё что-то такое произошло, всего не предусмотреть. Какой способ решения этой ситуации был бы наиболее безболезненным для игрока? Всё-таки обидно терять ресурсы или убивать своего персонажа из-за глюка физики в игре, а бесплатный телепорт слишком легко абузить. Слишком сильно ограничивать возможности (скорость, ускорение) тоже как-то не очень хочется, хоть и понятно, что ограничения нужны.
Сижу на бете 4.4, использую Jolt. Заметил, что физический движок не пытается вытолкнуть тело, если тело или хотя бы один из его коллиженшейпов находится полностью внутри другого тела:
1. RigidBody3D, состоящий из двух CollisionShape3D, и один из них забрался внутрь StaticBody3D. Теперь RigidBody3D трясётся на одном месте и никак не может вылезти из StaticBody3D.
2. RigidBody3D/CharacterBody3D целиком залез внутрь StaticBody3D. Теперь он может двигаться по внутренней/нижней стороне StaticBody3D, но выбраться наружу никак не может.
Я встречал что-то похожее в разных других играх, старых и новых, так что это вряд ли вина конкретного физического движка. В некоторых играх можно выскочить, активировав какого-нибудь питомца, дверь или что-то подобное, чтобы анимация персонажа передвинула его наружу. Или совершить суицид через меню паузы. Или телепортироваться в сторону за игровую валюту/в ущерб игровому счёту. Но всё это какие-то костыли.
Понимаю, нужно заранее проверять, куда спавнишь объекты. Но если объект двигался очень быстро и из-за скорости влетел внутрь другого тела? Или ещё что-то такое произошло, всего не предусмотреть. Какой способ решения этой ситуации был бы наиболее безболезненным для игрока? Всё-таки обидно терять ресурсы или убивать своего персонажа из-за глюка физики в игре, а бесплатный телепорт слишком легко абузить. Слишком сильно ограничивать возможности (скорость, ускорение) тоже как-то не очень хочется, хоть и понятно, что ограничения нужны.
>>7160
Спавнить внутри коллайдера это точно не вариант. Это надо проверять через get_overlapping_bodies и искать в радиусе подходящее место.
Если говорить про движение, я слышал про такой способ ставить внутрь коллайдера еще 1 коллайдер поменьше. Сам не пробовал. Да и звучит расточительно.
Чтобы не влетать во что то быстро, то я писал выше - я лимитирую скорость персонажа после рассчетов физики.
Сейчас еще хочу попробовать вариант с пружиной. Не знаю как, но за персом будет летать привязанный цепью невидимый объект, и если перс влетел а предмет нет, то по идее резинка должна выдернуть перса обратно.
Может быть это можно сделать проще. Как в том же примере с цилиндрической гравитацией выше. Сделать всем статик боди зоны выталкивания с нужным направлением. Включаться они могут только когда игрок внутри них, так что жрать они много не будут. Нагенерить их можно тулскриптом автоматически.
В ммо которую я играл, бесплатный телепорт заряжался полминуты (то есть под уроном такое не выйдет) и "откатывал" тебя в место где ты безопасно был, например раз в 5 минут делался слепок твоей позиции (тут может быть нюанс с движущимися платформами). И имел кулдаун минут 30, или 15, не помню уже. То есть при желании его можно было разок другой заабузить, например вылезти из пропасти в которую упал или срезать возвращение обратно после ответвления. Но не то чтобы что-то поломное. Но там если застрял конкретно то застрял и уже через смерть, так как на гейммастерах быстро стали экономить и они перестали приходить (а на старте игры могли придти и рестартануть зависшего рейдбосса или заглючивший сундук).
Спавнить внутри коллайдера это точно не вариант. Это надо проверять через get_overlapping_bodies и искать в радиусе подходящее место.
Если говорить про движение, я слышал про такой способ ставить внутрь коллайдера еще 1 коллайдер поменьше. Сам не пробовал. Да и звучит расточительно.
Чтобы не влетать во что то быстро, то я писал выше - я лимитирую скорость персонажа после рассчетов физики.
Сейчас еще хочу попробовать вариант с пружиной. Не знаю как, но за персом будет летать привязанный цепью невидимый объект, и если перс влетел а предмет нет, то по идее резинка должна выдернуть перса обратно.
Может быть это можно сделать проще. Как в том же примере с цилиндрической гравитацией выше. Сделать всем статик боди зоны выталкивания с нужным направлением. Включаться они могут только когда игрок внутри них, так что жрать они много не будут. Нагенерить их можно тулскриптом автоматически.
>бесплатный телепорт слишком легко абузить
В ммо которую я играл, бесплатный телепорт заряжался полминуты (то есть под уроном такое не выйдет) и "откатывал" тебя в место где ты безопасно был, например раз в 5 минут делался слепок твоей позиции (тут может быть нюанс с движущимися платформами). И имел кулдаун минут 30, или 15, не помню уже. То есть при желании его можно было разок другой заабузить, например вылезти из пропасти в которую упал или срезать возвращение обратно после ответвления. Но не то чтобы что-то поломное. Но там если застрял конкретно то застрял и уже через смерть, так как на гейммастерах быстро стали экономить и они перестали приходить (а на старте игры могли придти и рестартануть зависшего рейдбосса или заглючивший сундук).
>>7166
слепок твоей позиции (тут может быть нюанс с движущимися платформами)
И уже запертой дверью в какую либо комнату
слепок твоей позиции (тут может быть нюанс с движущимися платформами)
И уже запертой дверью в какую либо комнату
>>7166
Как проверка перед спавном - так и надо делать, но этот метод есть только у Area3D. Если что-то где-то уже застряло на глазах у игрока (например, на игрока свалился тяжёлый объект и выпихнул его сквозь пол или стену за пределы игровой зоны), игра об этом "не знает" и не может ничем помочь, если, конечно, не облепить всё вокруг Area3D. Было бы хорошо иметь датчик вхождения у PhysicsBody3D, а не только у Area3D, но этого почему-то нет (скорее всего, ради оптимизации?).
Ты имеешь в виду коллайдер 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 и ходит по его внутренней поверхности (с обратной стороны потолка, если смотреть снаружи).
>проверять через 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 и ходит по его внутренней поверхности (с обратной стороны потолка, если смотреть снаружи).
>>7166
Как проверка перед спавном - так и надо делать, но этот метод есть только у Area3D. Если что-то где-то уже застряло на глазах у игрока (например, на игрока свалился тяжёлый объект и выпихнул его сквозь пол или стену за пределы игровой зоны), игра об этом "не знает" и не может ничем помочь, если, конечно, не облепить всё вокруг Area3D. Было бы хорошо иметь датчик вхождения у PhysicsBody3D, а не только у Area3D, но этого почему-то нет (скорее всего, ради оптимизации?).
Ты имеешь в виду коллайдер 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 и ходит по его внутренней поверхности (с обратной стороны потолка, если смотреть снаружи).
>проверять через 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 и ходит по его внутренней поверхности (с обратной стороны потолка, если смотреть снаружи).
>>7182
Прикрепляешь Area3D детектор к PhysBody, можно в своем слое.
>Было бы хорошо иметь датчик вхождения у PhysicsBody3D, а не только у Area3D
Прикрепляешь Area3D детектор к PhysBody, можно в своем слое.
>>7195
Вот двачую. Не могут анончики мыслить композиционно. Им дерево нод дали, композируй, нет, не хочу, хочу в наследовании функционал тащить.
Вот двачую. Не могут анончики мыслить композиционно. Им дерево нод дали, композируй, нет, не хочу, хочу в наследовании функционал тащить.
>>7160
Я все еще на буллете, у меня выталкивает. Более того, одна из фич моей игры. лул.
Я все еще на буллете, у меня выталкивает. Более того, одна из фич моей игры. лул.
>>1401
Ебучая необходимость постоянно РАБотать, править здоровье и заниматься 100500 других дел. На разработку игры сил и времени не остается.
Как следствие настроение, которое скачет в диапазоне апатия-раздражения, и ощущение подбирающегося кризиса среднего возраста
/thread
>С какими трудностями столкнулись?
Ебучая необходимость постоянно РАБотать, править здоровье и заниматься 100500 других дел. На разработку игры сил и времени не остается.
Как следствие настроение, которое скачет в диапазоне апатия-раздражения, и ощущение подбирающегося кризиса среднего возраста
/thread
>>7302
Мне похуй, вахтер. Я тут редко пишу, так что когда в след раз зайду в тред, бана уже не будет
Мне похуй, вахтер. Я тут редко пишу, так что когда в след раз зайду в тред, бана уже не будет
>>7302
Съебался с треда, уёбище.
Съебался с треда, уёбище.
>>7314
Я не могу делать игры, мне плохо, больно, нудно. Хочется, знаете ли, господа, чего-то эдакого, распахнуть крылья и взлететь. А не вот это вот всё.
Я не могу делать игры, мне плохо, больно, нудно. Хочется, знаете ли, господа, чего-то эдакого, распахнуть крылья и взлететь. А не вот это вот всё.
>>7314
Сижу пытаюсь вкурить в AI.
Спросил у нейронки, она предложила в общем-то всё то же, что и в интернетах пишут. Utility AI с весами, древовидная система, интеллект на основе задач. В принципе, у меня как раз и реализовано что-то типа первого варианта. Но пока что приходится каждому врагу индивидуально настраивать поведение, и я не очень понимаю, как от этого перейти к более гибкой системе, чтобы можно было просто расставлять врагов на уровне, не залезая каждому в мозги.
Так что вот, да, делаю.
Сижу пытаюсь вкурить в AI.
Спросил у нейронки, она предложила в общем-то всё то же, что и в интернетах пишут. Utility AI с весами, древовидная система, интеллект на основе задач. В принципе, у меня как раз и реализовано что-то типа первого варианта. Но пока что приходится каждому врагу индивидуально настраивать поведение, и я не очень понимаю, как от этого перейти к более гибкой системе, чтобы можно было просто расставлять врагов на уровне, не залезая каждому в мозги.
Так что вот, да, делаю.
>>7478
Один ресурс на всех врагов, внутри вся логика (через if). Настройка для каждого через экспортные переменные. Где не прав?
Хорошим ии в играх сейчас и не пахнет. Какой сложности поведения ты хочешь добиться?
Один ресурс на всех врагов, внутри вся логика (через if). Настройка для каждого через экспортные переменные. Где не прав?
Хорошим ии в играх сейчас и не пахнет. Какой сложности поведения ты хочешь добиться?
>>7495
Вот начнут подключать ЛЛМ - порядок будет. Еще поплачешь с того, как тебя в скайриме медведь унижает.
>Хорошим ии в играх сейчас и не пахнет
Вот начнут подключать ЛЛМ - порядок будет. Еще поплачешь с того, как тебя в скайриме медведь унижает.
>>7506
Тут нужны будут жесткие ограничения, ибо даже рпг - это красивая рельса в обертке псевдовыбора. Сиречь - аттракцион. А так то дело хорошее. Только как-то тупо, что со времен первого FEAR людишки ничего лучше не осилили
Тут нужны будут жесткие ограничения, ибо даже рпг - это красивая рельса в обертке псевдовыбора. Сиречь - аттракцион. А так то дело хорошее. Только как-то тупо, что со времен первого FEAR людишки ничего лучше не осилили
https://godotengine.org/article/dev-snapshot-godot-4-4-beta-4/
Последний бета билд, дальше - кандидаты не релиз!
Последний бета билд, дальше - кандидаты не релиз!
>>7618
А для этого надо делать чанки/стриминг. Ты же в любом случае будешь оптимизировать коллайдеры чтобы они подгружались только рядом с игроком, иначе они у тебя так же будут жрать ресурсы, и побольше чем Area
А для этого надо делать чанки/стриминг. Ты же в любом случае будешь оптимизировать коллайдеры чтобы они подгружались только рядом с игроком, иначе они у тебя так же будут жрать ресурсы, и побольше чем Area
>>7478
Всё правильно посоветовала:
Универсальное решение, как мозги людей.
Зачем? Что именно ты в них настраиваешь?
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, собирает и сортирует результаты вычислений, и выбирает лучшее из них (альтернативы: рандомное из лучших; рандомное в зависимости от полезности каждого действия).
Можно добавить иерархию, другие алгоритмы и т.д.
>>7506
У LLM много проблем в текущем виде.
Во-первых, LLM для этого плохо подходит.
Во-вторых, роль медведя - красиво проиграть.
>>7516
Там GOAP, это другое. Utility System - из The Sims 1.
У GOAP много проблем по сравнению с Utility System.
Всё правильно посоветовала:
>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, собирает и сортирует результаты вычислений, и выбирает лучшее из них (альтернативы: рандомное из лучших; рандомное в зависимости от полезности каждого действия).
Можно добавить иерархию, другие алгоритмы и т.д.
>>7506
>Вот начнут подключать ЛЛМ
У LLM много проблем в текущем виде.
>как тебя в скайриме медведь унижает
Во-первых, LLM для этого плохо подходит.
Во-вторых, роль медведя - красиво проиграть.
>>7516
>FEAR
Там GOAP, это другое. Utility System - из The Sims 1.
У GOAP много проблем по сравнению с Utility System.
>>7478
Всё правильно посоветовала:
Универсальное решение, как мозги людей.
Зачем? Что именно ты в них настраиваешь?
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, собирает и сортирует результаты вычислений, и выбирает лучшее из них (альтернативы: рандомное из лучших; рандомное в зависимости от полезности каждого действия).
Можно добавить иерархию, другие алгоритмы и т.д.
>>7506
У LLM много проблем в текущем виде.
Во-первых, LLM для этого плохо подходит.
Во-вторых, роль медведя - красиво проиграть.
>>7516
Там GOAP, это другое. Utility System - из The Sims 1.
У GOAP много проблем по сравнению с Utility System.
Всё правильно посоветовала:
>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, собирает и сортирует результаты вычислений, и выбирает лучшее из них (альтернативы: рандомное из лучших; рандомное в зависимости от полезности каждого действия).
Можно добавить иерархию, другие алгоритмы и т.д.
>>7506
>Вот начнут подключать ЛЛМ
У LLM много проблем в текущем виде.
>как тебя в скайриме медведь унижает
Во-первых, LLM для этого плохо подходит.
Во-вторых, роль медведя - красиво проиграть.
>>7516
>FEAR
Там GOAP, это другое. Utility System - из The Sims 1.
У GOAP много проблем по сравнению с Utility System.
>>7649
Пропиши стандартные веса и меняй их только если создаёшь новый класс врага. Мелкие отклонения добавляешь процедурно, через функцию рандома.
Если у тебя стрелялка, у тебя в любом случае будет несколько десятков одинаковых болванчиков, и все отличия заключаются в используемом ими оружии, "элитности", случайных отклонениях.
Алсо, если параметров много, и неизвестна заранее лучшая комбинация, но известен исход боя - можно организовать reinforcement learning, который будет подгонять множители (веса) в зависимости от того, насколько успешно действуют твои NPC.
Если ты пытаешься организовать работу отряда из нескольких юнитов, то проще сделать один общий менеджер, раздающий им приказы.
Если не знал, у @export есть значения по умолчанию.
Также можно сохранять фрагменты сцен как сцены и редактировать параметры нод вложенной сцены, т.е. сохранять настройки куска сцены и потом менять, не нарушая зависимости от исходного файла на диске (правой кнопкой по ноде - Editable Children).
Пропиши стандартные веса и меняй их только если создаёшь новый класс врага. Мелкие отклонения добавляешь процедурно, через функцию рандома.
Если у тебя стрелялка, у тебя в любом случае будет несколько десятков одинаковых болванчиков, и все отличия заключаются в используемом ими оружии, "элитности", случайных отклонениях.
Алсо, если параметров много, и неизвестна заранее лучшая комбинация, но известен исход боя - можно организовать reinforcement learning, который будет подгонять множители (веса) в зависимости от того, насколько успешно действуют твои NPC.
Если ты пытаешься организовать работу отряда из нескольких юнитов, то проще сделать один общий менеджер, раздающий им приказы.
Если не знал, у @export есть значения по умолчанию.
Также можно сохранять фрагменты сцен как сцены и редактировать параметры нод вложенной сцены, т.е. сохранять настройки куска сцены и потом менять, не нарушая зависимости от исходного файла на диске (правой кнопкой по ноде - Editable Children).
>>7661
Где ты найдешь стандартные веса? В каком то справочнике по игровому балансу?
>Пропиши стандартные веса
Где ты найдешь стандартные веса? В каком то справочнике по игровому балансу?
>>7643
Один враг должен патрулировать местность от этой до этой; при виде игрока - пару секунд потупить, после чего нырять вон в то укрытие и оттуда открывать огонь; игрока потерял - идти в точку, где последний раз видел; если и там не нашёл - возвращаться на исходный патруль.
Другой должен сидеть на посту и не ходить; при виде игрока - стоять насмерть, стрелять прямо с места.
Третий при виде игрока должен бежать со всех ног, искать любое доступное укрытие, а отстреливаться только если зажали в угол. Но бежать вооон в ту комнату - запрещается.
И таких вот сценариев поведения - до жопы. Я реализовал каждый из них в отдельности, составляя по кирпичикам: у каждого болванчика есть 2-3 вида поведения с условиями, каждое поведение состоит из простых движений типа "двигаться направо до координаты Х", "присесть". Но как их объединить во что-то целостное, чтоб каждый раз кирпичики не складывать, вот тут чота теряюсь.
>Что именно ты в них настраиваешь?
Один враг должен патрулировать местность от этой до этой; при виде игрока - пару секунд потупить, после чего нырять вон в то укрытие и оттуда открывать огонь; игрока потерял - идти в точку, где последний раз видел; если и там не нашёл - возвращаться на исходный патруль.
Другой должен сидеть на посту и не ходить; при виде игрока - стоять насмерть, стрелять прямо с места.
Третий при виде игрока должен бежать со всех ног, искать любое доступное укрытие, а отстреливаться только если зажали в угол. Но бежать вооон в ту комнату - запрещается.
И таких вот сценариев поведения - до жопы. Я реализовал каждый из них в отдельности, составляя по кирпичикам: у каждого болванчика есть 2-3 вида поведения с условиями, каждое поведение состоит из простых движений типа "двигаться направо до координаты Х", "присесть". Но как их объединить во что-то целостное, чтоб каждый раз кирпичики не складывать, вот тут чота теряюсь.
>>7666
Ты тактическую головоломку делаешь что ли?
Коридорный шутер с кучей уникальных сцен?
Думаю, сначала нужно было игру описать...
Ничего он тебе не должен... Тьфу, то есть, ты, видать, ошибся с выбором алгоритма. 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, симулировав поведение игрока другим юнитом.
Если работы слишком много, то, возможно, у твоей задумки слишком большой масштаб для тебя...
Никакой магии нет, даже нейронку обучать (какой-то особенной задаче на приемлемом уровне) тяжело.
Ты тактическую головоломку делаешь что ли?
Коридорный шутер с кучей уникальных сцен?
Думаю, сначала нужно было игру описать...
>враг должен
Ничего он тебе не должен... Тьфу, то есть, ты, видать, ошибся с выбором алгоритма. 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, симулировав поведение игрока другим юнитом.
Если работы слишком много, то, возможно, у твоей задумки слишком большой масштаб для тебя...
Никакой магии нет, даже нейронку обучать (какой-то особенной задаче на приемлемом уровне) тяжело.
>>7666
Ты тактическую головоломку делаешь что ли?
Коридорный шутер с кучей уникальных сцен?
Думаю, сначала нужно было игру описать...
Ничего он тебе не должен... Тьфу, то есть, ты, видать, ошибся с выбором алгоритма. 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, симулировав поведение игрока другим юнитом.
Если работы слишком много, то, возможно, у твоей задумки слишком большой масштаб для тебя...
Никакой магии нет, даже нейронку обучать (какой-то особенной задаче на приемлемом уровне) тяжело.
Ты тактическую головоломку делаешь что ли?
Коридорный шутер с кучей уникальных сцен?
Думаю, сначала нужно было игру описать...
>враг должен
Ничего он тебе не должен... Тьфу, то есть, ты, видать, ошибся с выбором алгоритма. 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, симулировав поведение игрока другим юнитом.
Если работы слишком много, то, возможно, у твоей задумки слишком большой масштаб для тебя...
Никакой магии нет, даже нейронку обучать (какой-то особенной задаче на приемлемом уровне) тяжело.
>>7713
2д-шутан с видом сбоку. Типа Noita, но без процедурной генерации и в сеттинге "под реализм".
Ну вот щас у меня двухъярусный конечный автомат, где общий паттерн поведения (мирный, тревога, бой) выбирается на основе весов, а внутри паттерна действия выполняются последовательно или рандомно.
В принципе, этого уже достаточно, играется весело, поведение врагов достаточно разнообразное. Проблема в том, что я изначально написал эти мозги так, что их надо слишком сильно править для каждого конкретного солдатика. Модульно, где паттерны это ноды - дети AI-ноды, а у них свои дети - отдельные действия. Щас переписываю на одну единственную ноду, чтобы
а) солдатика можно было без каких-либо правок воткнуть в любое место уровня, и он бы там сам разобрался, что ему делать,
б) если захочу особое поведение - настроить его парой галок в инспекторе.
А да, кстати. Если промотаешь, с чего всё началось. Там анон спрашивал, что делаете, ну я и поделился своим. То есть, это не "помогите подскажите", а "щас вот работаю над такой задачей, ищу пути решения". Так что ты, возможно, зря так расстарался.
>сначала нужно было игру описать
2д-шутан с видом сбоку. Типа Noita, но без процедурной генерации и в сеттинге "под реализм".
>можешь просто иерархические конечные автоматы заюзать и всё
Ну вот щас у меня двухъярусный конечный автомат, где общий паттерн поведения (мирный, тревога, бой) выбирается на основе весов, а внутри паттерна действия выполняются последовательно или рандомно.
В принципе, этого уже достаточно, играется весело, поведение врагов достаточно разнообразное. Проблема в том, что я изначально написал эти мозги так, что их надо слишком сильно править для каждого конкретного солдатика. Модульно, где паттерны это ноды - дети AI-ноды, а у них свои дети - отдельные действия. Щас переписываю на одну единственную ноду, чтобы
а) солдатика можно было без каких-либо правок воткнуть в любое место уровня, и он бы там сам разобрался, что ему делать,
б) если захочу особое поведение - настроить его парой галок в инспекторе.
А да, кстати. Если промотаешь, с чего всё началось. Там анон спрашивал, что делаете, ну я и поделился своим. То есть, это не "помогите подскажите", а "щас вот работаю над такой задачей, ищу пути решения". Так что ты, возможно, зря так расстарался.
>>6907
Посидел вечерок в блендере с этой проблемой
Придумал так - у нас есть говноUV от нейронки. И делаем в другом слое еще одну UV развертку которая нам уже нравится. Пользуемся smart UNWrap-ами, разрезаем грани расставляя Seam, склеиваем юзая Stitch
Потом геометри нодами мы расплющиваем нашу в модельку в плоскость с формой хорошей UV. А рендерим ее используя старый UV! (ортографической камерой с отключенным освещением)
И хоппа, мы провернули фарш и полуавтоматически перерисовали полигоны текстуры под новое расположение.
Даже получилось что-то вроде реалтаймого редактора не разобрался как в бленедере автоматизировать рендер->запечение текстуры из шейдера->переиспользование этой текстуры на вход заново
Посидел вечерок в блендере с этой проблемой
Придумал так - у нас есть говноUV от нейронки. И делаем в другом слое еще одну UV развертку которая нам уже нравится. Пользуемся smart UNWrap-ами, разрезаем грани расставляя Seam, склеиваем юзая Stitch
Потом геометри нодами мы расплющиваем нашу в модельку в плоскость с формой хорошей UV. А рендерим ее используя старый UV! (ортографической камерой с отключенным освещением)
И хоппа, мы провернули фарш и полуавтоматически перерисовали полигоны текстуры под новое расположение.
Даже получилось что-то вроде реалтаймого редактора не разобрался как в бленедере автоматизировать рендер->запечение текстуры из шейдера->переиспользование этой текстуры на вход заново
Всем привет. Возникла проблема. DeleteArea не детектит входящие объекты. Вроде сигнал подключил верно....
>>7755
Если что версия Godot 3.5.2
Если что версия Godot 3.5.2
>>7755
body_entered детектит физикс боди, такие как статик/кинематик/ригид. Содержание сцен Platform из твоего скрина непонятно - может они у тебя не физикс боди, а ареа2д - для их детекта нужен сигнал area_entered
body_entered детектит физикс боди, такие как статик/кинематик/ригид. Содержание сцен Platform из твоего скрина непонятно - может они у тебя не физикс боди, а ареа2д - для их детекта нужен сигнал area_entered
Проснулись, потянулись, улыбнулись, попиздовали делать игры
Посмотрите какой дипсик https://www.youtube.com/watch?v=fd1XGAJDB7E
>>7759
Спасибо. Я вроде разобрался
Спасибо. Я вроде разобрался
>>7767
Хотел бы я чтобы такой дипсик дал мне код
Хотел бы я чтобы такой дипсик дал мне код
>>7767
Чушь какая-то. Зачем такая интеграция в Годот, когда его можно в обычном терминале использовать? Автор изобрел велосипед с квадратными колесами
А для игры это не сработает, потому что игроку самому нужно разворачивать у себя сервер и нейронку, что занимает очень много ресурсов (видеопамяти)
Чушь какая-то. Зачем такая интеграция в Годот, когда его можно в обычном терминале использовать? Автор изобрел велосипед с квадратными колесами
А для игры это не сработает, потому что игроку самому нужно разворачивать у себя сервер и нейронку, что занимает очень много ресурсов (видеопамяти)
>>7771
Чтобы нейронка сразу генерировала ресурсы в проект, а не твои ответы текстовые.
> Зачем такая интеграция в Годот
Чтобы нейронка сразу генерировала ресурсы в проект, а не твои ответы текстовые.
>>7779
Ты, похоже, даже не глядел на код автора из видео. Все, что он сделал - подключение к локальному серверу, хостящему LLM, напрямую из Годота. Там нет никакого функционала для генерации ресурсов и каких-либо иных действий. Содержательная часть видоса отсутствует. Тот, кто хочет идею довести до конца, в данном видосе не нуждается, а такие как ты, не понимают даже, что в нем происходит
Ты, похоже, даже не глядел на код автора из видео. Все, что он сделал - подключение к локальному серверу, хостящему LLM, напрямую из Годота. Там нет никакого функционала для генерации ресурсов и каких-либо иных действий. Содержательная часть видоса отсутствует. Тот, кто хочет идею довести до конца, в данном видосе не нуждается, а такие как ты, не понимают даже, что в нем происходит
>>7782
Блин, угадал. Я другой видос досматривал, а этот запостил на потом. Штош, извините за говноту.
> Ты, похоже, даже не глядел на код автора из видео.
Блин, угадал. Я другой видос досматривал, а этот запостил на потом. Штош, извините за говноту.
Есть удобные функции типа rotate_y(0.5), воткнул их в процесс и объект вечно вращается. Есть ли подобное для плавного передвижения вверх и обратно вниз, типа левитации? Я свое нагородил уже с дельтой и синусом, но вдруг.
>>7795
Нейронки говорят что нет. Штош.
Нейронки говорят что нет. Штош.
>>7795
Rotate тоже надо делать с дельтой, иначе с разным фпс будет разное вращение.
У физ тел есть поле velocity.
Rotate тоже надо делать с дельтой, иначе с разным фпс будет разное вращение.
У физ тел есть поле velocity.
>>7801
Ну бля. Заебала эта дельта ебаная. Почему нельзя в движке поставить галку, "веди себя одинаково с любым фпс"?
Ну бля. Заебала эта дельта ебаная. Почему нельзя в движке поставить галку, "веди себя одинаково с любым фпс"?
>>7795
Tween для таких задач придумали.
Tween для таких задач придумали.
>>7801
У physic_process относительно стабильная дельта, делай там, либо на твинах.
У physic_process относительно стабильная дельта, делай там, либо на твинах.
>>7807
Вшить куда? Вшить как?
Вот простейший код с дельтой:
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. Как движок должен догадаться, где тебе нужна дельта, а где не нужна?
Вшить куда? Вшить как?
Вот простейший код с дельтой:
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. Как движок должен догадаться, где тебе нужна дельта, а где не нужна?
>>7813
Везде нужна. Какие подводные камни? Серьезный вопрос.
И, с другой стороны, как я должен догадаться где движку нужна дельта, а где нет? Почему move_and_slide сам дельту вшивает, а rotate_y - нет?
>2. Как движок должен догадаться, где тебе нужна дельта, а где не нужна?
Везде нужна. Какие подводные камни? Серьезный вопрос.
И, с другой стороны, как я должен догадаться где движку нужна дельта, а где нет? Почему move_and_slide сам дельту вшивает, а rotate_y - нет?
>>7814
Никак. Движку дельта не нужна. Она нужна ТЕБЕ. Хер тебя знает, что ты там этим ротейтом ротейтишь и зачем. Одно дело физику посчитать, совсем другое - ты делаешь A += B и только сам знаешь, что это и зачем.
А вот нихуя. Вообще совсем ни капельки нихуя.
>как я должен догадаться где движку нужна дельта, а где нет?
Никак. Движку дельта не нужна. Она нужна ТЕБЕ. Хер тебя знает, что ты там этим ротейтом ротейтишь и зачем. Одно дело физику посчитать, совсем другое - ты делаешь 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 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 загружать изображения которые находятся не в папке ресурсов.
Короче я накопипастил свой код в чатгпт и он мне указал где я дельту проебал.
>>7819
нада
var err = img.load_from_file("user://цп.png")
Ну и
https://docs.godotengine.org/en/stable/tutorials/io/data_paths.html
>А этот не показывает:
>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
>>7807
Потому что например ты создаешь где-то вспомогательную ноду для рассчетов и пишешь ей rotate_y(90) потому что хочешь повернуть объект на прямой угол. А он тебе повернет на 1,503 градуса, классно
Потому что например ты создаешь где-то вспомогательную ноду для рассчетов и пишешь ей rotate_y(90) потому что хочешь повернуть объект на прямой угол. А он тебе повернет на 1,503 градуса, классно
216 Кб, 396x410https://dtf.ru/software/3547201-microsoft-anonsirovala-muse-pervuyu-ii-model-sposobnuyu-generirovat-geimplei
Итс овер, даже грустить уже сил нет
Итс овер, даже грустить уже сил нет
>>7867
Круто, обязательно заюзаю аналог когда вывалят в опенсорс или бесплатный доступ и сделаю еще больше игр.
Круто, обязательно заюзаю аналог когда вывалят в опенсорс или бесплатный доступ и сделаю еще больше игр.
>>7867
Вам бы только найти повод для грусти. Это просто модель, которая генерирует исключительно видео геймплея. Можно сказать, Lora-стиль видеоигрового геймплея для ИИ, что генерируют видео
Грустью игру не сделаешь, заряжайся позитивом и работай. Кто хочет сделать игру - тому нет преград
Вам бы только найти повод для грусти. Это просто модель, которая генерирует исключительно видео геймплея. Можно сказать, Lora-стиль видеоигрового геймплея для ИИ, что генерируют видео
Грустью игру не сделаешь, заряжайся позитивом и работай. Кто хочет сделать игру - тому нет преград
1,9 Мб, mp4,640x480, 0:50
Как вам такой концепт UI для подсказок в круглом меню?
Опытный, уже всё знающий, может быстро нажать кнопку.
Новичок задерживает курсор на секунду, видит подсказку.
Подсказка не мешает нажимать, выделять другую кнопку.
Подсказка выводится анимацией чтобы быть заметной.
Подсказки есть как для кнопок, так и для категорий.
Кружочек в углу виден только если есть подсказка.
Как же всё-таки приятно работать с UI в Godot...
Опытный, уже всё знающий, может быстро нажать кнопку.
Новичок задерживает курсор на секунду, видит подсказку.
Подсказка не мешает нажимать, выделять другую кнопку.
Подсказка выводится анимацией чтобы быть заметной.
Подсказки есть как для кнопок, так и для категорий.
Кружочек в углу виден только если есть подсказка.
Как же всё-таки приятно работать с UI в Godot...
>>7889
Очень приятно выглядит. Идея хорошая и интуитивная. Новый игрок, не зная, за что отвечает некоторый пункт меню, остановится на нем, чтобы попытаться осмыслить картинку. И по таймингу как раз появится текст. Выше предложили не сдвигать сам блок, но на мой взгляд, все правильно: так текст центрирован относительно центра экрана, читать приятнее, не нужно наклонять голову вбок
Очень приятно выглядит. Идея хорошая и интуитивная. Новый игрок, не зная, за что отвечает некоторый пункт меню, остановится на нем, чтобы попытаться осмыслить картинку. И по таймингу как раз появится текст. Выше предложили не сдвигать сам блок, но на мой взгляд, все правильно: так текст центрирован относительно центра экрана, читать приятнее, не нужно наклонять голову вбок
>>7867
Наконец-то нейросеть сделает мне игру про толщеход во вселенной наоборот. Даже самому делать ничего не придётся.
> даже грустить уже сил нет
Наконец-то нейросеть сделает мне игру про толщеход во вселенной наоборот. Даже самому делать ничего не придётся.
>>7893
Ты же не наклоняешь голову вбок, чтобы читать текст который в инспекторе редактора справа.
Ты же не наклоняешь голову вбок, чтобы читать текст который в инспекторе редактора справа.
353 Кб, 1280x720>>7896
Ты прав. Однако я хорошо знаю, что там и где располагается, плюс я хорошо знаю язык, с которым работаю и мне не нужно сильно вчитываться
Гипотетический пример: игрок не знает английского и решил поиграть, текст уезжает вбок, он пытается вчитываться и понимать
Пример на моем опыте: одни из последних RPG, в которые играл, это трилогия Shadowrun. Там весь текст уходит вправо, и мне, как человеку, хорошо знающему английский, при встрече профильных или редких для языка слов приходилось иногда вчитываться, чтобы осознать, о чем идет речь. Шея болела ужасно, это оставило очень плохие впечатления (кстати, в последние годы в играх жанра почему-то мода на сдвиг текст вправо появилась)
А чем тебя напрягает то, что иконка смещается влево, чтобы центрировать текст по центру?
Ты прав. Однако я хорошо знаю, что там и где располагается, плюс я хорошо знаю язык, с которым работаю и мне не нужно сильно вчитываться
Гипотетический пример: игрок не знает английского и решил поиграть, текст уезжает вбок, он пытается вчитываться и понимать
Пример на моем опыте: одни из последних RPG, в которые играл, это трилогия Shadowrun. Там весь текст уходит вправо, и мне, как человеку, хорошо знающему английский, при встрече профильных или редких для языка слов приходилось иногда вчитываться, чтобы осознать, о чем идет речь. Шея болела ужасно, это оставило очень плохие впечатления (кстати, в последние годы в играх жанра почему-то мода на сдвиг текст вправо появилась)
А чем тебя напрягает то, что иконка смещается влево, чтобы центрировать текст по центру?
Можно попробовать иконку смещать по удалению от центра, т.е. если иконка выше центра - отдалять дальше по Y, если левее - значит еще дальше по -X
Текст будет центрирован, а иконка не будет слишком "прыгать"
Текст будет центрирован, а иконка не будет слишком "прыгать"
>>7899
Так делай же локализацию сразу.
> Гипотетический пример: игрок не знает английского и решил поиграть
Так делай же локализацию сразу.
>>7899
Если тебе приходится поворачивать голову, ты слишком близко сидишь перед экраном, к игре это имеет мало отношения.
Если тебе приходится поворачивать голову, ты слишком близко сидишь перед экраном, к игре это имеет мало отношения.
>>7903
Расскажи об этом своим игрокам, если таковые будут. Центрирование большого количества текста относительно чего-то, кроме центра экрана, плохо влияет на читаемость и раздражает пользователей. Именно поэтому в большинстве игр и софте основная рабочая область центрирована по центру и там же и располагается, а по бокам выбор инструментов или малозначительные вещи. Возьми ту же IDE и посмотри, что там где находится и относительно чего центрировано. Автору фидбек дал, а он сам уже решит, что с ним делать. Он достаточно умен, чтобы понимать такие очевидные вещи и сразу сделал центрирование по центру
Расскажи об этом своим игрокам, если таковые будут. Центрирование большого количества текста относительно чего-то, кроме центра экрана, плохо влияет на читаемость и раздражает пользователей. Именно поэтому в большинстве игр и софте основная рабочая область центрирована по центру и там же и располагается, а по бокам выбор инструментов или малозначительные вещи. Возьми ту же IDE и посмотри, что там где находится и относительно чего центрировано. Автору фидбек дал, а он сам уже решит, что с ним делать. Он достаточно умен, чтобы понимать такие очевидные вещи и сразу сделал центрирование по центру
>>7905
98% этих игр - текст. Вторая буквально называется книгоходитель.
98% этих игр - текст. Вторая буквально называется книгоходитель.
>>7822
"ПОШЁЛ НАХЕР МУДИЛО" - вот так был бы злобный. А там хз где ты злобность нашёл, вроде ж нормальный конструктивный пост без наездов.
Придумал ещё вот какой абстрактный в вакууме пример:
a += 1
b += 3
c = a + b
d += c * delta
Спрашивается: как объяснить умному движку, где тут дельта нужна, а где нет?
>>7889
Круто, только лично я бы на раскрытие текстового окошка поменял бы транзишон тайп. Нынешняя (это TRANS_SPRING или TRANS_ELASTIC?) выглядит слишком дёргано на таком коротком тайминге. Как по мне, TRANS_BACK смотрелось бы чище, тем более в других анимациях как раз этот тип у тебя использован же.
>Чего злобный такой?
"ПОШЁЛ НАХЕР МУДИЛО" - вот так был бы злобный. А там хз где ты злобность нашёл, вроде ж нормальный конструктивный пост без наездов.
Придумал ещё вот какой абстрактный в вакууме пример:
a += 1
b += 3
c = a + b
d += c * delta
Спрашивается: как объяснить умному движку, где тут дельта нужна, а где нет?
>>7889
Круто, только лично я бы на раскрытие текстового окошка поменял бы транзишон тайп. Нынешняя (это TRANS_SPRING или TRANS_ELASTIC?) выглядит слишком дёргано на таком коротком тайминге. Как по мне, TRANS_BACK смотрелось бы чище, тем более в других анимациях как раз этот тип у тебя использован же.
>>7891
Я пробовал, вроде... Но есть нюансы (долго перечислять). Вообще, сейчас это не важно, позже можно будет поменять без проблем. Делал это меню как универсальный компонент (типа встроенных Control), чтобы можно было использовать в разных системах игры (и не только этой). Сегодня вот занялся рефакторингом, а то там логика реакции на клик была свёрнута в непонятный клубок - теперь стало лучше. Логику подсказки накидал за несколько минут чисто чтоб оценить концепт "подсказки с анимацией, которые не мешают использовать меню по назначению, но бросаются в глаза новичку с первого взгляда".
Но задумка была "привлечь внимание к всплывающей подсказке", так что сдвиг иконки вбок более чем оправдан, на мой взгляд, типа "подвинься, я тут тоже важна". На нажатие/выбор это никак не влияет, т.к. выбор зависит только от сектора круга непосредственно под курсором мыши. В реальной игре можно добавить настройку для отключения этой анимации и/или подсказок.
По моему опыту, UI игр часто страдает от "баннерной слепоты" - когда игрок не замечает элемент UI, рассматривая его как визуальный шум, декорацию. Часто замечал за собой такое - тыкаюсь в новую игру и не замечаю какой-нибудь текст, загнанный в угол экрана, где мне чётко говорят, что я должен делать. Толку от такой незаметной подсказки мало... Впрочем, также я слышал мнение, что игра должна быть интуитивно понятной без навязчивых подсказок. Наверное, всё сильно зависит от жанра игры.
>>7893
Правда? Спасибо. Думаю, "приятность" там за счёт анимации. Анимации любой UI делают намного приятнее. Жаль, что в большинстве игр UI слишком "жёсткий" - практически не реагирует на взаимодействие.
Лол, это ирония? У меня там весь текст набок наклонён. Это типа стиль такой... перекошенный. Возможно, подсказку лучше всё-таки выровнять, но это тоже потом легко поменять, если что.
>>7898
Да. Можно и на AnimationPlayer сделать, но с твинами такое проще выходит.
>>7899
Может, у тебя сверхширокий монитор или ты слишком близко к нему сидишь? Или слишком долго. Причин может быть масса, обвинять игру за такое как-то немного странно. Хотя поддержка играми сверхшироких дисплеев важна:
Плохо, если так. Это раньше квадратные экраны были, сейчас один монитор может быть как два 16:9 (т.е. буквально 32:9). Игровой интерфейс должен учитывать такие сверхширокие мониторы, размещая информацию (шкалу здоровья, подсказки и т.д.) близко к центру экрана, и при этом учитывать, что у кого-то до сих пор может быть 16:10 или даже ещё меньше по ширине (если этого не учитывать, то интерфейс молча уезжает за границу экрана).
>>7901
Этот резкий "прыжок" ощущается так из-за TRANS_BOUNCE...
>>7905
IDE отличаются от игр тем, что могут растянуть свой UI на весь экран без каких-либо последствий, и вообще не сильно париться о UI/UX, если программа важная и нужная. Для игр же расстояние между отдельными элементами UI важнее всего, и ощущения от использования критичны.
Лол, на самом деле это как бы поведение по-умолчанию... Хотя раньше я экспериментировал с открытием вложенных субменю вокруг сектора надменю (видео скидывал сюда в мае-июне), и в результате менюшки могли даже уезжать за границу экрана. Это было прикольно в теории, но, побаловавшись с ними, я решил, что пока что лучше сфокусировать их все в одном месте, даже если они перекрывают друг друга. Сдвиг кнопки-иконки в центр - это тоже такая "прикольная фишка" системы меню - субменю теперь зависят от этой фичи (на видео не видно, но "кнопка категории" может быть центральной кнопкой субменю, занимая место круглого "(X)" по центру - мне казалось это крутой фичей), а описание просто приклеено к этой иконке через контейнеры и убрать его куда-то будет не так-то легко. Короче, рефакторить надо, чтобы всё это разделить и сделать более свободным. На данный момент я даже не могу дизайнить эти меню в редакторе сцен (WYSIWYG) - оно полностью генерируется из кода по структуре данных, что значительно ограничивает их гибкость как универсального модуля. А у меня столько разных идей/планов было на это меню...
В общем, расположение по центру - по сути, случайное стечение обстоятельств (но мне понравилось, как это выглядит).
>>7910
Согласен, в подобных играх альтернативы "весь текст лентой сбоку" просто нет. Куда ещё его загнать? Вниз экрана тоненькой полоской на всю ширину? Читать узкую ленту сбоку проще, чем широкую снизу. А над головами персонажей не стали отображать, наверное, чтобы не выглядело как мобильная гиперказуалка, плюс история реплик может быть важна для выбора опций. Главное, чтобы эта лента с текстом не уезжала на самый край какого-нибудь супер-игрового 32:9 с изгибом вокруг головы на 180 градусов.
>>7921
Каждый раз забываю, что именно мне нужно, и в этот раз использовал TRANS_BOUNCE...
Глянул код - и правда. Как ты угадал? Я-то уже совсем забыл, что я там использовал. Наверное, нужно как-то где-то сделать себе "стандарт анимаций в проекте", чтобы не задумываться каждый раз, какую функцию использовать в новой анимации.
Всем спасибо за ответы, интересное обсуждение, много мыслей пришло.
>текст раскрывать справа
Я пробовал, вроде... Но есть нюансы (долго перечислять). Вообще, сейчас это не важно, позже можно будет поменять без проблем. Делал это меню как универсальный компонент (типа встроенных Control), чтобы можно было использовать в разных системах игры (и не только этой). Сегодня вот занялся рефакторингом, а то там логика реакции на клик была свёрнута в непонятный клубок - теперь стало лучше. Логику подсказки накидал за несколько минут чисто чтоб оценить концепт "подсказки с анимацией, которые не мешают использовать меню по назначению, но бросаются в глаза новичку с первого взгляда".
Но задумка была "привлечь внимание к всплывающей подсказке", так что сдвиг иконки вбок более чем оправдан, на мой взгляд, типа "подвинься, я тут тоже важна". На нажатие/выбор это никак не влияет, т.к. выбор зависит только от сектора круга непосредственно под курсором мыши. В реальной игре можно добавить настройку для отключения этой анимации и/или подсказок.
По моему опыту, UI игр часто страдает от "баннерной слепоты" - когда игрок не замечает элемент UI, рассматривая его как визуальный шум, декорацию. Часто замечал за собой такое - тыкаюсь в новую игру и не замечаю какой-нибудь текст, загнанный в угол экрана, где мне чётко говорят, что я должен делать. Толку от такой незаметной подсказки мало... Впрочем, также я слышал мнение, что игра должна быть интуитивно понятной без навязчивых подсказок. Наверное, всё сильно зависит от жанра игры.
>>7893
>Очень приятно выглядит. Идея хорошая и интуитивная.
Правда? Спасибо. Думаю, "приятность" там за счёт анимации. Анимации любой UI делают намного приятнее. Жаль, что в большинстве игр UI слишком "жёсткий" - практически не реагирует на взаимодействие.
>не нужно наклонять голову вбок
Лол, это ирония? У меня там весь текст набок наклонён. Это типа стиль такой... перекошенный. Возможно, подсказку лучше всё-таки выровнять, но это тоже потом легко поменять, если что.
>>7898
>Анимировал твинами?
Да. Можно и на AnimationPlayer сделать, но с твинами такое проще выходит.
>>7899
>Шея болела ужасно
Может, у тебя сверхширокий монитор или ты слишком близко к нему сидишь? Или слишком долго. Причин может быть масса, обвинять игру за такое как-то немного странно. Хотя поддержка играми сверхшироких дисплеев важна:
>почему-то мода на сдвиг текст вправо появилась
Плохо, если так. Это раньше квадратные экраны были, сейчас один монитор может быть как два 16:9 (т.е. буквально 32:9). Игровой интерфейс должен учитывать такие сверхширокие мониторы, размещая информацию (шкалу здоровья, подсказки и т.д.) близко к центру экрана, и при этом учитывать, что у кого-то до сих пор может быть 16:10 или даже ещё меньше по ширине (если этого не учитывать, то интерфейс молча уезжает за границу экрана).
>>7901
>иконка не будет слишком "прыгать"
Этот резкий "прыжок" ощущается так из-за TRANS_BOUNCE...
>>7905
>Возьми ту же IDE
IDE отличаются от игр тем, что могут растянуть свой UI на весь экран без каких-либо последствий, и вообще не сильно париться о UI/UX, если программа важная и нужная. Для игр же расстояние между отдельными элементами UI важнее всего, и ощущения от использования критичны.
>понимать такие очевидные вещи и сразу сделал центрирование по центру
Лол, на самом деле это как бы поведение по-умолчанию... Хотя раньше я экспериментировал с открытием вложенных субменю вокруг сектора надменю (видео скидывал сюда в мае-июне), и в результате менюшки могли даже уезжать за границу экрана. Это было прикольно в теории, но, побаловавшись с ними, я решил, что пока что лучше сфокусировать их все в одном месте, даже если они перекрывают друг друга. Сдвиг кнопки-иконки в центр - это тоже такая "прикольная фишка" системы меню - субменю теперь зависят от этой фичи (на видео не видно, но "кнопка категории" может быть центральной кнопкой субменю, занимая место круглого "(X)" по центру - мне казалось это крутой фичей), а описание просто приклеено к этой иконке через контейнеры и убрать его куда-то будет не так-то легко. Короче, рефакторить надо, чтобы всё это разделить и сделать более свободным. На данный момент я даже не могу дизайнить эти меню в редакторе сцен (WYSIWYG) - оно полностью генерируется из кода по структуре данных, что значительно ограничивает их гибкость как универсального модуля. А у меня столько разных идей/планов было на это меню...
В общем, расположение по центру - по сути, случайное стечение обстоятельств (но мне понравилось, как это выглядит).
>>7910
Согласен, в подобных играх альтернативы "весь текст лентой сбоку" просто нет. Куда ещё его загнать? Вниз экрана тоненькой полоской на всю ширину? Читать узкую ленту сбоку проще, чем широкую снизу. А над головами персонажей не стали отображать, наверное, чтобы не выглядело как мобильная гиперказуалка, плюс история реплик может быть важна для выбора опций. Главное, чтобы эта лента с текстом не уезжала на самый край какого-нибудь супер-игрового 32:9 с изгибом вокруг головы на 180 градусов.
>>7921
>Нынешняя
Каждый раз забываю, что именно мне нужно, и в этот раз использовал TRANS_BOUNCE...
>TRANS_BACK
>как раз этот тип у тебя использован же
Глянул код - и правда. Как ты угадал? Я-то уже совсем забыл, что я там использовал. Наверное, нужно как-то где-то сделать себе "стандарт анимаций в проекте", чтобы не задумываться каждый раз, какую функцию использовать в новой анимации.
Всем спасибо за ответы, интересное обсуждение, много мыслей пришло.
>>7891
Я пробовал, вроде... Но есть нюансы (долго перечислять). Вообще, сейчас это не важно, позже можно будет поменять без проблем. Делал это меню как универсальный компонент (типа встроенных Control), чтобы можно было использовать в разных системах игры (и не только этой). Сегодня вот занялся рефакторингом, а то там логика реакции на клик была свёрнута в непонятный клубок - теперь стало лучше. Логику подсказки накидал за несколько минут чисто чтоб оценить концепт "подсказки с анимацией, которые не мешают использовать меню по назначению, но бросаются в глаза новичку с первого взгляда".
Но задумка была "привлечь внимание к всплывающей подсказке", так что сдвиг иконки вбок более чем оправдан, на мой взгляд, типа "подвинься, я тут тоже важна". На нажатие/выбор это никак не влияет, т.к. выбор зависит только от сектора круга непосредственно под курсором мыши. В реальной игре можно добавить настройку для отключения этой анимации и/или подсказок.
По моему опыту, UI игр часто страдает от "баннерной слепоты" - когда игрок не замечает элемент UI, рассматривая его как визуальный шум, декорацию. Часто замечал за собой такое - тыкаюсь в новую игру и не замечаю какой-нибудь текст, загнанный в угол экрана, где мне чётко говорят, что я должен делать. Толку от такой незаметной подсказки мало... Впрочем, также я слышал мнение, что игра должна быть интуитивно понятной без навязчивых подсказок. Наверное, всё сильно зависит от жанра игры.
>>7893
Правда? Спасибо. Думаю, "приятность" там за счёт анимации. Анимации любой UI делают намного приятнее. Жаль, что в большинстве игр UI слишком "жёсткий" - практически не реагирует на взаимодействие.
Лол, это ирония? У меня там весь текст набок наклонён. Это типа стиль такой... перекошенный. Возможно, подсказку лучше всё-таки выровнять, но это тоже потом легко поменять, если что.
>>7898
Да. Можно и на AnimationPlayer сделать, но с твинами такое проще выходит.
>>7899
Может, у тебя сверхширокий монитор или ты слишком близко к нему сидишь? Или слишком долго. Причин может быть масса, обвинять игру за такое как-то немного странно. Хотя поддержка играми сверхшироких дисплеев важна:
Плохо, если так. Это раньше квадратные экраны были, сейчас один монитор может быть как два 16:9 (т.е. буквально 32:9). Игровой интерфейс должен учитывать такие сверхширокие мониторы, размещая информацию (шкалу здоровья, подсказки и т.д.) близко к центру экрана, и при этом учитывать, что у кого-то до сих пор может быть 16:10 или даже ещё меньше по ширине (если этого не учитывать, то интерфейс молча уезжает за границу экрана).
>>7901
Этот резкий "прыжок" ощущается так из-за TRANS_BOUNCE...
>>7905
IDE отличаются от игр тем, что могут растянуть свой UI на весь экран без каких-либо последствий, и вообще не сильно париться о UI/UX, если программа важная и нужная. Для игр же расстояние между отдельными элементами UI важнее всего, и ощущения от использования критичны.
Лол, на самом деле это как бы поведение по-умолчанию... Хотя раньше я экспериментировал с открытием вложенных субменю вокруг сектора надменю (видео скидывал сюда в мае-июне), и в результате менюшки могли даже уезжать за границу экрана. Это было прикольно в теории, но, побаловавшись с ними, я решил, что пока что лучше сфокусировать их все в одном месте, даже если они перекрывают друг друга. Сдвиг кнопки-иконки в центр - это тоже такая "прикольная фишка" системы меню - субменю теперь зависят от этой фичи (на видео не видно, но "кнопка категории" может быть центральной кнопкой субменю, занимая место круглого "(X)" по центру - мне казалось это крутой фичей), а описание просто приклеено к этой иконке через контейнеры и убрать его куда-то будет не так-то легко. Короче, рефакторить надо, чтобы всё это разделить и сделать более свободным. На данный момент я даже не могу дизайнить эти меню в редакторе сцен (WYSIWYG) - оно полностью генерируется из кода по структуре данных, что значительно ограничивает их гибкость как универсального модуля. А у меня столько разных идей/планов было на это меню...
В общем, расположение по центру - по сути, случайное стечение обстоятельств (но мне понравилось, как это выглядит).
>>7910
Согласен, в подобных играх альтернативы "весь текст лентой сбоку" просто нет. Куда ещё его загнать? Вниз экрана тоненькой полоской на всю ширину? Читать узкую ленту сбоку проще, чем широкую снизу. А над головами персонажей не стали отображать, наверное, чтобы не выглядело как мобильная гиперказуалка, плюс история реплик может быть важна для выбора опций. Главное, чтобы эта лента с текстом не уезжала на самый край какого-нибудь супер-игрового 32:9 с изгибом вокруг головы на 180 градусов.
>>7921
Каждый раз забываю, что именно мне нужно, и в этот раз использовал TRANS_BOUNCE...
Глянул код - и правда. Как ты угадал? Я-то уже совсем забыл, что я там использовал. Наверное, нужно как-то где-то сделать себе "стандарт анимаций в проекте", чтобы не задумываться каждый раз, какую функцию использовать в новой анимации.
Всем спасибо за ответы, интересное обсуждение, много мыслей пришло.
>текст раскрывать справа
Я пробовал, вроде... Но есть нюансы (долго перечислять). Вообще, сейчас это не важно, позже можно будет поменять без проблем. Делал это меню как универсальный компонент (типа встроенных Control), чтобы можно было использовать в разных системах игры (и не только этой). Сегодня вот занялся рефакторингом, а то там логика реакции на клик была свёрнута в непонятный клубок - теперь стало лучше. Логику подсказки накидал за несколько минут чисто чтоб оценить концепт "подсказки с анимацией, которые не мешают использовать меню по назначению, но бросаются в глаза новичку с первого взгляда".
Но задумка была "привлечь внимание к всплывающей подсказке", так что сдвиг иконки вбок более чем оправдан, на мой взгляд, типа "подвинься, я тут тоже важна". На нажатие/выбор это никак не влияет, т.к. выбор зависит только от сектора круга непосредственно под курсором мыши. В реальной игре можно добавить настройку для отключения этой анимации и/или подсказок.
По моему опыту, UI игр часто страдает от "баннерной слепоты" - когда игрок не замечает элемент UI, рассматривая его как визуальный шум, декорацию. Часто замечал за собой такое - тыкаюсь в новую игру и не замечаю какой-нибудь текст, загнанный в угол экрана, где мне чётко говорят, что я должен делать. Толку от такой незаметной подсказки мало... Впрочем, также я слышал мнение, что игра должна быть интуитивно понятной без навязчивых подсказок. Наверное, всё сильно зависит от жанра игры.
>>7893
>Очень приятно выглядит. Идея хорошая и интуитивная.
Правда? Спасибо. Думаю, "приятность" там за счёт анимации. Анимации любой UI делают намного приятнее. Жаль, что в большинстве игр UI слишком "жёсткий" - практически не реагирует на взаимодействие.
>не нужно наклонять голову вбок
Лол, это ирония? У меня там весь текст набок наклонён. Это типа стиль такой... перекошенный. Возможно, подсказку лучше всё-таки выровнять, но это тоже потом легко поменять, если что.
>>7898
>Анимировал твинами?
Да. Можно и на AnimationPlayer сделать, но с твинами такое проще выходит.
>>7899
>Шея болела ужасно
Может, у тебя сверхширокий монитор или ты слишком близко к нему сидишь? Или слишком долго. Причин может быть масса, обвинять игру за такое как-то немного странно. Хотя поддержка играми сверхшироких дисплеев важна:
>почему-то мода на сдвиг текст вправо появилась
Плохо, если так. Это раньше квадратные экраны были, сейчас один монитор может быть как два 16:9 (т.е. буквально 32:9). Игровой интерфейс должен учитывать такие сверхширокие мониторы, размещая информацию (шкалу здоровья, подсказки и т.д.) близко к центру экрана, и при этом учитывать, что у кого-то до сих пор может быть 16:10 или даже ещё меньше по ширине (если этого не учитывать, то интерфейс молча уезжает за границу экрана).
>>7901
>иконка не будет слишком "прыгать"
Этот резкий "прыжок" ощущается так из-за TRANS_BOUNCE...
>>7905
>Возьми ту же IDE
IDE отличаются от игр тем, что могут растянуть свой UI на весь экран без каких-либо последствий, и вообще не сильно париться о UI/UX, если программа важная и нужная. Для игр же расстояние между отдельными элементами UI важнее всего, и ощущения от использования критичны.
>понимать такие очевидные вещи и сразу сделал центрирование по центру
Лол, на самом деле это как бы поведение по-умолчанию... Хотя раньше я экспериментировал с открытием вложенных субменю вокруг сектора надменю (видео скидывал сюда в мае-июне), и в результате менюшки могли даже уезжать за границу экрана. Это было прикольно в теории, но, побаловавшись с ними, я решил, что пока что лучше сфокусировать их все в одном месте, даже если они перекрывают друг друга. Сдвиг кнопки-иконки в центр - это тоже такая "прикольная фишка" системы меню - субменю теперь зависят от этой фичи (на видео не видно, но "кнопка категории" может быть центральной кнопкой субменю, занимая место круглого "(X)" по центру - мне казалось это крутой фичей), а описание просто приклеено к этой иконке через контейнеры и убрать его куда-то будет не так-то легко. Короче, рефакторить надо, чтобы всё это разделить и сделать более свободным. На данный момент я даже не могу дизайнить эти меню в редакторе сцен (WYSIWYG) - оно полностью генерируется из кода по структуре данных, что значительно ограничивает их гибкость как универсального модуля. А у меня столько разных идей/планов было на это меню...
В общем, расположение по центру - по сути, случайное стечение обстоятельств (но мне понравилось, как это выглядит).
>>7910
Согласен, в подобных играх альтернативы "весь текст лентой сбоку" просто нет. Куда ещё его загнать? Вниз экрана тоненькой полоской на всю ширину? Читать узкую ленту сбоку проще, чем широкую снизу. А над головами персонажей не стали отображать, наверное, чтобы не выглядело как мобильная гиперказуалка, плюс история реплик может быть важна для выбора опций. Главное, чтобы эта лента с текстом не уезжала на самый край какого-нибудь супер-игрового 32:9 с изгибом вокруг головы на 180 градусов.
>>7921
>Нынешняя
Каждый раз забываю, что именно мне нужно, и в этот раз использовал TRANS_BOUNCE...
>TRANS_BACK
>как раз этот тип у тебя использован же
Глянул код - и правда. Как ты угадал? Я-то уже совсем забыл, что я там использовал. Наверное, нужно как-то где-то сделать себе "стандарт анимаций в проекте", чтобы не задумываться каждый раз, какую функцию использовать в новой анимации.
Всем спасибо за ответы, интересное обсуждение, много мыслей пришло.
37 Кб, 156x165>>7889
ууууааааа привстал
ууууааааа привстал
>>7889
Поправил анимации + добавил блюр...
Как вы боретесь с желанием писать "оптимальный" код?
Внезапно осознал, что в прошлом году пытался сделать эти меню "оптимально", экономя на спичках, и в результате код получился трудночитаемым, а встроить в него что-то новое невозможно без переписывания кучи кода по-новому. Зачем я это делал? Эти меню никогда не будут существовать в огромных количествах, можно было бы просто накидать отдельных нод.
Скорее всего, на меня повлияло то, что в некоторых играх меню очень сильно тормозят, но я даже не знаю, от чего они там (на других движках) тормозят - может, там кто-то XML с диска при каждом открытии меню читает, парсит, и заново создаёт все UI объекты - мало ли у кого какие костыли. В Godot нужно сильно постараться, чтобы типичный игровой UI начал тормозить.
Поправил анимации + добавил блюр...
Как вы боретесь с желанием писать "оптимальный" код?
Внезапно осознал, что в прошлом году пытался сделать эти меню "оптимально", экономя на спичках, и в результате код получился трудночитаемым, а встроить в него что-то новое невозможно без переписывания кучи кода по-новому. Зачем я это делал? Эти меню никогда не будут существовать в огромных количествах, можно было бы просто накидать отдельных нод.
Скорее всего, на меня повлияло то, что в некоторых играх меню очень сильно тормозят, но я даже не знаю, от чего они там (на других движках) тормозят - может, там кто-то XML с диска при каждом открытии меню читает, парсит, и заново создаёт все UI объекты - мало ли у кого какие костыли. В Godot нужно сильно постараться, чтобы типичный игровой UI начал тормозить.
>>7932
Не пишу никакого вовсе, но то я, не будьте такими как я.
> Как вы боретесь с желанием писать "оптимальный" код?
Не пишу никакого вовсе, но то я, не будьте такими как я.
>>7932
Может мои познания устарели, но наклоненные шрифты это зло, поскольку дизайнер редактируя шрифты расставляет хинты чтобы он хорошо и четко смотрелся. Я сам правда не смотрел долго на проги где был бы наклоненный текст, и не знаю будут ли от этого сильно вытекать глаза.
Может мои познания устарели, но наклоненные шрифты это зло, поскольку дизайнер редактируя шрифты расставляет хинты чтобы он хорошо и четко смотрелся. Я сам правда не смотрел долго на проги где был бы наклоненный текст, и не знаю будут ли от этого сильно вытекать глаза.
Так где встроенная возможность создания моделей?
Я не хочу осваивать шизо-Блендер просто для того, чтобы модели делать.
Я не хочу осваивать шизо-Блендер просто для того, чтобы модели делать.
12 Кб, 425x115>>7956
Выбери LOD. Выбери LOD Range. Выбери LOD Ноду в 3-ке. Выбери Visibility Parent в 4-ке.
Выбери LOD. Выбери LOD Range. Выбери LOD Ноду в 3-ке. Выбери Visibility Parent в 4-ке.
>>7989
Варежку прикрой и работай.
Варежку прикрой и работай.
>>7976
Лоды чисто визуальные. VisibilityEnabler еще по физике и процессам.
Лоды чисто визуальные. VisibilityEnabler еще по физике и процессам.
>>7975
Я создаю через CSG меши и их булевые операции прямо в движке. Потом перегоняю в обычный мешинстанс плагином. Но у меня стиль подходящий, хз чего там у тебя.
Я создаю через CSG меши и их булевые операции прямо в движке. Потом перегоняю в обычный мешинстанс плагином. Но у меня стиль подходящий, хз чего там у тебя.
>>7845
Так load() и image.load() это разное, разве нет?
И я изображения открываю через диалог open file.
Так load() и image.load() это разное, разве нет?
И я изображения открываю через диалог open file.
>>7989
Какой вопрос такой и ответ.
Для серьезного создания моделей тебе понадобится блендер
Для простых штук - CSG и конвертировать их в OBJ. Но так что угодно ты не сдедаешь и остается вопрос с текстурированием - UV развертку то как то редактировать придется.
Да и много чего еще.
Ну а дальше захочется что-то делать с вершинами. Какой-то инструмент добавить типа скульптинга. Или array вдоль path. Ну вот там без surfacemeshtool никак. А там и поймешь что это совсем не страшно, что все модельки это просто несколько массивов чисел.
Какой вопрос такой и ответ.
Для серьезного создания моделей тебе понадобится блендер
Для простых штук - CSG и конвертировать их в OBJ. Но так что угодно ты не сдедаешь и остается вопрос с текстурированием - UV развертку то как то редактировать придется.
Да и много чего еще.
Ну а дальше захочется что-то делать с вершинами. Какой-то инструмент добавить типа скульптинга. Или array вдоль path. Ну вот там без surfacemeshtool никак. А там и поймешь что это совсем не страшно, что все модельки это просто несколько массивов чисел.
>>7999
Так есть хоть одна адекватная альтернатива Блендеру на сегодня, без шизофрении или точно нет?
И нет смысла и пробовать другие тогда а сразу нужно окунаться с головой в шизу?
Так есть хоть одна адекватная альтернатива Блендеру на сегодня, без шизофрении или точно нет?
И нет смысла и пробовать другие тогда а сразу нужно окунаться с головой в шизу?
>>8011
В моём текстовичке "тридэ редакторы" 42 программы для моделирования. Часть из них уже мертвы вместе с разработчиками, но более половины ещё работает.
В моём текстовичке "тридэ редакторы" 42 программы для моделирования. Часть из них уже мертвы вместе с разработчиками, но более половины ещё работает.
>>8044 (Del)
Лови свой репорт, уговорил.
Лови свой репорт, уговорил.
>>8044 (Del)
Сможешь ли ты сделать настолько крутую 3D графику, что "средняя поебота - Годот" не вывезет ее?
Многие аноны мыслят теоретическими понятиями и уже воображают себя настолько крутыми, что аж сам движок станет им препятствием
Просто сделай игру в соответствии с реалистичными ожиданиями. Плохому танцору ноги мешают
Сможешь ли ты сделать настолько крутую 3D графику, что "средняя поебота - Годот" не вывезет ее?
Многие аноны мыслят теоретическими понятиями и уже воображают себя настолько крутыми, что аж сам движок станет им препятствием
Просто сделай игру в соответствии с реалистичными ожиданиями. Плохому танцору ноги мешают
>>8044 (Del)
https://youtu.be/24Dho0ITq6w
https://youtu.be/n1Lon_Q2T18
Лучше сделаешь? Если да, тогда уже думай, что движок может стать тебе препятствием
https://youtu.be/24Dho0ITq6w
https://youtu.be/n1Lon_Q2T18
Лучше сделаешь? Если да, тогда уже думай, что движок может стать тебе препятствием
>>8044 (Del)
Средняя поебота это ты. Скиллов ноль, денег ноль, желания учиться ноль а понты нарезаешь как охуевший. Хртьфу.
Средняя поебота это ты. Скиллов ноль, денег ноль, желания учиться ноль а понты нарезаешь как охуевший. Хртьфу.
>>8063
Вот видишь, что бывает когда мусор не прибран - анончики сагрились.
Вот видишь, что бывает когда мусор не прибран - анончики сагрились.
>>7932
Стало заебись.
https://raw.githubusercontent.com/godotengine/godot-docs/master/img/tween_cheatsheet.webp
Приучаю себя к хорошим паттернам. Пишу чистый читаемый код, сразу же оформленный и сразу же с комментами. Давно уже нету проблемы попыток в оптимизацию, потому что паттерны уже достаточно оптимизированы, а больше на скриптовом языке и не имеет особого смысла.
>Поправил анимации + добавил блюр
Стало заебись.
>Как ты угадал?
https://raw.githubusercontent.com/godotengine/godot-docs/master/img/tween_cheatsheet.webp
>Как вы боретесь с желанием писать "оптимальный" код?
Приучаю себя к хорошим паттернам. Пишу чистый читаемый код, сразу же оформленный и сразу же с комментами. Давно уже нету проблемы попыток в оптимизацию, потому что паттерны уже достаточно оптимизированы, а больше на скриптовом языке и не имеет особого смысла.
>>8078
Так там из полноценных игр только недо Побег из Таркова.
Очерденой закос под Сталкер и даже не Метро.
Так там из полноценных игр только недо Побег из Таркова.
Очерденой закос под Сталкер и даже не Метро.
>>7845
Спасибо. Правильный код будет:
var image = Image.load_from_file(path)
var texture = ImageTexture.create_from_image(image)
$Sprite.texture = texture
Спасибо. Правильный код будет:
var image = Image.load_from_file(path)
var texture = ImageTexture.create_from_image(image)
$Sprite.texture = texture
>>8044 (Del)
Анон с нулевым скилом размышляет о своем месте в игровой индустрии в качестве игродела. Видит себя в роли жертвы глобального невежества. Хочет конеурировать с играми первого эшалона.
Анон с нулевым скилом размышляет о своем месте в игровой индустрии в качестве игродела. Видит себя в роли жертвы глобального невежества. Хочет конеурировать с играми первого эшалона.
228 Кб, 1540x800Как сделать игру на Godot за один час?
>>8137
Бляяя... Бамплимит уже. Посидите пока в этом. У меня куча дел.
Бляяя... Бамплимит уже. Посидите пока в этом. У меня куча дел.
>>8136
3д говно не предлагать, минимум 4д. И за 20 минут плиз. Очень надо. Вам что, жолко что-ли?
>гта 7
3д говно не предлагать, минимум 4д. И за 20 минут плиз. Очень надо. Вам что, жолко что-ли?
Текстуры как делать свои?
И где бесплатные и открытые ресурсы брать?
Чтобы хуяк-хуяк и в продакшн.
И где бесплатные и открытые ресурсы брать?
Чтобы хуяк-хуяк и в продакшн.
>>8114
Да, кому как не безыгорному анону с двача опускать все игры, выпущенные на движке за целый год... Ты, конечно, сделаешь что-то, что круче всех этих проектов вместе взятых.
Да, кому как не безыгорному анону с двача опускать все игры, выпущенные на движке за целый год... Ты, конечно, сделаешь что-то, что круче всех этих проектов вместе взятых.
>>8220
Да можешь не сохронять, в следующий раз еще чет сделаем
Да можешь не сохронять, в следующий раз еще чет сделаем