С изучения документации. Если не можешь в инглиш, и даже в гугл-переводчик, то продолжается перевод официальной документации: https://docs.godotengine.org/ru/latest/
Но вообще, будь мужиком и изучи английский: https://docs.godotengine.org/en/stable/
Вместе с движком обязательно смотри примеры, там есть всё - от платформера до чата. Примеры качаются прямо в движке через свой магазин.
Скачать движок: https://godotengine.org/download/ или http://store.steampowered.com/app/404790/Godot_Engine/
FAQ: https://docs.godotengine.org/ru/latest/about/faq.html
Игры, созданные глобальными кириллами: https://godotengine.org/showcase или https://steamcommunity.com/app/404790/discussions/0/412448792354265655/
Скажи "Годот круто!" https://github.com/Calinou/awesome-godot - подборка дополнений, модулей и минишоукейс от одного из авторов.
Годнота от анона:
Для приверженцев опенсорца существует возможность распространять проекты в незапакованном формате. Просто скачай темплейт с оф.сайта и положи экзешник/эльфешник в папку с проектом, этого достаточно. Дополнительно можешь вшить свою иконку в экзешник. После этого, запустившийся файл темплейта обнаружит рядом с собой файл project.godot и начнет грузить проект из него и из файлов, лежащих в распакованном виде в той же директории.
В версии 3.2 появилась возможность прикреплять pck к бинарнику. Бриллиант для любителей однофайлового продукта!
Редактор персонажей на основе makehuman: https://github.com/Lexpartizan/Go_MakeHuman_dot
Все языки в одном месте: https://vk.com/topic-70467171_35982467
Тест-бенчмарк:
Веб-версия - https://govdot.herokuapp.com
Вишмастер для винды - https://govdot.herokuapp.com/4Anon.rar
Предыдущий тонет там: >>643188 (OP)
Архивы:
1 http://arhivach.ng/thread/207802/
2 http://arhivach.ng/thread/388500/
3 http://arhivach.ng/thread/388501/
4 http://arhivach.ng/thread/388502/
5 http://arhivach.ng/thread/388503/
6 http://arhivach.ng/thread/432708/
7 http://arhivach.ng/thread/433902/
8 http://arhivach.ng/thread/436355/
9 http://arhivach.ng/thread/455461/
10 http://arhivach.ng/thread/479963/
11 http://arhivach.ng/thread/489815/
12 http://arhivach.ng/thread/494513/
13 http://arhivach.ng/thread/515567/
14 http://arhivach.ng/thread/533171/
Видос в шапку не забудьте плиз
https://www.youtube.com/watch?v=BAsVI-Yv928
Так я и не программист ._.
> func pause_game(state : bool = !get_tree().paused):
> > get_tree().paused = state
Ответ, что функция делает - под спойлером. Сначала догадайтесь сами.
Когда вызываешь функцию без параметра, она работает, как переключатель. На входе получается инвертированное состояние паузы. Однако, ты всегда можешь вызвать функцию с явным параметром, и она уже сработает как включатель: либо гарантированно включит, либо гарантированно выключит.
> Вдруг там кешируется значение, а не вызывается по честному функция.
Ну, вроде как.
Похоже ни на что. Я особо не вникал, камеры работают примерно по таким правилам: камера рендерит в ближайший вьюпорт выше по дереву (таким образом можно рендерить в текстуру для постпроцессинга), если вьюпорта нет, рендерит в главное окно, если камер несколько, то надо ставить только одной current=true, если current у нескольких, то наверное работает более поздняя по списку (не знаю, гарантируется ли это). Например, если добавить контроллер игрока (сцену с камерой), и после него еще камеру, то включая current у последней, можно включать/выключать вид "извне" на игрока.
Пытаюсь сделать выхлоп дульных газов. Но пока не понимаю, как сделать некоторые вещи, буду рад совету или (лучше) подходящему видеотутору. Что я уже посмотрел, там эти вопросы не освещаются.
а) Чтобы частица поворачивалась вместе со стволом. Вот я поворачиваю ствол, источник и направление полёта частиц вертятся вместе с ним; но сами спрайты не поворачиваются. В материале есть настройка Angle, можно фиксированно развернуть спрайт, и он в таком виде будет стрелять в любую сторону. Неужели это придётся кодить? Было бы очень неудобно.
б) Не нахожу никаких настроек прозрачности. Это же дым, он должен не резко исчезать, а постепенно. Но чёт не вижу такой опции. Это странно, вроде ж первейшее применение для партиклей. Сама картинка полупрозрачная, но этого мало же.
в) Как заставить её выплёвывать ровно по одной частице ровно тогда, когда мне нужно? Есть выключатель вкл/выкл, но он работает как-то по-своему, не начинает испускать частицы сразу по включению, а чего-то ждёт. В режиме ваншот после испускания всех частиц источник не хочет включаться вообще, и это типа фича.
Бамп
Вот тут описан хак как пропукивать их при загрузке сцены
https://www.reddit.com/r/godot/comments/e7sf82/godot_background_loading_tutorial/
Но всё равно основной поток при этом висит.
У него нет метода "рестартить", есть только свойство вкл/выкл. Ваншот работает так:
1. Включаем
2. Ждём, пока эмиттер поссыт
3. Ждём, пока умрут все партиклы
4. Эмиттер выключаеся сам, ни в коем случае нельзя его торопить
5. Только после этого можно попробовать заново его включить, и он, может быть, включится.
Да и если бы он просто работал так, как задумано, в любом случае, для автоматического оружия не подходит, потому что у него дым от предыдущего выстрела не успевает рассеяться перед следующим.
Пока что я использую костыльное решение без ваншота: просто подгоняю темп испускания частиц под темп стрельбы и выключаю, когда игрок отжимает кнопку или кончаются патроны. Но это не подходит уже для медленного оружия, когда время жизни пороховых газов меньше времени до следующего выстрела.
Не очень понял вопрос. Создаешь не Shader Material, а Spatial Material, там всякие цвета и текстуры. Но внутри там шейдеры. Ты имеешь в виду, есть ли специальный рендерер типа как GL1, с glBegin/End? Думаю нет. Примитивы рисования какие-то доступны, конечно. drawLine и т.д.
Прочитал жопой
@
В З О Р В А Л С Я
Специально для тебя повторю задачу: сделать дульную вспышку, которая будет адекватно отрисовываться при любом темпе стрельбы. Поведение вспышки:
1. Единовременно испускается в момент выстрела
2. Испускается после каждого выстрела, а не после некоторых
3. После испускания некоторое время рассеивается в воздухе
4. Последующие выстрелы и вспышки никак не влияют на поведение уже выпущенной
5. Следующий выстрел может быть произведён раньше, чем рассеется вспышка от предыдущего, это тоже не должно на неё повлиять.
Это точно такой же костыль, как те два решения, которые я уже придумал:
1. Поставить ваншотный таймер с маленьким временем. Выстрел - партиклы запустились, таймер включился; таймер протикал и выключил партиклы.
2. Для каждого оружия выставляются свои параметры для партиклы, соответствующие скорострельности данного оружия. Партикла включается с началом стрельбы и выключается с концом.
Но хотелось бы что-то менее костыльное. Наверняка в партиклах есть какая-то подходящая опция, просто её расположение не очень очевидно.
2д-персонаж анимирован из кусочков. Наделал ему кучу анимаций: отдельно для ног и туловища, отдельно для рук и головы. Ко всему этому подвязал AnimationTree, нарисовал там сложное дерево с вложенными стейт-машинами. Теперь пытаюсь это всё заставить работать.
Пока что впечатления: дерево анимаций - очень мощная штука. Завтра, видимо, весь день потрачу на то, чтобы привести в порядок взаимодействия с ней.
>если добавить контроллер игрока (сцену с камерой), и после него еще камеру, то включая current у последней, можно включать/выключать вид "извне" на игрока.
У меня наоборот получалось. Player со своей камерой должен стоять выше остальных сцен с камерами, активной по умолчанию становится первая вошедшая в сцену камера.
>надо ставить только одной current=true
По-моему проще вызывать make_current(), а свойство current использовать только для чтения.
>Player со своей камерой должен стоять выше остальных сцен с камерами, активной по умолчанию становится первая вошедшая в сцену камера.
Ты прав, но и я тоже прав, ты пишешь про то что если нет ни одной current, то рендерится с первой по списку, а я пишу о том, что если нескольким камерам поставили current, то из них побеждает более поздняя. Проверял в 3.2.1
Блять, не отвлекай меня от ТВГ! Так не устроит штоле?
Я вот не уверен что это костыль. У тебя что, персонаж неподвижен? Если предположим 3д шутер, и во время стрельбы персонаж бежит вперед и поворачивает ствол между выстрелами. Разве это должен быть один эмиттер? С разными тракеториями, исходной точкой, углом? Ну хз может можно как то *текстурой?) передавать в шейдер координаты и углы.
Включи воображение. На эту партиклю навешиваем ваншот. Дополнительно выставляем частицам глобальные координаты, чтобы дымок оставался в месте выстрела, а не перемещался вместе со стволом. Делаем из неё префаб. Прелоадим его в скрипт оружия. Создаём инстанс при каждом выстреле. Инстанс автоматически срабатывает один раз. Затем он должен удалить сам себя. Можно по таймеру, зная тайминг партикла, можно по сигналу, подбери подходящий.
Но вообще конечно, с таким уровнем тупости ты вряд ли сделаешь игру, если на такой банальной задаче у тебя случился затык на два дня. Без обид, бро, может стоит сменить профессию?
>если нескольким камерам поставили current, то из них побеждает более поздняя
Скорее всего она не "побеждает", а перезаписывает предыдущую. Т.е. должно быть какое-то свойство типа Viewport.RenderFrom: Camera, в котором лежит ссылка на камеру. У свойства камеры Camera.current вызывается сеттер set_current(), который кроме установки значения true, обращается к вьюпорту и записывает ссылку на эту камеру в соответствующий параметр. Следовательно, не имеет значения, скольким камерам ты сделаешь current = true, поскольку значение имеет ссылка на камеру в текущем вьюпорте. Не будет же вьюпорт бегать по сцене и проверять if Camera.current == true: каждый раз, когда собирается рисовать (т.е. каждый кадр)?
А если не ставить камеру вручную, то вьюпорт идёт по списку вложенных сцен и присваивает своему свойству ссылку на первую попавшуюся камеру; если камеру не найдёт, будет пустота. Как-то так должно быть под капотом устроено...
>Создаём инстанс при каждом выстреле. Инстанс автоматически срабатывает один раз. Затем он должен удалить сам себя.
Оптимизация стрельбы уровня /gd/? А потом они ненавидят ООП за медлительность...
>>658013 →
>Ставлю на сцену двух инстансов от одной и той же сцены "человечек" (игрок и враг). Игрока вкладываю в ноду Control, которая передаёт сигналы с клавиатуры как команды своему человечку-потомку.
ИМХО, лучше, наверное, наследоваться от общего скрипта. Т.е. есть скрипт human.gd:
class_name Human extends KinematicBody
# тут всё, что нужно для движения человечка
Далее скрипт игрока player.gd:
extends Human
# тут вызываются методы Human в ответ на нажатия клавиш
И скрипт бота bot.gd:
extends Human
# тут вызываются методы Human в соответствии с решениями ИИ
Я так сделал, выглядит вроде логичнее, чем набрасывать отдельный контрол на абстрактного чувака. Хотя, если у тебя какая-нибудь РТС, в которой игрок может попеременно управлять разными юнитами, тогда, похоже, следует именно перекидывать отдельную контролирующую ноду-скрипт (но тогда она сама должна быть потомком, наверное)...
>>658373 →
>видимо ты в этой строчке случайно ее жамкнул
Там хоткей вроде F9, я часто его случайно нажимаю, т.к. в нормальных IDE компиляция забита на F9, а не F5.
Первый раз точно так же недоумевал, почему у меня брекпойнт возник, пока не понял, что на автомате жму F9...
>в нормальных IDE компиляция забита на F9, а не F5.
Ты, наверное, шутишь.
Мы просто с разных планет, ничего страшного.
Чем этот костыль лучше уже придуманных выше костылей >>659891
? Вопрос был про поиск решения встроенными в партиклу средствами (т.е. без других нод и дополнительного кода), а не про обход технических ограничений в виде отсутствия этих средств.
>>660039
>во время стрельбы персонаж бежит вперед и поворачивает ствол между выстрелами. Разве это должен быть один эмиттер? С разными тракеториями, исходной точкой, углом?
Снимаем галку Local Coords и не плодим сущности. Не смотрел, как это работает в 3д, я делаю в 2д, и это работает при любых перемещениях и поворотах ствола.
>Чем этот костыль лучше уже придуманных выше костылей
Смирись, программирование - это само по себе костыль.
Загрузи пример 2d in 3d из библиотеки и посмотри, как там.
В общем, моё монструозное дерево из if'ов пошло под нож, вместо него теперь короткие обращения к дереву анимации. Я прям доволен. Пойду интерфейс пилить теперь.
Я не он, но вот моё дерево и вот моя стейтмашина.
Как видишь, дерево еле влезло на один экран, хотя там я заморочился со скоростью анимаций, без них на 4 ноды меньше было бы. В стейтмашине тоже можно заморочиться со скоростью, но щас я клепаю проект на ТВГ и там уже не до таких красивостей.
В общем, постигнув суть стейтмашин, я как-то отошёл от дерева. У него какие-то свои специфичные задачи. Стейтмашиной всё то же самое делается быстрее и компактнее.
Вот как это делается:
В корневую стейтмашину вместо блендспейсов добавляешь бленддеревья, внутри котоых блендспейс и таймскейл. Получается дополнительный уровень вложенности, не критичный для кода. Всё равно пути один раз прописываешь в сеттере.
И всё, получается, легко и просто контролируешь скорость анимаций. Третья пикча показывает сравнение в инспекторе старого walk0, которое просто блендспейс и нового walk, которое теперь поддерево.
Ну и приблизительный код сеттера для нового дерева.
$'object'.a=$'object'.hz_func()
$'object'.do_something('object'.a)
>так он тебе и предлагает получить ссылку на объект один раз и работать уже по ее адресу, а не каждый раз заново ее получать
Нет, он хочет вот такое (я тоже это очень хочу): <картинка>
>Что? К годоте можно прикрутить паскаль?
То был пример конструкции with <something> do ... на полноценном ЯП.
А так - вроде бы да, можно прикрутить с помощью GDNative, но я пока не пробовал.
>>660959
>Смутили " := "
Первая картинка. Это позволяет пропустить указание типа, определив тип по присваиваемому значению.
>"$" без кавычек
Вторая картинка. Кавычки писать не нужно, сам $-синтаксис всего лишь сокращает запись get_node("").
Источник - https://docs.godotengine.org/en/stable/getting_started/scripting/gdscript/gdscript_basics.html
В принципе, писать так:
onready var button := $form/panel/button
button.text = "text"
Проще (и, возможно, оптимальнее), чем так:
$form/panel/button.text = "text"
Но в ряде случаев хотелось бы иметь with-сокращения как в Паскале (и других языках).
>В принципе, писать так:
>onready var button := $form/panel/button
>button.text = "text"
>Проще (и, возможно, оптимальнее), чем так:
>$form/panel/button.text = "text"
Ой, все.
>Но в ряде случаев хотелось бы иметь with-сокращения как в Паскале (и других языках).
Я вообще хз, почему этого нет в годо. Это же гиперудобная вещь, и, если ее нет, то могли бы хоть добавить заменитель идентичный натуральному.
>Я вообще хз, почему этого нет в годо. Это же гиперудобная вещь
Согласен.
>могли бы хоть добавить заменитель идентичный натуральному.
Решили не добавлять, потому что:
>>660968
>https://github.com/godotengine/godot/issues/1736
>I don't think we'll implement any with statement in GDScript, as it is used in different languages for different things...
(лолшто)
>If you need with for a long block of code, it's a hint that this code should likely be placed in the script of that node, and replaced by a single function call in the parent node.
--> "сокращайте код ручками, лалки".
То есть если у меня класс в классе в классе, я должен ручками делать дополнительный метод в главном классе, который упрощает доступ к классу в классе в классе, чтобы сделать несколько таких обращений подряд? Понятное дело, что лучше так не делать, но а что если у меня длинные имена главного класса и длинные имена методов?
Всяко проще было бы сделать:
with EntityWhatDoesSomethingCool do
param1 = param2 # синхронизация внутренних параметров
Чем делать:
EntityWhatDoesSomethingCool.param1 = EntityWhatDoesSomethingCool.param2
Да даже если эта операция пишется в функции:
func sync_params_of_cool_slave_entity():
EntityWhatDoesSomethingCool.param1 = EntityWhatDoesSomethingCool.param2
Всё равно это выглядит отвратительно по сравнению с with.
Впрочем, ладно. Всегда можно прикрутить Паскаль отдельной DLL-кой...
Если ты про такое:
with Player, Enemy do
Position = Position
Достаточно вывести ошибку парсинга:
[error] Position of wich class do you call?
Однако если у классов есть разные поля, то проблемы нет:
with Player, Enemy do
Target = Inventory.Position
Enemy имеет цель преследования Target, Player несёт в себе рюкзак-инвентарь на спине.
Ну, это абстрактный пример, трудно с ходу выдумать что-то реально полезное...
Это абстрактный пример, но он прекрасно иллюстрирует, почему в настоящем языке (Си, повторюсь) от этой конструкции отказались. Срачом на эту тему форумы забиты с 90х годов, не вижу смысла пересказывать, иди гугли сам, раз вышел из криостаза только в этом году.
Хочешь сокращать? Пожалуйста:
var p = $my/long/player/node/path
var e = $my/long/enemy/node/path
var i = $my/long/player/node/path/inventory
e.position = p.position
e.target = i.position
Так делают сишники, настоящие программисты на настоящем языке программирования, а не на учебном.
>однобуквенные переменные повсюду
>Так делают сишники
Теперь понятно, почему код на C-подобных языках настолько уродлив.
Чтобы не разводить срач, GDScript предназначен для школьников/студентов/дизайнеров, если хочешь обмазываться своим C++ - пиши на C++, никто тебе не мешает, а GDScript нужен для быстрого прототипирования без особых познаний в программировании и всего такого, и я не вижу смысла пилить неудобные однобуквенные костыли там, где можно было бы воспользоваться мощным оператором удобного языка. Между прочим, C++ - это и есть мусорка из "мощных операторов", с каждым годом количество операторов удваивается, каждая задача одинаково решаема десятком разных операторов. Так что не сравнивай.
Алсо, по-моему у тебя бомбануло, потому что в твоём языке with нет, а в моём - есть.
В однобуквенных переменных нет ничего плохого, когда речь идет об алгоритмах и математике, а код на С-подобных языках благодаря им выглядить компактно и аккуратно.
Прописывать полностью каждый раз имя, иерархию и тип приходится только на всяких маргинальных языках без типизации и нормальной поддержки IDE.
В самом деле, если идет в цикле работа с врагами, его логичнее называть e., чем каждый раз enemy., а че сразу не писать enemy_from_array_of_active_enemies. ?
>Ага, у меня бомбит от того, что 99% софта написано на си/си++. Конечно. А у тебя НЕБОМБИТ! Твёрдо и чотко!
Причина бомбления очевидна: ты юзаешь ЯП только из-за его популярности, а я юзаю ЯП, который мне по нраву.
>>661000
>геймдизами или художниками он тоже плох, постоянно плюются, особенно с значащими отступами
Ну фиг знает, значащие отступы приучают человека писать хорошо читаемый визуально код.
Скажем так, конструкция
if (something) {
action1;
action2;
} else {
action3;
action4;
}
читается намного хуже, чем
if (something) {
_ action1;
_ action2;
} else {
_ action3;
_ action4;
}
А уж без программных скобок вообще не было бы ясно, что к чему относится.
Поэтому синтаксис GDScript в целом лучше для восприятия, чем у классических ЯП.
>>661009
>Там потом 100500 примеров из разных языков и действительно везде свои нюансы.
Какое отношение 100500 примеров других языков имеют к GDScript? Я об этом.
>>661010
>В однобуквенных переменных нет ничего плохого, когда речь идет об алгоритмах и математике
Только если это абстрактный алгоритм для обработки чего-либо абстрактного, как в математике.
>код на С-подобных языках благодаря им выглядить компактно и аккуратно
Ты дважды ошибся, пытаясь написать "нечитабельно". Сишники и функции 2-3 буквами обзывают.
>Прописывать полностью каждый раз имя, иерархию и тип приходится только на всяких маргинальных языках без типизации и нормальной поддержки IDE.
Это когда речь идёт о написании кода. Каким образом IDE может помочь тебе в чтении написанного?
>В самом деле, если идет в цикле работа с врагами, его логичнее называть e., чем каждый раз enemy., а че сразу не писать enemy_from_array_of_active_enemies. ?
В цикле ещё ладно, но только если этот цикл занимает одну строчку, а не несколько экранов.
А так, "e" может быть и entity, и element, и ещё куча всякого. Написав строчку вида
for e in get_children():
уже на следующей строке можно забыть о том, что e - это enemy, а не какая-то там entity.
А уж что говорить о том, когда ты вернёшься к этой e через недельку/месяц/год... Особенно, если это не твоя e.
>Я бы предпочёл обязательные отступы + программные скобки begin..end, но хомячки не обрадуются писать лишние символы.
Люто двачаю.
Вторая проблема этих отступов - нельзя просто так взять и обрамить готовый кусок кода дополнительным if'ом, например. Скажем, проверкой на состояние здоровья. Да, в годоте можно выделить текст и нажать tab; но это костыль. Плюс табуляции занимают много места на экране, я бы предпочёл пробелы.
И ещё очень печалит отсутствие комментариев вида / .. / - чтобы быстро закомментировать и раскомментировать блоки кода.
>значащие отступы приучают человека
Воспитанием должны заниматься родители. Ну, или хотя бы учителя. Когда взрослый человек берётся самостоятельно заниматься чем-то, предполагается, что он уже приучен ко всяким таким вещам, типа не гадить под себя.
Да даже не случайные. Можно сказать что вообще все ошибки совершаются случайно )
Я тоже предпочитаю обязательные отступы + скобки, сишные компиляторы выдают предупреждение (а при флаге warning as errors - ошибку) на плохое форматирование, в случаях типа
if(c)
foo();
bar();
Но при этом я не хочу чтобы пробелы были значащими символами.
>нельзя просто так взять и обрамить готовый кусок кода дополнительным if'ом, например
>Да, в годоте можно выделить текст и нажать tab; но это костыль
Я обычно код пишу в PS Pad, тут для отступов есть ctrl+shift+I (вправо) и ctrl+shift+U (влево), мне удобно. Да и в любом другом редакторе, заточенном под кодинг, скорее всего будут аналогичные "костыли". Ты ж всё равно будешь вынужден отступы добавлять, даже если они чисто декоративные, если только пишешь не на Форте в одну строчку. Да, есть автоформатирование, но это точно такой же костыль, придуманный для того, чтобы облегчать работу над стилем кода, тогда как стиль кода сам по себе костыль, призванный облегчить чтение кода... >>660118
>Плюс табуляции занимают много места на экране, я бы предпочёл пробелы.
Это всё настраивается (картинка). Ширина табов, кстати, настраивается во многих текстовых редакторах.
>чтобы быстро закомментировать и раскомментировать блоки кода.
Есть функция IDE для этого (шорткат ctrl+k вроде бы), но да, это тоже костыль получается)
>Воспитанием должны заниматься родители. Ну, или хотя бы учителя
Родители-программисты и учителя информатики? Возможно, но не всем так повезло.
>предполагается, что он уже приучен ко всяким таким вещам, типа не гадить под себя
Когда только учишься программировать, не понимаешь многих вещей, связанных с чистотой кода и стандартными практиками. Если бы всё было так просто, никто бы не говорил об "антипаттернах", а теория программирования не развивалась за последние полвека. Если бы можно было кодить прямо на живом русском (английском) языке, тогда, возможно, для программирования достаточно было бы уметь говорить, но пока мы кодим на искусственных языках, нам недостаточно знать используемый язык - приходится овладевать определёнными навыками и изучать то, до чего своим умом доходишь спустя годы досадных ошибок.
Поэтому, имхо, транслятор кода, понятно объясняющий/комментирующий большинство очевидных ошибок, всегда лучше транслятора, который съедает любой валидный код, никак не помогая найти ошибки, связанные с неопытностью пишущего этот код. Пусть лучше транслятор приучает, чем вообще никто.
>Когда только учишься программировать, не понимаешь многих вещей
Для обучения существуют учебники, гайды и мануалы. Язык - это инструмент для выполнения работы, а не обучения. Автомобиль тебя ведь не учит ПДД и не учит манерам поведения на дороге, он просто едет туда, куда ты его ведёшь; ведёшь неправильно - твои проблемы. Представь, что автомобиль отказывается поворачивать колёса, если выключен поворотник; по учебной площадке на таком автомобиле ездить можно, однако в город на нём лучше не соваться.
Язык не должен ничего тебе объяснять, он должен просто работать. Не понимаешь - пиздуй в поиск. Особенно когда только учишься.
Хотя да, наверное, я сужу с позиции человека, который умеет учиться. Многие не умеют и всячески сопротивляются.
>Re-create Godot's basic types in your new language: These are types such as Vector3, int, float, String, etc. Many of these are usually provided already.
Фрипаскаль пасасал с нативными векторами. В math есть какое-то говно из 70х, не имеющее 90% функционала. То есть, либо велосипедить, либо брать из имеющихся готовых модулей для фрипаскаля.
>Create a module: A C++ module that creates binding code needs to be done (creating modules in C++ is well documented). The entire exposed Godot API can be accessed via the static functions in ObjectTypeDB.
Какой язык ни пытайся добавить в годо - знание си обязательно.
>Generate binding code in your new language that accesses the exposed functions in the MethodBind class (there is one for each exposed method).
Титанический, монотонный труд, который Хуаном для си автоматизирован (есть готовые заголовки) - остальные ебитес как хотите.
>Create a ScriptLanguage class and supply the neccesary methods exposed for debugging, profiling, etc. You can supply symbols, code completion helpers, etc. if this language is meant to be edited inside Godot.
Основной титанический труд по добавлению связки фрипаскаля с редактором. Если предполагается кодить в лазаре - этот пункт можно пропустить.
-Игра
--Интерфейс
--Уровень
Читаю оф. мануалы и не могу вкурить, нигде про это ничего не говорится.
> >Generate binding code in your new language that accesses the exposed functions in the MethodBind class (there is one for each exposed method).
> Титанический, монотонный труд, который Хуаном для си автоматизирован (есть готовые заголовки) - остальные ебитес как хотите.
Что мешает регекспом конвертнуть? Или по api.json сгенерировать. Или по файлу который для моно генерится.
> Разве зелёные ноды не должны перемещаться вместе с камерой
Не совсем так, но для простоты - да.
Например, делаем как на картинке:
UI - это все твое дерево интерфейса. Можно сделать в виде узла control, в которое засунешь весь необходимый интерфейс данного состояния игры.
player - это просто камера, на которую навешен простейший скрипт движения на кнопки влево/вправо (без дублирования на кнопки AD), скрипт на третьем пике
Есть твоя загружаемая сцена уровня, которую меняешь. Сейчас это просто Меш кубика, который окрашен.
Запускаем - нажимаем кнопки, камера перемещается в пространстве, UI "вместе с ней", сцена на месте (первые две картинки)
Забыл сказать, что речь идёт про 2D.
Проблема была в том, что камера масштабирует всю сцену вместе с интерфейсом (HUDом). И перемещается по всей сцене и по интерфейсу. Если интерфейс сделать потомком камеры, он будет перемещаться вместе с игроком (потому что камера - потомок игрока), но не с камерой (потому что у камеры есть всякие плюшки типа смуфинга и драг маргинов).
Решение нашлось. Нигде (НИГДЕ) об этом прямым текстом не говорится. Все туториалы рассматривают либо перемещаемую камеру без интерфейса, либо интерфейс в неподвижной сцене. Итак, решение: интерфейс надо делать потомком CanvasLayer'а. Тогда он адекватно масштабируется и размещается в правильном месте. При этом сам канваслой у меня никак не связан ни с персонажем, ни с уровнем.
Такие дела. Всю ночь тыкался в поисках ответа, только под утро наконец нашёл.
Ну да, для 2D можно сделать также почти как с 3D, с некоторыми отличиями: например, да, засунуть UI в отдельный CanvasLayer, также поставить самой камере галку в поле current, что она будет текущей камерой.
>Для обучения существуют учебники, гайды и мануалы
Некоторые вещи можно понять только на практике. Кратковременная память человека очень ограничена.
>Автомобиль ... просто едет туда, куда ты его ведёшь
Автомобиль не взлетает в воздух, когда ты нечаянно дёргаешь руль на себя, и не трансформируется внезапно в самолёт, когда в бак заливается керосин вместо бензина. У реального автомобиля есть жёсткие ограничения - хотя бы тот же ограниченный поворот руля, не позволяющий вертеть его бесконечно долго - тогда как типичный транслятор позволяет совершать намного более жуткие вещи, чем банальный и предсказуемый наезд на пешехода. Транслятор как волшебная палочка, может сделать что угодно, в том числе совсем не то, что ты от него ожидал, особенно если инструкция частично утрачена (не написана).
>Представь, что автомобиль отказывается поворачивать колёса, если выключен поворотник
Умный автомобиль будет включать поворотник при повороте руля. Хотя я не знаю тонкостей ПДД, может, так нельзя...
>Язык не должен ничего тебе объяснять, он должен просто работать
Дарю тебе сведения о языке программирования Forth. Он просто работает. Всё, что он умеет - это выполнять инструкции, которые ты ему даёшь. Если инструкция выполнилась, он пишет ok. Если stack overflow или underflow, он пишет соответствующее сообщение. Если он не нашёл в словаре твоё слово, он пишет, что слово not found. Ещё может писать division by zero, допустим. Всё остальное зависит исключительно от тебя, и если ты что-нибудь нечаянно сломаешь - а ты обязательно что-нибудь сломаешь - всё рухнет и последствия придётся разгребать именно тебе, в одиночку. То есть ты можешь сделать на Forth всё, что можешь себе вообразить, и никаких встроенных проверок на безопасность и корректность кода тут нет и быть не может; код на Forth - это просто слова, разделённые пробелами, как этот текст (он может быть корректной программой на Forth/Forth-подобном языке). Много людей программирует на Forth? А вот нифига. Потому что все любят, когда кто-нибудь указывает на их ошибки, а не взрывается столпом искр и останавливается до тех пор, пока код не будет изменён на что-нибудь другое. А вот Ada - почему Ada сокращает время отладки на 80%? Потому что она заранее предотвращает твои ошибки, и тебе труднее выстрелить себе в ногу. Язык не должен слепо выполнять твои команды, если это не низкоуровневый язык типа Ассемблера, язык должен упрощать твою работу.
>>661089
>Фрипаскаль пасасал с нативными векторами
В чём проблема написать самому? TVector2, TVector3. Можно в точности повторить функционал из GDScript.
>Какой язык ни пытайся добавить в годо - знание си обязательно.
Что-то я не понял, биндинг ведь через DLL идёт, не?.. Ааа, понял, это DLL-ку нужно биндить к Godot, а не Godot к DLL-ке. Лол. Ну ладно, Си - это как Паскаль, только со {скобочками}. Не даром же Паскаль создавался для обучения программированию на Си. В крайнем случае можно скопипастить...
>Титанический, монотонный труд
ctrl+c/ctrl+v в основном? В остальном только заголовки функций поправить и типы в аргументах?
>титанический труд
Ты меня будто на слабо вызываешь. Но, если честно, не так уж мне хочется делать игры...
>>661109 >>661112
Почему такая разница между 3D/2D? Я думал, логика построения сцены должна быть одинаковой. Что делает CanvasLayer?
var a=[][][]
a[1][2][3]='Збс!'
print(a[1][2][3])
Да. В нормальном, строго типизированном ЯП ты мог бы создать массив элементов одного типа, они все размещались бы в памяти последовательно (массив же), и при проходе подряд обрабатывались бы быстро (такой массив вроде должен автоматом подгружаться в кэш процессора). В GDScript обычный массив[] содержит нетипизированные элементы, т.е. "variant", которые могут принимать любое значение. Делается это в ущерб производительности, т.к. для чтения/перезаписи каждой такой переменной тратится время ЦП на проверку или перезапись метки типа (не считая того, что на эту метку тратится память); кроме того, ещё не факт, что они располагаются последовательно, данные могут разбрасываться по памяти (ЦП не сможет подгрузить в кэш). Чтобы обойти этот недостаток, существуют классы с именами Pool<N>Array, где <N> - название типа (например, Int); это одномерные типизированные массивы, оптимизированные по использованию памяти, но вкладывать друг в друга их уже не получится.
Так что если ты собираешься держать в трёхмерном массиве огромный массив информации, который будет часто обновляться, лучше подумать о написании модуля на C++. Впрочем, не знаю, насколько серьёзные просадки будут на практике, сам тестов не проводил, читал только (когда искал типизированные массивы). Если часто обновлять не планируешь, то, возможно, сойдёт и так, просто помни, что по сути будешь палить из пушки (variant'ы) по воробьям (int'ы какие-нибудь).
Да, кстати, для воксельных игр а-ля Майнкрафт как раз-таки пишут модули на C++, GDScript слишком слоупок для этого.
_input(event)
_unhandled_input(event)
Ivent
Когда и что надо использовать?
>Почему такая разница между 3D/2D? Я думал, логика построения сцены должна быть одинаковой. Что делает CanvasLayer?
Эту магию пока не дано мне постичь. Но из побочных эффектов - сбилось глобальное позиционирование, и теперь пули вылетают не из ствола (они рождались по глобальным координатам Position2D, дочерней от оружия), а откуда попало. Другие объекты со своих мест не уехали, и координаты мыши правильно определяются; и вообще, вся сцена с персонажем и оружием находится не в той ветке, в которой интерфейс и канвас. ЧХ выхлопы от генератора частиц, который тоже привязан к стволу, позиционируются правильно.
Не обращай внимания на поехавшего, он нахватался знаний по верхам и выпендривается сложными словами, в программировании есть принцип предварительная оптимизация зло, все зависит от конкретного случая и нужно тестировать, я один раз тестировал производительность тайлмапов в годоте и замена гдскрипта на плюсы дала прирост порядка 5%, а не 500% как должна была бы, а все потому что система упиралась в скорость вывода графики. Если у тебя какой то простой случай то все спокойно будет работать с 3д массивами, но конечно игру на микровокселях в 1см не сделать
>Как настроить свои шары, чтобы они не летали сквозь стены?
У тебя KinematicBody проваливается сквозь RigidBody? Если так, поставь infinite_inertia = false у move_and_slide().
https://docs.godotengine.org/en/3.1/classes/class_kinematicbody2d.html#class-kinematicbody2d-method-move-and-slide
Если у тебя пролетают очень быстро движущие объекты через тонкие статичные стенки, я полагаю, нужно либо делать стенки физически толще, либо тестировать смещение на более короткую дистанцию, прежде чем "прыгать" далеко.
>>661615
>лучше для сравнительно крупных 2д проектов
Godot лучше, к тому же Godot универсальнее, его предпочтительнее изучать.
Но ещё зависит от того, что ты называешь "крупным". Terraria-like ни Godot, ни GM "из коробки" не потянут, нужны специфичные для таких игр оптимизации, которые трудно прикрутить к универсальному движку/конструктору.
>>661616
>Массив классов
Для "массива классов" используй обычный массив. Экземпляр класса занимает рандомное место в памяти, доступ всегда происходит по ссылке, в массиве хранится только ссылка. Так что работа с большим массивом классов по идее всегда будет медленной, но пока тебе не нужны десятки тысяч классов - всё ок.
>>661651
>есть принцип предварительная оптимизация зло
Я всего лишь предупредил, где могут возникнуть подводные камни, если он замутит какой-нибудь 3D массив 1000x1000x1000 и внезапно обнаружит, что всё стало в разы медленнее (или вообще падает).
>все зависит от конкретного случая и нужно тестировать
И я о том же, но он не сказал конкретики, так что я обрисовал худший сценарий. А то сейчас понасоздают тут массивов в массивах в массивах, а потом будут говорить "чёт Годо медленный, чёт Годо лагает".
>Если у тебя пролетают очень быстро движущие объекты через тонкие статичные стенки, я полагаю, нужно либо делать стенки физически толще, либо тестировать смещение на более короткую дистанцию, прежде чем "прыгать" далеко.
Да, вот этот вот вариант. Про тест мув знаю, но не хотел писать доп код. Ну ок, раз по другому низя.
>Но ещё зависит от того, что ты называешь "крупным". Terraria-like ни Godot, ни GM "из коробки" не потянут
А единство?
>1000x1000x1000 и внезапно обнаружит, что всё стало в разы медленнее (или вообще падает).
Это же вроде не супербольшой массив, не? Если я не буду каждый фрейм его сортировать, то не должно же вроде быть проседаний фпс? Обращение к элементам по индексам наверное уж не должно так жрать ресурсы?
class container
( )var a=1
( )var b=4
var tmp=container.New()
s=str(tmp)
Типа такого, но чтобы передало значения a и b, а не реф
>Да, вот этот вот вариант. Про тест мув знаю, но не хотел писать доп код. Ну ок, раз по другому низя.
Покажи, какой код и при каких условиях у тебя пролетает. А то гадаем на кофейной гуще.
>А единство?
Ты про что?
>Это же вроде не супербольшой массив, не?
Миллиард указателей, разбросанных по памяти, и указывающих на миллиард разбросанных по памяти классов? Даже если бы это был просто миллиард 32-битных Int, такой массив занял бы почти 4 ГБ оперативной памяти. А безтиповые переменные занимают по идее намного больше места, чем 32-битный Int, плюс каждый класс будет добавлять вес.
>Если я не буду каждый фрейм его сортировать, то не должно же вроде быть проседаний фпс?
>Обращение к элементам по индексам наверное уж не должно так жрать ресурсы?
Ой, ну попробуй, если вообще запустится, посмотришь, будут ли просадки. Я просто говорю, что не питай особых надежд, скорее всего придётся костылировать что-нибудь.
Воксельные игры вообще-то используют чанки, это, по сути, 5(6)-х мерный массив, два измерения индексируют чанки, а остальные три индексируют малое пространство внутри чанка (16x16x128, допустим). Но даже так, для нормальной игры потребуется ещё куча всяких костылей-оптимизаций, в лоб это не решается.
>Ты про что?
Unity
>Покажи, какой код и при каких условиях у тебя пролетает. А то гадаем на кофейной гуще.
Да я ж как раз не про код. Как в коде сделать я и сам знаю. Думал настройка есть под это, какая-нибудь, для более точного рассчета столкновений
>Воксельные игры вообще-то используют чанки, это, по сути, 5(6)-х мерный массив, два измерения индексируют чанки, а остальные три индексируют малое пространство внутри чанка (16x16x128, допустим). Но даже так, для нормальной игры потребуется ещё куча всяких костылей-оптимизаций, в лоб это не решается.
У меня как-раз подобная структура намечается, но немного для других целей
>Я просто учусь, пока что. Но надо же знать, на что рассчитывать.
Попробуй придумать что-нибудь и потом реализовать это своими руками. Если не получится - ищи другую идею, если получится - уже будет опыт для новых идей. А так ты сейчас обучишься инструменту, а идей как не было, так и не возникнет. Личный опыт...
>>661724
>Еще вопрос: как наиболее просто и незамороченно передать в строку содержимое переменной-класса
>Тут, конечно, для двух переменных все очень просто, но у меня их сильно больше, чем две, в каждом классе.
По идее, каждый класс должен сам формировать такую строку, если тебе очень надо:
func to_string():
return бла-бла-бла
Универсальных инструментов под это вроде как нет, это вообще весьма странная задача, если подумать. Зачем тебе?
>Unity
Ой, хочешь выбрать идеальный движок - иди в движкосрач и там спрашивай. Unity такой же универсальный движок, как и Godot; все кубопесочницы на Unity, что я видел, лагали намного сильнее оригинального майнкрафта. Для кубопесочниц нужен узкоспециализированный движок - либо форкай minetest, либо пиши свой с нуля.
>У меня как-раз подобная структура намечается, но немного для других целей
Оптимизировать открытое пространство? Если нужны просто чанки, то чанками размером, условно, 50x50 метров можно покрыть очень большую карту без особых затрат, я так думаю. Сам хотел что-то такое сделать, но потом забил на проект и чот приуныл.
>Ой, хочешь выбрать идеальный движок - иди в движкосрач и там спрашивай. Unity такой же универсальный движок, как и Godot; все кубопесочницы на Unity, что я видел, лагали намного сильнее оригинального майнкрафта. Для кубопесочниц нужен узкоспециализированный движок - либо форкай minetest, либо пиши свой с нуля.
Вот поэтому и не хотел здесь даже упоминать про юнити, ибо, как понял, для здешнего анона это больная тема.
> но потом забил на проект и чот приуныл.
ЖЫза
>В файл писать и обратно
А, ты про streaming... Не уверен, есть ли в Godot это в таком виде.
Но можно сохранять ноды/сцены целиком: https://godotengine.org/qa/903/how-to-save-a-scene-at-run-time
Правда, я не уверен, сохраняется ли состояние переменных прикреплённого скрипта, т.к. сам пока не пробовал так.
>почему существуют такие моды, как оптифайн
Понятия не имею, как работает оптифайн, но он вроде какие-то файлы подменяет на свои.
>Почему разрабы не закладывают это в код программы?
>есть какой-то скрытый смысл?
Возможно, несовместимость лицензий. К примеру, код под лицензией GPL, насколько мне известно, не может линковаться с каким-либо кодом под несовместимой с GPL лицензией (т.к. GPL как зомби-вирус - всё, что линкуется с GPL, обязано лицензироваться GPL и выкладываться в виде исходных кодов). Код майнкрафта - закрытый, то есть лицензия проприетарная, а это значит, что в код майнкрафта нельзя легально поместить GPL-код. То есть разрабам майнкрафта либо свой велосипед писать, либо искать код под какой-нибудь лицензией типа MIT, в то время как моддеры могут наплевать на законность и вволю пиратствовать (моддинг игр сам по себе незаконен, пока разраб не сделает ModAPI).
Ну и фиг знает, возможно есть внутренние проблемы, по которым нельзя просто взять и заменить что-то. Майнкрафт - это большая куча легаси кода, насколько я понимаю, выдернешь одно, может рухнуть другое. Его постепенно оптимизируют (и наверняка рефакторят), судя по всему, но процесс трудоёмкий и всё сразу сделать не получается.
Вот всегда интересовало, как можно кому-то предъявить за закрытый код? Он же закрытый))))))) То-есть, если что-либо всплывет, то налицо факт взлома ПО. Поэтому, что мешает использовать что-угодно в закрытом коде? Если нашел нарушение - значит взламывал и сам пидорас.
Хотя, я, конечно, понимаю, что все далеко не так просто
> Ааа, понял, это DLL-ку нужно биндить к Godot, а не Godot к DLL-ке. Лол. Ну ладно
Эх, моя мечта, чтобы годот существовал как ДЛЛ, которая бы через бинды подключалась к Лазарусу как компонент, чтобы весь код создавался и редактировался прямо в ИДЕ, все ресурсы так же в ИДЕ, отдельными окнами-инспекторами, чтобы сцену можно было редактировать в отдельном окошке с OPENGL выводом, как простую форму. А потом билд экзешника средствами фрипаскаля с полным доступом ко всем секциям бинарника, иконки/ресурсы и т.п. Ресурсы вшивать в соответствующие секции бинарника, а не как сейчас - файл PCK приклеивается в хвост заранее скомпилированного "шаблона экспорта". Эх, мечты.
Потому что взял ты такой код gpl у васи пупкина и вставил в свою закрытую игру, в потом некий анон выложил исходники твоей игры, т.к. работали вы компанией и произошла утечка (типа как у вальв сейчас). В лучше случае ты как компания найдешь анона а анально покараешь через суд, который обяжет его выплатить штраф, и тот будет тебе по 100 рупий платить каждый месяц до конца жизни. Но и ты как компания в свою очередь выплатишь охуеть какой штраф Васе Пупкину за нарушение лицензии и будешь открывать свой код.
>т.к. работали вы компанией и произошла утечка
Это отдельный случай.
>потом некий анон выложил исходники твоей игры
А в этом случае, по идее, нужно еще доказать, что это ТВОИ исходники, а не его маняфантазии на тему твоей программы. Хотя, наверное, можно перекомпилить и сравнить хэш или типа того..
>Если нашел нарушение - значит взламывал
Однако нарушение-то есть. Если вор вломился в дом и увидел маньяка-педофила, вора судить будут за взлом дома, а маньяка - за педофилию. Загугли, были какие-то прецеденты с GPL, прям до суда дошло вроде. Да и, к тому же, закрытый код доступен сотрудникам компании, а те, хоть и подписывают NDA, по-прежнему могут доложить о нарушении, пусть даже анонимно.
Вокруг GPL вообще много срачей, поэтому ровные пацаны, как Godot, лицензируются под чем-то вроде MIT, чтобы не отпугивать людей жёсткими требованиями "только опенсурс" и "только под той же лицензией".
> нужно еще доказать, что это ТВОИ исходники
1) ты не проебал исходники
на тебя подают в суд и происходить проверка твоих закрытых кодов группой экспертной комиссии
2) ты клятвенно уверяшь, что ты потерял исходники, т.к. их же украли
берут слитые и ассемблируют, берут твою игру - аналогично.. сверяют до какого-там процента, который в суде считается достаточным
>подключалась к Лазарусу как компонент, чтобы весь код создавался и редактировался прямо в ИДЕ, все ресурсы так же в ИДЕ, отдельными окнами-инспекторами, чтобы сцену можно было редактировать в отдельном окошке с OPENGL выводом, как простую форму
По-моему, в таком виде существуют GLScene и Castle Game Engine, нет? А ещё были DelphiX и ещё что-то...
>Ресурсы вшивать в соответствующие секции бинарника
По-моему у EXE есть строгое ограничение на ресурсы. Во всяком случае, если пытаться через .res запихнуть больше скольких-то десятков мегабайт изображений - приложение сломается. Так что лучше обращаться к внешним файлам (возможно, упакованным в свой формат), чем совать что попало в EXE.
>а не как сейчас - файл PCK приклеивается в хвост заранее скомпилированного
А чем это плохо? Ну, кроме того, что заранее скомпилированный движок тащит в себе кучу лишнего.
>>661814
>Я хочу игоры делать
Эх, все мы хотим, да не у всех хоть что-то получается(
>Едиснтвенное, еще одну вещь спрошу: насколько реально обнаружить свои исходники в сети одним прекрасным утром, если работаешь один?
Такое может произойти, если:
1. Ты не Неуловимый Джо, и кому-то позарез нужны именно твои исходники;
2. У тебя на компьютере вирус или антивирус, любезно сливающий все файлы в Сеть;
3. Ты был пьян или с температурой 41+ пытался что-то делать, и сам слил исходники;
4. У тебя есть девушка/родственники/дети/друзья/соседи, которые имеют доступ к твоему ПК;
5. У тебя есть кот или любое другое животное, способное осмысленно нажимать клавиши клавиатуры;
6. Твой ПК изъяли менты на экспертизу, а уже у них завелась какая-то крыса или просто приколист;
7. ???
8. Тебя похитили инопланетяне, узнали пароль от компьютера и слили исходники ряди эксперимента.
В остальных случаях, думаю, шансы малы.
>насколько реально обнаружить свои исходники в сети одним прекрасным утром, если работаешь один?
В треде по опенсурсному движку этот вопрос выглядит очень странно. Вы или крест снимите, или штаны наденьте. А лучше заберите этот дискурс обратно в движкосрачи; и шапочку из фольги не забудьте.
Сейвил вот так, сцена создалась
Эддчайлд что-то там делает противозаконное явно. Т.к. если его убрать, то программа запускается (если оставить, то на экран выводится только логотип годо), хотя print(a) в сохраненной сцене ничего не выводит в аутпут, так что я хз, где эта нода вообще находится, если она вообще загрузилась
>>661894
Вот еще, если это важно
https://www.youtube.com/watch?v=MA7jSbXfS34
Стоило решить проблему самому, как тут же появилось решение в сети.
После некоторых тестов оказалось, что положение пуль сбивается вовсе не из-за CanvasLayer'а, а по какой-то причине в коде самих пуль.
Речь про 2д, всякие сглаживания движений на масштабах в 20-30 пикселей.
#преждевременнаяоптимизация #XYпроблема
Он все правильно тебе ответил. Ну если тебе так важно то lerp это обертка над чем то вроде a(1-t)+bt и имеет 1 или 2 умножения, в зависимости от формулы. Что будет быстрее? Во-первых, если у тебя значения только от нуля, то одну половины формулы можно выкинуть. Во-вторых, если у тебя начальное и конечное значение неизменны, то иногда можно вынести все из цикла, а в цикле оставить только x+=delta
Ну вот, ответ по существу, спасибо.
Это приблизительно совпадает с моими догадками. Прежде чем спросить, я, естественно, погуглил, прочекал суть идеи, выяснил, что под словами "линейная интерполяция" скрывается простое ax+b. Сам вопрос возник по той простой причине, что зачастую простые решения, описываемые в гайдах, имеют какие-то недостатки; или, например, в гайдах не упоминаются какие-нибудь тонкости или частные случаи. Например, ситуация с канвасом выше по треду. Или вот, из найденного сегодня: функция lerp_angle меня спасла, потому то я поворачивал lerp'ом ствол вслед за мышкой, и для гладкого поворота из левой верхней четверти круга в верхнюю нижнюю без этого пришлось бы поизвращаться. В конце концов, все эти гайды существуют для обучения, они не рассчитаны на работу проектах в более сложных, чем демка в один экран.
Почему возникли подозрения в скорости lerp'а: ну, например, потому что он принимает разные типы данных, а значит могла бы существовать более строго типизированная функция, которая работает быстрее. Или ещё почему. Хз, что там за код под капотом. Я спросил в треде, потому что тут, может быть, есть кто-то, кто копался в исходниках и смотрел, как оно там реализовано.
Что касается "преждевременной" оптимизации. Лучше я сразу напишу оптимальный код, чем напишу сначала не оптимальный, а потом буду оптимизировать. Времени на написание кода уйдёт одинаково, зато потом на оптимизации сэкономлю. А ещё я узнаю что-то новое, если попробую какой-то метод, который прежде не пробовал.
Такие дела.
>Разгадка проста - твой lerp может занимать 0,00000001% кадра. Это экономия на спичках.
Самая главная проблема преждевременных оптимизаций не в том, что может быть экономия на спичках; порой каждая спичка имеет цену. Самая главная проблема в том, что пока он >>662448 будет искать самый оптимальный способ решения какой-то абстрактной задачи, он будет занят только этой задачей, забыв про собственно разработку конкретной игры. Это как движкописательство, вот ты заметил, что твоей игре в твоём движке не хватает какого-то компонента, сел его писать, и через несколько недель у тебя есть превосходная версия компонента, само совершенство, идеальный код, но за всё это время ты не вспоминал об игре, ради которой этот компонент делался, и в итоге возвращаться к игре трудно... а самое страшное, что после возврата к игре окажется, что планировавшаяся в игре фича неинтересна или работает не так, как хотелось, поэтому написанный за эти недели идеальный компонент придётся убрать в ящик идеальных, но бесполезных вещей, и больше никогда не использовать.
Короче, преимущество движков типа Godot в быстром прототипировании - можно одним пальцем накидать заготовку игры, поиграть в неё и определиться, что нужно для финальной игры. А потом можно даже выкинуть Godot и взять что-то более узкоспециализированное, более сложное в работе, потому что к тому моменту у тебя будет чёткое понимание того, что нужно игре. Раньше игры было трудно делать не потому, что не было простых в освоении готовых инструментов, а потому, что прототипы делались месяцами, а потом выкидывались тем же образом, что выкидываются проекты-однодневки сегодня.
Ок, ребут. Последнее сохранение-то, думаю я, было до того, что вызвало это подвисание. Загружаю проект, нажимаю на ноду дерева_анимаций - и она не нажимается, а снова всё вешает. После нескольких попыток я понял, что любое нажатие хоть левой, хоть правой кнопкой вызывает подвисание. Походу, годоте сам граф дерева не нравится.
Открыл в текстовом редакторе файл сцены, нашёл там дерево анимации, стёр. Предварительно забэкапив, конечно же. Часа за два сделал дерево заново. Начал тестить, случайно рассоединил в одном месте. Соединил обратно, и оно снова зависло. И снова это зависание каким-то неведомым образом записалось в файл сцены.
Особая вкуснота ситуация в том, что у меня не винда, а линух. А его подвесить это надо постараться.
Сборкой 3.2.2 пробовал открывать. Точно так же виснет.
Скачал виндовс-версию, запустил через Wine. При нажатии на дерево анимации на пару секунд годотя подвисла, но потом нормально его открыла.
Такой вот опыт.
https://youtu.be/UEDEIksGEjQ
https://youtu.be/AIapugketbs
Я нашёл твою проблему, ты упомянул её как минимум дважды:
>линух
Если серьёзно, сколько у тебя RAM и как настроен файл подкачки? Полный висяк линукса мне очень хорошо знаком, у меня он часто происходил из-за переполнения физической RAM без файла подкачки (разные дистрибутивы, 3 полностью разных машины). Учитывая то, что редактор Godot очень любит кушать память (VRAM в т.ч., а при её нехватке отбирается RAM), подозреваю, что у тебя в сцене с деревом анимаций происходит резкое переполнение RAM, которое и вешает линукс. Почему на Windows/Wine такого не случается? У Windows работа с памятью устроена как-то иначе, из моего опыта она стремится во что бы то ни стало сохранить стабильность своих процессов, убивая самые толстые пользовательские процессы, но только когда заканчивается RAM+файл подкачки; т.о. даже забитая до предела память не вешает системные процессы, а только создаёт тормоза на несколько секунд (пока приложение не отдаст память обратно) и некоторые минимальные глюки (диспетчер рабочего стола Explorer может упасть и загрузиться с небольшими глюками, видимо он не входит в число бережно защищаемых процессов).
Короч, попробуй включить/увеличить файл подкачки, по идее должно помочь. И посмотри по диспетчеру задач, что происходит с памятью/процессом Godot сразу после нажатия на файл сцены, если происходит резкий всплеск потребления памяти - это точно оно.
Погоди-ка, я правильно понимаю, что ты предлагаешь рекурсивному процессу, отжирающему всю доступную память, дать ещё памяти, чтобы он сожрал и её?
График потребления памяти рос равномерными такими ступеньками. И да, до потолка, а потом и своп. А перед тем, как начать жрать память, на 100% нагрузилось первое ядро процессора.
Вайн сандбоксит приложения, вроде как, поэтому у него краш случается гораздо быстрее, до достижения предела памяти. А вот почему вин-версия иногда вообще не пытается ничего сожрать, и граф открывается за пару секунд, не отъедая память, вот это не очень понятно.
>>662552
Скину, когда точно перепробую все варианты. Да и не очень понятно, как его скидывать: не весь же проект в архив запихивать, там говнокод и заглушки, нельзя такое показывать; а вне проекта не факт, что баг воспроизведётся.
> и не очень понятно, как его скидывать
Сохрани ресурс в ресурсный файл, очевидно. В анимплеере анимации тоже схорони в файлы.
>>662663
Ну и делай игры в своем дельфи. К нам-то в тред чего залез и ноешь? Допиздишься, побрацки тебе говорю.
>Погоди-ка, я правильно понимаю
Какой-то грубый тон однако чувствую я.
>ты предлагаешь рекурсивному процессу, отжирающему всю доступную память, дать ещё памяти, чтобы он сожрал и её?
Да. Ведь когда-нибудь он остановится, так? Рекурсивные процессы не бывают бесконечными - в какой-то момент переполняется стек вызовов и всё рушится, но в твоём случае ему просто нужно больше памяти (а тебе - не строить такие деревья). Даже если у тебя файл подкачки на SSD, ничего страшного не случится, в следующий раз просто не будешь делать такие жирные сцены.
>А вот почему вин-версия иногда вообще не пытается ничего сожрать, и граф открывается за пару секунд, не отъедая память, вот это не очень понятно.
Возможно, какой-то баг конкретно линуксовой версии, попробуй открыть issue на гитхабе.
Вообще, ты так бойко отвечаешь, будто хочешь сказать "я и без тебя всё это знал" или будто обиделся, что линукс, оказывается, проще уронить, чем винду. А ведь я просто попытался подсказать, в чём может быть проблема. С:
>>662670
Если немного подумать, в чём-то ты прав. У Godot как минимум какое-то фиговое хранение сцен. То есть если уровней вложенности мало, всё ОК, но как только ты пытаешься вложить сцену в сцену в сцену в сцену, в какой-то момент всё начинает дико тормозить на СОХРАНЕНИИ этой сцены, и это очень огорчает.
>Ну и делай игры в своем дельфи. К нам-то в тред чего залез и ноешь?
Я сюда залез, потому что пытаюсь сделать игру на Godot, очевидно же)
А пост было в том смысле, что он >>662610 открыл Америку - древовидные GUI с контейнерами были ещё в первых RAD. Godot может многим похвастаться, но древовидный GUI - это не изобретение Godot, вот я о чём.
>В анимплеере анимации тоже схорони в файлы.
Их там два с половиной экрана по 1080p. Я пересоздавал сцену, копипастил анимации, задолбался. Больше чёт не хочется.
>Сохрани ресурс в ресурсный файл
У меня почему-то эта кнопочка неактивна. Можно попытаться сохранить tree_root, но работает это весьма криво.
>Рекурсивные процессы не бывают бесконечными
Не вижу, почему бы ему не быть достаточно прожорливым, чтобы не всосать ещё пару гигов, которые я чисто теоретически мог бы ему дать.
>в следующий раз просто не будешь делать такие жирные сцены.
Переделать дерево анимаций - это да, это мне видится единственным адекватным решением. Перераспределить по стейт-машинам, чтобы было меньше всяких блендов.
>Вообще, ты так бойко отвечаешь, будто хочешь сказать "я и без тебя всё это знал" или будто обиделся, что линукс
Ты зря пытаешься уловить интонации в печатном тексте.
Я так отвечаю, потому что в моём понимании это нелогично: дать ещё памяти, если процесс без причины съедает её всю. Это всё равно что пытаться затушить пожар из ведра и кастрюли, когда одного ведра оказалось мало. Да, наверное, если дать терабайт подкачки, может, что-то и получится. Но это всё равно очень сомнительно.
>У Godot как минимум какое-то фиговое хранение сцен.
Если быть точным, там полнейший бардак. Ресурсы раскиданы по файлу без какого-либо порядка, ссылаются друг на друга по номерам, которые тоже не по порядку. Я хотел аккуратненько вырезать дерево вместе со всеми внутренностями, но оказалось, что это не так-то легко сделать. Почему там нет хотя бы подобия иерархической структуры не очень понятно.
> Переделать дерево анимаций — это да, это мне видится единственным адекватным решением. Перераспределить по стейт-машинам, чтобы было меньше всяких блендов.
А вот же, глянь, анончик сначала юзал дерево, потом заменил его на КА: >>660760 >>660749 и получил нехилый буст, судя по его восторженному тону.
> Если быть точным, там полнейший бардак. Ресурсы раскиданы по файлу без какого-либо порядка, ссылаются друг на друга по номерам, которые тоже не по порядку. Я хотел аккуратненько вырезать дерево вместе со всеми внутренностями, но оказалось, что это не так-то легко сделать. Почему там нет хотя бы подобия иерархической структуры не очень понятно.
Поэтому я лично рекомендую все ресурсы по возможности сохранять в отдельные файлы. Файл tscn по возможности должен содержать ТОЛЬКО пути к файлам ресурсов. Но вообще, это сложно, когда привык лепить ресурсы, как это принято в видеотуториалах. Вот я специально для тебя заморочился и сохранил все вложенные ресурсы одной из своих сцен в отдельные файлы. Файл сцены похудел очень сильно (я не подумал заранее и не запомнил предыдущий размер, было около 40 Кб, стало 2 Кб). Пикрелейтед содержание начала файла вместо длинных текстов с описаниями ресурсов.
И ещё одна полезная фишка: Файлы tscn - это текстовые файлы, есть бинарный формат scn, который сильно тоньше (вышеуказанная сплеш-сцена в бинарном виде стала 1 Кб). То же самое с ресурсами, когда ты их сохраняешь через "сохранить как", тебе диалог предлагает фильтр .tres, .material или *.anim, так вот tres - текстовый и раза в два больше, чем файлы с аббревиатурой ресурса. Выглядят бинарные сцены и ресурсы как второй пик.
Вроде как при экспорте это всё равно в ПАК-файл конвертируется как бинарное, но это не точно. В любом случае, ты можешь нехило бустануть работу с проектом в редакторе, если будешь сохранять всё в бинарные форматы. А если требуется что-то ручками в блокноте подшаманить - всегда можно сохранить копию в текстовый формат, подшаманить, открыть, проверить что всё норм и пересохранить в бинарном.
>Не вижу, почему бы ему не быть достаточно прожорливым, чтобы не всосать ещё пару гигов, которые я чисто теоретически мог бы ему дать.
Ох, я тебе говорю - если ты в следующий раз столкнёшься с такой проблемой, просто докинь ещё гигов 8 памяти, а потом удали из сцены всё лишнее, чтобы она больше так не делала. Это только чтобы попытаться разрулить ситуацию, которую сам же случайно и создал, чтобы не пределывать всё с нуля с тем же результатом.
Или в линуксе файл подкачки занимает фиксированное пространство? Когда я пользовался, там вроде вместо "файла" была "папка подкачки"... У меня на Windows сейчас 8 ГБ физической RAM, 2 ГБ исходного файла подкачки (на всякий случай) и верхний предел 16 ГБ, чтобы в сумме получалось 24 ГБ. Раньше было меньше (16 ГБ в сумме), недавно расширил, т.к. заметил переполнение, когда попытался поиграть в одну игру, не закрывая редактор Godot...
>в моём понимании это нелогично: дать ещё памяти, если процесс без причины съедает её всю
Условно, может быть два варианта:
1. Процесс заглючил и вошёл в бесконечный цикл и будет жрать столько, сколько дадут;
2. Процесс в порядке, просто ты задал ему слишком тяжёлую задачу, ресурсов не хватает.
Ты думаешь про 1-й вариант, а я тебе говорю про 2-й. Тем более, как я уже говорил, у меня линукс вис намертво от простейшего переполнения памяти, а это как минимум говорит о том, что железо не тянет (в моём случае памяти реально мало было, <1 ГБ). Если физическая оператива не тянет и нет возможности её проапгрейдить (как у меня, 8 ГБ потолок), остаётся только расширять файл подкачки (подкачка с SSD вообще незаметна), если хочешь стабильно работать с тяжёлыми проектами. А то у тебя так и будет всё чуть что падать от переполнения...
Вариант с бесконечной утечкой памяти, разумеется, возможен, но узнать наверняка это невозможно, всегда возможна ситуация "ещё бы полгига докинуть сверху и всё завершилось бы" - не попробуешь, не узнаешь. Это вроде бы относится к принципиально неразрешимой задаче останова...
>Да, наверное, если дать терабайт подкачки, может, что-то и получится.
Глупости. Просто скажи, что тебе лень докинуть десяток гигабайт про запас и забыть об этом)
>>662734
>рекомендую все ресурсы по возможности сохранять в отдельные файлы
У меня как раз с таким методом сохранения получилась какая-то фигня, правда у меня получается что-то вроде "tscn <- tscn <- tscn <- tscn <- tscn <- tscn", очень глубокая степень вложенности, может из-за этого сохранение так жутко тормозит.
> правда у меня получается что-то вроде "tscn <- tscn <- tscn <- tscn <- tscn <- tscn", очень глубокая степень вложенности, может из-за этого сохранение так жутко тормозит.
Скорее всего. Как я выше написал, форматы с приставкой t - текстовые, соответственно их парсинг будет обладать всеми тормозами работы с текстом. Попробуй организовать
> "scn <- scn <- scn <- scn <- scn <- scn"
внутри которых
> "scn <- res <- material <- texture <- anim <- etc"
>если ты в следующий раз столкнёшься с такой проблемой
В момент возникновения этой проблемы решать докидывать что-либо будет уже поздно, всё зависнет.
А потом я лучше воспользуюсь вайн-версией для удаления всего лишнего. Нынешний объём подкачки меня устраивает, нет никаких задач (работающих как задумано), где бы мне понадобилось больше.
>просто докинь ещё гигов 8 памяти
>Просто скажи, что тебе лень докинуть десяток гигабайт про запас
HDD-боярина благородные речи
>Когда я пользовался, там вроде вместо "файла" была "папка подкачки"
Раздел на диске. Увеличить-уменьшить его довольно проблематично.
>Ты думаешь про 1-й вариант, а я тебе говорю про 2-й.
Ну да. Потому что, если софтина потребляла около ста мегабайт памяти, а потом вдруг после тривиального действия, выполнявшегося прежде без употребления дополнительной памяти, съела 10 гигов, 2-й вариант не выглядит чем-то правдоподобным.
>если хочешь стабильно работать с тяжёлыми проектами.
Пиксельное 2д, какие там тяжёлые проекты.
Не, с тяжёлыми я работаю, но это не годот и вообще не геймдев, а обработка звука. И там всё упирается в процессор, а не в память. Мне памяти всегда хватает с запасом.
>>662734
>рекомендую все ресурсы по возможности сохранять в отдельные файлы.
Кстати, дельный совет, только я бы применил его лишь к самым крупным ресурсам. Типа того же дерева анимаций. Потому что они действительно сильно запутывают файл проекта.
Я тут повкладывал бленддеревья одно в другое. Вместо одного огромного разветвлённого бленддерева получилось много маленьких. И это, кажется, сработало. По крайней мере, пока что всё нормально открывается. Да и ориентироваться стало, в общем-то, удобнее.
Теперь воюю с новой странностью:
var a: bool = True #тут сначала было false
var b: float = PI #там могут быть разные значения от -PI до PI, это на самом деле результат работы angle_to
print(b)
#3.14...
if a and abs(b) > PI/2:
#и тут мы падаем с ошибкой:
#Invalid type in built-in function 'abs'. Cannot convert argument 1 from Nil to float
Я даже явным образом задавал значение b непосредственно перед проблемным местом. Если непосредственно перед условным блоком написать var c = abs(b) и потом в условие добавлять это самое c, то всё работает. Либо это какое-то очень сильное колдунство, либо я чего-то не знаю о том, как работают условия в гдскрипте. Либо просто спать ночью надо было.
>В момент возникновения этой проблемы решать докидывать что-либо будет уже поздно, всё зависнет.
Вот поэтому памяти на ПК нужно иметь с запасом. Когда-нибудь да не хватит, тем более когда игры пилишь.
>HDD-боярина благородные речи
Мой HDD умер от старости. Но с тех пор, как поставил SSD, держу файл подкачки на SSD, ибо так быстрее.
inb4: нет, SSD не изнашивается слишком быстро, за 3/4 года 24/7-аптайма потратилось всего ~2% износа.
>Раздел на диске. Увеличить-уменьшить его довольно проблематично.
Насколько я помню, в линуксе есть несколько видов виртуальной памяти, их можно переключать между собой.
>2-й вариант не выглядит чем-то правдоподобным
Однако и такое бывает. Достаточно импортнуть какую-нибудь большую модель в 3D-редактор, например.
>Пиксельное 2д, какие там тяжёлые проекты.
Всё относительно)
>>662825
>Нет ничего страшного в том, чтобы объявить локальные переменные
Кроме того, что выделение памяти под локальные переменные должно отнимать дополнительное время.
>>662832
Скорее разрешение мелкое какое-нибудь, или вертикальный дисплей. 3:4 уже редко встречается.
>angle_to(b)
Оговариваться стал от бессонницы. Причём написал angle_to, глядя в свой же код, где написано b = self.global_position.direction_to(мышь).angle()
>>662830
>Значит ты что то накосячил в своей angle to print
Я делал даже присваивание непосредственно перед if'ом. То есть, так и писал:
b = PI
а потом, чтобы убедиться, что оно точно-точно присвоилось, добавлял:
print(b)
И всё равно в abs в условии говорил, что b это nil. Тот же самый abs в том же месте кода, но вызванный на строчку выше условного блока, прекрасно переваривает ту же самую b, никаких nil'ов.
Я просто попробовал для интереса, вроде получилось неплохо и мне понравилось, но слегка смущает что по мануалу поддержка C# еще в 'late alpha' стадии.
Продуктивненько, в общем. Я долго ковырялся с начальной частью, тыкался в непонятные места и всё никак не мог с ними разобраться; стоило это сделать, как работа пошла отличными темпами. Завтра доделываю всякое по мелочи, после чего можно приступать к работе над ИИ. Я совершенно хз, как ему лучше выстраивать логику, поэтому попробую для начала обучить простой генетический алгоритм; если не получится, буду уже глубже копать материалы по этой теме.
Двачую ГОАП для ИИ. В библиотеке ассетов есть готовая реализация.
>>663892
> если прервать OneShot другой анимацией, то при повторном вызове ваншота проиграется только окончание, не довыполненное в прошлый раз
Откажись от дерева и перейди на стейтмашину. Я тебе даже пытался помочь разобраться:
>>660749
>>660760
>попробую для начала обучить простой генетический алгоритм
Лолшто, зачем тебе ГА в игре? И как ты это себе представляешь? Для ГА нужна какая-то виртуальная машина, которая будет исполнять генетический код, при этом сложность кода должна быть мизерной, иначе годное решение никогда не найдётся.
На ГА удобно сделать симуляцию жизни популяции организмов, но для обычной игори смысла в ГА нет, игре нужны чёткие алгоритмы поведения ботов.
Затем, что
>попробую
В конце концов, это любительский проект, важной целью которого является познание. Мне всегда было интересно узнать, как будет выглядеть такой ии в играх, но никогда не попадалось адекватных готовых примеров.
У меня есть некоторые соображения, как сделать, чтобы ГА можно было обучить на достаточно сложные задачи за адекватное время. Например, увеличивать количество доступных входов и выходов по мере обучения, чтобы новую фичу получали только самые стабильные экземпляры.
>увеличивать количество доступных входов и выходов по мере обучения, чтобы новую фичу получали только самые стабильные экземпляры
Всё зависит от того, какой будет исполняющая машина. Может получиться так, что изменяя её параметры, ты будешь делать всех текущих выживальщиков нежизнеспособными. ГА - это не нейронка, в нейронке ты можешь зафиксировать часть нейронов и наращивать новые, а в ГА по идее меняется всё сразу.
>>664022
>Что-то типа кучи ботов с параметрами, из которых в следующее поколение переходят те, что выжили, не?
Так можно только отрегулировать значения параметров (есть/нет/%), это не очень интересно. Грубо говоря, если у твоих ботов есть параметр "цвет", то в конечном итоге они все будут одного выигрышного цвета, и дальше никакой эволюции не будет (хотя окей, выбор идеального значения и есть цель ГА). ГА для ботов можно применить иначе. Щас пример набросаю, надеюсь, не ошибусь...
Сначала задаём исходный алфавит из кодов-команд бота:
0 - ожидание, 1 - идти вперёд, 2/3 - поворот влево/вправо, 4 - атака, 5 - защита, ...
Дальше генерируем каких-нибудь рандомных ботов, примеры:
323534 - вращается на месте, защищается и атакует (ходить не умеет)
121300 - движется по диагонали (ничего кроме этого не умеет)
Предположим, они выжили, скрещиваем, получаем:
323300 - вращается на месте (больше ничего не делает)
121534 - движется по диагонали, иногда защищается и атакует
Вероятно, 121534 будет успешнее предков и брата. Но это абстрактно. Чтобы реально протестировать ботов на успешность, нужны регулирующие условия. Скажем, бот может есть - значит, вокруг разбросана еда, а у бота есть параметр "энергия". Если бот не умеет есть или не находит еду - теряет энергию и погибает раньше всех. Если бот жрёт всё подряд, то еда быстро кончается и он опять же мрёт, хоть и позже. Теоретически, можно выстроить такую цепочку кодов, что бот будет двигаться и потреблять пищу оптимально для конкретной среды обитания. Чтобы эту цепочку найти, мы скрещиваем самых живучих ботов и вносим небольшие мутации:
121534 -> 121434 - теперь бот чаще пытается атаковать/есть, но разучился защищаться
Мутации нужны, скорее всего, потому, что простые комбинации кусочков в конечном итоге потеряют некоторые буквы (например, тут уже потерян 0, а другой бот потерял 1, 4 и 5) или их комбинации (если комбинируем половинками или любыми другими группами, без перемешивания букв), из-за чего наступит однообразие и топтание на одном месте. Ну, тут нужно гуглить реальную генетику.
Так вот... Мы можем расширять алфавит, добавляя разные команды (включая конструкции if/loop, переменные и прочее), можем расширять длину кода, можем добавлять регулирующие условия среды (например, днём жарко, и ботам нужно найти укрытие; боты имеют датчики и условия для проверки, а как ими пользоваться - должны дойти до этого сами через сколько-то поколений бессмысленных смертей, лол). Если всё сделать правильно, то боты за какое-то число поколений (каждое поколение добавляются новички, полученные путём скрещивания выживших или умерших позже всех) должны адаптироваться к любым условиям среды. По сути, в их генах будет хаотически формироваться поведенческая программа, дающая оптимальный вариант для конкретной среды.
Ну, это если рассматривать ботов именно как маленькие программируемые машинки. Если ничего не путаю, ДНК в клетках играет отдалённо похожую роль - коды ДНК описывают белки, рибосомы собирают эти белки, белки делают какую-то работу в клетке, эта работа снаружи клетки наблюдается как поведение клетки. Если описывать не команды поведения, а "параметры", то не будет достаточного разнообразия, я так думаю. Хотя конкретно ГА к параметрам применимо, но мы ведь хотим выработать некое сложное поведение ботов, не так ли?
О, кстати, в описанной модели самое интересное начинается не в генах, а выше - на уровне популяций. Когда ботов много, они могут начать разделяться на виды и кооперироваться. Напоминает колонии одноклеточных, которые в природе тоже объединяются, выживая вместе (и жертвуя собой ради коллектива). Когда-то давно видел такое в одном примере реализации ГА на ютубе...
Ещё небольшая идея - можно рассматривать бота как хранилище подпрограмм, каждая из которых скрещивается индивидуально а-ля хромосома. Подпрограммы могут вызываться из одной главной программы или обращаться друг к другу. Суть подпрограмм в том, что в них могут сформироваться отдельные "навыки" ботов, которые можно зафиксировать, продолжив эволюцию в остальном коде. Тогда если мы дрессируем ботов на определённую задачу и заметили, что они сформировали в одной из подпрограмм подходящее под решение части задачи поведение, мы фиксируем эту подпрограмму, чтобы они не потеряли её из-за последующих скрещиваний и мутаций. Скажем, если некоторые боты научились прятаться в тень от жары, но пока что недостаточно хорошо ищут пропитание.
...так, ладно, я немного запутал, наверное, напишу вкратце:
- бот - исполнитель с набором команд и параметров
- бот погибает, если параметры достигают предела
- из команд бота составляются программы поведения
- первые программки составляются чисто рандомно
- бот исполняет программы в некой среде обитания
- среда имеет параметры вроде еды, освещённости
- сумевшие выжить боты скрещиваются друг с другом
- скрещивание - это склейка половинок программ ботов
- ещё есть мутации - случайные опечатки в программах
...ладно, короч, читайте википедию: https://ru.wikipedia.org/wiki/Генетический_алгоритм
Ну вот, теперь мне жутко захотелось реализовать ГА с ботами на Godot. :C
Ой, сам того не зная, описал ГП вместо ГА: https://ru.wikipedia.org/wiki/Генетическое_программирование
Но суть та же, ГП - это когда ГА применяется для построения программ (в данном случае - поведения ботов).
В общем, я переделал лезвие в KinematicBody2D, и тела стали падать. Почему сразу так не сделал? Потому что кинематик сталкивался с телом и съезжал со своего места на оружии. Оказалось, это работал move_and_collide, унаследованный от пули. Стоило его отключить, как всё починилось.
Окей. Труп должен выпускать оружие из рук. Но оно почему-то зависало в воздухе. Хотя было риджидбодей. И вот этот баг я так и не смог починить: он починился сам. Хотя до того в течение часа постоянно воспроизводился.
Но ладно. Больше всего времени было убито на коллизии оружия ближнего боя. Они должны были включаться и выключаться по таймерам, но почему-то при зажатой кнопке атаки эти таймеры начинали съезжать. Оказалось, что анимации длятся несколько дольше своей номинальной длятельности. Стоило таймеру задержки до следующего удара выставить время на 0.1с больше, как всё пришло в норму.
Последняя проблема была очень странной. Почему-то персонаж игрока, когда садился, левитировал в полуметре над полом; но если враг умирал, то игрок уже садился на пол нормально. Почему? Потому что коллизия у них одна на двоих. Решение нашлось уже во время написания этого поста: галочка "local_to_scene" под ресурсом коллижен-шейпа. С этой галочкой каждый новый инстанс получал свою уникальную копию ресурса. Вот это, я считаю, важный урок, которым следует поделиться с аноном: в некоторых ситуациях для инстансов нужно ресурсы делать локальными.
Всё. Все активные баги исправлены (про некоторые не упомянул, потому что времени на них почти не потратил). Теперь точно можно дальше двигаться. ИИ пилить. Или подбираемые предметы накодить, типа аптечек.
> Труп должен выпускать оружие из рук. Но оно почему-то зависало в воздухе. Хотя было риджидбодей. И вот этот баг я так и не смог починить: он починился сам. Хотя до того в течение часа постоянно воспроизводился.
can_sleep?
sleeping?
Проверь эти параметры, по умолчанию физические тела "засыпают" при бездействии.
Ствол уже нормально падает.
Тут новая магия творится. Добавляю взрывы. Взрыв - area2d, наносит повреждения бодям по on_Area2D_body_entered и дополнительно делает apply_central_impulse всем попавшим в зону риджидам. Телу особой разницы нет, что именно наносит ему повреждение: если в test() вызывать Die() или даже Hurt(100), оно ведёт себя точно так же, как и при попадании пули: превращается в рэгдолл. Но почему-то взрыв вызывает другой эффект. Тушка замирает и больше не реагирует ни на какие физические воздействия.
Такая же ерунда была, когда я делал холодное оружие на ареа2д. Тогда так и не разобрался, в чём причина, просто заменил на кинематик.
Но теперь причина выяснена. Дело в том, что всё происходящее с телом персонажа обрабатывается через физикс_процесс, а тут происходил вызов через сигналы. Подозреваю, что оно что-то ломало в памяти, после чего тело вообще переставало обрабатываться физическим движком.
Перенёс взрыву код ранения в физикс-процесс, всё равно живёт он доли секунды. Это сработало, умирающие стали нормально превращаться в рэгдоллы.
>вызывать Die() или даже Hurt(100),
А что они делают? По идее должны выставлять флаги:
wanna_die = true
wanna_hurt = 100
Потом в обработчике _physics_process:
if wanna_die:
_ dead = true
if wanna_hurt > 0:
_ health -= wanna_hurt
_ wanna_hurt = 0
Тогда всё должно быть чотко.
> теперь причина выяснена. Дело в том, что всё происходящее с телом персонажа обрабатывается через физикс_процесс, а тут происходил вызов через сигналы. Подозреваю, что оно что-то ломало в памяти, после чего тело вообще переставало обрабатываться физическим движком.
> Перенёс взрыву код ранения в физикс-процесс, всё равно живёт он доли секунды. Это сработало, умирающие стали нормально превращаться в рэгдоллы.
Тебя ещё ждёт интересное открытие, что некоторые вещи с физикой даже в physics_process делать нельзя, а нужно добавлять особую функцию _integrate_forces(Physics2DDirectBodyState state), в которой уже именно со state производить операции.
Кидаешь слоем в фотошоп, а сверху рисуешь свои тайлы, согласно этой маске.
>32 в названии видишь? Видишь. Сетку 32х32 в своём графическом редакторе установи - и сразу всё увидишь.
Об этом я догадался, но не стал сразу делать. Я спрашиваю, что именно рисовать поверх? Переходы между разными видами спрайтов, типа трава/песок и песок/вода? Этот тайлсет только на два материала? Просто для тех, кто ни разу не рисовал тайлсет, как я, это всё вообще тёмный лес. А пиксель-арт - вообще слишком сложен.
Есть 2Д проект.
В нем ест CanvasLayer. На нем есть TouchScreenButton.
Когда я в скрипте пытаюсь спрятать TouchScreenButton, (с помощью Hide() или SetVisible(false) ) - у меня каждый раз выскакивает ошибка (приложение продолжает работать):
_input: Condition "!is_visible_in_tree()" is true.
(см пикрелейтед)
Если кнопку показать опять то все нормально. Кнопка работает только в видимом состоянии.
При попытке кнопку спрятать она гасится, но в консоли вываливается эта ошибка.
Что с ней можно сделать? Может я как то неправильно наэкранные кнопки прячу и их надо по другому убирать с канваса?
Извиняюсь, не тот пик скинул. Вот правильный.
Есть sqrt(). А как корни других степеней извлекать?
Или через дробные pow()?
Изучай свой код, у меня всё работает, см. скрин.
>>664882
Сомневаюсь, что в GDScript есть что-то специальное для корней >2, так что да, только через pow().
Но тебе точно нужны эти корни? Просто в играх даже квадратный корень - очень затратная операция...
>Изучай свой код, у меня всё работает, см. скрин
Блин, не в этом дело. У мея тоже все работает - прячет и показывает кнопку. И приложение продолжает работать нормально без вылетов.
Проблема в том, что при отключении кнопки оно спамит в консоль этим эксепшеном. Даже если это пустая кнопка и она ни к чему не привязана.
>Но тебе точно нужны эти корни? Просто в играх даже квадратный корень - очень затратная операция...
Нужны. Немного сложной математики в движении есть. Про затраты понятно. Но это, думаю, вполне нивелируется тем, что вычисляется значение раз в значительный промежуток времени, в остальных случаях уже готовое расчитанное значение используется.
>>664935
Прототип же.
Таким образом у нас есть зашитый в игру дефолтный мир, при начале игры объекты активно пишут данные в кастомный словарь, затем при сохранениях этот кастомный словарь сохраняется как сейвфайл, собственно. И восстанавливается при загрузке он же.
Это очень важный этап, а то у меня при сохранениях в файл ебошилось всё подряд: список локаций из дефолтного мира, список персонажей, реплики, триггеры. Всё это не нужно в файлах сохранения, при этом, сохраняется возможность всё таки добавлять и такие данные в файл сохранения, например, если в игру установлен мод, добавляющий локации, эти данные могут быть добавлены. Хотя тут тоже есть над чем подумать, можно же в файл записывать только список модов, а у модов держать свои дефолт-данные, которые так же будут читаться.
Очевидно он про цвет нод в редакторе, красные - 3д (наследники spatial), синие - 2д (наследники Node2D), фиолетовые - анимация, белые - абстрактные или служебные, а зеленые - наследники Control, и у него действительно появляется поле theme, которого нет у canvasitem от которого он наследуется.
>Тебе английским языком, чёрным по белому написано: у тебя кнопка скрыта, но у неё инпут обрабатывается. При скрытии делай ей set_input(false) а при отображении - наоборот.
Не. Нихуя. Я пробовал отрубать все инпуты (и обычный и унхендленые и в дереве) - не помогло.
Знаешь в чем дело было?
Оказалось, надо чтобы кнопки которые мне надо было спрятать, в дереве ноды стояли после той кнопки, по нажатию на которую я их скрывал/показывал и сообщения об ошибке прекратились.
> материал точно также не применяется
Потому что у тебя материал Spatial, а нужно выставить ему режим CanvasItem.
>>665047
Воистину чудны пути программистьи! А код к самим кнопкам прикреплён? Если да, то рекомендую сделать общий код у парента всех этих кнопок, который будет осуществлять всё управление их поведением.
Не это просто кнопки которые определенные экшены задают вроде ui_left или ui_up и т.д. Но такая же петрушка была и с полностью пустыми кнопками и с теми на которые я какие-то скрипты вешал.
Я поэкспериментировал по разному. Единственное что влияло на появление ошибки - это положение скрываемой кнопки в дереве относительно кнопки которая выдает сигнал в скрипт в котором прячется нужная кнопка (выше или ниже). Вложенность в другие узлы роли не играет. Скрипт тоже не важен, он может быть прикреплен к любой другой ноде. Дело только в положении кнопки с сигналом.
Не пробовал только еще отключать не через сигнал, а через отдельный экшен, но чет мне влом отдельный ui_ на это дело вешать.
public override void _Ready()
{
// This function is called after _enter_tree, but it ensures
// that all children nodes have also entered the Scene Tree,
// and became active.
base._Ready();
}
public override void _Process(float delta)
{
// This function is called every frame.
base._Process(delta);
}
Зачем base. в данном случае нужны?
Это ООП. Вызов такой же функции у класса, от которого отнаследовались. Не факт что это вообще используется.
Ну например у тебя может быть класс Vehicle: Node, и класс Tank: Vehicle. И ты хочешь чтобы когда создается Vehicle, загружалась моделька шасси. А когда создается Tank, загружалась моделька башни, но при этом чтобы сначала все равно загружалась моделька шасси.
> хз анон, не проверял. Мое предположение - не нужен, если только ты сам такую логику не закладывал.
Пока все пробовал без base. делать, вроде бы все работает тип-топ.
>>665124
>Ты ведь в курсе, что шарп в годо сыроват еще?
В курсе. Но пока полет нормальный.
>>665130
>Сыроват экспорт на андроид, айфон и особенно веб.
Я х.з, у меня все нормально. Использую V3.2.2.beta1. Экспорт под веб и андроид работает без проблем. Даже деплой в один клик и туда и туда работает. Яблока у меня нет - проверить не могу.
-----
Ситуация: герой стоит на полу и может пойти прямо, а может пойти вперёд-вверх по лестнице. А если есть таковая, то вперёд-вниз. А если платформа закончилась, то только по лестнице. А если подпрыгнет с лестницы, то приземляться будет на неё же. Но если сверху платформа, то на платформу. Но если с пола подпрыгнет, то и приземлится на пол.
Крч есть какая-нибудь структурированная инфа по теме?
nb: я очень прошу НЕ рассказывать своё мнение и расписывать мини-тутор прямо в треде. Только ссылки, умоляю.
> я очень прошу НЕ рассказывать своё мнение и расписывать мини-тутор прямо в треде. Только ссылки, умоляю.
https://godotengine.org/qa/47794/one-way-collision
https://godotengine.org/article/godot-31-will-get-many-improvements-kinematicbody
Вот первый пик поставил omni light, но при этом все горизонтальные поверхности подсвечены, например пик 2, с другой сотороны стены виден свет. Если включаю тени, то этого не происходит, но тут уже сами тени могут выглядеть как говно, третий пик, я как понимаю, в такм случаи мне нужно будет отдельно заморачиваться над дизайном всех элементов окружения, чтоб они отпрасывали красивую тень? или может есть какие-то более простое выходы из ситуации?
Прочитал задачу жопой
@
Выдал первое из гугла
Между тем, я так и не придумал и не нагуглил ничего годного. Тредик, давай подумаем вместе. Пикрилейтед - разные виды взаимодействия с лестницами. Односторонней коллизией тут ничего не добиться, хотя, конечно же, она понадобится. В принципе, можно нагородить целую груду кода и пройтись по куче частных случаев. Но я подозреваю, что должно быть какое-то более общее решение, которое лежит настолько на поверхности для людей, плотно знакомых с геймдевом, что им не приходит в голову его обсужить. Или же каждый раз выстраиваются леса из костылей, такой вариант я тоже не исключаю.
В общем. Выкидываем тезис про "только ссылки". Анон, если бы тебе надо было реализовать лестницы, как бы ты это делал в своей игре?
Делаешь лестницу one-way и на своем отдельном слое коллизий. Цепляешь к лестнице area. От этого area кидаешь сигналы bodyEntered и bodyExited в скрипт который меняет игроку флаг onStairs.
Далее уже в своем обработчике физики в зависимости от инпута, текущего стейта игрока и флага onStairs, включаешь/отключаешь коллизии игрока со слоем лестниц и переводишь его в нужный стейт (walk, walk_on_stairs, fall и т.д.).
Собственно? подобным же образом делается обработка верхних платформ для ladders, когда нужно пролезать вверх/вниз через них. Можешь поискать туториалы на эту тему.
Поскольку то что ты нарисовал невозможно (нельзя одновременно идти по полу и при этом спускаться вниз по лестнице), то надо рассматривать эту систему как железнодорожные стрелки - ты можешь или идти по полу, или спускаться по лестнице. А реализация, как анон выше расписал, видимо. Только надо продумать что если у тебя враги тоже могут так ходить, тогда придется все это раскидать по слоям еще, и на каждом слое может быть свое состояние.
> рассматривать эту систему как железнодорожные стрелки
Двачую. По умолчанию дорога ведёт по сплошной поверхности (извне), при подходе к развилке появляется подсказка "Press F to" которая переключает на спуск по лестнице. При подходе снизу/изнутри подсказка/операция не требуется.
1) почему при скачивании редактора движка в виде одного exe файла с ним также не предоставляется копия файла лицензии MIT ?
2) Когда я публикую свою игру, а она у меня тоже состоит из одного запускаемого файла, то мне нужно прикладывать этот файл лицензии или можно распространять в виде одного своего бинарника?
>Увеличь разрешение лайтмапов (UV2 которое генерируется в блендере для модели).
где можно подробно про это прочитать? я все это дело затеял, что разобраться, я ничего про uv2 не знаю
>>666029
bias это где? я все параметры уже как только не крутил и у света и у материала стены.
>>666174
не понял, как это поможет в моем вопросе?
http://www.apache.org/licenses/LICENSE-2.0
ну да
только когда я создаю игру, то она уже собрана не с редактором, а с ядром движка и там нет этого доступа к тому, чтобы прочитать лицензии, поэтому нужно самому в игре делать примерно тоже, что в редакторе, но с меньшим количеством либ: апач, мит, либпнг, злиб..
Судя по всему можно просто хуячить этот файл
https://github.com/godotengine/godot/blob/master/COPYRIGHT.txt
Хули там размытого, все четко написано.
>Note however that the Godot Engine binary that you would distribute with your game is a copy of the "Software" as defined in the license, and you are therefore required to include the copyright notice and license statement somewhere in your documentation.
>The Godot Engine developers consider that a link to this page (godotengine.org/license) in your game documentation or credits would be an acceptable way to satisfy the license terms.
Достаточно линк в на лицензию годота в кридитах игры кинуть и все.
Что ты нервный такой, попей мяты. Я разбираюсь с лицензиями, попутно другие уже не будут наступать на эти же грабли и будут знать, что делать в этой ситуации. Хотя по идее уже в треде должно быть достаточно людей, кто выпускал коммерческий продукт на нем и знает, что там и как правильно.
Кароче, пытался скомпилить движок с https://github.com/perbone/luascript, вроде все ок, создал скрипт но чет не ворк ничерта, скрипт вроде рабочий, но hello world банально не выводит...
windows godot 3.2.1 (пробовал с 3.2)
А вот в это больше верится, это же Westnoth
https://github.com/wesnoth/jessenehttps://github.com/wesnoth/jessene
>Я разбираюсь с лицензиями
Я вот тут подумал, технически, в лицензировании нужно отталкиваться от требований заказчика/издателя, т.к. это он потом будет использовать/распространять продукт. Такие вещи, по идее еще на стадии т.з. согласовываться должны. А то может он собирается игруху полностью закрытой сделать, а у каких-то компонентов которые ты использовал нужно обязательно открытый код выкладывать. Или наоборот, он захочет полный опенсорц сделать, а у каких-то модулей есть запрет на выкладывание исходников (я кстати с таким столкнулся, хотел к своему проекту прикрутить один модуль диалогов, а потом уже прочитал, что с ним можно делать все, что угодно, кроме выкладывания сорцев в составе проекта, а у меня реп полностью открытый. Хорошо не успел его туда включить).
Поэтому нужно сразу говорить заказчику "Я буду делать проект с тем-то тем-то, лицензии лежат вон там. Пиздуй читать, согласен - делаем, нет - думаем чем заменить". И если по ходу разработки прикручивается какой-то сторонний модуль, то тоже уведомлять об этом.
Ну примерно так и было. Заказчик сказал, что хочет такую-то такую-то игру на годоте, чтобы я написал. Лицензия MIT и все дела. Ну я написал, попутно оказалось, что ему нужно, чтобы распространялся строго один файл, т.е. надо как у редактора годо засунуть текст лицензии MIT и то, что игра создавалась на этом движке. А потом оказалось, что у кучи внутренних либ, которые годо использует, есть тоже не с простыми лицензиями и что и всех их тоже надо прикладывать и уведомлять.
Когда есть возможность распространять с кучей файлов - там как выше писали создаешь текстовый файл и все в него вписываешь, но тоже надо не только годо указать, а еще некоторые части, которые под мит, апач, бсд..
Че почитать по созданию ботов? И еще, поясните за эту книгу: Алекс Дж. Шампандар. "Искусственный интеллект в компьютерных играх.", стоит ли ее читать? А то я, блять, уже на 120 странице, а суть даже не начиналась)))))
Итак, годаны. Где может узнать про все эти формы коллизий и про их применение?
>Че почитать по созданию ботов?
Хотел что то посоветовать, но оказалось что сам еще ничего не прочитал и даже в закладках и закачках ничего не нашел. Есть только пара обзорных статей в закладах
https://habr.com/en/post/420219/
https://habr.com/ru/post/173187/
https://habr.com/ru/company/intel/blog/265679/
https://habr.com/ru/company/it-grad/blog/306214/
В общем по моему ограниченному пониманию, есть всякие штуки как поиск пути, там в основном a* (a-star), в том числи и по тайлам, и по навмешу (сетке узлов). Там свои приколы как оптимизировать все это, быстрые эвристики для неточного пути, отсечения в точках схождения, например дверях.
В играх типа шахмат используется min-max, он по очереди пытается сделать лучший ход за одного игрока, потом за другого, до какой-то глубины перебора, фишка в том, что прирост очков для одного игрока является таким же уменьшением очков для второго, поэтому можно его просто вызывать рекурсивно со знаком минус. Оценочная фунция приблизительно считает очки за состояние поля - сколько каких фигур осталось, какие угрозы они создают. Там свои оптимизации, проверять сначала ходы на которые обязательно отвечать, такие как шах.
Дальше, в обычных видеоиграх, как я понимаю в почете GOAP - Goal oriented planning, также используются деревья решений (decision tree), конечные автоматы (FSM, finite-state-machine), конечные автоматы конечных автоматов (вложенные). Некие реализации можно глянуть для годота
https://github.com/RodZill4/godot-goap
https://github.com/godot-addons/godot-behavior-tree-plugin
Слышал есть еще что-то вроде координатора, не помню как называется, идея в том что он раздает приказы юнитам, такое вроде было в старике и в халфе для команд солдат, т.к. если каждый будет думать индивидуально возможны конфликты, а координатор может выдать команды двое налево, двое направо, один прикрывает.
Есть еще такая вещь, как Steering behavior -это типа рулевого, как если бы искуственный интеллект отдал команду переместиться в точку x,y, а steering behavior отвечает за то, как плавно изменить скорость, повернуть на курс и т.д. это касается и движения персонажей, не только техники.
Дальше уже идут нейронные сети, там я еще хуже разбираюсь, но в /pr мне сказали что оно пока не готово. По причине хрен отладишь. Тут примерно то же пишут https://www.quora.com/Are-there-any-video-games-that-use-neural-networks-for-their-AI Идея, думается, такая - на вход нейронке подается то, что она видит - позиции врагов, хитпоинты юнитов, на выходе она выдает аналог нажатий на кнопочки - пойти влево, прожать атаку, в результате это все оценивается функцией оценки, и выигрышное поведение закрепляется, все это проворачивается на десятках тысяч игр самой с собой.
>Поскольку то что ты нарисовал невозможно (нельзя одновременно идти по полу и при этом спускаться вниз по лестнице)
Чего блять?
>>666050
>при подходе к развилке появляется подсказка
"Чтобы пройти по лестнице вверх, поднесите левую руку к клавиатуре, поместите средний палец на клавишу W, а затем небольшим усилием надавите на неё до упора."
>>666010
Я тоже думал в таком направлении. Но в конструкции пикрилейтед (а они предполагаются повсеместно) начинается жопа. Потому что неизбежно при спуске происходит area_exited верхней лестницы.
Короче, надо ещё учитывать, на какой именно лестнице стоит персонаж. Так что, видимо, не обойтись простым onStairs, придётся передавать self в параметрах, а при выходе сравнивать.
Кажется, я нашёл изящное решение лестниц.
Смотрим коллизии. Если среди них есть объект из слоя stairs, то коллизия с лестницами включается; если нет - выключается. Также коллизия с лестницами включена при нажатой клавише "вверх" при одновременном is_on_floor. В верхней части каждой лестницы есть небольшой участок со слоями коллизии world и stairs, а весь остальной пролёт имеет только слой stairs.
И никаких дополнительных зон с дополнительными событиями. При такой системе, пожалуй, только спуск вниз с ровного пола может быть немного сложнее, но не сильно. И от прыжков на лестницах придётся отказаться, иначе придётся кучу условий нагромождать. Хотя, если опрашивать коллизии только при is_on_floor, то не придётся, зато можно будет перепрыгивать с одной лестницы на другую.
Не, ну вы видели? Видели?
Если я правильно понял гит вообще и гитхаб в частности (поправьте меня, если ошибаюсь), это система для синхронизации сорцов для программистов. Вот, допустим я программист (хаха, вот это был бы прекол!) и мне требуется работать над проектом в главном офисе, дома, в дополнительном офисе, который в производственном моногородке, куда я езжу с командировками. Конечно, можно возить с собой внешний хдд и не париться, но все программисты делятся на две категории: 1) кто не парится и возит хдд, 2) потерявший кучу исходников, просравший сроки, контракты, обанкротившийся.
Так воот. И эта система гит вообще кароч предлагает облачное хранение сорцов на любой удобной тебе серверной площадке, синхронизацию, древовидный функционал версий. А гитхаб предлагает уже готовое физическое хранилище, площадку.
Так воооот. В случае с годотом, как и в случае с большинством проектов на гитхабе, мастер ветка является текущей работой этого программиста (или команды их). В этой текущей работе могут быть недоделки, уровня "пойду выпью кофе и допишу, но пока синхронизирую". А если программист хочет опубликовать свою работу, то в момент, когда ему кажется, что текущая версия программы достойна релиза, он создаёт копию и помещает её в специальный раздел гитхаба "релизы". В этом разделе так же можно разместить уже собранные бинарники, инструкции, дополнительные файлы, которых нет в мастер-ветке, ибо данные эти не синхронизируются, так как статичны (например, звуки, текстуры, модели, и т.п.) и просто лежат в трёх экземплярах на ноуте программиста, на рабочем компе и на гугл-диске, на случай если понадобятся в новом месте, а ноута под рукой нет.
Так вот! Качать мастер чтобы заценить движок это ну такое себе, потому что работоспособность пилящегося ПРЯМО ЩАС проекта гарантировать сложно. Из какой ветви мастер не возьми - это будет нестабильная, модифицируемая наживо версия. Неважно какой ты там тег выбрал.
Первоначальная коллизия со слоем stairs возьмётся из:
а) Нажатия кнопки
б) Коллизии с телом, которое находится в слое stairs и ещё каком-нибудь. Самая-самая верхняя ступенька - это статик_боди со слоями stairs и world, а весь остальной лестничный пролёт - только world.
Читай может неправильно выразился, повторюсь я собирал из текущей ветки с тегом 3.2. Не из мастера 4.0. Собирал вчера, и новость про бету вчера, расхождение не больше одного дня. Отдельной ветки для беты мне не поадалось, поэтому я предполагаю, что у меня версия очень близкая к бете.
Херассе, в годоте теоретически можно написать полноценный звуковой синтезтор. Правда, как пишут, гдскрипт работает слишком медленно, чтобы сделать что-то более-менее сложное практически. Жаль, у меня есть в загашнике идея, чтобы абсолютно все звуки в игре синтезировались "на лету", без записанных семплов.
Возьми бинды в сишарп любого понравившегося тебе звукового синтезатора и зделой себе класс-адаптер по паттерну адаптера, разумеется, затем остальные скрепты можешь продолжать писать на гдскрипте, просто релиз у тебя будет с дополнительной либой.
Ах да, на иосе соснешь с шарпом, ну, надо подождать.
Сорян, заснул вчера. Вот следующий пост, если кто-то ждал.
>Риалтайм-синтез реалистичных звуков всё ещё слишком тяжёл для современных процессоров.
Что ты блять несёшь?
1. Уже лет 20 как не слишком тяжёл. А основные алгоритмы так вообще полвека известны.
2. Для создания реалистичных звуков он не предназначен, так что полного реализма добиться нельзя.
Основная причина, почему обычно используются предзаписанные семплы вместо синтеза: это проще и дешевле. Синтез нужен для того, чтобы создавать не существовавшие ранее звуки, которые невозможно издать никаким естественным источником, потому что, если бы такой источник существовал, проще записать его на микрофон и не ебать мозги сложными алгоритмами.
Сравни с анимацией. Её можно делать вручную (синтез) или мокапом (заись). В обоих случаях понадобятся определённые затраты, и мокап тоже придётся потом руками редактировать. Для мультяшности лучше подходит ручная анимация, а для реализма мокап. Можно наборот, но только если это действительно необходимо.
Что касается моторов в GTA5 и, скажем, фортепианного синтезатора Pianoteq, то это исключения ввиду изначальной постановки задачи. В обоих случаях имеет место пересечение двух проблем:
1. Нужно много семплов. Каждый автомобиль имеет несколько передач, свои звуки старта и остановки, автомобилей в игре много. Клавиш у пианины 88 штук, на разных громкостях характер звука меняется.
2. Взаимное влияние и вариативность. Разгон и торможение, смена передач - всё это не так просто между собой соединить. Фортепиано резонирует сложным образом, высокие струны при нажатой клавише улавливают колебания более низких.
В результате получается выбор между двумя стульями: пожертвовать производительностью и получить более гибкую систему или пожертвовать гибкостью и получить более дешёвую систему. И всё это имеет к вопросу "синтез или семплы" мало отношения, потому что в большинстве случаев ответ на него примерно совпадает с "сфотографировать или нарисовать".
Годный ассет?
>мастер ветка является текущей работой этого программиста (или команды их). В этой текущей работе могут быть недоделки, уровня "пойду выпью кофе и допишу, но пока синхронизирую". А если программист хочет опубликовать свою работу, то в момент,
Никогда, слышишь, НИКОГДА, блядь, так не делай. Master не для этого.
>Я тоже думал в таком направлении. Но в конструкции пикрилейтед (а они предполагаются повсеместно) начинается жопа. Потому что неизбежно при спуске происходит area_exited верхней лестницы.
>Короче, надо ещё учитывать, на какой именно лестнице стоит персонаж. Так что, видимо, не обойтись простым onStairs, придётся передавать self в параметрах, а при выходе сравнивать.
Два варианта тебе на выбор:
1) Свойство onStairs делай тогда не флагом, а счетчиком. И каждый заход в зону лестницы плюс 1, каждый выход минус 1. Если 0 то чел на лестнице, если больше нуля, то на какой-либо лестнице.
2) Делаешь для правых и левых лестниц разные флаги (onLeftStair и onRightStair) и соответсвенно разные стейты для них в стейт-машине игрока. Да, это ведет к дублированию кода, но может оказаться проще в реализации.
Сделал сцену, в которой к RigidBody2D добавляются всякие полезные мелочи типа звука удара, таймера самоуничтожения и прочие.
Расставил по сцене кучу таких вот тел, проставил им всем галки "sleeping". Но эти гады всё равно просыпаются сами по себе. Ударил по одному ящику, а проснулся другой; иногда они сами по себе дёргаются, если ударить какой-то посторонний предмет. Я очень подозреваю, что виноваты общие ресурсы, не захотевшие сделаться local_to_scene. Поискал, нашёл соответствующую галку для скрипта. Не помогло. Коллизиям проставил галки, тоже не помогло. Я подозреваю, что где-то в самом риджидбоди надо искать. Но хз где, глазами по двадцать раз каждый пиксель просмотрел. Чего я не знаю? Где мог не посмотреть? Где-то скрыта какая-то не вполне очевидная опция?
Судя по посту, у тебя какие-то неудачные решения в архитектуре проекта были предприняты. Подозреваю, у тебя очень большая вложенность ресурсов друг в друга с неконтролируемыми тобой взаимопересечениями, при которых, скажем, у одного куба оказывается коллайдер второго куба, например.
Что с этим делать? Возьми карандаш и бумагу и нарисуй схему своей сцены так, как ты это видишь. Затем открывай субсцены в редакторе и сверяй со своим листком на соответствие.
>Зачем это всё? Нашлось же простое работающее решение:
>>666898
Может быть. Но вот это:
>Смотрим коллизии. Если среди них есть объект из слоя stairs
мне кажется не сильно продуктивным. Если я правильно понял, то тебе придется дрочить проверку коллизий с лестницами каждый игровой цикл, чтобы понимать где игрок находится. В случае с area, твой игрок просто получает сообщения в момент выхода/входа в зону лестницы, а дальше ты уже работаешь с полями своего объекта-игрока.
Анончики. Можно ли как нибудь в проекте получить доступ к значению дата/время когда был сделан билд проекта?
> просто получить доступ к файлу PCK и узнать время его создания
Вот что нашлось
http://docs.godotengine.org/en/3.2/classes/class_file.html#class-file-method-get-modified-time
Корень сцены AnimatedSprite по имени Door, в нём StaticBody2D по имени Body.Не наоборот, чтобы без редактирования потомков можно было легко поменять текстуру двери. В скрипте к спрайту в разных местах есть обращение к $Body. И почему-то он его не хочет видеть, говорит, что нет такого:
var B = $Body
print(B)
#выводит: null
При этом Body я не вручную писал, а выковырял из всплывающей подсказки, которая возникла после написания $. Через get_node тоже не видит. Скрипт точно прикреплён к Door, Door точно корень.
Штобля? Как это вообще? Почему в других нодах нормально работает? Где вообще тут можно накосячить?
>Но вообще тебе зачем? Моды? Сетевая синхронизация версий клиентов и сервера?
Помечать билды для тестеров.
Сейчас я просто на экран вывожу label в который руками прописываю версию и дату создания билда.
Хотелось бы, чтобы либо эта дата сама где-то фиксировалась при экспорте проекта, либо можно было как нибудь получить доступ к хэшу текущего коммита в репозитории проекта.
>>668374
>>668382
Вобщем, сделал пока так
создал батник stamp.bat в корне который пишет в файл res://data/stamp.txt, дату, время и инфу из репа по hg id (батник и текстовик записал в игнор в проекте)
В проекте кинул на канвас label в которой в _Ready() прописал простой скрипт, который во время запуска при наличии в ресурсах stamp.txt помещает инфу из него в label.text.
Теперь перед экспортом проекта просто запускаю батник и у меня в билде выводится нужная инфа.
Пример на пике.
В будущем когда в годоте починят экспорт проекта из командной строки, можно будет все одним нажатием делать.
А чем не устраивает делать то же самое из кода в проекте?
Просто нравится батники вызывать?
> кинул на канвас label в которой в _Ready() прописал простой скрипт, который во время запуска при наличии в ресурсах stamp.txt помещает инфу из него в label.text
Можно ведь сделать проще:
> кинул на канвас label в которой в _Ready() прописал простой скрипт, который во время запуска помещает инфу из репа по hg id в label.text
>во время запуска помещает инфу из репа по hg id в label.text
1) Запускать из игры какие-то сторонние приложения - это крайне плохо. За такое по лицу бьют. Плюс, подозреваю, половина антивирусов будет матом орать на подобные телодвижения.
Может быть это можно сделать в виде плагина к редактору, который бы перед экспортом получал информацию, но я пока не нашел как такое сделать.
2) У тестеров нету репозитория, откуда тогда игра будет инфу брать, когда она построена. А даже если и есть, то реп может быть совсем на другой ветке открыт и т.д.
>Причём тут сторонние приложения? Получить инфу из репа - это обычный веб-запрос. За такое только брандмауер разрешение на сеть запросит.
1) Реп закрыт о тех кто будет запускать приложение.
2) Даже если есть доступ, откуда приложение будет знать из какой ветки репозитория я его собирал.
3) Нахер мне еще своему приложению доступ в сеть давать если он ему объективно не нужен.
>>668606
>Учитывая современные системы защиты от ператов типа денувы, игроки не удивятся запросу на сеть.
Игроки играющие в игры с активной денувой и анальному зонду в своей заднице не удивятся.
Вполне норм. Простой, удобный двиг, дающий знания обо всех современных фишках и тенденциях геймдева. Даже если захочешь уйти - время, потраченное на изучение не пройдёт впустую, ибо в Годо не используется ни единого вендорлока, все данные ты сможешь использовать в открытом виде и при желании забрать их с собой на другие платформы.
>Очень странно слышать пиратско-воровские с примесью шапочки из фольги речи от сторонника опенсорца. Стапэ.
Ничего воровского. Денува (и прочие подобные защиты, вроде старфорса) такая срань, что ну его нахуй. Я принципиально не покупаю и даже не пирачу игры с такими защитами, идут они лесом.
>А с чего это я решил, что он сторонник опенсорца?
Я х.з. с чего ты это решил. Но таки да, после окончания разработки я сорцы всех своих проектов открываю. Но на время разработки реп закрытым держу.
Так-то я геймдевом по фану занимаюсь. Для себя и друзяшек. А сам процесс разработки и есть мое веселье.
> Всё, что я нагуглил, не работает в актуальной версии.
Плохо гуглил.
1. https://www.google.com/search?q=godot+gaussian+shader
2. https://godotforums.org/discussion/20506/a-good-blur-shader
3. https://github.com/godotengine/godot-demo-projects/blob/master/2d/screen_space_shaders/shaders/blur.shader
Попробовал, оф. демо, все работает в GLES3. Исходя из того что пишут, в GLES2 да, не будет работать, потому что там не строят автоматом мипмапы, поэтому при чтении через textureLod возвращается только фулл разрешение.
Я же правильно понимаю, что для того, чтобы хуйнуть в свой проект модуль для андройда мне этот самый модуль нужно сначала в апкашку скомпилить? И для этого придется наебнуть все, что написано в доках https://docs.godotengine.org/en/stable/development/compiling/compiling_for_android.html ?
Есть более халявные варианты, вообще нет желания ебаться с окружением и настройкой десятка пекедж билдеров и прочей хуйни
Там ничего особо сложного нет, я недавно винду переставлял и за пол дня все вернул. По памяти там всего-то надо: python (самый свежий сойдет), scons (pip install scons), java (кошерная с AdoptOpenJDK.net), android sdk и ndk (далее-далее-готово), плюсовый компилятор вроде в ndk идет. Потом берешь за основу этот батник https://gist.github.com/Calinou/44edbd5d9c4a2ac0dbc8f165b8b7f0ce есть такой же под линь, меняешь пути, дописываешь флаги из твоей ссылки если надо и все.
Продолжаю ковыряться.
Теперь Sprite. Пытаюсь к спрайту прикрепить скрипт с какими-то действиями. Пишу $что-нибудь и получаю ошибку: метод get_node() не объявлен в этом классе.
Походу, в этом проблема. Спрайты (и их анимированные наследники) по какой-то причине не могут иметь здоровое потомство. Придётся городить огород из системы Node2D/Sprite
>Что у тебя написано в первой строке файла после слова extends?
У меня такая вот конструкция:
foo.gd:
extends Sprite
class_name foo
bar.gd:
extends foo
И вот как раз bar уже не имеет метода get_node()
Сделал всё то же самое, но не от спрайта, а от Node2D - полёт нормальный.
foo.gd:
var My_Array: PoolIntArray
...
var.gd:
foo.My_Array.append(12345)
В массив ничего не добавляется. Я хз почему и куда пишутся эти данные, ошибки никакой не выдаёт. Решение:
foo.gd:
var My_Array: PoolIntArray
func My_Append(value: int):
My_Array.append(value)
...
var.gd:
foo.My_Append(12345)
Теперь массив заполняется корректно.
В принципе, наверное, так всё равно лучше и типобезопаснее.
Кто понимает матчасть, разъясните, почему оно именно так работает.
Перепроверяй свой код. Ты что-то напортачил, ибо наследование работает, как ожидалось:
Вроде в доках написано массивы по ссылке.
Я юзаю вот такой для глес2, но он медленный как сука. Мобилочки не вывозят. https://pastebin.com/uXjK1pca
Если тебе это нужно для окна паузы, где никаких визуальных изменений не будет происходить и шейдер тебе не нужен в риалтайме, то можешь его запускать таким костылём всего на пару фреймов:
Здесь на сцене тупо друг над другом стоят ColorRect (на котором и запущен шейдер) и пустой TextureRect, которые друг друга заменяют.
func show_menu():
self.visible=true #Показать меню
yield(get_tree(), "idle_frame")
yield(get_tree(), "idle_frame")
var pic = get_viewport().get_texture().get_data()
pic.flip_y() #Нужно т.к. вьюпорт возвращается перевёрнутым
var img = ImageTexture.new()
img.create_from_image(pic)
$TextureRect.texture=img
$TextureRect.visible=true
$ColorRect.visible=false
Мб кто-то мне подскажет, как это сделать лучше, а не этим костылём. Буду благодарен
> но он медленный как сука
> как это сделать лучше
Чисто с дивана предполагаю, что циклы можно попробовать заменить индусским кодом (копипащенными строчками с магическими числами), там всего по 8 раз нужно все направления вокруг пиксела обработать. ЕМНИП, циклы в ЖЛШЛ тормозные.
position.x = wrapf(position.x, 0, 1000)
и получаю на границах перехода лютые мерцания объектов на границе плюс глючащую физику, которая не знает, что ей надо детектить коллизии с другого конца игрового мира.
Есть какая-то более-менее простая опция, которая бы решала эти проблемы и другие, связанные с тороидным миром, о которых я ещё не знаю? Или надо писать свои костыли?
> Есть какая-то более-менее простая опция
Есть. Зацикливание перемещения физических объектов делается обращением к их физическому состоянию в колбэке _integrate_forces() и вообще обращения к физике лучше делать там. Тогда всё будет фрейм к фрейму, без мерцаний и подёргиваний.
Пик 1. Что будет, если a>b? Круг докатится до правого края экрана, телепортируется на левый край, обнаружит себя глубоко погружённым в квадрат, вытолкнется за левый край, телепортируется снова в правую часть. Время, вектор и точка столкновения будут совсем не такими, какими они были бы на бесшовном цилиндре. Плюс отрисовка: круг на один кадр мигнёт слева и снова окажется справа.
Пик 2. Квадрат и зелёный круг сильно тяжелее серого. И вот зелёный утолкал серого настолько, что стало b<a. Серый круг каждый кадр телепортируется через границу экрана и проникает в коллизию то с квадратом, то с зелёным кругом. Полноценно передать импульс от двух столкновений он не может, потому что эти два столкновения никогда не происходят одновременно. На бесшовном цилиндре серый круг бы в какой-то момент получил две коллизии одновременно и напрямую передал импульс от квадрата в зелёный круг.
> почему такие пространства называются торроидными?
Если представить себе карту мира как в первой Циве, то она не натягивается на сферу, но натягивается на тор (это когда закольцованы и верх с низом, и лево с право). У сферы верх и низ должны схлопываться в одну точку. мимо
Если сшито по одной координате, то цилиндр. Если по двум - тор. Принципиальная разница в том, что на сфере параллельные прямые могут пересекаться (меридианы на полюсах, например), а на торе нет. Сферическую поверхность в 2д я вообще хз как симулировать. Хотя было б круто.
Гугли какого-нибудь Савватеева про топологию, он понятно объясняет. И ещё физики в лекциях про устройство вселенной любят эту тему рассказывать.
>свой собственный интегратор физических сил
Сложна. Погуглю, но чёт кажется, что такая задача мне не по зубам. Придётся от цилиндра отказаться.
>>670505
Боюсь, что такую конструкцию из костылей даже бубном 80лвла не выстроить.
Есть одна идея, не факт что тебе подойдет. Использовалась в Portal. Заключается в том, что сбоку карта продолжается на какое-то расстояние, и там размещаются "копии" объектов. Но да, думаю все равно придется возиться с integrate force. Потому что копия не имеет самостоятельной физики.
Собсно да. Вот какое найдено решение в гугле: https://steemit.com/utopian-io/@sp33dy/tutorial-godot-engine-v3-gdscript-generic-screen-wrapping-sprite
С физикой всё будет осложняться необходимостью копировать объекты. А учитывая, что они могут быть интерактивные, могут взаимодействовать между собой и даже соединяться пружинами... В общем, раз нету нативного решения, придётся забить, дабы не строить костыльных замков.
Хотя я тут подумал, что можно было бы попозже поиграться в 3Д с порталами, как в первом Prey. В ситуации, когда не нужно продвинутое взаимодействие между предметами, можно даже и немножко копировать их на входе в портал. А обстановку позади порталов рисовать шейдерами.
Ну так с физикой ещё большие костыли. Не знаю, есть ли такое в годоте, но вот в Панда 3д я такое делал с помощью класса NonlinearImager, который склеивает изображения с разных камер. Можно отобразить на плоскости сферическую проекцию, полусферическую, цилиндрическую. И шейдер сверху, чтобы корректировать искажения.
С отображением проекций и в годоте проблемы нет. Но анону нужна именно корректно работающая физика. По факту - портальная, где порталы это края экрана. А на углах экрана вообще должен корректно работать двойной портал, считывающий коллизии и горизонтально и вертикально. Вот это задачка так задачка!
> продемонстрировал бы
Зачем велосипедить то, что уже продемонстрировано на ютубе? Вот, с 13 минуты смотри: https://www.youtube.com/watch?v=Eu5sBPqE6Ag
1. var foo = $RayCast2D
2. if foo != null:
3. _ if foo.is_colliding():
4. _ _ var collider = foo.get_collider()
5. _ _ if collider.has_method("bar"):
А дальше не важно, потому что дальше мы вываливаемся с ошибкой, что, дескать, у коллайдера нету метода has_method(), потому что коллайдер у нас null. Как так? Как вообще можно оказаться на 5 строчке, если мы прошли через 3, и там точно-точно is_colliding, то есть коллайдер точно-точно не null, а вполне себе Object, а значит и has_method() у него обязан быть.
Где можно было накосячить так, чтобы данная ситуация вообще сложилась? И как это исправить?
Мы находимся в теле функции, так что всё давно уже реди. Вне тела редактор не даст запустить без onready в таком объявлении. И вообще, данная строчка чисто для твоего понимания, что речь идёт про рейкаст.
И да, строка 2. Если foo не инициализировался, то дальше программа не пойдёт. А даже если и пойдёт, то упадёт на строке 3, скажет, мол, нет такого метода id_colliding().
У тебя там реально фу/бар или нормальные имена? Потому что вдруго у тебя там ещё где то в проекте такие же имена и они конфликтуют на локальном и глобальном уровне?
Чисто предположение с дивана.
Алсо, в любом случае нужно больше деталей, больше кода. Совершенно непонятно, что там у тебя творится. Воспроизводится ли проблема на пустом проекте?
Нормальные имена. Всё, кроме первой строки, переписано из проекта с заменой имён. Вкидывать в тред весь проект не буду, он довольно объёмный.
Одинаковые имена я даю в двух случаях:
1. Это константа, которую по какой-то причине я не хочу переносить в синглтон, поэтому добавляю её в каждый скрипт. Например, потому что этого синглтона нет.
2. Это имя скопипащено из соседнего скрипта вместе со всем, что оно делает.
Оба варианта не про здесь, потому что такой вот лучик у меня только в одной сцене. Имена уникальные. Но инстансов может быть много.
В пустом проекте оно не воспроизводится. Оно и в наполненном-то случается далеко не всегда, только когда инстансов много. Все скрипты у них local_to_scene, есичо.
Да и вообще. В том как раз и состоит мой вопрос. Что надо сделать, чтобы такое вообще произошло? Как воспроизвести это в пустом проекте?
>а вполне себе Object, а значит и has_method() у него обязан быть.
А почему ты уверен, что он коллайдится именно с тем у объектом у которого есть этот метод, а не с каким-нибудь другим.
После 4. _ _ var collider = foo.get_collider() сделай вывод в консоль collider и посмотри, что там.
Я бы проверил что твой $RayCast:
1. enabled
2. Настроен на нужные фильтры (collide with bodies, collide with areas)
3. Включена маска на физ слои, в которых находятся интересующие тебя объекты
4. Настроен ли в нем вообще вектор cast_to
5. По описанию вроде это не требуется при таком использовании, но попробуй перенести код в physics_process
6. По описанию, можно и не проверять на is colliding если баг в ней - get collision вернет null при отсутствиии коллизий.
Потому что
а) метод has_method() есть у всех объектов. Вообще у всех. В этом смысл его применения. https://docs.godotengine.org/en/stable/classes/class_object.html#class-object-method-has-method
б) Вываливается с ошибкой Attempt to call function "has_method"in base "null instance"on a null instance.
Принт в данной ситуации, кстати, не поможет, потому что будет говорить, мол, "вы слишком много выводите, мне столько не съесть", и похерит часть текста.
Кстати, я уже придумал, как исправить ошибку конкретно в этом месте.
1. var foo = $RayCast2D
2. if foo != null:
3. _ var collider = foo.get_collider()
4. _ if collider != null:
5. _ _ if collider.has_method("bar"):
Но это не избавляет проблемы более крупной, которая происходит где-то в памяти, ведь изменение коллайдера происходило явно не тут. И действительно, теперь код падает молча, не выдавая никаких ошибок, чёрт знает в какой момент, просто когда объектов много; может упасть при 1000, а может при 50, тут как повезёт.
>>671128
Попробовал впихнуть твою конструкцию в свой проект - вроде работает. На первом пике код (все лишнее вырезал), на втором результат.
Проверка HasMethod действует и с object и c area.
На сцене чуть более 120 объектов.
Версия Godot 3.2.2 beta 2
>Хоспаде, пошто я такой тупой? Такое простое и элегантное решение, а я не додумался.
Для справки красные платформы, на самом верху лестниц, находятся на отдельном слое коллизий. Когда игрок переходит в STATE_CLIMB, то коллизии с этим слоем отключаются, все остальное время они включены. Это позволяет без геморроя пролезать через платформы при CLIMB вверх-вниз по лестнице, и спокойно IDLE, WALK, JUMP на них.
>Попробовал впихнуть твою конструкцию в свой проект - вроде работает
Конечно работает. Никто и не сомневался, что она работать будет. Она и должна работать. Ты доказал, что работающая конструкция работает. И я вообще не понимаю, что надо сделать в проекте, чтобы она не работала. Однако факт: я таки сделал это случайно. Какими-то другими действиями сломал эту работающую конструкцию. Соответственно, ни в пустом проекте, ни в твоём, ни в каком-либо ещё она не будет сломана, если повторить только её, но не повторить эти ломающие действия. А что именно её сломало? Что вообще могло её сломать?
А у меня всё проще было организовано: У контроллера персонажа два режима движения: ходьба и полёт. При ходьбе работает гравитация и есть прыжки, при полёте гравитации нет, вместо прыжков полное перемещение по 2м осям. На лестницы накидываю area2d которая при появлении в нем игрока в общем случае посылает ему команду перейти в режим полёта. И всё. Несмотря на некоторую костыльность, как мне кажется, работает всё достаточно гладко. Кроме ебучих верхушек лестниц. Как я с ними ни мучился! А оказывается всё так просто было. Делаешь дополнительную area2d которая выталкивает вверх.
> то коллизии с этим слоем отключаются
Я бы так не стал делать ибо есть односторонняя коллизия.
https://www.youtube.com/watch?v=TdWWiVd1IxQ
if foo <= 1:
Остановился с ошибкой: Invalid operands 'Array' and 'Int' in operator '=='
Смотрю стек. Нахожу там foo, вижу значение: 3. В смысле да, не Array (size 4), а просто 3.
Я в ступоре нахуй. Как так-то? Как переменная может быть числом и массивом одновременно?
>Делаешь дополнительную area2d которая выталкивает вверх.
У меня ничего никуда не выталкивается. Область над лестницей просто служит ограничителем и устанавливает свой флаг onLadderTop, видя который контролер просто либо не дает ползти дальше вверх, либо позволяет ползти вниз (если игрок до этого стоит на верхней платформе и нажимает вниз)
>Я бы так не стал делать ибо есть односторонняя коллизия.
А как ты будешь слезать вниз когда ты на верхней платформе? Коллизию все равно как-то отключать придется.
>>671608
>А у меня всё проще было организовано: У контроллера персонажа два режима движения: ходьба и полёт.
Слишком просто для моего случая. У меня во время только прыжка может быть три стейта JUMP, FALL и ROLL. На лестницах тоже несколько возможных CLIMB, CLIMB_IDLE, CLIMB_WALK. Плюс еще всяких вроде IDLE, WALK, SWIM и т.д.
>Я в ступоре нахуй. Как так-то? Как переменная может быть числом и массивом одновременно?
Х.з. но с этой их динамической типизацей все возможно. Насколько я понимаю в GDScripte любая переменная может свой тип в любой момент поменять. Собсно это одна из многих причин (помимо производительности, форматирования отступами и других) почему я его дропнул в пользу C#.
>А что именно её сломало? Что вообще могло её сломать?
Ну ты же понимаешь, что однозначно это сказать можно только увидев твой проект полностью.
Попробуй как я уже писал после var collider = foo.get_collider() хоть какой-нибудь вывод сделать и посмотреть, что конкретно у тебя попадает в collider. Хотя бы ID объекта получить или его тип. Может туда нихрена не object попадает, а что-то другое. Если же попадает то, что надо, возможно придется открывать issue с багом.
Блин, а есть какой-нибудь ПОЛНЫЙ туториал по созданию контроллера персонажа в 3D со всеми нюансами типа захода на бордюры и перемещения по лестницам? Движение в одной плоскости - это легко, но лестницы уже кажутся чем-то принципиально непреодолимым, но ведь как-то их делают. Я месяц бился со своим контроллером, пока не забил на игрострой из-за всех этих дурацких проблем, и сейчас не хочу снова с этим биться чтобы снова проиграть. Готовые контроллеры не подходят, т.к. там быдлокот какой-то и вообще есть фатальный недостаток, короч никакой возможности модификации.
>Inverse_kinematics
Да при чём тут вообще инверсная кинематика? Я до этапа анимирования ещё не дополз вообще. Мне бы хотя бы кубик заставить по лестницам "шагать"... Нет, хотя бы чтобы он перестал подпрыгивать на маленьком бордюре так, будто врезается в почти вертикальный трамплин.
Вообще думаю нафиг 3D-модели, сделаю персонажей 2D-спрайтами с подменой на правильный ракурс при повороте камеры (хочу попробовать что-то типа GTA 2, только с видом сверху-сбоку, а не чисто сверху). Потому что в 3D всё равно хрень колючая получается, в 2D можно хотя бы сказать "это стиль такой". Но для этого мне сначала нужно реализовать правильное движение, а это ад какой-то, постоянно какие-то глюки, неужели так трудно было внедрить готовый контроллер прямо в движок?
Сделал print(foo) непосредственно перед сравнением. Выдаёт 3, как и следовало ожидать.
print(foo <= 1) выдаёт false. Но if после этого всё равно вываливается за несоответствие типов.
var bar: bool = (foo <= 1)
if bar:
ТО ЖЕ САМОЕ!!!!
И тут я нашёл проблему.
Кароч. На самом деле текст был такой:
1. func my_func() -> bool:
2. _ if foo <= 1: return true
3. _ if bar == 0: return true
4. _ return false
Вооот. Вываливалось всё на второй строке. Но со второй строкой на самом деле не было никаких проблем, и она работала корректно. Ошибка была на третьей строке, так как bar это на самом деле массив. У меня всё равно остался вопрос, какого чёрта дебаггер ругался не на то место, но уже понятно, что это действительно мой косяк.
Вывод: иногда дебаггер неверно указывает строку.
>>671783
Обсосали и обсудили же, что там null.
Тебе анон не просто дал статью на инверсную кинематику. Да, ты, блять не дошёл ещё до анимаций. Но когда дойдёшь, у тебя уже будет шагающий невидимыми ногами по лестницам контроллер.
>>671819
Так что, вариантов не остаётся. Ты либо сразу делаешь контроллер на инверсной кинематике, либо проигрываешь снова, потому что контроллер на простой капсуле/кубе это прошлый век геймдева. И очень верно, что ты подметил то, что все туториалы, опирающиеся на это обладают быдлокодом. Потому что пилит эти туториалы либо быдло, либо инфоцыгане. В первом случае просто бесполезный кривой туториал, во втором случае замануха для платных курсов, причём инфоцыганен может быть одновременно быдлокодером и заплатив ему ты получишь ещё один кривой туториал, но уже за деньги.
Нет туториалов. Никто в здравом уме не будет бесплатно раздавать такое. Ты либо читаешь фундаментальные статьи, типа той, что дал анон и по ссылкам из неё на источники. Либо продолжаешь раз за разом делать то же самое говно по кривым туториалам. Кстати, я уже рассказывал тебе, что такое - безумие?
>контроллер на инверсной кинематике
Разве в играх инверсная кинематика используется для чего-то кроме анимации? Это ведь когда движение ступни корректно сдвигает коленный сустав, или движение кисти руки сдвигает локтевой сустав...
Скажем, в прямой кинематике мы должны сначала согнуть бедренный шарнир, потом согнуть коленный шарнир, потом согнуть ступню. А в инверсной кинематике мы просто делаем смещение ступни по прямой, и вслед за ней сгибаются все связанные шарниры.
Вот только как это может помочь в движении по неровной местности, если инверсная кинематика никоим образом не связана со взаимодействием с поверхностями? Ну да, суставы можно согнуть, т.о. нога, визуально стоящая на кочке, будет правдоподобно сгибаться - но ведь по факту это только 3D-модель, реальная модель персонажа стоит на определённой высоте и представляет из себя точку.
Алсо, ну вот какой мне смысл симулировать смещения коленных суставов, если у меня вместо визуальной модельки будет плоский спрайт? Ведь, по факту, у меня не будет НИКАКИХ суставов...
Так, кажется, я понял. Нужно сделать вращающиеся ступни, а всё остальное тело заменить кубиком...
> Разве в играх инверсная кинематика используется для чего-то кроме анимации?
Не хочется тебе давать вредных советов. Осторожно напомню, что кинематика - это раздел физики. Следовательно, инверсная кинематика помимо анимации используется в физических движках. НАВЕРНОЕ. Чтобы естественным образом идти по лестнице, должно быть некоторое основное тело и два контрольных тела-ступни, которые инверсным образом вычисляются лежащими на поверхностях ступенек. Всё, больше ничего не скажу, чтобы не нести хуйню. Я сам в этом вопросе плаваю.
>Чтобы естественным образом идти по лестнице
>естественным образом
Так мне не нужно "естественным образом". Мне нужно, чтобы не было бесконечного сползания вниз и прыжков вверх.
>два контрольных тела-ступни, которые инверсным образом
А зачем инверсным-то? Ведь у них нет коленок. То есть они должны просто вращаться друг относительно друга как лопасти колёс парохода, "загребая" под себя любые препятствия. Ну, как я это вижу сейчас. Просто если делать реальные ступни, то придётся запариваться с их навигацией в пространстве - мы ведь ступни на ступеньки ставим не просто так, а на ощупь, следовательно опять-таки нужно мудрить с обнаружением столкновений и опять будет какая-нибудь глючная хрень...
Собственно хочется что-нибудь простое, типа капсулы, потому что у простых решений не бывает внезапных глюков. Но в готовых движках такое невозможно, наверное...
> Фигня какая-то получается.
Ну шо тут сказати? Плохо пробовал, потому что у меня получалось ещё на 3.0 по видеотуториалу (англоязычному разумеется, может в этом твоя проблема, кстати) настраивал контроллер в триде, с капсулем, не скатывающийся на наклонных поверхностях, причём угол наклона можно было регулировать. Лестницы в таком случае делаются как пандусы, без ступенек. Ступеньки просто меши, а коллижншейп = пандус. Всё как мы любили в конце девяностых начале нулевых.
Сколько-то времени назад я писал здесь, что собираюсь сделать AI на основе генетического алгоритма. И тогда я не очень понимал, как вообще это надо делать. По такому случаю сделал проект попроще, чтобы обкатать алгоритм.
Это была искусственная жизнь, ничего особенного. Но из этого проекта я извлёк два важных вывода:
1. Генетическому алгоритму нужно выстраивать баланс из условий
2. Иерархическая структура
По второму пункту поподробнее. На самом деле это почти то, что я уже давно хотел сделать с искусственной жизнью. Генотип срабатывает один раз при создании клетки, он регулирует создание органелл и их наполнение. Каждая органелла это нода, дочерняя клетке, имеет свою собственную программу - то самое наполнение. Органеллы имеют разные типы: ядро, митохондрия, хлоропласт и т.д. У каждого типа своя функция, ничего другого он выполнять не может. Например: ядро умеет только размножать, хлоропласт только питаться светом и т.д. И есть особая органелла рибосома, которая умеет выполнять умную программу: запоминать что-нибудь и сравнивать ещё что-нибудь с памятью, в зависимости от результата сравнения изменять порядок выполнения органелл. Раз в цикл действует только одна органелла, на которую указывает указатель. В норме они все опрашиваются по очереди, если только рибосома не переместит указатель.
До конца этот проект я так и не довёл. Понял, что закапываюсь и ухожу слишком далеко от главного, пришлось оставить до лучших времён. Так и не смог пофиксить джоинты, вызывавшие молчаливый краш и вообще не работавшие корректно. Не нашёл баланса, чтобы оказались полезны рибосомы. Не нашёл баланса, чтобы оказалось полезно не только уменьшение размера, но и увеличение. Доделаю демку основного проекта - допилю жизнь и обязательно поделюсь с анонами, занимательно получилось.
Но это я всё к чему. Иерархическая структура. Я понял, что применить генетический алгоритм на мобах не получится, по крайней мере, в том виде, в каком понимал тогда. Зато нашёл удобный способ организации для AI.
1. Одна нода AI управляет одним юнитом. В ней распределяются общие состояния: патрулировать или нападать, например. Каждое состояние представляет собой набор задач, каждая из которых является отдельной нодой, дочерней к основной. Всегда выполняется только самая первая задача; если их нет, включается перепроверка всего состояния и добавление списка задач заново.
2. Задание работает аналогично, только распределяет уже примитивные действия. Например: пройти до координаты. Или: стрелять. У задания есть определённые условия, при которых оно самоуничтожится и уступит место следующему заданию. Задание это такое промежуточное звено между общей задачей и последовательностью нажатий на кнопки. Действия точно так же являются нодами и добавляются как дочерние объекты, точно так же выполняется всегда самое первое действие.
3. Действия уже не могут иметь потомков, потому что они сами примитивнее некуда. Но у них есть условия самоуничтожения. Например, для стрельбы таким условием может быть пустая обойма.
Вооот. Это всё я за вчера-сегодня запилил. Теперь предстоит прописать довольно большое количество таких вот AI-нод. К ним по желанию можно добавлять всякие там рейкасты, если надо, например, оценить присутствие врага в поле зрения. Совсем-совсем простой уровень уже реализовал, болванчики ходят туда-сюда, при виде игрока стреляют.
Если кто прочитал эту стену текста, любые соображения велкам.
Бля, анон, утром прочитаю, засыпаю уже. Чисто мысль перед сном: не зря ИИ пилят на питоне. Видать синтаксис питона способствует. А раз гдскрипт потянул синтаксис, то чем чёрт не шутит, может и самые интеллектуальные боты будут у нас? А? (Будет обломно, если ты тот анон, который пилит на шарпе, мда)
https://www.youtube.com/watch?v=uuP3dOH2y6w
Краткое содержание:
Если массив объявлен, как экспортируемый, он начинает передаваться по ссылке. Если при объявлении нескольких таких массивов их проинициализировать одинаковой конструкцией [] то из-за чудес оптимизации всем им выдастся ссылка на один массив, что неочевидно и нигде не описано. Автор видоса побежал ишью пилить. А я из видоса вынес для себя, что существует возможность объявить передаваемый по ссылке массив, что может быть полезно в ряде случаев, ибо в нормальном (не экспортируемом) состоянии простые массивы передаются в гдскрипте по значению.
Баг воспроизвелся, да.
> ибо в нормальном (не экспортируемом) состоянии простые массивы передаются в гдскрипте по значению.
Тут ты не прав, я тебе уже отвечал. Массивы вседа по ссылке, так написано в доках.>>670203
