>>1525

>два действия по трём кнопкам.

Чё?

>обработку одновременного нажатия

Чёёё?

ЛКМ - открыть клетку (мина взрывается).
ПКМ - воткнуть/снять флажок (не взрывается).
Клетку с флажком открыть нельзя.
Если можно поставить "?", тогда:
ПКМ - флажок/"?"/пусто/флажок/"?"/... - цикл
Где там что-то ещё? Что ещё ты там выдумал?

>>1534

>непонимании сапера

Там всё очень просто: каждый номер обозначает количество заложенных мин на соседних клетках (теоретический максимум 8, минимум 0). Разные соседние клетки суммируют одни и те же мины, что помогает обнаружить точное положение этих мин.

Если у тебя такая ситуация (поле 3x3):
_ _ _
1 2 2
? ? ?
Тогда первый ? - пустой, на других - мины:
_ _ _
1 2 2
_ ✓✓
Ставишь флажки ✓ на все потенциальные мины.

Общий алгоритм игры:
1. Начинать проще всего с любого угла.
2. Помечаешь все очевидные мины флагами.
3. Открываешь все очевидно пустые клетки.
4. Повторяешь 2-3, пока есть очевидное.
5. В редких случаях приходится угадывать.
Играешь, пока не откроешь все пустые клетки.

Начинай с самого маленького уровня сложности.

спидранил сапёра на уроках через проектор

>>2198

>реализации/implementation

В каком контексте? Реализация (имплементация) - осуществление задуманного. В контексте ООП это может означать реализацию абстрактного класса.

Пример из классов Godot:
https://docs.godotengine.org/en/stable/classes/class_basebutton.html
Это базовая кнопка. Её нельзя использовать как есть, потому что у неё нет поведения. Но из неё можно создать собственную кнопку, реализовав методы:

>void _pressed() virtual

>void _toggled(toggled_on: bool) virtual

В них описывается поведение твоей новой кнопки.

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

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

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

>Can't make instance of abstract class BlaBla! Implement method Say(text: String) before calling BlaBla.new().

В GDScript понятия абстрактных методов пока нет:
https://github.com/godotengine/godot-proposals/issues/989
Там см. примеры, как это можно обойти (assert).

Ещё слово "реализация" может использоваться как противопоставление "интерфейса" класса. Здесь интерфейс - это список публичных полей и методов. Например, is_hovered() у кнопки - это интерфейс, а реализация спрятана где-то в исходниках на C++.

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

Допустим, есть такой интерфейс:

>func pull_data()

Мы обнаружили, что pull_data() выполняется ровно 5 секунд, и использовали это знание в своём коде:

>pull_data()

>time += 5

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

Пример смешной, а ситуация страшная - из-за таких ошибок в программах космические корабли теряли.

>внедрения/injection

Это вообще отдельная тема. Допустим, тебе нужна определённая зависимость, но ты не знаешь пока конкретные детали. Пускай пользователь сам определяет эти детали! Ты объявляешь:

>@export var platform: VehiclePlatform

А дальше пользователь сам укажет, какая ему платформа нужна: на колёсиках, на гусеницах, на механических ногах, на воздушной подушке... Тут единственное условие - совпадение интерфейса:

>platform.move(direction)

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

Примеры DI из Godot: любые физические объекты, зависимые от вложенных в них форм коллизии; контейнеры и вложенные в них Control-ноды, без которых смысла в контейнерах нет (зависимость).

Могу ошибаться, поскольку я самоучка.

Мини-план по левел-дизайну для соло инди 3D игр.

1. КОНЦЕПТ.

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

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

2. ГРЕЙБОКС (механический прототип).

2.1. Используйте CSG фигуры с натянутой сетчатой трипланарной текстурой для грубого наброска в 3D. Игнорируйте детали. Если вам нужна машина - вам достаточно растянуть один куб. Здание - куб. Любое заграждение - куб. Но иногда нужны цилиндры, как, например, для круглой площади, фонтана. Также игнорируйте мелкие отклонения в величинах, дрочь циферок сейчас ничего не даст, только замедлит. Однако, ориентируйтесь на сетку и обязательно сохраняйте повторяющиеся объекты как сцены.

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

3. ВАЙТБОКС (графический прототип).

3.1. Когда грейбокс доказал общий дизайн уровня, переходим к постепенной детализации моделей. Нет необходимости трогать 3D редактор, для многого хватит и CSG форм, но куда меньшего размера. Тут серые кубы и цилиндры начинают напоминать реальные объекты, пусть и без текстур. У машины появляются колёса, например, а у здания - окна.

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

