>>2519
Скажи честно, как часто тебе ПРИХОДИТСЯ делать что-то такое?

>ГлобальнаяСущность.какое_то_свойство = значение

>ГлобальнаяСущность.какое_то_действие(значение)

И главное: ПОЧЕМУ тебе ПРИХОДИТСЯ это делать именно так?

Задумайся. Прислушайся к своим ощущениям. Почему ты так делаешь?

Скорее всего, твой ответ будет примерно таким:

>Мне так удобно. Это быстро приводит к решению текущей задачи.

Но ты никогда не задумывался, какой ценой даётся это решение?

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

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

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

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

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

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

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

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

Наконец, рассмотрим "синглтоны". Что такое "синглтон"? Это уникальный и глобально доступный объект, создающийся в самом начале программы и удаляющийся перед завершением программы. В сущности, это ООП-костыль, возвращающий нас во времена, когда никаких объектов не было и все данные в памяти были доступны из любого участка кода, а все функции вызывались из любой другой функции. Если посмотреть ещё глубже в историю - это аналог беспорядочного GOTO/JUMP в коде программы, т.к. позволяет напихать спонтанных переходов неизвестно откуда неизвестно куда. Это буквально сознательный отказ от всех правил ООП ради "удобства" решения задачи: вместо создания вспомогательных объектов, запроса объектов извне, аккуратного управления объектами, ты просто втыкаешь глобально доступный рычаг, за который можно дёргать откуда угодно и когда угодно.

Что ж, всё ещё не видишь проблемы синглтона? Тогда ты не видишь проблемы GOTO/JUMP. Может, попробуешь сделать игру на ассемблере? Только что-нибудь посложнее давай, крестики-нолики любой дурак сделать сможет даже на ассемблере. Или скажешь, что это слишком сложно? А почему тебе так сложно писать на ассемблере без всех удобств высокоуровневых ООП языков? Может быть, потому что "неудобные" правила ООП придуманы, на самом деле, для удобства? И отказываясь от этих правил ты деградируешь до времён хаотичных прыжков по памяти и по инструкциям.

Я понимаю, лень сложно признать. Мы генетически захардкожены экономить энергию - и наш древний мозг не может понять, зачем ему тратить энергию прямо сейчас, если он может её сэкономить. Наш древний мозг говорит нам: если вот здесь воткнуть GOTO, мы быстрее решим задачу; если вот здесь обратиться к глобальной переменной, мы быстрее решим задачу; если воткнуть вот этот глобальный рычаг управления, мы быстрее решим задачу. Проблема в том, что наш древний мозг не способен смотреть далеко в будущее, он думает только о краткосрочных преимуществах. Древний мозг не разбирается в разработке программ и не может даже представить себе, какого это - заниматься одним проектом много месяцев и даже лет. Но ты-то выше него, у тебя новая кора есть, и она способна смотреть в будущее и оценивать последствия своих поступков.

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

>>2629

>Частенько. Каждый раз, когда надо выйти.

Ручками эту команду набираешь в консоли?

>get_tree().quit()

Во-первых, это не синглтон, а обращение к самому себе (self).
Во-вторых, эта строчка в единственном месте всего проекта.
В-третьих, это API движка, а не твой личный код в проекте.

>Потому что движок так спроектирован.

Движок заставляет тебя создавать как можно больше лапши?

>>2633

>решил проверить, как оно будет

Как будет что? Нормальный код без лишней лапши?

>>2643
Если ты игр не делаешь - действительно без разницы.

>>2635 >>2636

>ad hominem

Загуглите, что это, чтобы реже быть баттхёртами.
>>2645

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

Ты тоже "ad hominem" загугли - должно помочь.

>послушать мнение функциональщиков

Функциональные языки - это не для нас, а для математиков.

>Минусы будут?

Будут - в будущем, поэтому я и предлагаю избегать их заранее.

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

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

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

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

Вот как новичок изучает движок?
1. Узнаёт про ноды и сцены, учится писать код и т.д.
2. Создаёт игровую локацию и минимальный геймплей.
3. Хочет сменить локацию или открыть/закрыть меню.
4. Находит в API дерева сцены функции "change scene"...
5. ...и обнаруживает, что движок теряет все его данные....
6. Находит решение - поместить эти данные в "autoload".
7. Радуется, что персонаж переходит из локации в локацию.
8. Начинает использовать "autoload" к месту и не к месту...
9. Привыкает к ним, и замахивается на проект побольше...
Результат немного предсказуем, вы так не думаете?

При этом нет ничего, что нельзя было решить без "autoload". Это буквально фича без задач, если ты не используешь "change scene" в дереве сцены, а он тебе вообще не нужен, когда у тебя есть load(), add_child() и queue_free(), что дают тебе намного больше контроля, чем методы "change scene". Не говоря уж о том, что для бесшовного мира ты вообще не можешь использовать "change scene" и будешь добавлять новые куски мира через add_child(), а значит, не остаётся ни одной разумной причины использовать "autoload" в проекте, за исключением какого-нибудь счётчика кадров, который ты хочешь выводить при нажатии на F6 в совершенно любой сцене, но это опять-таки не синглтон (счётчику кадров не нужно быть глобально доступным, а глобальный доступ - важное условие синглтона). Но вот нюанс: если ты слишком сильно обмазался синглтонами (читай: глобальным доступом к уникальным объектам), F6 у тебя рано или поздно сломается (т.к. запутаешься в том, что твои синглтоны должны делать при запуске), не говоря уж о более долгой загрузке проекта при каждом рестарте (окно движка фризится, пока все начальные ноды не загрузятся и не инициализируются).

>имею ecs геймплей

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

Впрочем, из-за ECS у тебя вряд ли сложный геймплей.

>>2667

>Он игры не делает, он движок изучает

Я всё что нужно изучил и по граблям прошёлся - пытаюсь предостеречь других.