>>793623

>Вместо этого, почему никто не использует сигналы и таймеры? Это ведь производительней в разы. Какое-то дурновкусие у тех же туториалов, по которых я и обучаюсь.

Не всякое производительное решение легко объяснить, особенно ньюфагу. Если сигналы и таймеры объясняются на каком-то определённом уроке - до этого урока всё будут делать более примитивным кодом, которого в реальном проекте быть не должно. Это не ошибка, это просто последовательное объяснение сложных тем полным новичкам, с расчётом на то, что они пройдут весь курс от начала до конца не пропуская и не перескакивая главы.

Сравни это с преподаванием в обычных школах. Первокласснику не пихают в голову знания старшей школы лишь потому, что они оптимальнее или нужнее во взрослой жизни. Сначала учат писать "печатными буквами", да ещё и каждую букву своим цветом (типа согласные синей ручкой, гласные красной, ещё какие-то зелёной), что дико неэффективно, но помогает научиться (или должно помогать по замыслу педагогов). Или учат считать на каких-нибудь яблоках, на пальцах, палочки по парте раскладывать, какие-то закорючки в тетради, что взрослый человек делать никогда в жизни не будет. Учат читать сначала по буквам, потом по слогам, потом проговаривая каждое слово, а не бегло просматривая текст по диагонали. И так далее. Если ты не вылетишь из школы во втором классе, то всё будет нормально. Проблема с онлайн-туториалами в том, что никто не может заставить тебя внимательно прочитать весь курс туториалов от начала до конца, а иногда и сам автор не успевает доделать этот курс до конца или забрасывает работу над ним.

Раз уж ты знаешь такие сложные темы, как сигналы, то тебе будет лучше изучать Годо по официальному руководству:
https://docs.godotengine.org/en/stable/index.html
На русский там почти ничего не переведено, но ничего сложного там нет, это не художественная литература. А сторонние туториалы толку не имеют, они в большинстве своём пересказывают официальное руководство и ничего нового не добавляют, если только не касаются каких-то сторонних аддонов.

Чёт последние 3 недели вообще не хочется ничего делать, не могу заставить себя сесть за проект, что-то сделать. Депрессивные вопросы "зачем мне это" и так далее. Я уже не уверен, хотел ли я сделать игру или причина была в чём-то другом. Было бы круто иметь прототип игры, работающий на смартфоне, чтобы в такое депрессивное время просто лежать на кровати и играть в свою недоделку. Проблема в том, что у меня нет прототипа, который имело бы смысл портировать на смартфон.

>>795827

>Радиус подгрузки чанка меньше чем радиус выгрузки.

Круто, спасибо, именно то, что у меня вертелось в голове, но я не мог это сформулировать. Сейчас у меня чанки встают в очередь на загрузку/выгрузку, но всё происходит так быстро, что можно "мигать" чанками, находясь на границе чанков. Разница в радиусах должна помочь с этой проблемой (и с ИИ тоже).

>>795816

>Попробуй представить чанки отдельно и ИИ отдельно. Тогда постоянно деспавниться не будет.

ИИ для физического существования в мире нужен физически существующий чанк, следовательно, радиус загрузки ИИ должен быть не больше радиуса загрузки физических чанков. Если физический чанк выгружается, все ИИ в нём должны немедленно быть выгружены, иначе они провалятся "под карту". Поэтому эти системы должны быть как-то связаны между собой.

>>795813

>если это в отдельном потоке

Я не уверен, что можно безопасно взаимодействовать с деревом сцены (KinematicBody, Area и т.д.) из параллельного потока. В любом случае хотел сделать сначала однопоточный вариант, а уже потом пытаться вынести в отдельный поток, если это будет возможно, потому что параллельные системы всегда сложнее.

>>795838

>Таким образом, если даже твой бот выгрузился и вгрузился через время t, ты абсолютно точно по школьной формуле определишь, какую часть отрезка A-B он преодолел.

Я думал об этом, но боюсь того, что моя формула не будет соответствовать реальному движению KinematicBody, потому что неизвестно, что там за формулы внутри move_and_slide и других функций. Получается, два бота, идущие в загруженном и выгруженном чанках, пройдут один участок за разное время... А что на счёт VehicleBody или каких-то кастомных машинок на RigidBody? Они же вообще сложную физику для движения используют. Впрочем, наверное, я зря об этом задумываюсь, т.к. вряд ли это будет легко заметить, если не пытаться специально обнаружить.

Реальная проблема у меня не с формулами движения. Сначала было бы неплохо загружать/выгружать неподвижных ботов. Проблема в том, как их объединить в одну систему с чанками и KinematicBody, чтобы не было десятка костылей-ссылок. Вроде как решений может быть несколько, но совершенно не ясно, какое из них будет лучше. Я уже задолбался переписывать одни и те же системы на новый лад, только чтобы обнаружить, что придётся переписывать снова. Заранее всё спланировать не удаётся...

Сейчас у меня такое дерево (описываю по памяти):
- WorldEnvironment и система времени (синглтон)
- HUD с мини-картой мира (синглтон)
- данные мира
- - генератор данных мира
- - отрисовщик блока (что-то устаревшее)
- - менеджер чанков (имеет ссылку на игрока)
- - - чанки (создаются менеджером в рантайме)
- - невидимая "безопасная" платформа (лол)
- - персонаж игрока
- - тестовые машинки
- - тестовые боты
Логично было бы создать менеджер ИИ жителей, а потом связать его ссылками и сигналами с менеджером чанков... А сам ИИ держать не в нодах, а в каких-то отдельных классах, я полагаю, наследниках Resource (чтобы можно было хранить образцы в файлах ресурсов, хотя, возможно, это не пригодится). Сложно...

Всем спасибо за ответы, не ожидал.

>>795961

>Это только если они у тебя ходят по физике.

А как ещё могут ходить жители города в ГТА-лайк игре?

>Но если они будут "в фоне" ходить по маршруту, то физика им не нужна, это просто translate.

Откуда возьмётся транслейт, если житель "в фоне" физически не существует? Не существует ноды, которую можно было бы транслейтить. Или ты предлагаешь оставлять Spatial ноду в сцене? Но я как бы пытаюсь избежать лишних нод, именно для этого и нужна чанковая система (удаляет из сцены лишние ноды).

>можно добавить Plane на всю карту на уровне моря,

Костыль уровня 90-х, где ты в ГТА-подобных играх видел такое?

>>795966

>не нужна такая точность, по типу физики и т.д. Не знаю зачем вообще это нужно реализовывать.

Всё так, физика нужна только пока житель вблизи игрока (пара сотен метров, к примеру). Когда житель удаляется от игрока, игрок удаляется от жителя, житель заходит в здание или игрок заходит в здание, KinematicBody жителя должен быть удалён из сцены или вообще уничтожен, в то время как мозги жителя перейдут в фоновый режим работы - меньше тиков и более абстрактное взаимодействие с данными мира. Проблема в том, как связать это с чанками.

>Разделить карту на зоны

Эти зоны называются чанками.

Вопщем последние несколько недель я играл в разные игры и чёт совсем приуныл. Наверное, отложу свою ЖТА в сторону снова на неопределённое число месяцев. Но заняться чем-то хочется и я думаю, а что если попробовать сделать 2Д космосим-песочницу по типу Space Impossible? Этот SI уже много лет в раннем доступе и разработка еле-еле шевелится, а последний апдейт радикально изменил геймплей в худшую, на мой взгляд, сторону. Выглядит стильно (шейдеры всякие), но возможностей слишком мало. Собственно, к чему я это пишу. Кто-нибудь знает, GodotPhysics в 2D нормально тянет процедурную генерацию произвольной формы из квадратиков? Вообще на Godot имеет смысл что-то в этом роде делать? Просто широко распространено мнение, что Terraria-подобные игрые нерационально делать на движках общего назначения, и ужасно глючный и тормозной Starbound на Unity в который раз подтверждает это мнение. В общем не хотелось бы начать делать очередной проект, который закончится ничем из-за принципиальной несовместимости движка уровня Godot (или Unity, UE, без разницы вообще, они все тяжёлые, Godot 4.0 тоже будет значительно тяжелее) с такого рода играми...