4. ГРАФИКА.

4.1. Экспортируете вайтбокс-модели в GLTF и потом импортируете их, например, в Blender. Лучше всего делать это по отдельности, особенно если модели повторяются несколько раз в разных местах. Они пригодятся как эталон по масштабу/пропорциям.

4.2. Делаете поверх них полноценные модели с полноценными текстурами, но не обязательно до финального вида. Тут тоже можно разбить процесс на несколько итераций, чтобы подстраховаться.

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

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

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

И Godot в это удивительно хорошо вписывается.

>>2604

>уровни в тренчбруме или блендере это

Тренчбрум не трогал, но с блендером всё нормально.

>но с геометрией сложнее, чем три куба.

Прототип уровня всегда редуцируется до кубов...

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

Может, ты слишком высокое число подразделений выбираешь? Или делаешь булевы операции, которых возможно было избежать? В любом случае, если ты понимаешь, как работают булевы операции в 3D, ты сможешь использовать CSG для сложных сцен. Для прототипа уровня (грейбокса) этого достаточно.

Простой пример, как избежать лишних тормозов:

>Scene: Node3D # это корень сцены, обычная нода

>_ Floor: CSGBox # это глобальный пол сцены

>_ Walls: Node3D # просто группа для удобства

>_ _ Wall1: CSGBox # уникальная стена

>_ _ Wall2: CSGBox # отдельная уникальная стена

>_ _ _ Doorway: CSGBox # дырка прохода в стене

>_ _ _ Door: Node3D # вложенная сцена двери

>_ WeaponBox: Area3D # вложенная сцена

>_ JumpPad: Area3D # вложенная сцена

Так у тебя разные коробки не будут "склеиваться".

>>2608

>конвертируй csg в меши перед запуском

>>2611

>конверчу в обычные меши

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

>>2617
У меня есть несколько замечаний по скриншоту.

1. Организация папок - в Godot принято собирать файлы, принадлежащие одному объекту, в папке объекта. Нет никакой необходимости сваливать графические ассеты в одну внешнюю папку где-то далеко от связанной сцены и скрипта. Когда всё необходимое лежит рядом, навигация удобнее. В редакторе оптимизированы относительные пути, например, не нужно указывать полный путь до конкретного файла в той же папке или глубже.

2. Глобальные события - тебе действительно так необходимо, например, глобальное "TO_PAUSE"? Ты можешь просто отобразить меню паузы, которое автоматически остановит всё то, что должно быть остановлено во время паузы. Никаким игровым объектам не нужно ждать/знать про паузу. То же касается всех остальных событий на скриншоте.

3. Конечный автомат меню с помощью стороннего аддона - зачем он тебе? Эти состояния игры и меню не настолько сложны, чтоб тебе нужны были все эти лишние телодвижения, ноды конечного автомата. Встроенный в AnimationTree конечный автомат тут справился бы не хуже, но любой конечный автомат в конкретной ситуации только усложняет работу. Ты реализовал решение отсутствующей проблемы. Не забывай, что ты можешь делать просто:

>signal exit_to_main_menu()

>exit_to_main_menu.emit()

И подключить всё через вкладку Node -> Signals, которая находится справа от Inspector. Или код:

>exit_to_main_menu.connect(_on_exit_to_main_menu)

Это главный механизм работы Godot и не нужно изобретать велосипеды на его замену. Соглашусь только, что имя "Signal" вместо "Event" запутывает.

Метод bind() вызывать без аргументов не нужно. Он необходим, когда тебе нужно забиндить какие-то дополнительные аргументы, которых нет в сигнале.

4. Вьюпорт - для чего он там? Делал пиксель-арт с UI в высоком разрешении? Если нет, то он избыточен. Корневой вьюпорт имеет все те же настройки и 2D рендерится нормально без лишних вьюпортов.

5. Менюшки без CanvasLayer - в Godot лучше каждое отдельное меню помещать в свой CanvasLayer или, как минимум, весь UI - это CanvasLayer. Тогда он не будет зависеть от Camera2D и его можно будет легче сортировать, не меняя порядка нод в дереве сцены.

