Этого треда уже нет.
Это копия, сохраненная 22 апреля 2022 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Это копия, сохраненная 22 апреля 2022 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
1,5 Мб, 1700x1700Добро пожаловать в тред любви, взаимопомощи и форматирования отступами!
Ссылки
Скачать движок: https://godotengine.org/download/ или http://store.steampowered.com/app/404790/Godot_Engine/
FAQ: https://docs.godotengine.org/ru/latest/about/faq.html
Документация: https://docs.godotengine.org/ru/latest/ https://docs.godotengine.org/en/stable/
Примеры качаются прямо в движке через свой магазин в отдельной вкладке AssetLib. Там есть всё - от платформера до чата.
Игры, созданные глобальными кириллами: https://steamcommunity.com/app/404790/discussions/0/412448792354265655/
Изумительный Годот: https://github.com/Calinou/awesome-godot - подборка дополнений, модулей и минишоукейс от одного из авторов.
Годнота от анона
- Для приверженцев опенсорца существует возможность распространять проекты в незапакованном формате. Просто скачай темплейт с оф.сайта и положи экзешник/эльфешник в папку с проектом, этого достаточно. Дополнительно можешь вшить свою иконку в экзешник. После этого, запустившийся файл темплейта обнаружит рядом с собой файл project.godot и начнет грузить проект из него и из файлов, лежащих в распакованном виде в той же директории.
- В версии 3.2 появилась возможность прикреплять pck к бинарнику. Бриллиант для любителей однофайлового продукта!
- Редактор персонажей на основе makehuman: https://github.com/Lexpartizan/Go_MakeHuman_dot
- Тест-бенчмарк:
- - Веб-версия - https://govdot.herokuapp.com
- - Вишмастер для винды - https://govdot.herokuapp.com/4Anon.rar
Предыдущий тонет там: >>681839 (OP)
Архивы:
1 https://arhivach.ng/thread/207802/
2 https://arhivach.ng/thread/388500/
3 https://arhivach.ng/thread/388501/
4 https://arhivach.ng/thread/388502/
5 https://arhivach.ng/thread/388503/
6 https://arhivach.ng/thread/432708/
7 https://arhivach.ng/thread/433902/
8 https://arhivach.ng/thread/436355/
9 https://arhivach.ng/thread/455461/
10 https://arhivach.ng/thread/479963/
11 https://arhivach.ng/thread/489815/
12 https://arhivach.ng/thread/494513/
13 https://arhivach.ng/thread/515567/
14 https://arhivach.ng/thread/533171/
15 https://arhivach.ng/thread/555441/
16 https://arhivach.ng/thread/592945/
17 https://arhivach.ng/thread/592946/
Ссылки
Скачать движок: https://godotengine.org/download/ или http://store.steampowered.com/app/404790/Godot_Engine/
FAQ: https://docs.godotengine.org/ru/latest/about/faq.html
Документация: https://docs.godotengine.org/ru/latest/ https://docs.godotengine.org/en/stable/
Примеры качаются прямо в движке через свой магазин в отдельной вкладке AssetLib. Там есть всё - от платформера до чата.
Игры, созданные глобальными кириллами: https://steamcommunity.com/app/404790/discussions/0/412448792354265655/
Изумительный Годот: https://github.com/Calinou/awesome-godot - подборка дополнений, модулей и минишоукейс от одного из авторов.
Годнота от анона
- Для приверженцев опенсорца существует возможность распространять проекты в незапакованном формате. Просто скачай темплейт с оф.сайта и положи экзешник/эльфешник в папку с проектом, этого достаточно. Дополнительно можешь вшить свою иконку в экзешник. После этого, запустившийся файл темплейта обнаружит рядом с собой файл project.godot и начнет грузить проект из него и из файлов, лежащих в распакованном виде в той же директории.
- В версии 3.2 появилась возможность прикреплять pck к бинарнику. Бриллиант для любителей однофайлового продукта!
- Редактор персонажей на основе makehuman: https://github.com/Lexpartizan/Go_MakeHuman_dot
- Тест-бенчмарк:
- - Веб-версия - https://govdot.herokuapp.com
- - Вишмастер для винды - https://govdot.herokuapp.com/4Anon.rar
Предыдущий тонет там: >>681839 (OP)
Архивы:
1 https://arhivach.ng/thread/207802/
2 https://arhivach.ng/thread/388500/
3 https://arhivach.ng/thread/388501/
4 https://arhivach.ng/thread/388502/
5 https://arhivach.ng/thread/388503/
6 https://arhivach.ng/thread/432708/
7 https://arhivach.ng/thread/433902/
8 https://arhivach.ng/thread/436355/
9 https://arhivach.ng/thread/455461/
10 https://arhivach.ng/thread/479963/
11 https://arhivach.ng/thread/489815/
12 https://arhivach.ng/thread/494513/
13 https://arhivach.ng/thread/515567/
14 https://arhivach.ng/thread/533171/
15 https://arhivach.ng/thread/555441/
16 https://arhivach.ng/thread/592945/
17 https://arhivach.ng/thread/592946/
>>698054 (OP)
Кстати на TWG не сработало, некогда было разбираться почему.
> В версии 3.2 появилась возможность прикреплять pck к бинарнику. Бриллиант для любителей однофайлового продукта!
Кстати на TWG не сработало, некогда было разбираться почему.
>>698077
Нет, винда. Мне даже кажется один раз запустилось, но больше ни разу, и ни у кого.
Нет, винда. Мне даже кажется один раз запустилось, но больше ни разу, и ни у кого.
>>698100
А куда делся двач в 2009?
А куда делся двач в 2009?
Ебашу сейчас стейтмашину на гдскрипт. Почувствовал, что доразвился до реализации собственной стейтмашины. Состоит она из трёх классов:
1. собственно сама машина (FSM)
2. класс-состояние (state)
3. класс-передача (transition)
Все классы наследуются от Reference, то есть, это не ноды и не могут входить в дерево сцены. И разумеется, у них нет коллбэков к мэйнлупу.
Машина содержит в себе массив состояний и массив передач.
Передача содержит в себе ссылки на состояние-откуда и состояние-куда.
Класс-состояние содержит в себе функции start, stop и update. Состояние это базовый класс с пустыми функциями, в си, это был бы абстрактный класс, требующий наследовать от него специализированных потомков с реализацией этих функций.
Алгоритм работы таков. У машины есть своя функция update, которая пробегает по массиву состояний, чекает у них внутреннюю переменную mode которая enum { Active, Idle } и у найденных активных выполняет их функцию update.
Каждая передача создаётся с обязательным указанием ссылок на состояния, и при своём создании подписывается на их сигналы activated и finished, которые сигналы излучают при переходе из режима в режим. Соответственно, при переходе состояния в idle состояние излучает finished и если в какой либо из передач оно указано состоянием-откуда, оно активирует эту передачу, а она активирует состояние-куда согласно своему режиму либо сразу, либо ждёт, когда то состояние будет idle. Можно запрограммировать машину так, что из одного состояния будет выходить несколько передач к другим состояниям, активируя их одновременно. Это несколько расходится с классическим определением конечного автомата, который должен иметь одно активное состояние в единицу времени, но звучит интригующе.
Я предполагаю использовать данную машину, объявляя её переменной, а затем вручную вызывая у неё update там, где мне надо, когда по таймеру, когда в _process.
Программирование машины пока что предполагается из кода, без каких бы то ни было визуальных компонентов. Создаются состояния-потомки, реализующие требуемый функционал. Объявляется машина, объявляются состояния, в машину специальной функцией добавляются передачи вместе с состояниями. Стартовому состоянию выставляется режим Active и начинает вызываться update из машины, как описано выше, по требованию.
Если всё получится, то следующим шагом прикручу конфигурирование из текстового конфига.
В чём вопрос? Спросишь ты. Этот пост скорее минидиздок для себя, чтобы собрать мысли в кучу.
1. собственно сама машина (FSM)
2. класс-состояние (state)
3. класс-передача (transition)
Все классы наследуются от Reference, то есть, это не ноды и не могут входить в дерево сцены. И разумеется, у них нет коллбэков к мэйнлупу.
Машина содержит в себе массив состояний и массив передач.
Передача содержит в себе ссылки на состояние-откуда и состояние-куда.
Класс-состояние содержит в себе функции start, stop и update. Состояние это базовый класс с пустыми функциями, в си, это был бы абстрактный класс, требующий наследовать от него специализированных потомков с реализацией этих функций.
Алгоритм работы таков. У машины есть своя функция update, которая пробегает по массиву состояний, чекает у них внутреннюю переменную mode которая enum { Active, Idle } и у найденных активных выполняет их функцию update.
Каждая передача создаётся с обязательным указанием ссылок на состояния, и при своём создании подписывается на их сигналы activated и finished, которые сигналы излучают при переходе из режима в режим. Соответственно, при переходе состояния в idle состояние излучает finished и если в какой либо из передач оно указано состоянием-откуда, оно активирует эту передачу, а она активирует состояние-куда согласно своему режиму либо сразу, либо ждёт, когда то состояние будет idle. Можно запрограммировать машину так, что из одного состояния будет выходить несколько передач к другим состояниям, активируя их одновременно. Это несколько расходится с классическим определением конечного автомата, который должен иметь одно активное состояние в единицу времени, но звучит интригующе.
Я предполагаю использовать данную машину, объявляя её переменной, а затем вручную вызывая у неё update там, где мне надо, когда по таймеру, когда в _process.
Программирование машины пока что предполагается из кода, без каких бы то ни было визуальных компонентов. Создаются состояния-потомки, реализующие требуемый функционал. Объявляется машина, объявляются состояния, в машину специальной функцией добавляются передачи вместе с состояниями. Стартовому состоянию выставляется режим Active и начинает вызываться update из машины, как описано выше, по требованию.
Если всё получится, то следующим шагом прикручу конфигурирование из текстового конфига.
В чём вопрос? Спросишь ты. Этот пост скорее минидиздок для себя, чтобы собрать мысли в кучу.
Ебашу сейчас стейтмашину на гдскрипт. Почувствовал, что доразвился до реализации собственной стейтмашины. Состоит она из трёх классов:
1. собственно сама машина (FSM)
2. класс-состояние (state)
3. класс-передача (transition)
Все классы наследуются от Reference, то есть, это не ноды и не могут входить в дерево сцены. И разумеется, у них нет коллбэков к мэйнлупу.
Машина содержит в себе массив состояний и массив передач.
Передача содержит в себе ссылки на состояние-откуда и состояние-куда.
Класс-состояние содержит в себе функции start, stop и update. Состояние это базовый класс с пустыми функциями, в си, это был бы абстрактный класс, требующий наследовать от него специализированных потомков с реализацией этих функций.
Алгоритм работы таков. У машины есть своя функция update, которая пробегает по массиву состояний, чекает у них внутреннюю переменную mode которая enum { Active, Idle } и у найденных активных выполняет их функцию update.
Каждая передача создаётся с обязательным указанием ссылок на состояния, и при своём создании подписывается на их сигналы activated и finished, которые сигналы излучают при переходе из режима в режим. Соответственно, при переходе состояния в idle состояние излучает finished и если в какой либо из передач оно указано состоянием-откуда, оно активирует эту передачу, а она активирует состояние-куда согласно своему режиму либо сразу, либо ждёт, когда то состояние будет idle. Можно запрограммировать машину так, что из одного состояния будет выходить несколько передач к другим состояниям, активируя их одновременно. Это несколько расходится с классическим определением конечного автомата, который должен иметь одно активное состояние в единицу времени, но звучит интригующе.
Я предполагаю использовать данную машину, объявляя её переменной, а затем вручную вызывая у неё update там, где мне надо, когда по таймеру, когда в _process.
Программирование машины пока что предполагается из кода, без каких бы то ни было визуальных компонентов. Создаются состояния-потомки, реализующие требуемый функционал. Объявляется машина, объявляются состояния, в машину специальной функцией добавляются передачи вместе с состояниями. Стартовому состоянию выставляется режим Active и начинает вызываться update из машины, как описано выше, по требованию.
Если всё получится, то следующим шагом прикручу конфигурирование из текстового конфига.
В чём вопрос? Спросишь ты. Этот пост скорее минидиздок для себя, чтобы собрать мысли в кучу.
1. собственно сама машина (FSM)
2. класс-состояние (state)
3. класс-передача (transition)
Все классы наследуются от Reference, то есть, это не ноды и не могут входить в дерево сцены. И разумеется, у них нет коллбэков к мэйнлупу.
Машина содержит в себе массив состояний и массив передач.
Передача содержит в себе ссылки на состояние-откуда и состояние-куда.
Класс-состояние содержит в себе функции start, stop и update. Состояние это базовый класс с пустыми функциями, в си, это был бы абстрактный класс, требующий наследовать от него специализированных потомков с реализацией этих функций.
Алгоритм работы таков. У машины есть своя функция update, которая пробегает по массиву состояний, чекает у них внутреннюю переменную mode которая enum { Active, Idle } и у найденных активных выполняет их функцию update.
Каждая передача создаётся с обязательным указанием ссылок на состояния, и при своём создании подписывается на их сигналы activated и finished, которые сигналы излучают при переходе из режима в режим. Соответственно, при переходе состояния в idle состояние излучает finished и если в какой либо из передач оно указано состоянием-откуда, оно активирует эту передачу, а она активирует состояние-куда согласно своему режиму либо сразу, либо ждёт, когда то состояние будет idle. Можно запрограммировать машину так, что из одного состояния будет выходить несколько передач к другим состояниям, активируя их одновременно. Это несколько расходится с классическим определением конечного автомата, который должен иметь одно активное состояние в единицу времени, но звучит интригующе.
Я предполагаю использовать данную машину, объявляя её переменной, а затем вручную вызывая у неё update там, где мне надо, когда по таймеру, когда в _process.
Программирование машины пока что предполагается из кода, без каких бы то ни было визуальных компонентов. Создаются состояния-потомки, реализующие требуемый функционал. Объявляется машина, объявляются состояния, в машину специальной функцией добавляются передачи вместе с состояниями. Стартовому состоянию выставляется режим Active и начинает вызываться update из машины, как описано выше, по требованию.
Если всё получится, то следующим шагом прикручу конфигурирование из текстового конфига.
В чём вопрос? Спросишь ты. Этот пост скорее минидиздок для себя, чтобы собрать мысли в кучу.
>>698115
И да, я не сильно вникал в твою писанину, но навскидку, вот это:
и вот, это:
выглядят, как крайне хреновые идеи.
-------
Это звучит так, что ты наебешься, когда будешь делать отладку этого франкенштейна. Не трахай себе мозг и делай отдельные стейтмашины.
И да, я не сильно вникал в твою писанину, но навскидку, вот это:
>которая пробегает по массиву состояний, чекает у них внутреннюю переменную mode которая enum { Active, Idle } и у найденных активных выполняет их функцию update.
и вот, это:
>Можно запрограммировать машину так, что из одного состояния будет выходить несколько передач к другим состояниям, активируя их одновременно.
выглядят, как крайне хреновые идеи.
-------
>Это несколько расходится с классическим определением конечного автомата, который должен иметь одно активное состояние в единицу времени, но звучит интригующе.
Это звучит так, что ты наебешься, когда будешь делать отладку этого франкенштейна. Не трахай себе мозг и делай отдельные стейтмашины.
>>698164
О, спасибо, а я вчера мучительно подбирал русскоязычный термин, так и не подобрал. Код универсален, можно и гонки на нём сделать.
>>698165
Ну а щито поделать, программирование не лишено некоторой доли мазохизма.
Алсо, всё заработало. Пикрелейтед. Доволен как слон. ЧСВ +10
О, спасибо, а я вчера мучительно подбирал русскоязычный термин, так и не подобрал. Код универсален, можно и гонки на нём сделать.
>>698165
> хреновые идеи
> наебешься
Ну а щито поделать, программирование не лишено некоторой доли мазохизма.
Алсо, всё заработало. Пикрелейтед. Доволен как слон. ЧСВ +10
>>698513
2d? 3d? Можно на физике, у rigibody тела можно создать физический материал, там есть bounciness. А само вращение можно задавать какими-то пропертями angular_... Но может быть без импульсов не обойтись будет.
Можно и без физики, просто обычный контроллер, только при движении спрайт/меш выставляешь на угол, пропорциональный пройденному расстоянию (чет там на пи поделить). Подпрыгивать, соответственно, так же как прыгают в обычном контроллере вычитая из .y и потом прибавляя гравитацию.
2d? 3d? Можно на физике, у rigibody тела можно создать физический материал, там есть bounciness. А само вращение можно задавать какими-то пропертями angular_... Но может быть без импульсов не обойтись будет.
Можно и без физики, просто обычный контроллер, только при движении спрайт/меш выставляешь на угол, пропорциональный пройденному расстоянию (чет там на пи поделить). Подпрыгивать, соответственно, так же как прыгают в обычном контроллере вычитая из .y и потом прибавляя гравитацию.
Общался с одним из представителей годототреда по поводу игры про иерархию карт. Прикладываю исходники моего говнокода.
https://dropmefiles.com/TWCLL
https://dropmefiles.com/TWCLL
30 Кб, 739x483>>698173
Чтобы эта машина не казалась абстрактным экспериментом, приведу пример использования, пиклелейтед класс-состояние, который при его достижении, управляет персонажем с клавиатуры. Можно активировать другие состояния, в которых персонаж управляется компом, в катсценках например, или использовать несколько типов управления (на земле, под водой, в полёте, и т.п.), или реализовать геймплей майнд-контроля, когда вашего персонажа контроллит лич, а вы судорожно стучите по клавише хила, чтобы управление вернулось.
> всё заработало
Чтобы эта машина не казалась абстрактным экспериментом, приведу пример использования, пиклелейтед класс-состояние, который при его достижении, управляет персонажем с клавиатуры. Можно активировать другие состояния, в которых персонаж управляется компом, в катсценках например, или использовать несколько типов управления (на земле, под водой, в полёте, и т.п.), или реализовать геймплей майнд-контроля, когда вашего персонажа контроллит лич, а вы судорожно стучите по клавише хила, чтобы управление вернулось.
>>698693
Да, я же говорю, тупо забомбил от того, что не могу карточки нормально по столу на рандоме расположить так, чтобы они не пересекались и перегорел, лол.
+ без понятия как сделать нормально кастомные вызовы функций с передачей туда параметров.
Да, я же говорю, тупо забомбил от того, что не могу карточки нормально по столу на рандоме расположить так, чтобы они не пересекались и перегорел, лол.
+ без понятия как сделать нормально кастомные вызовы функций с передачей туда параметров.
>>698831
Эмм, поподробнее здесь. Я вызывал кастомные параметрические методы несколькими способами. Чаще всего через встроенный механизм .call(), .callv()
> как сделать нормально кастомные вызовы функций с передачей туда параметров
Эмм, поподробнее здесь. Я вызывал кастомные параметрические методы несколькими способами. Чаще всего через встроенный механизм .call(), .callv()
>>698831
Я на твг делал карты на сигналах. Правда, толком не доделал. Идея простая - кому надо, тот на те сигналы и подписан. Например, карта может получить сигнал пора лететь в такую-то точку. Начинается анимация, когда анимация закончится, карта получит сигнал об окончании анимации и разошлет сигнал о том, что она на месте. В простых случаях вызывающий код просто ждал по yield(...). В сигнале можно передавать данные. Это может быть массив, или к примеру, словарь. [location:"лес", action:"мамку твою любил"]
Я на твг делал карты на сигналах. Правда, толком не доделал. Идея простая - кому надо, тот на те сигналы и подписан. Например, карта может получить сигнал пора лететь в такую-то точку. Начинается анимация, когда анимация закончится, карта получит сигнал об окончании анимации и разошлет сигнал о том, что она на месте. В простых случаях вызывающий код просто ждал по yield(...). В сигнале можно передавать данные. Это может быть массив, или к примеру, словарь. [location:"лес", action:"мамку твою любил"]
>>698863
Все верно. А теперь представим, что для части действий, которые должен сделать пользователь, ты должен передать урон этой же карте, другой, герою, печенью на столе. Меняется только объект. И вот это разделение говнокодом на matchс каким-нибудь текстом из жсона меня выбесило чето.
>>698878
Сигналы это круто,но я о другом.
Все верно. А теперь представим, что для части действий, которые должен сделать пользователь, ты должен передать урон этой же карте, другой, герою, печенью на столе. Меняется только объект. И вот это разделение говнокодом на matchс каким-нибудь текстом из жсона меня выбесило чето.
>>698878
Сигналы это круто,но я о другом.
>>698900
Анон выше верно заметил, это делается через сигналы.
Возможно, твоя задача более удобно решится через глобальные сигналы. Объясню: делаешь синглтон, в нём объявляешь сигналы. Излучает сигналы только этот синглтон. Объекты, когда им нужно, подписываются на глобальные сигналы своим коллбэком. После чего ты единожды излучив нужный сигнал (signal_hub.emit_signal make_damage(10), будешь уверен, что эта же карта, другая, герой, печенье на столе, обработают глобальный сигнал и нанесут себе урон.
> для части действий, которые должен сделать пользователь, ты должен передать урон этой же карте, другой, герою, печенью на столе
Анон выше верно заметил, это делается через сигналы.
> это разделение говнокодом на match с каким-нибудь текстом из жсона
Возможно, твоя задача более удобно решится через глобальные сигналы. Объясню: делаешь синглтон, в нём объявляешь сигналы. Излучает сигналы только этот синглтон. Объекты, когда им нужно, подписываются на глобальные сигналы своим коллбэком. После чего ты единожды излучив нужный сигнал (signal_hub.emit_signal make_damage(10), будешь уверен, что эта же карта, другая, герой, печенье на столе, обработают глобальный сигнал и нанесут себе урон.
32 Кб, 494x400>>698947
Вот например, у меня в одном из проектов было:
Вот например, у меня в одном из проектов было:
>>698947
Не нужны сигналы. У моего персонажа есть ссылка и на первую карту и на выбранную и на себя. Он вполне может агрегировать внутри себя эту логику. Да и сигналы много кушают, как бы они не были удобны. Нотификациями быстрее.
Не нужны сигналы. У моего персонажа есть ссылка и на первую карту и на выбранную и на себя. Он вполне может агрегировать внутри себя эту логику. Да и сигналы много кушают, как бы они не были удобны. Нотификациями быстрее.
>>698997
А ты куда то торопишься в карточной игре?
А ты куда то торопишься в карточной игре?
>>698997
Ничоси, какой внезапный хинт. Изучил вопрос и нашёл вот эту писечку:
https://github.com/didier-v/GodotNotificationCenter
Пойду щупать.
> Да и сигналы много кушают, как бы они не были удобны. Нотификациями быстрее.
Ничоси, какой внезапный хинт. Изучил вопрос и нашёл вот эту писечку:
https://github.com/didier-v/GodotNotificationCenter
Пойду щупать.
>>699179
Я уже сам разглядел. Да ещё и хуже, надо вручную дисконнектить. Я думал, этот код юзает встроенный механизм нотификаций, а это просто название в коде.
Я уже сам разглядел. Да ещё и хуже, надо вручную дисконнектить. Я думал, этот код юзает встроенный механизм нотификаций, а это просто название в коде.
>>699177
Вот ещё пример аналогичный (во втором ответе к вопросу):
https://godotengine.org/qa/10650/best-way-to-create-events-between-two-nodes
Вот ещё пример аналогичный (во втором ответе к вопросу):
https://godotengine.org/qa/10650/best-way-to-create-events-between-two-nodes
>>699181
На моём примере. У чувака есть 3 спелла. Первый юзается на себя, второй на героя, третий на комбо карту. Все что они делают - передают дамаг. Причем тут сигналы? Мне надо прокинуть верный референс без заеба, считав из жсона ноду.
На моём примере. У чувака есть 3 спелла. Первый юзается на себя, второй на героя, третий на комбо карту. Все что они делают - передают дамаг. Причем тут сигналы? Мне надо прокинуть верный референс без заеба, считав из жсона ноду.
>>699198
У тебя в проекте, который ты скидывал, это реализовано? Назови точное место. Я несколько раз туда заглядывал, но ничо нипонил.
У тебя в проекте, который ты скидывал, это реализовано? Назови точное место. Я несколько раз туда заглядывал, но ничо нипонил.
>>699198
Нирикаминдую такой подход, несмотря на то, что он показан в официальной документации (навскидку, в статье по сохранениям игор).
Моё мнение - игровые данные (которые считываются из текстовых жсон-файлов) должны быть отделены от внутренней логики движка. Это значит, что никаких нод и путей к нодам в жсон быть не должно. В терминологии жсон объект - это ассоциативный массив, который в терминологии годота - словарь. Вот единственное, что я сериализую и всем рекомендую. Приложения перекидываются между собой словарями. Этого необходимо и достаточно для подавляющего большинства задач.
Если же тебе для поднятия карты, нужно десериализовать ноду, сохранённую в жсон - это, по моему глубокому убеждению, ошибка архитектуры твоего проекта.
> считав из жсона ноду
Нирикаминдую такой подход, несмотря на то, что он показан в официальной документации (навскидку, в статье по сохранениям игор).
Моё мнение - игровые данные (которые считываются из текстовых жсон-файлов) должны быть отделены от внутренней логики движка. Это значит, что никаких нод и путей к нодам в жсон быть не должно. В терминологии жсон объект - это ассоциативный массив, который в терминологии годота - словарь. Вот единственное, что я сериализую и всем рекомендую. Приложения перекидываются между собой словарями. Этого необходимо и достаточно для подавляющего большинства задач.
Если же тебе для поднятия карты, нужно десериализовать ноду, сохранённую в жсон - это, по моему глубокому убеждению, ошибка архитектуры твоего проекта.
>>699210
Есть синглтон-персонаж. У него есть методы взаимодействия с миром. И вот каждая карточка спела несет в себе action_id, который является ссылкой в жссон на такой экшон. В будущем этот жсон сменится на бд. И он такой считывает жсон и вызывает то, что надо.
>>699215
Я знаю. И я по этому сгорел. Как указать одностроково в коде таргет который описан в скролле жсона, чтобы это могли быть разные таргеты. Не ясно.
Есть синглтон-персонаж. У него есть методы взаимодействия с миром. И вот каждая карточка спела несет в себе action_id, который является ссылкой в жссон на такой экшон. В будущем этот жсон сменится на бд. И он такой считывает жсон и вызывает то, что надо.
>>699215
Я знаю. И я по этому сгорел. Как указать одностроково в коде таргет который описан в скролле жсона, чтобы это могли быть разные таргеты. Не ясно.
>>699537
Подойдёт ли тебе метод Пети "Сканера" с ютуба? Он добавляет в проект единственный синглтон для глобальных вещей G - Global. В нём он заводит переменные для сущностей, которые должны быть видимы глобально, например var player : Node, а потом при загрузке сущности игрока, у неё в _ready пишется G.player = self
Но этот метод статичный, а у тебя, как я понимаю, таргеты будут динамически появляться и исчезать в течение игры, поэтому я бы попробовал завести словарь, но я подозреваю, что быстродействие такого решения будет медленнее, чем ранее посоветованный способ с сигналами. Потому что хоть хэш, хоть хуэш - поиск таргетов будет происходить по строковым ключам.
Я сам не уважаю этот модный молодёжный подход, когда части приложения обмениваются между собой строковыми идентификаторами. Как серпом по яйцам, когда вижу emit_signal("string_signal_name"). Зумеры уверяли меня неоднократно, что строки в современных средах исполнения хэшируются и их быстродействие якобы не отличается от именованных целочисленных констант. Но я во первых не проверял, а во вторых всё равно хочется emit_signal(INT_SIGNAL_CONSTANT)
Подойдёт ли тебе метод Пети "Сканера" с ютуба? Он добавляет в проект единственный синглтон для глобальных вещей G - Global. В нём он заводит переменные для сущностей, которые должны быть видимы глобально, например var player : Node, а потом при загрузке сущности игрока, у неё в _ready пишется G.player = self
Но этот метод статичный, а у тебя, как я понимаю, таргеты будут динамически появляться и исчезать в течение игры, поэтому я бы попробовал завести словарь, но я подозреваю, что быстродействие такого решения будет медленнее, чем ранее посоветованный способ с сигналами. Потому что хоть хэш, хоть хуэш - поиск таргетов будет происходить по строковым ключам.
Я сам не уважаю этот модный молодёжный подход, когда части приложения обмениваются между собой строковыми идентификаторами. Как серпом по яйцам, когда вижу emit_signal("string_signal_name"). Зумеры уверяли меня неоднократно, что строки в современных средах исполнения хэшируются и их быстродействие якобы не отличается от именованных целочисленных констант. Но я во первых не проверял, а во вторых всё равно хочется emit_signal(INT_SIGNAL_CONSTANT)
>>699556
Я хз, но я не нашел (может плохо искал) описания того как это реализовано в годоте. Зная гений Хуана, там вполне может быть обычная цепочка "ссылка-длина-побайтово"
>>699556
Но я во первых не проверял, а во вторых всё равно хочется emit_signal(INT_SIGNAL_CONSTANT)
Вот да, я бы тоже не отказался от возможности присваивать объектам обычные человеческие числовые статические ID
>Зумеры уверяли меня неоднократно, что строки в современных средах исполнения хэшируются и их быстродействие якобы не отличается от именованных целочисленных констант.
Я хз, но я не нашел (может плохо искал) описания того как это реализовано в годоте. Зная гений Хуана, там вполне может быть обычная цепочка "ссылка-длина-побайтово"
>>699556
Но я во первых не проверял, а во вторых всё равно хочется emit_signal(INT_SIGNAL_CONSTANT)
Вот да, я бы тоже не отказался от возможности присваивать объектам обычные человеческие числовые статические ID
>>699556
Жесть, как же это плохо выглядит.
>Подойдёт ли тебе метод Пети "Сканера" с ютуба? Он добавляет в проект единственный синглтон для глобальных вещей G - Global. В нём он заводит переменные для сущностей, которые должны быть видимы глобально, например var player : Node, а потом при загрузке сущности игрока, у неё в _ready пишется G.player = self
Жесть, как же это плохо выглядит.
>>699580
Вовсе да. Метод Пети жоска абузит принцип инкапсуляции. В глобальном объекте прямые ссылки на разные части программы. Какая уж тут инкапсуляция когда всем всё видно? Сначала возможность напрямую обращаться к игровому персу, неписям, сундукам на сцене выглядит заманчиво, но потом наступит путаница и пиздец. Неизбежно наступит путаница и обязательно придёт пиздец.
Гораздо корректнее выглядит описанный выше принцип глобальных сигналов.
Игровым объектам всё так же нужно у себя в _ready обращаться к глобальному объекту, но в этом случае они не оставляют там прямую ссылку на себя, а регистрируются на глобальные сигналы. Глобальный объект может дёргать эти сигналы, но ни он, ни другие объекты не могут обратиться к получателям сигналов напрямую.
Я настолько глубоко изучил данную тему, что даже научился возвращать данные с излученных сигналов. Просто регистрируешь сигнал с аргументом и следуешь соглашению о том, что аргументом должен быть словарь, в который все зарегистрированные на сигнал обработчики добавляют запись о результатах своей работы.
Например, в глобальном объекте:
signal query_something(query_result) #Пока что язык не позволяет задекларировать в аргументе статический тип, увы.
Далее, в объектах-обработчиках:
func _ready():
____G.connect("query_something", self, "process_query")
func process_query(byref_result : Dictionary):
____byref_result[self.name].data = "Задание принял сержант %s" % self.name
Вовсе да. Метод Пети жоска абузит принцип инкапсуляции. В глобальном объекте прямые ссылки на разные части программы. Какая уж тут инкапсуляция когда всем всё видно? Сначала возможность напрямую обращаться к игровому персу, неписям, сундукам на сцене выглядит заманчиво, но потом наступит путаница и пиздец. Неизбежно наступит путаница и обязательно придёт пиздец.
Гораздо корректнее выглядит описанный выше принцип глобальных сигналов.
Игровым объектам всё так же нужно у себя в _ready обращаться к глобальному объекту, но в этом случае они не оставляют там прямую ссылку на себя, а регистрируются на глобальные сигналы. Глобальный объект может дёргать эти сигналы, но ни он, ни другие объекты не могут обратиться к получателям сигналов напрямую.
Я настолько глубоко изучил данную тему, что даже научился возвращать данные с излученных сигналов. Просто регистрируешь сигнал с аргументом и следуешь соглашению о том, что аргументом должен быть словарь, в который все зарегистрированные на сигнал обработчики добавляют запись о результатах своей работы.
Например, в глобальном объекте:
signal query_something(query_result) #Пока что язык не позволяет задекларировать в аргументе статический тип, увы.
Далее, в объектах-обработчиках:
func _ready():
____G.connect("query_something", self, "process_query")
func process_query(byref_result : Dictionary):
____byref_result[self.name].data = "Задание принял сержант %s" % self.name
>>699591
О, и в объектах-излучателях примерно так:
func command():
____var reports : Dictionary
____G.emit_signal("query_something", reports)
После чего в словаре reports окажется что-то типа:
{
"Иванов" : { "data" : "Задание принял сержант Иванов"},
"Петров" : { "data" : "Задание принял сержант Петров"},
"Сидоров" : { "data" : "Задание принял сержант Сидоров"}
}
О, и в объектах-излучателях примерно так:
func command():
____var reports : Dictionary
____G.emit_signal("query_something", reports)
После чего в словаре reports окажется что-то типа:
{
"Иванов" : { "data" : "Задание принял сержант Иванов"},
"Петров" : { "data" : "Задание принял сержант Петров"},
"Сидоров" : { "data" : "Задание принял сержант Сидоров"}
}
>>698900
>>699198
Я всё больше убеждаюсь, что именно сигналы здесь притом и к месту.
>>698997
Я так и не увидел примера твоей работы с нотификациями. Я бы освоил эту подсистему. Если конечно имеются ввиду те самые нотификации, которые идут через _notification(what)
> А теперь представим, что для части действий, которые должен сделать пользователь, ты должен передать урон этой же карте, другой, герою, печенью на столе. Меняется только объект. И вот это разделение говнокодом на matchс каким-нибудь текстом из жсона меня выбесило чето.
>>699198
> У чувака есть 3 спелла. Первый юзается на себя, второй на героя, третий на комбо карту. Все что они делают — передают дамаг. Причем тут сигналы? Мне надо прокинуть верный референс без заеба, считав из жсона ноду.
> Причем тут сигналы?
Я всё больше убеждаюсь, что именно сигналы здесь притом и к месту.
>>698997
> Да и сигналы много кушают, как бы они не были удобны. Нотификациями быстрее.
Я так и не увидел примера твоей работы с нотификациями. Я бы освоил эту подсистему. Если конечно имеются ввиду те самые нотификации, которые идут через _notification(what)
>>699670
Сигналы нужны, когда я хочу десятку неизвестных сказать - вперед/назад/стань красным, на какое-то событие.
А когда у меня четкое ограниченное число лиц, на которых я имею референс, тогда не надо.
Вопрос только в том, как использовать референс адекватно.
Но спорить об этом без смыслено. Давай на практике.
Есть dict спелов.
var mayspelldict = {
0: {"name":"damage spell", "damage":5, "func":"hello_world"}}
Как заставить пикачу юзнуть это на всех/одного себя/вызвавшего и т.п.?
Сигналы нужны, когда я хочу десятку неизвестных сказать - вперед/назад/стань красным, на какое-то событие.
А когда у меня четкое ограниченное число лиц, на которых я имею референс, тогда не надо.
Вопрос только в том, как использовать референс адекватно.
Но спорить об этом без смыслено. Давай на практике.
Есть dict спелов.
var mayspelldict = {
0: {"name":"damage spell", "damage":5, "func":"hello_world"}}
Как заставить пикачу юзнуть это на всех/одного себя/вызвавшего и т.п.?
>>699741
Если у тебя есть референсы на все нужные тебе объекты, то наиболее адекватным решением будет вызывать у требуемых тебе объектов нужный метод. И всё.
Практически это означает, что у тебя есть скажем, несколько объектов, которые реализуют интерфейс "ПринимательСпеллов" (разумеется, в гдскрипте нет интерфейсов и возможности объектами указанный интерфейс реализовывать, потому в гдскрипте, это всё следует сделать ручками).
Допустим, принимателями спеллов у нас являются сами карты, игроки, игровой стол. Как у принимателей спеллов у любого из них есть созданный тобою лично метод .accept_spell(spell_data : Dictionary)
Таким образом, наш пикачу, когда ему необходимо, берёт имеющиеся у него референсы, согласно игровым правилам, и пишет:
ref1.accept_spell(myspelldict[0])
ref2.accept_spell(myspelldict[1])
desk.accept_spell(myspelldict[100500])
Ну а приниматели спеллов у себя в вышеуказанном методе применяют полученный из аргумента спелл на себя. Разумеется, проверяя, что в метод прилетел спелл, а не словарь с прогнозом погоды в Мозамбике. Парсить словарь придётся в любом случае.
Есть ещё вот такой вариант, тоже с серпояйцевыми стрингами:
call_group("spell_acceptors", "accept_spell", myspelldict[0])
В этом варианте роль интерфейсов частично берут на себя группы. Включая объект в группу, ты "должен" позаботиться, чтобы в нём были реализованы методы, которые ты потом будешь дёргать через call_group.
Если хочется кодить нормально, с соблюдением парадигм и паттернов, чтобы классы принудительно реализовали интерфейсы, чтобы данные между инстансами передавались по числовым ключам, минуя явные и неявные преобразования в строки, то тогда рекомендую заюзать годот-шарп и кодить всю ключевую логику на шарпе. А уж мелочи вроде загрузить/выгрузить, показать/скрыть/задать-цвет-прозрачность - на гдскрипте.
Если у тебя есть референсы на все нужные тебе объекты, то наиболее адекватным решением будет вызывать у требуемых тебе объектов нужный метод. И всё.
Практически это означает, что у тебя есть скажем, несколько объектов, которые реализуют интерфейс "ПринимательСпеллов" (разумеется, в гдскрипте нет интерфейсов и возможности объектами указанный интерфейс реализовывать, потому в гдскрипте, это всё следует сделать ручками).
Допустим, принимателями спеллов у нас являются сами карты, игроки, игровой стол. Как у принимателей спеллов у любого из них есть созданный тобою лично метод .accept_spell(spell_data : Dictionary)
Таким образом, наш пикачу, когда ему необходимо, берёт имеющиеся у него референсы, согласно игровым правилам, и пишет:
ref1.accept_spell(myspelldict[0])
ref2.accept_spell(myspelldict[1])
desk.accept_spell(myspelldict[100500])
Ну а приниматели спеллов у себя в вышеуказанном методе применяют полученный из аргумента спелл на себя. Разумеется, проверяя, что в метод прилетел спелл, а не словарь с прогнозом погоды в Мозамбике. Парсить словарь придётся в любом случае.
Есть ещё вот такой вариант, тоже с серпояйцевыми стрингами:
call_group("spell_acceptors", "accept_spell", myspelldict[0])
В этом варианте роль интерфейсов частично берут на себя группы. Включая объект в группу, ты "должен" позаботиться, чтобы в нём были реализованы методы, которые ты потом будешь дёргать через call_group.
Если хочется кодить нормально, с соблюдением парадигм и паттернов, чтобы классы принудительно реализовали интерфейсы, чтобы данные между инстансами передавались по числовым ключам, минуя явные и неявные преобразования в строки, то тогда рекомендую заюзать годот-шарп и кодить всю ключевую логику на шарпе. А уж мелочи вроде загрузить/выгрузить, показать/скрыть/задать-цвет-прозрачность - на гдскрипте.
>>699741
Ах да, и вот это ещё не заметил.
Ну, это в любом случае через call.
if ref1.has_method("hello_world"): ref1.call("hello_world") else: assert(false, "Wrong object for call hello_world!")
> "func":"hello_world"
Ах да, и вот это ещё не заметил.
Ну, это в любом случае через call.
if ref1.has_method("hello_world"): ref1.call("hello_world") else: assert(false, "Wrong object for call hello_world!")
>>699741
Для простоты проверки можно типизировать данные отдельным ключом в словаре:
var mayspelldict = {
0: {"type" : "spell", "name":"damage spell", "damage":5, "func":"hello_world"}}
После чего, кастуем спелл на имеющиеся референсы:
ref1.accept_spell(myspelldict[0])
После чего объекты по референсам у себя в методе делают так:
func accept_spell(spell_data : Dictionary):
___ if !spell_data or !(spell_data.has("type") and spell_data.type == "spell"): return
Этим условиями мы убедились, что в аргумент прилетел строго типизированный спелл, в котором точно есть name:String, damage:int, func:String и далее можем не выполнять утомительные перепроверки, но в случае, если юзеры залезут шаловливыми пальчиками в наши файлы данных (юзеры даже в БД смогут залезть через сторонние утилиты, даже зашифрованные данные расшифруют), то наша игора будет падать как тот скайрим, крошиться на десктоп после каждого чиха. Поэтому тут решай сам: удобство сейчас или головняк с саппортом потом.
Для простоты проверки можно типизировать данные отдельным ключом в словаре:
var mayspelldict = {
0: {"type" : "spell", "name":"damage spell", "damage":5, "func":"hello_world"}}
После чего, кастуем спелл на имеющиеся референсы:
ref1.accept_spell(myspelldict[0])
После чего объекты по референсам у себя в методе делают так:
func accept_spell(spell_data : Dictionary):
___ if !spell_data or !(spell_data.has("type") and spell_data.type == "spell"): return
Этим условиями мы убедились, что в аргумент прилетел строго типизированный спелл, в котором точно есть name:String, damage:int, func:String и далее можем не выполнять утомительные перепроверки, но в случае, если юзеры залезут шаловливыми пальчиками в наши файлы данных (юзеры даже в БД смогут залезть через сторонние утилиты, даже зашифрованные данные расшифруют), то наша игора будет падать как тот скайрим, крошиться на десктоп после каждого чиха. Поэтому тут решай сам: удобство сейчас или головняк с саппортом потом.
Парни, подскажите пожалуйста, возможно ли в годоте сделать варианты ответа и хоть какие-то диалоги?
>>699881
Да.
Да.
>>699881
Естественно.
Естественно.
Парни, подскажите пожалуйста, как в годоте сделать диалоги с вариантами ответов?
Мне надо чтобы были скилл-чеки и эквип-чеки (это когда у гироя на поясе весит легендарный ибанитовый меч +2 к ловкости и он может в диалогах поугражать что дастанет мечь и уебет).
Мне надо чтобы были скилл-чеки и эквип-чеки (это когда у гироя на поясе весит легендарный ибанитовый меч +2 к ловкости и он может в диалогах поугражать что дастанет мечь и уебет).
>>699961
В треде тут обычно все свои велосипедят.
Что такое варианты ответа? Это кнопки какого то вида (не обязательно кнопки, может быть спрайты). Они собираются в список, например в VBoxContainer.
Тут я вижу два варианта. Первый - набирать список по пунктам в коде, например из какого-то массива вариантов ответа. И по условию не добавлять твой пункт, если меча нет.
Второй - наоборот, накидать сразу все возможные ответы, а отсутствующие по условию скрывать.
В реале, там будет не массив, а скорее какой то словарь.
Или ты можешь пощупать готовые ассеты. Там есть и с условиями.
https://godotengine.org/asset-library/asset/628
https://godotengine.org/asset-library/asset/273
https://godotengine.org/asset-library/asset/416
В треде тут обычно все свои велосипедят.
Что такое варианты ответа? Это кнопки какого то вида (не обязательно кнопки, может быть спрайты). Они собираются в список, например в VBoxContainer.
Тут я вижу два варианта. Первый - набирать список по пунктам в коде, например из какого-то массива вариантов ответа. И по условию не добавлять твой пункт, если меча нет.
Второй - наоборот, накидать сразу все возможные ответы, а отсутствующие по условию скрывать.
В реале, там будет не массив, а скорее какой то словарь.
Или ты можешь пощупать готовые ассеты. Там есть и с условиями.
https://godotengine.org/asset-library/asset/628
https://godotengine.org/asset-library/asset/273
https://godotengine.org/asset-library/asset/416
>>699967
Годный ответ, спасибо, бро!
Годный ответ, спасибо, бро!
>>700018
Это объявление функции. В скобках - параметры, которая она принимает.
Пример из математики - функция синус принимает параметром угол.
При вызове функции эти параметры будут заполнены значениями. Вызов смотри в 16 строчке.
Это объявление функции. В скобках - параметры, которая она принимает.
Пример из математики - функция синус принимает параметром угол.
При вызове функции эти параметры будут заполнены значениями. Вызов смотри в 16 строчке.
>>699821
Бля, о принимателе спелов я не подумал. Годная страта.
А что скажешь о расположении объектов на местности в генерирующемся случайном/псевдослучайной порядке, но при этом объект не должен наслаиваться на другой обьект?
Бля, о принимателе спелов я не подумал. Годная страта.
А что скажешь о расположении объектов на местности в генерирующемся случайном/псевдослучайной порядке, но при этом объект не должен наслаиваться на другой обьект?
>>700026
Откуда этот параметр будет браться? Переменная input_vector в нескольких функциях задействуется. Или в скобках ничего общего с переменной не имеет?
Откуда этот параметр будет браться? Переменная input_vector в нескольких функциях задействуется. Или в скобках ничего общего с переменной не имеет?
>>700057
Параметр функции - это как бы новая переменная. Она "затеняет" другую. Т.е.
var x = 1
var y = 2
func foo(x):
print(x)
print(y)
foo(300)
Параметр функции - это как бы новая переменная. Она "затеняет" другую. Т.е.
var x = 1
var y = 2
func foo(x):
print(x)
print(y)
foo(300)
>300
>2
>>700060
Для того, чтобы функция работала с тем, что ей передали. А не с оригинальной переменной.
Например, на тело действует ветер, и ты вызываешь с другой переменной
apply_horizontal_force(input_vector, delta)
apply_horizontal_force(wind_vector, delta)
Если тебя смущает совпадение имени, то просто переименуй.
Для того, чтобы функция работала с тем, что ей передали. А не с оригинальной переменной.
Например, на тело действует ветер, и ты вызываешь с другой переменной
apply_horizontal_force(input_vector, delta)
apply_horizontal_force(wind_vector, delta)
Если тебя смущает совпадение имени, то просто переименуй.
>>700062
Ну смотри - как бы ты написал функцию возведения в квадрат?
Она получает параметр и возвращает значение.
func square(x):
return x*x
Этот x определен как псевдо-переменная внутри функции.
Ты можешь вызывать эту функцию
square(2) #вернет 4
var x = 3 #завели переменную x
square(5) #вернет 25, потому что ВНУТРИ функции x означает по прежнему то, что в нее передали, а не этот новый x
Ну смотри - как бы ты написал функцию возведения в квадрат?
Она получает параметр и возвращает значение.
func square(x):
return x*x
Этот x определен как псевдо-переменная внутри функции.
Ты можешь вызывать эту функцию
square(2) #вернет 4
var x = 3 #завели переменную x
square(5) #вернет 25, потому что ВНУТРИ функции x означает по прежнему то, что в нее передали, а не этот новый x
>>698054 (OP)
Почему у вас нет туторов этого парняги?
https://www.youtube.com/watch?v=H2a4lgV7CuY&list=PLf0k8CBUad-vNh-svvC9oiU00evBUZmS6&index=1
Как вы обучаетесь движку на документации написанной на буржуйском?
Почему у вас нет туторов этого парняги?
https://www.youtube.com/watch?v=H2a4lgV7CuY&list=PLf0k8CBUad-vNh-svvC9oiU00evBUZmS6&index=1
Как вы обучаетесь движку на документации написанной на буржуйском?
>>700069
Тебе нужно как то обращаться к полученным параметрам. У них должно быть имя.
Тебе нужно как то обращаться к полученным параметрам. У них должно быть имя.
114 Кб, 1920x1042Сап годотач. Делаем кликер и не знаем как заставить лэйбел прибавлять и отображать кол-во очков, по нажатию на кнопку. Скрин с кодом предоставил
Гугл ответов не дал
Гугл ответов не дал
87 Кб, 690x848>>700181
Все правильно, но надо подкчлючить сигнал.
Либо из UI редактора (справа вкладка Узел, рядом с Инспектором)
Либо из кода: $Button.connect("pressed", self, "_on_Button_pressed")
Все правильно, но надо подкчлючить сигнал.
Либо из UI редактора (справа вкладка Узел, рядом с Инспектором)
Либо из кода: $Button.connect("pressed", self, "_on_Button_pressed")
>>700181
Насчет того, что гугл не дал - по прежнему советую хотя бы пролистать https://docs.godotengine.org/en/stable/getting_started/step_by_step/index.html
Насчет того, что гугл не дал - по прежнему советую хотя бы пролистать https://docs.godotengine.org/en/stable/getting_started/step_by_step/index.html
>>700184
Благодарю анонче, не знаю что бы я без тебя делал.
Благодарю анонче, не знаю что бы я без тебя делал.
>>700298
Покажи туторы которые не говно. Я серьёзно.
Покажи туторы которые не говно. Я серьёзно.
Есть способ получить _грань_ объекта с которой произошло столкновение в физике? Желательно без перекомпиляции с++
>>700054
Накинь на объекты дополнительную area и пусть генератор перед тем, как выставить следующий объект, проверяет нет ли в сгенерированном месте чьих-либо area, если есть - значит будет наслоение, значит надо сгенерировать другую точку.
Накинь на объекты дополнительную area и пусть генератор перед тем, как выставить следующий объект, проверяет нет ли в сгенерированном месте чьих-либо area, если есть - значит будет наслоение, значит надо сгенерировать другую точку.
>>700065
Он и без нас прекрасно справляется. Щас бы пиарить конкурента бесплатно, ага.
> Почему у вас нет туторов этого парняги?
Он и без нас прекрасно справляется. Щас бы пиарить конкурента бесплатно, ага.
>>700321
Нормаль столкновения физический сервер возвращает. Согласно направлению нормали можешь посчитать с какой стороны столкновение и теоретически определить подходящую грань.
Нормаль столкновения физический сервер возвращает. Согласно направлению нормали можешь посчитать с какой стороны столкновение и теоретически определить подходящую грань.
>>700325
Я Петя Сканер и это - мой любимый тред на дваче.
Я Петя Сканер и это - мой любимый тред на дваче.
>>700326
Сложна. Вот в three.js мне реальный индекс грани в меше вернули.
> теоретически определить подходящую грань.
Сложна. Вот в three.js мне реальный индекс грани в меше вернули.
>>700323
Ты бы своей кпыше крикнул остановится. Какой конкурент, он в каждом видео говорит о точ, что сам учится и не является последней инстанцией и внезапно оказался прав о том что рускоязычных полных туторов по годоту на ютубе нет. Если у тебя есть примеры опровергающие это, то почему они не в шапке?
>конкурента
Ты бы своей кпыше крикнул остановится. Какой конкурент, он в каждом видео говорит о точ, что сам учится и не является последней инстанцией и внезапно оказался прав о том что рускоязычных полных туторов по годоту на ютубе нет. Если у тебя есть примеры опровергающие это, то почему они не в шапке?
>>700326
Я имею в виду что движок же уже должен знать какая. По видимому придется в кишочки лезть.
Я имею в виду что движок же уже должен знать какая. По видимому придется в кишочки лезть.
>>700333
Произошла чудовищная ошибка.
Произошла чудовищная ошибка.
>>700331
Лишь бы игры не делать. Вот я вместо тебя полез в документацию и уточнил, что при коллизии возвращается не только нормаль, но ещё и точка, и какие-то шейп-индексы. https://docs.godotengine.org/en/3.2/classes/class_kinematiccollision.html
> По видимому придется в кишочки лезть.
Лишь бы игры не делать. Вот я вместо тебя полез в документацию и уточнил, что при коллизии возвращается не только нормаль, но ещё и точка, и какие-то шейп-индексы. https://docs.godotengine.org/en/3.2/classes/class_kinematiccollision.html
>>700336
Точка - это просто координата в пространстве, она так же не помогает узнать грань. А шейп-индексы действительно "какие-то", это если у тебя несколько коллизий на одном объекте. Ты же понимаешь, что я сначала все это почитал а потом перепробовал. Пришлось написать свой tool скрипт который дублирует геометрию и строит ареа и коллижншейпы, но это же костыль оверхедный.
Точка - это просто координата в пространстве, она так же не помогает узнать грань. А шейп-индексы действительно "какие-то", это если у тебя несколько коллизий на одном объекте. Ты же понимаешь, что я сначала все это почитал а потом перепробовал. Пришлось написать свой tool скрипт который дублирует геометрию и строит ареа и коллижншейпы, но это же костыль оверхедный.
>>700337
Давай зайдём с другой стороны. Какую вообще задачу ты решаешь?
(просто я сейчас после твоих слов о тулскриптах почувствовал главную болезнь форумов, когда приходит пользователь, который поставил себе задачу, начал её решать неправильно и уже после этого обратился на форум за советом, как ему заставить работать своё неправильное решение)
Давай зайдём с другой стороны. Какую вообще задачу ты решаешь?
(просто я сейчас после твоих слов о тулскриптах почувствовал главную болезнь форумов, когда приходит пользователь, который поставил себе задачу, начал её решать неправильно и уже после этого обратился на форум за советом, как ему заставить работать своё неправильное решение)
>>700347
>>700348
Гугол говорит, что нужно юзать этот класс https://docs.godotengine.org/ru/stable/classes/class_meshdatatool.html
>>700348
Гугол говорит, что нужно юзать этот класс https://docs.godotengine.org/ru/stable/classes/class_meshdatatool.html
>>700351
Это уже для следующего этапа, когда я захочу модифицировать полигон. Сначала мне надо узнать, какой именно полигон столкнулся.
Представь себе следующую ситуацию - игрок кидает нож во врага. Я хочу чтобы мигнул тот полигон в который он попал. Движок эту инфу судя по всему не пробрасывает https://github.com/godotengine/godot/issues/684
Поэтому я решил временно написав тул, который создает для каждого треугольника меша area, который уже сможет отозваться на рейкаст. Видимо без с++ никак.
Это уже для следующего этапа, когда я захочу модифицировать полигон. Сначала мне надо узнать, какой именно полигон столкнулся.
Представь себе следующую ситуацию - игрок кидает нож во врага. Я хочу чтобы мигнул тот полигон в который он попал. Движок эту инфу судя по всему не пробрасывает https://github.com/godotengine/godot/issues/684
Поэтому я решил временно написав тул, который создает для каждого треугольника меша area, который уже сможет отозваться на рейкаст. Видимо без с++ никак.
>>700372
Насколько я знаю, такую задачу решают помещением на одну модель нескольких коллайдеров.
Насколько я знаю, такую задачу решают помещением на одну модель нескольких коллайдеров.
Итак, вот мои результаты исследования стейтмашин. Я написал две.
Первая по принципам ООП, стейты - это классы, транзишоны - классы. Стейты наследуешь от базового стейта из комплекта поставки и таким образом программируешь машину. Транзишоны у себя в инит принимают обязательными параметрами стейт-откуда и стейт-куда и подписываются на сигнал "завершен" у стейта-откуда. Таким образом переходы работают автоматически по сигналам стейтов. Узнать текущий стейт машины возможно, опросив список её стейтов на предмет активированности, что выглядит тупо. Если неправильно запрограммировать логику, возможна одновременная активация нескольких стейтов, для чего в транзишоны введены режимы на манер искаробочной анимационной стейтмашины (немедленно, ждать начала, ждать конца), но это тоже тупенько.
Вторая по олдовым дидовским императивным принципам. Стейты - это текстовый конфиг (жсон), преобразующийся в словарь. Каждый конкретный стейт - тоже словарь, имеющий имя-ключ, имеющий поле некст с именем следующего стейта, имеющий поля с именами функций, которые должны быть вызваны при старте, при апдейте, при стопе. Вызваны у кого? - Сама машина у себя в ините принимает обязательным параметром ссылку на объект-процессор, в котором предполагается наличие функций из вышеуказанного конфига. Без валидного инстанса процессора - работать отказывается с сообщением об ошибке. Процессором может быть сама нода, создающая стейтмашину, сторонний скрипт, да хоть глобальный синглтон, здесь ограничений нет. Получить текущий стейт можно просто прочитав текстовую переменную куррент_стейт. Внутри машины специальная функция умно парсит поданный при ините словарь стейтов на предмет наличия опций и соответствие их процессору и грамотно вызывает функции через искаробочный метод колл(). Таким образом машина может быть естественным (для годоскрипта) образом интегрирована куда угодно. Самый главный её минус - работа с текстом, горы текста, тысячи их!
Я просмотрел имеющиеся в наличии стейтмашины на ассетлибе и выяснил, что они в том или ином виде относятся к одному из двух вышеописанных типов. При этом они тянутся со времён 3.0, в них перемешивается старый синтаксис с новым. И в общем-то, ассеты, они и тут ассеты - работать с ними непривычно, неудобно, демотивирующе.
Продолжу изыскания, попробую совместить оба принципа.
Первая по принципам ООП, стейты - это классы, транзишоны - классы. Стейты наследуешь от базового стейта из комплекта поставки и таким образом программируешь машину. Транзишоны у себя в инит принимают обязательными параметрами стейт-откуда и стейт-куда и подписываются на сигнал "завершен" у стейта-откуда. Таким образом переходы работают автоматически по сигналам стейтов. Узнать текущий стейт машины возможно, опросив список её стейтов на предмет активированности, что выглядит тупо. Если неправильно запрограммировать логику, возможна одновременная активация нескольких стейтов, для чего в транзишоны введены режимы на манер искаробочной анимационной стейтмашины (немедленно, ждать начала, ждать конца), но это тоже тупенько.
Вторая по олдовым дидовским императивным принципам. Стейты - это текстовый конфиг (жсон), преобразующийся в словарь. Каждый конкретный стейт - тоже словарь, имеющий имя-ключ, имеющий поле некст с именем следующего стейта, имеющий поля с именами функций, которые должны быть вызваны при старте, при апдейте, при стопе. Вызваны у кого? - Сама машина у себя в ините принимает обязательным параметром ссылку на объект-процессор, в котором предполагается наличие функций из вышеуказанного конфига. Без валидного инстанса процессора - работать отказывается с сообщением об ошибке. Процессором может быть сама нода, создающая стейтмашину, сторонний скрипт, да хоть глобальный синглтон, здесь ограничений нет. Получить текущий стейт можно просто прочитав текстовую переменную куррент_стейт. Внутри машины специальная функция умно парсит поданный при ините словарь стейтов на предмет наличия опций и соответствие их процессору и грамотно вызывает функции через искаробочный метод колл(). Таким образом машина может быть естественным (для годоскрипта) образом интегрирована куда угодно. Самый главный её минус - работа с текстом, горы текста, тысячи их!
Я просмотрел имеющиеся в наличии стейтмашины на ассетлибе и выяснил, что они в том или ином виде относятся к одному из двух вышеописанных типов. При этом они тянутся со времён 3.0, в них перемешивается старый синтаксис с новым. И в общем-то, ассеты, они и тут ассеты - работать с ними непривычно, неудобно, демотивирующе.
Продолжу изыскания, попробую совместить оба принципа.
Итак, вот мои результаты исследования стейтмашин. Я написал две.
Первая по принципам ООП, стейты - это классы, транзишоны - классы. Стейты наследуешь от базового стейта из комплекта поставки и таким образом программируешь машину. Транзишоны у себя в инит принимают обязательными параметрами стейт-откуда и стейт-куда и подписываются на сигнал "завершен" у стейта-откуда. Таким образом переходы работают автоматически по сигналам стейтов. Узнать текущий стейт машины возможно, опросив список её стейтов на предмет активированности, что выглядит тупо. Если неправильно запрограммировать логику, возможна одновременная активация нескольких стейтов, для чего в транзишоны введены режимы на манер искаробочной анимационной стейтмашины (немедленно, ждать начала, ждать конца), но это тоже тупенько.
Вторая по олдовым дидовским императивным принципам. Стейты - это текстовый конфиг (жсон), преобразующийся в словарь. Каждый конкретный стейт - тоже словарь, имеющий имя-ключ, имеющий поле некст с именем следующего стейта, имеющий поля с именами функций, которые должны быть вызваны при старте, при апдейте, при стопе. Вызваны у кого? - Сама машина у себя в ините принимает обязательным параметром ссылку на объект-процессор, в котором предполагается наличие функций из вышеуказанного конфига. Без валидного инстанса процессора - работать отказывается с сообщением об ошибке. Процессором может быть сама нода, создающая стейтмашину, сторонний скрипт, да хоть глобальный синглтон, здесь ограничений нет. Получить текущий стейт можно просто прочитав текстовую переменную куррент_стейт. Внутри машины специальная функция умно парсит поданный при ините словарь стейтов на предмет наличия опций и соответствие их процессору и грамотно вызывает функции через искаробочный метод колл(). Таким образом машина может быть естественным (для годоскрипта) образом интегрирована куда угодно. Самый главный её минус - работа с текстом, горы текста, тысячи их!
Я просмотрел имеющиеся в наличии стейтмашины на ассетлибе и выяснил, что они в том или ином виде относятся к одному из двух вышеописанных типов. При этом они тянутся со времён 3.0, в них перемешивается старый синтаксис с новым. И в общем-то, ассеты, они и тут ассеты - работать с ними непривычно, неудобно, демотивирующе.
Продолжу изыскания, попробую совместить оба принципа.
Первая по принципам ООП, стейты - это классы, транзишоны - классы. Стейты наследуешь от базового стейта из комплекта поставки и таким образом программируешь машину. Транзишоны у себя в инит принимают обязательными параметрами стейт-откуда и стейт-куда и подписываются на сигнал "завершен" у стейта-откуда. Таким образом переходы работают автоматически по сигналам стейтов. Узнать текущий стейт машины возможно, опросив список её стейтов на предмет активированности, что выглядит тупо. Если неправильно запрограммировать логику, возможна одновременная активация нескольких стейтов, для чего в транзишоны введены режимы на манер искаробочной анимационной стейтмашины (немедленно, ждать начала, ждать конца), но это тоже тупенько.
Вторая по олдовым дидовским императивным принципам. Стейты - это текстовый конфиг (жсон), преобразующийся в словарь. Каждый конкретный стейт - тоже словарь, имеющий имя-ключ, имеющий поле некст с именем следующего стейта, имеющий поля с именами функций, которые должны быть вызваны при старте, при апдейте, при стопе. Вызваны у кого? - Сама машина у себя в ините принимает обязательным параметром ссылку на объект-процессор, в котором предполагается наличие функций из вышеуказанного конфига. Без валидного инстанса процессора - работать отказывается с сообщением об ошибке. Процессором может быть сама нода, создающая стейтмашину, сторонний скрипт, да хоть глобальный синглтон, здесь ограничений нет. Получить текущий стейт можно просто прочитав текстовую переменную куррент_стейт. Внутри машины специальная функция умно парсит поданный при ините словарь стейтов на предмет наличия опций и соответствие их процессору и грамотно вызывает функции через искаробочный метод колл(). Таким образом машина может быть естественным (для годоскрипта) образом интегрирована куда угодно. Самый главный её минус - работа с текстом, горы текста, тысячи их!
Я просмотрел имеющиеся в наличии стейтмашины на ассетлибе и выяснил, что они в том или ином виде относятся к одному из двух вышеописанных типов. При этом они тянутся со времён 3.0, в них перемешивается старый синтаксис с новым. И в общем-то, ассеты, они и тут ассеты - работать с ними непривычно, неудобно, демотивирующе.
Продолжу изыскания, попробую совместить оба принципа.
>>701031
Мой дидовский подход к стейтмашинам выглядит очень просто.
Смущают строки или классы? Идут нахуй - стейты это просто enum интов.
Смущают косяки в транзишнах? Транзишны идут нахуй, все возможные переходы описаны в обработчике конкретного стейта через switch (или match), для необрабатываемых в default вывод ошибки.
Мой дидовский подход к стейтмашинам выглядит очень просто.
Смущают строки или классы? Идут нахуй - стейты это просто enum интов.
Смущают косяки в транзишнах? Транзишны идут нахуй, все возможные переходы описаны в обработчике конкретного стейта через switch (или match), для необрабатываемых в default вывод ошибки.
>>701034
Тащемта, всё так. Но хочется изъебнуться, например. Ну не игры же делать, в самом-то деле, а?
Тащемта, всё так. Но хочется изъебнуться, например. Ну не игры же делать, в самом-то деле, а?
>>701039
Ага.
Вспоминил еще почему не люблю enter/exit в FSM
В них все равно пролезает говно типа if (prevState was...)
Ну и нахуй так жить
Ага.
Вспоминил еще почему не люблю enter/exit в FSM
В них все равно пролезает говно типа if (prevState was...)
Ну и нахуй так жить
>>701042
Это говно теоретически исправляется разделением логики и данных. В твоём случае логика включения стейта пытается смешаться с данными о предыдущем стейте. Значит надо добавить в класс данные, набор флагов, включаемых стейтами и при старте стейтов смотреть не на предыдущий стейт, а на интересующие конкретно этот стейт флаги.
И разумеется, поскольку флаги - это данные, они с лёгкостью вынесутся из класса в БД, потом, на стадии оптимизации.
Это говно теоретически исправляется разделением логики и данных. В твоём случае логика включения стейта пытается смешаться с данными о предыдущем стейте. Значит надо добавить в класс данные, набор флагов, включаемых стейтами и при старте стейтов смотреть не на предыдущий стейт, а на интересующие конкретно этот стейт флаги.
И разумеется, поскольку флаги - это данные, они с лёгкостью вынесутся из класса в БД, потом, на стадии оптимизации.
Просто держу в курсе
https://www.youtube.com/watch?v=2qB3CNvOoGg
https://www.youtube.com/watch?v=2qB3CNvOoGg
>>701378
В одиночку ты не сможешь запилить реалистичный графониум уровня трипл-эй. Получится какое-нибудь корявое ассетоговно уровня 35мм. Поэтому как ни крути - нужно делать упор на стиль и геймплей. Стилизованный графон может быть пиксельный, может быть под первую плойку, или сингл-колор-лоу-поли.
В одиночку ты не сможешь запилить реалистичный графониум уровня трипл-эй. Получится какое-нибудь корявое ассетоговно уровня 35мм. Поэтому как ни крути - нужно делать упор на стиль и геймплей. Стилизованный графон может быть пиксельный, может быть под первую плойку, или сингл-колор-лоу-поли.
https://youtu.be/HKTR8upoaLw
За сколько в годо можно такие игры научиться делать, и что для этого нужно знать?
За сколько в годо можно такие игры научиться делать, и что для этого нужно знать?
>>701382
Какой у тебя опыт? Про арт ничего не скажу. Если умеешь кодить, механики тут пишутся за неделю (а может быть есть и пример игры с исходниками - не помню попадались ли такие), но если не знаешь - прибавь пару месяцев на изучение языков программирования и прохождение туториалов конкретно по top-down rpg и менюшкам в стиле ВНок.
Какой у тебя опыт? Про арт ничего не скажу. Если умеешь кодить, механики тут пишутся за неделю (а может быть есть и пример игры с исходниками - не помню попадались ли такие), но если не знаешь - прибавь пару месяцев на изучение языков программирования и прохождение туториалов конкретно по top-down rpg и менюшкам в стиле ВНок.
>>701384
Потом уже сами карты, уровни, сюжеты сверху плюсуй.
Потом уже сами карты, уровни, сюжеты сверху плюсуй.
>>701384
Две-три на самом деле, заебешься итерфейс кодить. Ничего сложного, конечно, но тупо долго и муторно.
>механики тут пишутся за неделю
Две-три на самом деле, заебешься итерфейс кодить. Ничего сложного, конечно, но тупо долго и муторно.
>>701031
Ты нихуя не знаешь про дидовский подход к стейтмашинам. Истинный дидовский подход - это цепочка if...elseif
Ты нихуя не знаешь про дидовский подход к стейтмашинам. Истинный дидовский подход - это цепочка if...elseif
>>701394
Ну вот для интерфейса то как раз во-первых есть искаробочный гуй с кастомизацией тем, потом есть 9-patch rect, и в конце концов для диалогов-инвентарей есть хоть какие то ассетики.
Ну вот для интерфейса то как раз во-первых есть искаробочный гуй с кастомизацией тем, потом есть 9-patch rect, и в конце концов для диалогов-инвентарей есть хоть какие то ассетики.
>>701396
А логику(которая и занимает больше всего времени) за тебя будет личный раб писать?
А логику(которая и занимает больше всего времени) за тебя будет личный раб писать?
>>701425
Так в скинутой игре логики почти не наблюдается (один раз двигается ящик по принципу сокобана и 1 раз вводится число в кодовый замок), в остальном это просто зашел в ареа-сработал триггер, логику топ-даун бродилки можно найти в туторах за указанную неделю, а логика ассетов-диалогов будет работать из коробки, или ты про общую логику типа завести переменные-флаги- isHauntedHouseVisited, isNpcBartenderKnowsAboutGhost?
Так в скинутой игре логики почти не наблюдается (один раз двигается ящик по принципу сокобана и 1 раз вводится число в кодовый замок), в остальном это просто зашел в ареа-сработал триггер, логику топ-даун бродилки можно найти в туторах за указанную неделю, а логика ассетов-диалогов будет работать из коробки, или ты про общую логику типа завести переменные-флаги- isHauntedHouseVisited, isNpcBartenderKnowsAboutGhost?
>>701454
Ну если кого-то развлекает тоска, то что ж.
Ну если кого-то развлекает тоска, то что ж.
>>701530
о, так оно всё таки есть!
о, так оно всё таки есть!
497 Кб, 1441x953Подбираю сейчас трекер для геймджема, а оказывается Chibitracker Хуан сделал.
Запилил генератор херни через surface tool
Но вообще не понимаю, как к этому объекту прилепить UV развёртку и повесить текстуру. По сути надо лишь развернуть планарной проекцией с видом сверху и на неё назначить текстуру
Но я вообще не пойму - через что это можно сделать?
Но вообще не понимаю, как к этому объекту прилепить UV развёртку и повесить текстуру. По сути надо лишь развернуть планарной проекцией с видом сверху и на неё назначить текстуру
Но я вообще не пойму - через что это можно сделать?
>>701732
Через что в движке? Ну вроде там есть add_uv, по аналогии с add_normal
https://docs.godotengine.org/en/3.2/tutorials/content/procedural_geometry/surfacetool.html
Почитай еще тут, там три инструмента для создания мешей, может тебе другой окажется удобней
https://docs.godotengine.org/en/3.2/tutorials/content/procedural_geometry/index.html
Или ты про сами алгоритмы uv развертки?
Через что в движке? Ну вроде там есть add_uv, по аналогии с add_normal
https://docs.godotengine.org/en/3.2/tutorials/content/procedural_geometry/surfacetool.html
Почитай еще тут, там три инструмента для создания мешей, может тебе другой окажется удобней
https://docs.godotengine.org/en/3.2/tutorials/content/procedural_geometry/index.html
Или ты про сами алгоритмы uv развертки?
25,5 Мб, mp4,1920x1080, 1:39
3 часа назад релизнулась бета 0.3.1 тайлового редактор LEd
https://github.com/deepnight/led/releases/
Его пишет автор dead cells, которому надоели неудобные редакторы.
Фишка редактора в автотайлинге - задаешь правила, какие тайлы могут появляться слева, с краю, сверху от каких - и просто рисуешь кистью по карте, а он все расставляет.
В чем магический эффект?
Вот этот ассет годота позволяет импотировать файлы редактора Tiled .tmx https://godotengine.org/asset-library/asset/158
А LEd 0.3.1 научился экспортировать в этот формат, если поставить галочку.
Таким образом, практически в два клика получаем в Годоте то, что рисуем в LEd.
Из замеченных косяков - при экспорте правила применяются в обратном порядке - поэтому при финальном экспорте надо будет переставить их (думаю быстро поправят), во-вторых расставленные объекты (враги, паверапы) промахнулись на 1 клетку вниз, в-третьих не нашел куда деваются кастомные проперти (если им там задавать здоровье, лут и т.д.)
Мржет быть кому то понравится.
https://github.com/deepnight/led/releases/
Его пишет автор dead cells, которому надоели неудобные редакторы.
Фишка редактора в автотайлинге - задаешь правила, какие тайлы могут появляться слева, с краю, сверху от каких - и просто рисуешь кистью по карте, а он все расставляет.
В чем магический эффект?
Вот этот ассет годота позволяет импотировать файлы редактора Tiled .tmx https://godotengine.org/asset-library/asset/158
А LEd 0.3.1 научился экспортировать в этот формат, если поставить галочку.
Таким образом, практически в два клика получаем в Годоте то, что рисуем в LEd.
Из замеченных косяков - при экспорте правила применяются в обратном порядке - поэтому при финальном экспорте надо будет переставить их (думаю быстро поправят), во-вторых расставленные объекты (враги, паверапы) промахнулись на 1 клетку вниз, в-третьих не нашел куда деваются кастомные проперти (если им там задавать здоровье, лут и т.д.)
Мржет быть кому то понравится.
>>701913
Маски, тысячи их. И связи логические.
Судя по видосу, редактор помощнее искаробочного, как минимум он может рандомно траву поверх граунда рисовать.
> В чем магический эффект?
Маски, тысячи их. И связи логические.
Судя по видосу, редактор помощнее искаробочного, как минимум он может рандомно траву поверх граунда рисовать.
>>701913
А, еще минус - там пока нет полигонных коллизий - под скосы и склоны. Вообще, по-моему там вообще нет коллизий - просто один из слоев данных можно трактовать как поклеточные коллизии.
А, еще минус - там пока нет полигонных коллизий - под скосы и склоны. Вообще, по-моему там вообще нет коллизий - просто один из слоев данных можно трактовать как поклеточные коллизии.
>>701913
Обесни вот это, плиз. Что это, можно делать игру прямо в тайл-редакторе, без кодинга?
> кастомные проперти (если им там задавать здоровье, лут и т.д.)
Обесни вот это, плиз. Что это, можно делать игру прямо в тайл-редакторе, без кодинга?
>>701915
Tiled тоже мощный редактор, но он конечно не очень удобный уже, с интерфейсом 2000 года. Позволяет делать всякие приколюхи
https://doc.mapeditor.org/en/stable/manual/using-wang-tiles/
Tiled тоже мощный редактор, но он конечно не очень удобный уже, с интерфейсом 2000 года. Позволяет делать всякие приколюхи
https://doc.mapeditor.org/en/stable/manual/using-wang-tiles/
805 Кб, 1548x1061>>701919
В самом редакторе заявляется вот такой пример использования.
Как ты потом распорядишься данными в игре - дело за тобой.
В принципе можно представить себе следующий воркфлоу - программист пишет логику, а предметы уже раздает дизайнер, главное чтобы называл их по ожидаемой кодом схеме.
В самом редакторе заявляется вот такой пример использования.
Как ты потом распорядишься данными в игре - дело за тобой.
В принципе можно представить себе следующий воркфлоу - программист пишет логику, а предметы уже раздает дизайнер, главное чтобы называл их по ожидаемой кодом схеме.
>>701913
Ха, я знаю как это поправить. Там в плагине всего в одной строке надо true/false переключиь. Доберусь до компа - посмотрю и отпишусь где.
>во-вторых расставленные объекты (враги, паверапы) промахнулись на 1 клетку вниз,
Ха, я знаю как это поправить. Там в плагине всего в одной строке надо true/false переключиь. Доберусь до компа - посмотрю и отпишусь где.
>>701913
>>701948
Добрался, отписываюсь.
Плагин писался еще под версию годота 3.1, а там был косяк со сдвигом объектов в тайлмапах. В плагине добавили костыль для его обхода. В 3.2 косяк исправили, а в плагине костыль не отключили.
-------
Короче. В каталоге с проектом где используется плагин, находишь вот этот файл:
addons/vren.tiled_importer/tiled_import_plugin.gd
в нем находишь строку:
options.apply_offset = true
и меняешь значение на false.
И все должно быть нормально.
>во-вторых расставленные объекты (враги, паверапы) промахнулись на 1 клетку вниз
>>701948
>Ха, я знаю как это поправить. Там в плагине всего в одной строке надо true/false переключиь. Доберусь до компа - посмотрю и отпишусь где.
Добрался, отписываюсь.
Плагин писался еще под версию годота 3.1, а там был косяк со сдвигом объектов в тайлмапах. В плагине добавили костыль для его обхода. В 3.2 косяк исправили, а в плагине костыль не отключили.
-------
Короче. В каталоге с проектом где используется плагин, находишь вот этот файл:
addons/vren.tiled_importer/tiled_import_plugin.gd
в нем находишь строку:
options.apply_offset = true
и меняешь значение на false.
И все должно быть нормально.
Неспешно перекатываюсь на сишарп
На гдскрипте ждать следующий кадр будет так
yield(get_tree(), "idle_frame")
В C# нашел такое:
await ToSignal(this, "idle_frame");
Но требует чтобы я пометил функцию async.
А тогда же покрасятся все функции откуда и куда вызовы, то есть всю программу что ли придется делать async?
Или я переусложняю.
На гдскрипте ждать следующий кадр будет так
yield(get_tree(), "idle_frame")
В C# нашел такое:
await ToSignal(this, "idle_frame");
Но требует чтобы я пометил функцию async.
А тогда же покрасятся все функции откуда и куда вызовы, то есть всю программу что ли придется делать async?
Или я переусложняю.
>>702082
(Незначительная опечатка закралась await ToSignal(GetTree(), "idle_frame");
(Незначительная опечатка закралась await ToSignal(GetTree(), "idle_frame");
>>702082
await async очень годно расписано у хача на ютубе, я только там понял смысел
https://www.youtube.com/watch?v=oGxZuq2Ye2Q
await async очень годно расписано у хача на ютубе, я только там понял смысел
https://www.youtube.com/watch?v=oGxZuq2Ye2Q
>>702089
Придется посмотреть попозже, просто функционал один и тот же, думал одной строчкой получится сделать.
На самом деле похоже столкнулся с особенностью таймлайна анимейшн плеера - хоть события и нанесены в одну точку, но сработать могут не одновременно, в моем случае смена кадра анимации и смена оффсета спрайта привели к промигиванию (кадр менялся но скакал в другую точку и потом возвращался обратно)
Придется посмотреть попозже, просто функционал один и тот же, думал одной строчкой получится сделать.
На самом деле похоже столкнулся с особенностью таймлайна анимейшн плеера - хоть события и нанесены в одну точку, но сработать могут не одновременно, в моем случае смена кадра анимации и смена оффсета спрайта привели к промигиванию (кадр менялся но скакал в другую точку и потом возвращался обратно)
>>702095
Хотя, тут возможно я сам лоханулся - всю логику то считаю в physics process, а аниматору такое же свойство выставить забыл.
Хотя, тут возможно я сам лоханулся - всю логику то считаю в physics process, а аниматору такое же свойство выставить забыл.
>>701998
Еще не смотрел, но спасибо за инфу.
Еще не смотрел, но спасибо за инфу.
Есть способ узнать разрешение экрана не включая фулскрин? Чтобы выставить окну максимальный размер.
>>702144
OS.max_window_size возвращает за вычетом рамки, т.е. не всю правду.
OS.max_window_size возвращает за вычетом рамки, т.е. не всю правду.
>>702144
OS.get_screen_size(-1)
-----
в скобках номер монитора если их несколько, -1 - текущий монитор.
OS.get_screen_size(-1)
-----
в скобках номер монитора если их несколько, -1 - текущий монитор.
>>702164
О, прикольно. Спасибо.
О, прикольно. Спасибо.
>>702163
Есть такое понятие как хиральность. Это когда есть два вида одинакового объекта, только различающихся зеркально, оптические изомеры в общем. И вот такая проблема - молекулы разной хиральности не подходят друг к другу. Не встраиваются в организм. Был такой случай, когда от лекарства Талидамид много выкидышей было. Так вот это я к чему веду. Если у тебя что-то не получилось в Годоте - есть неиллюзорный шанс, что проблема в тебе. Что ты ему не подходишь, потому что у тебя руки не той хиральности вырасли.
Есть такое понятие как хиральность. Это когда есть два вида одинакового объекта, только различающихся зеркально, оптические изомеры в общем. И вот такая проблема - молекулы разной хиральности не подходят друг к другу. Не встраиваются в организм. Был такой случай, когда от лекарства Талидамид много выкидышей было. Так вот это я к чему веду. Если у тебя что-то не получилось в Годоте - есть неиллюзорный шанс, что проблема в тебе. Что ты ему не подходишь, потому что у тебя руки не той хиральности вырасли.
Если кто пользовался C# - API годота никогда не кидает исключения, только возвращает коды ошибки как в GDScript? Речь не про то что куда-то передал Null
>>702166
Слава Кодзиме гению, теперь этот термин у меня ассоциируется с летающими в небесах китами-зомби.
> хиральность
Слава Кодзиме гению, теперь этот термин у меня ассоциируется с летающими в небесах китами-зомби.
394 Кб, 750x1121Как сделать что бы при наведении на кнопку курсор менялся на системный указывающий палец?
https://2ch.hk/news/res/8465940.html#8466083 (
М)
Вот это остряк.
Но впринципе верно подметил.
М)>Это те которые ничего не разрабатывали в своей жизни? Как я люблю их называть "Годот разработчики"
Вот это остряк.
Но впринципе верно подметил.
186 Кб, 1060x1047Код плагина для добавления меню в главное меню. Работает с локализированным редактором тоже.
>>702398
Ты тредом ошибся, движкосрачер, иди в свой загон и там обсасывай с такими же как ты недоумками, как даже в ньюсачах унижают "годотей".
Репорт.
Ты тредом ошибся, движкосрачер, иди в свой загон и там обсасывай с такими же как ты недоумками, как даже в ньюсачах унижают "годотей".
Репорт.
>>698054 (OP)
не пойму, как работают отступы. Постоянно компилятор ругается, что где-то отступ просрал. Как это фиксится?
не пойму, как работают отступы. Постоянно компилятор ругается, что где-то отступ просрал. Как это фиксится?
42 Кб, 895x719>>702813
У меня такое бывает, когда я качаю ассеты из ассетстора, там какого-то хуя часть ассетов, по видимому какими-то гитхабовскими алгоритмами преобразует табы в двухпробельные отступы (или авторы этих проблемных ассетов за каким-то хуем настраивают двухпробельные отступы у себя в проектах). После чего годот пытается автоматически заменить уже 4 по его дефолту пробела, после чего код всирается, и если код длинен и сложен, то хуй ты уже восстановишь оригинал.
Костыльное и неудобное решение в таком случае, чтобы не портить свой код, создать отдельный проект, в его настройках выставить отступ в два пробела, скачать туда проблемный ассет, компильнуть проект один раз, чтобы годот заменил там по два каждых пробела на табы, после чего скопировать файлы ассета в рабочий проект.
Но воще это серьёзная проблема и надо создавать ишью. Но мне впадлу.
У меня такое бывает, когда я качаю ассеты из ассетстора, там какого-то хуя часть ассетов, по видимому какими-то гитхабовскими алгоритмами преобразует табы в двухпробельные отступы (или авторы этих проблемных ассетов за каким-то хуем настраивают двухпробельные отступы у себя в проектах). После чего годот пытается автоматически заменить уже 4 по его дефолту пробела, после чего код всирается, и если код длинен и сложен, то хуй ты уже восстановишь оригинал.
Костыльное и неудобное решение в таком случае, чтобы не портить свой код, создать отдельный проект, в его настройках выставить отступ в два пробела, скачать туда проблемный ассет, компильнуть проект один раз, чтобы годот заменил там по два каждых пробела на табы, после чего скопировать файлы ассета в рабочий проект.
Но воще это серьёзная проблема и надо создавать ишью. Но мне впадлу.
>>702813
Двачую табы vs пробелы.
Отступы работают так:
Все строки одного блока кода должны быть на одинаковых отступах. Они делаются табами.
Например
func somefun():
[tab]var x = 0 #эта
[tab]call1(x) #и эта
[tab]if x == 0: #и эта на одном уровне
[tab][tab]x = 1 #а этот вложенный блок
[tab][tab]call2(x) #на втором
[tab]x = 3 #вернулись на первый
[tab] call3(x) # ошибка - лишний пробел
Двачую табы vs пробелы.
Отступы работают так:
Все строки одного блока кода должны быть на одинаковых отступах. Они делаются табами.
Например
func somefun():
[tab]var x = 0 #эта
[tab]call1(x) #и эта
[tab]if x == 0: #и эта на одном уровне
[tab][tab]x = 1 #а этот вложенный блок
[tab][tab]call2(x) #на втором
[tab]x = 3 #вернулись на первый
[tab] call3(x) # ошибка - лишний пробел
42 Кб, 894x722>>702813
А вообще, немношк покрутил опции, попробуй вот эту опцию отключить, пикрелейтед:
...
И вот этот совет следует пофиксить, так как настройки редактора глобальны для всех проектов, то:
>>702814
(А ищью Хуану надо закинуть следующего содержания: В файлы .gd следует добавить нечитаемую редактором, ну или содержащуюся в комментарии а-ля xml мета-инфу, содержащую как минимум, сколько пробелов следует рассматривать в данном скрипте как один таб. Закиньте, годаны.)
А вообще, немношк покрутил опции, попробуй вот эту опцию отключить, пикрелейтед:
...
И вот этот совет следует пофиксить, так как настройки редактора глобальны для всех проектов, то:
>>702814
> создать отдельный проект
> настроить вооще редактор на двухпробельный таб с выставленной конвертацией при сохранении
> скачать двухпробельный ассет
> сохранить
> сбросить настройки вооще редактора на 4-пробельный таб
> перекинуть файлы
> ПРОФИТ
(А ищью Хуану надо закинуть следующего содержания: В файлы .gd следует добавить нечитаемую редактором, ну или содержащуюся в комментарии а-ля xml мета-инфу, содержащую как минимум, сколько пробелов следует рассматривать в данном скрипте как один таб. Закиньте, годаны.)
> #!tab:4!#
> extends Node
>
> func _ready(): pass
>>702817
После этого, разумеется, придётся перекачать заново все испорченные автоконвертацией ассеты с заменой gd-скриптов.
> попробуй вот эту опцию отключить
После этого, разумеется, придётся перекачать заново все испорченные автоконвертацией ассеты с заменой gd-скриптов.
>>702851
Для разработки - сишарп, для джемов - только гдскрипт. Все таки компиляция солюшна отжирает ценное время между итерациями.
Для разработки - сишарп, для джемов - только гдскрипт. Все таки компиляция солюшна отжирает ценное время между итерациями.
>>702851
Майкрософтовская студия традиционно сама автоматически формирует отступы блоков, ещё с 90х, а может с 80х. Так же поступают все уважаемые ИДЕ, от дельфи до райдера. Так что визуально разницы нет, только кроме отступов у тебя ещё скобачьки сверху-снизу для сиподобных, бегин-энд для паскальподобных, энд %операторнейм% для бейсика, торобоан ротарепо для шеллскрипта. Именно это легло в основу философии питона: "Если отступы и так ставят почти все (кроме школокульхацкеров с их кодом в одну строку), то чобы не сделать отступы синтаксическим элементом?" Так был рождён питон, бейсик 21 века.
Майкрософтовская студия традиционно сама автоматически формирует отступы блоков, ещё с 90х, а может с 80х. Так же поступают все уважаемые ИДЕ, от дельфи до райдера. Так что визуально разницы нет, только кроме отступов у тебя ещё скобачьки сверху-снизу для сиподобных, бегин-энд для паскальподобных, энд %операторнейм% для бейсика, торобоан ротарепо для шеллскрипта. Именно это легло в основу философии питона: "Если отступы и так ставят почти все (кроме школокульхацкеров с их кодом в одну строку), то чобы не сделать отступы синтаксическим элементом?" Так был рождён питон, бейсик 21 века.
>>702860
Это и есть главный фейл.
Rак раз на днях искал пару часов баг, из-за поехавшего при копи пасте отступа в if.
>Если отступы и так ставят почти все, то чобы не сделать отступы синтаксическим элементом?
Это и есть главный фейл.
Rак раз на днях искал пару часов баг, из-за поехавшего при копи пасте отступа в if.
>>702859
Нахуй джемы. По крайней мере такие в которых лишняя пара секунд на компиляцию настолько критична.
Да и в принципе нахуй джемы.
Нахуй джемы. По крайней мере такие в которых лишняя пара секунд на компиляцию настолько критична.
Да и в принципе нахуй джемы.
>>702860
Весь финт в том, что в этих языках ситуация "удалил пару пробелов в начале строки - программе пиздец", в принципе невозможна. Ты можешь вообще удалить все пробелы/табы в начале всех строк и код будет работать точно так же без изменений. Может быть его будет не так удобно читать, но работать он все равно будет. А вот у питухона, даже обычное действие сохранить-закрыть-открыть файл уже может похерить программу, если редактор в котором ты это делал, решит, что табы должны быть в 2 пробела, а не 4. А выкрики вроде, "код все равно открывают только в специализированных IDE где все настроено" идут нахуй, т.к. это просто не соответствует реальному положению вещей. Та же шняга с гитхабом все это показывает.
Их проблема не в том, что они сделали отступы элементом синтаксиса, а то как они это сделали.
Можно было взять любой другой символ, кроме пробела/таба и использовать его как отступ. Да даже сраное подчеркивание или точку, либо вообще свой выдумать. Тогда путаницы в принципе бы не было, т.к. при открытии в специальных питухонских IDE их можно было бы отображать как пробелы, а в любых других это были бы символы, которые ни человек, ни IDE-шка не спутает по случайности с пробелом/табом и не похерит листинг.
>>702860
Тру стори. И лет через 20 в учебниках про питон будут писать то же самое, что и про бейсик сейчас (вкатиться легко, но станешь калекой от программирования)
>Так что визуально разницы нет, только кроме отступов у тебя ещё скобачьки сверху-снизу для сиподобных, бегин-энд для паскальподобных, энд %операторнейм% для бейсика, торобоан ротарепо для шеллскрипта.
Весь финт в том, что в этих языках ситуация "удалил пару пробелов в начале строки - программе пиздец", в принципе невозможна. Ты можешь вообще удалить все пробелы/табы в начале всех строк и код будет работать точно так же без изменений. Может быть его будет не так удобно читать, но работать он все равно будет. А вот у питухона, даже обычное действие сохранить-закрыть-открыть файл уже может похерить программу, если редактор в котором ты это делал, решит, что табы должны быть в 2 пробела, а не 4. А выкрики вроде, "код все равно открывают только в специализированных IDE где все настроено" идут нахуй, т.к. это просто не соответствует реальному положению вещей. Та же шняга с гитхабом все это показывает.
>Именно это легло в основу философии питона: "Если отступы и так ставят почти все (кроме школокульхацкеров с их кодом в одну строку), то чобы не сделать отступы синтаксическим элементом?"
Их проблема не в том, что они сделали отступы элементом синтаксиса, а то как они это сделали.
Можно было взять любой другой символ, кроме пробела/таба и использовать его как отступ. Да даже сраное подчеркивание или точку, либо вообще свой выдумать. Тогда путаницы в принципе бы не было, т.к. при открытии в специальных питухонских IDE их можно было бы отображать как пробелы, а в любых других это были бы символы, которые ни человек, ни IDE-шка не спутает по случайности с пробелом/табом и не похерит листинг.
>>702860
>Так был рождён питон, бейсик 21 века.
Тру стори. И лет через 20 в учебниках про питон будут писать то же самое, что и про бейсик сейчас (вкатиться легко, но станешь калекой от программирования)
>>702865
На вкус и цвет товарищей нет. Вон выше по треду ОП обеснил, как решается проблема с отступами всего одной галочкой в настройках.
>>702871
Ну ХЗ, будем посмотреть. В отличие от своего духовного отца, питон таки вкатился в большой продакшон, на ём нейроночки пишут, например. И ничо, калеками не становятся. И с отступами проблем не имеют.
> Это и есть главный фейл.
На вкус и цвет товарищей нет. Вон выше по треду ОП обеснил, как решается проблема с отступами всего одной галочкой в настройках.
>>702871
> И лет через 20 в учебниках про питон будут писать то же самое, что и про бейсик сейчас (вкатиться легко, но станешь калекой от программирования)
Ну ХЗ, будем посмотреть. В отличие от своего духовного отца, питон таки вкатился в большой продакшон, на ём нейроночки пишут, например. И ничо, калеками не становятся. И с отступами проблем не имеют.
>>702874
Ты вообще ерунду пишешь.
Бейсик был повсеместно в большом продакшне (в винде настройки тыкал когда нибудь? А там vbs скрипты, ага)
Никто не пишет на нем нейроночки. На нем пишут конфиги к нейроночкам, а тот же numpy это Си.
Становятся, становятся. Большинство ученых очень хуевые программисты.
Конечно не имеют - это же не программа, а просто линейный конфиг.
Ты вообще ерунду пишешь.
>В отличие от своего духовного отца, питон таки вкатился в большой продакшон
Бейсик был повсеместно в большом продакшне (в винде настройки тыкал когда нибудь? А там vbs скрипты, ага)
>на ём нейроночки пишут
Никто не пишет на нем нейроночки. На нем пишут конфиги к нейроночкам, а тот же numpy это Си.
>калеками не становятся
Становятся, становятся. Большинство ученых очень хуевые программисты.
> И с отступами проблем не имеют.
Конечно не имеют - это же не программа, а просто линейный конфиг.
>>702874
Ага, а потом еще не забудь вернуть галочку обратно, а то другой проект по пизде разъедется. Да и вообще попробуй угадай, а нужно ли конкретно для этого исходника ее включать или нет.
Ну и пиздецовые ситуации, когда ты случайно, стер отступ и у тебя инструкция выскочила за пределы if-а или цикла и все продолжает работать, но совсем не так как должно, и хуй ты это отследишь.
Нахуй такие фломастеры.
>На вкус и цвет товарищей нет. Вон выше по треду ОП обеснил, как решается проблема с отступами всего одной галочкой в настройках.
Ага, а потом еще не забудь вернуть галочку обратно, а то другой проект по пизде разъедется. Да и вообще попробуй угадай, а нужно ли конкретно для этого исходника ее включать или нет.
Ну и пиздецовые ситуации, когда ты случайно, стер отступ и у тебя инструкция выскочила за пределы if-а или цикла и все продолжает работать, но совсем не так как должно, и хуй ты это отследишь.
Нахуй такие фломастеры.
>>702875
Хотел поспорить, но потом
Ой всё, кароч, иди нахуй, тролляка.
Хотел поспорить, но потом
> Большинство ученых очень хуевые программисты.
Ой всё, кароч, иди нахуй, тролляка.
>>702886
Это по предыдущему посту, не путаем. В крайнем посте галочку можно не возвращать.
> а потом еще не забудь вернуть галочку обратно
Это по предыдущему посту, не путаем. В крайнем посте галочку можно не возвращать.
>>702875
Поддвачну, все либы для машоба типа tensorflow - это высокопроизводительный многопоточный код на плюсах/сишке.
Питон нужен только для того, чтобы дата саентист (это ученый, математик, аналитик, а не программист) сформировал конфиг для этих нейроночек и запустил процесс обработки, дальше работает уже плюсовый код, заслуги питона в этом нет никакой, он нужен только для того, чтобы этот аналитик по быстрому накидал конфиг и получил результат без необходимости разбираться с плюсами/конпелять нативный код.
Ровно как и никакого программерского скилла для этого не нужно - надо знать математику, статистику, теорию вероятности, свою предметную область, никакого программирования как такового при этом не осуществляется.
>>702874
И правда ерунду пишешь.
"Нейроночки" это не большой продакшен, а скриптики на 100, 200, в редких случаях больше строк. Задача этих скриптов - взять данные, прогнать через сконфигуренную нейронку, сохранить/отдать другому сервису результат. Всё. Там кода и бизнес-логики как таковой нет.
А большой продакшен - это джава, .net, плюсы, там нет места слаботипизированным языкам.
Поддвачну, все либы для машоба типа tensorflow - это высокопроизводительный многопоточный код на плюсах/сишке.
Питон нужен только для того, чтобы дата саентист (это ученый, математик, аналитик, а не программист) сформировал конфиг для этих нейроночек и запустил процесс обработки, дальше работает уже плюсовый код, заслуги питона в этом нет никакой, он нужен только для того, чтобы этот аналитик по быстрому накидал конфиг и получил результат без необходимости разбираться с плюсами/конпелять нативный код.
Ровно как и никакого программерского скилла для этого не нужно - надо знать математику, статистику, теорию вероятности, свою предметную область, никакого программирования как такового при этом не осуществляется.
>>702874
>большой продакшен
>нейроночки
И правда ерунду пишешь.
"Нейроночки" это не большой продакшен, а скриптики на 100, 200, в редких случаях больше строк. Задача этих скриптов - взять данные, прогнать через сконфигуренную нейронку, сохранить/отдать другому сервису результат. Всё. Там кода и бизнес-логики как таковой нет.
А большой продакшен - это джава, .net, плюсы, там нет места слаботипизированным языкам.
Вот, кароч, чел предлагает свой метод борьбы с отступами https://habr.com/ru/post/501538/ статья про питон, но рассмотренные методы подходят и к гдскрипту.
Самое интересное, как водится, в комментах.
Самое интересное, как водится, в комментах.
55 Кб, 805x358>>702892
Мхех. Пост отменяется.
Мхех. Пост отменяется.
>>702889
Ты просто думаешь что раз они разбираются в матане или физике то и кодинг у них на уровне Александреску. Но это далеко не так.
И это ты еще не видел как они хуево Вордом пользуются.
Ты просто думаешь что раз они разбираются в матане или физике то и кодинг у них на уровне Александреску. Но это далеко не так.
И это ты еще не видел как они хуево Вордом пользуются.
>>702892
Годно. Ведь и сам редактор Годота вставляет pass в конце создаваемой функции.
Годно. Ведь и сам редактор Годота вставляет pass в конце создаваемой функции.
>>702892
Шедеврально. Питухонист по факту изобрел для питона аналог скобочек в других языках. И стоила ебля с отступами того, чтобы вернутся, к тому от чего отказались?
Шедеврально. Питухонист по факту изобрел для питона аналог скобочек в других языках. И стоила ебля с отступами того, чтобы вернутся, к тому от чего отказались?
девачьки, таб для кого придумали? Я хуееею...
>>702860
Мне кажется, авторы этой идеи так и не поняли, что отступы и скобочки нужны для разного. Отступы это удобный инструмент улучшения читаемости, но ужасно неудобный элемент синтаксиса. Скобочки это отличный и вполне естественный элемент синтаксиса, но читаемость они засоряют. Но если выбирать между языками со скобочками без отступов и с отступами без скобочек, я выберу первый. Потому что код пишут всё-таки для компиляторов, а не для людей.
Всё сказал.
>Именно это легло в основу философии питона: "Если отступы и так ставят почти все (кроме школокульхацкеров с их кодом в одну строку), то чтобы не сделать отступы синтаксическим элементом?"
Мне кажется, авторы этой идеи так и не поняли, что отступы и скобочки нужны для разного. Отступы это удобный инструмент улучшения читаемости, но ужасно неудобный элемент синтаксиса. Скобочки это отличный и вполне естественный элемент синтаксиса, но читаемость они засоряют. Но если выбирать между языками со скобочками без отступов и с отступами без скобочек, я выберу первый. Потому что код пишут всё-таки для компиляторов, а не для людей.
Всё сказал.
>>702997
Только если ты такой весь из себя хикка-одиночка.
>код пишут всё-таки для компиляторов, а не для людей.
Только если ты такой весь из себя хикка-одиночка.
А какой рендерер сам офф. билд годота использует под линуксом и можно ли его сменить где-то не билдя самому?
239 Кб, 1080x1920>>703060
Он работает в том режиме, который выставлен в правом верхнем углу.
Емнип есть какая то настройка в домашней директории
Или ты просто можешь поменять текстовым редактором в файле проекта, который открываешь.
Пишу по памяти, не за компом.
Он работает в том режиме, который выставлен в правом верхнем углу.
Емнип есть какая то настройка в домашней директории
Или ты просто можешь поменять текстовым редактором в файле проекта, который открываешь.
Пишу по памяти, не за компом.
>>703062
То есть если у проекта gles2, то у самого редактора тоже становится gles2? Ясненько, ну тогда intel-дрова для линупса не очень хорошо дружат и с gles2 и с gles3 godot-ом, что печаль.
То есть если у проекта gles2, то у самого редактора тоже становится gles2? Ясненько, ну тогда intel-дрова для линупса не очень хорошо дружат и с gles2 и с gles3 godot-ом, что печаль.
>>703065
А если использовать открытые дрова линукса? У меня искаробочный драйвер убунты поддерживал глес2. Потом я всё равно проприетарный поставил на свою ПЕЧ.
> не очень хорошо дружат
А если использовать открытые дрова линукса? У меня искаробочный драйвер убунты поддерживал глес2. Потом я всё равно проприетарный поставил на свою ПЕЧ.
>>703065
Да, многие на встройках жалуются.
Да, многие на встройках жалуются.
>>703066
Так интел вроде сам и выпускает только открытые дрова, а не как нвидия где есть и открытые и закрытые.
Причем смешно, то что при этом блендер на винде работал как говно, а под линем летает. Так что на обоих системах пайплайн мой сломан.
Так интел вроде сам и выпускает только открытые дрова, а не как нвидия где есть и открытые и закрытые.
Причем смешно, то что при этом блендер на винде работал как говно, а под линем летает. Так что на обоих системах пайплайн мой сломан.
>>703068
В общем, пора бы уже тебе купить свою первую видеокарту. Мальчик взрослый поди?
В общем, пора бы уже тебе купить свою первую видеокарту. Мальчик взрослый поди?
>>703074
Вопрос привычки. Я сам тоже не смог привыкнуть именно к связке шарпа с годотом, хотя сам шарп понравился и просто на формсах я чота своё мелкое пописываю.
Но люди есть, которые на шарп перешли, наш анон выше по треду, и вообще куча народу, даже на ютубе есть блогер, который пилит серию туториалов по годот-шарпу.
https://www.youtube.com/watch?v=ra-BJ-fJ6Qo
> жутко геморойно и проще писать на гдскрипте и не выёживаться
Вопрос привычки. Я сам тоже не смог привыкнуть именно к связке шарпа с годотом, хотя сам шарп понравился и просто на формсах я чота своё мелкое пописываю.
Но люди есть, которые на шарп перешли, наш анон выше по треду, и вообще куча народу, даже на ютубе есть блогер, который пилит серию туториалов по годот-шарпу.
https://www.youtube.com/watch?v=ra-BJ-fJ6Qo
>>703074
Нет там ничего геморойного. Все на изи.
>Так как я изучал его тоже, попробовал настроить, но как понял, это жутко геморойно и проще писать на гдскрипте и не выёживаться.
Нет там ничего геморойного. Все на изи.
>>703078
Недавно переехал на C#, настроено примерно как на видео, только другой плагин в vs code (C# Tools for Godot)
Примерный сетап: Моно и .Net Core 3.1 - не знаю что из этого нужно, ставил полгода назад
vs code + плагины C#, Mono Debug, C# Tools for Godot, прикручиваю Roslynator для линтера (через StyleCop(Omnisharp))
В папке проекта настроены .vscode/launch.json и tasks.json по образцу коммента под видео. Таким образом, запуск по F5 настроен на Attach, у которого предварительным таском прописан запуск Годота
В Годоте в настройках проекта убрана галочка wait for debugger, а в настройках редактора - внешним редактором прописан vs code с флагами {project} --goto {file}:{line}:{col}
Автодополнение работает учитывая текущую выбранную сцену в редакторе Годота (т.е. если редактируешь Player.cs и отрыта Player.tscn, то дополнение есть, а если Level.tscn - то нет)
GD.Print срет в терминал VS Code. Работают брейкпоинты, просмотр переменных, стек вызовов.
Недавно переехал на C#, настроено примерно как на видео, только другой плагин в vs code (C# Tools for Godot)
Примерный сетап: Моно и .Net Core 3.1 - не знаю что из этого нужно, ставил полгода назад
vs code + плагины C#, Mono Debug, C# Tools for Godot, прикручиваю Roslynator для линтера (через StyleCop(Omnisharp))
В папке проекта настроены .vscode/launch.json и tasks.json по образцу коммента под видео. Таким образом, запуск по F5 настроен на Attach, у которого предварительным таском прописан запуск Годота
В Годоте в настройках проекта убрана галочка wait for debugger, а в настройках редактора - внешним редактором прописан vs code с флагами {project} --goto {file}:{line}:{col}
Автодополнение работает учитывая текущую выбранную сцену в редакторе Годота (т.е. если редактируешь Player.cs и отрыта Player.tscn, то дополнение есть, а если Level.tscn - то нет)
GD.Print срет в терминал VS Code. Работают брейкпоинты, просмотр переменных, стек вызовов.
>>703084
+ настроен .gitignore с помощью какого то онлайн сервиса
+ настроен .gitignore с помощью какого то онлайн сервиса
>>703084
Вот этого не понел, когда смотрел видосы по этим плагинам и тулзам. Редактор всегда запущен же. По крайней мере у меня. Я ж там собственно сцены редактирую.
> предварительным таском прописан запуск Годота
Вот этого не понел, когда смотрел видосы по этим плагинам и тулзам. Редактор всегда запущен же. По крайней мере у меня. Я ж там собственно сцены редактирую.
>>703293
Что с ходу удалось найти:
----------
Godot C# game development
https://www.youtube.com/watch?v=WHx0l_nKCU8&list=PLm_vxcRCNKYzIyUjHtlWAk_mM7-QUD5kw&index=8
Без комментариев, все чисто на визуале объясняется. Но довольно старые уроки (2017 год)
-------
C# Godot tutorials
https://www.youtube.com/watch?v=Ej2p_TPGCDE&list=PLMgDVIa0Pg8XMe1GVc5eg0Rwi-cXqIR6q
Более свежее (2019-2020 г.), с голосом. У автора достаточно хороший английский, все понятно без сабов.
-------
Godot C# Top Down Shooter Tutorials
https://www.youtube.com/watch?v=JTXan5M92ms&list=PLMgDVIa0Pg8W54idRaVn2ZCnFmQ7gWMmG
Тот же автор совсем свежак, видео делаются сейчас, пока всего 3 штуки.
------------
Сразу говорю, что сами видео не смотрел от и до, просто пролистал. Вполне возможно, что внутри наличествует говнокод. Я сам без уроков делаю, внутренней документации достаточно.
Что с ходу удалось найти:
----------
Godot C# game development
https://www.youtube.com/watch?v=WHx0l_nKCU8&list=PLm_vxcRCNKYzIyUjHtlWAk_mM7-QUD5kw&index=8
Без комментариев, все чисто на визуале объясняется. Но довольно старые уроки (2017 год)
-------
C# Godot tutorials
https://www.youtube.com/watch?v=Ej2p_TPGCDE&list=PLMgDVIa0Pg8XMe1GVc5eg0Rwi-cXqIR6q
Более свежее (2019-2020 г.), с голосом. У автора достаточно хороший английский, все понятно без сабов.
-------
Godot C# Top Down Shooter Tutorials
https://www.youtube.com/watch?v=JTXan5M92ms&list=PLMgDVIa0Pg8W54idRaVn2ZCnFmQ7gWMmG
Тот же автор совсем свежак, видео делаются сейчас, пока всего 3 штуки.
------------
Сразу говорю, что сами видео не смотрел от и до, просто пролистал. Вполне возможно, что внутри наличествует говнокод. Я сам без уроков делаю, внутренней документации достаточно.
>>703327
Это все ссылки на плейлисты, если что
Это все ссылки на плейлисты, если что
>>703327
Удваиваю.
Видеоуроки - чисто как развлечение. С говнокода поугарать, с картавости и/или всратости ютубера. Покекать в комментах. Ну а потом опять за работу.
> Я сам без уроков делаю, внутренней документации достаточно.
Удваиваю.
Видеоуроки - чисто как развлечение. С говнокода поугарать, с картавости и/или всратости ютубера. Покекать в комментах. Ну а потом опять за работу.
>>703373
И поддержу, и не соглашусь.
Для меня, как вообще не программиста, видеоуроки оказались хорошим стартом, чтобы увидеть, как вообще на этом творят настоящие живые люди. Но дальше - только доки, потому что в них проще найти ответы на бесконечно подкидываемые моим воображением вопросы "а можно ли сделать вот так". Если уж совсем не нахожу ответа, спрашиваю тут в тредике, пару раз получал довольно неожиданные советы, которые в итоге реализовывал.
И поддержу, и не соглашусь.
Для меня, как вообще не программиста, видеоуроки оказались хорошим стартом, чтобы увидеть, как вообще на этом творят настоящие живые люди. Но дальше - только доки, потому что в них проще найти ответы на бесконечно подкидываемые моим воображением вопросы "а можно ли сделать вот так". Если уж совсем не нахожу ответа, спрашиваю тут в тредике, пару раз получал довольно неожиданные советы, которые в итоге реализовывал.
>>703376
Для старта - всё верно, ютуб помогает. Но потом наступает момент, когда ты перерастаешь уровень ютуб-учителей, видишь, что они делают упрощённые проекты для новичков, пишут упрощённый код для новичков, понимаешь, что ничего нового в течение следующих N минут видоса ты не узнаешь.
И вот тогда ты переходишь на документацию.
Для старта - всё верно, ютуб помогает. Но потом наступает момент, когда ты перерастаешь уровень ютуб-учителей, видишь, что они делают упрощённые проекты для новичков, пишут упрощённый код для новичков, понимаешь, что ничего нового в течение следующих N минут видоса ты не узнаешь.
И вот тогда ты переходишь на документацию.
>>703293
Как вариант могу предложить изучать туториалы по GDScript и отдельно уроки по C#.
Ведь алгоритм можно воспроизвести практически построчно.
(единственное что я так и не придумал как заменить однострочник yield(get_tree().create_timer(1.0), "timeout")
Как вариант могу предложить изучать туториалы по GDScript и отдельно уроки по C#.
Ведь алгоритм можно воспроизвести практически построчно.
(единственное что я так и не придумал как заменить однострочник yield(get_tree().create_timer(1.0), "timeout")
>>703554
Это лучший тред раздела, вообще-то.
Это лучший тред раздела, вообще-то.
182 Кб, 822x460Еее, детка! ГОДОТ!
>>704382
Проверял в прошлом году, до батчинга, жрали прилично. Точнее неприлично. На свежаке не проверял.
Проверял в прошлом году, до батчинга, жрали прилично. Точнее неприлично. На свежаке не проверял.
>>704384
Я имел в виду скрытые по visible=false
Сейчас чекнул, там почти не жрут, в пределах погрешности.
На время разработки пойдет. Просто так вышло, что я импортировал все уровни отдельными слоями.
Я имел в виду скрытые по visible=false
Сейчас чекнул, там почти не жрут, в пределах погрешности.
На время разработки пойдет. Просто так вышло, что я импортировал все уровни отдельными слоями.
В общем, анончик спрашивал как делать по быстрому логические игры.
Я не очень понял, интересует его 2д или 3д. Но неважно.
Для 2д в Годоте есть TileMap, а для 3д - GridMap.
Соответственно в случае 2д мы закидываем в папку проекта картинку с фигурами. (или по одной). Потом в тайлмапе создаем тайлсет, в нем добавляем атлас на эту картинку. Все, с этого момента можно работать с тайлмапом просто как с двухмерным массивом.
В 3д примерно так же, создаем GridMap, закидываем модельки фигур в папку (лучше по одной), создаем новую сцену закидываем все фигурки в новую сцену, конвертируем и сохраняем ее как библиотеку тайлов (meshlib), возможно тут захочется поменять моделькам материалы. Все, опять можем работать как с 3д массивом.
Надо добавить само поле - это можно сделать хоть тупо сделав бокс, на который натянуть текстуру в клеточку.
Другой подход будет заключаться в, например, создании сцены-объекта для фигур. В него кидаем все виды фигур и пишем простенький скрипт, который делает только одну из них видимой. Эти объекты можно расставлять по игровому уровню. Если ты включишь режим snap, то и расставляться они будут по сетке. Но тебе уже придется самому вычислять их координаты потом. Но в принципе ничего сложного, особенно если ты сделаешь их с шагом 1.
Для выделения и перемещения фигур код придется спиздить, ну или если надо я потом с ним могу помочь.
Менюшки рисуются довольно просто и быстро, накидываешь на сцену лейблы, кнопки, по вкусу задаешь им визуальные стили покрасивее, шрифты, все это надо сначала закинуть в проект. И добавляешь обработчики нажатий.
Если что то будет не понятно - спрашивай, тут всегда ответят.
Я не очень понял, интересует его 2д или 3д. Но неважно.
Для 2д в Годоте есть TileMap, а для 3д - GridMap.
Соответственно в случае 2д мы закидываем в папку проекта картинку с фигурами. (или по одной). Потом в тайлмапе создаем тайлсет, в нем добавляем атлас на эту картинку. Все, с этого момента можно работать с тайлмапом просто как с двухмерным массивом.
В 3д примерно так же, создаем GridMap, закидываем модельки фигур в папку (лучше по одной), создаем новую сцену закидываем все фигурки в новую сцену, конвертируем и сохраняем ее как библиотеку тайлов (meshlib), возможно тут захочется поменять моделькам материалы. Все, опять можем работать как с 3д массивом.
Надо добавить само поле - это можно сделать хоть тупо сделав бокс, на который натянуть текстуру в клеточку.
Другой подход будет заключаться в, например, создании сцены-объекта для фигур. В него кидаем все виды фигур и пишем простенький скрипт, который делает только одну из них видимой. Эти объекты можно расставлять по игровому уровню. Если ты включишь режим snap, то и расставляться они будут по сетке. Но тебе уже придется самому вычислять их координаты потом. Но в принципе ничего сложного, особенно если ты сделаешь их с шагом 1.
Для выделения и перемещения фигур код придется спиздить, ну или если надо я потом с ним могу помочь.
Менюшки рисуются довольно просто и быстро, накидываешь на сцену лейблы, кнопки, по вкусу задаешь им визуальные стили покрасивее, шрифты, все это надо сначала закинуть в проект. И добавляешь обработчики нажатий.
Если что то будет не понятно - спрашивай, тут всегда ответят.
Привет анон! В ньюфаня треде задал вопрос, мол, без программирования реально художнику сделать хоть что-нибудь - желательно с мультиплеером
На мои глупые маняфантазии пришло 2 серьезных ответа - годот и юнити (плеймейкер + фотон для мультика)
Спрошу пожалуй тут - как считаешь, что лучше мне подойдет? Годот кажется мне лучше ибо он насколько я понял полностью бесплатный, а на юнити придётся скрабить этот самый плеймейкер ибо платить за него деньги ради мелкого хобби я не желаю
Но вдруг у тебя есть доводы/аргументы за и против, был бы очень рад их послушать
На мои глупые маняфантазии пришло 2 серьезных ответа - годот и юнити (плеймейкер + фотон для мультика)
Спрошу пожалуй тут - как считаешь, что лучше мне подойдет? Годот кажется мне лучше ибо он насколько я понял полностью бесплатный, а на юнити придётся скрабить этот самый плеймейкер ибо платить за него деньги ради мелкого хобби я не желаю
Но вдруг у тебя есть доводы/аргументы за и против, был бы очень рад их послушать
33,9 Мб, mp4,1920x1080, 0:06
>>705431
Без программирования вряд ли выйдет. Визуал скрипт это то же замаскированное программирование. Завтра могу подробнее, сейчас уже сплю.
Если хочешь можешь почитать в прошлом треде в конце.
>>697739 →
>>697740 →
>>697741 →
Мультиплеер думаю без программирования тоже не выйдет.
Хотя примеры есть, надо смотреть.
В принципе есть какой то ассет который тупо реплицирует положение объекта с сервера на клиент.
Без программирования вряд ли выйдет. Визуал скрипт это то же замаскированное программирование. Завтра могу подробнее, сейчас уже сплю.
Если хочешь можешь почитать в прошлом треде в конце.
>>697739 →
>>697740 →
>>697741 →
Мультиплеер думаю без программирования тоже не выйдет.
Хотя примеры есть, надо смотреть.
В принципе есть какой то ассет который тупо реплицирует положение объекта с сервера на клиент.
>>705431
А реально ли программисту без рисования сделать графон для своей игры? Технически реально, практически - говно на выходе.
Программировать все равно придется. Так что либо кооперируйся с кем-нибудь, либо сам изучай кодинг. Как показывает опыт научить художника минимальным скилам программирования намного легче, чем программиста рисованию.
>Привет анон! В ньюфаня треде задал вопрос, мол, без программирования реально художнику сделать хоть что-нибудь - желательно с мультиплеером
А реально ли программисту без рисования сделать графон для своей игры? Технически реально, практически - говно на выходе.
Программировать все равно придется. Так что либо кооперируйся с кем-нибудь, либо сам изучай кодинг. Как показывает опыт научить художника минимальным скилам программирования намного легче, чем программиста рисованию.
>>705444
Вот с этого больше всего горит. Особенно, когда художники жалуются
Кодинг - это сложно, но намного легче вкатиться в кодинг с нуля, чем в рисование с нуля.
Я рисую уже джва года и до сих пор нихуя не получается.
За эти джва года я освоил две новые парадигмы в кодинге и выучил два новых языка.
Был бы я художником.
Эх, были бы у бабушки яйца, а у дедушки сиськи...
> научить художника минимальным скилам программирования намного легче, чем программиста рисованию
Вот с этого больше всего горит. Особенно, когда художники жалуются
> кококодинг этоо таак слоожно!
Кодинг - это сложно, но намного легче вкатиться в кодинг с нуля, чем в рисование с нуля.
Я рисую уже джва года и до сих пор нихуя не получается.
За эти джва года я освоил две новые парадигмы в кодинге и выучил два новых языка.
Был бы я художником.
Эх, были бы у бабушки яйца, а у дедушки сиськи...
>>705524
Представь себе что у них другая половина лучше развита - и у них то же самое, они могут за джва года освоить пару техник рисования задрочить там свето тень и анатомию, и не быть в состоянии написать что то сложнее if.
Представь себе что у них другая половина лучше развита - и у них то же самое, они могут за джва года освоить пару техник рисования задрочить там свето тень и анатомию, и не быть в состоянии написать что то сложнее if.
>>705524
Основная суть художника - запрограммировать у себя в голове встроенный RTX.
По этой причине у личинусов на уроках ИЗО первому чему учат - это нахуярить на листе бумаги кубики пирамидки и прочие шарики и сделать с помощью того же карандаша им PBR.
Потом уже идет надроч силуэта и в ход идут те самые кружки с последующим усложнением формы силуэта
Основная суть художника - запрограммировать у себя в голове встроенный RTX.
По этой причине у личинусов на уроках ИЗО первому чему учат - это нахуярить на листе бумаги кубики пирамидки и прочие шарики и сделать с помощью того же карандаша им PBR.
Потом уже идет надроч силуэта и в ход идут те самые кружки с последующим усложнением формы силуэта
Кто-нибудь реализовывал шаблон MVVM на GDScript'е? Я тут курю мануалы по MVVM и задумался, насколько он применим к играм? Насколько он реализуем в годоте? Подписаться на изменения данных средствами языка можно. Разделить данные и логику тоже можно, средствами файловой системы. Описание интерфейса языком разметки присутствует, хоть и не ХАМЛо. Остаётся только прикрутить аналог INotifyPropertyChanged к каждому требующемуся контролу/виджету через сабкласс - и готово! или нет?
>>705937
Или всё же придётся использовать существующие фреймворки в шарпе, типа авалонии, а годот прикрутить как визуальный бэк-энд вместо, скажем avalonia.win32 или avalonia.x11 ?
Или всё же придётся использовать существующие фреймворки в шарпе, типа авалонии, а годот прикрутить как визуальный бэк-энд вместо, скажем avalonia.win32 или avalonia.x11 ?
>>705948
Честно говоря, я только начал вплотную изучать вопрос и ещё сам не понял, что конкретно мне тулят под этой волшебной фразой MVVM. Из статей и документации я почерпнул пока что только абстрактные лозунги, типа Хочу получить динамически подстраивающийся под меняющиеся условия интерфейс, действующий по заложенным внутрь него правилам, легко масштабируемый от мини-проекта инди-студии из одного человека, до масштабов корпоративного продукта.
Шаблон состоит из трёх частей:
Model - непосредственно логика, может быть написана на любом языке, любой среды и лежать где угодно, хоть в сети, отдавая данные по запросу, принимая запросы, похожа на сервер.
ViewModel - Самая сложная часть, которая являет собой связку между остальными двумя частями. Если View и Model представить себе, как слепых мудрецов из знаменитой притчи, до ViewModel для View выглядит как View, для Model выглядит как Model.
View - это собственно сам интерфейс, который строится динамически, получая данные из ViewModel.
> что ты хочешь получить
> на примере?
Честно говоря, я только начал вплотную изучать вопрос и ещё сам не понял, что конкретно мне тулят под этой волшебной фразой MVVM. Из статей и документации я почерпнул пока что только абстрактные лозунги, типа Хочу получить динамически подстраивающийся под меняющиеся условия интерфейс, действующий по заложенным внутрь него правилам, легко масштабируемый от мини-проекта инди-студии из одного человека, до масштабов корпоративного продукта.
Шаблон состоит из трёх частей:
Model - непосредственно логика, может быть написана на любом языке, любой среды и лежать где угодно, хоть в сети, отдавая данные по запросу, принимая запросы, похожа на сервер.
ViewModel - Самая сложная часть, которая являет собой связку между остальными двумя частями. Если View и Model представить себе, как слепых мудрецов из знаменитой притчи, до ViewModel для View выглядит как View, для Model выглядит как Model.
View - это собственно сам интерфейс, который строится динамически, получая данные из ViewModel.
>>705950
Ну хз я MVVM сам толком никогда не понимал.
На примере я имел в виду на каком то конкретном.
То есть какой нибудь контрол, например слайдер с цифиркой.
У нас есть модель - собственно переменная с цифиркой
Допустим у модели есть какая то логика - хотя бы ограничивать минимальное/максимальное значение
У нас есть вью - это отображение цифирки и отображение слайдера, и еще в него можно кликать.
Допустим у вью тоже есть своя логика - слайдер двигается к месту куда кликнули постепенно, с определенной скоростью.
Ну вот я просто создам сцену, заведу переменную target_value, move_speed, и буду в process двигать к ней. Может быть, добавлю сигналы on_changed и on_finished_animation. Это, наверное, MVP?
А что предлагает MVVM? Там есть декларативные связывания. Ну писать TSCN ручками вряд ли кто то захочет в здравом уме. Тогда надо экспортить какие то переменные, чтобы можно было в редакторе их редактировать. А что туда писать? Пути к переменным, по аналогии к путям к нодам? В принципе в редакторе уже что-то подобное есть, ведь в анимейшн плеере можно анимировать, например, чей-то position:x
Ну хз я MVVM сам толком никогда не понимал.
На примере я имел в виду на каком то конкретном.
То есть какой нибудь контрол, например слайдер с цифиркой.
У нас есть модель - собственно переменная с цифиркой
Допустим у модели есть какая то логика - хотя бы ограничивать минимальное/максимальное значение
У нас есть вью - это отображение цифирки и отображение слайдера, и еще в него можно кликать.
Допустим у вью тоже есть своя логика - слайдер двигается к месту куда кликнули постепенно, с определенной скоростью.
Ну вот я просто создам сцену, заведу переменную target_value, move_speed, и буду в process двигать к ней. Может быть, добавлю сигналы on_changed и on_finished_animation. Это, наверное, MVP?
А что предлагает MVVM? Там есть декларативные связывания. Ну писать TSCN ручками вряд ли кто то захочет в здравом уме. Тогда надо экспортить какие то переменные, чтобы можно было в редакторе их редактировать. А что туда писать? Пути к переменным, по аналогии к путям к нодам? В принципе в редакторе уже что-то подобное есть, ведь в анимейшн плеере можно анимировать, например, чей-то position:x
24 Кб, 320x512>>698054 (OP)
Привет, я нюфаня. Нубский вопрос. Я думаю.
Сейчас собрался скомпилировать игру на ПК, но что-то пошло не так. У меня годот стимовский и я нашёл только компиляцию для планшетов, а как для пк компилировать? Или это уже нужно платную версию годота покупать?
Привет, я нюфаня. Нубский вопрос. Я думаю.
Сейчас собрался скомпилировать игру на ПК, но что-то пошло не так. У меня годот стимовский и я нашёл только компиляцию для планшетов, а как для пк компилировать? Или это уже нужно платную версию годота покупать?
>>706063
Там при экспорте должна быть кнопочка управлять шаблонами - скачать с оф зеркала. Впрочем не знаю что там в стимовской версии.
Там при экспорте должна быть кнопочка управлять шаблонами - скачать с оф зеркала. Впрочем не знаю что там в стимовской версии.
>>706066
Всё разобрался, спасибо. Оказывается всё делается в одну кнопку, если уже скачен пакет, хрен пойми чего.
И главное сишарп работает!
А есть какой ни будь способ подключить вижуал студию?
Всё разобрался, спасибо. Оказывается всё делается в одну кнопку, если уже скачен пакет, хрен пойми чего.
И главное сишарп работает!
А есть какой ни будь способ подключить вижуал студию?
>>706070
Пока шта только для vs code
https://marketplace.visualstudio.com/items?itemName=geequlim.godot-tools
Пока шта только для vs code
https://marketplace.visualstudio.com/items?itemName=geequlim.godot-tools
>>706070
В вижуал студии ты можешь просто открыть созданный годотом солюшен и редактировать.
В вижуал студии ты можешь просто открыть созданный годотом солюшен и редактировать.
>>706076
Миллионом способов.
У тебя в игре наверняка планируются сохранения, так? Вот и задействуй механизм сохранений для сохранения данных в сцене.
Миллионом способов.
У тебя в игре наверняка планируются сохранения, так? Вот и задействуй механизм сохранений для сохранения данных в сцене.
>>706079
Но наверняка ты следующим вопросом спросишь, а как сделоть механизм сохранений?
Я всем рекомендую антипаттерн "синглтон". В случае с сохранениями, синглтоном является игровой мир, состоящий из объекта с полями и функций чтения записи в поля этого мира. Игровой мир существует всегда. Каждый объект подлежащий сохранению пишет в игровой мир данные о себе, ровно в тот момент, когда данные эти изменились. По твоему запросу игровой мир отдаёт подготовленный жсон-объект, пригодный для записи в сейв-файл или для записи в переменную как чек-поинт из которого можно быстро загрузиться, не прибегая к файловым операциям. По твоему запросу игровой мир получает подготовленный тобой сейв-словарь и загружает его в себя. На периоды сохранения и загрузки, игровой мир должен переходить в режим только-чтение, не давая существующим объектам производить запись.
Это в общих чертах система сохранения.
Теперь, как нам её задействовать в твоём вопросе >>706076 думаю ты уже догадался. При выгрузке сцены все необходимые данные уже записаны в игровом мире, так как запись ведется постоянно, по факту появляения изменений. А вот при загрузке новой сцены, новая сцена сразу пишет туда, что сейчас она является активной сценой. И она читает оттуда переменные, относящиеся к ней: таак, читает сцена, сундук_3 опустошён, дерево_6 срублено, моб_5 убит, труп лежит в точке (1108, 637), инвентарь трупа опустошён, расставим остальные объекты по дефолту, время суток - вечер, загрузим вечерний скайбокс, ветер северо-западный, 3 м/с, загрузим данные в шейдер листвы и травы.
Но наверняка ты следующим вопросом спросишь, а как сделоть механизм сохранений?
Я всем рекомендую антипаттерн "синглтон". В случае с сохранениями, синглтоном является игровой мир, состоящий из объекта с полями и функций чтения записи в поля этого мира. Игровой мир существует всегда. Каждый объект подлежащий сохранению пишет в игровой мир данные о себе, ровно в тот момент, когда данные эти изменились. По твоему запросу игровой мир отдаёт подготовленный жсон-объект, пригодный для записи в сейв-файл или для записи в переменную как чек-поинт из которого можно быстро загрузиться, не прибегая к файловым операциям. По твоему запросу игровой мир получает подготовленный тобой сейв-словарь и загружает его в себя. На периоды сохранения и загрузки, игровой мир должен переходить в режим только-чтение, не давая существующим объектам производить запись.
Это в общих чертах система сохранения.
Теперь, как нам её задействовать в твоём вопросе >>706076 думаю ты уже догадался. При выгрузке сцены все необходимые данные уже записаны в игровом мире, так как запись ведется постоянно, по факту появляения изменений. А вот при загрузке новой сцены, новая сцена сразу пишет туда, что сейчас она является активной сценой. И она читает оттуда переменные, относящиеся к ней: таак, читает сцена, сундук_3 опустошён, дерево_6 срублено, моб_5 убит, труп лежит в точке (1108, 637), инвентарь трупа опустошён, расставим остальные объекты по дефолту, время суток - вечер, загрузим вечерний скайбокс, ветер северо-западный, 3 м/с, загрузим данные в шейдер листвы и травы.
>>706070
Лично я пользуюсь VS Code, но думаю и студию можно подключить.
Лично я пользуюсь VS Code, но думаю и студию можно подключить.
>>706076
Заводишь отдельную сцену, например GameState.
И в ней скрипт, в котором будут собственно глобальные переменные (или геттеры-сеттеры).
И все это удовольствие в настройках проекта - в автолоад.
И там хрванить состояние игры (например isBossDead = false, и т.д.)
Заводишь отдельную сцену, например GameState.
И в ней скрипт, в котором будут собственно глобальные переменные (или геттеры-сеттеры).
И все это удовольствие в настройках проекта - в автолоад.
И там хрванить состояние игры (например isBossDead = false, и т.д.)
215 Кб, 400x400>>706101
Да, я Пётр из Ютуба и это мой любимый тред на дваче.
Да, я Пётр из Ютуба и это мой любимый тред на дваче.
Вот я пропустил знаменательный момент!
Наш движок был запримечен тёмным гением российского инфоцыганства!
https://www.youtube.com/watch?v=xKbZQHthbR8
Наш движок был запримечен тёмным гением российского инфоцыганства!
https://www.youtube.com/watch?v=xKbZQHthbR8
А, а , а можно ли каким-то образом не просто сохранять сцену, а не останавливать её работу при смене на новую?
>>706615
Опенворлд? Да? Да?
Загружаешь первую и единственную сцену World и подгружаешь локации к ней чайлдами по мере приближения к ним игрока. По мере удаления - выгружаешь. Но есть один нюанс. Загрузка и выгрузка должна работать умно, в объектном пуле, потому что создание объекта (выделение памяти в куче) - затратная операция. Поэтому тебе нужно организовать пул объектов, которые будут держателями локаций и будут крутиться каруселью перед глазами игрока, показывая ему то рифтен, то винтерхолд с солитьюдом.
Опенворлд? Да? Да?
Загружаешь первую и единственную сцену World и подгружаешь локации к ней чайлдами по мере приближения к ним игрока. По мере удаления - выгружаешь. Но есть один нюанс. Загрузка и выгрузка должна работать умно, в объектном пуле, потому что создание объекта (выделение памяти в куче) - затратная операция. Поэтому тебе нужно организовать пул объектов, которые будут держателями локаций и будут крутиться каруселью перед глазами игрока, показывая ему то рифтен, то винтерхолд с солитьюдом.
>>706641
А причем тут вообще выделение на куче и пул объектов? Как ты себе это представляешь в случае годота?
А причем тут вообще выделение на куче и пул объектов? Как ты себе это представляешь в случае годота?
>>706727
Два треда назад подробно рассмотрели.
В качестве пулов объектов прекрасно подходит механизм чайлдов в нодах. Заводишь ноду, которая не вводится в дерево сцены (далее: Бэкап-нода). К этой ноде в потомки добавляешь нужные ноды (далее: Чанки). При добавлении идёт нагрузка на комп, так что делаешь это один раз при создании абстракции игрового мира / игрового поля (далее: Игра). Далее, при необходимости ввести чанк в игру, меняешь ему парента с бэкап-ноды на игру. При необходимости вывести - меняешь парента с игры на бэкап-ноду.
Все выведенные из дерева сцены ноды вызывают колбэк _exit_tree и перестают обрабатывать _process... колбэки. Соответственно, все введённые репарентом в дерево сцены - снова выполняют _enter_tree и возобновляют вызов _process... коллбэков. Это нужно знать и активно использовать в этом, не побоюсь этого слова, паттерне.
Загрузку ресурсов следует делать в несколько этапов и в несколько потоков.
Следует завести себе не менее двух уровней детализации в зависимости от дальности от игрока. Назовём их ближний, средний и дальний.
Приближение игрока: На дальнем уровне активных чанков нет, на среднем уровне чанков всё ещё нет, но они уже начали фоновую загрузку ресурсов, на ближнем уровне чанки с загруженными ресурсами вводятся в дерево сцены репарентом из бэкап-ноды в игру.
Отдаление игрока: На ближнем уровне чанки работают в сцене, но уже помечены в очередь на вывод, на среднем чанки выведены из сцены, но сохраняют загруженные в себя ресурсы, на случай, если игрок пойдёт обратно, на дальнем чанки выгружают из себя ресурсы и помечаются, как свободные.
Свободные чанки не имеют ни типа, ни координат в игре, они получают тип и координаты, когда получают данные о ресурсах, которые им следует загрузить. Таким образом я в самом начале выразил это как карусель: Чанки как бы вращаются всё время вокруг игрока, выгружая из себя объекты позади и загружая объекты впереди.
И ещё раз повторю, загрузка ресурсов должна идти в несколько потоков. Без этого даже не пытайся зделоть опенворлд с корованами. Должна быть возможность не только быстро и одновременно, не нагружая основной поток, загружать ресурсы, но и возможность отменять начатую загрузку на любом этапе. Потому что игрок ходит рандомно. Только что он шёл на север и там прогружались замки, горы, тролли, и вдруг он резко развернулся назад и пошёл на юг, и надо срочно бросать загрузку и грузить лес, эльфов, домики деревянные.
> Как ты себе это представляешь в случае годота?
Два треда назад подробно рассмотрели.
В качестве пулов объектов прекрасно подходит механизм чайлдов в нодах. Заводишь ноду, которая не вводится в дерево сцены (далее: Бэкап-нода). К этой ноде в потомки добавляешь нужные ноды (далее: Чанки). При добавлении идёт нагрузка на комп, так что делаешь это один раз при создании абстракции игрового мира / игрового поля (далее: Игра). Далее, при необходимости ввести чанк в игру, меняешь ему парента с бэкап-ноды на игру. При необходимости вывести - меняешь парента с игры на бэкап-ноду.
Все выведенные из дерева сцены ноды вызывают колбэк _exit_tree и перестают обрабатывать _process... колбэки. Соответственно, все введённые репарентом в дерево сцены - снова выполняют _enter_tree и возобновляют вызов _process... коллбэков. Это нужно знать и активно использовать в этом, не побоюсь этого слова, паттерне.
Загрузку ресурсов следует делать в несколько этапов и в несколько потоков.
Следует завести себе не менее двух уровней детализации в зависимости от дальности от игрока. Назовём их ближний, средний и дальний.
Приближение игрока: На дальнем уровне активных чанков нет, на среднем уровне чанков всё ещё нет, но они уже начали фоновую загрузку ресурсов, на ближнем уровне чанки с загруженными ресурсами вводятся в дерево сцены репарентом из бэкап-ноды в игру.
Отдаление игрока: На ближнем уровне чанки работают в сцене, но уже помечены в очередь на вывод, на среднем чанки выведены из сцены, но сохраняют загруженные в себя ресурсы, на случай, если игрок пойдёт обратно, на дальнем чанки выгружают из себя ресурсы и помечаются, как свободные.
Свободные чанки не имеют ни типа, ни координат в игре, они получают тип и координаты, когда получают данные о ресурсах, которые им следует загрузить. Таким образом я в самом начале выразил это как карусель: Чанки как бы вращаются всё время вокруг игрока, выгружая из себя объекты позади и загружая объекты впереди.
И ещё раз повторю, загрузка ресурсов должна идти в несколько потоков. Без этого даже не пытайся зделоть опенворлд с корованами. Должна быть возможность не только быстро и одновременно, не нагружая основной поток, загружать ресурсы, но и возможность отменять начатую загрузку на любом этапе. Потому что игрок ходит рандомно. Только что он шёл на север и там прогружались замки, горы, тролли, и вдруг он резко развернулся назад и пошёл на юг, и надо срочно бросать загрузку и грузить лес, эльфов, домики деревянные.
>>706727
Два треда назад подробно рассмотрели.
В качестве пулов объектов прекрасно подходит механизм чайлдов в нодах. Заводишь ноду, которая не вводится в дерево сцены (далее: Бэкап-нода). К этой ноде в потомки добавляешь нужные ноды (далее: Чанки). При добавлении идёт нагрузка на комп, так что делаешь это один раз при создании абстракции игрового мира / игрового поля (далее: Игра). Далее, при необходимости ввести чанк в игру, меняешь ему парента с бэкап-ноды на игру. При необходимости вывести - меняешь парента с игры на бэкап-ноду.
Все выведенные из дерева сцены ноды вызывают колбэк _exit_tree и перестают обрабатывать _process... колбэки. Соответственно, все введённые репарентом в дерево сцены - снова выполняют _enter_tree и возобновляют вызов _process... коллбэков. Это нужно знать и активно использовать в этом, не побоюсь этого слова, паттерне.
Загрузку ресурсов следует делать в несколько этапов и в несколько потоков.
Следует завести себе не менее двух уровней детализации в зависимости от дальности от игрока. Назовём их ближний, средний и дальний.
Приближение игрока: На дальнем уровне активных чанков нет, на среднем уровне чанков всё ещё нет, но они уже начали фоновую загрузку ресурсов, на ближнем уровне чанки с загруженными ресурсами вводятся в дерево сцены репарентом из бэкап-ноды в игру.
Отдаление игрока: На ближнем уровне чанки работают в сцене, но уже помечены в очередь на вывод, на среднем чанки выведены из сцены, но сохраняют загруженные в себя ресурсы, на случай, если игрок пойдёт обратно, на дальнем чанки выгружают из себя ресурсы и помечаются, как свободные.
Свободные чанки не имеют ни типа, ни координат в игре, они получают тип и координаты, когда получают данные о ресурсах, которые им следует загрузить. Таким образом я в самом начале выразил это как карусель: Чанки как бы вращаются всё время вокруг игрока, выгружая из себя объекты позади и загружая объекты впереди.
И ещё раз повторю, загрузка ресурсов должна идти в несколько потоков. Без этого даже не пытайся зделоть опенворлд с корованами. Должна быть возможность не только быстро и одновременно, не нагружая основной поток, загружать ресурсы, но и возможность отменять начатую загрузку на любом этапе. Потому что игрок ходит рандомно. Только что он шёл на север и там прогружались замки, горы, тролли, и вдруг он резко развернулся назад и пошёл на юг, и надо срочно бросать загрузку и грузить лес, эльфов, домики деревянные.
> Как ты себе это представляешь в случае годота?
Два треда назад подробно рассмотрели.
В качестве пулов объектов прекрасно подходит механизм чайлдов в нодах. Заводишь ноду, которая не вводится в дерево сцены (далее: Бэкап-нода). К этой ноде в потомки добавляешь нужные ноды (далее: Чанки). При добавлении идёт нагрузка на комп, так что делаешь это один раз при создании абстракции игрового мира / игрового поля (далее: Игра). Далее, при необходимости ввести чанк в игру, меняешь ему парента с бэкап-ноды на игру. При необходимости вывести - меняешь парента с игры на бэкап-ноду.
Все выведенные из дерева сцены ноды вызывают колбэк _exit_tree и перестают обрабатывать _process... колбэки. Соответственно, все введённые репарентом в дерево сцены - снова выполняют _enter_tree и возобновляют вызов _process... коллбэков. Это нужно знать и активно использовать в этом, не побоюсь этого слова, паттерне.
Загрузку ресурсов следует делать в несколько этапов и в несколько потоков.
Следует завести себе не менее двух уровней детализации в зависимости от дальности от игрока. Назовём их ближний, средний и дальний.
Приближение игрока: На дальнем уровне активных чанков нет, на среднем уровне чанков всё ещё нет, но они уже начали фоновую загрузку ресурсов, на ближнем уровне чанки с загруженными ресурсами вводятся в дерево сцены репарентом из бэкап-ноды в игру.
Отдаление игрока: На ближнем уровне чанки работают в сцене, но уже помечены в очередь на вывод, на среднем чанки выведены из сцены, но сохраняют загруженные в себя ресурсы, на случай, если игрок пойдёт обратно, на дальнем чанки выгружают из себя ресурсы и помечаются, как свободные.
Свободные чанки не имеют ни типа, ни координат в игре, они получают тип и координаты, когда получают данные о ресурсах, которые им следует загрузить. Таким образом я в самом начале выразил это как карусель: Чанки как бы вращаются всё время вокруг игрока, выгружая из себя объекты позади и загружая объекты впереди.
И ещё раз повторю, загрузка ресурсов должна идти в несколько потоков. Без этого даже не пытайся зделоть опенворлд с корованами. Должна быть возможность не только быстро и одновременно, не нагружая основной поток, загружать ресурсы, но и возможность отменять начатую загрузку на любом этапе. Потому что игрок ходит рандомно. Только что он шёл на север и там прогружались замки, горы, тролли, и вдруг он резко развернулся назад и пошёл на юг, и надо срочно бросать загрузку и грузить лес, эльфов, домики деревянные.
>>706739
Я не очень понимаю, или ты не очень понимаешь, что такое "фоновая загрузка ресурсов" и как ты собираешься ее делать без "выделения памяти в куче".
Я не очень понимаю, или ты не очень понимаешь, что такое "фоновая загрузка ресурсов" и как ты собираешься ее делать без "выделения памяти в куче".
>>706747
https://ru.wikipedia.org/wiki/Куча_(структура_данных)
... к данным, в оперативной памяти, при работе с инстансами классов, которые в этой памяти (и этой куче) лежат.
Штош, по вопросу ресурсов.
Для центрального процессора ресурсами являются эти самые данные в куче.
Для видеокарты же ресурсами являются данные о геометрии и шейдерах.
Для звуковой карты - данные о звуке.
Так что да, ты не понимаешь. Ты уцепился за один аспект значения "ресурсов".
https://ru.wikipedia.org/wiki/Куча_(структура_данных)
>Реализации
>Стандартная библиотека шаблонов языка C++ предоставляет шаблоны функций для управления кучей make_heap, push_heap и pop_heap (обычно реализуются бинарные кучи), которые оперируют с итераторами произвольного доступа
... к данным, в оперативной памяти, при работе с инстансами классов, которые в этой памяти (и этой куче) лежат.
Штош, по вопросу ресурсов.
Для центрального процессора ресурсами являются эти самые данные в куче.
Для видеокарты же ресурсами являются данные о геометрии и шейдерах.
Для звуковой карты - данные о звуке.
Так что да, ты не понимаешь. Ты уцепился за один аспект значения "ресурсов".
>>706763
Это все замечательно, но ты попробуй как то внятно объяснить, что именно ты собираешься пулить, если все загружаешь в фоне и все равно выделяешь память пачками.
Это все замечательно, но ты попробуй как то внятно объяснить, что именно ты собираешься пулить, если все загружаешь в фоне и все равно выделяешь память пачками.
Бросил godot из-за старого opengl, так ещё и вулкана нет поддержки лул.
>>706935
Что ты имеешь в виду?
var child = obj1.get_child(i)
obj1.remove_child(child)
some_other.add_child(child)
Возможно понадобится писать через call_deferred
Что ты имеешь в виду?
var child = obj1.get_child(i)
obj1.remove_child(child)
some_other.add_child(child)
Возможно понадобится писать через call_deferred
>>706935
Сформулируй задачу. А то вытаскивание объекта из родителя попахивает операцией на голове через жопу.
Сформулируй задачу. А то вытаскивание объекта из родителя попахивает операцией на голове через жопу.
>>706959
Вообще говоря в годоте это штатная операция. Пример: у тебя игра типа кваки, сцена - уровень у которому прикреплен игрок и вращающаяся пушка. Когда игрок подходит и поднимает пушку, можно ее открепить от сцены и пприкрепить к руке игрока через boneattachment. Надо только учесть нюансы, типа упомянутого вызова add/remove через call deferred, и сработающих эффектов типа area enter/exit
Вообще говоря в годоте это штатная операция. Пример: у тебя игра типа кваки, сцена - уровень у которому прикреплен игрок и вращающаяся пушка. Когда игрок подходит и поднимает пушку, можно ее открепить от сцены и пприкрепить к руке игрока через boneattachment. Надо только учесть нюансы, типа упомянутого вызова add/remove через call deferred, и сработающих эффектов типа area enter/exit
>>706999
Вообще, всё ещё проще, начиная с 3.2.1, ЕМНИП, ввели ноду, которая синхронизирует координаты. Вот тебе и готовый аттач чего угодно к чему угодно, без возни с репарентом.
Вообще, всё ещё проще, начиная с 3.2.1, ЕМНИП, ввели ноду, которая синхронизирует координаты. Вот тебе и готовый аттач чего угодно к чему угодно, без возни с репарентом.
>>707061
В смысле сомнительное? Это индустриальный стандарт, который есть во всех движках и наконец хуан завёз его фкаропку.
В смысле сомнительное? Это индустриальный стандарт, который есть во всех движках и наконец хуан завёз его фкаропку.
>>707101
Конечно же пошутил. Все нормально.
Конечно же пошутил. Все нормально.
Почему не работаем импорт звука?
Беру Wav, импортирую и ничего не происходит, даже в сцену не могу его добавит.
Беру Wav, импортирую и ничего не происходит, даже в сцену не могу его добавит.
>>707241
Что по-твоему должно произойти? Файл должен отобразиться в инспекторе, все.
Аудиофайлы это ресурс, который используют AudioStreamPlayer, их нельзя самостоятельно добавить в сцену.
>импортирую и ничего не происходит
Что по-твоему должно произойти? Файл должен отобразиться в инспекторе, все.
>даже в сцену не могу его добавит.
Аудиофайлы это ресурс, который используют AudioStreamPlayer, их нельзя самостоятельно добавить в сцену.
>>707241
Потому что ты трогал себя под одеялом вывалился из срачезагона, ща живительный репорт вернёт тебя в любимую среду не читаешь документацию.
https://docs.godotengine.org/ru/stable/tutorials/audio/audio_streams.html
> Почему не работае
Потому что ты трогал себя под одеялом вывалился из срачезагона, ща живительный репорт вернёт тебя в любимую среду не читаешь документацию.
https://docs.godotengine.org/ru/stable/tutorials/audio/audio_streams.html
>>707245
Не поверишь, но с документации я и начал. Вот только там наглядно не показывается, что перед началом работы нужно сначала добавить AudioStreamPlayer на сцену, потом загрузить трек, переимпортировать его и написать скрипт, чтобы всё заработало.
Не поверишь, но с документации я и начал. Вот только там наглядно не показывается, что перед началом работы нужно сначала добавить AudioStreamPlayer на сцену, потом загрузить трек, переимпортировать его и написать скрипт, чтобы всё заработало.
>>707249
Вообще-то, поверю.
Я на неделе изучал некоторые UI-фреймворки для шарпа (более для ентерпрайза, чем для геймдева) и наткнулся на множество вещей, которые не понимаю, даже интуитивно не вдупляю. Тыкаюсь, как слепой котёнок, а фронтендеры в шарпотреде посмеиваются над моими жалобами. И в гугле не могу найти ответы. И в документации написано лунным языком, который влетает мне в один глаз, а вылетает через второе ухо.
Такшта, вот.
Вообще-то, поверю.
Я на неделе изучал некоторые UI-фреймворки для шарпа (более для ентерпрайза, чем для геймдева) и наткнулся на множество вещей, которые не понимаю, даже интуитивно не вдупляю. Тыкаюсь, как слепой котёнок, а фронтендеры в шарпотреде посмеиваются над моими жалобами. И в гугле не могу найти ответы. И в документации написано лунным языком, который влетает мне в один глаз, а вылетает через второе ухо.
Такшта, вот.
>>707249
Да, там нет картинки, но текстом это написано.
А вообще есть же набор оф. примеров.
Они доступны через ассеты либо гитхаб.
https://godotengine.org/asset-library/asset/525
Открываешь и смотришь как там сделано
( остальные
https://godotengine.org/asset-library/asset?user=Godot Engine
https://github.com/godotengine/godot-demo-projects/ )
Не буду говорить что они там идеально как то сделаны, но чтобы понять что происходит то можно и ознакомиться.
Да, там нет картинки, но текстом это написано.
А вообще есть же набор оф. примеров.
Они доступны через ассеты либо гитхаб.
https://godotengine.org/asset-library/asset/525
Открываешь и смотришь как там сделано
( остальные
https://godotengine.org/asset-library/asset?user=Godot Engine
https://github.com/godotengine/godot-demo-projects/ )
Не буду говорить что они там идеально как то сделаны, но чтобы понять что происходит то можно и ознакомиться.
>>707264
Пожалуй, придётся вернуть в шапку изначальные предложения
1. Читать документацию.
2. КАЧАТЬ ПРИМЕРЫ
Пожалуй, придётся вернуть в шапку изначальные предложения
1. Читать документацию.
2. КАЧАТЬ ПРИМЕРЫ
>>707249
Я не верю. Вот смотри чего нашёл: https://docs.godotengine.org/en/stable/tutorials/audio/audio_streams.html
Вообще, советую по непоятным темам заглядывать не только в CLASS REFERENCE, но и в TUTORIALS. Поначалу не очень очевидно, что они там есть и что их сколько-нибудь достаточно, однако, если внимательно пролистать всю левую колонку (которая с оглавлением), то обнаружишь много нового. Я так годоту учился в своё время.
Чо как, пацаны? Полгода не заглядывал. Кто-нибудь релизнул свою игру мечты?
>Не поверишь
Я не верю. Вот смотри чего нашёл: https://docs.godotengine.org/en/stable/tutorials/audio/audio_streams.html
Вообще, советую по непоятным темам заглядывать не только в CLASS REFERENCE, но и в TUTORIALS. Поначалу не очень очевидно, что они там есть и что их сколько-нибудь достаточно, однако, если внимательно пролистать всю левую колонку (которая с оглавлением), то обнаружишь много нового. Я так годоту учился в своё время.
Чо как, пацаны? Полгода не заглядывал. Кто-нибудь релизнул свою игру мечты?
>>707274
Всё плохо.
Мотивации нет.
Желания нет.
Фуфлыжно сидим.
Как сам?
> Чо как, пацаны? Полгода не заглядывал. Кто-нибудь релизнул свою игру мечты?
Всё плохо.
Мотивации нет.
Желания нет.
Фуфлыжно сидим.
Как сам?
>>707274
Игру мечты пока нет, там много работы еще.
А мелкоигр чуть чуть не успел три в прошлом месяце закончить.
Игру мечты пока нет, там много работы еще.
А мелкоигр чуть чуть не успел три в прошлом месяце закончить.
Парни у кого есть ссылка на исходник шутера из официально тутора на гитхабе?
https://docs.godotengine.org/
https://docs.godotengine.org/
>>707330
The finished project source is hosted on GitHub as well: https://github.com/TwistedTwigleg/Godot_FPS_Tutorial
The finished project source is hosted on GitHub as well: https://github.com/TwistedTwigleg/Godot_FPS_Tutorial
>>707334
Вы и вправду лучший раздел треда. Спасибо.
Вы и вправду лучший раздел треда. Спасибо.
131 Кб, 2086x1221Выбрал сцену для запуска, напчал писать скрипт для плеера и выскочило это.
Что не так со скриптом?
Что не так со скриптом?
>>707343
Какого ещё плеера? Почему плеер требует дотнетстандарт? Годот-шарп только на моно. Никаких дотнестандартов и дотнеткоров. Увы.
Какого ещё плеера? Почему плеер требует дотнетстандарт? Годот-шарп только на моно. Никаких дотнестандартов и дотнеткоров. Увы.
243 Кб, 1186x1027>>707343
А это мне в студии пишет.
ОшибкаCS0012Тип "Object" определен в сборке, на которую нет ссылки. Следует добавить ссылку на сборку "netstandard, Version=2.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51".
как можно добавить ссылку на netstandard?
А это мне в студии пишет.
ОшибкаCS0012Тип "Object" определен в сборке, на которую нет ссылки. Следует добавить ссылку на сборку "netstandard, Version=2.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51".
как можно добавить ссылку на netstandard?
>>707346
Выше читай. Никаких дотнетстандартов. Только моно.
Выше читай. Никаких дотнетстандартов. Только моно.
11 Кб, 322x179>>707348
Вот так должен выглядеть сгенерированный редактором файл проекта. Там свой собственный СДК, прямо зависящий от моно.
Я в прошлом году тоже пытался напихать в проект пакетов нюгета через студию. В принципе, большинство пакетов работают. А ты что пытался затянуть в проект?
Вот так должен выглядеть сгенерированный редактором файл проекта. Там свой собственный СДК, прямо зависящий от моно.
Я в прошлом году тоже пытался напихать в проект пакетов нюгета через студию. В принципе, большинство пакетов работают. А ты что пытался затянуть в проект?
Слушайте, а что за "пропуки" о которых тут весь тред ниже уши прожужжал и как правильно их лечить?
Я так понял нужно налепить типа галереи материалов на прямоугольниках под полом карты, что бы никто не видел, да?
Я так понял нужно налепить типа галереи материалов на прямоугольниках под полом карты, что бы никто не видел, да?
>>707358
Da.
В целом, "пропуками" в нашем соседнем срачетреде обезумевших пуконюхов, называются проседания ФПС. Проседания ФПС случаются по разным причинам.
Управление загрузкой шейдеров в видеокарту отдано в твои руки, как полновластному разработчику твоей игры. По дефолту шейдеры грузятся лениво, в момент первого вхождения в пространство обзора камеры. Ты можешь загрузить их "трудолюбиво" при начальной загрузке сцены.
Так же ФПС может просесть при любой ленивой инициализации тех или иных сущностей объектной системы. Бороться с ними следует разными методами. Описанными не только в документации годота, но так же и в классической технической литературе. Потому что проблема времени на выполнение тех или иных алгоритмов - проблема фундаментальная. И оптимальные алгоритмы, эффективные решения, они являются ценностью, которую никто не раздаёт бесплатно. Либо реализуй самостоятельно - либо покупай библиотеку, пиши класс-адаптер к ней, используя покупное же API.
Но, повторюсь. Движок опенсорсный и модульный и даёт тебе полную власть над реализацией алгоритмов. Свою игру ты сможешь оптимизировать до бесконечности, вклиниваясь в исходники, заменяя модули на собственные. Ничто из этого не запрещено лицензией. Такие дела. Это сложно. За ручку тебя никто не поведёт.
Однако, на этапе полировки игры никто не мешает нанять грамотного кодера для оптимизации. Была бы игра. Есть у тебя игра-то? А если найду?
> нужно налепить типа галереи материалов на прямоугольниках под полом карты, что бы никто не видел, да?
Da.
> а что за "пропуки" о которых тут весь тред ниже уши прожужжал
В целом, "пропуками" в нашем соседнем срачетреде обезумевших пуконюхов, называются проседания ФПС. Проседания ФПС случаются по разным причинам.
Управление загрузкой шейдеров в видеокарту отдано в твои руки, как полновластному разработчику твоей игры. По дефолту шейдеры грузятся лениво, в момент первого вхождения в пространство обзора камеры. Ты можешь загрузить их "трудолюбиво" при начальной загрузке сцены.
Так же ФПС может просесть при любой ленивой инициализации тех или иных сущностей объектной системы. Бороться с ними следует разными методами. Описанными не только в документации годота, но так же и в классической технической литературе. Потому что проблема времени на выполнение тех или иных алгоритмов - проблема фундаментальная. И оптимальные алгоритмы, эффективные решения, они являются ценностью, которую никто не раздаёт бесплатно. Либо реализуй самостоятельно - либо покупай библиотеку, пиши класс-адаптер к ней, используя покупное же API.
Но, повторюсь. Движок опенсорсный и модульный и даёт тебе полную власть над реализацией алгоритмов. Свою игру ты сможешь оптимизировать до бесконечности, вклиниваясь в исходники, заменяя модули на собственные. Ничто из этого не запрещено лицензией. Такие дела. Это сложно. За ручку тебя никто не поведёт.
Однако, на этапе полировки игры никто не мешает нанять грамотного кодера для оптимизации. Была бы игра. Есть у тебя игра-то? А если найду?
>>707349
Выбирал те, что были вязаны с годотом. Но они не очень подходили.
Лучше в моно и не выпендриваться.
Выбирал те, что были вязаны с годотом. Но они не очень подходили.
Лучше в моно и не выпендриваться.
сук я уже десяток раз экспортировал, чому иконка годота не меняется на ту которую поставил в настройках проэкта и настройках эскпорта
>>707729
Ты по инструкции делал? С rcedit?
На самом деле виндовый проводник кеширует. Попробуй скопировать экзешник с новым именем. Если там будет новая иконка то все ок.
Ты по инструкции делал? С rcedit?
На самом деле виндовый проводник кеширует. Попробуй скопировать экзешник с новым именем. Если там будет новая иконка то все ок.
295 Кб, 760x498>>707742
>>707729
ИМХО, гораздо проще и удобнее поменять иконку своим любимым сторонним инструментом. Я, например, юзаю RecourceHacker. Можно вообще прошить иконку шаблону экспорта и не париться.
Но в таких прогах как редакторы ресурсов нужно матчасть знать. Иконгруп - не то же самое, что икон.
> С rcedit?
>>707729
> иконка годота не меняется
ИМХО, гораздо проще и удобнее поменять иконку своим любимым сторонним инструментом. Я, например, юзаю RecourceHacker. Можно вообще прошить иконку шаблону экспорта и не париться.
Но в таких прогах как редакторы ресурсов нужно матчасть знать. Иконгруп - не то же самое, что икон.
>>707758
Ну это вручную. А там консольная утилита. Годот просто ее вызывает при экспорте.
Ну это вручную. А там консольная утилита. Годот просто ее вызывает при экспорте.
>>707813
Как что-то плохое.
Некоторые ответственные вещи не стоит доверять автоматике.
> Ну это вручную.
Как что-то плохое.
Некоторые ответственные вещи не стоит доверять автоматике.
>>707823
Конечно плохое. Такие вещи настраиваются один раз и просто работают. Представь себе что тебе надо сдавать игру на конкурс, у тебя последние баг фиксы новые версии каждые 15 минут, экспортишь, отправляешь и... понимаешь что забыл сделать ручную операцию в последний момент.
Конечно плохое. Такие вещи настраиваются один раз и просто работают. Представь себе что тебе надо сдавать игру на конкурс, у тебя последние баг фиксы новые версии каждые 15 минут, экспортишь, отправляешь и... понимаешь что забыл сделать ручную операцию в последний момент.
63 Кб, 779x561>>707828
Я только что проверил - и действительно. Замена иконки в файле шаблона windows_XX_YY.exe, где X - 32 или 64, а Y - debug или release, работает прекрасно, проект экспортируется с кастомной иконкой и даже со встроенным PCK все запускается нормально.
Разумеется, это не подойдёт разрабам, которые активно выпускают патчи сразу для нескольких игор. Но я лично как правило только с одной игрой работаю, мне норм.
Хотя, чего это я туплю? Свой кастом темплейт скопировать в отдельную папочку для каждой игры и юзать его для экспорта. Тем более, если игра серьёзнее туториалов и тестов, у неё будет как минимум один сторонний модуль вкомпилен и в редактор и в темплейт, что потребует юзать именно кастом.
Я только что проверил - и действительно. Замена иконки в файле шаблона windows_XX_YY.exe, где X - 32 или 64, а Y - debug или release, работает прекрасно, проект экспортируется с кастомной иконкой и даже со встроенным PCK все запускается нормально.
Разумеется, это не подойдёт разрабам, которые активно выпускают патчи сразу для нескольких игор. Но я лично как правило только с одной игрой работаю, мне норм.
Хотя, чего это я туплю? Свой кастом темплейт скопировать в отдельную папочку для каждой игры и юзать его для экспорта. Тем более, если игра серьёзнее туториалов и тестов, у неё будет как минимум один сторонний модуль вкомпилен и в редактор и в темплейт, что потребует юзать именно кастом.
>>707890
Не перепутаешь. Кастомный темплейт задаётся один раз в настройках проекта и дальше работаешь с ним. Автоматически, как анон выше и желал.
> и не перепутать
Не перепутаешь. Кастомный темплейт задаётся один раз в настройках проекта и дальше работаешь с ним. Автоматически, как анон выше и желал.
>>707900T
Ебать это просто пиздец, танцы с бубном, чтобы заставить работать С# скрипты, нахуй такая реализация если она толком не работает?
Ебать это просто пиздец, танцы с бубном, чтобы заставить работать С# скрипты, нахуй такая реализация если она толком не работает?
Проснулись-потянулись! Доброе утро, анончики дорогие мои! Ну-ка пописоли-покушоли и за пеку - игоры делать. Туц-туц лапками по клавиатуре!
>>708177
Скачать селфконтейнед приложуху (корректно подписанную к тому же) тоже не сильно сложно. Уже 2к2д и даже учителя информатики в школах умеют скачивать софт.
> прямой заход в различные школы
Скачать селфконтейнед приложуху (корректно подписанную к тому же) тоже не сильно сложно. Уже 2к2д и даже учителя информатики в школах умеют скачивать софт.
Короче, собираю команду для создания опенворлда на годоте. Там в соседнем треде неосиляторы пишут что не получится. Если же мы выкатим рабочий прототип, они уже охуеют, а если мы доведём прототип до релиза - будет эпик вин.
>>708552
Я особо гнать не буду - дел много.
Могу пока просто делиться ресерчем.
Из готового террейна у нас есть только heightmap террейн.
А по хорошему нужен бы vertex displacement (VDM)
Без него не получится делать террейном нависающие уступы. Только объектами, а это мне кажется уже не совсем рационально. Также придется как то дополнительно обрабатывать пещеры и вообще все двух+ ярусное. Как минимум с точки зрения коллайдеров и навигации. Т.е. пол пещеры будет еще террейном - а потолок уже отдельным объектом.
Также я не знаю, как в случае с дисплейсментом вершин будут работать встроенные тени.
(В процессе написания родилась идея на пробу - сделать для скал дополнительные полоски террейна, повернутые на ребро на 90 градусов... Надо потестить на производительность)
Второе наблюдение касается текстур. Из коробки террейн поддерживает смешивание 4 текстур, из которых на последнюю можно включить трипланар, то есть только она может играть роль скал - остальные будут растянуты. Впрочем, в шейдере написано что это можно изменить, ценой производительности. Также есть экспериментальная ветка где можно блендить до 16 текстур (но только до 4-х в каждой конкретной точке - что-то типа тайлсета выходит). Но там, вроде бы, трипланар вообще не сделан сейчас.
https://www.youtube.com/watch?v=sbADtAkh92w
Стриминг еще не продумывал. Попробую сначала просто несколько чанков террейнов и лоу-поли версию меша для дальних пейзажей. Также подумываю о том чтобы коллайдеры шли отдельно, и может быть тоже нарезаны на небольшие чанки. По идее мобы рисуются только в каком то радиусе от игрока, в ближнем радиусе будет детальный коллайдер, а подальше, там где враги просто несагрившиеся стоят - возможно просто плоскости для экономии.
Я особо гнать не буду - дел много.
Могу пока просто делиться ресерчем.
Из готового террейна у нас есть только heightmap террейн.
А по хорошему нужен бы vertex displacement (VDM)
Без него не получится делать террейном нависающие уступы. Только объектами, а это мне кажется уже не совсем рационально. Также придется как то дополнительно обрабатывать пещеры и вообще все двух+ ярусное. Как минимум с точки зрения коллайдеров и навигации. Т.е. пол пещеры будет еще террейном - а потолок уже отдельным объектом.
Также я не знаю, как в случае с дисплейсментом вершин будут работать встроенные тени.
(В процессе написания родилась идея на пробу - сделать для скал дополнительные полоски террейна, повернутые на ребро на 90 градусов... Надо потестить на производительность)
Второе наблюдение касается текстур. Из коробки террейн поддерживает смешивание 4 текстур, из которых на последнюю можно включить трипланар, то есть только она может играть роль скал - остальные будут растянуты. Впрочем, в шейдере написано что это можно изменить, ценой производительности. Также есть экспериментальная ветка где можно блендить до 16 текстур (но только до 4-х в каждой конкретной точке - что-то типа тайлсета выходит). Но там, вроде бы, трипланар вообще не сделан сейчас.
https://www.youtube.com/watch?v=sbADtAkh92w
Стриминг еще не продумывал. Попробую сначала просто несколько чанков террейнов и лоу-поли версию меша для дальних пейзажей. Также подумываю о том чтобы коллайдеры шли отдельно, и может быть тоже нарезаны на небольшие чанки. По идее мобы рисуются только в каком то радиусе от игрока, в ближнем радиусе будет детальный коллайдер, а подальше, там где враги просто несагрившиеся стоят - возможно просто плоскости для экономии.
>>708655
Ща пойду загуглю ВДМ, но, по идее плагин Зилана так и работает, дисплейсом вершин. По крайней мере я такой вывод сделал, разглядывая шейдеры в его комплекте.
А вот зацени мою идею.
Чтобы сделать сложный террейн с поддержкой нависающих скал, пещер и даже терраформирования, но (ПРЕДПОЛОЖИТЕЛЬНО) производительнее, чем воксели, нужно помимо карты высот использовать инверсную карту высот снизу, две карты ширин, справа и слева, и карту длин, спереди и сзади. То же самое триде. Все шесть карт совмещаются генератором и на их основе строится один или несколько мешей, подобно тому, как в черчении из трёх видов строится проекция объёмной модели, а у нас натурально вся модель строится из окружающих кубемапом видов. Но только получается, что для пещер всё равно придётся завозить в генератор дополнительные карты. Ведь кубемап даст нам только наружною поверхность - как только глубина впадины в поверхности увеличится настолько, что её не будет видно ни сверху, ни с боков, она перестанет вычисляться. Очевидным решением в таком случае будет от генератора запросить локальный кубемап для отрисовки этой зоны, в которм и будет закодирована полость внутри террейна (пещера).
Сложность алгоритма на первый взгляд не должна быть очень большой. Но я не спец в вычислении сложностей алгоритмов. Основной сложностью в этой идее я вижу само получение набора кубемапов. Как вариант, можно написать плагин для блендера. В блендере строится/генерируется террейн со всеми пещерами, уступами, скалами. Прямо хайполи со всеми скульптингами. Потом запускается плагин, который с этого набора мешей снимает кубемап-карты. Сначала внешнюю, глобальную, потом локальные для всех вершин, которые не видны на глобальной, затем рекурсивно со всех вершин, которые не видны на локальных картах. Каждому сгенерированному кубемапу присваивается идентификатор, или координаты, ну не знаю.
Генератор действует наоборот и уже с ЛОДами, для всей карты генерируется крупноячеистый меш, затем, при приближении к координатам нашего игрока меш уточняется так, что рассматривая поверхность вблизи игрок видит хайполи, а глядя вдаль полигональность пропорционально углу обзора падает.
Только вот тот же Зилан уже написал си++ модуль с поддержкой воксельных террейнов и эта идея в принципе нафиг не нужна. Я её реализовать сам вряд ли смогу. Проще скомпилировать редактор и шаблоны с модулем Зилана и наслаждаться готовой реализацией.
Ща пойду загуглю ВДМ, но, по идее плагин Зилана так и работает, дисплейсом вершин. По крайней мере я такой вывод сделал, разглядывая шейдеры в его комплекте.
А вот зацени мою идею.
Чтобы сделать сложный террейн с поддержкой нависающих скал, пещер и даже терраформирования, но (ПРЕДПОЛОЖИТЕЛЬНО) производительнее, чем воксели, нужно помимо карты высот использовать инверсную карту высот снизу, две карты ширин, справа и слева, и карту длин, спереди и сзади. То же самое триде. Все шесть карт совмещаются генератором и на их основе строится один или несколько мешей, подобно тому, как в черчении из трёх видов строится проекция объёмной модели, а у нас натурально вся модель строится из окружающих кубемапом видов. Но только получается, что для пещер всё равно придётся завозить в генератор дополнительные карты. Ведь кубемап даст нам только наружною поверхность - как только глубина впадины в поверхности увеличится настолько, что её не будет видно ни сверху, ни с боков, она перестанет вычисляться. Очевидным решением в таком случае будет от генератора запросить локальный кубемап для отрисовки этой зоны, в которм и будет закодирована полость внутри террейна (пещера).
Сложность алгоритма на первый взгляд не должна быть очень большой. Но я не спец в вычислении сложностей алгоритмов. Основной сложностью в этой идее я вижу само получение набора кубемапов. Как вариант, можно написать плагин для блендера. В блендере строится/генерируется террейн со всеми пещерами, уступами, скалами. Прямо хайполи со всеми скульптингами. Потом запускается плагин, который с этого набора мешей снимает кубемап-карты. Сначала внешнюю, глобальную, потом локальные для всех вершин, которые не видны на глобальной, затем рекурсивно со всех вершин, которые не видны на локальных картах. Каждому сгенерированному кубемапу присваивается идентификатор, или координаты, ну не знаю.
Генератор действует наоборот и уже с ЛОДами, для всей карты генерируется крупноячеистый меш, затем, при приближении к координатам нашего игрока меш уточняется так, что рассматривая поверхность вблизи игрок видит хайполи, а глядя вдаль полигональность пропорционально углу обзора падает.
Только вот тот же Зилан уже написал си++ модуль с поддержкой воксельных террейнов и эта идея в принципе нафиг не нужна. Я её реализовать сам вряд ли смогу. Проще скомпилировать редактор и шаблоны с модулем Зилана и наслаждаться готовой реализацией.
>>708655
Ща пойду загуглю ВДМ, но, по идее плагин Зилана так и работает, дисплейсом вершин. По крайней мере я такой вывод сделал, разглядывая шейдеры в его комплекте.
А вот зацени мою идею.
Чтобы сделать сложный террейн с поддержкой нависающих скал, пещер и даже терраформирования, но (ПРЕДПОЛОЖИТЕЛЬНО) производительнее, чем воксели, нужно помимо карты высот использовать инверсную карту высот снизу, две карты ширин, справа и слева, и карту длин, спереди и сзади. То же самое триде. Все шесть карт совмещаются генератором и на их основе строится один или несколько мешей, подобно тому, как в черчении из трёх видов строится проекция объёмной модели, а у нас натурально вся модель строится из окружающих кубемапом видов. Но только получается, что для пещер всё равно придётся завозить в генератор дополнительные карты. Ведь кубемап даст нам только наружною поверхность - как только глубина впадины в поверхности увеличится настолько, что её не будет видно ни сверху, ни с боков, она перестанет вычисляться. Очевидным решением в таком случае будет от генератора запросить локальный кубемап для отрисовки этой зоны, в которм и будет закодирована полость внутри террейна (пещера).
Сложность алгоритма на первый взгляд не должна быть очень большой. Но я не спец в вычислении сложностей алгоритмов. Основной сложностью в этой идее я вижу само получение набора кубемапов. Как вариант, можно написать плагин для блендера. В блендере строится/генерируется террейн со всеми пещерами, уступами, скалами. Прямо хайполи со всеми скульптингами. Потом запускается плагин, который с этого набора мешей снимает кубемап-карты. Сначала внешнюю, глобальную, потом локальные для всех вершин, которые не видны на глобальной, затем рекурсивно со всех вершин, которые не видны на локальных картах. Каждому сгенерированному кубемапу присваивается идентификатор, или координаты, ну не знаю.
Генератор действует наоборот и уже с ЛОДами, для всей карты генерируется крупноячеистый меш, затем, при приближении к координатам нашего игрока меш уточняется так, что рассматривая поверхность вблизи игрок видит хайполи, а глядя вдаль полигональность пропорционально углу обзора падает.
Только вот тот же Зилан уже написал си++ модуль с поддержкой воксельных террейнов и эта идея в принципе нафиг не нужна. Я её реализовать сам вряд ли смогу. Проще скомпилировать редактор и шаблоны с модулем Зилана и наслаждаться готовой реализацией.
Ща пойду загуглю ВДМ, но, по идее плагин Зилана так и работает, дисплейсом вершин. По крайней мере я такой вывод сделал, разглядывая шейдеры в его комплекте.
А вот зацени мою идею.
Чтобы сделать сложный террейн с поддержкой нависающих скал, пещер и даже терраформирования, но (ПРЕДПОЛОЖИТЕЛЬНО) производительнее, чем воксели, нужно помимо карты высот использовать инверсную карту высот снизу, две карты ширин, справа и слева, и карту длин, спереди и сзади. То же самое триде. Все шесть карт совмещаются генератором и на их основе строится один или несколько мешей, подобно тому, как в черчении из трёх видов строится проекция объёмной модели, а у нас натурально вся модель строится из окружающих кубемапом видов. Но только получается, что для пещер всё равно придётся завозить в генератор дополнительные карты. Ведь кубемап даст нам только наружною поверхность - как только глубина впадины в поверхности увеличится настолько, что её не будет видно ни сверху, ни с боков, она перестанет вычисляться. Очевидным решением в таком случае будет от генератора запросить локальный кубемап для отрисовки этой зоны, в которм и будет закодирована полость внутри террейна (пещера).
Сложность алгоритма на первый взгляд не должна быть очень большой. Но я не спец в вычислении сложностей алгоритмов. Основной сложностью в этой идее я вижу само получение набора кубемапов. Как вариант, можно написать плагин для блендера. В блендере строится/генерируется террейн со всеми пещерами, уступами, скалами. Прямо хайполи со всеми скульптингами. Потом запускается плагин, который с этого набора мешей снимает кубемап-карты. Сначала внешнюю, глобальную, потом локальные для всех вершин, которые не видны на глобальной, затем рекурсивно со всех вершин, которые не видны на локальных картах. Каждому сгенерированному кубемапу присваивается идентификатор, или координаты, ну не знаю.
Генератор действует наоборот и уже с ЛОДами, для всей карты генерируется крупноячеистый меш, затем, при приближении к координатам нашего игрока меш уточняется так, что рассматривая поверхность вблизи игрок видит хайполи, а глядя вдаль полигональность пропорционально углу обзора падает.
Только вот тот же Зилан уже написал си++ модуль с поддержкой воксельных террейнов и эта идея в принципе нафиг не нужна. Я её реализовать сам вряд ли смогу. Проще скомпилировать редактор и шаблоны с модулем Зилана и наслаждаться готовой реализацией.
>>708655
Главное, при продумывании стриминга чтобы не произошло путаницы между ресурсами процессора (объектами в куче, которая в оперативной памяти) и ресурсами диска (которые есть файлы на диске), как это случилось ИТТ десятком постов выше.
> Стриминг еще не продумывал.
Главное, при продумывании стриминга чтобы не произошло путаницы между ресурсами процессора (объектами в куче, которая в оперативной памяти) и ресурсами диска (которые есть файлы на диске), как это случилось ИТТ десятком постов выше.
>>708711
Heightmap дисплейсит только по вертикали, вот в чем дело. Как в предыдущем посте на 2-м пике. Как на 1-м и 3-м пике - не может.
То, что у него есть воксельный, я забыл, но мне они не очень нравятся
Heightmap дисплейсит только по вертикали, вот в чем дело. Как в предыдущем посте на 2-м пике. Как на 1-м и 3-м пике - не может.
То, что у него есть воксельный, я забыл, но мне они не очень нравятся
Хотя, из этого можно наверное что то выжать. Но формы все же какие то несественные. Наверное, проблема в том, что они всегда осе-ориентированы.
>>708714
Эх, если бы разбираться во всём этом, можно крутые вещи творить! Вот нашёл простенький примерчик:
https://www.youtube.com/watch?v=4zhTtOuLpjA
>>708715
Ну да, поверх первоначальной генерации нужно накладывать фильтры, имитирующие природные эффекты: выветривание, вымывание, выплавление и т.п. И сдаётся мне, плоскими картами это будет накладываться гораздо производительнее, чем вокселями. Но опять же, я не уверен. Да и вообще, может под вокселями Зилан как раз и подразумевает примерно то, что я описал выше. Ведь каждый пиксель, описанный шестью хайтмапами кубемапа из примера выше, это по факту и есть - волюметрик пиксель - воксель.
> vertex displacement
Эх, если бы разбираться во всём этом, можно крутые вещи творить! Вот нашёл простенький примерчик:
https://www.youtube.com/watch?v=4zhTtOuLpjA
>>708715
Ну да, поверх первоначальной генерации нужно накладывать фильтры, имитирующие природные эффекты: выветривание, вымывание, выплавление и т.п. И сдаётся мне, плоскими картами это будет накладываться гораздо производительнее, чем вокселями. Но опять же, я не уверен. Да и вообще, может под вокселями Зилан как раз и подразумевает примерно то, что я описал выше. Ведь каждый пиксель, описанный шестью хайтмапами кубемапа из примера выше, это по факту и есть - волюметрик пиксель - воксель.
>>708180
А теперь даже устанавливать ничего не надо будет. "Дети, переходим по ссылке и ебашим игру своей мечты".
>Скачать селфконтейнед приложуху (корректно подписанную к тому же) тоже не сильно сложно. Уже 2к2д и даже учителя информатики в школах умеют скачивать софт.
А теперь даже устанавливать ничего не надо будет. "Дети, переходим по ссылке и ебашим игру своей мечты".
>>708782
На самом деле не факт что проще - может быть белый список доступных сайтов.
На самом деле не факт что проще - может быть белый список доступных сайтов.
Годаны, поясните за 2д-скелеты.
Хочу сделать по уму. Создаю Skeleton2D, к нему потомки Bone2D. Дальше ему устанавливаю позицию покоя. Дальше выбираю все кости, составляющие одну конечность (например, руку) и жму "создать цепь ИК". Двигаю конец руки, но предыдущая кость растягивается, а не идёт следом.
Делаю по простому. Создаю дерево из обычных 2д-нод. Потом из него создаю пользовательский скелет. У этого скелета выбираю кости одной конечности, создаю цепь ИК - вуаля, при движении последней кости предыдущая не растягивается, а тащит и поворачивает следом всю конечность, сохраняя длину каждой кости.
ЧЯДНТ? Это так и задумано? Или баг? Или я чего-то не знаю?
Хочу сделать по уму. Создаю Skeleton2D, к нему потомки Bone2D. Дальше ему устанавливаю позицию покоя. Дальше выбираю все кости, составляющие одну конечность (например, руку) и жму "создать цепь ИК". Двигаю конец руки, но предыдущая кость растягивается, а не идёт следом.
Делаю по простому. Создаю дерево из обычных 2д-нод. Потом из него создаю пользовательский скелет. У этого скелета выбираю кости одной конечности, создаю цепь ИК - вуаля, при движении последней кости предыдущая не растягивается, а тащит и поворачивает следом всю конечность, сохраняя длину каждой кости.
ЧЯДНТ? Это так и задумано? Или баг? Или я чего-то не знаю?
>>709070
Я с 2д не работаю, так что могу только вечером попозже глянуть
Вроде бы читал что с IK что то меняли в последнее время. Вполне возможно что там что то не работает.
Я с 2д не работаю, так что могу только вечером попозже глянуть
Вроде бы читал что с IK что то меняли в последнее время. Вполне возможно что там что то не работает.
>>709070
Может там как в блендере, важен порядок выбора нод?
> Дальше выбираю все кости, составляющие одну конечность (например, руку) и жму "создать цепь ИК".
Может там как в блендере, важен порядок выбора нод?
>>709193
Судя по тому что пишут, баг заключается в том, что кнопка Make IK chain не работает, а работает кнопка Make custom bones при выделенных костях.
Судя по тому что пишут, баг заключается в том, что кнопка Make IK chain не работает, а работает кнопка Make custom bones при выделенных костях.
>>709197
То есть, если я правильно понял, предлагается сделать кости из костей, чтобы получились кости?
То есть, если я правильно понял, предлагается сделать кости из костей, чтобы получились кости?
>>709198
Посмотри с 15-й минуты, я сам не понял, но вроде у него работает.
https://youtu.be/QL57J3anDTU?t=905
Может есть какой то сторонний модуль? Смущает отсутствие аттрактора для локтя
Посмотри с 15-й минуты, я сам не понял, но вроде у него работает.
https://youtu.be/QL57J3anDTU?t=905
Может есть какой то сторонний модуль? Смущает отсутствие аттрактора для локтя
>>709201
сцуко. Всё затевалось для того, чтобы НЕ делать custom bones. А тут выходит, что делать это надо в любом случае, потому что кости это на самом деле не настоящие кости, а настоящие кости это те, которые не кости.
Точнее, просто кости нужны не для того, чтобы строить из них скелет, а для того, чтобы привязывать к ним искажения меша. А для построения скелета подойдут любые ноды, просто в режиме отображения как будто это кость.
Я понял. Спасибо, анончик, ты мне действительно помог.
сцуко. Всё затевалось для того, чтобы НЕ делать custom bones. А тут выходит, что делать это надо в любом случае, потому что кости это на самом деле не настоящие кости, а настоящие кости это те, которые не кости.
Точнее, просто кости нужны не для того, чтобы строить из них скелет, а для того, чтобы привязывать к ним искажения меша. А для построения скелета подойдут любые ноды, просто в режиме отображения как будто это кость.
Я понял. Спасибо, анончик, ты мне действительно помог.
>>709203
https://en.wikipedia.org/wiki/Helper_class
> потому что кости это на самом деле не настоящие кости, а настоящие кости это те, которые не кости
https://en.wikipedia.org/wiki/Helper_class
>>709604
В начале бой выглядит норм
В начале бой выглядит норм
>>709901
Не меньше четырех, по крайней мере художник, аниматор, дизайнер уровней и программист. Может быть больше.
У них оказывается еще и кикстартер 2 года назад был, собрали $5000.
Не меньше четырех, по крайней мере художник, аниматор, дизайнер уровней и программист. Может быть больше.
У них оказывается еще и кикстартер 2 года назад был, собрали $5000.
>>709902
+ у них музыкант в коре тиме
+ у них музыкант в коре тиме
>>709892
Годно. Вот только анимации слабоваты, очень каменные. Прям даже глядя на видео персонаж не ощущается плотным или живым.
Годно. Вот только анимации слабоваты, очень каменные. Прям даже глядя на видео персонаж не ощущается плотным или живым.
>>709892
гг не вписывается как-то
гг не вписывается как-то
визуальный скриптинг рабочая тема или костыль лютый? Никогда в жизни не программировал, занимался исключительно цг, а на погромиста денег нет, что очевидно
>>709992
Не попадайся в эту ловушку. Визуальный скриптинг - ЭТО ТОЖЕ ПРОГРАММИРОВАНИЕ. Если у тебя нет кодерского скилла - ты ничего толкового на нодах не соберёшь.
Но вообще, ВС полноценен. Но не нравится лично мне излишней громоздкостью. Все ноды соединяются слева-направо. А мне бы хотелось, чтобы ноды вращались таким образом, чтобы соединять их можно было в любом направлении. В отсутствие этого визуальный скрипт неприлично разрастается в ширину.
Не попадайся в эту ловушку. Визуальный скриптинг - ЭТО ТОЖЕ ПРОГРАММИРОВАНИЕ. Если у тебя нет кодерского скилла - ты ничего толкового на нодах не соберёшь.
Но вообще, ВС полноценен. Но не нравится лично мне излишней громоздкостью. Все ноды соединяются слева-направо. А мне бы хотелось, чтобы ноды вращались таким образом, чтобы соединять их можно было в любом направлении. В отсутствие этого визуальный скрипт неприлично разрастается в ширину.
>>709992
На мой (программистский) взгляд не стоит того.
Дело в том, что в Годоте ВС делали люди с программистским мышлением.
ИМХО стоило загнать в ВС предметную область, а они загнали программерские конструкции.
В самом деле, вместо "создать случайное число" они используют "вызов встроенной функции" в которой параметром "rand_range". Вместо проверки "столкнулись с шаром" там нода "приведение типа" с параметром "ball.vs". Вместо какой нибудь ноды "создать вектор 2d" там нода "конструктор" с параметром "new Vector2()", а вместо "нормализовать" там "базовый вызов" с параметром "Vector2.normalized()".
Лучше уж тогда учить простенький кодинг по туториалам, и спрашивать совета как что делать ИТТ.
На мой (программистский) взгляд не стоит того.
Дело в том, что в Годоте ВС делали люди с программистским мышлением.
ИМХО стоило загнать в ВС предметную область, а они загнали программерские конструкции.
В самом деле, вместо "создать случайное число" они используют "вызов встроенной функции" в которой параметром "rand_range". Вместо проверки "столкнулись с шаром" там нода "приведение типа" с параметром "ball.vs". Вместо какой нибудь ноды "создать вектор 2d" там нода "конструктор" с параметром "new Vector2()", а вместо "нормализовать" там "базовый вызов" с параметром "Vector2.normalized()".
Лучше уж тогда учить простенький кодинг по туториалам, и спрашивать совета как что делать ИТТ.
>>710039
>Лучше уж тогда учить простенький кодинг по туториалам
Я очень плохо понимаю в вашей теме, но из того что я успел понять, что если я буду использовать куски чужого кода это равноценно воровству трейсу чужих рисунков у нас в цг, правильно? Что тогда насчёт кода из туториалов, я могу использовать их в коммерческом проекте?
>Лучше уж тогда учить простенький кодинг по туториалам
Я очень плохо понимаю в вашей теме, но из того что я успел понять, что если я буду использовать куски чужого кода это равноценно воровству трейсу чужих рисунков у нас в цг, правильно? Что тогда насчёт кода из туториалов, я могу использовать их в коммерческом проекте?
>>710061
Начав кодить, ты неизбежно начнёшь понимать, как это работает. Копируя код из туториалов, обнаружишь, что тебе надо его допилить под свой проект. И вообще, если ты из туториала "как нарисовать сову" скопируешь начальные овалы, а потом нарисуешь совсем другую сову, это будет считаться воровством?
Вообще, я вот прямо сейчас сижу и рассказываю ребёнку (8 лет), как кодить в Годоте. Это вот настолько просто.
Начав кодить, ты неизбежно начнёшь понимать, как это работает. Копируя код из туториалов, обнаружишь, что тебе надо его допилить под свой проект. И вообще, если ты из туториала "как нарисовать сову" скопируешь начальные овалы, а потом нарисуешь совсем другую сову, это будет считаться воровством?
Вообще, я вот прямо сейчас сижу и рассказываю ребёнку (8 лет), как кодить в Годоте. Это вот настолько просто.
>>710061
Воровство - когда забираешь то, что тебе не хотели отдавать. Когда ты берёшь опенсорс, это не воровство. Потому что опенсорс тебе хотели отдать и отдали.
> если я буду использовать куски чужого кода это равноценно воровству
Воровство - когда забираешь то, что тебе не хотели отдавать. Когда ты берёшь опенсорс, это не воровство. Потому что опенсорс тебе хотели отдать и отдали.
>>710061
Как и в цг все зависит от лицензии - у вас бывает все что угодно начиная от all rights reserved, когда нельзя ничего, от CC-ND когда можно только смотреть, до CC-0 когда можно все. Обычно код туториала выложен на гитхаб, и там есть лицензия. Часто это MIT или BSD, грубо аналог CC-BY - если используешь должен упомянуть авторство оригинала.
Второй момент заключается в том, что туториалы покрывают базовые вещи, то есть практически азы. Там сложно что то предъявить, это как туториал на рисование квадратов и кубов - что же теперь, никто не может их рисовать?
Как и в цг все зависит от лицензии - у вас бывает все что угодно начиная от all rights reserved, когда нельзя ничего, от CC-ND когда можно только смотреть, до CC-0 когда можно все. Обычно код туториала выложен на гитхаб, и там есть лицензия. Часто это MIT или BSD, грубо аналог CC-BY - если используешь должен упомянуть авторство оригинала.
Второй момент заключается в том, что туториалы покрывают базовые вещи, то есть практически азы. Там сложно что то предъявить, это как туториал на рисование квадратов и кубов - что же теперь, никто не может их рисовать?
>>710116
С чего ты это взял? Не нужно этого делать.
>Часто это MIT или BSD, грубо аналог CC-BY - если используешь должен упомянуть авторство оригинала.
С чего ты это взял? Не нужно этого делать.
>>710129
Насколько я помню их текст, ты обязан предоставить пользователю copyright notice, который идет в начале лицензии используемой либы.
Насколько я помню их текст, ты обязан предоставить пользователю copyright notice, который идет в начале лицензии используемой либы.
>>710116
Насчёт бсд не интересовался, а мит - аналог цц-0. Я специально интересовался. Делая игры на годоте, ты можешь отключить сплеш-скрин. Ну ты понел.
> MIT или BSD, грубо аналог CC-BY
Насчёт бсд не интересовался, а мит - аналог цц-0. Я специально интересовался. Делая игры на годоте, ты можешь отключить сплеш-скрин. Ну ты понел.
153 Кб, 1080x1920>>710135
Нет, даже не близко. Ты обязан include copyright. Это сказано в самом тексте лицензии:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
Более того, в годоте используются либы под apache лицензией, а она требует так же указывать авторство. Это значит что просто указать мит лицензию годота с копирайтом хуана, скорее всего, юридически недостаточно
Так что я бы советовал вообще куда то в about тиснуть содержимое этого файла https://github.com/godotengine/godot/blob/3.2/COPYRIGHT.txt
Даю ссылку на версию 3.2., но надо учитывать что состав либ мог поменяться между билдами
Да, можешь. Нет лицензии которая обязывала бы тебя его показывать.
> мит - аналог цц-0.
Нет, даже не близко. Ты обязан include copyright. Это сказано в самом тексте лицензии:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
Более того, в годоте используются либы под apache лицензией, а она требует так же указывать авторство. Это значит что просто указать мит лицензию годота с копирайтом хуана, скорее всего, юридически недостаточно
Так что я бы советовал вообще куда то в about тиснуть содержимое этого файла https://github.com/godotengine/godot/blob/3.2/COPYRIGHT.txt
Даю ссылку на версию 3.2., но надо учитывать что состав либ мог поменяться между билдами
> ты можешь отключить сплеш-скрин.
Да, можешь. Нет лицензии которая обязывала бы тебя его показывать.
Чувак ртску замутил
https://www.youtube.com/watch?v=ngFuN5MD8hY
https://www.youtube.com/watch?v=ngFuN5MD8hY
>>710147
Перестал смотреть этого инфоцыгана, и вам рекомендую. Начал делать фундаментальный гайд по движку, забросил и хуярит вот такое. Позор. Презрение. Дизлайк. Отписка.
Перестал смотреть этого инфоцыгана, и вам рекомендую. Начал делать фундаментальный гайд по движку, забросил и хуярит вот такое. Позор. Презрение. Дизлайк. Отписка.
Кто ни будь подскажите почему мой код не работает?
Я даже упростил назначение клавиш и всё равно кубик стоит.
Сначала всё делал через список действий, но и там ничего не работает.
Я даже упростил назначение клавиш и всё равно кубик стоит.
Сначала всё делал через список действий, но и там ничего не работает.
>>710211
Velocity - это твоя переменная. Она ни к чему не подключена.¯\_(ツ)_/¯
Очевидно тебе надо делать Position += Velocity или какой нибудь MoveAndSlide.
Velocity - это твоя переменная. Она ни к чему не подключена.¯\_(ツ)_/¯
Очевидно тебе надо делать Position += Velocity или какой нибудь MoveAndSlide.
>>710211
Потому что ты просто написал, что у тебя velocity чему-то равна. Для движения kinematic body нужно вызвать метод move_and_slide/move_and_collide. Еще я не понял, зачем тебе вообще spatial node.
Потому что ты просто написал, что у тебя velocity чему-то равна. Для движения kinematic body нужно вызвать метод move_and_slide/move_and_collide. Еще я не понял, зачем тебе вообще spatial node.
>>710215
Да, еще, если используешь kinematic body, то двигать лучше с помощью physics process, а не просто process.
Да, еще, если используешь kinematic body, то двигать лучше с помощью physics process, а не просто process.
>>710215
Просто неудачно гайды посмотрел и не правильно понял. Простим нашему новому брату сию оплошность?
> Еще я не понял, зачем тебе вообще spatial node.
Просто неудачно гайды посмотрел и не правильно понял. Простим нашему новому брату сию оплошность?
Ловлю очередное подгорание от загрузки игры.
Делаю так. Сначала очищаю игровое поле. Потом подгружаю тайлмап (словарь, у которого ключи это вектора, а значения это виды тайлов). После тайлмапа загружаю всякие дополнительные объекты-сцены. После загрузки всё молча падает.
Файл сейва не битый, загружается корректно.
Игровое поле очищается корректно, если запускать очистку без загрузки.
Какую бы часть из непосредственно загрузки ресурса я ни удалял, падает всё равно.
Предохранился, обернул все добавления в дерево при помощи call_deferred. Не помогло.
По точкам останова прошёл весь процесс загрузки, никаких проблем. Падение наступает позже.
Проект довольно простой, загружается, кроме тайлов, всего два объекта.
Вот как это отлавливать?
Делаю так. Сначала очищаю игровое поле. Потом подгружаю тайлмап (словарь, у которого ключи это вектора, а значения это виды тайлов). После тайлмапа загружаю всякие дополнительные объекты-сцены. После загрузки всё молча падает.
Файл сейва не битый, загружается корректно.
Игровое поле очищается корректно, если запускать очистку без загрузки.
Какую бы часть из непосредственно загрузки ресурса я ни удалял, падает всё равно.
Предохранился, обернул все добавления в дерево при помощи call_deferred. Не помогло.
По точкам останова прошёл весь процесс загрузки, никаких проблем. Падение наступает позже.
Проект довольно простой, загружается, кроме тайлов, всего два объекта.
Вот как это отлавливать?
>>710245
Лично я в таких ситуациях начинаю логгировать все действия. Чем подробнее, тем лучше. Необязательно в файл, можно прям в консоль. На чём вылетит, на той строке лог и прервётся. С теми переменными, которые ты подозреваешь.
Если и так не получается отладить - пили модульные тесты, как настоящий программист.
> Вот как это отлавливать?
Лично я в таких ситуациях начинаю логгировать все действия. Чем подробнее, тем лучше. Необязательно в файл, можно прям в консоль. На чём вылетит, на той строке лог и прервётся. С теми переменными, которые ты подозреваешь.
Если и так не получается отладить - пили модульные тесты, как настоящий программист.
>>710253
Ни на чём. В момент вылетания не выполняется никакой мой код. Загрузка всего завершена, все ноды выполнили свои _ready, а ноды, имеющие _physics_process, будут созданы позже игроком.
Я не настоящий программист. Погуглил, чоэтотакое. По частям-то у меня всё работает. Не работает только всё вместе.
>На чём вылетит, на той строке лог и прервётся
Ни на чём. В момент вылетания не выполняется никакой мой код. Загрузка всего завершена, все ноды выполнили свои _ready, а ноды, имеющие _physics_process, будут созданы позже игроком.
>как настоящий программист
Я не настоящий программист. Погуглил, чоэтотакое. По частям-то у меня всё работает. Не работает только всё вместе.
>>710274
Выкладывай проект на любой файлообменник (ну или копию проекта без твоих ресурсов, но с воспроизводящейся проблемой) и ссылку сюда. Будем посмотреть, что у тебя там.
Выкладывай проект на любой файлообменник (ну или копию проекта без твоих ресурсов, но с воспроизводящейся проблемой) и ссылку сюда. Будем посмотреть, что у тебя там.
А теперь у меня >>710245 подгорает от собственной тупости.
Я не делал сохранению и загрузке какого-либо интерфейса, просто повесил на привычные по большинству игр клавиши F5 и F8. Катарсис наступил, когда я закомментил вообще весь код, срабатывающий после выполнения клавиши F8, а игра всё равно молча падала. Ну да, я ж её, получается, сам и останавливал.
Я не делал сохранению и загрузке какого-либо интерфейса, просто повесил на привычные по большинству игр клавиши F5 и F8. Катарсис наступил, когда я закомментил вообще весь код, срабатывающий после выполнения клавиши F8, а игра всё равно молча падала. Ну да, я ж её, получается, сам и останавливал.
>>710341
Бывает. Штош. Проблема решена?
Бывает. Штош. Проблема решена?
А кто-нибудь юзал веб-версию движка? Я чёт попытался скормить ему ZIP-файл с проектом, не видит.
>>710401
Фича новая. Понимать надо. Оформи багрепорт.
Фича новая. Понимать надо. Оформи багрепорт.
>>710401
1. закидываешь Zip. Он заливается в файл preload.zip
2. нажимаешь Import, выбираешь preload.zip
3. во второй строчке создаешь новую папку под проект.
Например /home/web_user/projects/your_excellent_game
1. закидываешь Zip. Он заливается в файл preload.zip
2. нажимаешь Import, выбираешь preload.zip
3. во второй строчке создаешь новую папку под проект.
Например /home/web_user/projects/your_excellent_game
Возможно ли на Godot создать Action/RPG с элементами dungeon crawler?
Спрашиваю без рофлов, а потому что интересно.
Спрашиваю без рофлов, а потому что интересно.
>>710544
Возможно.
Возможно.
>>710544
Что-то такого уровня делают люди.
Что-то такого уровня делают люди.
>>710544
Возможно.
Командой от 3 человек.
Вас сколько?
> Возможно ли ... создать Action/RPG с элементами dungeon crawler?
Возможно.
Командой от 3 человек.
Вас сколько?
>>710419
Немножко не очевидная последовательность действий. Спасибо, анон.
Немножко не очевидная последовательность действий. Спасибо, анон.
>>710568
Ну тогда от 10 лет. Только на прототип. За убийство столько не дают.
Я не троллю. Сам начал игру мечты уже три года как назад. Пока что в процессе прототипирования базовых механик нахожусь.
Ну тогда от 10 лет. Только на прототип. За убийство столько не дают.
Я не троллю. Сам начал игру мечты уже три года как назад. Пока что в процессе прототипирования базовых механик нахожусь.
>>710567
Не помню именно изометрических. Туториалов на просто 2д рпг и отдельно изометрию полно.
Не помню именно изометрических. Туториалов на просто 2д рпг и отдельно изометрию полно.
Офигеть, туториал с бесплатными ассетами для 3д шутера!
https://www.youtube.com/watch?v=DPTsTr9Fi_Q&list=PLqbBeBobXe08DLRMDMyY2YXLx-Q4R9Ujl&index=1
https://www.youtube.com/watch?v=DPTsTr9Fi_Q&list=PLqbBeBobXe08DLRMDMyY2YXLx-Q4R9Ujl&index=1
>>710583
Да, крутой ассет.
Если интересен процесс создания, вот первый плейлист
https://www.youtube.com/watch?v=rgpcSJTTGoc&list=PLqbBeBobXe09NZez_1LLRcT7NQ9NfUCBC
(у тебя второй)
Да, крутой ассет.
Если интересен процесс создания, вот первый плейлист
https://www.youtube.com/watch?v=rgpcSJTTGoc&list=PLqbBeBobXe09NZez_1LLRcT7NQ9NfUCBC
(у тебя второй)
>>710583
Хуёво что от третьего лица, воспринимать как шутер трудно, хотя зумерам норм скорей всего
Хуёво что от третьего лица, воспринимать как шутер трудно, хотя зумерам норм скорей всего
>>710606
От первого ещё проще контроллер (анимировать увороты и перекаты не надо). И ассеты на него уже имеются.
От первого ещё проще контроллер (анимировать увороты и перекаты не надо). И ассеты на него уже имеются.
>>710611
Сомневаюсь. Оружие-то всё равно своё приделывать, следовательно и анимации свои подгонять. Но я уверен ты найдёшь с ригом рук и анимированным базовым пистолетиком. Надо только загуглить. Всё, я спать.
Сомневаюсь. Оружие-то всё равно своё приделывать, следовательно и анимации свои подгонять. Но я уверен ты найдёшь с ригом рук и анимированным базовым пистолетиком. Надо только загуглить. Всё, я спать.
>>710613
Я имею ввиду, риг - это не проблема. Проблема в анимациях на нём основанных. Гораздо проще сразу заанимированные руки-крюки-базуки экспортнуть в глтф какой-нибудь, чем вытаскивать из ассетного глтф в блендер модель, ебаться с ней, а потом переэкспортировать обратно?
Честное слово - проще самому всё сделать.
Ну всё, ушёл.
Я имею ввиду, риг - это не проблема. Проблема в анимациях на нём основанных. Гораздо проще сразу заанимированные руки-крюки-базуки экспортнуть в глтф какой-нибудь, чем вытаскивать из ассетного глтф в блендер модель, ебаться с ней, а потом переэкспортировать обратно?
Честное слово - проще самому всё сделать.
Ну всё, ушёл.
>>710613
Ну в этом же тоже модельку подменять, однако она есть.
Можно же просто подсунуть другие модельки рук, и переименовать анимации, не?
>>710614
Те что я смотрел были довольно куцыми по функционалу, приседаний нет, ступеньки низкие не перешагивают. Хотя при этом встречается и бег по стенам, и зацепление крюком.
Ну в этом же тоже модельку подменять, однако она есть.
>Оружие-то всё равно своё приделывать, следовательно и анимации свои подгонять.
Можно же просто подсунуть другие модельки рук, и переименовать анимации, не?
>>710614
Те что я смотрел были довольно куцыми по функционалу, приседаний нет, ступеньки низкие не перешагивают. Хотя при этом встречается и бег по стенам, и зацепление крюком.
>>710606
Меня в последнее время стало укачивать от первого лица особенно быстрых шутерах типа халфы.
А здесь ничего так, можно модельку ГГ забабахать красивую, анимацию приделать, опять же боёвка будет более наглядной.
Меня кстати всегда это добивало. Шутер от первого лица вижу врагов, вижу обстановку, но не вижу себя кроме 2х рук и если повезёт ног. Не логично.
>Хуёво что от третьего лица, воспринимать как шутер трудно
Меня в последнее время стало укачивать от первого лица особенно быстрых шутерах типа халфы.
А здесь ничего так, можно модельку ГГ забабахать красивую, анимацию приделать, опять же боёвка будет более наглядной.
Меня кстати всегда это добивало. Шутер от первого лица вижу врагов, вижу обстановку, но не вижу себя кроме 2х рук и если повезёт ног. Не логично.
>>710606
У бумеров была плойка с кучей игр от третьего лица.
Но если вырос на досе, то тогда увы конечно.
Только серия гта 3 вспоминается
У бумеров была плойка с кучей игр от третьего лица.
Но если вырос на досе, то тогда увы конечно.
Только серия гта 3 вспоминается
233 Кб, 339x259>>710647
Да, есть удобство игры от третьего лица, так же как в гонках, но минус атмосфера.
Да, есть удобство игры от третьего лица, так же как в гонках, но минус атмосфера.
>>710617
Возьми этот и перемести точку крепления камеры на переносицу персонажа. Получишь современный FPC с видимыми ногами и сисечками.
У меня другая проблема с ассетными контроллерами.
Все они предполагают базовый функционал. Чтобы допилить мне свой, мне придётся привыкать к привычкам кодинга автора ассета. Например, у него в туториалах все переменные нетипизированные. Мне, как диду-паскалисту, это как серпом по яйцам. То есть первое же, что мне придётся сделать с ассетом, это переписать все определения вида var velocity = Vector3() на var velocity : Vector3 = Vector3.ZERO
Далее.
Множество ассетов тянется с версии 3.0 а то и с 2.0. И там уже на сегодняшний день существует легаси натуральное. Например, подгрузка скриптов через preload вместо раздачи нужным скриптам имён и конструированием их классов через new(). Это тоже весьма раздражает. Хочется взять и переписать.
И самое главное.
Контроллер-ассеты (если вернуться к ним) предоставляют базовую функциональность. Мне кроме ходьбы/бега нужно перемещение по лестницам (вертикальным). А ещё мне хочется, чтобы колёсиком мыши менялась длина плеча камеры за спиной и в крайнем ближнем положении переключалась на вид от первого лица. Как я описал в первом предложении.
Бленд-дерево слишком простое. Помимо перекатов туда ещё следует добавить анимации активностей, добавить логику, при которой проигрывается короткая анимация начала активности, потом играется бесконечная анимация тела активности, а потом следует предусмотреть несколько коротких конечных анимаций конца активности (нормальная при окончании активности, при прерывании игроком, при уроне мобом, при изменении условий на локации).
А ещё я хочу, чтобы при получении абилки, персонаж мог летать. Следовательно, при активации абилки игроком, бленд-дерево переключается на анимацию полёта, а стейт-машина персонажа должна переключиться с логики ходьбы/бега на логику полёта на крыле.
А ещё я хочу, чтобы в режиме боя включалась имитация пошаговой боёвки, при которой локация дробится на кубы, персонаж перемещается из одного центра куба в другой, когда у него есть ОД (очки действия, ходы) и их хватает на перемещение туда. При этом персонаж переключается в режим ожидания, когда ОД нет и ходят мобы, и получая урон от них, проигрывает соответствующую анимацию.
Такие задачи в принципе нерешаемы дженерик-контроллерами.
Допустим, некоторая фирма продаёт сложный модульный контроллер, со своим фактически АПИ. Который может ходить (тремя способами искаропки с возможностью написать свой модуль ходьбы), летать (двумя способами), ползать, карабкаться, взбираться, имеет расширяемое бленд-дерево, в которое простыми жсон-файлами мы можем добавить логику с путями к анимациям. Допустим я купил его. И теперь помимо основного движка мне нужно учить АПИ ассета. Охуеть просто какой геймдев!
Реально проще изучить матчасть и запилить свой контроллер с нуля. С твоими привычками кодинга и с удобным тебе расположением ресурсов.
> Те что я смотрел были довольно куцыми по функционалу
Возьми этот и перемести точку крепления камеры на переносицу персонажа. Получишь современный FPC с видимыми ногами и сисечками.
У меня другая проблема с ассетными контроллерами.
Все они предполагают базовый функционал. Чтобы допилить мне свой, мне придётся привыкать к привычкам кодинга автора ассета. Например, у него в туториалах все переменные нетипизированные. Мне, как диду-паскалисту, это как серпом по яйцам. То есть первое же, что мне придётся сделать с ассетом, это переписать все определения вида var velocity = Vector3() на var velocity : Vector3 = Vector3.ZERO
Далее.
Множество ассетов тянется с версии 3.0 а то и с 2.0. И там уже на сегодняшний день существует легаси натуральное. Например, подгрузка скриптов через preload вместо раздачи нужным скриптам имён и конструированием их классов через new(). Это тоже весьма раздражает. Хочется взять и переписать.
И самое главное.
Контроллер-ассеты (если вернуться к ним) предоставляют базовую функциональность. Мне кроме ходьбы/бега нужно перемещение по лестницам (вертикальным). А ещё мне хочется, чтобы колёсиком мыши менялась длина плеча камеры за спиной и в крайнем ближнем положении переключалась на вид от первого лица. Как я описал в первом предложении.
Бленд-дерево слишком простое. Помимо перекатов туда ещё следует добавить анимации активностей, добавить логику, при которой проигрывается короткая анимация начала активности, потом играется бесконечная анимация тела активности, а потом следует предусмотреть несколько коротких конечных анимаций конца активности (нормальная при окончании активности, при прерывании игроком, при уроне мобом, при изменении условий на локации).
А ещё я хочу, чтобы при получении абилки, персонаж мог летать. Следовательно, при активации абилки игроком, бленд-дерево переключается на анимацию полёта, а стейт-машина персонажа должна переключиться с логики ходьбы/бега на логику полёта на крыле.
А ещё я хочу, чтобы в режиме боя включалась имитация пошаговой боёвки, при которой локация дробится на кубы, персонаж перемещается из одного центра куба в другой, когда у него есть ОД (очки действия, ходы) и их хватает на перемещение туда. При этом персонаж переключается в режим ожидания, когда ОД нет и ходят мобы, и получая урон от них, проигрывает соответствующую анимацию.
Такие задачи в принципе нерешаемы дженерик-контроллерами.
Допустим, некоторая фирма продаёт сложный модульный контроллер, со своим фактически АПИ. Который может ходить (тремя способами искаропки с возможностью написать свой модуль ходьбы), летать (двумя способами), ползать, карабкаться, взбираться, имеет расширяемое бленд-дерево, в которое простыми жсон-файлами мы можем добавить логику с путями к анимациям. Допустим я купил его. И теперь помимо основного движка мне нужно учить АПИ ассета. Охуеть просто какой геймдев!
Реально проще изучить матчасть и запилить свой контроллер с нуля. С твоими привычками кодинга и с удобным тебе расположением ресурсов.
>>710617
Возьми этот и перемести точку крепления камеры на переносицу персонажа. Получишь современный FPC с видимыми ногами и сисечками.
У меня другая проблема с ассетными контроллерами.
Все они предполагают базовый функционал. Чтобы допилить мне свой, мне придётся привыкать к привычкам кодинга автора ассета. Например, у него в туториалах все переменные нетипизированные. Мне, как диду-паскалисту, это как серпом по яйцам. То есть первое же, что мне придётся сделать с ассетом, это переписать все определения вида var velocity = Vector3() на var velocity : Vector3 = Vector3.ZERO
Далее.
Множество ассетов тянется с версии 3.0 а то и с 2.0. И там уже на сегодняшний день существует легаси натуральное. Например, подгрузка скриптов через preload вместо раздачи нужным скриптам имён и конструированием их классов через new(). Это тоже весьма раздражает. Хочется взять и переписать.
И самое главное.
Контроллер-ассеты (если вернуться к ним) предоставляют базовую функциональность. Мне кроме ходьбы/бега нужно перемещение по лестницам (вертикальным). А ещё мне хочется, чтобы колёсиком мыши менялась длина плеча камеры за спиной и в крайнем ближнем положении переключалась на вид от первого лица. Как я описал в первом предложении.
Бленд-дерево слишком простое. Помимо перекатов туда ещё следует добавить анимации активностей, добавить логику, при которой проигрывается короткая анимация начала активности, потом играется бесконечная анимация тела активности, а потом следует предусмотреть несколько коротких конечных анимаций конца активности (нормальная при окончании активности, при прерывании игроком, при уроне мобом, при изменении условий на локации).
А ещё я хочу, чтобы при получении абилки, персонаж мог летать. Следовательно, при активации абилки игроком, бленд-дерево переключается на анимацию полёта, а стейт-машина персонажа должна переключиться с логики ходьбы/бега на логику полёта на крыле.
А ещё я хочу, чтобы в режиме боя включалась имитация пошаговой боёвки, при которой локация дробится на кубы, персонаж перемещается из одного центра куба в другой, когда у него есть ОД (очки действия, ходы) и их хватает на перемещение туда. При этом персонаж переключается в режим ожидания, когда ОД нет и ходят мобы, и получая урон от них, проигрывает соответствующую анимацию.
Такие задачи в принципе нерешаемы дженерик-контроллерами.
Допустим, некоторая фирма продаёт сложный модульный контроллер, со своим фактически АПИ. Который может ходить (тремя способами искаропки с возможностью написать свой модуль ходьбы), летать (двумя способами), ползать, карабкаться, взбираться, имеет расширяемое бленд-дерево, в которое простыми жсон-файлами мы можем добавить логику с путями к анимациям. Допустим я купил его. И теперь помимо основного движка мне нужно учить АПИ ассета. Охуеть просто какой геймдев!
Реально проще изучить матчасть и запилить свой контроллер с нуля. С твоими привычками кодинга и с удобным тебе расположением ресурсов.
> Те что я смотрел были довольно куцыми по функционалу
Возьми этот и перемести точку крепления камеры на переносицу персонажа. Получишь современный FPC с видимыми ногами и сисечками.
У меня другая проблема с ассетными контроллерами.
Все они предполагают базовый функционал. Чтобы допилить мне свой, мне придётся привыкать к привычкам кодинга автора ассета. Например, у него в туториалах все переменные нетипизированные. Мне, как диду-паскалисту, это как серпом по яйцам. То есть первое же, что мне придётся сделать с ассетом, это переписать все определения вида var velocity = Vector3() на var velocity : Vector3 = Vector3.ZERO
Далее.
Множество ассетов тянется с версии 3.0 а то и с 2.0. И там уже на сегодняшний день существует легаси натуральное. Например, подгрузка скриптов через preload вместо раздачи нужным скриптам имён и конструированием их классов через new(). Это тоже весьма раздражает. Хочется взять и переписать.
И самое главное.
Контроллер-ассеты (если вернуться к ним) предоставляют базовую функциональность. Мне кроме ходьбы/бега нужно перемещение по лестницам (вертикальным). А ещё мне хочется, чтобы колёсиком мыши менялась длина плеча камеры за спиной и в крайнем ближнем положении переключалась на вид от первого лица. Как я описал в первом предложении.
Бленд-дерево слишком простое. Помимо перекатов туда ещё следует добавить анимации активностей, добавить логику, при которой проигрывается короткая анимация начала активности, потом играется бесконечная анимация тела активности, а потом следует предусмотреть несколько коротких конечных анимаций конца активности (нормальная при окончании активности, при прерывании игроком, при уроне мобом, при изменении условий на локации).
А ещё я хочу, чтобы при получении абилки, персонаж мог летать. Следовательно, при активации абилки игроком, бленд-дерево переключается на анимацию полёта, а стейт-машина персонажа должна переключиться с логики ходьбы/бега на логику полёта на крыле.
А ещё я хочу, чтобы в режиме боя включалась имитация пошаговой боёвки, при которой локация дробится на кубы, персонаж перемещается из одного центра куба в другой, когда у него есть ОД (очки действия, ходы) и их хватает на перемещение туда. При этом персонаж переключается в режим ожидания, когда ОД нет и ходят мобы, и получая урон от них, проигрывает соответствующую анимацию.
Такие задачи в принципе нерешаемы дженерик-контроллерами.
Допустим, некоторая фирма продаёт сложный модульный контроллер, со своим фактически АПИ. Который может ходить (тремя способами искаропки с возможностью написать свой модуль ходьбы), летать (двумя способами), ползать, карабкаться, взбираться, имеет расширяемое бленд-дерево, в которое простыми жсон-файлами мы можем добавить логику с путями к анимациям. Допустим я купил его. И теперь помимо основного движка мне нужно учить АПИ ассета. Охуеть просто какой геймдев!
Реально проще изучить матчасть и запилить свой контроллер с нуля. С твоими привычками кодинга и с удобным тебе расположением ресурсов.
>>710706
Ах да, если я хочу контроллер в слешерную игору, я автоматически иду нахуй, потому что 99% ассетов дженерик-сцай-файные с пистолетиком и механикой стрельбы. А для слешера мне мало того, что придётся переделывать скелет. Мне под каждое холодное оружие придётся добавить свои мувсеты и добавить их целой пачкой в бленд-дерево. (Держим в уме, что персонаж в любой момент может получить абилку полёта и махать клинком в полёте нужен отдельный мувсет). (И не забываем, что карабкаясь по лестницам персонаж может отмахиваться от набигающих вражин ещё одним отдельным мувсетом). (И имеем ввиду, что мувсет не даётся игроку целиком, а постепенно открывается при прокачке, следовательно следует предусмотреть блокировку частей каждого мувсета по отдельности).
И ещё. Если я хочу, чтобы контроллеры персонажей не были жестко прибиты к игроку гвоздями, а могли своей стейт-машиной переключаться с AI на управление игроком когда надо - то я тоже иду нахуй.
Ах да, если я хочу контроллер в слешерную игору, я автоматически иду нахуй, потому что 99% ассетов дженерик-сцай-файные с пистолетиком и механикой стрельбы. А для слешера мне мало того, что придётся переделывать скелет. Мне под каждое холодное оружие придётся добавить свои мувсеты и добавить их целой пачкой в бленд-дерево. (Держим в уме, что персонаж в любой момент может получить абилку полёта и махать клинком в полёте нужен отдельный мувсет). (И не забываем, что карабкаясь по лестницам персонаж может отмахиваться от набигающих вражин ещё одним отдельным мувсетом). (И имеем ввиду, что мувсет не даётся игроку целиком, а постепенно открывается при прокачке, следовательно следует предусмотреть блокировку частей каждого мувсета по отдельности).
И ещё. Если я хочу, чтобы контроллеры персонажей не были жестко прибиты к игроку гвоздями, а могли своей стейт-машиной переключаться с AI на управление игроком когда надо - то я тоже иду нахуй.
1 Мб, 1920x1080>>710706
Даже эта простая операция на чужом ассете обладает подводными камнями.
Попробовал сейчас. Результат пикрелейтед. Когда стоишь на месте выглядит неплохо. Когда бежишь - лицо маячит перед камерой. Лень видос записывать.
В общем:
1. добавляем на кончик носа отдельную камеру.
2. добавляем флаг FPC в код.
3. по нажатию F (или прокрутке колёсика до упора вперёд) меняем значение флага.
4. переключаемся между камерами искаропки (да их там две, зачем - не вникал) (FPC=false) и камерой на носу (FPC=true).
5. ПРОФИТ(?)
> Возьми этот и перемести точку крепления камеры на переносицу персонажа.
Даже эта простая операция на чужом ассете обладает подводными камнями.
Попробовал сейчас. Результат пикрелейтед. Когда стоишь на месте выглядит неплохо. Когда бежишь - лицо маячит перед камерой. Лень видос записывать.
В общем:
1. добавляем на кончик носа отдельную камеру.
2. добавляем флаг FPC в код.
3. по нажатию F (или прокрутке колёсика до упора вперёд) меняем значение флага.
4. переключаемся между камерами искаропки (да их там две, зачем - не вникал) (FPC=false) и камерой на носу (FPC=true).
5. ПРОФИТ(?)
>>710710
4.1. Для режима FPC: Пишем заново логику поворота камеры вверх-вниз, а вместо поворота камеры вправо-влево пишем логику поворота тела.
Быстрофикс.
4.1. Для режима FPC: Пишем заново логику поворота камеры вверх-вниз, а вместо поворота камеры вправо-влево пишем логику поворота тела.
Быстрофикс.
Годотаны, есть у меня такой вопрос.
Двумерный изометрический пруф оф концепт. Есть две тайлмапы для пола и стенок, пол в том числе под стенками (стенки не занимают весь ромб, да ещё и торчат наверх, как обычно). Есть ли способ сделать красиво сделать автоматическую навигацию «вычитая» из общего навигационного полигона стенки? Или лучше добавить к тайлсету стенок прозрачный и проходимый тайл и впихивать повсюду в пустые места?
Или с навигацией в тайлах есть подводные камни и стоит не сношать мозги, а нарисовать полигон вручную? Всё равно тестовый уровень тестового уровня.
И второй вопрос: простого способа организовать правильную сортировку тайловой карты и спрайтов, чтобы видеть ровно то, что нужно, не существует? Понятное дело, что это не очень тривиальная задача, но очевидно, что её уже кто-то решил.
Опять-таки, если нет — я забью, у меня там сейчас спрайты на три кадра, и дрочить нужно не это, а игромеханики.
Двумерный изометрический пруф оф концепт. Есть две тайлмапы для пола и стенок, пол в том числе под стенками (стенки не занимают весь ромб, да ещё и торчат наверх, как обычно). Есть ли способ сделать красиво сделать автоматическую навигацию «вычитая» из общего навигационного полигона стенки? Или лучше добавить к тайлсету стенок прозрачный и проходимый тайл и впихивать повсюду в пустые места?
Или с навигацией в тайлах есть подводные камни и стоит не сношать мозги, а нарисовать полигон вручную? Всё равно тестовый уровень тестового уровня.
И второй вопрос: простого способа организовать правильную сортировку тайловой карты и спрайтов, чтобы видеть ровно то, что нужно, не существует? Понятное дело, что это не очень тривиальная задача, но очевидно, что её уже кто-то решил.
Опять-таки, если нет — я забью, у меня там сейчас спрайты на три кадра, и дрочить нужно не это, а игромеханики.
>>710796
ЕЯПП, то ответом будет Y-sort. Но вообще чёт ты как-то не очень ясно выражаешься, и первый вопрос я вообще не понял.
>второй вопрос
ЕЯПП, то ответом будет Y-sort. Но вообще чёт ты как-то не очень ясно выражаешься, и первый вопрос я вообще не понял.
>>710796
Я не очень понял твой вопрос, но я писал импортер из редактора уровней и никаких проблем с генерацией кастомных полигонов коллизий нужной формы из кода не было.
Я не очень понял твой вопрос, но я писал импортер из редактора уровней и никаких проблем с генерацией кастомных полигонов коллизий нужной формы из кода не было.
>>710800
Кстати, да, Ysort я для этого не пробовал, потому что думал, что он всю тайлокарту одним объектом считать будет.
А про первый вопрос — всё просто: навигация возможна везде, где не стоит стена, поэтому помимо инструмента «вот тут можно пройти» хорошо бы иметь инструмент «нет, вот тут пройти низзя». Тогда можно было бы все тайлы пола покрыть навигационным полигоном, а тайлы стен тогда вырезали бы из него непроходимые куски.
Но ладно, это уже раскат губы, пойду немножко по-другому сделаю, спасибо.
Кстати, да, Ysort я для этого не пробовал, потому что думал, что он всю тайлокарту одним объектом считать будет.
А про первый вопрос — всё просто: навигация возможна везде, где не стоит стена, поэтому помимо инструмента «вот тут можно пройти» хорошо бы иметь инструмент «нет, вот тут пройти низзя». Тогда можно было бы все тайлы пола покрыть навигационным полигоном, а тайлы стен тогда вырезали бы из него непроходимые куски.
Но ладно, это уже раскат губы, пойду немножко по-другому сделаю, спасибо.
>>710802
Kurwa! А навигацию на тайлах-то не видно в редакторе. Придётся для дебага чего-нибудь рисовать, видимо.
Или действительно не сношать мозги и импортировать из файла, но тайлоредактор-то в целом сносный.
Kurwa! А навигацию на тайлах-то не видно в редакторе. Придётся для дебага чего-нибудь рисовать, видимо.
Или действительно не сношать мозги и импортировать из файла, но тайлоредактор-то в целом сносный.
>>710802
Более того тебе скажу, в тайлмапе для каждого отдельного тайла можно настроить положение по оси Z.
Более того тебе скажу, в тайлмапе для каждого отдельного тайла можно настроить положение по оси Z.
Немцы чо творят, а!
https://www.youtube.com/watch?v=qS3pMa8D7PM
https://www.youtube.com/watch?v=qS3pMa8D7PM
>>710811
В общем, лучше переходить на какой-нибудь нестандартный редактор тайлов. Я люблю защищать стандартный, но он действительно кривоват.
В общем, лучше переходить на какой-нибудь нестандартный редактор тайлов. Я люблю защищать стандартный, но он действительно кривоват.
>>710864
С чего такие выводы, лол?
С чего такие выводы, лол?
Обджект пуллинг на пятнадцатой минуте
https://youtu.be/ExgFb3LowIQ?list=PLqbBeBobXe08DLRMDMyY2YXLx-Q4R9Ujl&t=900
То, о чем два тжреада мусолили.
https://youtu.be/ExgFb3LowIQ?list=PLqbBeBobXe08DLRMDMyY2YXLx-Q4R9Ujl&t=900
То, о чем два тжреада мусолили.
>>710874
Вот и я о том же, вместо распинания можно сразу скидывать туторы с решением проблем.
Вот и я о том же, вместо распинания можно сразу скидывать туторы с решением проблем.
>>710875
Если бы ещё обладать скиллом сразу находить нужный туториал... Иногда задают вопрос, и помню же, что видел такой видос с детальным разбором проблемы. Но найти не могу.
Если бы ещё обладать скиллом сразу находить нужный туториал... Иногда задают вопрос, и помню же, что видел такой видос с детальным разбором проблемы. Но найти не могу.
Зачем-то скомпилировал форк ecs под 3.2. Скорее всего не заработает, много всего в плюсах накостылил, да и тестовый проект сегодня лень писать.
>>710902
Мне казалось это такой прикол был: Форсить ЕЦС, который придумали кодеры нотидог для обхода ограничений плойки. Плойки, Карл! Всё что даёт ЕЦС на современных ИГРОВЫХ пека, это тысячные доли секунды выигрыша. Зато эти доли секунды ты покупаешь ценой отказа от удобных кодерских инструментов и задрачивания сотен текстовых датафайлов. Мда.
> ecs
Мне казалось это такой прикол был: Форсить ЕЦС, который придумали кодеры нотидог для обхода ограничений плойки. Плойки, Карл! Всё что даёт ЕЦС на современных ИГРОВЫХ пека, это тысячные доли секунды выигрыша. Зато эти доли секунды ты покупаешь ценой отказа от удобных кодерских инструментов и задрачивания сотен текстовых датафайлов. Мда.
>>710906
Ну автор у себя в синтетике намерял 5х прирост.
https://twitter.com/_AndreaCatania/status/1312824560358752256
Впрочем, в моем текущем проекте сам подход ecs удобнее будет, даже если я его на ООП напишу, тупо удобнее развешивать статусы на персонажей.
Ну автор у себя в синтетике намерял 5х прирост.
https://twitter.com/_AndreaCatania/status/1312824560358752256
Впрочем, в моем текущем проекте сам подход ecs удобнее будет, даже если я его на ООП напишу, тупо удобнее развешивать статусы на персонажей.
>>710906
Какбе у тебя на кадр этих тысячных всего 16. Так что выигрыш тысячных долей секунды это пиздец как важно.
>тысячные доли секунды выигрыш
Какбе у тебя на кадр этих тысячных всего 16. Так что выигрыш тысячных долей секунды это пиздец как важно.
>>710907
в синтетике (саркастический жест)
ЕЦС - это паттерн ООП, такшта в любом случае ты пишешь на ООП, системы - есть классы, компоненты - классы, сущности - классы. Накладные расходы ООП известны и описаны в литературе ещё 80х годов. Ты отказываешься от наследования и гоняешь текстовые конфиги между компонентами и системами. И тебе тупо удобно. Да.
ЕЦС в случае плойки - жёсткая необходимость и ловкое решение. ЕЦС в остальных случаях - подростковый нигилизм по типу "МАМ, НЕ ХОЧУ ЗАМШЕЛЫЙ ООП, ХОЧУ ЧТО-ТО МОЛОДЁЖНОЕ"
>>710914
Как по мне - важнее качественный арт и эффекты. А ещё важнее - интересный геймплей. А выигрывать кадр на синтетическом тесте, когда ещё игоря тонет - это ящитаю преждевременная оптимизация во всей красе.
> автор у себя в синтетике намерял 5х прирост
в синтетике (саркастический жест)
> если я его на ООП напишу
ЕЦС - это паттерн ООП, такшта в любом случае ты пишешь на ООП, системы - есть классы, компоненты - классы, сущности - классы. Накладные расходы ООП известны и описаны в литературе ещё 80х годов. Ты отказываешься от наследования и гоняешь текстовые конфиги между компонентами и системами. И тебе тупо удобно. Да.
ЕЦС в случае плойки - жёсткая необходимость и ловкое решение. ЕЦС в остальных случаях - подростковый нигилизм по типу "МАМ, НЕ ХОЧУ ЗАМШЕЛЫЙ ООП, ХОЧУ ЧТО-ТО МОЛОДЁЖНОЕ"
>>710914
> это пиздец как важно
Как по мне - важнее качественный арт и эффекты. А ещё важнее - интересный геймплей. А выигрывать кадр на синтетическом тесте, когда ещё игоря тонет - это ящитаю преждевременная оптимизация во всей красе.
>>710943
Я пробовал esc. Очень удобный модульный подход, но его работоспособность в разы медленнее дефолтного наследования. А если юзать не наследование, а структуры, так вообще слоупочная хуйня.
Я пробовал esc. Очень удобный модульный подход, но его работоспособность в разы медленнее дефолтного наследования. А если юзать не наследование, а структуры, так вообще слоупочная хуйня.
>>710961
Толсто.
>его работоспособность в разы медленнее дефолтного наследования. А если юзать не наследование, а структуры, так вообще слоупочная хуйня.
Толсто.
>>711087
Слушай, ECS не так работает, массивы компонентов-pod структур, (даже в C# это делается через unmanaged доступ к памяти) никаких "объявлений функций" они с собой не возят, у нас тут не JS, системы это просто функции, сущности это вообще просто int id. Если у тебя что то тормозило, то это значит у тебя неправильная реализация, вот и все.
Слушай, ECS не так работает, массивы компонентов-pod структур, (даже в C# это делается через unmanaged доступ к памяти) никаких "объявлений функций" они с собой не возят, у нас тут не JS, системы это просто функции, сущности это вообще просто int id. Если у тебя что то тормозило, то это значит у тебя неправильная реализация, вот и все.
Доставка контента.
https://www.youtube.com/watch?v=FSktK9WLp0w
https://www.youtube.com/watch?v=FSktK9WLp0w
>>711270
Я ошибочно прочитал за одну неделю как за один месяц, my bad.
Да, если он за 6 дней надизайнил 50 уровней, это конечно респект.
В общем моя основаня придирка к поставленному свету.
Во-первых, "честный" космический свет не работает. Он смотрится паршиво, с резким перепадом в темноту.
Во-вторых, он не озаботился частицами. Пули хоть и яркие, не производят свет, двигатели аналогично. Не пульсируют, не оставляют шлейфов. Взрывы не освещают. И вообще, кажется, тупо 2д круги.
Однообразные астероиды без вариативности, обломки тоже однообразные. Обломки можно было кстати и не в 2д плоскости раскидывать, а "в глубину" тоже.
Космолет выглядит серым, безжизненным.
При этом, он таки знает какие приемы использовать. Он применяет easing к барьеру, который пружинит после столкновения. Он анимирует слои заставки. Просто он не применил этот juice ко всем элементам игры.
Я ошибочно прочитал за одну неделю как за один месяц, my bad.
Да, если он за 6 дней надизайнил 50 уровней, это конечно респект.
В общем моя основаня придирка к поставленному свету.
Во-первых, "честный" космический свет не работает. Он смотрится паршиво, с резким перепадом в темноту.
Во-вторых, он не озаботился частицами. Пули хоть и яркие, не производят свет, двигатели аналогично. Не пульсируют, не оставляют шлейфов. Взрывы не освещают. И вообще, кажется, тупо 2д круги.
Однообразные астероиды без вариативности, обломки тоже однообразные. Обломки можно было кстати и не в 2д плоскости раскидывать, а "в глубину" тоже.
Космолет выглядит серым, безжизненным.
При этом, он таки знает какие приемы использовать. Он применяет easing к барьеру, который пружинит после столкновения. Он анимирует слои заставки. Просто он не применил этот juice ко всем элементам игры.
Пагни, я с тачскрином в выборе между двумя стульями. На одном TextureButton, который не работает с тачем, если не включить эмуляцию мыши (а включать её я не хочу, так как это создаст новые проблемы с управлением). На другом TouchScreenButton, который вообще не наследник контрола, следовательно имеет кучу проблем с масштабированием. Шоделоть? Кагбыдь?
>>711352
Может быть все же работает? Просто не будет pressed и hover? Надо потестить
>TextureButton, который не работает с тачем
Может быть все же работает? Просто не будет pressed и hover? Надо потестить
>>711354
Хз, я разные варианты пробовал. В лучшем случае просто крутит часики. Не нашёл ни одного сигналау текстурбаттона, который бы отзывался на прикосновение.
Вообще, у я разрабатываю на ноуте с тачскрином и убунтой. Но сомневаюсь, что тут порылась какая-нибудь собака, так как TouchScreenButton и всякие тачевые инпуты работают без нареканий. Годот, няп, хандлит ввод напрямую, ему наплевать на установленные в системе прослойки для тача.
Хз, я разные варианты пробовал. В лучшем случае просто крутит часики. Не нашёл ни одного сигналау текстурбаттона, который бы отзывался на прикосновение.
Вообще, у я разрабатываю на ноуте с тачскрином и убунтой. Но сомневаюсь, что тут порылась какая-нибудь собака, так как TouchScreenButton и всякие тачевые инпуты работают без нареканий. Годот, няп, хандлит ввод напрямую, ему наплевать на установленные в системе прослойки для тача.
>>711369
Спс, попробую. Не рассматривал ничего, что не относится к BaseButton.
Спс, попробую. Не рассматривал ничего, что не относится к BaseButton.
>>711369
Попробовал. Работает. Но возникла проблема с тем, что FileDialog не умеет в тач. Сцуко. А я хотел сделать сохранение/загрузку.
Но вообще, тот факт, что интерфейсные ноды не дружат с тачем, создаёт огромные проблемы. Эмуляция нажатия мыши - ужасный костыль так-то. Как в такой ситуации определить отдельно перетаскивание левой кнопкой и СкринДраг? Ну, то есть, понятно, что можно, но кривизна прям буэээ.
Попробовал. Работает. Но возникла проблема с тем, что FileDialog не умеет в тач. Сцуко. А я хотел сделать сохранение/загрузку.
Но вообще, тот факт, что интерфейсные ноды не дружат с тачем, создаёт огромные проблемы. Эмуляция нажатия мыши - ужасный костыль так-то. Как в такой ситуации определить отдельно перетаскивание левой кнопкой и СкринДраг? Ну, то есть, понятно, что можно, но кривизна прям буэээ.
>>711384
М-да. Попытался накостылить, чтобы при вводе с тача события мыши не обрабатывались бы как мышь. Хер там плавал.
Проблема в том, что при включённом режиме эмуляции мыши всё равно сначала отправляется клик, а потом касание (при том, что реально это просто касание). И я не вижу способа в момент клика понять, последует ли за ним касание. Был вариант просто спросить систему, а есть ли у неё сенсорный экран, но вот у моего ноута и тачскрин, и мышь. Попробовал запоминать ввод, а потом реагировать на него в _physics_process; помогло, но вместо этого теперь я не могу распознать касание без перетаскивания.
В общем, что я пытаюсь запилить:
1. Щелчок мышью - заполнить клетку на тайлмапе
2. Перетаскивание мышью - заполнить все клетки на тайлмапе, через которые прошла мышь
3. Короткое касание - заполнить клетку на тайлмапе
4. СкринДраг - переместить камеру
5. Щелчок мышью ИЛИ короткое касание по кнопке интерфейса - нажатие кнопки интерфейса
Вроде бы наборчик вполне стандартный, ничего уникального. Но постоянно один-два пункта не получается приклеить, когда все остальные исправно работают. Есть какие-то готовые решения? Может, внятный видос по теме?
М-да. Попытался накостылить, чтобы при вводе с тача события мыши не обрабатывались бы как мышь. Хер там плавал.
Проблема в том, что при включённом режиме эмуляции мыши всё равно сначала отправляется клик, а потом касание (при том, что реально это просто касание). И я не вижу способа в момент клика понять, последует ли за ним касание. Был вариант просто спросить систему, а есть ли у неё сенсорный экран, но вот у моего ноута и тачскрин, и мышь. Попробовал запоминать ввод, а потом реагировать на него в _physics_process; помогло, но вместо этого теперь я не могу распознать касание без перетаскивания.
В общем, что я пытаюсь запилить:
1. Щелчок мышью - заполнить клетку на тайлмапе
2. Перетаскивание мышью - заполнить все клетки на тайлмапе, через которые прошла мышь
3. Короткое касание - заполнить клетку на тайлмапе
4. СкринДраг - переместить камеру
5. Щелчок мышью ИЛИ короткое касание по кнопке интерфейса - нажатие кнопки интерфейса
Вроде бы наборчик вполне стандартный, ничего уникального. Но постоянно один-два пункта не получается приклеить, когда все остальные исправно работают. Есть какие-то готовые решения? Может, внятный видос по теме?
>>711393
Я бы делал обработку тача и мыши в отдельных методах. Подробно тому, как игры работают с геймпадом: прошёл инпут с геймпада -> стейтмашина инпута перешла в режим геймпада, прошел инпут с клавы или мыши -> режим клавомышь.
В соответствующем режиме вызывается только соответствующий обработчик.
Я бы делал обработку тача и мыши в отдельных методах. Подробно тому, как игры работают с геймпадом: прошёл инпут с геймпада -> стейтмашина инпута перешла в режим геймпада, прошел инпут с клавы или мыши -> режим клавомышь.
В соответствующем режиме вызывается только соответствующий обработчик.
>>710906
ЕЦС придуман может и для обхода ограничений плойки (в чём я сомневаюсь, так как не видел никакой информации про это), но так как он эксплуатирует особенности работы кеша и процессоров в принципе, то он применим не только лишь на Cell, но и на x86 и на ARM и дает хороший прирост где угодно.
>>710920
Очевидно нет, так по нормальному он нарушает принцип инкапсуляции и очень редко следует наследованию и полиморфизму. Также ЕЦС прекрасно имплементируется в языках без поддержки ООП вроде раста и даже на чистейшем ФП.
Или функция-редьюсер.
Или структуры, содержащие лишь данные, которыми оперирует система-редьюсер.
Или кортежи компонентов. Или опять таки структуры, содержащие лишь данные.
То что за 40 лет от ООП никто не умер не значит, что это что-то хорошее и нам не нужно искать более удобные альтернативы. За всю свою жизнь я никогда не видел удобночитаемого ООП кода, в какие бы сорцы я не залезал. Весь мир сейчас движется в сторону отделения данных от кода и лишь история рассудит, что лучше.
Это правда, но если вдруг ботлнеком станет архитектура, то придётся переписывать абсолютно всё. Лично для меня ЕЦС удобнее для организации кода, повышенная производительность это скорее побочный эффект.
мимо программист не из геймдева
ЕЦС придуман может и для обхода ограничений плойки (в чём я сомневаюсь, так как не видел никакой информации про это), но так как он эксплуатирует особенности работы кеша и процессоров в принципе, то он применим не только лишь на Cell, но и на x86 и на ARM и дает хороший прирост где угодно.
>>710920
>ЕЦС - это паттерн ООП
Очевидно нет, так по нормальному он нарушает принцип инкапсуляции и очень редко следует наследованию и полиморфизму. Также ЕЦС прекрасно имплементируется в языках без поддержки ООП вроде раста и даже на чистейшем ФП.
>системы - есть классы
Или функция-редьюсер.
>компоненты - классы
Или структуры, содержащие лишь данные, которыми оперирует система-редьюсер.
>сущности - классы
Или кортежи компонентов. Или опять таки структуры, содержащие лишь данные.
>ЕЦС в остальных случаях - подростковый нигилизм по типу "МАМ, НЕ ХОЧУ ЗАМШЕЛЫЙ ООП, ХОЧУ ЧТО-ТО МОЛОДЁЖНОЕ"
То что за 40 лет от ООП никто не умер не значит, что это что-то хорошее и нам не нужно искать более удобные альтернативы. За всю свою жизнь я никогда не видел удобночитаемого ООП кода, в какие бы сорцы я не залезал. Весь мир сейчас движется в сторону отделения данных от кода и лишь история рассудит, что лучше.
>Как по мне - важнее качественный арт и эффекты. А ещё важнее - интересный геймплей. А выигрывать кадр на синтетическом тесте, когда ещё игоря тонет - это ящитаю преждевременная оптимизация во всей красе.
Это правда, но если вдруг ботлнеком станет архитектура, то придётся переписывать абсолютно всё. Лично для меня ЕЦС удобнее для организации кода, повышенная производительность это скорее побочный эффект.
мимо программист не из геймдева
>>711393
Разве это не противоречит друг другу?
> Перетаскивание мышью - заполнить все клетки на тайлмапе,
> СкринДраг - переместить камеру
Разве это не противоречит друг другу?
>>711393
В общем, я бы на твоем месте делал так:
-либо drag работает в зависимости от того, куда кликнул. Если кликнул по рабочим тайлам - то рисуешь, если по пустому месту - двигаешь карту. Это вообще говоря много где используется.
-либо таскание работает только двумя пальцами. Это же вроде сейчас стандарт уже? обычно в связке с зумом, и иногда поворотом. Но тогда надо решить как таскать одной мышкой, возможно правой кнопкой.
В общем, я бы на твоем месте делал так:
-либо drag работает в зависимости от того, куда кликнул. Если кликнул по рабочим тайлам - то рисуешь, если по пустому месту - двигаешь карту. Это вообще говоря много где используется.
-либо таскание работает только двумя пальцами. Это же вроде сейчас стандарт уже? обычно в связке с зумом, и иногда поворотом. Но тогда надо решить как таскать одной мышкой, возможно правой кнопкой.
>>711414
В режиме эмуляции мыши - противоречит. В режиме здорового человека это выполняется разными устройствами и потому не возникает противоречий.
Вообще, если ивент _gui_input() прописывать интерфейсным кнопкам реакцию на ИнпутИвентСкринТач, то можно обойтись без режима эмуляции. Но возникает проблема с диалоговыми окнами (в частности, FileDialog), которые уже на тач не отзываются от слова никак.
>>711418
Не работает, если я делаю инструмент рисования, рисующий тайлы там, где пока ещё пусто.
Вынос костыля на обозрение игроку. Не могу навскидку вспомнить ни одного мобильного приложения, внутри которого навигация осуществлялась бы двумя пальцами. И не мобильного тоже, если оно нативно поддерживает тач.
Прямо сейчас я пишу этот пост в гуглхроме, мышью таскаю по текстовому полю - выделяется текст; пальцем вожу по экрану, вне зависимости от места на странице, - двигается страница; тыкаю пальцем или мышкой в ссылку или кнопку - она срабатывает. Это абсолютный стандарт де-факто с самого появления управления пальцами.
Правой, средней - это вообще не представляет сложности. Прямо сейчас у меня это выполняется средней кнопкой. Пожалуй, правую тоже добавлю, она всё равно не задействована.
На крайний случай можно вернуть эмуляцию мыши и отказаться от навигации тачем при включённом рисовании. Но ведь предполагается, что это основной игровой режим. ИЛИ убрать возможность рисовать тасканием, а для установки тайла требовать полного цикла "нажал-отпустил".
>>711399
А как ты обошёл проблему диалоговых окон, типа FileDialog? Просто не использовал их?
>Разве это не противоречит друг другу?
В режиме эмуляции мыши - противоречит. В режиме здорового человека это выполняется разными устройствами и потому не возникает противоречий.
Вообще, если ивент _gui_input() прописывать интерфейсным кнопкам реакцию на ИнпутИвентСкринТач, то можно обойтись без режима эмуляции. Но возникает проблема с диалоговыми окнами (в частности, FileDialog), которые уже на тач не отзываются от слова никак.
>>711418
>либо drag работает в зависимости от того, куда кликнул
Не работает, если я делаю инструмент рисования, рисующий тайлы там, где пока ещё пусто.
>либо таскание работает только двумя пальцами
Вынос костыля на обозрение игроку. Не могу навскидку вспомнить ни одного мобильного приложения, внутри которого навигация осуществлялась бы двумя пальцами. И не мобильного тоже, если оно нативно поддерживает тач.
Прямо сейчас я пишу этот пост в гуглхроме, мышью таскаю по текстовому полю - выделяется текст; пальцем вожу по экрану, вне зависимости от места на странице, - двигается страница; тыкаю пальцем или мышкой в ссылку или кнопку - она срабатывает. Это абсолютный стандарт де-факто с самого появления управления пальцами.
>Но тогда надо решить как таскать одной мышкой, возможно правой кнопкой.
Правой, средней - это вообще не представляет сложности. Прямо сейчас у меня это выполняется средней кнопкой. Пожалуй, правую тоже добавлю, она всё равно не задействована.
На крайний случай можно вернуть эмуляцию мыши и отказаться от навигации тачем при включённом рисовании. Но ведь предполагается, что это основной игровой режим. ИЛИ убрать возможность рисовать тасканием, а для установки тайла требовать полного цикла "нажал-отпустил".
>>711399
А как ты обошёл проблему диалоговых окон, типа FileDialog? Просто не использовал их?
>>711435
Я вижу ситуацию немного по другому - у 99% обычных людей или комп с мышкой без тача, или смартфон/планшет с тачем без мышки.
Поэтому в твоем дизайне управления половина не получает одну четверть функционала, а другая половина - другую четверть.
Ну если ты делаешь только для себя, то это другая история.
Я вижу ситуацию немного по другому - у 99% обычных людей или комп с мышкой без тача, или смартфон/планшет с тачем без мышки.
Поэтому в твоем дизайне управления половина не получает одну четверть функционала, а другая половина - другую четверть.
Ну если ты делаешь только для себя, то это другая история.
>>711435
Именно так. Комповские диалоговые окна сами по себе неудобны на тач-устройствах. Там надо "диалоговые панели" однопанельного режима. Вместо тонкой строки с выбранным файлом - толстая строчища с огромными буквищами. Чтобы толстые пальцы жырных американцев попадали в неё. Большие кнопки. Список файлов не в диалоге, а вызывается отдельно поверх, модально. И тоже с жырными строками.
> А как ты обошёл проблему диалоговых окон, типа FileDialog? Просто не использовал их?
Именно так. Комповские диалоговые окна сами по себе неудобны на тач-устройствах. Там надо "диалоговые панели" однопанельного режима. Вместо тонкой строки с выбранным файлом - толстая строчища с огромными буквищами. Чтобы толстые пальцы жырных американцев попадали в неё. Большие кнопки. Список файлов не в диалоге, а вызывается отдельно поверх, модально. И тоже с жырными строками.
>>711458
В связи с вышесказанным я предлагаю ОДИН РАЗ написать себе велосипедистый тач-диалог на тач-нодах и юзать его в проектах. Сам проект при запуске знает в каокй он системе, какие у него в наличии имеются методы ввода. Сообразно этим данным проект может переключать интерфейс с того на этот и обратно.
В связи с вышесказанным я предлагаю ОДИН РАЗ написать себе велосипедистый тач-диалог на тач-нодах и юзать его в проектах. Сам проект при запуске знает в каокй он системе, какие у него в наличии имеются методы ввода. Сообразно этим данным проект может переключать интерфейс с того на этот и обратно.
>>711460
Слоты везде ящитаю надо делать. Большинству игроков нахуй не всралось управлять файлами из игры, отвлекаясь от ПОГРУЖЕНИЯ. Кому надо - те самостоятельно папку с сейвами забэкапят.
Слоты везде ящитаю надо делать. Большинству игроков нахуй не всралось управлять файлами из игры, отвлекаясь от ПОГРУЖЕНИЯ. Кому надо - те самостоятельно папку с сейвами забэкапят.
Всё гениальное - просто: https://www.youtube.com/watch?v=Ip5SlTlF2iQ
Как я сам до этого не додумался? (А всё потому, что ещё не начал мыслить стейтмашинами. Всё есть стейтмашины!)
Как я сам до этого не додумался? (А всё потому, что ещё не начал мыслить стейтмашинами. Всё есть стейтмашины!)
>>711466
Потому что честная гравитация в 9,5 метров в секунду не подходит для аркадности большинства игор. Ты когда в какую-нибудь кваку играешь, там гравитация вообще всё 100 жэ.
Потому что честная гравитация в 9,5 метров в секунду не подходит для аркадности большинства игор. Ты когда в какую-нибудь кваку играешь, там гравитация вообще всё 100 жэ.
>>711437
Не понимаю тебя. У меня выбор: сесть на стул эмуляции мыши и лишить пользователей компьютера непрерывного рисования или посадить мать на стул раздельного тача и лишить мобильных игроков нормальной навигации. А благодаря тому, что у меня ноут с тачем, я своими руками ощущаю обе эти проблемы.
Не понимаю тебя. У меня выбор: сесть на стул эмуляции мыши и лишить пользователей компьютера непрерывного рисования или посадить мать на стул раздельного тача и лишить мобильных игроков нормальной навигации. А благодаря тому, что у меня ноут с тачем, я своими руками ощущаю обе эти проблемы.
>>711475
Так ощущения от игр надо регулировать массой объекта и силой прыжка, гравитация то тут причем? Ну диды косячили, а сейчас зачем?
з.ы. чекнул кваку 3, там написано sv_gravity 800, НО в коде есть умножение на 0.5. Высота персонажа 64 юнита, возьмем средний рост 180см, 1 юнит ~= 2.8125см, ускорение 400 х 0,028125м = 11,25м/c2. Что довольно близко к земному. В халве гравитация 600, то есть 8,4375м/с2
Так ощущения от игр надо регулировать массой объекта и силой прыжка, гравитация то тут причем? Ну диды косячили, а сейчас зачем?
з.ы. чекнул кваку 3, там написано sv_gravity 800, НО в коде есть умножение на 0.5. Высота персонажа 64 юнита, возьмем средний рост 180см, 1 юнит ~= 2.8125см, ускорение 400 х 0,028125м = 11,25м/c2. Что довольно близко к земному. В халве гравитация 600, то есть 8,4375м/с2
>>711479
Есть клик, который приводит к драгу.
Это может быть только одно действие в приложении.
В тач версии ты хочешь прокрутку экрана.
В ПК версии ты хочешь закрашивание тайлов.
У тебя устройство где есть два разных клика.
У твоих пользователей где будет только один вариант клика.
Да, тебе нужно определиться что именно будет делать драг - или то, или другое.
>Не понимаю тебя.
Есть клик, который приводит к драгу.
Это может быть только одно действие в приложении.
В тач версии ты хочешь прокрутку экрана.
В ПК версии ты хочешь закрашивание тайлов.
У тебя устройство где есть два разных клика.
У твоих пользователей где будет только один вариант клика.
Да, тебе нужно определиться что именно будет делать драг - или то, или другое.
>>711484
Я сам не понимаю, причём. Все туториалы говорят, что надо настраивать ощущения гравитацией. Зделой свой туториал - с удовольствием изучу.
> гравитация то тут причем?
Я сам не понимаю, причём. Все туториалы говорят, что надо настраивать ощущения гравитацией. Зделой свой туториал - с удовольствием изучу.
>>711484
Физику прогуливал? Ускорение свободного падения не зависит от массы.
Есть несколько простых объяснений, почему G в играх отличается от земного.
1. Масштаб. Если персонаж ростом с человека, то всё ок, но все размеры во всей игре могут отличаться от настоящих. Потому что метрами в играх бывает неудобно пользоваться. Или потому что разрешение текстур не позволяет. Особенно актуально для двадэ.
2. Высота прыжка. Бывает так, что надо наделить персонажа более высоким (относительно его роста) прыжком. Но в таком случае он при нормальной гравитации будет прыгать слишком долго. Увеличиваем силу прыжка, увеличиваем гравитацию - готово, теперь прыжок высокий и быстрый.
3. Скорость перемещения. Прыжок должен восприниматься адекватно ей. Иначе у игрока будет ощущение, что он на Луне. А скорость перемещения обычно увеличивают в сравнении с реальным миром, чтобы не так нудно было.
4. Общая динамика. В общем случае прыжок на экране обычно ощущается вовсе не так же, как прыжок в реальности, если просто задать персонажу все характеристики, соответствующие реальному миру. Поэтому все физические параметры так, чтобы получить задуманный гейм-дизайнером геймплейный экспириенс. Или делают на отъебись, просто хоть как-то.
>массой объекта и силой прыжка, гравитация то тут причем?
Физику прогуливал? Ускорение свободного падения не зависит от массы.
Есть несколько простых объяснений, почему G в играх отличается от земного.
1. Масштаб. Если персонаж ростом с человека, то всё ок, но все размеры во всей игре могут отличаться от настоящих. Потому что метрами в играх бывает неудобно пользоваться. Или потому что разрешение текстур не позволяет. Особенно актуально для двадэ.
2. Высота прыжка. Бывает так, что надо наделить персонажа более высоким (относительно его роста) прыжком. Но в таком случае он при нормальной гравитации будет прыгать слишком долго. Увеличиваем силу прыжка, увеличиваем гравитацию - готово, теперь прыжок высокий и быстрый.
3. Скорость перемещения. Прыжок должен восприниматься адекватно ей. Иначе у игрока будет ощущение, что он на Луне. А скорость перемещения обычно увеличивают в сравнении с реальным миром, чтобы не так нудно было.
4. Общая динамика. В общем случае прыжок на экране обычно ощущается вовсе не так же, как прыжок в реальности, если просто задать персонажу все характеристики, соответствующие реальному миру. Поэтому все физические параметры так, чтобы получить задуманный гейм-дизайнером геймплейный экспириенс. Или делают на отъебись, просто хоть как-то.
>>711490
Я только что привел пример квейка и халвы где гравитация примерно земная, с ощущениями все в порядке.
Дальше, у тебя что у каждого существа своя гравитация будет что ли? Потому что если у тебя одна на всех, то увеличив персонажу, ты поменяешь и всем монстрам.
Я только что привел пример квейка и халвы где гравитация примерно земная, с ощущениями все в порядке.
Дальше, у тебя что у каждого существа своя гравитация будет что ли? Потому что если у тебя одна на всех, то увеличив персонажу, ты поменяешь и всем монстрам.
>>711491
И что нам до ощущений тех монстров? И, кстати, они могут и не обращаться к физическому серверу, а иметь своё ускорение падения.
В твоих примерах гравитация ощутимо отличается от земной. Что таки говорит, что её настраивали в угоду геймплею.
И что нам до ощущений тех монстров? И, кстати, они могут и не обращаться к физическому серверу, а иметь своё ускорение падения.
В твоих примерах гравитация ощутимо отличается от земной. Что таки говорит, что её настраивали в угоду геймплею.
>>711494
Чо совсем тупой, если не понимаешь, что мы джва часа обсуждаем константу в скрипте персонажа? Ёбом токнуть?
Чо совсем тупой, если не понимаешь, что мы джва часа обсуждаем константу в скрипте персонажа? Ёбом токнуть?
>>711497
Ты первую половину предложения не прочитал что ли? ТЫ ПРЕДЛАГАЕШЬ В КАЖДОМ СКРИПТЕ КАЖДОГО МОБА СВОЮ ГРАВИТАЦИЮ ПИСАТЬ?
Ты первую половину предложения не прочитал что ли? ТЫ ПРЕДЛАГАЕШЬ В КАЖДОМ СКРИПТЕ КАЖДОГО МОБА СВОЮ ГРАВИТАЦИЮ ПИСАТЬ?
>>711504
Пчел, ты... Гравитация - это свойство ПЛАНЕТЫ к которой они притягиваются.
>Гравитация
>у моба
>своя
Пчел, ты... Гравитация - это свойство ПЛАНЕТЫ к которой они притягиваются.
>>711499
Не вижу в этом ничего такого. Один моб у тебя прыгает, другой летает, третий ползает, четвёртый плавает. Зачем им всем одинаковое ускорение свободного падения? Зачем этому параметру совпадать с таковым для игрока и/или физического движка?
Не вижу в этом ничего такого. Один моб у тебя прыгает, другой летает, третий ползает, четвёртый плавает. Зачем им всем одинаковое ускорение свободного падения? Зачем этому параметру совпадать с таковым для игрока и/или физического движка?
>>711505
Нет ты. Пролетай уже своей дорогой. Пчевелопер, блять.
Алсо, годаны, мне тут на ютубе снова советуют перекатываться на шарп с гдскрипта. Как считаете? Стоит? Полюбил я уже гдскрипт за эти джва года, но сука, и медленный же он.
> Пчел, ты.
Нет ты. Пролетай уже своей дорогой. Пчевелопер, блять.
Алсо, годаны, мне тут на ютубе снова советуют перекатываться на шарп с гдскрипта. Как считаете? Стоит? Полюбил я уже гдскрипт за эти джва года, но сука, и медленный же он.
>>711508
Вот мои аргументы, а ты смотри сам:
1. На гдскрипте ты можешь писать только в годоте, а сишарп много где используется.
2. С версии 4.0 мы получим уже какой-то совсем другой гдскрипт. Его очень сильно перепиливают, придётся ко многому заново привыкать. Сравнимо с освоением нового языка.
Вооот.
Вот мои аргументы, а ты смотри сам:
1. На гдскрипте ты можешь писать только в годоте, а сишарп много где используется.
2. С версии 4.0 мы получим уже какой-то совсем другой гдскрипт. Его очень сильно перепиливают, придётся ко многому заново привыкать. Сравнимо с освоением нового языка.
Вооот.
>>711509
И кстати, в той же ветке комментов обещают устранение ботлнека. Но... Сишарп-то, он уже здесь и сейчас. А будет ли реальное устранение ботлнека в будущем?
Впрочем, надо без фанатизма. Простенькие скрипты в пару строк, из которых обе строки - дефайны переменных для редактора - вполне ок делать на гдскрипте. А вот игровую логику, со всякими сложными вычислениями октодеревьев поведения, это всё таки надо на шарпе. А лучше сразу конпелять модули на си. Но в настоящий си я пока ещё не могу. Увы.
> какой-то совсем другой гдскрипт
И кстати, в той же ветке комментов обещают устранение ботлнека. Но... Сишарп-то, он уже здесь и сейчас. А будет ли реальное устранение ботлнека в будущем?
Впрочем, надо без фанатизма. Простенькие скрипты в пару строк, из которых обе строки - дефайны переменных для редактора - вполне ок делать на гдскрипте. А вот игровую логику, со всякими сложными вычислениями октодеревьев поведения, это всё таки надо на шарпе. А лучше сразу конпелять модули на си. Но в настоящий си я пока ещё не могу. Увы.
>>711511
А ещё в сишарп-солшене, как я заметил, можно прокидывать ссылки из проекта в проект, и следовательно, можно прикрутить к игровой сборке внешний экзешник. Возможностей море: Конфигуратор? Да! Сервер? Да! Интеграция с СУБД? Да! Драйвер защиты? Да! И это только навскидку.
> Сишарп-то, он уже здесь и сейчас
А ещё в сишарп-солшене, как я заметил, можно прокидывать ссылки из проекта в проект, и следовательно, можно прикрутить к игровой сборке внешний экзешник. Возможностей море: Конфигуратор? Да! Сервер? Да! Интеграция с СУБД? Да! Драйвер защиты? Да! И это только навскидку.
>>711506
Я думаю что ты споришь просто ради того чтобы спорить, и зачем то защищаешь плохой подход.
Например у Area и Area2D есть свойство gravity, по умолчанию равное 9.8. То есть ты можешь его изменять, создавая области с другой гравитацией. А у тебя уже везде своя вписана, то 20, то 25.
>>711490
Перечитал с утра свой пост. Там сказано что ощущения от игры должны зависеть от массы. Так что все верно. Масса влияет на действующую на объект силу. Я не предлагал менять массой ускорение свободного падения.
Я думаю что ты споришь просто ради того чтобы спорить, и зачем то защищаешь плохой подход.
Например у Area и Area2D есть свойство gravity, по умолчанию равное 9.8. То есть ты можешь его изменять, создавая области с другой гравитацией. А у тебя уже везде своя вписана, то 20, то 25.
>>711490
>Физику прогуливал? Ускорение свободного падения не зависит от массы.
Перечитал с утра свой пост. Там сказано что ощущения от игры должны зависеть от массы. Так что все верно. Масса влияет на действующую на объект силу. Я не предлагал менять массой ускорение свободного падения.
>>711556
И БАЦ
Пчел, ты...
Во всех примерах выше, к которым ты (или кто там) доебался до гравитации, используется, блять, KINEMATICBODY, у которого главная фишка в упрощенном взаимодействии с физическим сервером. Всю кинематику разраб должен реализовать сам: движение, ускорение и т.п.
Классика геймдева, блять, это знать надо!
Хочешь делать контроллер персонажа на RigidBody? С достоверными физическими параметрами? Как тебе уже указали выше, готовься к скучному и медленному геймплею. Окажется, что персонаж не носится по карте, как паровоз, при это мне разгоняется мгновенно, не тормозит мгновенно. А медленно ходит!! Оказывается, персонаж не может прыгнуть выше, чем на 20 см! Ни о каких прыжках через бочки и заборы речи быть не может.
> Я думаю что ты споришь просто ради того чтобы спорить, и зачем то защищаешь плохой подход.
И БАЦ
> Например у Area и Area2D есть свойство gravity, по умолчанию равное 9.8
Пчел, ты...
Во всех примерах выше, к которым ты (или кто там) доебался до гравитации, используется, блять, KINEMATICBODY, у которого главная фишка в упрощенном взаимодействии с физическим сервером. Всю кинематику разраб должен реализовать сам: движение, ускорение и т.п.
Классика геймдева, блять, это знать надо!
Хочешь делать контроллер персонажа на RigidBody? С достоверными физическими параметрами? Как тебе уже указали выше, готовься к скучному и медленному геймплею. Окажется, что персонаж не носится по карте, как паровоз, при это мне разгоняется мгновенно, не тормозит мгновенно. А медленно ходит!! Оказывается, персонаж не может прыгнуть выше, чем на 20 см! Ни о каких прыжках через бочки и заборы речи быть не может.
>>711576
Пчел, ты... Где ты увидел хоть слово про RigidBody? Почему ты не можешь для KinematicBody подхватывать значение гравитации из того в какой зоне находишься?
За это отвечает jump_force, а не гравитация, даже в самых парашных туторах.
Пчел, ты... Где ты увидел хоть слово про RigidBody? Почему ты не можешь для KinematicBody подхватывать значение гравитации из того в какой зоне находишься?
> Оказывается, персонаж не может прыгнуть выше, чем на 20 см!
За это отвечает jump_force, а не гравитация, даже в самых парашных туторах.
Предлагаю лучше вот что обсудить. Как правильно делать лифты? Меня интересует, чтобы персонажи не падали следом за лифтом, если лифт движется быстро: как знаете, в старых игорах, когда садишься в лифт и чувствуешь заметное неприятное дрожание вверх-вниз из-за того, что лифт уезжает из под ног персонажа, персонаж переходит в режим падения, потом моментально касается пола и переходит обратно в режим стояния, но лифт продолжает уходить вниз. И так с частотой 60 герц нахуй. А если подпрыгнуть - получишь дамаг от падения! Неприемлемо! Как грамотно реализовать правильную кинематику с накладными силами и относительными системами отсчёта?
Я щас капчую с калькулятора, поэтому не могу проверить, решает ли проблему прикрученная к лифту Area с параметром Replace? По идее этот параметр для этого и нужен, чтобы персонажа тянуло за платформой?
Я щас капчую с калькулятора, поэтому не могу проверить, решает ли проблему прикрученная к лифту Area с параметром Replace? По идее этот параметр для этого и нужен, чтобы персонажа тянуло за платформой?
>>711556
Возможно, ты не заметил, но я тут не один с тобой спорю. Как минимум ещё один анон на стороне раздельных гравитаций. И в моём посте вообще нет ни слова про массу.
Кстати, вспоминай: за что отвечает масса в реальном мире? Помнишь, как на БАКе искали бозон Хиггса? А зачем он нужен? А он нужен для инерции. Масса отвечает за инерцию, и это ныне считается одним из фундаментальных взаимодействий.
Так вот. Если у тебя есть массивный объект, который движется по всем законам физики, он будет, как верно заметил анон выше, жутко инертный. Он, в отличие от живого персонажа, не сможет а) сохранять вертикальное положение тела, б) резко тормозить, перемещая центр тяжести.
Но это всё ладно. Мы же тут о прыжках говорим. И вот, в этом-то процессе масса влияет на высоту прыжка, но не влияет на скорость. Потому что Velocity.y += G * delta, массы в этой формуле нет. Как видно из формулы, для регулировки скорости прыжка единственная доступная переменная это гравитационная постоянная.
>>711576
Кстати, а я делал. Только это был вертолёт. Для вертолёта такой подход очень даже гуд. Хотя, конечно, управлять им оказалось довольно сложно. Но весело, особенно когда сначала побегаешь по уровням как человек-кинематик, а потом садишься за штурвал тяжёлой неповоротливой машины, вооружённой бесконечным пулемётом и ракетами.
>>711609
Тут было бы что обсудить, но у геймэндевора эта тема полностью раскрыта. Вопросы могут быть только с конкретной реализацией.
>Перечитал с утра свой пост.
Возможно, ты не заметил, но я тут не один с тобой спорю. Как минимум ещё один анон на стороне раздельных гравитаций. И в моём посте вообще нет ни слова про массу.
Кстати, вспоминай: за что отвечает масса в реальном мире? Помнишь, как на БАКе искали бозон Хиггса? А зачем он нужен? А он нужен для инерции. Масса отвечает за инерцию, и это ныне считается одним из фундаментальных взаимодействий.
Так вот. Если у тебя есть массивный объект, который движется по всем законам физики, он будет, как верно заметил анон выше, жутко инертный. Он, в отличие от живого персонажа, не сможет а) сохранять вертикальное положение тела, б) резко тормозить, перемещая центр тяжести.
Но это всё ладно. Мы же тут о прыжках говорим. И вот, в этом-то процессе масса влияет на высоту прыжка, но не влияет на скорость. Потому что Velocity.y += G * delta, массы в этой формуле нет. Как видно из формулы, для регулировки скорости прыжка единственная доступная переменная это гравитационная постоянная.
>>711576
>Хочешь делать контроллер персонажа на RigidBody?
Кстати, а я делал. Только это был вертолёт. Для вертолёта такой подход очень даже гуд. Хотя, конечно, управлять им оказалось довольно сложно. Но весело, особенно когда сначала побегаешь по уровням как человек-кинематик, а потом садишься за штурвал тяжёлой неповоротливой машины, вооружённой бесконечным пулемётом и ракетами.
>>711609
>лифты
Тут было бы что обсудить, но у геймэндевора эта тема полностью раскрыта. Вопросы могут быть только с конкретной реализацией.
>>711610
Падажжи! Но там же двадэ! Тридэ не внесёт несовместимых нюансов в эту полностью раскрытую тему?
> у геймэндевора эта тема полностью раскрыта
Падажжи! Но там же двадэ! Тридэ не внесёт несовместимых нюансов в эту полностью раскрытую тему?
>>711620
Но стоит тебе сдвинуться и ты РЕЗКО улетаешь в сторону.
Хорош изобретать велосипеды. Я уже просмотрел соответствубщий видос геймэндевора.
Но стоит тебе сдвинуться и ты РЕЗКО улетаешь в сторону.
Хорош изобретать велосипеды. Я уже просмотрел соответствубщий видос геймэндевора.
>>711610
У геймэндевора забавная дикция. И юморок такой, тролячий характерный. Смотрю щас. И он такой
От так прям нараспев и прожужжал, >_<, пчел...
У геймэндевора забавная дикция. И юморок такой, тролячий характерный. Смотрю щас. И он такой
> мы работали над проектом с pigdev, райаном флури и
> МЗЫЗЫ, ЗЫ-ЗЫ, ЗЫ-ЗЫЗОМ
От так прям нараспев и прожужжал, >_<, пчел...
>>711509
С сеттерами-геттерами прямо в инициализаторе, прямо как в шарпе. Первый шаг к лямбдам. А с лямбдами это будет просто топ-писечка, а не язык.
И с доведённой до ума типизацией методов.
> С версии 4.0 мы получим уже какой-то совсем другой гдскрипт
С сеттерами-геттерами прямо в инициализаторе, прямо как в шарпе. Первый шаг к лямбдам. А с лямбдами это будет просто топ-писечка, а не язык.
И с доведённой до ума типизацией методов.
Кто ниб может подсказать как в годо текст из файла подгружать на экран или ссылку на гайд дать?
>>711699
Обычные файловые операции
https://www.davidepesce.com/2019/11/04/essential-guide-to-godot-filesystem-api/
file.open("res://file.txt")
var str = file.get_line()
label.text = str
Если участвуют переводы, то путь будет посложнее.
Обычные файловые операции
https://www.davidepesce.com/2019/11/04/essential-guide-to-godot-filesystem-api/
file.open("res://file.txt")
var str = file.get_line()
label.text = str
Если участвуют переводы, то путь будет посложнее.
Чайник спрашивает.
Как сделать персонажу возможность "подниматься" по ступенькам? Ну или подниматься на небольшие выступы, не подпрыгивая, аки на трамплине.
Как сделать персонажу возможность "подниматься" по ступенькам? Ну или подниматься на небольшие выступы, не подпрыгивая, аки на трамплине.
>>711833
Самый простой способ - делать коллайдер наклонным, без всяких ступенек.
Более сложный - там делается рейкаст. Если на пальцах, то если "ботинок" уперся в ступеньку, но на уровне коленки нет препятствия, то ты делаешь небольшой подпрыг.
Самый простой способ - делать коллайдер наклонным, без всяких ступенек.
Более сложный - там делается рейкаст. Если на пальцах, то если "ботинок" уперся в ступеньку, но на уровне коленки нет препятствия, то ты делаешь небольшой подпрыг.
>>711837
Если подумать, то ты рейкастом сверху вниз даже сможешь узнать на какую именно высоту.
Если подумать, то ты рейкастом сверху вниз даже сможешь узнать на какую именно высоту.
20 Кб, 284x492>>711837
У меня тогда на платформе "лифта" ГГ или залезает, подпрыгивая, или не залезает. А вот за способы с рейкастом пасыбо, попробую.
З.Ы.: Изменил полигон ГГ в состоянии стояния обратно на коллижншейп - и её перестало коноёбить на быстро поднимающемся лифте. Две проблемы решены.
>делать коллайдер наклонным
У меня тогда на платформе "лифта" ГГ или залезает, подпрыгивая, или не залезает. А вот за способы с рейкастом пасыбо, попробую.
З.Ы.: Изменил полигон ГГ в состоянии стояния обратно на коллижншейп - и её перестало коноёбить на быстро поднимающемся лифте. Две проблемы решены.
>>711715
Для переводов нужно встроенную систему юзать. Она хороша!
> Если участвуют переводы, то путь будет посложнее.
Для переводов нужно встроенную систему юзать. Она хороша!
>>711750
Изумительно! Так держать, товарищи!
Изумительно! Так держать, товарищи!
>>711833
Гораздо круче завязать подъём по ступенькам на инверсную кинематику: у каждой кости ступней ног персонажа приаттачена нода с коллиженшейпом. При анимации ноги перемещаются. Если нога на что-то встала, персонаж перемещается относительно ноги так, что поднимается вверх на высоту ступеньки. Потом движение продолжается и другая нога становится на следующую ступеньку.
А рейкасты и подпрыгивания - это прошлый век. Век капсулей вместо полноценного кинематического тела.
Гораздо круче завязать подъём по ступенькам на инверсную кинематику: у каждой кости ступней ног персонажа приаттачена нода с коллиженшейпом. При анимации ноги перемещаются. Если нога на что-то встала, персонаж перемещается относительно ноги так, что поднимается вверх на высоту ступеньки. Потом движение продолжается и другая нога становится на следующую ступеньку.
А рейкасты и подпрыгивания - это прошлый век. Век капсулей вместо полноценного кинематического тела.
>>711929
Ну, это, конечно, интересно, но для моих навыков ЖДскрипта уровня "посмотрел три туториала, вырвал по куску кода и собрал гомункула" это непосильное дзюцу.
>у каждой кости ступней ног
Ну, это, конечно, интересно, но для моих навыков ЖДскрипта уровня "посмотрел три туториала, вырвал по куску кода и собрал гомункула" это непосильное дзюцу.
>>711943
Я тут в соседнем разделе скроллил глагне и там кароч написали, что программисты переоценены, потому что занимаются примитивными вещами, для которых большого ума не надо. Ну, типа кодинг - это настолько просто, что непонятно за что там всяким сеньорам-девелоперам плотют такие сотни космокредов?
Я хотел было возразить, но поразмыслив, не стал ввязываться.
Потому что программирование (для меня) это в основном однообразно и муторно. Кодогенерация лепит хуйню, которая меня не устраивает, приходится копипастить тысячи строк бойлерплейта ручками. Для того, чтобы в конце сложить 2 + 2 и разделить на 3 и помножить на дельту. А в нашем годоте кодогенерации и подавно нет. Да я только за эту муторность и требовал бы 100500баксовый оклад. А сложного для меня тут давно ничего нет. Аттач нод к костям скелета? Что тут может пойти не так?
> непосильное дзюцу
Я тут в соседнем разделе скроллил глагне и там кароч написали, что программисты переоценены, потому что занимаются примитивными вещами, для которых большого ума не надо. Ну, типа кодинг - это настолько просто, что непонятно за что там всяким сеньорам-девелоперам плотют такие сотни космокредов?
Я хотел было возразить, но поразмыслив, не стал ввязываться.
Потому что программирование (для меня) это в основном однообразно и муторно. Кодогенерация лепит хуйню, которая меня не устраивает, приходится копипастить тысячи строк бойлерплейта ручками. Для того, чтобы в конце сложить 2 + 2 и разделить на 3 и помножить на дельту. А в нашем годоте кодогенерации и подавно нет. Да я только за эту муторность и требовал бы 100500баксовый оклад. А сложного для меня тут давно ничего нет. Аттач нод к костям скелета? Что тут может пойти не так?
>>711929
Смотрю современные игры и там капсула, а ик ног только для красоты, часто проваливается.в ступеньки иди висит в воздухе. Видать сильно ненадежно, застрять может.
Смотрю современные игры и там капсула, а ик ног только для красоты, часто проваливается.в ступеньки иди висит в воздухе. Видать сильно ненадежно, застрять может.
>>711955
Ну смотри, шейпы на ногах не ВМЕСТО капсулы, а вместе с ней. Тут я немного приукрасил, признаю. В целом, удобное и универсальное перемещение (как это вижу я) реализовано, как две ноги с жопой. Персонаж постоянно сидит на жопе, а ногами передвигает жопу в нужном направлении. Сорян за лексику. Это не троллинг, просто так короче передать образную суть.
Ну смотри, шейпы на ногах не ВМЕСТО капсулы, а вместе с ней. Тут я немного приукрасил, признаю. В целом, удобное и универсальное перемещение (как это вижу я) реализовано, как две ноги с жопой. Персонаж постоянно сидит на жопе, а ногами передвигает жопу в нужном направлении. Сорян за лексику. Это не троллинг, просто так короче передать образную суть.
>>711958
Ах да, в случае со ступеньками, ноги работают как детекторы поверхностей, почти как рейкаст, но во первых, они завязаны на анимацию, у тебя всё равно будет анимация ходьбы, и всё равно инверсная кинематика будет, так почему бы не задействовать имеющуюся систему, чем лепить рейкаст? Во вторых, рейкаст во всех имеющихся примерах завязан на подпрыгивание персонажа, а вариант с капсулой и ногами похож на лебёдку. Нога на ступеньке плавно подтягивает остальное туловище наверх.
Я только что подумал, что идеально это реализовать приделав капсуле на джойнтах две палки. Завтра потестирую, если не лень будет. Две палки начинают вращаться, как водяные колёса у парохода, когда игрок нажимает клавишу или кнопку ВПЕРЕД. Палки прикручены джойнтами так, что они чуточку длиннее капсулы внизу таким образом они толкают капсулу мелкими шажками вперёд, и если впереди ступени, то одна из палок, попав на ступеньку, перекатит всю конструкцию дальше. При этом, если упрёшься в стену, длины палок не хватит, чтобы заползти вверх. Впрочем, если стена ячеистая. Хммм.... Надо потестить.
Ах да, в случае со ступеньками, ноги работают как детекторы поверхностей, почти как рейкаст, но во первых, они завязаны на анимацию, у тебя всё равно будет анимация ходьбы, и всё равно инверсная кинематика будет, так почему бы не задействовать имеющуюся систему, чем лепить рейкаст? Во вторых, рейкаст во всех имеющихся примерах завязан на подпрыгивание персонажа, а вариант с капсулой и ногами похож на лебёдку. Нога на ступеньке плавно подтягивает остальное туловище наверх.
Я только что подумал, что идеально это реализовать приделав капсуле на джойнтах две палки. Завтра потестирую, если не лень будет. Две палки начинают вращаться, как водяные колёса у парохода, когда игрок нажимает клавишу или кнопку ВПЕРЕД. Палки прикручены джойнтами так, что они чуточку длиннее капсулы внизу таким образом они толкают капсулу мелкими шажками вперёд, и если впереди ступени, то одна из палок, попав на ступеньку, перекатит всю конструкцию дальше. При этом, если упрёшься в стену, длины палок не хватит, чтобы заползти вверх. Впрочем, если стена ячеистая. Хммм.... Надо потестить.
>>711962
Можно при разных поворотах персонажа наклонять эти самые палки под разными углами.
Алсо, если получится, скинь результат. Ради науки
Можно при разных поворотах персонажа наклонять эти самые палки под разными углами.
Алсо, если получится, скинь результат. Ради науки
>>711966
В общем, это работает. Но надо подгонять параметры. И работает только на ригидах. То есть все туториалы по контроллеру на кинематиках сразу идут лесом.
И да, идея не моя, видел такую игру у китайцев. Там ещё надо себе ноги нарисовать, потом включается забег и твой куб должен обогнать куб соперника, бешенно вращая нарисованными тобой ногами.
В общем, это работает. Но надо подгонять параметры. И работает только на ригидах. То есть все туториалы по контроллеру на кинематиках сразу идут лесом.
И да, идея не моя, видел такую игру у китайцев. Там ещё надо себе ноги нарисовать, потом включается забег и твой куб должен обогнать куб соперника, бешенно вращая нарисованными тобой ногами.
Антон, в чём может быть причина? Тайлы в тайлмапе отрисовываются в виде чёрных квадратиков. Но только в веб-версии, запущенной с мобилы. Веб-версия на десктопе и полнокомпьютерные версии рисуются нормально.
Тайлсет обычный, атласом, без шейдеров. Поверх тоже никаких шейдеров не накладывается. Может, какую где компрессию текстур подкрутить? Погуглил, нашёл похожий симптом, но только платформонезависимый.
Тайлсет обычный, атласом, без шейдеров. Поверх тоже никаких шейдеров не накладывается. Может, какую где компрессию текстур подкрутить? Погуглил, нашёл похожий симптом, но только платформонезависимый.
>>712062
Помню читал про эту хуйню в каком то советском журнале типа техника молодежи, там еще предлагали такое кресло каталку для лестниц сделать.
Помню читал про эту хуйню в каком то советском журнале типа техника молодежи, там еще предлагали такое кресло каталку для лестниц сделать.
>>712078
Где то через год наверное
Где то через год наверное
Когда выйдет в годоте compute shader, чтобы я мог написать сверхбыстро работающий дварфортресс с миллионом юнитов?
>>712086
в 4 версии )
в 4 версии )
>>712086
Сто раз обсуждали, что такие вещи делаются на самописных узкоспециализированных движках. Впрочем, ты можешь скачать исходники годо, переписать часть модулей под свою задачу, дописать свои модули, выкинуть лишние. Собрать. Сделать игру.
Действительно. Тред движкописей тут недалеко.
С такими вопросами в движкосрач тред. Пропукайся там и как попустит - возвращайся. Или не возвращайся.
> сверхбыстро работающий дварфортресс с миллионом юнитов
Сто раз обсуждали, что такие вещи делаются на самописных узкоспециализированных движках. Впрочем, ты можешь скачать исходники годо, переписать часть модулей под свою задачу, дописать свои модули, выкинуть лишние. Собрать. Сделать игру.
> Зачем мне ковыряться в чужом движке, если я могу написать свой?
Действительно. Тред движкописей тут недалеко.
> Зачем мне ковыряться в чужом движке, если я могу взять %движокнейм%, в котором есть %фичанейм%?
С такими вопросами в движкосрач тред. Пропукайся там и как попустит - возвращайся. Или не возвращайся.
>>712086
Сомневаюсь что компьют шейдер поможет - вроде бы они помогают при распараллеливании, а у тебя будет зависимость гнумов от действий других, то есть последовательно.
Сомневаюсь что компьют шейдер поможет - вроде бы они помогают при распараллеливании, а у тебя будет зависимость гнумов от действий других, то есть последовательно.
>>712109
Те коллизии и физику считают на видюхе, а гнумов нельзя? Так то это как-то не честно. В общем, вполне в шейдер можно передать массив гнумов и их определенным способом двигать. Либо сделать кучу текстур, которые бы цветом кодировали переменные и состояния гнумов. В общем, вариаций моего доблоебства можно придумать много.
>>712095
Такие вещи делаются в Юнити, тк оно может ретурнить текстуру, которую поменял шейдер, чтобы снова пихнуть ее в шейдер. Это позволяет писать на шейдерах божественную физику, которая не требует почти никаких ресурсов. Это довольно неплохо. Как минимум для годота, спамящего дравколы на каждую букву.
Те коллизии и физику считают на видюхе, а гнумов нельзя? Так то это как-то не честно. В общем, вполне в шейдер можно передать массив гнумов и их определенным способом двигать. Либо сделать кучу текстур, которые бы цветом кодировали переменные и состояния гнумов. В общем, вариаций моего доблоебства можно придумать много.
>>712095
Такие вещи делаются в Юнити, тк оно может ретурнить текстуру, которую поменял шейдер, чтобы снова пихнуть ее в шейдер. Это позволяет писать на шейдерах божественную физику, которая не требует почти никаких ресурсов. Это довольно неплохо. Как минимум для годота, спамящего дравколы на каждую букву.
>>712112
Have a nice day.
Have a nice day.
>>712058
Ничего не поменялось.
>>712064
Изначально на нём и делал.
А ещё я тут заметил, что кисть, которой внутри игры рисуются тайлы, тоже отображается чёрным квадратом. А кисть это просто спрайт, берущий текстуру тайлмапа и обрезающий её необходимым образом. Может ли быть проблема в текстуре? Она довольно большая, 5120х1024.
>Дак прям в настройках экспорта и крути.
Ничего не поменялось.
>>712064
>GLES2 включил?
Изначально на нём и делал.
А ещё я тут заметил, что кисть, которой внутри игры рисуются тайлы, тоже отображается чёрным квадратом. А кисть это просто спрайт, берущий текстуру тайлмапа и обрезающий её необходимым образом. Может ли быть проблема в текстуре? Она довольно большая, 5120х1024.
>>712122
Таки да, дело оказалось в размере тайлмапы. Сжал её в два раза, стало всё нормально рисоваться. Теперь вот только предстоит развлекаться с масштабированием всего в игре, потому что в годот не завезли нормальный скейл для тайлмапа, который бы не затрагивал его потомков, координаты мыши и прочие важные характеристики.
Таки да, дело оказалось в размере тайлмапы. Сжал её в два раза, стало всё нормально рисоваться. Теперь вот только предстоит развлекаться с масштабированием всего в игре, потому что в годот не завезли нормальный скейл для тайлмапа, который бы не затрагивал его потомков, координаты мыши и прочие важные характеристики.
Хочу запилить модную фичу: при сохранении игры берётся скриншот, кладётся в папку с сейвами, в списке сохранений отображается миниатюрка.
Но не тут-то было. Как взять скриншот игрового поля, если поверх прямо в данный момент отрисовывается окно сохранения? Ну, допустим, как-то взяли. Но Годот не умеет подгружать текстуры без предварительного импорта. И как это обойти, тоже чёт хз.
Годаны, вы бы как это решали? В общих чертах.
Но не тут-то было. Как взять скриншот игрового поля, если поверх прямо в данный момент отрисовывается окно сохранения? Ну, допустим, как-то взяли. Но Годот не умеет подгружать текстуры без предварительного импорта. И как это обойти, тоже чёт хз.
Годаны, вы бы как это решали? В общих чертах.
>>712183
С подгрузкой текстур таки разобрался:
var image = Image.new()
var err = image.load("path/to/the/image.png")
if err == OK:
texture = ImageTexture.new()
texture.create_from_image(image, 0)
Работает, миниатюры успешно отрисовывает.
А вот как делать скриншот-не-скриншот, когда поверх открыто окно, я чёт пока не понимаю.
С подгрузкой текстур таки разобрался:
var image = Image.new()
var err = image.load("path/to/the/image.png")
if err == OK:
texture = ImageTexture.new()
texture.create_from_image(image, 0)
Работает, миниатюры успешно отрисовывает.
А вот как делать скриншот-не-скриншот, когда поверх открыто окно, я чёт пока не понимаю.
>>712214
Скрыть интерфейс (Control-ноду)
Сделать скриншот https://godotengine.org/qa/3313/capture-frame-and-show-it-as-sprite
Показать интерфейс
Не переживай, всё сделается так быстро, что игрок даже не заметит исчезновения интерфейса.
> А вот как делать скриншот-не-скриншот, когда поверх открыто окно, я чёт пока не понимаю.
Скрыть интерфейс (Control-ноду)
Сделать скриншот https://godotengine.org/qa/3313/capture-frame-and-show-it-as-sprite
Показать интерфейс
Не переживай, всё сделается так быстро, что игрок даже не заметит исчезновения интерфейса.
>>712183
1. Делать скриншот ДО вывода окна сохранения? Ты же контролируешь когда оно появится при нажатии на кнопку.
2. Рендерить игру куда то во Viewport
1. Делать скриншот ДО вывода окна сохранения? Ты же контролируешь когда оно появится при нажатии на кнопку.
2. Рендерить игру куда то во Viewport
>>712232
Если ему понадобится сохранять игру в диалоге списка сейвов? Как это практиковалось в ряде игор 2000х годов? Либо трюк со скрытием этого диалога на один фрейм для скриношота. Либо ебаться с вьюпортами.
Если ему понадобится сохранять игру в диалоге списка сейвов? Как это практиковалось в ряде игор 2000х годов? Либо трюк со скрытием этого диалога на один фрейм для скриношота. Либо ебаться с вьюпортами.
>>712183
Я бы ещё круче сделал.
Закодировал бы скриншот маршаллингом https://docs.godotengine.org/ru/stable/classes/class_marshalls.html и положил прямо в сейв-файл.
> берётся скриншот, кладётся в папку с сейвами, в списке сохранений отображается миниатюрка
Я бы ещё круче сделал.
Закодировал бы скриншот маршаллингом https://docs.godotengine.org/ru/stable/classes/class_marshalls.html и положил прямо в сейв-файл.
>>712230
Эммм... пиздос. Это всё работало в 2017 году. Сегодня все эти кэпчуры выпилили. попытка декодировать текстуру вьюпорта у меня только что провалилась (выдаёт сырые гл-данные, которые надо хитрым образом конвертировать, попытка их напрямую заюзать приводит к созданию пустого объекта-пикчи). Надо убегать по делам. Напомни вечером тебе рабочий пример допилить.
Эммм... пиздос. Это всё работало в 2017 году. Сегодня все эти кэпчуры выпилили. попытка декодировать текстуру вьюпорта у меня только что провалилась (выдаёт сырые гл-данные, которые надо хитрым образом конвертировать, попытка их напрямую заюзать приводит к созданию пустого объекта-пикчи). Надо убегать по делам. Напомни вечером тебе рабочий пример допилить.
99 Кб, 846x806>>712250
Этот пример - НЕРАБОЧИЙ
Этот пример - НЕРАБОЧИЙ
>>712257
Откуда ты знаешь, что он схороняться собрался, а не звуку прибавить? В принципе можно при каждом входе в менюшки делать скриншоты, а потом удолять, но зачем?
Откуда ты знаешь, что он схороняться собрался, а не звуку прибавить? В принципе можно при каждом входе в менюшки делать скриншоты, а потом удолять, но зачем?
>>712274
Так если он быстрый что быстрее кадра, то что плохого в том чтобы делать скрин в момент нажатия кнопки меню? Вот если скрин делается медленно, тогда уже да. Надо потестить.
Так если он быстрый что быстрее кадра, то что плохого в том чтобы делать скрин в момент нажатия кнопки меню? Вот если скрин делается медленно, тогда уже да. Надо потестить.
>>712276
В том, что это оверхэд. Неизвестно где и когда он выскочит. Следует избегать оверхэда в проектировании проектов.
> что плохого в том чтобы делать скрин в момент нажатия кнопки меню
В том, что это оверхэд. Неизвестно где и когда он выскочит. Следует избегать оверхэда в проектировании проектов.
>>712277
Так что, все таки не быстро? А раз не быстро, то и промигивать в меню сохранения не выйдет.
Так что, все таки не быстро? А раз не быстро, то и промигивать в меню сохранения не выйдет.
>>712278
Пока что у меня get_viewport().get_texture().get_data() возвращает чёрный квадрат. Как разберусь с этим - так и узнаю, быстро или нет. И если окажется, что нет, у тебя будет ещё один повод попукать в срачетреде одебилевших пуконюхов.
Пока что у меня get_viewport().get_texture().get_data() возвращает чёрный квадрат. Как разберусь с этим - так и узнаю, быстро или нет. И если окажется, что нет, у тебя будет ещё один повод попукать в срачетреде одебилевших пуконюхов.
>>712280
Что, даже в оф демке? Возможно трабла в дровах?
https://godotengine.org/asset-library/asset/130
(у меня есть один забавный ноут, на котором opengl не умеет рисовать прозрачные окна. На всех умеет, а на нем черный фон)
Что, даже в оф демке? Возможно трабла в дровах?
https://godotengine.org/asset-library/asset/130
(у меня есть один забавный ноут, на котором opengl не умеет рисовать прозрачные окна. На всех умеет, а на нем черный фон)
Если просто доставать вьюпорт 65 миллисекунд, если ресайзить (нам ведь миниатюра нужна, не так ли?) то ещё больше выходит 100 миллисекунд.
Конвертация в Б64 с сохранением в ЖСОН, полной текстуры цельная секунда! Но это безумие, если и схоронять, то миниатюру, миниатюра 160x120 пикселов - 130 миллисекунд и 200Кб текстового файла вида {"image" : "HURRRDURRDURRRRRDRAAAAAAAAGHHHH="}
Конвертация в Б64 с сохранением в ЖСОН, полной текстуры цельная секунда! Но это безумие, если и схоронять, то миниатюру, миниатюра 160x120 пикселов - 130 миллисекунд и 200Кб текстового файла вида {"image" : "HURRRDURRDURRRRRDRAAAAAAAAGHHHH="}
>>712301
Можно написать свой ресайзер на с++, который считывает точки только через каждые N координат, и записывает байты сразу в неупакованный png к примеру.
Можно написать свой ресайзер на с++, который считывает точки только через каждые N координат, и записывает байты сразу в неупакованный png к примеру.
>>712303
Можно. На этапе постпродакшена. Когда уже есть игра и автором-художником нанимается кодер-сишник за понюшку творожка в час, чтобы её оптимизировать.
Можно. На этапе постпродакшена. Когда уже есть игра и автором-художником нанимается кодер-сишник за понюшку творожка в час, чтобы её оптимизировать.
>>712307
Ну мало ли, вдруг у него USP игры это возможность делать скриншоты в реальном времени.
Ну мало ли, вдруг у него USP игры это возможность делать скриншоты в реальном времени.
>>712214
А на андроидах такое будет работать?
А на андроидах такое будет работать?
>>712303
Там уже есть готовый метод save_png_to_buffer, который возвращает PoolByteArray.
Там уже есть готовый метод save_png_to_buffer, который возвращает PoolByteArray.
>>712312
Забей, ты не поймешь о чем я.
Забей, ты не поймешь о чем я.
Тред утонул или удален.
Это копия, сохраненная 22 апреля 2022 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Это копия, сохраненная 22 апреля 2022 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.