>>796115
Как делать ИИ на чанковой системе я подробно расписывал в давних тредах. Копаться в архивах лень, поэтому ебану с подливой по памяти, заодно что-то дополню. Итак.
Перво наперво, твоя игра должна содержать менеджеры, управляющие теми или иными аспектами игры. Некоторые менеджеры синглтонны и их есть смысл пихануть в автозагрузку. Некоторые менеджеры временны и/или многоинстансны, их логичнее создавать при надобности.
Менеджер ИИ - синглтон. Он загружается в память и сидит во время игры всегда. Он в реальном времени обсчитывает мысли, желания и стремления всех живых существ. Ууу, чот меня понесло. В общем, он в реальном времени обсчитывает GOAP-графики всех мобов. Всех, да не всех. Всех, да не одинаково. У менеджера ИИ тебе нужно сделать несколько "ЛОД"ов, уровней детализации мышления мобов. И они разумеется, привязаны к координатам игрока. Пусть нумерация ЛОДов начинается от игрока. Стало быть, нулевой уровень, это непосредственно взаимодействующие с игроком мобы. На уровне один - мобы, которых видно. На уровне два мобы, которые за спиной, за стенами, но в пределах существующих локаций. Всем этим мобам менеджер ИИ аттачит физические тела, которые берёт по запросу у менеджера существ. Мобы (которые есть чисто математическая сущность, душа, наследуемая от Node) управляют телами, водят их по навмешу, кусают или ебут игрока, катаются с ним на машинах, ходят на обед и в туалет, смотрят футбол (или 60 минут) по телевизору и занимаются своими мобскими делами.
Когда чанк, удаляющийся от игрока выгружается, он посылает сигнал "я выгружаюсь". Мобы, стоящие на чанке навмеша, принадлежащем выгружаемому чанку локации, подписаны на этот сигнал (вообще, нужно было сказать, что они переходя из чанка в чанк подписываются на сигналы нового и отписываются от сигналов старого). И с этого момента для мобов настаёт новая жизнь. Их тела выгружаются вместе с чанком, мобы получают null в переменной, отвечающей за их тело. У них жизненные процессы затормаживаются с дельта-тайма до скажем одного тика в минуту. В таком ленивом режиме мобы некоторое время существуют, чтобы завершить свои GOAP-графики, завершить те дела, которые важны для продвижения игрока по игре. Например, подождать некоторое время, как писал анон выше, достаточное, чтобы приблизительно дойти из Вайтрана в Лос-Сантос, сесть в казино и играть там в рулетку, чтобы проезжающий мимо игрок краем глаза именно этого моба увидел. Потому что, когда локация загрузится, она получит из менеджера мира данные о том, каких мобов грузить, загруженные мобы запросят у менеджера ИИ свой интеллект, и одним из таких будет вышеописанный лениво существующий в игровом астрале Node-моб.
Ну вот, как-то так. Кто осилил - молодец. Кто понял - ваще красаучег! Кто понял и нашёл ошибки - велком к дискассу.

>>796119

>>Откуда возьмётся транслейт

>Будет высчитан математически.

В смысле? Я не понимаю, что ты называешь "транслейтом" - просто вектор смещения или поле Spatial.translation?

>Причем тут вообще ГТА?

Ты разве не видел мои прыдущие видео? Дороги, домики, мафынки, на мафынках можно кататься, а можно пешком ходить. ГТА? ГТА. Что тебе ещё нужно? Оружие? Оно не главное, ГТА - это "великий автоугонщик", в ГТА главное мафынки, жители и город.

>В ГТА когда ты отворачиваешься, жители и машины исчезают

Вот именно, вот это я и хотел бы исправить, т.е. превратить бездушные декорации в полноценную симуляцию жизни, социума и всего такого. В ГТА ты смотришь на жителя города и задаёшься вопросом, а куда он идёт, что он думает и вообще в каком состоянии сейчас находится; но в ГТА это просто тупой болванчик на рельсах замкнутого маршрута, не более чем пустая декорация. Было бы круто симулировать жизнь жителей и настроить их ИИ на эффективное выживание и размножение, а оружие максимально сократить, чтобы игрок не мог истребить весь город за пять минут. Но геймплейно и графически это та же самая ГТА, просто с более глубокой закулисной работой, чем в обычной экшн-игре.

>>796123

>есть смысл пихануть в автозагрузку

Кстати, пытаюсь от автозагрузки избавиться совсем. Имхо, это неудобно, когда делаешь прототип и нужно запускать разные сцены по отдельности. Сейчас у меня, например, мини-карта вообще отключена, потому что несовместима с остальными имеющимися системами... Что будет делать, например, менеджер ИИ, когда игра загрузила главное меню? Мир игры ещё не существует, агентов размещать негде, менеджер совершенно бесполезен. Значит, он не должен находиться в автозагрузке, даже если он нужен в единственном числе. Алсо синглтоны снижают гибкость кода, заставляя использовать в коде идентификаторы, зависящие от списка автозагрузки - я из-за этого пострадал, переписывая некоторые системы на новый лад.

>Он в реальном времени обсчитывает мысли, желания и стремления всех живых существ.

Вот это, я считаю, важная тема. Должен ли один общий менеджер обсчитывать всех агентов сразу, или у каждого агента должен быть свой логический аппарат, а менеджер должен вызывать process() каждого агента? Я считаю второе более гибким, потому что можно создать много разных агентов, и получить сложное эмерджентное поведение всей системы в целом. Особенно если ты объединяешь всех живых существ в одном менеджере.

>У менеджера ИИ тебе нужно сделать несколько "ЛОД"ов, уровней детализации мышления

Не проще ли сделать эти ЛОДы у самих агентов, и переключать их командами от менеджера ИИ/менеджера чанков?

>наследуемая от Node

Почему Node, почему не Resource/Reference? Количество Node в дереве сцены сильно ограничено (всего лишь несколько десятков тысяч) и они в таких количествах сильно нагружают одно ядро процессора, при этом у Node довольно много "лишнего" функционала. В мануале об этом даже отдельная статья есть... Именно по этой причине я постоянно вывожу на экран число активных и число скрытых из дерева нод, это важная инфа.

>Когда чанк, удаляющийся от игрока выгружается, он посылает сигнал "я выгружаюсь".

Вот этот момент не совсем ясен. Я думал о том, чтобы использовать сигналы, но не могу понять, кому их отправлять. Ведь чтобы использовать сигналы, нужно вешать обработчик сигналов. Если агенты ИИ независимо слушают сигналы от чанков, значит, кто-то должен связывать каждого агента с каждым чанком? Или лучше связывать менеджер чанков с менеджером ИИ? Сейчас у меня чанки вообще без скриптов и поэтому не могут генерировать сигналы, логично было бы генерировать сигналы с аргументами (x, y) в менеджере чанков...

Всё остальное и так очевидно. Непонятно как всё это сигналами связывать и вообще менеджить, чтобы не было лапши из ссылок. Моя тестовая версия бота оказалась совсем не подходящей из-за того, что его мозги вызываются из KinematicBody и обращаются к методам KinematicBody, а нужно что-то более абстрактное, отрезанное от KinematicBody, но при этом управляющее им, когда это возможно. Сложно это всё в голове представить (а схему чёт не додумался сделать, нужно будет попробовать начертить что-нибудь, в некоторых случаях в прошлом это мне помогало).

>>796132

> Что будет делать, например, менеджер ИИ, когда игра загрузила главное меню? Мир игры ещё не существует, агентов размещать негде, менеджер совершенно бесполезен.

var active : bool = false
И далее во всех критических участках кода оборачиваешь в
if active: ...

> каждого агента должен быть свой логический аппарат

А менеджер это менеджер, он управляет созданием и удалением агентов.

> Не проще ли сделать эти ЛОДы у самих агентов, и переключать их командами от менеджера ИИ/менеджера чанков?

Смотри сам по коду, как до реализации дойдёшь. Может и проще.

> Почему Node, почему не Resource/Reference?

Смотри сам, как удобнее.

> Вот этот момент не совсем ясен. Я думал о том, чтобы использовать сигналы, но не могу понять, кому их отправлять.

Сигналы это посты в треде. Вот у тебя допустим открыт годотред и ты видишь, как в нём появляются посты. Значит, ты подписан на эти сигналы. Приконнекчен. Если ты закроешь тред, мы, остальные аноны не исчезнем, мы будем всё так же постить посты, но ты их уже видеть не будешь. Вот так работают сигналы. Подробности в доках.

Единственный совет, который я хочу порекомендовать, в одном их прошлых тредов так же обсуждалось. В некоторых случаях может быть удобен синглтон для хранения своих кастомных сигналов. В его скрипте ты пишешь портянку из строк типа "signal hurr_durr", а потом в коде совершенно различных нод ты можешь и коннектить и излучать эти так сказать глобальные сигналы

> нужно что-то более абстрактное, отрезанное от KinematicBody

Ну вот попробуй на тестовом проекте, заведи четыре сцены, в одной напиши "signal hurr_durr", назови её signal_hub и запихни в автозапуск. Во второй, в ready напиши signal_hub.connect("hurr_durr", self, "foo") и сделай функцию foo конечно же, с каким нибудь принтом. И в третьей сцене в ready сделай signal_hub.emit("hurr_durr"). И сделай четвёртую сцену, которая стартует главной сценой, а в ней вторая и третья как чайдлы. Они могут быть разного типа, и не знают друг о друге, но когда третья дёргает сигнал, вторая, которая на сигнал подписана, выполнит свой метод, пристёгнутый к сигналу. Вот так можно абстрактной логикой связать совершенно разнотипные и инкапсулированные сущности. И не забудь, что сигналы ещё можно с аргументами объявлять. А коннекты можно с кастомными данными делать. Там такое широкое поле для манёвров - закачаешься!