В общем и целом складывается впечатление, что ты пытаешься натянуть пайплайн из Unreal на Godot, что приводит к таким костылям и сложностям. Тебе необходимо сначала разобраться в инструменте, а потом только решать, нужны ли все эти костыли. И в частности, простую 2D игрушку в Godot можно и нужно делать снизу вверх, а не с каких-то меню.

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

>>3426

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

Так ты ж ничего не сделал. Даже 2D проект, если ты делаешь полноценную игру в хорошем разрешении, в конечном итоге может занимать гигабайты. Даже в пиксельартовом стиле. Пример: Starbound ≈3.2 ГБ, используя какой-то велосипед на C++ и SDL2.

>весит 150 МБ

https://docs.godotengine.org/en/stable/contributing/development/compiling/optimizing_for_size.html
Вкратце: можно выключить очень многое, что ты не собираешься использовать. Однако, до тех пор, пока ты не опубликуешь игру, иметь "всё в одном" удобно.

Плюс сжатие файлов NTFS сжимает EXE до ≈50%.

>>3447

>пишу игру для себя

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

Тогда у тебя будет один EXE под все твои проекты - остаётся только создавать ярлыки для запуска.

>>3449

>когда будет >= 100 сцен, размер исполняемого файла не вырастет на пару гигабайт?

Все твои данные хранятся в PCK. Во время экспорта Godot не компилирует свой EXE, а только изменяет мета-данные внутри копии "шаблона экспорта", как, например, имя твоей компании, версию билда и т.п.

PCK, в свою очередь, подобен ZIP, но это кастомный формат Godot. Также можно экспортировать в ZIP и упаковать все данные PCK внутрь EXE как ресурс.

>>3457

>небольшой размер исполняемого

Конкретно зачем? На микроконтроллер прошивать?

Если тебе нужен движок для микроконтроллера, то посмотри в сторону инструментов, подходящих для выбранного микроконтроллера. Типа, что там для Arduino подходит или какой у тебя там контроллер.

>>3484

>нет души

>>3489

>Ее в компьютере

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

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

СЕЙЧАС БУДЕТ ШИЗА!!

Заебала шизо нейронка и гайды в падло на youtube смотреть, помогите.

У меня было так

Player (CharacterBody2D)
├── Sprite2D
├── Camera2D
├── EnemySpawner
└── CollisionShape2D // хз зачем онм нен нужен был

Enemy (CharacterBody2D)
├── Sprite2D
└── CollisionShape2D

Спросил у нейронки как детектить вхождение Enemy
Насоветовала хуеты ебаной, добавь Area2D и CollisionShape2D
Сразу не разобрался и перенес текуший CollisionShape2D в Area2D

код:
public override void _Ready()
{
GD.Print("PlayerArea2d OnReady");
BodyEntered += OnBodyEntered;
}
private void OnBodyEntered(Node2D body)
{
GD.Print(body.Name);
}

Мучался мучался, нихкя не работало. Потом случайно добавил еще один CollisionShape2D И оказалость что так правильно

Как в итоге оказалось что нужно было так

Player (CharacterBody2D)
├── Sprite2D
├── Camera2D
├── EnemySpawner
└── CollisionShape2D //Disabled
└───Area2D
└─CollisionShape2D

Enemy (CharacterBody2D)
├── Sprite2D
└── CollisionShape2D
└───Area2D
└─CollisionShape2D

МНЕ ТОЛЬКО НАДО ЧТО БЫ Enemy НЕМНОГО ТОЛАЛи СЕБЯ И ВХОДИЛИ В ИГРОКА НАНОСЯ ЕМУ УРОН

На гадах на ютубе испольсуют Area2D вместо CharacterBody2D

А CharacterBody2D тогда для кого, только для игрока получается?

Почему кстатий в gd нет [code] Как в pr

>>3732
СЕЙЧАС БУДЕТ ШИЗА!!

Заебала шизо нейронка и гайды в падло на youtube смотреть, помогите.

У меня было так

Player (CharacterBody2D)
├── Sprite2D
├── Camera2D
├── EnemySpawner
└── CollisionShape2D // хз зачем онм нен нужен был

Enemy (CharacterBody2D)
├── Sprite2D
└── CollisionShape2D

Спросил у нейронки как детектить вхождение Enemy
Насоветовала хуеты ебаной, добавь Area2D и CollisionShape2D
Сразу не разобрался и перенес текуший CollisionShape2D в Area2D

