Этого треда уже нет.
Это копия, сохраненная 15 мая 2023 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Это копия, сохраненная 15 мая 2023 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
250 Кб, 1920x1080Добро пожаловать в тред прощанья, в тред где горят костры рябин!
Краткий гайд по вкату в движок:
1. Читать документацию.
2. Качать примеры.
3. ПРОФИТ!
Ссылки
Новости движка: https://godotengine.org/news/
Скачать движок: https://godotengine.org/download/ или http://store.steampowered.com/app/404790/Godot_Engine/
Теперь прямо онлайн - можно и с дивана: https://godotengine.org/online/godot.tools.html
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 - подборка дополнений, модулей и минишоукейс от одного из авторов, левый необновляемый форк-репо, есть оффициальный обновляемый оригинал https://github.com/godotengine/awesome-godot
Аддон для диалоговой системы: https://github.com/coppolaemilio/dialogic
Для любителей пощекотать конпеляцию
Бинды LUA: https://github.com/perbone/luascript
Бинды JS: https://github.com/GodotExplorer/ECMAScript
Для ностальгирующих дидов
Конвертор кваковских карт https://github.com/Shfty/qodot-plugin
Годнота от анона
- Для приверженцев опенсорца существует возможность распространять проекты в незапакованном формате. Просто скачай темплейт с оф.сайта и положи экзешник/эльфешник в папку с проектом, этого достаточно. Имя файлу можно задать любое. Дополнительно можешь вшить свою иконку в экзешник. После этого, запустившийся файл темплейта обнаружит рядом с собой файл project.godot и начнет грузить проект из него и из файлов, лежащих в распакованном виде в той же директории. Для запущенного таким образом проекта папка res:// становится доступна для записи (если это не ограничено правами доступа в системе).
- В версии 3.2 появилась возможность прикреплять pck к бинарнику. Не появилась, а вернулась - 2.х умел. Бриллиант для любителей однофайлового продукта!
- Редактор персонажей на основе makehuman: https://github.com/Lexpartizan/Go_MakeHuman_dot
- Тест-бенчмарк:
- - Веб-версия - https://govdot.herokuapp.com
- - Вишмастер для винды - https://govdot.herokuapp.com/4Anon.rar
Предыдущий: >>747202 (OP)
Архивный: https://arhivach.net/thread/682305/
Краткий гайд по вкату в движок:
1. Читать документацию.
2. Качать примеры.
3. ПРОФИТ!
Ссылки
Новости движка: https://godotengine.org/news/
Скачать движок: https://godotengine.org/download/ или http://store.steampowered.com/app/404790/Godot_Engine/
Теперь прямо онлайн - можно и с дивана: https://godotengine.org/online/godot.tools.html
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 - подборка дополнений, модулей и минишоукейс от одного из авторов, левый необновляемый форк-репо, есть оффициальный обновляемый оригинал https://github.com/godotengine/awesome-godot
Аддон для диалоговой системы: https://github.com/coppolaemilio/dialogic
Для любителей пощекотать конпеляцию
Бинды LUA: https://github.com/perbone/luascript
Бинды JS: https://github.com/GodotExplorer/ECMAScript
Для ностальгирующих дидов
Конвертор кваковских карт https://github.com/Shfty/qodot-plugin
Годнота от анона
- Для приверженцев опенсорца существует возможность распространять проекты в незапакованном формате. Просто скачай темплейт с оф.сайта и положи экзешник/эльфешник в папку с проектом, этого достаточно. Имя файлу можно задать любое. Дополнительно можешь вшить свою иконку в экзешник. После этого, запустившийся файл темплейта обнаружит рядом с собой файл project.godot и начнет грузить проект из него и из файлов, лежащих в распакованном виде в той же директории. Для запущенного таким образом проекта папка res:// становится доступна для записи (если это не ограничено правами доступа в системе).
- В версии 3.2 появилась возможность прикреплять pck к бинарнику. Не появилась, а вернулась - 2.х умел. Бриллиант для любителей однофайлового продукта!
- Редактор персонажей на основе makehuman: https://github.com/Lexpartizan/Go_MakeHuman_dot
- Тест-бенчмарк:
- - Веб-версия - https://govdot.herokuapp.com
- - Вишмастер для винды - https://govdot.herokuapp.com/4Anon.rar
Предыдущий: >>747202 (OP)
Архивный: https://arhivach.net/thread/682305/
>>766142 →
Ответил тебе не я, я проигнорил.
Ответил тебе не я, я проигнорил.
Опять забыли в шапку добавить список успешных игр.
(Автор этого поста был предупрежден.)
(Автор этого поста был предупрежден.)
>>66178
Сахедо просит передать, что он покушал арбузик и смотрит ютубчик. Думать о геймдеве ему неохота. Приходите завтра.
Сахедо просит передать, что он покушал арбузик и смотрит ютубчик. Думать о геймдеве ему неохота. Приходите завтра.
>>66192 (Del)
Целая одна? Успех.
Целая одна? Успех.
>>66192 (Del)
Вырвиглазная стыдная параша, годоти даже тут обосрались. Вроде реально есть игра, а вроде такое постить зашкварно пиздец
(Автор этого поста был забанен. Помянем.)
Вырвиглазная стыдная параша, годоти даже тут обосрались. Вроде реально есть игра, а вроде такое постить зашкварно пиздец
(Автор этого поста был забанен. Помянем.)
>>66221
Ну жив и хорошо. Это главное
Ну жив и хорошо. Это главное
>>66235 (Del)
Ну так то да. Играть в это я конечно же не буду
Один только взгляд на Cruelty Squad может вызвать у вас тошноту, но он проходит самые важные тесты на погружение в симуляторы с яркими, тошнотворными цветами. Я использовал классические вентиляционные маршруты, чтобы тихо убить надувной замок из плоти в одном прохождении, переключившись на ракетную установку и используя свои кишки в качестве крюка для захвата для более прямого подхода в следующем. Я сложил достаточно стволов, чтобы перелезть через целые здания, и поразил несколько целей идеально рассчитанными снайперскими выстрелами через всю карту.
Cruelty Squad - это Deus Ex, если бы он был создан сегодня, естественный продукт разъяренных людей, измученных неравенством богатства, милитаризацией полиции и упрямыми структурами, которые заставляют человечество катиться к полному уничтожению души. Ага.
Но Отряд жестокости хочет повеселиться до неизбежного конца. Это игра-невидимка, которая подпирает чистую, безмозглую радость от ощущения, что я перехитрил дизайнеров с помощью диких экспериментов, даже если я делаю именно то, что они ожидали. Как и Хитман, это катарсическое упражнение по уничтожению абсолютно худших живых людей. Это аудиовизуальное чудо, виртуальный мир, распадающийся на ваших глазах. И это одна из самых блестящих абсурдных игр, в которые я играл, видение будущего, в котором люди считаются корпоративными дочерними компаниями, а рынок оружия меняется в зависимости от того, какое оружие лицензировано для использования в популярном аниме.
Ну так то да. Играть в это я конечно же не буду
Один только взгляд на Cruelty Squad может вызвать у вас тошноту, но он проходит самые важные тесты на погружение в симуляторы с яркими, тошнотворными цветами. Я использовал классические вентиляционные маршруты, чтобы тихо убить надувной замок из плоти в одном прохождении, переключившись на ракетную установку и используя свои кишки в качестве крюка для захвата для более прямого подхода в следующем. Я сложил достаточно стволов, чтобы перелезть через целые здания, и поразил несколько целей идеально рассчитанными снайперскими выстрелами через всю карту.
Cruelty Squad - это Deus Ex, если бы он был создан сегодня, естественный продукт разъяренных людей, измученных неравенством богатства, милитаризацией полиции и упрямыми структурами, которые заставляют человечество катиться к полному уничтожению души. Ага.
Но Отряд жестокости хочет повеселиться до неизбежного конца. Это игра-невидимка, которая подпирает чистую, безмозглую радость от ощущения, что я перехитрил дизайнеров с помощью диких экспериментов, даже если я делаю именно то, что они ожидали. Как и Хитман, это катарсическое упражнение по уничтожению абсолютно худших живых людей. Это аудиовизуальное чудо, виртуальный мир, распадающийся на ваших глазах. И это одна из самых блестящих абсурдных игр, в которые я играл, видение будущего, в котором люди считаются корпоративными дочерними компаниями, а рынок оружия меняется в зависимости от того, какое оружие лицензировано для использования в популярном аниме.
>>66225
Кто тебя из загона выпустил, животное.
Кто тебя из загона выпустил, животное.
>>66429
Она там давно есть, через animated texture. В пуштайме так блоки с глазами моргают.
Она там давно есть, через animated texture. В пуштайме так блоки с глазами моргают.
>>66734 (Del)
Зачем функция вообще? Объяви и заполни без задней мысли словарь в начале скрипта, а потом без задней мысли пиши где надо: smth[index]
>>66736 (Del)
Вот это охуенная фича питона! Слава Хуану, что перетащил её в годот.
К слову, в си# так же можно, но разумеется, формальностей больше:
foreach (string s in new string[] { "Circle", "Triangle", "Square" } ) { Console.WriteLine(s); }
Зачем функция вообще? Объяви и заполни без задней мысли словарь в начале скрипта, а потом без задней мысли пиши где надо: smth[index]
>>66736 (Del)
Вот это охуенная фича питона! Слава Хуану, что перетащил её в годот.
К слову, в си# так же можно, но разумеется, формальностей больше:
foreach (string s in new string[] { "Circle", "Triangle", "Square" } ) { Console.WriteLine(s); }
14 Кб, 301x323>>66759 (Del)
Палю тебе лайфхак. Если скрипт объявить вместе с содержимым, оно подставляется в подсказках редактора.
> чтобы в начало скрипта к словарю не листать
Палю тебе лайфхак. Если скрипт объявить вместе с содержимым, оно подставляется в подсказках редактора.
>>67552
Ох, вей, точно, надо будет студию подключить видимо лучше
Ох, вей, точно, надо будет студию подключить видимо лучше
Вот в списке у меня экземпляры классов персов лежат. Как мне их на сцену добавить, при этом для каждого еще разные спрайты должны быть в зависимости от их полей?
>>67567 (Del)
Я к студии привык, вс код как то всрато выглядит, ну и с ним ебля какая то нужна, а не включил и код пишешь, насколько я помню
Я к студии привык, вс код как то всрато выглядит, ну и с ним ебля какая то нужна, а не включил и код пишешь, насколько я помню
>>67572 (Del)
Не, вот гляди. Есть у мейн сцена. Есть у меня класс с коллизией. В классе поля, типо, pozitionX, pozitionY, weapon и тд.
В мейн сцене скрипт, в методе Ready я создаю штук десять этих экземпляров классов и кладу их в лист, естественно, чтобы потом можно было перебирать. При создании указываю у них разное оружие. Теперь мне их надо на мейн сцену всех добавить, но при этом спрайт самого хумана один и тот же, меняется только спрайт оружия в зависимости от того что в поле weapon. То есть по итогу на сцене должны быть десять хуманов, но с разным спрайтом оружия
Не, вот гляди. Есть у мейн сцена. Есть у меня класс с коллизией. В классе поля, типо, pozitionX, pozitionY, weapon и тд.
В мейн сцене скрипт, в методе Ready я создаю штук десять этих экземпляров классов и кладу их в лист, естественно, чтобы потом можно было перебирать. При создании указываю у них разное оружие. Теперь мне их надо на мейн сцену всех добавить, но при этом спрайт самого хумана один и тот же, меняется только спрайт оружия в зависимости от того что в поле weapon. То есть по итогу на сцене должны быть десять хуманов, но с разным спрайтом оружия
>>67569
А я и в студии работаю, и в коде. В студии удобно десктопные формы формошлёпить и встроееным дебаггером запускать на дебаг, а в коде удобнее кодить модули стороннего софта (годот, юнити) который самостоятельно проекты запускает на дебаг/исполнение.
А я и в студии работаю, и в коде. В студии удобно десктопные формы формошлёпить и встроееным дебаггером запускать на дебаг, а в коде удобнее кодить модули стороннего софта (годот, юнити) который самостоятельно проекты запускает на дебаг/исполнение.
>>67604 (Del)
Ага, понятно, спасибо.
С точки зрения программиста нода это некая сущность, любой объект, класс по сути. А сцена тогда это что? Контейнер для классов, типо, модуль или как?
Ага, понятно, спасибо.
С точки зрения программиста нода это некая сущность, любой объект, класс по сути. А сцена тогда это что? Контейнер для классов, типо, модуль или как?
>>67677 (Del)
Это если в расширении файла есть метка t - текстовый, файлы же scn - бинарные. Правда ими никто не пользуется (даже я).
> это текстовый файл
Это если в расширении файла есть метка t - текстовый, файлы же scn - бинарные. Правда ими никто не пользуется (даже я).
>>67677 (Del)
Ну вот открыл и чо
Nodes
But let's start with the basics. Nodes are fundamental building blocks for creating a game. As mentioned above, a node can perform a variety of specialized functions. However, any given node always has the following attributes:
It has a name.
It has editable properties.
It can receive a callback to process every frame.
It can be extended (to have more functions).
It can be added to another node as a child.
../../_images/tree.png
The last one is important. Nodes can have other nodes as children. When arranged in this way, the nodes become a tree.
In Godot, the ability to arrange nodes in this way creates a powerful tool for organizing projects. Since different nodes have different functions, combining them allows for the creation of more complex functions.
Don't worry if this doesn't click yet. We will continue to explore this over the next few sections. The most important fact to remember for now is that nodes exist and can be arranged this way.
Scenes
../../_images/scene_tree_example.png
Now that the concept of nodes has been defined, the next logical step is to explain what a Scene is.
A scene is composed of a group of nodes organized hierarchically (in tree fashion). Furthermore, a scene:
always has one root node.
can be saved to disk and loaded back.
can be instanced (more on that later).
Running a game means running a scene. A project can contain several scenes, but for the game to start, one of them must be selected as the main scene.
Basically, the Godot editor is a scene editor. It has plenty of tools for editing 2D and 3D scenes as well as user interfaces, but the editor is based on the concept of editing a scene and the nodes that compose it.
Нода это узел, узел может содержать другие узлы и у него есть имя и свойства. И чо? Чо это такое, с точки зрения программиста? Класс? Ну вот сцена может инстанциироваться, так вроде тогда сцена это класс, а узел тогда что?
Ну вот открыл и чо
Nodes
But let's start with the basics. Nodes are fundamental building blocks for creating a game. As mentioned above, a node can perform a variety of specialized functions. However, any given node always has the following attributes:
It has a name.
It has editable properties.
It can receive a callback to process every frame.
It can be extended (to have more functions).
It can be added to another node as a child.
../../_images/tree.png
The last one is important. Nodes can have other nodes as children. When arranged in this way, the nodes become a tree.
In Godot, the ability to arrange nodes in this way creates a powerful tool for organizing projects. Since different nodes have different functions, combining them allows for the creation of more complex functions.
Don't worry if this doesn't click yet. We will continue to explore this over the next few sections. The most important fact to remember for now is that nodes exist and can be arranged this way.
Scenes
../../_images/scene_tree_example.png
Now that the concept of nodes has been defined, the next logical step is to explain what a Scene is.
A scene is composed of a group of nodes organized hierarchically (in tree fashion). Furthermore, a scene:
always has one root node.
can be saved to disk and loaded back.
can be instanced (more on that later).
Running a game means running a scene. A project can contain several scenes, but for the game to start, one of them must be selected as the main scene.
Basically, the Godot editor is a scene editor. It has plenty of tools for editing 2D and 3D scenes as well as user interfaces, but the editor is based on the concept of editing a scene and the nodes that compose it.
Нода это узел, узел может содержать другие узлы и у него есть имя и свойства. И чо? Чо это такое, с точки зрения программиста? Класс? Ну вот сцена может инстанциироваться, так вроде тогда сцена это класс, а узел тогда что?
>>67677 (Del)
Ну вот открыл и чо
Nodes
But let's start with the basics. Nodes are fundamental building blocks for creating a game. As mentioned above, a node can perform a variety of specialized functions. However, any given node always has the following attributes:
It has a name.
It has editable properties.
It can receive a callback to process every frame.
It can be extended (to have more functions).
It can be added to another node as a child.
../../_images/tree.png
The last one is important. Nodes can have other nodes as children. When arranged in this way, the nodes become a tree.
In Godot, the ability to arrange nodes in this way creates a powerful tool for organizing projects. Since different nodes have different functions, combining them allows for the creation of more complex functions.
Don't worry if this doesn't click yet. We will continue to explore this over the next few sections. The most important fact to remember for now is that nodes exist and can be arranged this way.
Scenes
../../_images/scene_tree_example.png
Now that the concept of nodes has been defined, the next logical step is to explain what a Scene is.
A scene is composed of a group of nodes organized hierarchically (in tree fashion). Furthermore, a scene:
always has one root node.
can be saved to disk and loaded back.
can be instanced (more on that later).
Running a game means running a scene. A project can contain several scenes, but for the game to start, one of them must be selected as the main scene.
Basically, the Godot editor is a scene editor. It has plenty of tools for editing 2D and 3D scenes as well as user interfaces, but the editor is based on the concept of editing a scene and the nodes that compose it.
Нода это узел, узел может содержать другие узлы и у него есть имя и свойства. И чо? Чо это такое, с точки зрения программиста? Класс? Ну вот сцена может инстанциироваться, так вроде тогда сцена это класс, а узел тогда что?
Ну вот открыл и чо
Nodes
But let's start with the basics. Nodes are fundamental building blocks for creating a game. As mentioned above, a node can perform a variety of specialized functions. However, any given node always has the following attributes:
It has a name.
It has editable properties.
It can receive a callback to process every frame.
It can be extended (to have more functions).
It can be added to another node as a child.
../../_images/tree.png
The last one is important. Nodes can have other nodes as children. When arranged in this way, the nodes become a tree.
In Godot, the ability to arrange nodes in this way creates a powerful tool for organizing projects. Since different nodes have different functions, combining them allows for the creation of more complex functions.
Don't worry if this doesn't click yet. We will continue to explore this over the next few sections. The most important fact to remember for now is that nodes exist and can be arranged this way.
Scenes
../../_images/scene_tree_example.png
Now that the concept of nodes has been defined, the next logical step is to explain what a Scene is.
A scene is composed of a group of nodes organized hierarchically (in tree fashion). Furthermore, a scene:
always has one root node.
can be saved to disk and loaded back.
can be instanced (more on that later).
Running a game means running a scene. A project can contain several scenes, but for the game to start, one of them must be selected as the main scene.
Basically, the Godot editor is a scene editor. It has plenty of tools for editing 2D and 3D scenes as well as user interfaces, but the editor is based on the concept of editing a scene and the nodes that compose it.
Нода это узел, узел может содержать другие узлы и у него есть имя и свойства. И чо? Чо это такое, с точки зрения программиста? Класс? Ну вот сцена может инстанциироваться, так вроде тогда сцена это класс, а узел тогда что?
>>67698
Бля затупил. Отвечаю повторно.>>67694
Дерево нод - это шаблон проектирования, известный как Компоновщик https://refactoring.guru/ru/design-patterns/composite
Вот теперь дальше сам, по ссылочкам и в гугел.
Бля затупил. Отвечаю повторно.>>67694
> И чо? Чо это такое, с точки зрения программиста?
Дерево нод - это шаблон проектирования, известный как Компоновщик https://refactoring.guru/ru/design-patterns/composite
Вот теперь дальше сам, по ссылочкам и в гугел.
>>66221
Кстати, планируешь закатываться снова, пока всю какаву не выпили и музыку для жёлтой зоны не нашли?
Кстати, планируешь закатываться снова, пока всю какаву не выпили и музыку для жёлтой зоны не нашли?
>>67714
Я пока в сомнениях. Не вдохновляет меня пиксельарт. Я хочу делать игры в графическом стиле Crippy Tale, например, со скелетной анимацией и художественным графоном. Ты, как я понимаю, такой уровень графона мне поставить не сможешь.
Я пока в сомнениях. Не вдохновляет меня пиксельарт. Я хочу делать игры в графическом стиле Crippy Tale, например, со скелетной анимацией и художественным графоном. Ты, как я понимаю, такой уровень графона мне поставить не сможешь.
>>67715
Всё так. Я в пуксели потому и подался, что рисовать не умею.
Может в /гд/ и будут идейные товарищи кто так запилит, но сомневаюсь
Всё так. Я в пуксели потому и подался, что рисовать не умею.
Может в /гд/ и будут идейные товарищи кто так запилит, но сомневаюсь
Есть ли в годоте какие-то алгоритмы по графам, кроме AStar? Или надо самому всё реализовывать/библиотеки искать?
>>67997
Да есть у меня AStar уже.
Но с ним ИИ вытворяет дикие кренделя в сборке ресурсов по карте. Потому что когда надо обойти граф, то получается жадный алгоритм, который бегает от вершины к ближайшей вершине. Обмазал пока его кучей ифов, чтобы составить правдоподобный маршрут. Но выглядит костыльно, хотя и работает. Я не хочу сделать, чтобы ИИ бегал по карте с максимально оптимальным маршрутом, потому что 100% эффективность не выглядит интересной, но ИИ, который мечется на ровном месте тоже выглядит странным.
У меня другой вопрос возник. Что я делаю не так с извлечением значения в двумерном массиве (естественно, массив массивов)?
У меня извлекается нужное значение, но в виде массива, например vortexDistance[2][6] как [4]. При этом для одномерных массивов там сразу извлекается int, вроде 4.
Пока закостылил через даблкаст int(str()), но костыль же.
Да есть у меня AStar уже.
Но с ним ИИ вытворяет дикие кренделя в сборке ресурсов по карте. Потому что когда надо обойти граф, то получается жадный алгоритм, который бегает от вершины к ближайшей вершине. Обмазал пока его кучей ифов, чтобы составить правдоподобный маршрут. Но выглядит костыльно, хотя и работает. Я не хочу сделать, чтобы ИИ бегал по карте с максимально оптимальным маршрутом, потому что 100% эффективность не выглядит интересной, но ИИ, который мечется на ровном месте тоже выглядит странным.
У меня другой вопрос возник. Что я делаю не так с извлечением значения в двумерном массиве (естественно, массив массивов)?
У меня извлекается нужное значение, но в виде массива, например vortexDistance[2][6] как [4]. При этом для одномерных массивов там сразу извлекается int, вроде 4.
Пока закостылил через даблкаст int(str()), но костыль же.
15 Кб, 883x171>>68016
Возможно, у тебя типичная ошибка при работе с массивмассивычем. У него чтение элементов идёт в формате массивыч[y][x]. Массив-наоборот с толщечислами.
> Что я делаю не так с извлечением значения в двумерном массиве (естественно, массив массивов)?
Возможно, у тебя типичная ошибка при работе с массивмассивычем. У него чтение элементов идёт в формате массивыч[y][x]. Массив-наоборот с толщечислами.
>>68081 (Del)
Кстати двачую.
Чтобы произвести обратное действие и разложить индекс массива на координаты i,j (они же x,y) нужно применить несложную формулу:
X = index % ARRAY_WIDTH
Y = index / ARRAY_WIDTH
Кстати двачую.
Чтобы произвести обратное действие и разложить индекс массива на координаты i,j (они же x,y) нужно применить несложную формулу:
X = index % ARRAY_WIDTH
Y = index / ARRAY_WIDTH
>>68069
Не вижу никаких проблем. Ты же говоришь [2][1], что соответствует в человекочитаемом языке "эй, годо, отдай мне третий массив, второй элемент".
>>68081 (Del)
Уже отказался. Слишком много возни. Перешёл на словари массивов, кек. Но работать стало удобнее + осталась возможность пользоваться преимуществами одномерных массивов + возможность использования фунцкии для создания соваря-перевёртыша, что позволяет обратный поиск совершать удобно именно по значению.
Вообще, не думаю, что на ограниченных объёмах таблиц размеров типа 6*6 производительность прямо критично просядет. И всяко удобнее, когда ты не знаешь, будет у тебя таблица 2х2 или 5х5,но точно никогда 8х8 и больше.
Не вижу никаких проблем. Ты же говоришь [2][1], что соответствует в человекочитаемом языке "эй, годо, отдай мне третий массив, второй элемент".
>>68081 (Del)
Уже отказался. Слишком много возни. Перешёл на словари массивов, кек. Но работать стало удобнее + осталась возможность пользоваться преимуществами одномерных массивов + возможность использования фунцкии для создания соваря-перевёртыша, что позволяет обратный поиск совершать удобно именно по значению.
Вообще, не думаю, что на ограниченных объёмах таблиц размеров типа 6*6 производительность прямо критично просядет. И всяко удобнее, когда ты не знаешь, будет у тебя таблица 2х2 или 5х5,но точно никогда 8х8 и больше.
>>68069
Так ведь же именно так и работают массивы, с обратной перечислением координат.
Именно поэтому во всех топ-современных софтах с тремя осями XYZ высоту обозначают Z, а не Y.
Потому, как если бы мы хотели трёхмерный массив сделать (аля чанк майнкрафта), мы бы выбирали элемент по elements[z][y][x]. То есть, сначала слой по высоте, потом ряд, потом элемент из ряду.
Так ведь же именно так и работают массивы, с обратной перечислением координат.
Именно поэтому во всех топ-современных софтах с тремя осями XYZ высоту обозначают Z, а не Y.
Потому, как если бы мы хотели трёхмерный массив сделать (аля чанк майнкрафта), мы бы выбирали элемент по elements[z][y][x]. То есть, сначала слой по высоте, потом ряд, потом элемент из ряду.
>>68133
А почему раньше высота была Y?
> Именно поэтому во всех топ-современных софтах с тремя осями XYZ высоту обозначают Z, а не Y.
А почему раньше высота была Y?
16 Кб, 469x105А по сохранениям подскажите.
Как лучше сделать? Пилить предварительно свою структуру данных, которую потом сохранять? Или есть возможность, например, сохранить пачку глобальных переменных и радоваться жизни? До этого пикрил накидал в качестве заглушки, а вот теперь дошёл до того, чтобы сделать системы сохранения и загрузки.
Как лучше сделать? Пилить предварительно свою структуру данных, которую потом сохранять? Или есть возможность, например, сохранить пачку глобальных переменных и радоваться жизни? До этого пикрил накидал в качестве заглушки, а вот теперь дошёл до того, чтобы сделать системы сохранения и загрузки.
>>68177
>>68175
Ретранслирую совет из документации. Делай группу сохраняемых сущностей, в каждой из них делай метод get_save_data, возвращающий жсон с актуальными данными, затем собирай это всё и в файл.
А от себя хочу предложить мой авторский метод, который я частично и у тебя на скрине наблюдаю. Делаешь синглтон WORLD в котором есть глобальный словарь со всем конфигом мира, членами которого являются подсловари-секции локаций, внутри которых можно организовать подсловари-секции объектов на локации.
Синглтон держит всю инфу игрового мира в памяти всё время, когда пользователь играет. При загрузке загружается полный файл, со всеми данными мира. При записи записывается так же весь файл.
Казалось бы оверхэд?
Но нет. При такой системе элегантно и без дополнительных усилий игра может менять состояния незагруженных в данный момент объектов. И когда игрок придёт в новую локацию, там его будут уже автоматически ожидать изменившиеся условия.
Например. Довакин в Вайтране сдал страже некоторого вора, ограбившего некоторого прохожего. Получил награду. И пошел в Виндхельм. Оттуда пошёл в Маркарт. По пути зачистил сотню пещер. Забыл уже об этом инциденте. И только много дней спустя посетил Рифтен, а там на него заагрились воры в подворотне. Потому что тот квест отправил данные в секцию Рифтена о том, что таких-то НПЦ требуется переключить во враждебную фракцию игроку.
Или другой пример. Довакин помог неписю с бедой. Непись поблагодарил и пошёл домой. Можно проследить за ним, как он пиздует пешком через всю карту, и он будет честно идти. Но если игрок уходит в противоположную сторону, непись выгружается и записывает график своего местонахождения в несколько локаций по пути следования так, что в идеале, пока он идёт, Довакин может рандомно наткнуться на него. Но эта фича сложная, даже у тодда глючит, есть знаменитый баг, когда какая-то орчиха, не помню уже имя, заглючивает и начинает рандомно встречаться Довакину в разных локациях.
Или третий пример. Квест затрагивает несколько локаций. Согласно стадиям квеста, локации должны принимать тот или иной вид. На одной руке имеем принудительную проверку каждой загружаемой локацией состояние всех квестов в книге Довакина. На другой - элегантная запись самим квестом изменений в параметры затрагиваемых локаций, так что им при своей загрузке ничего лишнего проверять не надо. Об Довакине и его книге квестов знать ничего не надо.
>>68175
Ретранслирую совет из документации. Делай группу сохраняемых сущностей, в каждой из них делай метод get_save_data, возвращающий жсон с актуальными данными, затем собирай это всё и в файл.
А от себя хочу предложить мой авторский метод, который я частично и у тебя на скрине наблюдаю. Делаешь синглтон WORLD в котором есть глобальный словарь со всем конфигом мира, членами которого являются подсловари-секции локаций, внутри которых можно организовать подсловари-секции объектов на локации.
Синглтон держит всю инфу игрового мира в памяти всё время, когда пользователь играет. При загрузке загружается полный файл, со всеми данными мира. При записи записывается так же весь файл.
Казалось бы оверхэд?
Но нет. При такой системе элегантно и без дополнительных усилий игра может менять состояния незагруженных в данный момент объектов. И когда игрок придёт в новую локацию, там его будут уже автоматически ожидать изменившиеся условия.
Например. Довакин в Вайтране сдал страже некоторого вора, ограбившего некоторого прохожего. Получил награду. И пошел в Виндхельм. Оттуда пошёл в Маркарт. По пути зачистил сотню пещер. Забыл уже об этом инциденте. И только много дней спустя посетил Рифтен, а там на него заагрились воры в подворотне. Потому что тот квест отправил данные в секцию Рифтена о том, что таких-то НПЦ требуется переключить во враждебную фракцию игроку.
Или другой пример. Довакин помог неписю с бедой. Непись поблагодарил и пошёл домой. Можно проследить за ним, как он пиздует пешком через всю карту, и он будет честно идти. Но если игрок уходит в противоположную сторону, непись выгружается и записывает график своего местонахождения в несколько локаций по пути следования так, что в идеале, пока он идёт, Довакин может рандомно наткнуться на него. Но эта фича сложная, даже у тодда глючит, есть знаменитый баг, когда какая-то орчиха, не помню уже имя, заглючивает и начинает рандомно встречаться Довакину в разных локациях.
Или третий пример. Квест затрагивает несколько локаций. Согласно стадиям квеста, локации должны принимать тот или иной вид. На одной руке имеем принудительную проверку каждой загружаемой локацией состояние всех квестов в книге Довакина. На другой - элегантная запись самим квестом изменений в параметры затрагиваемых локаций, так что им при своей загрузке ничего лишнего проверять не надо. Об Довакине и его книге квестов знать ничего не надо.
>>68177
>>68175
Ретранслирую совет из документации. Делай группу сохраняемых сущностей, в каждой из них делай метод get_save_data, возвращающий жсон с актуальными данными, затем собирай это всё и в файл.
А от себя хочу предложить мой авторский метод, который я частично и у тебя на скрине наблюдаю. Делаешь синглтон WORLD в котором есть глобальный словарь со всем конфигом мира, членами которого являются подсловари-секции локаций, внутри которых можно организовать подсловари-секции объектов на локации.
Синглтон держит всю инфу игрового мира в памяти всё время, когда пользователь играет. При загрузке загружается полный файл, со всеми данными мира. При записи записывается так же весь файл.
Казалось бы оверхэд?
Но нет. При такой системе элегантно и без дополнительных усилий игра может менять состояния незагруженных в данный момент объектов. И когда игрок придёт в новую локацию, там его будут уже автоматически ожидать изменившиеся условия.
Например. Довакин в Вайтране сдал страже некоторого вора, ограбившего некоторого прохожего. Получил награду. И пошел в Виндхельм. Оттуда пошёл в Маркарт. По пути зачистил сотню пещер. Забыл уже об этом инциденте. И только много дней спустя посетил Рифтен, а там на него заагрились воры в подворотне. Потому что тот квест отправил данные в секцию Рифтена о том, что таких-то НПЦ требуется переключить во враждебную фракцию игроку.
Или другой пример. Довакин помог неписю с бедой. Непись поблагодарил и пошёл домой. Можно проследить за ним, как он пиздует пешком через всю карту, и он будет честно идти. Но если игрок уходит в противоположную сторону, непись выгружается и записывает график своего местонахождения в несколько локаций по пути следования так, что в идеале, пока он идёт, Довакин может рандомно наткнуться на него. Но эта фича сложная, даже у тодда глючит, есть знаменитый баг, когда какая-то орчиха, не помню уже имя, заглючивает и начинает рандомно встречаться Довакину в разных локациях.
Или третий пример. Квест затрагивает несколько локаций. Согласно стадиям квеста, локации должны принимать тот или иной вид. На одной руке имеем принудительную проверку каждой загружаемой локацией состояние всех квестов в книге Довакина. На другой - элегантная запись самим квестом изменений в параметры затрагиваемых локаций, так что им при своей загрузке ничего лишнего проверять не надо. Об Довакине и его книге квестов знать ничего не надо.
>>68175
Ретранслирую совет из документации. Делай группу сохраняемых сущностей, в каждой из них делай метод get_save_data, возвращающий жсон с актуальными данными, затем собирай это всё и в файл.
А от себя хочу предложить мой авторский метод, который я частично и у тебя на скрине наблюдаю. Делаешь синглтон WORLD в котором есть глобальный словарь со всем конфигом мира, членами которого являются подсловари-секции локаций, внутри которых можно организовать подсловари-секции объектов на локации.
Синглтон держит всю инфу игрового мира в памяти всё время, когда пользователь играет. При загрузке загружается полный файл, со всеми данными мира. При записи записывается так же весь файл.
Казалось бы оверхэд?
Но нет. При такой системе элегантно и без дополнительных усилий игра может менять состояния незагруженных в данный момент объектов. И когда игрок придёт в новую локацию, там его будут уже автоматически ожидать изменившиеся условия.
Например. Довакин в Вайтране сдал страже некоторого вора, ограбившего некоторого прохожего. Получил награду. И пошел в Виндхельм. Оттуда пошёл в Маркарт. По пути зачистил сотню пещер. Забыл уже об этом инциденте. И только много дней спустя посетил Рифтен, а там на него заагрились воры в подворотне. Потому что тот квест отправил данные в секцию Рифтена о том, что таких-то НПЦ требуется переключить во враждебную фракцию игроку.
Или другой пример. Довакин помог неписю с бедой. Непись поблагодарил и пошёл домой. Можно проследить за ним, как он пиздует пешком через всю карту, и он будет честно идти. Но если игрок уходит в противоположную сторону, непись выгружается и записывает график своего местонахождения в несколько локаций по пути следования так, что в идеале, пока он идёт, Довакин может рандомно наткнуться на него. Но эта фича сложная, даже у тодда глючит, есть знаменитый баг, когда какая-то орчиха, не помню уже имя, заглючивает и начинает рандомно встречаться Довакину в разных локациях.
Или третий пример. Квест затрагивает несколько локаций. Согласно стадиям квеста, локации должны принимать тот или иной вид. На одной руке имеем принудительную проверку каждой загружаемой локацией состояние всех квестов в книге Довакина. На другой - элегантная запись самим квестом изменений в параметры затрагиваемых локаций, так что им при своей загрузке ничего лишнего проверять не надо. Об Довакине и его книге квестов знать ничего не надо.
>>68147
Дети смотрели на доску и видели траекторию полёта мячика. "Ага, значит Y — высота". Но потом пришло поколение, которое видело тертрадку, а тетрадь горизонтально расположена, значит X и Y это горизонтальные оси.
На самом деле я не знаю, почему и зачем так делали. Я и сам раньше был адептом игрековой высоты, но как осознал индексацию, так и понял, что лучше Z использовать.
Дети смотрели на доску и видели траекторию полёта мячика. "Ага, значит Y — высота". Но потом пришло поколение, которое видело тертрадку, а тетрадь горизонтально расположена, значит X и Y это горизонтальные оси.
На самом деле я не знаю, почему и зачем так делали. Я и сам раньше был адептом игрековой высоты, но как осознал индексацию, так и понял, что лучше Z использовать.
>>68244
Лишь бы разработчик не допустил баг, записывающий в локации неправильное, так что даже при перезапуске игры прохождение будет запоротым.
>элегантная запись самим квестом изменений в параметры затрагиваемых локаций, так что им при своей загрузке ничего лишнего проверять не надо
Лишь бы разработчик не допустил баг, записывающий в локации неправильное, так что даже при перезапуске игры прохождение будет запоротым.
>>68261
А ты на тетрадь смотришь под углом в 90 градусов? Потому что у всех нормальных людей верх тетрадного листа - это "вверх", а не "вперёд".
> а тетрадь горизонтально расположена, значит X и Y это горизонтальные оси.
А ты на тетрадь смотришь под углом в 90 градусов? Потому что у всех нормальных людей верх тетрадного листа - это "вверх", а не "вперёд".
>>68296
Ты невнимательно читаешь анона. Если позволите вступлюсь за него.
Он написал, что мыслить следует категориями: Слой-Ряд-Элемент. Тогда все противоречия отпадают. Иначе же можно до хрипоты спорить, что один видит лист так, а второй - эдак. Одному игрек высота, другому ширина.
Ты невнимательно читаешь анона. Если позволите вступлюсь за него.
Он написал, что мыслить следует категориями: Слой-Ряд-Элемент. Тогда все противоречия отпадают. Иначе же можно до хрипоты спорить, что один видит лист так, а второй - эдак. Одному игрек высота, другому ширина.
Как изменить размеры экрана при смене ориентации с модом keep? Не выходит из размера считанного с конфига 1080.500 сделать 500,1080 в рилтайме.
var _size:Vector2 = Vector2.ZERO setget size_set, size_get;
func size_set(value:Vector2)->void:
if value == _size:
return;
var is_landscape:bool = self.is_landscape();
_size = value;
if is_landscape != self.is_landscape():
if !is_landscape:
get_tree().set_screen_stretch(1,2,Vector2(380,640));
else:
get_tree().set_screen_stretch(1,2,Vector2(640,380));
self.emit_signal("orintation_changed");
Вроде помогли, но за двумя исключениями =>
1) Первый раз окно поворачивается, но его масштабирование не верно. Если снова повернуть в это положение, все будет нормально.
2) Черные бордеры от keep не изменились даже от смены размера.
func size_set(value:Vector2)->void:
if value == _size:
return;
var is_landscape:bool = self.is_landscape();
_size = value;
if is_landscape != self.is_landscape():
if !is_landscape:
get_tree().set_screen_stretch(1,2,Vector2(380,640));
else:
get_tree().set_screen_stretch(1,2,Vector2(640,380));
self.emit_signal("orintation_changed");
Вроде помогли, но за двумя исключениями =>
1) Первый раз окно поворачивается, но его масштабирование не верно. Если снова повернуть в это положение, все будет нормально.
2) Черные бордеры от keep не изменились даже от смены размера.
>>68345
Скорее всего годот сам меняет пропорции, а потом приходишь ты и меняешь ещё раз вручную. Чисто с дивана предположил. Чисто по своему опыту знакомства с годотом - я многие вещи пытался велосипедить, а потом оказывалось, что всё это было искаропки, надо только доки почитать внимательно.
Скорее всего годот сам меняет пропорции, а потом приходишь ты и меняешь ещё раз вручную. Чисто с дивана предположил. Чисто по своему опыту знакомства с годотом - я многие вещи пытался велосипедить, а потом оказывалось, что всё это было искаропки, надо только доки почитать внимательно.
>>68347
Так, и как мне искаропки сделать возможность менять ориентацию экрана, но с keep_width?
Так, и как мне искаропки сделать возможность менять ориентацию экрана, но с keep_width?
>>68365
Ага, спасибо, помогло.
Ага, спасибо, помогло.
>>68262
Кстати, злобная штука, когда сейвы херятся по техническим причинам.
У меня так похерилось 2 катки в стелларисе на айрон моде. Потому что оно записало где-то ошибку, видимо, и меня выкидывало на следующий внутриигровой месяц всегда.
Кстати, злобная штука, когда сейвы херятся по техническим причинам.
У меня так похерилось 2 катки в стелларисе на айрон моде. Потому что оно записало где-то ошибку, видимо, и меня выкидывало на следующий внутриигровой месяц всегда.
>>68411
На каждую старуху бывает проруха, хоть делай интегрити-чек, хоть нет, особенно, если игра с модами.
На каждую старуху бывает проруха, хоть делай интегрити-чек, хоть нет, особенно, если игра с модами.
59 Кб, 481x783Яндекс сделал автоматический голосовой перевод видосов.
Я ухожу пересматривать гейм эндевора на русском!
Я ухожу пересматривать гейм эндевора на русском!
>И до следующего раза... ВЫ ВСЕ УСПОКОЙТЕСЬ!
Сделан мой вечер!
179 Кб, 307x514>>68511
А вы используете Государственную Машину в своих играх?
А вы используете Государственную Машину в своих играх?
"Технически Ultimate скорее реконструкция на новом движке, чем ремастер. Colors перенесли с форка Hedgehog Engine на открытый движок Godot. Здесь создатели Ultimate поступили максимально странно: они создали свой форк Godot, назвали его Blind Squirrel Engine, и удалили все упоминания Godot. Разработчики уже извинились и пообещали исправить эту оплошность в ближайшем патче"
https://twitter.com/falessandrelli/status/1433856957476216840
как перестать ржать??)
https://twitter.com/falessandrelli/status/1433856957476216840
как перестать ржать??)
>>68581
Следующий патч: "Обратите внимание, это не мы с игрой обосрались, это годотя нам в штаны насрала".
>Разработчики уже извинились и пообещали исправить эту оплошность в ближайшем патче
Следующий патч: "Обратите внимание, это не мы с игрой обосрались, это годотя нам в штаны насрала".
586 Кб, 2186x908>>68584 (Del)
Да-да, к релизу все обязательно пропатчат и заапдейтят. Ты, может, еще в деда мороза веришь до сих пор?
Да-да, к релизу все обязательно пропатчат и заапдейтят. Ты, может, еще в деда мороза веришь до сих пор?
34 Кб, 400x300>>68581
Поступили как и большинство ньюфагов, встречающих опенсорс. БЛЯТЬ, КОД! БЕСПЛАТНО! Я ЕГО ПЕРЕИМЕНУЮ И ВЫДАМ ЗА СВОЙ
> Здесь создатели Ultimate поступили максимально странно
Поступили как и большинство ньюфагов, встречающих опенсорс. БЛЯТЬ, КОД! БЕСПЛАТНО! Я ЕГО ПЕРЕИМЕНУЮ И ВЫДАМ ЗА СВОЙ
>>68588 (Del)
Я не про кредитсы говорю, а про то, что игра - забагованный пиздец.
Я не про кредитсы говорю, а про то, что игра - забагованный пиздец.
Как воспроизвести видео из ютуба или все еще не завезли поддержку кодеков?
2,3 Мб, 1280x854>>69243 (Del)
Можно, разрешаю
Можно, разрешаю
103 Кб, 598x595>>69243 (Del)
Я тоже не против.
Я тоже не против.
Котаны, а вот вопрос, над которым я задумался только что. Как лучше с сигналами работать? Всё время цеплял их через гуя, а потом понял, что местами начал через .connect() писать, и теперь (пока) у меня смесь того и другого.
В чём разница? Или вопрос сугубо персонального удобства?
>>69413 (Del)
Мне кажется, проблема шарпа в годоте в том, что основная масса примеров, проблем и обсуждений ведётся на гдскрипте. Без всего этого шарпу не захватить массу.
Я шарпом когда-то пользовался, потом лет на 5 забил. Потом скачал годот и понял, что шар я так и не очень-то помню, а тут ещё и годот пытаешься освоить попутно, спотыкаясь то на одном, то на втором.
В чём разница? Или вопрос сугубо персонального удобства?
>>69413 (Del)
Мне кажется, проблема шарпа в годоте в том, что основная масса примеров, проблем и обсуждений ведётся на гдскрипте. Без всего этого шарпу не захватить массу.
Я шарпом когда-то пользовался, потом лет на 5 забил. Потом скачал годот и понял, что шар я так и не очень-то помню, а тут ещё и годот пытаешься освоить попутно, спотыкаясь то на одном, то на втором.
>>69522
Именно так. Нужно выбрать один вариант, твёрдо и чётко. Так же в анриале большинство ответов на блюпринтах, просто нелепо. В юнити изредка натыкаюсь на ответы с яваскриптом, хотя он никогда не был популярен там.
>масса примеров, проблем и обсуждений ведётся на гдскрипте. Без всего этого шарпу не захватить массу.
Именно так. Нужно выбрать один вариант, твёрдо и чётко. Так же в анриале большинство ответов на блюпринтах, просто нелепо. В юнити изредка натыкаюсь на ответы с яваскриптом, хотя он никогда не был популярен там.
>>69556 (Del)
Ну на то в студии (и в коде, и в любом уважающем себя ИДЕ) есть синтаксические подсказки (интеллисенс и т.п. синонимы), ты набираешь gtpr а тебе уже вываливается в подсказках:
Встроенный редактор годота увы под шарп не заточен. В шарпе надо кодить из стороннего ИДЕ. Годот обещает всё-в-одном только при использовании гдскрипта, если ты берешь сторонний язык, то уже как бы внутренне готов к стороннему редактору кода.
> Единственная трудность в названиях полей. Потому что get_parent() может называться GetParent, а может просто проперти Parent.
Ну на то в студии (и в коде, и в любом уважающем себя ИДЕ) есть синтаксические подсказки (интеллисенс и т.п. синонимы), ты набираешь gtpr а тебе уже вываливается в подсказках:
>GetParent
>GotPoopRequest
>GoatTeamProduce<T>
Встроенный редактор годота увы под шарп не заточен. В шарпе надо кодить из стороннего ИДЕ. Годот обещает всё-в-одном только при использовании гдскрипта, если ты берешь сторонний язык, то уже как бы внутренне готов к стороннему редактору кода.
>>69557 (Del)
Решения тоже есть. Самое простое, описанное у Пети-сканера на ютубе, сделать один синглтон, пересилить себя и пойти против правил так сказать. В синглтоне завести пустые переменные, любая интересующая тебя нода, хоть она цельная сцена, хоть объект на внешней от неё сцене, неважно, каждая из них при своей загрузке прописывает себя в свою переменную. При выгрузке обнуляет переменную. Таким образом ты быстро, без зумерских заморочек, небезопасным, неконтролируемым дедовским способом нарушаешь кучу СОЛИДов энтих зумерских и из любой другой ноды видишь любую нужную тебе. Например, в синглтоне есть переменная Player, в которую очевидно прописывается перс игрока при загрузке. И стало быть, все Enemies без задней мысли чекают плеера, если он не нуль, то насколько он далеко? Прикинуться что не замечают его? Или атаковать?
При разработке в соло проблем не будет. При командной разработке такой клубок лапши быстро превратит проект в ад.
> из минусов - надо самому переименовывать, если перетащил/переименовал ноду где-то
Решения тоже есть. Самое простое, описанное у Пети-сканера на ютубе, сделать один синглтон, пересилить себя и пойти против правил так сказать. В синглтоне завести пустые переменные, любая интересующая тебя нода, хоть она цельная сцена, хоть объект на внешней от неё сцене, неважно, каждая из них при своей загрузке прописывает себя в свою переменную. При выгрузке обнуляет переменную. Таким образом ты быстро, без зумерских заморочек, небезопасным, неконтролируемым дедовским способом нарушаешь кучу СОЛИДов энтих зумерских и из любой другой ноды видишь любую нужную тебе. Например, в синглтоне есть переменная Player, в которую очевидно прописывается перс игрока при загрузке. И стало быть, все Enemies без задней мысли чекают плеера, если он не нуль, то насколько он далеко? Прикинуться что не замечают его? Или атаковать?
При разработке в соло проблем не будет. При командной разработке такой клубок лапши быстро превратит проект в ад.
25 Кб, 587x486>>69593 (Del)
Ага, понятно. А в шарпе как вообще сигналы работают? Это классические ивенты EventHandler<EventArgs> или какой то хитровыкрученный велосипед?
>>69522
Для меня персональное удобство вручную назначаемых в гдскрипте сигналов в том, что туда можно любые данные прибиндить, какие я захочу. Через интерфейс только встроенные классы (пикрелейтед). А кодом я могу в сигнал как минимум сендера прихуячить, и ссылку на словарь с данными, и любую произвольную ноду и, и, ооо, да, детка!
Ага, понятно. А в шарпе как вообще сигналы работают? Это классические ивенты EventHandler<EventArgs> или какой то хитровыкрученный велосипед?
>>69522
> Котаны, а вот вопрос, над которым я задумался только что. Как лучше с сигналами работать? Всё время цеплял их через гуя, а потом понял, что местами начал через .connect() писать, и теперь (пока) у меня смесь того и другого.
> В чём разница? Или вопрос сугубо персонального удобства?
Для меня персональное удобство вручную назначаемых в гдскрипте сигналов в том, что туда можно любые данные прибиндить, какие я захочу. Через интерфейс только встроенные классы (пикрелейтед). А кодом я могу в сигнал как минимум сендера прихуячить, и ссылку на словарь с данными, и любую произвольную ноду и, и, ооо, да, детка!
>>69600 (Del)
Ну, хз, вроде не очень уж и страшно выглядит. Зато наверняка через [Signal] этот делегат регистрируется внутри редактора и его можно мышкой прибиндить к другим нодам.
>>69603 (Del)
Через интеллисенс студии.
Ну, хз, вроде не очень уж и страшно выглядит. Зато наверняка через [Signal] этот делегат регистрируется внутри редактора и его можно мышкой прибиндить к другим нодам.
>>69603 (Del)
> А как найти такой делегат у Timer, к примеру, я пока не понял.
Через интеллисенс студии.
>>69603 (Del)
Неее... Я освоил анонимные методы через лямбду и хуячу их везде, где надо и не надо:
> MySignal += MySignalHandlerFunc;
Неее... Я освоил анонимные методы через лямбду и хуячу их везде, где надо и не надо:
> MySignal += (args) => { //Здесь набираю сам код, если много кода, разношу на несколько строк, и только если кода становится больше экрана - выношу в отдельный метод. };
>>69607 (Del)
Так, нипонил. Рассказывай сначала. Чего нету? А я пока моногодот скачаю. Сто лет не годошарпил.
Так, нипонил. Рассказывай сначала. Чего нету? А я пока моногодот скачаю. Сто лет не годошарпил.
>>69611 (Del)
Я понел. Смотри какую я хрень накопал. Там вместо этого навелосипежен некий SignalAwaiter, принимающий инстанс ноды и текстовое описание сигнала этой ноды. Если я правильно понял, затем надо следить за состояниями этого эвэйтера. ХЗ, чот неудобно.
Я понел. Смотри какую я хрень накопал. Там вместо этого навелосипежен некий SignalAwaiter, принимающий инстанс ноды и текстовое описание сигнала этой ноды. Если я правильно понял, затем надо следить за состояниями этого эвэйтера. ХЗ, чот неудобно.
>>69613 (Del)
Сигналы биндятся через редактор годота (вкладка узел/сигналы), но до сих пор игнорируют скобачьки - обработчик дописывается в хвост файла и его надо принудительно переместить вверх, внутрь скобачекь объекта. Тогда заработает.
Сигналы биндятся через редактор годота (вкладка узел/сигналы), но до сих пор игнорируют скобачьки - обработчик дописывается в хвост файла и его надо принудительно переместить вверх, внутрь скобачекь объекта. Тогда заработает.
>>69616
2 секунды сэвед, зато 10 секунд вастед на массив-массивыч.
2 секунды сэвед, зато 10 секунд вастед на массив-массивыч.
В продолжение эпопеи с сохранениями. Есть пикрил.
Директория выводится не та, что я хочу заюзать, в if я не проваливаюсь. Есть похожий баг, но что-то круто для бага такого рода. Это он, или всё же пользовательские директории можно зхаставить работать?
https://github.com/godotengine/godot/issues/35346
Директория выводится не та, что я хочу заюзать, в if я не проваливаюсь. Есть похожий баг, но что-то круто для бага такого рода. Это он, или всё же пользовательские директории можно зхаставить работать?
https://github.com/godotengine/godot/issues/35346
>>69618
А, всё, отбой. Через dir.open() обошёл проблему.
А, всё, отбой. Через dir.open() обошёл проблему.
Как правильно настроить Margin чтобы контролы стояли в три столбца: 10%, 30%, 60% помогите, я нихуя не понимаю и не получается. При ресайзе всё разъезжается в стороны!
>>70018 (Del)
Спасибо! Всё получилось!
Спасибо! Всё получилось!
Анончики, в отчётах гугл плэя иногда проскакивает ANR для игрушки на годоте. С чем это может быть связано?
>>70203 (Del)
Какой нафик ии, там рассчёты не сложнее калькулятора. Такое не массово происходит, а редко случается - может одно на сотню устройств. Какие-то допотопные кирпичи с 4-м и 5-м андроидом судя по аналитике нормально работают. Из последних anr - galaxy a10 с 10-м или 11-м андроидом, не помню.
Какой нафик ии, там рассчёты не сложнее калькулятора. Такое не массово происходит, а редко случается - может одно на сотню устройств. Какие-то допотопные кирпичи с 4-м и 5-м андроидом судя по аналитике нормально работают. Из последних anr - galaxy a10 с 10-м или 11-м андроидом, не помню.
Мзизиз пилит халфу своей мечты
https://www.youtube.com/watch?v=iGah8RemjE0
https://www.youtube.com/watch?v=iGah8RemjE0
Гуру, подскажите, а есть ли какой-то встроенный построитель диаграмм? У меня всего десяток сцен и два десятка скриптов, а я уже начинаю путаться что откуда вызывается, если от проекта отвлекусь на несколько дней. Просто чтобы иметь под рукой всегда накиданную шпаргалку связей (не автоматических, а хотя бы руками связанных), а не листать тетрадь с записями каждый раз.
>>70376 (Del)
Охуенно! Это в шапку однозначно.
Охуенно! Это в шапку однозначно.
>>70611 (Del)
А смысл дёргаться в минорных версиях? Только если тебе нужен специфический добавленный функционал или фикс проблемы.
А смысл дёргаться в минорных версиях? Только если тебе нужен специфический добавленный функционал или фикс проблемы.
1,6 Мб, 1000x800>>70619 (Del)
Сорока-белобока!
Сорока-белобока!
>>70662 (Del)
Оу! Сорян. Евангелисты нам нужны. Ну, расписывай тогда все воцньюсы по пунктам.
Оу! Сорян. Евангелисты нам нужны. Ну, расписывай тогда все воцньюсы по пунктам.
36 Кб, 1586x506Ситуация. Есть Control вот такой ширины (изначально на весь экран). В чём суть проблемы. Вот эта область в оранжевом прямоугольнике, оказывается, непрозрачна для мыши, не смотря на то, что там элементов нет. Как заставить её быть прозрачной для событий с мыши, например, чтобы увеличить эффективную площадь взаимодействия с игровыми объектами? В хайд отправлять всё меню не плинирую, дробить на пачку Control тоже не хотелось бы.
10 Кб, 248x256>>70668
Как обычно, до решения допёр сам. Пробовал пасс, игнор не пробовал. А именно он и делает то, что хочу. Однако вопрос, почему работает только вариант игнор?
Как обычно, до решения допёр сам. Пробовал пасс, игнор не пробовал. А именно он и делает то, что хочу. Однако вопрос, почему работает только вариант игнор?
>>70685 (Del)
Спасибо. Очень доходчиво. Нашёл описание этого уже в доках, но там, кстати, менее ясно смысл описан.
Спасибо. Очень доходчиво. Нашёл описание этого уже в доках, но там, кстати, менее ясно смысл описан.
Можете подсказать туториалов для максимально тупых? Давно хочу что-то склепать для души, и пытался освоить годо, но соснул хуйца дважды. Прошел официальный туториал в котором нужно уворачиваться от летающих головастиков и вроде все понятно. Но как садишься за что-то своё и ощущаешь полную беспомощность.
>>70843
Очень вредное ощущение новичка. В любой сфере, не только в кодинге/геймдевелопинге. Оно может отвернуть от дальнейшего изучения и продвижения. Какой тут может быть совет? Удваиваю предыдущего анона, нарабатывай базу. Пили на движке простые вещи, которые просто работают. Одновременно читай матчасть. Не по годоту матчасть, а по компам вообще. Ты должен осознать, как всё работает. Осознать, почему, например, Хуан в Годоте сделал так, а не иначе. И тогда, постепенно, шаг за шагом, будет приходить понимание:
> как садишься за что-то своё и ощущаешь полную беспомощность
Очень вредное ощущение новичка. В любой сфере, не только в кодинге/геймдевелопинге. Оно может отвернуть от дальнейшего изучения и продвижения. Какой тут может быть совет? Удваиваю предыдущего анона, нарабатывай базу. Пили на движке простые вещи, которые просто работают. Одновременно читай матчасть. Не по годоту матчасть, а по компам вообще. Ты должен осознать, как всё работает. Осознать, почему, например, Хуан в Годоте сделал так, а не иначе. И тогда, постепенно, шаг за шагом, будет приходить понимание:
> Я могу сделать это.
> Я могу сделать вот так.
9,2 Мб, mp4,1280x720, 0:36
8,6 Мб, mp4,544x416, 1:03
>>70957
Потом прошло 3 месяца и я начал лепить первые поделия. Нихуя не понимал, но всюду лез. В данной технодемке с включённым отображением коллизий показано, как я лепил инстансы объектов без полного понимания наследования.
> как я начинал 3 года назад
Потом прошло 3 месяца и я начал лепить первые поделия. Нихуя не понимал, но всюду лез. В данной технодемке с включённым отображением коллизий показано, как я лепил инстансы объектов без полного понимания наследования.
8,9 Мб, mp4,852x480, 1:06
>>70966
Прошёл год и я ощутил себя в силах поучаствовать в своём первом ТВГ. О, как же я ошибался. Я запилил катающегося Йобу-Супер-Йобика и был осмеян за это.
Прошёл год и я ощутил себя в силах поучаствовать в своём первом ТВГ. О, как же я ошибался. Я запилил катающегося Йобу-Супер-Йобика и был осмеян за это.
19,7 Мб, mp4,852x480, 1:04
>>70968
В ужасе от масштабной травли, я забил на двадэ и вернулся к триде, вспомнил свои старые мечты и задумки. Начал воплощать. Но охуел от масштаба работ, которые нужно провернуть в тридэ для запила сколь нибудь толковой игори.
В ужасе от масштабной травли, я забил на двадэ и вернулся к триде, вспомнил свои старые мечты и задумки. Начал воплощать. Но охуел от масштаба работ, которые нужно провернуть в тридэ для запила сколь нибудь толковой игори.
5,1 Мб, mp4,612x360, 0:43
>>70969
Месяц спустя я перешел на мини-игры, размяться решил с признанной классики.
Месяц спустя я перешел на мини-игры, размяться решил с признанной классики.
2,1 Мб, mp4,800x600, 0:15
>>70970
Прошло ещё три месяца метаний из двадэ в тридэ, и тогда мне анон подсказал, что зачем, мол ты пытаешься велосипедить, когда всё уже есть в интернетах: генераторы людей, наборы анимаций. Я подумал, и действительно. И провёл рисёрч.
Прошло ещё три месяца метаний из двадэ в тридэ, и тогда мне анон подсказал, что зачем, мол ты пытаешься велосипедить, когда всё уже есть в интернетах: генераторы людей, наборы анимаций. Я подумал, и действительно. И провёл рисёрч.
>>70861 (Del)
>>70939
>>70957
Спасибо за ответы. Но на самом деле я программист. Просто стек совсем отличный от геймдева. У меня проблема не с языком, хоть гдскрипт и отличен от того на чем я обычно калякаю. Проблема в самом подходе что ли. Ладно, пойду в третий раз сяду делать летабщих головастиков.
>>70939
>>70957
Спасибо за ответы. Но на самом деле я программист. Просто стек совсем отличный от геймдева. У меня проблема не с языком, хоть гдскрипт и отличен от того на чем я обычно калякаю. Проблема в самом подходе что ли. Ладно, пойду в третий раз сяду делать летабщих головастиков.
>>70939
Задроты движкодрочеры. Нафика простому Васяну знать, что там под капотом.
>Осознать, почему, например, Хуан в Годоте сделал так, а не иначе.
Задроты движкодрочеры. Нафика простому Васяну знать, что там под капотом.
>>70971
кулстори бро, продолжай в том же духе.
кулстори бро, продолжай в том же духе.
23 Кб, 522x386print(_triple_point, second, rad2deg(_triple_point.angle_to_point(second)))
p1(1.4, 190) p2(0, 0) angle = 89.577829
p1(1.4, 190) p2(3.5, 1100) angle = -90.132221
p1(1.4, 190) p2(3.8, 500) angle = -90.443569
Как блять посчитать ебаный сука угол от оси XЭ. Какие нахуй 90 градусов, блять.
p1(1.4, 190) p2(0, 0) angle = 89.577829
p1(1.4, 190) p2(3.5, 1100) angle = -90.132221
p1(1.4, 190) p2(3.8, 500) angle = -90.443569
Как блять посчитать ебаный сука угол от оси XЭ. Какие нахуй 90 градусов, блять.
395 Кб, 512x385>>71102
Ну що, дядя, убедился в том, что матеша в школе джвадцать лет назад была таки нужна?
> Как блять
> Какие нахуй
Ну що, дядя, убедился в том, что матеша в школе джвадцать лет назад была таки нужна?
>>71104 (Del)
Т.е. твое утверждение, что оси x и y перепутаны и из-за этого угл неверен?
Т.е. твое утверждение, что оси x и y перепутаны и из-за этого угл неверен?
>>71160
Естественно это нихуя не помогло
(190, 1.4)(0, 0)0.422172
(190, 1.4)(1100, 3.5)-179.867773
(190, 1.4)(500, 3.8)-179.556425
Мы видим явно рост точки вверх, а углы теперь отрицательные. Пиздец.
Естественно это нихуя не помогло
(190, 1.4)(0, 0)0.422172
(190, 1.4)(1100, 3.5)-179.867773
(190, 1.4)(500, 3.8)-179.556425
Мы видим явно рост точки вверх, а углы теперь отрицательные. Пиздец.
>>71146
Мне не нужна математика, епта. Мне нужен угол, блять! А годот его посчитать не может.
Мне не нужна математика, епта. Мне нужен угол, блять! А годот его посчитать не может.
>>71175 (Del)
Это и есть angle_to_point функция. И она не работает
Это и есть angle_to_point функция. И она не работает
>>71163
А пиздец в том, что человек, прогулявший матешу в свои 16цать, срёт на дваче, вместо того, чтобы курить матчасть до просветления.
https://docs.godotengine.org/ru/latest/tutorials/math/vector_math.html#introduction
> Пиздец.
А пиздец в том, что человек, прогулявший матешу в свои 16цать, срёт на дваче, вместо того, чтобы курить матчасть до просветления.
https://docs.godotengine.org/ru/latest/tutorials/math/vector_math.html#introduction
6 Кб, 236x202>>71203
Пятихатку мне на киви - а я в ответ готовый код.
Пятихатку мне на киви - а я в ответ готовый код.
>>71567 (Del)
Я как-то ебался с этим сортингом, ещё на 3.0.6., там столько подводных камней, что я плюнул и решил либо делать плоское двадэ без имитации тридэ, либо настоящее тридэ делать.
Я как-то ебался с этим сортингом, ещё на 3.0.6., там столько подводных камней, что я плюнул и решил либо делать плоское двадэ без имитации тридэ, либо настоящее тридэ делать.
2 Кб, 200x200>>71573 (Del)
Ну чё? Ну как? Я ж переживаю...
Ну чё? Ну как? Я ж переживаю...
9 Кб, 574x43Гуру, помогите разобраться с плавным передвежением камеры по сцене.
Есть два стула. Свободно двигать камеру по нажатию и двигать камеру по нажатию, цепляясь за ландшафт.
Стул первый.
Вроде всё просто. В абсолютном значении mouseMoveX(Y)Ratio - величина от 0 до 1, которая регулирует скорость от 0 до максимальной moveSpeed.
Знак mouseMoveX(Y)Ratio зависит от того, как изменяется положение мыши относительно момента, когда нажал сренюю кнопку.
Косяки начинаются, когда я верчу камеру. Чем ближе поворот камеры к 90 или -90 градусов, тем сильнее меняются верх-низ местами с право-лево. Должно быть тут надо как-то трансформ заварить, но у меня не получается.
Второй стул.
Есть идея цепляться за точку на поверхности, но тут вопрос, как плавно двигать камеру от текущей точки к точке зацепления.
Но этот вариант я даже не начинал. Как считать изменение позиции камеры относительно точки зацепления? Прямоугольными треугольниками?
Есть два стула. Свободно двигать камеру по нажатию и двигать камеру по нажатию, цепляясь за ландшафт.
Стул первый.
Вроде всё просто. В абсолютном значении mouseMoveX(Y)Ratio - величина от 0 до 1, которая регулирует скорость от 0 до максимальной moveSpeed.
Знак mouseMoveX(Y)Ratio зависит от того, как изменяется положение мыши относительно момента, когда нажал сренюю кнопку.
Косяки начинаются, когда я верчу камеру. Чем ближе поворот камеры к 90 или -90 градусов, тем сильнее меняются верх-низ местами с право-лево. Должно быть тут надо как-то трансформ заварить, но у меня не получается.
Второй стул.
Есть идея цепляться за точку на поверхности, но тут вопрос, как плавно двигать камеру от текущей точки к точке зацепления.
Но этот вариант я даже не начинал. Как считать изменение позиции камеры относительно точки зацепления? Прямоугольными треугольниками?
>>71736 (Del)
Вот тебе ещё лайфхак, замени
на
избавишься от лишнего преобразования буль-инт.
Вот тебе ещё лайфхак, замени
> int(Input.is_action_pressed("move_crouch"))
на
> Input.get_action_strength("move_crouch")
избавишься от лишнего преобразования буль-инт.
Как сделать, чтобы воспроизводилась анимация прыжка?
Суть проблемы в том, что когда персонаж прыгает, то не производится вся анимация, а лишь первый спрайт, как сделать чтобы воспроизводились все 4 спрайта? С анимацией ходьбы таких проблем нет.
Суть проблемы в том, что когда персонаж прыгает, то не производится вся анимация, а лишь первый спрайт, как сделать чтобы воспроизводились все 4 спрайта? С анимацией ходьбы таких проблем нет.
323 Кб, 1920x1080>>71747 (Del)
Если ты имеешь введу пикрил, то я так делал и ничего не поменялось.
Если ты имеешь введу пикрил, то я так делал и ничего не поменялось.
140 Кб, 680x273проходим товарищи бейкаем нестессняемся
https://www.youtube.com/watch?v=yQZKXdwyh-Q
https://www.kickstarter.com/projects/gdquest/learn-to-code-from-zero-with-godot-the-free-game-engine
https://www.youtube.com/watch?v=yQZKXdwyh-Q
https://www.kickstarter.com/projects/gdquest/learn-to-code-from-zero-with-godot-the-free-game-engine
706 Кб, 602x602>>73251
Так релиз курса весной 2022 а что всё это время делать? Не проще начать учить язык просто по урокам на ютубе, я вот только вкатываюсь и так планирую сделать, поседений месяц метался между годо и ГМ2, но вот все таки годо выбрал, хотя уже проебал две недели на гм2 после работки, сделал по урокам понг.
Так релиз курса весной 2022 а что всё это время делать? Не проще начать учить язык просто по урокам на ютубе, я вот только вкатываюсь и так планирую сделать, поседений месяц метался между годо и ГМ2, но вот все таки годо выбрал, хотя уже проебал две недели на гм2 после работки, сделал по урокам понг.
>>73682
просто проект пилится для калифорнийских бойчиков, которым будучи угашенным травой очень сложно начать напрягаться и учить, а тут няшная обучалка в игровой форме
от гугла (кажется) пазлы с кодом были подобные, к ним тоже игровую логику какого то известного тайтла прикручивали
а так все правильно сделал котей
>>73686 (Del)
па ху ю
> проще начать учить язык просто по урокам на ютубе
просто проект пилится для калифорнийских бойчиков, которым будучи угашенным травой очень сложно начать напрягаться и учить, а тут няшная обучалка в игровой форме
от гугла (кажется) пазлы с кодом были подобные, к ним тоже игровую логику какого то известного тайтла прикручивали
а так все правильно сделал котей
>>73686 (Del)
> C++ там не будет.
па ху ю
Плагин для реализации диалоговой системы.
Напоминаю. Пилить свой велосипед больше не нужно.
https://www.youtube.com/watch?v=xOqbZBL0V7A
Напоминаю. Пилить свой велосипед больше не нужно.
https://www.youtube.com/watch?v=xOqbZBL0V7A
>>71744
А если ему именно int нужен, а не float? У него вроде 2D.
>>71748 (Del)
Будет всё то же самое, что и с обычными кнопками.
get_action_strength() возвращает float от 0.0 до 1.0, независимо от того, какие кнопки ты назначил на action.
Если, например, написать так (явно объявить ожидаемый тип):
var number: Int = Input.get_action_strength("action")
Будет предупреждение о том, что происходит неявное преобразование из float в int, которое может привести к потере точности.
Во-первых, это называется "неявное приведение/преобразование". Неявное - потому что из кода не ясно, будет оно или нет, нужно смотреть документацию на компилятор/транслятор и/или смотреть код в другом месте (заголовки функций, объявление переменных). Явное - это когда ты прямо в коде пишешь запрос на преобразование (int(), float()).
Во-вторых, чтобы оно произошло (в GDScript), получатель результата этой функции должен явно указывать тип, который ему нужен. Это может быть указание типа переменной (как выше) или указание типа функции. На массивы это не распространяется - массив тут может хранить произвольный тип в каждой из ячеек (исключение - специальные классы Pool...Array). Если получателю безразличен тип данных, то он получит float от этой функции без преобразования.
>избавишься от лишнего преобразования буль-инт.
А если ему именно int нужен, а не float? У него вроде 2D.
>>71748 (Del)
>А что будет если там ось джойстика?
Будет всё то же самое, что и с обычными кнопками.
get_action_strength() возвращает float от 0.0 до 1.0, независимо от того, какие кнопки ты назначил на action.
Если, например, написать так (явно объявить ожидаемый тип):
var number: Int = Input.get_action_strength("action")
Будет предупреждение о том, что происходит неявное преобразование из float в int, которое может привести к потере точности.
>Автопреобразование
Во-первых, это называется "неявное приведение/преобразование". Неявное - потому что из кода не ясно, будет оно или нет, нужно смотреть документацию на компилятор/транслятор и/или смотреть код в другом месте (заголовки функций, объявление переменных). Явное - это когда ты прямо в коде пишешь запрос на преобразование (int(), float()).
Во-вторых, чтобы оно произошло (в GDScript), получатель результата этой функции должен явно указывать тип, который ему нужен. Это может быть указание типа переменной (как выше) или указание типа функции. На массивы это не распространяется - массив тут может хранить произвольный тип в каждой из ячеек (исключение - специальные классы Pool...Array). Если получателю безразличен тип данных, то он получит float от этой функции без преобразования.
>>73796
Он на дельту умножает. Дельта уже флоат, итог будет флоат энивей.
А это неважно.
> А если ему именно int нужен, а не float?
Он на дельту умножает. Дельта уже флоат, итог будет флоат энивей.
> У него вроде 2D.
А это неважно.
>>73796
типов аргументов функции
>>73800
Я думал, это отдельное выражение, там знака между ними нет.
В смысле? Если делать pixel perfect 2D, то все координаты должны быть целыми...
>>72006
В вормсах другой террейн. В вормсах сравнение попиксельное или с использованием сжатия RLE:
https://gamedev.stackexchange.com/questions/158906/destructible-terrain-like-worms
Террейн на полигонах, конечно, заманчивый, но у него куча подводных камней.
>указание типа функции
типов аргументов функции
>>73800
>Он на дельту умножает
Я думал, это отдельное выражение, там знака между ними нет.
>А это неважно.
В смысле? Если делать pixel perfect 2D, то все координаты должны быть целыми...
>>72006
>как в вормсах
В вормсах другой террейн. В вормсах сравнение попиксельное или с использованием сжатия RLE:
https://gamedev.stackexchange.com/questions/158906/destructible-terrain-like-worms
Террейн на полигонах, конечно, заманчивый, но у него куча подводных камней.
>>73810 (Del)
Ну и?
Допустим, у нас такое выражение:
Если управляем клавишами:
Если управляем джойстиком:
То есть в случае управления с клавиатуры, персонаж резко начинает двигаться на максимальной скорости (если мы не добавим сглаживание движений), а в случае управления с джойстика, персонаж двигается настолько плавно и на той скорости, насколько и которую хочет игрок. Наклоняешь грибок на 50% - получаешь половину скорости, наклоняешь на 75% - 3/4 скорости и т.д.
Кстати, я этим летом делал виртуальный джойстик, управляемый одной только мышью. Получилось, по-моему, круто, но я забил на проект, т.к. не люблю 2D и вообще в депрессии был. Просто мой китайский геймпад имеет хреновые стики, и мне хотелось почувствовать, каково это - управлять с хорошего джойстика.
>Ось джойстика это именно ось с плавными значениями.
Ну и?
Допустим, у нас такое выражение:
>translation.x += speed x delta x (Input.get_action_strength("move_forward") - Input.get_action_strength("move_backward"))
Если управляем клавишами:
>100 x 0.01667 x (1 - 0) = 1.667 пикселя за кадр x 60 = 100 пикселей в секунду
Если управляем джойстиком:
>100 x 0.01667 x (0.75 - 0) = 1.25 пикселя за кадр x 60 = 75 пикселей в секунду
То есть в случае управления с клавиатуры, персонаж резко начинает двигаться на максимальной скорости (если мы не добавим сглаживание движений), а в случае управления с джойстика, персонаж двигается настолько плавно и на той скорости, насколько и которую хочет игрок. Наклоняешь грибок на 50% - получаешь половину скорости, наклоняешь на 75% - 3/4 скорости и т.д.
Кстати, я этим летом делал виртуальный джойстик, управляемый одной только мышью. Получилось, по-моему, круто, но я забил на проект, т.к. не люблю 2D и вообще в депрессии был. Просто мой китайский геймпад имеет хреновые стики, и мне хотелось почувствовать, каково это - управлять с хорошего джойстика.
>>73844 (Del)
Всё он вкурил. Это ты не выкупаешь.
>>73815
Поэтому игра должна детектить устройство ввода, и своевременно переключать модель движения согласно действующему устройству ввода. Для геймпада - вышеописанный вариант. Для клавиатуры - интерполяция к максимальной/минимальной скорости, создающая видимость плавного разбега/остановки.
Всё он вкурил. Это ты не выкупаешь.
>>73815
Поэтому игра должна детектить устройство ввода, и своевременно переключать модель движения согласно действующему устройству ввода. Для геймпада - вышеописанный вариант. Для клавиатуры - интерполяция к максимальной/минимальной скорости, создающая видимость плавного разбега/остановки.
>>73850
И да, в настройках следует добавить опцию "спидран мод" которая лочит модель движения геймпада на клавиатуру. Иначе спидранеры сделают это самостоятельно сторонними тулзами. Зачем расстраивать посанов? Пусть себе спидранят на официальных настройках от девелопера.
И да, в настройках следует добавить опцию "спидран мод" которая лочит модель движения геймпада на клавиатуру. Иначе спидранеры сделают это самостоятельно сторонними тулзами. Зачем расстраивать посанов? Пусть себе спидранят на официальных настройках от девелопера.
>>73850
В чём проблема включить интерполяцию для всех способов ввода, включая джойстики? Дешёвые китайские джойстики нуждаются в интерполяции ничуть не меньше, чем клавиши. Да и на дорогих наверняка хотелось бы плавности, у пальцев-то неточные движения.
Я написал вариант без интерполяции только потому что его проще было написать по памяти.
>>73851
Вообще не понял про спидранеров, почему спидранерам нужна интерполяция? Интерполяция же замедляет разгон и торможение, то есть без неё можно сэкономить время прохождения.
>Для клавиатуры - интерполяция к максимальной/минимальной скорости
В чём проблема включить интерполяцию для всех способов ввода, включая джойстики? Дешёвые китайские джойстики нуждаются в интерполяции ничуть не меньше, чем клавиши. Да и на дорогих наверняка хотелось бы плавности, у пальцев-то неточные движения.
Я написал вариант без интерполяции только потому что его проще было написать по памяти.
>>73851
Вообще не понял про спидранеров, почему спидранерам нужна интерполяция? Интерполяция же замедляет разгон и торможение, то есть без неё можно сэкономить время прохождения.
Два дня мучился с одним вопросом, наконец решил сформулировать его в этом треде, и пока печатал, нашёл ответ на него. Всем спасибо, очень помогли, вопрос постить не буду, там многобукав.
inb4 https://en.wikipedia.org/wiki/Rubber_duck_debugging
inb4 https://en.wikipedia.org/wiki/Rubber_duck_debugging
>>66120 (OP)
Что это значит? iCalendar? Как с Годо связано?
Алсо, не одобряю просёр нумерации. Этот тред вроде 24, да? Почини нумерацию в следующем (25?) треде, а то неудобно получается.
Эта фича ещё в конце 2020 или самом начале 2021 (судя по веб архиву) сдохла, теперь даже упоминания на сайте нет - ты давно ссылки из шапки проверял?
Кстати, почему они от онлайн версии отказались? Слишком сложно поддерживать, наверное? Я год назад вроде пробовал запустить, чёт ничего не вышло. Что там было?
>ЯКАЛЕНДАРЬ EDITION
Что это значит? iCalendar? Как с Годо связано?
Алсо, не одобряю просёр нумерации. Этот тред вроде 24, да? Почини нумерацию в следующем (25?) треде, а то неудобно получается.
>Теперь прямо онлайн - можно и с дивана: >https://godotengine.org/online/godot.tools.html
>The requested page cannot be found
Эта фича ещё в конце 2020 или самом начале 2021 (судя по веб архиву) сдохла, теперь даже упоминания на сайте нет - ты давно ссылки из шапки проверял?
Кстати, почему они от онлайн версии отказались? Слишком сложно поддерживать, наверное? Я год назад вроде пробовал запустить, чёт ничего не вышло. Что там было?
>>73937
Чиво? Это какой-то мем?
>>73935 (Del)
Ясно, понятно, но ссылку давно пора обновить, она с начала года не работает, если верить веб архиву. За ~3 переката можно было много раз перепроверить.
Алсо, если тут
подразумевается мобильный браузер, то
Чиво? Это какой-то мем?
>>73935 (Del)
Ясно, понятно, но ссылку давно пора обновить, она с начала года не работает, если верить веб архиву. За ~3 переката можно было много раз перепроверить.
Алсо, если тут
>можно и с дивана
подразумевается мобильный браузер, то
>Mobile browsers are currently not supported.
Поясните за визуалскриптинг в вашем говне, кто-нибудь пользовался? Для каких задач подходит, если вообще подходит или это ради рофла сделано?
п.с. извините за говно
п.с. извините за говно
>>73961
Не пользовался. Я программист-любитель со средней школы и GDScript оказался очень простым и удобным, в отличие от C#. Встроенный редактор с подсветкой и автодополнением, а что ещё можно желать для кодинга?
Визуальные скрипты (вообще любые, не конкретно в Godot) могут быть удобны для маленьких детей, которые ещё не умеют печатать на клавиатуре, а для взрослых текст должен быть удобнее.
Есть какой-то аддон для визуальной разработки конечных автоматов, вот он теоретически может быть полезен, но я не пользовался.
Пиши документацию, тогда код не придётся мышкой таскать.
>визуалскриптинг
Не пользовался. Я программист-любитель со средней школы и GDScript оказался очень простым и удобным, в отличие от C#. Встроенный редактор с подсветкой и автодополнением, а что ещё можно желать для кодинга?
Визуальные скрипты (вообще любые, не конкретно в Godot) могут быть удобны для маленьких детей, которые ещё не умеют печатать на клавиатуре, а для взрослых текст должен быть удобнее.
Есть какой-то аддон для визуальной разработки конечных автоматов, вот он теоретически может быть полезен, но я не пользовался.
Пиши документацию, тогда код не придётся мышкой таскать.
1,3 Мб, 1280x723>>73946
ЯМЕГАФОН
ЯМЕГАФОН
Не могу понять, в чём проблема.
Есть ригидбоди. У него есть несколько колиженшейпов. Игрок добавляет новые колиженшейпы. Чтобы ригидбоди работал как мне нужно, его начало координат (0;0;0) должно совпадать с центром масс. Я вычисляю "центр масс" как среднее арифметическое позиций всех колиженшейпов. Затем смещаю все колиженшейпы на этот вектор, а сам ригидбоди - на обратный вектор. Происходит это всё однократно и только в _physics_process(), а для надёжности ригидбоди усыпляется на время смещения и пробуждается сразу после него.
Что я ожидаю? Что визуально ригидбоди останется на том же месте, где и был, но его масса станет более равномерной.
Что получается? Две ситуации:
1) Ригидбоди лежит в сцене изначально. Всё вышеописанное работает как и ожидается. Даже если его физически сдвинуть, повернуть или отбросить, всё будет работать как и ожидается (вроде бы).
2) Ригидбоди уничтожается, затем создаётся (instance()) заново, наполняется теми же колиженшейпами, что и были, падает и останавливается. Если теперь попытаться добавить ему ещё один колиженшейп, он начнёт сдвигаться в определённом направлении, хотя должен оставаться неподвижен. При этом смещаться может прямо внутрь препятствий, в которые при обычных условиях попасть не может - то есть это из-за моего смещения кодом, а не из-за ошибок физического движка (надеюсь).
Как такое может происходить? Я проверял через дебаггер сцену и трансформы, внутренние переменные этих ригидбоди. Всё выглядит нормально. Пробовал print() вектора, на который происходит смещение, но эти числа мне ни о чём не говорят - я не знаю, какими они должны быть, это сложно посчитать вручную.
В общем, куда копать, что делать? Проблема довольно раздражающая из-за своей непостоянности, то есть, то нет.
Есть ригидбоди. У него есть несколько колиженшейпов. Игрок добавляет новые колиженшейпы. Чтобы ригидбоди работал как мне нужно, его начало координат (0;0;0) должно совпадать с центром масс. Я вычисляю "центр масс" как среднее арифметическое позиций всех колиженшейпов. Затем смещаю все колиженшейпы на этот вектор, а сам ригидбоди - на обратный вектор. Происходит это всё однократно и только в _physics_process(), а для надёжности ригидбоди усыпляется на время смещения и пробуждается сразу после него.
Что я ожидаю? Что визуально ригидбоди останется на том же месте, где и был, но его масса станет более равномерной.
Что получается? Две ситуации:
1) Ригидбоди лежит в сцене изначально. Всё вышеописанное работает как и ожидается. Даже если его физически сдвинуть, повернуть или отбросить, всё будет работать как и ожидается (вроде бы).
2) Ригидбоди уничтожается, затем создаётся (instance()) заново, наполняется теми же колиженшейпами, что и были, падает и останавливается. Если теперь попытаться добавить ему ещё один колиженшейп, он начнёт сдвигаться в определённом направлении, хотя должен оставаться неподвижен. При этом смещаться может прямо внутрь препятствий, в которые при обычных условиях попасть не может - то есть это из-за моего смещения кодом, а не из-за ошибок физического движка (надеюсь).
Как такое может происходить? Я проверял через дебаггер сцену и трансформы, внутренние переменные этих ригидбоди. Всё выглядит нормально. Пробовал print() вектора, на который происходит смещение, но эти числа мне ни о чём не говорят - я не знаю, какими они должны быть, это сложно посчитать вручную.
В общем, куда копать, что делать? Проблема довольно раздражающая из-за своей непостоянности, то есть, то нет.
>>74101
Только что наконец-то исправил проблему! Причина обнаружилась в неочевидной разнице между translate() и прямым изменением transform.origin. Судя по всему, RigidBody каким-то особым образом работает со своим орижином, поэтому трогать его нельзя, но можно двигать через translate(). Т.е. заменил
на
И все "заикания" волшебным образом исчезли. Странно, ведь у остальных объектов можно менять орижин без таких последствий... Интересно, это моё личное непонимание ситуации и "так и задумано" или это всё-таки баг движка?
>>74105 (Del)
1. Всё так и есть, разумеется. Я ставлю флаг "откалибровать центр масс", а в _physics_process вызываю функцию калибровки, снимая флаг. Сделал так в т.ч. потому, что за один кадр может добавиться очень много новых блоков, и каждый ставит флаг, но калибровка происходит только раз за физический тик, если нужна.
2. Я думал об этом. Не пробовал, но мне кажется, что установка в статичный режим сбросит все скорости, т.о. ригидбоди застынет в пространстве и затем снова начнёт ускоряться. Я ведь не зря именно с ригидбоди работаю, мне нужно чтобы он свободно двигался.
3. У меня всего одна манипуляция за физический тик)
4. На самом деле ситуация с "ногой внутри пола" обрабатывается движком вполне ожидаемо: объект начинает трястись и медленно выдавливаться из пола, либо застревает в нём и трясётся. Это нормально и ожидаемо; избежать легко, если проверять коллизии добавляемого объекта и запрещать добавление, если он пересекает пол, стены и другие объекты. Но проблема была в том, что когда я крепил что-нибудь сбоку, объект мог сдвигаться в противоположную сторону, застревая в стене. Чуть с ума не сошёл, пытаясь найти причину.
5. Знаю, когда-то я баловался с этими силами и скоростями. Но это не то, смещение должно быть мгновенным и никак не влиять на происходящее движение (в идеале, конечно).
Только что наконец-то исправил проблему! Причина обнаружилась в неочевидной разнице между translate() и прямым изменением transform.origin. Судя по всему, RigidBody каким-то особым образом работает со своим орижином, поэтому трогать его нельзя, но можно двигать через translate(). Т.е. заменил
>transform.origin += delta
на
>translate(delta)
И все "заикания" волшебным образом исчезли. Странно, ведь у остальных объектов можно менять орижин без таких последствий... Интересно, это моё личное непонимание ситуации и "так и задумано" или это всё-таки баг движка?
>>74105 (Del)
1. Всё так и есть, разумеется. Я ставлю флаг "откалибровать центр масс", а в _physics_process вызываю функцию калибровки, снимая флаг. Сделал так в т.ч. потому, что за один кадр может добавиться очень много новых блоков, и каждый ставит флаг, но калибровка происходит только раз за физический тик, если нужна.
2. Я думал об этом. Не пробовал, но мне кажется, что установка в статичный режим сбросит все скорости, т.о. ригидбоди застынет в пространстве и затем снова начнёт ускоряться. Я ведь не зря именно с ригидбоди работаю, мне нужно чтобы он свободно двигался.
3. У меня всего одна манипуляция за физический тик)
4. На самом деле ситуация с "ногой внутри пола" обрабатывается движком вполне ожидаемо: объект начинает трястись и медленно выдавливаться из пола, либо застревает в нём и трясётся. Это нормально и ожидаемо; избежать легко, если проверять коллизии добавляемого объекта и запрещать добавление, если он пересекает пол, стены и другие объекты. Но проблема была в том, что когда я крепил что-нибудь сбоку, объект мог сдвигаться в противоположную сторону, застревая в стене. Чуть с ума не сошёл, пытаясь найти причину.
5. Знаю, когда-то я баловался с этими силами и скоростями. Но это не то, смещение должно быть мгновенным и никак не влиять на происходящее движение (в идеале, конечно).
>>74101
Кстати, оказалось, что усыплять ригидбоди вообще не нужно - можно спокойно крепить новые детали на движущийся ригидбоди и он не будет менять свою траекторию (вроде бы). А вот пробуждать после крепления нужно, потому что новые детали смещают центр масс, смещённый центр масс в теории может спровоцировать движение (наклонить, опрокинуть), но этого не происходит, если ригидбоди в режиме сна.
Ещё добавлю увеличение массы и вообще круто будет, а то сейчас большая конструкция из блоков слишком сильно реагирует на столкновение со всего одним блоком... выглядит так, будто добавление блоков уменьшает их массу. А блоки с разной массой будут смещать центр масс сильнее/слабее, вот это самая интересная часть - какой-нибудь парус сильно легче металлического двигателя, несмотря на больший размер.
>для надёжности ригидбоди усыпляется на время смещения
Кстати, оказалось, что усыплять ригидбоди вообще не нужно - можно спокойно крепить новые детали на движущийся ригидбоди и он не будет менять свою траекторию (вроде бы). А вот пробуждать после крепления нужно, потому что новые детали смещают центр масс, смещённый центр масс в теории может спровоцировать движение (наклонить, опрокинуть), но этого не происходит, если ригидбоди в режиме сна.
Ещё добавлю увеличение массы и вообще круто будет, а то сейчас большая конструкция из блоков слишком сильно реагирует на столкновение со всего одним блоком... выглядит так, будто добавление блоков уменьшает их массу. А блоки с разной массой будут смещать центр масс сильнее/слабее, вот это самая интересная часть - какой-нибудь парус сильно легче металлического двигателя, несмотря на больший размер.
>>74161 (Del)
Хотел тебе ответить и полез в документацию по апи движка, и нашёл ответ на мучавший меня вопрос:
https://docs.godotengine.org/en/stable/classes/class_spatial.html
То есть я получал в своём коде неактуальный origin и присваивал это неактуальное значение, чем вызывал рывки. Теоретически, вызов этой функции должен был бы помочь, но это лишние строчки кода - обратиться к translate оказалось проще и удобнее.
Кстати, о разнице между тем и этим:
Если я правильно понял, translate() принимает во внимание масштаб объекта, т.е. увеличенный в 2 раза объект будет смещаться на в 2 раза большее расстояние. Вроде логично. В то же время в Transform масштаб хранится в виде длины векторов basis, а origin - это отдельный вектор, поэтому если мы только меняем орижин, мы игнорируем масштаб объекта (но это стоит проверить на практике, а то я что-то сомневаюсь).
А мне, получается, translate() позволяет изменить актуальное смещение ригидбоди, а не то, что есть в орижине.
Хотел тебе ответить и полез в документацию по апи движка, и нашёл ответ на мучавший меня вопрос:
https://docs.godotengine.org/en/stable/classes/class_spatial.html
>void force_update_transform ( )
>Forces the transform to update. Transform changes in physics are not instant for performance reasons. Transforms are accumulated and then set. Use this if you need an up-to-date transform when doing physics operations.
То есть я получал в своём коде неактуальный origin и присваивал это неактуальное значение, чем вызывал рывки. Теоретически, вызов этой функции должен был бы помочь, но это лишние строчки кода - обратиться к translate оказалось проще и удобнее.
Кстати, о разнице между тем и этим:
>void translate ( Vector3 offset )
>Changes the node's position by the given offset Vector3.
>Note that the translation offset is affected by the node's scale, so if scaled by e.g. (10, 1, 1), a translation by an offset of (2, 0, 0) would actually add 20 (2 х 10) to the X coordinate.
Если я правильно понял, translate() принимает во внимание масштаб объекта, т.е. увеличенный в 2 раза объект будет смещаться на в 2 раза большее расстояние. Вроде логично. В то же время в Transform масштаб хранится в виде длины векторов basis, а origin - это отдельный вектор, поэтому если мы только меняем орижин, мы игнорируем масштаб объекта (но это стоит проверить на практике, а то я что-то сомневаюсь).
А мне, получается, translate() позволяет изменить актуальное смещение ригидбоди, а не то, что есть в орижине.
>>74206 (Del)
Странно. Но на практике он точно работает иначе простого обращения к origin. Возможно, где-то в другом месте стоит триггер на вызов транслейта.
Нет, конечно, я знаю, что менять масштаб ригидбоди нельзя.
Нет, только RigidBody в режимах Rigid и Character.
Всего у него четыре режима:
Rigid - нормальное состояние, в котором тело подвергается воздействию физических сил и может вращаться.
Static - аналог StaticBody.
Character - подвергается воздействию физических сил, но не может вращаться (персонаж не кувыркается).
Kinematic - аналог KinematicBody.
Я думаю, невозможность присвоить масштаб вызвана тем, что масштаб сильно усложнил бы вычисления физики (не коллизий, а вот эти все силы, ускорения и т.д.).
Если камень неподвижный (StaticBody), тогда масштаб изменить можно вроде бы. А если тебе нужен подвижный камень, тогда есть такой вариант: вешаешь скрипт на RigidBody, у скрипта export var custom_scale = Vector3(1.0, 1.0, 1.0), в функции скрипт меняет масштаб всех своих потомков. Да, в визуальном редакторе масштаб не будет отображаться, но такой способ должен быть удобен, если тебе нужно программно спавнить камни разных размеров. Создал камень - присвоил размер custom_scale - добавил в сцену.
>translate() тоже просто читает-записывает origin и никаких специальных путей кода с отложенной записью в нем нет.
Странно. Но на практике он точно работает иначе простого обращения к origin. Возможно, где-то в другом месте стоит триггер на вызов транслейта.
>А не менял ли ты масштаб самого rigidbody?
Нет, конечно, я знаю, что менять масштаб ригидбоди нельзя.
>это касается вообще любых объектов
Нет, только RigidBody в режимах Rigid и Character.
Всего у него четыре режима:
Rigid - нормальное состояние, в котором тело подвергается воздействию физических сил и может вращаться.
Static - аналог StaticBody.
Character - подвергается воздействию физических сил, но не может вращаться (персонаж не кувыркается).
Kinematic - аналог KinematicBody.
Я думаю, невозможность присвоить масштаб вызвана тем, что масштаб сильно усложнил бы вычисления физики (не коллизий, а вот эти все силы, ускорения и т.д.).
>ты хочешь поставить одинаковый ассет камня разных размеров, то тебе надо во втором реально менять коллижншейпы.
Если камень неподвижный (StaticBody), тогда масштаб изменить можно вроде бы. А если тебе нужен подвижный камень, тогда есть такой вариант: вешаешь скрипт на RigidBody, у скрипта export var custom_scale = Vector3(1.0, 1.0, 1.0), в функции скрипт меняет масштаб всех своих потомков. Да, в визуальном редакторе масштаб не будет отображаться, но такой способ должен быть удобен, если тебе нужно программно спавнить камни разных размеров. Создал камень - присвоил размер custom_scale - добавил в сцену.
>>74265 (Del)
Прекрасно! Давай зачётку.
Прекрасно! Давай зачётку.
Кто-нибудь может подсказать, нужно ли работать для камеры с углами эйлера или нужно преобразовать в кватернионы?
>>74767
Я в годоте работал с матрицей преобразования, так же известной в дереве классов годота как Transform. Не знаю, Эйлер ли это или кватернион? Но если тебе надо без задней мысли работать с камерой, просто построй из невидимых нод киношную вышку, или как она там правильно называется? Ну тоесть, воссоздай рабочее место оператора ИРЛ. Тебе понадобится в общем случае два шарнира класса Spatial, один ты будешь вращать вокруг вертикальной оси влево-вправо, второй вокруг поперечной оси вверх-вниз. В 90% туториалов предлагается делать так. В остальных 10% в зависимости от требований игоры может потребоваться покачивание вокруг продольной оси, а так же удаление и приближение по ней же.
А так же в новые версии движка завезли автоотдаляющуюся камеру.
Я в годоте работал с матрицей преобразования, так же известной в дереве классов годота как Transform. Не знаю, Эйлер ли это или кватернион? Но если тебе надо без задней мысли работать с камерой, просто построй из невидимых нод киношную вышку, или как она там правильно называется? Ну тоесть, воссоздай рабочее место оператора ИРЛ. Тебе понадобится в общем случае два шарнира класса Spatial, один ты будешь вращать вокруг вертикальной оси влево-вправо, второй вокруг поперечной оси вверх-вниз. В 90% туториалов предлагается делать так. В остальных 10% в зависимости от требований игоры может потребоваться покачивание вокруг продольной оси, а так же удаление и приближение по ней же.
А так же в новые версии движка завезли автоотдаляющуюся камеру.
Ребята я что календарь?
>>74820 (Del)
Да я нашел у них в пособии, что лучше юзать кватернионы. Я просто понял, что если тупо юзать матрицу преобразований, то там траблы выходят, что при движении одной оси двигаются другие и как бы угол уже не тот выходит, когда вращаем некс ось. Плюс там при определенных положениях может возникнуть ситуация, что степень свободы можем потерять, т.е вращаться только по одной оси.
Да я нашел у них в пособии, что лучше юзать кватернионы. Я просто понял, что если тупо юзать матрицу преобразований, то там траблы выходят, что при движении одной оси двигаются другие и как бы угол уже не тот выходит, когда вращаем некс ось. Плюс там при определенных положениях может возникнуть ситуация, что степень свободы можем потерять, т.е вращаться только по одной оси.
>>74785
Вообще Transform, там комбинация Basis и origin. Ну в Basis походу перемножение scale и rotation. А вот orgion будто бы просто добавлена строка и все. Rotation задается виде матрицы с векторами 3х3. Т.е по идеи если я домножу эту матрицу вращения, то получу углы эйлера.
Вообще Transform, там комбинация Basis и origin. Ну в Basis походу перемножение scale и rotation. А вот orgion будто бы просто добавлена строка и все. Rotation задается виде матрицы с векторами 3х3. Т.е по идеи если я домножу эту матрицу вращения, то получу углы эйлера.
>>74820 (Del)
Так там ведь просто RigidBody.add_force() юзать и всё, зачем тебе что-то вручную поворачивать?
>>74834
Суть в том, что нужно соблюдать порядок вращения. Сначала по одной оси, потом по другой, если наоборот - выйдет не то, что ты ожидал. Да и за направлением вращения следить надо. В мануале пишут, что от обоих этих проблем можно избавиться, юзая кватернионы, но для большинства простых игр хватит повесить камеру на одну/две вложенные ноды или SpringArm.
https://docs.godotengine.org/en/stable/classes/class_springarm.html
>подумываю о флайтсиме
Так там ведь просто RigidBody.add_force() юзать и всё, зачем тебе что-то вручную поворачивать?
>>74834
Суть в том, что нужно соблюдать порядок вращения. Сначала по одной оси, потом по другой, если наоборот - выйдет не то, что ты ожидал. Да и за направлением вращения следить надо. В мануале пишут, что от обоих этих проблем можно избавиться, юзая кватернионы, но для большинства простых игр хватит повесить камеру на одну/две вложенные ноды или SpringArm.
https://docs.godotengine.org/en/stable/classes/class_springarm.html
>>74934 (Del)
Тебя интересует, как сохранять вертикальную ориентацию камеры, когда самолёт наклоняется? Тоже планирую делать что-то вроде авиасимулятора на минималках.
>>74959
SpringArm - это не костыль, это встроенное решение, позволяющее не городить самодельный рейкаст и код для приближения камеры. Во всех играх от третьего лица камера должна приближаться к персонажу, когда сталкивается с препятствиями или когда препятствия встают между камерой и персонажем, иначе игроку будет неудобно и он может увидеть скрытые объекты сквозь стены. Так что радоваться надо, что такой "костыль" есть в Годо из коробки.
Примерно год назад пилил-пилил свой велосипед, потом узнал про SpringArm и половину кода выкинул, лол.
>Обзор камеры
Тебя интересует, как сохранять вертикальную ориентацию камеры, когда самолёт наклоняется? Тоже планирую делать что-то вроде авиасимулятора на минималках.
>>74959
>костыль
SpringArm - это не костыль, это встроенное решение, позволяющее не городить самодельный рейкаст и код для приближения камеры. Во всех играх от третьего лица камера должна приближаться к персонажу, когда сталкивается с препятствиями или когда препятствия встают между камерой и персонажем, иначе игроку будет неудобно и он может увидеть скрытые объекты сквозь стены. Так что радоваться надо, что такой "костыль" есть в Годо из коробки.
Примерно год назад пилил-пилил свой велосипед, потом узнал про SpringArm и половину кода выкинул, лол.
>>66120 (OP)
Посоветуйте что ли по чарактерконтроллеру. У меня есть на основе кинематикбоди, сам сделал кое-как. На статичном ландшафте работает более-менее приемлемо, но у меня в игре подвижные конструкции на основе ригидбоди, движутся с помощью add_force(). В общем, персонаж вроде как немного мешает движению ригидбоди, когда ригидбоди поднимается вверх (но не сильно), но хуже всего то, что персонаж немного остаёт от ригидбоди при движении вниз. Алсо давно заметил, что мой персонаж падает быстрее любых ригидбоди... Это всё можно как-то пофиксить, оставаясь на кинематикбоди, или нужно обязательно переписывать чарактерконтроллер на ригидбоди? Я просто уже несколько раз туда-сюда перекатывался за последние пару лет, я уже не знаю что делать, и там и там косяки вылезают (помню, ригидбоди персонаж расшвыривал другие ригидбоди как будто они ничего не весят, да ещё и проблемы были с определением пола, короче ну нафиг).
Алсо хочется в будущем сделать регдолл, посоветуйте, нужно ли к этому как-то специально готовиться? В плане адаптации чарактерконтроллера под это дело. Кинематикбоди не помешает же?
Посоветуйте что ли по чарактерконтроллеру. У меня есть на основе кинематикбоди, сам сделал кое-как. На статичном ландшафте работает более-менее приемлемо, но у меня в игре подвижные конструкции на основе ригидбоди, движутся с помощью add_force(). В общем, персонаж вроде как немного мешает движению ригидбоди, когда ригидбоди поднимается вверх (но не сильно), но хуже всего то, что персонаж немного остаёт от ригидбоди при движении вниз. Алсо давно заметил, что мой персонаж падает быстрее любых ригидбоди... Это всё можно как-то пофиксить, оставаясь на кинематикбоди, или нужно обязательно переписывать чарактерконтроллер на ригидбоди? Я просто уже несколько раз туда-сюда перекатывался за последние пару лет, я уже не знаю что делать, и там и там косяки вылезают (помню, ригидбоди персонаж расшвыривал другие ригидбоди как будто они ничего не весят, да ещё и проблемы были с определением пола, короче ну нафиг).
Алсо хочется в будущем сделать регдолл, посоветуйте, нужно ли к этому как-то специально готовиться? В плане адаптации чарактерконтроллера под это дело. Кинематикбоди не помешает же?
Как чекнуть, что игра уже запущена? Делаю типа сетевой, а если запустить дохуя одинаковых экзешников на одной машине, то можно нихуёво ботоводить, нужно пофиксить.
>>75259
Кеклол, в современном мире под одним внешним v4 айпи могут сидеть сотни пользователей, а у v6 покрытие мизерное, по сути он практически не используется ещё. Теоретически можно чекать внутренние айпи, но откуда тебе знать, что там конкретный провайдер Сычов Тырнет накрутил в своей сети?
>>75255
Забей, во всех ММО ботоводят, в некоторых это даже поощряется вроде как. Лучшее, что можно сделать - стимулировать игрока играть только одним персонажем, не давать преимуществ игроку с несколькими персонажами. К примеру, запретить свободную передачу предметов между персонажами, а за игру соло давать существенный бонус опыта, чтобы не было желания водить хороводы.
>>75260 (Del)
Можно сделать проще: игра создаёт файл, открывает его на чтение/запись и держит открытым. Если её копия попытается получить доступ к тому же файлу, то получит ошибку доступа и должна закрыться. Если пользователь найдёт этот файл и попытается удалить или переименовать, то получит ошибку доступа. Если пользователь обойдёт блокировку файла, то оригинальная игра должна заметить пропажу файла и принять соответствующие меры (специальный флаг на аккаунт или бан). Но это не решает проблемы куллхацкера, который изменяет имя файла в данных игры (зная имя файла сделать это несложно, если exe не проверяется хэш-суммой). Также это не решает проблемы эмуляторов ОС... Вариант с сервером вроде бы тоже не защищает от эмулятора ОС, т.к. все сервера будут на независимых виртуальных машинах. Т.е. кто ищет способ запустить бота, обязательно его найдёт.
https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-findwindowa
>чекай айпишки
Кеклол, в современном мире под одним внешним v4 айпи могут сидеть сотни пользователей, а у v6 покрытие мизерное, по сути он практически не используется ещё. Теоретически можно чекать внутренние айпи, но откуда тебе знать, что там конкретный провайдер Сычов Тырнет накрутил в своей сети?
>>75255
>Делаю типа сетевой, а если запустить дохуя одинаковых экзешников на одной машине, то можно нихуёво ботоводить, нужно пофиксить.
Забей, во всех ММО ботоводят, в некоторых это даже поощряется вроде как. Лучшее, что можно сделать - стимулировать игрока играть только одним персонажем, не давать преимуществ игроку с несколькими персонажами. К примеру, запретить свободную передачу предметов между персонажами, а за игру соло давать существенный бонус опыта, чтобы не было желания водить хороводы.
>>75260 (Del)
>запускаешь сервер на этом порту, который ждет запрос
Можно сделать проще: игра создаёт файл, открывает его на чтение/запись и держит открытым. Если её копия попытается получить доступ к тому же файлу, то получит ошибку доступа и должна закрыться. Если пользователь найдёт этот файл и попытается удалить или переименовать, то получит ошибку доступа. Если пользователь обойдёт блокировку файла, то оригинальная игра должна заметить пропажу файла и принять соответствующие меры (специальный флаг на аккаунт или бан). Но это не решает проблемы куллхацкера, который изменяет имя файла в данных игры (зная имя файла сделать это несложно, если exe не проверяется хэш-суммой). Также это не решает проблемы эмуляторов ОС... Вариант с сервером вроде бы тоже не защищает от эмулятора ОС, т.к. все сервера будут на независимых виртуальных машинах. Т.е. кто ищет способ запустить бота, обязательно его найдёт.
>Можно посмотреть просто средствами винды (чет то там про ProcessName)
https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-findwindowa
>>75286
Вот да, думаю в том же направлении.
Просто держать на пеке файл, который будет говорить каждому новому экзешнику, что игра-то уже запущена. + добавлю мб проверку на сервере, должно хватить.
>Можно сделать проще
Вот да, думаю в том же направлении.
Просто держать на пеке файл, который будет говорить каждому новому экзешнику, что игра-то уже запущена. + добавлю мб проверку на сервере, должно хватить.
Хотя я пилю игру под Steam, думал у них встроенный запрет на множественный запуск одной игры, но проверил и оказалось, что не так.
>>75409
При чём тут мьютексы и семафоры? Они же регулируют потоки внутри приложения, а не сторонние приложения? Задача анона стоит как "не допустить запуск второго экземпляра приложения". Решение с файлом подразумевает использование особенности ОС, которая не позволяет двум приложениям одновременно работать с одним и тем же файлом в файловой системе.
Приложение 1 открывает файл "файл" на запись.
ОС блокирует доступ к "файл" для остальных приложений.
Приложение 2 пытается открыть "файл" на запись.
ОС сообщает код ошибки: "доступ запрещён".
Приложение 2 получает код и завершает свою работу.
Приложение 1 завершает работу, закрывает файл.
ОС разблокирует доступ к "файл" для приложений.
Приложение 1 или 2 можно снова запустить.
Итого мы можем иметь только 1 или 2, но не оба сразу. Но это не решает проблемы виртуальной машины, у которой отдельная файловая система и которая не знает о существовании соседних виртуальных машин.
>>75358
Может, нужно где-то в настройках включить? Или воспользоваться фичами из АПИ Стима. Потому что обычно игры из Стима автоматически запускают Стим перед своим запуском, может, там в апи есть какой-то интерфейс для теста типа "играет ли пользователь в эту игру"?
При чём тут мьютексы и семафоры? Они же регулируют потоки внутри приложения, а не сторонние приложения? Задача анона стоит как "не допустить запуск второго экземпляра приложения". Решение с файлом подразумевает использование особенности ОС, которая не позволяет двум приложениям одновременно работать с одним и тем же файлом в файловой системе.
Приложение 1 открывает файл "файл" на запись.
ОС блокирует доступ к "файл" для остальных приложений.
Приложение 2 пытается открыть "файл" на запись.
ОС сообщает код ошибки: "доступ запрещён".
Приложение 2 получает код и завершает свою работу.
Приложение 1 завершает работу, закрывает файл.
ОС разблокирует доступ к "файл" для приложений.
Приложение 1 или 2 можно снова запустить.
Итого мы можем иметь только 1 или 2, но не оба сразу. Но это не решает проблемы виртуальной машины, у которой отдельная файловая система и которая не знает о существовании соседних виртуальных машин.
>>75358
Может, нужно где-то в настройках включить? Или воспользоваться фичами из АПИ Стима. Потому что обычно игры из Стима автоматически запускают Стим перед своим запуском, может, там в апи есть какой-то интерфейс для теста типа "играет ли пользователь в эту игру"?
Кто работал с этим:
https://docs.godotengine.org/en/stable/classes/class_physicsserver.html
Подскажите, насколько хорошо использование этого сервера оптимизирует сцены с большим количеством коллиженшейпов на небольшом количестве объектов? В частности всего несколько статикбоди и несколько ригидбоди, но у них может быть очень большое количество шейпов, которые могут добавляться и удаляться динамически. Хочу прикинуть, на сколько сотен/тысяч шейпов я могу рассчитывать на своём древнем ПК. Прототип на нодах уже работает и пока не лагает, если не спавнить слишком много шейпов, но мне нужно прикинуть перспективы масштабирования.
https://docs.godotengine.org/en/stable/classes/class_physicsserver.html
Подскажите, насколько хорошо использование этого сервера оптимизирует сцены с большим количеством коллиженшейпов на небольшом количестве объектов? В частности всего несколько статикбоди и несколько ригидбоди, но у них может быть очень большое количество шейпов, которые могут добавляться и удаляться динамически. Хочу прикинуть, на сколько сотен/тысяч шейпов я могу рассчитывать на своём древнем ПК. Прототип на нодах уже работает и пока не лагает, если не спавнить слишком много шейпов, но мне нужно прикинуть перспективы масштабирования.
>>75610 (Del)
Игра-то есть? Или опять преждевременной оптимизацией несуществующей игоры занимаемся? В гдскрипте ящитаю выигрыша не будет по сравнению с искаробочными классами-хелперами. Если бы у тебя была игра и тебе нужно было её оптимизировать, ты бы написал модуль на крестах, реализующий пул коллижншейпов и пересобрал бы движок со своим модулем.
> пул коллижнов сделать
Игра-то есть? Или опять преждевременной оптимизацией несуществующей игоры занимаемся? В гдскрипте ящитаю выигрыша не будет по сравнению с искаробочными классами-хелперами. Если бы у тебя была игра и тебе нужно было её оптимизировать, ты бы написал модуль на крестах, реализующий пул коллижншейпов и пересобрал бы движок со своим модулем.
>>75611 (Del)
Ты сделал 7 ошибок в слове "клевета", анон.
>>75610 (Del)
По-моему, эта функция делает то же самое, что ты делаешь вручную, когда добавляешь ноду CollisionShape к ноде Area.
Мне не пул нужен, а собрать одну большую физическую модель из множества шейпов в процессе игры. Не ясно только, на сколько шейпов я могу рассчитывать, прежде чем всё начнёт лагать.
Прост раньше пробовал чисто на дерево инстанциировать отдельные статикбоди с простыми шеймпами и всё дико лагало после нескольких десятков тысяч нод в дереве (более 40k). Я знаю, что дерево сильно замедляет работу, но сомневаюсь в эффективности "серверов", а на них работать всё-таки значительно сложнее, чем с деревом сцены. Щас напишу огромный велосипед, а вдруг прирост производительности будет +5 фпс, ну нафиг такое.
Алсо не совсем понятно, что лучше - несколько статикбоди с десятками шейпов или один статикбоди с сотнями шейпов? Они же так и так не двигаются, можно склеить...
>Шютка
Ты сделал 7 ошибок в слове "клевета", анон.
>Клевета — заведомо ложная порочащая информация или распространение заведомо ложных сведений, порочащих честь и достоинство другого лица или подрывающих его репутацию.
>>75610 (Del)
>area_set_shape
По-моему, эта функция делает то же самое, что ты делаешь вручную, когда добавляешь ноду CollisionShape к ноде Area.
>пул коллижнов
Мне не пул нужен, а собрать одну большую физическую модель из множества шейпов в процессе игры. Не ясно только, на сколько шейпов я могу рассчитывать, прежде чем всё начнёт лагать.
Прост раньше пробовал чисто на дерево инстанциировать отдельные статикбоди с простыми шеймпами и всё дико лагало после нескольких десятков тысяч нод в дереве (более 40k). Я знаю, что дерево сильно замедляет работу, но сомневаюсь в эффективности "серверов", а на них работать всё-таки значительно сложнее, чем с деревом сцены. Щас напишу огромный велосипед, а вдруг прирост производительности будет +5 фпс, ну нафиг такое.
Алсо не совсем понятно, что лучше - несколько статикбоди с десятками шейпов или один статикбоди с сотнями шейпов? Они же так и так не двигаются, можно склеить...
338 Кб, 1440x850>>75624
Игры нет, но есть несколько прототипов, в одном из которых я ощутил довление со стороны дерева сцены, но узнав сложности работы с серверами как-то приуныл и сдулся. Теперь я думаю, а что было бы, если бы я переписал всё на сервера? Вдруг фпс подскочил бы до небес и я бы смог на одну такую карту в сотню раз больше контента накидать, а не оставлять недоделанные тестовые кубы.
Если что, я пробовал сделать чанковую систему. Проблема в том, что добавление/удаление чанков в/с дерева сцены создаёт ещё более сильные тормоза, чем само существование нескольких десятков тысяч нод. Непонятно, будут ли такие же тормоза в чанковой системе на основе серверов или нет.
Я видел чей-то проект на базе серверов годо, но там чувак хвастался тем, что с самого начала делал на серверах, поэтому никакой сравнительной статистики у него нет. Да и проект у него, гм, с видом сверху, т.е. обзор камеры ограничен очень малым числом объектов (непонятно зачем ему вообще сервера понадобились).
>Игра-то есть? Или опять преждевременной оптимизацией несуществующей игоры занимаемся?
Игры нет, но есть несколько прототипов, в одном из которых я ощутил довление со стороны дерева сцены, но узнав сложности работы с серверами как-то приуныл и сдулся. Теперь я думаю, а что было бы, если бы я переписал всё на сервера? Вдруг фпс подскочил бы до небес и я бы смог на одну такую карту в сотню раз больше контента накидать, а не оставлять недоделанные тестовые кубы.
Если что, я пробовал сделать чанковую систему. Проблема в том, что добавление/удаление чанков в/с дерева сцены создаёт ещё более сильные тормоза, чем само существование нескольких десятков тысяч нод. Непонятно, будут ли такие же тормоза в чанковой системе на основе серверов или нет.
Я видел чей-то проект на базе серверов годо, но там чувак хвастался тем, что с самого начала делал на серверах, поэтому никакой сравнительной статистики у него нет. Да и проект у него, гм, с видом сверху, т.е. обзор камеры ограничен очень малым числом объектов (непонятно зачем ему вообще сервера понадобились).
>>75631 (Del)
Эксперты в суде разберутся без твоей подсказки))((
Оригинальное слово scammer по правилам английского языка с двойной m, слова scamer в английском не существует, а в русском многие забывают или ленятся удваивать согласные и со временем заимствованное слово может потерять одну согласную. Но, тем не менее, оба варианта слова в народе означают "мошенник".
Я понимаю, что ты так пошутил, но шутка неуместная и тупая. Уровня школьников, которые смеются над Миссисипи и другими Телепорно.
>>75623
А ты токсик-борд не видел, похоже.
>Скамер != скаммер.
Эксперты в суде разберутся без твоей подсказки))((
Оригинальное слово scammer по правилам английского языка с двойной m, слова scamer в английском не существует, а в русском многие забывают или ленятся удваивать согласные и со временем заимствованное слово может потерять одну согласную. Но, тем не менее, оба варианта слова в народе означают "мошенник".
Я понимаю, что ты так пошутил, но шутка неуместная и тупая. Уровня школьников, которые смеются над Миссисипи и другими Телепорно.
>>75623
>токсик-борда
А ты токсик-борд не видел, похоже.
>>75628
Я не знаю. Вроде многопотоки надо лепить с мьютексами и семафорами. Иначе я ХЗ какую надо слепить чорную магию пиксельговгину в окне 400х300 отскейленном чтобы запилить в одном потоке динамический опенворлд.
> довление со стороны дерева сцены
> тормоза в чанковой системе
Я не знаю. Вроде многопотоки надо лепить с мьютексами и семафорами. Иначе я ХЗ какую надо слепить чорную магию пиксельговгину в окне 400х300 отскейленном чтобы запилить в одном потоке динамический опенворлд.
>>75648
Какие там многопотоки, дерево сцены работает в одном потоке. Сильные тормоза возникают из-за, как минимум:
- обхода дерева движком каждый кадр;
- добавления новых нод в дерево (add_child());
- удаления нод из дерева (remove_child()).
Чтобы избавиться от этой проблемы, в движке есть АПИ для прямой работы с серверами (графическим, физическим и т.д.). Ты можешь отправить какие-то данные на сервер и не теребонькать дерево сцены. Но работа с сервером сложнее работы с деревом сцены, поэтому применять их нужно только когда в этом есть необходимость. Вот я и пытаюсь понять, насколько выгодно их использовать, а то вдруг прирост производительности +1%, зачем мне он...
Графика вообще проблемы не составляет, у меня и 5+ миллионов вершин на экране было и ничего не тормозило (75 фпс), а тут >>75628, как видишь, меньше миллиона вершин, но фпс просел до 3, потому что 88к нод в сцене.
Ладно, я всё понял, тут никто опенворлды не делает, придётся самому на практике выяснять, насколько выгодны сервера.
>Вроде многопотоки надо лепить с мьютексами и семафорами
Какие там многопотоки, дерево сцены работает в одном потоке. Сильные тормоза возникают из-за, как минимум:
- обхода дерева движком каждый кадр;
- добавления новых нод в дерево (add_child());
- удаления нод из дерева (remove_child()).
Чтобы избавиться от этой проблемы, в движке есть АПИ для прямой работы с серверами (графическим, физическим и т.д.). Ты можешь отправить какие-то данные на сервер и не теребонькать дерево сцены. Но работа с сервером сложнее работы с деревом сцены, поэтому применять их нужно только когда в этом есть необходимость. Вот я и пытаюсь понять, насколько выгодно их использовать, а то вдруг прирост производительности +1%, зачем мне он...
>пиксельговгину в окне 400х300 отскейленном
Графика вообще проблемы не составляет, у меня и 5+ миллионов вершин на экране было и ничего не тормозило (75 фпс), а тут >>75628, как видишь, меньше миллиона вершин, но фпс просел до 3, потому что 88к нод в сцене.
Ладно, я всё понял, тут никто опенворлды не делает, придётся самому на практике выяснять, насколько выгодны сервера.
>>75703
Если ты такой крутой, то лепи свой собственный майнлуп без дерева сцены вообще.
https://docs.godotengine.org/ru/stable/classes/class_mainloop.html
Если ты такой крутой, то лепи свой собственный майнлуп без дерева сцены вообще.
https://docs.godotengine.org/ru/stable/classes/class_mainloop.html
>>75705
Зачем? В прошлом пробовал писать движок с нуля, бросил и перешёл на готовый движок, только чтобы снова писать с нуля?
Дерево сцены удобно для многих задач. Но не справляется с большим количеством объектов (десятки тысяч). Обычно в таких случаях используют сервера...
>>75704 (Del)
Хм... Попробую.
Зачем? В прошлом пробовал писать движок с нуля, бросил и перешёл на готовый движок, только чтобы снова писать с нуля?
Дерево сцены удобно для многих задач. Но не справляется с большим количеством объектов (десятки тысяч). Обычно в таких случаях используют сервера...
>>75704 (Del)
Хм... Попробую.
>>75711
Свой майнлуп в готовом движке проще, чем свой движок и сложнее, чем чужой готовый майнлуп. Это типа нечто среднее. У тебя остаются серверы и менеджеры ресурсов. Вся инфраструктура годота остаётся. Только майнлуп твой.
Вместо дерева сцены менеджер сцены, который ты можешь сделать... эммм... деревом.
> Зачем? В прошлом пробовал писать движок с нуля, бросил и перешёл на готовый движок
Свой майнлуп в готовом движке проще, чем свой движок и сложнее, чем чужой готовый майнлуп. Это типа нечто среднее. У тебя остаются серверы и менеджеры ресурсов. Вся инфраструктура годота остаётся. Только майнлуп твой.
Вместо дерева сцены менеджер сцены, который ты можешь сделать... эммм... деревом.
>>75716
У нас всегда так. Либо душно, либо токсично.
У нас всегда так. Либо душно, либо токсично.
>>75726
В чем он не прав?
В чем он не прав?
>>75726
Ну это всё понятно, но я делаю 3Д и мне нужно изкоробочное дерево сцены для таких вещей, как, например, персонажи. Дерево мешает только с большим количеством однотипных простых элементов, например, модули генерируемого ландшафта или модули сборных построек. Т.к. модули в большинстве своём тупые, тратить на них ноды нерационально, а их потенциально огромное количество перегружает дерево сцены.
Пару часов назад сделал тест на обычной сцене. Результат неожиданный - добавление коллиженшейпов в один статикбоди нагружает игру намного сильнее, чем создание того же количества статикбоди с одиночными шейпами (в обоих случаях ещё добавляются меши с материалом и текстурой). Как я понял, буллет начинает серьёзно тормозить после 1000 шейпов на одном боди, а вот дерево сцены тормозит у меня примерно после 20-30 нод, то есть в простейшем случае без тормозов (~75 фпс) можно иметь 10к статикбоди или менее 15к коллиженшейпов на одном статикбоди, но чтобы достичь второго варианта, придётся убить уйму времени (где-то полчаса) на пропихивание коллиженшейпов в статикбоди. И это я даже не пытался ничего на них сбрасывать, просто камеру крутил. Хорошо, что я не начал реализовывать второй способ в игре (ну как "не начал", он уже реализован, но только для ригидбоди).
Глянул как юзать сервера... для статикбоди должно быть несложно, жаль, что с ригидбоди получится хрень - нужно вручную передавать трансформы из физиксервера в визуалсервер. Почему так-то? Я ожидал чего-то вроде link(body, mesh) и дальше пусть оно само повторяет трансформы. Сомневаюсь что есть какая-то большая польза от того, что все боди по умолчанию невидимые.
Хе-хе, щас как напишу оболочку для обращения к серверам и снова буду абстрагирован от всех этих низкоуровневых апи)
Ну это всё понятно, но я делаю 3Д и мне нужно изкоробочное дерево сцены для таких вещей, как, например, персонажи. Дерево мешает только с большим количеством однотипных простых элементов, например, модули генерируемого ландшафта или модули сборных построек. Т.к. модули в большинстве своём тупые, тратить на них ноды нерационально, а их потенциально огромное количество перегружает дерево сцены.
Пару часов назад сделал тест на обычной сцене. Результат неожиданный - добавление коллиженшейпов в один статикбоди нагружает игру намного сильнее, чем создание того же количества статикбоди с одиночными шейпами (в обоих случаях ещё добавляются меши с материалом и текстурой). Как я понял, буллет начинает серьёзно тормозить после 1000 шейпов на одном боди, а вот дерево сцены тормозит у меня примерно после 20-30 нод, то есть в простейшем случае без тормозов (~75 фпс) можно иметь 10к статикбоди или менее 15к коллиженшейпов на одном статикбоди, но чтобы достичь второго варианта, придётся убить уйму времени (где-то полчаса) на пропихивание коллиженшейпов в статикбоди. И это я даже не пытался ничего на них сбрасывать, просто камеру крутил. Хорошо, что я не начал реализовывать второй способ в игре (ну как "не начал", он уже реализован, но только для ригидбоди).
Глянул как юзать сервера... для статикбоди должно быть несложно, жаль, что с ригидбоди получится хрень - нужно вручную передавать трансформы из физиксервера в визуалсервер. Почему так-то? Я ожидал чего-то вроде link(body, mesh) и дальше пусть оно само повторяет трансформы. Сомневаюсь что есть какая-то большая польза от того, что все боди по умолчанию невидимые.
Хе-хе, щас как напишу оболочку для обращения к серверам и снова буду абстрагирован от всех этих низкоуровневых апи)
>>75789 (Del)
У меня несколько заготовок, эти две самые серьёзные:
1. GTA-like с генерируемыми городами. Есть базовый генератор карты островного типа из модулей 24х24 метра, есть система чанков. Проблема: все объекты на нодах, число нод растёт очень быстро, из-за этого даже "голая" карта достаточного размера тормозит, но если применять выгрузку и загрузку чанков во время движения игрока, тормоза становятся ещё сильнее - операции по извлечению нод из сцены дороже, чем хранение их в сцене. В общем, я испугался сложности необходимых оптимизаций (серверы) и отложил проект в долгий ящик (уже который раз за последние ~13 лет).
2. Игра про летающие острова и строительство летающих кораблей. Есть базовый прототип строительства на нодах - компоненты на базе CollisionShape соединяются с кораблём-RigidBody, конструкция правдоподобно летает, можно достраивать прямо в полёте. Острова планируется генерировать по тому же принципу, что и города из предыдущего прототипа, но из более крупных фрагментов и меньшей суммарной площади. Но тут я сталкиваюсь с тем, что после 1000 CollisionShape добавление новых затруднительно, да и загрузка/выгрузка острова доставит проблем, особенно со всеми мелкими компонентами (деревья/кусты, например). Я в раздумьях, стоит ли сразу писать под серверы или можно сделать на нодах...
Если что, я знаю про то, что загрузку/выгрузку можно ставить в очередь и распределять по кадрам, чтобы минимизировать задержки. Не помню точно, вроде не пытался таким способом оптимизировать чанковую систему... но главная проблема в том, что даже единичная выгрузка (через remove_child) занимает кучу времени. А если распределение по времени будет слишком долгим, игрок быстро добежит до дырок и провалится или застрянет в них.
>У тебя что вообще за жанр?
У меня несколько заготовок, эти две самые серьёзные:
1. GTA-like с генерируемыми городами. Есть базовый генератор карты островного типа из модулей 24х24 метра, есть система чанков. Проблема: все объекты на нодах, число нод растёт очень быстро, из-за этого даже "голая" карта достаточного размера тормозит, но если применять выгрузку и загрузку чанков во время движения игрока, тормоза становятся ещё сильнее - операции по извлечению нод из сцены дороже, чем хранение их в сцене. В общем, я испугался сложности необходимых оптимизаций (серверы) и отложил проект в долгий ящик (уже который раз за последние ~13 лет).
2. Игра про летающие острова и строительство летающих кораблей. Есть базовый прототип строительства на нодах - компоненты на базе CollisionShape соединяются с кораблём-RigidBody, конструкция правдоподобно летает, можно достраивать прямо в полёте. Острова планируется генерировать по тому же принципу, что и города из предыдущего прототипа, но из более крупных фрагментов и меньшей суммарной площади. Но тут я сталкиваюсь с тем, что после 1000 CollisionShape добавление новых затруднительно, да и загрузка/выгрузка острова доставит проблем, особенно со всеми мелкими компонентами (деревья/кусты, например). Я в раздумьях, стоит ли сразу писать под серверы или можно сделать на нодах...
Если что, я знаю про то, что загрузку/выгрузку можно ставить в очередь и распределять по кадрам, чтобы минимизировать задержки. Не помню точно, вроде не пытался таким способом оптимизировать чанковую систему... но главная проблема в том, что даже единичная выгрузка (через remove_child) занимает кучу времени. А если распределение по времени будет слишком долгим, игрок быстро добежит до дырок и провалится или застрянет в них.
>>75824
Беседы про репарент нод несколько тредов назад ты, видимо пропустил?
Если вкратце. Там некий анон хвастался, что добился прироста производительности, создав пул нод, висящий в памяти, загруженный и не выгружающийся. У пула парент не в дереве. Соответственно, и он сам и его потомки не активны - у них не вызываются колбэки процесса и т.п. При необходимости, ноды из этого пула внедряются в дерево сцены и начинают работать, а потом обратно удаляются в пул. И якобы у него там был прирост производительности по сравнению с загрузкой/выгрузкой нод. Но пруфов он не предоставил.
Беседы про репарент нод несколько тредов назад ты, видимо пропустил?
Если вкратце. Там некий анон хвастался, что добился прироста производительности, создав пул нод, висящий в памяти, загруженный и не выгружающийся. У пула парент не в дереве. Соответственно, и он сам и его потомки не активны - у них не вызываются колбэки процесса и т.п. При необходимости, ноды из этого пула внедряются в дерево сцены и начинают работать, а потом обратно удаляются в пул. И якобы у него там был прирост производительности по сравнению с загрузкой/выгрузкой нод. Но пруфов он не предоставил.
>>75825
Да, я вообще не слежу за тредами здесь, редко захожу.
Я делал точь-в-точь такую же систему полтора года назад. Сразу в двух вариантах:
1. Объекты интерьера скрываются, когда игрок выходит за дверь, и отображаются, когда игрок входит в дверь.
2. Чанки скрываются, когда игрок отходит от них на определённое расстояние, и отображаются, когда подходит к ним.
Я неправильно выразился.
"Загрузка" - add_child(chunk)
"Выгрузка" - remove_child(chunk)
Т.е. точно та же фигня, что у того анона.
Проблема в том, сколько нод нужно добавлять/удалять за кадр. В случае с интерьером я особо не тестил нагрузку, но там у меня были мелкие комнаты и в идеале нод было мало (на самом деле была значительная нагрузка, если попытаться включать интерьеры в нескольких ближайших домах). В случае с чанками вышло так, что даже имея крупные чанки (24 метра), нужно за один раз работать сразу с несколькими десятками, даже в небольшом радиусе, а ведь внутри чанка тоже ноды. Возможно, если создавать очередь, это было бы не так заметно...
В общем, ноды для больших сцен - это плохо, нужно изучать работу с серверами и не насиловать дерево сцены тысячами нод, особенно физических (т.к. каждая физическая нода регистрирует себя на физическом сервере, а он работает асинхронно в отдельном потоке, отсюда лаги).
>Беседы про репарент нод несколько тредов назад ты, видимо пропустил?
Да, я вообще не слежу за тредами здесь, редко захожу.
>создав пул нод, висящий в памяти, загруженный и не выгружающийся. У пула парент не в дереве. Соответственно, и он сам и его потомки не активны - у них не вызываются колбэки процесса и т.п. При необходимости, ноды из этого пула внедряются в дерево сцены и начинают работать, а потом обратно удаляются в пул.
Я делал точь-в-точь такую же систему полтора года назад. Сразу в двух вариантах:
1. Объекты интерьера скрываются, когда игрок выходит за дверь, и отображаются, когда игрок входит в дверь.
2. Чанки скрываются, когда игрок отходит от них на определённое расстояние, и отображаются, когда подходит к ним.
>по сравнению с загрузкой/выгрузкой нод
Я неправильно выразился.
"Загрузка" - add_child(chunk)
"Выгрузка" - remove_child(chunk)
Т.е. точно та же фигня, что у того анона.
Проблема в том, сколько нод нужно добавлять/удалять за кадр. В случае с интерьером я особо не тестил нагрузку, но там у меня были мелкие комнаты и в идеале нод было мало (на самом деле была значительная нагрузка, если попытаться включать интерьеры в нескольких ближайших домах). В случае с чанками вышло так, что даже имея крупные чанки (24 метра), нужно за один раз работать сразу с несколькими десятками, даже в небольшом радиусе, а ведь внутри чанка тоже ноды. Возможно, если создавать очередь, это было бы не так заметно...
В общем, ноды для больших сцен - это плохо, нужно изучать работу с серверами и не насиловать дерево сцены тысячами нод, особенно физических (т.к. каждая физическая нода регистрирует себя на физическом сервере, а он работает асинхронно в отдельном потоке, отсюда лаги).
>>75873
Ну я в самом начале сказал, что пилить надо многопоточную систему, а это невозможно в дефолтной (однопоточной!) реализации дерева сцены. Следовательно, нужно пилить собственный майнлуп, в который впроектировать многопоточную архитектуру.
И это логично, не в упрёк Хуану, но его решения исключительно учебного характера. Не рассчитанные на реальный продакшен.
Ну я в самом начале сказал, что пилить надо многопоточную систему, а это невозможно в дефолтной (однопоточной!) реализации дерева сцены. Следовательно, нужно пилить собственный майнлуп, в который впроектировать многопоточную архитектуру.
И это логично, не в упрёк Хуану, но его решения исключительно учебного характера. Не рассчитанные на реальный продакшен.
>>75703
>>76022
>>76027 (Del)
Нет ты.
> Какие там многопотоки, дерево сцены работает в одном потоке
>>76022
> дефолтной (однопоточной!) реализации дерева сцены
>>76027 (Del)
> Ты же знаешь
Нет ты.
>>76036 (Del)
На дерево это не влияет. Во сколько потоков ты ни грузи ноды, тебе придётся локнуть главный поток, чтобы присоединить их к дереву. Об том и речь.
На дерево это не влияет. Во сколько потоков ты ни грузи ноды, тебе придётся локнуть главный поток, чтобы присоединить их к дереву. Об том и речь.
Сделал свой тест производительности на базе серверов по официальному туториалу. Что печалит:
- визуальный сервер начинает плавно тормозить примерно с 13-14 тысяч визуальных объектов одновременно на экране, и это не зависит от видеокарты (подозреваю, всё упирается в число запросов от процессора к видеокарте);
- визуальный сервер не отсекает объекты, перекрытые другими объектами (ну это и так всем известно);
- физический сервер резко захлёбывается и снижает общую производительность до минимальной (5 FPS лол) на 12-13 тысячах статических объектов, при этом нагрузка на 4-ядерный процессор неполная - видимо, всё упирается в производительность на ядро;
- если неправильно вызвать free_rid() (например, освободить шейп, который привязан к боди), программа зависает и завершается без каких-либо сообщений об ошибке (похоже на баг).
Что радует:
- визуальный сервер отсекает объекты вне поля зрения камеры, поэтому можно без проблем создать 300 тысяч и больше визуальных объектов, лишь бы они не отображались одновременно;
- физический сервер создаёт новые физические (статические) тела молниеносно вплоть до примерно 10 тысяч объектов;
- удаление объектов пачками через free_rid() практически не влияет на производительность примерно до тысячи объектов за кадр (один объект - это 3 вызова free_rid(): шейп, боди и графический инстанс).
RigidBody, несколько шейпов на объект и т.д. тестить не стал. Главный для меня вывод - чанковая система на основе серверов будет работать лучше, т.к. тормоза во время создания и удаления объектов меньше. Я знаю, что удалять не обязательно, но т.к. это самые затратные операции и они не занимают много времени - другие способы будут быстрее. Хотя через сервера управлять объектами сложнее...
Эх, ещё немного потыкался - всё-таки прирост производительности минимальный. Ноды и дерево, конечно, замедляют игру, но не так сильно, как казалось. Впрочем, разница в производительности заметна невооружённым глазом, а это что-то да значит. В любом случае, главное - это умная система чанков, я просто в тупую пытался тысячи объектов туда-сюда таскать, поэтому и медленно было.
>>76022
Ну я прикинул, если использовать серверы - многопоточности не нужно, добавления/удаления 1000 объектов за кадр должно хватить чанковой системе, учитывая возможность поставить всё это в очередь, растянув на несколько кадров. Многопоточность нужна физическому движку, который захлёбывается из-за 12 тысяч статичных объектов, не нагружая процессор, но это вопрос к Bullet, а не к Godot. Конкретно к Godot вопрос в том, почему он до сих пор не умеет отбрасывать невидимые (перекрытые) объекты, но, мне кажется, это должны скоро исправить (порталы вот уже сделали в одной из бета-версий, а ведь я их велосипедил когда-то).
>>76044
Таки почему у меня цикл
Работает существенно медленнее чем
? Это ведь в обоих случаях однопоточная задача, при том что в первом случае я даже ничего не высвобождаю - только разрываю связь ноды с деревом, тогда как во втором случае высвобождаются блоки памяти (или, как минимум, собираются это сделать).
Т.е. проблема не в потоках. Тот же remove_child() происходит в потоке сцены, тогда как обращения free_rid() идут к отдельным потокам, в которых вертятся сервера (по идее).
- визуальный сервер начинает плавно тормозить примерно с 13-14 тысяч визуальных объектов одновременно на экране, и это не зависит от видеокарты (подозреваю, всё упирается в число запросов от процессора к видеокарте);
- визуальный сервер не отсекает объекты, перекрытые другими объектами (ну это и так всем известно);
- физический сервер резко захлёбывается и снижает общую производительность до минимальной (5 FPS лол) на 12-13 тысячах статических объектов, при этом нагрузка на 4-ядерный процессор неполная - видимо, всё упирается в производительность на ядро;
- если неправильно вызвать free_rid() (например, освободить шейп, который привязан к боди), программа зависает и завершается без каких-либо сообщений об ошибке (похоже на баг).
Что радует:
- визуальный сервер отсекает объекты вне поля зрения камеры, поэтому можно без проблем создать 300 тысяч и больше визуальных объектов, лишь бы они не отображались одновременно;
- физический сервер создаёт новые физические (статические) тела молниеносно вплоть до примерно 10 тысяч объектов;
- удаление объектов пачками через free_rid() практически не влияет на производительность примерно до тысячи объектов за кадр (один объект - это 3 вызова free_rid(): шейп, боди и графический инстанс).
RigidBody, несколько шейпов на объект и т.д. тестить не стал. Главный для меня вывод - чанковая система на основе серверов будет работать лучше, т.к. тормоза во время создания и удаления объектов меньше. Я знаю, что удалять не обязательно, но т.к. это самые затратные операции и они не занимают много времени - другие способы будут быстрее. Хотя через сервера управлять объектами сложнее...
Эх, ещё немного потыкался - всё-таки прирост производительности минимальный. Ноды и дерево, конечно, замедляют игру, но не так сильно, как казалось. Впрочем, разница в производительности заметна невооружённым глазом, а это что-то да значит. В любом случае, главное - это умная система чанков, я просто в тупую пытался тысячи объектов туда-сюда таскать, поэтому и медленно было.
>>76022
>пилить надо многопоточную систему
Ну я прикинул, если использовать серверы - многопоточности не нужно, добавления/удаления 1000 объектов за кадр должно хватить чанковой системе, учитывая возможность поставить всё это в очередь, растянув на несколько кадров. Многопоточность нужна физическому движку, который захлёбывается из-за 12 тысяч статичных объектов, не нагружая процессор, но это вопрос к Bullet, а не к Godot. Конкретно к Godot вопрос в том, почему он до сих пор не умеет отбрасывать невидимые (перекрытые) объекты, но, мне кажется, это должны скоро исправить (порталы вот уже сделали в одной из бета-версий, а ведь я их велосипедил когда-то).
>>76044
>тебе придётся локнуть главный поток, чтобы присоединить их к дереву
Таки почему у меня цикл
>for child in children(): remove_child(child)
Работает существенно медленнее чем
>for object in objects:
>...free_rid(object.body)
>...free_rid(object.shape)
>...free_rid(object.mesh)
? Это ведь в обоих случаях однопоточная задача, при том что в первом случае я даже ничего не высвобождаю - только разрываю связь ноды с деревом, тогда как во втором случае высвобождаются блоки памяти (или, как минимум, собираются это сделать).
Т.е. проблема не в потоках. Тот же remove_child() происходит в потоке сцены, тогда как обращения free_rid() идут к отдельным потокам, в которых вертятся сервера (по идее).
Сделал свой тест производительности на базе серверов по официальному туториалу. Что печалит:
- визуальный сервер начинает плавно тормозить примерно с 13-14 тысяч визуальных объектов одновременно на экране, и это не зависит от видеокарты (подозреваю, всё упирается в число запросов от процессора к видеокарте);
- визуальный сервер не отсекает объекты, перекрытые другими объектами (ну это и так всем известно);
- физический сервер резко захлёбывается и снижает общую производительность до минимальной (5 FPS лол) на 12-13 тысячах статических объектов, при этом нагрузка на 4-ядерный процессор неполная - видимо, всё упирается в производительность на ядро;
- если неправильно вызвать free_rid() (например, освободить шейп, который привязан к боди), программа зависает и завершается без каких-либо сообщений об ошибке (похоже на баг).
Что радует:
- визуальный сервер отсекает объекты вне поля зрения камеры, поэтому можно без проблем создать 300 тысяч и больше визуальных объектов, лишь бы они не отображались одновременно;
- физический сервер создаёт новые физические (статические) тела молниеносно вплоть до примерно 10 тысяч объектов;
- удаление объектов пачками через free_rid() практически не влияет на производительность примерно до тысячи объектов за кадр (один объект - это 3 вызова free_rid(): шейп, боди и графический инстанс).
RigidBody, несколько шейпов на объект и т.д. тестить не стал. Главный для меня вывод - чанковая система на основе серверов будет работать лучше, т.к. тормоза во время создания и удаления объектов меньше. Я знаю, что удалять не обязательно, но т.к. это самые затратные операции и они не занимают много времени - другие способы будут быстрее. Хотя через сервера управлять объектами сложнее...
Эх, ещё немного потыкался - всё-таки прирост производительности минимальный. Ноды и дерево, конечно, замедляют игру, но не так сильно, как казалось. Впрочем, разница в производительности заметна невооружённым глазом, а это что-то да значит. В любом случае, главное - это умная система чанков, я просто в тупую пытался тысячи объектов туда-сюда таскать, поэтому и медленно было.
>>76022
Ну я прикинул, если использовать серверы - многопоточности не нужно, добавления/удаления 1000 объектов за кадр должно хватить чанковой системе, учитывая возможность поставить всё это в очередь, растянув на несколько кадров. Многопоточность нужна физическому движку, который захлёбывается из-за 12 тысяч статичных объектов, не нагружая процессор, но это вопрос к Bullet, а не к Godot. Конкретно к Godot вопрос в том, почему он до сих пор не умеет отбрасывать невидимые (перекрытые) объекты, но, мне кажется, это должны скоро исправить (порталы вот уже сделали в одной из бета-версий, а ведь я их велосипедил когда-то).
>>76044
Таки почему у меня цикл
Работает существенно медленнее чем
? Это ведь в обоих случаях однопоточная задача, при том что в первом случае я даже ничего не высвобождаю - только разрываю связь ноды с деревом, тогда как во втором случае высвобождаются блоки памяти (или, как минимум, собираются это сделать).
Т.е. проблема не в потоках. Тот же remove_child() происходит в потоке сцены, тогда как обращения free_rid() идут к отдельным потокам, в которых вертятся сервера (по идее).
- визуальный сервер начинает плавно тормозить примерно с 13-14 тысяч визуальных объектов одновременно на экране, и это не зависит от видеокарты (подозреваю, всё упирается в число запросов от процессора к видеокарте);
- визуальный сервер не отсекает объекты, перекрытые другими объектами (ну это и так всем известно);
- физический сервер резко захлёбывается и снижает общую производительность до минимальной (5 FPS лол) на 12-13 тысячах статических объектов, при этом нагрузка на 4-ядерный процессор неполная - видимо, всё упирается в производительность на ядро;
- если неправильно вызвать free_rid() (например, освободить шейп, который привязан к боди), программа зависает и завершается без каких-либо сообщений об ошибке (похоже на баг).
Что радует:
- визуальный сервер отсекает объекты вне поля зрения камеры, поэтому можно без проблем создать 300 тысяч и больше визуальных объектов, лишь бы они не отображались одновременно;
- физический сервер создаёт новые физические (статические) тела молниеносно вплоть до примерно 10 тысяч объектов;
- удаление объектов пачками через free_rid() практически не влияет на производительность примерно до тысячи объектов за кадр (один объект - это 3 вызова free_rid(): шейп, боди и графический инстанс).
RigidBody, несколько шейпов на объект и т.д. тестить не стал. Главный для меня вывод - чанковая система на основе серверов будет работать лучше, т.к. тормоза во время создания и удаления объектов меньше. Я знаю, что удалять не обязательно, но т.к. это самые затратные операции и они не занимают много времени - другие способы будут быстрее. Хотя через сервера управлять объектами сложнее...
Эх, ещё немного потыкался - всё-таки прирост производительности минимальный. Ноды и дерево, конечно, замедляют игру, но не так сильно, как казалось. Впрочем, разница в производительности заметна невооружённым глазом, а это что-то да значит. В любом случае, главное - это умная система чанков, я просто в тупую пытался тысячи объектов туда-сюда таскать, поэтому и медленно было.
>>76022
>пилить надо многопоточную систему
Ну я прикинул, если использовать серверы - многопоточности не нужно, добавления/удаления 1000 объектов за кадр должно хватить чанковой системе, учитывая возможность поставить всё это в очередь, растянув на несколько кадров. Многопоточность нужна физическому движку, который захлёбывается из-за 12 тысяч статичных объектов, не нагружая процессор, но это вопрос к Bullet, а не к Godot. Конкретно к Godot вопрос в том, почему он до сих пор не умеет отбрасывать невидимые (перекрытые) объекты, но, мне кажется, это должны скоро исправить (порталы вот уже сделали в одной из бета-версий, а ведь я их велосипедил когда-то).
>>76044
>тебе придётся локнуть главный поток, чтобы присоединить их к дереву
Таки почему у меня цикл
>for child in children(): remove_child(child)
Работает существенно медленнее чем
>for object in objects:
>...free_rid(object.body)
>...free_rid(object.shape)
>...free_rid(object.mesh)
? Это ведь в обоих случаях однопоточная задача, при том что в первом случае я даже ничего не высвобождаю - только разрываю связь ноды с деревом, тогда как во втором случае высвобождаются блоки памяти (или, как минимум, собираются это сделать).
Т.е. проблема не в потоках. Тот же remove_child() происходит в потоке сцены, тогда как обращения free_rid() идут к отдельным потокам, в которых вертятся сервера (по идее).
>>76064
А-а-а, блин! Я совсем запутался.
Короче, этот цикл у меня был таким:
Вот из-за этой последней строчки возникала значительная задержка. Закомментировал эту строчку, оставив только remove_child() - теперь удаление объектов из сцены занимает ровно столько же времени, сколько и free_rid(). Щито? Почему так? То есть у серверов вообще никаких преимуществ перед деревом сцены не остаётся? Где этот прирост производительности-то... куда он делся?(
Я запутался. Впрочем, ладно, сделаю что-нибудь. Главная задача была - определить практический лимит количества нод/объектов, выше которого всё начинает жёстко тормозить. И этот лимит примерно на уровне 30 тысяч нод для моего компьютера.
Кажется, я кое-что вспомнил. Предыдущий проект я забросил не из-за проблем с производительностью, а из-за того, что не смог выдавить из себя красивый контент, в результате карта выглядела крайне унылой. Я переключился на 2D, рассчитывая что рисовать 2D с видом сверху проще, но там нужно было сильно переделывать генератор карт и я окончательно на всё забил... Блин.
>Таки почему у меня цикл
>>for child in children(): remove_child(child)
>Работает существенно медленнее
А-а-а, блин! Я совсем запутался.
Короче, этот цикл у меня был таким:
>for child in get_children():
>_ remove_child(child)
>_ child.queue_free()
Вот из-за этой последней строчки возникала значительная задержка. Закомментировал эту строчку, оставив только remove_child() - теперь удаление объектов из сцены занимает ровно столько же времени, сколько и free_rid(). Щито? Почему так? То есть у серверов вообще никаких преимуществ перед деревом сцены не остаётся? Где этот прирост производительности-то... куда он делся?(
Я запутался. Впрочем, ладно, сделаю что-нибудь. Главная задача была - определить практический лимит количества нод/объектов, выше которого всё начинает жёстко тормозить. И этот лимит примерно на уровне 30 тысяч нод для моего компьютера.
Кажется, я кое-что вспомнил. Предыдущий проект я забросил не из-за проблем с производительностью, а из-за того, что не смог выдавить из себя красивый контент, в результате карта выглядела крайне унылой. Я переключился на 2D, рассчитывая что рисовать 2D с видом сверху проще, но там нужно было сильно переделывать генератор карт и я окончательно на всё забил... Блин.
85 Кб, 680x680>>76065
Ты меня не слушал.
>>75825
Загруженный.
Не выгружающийся.
Пул, мазафака, ду ю но ит? Тормоза берутся, когда ГЦ высвобождает память. И когда менеджер памяти выделяет память под новую ноду. Минимизируешь загрузку/выгрузку из памяти за счёт максимального реиспользования нод. Это напрямую значит, что чайлды нод создаются только один раз при старте игры. Возможно даже в отдельных потоках. После того как поток просигналил о завершении, ты знаешь, что в определенной переменной лежит новая нода. Нода помещается в пул. Далее ноды, оставаясь в памяти, вмять! перемещаются репарентом по необходимости из пула в дерево и из дерева в пул.
> queue_free()
> Где этот прирост производительности-то... куда он делся?(
Ты меня не слушал.
>>75825
> создав пул нод, висящий в памяти, загруженный и не выгружающийся.
Загруженный.
Не выгружающийся.
Пул, мазафака, ду ю но ит? Тормоза берутся, когда ГЦ высвобождает память. И когда менеджер памяти выделяет память под новую ноду. Минимизируешь загрузку/выгрузку из памяти за счёт максимального реиспользования нод. Это напрямую значит, что чайлды нод создаются только один раз при старте игры. Возможно даже в отдельных потоках. После того как поток просигналил о завершении, ты знаешь, что в определенной переменной лежит новая нода. Нода помещается в пул. Далее ноды, оставаясь в памяти, вмять! перемещаются репарентом по необходимости из пула в дерево и из дерева в пул.
Парни, хелпайте, в геймдеве опыта не имею, а тут такие обидные штуки случаются.
В общем, баловался с Camera2D и управлением как во всяких стратегиях с видом сверху. Я смог понять, как камера передвигается с помощью мыши и вроде не так уж и криво, но решил привязать gui к этой камере.
Так вот, сама суть: когда Camera2D достигает лимита, то если я делаю движение по смене позиции в сторону лимита, то картинка за лимит не уходит, но туда gui съезжает, т. е. Camera2D всё равно меняет позицию, уходя за лимит, но этого не видно.
Вообще, можно как-то сдетектить, что лимит был достигнут(чтобы не передвигалась Camera2D за него) или нужно gui не к камере привязывать, лол? Если что, реализовал перемещение камеры через изменение global_position.
В общем, баловался с Camera2D и управлением как во всяких стратегиях с видом сверху. Я смог понять, как камера передвигается с помощью мыши и вроде не так уж и криво, но решил привязать gui к этой камере.
Так вот, сама суть: когда Camera2D достигает лимита, то если я делаю движение по смене позиции в сторону лимита, то картинка за лимит не уходит, но туда gui съезжает, т. е. Camera2D всё равно меняет позицию, уходя за лимит, но этого не видно.
Вообще, можно как-то сдетектить, что лимит был достигнут(чтобы не передвигалась Camera2D за него) или нужно gui не к камере привязывать, лол? Если что, реализовал перемещение камеры через изменение global_position.
>>76100
This.
Изучи класс CanvasLayer и зачем он нужен. Если вкратце, то ты делаешь несколько таких слоёв, в одном гуй, в другом сцена и камера.
> или нужно gui не к камере привязывать, лол?
This.
Изучи класс CanvasLayer и зачем он нужен. Если вкратце, то ты делаешь несколько таких слоёв, в одном гуй, в другом сцена и камера.
>>76077
Это ты меня не слушал.
Я именно так и делал. Но это вызывает дичайшую нагрузку, когда нужно репарентить сколь-либо существенное количество нод. Именно поэтому я заинтересовался серверами, но на практике выяснилось, что они не дают никакого прироста производительности по сравнению с этим самым "пулом нод".
Единственный выход - делать очередь на репарент и пропихивать ноды в час по чайной ложке, чтобы не было резких просадок фпс. Аналогично с созданием и освобождением нод.
Вообще, мне кажется, что тот хваставшийся анон - это я, ведь именно я 1.5 года назад где-то здесь хвастался, как у меня десятки тысяч нод находятся в скрытом пуле (только слова я такого не знал, я называю это контейнером), пока игрок не зайдёт в помещение.
Это ты меня не слушал.
>перемещаются репарентом по необходимости из пула в дерево и из дерева в пул.
Я именно так и делал. Но это вызывает дичайшую нагрузку, когда нужно репарентить сколь-либо существенное количество нод. Именно поэтому я заинтересовался серверами, но на практике выяснилось, что они не дают никакого прироста производительности по сравнению с этим самым "пулом нод".
Единственный выход - делать очередь на репарент и пропихивать ноды в час по чайной ложке, чтобы не было резких просадок фпс. Аналогично с созданием и освобождением нод.
Вообще, мне кажется, что тот хваставшийся анон - это я, ведь именно я 1.5 года назад где-то здесь хвастался, как у меня десятки тысяч нод находятся в скрытом пуле (только слова я такого не знал, я называю это контейнером), пока игрок не зайдёт в помещение.
>>76113
Ну ладно. Значит отбрасываем эту идею и ищем дальше.
Ну ладно. Значит отбрасываем эту идею и ищем дальше.
>>76100
>>76207
В следующий раз, прежде чем задавать вопрос, попробуй почитать официальные туториалы в мануале, например: https://docs.godotengine.org/en/stable/tutorials/2d/canvas_layers.html - первая же статья в категории "Tutorials > 2D".
>>76207
В следующий раз, прежде чем задавать вопрос, попробуй почитать официальные туториалы в мануале, например: https://docs.godotengine.org/en/stable/tutorials/2d/canvas_layers.html - первая же статья в категории "Tutorials > 2D".
Тут недавно туториал вышел:
https://www.reddit.com/r/godot/comments/qmy2er/a_lot_of_people_wanted_to_know_how_to_make_a/
Но зачем делать так, если можно просто:
export var player = {
speed = 50.0,
weight = 75.0,
weapons = []}
И так далее. Всё организованно, можно свернуть/развернуть.
И доступ из кода удобный, через точку: player.speed, player.weight
Зачем может быть нужно что-то другое? Тем более сложное.
https://www.reddit.com/r/godot/comments/qmy2er/a_lot_of_people_wanted_to_know_how_to_make_a/
Но зачем делать так, если можно просто:
export var player = {
speed = 50.0,
weight = 75.0,
weapons = []}
И так далее. Всё организованно, можно свернуть/развернуть.
И доступ из кода удобный, через точку: player.speed, player.weight
Зачем может быть нужно что-то другое? Тем более сложное.
>>76260
Всё это - вопрос вкуса. Тебе удобнее через словари/объекты/таблицы/ассоц.массивы. Через точку. Кому-то другому нравится через классы и методы, через функцию с аргументом в скобочках. Некоторым нравится ещё и через словари, но не через точку, а через квадратные скобочки.
> Зачем может быть нужно что-то другое?
Всё это - вопрос вкуса. Тебе удобнее через словари/объекты/таблицы/ассоц.массивы. Через точку. Кому-то другому нравится через классы и методы, через функцию с аргументом в скобочках. Некоторым нравится ещё и через словари, но не через точку, а через квадратные скобочки.
>>76260
Насколько я помню, в инспектор вылезет интерфейс нетипизированного массива, в который можно напихать любой хуйни, от которой игра обмякнет, если не писать кучу проверок на дурака при работе с этим массивом. Возможно уже сделали механизм, позволяющий фильтровать, а лучше типизировать данные для добавления в массив из инспектора?
В качестве костыля, испрвляющего эту и подобные траблы при работе со словарями, несколько лет назад был написан скрипт, реализующий минимальный функционал ЖСОН-схемы. Идея скрипта, для анонов, не знакомых с принципом валидации по схеме, заключается в том, что для целевого объекта пишется схема, из чего он может состоять, из чего не может, включая все уровни вложенности. Т.Е. схема может быть весьма обширной. Единожды написанная схема позволяет заменить собой весь комплекс проверок на дурака.
Внимание! Костыль с говнокодом через 3... 2... 1...
https://godotengine.org/asset-library/asset/514
> export var
> weapons = []
Насколько я помню, в инспектор вылезет интерфейс нетипизированного массива, в который можно напихать любой хуйни, от которой игра обмякнет, если не писать кучу проверок на дурака при работе с этим массивом. Возможно уже сделали механизм, позволяющий фильтровать, а лучше типизировать данные для добавления в массив из инспектора?
В качестве костыля, испрвляющего эту и подобные траблы при работе со словарями, несколько лет назад был написан скрипт, реализующий минимальный функционал ЖСОН-схемы. Идея скрипта, для анонов, не знакомых с принципом валидации по схеме, заключается в том, что для целевого объекта пишется схема, из чего он может состоять, из чего не может, включая все уровни вложенности. Т.Е. схема может быть весьма обширной. Единожды написанная схема позволяет заменить собой весь комплекс проверок на дурака.
Внимание! Костыль с говнокодом через 3... 2... 1...
https://godotengine.org/asset-library/asset/514
>>76432 (Del)
Никто не вывезет. 100500 кубов с физоном это лютая подъёбка, которую раскусили ещё джва года назад (но не смирившиеся были изгнаны в срачетред). Суть токова: мобилы это глобальное наебалово быдла корпоративными кабанчиками. Хочешь, чтобы мобила вывозила ГРАФОНИУМ - покупай мобилу за 50К. Но зачем, если вместо игровой мобилы выгоднее купить плойку?
> не вывезли реквест
> на мобиле
Никто не вывезет. 100500 кубов с физоном это лютая подъёбка, которую раскусили ещё джва года назад (но не смирившиеся были изгнаны в срачетред). Суть токова: мобилы это глобальное наебалово быдла корпоративными кабанчиками. Хочешь, чтобы мобила вывозила ГРАФОНИУМ - покупай мобилу за 50К. Но зачем, если вместо игровой мобилы выгоднее купить плойку?
Анончики, подскажите как правильно настроить fog. Хочу сделать атмосферное затенение для высокой башни для задника, но нужный мне эффект достигается только фогом с высталеннымы параметрами height max и height min (500 и 3000 соответвенно) но при этом все объекты находящиеся снизу закумариваются фогом вглухую. Как можно настроить реалистичный фог, который усиливается вдаль, и уменьшается с высотой?
>>76604
Плагином. Буквально вчера видел.
> реалистичный фог, который усиливается вдаль, и уменьшается с высотой?
Плагином. Буквально вчера видел.
>>76265 (Del)
Это и через словари с массивами делается.
Зачем?
>>76345
Согласен, но я не понимаю, кому может быть удобно группировать переменные с именами типа player_weapon, player_weapon_count, player_weapon_pistol_bullets_damage, player_weapon_pistol_bullets_count и т.д., когда такие вещи нужно сортировать по разным объектам (player, weapon, pistol, bullet) или внутри древовидного словаря (player.weapons.pistol.bullets.damage - всё просто, понятно и, главное, компактно как в коде, так и в интерфейсе)..
>>76346
Лучшая проверка на дурака - это человек, который контролирует доступ дураков к конкретному компьютеру. Если программа встретила ошибку в данных, она должна упасть с сообщением об ошибке, требующим эту ошибку исправить, а не тихо проглотить или попытаться исправить. Мы ведь не прошивку для космических ракет пишем (для этого нужна Ada), а развлекательные программы, от которых не требуется надёжной безотказной работы во что бы то ни стало. И если ты объявил динамический массив, а потом САМ напихал в него всякой херни, от которой твоя игра обмякла - виноват тут только ты сам.
Другое дело, что строго типизированные переменные ускоряют операции на сколько-то %, но это вроде как только в будущих версиях. Кстати, в GDScript 2.0 будут типизированные массивы, что-то вроде Array[String] - массив строк. Мне, как воспитанному Паскалем, очень хочется такие массивы, я привык к "array of тип". Впрочем, гораздо больше мне не хватает создания пользовательских типов (в Паскале это раздел type любого модуля/программы)...
>Очевидно чтобы были категории, сворачиваемые списки.
Это и через словари с массивами делается.
>Есть еще ассет цветные кнопочки наворачивать.
Зачем?
>>76345
>Всё это - вопрос вкуса.
Согласен, но я не понимаю, кому может быть удобно группировать переменные с именами типа player_weapon, player_weapon_count, player_weapon_pistol_bullets_damage, player_weapon_pistol_bullets_count и т.д., когда такие вещи нужно сортировать по разным объектам (player, weapon, pistol, bullet) или внутри древовидного словаря (player.weapons.pistol.bullets.damage - всё просто, понятно и, главное, компактно как в коде, так и в интерфейсе)..
>>76346
>от которой игра обмякнет, если не писать кучу проверок на дурака при работе с этим массивом
Лучшая проверка на дурака - это человек, который контролирует доступ дураков к конкретному компьютеру. Если программа встретила ошибку в данных, она должна упасть с сообщением об ошибке, требующим эту ошибку исправить, а не тихо проглотить или попытаться исправить. Мы ведь не прошивку для космических ракет пишем (для этого нужна Ada), а развлекательные программы, от которых не требуется надёжной безотказной работы во что бы то ни стало. И если ты объявил динамический массив, а потом САМ напихал в него всякой херни, от которой твоя игра обмякла - виноват тут только ты сам.
Другое дело, что строго типизированные переменные ускоряют операции на сколько-то %, но это вроде как только в будущих версиях. Кстати, в GDScript 2.0 будут типизированные массивы, что-то вроде Array[String] - массив строк. Мне, как воспитанному Паскалем, очень хочется такие массивы, я привык к "array of тип". Впрочем, гораздо больше мне не хватает создания пользовательских типов (в Паскале это раздел type любого модуля/программы)...
>>76458 (Del)
Тебе кинуть ссылку на алиэкспресс, где можно купить детские кубики с буковками? Как раз скоро распродажа 11.11, купишь себе 500 кубиков и будешь с ними в своей комнате играть сколько влезет, без единого лага на максимальной частоте кадров, сколько могут воспринять твои глаза. Я же вижу, ты не наигрался в детстве, наверное, тебе их просто не покупали...
А на игровых движках нужно делать нормальные игры.
>400 кубов
Тебе кинуть ссылку на алиэкспресс, где можно купить детские кубики с буковками? Как раз скоро распродажа 11.11, купишь себе 500 кубиков и будешь с ними в своей комнате играть сколько влезет, без единого лага на максимальной частоте кадров, сколько могут воспринять твои глаза. Я же вижу, ты не наигрался в детстве, наверное, тебе их просто не покупали...
А на игровых движках нужно делать нормальные игры.
>>76661
Тодд Говард в треде! С его падающим каждые 5 минут скайримом!
Ты невнимательно смотрел видос. Там имена переменных даются для наглядности. В реале через оверрайд тех методов ты можешь в инспекторе прописать переменную Foo в категории Bar, которая перенаправляет значения во внутреннюю переменную Baz скрипта. И даже (о ужас!) в индекс массива записывать!
Мне не понравилось, что для этого скрипт нужно тулскриптом делать. Это добавит головняка.
> Мы ведь не прошивку для космических ракет пишем (для этого нужна Ada), а развлекательные программы, от которых не требуется надёжной безотказной работы во что бы то ни стало.
Тодд Говард в треде! С его падающим каждые 5 минут скайримом!
> кому может быть удобно группировать переменные с именами типа player_weapon, player_weapon_count, player_weapon_pistol_bullets_damage, player_weapon_pistol_bullets_count и т.д.
Ты невнимательно смотрел видос. Там имена переменных даются для наглядности. В реале через оверрайд тех методов ты можешь в инспекторе прописать переменную Foo в категории Bar, которая перенаправляет значения во внутреннюю переменную Baz скрипта. И даже (о ужас!) в индекс массива записывать!
Мне не понравилось, что для этого скрипт нужно тулскриптом делать. Это добавит головняка.
>>76676
Я не предлагаю выпускать в релиз неотлаженную версию, которая падает каждые 5 минут. Просто позволь игре падать, пока ты её разрабатываешь, чтобы ты знал о существовании внутренних проблем и пытался их исправить. А если игра у тебя сейчас молча съедает любые данные и не падает, то потом ты очень удивишься, когда в релизе вылезут непонятные баги, о которых ты ничего не знаешь, потому что даже не пытался их отлавливать.
З А Ч Е М
А
Ч
Е
М
В каких ситуациях вот прям очень нужно внедрять такую мудрёную систему? Тем более что она в любом случае
>падающим каждые 5 минут скайримом
Я не предлагаю выпускать в релиз неотлаженную версию, которая падает каждые 5 минут. Просто позволь игре падать, пока ты её разрабатываешь, чтобы ты знал о существовании внутренних проблем и пытался их исправить. А если игра у тебя сейчас молча съедает любые данные и не падает, то потом ты очень удивишься, когда в релизе вылезут непонятные баги, о которых ты ничего не знаешь, потому что даже не пытался их отлавливать.
>ты можешь в инспекторе прописать переменную Foo в категории Bar, которая перенаправляет значения во внутреннюю переменную Baz скрипта. И даже (о ужас!) в индекс массива записывать!
З А Ч Е М
А
Ч
Е
М
В каких ситуациях вот прям очень нужно внедрять такую мудрёную систему? Тем более что она в любом случае
>добавит головняка.
>>76775
Вообще-то речь про инструменты разработчика - их никто кроме тебя не увидит, если ты работаешь над проектом один и не спамишь скриншотами редактора везде где можно.
Вообще-то речь про инструменты разработчика - их никто кроме тебя не увидит, если ты работаешь над проектом один и не спамишь скриншотами редактора везде где можно.
А у всех подсказки в редакторе Годо мигают? Навожу курсор на элемент интерфейса, подсказка появляется, через секунду исчезает, потом снова появляется и т.д. Читать текст подсказки из-за этого очень сложно. Версии Годо - разные, я этот баг уже 2 года наблюдаю. Система Windows 10. Дрейфа курсора точно нет и в других программах с всплывающими подсказками всё нормально, впервые встретил такое именно в Годо. Почему это так и как исправить? Очень редко, бывает, подсказка работает нормально, но потом опять ломается и начинает мигать. Очень раздражает...
>>76847 (Del)
Нет такого. Есть только драйвер мыши, но он ничего особенного на экран не выводит, тем более в окно Godot, тем более постоянно.
Ну вот диспетчер задач никак подсказкам Годо не мешает, хотя находится поверх всех окон... Да и как оно может мешать, если подсказки Годо рендерятся прямо в окне редактора, не выходя за его пределы?
Вообще не пользуюсь.
Короче, хотел сейчас протестировать, закрыв лишние программы, но ВНЕЗАПНО подсказки сейчас работают нормально со всеми теми программами что обычно открыты. Я позавчера перекатился на 3.4, не уверен, замечал ли этот баг в этой версии или нет... Почему-то кажется, что вчера он был, а сейчас пропал.
Вспомнил ещё, что меня раздражает в подсказках: там часто есть ссылки на какие-нибудь компоненты, разделы справки и т.д., но кликнуть по ним невозможно, потому что подсказка скрывается, если навести на неё курсор. Приходится искать тот же текст в окне по F1. Это так и задумано что ли? Я бы сделал так, чтобы подсказки задерживались на экране, давая кликнуть на ссылку.
Кстати, кто уже перекатился на 3.4 - как ощущения? По-моему редактор стал в несколько раз шустрее откликаться, сцены быстрее открываются и даже отклик игры лучше. Они что, повысили частоту опроса устройств ввода? Я благодаря этому обнаружил баг в своём коде вращения камеры мышкой, лол, вместо "+=" было "=" и смещение курсора не накапливалось, из-за чего камера двигалась рывками.
>кастомного рабочего стола
Нет такого. Есть только драйвер мыши, но он ничего особенного на экран не выводит, тем более в окно Godot, тем более постоянно.
>всегда поверх других окон
Ну вот диспетчер задач никак подсказкам Годо не мешает, хотя находится поверх всех окон... Да и как оно может мешать, если подсказки Годо рендерятся прямо в окне редактора, не выходя за его пределы?
>мессенджер
Вообще не пользуюсь.
Короче, хотел сейчас протестировать, закрыв лишние программы, но ВНЕЗАПНО подсказки сейчас работают нормально со всеми теми программами что обычно открыты. Я позавчера перекатился на 3.4, не уверен, замечал ли этот баг в этой версии или нет... Почему-то кажется, что вчера он был, а сейчас пропал.
Вспомнил ещё, что меня раздражает в подсказках: там часто есть ссылки на какие-нибудь компоненты, разделы справки и т.д., но кликнуть по ним невозможно, потому что подсказка скрывается, если навести на неё курсор. Приходится искать тот же текст в окне по F1. Это так и задумано что ли? Я бы сделал так, чтобы подсказки задерживались на экране, давая кликнуть на ссылку.
Кстати, кто уже перекатился на 3.4 - как ощущения? По-моему редактор стал в несколько раз шустрее откликаться, сцены быстрее открываются и даже отклик игры лучше. Они что, повысили частоту опроса устройств ввода? Я благодаря этому обнаружил баг в своём коде вращения камеры мышкой, лол, вместо "+=" было "=" и смещение курсора не накапливалось, из-за чего камера двигалась рывками.
>>76847 (Del)
>>76863
Опять мигают. Но теперь я погуглил и нашёл источник проблемы.
https://github.com/godotengine/godot/issues/41251
Только в моём случае подсказки мигают с частотой примерно 1 Гц пока MPC-HC воспроизводит музыку. От режима отображения окна никак не зависит, даже если окно свернуть в трей.
Кстати, забавно, но подсказка сохраняется и не мигает, если двигать курсором туда-сюда вдоль элемента управления, которому принадлежит эта подсказка. Ну а если поставить музыку на паузу, например, медиаклавишей, то подсказка вообще мигать перестаёт и работает нормально.
Какой-то дурацкий баг. Но теперь хотя бы понятно, как читать подсказки)
>>76863
>ВНЕЗАПНО подсказки сейчас работают нормально
Опять мигают. Но теперь я погуглил и нашёл источник проблемы.
https://github.com/godotengine/godot/issues/41251
Только в моём случае подсказки мигают с частотой примерно 1 Гц пока MPC-HC воспроизводит музыку. От режима отображения окна никак не зависит, даже если окно свернуть в трей.
Кстати, забавно, но подсказка сохраняется и не мигает, если двигать курсором туда-сюда вдоль элемента управления, которому принадлежит эта подсказка. Ну а если поставить музыку на паузу, например, медиаклавишей, то подсказка вообще мигать перестаёт и работает нормально.
Какой-то дурацкий баг. Но теперь хотя бы понятно, как читать подсказки)
42 Кб, 298x534>>76871
Это не я! Это всё драйвера опен гл ес! Вот выкачу четвёрку на вулкане и подсказки будут мигать уже при одновременно запущенном в фоне вулкан-приложении!
мимохуан
> Какой-то дурацкий баг.
Это не я! Это всё драйвера опен гл ес! Вот выкачу четвёрку на вулкане и подсказки будут мигать уже при одновременно запущенном в фоне вулкан-приложении!
мимохуан
>>76923 (Del)
Еблан наставил говна себе в винду, что она вся моргает и трисётси, а виноват конечно - кто? Ну-ка хором!
> Что тут сказать
Еблан наставил говна себе в винду, что она вся моргает и трисётси, а виноват конечно - кто? Ну-ка хором!
>>76923 (Del)
Да я просто MPC:HC пользуюсь сколько себя помню, ещё с Windows XP, не хочу переходить на какие-то непривычные свестяще-пердящие альтернативы. И это первый такой случай, чтобы MPC:HC мешал каким-либо приложениям. Но помеха минимальная, мне эти подсказки редко нужны, а поставить музыку на паузу вообще не проблема с медиа-клавишами клавиатуры. Просто баг очень странный, MPC:HC вообще-то использует DirectX, а Godot только OpenGL, при этом речь даже не о видео, а о музыке... Но каким-то мистическим образом воспроизведение музыки MPC:HC вызывает ежесекундные обновления окна редактора Godot и мигание подсказок (которые цветные с форматированием, с жёлтыми всё нормально).
>>76914
Сделай тестовую сцену и проверь сам. Мне вот порталы не нужны, у меня опенворлд и оптимизация должна быть чанками, а порталы используют только в помещениях, то есть в каких-нибудь коридорных уровнях, где игрок идёт из комнаты в комнату.
>vlc, mpv
Да я просто MPC:HC пользуюсь сколько себя помню, ещё с Windows XP, не хочу переходить на какие-то непривычные свестяще-пердящие альтернативы. И это первый такой случай, чтобы MPC:HC мешал каким-либо приложениям. Но помеха минимальная, мне эти подсказки редко нужны, а поставить музыку на паузу вообще не проблема с медиа-клавишами клавиатуры. Просто баг очень странный, MPC:HC вообще-то использует DirectX, а Godot только OpenGL, при этом речь даже не о видео, а о музыке... Но каким-то мистическим образом воспроизведение музыки MPC:HC вызывает ежесекундные обновления окна редактора Godot и мигание подсказок (которые цветные с форматированием, с жёлтыми всё нормально).
>>76914
Сделай тестовую сцену и проверь сам. Мне вот порталы не нужны, у меня опенворлд и оптимизация должна быть чанками, а порталы используют только в помещениях, то есть в каких-нибудь коридорных уровнях, где игрок идёт из комнаты в комнату.
Как делать ДЛЦ? Как бы делали вы?
Как настроить освещение, чтобы было как, например, в майнкрафте? Там на освещённых местах ярко, а в пещерах тьма, вообще ничего без источника света не видно. Я у себя настроил освещение так, чтобы тени были светлыми, но из-за этого в закрытых помещениях слишком светло... Я так понимаю, придётся динамически определять, находится ли игрок в помещении или снаружи?
>>77127
В мойнкрафте освещение считается велосипедно поиском пути по A* от кубиков
>Как настроить освещение, чтобы было как, например, в майнкрафте?
В мойнкрафте освещение считается велосипедно поиском пути по A* от кубиков
>>77127
Правильно понимаешь.
Вообще, работа со светом - отдельный параграф геймдизайна, требующий без шуток кинематографических знаний и желательно опыта. Когда ты в современных играх видишь, как освещение меняется по ходу движения, там желтеет, тут синеет, там ярче, тут глубже, - ты порой даже не задумываешься, что за этим стоит долгая (и высокооплачиваемая!) постановочная работа.
Ну а технически, в годоте, рекомендую делать это через Area. Прошёл сигнал, что камера, через которую игрок смотрит в пещере - источники света переключаются для неё в режим пещер. Так же удобно сразу подгружать в камеру соответствующий файл окружения. Думаешь это просто так Хуан сделал окружение отдельным файловым ресурсом Environment, и полем для его динамической подгрузки в камеру?
> Я так понимаю, придётся динамически определять, находится ли игрок в помещении или снаружи?
Правильно понимаешь.
Вообще, работа со светом - отдельный параграф геймдизайна, требующий без шуток кинематографических знаний и желательно опыта. Когда ты в современных играх видишь, как освещение меняется по ходу движения, там желтеет, тут синеет, там ярче, тут глубже, - ты порой даже не задумываешься, что за этим стоит долгая (и высокооплачиваемая!) постановочная работа.
Ну а технически, в годоте, рекомендую делать это через Area. Прошёл сигнал, что камера, через которую игрок смотрит в пещере - источники света переключаются для неё в режим пещер. Так же удобно сразу подгружать в камеру соответствующий файл окружения. Думаешь это просто так Хуан сделал окружение отдельным файловым ресурсом Environment, и полем для его динамической подгрузки в камеру?
Анон, расскажи перекату с первого GameMaker за Годо. Хочу запилить две игори, но не могу оценить затраты по времени, дошику и общий заеб -
1) 2D, Симулятор сетевого маркетолога. По фронту близкое к визуальной новелле, то есть набор сцен, артов персонажей, на движке упрощенной RPG со статами, прокачкой и инвентарем (без менеджмента). Возможно будет передвижение по городу аля JRPG.
2) 3D топ-довн шутан. Очень нравится эстетический лук пикрелейтед, но с 3D до этого вообще не работал и не могу осознать насколько это гемор или нет. По механикам всё стандартно на уровне технодемки: стрельба, перезарядка, смена оружия, разные параметры оружия, смэрть и сердешки. AI тоже простой, на паре стейтов типа "покой, бег к цели до дистанции атаки, атака".
На коммерцию не рассчитываю, хочу пощупать движок и воплотить идеи. Может быть потом когда-нибудь с кем-нибудь как-нибудь это будет допиливаться/перепиливаться для сторов, но сейчас цели другие.
Какие подводные? Стоит ли вообще вкатываться в Годо?
1) 2D, Симулятор сетевого маркетолога. По фронту близкое к визуальной новелле, то есть набор сцен, артов персонажей, на движке упрощенной RPG со статами, прокачкой и инвентарем (без менеджмента). Возможно будет передвижение по городу аля JRPG.
2) 3D топ-довн шутан. Очень нравится эстетический лук пикрелейтед, но с 3D до этого вообще не работал и не могу осознать насколько это гемор или нет. По механикам всё стандартно на уровне технодемки: стрельба, перезарядка, смена оружия, разные параметры оружия, смэрть и сердешки. AI тоже простой, на паре стейтов типа "покой, бег к цели до дистанции атаки, атака".
На коммерцию не рассчитываю, хочу пощупать движок и воплотить идеи. Может быть потом когда-нибудь с кем-нибудь как-нибудь это будет допиливаться/перепиливаться для сторов, но сейчас цели другие.
Какие подводные? Стоит ли вообще вкатываться в Годо?
2,8 Мб, 1280x960>>77164
Посмотри на тысячи готовых успешных законченных годот игр и ты сам себе ответишь на этот вопрос.
>Стоит ли вообще вкатываться в Годо?
Посмотри на тысячи готовых успешных законченных годот игр и ты сам себе ответишь на этот вопрос.
>>77178
Двачую. Ссылка на игры в оп-посте.
Двачую. Ссылка на игры в оп-посте.
>>77129
Про это я слышал, но меня интересует не велосипед майнкрафта, а то, как выглядит результат - светлые тени на поверхности и кромешная тьма в подземельях - и как можно добиться его в игре на Годо.
>>77167 (Del)
Как это поможет в ситуации, когда я хочу светлые тени в одном месте и тёмные тени в другом? Тени друг с другом не складываются же.
>>77159
Это если нужен реализм, а мне реализм не нужен. Я просто собрал из примитивных блоков "пещеру", прогулялся по ней, вроде всё ок - но вдруг подумал, а чё так светло-то, будто днём под деревом? И вспомнил, какая в майнкрафтовских пещерах тьма... Так что мне особых знаний и опыта не нужно, мне, надеюсь, достаточно темноту нагнать.
О, точно, а я что-то про рейкаст "в потолок" думал. Area действительно удобнее будет, я могу её шейп динамически смоделировать и объединить все ближайшие однотипные зоны в одну.
Нет, конечно, я понимаю такое решение, но не совсем ясно, как сделать переключение, да ещё и плавное. Про отдельный ресурс я, кстати, читал в блоге Overwatch - там они для Overwatch 2 изобрели какой-то велосипед, позволяющий легко менять настройки окружения для любой карты - раньше всё окружение, как я понял, запекалась в карту, из-за чего нельзя было просто так взять и изменить день на ночь, не создавая отдельной карты. Забавно, что в Godot уже давно есть то, что только собираются внедрить в ещё не вышедший сиквел Overwatch...
А про поле в камере впервые слышу, я у себя создал отдельную сцену с какой-то нодой environment и источником света, имитирующем солнце, и сделал её синглтоном. Нужно будет мануал почитать)
>велосипедно поиском пути по A* от кубиков
Про это я слышал, но меня интересует не велосипед майнкрафта, а то, как выглядит результат - светлые тени на поверхности и кромешная тьма в подземельях - и как можно добиться его в игре на Годо.
>>77167 (Del)
>можно сделать объект стены, который только отбрасывает тень
Как это поможет в ситуации, когда я хочу светлые тени в одном месте и тёмные тени в другом? Тени друг с другом не складываются же.
>>77159
>требующий без шуток кинематографических знаний и желательно опыта
Это если нужен реализм, а мне реализм не нужен. Я просто собрал из примитивных блоков "пещеру", прогулялся по ней, вроде всё ок - но вдруг подумал, а чё так светло-то, будто днём под деревом? И вспомнил, какая в майнкрафтовских пещерах тьма... Так что мне особых знаний и опыта не нужно, мне, надеюсь, достаточно темноту нагнать.
>делать это через Area
О, точно, а я что-то про рейкаст "в потолок" думал. Area действительно удобнее будет, я могу её шейп динамически смоделировать и объединить все ближайшие однотипные зоны в одну.
>Думаешь это просто так Хуан сделал окружение отдельным файловым ресурсом Environment, и полем для его динамической подгрузки в камеру?
Нет, конечно, я понимаю такое решение, но не совсем ясно, как сделать переключение, да ещё и плавное. Про отдельный ресурс я, кстати, читал в блоге Overwatch - там они для Overwatch 2 изобрели какой-то велосипед, позволяющий легко менять настройки окружения для любой карты - раньше всё окружение, как я понял, запекалась в карту, из-за чего нельзя было просто так взять и изменить день на ночь, не создавая отдельной карты. Забавно, что в Godot уже давно есть то, что только собираются внедрить в ещё не вышедший сиквел Overwatch...
А про поле в камере впервые слышу, я у себя создал отдельную сцену с какой-то нодой environment и источником света, имитирующем солнце, и сделал её синглтоном. Нужно будет мануал почитать)
>>77164
GM/GMS - это "конструктор игр", а Godot - "игровой движок", хотя и выглядит внешне как "конструктор игр". Разница в том, что конструктор даёт компоненты по типу деталек Лего, из которых любой ребёнок без опыта и знаний соберёт игру, но что-то более сложное сделать не всегда возможно, тогда как игровой движок даёт сложные программные инструменты, которые нужно изучать перед использованием, но зато и ограничений намного меньше. Однако система нод Godot сильно напоминает такие детальки Лего, просто разобраться в них сложнее и многое придётся делать самостоятельно в виде скриптов, а не кнопками на экране. Можешь рассматривать GM как Lego Duplo, а Godot - как Lego Technic.
1) Читай туториалы, там всё есть. Затраты по времени будут снижаться многократно в процессе выработки навыков.
2) Читай туториалы и не бойся, что это 3D, потому что геймплейно твоя идея 2D, и трёхмерные модельки в данном случае усложняют работу лишь художникам. 3D сложно кодить только если геймплей 3D.
Самое сложное в игре - нарисовать вменяемую графику, от которой не будет тошнить хотя бы тебя. Тем более если ты никогда графикой не занимался, в частности 3D. Закинуть модельки с текстурами в движок и заставить их двигаться - вообще очень легко в сравнении с созданием этих самых моделек и текстур...
Поскольку у тебя нет никаких конкретных запросов, стоит попробовать, а дальше сам разберёшься, продолжать или искать что-то другое. Порог входа в Godot ниже, чем у других популярных движков, он нетребователен к компьютеру, мало весит и полностью бесплатен, поэтому не вижу причин не пробовать.
>перекату с первого GameMaker за Годо
GM/GMS - это "конструктор игр", а Godot - "игровой движок", хотя и выглядит внешне как "конструктор игр". Разница в том, что конструктор даёт компоненты по типу деталек Лего, из которых любой ребёнок без опыта и знаний соберёт игру, но что-то более сложное сделать не всегда возможно, тогда как игровой движок даёт сложные программные инструменты, которые нужно изучать перед использованием, но зато и ограничений намного меньше. Однако система нод Godot сильно напоминает такие детальки Лего, просто разобраться в них сложнее и многое придётся делать самостоятельно в виде скриптов, а не кнопками на экране. Можешь рассматривать GM как Lego Duplo, а Godot - как Lego Technic.
>оценить затраты по времени
1) Читай туториалы, там всё есть. Затраты по времени будут снижаться многократно в процессе выработки навыков.
2) Читай туториалы и не бойся, что это 3D, потому что геймплейно твоя идея 2D, и трёхмерные модельки в данном случае усложняют работу лишь художникам. 3D сложно кодить только если геймплей 3D.
>Какие подводные?
Самое сложное в игре - нарисовать вменяемую графику, от которой не будет тошнить хотя бы тебя. Тем более если ты никогда графикой не занимался, в частности 3D. Закинуть модельки с текстурами в движок и заставить их двигаться - вообще очень легко в сравнении с созданием этих самых моделек и текстур...
>Стоит ли вообще вкатываться в Годо?
Поскольку у тебя нет никаких конкретных запросов, стоит попробовать, а дальше сам разберёшься, продолжать или искать что-то другое. Порог входа в Godot ниже, чем у других популярных движков, он нетребователен к компьютеру, мало весит и полностью бесплатен, поэтому не вижу причин не пробовать.
>>77178
Не вижу прямой связи между количеством успешных игр и движком. Может, дело в игроделах? Или фазе Луны?
>>77214
Вопрос скорее был именно про актуальность движка и его выбор в рамках специфики конкретных игр. По тому же GMS я могу сказать - да, это конструктор. Он дает больше возможностей если писать код, а не дропать компоненты. Но вывозит что-то дальше геймджемов он с трудом. Быстрое прототипирование и возможность писать костыли - это плюс на короткосроке и в мелких проектах, но на дальней дистанции лично я заработал смерть жопы, пытаясь развить игру во что-то большее. Плюс готовых решений практически нет - от освещения до UI, всё нужно костылить самому, а это тянет за собой необходимость курить дохера материалов и учиться разбираться во всём вообще. Даже поддержка Steam SDK барахлит, и на долгосроке вылезает косяками, помимо непонятных ошибок с исчезающими ключевыми объектами и данными.
Возможно это я криворукий, наиболее вероятно так и есть. Тем не менее.
Поэтому вопрос так верхнеуровнево и звучит - стоит ли в Годо? Потому что я не могу предвидеть все подводные, это можно озвучить только человек который плотно елозится с движком уже год, а лучше и не один. По тому что я успел увидеть в гайдах и в выдаче на ютабе - выглядит слишком оптимистично и идеально. Запнулся только о сигналы, какой-то люто абстрактный прекол, суть вроде бы ясна, а имплементация душит. В остальном выглядит как райский рай где всё модульно, для UI всё готово, освещение, камеры, вагон готовых нодов, скелетная анимация, 2Д, 3Д, и просто уруру и уняня. Тут и возникает вопрос - а какие подводные, и почему еще весь геймдев не перешел на Годо? Дело в движке, или в геймдеве?
Не вижу прямой связи между количеством успешных игр и движком. Может, дело в игроделах? Или фазе Луны?
>>77214
Вопрос скорее был именно про актуальность движка и его выбор в рамках специфики конкретных игр. По тому же GMS я могу сказать - да, это конструктор. Он дает больше возможностей если писать код, а не дропать компоненты. Но вывозит что-то дальше геймджемов он с трудом. Быстрое прототипирование и возможность писать костыли - это плюс на короткосроке и в мелких проектах, но на дальней дистанции лично я заработал смерть жопы, пытаясь развить игру во что-то большее. Плюс готовых решений практически нет - от освещения до UI, всё нужно костылить самому, а это тянет за собой необходимость курить дохера материалов и учиться разбираться во всём вообще. Даже поддержка Steam SDK барахлит, и на долгосроке вылезает косяками, помимо непонятных ошибок с исчезающими ключевыми объектами и данными.
Возможно это я криворукий, наиболее вероятно так и есть. Тем не менее.
Поэтому вопрос так верхнеуровнево и звучит - стоит ли в Годо? Потому что я не могу предвидеть все подводные, это можно озвучить только человек который плотно елозится с движком уже год, а лучше и не один. По тому что я успел увидеть в гайдах и в выдаче на ютабе - выглядит слишком оптимистично и идеально. Запнулся только о сигналы, какой-то люто абстрактный прекол, суть вроде бы ясна, а имплементация душит. В остальном выглядит как райский рай где всё модульно, для UI всё готово, освещение, камеры, вагон готовых нодов, скелетная анимация, 2Д, 3Д, и просто уруру и уняня. Тут и возникает вопрос - а какие подводные, и почему еще весь геймдев не перешел на Годо? Дело в движке, или в геймдеве?
>>77274
Проблема в годоте - комплексные ноды работают как говно. Ими никто не пользуется. Все что больше кнопки или лейбла уродливо.
Проблемы с оптимизацией. Boolean весит 1 байт. Некоторые решения сделаны очень топорно и будут фризить даже на небольшом количестве данных. Типа выполнение кода с# в первый раз, добавление партиклов в первый раз, некоторых шейдерочков на сцены. Надо делать кучу пустых нод чтобы делать слои шейдеров. Написание 1 буквы вызывает 1 драв колл. Буквы с большим шрифтом (100-200+) будут ещё сжирать видеопамять. Конкретной клетке в тайлмапе нельзя задать высоту, поэтому придется всегда костылить свою тайлмапу. Шейдеры не могут выпукивать свои данные в другие шейдеры или быть зациклены от текущего состояния экрана.
В остальном, особенно для 2д, норм.
Проблема в годоте - комплексные ноды работают как говно. Ими никто не пользуется. Все что больше кнопки или лейбла уродливо.
Проблемы с оптимизацией. Boolean весит 1 байт. Некоторые решения сделаны очень топорно и будут фризить даже на небольшом количестве данных. Типа выполнение кода с# в первый раз, добавление партиклов в первый раз, некоторых шейдерочков на сцены. Надо делать кучу пустых нод чтобы делать слои шейдеров. Написание 1 буквы вызывает 1 драв колл. Буквы с большим шрифтом (100-200+) будут ещё сжирать видеопамять. Конкретной клетке в тайлмапе нельзя задать высоту, поэтому придется всегда костылить свою тайлмапу. Шейдеры не могут выпукивать свои данные в другие шейдеры или быть зациклены от текущего состояния экрана.
В остальном, особенно для 2д, норм.
>>77274
Движок регулярно обновляется большой группой людей на гитхабе, в следующем году должна выйти версия 4.0, которая исправит массу недоработок.
Годо универсален. Есть, конечно, игры, для которых текущая версия Годо не очень подходит - это игры, в которых нужно выжимать из железа максимум производительности, т.е. оптимизировать игру на очень низком уровне абстракции. Твои идеи ничего такого не содержат, это обычные игры.
Ну, в Годо такие базовые вещи есть, но всё равно придётся многое самостоятельно делать под свою игру, если она необычная.
Разделяешь игру на независимые компоненты и проблем с гибкостью расширения контента и механик не будет, в этом вся суть нодовой системы Годо. Проблема может быть, если будет слишком много нод в дереве сцены (десятки тысяч), тут уже придётся думать над оптимизациями (например, объединять сотни мешей в один).
У всех свои игры мечты, соответственно разные подводные камни. Я вот хочу опенворлд песочницу с физикой, Годо сейчас для этого не очень подходит, но у тебя же идеи намного проще.
Рассматривай их как события из таких средств разработки, как Delphi/Lazarus, а ещё это похоже на события HTML страниц, которые обрабатывают JS функции. Пример: пользователь нажимает кнопку на экране, это генерирует событие а.к.а. сигнал "кнопка нажата", дальше движок смотрит, какие обработчики (функции) ждут это событие/сигнал, и вызывает их как обычные функции. Это позволяет разнести по разным местам генераторы событий и обработчики событий, объединяя их между собой динамически по мере необходимости.
У юнити была агрессивная политика пиара, благодаря которой она за последнее десятилетие заработала бешеную популярность. Хочешь сделать игру и гуглишь "как сделать игру"? В первых строчках выдачи юнити. Ищешь видео по геймдеву на ютубе? Они все про юнити. Ищешь платные курсы? Там всё про юнити. Ищешь вакансии? Кроме юнити ничего нет. Естественно, если ты совсем нуб, то выберешь то, что у всех на слуху. А потом привыкнешь и будешь мириться со всеми недостатками из-за синдрома утёнка и привычек. Большинство юзают то, что им пропихнули хитрые маркетологи юнити, и они довольны этим, потому что нетребовательны. Если бы у Годо была такая же агрессивная политика пиара, он бы легко превзошёл все остальные движки, но откуда у опенсурса деньги на хитрых маркетологов и пиар-компании? У опенсурса есть только преданные поклонники, которые чисто на энтузиазме рассказывают знакомым о том, как им помогает конкретный продукт, но их усилий недостаточно, чтобы превзойти пиар-компании гигантов рынка.
Ну а что касается крупных коммерческих компаний, у них обычно либо свой собственный движок, либо соглашение с одной из таких же крупных коммерческих компаний, там совершенно другой уровень геймдева, не то, что у инди и любителей опенсурса.
Засим предлагаю свернуть это обсуждение, если хочешь делать игры - просто качай движок, читай мануал и следуй туториалам, если что-то категорически не нравится - ищи другой движок, в чём проблема?
>актуальность движка
Движок регулярно обновляется большой группой людей на гитхабе, в следующем году должна выйти версия 4.0, которая исправит массу недоработок.
>специфики конкретных игр
Годо универсален. Есть, конечно, игры, для которых текущая версия Годо не очень подходит - это игры, в которых нужно выжимать из железа максимум производительности, т.е. оптимизировать игру на очень низком уровне абстракции. Твои идеи ничего такого не содержат, это обычные игры.
>готовых решений практически нет - от освещения до UI
Ну, в Годо такие базовые вещи есть, но всё равно придётся многое самостоятельно делать под свою игру, если она необычная.
>развить игру во что-то большее
Разделяешь игру на независимые компоненты и проблем с гибкостью расширения контента и механик не будет, в этом вся суть нодовой системы Годо. Проблема может быть, если будет слишком много нод в дереве сцены (десятки тысяч), тут уже придётся думать над оптимизациями (например, объединять сотни мешей в один).
>человек который плотно елозится с движком уже год
У всех свои игры мечты, соответственно разные подводные камни. Я вот хочу опенворлд песочницу с физикой, Годо сейчас для этого не очень подходит, но у тебя же идеи намного проще.
>Запнулся только о сигналы
Рассматривай их как события из таких средств разработки, как Delphi/Lazarus, а ещё это похоже на события HTML страниц, которые обрабатывают JS функции. Пример: пользователь нажимает кнопку на экране, это генерирует событие а.к.а. сигнал "кнопка нажата", дальше движок смотрит, какие обработчики (функции) ждут это событие/сигнал, и вызывает их как обычные функции. Это позволяет разнести по разным местам генераторы событий и обработчики событий, объединяя их между собой динамически по мере необходимости.
>почему еще весь геймдев не перешел на Годо?
У юнити была агрессивная политика пиара, благодаря которой она за последнее десятилетие заработала бешеную популярность. Хочешь сделать игру и гуглишь "как сделать игру"? В первых строчках выдачи юнити. Ищешь видео по геймдеву на ютубе? Они все про юнити. Ищешь платные курсы? Там всё про юнити. Ищешь вакансии? Кроме юнити ничего нет. Естественно, если ты совсем нуб, то выберешь то, что у всех на слуху. А потом привыкнешь и будешь мириться со всеми недостатками из-за синдрома утёнка и привычек. Большинство юзают то, что им пропихнули хитрые маркетологи юнити, и они довольны этим, потому что нетребовательны. Если бы у Годо была такая же агрессивная политика пиара, он бы легко превзошёл все остальные движки, но откуда у опенсурса деньги на хитрых маркетологов и пиар-компании? У опенсурса есть только преданные поклонники, которые чисто на энтузиазме рассказывают знакомым о том, как им помогает конкретный продукт, но их усилий недостаточно, чтобы превзойти пиар-компании гигантов рынка.
Ну а что касается крупных коммерческих компаний, у них обычно либо свой собственный движок, либо соглашение с одной из таких же крупных коммерческих компаний, там совершенно другой уровень геймдева, не то, что у инди и любителей опенсурса.
Засим предлагаю свернуть это обсуждение, если хочешь делать игры - просто качай движок, читай мануал и следуй туториалам, если что-то категорически не нравится - ищи другой движок, в чём проблема?
>>77274
Движок регулярно обновляется большой группой людей на гитхабе, в следующем году должна выйти версия 4.0, которая исправит массу недоработок.
Годо универсален. Есть, конечно, игры, для которых текущая версия Годо не очень подходит - это игры, в которых нужно выжимать из железа максимум производительности, т.е. оптимизировать игру на очень низком уровне абстракции. Твои идеи ничего такого не содержат, это обычные игры.
Ну, в Годо такие базовые вещи есть, но всё равно придётся многое самостоятельно делать под свою игру, если она необычная.
Разделяешь игру на независимые компоненты и проблем с гибкостью расширения контента и механик не будет, в этом вся суть нодовой системы Годо. Проблема может быть, если будет слишком много нод в дереве сцены (десятки тысяч), тут уже придётся думать над оптимизациями (например, объединять сотни мешей в один).
У всех свои игры мечты, соответственно разные подводные камни. Я вот хочу опенворлд песочницу с физикой, Годо сейчас для этого не очень подходит, но у тебя же идеи намного проще.
Рассматривай их как события из таких средств разработки, как Delphi/Lazarus, а ещё это похоже на события HTML страниц, которые обрабатывают JS функции. Пример: пользователь нажимает кнопку на экране, это генерирует событие а.к.а. сигнал "кнопка нажата", дальше движок смотрит, какие обработчики (функции) ждут это событие/сигнал, и вызывает их как обычные функции. Это позволяет разнести по разным местам генераторы событий и обработчики событий, объединяя их между собой динамически по мере необходимости.
У юнити была агрессивная политика пиара, благодаря которой она за последнее десятилетие заработала бешеную популярность. Хочешь сделать игру и гуглишь "как сделать игру"? В первых строчках выдачи юнити. Ищешь видео по геймдеву на ютубе? Они все про юнити. Ищешь платные курсы? Там всё про юнити. Ищешь вакансии? Кроме юнити ничего нет. Естественно, если ты совсем нуб, то выберешь то, что у всех на слуху. А потом привыкнешь и будешь мириться со всеми недостатками из-за синдрома утёнка и привычек. Большинство юзают то, что им пропихнули хитрые маркетологи юнити, и они довольны этим, потому что нетребовательны. Если бы у Годо была такая же агрессивная политика пиара, он бы легко превзошёл все остальные движки, но откуда у опенсурса деньги на хитрых маркетологов и пиар-компании? У опенсурса есть только преданные поклонники, которые чисто на энтузиазме рассказывают знакомым о том, как им помогает конкретный продукт, но их усилий недостаточно, чтобы превзойти пиар-компании гигантов рынка.
Ну а что касается крупных коммерческих компаний, у них обычно либо свой собственный движок, либо соглашение с одной из таких же крупных коммерческих компаний, там совершенно другой уровень геймдева, не то, что у инди и любителей опенсурса.
Засим предлагаю свернуть это обсуждение, если хочешь делать игры - просто качай движок, читай мануал и следуй туториалам, если что-то категорически не нравится - ищи другой движок, в чём проблема?
>актуальность движка
Движок регулярно обновляется большой группой людей на гитхабе, в следующем году должна выйти версия 4.0, которая исправит массу недоработок.
>специфики конкретных игр
Годо универсален. Есть, конечно, игры, для которых текущая версия Годо не очень подходит - это игры, в которых нужно выжимать из железа максимум производительности, т.е. оптимизировать игру на очень низком уровне абстракции. Твои идеи ничего такого не содержат, это обычные игры.
>готовых решений практически нет - от освещения до UI
Ну, в Годо такие базовые вещи есть, но всё равно придётся многое самостоятельно делать под свою игру, если она необычная.
>развить игру во что-то большее
Разделяешь игру на независимые компоненты и проблем с гибкостью расширения контента и механик не будет, в этом вся суть нодовой системы Годо. Проблема может быть, если будет слишком много нод в дереве сцены (десятки тысяч), тут уже придётся думать над оптимизациями (например, объединять сотни мешей в один).
>человек который плотно елозится с движком уже год
У всех свои игры мечты, соответственно разные подводные камни. Я вот хочу опенворлд песочницу с физикой, Годо сейчас для этого не очень подходит, но у тебя же идеи намного проще.
>Запнулся только о сигналы
Рассматривай их как события из таких средств разработки, как Delphi/Lazarus, а ещё это похоже на события HTML страниц, которые обрабатывают JS функции. Пример: пользователь нажимает кнопку на экране, это генерирует событие а.к.а. сигнал "кнопка нажата", дальше движок смотрит, какие обработчики (функции) ждут это событие/сигнал, и вызывает их как обычные функции. Это позволяет разнести по разным местам генераторы событий и обработчики событий, объединяя их между собой динамически по мере необходимости.
>почему еще весь геймдев не перешел на Годо?
У юнити была агрессивная политика пиара, благодаря которой она за последнее десятилетие заработала бешеную популярность. Хочешь сделать игру и гуглишь "как сделать игру"? В первых строчках выдачи юнити. Ищешь видео по геймдеву на ютубе? Они все про юнити. Ищешь платные курсы? Там всё про юнити. Ищешь вакансии? Кроме юнити ничего нет. Естественно, если ты совсем нуб, то выберешь то, что у всех на слуху. А потом привыкнешь и будешь мириться со всеми недостатками из-за синдрома утёнка и привычек. Большинство юзают то, что им пропихнули хитрые маркетологи юнити, и они довольны этим, потому что нетребовательны. Если бы у Годо была такая же агрессивная политика пиара, он бы легко превзошёл все остальные движки, но откуда у опенсурса деньги на хитрых маркетологов и пиар-компании? У опенсурса есть только преданные поклонники, которые чисто на энтузиазме рассказывают знакомым о том, как им помогает конкретный продукт, но их усилий недостаточно, чтобы превзойти пиар-компании гигантов рынка.
Ну а что касается крупных коммерческих компаний, у них обычно либо свой собственный движок, либо соглашение с одной из таких же крупных коммерческих компаний, там совершенно другой уровень геймдева, не то, что у инди и любителей опенсурса.
Засим предлагаю свернуть это обсуждение, если хочешь делать игры - просто качай движок, читай мануал и следуй туториалам, если что-то категорически не нравится - ищи другой движок, в чём проблема?
>>77286
Какие именно? KinematicBody пофиксили в 3.4, теперь нормально на движущиеся платформы реагирует.
Были какие-то опросы?
В каком смысле? Я вот пробовал разные UI элементы - всё нормально, как в старые добрые времена и даже лучше благодаря темам.
Это во всех языках так, побитовая упаковка флагов - отдельная фича, которая далеко не везде есть, тем более в скриптовых ЯП. Вряд ли тебе нужны огромные массивы флагов в обычной игре, если ты не под микроконтроллеры пишешь.
Это JIT-компиляция. Не используй C#, раз не нравится. В юнити ты вынужден ждать перекомпиляции всех скриптов игры несколько минут, а здесь ты запускаешь игру сразу, без компиляции.
Это ленивая компиляция шейдеров - особенность OpenGL, а не движка. Решается скрытным добавлением материалов на сцену во время загрузки игры, чтобы вызвать компиляцию принудительно.
Это уже давно пофиксили 2D батчингом.
Так для этого нужно несколько тайлмапов на сцене, это вроде стандартная практика в изометрических тайловых картах.
Все проблемы шейдеров скорее всего из-за поддержки OpenGL 2.1, WebGL 1.0 и OpenGL ES одновременно. Ограничения разных платформ суммируются, иначе кроссплатформы "в один клик" не видать.
На счёт остального не знаю, не сталкивался.
>комплексные ноды работают как говно.
Какие именно? KinematicBody пофиксили в 3.4, теперь нормально на движущиеся платформы реагирует.
>Ими никто не пользуется.
Были какие-то опросы?
>Все что больше кнопки или лейбла уродливо.
В каком смысле? Я вот пробовал разные UI элементы - всё нормально, как в старые добрые времена и даже лучше благодаря темам.
>Boolean весит 1 байт
Это во всех языках так, побитовая упаковка флагов - отдельная фича, которая далеко не везде есть, тем более в скриптовых ЯП. Вряд ли тебе нужны огромные массивы флагов в обычной игре, если ты не под микроконтроллеры пишешь.
>Типа выполнение кода с# в первый раз
Это JIT-компиляция. Не используй C#, раз не нравится. В юнити ты вынужден ждать перекомпиляции всех скриптов игры несколько минут, а здесь ты запускаешь игру сразу, без компиляции.
>добавление партиклов в первый раз, некоторых шейдерочков на сцены.
Это ленивая компиляция шейдеров - особенность OpenGL, а не движка. Решается скрытным добавлением материалов на сцену во время загрузки игры, чтобы вызвать компиляцию принудительно.
>Написание 1 буквы вызывает 1 драв колл.
Это уже давно пофиксили 2D батчингом.
>клетке в тайлмапе нельзя задать высоту
Так для этого нужно несколько тайлмапов на сцене, это вроде стандартная практика в изометрических тайловых картах.
>Шейдеры
Все проблемы шейдеров скорее всего из-за поддержки OpenGL 2.1, WebGL 1.0 и OpenGL ES одновременно. Ограничения разных платформ суммируются, иначе кроссплатформы "в один клик" не видать.
На счёт остального не знаю, не сталкивался.
>>77332
А ты с какой целью интересуешься?
Для простых задач лучше GDScript ничего нет. Для сложных задач лучше всего писать модули для движка на C++ или использовать GDNative. C# в Godot, по-моему, только для привлечения зумерков, которые ничего кроме юнити никогда в жизни не видели.
Алсо не понимаю, как сочетается опенсурс и порождение Micro$oft, которое суть клонированная Java без блекджека и без шлюх...
А ты с какой целью интересуешься?
Для простых задач лучше GDScript ничего нет. Для сложных задач лучше всего писать модули для движка на C++ или использовать GDNative. C# в Godot, по-моему, только для привлечения зумерков, которые ничего кроме юнити никогда в жизни не видели.
Алсо не понимаю, как сочетается опенсурс и порождение Micro$oft, которое суть клонированная Java без блекджека и без шлюх...
>>77391
интерес больше вызывал выбор пользователей и их отношение к тому или иному языку.
интерес больше вызывал выбор пользователей и их отношение к тому или иному языку.
Годаны, расскажите, плиз, как получается распрыжка у спидранеров в старых шутанах? Меня интересует техническая часть. Какую ошибку допускали разработчики ФП-контроллера, что позволяло наращивать скорость при определенных действиях?
>>77391
Человек слаб. Если тебе дают многотысячный донат с условием, что ты их язык нативно интегрируешь в свой продукт, - сложно отказаться.
> Алсо не понимаю, как сочетается опенсурс и порождение Micro$oft
Человек слаб. Если тебе дают многотысячный донат с условием, что ты их язык нативно интегрируешь в свой продукт, - сложно отказаться.
>>77403
множитель скорости, которая дамперилась от времени. если множить быстрее чем идет дамперинг - получается упс
множитель скорости, которая дамперилась от времени. если множить быстрее чем идет дамперинг - получается упс
>>77391
Уж что-то, а бэкджека и шлюх в шарпе немеряно. Джава очень убогий язык по сравнению с шарпом, ни перегрузки операторов, ни нормальных дженериков, ни типов-значений, дохрена чего нет.
>суть клонированная Java без блекджека и без шлюх
Уж что-то, а бэкджека и шлюх в шарпе немеряно. Джава очень убогий язык по сравнению с шарпом, ни перегрузки операторов, ни нормальных дженериков, ни типов-значений, дохрена чего нет.
>>77419 (Del)
Хоспаде, как же много надо знать, чтобы игроки проходили мою игру как я задумал, а не скипали большую часть контента.
Хоспаде, как же много надо знать, чтобы игроки проходили мою игру как я задумал, а не скипали большую часть контента.
>>77418 (Del)
Он включает галочку для гладкого геймплея?
Он включает галочку для гладкого геймплея?
Годаны! Как сделать, чтобы при удалении от игрока мобы уменьшали свой ФПС, как в большинстве современных игор, и экономили ресурсы компа?
На ум приходит доропать функции _process по таймеру, что-то типа if timer < distance: return
На ум приходит доропать функции _process по таймеру, что-то типа if timer < distance: return
>>77471
Они в любом случае найдут способ сломать игру. Если у тебя в одиночной игре есть, например, валюта, патроны или любое другое часто изменяющееся по желанию игрока число, обязательно найдётся умник, который накрутит её с помощью Cheat Engine. Короче, не парься и делай просто хорошую игру, кому нужно - тот пройдёт её именно так, как ты задумывал.
>>77506
А они у тебя точно эти ресурсы потребляют больше необходимого? Что у тебя там за код каждый кадр выполняется, что нужно именно от расстояния зависимость вводить?
Мне на ум такое решение приходит: разделить мир на чанки, каждому чанку назначить отдельный таймер, таймер будет обновлять состояния мобов вместо process. Игрок, приближаясь к чанку, увеличивает частоту срабатывания таймера чанка и снижает частоту предыдущих чанков. Моб, переходя из чанка в чанк, переключается с одного таймера на другой. Связь таймер-моб, разумеется, через сигналы. Такая система позволит избежать вычисления расстояния от моба до игрока каждым мобом каждый кадр, что звучит очень избыточно. В системе чанков переключение таймеров происходит только когда игрок пройдёт некоторое расстояние, сами таймеры не крутят циклы впустую, а переключение с таймера на таймер вряд ли будет частым - но это зависит от размера чанков и поведения твоих мобов.
>как я задумал
Они в любом случае найдут способ сломать игру. Если у тебя в одиночной игре есть, например, валюта, патроны или любое другое часто изменяющееся по желанию игрока число, обязательно найдётся умник, который накрутит её с помощью Cheat Engine. Короче, не парься и делай просто хорошую игру, кому нужно - тот пройдёт её именно так, как ты задумывал.
>>77506
>мобы уменьшали свой ФПС
>экономили ресурсы компа
А они у тебя точно эти ресурсы потребляют больше необходимого? Что у тебя там за код каждый кадр выполняется, что нужно именно от расстояния зависимость вводить?
Мне на ум такое решение приходит: разделить мир на чанки, каждому чанку назначить отдельный таймер, таймер будет обновлять состояния мобов вместо process. Игрок, приближаясь к чанку, увеличивает частоту срабатывания таймера чанка и снижает частоту предыдущих чанков. Моб, переходя из чанка в чанк, переключается с одного таймера на другой. Связь таймер-моб, разумеется, через сигналы. Такая система позволит избежать вычисления расстояния от моба до игрока каждым мобом каждый кадр, что звучит очень избыточно. В системе чанков переключение таймеров происходит только когда игрок пройдёт некоторое расстояние, сами таймеры не крутят циклы впустую, а переключение с таймера на таймер вряд ли будет частым - но это зависит от размера чанков и поведения твоих мобов.
>>77510
Селектор стейтмашины, который выбирает стейт по обширному набору входных данных, например, голод-жажда, агрессия, состояние погоды в локации, суета в локации, нахождение враждебных сущностей в зонах обнаружения (видимости, слышимости). Ну и еще там по мелочи.
> Что у тебя там за код каждый кадр выполняется
Селектор стейтмашины, который выбирает стейт по обширному набору входных данных, например, голод-жажда, агрессия, состояние погоды в локации, суета в локации, нахождение враждебных сущностей в зонах обнаружения (видимости, слышимости). Ну и еще там по мелочи.
Оказывается и такое делается:
https://github.com/godotengine/godot/pull/36776
Скачать без смс и регистрации:
https://mega.nz/folder/u6IHQI4R#OLMeA8tqwWL_2T8vEo6CRQ
Только что попробовал сентябрьский билд. На моём смартфоне элементы управления слишком мелкие, пальцем тяжело попасть - масштаб для полноценного FullHD экрана. Подключил мышку с клавиатурой через OTG - управляется нормально, почти как на ПК, хотя сцену вращать я не смог (ПКМ/СКМ закрывают приложение, т.к. их перехватывает ОС, воспринимая как "назад"/"домой"). Рендеринг 3D (мобильный вулкан) так и не завёлся, а в редакторе на вкладке 3D сильные тормоза (GPU на 100%) и текстуры не отображаются. Но 2D рендерится нормально и без тормозов. Попробовал сделать визуальный скрипт - редактируется и запускается нормально. Но в какой-то момент экран стал на каждое нажатие мигать оранжевым, пришлось перезагружать проект. Также в настройках проекта почему-то нет очень многих опций, там почти ничего нет по сравнению с 3.4.
Короче, штука пока неюзабельная и вряд ли когда-нибудь будет юзабельной на смартфонах, не подключать же каждый раз мышку с клавиатурой. В лучшем случае на планшетах с HD разрешением или если масштабировать интерфейс. А жаль, было бы здорово иметь специальную мобильную версию, с мобильным (вертикальным) интерфейсом...
Алсо, я не понял, они совсем от поддержки OpenGL избавляются?
https://github.com/godotengine/godot/pull/36776
Скачать без смс и регистрации:
https://mega.nz/folder/u6IHQI4R#OLMeA8tqwWL_2T8vEo6CRQ
Только что попробовал сентябрьский билд. На моём смартфоне элементы управления слишком мелкие, пальцем тяжело попасть - масштаб для полноценного FullHD экрана. Подключил мышку с клавиатурой через OTG - управляется нормально, почти как на ПК, хотя сцену вращать я не смог (ПКМ/СКМ закрывают приложение, т.к. их перехватывает ОС, воспринимая как "назад"/"домой"). Рендеринг 3D (мобильный вулкан) так и не завёлся, а в редакторе на вкладке 3D сильные тормоза (GPU на 100%) и текстуры не отображаются. Но 2D рендерится нормально и без тормозов. Попробовал сделать визуальный скрипт - редактируется и запускается нормально. Но в какой-то момент экран стал на каждое нажатие мигать оранжевым, пришлось перезагружать проект. Также в настройках проекта почему-то нет очень многих опций, там почти ничего нет по сравнению с 3.4.
Короче, штука пока неюзабельная и вряд ли когда-нибудь будет юзабельной на смартфонах, не подключать же каждый раз мышку с клавиатурой. В лучшем случае на планшетах с HD разрешением или если масштабировать интерфейс. А жаль, было бы здорово иметь специальную мобильную версию, с мобильным (вертикальным) интерфейсом...
Алсо, я не понял, они совсем от поддержки OpenGL избавляются?
>>77506
>>77526
Зачем тебе всё это каждый кадр проверять? Если у игрока монитор, допустим, 240 Гц, твои мобы будут каждые 4 мс интересоваться состоянием погоды - зачем? Если, допустим, пошёл дождь, менеджер погоды должен разослать всем мобам предупреждение, что они должны изменить поведение соответственно погоде. Желудок моба вполне может обновляться раз в секунду или намного реже, а изменение поведения будет только при определённом % заполненности. "Суета" может проверяться общим для локации менеджером раз в несколько секунд, далее аналогично погоде. Агрессия должна исходить, очевидно, от агрессора. И так далее. Если тебе прям очень нужно все состояния проверять - можно делать это в момент изменения одного из состояний. Так моб, который отдыхает в одиночестве в комнате, вообще не будет ничего делать, пока кто-нибудь или что-нибудь (включая его внутренние органы) не повлияет на него.
Собственно для этого сигналы и нужны, моб подключается слушателем к нескольким разным системам и ждёт сигналов, которые изменят его поведение. Т.е. вместо взгляда в облака каждые 4 мс моб просто почувствует падение капель на его голову, или почувствует, что капли перестали падать. Аналогично с желудком, он почувствует голод, когда желудок переварит пищу, а не будет каждые 4 мс проверять наполненность своего желудка.
Также, насколько я понимаю, для принятия решений не обязательно проверять все возможные параметры. У каждого параметра для каждого решения должен быть приоритет, например, для решения "убежать от врага" параметрами с наивысшим приоритетом будут "присутствие врага" и "состояние здоровья" - тяжело раненный моб попытается убежать от врага независимо от текущей погоды, наполненности желудка и т.д. Это также должно ускорить вычисления, особенно если у тебя сотни/тысячи параметров.
>_process
>>77526
>выбирает стейт по обширному набору входных данных, например, голод-жажда, агрессия, состояние погоды в локации, суета в локации, нахождение враждебных сущностей в зонах обнаружения (видимости, слышимости)
Зачем тебе всё это каждый кадр проверять? Если у игрока монитор, допустим, 240 Гц, твои мобы будут каждые 4 мс интересоваться состоянием погоды - зачем? Если, допустим, пошёл дождь, менеджер погоды должен разослать всем мобам предупреждение, что они должны изменить поведение соответственно погоде. Желудок моба вполне может обновляться раз в секунду или намного реже, а изменение поведения будет только при определённом % заполненности. "Суета" может проверяться общим для локации менеджером раз в несколько секунд, далее аналогично погоде. Агрессия должна исходить, очевидно, от агрессора. И так далее. Если тебе прям очень нужно все состояния проверять - можно делать это в момент изменения одного из состояний. Так моб, который отдыхает в одиночестве в комнате, вообще не будет ничего делать, пока кто-нибудь или что-нибудь (включая его внутренние органы) не повлияет на него.
Собственно для этого сигналы и нужны, моб подключается слушателем к нескольким разным системам и ждёт сигналов, которые изменят его поведение. Т.е. вместо взгляда в облака каждые 4 мс моб просто почувствует падение капель на его голову, или почувствует, что капли перестали падать. Аналогично с желудком, он почувствует голод, когда желудок переварит пищу, а не будет каждые 4 мс проверять наполненность своего желудка.
Также, насколько я понимаю, для принятия решений не обязательно проверять все возможные параметры. У каждого параметра для каждого решения должен быть приоритет, например, для решения "убежать от врага" параметрами с наивысшим приоритетом будут "присутствие врага" и "состояние здоровья" - тяжело раненный моб попытается убежать от врага независимо от текущей погоды, наполненности желудка и т.д. Это также должно ускорить вычисления, особенно если у тебя сотни/тысячи параметров.
>>77506
>>77526
Зачем тебе всё это каждый кадр проверять? Если у игрока монитор, допустим, 240 Гц, твои мобы будут каждые 4 мс интересоваться состоянием погоды - зачем? Если, допустим, пошёл дождь, менеджер погоды должен разослать всем мобам предупреждение, что они должны изменить поведение соответственно погоде. Желудок моба вполне может обновляться раз в секунду или намного реже, а изменение поведения будет только при определённом % заполненности. "Суета" может проверяться общим для локации менеджером раз в несколько секунд, далее аналогично погоде. Агрессия должна исходить, очевидно, от агрессора. И так далее. Если тебе прям очень нужно все состояния проверять - можно делать это в момент изменения одного из состояний. Так моб, который отдыхает в одиночестве в комнате, вообще не будет ничего делать, пока кто-нибудь или что-нибудь (включая его внутренние органы) не повлияет на него.
Собственно для этого сигналы и нужны, моб подключается слушателем к нескольким разным системам и ждёт сигналов, которые изменят его поведение. Т.е. вместо взгляда в облака каждые 4 мс моб просто почувствует падение капель на его голову, или почувствует, что капли перестали падать. Аналогично с желудком, он почувствует голод, когда желудок переварит пищу, а не будет каждые 4 мс проверять наполненность своего желудка.
Также, насколько я понимаю, для принятия решений не обязательно проверять все возможные параметры. У каждого параметра для каждого решения должен быть приоритет, например, для решения "убежать от врага" параметрами с наивысшим приоритетом будут "присутствие врага" и "состояние здоровья" - тяжело раненный моб попытается убежать от врага независимо от текущей погоды, наполненности желудка и т.д. Это также должно ускорить вычисления, особенно если у тебя сотни/тысячи параметров.
>_process
>>77526
>выбирает стейт по обширному набору входных данных, например, голод-жажда, агрессия, состояние погоды в локации, суета в локации, нахождение враждебных сущностей в зонах обнаружения (видимости, слышимости)
Зачем тебе всё это каждый кадр проверять? Если у игрока монитор, допустим, 240 Гц, твои мобы будут каждые 4 мс интересоваться состоянием погоды - зачем? Если, допустим, пошёл дождь, менеджер погоды должен разослать всем мобам предупреждение, что они должны изменить поведение соответственно погоде. Желудок моба вполне может обновляться раз в секунду или намного реже, а изменение поведения будет только при определённом % заполненности. "Суета" может проверяться общим для локации менеджером раз в несколько секунд, далее аналогично погоде. Агрессия должна исходить, очевидно, от агрессора. И так далее. Если тебе прям очень нужно все состояния проверять - можно делать это в момент изменения одного из состояний. Так моб, который отдыхает в одиночестве в комнате, вообще не будет ничего делать, пока кто-нибудь или что-нибудь (включая его внутренние органы) не повлияет на него.
Собственно для этого сигналы и нужны, моб подключается слушателем к нескольким разным системам и ждёт сигналов, которые изменят его поведение. Т.е. вместо взгляда в облака каждые 4 мс моб просто почувствует падение капель на его голову, или почувствует, что капли перестали падать. Аналогично с желудком, он почувствует голод, когда желудок переварит пищу, а не будет каждые 4 мс проверять наполненность своего желудка.
Также, насколько я понимаю, для принятия решений не обязательно проверять все возможные параметры. У каждого параметра для каждого решения должен быть приоритет, например, для решения "убежать от врага" параметрами с наивысшим приоритетом будут "присутствие врага" и "состояние здоровья" - тяжело раненный моб попытается убежать от врага независимо от текущей погоды, наполненности желудка и т.д. Это также должно ускорить вычисления, особенно если у тебя сотни/тысячи параметров.
>>77533
Ну ХЗ, тут бывает на дваче посмотришь иной раз, даже тяжело раненные бугуртом аноны продолжают боевые картиночки постить, надеясь на еду.
Хм, да. Чего-то я перемудрил с архитектурой. Придётся переделывать.
> тяжело раненный моб попытается убежать от врага независимо от текущей погоды, наполненности желудка и т.д.
Ну ХЗ, тут бывает на дваче посмотришь иной раз, даже тяжело раненные бугуртом аноны продолжают боевые картиночки постить, надеясь на еду.
> подключается слушателем к нескольким разным системам и ждёт сигналов, которые изменят его поведение
Хм, да. Чего-то я перемудрил с архитектурой. Придётся переделывать.
>>77540 (Del)
Area сама по себе повышает нагрузку. Поскольку ему нужно по какой-то причине оптимизировать ФПС логики мобов - причина скорее всего в том, что мобов ОЧЕНЬ много, следовательно, лишние Area в таком количестве вызовут слишком большую нагрузку. В идеале система чанков должна опираться только на простейшие математические формулы, в то время как Area нужна для геометрически сложных случаев.
>>77582
А это уже индивидуальные особенности. Кто-то бежит с поля боя, получив лёгкое ранение, а кто-то сражается до последней капли крови. Для симуляции в игре можно генерировать коэффициенты в формулах в определённых приделах, тогда один моб в первую очередь будет смотреть на своё здоровье, а другой моб - на здоровье врага. Это должно сделать игру более правдоподобной, но при этом намного более непредсказуемой для игрока (что не всегда требуется).
У тебя же не на if'ах логика? Решение должно приниматься суммированием, типа Σ решениеi x коэффициентi, где результат решенияi зависит от внешних обстоятельств, а коэффициентi - это уже индивидуальные предпочтения. Пример: нужно_ли_бежать? = своё_здоровье x 1.0 + здоровье_врага x 5.0 - это агрессивный моб, а если поменять коэффициенты местами - получится моб трусливый. Ну как-то так, я пробовал это делать, но уже не помню подробностей. Решения, если что, можно совмещать древовидно...
Ты просто взял решение, первым приходящее на ум - брутфорсить все изменяющиеся переменные. К такому все новички приходят, пока не узнают про события/сигналы.
>Когда kinematicbody игрока входит в радиус, включить, когда выходит, выключить повышенный фпс.
Area сама по себе повышает нагрузку. Поскольку ему нужно по какой-то причине оптимизировать ФПС логики мобов - причина скорее всего в том, что мобов ОЧЕНЬ много, следовательно, лишние Area в таком количестве вызовут слишком большую нагрузку. В идеале система чанков должна опираться только на простейшие математические формулы, в то время как Area нужна для геометрически сложных случаев.
>>77582
>даже тяжело раненные бугуртом аноны продолжают боевые картиночки постить, надеясь на еду.
А это уже индивидуальные особенности. Кто-то бежит с поля боя, получив лёгкое ранение, а кто-то сражается до последней капли крови. Для симуляции в игре можно генерировать коэффициенты в формулах в определённых приделах, тогда один моб в первую очередь будет смотреть на своё здоровье, а другой моб - на здоровье врага. Это должно сделать игру более правдоподобной, но при этом намного более непредсказуемой для игрока (что не всегда требуется).
У тебя же не на if'ах логика? Решение должно приниматься суммированием, типа Σ решениеi x коэффициентi, где результат решенияi зависит от внешних обстоятельств, а коэффициентi - это уже индивидуальные предпочтения. Пример: нужно_ли_бежать? = своё_здоровье x 1.0 + здоровье_врага x 5.0 - это агрессивный моб, а если поменять коэффициенты местами - получится моб трусливый. Ну как-то так, я пробовал это делать, но уже не помню подробностей. Решения, если что, можно совмещать древовидно...
>Чего-то я перемудрил с архитектурой
Ты просто взял решение, первым приходящее на ум - брутфорсить все изменяющиеся переменные. К такому все новички приходят, пока не узнают про события/сигналы.
>>77587
Лол, пределах.
Что-то я напутал в параметрах... Ну, не важно - в таком виде логику вообще сложно отлаживать, лучше всего вооружиться таблицами, чтобы сразу видеть изменение всех решений во множестве ситуаций, когда изменяешь какой-то параметр.
Эх, как же хочется ИИ в своей игре... Разве я многого хочу?
>определённых приделах
Лол, пределах.
>нужно_ли_бежать? = своё_здоровье x 1.0 + здоровье_врага x 5.0 - это агрессивный моб
Что-то я напутал в параметрах... Ну, не важно - в таком виде логику вообще сложно отлаживать, лучше всего вооружиться таблицами, чтобы сразу видеть изменение всех решений во множестве ситуаций, когда изменяешь какой-то параметр.
Эх, как же хочется ИИ в своей игре... Разве я многого хочу?
>>77593 (Del)
Area в форме сферы, по идее, проверяет все объекты, и реагирует только на те, у которых флаг в определённом слое. И делает это каждый физический тик. К тому же каждая проверка расстояния требует вычисление квадратного корня...
С чанками всё намного проще: целочисленно делишь позицию моба на размеры чанка и получаешь адрес чанка, в котором находится данный моб. И это нужно делать не каждый тик, а только во время движения, чтобы узнать, когда моб перейдёт в другой чанк.
Алсо, метод с Area - это увеличение числа нод и сущностей на физическом сервере по числу мобов, а чанковая система может держать любое число мобов независимо от числа чанков и не зависит от физического сервера.
Но так-то да, нужно проверить на практике.
Area в форме сферы, по идее, проверяет все объекты, и реагирует только на те, у которых флаг в определённом слое. И делает это каждый физический тик. К тому же каждая проверка расстояния требует вычисление квадратного корня...
С чанками всё намного проще: целочисленно делишь позицию моба на размеры чанка и получаешь адрес чанка, в котором находится данный моб. И это нужно делать не каждый тик, а только во время движения, чтобы узнать, когда моб перейдёт в другой чанк.
Алсо, метод с Area - это увеличение числа нод и сущностей на физическом сервере по числу мобов, а чанковая система может держать любое число мобов независимо от числа чанков и не зависит от физического сервера.
Но так-то да, нужно проверить на практике.
Почитал issues на гитхабе Godot - я не понял, они планируют отказаться от интеграции Bullet? Просто моей игре GodotPhysics не подходит из-за того, что центр масс нельзя сместить в произвольное место.
Вообще чёт много иссуев, которые висят годами с отметкой "milestone: 4.0"...
Вообще чёт много иссуев, которые висят годами с отметкой "milestone: 4.0"...
>>77615 (Del)
Какая вероятность, что физика Хуана будет производительнее буллета? Или какие там супер особенности будут?
Какая вероятность, что физика Хуана будет производительнее буллета? Или какие там супер особенности будут?
>>77615 (Del)
Ты предлагаешь сделать костыль, который тяжело рассчитать и с которым невозможно предсказать последствия. Вот на буллете я могу добавить в ригидбоди 1000 коллиженшейпов и расположить центр масс ровно так, как хочу, с учётом массы каждого отдельного коллиженшейпа. А с тем, что представляет из себя годофизикс сейчас, я такого сделать не могу...
>>77619
Годофизикс - это затычка уровня "шоб было". Кому нужна физика, будут подключать сторонние библиотеки...
Ты предлагаешь сделать костыль, который тяжело рассчитать и с которым невозможно предсказать последствия. Вот на буллете я могу добавить в ригидбоди 1000 коллиженшейпов и расположить центр масс ровно так, как хочу, с учётом массы каждого отдельного коллиженшейпа. А с тем, что представляет из себя годофизикс сейчас, я такого сделать не могу...
>>77619
Годофизикс - это затычка уровня "шоб было". Кому нужна физика, будут подключать сторонние библиотеки...
>>77678
Мне бы конкретные технические особенности, а не субъективное мнение
Мне бы конкретные технические особенности, а не субъективное мнение
>>77665
Более того, опенсорц - это движок. Игра опенсорцом быть не обязана, поэтому игроделу ничто не мешает прикрутить через адаптер любую проприетарную физику, например, Newton Dynamics, Tokamak Physics, Havok, PhysX, Meqon, TrueAxis, SPE. Главное, умей в плюсы. Ах, как я завидую умеющим в кресты!
> Кому нужна физика, будут подключать сторонние библиотеки...
Более того, опенсорц - это движок. Игра опенсорцом быть не обязана, поэтому игроделу ничто не мешает прикрутить через адаптер любую проприетарную физику, например, Newton Dynamics, Tokamak Physics, Havok, PhysX, Meqon, TrueAxis, SPE. Главное, умей в плюсы. Ах, как я завидую умеющим в кресты!
>>77682
Ну ни траль, крестовик! Я сколько раз пытался в это вкатиться, ниасиливаю все эти закорючки.
Ну ни траль, крестовик! Я сколько раз пытался в это вкатиться, ниасиливаю все эти закорючки.
>>77685
Туда ли ты вкатывался? Там после 11 стандарта все только проще и проще, даже мантры про байтики и ручное выделение памяти уже не работает
Туда ли ты вкатывался? Там после 11 стандарта все только проще и проще, даже мантры про байтики и ручное выделение памяти уже не работает
>>77700 (Del)
в их апи просто дергаешь функции, там сам ничего тоже не выделяешь вручную, ты бы хоть пописал что ли на них для начала
в их апи просто дергаешь функции, там сам ничего тоже не выделяешь вручную, ты бы хоть пописал что ли на них для начала
10 Кб, 244x232>>77724
И хорошо. Чего они там наворотили в четвёрке - лучше вообще отменить. Поломали всё что работало. ГДСкрипт сделали похожим на сишарп. Куча бессмысленных переименований в дереве классов. Вместо запила контейнера для окон они выпилили всю оверлейную оконную систему и перенесли её в оконную систему отдельных окон, пикрелейтед. И теперь если я хочу 2д-дисплей с окнами внутри 3д игры - я иду нахуй. Точнее иду рисовать самодельные велосипедные окна.
В общем, четвёрка очень огорчила. Лучше бы Хуан одумался и отыграл бы всё взад.
И хорошо. Чего они там наворотили в четвёрке - лучше вообще отменить. Поломали всё что работало. ГДСкрипт сделали похожим на сишарп. Куча бессмысленных переименований в дереве классов. Вместо запила контейнера для окон они выпилили всю оверлейную оконную систему и перенесли её в оконную систему отдельных окон, пикрелейтед. И теперь если я хочу 2д-дисплей с окнами внутри 3д игры - я иду нахуй. Точнее иду рисовать самодельные велосипедные окна.
В общем, четвёрка очень огорчила. Лучше бы Хуан одумался и отыграл бы всё взад.
>>77754
это нужно паре анонов
а вот новый рендер для дерева более эффектинвный - вот это нужно
> 2д-дисплей с окнами внутри 3д игры
это нужно паре анонов
а вот новый рендер для дерева более эффектинвный - вот это нужно
>>77677
Измерение в пикселях - это значит, что ты размещаешь все спрайты в пикселях экрана, а не вещественными числами. Если у тебя экран 800х600, ты размещаешь спрайт в точке (200; 150), а не в (-0.5; 0.5). Это помогает делать пиксель-арт игры, потому что все пиксели спрайтов попадают в пиксели экрана, а не размазываются, пытаясь нарисоваться по дробным координатам.
Также есть встроенная функция "увеличения пикселей", т.е. можно один игровой пиксель рисовать четырьмя экранными пикселями или больше. Это тоже полезно для пиксель-арта, потому что позволяет рисовать спрайты с размером пикселей 1х1, а выводить на экран увеличенные пиксели (2х2, 3х3, 4х4 и т.д.). Вообще-то эта функция скорее для снижения нагрузки на видеокарту, такое часто можно встретить в 3D играх (называется "половинное разрешение" или что-то такое), но для пиксель-арта подходит лучше всего.
Измерение в пикселях - это значит, что ты размещаешь все спрайты в пикселях экрана, а не вещественными числами. Если у тебя экран 800х600, ты размещаешь спрайт в точке (200; 150), а не в (-0.5; 0.5). Это помогает делать пиксель-арт игры, потому что все пиксели спрайтов попадают в пиксели экрана, а не размазываются, пытаясь нарисоваться по дробным координатам.
Также есть встроенная функция "увеличения пикселей", т.е. можно один игровой пиксель рисовать четырьмя экранными пикселями или больше. Это тоже полезно для пиксель-арта, потому что позволяет рисовать спрайты с размером пикселей 1х1, а выводить на экран увеличенные пиксели (2х2, 3х3, 4х4 и т.д.). Вообще-то эта функция скорее для снижения нагрузки на видеокарту, такое часто можно встретить в 3D играх (называется "половинное разрешение" или что-то такое), но для пиксель-арта подходит лучше всего.
>>77762
Я задал простой вопрос. Почему нельзя было сделать окно контейнер (Viewport/Window на скрине), а всё остальное оставить как есть (в зелёных нодах) чтобы у нас была свобода, (блять фри ас фри бир же, ёпт!) выводить окна хоть через этот контейнер, хоть внутри существующего CanvasItem?
> это нужно паре анонов
Я задал простой вопрос. Почему нельзя было сделать окно контейнер (Viewport/Window на скрине), а всё остальное оставить как есть (в зелёных нодах) чтобы у нас была свобода, (блять фри ас фри бир же, ёпт!) выводить окна хоть через этот контейнер, хоть внутри существующего CanvasItem?
>>77794
Для справки, то что в юнити этого нет - просто пиздёж.
Для справки, то что в юнити этого нет - просто пиздёж.
>>77863
Ну, вероятно, это с чем-то конфликтовало в архитектуре. Так глубоко я пока не копался еще.
Но вот новые методы рендеринга и физики точно нужны большому количеству анонов, поэтому четверку многие и ждут.
Ну, вероятно, это с чем-то конфликтовало в архитектуре. Так глубоко я пока не копался еще.
Но вот новые методы рендеринга и физики точно нужны большому количеству анонов, поэтому четверку многие и ждут.
Как в годоте вкинуть в polygon2d тайлсет, вырезать 1 тайл из него и расклонить. Так же было бы неплохо засмузить углы. Нихуя не получается. Где то ещё был примерно такой ассет, но чето найти не могу.
>>77754
А ты разве не можешь рендерить во вьюпорт и затем накладывать результат как текстуру на любую плоскость? У тебя же на скриншоте окошки во вьюпорте - что мешает получить текстуру с этого вьюпорта? Или в вулкане больше нельзя получать текстуры?
>>77863
А в чём смысл CanvasItem, если Viewport мощнее и позволяет тебе рендерить текстуру куда угодно? Хоть все модели обклей текстурой с гуёвыми кнопками и слайдерами.
Или Window будет рендерить в отдельный буфер независимо от вьюпорта, в котором находится? Это, по-моему, какой-то баг.
>>77872
Кстати, а почему в четвёрку откладывают все breaking changes? Почему нельзя сначала выпустить 4.0, потом, через полгодика, 5.0, ещё через полгодика 6.0 и т.д.? Ведь такими небольшими шагами будет намного проще портировать игры на следующую версию, чем переписывать всё с нуля из-за одного перехода с 3.x на 4.0. Насколько я понимаю, многие модификации уже готовы к релизу и ждут только выхода 4.0, а так можно было бы быстрее релизнуть их, передвинув остальные фичи на 5.0 или 6.0. Браузеры вон вообще каждый месяц мажорную версию наращивают и никто не жалуется...
Мне лично они не нужны. Мне нужны багфиксы. Но они и багфиксы тоже переносят на 4.0. Зачем?
>если я хочу 2д-дисплей с окнами внутри 3д игры
А ты разве не можешь рендерить во вьюпорт и затем накладывать результат как текстуру на любую плоскость? У тебя же на скриншоте окошки во вьюпорте - что мешает получить текстуру с этого вьюпорта? Или в вулкане больше нельзя получать текстуры?
>>77863
>свобода выводить окна хоть через этот контейнер, хоть внутри существующего CanvasItem
А в чём смысл CanvasItem, если Viewport мощнее и позволяет тебе рендерить текстуру куда угодно? Хоть все модели обклей текстурой с гуёвыми кнопками и слайдерами.
Или Window будет рендерить в отдельный буфер независимо от вьюпорта, в котором находится? Это, по-моему, какой-то баг.
>>77872
>четверку многие и ждут
Кстати, а почему в четвёрку откладывают все breaking changes? Почему нельзя сначала выпустить 4.0, потом, через полгодика, 5.0, ещё через полгодика 6.0 и т.д.? Ведь такими небольшими шагами будет намного проще портировать игры на следующую версию, чем переписывать всё с нуля из-за одного перехода с 3.x на 4.0. Насколько я понимаю, многие модификации уже готовы к релизу и ждут только выхода 4.0, а так можно было бы быстрее релизнуть их, передвинув остальные фичи на 5.0 или 6.0. Браузеры вон вообще каждый месяц мажорную версию наращивают и никто не жалуется...
>новые методы рендеринга и физики
Мне лично они не нужны. Мне нужны багфиксы. Но они и багфиксы тоже переносят на 4.0. Зачем?
>>77913
1) потому что у некоторых разработчиков есть крайняя помешанность на обратной совместимости
2) некоторые вещи нельзя исправить без других потому что они взаимосвязаны или это очень трудозатратно, поэтому целые группы вещей остаются до четверки
но многое прямо сейчас спокойно кочует в тройку, поэтому и выходят новые ее версии
большинство из-за пункта 2
> Почему нельзя сначала выпустить 4.0, потом, через полгодика, 5.0, ещё через полгодика 6.0 и т.д.?
1) потому что у некоторых разработчиков есть крайняя помешанность на обратной совместимости
2) некоторые вещи нельзя исправить без других потому что они взаимосвязаны или это очень трудозатратно, поэтому целые группы вещей остаются до четверки
но многое прямо сейчас спокойно кочует в тройку, поэтому и выходят новые ее версии
> Но они и багфиксы тоже переносят на 4.0. Зачем?
большинство из-за пункта 2
>>77913
Вот в таком конфиге окно действительно
При попытке его включить возникает новое окно, а ожидается, что вообще ничего не должно было произойти, чтобы я потом подключил текстуру в колоррект.
Кроме того, Вьюпорт теперь абстрактный класс, а для вышеописанного тобой рендеринга будет юзаться субвьюпорт пикрелейтед. Который вынесен в отдельную ветвь наследования от окон, пикрелейтед 2.
Надеюсь, что вся четвёрка - это ебучий баг, сраная ошибка, Хуан опомнится и отменит всё это.
> Viewport мощнее и позволяет тебе рендерить текстуру куда угодно?
Вот в таком конфиге окно действительно
> рендерить в отдельный буфер независимо от вьюпорта
При попытке его включить возникает новое окно, а ожидается, что вообще ничего не должно было произойти, чтобы я потом подключил текстуру в колоррект.
Кроме того, Вьюпорт теперь абстрактный класс, а для вышеописанного тобой рендеринга будет юзаться субвьюпорт пикрелейтед. Который вынесен в отдельную ветвь наследования от окон, пикрелейтед 2.
Надеюсь, что вся четвёрка - это ебучий баг, сраная ошибка, Хуан опомнится и отменит всё это.
>>77934
четверка - это пока единственный шанс выйти в нормальное 3D сейчас (и это я не про переход на вулкан, а на глобальное изменение внутреннего устройства системы рендера)
четверка - это пока единственный шанс выйти в нормальное 3D сейчас (и это я не про переход на вулкан, а на глобальное изменение внутреннего устройства системы рендера)
208 Кб, 809x586>>77934
Ну и? Юзай субвьюпорт вместо виндоу, в чём проблема-то?
И мы будем ждать багфиксов физики в 5.0 ещё лет пять.
>>77941
Да что вам всем так не нравится? По-моему замечательное 3D, блюр и блум точно есть и работают нормально. Единственный существенный косяк - тени странно себя ведут, никак не могу добиться того, чтобы тень от персонажа не проваливалась под землю...
>субвьюпорт
Ну и? Юзай субвьюпорт вместо виндоу, в чём проблема-то?
>Хуан опомнится и отменит всё это
И мы будем ждать багфиксов физики в 5.0 ещё лет пять.
>>77941
>выйти в нормальное 3D
>глобальное изменение внутреннего устройства
Да что вам всем так не нравится? По-моему замечательное 3D, блюр и блум точно есть и работают нормально. Единственный существенный косяк - тени странно себя ведут, никак не могу добиться того, чтобы тень от персонажа не проваливалась под землю...
56 Кб, 1080x667>>77953 (Del)
У меня проблем не было. Впрочем, я в принципе не возражаю против велосипедных окон, просто за кодобазу обидно. Всё ж есть. А возьмут и удолят к хуям.
У меня проблем не было. Впрочем, я в принципе не возражаю против велосипедных окон, просто за кодобазу обидно. Всё ж есть. А возьмут и удолят к хуям.
>>77945
Долго обеснять. Если бы были архивы движкосрач-треда, можно было бы сослаться на них, там периодически, когда толстенные траллищи уставали делать вид, что обижаются на толстоту друг друга, они начинали вести вполне аргументированные споры по вопросу того, что именно не работает, и как оптимизировать. Но увы, тред бесконечный самозатирающийся там.
Если вкратце, то в годоте нагорожены сомнительные велосипеды, хотя индустрия уже предлагала отточенные до уровня паттерна решения. Хуан полез в залупу и отказался убирать велосипеды. А в четвёрке вроде как сдал назад и убрал одни велосипеды, но обязательно накидает новых. Потому что тщетно бытие опенсорсное. И большинству девелоперов придётся выбирать межу релизами точёными из трёшки, и релизами дрочёными из четвёрки. Универсального решения не будет.
В выигрыше будут только крестовики, которым под силу будет взять улучшенный рендер из одной ветки, улучшенные классы из другой, собрать в свой кастомный билд и довольно урча делать игру мечты.
> Да что вам всем так не нравится?
Долго обеснять. Если бы были архивы движкосрач-треда, можно было бы сослаться на них, там периодически, когда толстенные траллищи уставали делать вид, что обижаются на толстоту друг друга, они начинали вести вполне аргументированные споры по вопросу того, что именно не работает, и как оптимизировать. Но увы, тред бесконечный самозатирающийся там.
Если вкратце, то в годоте нагорожены сомнительные велосипеды, хотя индустрия уже предлагала отточенные до уровня паттерна решения. Хуан полез в залупу и отказался убирать велосипеды. А в четвёрке вроде как сдал назад и убрал одни велосипеды, но обязательно накидает новых. Потому что тщетно бытие опенсорсное. И большинству девелоперов придётся выбирать межу релизами точёными из трёшки, и релизами дрочёными из четвёрки. Универсального решения не будет.
В выигрыше будут только крестовики, которым под силу будет взять улучшенный рендер из одной ветки, улучшенные классы из другой, собрать в свой кастомный билд и довольно урча делать игру мечты.
>>77952 (Del)
Не, мне нужно просто шоб я сделал многоугольник с помощью area и залил его текстурой тайлов на репите
Не, мне нужно просто шоб я сделал многоугольник с помощью area и залил его текстурой тайлов на репите
>>77959
Многоугольник ты делаешь отдельно, а текстуру ты делаешь отдельно, через шейдер или канву. Не мешай в кучу две задачи.
Многоугольник ты делаешь отдельно, а текстуру ты делаешь отдельно, через шейдер или канву. Не мешай в кучу две задачи.
Гдскриптом все можно описать и сделать?
>>77977 (Del)
Тут?
Не, ты наверное что-то путаешь. Это было не тут. Это было в шарпотреде в /пр/
> тут один анон хотел иконку в трее
Тут?
Не, ты наверное что-то путаешь. Это было не тут. Это было в шарпотреде в /пр/
А визуал где рисовать?
>>77981
И кстати, если уж хочется из трея управлять приложением, у годота есть OS.shell_open("myTrayAppWithMinerLOL.exe")
И кстати, если уж хочется из трея управлять приложением, у годота есть OS.shell_open("myTrayAppWithMinerLOL.exe")
>>77985 (Del)
Если всё таки вспомнить, что мы в треде игрового движка и предположительно говорим всё таки об играх, то стоит отметить, что играм нужно всего два окна: конфигуратор и само окно с игрой. Запускаешь игру, она ищет конфиг, не находит, открывает окно конфигуратора, создаёт конфиг по умолчанию и, чтобы не раздражать игрока, в конфигураторе сразу посередине есть крупная зелёная кнопка ИГРАТЬ. При нажатии на которую если есть изменения в параметрах, конфиг сохранится, затем игра запускает окно собсна игры, которое при своём запуске читает актуальный конфиг и действует соответствующе. В парадигме тройки даже окна не нужны, конфигуратор - это одна сцена, главная игра - вторая сцена. Всё.
> между ними гонять данные
Если всё таки вспомнить, что мы в треде игрового движка и предположительно говорим всё таки об играх, то стоит отметить, что играм нужно всего два окна: конфигуратор и само окно с игрой. Запускаешь игру, она ищет конфиг, не находит, открывает окно конфигуратора, создаёт конфиг по умолчанию и, чтобы не раздражать игрока, в конфигураторе сразу посередине есть крупная зелёная кнопка ИГРАТЬ. При нажатии на которую если есть изменения в параметрах, конфиг сохранится, затем игра запускает окно собсна игры, которое при своём запуске читает актуальный конфиг и действует соответствующе. В парадигме тройки даже окна не нужны, конфигуратор - это одна сцена, главная игра - вторая сцена. Всё.
38 Кб, 758x855>>77988
Как-то так.
Как-то так.
>>77993 (Del)
И это были оверлейные псевдоокна внутри одного полноэкранного окна игры. Как сейчас в трёшке. И вместо того, чтобы добавить к существующим оверлейным окнам системные окна, Хуан переименовал их, выпилил из наследников Control и впилил в наследники Viewport. Ужасно. Просто ужасно!
И это были оверлейные псевдоокна внутри одного полноэкранного окна игры. Как сейчас в трёшке. И вместо того, чтобы добавить к существующим оверлейным окнам системные окна, Хуан переименовал их, выпилил из наследников Control и впилил в наследники Viewport. Ужасно. Просто ужасно!
>>77985 (Del)
поддержка многооконности для игр и не нужна
1) запускается лаунчер
2) в лаунчере производятся настройки игры или просто нажимается играть
3) лаунчер или пересоздает контекст рендера окна, если требуется выводить на другом типе, либо просто отрисовывает содержимое прямо в том же окне
поддержка многооконности для игр и не нужна
1) запускается лаунчер
2) в лаунчере производятся настройки игры или просто нажимается играть
3) лаунчер или пересоздает контекст рендера окна, если требуется выводить на другом типе, либо просто отрисовывает содержимое прямо в том же окне
>>77949
Ты как-то невнятно объясняешь.
>>77994
ЧТО он выпилил?
Ладно, сам разберусь:
https://docs.godotengine.org/en/latest/classes/class_control.html
https://docs.godotengine.org/en/stable/classes/class_control.html
Что, только попыт?
https://docs.godotengine.org/en/latest/classes/class_popup.html
https://docs.godotengine.org/en/stable/classes/class_popup.html
И зачем он тебе нужен вообще? Бери Panel и делай свой собственный попыт с надписями и кнопками. В ЧЁМ ТВОЯ ПРОБЛЕМА?
А Хуан делает всё абсолютно правильно. ПОПЫТ подразумевает модальное окно, которое должно перекрывать окно игры в тех ОС, где есть модальные окна (вроде во всех есть). Всё, что находится внутри окна игры, по определению не может быть модальным окном, потому что не является окном (с точки зрения ОС) в принципе. Если тебе нужно симулировать поведение модальных окон внутри окна игры - используй простые панельки. Это просто!
А текущая реализация попытов, судя по всему, костыль, который давно пора было заменить. Лично меня бесит, что вместо родного color picker'а винды я вынужден бороться с каким-то глючным говном, которое появляется внутри окна Годо на долю секунды и исчезает. Конечно, в виндовом нет альфа-канала, но его можно было бы и циферками напротив поля с цветом вводить...
Впрочем, если новые попыты окажутся не системными, а созданием нового графического контекста (2-3 секунды на открытие модального окна, лол), то это, конечно, ещё хуже, чем глючная имитация внутри единственного окна.
Ты как-то невнятно объясняешь.
>>77994
>переименовал их, выпилил из наследников Control
ЧТО он выпилил?
Ладно, сам разберусь:
https://docs.godotengine.org/en/latest/classes/class_control.html
https://docs.godotengine.org/en/stable/classes/class_control.html
Что, только попыт?
https://docs.godotengine.org/en/latest/classes/class_popup.html
https://docs.godotengine.org/en/stable/classes/class_popup.html
И зачем он тебе нужен вообще? Бери Panel и делай свой собственный попыт с надписями и кнопками. В ЧЁМ ТВОЯ ПРОБЛЕМА?
А Хуан делает всё абсолютно правильно. ПОПЫТ подразумевает модальное окно, которое должно перекрывать окно игры в тех ОС, где есть модальные окна (вроде во всех есть). Всё, что находится внутри окна игры, по определению не может быть модальным окном, потому что не является окном (с точки зрения ОС) в принципе. Если тебе нужно симулировать поведение модальных окон внутри окна игры - используй простые панельки. Это просто!
А текущая реализация попытов, судя по всему, костыль, который давно пора было заменить. Лично меня бесит, что вместо родного color picker'а винды я вынужден бороться с каким-то глючным говном, которое появляется внутри окна Годо на долю секунды и исчезает. Конечно, в виндовом нет альфа-канала, но его можно было бы и циферками напротив поля с цветом вводить...
Впрочем, если новые попыты окажутся не системными, а созданием нового графического контекста (2-3 секунды на открытие модального окна, лол), то это, конечно, ещё хуже, чем глючная имитация внутри единственного окна.
Револбшн уже скоро?
>>78004
В том что я щупаю реальную сборку четвёрки, а ты читаешь манядокументацию, думая, что переключение с latest на stable - это истина.
Вчера ещё одну интересную вещь заметил. Подсказки в щупаемой мною сборке тоже переделаны на графический контекст и захватывают фокус, если быстро елозить мышкой по окну настроек, и попасть на всплывшую подсказку и щёлкнуть, то она ворует клик и не происходит переключения на ожидаемый пункт настроек. Раздражающе.
> В ЧЁМ ТВОЯ ПРОБЛЕМА?
В том что я щупаю реальную сборку четвёрки, а ты читаешь манядокументацию, думая, что переключение с latest на stable - это истина.
Вчера ещё одну интересную вещь заметил. Подсказки в щупаемой мною сборке тоже переделаны на графический контекст и захватывают фокус, если быстро елозить мышкой по окну настроек, и попасть на всплывшую подсказку и щёлкнуть, то она ворует клик и не происходит переключения на ожидаемый пункт настроек. Раздражающе.
>>78007
Пойду свежую сборку скачаю, а то вдруг там уже всё откатили взад, а я тут ругаюсь почём зря.
Пойду свежую сборку скачаю, а то вдруг там уже всё откатили взад, а я тут ругаюсь почём зря.
>>78004
Это и не должно быть в играх вызовом реальных системных. Потому что разработчик почти всегда для игры делает свой стиль, поэтому у него должна быть собственная реализация любых игровых окон так, как ему нужно отрисовывать для конкретно его приложения\игры. Поэтому похожесть окон на системные будет добиваться схожестью стиля, установленного в ОС при необходимости, но технически вся новая отрисовка будет на новом рендере
> Впрочем, если новые попыты окажутся не системными, а созданием нового графического контекста
Это и не должно быть в играх вызовом реальных системных. Потому что разработчик почти всегда для игры делает свой стиль, поэтому у него должна быть собственная реализация любых игровых окон так, как ему нужно отрисовывать для конкретно его приложения\игры. Поэтому похожесть окон на системные будет добиваться схожестью стиля, установленного в ОС при необходимости, но технически вся новая отрисовка будет на новом рендере
11 Кб, 413x609>>78008
В свежей сборке пофиксили
>>78007
Претензия снимается.
>>78004
Вот! Вот это "глючное говно" является контентом, который собран на нодах, вот хотя бы к нему Хуан должен был оставить доступ. Обесню на рисунке, чтобы было внятно: пикрелейтед. То есть, никаких диалогов не переносится в новую ветку. Всё остаётся на своём месте. Создаётся вьюпорт и окно, а в окно можно выводить любой контент. Почему Хуан так не сделал? Я описал выше. Он настойчиво игнорирует открытия в области кодинга, и делает сомнительной адекватности велосипеды. Он должен был оставить оконный класс и возможность выводить в него контент, в том числе запросить системное окно в системе и скормить своему оконному классу хендл этого окна, как делают все, когда надо показывать платформ-специфичнное окно, разное в разных платформах. При этом оставалась бы возможность выводить в отдельное окно как брендированные авторские диалоги, так и любой авторский контент.
В свежей сборке пофиксили
>>78007
> захватывают фокус, если быстро елозить мышкой по окну настроек, и попасть на всплывшую подсказку и щёлкнуть, то она ворует клик и не происходит переключения на ожидаемый пункт настроек
Претензия снимается.
>>78004
> попыт?
> ПОПЫТ
> В ЧЁМ ТВОЯ ПРОБЛЕМА?
> вместо родного color picker'а винды я вынужден бороться с каким-то глючным говном
Вот! Вот это "глючное говно" является контентом, который собран на нодах, вот хотя бы к нему Хуан должен был оставить доступ. Обесню на рисунке, чтобы было внятно: пикрелейтед. То есть, никаких диалогов не переносится в новую ветку. Всё остаётся на своём месте. Создаётся вьюпорт и окно, а в окно можно выводить любой контент. Почему Хуан так не сделал? Я описал выше. Он настойчиво игнорирует открытия в области кодинга, и делает сомнительной адекватности велосипеды. Он должен был оставить оконный класс и возможность выводить в него контент, в том числе запросить системное окно в системе и скормить своему оконному классу хендл этого окна, как делают все, когда надо показывать платформ-специфичнное окно, разное в разных платформах. При этом оставалась бы возможность выводить в отдельное окно как брендированные авторские диалоги, так и любой авторский контент.
>>78009
Согласен. Но на годо нынче можно и приложения писать. Знаменитый клон асепрайта - пикселорама - написан на годо.
> Это и не должно быть в играх вызовом реальных системных
Согласен. Но на годо нынче можно и приложения писать. Знаменитый клон асепрайта - пикселорама - написан на годо.
>>78012
Да и в приложениях это тоже нахуй не надо. А то раньше приложения любили распадаться на триста отдельных окошек, как тот же гимп - нахуй это вообще надо?
Да и в приложениях это тоже нахуй не надо. А то раньше приложения любили распадаться на триста отдельных окошек, как тот же гимп - нахуй это вообще надо?
>>78014
Разобрался в вопросе. Претензии снимаю все вышеизложенные. Оказывается! В проекте! На уровне настроек/конфига есть опция EmbedSubWindows которая если true выводит попапы в стиле трёшки, оверлейно. Это снимает все мои вопросы к новой системе.
Разобрался в вопросе. Претензии снимаю все вышеизложенные. Оказывается! В проекте! На уровне настроек/конфига есть опция EmbedSubWindows которая если true выводит попапы в стиле трёшки, оверлейно. Это снимает все мои вопросы к новой системе.
>>78014
Для мультимониторобогов. На основном мониторе кидаешь вьюпорт со сценой, на дополнительном мониторе размещаешь инспекторы, табы, листы, тулзы.
> нахуй это вообще надо?
Для мультимониторобогов. На основном мониторе кидаешь вьюпорт со сценой, на дополнительном мониторе размещаешь инспекторы, табы, листы, тулзы.
>>78012
в подавляющем числе приложений также не нужны отдельные физические окна, поэтому игровому движку можно не усложнять архитектуру под ряд этих специфических задач
> Но на годо нынче можно и приложения писать
в подавляющем числе приложений также не нужны отдельные физические окна, поэтому игровому движку можно не усложнять архитектуру под ряд этих специфических задач
>>66120 (OP)
Вот что в следующую шапку пойдёт.
https://docs.godotengine.org/en/stable/getting_started/workflow/assets/escn_exporter/index.html
Вот что в следующую шапку пойдёт.
https://docs.godotengine.org/en/stable/getting_started/workflow/assets/escn_exporter/index.html
>>78347 (Del)
Тоже ЗБС. Чем больше возможностей - тем лучше.
Тоже ЗБС. Чем больше возможностей - тем лучше.
>>66120 (OP)
Репост из ньюфаг треда. Сел за godot, первый день, нарисовал карту 2д, персонажа, джойстик управления и кнопку. Когда я перемещаю персонажа, камера двигается за персонажем а кнопки остаются на месте. Даже не знаю как гуглить. Руководствовался https://youtu.be/oeC_3l0tODg.
Мой высер.
https://github.com/learngodot/test1.git
Репост из ньюфаг треда. Сел за godot, первый день, нарисовал карту 2д, персонажа, джойстик управления и кнопку. Когда я перемещаю персонажа, камера двигается за персонажем а кнопки остаются на месте. Даже не знаю как гуглить. Руководствовался https://youtu.be/oeC_3l0tODg.
Мой высер.
https://github.com/learngodot/test1.git
>>78447
Тебе нужно это: https://docs.godotengine.org/en/stable/tutorials/2d/canvas_layers.html
Прежде чем гуглить и проходить туториалы на Ютубе, почитай сначала официальный мануал (частично переведён на русский, но лучше читать на английском), особенно это: https://docs.godotengine.org/en/stable/getting_started/step_by_step/index.html
Большинство вопросов сами собой отпадут.
>>78448
К какому именно? Могут возникнуть проблемы, когда попытаешься приближать/отдалять камеру. CanvasLayer позволяет рендерить GUI независимо от игровых объектов.
>камера двигается за персонажем а кнопки остаются на месте
Тебе нужно это: https://docs.godotengine.org/en/stable/tutorials/2d/canvas_layers.html
>Даже не знаю как гуглить
>Руководствовался
Прежде чем гуглить и проходить туториалы на Ютубе, почитай сначала официальный мануал (частично переведён на русский, но лучше читать на английском), особенно это: https://docs.godotengine.org/en/stable/getting_started/step_by_step/index.html
Большинство вопросов сами собой отпадут.
>>78448
>Прицепил к родительскому элементу кнопку и получилось.
К какому именно? Могут возникнуть проблемы, когда попытаешься приближать/отдалять камеру. CanvasLayer позволяет рендерить GUI независимо от игровых объектов.
>>78450 (Del)
Спасибо.
>>78453
И тебе Спасибо.
Я пока по туториалу за пару дней первый раз пробну что-то сделать, посмотреть по себе. Если зайдет эта движуха, стану gdscript учить и оф доки курить.
Очень тяжело пока ориентироваться в игровом физ пространстве, векторах, осях и т.д. Надеюсь, скоро будет легче.
Давно уже хотел чем-то эдаким заняться, буду реализовывать хотелки.
Спасибо.
>>78453
И тебе Спасибо.
Я пока по туториалу за пару дней первый раз пробну что-то сделать, посмотреть по себе. Если зайдет эта движуха, стану gdscript учить и оф доки курить.
Очень тяжело пока ориентироваться в игровом физ пространстве, векторах, осях и т.д. Надеюсь, скоро будет легче.
Давно уже хотел чем-то эдаким заняться, буду реализовывать хотелки.
>>78454
Если у тебя 2D, то "пространство" - это просто лист бумаги. Ты можешь сложить несколько полупрозрачных листов вместе и двигать их независимо друг от друга (параллакс), но вся игра у тебя будет происходить всегда на одном листе, остальные только для декораций (если не придумывать каких-то необычных механик).
Специальный туториал поможет: https://docs.godotengine.org/en/stable/tutorials/math/vector_math.html
Ну и в старшей школе вроде должны были это давать.
В 2D оси как в геометрии из средней школы, только Y перевёрнута из-за особенностей вывода графики на экран, т.е. точка (0;0) в левом верхнем углу экрана (так было принято ещё в прошлом веке - потому что строчки пикселей на экране нумеруются сверху вниз). Но привыкнуть легко.
Если есть некая концепция игры, лучше сначала записать все идеи как "дизайн-документ" (удобнее всего в формате вики, рекомендую попробовать TiddlyWiki), чтобы потом не забыть ничего. Потому что любая идея реализуется достаточно долго и занимает собой всё внимание, поэтому легко потерять другие идеи в процессе реализации одной из них. Также любую задумку нужно разделять на мельчайшие компоненты и реализовать их, а не абстрактную "идею", так будет легче (это называется декомпозиция). Собственно поэтому вики-движок удобнее для записи, т.к. позволяет описывать идею и её части по отдельности, соединяя ссылками в любую структуру.
>тяжело пока ориентироваться в игровом физ пространстве
Если у тебя 2D, то "пространство" - это просто лист бумаги. Ты можешь сложить несколько полупрозрачных листов вместе и двигать их независимо друг от друга (параллакс), но вся игра у тебя будет происходить всегда на одном листе, остальные только для декораций (если не придумывать каких-то необычных механик).
>векторах
Специальный туториал поможет: https://docs.godotengine.org/en/stable/tutorials/math/vector_math.html
Ну и в старшей школе вроде должны были это давать.
>осях
В 2D оси как в геометрии из средней школы, только Y перевёрнута из-за особенностей вывода графики на экран, т.е. точка (0;0) в левом верхнем углу экрана (так было принято ещё в прошлом веке - потому что строчки пикселей на экране нумеруются сверху вниз). Но привыкнуть легко.
>буду реализовывать хотелки
Если есть некая концепция игры, лучше сначала записать все идеи как "дизайн-документ" (удобнее всего в формате вики, рекомендую попробовать TiddlyWiki), чтобы потом не забыть ничего. Потому что любая идея реализуется достаточно долго и занимает собой всё внимание, поэтому легко потерять другие идеи в процессе реализации одной из них. Также любую задумку нужно разделять на мельчайшие компоненты и реализовать их, а не абстрактную "идею", так будет легче (это называется декомпозиция). Собственно поэтому вики-движок удобнее для записи, т.к. позволяет описывать идею и её части по отдельности, соединяя ссылками в любую структуру.
>>78562
Есть что-нибудь попроще, оффлайновое? Это тоже можно заставить работать локально, но там нужно свой локальный сервер поднимать. Нахуй так сложно?
другой анон
> TiddlyWiki
Есть что-нибудь попроще, оффлайновое? Это тоже можно заставить работать локально, но там нужно свой локальный сервер поднимать. Нахуй так сложно?
другой анон
>>78568
З.Ы. Я давно уже ищу компактное и простое оффлайн-приложение для организации диздока в виде гипертекста (зумерск. вики), скоро я потеряю терпение и напишу его себе сам, на годоте!
З.Ы. Я давно уже ищу компактное и простое оффлайн-приложение для организации диздока в виде гипертекста (зумерск. вики), скоро я потеряю терпение и напишу его себе сам, на годоте!
>>78568
В каком смысле? На мой взгляд, TiddlyWiki максимально проста, если не учитывать необходимость в браузере. В сжатом архиве пустая вики весит меньше 400 КБ.
Просто открываешь .html файл в браузере и работаешь локально. Никакой сервер не нужен, можно даже на телефоне открывать и всё будет работать почти как на компе. Сохранение происходит путём "скачивания" копии .html файла по нажатию кнопки на странице - не очень логично, но удобно в контексте бекапов. Собственно, сам .html файл может быть где угодно, например, на флешке или удалённом жёстком диске, главное чтоб браузер разрешал протокол file:// или content:// (на Android недавно запретили браузерам читать .html через file://, но по-прежнему можно открывать через файловый менеджер, поддерживающий создание content:// ссылок).
Вообще, просто почитай официальный сайт: https://tiddlywiki.com/ - можешь его прямо сейчас скачать себе (значок в виде галочки внутри окружности, меняет цвет на красный, если вносишь изменения) и открыть оффлайн, лол. Я так и сделал, схоронил копию сайта себе на комп и на телефон, т.к. там справка по многим фичам и будет жалко потерять к ней доступ.
>>78570
Вики - это не гипертекст. Вики - это сайт с определёнными свойствами, отличающими его от других сайтов. https://ru.wikipedia.org/wiki/Вики
В случае с TiddlyWiki это не совсем сайт, это просто один .html файл, который хоть и можно разместить на сайте, но не обязательно.
У TiddlyWiki преимущество в том, что тебе нужен только браузер, чтобы её открыть - сможешь открыть на любой платформе, где есть браузер с JS (кроме разве что древних версий браузеров). Т.е. не нужно таскать с собой несколько версий приложения и отдельный файл с записями. Плюс вся мощь JS для создания своих собственных фич прямо внутри работающей вики...
Я как-то тоже хотел свой велосипед сделать, но потом осознал, сколько труда вложено в проект вроде TiddlyWiki и решил не тратить время зря на глупые хотелки.
Некоторые даже пробуют использовать TiddlyWiki как игровой движок, например, текстовые игры относительно легко делать...
>попроще
В каком смысле? На мой взгляд, TiddlyWiki максимально проста, если не учитывать необходимость в браузере. В сжатом архиве пустая вики весит меньше 400 КБ.
>оффлайновое
Просто открываешь .html файл в браузере и работаешь локально. Никакой сервер не нужен, можно даже на телефоне открывать и всё будет работать почти как на компе. Сохранение происходит путём "скачивания" копии .html файла по нажатию кнопки на странице - не очень логично, но удобно в контексте бекапов. Собственно, сам .html файл может быть где угодно, например, на флешке или удалённом жёстком диске, главное чтоб браузер разрешал протокол file:// или content:// (на Android недавно запретили браузерам читать .html через file://, но по-прежнему можно открывать через файловый менеджер, поддерживающий создание content:// ссылок).
Вообще, просто почитай официальный сайт: https://tiddlywiki.com/ - можешь его прямо сейчас скачать себе (значок в виде галочки внутри окружности, меняет цвет на красный, если вносишь изменения) и открыть оффлайн, лол. Я так и сделал, схоронил копию сайта себе на комп и на телефон, т.к. там справка по многим фичам и будет жалко потерять к ней доступ.
>>78570
>гипертекста (зумерск. вики)
Вики - это не гипертекст. Вики - это сайт с определёнными свойствами, отличающими его от других сайтов. https://ru.wikipedia.org/wiki/Вики
В случае с TiddlyWiki это не совсем сайт, это просто один .html файл, который хоть и можно разместить на сайте, но не обязательно.
>напишу его себе сам, на годоте
У TiddlyWiki преимущество в том, что тебе нужен только браузер, чтобы её открыть - сможешь открыть на любой платформе, где есть браузер с JS (кроме разве что древних версий браузеров). Т.е. не нужно таскать с собой несколько версий приложения и отдельный файл с записями. Плюс вся мощь JS для создания своих собственных фич прямо внутри работающей вики...
Я как-то тоже хотел свой велосипед сделать, но потом осознал, сколько труда вложено в проект вроде TiddlyWiki и решил не тратить время зря на глупые хотелки.
Некоторые даже пробуют использовать TiddlyWiki как игровой движок, например, текстовые игры относительно легко делать...
>>78568
В каком смысле? На мой взгляд, TiddlyWiki максимально проста, если не учитывать необходимость в браузере. В сжатом архиве пустая вики весит меньше 400 КБ.
Просто открываешь .html файл в браузере и работаешь локально. Никакой сервер не нужен, можно даже на телефоне открывать и всё будет работать почти как на компе. Сохранение происходит путём "скачивания" копии .html файла по нажатию кнопки на странице - не очень логично, но удобно в контексте бекапов. Собственно, сам .html файл может быть где угодно, например, на флешке или удалённом жёстком диске, главное чтоб браузер разрешал протокол file:// или content:// (на Android недавно запретили браузерам читать .html через file://, но по-прежнему можно открывать через файловый менеджер, поддерживающий создание content:// ссылок).
Вообще, просто почитай официальный сайт: https://tiddlywiki.com/ - можешь его прямо сейчас скачать себе (значок в виде галочки внутри окружности, меняет цвет на красный, если вносишь изменения) и открыть оффлайн, лол. Я так и сделал, схоронил копию сайта себе на комп и на телефон, т.к. там справка по многим фичам и будет жалко потерять к ней доступ.
>>78570
Вики - это не гипертекст. Вики - это сайт с определёнными свойствами, отличающими его от других сайтов. https://ru.wikipedia.org/wiki/Вики
В случае с TiddlyWiki это не совсем сайт, это просто один .html файл, который хоть и можно разместить на сайте, но не обязательно.
У TiddlyWiki преимущество в том, что тебе нужен только браузер, чтобы её открыть - сможешь открыть на любой платформе, где есть браузер с JS (кроме разве что древних версий браузеров). Т.е. не нужно таскать с собой несколько версий приложения и отдельный файл с записями. Плюс вся мощь JS для создания своих собственных фич прямо внутри работающей вики...
Я как-то тоже хотел свой велосипед сделать, но потом осознал, сколько труда вложено в проект вроде TiddlyWiki и решил не тратить время зря на глупые хотелки.
Некоторые даже пробуют использовать TiddlyWiki как игровой движок, например, текстовые игры относительно легко делать...
>попроще
В каком смысле? На мой взгляд, TiddlyWiki максимально проста, если не учитывать необходимость в браузере. В сжатом архиве пустая вики весит меньше 400 КБ.
>оффлайновое
Просто открываешь .html файл в браузере и работаешь локально. Никакой сервер не нужен, можно даже на телефоне открывать и всё будет работать почти как на компе. Сохранение происходит путём "скачивания" копии .html файла по нажатию кнопки на странице - не очень логично, но удобно в контексте бекапов. Собственно, сам .html файл может быть где угодно, например, на флешке или удалённом жёстком диске, главное чтоб браузер разрешал протокол file:// или content:// (на Android недавно запретили браузерам читать .html через file://, но по-прежнему можно открывать через файловый менеджер, поддерживающий создание content:// ссылок).
Вообще, просто почитай официальный сайт: https://tiddlywiki.com/ - можешь его прямо сейчас скачать себе (значок в виде галочки внутри окружности, меняет цвет на красный, если вносишь изменения) и открыть оффлайн, лол. Я так и сделал, схоронил копию сайта себе на комп и на телефон, т.к. там справка по многим фичам и будет жалко потерять к ней доступ.
>>78570
>гипертекста (зумерск. вики)
Вики - это не гипертекст. Вики - это сайт с определёнными свойствами, отличающими его от других сайтов. https://ru.wikipedia.org/wiki/Вики
В случае с TiddlyWiki это не совсем сайт, это просто один .html файл, который хоть и можно разместить на сайте, но не обязательно.
>напишу его себе сам, на годоте
У TiddlyWiki преимущество в том, что тебе нужен только браузер, чтобы её открыть - сможешь открыть на любой платформе, где есть браузер с JS (кроме разве что древних версий браузеров). Т.е. не нужно таскать с собой несколько версий приложения и отдельный файл с записями. Плюс вся мощь JS для создания своих собственных фич прямо внутри работающей вики...
Я как-то тоже хотел свой велосипед сделать, но потом осознал, сколько труда вложено в проект вроде TiddlyWiki и решил не тратить время зря на глупые хотелки.
Некоторые даже пробуют использовать TiddlyWiki как игровой движок, например, текстовые игры относительно легко делать...
>>78571
У меня один комп и одна платформа. Не нужно ничего таскать. Ладно попробую почитать сайт ещё раз.
> не нужно таскать с собой несколько версий приложения и отдельный файл с записями
У меня один комп и одна платформа. Не нужно ничего таскать. Ладно попробую почитать сайт ещё раз.
>>78571
Тут вот это больше подходит: https://ru.wikipedia.org/wiki/Персональная_вики
Ну и там ещё целая статья про саму TiddlyWiki.
Мне лично очень зашла своей компактностью, дизайном и возможностями. Полноценный сайт, только оффлайн без сервера. Есть недостатки или особенности работы (к примеру, нерационально вставлять большие изображения в сам .html, их нужно хранить отдельными файлами; сложно организовать совместное редактирование), конечно, но мне они не мешают.
>Вики - это не гипертекст. Вики - это сайт с определёнными свойствами, отличающими его от других сайтов.
Тут вот это больше подходит: https://ru.wikipedia.org/wiki/Персональная_вики
>...однопользовательские вики-приложения, не имеющие веб-сервера и сервера баз данных.
>TiddlyWiki — вики-движок и вики-концепция, заключающаяся в том, что весь вики-сайт представляет собой одну HTML-страницу, интерактивность которой обеспечивается сценариями.
Ну и там ещё целая статья про саму TiddlyWiki.
Мне лично очень зашла своей компактностью, дизайном и возможностями. Полноценный сайт, только оффлайн без сервера. Есть недостатки или особенности работы (к примеру, нерационально вставлять большие изображения в сам .html, их нужно хранить отдельными файлами; сложно организовать совместное редактирование), конечно, но мне они не мешают.
>>78574
Нет. Не моё. Попробовал ещё раз, накидал пару тидлеров. По ссылкам друг на друга не открываются. Почему? Нет желания разбираться. Хотелось просто писать текст в одном окошке, и где надо обрамлять [[ссылки]] двойными скобками, чтобы автоматически создавались статьи, потом щелкать по ссылкам и ебашить текст туда. Скачанный хтмл у меня в ффоксе не работает. Может для этого нужен зумерский пориджехром? Не знаю. Похуй. Буду искать дальше.
Нет. Не моё. Попробовал ещё раз, накидал пару тидлеров. По ссылкам друг на друга не открываются. Почему? Нет желания разбираться. Хотелось просто писать текст в одном окошке, и где надо обрамлять [[ссылки]] двойными скобками, чтобы автоматически создавались статьи, потом щелкать по ссылкам и ебашить текст туда. Скачанный хтмл у меня в ффоксе не работает. Может для этого нужен зумерский пориджехром? Не знаю. Похуй. Буду искать дальше.
1,5 Мб, 1000x820>>78577
Ну ладно, разобрался, тидлеры создаются. Ну ХЗ. Будем посмотреть.
Ну ладно, разобрался, тидлеры создаются. Ну ХЗ. Будем посмотреть.
Щас будет боевой клич безыгорника... РРЯЯЯЯЯЯЯЯ!
В ветке 3.x у нас есть два стула:
1. Bullet точёный:
1.1. Спящий RigidBody полностью игнорирует KinematicBody, т.е. можно спокойно двигаться даже по круглому мячику и не будет никаких глюков. Но стоит только RigidBody проснуться, и он будет отлетать от KinematicBody. Впрочем, стоя на проснувшемся мячике его поведение предсказуемо и не вызывает проблем.
1.2. Дверь на RigidBody и 2-х HingeJoint нормально толкается KinematicBody и не зажимает его, но получает слишком сильные удары от него - ведь она не спит, пока открывается.
2. GodotPhysics дрочёный:
2.1. RigidBody не реагирует на KinematicBody даже когда не спит, но только если столкновение боковое: если встать на мячик, то даже если мячик спал, начнётся дикий расколбас - KinematicBody будет резко метаться во все стороны, а мячик рано или поздно вылетит из-под него, что совершенно нереалистично и не должно происходить.
2.2. Та же дверь из 2.1 нормально толкается KinematicBody, получая ровно такие удары, какие я прописал в коде, но ВНЕЗАПНО может зажимать KinematicBody между собой и StaticBody стенкой (точнее CSG с галочкой collider или как там её), в результате чего KinematicBody не может сдвинуться с места и как будто бы находится в воздухе (velocity.y не обнуляется move_and_slide).
Я не знаю, что делать. Я хочу чтобы ПРОСТО можно было двигаться и ПРОСТО правдоподобно взаимодействовать с окружающими предметами, без регулярных застреваний, резких толчков и расколбаса всех ближайших объектов. Кто там Godot 4.0 щупает, как там с физикой? Поправили уже всё или только обещают? Я читал на гитхабе, что они решили избавиться от KinematicBody и сделать специальный CharacterBody, а StaticBody и RigidBody дополнить новыми функциями, но на счёт исправления багов непонятно.
Кто-то скажет "делой игру без RigidBody" - отвечаю сразу, мне не нужен ассетфлип для рубки бабла, я пытаюсь реализовать конкретные идеи и в результате вынужден бороться с багами движка, хотя ВНЕЗАПНО Bullet позиционируется как среда для симуляции роботов и т.п. важных вещей. Т.е. получается это не Bullet виноват, это KinematicBody в Godot такой кривой? Почему они уже несколько лет не могут пофиксить взаимодействие разбуженного RigidBody и KinematicBody, если в GodotPhysics это частично пофикшено? И почему в GodotPhysics начинается расколбас, если Bullet обрабатывает те же ситуации нормально? Хотя, плевать на GodotPhysics, Bullet кажется более взрослым и серьёзным.
В ветке 3.x у нас есть два стула:
1. Bullet точёный:
1.1. Спящий RigidBody полностью игнорирует KinematicBody, т.е. можно спокойно двигаться даже по круглому мячику и не будет никаких глюков. Но стоит только RigidBody проснуться, и он будет отлетать от KinematicBody. Впрочем, стоя на проснувшемся мячике его поведение предсказуемо и не вызывает проблем.
1.2. Дверь на RigidBody и 2-х HingeJoint нормально толкается KinematicBody и не зажимает его, но получает слишком сильные удары от него - ведь она не спит, пока открывается.
2. GodotPhysics дрочёный:
2.1. RigidBody не реагирует на KinematicBody даже когда не спит, но только если столкновение боковое: если встать на мячик, то даже если мячик спал, начнётся дикий расколбас - KinematicBody будет резко метаться во все стороны, а мячик рано или поздно вылетит из-под него, что совершенно нереалистично и не должно происходить.
2.2. Та же дверь из 2.1 нормально толкается KinematicBody, получая ровно такие удары, какие я прописал в коде, но ВНЕЗАПНО может зажимать KinematicBody между собой и StaticBody стенкой (точнее CSG с галочкой collider или как там её), в результате чего KinematicBody не может сдвинуться с места и как будто бы находится в воздухе (velocity.y не обнуляется move_and_slide).
Я не знаю, что делать. Я хочу чтобы ПРОСТО можно было двигаться и ПРОСТО правдоподобно взаимодействовать с окружающими предметами, без регулярных застреваний, резких толчков и расколбаса всех ближайших объектов. Кто там Godot 4.0 щупает, как там с физикой? Поправили уже всё или только обещают? Я читал на гитхабе, что они решили избавиться от KinematicBody и сделать специальный CharacterBody, а StaticBody и RigidBody дополнить новыми функциями, но на счёт исправления багов непонятно.
Кто-то скажет "делой игру без RigidBody" - отвечаю сразу, мне не нужен ассетфлип для рубки бабла, я пытаюсь реализовать конкретные идеи и в результате вынужден бороться с багами движка, хотя ВНЕЗАПНО Bullet позиционируется как среда для симуляции роботов и т.п. важных вещей. Т.е. получается это не Bullet виноват, это KinematicBody в Godot такой кривой? Почему они уже несколько лет не могут пофиксить взаимодействие разбуженного RigidBody и KinematicBody, если в GodotPhysics это частично пофикшено? И почему в GodotPhysics начинается расколбас, если Bullet обрабатывает те же ситуации нормально? Хотя, плевать на GodotPhysics, Bullet кажется более взрослым и серьёзным.
Щас будет боевой клич безыгорника... РРЯЯЯЯЯЯЯЯ!
В ветке 3.x у нас есть два стула:
1. Bullet точёный:
1.1. Спящий RigidBody полностью игнорирует KinematicBody, т.е. можно спокойно двигаться даже по круглому мячику и не будет никаких глюков. Но стоит только RigidBody проснуться, и он будет отлетать от KinematicBody. Впрочем, стоя на проснувшемся мячике его поведение предсказуемо и не вызывает проблем.
1.2. Дверь на RigidBody и 2-х HingeJoint нормально толкается KinematicBody и не зажимает его, но получает слишком сильные удары от него - ведь она не спит, пока открывается.
2. GodotPhysics дрочёный:
2.1. RigidBody не реагирует на KinematicBody даже когда не спит, но только если столкновение боковое: если встать на мячик, то даже если мячик спал, начнётся дикий расколбас - KinematicBody будет резко метаться во все стороны, а мячик рано или поздно вылетит из-под него, что совершенно нереалистично и не должно происходить.
2.2. Та же дверь из 2.1 нормально толкается KinematicBody, получая ровно такие удары, какие я прописал в коде, но ВНЕЗАПНО может зажимать KinematicBody между собой и StaticBody стенкой (точнее CSG с галочкой collider или как там её), в результате чего KinematicBody не может сдвинуться с места и как будто бы находится в воздухе (velocity.y не обнуляется move_and_slide).
Я не знаю, что делать. Я хочу чтобы ПРОСТО можно было двигаться и ПРОСТО правдоподобно взаимодействовать с окружающими предметами, без регулярных застреваний, резких толчков и расколбаса всех ближайших объектов. Кто там Godot 4.0 щупает, как там с физикой? Поправили уже всё или только обещают? Я читал на гитхабе, что они решили избавиться от KinematicBody и сделать специальный CharacterBody, а StaticBody и RigidBody дополнить новыми функциями, но на счёт исправления багов непонятно.
Кто-то скажет "делой игру без RigidBody" - отвечаю сразу, мне не нужен ассетфлип для рубки бабла, я пытаюсь реализовать конкретные идеи и в результате вынужден бороться с багами движка, хотя ВНЕЗАПНО Bullet позиционируется как среда для симуляции роботов и т.п. важных вещей. Т.е. получается это не Bullet виноват, это KinematicBody в Godot такой кривой? Почему они уже несколько лет не могут пофиксить взаимодействие разбуженного RigidBody и KinematicBody, если в GodotPhysics это частично пофикшено? И почему в GodotPhysics начинается расколбас, если Bullet обрабатывает те же ситуации нормально? Хотя, плевать на GodotPhysics, Bullet кажется более взрослым и серьёзным.
В ветке 3.x у нас есть два стула:
1. Bullet точёный:
1.1. Спящий RigidBody полностью игнорирует KinematicBody, т.е. можно спокойно двигаться даже по круглому мячику и не будет никаких глюков. Но стоит только RigidBody проснуться, и он будет отлетать от KinematicBody. Впрочем, стоя на проснувшемся мячике его поведение предсказуемо и не вызывает проблем.
1.2. Дверь на RigidBody и 2-х HingeJoint нормально толкается KinematicBody и не зажимает его, но получает слишком сильные удары от него - ведь она не спит, пока открывается.
2. GodotPhysics дрочёный:
2.1. RigidBody не реагирует на KinematicBody даже когда не спит, но только если столкновение боковое: если встать на мячик, то даже если мячик спал, начнётся дикий расколбас - KinematicBody будет резко метаться во все стороны, а мячик рано или поздно вылетит из-под него, что совершенно нереалистично и не должно происходить.
2.2. Та же дверь из 2.1 нормально толкается KinematicBody, получая ровно такие удары, какие я прописал в коде, но ВНЕЗАПНО может зажимать KinematicBody между собой и StaticBody стенкой (точнее CSG с галочкой collider или как там её), в результате чего KinematicBody не может сдвинуться с места и как будто бы находится в воздухе (velocity.y не обнуляется move_and_slide).
Я не знаю, что делать. Я хочу чтобы ПРОСТО можно было двигаться и ПРОСТО правдоподобно взаимодействовать с окружающими предметами, без регулярных застреваний, резких толчков и расколбаса всех ближайших объектов. Кто там Godot 4.0 щупает, как там с физикой? Поправили уже всё или только обещают? Я читал на гитхабе, что они решили избавиться от KinematicBody и сделать специальный CharacterBody, а StaticBody и RigidBody дополнить новыми функциями, но на счёт исправления багов непонятно.
Кто-то скажет "делой игру без RigidBody" - отвечаю сразу, мне не нужен ассетфлип для рубки бабла, я пытаюсь реализовать конкретные идеи и в результате вынужден бороться с багами движка, хотя ВНЕЗАПНО Bullet позиционируется как среда для симуляции роботов и т.п. важных вещей. Т.е. получается это не Bullet виноват, это KinematicBody в Godot такой кривой? Почему они уже несколько лет не могут пофиксить взаимодействие разбуженного RigidBody и KinematicBody, если в GodotPhysics это частично пофикшено? И почему в GodotPhysics начинается расколбас, если Bullet обрабатывает те же ситуации нормально? Хотя, плевать на GodotPhysics, Bullet кажется более взрослым и серьёзным.
>>78685 (Del)
1. Если будешь публиковать в Стим или на любую другую международную платформу, рано или поздно придут игроки, которым твоя дефолтная раскладка не даёт нормально играть, а сменить некоторые клавиши, допустим, невозможно, или ты поленился делать меню смены раскладки. Или может быть какая-то проблема с раскладками в, например, линуксе. Короче, гораздо надёжнее опираться на сканкоды, потому что сканкод - это адрес физической клавиши, не зависящий от системной раскладки и надписей на клавише. В теории сканкоды у всех современных клавиатур одинаково расположены, не считая кастомных.
2. Попробуй сам и увидишь. Ещё поищи по issues на гитхабе, там может быть полезная инфа. А зачем тебе эта фича? Имхо, если тебе нужно двигать какую-то ноду в глобальной системе координат, для этого нужно или конвертировать координаты (to_local() или global_transform), или размещать эту ноду в другом месте.
1. Если будешь публиковать в Стим или на любую другую международную платформу, рано или поздно придут игроки, которым твоя дефолтная раскладка не даёт нормально играть, а сменить некоторые клавиши, допустим, невозможно, или ты поленился делать меню смены раскладки. Или может быть какая-то проблема с раскладками в, например, линуксе. Короче, гораздо надёжнее опираться на сканкоды, потому что сканкод - это адрес физической клавиши, не зависящий от системной раскладки и надписей на клавише. В теории сканкоды у всех современных клавиатур одинаково расположены, не считая кастомных.
2. Попробуй сам и увидишь. Ещё поищи по issues на гитхабе, там может быть полезная инфа. А зачем тебе эта фича? Имхо, если тебе нужно двигать какую-то ноду в глобальной системе координат, для этого нужно или конвертировать координаты (to_local() или global_transform), или размещать эту ноду в другом месте.
>>78689 (Del)
Ну и что ты мне эту ссылку тычешь? Я уже тыщу раз этот туториал видел. И даже сделал тычки RigidBody как там описано. Проблема не в этих тычках, а в том, что RigidBody в Bullet САМОСТОЯТЕЛЬНО отлетает от KinematicBody, если sleeping == false, хотя этого происходить не должно и в GodotPhysics это не происходит, за исключением случаев "KinematicBody залез на RigidBody", в которых происходят глюки.
Смотри что получается. Вот у меня есть в сцене большой мячик и маленький кусочек сыра.
1. Если я выберу Bullet, я могу пройти по кусочку сыра и ничего не произойдёт. Но мячик будет отлетать от игрока очень далеко из-за того, что излишне реагирует в пробуждённом состоянии.
2. Если я выберу GodotPhysics, мячик будет нормально отлетать с фиксированной силой. Но если игрок случайно или специально пройдёт по кусочку сыра, этот кусочек заглючит и вылетит из-под него в неизвестном направлении с высокой скоростью, а мячик в той же ситуации будет трясти игрока во все стороны.
И это ещё не говоря о дверях, которые в первом случае неадекватно отлетают, а во втором случае могут зажать намертво и хрен знает как эту ситуацию распознать из кода...
Ну и что ты мне эту ссылку тычешь? Я уже тыщу раз этот туториал видел. И даже сделал тычки RigidBody как там описано. Проблема не в этих тычках, а в том, что RigidBody в Bullet САМОСТОЯТЕЛЬНО отлетает от KinematicBody, если sleeping == false, хотя этого происходить не должно и в GodotPhysics это не происходит, за исключением случаев "KinematicBody залез на RigidBody", в которых происходят глюки.
Смотри что получается. Вот у меня есть в сцене большой мячик и маленький кусочек сыра.
1. Если я выберу Bullet, я могу пройти по кусочку сыра и ничего не произойдёт. Но мячик будет отлетать от игрока очень далеко из-за того, что излишне реагирует в пробуждённом состоянии.
2. Если я выберу GodotPhysics, мячик будет нормально отлетать с фиксированной силой. Но если игрок случайно или специально пройдёт по кусочку сыра, этот кусочек заглючит и вылетит из-под него в неизвестном направлении с высокой скоростью, а мячик в той же ситуации будет трясти игрока во все стороны.
И это ещё не говоря о дверях, которые в первом случае неадекватно отлетают, а во втором случае могут зажать намертво и хрен знает как эту ситуацию распознать из кода...
>>78691 (Del)
Добавили только "физические клавиши" в меню действий.
Ты, видимо, говоришь о scancode в InputEvent? Там это как было, так и осталось. Но теперь можно привязывать к действиям эти сканкоды из меню, что удобнее. "Физическими клавишами" это называли, скорее всего, для новичков, которым будет непонятно название "сканкод".
В смысле "летает"? Если это какой-то дрон, который игрок может взять в руки и запустить в самостоятельный полёт, то логичнее использовать add_child/remove_child, потому что этот дрон в свободном полёте является независимой от игрока сущностью. Если, например, тебе потребуется реализовать сцену в подвижном помещении типа грузовика, то дрон должен будет двигаться вместе с грузовиком, а не в глобальной системе координат. ИМХО.
>какую-то новую систему добавили
Добавили только "физические клавиши" в меню действий.
>есть сканкоды, а есть физические сканкоды
Ты, видимо, говоришь о scancode в InputEvent? Там это как было, так и осталось. Но теперь можно привязывать к действиям эти сканкоды из меню, что удобнее. "Физическими клавишами" это называли, скорее всего, для новичков, которым будет непонятно название "сканкод".
>летает в глобальную координату, то возвращается привязанный к игроку
В смысле "летает"? Если это какой-то дрон, который игрок может взять в руки и запустить в самостоятельный полёт, то логичнее использовать add_child/remove_child, потому что этот дрон в свободном полёте является независимой от игрока сущностью. Если, например, тебе потребуется реализовать сцену в подвижном помещении типа грузовика, то дрон должен будет двигаться вместе с грузовиком, а не в глобальной системе координат. ИМХО.
>>78704
Хотя я понял про что ты, типа дрон 5км/с в закрытом поезде 100км/с, да пожалуй это подводный, спасибо
Хотя я понял про что ты, типа дрон 5км/с в закрытом поезде 100км/с, да пожалуй это подводный, спасибо
>>78705 (Del)
Нет же. Это уже давно известный баг. Если sleeping == false, то флаг "infinite_inertia = false" тупо перестаёт работать, как если бы он был true.
Куда их сбрасывать? Если мячик катится мимо KinematicBody и сталкивается с ним, он должен отскочить от него как от StaticBody (т.е. как от другого RigidBody с бесконечной массой), а не улететь за горизонт из-за неработающего флага infinite_inertia. А если сбросить вектор скорости, он остановится на месте.
>>78708 (Del)
Где?
>>78713
Да, именно так.
>Он отлетает в момент пробуждения? Когда sleeping меняется с false на true?
Нет же. Это уже давно известный баг. Если sleeping == false, то флаг "infinite_inertia = false" тупо перестаёт работать, как если бы он был true.
>Может быть просто отследить этот момент и сбросить векторы?
Куда их сбрасывать? Если мячик катится мимо KinematicBody и сталкивается с ним, он должен отскочить от него как от StaticBody (т.е. как от другого RigidBody с бесконечной массой), а не улететь за горизонт из-за неработающего флага infinite_inertia. А если сбросить вектор скорости, он остановится на месте.
>>78708 (Del)
>другая сущность физический сканкод
Где?
>>78713
>дрон 5км/ч в закрытом поезде 100км/ч
Да, именно так.
>>78738 (Del)
Катится == не спит
Лежит == может спать, а может и не спать
В любом случае, когда не спит - буянит из-за воздействия KinematicBody. Я даже слышал мнение, что "в игре могут быть только кинематики или только ригиды", но это бред какой-то.
Впрочем, я уже решил проблемы повышением safe_margin у KinematicBody с 0.001 (1 мм) до 0.05 (5 см). Правда, это не совсем решает проблемы GodotPhysics: KinematicBody продолжает колбасить на RigidBody, сами RigidBody тоже под ним колбасятся, но всё это в меньшей степени. А вот Bullet на первый взгляд полностью вылечился и проснувшийся мячик не реагирует на движущийся KinematicBody. Жаль, я подумывал переключиться на GodotPhysics, но, похоже, Bullet всё-таки лучше. Вдвойне жаль, что его выпиливают из 4.0 в отдельный модуль, который ещё непонятно как подключать (хорошо бы просто кинуть dll в папку с игрой, без перекомпиляции движка)...
Забавно, но года 1.5 назад я уже вроде как решал эту проблему с помощью того же safe_margin, просто совсем забыл.
Судя по документации:
Похоже, ситуация такова:
1. Если safe_margin маленький, KinematicBody телепортируется максимально близко к RigidBody, после чего физический движок регистрирует столкновение с объектом бесконечной массы и пытается разрешить это столкновение сдвигом RigidBody в сторону. Если KinematicBody телепортируется очень часто, RigidBody ничего не остаётся кроме как разгоняться всё больше и больше прочь от этой телепортирующейся стенки (для него это неподвижный объект). Если RigidBody зажат между KinematicBody и StaticBody, он, очевидно, пытается выскочить в сторону.
2. Если safe_margin достаточно большой, KinematicBody телепортируется так, чтобы между ним и другими физическими объектами оставалось свободное пространство. Это позволяет ему избежать регистрации столкновения с RigidBody со стороны физического движка, хотя сам он это столкновение регистрирует. И когда KinematicBody оказывается над RigidBody, он на самом деле висит над ним в воздухе, а не опирается на него, избегая приведения RigidBody в движение (независимо от sleeping).
Всё время забываю, что KinematicBody на самом деле телепортируется (с точки зрения физического движка), а не симулирует полноценное физически точное движение.
>причем тут sleeping?
Катится == не спит
Лежит == может спать, а может и не спать
В любом случае, когда не спит - буянит из-за воздействия KinematicBody. Я даже слышал мнение, что "в игре могут быть только кинематики или только ригиды", но это бред какой-то.
Впрочем, я уже решил проблемы повышением safe_margin у KinematicBody с 0.001 (1 мм) до 0.05 (5 см). Правда, это не совсем решает проблемы GodotPhysics: KinematicBody продолжает колбасить на RigidBody, сами RigidBody тоже под ним колбасятся, но всё это в меньшей степени. А вот Bullet на первый взгляд полностью вылечился и проснувшийся мячик не реагирует на движущийся KinematicBody. Жаль, я подумывал переключиться на GodotPhysics, но, похоже, Bullet всё-таки лучше. Вдвойне жаль, что его выпиливают из 4.0 в отдельный модуль, который ещё непонятно как подключать (хорошо бы просто кинуть dll в папку с игрой, без перекомпиляции движка)...
Забавно, но года 1.5 назад я уже вроде как решал эту проблему с помощью того же safe_margin, просто совсем забыл.
Судя по документации:
>If the body is at least this close to another body, it will consider them to be colliding and will be pushed away before performing the actual motion.
Похоже, ситуация такова:
1. Если safe_margin маленький, KinematicBody телепортируется максимально близко к RigidBody, после чего физический движок регистрирует столкновение с объектом бесконечной массы и пытается разрешить это столкновение сдвигом RigidBody в сторону. Если KinematicBody телепортируется очень часто, RigidBody ничего не остаётся кроме как разгоняться всё больше и больше прочь от этой телепортирующейся стенки (для него это неподвижный объект). Если RigidBody зажат между KinematicBody и StaticBody, он, очевидно, пытается выскочить в сторону.
2. Если safe_margin достаточно большой, KinematicBody телепортируется так, чтобы между ним и другими физическими объектами оставалось свободное пространство. Это позволяет ему избежать регистрации столкновения с RigidBody со стороны физического движка, хотя сам он это столкновение регистрирует. И когда KinematicBody оказывается над RigidBody, он на самом деле висит над ним в воздухе, а не опирается на него, избегая приведения RigidBody в движение (независимо от sleeping).
Всё время забываю, что KinematicBody на самом деле телепортируется (с точки зрения физического движка), а не симулирует полноценное физически точное движение.
>>78738 (Del)
Катится == не спит
Лежит == может спать, а может и не спать
В любом случае, когда не спит - буянит из-за воздействия KinematicBody. Я даже слышал мнение, что "в игре могут быть только кинематики или только ригиды", но это бред какой-то.
Впрочем, я уже решил проблемы повышением safe_margin у KinematicBody с 0.001 (1 мм) до 0.05 (5 см). Правда, это не совсем решает проблемы GodotPhysics: KinematicBody продолжает колбасить на RigidBody, сами RigidBody тоже под ним колбасятся, но всё это в меньшей степени. А вот Bullet на первый взгляд полностью вылечился и проснувшийся мячик не реагирует на движущийся KinematicBody. Жаль, я подумывал переключиться на GodotPhysics, но, похоже, Bullet всё-таки лучше. Вдвойне жаль, что его выпиливают из 4.0 в отдельный модуль, который ещё непонятно как подключать (хорошо бы просто кинуть dll в папку с игрой, без перекомпиляции движка)...
Забавно, но года 1.5 назад я уже вроде как решал эту проблему с помощью того же safe_margin, просто совсем забыл.
Судя по документации:
Похоже, ситуация такова:
1. Если safe_margin маленький, KinematicBody телепортируется максимально близко к RigidBody, после чего физический движок регистрирует столкновение с объектом бесконечной массы и пытается разрешить это столкновение сдвигом RigidBody в сторону. Если KinematicBody телепортируется очень часто, RigidBody ничего не остаётся кроме как разгоняться всё больше и больше прочь от этой телепортирующейся стенки (для него это неподвижный объект). Если RigidBody зажат между KinematicBody и StaticBody, он, очевидно, пытается выскочить в сторону.
2. Если safe_margin достаточно большой, KinematicBody телепортируется так, чтобы между ним и другими физическими объектами оставалось свободное пространство. Это позволяет ему избежать регистрации столкновения с RigidBody со стороны физического движка, хотя сам он это столкновение регистрирует. И когда KinematicBody оказывается над RigidBody, он на самом деле висит над ним в воздухе, а не опирается на него, избегая приведения RigidBody в движение (независимо от sleeping).
Всё время забываю, что KinematicBody на самом деле телепортируется (с точки зрения физического движка), а не симулирует полноценное физически точное движение.
>причем тут sleeping?
Катится == не спит
Лежит == может спать, а может и не спать
В любом случае, когда не спит - буянит из-за воздействия KinematicBody. Я даже слышал мнение, что "в игре могут быть только кинематики или только ригиды", но это бред какой-то.
Впрочем, я уже решил проблемы повышением safe_margin у KinematicBody с 0.001 (1 мм) до 0.05 (5 см). Правда, это не совсем решает проблемы GodotPhysics: KinematicBody продолжает колбасить на RigidBody, сами RigidBody тоже под ним колбасятся, но всё это в меньшей степени. А вот Bullet на первый взгляд полностью вылечился и проснувшийся мячик не реагирует на движущийся KinematicBody. Жаль, я подумывал переключиться на GodotPhysics, но, похоже, Bullet всё-таки лучше. Вдвойне жаль, что его выпиливают из 4.0 в отдельный модуль, который ещё непонятно как подключать (хорошо бы просто кинуть dll в папку с игрой, без перекомпиляции движка)...
Забавно, но года 1.5 назад я уже вроде как решал эту проблему с помощью того же safe_margin, просто совсем забыл.
Судя по документации:
>If the body is at least this close to another body, it will consider them to be colliding and will be pushed away before performing the actual motion.
Похоже, ситуация такова:
1. Если safe_margin маленький, KinematicBody телепортируется максимально близко к RigidBody, после чего физический движок регистрирует столкновение с объектом бесконечной массы и пытается разрешить это столкновение сдвигом RigidBody в сторону. Если KinematicBody телепортируется очень часто, RigidBody ничего не остаётся кроме как разгоняться всё больше и больше прочь от этой телепортирующейся стенки (для него это неподвижный объект). Если RigidBody зажат между KinematicBody и StaticBody, он, очевидно, пытается выскочить в сторону.
2. Если safe_margin достаточно большой, KinematicBody телепортируется так, чтобы между ним и другими физическими объектами оставалось свободное пространство. Это позволяет ему избежать регистрации столкновения с RigidBody со стороны физического движка, хотя сам он это столкновение регистрирует. И когда KinematicBody оказывается над RigidBody, он на самом деле висит над ним в воздухе, а не опирается на него, избегая приведения RigidBody в движение (независимо от sleeping).
Всё время забываю, что KinematicBody на самом деле телепортируется (с точки зрения физического движка), а не симулирует полноценное физически точное движение.
>>78757
Поставлю галку, чтоб меня не перепутали с каким-нибудь движкосрачером.
Я слышал, что в других движках вообще нет никакого кинематикбоди. Есть только ригидбоди и режим кинематик у них, если тебе нужно. Попробуй копнуть в эту сторону.
> Я даже слышал мнение, что "в игре могут быть только кинематики или только ригиды", но это бред какой-то.
Поставлю галку, чтоб меня не перепутали с каким-нибудь движкосрачером.
Я слышал, что в других движках вообще нет никакого кинематикбоди. Есть только ригидбоди и режим кинематик у них, если тебе нужно. Попробуй копнуть в эту сторону.
>>78761 (Del)
Ты троллишь или просто нуб?
https://github.com/godotengine/godot/issues/31981
Этому багу уже почти 3 года. Пофиксили в 4.0, вроде бы, благодаря введению односторонних взаимодействий через слои. Хотя логика всё равно... странная, теперь, получается, важен порядок слоёв.
>>78760
Ну да, да, кинематик - это ригидбоди с бесконечной массой, то есть его никто с места столкнуть не может, кроме кода. Я как раз на днях читал в иссуях годо обсуждение изменений, которые уже внесли в 4.0: теперь нет никакого отдельного "кинематикбоди", есть только статик, ригид, и... "чарактер", который наследует иконку кинематикбоди:
https://docs.godotengine.org/en/latest/classes/class_characterbody3d.html
Кстати, "чарактер" есть как минимум в юнити. В юнити я пробовал, там суть практически та же, так что переименование логичное. Но лучше всего то, что теперь все параметры move_and_slide уехали в свойства объекта, где им и место.
А у ригидбоди, который теперь ригиддинамикбоди (лол), убрали выбор режима и сделали галку "заморожен" и "режим заморозки" - статик и кинематик. Вроде логично. Также добавили возможность ПРОСТО указать центр масс в виде вектора, не извращаясь с переносом коллиженшейпов или добавлением ещё одного.
Также добавили аниматаблебоди, который наследуется от статикбоди и содержит галочку, которая раньше была у кинематикбоди (синк ту физикс). Типа чисто для платформ, дверей и т.п.
Ты троллишь или просто нуб?
https://github.com/godotengine/godot/issues/31981
Этому багу уже почти 3 года. Пофиксили в 4.0, вроде бы, благодаря введению односторонних взаимодействий через слои. Хотя логика всё равно... странная, теперь, получается, важен порядок слоёв.
>>78760
>нет никакого кинематикбоди
>ригидбоди и режим кинематик
Ну да, да, кинематик - это ригидбоди с бесконечной массой, то есть его никто с места столкнуть не может, кроме кода. Я как раз на днях читал в иссуях годо обсуждение изменений, которые уже внесли в 4.0: теперь нет никакого отдельного "кинематикбоди", есть только статик, ригид, и... "чарактер", который наследует иконку кинематикбоди:
https://docs.godotengine.org/en/latest/classes/class_characterbody3d.html
Кстати, "чарактер" есть как минимум в юнити. В юнити я пробовал, там суть практически та же, так что переименование логичное. Но лучше всего то, что теперь все параметры move_and_slide уехали в свойства объекта, где им и место.
А у ригидбоди, который теперь ригиддинамикбоди (лол), убрали выбор режима и сделали галку "заморожен" и "режим заморозки" - статик и кинематик. Вроде логично. Также добавили возможность ПРОСТО указать центр масс в виде вектора, не извращаясь с переносом коллиженшейпов или добавлением ещё одного.
Также добавили аниматаблебоди, который наследуется от статикбоди и содержит галочку, которая раньше была у кинематикбоди (синк ту физикс). Типа чисто для платформ, дверей и т.п.
>>78562
Вспомнить бы ещё ту школьную программу, когда тебе под сраку лет а в 90х в школах ничему не учили.
В целом то я понимаю все. Просто когда я смотрю туториалы, где автор так свободно и уверенно оперирует математикой а мне даже не то, что требуется время чтоб переварить и обрисовать в голове для понимания, а осознание, что самостоятельно я и не додумался бы до этого. И это элементарные вещи, типа движений npc. Думаю, с опытом будет проще.
Сейчас расписал себе месяц на подготовку. За недельку - две пройдусь по оф документации. Ещё пара недель пересмотрю туториалы на ютубе по своей теме и возьмусь за дело.
Тоже думаю себе вики завести, и набросать там ООП шаблон, которому буду следовать, чтоб потом не переделывать.
Вспомнить бы ещё ту школьную программу, когда тебе под сраку лет а в 90х в школах ничему не учили.
В целом то я понимаю все. Просто когда я смотрю туториалы, где автор так свободно и уверенно оперирует математикой а мне даже не то, что требуется время чтоб переварить и обрисовать в голове для понимания, а осознание, что самостоятельно я и не додумался бы до этого. И это элементарные вещи, типа движений npc. Думаю, с опытом будет проще.
Сейчас расписал себе месяц на подготовку. За недельку - две пройдусь по оф документации. Ещё пара недель пересмотрю туториалы на ютубе по своей теме и возьмусь за дело.
Тоже думаю себе вики завести, и набросать там ООП шаблон, которому буду следовать, чтоб потом не переделывать.
>>78836
Хотелось бы взглянуть на более длинный код чем две строки. Строк на 100 хотя бы.
Хотелось бы взглянуть на более длинный код чем две строки. Строк на 100 хотя бы.
Unity
>>66120 (OP)
Мне нужен пример адекватного арканоида для создания, в ассетах не нашёл, нашёл только урок на тытрубе, всё нормально, кроме того, что там управление клавой, а не мышью, я сделал как хочу, но получается просто пиздец как криво.
Где или как искать?
Мне нужен пример адекватного арканоида для создания, в ассетах не нашёл, нашёл только урок на тытрубе, всё нормально, кроме того, что там управление клавой, а не мышью, я сделал как хочу, но получается просто пиздец как криво.
Где или как искать?
>>78957
Криво кинематические объекты, я подобную игру могу сделать и на С++ без проблем, но беда именно с пониманием того как всё устроено в годоте, делать хуету платформер неинтересно.
А вот хочется сделать арканоид с меню, настройками разрешения, графона, может быть клавиш, понятное дело, что всё это фигачить с нуля такое себе, а тут готовое.
Забил я на кинематики пока и повторяю за испанцем area2d
С мышью особых проблем не возникло, просто удивило, что бля клавишами двигать платформу, видать сложно или нудно ему показалось.
Ну и странно, что пока с камерой не возится, а это как бэ тоже важно - масштабирование в зависимости от разрешения там, соотношения сторон моника и тд.
Для 2д пока топчик, хочу попробовать потом бахнуть сапёр, ато на шарпе и винформс лагат, а в впф чот не хочется совсем пока.
Кароч, уроки есть, ассеты видал, но пока что видал, то слишком тривиальное и именно для создания полноценной игры, а не окошка демкой чот не вижу, что печально.
Криво кинематические объекты, я подобную игру могу сделать и на С++ без проблем, но беда именно с пониманием того как всё устроено в годоте, делать хуету платформер неинтересно.
А вот хочется сделать арканоид с меню, настройками разрешения, графона, может быть клавиш, понятное дело, что всё это фигачить с нуля такое себе, а тут готовое.
Забил я на кинематики пока и повторяю за испанцем area2d
С мышью особых проблем не возникло, просто удивило, что бля клавишами двигать платформу, видать сложно или нудно ему показалось.
Ну и странно, что пока с камерой не возится, а это как бэ тоже важно - масштабирование в зависимости от разрешения там, соотношения сторон моника и тд.
Для 2д пока топчик, хочу попробовать потом бахнуть сапёр, ато на шарпе и винформс лагат, а в впф чот не хочется совсем пока.
Кароч, уроки есть, ассеты видал, но пока что видал, то слишком тривиальное и именно для создания полноценной игры, а не окошка демкой чот не вижу, что печально.
>>78959
На данный момент я так воспринимаю, ибо в унити можно бахнуть вычислительные шейдеры, я на них воксели сделал, но как же я матерился, что нету готового урока по этому, опездолы блядь цпу воксели рисуют с охуевшим видом и это выдают за открытие, и это я молчу про то как красить их попиксельно. Просто пиздец конечно сейчас разрабы попёрли.
На данный момент я так воспринимаю, ибо в унити можно бахнуть вычислительные шейдеры, я на них воксели сделал, но как же я матерился, что нету готового урока по этому, опездолы блядь цпу воксели рисуют с охуевшим видом и это выдают за открытие, и это я молчу про то как красить их попиксельно. Просто пиздец конечно сейчас разрабы попёрли.
>>78962
спасибо, но если бы выбор пал на другой движок, то уж с гораздо большим приятием он бы пал на UE, где это все делать гораздо приятнее
спасибо, но если бы выбор пал на другой движок, то уж с гораздо большим приятием он бы пал на UE, где это все делать гораздо приятнее
>>78963
Сверхчеловек, ты?
Я вот попробовал на уече, да, вроде всё нарм, только он тяжёлый и не всегда понятный, унити после него просто супер лёгкий и удобный по ощущениям. А уж делать POM на нодах было и весело и жутко.
Не спеши графон делать, обрати внимание на новые ниппон игры, там авторы не ебут мозги и делают мелкие, но хорошо проработанные локи вместо унылого и пустого огромного мира. Мне нравится такая концепция создания игр и я стараюсь идти этим путём. Пусть мелкая игра, но пездатая.
Например:
ты просто охренеешь делать детализированную деревушку с травой, десятью домами, церквушкой, забрами, плодовыми кустами и деревьями, ручьём и живностью. Про мир с несколькими такими и даже городом тут и говорить нечего. Задача намного сложнее чем кажется.
> где это все делать гораздо приятнее
Сверхчеловек, ты?
Я вот попробовал на уече, да, вроде всё нарм, только он тяжёлый и не всегда понятный, унити после него просто супер лёгкий и удобный по ощущениям. А уж делать POM на нодах было и весело и жутко.
Не спеши графон делать, обрати внимание на новые ниппон игры, там авторы не ебут мозги и делают мелкие, но хорошо проработанные локи вместо унылого и пустого огромного мира. Мне нравится такая концепция создания игр и я стараюсь идти этим путём. Пусть мелкая игра, но пездатая.
Например:
ты просто охренеешь делать детализированную деревушку с травой, десятью домами, церквушкой, забрами, плодовыми кустами и деревьями, ручьём и живностью. Про мир с несколькими такими и даже городом тут и говорить нечего. Задача намного сложнее чем кажется.
>>78965
а что там тяжелого-то? всякие логические связи пишешь нодами как и для дизйнеров пишешь новые ноды под игру, им только ползунки дергать да простейшую логику клепать
нагруженные алгоритмы в плюсах сразу
я и не спешу, вопрос был в том, что вытянет ли годот сейчас графоний открытого мира типа ванильного скайрима или пока не рисковать на него спрыгивать, потому что кучу всего для рендера самому еще дописывать придется
ну это на стадии разработки проекта геймдизайнерами требуется, а сейчас уже другая, где с технологиями определяемся под уже написанный диздок
я и не буду, этим моделлеры и дизайнеры занимаются уже
> Я вот попробовал на уече, да, вроде всё нарм, только он тяжёлый и не всегда понятный
а что там тяжелого-то? всякие логические связи пишешь нодами как и для дизйнеров пишешь новые ноды под игру, им только ползунки дергать да простейшую логику клепать
нагруженные алгоритмы в плюсах сразу
> Не спеши графон делать
я и не спешу, вопрос был в том, что вытянет ли годот сейчас графоний открытого мира типа ванильного скайрима или пока не рисковать на него спрыгивать, потому что кучу всего для рендера самому еще дописывать придется
> обрати внимание на новые ниппон игры
ну это на стадии разработки проекта геймдизайнерами требуется, а сейчас уже другая, где с технологиями определяемся под уже написанный диздок
>ты просто охренеешь делать детализированную деревушку с травой .. Задача намного сложнее чем кажется.
я и не буду, этим моделлеры и дизайнеры занимаются уже
>>78967
Годот вытянет.
Ты - не вытянешь.
> вытянет ли годот сейчас графоний открытого мира типа ванильного скайрима
Годот вытянет.
Ты - не вытянешь.
>>78967
Только сейчас я понял, что он вышел в 2011 году. Я не знаю умеет ли годот рисовать большие миры с подгрузкой и без лагов.
Только сейчас я понял, что он вышел в 2011 году. Я не знаю умеет ли годот рисовать большие миры с подгрузкой и без лагов.
>>78969
Умеет.
Ты не умеешь. Потому что ты ебанёшь подгрузку чанков в один поток с основным деревом сцены и будешь визжать про тормоза, и трясти скрином настроек, где ты включил поддержку многопоточности. Выкатывайся уже давай в свой загон. Не доводи до репорта.
> умеет ли годот рисовать большие миры с подгрузкой и без лагов
Умеет.
Ты не умеешь. Потому что ты ебанёшь подгрузку чанков в один поток с основным деревом сцены и будешь визжать про тормоза, и трясти скрином настроек, где ты включил поддержку многопоточности. Выкатывайся уже давай в свой загон. Не доводи до репорта.
>>78973
Ты лучше мне ответь, а если в годоте автоматическая преобразовалка в многоугольник для столкновений некого 2д изображения на основе его прозрачности.
Ты лучше мне ответь, а если в годоте автоматическая преобразовалка в многоугольник для столкновений некого 2д изображения на основе его прозрачности.
>>78968
столько много в рендере придется переписывать по сравнению с UE ?
>>78970
да, пробовал, делал, но хотелось бы меньше всего с той частью, что отвечает за рендер и его оптимизацию
> Ты - не вытянешь.
столько много в рендере придется переписывать по сравнению с UE ?
>>78970
> Ебашишь нагруженные алгоритмы в адаптеры, наследующиеся от Node в Godot API, в том числе тянущие API твоих или третьих библиотек, фреймворков, систем.
да, пробовал, делал, но хотелось бы меньше всего с той частью, что отвечает за рендер и его оптимизацию
>>78988 (Del)
а на последних двух видосах не знаешь сколько треугольников и дравколов?
а на последних двух видосах не знаешь сколько треугольников и дравколов?
>>78993
Да, спасибо.
Да, спасибо.
Тред утонул или удален.
Это копия, сохраненная 15 мая 2023 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Это копия, сохраненная 15 мая 2023 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.