>>796174

>get_tree().set_deferred("script", preload("res://твой_скрипт_наследующийся_от_SceneTree.gd"))

Бесполезный грязный хак с непредсказуемыми последствиями в будущем, зачем это нужно? Я серьёзно. Тебе дали графический редактор - описывай свои сцены декларативно, нет, не хочу декларативно, хочу вкорячивать свои скриптики туда куда не надо императивным кодом. Что мешает сделать общую для всех ноду Game и назначить ей скрипт через редактор?

>через хардлинки в файловой системе подключить папку со сценами к разным проектам

К сожалению, жёсткие ссылки в Windows никак не обозначаются в Проводнике, да и создавать их можно только через консоль. Не знаю как в Linux, возможно, проще. В общем, сложно это использовать, последствия забывания "где что" непредсказуемы. Лучше бы Godot поддерживал подключение "библиотек с ассетами" из отдельных от папки проекта папок, но насколько я знаю (читал на гитхабе), в официальной ветке этого никогда не будет из-за каких-то теоретических проблем (типа это может повлечь какие-то ошибки в проектах).

>>796175

>это просто договорённость с самим собой

У любой договорённости есть причины, о которых я и спросил.

>>796182

>Синглтон в Годо - не более чем ещё одна нода, в дереве расположенная как дочерняя к SceneTree.

Да, это можно заметить, запустив проект и посмотрев удалённую сцену. Ну а что ещё можно было ожидать.

>удобно обращаться без лишних строчек кода

А потом искать баги...

>Важные особенности:

5. Невозможно настроить экспортируемые переменные. Т.е. если ты добавляешь в автозагрузку целую сцену, экспортированные переменные должны быть настроены в самой сцене. Другими словами, никакого тебе инспектора с кастомизацией полей. Если ты добавляешь в автозагрузку не сцену, а отдельный скрипт, то вообще забудь ключевое слово "export", лол.
6. Из-за предыдущего пункта невозможно связать автоматически загруженную сцену/скрипт ссылками с другими сценами. Придётся вручную обращаться к ней и передавать ссылки на объекты, которые ей нужны для работы. Короче, придётся забыть о декларативности. С другой стороны это логично, т.к. автозагружаемые сцены/скрипты могут загружаться с произвольным набором сцен и поэтому связывать их просто не с чем. Но если у тебя вся игра в одной "комнате" (опенворлд) и переключения сцен движком не нужно, стоит ли тогда вообще использовать автозагрузку? Наверное, автозагрузка полезна только для игр, разделённых на уровни...

>ООП-философии. Гдскрипт - скриптовый язык

ООП не зависит от реализации ЯП. ООП можно использовать на любом языке программирования, просто некоторые языки имеют специальный синтаксис для этого (GDScript имеет, но сильно ограниченный, к сожалению; мне бы очень хотелось ключевые слова как минимум для приватных и публичных членов класса, и соответствующий контроль доступа со стороны интерпретатора).

>Кодишь как тебе удобно, чтобы читалось хорошо.

Проблема в том, что многие проблемные способы кодить удобны на ближней дистанции, но создают серьёзные проблемы в будущем. Простой пример: удобно создавать однобуквенные переменные, и поэтому многие страдают этим, особенно новички, но общеизвестно, что так делать очень плохо в любом проекте больше "hello world", поскольку если большинство людей очень быстро забудет предназначение таких переменных, а посторонним будет ещё тяжелее разобраться. Так что "как тебе удобно" кодить нельзя, нужно кодить так, чтобы потом не тратить кучу времени на исправление проблем, которых можно было избежать. ООП, другие парадигмы и всё остальное с этой целью и разрабатывали, чтобы писали код как положено, а не как "удобно".

>>796319

>В какой-то момент стало бесить постоянное get_tree().current_scene

А зачем получать дерево? Делаешь так:

>export var something_path: NodePath

>onready var _something: Something = get_node(something_path)

И вуаля, у тебя есть именованный доступ к какой-то части проекта, и ты при этом с самого заголовка скрипта знаешь о том, что этому скрипту требуется для работы. Даже более того, ты знаешь об этом ещё из инспектора нод, не открывая сам скрипт. А все эти обращения к синглтонам - скрытые зависимости, о которых ты узнаёшь лишь когда решаешь что-то изменить в синглтоне или удалить его. Плохо, очень плохо. В нормальных языках, например, на Паскале, ты обязан объявлять используемые модули:

>unit MyUnit;

>uses MyOtherUnit, SysUtils, Classes, MyAwesomeSingleton;

И ты сразу с первых строчек видишь, что конкретному модулю (ака скрипту) нужен для работы такой-то синглтон. А в GDScript нет такого, ты можешь написать несколько тысяч строк в одном скрипте, и попробуй потом разберись, что этому скрипту нужно.

>Экспорт тут зачем? Чтобы что?

Чтобы по-быстрому менять параметры проекта в процессе работы над прототипом или изменения баланса в уже оформившейся игре. Чтобы не бегать по коду и не менять константы в самом коде (рискуя что-нибудь сломать из-за невнимательности), а извне, через инспектор подвигать ползунки и получить новый результат. К примеру, синглтон "менеджер инвентаря" может экспортить размер инвентаря в ячейках или размер стандартной стопки предметов, чтобы можно было по-быстрому менять баланс между "ходишь с целой горой кирпичей в кармане" и "бегаешь за спичками, потому что не можешь унести больше одной за раз".

Вот только инвентарь не должен быть синглтоном. Что, если ты захочешь сделать мультиплеер на 2+ игрока? Что, если тебе понадобится сделать инвентарь у некоторых неигровых персонажей (такое есть во многих играх)? И почему вообще инвентарь отделён от игрового актёра, которому он принадлежит? Или ты подразумеваешь элемент графического интерфейса, отображающий квадратики ячеек и предметы в них? И т.д. Таким образом можно по любому "синглтону" пройтись и выявить его уязвимости.

Вообще, напоминаю, что синглтон - глобальный объект, а глобальных объектов принято избегать, поэтому синглтонов должно быть как можно меньше, как и других глобальных сущностей.
https://ru.wikipedia.org/wiki/Одиночка_(шаблон_проектирования)

>Плюсы:

>контролируемый доступ к единственному экземпляру.

>Минусы:

>глобальные объекты могут быть вредны для объектного программирования, в некоторых случаях приводят к созданию немасштабируемого проекта;

>усложняет написание модульных тестов и следование TDD;

>усложняется контроль за межпоточными гонками и задержками.

Ну тут без комментариев, лол.

>>796334

>Чтобы было автодополнение, в язык ввели регистрацию имён классов через class_name

Да, но нет. Этот механизм удобно использовать, когда у тебя есть (или планируется) много экземпляров класса. В ином случае начинается нагромождение.

>>796337

>скрытые зависимости

А как насчёт - "все зависят от синглтона, синглтон не зависит ни от кого" - ? Он же один единственный.

>И ты сразу с первых строчек видишь, что конкретному модулю (ака скрипту) нужен для работы такой-то синглтон.

Вот кстати да. Если я где-то в скрипте написал var foo: MyClass, то скрипт начинает автоматически зависеть от MyClass, что бесит. Гораздо удобнее было бы прописывать все зависимости в заголовке. Но на маленьких проектах-прототипах такой подход ускоряет написание кода.

>И вуаля, у тебя есть именованный доступ к какой-то части проекта, и ты при этом с самого заголовка скрипта знаешь о том, что этому скрипту требуется для работы

Таким образом твой скрипт увеличился на две строчки, а с синглтоном их нет. И он будет криво работать а) в самом начале, пока не всё проинициализировалось, б) если запустить сцену отдельно.

>Вот только инвентарь не должен быть синглтоном

В моём случае это не инвентарь, а скорее менеджер способностей, сменного оружия и всяких прочих штук, которые принципиально могут быть только у игрока.

>Чтобы не бегать по коду и не менять константы в самом коде (рискуя что-нибудь сломать из-за невнимательности)

Ну чёрт знает, я обычно всё объявляю в самом верху, а не раскидываю по коду. Сначала константы одним блоком, потом переменные другим блоком, красивенько их разделяю комментариями, всё подписываю и обязательно типизирую.
Ну ладно, а в чём проблема создать сцену из одной ноды, прописать ей все экспорты, и эту сцену (не скрипт) использовать как синглтон? Я так не делаю (потому что все константы держу в отдельном файле, например), но должно же работать, не?

>Вообще, напоминаю, что синглтон - глобальный объект, а глобальных объектов принято избегать, поэтому синглтонов должно быть как можно меньше, как и других глобальных сущностей.

Мне кажется, ты не столько синглтоны ругаешь, сколько методы их использования. На мой взгляд, в Годо нет принципиальной разницы между синглтоном и любой другой нодой, кроме простого доступа и постоянного висения в дереве. Любая нода в Годо - глобальный объект, к которому можно обратиться без ограничений из любого места в проекте, что-нибудь с ним сделать (вплоть до того, чтобы подсунуть исполняемый код вместо скрипта), так что надо просто смириться с этим свойством и писать код так, будто все глобальные объекты не глобальны.