код:
public override void _Ready()
{
....GD.Print("PlayerArea2d OnReady");
....BodyEntered += OnBodyEntered;
}
private void OnBodyEntered(Node2D body)
{
....GD.Print(body.Name);
}

Мучался мучался, нихкя не работало. Потом случайно добавил еще один CollisionShape2D И оказалость что так правильно

Как в итоге оказалось что нужно было так

Player (CharacterBody2D)
├── Sprite2D
├── Camera2D
├── EnemySpawner
└── CollisionShape2D //Disabled
....└───Area2D
........└─CollisionShape2D

Enemy (CharacterBody2D)
├── Sprite2D
└── CollisionShape2D
└───Area2D
....└─CollisionShape2D

МНЕ ТОЛЬКО НАДО ЧТО БЫ Enemy НЕМНОГО ТОЛАЛи СЕБЯ И ВХОДИЛИ В ИГРОКА НАНОСЯ ЕМУ УРОН

На гадах на ютубе испольсуют Area2D вместо CharacterBody2D

А CharacterBody2D тогда для кого, только для игрока получается?

Почему кстатий в gd нет [code] Как в pr

>>4283
Кодил в начале на похуй. Потом спустя какоето время надоело копи пастить одно и тоже. Применил все свои знания в области наследования и разбил на класы.

[Сharacter]
.+Move
.+FlipSprite
....[Enemy]
......+GetDirectionToPlayer
......+GetPlayer
........[Mob1]
........[Mob2]
........[Mob2]
....[Player]
......+GetDirectionFromControl

Пофиксил баг залипания костылями которыей хуй пойми как работают.

Потом заметил еще баг что мобы ходят очередью несмотря на то что колижен овальный и мобы статусом повыше расталкивают медленую мелочь.
Но в итоге сами собираються в очередь к игроку.
Начал копать в сторону нахождения пути.
Увидил элемент поиска пути в редакторе.
На элементе написано: "Внимание, может быть удалён в следуших версиях движка!".
Ну ладно, похуй я себе думал.
Сидел весь день.
Гады говёные старые, нихуя нормально не работает.
Глобальная позиция игрока у далбоёбов обновляется через таймеры.
Все пидорасы использут не тот метод для mova. Если использовать его то у меня опять будет баг.
Кроме того использут свои костыли что бы скользило.
С моим наследованием хуй знает как стакать.
На всех видео поиск пути по точкам у меня всегда прямая линия хоть даже если делаю полность всё по копи пасте.
Нейронка тоже тупит ничег дельного сказать не может.
Хоть бери и сам делай свой велосипед для поиска пути.

ВОт почему оно всеглда всё так? Хочется делать всё по красоте но никогда не получается.

>>4289
Вообще, наследование для актёров (персонажей, монстров, юнитов) обычно не рекомендуется. Это затрудняет создание новых вариантов актёров.

>....[Enemy]

>......+GetDirectionToPlayer

>......+GetPlayer

Што? Почему у тебя Enemy отдает кому-то наружу направление на игрока и ссылку на игрока? Он же наоборот, должен получать извне эту информацию?

>....[Player]

>......+GetDirectionFromControl

Опять же, нет особого смысла в этом методе, когда можешь вызвать свой Move() из PhysicsProcess:
https://docs.godotengine.org/en/stable/classes/class_input.html#class-input-method-get-vector

>нахождения пути

>Внимание, может быть удалён

Что ты используешь, NavigationAgent2D? Зачем? Ты ж вроде как хотел отказаться от физики совсем, потому что у тебя полноценных стен на сцене нет? Эти ноды навигации работают в первую очередь со статичной геометрией. Если тебе нужно просто двигать мобов в направлении игрока, по прямой - навигация не нужна.

Что ты вообще делаешь, клон Vampire Survivors?
Много разных жанров в 2D, от жанра зависит код.

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

Поиска пути где? Ты хоть скриншот уровня дай.

Для простых уровней из клеток (со множеством туннелей, стенок, комнат, дверей) хорошо это:
https://docs.godotengine.org/en/stable/classes/class_astar2d.html
https://docs.godotengine.org/en/stable/classes/class_astargrid2d.html
А раз уж ты на C#, то в C# могут быть какие-то более продвинутые библиотеки поиска пути. Нет нужды изобретать свой велосипед в данной ситуации.

>ВОт почему оно всеглда всё так?

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

У тебя проблемы не с Godot, игрой или геймдевом.
У тебя систематические проблемы с обучением.

Я тоже через подобное проходил, много лет назад...