960 Кб, 1080x1485Добро пожаловать в тред любви и взаимопомощи, диздоков и прототипов!
Шапка: https://hipolink.me/godothread
Предыдущий: >>901894 (OP)
Архивный: >>895906 (OP)
Шапка: https://hipolink.me/godothread
Предыдущий: >>901894 (OP)
Архивный: >>895906 (OP)
>>07247
Запустил три годота, выбираю какой проект проработать сегодня хочу
Запустил три годота, выбираю какой проект проработать сегодня хочу
>>07247
Делаю ИИ для своией топ-даун игры. Думаю какие интересные поведения добавить можно.
Делаю ИИ для своией топ-даун игры. Думаю какие интересные поведения добавить можно.
>>07294
GOAP? Utility AI? Какой-то свой подход?
Меня как раз ИИ интересует. Хочу сделать что-то модульное, чтобы процедурно генерировать. Чтоб комбинации проявляли эмерджентность.
Пробовал делать локации, но без ИИ мотивации продолжать нет никакой - мёртвый пустой мир не привлекает, а тупые мобы мне не подходят.
Если компьютер заработает, на днях планирую очередной прототип делать, конкретно про ИИ.
>ИИ для топ-даун игры
>интересные поведения добавить
GOAP? Utility AI? Какой-то свой подход?
Меня как раз ИИ интересует. Хочу сделать что-то модульное, чтобы процедурно генерировать. Чтоб комбинации проявляли эмерджентность.
Пробовал делать локации, но без ИИ мотивации продолжать нет никакой - мёртвый пустой мир не привлекает, а тупые мобы мне не подходят.
Если компьютер заработает, на днях планирую очередной прототип делать, конкретно про ИИ.
>>07304
Пока разбираюсь с обычными стейт машинами. Например есть идея убегающего врага, который несет с собой кучу лута. Уже лучше чем одни нападающие болванчики.
Пока разбираюсь с обычными стейт машинами. Например есть идея убегающего врага, который несет с собой кучу лута. Уже лучше чем одни нападающие болванчики.
>>07312
Там проблема в том, что ты должен явным образом прописать отношения между состояниями. Сложнее поведение - больше состояний и связей между ними.
С другой стороны, граф состояний можно просто нарисовать перед тем, как писать какой-либо код.
Видел подобное в нескольких играх.
Тут большая разница в том, что нападающие обычно агрессоры и игрок защищается (если забыть о том, что он сам лезет в толпу гриндить опыт и лут), а если монстр убегает, то это уже игрок агрессор и негодяй, обижающий безобидных существ. Такое плохо будет выглядеть в игре про героя-спасителя, т.к. у игрока оптимальная стратегия - нападать на убегающих, а игроки стремятся оптимизировать свой геймплей.
Так что не всякое разнообразие лучше.
>стейт машина
Там проблема в том, что ты должен явным образом прописать отношения между состояниями. Сложнее поведение - больше состояний и связей между ними.
С другой стороны, граф состояний можно просто нарисовать перед тем, как писать какой-либо код.
>идея убегающего врага
>несет с собой кучу лута
Видел подобное в нескольких играх.
>лучше чем одни нападающие болванчики
Тут большая разница в том, что нападающие обычно агрессоры и игрок защищается (если забыть о том, что он сам лезет в толпу гриндить опыт и лут), а если монстр убегает, то это уже игрок агрессор и негодяй, обижающий безобидных существ. Такое плохо будет выглядеть в игре про героя-спасителя, т.к. у игрока оптимальная стратегия - нападать на убегающих, а игроки стремятся оптимизировать свой геймплей.
Так что не всякое разнообразие лучше.
>>07319
Нет, не должен. Зачем? Просто стейты-тактики и менеджер. Менеджер определяет, какую тактику использовать вотпрямщас, но сами по себе они автономны, переключиться от одной к другой можно в любой момент.
И да, это НЕ стейты физики+анимации типа "идти", "стоять", "пердеть". Скорее это простые паттерны поведения, вроде "искать укрытие", "заходить сбоку", "прикрывать братюнь огнём", "переть танком". А они уже управляют персонажем, жмут виртуальные кнопки, от которых тушка ходит или стреляет или ещё что.
Ну и да, разные менеджеры могут иметь разную логику смены тактик.
>должен явным образом прописать отношения между состояниями
Нет, не должен. Зачем? Просто стейты-тактики и менеджер. Менеджер определяет, какую тактику использовать вотпрямщас, но сами по себе они автономны, переключиться от одной к другой можно в любой момент.
И да, это НЕ стейты физики+анимации типа "идти", "стоять", "пердеть". Скорее это простые паттерны поведения, вроде "искать укрытие", "заходить сбоку", "прикрывать братюнь огнём", "переть танком". А они уже управляют персонажем, жмут виртуальные кнопки, от которых тушка ходит или стреляет или ещё что.
Ну и да, разные менеджеры могут иметь разную логику смены тактик.
>>07320
И что? Тебе всё равно это всё вручную печатать.
Если у тебя просто список состояний, это не FSM.
Как ты будешь определять требуемое состояние?
Из случайной статьи про FSM:
Вот для определения состояния следует вместо огромной портянки if сделать что-то вроде этого:
Т.е. это не конечный автомат: вместо состояний - поведения, имеющие функцию оценки пользы, и выполняется наиболее полезное поведение.
>Просто стейты-тактики и менеджер.
И что? Тебе всё равно это всё вручную печатать.
>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.
Т.е. это не конечный автомат: вместо состояний - поведения, имеющие функцию оценки пользы, и выполняется наиболее полезное поведение.
34 Кб, 580x350>>07320 >>07325
Вот, нашёл эту иллюстрацию. Вот это - FSM. Если ты убираешь рёбра графа, у тебя остаются только состояния, так что это больше не будет FSM. Поэтому, говоря о FSM, мы говорим не только о состояниях, но и о конкретных переходах между ними.
Да, есть деление на детерминированные автоматы и недетерминированные, а есть ещё вероятностные. Но везде указываются конкретные рёбра на графе, а не "ну вот типа менеджер есть, он как-то решает, в какое состояние прыгнуть".
Вот есть, например, решатель Utility AI. Он явно противопоставлен FSM как отдельная архитектура:
При том что Utility AI, по сути, работает с теми же самыми состояниями, только вместо вручную описанных рёбер - функция оценки полезности и выбор наиболее полезного в данный момент состояния.
>на изображении выше
Вот, нашёл эту иллюстрацию. Вот это - 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, по сути, работает с теми же самыми состояниями, только вместо вручную описанных рёбер - функция оценки полезности и выбор наиболее полезного в данный момент состояния.
Эх, щас бы игры поделать...
>>07328
Ну, ок. Пусть состояния соревнуются между собой. Каждое даёт свою оценку полезности; у которого она наивысшая, то и будет активным.
На мой взгляд, нахер не нужны. Почему по условию "healthpoints are low" не переключаться из любого состояния в "find aid"? Вообще не представляю себе ситуацию, когда бы из одного поведения нельзя было переключиться на любое другое.
Я понимаю анимации, типа когда прыжок переходит в падение, но не в ползание. Но тут что мешает перейти откуда угодно куда угодно? Ладно, добавляем к каждому состоянию таймер fade_in/out, если надо, чтобы моб не мгновенно реагировал на смену обстоятельств. Ну и всё.
Ну, ок. Пусть состояния соревнуются между собой. Каждое даёт свою оценку полезности; у которого она наивысшая, то и будет активным.
> переходы
На мой взгляд, нахер не нужны. Почему по условию "healthpoints are low" не переключаться из любого состояния в "find aid"? Вообще не представляю себе ситуацию, когда бы из одного поведения нельзя было переключиться на любое другое.
Я понимаю анимации, типа когда прыжок переходит в падение, но не в ползание. Но тут что мешает перейти откуда угодно куда угодно? Ладно, добавляем к каждому состоянию таймер fade_in/out, если надо, чтобы моб не мгновенно реагировал на смену обстоятельств. Ну и всё.
>>07319
Игра про героя-спасителя такое себе. Ограничивающее, избитое, скучное. Быть правильным скучно. Играть правильно - еще скучнее. Вспомните сколько раз вы забивали на правильное прохождение скайрима и выпиливали города? Но игра за такое дает понять что ты портишь негласный договор и наказывает тебя закрытием возможностей. И приходится загружаться. Не делайте игор про игрока-спасителя.
Самый топ, ящитаю, это злодеи против злодеев.
Игра про героя-спасителя такое себе. Ограничивающее, избитое, скучное. Быть правильным скучно. Играть правильно - еще скучнее. Вспомните сколько раз вы забивали на правильное прохождение скайрима и выпиливали города? Но игра за такое дает понять что ты портишь негласный договор и наказывает тебя закрытием возможностей. И приходится загружаться. Не делайте игор про игрока-спасителя.
Самый топ, ящитаю, это злодеи против злодеев.
>>07343
А мне вот не хватает игр про добряков. Как не заходишь в игру, так прорабатывают ветки каких-нибудь темных братств и прочего криминал скам, а для доброго паладина придумывают контент уровня "убей 10 медведей"
>Игра про героя-спасителя такое себе.Ограничивающее, избитое, скучное.
А мне вот не хватает игр про добряков. Как не заходишь в игру, так прорабатывают ветки каких-нибудь темных братств и прочего криминал скам, а для доброго паладина придумывают контент уровня "убей 10 медведей"
>>07343
Ну ноль, ебать. В скайриме весь контент в чистке данжей, проклике диалогов и немного рофла с магии. Чистка городов почти во всех эрпоге - говно без задач. В последний раз таким наверное в фолаче3 школотуном занимался, и то только потому что туда завезли расчленёнку.
Школоивел порвался, лол. Пиздуй лечить детские травмы, раз коупишь через злодейства над комплюктерными болванчиками.
>Вспомните сколько раз вы забивали на правильное прохождение скайрима и выпиливали города?
Ну ноль, ебать. В скайриме весь контент в чистке данжей, проклике диалогов и немного рофла с магии. Чистка городов почти во всех эрпоге - говно без задач. В последний раз таким наверное в фолаче3 школотуном занимался, и то только потому что туда завезли расчленёнку.
>Игра про героя-спасителя такое себе.
Школоивел порвался, лол. Пиздуй лечить детские травмы, раз коупишь через злодейства над комплюктерными болванчиками.
>>07343
Я бы хотел сделать игру про настоящего злого. Я даже видел запрос на такое однажды. Чтобы играть за дроу в андердарке. Чтобы можно было пытать людей, устраивать набеги на деревни, колдовать всякую темную магию, устраивать разборки домов с выпилом. От себя я бы еще много чего наворотил, всякие эксперименты над телами. Но останавливают правовые последствия. Да и хрен ее выложишь где то. Если только на порнохостингах, да и то до тех пор пока игроки не найдут способы устраивать рейп. Полностью подпольную игру в даркнете с выводом крипты делать если только.
Я бы хотел сделать игру про настоящего злого. Я даже видел запрос на такое однажды. Чтобы играть за дроу в андердарке. Чтобы можно было пытать людей, устраивать набеги на деревни, колдовать всякую темную магию, устраивать разборки домов с выпилом. От себя я бы еще много чего наворотил, всякие эксперименты над телами. Но останавливают правовые последствия. Да и хрен ее выложишь где то. Если только на порнохостингах, да и то до тех пор пока игроки не найдут способы устраивать рейп. Полностью подпольную игру в даркнете с выводом крипты делать если только.
>>07343
А теперь посмотри на популярность какого-нибудь Евро Трак Симулятора
А теперь посмотри на популярность какого-нибудь Евро Трак Симулятора
Однажды я возьму в кулак свою прокрастинацию и сделаю игру про деревянного мальчика, слушающего виниловые пластинки.
осваиваю этот ваш годот потихоньку, и возник такой тупой вопрос. как сделать гуи панельку динамического размера. вот банальный пик релейтед - что бы панель сама меняла высоту в зависимости от количества кнопок
>>07350
Чет не взлетит, думаю я. В даркнете у людей другие интересы.
Чет не взлетит, думаю я. В даркнете у людей другие интересы.
>>07379
Установи ей grow direction в зависимости от того, куда хочешь расти. А VBox ты уже используешь. Вроде все.
Установи ей grow direction в зависимости от того, куда хочешь расти. А VBox ты уже используешь. Вроде все.
>>07387
ага оно. только надо было панелконтейнер а не просто панел
ага оно. только надо было панелконтейнер а не просто панел
486 Кб, 1081x302>>07350
Уже сделали, проверяй.
>Чтобы можно было пытать людей, устраивать набеги на деревни, колдовать всякую темную магию, устраивать разборки домов с выпилом.
Уже сделали, проверяй.
>>07337
Это и называют Utility AI или Utility System.
https://en.wikipedia.org/wiki/Utility_system
Кстати, где-то читал, что что-то похожее происходит в головном мозге - соревнование между колонками неокортекса за право активации в данный момент. Победившая колонка подавляет всех проигравших.
Потому что тогда граф твоего автомата будет представлять из себя огромный клубок нитей.
Я тут набросал примеры в виде графов...
1. FSM в классическом геймдев понимании: граф из состояний и чётко прописанных переходов.
2. Utility AI: у каждого поведения есть функция оценки полезности, и мы периодически проверяем, какое из поведений в данный момент лучшее. Да, формально здесь нарисована FSM, но суть у неё совсем иная и называть это "просто FSM" нельзя - тебя не поймут.
3. GOAP - честно признаюсь, я без понятия, как это реализовать правильно, так что пример кривой, но всё-таки: есть список действий с предусловиями и последствиями, и есть FSM с тремя состояниями; составление плана происходит через AStar (это уже намного сложнее изобразить, так что... гуглите).
>Пусть состояния соревнуются между собой. Каждое даёт свою оценку полезности; у которого она наивысшая, то и будет активным.
Это и называют 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 (это уже намного сложнее изобразить, так что... гуглите).
>>07343
Игры - это всегда ограничения. Песочницы в чистом виде имеют довольно узкую аудиторию - чаще игроки играют либо по правилам игры, либо по правилам модификаций игры, а не по своим выдумкам.
Наоборот, слишком много игр про убийства, и даже "добрые" персонажи занимаются геноцидом мобов, борьба со "злом" идёт методами самих "злодеев". Идеальная игра про добро должна заканчиваться тем, что злодей признал свои ошибки и исправился - стал добрым, а такого почти не бывает - герои тупо убивают карикатурного "злодея", не обременяя себя вопросами морали, как какие-то солдаты. Хороший герой должен искать путь, не состоящий на 99% из мясорубки мобов и убийства финального босса.
Это уже твоё субъективное стремление к жести.
Интересный геймплей никак не связан с тем, чем ты в игре занимаешься. Интересный геймплей даёт тебе дозы эндорфинов. Если ты достигатор, стремящийся достичь 999 уровня, не всё ли равно, что ты будешь делать в игре - убивать или заводить друзей? Главное, чтобы действия давали очки опыта, от которых у тебя происходит всплеск гормонов удовольствия.
Ты разве не понимаешь? Игра завязана на квесты, ты получаешь квесты от неигровых персонажей в строго определённых дизайнером уровней местах. Если ты сбрасываешь атомную бомбу на это место, то как ты планируешь потом брать квесты? Или игра должна спамить тебе новых случайных квестодателей? Чаще всего эту проблему решают бессмертием персонажей.
Ты, наверное, сюжет в квестах вообще не читал, и воспринимаешь их только как точки входа в новые активности на карте. Это значит, что жанр РПГ не для тебя, тебе больше подойдут слешеры - там не нужно много читать, зато нужно много рубить мобов.
Большинство игр в этой категории, см. выше. Смешно смотреть на "героя", все геройства которого состоят из массовой резни зачастую маленьких и слабых мобов. Начинают путь буквально с истребления малышей, пока не объявится рассерженная огромная самка...
>Ограничивающее
Игры - это всегда ограничения. Песочницы в чистом виде имеют довольно узкую аудиторию - чаще игроки играют либо по правилам игры, либо по правилам модификаций игры, а не по своим выдумкам.
>избитое
Наоборот, слишком много игр про убийства, и даже "добрые" персонажи занимаются геноцидом мобов, борьба со "злом" идёт методами самих "злодеев". Идеальная игра про добро должна заканчиваться тем, что злодей признал свои ошибки и исправился - стал добрым, а такого почти не бывает - герои тупо убивают карикатурного "злодея", не обременяя себя вопросами морали, как какие-то солдаты. Хороший герой должен искать путь, не состоящий на 99% из мясорубки мобов и убийства финального босса.
>скучное
Это уже твоё субъективное стремление к жести.
>Играть правильно - еще скучнее.
Интересный геймплей никак не связан с тем, чем ты в игре занимаешься. Интересный геймплей даёт тебе дозы эндорфинов. Если ты достигатор, стремящийся достичь 999 уровня, не всё ли равно, что ты будешь делать в игре - убивать или заводить друзей? Главное, чтобы действия давали очки опыта, от которых у тебя происходит всплеск гормонов удовольствия.
>выпиливать города скайрима
>игра за такое дает понять что ты портишь негласный договор и наказывает тебя закрытием возможностей.
Ты разве не понимаешь? Игра завязана на квесты, ты получаешь квесты от неигровых персонажей в строго определённых дизайнером уровней местах. Если ты сбрасываешь атомную бомбу на это место, то как ты планируешь потом брать квесты? Или игра должна спамить тебе новых случайных квестодателей? Чаще всего эту проблему решают бессмертием персонажей.
Ты, наверное, сюжет в квестах вообще не читал, и воспринимаешь их только как точки входа в новые активности на карте. Это значит, что жанр РПГ не для тебя, тебе больше подойдут слешеры - там не нужно много читать, зато нужно много рубить мобов.
>злодеи против злодеев
Большинство игр в этой категории, см. выше. Смешно смотреть на "героя", все геройства которого состоят из массовой резни зачастую маленьких и слабых мобов. Начинают путь буквально с истребления малышей, пока не объявится рассерженная огромная самка...
>>07343
Игры - это всегда ограничения. Песочницы в чистом виде имеют довольно узкую аудиторию - чаще игроки играют либо по правилам игры, либо по правилам модификаций игры, а не по своим выдумкам.
Наоборот, слишком много игр про убийства, и даже "добрые" персонажи занимаются геноцидом мобов, борьба со "злом" идёт методами самих "злодеев". Идеальная игра про добро должна заканчиваться тем, что злодей признал свои ошибки и исправился - стал добрым, а такого почти не бывает - герои тупо убивают карикатурного "злодея", не обременяя себя вопросами морали, как какие-то солдаты. Хороший герой должен искать путь, не состоящий на 99% из мясорубки мобов и убийства финального босса.
Это уже твоё субъективное стремление к жести.
Интересный геймплей никак не связан с тем, чем ты в игре занимаешься. Интересный геймплей даёт тебе дозы эндорфинов. Если ты достигатор, стремящийся достичь 999 уровня, не всё ли равно, что ты будешь делать в игре - убивать или заводить друзей? Главное, чтобы действия давали очки опыта, от которых у тебя происходит всплеск гормонов удовольствия.
Ты разве не понимаешь? Игра завязана на квесты, ты получаешь квесты от неигровых персонажей в строго определённых дизайнером уровней местах. Если ты сбрасываешь атомную бомбу на это место, то как ты планируешь потом брать квесты? Или игра должна спамить тебе новых случайных квестодателей? Чаще всего эту проблему решают бессмертием персонажей.
Ты, наверное, сюжет в квестах вообще не читал, и воспринимаешь их только как точки входа в новые активности на карте. Это значит, что жанр РПГ не для тебя, тебе больше подойдут слешеры - там не нужно много читать, зато нужно много рубить мобов.
Большинство игр в этой категории, см. выше. Смешно смотреть на "героя", все геройства которого состоят из массовой резни зачастую маленьких и слабых мобов. Начинают путь буквально с истребления малышей, пока не объявится рассерженная огромная самка...
>Ограничивающее
Игры - это всегда ограничения. Песочницы в чистом виде имеют довольно узкую аудиторию - чаще игроки играют либо по правилам игры, либо по правилам модификаций игры, а не по своим выдумкам.
>избитое
Наоборот, слишком много игр про убийства, и даже "добрые" персонажи занимаются геноцидом мобов, борьба со "злом" идёт методами самих "злодеев". Идеальная игра про добро должна заканчиваться тем, что злодей признал свои ошибки и исправился - стал добрым, а такого почти не бывает - герои тупо убивают карикатурного "злодея", не обременяя себя вопросами морали, как какие-то солдаты. Хороший герой должен искать путь, не состоящий на 99% из мясорубки мобов и убийства финального босса.
>скучное
Это уже твоё субъективное стремление к жести.
>Играть правильно - еще скучнее.
Интересный геймплей никак не связан с тем, чем ты в игре занимаешься. Интересный геймплей даёт тебе дозы эндорфинов. Если ты достигатор, стремящийся достичь 999 уровня, не всё ли равно, что ты будешь делать в игре - убивать или заводить друзей? Главное, чтобы действия давали очки опыта, от которых у тебя происходит всплеск гормонов удовольствия.
>выпиливать города скайрима
>игра за такое дает понять что ты портишь негласный договор и наказывает тебя закрытием возможностей.
Ты разве не понимаешь? Игра завязана на квесты, ты получаешь квесты от неигровых персонажей в строго определённых дизайнером уровней местах. Если ты сбрасываешь атомную бомбу на это место, то как ты планируешь потом брать квесты? Или игра должна спамить тебе новых случайных квестодателей? Чаще всего эту проблему решают бессмертием персонажей.
Ты, наверное, сюжет в квестах вообще не читал, и воспринимаешь их только как точки входа в новые активности на карте. Это значит, что жанр РПГ не для тебя, тебе больше подойдут слешеры - там не нужно много читать, зато нужно много рубить мобов.
>злодеи против злодеев
Большинство игр в этой категории, см. выше. Смешно смотреть на "героя", все геройства которого состоят из массовой резни зачастую маленьких и слабых мобов. Начинают путь буквально с истребления малышей, пока не объявится рассерженная огромная самка...
>>07395
Проверил, фигня какая то топдаун колония
Проверил, фигня какая то топдаун колония
>>07152 (OP)
Изучаю тут Obsidian, и мне так понравился Markdown. Насколько сложно будет прикрутить Markdown к игре на Godot? Мне нужно будет выводить информацию, а использовать BB-коды для выделения не хочется.
>>07554
Прежде чем игру делать, нужно диздок написать...
Изучаю тут Obsidian, и мне так понравился Markdown. Насколько сложно будет прикрутить Markdown к игре на Godot? Мне нужно будет выводить информацию, а использовать BB-коды для выделения не хочется.
>>07554
Прежде чем игру делать, нужно диздок написать...
Годаны, памагитя.
Пытаюсь запилить в своей игре режим "fallback to GLES2". Для этого написал ноду, которая заменяет найденные Particles2D на CPUParticles2D при помощи функции convert_from_particles(source_node). И столкнулся со странным.
Сразу оговорюсь. Если открыть (просто открыть) проект в режиме GLES2, то некоторые шейдеры забудут свои параметры, баг Годота. Поэтому для тестов я запускаю в GLES3, но в конвертилке вырубаю проверку видеодрайвера, и она всё равно конвертит партикли в цпушные. Смотрю дерево в рантайме - да, они цпу.
Но вот я делаю экспорт и запускаю с параметром --video-driver GLES2. И по неизвестной причине некоторые партикли не вижу (а некоторые вижу). Очевидно, я где-то накосячил в скрипте.
И теперь вопрос. Как это отдебагать?
а) Запустить с драйвером GLES2, но чтобы редактор был GLES3 - возможно ли?
б) Посмотреть дерево сцены уже экспортнутого проекта - как?
Пытаюсь запилить в своей игре режим "fallback to GLES2". Для этого написал ноду, которая заменяет найденные Particles2D на CPUParticles2D при помощи функции convert_from_particles(source_node). И столкнулся со странным.
Сразу оговорюсь. Если открыть (просто открыть) проект в режиме GLES2, то некоторые шейдеры забудут свои параметры, баг Годота. Поэтому для тестов я запускаю в GLES3, но в конвертилке вырубаю проверку видеодрайвера, и она всё равно конвертит партикли в цпушные. Смотрю дерево в рантайме - да, они цпу.
Но вот я делаю экспорт и запускаю с параметром --video-driver GLES2. И по неизвестной причине некоторые партикли не вижу (а некоторые вижу). Очевидно, я где-то накосячил в скрипте.
И теперь вопрос. Как это отдебагать?
а) Запустить с драйвером GLES2, но чтобы редактор был GLES3 - возможно ли?
б) Посмотреть дерево сцены уже экспортнутого проекта - как?
>>07398
Ну и что с того? Они ж ничего не делают всё равно. Чего ты к этим связям-то так привязался?
>>07350
Хотлайн Майами, серия Постал, Мэнхант сразу на ум приходят.
Ну, последствия будут не столько правовые (правоохранителям похеру, если в игре нет призывов к реальному нарушению законодательству), сколько твиттерные. На такую игру набросится вся прогрессивная общественность и будет бесплатно рекламироать. Хотя, конечно, для начала этого процесса всё равно привлечь внимание, не быть нонейм индюком, например.
>>07343
За себя говори. А кто-то отыгрывает винтик системы в Контрабанд Полис.
>>07319
Кобольды влезли на нашу базу и своровали ценный артефакт. Контрабандист даванул педаль в пол прямо через шлагбаум. Наркокурьер, с которого можно выбить бабос.
Легко придумать объяснение, почему эти существа не такие уж безобидные.
А ещё напомню, что Гордон Фримен давил безобидных беззащитных гусеничек ради 2-3 ХП, удовлетворительного звука и ачивки.
>тогда граф твоего автомата будет представлять из себя огромный клубок нитей.
Ну и что с того? Они ж ничего не делают всё равно. Чего ты к этим связям-то так привязался?
>>07350
Хотлайн Майами, серия Постал, Мэнхант сразу на ум приходят.
Ну, последствия будут не столько правовые (правоохранителям похеру, если в игре нет призывов к реальному нарушению законодательству), сколько твиттерные. На такую игру набросится вся прогрессивная общественность и будет бесплатно рекламироать. Хотя, конечно, для начала этого процесса всё равно привлечь внимание, не быть нонейм индюком, например.
>>07343
>Быть правильным скучно. Играть правильно - еще скучнее.
За себя говори. А кто-то отыгрывает винтик системы в Контрабанд Полис.
>>07319
>игрок агрессор и негодяй, обижающий безобидных существ.
Кобольды влезли на нашу базу и своровали ценный артефакт. Контрабандист даванул педаль в пол прямо через шлагбаум. Наркокурьер, с которого можно выбить бабос.
Легко придумать объяснение, почему эти существа не такие уж безобидные.
А ещё напомню, что Гордон Фримен давил безобидных беззащитных гусеничек ради 2-3 ХП, удовлетворительного звука и ачивки.
>>07152 (OP)
Аноны, можете объяснить в чем разница _process и _ready
Читаю документацию, и делаю по ней штуки и не понимаю почему обе функции ведут себя одинаково, хотя судя по референс описанию не должны, я даже ради эксперимента комментил всю _ready функцию и переносил её содержимое в конец _process, ничего не поменялось и иконка продолжила мигать с секундной периодичностью.
Как я понял _process запускается при каждом тике игры, тогда как _ready когда то к чему оно привязяно появляется на сцене. А значит эта функция должна была один раз вызваться при появлении иконки, которая появилась вместе со всем остальным при запуске сцены, и больше не вызываться.
https://docs.godotengine.org/en/stable/getting_started/step_by_step/signals.html
Аноны, можете объяснить в чем разница _process и _ready
Читаю документацию, и делаю по ней штуки и не понимаю почему обе функции ведут себя одинаково, хотя судя по референс описанию не должны, я даже ради эксперимента комментил всю _ready функцию и переносил её содержимое в конец _process, ничего не поменялось и иконка продолжила мигать с секундной периодичностью.
Как я понял _process запускается при каждом тике игры, тогда как _ready когда то к чему оно привязяно появляется на сцене. А значит эта функция должна была один раз вызваться при появлении иконки, которая появилась вместе со всем остальным при запуске сцены, и больше не вызываться.
https://docs.godotengine.org/en/stable/getting_started/step_by_step/signals.html
>>07613
Попробуй это, но сам я не пробовал:
https://docs.godotengine.org/en/3.6/tutorials/scripting/debug/overview_of_debugging_tools.html#deploy-with-remote-debug
Ну, ты всегда можешь просто print...
https://docs.godotengine.org/en/3.6/classes/class_node.html#class-node-method-print-tree
>Как это отдебагать?
Попробуй это, но сам я не пробовал:
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
>>07346
А мне всегда казалось наоборот,
Играешь за добряка, помогаешь людям, эти чуваки потом встречаюстся дальше по сюжету и могут ещё каких квестов подкинуть.
Играешь за злодея, и либо сам выпиливаешь ради выгоды, либо следуя отыгрышу игноришь не свои проблему участие в которых не пахнет богатствами таким образом добровольно обрезая себе контент.
Тот же BG3 которую много кто хвалит за вариативность, я пока только в первом акте, играю за жадную до могущества прагматично злую высшую эльфийку волшебницу школы прорицания. Судя по тому что я слышал, "злой выбор" вырезать рощу друидов, что заставляет отвернуться от тебя целую пачку компаньонов и не дает какой-то иной особой альтернативы помимо одной дроу которую ты не факт что возьмешь.
Единственная известная мне игра где реально хорошо прописано злодейский путь это Tyrrany, и то только потому что там сеттинг победившей империи зла и мы её агент.
Я просто обожаю прагматичных злодеев и хочу видеть больше книг, игр и т.д. с такими на главной роли, и нет не потому что я школоивел, а потому что все известные мне примеры, пиздец волевые и целеустремленные челы, тогда как я сам тот ещё рохля в этом плане.
А мне всегда казалось наоборот,
Играешь за добряка, помогаешь людям, эти чуваки потом встречаюстся дальше по сюжету и могут ещё каких квестов подкинуть.
Играешь за злодея, и либо сам выпиливаешь ради выгоды, либо следуя отыгрышу игноришь не свои проблему участие в которых не пахнет богатствами таким образом добровольно обрезая себе контент.
Тот же BG3 которую много кто хвалит за вариативность, я пока только в первом акте, играю за жадную до могущества прагматично злую высшую эльфийку волшебницу школы прорицания. Судя по тому что я слышал, "злой выбор" вырезать рощу друидов, что заставляет отвернуться от тебя целую пачку компаньонов и не дает какой-то иной особой альтернативы помимо одной дроу которую ты не факт что возьмешь.
Единственная известная мне игра где реально хорошо прописано злодейский путь это Tyrrany, и то только потому что там сеттинг победившей империи зла и мы её агент.
Я просто обожаю прагматичных злодеев и хочу видеть больше книг, игр и т.д. с такими на главной роли, и нет не потому что я школоивел, а потому что все известные мне примеры, пиздец волевые и целеустремленные челы, тогда как я сам тот ещё рохля в этом плане.
>>07454
Это конечно не игра, но для тебя есть идеальное аниме, наруто, очень многие противники либо просто исправляются, либо исправляются и жертвуют собой что бы искупить грехи. Там даже есть один злодей, Орочимару, который "исправился" тем, что перестал быть антагонистом, и то по большей части потому что он получил возможность жить вечно в искусственно созданных телах из клеток Хаширамы.
Да и как ты себе пресдставляешь перевоспитание злых инопланетян для которых убийства и грабеж норма? а именно так и происходит в большинстве фентези сеттингов, белый ну или серый герой сражается против объективно черных сил, которые по самой своей природе злые, нежить, демоны, монсты, всякие варварские зверолюдные рассы, начиная орками и гоблинами и заканчивая гноллами и людоящерами. В старых редакциях днд, было порядочное мировозрение, нейтральное и хаотичское, и группа персонажей была представителями сил порядка, которые ходят в походы в земли хаоса с целью разбогатеть и прославиться.
>Идеальная игра про добро должна заканчиваться тем, что злодей признал свои ошибки и исправился - стал добрым
Это конечно не игра, но для тебя есть идеальное аниме, наруто, очень многие противники либо просто исправляются, либо исправляются и жертвуют собой что бы искупить грехи. Там даже есть один злодей, Орочимару, который "исправился" тем, что перестал быть антагонистом, и то по большей части потому что он получил возможность жить вечно в искусственно созданных телах из клеток Хаширамы.
Да и как ты себе пресдставляешь перевоспитание злых инопланетян для которых убийства и грабеж норма? а именно так и происходит в большинстве фентези сеттингов, белый ну или серый герой сражается против объективно черных сил, которые по самой своей природе злые, нежить, демоны, монсты, всякие варварские зверолюдные рассы, начиная орками и гоблинами и заканчивая гноллами и людоящерами. В старых редакциях днд, было порядочное мировозрение, нейтральное и хаотичское, и группа персонажей была представителями сил порядка, которые ходят в походы в земли хаоса с целью разбогатеть и прославиться.
>>07623
Если хочешь подрочить ты в _ready снимаешь штаны и берешь в руку хуй. Дрочишь уже в _process.
Если обратиться к хую до того как он инициализируется - будет ошибка
>_process запускается при каждом тике игры
>_ready срабатывает при создании ноды один раз
Если хочешь подрочить ты в _ready снимаешь штаны и берешь в руку хуй. Дрочишь уже в _process.
Если обратиться к хую до того как он инициализируется - будет ошибка
>>07623
Ты про какую функцию? Про эту?
У тебя таймером генерируется сигнал, а эта функция - обработчик сигнала, который вызывается всякий раз, когда генерируется сигнал. В _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.
>эта функция должна была один раз вызваться при появлении иконки
Ты про какую функцию? Про эту?
>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.
>>07630
Показать им, что любовь и доброта это заебись, круто и вообще хайповая тема.
>злых инопланетян для которых убийства и грабеж норма
Показать им, что любовь и доброта это заебись, круто и вообще хайповая тема.
>>07625
Работает, хоть и довольно странно. После первого запуска зацепляется к хттп-серверу, и пока его не остановишь, повторно подключиться не даёт. А остановить можно только запустив хтмл-билд, и тогда под этой кнопкой появится кнопка остановить сервер. Или я просто не знаю, где ещё искать.
Впрочем, работает же.
Просто принта не достаточно. Открыть свойства ноды, посмотреть, что с ней не так, глянуть другую и т.д.
В общем, аригато, анонче, пофиксил баг.
>Попробуй это
Работает, хоть и довольно странно. После первого запуска зацепляется к хттп-серверу, и пока его не остановишь, повторно подключиться не даёт. А остановить можно только запустив хтмл-билд, и тогда под этой кнопкой появится кнопка остановить сервер. Или я просто не знаю, где ещё искать.
Впрочем, работает же.
>всегда можешь просто print
Просто принта не достаточно. Открыть свойства ноды, посмотреть, что с ней не так, глянуть другую и т.д.
В общем, аригато, анонче, пофиксил баг.
Кто-нибудь ИТТ достиг значимых значений в гугл-плее? Это реально вообще? Игра не показывается по полному названию в поиске гплея, только если с кавычками искать. Вообще охуеть.
>>07732
Блин ты что сам туда полез? По моему так уже лет 5 не работает. Ничего не могу посоветовать, извини, сам буду издателя искать через годик.
Блин ты что сам туда полез? По моему так уже лет 5 не работает. Ничего не могу посоветовать, извини, сам буду издателя искать через годик.
>>07732
Я пока целюсь на итч+вкплей+ЯИ. Если на этих сервисах моя игра будет кому-то интересна, тогда можно и расширять охват.
Кстати, анончики, подкиньте ещё сервисов, куда можно закинуть.
Я пока целюсь на итч+вкплей+ЯИ. Если на этих сервисах моя игра будет кому-то интересна, тогда можно и расширять охват.
Кстати, анончики, подкиньте ещё сервисов, куда можно закинуть.
>>07750
В чем суть? Продаешь им своего игоря и получаешь процент? Я просто не хочу чтобы мою игру, над которой я душевно работал, завалили десятком говнореклам настолько, что игры не видно.
>издателя
В чем суть? Продаешь им своего игоря и получаешь процент? Я просто не хочу чтобы мою игру, над которой я душевно работал, завалили десятком говнореклам настолько, что игры не видно.
>>07759
Лол
Лол
>>07757
kongregate если он еще жив
kongregate если он еще жив
>>07759
В инди сегменте это значит, что находишь того, кто вываливает твою игру в магазин и обеспечивает какую-никакую рекламу за процент от продаж.
В инди сегменте это значит, что находишь того, кто вываливает твою игру в магазин и обеспечивает какую-никакую рекламу за процент от продаж.
>>07759
Я вообще хз как там сейчас.
У тебя игра бесплатная скорее всего и соревнуешься ты с другими бесплатными от фирм тупо вливающих миллионы в рекламу и показывающих рекламу.
Хотя конечно какие то игры с вменяемой схемой видел, например Eternal Senia 80000 отзывов.
По идее все живут на том, чтобы задолбать рекламой и добавить опцию отключения, то есть по сути заставить купить игру, плюс манипуляция расходниками, когда ты проиграл а тебе говорят вот купи бутылочку, с ней ты победишь и не потеряешь прогресс.
Я вообще хз как там сейчас.
У тебя игра бесплатная скорее всего и соревнуешься ты с другими бесплатными от фирм тупо вливающих миллионы в рекламу и показывающих рекламу.
Хотя конечно какие то игры с вменяемой схемой видел, например Eternal Senia 80000 отзывов.
По идее все живут на том, чтобы задолбать рекламой и добавить опцию отключения, то есть по сути заставить купить игру, плюс манипуляция расходниками, когда ты проиграл а тебе говорят вот купи бутылочку, с ней ты победишь и не потеряешь прогресс.
>>07822
Да на самом деле ничего особо интересно, просто фиксят баги, улучшают стабильность, иногда доносят фичи, часто в GLES2 добавляют что-то из GLES3, немного улучшают перформанс. Допиливают fixed step interpolation. LTS короче.
Да на самом деле ничего особо интересно, просто фиксят баги, улучшают стабильность, иногда доносят фичи, часто в GLES2 добавляют что-то из GLES3, немного улучшают перформанс. Допиливают fixed step interpolation. LTS короче.
>>07791
Что завезли, если по сути?
Что завезли, если по сути?
>>07861
Стим - это если игру продавать будешь. А у меня пока не тот масштаб. План пока такой: сначала игру 1.0 лью на бесплатные площадки-помойки, прощупываю аудиторию, может, какую фанбазу изначальную сформирую; потом либо буду пилить игру 2.0 и продавать её за деняки, либо (если 1.0 не зайдёт публике) запущу совсем другой проект гиперказуалку с рекламой для ЯИ.
Не, славься пресвятой Габен и всё такое, но туда, мне кажется, надо идти с бюджетом, пусть даже небольшим.
>>07822
Ну скажем, четвёрка не годится для веба и мобилок, а это так-то огромный и всё ещё довольно просторный рынок.
Стим - это если игру продавать будешь. А у меня пока не тот масштаб. План пока такой: сначала игру 1.0 лью на бесплатные площадки-помойки, прощупываю аудиторию, может, какую фанбазу изначальную сформирую; потом либо буду пилить игру 2.0 и продавать её за деняки, либо (если 1.0 не зайдёт публике) запущу совсем другой проект гиперказуалку с рекламой для ЯИ.
Не, славься пресвятой Габен и всё такое, но туда, мне кажется, надо идти с бюджетом, пусть даже небольшим.
>>07822
Ну скажем, четвёрка не годится для веба и мобилок, а это так-то огромный и всё ещё довольно просторный рынок.
>>07871
шарповая четверка как и тройка таки не годится да. хотя в 4.2 есть уже ограниченная поддержка а с обычной версией какая проблемма то?
шарповая четверка как и тройка таки не годится да. хотя в 4.2 есть уже ограниченная поддержка а с обычной версией какая проблемма то?
>>07927
Будет. Успеют.
Будет. Успеют.
И все же, где найти тестировщиков? Друзья-знакомые это мало. Если выкладывать каждый стабильный билд на итче с меткой "прототип" - кто-нибудь туда вообще зайдет?
>>07941
Значение знаешь?
На двач закидывай, очевидно же. На другие форумы. Ты ж не ААА студия, у тебя нет секретов от народа.
>стабильный билд
>с меткой "прототип"
Значение знаешь?
>где найти тестировщиков?
На двач закидывай, очевидно же. На другие форумы. Ты ж не ААА студия, у тебя нет секретов от народа.
>>07941
бартер тестами с другими индюками
бартер тестами с другими индюками
>>07941
Почему мало? Сколько тебе тестеров вообще нужно?
Почему мало? Сколько тебе тестеров вообще нужно?
>>07941
Не очень понятен твой вопрос. Ну я могу работать qa инженером хотт фулл тайм. Но ты наверное имел в виду что то другое, просто фанатов за бесплатно?
Не очень понятен твой вопрос. Ну я могу работать qa инженером хотт фулл тайм. Но ты наверное имел в виду что то другое, просто фанатов за бесплатно?
Перепост
Аноны подскажите пж, хочу сделать редактор уровней супер марио брос, но оказалось что я слишком тупой даже для этого.
Базовая концепция следующая:
1. Пользователь выбирает тайл
2. Пользователь ставит тайл на поле
3. Пользователь нажимает кноку сохранить
4. Тайлмапа конвертится в json (или сразу создается параллельный словарь который после сохраняется как json)
5. При загрузке просто расставляем обжекты по json'у
Тут все логично лаконично и понятно, но вопрос у меня больше по технической составляющей визуала.
Мне очевидно требуется сетка, начало отсчета координат и границы. В этом плане я выбрал пока примерно позицию нулевая позиция х:0 y: 300 16. Пределы соответствующие, слева сверху нули, снизу и справа 300 16. Интро к вопросу долгое но похуй.
То что меня волнует сейчас больше всего - как рисовать сетку? Мне нужна сетка что бы юзер не терялся очевидно. Как то разделять тайлы и прочее. Возможно даже как в оригинальном редакторе godot'a когда рисуешь что-то тайлами там такая небольшая обводка в виде сетки. У меня конечно последние недели времени много времени подумать над этим небыло, но я либо тупой либо задача реально нестандартная.
Какие есть советы?
Аноны подскажите пж, хочу сделать редактор уровней супер марио брос, но оказалось что я слишком тупой даже для этого.
Базовая концепция следующая:
1. Пользователь выбирает тайл
2. Пользователь ставит тайл на поле
3. Пользователь нажимает кноку сохранить
4. Тайлмапа конвертится в json (или сразу создается параллельный словарь который после сохраняется как json)
5. При загрузке просто расставляем обжекты по json'у
Тут все логично лаконично и понятно, но вопрос у меня больше по технической составляющей визуала.
Мне очевидно требуется сетка, начало отсчета координат и границы. В этом плане я выбрал пока примерно позицию нулевая позиция х:0 y: 300 16. Пределы соответствующие, слева сверху нули, снизу и справа 300 16. Интро к вопросу долгое но похуй.
То что меня волнует сейчас больше всего - как рисовать сетку? Мне нужна сетка что бы юзер не терялся очевидно. Как то разделять тайлы и прочее. Возможно даже как в оригинальном редакторе godot'a когда рисуешь что-то тайлами там такая небольшая обводка в виде сетки. У меня конечно последние недели времени много времени подумать над этим небыло, но я либо тупой либо задача реально нестандартная.
Какие есть советы?
>>08016
Вероятно я просто тугодум и не умею гуглить.
Сейчас нагуглил тот факт что вероятность для более менее цельных не процедурных игр на годо алгоритмы чанкирования и левел клитор нужно писать ручками, потому что экраны загрузки харам.
Такой вывод сделал из-за того что годо невероятно прожорлив и 300 на 300 примитивных 2д квадратиков сажают ФПС весьма сильно.
Я все ещё ищу годные гайды по тому как сделать ингейм левел клитор понятным. Сам алгоритм редактора уровней это не так сложно, а вот как сделать так что в нем не запутаться в первую секунду я ума не приложу.
Накидайте идей, мыслей и гайдов на этот счёт. Буду благодарен.
Вероятно я просто тугодум и не умею гуглить.
Сейчас нагуглил тот факт что вероятность для более менее цельных не процедурных игр на годо алгоритмы чанкирования и левел клитор нужно писать ручками, потому что экраны загрузки харам.
Такой вывод сделал из-за того что годо невероятно прожорлив и 300 на 300 примитивных 2д квадратиков сажают ФПС весьма сильно.
Я все ещё ищу годные гайды по тому как сделать ингейм левел клитор понятным. Сам алгоритм редактора уровней это не так сложно, а вот как сделать так что в нем не запутаться в первую секунду я ума не приложу.
Накидайте идей, мыслей и гайдов на этот счёт. Буду благодарен.
>>08018
Оу щит, не клитор, а едитор.
Оу щит, не клитор, а едитор.
>>08016
Тут возникает вопрос, если у тебя марио игра где в редакторе расставляются по сетке, то зачем потом используются объекты, а не тайлмап?
Тут возникает вопрос, если у тебя марио игра где в редакторе расставляются по сетке, то зачем потом используются объекты, а не тайлмап?
>>08020
Вероятно я где то был не точен или я неправильно вопрос понял. У тайлмапа есть плюс в виде оптимизированной работы с большим количеством тайлов и с простотой отрисовки, но есть и минусы в виде меньшего контроля за каждым отдельно взятым тайлом. Если основной граунд можно отрисовать тайлмапой, то знаки вопросиков например (или знаки on и off из super mario maker) уже сделать вроде как нельзя.
Плюс по моим экспериментам большие тайлмапы все равно предательски лагают. Из-за этого я и начал смотреть в сторону чанкирования карт.
Вероятно я где то был не точен или я неправильно вопрос понял. У тайлмапа есть плюс в виде оптимизированной работы с большим количеством тайлов и с простотой отрисовки, но есть и минусы в виде меньшего контроля за каждым отдельно взятым тайлом. Если основной граунд можно отрисовать тайлмапой, то знаки вопросиков например (или знаки on и off из super mario maker) уже сделать вроде как нельзя.
Плюс по моим экспериментам большие тайлмапы все равно предательски лагают. Из-за этого я и начал смотреть в сторону чанкирования карт.
>>08036
Рисуешь статичные тайлы тайлмапой, а динамические объекты спавнишь по необходимости. Проблемы?
Ты на 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. Сдвигай её с шагом, равным одному тайлу:
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
>Я все ещё ищу годные гайды по тому как сделать ингейм левел клитор понятным.
Делаешь палитру блоков и всё, что ещё надо?
>клитор нужно ручками
Да. Вот так. Продолжай.
>>08036
Рисуешь статичные тайлы тайлмапой, а динамические объекты спавнишь по необходимости. Проблемы?
Ты на 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. Сдвигай её с шагом, равным одному тайлу:
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
>Я все ещё ищу годные гайды по тому как сделать ингейм левел клитор понятным.
Делаешь палитру блоков и всё, что ещё надо?
>клитор нужно ручками
Да. Вот так. Продолжай.
>>08048
Перепутал немного, нужно не дельту сдвига мыши, а актуальную позицию мыши относительно начала координат/сетки тайлов:
Может, есть метод проще...
...а, точно, есть:
https://docs.godotengine.org/en/stable/classes/class_vector2.html#class-vector2-method-snapped
Тогда просто:
>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)
16,1 Мб, webm,1920x1080, 0:28
Все таки надо допилить бенчмарк. Он тут еще времен когда в 3ке не было 2д батчинга
>>08052
Спасибо мужик, от души душевно в душу. Я от чего то даже и не подумал про перемещение. Я же по концепту хотел фоновую сетку крупную что бы общее положение пользователя на поле не терялось, думал что отрисовывать ее каждый раз заново единственный вариант. За вариант с движением спасибо огромное.
Спасибо мужик, от души душевно в душу. Я от чего то даже и не подумал про перемещение. Я же по концепту хотел фоновую сетку крупную что бы общее положение пользователя на поле не терялось, думал что отрисовывать ее каждый раз заново единственный вариант. За вариант с движением спасибо огромное.
>>08048
Касательно вьюпорта я не особо понял. Смысл же не только в том что конкретно тайлмапы лагают. Допустим я потенциально захочу какое нибудь РПГ с грабежом караванов в топ даун 2д, даже если самое поле тайловое я оптимизирую, то несколько сот объектов просто убьют всю производительность. Моё негодование тут скорее конкретно про вот этот аспект было, но конкретно для Марио тайлмап + объекты по ощущениям самый оптимальный вариант.
Касательно вьюпорта я не особо понял. Смысл же не только в том что конкретно тайлмапы лагают. Допустим я потенциально захочу какое нибудь РПГ с грабежом караванов в топ даун 2д, даже если самое поле тайловое я оптимизирую, то несколько сот объектов просто убьют всю производительность. Моё негодование тут скорее конкретно про вот этот аспект было, но конкретно для Марио тайлмап + объекты по ощущениям самый оптимальный вариант.
>>08048
Но я завтра ещё со свежей головой все перепрочту, ещё раз спасибо огромное. Гуглил как сделать эту сетку наверное дня два.
Но я завтра ещё со свежей головой все перепрочту, ещё раз спасибо огромное. Гуглил как сделать эту сетку наверное дня два.
>>08079
Аргумент. Сонный перепутал 100 и 100 * 100
Аргумент. Сонный перепутал 100 и 100 * 100
в качестве совсем ебанутого варианта всегда можно поверх тайлмепа натянуть плоскость с ворлдспейс шейдером, который будет рисовать сетку с прозрачностью, подсветками и прочими фишками
мимо
мимо
29 Кб, 641x521>>08095
Помню кто то тут показывал сетку без единой строчки кода.
В тайлмапах же можно расставлять сцены вместо тайлов. (Начиная с 4ки). Ну и нарисовать сцену уголок из Line2D
Помню кто то тут показывал сетку без единой строчки кода.
В тайлмапах же можно расставлять сцены вместо тайлов. (Начиная с 4ки). Ну и нарисовать сцену уголок из Line2D
>>08100
Я уже справился обычной node 2d и несколькими ректанглами. Вот прочел про бетчинг, думаю разобраться поглубже, мб можно как то 30*50 ректанглов оптимизировать оптимизировать.
А вот насчёт сцен в тайлмапах не знал, огненная тема по идее для моей задумки.
Я уже справился обычной node 2d и несколькими ректанглами. Вот прочел про бетчинг, думаю разобраться поглубже, мб можно как то 30*50 ректанглов оптимизировать оптимизировать.
А вот насчёт сцен в тайлмапах не знал, огненная тема по идее для моей задумки.
4,1 Мб, mp4,800x600, 2:01
>>08147
Низкой производительности бояться - игру не делать. Преждевременная оптимизация - корень всех зол.
>оптимизировать оптимизировать
Низкой производительности бояться - игру не делать. Преждевременная оптимизация - корень всех зол.
Бля, подскажите, заебался. У меня есть навигационная меш. Я ее запекаю из редактора (кнопка bake navmesh), все ок, показывается что она обновляется. Запускаю игру - показывается старая версия запечения, которую я сделал еще пару дней назад. Перезапускаю редактор - теперь и в редакторе старая версия запечения. Будто что-то где-то закешировалось, но я хуй знает, каталог .import удалял - не спасло.
>>08180
Разобрался через минуту после поста. Я ее в прошлый раз задублировал и забыл про это. Помогло ПКМ -> make unique
Разобрался через минуту после поста. Я ее в прошлый раз задублировал и забыл про это. Помогло ПКМ -> make unique
Годаны, если у меня нода находится вне дерева, ей надо при выходе из приложения делать queue_free()? Или, может, free()? Или пусть движок сам подчищает?
И вообще. Откуда берутся leaked instance'ы на выходе? Как с этим бороться? Я всего лишь открыл уровень и тут же закрыл игру, а они наутекали.
И вообще. Откуда берутся leaked instance'ы на выходе? Как с этим бороться? Я всего лишь открыл уровень и тут же закрыл игру, а они наутекали.
>>08287
Ищи протечку. Срёшь поди всякими .new() вникуда.
>Я всего лишь открыл уровень и тут же закрыл игру, а они наутекали.
Ищи протечку. Срёшь поди всякими .new() вникуда.
Ребят, пилю потихоньку 2д игру видом сбоку, и не знаю как лучше делать локи, через тайлсеты или сразу нарисовать, если рисовать мне кажется что что-то менять неудобно будет потом
>>08325
Не парься, через тайлсеты тоже будет неудобно потом. Делай, в процессе наловчишься.
Не парься, через тайлсеты тоже будет неудобно потом. Делай, в процессе наловчишься.
>>08326
Жиза. Третью игру делаю, третий раз думаю "ну вот сейчас то я удобную систему создания локаций запилил", а потом боль-унижение. Похоже без кропотливого ручного труда в этом деле никуда, если у тебя не процедурное.
Жиза. Третью игру делаю, третий раз думаю "ну вот сейчас то я удобную систему создания локаций запилил", а потом боль-унижение. Похоже без кропотливого ручного труда в этом деле никуда, если у тебя не процедурное.
>>08287
Проверь, если куй-фри срабатывает, делай куй-фри, если нет - делай фри. Куй-фри отличается только тем, что проверяет, нагрузку на движок (если по простому) и если нагрузка минимальна, он вызывает фри. Соответственно, если нода не в дереве, у неё не срабатывают процесс-колбэки, и вполне вероятно, что куй-фри не знает о том, нагрузка есть или нет.
> нода находится вне дерева, ей надо при выходе из приложения делать queue_free()? Или, может, free()?
Проверь, если куй-фри срабатывает, делай куй-фри, если нет - делай фри. Куй-фри отличается только тем, что проверяет, нагрузку на движок (если по простому) и если нагрузка минимальна, он вызывает фри. Соответственно, если нода не в дереве, у неё не срабатывают процесс-колбэки, и вполне вероятно, что куй-фри не знает о том, нагрузка есть или нет.
>>08052
Пробовал snapped но отсчёт тайла говено происходит, поскольку там идёт дефолтное округление, а надо просто отрезать десятичную часть.
Мой метод поиска тайла Vector2i(get_global_mouse_position() / tile_size)
Пробовал snapped но отсчёт тайла говено происходит, поскольку там идёт дефолтное округление, а надо просто отрезать десятичную часть.
Мой метод поиска тайла Vector2i(get_global_mouse_position() / tile_size)
>>08398
А теперь, если я уберу строку 7, то тест-нода уже не получает уведомлений и не выгружается:
А теперь, если я уберу строку 7, то тест-нода уже не получает уведомлений и не выгружается:
31 Кб, 478x203>>08399
Лол, знаете, что? Я прописал оверрайд на queue_free() в обычную ноду, и знаете что? При остановке проекта она тоже не срабатывает. То есть, у меня есть большие сомнения насчёт того, чистит ли движок память после себя в принципе? Я не настолько кодер, чтобы делать выводы, насколько это правильно, но предполагается, что при остановке приложения оно должно чистить память. Вероятно, Хуан подумал, что память всё равно почистит система, после удаления процесса, поэтому не заморачивался? Или я чего-то не понимаю?
Выглядит всё так, что при закрытии окна, останавливается майнлуп, а все ресурсы продолжают висеть в памяти, пока винда/линух её не вычистит сама после убитого процесса.
Лол, знаете, что? Я прописал оверрайд на queue_free() в обычную ноду, и знаете что? При остановке проекта она тоже не срабатывает. То есть, у меня есть большие сомнения насчёт того, чистит ли движок память после себя в принципе? Я не настолько кодер, чтобы делать выводы, насколько это правильно, но предполагается, что при остановке приложения оно должно чистить память. Вероятно, Хуан подумал, что память всё равно почистит система, после удаления процесса, поэтому не заморачивался? Или я чего-то не понимаю?
Выглядит всё так, что при закрытии окна, останавливается майнлуп, а все ресурсы продолжают висеть в памяти, пока винда/линух её не вычистит сама после убитого процесса.
>>08401
память да почистится. для отдельно запущенного приложения. с отладочным запуском из движка скорее всего будет копится мусор пока не закроешь годот
память да почистится. для отдельно запущенного приложения. с отладочным запуском из движка скорее всего будет копится мусор пока не закроешь годот
>>08402
Окей, щас соберу релиз тестового проекта. Прям аж интересно стало.
Окей, щас соберу релиз тестового проекта. Прям аж интересно стало.
16 Кб, 335x2052d платформер
Почему при подъеме на угол или спуске визуально изменяется скорость движения персонажа? При этом, если выводить velocity, то остается без изменений. Godot 4
Если поставить галку constant speed у игрока, то скорость не меняется и все норм. В чем подвох этой галки?
Почему при подъеме на угол или спуске визуально изменяется скорость движения персонажа? При этом, если выводить velocity, то остается без изменений. Godot 4
Если поставить галку constant speed у игрока, то скорость не меняется и все норм. В чем подвох этой галки?
>>08398
Лень проверять, но queue_free может и не влиять на ноды не в дереве, попробуй free. Мои рассуждения такие, смысл queuefree отложить до след. промежутка между кадрами, но если она не в дереве ей _notification может и не рассылают.
Лень проверять, но queue_free может и не влиять на ноды не в дереве, попробуй free. Мои рассуждения такие, смысл queuefree отложить до след. промежутка между кадрами, но если она не в дереве ей _notification может и не рассылают.
>>08409
Ля, спасибо
Ля, спасибо
>>08411
Мои рассуждения я изложил выше. Приложение обязано освободить все объекты перед выходом. Я наблюдаю обратное.
Мои рассуждения я изложил выше. Приложение обязано освободить все объекты перед выходом. Я наблюдаю обратное.
>>08417
Всё таки, высвобождение ресурсов происходит, но так, что оверрайды мною назначенные в скриптах, не отрабатывают. Потому что если сделать ноду и не освободить её, в консоли будет соответствующая инфа. Если же всё что сам создал, сам и освободишь, инфы не будет. Причём в редакторе ничего не пишется, редактор молчит. Инфа пишется только на экспортнутом проекте.
Всё таки, высвобождение ресурсов происходит, но так, что оверрайды мною назначенные в скриптах, не отрабатывают. Потому что если сделать ноду и не освободить её, в консоли будет соответствующая инфа. Если же всё что сам создал, сам и освободишь, инфы не будет. Причём в редакторе ничего не пишется, редактор молчит. Инфа пишется только на экспортнутом проекте.
847 Кб, 1366x768Привет пацаны это я тот самый чел который делает игру про ангелицу. Вот я леплю свой уровень для игрыыы. А вы чем заняты? Хотел ещё спросить: есть гайды по созданию стрельбы хорошие? Скиньте пожалуйста.
>>08443
Спасибо! А вот по такому случаю есть какие-то решения? Нужно создать заборчик текстурой, типа как в голдсурсовских играх, и честно говоря пиздец я ебался с этой хуйнёй. В хаммере в два клика такое делается. тут же пиздец. Суть проблемы: Годот размывает текстуру и не видит то что текстура прозрачная, т.е. вот этой черноты быть не должно. Вот как выглядит этот заборчик в редакторе(пик 2):
Спасибо! А вот по такому случаю есть какие-то решения? Нужно создать заборчик текстурой, типа как в голдсурсовских играх, и честно говоря пиздец я ебался с этой хуйнёй. В хаммере в два клика такое делается. тут же пиздец. Суть проблемы: Годот размывает текстуру и не видит то что текстура прозрачная, т.е. вот этой черноты быть не должно. Вот как выглядит этот заборчик в редакторе(пик 2):
>>08444
Я ж тебе вроде в прошлый раз отвечал? Ну проверь что там у тебя в материале стоит, там галочки для прозрачности есть.
Я ж тебе вроде в прошлый раз отвечал? Ну проверь что там у тебя в материале стоит, там галочки для прозрачности есть.
>>08294
Открыл уровень. Закрыл тестовый уровень. Вышел из игры. Утёк враг. Если его с уровня убрать, ничего не утекает. Если его убить, тоже не утекает. Враг дитя уровня, должен куефришиться вместе с уровнем, но вот нет.
Всяких там new() в этом куске нет. А что есть - добавляется в перестраховочный список подчищатора и подчищается при выходе.
>>08398
Вот такой херни у меня вообще не наблюдается. Зато в изобилии "Resource still i use" и "Orphan StringName".
>>08419
Вот да, тут вообще странно. Как будто предполагается, что я не должен об этом беспокоиться. Я вот узнал, что у меня утекает, вообще случайно, когда консоль браузера открыл.
Открыл уровень. Закрыл тестовый уровень. Вышел из игры. Утёк враг. Если его с уровня убрать, ничего не утекает. Если его убить, тоже не утекает. Враг дитя уровня, должен куефришиться вместе с уровнем, но вот нет.
Всяких там new() в этом куске нет. А что есть - добавляется в перестраховочный список подчищатора и подчищается при выходе.
>>08398
>hidden node
Вот такой херни у меня вообще не наблюдается. Зато в изобилии "Resource still i use" и "Orphan StringName".
>>08419
>Причём в редакторе ничего не пишется, редактор молчит
Вот да, тут вообще странно. Как будто предполагается, что я не должен об этом беспокоиться. Я вот узнал, что у меня утекает, вообще случайно, когда консоль браузера открыл.
>>08498
Да как их делать-то с такими утечками памяти???
Да как их делать-то с такими утечками памяти???
>>08475
И я тоже. Пару дней назад скачал репу раст-екстеншна, в которую входит образец игоры на расте, переделанный додж да крипс. И сконпелировал всё, и экспортировал, был мужиком бля. А потом взглянул в консоль, а там аналогичное. И я тогда подумал, ну штош, видать наспех сделали. А тут такой дискасс в треде завертелся. Выходит в расте всё нормально закожено, это у годота проблемс.
> Я вот узнал, что у меня утекает, вообще случайно
И я тоже. Пару дней назад скачал репу раст-екстеншна, в которую входит образец игоры на расте, переделанный додж да крипс. И сконпелировал всё, и экспортировал, был мужиком бля. А потом взглянул в консоль, а там аналогичное. И я тогда подумал, ну штош, видать наспех сделали. А тут такой дискасс в треде завертелся. Выходит в расте всё нормально закожено, это у годота проблемс.
>>08498
Я сделоль, уже релизить собирался, а оно вот.
Я сделоль, уже релизить собирался, а оно вот.
>>08475
А вот тут ты что-то нахуевертил. В случае, когда нода добавлена в дерево - она куефришится. Пруф:
> Враг дитя уровня, должен куефришиться вместе с уровнем, но вот нет.
А вот тут ты что-то нахуевертил. В случае, когда нода добавлена в дерево - она куефришится. Пруф:
>>08498
Сидим с нейронко-тян сюжет пишем. К движку даже не прикасался несколько дней, не до этого. Там такие полеты мысли. Мы так отлично дополняем друг друга.
Сидим с нейронко-тян сюжет пишем. К движку даже не прикасался несколько дней, не до этого. Там такие полеты мысли. Мы так отлично дополняем друг друга.
>>08520
На самом деле да, тут действительно. И я даже нашёл причину.
Кароч. Враг - рыба. Плавает в воде. Вода инстанциирует партиклю с брызгами, когда в неё что-то ныряет или из неё выныривает (_on_body_entered/exited). Партикля добавляется так: self.call_deferred("add_child", splashes). Ну и потом сама себе куефришит по таймеру.
При выгрузке уровня уровня рыба как бы "выныривает" - срабатывает body_exited. Но к следующему кадру call_deferred уже не случится, некуда деферрить. Ну и остаётся висеть в памяти.
Но я нашёл совсем уж необъяснимую утечку - рыбьи мозги. Простая нода, отрабатывающая рандомное плавание влево-вправо. Вот уж что точно не добавляется, не удаляется и ни с чем, кроме этой самой рыбы, не взаимодействует. Но утекает по не выясненной пока причине.
Но в итоге, походу, всё-таки не движок виноват, а мой говнокод. Это успокаивает, так как это исправимо.
Кстати, если так, то >>08517 , возможно, действительно тот образец игры или сам раст-экстеншен подтекают.
На самом деле да, тут действительно. И я даже нашёл причину.
Кароч. Враг - рыба. Плавает в воде. Вода инстанциирует партиклю с брызгами, когда в неё что-то ныряет или из неё выныривает (_on_body_entered/exited). Партикля добавляется так: self.call_deferred("add_child", splashes). Ну и потом сама себе куефришит по таймеру.
При выгрузке уровня уровня рыба как бы "выныривает" - срабатывает body_exited. Но к следующему кадру call_deferred уже не случится, некуда деферрить. Ну и остаётся висеть в памяти.
Но я нашёл совсем уж необъяснимую утечку - рыбьи мозги. Простая нода, отрабатывающая рандомное плавание влево-вправо. Вот уж что точно не добавляется, не удаляется и ни с чем, кроме этой самой рыбы, не взаимодействует. Но утекает по не выясненной пока причине.
Но в итоге, походу, всё-таки не движок виноват, а мой говнокод. Это успокаивает, так как это исправимо.
Кстати, если так, то >>08517 , возможно, действительно тот образец игры или сам раст-экстеншен подтекают.
>>08524
Я тоже нашёл причину. Я в тот раз компилил на рабочей машине без звука. И в редакторе меня предупреждало, что звуковое устройство не обнаружено. И видимо из-за этого в движке образовывалась утечка. Сейчас я когда мне анон предъявил >>08518 я не поленился скачал и скомпилил, и нихуясе, никаких утечек на домашней пеке со звуком.
>>08518
Сорян, был неправ, действовал сгоряча.
> возможно, действительно тот образец игры или сам раст-экстеншен подтекают
Я тоже нашёл причину. Я в тот раз компилил на рабочей машине без звука. И в редакторе меня предупреждало, что звуковое устройство не обнаружено. И видимо из-за этого в движке образовывалась утечка. Сейчас я когда мне анон предъявил >>08518 я не поленился скачал и скомпилил, и нихуясе, никаких утечек на домашней пеке со звуком.
>>08518
Сорян, был неправ, действовал сгоряча.
>>08527
Ну у меня сейчас реально есть задача сделать сюжет часа на 3. Потом закончу буду думать, внки я не считаю играми, но вот экшн-рпг с диалогами с подачей сюжета уже соблазнительно. Или jrpg.
Ну у меня сейчас реально есть задача сделать сюжет часа на 3. Потом закончу буду думать, внки я не считаю играми, но вот экшн-рпг с диалогами с подачей сюжета уже соблазнительно. Или jrpg.
Продолжая сражаться с памятью...
Вот ещё что происходит непосредственно при выходе (то есть, после print("shutting down") у меня сразу get_tre().quit(), и вот в логе после "shutting down", но перед отключением от пульсаудио):
Вот ещё что происходит непосредственно при выходе (то есть, после 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.
>>08530
Мы вместе делаем. Дополняем слабые стороны друг друга, так сказать. Главное чтобы она не узнала что у меня девушка есть.
Мы вместе делаем. Дополняем слабые стороны друг друга, так сказать. Главное чтобы она не узнала что у меня девушка есть.
Я хз, может, кому пригодится.
https://docs.godotengine.org/en/3.5/classes/class_node.html#class-node-method-print-stray-nodes
Странно, что это надо делать вот так вот. При том, что в отладчике можно посмотреть количество мёртвых душ; а вот имена их посмотреть можно только таким вот образом.
Насколько я понял.
В тройке. Четвёрку не щупал на этот счёт.
И всё же очень странная херня. С одной стороны, Годот такой заботливый, сам следит за памятью и всё подчищает, если на какую-то область данных не осталось указателей. С другой - есть реальная возможность накосячить, но никто тебе об этом не расскажет и нигде не покажет, пока ты не соберёшь проект и не экспортируешь его куда-нибудь в веб. Почему при выходе из игры не печатается в консоль редактора банальное "WARNING: ObjectDB instances leaked at exit"? Почему список этих утёкших нод нельзя посмотреть в редакторе? Почему , Хуан?
Зато я стал умнее и теперь буду следить за утечками с самых ранних стадий разработки, а не разгребать из прямо перед релизом. Чего и вам, аноны, советую, не повторяйте моих ошибок. А то я там таких костылей навтыкал, чтобы не утекало, страх и ужас.
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"? Почему список этих утёкших нод нельзя посмотреть в редакторе? Почему , Хуан?
Зато я стал умнее и теперь буду следить за утечками с самых ранних стадий разработки, а не разгребать из прямо перед релизом. Чего и вам, аноны, советую, не повторяйте моих ошибок. А то я там таких костылей навтыкал, чтобы не утекало, страх и ужас.
>>08551
Полезно. Я сейчас у себя мудрю с частым удалением-восстановлением нод, таймерами и твинами, и периодически у меня выскакивают варнинги "твин проснулся, а ноды уже нет!", если приведет к утечкам пригодится твой совет.
Полезно. Я сейчас у себя мудрю с частым удалением-восстановлением нод, таймерами и твинами, и периодически у меня выскакивают варнинги "твин проснулся, а ноды уже нет!", если приведет к утечкам пригодится твой совет.
Аноны эт пиздец я целый день вчера искал где эту прозрачность включить а оказалось так легко. Пиздец я тупой. Спасибо тому анончику который подсказал! Вот теперь как этот кусок заборчика выглядит! Правда с другой стороны ещё нужно текстурку подправить, подтянуть, но в целом уже одна сторона хорошо сделана. Уф-ф. Целые две недели у меня свободны, чую я заебуся над игрой работать.
8 Кб, 678x168>>07152 (OP)
Кто-нибудь уже пользуется генератором справки?
Что я выяснил:
1. Достаточно дать скрипту имя (class_name) и он должен появиться в справке (F1 -> введите имя).
2. Все записи нужно писать после "##". В редакторе подсветка для таких строк изменяется.
3. Краткое описание скрипта пишется в самом его начале, после class_name и extends, но нужна пустая строка перед всем остальным содержимым.
4. Описание к сигналам, константам, свойствам и методам класса пишутся на строчке перед кодом.
5. Доступно форматирование - то же, какое можно найти в xml-файлах документации на гитхабе. Из того, что я сам обнаружил методом тыка:
Выделит "text" как строчку кода.
Ссылка на страницу справки о классе Node.
Ссылка на метод foo() текущего класса.
Ссылка на метод get_node() на странице Node.
Ссылка на свойство/сигнал/константу "bar".
Перенос на следующую строчку. Переносы текста внутри "##", даже если вы несколько строчек с "##" пишете, никак в документации не отображаются.
Если есть ещё какая инфа - делитесь, интересно же.
Кто-нибудь уже пользуется генератором справки?
Что я выяснил:
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]
Перенос на следующую строчку. Переносы текста внутри "##", даже если вы несколько строчек с "##" пишете, никак в документации не отображаются.
Если есть ещё какая инфа - делитесь, интересно же.
>>08655
Ценная инфа. Спасибо!
Ценная инфа. Спасибо!
>>08662
Я и делаю, на 3.5. Но кто-то же должен тестировать новые версии, чтобы багов поменьше было когда я на них перекачусь.
Я и делаю, на 3.5. Но кто-то же должен тестировать новые версии, чтобы багов поменьше было когда я на них перекачусь.
>>08287
Читать:
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
>>08401
Потому что ты не можешь оверрайдить встроенные методы встроенных классов. Т.е. можешь, конечно, но движок их вызывать не будет. Причина: если бы движок позволял оверрайдить любые методы, он был бы намного медленнее, чем сейчас.
Ничего оно не должно "чистить". Когда процесс приложения работает, он может запрашивать у ОС новые блоки памяти, а когда они ему больше не нужны - сообщать ОС "мне это больше не нужно", чтобы другие приложения могли воспользоваться. Когда процесс приложения завершается, ОС знает, что память ему больше не нужна. Важно понимать, что речь идёт о высвобождении блоков памяти, а не буквальной очистке - все данные остаются в памяти, нулями автоматом не забиваются, только "умные" механизмы компиляторов помогают неявно очищать переменные/поля объектов, иначе там всегда был бы какой-нибудь рандомный мусор.
>>08417
Кому обязано? Тебе обязано? Утечек на уровне ОС такое поведение приложения не вызывает.
>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
>Приложение обязано освободить все объекты перед выходом.
Кому обязано? Тебе обязано? Утечек на уровне ОС такое поведение приложения не вызывает.
>>08661
Блин, я всего пару часов назад скачал beta-1, создал проект и начал переписывать старые скрипты с 3.x...
>dev-snapshot-godot-4-2-beta-2/
Блин, я всего пару часов назад скачал beta-1, создал проект и начал переписывать старые скрипты с 3.x...
>>08667
Могу.
При моём самостоятельном высвобождении объекта, оверрайженая куфря работает, оверрайженная фря, да, не работает, потому что это таки деконструктор, а не просто метод.
> ты не можешь оверрайдить встроенные методы встроенных классов
Могу.
При моём самостоятельном высвобождении объекта, оверрайженая куфря работает, оверрайженная фря, да, не работает, потому что это таки деконструктор, а не просто метод.
>>08687
Ну так и работает, что тут объяснять?
Если номер поста ИТТ, то клэмп вернёт номер поста без изменений. Если номер из прошлого треда, вернёт ОП-пост, если номер несуществующий большой номер - клэмп вернёт бамплимитный пост.
Ну так и работает, что тут объяснять?
> CLAMP(пост_анона, ОП_пост, бмаплимит)
Если номер поста ИТТ, то клэмп вернёт номер поста без изменений. Если номер из прошлого треда, вернёт ОП-пост, если номер несуществующий большой номер - клэмп вернёт бамплимитный пост.
>>08690
Аааа, всё понял, спасибо! Примерно так и думал
Аааа, всё понял, спасибо! Примерно так и думал
>>08674
Именно так. Если в коде движка где-то есть вызов того же queue_free, твою функцию он не увидит.
Поэтому по умолчанию редактор выдает ошибку.
>При моём самостоятельном высвобождении
Именно так. Если в коде движка где-то есть вызов того же queue_free, твою функцию он не увидит.
Поэтому по умолчанию редактор выдает ошибку.
>>08687
Это короткая запись такой логики:
Это довольно часто в играх встречается.
Это короткая запись такой логики:
>if value < min_bound: return min_bound
>elif value > max_bound: return max_bound
>else: return value
Это довольно часто в играх встречается.
>>08711
А, это на цпп, понял.
А, это на цпп, понял.
>>08444
Тут такое дело. Во времена древних игр каждый треугольник был на счету, потому что видеокарты слишком долго их перебирали. Поэтому всякие решётки, веревки и прочее рисовали текстурой с большим количеством прозрачных пикселей.
Потом видеокарты стали быстрее и начали гриндить десятки миллионов треугольников как будто их и нет совсем. Но вот растеризация как была сложной, так и осталась, а тем более если у тебя в текстуре есть прозрачные пиксели. Поэтому в современных играх оптимальнее насрать кучу мелких полигонов в виде решетки вместо натягивания прозрачной текстуры.
Но чтобы знать наверняка, нужно тестировать. Во всяком случае у меня были серьёзные просадки в Godot из-за множества прозрачных текстур. Не зря эта опция в материале выключена по умолчанию.
>>08619
Переключи в материале решётки этот параметр:
https://docs.godotengine.org/en/stable/classes/class_basematerial3d.html#class-basematerial3d-property-cull-mode
"CULL_BACK" на "CULL_DISABLED". Тогда ты можешь полностью удалить прямоугольник с другой стороны, потому что одна текстура будет видна с двух сторон.
Надеюсь, у тебя этот материал решётки отдельно от материалов остальной сцены, иначе:
- код для прозрачных пикселей будет работать для всех текстур, даже если нет прозрачных пикселей, это очень высокая суммарная нагрузка.
- CULL_DISABLED будет рисовать лишнюю геометрию у всех остальных объектов, в зависимости от сцены это может дать слишком высокую нагрузку.
>Нужно создать заборчик текстурой, типа как в голдсурсовских играх,
>текстура прозрачная
Тут такое дело. Во времена древних игр каждый треугольник был на счету, потому что видеокарты слишком долго их перебирали. Поэтому всякие решётки, веревки и прочее рисовали текстурой с большим количеством прозрачных пикселей.
Потом видеокарты стали быстрее и начали гриндить десятки миллионов треугольников как будто их и нет совсем. Но вот растеризация как была сложной, так и осталась, а тем более если у тебя в текстуре есть прозрачные пиксели. Поэтому в современных играх оптимальнее насрать кучу мелких полигонов в виде решетки вместо натягивания прозрачной текстуры.
Но чтобы знать наверняка, нужно тестировать. Во всяком случае у меня были серьёзные просадки в Godot из-за множества прозрачных текстур. Не зря эта опция в материале выключена по умолчанию.
>>08619
>Правда с другой стороны ещё нужно текстурку подправить, подтянуть, но в целом уже одна сторона хорошо сделана.
Переключи в материале решётки этот параметр:
https://docs.godotengine.org/en/stable/classes/class_basematerial3d.html#class-basematerial3d-property-cull-mode
"CULL_BACK" на "CULL_DISABLED". Тогда ты можешь полностью удалить прямоугольник с другой стороны, потому что одна текстура будет видна с двух сторон.
Надеюсь, у тебя этот материал решётки отдельно от материалов остальной сцены, иначе:
- код для прозрачных пикселей будет работать для всех текстур, даже если нет прозрачных пикселей, это очень высокая суммарная нагрузка.
- CULL_DISABLED будет рисовать лишнюю геометрию у всех остальных объектов, в зависимости от сцены это может дать слишком высокую нагрузку.
>>08718
Только потом на плачь в треде, что ты создал гениальную архитектуру проекта, обмазанную @warning_ignore(), а он ВНЕЗАПНО И ПО НЕИЗВЕСТНОЙ ПРИЧИНЕ отказывается работать. Потом ещё какой-нибудь issue с жалобой на неуловимый баг сделаешь и обидишься на то, что этот баг не баг и фиксить не будут.
>Годот может самостоятельно без спроса закуефришить ноду. Очень страшно.
Только потом на плачь в треде, что ты создал гениальную архитектуру проекта, обмазанную @warning_ignore(), а он ВНЕЗАПНО И ПО НЕИЗВЕСТНОЙ ПРИЧИНЕ отказывается работать. Потом ещё какой-нибудь issue с жалобой на неуловимый баг сделаешь и обидишься на то, что этот баг не баг и фиксить не будут.
>>08551
Мне больше всего кажется странным, что Node у нас наследуется от Object, а не от RefCounted. Наверное, этому есть какие-то внутренние причины... Но чисто с точки зрения пользователя движка, зачем нужно иметь возможность сохранить сиротскую ноду, на которую никто больше не ссылается?
Если вы удаляете ноду через remove_child(), вы обязаны сохранить ссылку на неё, иначе потеряете к ней доступ. Теоретически, нода может сама себя добавить в дерево, если получит сигнал извне, а сигнал мог быть привязан заранее... Но вот если серьёзно, зачем может быть нужен такой костыль?
Пусть бы ноды самоудалялись, когда они никому больше не нужны. Не думаю, что это вызвало бы ощутимые проблемы с производительностью...
>>08524
Не лучше было бы иметь какое-то количество подготовленных заранее брызг? Чтобы не было, например, одновременного создания 1000 новых брызг, когда в воду упадёт большая куча вещей.
А для чего здесь call_deferred? Ошибку выдаёт? Если у тебя 100500 брызг добавляется за раз, то игра всё равно зависнет, только не сразу.
Лол, не удивлюсь, если ты где-то что-то с ней делаешь, но забыл об этом, как с брызгами.
>>08526
Линукс что ли? На Виндувс вроде есть затычка для звука, если ты её специально не отключал...
>Почему при выходе из игры не печатается в консоль редактора банальное "WARNING: ObjectDB instances leaked at exit"? Почему список этих утёкших нод нельзя посмотреть в редакторе? Почему, Хуан?
Мне больше всего кажется странным, что Node у нас наследуется от Object, а не от RefCounted. Наверное, этому есть какие-то внутренние причины... Но чисто с точки зрения пользователя движка, зачем нужно иметь возможность сохранить сиротскую ноду, на которую никто больше не ссылается?
Если вы удаляете ноду через remove_child(), вы обязаны сохранить ссылку на неё, иначе потеряете к ней доступ. Теоретически, нода может сама себя добавить в дерево, если получит сигнал извне, а сигнал мог быть привязан заранее... Но вот если серьёзно, зачем может быть нужен такой костыль?
Пусть бы ноды самоудалялись, когда они никому больше не нужны. Не думаю, что это вызвало бы ощутимые проблемы с производительностью...
>>08524
>Враг - рыба. Плавает в воде. Вода инстанциирует партиклю с брызгами, когда в неё что-то ныряет или из неё выныривает
Не лучше было бы иметь какое-то количество подготовленных заранее брызг? Чтобы не было, например, одновременного создания 1000 новых брызг, когда в воду упадёт большая куча вещей.
>Партикля добавляется так: self.call_deferred("add_child", splashes).
А для чего здесь call_deferred? Ошибку выдаёт? Если у тебя 100500 брызг добавляется за раз, то игра всё равно зависнет, только не сразу.
>Но я нашёл совсем уж необъяснимую утечку - рыбьи мозги. Простая нода, отрабатывающая рандомное плавание влево-вправо. Вот уж что точно не добавляется, не удаляется и ни с чем, кроме этой самой рыбы, не взаимодействует.
Лол, не удивлюсь, если ты где-то что-то с ней делаешь, но забыл об этом, как с брызгами.
>>08526
>компилил на рабочей машине без звука
>звуковое устройство не обнаружено.
Линукс что ли? На Виндувс вроде есть затычка для звука, если ты её специально не отключал...
>>08551
Имеет ли это смысл? Главное по-быстрому накидать прототип, поиграть в него, выбросить. Если редактор на любой Hello World будет срать ошибками вида:
Это отпугнёт новичков + будет напрягать во время прототипирования новых идей. Памяти слишком много лишней, ноды почти ничего не весят, так что на первых этапах плевать, кто там утекает.
Искать утечки памяти в прототипе - это что-то из разряда "язык без строгой типизации не язык", "язык должен быть максимально быстрым, даже если это ощутимо вредит читаемости кода" или "движок без магической оптимизации любых кривых ассетов не подходит для создания игр".
Прежде чем люди построили Титаник, они строили множество мелких судов, лодок и простых плотов. Однако, заделывание дырок в лодках и плотах не помогло избежать протечек в Титанике...
>Зато я стал умнее и теперь буду следить за утечками с самых ранних стадий разработки
Имеет ли это смысл? Главное по-быстрому накидать прототип, поиграть в него, выбросить. Если редактор на любой Hello World будет срать ошибками вида:
>WARNING: ObjectDB instances leaked at exit
Это отпугнёт новичков + будет напрягать во время прототипирования новых идей. Памяти слишком много лишней, ноды почти ничего не весят, так что на первых этапах плевать, кто там утекает.
Искать утечки памяти в прототипе - это что-то из разряда "язык без строгой типизации не язык", "язык должен быть максимально быстрым, даже если это ощутимо вредит читаемости кода" или "движок без магической оптимизации любых кривых ассетов не подходит для создания игр".
Прежде чем люди построили Титаник, они строили множество мелких судов, лодок и простых плотов. Однако, заделывание дырок в лодках и плотах не помогло избежать протечек в Титанике...
163 Кб, 1280x720>>08736
Забыл прикрепить иллюстрацию своего прогрессивного геймдев воркфлоу. Рекомендую.
>Главное по-быстрому накидать прототип, поиграть в него, выбросить.
Забыл прикрепить иллюстрацию своего прогрессивного геймдев воркфлоу. Рекомендую.
49 Кб, 185x589>>08719
Спасибо за подробный ответ. А вот это
Как понять? Вот, смотри, нормально всё?
Спасибо за подробный ответ. А вот это
>Надеюсь, у тебя этот материал решётки отдельно от материалов остальной сцены, иначе...
Как понять? Вот, смотри, нормально всё?
6 Кб, 275x183Поставил годот после долгого перерыва
Настроил вс студию
Движок крашнулся при первом запуске
После перезапуска все окей
Импортировал модель в сцену
Увидел какой-то новый адвансед импорт в отдельном окне.
Потыкал кнопки
Движок крашнулся
Импоритирую модель снова
Забыл как превратить импорт в полноценную сцену вместо ебаного inherited scene
Идешь в доки
В доках за годы по прежнему нихуя
Идешь в гугл
В гугле все жалуются на эту хуйню но никто не дает ответа
Удалил годот
Пришел насрать на дваче
Настроил вс студию
Движок крашнулся при первом запуске
После перезапуска все окей
Импортировал модель в сцену
Увидел какой-то новый адвансед импорт в отдельном окне.
Потыкал кнопки
Движок крашнулся
Импоритирую модель снова
Забыл как превратить импорт в полноценную сцену вместо ебаного inherited scene
Идешь в доки
В доках за годы по прежнему нихуя
Идешь в гугл
В гугле все жалуются на эту хуйню но никто не дает ответа
Удалил годот
Пришел насрать на дваче
>>08746
Хм почти также было! Хехехехе. Ехехехехе. Ахахахах. АГАГАГАГАГА. Ну я тип... Гомо. Гомоиммунитет у меня выработался.
Хм почти также было! Хехехехе. Ехехехехе. Ахахахах. АГАГАГАГАГА. Ну я тип... Гомо. Гомоиммунитет у меня выработался.
>>08746
Годот не требует установки, ты спалился в первой строчке, движкосрачер.
Ах да, конечно, верим. Без скринов, пруфов. Так все и было.
>Поставил годот
Годот не требует установки, ты спалился в первой строчке, движкосрачер.
Ах да, конечно, верим. Без скринов, пруфов. Так все и было.
>>08746
1. Его достаточно скачать и запустить.
2. Зачем было удалять? У тебя диск на 32 Гб?
Зачем? У нас встроенный редактор.
Может быть из-за шейдеров/драйвера видюхи. При первом запуске они компилируются и сохраняются.
Нужно issue писать на гитхаб. Вот сюда:
https://github.com/godotengine/godot/issues
Зачем? В этом нет необходимости.
Это нужно, чтобы при обновлении файла модели твоя сцена не была перезаписана импортом.
Учи английский, тогда буквы латиницы увидишь.
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.
>>08746
1. Его достаточно скачать и запустить.
2. Зачем было удалять? У тебя диск на 32 Гб?
Зачем? У нас встроенный редактор.
Может быть из-за шейдеров/драйвера видюхи. При первом запуске они компилируются и сохраняются.
Нужно issue писать на гитхаб. Вот сюда:
https://github.com/godotengine/godot/issues
Зачем? В этом нет необходимости.
Это нужно, чтобы при обновлении файла модели твоя сцена не была перезаписана импортом.
Учи английский, тогда буквы латиницы увидишь.
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.
498 Кб, 1280x720Dev snapshot: Godot 4.2 beta 2
https://godotengine.org/article/dev-snapshot-godot-4-2-beta-2/
Не ждём, а готовимся.
https://godotengine.org/article/dev-snapshot-godot-4-2-beta-2/
Не ждём, а готовимся.
>>08736
Нихуя, новички такое вообще не понимают.
Прикинь, кое-кто не прототипы делает, а игры. Кто делает прототипы, разрешаю эти утечки игнорировать.
Если ошибки есть, о них надо сообщать. Можно дать галочку в настойках, сообщать ли конкретно об этих ошибках (как собсно с большинством ошибок и сделано).
>>08729
В прототипе так и было. Но это некрасиво и не экономно.
Не "когда", а "если". Уровни крупнее не станут, потому что тогда станет слишком долго их проходить; врагов больше не станет, потому что тогда буит мясо. Так что большую кучу вещей взять тупо неоткуда.
Ошибок не выдаёт, но ругается, что добавлять ноды в физикс_процессе не положено.
>>08724
Чел, я не тот анон, который оверрайдил куефри, но мне кажется, он это чисто из спортивного интереса делал, а не вот это что ты там придумал. И вообще, я всего лишь говорю, что вряд ли где-то ещё в движке есть вызов куефри, потому что а) это привело бы к самопроизвольному удалению нод, б) это всего лишь интерфейс к внутренним вызовам, а не сами внутренние вызовы. Вот в коде редактора - да, там наверняка есть. Но не в движке.
>Это отпугнёт новичков
Нихуя, новички такое вообще не понимают.
>Искать утечки памяти в прототипе
Прикинь, кое-кто не прототипы делает, а игры. Кто делает прототипы, разрешаю эти утечки игнорировать.
>Если редактор на любой Hello World будет срать ошибками
Если ошибки есть, о них надо сообщать. Можно дать галочку в настойках, сообщать ли конкретно об этих ошибках (как собсно с большинством ошибок и сделано).
>>08729
>Не лучше было бы иметь какое-то количество подготовленных заранее брызг?
В прототипе так и было. Но это некрасиво и не экономно.
>когда в воду упадёт большая куча вещей
Не "когда", а "если". Уровни крупнее не станут, потому что тогда станет слишком долго их проходить; врагов больше не станет, потому что тогда буит мясо. Так что большую кучу вещей взять тупо неоткуда.
>А для чего здесь call_deferred? Ошибку выдаёт?
Ошибок не выдаёт, но ругается, что добавлять ноды в физикс_процессе не положено.
>>08724
Чел, я не тот анон, который оверрайдил куефри, но мне кажется, он это чисто из спортивного интереса делал, а не вот это что ты там придумал. И вообще, я всего лишь говорю, что вряд ли где-то ещё в движке есть вызов куефри, потому что а) это привело бы к самопроизвольному удалению нод, б) это всего лишь интерфейс к внутренним вызовам, а не сами внутренние вызовы. Вот в коде редактора - да, там наверняка есть. Но не в движке.
>>08661
>>08760
Ну и зачем дважды постить?
Я тут >>08669
А ты второй раз постишь...
>Аноним 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
А ты второй раз постишь...
>>08761
Зато они видят КРАСНУЮ НАДПИСЬ и пугаются.
Мне бы твою суперспособность... Даже ААА студии не смогут сравниться с твоей геймдев суперсилой.
Утечка - не ошибка. Это проблема, но не такая, как сложение строки с числом или деление на ноль.
В таком случае ограниченное количество заранее подготовленных спецэффектов выглядит более рациональным выбором, чем динамическая работа с произвольным количеством эффектов. У тебя выбор между памятью и скоростью, и ты можешь точно посчитать, сколько памяти тебе понадобится, а скорости тебе нужно как можно больше.
Нужно проверить, влияет ли это на tool-скрипты...
>новички такое вообще не понимают
Зато они видят КРАСНУЮ НАДПИСЬ и пугаются.
>Прикинь, кое-кто не прототипы делает, а игры.
Мне бы твою суперспособность... Даже ААА студии не смогут сравниться с твоей геймдев суперсилой.
>Если ошибки есть, о них надо сообщать.
Утечка - не ошибка. Это проблема, но не такая, как сложение строки с числом или деление на ноль.
>Но это некрасиво и не экономно.
>Не "когда", а "если".
>Так что большую кучу вещей взять тупо неоткуда.
В таком случае ограниченное количество заранее подготовленных спецэффектов выглядит более рациональным выбором, чем динамическая работа с произвольным количеством эффектов. У тебя выбор между памятью и скоростью, и ты можешь точно посчитать, сколько памяти тебе понадобится, а скорости тебе нужно как можно больше.
>Вот в коде редактора - да, там наверняка есть.
Нужно проверить, влияет ли это на tool-скрипты...
>>08765
Я хочу сказать, что можно было бы выводить:
Но даже в таком случае, эта надпись может быть раздражающей, когда ты часто юзаешь F6, тестя множество обрывков игры, которые могут по отдельности сорить нодами, но не будут вместе.
>видят КРАСНУЮ НАДПИСЬ и пугаются
>Утечка - не ошибка. Это проблема, но
Я хочу сказать, что можно было бы выводить:
>Warning: 1234 orphan nodes freed automatically.
Но даже в таком случае, эта надпись может быть раздражающей, когда ты часто юзаешь F6, тестя множество обрывков игры, которые могут по отдельности сорить нодами, но не будут вместе.
120 Кб, 900x820>>08765
В таком случае объясни мне, почему вот эти все неошибки достойны того, чтобы присутствовать в этом списке, а утечки - нет? Почему эти неошибки не мешают прототипировать и не пугают нубов, а сообщения об утечках - мешают и пугают?
А ведь можно эту надпись написать ну я не знаю... Жёлтым? Белым? Серым? Какой там у нас цвет считается не страшным для новичков?
И вообще. Пусть боятся говнокодить, а не красных надписей.
>Утечка - не ошибка
В таком случае объясни мне, почему вот эти все неошибки достойны того, чтобы присутствовать в этом списке, а утечки - нет? Почему эти неошибки не мешают прототипировать и не пугают нубов, а сообщения об утечках - мешают и пугают?
>видят КРАСНУЮ НАДПИСЬ и пугаются.
А ведь можно эту надпись написать ну я не знаю... Жёлтым? Белым? Серым? Какой там у нас цвет считается не страшным для новичков?
И вообще. Пусть боятся говнокодить, а не красных надписей.
Посоны, осторожнее с 3.5.3. Там какой-то баг портит сцены со сложным наследованием. Восстанавливал из бэкапа, а он снова портил. Откатился на 3.5.2 - всё вроде нормально.
Сцена А, её наследники А1, А2, А3 и т.д.
Сцена Б содержит детей: А1, А2, А3.
Сцена Б1 наследует от Б.
Баг: открываю Б1, а там А1 и А3 превратились в А; хотя в родительской Б ничего не поменялось. Через пару переоткрытий все А1 и А3 внутри Б превратились в А. Ещё через пару переоткрытий Б перестала открываться, неожиданное окончание файла.
Такая хуйня.
Сцена А, её наследники А1, А2, А3 и т.д.
Сцена Б содержит детей: А1, А2, А3.
Сцена Б1 наследует от Б.
Баг: открываю Б1, а там А1 и А3 превратились в А; хотя в родительской Б ничего не поменялось. Через пару переоткрытий все А1 и А3 внутри Б превратились в А. Ещё через пару переоткрытий Б перестала открываться, неожиданное окончание файла.
Такая хуйня.
>>08790
новый спайдермен на любителя, конечно
новый спайдермен на любителя, конечно
>>08787
Хуй знает. Переполз с наследование на композицию и тебе советую.
Хуй знает. Переполз с наследование на композицию и тебе советую.
>>08854
Ты перепутал, это не юнити тред
Ты перепутал, это не юнити тред
>>08854
Ты вместо LTS поставил бету которая еще даже не релтз кандидат, но виноват конечно кто-то другой.
Ты вместо LTS поставил бету которая еще даже не релтз кандидат, но виноват конечно кто-то другой.
356 Кб, 468x426Безопасно ли устанавливать scale отличным от 1 объектам с физической коллизией? То есть, у меня есть условный физический арбуз, и мне лень увеличивать отдельно меш и отдельно коллизию, поэтому я беру и ставлю скейл 5 на весь объект целиком. Подводные?
>>08787
Делаешь минимальный проект воспроизводящийся
Открываешь issue либо отправляешь в ту если про это уже создали.
Можешь кинуть сюда, я тоже посмотрю.
Делаешь минимальный проект воспроизводящийся
Открываешь issue либо отправляешь в ту если про это уже создали.
Можешь кинуть сюда, я тоже посмотрю.
>>08866
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, напр. радиус у сферы.
Хотя мне казалось что в какой то момент это переделали и можно стало масштабировать и редактор перестал ругаться, но может быть я путаю.
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, напр. радиус у сферы.
Хотя мне казалось что в какой то момент это переделали и можно стало масштабировать и редактор перестал ругаться, но может быть я путаю.
>>08787
Алсо ты можешь еще раз повторить процесс и прямо скидывать после каждого шага tscn, это же текстовый файл, в нем сразу видно будет что поменялось, намного упростит исправление.
Алсо ты можешь еще раз повторить процесс и прямо скидывать после каждого шага tscn, это же текстовый файл, в нем сразу видно будет что поменялось, намного упростит исправление.
>>08872
Мне вот тоже так казалось. Редактор не ругается, но если физика начнет вести себя странно - в первую очередь уберу скалирование.
>Хотя мне казалось что в какой то момент это переделали и можно стало масштабировать и редактор перестал ругаться, но может быть я путаю.
Мне вот тоже так казалось. Редактор не ругается, но если физика начнет вести себя странно - в первую очередь уберу скалирование.
>>08874
откройте для себя гит.
откройте для себя гит.
149 Кб, 689x960>>08854
Ты не понял.
Ты не понял.
>>08787
А не, нихуя, в 3.5.2 тоже вылезло.
Походу, при каких-то изменениях в скрипте A возникает. Точные условия пока вообще хз.
А не, нихуя, в 3.5.2 тоже вылезло.
Походу, при каких-то изменениях в скрипте A возникает. Точные условия пока вообще хз.
>>08787
Последней версией тройки у меня стоит 3.5. Меня задолбало качать все эти патчи и я уже собирался переходить на четвёрку. А потом задепрессовал.
Решение: не открывать сцены лишний раз, лол.
Можешь конкретнее сказать, о чём идёт речь? Что это за объекты с таким наследованием? Любопытно.
>Откатился на 3.5.2
Последней версией тройки у меня стоит 3.5. Меня задолбало качать все эти патчи и я уже собирался переходить на четвёрку. А потом задепрессовал.
>Баг: открываю Б1, а там...
>Через пару переоткрытий
Решение: не открывать сцены лишний раз, лол.
>Сцена А, её наследники А1, А2, А3 и т.д.
>Сцена Б содержит детей: А1, А2, А3.
>Сцена Б1 наследует от Б.
Можешь конкретнее сказать, о чём идёт речь? Что это за объекты с таким наследованием? Любопытно.
>>08787
Очередной мудак без диздока запутался в своём производственном аду. А виноват движок. Ну конечно же. Не ты.
Очередной мудак без диздока запутался в своём производственном аду. А виноват движок. Ну конечно же. Не ты.
>>08937
У любого человека есть право запутаться, и движок не безупречный, в такой баг вполне верится, хотя пруфов нам так и не предоставили, конечно.
У любого человека есть право запутаться, и движок не безупречный, в такой баг вполне верится, хотя пруфов нам так и не предоставили, конечно.
>>08953
Двачую. Регулярно сталкивался с поломкой сцен и привык к этому. Это норма для любого движка. Поэтому хранят данные сцены в текстовом виде.
Пруфов чего? Файла, в котором какие-то связи неправильно прописаны? Это подделать можно.
Поломка могла быть вызвана вообще не движком, а какой-нибудь фазой луны, лол, ОС что-то делала и повредила код движка в RAM, на диске произошла ошибка чтения или записи, или космические лучи переключили бит в памяти, всякое могло быть. Так и появляются баги, которые нельзя воспроизвести.
>в такой баг вполне верится
Двачую. Регулярно сталкивался с поломкой сцен и привык к этому. Это норма для любого движка. Поэтому хранят данные сцены в текстовом виде.
>хотя пруфов нам так и не предоставили
Пруфов чего? Файла, в котором какие-то связи неправильно прописаны? Это подделать можно.
Поломка могла быть вызвана вообще не движком, а какой-нибудь фазой луны, лол, ОС что-то делала и повредила код движка в RAM, на диске произошла ошибка чтения или записи, или космические лучи переключили бит в памяти, всякое могло быть. Так и появляются баги, которые нельзя воспроизвести.
>>08976
Файлом сцены, который при сохранении херится с каждым разом все сильнее. Причем это в первую очередь надо в ишью, чтобы это могли починить.
>Файла, в котором какие-то связи неправильно прописаны? Это подделать можно.
Файлом сцены, который при сохранении херится с каждым разом все сильнее. Причем это в первую очередь надо в ишью, чтобы это могли починить.
>>08980
Тупость ещё и в том, что херится он при ОТКРЫТИИ, но потом тут же СОХРАНЯЕТСЯ без разрешения.
Вообще, есть подозрение, что в тот момент, когда я случайно перетащил папку scenes в табе файловой системы (описывал этот косяк в прошлом треде), поломались какие-то адреса зависимостей где-то там. По крайней мере, после того случая мне попадалось что-то типа: сцена А наследует от Б, сцена Б наследует от А; каким-то хером этот барон мюнхаузен работал, пока я не попробовал поменять свойства, после чего обе сцены превратились в тыкву; естественно, изначально ничего такого не было, А была предком, Б наследником.
В общем,
>>08870
вряд ли получится собрать.
Вдобавок сцены у меня в этом проекте все .scn (анон посоветовал для быстродействия; я был тогда нуб, наивен и поверил). Ошибку осознал, к следующему проекту не повторю, все сцены и ресурсы буду хранить исключительно в текстовом формате.
>>08914
Б - базовый класс персонажа. От него наследуют все прочие персы.
А - базовый класс способности. Все остальные способности от него зависят. Соответственно, несколько основных способностей есть и в базовом персонаже.
>>08937
Ну, что ж ты о себе так плохо говоришь? Поднимай самооценку, бро. У меня вот с архитектурой проекта вообще проблем нет. Забросил его больше чем на полгода, потом открыл и нигде ни в чём не запутался. А сегодня таки довёл до релиза.
>Файлом сцены, который при сохранении херится с каждым разом все сильнее.
Тупость ещё и в том, что херится он при ОТКРЫТИИ, но потом тут же СОХРАНЯЕТСЯ без разрешения.
Вообще, есть подозрение, что в тот момент, когда я случайно перетащил папку scenes в табе файловой системы (описывал этот косяк в прошлом треде), поломались какие-то адреса зависимостей где-то там. По крайней мере, после того случая мне попадалось что-то типа: сцена А наследует от Б, сцена Б наследует от А; каким-то хером этот барон мюнхаузен работал, пока я не попробовал поменять свойства, после чего обе сцены превратились в тыкву; естественно, изначально ничего такого не было, А была предком, Б наследником.
В общем,
>>08870
>минимальный проект воспроизводящийся
вряд ли получится собрать.
Вдобавок сцены у меня в этом проекте все .scn (анон посоветовал для быстродействия; я был тогда нуб, наивен и поверил). Ошибку осознал, к следующему проекту не повторю, все сцены и ресурсы буду хранить исключительно в текстовом формате.
>>08914
>Можешь конкретнее сказать, о чём идёт речь? Что это за объекты с таким наследованием? Любопытно
Б - базовый класс персонажа. От него наследуют все прочие персы.
А - базовый класс способности. Все остальные способности от него зависят. Соответственно, несколько основных способностей есть и в базовом персонаже.
>>08937
>Очередной мудак без диздока запутался в своём производственном аду.
Ну, что ж ты о себе так плохо говоришь? Поднимай самооценку, бро. У меня вот с архитектурой проекта вообще проблем нет. Забросил его больше чем на полгода, потом открыл и нигде ни в чём не запутался. А сегодня таки довёл до релиза.
3,6 Мб, mp4,900x890, 1:11
>>09130
И вправду обидно.
И вправду обидно.
>>09130
Это норма, двач же. Продолжай хорошо работать.
Алсо я нахожу что толковей показывать видосы на реддите, а ИТТ удобней общаться на тему годота и спрашивать/отвечать технические штуки.
Это норма, двач же. Продолжай хорошо работать.
Алсо я нахожу что толковей показывать видосы на реддите, а ИТТ удобней общаться на тему годота и спрашивать/отвечать технические штуки.
Почему они просто не учитывают дельту автоматом во всем движке, зачем я вручную должен? Опять ее где-то упустил и теперь искать.
А еще эти move_and_collide/move_and_slide, одного надо умножать на дельту, а другого нельзя. Уууу сюка.
А еще эти move_and_collide/move_and_slide, одного надо умножать на дельту, а другого нельзя. Уууу сюка.
>>09144
Потому что иногда дельта не нужна.
Потому что иногда дельта не нужна.
>>09133
Там регистрация + репутация а-ля Пикабу, так что если однажды обосрёшься, в жизнь не отмоешься.
Ну вот я думал, что кто-нибудь спросит, как я это сделал, а я опишу подход. И ещё хотел спросить, как решить баг с застреванием, но передумал (там нужно всё переписать масштабируемо).
>>09135
Такое показывать бессмысленно, игроки без опыта разработки игр не понимают суть™. Они либо будут недовольны низким качеством (серые кубы, суть которых - не отвлекаться на арт, отсутствие всех побочных деталей), либо, наоборот, создадут себе завышенные ожидания и начнут просить/требовать невозможное (ММО и т.п.).
Так что мне больше нравится отклик других разработчиков, которые в теме и могут что-то по существу спросить или подсказать.
А игрокам нужно показывать уже почти готовый продукт, который осталось только отполировать.
См. выше, репутация + серьёзные ограничения.
Он уже мёртв - без платной подписки тебя мало кто увидит, да и раньше встречал много годных проектов, о которых твитят, а откликов нет.
Чаще всего бесполезно, там взлетают только развлекательные влоги с кучей шуток.
Вообще бесполезно, если заводить свой паблик без сотен активных знакомых, а в какой-либо большой вряд ли пропустят, разве что это геймдев клуб по интересам аналогично /gd/.
И потом, всё перечисленное имеет смысл только когда есть сформированная база игры и разработка идёт полным ходом по чётко намеченному пути к релизу. Постить в "верхний интернет" какие-то мелкие прототипы смысла нет, если ты не популярный клоун ютубер с кучей подписчиков.
Не понимаю, почему все стесняются залить свои недоделки сюда, как будто реально могут "украсть идею" и заработать миллионы вместо тебя (да на здоровье, я только рад буду, если идея взлетела).
В /pa/ и /td/ охотнее делятся тем, что сами сделали (включая бесконечный поток прототипов), хотя это то же самое "показывать коллегам".
>толковей показывать видосы на реддите
Там регистрация + репутация а-ля Пикабу, так что если однажды обосрёшься, в жизнь не отмоешься.
>ИТТ удобней общаться на тему годота и спрашивать/отвечать технические штуки.
Ну вот я думал, что кто-нибудь спросит, как я это сделал, а я опишу подход. И ещё хотел спросить, как решить баг с застреванием, но передумал (там нужно всё переписать масштабируемо).
>>09135
>показывать сделанное надо не коллегам
>а потенциальным игрокам.
Такое показывать бессмысленно, игроки без опыта разработки игр не понимают суть™. Они либо будут недовольны низким качеством (серые кубы, суть которых - не отвлекаться на арт, отсутствие всех побочных деталей), либо, наоборот, создадут себе завышенные ожидания и начнут просить/требовать невозможное (ММО и т.п.).
Так что мне больше нравится отклик других разработчиков, которые в теме и могут что-то по существу спросить или подсказать.
А игрокам нужно показывать уже почти готовый продукт, который осталось только отполировать.
>На реддите,
См. выше, репутация + серьёзные ограничения.
>твиттере,
Он уже мёртв - без платной подписки тебя мало кто увидит, да и раньше встречал много годных проектов, о которых твитят, а откликов нет.
>ютубе,
Чаще всего бесполезно, там взлетают только развлекательные влоги с кучей шуток.
>вк
Вообще бесполезно, если заводить свой паблик без сотен активных знакомых, а в какой-либо большой вряд ли пропустят, разве что это геймдев клуб по интересам аналогично /gd/.
И потом, всё перечисленное имеет смысл только когда есть сформированная база игры и разработка идёт полным ходом по чётко намеченному пути к релизу. Постить в "верхний интернет" какие-то мелкие прототипы смысла нет, если ты не популярный клоун ютубер с кучей подписчиков.
Не понимаю, почему все стесняются залить свои недоделки сюда, как будто реально могут "украсть идею" и заработать миллионы вместо тебя (да на здоровье, я только рад буду, если идея взлетела).
В /pa/ и /td/ охотнее делятся тем, что сами сделали (включая бесконечный поток прототипов), хотя это то же самое "показывать коллегам".
>>09133
Там регистрация + репутация а-ля Пикабу, так что если однажды обосрёшься, в жизнь не отмоешься.
Ну вот я думал, что кто-нибудь спросит, как я это сделал, а я опишу подход. И ещё хотел спросить, как решить баг с застреванием, но передумал (там нужно всё переписать масштабируемо).
>>09135
Такое показывать бессмысленно, игроки без опыта разработки игр не понимают суть™. Они либо будут недовольны низким качеством (серые кубы, суть которых - не отвлекаться на арт, отсутствие всех побочных деталей), либо, наоборот, создадут себе завышенные ожидания и начнут просить/требовать невозможное (ММО и т.п.).
Так что мне больше нравится отклик других разработчиков, которые в теме и могут что-то по существу спросить или подсказать.
А игрокам нужно показывать уже почти готовый продукт, который осталось только отполировать.
См. выше, репутация + серьёзные ограничения.
Он уже мёртв - без платной подписки тебя мало кто увидит, да и раньше встречал много годных проектов, о которых твитят, а откликов нет.
Чаще всего бесполезно, там взлетают только развлекательные влоги с кучей шуток.
Вообще бесполезно, если заводить свой паблик без сотен активных знакомых, а в какой-либо большой вряд ли пропустят, разве что это геймдев клуб по интересам аналогично /gd/.
И потом, всё перечисленное имеет смысл только когда есть сформированная база игры и разработка идёт полным ходом по чётко намеченному пути к релизу. Постить в "верхний интернет" какие-то мелкие прототипы смысла нет, если ты не популярный клоун ютубер с кучей подписчиков.
Не понимаю, почему все стесняются залить свои недоделки сюда, как будто реально могут "украсть идею" и заработать миллионы вместо тебя (да на здоровье, я только рад буду, если идея взлетела).
В /pa/ и /td/ охотнее делятся тем, что сами сделали (включая бесконечный поток прототипов), хотя это то же самое "показывать коллегам".
>толковей показывать видосы на реддите
Там регистрация + репутация а-ля Пикабу, так что если однажды обосрёшься, в жизнь не отмоешься.
>ИТТ удобней общаться на тему годота и спрашивать/отвечать технические штуки.
Ну вот я думал, что кто-нибудь спросит, как я это сделал, а я опишу подход. И ещё хотел спросить, как решить баг с застреванием, но передумал (там нужно всё переписать масштабируемо).
>>09135
>показывать сделанное надо не коллегам
>а потенциальным игрокам.
Такое показывать бессмысленно, игроки без опыта разработки игр не понимают суть™. Они либо будут недовольны низким качеством (серые кубы, суть которых - не отвлекаться на арт, отсутствие всех побочных деталей), либо, наоборот, создадут себе завышенные ожидания и начнут просить/требовать невозможное (ММО и т.п.).
Так что мне больше нравится отклик других разработчиков, которые в теме и могут что-то по существу спросить или подсказать.
А игрокам нужно показывать уже почти готовый продукт, который осталось только отполировать.
>На реддите,
См. выше, репутация + серьёзные ограничения.
>твиттере,
Он уже мёртв - без платной подписки тебя мало кто увидит, да и раньше встречал много годных проектов, о которых твитят, а откликов нет.
>ютубе,
Чаще всего бесполезно, там взлетают только развлекательные влоги с кучей шуток.
>вк
Вообще бесполезно, если заводить свой паблик без сотен активных знакомых, а в какой-либо большой вряд ли пропустят, разве что это геймдев клуб по интересам аналогично /gd/.
И потом, всё перечисленное имеет смысл только когда есть сформированная база игры и разработка идёт полным ходом по чётко намеченному пути к релизу. Постить в "верхний интернет" какие-то мелкие прототипы смысла нет, если ты не популярный клоун ютубер с кучей подписчиков.
Не понимаю, почему все стесняются залить свои недоделки сюда, как будто реально могут "украсть идею" и заработать миллионы вместо тебя (да на здоровье, я только рад буду, если идея взлетела).
В /pa/ и /td/ охотнее делятся тем, что сами сделали (включая бесконечный поток прототипов), хотя это то же самое "показывать коллегам".
>>09149
Это не шутки. Реально могут и украдут.
> реально могут "украсть идею" и заработать миллионы вместо тебя
Это не шутки. Реально могут и украдут.
Украл все ваши многомиллионные идеи, уже заказываю пятую яхту.
>>09149
А если серьезно, реддит самая полезная платформа. Ограничения фармятся за пару вечеров методом "пощу котов в малопопулярные сабреддиты", а репутация - ну, просто не веди себя как на харкаче. Я обычно пощу видос, а в комментах только "спасибо за фидбек" раздаю. И ничего больше на этом аккаунте не делаю. Сру с другого.
А если серьезно, реддит самая полезная платформа. Ограничения фармятся за пару вечеров методом "пощу котов в малопопулярные сабреддиты", а репутация - ну, просто не веди себя как на харкаче. Я обычно пощу видос, а в комментах только "спасибо за фидбек" раздаю. И ничего больше на этом аккаунте не делаю. Сру с другого.
>>09144
Где нужно - там учитывают.
Ты не должен. В обработчики поступает дельта, а ты используешь её как захочешь, или не используешь вообще (переименуй в _delta чтоб не жаловался).
В 4.x у CharacterBody2D/3D остался только slide, и тебе больше не нужно передавать в него аргументы - всё настраивается через свойства класса.
>не учитывают дельту автоматом
Где нужно - там учитывают.
>зачем я вручную должен?
Ты не должен. В обработчики поступает дельта, а ты используешь её как захочешь, или не используешь вообще (переименуй в _delta чтоб не жаловался).
>move_and_collide/move_and_slide, одного надо умножать на дельту, а другого нельзя.
В 4.x у CharacterBody2D/3D остался только slide, и тебе больше не нужно передавать в него аргументы - всё настраивается через свойства класса.
>>09075
Всё верно, но лучше конвертировать для экспорта, если экспорт ещё не делает это автоматически.
Ты ж можешь пересохранить сцены в tscn. Если они, конечно, открываются редактором без ошибок.
>все .scn (анон посоветовал для быстродействия
Всё верно, но лучше конвертировать для экспорта, если экспорт ещё не делает это автоматически.
>Ошибку осознал, к следующему проекту не повторю, все сцены и ресурсы буду хранить исключительно в текстовом формате.
Ты ж можешь пересохранить сцены в tscn. Если они, конечно, открываются редактором без ошибок.
>>09171
Что мешает начать осваивать уже сейчас? Основные проблемы с редактором вроде как решены, он даже меньше тормозить стал (по сравнению с 4.0).
>Однажды доползу и до нее.
Что мешает начать осваивать уже сейчас? Основные проблемы с редактором вроде как решены, он даже меньше тормозить стал (по сравнению с 4.0).
>>09151
Правда?! Как здорово! Тогда вот:
Здраствуйте. Я, Анонимус. Хотел бы чтобы вы сделали игру, 3Д-экшон суть такова... Пользователь может играть выжившим мастером на все руки и путешественником. И если пользователь играет на острове, то он должен построить деревянный домик летающий и збижать с острова, пока тот не упал в бездну. Можно грабить летающие корованы... И острова раз лесные то сделать так что там густой лес... А движок можно поставить так что вдали деревья картинкой, когда подлетаеш они преобразовываются в 3-хмерные деревья. Можно крафтить и т.п. возможности как в типичных выживалках. И предметы 3-хмерные тоже, и запчасти корабля тоже 3д. Можно прыгать на тросе по острову и т.п. Если играть за путешественника то надо управлять кораблём, и ремонтировать его на ходу (механики я не придумал) и заправлять топливом, летучим газом, и ходит на набеги на острова за ресурсами (деревом, топливом, газом…). Ну а если корабль разбился… то значит нужно строить новый на острове, пользователь сам себе командир может делать что сам захочет хочет строит хочет летает может просто бегать и беситься. Всего в игре 4 зоны. Т.е. карта и на ней есть 4 зоны, 1 - зона над облаками (нейтрал), 2- зона плотных облаков (где много островов), 3-зона стратосферы, 4 - зона бездны… (в самом низу, там всё погибает…)
Так же чтобы в игре корабли могли не только сломаться но и отвалиться часть корабля и если пользователь не починит его то он развалится, так же сломать двигатель но пользователь может не умереть а просто лететь на оставшихся, или собрать новый прямо в полёте, если баллон с газом тоже либо упадёшь в пропасть либо будеш медленно лететь до ближайшего острова, или самое хорошее… скрафтить замену прямо в полёте из запасных ресурсов. Сохранятся можно…
P.S. Я четыре года хочу такую игру.
>Это не шутки. Реально могут и украдут.
Правда?! Как здорово! Тогда вот:
Здраствуйте. Я, Анонимус. Хотел бы чтобы вы сделали игру, 3Д-экшон суть такова... Пользователь может играть выжившим мастером на все руки и путешественником. И если пользователь играет на острове, то он должен построить деревянный домик летающий и збижать с острова, пока тот не упал в бездну. Можно грабить летающие корованы... И острова раз лесные то сделать так что там густой лес... А движок можно поставить так что вдали деревья картинкой, когда подлетаеш они преобразовываются в 3-хмерные деревья. Можно крафтить и т.п. возможности как в типичных выживалках. И предметы 3-хмерные тоже, и запчасти корабля тоже 3д. Можно прыгать на тросе по острову и т.п. Если играть за путешественника то надо управлять кораблём, и ремонтировать его на ходу (механики я не придумал) и заправлять топливом, летучим газом, и ходит на набеги на острова за ресурсами (деревом, топливом, газом…). Ну а если корабль разбился… то значит нужно строить новый на острове, пользователь сам себе командир может делать что сам захочет хочет строит хочет летает может просто бегать и беситься. Всего в игре 4 зоны. Т.е. карта и на ней есть 4 зоны, 1 - зона над облаками (нейтрал), 2- зона плотных облаков (где много островов), 3-зона стратосферы, 4 - зона бездны… (в самом низу, там всё погибает…)
Так же чтобы в игре корабли могли не только сломаться но и отвалиться часть корабля и если пользователь не починит его то он развалится, так же сломать двигатель но пользователь может не умереть а просто лететь на оставшихся, или собрать новый прямо в полёте, если баллон с газом тоже либо упадёшь в пропасть либо будеш медленно лететь до ближайшего острова, или самое хорошее… скрафтить замену прямо в полёте из запасных ресурсов. Сохранятся можно…
P.S. Я четыре года хочу такую игру.
Анальники, столкнулся с проблемой. В игре хитбоксы союзников наслаиваются и начинают считаться за один, ведь полностью повторяют размеры и координаты друг друга. Для того, чтобы враг имел доступ к здоровью юнитов, я сделал рейкаст. Когда рейкаст противника ловит скопившееся количество одинаковых юнитов, урон наносится всем сразу и, таким образом, один враг может победить целую армию одинаковых персонажей. Как сделать так, чтобы рейкаст ловил не всех юнитов сразу, а одного, самого последнего из детей материнской ноды?
Если используете гридмап и хотите халявных фпс - покрутите Octant Size. Только что 30% выжал.
>>09234
Это очевидно, если почитать исходники.
Каждый октант - это набор MultiMeshInstance. Если октант слишком мелкий, толку от мультимеша мало.
Размер по умолчанию в 8x8x8 непонятно для кого сделан, ведь очевидно, что ты не будешь заполнять все 512 позиций одним мешем. Скорее всего у тебя вообще всё в один слой, 64 позиции. Допустим, ты сделал 8 типов блоков - тогда в одном октанте в среднем у тебя по 8 блоков внутри каждого из 8 мультимешей. Бессмыслица какая-то выходит.
С другой стороны, из-за мультимешей каждый октант отображается даже когда на экране, условно, только маленький уголок одного блока. Если октанты очень большие, это может вызвать лишнюю нагрузку в ситуациях, когда можно было ничего не рисовать.
Это очевидно, если почитать исходники.
Каждый октант - это набор MultiMeshInstance. Если октант слишком мелкий, толку от мультимеша мало.
Размер по умолчанию в 8x8x8 непонятно для кого сделан, ведь очевидно, что ты не будешь заполнять все 512 позиций одним мешем. Скорее всего у тебя вообще всё в один слой, 64 позиции. Допустим, ты сделал 8 типов блоков - тогда в одном октанте в среднем у тебя по 8 блоков внутри каждого из 8 мультимешей. Бессмыслица какая-то выходит.
С другой стороны, из-за мультимешей каждый октант отображается даже когда на экране, условно, только маленький уголок одного блока. Если октанты очень большие, это может вызвать лишнюю нагрузку в ситуациях, когда можно было ничего не рисовать.
>>09228
Не очень тебя понял. Разве рейкаст не находит только ближайший по расстоянию, почему он у тебя всех цепляет?
А вообще есть разные способы.
У Area есть функция get overlapping bodies. Получаешь список, сам в нем определяешь самый верхний спрайт по индексу.
Ну или например враги сами следят и отключают хитбоксы когда на них стоит другой враг.
Или делаешь так чтобы они не ходили друг по другу.
Не очень тебя понял. Разве рейкаст не находит только ближайший по расстоянию, почему он у тебя всех цепляет?
А вообще есть разные способы.
У Area есть функция get overlapping bodies. Получаешь список, сам в нем определяешь самый верхний спрайт по индексу.
Ну или например враги сами следят и отключают хитбоксы когда на них стоит другой враг.
Или делаешь так чтобы они не ходили друг по другу.
>>09204
Вор крадёт то, что плохо лежит: бывший владелец вещи не позаботился о её безопасности и поэтому вор её украл. Вору приходится приложить усилия для совершения воровства, и чем больше старается владелец вещи, тем тяжелее приходится вору для совершения воровства. Лучше всего для вора, чтобы владелец вещи просто кинул её на какое-нибудь легкодоступное место и ушёл, забыв о ней, тогда вор легко сможет забрать вещь себе, возможно, даже без последствий, ведь владелец забыл вещь.
Следовательно, если идею игры можно украсть, то идейный вор должен брать самые непримечательные, брошенные, плохо сформированные идеи, выброшенные на произвол судьбы без стараний со стороны выдумывателя идеи. Чем больше выдумыватель старается в оформлении и вылизывании своей идеи, тем больше усилий придётся приложить идейному вору, чтобы украсть эту идею.
Так зачем мне стараться и что-то писать, если я хочу помочь вору идей? Я вбросил идею - бери, воруй, я сделал всё возможное для упрощения твоей работы.
Вор крадёт то, что плохо лежит: бывший владелец вещи не позаботился о её безопасности и поэтому вор её украл. Вору приходится приложить усилия для совершения воровства, и чем больше старается владелец вещи, тем тяжелее приходится вору для совершения воровства. Лучше всего для вора, чтобы владелец вещи просто кинул её на какое-нибудь легкодоступное место и ушёл, забыв о ней, тогда вор легко сможет забрать вещь себе, возможно, даже без последствий, ведь владелец забыл вещь.
Следовательно, если идею игры можно украсть, то идейный вор должен брать самые непримечательные, брошенные, плохо сформированные идеи, выброшенные на произвол судьбы без стараний со стороны выдумывателя идеи. Чем больше выдумыватель старается в оформлении и вылизывании своей идеи, тем больше усилий придётся приложить идейному вору, чтобы украсть эту идею.
Так зачем мне стараться и что-то писать, если я хочу помочь вору идей? Я вбросил идею - бери, воруй, я сделал всё возможное для упрощения твоей работы.
>>09228
Покажи, как ты сделал "рейкаст". Area2D - не рейкаст.
Зачем? Никогда не понимал этого в играх, выглядит максимально тупо. С тем же успехом можно просто сделать один юнит с увеличенным уроном.
>сделал рейкаст. Когда рейкаст противника ловит скопившееся количество одинаковых юнитов,
Покажи, как ты сделал "рейкаст". Area2D - не рейкаст.
>В игре хитбоксы союзников наслаиваются
Зачем? Никогда не понимал этого в играх, выглядит максимально тупо. С тем же успехом можно просто сделать один юнит с увеличенным уроном.
>>09149
Добро пожаловать в реальный мир, где всем насрать.
Нет, я не хочу сказать, что и мне тоже, хотя так и есть, просто выходит, что ты сам выстроил ожидания и сам же разочаровался, когда мир их не оправдал. Мой тебе совет: избавляйся от этого паттерна. Он ведёт к снижению самооценки и многочисленным социальным проблемам. Окружающие не обязаны выполнять твои ожидания и даже знать о них.
В данном случае следовало поступить так: хочешь описать подход - описываешь подход. И внезапно оказалось бы, что анонам интересно.
>я думал, что кто-нибудь спросит, а я опишу подход
Добро пожаловать в реальный мир, где всем насрать.
Нет, я не хочу сказать, что и мне тоже, хотя так и есть, просто выходит, что ты сам выстроил ожидания и сам же разочаровался, когда мир их не оправдал. Мой тебе совет: избавляйся от этого паттерна. Он ведёт к снижению самооценки и многочисленным социальным проблемам. Окружающие не обязаны выполнять твои ожидания и даже знать о них.
В данном случае следовало поступить так: хочешь описать подход - описываешь подход. И внезапно оказалось бы, что анонам интересно.
>>09228
А как ты наносишь урон? Тащемта ничто же не мешает определять все тушки, но дамажить только одну.
А как ты наносишь урон? Тащемта ничто же не мешает определять все тушки, но дамажить только одну.
>>09250
Вангую, у него что-то вроде:
Поэтому дамажит сразу всех + он не видит ошибку.
>ничто же не мешает определять все тушки
Вангую, у него что-то вроде:
>func _on_area_2d_body_enter(body):
> if body.is_in_group("player"): body.hurt(damage)
Поэтому дамажит сразу всех + он не видит ошибку.
Godot 4.2 beta 2
>>09240
Именно так. Я для этого и использовал рейкаст, чтобы ближайшего к источнику луча цеплял.
Я предполагаю, именно потому что коллизия у персонажей одинаковая и координаты по иску и игрику совпадают.
>>09243
Спасибо, обращусь, если не решу здесь и сейчас.
>>09250 >>09251
Я фиксирую саму коллизию Collision врагов при помощи разных слоёв Layers и Mask, безо всяких Area2D, Groups, Signals. Такая ситуация не только в третьей версии движка, но и четвёртой: одинаковые юниты накапливаются в одном месте и их может дамажить один противник.
Думаю это исправлять через get_children_count( Мама всех союзнических нод ), get_child( max Последняя нода в списке ). Мне это не нравится на интуитивном уровне, это по-уродски, отвратительный говнокод, неэстетичный, не энергоэффективный, лол.
>Разве рейкаст не находит только ближайший по расстоянию
Именно так. Я для этого и использовал рейкаст, чтобы ближайшего к источнику луча цеплял.
>почему он у тебя всех цепляет?
Я предполагаю, именно потому что коллизия у персонажей одинаковая и координаты по иску и игрику совпадают.
>>09243
Спасибо, обращусь, если не решу здесь и сейчас.
>>09250 >>09251
>Эпизод один.png
>Эпизод два.png
>Эпизод три.png
Я фиксирую саму коллизию Collision врагов при помощи разных слоёв Layers и Mask, безо всяких Area2D, Groups, Signals. Такая ситуация не только в третьей версии движка, но и четвёртой: одинаковые юниты накапливаются в одном месте и их может дамажить один противник.
Думаю это исправлять через get_children_count( Мама всех союзнических нод ), get_child( max Последняя нода в списке ). Мне это не нравится на интуитивном уровне, это по-уродски, отвратительный говнокод, неэстетичный, не энергоэффективный, лол.
>>09272
!Дополню!
Я создал отдельную булевую переменную money_collected именно потому что каждый юнит, который синхронно атаковал врага, вызвал метод Collect_money() и это приносило в (n=количество союзников) больше денег. Удивительно, но, получается, что всё-таки есть единственный, первый союзник, который первее активирует функцию Collect_money() и заставляет money_collected стать true, но с уроном это почему-то не работает.
!Дополню!
Я создал отдельную булевую переменную money_collected именно потому что каждый юнит, который синхронно атаковал врага, вызвал метод Collect_money() и это приносило в (n=количество союзников) больше денег. Удивительно, но, получается, что всё-таки есть единственный, первый союзник, который первее активирует функцию Collect_money() и заставляет money_collected стать true, но с уроном это почему-то не работает.
>>09272
Может лучше включать маску коллизии луча только для последней ноды? Как только нода умирает, включаешь коллизую следующей, и так далее.
Может лучше включать маску коллизии луча только для последней ноды? Как только нода умирает, включаешь коллизую следующей, и так далее.
>>09289
Не получится, у меня будут другие ноды, которые двигаются с разной скоростью и имеют разную высоту коллизии. Тут даже если измерять у кого в списке дальше остальных позиция по x, не получится из-за задуманной механики с разным ростом Y коллизий и способности по ней попадать разными типами противников.
Не получится, у меня будут другие ноды, которые двигаются с разной скоростью и имеют разную высоту коллизии. Тут даже если измерять у кого в списке дальше остальных позиция по x, не получится из-за задуманной механики с разным ростом Y коллизий и способности по ней попадать разными типами противников.
>>09252
Всех нас ждёт в конце free(). А queue_free() - это когда сверху приходит приказ расстрелять, а расстрельная переполнена - приходится вставать в очередь.
>queue_free
>Ведь он ждет нас всех в конце.
Всех нас ждёт в конце free(). А queue_free() - это когда сверху приходит приказ расстрелять, а расстрельная переполнена - приходится вставать в очередь.
>>09301
Для опыта, как минимум, чтобы понять все тонкости механик, обнаружить для себя неожиданные препятствия, а потом с набитой рукой делать игру мечты с блэкджеком и кораванами.
Для опыта, как минимум, чтобы понять все тонкости механик, обнаружить для себя неожиданные препятствия, а потом с набитой рукой делать игру мечты с блэкджеком и кораванами.
>>09295
Если честно выглядит как какая-то проблема с механикой, не до конца понятно что именно ты хочешь добиться, это какой-то tower attack, или как оно там называется?
Тебе нужно чтобы враг атаковал только одного?
Возможно стоит обойтись без кастования лучей, а использовать вместо этого стек целей, для каждого противника свой стек целей которые он может атаковать.
Например:
Враг с мечом атакует тех кто перед на дистанции меньше N.
Враг лучник атакует тех кто дальше N, но не атакует тех кто ближе.
Заходя в разные зоны цель попадает в разные группы, по таймеру каждые сколько-то секунд раздаешь целям урон и обновляешь группы.
Если честно выглядит как какая-то проблема с механикой, не до конца понятно что именно ты хочешь добиться, это какой-то tower attack, или как оно там называется?
Тебе нужно чтобы враг атаковал только одного?
Возможно стоит обойтись без кастования лучей, а использовать вместо этого стек целей, для каждого противника свой стек целей которые он может атаковать.
Например:
Враг с мечом атакует тех кто перед на дистанции меньше N.
Враг лучник атакует тех кто дальше N, но не атакует тех кто ближе.
Заходя в разные зоны цель попадает в разные группы, по таймеру каждые сколько-то секунд раздаешь целям урон и обновляешь группы.
>>09303
Хотя не, не совсем так.
free() - расстрел на месте, когда человечек не важен.
queue_free() - это когда человечек настолько важен, что ему позволяют перед расстрелом дела доделать.
А расстрельная переполняется в любом случае, но в случае queue_free() все дела уже доделали и ждут.
Хотя не, не совсем так.
free() - расстрел на месте, когда человечек не важен.
queue_free() - это когда человечек настолько важен, что ему позволяют перед расстрелом дела доделать.
А расстрельная переполняется в любом случае, но в случае queue_free() все дела уже доделали и ждут.
>>09307
Обычно это что угодно, во что анон играл в детстве. Если анон не имеет тормозов, то это условный скайрим/бг3, а если анон рассчитывает свои силы то условный ангри бердс.
Обычно это что угодно, во что анон играл в детстве. Если анон не имеет тормозов, то это условный скайрим/бг3, а если анон рассчитывает свои силы то условный ангри бердс.
>>09307
У меня раньше были игры мечты, но со временем понял, что на самом деле нет никаких игр мечты, есть только путь геядевелопера и хочется просто делать разные игры по настроению, а потом если в голове появляется оригинальная механика, добавляешь её в один из тематических проектов.
У меня раньше были игры мечты, но со временем понял, что на самом деле нет никаких игр мечты, есть только путь геядевелопера и хочется просто делать разные игры по настроению, а потом если в голове появляется оригинальная механика, добавляешь её в один из тематических проектов.
>>09272
Это невозможно, get_collider() возвращает 1 объект.
Где/когда эта функция вызывается?
Не верю. Сейчас пойду проверю.
Такая проблема с лучами была бы критической и её немедленно бы исправили в минорной версии.
>Я предполагаю, именно потому что коллизия у персонажей одинаковая и координаты по иску и игрику совпадают.
Это невозможно, get_collider() возвращает 1 объект.
>play_ability()
Где/когда эта функция вызывается?
>Такая ситуация не только в третьей версии движка, но и четвёртой: одинаковые юниты накапливаются в одном месте и их может дамажить один противник.
Не верю. Сейчас пойду проверю.
Такая проблема с лучами была бы критической и её немедленно бы исправили в минорной версии.
>>07152 (OP)
Когда сидел на гамаке, со стороны годоте слышал кудахты что Юай такой, такой Юай. Так удобно делать Юай. Сегодня залез в годоте в эти ваши контейнеры, сделал привязку к правой стене с сохранением аспект ратио. Уменьшаю окно - лезет влево. попробовал через марджин контейнер, попробовал через горизонтальный контйнер. Лезет влево да и ещё с этими наследованиям хуй поймешь что влияет, что не влияет. Плюннул я на эти ваши Юаи, напиал логику напрямую к спрайт2д как в гамаке, все работает как надо. Хуйня эти ваши юаи. Как только что-то более кастомное чем стандартную кнопку делать так сразу все летит нахер. Эти ноды ваши - хуйня полная. Хотел маску для спрайтов сделать... Маски делаются через Лайт2д. Хуан ебнутый? Как этим пользоваться?
Когда сидел на гамаке, со стороны годоте слышал кудахты что Юай такой, такой Юай. Так удобно делать Юай. Сегодня залез в годоте в эти ваши контейнеры, сделал привязку к правой стене с сохранением аспект ратио. Уменьшаю окно - лезет влево. попробовал через марджин контейнер, попробовал через горизонтальный контйнер. Лезет влево да и ещё с этими наследованиям хуй поймешь что влияет, что не влияет. Плюннул я на эти ваши Юаи, напиал логику напрямую к спрайт2д как в гамаке, все работает как надо. Хуйня эти ваши юаи. Как только что-то более кастомное чем стандартную кнопку делать так сразу все летит нахер. Эти ноды ваши - хуйня полная. Хотел маску для спрайтов сделать... Маски делаются через Лайт2д. Хуан ебнутый? Как этим пользоваться?
18 Кб, 524x188>>09308
На самом деле всё у меня сделано так, как задумано, и единственная проблема — это хитбоксы, которые наслаиваются и годот считает их одной и той же нодой. Враги действительно должны наслаиваться, атаковать синхронно, если накапливаются в одном месте. Главная проблема — Это одновременная смерть всех накопившихся персонажей от удара единственного противника.
>>09314
Метод play_ability() из >>09272 записан в _physics_process(), далее всё на скриншотах. Может из-за физ-процесса нода успевает захватить все объекты, которые коснулись луча?
Тут я пометил цифрами 1 и 2 хронологию кода, по аналогии с постом >>09272.
На самом деле всё у меня сделано так, как задумано, и единственная проблема — это хитбоксы, которые наслаиваются и годот считает их одной и той же нодой. Враги действительно должны наслаиваться, атаковать синхронно, если накапливаются в одном месте. Главная проблема — Это одновременная смерть всех накопившихся персонажей от удара единственного противника.
>>09314
Метод play_ability() из >>09272 записан в _physics_process(), далее всё на скриншотах. Может из-за физ-процесса нода успевает захватить все объекты, которые коснулись луча?
>работа атаки.PNG
Тут я пометил цифрами 1 и 2 хронологию кода, по аналогии с постом >>09272.
>>09307
Игра-песочница с камерными локациями, геймплейными элементами выживалки и крафта. Главный герой путешествует на титанической махине сквозь бесконечную толщу, вспененную пустотными ячейками в которых живёт жизнь, когда дружелюбная, когда опасная. В пустотах ГГ находит материалы для починки и апгрейда своего толщехода, а так же для торговли ресурсами в цивилизованных пустотах.
Главная фишка игры: осевая и точечная гравитации. В толщеходе осевая, поскольку при его движении внутренняя кабина вращается, как Рама в книжке "свидание с Рамой", а в пустотах точечная инверсная гравитация, отталкивающая всё от центра к краям, но в центре ячейки невесомость и там может бесконечно долго уравновешенно зависать светящийся кусок первичной толщи, заменяя жителям ячейки солнце. Мало того, этот фрагмент толщи может вращаться, а вокруг него по орбите может вращаться кусок поменьше и из вторичных материй, делая жителям ячейки что-то типа смены дня и ночи, но не совсем. Если у тебя есть воображение, можешь себе представить, как на локации в центре висит OmniLight и освещает противоположный край, прямого света на твоей стороне нет, но есть отражённый. Зрелище неописуемое. Кто играл в игру "Вселенная наоборот с Толщеходами", тот никогда не забудет это явление природы. В нашей вселенной, пока что, в эту игру играл только я, и только в своей голове. Но когда нибудь, я встану с печи и сделаю её.
Игра организована как бесшовный мир в котором подзагрузка локаций спрятана за мини-игрой в кабине толщехода. Эта кабина по сути хаб игрока, где можно прокачиваться, перечитывать записки, строить планы и осуществлять навигацию по пустотам на карте. По сути это как космический симулятор, только в космосе-наоборот, где пространство - заполнено материей, а планеты - это пустоты в бесконечнозаполненном космосе.
> игру мечты
> На полном серьезе спрошу-что это для вас?
Игра-песочница с камерными локациями, геймплейными элементами выживалки и крафта. Главный герой путешествует на титанической махине сквозь бесконечную толщу, вспененную пустотными ячейками в которых живёт жизнь, когда дружелюбная, когда опасная. В пустотах ГГ находит материалы для починки и апгрейда своего толщехода, а так же для торговли ресурсами в цивилизованных пустотах.
Главная фишка игры: осевая и точечная гравитации. В толщеходе осевая, поскольку при его движении внутренняя кабина вращается, как Рама в книжке "свидание с Рамой", а в пустотах точечная инверсная гравитация, отталкивающая всё от центра к краям, но в центре ячейки невесомость и там может бесконечно долго уравновешенно зависать светящийся кусок первичной толщи, заменяя жителям ячейки солнце. Мало того, этот фрагмент толщи может вращаться, а вокруг него по орбите может вращаться кусок поменьше и из вторичных материй, делая жителям ячейки что-то типа смены дня и ночи, но не совсем. Если у тебя есть воображение, можешь себе представить, как на локации в центре висит OmniLight и освещает противоположный край, прямого света на твоей стороне нет, но есть отражённый. Зрелище неописуемое. Кто играл в игру "Вселенная наоборот с Толщеходами", тот никогда не забудет это явление природы. В нашей вселенной, пока что, в эту игру играл только я, и только в своей голове. Но когда нибудь, я встану с печи и сделаю её.
Игра организована как бесшовный мир в котором подзагрузка локаций спрятана за мини-игрой в кабине толщехода. Эта кабина по сути хаб игрока, где можно прокачиваться, перечитывать записки, строить планы и осуществлять навигацию по пустотам на карте. По сути это как космический симулятор, только в космосе-наоборот, где пространство - заполнено материей, а планеты - это пустоты в бесконечнозаполненном космосе.
>>09321
Решительно непонятно почему у тебя так, при том что рейкаст обнаруживает только одну цель. То есть так может быть только если ты умышленно написал код который посылает рейкаст раз за разом.
>Это одновременная смерть всех накопившихся персонажей
Решительно непонятно почему у тебя так, при том что рейкаст обнаруживает только одну цель. То есть так может быть только если ты умышленно написал код который посылает рейкаст раз за разом.
>>09307
Все расписывать не буду, а то палевно да и утащить могут. Скажем так это 3д экшн-слешер-рпг в песочнице с постройкой баз.
Все расписывать не буду, а то палевно да и утащить могут. Скажем так это 3д экшн-слешер-рпг в песочнице с постройкой баз.
>>09314
Проверил. Лол, у меня иногда на высокой скорости движения луча цели не регистрируются, но только когда они столпились кучей в одном месте...
Самое странное, что повышение TPS даже до 480 не исправило проблему полностью, только уменьшило.
>>09321
Ясно. Он вызывается 60 раз в секунду по умолчанию.
Делай после каждого попадания кулдаун:
Без кулдауна атака вида "торчащая писька" будет делать 60 ударов в секунду, убивая толпу быстрее, чем ты можешь заметить. Т.е. тебе только кажется, что они умирают все сразу, на деле же - по очереди.
>Сейчас пойду проверю.
Проверил. Лол, у меня иногда на высокой скорости движения луча цели не регистрируются, но только когда они столпились кучей в одном месте...
Самое странное, что повышение TPS даже до 480 не исправило проблему полностью, только уменьшило.
>>09321
>Метод play_ability() _physics_process()
Ясно. Он вызывается 60 раз в секунду по умолчанию.
Делай после каждого попадания кулдаун:
>attack_ray.enabled = false
>cooldown_timer.start()
Без кулдауна атака вида "торчащая писька" будет делать 60 ударов в секунду, убивая толпу быстрее, чем ты можешь заметить. Т.е. тебе только кажется, что они умирают все сразу, на деле же - по очереди.
>>09341
В смысле, если у тебя в коде такая запись:
>Без кулдауна атака вида "торчащая писька" будет делать 60 ударов в секунду
В смысле, если у тебя в коде такая запись:
>func _physics_process():
> if ray.is_colliding(): play_ability()
Кстати, кто-нибудь читал эту книгу:
Там как раз (ближе к концу книги) описан процесс итеративной разработки, в котором вы сначала делаете кучу кривых прототипов из CSG нод.
>Tynan Sylvester. Designing Games: A Guide to Engineering Experiences
Там как раз (ближе к концу книги) описан процесс итеративной разработки, в котором вы сначала делаете кучу кривых прототипов из CSG нод.
>>09341
Не так. У меня для атаки есть аниматор и отдельный таймер. Каждый раз, когда Timer timeout, происходит один хит.
и
Было некрасиво с моей стороны это умолчать. Я изначально наносил урон в момент Animator.is_stopped(), но получалось некрасиво, ведь враг получал урон, когда персонаж уже встал в стойку смирно после удара, поэтому в момент запуска анимации я запускал таймер с нужным (красивым) таймингом для урона и уже на сигнал timeout отнималось здоровье у target. Вот так вот...
>60 ударов в секунду
Не так. У меня для атаки есть аниматор и отдельный таймер. Каждый раз, когда Timer timeout, происходит один хит.
>таймер.PNG
и
>Эпизод три.png
Было некрасиво с моей стороны это умолчать. Я изначально наносил урон в момент Animator.is_stopped(), но получалось некрасиво, ведь враг получал урон, когда персонаж уже встал в стойку смирно после удара, поэтому в момент запуска анимации я запускал таймер с нужным (красивым) таймингом для урона и уже на сигнал timeout отнималось здоровье у target. Вот так вот...
>>09349
Очень кривые и неточные. И к тому же работают мимо физики. Если у тебя есть анимейшон_плеер, добавь в анимацию атаки дорожку с вызовом функции, чтобы функция нанесения дамага вызывалась точно в нужный момент. Это гарантирует, что визуальная составляющая совпадёт с реальной, да к тому же даст супер-точный тайминг, который будет одинаков везде и всегда. В отличие от таймеров.
>таймеры
Очень кривые и неточные. И к тому же работают мимо физики. Если у тебя есть анимейшон_плеер, добавь в анимацию атаки дорожку с вызовом функции, чтобы функция нанесения дамага вызывалась точно в нужный момент. Это гарантирует, что визуальная составляющая совпадёт с реальной, да к тому же даст супер-точный тайминг, который будет одинаков везде и всегда. В отличие от таймеров.
>>09349
Эмм... Вообще-то, кулдаун - это время "перезарядки". Таймаут таймера должен не наносить удар, а только разрешать совершение удара.
В частности, предлагаю сделать так:
Или, если хочешь более абстрактно:
А дальше ты где-то проверяешь, можно ли атаковать.
>когда Timer timeout, происходит один хит
Эмм... Вообще-то, кулдаун - это время "перезарядки". Таймаут таймера должен не наносить удар, а только разрешать совершение удара.
В частности, предлагаю сделать так:
>func _on_cooldown_timeout():
> attack_ray.enabled = true
Или, если хочешь более абстрактно:
> attack_ready = true
А дальше ты где-то проверяешь, можно ли атаковать.
>>09352
Это работает только для оружия с точечным уроном.
Если ты меч крутишь, он может нанести урон в любой момент, когда заденет врага - но после этого уйдёт на перезарядку, продолжая визуально вращаться.
>добавь в анимацию атаки дорожку с вызовом функции, чтобы функция нанесения дамага вызывалась точно в нужный момент
Это работает только для оружия с точечным уроном.
Если ты меч крутишь, он может нанести урон в любой момент, когда заденет врага - но после этого уйдёт на перезарядку, продолжая визуально вращаться.
>>09318
Тебе шашечки или ехать?
Лол.
Что за "стена"? Что ты хотел? В пейнте нарисуй.
В Godot действительно хороший GUI. Нужно просто разбираться в базе построения адаптивных GUI.
>Маски делаются через Лайт2д.
Тебе шашечки или ехать?
>Плюннул я на эти ваши Юаи, напиал логику напрямую к спрайт2д как в гамаке
Лол.
>сделал привязку к правой стене с сохранением аспект ратио. Уменьшаю окно - лезет влево
Что за "стена"? Что ты хотел? В пейнте нарисуй.
В Godot действительно хороший GUI. Нужно просто разбираться в базе построения адаптивных GUI.
>>09376
Это украли.
Вот теперь, когда очередной вор идей будет вас уговаривать изложить на двачах свою идею, потому что "ну да кому ты нужен со своими идеями", приведите в пример эту игру.
Это украли.
Вот теперь, когда очередной вор идей будет вас уговаривать изложить на двачах свою идею, потому что "ну да кому ты нужен со своими идеями", приведите в пример эту игру.
>>09392
Помогите что тут не так!
Помогите что тут не так!
>>09396
Бля спасибо анон правда сработало!
Бля спасибо анон правда сработало!
383 Кб, 500x500>>09392
ебусь с шарпом и мне пох, но быстрый гуглеж показал что
= это присваивание.
:= с явным приведением типа.
так как var collider у тебя не типизирован - приведение тут не знает к чему приводить. или укажи тип явно или юзай обычное присваивание.
ебусь с шарпом и мне пох, но быстрый гуглеж показал что
= это присваивание.
:= с явным приведением типа.
так как var collider у тебя не типизирован - приведение тут не знает к чему приводить. или укажи тип явно или юзай обычное присваивание.
202 Кб, 1366x768Ребята а я же ему написал чтоб он выводил, чё он не выводит текст-то ёпти бля? Гыыыы ёпти.
>>09402
Скорее всего у тебя код unreachable. То есть не исполняется, потому что ифы твои не соблюдаются.
Скорее всего у тебя код unreachable. То есть не исполняется, потому что ифы твои не соблюдаются.
>>09408
Одно из двух условий, ведущих к твоему принту, не срабатывает. Либо ты action_pressed не нажимаешь, либо рейкаст не коллайдинг.
Алсо у тебя странная структура сцены. Нет причин, по которым рейкаст должен сидеть внутри аниматора, а аниматор внутри меша.
Одно из двух условий, ведущих к твоему принту, не срабатывает. Либо ты action_pressed не нажимаешь, либо рейкаст не коллайдинг.
Алсо у тебя странная структура сцены. Нет причин, по которым рейкаст должен сидеть внутри аниматора, а аниматор внутри меша.
>>09408
if на 22 или 24 не дает true, поэтому исполнение кода не доходит до print. Поставь брекпоинт на 22ую строку и запусти игру. Потом пошагово смотри что происходит и где обсер
if на 22 или 24 не дает true, поэтому исполнение кода не доходит до print. Поставь брекпоинт на 22ую строку и запусти игру. Потом пошагово смотри что происходит и где обсер
>>09412
https://www.gdquest.com/tutorial/godot/gdscript/debugging/
Метка в едиторе кода которая паузит выполнение кода пока ты не разрешишь идти дальше. Короче разберись что такое дебаггинг, без этого никак
>Поставить что?
https://www.gdquest.com/tutorial/godot/gdscript/debugging/
Метка в едиторе кода которая паузит выполнение кода пока ты не разрешишь идти дальше. Короче разберись что такое дебаггинг, без этого никак
У меня есть хитбокс (area) и физическая коллизия у нпс (kinematic). Снаряды, тоже кинематик, должны отскакивать от нпс, но должны и бить по хитбоксу. Проблема в том, что ареа хитбокса и физическая коллизия - идентичны, и снаряд иногда отскакивает от нпс так и не задев хитбокс. Сейчас я это решил сделав хитбокс на 0.01 больше чем физическая коллизия, но тут возникает редкий случай удара по касательной, когда снаряд задевает хитбокс, а коллизию не задевает. Есть ли способ лучше?
>>09416
Если они идентичны, то может отсылать сигнал из физ коллизии к хитбоксу и наносить урон?
Если они идентичны, то может отсылать сигнал из физ коллизии к хитбоксу и наносить урон?
Сап, Годаны! Такой вопрос - получаю я значит объект в переменную, а как мне взять ноду объекта, чтобы потом взять дерево сцены? Может быть хуйню какую-то вообще несу?
Бля, объясню по другому, что мне нужно. Есть основная сцена, где происходит игра. Есть просто сцены, которых нету в основной. Мне жужно, чтобы я на выбранную сцену, прикрепил в качестве дочерней одну из незадействованных сцен. Грубо говоря к кубу прикрепил треугольник. Вот есть у меня вроде скрипт, которым я получаю информацию из под курсора - позицию там, коллайдер, меш, ещё там херня всякая. И вот я объект этот могу в переменную поместить. Ну или не обязательно конечно, в общем не могу никак догнать логику всей этой шняги. Почему просто незя взять сцену объекта, и поместить ему как дочернюю другую сцену?
>>09446
Инстанс сцены сделал перед добавлением?
Инстанс сцены сделал перед добавлением?
>>09449
А бля, заработало. Но по поводу инстанса, как его правильно делать? У меня сейчас в переменную x_scene preload'ится сцена, потом в переменную x уже инстанс. Правильно или нет? Чет не хочется переменными засирать вот так.
А бля, заработало. Но по поводу инстанса, как его правильно делать? У меня сейчас в переменную x_scene preload'ится сцена, потом в переменную x уже инстанс. Правильно или нет? Чет не хочется переменными засирать вот так.
>>09453
Точно, спасибо!
Точно, спасибо!
Бляха... Извините за флуд, но ещё глупый вопрос - можно ли как-то добавить дочерний узел прямо под корневым, чтоб он всегда имел индекс 0?
35 Кб, 1106x221>>09457
Учись гуглить
Учись гуглить
Никак не могу понять, почему в официальном демо:
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
В демке ошибка или в документации?
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).
В демке ошибка или в документации?
>>09402
Дурачок, ты сообщения в консоли скрыл, лол. Нажми кнопки справа, там где иконки смешные и цифорки.
Дурачок, ты сообщения в консоли скрыл, лол. Нажми кнопки справа, там где иконки смешные и цифорки.
>>09356
Экспортируем булевую переменную "can_do_damage". Меняем её значение в треке анимации. Наносим дамаг в физикс_процессе, опрашивая все попавшие хитбоксы. И это всё ещё лучше, чем таймеры.
>>09464
В документации всё верно, но речь о другой ситуации. Если ты хочешь прицепить к ригиду реактивный двигатель, то надо апплаить силу, а если разочек толкнуть - то импульс. Но если уж тебе всё равно придётся каждый кадр контролировать, то лучше снова импульс.
А вообще, лично я б в той демке импульс на дельту домножил, тогда он станет фреймрейто-независимым.
>>09379
Не украли, а реализовали раньше тебя.
Годаны, вопрос! А как узнать, что окно браузера с веб-версией игры свернулось/развернулось? На ЯИ мочераторы не пропустили, потому что при сворачивании музыка должна замолкать, а я чёт думал, что это и не определить никак. Нотификейшенов соответствующих нету вроде (ну, мобильные есть). Как?
Экспортируем булевую переменную "can_do_damage". Меняем её значение в треке анимации. Наносим дамаг в физикс_процессе, опрашивая все попавшие хитбоксы. И это всё ещё лучше, чем таймеры.
>>09464
В документации всё верно, но речь о другой ситуации. Если ты хочешь прицепить к ригиду реактивный двигатель, то надо апплаить силу, а если разочек толкнуть - то импульс. Но если уж тебе всё равно придётся каждый кадр контролировать, то лучше снова импульс.
А вообще, лично я б в той демке импульс на дельту домножил, тогда он станет фреймрейто-независимым.
>>09379
>украли
Не украли, а реализовали раньше тебя.
Годаны, вопрос! А как узнать, что окно браузера с веб-версией игры свернулось/развернулось? На ЯИ мочераторы не пропустили, потому что при сворачивании музыка должна замолкать, а я чёт думал, что это и не определить никак. Нотификейшенов соответствующих нету вроде (ну, мобильные есть). Как?
>>09438
Если ты получаешь "игровой объект", то это и есть нода какого-то типа, но обязательно потомок Node.
Если у тебя код в потомке Node и находится внутри дерева сцены, то просто пиши get_tree() - это будет аналогично self.get_tree(). Дерево сцены у тебя всё равно единственное должно быть.
https://docs.godotengine.org/en/stable/classes/class_node.html#class-node-method-get-tree
>получаю я значит объект в переменную, а как мне взять ноду объекта
Если ты получаешь "игровой объект", то это и есть нода какого-то типа, но обязательно потомок Node.
>чтобы потом взять дерево сцены
Если у тебя код в потомке Node и находится внутри дерева сцены, то просто пиши get_tree() - это будет аналогично self.get_tree(). Дерево сцены у тебя всё равно единственное должно быть.
https://docs.godotengine.org/en/stable/classes/class_node.html#class-node-method-get-tree
>>09468
Лол, разве это не обязанность браузеров?
Он "реактивный" только если ты его используешь безусловно, то есть не проверяешь касание пола.
А что это даст? Я не понимаю. По логике, если ты перестаёшь прикладывать силу, объект всё ещё движется по инерции; если ты даёшь объекту один толчок, он движется только за счёт инерции...
Алсо, вот в физике есть сила трения - это force? Она ведь постоянно действует, пока есть контакт.
>при сворачивании музыка должна замолкать
Лол, разве это не обязанность браузеров?
>реактивный двигатель
Он "реактивный" только если ты его используешь безусловно, то есть не проверяешь касание пола.
>Но если уж тебе всё равно придётся каждый кадр контролировать, то лучше снова импульс.
А что это даст? Я не понимаю. По логике, если ты перестаёшь прикладывать силу, объект всё ещё движется по инерции; если ты даёшь объекту один толчок, он движется только за счёт инерции...
Алсо, вот в физике есть сила трения - это force? Она ведь постоянно действует, пока есть контакт.
>>09468
Я пока не копал, но там в любом случае можно написать кастомный js скрипт
https://godotforums.org/d/28241-html5-signal-when-page-recover-the-focus/4
Я пока не копал, но там в любом случае можно написать кастомный js скрипт
https://godotforums.org/d/28241-html5-signal-when-page-recover-the-focus/4
117 Кб, 1280x600>>09466
Нахуй ты грубишь, быдло?
Нахуй ты грубишь, быдло?
>>09392
Запись вида:
Является укороченной записью вида:
И выполняется в рантайме, поэтому может вернуть ноду неизвестного заранее типа - в зависимости от того, что у тебя в сцене имеет имя "RayCast3D".
Оператор ":=" определяет тип переменной по типу присваиваемых данных до выполнения скрипта, поэтому ему нужно заранее знать, что ты пытаешься присвоить. Поскольку тип ответа от get_node() можно узнать только в рантайме, Godot ругается на этот код.
Хорошая практика - делать так:
Тогда ты сможешь без проблем писать такой код:
Который будет понятнее, быстрее и точнее, а ещё будет проще отредактировать (все строки вверху).
Для упрощения добавления этого куска кода:
1. Зажми левую кнопку мыши на ноде в дереве.
2. Зажми ctrl и shift, пока удерживаешь ноду мышкой.
3. Перетащи ноду в желаемое место в редакторе кода.
4. Отпусти кнопку мыши.
Редактор сгенерирует строчку с @onready.
>>09396
Толк в том, что переменная будет иметь тип.
>>09399
Ребят, это не приведение типа. Приведение типа:
https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/gdscript_basics.html#casting
Там совсем другой смысл, не путай ньюфага.
GDScript - последовательно типизированный:
https://en.wikipedia.org/wiki/Gradual_typing
Т.е. поддерживает и статическую, и динамическую типизацию одновременно, в зависимости от кода.
По умолчанию, когда ты не указываешь тип данных, типизация динамическая, пример:
Функции без указания типов принимают что угодно и возвращают что угодно либо ничего:
Динамическая типизация имеет преимущества и недостатки, поэтому есть статическая типизация.
Статическая типизация включается, когда вы явно указываете типы или используете ":=", примеры:
Суть ":=" в том, чтобы не писать лишнего:
Т.е. задействуется статическая типизация, если это возможно (иначе будет >>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), но при этом вам не обязательно явно прописывать тип данных.
Я не уверен на счёт "="/":=" в аргументах функций...
>>09392
Запись вида:
Является укороченной записью вида:
И выполняется в рантайме, поэтому может вернуть ноду неизвестного заранее типа - в зависимости от того, что у тебя в сцене имеет имя "RayCast3D".
Оператор ":=" определяет тип переменной по типу присваиваемых данных до выполнения скрипта, поэтому ему нужно заранее знать, что ты пытаешься присвоить. Поскольку тип ответа от get_node() можно узнать только в рантайме, Godot ругается на этот код.
Хорошая практика - делать так:
Тогда ты сможешь без проблем писать такой код:
Который будет понятнее, быстрее и точнее, а ещё будет проще отредактировать (все строки вверху).
Для упрощения добавления этого куска кода:
1. Зажми левую кнопку мыши на ноде в дереве.
2. Зажми ctrl и shift, пока удерживаешь ноду мышкой.
3. Перетащи ноду в желаемое место в редакторе кода.
4. Отпусти кнопку мыши.
Редактор сгенерирует строчку с @onready.
>>09396
Толк в том, что переменная будет иметь тип.
>>09399
Ребят, это не приведение типа. Приведение типа:
https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/gdscript_basics.html#casting
Там совсем другой смысл, не путай ньюфага.
GDScript - последовательно типизированный:
https://en.wikipedia.org/wiki/Gradual_typing
Т.е. поддерживает и статическую, и динамическую типизацию одновременно, в зависимости от кода.
По умолчанию, когда ты не указываешь тип данных, типизация динамическая, пример:
Функции без указания типов принимают что угодно и возвращают что угодно либо ничего:
Динамическая типизация имеет преимущества и недостатки, поэтому есть статическая типизация.
Статическая типизация включается, когда вы явно указываете типы или используете ":=", примеры:
Суть ":=" в том, чтобы не писать лишнего:
Т.е. задействуется статическая типизация, если это возможно (иначе будет >>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), но при этом вам не обязательно явно прописывать тип данных.
Я не уверен на счёт "="/":=" в аргументах функций...
>>09490
Эээ, кажись перепутал, "$" равен просто get_node().
Т.е. должно быть возможно сделать так:
Но это уже говнокод какой-то, не делайте так.
>>$RayCast3D
>Является укороченной записью вида:
>>self.get_node("RayCast3D")
Эээ, кажись перепутал, "$" равен просто get_node().
Т.е. должно быть возможно сделать так:
>get_parent().$Foo
>var node: Node...
>node.$Foo
Но это уже говнокод какой-то, не делайте так.
>>09472
Там как то хитрее работает. В архитектуре буллета, которая использовалась, форс все равно надо каждый кадр применять. Разница, впроде в том, что add force ее интегрирует в общем растягивает на весь временной шаг, а add impulse нет. Наверное можно считать что force умножает на дельту сам, а impulse нет. Может быть я что-то не так понимаю, конечно.
Там как то хитрее работает. В архитектуре буллета, которая использовалась, форс все равно надо каждый кадр применять. Разница, впроде в том, что add force ее интегрирует в общем растягивает на весь временной шаг, а add impulse нет. Наверное можно считать что force умножает на дельту сам, а impulse нет. Может быть я что-то не так понимаю, конечно.
9 Кб, 366x370А что, AnimatedSprite2D привязан к фпс, а не ко времени?
Я хочу чтобы у меня деревья на фоне качались, допустим.
На экране 120гц они будут качаться в два раза быстрее чем на 60гц?
Я хочу чтобы у меня деревья на фоне качались, допустим.
На экране 120гц они будут качаться в два раза быстрее чем на 60гц?
>>09506
Ты че, ебанат? Не, ну это просто ахуеть можно. У вас в годоте все такие недоразвитые чтоли? Фпс буквально переводится как кадр в секунду. Каждый спрайт анимации - это кадр. У тебя на скрине 5 фпс. А это значит что у тебя за 1 секунду проиграется 5 кадров анимации. Ты реально на столько даун или че?
мимо в юнититред шел
Ты че, ебанат? Не, ну это просто ахуеть можно. У вас в годоте все такие недоразвитые чтоли? Фпс буквально переводится как кадр в секунду. Каждый спрайт анимации - это кадр. У тебя на скрине 5 фпс. А это значит что у тебя за 1 секунду проиграется 5 кадров анимации. Ты реально на столько даун или че?
мимо в юнититред шел
>>09507
Теперь понятно, спасибо.
А я-то подумал это значит всю анимацию нужно проиграть за 5 экранных кадров.
И хуле ты такой злой? Мне когда надоест с годотом ковыряться, я и ваше говно скачаю и буду задавать тупые вопросы, готовься морально.
> А это значит что у тебя за 1 секунду проиграется 5 кадров анимации
Теперь понятно, спасибо.
А я-то подумал это значит всю анимацию нужно проиграть за 5 экранных кадров.
И хуле ты такой злой? Мне когда надоест с годотом ковыряться, я и ваше говно скачаю и буду задавать тупые вопросы, готовься морально.
>>09506
Эта нода нужна для покадровой анимации. При создании покадровой анимации определяется определённая частота кадров, например, в классических мультфильмах обычно 12 кадров в секунду, в отличие от 24 к/с у фильмов. Т.е. тебе необходимо указать в этом поле конкретное число кадров в секунду, которое использовал художник. А движок постарается обеспечить заданную частоту.
Или ты хочешь указывать в миллисекундах на кадр?
Чтоб ты знал, герц - это обозначение единицы частоты любого периодического процесса:
https://ru.wikipedia.org/wiki/Гц
Так что частота кадров - это, по сути, герцы. Отличие от частоты монитора в том, что частота обновления зависит от электроники самого монитора - монитор будет обновляться даже если процессор завис и не может передать новую пачку данных в монитор.
У игр есть главный цикл - game loop, он повторяет фиксированный набор действий с определённой частотой. Но бессмысленно генерировать картинку чаще, чем экран физически может показать, кроме того, могут быть проблемы с отображением, если отправлять данные в монитор, когда он в процессе обновления. Поэтому изобрели вертикальную синхронизацию. Игра, условно, тормозит главный цикл до частоты экрана, избегая лишней работы.
Но когда речь заходит об анимациях, там "частота кадров" вообще не связана с главным циклом игры и обновлениями монитора. Это абстрактная частота смены кадров в анимации - а сможет ли движок отобразить все кадры анимации и дойдут ли они до монитора вовремя это уже детали реализации.
>AnimatedSprite2D
Эта нода нужна для покадровой анимации. При создании покадровой анимации определяется определённая частота кадров, например, в классических мультфильмах обычно 12 кадров в секунду, в отличие от 24 к/с у фильмов. Т.е. тебе необходимо указать в этом поле конкретное число кадров в секунду, которое использовал художник. А движок постарается обеспечить заданную частоту.
Или ты хочешь указывать в миллисекундах на кадр?
>120гц
>60гц
Чтоб ты знал, герц - это обозначение единицы частоты любого периодического процесса:
https://ru.wikipedia.org/wiki/Гц
Так что частота кадров - это, по сути, герцы. Отличие от частоты монитора в том, что частота обновления зависит от электроники самого монитора - монитор будет обновляться даже если процессор завис и не может передать новую пачку данных в монитор.
У игр есть главный цикл - game loop, он повторяет фиксированный набор действий с определённой частотой. Но бессмысленно генерировать картинку чаще, чем экран физически может показать, кроме того, могут быть проблемы с отображением, если отправлять данные в монитор, когда он в процессе обновления. Поэтому изобрели вертикальную синхронизацию. Игра, условно, тормозит главный цикл до частоты экрана, избегая лишней работы.
Но когда речь заходит об анимациях, там "частота кадров" вообще не связана с главным циклом игры и обновлениями монитора. Это абстрактная частота смены кадров в анимации - а сможет ли движок отобразить все кадры анимации и дойдут ли они до монитора вовремя это уже детали реализации.
>>09513
Да, как раз про это и был вопрос по сути, это там кадры анимации или экранные кадры игры.
> Но когда речь заходит об анимациях, там "частота кадров" вообще не связана с главным циклом игры и обновлениями монитора. Это абстрактная частота смены кадров в анимации
Да, как раз про это и был вопрос по сути, это там кадры анимации или экранные кадры игры.
>>09474
Ох, я пока не настолько шарю в ЖС. Тем более вместе с ЯИ.
В общем, пока сделал на NOTIFICATION_WM_FOCUS_IN/OUT. Конечно, сворачивание от потери фокуса это не отличит, но пусть и при обычной потере фокуса звук пропадает.
>>09500
Я хз насчёт 3д и буллетов, но вот в 2д форс если ты прикрепил, то он действует бесконечно, а импульс - разовая акция.
>>09472
Ну например, тебе надо преодолевать какие-нибудь силы, типа гравитации или трения. Тогда единичный импульс не прокатит - надо либо систематически их давать, либо силу привязывать.
>кастомный js скрипт
Ох, я пока не настолько шарю в ЖС. Тем более вместе с ЯИ.
В общем, пока сделал на NOTIFICATION_WM_FOCUS_IN/OUT. Конечно, сворачивание от потери фокуса это не отличит, но пусть и при обычной потере фокуса звук пропадает.
>>09500
Я хз насчёт 3д и буллетов, но вот в 2д форс если ты прикрепил, то он действует бесконечно, а импульс - разовая акция.
>>09472
>А что это даст?
Ну например, тебе надо преодолевать какие-нибудь силы, типа гравитации или трения. Тогда единичный импульс не прокатит - надо либо систематически их давать, либо силу привязывать.
>>09515
Так 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().
>тебе надо преодолевать какие-нибудь силы, типа гравитации или трения
Так 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().
12 Кб, 627x214Ребят, а как на кнопку поменять переменную? Если поставить просто куеуе_фри, то объект исчезает и меняет переменную
>>09522
А все понял, сделаль
А все понял, сделаль
>>09515
Вроде ничего сложного, и 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 своего сигнала
Вроде ничего сложного, и 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 своего сигнала
>>09534
Спасибо за старания, анонче.
Твой код я использовать не буду (хотя...), потому что на нотификации потери фокуса норм работает (да и нехер игре работать не в фокусе, в любом случае). Но внимательно его перечитал и вкурил, как вообще осуществляется взаимодействие ГД и ЖС.
Я прост как раз последние пару дней поглощаю инфу по всяким жабаскриптам и похапэ, хочу себе сайт забацать. Вот, в общую копилочку знаний ляжет. Смогу по-взрослому заэмбеддить игру прямо в страницу сайта.
Спасибо за старания, анонче.
Твой код я использовать не буду (хотя...), потому что на нотификации потери фокуса норм работает (да и нехер игре работать не в фокусе, в любом случае). Но внимательно его перечитал и вкурил, как вообще осуществляется взаимодействие ГД и ЖС.
Я прост как раз последние пару дней поглощаю инфу по всяким жабаскриптам и похапэ, хочу себе сайт забацать. Вот, в общую копилочку знаний ляжет. Смогу по-взрослому заэмбеддить игру прямо в страницу сайта.
>>09535
Так я себе сейчас написал, для своей яндексказуалки, а сюда вывалил, опенсорс же
Так я себе сейчас написал, для своей яндексказуалки, а сюда вывалил, опенсорс же
40 Кб, 838x354Сап. Есть такой скрипт, на ноде2д, у которой в чайлд popup menu. По задумке, как я понимаю, при попадании курсора мыши на popup меню, в консоль будет отправляться сообщение. Но этого не происходит. Я что-то не так делаю?
>>09559
Хз что то странное я переписал твой код и работает, но кроме самого первого раза. Может там фокуса какого то нет.
Хз что то странное я переписал твой код и работает, но кроме самого первого раза. Может там фокуса какого то нет.
>>09561
Не знаю, сейчас не могу посмотреть, да и 4-ка у меня нестабильно работает. Ну если у тебя задумка именно такая как написано, то при нажатии ты всегда в рамке значит можешь вообще без условия вызывать функцию.
Не знаю, сейчас не могу посмотреть, да и 4-ка у меня нестабильно работает. Ну если у тебя задумка именно такая как написано, то при нажатии ты всегда в рамке значит можешь вообще без условия вызывать функцию.
Я попробовал еще пару вариантов и не помогло. Так что надо issue открывать. Но я сегодня не успею.
Я поменял popupMenu на window, и всё равно не работает.
>>09567
закинь в тред ссылку как откроешь
закинь в тред ссылку как откроешь
>>09556
Посмотри родителей, всех кто выше. Там запросто может оказаться элемент, съедающий в себя твой попап. Для понимания - если ты на весь экран растянешь прозрачный TextureRect, то все, что ниже него, получать инпут перестанет - он съест. Управляется это через mouse_filter
Посмотри родителей, всех кто выше. Там запросто может оказаться элемент, съедающий в себя твой попап. Для понимания - если ты на весь экран растянешь прозрачный TextureRect, то все, что ниже него, получать инпут перестанет - он съест. Управляется это через mouse_filter
>>09468
Правильный ответ. Потому что идея не моя, а коллективная. Форс толщеходов здесь возник именно как реакция на споры о том, воруются ли идеи или нет. Так-то идее сто лет в обед, создавалась ещё на доброчане, на основе более ранних идей. Но фишка не в этом. Фишка в том, что реально ценные собственные идеи осторожный анон (я) вам тут в паблик не выложит. Потому что, как мы видим, через пару лет после форса толщеходов, клон идеи таки появился в стиме. И кто-то на нём зарабатывает прямо щас. Не миллионы, конечно, но какую-то копеечку поимел(и).
> Не украли, а реализовали раньше тебя.
Правильный ответ. Потому что идея не моя, а коллективная. Форс толщеходов здесь возник именно как реакция на споры о том, воруются ли идеи или нет. Так-то идее сто лет в обед, создавалась ещё на доброчане, на основе более ранних идей. Но фишка не в этом. Фишка в том, что реально ценные собственные идеи осторожный анон (я) вам тут в паблик не выложит. Потому что, как мы видим, через пару лет после форса толщеходов, клон идеи таки появился в стиме. И кто-то на нём зарабатывает прямо щас. Не миллионы, конечно, но какую-то копеечку поимел(и).
>>09583
DigDug и Mr. Driller тоже на доброчане придумали?
DigDug и Mr. Driller тоже на доброчане придумали?
>>07152 (OP)
А есть сурс модельки?
А есть сурс модельки?
>>09583
Никак вы, блять, не научитесь, что
не существуют. Если только это не быстрое разложение большого числа на простые множители. Идей в интернетах - лопатой греби. С развитием нейронок так тем более.
Ценой обладает лишь реализация. Вложенный труд: сценарий, код, графика, звук и т.д. Кто-то с толщеходами зарабатывает на реализации. А раз зарабатывает не миллионы, то и реализация, очевдно, не так уж хороша. Решительно ничего не поменялось бы, если бы если бы вместо этой идеи там был бы, например, ремейк Вангеров или что-нибудь по мотивам Рика и Морти.
Никак вы, блять, не научитесь, что
>ценные идеи
не существуют. Если только это не быстрое разложение большого числа на простые множители. Идей в интернетах - лопатой греби. С развитием нейронок так тем более.
Ценой обладает лишь реализация. Вложенный труд: сценарий, код, графика, звук и т.д. Кто-то с толщеходами зарабатывает на реализации. А раз зарабатывает не миллионы, то и реализация, очевдно, не так уж хороша. Решительно ничего не поменялось бы, если бы если бы вместо этой идеи там был бы, например, ремейк Вангеров или что-нибудь по мотивам Рика и Морти.
Всё-таки юзать RigidBody3D или CharacterBody3D?
Попытался расписать самому себе, что мне вообще требуется от контроллера... Думал, это поможет мне определиться, но что-то не получилось.
Вкратце, что мне нужно:
- физически точное взаимодействие с RigidBody3D, желательно без внезапного расколбаса всей сцены;
- физически точная траектория свободного полёта;
- но при этом ходьба должна быть ходьбой, а не виртуальными ракетами на спине персонажа;
- персонаж должен сопротивляться слабым толчкам RigidBody3D, а то выглядит как будто ты управляешь катящимся шариком, а не человеком с ногами.
В идеале, чтоб можно было безболезненно сменить физический движок, ибо судьба Godot Physics под вопросом, а у Jolt какие-то свои нюансы.
Главный вопрос: есть ли принципиальная разница? Возможно ли повторить одно и то же произвольное поведение на CharacterBody3D и RigidBody3D? Проще говоря, что именно я теряю, выбирая одно из двух?
Попытался расписать самому себе, что мне вообще требуется от контроллера... Думал, это поможет мне определиться, но что-то не получилось.
Вкратце, что мне нужно:
- физически точное взаимодействие с RigidBody3D, желательно без внезапного расколбаса всей сцены;
- физически точная траектория свободного полёта;
- но при этом ходьба должна быть ходьбой, а не виртуальными ракетами на спине персонажа;
- персонаж должен сопротивляться слабым толчкам RigidBody3D, а то выглядит как будто ты управляешь катящимся шариком, а не человеком с ногами.
В идеале, чтоб можно было безболезненно сменить физический движок, ибо судьба Godot Physics под вопросом, а у Jolt какие-то свои нюансы.
Главный вопрос: есть ли принципиальная разница? Возможно ли повторить одно и то же произвольное поведение на CharacterBody3D и RigidBody3D? Проще говоря, что именно я теряю, выбирая одно из двух?
>>09593
Т.е. если что-то на GPU невозможно или слишком затратно делать, то этого вообще в движке не будет?
>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 невозможно или слишком затратно делать, то этого вообще в движке не будет?
201 Кб, 1814x753>>09671
Проверил так же на веб-версии Не работает. Может всё таки я что-то делаю не так?
Проверил так же на веб-версии Не работает. Может всё таки я что-то делаю не так?
>>09682
Если какие-то частицы невозможны на GPU, то на CPU это вообще будет бессымсленное слайдшоу.
Если какие-то частицы невозможны на GPU, то на CPU это вообще будет бессымсленное слайдшоу.
>>09450
имей ввиду что технически между этими двумя вариантами разницы нет. x_scene.instantiate() создает объект во "внешней" памяти и возвращает ссылку на него, которая сохраняется в "локальной" памяти скрипта и передается в add_child. разница только в том поименуешь ли ты эту ссылку(для дальнейшего использования или просто удобства) или нет
имей ввиду что технически между этими двумя вариантами разницы нет. x_scene.instantiate() создает объект во "внешней" памяти и возвращает ссылку на него, которая сохраняется в "локальной" памяти скрипта и передается в add_child. разница только в том поименуешь ли ты эту ссылку(для дальнейшего использования или просто удобства) или нет
10 Кб, 404x446>>09671
Я проверил, на 4.2.beta2 всё как у тебя.
При первом вхождении курсора мыши в область окна (popup) не генерируется событие 1010, которое генерируется только со второй попытки - видимо, это mouse_entered.
Это, очевидно, баг движка, но в рамках проекта, возможно, можно сделать костыль с событием 1002? Оно приходит одновременно и только с 1010, но почему-то дважды каждый раз.
Где можно прочитать названия всех событий по их индексам? Я не нашёл списка...
Скрипт на пикриле принадлежит PopupMenu.
>Кто на четверке, можете проверить?
Я проверил, на 4.2.beta2 всё как у тебя.
При первом вхождении курсора мыши в область окна (popup) не генерируется событие 1010, которое генерируется только со второй попытки - видимо, это mouse_entered.
Это, очевидно, баг движка, но в рамках проекта, возможно, можно сделать костыль с событием 1002? Оно приходит одновременно и только с 1010, но почему-то дважды каждый раз.
Где можно прочитать названия всех событий по их индексам? Я не нашёл списка...
Скрипт на пикриле принадлежит PopupMenu.
>>09704
В исходиках точно есть https://github.com/godotengine/godot/blob/c21c2706ad33c59295f6a3ac1e128db6fa7cce69/scene/main/node.h#L364
>>09671
Алсо, можете проверить, это происходит первый раз вообще, или первый раз с конкретным попапом. Можно, например, сделать два попапа и наводить на них. Или создавать каждый раз новый инстанс попапа. Я сам пока не могу, лапки.
В исходиках точно есть https://github.com/godotengine/godot/blob/c21c2706ad33c59295f6a3ac1e128db6fa7cce69/scene/main/node.h#L364
>>09671
Алсо, можете проверить, это происходит первый раз вообще, или первый раз с конкретным попапом. Можно, например, сделать два попапа и наводить на них. Или создавать каждый раз новый инстанс попапа. Я сам пока не могу, лапки.
>>09682
Как я понял ЦПУ партикли останутся, но сложное на них недоступно из-за производительности. По сути это gles2-only партикли для древних мобилок.
Как я понял ЦПУ партикли останутся, но сложное на них недоступно из-за производительности. По сути это gles2-only партикли для древних мобилок.
>>09717
глес2 не поддерживается с 4.0
глес2 не поддерживается с 4.0
>>09665
Если у тебя "живой" персонаж с вестибулярным аппаратом, то чарактер. Если бездушный робот, которого должно мотылять по физике, то ригид. Если в поведении чарактера не хватает отзывчивости и нюансов, то берёшь и сам это всё прописываешь.
Ригид сам по себе не создан для ручного управления как такового. Да, можно, но не нужно, его фишка - расслабиться и плыть по течению. Чарактер же как раз для того и есть, чтобы каждый пук ему прописать.
Если у тебя "живой" персонаж с вестибулярным аппаратом, то чарактер. Если бездушный робот, которого должно мотылять по физике, то ригид. Если в поведении чарактера не хватает отзывчивости и нюансов, то берёшь и сам это всё прописываешь.
Ригид сам по себе не создан для ручного управления как такового. Да, можно, но не нужно, его фишка - расслабиться и плыть по течению. Чарактер же как раз для того и есть, чтобы каждый пук ему прописать.
>>09335
Что ты тут делаешь? Ты же психовал, что готовый движок твоим толщеходам не подходит, и нужно писать свой велосипед с нуля, обязательно в 3D. Впрочем, я твой фанат. Когда ждать демку на Godot?
Это всё легко реализовать программно. Сложнее сделать достаточное количество графики для игры. Алсо, сомневаюсь, что эта "главная фишка" принесёт фан игроку. Как минимум эта вывернутая гравитация должна как-то влиять на геймплей.
Если сфера достаточно большая (несколько километров в диаметре), то ты вряд ли разглядишь что-то кроме тумана на другой стороне (пар в воздухе рассеивает лучи, в играх такое нужно вручную делать). Непонятно, как это рендерить в таком масштабе - настолько удалённые объекты в играх обычно изображаются плоской текстурой/скайбоксом. Если же сфера маленькая, то будет... фигня какая-то, будто в большом помещении вращается прожектор, что в этом такого "неописуемого"?
>>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.
>>09335
Что ты тут делаешь? Ты же психовал, что готовый движок твоим толщеходам не подходит, и нужно писать свой велосипед с нуля, обязательно в 3D. Впрочем, я твой фанат. Когда ждать демку на Godot?
Это всё легко реализовать программно. Сложнее сделать достаточное количество графики для игры. Алсо, сомневаюсь, что эта "главная фишка" принесёт фан игроку. Как минимум эта вывернутая гравитация должна как-то влиять на геймплей.
Если сфера достаточно большая (несколько километров в диаметре), то ты вряд ли разглядишь что-то кроме тумана на другой стороне (пар в воздухе рассеивает лучи, в играх такое нужно вручную делать). Непонятно, как это рендерить в таком масштабе - настолько удалённые объекты в играх обычно изображаются плоской текстурой/скайбоксом. Если же сфера маленькая, то будет... фигня какая-то, будто в большом помещении вращается прожектор, что в этом такого "неописуемого"?
>>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.
>>09728
Я тебя не понимаю. У робота тоже должен быть "вестибулярный аппарат", а любое животное будет "мотыляться по физике", если расслабится или если воздействие внешних сил будет сильнее мышц. Весь вопрос в том, как совокупляться с движком физики.
Как это сделать без доступа к физическому движку? Делаешь что-то, а движок начинает колбасить и всё выглядит так, будто вот-вот разлетится на части. Очевидно, нужно как-то встраиваться в движок, но у CharacterBody3D нет обработчика _integrate_forces.
Фишка RigidBody3D - он находится в пространстве физического движка, а не отдельным костылём. Расслабиться или нет - зависит от _integrate_forces. Персонаж, очевидно, должен иногда расслабляться.
Да, но он же будет конфликтовать с физикой. Его единственное преимущество - он может с каким-то шансом остановиться перед препятствием, если движок не заглючит и не начнёт колбасить.
Ну, ладно, персонаж. А корабль? Я часто замечал, что в играх корабли (морские, воздушные, да даже космические) - кинематики без реальной физики. Почему не сделать через RigidBody3D? Из моего опыта, RigidBody3D сам по себе хорошо моделирует корабль, проблема только в том, чтобы двигаться по его поверхности игровым персонажем.
Знаю про костыль "сделать невидимую StaticBody3D копию и бегать по ней вместо реального RigidBody3D", но это тоже проблемный подход и не подходит для сложной физической песочницы.
Хм... Я думаю, что если сделать два объекта - CharacterBody3D и RigidBody3D, и копировать все параметры с одного на другой в зависимости от состояния персонажа? Когда надо - ходить, а когда надо - мотыляться. Это независимо от рэгдолла.
У меня в школе по физике тройки за присутствие на уроках были, зачем я вообще в геймдев лезу...
>Если у тебя "живой" персонаж с вестибулярным аппаратом, то чарактер. Если бездушный робот, которого должно мотылять по физике, то ригид.
Я тебя не понимаю. У робота тоже должен быть "вестибулярный аппарат", а любое животное будет "мотыляться по физике", если расслабится или если воздействие внешних сил будет сильнее мышц. Весь вопрос в том, как совокупляться с движком физики.
>Если в поведении чарактера не хватает отзывчивости и нюансов, то берёшь и сам это всё прописываешь.
Как это сделать без доступа к физическому движку? Делаешь что-то, а движок начинает колбасить и всё выглядит так, будто вот-вот разлетится на части. Очевидно, нужно как-то встраиваться в движок, но у CharacterBody3D нет обработчика _integrate_forces.
>Ригид сам по себе не создан для ручного управления как такового. Да, можно, но не нужно, его фишка - расслабиться и плыть по течению.
Фишка RigidBody3D - он находится в пространстве физического движка, а не отдельным костылём. Расслабиться или нет - зависит от _integrate_forces. Персонаж, очевидно, должен иногда расслабляться.
>Чарактер же как раз для того и есть, чтобы каждый пук ему прописать.
Да, но он же будет конфликтовать с физикой. Его единственное преимущество - он может с каким-то шансом остановиться перед препятствием, если движок не заглючит и не начнёт колбасить.
Ну, ладно, персонаж. А корабль? Я часто замечал, что в играх корабли (морские, воздушные, да даже космические) - кинематики без реальной физики. Почему не сделать через RigidBody3D? Из моего опыта, RigidBody3D сам по себе хорошо моделирует корабль, проблема только в том, чтобы двигаться по его поверхности игровым персонажем.
Знаю про костыль "сделать невидимую StaticBody3D копию и бегать по ней вместо реального RigidBody3D", но это тоже проблемный подход и не подходит для сложной физической песочницы.
Хм... Я думаю, что если сделать два объекта - CharacterBody3D и RigidBody3D, и копировать все параметры с одного на другой в зависимости от состояния персонажа? Когда надо - ходить, а когда надо - мотыляться. Это независимо от рэгдолла.
У меня в школе по физике тройки за присутствие на уроках были, зачем я вообще в геймдев лезу...
>>09728
Я тебя не понимаю. У робота тоже должен быть "вестибулярный аппарат", а любое животное будет "мотыляться по физике", если расслабится или если воздействие внешних сил будет сильнее мышц. Весь вопрос в том, как совокупляться с движком физики.
Как это сделать без доступа к физическому движку? Делаешь что-то, а движок начинает колбасить и всё выглядит так, будто вот-вот разлетится на части. Очевидно, нужно как-то встраиваться в движок, но у CharacterBody3D нет обработчика _integrate_forces.
Фишка RigidBody3D - он находится в пространстве физического движка, а не отдельным костылём. Расслабиться или нет - зависит от _integrate_forces. Персонаж, очевидно, должен иногда расслабляться.
Да, но он же будет конфликтовать с физикой. Его единственное преимущество - он может с каким-то шансом остановиться перед препятствием, если движок не заглючит и не начнёт колбасить.
Ну, ладно, персонаж. А корабль? Я часто замечал, что в играх корабли (морские, воздушные, да даже космические) - кинематики без реальной физики. Почему не сделать через RigidBody3D? Из моего опыта, RigidBody3D сам по себе хорошо моделирует корабль, проблема только в том, чтобы двигаться по его поверхности игровым персонажем.
Знаю про костыль "сделать невидимую StaticBody3D копию и бегать по ней вместо реального RigidBody3D", но это тоже проблемный подход и не подходит для сложной физической песочницы.
Хм... Я думаю, что если сделать два объекта - CharacterBody3D и RigidBody3D, и копировать все параметры с одного на другой в зависимости от состояния персонажа? Когда надо - ходить, а когда надо - мотыляться. Это независимо от рэгдолла.
У меня в школе по физике тройки за присутствие на уроках были, зачем я вообще в геймдев лезу...
>Если у тебя "живой" персонаж с вестибулярным аппаратом, то чарактер. Если бездушный робот, которого должно мотылять по физике, то ригид.
Я тебя не понимаю. У робота тоже должен быть "вестибулярный аппарат", а любое животное будет "мотыляться по физике", если расслабится или если воздействие внешних сил будет сильнее мышц. Весь вопрос в том, как совокупляться с движком физики.
>Если в поведении чарактера не хватает отзывчивости и нюансов, то берёшь и сам это всё прописываешь.
Как это сделать без доступа к физическому движку? Делаешь что-то, а движок начинает колбасить и всё выглядит так, будто вот-вот разлетится на части. Очевидно, нужно как-то встраиваться в движок, но у CharacterBody3D нет обработчика _integrate_forces.
>Ригид сам по себе не создан для ручного управления как такового. Да, можно, но не нужно, его фишка - расслабиться и плыть по течению.
Фишка RigidBody3D - он находится в пространстве физического движка, а не отдельным костылём. Расслабиться или нет - зависит от _integrate_forces. Персонаж, очевидно, должен иногда расслабляться.
>Чарактер же как раз для того и есть, чтобы каждый пук ему прописать.
Да, но он же будет конфликтовать с физикой. Его единственное преимущество - он может с каким-то шансом остановиться перед препятствием, если движок не заглючит и не начнёт колбасить.
Ну, ладно, персонаж. А корабль? Я часто замечал, что в играх корабли (морские, воздушные, да даже космические) - кинематики без реальной физики. Почему не сделать через RigidBody3D? Из моего опыта, RigidBody3D сам по себе хорошо моделирует корабль, проблема только в том, чтобы двигаться по его поверхности игровым персонажем.
Знаю про костыль "сделать невидимую StaticBody3D копию и бегать по ней вместо реального RigidBody3D", но это тоже проблемный подход и не подходит для сложной физической песочницы.
Хм... Я думаю, что если сделать два объекта - CharacterBody3D и RigidBody3D, и копировать все параметры с одного на другой в зависимости от состояния персонажа? Когда надо - ходить, а когда надо - мотыляться. Это независимо от рэгдолла.
У меня в школе по физике тройки за присутствие на уроках были, зачем я вообще в геймдев лезу...
>>09728
Вот смотри, >>09743
Представь себя на морском корабле. Волны в море раскачивают корабль, корабль качается из стороны в сторону. Ты стоишь на палубе и тебя то поднимает, то опускает, но ты держишься на ногах, если качка не будет слишком сильной и если тебя не собьёт с ног катящаяся по палубе бочка. Как это сделать?
CharacterBody3D остановится, если на его пути будет RigidBody3D, но RigidBody3D не может сам по себе вытолкнуть со своего пути CharacterBody3D.
RigidBody3D может лежать на другом RigidBody3D, реалистично оказывая сопротивление согласно собственной массе, но если ты будешь двигать его посредством apply_force(), он будет "лететь" по палубе, толкая корабль как ракетный двигатель.
Если сделать скрытую StaticBody3D копию корабля, то это должна быть копия со всеми предметами на корабле, т.е. если по палубе катается бочка - где она должна на самом деле кататься? На StaticBody3D она не будет реагировать на наклон палубы, а если её там не будет, то она не сможет сбить с ног игрока.
Неужели я слишком многого хочу? Вроде банальная фича, а не какая-нибудь 4D/5D реальность...
>Если у тебя "живой" персонаж с вестибулярным аппаратом, то чарактер. Если бездушный робот, которого должно мотылять по физике, то ригид.
Вот смотри, >>09743
>RigidBody3D сам по себе хорошо моделирует корабль, проблема только в том, чтобы двигаться по его поверхности игровым персонажем.
Представь себя на морском корабле. Волны в море раскачивают корабль, корабль качается из стороны в сторону. Ты стоишь на палубе и тебя то поднимает, то опускает, но ты держишься на ногах, если качка не будет слишком сильной и если тебя не собьёт с ног катящаяся по палубе бочка. Как это сделать?
CharacterBody3D остановится, если на его пути будет RigidBody3D, но RigidBody3D не может сам по себе вытолкнуть со своего пути CharacterBody3D.
RigidBody3D может лежать на другом RigidBody3D, реалистично оказывая сопротивление согласно собственной массе, но если ты будешь двигать его посредством apply_force(), он будет "лететь" по палубе, толкая корабль как ракетный двигатель.
Если сделать скрытую StaticBody3D копию корабля, то это должна быть копия со всеми предметами на корабле, т.е. если по палубе катается бочка - где она должна на самом деле кататься? На StaticBody3D она не будет реагировать на наклон палубы, а если её там не будет, то она не сможет сбить с ног игрока.
Неужели я слишком многого хочу? Вроде банальная фича, а не какая-нибудь 4D/5D реальность...
>>09750
Просто регистрируешь столкновения и кодом двигаешь персонажа.
По идее так и должно быть, когда человек ходит по земле, он тоже ее двигает, весь вопрос тут в соотношении масс...
> RigidBody3D не может сам по себе вытолкнуть со своего пути CharacterBody3D.
Просто регистрируешь столкновения и кодом двигаешь персонажа.
> двигать его посредством apply_force(), он будет "лететь" по палубе, толкая корабль как ракетный двигатель.
По идее так и должно быть, когда человек ходит по земле, он тоже ее двигает, весь вопрос тут в соотношении масс...
>>09743
Перефразирую. Если тебе надо всё по физике и довериться физ.движку, то ригид; если хочешь максимум контроля, то чарактер. Что тут непонятного-то?
Но зачем? Но нахуя? У тебя в игре 100500 кораблей, они сталкиваются и взаимодействуют между собой? Гораздо проще поставить ему бесконечную инерцию и не ебать мозг с тем, что он там что-то не двигает: масса корабля несравнимо больше с любым объектом, который можно было бы поместить на палубу. А качку вообще анимировать, а не просчитывать физикой.
>Я тебя не понимаю.
Перефразирую. Если тебе надо всё по физике и довериться физ.движку, то ригид; если хочешь максимум контроля, то чарактер. Что тут непонятного-то?
>корабли - кинематики без реальной физики. Почему не сделать через RigidBody3D?
Но зачем? Но нахуя? У тебя в игре 100500 кораблей, они сталкиваются и взаимодействуют между собой? Гораздо проще поставить ему бесконечную инерцию и не ебать мозг с тем, что он там что-то не двигает: масса корабля несравнимо больше с любым объектом, который можно было бы поместить на палубу. А качку вообще анимировать, а не просчитывать физикой.
И вообще. Игровая физика не умеет учитывать третий закон Ньютона в ситуациях, когда сам Бог (т.е. программист) толкает предметы. Потому что apply_force() это, по факту, нарушение этого самого третьего закона. И движок не обязан иметь инструкций на этот счёт.
>>09753
RigidBody3D успевает столкнуться с CharacterBody3D раньше, чем срабатывает твой код сдвига. Движок автоматически выталкивает все RigidBody3D из препятствий, а на CharacterBody3D это не влияет.
Не, тут проблема в другом.
Когда ты идёшь, ты отталкиваешься от опоры под ногами. Если эта опора достаточно лёгкая и гладкая, она может выскользнуть назад. Теперь представь себе опору в форме буквы L:
||
||<-X__
Ты идёшь налево и упираешься в стену, но ты не можешь сдвинуть стену, потому что она соединена с полом, а отталкиваешься ты от пола. Вот если бы вместо стены был шкаф, ты мог бы его сдвинуть, ведь шкаф не связан с полом (кроме силы трения).
На игровом физическом движке без дополнительных проверок ты будешь двигать стену ВМЕСТЕ с полом, если твой персонаж - RigidBody3D с apply_force(). Это большая проблема в игре, где вся суть геймплея в перемещении на корабле - ведь игрок может просто бежать в стену, игнорируя все остальные механики.
>Просто регистрируешь столкновения и кодом двигаешь персонажа.
RigidBody3D успевает столкнуться с CharacterBody3D раньше, чем срабатывает твой код сдвига. Движок автоматически выталкивает все RigidBody3D из препятствий, а на CharacterBody3D это не влияет.
>По идее так и должно быть, когда человек ходит по земле, он тоже ее двигает, весь вопрос тут в соотношении масс...
Не, тут проблема в другом.
Когда ты идёшь, ты отталкиваешься от опоры под ногами. Если эта опора достаточно лёгкая и гладкая, она может выскользнуть назад. Теперь представь себе опору в форме буквы L:
||
||<-X__
Ты идёшь налево и упираешься в стену, но ты не можешь сдвинуть стену, потому что она соединена с полом, а отталкиваешься ты от пола. Вот если бы вместо стены был шкаф, ты мог бы его сдвинуть, ведь шкаф не связан с полом (кроме силы трения).
На игровом физическом движке без дополнительных проверок ты будешь двигать стену ВМЕСТЕ с полом, если твой персонаж - RigidBody3D с apply_force(). Это большая проблема в игре, где вся суть геймплея в перемещении на корабле - ведь игрок может просто бежать в стену, игнорируя все остальные механики.
>>09756
Либо обвесь Area3D чтобы срабатывало чуть раньше, либо смотреть в кишки физ движка и оттуда слать сигнал.
Движок не позволяет выставить заведомо большую массу?
>RigidBody3D успевает столкнуться с CharacterBody3D раньше, чем срабатывает твой код сдвига
Либо обвесь Area3D чтобы срабатывало чуть раньше, либо смотреть в кишки физ движка и оттуда слать сигнал.
>ты будешь двигать стену ВМЕСТЕ с полом
Движок не позволяет выставить заведомо большую массу?
>>09754
Затем, чтобы модель реалистично реагировала. Ой, слишком долго объяснять... Попробуй НАКЛОНИТЬ CharacterBody3D, если что-то ударилось в его УГОЛ - насколько я понимаю, там сложная формула, и ты предлагаешь это вручную писать? А в физическом движке все эти формулы уже есть на C++.
Ну, не корабль, а плот. Или обломок корабля. Какая разница, вот столкнулся ты и у тебя не корабль, а 25 обломков корабля, и все они отдельные RigidBody3D. Просчитывать на CharacterBody3D задолбаешься.
Вот сам и делай игру с захардкоженной качкой. Это неинтересно и делать такую игру я не хочу.
Я хотел сделать игру в основном ради такой фичи, но что-то не получается настроить как хочется.
>Но зачем?
Затем, чтобы модель реалистично реагировала. Ой, слишком долго объяснять... Попробуй НАКЛОНИТЬ CharacterBody3D, если что-то ударилось в его УГОЛ - насколько я понимаю, там сложная формула, и ты предлагаешь это вручную писать? А в физическом движке все эти формулы уже есть на C++.
>масса корабля несравнимо больше с любым объектом, который можно было бы поместить на палубу
Ну, не корабль, а плот. Или обломок корабля. Какая разница, вот столкнулся ты и у тебя не корабль, а 25 обломков корабля, и все они отдельные RigidBody3D. Просчитывать на CharacterBody3D задолбаешься.
>качку анимировать, а не просчитывать физикой
Вот сам и делай игру с захардкоженной качкой. Это неинтересно и делать такую игру я не хочу.
Я хотел сделать игру в основном ради такой фичи, но что-то не получается настроить как хочется.
>>09708
Проверил: скопипастил первый попап и забиндил на другую кнопку мыши. Этот баг проявляется индивидуально для каждого попапа (окна).
Ясно, спасибо.
Как я понимаю,
Практически идентичны в данном случае, но второй приходит дважды, а первый вообще не приходит в первый раз. Думаю, можно пока юзать WM?
А зачем тебе это событие в попапе? Интересно.
>Алсо, можете проверить, это происходит первый раз вообще, или первый раз с конкретным попапом. Можно, например, сделать два попапа и наводить на них.
Проверил: скопипастил первый попап и забиндил на другую кнопку мыши. Этот баг проявляется индивидуально для каждого попапа (окна).
>В исходиках точно есть
Ясно, спасибо.
Как я понимаю,
>NOTIFICATION_VP_MOUSE_ENTER
>NOTIFICATION_WM_MOUSE_ENTER
Практически идентичны в данном случае, но второй приходит дважды, а первый вообще не приходит в первый раз. Думаю, можно пока юзать WM?
А зачем тебе это событие в попапе? Интересно.
>>09756
Вот что я вспомнил
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
> 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
>>09760
Тогда у тебя по нему бочки не катаются, слишком мелкий.
Ну то есть, либо у тебя здоровенная громадина, где можно по палубе погулять и такой ПОДНЯТЬ ГРОТ-БРАМСЕЛЬ!!11 Либо мелкое корыто, типа Моана. В первом случае
означает либо пробоину, либо похеру. Во втором да, надо уже по физике всё делать, но там и пространства для перемещения по палубе сильно меньше.
Но если ты задумал вообще разрушаемость, то тут вообще хз. Тут уже придётся тебе самому изобретать реализацию.
Тащемта да, влом стирать написанное, но я подумал тут, что, раз уж ты хочешь что-то эдакое, чего никто не делал, то и реализовывать тебе придётся эдак, как никто не делал. Но вообще, обычно ригиды в любых игровых движках ведут себя по физике очень условно и с большими допущениями. Так что для продвинутой физики им в любом случае надо эту продвинутую физику писать. Такие дела.
>Ну, не корабль, а плот
Тогда у тебя по нему бочки не катаются, слишком мелкий.
Ну то есть, либо у тебя здоровенная громадина, где можно по палубе погулять и такой ПОДНЯТЬ ГРОТ-БРАМСЕЛЬ!!11 Либо мелкое корыто, типа Моана. В первом случае
>что-то ударилось в его УГОЛ
означает либо пробоину, либо похеру. Во втором да, надо уже по физике всё делать, но там и пространства для перемещения по палубе сильно меньше.
Но если ты задумал вообще разрушаемость, то тут вообще хз. Тут уже придётся тебе самому изобретать реализацию.
Тащемта да, влом стирать написанное, но я подумал тут, что, раз уж ты хочешь что-то эдакое, чего никто не делал, то и реализовывать тебе придётся эдак, как никто не делал. Но вообще, обычно ригиды в любых игровых движках ведут себя по физике очень условно и с большими допущениями. Так что для продвинутой физики им в любом случае надо эту продвинутую физику писать. Такие дела.
страдаю херней осваивая годот, flecs.net и генерацию кода.
Сап. Меня беспокоит вопрос. Допустим у меня есть два нпс на сцене, два объекта внутренним инвентарем, и два предмета. По клику на каждого из них открывается свое окошко, со своими уникальными вариантами взаимодействия. У неписей это, к примеру, "поговорить", "ударить", "обокрасть" и тд. У объектов это "открыть", "сломать" и тд. У предметов тоже что-то своё, не буду расписывать, перейду ближе к сути вопроса.
Как по итогу такую систему удобнее всего реализовать? Сделать у каждого из них своё отдельное окошко, на все случаи взаимодействия и показывать в зависимости от ситуации? Ведь даже с одним и тем же нпс и предметом могут сейчас быть такие варианты взаимодействия, а позже станут другие. Или сделать одно окошко, но чтобы его элементы подключались и отключались как то с помощью скриптов и сигналов? Допустим, если взаимодействуешь с нпс, в окошко заносятся данные для вариантов из его скрипта, ну или что-то такое. Вобщем, надеюсь, понятно объяснил.
Как по итогу такую систему удобнее всего реализовать? Сделать у каждого из них своё отдельное окошко, на все случаи взаимодействия и показывать в зависимости от ситуации? Ведь даже с одним и тем же нпс и предметом могут сейчас быть такие варианты взаимодействия, а позже станут другие. Или сделать одно окошко, но чтобы его элементы подключались и отключались как то с помощью скриптов и сигналов? Допустим, если взаимодействуешь с нпс, в окошко заносятся данные для вариантов из его скрипта, ну или что-то такое. Вобщем, надеюсь, понятно объяснил.
>>09868
Удобнее делать как умеешь и потом подгонять под свои нужды. В любом случае ты динамически заполняешь окошко вариантами взаимодействия. Главное чтобы при создании новой сущности не пришлось дублировать код, а прост новые взаимодействия сделать.
Наверно так.
Удобнее делать как умеешь и потом подгонять под свои нужды. В любом случае ты динамически заполняешь окошко вариантами взаимодействия. Главное чтобы при создании новой сущности не пришлось дублировать код, а прост новые взаимодействия сделать.
Наверно так.
>>09868
Я бы сделал каждому объекту отдельную сцену с элементами управления, типа "var scene: PackedScene",
а при взаимодействии отдавал её в интерфейс и там инстансил. Но только при условии, что там прям уникальные способы взаимодействия, для которых нужны уникальные элементы управления. А если просто разные надписи на кнопках - отдавал бы интерфейсу массив с подписями; сколько элементов в массиве, столько кнопок и показывать; обратный сигнал отдаёт номер нажатой кнопки.
Я бы сделал каждому объекту отдельную сцену с элементами управления, типа "var scene: PackedScene",
а при взаимодействии отдавал её в интерфейс и там инстансил. Но только при условии, что там прям уникальные способы взаимодействия, для которых нужны уникальные элементы управления. А если просто разные надписи на кнопках - отдавал бы интерфейсу массив с подписями; сколько элементов в массиве, столько кнопок и показывать; обратный сигнал отдаёт номер нажатой кнопки.
>>09903
Роялти завезут за установку каждой копии.
Роялти завезут за установку каждой копии.
>>09912
Значит не слушай этого, спокойно не торопясь изучай движок.
>>09903
Ничего. Это местный мем, основанный на пьесе какого-то там драматурга: "В ожидании Годота". Годаны оправдывают свою прокрастинацию тем, что вот типа, версия N+1 еще не вышла, вот выйдет в ноябре, тогда-то наконец я и начну делать свою игру мечты.
Ты уже догадываешься, что те же самые годаны скажут в ноябре. Они начнут ждать версию N+2
> я только месяц как в движок вкатился
Значит не слушай этого, спокойно не торопясь изучай движок.
>>09903
> А что там прям такого крутого и важного?
Ничего. Это местный мем, основанный на пьесе какого-то там драматурга: "В ожидании Годота". Годаны оправдывают свою прокрастинацию тем, что вот типа, версия N+1 еще не вышла, вот выйдет в ноябре, тогда-то наконец я и начну делать свою игру мечты.
Ты уже догадываешься, что те же самые годаны скажут в ноябре. Они начнут ждать версию N+2
>>09939
4.2 было обоснованным предположением, потому что 3.2 уже был пригоден доя продакшна по сравнению с 3.0, а на 3.4+ уже можно полноценные игры делать
Но тут решили ускорить как релиз 4.0 под GDC с резанием и откатом фич, так и сейчас цифры быстро накручивают.
Иными слова 4.2 имело бы смысл ждать, если бы релиз 4.0 был полноценным, а не альфой. А так, получается, надо ждать 4.2+2. Не в смысле ждать ради ждать, а в смысле объективного готово/неготово
4.2 было обоснованным предположением, потому что 3.2 уже был пригоден доя продакшна по сравнению с 3.0, а на 3.4+ уже можно полноценные игры делать
Но тут решили ускорить как релиз 4.0 под GDC с резанием и откатом фич, так и сейчас цифры быстро накручивают.
Иными слова 4.2 имело бы смысл ждать, если бы релиз 4.0 был полноценным, а не альфой. А так, получается, надо ждать 4.2+2. Не в смысле ждать ради ждать, а в смысле объективного готово/неготово
Обнаруживаю что менять слои/маски коллизий через animationplayer - боль. Меняешь в свойствах объекта маску, потом приходится лезть в каждую анимацию, где ты использовал маску, и обновлять. Если вспомнишь. А если не вспомнишь - будешь тупить, думая почему ты выключил коллизию, а она все еще коллизирует. А потому что в анимации выключить забыл.
Лучше уж через код.
Лучше уж через код.
>>09944
Делаю на LTS 3. На моей комбинации некроноута/линукса/видеодрайвера четверка зависает примерно через 2 минуты работы.
Делаю на LTS 3. На моей комбинации некроноута/линукса/видеодрайвера четверка зависает примерно через 2 минуты работы.
>>09972
Меня все устраивает. Я делаю низкотребовательные игры которые потом идут даже у бомжей.
Меня все устраивает. Я делаю низкотребовательные игры которые потом идут даже у бомжей.
>>09972
Вполне заебатые игры на некрожелезе делают, и вполне заебатые игры на некрожелезе работают. Тем более годот это не юнити, который включается по полчаса.
Вполне заебатые игры на некрожелезе делают, и вполне заебатые игры на некрожелезе работают. Тем более годот это не юнити, который включается по полчаса.
620 Кб, 700x467>>09976
Линукс быстро работает без ссд, ну и заодно тестируем для тех у кого его нет.
Тем хуже для нее.
Линукс быстро работает без ссд, ну и заодно тестируем для тех у кого его нет.
>последняя версия движка вылетает через две минуты
Тем хуже для нее.
883 Кб, 700x933Карочи, вот вам мой пайплайн:
1. Делаеш прототип на гдскрипте.
2. Переписываеш критические участки на РАСТЕ.
Как я выяснил за прошедшую неделю, ржавый критически хорош! Системный язык, с абстракциями нулевой стоимости, внешне гдскрипт похож на него (я даже начинаю думать, что кое что Хуан потянул из ржавого). На гитхабе есть готовый полнофункциональный гд-экстеншон, который джаст воpкс.
Дискасс.
1. Делаеш прототип на гдскрипте.
2. Переписываеш критические участки на РАСТЕ.
Как я выяснил за прошедшую неделю, ржавый критически хорош! Системный язык, с абстракциями нулевой стоимости, внешне гдскрипт похож на него (я даже начинаю думать, что кое что Хуан потянул из ржавого). На гитхабе есть готовый полнофункциональный гд-экстеншон, который джаст воpкс.
Дискасс.
>>09984
Меня пока устраивает с++, потенциально с перекатом в cpp2 или zig.
Меня пока устраивает с++, потенциально с перекатом в cpp2 или zig.
>>09986
Это правда. Но у дедов было определенное преимущество, в виде низкой конкуренции и неосвоенных ниш и жанров, ну и то, что калькуляторы были около-АА железом.
Это правда. Но у дедов было определенное преимущество, в виде низкой конкуренции и неосвоенных ниш и жанров, ну и то, что калькуляторы были около-АА железом.
>>09987
Отцы тоже делали. И ты делой.
Отцы тоже делали. И ты делой.
21 Кб, 490x325Оказывается можно такой финт провернуть. Удобно. Расширяем ноду через extend AnimationPlayer, называем по своему через class_name, надстраиваем над ней как угодно, и она считается не классом-сценой, а полноценной новой нодой. Охуенчик.
>>10016
Подводный в том, что на ноду ты можешь вешать доп скрипт, а здесь уже только этот может быть. И длинная подпись.
Полноценную ноду можно через свой аддон делать, но там и бойлерплейта побольше написать надо, и для отладки перезапускать аддон надо (но для этого есть аддон plugin refresher)
Подводный в том, что на ноду ты можешь вешать доп скрипт, а здесь уже только этот может быть. И длинная подпись.
Полноценную ноду можно через свой аддон делать, но там и бойлерплейта побольше написать надо, и для отладки перезапускать аддон надо (но для этого есть аддон plugin refresher)
>>10026
Здесь точно так же можно прикрепить скрипт ("расширить скрипт"), главное в нём написать extends my_super_mega_class.
>а здесь уже только этот может быть
Здесь точно так же можно прикрепить скрипт ("расширить скрипт"), главное в нём написать extends my_super_mega_class.
>>10027
Я подумал, и пришел к выводу, что все дело в удобстве воркфлоу
Если ты удаляешь с обычной ноды скрипт, то нода все равно сохраняет поведение по умолчанию. В случае с твоей, слетает совсем и надо выставлять твой базовый скрипт.
Если ты добавляешь к обычной ноде скрипт, то там по умолчанию уже все отнаследовано от той, что выбрана в инспекторе. В случае с твоей, надо выбирать из списка классов в окошке создания скрипта.
Я подумал, и пришел к выводу, что все дело в удобстве воркфлоу
Если ты удаляешь с обычной ноды скрипт, то нода все равно сохраняет поведение по умолчанию. В случае с твоей, слетает совсем и надо выставлять твой базовый скрипт.
Если ты добавляешь к обычной ноде скрипт, то там по умолчанию уже все отнаследовано от той, что выбрана в инспекторе. В случае с твоей, надо выбирать из списка классов в окошке создания скрипта.
>>10029
Еще индикация. В случае обычной ноды, листочек есть/листочка нет/листочек серенький. В твоем случае, они всегда будут, и надо читать какой же именно скрипт в названии.
Еще индикация. В случае обычной ноды, листочек есть/листочка нет/листочек серенький. В твоем случае, они всегда будут, и надо читать какой же именно скрипт в названии.
280 Кб, 500x500> Instance parameters not implemented for 2D shaders.
ну блин
3 Кб, 422x245https://github.com/gdquest-demos/godot-design-patterns/blob/main/godot/StateMachine/State.gd
Зачем так делать? Там нет ни _process, ни _input, ни других коллбеков движка. Зачем тогда Node?
Пикрил меня вообще выводит из себя - будто бы яждизайнер будет каждый день эти Idle/Run/Air мышкой по дереву таскать, иначе зачем оно надо?
На вопрос о противоречии практикам Godot он написал, что эти объекты специально сделаны с высоким зацеплением - мол, они не будут нужны никому, кроме Player. Но тогда зачем вообще ноды?
Кроме того. Вот хочу сделать состояние, в котором требуется _integrate_forces с аргументом. Конечный автомат из примера по ссылке принципиально не позволяет такое провернуть...
Короче, я придумал отправлять сигналы из главной ноды, на которую цепляется нода-конечный автомат, у которой есть массив Resource-состояний, которые проверяют наличие желаемых сигналов и цепляют на них свои собственные обработчики. Нормально?
Примерно такой код:
Так можно писать какие угодно состояния на какие угодно события, не меняя скрипт state_machine.gd.
>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.
>>10083
А зачем менять его? Он же просто обрабатывает переключения между состояниями.
>Так можно писать какие угодно состояния на какие угодно события, не меняя скрипт state_machine.gd.
А зачем менять его? Он же просто обрабатывает переключения между состояниями.
>>10088
Ты код в том примере по ссылке смотрел?
https://github.com/gdquest-demos/godot-design-patterns/blob/main/godot/StateMachine/StateMachine.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)
Честно говоря, навскидку в первый раз я тоже что-то подобное планировал, но потом вспомнил, что ряд коллбеков присутствует только у определённых нод. Поэтому конечный автомат из этого примера совсем не универсальный, к сожалению.
>>10089
Ну ок. Правда так и не понимаю почему ты не можешь добавить _input или _process прописав так же как:
А с _integrate_forces не работал, так что хз.
Ну ок. Правда так и не понимаю почему ты не можешь добавить _input или _process прописав так же как:
> func _unhandled_input(event: InputEvent) -> void:
> state.handle_input(event)
А с _integrate_forces не работал, так что хз.
>>10091
Потому что он есть только у RigidBody3D/RigidBody2D.
Алсо... С таким подходом тебе придётся добавлять новые затычки во все уже существующие классы состояний. Не очень-то гибко, не так ли?
>почему ты не можешь добавить
>_integrate_forces
Потому что он есть только у RigidBody3D/RigidBody2D.
Алсо... С таким подходом тебе придётся добавлять новые затычки во все уже существующие классы состояний. Не очень-то гибко, не так ли?
>>10099
Зачем? Затычка(с pass) идет в класс state от которого наследуются остальные состояния. Если в состоянии используется функция - прописываю реализацию в нужном классе. Если нет - автоматом юзается родительская затычка
>Алсо... С таким подходом тебе придётся добавлять новые затычки во все уже существующие классы состояний. Не очень-то гибко, не так ли?
Зачем? Затычка(с pass) идет в класс state от которого наследуются остальные состояния. Если в состоянии используется функция - прописываю реализацию в нужном классе. Если нет - автоматом юзается родительская затычка
Как можно реализовать _on_mouse_entered/exited сигналы только с меша объекта, а не коллишн шейпа? У меня при наведении на перса должен курсор меняться. Но из за того, что коллишн в виде капсулы и несколько больше меша, то курсор меняется до наведения непосредственно на персонажа. Погуглить конкретную проблему не удалось. Помогите!
>>09822
Ты слишком зациклился на морских кораблях. Они были только как пример качающейся платформы; в сущности, это декорация, а ты начал обсуждать её, игнорируя реальную проблему (движения игрока).
Я пытаюсь сделать песочницу, в которой игроку требуется строить транспорт, относящийся к дирижаблям, по-английски гуглить 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.
Песочницы с транспортом делятся на:
- унылое говно на деревянных кинематиках;
- прикольный кубач с физикой на ригидах;
- хардкорная симуляция ирл материалов.
Первое не хочу, третье не смогу, второе в самый раз.
>>09822
Ты слишком зациклился на морских кораблях. Они были только как пример качающейся платформы; в сущности, это декорация, а ты начал обсуждать её, игнорируя реальную проблему (движения игрока).
Я пытаюсь сделать песочницу, в которой игроку требуется строить транспорт, относящийся к дирижаблям, по-английски гуглить 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.
Песочницы с транспортом делятся на:
- унылое говно на деревянных кинематиках;
- прикольный кубач с физикой на ригидах;
- хардкорная симуляция ирл материалов.
Первое не хочу, третье не смогу, второе в самый раз.
>>10115
Сделай отдельную Area2D/Area3D и отключи ей всё лишнее, чтобы она не мешала игровым объектам.
>коллишн в виде капсулы и несколько больше меша, то курсор меняется до наведения непосредственно на персонажа.
Сделай отдельную Area2D/Area3D и отключи ей всё лишнее, чтобы она не мешала игровым объектам.
>>10117
Ареа3д требует колишн шейп как ребенка, а мне без него нужно, потому что он статичный.
Ареа3д требует колишн шейп как ребенка, а мне без него нужно, потому что он статичный.
>>10083
Я так делал, "изобрёл" такой подход независимо от Гдквеста. Пробовал стейты внутри скрипта, пробовал стейты-ресурсы в массиве. Стейты-ноды удобнее всего. 2д-ноды - вообще супер, в них ещё и графические эффекты впихнуть можно. Щас прихожу к тому, чтобы не опрашивать их стейт-машиной каждый кадр, а по необходимости добавлять в сами ноды _процесс (ну или _физикс_процесс). Стейт-машина просто выбирает самого достойного среди стейтов (каждый стейт сам подсчитывает, насколько он подходит для той или иной ситуации) и ставит ему галочку "активен". Ну и для реализации переходов вызывает функции exit_state(next_state) и enter_state(prev_state), чтобы стейт мог сам определять свои переходы.
И да, отдельная стейт-машина не нужна. Персонаж это и есть стейт-машина. Отдельно от персонажа она не имеет смысла; персонаж без стейт-машины тоже не нужен; внутри него прочий код - это разве что обработка хитпоинтов и управляющих команд.
Очень удобно и наглядно. Сразу видно, какой персонаж что умеет. А ещё можно собрать сцену базового перса и всех остальных наследовать от него. А ещё можно на ходу добавлять/убирать способности.
Я так делал, "изобрёл" такой подход независимо от Гдквеста. Пробовал стейты внутри скрипта, пробовал стейты-ресурсы в массиве. Стейты-ноды удобнее всего. 2д-ноды - вообще супер, в них ещё и графические эффекты впихнуть можно. Щас прихожу к тому, чтобы не опрашивать их стейт-машиной каждый кадр, а по необходимости добавлять в сами ноды _процесс (ну или _физикс_процесс). Стейт-машина просто выбирает самого достойного среди стейтов (каждый стейт сам подсчитывает, насколько он подходит для той или иной ситуации) и ставит ему галочку "активен". Ну и для реализации переходов вызывает функции exit_state(next_state) и enter_state(prev_state), чтобы стейт мог сам определять свои переходы.
И да, отдельная стейт-машина не нужна. Персонаж это и есть стейт-машина. Отдельно от персонажа она не имеет смысла; персонаж без стейт-машины тоже не нужен; внутри него прочий код - это разве что обработка хитпоинтов и управляющих команд.
>мышкой по дереву таскат
Очень удобно и наглядно. Сразу видно, какой персонаж что умеет. А ещё можно собрать сцену базового перса и всех остальных наследовать от него. А ещё можно на ходу добавлять/убирать способности.
>>10118
Ты можешь менять его параметры динамически или сделать несколько шейпов и переключать их. Да, это ударит по производительности, но что ты хотел?
Если ты хочешь пиксельную точность выбора, то придётся проверять цвет пикселя под курсором. К примеру, можешь рендерить персонажей сплошной заливкой одним цветом на невидимом Viewport, а затем проверять цвет пикселей, координаты которых совпадают с тем, что видит игрок... Опять-таки, это серьёзно ударит по производительности.
Спроси себя сам, нужна ли тебе избыточная точность выделения? Если юниты не наслаиваются друг на друга, то не всё ли равно, как их выделять? Как я понимаю, в стратегиях чаще рамочкой выделяют...
>колишн шейп
>он статичный
Ты можешь менять его параметры динамически или сделать несколько шейпов и переключать их. Да, это ударит по производительности, но что ты хотел?
Если ты хочешь пиксельную точность выбора, то придётся проверять цвет пикселя под курсором. К примеру, можешь рендерить персонажей сплошной заливкой одним цветом на невидимом Viewport, а затем проверять цвет пикселей, координаты которых совпадают с тем, что видит игрок... Опять-таки, это серьёзно ударит по производительности.
Спроси себя сам, нужна ли тебе избыточная точность выделения? Если юниты не наслаиваются друг на друга, то не всё ли равно, как их выделять? Как я понимаю, в стратегиях чаще рамочкой выделяют...
>>10118
>>10129
Ещё придумал: если у тебя 3D модель со скелетом, то возможно подвесить на каждую кость отдельный CollisionShape3D в одном Area3D или разные Area3D. Тогда они будут повторять силуэт персонажа с любыми анимациями автоматически.
>он статичный
>>10129
>можешь менять его параметры динамически или сделать несколько шейпов и переключать их
Ещё придумал: если у тебя 3D модель со скелетом, то возможно подвесить на каждую кость отдельный CollisionShape3D в одном Area3D или разные Area3D. Тогда они будут повторять силуэт персонажа с любыми анимациями автоматически.
>>10129
А если нужен рэгдолл на каждого перса? Я видел ещё физический скелет, он на каждую кость добавляет коллизию. Можно конечно добавить коллизию на основные кости, таким образом и выделение будет точнее, и коллизия в целом. И к тому же пули, летящие в персонажа смогут пролетать между ног, под руками, у головы, не задевая ее коллизию.
>>10130
Пока это описывал, ты уже отписался.
А если нужен рэгдолл на каждого перса? Я видел ещё физический скелет, он на каждую кость добавляет коллизию. Можно конечно добавить коллизию на основные кости, таким образом и выделение будет точнее, и коллизия в целом. И к тому же пули, летящие в персонажа смогут пролетать между ног, под руками, у головы, не задевая ее коллизию.
>>10130
Пока это описывал, ты уже отписался.
>>10120
Обсуждали же, это у тебя Utility AI.
Конечный автомат - абстрактная система, так что универсальный конечный автомат можно было бы использовать в разных частях игры в роли сложной ООП замены конструкции "match state:".
Всё то же самое можно через инспектор реализовать.
Единственное преимущество нод - это стандартные коллбеки движка, которых у ресурсов нет. Но их несложно пробросить, если очень нужно.
Алсо, зону инспектора можно кастомизировать в tool-скриптах, создавая свои кнопки и разделы...
>Стейт-машина просто выбирает самого достойного среди стейтов (каждый стейт сам подсчитывает, насколько он подходит для той или иной ситуации)
Обсуждали же, это у тебя Utility AI.
>Отдельно от персонажа она не имеет смысла
Конечный автомат - абстрактная система, так что универсальный конечный автомат можно было бы использовать в разных частях игры в роли сложной ООП замены конструкции "match state:".
>Очень удобно и наглядно. Сразу видно, какой персонаж что умеет. А ещё можно собрать сцену базового перса и всех остальных наследовать от него. А ещё можно на ходу добавлять/убирать способности.
Всё то же самое можно через инспектор реализовать.
Единственное преимущество нод - это стандартные коллбеки движка, которых у ресурсов нет. Но их несложно пробросить, если очень нужно.
Алсо, зону инспектора можно кастомизировать в tool-скриптах, создавая свои кнопки и разделы...
>>10132
В Godot 3.x с Bullet на 4-х ядерном ЦПУ 2007-го года мне удавалось иметь 1000+ CollisionShape в одном RigidBody. И ещё удавалось что-то около 12000, если размещать их в разных телах. Дальше начинались просадки сильно ниже 75 ФПС. Точно не помню... Может, это даже не из-за физики, а из-за дроуколов, поскольку больше 10к-12к дроуколов всё тормозит.
Ну, набросай стресс-тест (сколько объектов нужно создать, чтобы игре поплохело), убедишься сам.
В Godot 3.x с Bullet на 4-х ядерном ЦПУ 2007-го года мне удавалось иметь 1000+ CollisionShape в одном RigidBody. И ещё удавалось что-то около 12000, если размещать их в разных телах. Дальше начинались просадки сильно ниже 75 ФПС. Точно не помню... Может, это даже не из-за физики, а из-за дроуколов, поскольку больше 10к-12к дроуколов всё тормозит.
Ну, набросай стресс-тест (сколько объектов нужно создать, чтобы игре поплохело), убедишься сам.
>>10130
Вероятно глупый вопрос, но как к отдельной кости добавить CollisionShape3D? У меня есть Skeleton3D, в инспекторе показаны кости, а дальше?
Вероятно глупый вопрос, но как к отдельной кости добавить CollisionShape3D? У меня есть Skeleton3D, в инспекторе показаны кости, а дальше?
>>10140
Напрямую никак. Можно через BoneAttachment попробовать, еще есьь PhysicalBones которые для рэгдоллов используют
Это в любом случае будет парадлельная скелету система нод
Напрямую никак. Можно через BoneAttachment попробовать, еще есьь PhysicalBones которые для рэгдоллов используют
Это в любом случае будет парадлельная скелету система нод
>>10145
Получается, что по иерархии CollisionShape3D стоит ниже кости, которая стоит ниже Skeleton3D, который стоит ниже CharacterBody3D и эти шейпы не считаются телом за собственные что-ли. То есть не влияют они на столкновения от слова совсем. :\
Получается, что по иерархии CollisionShape3D стоит ниже кости, которая стоит ниже Skeleton3D, который стоит ниже CharacterBody3D и эти шейпы не считаются телом за собственные что-ли. То есть не влияют они на столкновения от слова совсем. :\
>>10145
Кстати, ты не знаешь, что с IK?
https://docs.godotengine.org/en/stable/classes/class_skeleton3d.html
https://docs.godotengine.org/en/stable/classes/class_skeletonik3d.html
Skeletonik? Скелетоник, лол!
Кстати, ты не знаешь, что с 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? Скелетоник, лол!
>>10151
Оуп... Прошу прощения, это моя дурная голова забыла включить animate_physical_bones.
Оуп... Прошу прощения, это моя дурная голова забыла включить animate_physical_bones.
>>09857
Что ты имеешь в виду?
1. Чтобы объект сталкивался с чем-то, а это что-то с ним не сталкивалось?
2. Чтобы можно было пройти в одну сторону, но нельзя было в другую?
Опиши задачу подробнее, если хочешь ответ.
>В 3д с кинематик боди можно как-нибудь одностороннюю коллизию провернуть?
Что ты имеешь в виду?
1. Чтобы объект сталкивался с чем-то, а это что-то с ним не сталкивалось?
2. Чтобы можно было пройти в одну сторону, но нельзя было в другую?
Опиши задачу подробнее, если хочешь ответ.
Час от часу не легче. Оказывается каждый PhysicalBone3D наслдуется от CollisionObject3D, потому требует Shape. Получается с каждой физ. кости отдельно нужно снимать сигналы mouse_entered/exited, что ни разу не есть хорошо...
>>09868
Рекомендую следующий подход к разработке:
1. Сначала быстро набрасываешь фичу совершенно любым способом, лишь бы быстрее был результат.
2. Тестируешь эту фичу с точки зрения геймплея, экспериментируя с параметрами. Баги, тормоза и украшательства ни в коем случае не трогаешь.
3. Только когда отполируешь фичу геймплейно, оцениваешь работу с точки зрения технической поддержки, производительности и т.д.
4. При необходимости пределываешь с нуля. Не беспокойся, теперь ты точно знаешь, что нужно реализовать и что оно будет работать правильно.
Переписывать уже готовое всегда проще, чем изобретать что-то с нуля, поэтому оптимизировать нужно в первую очередь скорость изобретательства.
Наглядный пример: когда требуется что-то быстро вывести на экран, ПРОСТО втыкаешь Control-ноду в любое удобное место сцены и всё. Главное потом не забыть убрать всё лишнее/переделать начисто.
>Как такую систему реализовать?
Рекомендую следующий подход к разработке:
1. Сначала быстро набрасываешь фичу совершенно любым способом, лишь бы быстрее был результат.
2. Тестируешь эту фичу с точки зрения геймплея, экспериментируя с параметрами. Баги, тормоза и украшательства ни в коем случае не трогаешь.
3. Только когда отполируешь фичу геймплейно, оцениваешь работу с точки зрения технической поддержки, производительности и т.д.
4. При необходимости пределываешь с нуля. Не беспокойся, теперь ты точно знаешь, что нужно реализовать и что оно будет работать правильно.
Переписывать уже готовое всегда проще, чем изобретать что-то с нуля, поэтому оптимизировать нужно в первую очередь скорость изобретательства.
Наглядный пример: когда требуется что-то быстро вывести на экран, ПРОСТО втыкаешь Control-ноду в любое удобное место сцены и всё. Главное потом не забыть убрать всё лишнее/переделать начисто.
>>10156
Это, да. Я придумал способ вида "с одной стороны добавляем area, при входе в нее добавляем исключение с кинематиком, позволяя через него проходить", но как-то коряво это все. Хотелось бы проще. Поставить галку "one way collision" и указать нормально, где коллизия работает.
>2. Чтобы можно было пройти в одну сторону, но нельзя было в другую?
Это, да. Я придумал способ вида "с одной стороны добавляем area, при входе в нее добавляем исключение с кинематиком, позволяя через него проходить", но как-то коряво это все. Хотелось бы проще. Поставить галку "one way collision" и указать нормально, где коллизия работает.
>>10159
Не нужно отдельно. Просто в окне подключения сигнала, в поле ввода имени функции-обработчика, копипастишь одно и то же название. Тогда все сигналы всех костей будут дёргать одну и ту же функцию. Тебе же не нужно эти кости различать - тебе достаточно знать, что сигнал пришёл от какой-то кости конкретного персонажа. В случае, если различать всё-таки нужно, можно нажать кнопку дополнительных параметров и добавить какой-нибудь аргумент, например, int с номером кости или даже StringName с текстовым названием (они внутри движка индексируются и работают как сравнение чисел, добавили в четвёрке из-за того, что многие вещи в движке требуют указания текстовых строк, что с обычными String слишком затратно из-за сравнения строк посимвольно; главное не забывать символ & перед константами: &"текст").
>отдельно нужно снимать сигналы
Не нужно отдельно. Просто в окне подключения сигнала, в поле ввода имени функции-обработчика, копипастишь одно и то же название. Тогда все сигналы всех костей будут дёргать одну и ту же функцию. Тебе же не нужно эти кости различать - тебе достаточно знать, что сигнал пришёл от какой-то кости конкретного персонажа. В случае, если различать всё-таки нужно, можно нажать кнопку дополнительных параметров и добавить какой-нибудь аргумент, например, int с номером кости или даже StringName с текстовым названием (они внутри движка индексируются и работают как сравнение чисел, добавили в четвёрке из-за того, что многие вещи в движке требуют указания текстовых строк, что с обычными String слишком затратно из-за сравнения строк посимвольно; главное не забывать символ & перед константами: &"текст").
>>10163
Точно! Спасибо.
Точно! Спасибо.
>>10159
А ты не перемудриваешь? Тебе точно надо к костям коллайдеры? Не просто так в играх делают капсулу, а все антмации отдельно.
А ты не перемудриваешь? Тебе точно надо к костям коллайдеры? Не просто так в играх делают капсулу, а все антмации отдельно.
>>10166
А ещё в играх делают регдолл и даже такую штуку, как правдоподобная симуляция мышц (GTA IV).
Но это касательно движений. Для определения попаданий в шутерах используют отдельные коллизии, повторяющие части тела персонажа.
Вообще, капсула - это просто самая простая коллизия, чтобы побыстрее начать двигать персонажа. Продвинутый контроллер персонажа может быть обвешан кучей коллизий под разные ситуации...
Короч, не мешай полёту фантазии анона. А то сейчас он сделает всё правильно и исчезнет с радаров.
>Не просто так в играх делают капсулу, а все антмации отдельно.
А ещё в играх делают регдолл и даже такую штуку, как правдоподобная симуляция мышц (GTA IV).
Но это касательно движений. Для определения попаданий в шутерах используют отдельные коллизии, повторяющие части тела персонажа.
Вообще, капсула - это просто самая простая коллизия, чтобы побыстрее начать двигать персонажа. Продвинутый контроллер персонажа может быть обвешан кучей коллизий под разные ситуации...
Короч, не мешай полёту фантазии анона. А то сейчас он сделает всё правильно и исчезнет с радаров.
>>10162
Вроде бы такого нет и не было. Была какая-то глючная коллизия типа "плоскость", но её то ли удалили, то ли переделали и она продолжает глючить, не знаю. Сама идея односторонней коллизии весьма специфична, особенно для 3D игр, вот для 2D что-то есть.
Я погуглил, в интернете предлагают ещё такое: при вхождении в Area3D проверять, с какой стороны входит игрок, и запрещать ему двигаться дальше, к примеру, придавать ему импульс в обратную сторону.
А для чего тебе это нужно? Вертикальная дверь или горизонтальная платформа? Интересно.
>Хотелось бы проще. Поставить галку "one way collision" и указать нормально, где коллизия работает.
Вроде бы такого нет и не было. Была какая-то глючная коллизия типа "плоскость", но её то ли удалили, то ли переделали и она продолжает глючить, не знаю. Сама идея односторонней коллизии весьма специфична, особенно для 3D игр, вот для 2D что-то есть.
>с одной стороны добавляем area, при входе в нее добавляем исключение с кинематиком, позволяя через него проходить
Я погуглил, в интернете предлагают ещё такое: при вхождении в Area3D проверять, с какой стороны входит игрок, и запрещать ему двигаться дальше, к примеру, придавать ему импульс в обратную сторону.
А для чего тебе это нужно? Вертикальная дверь или горизонтальная платформа? Интересно.
Ну вот такие данные получились из стресс теста со 118 characterBody3D у каждого из которых получилось 17 костей с коллизией
Кстати, в тему физики.
Вот velocity - это вектор скорости, он есть у RigidBody. А что на счёт ускорения? Ускорение - это изменение скорости за момент времени, так что вручную его можно измерить только двумя проверками velocity. Разве нет никакой встроенной переменной? Мне кажется это странным, т.к. знать ускорение важно в некоторых ситуациях, например, чтобы персонажи в автобусе падали, если автобус врежется в стену.
Главное что физический движок где-то внутри манипулирует ускорением объектов, разве нет?
НЕТ, мне не сложно сделать это:
Я просто не понимаю, почему нет отдельного поля.
Вот velocity - это вектор скорости, он есть у RigidBody. А что на счёт ускорения? Ускорение - это изменение скорости за момент времени, так что вручную его можно измерить только двумя проверками velocity. Разве нет никакой встроенной переменной? Мне кажется это странным, т.к. знать ускорение важно в некоторых ситуациях, например, чтобы персонажи в автобусе падали, если автобус врежется в стену.
Главное что физический движок где-то внутри манипулирует ускорением объектов, разве нет?
НЕТ, мне не сложно сделать это:
>if last_velocity.distance_to(velocity) > max_accel: ...
Я просто не понимаю, почему нет отдельного поля.
>>10176
Попробуй очистить collision_mask у всех костей. Тебе же нужно только попадание мышки проверять?
https://docs.godotengine.org/en/stable/classes/class_collisionobject3d.html#class-collisionobject3d-property-collision-mask
Это ведь на пустой сцене, где больше ничего нет?
>Collision Pairs 7736
Попробуй очистить collision_mask у всех костей. Тебе же нужно только попадание мышки проверять?
https://docs.godotengine.org/en/stable/classes/class_collisionobject3d.html#class-collisionobject3d-property-collision-mask
Это ведь на пустой сцене, где больше ничего нет?
>>10179
Очистил, как ты и сказал. Упало с 7к до 1322.
Да, пока только проверка попадание мышки, но никаких особых экспериментов с физикой не планируется.
Сцена практически пуста, не считая с десяток простых объектов типа коробок и тд.
Очистил, как ты и сказал. Упало с 7к до 1322.
Да, пока только проверка попадание мышки, но никаких особых экспериментов с физикой не планируется.
Сцена практически пуста, не считая с десяток простых объектов типа коробок и тд.
>>10178
Ускорение это действие какой-либо силы, т.е. отдельный вектор ускорения, который умножается на вектор скорости.
Ебать ты говодя. Перечитай школьную физику.
>Вот velocity - это вектор скорости, он есть у RigidBody. А что на счёт ускорения?
Ускорение это действие какой-либо силы, т.е. отдельный вектор ускорения, который умножается на вектор скорости.
> т.к. знать ускорение важно в некоторых ситуациях, например, чтобы персонажи в автобусе падали, если автобус врежется в стену.
Ебать ты говодя. Перечитай школьную физику.
>>09903
На официальном сайте всё подробно перечисляют:
https://godotengine.org/article/dev-snapshot-godot-4-2-beta-1/
>>09954
Это неправда, они не накручивают.
Вкратце, раньше дедлайнов не существовало - когда хочешь, добавляешь фичу, а потом баги ищешь хрен знает сколько времени. Из-за этого версии долго ждать приходилось, пока всё допилят...
Сейчас ввели дедлайны. Если я правильно помню, разработчикам даётся 3 месяца на введение новых функций в версию, а затем месяц на поиск багов, когда любые новые функции вводить запрещено (остаются ждать следующую версию).
Так что теперь новые версии с новыми фичами выходят быстрее и надёжнее, чем раньше. Всё ненадёжное и недоделанное ждёт следующего окна.
Это здорово, что хватает разработчиков на такую высокую скорость. Большинство опенсурс движков не получают новых функций годами.
Подчёркиваю, речь идёт о минорных версиях, т.е. версиях с новым функционалом. Это не патчи багов. Патчи выходят отдельно по мере возможности.
Так что вы радоваться должны. Для вас стараются...
>А что там прям такого крутого и важного?
На официальном сайте всё подробно перечисляют:
https://godotengine.org/article/dev-snapshot-godot-4-2-beta-1/
>>09954
>тут решили ускорить как релиз
>так и сейчас цифры быстро накручивают.
Это неправда, они не накручивают.
Вкратце, раньше дедлайнов не существовало - когда хочешь, добавляешь фичу, а потом баги ищешь хрен знает сколько времени. Из-за этого версии долго ждать приходилось, пока всё допилят...
Сейчас ввели дедлайны. Если я правильно помню, разработчикам даётся 3 месяца на введение новых функций в версию, а затем месяц на поиск багов, когда любые новые функции вводить запрещено (остаются ждать следующую версию).
Так что теперь новые версии с новыми фичами выходят быстрее и надёжнее, чем раньше. Всё ненадёжное и недоделанное ждёт следующего окна.
Это здорово, что хватает разработчиков на такую высокую скорость. Большинство опенсурс движков не получают новых функций годами.
Подчёркиваю, речь идёт о минорных версиях, т.е. версиях с новым функционалом. Это не патчи багов. Патчи выходят отдельно по мере возможности.
Так что вы радоваться должны. Для вас стараются...
Главное - делать игры.
>>10183
Ускорение - это быстрота изменения скорости.
В конечном итоге у любого физического тела есть вектор ускорения для каждого тика движка... Но его вычислять вручную приходится, а для этого нужно где-то хранить предыдущее значение velocity.
a = ∆v / ∆t, что ещё тебе напомнить?
>>10180
Теперь движок делает меньше лишних проверок.
>Ускорение это действие какой-либо силы
Ускорение - это быстрота изменения скорости.
В конечном итоге у любого физического тела есть вектор ускорения для каждого тика движка... Но его вычислять вручную приходится, а для этого нужно где-то хранить предыдущее значение velocity.
>Перечитай школьную физику.
a = ∆v / ∆t, что ещё тебе напомнить?
>>10180
>Упало с 7к до 1322.
Теперь движок делает меньше лишних проверок.
>>10191
А есть ли? Движок просто для каждого объекта на каждом тике помножает дельту на скорость, движку не надо знать ускорение
> у любого физического тела есть вектор ускорения для каждого тика движка
А есть ли? Движок просто для каждого объекта на каждом тике помножает дельту на скорость, движку не надо знать ускорение
>>10191
Ускорения это сила, понимаешь? Сил может быть несколько.
Какие, блядь, вычисления вручную? Что ты несешь вообще? Газани и школьную физику изучи.
Какие ускорения и когда по-твоему испытывают тела в автобусе? По-твоему они ускоряются, когда автобус останавливается? Какая сила действует на них при ускорении?
> Ускорение - это быстрота изменения скорости.
Ускорения это сила, понимаешь? Сил может быть несколько.
Какие, блядь, вычисления вручную? Что ты несешь вообще? Газани и школьную физику изучи.
> a = ∆v / ∆t, что ещё тебе напомнить?
Какие ускорения и когда по-твоему испытывают тела в автобусе? По-твоему они ускоряются, когда автобус останавливается? Какая сила действует на них при ускорении?
>>10206
Кончай троллить.
Конечно. Ускоряются в сторону лобового стекла относительно автобуса и в сторону заднего стекла относительно асфальта под колёсами автобуса.
Пассажир движется со скоростью автобуса и в момент резкой остановки (ускорения автобуса до полной остановки) продолжает движение, замедляясь об препятствия. У него ускорение, заключающееся в быстром снижении скорости.
У тебя не укладывается в голове, что "торможение" равносильно "ускорению" в бытовом смысле?
>Ускорения это сила
Кончай троллить.
>По-твоему они ускоряются, когда автобус останавливается?
Конечно. Ускоряются в сторону лобового стекла относительно автобуса и в сторону заднего стекла относительно асфальта под колёсами автобуса.
>Какая сила действует на них при ускорении?
Пассажир движется со скоростью автобуса и в момент резкой остановки (ускорения автобуса до полной остановки) продолжает движение, замедляясь об препятствия. У него ускорение, заключающееся в быстром снижении скорости.
У тебя не укладывается в голове, что "торможение" равносильно "ускорению" в бытовом смысле?
286 Кб, webm,480x360, 0:05
>>Ускорения это сила
>Кончай троллить.
>>По-твоему тела ускоряются, когда автобус останавливается?
> Конечно.
Этого гододика уже не спасти...
>>10211
Ты кормишь дефрагментатора стека. Он не первый раз в треде разводит свой троллинг про физику.
Ты кормишь дефрагментатора стека. Он не первый раз в треде разводит свой троллинг про физику.
Почему может не передаваться InputEventScreenDrag когда на мобилке держишь кнопку одним пальцем, и двигаешь другим по не-кнопочной области? Кнопка ест драг? Отучить ее реально?
>>10239
Сам себе отвечаю. Да, ест. Mouse Filter Pass почему-то не помогает передать драг выше. Помогает только игнор.
Сам себе отвечаю. Да, ест. Mouse Filter Pass почему-то не помогает передать драг выше. Помогает только игнор.
>>10239
Все, разобрался. Надо не обычные баттоны использовать, а TouchScreenButton.
Все, разобрался. Надо не обычные баттоны использовать, а TouchScreenButton.
315 Кб, mp4,360x202, 0:06
>>10113
запуск из студии отвалился. ну точнее оно запускает, но последнюю сборку годота. сборки из студии игнорируются. с 1 и 2 бетой было ок.
запуск из студии отвалился. ну точнее оно запускает, но последнюю сборку годота. сборки из студии игнорируются. с 1 и 2 бетой было ок.
>>10246
ага, походу ему теперь как-то надо указывать какую конфигурацию запускать. по умолчанию запускает дебуг. ключей нужных в хелпе не нашел
ага, походу ему теперь как-то надо указывать какую конфигурацию запускать. по умолчанию запускает дебуг. ключей нужных в хелпе не нашел
>>10245
Раз ты начал маневрировать, и больше не утверждаешь что
То значит ты все таки нагуглил учебник по физике, прогресс.
Раз ты начал маневрировать, и больше не утверждаешь что
> ускорение это сила
То значит ты все таки нагуглил учебник по физике, прогресс.
>>10246
Может быть, тебе нужно что-то обновить?
https://github.com/godotengine/build-containers/pull/128
Из списка изменений с сайта:
Я не шарю в компиляции движка, но наверняка тебе нужно что-то обновить, если ты компилируешь.
>сборки из студии
Может быть, тебе нужно что-то обновить?
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.
Я не шарю в компиляции движка, но наверняка тебе нужно что-то обновить, если ты компилируешь.
99 Кб, 792x628не движка, проектов. все таки отладчик у студии получше будет. ну и банально не пересобирать проект по 2 раза
>>10323
Вот почему многие выбирают GDScript.
Производительность труда разработчика >>>> производительность игры.
Переписать своё говно на ассемблер всегда успеешь.
>не пересобирать проект по 2 раза
Вот почему многие выбирают GDScript.
Производительность труда разработчика >>>> производительность игры.
Переписать своё говно на ассемблер всегда успеешь.
>>10206
>>10245
Ты обосрался и не можешь этого признать? Человеку нужно узнать вектор ускорения за тик таймера, а ты ему про какие-то силы втираешь. Сил на объект много действует, а ускорение у него всегда одно (даже если оно нулевое или отрицательное, не важно).
Кроме того, движок не сообщает, какие силы подействовали на объект. Можно узнать вектор гравитации, но что там влияло кроме гравитации - неизвестно. Даже к встроенной силе трения прямого доступа по сути нет, ты можешь только физический материал настроить от "0" до "1"...
>Ускорения это сила, понимаешь? Сил может быть несколько.
>>10245
>Ускорение создаётся силой приложенной к объекту.
Ты обосрался и не можешь этого признать? Человеку нужно узнать вектор ускорения за тик таймера, а ты ему про какие-то силы втираешь. Сил на объект много действует, а ускорение у него всегда одно (даже если оно нулевое или отрицательное, не важно).
Кроме того, движок не сообщает, какие силы подействовали на объект. Можно узнать вектор гравитации, но что там влияло кроме гравитации - неизвестно. Даже к встроенной силе трения прямого доступа по сути нет, ты можешь только физический материал настроить от "0" до "1"...
Уже появилась нейросеть для музыкальных треков? Пидоры в музаче мне заломили прайс будто я ААА студия нахуй.
>>10332
Да, есть нейросети. А я могу бесплатно сделать, если проект интересный (смущает только то, что он на годоте). Пишу музыку более 20 лет.
Да, есть нейросети. А я могу бесплатно сделать, если проект интересный (смущает только то, что он на годоте). Пишу музыку более 20 лет.
>>10328
За 15 лет я писал код на десятках языков. Первое время было сложно адаптироваться к GDScript, но потом я понял, что лучше изучить один раз и без проблем пользоваться, чем почти ежедневно спотыкаться о косяки каких-то костылей, которые прикручены к движку снаружи.
Godot Editor может использоваться как полностью независимая RAD IDE. И это основной способ её использовать, всё остальное - костыли для помощи неспособным ходить без костылей. Настоящему программисту вообще плевать, на чём писать код, потому что код у него в голове в абстрактной форме, а записи буквами - это одна из интерпретаций.
Вот что ты видишь перед глазами, когда решаешь задачу? Команды из API библиотек .NET? Очевидно, решение у тебя в абстрактной форме, а команды - только один из вариантов выразить это решение.
И если язык позволяет быстрее выразить решение, то он, очевидно, лучше для программирования.
>15 лет опыта шарпа
За 15 лет я писал код на десятках языков. Первое время было сложно адаптироваться к GDScript, но потом я понял, что лучше изучить один раз и без проблем пользоваться, чем почти ежедневно спотыкаться о косяки каких-то костылей, которые прикручены к движку снаружи.
Godot Editor может использоваться как полностью независимая RAD IDE. И это основной способ её использовать, всё остальное - костыли для помощи неспособным ходить без костылей. Настоящему программисту вообще плевать, на чём писать код, потому что код у него в голове в абстрактной форме, а записи буквами - это одна из интерпретаций.
Вот что ты видишь перед глазами, когда решаешь задачу? Команды из API библиотек .NET? Очевидно, решение у тебя в абстрактной форме, а команды - только один из вариантов выразить это решение.
И если язык позволяет быстрее выразить решение, то он, очевидно, лучше для программирования.
>>10332
Во-первых, звучит хуже процедурной музыки. Процедурную музыку любая веб-макака сделает, потратив немного времени на изучение теории.
Во-вторых, тебя издатели задолбают, потому что нейросеть обучалась на существующей музыке и генерирует что-то слишком похожее на это.
Лучше сделать игру без музыки. В музыке одни копирасты озабоченные, ищут способы извлечь сверхприбыли из беззащитных лохов. Игру с музыкой сложнее стримить, потому что копирасты заставляют удалять звук из видео или полностью блокируют видео/стримера.
Не говоря уж о том, что музыка давит на мозг части игроков, которым придётся её заглушать. А кто-то изначально без звука играть будет. Делать музыку для игры - пустая трата времени, которую мало кто из реальных игроков оценит.
>нейросеть для музыкальных треков?
Во-первых, звучит хуже процедурной музыки. Процедурную музыку любая веб-макака сделает, потратив немного времени на изучение теории.
Во-вторых, тебя издатели задолбают, потому что нейросеть обучалась на существующей музыке и генерирует что-то слишком похожее на это.
Лучше сделать игру без музыки. В музыке одни копирасты озабоченные, ищут способы извлечь сверхприбыли из беззащитных лохов. Игру с музыкой сложнее стримить, потому что копирасты заставляют удалять звук из видео или полностью блокируют видео/стримера.
Не говоря уж о том, что музыка давит на мозг части игроков, которым придётся её заглушать. А кто-то изначально без звука играть будет. Делать музыку для игры - пустая трата времени, которую мало кто из реальных игроков оценит.
5,4 Мб, mp4,1280x720, 0:24
>>10330
Какая же ты поехавшая, гододя.
Когда ты программируешь игры у тебя не существует ускорения, есть только сила которая воздействует на объект. Внимательно читай. Не существует ускорения.
Не существует ускорения потому что объект, который производит силу, сам влияет на объекты и может когда угодно изменять силу, а значит и влияние на другие объекты. Объект, к которому приложена сила, если и влияет на объекты, которые являются источником силы, то не через ускорения или скорость, а по отдельному интерфейсу который изменяет именно силу.
Был бы ты не шизоидым гододей который не осилил даже школьный курс физики - ты бы это понимал. Жаль что ты гододя. Выкатывайся из гейдева, оно не для тебя. Даже говдод не ослили, ну и пиздец шиз.
Какая же ты поехавшая, гододя.
Когда ты программируешь игры у тебя не существует ускорения, есть только сила которая воздействует на объект. Внимательно читай. Не существует ускорения.
Не существует ускорения потому что объект, который производит силу, сам влияет на объекты и может когда угодно изменять силу, а значит и влияние на другие объекты. Объект, к которому приложена сила, если и влияет на объекты, которые являются источником силы, то не через ускорения или скорость, а по отдельному интерфейсу который изменяет именно силу.
Был бы ты не шизоидым гододей который не осилил даже школьный курс физики - ты бы это понимал. Жаль что ты гододя. Выкатывайся из гейдева, оно не для тебя. Даже говдод не ослили, ну и пиздец шиз.
>>10348
Игра должна быть интуитивно понятной, чтобы игроку не приходилось курить мануал три часа. Старайся избегать необходимости в туториале.
Есть глухие и слабослышащие. Твоя игра должна быть доступна для них, и вместо создания костыля в виде субтитров "(труп упал)" лучше делать игру, которая на звуки вообще не полагается - т.е. будет одинаково хорошо восприниматься без звука. Алсо, далеко не у всех есть аудиосистема в компе или возможность включать её для игры...
Вот тут ты в самую точку попал. Мне довольно часто приходилось напоминать разрабам в отзывах и на форумах о необходимости кнопки "выход", которую большинство почему-то решают не добавлять.
>Туториал,
Игра должна быть интуитивно понятной, чтобы игроку не приходилось курить мануал три часа. Старайся избегать необходимости в туториале.
>звуки,
Есть глухие и слабослышащие. Твоя игра должна быть доступна для них, и вместо создания костыля в виде субтитров "(труп упал)" лучше делать игру, которая на звуки вообще не полагается - т.е. будет одинаково хорошо восприниматься без звука. Алсо, далеко не у всех есть аудиосистема в компе или возможность включать её для игры...
>кнопка выход?
Вот тут ты в самую точку попал. Мне довольно часто приходилось напоминать разрабам в отзывах и на форумах о необходимости кнопки "выход", которую большинство почему-то решают не добавлять.
>>10349
Переменная была равна 1, стала равна 2, потом будет равна 4. Между значениями одинаковые интервалы времени (тик). Скорость в первом случае равна 1, во втором случае равна 2. Значит, ускорение равно 1.
Ты в какую сторону воюешь? Из школьного курса физики следует, что ускорение всегда существует. А ты утверждаешь, что оно не существует никогда.
>Не существует ускорения.
Переменная была равна 1, стала равна 2, потом будет равна 4. Между значениями одинаковые интервалы времени (тик). Скорость в первом случае равна 1, во втором случае равна 2. Значит, ускорение равно 1.
>не осилил даже школьный курс физики
Ты в какую сторону воюешь? Из школьного курса физики следует, что ускорение всегда существует. А ты утверждаешь, что оно не существует никогда.
>>10355
Он просто троллит и когда понял что обосрался переобулся на 180 градусов.
Он просто троллит и когда понял что обосрался переобулся на 180 градусов.
>>10249
В следующем году когда системы отсчета будете проходить, у марьиванны спросишь.
В следующем году когда системы отсчета будете проходить, у марьиванны спросишь.
100 Кб, 279x321>>10403
Вчера хотел компьютер включить и поработать над игрой, а он опять не хочет работать. На телефоне в Godot ковыряться мучительно, да и игра требует управления с клавомыши. Так что никаких игр.
>Делайте игры.
Вчера хотел компьютер включить и поработать над игрой, а он опять не хочет работать. На телефоне в Godot ковыряться мучительно, да и игра требует управления с клавомыши. Так что никаких игр.
>>10420
Гуляй, фантазёр. И не лезь в чужой разговор.
>Напишите мне саундтрек
>Я сам композитор с вышкой
Гуляй, фантазёр. И не лезь в чужой разговор.
2 Мб, mp4,1272x716, 0:14
>>10403
Вот делаю, но когда пуля попадает в псину, всё вылетает жалуясь на слои, а я в них запутался и не понял че делать надо
Вот делаю, но когда пуля попадает в псину, всё вылетает жалуясь на слои, а я в них запутался и не понял че делать надо
>>10422
Сделай аутлайн персонажам, а то сливаются с фоном
Сделай аутлайн персонажам, а то сливаются с фоном
>>10422
ШRYPHA?
Ты б ещё больше пиксели сделал... Хотя для первой попытки/прототипа неплохо, но ГГ сливается с фоном.
ПКМ по ошибке -> скопировать -> вставить сюда.
Алсо номер версии движка, чтоб мы не гадали.
ШRYPHA?
Ты б ещё больше пиксели сделал... Хотя для первой попытки/прототипа неплохо, но ГГ сливается с фоном.
>вылетает жалуясь на слои
ПКМ по ошибке -> скопировать -> вставить сюда.
Алсо номер версии движка, чтоб мы не гадали.
>>10418
Ты с разными людьми говорил, но я бы тоже не стал связываться с живым человеком с каким-то условиями и смущениями, когда есть нейросеть, способная в музыку. Пусть эта музыка и будет хуже.
Историю про падение стековерфлоу слышал? Вот там такая же хуйня. Лучше у чатгпт спросить, он тебя не будет забрасывать "ты делаешь не так, используй лучше X, а еще лучше заплати мне, и кстати весь твой стек технологий - говно".
Ты с разными людьми говорил, но я бы тоже не стал связываться с живым человеком с каким-то условиями и смущениями, когда есть нейросеть, способная в музыку. Пусть эта музыка и будет хуже.
Историю про падение стековерфлоу слышал? Вот там такая же хуйня. Лучше у чатгпт спросить, он тебя не будет забрасывать "ты делаешь не так, используй лучше X, а еще лучше заплати мне, и кстати весь твой стек технологий - говно".
>>10426
Invalid get index 'knockback_vector' (on base: 'Area2D (Bullet.gd)').
годот 3.5.2, делаю по туторам heartbeast'a, но он с мечем делает экшн рпг, а я с пулями, поэтому местами по своему игру делаю, и в целом уже чувствую кашу развел
Да, это язык будущего и сильно парится над домиками пока не хотел
они одного размера, это пиксели, прост без отступов
Invalid get index 'knockback_vector' (on base: 'Area2D (Bullet.gd)').
годот 3.5.2, делаю по туторам heartbeast'a, но он с мечем делает экшн рпг, а я с пулями, поэтому местами по своему игру делаю, и в целом уже чувствую кашу развел
>ШRYPHA
Да, это язык будущего и сильно парится над домиками пока не хотел
>Ты б ещё больше пиксели сделал
они одного размера, это пиксели, прост без отступов
>>10421
Гуляй, срачер. Все уже с тобой все поняли.
Гуляй, срачер. Все уже с тобой все поняли.
>>10428
Наркоман. Давай начнем с того что это разные вещи. Продолжим тем что Стим тебя за нейронку в музыке выпиздит рано или поздно. Музыкальные лейблы это тебе не шутка, они очень быстро выебут и высушат всех за копирайт.
Наркоман. Давай начнем с того что это разные вещи. Продолжим тем что Стим тебя за нейронку в музыке выпиздит рано или поздно. Музыкальные лейблы это тебе не шутка, они очень быстро выебут и высушат всех за копирайт.
>>10447
Даже если так, что не факт, то лучше без музыки вообще, или взять какой-нибудь паблик домейн, чем связываться с вонючкой с кучей условий.
Даже если так, что не факт, то лучше без музыки вообще, или взять какой-нибудь паблик домейн, чем связываться с вонючкой с кучей условий.
>>10453
Хау абаут научится работать в команде и прокачать свои социальные навыки.
>чем связываться с вонючкой с кучей условий.
Хау абаут научится работать в команде и прокачать свои социальные навыки.
>>10462
Ты это на анонимной имиджборде пишешь, нормис.
Большинство здесь гиперкомпенсирует отсутствие социальных навыков и кучу комплексов, мешающих разговаривать вживую/через мессенджеры.
А иначе зачем вообще этот форум нужен?
>работать в команде
>прокачать свои социальные навыки
Ты это на анонимной имиджборде пишешь, нормис.
Большинство здесь гиперкомпенсирует отсутствие социальных навыков и кучу комплексов, мешающих разговаривать вживую/через мессенджеры.
А иначе зачем вообще этот форум нужен?
>>10462
А, ты это к нам социальные навыки пришел прокачивать.
Жаль, такого композтора потеряли.
А, погоди, ты же не показал никакой музыки.
>пришел в тред годота
>засмущался почему игру делают на годоте
>начал посылать нахуй и называть наркоманами
>Хау абаут прокачать свои социальные навыки
А, ты это к нам социальные навыки пришел прокачивать.
Жаль, такого композтора потеряли.
А, погоди, ты же не показал никакой музыки.
>>10469
Но я не композитор, ты путаешь постеров.
А наркоман он потому что сравнивает то что скурвился стековерфлоу, по куче причин связанных не только с нейронками, и музыку, которую нейронки нормально не делают прям совсем. Это при живых композиторах готовых тебе бесплатно пару демок отдать для пользования в проекте, если найдешь и попросишь.
>>10463
У тебя какая-то проблема навыка, я на имейдж бордах нашел нескольких художников и композиторов, уже заказывал у них коммишены для своих проектов. А еще я делал это на форчане и знаю английский достаточно хорошо для этого, что для любого нормального программиста так-то требование для работы.
Просто попробуй начать общаться с людьми и искать нужные связи с нужными специалистами, без этого в геймдеве никак.
Но я не композитор, ты путаешь постеров.
А наркоман он потому что сравнивает то что скурвился стековерфлоу, по куче причин связанных не только с нейронками, и музыку, которую нейронки нормально не делают прям совсем. Это при живых композиторах готовых тебе бесплатно пару демок отдать для пользования в проекте, если найдешь и попросишь.
>>10463
>Большинство здесь гиперкомпенсирует отсутствие социальных навыков и кучу комплексов, мешающих разговаривать вживую/через мессенджеры.
>А иначе зачем вообще этот форум нужен?
У тебя какая-то проблема навыка, я на имейдж бордах нашел нескольких художников и композиторов, уже заказывал у них коммишены для своих проектов. А еще я делал это на форчане и знаю английский достаточно хорошо для этого, что для любого нормального программиста так-то требование для работы.
Просто попробуй начать общаться с людьми и искать нужные связи с нужными специалистами, без этого в геймдеве никак.
>>10476
Чисто теоретически они могут; проблема в GIGO:
https://en.wikipedia.org/wiki/GIGO
Кто учит эти нейронки? Однозначно не композиторы.
Они просто хотят бесплатный пиар за твой счёт. Если твоя игра не взлетит, им похрен. Если твоя игра взлетит, они будут всем говорить "а вы знали, это я написал музыку к той популярной игре, вот моя страничка, где вы можете купить другие мои работы".
Бесплатно помогать копирастам... ну такое. Ещё может деньги отжать, если нет доказательств, что он тебе бесплатно всю эту работу сделал.
Для меня разработка игр - хобби, которым я, как и многие, увлёкся из-за увлечения играми.
Я не хочу заработать или стать популярным, мне просто скучно и нравится копаться в коде, своими руками оживляя какие-то несложные идеи...
>музыку, которую нейронки нормально не делают прям совсем
Чисто теоретически они могут; проблема в GIGO:
https://en.wikipedia.org/wiki/GIGO
Кто учит эти нейронки? Однозначно не композиторы.
>Это при живых композиторах готовых тебе бесплатно пару демок отдать для пользования в проекте, если найдешь и попросишь.
Они просто хотят бесплатный пиар за твой счёт. Если твоя игра не взлетит, им похрен. Если твоя игра взлетит, они будут всем говорить "а вы знали, это я написал музыку к той популярной игре, вот моя страничка, где вы можете купить другие мои работы".
Бесплатно помогать копирастам... ну такое. Ещё может деньги отжать, если нет доказательств, что он тебе бесплатно всю эту работу сделал.
>искать нужные связи с нужными специалистами, без этого в геймдеве никак.
Для меня разработка игр - хобби, которым я, как и многие, увлёкся из-за увлечения играми.
Я не хочу заработать или стать популярным, мне просто скучно и нравится копаться в коде, своими руками оживляя какие-то несложные идеи...
2,1 Мб, mp4,1268x706, 0:17
>>10422
Блять, оказывается просто сигнал не был подключен, несмотря на то что строчка функции была, во дебил
Блять, оказывается просто сигнал не был подключен, несмотря на то что строчка функции была, во дебил
722 Кб, 786x582>>10479
Бля, я даж не знаю что на это ответить. Как бы... Да? И это нормально? И я бы на таком месте был бы даже рад за композитора, что помог и себе и ему?
В чем твоя проблема сука.
>Они просто хотят бесплатный пиар за твой счёт. Если твоя игра не взлетит, им похрен. Если твоя игра взлетит, они будут всем говорить "а вы знали, это я написал музыку к той популярной игре, вот моя страничка, где вы можете купить другие мои работы".
>Бесплатно помогать копирастам... ну такое.
Бля, я даж не знаю что на это ответить. Как бы... Да? И это нормально? И я бы на таком месте был бы даже рад за композитора, что помог и себе и ему?
В чем твоя проблема сука.
>>10488
Вот поэтому я не очень люблю подключать сигналы мышкой, а пишу в _ready connect(). Конечно это не 100% гарантия потому что и там можно забыть.
Вот поэтому я не очень люблю подключать сигналы мышкой, а пишу в _ready connect(). Конечно это не 100% гарантия потому что и там можно забыть.
>>10490
Пассажир, спок.
Пассажир, спок.
>>10490
В том, что они хотят нажиться даже если ты сам ничего не заработаешь и уйдешь в минус. Еще строить из себя будут охуенного композитора и ссать в уши как секунда их драгоценного времени стоит 100500 денег.
Всегда забавляло как среди программистов считается нормой выкладывать свой код под опенсорсом просто потому что может, а какой-то мутный пердячер во фрутилупсе сразу корчит из себя бетховена и дрожит за свои 30 секунд говна. Те же рисоваки не настолько отбитые.
В том, что они хотят нажиться даже если ты сам ничего не заработаешь и уйдешь в минус. Еще строить из себя будут охуенного композитора и ссать в уши как секунда их драгоценного времени стоит 100500 денег.
Всегда забавляло как среди программистов считается нормой выкладывать свой код под опенсорсом просто потому что может, а какой-то мутный пердячер во фрутилупсе сразу корчит из себя бетховена и дрожит за свои 30 секунд говна. Те же рисоваки не настолько отбитые.
>>10494
Ебать тут в башке насрано. Тебе композитор в детстве на хуй наступил? Они точно так же выкладывают свои работы под открытыми лицензиями. Их стараются не использовать просто чтоб у игры была своя уникальность так-то, да и заказать композитора дело дешевое довольно.
Не братан, пойду я лучше игры делать, ты слишком ебанутый.
>Всегда забавляло как среди программистов считается нормой выкладывать свой код под опенсорсом просто потому что может, а какой-то мутный пердячер во фрутилупсе сразу корчит из себя бетховена и дрожит за свои 30 секунд говна
Ебать тут в башке насрано. Тебе композитор в детстве на хуй наступил? Они точно так же выкладывают свои работы под открытыми лицензиями. Их стараются не использовать просто чтоб у игры была своя уникальность так-то, да и заказать композитора дело дешевое довольно.
Не братан, пойду я лучше игры делать, ты слишком ебанутый.
>>10497
Слишком редко чтобы считать это значимым. Зато будут исходить на говно, когда ты им напишешь и попросишь использовать трек с саундклауда с 3 прослушиваниями на всем аккаунте. В их голове им наверное сами Рокстары пишут и сейчас наш йоба-композер обзаведется парой феррари.
>Они точно так же выкладывают свои работы под открытыми лицензиями.
Слишком редко чтобы считать это значимым. Зато будут исходить на говно, когда ты им напишешь и попросишь использовать трек с саундклауда с 3 прослушиваниями на всем аккаунте. В их голове им наверное сами Рокстары пишут и сейчас наш йоба-композер обзаведется парой феррари.
>>10499
для игры с тремя покупателями.
Предложи ему хотя бы символическую сумму, а не спасибо.
> когда ты им напишешь и попросишь использовать трек с саундклауда с 3 прослушиваниями на всем аккаунте
для игры с тремя покупателями.
Предложи ему хотя бы символическую сумму, а не спасибо.
>>10506
Предлагаю ему показать свой трек моим трем покупателем. Было у него 3 прослушивания, станет 6. И делать ничего не надо. Будто что-то плохое.
Предлагаю ему показать свой трек моим трем покупателем. Было у него 3 прослушивания, станет 6. И делать ничего не надо. Будто что-то плохое.
>>10355
Пиздец ты говдодя.
Так и быть, объясню чтобы даже гододя поняла. Ускорение в играх не нужно. Нет никакого применения ускорению вообще. Ни в каких ситуациях. Никогда. Ему просто не никакого применения. Единственное что в играх используется - это сила.
Неужели тебе так сложно понять это, гододя?
Пиздец ты говдодя.
Так и быть, объясню чтобы даже гододя поняла. Ускорение в играх не нужно. Нет никакого применения ускорению вообще. Ни в каких ситуациях. Никогда. Ему просто не никакого применения. Единственное что в играх используется - это сила.
Неужели тебе так сложно понять это, гододя?
Проснулись, потянулись, время делать игры.
>>10548
А, оно старое. Еще альфа 4.0. Ну ладно.
А, оно старое. Еще альфа 4.0. Ну ладно.
>>07152 (OP)
Сап, годотеры. Я заметил, что в редакторе тайлмапов 3.5 версии можно выбрать сразу два тайла через ctrl+левый клик, так если есть такая функция, то может можно и ставить сразу два, а не по одному?
Сап, годотеры. Я заметил, что в редакторе тайлмапов 3.5 версии можно выбрать сразу два тайла через ctrl+левый клик, так если есть такая функция, то может можно и ставить сразу два, а не по одному?
58 Кб, 1033x839>>10560
в 4 можно. какой блок выбрал такой и ставиться. а если через заливку - чередуется
в 4 можно. какой блок выбрал такой и ставиться. а если через заливку - чередуется
Чет никакого смысла не вижу в scene unique names. Из-за пределов этой сцены ноду по этому новому имени все равно получить нельзя, а внутри сцены отследить ее не составляет труда.
Как делается сохранение состояния уровней в рпг?
Например, дверь открыта/заперта, свет включен/выключен, итд.
Придумал иметь дикшенари всех объектов в игре (или на уровне) в котором хранится их состояние.
При загрузке уровня каждый объект смотрит свое состояние в словаре, когда игрок изменяет состояние объекта оно тоже в словаре обновляется.
Это так делается в играх?
Например, дверь открыта/заперта, свет включен/выключен, итд.
Придумал иметь дикшенари всех объектов в игре (или на уровне) в котором хранится их состояние.
При загрузке уровня каждый объект смотрит свое состояние в словаре, когда игрок изменяет состояние объекта оно тоже в словаре обновляется.
Это так делается в играх?
>>10620
Не всех, только тех, которые могут менять состояние. И сохраняется только если состояние изменилось.
Можно использовать встроенный механизм ресурсов, но с ним есть нюанс: в сейв можно инжектить любой код на GDScript, в т.ч. вредоносный. Если игрок качает рандомные сейвы в tscn/tres формате, он рискует подцепить какой-нибудь вирус.
Поэтому лучше хранить сейвы в json или кастомном бинарном формате (записывать байты вручную).
>дикшенари всех объектов в игре (или на уровне) в котором хранится их состояние
Не всех, только тех, которые могут менять состояние. И сохраняется только если состояние изменилось.
Можно использовать встроенный механизм ресурсов, но с ним есть нюанс: в сейв можно инжектить любой код на GDScript, в т.ч. вредоносный. Если игрок качает рандомные сейвы в tscn/tres формате, он рискует подцепить какой-нибудь вирус.
Поэтому лучше хранить сейвы в json или кастомном бинарном формате (записывать байты вручную).
>>10620
приблизительно так. айди предмета с состоянием - его состояние. все остальное - вариации релизации
приблизительно так. айди предмета с состоянием - его состояние. все остальное - вариации релизации
>>10596
Полезнее всего в GUI. Сложный гуй может представлять собой очень глубокое дерево за счёт всех контейнеров и прочего, плюс ты можешь часто перетаскивать ноды по дереву, меняя внешний вид интерфейса. Чтобы каждый раз в коде не обновлять пути до отдельных кнопок и надписей, придумали использовать короткий синтаксис $%имя.
Вообще-то, можно. Это недокументированная фича и, возможно, даже баг, но пока что работает. Почему баг? Потому что в идеале ты не должен иметь доступа к рандомным нодам где-то за пределами твоей сцены. Почему фича? Потому что get_node() всегда позволял получить доступ к рандомной ноде из любого участка дерева. Так что не знаю, оставят это поведение или нет.
Только если ты сцену никак не меняешь. Во время разработки гуя ноды часто приходится таскать.
Как альтернатива, можно сделать так:
Тогда редактор будет автоматически обновлять путь, указанный дизайнером сцены в button_path, когда дизайнер перемещает кнопку. Но это лишние действия по сравнению с простым запросом:
А Godot нацелен на быстрое прототипирование.
>никакого смысла не вижу в 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 нацелен на быстрое прототипирование.
>>10594
Хуан последние 3-4 года до выпуска 4.0 занимался в основном переписыванием всего рендерера с нуля на Вулкан. Над кодом движка работают 2 тысячи людей, несколько десятков - ключевые разработчики. Тем более, Хуан давно уже больше управлением и пиаром занят, чем разработкой. Конкретно тайлмапы кто переписывал не помню, но к 4.0 систему тайлмапов серьёзно переработали, так что обратно в 3.х кинуть возможности не было. Над 3.х работа практически завершена, будут только багфиксы добавлять при возможности (некоторые баги не пофиксить). Все ключевые разработчики давно работают над 4.х.
Короч, прекращайте Хуана пинать и переходите на четвёрку, если у вас не игра уровня ГТА 6 на тройке, требующая регулярных обновлений вот прям щас.
>а веб...
Веб-игры - зло и нинужны.
Большинство сидит на новых версиях.
Обнови драйвера, чтобы OpenGL 3.3 был.
Обновись до актуальной версии, наверное?
>Или Хуан выделение добавить додумался, а такой функционал нет?
Хуан последние 3-4 года до выпуска 4.0 занимался в основном переписыванием всего рендерера с нуля на Вулкан. Над кодом движка работают 2 тысячи людей, несколько десятков - ключевые разработчики. Тем более, Хуан давно уже больше управлением и пиаром занят, чем разработкой. Конкретно тайлмапы кто переписывал не помню, но к 4.0 систему тайлмапов серьёзно переработали, так что обратно в 3.х кинуть возможности не было. Над 3.х работа практически завершена, будут только багфиксы добавлять при возможности (некоторые баги не пофиксить). Все ключевые разработчики давно работают над 4.х.
Короч, прекращайте Хуана пинать и переходите на четвёрку, если у вас не игра уровня ГТА 6 на тройке, требующая регулярных обновлений вот прям щас.
>а веб...
Веб-игры - зло и нинужны.
>а мобильные...
Большинство сидит на новых версиях.
>а у меня ноутбук...
Обнови драйвера, чтобы OpenGL 3.3 был.
>а у меня Линукс...
Обновись до актуальной версии, наверное?
>>10536
Ты игры делал? Или только гиперказуалки?
Ещё раз. Задача: человек находится в сознании, стоя на движущейся платформе. Его мозг, анализируя ускорение платформы, калибрует тягу мышц скелета таким образом, чтобы компенсировать возникающее ускорение относительно платформы путём смещения центра тяжести. Если ускорение платформы слишком велико (резкая остановка, разгон или поворот), тогда скелетные мышцы не справятся с компенсацией, человек потеряет баланс, упадёт и покатится.
Повторяю, при равномерном движении платформы человек будет стоять неподвижно. Если платформа ускоряется, человек почувствует ускорение (дельту скорости платформы), попытается компенсировать своими мышцами, чтобы не упасть. Если ускорение слишком велико, компенсации мышцами будет недостаточно и человек упадёт. На одной только скорости и силах это никак не реализовать; силу в данном случае прикладывает сам человек, чтобы компенсировать изменение скорости платформы.
Алсо, если хочешь сиськи реалистично трясти:
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
- ускорение нужно, потому что колебание упругих тел производит из-за ускорения, а не скорости. Если нет ускорения, то упругое тело будет неподвижно. Всё потому, что часть тела не успевает ускориться, но на равномерной скорости догоняет основную массу. Поэтому сиськи оттягиваются только когда машина ускоряется, но не во время равномерного движения.
С симуляцией жидкости ты можешь поступить тупо, накидав невидимых шариков и обтянув их все одной поверхностью. Но если ты хочешь сделать более оптимальную модель и тебе не нужно разливать жидкость через край, ты можешь просто отображать поверхность воды, которая наклоняется в случае ускорения контейнера. При равномерном движении контейнера поверхность горизонтальна, но если контейнер ускоряется, поверхность наклоняется. Доступа к силам, действующим на контейнер, у тебя нет - ты ориентируешься только на его ускорение.
Наверняка есть другие примеры, но лень описывать. Ты игры всё равно не делаешь, зачем тебе это знать?
>>10536
Ты игры делал? Или только гиперказуалки?
Ещё раз. Задача: человек находится в сознании, стоя на движущейся платформе. Его мозг, анализируя ускорение платформы, калибрует тягу мышц скелета таким образом, чтобы компенсировать возникающее ускорение относительно платформы путём смещения центра тяжести. Если ускорение платформы слишком велико (резкая остановка, разгон или поворот), тогда скелетные мышцы не справятся с компенсацией, человек потеряет баланс, упадёт и покатится.
Повторяю, при равномерном движении платформы человек будет стоять неподвижно. Если платформа ускоряется, человек почувствует ускорение (дельту скорости платформы), попытается компенсировать своими мышцами, чтобы не упасть. Если ускорение слишком велико, компенсации мышцами будет недостаточно и человек упадёт. На одной только скорости и силах это никак не реализовать; силу в данном случае прикладывает сам человек, чтобы компенсировать изменение скорости платформы.
Алсо, если хочешь сиськи реалистично трясти:
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
- ускорение нужно, потому что колебание упругих тел производит из-за ускорения, а не скорости. Если нет ускорения, то упругое тело будет неподвижно. Всё потому, что часть тела не успевает ускориться, но на равномерной скорости догоняет основную массу. Поэтому сиськи оттягиваются только когда машина ускоряется, но не во время равномерного движения.
С симуляцией жидкости ты можешь поступить тупо, накидав невидимых шариков и обтянув их все одной поверхностью. Но если ты хочешь сделать более оптимальную модель и тебе не нужно разливать жидкость через край, ты можешь просто отображать поверхность воды, которая наклоняется в случае ускорения контейнера. При равномерном движении контейнера поверхность горизонтальна, но если контейнер ускоряется, поверхность наклоняется. Доступа к силам, действующим на контейнер, у тебя нет - ты ориентируешься только на его ускорение.
Наверняка есть другие примеры, но лень описывать. Ты игры всё равно не делаешь, зачем тебе это знать?
>>10653
Разве что для гуя. Но как по мне гуй в первую очередь не должен мешать игроку, поэтому сложные гуи я не делаю.
В тройке было магическое заклинание, два в одном:
export(NodePath) onready var button = get_node(button)
Разве что для гуя. Но как по мне гуй в первую очередь не должен мешать игроку, поэтому сложные гуи я не делаю.
>@export var button_path: NodePath
>@onready var button: Button = get_node(button_path)
В тройке было магическое заклинание, два в одном:
export(NodePath) onready var button = get_node(button)
>>10696
Емнип официально это было признано багом, потому что постоянно приводило к косяковым ситуациям,
Уже не помню точно, но сам вроде на такое напарывался со вложенными сценами (edit as children).
>export onready
Емнип официально это было признано багом, потому что постоянно приводило к косяковым ситуациям,
Уже не помню точно, но сам вроде на такое напарывался со вложенными сценами (edit as children).
154 Кб, 482x483И все же, как выбиться за пределы геймдевовского кружка? Чтобы в игру играли не только такие же геймведы как ты.
На ум приходит паразитирование на фандомах. Берешь условную Наруту и делаешь по ней платформер. Легкий вариант. Вот только потом тебя правообладатель прихлопнет.
На ум приходит паразитирование на фандомах. Берешь условную Наруту и делаешь по ней платформер. Легкий вариант. Вот только потом тебя правообладатель прихлопнет.
>>10710
Да, я так буду делать. Еще не сделал, но целюсь на аудиторию хотя бы в 100к.
Или подпольно что-то придумывать, например как порноделы. Когда билд можно скачать, но например за донаты более свежий.
Или искать лазейки, где есть фандом, но проще с собственностью.
Например, вариант: прочитать, какие персонажи вышли в Public Domain. К примеру, Шерлок Холмс и Винни Пух (но надо сделать визуально своего, либо брать оргинал) и нельзя наделять способностями, которых не было у оргинала и появились позже (когда супермен выйдет в общественное достояние, он будет уметь только прыгать, но не летать...)
Можно сделать свою франшизу, но похожую на что-то. RWBY берет в основе очевидные красную шапочку, белоснежку, златовласку и т.д. Даже если у Диснея есть эти персонажи, ничто не мешает их переосмыслить. Туда же Алису в стране чудес.
Можно воспользоваться принципом что геймплей не патентуется (не вдаваясь в буквоедство), например копировать геймплей homm3 и паразитировать на них.
Можно фармить 8 рублей в Я.Играх на играх про заглатывание бананов геншинодевочками потому что там пока что кладут на права
>На ум приходит паразитирование на фандомах.
Да, я так буду делать. Еще не сделал, но целюсь на аудиторию хотя бы в 100к.
>Вот только потом тебя правообладатель прихлопнет.
Или подпольно что-то придумывать, например как порноделы. Когда билд можно скачать, но например за донаты более свежий.
Или искать лазейки, где есть фандом, но проще с собственностью.
Например, вариант: прочитать, какие персонажи вышли в Public Domain. К примеру, Шерлок Холмс и Винни Пух (но надо сделать визуально своего, либо брать оргинал) и нельзя наделять способностями, которых не было у оргинала и появились позже (когда супермен выйдет в общественное достояние, он будет уметь только прыгать, но не летать...)
Можно сделать свою франшизу, но похожую на что-то. RWBY берет в основе очевидные красную шапочку, белоснежку, златовласку и т.д. Даже если у Диснея есть эти персонажи, ничто не мешает их переосмыслить. Туда же Алису в стране чудес.
Можно воспользоваться принципом что геймплей не патентуется (не вдаваясь в буквоедство), например копировать геймплей homm3 и паразитировать на них.
Можно фармить 8 рублей в Я.Играх на играх про заглатывание бананов геншинодевочками потому что там пока что кладут на права
>>10660
У меня слишком много сделано, а экспорт на 4 все ломает.
У меня слишком много сделано, а экспорт на 4 все ломает.
>>10717
Разве у этого есть живые фанаты? Последние вымерли еще в прошлом веке, за редким исключением, которые ты уже перечислил. Или вот Дракула, например. Кому он сегодня нужен? Дон Кихот, Моби Дик, ОЗ.
Закроется возможность завалиться в комьюнити и сказать "пацаны смотрите я игру про ваших персонажей сделал".
>прочитать, какие персонажи вышли в Public Domain
Разве у этого есть живые фанаты? Последние вымерли еще в прошлом веке, за редким исключением, которые ты уже перечислил. Или вот Дракула, например. Кому он сегодня нужен? Дон Кихот, Моби Дик, ОЗ.
>Можно сделать свою франшизу, но похожую на что-то.
Закроется возможность завалиться в комьюнити и сказать "пацаны смотрите я игру про ваших персонажей сделал".
>>10717
Вспомнил что есть Creative Commons фандомы. Например SCP. Мне этот сеттинг не подходит, но может тебе зайдет.
Вспомнил что есть Creative Commons фандомы. Например SCP. Мне этот сеттинг не подходит, но может тебе зайдет.
>>10717
Мне кажется как раз с ними юристы зассут связываться, чтобы потом в профильной прессе не ассоциировали бренд с порнографией.
Проще закрыть глаза на такое, пускай дрочат лишь бы не воняли.
> например как порноделы.
Мне кажется как раз с ними юристы зассут связываться, чтобы потом в профильной прессе не ассоциировали бренд с порнографией.
Проще закрыть глаза на такое, пускай дрочат лишь бы не воняли.
>>10641
>>10642
Ну я даже не столько про сохранение файла, сколько про сохранение при переходе между локациями, хотя это можно свести одно к другому.
Допустим есть вот есть уровень, на нем дверь. У нее дефолтное состояние заперто, оно зашито в сцену.
При этом есть допустим автолоад, хранящий словарь состояний объектов.
При каждой загрузке уровня дверь в onready спрашивает этот автолоад про состояние двери и выставляет нужное.
Игрок идет в другую комнату и там тянет рычаг, обновляется состояние в словаре, и вернувшись к двери игрок сможет пройти дальше.
Примерно так это должно выглядеть, как думаете?
>>10642
Ну я даже не столько про сохранение файла, сколько про сохранение при переходе между локациями, хотя это можно свести одно к другому.
Допустим есть вот есть уровень, на нем дверь. У нее дефолтное состояние заперто, оно зашито в сцену.
При этом есть допустим автолоад, хранящий словарь состояний объектов.
При каждой загрузке уровня дверь в onready спрашивает этот автолоад про состояние двери и выставляет нужное.
Игрок идет в другую комнату и там тянет рычаг, обновляется состояние в словаре, и вернувшись к двери игрок сможет пройти дальше.
Примерно так это должно выглядеть, как думаете?
>>10729
Полистал, пришел к выводу что больше всего фандом у пользователей GNU/Linux.
Полистал, пришел к выводу что больше всего фандом у пользователей GNU/Linux.
>>10730
Порноигры с Лунтиком и Барбоскиными удаляют с западных сайтов по запросу правообладателя из РФ.
В интернете все знают правило номер 34.
>>10729
Они много лет боролись с каким-то российским кабанчиком, который пытался их прикрыть на основании получения им торговой марки SCP...
>>10727
Двачую, персонажи средних веков нинужны.
В порноиграх часто бывают визуально похожие персонажи, так, что юрист не прикопаются, но фанат может быть вполне доволен. Что-то уровня смены имени, цвета волос и глаз, деталей одежды и т.п.
Вообще, думаю, можно закосить под AU:
https://en.wikipedia.org/wiki/Alternative_universe_(fan_fiction)
>>10717
Это называется "клон" и таких игр 99%, при том чем крупнее бюджет игры, тем вероятнее, что это клон, потому что клон менее рискованный. Только инди без гроша в кармане экспериментируют, и редкие стартапы (вроде No Man's Sky был стартапом, в него вложили тонны бабла, ожидая переворот в играх).
Собственно поэтому никто особо идеи не ворует. Скопировать успешную игру - это одно, а реализация фантазий форумного дрочера - слишком рискованно. Очень сложно доказать, что какая-то идея принесёт прибыль, если она ни на что не похожа - чаще всего оригинальные идеи проваливаются.
>юристы зассут связываться
Порноигры с Лунтиком и Барбоскиными удаляют с западных сайтов по запросу правообладателя из РФ.
>ассоциировали бренд с порнографией
В интернете все знают правило номер 34.
>>10729
>SCP
Они много лет боролись с каким-то российским кабанчиком, который пытался их прикрыть на основании получения им торговой марки SCP...
>>10727
>Разве у этого есть живые фанаты?
Двачую, персонажи средних веков нинужны.
>>похожую на что-то
>смотрите я игру про ваших персонажей сделал
В порноиграх часто бывают визуально похожие персонажи, так, что юрист не прикопаются, но фанат может быть вполне доволен. Что-то уровня смены имени, цвета волос и глаз, деталей одежды и т.п.
Вообще, думаю, можно закосить под AU:
https://en.wikipedia.org/wiki/Alternative_universe_(fan_fiction)
>>10717
>копировать геймплей
Это называется "клон" и таких игр 99%, при том чем крупнее бюджет игры, тем вероятнее, что это клон, потому что клон менее рискованный. Только инди без гроша в кармане экспериментируют, и редкие стартапы (вроде No Man's Sky был стартапом, в него вложили тонны бабла, ожидая переворот в играх).
Собственно поэтому никто особо идеи не ворует. Скопировать успешную игру - это одно, а реализация фантазий форумного дрочера - слишком рискованно. Очень сложно доказать, что какая-то идея принесёт прибыль, если она ни на что не похожа - чаще всего оригинальные идеи проваливаются.
>>10734
Я думаю, лучше так:
1. Загрузчик загружает сцену по требованию.
2. Перед показом сцены он передаёт ей состояние.
3. Скрипты сцены сами разбирают, что им надо.
4. Загрузчик вставляет сцену в дерево сцены.
...
5. Сцена меняет состояние в процессе геймплея.
...
6. Перед выгрузкой, загрузчик берёт её состояние.
Таким образом:
- сцена не зависит от внешних сущностей;
- сцена не имеет доступа к чужим данным;
- загрузчик не копается в деталях сцены;
- можно избежать лишних автолоадов.
>При каждой загрузке уровня дверь в onready спрашивает этот автолоад про состояние двери и выставляет нужное.
Я думаю, лучше так:
1. Загрузчик загружает сцену по требованию.
2. Перед показом сцены он передаёт ей состояние.
3. Скрипты сцены сами разбирают, что им надо.
4. Загрузчик вставляет сцену в дерево сцены.
...
5. Сцена меняет состояние в процессе геймплея.
...
6. Перед выгрузкой, загрузчик берёт её состояние.
Таким образом:
- сцена не зависит от внешних сущностей;
- сцена не имеет доступа к чужим данным;
- загрузчик не копается в деталях сцены;
- можно избежать лишних автолоадов.
>>10684 >>10536 >>10355 >>10349 etc.
Развели, блять, цирк.
В игровых вычислениях всё элементарно. У нас есть время кадра 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.
Ровно то же самое происходит и на движущейся платформе, и в сиське у бегущей тянки.
>>10684 >>10536 >>10355 >>10349 etc.
Развели, блять, цирк.
В игровых вычислениях всё элементарно. У нас есть время кадра 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.
Ровно то же самое происходит и на движущейся платформе, и в сиське у бегущей тянки.
775 Кб, 800x800>>07152 (OP)
Треды так быстро сменяют друг друга, у меня уже заканчиваются годные картинки для переката. Такая уже была или ещё нет? В оригинале справа Samsung, вообще не в тему и криво прилеплена - отрезал.
Серьёзно, этот тред всего две недели продержался.
Треды так быстро сменяют друг друга, у меня уже заканчиваются годные картинки для переката. Такая уже была или ещё нет? В оригинале справа Samsung, вообще не в тему и криво прилеплена - отрезал.
Серьёзно, этот тред всего две недели продержался.
>>10745
Потому что тут физику обсуждают
Потому что тут физику обсуждают
>>10744
Проебал форматирование - инвалидировал свое мнение, сорян.
Проебал форматирование - инвалидировал свое мнение, сорян.
>>10745
Тут какой то контекст неправильный. Будто мужик шел с какой-то другой девочкой. Мы же сразу верны Годетте.
Тут какой то контекст неправильный. Будто мужик шел с какой-то другой девочкой. Мы же сразу верны Годетте.
>>10745
Генерируй нейросетью, 2к24 год на дворе.
Генерируй нейросетью, 2к24 год на дворе.
>>10744
Ньюфаг не палится.
>>10743
Удачи запросить у физического движка все силы, которыми он там воздействует на ригидбоди. Или узнать все силы, которые могут возникать от разных источников в твоём собственном коде.
Изначально речь шла о симуляции RigidBody3D в физическом движке, чтобы минимизировать количество велосипедов в своём коде.
Никто не спорит, что на своём велосипеде делай что хочешь без проблем, только это совсем другая тема.
Тогда тут вообще физика не нужна. Речь о 3D физике, где на автобус могут действовать десятки сил из разных источников, о которых твой код знать не должен, иначе будет высокая связность.
Как ты это определишь, не зная ускорения? У тебя под ногами платформа, но ты не знаешь, какие силы на неё действуют. Только масса и скорость.
>макаба сожрала звёздочки
Ньюфаг не палится.
>>10743
>for force in all_forces:
Удачи запросить у физического движка все силы, которыми он там воздействует на ригидбоди. Или узнать все силы, которые могут возникать от разных источников в твоём собственном коде.
>velocity += acceleration × delta
>position += velocity × delta
Изначально речь шла о симуляции RigidBody3D в физическом движке, чтобы минимизировать количество велосипедов в своём коде.
Никто не спорит, что на своём велосипеде делай что хочешь без проблем, только это совсем другая тема.
>Возьмём модель одномерного автобуса в вакууме. Модель упрощённая
Тогда тут вообще физика не нужна. Речь о 3D физике, где на автобус могут действовать десятки сил из разных источников, о которых твой код знать не должен, иначе будет высокая связность.
>Пассажир с массой m испытывает силу F, передаваемую ему от автобуса.
Как ты это определишь, не зная ускорения? У тебя под ногами платформа, но ты не знаешь, какие силы на неё действуют. Только масса и скорость.
>>10749
Это в свете недавних событий. Но чтобы не возбуждать движкосрач, другая девочка вне кадра.
Ну, тут не поспоришь.
>Будто мужик шел с какой-то другой девочкой.
Это в свете недавних событий. Но чтобы не возбуждать движкосрач, другая девочка вне кадра.
>Мы же сразу верны Годетте.
Ну, тут не поспоришь.
>>10751
Эээ, перепутал, высокое зацепление.
Связность - внутри модуля.
Зацепление - между модулями.
В хорошем коде высокая связность и слабое зацепление, в плохом коде всё наоборот.
>из разных источников, о которых твой код знать не должен, иначе будет высокая связность
Эээ, перепутал, высокое зацепление.
Связность - внутри модуля.
Зацепление - между модулями.
В хорошем коде высокая связность и слабое зацепление, в плохом коде всё наоборот.
>>10743
Кстати ты тут походя доказал что ускорение это не сила.
Потому что они в разных половинах уравнения.
И хоть они пропорциональны, это не одно и то же. Как не одно и то же напряжение и сила тока, или давление и температура.
Можно еще показать через коэффициент массы.
Если у нас два идентичных ускорения, но у одного тела полмассы, то результаты разные - сила и полсилы. Так что это две уникальных сущности, а не одна.
А тот анон просто играл на том, что непонятно, что является первичным, что производит что - сила ускорение, или ускорение силу. А потом это накладывается на факт, что ИРЛ есть инерция, а в симулируемом мире ее нет, каждый кадр тело начинает со скоростью 0, пока программист (игры или движка) прямым действием не прибавит текущую скорость, то есть не действует 1-й закон Ньютона.
Кстати ты тут походя доказал что ускорение это не сила.
Потому что они в разных половинах уравнения.
И хоть они пропорциональны, это не одно и то же. Как не одно и то же напряжение и сила тока, или давление и температура.
Можно еще показать через коэффициент массы.
Если у нас два идентичных ускорения, но у одного тела полмассы, то результаты разные - сила и полсилы. Так что это две уникальных сущности, а не одна.
А тот анон просто играл на том, что непонятно, что является первичным, что производит что - сила ускорение, или ускорение силу. А потом это накладывается на факт, что ИРЛ есть инерция, а в симулируемом мире ее нет, каждый кадр тело начинает со скоростью 0, пока программист (игры или движка) прямым действием не прибавит текущую скорость, то есть не действует 1-й закон Ньютона.
>>10753
С пистолетом модная.
С пистолетом модная.
>>10755
Чаво? Просто не делай velocity = Vector3.ZERO.
Наоборот, добавить сопротивление воздуха или поверхностей сложнее, чем сделать инерцию, что есть по умолчанию (не обнуляешь переменную).
>ИРЛ есть инерция, а в симулируемом мире ее нет, каждый кадр тело начинает со скоростью 0
Чаво? Просто не делай velocity = Vector3.ZERO.
Наоборот, добавить сопротивление воздуха или поверхностей сложнее, чем сделать инерцию, что есть по умолчанию (не обнуляешь переменную).
Кто заметил, что в "каталоге" картинка сплюснута?
>>10759
Задавай здесь. Какая разница, где? Потом можешь репост сделать, если нужно будет.
>перекатывайте, у меня вопрос горит
Задавай здесь. Какая разница, где? Потом можешь репост сделать, если нужно будет.
>>10729
Есть еще вариант если автор не сильно против. Ни на что не намекаю, но например Zun давал разрешение выпускать фанатские игры по Touhou вот например платная с кучей отзывов https://store.steampowered.com/app/745880/Touhou_Tenkuushou__Hidden_Star_in_Four_Seasons/
Есть еще вариант если автор не сильно против. Ни на что не намекаю, но например Zun давал разрешение выпускать фанатские игры по Touhou вот например платная с кучей отзывов https://store.steampowered.com/app/745880/Touhou_Tenkuushou__Hidden_Star_in_Four_Seasons/
>>10784
Бессмысленный опрос как ему и написали
У многих по 2 языка, например GDscript/Godot Editor + C++/VScodium
Бессмысленный опрос как ему и написали
У многих по 2 языка, например GDscript/Godot Editor + C++/VScodium
>>10742
Да, тоже неплохой подход. Я скорее всего буду делать что-то среднее между тем и тем.
Еще мне интересно как сделать менеджер неписей, неписи-то не прибиты гвоздями к сцене, в зависимости от фазы дня или фазы игры они прыгают между локациями (днем нпс в одной локации, вечером в другой, ночью недоступен).
Пока что придумал только самое простое лобовое решение - храним глобально в виде (id нпс, сцена где он стоит, координаты), при загрузке сцены отбираем тех кто нужен в этой сцене и расставляем их. Явных подводные камней не вижу
Вообще интересно как эта все эти системы сделаны в играх беседки
Да, тоже неплохой подход. Я скорее всего буду делать что-то среднее между тем и тем.
Еще мне интересно как сделать менеджер неписей, неписи-то не прибиты гвоздями к сцене, в зависимости от фазы дня или фазы игры они прыгают между локациями (днем нпс в одной локации, вечером в другой, ночью недоступен).
Пока что придумал только самое простое лобовое решение - храним глобально в виде (id нпс, сцена где он стоит, координаты), при загрузке сцены отбираем тех кто нужен в этой сцене и расставляем их. Явных подводные камней не вижу
Вообще интересно как эта все эти системы сделаны в играх беседки
>>10786
Очень показательный опрос. Люди выбирают ближайшее, и как мы видим ближайшее это Godot+GDScript. Впрочем, будь опрос таким как ты хотел бы, там был бы похожий результат. От шарпистов просто шуму много, поскольку беженцы с юнити и все еще осваиваются.
Очень показательный опрос. Люди выбирают ближайшее, и как мы видим ближайшее это Godot+GDScript. Впрочем, будь опрос таким как ты хотел бы, там был бы похожий результат. От шарпистов просто шуму много, поскольку беженцы с юнити и все еще осваиваются.
>>10751
Все не получится, но можно их сумму - applied_force для тройки, constant_force для четвёрки. А это просто пример на случай, если ты сам пытаешься обрабатывать физику и хочешь применить к телу несколько сил, то вот так их считать.
Кстати, лучше сначала просуммировать все силы, а потом делить на массу, тут я прошляпил.
Какая разница-то? Векторы они хоть 196883-мерном пространстве векторы.
Третий закон Ньютона.
>>10755
Второй закон Ньютона.
Первый закон Ньютона.
Мне кажется, тут кое-кому следует подтянуть знания по физике за 7 класс.
>запросить у физического движка все силы,
Все не получится, но можно их сумму - applied_force для тройки, constant_force для четвёрки. А это просто пример на случай, если ты сам пытаешься обрабатывать физику и хочешь применить к телу несколько сил, то вот так их считать.
Кстати, лучше сначала просуммировать все силы, а потом делить на массу, тут я прошляпил.
>Тогда тут вообще физика не нужна. Речь о 3D физике
Какая разница-то? Векторы они хоть 196883-мерном пространстве векторы.
>Как ты это определишь, не зная ускорения?
Третий закон Ньютона.
>>10755
>Кстати ты тут походя доказал что ускорение это не сила
Второй закон Ньютона.
>инерция
Первый закон Ньютона.
Мне кажется, тут кое-кому следует подтянуть знания по физике за 7 класс.
>>10755
Вот смотри. Вариант 1:
Вариант 2:
Вроде бы одно и то же, но есть нюанс. В первом варианте инерция есть, а во втором её нет.
>ИРЛ есть инерция, а в симулируемом мире ее нет
Вот смотри. Вариант 1:
>var velocity = Vector3.ZERO
>func _physics_process(delta):
Вариант 2:
>func _physics_process(delta):
>var velocity = Vector3.ZERO
Вроде бы одно и то же, но есть нюанс. В первом варианте инерция есть, а во втором её нет.
>>10793
Не кажется. Тебе. Перечитывай до просветления ту часть поста, где говорится про пропорциональность, а не идентичность.
F = ma
1 = 1x1
2 = 2x1
Ускорение одинаковое, милы разные => сила не эквивалентно ускорение.
Есои и такой пример для тебя сложен, то вот тебе пример попроще
Расстояние это время на скорость
d = t*s
По твоей логике, расстояние это скорость, потому что они находятся в тех же позициях в формуле, что и сила с ускорением.
Еще раз для закрепления надо?
Если А зависит от В, не означает, что А является В.
> Мне кажется, тут кое-кому следует подтянуть знания по физике за 7 класс.
Не кажется. Тебе. Перечитывай до просветления ту часть поста, где говорится про пропорциональность, а не идентичность.
F = ma
1 = 1x1
2 = 2x1
Ускорение одинаковое, милы разные => сила не эквивалентно ускорение.
Есои и такой пример для тебя сложен, то вот тебе пример попроще
Расстояние это время на скорость
d = t*s
По твоей логике, расстояние это скорость, потому что они находятся в тех же позициях в формуле, что и сила с ускорением.
Еще раз для закрепления надо?
Если А зависит от В, не означает, что А является В.
>>10802
Это гододик возбудился и решил доказать что он не петушконикс с отсутствующими знаниями за 8 класс, засрав тред этим бесконечным бредом. Он шизик просто. Настолько шизик что не может в голове удерживать Ньютоновскую механику.
Имелось ввиду что для игровых движков обычно ускорение не нужно. Т.е. ускорение = сила для игровых движков, потому что зачем вообще искать ускорение, если оно нигде не используется? Во всех задачах где нужно ускорение, для какого-то конечного значения, есть своя формула вычисления этого конечного значения, потому что всегда есть какая-то сила компенсации всех сил которые действуют на объект. А ускорение? Нахуй не нужно.
Это настолько просто и понятно что даже хуан сделал всё правильно, а гододик до сих пор не понял. Жалкий шизик засирающий всё вокруг.
> ты споришь с воображаемыми собеседниками, которые говорят тебе, что ускорение и сила это одно и то же
Это гододик возбудился и решил доказать что он не петушконикс с отсутствующими знаниями за 8 класс, засрав тред этим бесконечным бредом. Он шизик просто. Настолько шизик что не может в голове удерживать Ньютоновскую механику.
Имелось ввиду что для игровых движков обычно ускорение не нужно. Т.е. ускорение = сила для игровых движков, потому что зачем вообще искать ускорение, если оно нигде не используется? Во всех задачах где нужно ускорение, для какого-то конечного значения, есть своя формула вычисления этого конечного значения, потому что всегда есть какая-то сила компенсации всех сил которые действуют на объект. А ускорение? Нахуй не нужно.
Это настолько просто и понятно что даже хуан сделал всё правильно, а гододик до сих пор не понял. Жалкий шизик засирающий всё вокруг.
>>10742
Типо на каждом сохраняемом объекте должен быть свой скрипт, который подтянет состояние? А если таких объектов 300? А если потом структуру сохранения как-то изменить понадобится, в каждом из 300 тоже менять?
Типо на каждом сохраняемом объекте должен быть свой скрипт, который подтянет состояние? А если таких объектов 300? А если потом структуру сохранения как-то изменить понадобится, в каждом из 300 тоже менять?
Вопрос утонет т.к. перекатят по закону подлости, но похуй.
Щас одну игорю переделываю на Годот 4.1, в оригинале есть диалоги и они составляют чуть-ли не 75% игры(можете угадать что за игра т.к. я уже светился тут со своим говном), я забил на них хуйца и первым делом решил воссоздать базу, база готова, теперь надо диалоговую систему, А ЕЁ НЕТ БЛЯ! Всякие диалогиги и прочее хуй дождёшься, я начал проект 3 месяца назад, а его всё ещё не портировали под 4.1, в итоге вштал вопрос: а чё юзать-то? Требуется прям диалоговая система для ВН, а не тупо вывод текста в коробочку, есть что-то похожее? А может мб кто-то даже диалогик к 4.1 смог пришаманить и поделится плагином/фиксами?
Щас одну игорю переделываю на Годот 4.1, в оригинале есть диалоги и они составляют чуть-ли не 75% игры(можете угадать что за игра т.к. я уже светился тут со своим говном), я забил на них хуйца и первым делом решил воссоздать базу, база готова, теперь надо диалоговую систему, А ЕЁ НЕТ БЛЯ! Всякие диалогиги и прочее хуй дождёшься, я начал проект 3 месяца назад, а его всё ещё не портировали под 4.1, в итоге вштал вопрос: а чё юзать-то? Требуется прям диалоговая система для ВН, а не тупо вывод текста в коробочку, есть что-то похожее? А может мб кто-то даже диалогик к 4.1 смог пришаманить и поделится плагином/фиксами?
>>10826
Наверняка есть другие аспекты игоря, которыми ты можешь заняться пока диалоги допиливают.
Но вроде альтернатив диалогика хватало. Поищи в ассетах.
Наверняка есть другие аспекты игоря, которыми ты можешь заняться пока диалоги допиливают.
Но вроде альтернатив диалогика хватало. Поищи в ассетах.
>>10826
Диалоджик работает на 4.1 нормально.
Диалоджик работает на 4.1 нормально.
>>10826
Ты наверное ставил из мертвого ассет либрари.
Вот настоящий диалоджик, для 4
https://github.com/coppolaemilio/dialogic
>А может мб кто-то даже диалогик к 4.1 смог пришаманить и поделится плагином/фиксами?
Ты наверное ставил из мертвого ассет либрари.
Вот настоящий диалоджик, для 4
https://github.com/coppolaemilio/dialogic
>>10802
Я отвечал тебе, потому что ты начал спорить тут
Раз ты возразил, значит поддерживал противоположенную точку зрения. Рад, что уладили это недопонимание.
>>10814
Иди читать школьный учебник. Они не всегда равны, потому что в формуле участвует еще и m.
Я отвечал тебе, потому что ты начал спорить тут
> >Кстати ты тут походя доказал что ускорение это не сила
> Второй закон Ньютона.
Раз ты возразил, значит поддерживал противоположенную точку зрения. Рад, что уладили это недопонимание.
>>10814
> ускорение = сила
Иди читать школьный учебник. Они не всегда равны, потому что в формуле участвует еще и m.
>>10856
Шизик-гододя-оопешка опять за своё. Ему говорят читать учебник школьной физики уже несколько анонов - он в ответ перефорс толкает "НЕТ ВЫЫ!!!111". Какое же поехавшее......
И что? Ускорение от этого не появляется, шизло. Единственно что в объект приходит, т.е. воздействует, это сила.
>Иди читать школьный учебник.
Шизик-гододя-оопешка опять за своё. Ему говорят читать учебник школьной физики уже несколько анонов - он в ответ перефорс толкает "НЕТ ВЫЫ!!!111". Какое же поехавшее......
> Они не всегда равны, потому что в формуле участвует еще и m.
И что? Ускорение от этого не появляется, шизло. Единственно что в объект приходит, т.е. воздействует, это сила.
455 Кб, 850x1164Кому тут Годетты не хватало для переката?
Давай перекат уже, вопросы назрели!
У меня тоже вопрос встал.
>>10814
Ну, скажем так. Я знаю как минимум одно ускорение, которое нужно и которое точно не сила. Ускорение свободного падения.
Обычно так. Ускорение нужно безмассовому кинематику; сила - массивному ригиду.
И во всех случаях следует помнить, что игра призвана дарить эмоции через геймплей, а не дотошно воспроизводить реальный мир.
>>10891
Этшто, бунд? Считать ли такой перекат легитимным? Ну, Годетта няшная, канеш.
>для игровых движков обычно ускорение не нужно
Ну, скажем так. Я знаю как минимум одно ускорение, которое нужно и которое точно не сила. Ускорение свободного падения.
Обычно так. Ускорение нужно безмассовому кинематику; сила - массивному ригиду.
И во всех случаях следует помнить, что игра призвана дарить эмоции через геймплей, а не дотошно воспроизводить реальный мир.
>>10891
Этшто, бунд? Считать ли такой перекат легитимным? Ну, Годетта няшная, канеш.
>>10905
Нет конечно, ни на что не претендую, прост не хотелось чтобы мои вопросики смыло перекатом.
>Считать ли такой перекат легитимным?
Нет конечно, ни на что не претендую, прост не хотелось чтобы мои вопросики смыло перекатом.
Обновить тред