>>796342

>get_node("/root/абсолютный/путь/до/ноды")

По-моему, даже в официальном руководстве было сказано, что использовать абсолютные пути - плохо. Даже get_parent() использовать не очень хорошо. Суть в том, что любая нода должна владеть только своими собственными потомками, знать она должна только о них, и обращаться напрямую ($Потомок) только к ним. Потому что расположение всех остальных нод в процессе работы над проектом может много раз меняться, да и в рантайме тоже могут потребоваться перемещения нод, и если нода пытается обращаться к предку или по абсолютному пути (не по ссылке, а через get_node()), она может обнаружить не то, что ожидает, и не факт, что проект остановится с ошибкой - ищи потом, почему у тебя игра работает, но как-то неправильно. Таким образом, все восходящие связи (потомок - родитель) должны быть через сигналы (кому надо - поймает, кому не надо - не будет реагировать), а вместо абсолютных путей в коде - настройка полей через инспектор:

>export var node_path: NodePath

>onready var node: Node = get_node(node_path)

Такая связь явно видна в инспекторе, в случае нарушения будет легко обнаружена дебаггером (если нода не найдена изначально или была освобождена раньше времени), и обращаемся мы здесь по ссылке, а не по пути в дереве, т.е. нода может свободно перемещаться в рантайме, даже совсем выходить из дерева (а в редакторе NodePath автоматически обновляется).

Почему GDScript разрешает делать то, что делать не рекомендуется? Потому что иногда это может очень сильно потребоваться, очевидно. Прямо как... костыли. Зачем ходить на костылях, если нет препятствий ходить как все здоровые люди? Нельзя привыкать ходить на костылях, а то потом проблемы будут.

>>796341

>В ином случае начинается нагромождение.

Тебе шашечки или ехать? Во всех нормальных языках у каждого класса должно быть имя, по которому к нему можно обращаться. GDScript разрешает не задавать имя класса, потому что это намного удобнее для новичков. Но без имени класса Godot не может знать, что именно ты пытаешься написать, и поэтому не может ничего подсказать. Сам подумай, ты объявил переменную типа Node, откуда Godot может узнать, что ты имеешь в виду безымянный класс из inventory_manager.gd? Без выполнения всего набора скриптов (на компьютере или мысленно) в данном случае нельзя узнать, что именно будет содержаться в этой переменной.

А нагромождение возникает из-за того, что в GDScript нет областей видимости, тех самых uses UnitName или чего-то похожего. Плохо, конечно. Но области видимости настраивать тоже сложно для новичков, видимо поэтому их и нет в GDScript. Зато порог входа очень низкий, сел и уже делаешь игру мечты.

>все зависят от синглтона

С какой это стати? Т.е. получается, что я должен ВСЕ скрипты проекта вручную просмотреть и по необходимости исправить, если захочу изменить один синглтон? А изменить синглтон когда-нибудь придётся, особенно если проект на ранних стадиях разработки.

>синглтон не зависит ни от кого

Опять странное утверждение, почему это синглтон не может от кого-то зависеть? Он что, сам всё делает? Как минимум он может зависеть от других синглтонов и создаваемых им/ими сущностей.

>скрипт увеличился на две строчки

Лол, считать строчки иди на ассемблер - ты проиграл, когда выбрал игровой движок общего назначения и скриптовый язык. Не вижу проблемы с тем, что скрипт будет больше на две строчки, которые несут в себе полезную функцию. Это даже не циклы какие-нибудь и не огромные массивы в памяти...

>в самом начале, пока не всё проинициализировалось

Слово onready гарантирует инициализацию переменной до того, как начнёт выполняться твой код в _ready(). А обработчик _init() в большинстве случаев не нужен. Что касается порядка готовности нод в дереве, то тут всё предсказуемо: сверху вниз, от самых дальних потомков к самым древним предкам. На автозагрузку это тоже влияет, если что, ты не можешь обращаться к нодам сцены из автозагруженного скрипта в его _ready(), потому что он выше по дереву и поэтому готов намного раньше основной сцены. Просто продумывай порядок действий заранее, это несложно.

>если запустить сцену отдельно

Если нода имеет зависимость от какой-то другой ноды, очевидно, нет смысла запускать её без этой ноды. Вот только если нода имеет зависимость от автозагружаемой ноды, ты не сможешь легко и просто запустить эту ноду, если в автозагрузке нет нужной ноды, или ноды нужной версии, или ноды с нужным именем и т.д. Т.е. если ты поработал над проектом и изменил что-то в автозагрузке, ты ВНЕЗАПНО обнаруживаешь, что несколько скриптов проекта превратились в тыкву и их теперь нужно переписывать или выкидывать и делать что-то другое с нуля. А если бы эти скрипты чётко прописывали свои зависимости через export, ты бы мог сохранить прежнюю версию требуемого им скрипта (или достать прежнюю версию из архива/системы контроля версий) и таким образом сохранить возможность запускать эти скрипты, даже после того, как внёс несовместимые изменения в зависимые скрипты.

Короче, автозагрузка сбивает с толку и добавляет кучу проблем на этапе прототипирования, когда системы проекта регулярно переписываются, заменяются и т.д. Да и в большом проекте скорее всего их невыгодно использовать, т.к. никогда не знаешь, когда может потребоваться полностью переделать какую-то систему, чтобы внедрить новую крутую фичу или исправить баг.

>менеджер способностей, сменного оружия и всяких прочих штук, которые принципиально могут быть только у игрока.

Ты лишаешь себя возможности сделать ботов с интересными способностями и всякими прочими штуками. Алсо не решён вопрос мультиплеера, какой-нибудь мультиплеер на двоих за одним экраном можно встроить, наверное, в любую игру. Будешь делать менеджер_способностей_игрок_2 или добавлять поддержку нескольких игроков в первый менеджер? А мог просто заспавнить второго игрока с идентичными способностями, осталось бы только изменить управление и разделить экран на два (или добавить синхронизацию через сеть и т.п.).

>всё объявляю в самом верху

Там в любом случае будет несколько экранов, особенно с комментариями и разделением пустыми строками.

>в чём проблема создать сцену из одной ноды, прописать ей все экспорты

Я до такого не додумался))

>смириться с этим свойством и писать код так, будто все глобальные объекты не глобальны.

Есть очень большая разница между аккуратной отправкой сигналов предкам (которые могут быть, а могут и не быть) и зарытым в километровые скрипты портянкам кода с чем-то вроде:

>MyBuggedSingleton.add_bugs(MyCountSingleton.Count.OVER_9000)

>if MyBuggedSingleton.is_single(): #== MyBooleanSingleton.Bool.TRUE:

>_ MyBuggedSingleton.find_bug_waifu(true, MyWaifuSingleton.Waifu.BUG)

>MyBuggedSingleton.waifu.hug(self, MyHuggingSingleton.Hug.TIGHT)

Я щас уже почти засыпаю, так что не ругайтесь, если где ошибся. Самое обидное что не знаю как найти ту статью в руководстве, где описывались проблемы, связанные с использованием абсолютных путей и т.п. Точно помню что было где-то, но читал не полностью и названия страницы не помню.

Кстати, куда делся туториал с забавной картинкой про повара? Там вроде говорилось, что разработчик игры как повар, а дерево сцены, мол, рецепт блюда, т.е. игры. Не могу найти в stable - удалили что ли? Странно, по-моему, нормальный туториал был.

>>796342

>нужную ноду дерева по её пути get_node

Фу так делать. Нет ничего более непостоянного, чем имена нод в рантайме. Один раз сделал отинстансил сцену, и вот уже она зовётся не my_scene, а my_scene@1, и хрен ты угадаешь, по какому адресу её искать в следующий раз.

>>796372

>Тебе шашечки или ехать?

Мне чтобы мой код приносил мне удовлетворение не только от результата, но и от процесса его написания, от того, как он логично внутри себя устроен.

>все зависят от синглтона, синглтон не зависит ни от кого

Разверну суть. К синглтонам обращаются самые разные ноды из самых разных частей проекта. Синглтоны - это своего рода АПИ для взаимодействия этих нод с игрой. Синглтон сам по себе не обращается к нодам и не зависит от них в гдскриптовом смысле: все типы максимально общие. Например, есть условный MyPlayerType, который наследует от KinematicBody2D, то в синглтоне будет только var player: KinematicBody2D, и во всех случаях, когда надо в нём вызвать что-то специфическое для MyPlayerType, то прибегаем к утиному вопросу has_method.
С другой стороны, если какая-то нода что-то хочет от синглтона, то никаких утят, сразу в лоб спрашиваем нужную функцию. Как она там внутри реализована, это уже другой разговор, там может быть просто pass вместо тело функции. Но она должна быть, потому что ноды пишутся под определённый игровой АПИ.
Ну и взаимодействие между синглтонами. В целом они почти не взаимодействуют. А если очень надо что-то сделать в связке, то есть синглтончик поменьше, который обращается к старшим братьям по их АПИ. Они изначально написаны так, чтобы каждый делал что-то одно.

