Сами вы его выбрали, или его выбрали за вас - это лучший тред из оставшихся. Я такого высокого мнения о Годотреде, что решил перекатить его здесь, в /gd/, столь заботливо предоставленной нам Абу. Спасибо, Абу! Я горжусь тем, что называю Годотред своим домом.
Итак, собираетесь ли вы остаться здесь, или же вас ждёт геймдевелопинг, добро пожаловать в Годотред-51. Тред любви, взаимопомощи и кэша процессора!
Шапка: https://hipolink.me/godothread
Предыдущий: >>951925 (OP)
Архивный: >>949247 (OP)
>>954699 (OP)
>добро пожаловать в Годотред-51.
А здесь безопасно?
Перегибаешь, вспомни где круглые меню используются в основном: обычно для каких-то быстрых действий в забитый экшеном момент, типа переключения оружия.
Годно!
Причеши, оформи - и на ассетлиб. Базарю, станешь легендой.
>>954723
>Не перегибаю ли я
Вынеси как можно больше фич в опции, пусть конечный девелопер конфигурирует на свой вкус.
>>954729
>где круглые меню используются в основном
А кому-то захочется круглое меню в пошаговой игре, тут-то ему свистоперделки и пригодятся.
>>954723
Воот, а потом принимайся за карусель-контрол. Есть такой паттерн.
>софтварный курсор
Как ты его создаёшь? Двигаешь ноду за мышкой?
Да. Причем в главном меню такие же кнопки и там все норм, но там они обычные. Эти создаю в пикрелейтеде вот так
for i in len(answers):
var _option_node = Button.new()
_option_node.text = answers["text"]
_option_node.theme = load("res://Scenes/UI/dialogue_button_theme.tres")
_option_node.alignment = HORIZONTAL_ALIGNMENT_LEFT
_vbox.add_child(_option_node)
_option_node.connect("pressed", _on_answer_selected.bind(answers["next"]))
в теме настроены только цвета, шрифты и тд.
Раньше в трёшке это реализовывалось путём организации ноды-спавнера в дереве так, чтобы она по дизайну находилась под курсор-нодой, и всё, что в ней спавнится, так же оставалось там. В четверке добавили возможность вручную задавать z-индексы. То есть курсору сразу задаёшь индекс 100500 и он гарантированно будет поверх всех. ХЗ, что у тебя не получается. УМВР.
>быстрых действий
>типа переключения оружия
Хех, в GTA Online они максимально всрали их меню переключения оружия: категорий много и почти в каждой категории можно купить десяток пушек, которые можно листать только по одной штучке, из-за чего быстрота выбора полностью теряется. Радиостанции тоже всрали, но их хотя бы можно скрыть по вкусу, и то на эту фичу 10 лет ушло.
В нашумевшем Palworld (сделан на Unreal) билдменю максимально всратое потому, что на каждом колесе фиксированное число кнопок, и они переключаются последовательно нажатиями кнопок влево-вправо, а страниц-категорий дохрена, т.е. у них там обратная проблема колеса оружия из GTA Online.
В The Sims вроде бы вообще тупо кнопки по кругу расставлены, т.е. на них нужно наводиться точно. В полноценном круглом меню секторы регистрируют наведение и клики мыши за пределами "кнопки".
Я читал, что круглые меню в играх появились из-за консолей, на которых сложно листать списки, а вот окружность стиком легко доступна. Но ты подумай: преимущество круглого меню в том, что все кнопки одинаково удалены от центра и их фактический (т.е. тактильный) размер намного больше визуального. Идеальный способ ввода для мыши и лентяев.
Если сравнить:
Списковые меню и меню квадратной сеткой: разное расстояние от кнопки до позиции курсора мыши по умолчанию, кнопки зачастую мелкие, а большие кнопки увеличивают расстояние крайних кнопок до позиции курсора мыши по умолчанию.
Табы/страницы: те же проблемы, что и у списковых меню, но табы, как правило, достаточно большими не сделать, сеткой не разместить, и от своего контента они зачастую загнаны на самый край экрана.
Главная проблема тут - юзеру необходимо целиться мышкой в желаемую кнопку. Чем меньше кнопка, тем сложнее прицелиться; чем больше кнопка, тем шире взмахи мышкой, но широкие взмахи всегда сложнее контролировать. В ОС даже придумали специальное ускорение курсора для решения этой проблемы, но в компьютерных играх это решение только мешает. Круглое меню решает проблему, позволяя без прицеливания махнуть мышкой и попасть в сектор; прицеливаться нужно только в центр, если он есть.
Круглые меню не панацея, но показалось интересным попробовать сделать из них что-то большее, чем одно нажатие на сектор круга. Может быть, даже можно реализовать инвентарь с переносом предметов? В инвентарях часто не хватает/используются группы предметов, и всё, что нужно - перенос из/в сундуки.
Да, криворукий, близорукий, не попадаю по кнопкам.
>>954750
>Причеши, оформи - и на ассетлиб.
Да, думал об этом, но как-то не очень хочется. Как минимум, много работы для нормального релиза. И вообще устал от этих меню, хочу игру делать. А если вдруг это станет популярным, появится 9001 игра с одинаковым дизайном, а это как-то не круто. Ничего особо сложного в этих меню нет, но большинство разработчиков, скорее всего, будут просто бездумно втыкать в свой проект, не меняя никаких настроек. А кому очень надо - те и с нуля сами написать смогут.
>Вынеси как можно больше фич в опции
Но чем больше опций - тем медленнее основной функционал из-за проверок в коде. Тем более пока сомневаюсь, что делать для рендеринга градиентов и текстур на место секторов (там сейчас draw_arc).
>карусель-контрол
Функцию предпросмотра чего-то на карусели легко заменить круговым меню, даже если элементов несколько десятков (сотни нужно группировать, а то будет сложно). Карусель имеет смысл, когда тебе нужно убрать подальше что-то старое и ненужное (как меню последних задач или рабочие столы на Android), разве такое часто встречается в играх? Для очень большой галереи (сотни снимков) лучше уж простую сетку нарисовать, чем листать поштучно.
Уверен, что базовая карусель в Godot делается за считанные строчки кода, и это с учётом анимаций.
>Вроде проблема не с z-индексом, у кнопок он 0, у курсора максимальный поставил.
>>954759
>Button.new()
А курсор находится где? Z-индекс неявно зависит от положения ноды в сцене (потомки отображаются поверх своих предков, но ниже следующих нод).
По умолчанию у всех CanvasItem нод стоит это:
https://docs.godotengine.org/en/stable/classes/class_canvasitem.html#class-canvasitem-property-z-as-relative
Попробуй отключить.
Я бы просто поместил курсор в самый нижний конец дерева, так он 100% будет выше всех. Игру и весь остальной контент вставляешь в середину дерева. Стандартный механизм переключения сцен мне всё равно совершенно не нравится.
Спасибо за ответ, я разобрался, у меня эти кнопки были в отдельном канваслеере по гайду для юая с ютуба, поэтому они и были поверх, в итоге вынес курсор тоже в отдельный канваслеер и сделал его самым верхним.
>были в отдельном канваслеере
>тоже в отдельный канваслеер
Не знаю, зачем тут CanvasLayer, сцена-то простая.
Хотя я вообще не очень понимаю роль CanvasLayer. В отличие от Viewport, текстуры не создаётся, только меняется порядок отрисовки. Но порядок отрисовки уже регулируется порядком нод и Z-индексом. Ну и зачем тогда слои, если роль слоя каждая CanvasItem выполняет своим положением и индексом? Если только всё очень сложно и запутанно в проекте.
Тем более на Node3D они вообще не влияют...
>>954759
>len(answers):
Думаю, лучше использовать .size():
len() ожидает Variant и принимает в т.ч. String.
.size() есть только у Array и Dictionary и тут ты
спрашиваешь конкретный объект, а не Variant.
Ну и как-то читать легче ("для i в ответов.размер").
Во всяком случае, никогда не видел, чтоб вот так использовали len(), и сам пользуюсь только .size() (у String, если нужна длина строки, есть .length()).
> Не знаю, зачем тут CanvasLayer, сцена-то простая.
Чтобы на ui диалога не действовал зум камеры
про size и len понял принял
ГОДО ДЕЛАТЬ ИГРА!
>DOF Far Blur в html под GLES2
Я по-быстрому протестировал здесь, на Firefox:
https://editor.godotengine.org/releases/3.6.beta5/
Похоже, что код шейдера сломан или несовместим.
DOF Near Blur вообще вываливает странные ошибки.
>как лечить?
Ковыряться в исходниках движка, если очень надо.
Из моего опыта на 3.x ветке, блюр очень затратный.
>Похоже, что код шейдера сломан или несовместим.
>Ковыряться в исходниках движка, если очень надо.
Спасяб за подсказку.
Если у предмета отключать коллизию, то во время отпускания предмета если игрок находился внутри предмета, происходит толчок и игрок может провалиться через текстуры. Плюс неприятно из-за того что игрок может видеть сквозь текстуры переносимого предмета.
Как сделать так, чтобы игрок мог носить большой предмет, сталкиваться с ним, но не летать на нём? Делать проверку позиции hand по высоте относительно ног игрока, чтобы выпусткать предмет из рук при отрицательном положении Y?
Я бы сравнивал положение игрока по обоим вертикалям с положением предмета, и если они достаточно близко и предмет ниже, то ронять. Ещё можно заделать метод, определяющий на чём игрок стоит, но тут ньюанс в том, что можно будет летать подпрыгивая на предмете и подтягивая его за собой, как в старых версиях халвы
Но есть загвоздка. Если предмет широкий, как, например огромный поддон или дверь, то можно сесть на край и поднять его, тем самым снова сооружая ковёр-самолёт.
Зная размер объекта и его поворот, можно определять его ближайшую точку к игроку. Но тут надо использовать проверку на чём стоит/находится прямо над игрок. Хотя как ни крути, а всякие приколы игрок найдёт, как летающие машины в ботве, где игрок одну вагонетку кладёт на другую, забирается на верх и магнитом поднимает нижнюю.
Я заметил, что софтварный курсор который я сделал не точен на некоторых объектах, сначала грешил на то что хотпойнт кривовато стоит, но оказалось дело не в этом.
Выглядит будто точка от которой считается global_position у спрайта меняется при его движении или типа того.
Вот записал видео, там софтварный курсор и хардварный с одинаковой картинкой
софтварный двигаю кодом
cursor.get_child(0).global_position = player.get_global_mouse_position()
И видно что в правой части экрана расхождение между курсорами по оси х больше.
У меня это вызывает недоумение.
print(cursor.get_child(0).global_position, " ", player.get_global_mouse_position()) выдают одинаковые значения
>Делаю игрушку с физическими механиками
Я тоже, в каком-то смысле. Много проблем...
Планируешь заменять встроенную физику?
https://github.com/godot-jolt/godot-jolt
>на Godot 4.3 (пока ещё бета).
Почему сразу 4.3? Говорят, там ещё не всё починили. Стабильные ветки действительно стабильны, а вот все эти бета-сборочки часто могут сцены ломать. Но дороги назад нет, если не сделал бэкап 4.2 проекта.
>Если взять большой предмет с которым игрок должен сталкиваться, и иметь возможность его двигать через grab, он может просто запрыгнуть на него, потянуть вверх и полететь как на ковре-самолёте.
У меня обратная проблема была: игрок должен мочь передвигаться по поверхности подвижного объекта, но не мочь толкать объект как ракетный двигатель, непосредственно на нём находясь.
В Godot 4 теперь есть решение обоих проблем:
https://docs.godotengine.org/en/stable/classes/class_collisionobject3d.html#class-collisionobject3d-property-collision-layer
>Note: Object A can detect a contact with object B only if object B is in any of the layers that object A scans.
Пример 1: игрок сканирует препятствия, но подвижное тело игрока не сканирует, результат - только игрок сталкивается с подвижным телом и двигается от него, тогда как подвижное тело игрока совсем игнорирует.
Пример 2: подвижное тело сканирует игрока, но игрок подвижное тело не сканирует, результат - подвижное тело сталкивается с игроком и двигается от него, тогда как игрок подвижное тело совсем игнорирует.
...но тут есть нюансы:
В первом примере, если игрок встанет между двумя препятствиями, они его проигнорируют и игрок будет "раздавлен", но поскольку игрок бесконечно твёрдое тело, он выскочит куда-нибудь, куда захочет движок. Решение: убивать и респавнить игрока, либо делать анимации/регдолл для этой конкретной ситуации.
Во втором примере, подвижное тело будет, конечно, отскакивать от игрока, но если игрок найдёт где-то возможность зажать тело в углу и прыгнуть на него, тогда высока вероятность, что тело уйдёт под землю или вообще улетит куда-то, ведь для тела игрок в данной ситуации - непреодолимое препятвие.
Как это решить:
- тестировать локации на защиту от дурака;
- респавнить объект, если он улетел куда-то;
- не делать лишних платформ, которые игрок может одновременно тащить и стоять на них;
- вообще отказаться от возможности тащить то, на чём ты в данный момент стоишь (лол, зачем?).
>летающие машины в ботве, где игрок одну вагонетку кладёт на другую, забирается на верх и магнитом поднимает нижнюю
Это легко пофиксить, если кидать рейкаст от игрока в желаемом направлении и магнитить только самый первый объект на пути рейкаста. Физически, это наиболее логично: если два предмета магнитятся, то первым примагнитится тот, что ближе.
Вопрос в том, нужно ли запрещать игроку фан?
>запрыгнуть на него, потянуть вверх и полететь
А-а-а, стоп... Ты имеешь в виду: сначала запрыгнуть, а уже потом потянуть? Единственным практичным решением тут будет определять, на чём игрок стоит своими ногами (это легко), и запрещать цеплять руками то, на чём стоим. Реальная проблема возникает только если игрок случайно наступит на то, что уже тащит, но это решается слоями физики - предмет отодвинется от ног сам по себе.
>Делать уровень сначала на затычках, постепенно заменяя их настоящими механиками, или сначала сделать все механики, а потом собирать из них уровень?
Я думаю, всё зависит от конкретной игры.
Если хочешь создать для игрока опыт, завязанный на локации, тогда сначала делаешь локацию, потом уже подстраиваешь механики под особенности локации.
Если хочешь сделать аттракцион весёлых механик, то сначала делаешь и отлаживаешь механики, потом уже вокруг них строишь все свои локации.
Скажем, если ты делаешь автобиографическую игру, сначала ты решаешь поставить в локации забор или дерево, а потом реализуешь механику карабкания по деревьям или перелезания через забор. Если же ты делаешь просто игру про паркур и всякие трюки в воздухе, то сначала делаешь механики паркура, уже после подстраиваешь локации, чтоб было весело эти механики использовать друг за другом.
Но тебе в любом случае потребуется какая-то тестовая локация для проверки механик, даже если финальная локация будет выглядеть совсем иначе. Тот же забор необходимо где-то поставить, чтобы тестировщик мог через него перебраться, иначе механику не потестишь.
>расхождение между курсорами по оси х больше
Может, у тебя там где-то масштаб не равен 1?
>выдают одинаковые значения
Естественно. Ты же их присваиваешь. Потом движок преобразует эти координаты относительно слоя:
https://docs.godotengine.org/en/stable/classes/class_control.html#class-control-property-global-position
>The node's global position, relative to the world (usually to the CanvasLayer).
>player.get_global_mouse_position()
Попробуй получать координаты от сервера:
>Returns the mouse's position in the CanvasLayer that this CanvasItem is in using the coordinate system of the CanvasLayer.
>Note: For screen-space coordinates (e.g. when using a non-embedded Popup), you can use DisplayServer.mouse_get_position.
ИМХО, ты всё слишком усложняешь.
Сначала отладь поведение курсора в изолированной сцене курсора, а уже потом добавляй эту сцену в игру.
>screen-space coordinates
А, не, это вроде относительно пикселей монитора?..
Обмажутся канвас лейерами и сдвигаются неточно...
У тебя случайно в винде не включено какое-нибудь масштабирование? Почитай вот про эту настройку и про stretch
https://docs.godotengine.org/en/stable/tutorials/rendering/multiple_resolutions.html#hidpi-support
Так это, просто отключай физику предмету когда он в руках.
>отключай физику предмету когда он в руках.
Так он это рассматривал же: >>954957
>во время отпускания предмета если игрок находился внутри предмета, происходит толчок и игрок может провалиться через текстуры. Плюс неприятно из-за того что игрок может видеть сквозь текстуры переносимого предмета.
Камера есть, у нее зум 0, тоже грешил на нее, пробовал удалить, но результат тоже.
Попробовал убрать курсор с отдельного канвасслоя, проблемы нет.
Просто я тогда не понимаю как правильно делать. Юай должен быть на отдельном канваслеере, чтобы не подчиняться камеере, скроллу и всему такому, так? Значит и курсор должен быть на отдельном канваслеере, чтобы он мог быть поверх интерфейса.
Пока писал увидел пост >>955012
С настройкой странно, я ее выключил и все заработало, а потом включил, но оно осталось работать. Но перед этим я пересоздал канвас леер после удаления в предыдущей проверке.
В общем я понял, что ничего не понял. Наверно я как-то починил расхождение между слоями пересоздав слой курсора, но это неутешительно.
>как-то починил расхождение между слоями пересоздав слой курсора, но это неутешительно.
Нужно было посмотреть, какие там настройки. А лучше всего создать бэкап сцены/проекта.
В Godot (4.2.2) до сих пор часто встречается проблема обновления актуальных значений в полях инспектора у внешних сцен. Т.е. ты вроде меняешь параметры во внешней сцене, а там, где ты их ожидаешь, они не изменяются как ты хотел... Сделал вывод, что лучше закрывать все лишние сцены и держать открытой только ту, с которой ты сейчас работаешь.
Похожие проблемы при переименовании и удалении скриптов и сцен. Лучше делать это, закрыв все сцены и скрипты, в которых этот файл используется, иначе потребуется перезагружать проект.
А вчера заметил, что инспектор не подгружает сразу актуальное содержимое enum в кастомном ресурсе. Пришлось перезагружать весь проект...
Ну, это всё не страшно, исправляется самим движком.
Я имел что-то вроде, объект rigid, чтобы с ним сталкиваться/толкать, но если поднял, он переключается в kinematic, прицепляется к персонажу и он ни в какие стены с ним заходить не будет. И вообще, вряд ли надо допускать ситуацию когда игрок оказыватся в объекте.
У анона проблема с пикрила:
1. Игрок встал на площадку.
2. Пытается взять площадку в руки.
3-а. Площадка толкает игрока вверх?
3-б. Площадка проходит сквозь игрока?
3-в. Площадка вылетает из-под ног?
3-г. Площадка не даётся в руки?
3-д. Площадка уменьшается?
Если ты предлагаешь коллиженшейп предмета добавить к коллизиям чарактербоди, тогда твой персонаж превратится из капсулы в капсулу с прямоугольником внизу.
Ну ты попробуй, потом покажешь.
Чуть чуть сложнее, там надо еще Area детектор пола в ногах. Я просто не понимаю что именно за механику анон хочет получить. В моем предствалении, если встать, например, на валун, и взяться за него руками, то ни поднять его нельзя, ни ходить пока ты стоишь на нем. Но если у него игра про серфинг на доске то это другая история и там могут появиться повороты.
Я не помню точно, капчую с телефона, но одна из двух кнопок на пикриле позволяет зайти в настройки и выбрать любое значение, в т.ч. дробное.
А, вспомнил, три точки - настройки освещения.
Transform - настройки трансформации.
Зато ты там можешь любое значение ввести, а не только выбрать одно из заложенных разрабами.
Вот у тебя на скрине вижу "1, 5, 10", а "other" нет. Как сделать привязку к сетке из 2, 3, 4 юнитов? А если мне необходима привязка к 0.575, 0.3, 0.025 юнита?
Впрочем, вся эта привязка не очень-то и нужна. Я задолбался со своим перфекционизмом, хочу уже просто слепить какое-нибудь говно играбельное...
>не нагуглил
https://www.reddit.com/r/godot/comments/qjqnxa/
>>955097 >>955099
А, вообще перепутал, нужно View нажимать (?).
Так редко этим пользуюсь, что не помню вообще.
>Впрочем, вся эта привязка не очень-то и нужна.
Ну а как без неё, если у тебя, допустим, модульные ассеты комнат, где метровые стены, молы и потолки? Без привязки ты не состыкуешь без щелей и наслоений.
>модульные ассеты комнат
>метровые стены, полы и потолки
Если у тебя квадратно-гнездовая застройка, пробуй:
https://docs.godotengine.org/en/stable/tutorials/3d/using_gridmaps.html
- автоматически оптимизирует повторения;
- автоматическая привязка к заданной сетке;
- можно иметь несколько разных в сцене;
- поддержка физики (StaticBody3D) и навмешей;
- более-менее удобно управлять из кода.
Минусы:
- поворот блоков по 90 градусов;
- у блоков нет анимаций, скриптов;
- не отдаёт свои коллизии в RigidBody3D (если хочешь делать модульный транспорт из кубиков);
- не оптимизирует полностью скрытые блоки (тут уже сам разбирайся, что показывать юзеру);
- оптимизации через мультимеш (это не Майнкрафт, в Майнкрафте сетка полностью перестраивается).
>>955106
Да, про гридмапс буквально сегодня читал. Это конечно больше для всяких платформеров и аркад больше подходит. Ну или для какого-нибудь аналога Майнкрафта. Это не то.
Да нормально можно высотку смастерить, если у тебя все панели одного размера - хватит одного гридмапа. Если у тебя панели разных размеров, можно использовать несколько гридмапов. Вот сделать что-то кроме панелек будет сложно.
Для воксельной игры нужен специальный аддон, потому что в воксельных играх нужны специальные оптимизации: грубо говоря, один чанк Майнкрафта - это не тысячи кубиков, а один меш со сложной процедурной текстурой. Поэтому Майнкрафт хорошо работает даже на слабых устройствах.
Тут аддоны (воксели, карты высот):
https://github.com/Zylann
Сделал Пакмана. Зачем?
>Just for LULZ
Ну не игры же делать.
Как же сложно без концеп-тортиста...
Я тебе про концепт ещё в прошлом году говорил, когда ты свою раскорячку-тян еще только создавал. но ты ж не хочешь по чужому концепту работать.
Скорее всего, лучше пройти ещё туториал. Но если у тебя большой опыт в другом движке, то можешь садиться пилить игру.
>Вот я прошел туториал, который "ваша первая 2д игра".
Всё понял? Получилось? Попробуй поиграть параметрами. Добавить новых функций. Переделать так, чтобы никто без подсказки не догадался, по какому туториалу ты это начинал делать. Буквальное и бездумное следование инструкциям в туториалах не способствует быстрому обучению.
>Или лучше еще игр по инструкции настругать?
Если ты только и делаешь, что повторяешь шаги этих инструкций, то толку от этого мало.
>Уже можно начинать пилить свою простенькую игрулю и походу разбираться?
Смотря что ты считаешь "простеньким". Многие новички хотят сразу свою "убийцу ГТА" делать, но считают это "простеньким" проектом, если откажутся от фотореализма, сложной физики, сюжета и озвучки... Но это по-прежнему экшн опенворлд в большом и сложном мире => сложный проект.
>Всё понял?
Ну процентов 90.
>Попробуй поиграть параметрами.
Пробовал.
>Переделать так, чтобы никто без подсказки не догадался
Так может все таки лучше новую начать?
>Смотря что ты считаешь "простеньким". Многие новички хотят сразу свою "убийцу ГТА" делать
Думал с автобатлера начать. Чтоб не душится сразу с многими аспектами работы с движком, сосредоточиться на поведении мобов, анимациях, балансе для начала.
Попытался сделать зеркало через рендер в SubViewport второй камерой, с зеркально отраженным вращением/положением. А там оказывается сабвьюпорт не получает информацию от источников света из основного вьюпорта (кроме Environment нода). На пикриле работа зеркала, что есть свет, что нет света, зеркальная камера в суб-вьюпорте рендерит одинаково без света.
Можно отражение в черно-белое перевести, но я хотел геймплейные моменты обыграть с зеркалами, которые работают не так как обычные в квартире.
Очередная жопа.
слу. а где интерактив айтем и переходы двери между локациями?
То ли в прошлом, то ли в позапрошлом треде выкладывал, базовое взаимодействие с объектами, подбор предметов, использование оных из инвентаря.
Переходы между локациями начну когда отработаю базовые функции внутри квартиры. Вот сейчас затык с зеркалом.
>в прошлом году ... тян ещё только создавал
Конкретно её начал в 2021. По жопе определил. ( ͡° ل͜ ͡°)
Общая концепция игры тянет свои гнилые корни с 2019.
>не хочешь по чужому концепту работать
Дело не в этом. Просто... нет, всё не просто. Попробую объяснить.
Хотел игру со строительством и ремонтом летающего транспорта "из говна и палок" или "тяп-ляп", при этом хотелось разрешить строить как угодно и где угодно без ограничений (отдельный 3D редактор каркаса в столе крафтинга сразу идёт мимо). Но на практике оказалось, что "строить как угодно без ограничений" (тяп-ляп) означает кучу проблем как игроку, так и игре. Намного удобнее строить, когда игра помогает тебе привязкой к чему-либо, и намного проще решать технические вопросы, когда дизайны транспорта имеют строгие правила.
Тогда я сделал точки крепления на краях панелей, но разрешил поворачивать практически на любой угол. И снова идея казалась замечательной в теории (можно было быстро слепить почти идеальную сферу из квадратных панелек, и она даже катилась по физике как шар), но на практике любой угол кроме 90 градусов ведёт к неровным дыркам, а как обрабатывать такого монстра из кода я даже не хочу думать (нужно было как-то соединять ближайшие точки крепления, а их буквально тысячи).
Ладно, решение очевидно - запретить все углы кроме 90. Но тогда получается, что строить из квадратов можно только "кубики", и для чего-то неровного нужны кучи отдельных блоков. Проблема отдельных блоков не только в том, что их нужно как-то смоделировать и описать правила сцепления между ними, но ещё и в том, что игроку придётся в менюшках копаться в поисках подходящих под его идею блоков (или - о, ужас! - листать колёсиком). Копание в десятках подвидов блоков противоречит изначальной задумке "тяп-ляп из говна и палок и полетели". Но вместе с тем хотелось бы чего-то привлекательного внешне, а не только летающие избушки из кубов.
В итоге пришёл к такой мысли: да, постройка состоит из "кубов" (вокселей), но характеристики этих кубов выбираются по их окружению, например, если у тебя три куба буквой "Г", то генерируются дополнительные треугольные опоры, якобы удерживающие эту конструкцию (наверняка видел ИРЛ). Что-то такое рассматривал для статичных зданий в прошлом, но далеко не зашёл. Чем-то напоминает "wave function collapse" или "марширующие кубы". Получается, игроку достаточно накидать кубов, а игра сама добавит декоративные детали, никак не влияющие на геймплей. Здесь учитывается необходимость часто накидывать новые кубы взамен разрушенных.
Кроме того, думал о том, что панели можно генерировать процедурно, расставляя деревянные балки в MultiMeshInstance3D (ИМХО, лучше, чем генерировать меш, если не смотреть на текстуры), что я этой ночью и накидал в сыром виде. Берём четыре точки, из них два ребра, находим середину, по шагам расставляем, поворачиваем и растягиваем одну и ту же балку с небольшой случайной вариацией - тяп-ляп панель произвольной формы готова - сам в шоке, но это проще, чем кажется. Правда, я только две оси из трёх осилил, по третьей ломается, но это не важно. Ещё непонятно что делать с коллизиями: для плоского квадрата всё просто, а что если образуется два треугольника? Да и геймплейно это никак толком не использовать без отдельного GUI - если только игра сама будет правильные формы создавать, типа тех же треугольников в случае расстановки кубов в форме "Г".
Короче! Завидую и отвлекаюсь на дизайн кораблей из игры, где корабли по геймплею создаются один раз в специальном GUI и никак не меняются до следующей остановки, тогда как моя игра, по задумке, про отчаянные попытки заткнуть дырки в непрерывно разрушающемся, гнилом и дырявом корыте, которое в любой момент может расколоться на два дырявых корыта или осыпаться балками игроку на голову, рванув самопальным двигателем и закрутившись вокруг своей оси на оставшихся, пока игрок латал дырки в попытке сохранить плавучесть. Игроку должно быть НЕКОГДА наводить красоту и выбирать треугольники из списка треугольников, НЕКОГДА дизайнить каркас причудливой формы в особом 3D редакторе каркасов, НЕКОГДА строить огромную сферу из деревянных квадратов. Но результат хотелось бы получать более-менее привлекательный геометрически (на любителя), а не вот эти унылые одинаковые кубы поверх кубов рядом с кубами под кубами. И чтоб внутри работала AStar навигация.
Почему всё так сложно? Пытаюсь совместить несовместимое? Хочу быстро, дёшево и красиво?
А ты типа компонентами все это сделал? Интерактив компонент на залупу вешаешь и она становится интерактивной. Или как?
Я просто только вкатываюсь и оче интересно, как про делают разное.
" so I learned unity by making Mario, you can watch how it went on my youtube! At the end of 2021 I switched to the Godot Engine and haven't looked back!" - https://www.twitch.tv/jackie_codes
Немного мотивации
>залупу вешаешь и она становится интерактивной
Ну да, вроде того.
Интерактивный объект (у меня называется Interactable) это отдельная сцена. В этой сцене содержится Area3D, с которым можно отследить столкновение и скрипт, позволяющий задать текст при взаимодействии и возможные опции (такие как выбор "Yes" или "No", при взаимодействии с выключателем света).
У персонажа перед носом свой Area3D который детектит столкновение с любым Interactable.
Затем, в игровой сцене, на нужные объекты, вешается экземпляр Interactable, каждому из которых присваивается свой текст при взаимодействии и опции. Если какой-то Interactable требует особых заскриптованных действий, ему присваивается новый скрипт, который расширяет класс Interactable переопределяя метод `interact'. Например, предметы, это класс Pickable, который является наследником Interactable с переопределенным методом `interact`.
>Интерактивный объект (у меня называется Interactable) это отдельная сцена
А такое возможно?
Я просто рили тупой и компонент такой написал бы скриптомю
Вот ещё стримы, возможно, кому-то помогут
>Я просто рили тупой
Ты не тупой, ты просто документацию не читал.
https://docs.godotengine.org/en/stable/getting_started/introduction/key_concepts_overview.html#scenes
>In Godot, you break down your game in reusable scenes. A scene can be a character, a weapon, a menu in the user interface, a single house, an entire level, or anything you can think of. Godot's scenes are flexible; they fill the role of both prefabs and scenes in some other game engines.
>You can also nest scenes. For example, you can put your character in a level, and drag and drop a scene as a child of it.
>>955171
>Я просто только вкатываюсь
Читай пока документацию.
>оче интересно, как про делают разное.
Если будешь копировать кого-то без понимания основ, получится каргокультинг - когда нуб пытается внешне повторить то, что видел у кого-то, не понимания, почему этот кто-то делал именно так, а не иначе. Получаются бесполезные чучела самолётов, которые делали аборигены, думая, это такой сигнал богам для сброса качественных припасов.
Можно рассматривать каждую отдельную сцену как класс, построенный по принципу композиции. Фактически, каждая сцена, это твой компонент.
>>955180
>Когда звуки добавишь?
Когда найду подходящую модельку тни и нейронку чтобы сгенерировать голос для начальной сцены (фраза "I'm starving" истощенным голосом).
Я инженер по обранизаваниманию, алло.
Я просто не могу делать говняно.
>класс, построенный по принципу композиции
Залупная хуита.
Только компоненты.
>Когда найду
Ясно, ты не понял. Пересмотри ещё раз >>955180 со звуком.
А теперь ответь на вопросы:
1. Почему у тебя "управление танчиком" (поворот на месте)?
2. Как часто ты ходишь по квартире задом, не оборачиваясь?
Теперь поделай игры без туториала, используя только документацию.
Можешь начать с клонов простых аркадных игр: Понг, Арканоид, Космическая Гонка и т.д. Главное - доводи их до конца. Чтобы были условия победы, поражения, меню. И чтобы были соответствующие экраны, и чтобы все это работало.
А ты количество полигонов в моделях как-то контролируешь? А то по внешнему виду кажется, будто эта швейная машинка может быть самым плотным сгустком полигонов в твоей сцене. Конечно, актуальные версии Godot уже могут в auto LOD, но это увеличивает затраты памяти и стремится к максимальной разумной детализации. Алсо, возможно у тебя там "бутылочка гнума" в моделях, а ты даже и не знаешь об этом, если не проверял всё вручную. Конечно, сейчас полигоны не такие дорогие, как раньше, но тормоза всё равно могут вызывать.
Почему ты записываешь с частотой кадров то 30, то вовсе 25?
Сколько кадров может выдать твоя сцена без записи (на твоём ПК)?
https://docs.godotengine.org/en/stable/classes/class_performance.html
>$Label1.text = str(Performance.get_monitor(TIME_FPS)) # больше - лучше
>$Label2.text = str(Performance.get_monitor(TIME_PROCESS)) # меньше - лучше
>вопросы:
Текущая модель это времянка для работы. Базовая механика, более подходящие анимации и параметры скоростей будут задаваться на основной модели.
>>955191
>А ты количество полигонов в моделях как-то контролируешь?
Да, стараюсь, но работы много получается, так что проскакивает на что-то забиваю с мыслью "потом заменю".
>А то по внешнему виду кажется, будто эта швейная машинка может быть самым плотным сгустком полигонов в твоей сцене
Почти. 5300 треугольников. Много. Но страшнее всего - часы на кухне, 7500 треугольников после редактуры (оригинальная модель содержит 12000+ треуголников). Стараюсь брать мелочь на 1000 и меньше, свыше 1000 только большие и заметные объекты, либо мелкие но с приблежением камеры.
>Почему ты записываешь с частотой кадров то 30, то вовсе 25?
Чтобы экономить место на диске.
>>955195
>Сколько кадров может выдать твоя сцена без записи (на твоём ПК)?
25-35 кадров. 60 если выключить лампы хотя бы в 2х комнатах. Тени жрут.
Ну норм, отражение как в ГТА5 на настройках уровня качества "нормальное".
>Как часто ты ходишь по квартире задом, не оборачиваясь?
А я вот часто так хожу. Места для разворота мало, квартира тесная, кость широкая.
> Пытаюсь совместить несовместимое?
Да.
> Хочу быстро, дёшево и красиво?
Да.
> Игроку должно быть НЕКОГДА
Игроку должно быть интересно.
> на практике любой угол кроме 90 градусов ведёт к неровным дыркам
Загугли платоновы тела. Там и углы будут.
Вот так делай.
А я может быть тоже бот. Просто я органический бот. Органический наноконгломерат на основе белкового синтеза в углеводно-аммиачном цикле. Оснащённый органической нейросетью.
Есть игра про хождение по комнатам, каждая комната это своя сцена, в них можно что-то делать пойнтэндклик квест да
Нагуглил два метода сохранять состояние комнат и потенциально сохранять игру - паковать сцену в ресурсы и распааковывать при необходимости или вести где-то огромный справочник переменных о состоянии комнат и их объектов и работать только с ним.
И я забыл задать собственно вопрос довольно очевидный
Какой из методов лты посоветуешь
Меня наверно обоссут, но я сцены не меняю и подгружаю/выгружаю их внутри одной основной
Нет, это нормальный метод работы. Тебе удобно - так делай. Какая разница, где в дереве будет игра.
>>955275
> два метода сохранять
> паковать сцену в ресурсы и распааковывать при необходимости
Оверхед. Оверкилл. И прочие оверы. Нирикаминдую.
> вести где-то огромный справочник переменных о состоянии комнат и их объектов и работать только с ним
Способ рабочий и старинный. Но есть много нюансов с ним. Самый главный - работа только в коде. Нет визуального представления. Если ты сделаешь к этому справочнику обёртки для доступа к данным, тебе будет легче работать. Самое простое - это сделать две функции
> set_data(key, value)
> get_data(key. dafault, make_key = false)
Пераметр key передавать полным строковым путём к ключу в словаре словарей, то есть, скажем, основной словарь называется world у него есть ключ location и у него значение тоже словарь, а у того словаря есть ключ door у которого значение тоже словарь, а того словаря есть ключ open который буль и значение true. Чтобы записать туда значение, ты вызываешь:
> saver.set_data("world/location/door/open", false)
Чтобы получить значение
> var door_open = saver.get_data("world/location/door/open", false)
Параметр make_key нужен, чтобы вписывать в словарь значения при первом обращении. Иногда такой функционал нужен.
Функции парсят входящий путь банальным сплитом и в цикле пытаются идти по пути, проверяя, является ил следующий элемент массивом? Если нет, возможны варианты. Если да, о доходят до конца пути и работают со значением, если оно есть. Если нет, опять же, варианты.
Я делал подобную систему, только я делал ещё замороченнее. У меня менеджер сохранений при создании получал ссылку на ридонли словарь1 (эталонные данные), и получал ссылку на ридрайт словарь2 (то что будет действительно сохраняться на диск). Логика работы такова: запись данных только в словарь2. Чтение, сначала читаем словарь2, если не найдено, читаем словарь1, если не найдено возвращаем дефолт, если найдено, на любом этапе возвращаем найденное. Если третий параметр тру и ничего не найдено, в словарь2 дополнительно записываем дефолт. Кроме того, у меня были режимы чтения и записи, как мне подсказал анон в треде "если у тебя идёт сохранение, а объекты продолжают данные записывать, что будет?"
> Самое простое - это сделать две функции
> > set_data(key, value)
> > get_data(key. dafault, make_key = false)
Ну это понятно, хочется верить, что я не совсем тупенький, по работе тоже разработчик, хоть и автотестов. Спасибо за ответ, буду так делать.
>я сцены не меняю и подгружаю/выгружаю их внутри одной основной
Это единственный вариант для любой более-менее сложной игры, особенно если опенворлд (включая метроидвании, гигахрущи и прочее подобное).
>>955275
>сохранять состояние комнат и игру
Делаешь такое дерево сцены:
- game: game.gd
- - menu:
- - - main: menu_main.gd
- - - pause: menu_pause.gd
- - world: game_world.gd
- - - room1: world_room.gd
- - - - door: door.gd
- - - - chest: chest.gd
- - - room2: ...
У скриптов door.gd, chest.gd и world_room.gd есть общий предок game_prop.gd, в котором:
>signal state_changed(who: Node, new_state: Variant)
Сообщает родителю, что состояние объекта только что изменилось (если планируешь сохранять при каждом действии игрока, как в некоторых играх).
>func _on_state_changed(who: Node, new_state: Variant) -> void:
Если будешь использовать описанный сигнал.
>func get_state() -> Variant:
Возвращает актуальное состояние объекта по внешнему запросу от родителя (если планируешь сохранять только во время выхода из игры или по запросу пользователя из меню паузы).
>func set_state(new_state: Variant) -> void:
Приводит объект в требуемое состояние. Родитель вызывает это во время загрузки игры. Если вызова не было - будет состояние по умолчанию, как начало новой игры или запуск сцены по нажатию F6.
Сразу видим, что можно описать свойство:
>var state: Variant: set = set_state, get = get_state
В скрипте game_world.gd:
>func _on_state_changed(who: Node, new_state: Variant) -> void:
Если будешь использовать описанный сигнал.
>func save(file_path: String) -> int:
>func load(file_path: String) -> int:
Сохраняет/загружает состояние мира игры в/из файл, возвращает код ошибки. Формат файла - JSON будет удобнее всего. Файлы ресурсов (.tres) не рекомендую, формат у них меняется от версии к версии движка, а ещё их возможно заразить вирусом на GDScript (лол).
В скрипте game.gd - управление всей игрой. Из меню приходит запрос сохранить/загрузить мир, главный скрипт обращается к game_world.gd, дальше знаешь.
Преимущество такой системы в том, что всё говно остаётся локальным, и если у тебя какой-то сундук обосрался с загрузкой состояния, ты его тут же за хвост поймаешь, а ещё можешь комбинировать всё разными способами (шкаф с ящичками управляет состоянием ящичков, сам управляясь комнатой).
Более того, если всё правильно сделал, то можешь комбинировать прям через редактор сцен, соединяя сигналами через инспектор нод или автоматически соединять сигналы, если есть подходящий предок:
>func _ready() -> void:
>_ var p := get_parent()
>_ if p is GameProp or p is GameWorld:
>_ _ state_changed.connect(p, _on_state_changed)
Тогда можно вообще не париться, само работает, сохраняя возможность запускать всё независимо.
Всё состояние игры может выглядеть так:
{
Player: { health: 100, items: [ key1, ... ], },
Room1: {
Chest: [ item1, item2, item3, ],
Door: true,
Radio: 5,
Label: "здесь был Вася",
Wardrobe: { Box1: [ ... ] , Box2: [ ... ] , },
}, Room2: { ... }, }
Т.е. не обязательно, чтобы состояние было Dictionary, конкретный тип у потомков не проверяем, поскольку каждый конкретный объект получает своё говно по собственному имени и дальше разбирается сам, что конкретно он там насохранял в прошлом. Например, игровой мир чётко знает, что его стейт - это словарь, радиоприёмник чётко знает, что 5 - это ID станции, гардероб ожидает словарь с ящиками и т.д.
В теории могут возникнуть проблемы с именами, если объекты загружаются в мир динамически и при этом получают индексы в случайном порядке. Ну тут сам разбирайся, как называть динамические объекты. В качестве простого решения можно просто игнорить ошибки, но это может привести игру в непроходимое состояние, так что устаревшие сейвы нужно помечать в меню загрузки как несовместимые (см. Minecraft).
Если сохраняешь в JSON, сейвы можно вручную пофиксить. Или сделать конвертер в новую версию.
Если игровой мир супер большой, то game_world.gd должен сохранять по чанкам (отдельные файлы в файловой системе), но это другой разговор.
>>955282
Ты меня сразу извини, но это меня триггерит:
>полным строковым путём
>Чтобы записать туда значение, ты вызываешь:
>>saver.set_data("world/location/door/open", false)
>Чтобы получить значение
>>var door_open = saver.get_data("world/location/door/open", false)
>парсят входящий путь банальным сплитом
>является ли следующий элемент массивом
>У меня менеджер сохранений
Лёг в ванну спагетти и дрочишь синглтоном?
Ты поди ещё и get_node("/root/...") балуешься?
>>955283
>Спасибо за ответ, буду так делать.
Он тебя учит как себе палки в колёса вставлять.
Лучше слушай меня, я уже давно проектирую игру.
>>func _ready() -> void:
>>_ var p := get_parent()
>>_ if p is GameProp or p is GameWorld:
>>_ _ state_changed.connect(p, _on_state_changed)
Или лучше будет так, в классе родителя:
>func _ready() -> void:
>_ for c: GameProp in get_children():
>_ _ if c: c.state_changed.connect(self, _on_state_changed)
Так убираем зависимость GameProp от GameWorld.
Или сделать GameWorld наследником GameProp?..
Также забыл добавить, что обработчику события изменения состояния в GameWorld следует только забирать свежие данные и отмечать необходимость сохранения на диск. А сохранение на диск должно происходить по таймеру или запросу пользователя.
Что-то не помню, нужно ли делать "if c:" в for?
Проспался без температуры и пришло озарение - все в порядке со светом в сабвьюпорте. Я просто забыл инвертировать камеру по оси X перед тем как перемножать ее базис на матрицу отражения.
И ни одна ебаная Кодзима в треде не сможет сказать: "ФРАТЕЛЕ! ПОСМОТРИ НА СВОЙ СКРИН! У ТЕБЯ ТАМ СВЕТ ИНВЕРТИРОВАН!".
То как временная моделька жопой вперед ходит им не нравится, то в какой последовательности игру проектировать тебя научат. А как в реальной задаче указать на косяк уставшему человеку с температурой за 38, косяк видимый на скриншотах, так жидко сренькают в штанишки своими глубокими геймдев познаниями.
Блядь, да просто сделай по сюжету чтобы в квартире кто-от недавно сдох и поэтому зеркала завешаны.
Чето тебе никто не пишет, я поиграл, анончик, прикольно, но у меня подтормаживает камера на сильном компе.
А ты где то писал что ты сам перемножаешь матрицы? Я вот такого не припомню, поэтому отвечаю только в рамках дефолт использования движка.
> Ты меня сразу извини, но это меня триггерит:
> Лёг в ванну спагетти и дрочишь синглтоном?
Хуану пойди расскажи, куда он лёг и чем он дрочит. Пикрелейтед официальный шаблон скрипта CharacterBody. Подставь его в свою боевую картиночку. Триггерится он, ишь ты. Валерьянки выпей.
Дело не в силе компа. Я сейчас на слабом проверил.
Камера летает бодро, но ловит стандартные годотовские пропуки.
Берёшь и хуячишь рандомно васд летая по всей карте пока не словишь все пропуки, тогда камера начинает бодро и без пропуков летать.
Я запустил только первую мисию и поймал примрено 10 фризов на карте и она перестала фризить после этого.
А летала изначально быстро.
Это не баг, это фича движка, ему всегда надо пропукаться и неважно какой у тебя комп.
Две вещи которые стоит оптимизировать:
Если 3-я версия движка, или gl версия в 4-ке, то надо использовать аддоны из шапки для прекомпиляции шейдеров. Еще был вариант с убершейдером, не пробовал.
Во-вторых, если делаешь средне-крупную игру, обязательно делать настройку качества текстур. На некропека это то, что у меня реально убрало пропуки. Я в своей демке накидывал все скачанные с инета ассеты, а в них часто бездумно закинуты 4К текстуры да еще нескольких видов. Видеопамять заканчивалась, поэтому когда поворачиаешь головой, текстуры вновь увиденных объектов начинают загружаться по узкой шине, вытесняя текстуры виденных.
По возможности убрать прозрачность. Самое страшное было от столика с пачкой стаканов и чайником.
Да нихуя он не делает. Это пукошизик из пукотреда. Пункул в кулачок, занюхнул и прибежал к нам в тред срать.
Я вообще считаю, что "смена сцены" подходит только для каких-то супер простых игр, например, на джем. Ну и нубасов учить, конечно, чтобы им не заморачиваться с комплексными системами раньше времени.
>>955275
Вот как я реализую сохранение. По крайней мере, в одной относительно большой (для соло-индюка) игре я это реализовал, и оно успешно работает без ошибок.
Есть общий словарь состояний. В нём хранится всякое, что игрок может по ходу игры поменять. Например, инфа всякие сюжетные триггеры.
Уровень имеет функцию save(), эта функция возвращает своё словарь состояний уровня. Кладём словари состояний уровней в общий словарь состояний.
Все сохраняемые ноды внутри уровня принадлежат к группе save. Внутри функции save() уровня есть что-то типа:
var nodedata = {}
for node in get_tree().get_nodes_in_group("save"):
. var path = get_path_to(node)
. if node.has_method("save"):
. . nodedata[path] = node.save()
. else:
. . nodedata[path] = default_save(node)
Ну и, соответственно, у каждой сохраняемой ноды реализована своя функция save(), которая возвращает словарь. Эта функция пишет какие-то существенные для данной конкретной ноды данные и только их. Ну или defaullt_save(node) возвращает словарь с какими-то стандартными данными, типа позиции, например. Смотря что ты сочтёшь важным для сохранения.
По итогу имеем словарь всех состояний, и выглядит он как-то так:
var global_state = {
. data1="blabla",
. data2="blublu",
. current_level = "level1"
. level_data = {
. . level1 = {
. . . node1 = {position = Vector3(1, 2, 3)},
. . . node2 = {hp = 99, text = "hui"},
. . },
. . level2 = {},
. },
}
Всё, осталось любым нравящимся способом сериализовать этот словарь (например, через var_to_bytes или через JSON.stringify, есть ещё варианты на выбор) и записать его в файл.
Для загрузки, надеюсь, не надо логику расписывать? Просто всё то же самое в обратном порядке - читаешь, десериализуешь, рекурсивно скармливаешь функциям, восстанавливающим состояния, соответствующие под-словари.
Данный метод достаточно гибкий, позволяет сохранять что угодно. Сюда же можно всунуть сохранение игрока, инвентаря, сюжетных квестов и так далее. Но, конечно, серьёзный недостаток - для каждой сохраняемой ноды надо вручную описывать функцию save(). Надо ж всё-таки как-то объяснить игре, какие переменные важны и следует писать в файл, а какие надо переинициализировать заново каждый раз.
Ну в общем-то, это метод из документации, просто причёсан тобой по твоему вкусу. У этого метода есть существенный недостаток: запрос сохранения / загрузки выходит дорогим. В одном фрейме происходит вызов множества функций save в группе. Мне этот метод не понравился. Я предпочитаю, чтобы ноды динамически обновляли свои данные в var global_state, а при запросе сохранения вот он словарик уже готовый, лочишь запись в него, сериализуешь, готово.
Алсо, метод из документации предлагает писать в сейв-файл специфичную движкоинформацию - пути нод. А они там нежелательны. Бритва Оккама.
Двощую, как пидорнули с работы прогресс за неделю больше, чем за полгода ковыряния в свободное от галер время.
Честно говоря, много ошибок сделал.
>>955341
Хуан консерватор и движку больше 20 лет.
>>955393
>запрос сохранения / загрузки выходит дорогим
>ноды динамически обновляли свои данные
Как ты предлагаешь сохранять пули в шутере?
А если у тебя пошаговая игра, зачем скорость?
Нужна система, подходящая всем.
> >ноды динамически обновляли свои данные
> Как ты предлагаешь сохранять пули в шутере?
Как в твоей голове из первой строки гринтекста получилась вторая? Как ты вместо "динамически" в своей голове вообразил "принудительно все свойства"? Интересна логическая цепь.
>принудительно все свойства
Какие данные нужны летящему снаряду?
- тип (ускорение, урон, траектория...);
- кто выпустил (для очков, френдлифаера...);
- где, куда и с какой скоростью летит.
Первые два достаточно записать один раз, но как минимум два вектора обновляются постоянно.
При этом снаряды - динамические объекты, они создаются игрой где-то и потом удаляются из дерева сцены, так что тебе нужно хранить адрес для размещения снарядов на загрузке игры.
Можно сделать менеджер снарядов, который будет управлять сохранением, загрузкой и полётом всех имеющихся снарядов, абстрагируя их от системы сохранения. Но это нарушает твой принцип "запись исключительно в глобальный синглтон отовсюду".
А если взять мобов/NPC, там ещё больше разных нетривиальных данных, что часто обновляются и должны всегда сохраняться по запросу игрока.
Так что глобальное хранилище длинных ключей подходит только мелким пошаговым игрушкам: визуальным новеллам всяким, пойнт-н-кликам.
Нет, если ты затачиваешь код под конкретную игру, продуманную до мелочей - может, не запутаешься, но лучше делать с возможностью повторного использования, особенно делая не пойми что.
И я не спорю, что на синглтонах удобно говнокодить, накидывая километры строк каждый день. Но потом разгребать это всё, распутывать очень неудобно.
Да, есть готовые компоненты, только мп4 нужно перекрдировать
Буквально первая ссылка по запросу "Godot video":
https://docs.godotengine.org/en/stable/tutorials/animation/playing_videos.html
Мой принцип не
Вышеописанный принцип (не мой, он старше меня лет на 10) менеджера сохранений не обязывает создавать синглтон. Вполне реально создавать его экземпляр при старте игровой сессии и сообщать ссылку на него всем нодам, которые желают сохранять какие-либо данные.
> глобальное хранилище длинных ключей подходит только мелким пошаговым игрушкам
Еще раз: >>955341 это у Хуана редактор Годота мелкий проект? Напишешь клон Годота на пару вечеров, м? Ведь именно ProjectSettings выглядит ровно так же. А еще, если вспомнить, работа с анимационными стейтмашинами из кода так же реализована.
Алсо, именно для крупных проектов нужны разветвлённые древовидные базы данных. Мелким проектам подойдёт одноуровневый ассоциативный массив.
Хорошо, давай разумно подойдём к проблеме. Критикуя предлагай. Как ещё ты предложишь обращаться к определённой ветви древовидной структуры, кроме как указанием её полного или относительного пути в дереве?
Еще планирую сделать сериализацию в XML на имеющемся в движке базовом парсере, там будет возможность прописывать каждой ноде и чайлды и параметры. ЖСОН так не может без костылей.
>метод из документации, просто причёсан тобой по твоему вкусу
А, да? Видимо, очень давно его осваивал, забыл, что по доке делал.
Энивей, документация хуйни не посоветует.
>запрос сохранения / загрузки выходит дорогим
Ну, тут смотря какой геймплей и когда вызывается сохранение и как много опрашиваемых объектов. У меня между уровнями, да и нод для сохранения от силы пара десятков наберётся.
>писать в сейв-файл специфичную движкоинформацию - пути нод.
Можно составить манифест, где алиасы/IDы нод будут сопоставлены их путям. И в сейв-файл писать не пути, а эти алиасы/IDы.
Но мне кажется, это лишняя заморочка просто для удовлетворения внутреннего перфекционизма. Не могу себе представить реальный кейс уровня /gd/, где бы она была оправдана. Какой-то долгоиграющий игросервис, который в процессе жизненного цикла может поменять движок. Лично я таких не делаю.
Слы, калогмерат. Ты все умные слова перечислил которые знаешь?
Хуя ты блистаешь интеллектом!
> Не могу себе представить реальный кейс уровня
Если ты что-то поменял в порядке нод в процессе доработки игры - старые сохранения автоматом становятся неработоспособны. Я это в голове держу, когда высказываюсь против записи в файл сохранения движкоспецифичной инфы. Если же там будут IDы объектов в твоей собственной терминологии, то со старыми сейвами проблем будет меньше. Это опять же, как сделать.
Это для тебя умные слова? Чел, ты где-нибудь учился, что-нибудь читал в своей жизни?
Если тебе до 12 лет, то еще ладно.
>Вполне реально создавать его экземпляр при старте игровой сессии и сообщать ссылку на него всем нодам, которые желают сохранять какие-либо данные.
Почему бы тогда не разделить его на несколько менеджеров в разных частях игры, которые затем объединяют всё накопленное добро в одну кучу?
>у Хуана редактор Годота
>ProjectSettings
Да чё ты к нему прицепился. Из настроек проекта ты раз в три года гравитацию достаёшь и больше о нём не вспоминаешь, пока не доделаешь игру и не приступишь к прикручиванию меню опций (где эти настройки изменяются игроком один раз за все 5000 часов геймплея, если не изменял ПК).
А у тебя совсем другое, ты непрерывно какие-то сомнительные данные туда кидаешь, и должен мочь достать те же данные обратно. При этом сцены в проекте за время разработки гоняются туда-сюда и на одном месте редко задерживаются, и тебе не захочется каждый раз распутывать все связи.
ProjectSettings ты никуда не выкинешь, не изменишь, гравитация там всегда в одном месте, и доступ к нему чрезвычайно редкий. Так что хрен с ним, работает - и ладно, у движка есть более серьёзные проблемы.
>работа с анимационными стейтмашинами
Это вообще совсем другое. Ты настраиваешь ноду AnimationTree где-то рядом с моделькой, создаёшь скрипт, управляющий анимациями, и обращаешься снаружи только к своему скрипту (от его родителя). Никакого глобального доступа из случайных мест.
>именно для крупных проектов нужны разветвлённые древовидные базы данных
Базы данных чего?
>Как ещё ты предложишь обращаться к определённой ветви древовидной структуры, кроме как указанием её полного или относительного пути в дереве?
Так ведь Dictionary и есть древовидный, но ты не указываешь полный путь в дереве, а получаешь отдельную веточку, которая тебе нужна.
>>955455
>сериализацию в XML
Зачем? XML тяжёлый, медленный и не нужен.
>ЖСОН так не может
В JSON любые данные сохранить можно.
>прописывать каждой ноде и чайлды и параметры
hjson: https://hjson.github.io/try.html
NodeName: {
class: Node
children: { Node1: {}, Node2: {}, Node3: {} }
script: my_node.gd
exports: { my_var: 0 }
}
>>955481
>поменял в порядке нод в процессе доработки
>старые сохранения неработоспособны
Это легко решается версиями игры:
Версии 0.x могут ломать сейвы как хотят.
Версии 1.x должны зафиксировать сейвы.
Версия 2.x и старше могут ломать один раз.
Версии до 1.0 - альфы, версии после 1.0 - патчи.
Версию 2.0 делаем только когда очень нужно всем игрокам сломать сейвы, моды и прочее.
Кто не хочет - сидит на старой версии.
Вот если твоя система сохранения совсем ломает игру, если ты изменил порядок нод - вот это уже большая проблема, тогда ты ничего изменить не можешь без переделывания всей системы.
>поменял в порядке нод в процессе доработки игры
Так это, игра зарелизена? Или всё ещё в разработке? Если в разработке, то похеру, сохранения поломаются только у меня. Если зарелизена - то явно никто уровни перепиливать уже не будет.
А если уровни перепиливаются после релиза, то это игра-сервис уже получается. Не уровень /gd/.
Ну или ранний доступ. Но это рак. Кто таким занимается, мы таких обоссываем. Игра должна быть готовой на релизе. Ранний доступ это альфатест за ваши деньги, и никто не гарантирует, что сейвы не поломаются.
>Если в разработке, то похеру, сохранения поломаются только у меня.
Ну, допустим, не только, но и у плейтестеров, но:
>альфатест - не гарантирует, что сейвы не поломаются
Тут полностью согласен, альфа на то и альфа.
Вот Godot - хорошая игра. Всегда предупреждают, что альфа-версии могут поломать сейвы (проекты).
>А если уровни перепиливаются после релиза, то это игра-сервис уже получается. Не уровень /gd/.
Почему нет? Пилить можно бесконечно для души. Некоторые инди проекты живут больше 20 лет.
>ранний доступ - это рак, мы таких обоссываем
Лол, кто сказал? А если ранний доступ бесплатно? И вообще, мы бы не смогли поиграть во многие интересные проекты, не будь раннего доступа.
Вот пример, давно играл, в целом нравилось:
https://store.steampowered.com/app/251570/
- больше 10 лет в раннем доступе, и только весной 2024 они начали планировать выход 1.0:
>Q: Why release now?
>A: We have been developing 7 Days for nearly 12 years and have had over twenty large scale early access releases that have brought the game to a significantly different place and quality than where it began. <...> The Fun Pimps have and will continue to support 7 Days to Die development with a majority of their resources.
Алсо, о сейвах:
>Q: Save incompatibility between console versions? Also, will there still be Save incompatibility between patches?
>A: Due to the technical architecture of 7 Days to Die’s game engine, users will have to start a new game with each major update. Eventually, this will not be the case.
Отзывы об игре:
>Очень положительные (88% из 217,324)
Теперь представь, что они вместо раннего доступа в 2013 держали бы игру у себя, кормя народ пустыми обещаниями "как круто будет, когда сделаем релиз", только в 2024 выпустили свой кубач, когда все уже наигрались в майн, выросли, женились, умерли.
Ранний доступ - благо. А мошенников везде полно.
Стоит ли вообще постить в этот ИТТ тред свои успехи на Godot или это только раздражает?
>это только раздражает
Раздражает тебя - не пости.
Раздражает остальных - пости.
Возьму волю в кулак и за сегодня постараюсь доделать уже, слишком уж дохуя времени я нихуя не делаю.
Кстати, видел итт или в прошлом жалобу на локаллайт в четверке, и тащемто удваиваю, чзх, в моем пиксельном долгострое таже хуйня, разрешение текстуры света никак на это не влияет, тени тоже, фпс тупо падает до 30 с нихуя, причем если центр камеры выйдет из зоны освещения то фпс возвращается к 60 и это при том что эти же источники света все еще в зоне видимости. Я в движке по сути еще нуфаня, поэтому как фиксить хуй его знает, а почему так происходит тем более, гуглить пытался но тщетно. Это на глес3 ес че такое, как на форварде это работает не тестил, мб там нормально все. Забыл добавить что это в канвасмод только так, на вьюпорт и дисейбл все работает отлично в 60 фпс. Надеюсь в 4.3 пофиксят, и надеюсь добавят возможность делать веб билды без SAB, я хоть и к тройке привык уже, но буду честным, по сравнению с четверкой это обрубок.
>кликер по факту готов на 90% осталась нудятина
Классика. http://ru.wikipedia.org/wiki/Закон_Парето
>20% усилий дают 80% результата, а остальные 80% усилий — лишь 20% результата
>Кучу времени убил еще на юай
В чём проблема была? Вроде всё просто.
>локаллайт
Што? Имхо, 2D свет в плане теней вообще сплошной косяк (пробовал в 3.x).
Не понимаю весь этот дрочь на тени в 2D играх, если не клон террарии...
Впереди вырисовывается долгая пауза из-за множества ассетов которые придется сделать. Так что решил не тянуть и пернул своим СХ на реддит, следующий если будет то очень не скоро.
>В чём проблема была?
В стиле. То что было в голове совершенно не вписалось в визуал игры.
>>локаллайт
Поинтлайт бтв.
>Не понимаю весь этот дрочь на тени в 2D играх
Да на тени пох вообще, узнать бы с какого хуя фпс падает из за дефолтного света.
4.3 уже всё, теперь только 4.4 ждать. В 4.3 только костыль:
@export_custom(PROPERTY_HINT_NONE, "") var my_var: Variant
>То что было в голове совершенно не вписалось в визуал игры.
А ты прям в редакторе проекта делал?
Обычно сначала делают концепт UI - в спец софте, в пейнте, на бумаге, хоть на салфетке...
>фпс падает из за дефолтного света
Там же пиксели перемножаются, затраты неизбежны, больше пикселей - больше трат.
>>955563
>в четверке
>фпс тупо падает до 30
>фпс возвращается к 60
>Это на глес3 ес че такое, как на форварде это работает не тестил
>Надеюсь в 4.3 пофиксят
Проверил на 4.3-beta1, в GLES3 и Forward+ одинаково 1500+ фпс независимо от света.
Смотри, что и как там у тебя отображается кроме собственно источников света.
>фпс тупо падает до 30
>>955577
>фпс падает
Ты ещё дрова проверь, у меня-то топовая ПЕЧ.
Ты сменил тактику бампов? Уже не предлагаешь делать игры?
Пиздец. 12 лет кормить людей кривым недоделанным говном и стричь бабло. Отзывы положительные: ну да, ну подождём ещё немножечко, и игра будет готова, а щас ранний доступ, ну простим ей, что она багованная, надо просто потерпеть.
Сука. Высшая степень мудачества и лицемерия - выкидывать продукт в магазин и 12 лет притворяться, что это не готовый продукт, за который ты хочешь бабло, а просто ну вот демка для выставки. Когда беседка выкатывает фоллаут 76 без неписей, еле работающий от багов, её даже метка раннего доступа не спасёт - говном закидают. Когда то же самое делает нонейм индюк - ну тут молодец чо, высрал нам кусочек счастья, спасибо. Хотя шо то игра-сервис для долговременного кормления, шо это. Никакой разницы.
>А если ранний доступ бесплатно?
А покажи мне хоть один ранний доступ бесплатно без ссылки на донат.
>ответа ни в одном гайде не нашел
Плохо искал, лалка. Учись читать документацию.
https://docs.godotengine.org/en/stable/tutorials/rendering/multiple_resolutions.html
>потом заколебусь все переделывать
Всё в порядке, переделать несложно.
>ранний доступ бесплатно без ссылки на донат
Вот годная бесплатная игра, донат символический:
https://store.steampowered.com/app/304930/
Прошла три/четыре стадии:
- режимы игры в роблоксе - я тогда о нём не знал
- кривая юнити-поделка 0.x-1.x? - тут не уверен
- кривая юнити-поделка 2.x - я в это играл
- ровная юнити-поделка 3.x - тоже играл
Суммарно где-то... лет -дцать? Раньше 2014 начал.
Геймплей лучше большинства ААА шутеров.
Думаю, на Godot можно сделать не хуже.
>12 лет кормить людей кривым
Ну, а люди и не против. Играть-то можно.
>подождём ещё немножечко
Чего? Играй. Вот ждали киберпук77 - дождались...
>фоллаут 76
>говном закидают
>нонейм индюк - ну тут молодец чо
>Никакой разницы.
Разница огромная:
- инди = превозмогатор трудностей;
- ААА = просираторы полимеров.
Первым уважение, вторым нет прощения.
Ещё есть стар ситизен - это развод "китов" на бабки.
>>955562
>Раздражает остальных - пости.
Ты сам напросился.
Уже почти не падает.
Всем, кому нужно держать N проектов на M версиях движка, и не переживать насчёт внезапного коррапта случайным открытием проекта не в той версии.
>Jolt физику
Так это она и есть. Godot Physics ощутимо медленнее.
В сцене 56 RigidBody3D летают + 56 AnimatableBody3D потомками привязаны, однако, физически ни с чем не сталкиваются. Если отключить все AnimatableBody3D, будет >75 FPS, но мне они нужны по задумке: внешний RigidBody3D прост как кирпич, а внутренние сложные коллизии отдельным слоем для игрока и неписей. Но мне достаточно будет парочку сложных пепелацев, остальное физическое должно быть намного проще устроено, так что на видео преувеличенная нагрузка.
...плюс там анимированные генераторы частиц. Неожиданно, но их влияние не так уж и высоко. AnimatableBody3D съедают больше 75% времени. Переключение на StaticBody3D лучше не делает. Понимаю, двигать статики вообще не ок. Нужно попробовать один лайфхак с телепортацией...
>Всем, кому нужно держать N проектов на M версиях движка, и не переживать насчёт внезапного коррапта случайным открытием проекта не в той версии.
Палю лайфхак, как не запутаться в версиях:
1. У тебя две отдельных папки:
- папка Godot с редакторами;
- папка Projects с проектами.
2. В папке проектов делаешь ярлык, указывающий на редактор нужной версии и нужную папку проекта. Можно разместить ярлык прямо в папке проекта.
3. Называешь ярлык подходящим именем:
>Edit Project AAA with Godot 3.6.beta
>Edit Project Beta with Godot 4.2.2
>Edit Tests with Godot 4.3.beta
4. Открываешь проекты только через эти ярлыки. Открывается Godot Editor, во встроенный менеджер проектов ничего не попадает, если сам не добавлял.
5. Для апгрейда проекта на новую версию:
- Ctrl+C/Ctrl+V по старому ярлыку;
- изменяешь в параметрах 4.2.2 на 4.3;
- запускаешь проект кликом по новому ярлыку.
6. Также можно сделать ярлык на запуск игры. Без экспортирования, без редактора - нажал и играешь.
Мне лично всё равно приходится папку проекта открывать, чтобы закинуть туда текстуры, модельки. Почему бы не сделать ярлыки на редактор там же?
1. install godot-manager
2. внутри него install godot's нужных версий
3. Добавляешь проект, прописываешь ему нужную версию.
ПРОФИТ!
3 пункта против 6 твоих, пердолинга с ярлыками. Палит он лайфхак. Пиздец просто.
>install godot-manager
Лишняя зависимость с багами и тормозами.
>внутри него install godot's нужных версий
Качаю сборки с официального сайта, а не васянки.
>Добавляешь проект, прописываешь
А потом у твоего godot-manager конфиг ломается.
>пердолинга с ярлыками.
Настроил несколько лет назад и до сих пор юзаю стабильно, пока ты ждёшь багфиксы: >>955949
>Уже почти не падает.
Лол, "почти" - это сколько раз в день?
Ты просто не представляешь, как это круто, когда ты ПРОСТО кликаешь на ярлык на рабочем столе и твой проект моментально запускается на выполнение или в редакторе, без лишних шагов в куче менеджеров.
>3 пункта против 6 твоих
Мои пункты займут пару минут один раз, а твои замедляют запуск проекта регулярно, да требуют багфиксов от падений. И вообще это юнитячество.
>Ехал васян через реку
>Видит васян в реке васян
>Сунул васян васян в васян
>Васян васян васян васян
Не продолжай, я понял, что ты Игорян.
Кликер кстати готов, осталось яндекс прибить гвозядми, и аудиолибу прикрутить, да юай немного доредачить и можно уже релизить.
Диды на калькуляторах игры программировали. И ты сможешь! Тем более твой проект не проебался и не закорраптился.
А вообще ибп прикупи, когда-нибудь в будущем.
>врубается и через секунду оффается картинка
С телевизором всё ок. Нужно предохранитель пофиксить. В инторнете погугли статейки. Это копейки будет стоить.
Из фичей мне необходимы:
1. Тулзы для процедурной анимации скелетал мешей
2. Что-то что поможет реализовать расчленёнку
3. Хорошая система коллизий чтобы детектить когда меч касается меша игрока или нпц
В годоте это всё имеется?
>врубается и через секунду оффается картинка, такая хуйня и до этого была, только выключение и включение помогало, а сейчас нихуя
Конденсаторы проверь. Блоку питания необходимо зарядить конденсаторы, если конденсаторы засохли или протекли, нормально включиться БП не сможет. Электролитические конденсаторы сохнут неизбежно, это наименее долговечный компонент (~15 лет).
>блять квадрат этот ебаный
Нажми Ctrl + Shift + F11. Я забиндил на просто F11.
https://docs.godotengine.org/en/stable/tutorials/editor/default_key_mapping.html#general-editor-actions
Можно вынести редактор кода в отдельное окно:
https://docs.godotengine.org/en/stable/tutorials/editor/customizing_editor.html#splitting-the-script-or-shader-editor-to-its-own-window
>средневековый лоуполи 3Д экшон с мечами
Нормально, Godot потянет, видел такие демки.
>процедурной анимации скелетал мешей
Всё норм, можно анимировать процедурно.
>тулзы
Какие тебе тулзы, если анимации процедурные? Процедурные анимации - это анимации кодом, как замена ручным анимациям или motion capture.
Если ты про регдолл, для него есть встроенные функции, однако, с ним придётся повозиться...
>поможет реализовать расчленёнку
Расчленёнка в играх бывает двух видов:
1. Части тела заранее отделены друг от друга и могут отделяться только в определённых местах. Дёшево и сердито, подходит 99% играм, но художнику нужно повозиться, создавая отдельные части тел. Какой-то особенный код тут не нужен, всё достаточно просто. Гарантированно нет проблем с анимациями мешей.
2. Цельный меш процедурно разрезается в реальном времени. Код сложный, багов много, будет нагружать компьютер игрока, разрезы нереалистичные. Зато достаточно накинуть скрипт. Видел аддоны:
https://github.com/PiCode9560/Godot-4-Concave-Mesh-Slicer
https://youtu.be/_yqTljJ0mW0
Не знаю, будет ли это работать с анимациями.
>Хорошая система коллизий чтобы детектить когда меч касается меша игрока или нпц
Тут довольно интересная ситуация.
Разработчики официально признают, что физический движок, встроенный в Godot, кривой и косой, так что официально рассматривают внедрение нового (Jolt). Однако, ты уже сейчас можешь попробовать его сам:
https://github.com/godot-jolt/godot-jolt
Достаточно закинуть нужную dll-ку.
Впрочем, встроенный физический движок вполне способен справиться с простыми задачами. Да, он медленный, да, глючит в определённых ситуациях, однако, его вполне хватает для быстрого прототипа, особенно когда ты от него ничего не ожидаешь.
Также есть другие альтернативы, можешь PhysX прикрутить или Havok, но они вроде как платные. Возможно прикрутить Bullet, но у него свои косяки, поэтому от него избавились при переходе на 4.0.
Короче, о физике не волнуйся - она есть, а при острой необходимости её можно заменить альтернативной.
>Какие тебе тулзы, если анимации процедурные? Процедурные анимации - это анимации кодом, как замена ручным анимациям или motion capture.
Например контрол риг с инверс кинематикой, чтобы я не задавал IK вручную. Если есть еще заранее заданные функции для контрол рига типа aimAt ваще круто будет.
>Не знаю, будет ли это работать с анимациями.
Правильный вопрос будет ли это работать с скелетал мешами. Но это уже что-то, спасибо.
>Разработчики официально признают, что физический движок, встроенный в Godot, кривой и косой, так что официально рассматривают внедрение нового (Jolt). Однако, ты уже сейчас можешь попробовать его сам:
Пичалька, а че там редко возникает потребность коллизии детектить? В целом могу и сам прикрутить, всё-таки тот факт что годот опен-сурс это серьезное преимущество для такого как я, который никому ничего не хочет быть должен.
>инверс кинематикой
Пока что всё не очень, есть только это:
https://docs.godotengine.org/en/stable/classes/class_skeletonik3d.html
Но оно давно deprecated. Вот старое демо:
https://godotengine.org/asset-library/asset/523
Можно поискать аддоны с готовым кодом IK.
>редко возникает потребность коллизии детектить?
Там проблемы такого уровня:
- при движении по стыкам можно подскочить;
- бывает лютая тряска, особенно в джойнтах;
- не тянет 100500 ригидбоди, максимум ~1500.
Фиксили-фиксили, но всё ещё далеко до идеала.
Ещё есть известная проблема производительности рейкастов, из-за того, что они при запросе из кода формируют ответ большим словарём (Dictionary), существенно ограничивая число запросов. При том сторонние языки (C#, C++) тут ничем не помогут - бутылочное горлышко в API физической системы.
Т.е. ты можешь кинуть несколько сотен рейкастов в один кадр, прежде чем у тебя ФПС упадёт ниже 60, в то время как в других движках ты мог бы кинуть намного больше за один кадр. Кто-то это считает критическим недостатком и даже высрал пост с критикой, но всем остальным норм, потому что так много рейкастов практически никому не нужно.
Здравствуйте, пилю, ради самобучения, свой клон vampire survivors (если что я в него никогда не играл, только слышал). Так вот, возник вопрос что лучше использовать CharacterBody2d или же Area2D, гугление и чтение доступных сигналов подсказало, что мне нужно использовать и то и то. Первое из-за удобный поддержки и передвижения и для коллайда с границами карты и прочими препятствиями, а второе, что бы детектить попадания и прочие регистрации урона. Только вот и Character body и Area2D требуют CollisionShape, и фигачить у одного обекта сразу две одинаковые ноды колиизии выглядит максимально костыльно. Так и надо или же существует способ сделать так, что бы обе ноды работали с одной и той же нодой коллизии?
А как тогда? У Characterbody и Colisionshape нету сигнала body_entered, а именно он нужен, что бы регистрировать дамаги.
Используй is_colliding из рейкаста прикрепленного к пуле для вызова функции хит в чарбоди или любом другом коллайдере.
Ну так дамажат не только "пули", а ещё сами враги, если ходить через них, плюс всякие слеши и другие объемные прожектайлы которые будет запускать игрок.
>vampire survivors
Как понимаю, это "буллет хелл наоборот":
1. На карте нет никаких препятствий. Совсем.
2. Мобы свободно наслаиваются друг на друга.
3. Игрок спамит атаками по чётким паттернам.
4. Мобы отлетают за 1-2 попадания от игрока.
5. Весь фан в создании новых паттернов атаки.
Из этого следует, что:
0. Нужно выдать максимум мобов и снарядов.
1. CharacterBody2D тут бесполезен и не нужен.
2. Достаточно Area2D как датчика попаданий.
3. Перемещение в сторону игрока по прямой.
Простейшая композиция сцены:
- Mob/Bullet: Area2D
- - Circle: CollisionShape2D
- - Sprite: AnimatedSprite2D
Area2D настраиваешь так:
1. У мобов: слой - mob, маска: ничего
2. У снарядов: слой: ничего, маска: mob
3. У игрока: слой: ничего, маска: mob
Снаряд бьёт моба, игрок бьётся об моба.
Сами мобы только наводятся на игрока:
>@export var player: Area2D
>func _physics_process(delta):
> position += position.direction_to(player.position) speed delta
Если будет медленно:
1. https://github.com/godot-jolt/godot-jolt
2. Можно попробовать Rect2.has_point()...
3. GDScript медленный, перепиши на C++))))
>Jolt
А, не, это ж только для 3D. Для 2D вот это:
https://github.com/appsinacup/godot-rapier
>Parallel support and SIMD build for better performance.
https://appsinacup.com/godot-physics-vs-box2d-vs-rapier2d/
>Performance: Best, about 2x,3x faster than competition
>Стенка всего-ничего, всрал в нее два дня.
Чего? Ты её с нуля моделировал что ли?
>И это без наполнения пустых полох.
Тяжёлые у тебя проблемы, конечно.
>>956344
> фигачить у одного обекта сразу две одинаковые ноды колиизии выглядит максимально костыльно
Просто скопируй ноду с настроенной коллизией, поскольку коллизия - это ресурс, она будет инстанцирована. Инстансинг коллайдеров.
> моделил стенку джва дня
А игра-то где?
Моделишь блок будущей стенки джве минуты и продолжаешь кодить геймплей.
>Ты её с нуля моделировал что ли?
Нет, экструдировал из дефолт куба.
Выглядит лампово. Я надеюсь ты не собираешь делать мужика главным гером? Пускай это будет молодая няшная тяночка с длинными волосами.
>А игра-то где?
>кодить геймплей.
Пора бы уже смириться, что у него бродилка.
Её геймплей делается за один вечер: >>955243
>>956377
>няшная тяночка с длинными волосами
А что с пропорциями и цветом трусиков?
Кошкодевочку пусть делает. Старая хозяйка умерла и кошкодевочка осталась сама по себе в квартире.
>>956387
Только вид от первого лица, и игрок всю дорогу думает, что у него померла мать и он - ребёнок в пустой квартире, а в конце выясняется, что он - кот.
>вид от первого лица
Да не, текущий вид прикольный, своеобразный.
>у него померла мать и он - ребёнок в пустой квартире
Слишком мрачно, серьёзно.
Пускай будет няшная кошкодевочка. Старушка хозяйка умерла от старости, без трагедии и прочего. И кошкодевочке теперь нужно присматривать за домом, как-то выживать. Хотя это лучше бы зашло в каком-нибудь деревенском домике с животными.
>Я надеюсь ты не собираешь делать мужика главным гером?
Скорее всего нет. Скорее всего тян лет до 25. Но моделить персонажей это не квадратный шкаф, придется искать. Или плотить.
>Или плотить
А дорого ли будет стоить такой персонаж? На геймдев.ру наверняка есть какой-нибудь чувак, который за небольшие деньги сделает неплохо.
>моделить персонажей это не квадратный шкаф
Делай стилизацию с акцентом на самом важном.
>А дорого ли будет стоить такой персонаж?
Знал автора (в губы не целовался) с ныне почившего форума по блендеру, его модели используют в порнушных модах, играх, артах
https://youtu.be/eFQKoI7aR0Q
Если могёт менее сексуализированно и в стиле ближе к Silent Hill, обращусь.
Думаю влетит в диапазоне 10-50 баксов. Ну или баш на баш, он хотел свою визуальную новеллу пилить. Я ему скелет игровых систем, он мне модельку. Но это вряд ли.
>Думаю влетит в диапазоне 10-50 баксов
Скульптинг, ретопология, текстуры, одежда, риггинг, анимация за 10 баксов? Я канеш не шарю за цены, но по-моему ты пизданулся, либо проебал пару нулей.
>менее сексуализированно
Sex sells, зачем себе вредить?
https://en.wikipedia.org/wiki/Sex_in_advertising
>в стиле ближе к Silent Hill
Там лоупольки с хендпейт текстурами. Для такого тебе другой художник нужен, этот, похоже, по хайполькам с запеканием (такие редко рисуют текстуры вручную, только запекают с хайполи, процесс совершенно разный - запекание буквально одной кнопкой). И если ты ориентируешься на SH, разве у тебя не слишком реалистичные модели окружения? Придётся всё переделывать для такой стилизации.
>10 баксов
А ты любишь шутить...
>в стиле ближе к Silent Hill
Если брать SH2, то там, похоже, делали по фото лица реального человека. Сложно...
>как загрузить их в годо
Спроси у нейронки. Я спросил, она хорошо ответила.
>>956436
>Это троллинг.
Слишком вялый. У него импотенция?
>>956432
>Там лоупольки с хендпейт текстурами.
Ты в курсе что после первого сайлент хила было еще несколько частей?
>>956437
Всем спасибо, добавил. А как сделать помещение? Это в годо невозможно? Надо в блендере?
>А как сделать помещение?
Для прототипа - вот это используй:
https://docs.godotengine.org/en/stable/tutorials/3d/csg_tools.html
Для красивого релиза - в блендере переделаешь.
>было еще несколько частей
Ну, какой ещё "стиль" ты хочешь повторить?
>Скульптинг, ретопология, текстуры, одежда, риггинг, анимация за 10 баксов?
Полигональное моделирование, материалы, одежда, текстуры. Емнип он не скульптурит, а классически редактирует сетку. Анимации/риг он так же не делает, натяну с mixamo как сделал в текущей демке. Лоуполи ретопологию проведу сам.
>>956432
>Sex sells, зачем себе вредить?
Сдрочусь.
>Емнип он не скульптурит, а классически редактирует сетку.
Это разве не сложнее?
Хочу предупредить, что в 4.3 изменят модификаторы Skeleton3D, включая SkeletonIK3D:
https://github.com/godotengine/godot/pull/87888
Если что, это уже давно собирались сделать.
4.3 должна выйти через месяц-два, я думаю...
>Это разве не сложнее?
Нет конечно, это зависит от задачи, мало где скульптуринг нужен кровь из носу как. Есть кнчно персонажи которые и квадратную коробку скульптурить будут, но это такие себе типы.
>Спроси у нейронки. Я спросил, она хорошо ответила.
В этом конкретном случае. А прошу у нее создать скрипт для движения игрока и она дает скрипт для годо 3. Про четвертый не знает.
> Есть кнчно персонажи которые и квадратную коробку скульптурить будут, но это такие себе типы.
Годноты навалили в систему анимаций 4.3.
https://godotengine.org/article/migrating-animations-from-godot-4-0-to-4-3/
>мало где скульптуринг нужен
Органику без скульптинга не сделать, если тебе фотореализм с прыщами и морщинками нужен. Десятки миллионов квадов на куб скульптеца!
Но если аниме-масочку, то тут скульпт не нужен.
>>956492
Открой для себя пропорциональное редактирование.
https://docs.blender.org/manual/en/latest/editors/3dview/controls/proportional_editing.html
>Открой для себя пропорциональное редактирование.
Открыл уже давно, но это по сути скульптинг, но можно пользоваться только одной кистью, нет ремеша и динтопо.
>но это по сути скульптинг
Нет, это не скульптинг: ты контролируешь вершины, осознавая влияние действий на структуру сетки.
Скульптинг - это когда ты совсем абстрагируешься, работая виртуальной "глиной", пока софт решает все проблемы с мешем вместо тебя. Поэтому после скульптинга нужна ретопология - восстановление меша до юзабельного состояния (ровная сетка).
Ну это примерно как мазня кисточкой vs мазня нейронками: нейронка решает все мазки за тебя, высирая неюзабельное говно, которое нужно вилкой чистить (а можно не чистить и стать знаменитым говноделом как яндередев, но это такое).
Кринжа навалил, анон. Попробуй поскульптить и поредактировать прежде чем такое категоричное мнение выдавать.
Я много лет в этой теме вообще-то.
Редактирование: чётко, гладко, полный контроль. Цепляешься за конкретные вершины, которые ты видишь глазами, они не рождаются из ниоткуда.
Скульптинг: один раз мазнул кисточкой и прога вываливает кучу треугольников. Если снять галку генерации треугольников, то будет лоуполи кринж, который совершенно не похож на ИРЛ глину.
Пропорциональное редактирование - это совсем не скульптинг. А "скульптинг" без генерации и удаления треугольников в принципе не имеет смысла.
С реальной глиной, воском, пластилином у тебя минимальная единица размером с молекулу, т.е. нет проблемы с нехваткой разрешения. Скульптинг в 3D вынужден генерировать треугольники, потому что невозможно уместить в RAM триллионы "атомов".
>Я много лет в этой теме вообще-то.
Незаметно, если честно. Ты звучишь как человек который ни разу в жизни скульптить не пробовал. Там всё пиздец как удобно, намного удобнее чем двигать вершины самому, и уж тем более удобнее чем с реальной глиной.
>удобно, намного удобнее
При чём тут удобство?
Речь шла о том, что скульпт - это отдельная от редактирования сетки тема, абстрагирующая художника от, собственно, сетки.
Удобно/неудобно - зависит от того, что ты делаешь. Пробовал лепить стрёмных монстров - да, удобно. Но анимешную гладенькую маску сложно сделать.
>Как придумать название для игры?
Тащемто никакого секрету тута нету.
https://www.imagineforest.com/blog/game-name-generator/
>1. Define the Genre of Your Game
>2. Make a List of Nouns
>3. Make a List of Adjectives
>4. Combine the Adjectives and Nouns
>5. Play around with Your Words
Накидал по инструкции, разбирайте, кому надо:
Tower of Ass; Pile of Boobs; Mr. Dick Short; Cum Dump; Cumpocalypse: Days to Come; Long White Shot; Smallfun Skillful; Forbidden Jar: Escape the Goo; Short Snort; Lost Fapathon: Impotence; My Neighbour's Wife; Kill la Cum.
Да, вот только получается дженерик хуйня вместо названия. Этих таверов, спайров и эскейпов бесчисленное безликое множество.
>бесчисленное безликое множество
1. Изобретаешь машину времени.
2. Путешествуешь в 70/80/90-е.
3. Забираешь лучшие имена.
4. Профит!
Постараюсь собраться с силами и на выходных все же доделать то что осталось.
Недавно кстати поймал себя на мысли что я не могу делать говноигры уровня яндекс игр, снимаю шляпу перед теми кто может просто взять за 5 минут собрать из ассетов "хагиваги против нубика" и без зазрения совести выложить это получив как минимум мрот, я так не могу, и не потому что не могу, а потому что как любитель игр не могу.
Скоро твг же будет, думаю попробовать, никогда ещё в таком не участвовал.
Ебать я конечно насрал тут, извиняюсь.
Про локализацию я не знаю, просто скажу что маленький шаг вперед лучше чем отсутствие этого шага. Вперед.
>меня то депресуха накроет, то прокрастинация
Хотел похожее написать, но ты опередил...
>юзаю 2 лейбла
>не удобно
Инкапсулируй @ профит.
>как любитель игр не могу.
Молодец. И без нас насрут.
По первой ссылке гугл-слайды.
Вкусовщина. Об этом на каждом углу говорят. Лучше сначала геймплей сделай, а уже потом обмазывай постпроцессингом и процедурными анимациями.
Самая полезная информация:
>The rounded shape may most commonly be named "bouba"
https://en.wikipedia.org/wiki/Bouba/kiki_effect
>сначала геймплей
Без вопросов. Просто у людей часто представление о пиксель-арте как о самом изи арте. Вот этот полегче будет.
>полегче будет
Ещё легче вообще ничего не делать.
Вот лично я хочу 3D игру, а не 2D головоломку.
Сказали тебе делай 2д головоломку, значит делай 2д головоломку.
>Хотел похожее написать, но ты опередил...
Плохо. Нужно выбираться из этого говна, только как - хуй его знает. Вообще это бич почти каждого индюка-оркестра, и то и это надо делать, и все это еще надо уметь, бррр.
>Инкапсулируй @ профит.
Понятное дело, не удобно в том плане что вместо одной ноды "текст KEY_1", приходится юзать три: контейнер, "текст", "KEY_1".
Нужного утюга не нашел, пришлось делать самому. Зато всего 1400 треугольников. Планируется на роль оружия ближне-дальнего боя после первого энкаунтера. Два дня на утюг. Если делать по модельке раз в три дня, то на сотню ассетов уйдет год. Аж плакать хочется.
>вместо одной ноды "текст KEY_1", приходится юзать три: контейнер, "текст", "KEY_1".
1. Делаешь новый tool-скрипт.
2. Добавляешь лейбелы как internal ноды.
https://docs.godotengine.org/en/stable/classes/class_node.html#enum-node-internalmode
Либо, ещё лучше — пишешь свою версию Label, которая воспринимает сколько тебе нужно тегов.
Потом просто юзаешь как обычную ноду.
У тебя игра в целом депрессивная получается...
Не хватает только серого фильтра и дождя.
И тазиков, собирающих воду с потолка.
>Два дня на утюг. Если делать по модельке раз в три дня, то на сотню ассетов уйдет год. Аж плакать хочется.
А может со временем скилуха прокачается и будешь срать моделькой за час? Мне иногда попадаются стримы моделлеров всяких, они за утро персонажа высирают.
>>956729
>У тебя игра в целом депрессивная получается
Тогда иду в правильном направлении. Хотя может поэтому самому так грустно становится.
>>956738
>они за утро персонажа высирают
Это отрепетированные стримы. Но 2 дня на утюг много конечно. Может одного вечера должно было хватить.
Попробую, к слову, выставить на продажу пару моделек где-нибудь.
1) У меня Игрок на Автозагрузке.
2) Игрок подпрыгивает на большой высоте и активирует смену сцены.
3) Когда сцена меняется, Игрока телепортируют на заданную глобальную координату, которая находится ниже текущей позиции Игрока. (Координата зависит от аргумента функции для смены локации.)
4) Игра просчитывает, что Игрок не is_on_floor().
5) После телепортации игра просчитывает, что Игрок is_on_floor().
6) Игрок теряет очки здоровья как от стандартного падения.
Автозагрузку для игрока я использую чтобы не перезагружать его каждый раз при смене локации, а также для упрощения кода.
Вообще по-хорошему ты должен был расчёт дамага привязать к стейт-машине, и среди стейтов можно было бы прописать "is jumping" который может переходить как в "is falling", так и в "is teleporting", во втором случае дамаг не распределяется.
>Окей, попробую сделать машину состояний.
или просто обнулить его велосити при переходе.ц
>>игра в целом депрессивная получается
>Тогда иду в правильном направлении.
Вот это попробуй использовать:
https://docs.godotengine.org/en/stable/tutorials/3d/environment_and_post_processing.html#adjustments
- минус насыщенность (saturation)
- минус контраст (contrast)
- минус яркость (brightness)
+ добавь полупрозрачный шум Перлина на весь экран
>проблему: Godot 4.3 beta 1
Это версия для тестов, а не для разработки игр.
>Игрок на Автозагрузке
>активирует смену сцены
Не стоит так делать...
>Игрок теряет очки здоровья
У тебя формула зависит от высоты?
Что-нибудь вроде:
>fall_damage += last_height - current_height
Получается огромный дамаг от телепорта вниз.
>>956775
>расчёт дамага привязать к стейт-машине
Конечный автомат не решает проблему в логике.
>Конечный автомат не решает проблему в логике.
Нахуя решать проблему в логике в сложной структуре, когда её можно облегчить и проблема с логикой уйдёт сама собой?
А чем ты комнатное освещение делаешь? Например тот источник света, который из кордиора в комнату светит? Омнилайт?
Я пробовал делать стейт машину, но результатов она не дала. Затем написал одну строку, которая меняет координату последнего касания земли на координату телепорта и урон пропал. Спасибо, anyway попрактиковался в написании машин, пускай они мне пока не нужны.\
>>956792
>Это версия для тестов, а не для разработки игр.
Меня это никогда не останавливало. Просто скачиваю последнюю версию и пользуюсь новейшими фишками, а когда релизится, проект переношу на стабильную версию и экспортирую.
>Не стоит так делать...
Я от очень многих это слышал, но подробно никто не раскрывал почему игрок не может быть синглтоном, если постоянно меняются все сцены, кроме игрока. Просто игрок в памяти находится, и всё. Разве нет? Это предоставляет кучу удобств для обращений и взаимодействий игрока с миром.
У меня не только синглтон-игрок, но и специальный системный скрипт и UI.
>Получается огромный дамаг от телепорта вниз.
Понимаю, спасибо, кэп.
>Конечный автомат не решает проблему в логике.
Так точно. Одной строкой в функции телепорта решается ВСЁ.
>подробно никто не раскрывал
Тыщу раз уже обсуждали в Godot-тредах.
>почему игрок не может быть синглтоном
Потому что ты его гвоздями прибиваешь.
Что, если ты захочешь сделать мультиплеер?
>если постоянно меняются все сцены
Что, если захочешь сделать плавный переход?
>Просто игрок в памяти находится, и всё.
Завязывает весь код игры на реализацию Player.
>кучу удобств для обращений и взаимодействий
Потом эти удобства могут боком выйти.
Короч, гугли low coupling, high cohesion.
Autoloaded - прямой путь к high coupling.
>Что, если ты захочешь сделать мультиплеер?
Пиздец у тебя "что если". А что если ты из своего хруща захочешь многоразовую ракету сделать? А потом переделать в подводную лодку?
Вот так и пилят-перепиливают десяток лет, а на выхлопе тухлый пук вместо игры с геймплеем.
>Потому что ты его гвоздями прибиваешь.
>Что, если ты захочешь сделать мультиплеер?
Спасибо, не захочу.
>Что, если захочешь сделать плавный переход?
У меня UI синглтоновский. Когда происходит смена сцены, игрок фризится, а интерфейс включает экран загрузки.
>Завязывает весь код игры на реализацию Player.
Ну да, это синглплеерная маленькая мобильная игра, в которой не будет мультиплеера, сложных механик. В крайнем случае много переписывать не придётся, ведь Player достаточно заменить на переменную, которую будет хранить глобальный скрипт, но в этом ничего сакрального не вижу.
>Потом эти удобства могут боком выйти.
Когда я делал игрули и раком изъёбывался чтобы получать доступ к игроку и от игрока к миллиону других нодов через окольные пути у меня были проблемы, а сейчас их ровно ноль. Посмотрим что будет в дальнейшем. Если обосрусь, то напишу что был не прав, если нет, то поделюсь готовым проектом и отмечу, что использовал игрока в качестве синглтона.
>Вот это попробуй использовать:
Мне эта серая блевотина как-то приелась. Как в американских фильмах сериалах - мексиканский фильтр (все желтое), русский фильтр (все синее), индийский фильтр (все коричневое). В играх тоже уже затрахало.
Правда я планировал взять эффект шума вблизи монстров, хоть и калька с SH4.
Квартира, к слову - сейв зона, там должно быть депрессивно, но уютно.
>>956799
>Омнилайт?
Да, в каждой комнате свой омник, плюс один солнечный источник света для света/теней из окон. Освещение у Environment стоит очень низкое, всего 0.08
>пилят-перепиливают десяток лет
Ты сначала стадию прототипа пройди. Прежде, чем переходить к продакшену и цементировать механики игры, нужно сначала придумать нормальную игру. А для этого нужна максимальная гибкость кода.
>>956822
>получать доступ к игроку и от игрока к миллиону других нодов через окольные пути
Ты что-то не то делаешь, если у тебя "игрок" (точка доступа пользователя к игре) занимается раздачей миллионов нод другим игровым системам.
>>956833
>серая блевотина как-то приелась
Мне тоже, но цвет должен подходить сюжету, работать на создание настроения.
>в каждой комнате свой омник
SpotLight3D не пробовал использовать?
>Ты что-то не то делаешь, если у тебя "игрок" (точка доступа пользователя к игре) занимается раздачей миллионов нод другим игровым системам.
Так взаимодействие игрока с игрой — это единственная неотьемлимая часть любой игры. Я её поставил в приоритет и на взаимодействии игрока с игрой завязывается всё остальное.
>единственная неотьемлимая часть
Вообще мимо. Игры могут быть без игрока.
Игру нужно рассматривать как игровую площадку с игрушками и правилами игры. Завязывать всю игру на игрока, это как если бы ИРЛ игрушки работали только с конкретным ребёнком, по анализу ДНК.
Да, ты создаёшь "игровой опыт" для игрока, но ты создаёшь его с помощью деталей, которые от игрока никак не должны зависеть, они есть сами по себе.
Вот, например, шахматы. Где там игрок? Есть доска в клеточку - это игровая площадка. Есть фигурки - это игрушки. И есть правила перемещения фигурок. Игра существует независимо от конкретных игроков.
Можно сделать так, чтобы игрок перемещал фигуры клавиатурой, мышью, тачскрином. Можно сделать, чтобы второй игрок использовал тот же способ ввода по очереди с первым, или подключался через сеть. Можно сделать ИИ, который будет играть с игроком. Или придумать ещё что-нибудь. Игра от этого никак не меняется, меняются только игроки.
Мне очень надо выдрочить кор механику езды от 1 лица, чтоб езда была по кайфу. Как настоящий авто аутист готов дрочить этот аспект в ущерб всему остальному, делать текстуры салона и звуки своего личного автомобиля, чтобы не было дженерик авто. Ну очень меня заебало что в играх машина это коробка без инерции делающая жу-жу-жу вместо звуков и ездящая как тележка в Майнкрафте.
Мне не хватает пары наводок чтобы понять чем делаются кор механики. Первое это как делается езда от первого лица. Нашел шаблоны с ездой от 3 лица, но не понимаю как на их основе сделать 1 лицо. И второе, хочу генерировать новую сцену когда приближаюсь к концу текущей. То-есть один общий класс (сцена) на отрисовку участков дороги. И постоянно надо дорисовывать новую сцену перед текущей чтобы не было швов. Как генерировать новую сцену и подшивать перед текущей не знаю.
На работе пишу код, поэтому быстро начну ориентироваться. Приходится постоянно писать костыли, работать с объектами, и читать ебанутые чейнджлоги, так что не привыкать.
Я бы сделал игроку неуязвимость 5 секунд после загрузки. Даже если урон будет не от падения все-равно полезно.
>Ты сначала стадию прототипа пройди. Прежде, чем переходить к продакшену и цементировать механики игры, нужно сначала придумать нормальную игру. А для этого нужна максимальная гибкость кода.
Вот тут я с тобой не соглашусь, анон. Имхо вот как раз-таки прототип можно наговнокодить, главное чтобы передавал суть игры, ведь прикол прототипа в том что его можно сделать быстро чтобы оттестировать идею. Вот если она выстрелит то да уже желательно пилить нормально по бест практисес, чтобы ты даже если в соло делаешь потом не охуевал разбираться в своей же лапше. Проблема в том когда люди как тот челик держатся за говнокод и защищают его просто потому что скорее всего неговнокодить тупо не умеют.
Начинай с чтения документации.
https://docs.godotengine.org/en/stable/getting_started/introduction/index.html
Внимательно изучай, на слепом редактировании каких-то готовых примеров далеко не уедешь.
>машина это коробка без инерции
Если поиграть настройками VehicleBody, можно сделать что-то наподобие работы подвески GTA IV:
https://docs.godotengine.org/en/stable/classes/class_vehiclebody3d.html
Хватит сделать подвеску мягкой и настроить wheel_roll_influence, чтоб машина наклонялась. Но там колёсики - рейкасты, а не физические тела, поэтому телепортируются на бордюрах.
Есть вот такой автосимулятор на Godot:
https://lupine-vidya.itch.io/gdsim
Там машинки сделаны на RigidBody:
https://www.gtplanet.net/forum/threads/gdsim-v0-4a-autocross-and-custom-setups.396400/
Хотя, вроде, там тоже рейкасты (не читал).
>не понимаю как на их основе сделать 1 лицо
Просто переносишь камеру в голову персонажа, т.е. положение где-то внутри салона автомобиля. Если от третьего лица не нужно, то всё очень просто. Раз возникают такие глупые вопросы - читай мануал.
>Как генерировать новую сцену и подшивать
Самый простой способ, справится любой:
1. Определись, что тебе вообще нужно. Тебе нужен список участков дороги, нужных по геймплею.
2. Смоделируй участки дороги в Блендере. Следи за стыками, они должны подходить друг к другу. Определи один универсальный стык участков.
3. Сделай участки дороги отдельными сценами. Коллизии можно сгенерировать автоматически, но сложную геометрию лучше заменить упрощённой (смоделировать отдельный меш для коллизий).
4. Поставь в сцене дороги датчик (Area3D), который реагирует на приближение игрока (машины).
5. При приближении игрока сцена дороги спавнит следующий участок дороги, примерно так:
>var paths := ["road1", "road2", "road3", "road4"]
>var path := "res://%s.tscn" % [paths.pick_random()]
>var scene := load(path).instantiate()
>get_parent().add_child(scene)
>scene.global_position = to_global(next_part_position)
>$Area3D.monitoring = false # чтоб не спамить
6. Старые участки дороги потом удаляешь. Нужно подумать в зависимости от геймплея твоей игры, а именно возможно ли возвращаться обратно, будет ли обратная дорога такой же и т.д. Думать надо.
Сделай сначала 2-3 участка дороги, проработай алгоритмы, уже потом добавляй остальные.
Если хочешь процедурный ландшафт (heightmap) и полностью процедурные извилистые дороги, то иди смотреть аддоны. Порекомендовать ничего не могу, ничего из них не пробовал. Но советую для начала изготовить максимально простую тестовую сцену, прежде чем искать какие-то сложные инструменты. Простая сцена позволит проработать основной геймплей (езду на машине) до генератора карты.
Вообще, процедурная генерация - сплошная головная боль, особенно если ты толком не знаешь, что нужно. Рекомендую не лезть в это дело, пока нет геймплея. Статичной сцены достаточно для 99% фич геймплея.
Если не удовлетворяет встроенная физика:
https://github.com/godot-jolt/godot-jolt
Но я не уверен, как она работает с VehicleBody3D.
Также есть другие физические движки, если что.
Видео с июня 2023, там Godot 3.x с Bullet Physics.
Игры без вмешательства игрока в процесс быть не может. Даже когда игрок подбрасывает кубик, он может это сделать по-своему, а то что ты написал никак не противоречит моим словам.
>>956895
В стойло, копроскот.
>>956902
Спасибо за идею. Может применю, если вообще буду сталкиваться с проблемой перманентного урона. Просто эта механика даёт игроку возможность абуза.
>Игры без вмешательства игрока в процесс быть не может. Даже когда игрок...
Это довольно специфический жанр:
https://ru.wikipedia.org/wiki/Zero_player_game
Что-то вроде виртуального аквариума.
>там Godot 3.x с Bullet Physics
Только я даже не пытался сделать реалистичную симуляцию машины, фокус был на процедурной генерации более-менее интересной дороги между процедурными городами с геймплеем а-ля ГТА.
Слишком сфокусировался на генерации сеткой... Хотелось попробовать "органичную" генерацию, но совершенно непонятно как, и меши дорог сложно генерировать с нуля, а сцеплять их ещё сложнее. Приуныл от отсутствия геймплея и забросил всё.
В теории, пикрил должен был помочь. Но было лень моделировать это, как всегда "отложил на потом". Нет, всё ещё рассматриваю этот проект, но нужно всё пересмотреть и определиться, зачем мне это надо. Первая заметка по игре - май 2019. Делойте выводы. Концепцию в целом вынашивал, наверное, с 2009...
Спасибо. Сохранил этот пост себе в текстово файл чтобы перечитывать пока не найду все ссылки на необходимую документацию.
В Dead End Road машина покорачивает только при движении вперед, не умеет в разворот, и имеет странную инерцию (будто инпут лаг). Цель сделать аркадную напоминающую опыт ИРЛ, но без душного реализма. Звуковой банк на коленке запишу для погружения, так как мне не нравится бесплатная библиотека звуков.
Да, наверное проще наклепать 20 сцен состоящих извилистых дорог длинной в условный 1км. Просто мне кажется что если заранее настругать сцен, то рандом будет околонулевой, и придется либо дробить дорогу на очень маленькие кусочки, либо манипулировть спавном ебак и освещением чтобы игрок не выкупил уже седьмой раз едет по тому же куску дороги, только в другом месте. Тем более что если зон будет например 3 (лесная дорога, городская дорога, лес), то нельзя будет одну из 20 сцен во всех тред зонах использовать. В общем вопрос как не привести игрока в отупления от однообразие. Ну ладно, сегодня соберусь с мыслями, а завтра после работы попробую дефолтную хеллоуворлд сценку собрать.
>было лень моделировать
>отложил на потом
Вспомнил, почему я это говно тупое забросил:
- чем больше видов блоков, тем больше нужно промежуточных комбинаций, без которых алгоритм неспособен собрать карту без дырок, т.е. каждый новый блок должен мочь стыковаться с другими, и введение новой категории умножает число блоков;
- даже когда он работает правильно, результат у него дурацкий: много петель, тоннелей и т.д., это неплохо в рогалике каком-то, но не в планировке города;
- контроля практически никакого, рандом (можно инициализировать часть клеток, можно раздать приоритеты блокам, но всё это фигня какая-то).
Переделал с нуля, вспомнил всё это и приуныл...
Есть ли выход?
>рандом будет околонулевой
Каждая из сцен может иметь свой набор случайных элементов, например, на сцене "прямая дорога":
- ничего нет;
- автозаправка;
- гостиница;
- авария на обочине;
И т.п. Когда ты выбираешь "едем прямо", эта сцена выбирает у себя случайные компоненты.
>лесная дорога, городская дорога
Тут аналогично: сцена может быть одна, но на ней спавнятся либо плотные деревья с кустами, либо случайные дома, автобусные остановки и т.д.
Т.е. у тебя есть два направления:
- добавлять сцены-категории;
- добавлять вариации имеющимся сценам.
Логично связать категории с формой дороги, а всё остальное делать вариациями.
Суммарное число сцен = категории × вариации.
>привести игрока в отупления от однообразие
На сколько часов геймплея рассчитываешь? Совсем повторений не избежать, можно только отсрочить их появление. Игры со статичной картой заставляют ездить вообще по одним и тем же дорогам, так что возможно выучить карту наизусть и ехать не глядя. Здесь же как минимум не знаешь, что за поворотом.
>Суммарное число сцен = категории × вариации.
Суммарное число возможных комбинаций. Те самые "триллионы планет" из No Man's Sky, которые на деле отличаются в основном цветом поверхности.
Т.е. если хочешь, например, добавить новый тип леса, достаточно будет прописать пути к новым моделькам, сцены должны остаться теми же самыми (те 20 штук), но количество комбинаций умножится.
> Как вы придумываете?
Отвечают на три вопроса:
1. В каком сеттинге игра? Вселенная наобо
2. В чём главная фишка игры? рот с тол
3. Какие ещё имеются геймплейные особенности? щеходами
> Есть ли выход?
Я видел туториал по автотайлмапу в тридэ, и там автор уверял, что нужно всего 27 блоков, чтобы закрыть все варианты.
>Вселенная наоборот с толщеходами
Как успехи? Показывай.
>>956946
>автотайлмапу в тридэ
Тоже видел, но это немного другое:
https://robertheaton.com/2018/12/17/wavefunction-collapse-algorithm/
> Есть ли выход?
Самый разумный выход отказаться от автогенерации на стороне игрока, перестать хуярить однотипные рогалики, дать игроку один мир, вручную проработанный тобой лично. Возможно проработанный на основе автогенерации, но ты её потом лично ручками доработал и вручную заделал все дырки интересными квестами.
> Как успехи?
Изучаю физику, орбитальную механику.
> Показывай.
Пока не изучу и не научусь свободно манипулировать векторами тяготения - показывать будет нечего.
Расчет менее 2 часов. Езда между городами суммарно 3+4+5+6+7 минут если играет сам разраб. В городах между дорогами всякий микроменеджмент с покупкой предметов и сохранения. Неписи в городах должны объяснять куда ехать. Ебаки должны нещадно ебать чтобы срывать прохождение участков забега, заставляя быстро реагировать на них: переключать свет, выворачивать руль, менять скорость, включать дворники, выезжать на встречку в процессе. Ну и некоторым ебакам достаточно просто жутко попездывать, смачно хуесося мамку игрока, рассказывая охуительные истории и срываясь на крик. Тип чтоб концентрации мешать. И, если получится, киллер фича, забытая технология древних, возможность играть mp3 треки из папки. Радио должно то пердеть, то выключаться, то играть реверс песни когда концентрация ебак повышается.
Знаю про существование этого "жанра" "игр", но считаю его простой симуляцией. Всё равно что виндовсовский визуализатор музыки или наблюдение за размножением рыб назвать игрой. Во втором случае можно использовать азартные механики, но тогда вообще из чего угодно можно сделать игру, достаточно найти только двух игроков и поставить любое условие, которое определит кто победил, а кто нет, зависящее в конечном итоге от случайности.
Зависит от игры. Мозг любит наблюдать патерны и ритмы. Если на экране происходит симуляция чего-то базового. Будет интересно смотреть.
Немного более высокого уровня но что-то похожее. Давно у меня была спутниковоя сетевая карта в компьютере. И я включал на ней "спутниковую рыбалку", - сетевуха переключалась в promiscuous mode, и ловила весь контент от всех пользователей которые висели на этом транспондере. Можно было ставить фильтры на файлы которые ты хотел чтобы ловились. Так вот помню можно было часами наблюдать как начиналась закачка многотомных архивов с фильмами и сериями из сериалов. Следить как наполняются папки с музыкой. Почитывать имейлы пользователей, и их переписку в разных мессенджарах. Видеоролики, с порнухой и приколами. Веб страницы с новостями и контентом. У меня интернета тогда не было и это было развлечением.
Так вот если игру такую создать с использованием нейронки например. Наблюдать за колонией на марсе например. Следить как разрастается колония и за каждым человеком в частности. Как они реалистично строят отношения между собой и общество. Для тех кто проходят игры на ютубе сойдет.
И почему я раньше не догадался комбинировать несколько шумов?..
>физику, орбитальную механику
>свободно манипулировать векторами тяготения
Э... У тебя же "вселенная наоборот". Какие там орбиты? ИМХО, при рытье тоннелей можно пренебречь силой тяготения, т.к. ты заперт в тесном бесконечно заполненном пространстве, а гравитация - слабейшее взаимодействие:
>Gravity is, by far, the weakest of the four fundamental interactions, approximately 10 times weaker than the strong interaction, 10 times weaker than the electromagnetic force and 10 times weaker than the weak interaction. As a result, it has no significant influence at the level of subatomic particles.
У тебя толщеходы постоянно опираются на и отталкиваются от "тверди", от которой же и питаются энергией. Было бы странно реализовывать силу тяготения и орбитальную механику в такой ситуации. Всё равно что кроты, выходящие на орбиту морковок в огороде... Т.е. даже банальное трение о поверхность туннеля должно быть сильнее гравитации, тем более что толщеход по идее разработан для максимально крепкого сцепления со стенками туннеля.
Да и потом, главное - чтобы фан от игры был. Будет ли фан от орбитальной механики в игре про толщеходы?
А ведь так можно бесконечный опенворлд как в Майнкрафте сделать, всего на нескольких шумах.
>>956952
>отказаться от автогенерации
Но это же киллер-фича. Без неё скучно.
>интересными квестами
Процедурно генерируемыми квестами?
Планирую зайти с более универсальной стороны: создать очередь модификаторов карты, которые друг за другом влияют на меш (или спавнят меши?).
Воспользуюсь мощью ООП наследования.
Шейдеры пока трогать не хочу. Следовал советам из интернета модифицировать в вершинном шейдере и это было сложно и затратно. Лучше уж заранее меш модифицировать, шейдер будет попроще.
Но сначала нужно в 2D общие карты отрисовать...
Кто знает, генерация коллизий потокобезопасна? Хотелось бы вынести весь код в отдельный поток.
Объясните почему годот так популярен на этой доске? Со стороны кажется что 70% всех тех кто делает игры на этой доске делают на нем. Хотя на твг всего одна/пару игр обычно.
Грамотный пиар. Хуан много денег платит. Пиши в личку, познакомлю тебя с нужными людьми.
Потому что на остальных движках делают молчаливые гопники, а тут тусовочка.
Хули ты музыку из Unreal Gold спиздил, блять? Никогда не применяй проприетарные плейсхолдеры, уёбище, а то блядь забудешь в релизной версии и будешь кукарекать "АМИНЯТОЗАЩО", когда игру нахер удалят с площадок.
Ты ёбнутый? Трек на фоне включил, просто чтоб в видео играл, проспись.
На вот, держи. Как раз будет кого в титрах указать.
https://opengameart.org/content/dream-raid-cinematic-action-soundtrack
https://opengameart.org/content/brave-space-explorers
https://opengameart.org/content/messengers-from-above
https://opengameart.org/content/anti-entity
Пасиба, полистаю на сайте какие нибудь затычки которые так и останутся в игре конечно, если знакомый не напишет треки, отсюда скорее всего буду брать
>3898 download(s)
Ящитаю топ скилла поиска свободной музыки - найти годный трек с загрузками/прослушиваниями <100.
Саундклауд удачен для поиска таких хидден гемов. Только там ебланы редко указывают лицензию, приходится еще теги потрошить.
Главное - выбрать правильное направление.
>>957168
>Somewhere else entirely -> Register with autoload
Осуждаю такие советы новичкам, вредно.
1. Почему оно "где-то там"? А если его не будет?
2. Почему оно нам нужно? А нужно ли оно нам?
>>957181
CollisionShape3D вложи в StaticBody3D.
>официальные написаны долбаебами
Не знаю, вроде понятно и доступно.
>>957182
Народный движок же, от народа народу.
>Хотя на твг всего одна/пару игр обычно.
Там другие люди, я вот ни разу не участвовал.
>>957191
От бедра отдача идёт в руку, а не в тело.
> Осуждаю такие советы новичкам, вредно.
Я тебя скоро репортить начну. Отъебись от автолоада. Это стандартный механизм движка.
Это ты там советовал переписывать всю архитектуру, на случай если ВДРУГ захочется переделать игру в мультиплеер? Таблетки прими.
>CollisionShape3D вложи в StaticBody3D.
То-есть чтобы машина не провалилась мне надо делать шейп не только машине, но и полу? Не уловил идею. Сам факт того что все проваливается через все по дефолту меня очень смущает.
В чём твоя проблема? Просто не советую советовать автолоад как панацею от всех проблем доступа, чтоб новички не ходили по граблям как я:
>Somewhere else entirely
"Somewhere" - это где? Новичок будет совать в твои любимые автолоады каждый свой скрипт. И зачем вообще нужно дерево сцен, если всю игру можно написать в одном скрипте автолоада?
>стандартный механизм
Команда "goto" была стандартной во многих языках и повсеместно использовалась. И где она теперь?
https://en.wikipedia.org/wiki/Goto
>>957268
>если ВДРУГ захочется переделать игру
Godot - движок, в первую очередь, для прототипов. Естественно, что тебе захочется всё переделать. А ещё захочется использовать свой код из старого проекта в десятках новых проектов. Не хочется?
Все эти ноды, сцены, сигналы, GDScript - тут всё адаптировано для гибких переделок, чтобы части проекта могли свободно двигаться. Автолоады противоречат этой философии, прибивая твой код гвоздями к одной всюду доступной точке проекта.
Почитай документацию.
https://docs.godotengine.org/en/stable/tutorials/physics/physics_introduction.html
>Не уловил идею.
Базовая композиция сцены с физикой:
- Node или Node3D - корень сцены
- - StaticBody3D - неподвижное тело: платформа
- - - CollisionShape3D - коллизия платформы
- - - MeshInstance3D - графика платформы
- - RigidBody3D - подвижное тело: мячик
- - - CollisionShape3D - коллизия мячика
- - - MeshInstance3D - графика мячика
- - CharacterBody3D - тело, двигаемое кодом: игрок
- - - CollisionShape3D - коллизия игрока
- - - MeshInstance3D - графика игрока
- - Area3D - датчик объектов
- - - CollisionShape3D - коллизия (форма) датчика
И т.д.
CollisionShape3D сама по себе только контейнер для Shape, что передаётся наверх, конкретному CollisionObject3D, который может быть любым.
>Сам факт того что все проваливается через все по дефолту меня очень смущает.
В играх далеко не всегда нужна физика столкновений, многие объекты могут обойтись без этого. Кроме того, несколько моделей могут быть частями одного целого физического объекта, а один объект может содержать несколько независимых физических частей.
Но есть несколько способов упростить задачу.
1. У MeshInstance3D на панели сверху окна сцены специальная кнопка позволяет сгенерировать физическую форму или сразу тело. Нужно помнить, что автоматическая форма не всегда оптимальна, особенно когда твой меш большой и сложный.
2. Прототип статичных декораций можно сделать из CSG-нод, у которых есть галочка "use collision", которая автоматически включает статическое тело (тут тоже не всё гладко: CSG объекты часто имеют сложные поверхности, физика на них может глючить).
https://docs.godotengine.org/en/stable/tutorials/3d/csg_tools.html
> В чём твоя проблема?
В чём ТВОЯ? Ты же не воспринял совет, ты продолжаешь доёбываться. Свали нахуй в ишью на гитхабе и доказывай там Хуану, что автолоад ненужен.
Ты чего такой серьёзный? Нормально ж общались.
>автолоад ненужен
Кто сказал, что не нужен? Нужен, но редко: чтобы автоматически загружать набор нод независимо от выбранной сцены, например, надпись с числом FPS. Поэтому доступ к ним из настроек проекта, а не напрямую с главного экрана редактора. Новичку о них знать вовсе не обязательно, а то и вредно.
Пойми, я говорю о тех, кто не имеет богатого опыта разработки. Наломать дров с автолодами намного проще, чем без них, несмотря на их пользу в ряде отдельных, специфических случаев.
Кажется начинаю понимать. Название CollisionShape3D ввело в заблуждение поначалу. Да, видел что можно автоматически добавлять коллизии. Даже одну так сделал.Не туда одну коллизию поставил, даже не заметил, и машина стала проваливаться. Еще предстоит толкать машину с места, и камеру в салон ставить. Интересно что на iOS есть приложение по годоту, если кому интересно. Небольшой справочник.
Пока планирую игру, постоянно что-то рисую на бумаге. Недавно сделал заметку со скриптом для генерации дорог пока сидел на работе. Очень простой скрипт. Его задача в том чтобы дорога не сворачивала больше чем на 90 градусов, то-есть генератор не начал сворачивать дорогу в калач. Ничего не сделал еще в плане текстур и сцен, а гейм дизайн раньше в голове выстраивается раньше чем понимание как соединять объекты в редакторе годота. Главное не начать делать все и сразу, а просто описать на бумаге, перечитать и немного попуститься. Попадаю в ловушку когда пытаюсь найти в годоте сходство с классами java, а тут другое мышление, даже не программистское, а скриптизерское что-ли. В общем удаляюсь на несколько дней чтобы что-нибудь приличное сделать прежде чем заливать скриншот в тред.
>толкать машину с места
engine_force = достаточно большое значение.
По опыту, лучше увеличивать это значение плавно, чтобы оно не было слишком большим. Со слишком большим engine_force заднеприводный автомобиль встаёт на задние колёса... Как масл-кары в GTA 5.
Приятно с вами познакомиться, а тут можно чатик делать и дневничок или забанят?
Воспоминание разблокировано: наблюдать за дефрагментацией диска в Вин98. Он ещё похрустывал так удовлетворительно.
Олсо, полистал ветку. Мне кажется анон >>956871
>Игры могут быть без игрока.
имел ввиду не ZPG, а отсутствие протагониста, ака персонификации игрока, внутри игры. А потом началась какая-то дичь с наблюдением за какими-то самодвижущимися системами. Кстати даже в классической конвеевской "жизни" игрок не полностью отсутствует, он раставляет клетки по полю и запускает/останавливает симуляцию.
>игрок не полностью отсутствует
Зависит от того, рассматриваем ли мы "игру" как приложение для ПК или веб-сервера с каким-либо пользовательским интерфейсом, или как систему, работающую по своим внутренним правилам.
Игра "Жизнь" Конвея может рассматриваться как программа с GUI, через который пользователь расставляет клеточки на поле, но обычно, когда обсуждают эту игру, имеют в виду набор правил, по которым меняются клеточки на поле. И этот набор правил включает только соседние клетки на том же поле - в нём нет ни слова о каком-то там "игроке".
Считаю, в любой игре полезно абстрагироваться от устройств ввода и пользователя в целом. Не важно, как игрок взаимодействует с игрой, она всегда должна следовать чётким правилам.
Конечно, часто игры подстраиваются под игрока, например, в гонках машины под управлением ИИ ускоряются, если отстают от машины игрока, либо замедляются, если обогнали машину игрока. Всё ради того, чтобы игрок был в центре событий. Но теоретически можно было бы запустить гонку без игрока и машины ИИ будут гоняться сами с собой - гоночная игра существует сама по себе как набор правил движения гоночных машин, не так ли?
Но в оригинале тень синего цвета. Как сделать такую в годо.
Для тени, я продублировал готовый Sprite2D, наклонил, и поменял цвет. Но цвет можно сделать только черный, хоть и полупрозрачный. Иначе в тени можно разглядеть сам спрайт.
Можно ли с помощью движка залить спрайт синим цветом?
И еще мне приходится дублировать управления на спрайт и на тень. Есть ли способ сделать тень чтобы она автоматически копировала спрайт?
"Game" -этимологически значит приятное совместное времяпровождение.
"Игра" - этимологически значит движение
Видеоигры называются так из-за адаптации компаний выпускающих автоматы для азартных игр к запрету на азартные игры. Атари, нинтедо, вильямс(пинбол) это изначально компании обслуживающие именно сферу азартных игр. Весь этот дроч на то что в "играх должен быть геймплей" ногами упирается тупо в этот историзм. По-настоящему, развлекательный софт может быть намного шире и существует куча игр где геймплей далеко не на первом месте, от популуса, автошахмат и текстрима до метал гирек, хэви-рейвов и стейдж лайтов.
Можно. Напиши простейший шейдер "Если Цвет.Альфа больше 0 то цвет = вектор 4 (0.,0.,1.,0.4)". Если не хочешь писать шейдер, можешь попробовать с материалом поиграть, но я хз.
>Напиши простейший шейдер
Спасибо за наводку, шейдеры охуительны. Просто втыкаем какой надо цвет, без всяких вычислений.
А как комбинировать шейдеры? Хочу еще один шейдер добавить, чтобы сгибал тень. Часть тени которая на земле, чтобы сильно наклонена была, а часть которая падает на стену, чтобы вообще без наклона, как на видео.
> А как комбинировать шейдеры?
Добавлять в шейдер блоки и соединять их лапшой.
>Добавлять в шейдер блоки и соединять их лапшой.
Меня интересует, во первых, можно ли напихать больше одного шейдера в материал спрайта?
И во вторых, как комбинировать вертексные шейдеры с цветовыми. Но оказалось что это разные слои одного и того же шейдра.
У каждого материала есть next_pass. Туда пихается следующий шейдер.
>>957415
>Просто втыкаем какой надо цвет, без всяких вычислений.
Не заигрывайся. Если игра целится в старое железо или мобилки, любой шейдер может неожиданно въебать по фпс. А может и нет.
Читай документацию:
https://docs.godotengine.org/en/stable/tutorials/shaders/index.html
Также есть много бесплатных:
https://godotshaders.com/
Дополнительный шейдер тебе нужен обычно только если ты хочешь модульно комбинировать несколько шейдеров, например, добавить обводку или другой спецэффект поверх имеющегося. Тень персонажа возможно нарисовать одним шейдером.
>>957389
>можно водить Гава влево-вправо.
Тебе для чего? Ты у Союзмультфильм лицензию на использование данного персонажа получил? Если нет, они имеют легальное право убрать твою игру из любого легального маркета.
Если чисто для себя и близких, то ничего страшного.
>дублировать управления
Либо прикрепи спрайт тени к спрайту персонажа в дереве сцены, либо используй эту ноду:
https://docs.godotengine.org/en/stable/classes/class_remotetransform2d.html
Ты можешь вложить тень в потомки спрайта персонажа и включить у тени вот эту галочку:
https://docs.godotengine.org/en/stable/classes/class_canvasitem.html#class-canvasitem-property-show-behind-parent
>next_pass
Поискал. Оказалось у двухмерных шейдеров такого нету.
>>957431
>документацию
>есть много бесплатных
>Тень персонажа возможно нарисовать одним шейдером
Я спрашиваю у нейронки что мне нужно от шейдера и она дает готовый пример. А комбинировать эти примеры вместе особо нет желания. Не хочу пока на этом застревать ковыряясь в их потрохах и дебажить почему не работает комбинация из двух шейдеров. Хотелось на изи разные идеи с шейдерами перепробовать, соединяя их вместе более простыми путями.
>Союзмультфильм
Да я просто попытался разнообразить учебный процесс. Жаль не получилось отделить персонажа от фона с помощью нейронки.
>используй эту ноду
>вложить тень в потомки спрайта
Я продублировал ноду AnimatedSprite2D. Приходится в контроле, и теперь приходится еще дополнительно включать анимации и в спрайте тени. Просто я подумал было бы классно если бы можно было сделать инстанс, основного спрайта чтобы он полностью его повторял. Наверное можно было бы добавить тень, пририсовав ее шейдером в основном спрайте без всякого дублирования. Или сделать родительскую ноду над спрайтом и тенью. И обновлять их как-то вместе.
А вообще, оказалось сложнее чем ожидал. Надо бы пока эту тень оставить и вернуться потом со свежей головой.
Изменил немного арену, добавил не лицензированные треки и немног анимации поменял. Хотел ещё всякие дэш атаки боссу дать, но слишком туп для этого, займусь может после катсцен и локаций
Короче когда нажимаешь на джордж флойда оно считает количество нажатий.
Как мне теперь её в плеймаркете опубликовать чтобы рубить шекели?
И как сделал форму кнопки ровно по ебальнику флойда?
Или лучше сразу релизнуть в стиме, я считаю, что такой АААА гейминг заслуживает ценника в 70$
>"Игра" - этимологически значит движение
Задорнова переслушал?
Ни в какой момент истории ни в одной ветке славянских языков слово "игра" не было даже и краешком связано со смыслом "движение".
[jьgra] - Древнерусская фонетика слова "игра"
[jьgra] - Древнерусска фонетика слова "движение" - "ёра", от которого прозошло, например, слово "ёрзать"
Двачую этого. Латинский язык произошёл от древнерусского (Rasenna, Raśna) — древняя цивилизация, населявшая в I тысячелетии до н. э. северо-запад Апеннинского полуострова (область — древняя Этрурия, современная Тоскана) так же этруски).
Затем от латинского произошли все европейские языки.
ну вот получается партикл как child у сигареты, visibility AABB маленьким квадратиком выставлен тоже
я так понимаю что это из-за того что партикл не успевает "умирать" и остается на том месте где был до поворота камеры
Игра с открытым миром? По скольким локациям уже можно погонять?
Там внутри партикля есть опция локальных координат, как показано на прилагаемом скриншоте. Опция выключена по умолчанию. Включи её.
> По скольким локациям уже можно погонять?
По одной. Но зато в ней есть высокодетализированный советский шкаф, как у бабушки в детстве.
>StaticBody3D, которое служит полом сцены
>Как прибить гвоздями статичное тело?
StaticBody3D никак движком не двигается, ты сам двигаешь его из своего кода, если хочешь.
Скорее всего ты сам запутался, где у тебя пол, а где потолок. Добавь (вывернутый) куб с координатами "это пол (Y-), это потолок (Y+), это стены (X, Z)". Без коллизий, просто висящий в пространстве куб.
А, кажется, я понял твою проблему.
Ты привязал камеру к сфере без текстур? И площадка ВНЕЗАПНО начинает вращаться вокруг сферы, только когда сфера касается площадки? А небо с горизонтом у тебя пока не настроено?
Тогда всё понятно. На самом деле это не площадка вращается, а шарик катится по площадке. А камера, через которую ты смотришь, вращается вместе с шариком, и это создаёт иллюзию, будто вращается площадка. Добавь небо с горизонтом и увидишь:
https://docs.godotengine.org/en/stable/tutorials/3d/environment_and_post_processing.html#preview-environment-and-sun-low-priority
Также советую всё обмазать текстурой-сеткой:
https://kenney.nl/assets/prototype-textures
Или такой: https://uvchecker.vinzi.xyz/
Тебе написали про локальные координаты.
Суть в том, что если координаты глобальные, то партикл относительно глобального мира (актуально например в случае искр из под колес), а если локальные, то относительно спавнера.
Показывай видео или скрин дерева сцены хотя бы. Одно предположение что ты их привязал чайлдом друг к другу и движение одного двигает и другое.
>предположение что ты их привязал чайлдом друг к другу и движение одного двигает и другое.
Я проверял, такое почему-то не работает:
- RigidBody3D
- - StaticBody3D
Статик останется неподвижно в пространстве.
Сегодня размышлял об ИИ для персонажей и вот вспомнил, как делал для себя аддон в ноябре.
Сначала я хотел просто фреймворк для нелинейных историй с удобным GUI, но потом этот проект начал мутировать в универсальный граф чего угодно, чтоб служить затычкой в любой разветвлённой бочке. Но почему-то приуныл тогда и забросил всё это.
Концепция была такова. Основной блок "sequence" - это линейный набор строк с тегами или чего-то ещё, если возможно (хотелось прикрутить типизацию, но непонятно как). У этого блока есть вход и выход, их можно соединять с другими блоками. Несколько соединений с выходом - это select/option, несколько соединений со входом - это merge (слияние веток). Обрабатывается граф специальной виртуальной машиной, которая делает все переходы, формирует списки опций на развилках. Что делать со строками и тегами решает сам пользователь, машина только возвращает значения из ячеек sequence.
Очень хотелось добавить условные выражения для блокирования входа в блоки и/или автоматического выбора следующего блока без внешней обработки. Однако я не разобрался, как это лучше сделать; тупо накидывать выпадающие менюшки мне надоело.
Идея с sequence возникла для решения проблемы, когда в редакторе с ниточками нужна некая длинная последовательность. У меня это столбиком, нитки в основном для развилок и слияний блоков. Нитки полезны для визуального представления ветвления, которое в линейной записи часто неудобно выглядит. Разумеется, сделал drag&drop для строк sequence, поэтому их легко делить на части по необходимости (конечно, в идеале нужно однокнопочное решение). Вообще, хотелось сделать что-то вроде инспектора ресурсов, только с ветвлением ниточками...
TL;DR: хочу всё и непонятно что => до ума не довёл.
В общем, что скажете? Ненужный велосипед?
Не помню, постил это здесь или нет?
Некст буду тдшку делать, точнее уже чутка начал. Чувствую больше всего со звуком намучаюсь.
Бывайте.
>сделать не могу в фхд
По-моему, можно сделать разрешение окна игры значительно больше разрешения экрана. И сделать скриншоты и видео с него. Конечно, кликать можно будет только в области, которая умещается в экран, однако, если у тебя весь кликабельный гуй с одной стороны, в настройках редактора есть опция для размещения окна игры в конкретном месте.
Ещё проблема: продумал возможность создания циклических связей, однако как разместить нитки визуально, чтоб легко читалось - непонятно. Вроде настройка изгиба есть, но как я посчитаю изгиб? Полностью вручную рисовать пробовал - опять же, необходимо как-то определить границы блоков...
Вот пример с тегами. В теории, их должна парсить виртуальная машина (не проблема со StringName), а дальше игра делает какие-то действия: выводит картинки, анимации, спецэффекты, надписи. Пока недоделано, но я планировал сделать менеджер, в котором к тегам можно привязать какие угодно данные, вроде png картинок. Плюс хотелось бы автодополнение при вводе тега в ячейку...
Вообще много чего придумал, но недоделал. Скажем, объединение в группы или "рабочие столы": можно разместить блоки в разных вкладках для удобства. Или вот хотелось сделать вызов метода скрипта. Вообще писать кусочки скриптов. В теории можно, но как проверять валидность кода? Сложно будет.
Какое отношение к игровому ИИ? Хотелось сделать редактор иерархических конечных автоматов или что-то в этом роде. Видел готовые аддоны, но мне совершенно не нравится юзать ноды для этого.
Приуныл и растерял мотивацию. Как всегда...
>>957657
Ощутил прилив сил вечером и стал играться с кэфами. Первое что сделал это добавил коллизию главной ноде. Просто забыл, из-за чего обидно. Потом понизил усиление пружин на колесах. В общем сделал неопрокидываемое авто, физон которому можно улучшать бесконечно. Можете использовать мой рецепт для гонащек.
Ещё такая мысль, изначально я сделал возможным сворачивать (минимизировать) блок, чтобы остался только заголовок и связи, для этого кнопка с иконкой свитка (скрипта). Но я видел где-то такой подход, что спискота отображается в отдельном боковом меню, а граф содержит только ноды с заголовками. Думаю попробовать так, но тогда нельзя будет захватить всё содержимое графа в один скриншот, и могут быть дополнительные проблемы с drag&drop'ом.
Сложно как то и неудобно, да и фуллскрин у меня запускается на мое разрешение а не проекта.
Делай контрол нодами. Сделай грид или Хсплит контейнер и засунь свои кубы туда для автовыравнивания. И используй не анимированнвй спрайт, а Текстурированый прямоугольник. Засунь свои кубы в ресурс анимейтед текстуре и меняй номер кадра для куба.
https://godotengine.org/article/dev-snapshot-godot-4-3-beta-2/
Дисклеймер: делайте бэкап проектов, есть несовместимые изменения.
Однопоточный веб экспорт
Проигрыватель сэмплов, для веб аудио без заиканий. Очевидные подводные это не для процедурных звуков. И надо прогружать заранее.
Улучшенный бутскрин
Обещают улучшение работы веб экспорта на айфонах
Добавление в веб рендер недостававших: MSAA and resolution scaling, Glow, ReflectionProbes, LightMapGI, Adjustments and Color Correction
Какой то рефакторинг AnimationPlayer, пока не читал что именно https://godotengine.org/article/migrating-animations-from-godot-4-0-to-4-3/
Добавлена нода SkeletonModifier3D, вроде то что не успели к 4.0
Импорт fbx без сторонней утилиты.
Обратный буфер глубины 3д, некоторые шейдеры надо переписывать https://godotengine.org/article/introducing-reverse-z/
Некоторые улучшения для пиксель перфект 2д игр, https://godotengine.org/article/dev-snapshot-godot-4-3-beta-1/
Оптимизация рендерграфа, возможное ускорение на 10%
Автообновление версии движка из хаба
> делайте бэкап проектов
Или пользуйтесь godot-manager и тогда вы будете уверены, что ваш проект запускается на явно настроенной для него версии движка.
Речь про ситуацию, когда ты захотел перевести проект на след. версию, например ждал какую то фичу или исправление бага, но потом не понравилось, допустим появился другой баг, и ты хочешь открыть старой версией, но так не выйдет.
>понизил усиление пружин на колесах
Ты подвеску убил - не держит машину.
>неопрокидываемое авто
Такие настройки попробуй.
>добавил коллизию главной ноде
Зачем? Она (Node3D) коллизию не принимает.
Читай внимательно:
https://docs.godotengine.org/en/stable/classes/class_collisionshape3d.html
>A node that provides a Shape3D to a CollisionObject3D parent and allows to edit it. This can give a detection shape to an Area3D or turn a PhysicsBody3D into a solid object.
Т.е. она нужна только потомкам этого класса:
https://docs.godotengine.org/en/stable/classes/class_collisionobject3d.html
>Abstract base class for 3D physics objects. CollisionObject3D can hold any number of Shape3Ds for collision.
Лично от себя рекомендую держать CollisionShape3D в списке потомков ближе всего к её предку, чтобы в случае чего сразу видеть, к чему она относится:
- физическое тело или зона-датчик
- - форм(а/ы) коллизии
- - визуальная модель
- - колёса и всё такое прочее
Полагаю что у VehicleBody3D из коробки откровенно всратые параметры физона по умолчанию, и поэтому многие разрабы берут сбалансированный RidgidBody3D чтобы хуяк-хуяк и сразу в игру закинуть. На данный момент у меня пружины дают адовейший body roll, который напрямую зависит от массы авто и гравитации. У тебя на видео лимузин рассекает в поле с физоном из роблокса, поэтому он устойчив. Столб с 4 колесами еще устойчивей будет, но можем ли мы его назвать машиной?
Попробую найти материал по зависимости параметров физона друг от друга. Не зря же советуют при массе 1000 делать тормоз 25. Существуют коэфы, которые предусмотрели разрабы, и при других значениях физон становится не очень.
Хочу сохранять сцену как в различных РПГ от бефезды типа Skyrim, Fallout 3, чтобы все объекты сохранялись в том же положении, с теми же характеристиками и переменными, что и в момент игры. Я попробовал использовать методы ResourceSaver и Resourceloader. Они работают не так, как мне надо. Когда я сохраняю сцену, сохраняются только те объекты, которые были заранее на ней в момент её создания. Если добавить на сцену новый объект при помощи add_child(), он не будет сохраняться, при этом никакой ошибки редактор не выдаёт. Предметы можно свободно передвигать, физические объекты сохраняют инерцию и энергию, а новые дети сцены просто испаряются.
Сначала я попробовал это исправить через перебор всех детей сцены при помощи цикла for и метода PackedScene.pack(), но это не сработало потому что .pack() сохраняет только одну ноду, а прежнюю ноду из PackedScene стирает. Что надо сделать, чтобы сохранялись все ноды current_scene в файл PackedScene?
Почитай про owner. Но вообще тут надо делать свою систему сейвов.
>Но вообще тут надо делать свою систему сейвов.
Что ты имеешь ввиду? Эти функции не подходят для сейвов?
В голове есть представление как делать систему из создания новых и перезаписывания старых сохранений, это потом имплементирую. Сейчас пока с одним файлом работаю.
Сохраняешь ноду - проставляешь всем ее детям овнеров. А "своя система сейвов" не нужна. У меня два проекта на пакед сценах сделаны, полет нормальный.
Алсо для сохранения на диск я использую бинарный .scn вместо .tscn. С tscn был какой-то баг, уже не помню какой, писал о нем ИТТ тредов 15 назад.
>owner
Блин, чёт не работает.
У меня в коде записано примерно так:
holded = объект, который игрок держит в руках
face_cast.get_collider( объект, на который смотрит игрок ).add_child( holded )
holded.set_owner( holded.get_parent() )
Почему-то не работает, хотя проверка через print(holded.owner) показывает то что ожидалось.
>>957762
А какой смысл в пикрил? Разве овнеры сразу ещё не расставлены? Вроде всё нормально сохраняется кроме добавленных нодов. Энивей, попробую, с чем чёрт не шутит!
>>957764
Посмотрим, попробуем
> A node can have any other node as owner (as long as it is a valid parent, grandparent, etc. ascending in the tree). When saving a node (using PackedScene), all the nodes it owns will be saved with it. This allows for the creation of complex SceneTrees, with instancing and subinstancing.
>Note: If you want a child to be persisted to a PackedScene, you must set owner in addition to calling add_child(). This is typically relevant for tool scripts and editor plugins. If add_child() is called without setting owner, the newly added Node will not be visible in the scene tree, though it will be visible in the 2D/3D view.
Нет, овнеры не расставлены. Это не родители, это фича скорее от движка для движка.
Потому что в отличии от второго ответившего анона, я не считаю что для игры "типа скайрима" нужен сейв сцены со всеми коллайдерами и прочими зависимостями. А нужен сейв "предметной модели" - сохранить, например, что условная телега сейчас по координатам xyz под углом uvw, а при загрузке спавнить нужную сцену с коллайдером в нужном месте.
Сработало!!! Спасибо, не все герои носят плащи
>>957767
Понял, спасибо
>>957768
Я об этом думал, но понял, что гораздо проще в моём случае (небольшие, практически комнатные сцены) всю сцену сохранять в один файл. Понятное дело, что в игре с открытым миром каждый раз сохранять всю карту на отдельный сейв просто неразумно, а загрузки будут долгими.
>всратые параметры физона по умолчанию
Да, параметры странные, не менялись годами.
>RidgidBody3D чтобы хуяк-хуяк и сразу в игру
Я несколько раз пробовал сделать велосипед на RigidBody3D, это довольно сложно, я не осилил.
>пружины дают адовейший body roll
Поставь roll_influence = 1 или 2, немного поможет.
>У тебя на видео лимузин
Там габариты чуть короче и шире, чем у Жигулей.
>с физоном из роблокса, поэтому он устойчив
Даже в GTA 5 (!) увеличили силу тяжести машинам, прижимая их к асфальту так, будто они на рельсах.
>Столб с 4 колесами еще устойчивей будет
Нет. Чем выше центр тяжести, тем легче опрокинуть, поэтому специально занизил центр тяжести (смотри внимательнее на center of mass у VehicleBody3D).
>но можем ли мы его назвать машиной?
На видео вообще сфера. Туториал (устарел):
https://kidscancode.org/godot_recipes/3.x/3d/3d_sphere_car/
>найти материал по зависимости параметров
Самое надёжное - смотреть исходники движка. Но если ты хочешь прям реалистично, то тебе нужно самостоятельно делать всё на RigidBody3D...
Однако, я тебя не понимаю. Ты хочешь повторить игру, в которой машина не может развернуться на 180 градусов, т.е. это "вагонетка на рельсах", а не настоящая машина. Я бы на твоём месте взял ноды PathFollow3D и Path3D, чтобы привязать "машину" к дороге, а физику имитировал бы смещением меша.
https://docs.godotengine.org/en/stable/classes/class_pathfollow3d.html
В старых 2.5D гонках не было настоящей физики, машинка вообще никуда не катилась - создавали иллюзию за счёт смещения сегментов дороги.
>нужен сейв "предметной модели"
Годочую.
>>957769
>всю сцену сохранять в один файл
Проблемы с таким подходом:
1. В файл сцены можно запаковать скрипт, при чём автоматически запускаемый. Т.е. есть возможность разработать GDScript-вирус, который будет скакать по сейв-файлам и делать свои грязные дела. Это обсуждалось на GitHub, официальное мнение:
>ну, делать песочницу для кода сложна, и вообще не наша забота, пользователь сам дурак, юзайте json
С чем я полностью согласен. Юзаем json.
2. При обновлении движка меняется формат сцен, некоторые сцены вообще приходят в негодность. Соответственно, либо сидишь на одной версии, либо ломаешь пользователям сохранения игры.
3. Если ты хоть что-то в своих сценах меняешь, все сохранения этой сцены становятся неактуальными, проверить и исправить автоматически ты это вряд ли сможешь. Соответственно игроки вынуждены начинать игру с нуля, чтобы оценить новый контент.
4. Избыточные данные. Да, ты можешь сказать "да ладно, сцены небольшие", но есть нюансы:
- сцены небольшие, но их будет много (РПГ же?);
- некоторые ресурсы в сценах очень жирные, типа массивов тайлмапа/гридмапа, некоторые Shape3D, некоторые Mesh, и т.д. Буквально десятки мегабайт может занимать визуально простенькая сцена. О бинарном формате не знаю, что там по сжатию...
Короче, если делаешь что-то больше "игры-прикола" на один раз, лучше подойти к сохранениям серьёзно.
>roll_influence = 1
>center_of_mass
Попробую. Вообще придется опять все коллизии проверять, а так же форму коллизий колес. Общая коллизия на машине у меня пока ящик, но я все больше убеждаюсь что это работает тогда и только тогда когда мы хотим прибить машину к полу. В идеале нужна даже не сфера, а эллипсоид как промежуточная фигура. Когда коллизия ящик, то сначала все очень удобно, но если предусматривается крен, то он становится таким резким, что машина начинает вращаться вокруг своей оси. Возможно сделаю шейп из нескольких шейпов.
Проворот тел вокруг своей оси отлично описывается здесь. У меня 1 в 1 опыт на 4.2.2..
https://forum.godotengine.org/t/issue-with-vehicle-suspension-when-applying-angular-forces/41729/6
>Ты хочешь повторить игру, в которой машина не может развернуться на 180 градусов, т.е. это "вагонетка на рельсах"
Хочу заменить езду на более технологичную, перейти с 2.5д на 3д. Чтобы слегка укачивало, был легкий крен и опрокидывание на крышу при вывороте руля на максимальной скорости.
>Насколько это удачная ниша?
1. Нужны друзья.
2. ...кому нравится играть в те же игры, что и тебе.
3. ...и они должны быть в одной комнате с тобой.
4. ...и у вас должно быть минимум два геймпада или желание сидеть вдвоём за одной клавиатурой.
5. ...при этом очень желателен большой монитор.
А теперь подумай сам о том, как ты сужаешь ЦА.
>одной галкой переделать в онлайн кооп.
Не знаю, не слышал, сильно сомневаюсь.
Там есть API для p2p мультиплеера, но локальный кооператив принципиально отличается от онлайна.
Брух, так у всех нормальных людей пункты 1-5 по дефолту присутствуют.
>сильно сомневаюсь
Погуглил - Remote Play Together называется.
>Когда коллизия ящик, то сначала все очень удобно, но если предусматривается крен, то он становится таким резким, что машина начинает вращаться вокруг своей оси.
Возможно, у тебя колёса в пол западают. У меня нормально с "ящиками", никаких сфер не нужно.
>Проворот тел вокруг своей оси
Так ведь там проблема была в apply_force(). Тебе эта функция вообще не нужна для VehicleBody3D.
>Чтобы слегка укачивало, был легкий крен и опрокидывание на крышу при вывороте руля на максимальной скорости.
Чисто технически, всё это возможно сделать через анимации, не используя физическую симуляцию. Физическая стимуляция нужна для неровного ландшафта, бордюров, сложных столкновений.
Брух, мы на дваче. Нормальные люди социоблядстивуют, а не капчу вводят.
https://www.reddit.com/r/godot/comments/1dkzeun/statically_typed_gdscript_should_be_the_default/
>After having built a 3D bullet hell in GDScript, spending almost as much time doing optimizations as I spent on programming the prototype, and now building a similar prototype in C# using the physics / rendering server...I can't think of any reason to NOT statically type your GDScript code.
>I did a side-by-side optimization comparison test that directly accesses the Physics/Rendering 3D server to create 3000 bullets in GDScript and C#. Statically typed GDScript was only about 10% FPS slower than the C# version.
Из комментариев:
>And the gains going from dynamically typed GDScript to full out statically typed GDscript was literally 40-50 fps to 200+ fps.
>And this difference is only exacerbated the larger your project becomes, as games ultimately do.
Один из крутанов пишет:
>KoBeWi
>Actually, type hints are enabled by default in 4.3 and AFAIK demos/documentation are being updated to use typed code.
Все так. ГДСкрипт с тайпхинтами довольно шустр и гораздо удобней чем без, и его давно уже всюду пихают и правильно делают. Идеально. Не удивлюсь если юнька через пару лет гдскрипт украдет и он станет де-факто дефолтом для геймдева.
>если юнька через пару лет гдскрипт украдет
Юридически они имеют право, пусть крадут. Но эффективные менеджеры не смогут сладить с тысячами программистов, которые нужны, чтобы выкрутить лампочку виртуальную машину GDScript из Godot и вкрутить её в Unity. Дорого, тут нужны триллионы долларов, а $U всё падает и падает.
Поэтому продолжаем делать игры на Godot.
>станет де-факто дефолтом для геймдева
Game Develop Script
А у него есть бур?
Реализовал себе фичу из GTA 5: контроль поворота в воздухе. Знал об этой фиче много лет и активно её использовал, но и подумать не мог, как сильно она влияет на ощущения от геймплея. Разница уровня "беспомощный кирпич" vs "крутой акробат". Только теперь по-настоящему понимаю решение Rockstar.
>>957781
>становится таким резким, что машина начинает вращаться вокруг своей оси
Я вспомнил об одной очень важной для правильной физической симуляции настройке, о которой редко упоминают: angular_damp. Суть в том, что реальные объекты замедляются сопротивлением воздуха, зависящего от формы объекта, но в игровом движке слишком дорого симулировать потоки воздуха. Так придумали упрощённую формулу, приблизительно имитирующую сопротивление воздуха.
Короче, значение по умолчанию 0.1, оно нормально подходит только сферическим объектам. Машинке необходимо поднять это значение повыше, тогда спокойнее будет реагировать на работу подвески.
На видео angular_damp должен быть равен 1.0, но я сделал это для более точного контроля в воздухе.
Фигню какую-то сделал. У тебя только одна кнопка в главном меню? А зачем тогда она нужна? Или это экран "нажмите что угодно чтобы войти в главное меню"? Но тогда главное меню уже должно быть в дереве сцены, чтобы не тормозило.
Я тоже думаю стоит переделать архитектуру, на случай если захочется сделать кнопку мультиплеерной.
Не смешно. Поведение главного меню изменится с большей вероятностью, чем дизайн геймплея.
Алсо, любую игру можно переделать в мультиплеер, а мультиплеер чрезвычайно популярен у нормисов, так что полностью сбрасывать его со счетов нельзя.
Так и представляю как за месяц до релиза начинаю переделывать свою визуальную новеллу в ммо.
>за месяц до релиза
О, ты прям как ААА студия, дедлайн себе ставишь. Кранчишь поди 24/7, премию себе урезаешь за невыполнение сроков, потом переносишь релиз несколько раз, а на выходе всё равно киберпук77.
>визуальную новеллу в ммо
Книжки читать тоже можно большой компанией.
Я не, но даже это лучше чем как ты - бесконечно вариться в продакшн хелле, переделывая один участок кода раз за разом, в итоге выпуская игру морально устаревшую лет на 10, а то и не выпуская ничего.
>морально устаревшую лет на 10
Судьба всех труъ инди...
>а то и не выпуская ничего
Лучше вообще ничего не выпускать, чем пополнить огромную коллекцию никому не нужного софта.
Найс аутотренинг у тебя, канешн. Но мамка твоя тебя все же релизнула.
Молодец!
Вчера смог исправить все проблемы с физоном. Сделал коллизию авто из трех циллиндров. Этого за глаза для npc тачек. Главная машина временно будет такая же пока не решу какой ей нужен физон. Теперь пора соденинять несколько сцен чтобы была бесконечная прямая дорога, и процедурно добавлять в них встречные машины. Потом изучать работу физона столкновений со встречкой. Есть идеи на счет сюжета чтобы был смысл идти из точки А в точку Б. А то обычно в хоррорах просто бросают игрока в сцену и говорят: "давай дальше сам как-нибудь, только красную дверь не трогай, иначе умрешь".
Еще оказалось что игра Spooky Night уже существует, поэтому переименовался. Жаль имя Night Drive тоже было занято. Кстати графическая часть в Night Drive выглядит охуенно: езда от 1 лица с графоном и ебаками SCP. Вот только сами ебаки из SCP как бревна с глазами стоят и изредка двигаются. Сюжет на уровне найти на обочине ебаку чтобы сюжет продолжился.
Спасибо, ты тоже молодец.
>смог исправить все проблемы с физоном
Ээээ... Как бы сказать...
Во-первых, колёса VehicleWheel3D, по идее, должны располагаться примерно по середине меша шины колеса. В противном случае у тебя машинка будет физически заезжать колесом на бордюр, когда визуальное колесо ещё не находится на бордюре. От первого лица это не критично, наверное, но могут возникнуть проблемы со стенками (эти колёса не являются твёрдыми, там просто рейкаст) и NPC.
Во-вторых,
>Сделал коллизию авто из трех циллиндров
Это очень странное решение. На твоём же видео машинка нереалистично покатилась из-за того, что она физически круглая. А ещё вот:
https://docs.godotengine.org/en/stable/classes/class_cylindershape3d.html
>Note: There are several known bugs with cylinder collision shapes. Using CapsuleShape3D or BoxShape3D instead is recommended.
>Performance: CylinderShape3D is fast to check collisions against, but it is slower than CapsuleShape3D, BoxShape3D, and SphereShape3D.
Вкратце: самая багнутая и самая медленная форма из всех примитивов, лучше пока не использовать. В альтернативных физдвижках может быть иначе.
В-третьих, попробуй менять angular_damp... или это:
https://docs.godotengine.org/en/stable/classes/class_rigidbody3d.html#class-rigidbody3d-property-inertia
Можно настроить вращение по каждой оси.
Но ты прав в том, что лучше поработать над другими элементами игры. Как минимум тебе нужна длинная извилистая дорога для полноценного теста езды, по текущему короткому участку сложно что-то сказать.
>Есть идеи на счет сюжета чтобы был смысл идти из точки А в точку Б. А то обычно в хоррорах...
Можно сделать что-то в этом духе:
https://ru.wikipedia.org/wiki/Мгла_(фильм)
Спасаемся от растущей зоны НЁХ, из которой лезут различные монстры. На мой взгляд, страшнее будет сделать так, чтоб монстры нападали в т.ч. друг на друга, ибо так они правдоподобнее (у них там своя экосистема, люди для них просто необычная еда). Геймплей можно завязать на том, что если хорошо водишь машину - отрываешься от монстров, а если плохо - должен чаще уворачиваться от нападений. Дальше оторвался - больше времени на заправке. Безумные водятлы, мешающие сбежать, олени на дорогах, упавшие деревья и камни, огромные ямы, перекрытые на ремонт участки дороги добавляют препятствий, повышая риск затормозить.
Кстати, повторяемость участков дороги в данном варианте геймплея не страшна, поскольку весь фан в реакции на неожиданные ситуации на дороге. Так геймплей можно сделать условно-бесконечным, чтоб было интересно проходить без конца, стараясь проехать как можно дальше, прежде чем сожрут. В общем, классическая аркадная формула.
>переименовался
Не парься о названии пока.
Ещё о камере. Вроде ты хотел от первого лица, но почему-то размещаешь камеру снаружи машины. Вопрос, зачем? Вид камеры сильно влияет на ощущения от геймплея. Конечно, нужно сделать салон машины и прозрачные стёкла, но в лоуполи это не так уж сложно, и наверняка есть готовые бесплатные модельки с салоном.
Для камеры от третьего лица нужно как минимум:
1. SpringArm3D для вращения по X/Y и сближения, если между камерой и объектом препятствие.
2. Убрать вращение по Z, чтобы камеру не шатало вместе с машиной. Раньше думал, что это прикольно, однако быстро начинает раздражать.
С камерой от первого лица чуть проще. Но там свои проблемы, ведь угол обзора сильно ограничен.
А впрочем, четвёрка же. Можно быть ещё круче.
В плане физона для npc машин оставляю то что есть. Вся надежда на то что машина быстро появляется в кадре, и так же быстро пропадает, из-за чего игроку ее физон вообще не важен пока поведение в пределах нормы. Камеру к машине для 1 лица еще не прикручивал. Все еще делаю тесты в 3 лице. Салон (и вся остальная машина вокруг) не в наличии, а без него 1 лицо имеет мало смысла. С новой моделькой надо заново все части машины собирать, и заново гонять параметры через тесты. Скачал Blockbench и MagicaVoxel для графона.
Пока вижу резонным не усложнять ландшафт, и иметь плоскую текстуру, делающую вид будто на ней есть объемные бордюры и ямы. Яма может быть пятном на карте, у которой прописана смена гравитации чтобы подвеску вжимало, а бордюр так же, но в другую сторону. Главное чтобы игрок поверил.
Все шейпы хороши, но для машин мне проще использовать циллиндр. Теоретики могут писать что хотят, но лично у меня в сценах все работает прекрасно без багов. В шейпе две оси, одна из которых напоминает куб, а вторая капсулу. Стык имеет специфичный физон, но, сюрприз, он такой же неочевидный в реальной жизни. То что "CylinderShape3D is fast to check collisions against, but it is slower than CapsuleShape3D, BoxShape3D, and SphereShape3D" меня не удивляет, и никак не мешает. Не понимаю почему дауны ожидают от опенсурсных упрощенных шейпов в godot каких-то чудес на уровне специализированного пропиретарного движка Havok.
Если нужен переворот на крышу на максимальной скорости при вывороте руля, то подгонять десятки параметров тела под этот случай можно бесконечно. Мне видится что намного легче сделать этот переворот когда достигнуты определенные значения скорости и угла руля. Как только оба значения равны искомому, делаем каунтер +=1 (1 фрейм условие выполнилось). При N фреймов переворачиваемся. В нейтральном положении руля сбрасываем каунтер. Мне будет в будущем проще код показать наверное, чем объяснить. Такой костыль мне дешевле по времени написать чем стать специалистом по RigidBody3D.
Сюжет простой: главгерой автостопом едет в ебеня чтобы купить себе машину. На месте выесняет что в машине умер дед. Ну и дальше чел уже один едет и офигивает, что он дорогу не знает, пытается достучаться до местных чтобы направили. И так едет из города в город. Ну а неписи как в Морровинде такие: как поедешь там за речкой сверни, а потом налево, че как маленький.
>бесконечно вариться в продакшн хелле, переделывая один участок кода раз за разом
Так наоборот если говнокодить без какой-либо попытки заложить архитектуру на будущее, то увеличиваешь шансы увязнуть в лапше когда в очередной раз попытаешься добавить фичу и поймёшь что конструкция уже трещит по швам. Чистый код, паттерны и прочую залупу придумали на вот таких ошибках как у тебя, впрочем я думаю что пока говнокод тебя не ужалит в жопу, смысла втирать про бест практисес нет. Каждый должен наговнокодить свою долю прежде чем осознать зачем нужны паттерны.
https://github.com/godotengine/godot-proposals/issues/56
>AThousandShips commented May 16, 2024
>At this time there isn't really anything that needs doing from any contributor, we're in feature freeze for 4.3 so it won't be merged right now, but hopefully it can be reviewed early in the 4.4 release cycle, it's a large feature so it's been hard for reviewers to find the time to focus on it properly.
https://github.com/godotengine/godot/pull/78656
>All core issues are resolved!
>var typed_key_value: Dictionary[int, String] = { 1: "first value", 2: "second value", 3: "etc" }
>var typed_key: Dictionary[int, Variant] = { 0: "any value", 10: 3.14, 100: null }
>var typed_value: Dictionary[Variant, int] = { "any value": 0, 123: 456, null: -1 }
Палю лайвхак, никому не рассказывай:
>$PlayButton.pressed.connect(get_tree().start_the_game)
>$PlayButton.disabled = false
>С коннектом любой дурак может.
Да не дура я! Сам дурак!
>В плане физона для npc машин оставляю то что есть.
Если игрок столкнётся с ними, они должны иметь достаточно точные коллизии. У тебя, как понимаю, коллизии выходят за пределы визуальной модели, поэтому игрок может случайно зацепить встречный автомобиль за невидимый выступ. Это раздражает игрока, когда он цепляет что-то невидимое, что по логике цеплять не должен, особенно когда игра наказывает за это (даже если неявно).
Если игрок не сталкивается, а машин NPC много, то физику им можно вообще отключать и вести их по заранее известным кривым (Безье - Path3D) дороги, как это делали в разных 3D GTA (это легко наблюдать прямо в игре: машины NPC иногда глючат, проходя сквозь асфальт или двигаясь боком, никакая подвеска у них не работает). Но пока что об этой оптимизации не думай - запаса производительности движка хватит на приблизительно сотню простых VehicleBody3D. Просто предупреждаю о подводных камнях и типичных решениях, потому что кроме физики тебе нужно ещё и графику рендерить, ресурсы подгружать и т.д., рано или поздно столкнёшься с необходимостью резать фичи оптимизацией.
Ещё узкое место движка на данный момент - спавн новых CollisionShape3D. Он происходит в основном потоке и выделить в отдельный поток нельзя (небезопасно). Из-за этого узкого места нужно регулировать (ставить в очередь), сколько шейпов ты спавнишь за один кадр (иначе блокируется главный поток -> игра заикается). Когда-нибудь эту проблему решат, но она на гитхабе несколько лет висит... Опять же, пока что не парься об этом, просто это одно из главных узких мест в процедурной генерации сцены на Godot.
>иметь плоскую текстуру, делающую вид будто на ней есть объемные бордюры и ямы. Яма может быть пятном на карте, у которой прописана смена гравитации чтобы подвеску вжимало, а бордюр так же, но в другую сторону.
По моему опыту, легче использовать возможности физического движка, чем изобретать такие хитрые иллюзии. Ты же всё равно используешь VehicleBody3D, у которого всё что нужно симулируется, так зачем иллюзии?
>мне проще использовать циллиндр
Ясно-понятно, делай как хочешь...
>Если нужен переворот на крышу на максимальной скорости при вывороте руля, то подгонять десятки параметров тела под этот случай можно бесконечно.
Ээээм, вообще-то, у всех новичков проблема ИЗБЕЖАТЬ переворота на крышу при малейшем повороте руля на высокой скорости движения (больше 100 км/ч). VehicleBody3D достаточно стабилен на низкой скорости, но на высокой стремится перевернуться - кто-то говорит, что это реалистично (смотрел много видео про разбор условно-реалистичной физики машин в GTA IV), но в играх игроки привыкли к другому, и приходится делать "quality of life" фичи, чтоб машина не переворачивалась. В реальности, вроде бы, существуют специальные механизмы против переворота на скорости, но в стандартном VehicleBody3D этих механизмов нет (как и в старых машинах).
Вообще, тема физики машин в играх очень интересная, например, создатели одного автомобильного симулятора столкнулись с какой-то проблемой и пофиксили её, думая, что это баг их симуляции - но оказалось, что это не баг, а так и должно быть в реальности, и автомобильные производители используют какое-то решение, похожее на их "багфикс" симуляции. Во как бывает.
>стать специалистом по RigidBody3D
Если планируешь и дальше делать 3D игры, хорошее понимание RigidBody3D пригодится. Даже если забросишь Godot, 3D физика твёрдых тел (rigid body) везде плюс-минус похоже работает (отличия в стабильности, точности, скорости, багах и т.п.). Хотя, конечно, далеко не всем 3D играм нужна физика.
>пытается достучаться до местных чтобы направили
Прикольно. Планируешь развилки с тупиками, чтоб игрок мог реально заблудиться?
У тебя что, цилиндры поперек по дну? Там же клиренса нет, у тебя что, дорога идеальная без камушков и ям?
>reviewed early in the 4.4 release cycle
В свою документацию можно эмодзи добавлять.
На Windows 10: WinKey + ./ю или WinKey + ;/ж
Теперь точно могу модный 💩код писать. 👌👴
>цилиндры поперек по дну? Там же клиренса нет
Без паники! У него всё в полном порядке:
>В идеале нужна даже не сфера, а эллипсоид
>Когда коллизия ящик, то сначала все очень удобно
>машина начинает вращаться вокруг своей оси
>Вчера смог исправить все проблемы с физоном
>Сделал коллизию авто из трех циллиндров
>для машин мне проще использовать циллиндр
>лично у меня в сценах все работает прекрасно без багов
У пингвинов вот тоже клиренса нет, а они быстро ездят.
Есть три базовых дурака: нейроёб, ассеточмоня и ецсшиз.
Какой из них не ты?
Сам Тодд Говард одобряет пришивание поезда вместо головы. Там чем я хуже? У меня машины неписей скрещены с пингвинами. Так сказать, коллизия червь-пидор, колизия пингвин. Машина просто катается на брюхе и слегка покачивается при поворотах на разницу в высоте между продольным и поперечными циллиндрами (анало-говнетная подвес-очка). Из пингвина можно так же сделать поезд или морское судно.
Отдельно буду делать модель машину без костылей для главного героя. Прям по докам попробую, если еще один гениальный костыль не придумаю. Шейп придется составлять из нескольких, и пока нет определенности в конечном виде. То ли кусок мыла из капсул получится, то ли стопка дров из циллиндров. Долго буду делать.
Система частиц - огонь!
Это как это ты такую красоту намутил, не подскажешь анонче?
Моя ставка: партикли с квад мешами-биллбордами, с кривой скалирования и цвета. Аналогично для дыма.
Годетта: Artbreeder + спрайт Годетты + скриншот огня + короткое описание + подправил косяки вручную.
Godot 3D: кучка CSG шейпов; глаза: дырки с чёрной точкой на дне, такое часто юзают в аниме моделях.
Огонь:
1. Quad меш. Поставил галочки на "unshaded", "цвет вершин как альбедо" и "билборд для партиклов + keep scale" в StandardMaterial3D, конвертировал его в шейдер. В шейдере удалил всё лишнее (дало больше FPS), оставив только преобразования матриц для билборда и альбедо из вершин и из текстуры, добавил простейшую формулу для создания полупрозрачного круга (length(UV - vec2(0.5, 0.5));), чтобы выглядело гладко по краям, без острых углов. В альбедо поставил NoiseTexture2D с каким-то из шумов, чтобы разнообразить спрайты, плюс добавил необычный градиент для имитации чего-то вроде "волн" в огне (прозрачно > темно > прозрачно > светло и т.д.), он ложится на шум и создаёт узор. Перебрал много вариантов, тут по вкусу выбирать нужно - можно сделать гладкий поток, можно сделать завихрения, лабиринты какие-то, узоры, контуры. Это основа, в ней вся красота. Самое интересное начало получаться только когда в градиент текстуры шума добавил прозрачные точки, чтобы шум сделал из круга неровную кляксу. Градиент лучше оставить чёрно-белым, но можно добавить какой-либо оттенок, общий для всех частиц. Я хотел сделать ещё реалистичнее оттенки, но устал возиться.
2. GPU партиклы. Тут пришлось сильно повозиться, но только потому что параметры разбросаны как-то не интуитивно и я наугад их подбирал. Основное: начальный вектор скорости с разбросом (нужно, чтобы частицы летели и быстро, и медленно) и рандомный поворот при спавне (чтобы не выглядело как равномерная сетка, ведь спрайт всего один на всё), гравитация строго вверх (горячий газ взлетает), масштаб (расширяется: 0.5 > 10), градиент цвета (белый > жёлтый > оранжевый полупрозрачный > почти чёрный прозрачный, чтобы плавно исчезало), градиент эмиссии (в самом начале ярче светится, чем под конец). Дальше Sub Emitter - он почему-то должен иметь минимум в 2 раза больше частиц, чтобы спамить без перерывов. Это копия первой ноды, с тем же мешем и текстурой, но со своими настройками: нулевая скорость спавна, только взлёт вверх, увеличение масштаба ещё больше (10 > 30), градиент цвета от полупрозрачно оранжевого к чёрному прозрачному. Субчастицы эти спавнятся по истечению жизни предыдущих частиц, поэтому-то они должны лететь с разной скоростью (иначе весь дым будет в одной точке, а не облаком). Пробовал разобраться с коллизиями частиц, но что-то не получилось. Пробовал рандомные вариации оттенков (hue), но выключил - градиент точнее/удобнее регулирует переходы цвета. Ещё поставил Draw Order = View Depth, но это больше актуально если спрайты непрозрачные.
Есть один странный косяк у этой системы: при определённых положениях камеры порядок отображения между главными частицами и второстепенными резко переключается, из-за чего яркий жёлтый центр проступает через чёрный дым, который всё ещё на экране и должен его собой перекрывать. Draw Order с этим не помогает, что с этим делать - непонятно. Depth Draw тоже пробовал переключать, это не то. Впрочем, мне пока и так сойдёт.
Сегодня я узнал, что делать спецэффекты без референсов - всё равно что пытаться рисовать людей по памяти без знаний анатомии: получается какая-то нелепая кривота и я это интуитивно чувствую, но умом понять проблему не могу...
Захотел после этого анонса сделать следующую браузерку на 4-ке.
Пустая сцена террейн+моделька. В godot3 архив выходит 7Мб, в godot4 20Мб. Если без террейна, допустим сделаю террейн из кубиков, godot3 6Мб, godot4 12-14Мб.
Сам неупакованный wasm движка 20Мб против 60Мб.
В общем что-то опять сомнения по целесообразности вообще переползать на 4 в вебе.
ЕБАТЬ ВРОТ А ЧЕ НА ГОДОТЕ ТАК МОЖНО ЧТО ЛИ?
Или, альтерантивно, хочу поменять контрол+движение. Хочу 0.01 юнит вместо 0.001 как сейчас.
И еще вопрос про скалирование в редакторе. Неужели нельзя scale snap привязать к юнитам вместо процентов?
>ТАК МОЖНО ЧТО ЛИ?
Там вся игра в одной комнате происходит, лол. Все ресурсы загружаешь в RAM/VRAM и не паришься. Ландшафт за окном вообще может быть плоским.
>Шифт+движение двигает его по 0.1 юниту
По-моему, шифт снижает шаг привязки до 1/10 от установленного тобой значения без шифта. Но я привязкой с шифтом никогда не пользовался.
>контрол+движение. Хочу 0.01 юнит
Что ты имеешь в виду? На Ctrl вроде бы зум.
>scale snap привязать к юнитам
Как ты себе это представляешь? Масштаб объектов вычисляется в процентах от обычного размера, например, Vector3(0.25, 1.0, 2.5): 25% по X, 100% по Y, 250% по Z. Так весь 3D софт работает по-моему. К каким таким юнитам ты хочешь это привязывать?
Но если очень нужно, можешь написать плагин. В документации есть объяснение, а тут есть примеры:
https://godotengine.org/asset-library/asset?filter=snap
>На Ctrl вроде бы зум.
Контрол+перетаскивание со снапом снапит по 0.001.
>Так весь 3D софт работает по-моему. К каким таким юнитам ты хочешь это привязывать?
Не, например в Blockbench не так, и поскольку я все ассеты в нем делаю, хотелось бы сохранить скалирование по юнитам как в нем.
Жаль что по-дефолту такого поведения нет. Посмотрю плагины, спасибо.
Форма прокрастинации, чтобы игру не делать. Бороться так же как с любой прокрастинацией. Допиливаешь ммо-режим в свою кнопку в главном меню?
>wasm движка 20Мб против 60Мб
Вроде бы обещали сфокусироваться на улучшениях производительности и сокращении объёма в 4.4, не?
>сомнения по целесообразности... в вебе
Да зачем эти веб-игры вообще нужны?..
Раньше, во времена Flash, Silverlight, Java апплетов, Unity Player и других подобных, игрок скачивал весь движок один раз и играл на нём во что угодно, игры в основном были простые и нетребовательные.
Потом они убили все эти плагины, объяснив это стремлением к безопасности, но реальные мотивы наверняка были в другом (монополизация вокруг гугловского хрома). Теперь каждая игра, даже самая простая, грузится как грёбанный фейсбук из 00-х.
Но ладно, игра загрузилась и... Браузер пукнул и сдох, потеряв все твои вкладки и просрав кэш, так что всё по-новой открывать и скачивать. А если не сдох, то тормозит как будто там ААА 3D в инди поделке, и это независимо от движка, потому что браузеры - говно.
На площадках типа Яндекс.Игр, где показ рекламы значительно важнее содержимого самих игр, играют только какие-то тупые школьники и старики, у кого компуктера нет и память в телефоне закончилась. Деградация аудитории связана с деградацией игр.
Короче, ящитаю, веб надо вернуть во времена где-то между Web1.0 и Web2.0, когда сайты были чистыми и лёгкими, а все эти примочки ещё не придумали, и ты заходил на сайт по делу, а не ждать закачки недоигр после ожидания закачки нескольких видов рекламы после ожидания закачки модного веб-фреймворка на 50 МБ, который используется для добавления <div>.
И это у меня ещё хорошая скорость, 8 МБ/с вроде бы, а как же люди, что живут в удалённых районах? Как раз деревенщина и есть основная ЦА веб-говна без установки, потому что они не шарят в компуктирах.
Хотите делать Игры - делайте для ПК.
Хотя там в принципе 2 получится в итоге, а не 4 для каждого. Т.е. размер спрайтов, для вверх/вниз одинаковый как и для лево/право.
Хотя стоп, коллижн пишет мол только дочерним для ареа2д, а для анимации его привязать нельзя. Помогите тупому разобраться.
>снапит по 0.001
Разве это снап? 0.001 вроде стандартный минимум изменения векторов в инспекторе. Я не знаю, где он настраивается, но все вектора округляются до 0.001, как минимум при отображении в редакторе.
>Blockbench
Там вообще всё не как у людей, я ниасилил его. В блендере и то проще разобраться, всё как у людей.
>скалирование по юнитам как в нем
Я не понимаю, что ты имеешь в виду. Какие юниты используются для масштаба? Масштаб в единицу - это сколько метров по расстоянию?
Я поискал, там ничего непонятно. Судя по всему, "размер" означает размер в блоках Minecraft. Это не масштабирование, это именно что "размер в блоках".
В Godot похожая настройка есть, например, у CSGBox, там можно изменить размер по каждой оси в метрах.
Короче, тут путаница в понятиях.
Масштаб (scale) - это изменение в процентах.
Размер (size) - в контексте майнкрафта - в кубиках.
>Да зачем эти веб-игры вообще нужны?..
>Хотите делать Игры - делайте для ПК.
Потому что мне сейчас доступны только я.игры как площадка.
>как сделать разный collisionshape в зависимости от анимации?
Создаёшь в новый скрипт. В скрипте делаешь:
1. @export... для спрайта и всех коллизий.
2. Метод animate(анимация) для управления извне.
3. В методе вызываешь play() у спрайта.
4. Одновременно с этим переключаешь disabled:
>for c in collisions: if c != current: c.disabled = true
>current.disabled = false
Скрипт можешь повесить на отдельную Node в сцене игрока, либо на самого игрока/персонажа. В первом случае скрипт игрока должен получить ссылку на этот скрипт, т.к. управление анимацией через него.
Как вариант перейти с animated sprite на animation player и там вкл/выкл соответствующие коллайдеры.
https://youtu.be/8EVHNbgQCBg?si=ATq6han-WUHRktOi&t=926
Сразу предлагаю другой вариант.
У AnimationSprite2D есть сигнал animation_changed.
Создаём скрипт:
extends CollsionShape2D
@export var sprite: AnimationSprite2D
@export var enabling_animation: StringName
func _ready(): sprite.animation_changed.connect(_update)
func _update(): disabled = sprite.animation != enabling_animation
Связываем все коллиженшейпы ссылками на спрайт, вводим им названия анимаций, которые их должны активировать, и теперь всё работает автоматически с управлением анимациями AnimationSprite2D.play().
Я только учусь основам. Но примерно понял. Спасибо. Думал это немного проще делается.
А, ну да, совсем забыл о нём.
>>958270
>Я только учусь основам
Читай вот эти страницы, там всё подробно:
https://docs.godotengine.org/en/stable/tutorials/animation/index.html
Это наиболее мощная система анимации, позволяет анимировать любые свойства любых нод и твой код.
Ну я понемногу мануал курю, вон игру 2д с него сделал. А сейчас решил сделать вместо доджера, что-то другое. Погуглил бесплатные ассеты на itch. Вон понравился песель. Идея простая, песель бегает по лужайке и собираем рандомно появляющиеся кости, счетчик считает количество костей. Для начала вроде будет нормально потренироваться. Тем более в учебном коде есть практически все для такого концепта.
>Как перестать мусолить один и тот же код, бесконечно его улучшая и оптимизируя, и начать добавлять новые вещи?
Нарисуй графическое изображение проекта со всеми отдельными компонентами на разных уровнях. Далее отметь в % прогресс разработки каждой части игры до юзабельного (можно использовать) состояния. Если слишком фокусируешься на одной части графика, то переходи к другой, чтобы % были равномерными.
Главное тут расставить приоритеты и делать то, что важнее для игры в первую очередь. Не следует переключаться на какие-то неважные детали.
>>958256
>Бороться так же как с любой прокрастинацией
Как? Статьи о прокрастинации слишком длинные.
>>958259
>Долго и мучительно менял екс библиотеку
А мог бы игру на ООП делать, нодами и сценами...
> Нарисуй графическое изображение
Попробую....
> А мог бы игру на ООП делать, нодами и сценами...
Или точно так же прокрастинировал бы, и переписывал бы рабочий код, потому что "не продумал архитектуру". Подозреваю тут дело не в подходе...
>песель бегает по лужайке и собираем рандомно появляющиеся кости, счетчик считает количество
Тогда оставь одну круглую коллизию, но уменьши её примерно в два раза. Спрайт собаки смести немного вверх, чтобы коллизия была ближе к ногам. Тогда, по идее, должно быть более интересно визуально (игрок должен непосредственно встать на кость, в не просто задать её, пробегая боком).
>прокрастинировал бы, и переписывал бы рабочий код, потому что "не продумал архитектуру"
Это не прокрастинация, это рефакторинг.
https://ru.wikipedia.org/wiki/Рефакторинг
Все серьёзные дяди в IT этим занимаются.
Как вариант. Можно вообще на голову сместить, чтобы типа съедала, но тогда все равно 2 коллизии нужно
>все равно 2 коллизии нужно
Не. Если хочешь чтобы типа съедала, тогда тут нужна дополнительная анимация собаки, а коллизия может остаться одной вблизи ног.
Такие коллизии вообще нужны для взаимодействия с неподвижными стенами в основном. Поэтому они должны быть простыми и, желательно, круглыми.
Коллизия, точно повторяющаяся спрайт, это обычно зоны попадания пуль или других подобных объектов.
Коллизия для сбора предметов зависит от игры, но, имхо, чаще встречается, что зона сбора предметов даже шире основной коллизии (ног/туловища).
Да. Но обновление навмеша может быть дорогим, смотря как его сконфигурируешь. Если он строится по статик коллайдерам, а они довольно простые, то терпимо. Как делить - хз, не делил.
Это про тройку, в четверке слышал навмеш сильно прокачали.
У меня пока появилась другая проблема, заставить проигрывать анимацию при движении по диагонали. На форумах пишут, что таки надо юзать анимейшентри, а это для начала лишняя информация. Либо через elif, но у меня чет оно не получается, где-то я туплю. Поразбираюсь пока с этим...
Я сделал, чисто случайно, но сделал. Оказывается надо было 4 базовые направления через elif, а уже диагонали через if, тогда анимация играется нормально.
А ты возьми тетрадку с карандашом, начерти табличку и пойми как расставить условия.
Например такой вариант: вообще убрать elif, оставить if.
Или: разделить движение и анимации на отдельные блоки условий. Вызывать анимацию если velocity.x != 0
Изначально там только if и было везде. Но тогда анимация не проигрывалась. Гуглил. Народ на зарубежных форумах писал, что надо анимейшентри юзать или елифы. Короче там связано с одновременным нажатием и тем, что пытаются проиграться 2 анимации сразу, поэтому получается только 1 кадр. Ну или я это так понял.
>If up and left are held at the same time, the script will play the left animation and then the topleft animation every frame, which resets the animation.
Зачем для этого что-то гуглить? Просто голову включай. По шагам проходи и понимай, что где проигрывается.
Ты всё неправильно делаешь (неудобно). Лучше будет как-то так:
>@export var speed: float = 100 # чтобы настраивать скорость из инспектора
>@onready var sprite := $AnimatedSprite2D # сохраняем ссылку - так удобнее
>func _process(delta):
> # Получаем Vector2 со всеми четырьмя направлениями, длиной не более 1:
> var input := Input.get_vector("move_left", "move_right", "move_up", "move_down")
> velocity = input x speed x delta # двач съедает звёздочку (x)
> if velocity.is_zero_approx(): sprite.stop() # никуда не идём
> else: # если куда-то идём - анимируем:
> _ # sprite.speed_scale = число x velocity.length() # если будешь делать бег (?)
> _ if velocity.y < 0: sprite.play("up")
> _ elif velocity.y > 0: sprite.play("down")
> _ if velocity.x < 0: sprite.play("left")
> _ elif velocity.x > 0: sprite.play("right")
>воткнуть на весь экран полупрозрачную текстуру с шумом
Зависит от того, какого эффекта ты хочешь добиться...
И как я без гугла должен был догаться почему дальше 1 кадра ничего не работает.
>>958319
У меня анимация идлы есть.
Кстати если оставлять коллижны для разных анимаций я уже догадался как это ещё можно сделать, через . disable = true/false. Можно в отдельную функцию ввести для сокращения кода, но я сделал просто под каждым ифом. Благо в самом движке можно включить отображение в дебагере и видеть, что происходит.
>по статик коллайдерам, а они довольно простые
Чё? Статики могут быть намного сложнее ригидов. Там ведь тримеши.
>>958296
>Можно ли использовать NavigationMesh на больших плоскостях?
Должно быть можно, но я не тестировал. Сложная тема вообще.
>Можно ли делить NavigationMesh на составляющие для оптимизации
Я читал, что можно, но это не для оптимизации, а для составных сцен.
>NavigationMesh гайд
https://docs.godotengine.org/en/stable/tutorials/navigation/index.html
>Как лучше всего сделать передвижение нпс в трёхмерном мире?
Это зависит от:
1. Размеры мира:
- Комнатки?
- Большой город?
- Процедурная бесконечность?
2. Используется ли высота (Y)? НЕ НЕРОВНОСТИ, а пересечения:
- Существуют ли в мире мосты/туннели, пересекающие пути?
- Можно ли прыгать, лазить по стенам, бегать по крышам?
3. Что должны делать NPC?
- находить цели или бесцельно блуждать?
- требуется ли им обходить друг друга?
- ходят ли они толпами или по одиночке?
- могут ли они ходить в неактивных чанках?
4. Как игрок влияет на маршруты? Как NPC должны реагировать?
Общие рекомендации:
- лучше AStar - он проще, чем навмеши.
- лучше упростить мир до 2D, если возможно.
- в большом мире сделать навигацию по чанкам.
- обход NPC друг друга - жопа, оставь надежду.
- в стратегиях управляй большими группами.
- лучше делой ЖРПГ с NPC-статистами))))
>3. Что должны делать NPC?
Забыл ещё: как двигаются NPC?
- по клеточкам как фигурки в шахматах?
- идут строго по прямой, разворачиваясь на месте?
- едут на машине с каким-то радиусом разворота?
- летят на ракете в космосе?
Вопросов куча, ответить нужно на всё - для себя.
>И как я без гугла должен был догаться почему дальше 1 кадра ничего не работает.
Пройтись по шагам.
var cond = 4
var x = 0
if cond > 0:
_x = 1
if cond > 2:
_x = 2
Понятно же что в такой ситуации x перезапишется внутри этого же кадра.
1. Город/Совковый ПГТ
2. В мире мосты/туннели, пересекающие пути. Ползание по стенам не планировал, но интересно как это работает.
3. Некоторые НПС просто блуждают, другие двигаются по маршруту. Из обоих типов переключение на третье состояние - преследование с последующей атакой. (через стейт машину могу сделать)
4. Маленькие НПС обходят игрока, а большие толкают. Не знаю как работать с навмешем, кроме примитивного преследования каких-то целей, когда сравниваю положение НПС и нужной точки.
>>958325
Двигаются НПС как физические объекты, к сетке не привязаны.
У меня получается делать отдельных примитивных болванчиков, которые в случайный промежуток времени выбирают случайную точку и идут к ней, а также могу делать преследование игрока, но не знаю как они должны избегать друг друга, чтобы не сталкивались во время передвижения. Документацию давно читал, вроде ничего не было про это. Надо будет снова перепрочитать.
Алсо, может есть инфа про то как в скайриме работал ии противников/НПС? Там ведь не вручную расставляли сетку перемещения и вряд-ли навигационный меш был на всю карту один здоровый.
Нет, я не делаю скайрим 2, просто у меня карта большая, это обусловлено особенностями геймплея, а не размерами ради размера, шоб как в трипл эй
Спасибо
>Чё? Статики могут быть намного сложнее ригидов. Там ведь тримеши.
У навмеша есть опция генерации меша по, собственно, MeshInstance. Вот он был самый медленный, потому что модельки как правило сложнее чем их коллизии. ЕМНИП он стоял по дефолту.
>посёлок городского типа
Если мелкий - возможно, уместится в одну сцену. Главное чтоб LODы работали. Ещё можно настроить HLOD для объединения дальних объектов в цельный объект-заглушку. Если город большой, придётся резать на чанки и уже для чанков делать HLOD, в том числе для навигации NPC. Также есть вариант разделить город не на чанки, а на районы, например, в GTA 3 по идее всего 3 вытянутых района, разделённых мостами, между которыми есть загрузочный экран (на современном ПК экран пролетает за долю секунды, но в прошлом он имел смысл).
>В мире мосты/туннели
Кстати, вспомнилось что-то: в GTA IV машины, едущие по мосту, пугаются проезжающего трамвая и пытаются его объехать по другой полосе, потому что у них навигация как-то странно в 2D запечена и для них проезжающий под мостом трамвай выглядит внезапным препятствием. Очевидно, что навигация в игре оптимизирована в 2D, игнорируя высоту, и в большинстве случаев этого хватает - кроме таких вот мостов. Но в GTA V они это как-то пофиксили.
>Маленькие НПС обходят игрока, а большие толкают
ИМХО, это уже не задача навмеша/а-стара, т.к. поведение в непосредственной близости игрока. Если персонаж приближается к игроку, у него срабатывает логика обхода/толкания. Вопрос в том, должны ли они делать то же самое для всех персонажей в поле видимости игрока или только для игрока. Персонажи вдалеке от игрока могут вообще не использовать физику, если их нужно много... CharacterBody3D вообще сильно жрёт производительность, Area3D тоже не слишком быстра, самое быстрое - это считать квадрат расстояния или вхождение точки в Rect2, но это если тебе нужны прям сотни NPC на относительно слабом ЦПУ. Оптимизации в любом случае понадобятся...
>как физические объекты, к сетке не привязаны
Кстати, узнал где-то такую фичу: навигация может быть привязана к графу точек (waypoint называются), а NPC идут или едут по физике (когда она доступна), стараясь приблизительно достичь заданной точки. Т.к. доходить прямо до точки им не обязательно (допускается погрешность), в целом движение не выглядит привязанным к сетке. Точки могут быть выстроены по-разному, не обязательно сеткой.
>чтобы не сталкивались во время передвижения. Документацию давно читал, вроде ничего не было
Систему навигации сильно переделали в 4.x. Вроде бы вот тут объясняется:
https://docs.godotengine.org/en/stable/tutorials/navigation/navigation_using_navigationobstacles.html
Если использовать AStar на вейпойнтах, то точки графа можно временно отключать:
https://docs.godotengine.org/en/stable/classes/class_astar3d.html#class-astar3d-method-set-point-disabled
>как в скайриме работал ии противников/НПС?
Не знаю, но быстрый поиск показал, что там есть навмеши на кусках карты. Но юзабельных дорог там немного, и возможно, что NPC выбирают дороги через систему вейпойнтов, а на открытой местности используют навмеш. Роль навмеша - избежать столкновения с какими-нибудь рандомными деревьями или бочками, а роль вейпойнтов - построить путь до населённого пункта по имеющимся дорогам с развилками. Но, возможно, что там что-то другое.
>Там ведь не вручную расставляли сетку перемещения
Если не ошибаюсь, то как минимум в старых GTA (3/VC/SA) пешеходы ходят по сети точек, расположенных на тротуарах. В игре это хорошо заметно, когда NPC, убегающий от игрока или догоняющий игрока, предпочтёт бежать по тротуару вместо того, чтобы бежать по проезжей части или траве (и это, имхо, реалистично до некоторой степени). Автомобили тоже следуют точкам, но на проезжей части - можешь представить это как игру Pacman, где вместо пакмана - машина NPC, а точки невидимые. Все эти пути можно как-то менять в файлах игры...
В целом, система вейпойнтов не так сложна для настройки, потому что вейпойнты предполагается ставить на большом друг от друга расстоянии - их не нужно спамить плотно, это может быть сильно разреженная сеть.
>просто у меня карта большая
Запаришься с чанковой системой и подгрузкой/выгрузкой... А что уже есть, если не секрет?
>обусловлено особенностями геймплея
Геймплей ближе к РПГ про средневековье или к ГТА про современный город? Просто интересно, почему тебя интересует именно Скайрим - РПГ с редкими лошадьми, если у тебя современный город с автомобилями...
>>958330
>модельки как правило сложнее чем их коллизии
Для ландшафта имеет смысл тримеш (ConcavePolygonShape3D) использовать, чтобы он повторял визуальный меш, если нет возможности использовать HeightMapShape3D (у неё свои нюансы). Для дорог с частыми ямами, насыпями и бордюрами тоже тримеш лучше форму повторит, чем куча простых шейпов. Мне кажется, не стоит экономить на шейпах проходимой поверхности, чтобы ноги персонажей и колёса машин не проваливались "в текстуры" и не висели в воздухе. Экономить можно только на объектах, к которым персонаж подходит, например, статуя, стена, отвесная часть скалы - к ним нет никаких вопросов, если игрок не может подойти вплотную к чисто визуальной впадине.
Это работает
draw_road_one(["road_straight", "road_straight", "road_straight"])
func draw_road_one(paths: Array):
var y = 0
var z = 0
var path = load("res://scenes/%s.tscn" % paths[0]).instantiate()
y -= 1
z += 100
get_parent().add_child.call_deferred(path)
path.position = Vector3(0, y, z)
pass
Это не работает
draw_road_many(["road_straight", "road_straight", "road_straight"])
func draw_road_many(paths: Array):
var y = 0
var z = 0
for i in paths:
var path = load("res://scenes/%s.tscn" % i).instantiate()
y -= 1
z += 100
get_parent().add_child.call_deferred(path)
path.position = Vector3(0, y, z)
pass
Несколько раз переписывал, но не могу уловить опечатку в коде.
Запусти отладчик и посмотри в remote какая реальная структура, сколько добавилось и какие у них координаты.
нужно сделать свой класс из "кубик + новое свойство" и инстанцировать экземпляры нового класса.
Может я в коде ошибся, вот что я накалякал и результат: все кубы ебашат одновременно
Но тогда я должен id устанавливать снаружи MyButton, а я хочу внутри
Наверное, надо писать texture = textureRes.duplicate()
Правда я вообще не знаю зачем там ресурс понадобился.
>Однопоточный веб экспорт
>Проигрыватель сэмплов, для веб аудио без заиканий.
Храни боже Адама за то что он решил заняться вебом. Похуй что бета, переползаю на четверку. Правда сначала нужно потестить, но не думаю что чето критичное будет.
Я тут задумался, а есть ли инструменты для
> Нарисуй графическое изображение проекта
Я конечно понимаю, что всё можно текстом описать и карандашом нарисовать, но нет ли каких-нибудь удобных штук для составления диздока?
>текстом описать и карандашом нарисовать
https://excalidraw.com/ - редактор для эффективных менеджеров, хорошо работает даже на телефоне.
>удобных штук для составления диздока
https://obsidian.md/ - пишешь txt-заметки, а он тебе [[ссылки]] и граф (заметки - узлы, ссылки - рёбра).
Специализированного софта для проджект-менеджмента много, но соло инди это всё обычно не нужно.
>>958420
Жиза. Моя прокрастинация сейчас - запилить себе плагин на скалинрование по юнитам вместо процентов >>958248
Основа уже работает, довожу до ума.
>плагин на скалинрование по юнитам вместо процентов
А что конкретно тебе нужно масштабировать?
Если ты масштабируешь объект (например, простой кубик) размером 1 на 1 на 1 метр (Vector3.ONE), то любое число в scale будет идентично размеру в метрах:
>scale = size
Если ты масштабируешь объект размером X на Y на Z метр, то формула такая:
>scale = Vector3.ONE / initial_size × size
Как понимаешь, если initial_size == Vector3.ONE, то получаем предыдущее выражение.
У Mesh есть get_aabb(), возвращает минимальный AABB, в который вписывается меш, но я сомневаюсь, что это надёжно для определения "размера в метрах" для общего случая.
Вроде бы в плагине можно сделать ручки управления как у CSGBox3D:
https://docs.godotengine.org/en/stable/tutorials/plugins/editor/3d_gizmos.html
И тогда можно будет наращивать/убирать размер с каждой из трёх сторон по шагам.
Но зачем тебе это нужно для мешей - непонятно...
CollisionShape3D нельзя масштабировать неравномерно - баги, изменяй Shape3D.
CollisionObject3D вообще никак нельзя масштабировать - баги, изменяй потомков.
Остальные Node3D вроде не нуждаются масштабировании...
Мне нужен удобный гизмо или хотя бы хоткеи, чтобы не вбивать значения в поля scale руками. И чтобы этот гизмо/хоткей снапался по 1 юниту, без этих scale.x=11.424, которые в итоге получаются от скалирования дефолтным процентным гизмо.
>снапался по 1 юниту
Ещё раз: зачем тебе это в редакторе сцен Godot? Я так и не понял этого. Как я это понимаю:
1. Хочешь накидать прототип по-быстрому -> юзай CSGBox (сцену можно экспортировать в GLTF).
2. Хочешь делать воксельную сцену прямо в Godot -> https://github.com/Zylann/godot_voxel
3. Хочешь масштабировать импортированные модели с привязкой по кубикам -> но зачем???
Возможно, у тебя http://ru.wikipedia.org/wiki/Проблема_XY ?
Нет, у меня не проблема XY, я строю блоковые уровни, элементы в которых должны быть расположены по сетке. А переходить на воксели - это ты из пушки по воробьям. Более-менее мою проблему решают гридмапы, но большой гридмап сажает производительность плюс имеет другие ограничения, которые все равно приходится закрывать обычными spatial сценами.
И конечно мою проблему решает пойти в свойства объекта и вручную выставить скейл 2, 3, 4 ... 14, но я заебался уже так делать, хочу оптимизировать процесс.
Текстур не планируется. С удачно подобранными сплошными цветами выглядит ок, кстати.
Приведу пример проблемы. У меня есть пол. В нем - дыра, которую я хочу заделать блоком другого типа. Я знаю что размер этой дыры - целое_число на целое_число, конкретное число не знаю. Я беру блок 1х1, ставлю его в центр и начинаю вбивать значения "на глаз" в его scale свойства, чтобы растянуть его на дыру. 18 - слишком много. 11 - слишком мало. 13 - слишком мало. 15 - о, подошло, дыра была 15х15.
Гораздо удобней было бы взять scale gizmo и сразу растянуть блок как надо. Но поскольку scale gizmo работает с ебучими процентами, блок обязательно уедет на какое-нибудь 3.498, либо недоедет на 0.25, и это снова руками через свойства исправлять.
Или обратная проблема - у меня блок 8х1, я хочу уменьшить его длинную сторону. Но поскольку он уменьшается процентами, то единственное целое число, через которое я пройду - 4. А мне нужно было, например, 6.
>ПРОКРАСТИНАЦИЯ
Мне бы такую прокрастинацию.
Добавь над машинками линию жизни. Посчитай сколько жизни они теряют от ударов.
Расстреливай их из установленным на твоей машине пистолетом, пулеметом, дробовиком, ракетницей. Плюс перки как в кармагедоне, тяжелый вес чтобы при ударе отлетали, или пружинка чтобы в зависимости от близости их с большей силой торпедировало в обратную от тебя сторону как из пращи.
Лучше бы подумал как мне решить проблему малой кровью, пока я тут плагин допиливаю.
CSG Polygon положенный на бок. Позволяет мышкой перетаскивать вершины снэпом по сетке.
CSG медленные. В итоге мало чем лучше тормозных гридмапов.
Во-первых, не медленные. Медленные только рассчеты комбинирования, которых тут нет.
Во-вторых, элементарно конвертируются после того как закончишь прототипирование.
Хотя похоже ты просто разжигаешь.
Я делаю что мне нужно, и параллельно с тобой беседу веду. И я сделаю что мне нужно. Чилл.
> или хотя бы хоткеи, чтобы
Запили аддон с хоткеями, которые тебе нужны. Там несложно.
Фил фри ту предлагайте арт.
Так не работает:
>draw_road_many(["road_straight", "road_straight", "road_straight"])
>func draw_road_many(paths: Array):
>var y = 0
>var z = 0
>for i in paths:
>var path = load("res://scenes/%s.tscn" % i).instantiate()
>y -= 1
>z += 100
>get_parent().add_child.call_deferred(path)
>path.position = Vector3(0, y, z)
>pass
> технически невозможно добавлять инстансы одной сцены к текущей сцене
А если await frame?
>>958495
Перепаковывай видосы обс. Фаерфоксогоспода не смогут увидеть непожатый мкв.
>Фаерфоксогоспода не смогут увидеть непожатый мкв
А, точно. То самый случай, когда works on my machine. Запакую в mp4 x264.
> Запакую в mp4 x264.
Не ну прям с перепаковкой ебаться не надо, если у тебя OBS там в меню Файл - перепаковка (которая раньше демультиплексированием называлась).
Звучит как то, что ты бездумно копипастишь строки кода откуда то, не понимая последовательности событий и что такое deferred
В функции пробовал 3 способа добавлять чайлд ноду, и на момент когда я постил не закомментирован был get_parent().add_child.call_deferred(path). В актуальной версии используется просто get_child(path).
Поясните такую вещь, на каком языке лучше пилить штуки в годоте, чтобы потом можно было чиркануть в резюме, что ты молодец?
Или дроч шарпа в годоте никак не повлияет на конечный навык говнокодинга?
Не привязывайся к инструментам. Выбери движок более подходящий для резюме, если для тебя это важно. Годот с гдскриптом хорош для многих вещей но не для резюме. Если ты новичок то шарп очень не рекомендуется.
>Если ты новичок то шарп очень не рекомендуется.
Если ты новичок то шарп в годоте очень не рекомендуется
самофикс
>Годот с гдскриптом хорош для многих вещей но не для резюме.
Если сможешь начать, сделать и закончить какой-то достаточно сложный проект, особенно если он будет популярным, тогда это даёт тебе жирный плюс вне зависимости от выбранных инструментов.
Вот только зачем тебе идти рабом к дяде, если ты и самостоятельно можешь начать, сделать и закончить достаточно сложный популярный проект? Ты только талант свой закопаешь, уйдя в рабство к дяде.
>Если сможешь
https://www.youtube.com/watch?v=jQ_Te-uaPRw
Если я продолжаю печатать слово, то варианты из автокомлита пропадают. Я начинают писать имя переменной, она появляется на первой строчке и если я после этого ещё символ напечатаю она пропадает. Самое отвратное, что если удалить символ то автокомплит другой почему-то предлагается и переменная не вылазит снова и приходится всё слово стирать.
Проверил автокомлит отдельно, работает нормально. В ридере и эдиторе годота, тоже всё нормально работает. Проблема только между нвимом и годотом.
Отписываюсь, может потом кому-нибудь поможет.
Глючит из-за этой строки в конфиге нвима:
completion = { completeopt = 'menu,menuone,noinsert' }
Пока разницы не вижу, что с ней что без неё.
С камерой зафиксированной на персонаже все работает как надо, тк очевидно персонаж всегда в одной точке по центру. А вот если камеру отдалить/отключить/зафиксировать на чём-то другом – то приходится елозить мышкой по всему столу, как на втором видосе.
Щас поворот делается через обычный лук_ат
Железо в норме, тянет всякие халфлайфы2, а в другое я не играю.
https://www.google.com/url?sa=t&source=web&rct=j&opi=89978449&url=https://m.youtube.com/watch%3Fv%3DjzbgH4AMtI8&ved=2ahUKEwimqo2U3v6HAxWiJhAIHRxSDVAQwqsBegQIDxAG&usg=AOvVaw0yASfV3tq5Aej8cVXYDZsW
>>970671 (OP)
>>970671 (OP)
Анон, можно как-нибудь включить сглаживание в редакторе, а то немного раздражает эта "пила" у линий?
Нашел в настройках, включил FXMAA, большая часть "лесенок" исчезла, но края квадратов отрендеренных материалом все равно в лесенках.
Возвращаться в UE не хочется
В настройках проекта вкладка Сглаживание, выкручиваешь хоть MSAA хоть рендер в x2, хоть FSR2
Одновременно настройка и для игры и для редактора
Я если честно вообще не понимаю нахрена разрабы годота создали еще один динамически типизированный язык. Ну поиграли с этим говном в 90-е, обосрались и хватит. Разработка на динамически типизированных языках уже везде мертва как концепт. Для жс придумали тайпскрипт, в пистон добавили и юзают типы, в пхп тоже есть типы.
>>973473 (OP)
>>973473 (OP)
Sup двач
Знаю что не по теме, но как насчёт захейтить игру Юлика Хрюлика. Хрюлик возомнил себя мамкиным Кодзимой и решил засрать наш любимый Стим и оскорбил священный Godot. Мало того что игра говнище, так она ещё и стоит 3,5$.
https://store.steampowered.com/app/2883280/Dog_Brew/
Анончик, а подскажи как работает анимация поворота тянки на месте?
С остальными обычными анимациями у меня проблем нет, такими как ходьба вперёд или бег, даже переходы между ними получаются легко, даже комбинации разных анимаций, типа действия руками и при этом переход анимации ног из одной в другую. В этих случаях просто оперируешь готовыми анимациями и настраиваешь их всячески.
А вот с поворотом на месте у меня проблемы, как заставить поворачиваться на нужный градус и ещё чтобы моделька ноги переставляла правильно, в сторону поворота. И только после прохождения определённого градуса, ну то есть естественно, как в жизни, когда для легкого поворота достаточно корпуса, а если продолжить поворот, то уже переставляются ноги. Нужно риальне какое-то колдунство или это я даун усложняю?
вкатун-нуб-мимокрок
Гайзы, есть тут кто-то кто на c# годотит? Как можно сделать hot reload как с гд скриптом, чтобы не перезагружать каждый раз окно?
Нашел нужные мне туторы по гототу, почему будет ошибкой поменять юнити на годот?
Какой де факто дефолт язык в годоте? GDscript?
>Нашел нужные мне туторы по гототу, почему будет ошибкой поменять юнити на годот?
Если спрашиваешь тут, то, наверное, не надо. Просто попробуй exeшник 100 мегабайт весит.
>Какой де факто дефолт язык в годоте? GDscript?
Дефолт GDscript. C# второй официальный
Делить, конечно, если ты собрался весь уровень одним мешем сделать