Можно с кем созвониться по тг пообсуждать геймдизайн?
Ответил тебе не я, я проигнорил.
Был бы Сахедо жив... Хоть бы списался
немимопикселеёб
Опять забыли в шапку добавить список успешных игр.
Действительно.
Ну оставлю тут одну на миллион долларов.
(Автор этого поста был предупрежден.)
Сахедо просит передать, что он покушал арбузик и смотрит ютубчик. Думать о геймдеве ему неохота. Приходите завтра.
Целая одна? Успех.
Вырвиглазная стыдная параша, годоти даже тут обосрались. Вроде реально есть игра, а вроде такое постить зашкварно пиздец
Ну жив и хорошо. Это главное
>ПОЧЕМУ НЕ ДВЕ
Спрашивали про успешную, а не про красивую.
Ну так то да. Играть в это я конечно же не буду
Один только взгляд на Cruelty Squad может вызвать у вас тошноту, но он проходит самые важные тесты на погружение в симуляторы с яркими, тошнотворными цветами. Я использовал классические вентиляционные маршруты, чтобы тихо убить надувной замок из плоти в одном прохождении, переключившись на ракетную установку и используя свои кишки в качестве крюка для захвата для более прямого подхода в следующем. Я сложил достаточно стволов, чтобы перелезть через целые здания, и поразил несколько целей идеально рассчитанными снайперскими выстрелами через всю карту.
Cruelty Squad - это Deus Ex, если бы он был создан сегодня, естественный продукт разъяренных людей, измученных неравенством богатства, милитаризацией полиции и упрямыми структурами, которые заставляют человечество катиться к полному уничтожению души. Ага.
Но Отряд жестокости хочет повеселиться до неизбежного конца. Это игра-невидимка, которая подпирает чистую, безмозглую радость от ощущения, что я перехитрил дизайнеров с помощью диких экспериментов, даже если я делаю именно то, что они ожидали. Как и Хитман, это катарсическое упражнение по уничтожению абсолютно худших живых людей. Это аудиовизуальное чудо, виртуальный мир, распадающийся на ваших глазах. И это одна из самых блестящих абсурдных игр, в которые я играл, видение будущего, в котором люди считаются корпоративными дочерними компаниями, а рынок оружия меняется в зависимости от того, какое оружие лицензировано для использования в популярном аниме.
Кто тебя из загона выпустил, животное.
Сила годота! Проперти сами все считают как калькулятор.
В тайлмапы анимацию добавили уже?
Она там давно есть, через animated texture. В пуштайме так блоки с глазами моргают.
Мастхев аддон, сразу дающий +100 к качеству вашей игры
https://godotengine.org/asset-library/asset/977
Инструкция проста до безобразия.
Просто кидаешь в главную сцену.
Опционально если какие-то сцены загружаются динамически, подвешиваешь их под него.
Все, вы великолепны.
https://godotengine.org/asset-library/asset/977
Инструкция проста до безобразия.
Просто кидаешь в главную сцену.
Опционально если какие-то сцены загружаются динамически, подвешиваешь их под него.
Все, вы великолепны.
Начал писать многие скрипты в виде
func get_some(index)
var smth = {"KeyA": "value1", "KeyB": "value2"}[index]
Удобно для джемов
func get_some(index)
var smth = {"KeyA": "value1", "KeyB": "value2"}[index]
Удобно для джемов
И другой лайфхак
for s in ["Circle", "Triangle", "Square"]: ...
Зачем функция вообще? Объяви и заполни без задней мысли словарь в начале скрипта, а потом без задней мысли пиши где надо: smth[index]
Вот это охуенная фича питона! Слава Хуану, что перетащил её в годот.
К слову, в си# так же можно, но разумеется, формальностей больше:
foreach (string s in new string[] { "Circle", "Triangle", "Square" } ) { Console.WriteLine(s); }
> чтобы в начало скрипта к словарю не листать
Палю тебе лайфхак. Если скрипт объявить вместе с содержимым, оно подставляется в подсказках редактора.
> Если словарь объявить
Слоооооуфикс.
Я чо, списки шарповские юзать тут не могу? Или что то не так делаю?
Там
System.Collections.Generic
а не
System.Collection.Generic
Ох, вей, точно, надо будет студию подключить видимо лучше
Вот в списке у меня экземпляры классов персов лежат. Как мне их на сцену добавить, при этом для каждого еще разные спрайты должны быть в зависимости от их полей?
Я к студии привык, вс код как то всрато выглядит, ну и с ним ебля какая то нужна, а не включил и код пишешь, насколько я помню
Не очень понятен вопрос. Я обычно делаю так
var npc = npc_tscn.instance()
npc.set_parameters(blabla) #какая то инициализация
npc_container.add_child(npc)
npc.set_position_and_other(...) #то что имеет смысл только после добавления в дерево, например global_position
Не, вот гляди. Есть у мейн сцена. Есть у меня класс с коллизией. В классе поля, типо, pozitionX, pozitionY, weapon и тд.
В мейн сцене скрипт, в методе Ready я создаю штук десять этих экземпляров классов и кладу их в лист, естественно, чтобы потом можно было перебирать. При создании указываю у них разное оружие. Теперь мне их надо на мейн сцену всех добавить, но при этом спрайт самого хумана один и тот же, меняется только спрайт оружия в зависимости от того что в поле weapon. То есть по итогу на сцене должны быть десять хуманов, но с разным спрайтом оружия
А я и в студии работаю, и в коде. В студии удобно десктопные формы формошлёпить и встроееным дебаггером запускать на дебаг, а в коде удобнее кодить модули стороннего софта (годот, юнити) который самостоятельно проекты запускает на дебаг/исполнение.
>positionX
Это есть штатно в нодах
> чтобы потом можно было перебирать
Их и так можно перебирать через GetChildren(), но тут уже как тебе удобней.
>я создаю штук десять этих экземпляров
Ок, их и добавляешь через AddChild куда хочешь.
В годоте сцена представлена деревом, у любой ноды есть метод AddChild. Я обычно для однотипных сущностей держу отдельную ноду, типа NpcContainer, BulletContainer. Помогает например быстро удалить всех.
> при этом спрайт самого хумана один и тот же, меняется только спрайт оружия в зависимости от того что в поле weapon.
Берешь и меняешь, это можно сделать кучей способов.
У меня в таких случаях оружие - отдельная сцена, но можно и просто спрайт. За смену может отвечать сам класс хумана. В C# есть проперти, они же setget в гдскрипте. При изменении переменной вызовется соответствующая функция, в ней и поменяешь спрайт
[Export] Weapon weapon
{
get {return weapon;}
set {weapon = value; set_your_texure(weapon); }
}
Ага, понятно, спасибо.
С точки зрения программиста нода это некая сущность, любой объект, класс по сути. А сцена тогда это что? Контейнер для классов, типо, модуль или как?
Если ты только вкатываешься, то читай step by step
https://docs.godotengine.org/en/stable/getting_started/step_by_step/index.html
Потому что пересказывать документацию смысла особого нет.
Как устроена сцена, можешь в блокноте смотреть, это текстовый файл.
> это текстовый файл
Это если в расширении файла есть метка t - текстовый, файлы же scn - бинарные. Правда ими никто не пользуется (даже я).
Ну вот открыл и чо
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.
Нода это узел, узел может содержать другие узлы и у него есть имя и свойства. И чо? Чо это такое, с точки зрения программиста? Класс? Ну вот сцена может инстанциироваться, так вроде тогда сцена это класс, а узел тогда что?
>Чо это такое, с точки зрения программиста?
Нода это один из базовых классов, узел дерева (спрайты, элементы интерфейса и прочее наследуются от него).
Сцена это дерево, состоит из узлов, может включать подсцены. Имеет определенную логику, например, более нижние узлы рисуются поверх предыдущих (если не задать z-глубину), по умолчанию работает более нижняя камера и т.д.
> И чо? Чо это такое, с точки зрения программиста?
Сериализованные данные.
Дальше сам.
Бля затупил. Отвечаю повторно.
> И чо? Чо это такое, с точки зрения программиста?
Дерево нод - это шаблон проектирования, известный как Компоновщик https://refactoring.guru/ru/design-patterns/composite
Вот теперь дальше сам, по ссылочкам и в гугел.
Кстати, планируешь закатываться снова, пока всю какаву не выпили и музыку для жёлтой зоны не нашли?
Я пока в сомнениях. Не вдохновляет меня пиксельарт. Я хочу делать игры в графическом стиле Crippy Tale, например, со скелетной анимацией и художественным графоном. Ты, как я понимаю, такой уровень графона мне поставить не сможешь.
Всё так. Я в пуксели потому и подался, что рисовать не умею.
Может в /гд/ и будут идейные товарищи кто так запилит, но сомневаюсь
Есть ли в годоте какие-то алгоритмы по графам, кроме AStar? Или надо самому всё реализовывать/библиотеки искать?
Не занимайся преждевременной оптимизацией. Делай игру на астаре.
Да есть у меня AStar уже.
Но с ним ИИ вытворяет дикие кренделя в сборке ресурсов по карте. Потому что когда надо обойти граф, то получается жадный алгоритм, который бегает от вершины к ближайшей вершине. Обмазал пока его кучей ифов, чтобы составить правдоподобный маршрут. Но выглядит костыльно, хотя и работает. Я не хочу сделать, чтобы ИИ бегал по карте с максимально оптимальным маршрутом, потому что 100% эффективность не выглядит интересной, но ИИ, который мечется на ровном месте тоже выглядит странным.
У меня другой вопрос возник. Что я делаю не так с извлечением значения в двумерном массиве (естественно, массив массивов)?
У меня извлекается нужное значение, но в виде массива, например vortexDistance[2][6] как [4]. При этом для одномерных массивов там сразу извлекается int, вроде 4.
Пока закостылил через даблкаст int(str()), но костыль же.
AStar надо тюнить, иначе он рисует зигзаги или тупо диагональ и потом прямую.
По-моему для базового тюнинга хватает годотовского из коробки, там можно переопределять функции compute_cost, estimate_cost https://docs.godotengine.org/en/stable/classes/class_astar.html
Можешь попробовать формулы отсюда или отсюда
https://www.redblobgames.com/pathfinding/a-star/implementation.html#troubleshooting-ugly-path
http://theory.stanford.edu/~amitp/GameProgramming/Heuristics.html#exact-heuristics
> Что я делаю не так с извлечением значения в двумерном массиве
Возможно ты не так его заполняешь. Т.е. засовываешь не значение, а массив.
> Что я делаю не так с извлечением значения в двумерном массиве (естественно, массив массивов)?
Возможно, у тебя типичная ошибка при работе с массивмассивычем. У него чтение элементов идёт в формате массивыч[y][x]. Массив-наоборот с толщечислами.
Кстати не советую массивы массивов, это почти наверняка удар по производительности. Можешь написать простую функцию-помощник, типа
get_value(i,j): return array[i+j*ARRAY_WIDTH]
Кстати двачую.
Чтобы произвести обратное действие и разложить индекс массива на координаты i,j (они же x,y) нужно применить несложную формулу:
X = index % ARRAY_WIDTH
Y = index / ARRAY_WIDTH
Не вижу никаких проблем. Ты же говоришь [2][1], что соответствует в человекочитаемом языке "эй, годо, отдай мне третий массив, второй элемент".
Уже отказался. Слишком много возни. Перешёл на словари массивов, кек. Но работать стало удобнее + осталась возможность пользоваться преимуществами одномерных массивов + возможность использования фунцкии для создания соваря-перевёртыша, что позволяет обратный поиск совершать удобно именно по значению.
Вообще, не думаю, что на ограниченных объёмах таблиц размеров типа 6*6 производительность прямо критично просядет. И всяко удобнее, когда ты не знаешь, будет у тебя таблица 2х2 или 5х5,но точно никогда 8х8 и больше.
Так ведь же именно так и работают массивы, с обратной перечислением координат.
Именно поэтому во всех топ-современных софтах с тремя осями XYZ высоту обозначают Z, а не Y.
Потому, как если бы мы хотели трёхмерный массив сделать (аля чанк майнкрафта), мы бы выбирали элемент по elements[z][y][x]. То есть, сначала слой по высоте, потом ряд, потом элемент из ряду.
> Именно поэтому во всех топ-современных софтах с тремя осями XYZ высоту обозначают Z, а не Y.
А почему раньше высота была Y?
А по сохранениям подскажите.
Как лучше сделать? Пилить предварительно свою структуру данных, которую потом сохранять? Или есть возможность, например, сохранить пачку глобальных переменных и радоваться жизни? До этого пикрил накидал в качестве заглушки, а вот теперь дошёл до того, чтобы сделать системы сохранения и загрузки.
Как лучше сделать? Пилить предварительно свою структуру данных, которую потом сохранять? Или есть возможность, например, сохранить пачку глобальных переменных и радоваться жизни? До этого пикрил накидал в качестве заглушки, а вот теперь дошёл до того, чтобы сделать системы сохранения и загрузки.
А, пожалуй, поторопился.
С json всё красиво раскладывается.
Ретранслирую совет из документации. Делай группу сохраняемых сущностей, в каждой из них делай метод get_save_data, возвращающий жсон с актуальными данными, затем собирай это всё и в файл.
А от себя хочу предложить мой авторский метод, который я частично и у тебя на скрине наблюдаю. Делаешь синглтон WORLD в котором есть глобальный словарь со всем конфигом мира, членами которого являются подсловари-секции локаций, внутри которых можно организовать подсловари-секции объектов на локации.
Синглтон держит всю инфу игрового мира в памяти всё время, когда пользователь играет. При загрузке загружается полный файл, со всеми данными мира. При записи записывается так же весь файл.
Казалось бы оверхэд?
Но нет. При такой системе элегантно и без дополнительных усилий игра может менять состояния незагруженных в данный момент объектов. И когда игрок придёт в новую локацию, там его будут уже автоматически ожидать изменившиеся условия.
Например. Довакин в Вайтране сдал страже некоторого вора, ограбившего некоторого прохожего. Получил награду. И пошел в Виндхельм. Оттуда пошёл в Маркарт. По пути зачистил сотню пещер. Забыл уже об этом инциденте. И только много дней спустя посетил Рифтен, а там на него заагрились воры в подворотне. Потому что тот квест отправил данные в секцию Рифтена о том, что таких-то НПЦ требуется переключить во враждебную фракцию игроку.
Или другой пример. Довакин помог неписю с бедой. Непись поблагодарил и пошёл домой. Можно проследить за ним, как он пиздует пешком через всю карту, и он будет честно идти. Но если игрок уходит в противоположную сторону, непись выгружается и записывает график своего местонахождения в несколько локаций по пути следования так, что в идеале, пока он идёт, Довакин может рандомно наткнуться на него. Но эта фича сложная, даже у тодда глючит, есть знаменитый баг, когда какая-то орчиха, не помню уже имя, заглючивает и начинает рандомно встречаться Довакину в разных локациях.
Или третий пример. Квест затрагивает несколько локаций. Согласно стадиям квеста, локации должны принимать тот или иной вид. На одной руке имеем принудительную проверку каждой загружаемой локацией состояние всех квестов в книге Довакина. На другой - элегантная запись самим квестом изменений в параметры затрагиваемых локаций, так что им при своей загрузке ничего лишнего проверять не надо. Об Довакине и его книге квестов знать ничего не надо.
Пилю пошаговую игру, и решил потестить на одном некро андроиде.
Так вот, вопрос в чем. Версия на C# грузится 5 секунд, на gdscript 4 секунды (+ 2 секунды если холодный старт в обоих случаях). Я правильно думаю что ради 1 секунды загрузки нет смысла отказываться от плюшек C#? Или в гуглоплее с этим строго.
Так вот, вопрос в чем. Версия на C# грузится 5 секунд, на gdscript 4 секунды (+ 2 секунды если холодный старт в обоих случаях). Я правильно думаю что ради 1 секунды загрузки нет смысла отказываться от плюшек C#? Или в гуглоплее с этим строго.
Дети смотрели на доску и видели траекторию полёта мячика. "Ага, значит Y — высота". Но потом пришло поколение, которое видело тертрадку, а тетрадь горизонтально расположена, значит X и Y это горизонтальные оси.
На самом деле я не знаю, почему и зачем так делали. Я и сам раньше был адептом игрековой высоты, но как осознал индексацию, так и понял, что лучше Z использовать.
>элегантная запись самим квестом изменений в параметры затрагиваемых локаций, так что им при своей загрузке ничего лишнего проверять не надо
Лишь бы разработчик не допустил баг, записывающий в локации неправильное, так что даже при перезапуске игры прохождение будет запоротым.
> а тетрадь горизонтально расположена, значит X и Y это горизонтальные оси.
А ты на тетрадь смотришь под углом в 90 градусов? Потому что у всех нормальных людей верх тетрадного листа - это "вверх", а не "вперёд".
Ты невнимательно читаешь анона. Если позволите вступлюсь за него.
Он написал, что мыслить следует категориями: Слой-Ряд-Элемент. Тогда все противоречия отпадают. Иначе же можно до хрипоты спорить, что один видит лист так, а второй - эдак. Одному игрек высота, другому ширина.
Как изменить размеры экрана при смене ориентации с модом 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 не изменились даже от смены размера.
Скорее всего годот сам меняет пропорции, а потом приходишь ты и меняешь ещё раз вручную. Чисто с дивана предположил. Чисто по своему опыту знакомства с годотом - я многие вещи пытался велосипедить, а потом оказывалось, что всё это было искаропки, надо только доки почитать внимательно.
Так, и как мне искаропки сделать возможность менять ориентацию экрана, но с keep_width?
Я не знаю. Читай документацию.
Ага, спасибо, помогло.
Кстати, злобная штука, когда сейвы херятся по техническим причинам.
У меня так похерилось 2 катки в стелларисе на айрон моде. Потому что оно записало где-то ошибку, видимо, и меня выкидывало на следующий внутриигровой месяц всегда.
На каждую старуху бывает проруха, хоть делай интегрити-чек, хоть нет, особенно, если игра с модами.
Яндекс сделал автоматический голосовой перевод видосов.
Я ухожу пересматривать гейм эндевора на русском!
Я ухожу пересматривать гейм эндевора на русском!
>И до следующего раза... ВЫ ВСЕ УСПОКОЙТЕСЬ!
Сделан мой вечер!
Сделан мой вечер!
Переводы улучшились, но всё равно почти в каждом предложении косячат
А вы используете Государственную Машину в своих играх?
"Технически Ultimate скорее реконструкция на новом движке, чем ремастер. Colors перенесли с форка Hedgehog Engine на открытый движок Godot. Здесь создатели Ultimate поступили максимально странно: они создали свой форк Godot, назвали его Blind Squirrel Engine, и удалили все упоминания Godot. Разработчики уже извинились и пообещали исправить эту оплошность в ближайшем патче"
https://twitter.com/falessandrelli/status/1433856957476216840
как перестать ржать??)
https://twitter.com/falessandrelli/status/1433856957476216840
как перестать ржать??)
>Разработчики уже извинились и пообещали исправить эту оплошность в ближайшем патче
Следующий патч: "Обратите внимание, это не мы с игрой обосрались, это годотя нам в штаны насрала".
Sonic Colors: Ultimate isn’t even officially out yet
Да-да, к релизу все обязательно пропатчат и заапдейтят. Ты, может, еще в деда мороза веришь до сих пор?
> Здесь создатели Ultimate поступили максимально странно
Поступили как и большинство ньюфагов, встречающих опенсорс. БЛЯТЬ, КОД! БЕСПЛАТНО! Я ЕГО ПЕРЕИМЕНУЮ И ВЫДАМ ЗА СВОЙ
В корпорациях конечно бюрократия, но добавить кредитсы это не долго.
Я не про кредитсы говорю, а про то, что игра - забагованный пиздец.
Ну понятно. Вот только баг там несложный для исправления, да и вызывают его спецом задрачивая меню выбора уровня.
Как воспроизвести видео из ютуба или все еще не завезли поддержку кодеков?
Ваше мнение?
https://docs.godotengine.org/en/stable/classes/class_jsonrpc.html
Можно через это взаимодействовать с сервером на другом языке.
https://docs.godotengine.org/en/stable/classes/class_jsonrpc.html
Можно через это взаимодействовать с сервером на другом языке.
Я тоже не против.
Спасибо, котятки.
В целом, работает, но требуются доработки.
Во-первых, параметры передаются не по стандарту.
Во-вторых, обработчик то один объект. Для простых команд этого хватит, но надо свою схему городить, если хочется вызывать функции других нод.
Кстати, кто то опять поднял справочник по API C#
http://www.polymo.de/gdsharp/api/Godot.html
Не идеально, проскакивают примеры на гдскрипте. Но лучше чем угадывать названия полей и методов
http://www.polymo.de/gdsharp/api/Godot.html
Не идеально, проскакивают примеры на гдскрипте. Но лучше чем угадывать названия полей и методов
Почитав исходники, понял, что 2-й пункт работает, просто неочевидным образом.
Можно подобавлять нужные объекты через
rpcHandler.set_scope("Player", player)
rpcHandler.set_scope("Enemies/Enemy1", player)
А потом вызывать их функции как пути
{ method = "Player/shoot" ... }
{ method = "Enemies/Enemy1/die" ... }
>Кстати, кто то опять поднял справочник по API C#
Ненужно, есть гдскрипт
Котаны, а вот вопрос, над которым я задумался только что. Как лучше с сигналами работать? Всё время цеплял их через гуя, а потом понял, что местами начал через .connect() писать, и теперь (пока) у меня смесь того и другого.
В чём разница? Или вопрос сугубо персонального удобства?
Мне кажется, проблема шарпа в годоте в том, что основная масса примеров, проблем и обсуждений ведётся на гдскрипте. Без всего этого шарпу не захватить массу.
Я шарпом когда-то пользовался, потом лет на 5 забил. Потом скачал годот и понял, что шар я так и не очень-то помню, а тут ещё и годот пытаешься освоить попутно, спотыкаясь то на одном, то на втором.
В чём разница? Или вопрос сугубо персонального удобства?
Мне кажется, проблема шарпа в годоте в том, что основная масса примеров, проблем и обсуждений ведётся на гдскрипте. Без всего этого шарпу не захватить массу.
Я шарпом когда-то пользовался, потом лет на 5 забил. Потом скачал годот и понял, что шар я так и не очень-то помню, а тут ещё и годот пытаешься освоить попутно, спотыкаясь то на одном, то на втором.
>масса примеров, проблем и обсуждений ведётся на гдскрипте. Без всего этого шарпу не захватить массу.
Именно так. Нужно выбрать один вариант, твёрдо и чётко. Так же в анриале большинство ответов на блюпринтах, просто нелепо. В юнити изредка натыкаюсь на ответы с яваскриптом, хотя он никогда не был популярен там.
>Мне кажется, проблема шарпа в годоте в том, что основная масса примеров, проблем и обсуждений ведётся на гдскрипте.
Так а проблемы-то нет. Тот же код можно построчно переписать на шарпе. (ну, циклы какие-нибудь по другой форме записать)
Единственная трудность в названиях полей. Потому что get_parent() может называться GetParent, а может просто проперти Parent. Но вот это как раз можно посмотреть на сайте что я скинул.
>В чём разница? Или вопрос сугубо персонального удобства?
В скрипте проще назначать динамически создаваевым объектам, или когда обработчики в другой сцене. Но из минусов - надо самому переименовывать, если перетащил/переименовал ноду где-то.
> Единственная трудность в названиях полей. Потому что get_parent() может называться GetParent, а может просто проперти Parent.
Ну на то в студии (и в коде, и в любом уважающем себя ИДЕ) есть синтаксические подсказки (интеллисенс и т.п. синонимы), ты набираешь gtpr а тебе уже вываливается в подсказках:
>GetParent
>GotPoopRequest
>GoatTeamProduce<T>
Встроенный редактор годота увы под шарп не заточен. В шарпе надо кодить из стороннего ИДЕ. Годот обещает всё-в-одном только при использовании гдскрипта, если ты берешь сторонний язык, то уже как бы внутренне готов к стороннему редактору кода.
> из минусов - надо самому переименовывать, если перетащил/переименовал ноду где-то
Решения тоже есть. Самое простое, описанное у Пети-сканера на ютубе, сделать один синглтон, пересилить себя и пойти против правил так сказать. В синглтоне завести пустые переменные, любая интересующая тебя нода, хоть она цельная сцена, хоть объект на внешней от неё сцене, неважно, каждая из них при своей загрузке прописывает себя в свою переменную. При выгрузке обнуляет переменную. Таким образом ты быстро, без зумерских заморочек, небезопасным, неконтролируемым дедовским способом нарушаешь кучу СОЛИДов энтих зумерских и из любой другой ноды видишь любую нужную тебе. Например, в синглтоне есть переменная Player, в которую очевидно прописывается перс игрока при загрузке. И стало быть, все Enemies без задней мысли чекают плеера, если он не нуль, то насколько он далеко? Прикинуться что не замечают его? Или атаковать?
При разработке в соло проблем не будет. При командной разработке такой клубок лапши быстро превратит проект в ад.
Я тебе опишу с чем чаще всего сталкиваюсь
Вот была у меня нода Scene/Spawn и у него какой-то сигнал
Я перетащил и теперь нода Scene/Town/House/Spawn
Если сигнал мышкой через интерфейс подключен, то он автоматически исправляется на ../../../script
Ага, понятно. А в шарпе как вообще сигналы работают? Это классические ивенты EventHandler<EventArgs> или какой то хитровыкрученный велосипед?
> Котаны, а вот вопрос, над которым я задумался только что. Как лучше с сигналами работать? Всё время цеплял их через гуя, а потом понял, что местами начал через .connect() писать, и теперь (пока) у меня смесь того и другого.
> В чём разница? Или вопрос сугубо персонального удобства?
Для меня персональное удобство вручную назначаемых в гдскрипте сигналов в том, что туда можно любые данные прибиндить, какие я захочу. Через интерфейс только встроенные классы (пикрелейтед). А кодом я могу в сигнал как минимум сендера прихуячить, и ссылку на словарь с данными, и любую произвольную ноду и, и, ооо, да, детка!
Там хотели переделать на шарповские events, но пока обертка над годотовскими
[Signal]
public delegate void MySignal(bool value, int other_value);
EmitSignal(nameof(MySignal), true, 42);
GetNode("Timer").Connect("timeout", this, nameof(_on_Timer_timeout));
Хотя пишут, что подписываться уже можно по шарповскому
MySignal += MySignalHandlerFunc;
А как найти такой делегат у Timer, к примеру, я пока не понял.
Ну, хз, вроде не очень уж и страшно выглядит. Зато наверняка через [Signal] этот делегат регистрируется внутри редактора и его можно мышкой прибиндить к другим нодам.
> А как найти такой делегат у Timer, к примеру, я пока не понял.
Через интеллисенс студии.
> MySignal += MySignalHandlerFunc;
Неее... Я освоил анонимные методы через лямбду и хуячу их везде, где надо и не надо:
> MySignal += (args) => { //Здесь набираю сам код, если много кода, разношу на несколько строк, и только если кода становится больше экрана - выношу в отдельный метод. };
>Через интеллисенс студии.
Нету его там. И вообще в исходниках .cs нету. Думаю, он из гдскрипта прилетает. Ведь объекты в C# могут общаться с остальными.
Так, нипонил. Рассказывай сначала. Чего нету? А я пока моногодот скачаю. Сто лет не годошарпил.
Если ты свой сигнал создаешь, ты можешь написать [Signal] delegate... и к нему цепляться. А у встроеных они не объявлены в C#. Через Connect подключиться можно, но это идет через ядро движка, так же как в гдскрипте.
Я понел. Смотри какую я хрень накопал. Там вместо этого навелосипежен некий SignalAwaiter, принимающий инстанс ноды и текстовое описание сигнала этой ноды. Если я правильно понял, затем надо следить за состояниями этого эвэйтера. ХЗ, чот неудобно.
Сигналы биндятся через редактор годота (вкладка узел/сигналы), но до сих пор игнорируют скобачьки - обработчик дописывается в хвост файла и его надо принудительно переместить вверх, внутрь скобачекь объекта. Тогда заработает.
2 секунды сэвед, зато 10 секунд вастед на массив-массивыч.
В продолжение эпопеи с сохранениями. Есть пикрил.
Директория выводится не та, что я хочу заюзать, в if я не проваливаюсь. Есть похожий баг, но что-то круто для бага такого рода. Это он, или всё же пользовательские директории можно зхаставить работать?
https://github.com/godotengine/godot/issues/35346
Директория выводится не та, что я хочу заюзать, в if я не проваливаюсь. Есть похожий баг, но что-то круто для бага такого рода. Это он, или всё же пользовательские директории можно зхаставить работать?
https://github.com/godotengine/godot/issues/35346
А, всё, отбой. Через dir.open() обошёл проблему.
Как правильно настроить Margin чтобы контролы стояли в три столбца: 10%, 30%, 60% помогите, я нихуя не понимаю и не получается. При ресайзе всё разъезжается в стороны!
Спасибо! Всё получилось!
Анончики, в отчётах гугл плэя иногда проскакивает ANR для игрушки на годоте. С чем это может быть связано?
Долгие рассчеты вроде ИИ или загрузки уровней вынести в отдельный Thread?
Какой нафик ии, там рассчёты не сложнее калькулятора. Такое не массово происходит, а редко случается - может одно на сотню устройств. Какие-то допотопные кирпичи с 4-м и 5-м андроидом судя по аналитике нормально работают. Из последних anr - galaxy a10 с 10-м или 11-м андроидом, не помню.
Мзизиз пилит халфу своей мечты
https://www.youtube.com/watch?v=iGah8RemjE0
https://www.youtube.com/watch?v=iGah8RemjE0
Гуру, подскажите, а есть ли какой-то встроенный построитель диаграмм? У меня всего десяток сцен и два десятка скриптов, а я уже начинаю путаться что откуда вызывается, если от проекта отвлекусь на несколько дней. Просто чтобы иметь под рукой всегда накиданную шпаргалку связей (не автоматических, а хотя бы руками связанных), а не листать тетрадь с записями каждый раз.
>диаграмм
Точнее схем, наверно. Но смысл не меняется.
Могу предложить посмотреть это
https://godotengine.org/asset-library/asset/879
А для более глубокой разработки вот это
https://godotengine.org/asset-library/asset/817
Охуенно! Это в шапку однозначно.
Пока не видел оф новости, но в папке лежит новая версия
https://downloads.tuxfamily.org/godotengine/3.4/beta5/
https://downloads.tuxfamily.org/godotengine/3.4/beta5/mono/
Или у них там найтли билд?
https://downloads.tuxfamily.org/godotengine/3.4/beta5/
https://downloads.tuxfamily.org/godotengine/3.4/beta5/mono/
Или у них там найтли билд?
А смысл дёргаться в минорных версиях? Только если тебе нужен специфический добавленный функционал или фикс проблемы.
А не знаю. Что-то лечат, что-то калечат. Вроде move_and_slide улучшали.
Сорока-белобока!
Оу! Сорян. Евангелисты нам нужны. Ну, расписывай тогда все воцньюсы по пунктам.
Ситуация. Есть Control вот такой ширины (изначально на весь экран). В чём суть проблемы. Вот эта область в оранжевом прямоугольнике, оказывается, непрозрачна для мыши, не смотря на то, что там элементов нет. Как заставить её быть прозрачной для событий с мыши, например, чтобы увеличить эффективную площадь взаимодействия с игровыми объектами? В хайд отправлять всё меню не плинирую, дробить на пачку Control тоже не хотелось бы.
Как обычно, до решения допёр сам. Пробовал пасс, игнор не пробовал. А именно он и делает то, что хочу. Однако вопрос, почему работает только вариант игнор?
Возможно там неудачное название, но pass делает обычный event bubbling, в терминах web DOM.
stop - дает обработать событие и на этом останавливает его продвижение вглубь
pass - дает обработать событие и передает его глубже по поддереву контролов, чтобы они тоже могли обработать.
ignore - отключает обработку событий этим деревом контролов.
Спасибо. Очень доходчиво. Нашёл описание этого уже в доках, но там, кстати, менее ясно смысл описан.
Можете подсказать туториалов для максимально тупых? Давно хочу что-то склепать для души, и пытался освоить годо, но соснул хуйца дважды. Прошел официальный туториал в котором нужно уворачиваться от летающих головастиков и вроде все понятно. Но как садишься за что-то своё и ощущаешь полную беспомощность.
Могу посоветовать только нарабатывать базу.
Пройди какой-нибудь курс по программированию. На питоне или C#.
Попробуй воспроизвести туториал по памяти, вообще не заглядывая в подсказки.
После туториала, добавляй в эту игру какую-нибудь новую фичу, главное не растекайся а делай по одной за раз.
Изучи какие средства есть в годоте, банально смотри какие есть ноды, какие у них методы, была какая-то серия видосов know your nodes
Смотри на другие игры, попробуй анализировать, как бы ты их сделал, из каких элементов они состоят. Какой-нибудь рогалик, платформер и т.д.
Пройди больше туториалов (1 это вообще ни о чем - хотя бы с десяток)
В конце концов, расскажи, что ты хочешь делать свое и какие у тебя трудности возникают, что непонятно как сделать.
> как садишься за что-то своё и ощущаешь полную беспомощность
Очень вредное ощущение новичка. В любой сфере, не только в кодинге/геймдевелопинге. Оно может отвернуть от дальнейшего изучения и продвижения. Какой тут может быть совет? Удваиваю предыдущего анона, нарабатывай базу. Пили на движке простые вещи, которые просто работают. Одновременно читай матчасть. Не по годоту матчасть, а по компам вообще. Ты должен осознать, как всё работает. Осознать, почему, например, Хуан в Годоте сделал так, а не иначе. И тогда, постепенно, шаг за шагом, будет приходить понимание:
> Я могу сделать это.
> Я могу сделать вот так.
Для мотивации вот тебе видос, как я начинал 3 года назад. Скрипт из одной строки Rotate() остальное - работа с материалами и текстурами.
> как я начинал 3 года назад
Потом прошло 3 месяца и я начал лепить первые поделия. Нихуя не понимал, но всюду лез. В данной технодемке с включённым отображением коллизий показано, как я лепил инстансы объектов без полного понимания наследования.
Прошёл год и я ощутил себя в силах поучаствовать в своём первом ТВГ. О, как же я ошибался. Я запилил катающегося Йобу-Супер-Йобика и был осмеян за это.
В ужасе от масштабной травли, я забил на двадэ и вернулся к триде, вспомнил свои старые мечты и задумки. Начал воплощать. Но охуел от масштаба работ, которые нужно провернуть в тридэ для запила сколь нибудь толковой игори.
Месяц спустя я перешел на мини-игры, размяться решил с признанной классики.
Прошло ещё три месяца метаний из двадэ в тридэ, и тогда мне анон подсказал, что зачем, мол ты пытаешься велосипедить, когда всё уже есть в интернетах: генераторы людей, наборы анимаций. Я подумал, и действительно. И провёл рисёрч.
Спасибо за ответы. Но на самом деле я программист. Просто стек совсем отличный от геймдева. У меня проблема не с языком, хоть гдскрипт и отличен от того на чем я обычно калякаю. Проблема в самом подходе что ли. Ладно, пойду в третий раз сяду делать летабщих головастиков.
>Осознать, почему, например, Хуан в Годоте сделал так, а не иначе.
Задроты движкодрочеры. Нафика простому Васяну знать, что там под капотом.
кулстори бро, продолжай в том же духе.
Стек можно свести к такому: есть неподвижные части уровня, и есть "фишки" которые двигаются каждый кадр. Ну а когда они сталкиваются, создаются события которые отправляются-получаются, и они могут запускать анимации, спавнить/уничтожать другие фишки. Конечно, есть элементы сложнее, типа генерации уровней. Но в целом, каждый объект отвечает за свое поведение и реакции на окружающие события, просто работает process каждый кадр. Пуля просто продолжает лететь в нужную сторону, персонаж просто летит по параболе прыжка. А навешанные Area и Body ловят столкновения и вызывают обработчики триггеров.
print(_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 градусов, блять.
Это почти прямая линия вдоль оси, а сколько по-твоему должно быть?
> Как блять
> Какие нахуй
Ну що, дядя, убедился в том, что матеша в школе джвадцать лет назад была таки нужна?
Т.е. твое утверждение, что оси x и y перепутаны и из-за этого угл неверен?
Естественно это нихуя не помогло
(190, 1.4)(0, 0)0.422172
(190, 1.4)(1100, 3.5)-179.867773
(190, 1.4)(500, 3.8)-179.556425
Мы видим явно рост точки вверх, а углы теперь отрицательные. Пиздец.
Мне не нужна математика, епта. Мне нужен угол, блять! А годот его посчитать не может.
Тебе, как раз нужна математика. За 5 класс.
Между точками угла не бывает. Угол бывает между векторами
Очевидно ты сравниваешь два вектора (0,0)(190, 1,4) и (0,0)(1100,3.5) и получаешь угол близкий к 0, 90 или 180.
Тебе надо сравнивать что-то типа (0,0)((1100,3.5)-(190, 1.4)) и (0,0)(10000,0)
Это и есть angle_to_point функция. И она не работает
> Пиздец.
А пиздец в том, что человек, прогулявший матешу в свои 16цать, срёт на дваче, вместо того, чтобы курить матчасть до просветления.
https://docs.godotengine.org/ru/latest/tutorials/math/vector_math.html#introduction
Какой код я должен написать, чтобы все работало?
Пятихатку мне на киви - а я в ответ готовый код.
Либо добавь 360 градусов, либо поменяй точки местами.
Пользуйся angle_to, раз не разобрался с angle_to_point.
Это все не поможет. Почему в треде годота сидят на столько тупые?
Чего только не узнаешь в ходе подготовки к джему.
https://www.youtube.com/watch?v=-hbZSH1t6VE
https://www.youtube.com/watch?v=-hbZSH1t6VE
Я как-то ебался с этим сортингом, ещё на 3.0.6., там столько подводных камней, что я плюнул и решил либо делать плоское двадэ без имитации тридэ, либо настоящее тридэ делать.
Ее тогда еще только добавляли, может сейчас нормально, завтра попробую.
Ну чё? Ну как? Я ж переживаю...
Гуру, помогите разобраться с плавным передвежением камеры по сцене.
Есть два стула. Свободно двигать камеру по нажатию и двигать камеру по нажатию, цепляясь за ландшафт.
Стул первый.
Вроде всё просто. В абсолютном значении mouseMoveX(Y)Ratio - величина от 0 до 1, которая регулирует скорость от 0 до максимальной moveSpeed.
Знак mouseMoveX(Y)Ratio зависит от того, как изменяется положение мыши относительно момента, когда нажал сренюю кнопку.
Косяки начинаются, когда я верчу камеру. Чем ближе поворот камеры к 90 или -90 градусов, тем сильнее меняются верх-низ местами с право-лево. Должно быть тут надо как-то трансформ заварить, но у меня не получается.
Второй стул.
Есть идея цепляться за точку на поверхности, но тут вопрос, как плавно двигать камеру от текущей точки к точке зацепления.
Но этот вариант я даже не начинал. Как считать изменение позиции камеры относительно точки зацепления? Прямоугольными треугольниками?
Есть два стула. Свободно двигать камеру по нажатию и двигать камеру по нажатию, цепляясь за ландшафт.
Стул первый.
Вроде всё просто. В абсолютном значении mouseMoveX(Y)Ratio - величина от 0 до 1, которая регулирует скорость от 0 до максимальной moveSpeed.
Знак mouseMoveX(Y)Ratio зависит от того, как изменяется положение мыши относительно момента, когда нажал сренюю кнопку.
Косяки начинаются, когда я верчу камеру. Чем ближе поворот камеры к 90 или -90 градусов, тем сильнее меняются верх-низ местами с право-лево. Должно быть тут надо как-то трансформ заварить, но у меня не получается.
Второй стул.
Есть идея цепляться за точку на поверхности, но тут вопрос, как плавно двигать камеру от текущей точки к точке зацепления.
Но этот вариант я даже не начинал. Как считать изменение позиции камеры относительно точки зацепления? Прямоугольными треугольниками?
Вообще на это есть готовые решения, сейчас несколько занят чтобы детально расписывать, например есть https://docs.godotengine.org/en/stable/classes/class_interpolatedcamera.html
Также можно посмотреть как в принципе считают интерполяцию
https://kidscancode.org/godot_recipes/3d/interpolated_camera/
Да и остальные рецепты с сайта посмотри
Посмотри как делают тут, плавный поворот через slerp
https://www.youtube.com/watch?v=XvFlM1uf2MM
https://godotengine.org/asset-library/asset/723
Наверное можно еще Tween навернуть ради easing
Логическое продолжение лайфхака
crouch_pos += delta * [-CROUCH_SPEED, +CROUCH_SPEED][int(Input.is_action_pressed("move_crouch"))]
Вот тебе ещё лайфхак, замени
> int(Input.is_action_pressed("move_crouch"))
на
> Input.get_action_strength("move_crouch")
избавишься от лишнего преобразования буль-инт.
Как сделать, чтобы воспроизводилась анимация прыжка?
Суть проблемы в том, что когда персонаж прыгает, то не производится вся анимация, а лишь первый спрайт, как сделать чтобы воспроизводились все 4 спрайта? С анимацией ходьбы таких проблем нет.
Суть проблемы в том, что когда персонаж прыгает, то не производится вся анимация, а лишь первый спрайт, как сделать чтобы воспроизводились все 4 спрайта? С анимацией ходьбы таких проблем нет.
Тебе надо делать play("Jump") там, где ты подпрыгиваешь на jumpForce
А так ты каждый кадр, _когда не на полу_, начинаешь воспроизводить с первого кадра.
А что будет если там ось джойстика? Автопреобразование float в int?
Если ты имеешь введу пикрил, то я так делал и ничего не поменялось.
Тогда, наверное, у тебя play("Idle") перекрывает ее.
Можешь проверять, не играется ли анимация прыжка
if not (spr.is_playing() and spr.animation == "Jump"): play("Idle")
проходим товарищи бейкаем нестессняемся
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
Так релиз курса весной 2022 а что всё это время делать? Не проще начать учить язык просто по урокам на ютубе, я вот только вкатываюсь и так планирую сделать, поседений месяц метался между годо и ГМ2, но вот все таки годо выбрал, хотя уже проебал две недели на гм2 после работки, сделал по урокам понг.
> проще начать учить язык просто по урокам на ютубе
просто проект пилится для калифорнийских бойчиков, которым будучи угашенным травой очень сложно начать напрягаться и учить, а тут няшная обучалка в игровой форме
от гугла (кажется) пазлы с кодом были подобные, к ним тоже игровую логику какого то известного тайтла прикручивали
а так все правильно сделал котей
> C++ там не будет.
па ху ю
Плагин для реализации диалоговой системы.
Напоминаю. Пилить свой велосипед больше не нужно.
https://www.youtube.com/watch?v=xOqbZBL0V7A
Напоминаю. Пилить свой велосипед больше не нужно.
https://www.youtube.com/watch?v=xOqbZBL0V7A
>избавишься от лишнего преобразования буль-инт.
А если ему именно int нужен, а не float? У него вроде 2D.
>А что будет если там ось джойстика?
Будет всё то же самое, что и с обычными кнопками.
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.
А это неважно.
>>А что будет если там ось джойстика?
>Будет всё то же самое, что и с обычными кнопками.
Ты не вкурил. Ось джойстика это именно ось с плавными значениями.
>указание типа функции
типов аргументов функции
>Он на дельту умножает
Я думал, это отдельное выражение, там знака между ними нет.
>А это неважно.
В смысле? Если делать pixel perfect 2D, то все координаты должны быть целыми...
>как в вормсах
В вормсах другой террейн. В вормсах сравнение попиксельное или с использованием сжатия RLE:
https://gamedev.stackexchange.com/questions/158906/destructible-terrain-like-worms
Террейн на полигонах, конечно, заманчивый, но у него куча подводных камней.
Думаю сейчас все делают на полигонах, а потом шейдером в пиксель перфект.
>Ось джойстика это именно ось с плавными значениями.
Ну и?
Допустим, у нас такое выражение:
>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 и вообще в депрессии был. Просто мой китайский геймпад имеет хреновые стики, и мне хотелось почувствовать, каково это - управлять с хорошего джойстика.
Ты вообще не вкурил про что шла речь. Причем тут translation.x?
Всё он вкурил. Это ты не выкупаешь.
Поэтому игра должна детектить устройство ввода, и своевременно переключать модель движения согласно действующему устройству ввода. Для геймпада - вышеописанный вариант. Для клавиатуры - интерполяция к максимальной/минимальной скорости, создающая видимость плавного разбега/остановки.
И да, в настройках следует добавить опцию "спидран мод" которая лочит модель движения геймпада на клавиатуру. Иначе спидранеры сделают это самостоятельно сторонними тулзами. Зачем расстраивать посанов? Пусть себе спидранят на официальных настройках от девелопера.
>Всё он вкурил. Это ты не выкупаешь.
Ты тоже не вкурил.
>Для клавиатуры - интерполяция к максимальной/минимальной скорости
В чём проблема включить интерполяцию для всех способов ввода, включая джойстики? Дешёвые китайские джойстики нуждаются в интерполяции ничуть не меньше, чем клавиши. Да и на дорогих наверняка хотелось бы плавности, у пальцев-то неточные движения.
Я написал вариант без интерполяции только потому что его проще было написать по памяти.
Вообще не понял про спидранеров, почему спидранерам нужна интерполяция? Интерполяция же замедляет разгон и торможение, то есть без неё можно сэкономить время прохождения.
Два дня мучился с одним вопросом, наконец решил сформулировать его в этом треде, и пока печатал, нашёл ответ на него. Всем спасибо, очень помогли, вопрос постить не буду, там многобукав.
inb4 https://en.wikipedia.org/wiki/Rubber_duck_debugging
inb4 https://en.wikipedia.org/wiki/Rubber_duck_debugging
>ЯКАЛЕНДАРЬ EDITION
Что это значит? iCalendar? Как с Годо связано?
Алсо, не одобряю просёр нумерации. Этот тред вроде 24, да? Почини нумерацию в следующем (25?) треде, а то неудобно получается.
>Теперь прямо онлайн - можно и с дивана: >https://godotengine.org/online/godot.tools.html
>The requested page cannot be found
Эта фича ещё в конце 2020 или самом начале 2021 (судя по веб архиву) сдохла, теперь даже упоминания на сайте нет - ты давно ссылки из шапки проверял?
Кстати, почему они от онлайн версии отказались? Слишком сложно поддерживать, наверное? Я год назад вроде пробовал запустить, чёт ничего не вышло. Что там было?
Фича не сдохла, наоборот, постоянно допиливается
https://editor.godotengine.org/releases/3.4.rc1/godot.tools.html
Ты дурак, я МегаФон?
Чиво? Это какой-то мем?
Ясно, понятно, но ссылку давно пора обновить, она с начала года не работает, если верить веб архиву. За ~3 переката можно было много раз перепроверить.
Алсо, если тут
>можно и с дивана
подразумевается мобильный браузер, то
>Mobile browsers are currently not supported.
Поясните за визуалскриптинг в вашем говне, кто-нибудь пользовался? Для каких задач подходит, если вообще подходит или это ради рофла сделано?
п.с. извините за говно
п.с. извините за говно
>визуалскриптинг
Не пользовался. Я программист-любитель со средней школы и GDScript оказался очень простым и удобным, в отличие от C#. Встроенный редактор с подсветкой и автодополнением, а что ещё можно желать для кодинга?
Визуальные скрипты (вообще любые, не конкретно в Godot) могут быть удобны для маленьких детей, которые ещё не умеют печатать на клавиатуре, а для взрослых текст должен быть удобнее.
Есть какой-то аддон для визуальной разработки конечных автоматов, вот он теоретически может быть полезен, но я не пользовался.
Пиши документацию, тогда код не придётся мышкой таскать.
Автор неплохо Human Diaspor-у развил
https://www.youtube.com/watch?v=AyUNjc3IK9I
https://www.youtube.com/watch?v=AyUNjc3IK9I
Не могу понять, в чём проблема.
Есть ригидбоди. У него есть несколько колиженшейпов. Игрок добавляет новые колиженшейпы. Чтобы ригидбоди работал как мне нужно, его начало координат (0;0;0) должно совпадать с центром масс. Я вычисляю "центр масс" как среднее арифметическое позиций всех колиженшейпов. Затем смещаю все колиженшейпы на этот вектор, а сам ригидбоди - на обратный вектор. Происходит это всё однократно и только в _physics_process(), а для надёжности ригидбоди усыпляется на время смещения и пробуждается сразу после него.
Что я ожидаю? Что визуально ригидбоди останется на том же месте, где и был, но его масса станет более равномерной.
Что получается? Две ситуации:
1) Ригидбоди лежит в сцене изначально. Всё вышеописанное работает как и ожидается. Даже если его физически сдвинуть, повернуть или отбросить, всё будет работать как и ожидается (вроде бы).
2) Ригидбоди уничтожается, затем создаётся (instance()) заново, наполняется теми же колиженшейпами, что и были, падает и останавливается. Если теперь попытаться добавить ему ещё один колиженшейп, он начнёт сдвигаться в определённом направлении, хотя должен оставаться неподвижен. При этом смещаться может прямо внутрь препятствий, в которые при обычных условиях попасть не может - то есть это из-за моего смещения кодом, а не из-за ошибок физического движка (надеюсь).
Как такое может происходить? Я проверял через дебаггер сцену и трансформы, внутренние переменные этих ригидбоди. Всё выглядит нормально. Пробовал print() вектора, на который происходит смещение, но эти числа мне ни о чём не говорят - я не знаю, какими они должны быть, это сложно посчитать вручную.
В общем, куда копать, что делать? Проблема довольно раздражающая из-за своей непостоянности, то есть, то нет.
Есть ригидбоди. У него есть несколько колиженшейпов. Игрок добавляет новые колиженшейпы. Чтобы ригидбоди работал как мне нужно, его начало координат (0;0;0) должно совпадать с центром масс. Я вычисляю "центр масс" как среднее арифметическое позиций всех колиженшейпов. Затем смещаю все колиженшейпы на этот вектор, а сам ригидбоди - на обратный вектор. Происходит это всё однократно и только в _physics_process(), а для надёжности ригидбоди усыпляется на время смещения и пробуждается сразу после него.
Что я ожидаю? Что визуально ригидбоди останется на том же месте, где и был, но его масса станет более равномерной.
Что получается? Две ситуации:
1) Ригидбоди лежит в сцене изначально. Всё вышеописанное работает как и ожидается. Даже если его физически сдвинуть, повернуть или отбросить, всё будет работать как и ожидается (вроде бы).
2) Ригидбоди уничтожается, затем создаётся (instance()) заново, наполняется теми же колиженшейпами, что и были, падает и останавливается. Если теперь попытаться добавить ему ещё один колиженшейп, он начнёт сдвигаться в определённом направлении, хотя должен оставаться неподвижен. При этом смещаться может прямо внутрь препятствий, в которые при обычных условиях попасть не может - то есть это из-за моего смещения кодом, а не из-за ошибок физического движка (надеюсь).
Как такое может происходить? Я проверял через дебаггер сцену и трансформы, внутренние переменные этих ригидбоди. Всё выглядит нормально. Пробовал print() вектора, на который происходит смещение, но эти числа мне ни о чём не говорят - я не знаю, какими они должны быть, это сложно посчитать вручную.
В общем, куда копать, что делать? Проблема довольно раздражающая из-за своей непостоянности, то есть, то нет.
1. Убедись что делаешь физические штуки в _physics_process, а не _process
2. Попробуй перед манипуляциями переводить в режим Kinematic или Static
3. Может быть где-то надо подождать 1 физический кадр между манипуляциями: yield(get_tree(), "physics_frame")
4. Если у тебя объект ползет внутри пола, хз. То есть теоретически у тебя такая ситуация, что ты к объекту приделал ногу и эта нога теперь внутри пола, и что по-твоему должен делать движок? Тебе надо игровой логикой поднять объект на высоту ноги.
5. Саму скорость можно как-то менять, то ли через linear_velocity, то ли через _integral_forces, я этим никогда не занимался.
Только что наконец-то исправил проблему! Причина обнаружилась в неочевидной разнице между translate() и прямым изменением transform.origin. Судя по всему, RigidBody каким-то особым образом работает со своим орижином, поэтому трогать его нельзя, но можно двигать через translate(). Т.е. заменил
>transform.origin += delta
на
>translate(delta)
И все "заикания" волшебным образом исчезли. Странно, ведь у остальных объектов можно менять орижин без таких последствий... Интересно, это моё личное непонимание ситуации и "так и задумано" или это всё-таки баг движка?
1. Всё так и есть, разумеется. Я ставлю флаг "откалибровать центр масс", а в _physics_process вызываю функцию калибровки, снимая флаг. Сделал так в т.ч. потому, что за один кадр может добавиться очень много новых блоков, и каждый ставит флаг, но калибровка происходит только раз за физический тик, если нужна.
2. Я думал об этом. Не пробовал, но мне кажется, что установка в статичный режим сбросит все скорости, т.о. ригидбоди застынет в пространстве и затем снова начнёт ускоряться. Я ведь не зря именно с ригидбоди работаю, мне нужно чтобы он свободно двигался.
3. У меня всего одна манипуляция за физический тик)
4. На самом деле ситуация с "ногой внутри пола" обрабатывается движком вполне ожидаемо: объект начинает трястись и медленно выдавливаться из пола, либо застревает в нём и трясётся. Это нормально и ожидаемо; избежать легко, если проверять коллизии добавляемого объекта и запрещать добавление, если он пересекает пол, стены и другие объекты. Но проблема была в том, что когда я крепил что-нибудь сбоку, объект мог сдвигаться в противоположную сторону, застревая в стене. Чуть с ума не сошёл, пытаясь найти причину.
5. Знаю, когда-то я баловался с этими силами и скоростями. Но это не то, смещение должно быть мгновенным и никак не влиять на происходящее движение (в идеале, конечно).
>для надёжности ригидбоди усыпляется на время смещения
Кстати, оказалось, что усыплять ригидбоди вообще не нужно - можно спокойно крепить новые детали на движущийся ригидбоди и он не будет менять свою траекторию (вроде бы). А вот пробуждать после крепления нужно, потому что новые детали смещают центр масс, смещённый центр масс в теории может спровоцировать движение (наклонить, опрокинуть), но этого не происходит, если ригидбоди в режиме сна.
Ещё добавлю увеличение массы и вообще круто будет, а то сейчас большая конструкция из блоков слишком сильно реагирует на столкновение со всего одним блоком... выглядит так, будто добавление блоков уменьшает их массу. А блоки с разной массой будут смещать центр масс сильнее/слабее, вот это самая интересная часть - какой-нибудь парус сильно легче металлического двигателя, несмотря на больший размер.
Хорошо, что разобрался, честно говоря не знаю в чем между ними разница.
Хотел тебе ответить и полез в документацию по апи движка, и нашёл ответ на мучавший меня вопрос:
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() позволяет изменить актуальное смещение ригидбоди, а не то, что есть в орижине.
> Transform changes in physics are not instant for performance reasons. Transforms are accumulated and then set.
Честно говоря не вижу принципиальной разницы. translate() тоже просто читает-записывает origin и никаких специальных путей кода с отложенной записью в нем нет.
> принимает во внимание масштаб объекта
А не менял ли ты масштаб самого rigidbody? Не могу найти в документации, но много где читал, что ridibody нельзя менять 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 - добавил в сцену.
> менять масштаб ригидбоди нельзя
Почему именно?
Потому что физика это обертка над буллетом, а в буллете все работает в масштабе 1:1. В 4-м годоте будет опция чтобы масштаб ригидбоди автоматически пересчитывал все масштабы коллижншейпов, но это, надо понимать, требует дополнительных вычислений.
Прекрасно! Давай зачётку.
Собака съела.
Тут какой-то курс математики для геймдевов показывают
https://www.reddit.com/r/godot/comments/q8zevk/i_completed_assignments_46_from_freya_holm%C3%A9rs/
https://github.com/charliedavenport/Godot_Math_Exercises
Кто-нибудь может подсказать, нужно ли работать для камеры с углами эйлера или нужно преобразовать в кватернионы?
Я в годоте работал с матрицей преобразования, так же известной в дереве классов годота как Transform. Не знаю, Эйлер ли это или кватернион? Но если тебе надо без задней мысли работать с камерой, просто построй из невидимых нод киношную вышку, или как она там правильно называется? Ну тоесть, воссоздай рабочее место оператора ИРЛ. Тебе понадобится в общем случае два шарнира класса Spatial, один ты будешь вращать вокруг вертикальной оси влево-вправо, второй вокруг поперечной оси вверх-вниз. В 90% туториалов предлагается делать так. В остальных 10% в зависимости от требований игоры может потребоваться покачивание вокруг продольной оси, а так же удаление и приближение по ней же.
А так же в новые версии движка завезли автоотдаляющуюся камеру.
Ребята я что календарь?
Двачую этого анона.
Хотя я подумываю о флайтсиме, там, наверное, кваты нужны.
Да я нашел у них в пособии, что лучше юзать кватернионы. Я просто понял, что если тупо юзать матрицу преобразований, то там траблы выходят, что при движении одной оси двигаются другие и как бы угол уже не тот выходит, когда вращаем некс ось. Плюс там при определенных положениях может возникнуть ситуация, что степень свободы можем потерять, т.е вращаться только по одной оси.
Вообще Transform, там комбинация Basis и origin. Ну в Basis походу перемножение scale и rotation. А вот orgion будто бы просто добавлена строка и все. Rotation задается виде матрицы с векторами 3х3. Т.е по идеи если я домножу эту матрицу вращения, то получу углы эйлера.
>подумываю о флайтсиме
Так там ведь просто RigidBody.add_force() юзать и всё, зачем тебе что-то вручную поворачивать?
Суть в том, что нужно соблюдать порядок вращения. Сначала по одной оси, потом по другой, если наоборот - выйдет не то, что ты ожидал. Да и за направлением вращения следить надо. В мануале пишут, что от обоих этих проблем можно избавиться, юзая кватернионы, но для большинства простых игр хватит повесить камеру на одну/две вложенные ноды или SpringArm.
https://docs.godotengine.org/en/stable/classes/class_springarm.html
>зачем тебе что-то вручную поворачивать?
Обзор камеры
А лол, прикольный костыль, но я бы чисто матан хотел поизучать.
>Обзор камеры
Тебя интересует, как сохранять вертикальную ориентацию камеры, когда самолёт наклоняется? Тоже планирую делать что-то вроде авиасимулятора на минималках.
>костыль
SpringArm - это не костыль, это встроенное решение, позволяющее не городить самодельный рейкаст и код для приближения камеры. Во всех играх от третьего лица камера должна приближаться к персонажу, когда сталкивается с препятствиями или когда препятствия встают между камерой и персонажем, иначе игроку будет неудобно и он может увидеть скрытые объекты сквозь стены. Так что радоваться надо, что такой "костыль" есть в Годо из коробки.
Примерно год назад пилил-пилил свой велосипед, потом узнал про SpringArm и половину кода выкинул, лол.
Посоветуйте что ли по чарактерконтроллеру. У меня есть на основе кинематикбоди, сам сделал кое-как. На статичном ландшафте работает более-менее приемлемо, но у меня в игре подвижные конструкции на основе ригидбоди, движутся с помощью add_force(). В общем, персонаж вроде как немного мешает движению ригидбоди, когда ригидбоди поднимается вверх (но не сильно), но хуже всего то, что персонаж немного остаёт от ригидбоди при движении вниз. Алсо давно заметил, что мой персонаж падает быстрее любых ригидбоди... Это всё можно как-то пофиксить, оставаясь на кинематикбоди, или нужно обязательно переписывать чарактерконтроллер на ригидбоди? Я просто уже несколько раз туда-сюда перекатывался за последние пару лет, я уже не знаю что делать, и там и там косяки вылезают (помню, ригидбоди персонаж расшвыривал другие ригидбоди как будто они ничего не весят, да ещё и проблемы были с определением пола, короче ну нафиг).
Алсо хочется в будущем сделать регдолл, посоветуйте, нужно ли к этому как-то специально готовиться? В плане адаптации чарактерконтроллера под это дело. Кинематикбоди не помешает же?
Как чекнуть, что игра уже запущена? Делаю типа сетевой, а если запустить дохуя одинаковых экзешников на одной машине, то можно нихуёво ботоводить, нужно пофиксить.
Просто чекай айпишки, че за пляски?
Можно сделать так - при запуске запрашиваешь определенный порт, и если пришел ответ, то игра уже запущена, если нет, то запускаешь сервер на этом порту, который ждет запрос.
Можно посмотреть просто средствами винды (чет то там про ProcessName)
Но надо понимать что это все довольно легко обходится. Надежного способа нет.
Алсо подумай насчет геймдизайна, чтобы простое ботоводство не давало тупо плюшек (нельзя было набирать бесконечные очки избивая неподвижного противника и т.д.)
>чекай айпишки
Кеклол, в современном мире под одним внешним v4 айпи могут сидеть сотни пользователей, а у v6 покрытие мизерное, по сути он практически не используется ещё. Теоретически можно чекать внутренние айпи, но откуда тебе знать, что там конкретный провайдер Сычов Тырнет накрутил в своей сети?
>Делаю типа сетевой, а если запустить дохуя одинаковых экзешников на одной машине, то можно нихуёво ботоводить, нужно пофиксить.
Забей, во всех ММО ботоводят, в некоторых это даже поощряется вроде как. Лучшее, что можно сделать - стимулировать игрока играть только одним персонажем, не давать преимуществ игроку с несколькими персонажами. К примеру, запретить свободную передачу предметов между персонажами, а за игру соло давать существенный бонус опыта, чтобы не было желания водить хороводы.
>запускаешь сервер на этом порту, который ждет запрос
Можно сделать проще: игра создаёт файл, открывает его на чтение/запись и держит открытым. Если её копия попытается получить доступ к тому же файлу, то получит ошибку доступа и должна закрыться. Если пользователь найдёт этот файл и попытается удалить или переименовать, то получит ошибку доступа. Если пользователь обойдёт блокировку файла, то оригинальная игра должна заметить пропажу файла и принять соответствующие меры (специальный флаг на аккаунт или бан). Но это не решает проблемы куллхацкера, который изменяет имя файла в данных игры (зная имя файла сделать это несложно, если exe не проверяется хэш-суммой). Также это не решает проблемы эмуляторов ОС... Вариант с сервером вроде бы тоже не защищает от эмулятора ОС, т.к. все сервера будут на независимых виртуальных машинах. Т.е. кто ищет способ запустить бота, обязательно его найдёт.
>Можно посмотреть просто средствами винды (чет то там про ProcessName)
https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-findwindowa
>Можно сделать проще
Вот да, думаю в том же направлении.
Просто держать на пеке файл, который будет говорить каждому новому экзешнику, что игра-то уже запущена. + добавлю мб проверку на сервере, должно хватить.
Хотя я пилю игру под Steam, думал у них встроенный запрет на множественный запуск одной игры, но проверил и оказалось, что не так.
> игра создаёт файл, открывает его на чтение/запись и держит открытым
> держать на пеке файл, который будет говорить
Вы двое только что изобрели мьютексы. Чтобы вы не изобретали семафоры, я пишу этот пост, с гуглящимися словами.
При чём тут мьютексы и семафоры? Они же регулируют потоки внутри приложения, а не сторонние приложения? Задача анона стоит как "не допустить запуск второго экземпляра приложения". Решение с файлом подразумевает использование особенности ОС, которая не позволяет двум приложениям одновременно работать с одним и тем же файлом в файловой системе.
Приложение 1 открывает файл "файл" на запись.
ОС блокирует доступ к "файл" для остальных приложений.
Приложение 2 пытается открыть "файл" на запись.
ОС сообщает код ошибки: "доступ запрещён".
Приложение 2 получает код и завершает свою работу.
Приложение 1 завершает работу, закрывает файл.
ОС разблокирует доступ к "файл" для приложений.
Приложение 1 или 2 можно снова запустить.
Итого мы можем иметь только 1 или 2, но не оба сразу. Но это не решает проблемы виртуальной машины, у которой отдельная файловая система и которая не знает о существовании соседних виртуальных машин.
Может, нужно где-то в настройках включить? Или воспользоваться фичами из АПИ Стима. Потому что обычно игры из Стима автоматически запускают Стим перед своим запуском, может, там в апи есть какой-то интерфейс для теста типа "играет ли пользователь в эту игру"?
Кто работал с этим:
https://docs.godotengine.org/en/stable/classes/class_physicsserver.html
Подскажите, насколько хорошо использование этого сервера оптимизирует сцены с большим количеством коллиженшейпов на небольшом количестве объектов? В частности всего несколько статикбоди и несколько ригидбоди, но у них может быть очень большое количество шейпов, которые могут добавляться и удаляться динамически. Хочу прикинуть, на сколько сотен/тысяч шейпов я могу рассчитывать на своём древнем ПК. Прототип на нодах уже работает и пока не лагает, если не спавнить слишком много шейпов, но мне нужно прикинуть перспективы масштабирования.
https://docs.godotengine.org/en/stable/classes/class_physicsserver.html
Подскажите, насколько хорошо использование этого сервера оптимизирует сцены с большим количеством коллиженшейпов на небольшом количестве объектов? В частности всего несколько статикбоди и несколько ригидбоди, но у них может быть очень большое количество шейпов, которые могут добавляться и удаляться динамически. Хочу прикинуть, на сколько сотен/тысяч шейпов я могу рассчитывать на своём древнем ПК. Прототип на нодах уже работает и пока не лагает, если не спавнить слишком много шейпов, но мне нужно прикинуть перспективы масштабирования.
>скаммер
В чём скам? Вроде бесплатно туториалы делает же.
Я хз, но заметил там интересную функцию area_set_shape ( RID area, int shape_idx, RID shape )
Substitutes a given area shape by another. The old shape is selected by its index, the new one by its RID.
На этом, наверное, можно пул коллижнов сделать.
Ты новенький здесь? Это токсик-борда. Все стараются побольней ужалить любого.
> пул коллижнов сделать
Игра-то есть? Или опять преждевременной оптимизацией несуществующей игоры занимаемся? В гдскрипте ящитаю выигрыша не будет по сравнению с искаробочными классами-хелперами. Если бы у тебя была игра и тебе нужно было её оптимизировать, ты бы написал модуль на крестах, реализующий пул коллижншейпов и пересобрал бы движок со своим модулем.
>Шютка
Ты сделал 7 ошибок в слове "клевета", анон.
>Клевета — заведомо ложная порочащая информация или распространение заведомо ложных сведений, порочащих честь и достоинство другого лица или подрывающих его репутацию.
>area_set_shape
По-моему, эта функция делает то же самое, что ты делаешь вручную, когда добавляешь ноду CollisionShape к ноде Area.
>пул коллижнов
Мне не пул нужен, а собрать одну большую физическую модель из множества шейпов в процессе игры. Не ясно только, на сколько шейпов я могу рассчитывать, прежде чем всё начнёт лагать.
Прост раньше пробовал чисто на дерево инстанциировать отдельные статикбоди с простыми шеймпами и всё дико лагало после нескольких десятков тысяч нод в дереве (более 40k). Я знаю, что дерево сильно замедляет работу, но сомневаюсь в эффективности "серверов", а на них работать всё-таки значительно сложнее, чем с деревом сцены. Щас напишу огромный велосипед, а вдруг прирост производительности будет +5 фпс, ну нафиг такое.
Алсо не совсем понятно, что лучше - несколько статикбоди с десятками шейпов или один статикбоди с сотнями шейпов? Они же так и так не двигаются, можно склеить...
>Игра-то есть? Или опять преждевременной оптимизацией несуществующей игоры занимаемся?
Игры нет, но есть несколько прототипов, в одном из которых я ощутил довление со стороны дерева сцены, но узнав сложности работы с серверами как-то приуныл и сдулся. Теперь я думаю, а что было бы, если бы я переписал всё на сервера? Вдруг фпс подскочил бы до небес и я бы смог на одну такую карту в сотню раз больше контента накидать, а не оставлять недоделанные тестовые кубы.
Если что, я пробовал сделать чанковую систему. Проблема в том, что добавление/удаление чанков в/с дерева сцены создаёт ещё более сильные тормоза, чем само существование нескольких десятков тысяч нод. Непонятно, будут ли такие же тормоза в чанковой системе на основе серверов или нет.
Я видел чей-то проект на базе серверов годо, но там чувак хвастался тем, что с самого начала делал на серверах, поэтому никакой сравнительной статистики у него нет. Да и проект у него, гм, с видом сверху, т.е. обзор камеры ограничен очень малым числом объектов (непонятно зачем ему вообще сервера понадобились).
Скамер != скаммер. Кроме того, закон о сатире козырней.
>Скамер != скаммер.
Эксперты в суде разберутся без твоей подсказки))((
Оригинальное слово scammer по правилам английского языка с двойной m, слова scamer в английском не существует, а в русском многие забывают или ленятся удваивать согласные и со временем заимствованное слово может потерять одну согласную. Но, тем не менее, оба варианта слова в народе означают "мошенник".
Я понимаю, что ты так пошутил, но шутка неуместная и тупая. Уровня школьников, которые смеются над Миссисипи и другими Телепорно.
>токсик-борда
А ты токсик-борд не видел, похоже.
А в русском языке нет слова скаммер.
>шутка неуместная и тупая.
Добро пожаловать на двач.
> довление со стороны дерева сцены
> тормоза в чанковой системе
Я не знаю. Вроде многопотоки надо лепить с мьютексами и семафорами. Иначе я ХЗ какую надо слепить чорную магию пиксельговгину в окне 400х300 отскейленном чтобы запилить в одном потоке динамический опенворлд.
>Вроде многопотоки надо лепить с мьютексами и семафорами
Какие там многопотоки, дерево сцены работает в одном потоке. Сильные тормоза возникают из-за, как минимум:
- обхода дерева движком каждый кадр;
- добавления новых нод в дерево (add_child());
- удаления нод из дерева (remove_child()).
Чтобы избавиться от этой проблемы, в движке есть АПИ для прямой работы с серверами (графическим, физическим и т.д.). Ты можешь отправить какие-то данные на сервер и не теребонькать дерево сцены. Но работа с сервером сложнее работы с деревом сцены, поэтому применять их нужно только когда в этом есть необходимость. Вот я и пытаюсь понять, насколько выгодно их использовать, а то вдруг прирост производительности +1%, зачем мне он...
>пиксельговгину в окне 400х300 отскейленном
Графика вообще проблемы не составляет, у меня и 5+ миллионов вершин на экране было и ничего не тормозило (75 фпс), а тут , как видишь, меньше миллиона вершин, но фпс просел до 3, потому что 88к нод в сцене.
Ладно, я всё понял, тут никто опенворлды не делает, придётся самому на практике выяснять, насколько выгодны сервера.
Если ты такой крутой, то лепи свой собственный майнлуп без дерева сцены вообще.
https://docs.godotengine.org/ru/stable/classes/class_mainloop.html
Зачем? В прошлом пробовал писать движок с нуля, бросил и перешёл на готовый движок, только чтобы снова писать с нуля?
Дерево сцены удобно для многих задач. Но не справляется с большим количеством объектов (десятки тысяч). Обычно в таких случаях используют сервера...
Хм... Попробую.
Какой же ты душный пиздец
мимо
> Зачем? В прошлом пробовал писать движок с нуля, бросил и перешёл на готовый движок
Свой майнлуп в готовом движке проще, чем свой движок и сложнее, чем чужой готовый майнлуп. Это типа нечто среднее. У тебя остаются серверы и менеджеры ресурсов. Вся инфраструктура годота остаётся. Только майнлуп твой.
Вместо дерева сцены менеджер сцены, который ты можешь сделать... эммм... деревом.
У нас всегда так. Либо душно, либо токсично.
В чем он не прав?
Ну это всё понятно, но я делаю 3Д и мне нужно изкоробочное дерево сцены для таких вещей, как, например, персонажи. Дерево мешает только с большим количеством однотипных простых элементов, например, модули генерируемого ландшафта или модули сборных построек. Т.к. модули в большинстве своём тупые, тратить на них ноды нерационально, а их потенциально огромное количество перегружает дерево сцены.
Пару часов назад сделал тест на обычной сцене. Результат неожиданный - добавление коллиженшейпов в один статикбоди нагружает игру намного сильнее, чем создание того же количества статикбоди с одиночными шейпами (в обоих случаях ещё добавляются меши с материалом и текстурой). Как я понял, буллет начинает серьёзно тормозить после 1000 шейпов на одном боди, а вот дерево сцены тормозит у меня примерно после 20-30 нод, то есть в простейшем случае без тормозов (~75 фпс) можно иметь 10к статикбоди или менее 15к коллиженшейпов на одном статикбоди, но чтобы достичь второго варианта, придётся убить уйму времени (где-то полчаса) на пропихивание коллиженшейпов в статикбоди. И это я даже не пытался ничего на них сбрасывать, просто камеру крутил. Хорошо, что я не начал реализовывать второй способ в игре (ну как "не начал", он уже реализован, но только для ригидбоди).
Глянул как юзать сервера... для статикбоди должно быть несложно, жаль, что с ригидбоди получится хрень - нужно вручную передавать трансформы из физиксервера в визуалсервер. Почему так-то? Я ожидал чего-то вроде link(body, mesh) и дальше пусть оно само повторяет трансформы. Сомневаюсь что есть какая-то большая польза от того, что все боди по умолчанию невидимые.
Хе-хе, щас как напишу оболочку для обращения к серверам и снова буду абстрагирован от всех этих низкоуровневых апи)
У тебя что вообще за жанр? Как бы обычной игре не нужно иметь ВЕСЬ город в физике одномоментно, только чанк квартала вокруг игрока/ов.
>У тебя что вообще за жанр?
У меня несколько заготовок, эти две самые серьёзные:
1. GTA-like с генерируемыми городами. Есть базовый генератор карты островного типа из модулей 24х24 метра, есть система чанков. Проблема: все объекты на нодах, число нод растёт очень быстро, из-за этого даже "голая" карта достаточного размера тормозит, но если применять выгрузку и загрузку чанков во время движения игрока, тормоза становятся ещё сильнее - операции по извлечению нод из сцены дороже, чем хранение их в сцене. В общем, я испугался сложности необходимых оптимизаций (серверы) и отложил проект в долгий ящик (уже который раз за последние ~13 лет).
2. Игра про летающие острова и строительство летающих кораблей. Есть базовый прототип строительства на нодах - компоненты на базе CollisionShape соединяются с кораблём-RigidBody, конструкция правдоподобно летает, можно достраивать прямо в полёте. Острова планируется генерировать по тому же принципу, что и города из предыдущего прототипа, но из более крупных фрагментов и меньшей суммарной площади. Но тут я сталкиваюсь с тем, что после 1000 CollisionShape добавление новых затруднительно, да и загрузка/выгрузка острова доставит проблем, особенно со всеми мелкими компонентами (деревья/кусты, например). Я в раздумьях, стоит ли сразу писать под серверы или можно сделать на нодах...
Если что, я знаю про то, что загрузку/выгрузку можно ставить в очередь и распределять по кадрам, чтобы минимизировать задержки. Не помню точно, вроде не пытался таким способом оптимизировать чанковую систему... но главная проблема в том, что даже единичная выгрузка (через remove_child) занимает кучу времени. А если распределение по времени будет слишком долгим, игрок быстро добежит до дырок и провалится или застрянет в них.
Беседы про репарент нод несколько тредов назад ты, видимо пропустил?
Если вкратце. Там некий анон хвастался, что добился прироста производительности, создав пул нод, висящий в памяти, загруженный и не выгружающийся. У пула парент не в дереве. Соответственно, и он сам и его потомки не активны - у них не вызываются колбэки процесса и т.п. При необходимости, ноды из этого пула внедряются в дерево сцены и начинают работать, а потом обратно удаляются в пул. И якобы у него там был прирост производительности по сравнению с загрузкой/выгрузкой нод. Но пруфов он не предоставил.
>Беседы про репарент нод несколько тредов назад ты, видимо пропустил?
Да, я вообще не слежу за тредами здесь, редко захожу.
>создав пул нод, висящий в памяти, загруженный и не выгружающийся. У пула парент не в дереве. Соответственно, и он сам и его потомки не активны - у них не вызываются колбэки процесса и т.п. При необходимости, ноды из этого пула внедряются в дерево сцены и начинают работать, а потом обратно удаляются в пул.
Я делал точь-в-точь такую же систему полтора года назад. Сразу в двух вариантах:
1. Объекты интерьера скрываются, когда игрок выходит за дверь, и отображаются, когда игрок входит в дверь.
2. Чанки скрываются, когда игрок отходит от них на определённое расстояние, и отображаются, когда подходит к ним.
>по сравнению с загрузкой/выгрузкой нод
Я неправильно выразился.
"Загрузка" - add_child(chunk)
"Выгрузка" - remove_child(chunk)
Т.е. точно та же фигня, что у того анона.
Проблема в том, сколько нод нужно добавлять/удалять за кадр. В случае с интерьером я особо не тестил нагрузку, но там у меня были мелкие комнаты и в идеале нод было мало (на самом деле была значительная нагрузка, если попытаться включать интерьеры в нескольких ближайших домах). В случае с чанками вышло так, что даже имея крупные чанки (24 метра), нужно за один раз работать сразу с несколькими десятками, даже в небольшом радиусе, а ведь внутри чанка тоже ноды. Возможно, если создавать очередь, это было бы не так заметно...
В общем, ноды для больших сцен - это плохо, нужно изучать работу с серверами и не насиловать дерево сцены тысячами нод, особенно физических (т.к. каждая физическая нода регистрирует себя на физическом сервере, а он работает асинхронно в отдельном потоке, отсюда лаги).
Ну я в самом начале сказал, что пилить надо многопоточную систему, а это невозможно в дефолтной (однопоточной!) реализации дерева сцены. Следовательно, нужно пилить собственный майнлуп, в который впроектировать многопоточную архитектуру.
И это логично, не в упрёк Хуану, но его решения исключительно учебного характера. Не рассчитанные на реальный продакшен.
Ты же знаешь, что в годоте есть https://docs.godotengine.org/en/stable/tutorials/threads/using_multiple_threads.html
> Какие там многопотоки, дерево сцены работает в одном потоке
> дефолтной (однопоточной!) реализации дерева сцены
> Ты же знаешь
Нет ты.
На дерево это не влияет. Во сколько потоков ты ни грузи ноды, тебе придётся локнуть главный поток, чтобы присоединить их к дереву. Об том и речь.
Сделал свой тест производительности на базе серверов по официальному туториалу. Что печалит:
- визуальный сервер начинает плавно тормозить примерно с 13-14 тысяч визуальных объектов одновременно на экране, и это не зависит от видеокарты (подозреваю, всё упирается в число запросов от процессора к видеокарте);
- визуальный сервер не отсекает объекты, перекрытые другими объектами (ну это и так всем известно);
- физический сервер резко захлёбывается и снижает общую производительность до минимальной (5 FPS лол) на 12-13 тысячах статических объектов, при этом нагрузка на 4-ядерный процессор неполная - видимо, всё упирается в производительность на ядро;
- если неправильно вызвать free_rid() (например, освободить шейп, который привязан к боди), программа зависает и завершается без каких-либо сообщений об ошибке (похоже на баг).
Что радует:
- визуальный сервер отсекает объекты вне поля зрения камеры, поэтому можно без проблем создать 300 тысяч и больше визуальных объектов, лишь бы они не отображались одновременно;
- физический сервер создаёт новые физические (статические) тела молниеносно вплоть до примерно 10 тысяч объектов;
- удаление объектов пачками через free_rid() практически не влияет на производительность примерно до тысячи объектов за кадр (один объект - это 3 вызова free_rid(): шейп, боди и графический инстанс).
RigidBody, несколько шейпов на объект и т.д. тестить не стал. Главный для меня вывод - чанковая система на основе серверов будет работать лучше, т.к. тормоза во время создания и удаления объектов меньше. Я знаю, что удалять не обязательно, но т.к. это самые затратные операции и они не занимают много времени - другие способы будут быстрее. Хотя через сервера управлять объектами сложнее...
Эх, ещё немного потыкался - всё-таки прирост производительности минимальный. Ноды и дерево, конечно, замедляют игру, но не так сильно, как казалось. Впрочем, разница в производительности заметна невооружённым глазом, а это что-то да значит. В любом случае, главное - это умная система чанков, я просто в тупую пытался тысячи объектов туда-сюда таскать, поэтому и медленно было.
>пилить надо многопоточную систему
Ну я прикинул, если использовать серверы - многопоточности не нужно, добавления/удаления 1000 объектов за кадр должно хватить чанковой системе, учитывая возможность поставить всё это в очередь, растянув на несколько кадров. Многопоточность нужна физическому движку, который захлёбывается из-за 12 тысяч статичных объектов, не нагружая процессор, но это вопрос к Bullet, а не к Godot. Конкретно к Godot вопрос в том, почему он до сих пор не умеет отбрасывать невидимые (перекрытые) объекты, но, мне кажется, это должны скоро исправить (порталы вот уже сделали в одной из бета-версий, а ведь я их велосипедил когда-то).
>тебе придётся локнуть главный поток, чтобы присоединить их к дереву
Таки почему у меня цикл
>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, несколько шейпов на объект и т.д. тестить не стал. Главный для меня вывод - чанковая система на основе серверов будет работать лучше, т.к. тормоза во время создания и удаления объектов меньше. Я знаю, что удалять не обязательно, но т.к. это самые затратные операции и они не занимают много времени - другие способы будут быстрее. Хотя через сервера управлять объектами сложнее...
Эх, ещё немного потыкался - всё-таки прирост производительности минимальный. Ноды и дерево, конечно, замедляют игру, но не так сильно, как казалось. Впрочем, разница в производительности заметна невооружённым глазом, а это что-то да значит. В любом случае, главное - это умная система чанков, я просто в тупую пытался тысячи объектов туда-сюда таскать, поэтому и медленно было.
>пилить надо многопоточную систему
Ну я прикинул, если использовать серверы - многопоточности не нужно, добавления/удаления 1000 объектов за кадр должно хватить чанковой системе, учитывая возможность поставить всё это в очередь, растянув на несколько кадров. Многопоточность нужна физическому движку, который захлёбывается из-за 12 тысяч статичных объектов, не нагружая процессор, но это вопрос к Bullet, а не к Godot. Конкретно к Godot вопрос в том, почему он до сих пор не умеет отбрасывать невидимые (перекрытые) объекты, но, мне кажется, это должны скоро исправить (порталы вот уже сделали в одной из бета-версий, а ведь я их велосипедил когда-то).
>тебе придётся локнуть главный поток, чтобы присоединить их к дереву
Таки почему у меня цикл
>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() идут к отдельным потокам, в которых вертятся сервера (по идее).
>Таки почему у меня цикл
>>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 с видом сверху проще, но там нужно было сильно переделывать генератор карт и я окончательно на всё забил... Блин.
> queue_free()
> Где этот прирост производительности-то... куда он делся?(
Ты меня не слушал.
> создав пул нод, висящий в памяти, загруженный и не выгружающийся.
Загруженный.
Не выгружающийся.
Пул, мазафака, ду ю но ит? Тормоза берутся, когда ГЦ высвобождает память. И когда менеджер памяти выделяет память под новую ноду. Минимизируешь загрузку/выгрузку из памяти за счёт максимального реиспользования нод. Это напрямую значит, что чайлды нод создаются только один раз при старте игры. Возможно даже в отдельных потоках. После того как поток просигналил о завершении, ты знаешь, что в определенной переменной лежит новая нода. Нода помещается в пул. Далее ноды, оставаясь в памяти, вмять! перемещаются репарентом по необходимости из пула в дерево и из дерева в пул.
Парни, хелпайте, в геймдеве опыта не имею, а тут такие обидные штуки случаются.
В общем, баловался с Camera2D и управлением как во всяких стратегиях с видом сверху. Я смог понять, как камера передвигается с помощью мыши и вроде не так уж и криво, но решил привязать gui к этой камере.
Так вот, сама суть: когда Camera2D достигает лимита, то если я делаю движение по смене позиции в сторону лимита, то картинка за лимит не уходит, но туда gui съезжает, т. е. Camera2D всё равно меняет позицию, уходя за лимит, но этого не видно.
Вообще, можно как-то сдетектить, что лимит был достигнут(чтобы не передвигалась Camera2D за него) или нужно gui не к камере привязывать, лол? Если что, реализовал перемещение камеры через изменение global_position.
В общем, баловался с Camera2D и управлением как во всяких стратегиях с видом сверху. Я смог понять, как камера передвигается с помощью мыши и вроде не так уж и криво, но решил привязать gui к этой камере.
Так вот, сама суть: когда Camera2D достигает лимита, то если я делаю движение по смене позиции в сторону лимита, то картинка за лимит не уходит, но туда gui съезжает, т. е. Camera2D всё равно меняет позицию, уходя за лимит, но этого не видно.
Вообще, можно как-то сдетектить, что лимит был достигнут(чтобы не передвигалась Camera2D за него) или нужно gui не к камере привязывать, лол? Если что, реализовал перемещение камеры через изменение global_position.
> или нужно gui не к камере привязывать, лол?
This.
Изучи класс CanvasLayer и зачем он нужен. Если вкратце, то ты делаешь несколько таких слоёв, в одном гуй, в другом сцена и камера.
Это ты меня не слушал.
>перемещаются репарентом по необходимости из пула в дерево и из дерева в пул.
Я именно так и делал. Но это вызывает дичайшую нагрузку, когда нужно репарентить сколь-либо существенное количество нод. Именно поэтому я заинтересовался серверами, но на практике выяснилось, что они не дают никакого прироста производительности по сравнению с этим самым "пулом нод".
Единственный выход - делать очередь на репарент и пропихивать ноды в час по чайной ложке, чтобы не было резких просадок фпс. Аналогично с созданием и освобождением нод.
Вообще, мне кажется, что тот хваставшийся анон - это я, ведь именно я 1.5 года назад где-то здесь хвастался, как у меня десятки тысяч нод находятся в скрытом пуле (только слова я такого не знал, я называю это контейнером), пока игрок не зайдёт в помещение.
Ну ладно. Значит отбрасываем эту идею и ищем дальше.
действительно, теперь ничего не съезжает, спасибо, анончик.
В следующий раз, прежде чем задавать вопрос, попробуй почитать официальные туториалы в мануале, например: 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
Зачем может быть нужно что-то другое? Тем более сложное.
>зачем делать так, если можно просто:
Очевидно чтобы были категории, сворачиваемые списки.
Есть еще ассет цветные кнопочки наворачивать.
https://godotengine.org/asset-library/asset/1054
> Зачем может быть нужно что-то другое?
Всё это - вопрос вкуса. Тебе удобнее через словари/объекты/таблицы/ассоц.массивы. Через точку. Кому-то другому нравится через классы и методы, через функцию с аргументом в скобочках. Некоторым нравится ещё и через словари, но не через точку, а через квадратные скобочки.
> export var
> weapons = []
Насколько я помню, в инспектор вылезет интерфейс нетипизированного массива, в который можно напихать любой хуйни, от которой игра обмякнет, если не писать кучу проверок на дурака при работе с этим массивом. Возможно уже сделали механизм, позволяющий фильтровать, а лучше типизировать данные для добавления в массив из инспектора?
В качестве костыля, испрвляющего эту и подобные траблы при работе со словарями, несколько лет назад был написан скрипт, реализующий минимальный функционал ЖСОН-схемы. Идея скрипта, для анонов, не знакомых с принципом валидации по схеме, заключается в том, что для целевого объекта пишется схема, из чего он может состоять, из чего не может, включая все уровни вложенности. Т.Е. схема может быть весьма обширной. Единожды написанная схема позволяет заменить собой весь комплекс проверок на дурака.
Внимание! Костыль с говнокодом через 3... 2... 1...
https://godotengine.org/asset-library/asset/514
> не вывезли реквест
> на мобиле
Никто не вывезет. 100500 кубов с физоном это лютая подъёбка, которую раскусили ещё джва года назад (но не смирившиеся были изгнаны в срачетред). Суть токова: мобилы это глобальное наебалово быдла корпоративными кабанчиками. Хочешь, чтобы мобила вывозила ГРАФОНИУМ - покупай мобилу за 50К. Но зачем, если вместо игровой мобилы выгоднее купить плойку?
> я плавал я знаю
Так а почему же тогда 15 ФПС на вебэмке, лол?
Анончики, подскажите как правильно настроить fog. Хочу сделать атмосферное затенение для высокой башни для задника, но нужный мне эффект достигается только фогом с высталеннымы параметрами height max и height min (500 и 3000 соответвенно) но при этом все объекты находящиеся снизу закумариваются фогом вглухую. Как можно настроить реалистичный фог, который усиливается вдаль, и уменьшается с высотой?
> реалистичный фог, который усиливается вдаль, и уменьшается с высотой?
Плагином. Буквально вчера видел.
>Очевидно чтобы были категории, сворачиваемые списки.
Это и через словари с массивами делается.
>Есть еще ассет цветные кнопочки наворачивать.
Зачем?
>Всё это - вопрос вкуса.
Согласен, но я не понимаю, кому может быть удобно группировать переменные с именами типа player_weapon, player_weapon_count, player_weapon_pistol_bullets_damage, player_weapon_pistol_bullets_count и т.д., когда такие вещи нужно сортировать по разным объектам (player, weapon, pistol, bullet) или внутри древовидного словаря (player.weapons.pistol.bullets.damage - всё просто, понятно и, главное, компактно как в коде, так и в интерфейсе)..
>от которой игра обмякнет, если не писать кучу проверок на дурака при работе с этим массивом
Лучшая проверка на дурака - это человек, который контролирует доступ дураков к конкретному компьютеру. Если программа встретила ошибку в данных, она должна упасть с сообщением об ошибке, требующим эту ошибку исправить, а не тихо проглотить или попытаться исправить. Мы ведь не прошивку для космических ракет пишем (для этого нужна Ada), а развлекательные программы, от которых не требуется надёжной безотказной работы во что бы то ни стало. И если ты объявил динамический массив, а потом САМ напихал в него всякой херни, от которой твоя игра обмякла - виноват тут только ты сам.
Другое дело, что строго типизированные переменные ускоряют операции на сколько-то %, но это вроде как только в будущих версиях. Кстати, в GDScript 2.0 будут типизированные массивы, что-то вроде Array[String] - массив строк. Мне, как воспитанному Паскалем, очень хочется такие массивы, я привык к "array of тип". Впрочем, гораздо больше мне не хватает создания пользовательских типов (в Паскале это раздел type любого модуля/программы)...
>400 кубов
Тебе кинуть ссылку на алиэкспресс, где можно купить детские кубики с буковками? Как раз скоро распродажа 11.11, купишь себе 500 кубиков и будешь с ними в своей комнате играть сколько влезет, без единого лага на максимальной частоте кадров, сколько могут воспринять твои глаза. Я же вижу, ты не наигрался в детстве, наверное, тебе их просто не покупали...
А на игровых движках нужно делать нормальные игры.
> Мы ведь не прошивку для космических ракет пишем (для этого нужна Ada), а развлекательные программы, от которых не требуется надёжной безотказной работы во что бы то ни стало.
Тодд Говард в треде! С его падающим каждые 5 минут скайримом!
> кому может быть удобно группировать переменные с именами типа player_weapon, player_weapon_count, player_weapon_pistol_bullets_damage, player_weapon_pistol_bullets_count и т.д.
Ты невнимательно смотрел видос. Там имена переменных даются для наглядности. В реале через оверрайд тех методов ты можешь в инспекторе прописать переменную Foo в категории Bar, которая перенаправляет значения во внутреннюю переменную Baz скрипта. И даже (о ужас!) в индекс массива записывать!
Мне не понравилось, что для этого скрипт нужно тулскриптом делать. Это добавит головняка.
>падающим каждые 5 минут скайримом
Я не предлагаю выпускать в релиз неотлаженную версию, которая падает каждые 5 минут. Просто позволь игре падать, пока ты её разрабатываешь, чтобы ты знал о существовании внутренних проблем и пытался их исправить. А если игра у тебя сейчас молча съедает любые данные и не падает, то потом ты очень удивишься, когда в релизе вылезут непонятные баги, о которых ты ничего не знаешь, потому что даже не пытался их отлавливать.
>ты можешь в инспекторе прописать переменную Foo в категории Bar, которая перенаправляет значения во внутреннюю переменную Baz скрипта. И даже (о ужас!) в индекс массива записывать!
З А Ч Е М
А
Ч
Е
М
В каких ситуациях вот прям очень нужно внедрять такую мудрёную систему? Тем более что она в любом случае
>добавит головняка.
> З А Ч Е М
Чтобы все охуели, как я могу.
Вообще-то речь про инструменты разработчика - их никто кроме тебя не увидит, если ты работаешь над проектом один и не спамишь скриншотами редактора везде где можно.
А у всех подсказки в редакторе Годо мигают? Навожу курсор на элемент интерфейса, подсказка появляется, через секунду исчезает, потом снова появляется и т.д. Читать текст подсказки из-за этого очень сложно. Версии Годо - разные, я этот баг уже 2 года наблюдаю. Система Windows 10. Дрейфа курсора точно нет и в других программах с всплывающими подсказками всё нормально, впервые встретил такое именно в Годо. Почему это так и как исправить? Очень редко, бывает, подсказка работает нормально, но потом опять ломается и начинает мигать. Очень раздражает...
Нет, никогда не сталкивался. Погуглил, пишут такое бывает, если стоит какой-то сторонний софт, типа кастомного рабочего стола. Особенно если у софта настройка "всегда поверх других окон". М.б. мессенджер какой-то.
>кастомного рабочего стола
Нет такого. Есть только драйвер мыши, но он ничего особенного на экран не выводит, тем более в окно Godot, тем более постоянно.
>всегда поверх других окон
Ну вот диспетчер задач никак подсказкам Годо не мешает, хотя находится поверх всех окон... Да и как оно может мешать, если подсказки Годо рендерятся прямо в окне редактора, не выходя за его пределы?
>мессенджер
Вообще не пользуюсь.
Короче, хотел сейчас протестировать, закрыв лишние программы, но ВНЕЗАПНО подсказки сейчас работают нормально со всеми теми программами что обычно открыты. Я позавчера перекатился на 3.4, не уверен, замечал ли этот баг в этой версии или нет... Почему-то кажется, что вчера он был, а сейчас пропал.
Вспомнил ещё, что меня раздражает в подсказках: там часто есть ссылки на какие-нибудь компоненты, разделы справки и т.д., но кликнуть по ним невозможно, потому что подсказка скрывается, если навести на неё курсор. Приходится искать тот же текст в окне по F1. Это так и задумано что ли? Я бы сделал так, чтобы подсказки задерживались на экране, давая кликнуть на ссылку.
Кстати, кто уже перекатился на 3.4 - как ощущения? По-моему редактор стал в несколько раз шустрее откликаться, сцены быстрее открываются и даже отклик игры лучше. Они что, повысили частоту опроса устройств ввода? Я благодаря этому обнаружил баг в своём коде вращения камеры мышкой, лол, вместо "+=" было "=" и смещение курсора не накапливалось, из-за чего камера двигалась рывками.
>ВНЕЗАПНО подсказки сейчас работают нормально
Опять мигают. Но теперь я погуглил и нашёл источник проблемы.
https://github.com/godotengine/godot/issues/41251
Только в моём случае подсказки мигают с частотой примерно 1 Гц пока MPC-HC воспроизводит музыку. От режима отображения окна никак не зависит, даже если окно свернуть в трей.
Кстати, забавно, но подсказка сохраняется и не мигает, если двигать курсором туда-сюда вдоль элемента управления, которому принадлежит эта подсказка. Ну а если поставить музыку на паузу, например, медиаклавишей, то подсказка вообще мигать перестаёт и работает нормально.
Какой-то дурацкий баг. Но теперь хотя бы понятно, как читать подсказки)
> Какой-то дурацкий баг.
Это не я! Это всё драйвера опен гл ес! Вот выкачу четвёрку на вулкане и подсказки будут мигать уже при одновременно запущенном в фоне вулкан-приложении!
мимохуан
Порталы 3д оптимизируют нормально?
Что тут сказать. С видео/музыкой vlc, mpv и firefox картинка-в-картинке таких проблем нет.
> Что тут сказать
Еблан наставил говна себе в винду, что она вся моргает и трисётси, а виноват конечно - кто? Ну-ка хором!
>а виноват конечно - кто? Ну-ка хором!
Иван Васильевич Бунша?!
>vlc, mpv
Да я просто MPC:HC пользуюсь сколько себя помню, ещё с Windows XP, не хочу переходить на какие-то непривычные свестяще-пердящие альтернативы. И это первый такой случай, чтобы MPC:HC мешал каким-либо приложениям. Но помеха минимальная, мне эти подсказки редко нужны, а поставить музыку на паузу вообще не проблема с медиа-клавишами клавиатуры. Просто баг очень странный, MPC:HC вообще-то использует DirectX, а Godot только OpenGL, при этом речь даже не о видео, а о музыке... Но каким-то мистическим образом воспроизведение музыки MPC:HC вызывает ежесекундные обновления окна редактора Godot и мигание подсказок (которые цветные с форматированием, с жёлтыми всё нормально).
Сделай тестовую сцену и проверь сам. Мне вот порталы не нужны, у меня опенворлд и оптимизация должна быть чанками, а порталы используют только в помещениях, то есть в каких-нибудь коридорных уровнях, где игрок идёт из комнаты в комнату.
Как делать ДЛЦ? Как бы делали вы?
Официальный способ таков
https://docs.godotengine.org/en/stable/getting_started/workflow/export/exporting_pcks.html
Как настроить освещение, чтобы было как, например, в майнкрафте? Там на освещённых местах ярко, а в пещерах тьма, вообще ничего без источника света не видно. Я у себя настроил освещение так, чтобы тени были светлыми, но из-за этого в закрытых помещениях слишком светло... Я так понимаю, придётся динамически определять, находится ли игрок в помещении или снаружи?
>Как настроить освещение, чтобы было как, например, в майнкрафте?
В мойнкрафте освещение считается велосипедно поиском пути по A* от кубиков
> Я так понимаю, придётся динамически определять, находится ли игрок в помещении или снаружи?
Правильно понимаешь.
Вообще, работа со светом - отдельный параграф геймдизайна, требующий без шуток кинематографических знаний и желательно опыта. Когда ты в современных играх видишь, как освещение меняется по ходу движения, там желтеет, тут синеет, там ярче, тут глубже, - ты порой даже не задумываешься, что за этим стоит долгая (и высокооплачиваемая!) постановочная работа.
Ну а технически, в годоте, рекомендую делать это через Area. Прошёл сигнал, что камера, через которую игрок смотрит в пещере - источники света переключаются для неё в режим пещер. Так же удобно сразу подгружать в камеру соответствующий файл окружения. Думаешь это просто так Хуан сделал окружение отдельным файловым ресурсом Environment, и полем для его динамической подгрузки в камеру?
Анон, расскажи перекату с первого GameMaker за Годо. Хочу запилить две игори, но не могу оценить затраты по времени, дошику и общий заеб -
1) 2D, Симулятор сетевого маркетолога. По фронту близкое к визуальной новелле, то есть набор сцен, артов персонажей, на движке упрощенной RPG со статами, прокачкой и инвентарем (без менеджмента). Возможно будет передвижение по городу аля JRPG.
2) 3D топ-довн шутан. Очень нравится эстетический лук пикрелейтед, но с 3D до этого вообще не работал и не могу осознать насколько это гемор или нет. По механикам всё стандартно на уровне технодемки: стрельба, перезарядка, смена оружия, разные параметры оружия, смэрть и сердешки. AI тоже простой, на паре стейтов типа "покой, бег к цели до дистанции атаки, атака".
На коммерцию не рассчитываю, хочу пощупать движок и воплотить идеи. Может быть потом когда-нибудь с кем-нибудь как-нибудь это будет допиливаться/перепиливаться для сторов, но сейчас цели другие.
Какие подводные? Стоит ли вообще вкатываться в Годо?
1) 2D, Симулятор сетевого маркетолога. По фронту близкое к визуальной новелле, то есть набор сцен, артов персонажей, на движке упрощенной RPG со статами, прокачкой и инвентарем (без менеджмента). Возможно будет передвижение по городу аля JRPG.
2) 3D топ-довн шутан. Очень нравится эстетический лук пикрелейтед, но с 3D до этого вообще не работал и не могу осознать насколько это гемор или нет. По механикам всё стандартно на уровне технодемки: стрельба, перезарядка, смена оружия, разные параметры оружия, смэрть и сердешки. AI тоже простой, на паре стейтов типа "покой, бег к цели до дистанции атаки, атака".
На коммерцию не рассчитываю, хочу пощупать движок и воплотить идеи. Может быть потом когда-нибудь с кем-нибудь как-нибудь это будет допиливаться/перепиливаться для сторов, но сейчас цели другие.
Какие подводные? Стоит ли вообще вкатываться в Годо?
В годоте есть визуальные слои (как в блендере), соответственно если какой-то объект находится в слое 2, то источник света в слое 1 на него не действует. Это же касается камер. Например можно сделать объект стены, который только отбрасывает тень.
>Какие подводные?
Никаких.
>но с 3D до этого вообще не работал
За месяца 3 научишься.
>Стоит ли вообще вкатываться в Годо?
Посмотри на тысячи готовых успешных законченных годот игр и ты сам себе ответишь на этот вопрос.
Двачую. Ссылка на игры в оп-посте.
>велосипедно поиском пути по A* от кубиков
Про это я слышал, но меня интересует не велосипед майнкрафта, а то, как выглядит результат - светлые тени на поверхности и кромешная тьма в подземельях - и как можно добиться его в игре на Годо.
>можно сделать объект стены, который только отбрасывает тень
Как это поможет в ситуации, когда я хочу светлые тени в одном месте и тёмные тени в другом? Тени друг с другом не складываются же.
>требующий без шуток кинематографических знаний и желательно опыта
Это если нужен реализм, а мне реализм не нужен. Я просто собрал из примитивных блоков "пещеру", прогулялся по ней, вроде всё ок - но вдруг подумал, а чё так светло-то, будто днём под деревом? И вспомнил, какая в майнкрафтовских пещерах тьма... Так что мне особых знаний и опыта не нужно, мне, надеюсь, достаточно темноту нагнать.
>делать это через Area
О, точно, а я что-то про рейкаст "в потолок" думал. Area действительно удобнее будет, я могу её шейп динамически смоделировать и объединить все ближайшие однотипные зоны в одну.
>Думаешь это просто так Хуан сделал окружение отдельным файловым ресурсом Environment, и полем для его динамической подгрузки в камеру?
Нет, конечно, я понимаю такое решение, но не совсем ясно, как сделать переключение, да ещё и плавное. Про отдельный ресурс я, кстати, читал в блоге Overwatch - там они для Overwatch 2 изобрели какой-то велосипед, позволяющий легко менять настройки окружения для любой карты - раньше всё окружение, как я понял, запекалась в карту, из-за чего нельзя было просто так взять и изменить день на ночь, не создавая отдельной карты. Забавно, что в Godot уже давно есть то, что только собираются внедрить в ещё не вышедший сиквел Overwatch...
А про поле в камере впервые слышу, я у себя создал отдельную сцену с какой-то нодой environment и источником света, имитирующем солнце, и сделал её синглтоном. Нужно будет мануал почитать)
>перекату с первого GameMaker за Годо
GM/GMS - это "конструктор игр", а Godot - "игровой движок", хотя и выглядит внешне как "конструктор игр". Разница в том, что конструктор даёт компоненты по типу деталек Лего, из которых любой ребёнок без опыта и знаний соберёт игру, но что-то более сложное сделать не всегда возможно, тогда как игровой движок даёт сложные программные инструменты, которые нужно изучать перед использованием, но зато и ограничений намного меньше. Однако система нод Godot сильно напоминает такие детальки Лего, просто разобраться в них сложнее и многое придётся делать самостоятельно в виде скриптов, а не кнопками на экране. Можешь рассматривать GM как Lego Duplo, а Godot - как Lego Technic.
>оценить затраты по времени
1) Читай туториалы, там всё есть. Затраты по времени будут снижаться многократно в процессе выработки навыков.
2) Читай туториалы и не бойся, что это 3D, потому что геймплейно твоя идея 2D, и трёхмерные модельки в данном случае усложняют работу лишь художникам. 3D сложно кодить только если геймплей 3D.
>Какие подводные?
Самое сложное в игре - нарисовать вменяемую графику, от которой не будет тошнить хотя бы тебя. Тем более если ты никогда графикой не занимался, в частности 3D. Закинуть модельки с текстурами в движок и заставить их двигаться - вообще очень легко в сравнении с созданием этих самых моделек и текстур...
>Стоит ли вообще вкатываться в Годо?
Поскольку у тебя нет никаких конкретных запросов, стоит попробовать, а дальше сам разберёшься, продолжать или искать что-то другое. Порог входа в Godot ниже, чем у других популярных движков, он нетребователен к компьютеру, мало весит и полностью бесплатен, поэтому не вижу причин не пробовать.
> про поле в камере впервые слышу
Не вижу прямой связи между количеством успешных игр и движком. Может, дело в игроделах? Или фазе Луны?
Вопрос скорее был именно про актуальность движка и его выбор в рамках специфики конкретных игр. По тому же GMS я могу сказать - да, это конструктор. Он дает больше возможностей если писать код, а не дропать компоненты. Но вывозит что-то дальше геймджемов он с трудом. Быстрое прототипирование и возможность писать костыли - это плюс на короткосроке и в мелких проектах, но на дальней дистанции лично я заработал смерть жопы, пытаясь развить игру во что-то большее. Плюс готовых решений практически нет - от освещения до UI, всё нужно костылить самому, а это тянет за собой необходимость курить дохера материалов и учиться разбираться во всём вообще. Даже поддержка Steam SDK барахлит, и на долгосроке вылезает косяками, помимо непонятных ошибок с исчезающими ключевыми объектами и данными.
Возможно это я криворукий, наиболее вероятно так и есть. Тем не менее.
Поэтому вопрос так верхнеуровнево и звучит - стоит ли в Годо? Потому что я не могу предвидеть все подводные, это можно озвучить только человек который плотно елозится с движком уже год, а лучше и не один. По тому что я успел увидеть в гайдах и в выдаче на ютабе - выглядит слишком оптимистично и идеально. Запнулся только о сигналы, какой-то люто абстрактный прекол, суть вроде бы ясна, а имплементация душит. В остальном выглядит как райский рай где всё модульно, для UI всё готово, освещение, камеры, вагон готовых нодов, скелетная анимация, 2Д, 3Д, и просто уруру и уняня. Тут и возникает вопрос - а какие подводные, и почему еще весь геймдев не перешел на Годо? Дело в движке, или в геймдеве?
А, ну и Python-like очень привлекает, после GMS-ного недоси, недохренпоймичего.
Проблема в годоте - комплексные ноды работают как говно. Ими никто не пользуется. Все что больше кнопки или лейбла уродливо.
Проблемы с оптимизацией. Boolean весит 1 байт. Некоторые решения сделаны очень топорно и будут фризить даже на небольшом количестве данных. Типа выполнение кода с# в первый раз, добавление партиклов в первый раз, некоторых шейдерочков на сцены. Надо делать кучу пустых нод чтобы делать слои шейдеров. Написание 1 буквы вызывает 1 драв колл. Буквы с большим шрифтом (100-200+) будут ещё сжирать видеопамять. Конкретной клетке в тайлмапе нельзя задать высоту, поэтому придется всегда костылить свою тайлмапу. Шейдеры не могут выпукивать свои данные в другие шейдеры или быть зациклены от текущего состояния экрана.
В остальном, особенно для 2д, норм.
>актуальность движка
Движок регулярно обновляется большой группой людей на гитхабе, в следующем году должна выйти версия 4.0, которая исправит массу недоработок.
>специфики конкретных игр
Годо универсален. Есть, конечно, игры, для которых текущая версия Годо не очень подходит - это игры, в которых нужно выжимать из железа максимум производительности, т.е. оптимизировать игру на очень низком уровне абстракции. Твои идеи ничего такого не содержат, это обычные игры.
>готовых решений практически нет - от освещения до UI
Ну, в Годо такие базовые вещи есть, но всё равно придётся многое самостоятельно делать под свою игру, если она необычная.
>развить игру во что-то большее
Разделяешь игру на независимые компоненты и проблем с гибкостью расширения контента и механик не будет, в этом вся суть нодовой системы Годо. Проблема может быть, если будет слишком много нод в дереве сцены (десятки тысяч), тут уже придётся думать над оптимизациями (например, объединять сотни мешей в один).
>человек который плотно елозится с движком уже год
У всех свои игры мечты, соответственно разные подводные камни. Я вот хочу опенворлд песочницу с физикой, Годо сейчас для этого не очень подходит, но у тебя же идеи намного проще.
>Запнулся только о сигналы
Рассматривай их как события из таких средств разработки, как Delphi/Lazarus, а ещё это похоже на события HTML страниц, которые обрабатывают JS функции. Пример: пользователь нажимает кнопку на экране, это генерирует событие а.к.а. сигнал "кнопка нажата", дальше движок смотрит, какие обработчики (функции) ждут это событие/сигнал, и вызывает их как обычные функции. Это позволяет разнести по разным местам генераторы событий и обработчики событий, объединяя их между собой динамически по мере необходимости.
>почему еще весь геймдев не перешел на Годо?
У юнити была агрессивная политика пиара, благодаря которой она за последнее десятилетие заработала бешеную популярность. Хочешь сделать игру и гуглишь "как сделать игру"? В первых строчках выдачи юнити. Ищешь видео по геймдеву на ютубе? Они все про юнити. Ищешь платные курсы? Там всё про юнити. Ищешь вакансии? Кроме юнити ничего нет. Естественно, если ты совсем нуб, то выберешь то, что у всех на слуху. А потом привыкнешь и будешь мириться со всеми недостатками из-за синдрома утёнка и привычек. Большинство юзают то, что им пропихнули хитрые маркетологи юнити, и они довольны этим, потому что нетребовательны. Если бы у Годо была такая же агрессивная политика пиара, он бы легко превзошёл все остальные движки, но откуда у опенсурса деньги на хитрых маркетологов и пиар-компании? У опенсурса есть только преданные поклонники, которые чисто на энтузиазме рассказывают знакомым о том, как им помогает конкретный продукт, но их усилий недостаточно, чтобы превзойти пиар-компании гигантов рынка.
Ну а что касается крупных коммерческих компаний, у них обычно либо свой собственный движок, либо соглашение с одной из таких же крупных коммерческих компаний, там совершенно другой уровень геймдева, не то, что у инди и любителей опенсурса.
Засим предлагаю свернуть это обсуждение, если хочешь делать игры - просто качай движок, читай мануал и следуй туториалам, если что-то категорически не нравится - ищи другой движок, в чём проблема?
>комплексные ноды работают как говно.
Какие именно? KinematicBody пофиксили в 3.4, теперь нормально на движущиеся платформы реагирует.
>Ими никто не пользуется.
Были какие-то опросы?
>Все что больше кнопки или лейбла уродливо.
В каком смысле? Я вот пробовал разные UI элементы - всё нормально, как в старые добрые времена и даже лучше благодаря темам.
>Boolean весит 1 байт
Это во всех языках так, побитовая упаковка флагов - отдельная фича, которая далеко не везде есть, тем более в скриптовых ЯП. Вряд ли тебе нужны огромные массивы флагов в обычной игре, если ты не под микроконтроллеры пишешь.
>Типа выполнение кода с# в первый раз
Это JIT-компиляция. Не используй C#, раз не нравится. В юнити ты вынужден ждать перекомпиляции всех скриптов игры несколько минут, а здесь ты запускаешь игру сразу, без компиляции.
>добавление партиклов в первый раз, некоторых шейдерочков на сцены.
Это ленивая компиляция шейдеров - особенность OpenGL, а не движка. Решается скрытным добавлением материалов на сцену во время загрузки игры, чтобы вызвать компиляцию принудительно.
>Написание 1 буквы вызывает 1 драв колл.
Это уже давно пофиксили 2D батчингом.
>клетке в тайлмапе нельзя задать высоту
Так для этого нужно несколько тайлмапов на сцене, это вроде стандартная практика в изометрических тайловых картах.
>Шейдеры
Все проблемы шейдеров скорее всего из-за поддержки OpenGL 2.1, WebGL 1.0 и OpenGL ES одновременно. Ограничения разных платформ суммируются, иначе кроссплатформы "в один клик" не видать.
На счёт остального не знаю, не сталкивался.
C# или GDScript?
> GDScript
Все пытаюсь перейти на C# (ну как перейти, писал на нем 10 назад) но быстрые итерации
разработки с гдскриптом так расслабляют, что все не перейду.
А ты с какой целью интересуешься?
Для простых задач лучше GDScript ничего нет. Для сложных задач лучше всего писать модули для движка на C++ или использовать GDNative. C# в Godot, по-моему, только для привлечения зумерков, которые ничего кроме юнити никогда в жизни не видели.
Алсо не понимаю, как сочетается опенсурс и порождение Micro$oft, которое суть клонированная Java без блекджека и без шлюх...
интерес больше вызывал выбор пользователей и их отношение к тому или иному языку.
Годаны, расскажите, плиз, как получается распрыжка у спидранеров в старых шутанах? Меня интересует техническая часть. Какую ошибку допускали разработчики ФП-контроллера, что позволяло наращивать скорость при определенных действиях?
> Алсо не понимаю, как сочетается опенсурс и порождение Micro$oft
Человек слаб. Если тебе дают многотысячный донат с условием, что ты их язык нативно интегрируешь в свой продукт, - сложно отказаться.
множитель скорости, которая дамперилась от времени. если множить быстрее чем идет дамперинг - получается упс
> дамперинг
По русски.
>суть клонированная Java без блекджека и без шлюх
Уж что-то, а бэкджека и шлюх в шарпе немеряно. Джава очень убогий язык по сравнению с шарпом, ни перегрузки операторов, ни нормальных дженериков, ни типов-значений, дохрена чего нет.
Возрадуемся.
Алсо включаем галочку "Verbose Stdout" и получаем кучу фиксов какого-то многопоточного затыка.
Алсо включаем галочку "Verbose Stdout" и получаем кучу фиксов какого-то многопоточного затыка.
Все эти ошибки можно описать так - неверная максимальная длина вектора.
Первая была, емнип, в думе - когда идти по диагонали, то есть зажав вперед и влево, было быстрее, чем просто вперед. Это фиксится нормализацией суммы векторов вперед и вбок.
Распрыжка тоже связана с диагональю. Проверялся не общий вектор скорости, а его проекция на направление движения. Таким образом и получается, что скорость больше допустимой, но игра считает, что ты не сильно отклонился от линии взгляда, поэтому все норм. Фиксится тем, что ограничиваешь окончательный вектор скорости, а не промежуточные рассчеты.
Еще один фактор связан с проверкой on_floor. В контроллерах годота она быстро обрастает кучей проверок, и надо следить, когда обнулять скорость через трение.
Можно писать на C# те части, которые потенциально надо переписывать на C++. Тогда, во-первых, их будет проще отлаживать, во-вторых, возможно, не придется переписывать, в-третьих, будет легче переписать, с языка со скобочками, чем с гдскрипта.
Хоспаде, как же много надо знать, чтобы игроки проходили мою игру как я задумал, а не скипали большую часть контента.
Он включает галочку для гладкого геймплея?
Годаны! Как сделать, чтобы при удалении от игрока мобы уменьшали свой ФПС, как в большинстве современных игор, и экономили ресурсы компа?
На ум приходит доропать функции _process по таймеру, что-то типа if timer < distance: return
На ум приходит доропать функции _process по таймеру, что-то типа if timer < distance: return
>как я задумал
Они в любом случае найдут способ сломать игру. Если у тебя в одиночной игре есть, например, валюта, патроны или любое другое часто изменяющееся по желанию игрока число, обязательно найдётся умник, который накрутит её с помощью Cheat Engine. Короче, не парься и делай просто хорошую игру, кому нужно - тот пройдёт её именно так, как ты задумывал.
>мобы уменьшали свой ФПС
>экономили ресурсы компа
А они у тебя точно эти ресурсы потребляют больше необходимого? Что у тебя там за код каждый кадр выполняется, что нужно именно от расстояния зависимость вводить?
Мне на ум такое решение приходит: разделить мир на чанки, каждому чанку назначить отдельный таймер, таймер будет обновлять состояния мобов вместо process. Игрок, приближаясь к чанку, увеличивает частоту срабатывания таймера чанка и снижает частоту предыдущих чанков. Моб, переходя из чанка в чанк, переключается с одного таймера на другой. Связь таймер-моб, разумеется, через сигналы. Такая система позволит избежать вычисления расстояния от моба до игрока каждым мобом каждый кадр, что звучит очень избыточно. В системе чанков переключение таймеров происходит только когда игрок пройдёт некоторое расстояние, сами таймеры не крутят циклы впустую, а переключение с таймера на таймер вряд ли будет частым - но это зависит от размера чанков и поведения твоих мобов.
> Что у тебя там за код каждый кадр выполняется
Селектор стейтмашины, который выбирает стейт по обширному набору входных данных, например, голод-жажда, агрессия, состояние погоды в локации, суета в локации, нахождение враждебных сущностей в зонах обнаружения (видимости, слышимости). Ну и еще там по мелочи.
Оказывается и такое делается:
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 избавляются?
>_process
>выбирает стейт по обширному набору входных данных, например, голод-жажда, агрессия, состояние погоды в локации, суета в локации, нахождение враждебных сущностей в зонах обнаружения (видимости, слышимости)
Зачем тебе всё это каждый кадр проверять? Если у игрока монитор, допустим, 240 Гц, твои мобы будут каждые 4 мс интересоваться состоянием погоды - зачем? Если, допустим, пошёл дождь, менеджер погоды должен разослать всем мобам предупреждение, что они должны изменить поведение соответственно погоде. Желудок моба вполне может обновляться раз в секунду или намного реже, а изменение поведения будет только при определённом % заполненности. "Суета" может проверяться общим для локации менеджером раз в несколько секунд, далее аналогично погоде. Агрессия должна исходить, очевидно, от агрессора. И так далее. Если тебе прям очень нужно все состояния проверять - можно делать это в момент изменения одного из состояний. Так моб, который отдыхает в одиночестве в комнате, вообще не будет ничего делать, пока кто-нибудь или что-нибудь (включая его внутренние органы) не повлияет на него.
Собственно для этого сигналы и нужны, моб подключается слушателем к нескольким разным системам и ждёт сигналов, которые изменят его поведение. Т.е. вместо взгляда в облака каждые 4 мс моб просто почувствует падение капель на его голову, или почувствует, что капли перестали падать. Аналогично с желудком, он почувствует голод, когда желудок переварит пищу, а не будет каждые 4 мс проверять наполненность своего желудка.
Также, насколько я понимаю, для принятия решений не обязательно проверять все возможные параметры. У каждого параметра для каждого решения должен быть приоритет, например, для решения "убежать от врага" параметрами с наивысшим приоритетом будут "присутствие врага" и "состояние здоровья" - тяжело раненный моб попытается убежать от врага независимо от текущей погоды, наполненности желудка и т.д. Это также должно ускорить вычисления, особенно если у тебя сотни/тысячи параметров.
Area.
Когда kinematicbody игрока входит в радиус, включить, когда выходит, выключить повышенный фпс.
Если не хватает, разделить мир на чанки. Включать детектор Area только тем врагам, которые по списку относятся к чанку, в котором находится игрок.
Поддвачну анона, насчет последнего абзаца на эту тему есть готовые аддоны, Behavior tree и GOAP
Алсо можно батчить мобов. Например у тебя 100 мобов, если разделить их на 4 пачки, каждый моб будет выполнять свою тяжелую логику только раз в 4 кадра. Как в 4 тактном двигателе.
> тяжело раненный моб попытается убежать от врага независимо от текущей погоды, наполненности желудка и т.д.
Ну ХЗ, тут бывает на дваче посмотришь иной раз, даже тяжело раненные бугуртом аноны продолжают боевые картиночки постить, надеясь на еду.
> подключается слушателем к нескольким разным системам и ждёт сигналов, которые изменят его поведение
Хм, да. Чего-то я перемудрил с архитектурой. Придётся переделывать.
> готовые аддоны, Behavior tree и GOAP
О, спасибо! Потестим.
>Когда kinematicbody игрока входит в радиус, включить, когда выходит, выключить повышенный фпс.
Area сама по себе повышает нагрузку. Поскольку ему нужно по какой-то причине оптимизировать ФПС логики мобов - причина скорее всего в том, что мобов ОЧЕНЬ много, следовательно, лишние Area в таком количестве вызовут слишком большую нагрузку. В идеале система чанков должна опираться только на простейшие математические формулы, в то время как Area нужна для геометрически сложных случаев.
>даже тяжело раненные бугуртом аноны продолжают боевые картиночки постить, надеясь на еду.
А это уже индивидуальные особенности. Кто-то бежит с поля боя, получив лёгкое ранение, а кто-то сражается до последней капли крови. Для симуляции в игре можно генерировать коэффициенты в формулах в определённых приделах, тогда один моб в первую очередь будет смотреть на своё здоровье, а другой моб - на здоровье врага. Это должно сделать игру более правдоподобной, но при этом намного более непредсказуемой для игрока (что не всегда требуется).
У тебя же не на if'ах логика? Решение должно приниматься суммированием, типа Σ решениеi x коэффициентi, где результат решенияi зависит от внешних обстоятельств, а коэффициентi - это уже индивидуальные предпочтения. Пример: нужно_ли_бежать? = своё_здоровье x 1.0 + здоровье_врага x 5.0 - это агрессивный моб, а если поменять коэффициенты местами - получится моб трусливый. Ну как-то так, я пробовал это делать, но уже не помню подробностей. Решения, если что, можно совмещать древовидно...
>Чего-то я перемудрил с архитектурой
Ты просто взял решение, первым приходящее на ум - брутфорсить все изменяющиеся переменные. К такому все новички приходят, пока не узнают про события/сигналы.
>определённых приделах
Лол, пределах.
>нужно_ли_бежать? = своё_здоровье x 1.0 + здоровье_врага x 5.0 - это агрессивный моб
Что-то я напутал в параметрах... Ну, не важно - в таком виде логику вообще сложно отлаживать, лучше всего вооружиться таблицами, чтобы сразу видеть изменение всех решений во множестве ситуаций, когда изменяешь какой-то параметр.
Эх, как же хочется ИИ в своей игре... Разве я многого хочу?
Если Area сферы, скорее всего там и так просто радиусы проверяются, впрочем можно померить, сколько будет на чистой математике и сколько оверхеда от солвера.
Area в форме сферы, по идее, проверяет все объекты, и реагирует только на те, у которых флаг в определённом слое. И делает это каждый физический тик. К тому же каждая проверка расстояния требует вычисление квадратного корня...
С чанками всё намного проще: целочисленно делишь позицию моба на размеры чанка и получаешь адрес чанка, в котором находится данный моб. И это нужно делать не каждый тик, а только во время движения, чтобы узнать, когда моб перейдёт в другой чанк.
Алсо, метод с Area - это увеличение числа нод и сущностей на физическом сервере по числу мобов, а чанковая система может держать любое число мобов независимо от числа чанков и не зависит от физического сервера.
Но так-то да, нужно проверить на практике.
Почитал issues на гитхабе Godot - я не понял, они планируют отказаться от интеграции Bullet? Просто моей игре GodotPhysics не подходит из-за того, что центр масс нельзя сместить в произвольное место.
Вообще чёт много иссуев, которые висят годами с отметкой "milestone: 4.0"...
Вообще чёт много иссуев, которые висят годами с отметкой "milestone: 4.0"...
>проверяет все объекты
Если там буллет используется, может там уже octotree оптимизирует такое
> проверка расстояния требует вычисление квадратного корня
Обычно сравнивают сами квадраты расстояний, без корня.
>С чанками всё намного проще: целочисленно делишь позицию моба на размеры чанка и получаешь адрес чанка, в котором находится данный моб.
Вообще, отличная мысль, просто кодить лень :3
Буллет будет через нативный плагин.
>Просто моей игре GodotPhysics не подходит из-за того, что центр масс нельзя сместить в произвольное место.
Посмотрел в доках, написано
>With Bullet physics (the default), the center of mass is the RigidBody3D center.
>With GodotPhysics, the center of mass is the average of the CollisionShape centers.
То есть по идее ты можешь добавить какой-то фиктивный collisionshape чтобы сумма центров оказалась в нужном месте.
Какая вероятность, что физика Хуана будет производительнее буллета? Или какие там супер особенности будут?
Ты предлагаешь сделать костыль, который тяжело рассчитать и с которым невозможно предсказать последствия. Вот на буллете я могу добавить в ригидбоди 1000 коллиженшейпов и расположить центр масс ровно так, как хочу, с учётом массы каждого отдельного коллиженшейпа. А с тем, что представляет из себя годофизикс сейчас, я такого сделать не могу...
Годофизикс - это затычка уровня "шоб было". Кому нужна физика, будут подключать сторонние библиотеки...
Да вроде легко рассчитать. У тебя есть сумма центров коллижншейпов, напримеп в точке (5,3). Ты хочешь чтобы цм был в точке (0,0). Для этого тебе надо добавить еще один коллижншейп в точке (-5,-3). При добавлении фигуры пересчитать. Это один цикл и одно вычитание вектора. Для проверки гипотезы про производительность тут работы минут на 15.
Смешная попытка заманить пикселедаунов в свою парашу.
Мне бы конкретные технические особенности, а не субъективное мнение
> Кому нужна физика, будут подключать сторонние библиотеки...
Более того, опенсорц - это движок. Игра опенсорцом быть не обязана, поэтому игроделу ничто не мешает прикрутить через адаптер любую проприетарную физику, например, Newton Dynamics, Tokamak Physics, Havok, PhysX, Meqon, TrueAxis, SPE. Главное, умей в плюсы. Ах, как я завидую умеющим в кресты!
> Ах, как я завидую умеющим в кресты!
а что там сложного в современных крестах?
Ну ни траль, крестовик! Я сколько раз пытался в это вкатиться, ниасиливаю все эти закорючки.
Туда ли ты вкатывался? Там после 11 стандарта все только проще и проще, даже мантры про байтики и ручное выделение памяти уже не работает
Непонятно, к чему ты это пишешь - по-твоему, апи хавока или физ-икс написано после 11 стандарта?
в их апи просто дергаешь функции, там сам ничего тоже не выделяешь вручную, ты бы хоть пописал что ли на них для начала
И хорошо. Чего они там наворотили в четвёрке - лучше вообще отменить. Поломали всё что работало. ГДСкрипт сделали похожим на сишарп. Куча бессмысленных переименований в дереве классов. Вместо запила контейнера для окон они выпилили всю оверлейную оконную систему и перенесли её в оконную систему отдельных окон, пикрелейтед. И теперь если я хочу 2д-дисплей с окнами внутри 3д игры - я иду нахуй. Точнее иду рисовать самодельные велосипедные окна.
В общем, четвёрка очень огорчила. Лучше бы Хуан одумался и отыграл бы всё взад.
> 2д-дисплей с окнами внутри 3д игры
это нужно паре анонов
а вот новый рендер для дерева более эффектинвный - вот это нужно
Измерение в пикселях - это значит, что ты размещаешь все спрайты в пикселях экрана, а не вещественными числами. Если у тебя экран 800х600, ты размещаешь спрайт в точке (200; 150), а не в (-0.5; 0.5). Это помогает делать пиксель-арт игры, потому что все пиксели спрайтов попадают в пиксели экрана, а не размазываются, пытаясь нарисоваться по дробным координатам.
Также есть встроенная функция "увеличения пикселей", т.е. можно один игровой пиксель рисовать четырьмя экранными пикселями или больше. Это тоже полезно для пиксель-арта, потому что позволяет рисовать спрайты с размером пикселей 1х1, а выводить на экран увеличенные пиксели (2х2, 3х3, 4х4 и т.д.). Вообще-то эта функция скорее для снижения нагрузки на видеокарту, такое часто можно встретить в 3D играх (называется "половинное разрешение" или что-то такое), но для пиксель-арта подходит лучше всего.
Спасибо большое, это вот как раз то, что я и хотела услышать
> это нужно паре анонов
Я задал простой вопрос. Почему нельзя было сделать окно контейнер (Viewport/Window на скрине), а всё остальное оставить как есть (в зелёных нодах) чтобы у нас была свобода, (блять фри ас фри бир же, ёпт!) выводить окна хоть через этот контейнер, хоть внутри существующего CanvasItem?
Для справки, то что в юнити этого нет - просто пиздёж.
Ну, вероятно, это с чем-то конфликтовало в архитектуре. Так глубоко я пока не копался еще.
Но вот новые методы рендеринга и физики точно нужны большому количеству анонов, поэтому четверку многие и ждут.
Как в годоте вкинуть в polygon2d тайлсет, вырезать 1 тайл из него и расклонить. Так же было бы неплохо засмузить углы. Нихуя не получается. Где то ещё был примерно такой ассет, но чето найти не могу.
>если я хочу 2д-дисплей с окнами внутри 3д игры
А ты разве не можешь рендерить во вьюпорт и затем накладывать результат как текстуру на любую плоскость? У тебя же на скриншоте окошки во вьюпорте - что мешает получить текстуру с этого вьюпорта? Или в вулкане больше нельзя получать текстуры?
>свобода выводить окна хоть через этот контейнер, хоть внутри существующего CanvasItem
А в чём смысл CanvasItem, если Viewport мощнее и позволяет тебе рендерить текстуру куда угодно? Хоть все модели обклей текстурой с гуёвыми кнопками и слайдерами.
Или Window будет рендерить в отдельный буфер независимо от вьюпорта, в котором находится? Это, по-моему, какой-то баг.
>четверку многие и ждут
Кстати, а почему в четвёрку откладывают все breaking changes? Почему нельзя сначала выпустить 4.0, потом, через полгодика, 5.0, ещё через полгодика 6.0 и т.д.? Ведь такими небольшими шагами будет намного проще портировать игры на следующую версию, чем переписывать всё с нуля из-за одного перехода с 3.x на 4.0. Насколько я понимаю, многие модификации уже готовы к релизу и ждут только выхода 4.0, а так можно было бы быстрее релизнуть их, передвинув остальные фичи на 5.0 или 6.0. Браузеры вон вообще каждый месяц мажорную версию наращивают и никто не жалуется...
>новые методы рендеринга и физики
Мне лично они не нужны. Мне нужны багфиксы. Но они и багфиксы тоже переносят на 4.0. Зачем?
> Почему нельзя сначала выпустить 4.0, потом, через полгодика, 5.0, ещё через полгодика 6.0 и т.д.?
1) потому что у некоторых разработчиков есть крайняя помешанность на обратной совместимости
2) некоторые вещи нельзя исправить без других потому что они взаимосвязаны или это очень трудозатратно, поэтому целые группы вещей остаются до четверки
но многое прямо сейчас спокойно кочует в тройку, поэтому и выходят новые ее версии
> Но они и багфиксы тоже переносят на 4.0. Зачем?
большинство из-за пункта 2
> Viewport мощнее и позволяет тебе рендерить текстуру куда угодно?
Вот в таком конфиге окно действительно
> рендерить в отдельный буфер независимо от вьюпорта
При попытке его включить возникает новое окно, а ожидается, что вообще ничего не должно было произойти, чтобы я потом подключил текстуру в колоррект.
Кроме того, Вьюпорт теперь абстрактный класс, а для вышеописанного тобой рендеринга будет юзаться субвьюпорт пикрелейтед. Который вынесен в отдельную ветвь наследования от окон, пикрелейтед 2.
Надеюсь, что вся четвёрка - это ебучий баг, сраная ошибка, Хуан опомнится и отменит всё это.
четверка - это пока единственный шанс выйти в нормальное 3D сейчас (и это я не про переход на вулкан, а на глобальное изменение внутреннего устройства системы рендера)
>субвьюпорт
Ну и? Юзай субвьюпорт вместо виндоу, в чём проблема-то?
>Хуан опомнится и отменит всё это
И мы будем ждать багфиксов физики в 5.0 ещё лет пять.
>выйти в нормальное 3D
>глобальное изменение внутреннего устройства
Да что вам всем так не нравится? По-моему замечательное 3D, блюр и блум точно есть и работают нормально. Единственный существенный косяк - тени странно себя ведут, никак не могу добиться того, чтобы тень от персонажа не проваливалась под землю...
> в чём проблема-то?
> При попытке его включить возникает новое окно, а ожидается, что вообще ничего не должно было произойти, чтобы я потом подключил текстуру в колоррект.
> рисовать самодельные велосипедные окна.
А мне и сейчас пришлось рисовать свое велосипедное окно. Потому что шрифт из темы не работал с масштабированием, и с кнопками что-то не так было, не помню уже, что-то с хоткеями и esc.
У меня проблем не было. Впрочем, я в принципе не возражаю против велосипедных окон, просто за кодобазу обидно. Всё ж есть. А возьмут и удолят к хуям.
> Да что вам всем так не нравится?
Долго обеснять. Если бы были архивы движкосрач-треда, можно было бы сослаться на них, там периодически, когда толстенные траллищи уставали делать вид, что обижаются на толстоту друг друга, они начинали вести вполне аргументированные споры по вопросу того, что именно не работает, и как оптимизировать. Но увы, тред бесконечный самозатирающийся там.
Если вкратце, то в годоте нагорожены сомнительные велосипеды, хотя индустрия уже предлагала отточенные до уровня паттерна решения. Хуан полез в залупу и отказался убирать велосипеды. А в четвёрке вроде как сдал назад и убрал одни велосипеды, но обязательно накидает новых. Потому что тщетно бытие опенсорсное. И большинству девелоперов придётся выбирать межу релизами точёными из трёшки, и релизами дрочёными из четвёрки. Универсального решения не будет.
В выигрыше будут только крестовики, которым под силу будет взять улучшенный рендер из одной ветки, улучшенные классы из другой, собрать в свой кастомный билд и довольно урча делать игру мечты.
Не, мне нужно просто шоб я сделал многоугольник с помощью area и залил его текстурой тайлов на репите
Многоугольник ты делаешь отдельно, а текстуру ты делаешь отдельно, через шейдер или канву. Не мешай в кучу две задачи.
Может быть вот этот?
https://godotengine.org/asset-library/asset/715
https://www.youtube.com/watch?v=r-pd2yuNPvA
Вчера эту игру на нем упоминали
https://connorrowe.itch.io/fragile-payload-ld49
Гдскриптом все можно описать и сделать?
С одной стороны все, это же тьюринг-полный язык.
С другой, тут один анон хотел иконку в трее, так для этого АПИ нет.
> тут один анон хотел иконку в трее
Тут?
Не, ты наверное что-то путаешь. Это было не тут. Это было в шарпотреде в /пр/
А визуал где рисовать?
пиксели - в aseprite
непиксели - в крите
3д - в блендере
И кстати, если уж хочется из трея управлять приложением, у годота есть OS.shell_open("myTrayAppWithMinerLOL.exe")
Еще нет поддержки нескольких окон, это надо делать несколько приложений и между ними гонять данные.
> между ними гонять данные
Если всё таки вспомнить, что мы в треде игрового движка и предположительно говорим всё таки об играх, то стоит отметить, что играм нужно всего два окна: конфигуратор и само окно с игрой. Запускаешь игру, она ищет конфиг, не находит, открывает окно конфигуратора, создаёт конфиг по умолчанию и, чтобы не раздражать игрока, в конфигураторе сразу посередине есть крупная зелёная кнопка ИГРАТЬ. При нажатии на которую если есть изменения в параметрах, конфиг сохранится, затем игра запускает окно собсна игры, которое при своём запуске читает актуальный конфиг и действует соответствующе. В парадигме тройки даже окна не нужны, конфигуратор - это одна сцена, главная игра - вторая сцена. Всё.
Как-то так.
Раньше встречались игры, стратегии, в которых было много окон и они все двигались и ресайзились, и могли быть поверх или снизу других.
И это были оверлейные псевдоокна внутри одного полноэкранного окна игры. Как сейчас в трёшке. И вместо того, чтобы добавить к существующим оверлейным окнам системные окна, Хуан переименовал их, выпилил из наследников Control и впилил в наследники Viewport. Ужасно. Просто ужасно!
поддержка многооконности для игр и не нужна
1) запускается лаунчер
2) в лаунчере производятся настройки игры или просто нажимается играть
3) лаунчер или пересоздает контекст рендера окна, если требуется выводить на другом типе, либо просто отрисовывает содержимое прямо в том же окне
>И это были оверлейные псевдоокна внутри одного полноэкранного окна игры
Нет, я про оконные игры, которые работали просто в виндоус.
Ты как-то невнятно объясняешь.
>переименовал их, выпилил из наследников 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 секунды на открытие модального окна, лол), то это, конечно, ещё хуже, чем глючная имитация внутри единственного окна.
Револбшн уже скоро?
> В ЧЁМ ТВОЯ ПРОБЛЕМА?
В том что я щупаю реальную сборку четвёрки, а ты читаешь манядокументацию, думая, что переключение с latest на stable - это истина.
Вчера ещё одну интересную вещь заметил. Подсказки в щупаемой мною сборке тоже переделаны на графический контекст и захватывают фокус, если быстро елозить мышкой по окну настроек, и попасть на всплывшую подсказку и щёлкнуть, то она ворует клик и не происходит переключения на ожидаемый пункт настроек. Раздражающе.
Пойду свежую сборку скачаю, а то вдруг там уже всё откатили взад, а я тут ругаюсь почём зря.
> Впрочем, если новые попыты окажутся не системными, а созданием нового графического контекста
Это и не должно быть в играх вызовом реальных системных. Потому что разработчик почти всегда для игры делает свой стиль, поэтому у него должна быть собственная реализация любых игровых окон так, как ему нужно отрисовывать для конкретно его приложения\игры. Поэтому похожесть окон на системные будет добиваться схожестью стиля, установленного в ОС при необходимости, но технически вся новая отрисовка будет на новом рендере
В свежей сборке пофиксили
> захватывают фокус, если быстро елозить мышкой по окну настроек, и попасть на всплывшую подсказку и щёлкнуть, то она ворует клик и не происходит переключения на ожидаемый пункт настроек
Претензия снимается.
> попыт?
> ПОПЫТ
> В ЧЁМ ТВОЯ ПРОБЛЕМА?
> вместо родного color picker'а винды я вынужден бороться с каким-то глючным говном
Вот! Вот это "глючное говно" является контентом, который собран на нодах, вот хотя бы к нему Хуан должен был оставить доступ. Обесню на рисунке, чтобы было внятно: пикрелейтед. То есть, никаких диалогов не переносится в новую ветку. Всё остаётся на своём месте. Создаётся вьюпорт и окно, а в окно можно выводить любой контент. Почему Хуан так не сделал? Я описал выше. Он настойчиво игнорирует открытия в области кодинга, и делает сомнительной адекватности велосипеды. Он должен был оставить оконный класс и возможность выводить в него контент, в том числе запросить системное окно в системе и скормить своему оконному классу хендл этого окна, как делают все, когда надо показывать платформ-специфичнное окно, разное в разных платформах. При этом оставалась бы возможность выводить в отдельное окно как брендированные авторские диалоги, так и любой авторский контент.
> Это и не должно быть в играх вызовом реальных системных
Согласен. Но на годо нынче можно и приложения писать. Знаменитый клон асепрайта - пикселорама - написан на годо.
Да и в приложениях это тоже нахуй не надо. А то раньше приложения любили распадаться на триста отдельных окошек, как тот же гимп - нахуй это вообще надо?
Разобрался в вопросе. Претензии снимаю все вышеизложенные. Оказывается! В проекте! На уровне настроек/конфига есть опция EmbedSubWindows которая если true выводит попапы в стиле трёшки, оверлейно. Это снимает все мои вопросы к новой системе.
> нахуй это вообще надо?
Для мультимониторобогов. На основном мониторе кидаешь вьюпорт со сценой, на дополнительном мониторе размещаешь инспекторы, табы, листы, тулзы.
> Но на годо нынче можно и приложения писать
в подавляющем числе приложений также не нужны отдельные физические окна, поэтому игровому движку можно не усложнять архитектуру под ряд этих специфических задач
> не нужны отдельные физические окна
Зачем Хуан их сделал в четвёрке?
Чтобы ты не плакал.
> Зачем Хуан их сделал в четвёрке?
Они в SDL2 есть по умолчанию, поэтому добавить не сложно
>EmbedSubWindows
Ясно, был один стул, стало два (embed дрочёные).
>пофиксили
А на ссылку в подсказке уже можно нажать?
Вот что в следующую шапку пойдёт.
https://docs.godotengine.org/en/stable/getting_started/workflow/assets/escn_exporter/index.html
А я вот такой сегодня поставил
https://github.com/V-Sekai/godot-blender
Надо только в настройках проекта путь к blender.exe указать.
Потом просто закидываешь .blend в папку и импортируется.
Тоже ЗБС. Чем больше возможностей - тем лучше.
Репост из ньюфаг треда. Сел за godot, первый день, нарисовал карту 2д, персонажа, джойстик управления и кнопку. Когда я перемещаю персонажа, камера двигается за персонажем а кнопки остаются на месте. Даже не знаю как гуглить. Руководствовался https://youtu.be/oeC_3l0tODg.
Мой высер.
https://github.com/learngodot/test1.git
А, все, спс. Заработало. Прицепил к родительскому элементу кнопку и получилось.
>камера двигается за персонажем а кнопки остаются на месте
Тебе нужно это: https://docs.godotengine.org/en/stable/tutorials/2d/canvas_layers.html
>Даже не знаю как гуглить
>Руководствовался
Прежде чем гуглить и проходить туториалы на Ютубе, почитай сначала официальный мануал (частично переведён на русский, но лучше читать на английском), особенно это: https://docs.godotengine.org/en/stable/getting_started/step_by_step/index.html
Большинство вопросов сами собой отпадут.
>Прицепил к родительскому элементу кнопку и получилось.
К какому именно? Могут возникнуть проблемы, когда попытаешься приближать/отдалять камеру. CanvasLayer позволяет рендерить GUI независимо от игровых объектов.
Спасибо.
И тебе Спасибо.
Я пока по туториалу за пару дней первый раз пробну что-то сделать, посмотреть по себе. Если зайдет эта движуха, стану gdscript учить и оф доки курить.
Очень тяжело пока ориентироваться в игровом физ пространстве, векторах, осях и т.д. Надеюсь, скоро будет легче.
Давно уже хотел чем-то эдаким заняться, буду реализовывать хотелки.
>тяжело пока ориентироваться в игровом физ пространстве
Если у тебя 2D, то "пространство" - это просто лист бумаги. Ты можешь сложить несколько полупрозрачных листов вместе и двигать их независимо друг от друга (параллакс), но вся игра у тебя будет происходить всегда на одном листе, остальные только для декораций (если не придумывать каких-то необычных механик).
>векторах
Специальный туториал поможет: https://docs.godotengine.org/en/stable/tutorials/math/vector_math.html
Ну и в старшей школе вроде должны были это давать.
>осях
В 2D оси как в геометрии из средней школы, только Y перевёрнута из-за особенностей вывода графики на экран, т.е. точка (0;0) в левом верхнем углу экрана (так было принято ещё в прошлом веке - потому что строчки пикселей на экране нумеруются сверху вниз). Но привыкнуть легко.
>буду реализовывать хотелки
Если есть некая концепция игры, лучше сначала записать все идеи как "дизайн-документ" (удобнее всего в формате вики, рекомендую попробовать TiddlyWiki), чтобы потом не забыть ничего. Потому что любая идея реализуется достаточно долго и занимает собой всё внимание, поэтому легко потерять другие идеи в процессе реализации одной из них. Также любую задумку нужно разделять на мельчайшие компоненты и реализовать их, а не абстрактную "идею", так будет легче (это называется декомпозиция). Собственно поэтому вики-движок удобнее для записи, т.к. позволяет описывать идею и её части по отдельности, соединяя ссылками в любую структуру.
> TiddlyWiki
Есть что-нибудь попроще, оффлайновое? Это тоже можно заставить работать локально, но там нужно свой локальный сервер поднимать. Нахуй так сложно?
другой анон
З.Ы. Я давно уже ищу компактное и простое оффлайн-приложение для организации диздока в виде гипертекста (зумерск. вики), скоро я потеряю терпение и напишу его себе сам, на годоте!
>попроще
В каком смысле? На мой взгляд, TiddlyWiki максимально проста, если не учитывать необходимость в браузере. В сжатом архиве пустая вики весит меньше 400 КБ.
>оффлайновое
Просто открываешь .html файл в браузере и работаешь локально. Никакой сервер не нужен, можно даже на телефоне открывать и всё будет работать почти как на компе. Сохранение происходит путём "скачивания" копии .html файла по нажатию кнопки на странице - не очень логично, но удобно в контексте бекапов. Собственно, сам .html файл может быть где угодно, например, на флешке или удалённом жёстком диске, главное чтоб браузер разрешал протокол file:// или content:// (на Android недавно запретили браузерам читать .html через file://, но по-прежнему можно открывать через файловый менеджер, поддерживающий создание content:// ссылок).
Вообще, просто почитай официальный сайт: https://tiddlywiki.com/ - можешь его прямо сейчас скачать себе (значок в виде галочки внутри окружности, меняет цвет на красный, если вносишь изменения) и открыть оффлайн, лол. Я так и сделал, схоронил копию сайта себе на комп и на телефон, т.к. там справка по многим фичам и будет жалко потерять к ней доступ.
>гипертекста (зумерск. вики)
Вики - это не гипертекст. Вики - это сайт с определёнными свойствами, отличающими его от других сайтов. https://ru.wikipedia.org/wiki/Вики
В случае с TiddlyWiki это не совсем сайт, это просто один .html файл, который хоть и можно разместить на сайте, но не обязательно.
>напишу его себе сам, на годоте
У TiddlyWiki преимущество в том, что тебе нужен только браузер, чтобы её открыть - сможешь открыть на любой платформе, где есть браузер с JS (кроме разве что древних версий браузеров). Т.е. не нужно таскать с собой несколько версий приложения и отдельный файл с записями. Плюс вся мощь JS для создания своих собственных фич прямо внутри работающей вики...
Я как-то тоже хотел свой велосипед сделать, но потом осознал, сколько труда вложено в проект вроде TiddlyWiki и решил не тратить время зря на глупые хотелки.
Некоторые даже пробуют использовать TiddlyWiki как игровой движок, например, текстовые игры относительно легко делать...
> не нужно таскать с собой несколько версий приложения и отдельный файл с записями
У меня один комп и одна платформа. Не нужно ничего таскать. Ладно попробую почитать сайт ещё раз.
>Вики - это не гипертекст. Вики - это сайт с определёнными свойствами, отличающими его от других сайтов.
Тут вот это больше подходит: https://ru.wikipedia.org/wiki/Персональная_вики
>...однопользовательские вики-приложения, не имеющие веб-сервера и сервера баз данных.
>TiddlyWiki — вики-движок и вики-концепция, заключающаяся в том, что весь вики-сайт представляет собой одну HTML-страницу, интерактивность которой обеспечивается сценариями.
Ну и там ещё целая статья про саму TiddlyWiki.
Мне лично очень зашла своей компактностью, дизайном и возможностями. Полноценный сайт, только оффлайн без сервера. Есть недостатки или особенности работы (к примеру, нерационально вставлять большие изображения в сам .html, их нужно хранить отдельными файлами; сложно организовать совместное редактирование), конечно, но мне они не мешают.
Нет. Не моё. Попробовал ещё раз, накидал пару тидлеров. По ссылкам друг на друга не открываются. Почему? Нет желания разбираться. Хотелось просто писать текст в одном окошке, и где надо обрамлять [[ссылки]] двойными скобками, чтобы автоматически создавались статьи, потом щелкать по ссылкам и ебашить текст туда. Скачанный хтмл у меня в ффоксе не работает. Может для этого нужен зумерский пориджехром? Не знаю. Похуй. Буду искать дальше.
Ну ладно, разобрался, тидлеры создаются. Ну ХЗ. Будем посмотреть.
1. Зачем нужен physical_scancode? Для лягушатников с AZERTY вместо QWERTY?
2. У set_as_toplevel() нет подводных? Нода остается в дереве, но при этом движется как будто прикреплена к корню дерева?
2. У set_as_toplevel() нет подводных? Нода остается в дереве, но при этом движется как будто прикреплена к корню дерева?
Щас будет боевой клич безыгорника... РРЯЯЯЯЯЯЯЯ!
В ветке 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 кажется более взрослым и серьёзным.
>Но стоит только RigidBody проснуться, и он будет отлетать от KinematicBody.
https://kidscancode.org/godot_recipes/physics/kinematic_to_rigidbody/
1. Если будешь публиковать в Стим или на любую другую международную платформу, рано или поздно придут игроки, которым твоя дефолтная раскладка не даёт нормально играть, а сменить некоторые клавиши, допустим, невозможно, или ты поленился делать меню смены раскладки. Или может быть какая-то проблема с раскладками в, например, линуксе. Короче, гораздо надёжнее опираться на сканкоды, потому что сканкод - это адрес физической клавиши, не зависящий от системной раскладки и надписей на клавише. В теории сканкоды у всех современных клавиатур одинаково расположены, не считая кастомных.
2. Попробуй сам и увидишь. Ещё поищи по issues на гитхабе, там может быть полезная инфа. А зачем тебе эта фича? Имхо, если тебе нужно двигать какую-то ноду в глобальной системе координат, для этого нужно или конвертировать координаты (to_local() или global_transform), или размещать эту ноду в другом месте.
>сканкоды
В том то и дело, что какую-то новую систему добавили, есть сканкоды, а есть физические сканкоды, а описание не гуглится.
>2 А зачем тебе эта фича?
Есть объект который то летает в глобальную координату, то возвращается привязанный к игроку. Раньше я перецеплял ноды remove_child add_child через call_deferrer, если это все можно заменить одной строчкой будет удобно, интересуюсь может пользовался кто.
Ну и что ты мне эту ссылку тычешь? Я уже тыщу раз этот туториал видел. И даже сделал тычки RigidBody как там описано. Проблема не в этих тычках, а в том, что RigidBody в Bullet САМОСТОЯТЕЛЬНО отлетает от KinematicBody, если sleeping == false, хотя этого происходить не должно и в GodotPhysics это не происходит, за исключением случаев "KinematicBody залез на RigidBody", в которых происходят глюки.
Смотри что получается. Вот у меня есть в сцене большой мячик и маленький кусочек сыра.
1. Если я выберу Bullet, я могу пройти по кусочку сыра и ничего не произойдёт. Но мячик будет отлетать от игрока очень далеко из-за того, что излишне реагирует в пробуждённом состоянии.
2. Если я выберу GodotPhysics, мячик будет нормально отлетать с фиксированной силой. Но если игрок случайно или специально пройдёт по кусочку сыра, этот кусочек заглючит и вылетит из-под него в неизвестном направлении с высокой скоростью, а мячик в той же ситуации будет трясти игрока во все стороны.
И это ещё не говоря о дверях, которые в первом случае неадекватно отлетают, а во втором случае могут зажать намертво и хрен знает как эту ситуацию распознать из кода...
>какую-то новую систему добавили
Добавили только "физические клавиши" в меню действий.
>есть сканкоды, а есть физические сканкоды
Ты, видимо, говоришь о scancode в InputEvent? Там это как было, так и осталось. Но теперь можно привязывать к действиям эти сканкоды из меню, что удобнее. "Физическими клавишами" это называли, скорее всего, для новичков, которым будет непонятно название "сканкод".
>летает в глобальную координату, то возвращается привязанный к игроку
В смысле "летает"? Если это какой-то дрон, который игрок может взять в руки и запустить в самостоятельный полёт, то логичнее использовать add_child/remove_child, потому что этот дрон в свободном полёте является независимой от игрока сущностью. Если, например, тебе потребуется реализовать сцену в подвижном помещении типа грузовика, то дрон должен будет двигаться вместе с грузовиком, а не в глобальной системе координат. ИМХО.
Он отлетает в момент пробуждения? Когда sleeping меняется с false на true? Может быть просто отследить этот момент и сбросить векторы?
>Там это как было, так и осталось. Но теперь можно привязывать к действиям эти сканкоды из меню, что удобнее. "Физическими клавишами" это называли, скорее всего, для новичков, которым будет непонятно название "сканкод".
Там теперь есть И сканкод, И другая сущность физический сканкод.
>логичнее использовать add_child/remove_child,
Я и так знаю как сделать на add_child/remove_child, вопрос был в том нет ли глюков или подводных в set_as_topdown. С грузовиком проблем не вижу, дрон или на игроке, который может ехать на грузовике, или трекает глобальную цель, которая может быть или не быть привязана к грузовику.
Хотя я понял про что ты, типа дрон 5км/с в закрытом поезде 100км/с, да пожалуй это подводный, спасибо
>Он отлетает в момент пробуждения? Когда sleeping меняется с false на true?
Нет же. Это уже давно известный баг. Если sleeping == false, то флаг "infinite_inertia = false" тупо перестаёт работать, как если бы он был true.
>Может быть просто отследить этот момент и сбросить векторы?
Куда их сбрасывать? Если мячик катится мимо KinematicBody и сталкивается с ним, он должен отскочить от него как от StaticBody (т.е. как от другого RigidBody с бесконечной массой), а не улететь за горизонт из-за неработающего флага infinite_inertia. А если сбросить вектор скорости, он остановится на месте.
>другая сущность физический сканкод
Где?
>дрон 5км/ч в закрытом поезде 100км/ч
Да, именно так.
>причем тут 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 на самом деле телепортируется (с точки зрения физического движка), а не симулирует полноценное физически точное движение.
> Я даже слышал мнение, что "в игре могут быть только кинематики или только ригиды", но это бред какой-то.
Поставлю галку, чтоб меня не перепутали с каким-нибудь движкосрачером.
Я слышал, что в других движках вообще нет никакого кинематикбоди. Есть только ригидбоди и режим кинематик у них, если тебе нужно. Попробуй копнуть в эту сторону.
>когда не спит - буянит из-за воздействия KinematicBody
Что, даже с infinite_inertia по ссылке?
Ты троллишь или просто нуб?
https://github.com/godotengine/godot/issues/31981
Этому багу уже почти 3 года. Пофиксили в 4.0, вроде бы, благодаря введению односторонних взаимодействий через слои. Хотя логика всё равно... странная, теперь, получается, важен порядок слоёв.
>нет никакого кинематикбоди
>ригидбоди и режим кинематик
Ну да, да, кинематик - это ригидбоди с бесконечной массой, то есть его никто с места столкнуть не может, кроме кода. Я как раз на днях читал в иссуях годо обсуждение изменений, которые уже внесли в 4.0: теперь нет никакого отдельного "кинематикбоди", есть только статик, ригид, и... "чарактер", который наследует иконку кинематикбоди:
https://docs.godotengine.org/en/latest/classes/class_characterbody3d.html
Кстати, "чарактер" есть как минимум в юнити. В юнити я пробовал, там суть практически та же, так что переименование логичное. Но лучше всего то, что теперь все параметры move_and_slide уехали в свойства объекта, где им и место.
А у ригидбоди, который теперь ригиддинамикбоди (лол), убрали выбор режима и сделали галку "заморожен" и "режим заморозки" - статик и кинематик. Вроде логично. Также добавили возможность ПРОСТО указать центр масс в виде вектора, не извращаясь с переносом коллиженшейпов или добавлением ещё одного.
Также добавили аниматаблебоди, который наследуется от статикбоди и содержит галочку, которая раньше была у кинематикбоди (синк ту физикс). Типа чисто для платформ, дверей и т.п.
Вспомнить бы ещё ту школьную программу, когда тебе под сраку лет а в 90х в школах ничему не учили.
В целом то я понимаю все. Просто когда я смотрю туториалы, где автор так свободно и уверенно оперирует математикой а мне даже не то, что требуется время чтоб переварить и обрисовать в голове для понимания, а осознание, что самостоятельно я и не додумался бы до этого. И это элементарные вещи, типа движений npc. Думаю, с опытом будет проще.
Сейчас расписал себе месяц на подготовку. За недельку - две пройдусь по оф документации. Ещё пара недель пересмотрю туториалы на ютубе по своей теме и возьмусь за дело.
Тоже думаю себе вики завести, и набросать там ООП шаблон, которому буду следовать, чтоб потом не переделывать.
Уважаемые знатоки, а вот этот абоминасион кто-нибудь пробовал?
да, Lua пробовали и теперь используем
Покежь кусочек рабочего кода на луа. Оче охота сравнить с гдскриптом.
Хотелось бы взглянуть на более длинный код чем две строки. Строк на 100 хотя бы.
Unity
Мне нужен пример адекватного арканоида для создания, в ассетах не нашёл, нашёл только урок на тытрубе, всё нормально, кроме того, что там управление клавой, а не мышью, я сделал как хочу, но получается просто пиздец как криво.
Где или как искать?
кто-то пробовал делать графоний уровня скайрима?
А разве годо не для 2д? Если уж графин, то лучше унити, он больше по 3д
а что именно криво?
сделать типа:
global_position.x = get_global_mouse_position().x
унити точно ничем не лучше
для чисто 2d как-то жирновато
Криво кинематические объекты, я подобную игру могу сделать и на С++ без проблем, но беда именно с пониманием того как всё устроено в годоте, делать хуету платформер неинтересно.
А вот хочется сделать арканоид с меню, настройками разрешения, графона, может быть клавиш, понятное дело, что всё это фигачить с нуля такое себе, а тут готовое.
Забил я на кинематики пока и повторяю за испанцем area2d
С мышью особых проблем не возникло, просто удивило, что бля клавишами двигать платформу, видать сложно или нудно ему показалось.
Ну и странно, что пока с камерой не возится, а это как бэ тоже важно - масштабирование в зависимости от разрешения там, соотношения сторон моника и тд.
Для 2д пока топчик, хочу попробовать потом бахнуть сапёр, ато на шарпе и винформс лагат, а в впф чот не хочется совсем пока.
Кароч, уроки есть, ассеты видал, но пока что видал, то слишком тривиальное и именно для создания полноценной игры, а не окошка демкой чот не вижу, что печально.
На данный момент я так воспринимаю, ибо в унити можно бахнуть вычислительные шейдеры, я на них воксели сделал, но как же я матерился, что нету готового урока по этому, опездолы блядь цпу воксели рисуют с охуевшим видом и это выдают за открытие, и это я молчу про то как красить их попиксельно. Просто пиздец конечно сейчас разрабы попёрли.
спасибо, но если бы выбор пал на другой движок, то уж с гораздо большим приятием он бы пал на UE, где это все делать гораздо приятнее
> где это все делать гораздо приятнее
Сверхчеловек, ты?
Я вот попробовал на уече, да, вроде всё нарм, только он тяжёлый и не всегда понятный, унити после него просто супер лёгкий и удобный по ощущениям. А уж делать POM на нодах было и весело и жутко.
Не спеши графон делать, обрати внимание на новые ниппон игры, там авторы не ебут мозги и делают мелкие, но хорошо проработанные локи вместо унылого и пустого огромного мира. Мне нравится такая концепция создания игр и я стараюсь идти этим путём. Пусть мелкая игра, но пездатая.
Например:
ты просто охренеешь делать детализированную деревушку с травой, десятью домами, церквушкой, забрами, плодовыми кустами и деревьями, ручьём и живностью. Про мир с несколькими такими и даже городом тут и говорить нечего. Задача намного сложнее чем кажется.
> Я вот попробовал на уече, да, вроде всё нарм, только он тяжёлый и не всегда понятный
а что там тяжелого-то? всякие логические связи пишешь нодами как и для дизйнеров пишешь новые ноды под игру, им только ползунки дергать да простейшую логику клепать
нагруженные алгоритмы в плюсах сразу
> Не спеши графон делать
я и не спешу, вопрос был в том, что вытянет ли годот сейчас графоний открытого мира типа ванильного скайрима или пока не рисковать на него спрыгивать, потому что кучу всего для рендера самому еще дописывать придется
> обрати внимание на новые ниппон игры
ну это на стадии разработки проекта геймдизайнерами требуется, а сейчас уже другая, где с технологиями определяемся под уже написанный диздок
>ты просто охренеешь делать детализированную деревушку с травой .. Задача намного сложнее чем кажется.
я и не буду, этим моделлеры и дизайнеры занимаются уже
> вытянет ли годот сейчас графоний открытого мира типа ванильного скайрима
Годот вытянет.
Ты - не вытянешь.
Только сейчас я понял, что он вышел в 2011 году. Я не знаю умеет ли годот рисовать большие миры с подгрузкой и без лагов.
> нагруженные алгоритмы в плюсах сразу
Для годота это тоже верно.
Ебашишь нагруженные алгоритмы в адаптеры, наследующиеся от Node в Godot API, в том числе тянущие API твоих или третьих библиотек, фреймворков, систем. Далее вкомпилировываешь свои модули в движок и юзаешь.
Но!
> умеет ли годот рисовать большие миры с подгрузкой и без лагов
Умеет.
Ты не умеешь. Потому что ты ебанёшь подгрузку чанков в один поток с основным деревом сцены и будешь визжать про тормоза, и трясти скрином настроек, где ты включил поддержку многопоточности. Выкатывайся уже давай в свой загон. Не доводи до репорта.
Не, я не тот челик, ты попутал
Хорошо если так.
Ты лучше мне ответь, а если в годоте автоматическая преобразовалка в многоугольник для столкновений некого 2д изображения на основе его прозрачности.
> Ты - не вытянешь.
столько много в рендере придется переписывать по сравнению с UE ?
> Ебашишь нагруженные алгоритмы в адаптеры, наследующиеся от Node в Godot API, в том числе тянущие API твоих или третьих библиотек, фреймворков, систем.
да, пробовал, делал, но хотелось бы меньше всего с той частью, что отвечает за рендер и его оптимизацию
Еще вот такое, у этого исходники выложены, но там сделано в Qodot (редактор карт квейка), а он мне не нравится.
https://github.com/sunkper/Project-Summer-Island
А это Andrea Catania пилит на 4, но у него много своих доработок движка. Год пилит, кажется.
https://www.youtube.com/watch?v=UAxTtXeAaFk
а на последних двух видосах не знаешь сколько треугольников и дравколов?
Ах да, чуть не забыл Sandfire
Автор выкладывал демку год назад
https://kmitt.itch.io/sandfire-014
https://www.youtube.com/watch?v=mmyH07FN_3U
Гюд
Не заметил, а специально искать некогда.
Еще сейчас глянул индус пилит свою Чакравьюгу, не забросил.
https://www.youtube.com/watch?v=uuJmHQhmZ5M
Надо взять и проверить
Ассет для фоновой загрузки есть.
https://godotengine.org/asset-library/asset/709
Либо
https://godotengine.org/asset-library/asset/530
Прекомпилятор шейдеров вроде уже в коре 3.4.1, либо ассетом
https://godotengine.org/asset-library/asset/977
Остается понять, как лучше нарезать на чанки, плюс подготовить модельки и материалы.
Ах да, еще LOD, но там тоже есть варианты (хотя скорее всего делать свой)
Да, спасибо.
Краткий гайд по вкату в движок:
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
Предыдущий:
Архивный: https://arhivach.net/thread/682305/