Шапка: https://hipolink.me/godothread
Предыдущий: >>901894 (OP)
Архивный: >>895906 (OP)
Запустил три годота, выбираю какой проект проработать сегодня хочу
Делаю ИИ для своией топ-даун игры. Думаю какие интересные поведения добавить можно.
>ИИ для топ-даун игры
>интересные поведения добавить
GOAP? Utility AI? Какой-то свой подход?
Меня как раз ИИ интересует. Хочу сделать что-то модульное, чтобы процедурно генерировать. Чтоб комбинации проявляли эмерджентность.
Пробовал делать локации, но без ИИ мотивации продолжать нет никакой - мёртвый пустой мир не привлекает, а тупые мобы мне не подходят.
Если компьютер заработает, на днях планирую очередной прототип делать, конкретно про ИИ.
Пока разбираюсь с обычными стейт машинами. Например есть идея убегающего врага, который несет с собой кучу лута. Уже лучше чем одни нападающие болванчики.
>стейт машина
Там проблема в том, что ты должен явным образом прописать отношения между состояниями. Сложнее поведение - больше состояний и связей между ними.
С другой стороны, граф состояний можно просто нарисовать перед тем, как писать какой-либо код.
>идея убегающего врага
>несет с собой кучу лута
Видел подобное в нескольких играх.
>лучше чем одни нападающие болванчики
Тут большая разница в том, что нападающие обычно агрессоры и игрок защищается (если забыть о том, что он сам лезет в толпу гриндить опыт и лут), а если монстр убегает, то это уже игрок агрессор и негодяй, обижающий безобидных существ. Такое плохо будет выглядеть в игре про героя-спасителя, т.к. у игрока оптимальная стратегия - нападать на убегающих, а игроки стремятся оптимизировать свой геймплей.
Так что не всякое разнообразие лучше.
>должен явным образом прописать отношения между состояниями
Нет, не должен. Зачем? Просто стейты-тактики и менеджер. Менеджер определяет, какую тактику использовать вотпрямщас, но сами по себе они автономны, переключиться от одной к другой можно в любой момент.
И да, это НЕ стейты физики+анимации типа "идти", "стоять", "пердеть". Скорее это простые паттерны поведения, вроде "искать укрытие", "заходить сбоку", "прикрывать братюнь огнём", "переть танком". А они уже управляют персонажем, жмут виртуальные кнопки, от которых тушка ходит или стреляет или ещё что.
Ну и да, разные менеджеры могут иметь разную логику смены тактик.
>Просто стейты-тактики и менеджер.
И что? Тебе всё равно это всё вручную печатать.
>An FSM is defined by a list of its states, its initial state, and the inputs that trigger each transition.
Если у тебя просто список состояний, это не FSM.
>"искать укрытие", "заходить сбоку", "прикрывать братюнь огнём", "переть танком".
Как ты будешь определять требуемое состояние?
Из случайной статьи про FSM:
>Конечный автомат можно представить в виде графа, вершины которого являются состояниями, а ребра — переходы между ними. Каждое ребро имеет метку, информирующую о том, когда должен произойти переход. Например, на изображении выше видно, что автомат сменит состояние «wander» на состояние «attack» при условии, что игрок находится рядом.
>Реализация конечного автомата начинается с выявления его состояний и переходов между ними...
Вот для определения состояния следует вместо огромной портянки if сделать что-то вроде этого:
>While behaviors in a utility system are often created individually (and by hand), the interactions and priorities between them are not inherently specified.
Т.е. это не конечный автомат: вместо состояний - поведения, имеющие функцию оценки пользы, и выполняется наиболее полезное поведение.
>на изображении выше
Вот, нашёл эту иллюстрацию. Вот это - FSM. Если ты убираешь рёбра графа, у тебя остаются только состояния, так что это больше не будет FSM. Поэтому, говоря о FSM, мы говорим не только о состояниях, но и о конкретных переходах между ними.
Да, есть деление на детерминированные автоматы и недетерминированные, а есть ещё вероятностные. Но везде указываются конкретные рёбра на графе, а не "ну вот типа менеджер есть, он как-то решает, в какое состояние прыгнуть".
Вот есть, например, решатель Utility AI. Он явно противопоставлен FSM как отдельная архитектура:
>...inject utility AI as a commonly-referred-to architecture alongside finite state machines (FSMs), behavior trees, and planners.
При том что Utility AI, по сути, работает с теми же самыми состояниями, только вместо вручную описанных рёбер - функция оценки полезности и выбор наиболее полезного в данный момент состояния.
Ну, ок. Пусть состояния соревнуются между собой. Каждое даёт свою оценку полезности; у которого она наивысшая, то и будет активным.
> переходы
На мой взгляд, нахер не нужны. Почему по условию "healthpoints are low" не переключаться из любого состояния в "find aid"? Вообще не представляю себе ситуацию, когда бы из одного поведения нельзя было переключиться на любое другое.
Я понимаю анимации, типа когда прыжок переходит в падение, но не в ползание. Но тут что мешает перейти откуда угодно куда угодно? Ладно, добавляем к каждому состоянию таймер fade_in/out, если надо, чтобы моб не мгновенно реагировал на смену обстоятельств. Ну и всё.
Игра про героя-спасителя такое себе. Ограничивающее, избитое, скучное. Быть правильным скучно. Играть правильно - еще скучнее. Вспомните сколько раз вы забивали на правильное прохождение скайрима и выпиливали города? Но игра за такое дает понять что ты портишь негласный договор и наказывает тебя закрытием возможностей. И приходится загружаться. Не делайте игор про игрока-спасителя.
Самый топ, ящитаю, это злодеи против злодеев.
>Игра про героя-спасителя такое себе.Ограничивающее, избитое, скучное.
А мне вот не хватает игр про добряков. Как не заходишь в игру, так прорабатывают ветки каких-нибудь темных братств и прочего криминал скам, а для доброго паладина придумывают контент уровня "убей 10 медведей"
>Вспомните сколько раз вы забивали на правильное прохождение скайрима и выпиливали города?
Ну ноль, ебать. В скайриме весь контент в чистке данжей, проклике диалогов и немного рофла с магии. Чистка городов почти во всех эрпоге - говно без задач. В последний раз таким наверное в фолаче3 школотуном занимался, и то только потому что туда завезли расчленёнку.
>Игра про героя-спасителя такое себе.
Школоивел порвался, лол. Пиздуй лечить детские травмы, раз коупишь через злодейства над комплюктерными болванчиками.
Я бы хотел сделать игру про настоящего злого. Я даже видел запрос на такое однажды. Чтобы играть за дроу в андердарке. Чтобы можно было пытать людей, устраивать набеги на деревни, колдовать всякую темную магию, устраивать разборки домов с выпилом. От себя я бы еще много чего наворотил, всякие эксперименты над телами. Но останавливают правовые последствия. Да и хрен ее выложишь где то. Если только на порнохостингах, да и то до тех пор пока игроки не найдут способы устраивать рейп. Полностью подпольную игру в даркнете с выводом крипты делать если только.
А теперь посмотри на популярность какого-нибудь Евро Трак Симулятора
Чет не взлетит, думаю я. В даркнете у людей другие интересы.
Установи ей grow direction в зависимости от того, куда хочешь расти. А VBox ты уже используешь. Вроде все.
ага оно. только надо было панелконтейнер а не просто панел
>Чтобы можно было пытать людей, устраивать набеги на деревни, колдовать всякую темную магию, устраивать разборки домов с выпилом.
Уже сделали, проверяй.
>Пусть состояния соревнуются между собой. Каждое даёт свою оценку полезности; у которого она наивысшая, то и будет активным.
Это и называют Utility AI или Utility System.
https://en.wikipedia.org/wiki/Utility_system
Кстати, где-то читал, что что-то похожее происходит в головном мозге - соревнование между колонками неокортекса за право активации в данный момент. Победившая колонка подавляет всех проигравших.
>Почему по условию "healthpoints are low" не переключаться из любого состояния в "find aid"?
Потому что тогда граф твоего автомата будет представлять из себя огромный клубок нитей.
Я тут набросал примеры в виде графов...
1. FSM в классическом геймдев понимании: граф из состояний и чётко прописанных переходов.
2. Utility AI: у каждого поведения есть функция оценки полезности, и мы периодически проверяем, какое из поведений в данный момент лучшее. Да, формально здесь нарисована FSM, но суть у неё совсем иная и называть это "просто FSM" нельзя - тебя не поймут.
3. GOAP - честно признаюсь, я без понятия, как это реализовать правильно, так что пример кривой, но всё-таки: есть список действий с предусловиями и последствиями, и есть FSM с тремя состояниями; составление плана происходит через AStar (это уже намного сложнее изобразить, так что... гуглите).
>Ограничивающее
Игры - это всегда ограничения. Песочницы в чистом виде имеют довольно узкую аудиторию - чаще игроки играют либо по правилам игры, либо по правилам модификаций игры, а не по своим выдумкам.
>избитое
Наоборот, слишком много игр про убийства, и даже "добрые" персонажи занимаются геноцидом мобов, борьба со "злом" идёт методами самих "злодеев". Идеальная игра про добро должна заканчиваться тем, что злодей признал свои ошибки и исправился - стал добрым, а такого почти не бывает - герои тупо убивают карикатурного "злодея", не обременяя себя вопросами морали, как какие-то солдаты. Хороший герой должен искать путь, не состоящий на 99% из мясорубки мобов и убийства финального босса.
>скучное
Это уже твоё субъективное стремление к жести.
>Играть правильно - еще скучнее.
Интересный геймплей никак не связан с тем, чем ты в игре занимаешься. Интересный геймплей даёт тебе дозы эндорфинов. Если ты достигатор, стремящийся достичь 999 уровня, не всё ли равно, что ты будешь делать в игре - убивать или заводить друзей? Главное, чтобы действия давали очки опыта, от которых у тебя происходит всплеск гормонов удовольствия.
>выпиливать города скайрима
>игра за такое дает понять что ты портишь негласный договор и наказывает тебя закрытием возможностей.
Ты разве не понимаешь? Игра завязана на квесты, ты получаешь квесты от неигровых персонажей в строго определённых дизайнером уровней местах. Если ты сбрасываешь атомную бомбу на это место, то как ты планируешь потом брать квесты? Или игра должна спамить тебе новых случайных квестодателей? Чаще всего эту проблему решают бессмертием персонажей.
Ты, наверное, сюжет в квестах вообще не читал, и воспринимаешь их только как точки входа в новые активности на карте. Это значит, что жанр РПГ не для тебя, тебе больше подойдут слешеры - там не нужно много читать, зато нужно много рубить мобов.
>злодеи против злодеев
Большинство игр в этой категории, см. выше. Смешно смотреть на "героя", все геройства которого состоят из массовой резни зачастую маленьких и слабых мобов. Начинают путь буквально с истребления малышей, пока не объявится рассерженная огромная самка...
>Ограничивающее
Игры - это всегда ограничения. Песочницы в чистом виде имеют довольно узкую аудиторию - чаще игроки играют либо по правилам игры, либо по правилам модификаций игры, а не по своим выдумкам.
>избитое
Наоборот, слишком много игр про убийства, и даже "добрые" персонажи занимаются геноцидом мобов, борьба со "злом" идёт методами самих "злодеев". Идеальная игра про добро должна заканчиваться тем, что злодей признал свои ошибки и исправился - стал добрым, а такого почти не бывает - герои тупо убивают карикатурного "злодея", не обременяя себя вопросами морали, как какие-то солдаты. Хороший герой должен искать путь, не состоящий на 99% из мясорубки мобов и убийства финального босса.
>скучное
Это уже твоё субъективное стремление к жести.
>Играть правильно - еще скучнее.
Интересный геймплей никак не связан с тем, чем ты в игре занимаешься. Интересный геймплей даёт тебе дозы эндорфинов. Если ты достигатор, стремящийся достичь 999 уровня, не всё ли равно, что ты будешь делать в игре - убивать или заводить друзей? Главное, чтобы действия давали очки опыта, от которых у тебя происходит всплеск гормонов удовольствия.
>выпиливать города скайрима
>игра за такое дает понять что ты портишь негласный договор и наказывает тебя закрытием возможностей.
Ты разве не понимаешь? Игра завязана на квесты, ты получаешь квесты от неигровых персонажей в строго определённых дизайнером уровней местах. Если ты сбрасываешь атомную бомбу на это место, то как ты планируешь потом брать квесты? Или игра должна спамить тебе новых случайных квестодателей? Чаще всего эту проблему решают бессмертием персонажей.
Ты, наверное, сюжет в квестах вообще не читал, и воспринимаешь их только как точки входа в новые активности на карте. Это значит, что жанр РПГ не для тебя, тебе больше подойдут слешеры - там не нужно много читать, зато нужно много рубить мобов.
>злодеи против злодеев
Большинство игр в этой категории, см. выше. Смешно смотреть на "героя", все геройства которого состоят из массовой резни зачастую маленьких и слабых мобов. Начинают путь буквально с истребления малышей, пока не объявится рассерженная огромная самка...
Проверил, фигня какая то топдаун колония
Изучаю тут Obsidian, и мне так понравился Markdown. Насколько сложно будет прикрутить Markdown к игре на Godot? Мне нужно будет выводить информацию, а использовать BB-коды для выделения не хочется.
>>07554
Прежде чем игру делать, нужно диздок написать...
Пытаюсь запилить в своей игре режим "fallback to GLES2". Для этого написал ноду, которая заменяет найденные Particles2D на CPUParticles2D при помощи функции convert_from_particles(source_node). И столкнулся со странным.
Сразу оговорюсь. Если открыть (просто открыть) проект в режиме GLES2, то некоторые шейдеры забудут свои параметры, баг Годота. Поэтому для тестов я запускаю в GLES3, но в конвертилке вырубаю проверку видеодрайвера, и она всё равно конвертит партикли в цпушные. Смотрю дерево в рантайме - да, они цпу.
Но вот я делаю экспорт и запускаю с параметром --video-driver GLES2. И по неизвестной причине некоторые партикли не вижу (а некоторые вижу). Очевидно, я где-то накосячил в скрипте.
И теперь вопрос. Как это отдебагать?
а) Запустить с драйвером GLES2, но чтобы редактор был GLES3 - возможно ли?
б) Посмотреть дерево сцены уже экспортнутого проекта - как?
>тогда граф твоего автомата будет представлять из себя огромный клубок нитей.
Ну и что с того? Они ж ничего не делают всё равно. Чего ты к этим связям-то так привязался?
>>07350
Хотлайн Майами, серия Постал, Мэнхант сразу на ум приходят.
Ну, последствия будут не столько правовые (правоохранителям похеру, если в игре нет призывов к реальному нарушению законодательству), сколько твиттерные. На такую игру набросится вся прогрессивная общественность и будет бесплатно рекламироать. Хотя, конечно, для начала этого процесса всё равно привлечь внимание, не быть нонейм индюком, например.
>>07343
>Быть правильным скучно. Играть правильно - еще скучнее.
За себя говори. А кто-то отыгрывает винтик системы в Контрабанд Полис.
>>07319
>игрок агрессор и негодяй, обижающий безобидных существ.
Кобольды влезли на нашу базу и своровали ценный артефакт. Контрабандист даванул педаль в пол прямо через шлагбаум. Наркокурьер, с которого можно выбить бабос.
Легко придумать объяснение, почему эти существа не такие уж безобидные.
А ещё напомню, что Гордон Фримен давил безобидных беззащитных гусеничек ради 2-3 ХП, удовлетворительного звука и ачивки.
Аноны, можете объяснить в чем разница _process и _ready
Читаю документацию, и делаю по ней штуки и не понимаю почему обе функции ведут себя одинаково, хотя судя по референс описанию не должны, я даже ради эксперимента комментил всю _ready функцию и переносил её содержимое в конец _process, ничего не поменялось и иконка продолжила мигать с секундной периодичностью.
Как я понял _process запускается при каждом тике игры, тогда как _ready когда то к чему оно привязяно появляется на сцене. А значит эта функция должна была один раз вызваться при появлении иконки, которая появилась вместе со всем остальным при запуске сцены, и больше не вызываться.
https://docs.godotengine.org/en/stable/getting_started/step_by_step/signals.html
>Как это отдебагать?
Попробуй это, но сам я не пробовал:
https://docs.godotengine.org/en/3.6/tutorials/scripting/debug/overview_of_debugging_tools.html#deploy-with-remote-debug
>Deploy with Remote Debug
>When exporting and deploying, the resulting executable will attempt to connect to the IP of your computer for debugging.
>Посмотреть дерево сцены уже экспортнутого проекта - как?
Ну, ты всегда можешь просто print...
https://docs.godotengine.org/en/3.6/classes/class_node.html#class-node-method-print-tree
А мне всегда казалось наоборот,
Играешь за добряка, помогаешь людям, эти чуваки потом встречаюстся дальше по сюжету и могут ещё каких квестов подкинуть.
Играешь за злодея, и либо сам выпиливаешь ради выгоды, либо следуя отыгрышу игноришь не свои проблему участие в которых не пахнет богатствами таким образом добровольно обрезая себе контент.
Тот же BG3 которую много кто хвалит за вариативность, я пока только в первом акте, играю за жадную до могущества прагматично злую высшую эльфийку волшебницу школы прорицания. Судя по тому что я слышал, "злой выбор" вырезать рощу друидов, что заставляет отвернуться от тебя целую пачку компаньонов и не дает какой-то иной особой альтернативы помимо одной дроу которую ты не факт что возьмешь.
Единственная известная мне игра где реально хорошо прописано злодейский путь это Tyrrany, и то только потому что там сеттинг победившей империи зла и мы её агент.
Я просто обожаю прагматичных злодеев и хочу видеть больше книг, игр и т.д. с такими на главной роли, и нет не потому что я школоивел, а потому что все известные мне примеры, пиздец волевые и целеустремленные челы, тогда как я сам тот ещё рохля в этом плане.
>Идеальная игра про добро должна заканчиваться тем, что злодей признал свои ошибки и исправился - стал добрым
Это конечно не игра, но для тебя есть идеальное аниме, наруто, очень многие противники либо просто исправляются, либо исправляются и жертвуют собой что бы искупить грехи. Там даже есть один злодей, Орочимару, который "исправился" тем, что перестал быть антагонистом, и то по большей части потому что он получил возможность жить вечно в искусственно созданных телах из клеток Хаширамы.
Да и как ты себе пресдставляешь перевоспитание злых инопланетян для которых убийства и грабеж норма? а именно так и происходит в большинстве фентези сеттингов, белый ну или серый герой сражается против объективно черных сил, которые по самой своей природе злые, нежить, демоны, монсты, всякие варварские зверолюдные рассы, начиная орками и гоблинами и заканчивая гноллами и людоящерами. В старых редакциях днд, было порядочное мировозрение, нейтральное и хаотичское, и группа персонажей была представителями сил порядка, которые ходят в походы в земли хаоса с целью разбогатеть и прославиться.
>_process запускается при каждом тике игры
>_ready срабатывает при создании ноды один раз
Если хочешь подрочить ты в _ready снимаешь штаны и берешь в руку хуй. Дрочишь уже в _process.
Если обратиться к хую до того как он инициализируется - будет ошибка
>эта функция должна была один раз вызваться при появлении иконки
Ты про какую функцию? Про эту?
>func _on_timer_timeout(): visible = not visible
У тебя таймером генерируется сигнал, а эта функция - обработчик сигнала, который вызывается всякий раз, когда генерируется сигнал. В _ready происходит подключение обработчика сигнала к сигналу, после чего обработчик будет вызываться сигналом.
Подключение обработчика сигнала не равно вызову обработчика сигнала. Обработчик сигнала у тебя вызывается только когда Timer генерирует timeout. В момент подключения сигнала к обработчику ничего не происходит, но таймер у тебя на 1 секунду, так что ты разницу просто не замечаешь.
Попробуй в инспекторе Timer изменить Wait Time. Попробуй поставить галочку One Shot - это выключит таймер после первого срабатывания timeout.
Про сигналы можно почитать в целом:
https://en.wikipedia.org/wiki/Signal_programming
Про _ready и _process ты почти правильно понял.
_init - когда объект создаётся.
_tree_entered - когда нода входит в дерево сцены.
_ready - один раз, когда нода впервые вошла в сцену и все её потомки уже готовы к работе (важно!).
_process - каждый визуальный кадр (если у тебя 1000+ кадров в секунду, это будет 1000+ вызовов).
_physics_process - каждый физический тик (число тиков в минуту настраивается в параметрах проекта и влияет на точность работы физического движка).
_input - когда от ОС приходит событие ввода.
и т.д., смотри API Node и Object.
>злых инопланетян для которых убийства и грабеж норма
Показать им, что любовь и доброта это заебись, круто и вообще хайповая тема.
>Попробуй это
Работает, хоть и довольно странно. После первого запуска зацепляется к хттп-серверу, и пока его не остановишь, повторно подключиться не даёт. А остановить можно только запустив хтмл-билд, и тогда под этой кнопкой появится кнопка остановить сервер. Или я просто не знаю, где ещё искать.
Впрочем, работает же.
>всегда можешь просто print
Просто принта не достаточно. Открыть свойства ноды, посмотреть, что с ней не так, глянуть другую и т.д.
В общем, аригато, анонче, пофиксил баг.
Блин ты что сам туда полез? По моему так уже лет 5 не работает. Ничего не могу посоветовать, извини, сам буду издателя искать через годик.
Я пока целюсь на итч+вкплей+ЯИ. Если на этих сервисах моя игра будет кому-то интересна, тогда можно и расширять охват.
Кстати, анончики, подкиньте ещё сервисов, куда можно закинуть.
>издателя
В чем суть? Продаешь им своего игоря и получаешь процент? Я просто не хочу чтобы мою игру, над которой я душевно работал, завалили десятком говнореклам настолько, что игры не видно.
Лол
kongregate если он еще жив
В инди сегменте это значит, что находишь того, кто вываливает твою игру в магазин и обеспечивает какую-никакую рекламу за процент от продаж.
Я вообще хз как там сейчас.
У тебя игра бесплатная скорее всего и соревнуешься ты с другими бесплатными от фирм тупо вливающих миллионы в рекламу и показывающих рекламу.
Хотя конечно какие то игры с вменяемой схемой видел, например Eternal Senia 80000 отзывов.
По идее все живут на том, чтобы задолбать рекламой и добавить опцию отключения, то есть по сути заставить купить игру, плюс манипуляция расходниками, когда ты проиграл а тебе говорят вот купи бутылочку, с ней ты победишь и не потеряешь прогресс.
Да на самом деле ничего особо интересно, просто фиксят баги, улучшают стабильность, иногда доносят фичи, часто в GLES2 добавляют что-то из GLES3, немного улучшают перформанс. Допиливают fixed step interpolation. LTS короче.
Что завезли, если по сути?
Стим - это если игру продавать будешь. А у меня пока не тот масштаб. План пока такой: сначала игру 1.0 лью на бесплатные площадки-помойки, прощупываю аудиторию, может, какую фанбазу изначальную сформирую; потом либо буду пилить игру 2.0 и продавать её за деняки, либо (если 1.0 не зайдёт публике) запущу совсем другой проект гиперказуалку с рекламой для ЯИ.
Не, славься пресвятой Габен и всё такое, но туда, мне кажется, надо идти с бюджетом, пусть даже небольшим.
>>07822
Ну скажем, четвёрка не годится для веба и мобилок, а это так-то огромный и всё ещё довольно просторный рынок.
шарповая четверка как и тройка таки не годится да. хотя в 4.2 есть уже ограниченная поддержка а с обычной версией какая проблемма то?
Будет. Успеют.
>стабильный билд
>с меткой "прототип"
Значение знаешь?
>где найти тестировщиков?
На двач закидывай, очевидно же. На другие форумы. Ты ж не ААА студия, у тебя нет секретов от народа.
бартер тестами с другими индюками
Почему мало? Сколько тебе тестеров вообще нужно?
Не очень понятен твой вопрос. Ну я могу работать qa инженером хотт фулл тайм. Но ты наверное имел в виду что то другое, просто фанатов за бесплатно?
Аноны подскажите пж, хочу сделать редактор уровней супер марио брос, но оказалось что я слишком тупой даже для этого.
Базовая концепция следующая:
1. Пользователь выбирает тайл
2. Пользователь ставит тайл на поле
3. Пользователь нажимает кноку сохранить
4. Тайлмапа конвертится в json (или сразу создается параллельный словарь который после сохраняется как json)
5. При загрузке просто расставляем обжекты по json'у
Тут все логично лаконично и понятно, но вопрос у меня больше по технической составляющей визуала.
Мне очевидно требуется сетка, начало отсчета координат и границы. В этом плане я выбрал пока примерно позицию нулевая позиция х:0 y: 300 16. Пределы соответствующие, слева сверху нули, снизу и справа 300 16. Интро к вопросу долгое но похуй.
То что меня волнует сейчас больше всего - как рисовать сетку? Мне нужна сетка что бы юзер не терялся очевидно. Как то разделять тайлы и прочее. Возможно даже как в оригинальном редакторе godot'a когда рисуешь что-то тайлами там такая небольшая обводка в виде сетки. У меня конечно последние недели времени много времени подумать над этим небыло, но я либо тупой либо задача реально нестандартная.
Какие есть советы?
Вероятно я просто тугодум и не умею гуглить.
Сейчас нагуглил тот факт что вероятность для более менее цельных не процедурных игр на годо алгоритмы чанкирования и левел клитор нужно писать ручками, потому что экраны загрузки харам.
Такой вывод сделал из-за того что годо невероятно прожорлив и 300 на 300 примитивных 2д квадратиков сажают ФПС весьма сильно.
Я все ещё ищу годные гайды по тому как сделать ингейм левел клитор понятным. Сам алгоритм редактора уровней это не так сложно, а вот как сделать так что в нем не запутаться в первую секунду я ума не приложу.
Накидайте идей, мыслей и гайдов на этот счёт. Буду благодарен.
Оу щит, не клитор, а едитор.
Тут возникает вопрос, если у тебя марио игра где в редакторе расставляются по сетке, то зачем потом используются объекты, а не тайлмап?
Вероятно я где то был не точен или я неправильно вопрос понял. У тайлмапа есть плюс в виде оптимизированной работы с большим количеством тайлов и с простотой отрисовки, но есть и минусы в виде меньшего контроля за каждым отдельно взятым тайлом. Если основной граунд можно отрисовать тайлмапой, то знаки вопросиков например (или знаки on и off из super mario maker) уже сделать вроде как нельзя.
Плюс по моим экспериментам большие тайлмапы все равно предательски лагают. Из-за этого я и начал смотреть в сторону чанкирования карт.
>меньшего контроля за каждым отдельно взятым тайлом. Если основной граунд можно отрисовать тайлмапой, то знаки вопросиков
Рисуешь статичные тайлы тайлмапой, а динамические объекты спавнишь по необходимости. Проблемы?
>Плюс по моим экспериментам большие тайлмапы все равно предательски лагают. Из-за этого я и начал смотреть в сторону чанкирования карт.
Ты на 4.x? Там вроде 2D батчинг сломали...
Попробуй увеличить это значение в тайлмапе:
https://docs.godotengine.org/en/stable/classes/class_tilemap.html#class-tilemap-property-cell-quadrant-size
Это должно сделать чанки больше размером, таким образом сократив общее число чанков.
Если не поможет, есть вариант использовать это:
https://docs.godotengine.org/en/stable/tutorials/rendering/viewports.html
Суть в том, чтобы отрисовать один раз в текстуру и потом использовать только эту текстуру.
>>08016
>То что меня волнует сейчас больше всего - как рисовать сетку?
1. Нарисуй спрайт-сетку с прозрачностью.
https://docs.godotengine.org/en/stable/tutorials/2d/custom_drawing_in_2d.html
2. Сдвигай её с шагом, равным одному тайлу:
>position = ((position + mouse_delta) / step).round() × step
3. Для красоты размываешь края сетки шейдером.
>>08018
>Я все ещё ищу годные гайды по тому как сделать ингейм левел клитор понятным.
Делаешь палитру блоков и всё, что ещё надо?
>клитор нужно ручками
Да. Вот так. Продолжай.
>меньшего контроля за каждым отдельно взятым тайлом. Если основной граунд можно отрисовать тайлмапой, то знаки вопросиков
Рисуешь статичные тайлы тайлмапой, а динамические объекты спавнишь по необходимости. Проблемы?
>Плюс по моим экспериментам большие тайлмапы все равно предательски лагают. Из-за этого я и начал смотреть в сторону чанкирования карт.
Ты на 4.x? Там вроде 2D батчинг сломали...
Попробуй увеличить это значение в тайлмапе:
https://docs.godotengine.org/en/stable/classes/class_tilemap.html#class-tilemap-property-cell-quadrant-size
Это должно сделать чанки больше размером, таким образом сократив общее число чанков.
Если не поможет, есть вариант использовать это:
https://docs.godotengine.org/en/stable/tutorials/rendering/viewports.html
Суть в том, чтобы отрисовать один раз в текстуру и потом использовать только эту текстуру.
>>08016
>То что меня волнует сейчас больше всего - как рисовать сетку?
1. Нарисуй спрайт-сетку с прозрачностью.
https://docs.godotengine.org/en/stable/tutorials/2d/custom_drawing_in_2d.html
2. Сдвигай её с шагом, равным одному тайлу:
>position = ((position + mouse_delta) / step).round() × step
3. Для красоты размываешь края сетки шейдером.
>>08018
>Я все ещё ищу годные гайды по тому как сделать ингейм левел клитор понятным.
Делаешь палитру блоков и всё, что ещё надо?
>клитор нужно ручками
Да. Вот так. Продолжай.
>position = ((position + mouse_delta) / step).round() × step
Перепутал немного, нужно не дельту сдвига мыши, а актуальную позицию мыши относительно начала координат/сетки тайлов:
>grid_pos = ((grid_pos + mouse_pos) / grid_step).round() × grid_step
Может, есть метод проще...
...а, точно, есть:
https://docs.godotengine.org/en/stable/classes/class_vector2.html#class-vector2-method-snapped
Тогда просто:
>grid_position = mouse_position.snapped(grid_step)
1920x1080, 0:28
Спасибо мужик, от души душевно в душу. Я от чего то даже и не подумал про перемещение. Я же по концепту хотел фоновую сетку крупную что бы общее положение пользователя на поле не терялось, думал что отрисовывать ее каждый раз заново единственный вариант. За вариант с движением спасибо огромное.
Касательно вьюпорта я не особо понял. Смысл же не только в том что конкретно тайлмапы лагают. Допустим я потенциально захочу какое нибудь РПГ с грабежом караванов в топ даун 2д, даже если самое поле тайловое я оптимизирую, то несколько сот объектов просто убьют всю производительность. Моё негодование тут скорее конкретно про вот этот аспект было, но конкретно для Марио тайлмап + объекты по ощущениям самый оптимальный вариант.
Но я завтра ещё со свежей головой все перепрочту, ещё раз спасибо огромное. Гуглил как сделать эту сетку наверное дня два.
Аргумент. Сонный перепутал 100 и 100 * 100
мимо
Помню кто то тут показывал сетку без единой строчки кода.
В тайлмапах же можно расставлять сцены вместо тайлов. (Начиная с 4ки). Ну и нарисовать сцену уголок из Line2D
Я уже справился обычной node 2d и несколькими ректанглами. Вот прочел про бетчинг, думаю разобраться поглубже, мб можно как то 30*50 ректанглов оптимизировать оптимизировать.
А вот насчёт сцен в тайлмапах не знал, огненная тема по идее для моей задумки.
800x600, 2:01
>оптимизировать оптимизировать
Низкой производительности бояться - игру не делать. Преждевременная оптимизация - корень всех зол.
Разобрался через минуту после поста. Я ее в прошлый раз задублировал и забыл про это. Помогло ПКМ -> make unique
И вообще. Откуда берутся leaked instance'ы на выходе? Как с этим бороться? Я всего лишь открыл уровень и тут же закрыл игру, а они наутекали.
>Я всего лишь открыл уровень и тут же закрыл игру, а они наутекали.
Ищи протечку. Срёшь поди всякими .new() вникуда.
Не парься, через тайлсеты тоже будет неудобно потом. Делай, в процессе наловчишься.
Жиза. Третью игру делаю, третий раз думаю "ну вот сейчас то я удобную систему создания локаций запилил", а потом боль-унижение. Похоже без кропотливого ручного труда в этом деле никуда, если у тебя не процедурное.
> нода находится вне дерева, ей надо при выходе из приложения делать queue_free()? Или, может, free()?
Проверь, если куй-фри срабатывает, делай куй-фри, если нет - делай фри. Куй-фри отличается только тем, что проверяет, нагрузку на движок (если по простому) и если нагрузка минимальна, он вызывает фри. Соответственно, если нода не в дереве, у неё не срабатывают процесс-колбэки, и вполне вероятно, что куй-фри не знает о том, нагрузка есть или нет.
Пробовал snapped но отсчёт тайла говено происходит, поскольку там идёт дефолтное округление, а надо просто отрезать десятичную часть.
Мой метод поиска тайла Vector2i(get_global_mouse_position() / tile_size)
А теперь, если я уберу строку 7, то тест-нода уже не получает уведомлений и не выгружается:
Лол, знаете, что? Я прописал оверрайд на queue_free() в обычную ноду, и знаете что? При остановке проекта она тоже не срабатывает. То есть, у меня есть большие сомнения насчёт того, чистит ли движок память после себя в принципе? Я не настолько кодер, чтобы делать выводы, насколько это правильно, но предполагается, что при остановке приложения оно должно чистить память. Вероятно, Хуан подумал, что память всё равно почистит система, после удаления процесса, поэтому не заморачивался? Или я чего-то не понимаю?
Выглядит всё так, что при закрытии окна, останавливается майнлуп, а все ресурсы продолжают висеть в памяти, пока винда/линух её не вычистит сама после убитого процесса.
память да почистится. для отдельно запущенного приложения. с отладочным запуском из движка скорее всего будет копится мусор пока не закроешь годот
Окей, щас соберу релиз тестового проекта. Прям аж интересно стало.
Почему при подъеме на угол или спуске визуально изменяется скорость движения персонажа? При этом, если выводить velocity, то остается без изменений. Godot 4
Если поставить галку constant speed у игрока, то скорость не меняется и все норм. В чем подвох этой галки?
Лень проверять, но queue_free может и не влиять на ноды не в дереве, попробуй free. Мои рассуждения такие, смысл queuefree отложить до след. промежутка между кадрами, но если она не в дереве ей _notification может и не рассылают.
Ля, спасибо
Мои рассуждения я изложил выше. Приложение обязано освободить все объекты перед выходом. Я наблюдаю обратное.
Всё таки, высвобождение ресурсов происходит, но так, что оверрайды мною назначенные в скриптах, не отрабатывают. Потому что если сделать ноду и не освободить её, в консоли будет соответствующая инфа. Если же всё что сам создал, сам и освободишь, инфы не будет. Причём в редакторе ничего не пишется, редактор молчит. Инфа пишется только на экспортнутом проекте.
Спасибо! А вот по такому случаю есть какие-то решения? Нужно создать заборчик текстурой, типа как в голдсурсовских играх, и честно говоря пиздец я ебался с этой хуйнёй. В хаммере в два клика такое делается. тут же пиздец. Суть проблемы: Годот размывает текстуру и не видит то что текстура прозрачная, т.е. вот этой черноты быть не должно. Вот как выглядит этот заборчик в редакторе(пик 2):
Я ж тебе вроде в прошлый раз отвечал? Ну проверь что там у тебя в материале стоит, там галочки для прозрачности есть.
Открыл уровень. Закрыл тестовый уровень. Вышел из игры. Утёк враг. Если его с уровня убрать, ничего не утекает. Если его убить, тоже не утекает. Враг дитя уровня, должен куефришиться вместе с уровнем, но вот нет.
Всяких там new() в этом куске нет. А что есть - добавляется в перестраховочный список подчищатора и подчищается при выходе.
>>08398
>hidden node
Вот такой херни у меня вообще не наблюдается. Зато в изобилии "Resource still i use" и "Orphan StringName".
>>08419
>Причём в редакторе ничего не пишется, редактор молчит
Вот да, тут вообще странно. Как будто предполагается, что я не должен об этом беспокоиться. Я вот узнал, что у меня утекает, вообще случайно, когда консоль браузера открыл.
Да как их делать-то с такими утечками памяти???
> Я вот узнал, что у меня утекает, вообще случайно
И я тоже. Пару дней назад скачал репу раст-екстеншна, в которую входит образец игоры на расте, переделанный додж да крипс. И сконпелировал всё, и экспортировал, был мужиком бля. А потом взглянул в консоль, а там аналогичное. И я тогда подумал, ну штош, видать наспех сделали. А тут такой дискасс в треде завертелся. Выходит в расте всё нормально закожено, это у годота проблемс.
Я сделоль, уже релизить собирался, а оно вот.
> Враг дитя уровня, должен куефришиться вместе с уровнем, но вот нет.
А вот тут ты что-то нахуевертил. В случае, когда нода добавлена в дерево - она куефришится. Пруф:
Сидим с нейронко-тян сюжет пишем. К движку даже не прикасался несколько дней, не до этого. Там такие полеты мысли. Мы так отлично дополняем друг друга.
На самом деле да, тут действительно. И я даже нашёл причину.
Кароч. Враг - рыба. Плавает в воде. Вода инстанциирует партиклю с брызгами, когда в неё что-то ныряет или из неё выныривает (_on_body_entered/exited). Партикля добавляется так: self.call_deferred("add_child", splashes). Ну и потом сама себе куефришит по таймеру.
При выгрузке уровня уровня рыба как бы "выныривает" - срабатывает body_exited. Но к следующему кадру call_deferred уже не случится, некуда деферрить. Ну и остаётся висеть в памяти.
Но я нашёл совсем уж необъяснимую утечку - рыбьи мозги. Простая нода, отрабатывающая рандомное плавание влево-вправо. Вот уж что точно не добавляется, не удаляется и ни с чем, кроме этой самой рыбы, не взаимодействует. Но утекает по не выясненной пока причине.
Но в итоге, походу, всё-таки не движок виноват, а мой говнокод. Это успокаивает, так как это исправимо.
Кстати, если так, то >>08517 , возможно, действительно тот образец игры или сам раст-экстеншен подтекают.
> возможно, действительно тот образец игры или сам раст-экстеншен подтекают
Я тоже нашёл причину. Я в тот раз компилил на рабочей машине без звука. И в редакторе меня предупреждало, что звуковое устройство не обнаружено. И видимо из-за этого в движке образовывалась утечка. Сейчас я когда мне анон предъявил >>08518 я не поленился скачал и скомпилил, и нихуясе, никаких утечек на домашней пеке со звуком.
>>08518
Сорян, был неправ, действовал сгоряча.
Ну у меня сейчас реально есть задача сделать сюжет часа на 3. Потом закончу буду думать, внки я не считаю играми, но вот экшн-рпг с диалогами с подачей сюжета уже соблазнительно. Или jrpg.
Вот ещё что происходит непосредственно при выходе (то есть, после print("shutting down") у меня сразу get_tre().quit(), и вот в логе после "shutting down", но перед отключением от пульсаудио):
>ERROR: Condition "_first != nullptr" is true.
> at: ~List (./core/self_list.h:108) - Condition "_first != nullptr" is true.
Мы вместе делаем. Дополняем слабые стороны друг друга, так сказать. Главное чтобы она не узнала что у меня девушка есть.
https://docs.godotengine.org/en/3.5/classes/class_node.html#class-node-method-print-stray-nodes
>void print_stray_nodes ( )
>Prints all stray nodes (nodes outside the SceneTree). Used for debugging. Works only in debug builds.
Странно, что это надо делать вот так вот. При том, что в отладчике можно посмотреть количество мёртвых душ; а вот имена их посмотреть можно только таким вот образом.
Насколько я понял.
В тройке. Четвёрку не щупал на этот счёт.
И всё же очень странная херня. С одной стороны, Годот такой заботливый, сам следит за памятью и всё подчищает, если на какую-то область данных не осталось указателей. С другой - есть реальная возможность накосячить, но никто тебе об этом не расскажет и нигде не покажет, пока ты не соберёшь проект и не экспортируешь его куда-нибудь в веб. Почему при выходе из игры не печатается в консоль редактора банальное "WARNING: ObjectDB instances leaked at exit"? Почему список этих утёкших нод нельзя посмотреть в редакторе? Почему , Хуан?
Зато я стал умнее и теперь буду следить за утечками с самых ранних стадий разработки, а не разгребать из прямо перед релизом. Чего и вам, аноны, советую, не повторяйте моих ошибок. А то я там таких костылей навтыкал, чтобы не утекало, страх и ужас.
Полезно. Я сейчас у себя мудрю с частым удалением-восстановлением нод, таймерами и твинами, и периодически у меня выскакивают варнинги "твин проснулся, а ноды уже нет!", если приведет к утечкам пригодится твой совет.
Кто-нибудь уже пользуется генератором справки?
Что я выяснил:
1. Достаточно дать скрипту имя (class_name) и он должен появиться в справке (F1 -> введите имя).
2. Все записи нужно писать после "##". В редакторе подсветка для таких строк изменяется.
3. Краткое описание скрипта пишется в самом его начале, после class_name и extends, но нужна пустая строка перед всем остальным содержимым.
4. Описание к сигналам, константам, свойствам и методам класса пишутся на строчке перед кодом.
5. Доступно форматирование - то же, какое можно найти в xml-файлах документации на гитхабе. Из того, что я сам обнаружил методом тыка:
>[code]text[/code]
Выделит "text" как строчку кода.
>[Node]
Ссылка на страницу справки о классе Node.
>[method foo]
Ссылка на метод foo() текущего класса.
>[method Node.get_node]
Ссылка на метод get_node() на странице Node.
>[member bar]
Ссылка на свойство/сигнал/константу "bar".
>[br]
Перенос на следующую строчку. Переносы текста внутри "##", даже если вы несколько строчек с "##" пишете, никак в документации не отображаются.
Если есть ещё какая инфа - делитесь, интересно же.
Ценная инфа. Спасибо!
Я и делаю, на 3.5. Но кто-то же должен тестировать новые версии, чтобы багов поменьше было когда я на них перекачусь.
>leaked instance
>Как с этим бороться?
Читать:
https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/gdscript_basics.html#memory-management
Также поможет запустить с командой --verbose.
>>08376
>Куй-фри отличается только тем, что проверяет, нагрузку на движок (если по простому) и если нагрузка минимальна, он вызывает фри. Соответственно, если нода не в дереве, у неё не срабатывают процесс-колбэки, и вполне вероятно, что куй-фри не знает о том, нагрузка есть или нет.
Ты этот бред нейронкой генерировал?
https://docs.godotengine.org/en/stable/classes/class_node.html#class-node-method-queue-free
>Queues a node for deletion at the end of the current frame. <...>
>The node will only be freed after all other deferred calls are finished, <...>
>>08401
>Я прописал оверрайд на queue_free() в обычную ноду, и знаете что? При остановке проекта она тоже не срабатывает.
Потому что ты не можешь оверрайдить встроенные методы встроенных классов. Т.е. можешь, конечно, но движок их вызывать не будет. Причина: если бы движок позволял оверрайдить любые методы, он был бы намного медленнее, чем сейчас.
>но предполагается, что при остановке приложения оно должно чистить память.
Ничего оно не должно "чистить". Когда процесс приложения работает, он может запрашивать у ОС новые блоки памяти, а когда они ему больше не нужны - сообщать ОС "мне это больше не нужно", чтобы другие приложения могли воспользоваться. Когда процесс приложения завершается, ОС знает, что память ему больше не нужна. Важно понимать, что речь идёт о высвобождении блоков памяти, а не буквальной очистке - все данные остаются в памяти, нулями автоматом не забиваются, только "умные" механизмы компиляторов помогают неявно очищать переменные/поля объектов, иначе там всегда был бы какой-нибудь рандомный мусор.
>>08417
>Приложение обязано освободить все объекты перед выходом.
Кому обязано? Тебе обязано? Утечек на уровне ОС такое поведение приложения не вызывает.
>dev-snapshot-godot-4-2-beta-2/
Блин, я всего пару часов назад скачал beta-1, создал проект и начал переписывать старые скрипты с 3.x...
> ты не можешь оверрайдить встроенные методы встроенных классов
Могу.
При моём самостоятельном высвобождении объекта, оверрайженая куфря работает, оверрайженная фря, да, не работает, потому что это таки деконструктор, а не просто метод.
Ну так и работает, что тут объяснять?
> CLAMP(пост_анона, ОП_пост, бмаплимит)
Если номер поста ИТТ, то клэмп вернёт номер поста без изменений. Если номер из прошлого треда, вернёт ОП-пост, если номер несуществующий большой номер - клэмп вернёт бамплимитный пост.
Аааа, всё понял, спасибо! Примерно так и думал
>При моём самостоятельном высвобождении
Именно так. Если в коде движка где-то есть вызов того же queue_free, твою функцию он не увидит.
Поэтому по умолчанию редактор выдает ошибку.
Это короткая запись такой логики:
>if value < min_bound: return min_bound
>elif value > max_bound: return max_bound
>else: return value
Это довольно часто в играх встречается.
А, это на цпп, понял.
>Нужно создать заборчик текстурой, типа как в голдсурсовских играх,
>текстура прозрачная
Тут такое дело. Во времена древних игр каждый треугольник был на счету, потому что видеокарты слишком долго их перебирали. Поэтому всякие решётки, веревки и прочее рисовали текстурой с большим количеством прозрачных пикселей.
Потом видеокарты стали быстрее и начали гриндить десятки миллионов треугольников как будто их и нет совсем. Но вот растеризация как была сложной, так и осталась, а тем более если у тебя в текстуре есть прозрачные пиксели. Поэтому в современных играх оптимальнее насрать кучу мелких полигонов в виде решетки вместо натягивания прозрачной текстуры.
Но чтобы знать наверняка, нужно тестировать. Во всяком случае у меня были серьёзные просадки в Godot из-за множества прозрачных текстур. Не зря эта опция в материале выключена по умолчанию.
>>08619
>Правда с другой стороны ещё нужно текстурку подправить, подтянуть, но в целом уже одна сторона хорошо сделана.
Переключи в материале решётки этот параметр:
https://docs.godotengine.org/en/stable/classes/class_basematerial3d.html#class-basematerial3d-property-cull-mode
"CULL_BACK" на "CULL_DISABLED". Тогда ты можешь полностью удалить прямоугольник с другой стороны, потому что одна текстура будет видна с двух сторон.
Надеюсь, у тебя этот материал решётки отдельно от материалов остальной сцены, иначе:
- код для прозрачных пикселей будет работать для всех текстур, даже если нет прозрачных пикселей, это очень высокая суммарная нагрузка.
- CULL_DISABLED будет рисовать лишнюю геометрию у всех остальных объектов, в зависимости от сцены это может дать слишком высокую нагрузку.
>Годот может самостоятельно без спроса закуефришить ноду. Очень страшно.
Только потом на плачь в треде, что ты создал гениальную архитектуру проекта, обмазанную @warning_ignore(), а он ВНЕЗАПНО И ПО НЕИЗВЕСТНОЙ ПРИЧИНЕ отказывается работать. Потом ещё какой-нибудь issue с жалобой на неуловимый баг сделаешь и обидишься на то, что этот баг не баг и фиксить не будут.
>Почему при выходе из игры не печатается в консоль редактора банальное "WARNING: ObjectDB instances leaked at exit"? Почему список этих утёкших нод нельзя посмотреть в редакторе? Почему, Хуан?
Мне больше всего кажется странным, что Node у нас наследуется от Object, а не от RefCounted. Наверное, этому есть какие-то внутренние причины... Но чисто с точки зрения пользователя движка, зачем нужно иметь возможность сохранить сиротскую ноду, на которую никто больше не ссылается?
Если вы удаляете ноду через remove_child(), вы обязаны сохранить ссылку на неё, иначе потеряете к ней доступ. Теоретически, нода может сама себя добавить в дерево, если получит сигнал извне, а сигнал мог быть привязан заранее... Но вот если серьёзно, зачем может быть нужен такой костыль?
Пусть бы ноды самоудалялись, когда они никому больше не нужны. Не думаю, что это вызвало бы ощутимые проблемы с производительностью...
>>08524
>Враг - рыба. Плавает в воде. Вода инстанциирует партиклю с брызгами, когда в неё что-то ныряет или из неё выныривает
Не лучше было бы иметь какое-то количество подготовленных заранее брызг? Чтобы не было, например, одновременного создания 1000 новых брызг, когда в воду упадёт большая куча вещей.
>Партикля добавляется так: self.call_deferred("add_child", splashes).
А для чего здесь call_deferred? Ошибку выдаёт? Если у тебя 100500 брызг добавляется за раз, то игра всё равно зависнет, только не сразу.
>Но я нашёл совсем уж необъяснимую утечку - рыбьи мозги. Простая нода, отрабатывающая рандомное плавание влево-вправо. Вот уж что точно не добавляется, не удаляется и ни с чем, кроме этой самой рыбы, не взаимодействует.
Лол, не удивлюсь, если ты где-то что-то с ней делаешь, но забыл об этом, как с брызгами.
>>08526
>компилил на рабочей машине без звука
>звуковое устройство не обнаружено.
Линукс что ли? На Виндувс вроде есть затычка для звука, если ты её специально не отключал...
>Зато я стал умнее и теперь буду следить за утечками с самых ранних стадий разработки
Имеет ли это смысл? Главное по-быстрому накидать прототип, поиграть в него, выбросить. Если редактор на любой Hello World будет срать ошибками вида:
>WARNING: ObjectDB instances leaked at exit
Это отпугнёт новичков + будет напрягать во время прототипирования новых идей. Памяти слишком много лишней, ноды почти ничего не весят, так что на первых этапах плевать, кто там утекает.
Искать утечки памяти в прототипе - это что-то из разряда "язык без строгой типизации не язык", "язык должен быть максимально быстрым, даже если это ощутимо вредит читаемости кода" или "движок без магической оптимизации любых кривых ассетов не подходит для создания игр".
Прежде чем люди построили Титаник, они строили множество мелких судов, лодок и простых плотов. Однако, заделывание дырок в лодках и плотах не помогло избежать протечек в Титанике...
>Главное по-быстрому накидать прототип, поиграть в него, выбросить.
Забыл прикрепить иллюстрацию своего прогрессивного геймдев воркфлоу. Рекомендую.
Спасибо за подробный ответ. А вот это
>Надеюсь, у тебя этот материал решётки отдельно от материалов остальной сцены, иначе...
Как понять? Вот, смотри, нормально всё?
Настроил вс студию
Движок крашнулся при первом запуске
После перезапуска все окей
Импортировал модель в сцену
Увидел какой-то новый адвансед импорт в отдельном окне.
Потыкал кнопки
Движок крашнулся
Импоритирую модель снова
Забыл как превратить импорт в полноценную сцену вместо ебаного inherited scene
Идешь в доки
В доках за годы по прежнему нихуя
Идешь в гугл
В гугле все жалуются на эту хуйню но никто не дает ответа
Удалил годот
Пришел насрать на дваче
Хм почти также было! Хехехехе. Ехехехехе. Ахахахах. АГАГАГАГАГА. Ну я тип... Гомо. Гомоиммунитет у меня выработался.
>Поставил годот
Годот не требует установки, ты спалился в первой строчке, движкосрачер.
Ах да, конечно, верим. Без скринов, пруфов. Так все и было.
>Поставил годот после долгого перерыва
1. Его достаточно скачать и запустить.
2. Зачем было удалять? У тебя диск на 32 Гб?
>Настроил вс студию
Зачем? У нас встроенный редактор.
>Движок крашнулся при первом запуске
Может быть из-за шейдеров/драйвера видюхи. При первом запуске они компилируются и сохраняются.
>Импортировал модель
>адвансед импорт
>Потыкал кнопки
>Движок крашнулся
Нужно issue писать на гитхаб. Вот сюда:
https://github.com/godotengine/godot/issues
>как превратить импорт в полноценную сцену
Зачем? В этом нет необходимости.
>вместо ебаного inherited scene
Это нужно, чтобы при обновлении файла модели твоя сцена не была перезаписана импортом.
>В доках за годы по прежнему нихуя
Учи английский, тогда буквы латиницы увидишь.
https://docs.godotengine.org/en/stable/tutorials/assets_pipeline/importing_scenes.html#using-the-advanced-import-settings-dialog
>В гугле все жалуются
>но никто не дает ответа
Нужно не в гугле смотреть, а здесь:
https://github.com/godotengine/godot/issues?q=is%3Aissue+is%3Aopen+%22advanced+import%22
>Удалил годот
>Пришел насрать на дваче
Так ты никогда ничего не сделаешь. Все инструменты имеют свои баги и проблемы, которые порой долго не могут исправить. Но если ты психуешь из-за мелких косяков и сразу бросаешь инструмент, тогда ты не сможешь ничего сделать. Я лично далеко не с первой попытки вкатился в Godot: пару раз пытался, бросал. Однако, когда попытался серьёзно разобраться, у той же юнити багов и критических проблем лично для меня оказалось существенно больше, поэтому я в конце концов остановился и освоился на Godot.
>Поставил годот после долгого перерыва
1. Его достаточно скачать и запустить.
2. Зачем было удалять? У тебя диск на 32 Гб?
>Настроил вс студию
Зачем? У нас встроенный редактор.
>Движок крашнулся при первом запуске
Может быть из-за шейдеров/драйвера видюхи. При первом запуске они компилируются и сохраняются.
>Импортировал модель
>адвансед импорт
>Потыкал кнопки
>Движок крашнулся
Нужно issue писать на гитхаб. Вот сюда:
https://github.com/godotengine/godot/issues
>как превратить импорт в полноценную сцену
Зачем? В этом нет необходимости.
>вместо ебаного inherited scene
Это нужно, чтобы при обновлении файла модели твоя сцена не была перезаписана импортом.
>В доках за годы по прежнему нихуя
Учи английский, тогда буквы латиницы увидишь.
https://docs.godotengine.org/en/stable/tutorials/assets_pipeline/importing_scenes.html#using-the-advanced-import-settings-dialog
>В гугле все жалуются
>но никто не дает ответа
Нужно не в гугле смотреть, а здесь:
https://github.com/godotengine/godot/issues?q=is%3Aissue+is%3Aopen+%22advanced+import%22
>Удалил годот
>Пришел насрать на дваче
Так ты никогда ничего не сделаешь. Все инструменты имеют свои баги и проблемы, которые порой долго не могут исправить. Но если ты психуешь из-за мелких косяков и сразу бросаешь инструмент, тогда ты не сможешь ничего сделать. Я лично далеко не с первой попытки вкатился в Godot: пару раз пытался, бросал. Однако, когда попытался серьёзно разобраться, у той же юнити багов и критических проблем лично для меня оказалось существенно больше, поэтому я в конце концов остановился и освоился на Godot.
https://godotengine.org/article/dev-snapshot-godot-4-2-beta-2/
Не ждём, а готовимся.
>Это отпугнёт новичков
Нихуя, новички такое вообще не понимают.
>Искать утечки памяти в прототипе
Прикинь, кое-кто не прототипы делает, а игры. Кто делает прототипы, разрешаю эти утечки игнорировать.
>Если редактор на любой Hello World будет срать ошибками
Если ошибки есть, о них надо сообщать. Можно дать галочку в настойках, сообщать ли конкретно об этих ошибках (как собсно с большинством ошибок и сделано).
>>08729
>Не лучше было бы иметь какое-то количество подготовленных заранее брызг?
В прототипе так и было. Но это некрасиво и не экономно.
>когда в воду упадёт большая куча вещей
Не "когда", а "если". Уровни крупнее не станут, потому что тогда станет слишком долго их проходить; врагов больше не станет, потому что тогда буит мясо. Так что большую кучу вещей взять тупо неоткуда.
>А для чего здесь call_deferred? Ошибку выдаёт?
Ошибок не выдаёт, но ругается, что добавлять ноды в физикс_процессе не положено.
>>08724
Чел, я не тот анон, который оверрайдил куефри, но мне кажется, он это чисто из спортивного интереса делал, а не вот это что ты там придумал. И вообще, я всего лишь говорю, что вряд ли где-то ещё в движке есть вызов куефри, потому что а) это привело бы к самопроизвольному удалению нод, б) это всего лишь интерфейс к внутренним вызовам, а не сами внутренние вызовы. Вот в коде редактора - да, там наверняка есть. Но не в движке.
>Аноним 19/10/23 Чтв 17:58:13
>https://godotengine.org/article/dev-snapshot-godot-4-2-beta-2/
>Делайте игры.
>>08760
>Аноним 20/10/23 Птн 00:01:39
>https://godotengine.org/article/dev-snapshot-godot-4-2-beta-2/
>Не ждём, а готовимся
Ну и зачем дважды постить?
Я тут >>08669
>всего пару часов назад скачал beta-1
А ты второй раз постишь...
>новички такое вообще не понимают
Зато они видят КРАСНУЮ НАДПИСЬ и пугаются.
>Прикинь, кое-кто не прототипы делает, а игры.
Мне бы твою суперспособность... Даже ААА студии не смогут сравниться с твоей геймдев суперсилой.
>Если ошибки есть, о них надо сообщать.
Утечка - не ошибка. Это проблема, но не такая, как сложение строки с числом или деление на ноль.
>Но это некрасиво и не экономно.
>Не "когда", а "если".
>Так что большую кучу вещей взять тупо неоткуда.
В таком случае ограниченное количество заранее подготовленных спецэффектов выглядит более рациональным выбором, чем динамическая работа с произвольным количеством эффектов. У тебя выбор между памятью и скоростью, и ты можешь точно посчитать, сколько памяти тебе понадобится, а скорости тебе нужно как можно больше.
>Вот в коде редактора - да, там наверняка есть.
Нужно проверить, влияет ли это на tool-скрипты...
>видят КРАСНУЮ НАДПИСЬ и пугаются
>Утечка - не ошибка. Это проблема, но
Я хочу сказать, что можно было бы выводить:
>Warning: 1234 orphan nodes freed automatically.
Но даже в таком случае, эта надпись может быть раздражающей, когда ты часто юзаешь F6, тестя множество обрывков игры, которые могут по отдельности сорить нодами, но не будут вместе.
>Утечка - не ошибка
В таком случае объясни мне, почему вот эти все неошибки достойны того, чтобы присутствовать в этом списке, а утечки - нет? Почему эти неошибки не мешают прототипировать и не пугают нубов, а сообщения об утечках - мешают и пугают?
>видят КРАСНУЮ НАДПИСЬ и пугаются.
А ведь можно эту надпись написать ну я не знаю... Жёлтым? Белым? Серым? Какой там у нас цвет считается не страшным для новичков?
И вообще. Пусть боятся говнокодить, а не красных надписей.
Сцена А, её наследники А1, А2, А3 и т.д.
Сцена Б содержит детей: А1, А2, А3.
Сцена Б1 наследует от Б.
Баг: открываю Б1, а там А1 и А3 превратились в А; хотя в родительской Б ничего не поменялось. Через пару переоткрытий все А1 и А3 внутри Б превратились в А. Ещё через пару переоткрытий Б перестала открываться, неожиданное окончание файла.
Такая хуйня.
новый спайдермен на любителя, конечно
Хуй знает. Переполз с наследование на композицию и тебе советую.
Ты перепутал, это не юнити тред
Ты вместо LTS поставил бету которая еще даже не релтз кандидат, но виноват конечно кто-то другой.
Делаешь минимальный проект воспроизводящийся
Открываешь issue либо отправляешь в ту если про это уже создали.
Можешь кинуть сюда, я тоже посмотрю.
https://docs.godotengine.org/en/stable/tutorials/physics/troubleshooting_physics_issues.html#scaled-physics-bodies-or-collision-shapes-do-not-collide-correctly
Официальная позиция масштабировать не надо, если надо, то нужна такая структура
Node3D
-MeshInstance
-RididBody3D (resource: CollisionShape)
Где мешинстанс ты скалируешь, а ригид - нет, но меняешь размеры у CollisionShape, напр. радиус у сферы.
Хотя мне казалось что в какой то момент это переделали и можно стало масштабировать и редактор перестал ругаться, но может быть я путаю.
Алсо ты можешь еще раз повторить процесс и прямо скидывать после каждого шага tscn, это же текстовый файл, в нем сразу видно будет что поменялось, намного упростит исправление.
>Хотя мне казалось что в какой то момент это переделали и можно стало масштабировать и редактор перестал ругаться, но может быть я путаю.
Мне вот тоже так казалось. Редактор не ругается, но если физика начнет вести себя странно - в первую очередь уберу скалирование.
откройте для себя гит.
Ты не понял.
А не, нихуя, в 3.5.2 тоже вылезло.
Походу, при каких-то изменениях в скрипте A возникает. Точные условия пока вообще хз.
>Откатился на 3.5.2
Последней версией тройки у меня стоит 3.5. Меня задолбало качать все эти патчи и я уже собирался переходить на четвёрку. А потом задепрессовал.
>Баг: открываю Б1, а там...
>Через пару переоткрытий
Решение: не открывать сцены лишний раз, лол.
>Сцена А, её наследники А1, А2, А3 и т.д.
>Сцена Б содержит детей: А1, А2, А3.
>Сцена Б1 наследует от Б.
Можешь конкретнее сказать, о чём идёт речь? Что это за объекты с таким наследованием? Любопытно.
Очередной мудак без диздока запутался в своём производственном аду. А виноват движок. Ну конечно же. Не ты.
У любого человека есть право запутаться, и движок не безупречный, в такой баг вполне верится, хотя пруфов нам так и не предоставили, конечно.
>в такой баг вполне верится
Двачую. Регулярно сталкивался с поломкой сцен и привык к этому. Это норма для любого движка. Поэтому хранят данные сцены в текстовом виде.
>хотя пруфов нам так и не предоставили
Пруфов чего? Файла, в котором какие-то связи неправильно прописаны? Это подделать можно.
Поломка могла быть вызвана вообще не движком, а какой-нибудь фазой луны, лол, ОС что-то делала и повредила код движка в RAM, на диске произошла ошибка чтения или записи, или космические лучи переключили бит в памяти, всякое могло быть. Так и появляются баги, которые нельзя воспроизвести.
>Файла, в котором какие-то связи неправильно прописаны? Это подделать можно.
Файлом сцены, который при сохранении херится с каждым разом все сильнее. Причем это в первую очередь надо в ишью, чтобы это могли починить.
>Файлом сцены, который при сохранении херится с каждым разом все сильнее.
Тупость ещё и в том, что херится он при ОТКРЫТИИ, но потом тут же СОХРАНЯЕТСЯ без разрешения.
Вообще, есть подозрение, что в тот момент, когда я случайно перетащил папку scenes в табе файловой системы (описывал этот косяк в прошлом треде), поломались какие-то адреса зависимостей где-то там. По крайней мере, после того случая мне попадалось что-то типа: сцена А наследует от Б, сцена Б наследует от А; каким-то хером этот барон мюнхаузен работал, пока я не попробовал поменять свойства, после чего обе сцены превратились в тыкву; естественно, изначально ничего такого не было, А была предком, Б наследником.
В общем,
>>08870
>минимальный проект воспроизводящийся
вряд ли получится собрать.
Вдобавок сцены у меня в этом проекте все .scn (анон посоветовал для быстродействия; я был тогда нуб, наивен и поверил). Ошибку осознал, к следующему проекту не повторю, все сцены и ресурсы буду хранить исключительно в текстовом формате.
>>08914
>Можешь конкретнее сказать, о чём идёт речь? Что это за объекты с таким наследованием? Любопытно
Б - базовый класс персонажа. От него наследуют все прочие персы.
А - базовый класс способности. Все остальные способности от него зависят. Соответственно, несколько основных способностей есть и в базовом персонаже.
>>08937
>Очередной мудак без диздока запутался в своём производственном аду.
Ну, что ж ты о себе так плохо говоришь? Поднимай самооценку, бро. У меня вот с архитектурой проекта вообще проблем нет. Забросил его больше чем на полгода, потом открыл и нигде ни в чём не запутался. А сегодня таки довёл до релиза.
900x890, 1:11
И вправду обидно.
Это норма, двач же. Продолжай хорошо работать.
Алсо я нахожу что толковей показывать видосы на реддите, а ИТТ удобней общаться на тему годота и спрашивать/отвечать технические штуки.
А еще эти move_and_collide/move_and_slide, одного надо умножать на дельту, а другого нельзя. Уууу сюка.
Потому что иногда дельта не нужна.
>толковей показывать видосы на реддите
Там регистрация + репутация а-ля Пикабу, так что если однажды обосрёшься, в жизнь не отмоешься.
>ИТТ удобней общаться на тему годота и спрашивать/отвечать технические штуки.
Ну вот я думал, что кто-нибудь спросит, как я это сделал, а я опишу подход. И ещё хотел спросить, как решить баг с застреванием, но передумал (там нужно всё переписать масштабируемо).
>>09135
>показывать сделанное надо не коллегам
>а потенциальным игрокам.
Такое показывать бессмысленно, игроки без опыта разработки игр не понимают суть™. Они либо будут недовольны низким качеством (серые кубы, суть которых - не отвлекаться на арт, отсутствие всех побочных деталей), либо, наоборот, создадут себе завышенные ожидания и начнут просить/требовать невозможное (ММО и т.п.).
Так что мне больше нравится отклик других разработчиков, которые в теме и могут что-то по существу спросить или подсказать.
А игрокам нужно показывать уже почти готовый продукт, который осталось только отполировать.
>На реддите,
См. выше, репутация + серьёзные ограничения.
>твиттере,
Он уже мёртв - без платной подписки тебя мало кто увидит, да и раньше встречал много годных проектов, о которых твитят, а откликов нет.
>ютубе,
Чаще всего бесполезно, там взлетают только развлекательные влоги с кучей шуток.
>вк
Вообще бесполезно, если заводить свой паблик без сотен активных знакомых, а в какой-либо большой вряд ли пропустят, разве что это геймдев клуб по интересам аналогично /gd/.
И потом, всё перечисленное имеет смысл только когда есть сформированная база игры и разработка идёт полным ходом по чётко намеченному пути к релизу. Постить в "верхний интернет" какие-то мелкие прототипы смысла нет, если ты не популярный клоун ютубер с кучей подписчиков.
Не понимаю, почему все стесняются залить свои недоделки сюда, как будто реально могут "украсть идею" и заработать миллионы вместо тебя (да на здоровье, я только рад буду, если идея взлетела).
В /pa/ и /td/ охотнее делятся тем, что сами сделали (включая бесконечный поток прототипов), хотя это то же самое "показывать коллегам".
>толковей показывать видосы на реддите
Там регистрация + репутация а-ля Пикабу, так что если однажды обосрёшься, в жизнь не отмоешься.
>ИТТ удобней общаться на тему годота и спрашивать/отвечать технические штуки.
Ну вот я думал, что кто-нибудь спросит, как я это сделал, а я опишу подход. И ещё хотел спросить, как решить баг с застреванием, но передумал (там нужно всё переписать масштабируемо).
>>09135
>показывать сделанное надо не коллегам
>а потенциальным игрокам.
Такое показывать бессмысленно, игроки без опыта разработки игр не понимают суть™. Они либо будут недовольны низким качеством (серые кубы, суть которых - не отвлекаться на арт, отсутствие всех побочных деталей), либо, наоборот, создадут себе завышенные ожидания и начнут просить/требовать невозможное (ММО и т.п.).
Так что мне больше нравится отклик других разработчиков, которые в теме и могут что-то по существу спросить или подсказать.
А игрокам нужно показывать уже почти готовый продукт, который осталось только отполировать.
>На реддите,
См. выше, репутация + серьёзные ограничения.
>твиттере,
Он уже мёртв - без платной подписки тебя мало кто увидит, да и раньше встречал много годных проектов, о которых твитят, а откликов нет.
>ютубе,
Чаще всего бесполезно, там взлетают только развлекательные влоги с кучей шуток.
>вк
Вообще бесполезно, если заводить свой паблик без сотен активных знакомых, а в какой-либо большой вряд ли пропустят, разве что это геймдев клуб по интересам аналогично /gd/.
И потом, всё перечисленное имеет смысл только когда есть сформированная база игры и разработка идёт полным ходом по чётко намеченному пути к релизу. Постить в "верхний интернет" какие-то мелкие прототипы смысла нет, если ты не популярный клоун ютубер с кучей подписчиков.
Не понимаю, почему все стесняются залить свои недоделки сюда, как будто реально могут "украсть идею" и заработать миллионы вместо тебя (да на здоровье, я только рад буду, если идея взлетела).
В /pa/ и /td/ охотнее делятся тем, что сами сделали (включая бесконечный поток прототипов), хотя это то же самое "показывать коллегам".
> реально могут "украсть идею" и заработать миллионы вместо тебя
Это не шутки. Реально могут и украдут.
А если серьезно, реддит самая полезная платформа. Ограничения фармятся за пару вечеров методом "пощу котов в малопопулярные сабреддиты", а репутация - ну, просто не веди себя как на харкаче. Я обычно пощу видос, а в комментах только "спасибо за фидбек" раздаю. И ничего больше на этом аккаунте не делаю. Сру с другого.
>не учитывают дельту автоматом
Где нужно - там учитывают.
>зачем я вручную должен?
Ты не должен. В обработчики поступает дельта, а ты используешь её как захочешь, или не используешь вообще (переименуй в _delta чтоб не жаловался).
>move_and_collide/move_and_slide, одного надо умножать на дельту, а другого нельзя.
В 4.x у CharacterBody2D/3D остался только slide, и тебе больше не нужно передавать в него аргументы - всё настраивается через свойства класса.
>все .scn (анон посоветовал для быстродействия
Всё верно, но лучше конвертировать для экспорта, если экспорт ещё не делает это автоматически.
>Ошибку осознал, к следующему проекту не повторю, все сцены и ресурсы буду хранить исключительно в текстовом формате.
Ты ж можешь пересохранить сцены в tscn. Если они, конечно, открываются редактором без ошибок.
>Однажды доползу и до нее.
Что мешает начать осваивать уже сейчас? Основные проблемы с редактором вроде как решены, он даже меньше тормозить стал (по сравнению с 4.0).
>Это не шутки. Реально могут и украдут.
Правда?! Как здорово! Тогда вот:
Здраствуйте. Я, Анонимус. Хотел бы чтобы вы сделали игру, 3Д-экшон суть такова... Пользователь может играть выжившим мастером на все руки и путешественником. И если пользователь играет на острове, то он должен построить деревянный домик летающий и збижать с острова, пока тот не упал в бездну. Можно грабить летающие корованы... И острова раз лесные то сделать так что там густой лес... А движок можно поставить так что вдали деревья картинкой, когда подлетаеш они преобразовываются в 3-хмерные деревья. Можно крафтить и т.п. возможности как в типичных выживалках. И предметы 3-хмерные тоже, и запчасти корабля тоже 3д. Можно прыгать на тросе по острову и т.п. Если играть за путешественника то надо управлять кораблём, и ремонтировать его на ходу (механики я не придумал) и заправлять топливом, летучим газом, и ходит на набеги на острова за ресурсами (деревом, топливом, газом…). Ну а если корабль разбился… то значит нужно строить новый на острове, пользователь сам себе командир может делать что сам захочет хочет строит хочет летает может просто бегать и беситься. Всего в игре 4 зоны. Т.е. карта и на ней есть 4 зоны, 1 - зона над облаками (нейтрал), 2- зона плотных облаков (где много островов), 3-зона стратосферы, 4 - зона бездны… (в самом низу, там всё погибает…)
Так же чтобы в игре корабли могли не только сломаться но и отвалиться часть корабля и если пользователь не починит его то он развалится, так же сломать двигатель но пользователь может не умереть а просто лететь на оставшихся, или собрать новый прямо в полёте, если баллон с газом тоже либо упадёшь в пропасть либо будеш медленно лететь до ближайшего острова, или самое хорошее… скрафтить замену прямо в полёте из запасных ресурсов. Сохранятся можно…
P.S. Я четыре года хочу такую игру.
Это очевидно, если почитать исходники.
Каждый октант - это набор MultiMeshInstance. Если октант слишком мелкий, толку от мультимеша мало.
Размер по умолчанию в 8x8x8 непонятно для кого сделан, ведь очевидно, что ты не будешь заполнять все 512 позиций одним мешем. Скорее всего у тебя вообще всё в один слой, 64 позиции. Допустим, ты сделал 8 типов блоков - тогда в одном октанте в среднем у тебя по 8 блоков внутри каждого из 8 мультимешей. Бессмыслица какая-то выходит.
С другой стороны, из-за мультимешей каждый октант отображается даже когда на экране, условно, только маленький уголок одного блока. Если октанты очень большие, это может вызвать лишнюю нагрузку в ситуациях, когда можно было ничего не рисовать.
Не очень тебя понял. Разве рейкаст не находит только ближайший по расстоянию, почему он у тебя всех цепляет?
А вообще есть разные способы.
У Area есть функция get overlapping bodies. Получаешь список, сам в нем определяешь самый верхний спрайт по индексу.
Ну или например враги сами следят и отключают хитбоксы когда на них стоит другой враг.
Или делаешь так чтобы они не ходили друг по другу.
Вор крадёт то, что плохо лежит: бывший владелец вещи не позаботился о её безопасности и поэтому вор её украл. Вору приходится приложить усилия для совершения воровства, и чем больше старается владелец вещи, тем тяжелее приходится вору для совершения воровства. Лучше всего для вора, чтобы владелец вещи просто кинул её на какое-нибудь легкодоступное место и ушёл, забыв о ней, тогда вор легко сможет забрать вещь себе, возможно, даже без последствий, ведь владелец забыл вещь.
Следовательно, если идею игры можно украсть, то идейный вор должен брать самые непримечательные, брошенные, плохо сформированные идеи, выброшенные на произвол судьбы без стараний со стороны выдумывателя идеи. Чем больше выдумыватель старается в оформлении и вылизывании своей идеи, тем больше усилий придётся приложить идейному вору, чтобы украсть эту идею.
Так зачем мне стараться и что-то писать, если я хочу помочь вору идей? Я вбросил идею - бери, воруй, я сделал всё возможное для упрощения твоей работы.
>сделал рейкаст. Когда рейкаст противника ловит скопившееся количество одинаковых юнитов,
Покажи, как ты сделал "рейкаст". Area2D - не рейкаст.
>В игре хитбоксы союзников наслаиваются
Зачем? Никогда не понимал этого в играх, выглядит максимально тупо. С тем же успехом можно просто сделать один юнит с увеличенным уроном.
>я думал, что кто-нибудь спросит, а я опишу подход
Добро пожаловать в реальный мир, где всем насрать.
Нет, я не хочу сказать, что и мне тоже, хотя так и есть, просто выходит, что ты сам выстроил ожидания и сам же разочаровался, когда мир их не оправдал. Мой тебе совет: избавляйся от этого паттерна. Он ведёт к снижению самооценки и многочисленным социальным проблемам. Окружающие не обязаны выполнять твои ожидания и даже знать о них.
В данном случае следовало поступить так: хочешь описать подход - описываешь подход. И внезапно оказалось бы, что анонам интересно.
А как ты наносишь урон? Тащемта ничто же не мешает определять все тушки, но дамажить только одну.
>ничто же не мешает определять все тушки
Вангую, у него что-то вроде:
>func _on_area_2d_body_enter(body):
> if body.is_in_group("player"): body.hurt(damage)
Поэтому дамажит сразу всех + он не видит ошибку.
>Разве рейкаст не находит только ближайший по расстоянию
Именно так. Я для этого и использовал рейкаст, чтобы ближайшего к источнику луча цеплял.
>почему он у тебя всех цепляет?
Я предполагаю, именно потому что коллизия у персонажей одинаковая и координаты по иску и игрику совпадают.
>>09243
Спасибо, обращусь, если не решу здесь и сейчас.
>>09250 >>09251
>Эпизод один.png
>Эпизод два.png
>Эпизод три.png
Я фиксирую саму коллизию Collision врагов при помощи разных слоёв Layers и Mask, безо всяких Area2D, Groups, Signals. Такая ситуация не только в третьей версии движка, но и четвёртой: одинаковые юниты накапливаются в одном месте и их может дамажить один противник.
Думаю это исправлять через get_children_count( Мама всех союзнических нод ), get_child( max Последняя нода в списке ). Мне это не нравится на интуитивном уровне, это по-уродски, отвратительный говнокод, неэстетичный, не энергоэффективный, лол.
!Дополню!
Я создал отдельную булевую переменную money_collected именно потому что каждый юнит, который синхронно атаковал врага, вызвал метод Collect_money() и это приносило в (n=количество союзников) больше денег. Удивительно, но, получается, что всё-таки есть единственный, первый союзник, который первее активирует функцию Collect_money() и заставляет money_collected стать true, но с уроном это почему-то не работает.
Может лучше включать маску коллизии луча только для последней ноды? Как только нода умирает, включаешь коллизую следующей, и так далее.
Не получится, у меня будут другие ноды, которые двигаются с разной скоростью и имеют разную высоту коллизии. Тут даже если измерять у кого в списке дальше остальных позиция по x, не получится из-за задуманной механики с разным ростом Y коллизий и способности по ней попадать разными типами противников.
>queue_free
>Ведь он ждет нас всех в конце.
Всех нас ждёт в конце free(). А queue_free() - это когда сверху приходит приказ расстрелять, а расстрельная переполнена - приходится вставать в очередь.
Для опыта, как минимум, чтобы понять все тонкости механик, обнаружить для себя неожиданные препятствия, а потом с набитой рукой делать игру мечты с блэкджеком и кораванами.
Если честно выглядит как какая-то проблема с механикой, не до конца понятно что именно ты хочешь добиться, это какой-то tower attack, или как оно там называется?
Тебе нужно чтобы враг атаковал только одного?
Возможно стоит обойтись без кастования лучей, а использовать вместо этого стек целей, для каждого противника свой стек целей которые он может атаковать.
Например:
Враг с мечом атакует тех кто перед на дистанции меньше N.
Враг лучник атакует тех кто дальше N, но не атакует тех кто ближе.
Заходя в разные зоны цель попадает в разные группы, по таймеру каждые сколько-то секунд раздаешь целям урон и обновляешь группы.
Хотя не, не совсем так.
free() - расстрел на месте, когда человечек не важен.
queue_free() - это когда человечек настолько важен, что ему позволяют перед расстрелом дела доделать.
А расстрельная переполняется в любом случае, но в случае queue_free() все дела уже доделали и ждут.
Обычно это что угодно, во что анон играл в детстве. Если анон не имеет тормозов, то это условный скайрим/бг3, а если анон рассчитывает свои силы то условный ангри бердс.
У меня раньше были игры мечты, но со временем понял, что на самом деле нет никаких игр мечты, есть только путь геядевелопера и хочется просто делать разные игры по настроению, а потом если в голове появляется оригинальная механика, добавляешь её в один из тематических проектов.
>Я предполагаю, именно потому что коллизия у персонажей одинаковая и координаты по иску и игрику совпадают.
Это невозможно, get_collider() возвращает 1 объект.
>play_ability()
Где/когда эта функция вызывается?
>Такая ситуация не только в третьей версии движка, но и четвёртой: одинаковые юниты накапливаются в одном месте и их может дамажить один противник.
Не верю. Сейчас пойду проверю.
Такая проблема с лучами была бы критической и её немедленно бы исправили в минорной версии.
Когда сидел на гамаке, со стороны годоте слышал кудахты что Юай такой, такой Юай. Так удобно делать Юай. Сегодня залез в годоте в эти ваши контейнеры, сделал привязку к правой стене с сохранением аспект ратио. Уменьшаю окно - лезет влево. попробовал через марджин контейнер, попробовал через горизонтальный контйнер. Лезет влево да и ещё с этими наследованиям хуй поймешь что влияет, что не влияет. Плюннул я на эти ваши Юаи, напиал логику напрямую к спрайт2д как в гамаке, все работает как надо. Хуйня эти ваши юаи. Как только что-то более кастомное чем стандартную кнопку делать так сразу все летит нахер. Эти ноды ваши - хуйня полная. Хотел маску для спрайтов сделать... Маски делаются через Лайт2д. Хуан ебнутый? Как этим пользоваться?
На самом деле всё у меня сделано так, как задумано, и единственная проблема — это хитбоксы, которые наслаиваются и годот считает их одной и той же нодой. Враги действительно должны наслаиваться, атаковать синхронно, если накапливаются в одном месте. Главная проблема — Это одновременная смерть всех накопившихся персонажей от удара единственного противника.
>>09314
Метод play_ability() из >>09272 записан в _physics_process(), далее всё на скриншотах. Может из-за физ-процесса нода успевает захватить все объекты, которые коснулись луча?
>работа атаки.PNG
Тут я пометил цифрами 1 и 2 хронологию кода, по аналогии с постом >>09272.
> игру мечты
> На полном серьезе спрошу-что это для вас?
Игра-песочница с камерными локациями, геймплейными элементами выживалки и крафта. Главный герой путешествует на титанической махине сквозь бесконечную толщу, вспененную пустотными ячейками в которых живёт жизнь, когда дружелюбная, когда опасная. В пустотах ГГ находит материалы для починки и апгрейда своего толщехода, а так же для торговли ресурсами в цивилизованных пустотах.
Главная фишка игры: осевая и точечная гравитации. В толщеходе осевая, поскольку при его движении внутренняя кабина вращается, как Рама в книжке "свидание с Рамой", а в пустотах точечная инверсная гравитация, отталкивающая всё от центра к краям, но в центре ячейки невесомость и там может бесконечно долго уравновешенно зависать светящийся кусок первичной толщи, заменяя жителям ячейки солнце. Мало того, этот фрагмент толщи может вращаться, а вокруг него по орбите может вращаться кусок поменьше и из вторичных материй, делая жителям ячейки что-то типа смены дня и ночи, но не совсем. Если у тебя есть воображение, можешь себе представить, как на локации в центре висит OmniLight и освещает противоположный край, прямого света на твоей стороне нет, но есть отражённый. Зрелище неописуемое. Кто играл в игру "Вселенная наоборот с Толщеходами", тот никогда не забудет это явление природы. В нашей вселенной, пока что, в эту игру играл только я, и только в своей голове. Но когда нибудь, я встану с печи и сделаю её.
Игра организована как бесшовный мир в котором подзагрузка локаций спрятана за мини-игрой в кабине толщехода. Эта кабина по сути хаб игрока, где можно прокачиваться, перечитывать записки, строить планы и осуществлять навигацию по пустотам на карте. По сути это как космический симулятор, только в космосе-наоборот, где пространство - заполнено материей, а планеты - это пустоты в бесконечнозаполненном космосе.
>Это одновременная смерть всех накопившихся персонажей
Решительно непонятно почему у тебя так, при том что рейкаст обнаруживает только одну цель. То есть так может быть только если ты умышленно написал код который посылает рейкаст раз за разом.
Все расписывать не буду, а то палевно да и утащить могут. Скажем так это 3д экшн-слешер-рпг в песочнице с постройкой баз.
>Сейчас пойду проверю.
Проверил. Лол, у меня иногда на высокой скорости движения луча цели не регистрируются, но только когда они столпились кучей в одном месте...
Самое странное, что повышение TPS даже до 480 не исправило проблему полностью, только уменьшило.
>>09321
>Метод play_ability() _physics_process()
Ясно. Он вызывается 60 раз в секунду по умолчанию.
Делай после каждого попадания кулдаун:
>attack_ray.enabled = false
>cooldown_timer.start()
Без кулдауна атака вида "торчащая писька" будет делать 60 ударов в секунду, убивая толпу быстрее, чем ты можешь заметить. Т.е. тебе только кажется, что они умирают все сразу, на деле же - по очереди.
>Без кулдауна атака вида "торчащая писька" будет делать 60 ударов в секунду
В смысле, если у тебя в коде такая запись:
>func _physics_process():
> if ray.is_colliding(): play_ability()
>Tynan Sylvester. Designing Games: A Guide to Engineering Experiences
Там как раз (ближе к концу книги) описан процесс итеративной разработки, в котором вы сначала делаете кучу кривых прототипов из CSG нод.
>60 ударов в секунду
Не так. У меня для атаки есть аниматор и отдельный таймер. Каждый раз, когда Timer timeout, происходит один хит.
>таймер.PNG
и
>Эпизод три.png
Было некрасиво с моей стороны это умолчать. Я изначально наносил урон в момент Animator.is_stopped(), но получалось некрасиво, ведь враг получал урон, когда персонаж уже встал в стойку смирно после удара, поэтому в момент запуска анимации я запускал таймер с нужным (красивым) таймингом для урона и уже на сигнал timeout отнималось здоровье у target. Вот так вот...
>таймеры
Очень кривые и неточные. И к тому же работают мимо физики. Если у тебя есть анимейшон_плеер, добавь в анимацию атаки дорожку с вызовом функции, чтобы функция нанесения дамага вызывалась точно в нужный момент. Это гарантирует, что визуальная составляющая совпадёт с реальной, да к тому же даст супер-точный тайминг, который будет одинаков везде и всегда. В отличие от таймеров.
>когда Timer timeout, происходит один хит
Эмм... Вообще-то, кулдаун - это время "перезарядки". Таймаут таймера должен не наносить удар, а только разрешать совершение удара.
В частности, предлагаю сделать так:
>func _on_cooldown_timeout():
> attack_ray.enabled = true
Или, если хочешь более абстрактно:
> attack_ready = true
А дальше ты где-то проверяешь, можно ли атаковать.
>добавь в анимацию атаки дорожку с вызовом функции, чтобы функция нанесения дамага вызывалась точно в нужный момент
Это работает только для оружия с точечным уроном.
Если ты меч крутишь, он может нанести урон в любой момент, когда заденет врага - но после этого уйдёт на перезарядку, продолжая визуально вращаться.
>Маски делаются через Лайт2д.
Тебе шашечки или ехать?
>Плюннул я на эти ваши Юаи, напиал логику напрямую к спрайт2д как в гамаке
Лол.
>сделал привязку к правой стене с сохранением аспект ратио. Уменьшаю окно - лезет влево
Что за "стена"? Что ты хотел? В пейнте нарисуй.
В Godot действительно хороший GUI. Нужно просто разбираться в базе построения адаптивных GUI.
Это украли.
Вот теперь, когда очередной вор идей будет вас уговаривать изложить на двачах свою идею, потому что "ну да кому ты нужен со своими идеями", приведите в пример эту игру.
Помогите что тут не так!
Бля спасибо анон правда сработало!
ебусь с шарпом и мне пох, но быстрый гуглеж показал что
= это присваивание.
:= с явным приведением типа.
так как var collider у тебя не типизирован - приведение тут не знает к чему приводить. или укажи тип явно или юзай обычное присваивание.
Скорее всего у тебя код unreachable. То есть не исполняется, потому что ифы твои не соблюдаются.
Одно из двух условий, ведущих к твоему принту, не срабатывает. Либо ты action_pressed не нажимаешь, либо рейкаст не коллайдинг.
Алсо у тебя странная структура сцены. Нет причин, по которым рейкаст должен сидеть внутри аниматора, а аниматор внутри меша.
if на 22 или 24 не дает true, поэтому исполнение кода не доходит до print. Поставь брекпоинт на 22ую строку и запусти игру. Потом пошагово смотри что происходит и где обсер
>Поставить что?
https://www.gdquest.com/tutorial/godot/gdscript/debugging/
Метка в едиторе кода которая паузит выполнение кода пока ты не разрешишь идти дальше. Короче разберись что такое дебаггинг, без этого никак
Если они идентичны, то может отсылать сигнал из физ коллизии к хитбоксу и наносить урон?
Инстанс сцены сделал перед добавлением?
А бля, заработало. Но по поводу инстанса, как его правильно делать? У меня сейчас в переменную x_scene preload'ится сцена, потом в переменную x уже инстанс. Правильно или нет? Чет не хочется переменными засирать вот так.
Точно, спасибо!
Учись гуглить
https://github.com/godotengine/godot-demo-projects/blob/master/3d/rigidbody_character/player/cubio.gd#L30
Используют apply_central_impulse()?
Из документации:
https://docs.godotengine.org/en/stable/classes/class_rigidbody3d.html#class-rigidbody3d-method-apply-central-impulse
>An impulse is time-independent! Applying an impulse every frame would result in a framerate-dependent force. For this reason, it should only be used when simulating one-time impacts (use the "_force" functions otherwise).
В демке ошибка или в документации?
Дурачок, ты сообщения в консоли скрыл, лол. Нажми кнопки справа, там где иконки смешные и цифорки.
Экспортируем булевую переменную "can_do_damage". Меняем её значение в треке анимации. Наносим дамаг в физикс_процессе, опрашивая все попавшие хитбоксы. И это всё ещё лучше, чем таймеры.
>>09464
В документации всё верно, но речь о другой ситуации. Если ты хочешь прицепить к ригиду реактивный двигатель, то надо апплаить силу, а если разочек толкнуть - то импульс. Но если уж тебе всё равно придётся каждый кадр контролировать, то лучше снова импульс.
А вообще, лично я б в той демке импульс на дельту домножил, тогда он станет фреймрейто-независимым.
>>09379
>украли
Не украли, а реализовали раньше тебя.
Годаны, вопрос! А как узнать, что окно браузера с веб-версией игры свернулось/развернулось? На ЯИ мочераторы не пропустили, потому что при сворачивании музыка должна замолкать, а я чёт думал, что это и не определить никак. Нотификейшенов соответствующих нету вроде (ну, мобильные есть). Как?
>получаю я значит объект в переменную, а как мне взять ноду объекта
Если ты получаешь "игровой объект", то это и есть нода какого-то типа, но обязательно потомок Node.
>чтобы потом взять дерево сцены
Если у тебя код в потомке Node и находится внутри дерева сцены, то просто пиши get_tree() - это будет аналогично self.get_tree(). Дерево сцены у тебя всё равно единственное должно быть.
https://docs.godotengine.org/en/stable/classes/class_node.html#class-node-method-get-tree
>при сворачивании музыка должна замолкать
Лол, разве это не обязанность браузеров?
>реактивный двигатель
Он "реактивный" только если ты его используешь безусловно, то есть не проверяешь касание пола.
>Но если уж тебе всё равно придётся каждый кадр контролировать, то лучше снова импульс.
А что это даст? Я не понимаю. По логике, если ты перестаёшь прикладывать силу, объект всё ещё движется по инерции; если ты даёшь объекту один толчок, он движется только за счёт инерции...
Алсо, вот в физике есть сила трения - это force? Она ведь постоянно действует, пока есть контакт.
Я пока не копал, но там в любом случае можно написать кастомный js скрипт
https://godotforums.org/d/28241-html5-signal-when-page-recover-the-focus/4
Нахуй ты грубишь, быдло?
Запись вида:
>$RayCast3D
Является укороченной записью вида:
>self.get_node("RayCast3D")
И выполняется в рантайме, поэтому может вернуть ноду неизвестного заранее типа - в зависимости от того, что у тебя в сцене имеет имя "RayCast3D".
Оператор ":=" определяет тип переменной по типу присваиваемых данных до выполнения скрипта, поэтому ему нужно заранее знать, что ты пытаешься присвоить. Поскольку тип ответа от get_node() можно узнать только в рантайме, Godot ругается на этот код.
Хорошая практика - делать так:
>@onready var ray: RayCast3D = $RayCast3D
Тогда ты сможешь без проблем писать такой код:
>var collider := ray.get_collider()
Который будет понятнее, быстрее и точнее, а ещё будет проще отредактировать (все строки вверху).
Для упрощения добавления этого куска кода:
1. Зажми левую кнопку мыши на ноде в дереве.
2. Зажми ctrl и shift, пока удерживаешь ноду мышкой.
3. Перетащи ноду в желаемое место в редакторе кода.
4. Отпусти кнопку мыши.
Редактор сгенерирует строчку с @onready.
>>09396
>Толку
Толк в том, что переменная будет иметь тип.
>тайпкаст
>>09399
>:= с явным приведением типа.
Ребят, это не приведение типа. Приведение типа:
https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/gdscript_basics.html#casting
>так как var collider у тебя не типизирован - приведение тут не знает к чему приводить
Там совсем другой смысл, не путай ньюфага.
GDScript - последовательно типизированный:
https://en.wikipedia.org/wiki/Gradual_typing
Т.е. поддерживает и статическую, и динамическую типизацию одновременно, в зависимости от кода.
По умолчанию, когда ты не указываешь тип данных, типизация динамическая, пример:
>var a
>a = 5 # это int
>a = 2.5 # это float
>var text = "text" # это String
>text = true # это bool
Функции без указания типов принимают что угодно и возвращают что угодно либо ничего:
>func foo(bar = "bar"):
>foo(3) # так можно
Динамическая типизация имеет преимущества и недостатки, поэтому есть статическая типизация.
Статическая типизация включается, когда вы явно указываете типы или используете ":=", примеры:
>var a: int
>a = 5 # ок
>a = 2.5 # ошибка!
>var text: String = "text" # ок
>text = true # ошибка!
>func foo(bar: String = "bar") -> FooBar:
>foo(3) # ошибка!
Суть ":=" в том, чтобы не писать лишнего:
>var a
>a := 5 # это int
>a = 2.5 # ошибка!
>var text := "text" # это String
>text = true # ошибка!
>func foo(bar := "bar") -> FooBar:
>foo(3) # ошибка!
Т.е. задействуется статическая типизация, если это возможно (иначе будет >>09392), но при этом вам не обязательно явно прописывать тип данных.
Я не уверен на счёт "="/":=" в аргументах функций...
Запись вида:
>$RayCast3D
Является укороченной записью вида:
>self.get_node("RayCast3D")
И выполняется в рантайме, поэтому может вернуть ноду неизвестного заранее типа - в зависимости от того, что у тебя в сцене имеет имя "RayCast3D".
Оператор ":=" определяет тип переменной по типу присваиваемых данных до выполнения скрипта, поэтому ему нужно заранее знать, что ты пытаешься присвоить. Поскольку тип ответа от get_node() можно узнать только в рантайме, Godot ругается на этот код.
Хорошая практика - делать так:
>@onready var ray: RayCast3D = $RayCast3D
Тогда ты сможешь без проблем писать такой код:
>var collider := ray.get_collider()
Который будет понятнее, быстрее и точнее, а ещё будет проще отредактировать (все строки вверху).
Для упрощения добавления этого куска кода:
1. Зажми левую кнопку мыши на ноде в дереве.
2. Зажми ctrl и shift, пока удерживаешь ноду мышкой.
3. Перетащи ноду в желаемое место в редакторе кода.
4. Отпусти кнопку мыши.
Редактор сгенерирует строчку с @onready.
>>09396
>Толку
Толк в том, что переменная будет иметь тип.
>тайпкаст
>>09399
>:= с явным приведением типа.
Ребят, это не приведение типа. Приведение типа:
https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/gdscript_basics.html#casting
>так как var collider у тебя не типизирован - приведение тут не знает к чему приводить
Там совсем другой смысл, не путай ньюфага.
GDScript - последовательно типизированный:
https://en.wikipedia.org/wiki/Gradual_typing
Т.е. поддерживает и статическую, и динамическую типизацию одновременно, в зависимости от кода.
По умолчанию, когда ты не указываешь тип данных, типизация динамическая, пример:
>var a
>a = 5 # это int
>a = 2.5 # это float
>var text = "text" # это String
>text = true # это bool
Функции без указания типов принимают что угодно и возвращают что угодно либо ничего:
>func foo(bar = "bar"):
>foo(3) # так можно
Динамическая типизация имеет преимущества и недостатки, поэтому есть статическая типизация.
Статическая типизация включается, когда вы явно указываете типы или используете ":=", примеры:
>var a: int
>a = 5 # ок
>a = 2.5 # ошибка!
>var text: String = "text" # ок
>text = true # ошибка!
>func foo(bar: String = "bar") -> FooBar:
>foo(3) # ошибка!
Суть ":=" в том, чтобы не писать лишнего:
>var a
>a := 5 # это int
>a = 2.5 # ошибка!
>var text := "text" # это String
>text = true # ошибка!
>func foo(bar := "bar") -> FooBar:
>foo(3) # ошибка!
Т.е. задействуется статическая типизация, если это возможно (иначе будет >>09392), но при этом вам не обязательно явно прописывать тип данных.
Я не уверен на счёт "="/":=" в аргументах функций...
>>$RayCast3D
>Является укороченной записью вида:
>>self.get_node("RayCast3D")
Эээ, кажись перепутал, "$" равен просто get_node().
Т.е. должно быть возможно сделать так:
>get_parent().$Foo
>var node: Node...
>node.$Foo
Но это уже говнокод какой-то, не делайте так.
Там как то хитрее работает. В архитектуре буллета, которая использовалась, форс все равно надо каждый кадр применять. Разница, впроде в том, что add force ее интегрирует в общем растягивает на весь временной шаг, а add impulse нет. Наверное можно считать что force умножает на дельту сам, а impulse нет. Может быть я что-то не так понимаю, конечно.
Я хочу чтобы у меня деревья на фоне качались, допустим.
На экране 120гц они будут качаться в два раза быстрее чем на 60гц?
Ты че, ебанат? Не, ну это просто ахуеть можно. У вас в годоте все такие недоразвитые чтоли? Фпс буквально переводится как кадр в секунду. Каждый спрайт анимации - это кадр. У тебя на скрине 5 фпс. А это значит что у тебя за 1 секунду проиграется 5 кадров анимации. Ты реально на столько даун или че?
мимо в юнититред шел
> А это значит что у тебя за 1 секунду проиграется 5 кадров анимации
Теперь понятно, спасибо.
А я-то подумал это значит всю анимацию нужно проиграть за 5 экранных кадров.
И хуле ты такой злой? Мне когда надоест с годотом ковыряться, я и ваше говно скачаю и буду задавать тупые вопросы, готовься морально.
>AnimatedSprite2D
Эта нода нужна для покадровой анимации. При создании покадровой анимации определяется определённая частота кадров, например, в классических мультфильмах обычно 12 кадров в секунду, в отличие от 24 к/с у фильмов. Т.е. тебе необходимо указать в этом поле конкретное число кадров в секунду, которое использовал художник. А движок постарается обеспечить заданную частоту.
Или ты хочешь указывать в миллисекундах на кадр?
>120гц
>60гц
Чтоб ты знал, герц - это обозначение единицы частоты любого периодического процесса:
https://ru.wikipedia.org/wiki/Гц
Так что частота кадров - это, по сути, герцы. Отличие от частоты монитора в том, что частота обновления зависит от электроники самого монитора - монитор будет обновляться даже если процессор завис и не может передать новую пачку данных в монитор.
У игр есть главный цикл - game loop, он повторяет фиксированный набор действий с определённой частотой. Но бессмысленно генерировать картинку чаще, чем экран физически может показать, кроме того, могут быть проблемы с отображением, если отправлять данные в монитор, когда он в процессе обновления. Поэтому изобрели вертикальную синхронизацию. Игра, условно, тормозит главный цикл до частоты экрана, избегая лишней работы.
Но когда речь заходит об анимациях, там "частота кадров" вообще не связана с главным циклом игры и обновлениями монитора. Это абстрактная частота смены кадров в анимации - а сможет ли движок отобразить все кадры анимации и дойдут ли они до монитора вовремя это уже детали реализации.
> Но когда речь заходит об анимациях, там "частота кадров" вообще не связана с главным циклом игры и обновлениями монитора. Это абстрактная частота смены кадров в анимации
Да, как раз про это и был вопрос по сути, это там кадры анимации или экранные кадры игры.
>кастомный js скрипт
Ох, я пока не настолько шарю в ЖС. Тем более вместе с ЯИ.
В общем, пока сделал на NOTIFICATION_WM_FOCUS_IN/OUT. Конечно, сворачивание от потери фокуса это не отличит, но пусть и при обычной потере фокуса звук пропадает.
>>09500
Я хз насчёт 3д и буллетов, но вот в 2д форс если ты прикрепил, то он действует бесконечно, а импульс - разовая акция.
>>09472
>А что это даст?
Ну например, тебе надо преодолевать какие-нибудь силы, типа гравитации или трения. Тогда единичный импульс не прокатит - надо либо систематически их давать, либо силу привязывать.
>тебе надо преодолевать какие-нибудь силы, типа гравитации или трения
Так apply_force() не преодолевает эти силы. Векторы суммируются, и результат может слишком слабо отличаться от естественного (гравитация/трение), чтобы его хотя бы визуально заметить.
>если ты прикрепил, то он действует бесконечно
В четвёрке ввели constant_force для этого.
https://docs.godotengine.org/en/stable/classes/class_rigidbody2d.html#class-rigidbody2d-method-add-constant-force
https://docs.godotengine.org/en/stable/classes/class_rigidbody3d.html#class-rigidbody3d-method-add-constant-force
Это отличается от apply_force().
А все понял, сделаль
Вроде ничего сложного, и JS не понадобился, просто внутри гдскрипта обращаешься к объектам document хтмл странички. Вот я для 3.5 набросал, проверил в хроме и лисе, сворачивая/разворачивая, и переключаясь на другую вкладку.
onready var isHtml5 = OS.get_name() == "HTML5"
var js_vis_ch_callback
func _ready():
_if isHtml5:
__js_vis_ch_callback = JavaScript.create_callback(self, "_on_vis_change")
__var doc = JavaScript.get_interface("document")
__doc.addEventListener("visibilitychange", js_vis_ch_callback)
func _on_vis_change(_event):
_if isHtml5:
__var vis_str = JavaScript.get_interface("document").visibilityState
__var vis = (vis_str == "visible")
__#тут можно сделать emit своего сигнала
Спасибо за старания, анонче.
Твой код я использовать не буду (хотя...), потому что на нотификации потери фокуса норм работает (да и нехер игре работать не в фокусе, в любом случае). Но внимательно его перечитал и вкурил, как вообще осуществляется взаимодействие ГД и ЖС.
Я прост как раз последние пару дней поглощаю инфу по всяким жабаскриптам и похапэ, хочу себе сайт забацать. Вот, в общую копилочку знаний ляжет. Смогу по-взрослому заэмбеддить игру прямо в страницу сайта.
Так я себе сейчас написал, для своей яндексказуалки, а сюда вывалил, опенсорс же
Хз что то странное я переписал твой код и работает, но кроме самого первого раза. Может там фокуса какого то нет.
Не знаю, сейчас не могу посмотреть, да и 4-ка у меня нестабильно работает. Ну если у тебя задумка именно такая как написано, то при нажатии ты всегда в рамке значит можешь вообще без условия вызывать функцию.
закинь в тред ссылку как откроешь
Посмотри родителей, всех кто выше. Там запросто может оказаться элемент, съедающий в себя твой попап. Для понимания - если ты на весь экран растянешь прозрачный TextureRect, то все, что ниже него, получать инпут перестанет - он съест. Управляется это через mouse_filter
> Не украли, а реализовали раньше тебя.
Правильный ответ. Потому что идея не моя, а коллективная. Форс толщеходов здесь возник именно как реакция на споры о том, воруются ли идеи или нет. Так-то идее сто лет в обед, создавалась ещё на доброчане, на основе более ранних идей. Но фишка не в этом. Фишка в том, что реально ценные собственные идеи осторожный анон (я) вам тут в паблик не выложит. Потому что, как мы видим, через пару лет после форса толщеходов, клон идеи таки появился в стиме. И кто-то на нём зарабатывает прямо щас. Не миллионы, конечно, но какую-то копеечку поимел(и).
DigDug и Mr. Driller тоже на доброчане придумали?
А есть сурс модельки?
Никак вы, блять, не научитесь, что
>ценные идеи
не существуют. Если только это не быстрое разложение большого числа на простые множители. Идей в интернетах - лопатой греби. С развитием нейронок так тем более.
Ценой обладает лишь реализация. Вложенный труд: сценарий, код, графика, звук и т.д. Кто-то с толщеходами зарабатывает на реализации. А раз зарабатывает не миллионы, то и реализация, очевдно, не так уж хороша. Решительно ничего не поменялось бы, если бы если бы вместо этой идеи там был бы, например, ремейк Вангеров или что-нибудь по мотивам Рика и Морти.
Попытался расписать самому себе, что мне вообще требуется от контроллера... Думал, это поможет мне определиться, но что-то не получилось.
Вкратце, что мне нужно:
- физически точное взаимодействие с RigidBody3D, желательно без внезапного расколбаса всей сцены;
- физически точная траектория свободного полёта;
- но при этом ходьба должна быть ходьбой, а не виртуальными ракетами на спине персонажа;
- персонаж должен сопротивляться слабым толчкам RigidBody3D, а то выглядит как будто ты управляешь катящимся шариком, а не человеком с ногами.
В идеале, чтоб можно было безболезненно сменить физический движок, ибо судьба Godot Physics под вопросом, а у Jolt какие-то свои нюансы.
Главный вопрос: есть ли принципиальная разница? Возможно ли повторить одно и то же произвольное поведение на CharacterBody3D и RigidBody3D? Проще говоря, что именно я теряю, выбирая одно из двух?
>From Godot 4.2 onwards, new features for CPUParticles will not be accepted unless they have a counterpart in GPUParticles. However, contributions to bring CPU particles to feature parity are welcome.
Т.е. если что-то на GPU невозможно или слишком затратно делать, то этого вообще в движке не будет?
Проверил так же на веб-версии Не работает. Может всё таки я что-то делаю не так?
Если какие-то частицы невозможны на GPU, то на CPU это вообще будет бессымсленное слайдшоу.
имей ввиду что технически между этими двумя вариантами разницы нет. x_scene.instantiate() создает объект во "внешней" памяти и возвращает ссылку на него, которая сохраняется в "локальной" памяти скрипта и передается в add_child. разница только в том поименуешь ли ты эту ссылку(для дальнейшего использования или просто удобства) или нет
>Кто на четверке, можете проверить?
Я проверил, на 4.2.beta2 всё как у тебя.
При первом вхождении курсора мыши в область окна (popup) не генерируется событие 1010, которое генерируется только со второй попытки - видимо, это mouse_entered.
Это, очевидно, баг движка, но в рамках проекта, возможно, можно сделать костыль с событием 1002? Оно приходит одновременно и только с 1010, но почему-то дважды каждый раз.
Где можно прочитать названия всех событий по их индексам? Я не нашёл списка...
Скрипт на пикриле принадлежит PopupMenu.
В исходиках точно есть https://github.com/godotengine/godot/blob/c21c2706ad33c59295f6a3ac1e128db6fa7cce69/scene/main/node.h#L364
>>09671
Алсо, можете проверить, это происходит первый раз вообще, или первый раз с конкретным попапом. Можно, например, сделать два попапа и наводить на них. Или создавать каждый раз новый инстанс попапа. Я сам пока не могу, лапки.
Как я понял ЦПУ партикли останутся, но сложное на них недоступно из-за производительности. По сути это gles2-only партикли для древних мобилок.
глес2 не поддерживается с 4.0
Если у тебя "живой" персонаж с вестибулярным аппаратом, то чарактер. Если бездушный робот, которого должно мотылять по физике, то ригид. Если в поведении чарактера не хватает отзывчивости и нюансов, то берёшь и сам это всё прописываешь.
Ригид сам по себе не создан для ручного управления как такового. Да, можно, но не нужно, его фишка - расслабиться и плыть по течению. Чарактер же как раз для того и есть, чтобы каждый пук ему прописать.
>Вселенная наоборот с Толщеходами
Что ты тут делаешь? Ты же психовал, что готовый движок твоим толщеходам не подходит, и нужно писать свой велосипед с нуля, обязательно в 3D. Впрочем, я твой фанат. Когда ждать демку на Godot?
>Главная фишка игры: осевая и точечная гравитации
Это всё легко реализовать программно. Сложнее сделать достаточное количество графики для игры. Алсо, сомневаюсь, что эта "главная фишка" принесёт фан игроку. Как минимум эта вывернутая гравитация должна как-то влиять на геймплей.
>Если у тебя есть воображение, можешь себе представить, как на локации в центре висит OmniLight и освещает противоположный край, прямого света на твоей стороне нет, но есть отражённый. Зрелище неописуемое.
Если сфера достаточно большая (несколько километров в диаметре), то ты вряд ли разглядишь что-то кроме тумана на другой стороне (пар в воздухе рассеивает лучи, в играх такое нужно вручную делать). Непонятно, как это рендерить в таком масштабе - настолько удалённые объекты в играх обычно изображаются плоской текстурой/скайбоксом. Если же сфера маленькая, то будет... фигня какая-то, будто в большом помещении вращается прожектор, что в этом такого "неописуемого"?
>>09379
>Это украли.
Не украли и не у тебя. Это вялый клон этого:
https://store.steampowered.com/app/951440
Дата выпуска: 29 янв. 2019 (вроде была в EA)
- ездим на длинной бурилке под землёй.
https://store.steampowered.com/app/548430
Дата выпуска: 13 мая. 2020 (в EA была дольше)
- едем на бурилке копать руду в пещерах.
В отдельном режиме даже несколько этапов, на каждом этапе прыгаем в бурилку и едем глубже.
>приведите в пример эту игру
Чем тебе эта вторичная игра мешает? Ты почему-то не возмущаешься о двух играх выше, а вот сырая индюшатина у тебя вдруг вызывает бугурт. Почему?
>>09583
>Форс толщеходов
>Так-то идее сто лет в обед, создавалась ещё на доброчане, на основе более ранних идей.
При чём тут доброчан? Идее реально больше ста лет:
https://ru.wikipedia.org/wiki/Подземная_лодка
Про вывернутый наизнанку мир идеи наверняка ещё в древности были, с его твердым небесным куполом, который мифологические герои пытались пробить. Ну, мы это в прошлых тредах уже обсуждали.
>Фишка в том, что реально ценные собственные идеи осторожный анон (я) вам тут в паблик не выложит.
Главное, чтобы ты не превращал идеи в идею-фикс. В психушке с психами лежать не очень приятно. А как будет больно, когда идея окажется фигнёй...
>клон идеи таки появился в стиме
Даже если это клон, то уж точно не твоей идеи.
Там что-то совсем другое, судя по описанию.
>И кто-то на нём зарабатывает прямо щас
Это всё из-за порочного капитализма... Ящитаю, честный разработчик должен выкладывать игры бесплатно, разрешая игрокам донатить (но без принудительных микротранзакций, рекламы и механик, абузящих дофаминовую систему игрока).
>>09635
>Идей в интернетах - лопатой греби.
И большинство из них - полное говно.
>С развитием нейронок так тем более.
Реально новые идеи можно сгенерировать только генератором случайных чисел, которого в мозгах и нейронках нет (можно подавать на вход нейронки случайные числа, но это не заслуга нейронки).
>Ценой обладает лишь реализация.
Если идея говно, хоть как её реализуй - будет говно. Говно в красивой обёртке остаётся говном, так ведь? Поэтому ассетфлипы говно и ААА игры очень часто скатываются в говно в красивой и дорогой обёртке.
>А раз зарабатывает не миллионы, то и реализация, очевдно, не так уж хороша.
Конкретно у той игры проблема в том, что автор просит большую сумму за короткую инди-поделку, которую стоило бы бесплатно раздавать. Но если представить, что идея "ехать на огромной подземной механической змее и иногда долбить камни в огромных пустотах" - полное говно, тогда оно будет скучным независимо от реализации. Т.е. как ты чарактер контроллер не вылизывай и какие шейдеры не натягивай, всё равно будет унылое говно про линейную езду и гринд. А если делать не уныло, то это уже не "толщеходы" будут, а что-то совсем другое (вроде бы предлагали что-то в старых тредах, но он отказался). Если идея == механика и ты меняешь механику в реализации в угоду фана, то ты меняешь идею, а значит изначальная идея была унылой или неиграбельной.
Есть бесконечное множество унылых идей, которые остаются унылыми в любой реализации. Как наглядный пример - реальный космос максимально скучен, поэтому игры про реальный космос не взлетают - везде эти моментальные варпы, лазеры делают пыщ-пыщ и инопланетяне буквально на каждой планете в каждой системе, а ещё пираты и т.п. Есть всего одна "игра" про реальный космос, но это скорее вьювер, чем игра, там нет привычных игровых механик. Так и здесь, игра про "космос наоборот" может быть унылым говном на этапе идеи, независимо от реализации. Поэтому существует профессия геймдизайнера и за неё платят много денег, хотя задача геймдизайнера - найти рабочие идеи, которые принесут прибыль, а не убытки. У плохого геймдизайнера игра будет говном даже если все остальные члены команды - крутые профессионалы и реализация всех идей на 10/10.
>Вселенная наоборот с Толщеходами
Что ты тут делаешь? Ты же психовал, что готовый движок твоим толщеходам не подходит, и нужно писать свой велосипед с нуля, обязательно в 3D. Впрочем, я твой фанат. Когда ждать демку на Godot?
>Главная фишка игры: осевая и точечная гравитации
Это всё легко реализовать программно. Сложнее сделать достаточное количество графики для игры. Алсо, сомневаюсь, что эта "главная фишка" принесёт фан игроку. Как минимум эта вывернутая гравитация должна как-то влиять на геймплей.
>Если у тебя есть воображение, можешь себе представить, как на локации в центре висит OmniLight и освещает противоположный край, прямого света на твоей стороне нет, но есть отражённый. Зрелище неописуемое.
Если сфера достаточно большая (несколько километров в диаметре), то ты вряд ли разглядишь что-то кроме тумана на другой стороне (пар в воздухе рассеивает лучи, в играх такое нужно вручную делать). Непонятно, как это рендерить в таком масштабе - настолько удалённые объекты в играх обычно изображаются плоской текстурой/скайбоксом. Если же сфера маленькая, то будет... фигня какая-то, будто в большом помещении вращается прожектор, что в этом такого "неописуемого"?
>>09379
>Это украли.
Не украли и не у тебя. Это вялый клон этого:
https://store.steampowered.com/app/951440
Дата выпуска: 29 янв. 2019 (вроде была в EA)
- ездим на длинной бурилке под землёй.
https://store.steampowered.com/app/548430
Дата выпуска: 13 мая. 2020 (в EA была дольше)
- едем на бурилке копать руду в пещерах.
В отдельном режиме даже несколько этапов, на каждом этапе прыгаем в бурилку и едем глубже.
>приведите в пример эту игру
Чем тебе эта вторичная игра мешает? Ты почему-то не возмущаешься о двух играх выше, а вот сырая индюшатина у тебя вдруг вызывает бугурт. Почему?
>>09583
>Форс толщеходов
>Так-то идее сто лет в обед, создавалась ещё на доброчане, на основе более ранних идей.
При чём тут доброчан? Идее реально больше ста лет:
https://ru.wikipedia.org/wiki/Подземная_лодка
Про вывернутый наизнанку мир идеи наверняка ещё в древности были, с его твердым небесным куполом, который мифологические герои пытались пробить. Ну, мы это в прошлых тредах уже обсуждали.
>Фишка в том, что реально ценные собственные идеи осторожный анон (я) вам тут в паблик не выложит.
Главное, чтобы ты не превращал идеи в идею-фикс. В психушке с психами лежать не очень приятно. А как будет больно, когда идея окажется фигнёй...
>клон идеи таки появился в стиме
Даже если это клон, то уж точно не твоей идеи.
Там что-то совсем другое, судя по описанию.
>И кто-то на нём зарабатывает прямо щас
Это всё из-за порочного капитализма... Ящитаю, честный разработчик должен выкладывать игры бесплатно, разрешая игрокам донатить (но без принудительных микротранзакций, рекламы и механик, абузящих дофаминовую систему игрока).
>>09635
>Идей в интернетах - лопатой греби.
И большинство из них - полное говно.
>С развитием нейронок так тем более.
Реально новые идеи можно сгенерировать только генератором случайных чисел, которого в мозгах и нейронках нет (можно подавать на вход нейронки случайные числа, но это не заслуга нейронки).
>Ценой обладает лишь реализация.
Если идея говно, хоть как её реализуй - будет говно. Говно в красивой обёртке остаётся говном, так ведь? Поэтому ассетфлипы говно и ААА игры очень часто скатываются в говно в красивой и дорогой обёртке.
>А раз зарабатывает не миллионы, то и реализация, очевдно, не так уж хороша.
Конкретно у той игры проблема в том, что автор просит большую сумму за короткую инди-поделку, которую стоило бы бесплатно раздавать. Но если представить, что идея "ехать на огромной подземной механической змее и иногда долбить камни в огромных пустотах" - полное говно, тогда оно будет скучным независимо от реализации. Т.е. как ты чарактер контроллер не вылизывай и какие шейдеры не натягивай, всё равно будет унылое говно про линейную езду и гринд. А если делать не уныло, то это уже не "толщеходы" будут, а что-то совсем другое (вроде бы предлагали что-то в старых тредах, но он отказался). Если идея == механика и ты меняешь механику в реализации в угоду фана, то ты меняешь идею, а значит изначальная идея была унылой или неиграбельной.
Есть бесконечное множество унылых идей, которые остаются унылыми в любой реализации. Как наглядный пример - реальный космос максимально скучен, поэтому игры про реальный космос не взлетают - везде эти моментальные варпы, лазеры делают пыщ-пыщ и инопланетяне буквально на каждой планете в каждой системе, а ещё пираты и т.п. Есть всего одна "игра" про реальный космос, но это скорее вьювер, чем игра, там нет привычных игровых механик. Так и здесь, игра про "космос наоборот" может быть унылым говном на этапе идеи, независимо от реализации. Поэтому существует профессия геймдизайнера и за неё платят много денег, хотя задача геймдизайнера - найти рабочие идеи, которые принесут прибыль, а не убытки. У плохого геймдизайнера игра будет говном даже если все остальные члены команды - крутые профессионалы и реализация всех идей на 10/10.
>Если у тебя "живой" персонаж с вестибулярным аппаратом, то чарактер. Если бездушный робот, которого должно мотылять по физике, то ригид.
Я тебя не понимаю. У робота тоже должен быть "вестибулярный аппарат", а любое животное будет "мотыляться по физике", если расслабится или если воздействие внешних сил будет сильнее мышц. Весь вопрос в том, как совокупляться с движком физики.
>Если в поведении чарактера не хватает отзывчивости и нюансов, то берёшь и сам это всё прописываешь.
Как это сделать без доступа к физическому движку? Делаешь что-то, а движок начинает колбасить и всё выглядит так, будто вот-вот разлетится на части. Очевидно, нужно как-то встраиваться в движок, но у CharacterBody3D нет обработчика _integrate_forces.
>Ригид сам по себе не создан для ручного управления как такового. Да, можно, но не нужно, его фишка - расслабиться и плыть по течению.
Фишка RigidBody3D - он находится в пространстве физического движка, а не отдельным костылём. Расслабиться или нет - зависит от _integrate_forces. Персонаж, очевидно, должен иногда расслабляться.
>Чарактер же как раз для того и есть, чтобы каждый пук ему прописать.
Да, но он же будет конфликтовать с физикой. Его единственное преимущество - он может с каким-то шансом остановиться перед препятствием, если движок не заглючит и не начнёт колбасить.
Ну, ладно, персонаж. А корабль? Я часто замечал, что в играх корабли (морские, воздушные, да даже космические) - кинематики без реальной физики. Почему не сделать через RigidBody3D? Из моего опыта, RigidBody3D сам по себе хорошо моделирует корабль, проблема только в том, чтобы двигаться по его поверхности игровым персонажем.
Знаю про костыль "сделать невидимую StaticBody3D копию и бегать по ней вместо реального RigidBody3D", но это тоже проблемный подход и не подходит для сложной физической песочницы.
Хм... Я думаю, что если сделать два объекта - CharacterBody3D и RigidBody3D, и копировать все параметры с одного на другой в зависимости от состояния персонажа? Когда надо - ходить, а когда надо - мотыляться. Это независимо от рэгдолла.
У меня в школе по физике тройки за присутствие на уроках были, зачем я вообще в геймдев лезу...
>Если у тебя "живой" персонаж с вестибулярным аппаратом, то чарактер. Если бездушный робот, которого должно мотылять по физике, то ригид.
Я тебя не понимаю. У робота тоже должен быть "вестибулярный аппарат", а любое животное будет "мотыляться по физике", если расслабится или если воздействие внешних сил будет сильнее мышц. Весь вопрос в том, как совокупляться с движком физики.
>Если в поведении чарактера не хватает отзывчивости и нюансов, то берёшь и сам это всё прописываешь.
Как это сделать без доступа к физическому движку? Делаешь что-то, а движок начинает колбасить и всё выглядит так, будто вот-вот разлетится на части. Очевидно, нужно как-то встраиваться в движок, но у CharacterBody3D нет обработчика _integrate_forces.
>Ригид сам по себе не создан для ручного управления как такового. Да, можно, но не нужно, его фишка - расслабиться и плыть по течению.
Фишка RigidBody3D - он находится в пространстве физического движка, а не отдельным костылём. Расслабиться или нет - зависит от _integrate_forces. Персонаж, очевидно, должен иногда расслабляться.
>Чарактер же как раз для того и есть, чтобы каждый пук ему прописать.
Да, но он же будет конфликтовать с физикой. Его единственное преимущество - он может с каким-то шансом остановиться перед препятствием, если движок не заглючит и не начнёт колбасить.
Ну, ладно, персонаж. А корабль? Я часто замечал, что в играх корабли (морские, воздушные, да даже космические) - кинематики без реальной физики. Почему не сделать через RigidBody3D? Из моего опыта, RigidBody3D сам по себе хорошо моделирует корабль, проблема только в том, чтобы двигаться по его поверхности игровым персонажем.
Знаю про костыль "сделать невидимую StaticBody3D копию и бегать по ней вместо реального RigidBody3D", но это тоже проблемный подход и не подходит для сложной физической песочницы.
Хм... Я думаю, что если сделать два объекта - CharacterBody3D и RigidBody3D, и копировать все параметры с одного на другой в зависимости от состояния персонажа? Когда надо - ходить, а когда надо - мотыляться. Это независимо от рэгдолла.
У меня в школе по физике тройки за присутствие на уроках были, зачем я вообще в геймдев лезу...
>Если у тебя "живой" персонаж с вестибулярным аппаратом, то чарактер. Если бездушный робот, которого должно мотылять по физике, то ригид.
Вот смотри, >>09743
>RigidBody3D сам по себе хорошо моделирует корабль, проблема только в том, чтобы двигаться по его поверхности игровым персонажем.
Представь себя на морском корабле. Волны в море раскачивают корабль, корабль качается из стороны в сторону. Ты стоишь на палубе и тебя то поднимает, то опускает, но ты держишься на ногах, если качка не будет слишком сильной и если тебя не собьёт с ног катящаяся по палубе бочка. Как это сделать?
CharacterBody3D остановится, если на его пути будет RigidBody3D, но RigidBody3D не может сам по себе вытолкнуть со своего пути CharacterBody3D.
RigidBody3D может лежать на другом RigidBody3D, реалистично оказывая сопротивление согласно собственной массе, но если ты будешь двигать его посредством apply_force(), он будет "лететь" по палубе, толкая корабль как ракетный двигатель.
Если сделать скрытую StaticBody3D копию корабля, то это должна быть копия со всеми предметами на корабле, т.е. если по палубе катается бочка - где она должна на самом деле кататься? На StaticBody3D она не будет реагировать на наклон палубы, а если её там не будет, то она не сможет сбить с ног игрока.
Неужели я слишком многого хочу? Вроде банальная фича, а не какая-нибудь 4D/5D реальность...
> RigidBody3D не может сам по себе вытолкнуть со своего пути CharacterBody3D.
Просто регистрируешь столкновения и кодом двигаешь персонажа.
> двигать его посредством apply_force(), он будет "лететь" по палубе, толкая корабль как ракетный двигатель.
По идее так и должно быть, когда человек ходит по земле, он тоже ее двигает, весь вопрос тут в соотношении масс...
>Я тебя не понимаю.
Перефразирую. Если тебе надо всё по физике и довериться физ.движку, то ригид; если хочешь максимум контроля, то чарактер. Что тут непонятного-то?
>корабли - кинематики без реальной физики. Почему не сделать через RigidBody3D?
Но зачем? Но нахуя? У тебя в игре 100500 кораблей, они сталкиваются и взаимодействуют между собой? Гораздо проще поставить ему бесконечную инерцию и не ебать мозг с тем, что он там что-то не двигает: масса корабля несравнимо больше с любым объектом, который можно было бы поместить на палубу. А качку вообще анимировать, а не просчитывать физикой.
>Просто регистрируешь столкновения и кодом двигаешь персонажа.
RigidBody3D успевает столкнуться с CharacterBody3D раньше, чем срабатывает твой код сдвига. Движок автоматически выталкивает все RigidBody3D из препятствий, а на CharacterBody3D это не влияет.
>По идее так и должно быть, когда человек ходит по земле, он тоже ее двигает, весь вопрос тут в соотношении масс...
Не, тут проблема в другом.
Когда ты идёшь, ты отталкиваешься от опоры под ногами. Если эта опора достаточно лёгкая и гладкая, она может выскользнуть назад. Теперь представь себе опору в форме буквы L:
||
||<-X__
Ты идёшь налево и упираешься в стену, но ты не можешь сдвинуть стену, потому что она соединена с полом, а отталкиваешься ты от пола. Вот если бы вместо стены был шкаф, ты мог бы его сдвинуть, ведь шкаф не связан с полом (кроме силы трения).
На игровом физическом движке без дополнительных проверок ты будешь двигать стену ВМЕСТЕ с полом, если твой персонаж - RigidBody3D с apply_force(). Это большая проблема в игре, где вся суть геймплея в перемещении на корабле - ведь игрок может просто бежать в стену, игнорируя все остальные механики.
>RigidBody3D успевает столкнуться с CharacterBody3D раньше, чем срабатывает твой код сдвига
Либо обвесь Area3D чтобы срабатывало чуть раньше, либо смотреть в кишки физ движка и оттуда слать сигнал.
>ты будешь двигать стену ВМЕСТЕ с полом
Движок не позволяет выставить заведомо большую массу?
>Но зачем?
Затем, чтобы модель реалистично реагировала. Ой, слишком долго объяснять... Попробуй НАКЛОНИТЬ CharacterBody3D, если что-то ударилось в его УГОЛ - насколько я понимаю, там сложная формула, и ты предлагаешь это вручную писать? А в физическом движке все эти формулы уже есть на C++.
>масса корабля несравнимо больше с любым объектом, который можно было бы поместить на палубу
Ну, не корабль, а плот. Или обломок корабля. Какая разница, вот столкнулся ты и у тебя не корабль, а 25 обломков корабля, и все они отдельные RigidBody3D. Просчитывать на CharacterBody3D задолбаешься.
>качку анимировать, а не просчитывать физикой
Вот сам и делай игру с захардкоженной качкой. Это неинтересно и делать такую игру я не хочу.
Я хотел сделать игру в основном ради такой фичи, но что-то не получается настроить как хочется.
>Алсо, можете проверить, это происходит первый раз вообще, или первый раз с конкретным попапом. Можно, например, сделать два попапа и наводить на них.
Проверил: скопипастил первый попап и забиндил на другую кнопку мыши. Этот баг проявляется индивидуально для каждого попапа (окна).
>В исходиках точно есть
Ясно, спасибо.
Как я понимаю,
>NOTIFICATION_VP_MOUSE_ENTER
>NOTIFICATION_WM_MOUSE_ENTER
Практически идентичны в данном случае, но второй приходит дважды, а первый вообще не приходит в первый раз. Думаю, можно пока юзать WM?
А зачем тебе это событие в попапе? Интересно.
> RigidBody3D успевает столкнуться с CharacterBody3D раньше, чем срабатывает твой код сдвига.
Вот что я вспомнил
https://docs.godotengine.org/en/stable/classes/class_rigidbody3d.html#class-rigidbody3d-property-contact-monitor
https://docs.godotengine.org/en/stable/classes/class_rigidbody3d.html#class-rigidbody3d-property-max-contacts-reported
>Ну, не корабль, а плот
Тогда у тебя по нему бочки не катаются, слишком мелкий.
Ну то есть, либо у тебя здоровенная громадина, где можно по палубе погулять и такой ПОДНЯТЬ ГРОТ-БРАМСЕЛЬ!!11 Либо мелкое корыто, типа Моана. В первом случае
>что-то ударилось в его УГОЛ
означает либо пробоину, либо похеру. Во втором да, надо уже по физике всё делать, но там и пространства для перемещения по палубе сильно меньше.
Но если ты задумал вообще разрушаемость, то тут вообще хз. Тут уже придётся тебе самому изобретать реализацию.
Тащемта да, влом стирать написанное, но я подумал тут, что, раз уж ты хочешь что-то эдакое, чего никто не делал, то и реализовывать тебе придётся эдак, как никто не делал. Но вообще, обычно ригиды в любых игровых движках ведут себя по физике очень условно и с большими допущениями. Так что для продвинутой физики им в любом случае надо эту продвинутую физику писать. Такие дела.
Как по итогу такую систему удобнее всего реализовать? Сделать у каждого из них своё отдельное окошко, на все случаи взаимодействия и показывать в зависимости от ситуации? Ведь даже с одним и тем же нпс и предметом могут сейчас быть такие варианты взаимодействия, а позже станут другие. Или сделать одно окошко, но чтобы его элементы подключались и отключались как то с помощью скриптов и сигналов? Допустим, если взаимодействуешь с нпс, в окошко заносятся данные для вариантов из его скрипта, ну или что-то такое. Вобщем, надеюсь, понятно объяснил.
Удобнее делать как умеешь и потом подгонять под свои нужды. В любом случае ты динамически заполняешь окошко вариантами взаимодействия. Главное чтобы при создании новой сущности не пришлось дублировать код, а прост новые взаимодействия сделать.
Наверно так.
Я бы сделал каждому объекту отдельную сцену с элементами управления, типа "var scene: PackedScene",
а при взаимодействии отдавал её в интерфейс и там инстансил. Но только при условии, что там прям уникальные способы взаимодействия, для которых нужны уникальные элементы управления. А если просто разные надписи на кнопках - отдавал бы интерфейсу массив с подписями; сколько элементов в массиве, столько кнопок и показывать; обратный сигнал отдаёт номер нажатой кнопки.
Роялти завезут за установку каждой копии.
> я только месяц как в движок вкатился
Значит не слушай этого, спокойно не торопясь изучай движок.
>>09903
> А что там прям такого крутого и важного?
Ничего. Это местный мем, основанный на пьесе какого-то там драматурга: "В ожидании Годота". Годаны оправдывают свою прокрастинацию тем, что вот типа, версия N+1 еще не вышла, вот выйдет в ноябре, тогда-то наконец я и начну делать свою игру мечты.
Ты уже догадываешься, что те же самые годаны скажут в ноябре. Они начнут ждать версию N+2
4.2 было обоснованным предположением, потому что 3.2 уже был пригоден доя продакшна по сравнению с 3.0, а на 3.4+ уже можно полноценные игры делать
Но тут решили ускорить как релиз 4.0 под GDC с резанием и откатом фич, так и сейчас цифры быстро накручивают.
Иными слова 4.2 имело бы смысл ждать, если бы релиз 4.0 был полноценным, а не альфой. А так, получается, надо ждать 4.2+2. Не в смысле ждать ради ждать, а в смысле объективного готово/неготово
Лучше уж через код.
Делаю на LTS 3. На моей комбинации некроноута/линукса/видеодрайвера четверка зависает примерно через 2 минуты работы.
Меня все устраивает. Я делаю низкотребовательные игры которые потом идут даже у бомжей.
Вполне заебатые игры на некрожелезе делают, и вполне заебатые игры на некрожелезе работают. Тем более годот это не юнити, который включается по полчаса.
Линукс быстро работает без ссд, ну и заодно тестируем для тех у кого его нет.
>последняя версия движка вылетает через две минуты
Тем хуже для нее.
1. Делаеш прототип на гдскрипте.
2. Переписываеш критические участки на РАСТЕ.
Как я выяснил за прошедшую неделю, ржавый критически хорош! Системный язык, с абстракциями нулевой стоимости, внешне гдскрипт похож на него (я даже начинаю думать, что кое что Хуан потянул из ржавого). На гитхабе есть готовый полнофункциональный гд-экстеншон, который джаст воpкс.
Дискасс.
Меня пока устраивает с++, потенциально с перекатом в cpp2 или zig.
Это правда. Но у дедов было определенное преимущество, в виде низкой конкуренции и неосвоенных ниш и жанров, ну и то, что калькуляторы были около-АА железом.
Отцы тоже делали. И ты делой.
Подводный в том, что на ноду ты можешь вешать доп скрипт, а здесь уже только этот может быть. И длинная подпись.
Полноценную ноду можно через свой аддон делать, но там и бойлерплейта побольше написать надо, и для отладки перезапускать аддон надо (но для этого есть аддон plugin refresher)
>а здесь уже только этот может быть
Здесь точно так же можно прикрепить скрипт ("расширить скрипт"), главное в нём написать extends my_super_mega_class.
Я подумал, и пришел к выводу, что все дело в удобстве воркфлоу
Если ты удаляешь с обычной ноды скрипт, то нода все равно сохраняет поведение по умолчанию. В случае с твоей, слетает совсем и надо выставлять твой базовый скрипт.
Если ты добавляешь к обычной ноде скрипт, то там по умолчанию уже все отнаследовано от той, что выбрана в инспекторе. В случае с твоей, надо выбирать из списка классов в окошке создания скрипта.
Еще индикация. В случае обычной ноды, листочек есть/листочка нет/листочек серенький. В твоем случае, они всегда будут, и надо читать какой же именно скрипт в названии.
> Instance parameters not implemented for 2D shaders.
ну блин
>class_name State extends Node
Зачем так делать? Там нет ни _process, ни _input, ни других коллбеков движка. Зачем тогда Node?
Пикрил меня вообще выводит из себя - будто бы яждизайнер будет каждый день эти Idle/Run/Air мышкой по дереву таскать, иначе зачем оно надо?
На вопрос о противоречии практикам Godot он написал, что эти объекты специально сделаны с высоким зацеплением - мол, они не будут нужны никому, кроме Player. Но тогда зачем вообще ноды?
Кроме того. Вот хочу сделать состояние, в котором требуется _integrate_forces с аргументом. Конечный автомат из примера по ссылке принципиально не позволяет такое провернуть...
Короче, я придумал отправлять сигналы из главной ноды, на которую цепляется нода-конечный автомат, у которой есть массив Resource-состояний, которые проверяют наличие желаемых сигналов и цепляют на них свои собственные обработчики. Нормально?
Примерно такой код:
>if owner.has_signal(&"integrate_forces"):
> owner.integrate_forces.connect(_on_integrate_forces)
Так можно писать какие угодно состояния на какие угодно события, не меняя скрипт state_machine.gd.
>Так можно писать какие угодно состояния на какие угодно события, не меняя скрипт state_machine.gd.
А зачем менять его? Он же просто обрабатывает переключения между состояниями.
>Он же просто обрабатывает переключения между состояниями.
Ты код в том примере по ссылке смотрел?
https://github.com/gdquest-demos/godot-design-patterns/blob/main/godot/StateMachine/StateMachine.gd
># The state machine subscribes to node callbacks and delegates them to the state objects.
>func _unhandled_input(event: InputEvent) -> void:
> state.handle_input(event)
>func _process(delta: float) -> void:
> state.update(delta)
>func _physics_process(delta: float) -> void:
> state.physics_update(delta)
Честно говоря, навскидку в первый раз я тоже что-то подобное планировал, но потом вспомнил, что ряд коллбеков присутствует только у определённых нод. Поэтому конечный автомат из этого примера совсем не универсальный, к сожалению.
Ну ок. Правда так и не понимаю почему ты не можешь добавить _input или _process прописав так же как:
> func _unhandled_input(event: InputEvent) -> void:
> state.handle_input(event)
А с _integrate_forces не работал, так что хз.
>почему ты не можешь добавить
>_integrate_forces
Потому что он есть только у RigidBody3D/RigidBody2D.
Алсо... С таким подходом тебе придётся добавлять новые затычки во все уже существующие классы состояний. Не очень-то гибко, не так ли?
>Алсо... С таким подходом тебе придётся добавлять новые затычки во все уже существующие классы состояний. Не очень-то гибко, не так ли?
Зачем? Затычка(с pass) идет в класс state от которого наследуются остальные состояния. Если в состоянии используется функция - прописываю реализацию в нужном классе. Если нет - автоматом юзается родительская затычка
Ты слишком зациклился на морских кораблях. Они были только как пример качающейся платформы; в сущности, это декорация, а ты начал обсуждать её, игнорируя реальную проблему (движения игрока).
Я пытаюсь сделать песочницу, в которой игроку требуется строить транспорт, относящийся к дирижаблям, по-английски гуглить fantasy airship.
На практике это означает, что:
- игрок может построить корпус любой формы, и от положения и массы блоков зависит центр тяжести;
- игрок должен цеплять к корпусу шары и двигатели, которые поднимают корабль в воздух, и от... всех их параметров зависит, перевернётся ли твой корабль вверх дном и переживёт ли повреждения.
К сожалению, большинство виденных мной игр тупо используют кинематик боди, лишая игру динамики физической симуляции и, как следствие, части фана.
Я уже делал прототипы. RigidBody3D подходит как нельзя лучше, решая 99% вопросов автоматически. Проблемы только в том, чтобы игрок мог спокойно перемещаться по палубе, не создавая конфликтов с физикой и не слетая с палубы от малейшего чиха.
Впрочем, я вчера вечером почти решил их:
1. Конфликты физики решаются в 4.x очень просто, достаточно снять галочку в физических слоях у тела персонажа и тогда RigidBody3D перестают на него реагировать. Я решил, что лучше пожертвовать возможностью "толкать телом", чем костыли. Можно потом толкание вернуть одной строчкой, если надо...
2. В _integrate_forces можно взять вектор скорости в точке столкновения и сложить его с собственным вектором скорости. Работает, но не до конца: по непонятной пока причине персонаж продолжает понемногу съезжать, но только когда опора меняет направление движения. На вращающейся опоре постепенно съезжает от центра к краю...
3. Я даже сделал так, что персонаж смотрит в одну сторону относительно вращающейся платформы; без этого выглядело будто он на месте вращался.
А потом у меня ПК заглючил, пришлось выключить. На самом интересном месте, представляете?
>>плот
>по нему бочки не катаются, слишком мелкий.
Ещё как катаются, если у тебя плот как в Raft.
>либо у тебя здоровенная громадина
>Либо мелкое корыто
>означает либо пробоину, либо похеру
https://en.wikipedia.org/wiki/Splitting_(psychology)
>если ты задумал вообще разрушаемость
Это должно быть не так сложно, если твой объект составлен из множества блоков (CollisionShape3D). Конечно, разрушение нереалистичное, но вполне достаточно, чтобы игровая механика работала.
>хочешь что-то эдакое, чего никто не делал
Есть несколько песочниц, где, как мне по ощущениям представляется, RigidBody3D. Глупо разрабатывать столь сложный велосипед, когда твоё корыто физически вполне обычный RigidBody3D.
Песочницы с транспортом делятся на:
- унылое говно на деревянных кинематиках;
- прикольный кубач с физикой на ригидах;
- хардкорная симуляция ирл материалов.
Первое не хочу, третье не смогу, второе в самый раз.
Ты слишком зациклился на морских кораблях. Они были только как пример качающейся платформы; в сущности, это декорация, а ты начал обсуждать её, игнорируя реальную проблему (движения игрока).
Я пытаюсь сделать песочницу, в которой игроку требуется строить транспорт, относящийся к дирижаблям, по-английски гуглить fantasy airship.
На практике это означает, что:
- игрок может построить корпус любой формы, и от положения и массы блоков зависит центр тяжести;
- игрок должен цеплять к корпусу шары и двигатели, которые поднимают корабль в воздух, и от... всех их параметров зависит, перевернётся ли твой корабль вверх дном и переживёт ли повреждения.
К сожалению, большинство виденных мной игр тупо используют кинематик боди, лишая игру динамики физической симуляции и, как следствие, части фана.
Я уже делал прототипы. RigidBody3D подходит как нельзя лучше, решая 99% вопросов автоматически. Проблемы только в том, чтобы игрок мог спокойно перемещаться по палубе, не создавая конфликтов с физикой и не слетая с палубы от малейшего чиха.
Впрочем, я вчера вечером почти решил их:
1. Конфликты физики решаются в 4.x очень просто, достаточно снять галочку в физических слоях у тела персонажа и тогда RigidBody3D перестают на него реагировать. Я решил, что лучше пожертвовать возможностью "толкать телом", чем костыли. Можно потом толкание вернуть одной строчкой, если надо...
2. В _integrate_forces можно взять вектор скорости в точке столкновения и сложить его с собственным вектором скорости. Работает, но не до конца: по непонятной пока причине персонаж продолжает понемногу съезжать, но только когда опора меняет направление движения. На вращающейся опоре постепенно съезжает от центра к краю...
3. Я даже сделал так, что персонаж смотрит в одну сторону относительно вращающейся платформы; без этого выглядело будто он на месте вращался.
А потом у меня ПК заглючил, пришлось выключить. На самом интересном месте, представляете?
>>плот
>по нему бочки не катаются, слишком мелкий.
Ещё как катаются, если у тебя плот как в Raft.
>либо у тебя здоровенная громадина
>Либо мелкое корыто
>означает либо пробоину, либо похеру
https://en.wikipedia.org/wiki/Splitting_(psychology)
>если ты задумал вообще разрушаемость
Это должно быть не так сложно, если твой объект составлен из множества блоков (CollisionShape3D). Конечно, разрушение нереалистичное, но вполне достаточно, чтобы игровая механика работала.
>хочешь что-то эдакое, чего никто не делал
Есть несколько песочниц, где, как мне по ощущениям представляется, RigidBody3D. Глупо разрабатывать столь сложный велосипед, когда твоё корыто физически вполне обычный RigidBody3D.
Песочницы с транспортом делятся на:
- унылое говно на деревянных кинематиках;
- прикольный кубач с физикой на ригидах;
- хардкорная симуляция ирл материалов.
Первое не хочу, третье не смогу, второе в самый раз.
>коллишн в виде капсулы и несколько больше меша, то курсор меняется до наведения непосредственно на персонажа.
Сделай отдельную Area2D/Area3D и отключи ей всё лишнее, чтобы она не мешала игровым объектам.
Ареа3д требует колишн шейп как ребенка, а мне без него нужно, потому что он статичный.
Я так делал, "изобрёл" такой подход независимо от Гдквеста. Пробовал стейты внутри скрипта, пробовал стейты-ресурсы в массиве. Стейты-ноды удобнее всего. 2д-ноды - вообще супер, в них ещё и графические эффекты впихнуть можно. Щас прихожу к тому, чтобы не опрашивать их стейт-машиной каждый кадр, а по необходимости добавлять в сами ноды _процесс (ну или _физикс_процесс). Стейт-машина просто выбирает самого достойного среди стейтов (каждый стейт сам подсчитывает, насколько он подходит для той или иной ситуации) и ставит ему галочку "активен". Ну и для реализации переходов вызывает функции exit_state(next_state) и enter_state(prev_state), чтобы стейт мог сам определять свои переходы.
И да, отдельная стейт-машина не нужна. Персонаж это и есть стейт-машина. Отдельно от персонажа она не имеет смысла; персонаж без стейт-машины тоже не нужен; внутри него прочий код - это разве что обработка хитпоинтов и управляющих команд.
>мышкой по дереву таскат
Очень удобно и наглядно. Сразу видно, какой персонаж что умеет. А ещё можно собрать сцену базового перса и всех остальных наследовать от него. А ещё можно на ходу добавлять/убирать способности.
>колишн шейп
>он статичный
Ты можешь менять его параметры динамически или сделать несколько шейпов и переключать их. Да, это ударит по производительности, но что ты хотел?
Если ты хочешь пиксельную точность выбора, то придётся проверять цвет пикселя под курсором. К примеру, можешь рендерить персонажей сплошной заливкой одним цветом на невидимом Viewport, а затем проверять цвет пикселей, координаты которых совпадают с тем, что видит игрок... Опять-таки, это серьёзно ударит по производительности.
Спроси себя сам, нужна ли тебе избыточная точность выделения? Если юниты не наслаиваются друг на друга, то не всё ли равно, как их выделять? Как я понимаю, в стратегиях чаще рамочкой выделяют...
>он статичный
>>10129
>можешь менять его параметры динамически или сделать несколько шейпов и переключать их
Ещё придумал: если у тебя 3D модель со скелетом, то возможно подвесить на каждую кость отдельный CollisionShape3D в одном Area3D или разные Area3D. Тогда они будут повторять силуэт персонажа с любыми анимациями автоматически.
А если нужен рэгдолл на каждого перса? Я видел ещё физический скелет, он на каждую кость добавляет коллизию. Можно конечно добавить коллизию на основные кости, таким образом и выделение будет точнее, и коллизия в целом. И к тому же пули, летящие в персонажа смогут пролетать между ног, под руками, у головы, не задевая ее коллизию.
>>10130
Пока это описывал, ты уже отписался.
>Стейт-машина просто выбирает самого достойного среди стейтов (каждый стейт сам подсчитывает, насколько он подходит для той или иной ситуации)
Обсуждали же, это у тебя Utility AI.
>Отдельно от персонажа она не имеет смысла
Конечный автомат - абстрактная система, так что универсальный конечный автомат можно было бы использовать в разных частях игры в роли сложной ООП замены конструкции "match state:".
>Очень удобно и наглядно. Сразу видно, какой персонаж что умеет. А ещё можно собрать сцену базового перса и всех остальных наследовать от него. А ещё можно на ходу добавлять/убирать способности.
Всё то же самое можно через инспектор реализовать.
Единственное преимущество нод - это стандартные коллбеки движка, которых у ресурсов нет. Но их несложно пробросить, если очень нужно.
Алсо, зону инспектора можно кастомизировать в tool-скриптах, создавая свои кнопки и разделы...
В Godot 3.x с Bullet на 4-х ядерном ЦПУ 2007-го года мне удавалось иметь 1000+ CollisionShape в одном RigidBody. И ещё удавалось что-то около 12000, если размещать их в разных телах. Дальше начинались просадки сильно ниже 75 ФПС. Точно не помню... Может, это даже не из-за физики, а из-за дроуколов, поскольку больше 10к-12к дроуколов всё тормозит.
Ну, набросай стресс-тест (сколько объектов нужно создать, чтобы игре поплохело), убедишься сам.
Вероятно глупый вопрос, но как к отдельной кости добавить CollisionShape3D? У меня есть Skeleton3D, в инспекторе показаны кости, а дальше?
Напрямую никак. Можно через BoneAttachment попробовать, еще есьь PhysicalBones которые для рэгдоллов используют
Это в любом случае будет парадлельная скелету система нод
Получается, что по иерархии CollisionShape3D стоит ниже кости, которая стоит ниже Skeleton3D, который стоит ниже CharacterBody3D и эти шейпы не считаются телом за собственные что-ли. То есть не влияют они на столкновения от слова совсем. :\
Кстати, ты не знаешь, что с IK?
https://docs.godotengine.org/en/stable/classes/class_skeleton3d.html
>To setup different types of inverse kinematics, consider using SkeletonIK3D, or add a custom IK implementation in Node._process as a child node.
https://docs.godotengine.org/en/stable/classes/class_skeletonik3d.html
>Deprecated. This class is deprecated, and might be removed in a future release.
Skeletonik? Скелетоник, лол!
Оуп... Прошу прощения, это моя дурная голова забыла включить animate_physical_bones.
>В 3д с кинематик боди можно как-нибудь одностороннюю коллизию провернуть?
Что ты имеешь в виду?
1. Чтобы объект сталкивался с чем-то, а это что-то с ним не сталкивалось?
2. Чтобы можно было пройти в одну сторону, но нельзя было в другую?
Опиши задачу подробнее, если хочешь ответ.
>Как такую систему реализовать?
Рекомендую следующий подход к разработке:
1. Сначала быстро набрасываешь фичу совершенно любым способом, лишь бы быстрее был результат.
2. Тестируешь эту фичу с точки зрения геймплея, экспериментируя с параметрами. Баги, тормоза и украшательства ни в коем случае не трогаешь.
3. Только когда отполируешь фичу геймплейно, оцениваешь работу с точки зрения технической поддержки, производительности и т.д.
4. При необходимости пределываешь с нуля. Не беспокойся, теперь ты точно знаешь, что нужно реализовать и что оно будет работать правильно.
Переписывать уже готовое всегда проще, чем изобретать что-то с нуля, поэтому оптимизировать нужно в первую очередь скорость изобретательства.
Наглядный пример: когда требуется что-то быстро вывести на экран, ПРОСТО втыкаешь Control-ноду в любое удобное место сцены и всё. Главное потом не забыть убрать всё лишнее/переделать начисто.
>2. Чтобы можно было пройти в одну сторону, но нельзя было в другую?
Это, да. Я придумал способ вида "с одной стороны добавляем area, при входе в нее добавляем исключение с кинематиком, позволяя через него проходить", но как-то коряво это все. Хотелось бы проще. Поставить галку "one way collision" и указать нормально, где коллизия работает.
>отдельно нужно снимать сигналы
Не нужно отдельно. Просто в окне подключения сигнала, в поле ввода имени функции-обработчика, копипастишь одно и то же название. Тогда все сигналы всех костей будут дёргать одну и ту же функцию. Тебе же не нужно эти кости различать - тебе достаточно знать, что сигнал пришёл от какой-то кости конкретного персонажа. В случае, если различать всё-таки нужно, можно нажать кнопку дополнительных параметров и добавить какой-нибудь аргумент, например, int с номером кости или даже StringName с текстовым названием (они внутри движка индексируются и работают как сравнение чисел, добавили в четвёрке из-за того, что многие вещи в движке требуют указания текстовых строк, что с обычными String слишком затратно из-за сравнения строк посимвольно; главное не забывать символ & перед константами: &"текст").
Точно! Спасибо.
А ты не перемудриваешь? Тебе точно надо к костям коллайдеры? Не просто так в играх делают капсулу, а все антмации отдельно.
>Не просто так в играх делают капсулу, а все антмации отдельно.
А ещё в играх делают регдолл и даже такую штуку, как правдоподобная симуляция мышц (GTA IV).
Но это касательно движений. Для определения попаданий в шутерах используют отдельные коллизии, повторяющие части тела персонажа.
Вообще, капсула - это просто самая простая коллизия, чтобы побыстрее начать двигать персонажа. Продвинутый контроллер персонажа может быть обвешан кучей коллизий под разные ситуации...
Короч, не мешай полёту фантазии анона. А то сейчас он сделает всё правильно и исчезнет с радаров.
>Хотелось бы проще. Поставить галку "one way collision" и указать нормально, где коллизия работает.
Вроде бы такого нет и не было. Была какая-то глючная коллизия типа "плоскость", но её то ли удалили, то ли переделали и она продолжает глючить, не знаю. Сама идея односторонней коллизии весьма специфична, особенно для 3D игр, вот для 2D что-то есть.
>с одной стороны добавляем area, при входе в нее добавляем исключение с кинематиком, позволяя через него проходить
Я погуглил, в интернете предлагают ещё такое: при вхождении в Area3D проверять, с какой стороны входит игрок, и запрещать ему двигаться дальше, к примеру, придавать ему импульс в обратную сторону.
А для чего тебе это нужно? Вертикальная дверь или горизонтальная платформа? Интересно.
Вот velocity - это вектор скорости, он есть у RigidBody. А что на счёт ускорения? Ускорение - это изменение скорости за момент времени, так что вручную его можно измерить только двумя проверками velocity. Разве нет никакой встроенной переменной? Мне кажется это странным, т.к. знать ускорение важно в некоторых ситуациях, например, чтобы персонажи в автобусе падали, если автобус врежется в стену.
Главное что физический движок где-то внутри манипулирует ускорением объектов, разве нет?
НЕТ, мне не сложно сделать это:
>if last_velocity.distance_to(velocity) > max_accel: ...
Я просто не понимаю, почему нет отдельного поля.
>Collision Pairs 7736
Попробуй очистить collision_mask у всех костей. Тебе же нужно только попадание мышки проверять?
https://docs.godotengine.org/en/stable/classes/class_collisionobject3d.html#class-collisionobject3d-property-collision-mask
Это ведь на пустой сцене, где больше ничего нет?
Очистил, как ты и сказал. Упало с 7к до 1322.
Да, пока только проверка попадание мышки, но никаких особых экспериментов с физикой не планируется.
Сцена практически пуста, не считая с десяток простых объектов типа коробок и тд.
>Вот velocity - это вектор скорости, он есть у RigidBody. А что на счёт ускорения?
Ускорение это действие какой-либо силы, т.е. отдельный вектор ускорения, который умножается на вектор скорости.
> т.к. знать ускорение важно в некоторых ситуациях, например, чтобы персонажи в автобусе падали, если автобус врежется в стену.
Ебать ты говодя. Перечитай школьную физику.
>А что там прям такого крутого и важного?
На официальном сайте всё подробно перечисляют:
https://godotengine.org/article/dev-snapshot-godot-4-2-beta-1/
>>09954
>тут решили ускорить как релиз
>так и сейчас цифры быстро накручивают.
Это неправда, они не накручивают.
Вкратце, раньше дедлайнов не существовало - когда хочешь, добавляешь фичу, а потом баги ищешь хрен знает сколько времени. Из-за этого версии долго ждать приходилось, пока всё допилят...
Сейчас ввели дедлайны. Если я правильно помню, разработчикам даётся 3 месяца на введение новых функций в версию, а затем месяц на поиск багов, когда любые новые функции вводить запрещено (остаются ждать следующую версию).
Так что теперь новые версии с новыми фичами выходят быстрее и надёжнее, чем раньше. Всё ненадёжное и недоделанное ждёт следующего окна.
Это здорово, что хватает разработчиков на такую высокую скорость. Большинство опенсурс движков не получают новых функций годами.
Подчёркиваю, речь идёт о минорных версиях, т.е. версиях с новым функционалом. Это не патчи багов. Патчи выходят отдельно по мере возможности.
Так что вы радоваться должны. Для вас стараются...
>Ускорение это действие какой-либо силы
Ускорение - это быстрота изменения скорости.
В конечном итоге у любого физического тела есть вектор ускорения для каждого тика движка... Но его вычислять вручную приходится, а для этого нужно где-то хранить предыдущее значение velocity.
>Перечитай школьную физику.
a = ∆v / ∆t, что ещё тебе напомнить?
>>10180
>Упало с 7к до 1322.
Теперь движок делает меньше лишних проверок.
> у любого физического тела есть вектор ускорения для каждого тика движка
А есть ли? Движок просто для каждого объекта на каждом тике помножает дельту на скорость, движку не надо знать ускорение
> Ускорение - это быстрота изменения скорости.
Ускорения это сила, понимаешь? Сил может быть несколько.
Какие, блядь, вычисления вручную? Что ты несешь вообще? Газани и школьную физику изучи.
> a = ∆v / ∆t, что ещё тебе напомнить?
Какие ускорения и когда по-твоему испытывают тела в автобусе? По-твоему они ускоряются, когда автобус останавливается? Какая сила действует на них при ускорении?
>Ускорения это сила
Кончай троллить.
>По-твоему они ускоряются, когда автобус останавливается?
Конечно. Ускоряются в сторону лобового стекла относительно автобуса и в сторону заднего стекла относительно асфальта под колёсами автобуса.
>Какая сила действует на них при ускорении?
Пассажир движется со скоростью автобуса и в момент резкой остановки (ускорения автобуса до полной остановки) продолжает движение, замедляясь об препятствия. У него ускорение, заключающееся в быстром снижении скорости.
У тебя не укладывается в голове, что "торможение" равносильно "ускорению" в бытовом смысле?
480x360, 0:05
>>Ускорения это сила
>Кончай троллить.
>>По-твоему тела ускоряются, когда автобус останавливается?
> Конечно.
Этого гододика уже не спасти...
Ты кормишь дефрагментатора стека. Он не первый раз в треде разводит свой троллинг про физику.
Сам себе отвечаю. Да, ест. Mouse Filter Pass почему-то не помогает передать драг выше. Помогает только игнор.
Все, разобрался. Надо не обычные баттоны использовать, а TouchScreenButton.
360x202, 0:06
запуск из студии отвалился. ну точнее оно запускает, но последнюю сборку годота. сборки из студии игнорируются. с 1 и 2 бетой было ок.
ага, походу ему теперь как-то надо указывать какую конфигурацию запускать. по умолчанию запускает дебуг. ключей нужных в хелпе не нашел
Раз ты начал маневрировать, и больше не утверждаешь что
> ускорение это сила
То значит ты все таки нагуглил учебник по физике, прогресс.
>сборки из студии
Может быть, тебе нужно что-то обновить?
https://github.com/godotengine/build-containers/pull/128
>SCons: 4.5.2
>Linux: GCC 10.2.0 built against glibc 2.19, binutils 2.35.1
>Windows: MinGW 11.0.0, GCC 13.2.1, binutils 2.40
Из списка изменений с сайта:
>This release also updates the toolchains used to build official binaries, notably for Windows, macOS, iOS and JavaScript. This should be mostly transparent to end users, but toolchain bugs are a possibility. So please report if anything seems off compared to the previous beta build in terms of performance, or outright crashing.
Я не шарю в компиляции движка, но наверняка тебе нужно что-то обновить, если ты компилируешь.
>не пересобирать проект по 2 раза
Вот почему многие выбирают GDScript.
Производительность труда разработчика >>>> производительность игры.
Переписать своё говно на ассемблер всегда успеешь.
>Ускорения это сила, понимаешь? Сил может быть несколько.
>>10245
>Ускорение создаётся силой приложенной к объекту.
Ты обосрался и не можешь этого признать? Человеку нужно узнать вектор ускорения за тик таймера, а ты ему про какие-то силы втираешь. Сил на объект много действует, а ускорение у него всегда одно (даже если оно нулевое или отрицательное, не важно).
Кроме того, движок не сообщает, какие силы подействовали на объект. Можно узнать вектор гравитации, но что там влияло кроме гравитации - неизвестно. Даже к встроенной силе трения прямого доступа по сути нет, ты можешь только физический материал настроить от "0" до "1"...
Да, есть нейросети. А я могу бесплатно сделать, если проект интересный (смущает только то, что он на годоте). Пишу музыку более 20 лет.
>15 лет опыта шарпа
За 15 лет я писал код на десятках языков. Первое время было сложно адаптироваться к GDScript, но потом я понял, что лучше изучить один раз и без проблем пользоваться, чем почти ежедневно спотыкаться о косяки каких-то костылей, которые прикручены к движку снаружи.
Godot Editor может использоваться как полностью независимая RAD IDE. И это основной способ её использовать, всё остальное - костыли для помощи неспособным ходить без костылей. Настоящему программисту вообще плевать, на чём писать код, потому что код у него в голове в абстрактной форме, а записи буквами - это одна из интерпретаций.
Вот что ты видишь перед глазами, когда решаешь задачу? Команды из API библиотек .NET? Очевидно, решение у тебя в абстрактной форме, а команды - только один из вариантов выразить это решение.
И если язык позволяет быстрее выразить решение, то он, очевидно, лучше для программирования.
>нейросеть для музыкальных треков?
Во-первых, звучит хуже процедурной музыки. Процедурную музыку любая веб-макака сделает, потратив немного времени на изучение теории.
Во-вторых, тебя издатели задолбают, потому что нейросеть обучалась на существующей музыке и генерирует что-то слишком похожее на это.
Лучше сделать игру без музыки. В музыке одни копирасты озабоченные, ищут способы извлечь сверхприбыли из беззащитных лохов. Игру с музыкой сложнее стримить, потому что копирасты заставляют удалять звук из видео или полностью блокируют видео/стримера.
Не говоря уж о том, что музыка давит на мозг части игроков, которым придётся её заглушать. А кто-то изначально без звука играть будет. Делать музыку для игры - пустая трата времени, которую мало кто из реальных игроков оценит.
1280x720, 0:24
Какая же ты поехавшая, гододя.
Когда ты программируешь игры у тебя не существует ускорения, есть только сила которая воздействует на объект. Внимательно читай. Не существует ускорения.
Не существует ускорения потому что объект, который производит силу, сам влияет на объекты и может когда угодно изменять силу, а значит и влияние на другие объекты. Объект, к которому приложена сила, если и влияет на объекты, которые являются источником силы, то не через ускорения или скорость, а по отдельному интерфейсу который изменяет именно силу.
Был бы ты не шизоидым гододей который не осилил даже школьный курс физики - ты бы это понимал. Жаль что ты гододя. Выкатывайся из гейдева, оно не для тебя. Даже говдод не ослили, ну и пиздец шиз.
>Туториал,
Игра должна быть интуитивно понятной, чтобы игроку не приходилось курить мануал три часа. Старайся избегать необходимости в туториале.
>звуки,
Есть глухие и слабослышащие. Твоя игра должна быть доступна для них, и вместо создания костыля в виде субтитров "(труп упал)" лучше делать игру, которая на звуки вообще не полагается - т.е. будет одинаково хорошо восприниматься без звука. Алсо, далеко не у всех есть аудиосистема в компе или возможность включать её для игры...
>кнопка выход?
Вот тут ты в самую точку попал. Мне довольно часто приходилось напоминать разрабам в отзывах и на форумах о необходимости кнопки "выход", которую большинство почему-то решают не добавлять.
>Не существует ускорения.
Переменная была равна 1, стала равна 2, потом будет равна 4. Между значениями одинаковые интервалы времени (тик). Скорость в первом случае равна 1, во втором случае равна 2. Значит, ускорение равно 1.
>не осилил даже школьный курс физики
Ты в какую сторону воюешь? Из школьного курса физики следует, что ускорение всегда существует. А ты утверждаешь, что оно не существует никогда.
Он просто троллит и когда понял что обосрался переобулся на 180 градусов.
В следующем году когда системы отсчета будете проходить, у марьиванны спросишь.
>Делайте игры.
Вчера хотел компьютер включить и поработать над игрой, а он опять не хочет работать. На телефоне в Godot ковыряться мучительно, да и игра требует управления с клавомыши. Так что никаких игр.
>Напишите мне саундтрек
>Я сам композитор с вышкой
Гуляй, фантазёр. И не лезь в чужой разговор.
1272x716, 0:14
Вот делаю, но когда пуля попадает в псину, всё вылетает жалуясь на слои, а я в них запутался и не понял че делать надо
Сделай аутлайн персонажам, а то сливаются с фоном
ШRYPHA?
Ты б ещё больше пиксели сделал... Хотя для первой попытки/прототипа неплохо, но ГГ сливается с фоном.
>вылетает жалуясь на слои
ПКМ по ошибке -> скопировать -> вставить сюда.
Алсо номер версии движка, чтоб мы не гадали.
Ты с разными людьми говорил, но я бы тоже не стал связываться с живым человеком с каким-то условиями и смущениями, когда есть нейросеть, способная в музыку. Пусть эта музыка и будет хуже.
Историю про падение стековерфлоу слышал? Вот там такая же хуйня. Лучше у чатгпт спросить, он тебя не будет забрасывать "ты делаешь не так, используй лучше X, а еще лучше заплати мне, и кстати весь твой стек технологий - говно".
Invalid get index 'knockback_vector' (on base: 'Area2D (Bullet.gd)').
годот 3.5.2, делаю по туторам heartbeast'a, но он с мечем делает экшн рпг, а я с пулями, поэтому местами по своему игру делаю, и в целом уже чувствую кашу развел
>ШRYPHA
Да, это язык будущего и сильно парится над домиками пока не хотел
>Ты б ещё больше пиксели сделал
они одного размера, это пиксели, прост без отступов
Гуляй, срачер. Все уже с тобой все поняли.
Наркоман. Давай начнем с того что это разные вещи. Продолжим тем что Стим тебя за нейронку в музыке выпиздит рано или поздно. Музыкальные лейблы это тебе не шутка, они очень быстро выебут и высушат всех за копирайт.
Даже если так, что не факт, то лучше без музыки вообще, или взять какой-нибудь паблик домейн, чем связываться с вонючкой с кучей условий.
>чем связываться с вонючкой с кучей условий.
Хау абаут научится работать в команде и прокачать свои социальные навыки.
>работать в команде
>прокачать свои социальные навыки
Ты это на анонимной имиджборде пишешь, нормис.
Большинство здесь гиперкомпенсирует отсутствие социальных навыков и кучу комплексов, мешающих разговаривать вживую/через мессенджеры.
А иначе зачем вообще этот форум нужен?
>пришел в тред годота
>засмущался почему игру делают на годоте
>начал посылать нахуй и называть наркоманами
>Хау абаут прокачать свои социальные навыки
А, ты это к нам социальные навыки пришел прокачивать.
Жаль, такого композтора потеряли.
А, погоди, ты же не показал никакой музыки.
Но я не композитор, ты путаешь постеров.
А наркоман он потому что сравнивает то что скурвился стековерфлоу, по куче причин связанных не только с нейронками, и музыку, которую нейронки нормально не делают прям совсем. Это при живых композиторах готовых тебе бесплатно пару демок отдать для пользования в проекте, если найдешь и попросишь.
>>10463
>Большинство здесь гиперкомпенсирует отсутствие социальных навыков и кучу комплексов, мешающих разговаривать вживую/через мессенджеры.
>А иначе зачем вообще этот форум нужен?
У тебя какая-то проблема навыка, я на имейдж бордах нашел нескольких художников и композиторов, уже заказывал у них коммишены для своих проектов. А еще я делал это на форчане и знаю английский достаточно хорошо для этого, что для любого нормального программиста так-то требование для работы.
Просто попробуй начать общаться с людьми и искать нужные связи с нужными специалистами, без этого в геймдеве никак.
>музыку, которую нейронки нормально не делают прям совсем
Чисто теоретически они могут; проблема в GIGO:
https://en.wikipedia.org/wiki/GIGO
Кто учит эти нейронки? Однозначно не композиторы.
>Это при живых композиторах готовых тебе бесплатно пару демок отдать для пользования в проекте, если найдешь и попросишь.
Они просто хотят бесплатный пиар за твой счёт. Если твоя игра не взлетит, им похрен. Если твоя игра взлетит, они будут всем говорить "а вы знали, это я написал музыку к той популярной игре, вот моя страничка, где вы можете купить другие мои работы".
Бесплатно помогать копирастам... ну такое. Ещё может деньги отжать, если нет доказательств, что он тебе бесплатно всю эту работу сделал.
>искать нужные связи с нужными специалистами, без этого в геймдеве никак.
Для меня разработка игр - хобби, которым я, как и многие, увлёкся из-за увлечения играми.
Я не хочу заработать или стать популярным, мне просто скучно и нравится копаться в коде, своими руками оживляя какие-то несложные идеи...
1268x706, 0:17
Блять, оказывается просто сигнал не был подключен, несмотря на то что строчка функции была, во дебил
>Они просто хотят бесплатный пиар за твой счёт. Если твоя игра не взлетит, им похрен. Если твоя игра взлетит, они будут всем говорить "а вы знали, это я написал музыку к той популярной игре, вот моя страничка, где вы можете купить другие мои работы".
>Бесплатно помогать копирастам... ну такое.
Бля, я даж не знаю что на это ответить. Как бы... Да? И это нормально? И я бы на таком месте был бы даже рад за композитора, что помог и себе и ему?
В чем твоя проблема сука.
Вот поэтому я не очень люблю подключать сигналы мышкой, а пишу в _ready connect(). Конечно это не 100% гарантия потому что и там можно забыть.
Пассажир, спок.
В том, что они хотят нажиться даже если ты сам ничего не заработаешь и уйдешь в минус. Еще строить из себя будут охуенного композитора и ссать в уши как секунда их драгоценного времени стоит 100500 денег.
Всегда забавляло как среди программистов считается нормой выкладывать свой код под опенсорсом просто потому что может, а какой-то мутный пердячер во фрутилупсе сразу корчит из себя бетховена и дрожит за свои 30 секунд говна. Те же рисоваки не настолько отбитые.
>Всегда забавляло как среди программистов считается нормой выкладывать свой код под опенсорсом просто потому что может, а какой-то мутный пердячер во фрутилупсе сразу корчит из себя бетховена и дрожит за свои 30 секунд говна
Ебать тут в башке насрано. Тебе композитор в детстве на хуй наступил? Они точно так же выкладывают свои работы под открытыми лицензиями. Их стараются не использовать просто чтоб у игры была своя уникальность так-то, да и заказать композитора дело дешевое довольно.
Не братан, пойду я лучше игры делать, ты слишком ебанутый.
>Они точно так же выкладывают свои работы под открытыми лицензиями.
Слишком редко чтобы считать это значимым. Зато будут исходить на говно, когда ты им напишешь и попросишь использовать трек с саундклауда с 3 прослушиваниями на всем аккаунте. В их голове им наверное сами Рокстары пишут и сейчас наш йоба-композер обзаведется парой феррари.
> когда ты им напишешь и попросишь использовать трек с саундклауда с 3 прослушиваниями на всем аккаунте
для игры с тремя покупателями.
Предложи ему хотя бы символическую сумму, а не спасибо.
Предлагаю ему показать свой трек моим трем покупателем. Было у него 3 прослушивания, станет 6. И делать ничего не надо. Будто что-то плохое.
Пиздец ты говдодя.
Так и быть, объясню чтобы даже гододя поняла. Ускорение в играх не нужно. Нет никакого применения ускорению вообще. Ни в каких ситуациях. Никогда. Ему просто не никакого применения. Единственное что в играх используется - это сила.
Неужели тебе так сложно понять это, гододя?
А, оно старое. Еще альфа 4.0. Ну ладно.
Сап, годотеры. Я заметил, что в редакторе тайлмапов 3.5 версии можно выбрать сразу два тайла через ctrl+левый клик, так если есть такая функция, то может можно и ставить сразу два, а не по одному?
в 4 можно. какой блок выбрал такой и ставиться. а если через заливку - чередуется
Например, дверь открыта/заперта, свет включен/выключен, итд.
Придумал иметь дикшенари всех объектов в игре (или на уровне) в котором хранится их состояние.
При загрузке уровня каждый объект смотрит свое состояние в словаре, когда игрок изменяет состояние объекта оно тоже в словаре обновляется.
Это так делается в играх?
>дикшенари всех объектов в игре (или на уровне) в котором хранится их состояние
Не всех, только тех, которые могут менять состояние. И сохраняется только если состояние изменилось.
Можно использовать встроенный механизм ресурсов, но с ним есть нюанс: в сейв можно инжектить любой код на GDScript, в т.ч. вредоносный. Если игрок качает рандомные сейвы в tscn/tres формате, он рискует подцепить какой-нибудь вирус.
Поэтому лучше хранить сейвы в json или кастомном бинарном формате (записывать байты вручную).
приблизительно так. айди предмета с состоянием - его состояние. все остальное - вариации релизации
>никакого смысла не вижу в scene unique names
Полезнее всего в GUI. Сложный гуй может представлять собой очень глубокое дерево за счёт всех контейнеров и прочего, плюс ты можешь часто перетаскивать ноды по дереву, меняя внешний вид интерфейса. Чтобы каждый раз в коде не обновлять пути до отдельных кнопок и надписей, придумали использовать короткий синтаксис $%имя.
>Из-за пределов этой сцены ноду по этому новому имени все равно получить нельзя
Вообще-то, можно. Это недокументированная фича и, возможно, даже баг, но пока что работает. Почему баг? Потому что в идеале ты не должен иметь доступа к рандомным нодам где-то за пределами твоей сцены. Почему фича? Потому что get_node() всегда позволял получить доступ к рандомной ноде из любого участка дерева. Так что не знаю, оставят это поведение или нет.
>а внутри сцены отследить ее не составляет труда
Только если ты сцену никак не меняешь. Во время разработки гуя ноды часто приходится таскать.
Как альтернатива, можно сделать так:
>@export var button_path: NodePath
>@onready var button: Button = get_node(button_path)
Тогда редактор будет автоматически обновлять путь, указанный дизайнером сцены в button_path, когда дизайнер перемещает кнопку. Но это лишние действия по сравнению с простым запросом:
>@onready var button: Button = $%Button
А Godot нацелен на быстрое прототипирование.
>Или Хуан выделение добавить додумался, а такой функционал нет?
Хуан последние 3-4 года до выпуска 4.0 занимался в основном переписыванием всего рендерера с нуля на Вулкан. Над кодом движка работают 2 тысячи людей, несколько десятков - ключевые разработчики. Тем более, Хуан давно уже больше управлением и пиаром занят, чем разработкой. Конкретно тайлмапы кто переписывал не помню, но к 4.0 систему тайлмапов серьёзно переработали, так что обратно в 3.х кинуть возможности не было. Над 3.х работа практически завершена, будут только багфиксы добавлять при возможности (некоторые баги не пофиксить). Все ключевые разработчики давно работают над 4.х.
Короч, прекращайте Хуана пинать и переходите на четвёрку, если у вас не игра уровня ГТА 6 на тройке, требующая регулярных обновлений вот прям щас.
>а веб...
Веб-игры - зло и нинужны.
>а мобильные...
Большинство сидит на новых версиях.
>а у меня ноутбук...
Обнови драйвера, чтобы OpenGL 3.3 был.
>а у меня Линукс...
Обновись до актуальной версии, наверное?
>Ускорение в играх не нужно. Нет никакого применения ускорению вообще. Ни в каких ситуациях. Никогда. Ему просто не никакого применения. Единственное что в играх используется - это сила.
Ты игры делал? Или только гиперказуалки?
Ещё раз. Задача: человек находится в сознании, стоя на движущейся платформе. Его мозг, анализируя ускорение платформы, калибрует тягу мышц скелета таким образом, чтобы компенсировать возникающее ускорение относительно платформы путём смещения центра тяжести. Если ускорение платформы слишком велико (резкая остановка, разгон или поворот), тогда скелетные мышцы не справятся с компенсацией, человек потеряет баланс, упадёт и покатится.
Повторяю, при равномерном движении платформы человек будет стоять неподвижно. Если платформа ускоряется, человек почувствует ускорение (дельту скорости платформы), попытается компенсировать своими мышцами, чтобы не упасть. Если ускорение слишком велико, компенсации мышцами будет недостаточно и человек упадёт. На одной только скорости и силах это никак не реализовать; силу в данном случае прикладывает сам человек, чтобы компенсировать изменение скорости платформы.
Алсо, если хочешь сиськи реалистично трясти:
https://github.com/detomon/wigglebone/blob/master/addons/wigglebone/wiggle_bone.gd#L31
- ускорение нужно, потому что колебание упругих тел производит из-за ускорения, а не скорости. Если нет ускорения, то упругое тело будет неподвижно. Всё потому, что часть тела не успевает ускориться, но на равномерной скорости догоняет основную массу. Поэтому сиськи оттягиваются только когда машина ускоряется, но не во время равномерного движения.
С симуляцией жидкости ты можешь поступить тупо, накидав невидимых шариков и обтянув их все одной поверхностью. Но если ты хочешь сделать более оптимальную модель и тебе не нужно разливать жидкость через край, ты можешь просто отображать поверхность воды, которая наклоняется в случае ускорения контейнера. При равномерном движении контейнера поверхность горизонтальна, но если контейнер ускоряется, поверхность наклоняется. Доступа к силам, действующим на контейнер, у тебя нет - ты ориентируешься только на его ускорение.
Наверняка есть другие примеры, но лень описывать. Ты игры всё равно не делаешь, зачем тебе это знать?
>Ускорение в играх не нужно. Нет никакого применения ускорению вообще. Ни в каких ситуациях. Никогда. Ему просто не никакого применения. Единственное что в играх используется - это сила.
Ты игры делал? Или только гиперказуалки?
Ещё раз. Задача: человек находится в сознании, стоя на движущейся платформе. Его мозг, анализируя ускорение платформы, калибрует тягу мышц скелета таким образом, чтобы компенсировать возникающее ускорение относительно платформы путём смещения центра тяжести. Если ускорение платформы слишком велико (резкая остановка, разгон или поворот), тогда скелетные мышцы не справятся с компенсацией, человек потеряет баланс, упадёт и покатится.
Повторяю, при равномерном движении платформы человек будет стоять неподвижно. Если платформа ускоряется, человек почувствует ускорение (дельту скорости платформы), попытается компенсировать своими мышцами, чтобы не упасть. Если ускорение слишком велико, компенсации мышцами будет недостаточно и человек упадёт. На одной только скорости и силах это никак не реализовать; силу в данном случае прикладывает сам человек, чтобы компенсировать изменение скорости платформы.
Алсо, если хочешь сиськи реалистично трясти:
https://github.com/detomon/wigglebone/blob/master/addons/wigglebone/wiggle_bone.gd#L31
- ускорение нужно, потому что колебание упругих тел производит из-за ускорения, а не скорости. Если нет ускорения, то упругое тело будет неподвижно. Всё потому, что часть тела не успевает ускориться, но на равномерной скорости догоняет основную массу. Поэтому сиськи оттягиваются только когда машина ускоряется, но не во время равномерного движения.
С симуляцией жидкости ты можешь поступить тупо, накидав невидимых шариков и обтянув их все одной поверхностью. Но если ты хочешь сделать более оптимальную модель и тебе не нужно разливать жидкость через край, ты можешь просто отображать поверхность воды, которая наклоняется в случае ускорения контейнера. При равномерном движении контейнера поверхность горизонтальна, но если контейнер ускоряется, поверхность наклоняется. Доступа к силам, действующим на контейнер, у тебя нет - ты ориентируешься только на его ускорение.
Наверняка есть другие примеры, но лень описывать. Ты игры всё равно не делаешь, зачем тебе это знать?
Разве что для гуя. Но как по мне гуй в первую очередь не должен мешать игроку, поэтому сложные гуи я не делаю.
>@export var button_path: NodePath
>@onready var button: Button = get_node(button_path)
В тройке было магическое заклинание, два в одном:
export(NodePath) onready var button = get_node(button)
>export onready
Емнип официально это было признано багом, потому что постоянно приводило к косяковым ситуациям,
Уже не помню точно, но сам вроде на такое напарывался со вложенными сценами (edit as children).
На ум приходит паразитирование на фандомах. Берешь условную Наруту и делаешь по ней платформер. Легкий вариант. Вот только потом тебя правообладатель прихлопнет.
>На ум приходит паразитирование на фандомах.
Да, я так буду делать. Еще не сделал, но целюсь на аудиторию хотя бы в 100к.
>Вот только потом тебя правообладатель прихлопнет.
Или подпольно что-то придумывать, например как порноделы. Когда билд можно скачать, но например за донаты более свежий.
Или искать лазейки, где есть фандом, но проще с собственностью.
Например, вариант: прочитать, какие персонажи вышли в Public Domain. К примеру, Шерлок Холмс и Винни Пух (но надо сделать визуально своего, либо брать оргинал) и нельзя наделять способностями, которых не было у оргинала и появились позже (когда супермен выйдет в общественное достояние, он будет уметь только прыгать, но не летать...)
Можно сделать свою франшизу, но похожую на что-то. RWBY берет в основе очевидные красную шапочку, белоснежку, златовласку и т.д. Даже если у Диснея есть эти персонажи, ничто не мешает их переосмыслить. Туда же Алису в стране чудес.
Можно воспользоваться принципом что геймплей не патентуется (не вдаваясь в буквоедство), например копировать геймплей homm3 и паразитировать на них.
Можно фармить 8 рублей в Я.Играх на играх про заглатывание бананов геншинодевочками потому что там пока что кладут на права
У меня слишком много сделано, а экспорт на 4 все ломает.
>прочитать, какие персонажи вышли в Public Domain
Разве у этого есть живые фанаты? Последние вымерли еще в прошлом веке, за редким исключением, которые ты уже перечислил. Или вот Дракула, например. Кому он сегодня нужен? Дон Кихот, Моби Дик, ОЗ.
>Можно сделать свою франшизу, но похожую на что-то.
Закроется возможность завалиться в комьюнити и сказать "пацаны смотрите я игру про ваших персонажей сделал".
Вспомнил что есть Creative Commons фандомы. Например SCP. Мне этот сеттинг не подходит, но может тебе зайдет.
> например как порноделы.
Мне кажется как раз с ними юристы зассут связываться, чтобы потом в профильной прессе не ассоциировали бренд с порнографией.
Проще закрыть глаза на такое, пускай дрочат лишь бы не воняли.
>>10642
Ну я даже не столько про сохранение файла, сколько про сохранение при переходе между локациями, хотя это можно свести одно к другому.
Допустим есть вот есть уровень, на нем дверь. У нее дефолтное состояние заперто, оно зашито в сцену.
При этом есть допустим автолоад, хранящий словарь состояний объектов.
При каждой загрузке уровня дверь в onready спрашивает этот автолоад про состояние двери и выставляет нужное.
Игрок идет в другую комнату и там тянет рычаг, обновляется состояние в словаре, и вернувшись к двери игрок сможет пройти дальше.
Примерно так это должно выглядеть, как думаете?
Полистал, пришел к выводу что больше всего фандом у пользователей GNU/Linux.
>юристы зассут связываться
Порноигры с Лунтиком и Барбоскиными удаляют с западных сайтов по запросу правообладателя из РФ.
>ассоциировали бренд с порнографией
В интернете все знают правило номер 34.
>>10729
>SCP
Они много лет боролись с каким-то российским кабанчиком, который пытался их прикрыть на основании получения им торговой марки SCP...
>>10727
>Разве у этого есть живые фанаты?
Двачую, персонажи средних веков нинужны.
>>похожую на что-то
>смотрите я игру про ваших персонажей сделал
В порноиграх часто бывают визуально похожие персонажи, так, что юрист не прикопаются, но фанат может быть вполне доволен. Что-то уровня смены имени, цвета волос и глаз, деталей одежды и т.п.
Вообще, думаю, можно закосить под AU:
https://en.wikipedia.org/wiki/Alternative_universe_(fan_fiction)
>>10717
>копировать геймплей
Это называется "клон" и таких игр 99%, при том чем крупнее бюджет игры, тем вероятнее, что это клон, потому что клон менее рискованный. Только инди без гроша в кармане экспериментируют, и редкие стартапы (вроде No Man's Sky был стартапом, в него вложили тонны бабла, ожидая переворот в играх).
Собственно поэтому никто особо идеи не ворует. Скопировать успешную игру - это одно, а реализация фантазий форумного дрочера - слишком рискованно. Очень сложно доказать, что какая-то идея принесёт прибыль, если она ни на что не похожа - чаще всего оригинальные идеи проваливаются.
>При каждой загрузке уровня дверь в onready спрашивает этот автолоад про состояние двери и выставляет нужное.
Я думаю, лучше так:
1. Загрузчик загружает сцену по требованию.
2. Перед показом сцены он передаёт ей состояние.
3. Скрипты сцены сами разбирают, что им надо.
4. Загрузчик вставляет сцену в дерево сцены.
...
5. Сцена меняет состояние в процессе геймплея.
...
6. Перед выгрузкой, загрузчик берёт её состояние.
Таким образом:
- сцена не зависит от внешних сущностей;
- сцена не имеет доступа к чужим данным;
- загрузчик не копается в деталях сцены;
- можно избежать лишних автолоадов.
Развели, блять, цирк.
В игровых вычислениях всё элементарно. У нас есть время кадра delta, и каждый кадр мы делаем:
jerk += snap delta # но это не нужно
acceleration += jerk delta # и это не нужно
velocity += acceleration delta # это иногда нужно
position += velocity delta # а нужно обычно только это
Не надо ускорению приписывать какие-то магические свойства. И силе тоже не надо приписывать магические свойства, потому что F=ma, то есть a=F/m, следовательно без всяких дополнительных производных делаем так:
# ускорение пересоздаём каждый кадр
var acceleration: Vector2 #или Vector3, если мы в тридэ
# force это вектор той же размерности, mass - скаляр
for force in all_forces:
acceleration += force / mass
# скорость храним между кадрами
velocity += acceleration delta
# допустим, у нас нет мувэндслайд всяких, двигаем просто спрайт
position += velocity * delta
Всё.
Возьмём модель одномерного автобуса в вакууме. Модель упрощённая, так что, выйдя на основную скорость, ему не надо будет разгоняться или тормозить, пока он не приблизится к концу маршрута. Разгон и торможение у автобуса равны по модулю.
Рассмотрим силы, действующие на пассажира в каждую из трёх фаз:
1. Разгон. Пассажир с массой m испытывает силу F, передаваемую ему от автобуса. Эта сила разгоняет его с ускорением a = F / m.
2. Маршрут. На пассажира не действуют никакие силы, он движется по инерции со скоростью, равной скорости автобуса.
3. Торможение. Автобус снижает свою скорость, а пассажир продолжает двигаться по инерции. Чтобы не улететь вперёд, он цепляется за автобус с силой F' = -F, таким образом приобретая ускорение a' = F' / m.
Ровно то же самое происходит и на движущейся платформе, и в сиське у бегущей тянки.
Развели, блять, цирк.
В игровых вычислениях всё элементарно. У нас есть время кадра delta, и каждый кадр мы делаем:
jerk += snap delta # но это не нужно
acceleration += jerk delta # и это не нужно
velocity += acceleration delta # это иногда нужно
position += velocity delta # а нужно обычно только это
Не надо ускорению приписывать какие-то магические свойства. И силе тоже не надо приписывать магические свойства, потому что F=ma, то есть a=F/m, следовательно без всяких дополнительных производных делаем так:
# ускорение пересоздаём каждый кадр
var acceleration: Vector2 #или Vector3, если мы в тридэ
# force это вектор той же размерности, mass - скаляр
for force in all_forces:
acceleration += force / mass
# скорость храним между кадрами
velocity += acceleration delta
# допустим, у нас нет мувэндслайд всяких, двигаем просто спрайт
position += velocity * delta
Всё.
Возьмём модель одномерного автобуса в вакууме. Модель упрощённая, так что, выйдя на основную скорость, ему не надо будет разгоняться или тормозить, пока он не приблизится к концу маршрута. Разгон и торможение у автобуса равны по модулю.
Рассмотрим силы, действующие на пассажира в каждую из трёх фаз:
1. Разгон. Пассажир с массой m испытывает силу F, передаваемую ему от автобуса. Эта сила разгоняет его с ускорением a = F / m.
2. Маршрут. На пассажира не действуют никакие силы, он движется по инерции со скоростью, равной скорости автобуса.
3. Торможение. Автобус снижает свою скорость, а пассажир продолжает двигаться по инерции. Чтобы не улететь вперёд, он цепляется за автобус с силой F' = -F, таким образом приобретая ускорение a' = F' / m.
Ровно то же самое происходит и на движущейся платформе, и в сиське у бегущей тянки.
Треды так быстро сменяют друг друга, у меня уже заканчиваются годные картинки для переката. Такая уже была или ещё нет? В оригинале справа Samsung, вообще не в тему и криво прилеплена - отрезал.
Серьёзно, этот тред всего две недели продержался.
Потому что тут физику обсуждают
Проебал форматирование - инвалидировал свое мнение, сорян.
Тут какой то контекст неправильный. Будто мужик шел с какой-то другой девочкой. Мы же сразу верны Годетте.
Генерируй нейросетью, 2к24 год на дворе.
>макаба сожрала звёздочки
Ньюфаг не палится.
>>10743
>for force in all_forces:
Удачи запросить у физического движка все силы, которыми он там воздействует на ригидбоди. Или узнать все силы, которые могут возникать от разных источников в твоём собственном коде.
>velocity += acceleration × delta
>position += velocity × delta
Изначально речь шла о симуляции RigidBody3D в физическом движке, чтобы минимизировать количество велосипедов в своём коде.
Никто не спорит, что на своём велосипеде делай что хочешь без проблем, только это совсем другая тема.
>Возьмём модель одномерного автобуса в вакууме. Модель упрощённая
Тогда тут вообще физика не нужна. Речь о 3D физике, где на автобус могут действовать десятки сил из разных источников, о которых твой код знать не должен, иначе будет высокая связность.
>Пассажир с массой m испытывает силу F, передаваемую ему от автобуса.
Как ты это определишь, не зная ускорения? У тебя под ногами платформа, но ты не знаешь, какие силы на неё действуют. Только масса и скорость.
>Будто мужик шел с какой-то другой девочкой.
Это в свете недавних событий. Но чтобы не возбуждать движкосрач, другая девочка вне кадра.
>Мы же сразу верны Годетте.
Ну, тут не поспоришь.
>из разных источников, о которых твой код знать не должен, иначе будет высокая связность
Эээ, перепутал, высокое зацепление.
Связность - внутри модуля.
Зацепление - между модулями.
В хорошем коде высокая связность и слабое зацепление, в плохом коде всё наоборот.
Кстати ты тут походя доказал что ускорение это не сила.
Потому что они в разных половинах уравнения.
И хоть они пропорциональны, это не одно и то же. Как не одно и то же напряжение и сила тока, или давление и температура.
Можно еще показать через коэффициент массы.
Если у нас два идентичных ускорения, но у одного тела полмассы, то результаты разные - сила и полсилы. Так что это две уникальных сущности, а не одна.
А тот анон просто играл на том, что непонятно, что является первичным, что производит что - сила ускорение, или ускорение силу. А потом это накладывается на факт, что ИРЛ есть инерция, а в симулируемом мире ее нет, каждый кадр тело начинает со скоростью 0, пока программист (игры или движка) прямым действием не прибавит текущую скорость, то есть не действует 1-й закон Ньютона.
С пистолетом модная.
>ИРЛ есть инерция, а в симулируемом мире ее нет, каждый кадр тело начинает со скоростью 0
Чаво? Просто не делай velocity = Vector3.ZERO.
Наоборот, добавить сопротивление воздуха или поверхностей сложнее, чем сделать инерцию, что есть по умолчанию (не обнуляешь переменную).
>перекатывайте, у меня вопрос горит
Задавай здесь. Какая разница, где? Потом можешь репост сделать, если нужно будет.
Есть еще вариант если автор не сильно против. Ни на что не намекаю, но например Zun давал разрешение выпускать фанатские игры по Touhou вот например платная с кучей отзывов https://store.steampowered.com/app/745880/Touhou_Tenkuushou__Hidden_Star_in_Four_Seasons/
Бессмысленный опрос как ему и написали
У многих по 2 языка, например GDscript/Godot Editor + C++/VScodium
Да, тоже неплохой подход. Я скорее всего буду делать что-то среднее между тем и тем.
Еще мне интересно как сделать менеджер неписей, неписи-то не прибиты гвоздями к сцене, в зависимости от фазы дня или фазы игры они прыгают между локациями (днем нпс в одной локации, вечером в другой, ночью недоступен).
Пока что придумал только самое простое лобовое решение - храним глобально в виде (id нпс, сцена где он стоит, координаты), при загрузке сцены отбираем тех кто нужен в этой сцене и расставляем их. Явных подводные камней не вижу
Вообще интересно как эта все эти системы сделаны в играх беседки
Очень показательный опрос. Люди выбирают ближайшее, и как мы видим ближайшее это Godot+GDScript. Впрочем, будь опрос таким как ты хотел бы, там был бы похожий результат. От шарпистов просто шуму много, поскольку беженцы с юнити и все еще осваиваются.
>запросить у физического движка все силы,
Все не получится, но можно их сумму - applied_force для тройки, constant_force для четвёрки. А это просто пример на случай, если ты сам пытаешься обрабатывать физику и хочешь применить к телу несколько сил, то вот так их считать.
Кстати, лучше сначала просуммировать все силы, а потом делить на массу, тут я прошляпил.
>Тогда тут вообще физика не нужна. Речь о 3D физике
Какая разница-то? Векторы они хоть 196883-мерном пространстве векторы.
>Как ты это определишь, не зная ускорения?
Третий закон Ньютона.
>>10755
>Кстати ты тут походя доказал что ускорение это не сила
Второй закон Ньютона.
>инерция
Первый закон Ньютона.
Мне кажется, тут кое-кому следует подтянуть знания по физике за 7 класс.
>ИРЛ есть инерция, а в симулируемом мире ее нет
Вот смотри. Вариант 1:
>var velocity = Vector3.ZERO
>func _physics_process(delta):
Вариант 2:
>func _physics_process(delta):
>var velocity = Vector3.ZERO
Вроде бы одно и то же, но есть нюанс. В первом варианте инерция есть, а во втором её нет.
> Мне кажется, тут кое-кому следует подтянуть знания по физике за 7 класс.
Не кажется. Тебе. Перечитывай до просветления ту часть поста, где говорится про пропорциональность, а не идентичность.
F = ma
1 = 1x1
2 = 2x1
Ускорение одинаковое, милы разные => сила не эквивалентно ускорение.
Есои и такой пример для тебя сложен, то вот тебе пример попроще
Расстояние это время на скорость
d = t*s
По твоей логике, расстояние это скорость, потому что они находятся в тех же позициях в формуле, что и сила с ускорением.
Еще раз для закрепления надо?
Если А зависит от В, не означает, что А является В.
> ты споришь с воображаемыми собеседниками, которые говорят тебе, что ускорение и сила это одно и то же
Это гододик возбудился и решил доказать что он не петушконикс с отсутствующими знаниями за 8 класс, засрав тред этим бесконечным бредом. Он шизик просто. Настолько шизик что не может в голове удерживать Ньютоновскую механику.
Имелось ввиду что для игровых движков обычно ускорение не нужно. Т.е. ускорение = сила для игровых движков, потому что зачем вообще искать ускорение, если оно нигде не используется? Во всех задачах где нужно ускорение, для какого-то конечного значения, есть своя формула вычисления этого конечного значения, потому что всегда есть какая-то сила компенсации всех сил которые действуют на объект. А ускорение? Нахуй не нужно.
Это настолько просто и понятно что даже хуан сделал всё правильно, а гододик до сих пор не понял. Жалкий шизик засирающий всё вокруг.
Типо на каждом сохраняемом объекте должен быть свой скрипт, который подтянет состояние? А если таких объектов 300? А если потом структуру сохранения как-то изменить понадобится, в каждом из 300 тоже менять?
Щас одну игорю переделываю на Годот 4.1, в оригинале есть диалоги и они составляют чуть-ли не 75% игры(можете угадать что за игра т.к. я уже светился тут со своим говном), я забил на них хуйца и первым делом решил воссоздать базу, база готова, теперь надо диалоговую систему, А ЕЁ НЕТ БЛЯ! Всякие диалогиги и прочее хуй дождёшься, я начал проект 3 месяца назад, а его всё ещё не портировали под 4.1, в итоге вштал вопрос: а чё юзать-то? Требуется прям диалоговая система для ВН, а не тупо вывод текста в коробочку, есть что-то похожее? А может мб кто-то даже диалогик к 4.1 смог пришаманить и поделится плагином/фиксами?
Наверняка есть другие аспекты игоря, которыми ты можешь заняться пока диалоги допиливают.
Но вроде альтернатив диалогика хватало. Поищи в ассетах.
Диалоджик работает на 4.1 нормально.
>А может мб кто-то даже диалогик к 4.1 смог пришаманить и поделится плагином/фиксами?
Ты наверное ставил из мертвого ассет либрари.
Вот настоящий диалоджик, для 4
https://github.com/coppolaemilio/dialogic
Я отвечал тебе, потому что ты начал спорить тут
> >Кстати ты тут походя доказал что ускорение это не сила
> Второй закон Ньютона.
Раз ты возразил, значит поддерживал противоположенную точку зрения. Рад, что уладили это недопонимание.
>>10814
> ускорение = сила
Иди читать школьный учебник. Они не всегда равны, потому что в формуле участвует еще и m.
>Иди читать школьный учебник.
Шизик-гододя-оопешка опять за своё. Ему говорят читать учебник школьной физики уже несколько анонов - он в ответ перефорс толкает "НЕТ ВЫЫ!!!111". Какое же поехавшее......
> Они не всегда равны, потому что в формуле участвует еще и m.
И что? Ускорение от этого не появляется, шизло. Единственно что в объект приходит, т.е. воздействует, это сила.
>для игровых движков обычно ускорение не нужно
Ну, скажем так. Я знаю как минимум одно ускорение, которое нужно и которое точно не сила. Ускорение свободного падения.
Обычно так. Ускорение нужно безмассовому кинематику; сила - массивному ригиду.
И во всех случаях следует помнить, что игра призвана дарить эмоции через геймплей, а не дотошно воспроизводить реальный мир.
>>10891
Этшто, бунд? Считать ли такой перекат легитимным? Ну, Годетта няшная, канеш.
>Считать ли такой перекат легитимным?
Нет конечно, ни на что не претендую, прост не хотелось чтобы мои вопросики смыло перекатом.