>Если нода имеет зависимость от какой-то другой ноды, очевидно, нет смысла запускать её без этой ноды. Вот только если нода имеет зависимость от автозагружаемой ноды, ты не сможешь легко и просто запустить эту ноду, если в автозагрузке нет нужной ноды, или ноды нужной версии, или ноды с нужным именем и т.д

Ага, а если я обновил Годо, а там вдруг что-то переименовали? Ты раздуваешь проблему там, где её нет. Есть набор синглтонов, и я рассчитываю, что они в проекте есть под своими именами точно так же, как под своими именами в движке представлены функции.

>Я щас уже почти засыпаю

Пусть тебе приснится твоя готовая игра, как она хорошо продаётся на всех платформах и получает хвалебные отзывы.

А вообще, кмк, эту дискуссию пора заканчивать, ничего нового уже не скажем, и так уже начались повторы в аргументации. Свой проект переписывать, потому что анон с двача так сказал, я не буду, но определённые выводы сделаю, конечно же, зато сторонний читатель, может быть, найдёт в этом всём рациональное зерно и сделает свою игру чуточку лучше.

>>796376

>Мне чтобы мой код приносил мне удовлетворение не только от результата, но и от процесса его написания, от того, как он логично внутри себя устроен.

Понимаю тебя, но эта дрочка на код не приносит проекту пользы, и даже может приносить вред. Ты отказываешься от строгой типизации из-за "нагромождения", тем самым провоцируешь проблемы в будущем, предотвратить которые могла бы строгая типизация. Что лучше: подрочить сегодня на код и получить проблемы в будущем, или сделать по уму и не иметь проблем в будущем? Ты же не просто самоудовлетворением занимаешься, а игру делаешь... так ведь?

>есть условный MyPlayerType, который наследует от KinematicBody2D, то в синглтоне будет только var player: KinematicBody2D, и во всех случаях, когда надо в нём вызвать что-то специфическое для MyPlayerType, то прибегаем к утиному вопросу has_method.

Ну вот опять ты вставляешь себе палки в колёса ради сиюминутного удовольствия. Сегодня ты сделал MyPlayerType с методом foo(), а завтра ты сделаешь MyBarType тоже с методом foo(), но метод этот будет немного другим... Сможет ли интерпретатор GDScript предупредить тебя, что ты творишь какую-то херню? Нет, потому что формально никаких нарушений нет, синглтон получил некий KinematicBody2D, нашёл в нём метод foo() и вызвал его, с точки зрения интерпретатора код абсолютно корректен, но ты получишь не тот результат, который ожидал, и будешь ломать голову. Зато сегодня ты подрочил на кажущееся красивым решение.

Алсо мне кажется, что метод has_method() должен вызывать лишнюю нагрузку. Сам подумай, интерпретатору заранее неизвестно, ссылка на какой объект окажется в переменной, следовательно, каждый раз нужно проверять наличие метода, и это никак не оптимизировать со стороны интерпретатора. Зато можно отказаться от этих проверок, если указать более точный тип. Если этот код выполняется часто, лишняя нагрузка будет существенной. И ради чего?

>если какая-то нода что-то хочет от синглтона, то никаких утят, сразу в лоб спрашиваем нужную функцию.

Ну а ежели синглтона БОЛЬШЕ НЕТ? Ну вот так, делал-делал и потом решил выкинуть нахрен, потому что оказалось НИНУЖНО, неправильно или вовсе контрпродуктивно.

>там может быть просто pass вместо тело функции

В ООП это чревато. Если объект O ожидает от синглтона S какой-то работы, а S ВНЕЗАПНО решил её больше не делать, весь дальнейший код в O окажется некорректным, но интерпретатор тебе никаких ошибок может не выдать. В лучшем случае O сломается на обращении к null, но может он работает только с простыми типами и получит допустимое значение, которое на деле ошибочно... Короче, ты не можешь просто оставить заглушку, не проанализировав весь код, который к ней в прошлом обращался.

>Есть набор синглтонов, и я рассчитываю, что они в проекте есть под своими именами точно так же, как под своими именами в движке представлены функции.

Функции из API движка ты изменить не можешь, если ты не лезешь в исходники движка и не собираешь свой форк движка. А свои синглтоны ты можешь свободно менять и будешь менять в процессе жизни проекта, особенно на начальных этапах, но и в будущем тоже. Глупо надеяться с первой попытки сделать всё правильно и потом никогда ничего не менять. Такое возможно только в самых мелких проектах, которые можно за недельку на коленке состряпать и потом больше не притрагиваться.

Вон, даже сам Годо существенно меняет API в 4.0, и до бета версии это самое API может ещё несколько раз измениться (поэтому не рекомендуют портировать большие проекты или делать что-то серьёзное на альфа версиях). Это нормально, просто осознали, что лучше сделать по-другому, и сделали по-другому. Но пользователям теперь весь код перебирать и исправлять кучу всего, особенно того, что касается 3D. Окей, возможно, что-то конвертируется автоматически, но это движок, со своими синглтонами ты такого провернуть не можешь (точнее можешь, но оно того не стоит - масштабы совсем не те, чтобы автоматизировать).

>как она хорошо продаётся на всех платформах и получает хвалебные отзывы

Ой, да пофиг на продажи и отзывы. Игроки будут нахваливать что угодно, не бывает играбельных игр с 0% рейтингом отзывов. А чтобы добиться продаж, нужны вложения в рекламу, качество игры в данном случае вторично, важен рекламный бюджет. В любом случае, я делаю хочу сделать игру для себя, и это даже скорее не игра, а эксперимент или площадка для экспериментов... Всё очень сложно, как ты понимаешь, у меня нет чёткого видения проекта. Забавно, но у меня есть множество других концепций игр, пусть полузабытых и плохо документированных, но они намного чётче (я даже мысленно играл в них, а этот проект мысленно не могу представить как целое), вот только мне совершенно не хочется над ними работать, интерес угас. Может, стоит сделать что-то простое, но завершённое, чтобы поднять мотивацию и силы для работы над этим проектом...

>>796378

>речь не о строчках, а о красоте кода

Сгруппируй строчки по категориям и будет красиво.

>И тут _process такой: просто здравствуй, просто как дела. А за ним _input: мышиные движения готовности не ждут.

Делаешь отдельное поле status и проверяешь:

>if status == Status.READY:

Тебя ведь не смущает перед каждым обращением к методу дёргать has_method()? Ну вот эта проверка очевидно быстрее has_method() и в целом полезнее, т.к. можно сделать разные статусы. А для совсем простой системы будет достаточно флага ready.

>>796385

>сетгеты стопудово запускаются

Вроде сетгет не запускается, если ты обращаешься к свойству класса из методов этого класса. Хрень какая-то, если честно, лишает сетгеты смысла, т.е. изнутри класса ты должен вручную делать set_foo(bar) вместо присвоения foo = bar. Хотя могу ошибаться, но меня это сильно смутило, т.к. на Паскале property позволяет запускать сеттеры и геттеры в том числе из методов класса, которому они принадлежат.

>>796403

>Ну дык всё обсуждение сводится к

>>Если я вот тут так напишу, будет ошибка

>>Не пиши так

>>Азаза, но гдскрипт же ПОЗВОЛЯЕТ!!11

Моя позиция в том, чтобы не использовать автозагрузочные синглтоны без крайней на то необходимости. То есть при любой возможности нужно создавать ноды в дереве сцены и связывать их между собой через экспортируемые переменные и сигналы. Это безопаснее и делает связи более очевидными. А если автозагрузку всё-таки придётся использовать, тогда да, ходишь как по минному полю, то не пиши, это не делай, вот это не работает, вон то работает, но не как обычно... СЛОЖНА и не очень-то полезно, т.к. ту же функциональность можно получить из обычных нод в сцене.

>>796504

>Ты отказываешься от строгой типизации из-за "нагромождения"

Где? Да я даже функциям прописываю -> void и все переменные типизирую.
Нагромождение лишних строчек, когда можно то же самое сделать из редактора, да, не люблю. Засорять интерфейс редактора классами, которые существуют в единственном экземпляре, тоже не вижу смысла. Это вот да.

>>796504

>Сегодня ты сделал MyPlayerType с методом foo(), а завтра ты сделаешь MyBarType тоже с методом foo(), но метод этот будет немного другим

Опять ты сводишь разговор к "завтра ты будешь не ты, начнёшь рисовать одуванчики вместо кода, и всё посыпется". Этот оборот имеет смысл только в большой команде и только если никто не читает документацию к АПИ проекта.

>мне кажется, что метод has_method() должен вызывать лишнюю нагрузку.

Тебе кажется. У нас тут скриптовый язык,

>Ну а ежели синглтона БОЛЬШЕ НЕТ?

Из-за санкций?Использовать поиск по файлам при таком крупном изменении в проекте религия не позволяет?

>Короче, ты не можешь просто оставить заглушку, не проанализировав весь код, который к ней в прошлом обращался.

Да ты что! Если ты пишешь код, обращаясь к функции-заглушке, внезапно ты должен знать, что она пока не написана - вот ведь открытие! Внезапно ты должен отметить себе в тудулист, что там вот пока заглушка, надо в будущем написать. Внезапно надо отслеживать весь процесс и знать, где чего не хватает, не когда уже интерпретатор ругается, а на этапе написания кода. А мужики-то не знают!

>со своими синглтонами ты такого провернуть не можешь

Ctrl+Shift+F. Конечно, предполагается, что все синглтоны и их функции имеют достаточно уникальные имена, чтобы таким методом их можно было найти везде. Ну и при крупном изменении, конечно же, надо у себя где-то отмечать процесс его применения.

>Делаешь отдельное поле status и проверяешь

Терпеть не могу так делать.

>Тебя ведь не смущает перед каждым обращением к методу дёргать has_method()?

Совершенно не смущает, если это не в _process у тысячи нод, а в каком-нибудь разово вызываемом методе в синглтоне.

>Вроде сетгет не запускается, если ты обращаешься к свойству класса из методов этого класса

Сетгет обязательно запустится при инициализации экспортного поля, и это происходит до _реади.

>Хрень какая-то, если честно, лишает сетгеты смысла

Сделано всего лишь для того, чтобы присвоение внутри сеттера не вызывало рекурсивный вызов сеттера. А так вообще где угодно можно написать self.foo = bar и вызвать таким образом сеттер.

>Моя позиция в том, чтобы не использовать автозагрузочные синглтоны без крайней на то необходимости.

Да поняли уже. Ты молодец.
Моя позиция в том, чтобы использовать автозагрузочные синглтоны как АПИ игры.

>Ой, да пофиг на продажи и отзывы

Не душни, тебе лучи добра посылают.

>Может, стоит сделать что-то простое, но завершённое, чтобы поднять мотивацию и силы для работы над этим проектом

Ага, я именно с такой мыслью начал нынешний проект больше месяца назад. Правда, там действительно совсем чуть-чуть кодить осталось, и можно будет переходить к стадии наполнения контентом. Но не суть. Главное что в целом метод "сделать что-то простое, но завершённое" хоть и рабочий, но обманчивый.

>>796550

>Засорять интерфейс редактора классами

Лол, это и есть типизация. Твой player по ООП не является "KinematicBody2D", он должен являться экземпляром Player, короче, отдельный класс. Годо позволяет тебе избежать индивидуального именования классов, но по-хорошему так делать нельзя. Отказываясь от class_name ты отказываешься от правильной типизации.

>завтра ты будешь не ты

>Этот оборот имеет смысл только в большой команде

"Завтра" - это гипербола. Пройти может неделя, месяц или год. И если ты не вундеркинд с фотографической памятью, который помнит абсолютно всё что видел со 100% точностью, то со временем ты обязательно, гарантированно забудешь, из чего состоит и как работает твой собственный код, который ты писал когда-то в прошлом. И в зависимости от твоей организованности, ты либо потратишь кучу времени на изучение своего кода, либо быстро что-то напишешь и потратишь ещё больше времени на поиск ошибок. Учитывая твоё отношение к коду, вероятнее всего второй вариант развития событий. Успехов в поиске ошибок, которых можно было бы избежать, но тебе лень.

>>has_method() должен вызывать лишнюю нагрузку.

>Тебе кажется. У нас тут скриптовый язык

Ну и? Этот метод должен сравнить строки-имена методов или связанные с ними числовые ключи. И чем больше методов в классе, тем больше сравнений в среднем. К чему этот костыль, если можно просто объявить конкретный тип класса?

Другое дело, если бы тебе реально было необходимо обрабатывать несколько совершенно разных классов с одной общей функцией. Я таким образом сделал функцию interact(), которую можно повесить на любой объект, сделав его интерактивным. Но думается мне, что это всё же неправильно и нужно будет переделать...

>Использовать поиск по файлам

И потом вручную исправлять все 100500 вхождений? А потом ловить ошибки из-за того, что нельзя было просто закомментировать строку, нужно было сделать что-то другое, но ты ведь не помнишь, что делает именно этот кусок кода, который ты писал в 2020.

>должен знать, что она пока не написана

Это противоречит принципу инкапсуляции, когда о состоянии какого-то элемента класса знает только сам класс. Если метод класса называется do_some_work(), то он действительно должен сделать какую-то работу, а не пукнуть в консольку и завершиться без выполнения заявленной работы.

>отслеживать весь процесс и знать, где чего не хватает

К счастью, я не обладаю фотографической памятью, а буфер оперативной памяти у меня такой же, как и большинства людей, соответственно я не могу удерживать в памяти десятки "туду" обо всём, чего не хватает моему коду. Пока пишешь одну функцию, ты фокусируешься только на ней, всё остальное вылетает из твоей оперативной памяти и это совершенно нормально для человека. Возможно, ты действительно гений с экстраординарными способностями...

>Ctrl+Shift+F

Мало просто найти, нужно знать, как изменить код в каждом конкретном случае, но скорее всего ты этого не знаешь.

>Терпеть не могу так делать.

Аргументы будут или это субъективное нежелание?

>Сделано всего лишь для того, чтобы присвоение внутри сеттера не вызывало рекурсивный вызов сеттера.

Что мешало сделать это ТОЛЬКО в теле непосредственно сеттера/геттера? Компилятор Паскаля (и, наверняка, компиляторы и интерпретаторы множества других ЯП) так может, почему тогда интерпретатор GDScript такую фигню творит? Вот же, написано программистом "setget", почему интерпретатор не принимает это слово во внимание?

>self.foo = bar

Костыль.

>АПИ игры

Исходя из https://semver.org/lang/ru/ стабильное АПИ может быть только с версии 1.0.0, в то время как версии 0.x предназначены для быстрой разработки, когда АПИ очень часто и сильно меняется. Т.е. окей, после релиза игры нельзя вносить случайные изменения в АПИ, иначе это будет уже 2.0 версия, но на этапе разработки 0.x изменения неизбежны. И чем сложнее их вносить, тем хуже для проекта. Автозагрузка усложняет внесение изменений.

>>796638

>_ready() аналог main() точки входа

Нифига подробного, выход из main = завершение программы.

>напишем так: get_tree().root.call_deferred("add_child",

Зачееееееем...

>get_node("/root/main_menu")

ЗАЧЕЕЕЕМ???

Тебе Хуан дал тебе export ...: NodePath, нет, не хочу экспортировать и тыкать мышкой в инспекторе, хочу костыли велосипедить и потом страдать из-за палок в колёсах своих велосипедов.

>просигнализирует (правда только в ран-тайме)

Ага, а с помощью export ты узнаешь о необходимости подключения какой-то специфичной ноды ещё до запуска проекта.

>Причем ещё в дизайн-тайме.

Вот это и плохо с "синглтонами", 100500 ошибок "скрипт не может быть проанализирован", приходится 100500 раз перезагружать редактор, чтобы исправить ошибки, которые мешают ему прочитать скрипты, в которых больше нет ошибок. Даже кнопка в меню есть "перезагрузить проект", знают прекрасно что редактор багнутый, но, видимо, ничего исправить пока не могут.

>Обошёлся без юзингов, импортов и прочей дремучей легаси

Повторяю, без этого можно только хэллоуворлды нубасам преподавать, для чего-то серьёзного это не подходит. В конце концов, делая сложный проект, ты дойдёшь до того, что будешь в комментариях к заголовку скрипта указывать, от чего этот скрипт зависит, вот только интерпретатор не сможет тебе подсказать, если ты ошибся в своём комментарии или он уже неактуален. А ключевое слово uses, import и т.п. тем и хорошо, что проверяется программой, то есть невозможно наломать дров и не заметить этого.

Да, кстати, главное достоинство слова uses в том, что оно ограничивает (вернее, расширяет) область видимости в рамках одного скрипта. Годо подразумевает, что из каждого скрипта видно вообще все остальные скрипты проекта и всё АПИ движка - это удобно в маленьких проектах, но становится сплошным неудобством и болью в сколь-либо больших проектах, где могут быть тысячи скриптов. Алсо именно из-за отсутствия uses невозможно использовать скрипты из других проектов, не копипастя их вручную, потому что Годо ограничивает видимость одной папкой проекта; на серьёзных ЯП ты можешь использовать юниты из любых папок на диске, расширяя видимость как тебе, лично тебе нужно, а не как задумал какой-то Хуан.

Надеюсь, со временем Хуан одумается и у нас будет какой-то аналог uses в GDScript. Для нубов это можно сделать опциональным: в настройках проекта сделать галочку "каждый скрипт видит все остальные скрипты", которая по умолчанию установлена, а если эту галочку снять, придётся добавлять в скрипты uses something.gd, иначе не запустится или упадёт с ошибкой доступа. В режиме по умолчанию эти ключевые слова игнорируются, т.к. расширяют и без того максимальную область видимости.

>>796688

>Лол, это и есть типизация. ... но по-хорошему так делать нельзя

Именно потому что так делать можно, я так делать буду. Я прописываю class_name либо если от скрипта кто-то будет наследоваться, либо если планирую это имя где-то употреблять. А от ООП в гдскрипте всё равно лишь огрызки, не вижу смысла гальванизировать труп.

>"Завтра" - это гипербола

Da_ladno.jpg

>гарантированно забудешь, из чего состоит и как работает твой собственный код, который ты писал когда-то в прошлом

Вот поэтому я комментирую почти каждую строчку и веду журнал разработки. С тех пор, как начал это делать, время вспоминания сократилось до "о, точняк, вот же как это было".

>Другое дело, если бы тебе реально было необходимо обрабатывать несколько совершенно разных классов с одной общей функцией.

Ну так да. Именно.

>И потом вручную исправлять все 100500 вхождений?

Погоди-ка, давай разберёмся, о какой ситуации мы говорим.
а) Ключевое слово изменилось, но суть осталась та же. Просто используем поиск и замену.
б) Ключевое слово пропало. Закомментировать все вхождения и посмотреть, что будет. Вряд ли это было что-то сильно важное, раз я его так без проблем выкинул.
в) Изменилось число аргументов или тип данных - в общем, что-то более сложное. А хорошо ли я подумал, прежде чем вообще делать такие изменения в проекте? Ну тогда ССЗБ.
Ещё раз. Изменения в АПИ - это ответственный шаг. Надо заранее подумать и написать всё с заделом на расширяемость и гибкость, чтобы потом не кусать локти, когда проект вырастет и вдруг надо будет что-то поменять.

>Это противоречит принципу инкапсуляции, когда о состоянии какого-то элемента класса знает только сам класс

Не подменяй понятия, речь шла о том, что я знаю о состоянии элемента, а не о том, что знает класс.

>К счастью, я не обладаю фотографической памятью, а буфер оперативной памяти у меня такой же, как и большинства людей, соответственно я не могу удерживать в памяти десятки "туду" обо всём, чего не хватает моему коду.

Так-то и у меня не фотографическая память. Спасает тетрадочка (обычная физическая на 96 листов), куда я записываю все свои туду. И баги туда же. И вообще любые замечания по проекту. Периодически пролистываю недавние записи и переношу на одну страницу все активные туду. Выполненные вычёркиваю. И ещё там же схемы зарисовываю, как что устроено в проекте.

>Мало просто найти, нужно знать, как изменить код в каждом конкретном случае, но скорее всего ты этого не знаешь.

Хммм... И как же мне изменить все обращения к одной и той же функции, которая везде работает одинаково? А, точно! Вот же в комментариях написано, что она тут иначе работает.

>Аргументы будут или это субъективное нежелание?

В данном случае чистая субъективщина. Просто всегда, когда я начинаю прибегать к подобным костылям, вокруг них начинает вырастать целая гора исключений, и в конечном итоге я прихожу к выводу, что изначально надо было выстроить цепочку действий иначе.

>Компилятор Паскаля...интерпретатор GDScript фигню творит

Наверное, потому что для паскалеподобного поведения ему нужно знать, что вызов идёт внутри сеттера-геттера. Компилятору проще с этим, он не ограничен по быстродействию. Предполагаю, что дело как раз в том, чтобы не проверять каждую строчку, а не сеттер ли у нас сейчас выполняется.
Или другое предположение: это лишнее исключение, которое только запутает логику написания кода.

>И чем сложнее их вносить, тем хуже для проекта. Автозагрузка усложняет внесение изменений.

Утверждение про автозагрузку тут не пришей кобыле хвост. Автозагрузка ничем не отличается от обыкновенного АПИ.

>>796711

>от ООП в гдскрипте всё равно лишь огрызки

Што? Тебе объектов недостаточно? Или объекты - не ООП? Это другие ЯП слишком расширяют ООП ненужным мусором, а так достаточно собрать данные и функции для обработки этих данных в одном месте. Даже специальных ключевых слов языка не нужно.

>Вот поэтому я комментирую почти каждую строчку и веду журнал разработки.

1. Мне это не помогает, например.
2. Комментировать слишком много - тоже антипаттерн, говорящий о том, что код сложно понять без комментариев; следовательно, нужно переписать код так, чтобы он стал понятнее и без комментариев. К примеру, ввести или конкретизировать типы там, где приходится в комментариях описывать, с чем работает кусок кода, потому что типы несут именно эту роль.
Вместо:

>var obj: Spatial // движимые коробки из movable_box.gd

Что-нибудь вроде:

>var obj: MovableBox

И сразу понятно, что это взаимодействие с movable_box.gd.

>тетрадочка обычная физическая

Что мешает использовать программы? Я последний раз к тетрадям в школе прикасался, такая гадость, кожа болит от бумаги, а если не болит кожа - страницы впитывают пот и портятся))

>знать, что вызов идёт внутри сеттера-геттера

>не проверять каждую строчку

Какие строчки? GDScript же компилируется в байт-код, не? В любом случае, сделать одну отметку "это сеттер/геттер" в памяти не проблема, учитывая что код выполняется не построчно, а после полного чтения. Построчное выполнение исходников действительно имело бы массу проблем, но Годо не вчера начали делать и таких наивных реализаций в нём быть не должно. Компилятор Паскаля просто в один проход делает машинный код, а Годо сначала делает байт-код, потом из него, грубо говоря, машинный код (ну, переходы к каким-то участкам ядра Годо, которое в машинном коде). Если бы Годо выполнял наш код построчно, тормоза были бы в разы сильнее, потому что работа со строками сложнее работы с числами.

Так что это просто какое-то неудачное дизайнерское решение, мол, вызывайте явно set_foo(), get_foo() или self.foo, непонятно только зачем тогда объявлять setget для полей, используемых самим классом или преимущественно самим классом.

>Автозагрузка ничем не отличается от обыкновенного АПИ.

Я уже объяснял, что "обыкновенный АПИ" разрабатывается отдельными людьми и меняется редко, а над игрой ты ведёшь активную работу, особенно в самом начале, особенно если новичок. Автозагрузка мешает свободно экспериментировать, а именно свободу таких экспериментов считают преимуществом Годо.

Был бы ты доволен, если бы в твой набор деталек Лего вмешивался строгий дядя и говорил, что вот эти детальки можно размещать только в таком порядке, потому что две недели назад ты с ними поиграл именно в таком порядке, и теперь должен расхлёбывать последствия нечаянно принятых важных решений, о которых тебя никто даже не пытался предупредить? Да, Годо сам по себе игрушка, достаточно простая для освоения, просто так получилось, что в нём можно делать игры. Они сами хвастаются, что Годо сделан на Годо, значит (редактор) Годо - это такая игра с глубоким многосторонним геймплеем)))

>>796791

>геттеры вида get_item_...(index) получаешь данные напрямую. Тупо, не ООПно, ну как есть.

Лол, а как ещё предлагаешь?

>item_list.item_aaaaa = ...

>item_list.item_bbbbb = ...

Так что ли? Хрень какая-то, зачем элементам списка ​имена?

Список элементов предназначен для однородных текстовых данных, которым не нужно ничего кроме вывода текста и которые никак не нужно идентифицировать кроме номера строки. При этом этих элементов может быть неизвестное заранее количество. Это очень полезный компонент, например, в меню сохранения и загрузки чего-либо, особенно если слотов для сохранения неограниченное количество. Ты просто выводишь список имён файлов в компонент, а потом получаешь ID строки, которую выбрал пользователь - ВСЁ! Никакой головной боли с созданием уникальных объектов, их настройкой и т.д. Просто загоняешь набор строк и получаешь в ответ номер выбранной строки.

>>796886

>меню паузы: Продолжить, Сохранить, Загрузить, Настройки, Выход

Слишком располагает к сейвскаму. Лучше так:

>Продолжить

>Настройки

>Сохранить & выйти

А загрузку только из главного меню.
В Террарии и Майнкрафте, например, именно так.

>нажимаете клавишу I

>повторным отжатием I

>окно инвентаря

УГ мамонта, которое должно было умереть в 80-х. Чем я от WASD и мыши должен тянуться к I? Биндят самые часто используемые функции в середину клавиатуры, не давая ребиндить, и удивляются потом, что на их игру негативные отзывы. Что мешает использовать таб, или, на крайний случай, близкие к WASD буквенные ​клавиши? А все остальные меню могут быть вкладками окна инвентаря, потому что нечего создавать кучу отдельных окон.

>игра может встать на паузу или не встать,

>нажмёте ESC, то меню пазы не появится, сначала закроется инвентарь,

>при нажатии ESC всё ставится на паузу,

Я бы попробовал совместить всё в одно меню, открывающееся по Esc, в котором на разных вкладках можно найти и инвентарь, и карту мира, и справку, и настройки, и выход из игры. А пауза может включаться или не включаться в зависимости от выбора игрока в настройках игры, и переключаться отдельной кнопкой в этом меню, если автопауза отключена. Всё просто, ничего лишнего.

>>796994

>сейвфайлами на диске манипулировать

Ну это нужно совсем упороться. Тот же Майнкрафт... Там есть режим хардкор. Да, можно делать бекап мира, и тогда даже когда игра удалит твой мир, ты можешь его восстановить. Но в чём тогда смысл играть в этот режим, если ты ломаешь его суть? Просто играй в обычном режиме, с бесконечным числом жизней. Аналогично с хардкорными персонажами Террарии, которые удаляются игрой после первой смерти (мир остаётся существовать): зачем создавать такого персонажа, если ты планируешь восстанавливать его из бекапа? Просто создай персонажа лёгкой или средней сложности.

>простые игроки будут жаловаться, что до босса далеко идти.

Хех, мда, ну что ж, делай чекпойнты ближе друг к другу, в чём проблема? Я же говорю, запрещать квиклоады, а сохраниться можно в любом месте по нажатию кнопки "выход". Т.е. простой игрок, без манипуляции файлами, может только закрыть игру с автоматическим сохранением мира, и затем загрузиться в том же месте, где вышел. Чтобы не было такого "ой, я проиграл в лотерею, загружу квиксейв, который сделал 30 секунд назад и попробую сыграть снова".

>>совместить всё в одно меню

>Слишком располагает к сейвскаму))

С чего вдруг? Вот в GTA 5 карта мира, меню с информацией, меню настроек и прочее на одной карусели расположены. Ещё где-то подобное видел, не помню уже. Просто не добавляй в это меню квиксейвы и квиклоады, и не будет соблазна сейвскамить.

Вообще, касательно сейвскама, лично я ближе к простым игрокам, т.е. не буду манипулировать файлами в большинстве случаев. Умер и умер, проиграл так проиграл. Но если в игре есть грёбанные ХОТКЕИ специально для сейвскама (F5/F6), то рано или поздно я начну ими пользоваться и это будет меня дико БЕСИТЬ, потому что соблазн загрузиться и поменять ход истории слишком велик - достаточно нажать всего одну кнопку. В то же время манипуляции файлами намного сложнее нажатия хоткея, поэтому заниматься ими я, скорее всего, не буду, а если игра слишком сложная - скорее брошу игру, чем буду пытаться её переиграть тем или иным способом. Вот я о чём, чтобы не было лишнего соблазна там, где можно обойтись без этого, а не чтобы помешать всем любителям сейвскамить.

>>796995

>Слишком расточительно сохранять игровой мир целиком в сейв-файл.

Нипонел. Ты прям .tscn в сейв-файл пишешь? В сейве должны быть только абстрктные данные, которые загрузчик накатывает на какие-то сущности в сцене, загруженной из res://. Я так считаю. Тогда никакой расточительности, если у тебя обычный шутан, а не какой-нибудь майнкрафт с миллиардами кубиков. Майнкрафт же использует специальные техники сжатия данных, без них никак.

>Мир-корректировка

Рано или поздно ты допустишь ошибку. Забудешь что-то сохранить или загрузить. В результате у игроков сломаются сейвы и игровой процесс, игра станет непроходимой. Алсо нужно учитывать важный момент, что если ты патчишь релизнутую игру, твой патч не должен ломать игрокам сейвы, в идеале, конечно. Вот что будет, если твой патч затрагивает "эталон", делая "корректировку" некорректной?

Ну а так, если сделать какой-то универсальный алгоритм, который не будет подвержен ошибкам и будет обходить проблему патчей, тогда всё норм, такой укороченный сейв должен быть полезен, по идее.

>>796998

>class_name MyData

>extends Reference

Если вместо Reference использовать Resource, то можно будет:
1. Создавать и заполнять объект этого класса прямо через инспектор нод, в тех нодах, которые экспортируют поле Resource.
2. Сохранять заполненный объект в файл и загружать из файла через код или мышкой в инспекторе.
Т.е. Resource в каком-то смысле урезанный Node, единственное что он не умеет - находиться в дереве сцены самостоятельно.

>var my_data := MyData.new().data.duplicate(true) # Поскольку MyData наследуется от Reference, он отдаст данные и уйдёт в ГЦ.

А зачем ты делаешь .new() и сразу освобождаешь его? Это создаёт лишнюю нагрузку на кучу и сборщик мусора в куче. Либо храни этот объект где-то и получай ссылку на него, либо создавай новую копию и храни её как объект. Вместо Data := {} ты можешь создать набор конкретных переменных, чтобы не было лишнего слова. Dictionary по сути тот же ООП объект, создающийся в куче, и я не вижу смысла использовать его вместо Reference, не вижу смысла использовать Reference как одноразовый контейнер для Dictionary.

>>798096
Ты допускаешь типичную ошибку новичка, задающего вопросы в интернете. У тебя есть некая проблема X, для решения которой ты попытался применить Y, но у тебя не получилось, и теперь ты спрашиваешь решение Z для работы Y, хотя на самом деле тебя интересует X, а не Y. Значит, спрашивать ты должен об X.

>функция, которая выдаёт номер, если он содержится в имени

У String такой функциональности нет.
https://docs.godotengine.org/en/stable/classes/class_string.html

>>798097

>add("Foo", "replace")

>add("Foo", "rename")

К теме не относится, но лучше сделать

>replace("Foo")

>rename("Foo")

Либо, если тебе очень нужен универсальный метод add(), использовать enum:

>enum AddMode {REPLACE, RENAME}

>func add(text: String, mode: int = AddMode.REPLACE) -> ...

Сравнение строк в любом ЯП занимает значительное время и делает код менее предсказуемым по времени (разные строки сравниваются разное время), поэтому лучше избегать использования строк в своём коде всегда, когда это возможно. В то же время enum - это просто целое число, которому присвоен идентификатор для удобства чтения исходного кода программы.

>Похоже, без обхода массива тут не обойтись

Можно, если использовать отдельный массив счётчиков.

>>798101
Твой код не даёт использовать пробелы в строках, кроме пробела перед числом; использует сравнение строк, которого будет тем больше, чем больше строк в массиве; использует сортировку массива чисел, которая тоже займёт существенное время, если будет много строк с одним и тем же "именем".

Возвращаясь к первому абзацу, какую задачу ты пытаешься решить? От характера задачи зависит то, какое решение будет более эффективным в плане времени/памяти/сложности реализации. Твоё решение подойдёт только если массивы небольшие и обращения к ним происходят редко, иначе всё будет тормозить.

Я бы на твоём месте создал отдельный словарь счётчиков, в котором каждой уникальной строке соответствует число-счётчик. Тогда при добавлении любой строки мы проверяем, какое следующее по порядку число мы должны добавить, и увеличиваем счётчик или создаём новый, если это первое вхождение строки. Но такое решение не подойдёт, если тебе нужно удалять строки с промежуточными номерами и затем заполнять "пробелы" в последовательности чисел, потому что счётчик всегда указывает на последнее использованное число, не учитывая "пробелы" в последовательности.

Чисто по скорости, Dictionary в GDScript вроде достаточно быстро работает благодаря хэшированию строк, т.е. тебе не нужно вручную перебирать все строки, достаточно обратиться по названию:

>var lines: Array

>var counters: Dictionary

>func add(line: String) -> void:

>_ if not counters.has(line):

>_ _ counters[line] = 0 # новый счётчик

>_ lines.append(line + str(counters[line]))

>_ counters[line] += 1

Если тебе нужно это всё проделать единожды и потом словарь со счётчиками больше не нужен, можешь сбросить ссылку на него, и сборщик мусора должен освободить занятую им память:

>counters = null

Совсем другое дело, если тебе нужно динамически добавлять и удалять строки, постоянно поддерживая целостность последовательности номеров, присвоенных этим строкам. В таком случае, я считаю, лучше вообще отказаться от хранения строк, соединённых с номерами, хранить номера отдельно от самих строк и объединять их только когда нужно получить строку с номером. Если у тебя будет много повторяющихся длинных строк, можно пойти ещё дальше и избежать повторений самих строк, создав три отдельных массива: массив с уникальными строками, массив с номерами строк, и массив, в котором уникальная строка соединяется с соответствующим ей номером... Эээ, правда, есть один нюанс: из-за того, что массивы в GDScript хранят ссылки, такая конструкция может оказаться не столь эффективной или даже вредной, так что нужно проверять на практике, что будет лучше. В любом случае, т.к. строка хранит длинный набор Unicode символов, пачка указателей на одну строку должна быть лучше множества копий этой строки.

В общем, всё зависит от твоей исходной задачи.