Этого треда уже нет.
Это копия, сохраненная 30 июня 2023 года.

Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее

Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
1638133344440.png1,7 Мб, 1920x2592
Godot #21.12 # OP 779036 В конец треда | Веб
Добро пожаловать в тред любви, взаимопомощи и многопоточной загрузки!

Краткий гайд по вкату в движок:
1. Читать документацию.
2. Качать примеры.
3. ПРОФИТ!

Ссылки
Новости движка: https://godotengine.org/news/
Скачать движок: https://godotengine.org/download/ или http://store.steampowered.com/app/404790/Godot_Engine/
Играть в игродела онлайн без регистрации: https://editor.godotengine.org/releases/3.4.rc1/godot.tools.html с дивана нельзя.
FAQ: https://docs.godotengine.org/ru/latest/about/faq.html
Документация: https://docs.godotengine.org/ru/latest/ https://docs.godotengine.org/en/stable/
Примеры качаются прямо в движке через свой магазин в отдельной вкладке AssetLib. Там есть всё - от платформера до чата.
Игры, созданные глобальными кириллами: https://steamcommunity.com/app/404790/discussions/0/412448792354265655/
Изумительный Годот: https://github.com/Calinou/awesome-godot https://github.com/godotengine/awesome-godot - подборка дополнений, модулей и минишоукейc.
Аддон для диалоговой системы: https://godotengine.org/asset-library/asset/833
Прекомпилер шейдеров: https://godotengine.org/asset-library/asset/977
Майндмаппинг проектов не отходя от кассы: https://godotengine.org/asset-library/asset/879
SmartShape для рисования 2D-террейнов без задней мысли: https://godotengine.org/asset-library/asset/715
Конвертор кваковских карт для ностальгирующих дидов: https://godotengine.org/asset-library/asset/446
Конвертер блендеровских моделей в формат сцен: https://docs.godotengine.org/en/stable/getting_started/workflow/assets/escn_exporter/index.html
Конвертер блендеровских файлов прямо в движок: https://github.com/V-Sekai/godot-blender Надо только в настройках проекта путь к blender.exe указать. Потом просто закидываешь .blend в папку и импортируется.

Для любителей пощекотать конпеляцию
Бинды LUA: https://github.com/perbone/luascript
Бинды JS: https://github.com/GodotExplorer/ECMAScript

Годнота от анона
- Для приверженцев опенсорца существует возможность распространять проекты в незапакованном формате. Просто скачай темплейт с оф.сайта и положи экзешник/эльфешник в папку с проектом, этого достаточно. Имя файлу можно задать любое. Дополнительно можешь вшить свою иконку в экзешник. После этого, запустившийся файл темплейта обнаружит рядом с собой файл project.godot и начнет грузить проект из него и из файлов, лежащих в распакованном виде в той же директории. Для запущенного таким образом проекта папка res:// становится доступна для записи (если это не ограничено правами доступа в системе).
- В версии 3.2 появилась возможность прикреплять pck к бинарнику. Не появилась, а вернулась - 2.х умел. Бриллиант для любителей однофайлового продукта!
- Редактор персонажей на основе makehuman: https://github.com/Lexpartizan/Go_MakeHuman_dot
- Тест-бенчмарк:
- - Веб-версия - https://govdot.herokuapp.com
- - Вишмастер для винды - https://govdot.herokuapp.com/4Anon.rar

Предыдущий: >>766120 (OP)

Архивный: https://arhivach.ng/thread/719365/
2 779049
Godot ECS = godex щупал кто?
https://github.com/GodotECS/godex
3 779055
>>79049
Он под 4ку
4 779069
>>79055
я в курсе
5 779077
>>79049
Не труъ DOD ECS:
https://github.com/GodotECS/godex-examples/blob/main/HierarchicalTransformation/Components/Velocity.gd

>var velocity := Vector3()


https://github.com/GodotECS/godex-examples/blob/main/GodexPinball/Components/BounceComponent.gd

>var overlap_area_transform: Transform = Transform()


>func get_spawners():



Вся суть™ ECS заключается в том, что "компонент" - это максимально тупой носитель максимально тупых данных, таких, как bool, int, float. При том это должны быть типизированные данные, без variant, потому что variant заставляет процессор проверять тип данных. Использование внутри компонента ООП объектов (Vector3, Transform) лишает ECS смысла, потому что ООП объект - это ссылка, а переход по ссылкам процессоры оптимизировать не умеют и из-за него вынуждены ждать лишние циклы ответ от RAM. Если в компоненте максимально тупые данные, то большой массив компонентов можно загрузить в кэш процессора одной пачкой и таким образом не ждать ответа RAM на каждой итерации цикла. Сам компонент, разумеется, тоже не должен быть объектом ООП, то есть он не может иметь никаких функций, только тупые данные - иначе в кэш процессора попадут не компоненты, а ссылки на компоненты, и снова придётся ждать ответа от RAM. Это место в ECS - главная причина потенциально высокой производительности, потому что избавляет от "бутылочного горлышка" между CPU и RAM. Если не удаётся реализовать тупые контейнеры тупых данных, то и от ECS толку нет.

Также нельзя использовать Array и Dictionary из GDScript - во-первых, это объекты, во-вторых, там внутри варианты. Array обещали сделать типизированным в 4.0, но вот Dictionary вряд ли когда-нибудь будет типизированным. Мне лично непонятно, почему это так, потому что в компилируемых ЯП есть типизированные структуры (record в Pascal и, если не ошибаюсь, struct в C/C++), которые не являются объектами (хранятся и передаются целиком, без ссылок).

Вот это тоже вызывает сомнения в производительности:
https://github.com/GodotECS/godex-examples/blob/main/GodexPinball/Systems/BounceSystem.gd

>func _for_each(bounce, impulse_storage):


>var data = {"impulse": ...}


>impulse_storage.insert(..., data)


Здесь мы неявно вызываем Dictionary.new(), выделяем в RAM память под него, записываем туда данные и передаём ссылку на эти данные в массив. К тому же работаем со строками, что требует от Dictionary хэширования этих строк... И это каждый кадр, для каждого компонента Bounce. Эффективно ли это? Не думаю. Во всяком случае это лишает смысла подход "все необходимые компоненты в одном массиве в кэше процессора и доступ к ним мгновенный".

А главная проблема ECS для пользователя - неочевидность происходящего в коде. Вот тот же пример, мы каким-то образом получаем какой-то импульс, который потом куда-то суём и... всё? Что этот код делает с точки зрения геймплея? Без комментариев не разберёшься, а код, в котором не разберёшься без комментариев - это плохой код. В обычном ООП у нас были бы платформы, которые каждый физический тик назначали импульс всем, кто с ними соприкасается, и это было бы понятно из кода: вот платформа, вот она вот это делает каждый тик, вот на кого она влияет. А тут это непонятно, нужно искать какие-то подсказки в декларативном коде сцены или в отдельной документации...

В общем, из-за сложности с пониманием кода в ECS, единственное её практическое применение - ускорение работы с массивами компонентов, но здесь на первый взгляд нет никакого ускорения, потому что всё обмазано переходами по ссылкам. Чисто как реализация ECS - ок, но практическая польза сомнительна без правильной реализации DOD:
https://en.wikipedia.org/wiki/Data-oriented_design
...лол, там всё ещё круче должно быть: каждый int в своём отдельном массиве, т.е. "структура с массивами", а не "массив структур".

Но я, конечно, исходный код не смотрел, может там есть какие-то ухищрения, позволяющие обернуть DOD стандартным ООП-кодом GDScript, но очень в этом сомневаюсь.
5 779077
>>79049
Не труъ DOD ECS:
https://github.com/GodotECS/godex-examples/blob/main/HierarchicalTransformation/Components/Velocity.gd

>var velocity := Vector3()


https://github.com/GodotECS/godex-examples/blob/main/GodexPinball/Components/BounceComponent.gd

>var overlap_area_transform: Transform = Transform()


>func get_spawners():



Вся суть™ ECS заключается в том, что "компонент" - это максимально тупой носитель максимально тупых данных, таких, как bool, int, float. При том это должны быть типизированные данные, без variant, потому что variant заставляет процессор проверять тип данных. Использование внутри компонента ООП объектов (Vector3, Transform) лишает ECS смысла, потому что ООП объект - это ссылка, а переход по ссылкам процессоры оптимизировать не умеют и из-за него вынуждены ждать лишние циклы ответ от RAM. Если в компоненте максимально тупые данные, то большой массив компонентов можно загрузить в кэш процессора одной пачкой и таким образом не ждать ответа RAM на каждой итерации цикла. Сам компонент, разумеется, тоже не должен быть объектом ООП, то есть он не может иметь никаких функций, только тупые данные - иначе в кэш процессора попадут не компоненты, а ссылки на компоненты, и снова придётся ждать ответа от RAM. Это место в ECS - главная причина потенциально высокой производительности, потому что избавляет от "бутылочного горлышка" между CPU и RAM. Если не удаётся реализовать тупые контейнеры тупых данных, то и от ECS толку нет.

Также нельзя использовать Array и Dictionary из GDScript - во-первых, это объекты, во-вторых, там внутри варианты. Array обещали сделать типизированным в 4.0, но вот Dictionary вряд ли когда-нибудь будет типизированным. Мне лично непонятно, почему это так, потому что в компилируемых ЯП есть типизированные структуры (record в Pascal и, если не ошибаюсь, struct в C/C++), которые не являются объектами (хранятся и передаются целиком, без ссылок).

Вот это тоже вызывает сомнения в производительности:
https://github.com/GodotECS/godex-examples/blob/main/GodexPinball/Systems/BounceSystem.gd

>func _for_each(bounce, impulse_storage):


>var data = {"impulse": ...}


>impulse_storage.insert(..., data)


Здесь мы неявно вызываем Dictionary.new(), выделяем в RAM память под него, записываем туда данные и передаём ссылку на эти данные в массив. К тому же работаем со строками, что требует от Dictionary хэширования этих строк... И это каждый кадр, для каждого компонента Bounce. Эффективно ли это? Не думаю. Во всяком случае это лишает смысла подход "все необходимые компоненты в одном массиве в кэше процессора и доступ к ним мгновенный".

А главная проблема ECS для пользователя - неочевидность происходящего в коде. Вот тот же пример, мы каким-то образом получаем какой-то импульс, который потом куда-то суём и... всё? Что этот код делает с точки зрения геймплея? Без комментариев не разберёшься, а код, в котором не разберёшься без комментариев - это плохой код. В обычном ООП у нас были бы платформы, которые каждый физический тик назначали импульс всем, кто с ними соприкасается, и это было бы понятно из кода: вот платформа, вот она вот это делает каждый тик, вот на кого она влияет. А тут это непонятно, нужно искать какие-то подсказки в декларативном коде сцены или в отдельной документации...

В общем, из-за сложности с пониманием кода в ECS, единственное её практическое применение - ускорение работы с массивами компонентов, но здесь на первый взгляд нет никакого ускорения, потому что всё обмазано переходами по ссылкам. Чисто как реализация ECS - ок, но практическая польза сомнительна без правильной реализации DOD:
https://en.wikipedia.org/wiki/Data-oriented_design
...лол, там всё ещё круче должно быть: каждый int в своём отдельном массиве, т.е. "структура с массивами", а не "массив структур".

Но я, конечно, исходный код не смотрел, может там есть какие-то ухищрения, позволяющие обернуть DOD стандартным ООП-кодом GDScript, но очень в этом сомневаюсь.
6 779078
>>79077

>Сам компонент, разумеется, тоже не должен быть объектом ООП, то есть он не может иметь никаких функций, только тупые данные


На самом деле это не совсем так. В некоторых ЯП есть структуры с включёнными в них функциями, которые хранятся на стеке, т.е. передаются целиком, без использования ссылок, например:
https://wiki.freepascal.org/Object
То есть массив таких объектов может, теоретически, умещаться в кэш процессора, но обращение к функциям, скорее всего, опять же вызовет лишние переходы. Так что лучше иметь массивы максимально простых данных (int, float), так будет точно быстрее.

Да, кстати. Может, кто-то считает, что ECS удобно использовать даже если она не даст роста производительности? Я имею в виду удобство с точки зрения разработчика игры. Я в этом сильно сомневаюсь - слишком много кода разбросано по разным файлам (компоненты, системы) и нет чёткой связи между кодом логики и объектами в сценах кроме как в декларативных файлах.
7 779080
>>79078

>удобство с точки зрения разработчика


Ну вот, допустим, я хочу сделать бота для игры. В ООП я просто создаю класс бота и дальше вся его логика у меня лежит в одном месте. Этой логике не нужно никуда двигаться, она будет только тут и нигде больше. В ЕЦС я вынужден создавать компонент AI и систему AI, которой потребуется доступ к сотням компонентов сразу, потому что бот должен иметь полноценный контроль за всеми возможными игровыми объектами, с которыми он может взаимодействовать. В результате система AI будет содержать в себе большую часть кода из обычного ООП класса, но этот код будет менее логичным из-за того, что данные вынесены из него в отдельные места, по которым приходится регулярно бегать... А если логику разделить на несколько компонентов и систем, то вся разработка превращается в ад из постоянных переходов между файлами и участками кода, которые никак не говорят о том, кому они в реальности принадлежат (боту).

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

Ладно, это не касается Godot. Просто я не понимаю, зачем ЭТО тащить в Godot, когда у него и без этого проблем хватает. Мало того, что ты борешься с багами и ограничениями движка, теперь будешь бороться с возмутительно противоестественным дизайном ЕЦС... Хорошо, что это пока только сторонний проект.
7 779080
>>79078

>удобство с точки зрения разработчика


Ну вот, допустим, я хочу сделать бота для игры. В ООП я просто создаю класс бота и дальше вся его логика у меня лежит в одном месте. Этой логике не нужно никуда двигаться, она будет только тут и нигде больше. В ЕЦС я вынужден создавать компонент AI и систему AI, которой потребуется доступ к сотням компонентов сразу, потому что бот должен иметь полноценный контроль за всеми возможными игровыми объектами, с которыми он может взаимодействовать. В результате система AI будет содержать в себе большую часть кода из обычного ООП класса, но этот код будет менее логичным из-за того, что данные вынесены из него в отдельные места, по которым приходится регулярно бегать... А если логику разделить на несколько компонентов и систем, то вся разработка превращается в ад из постоянных переходов между файлами и участками кода, которые никак не говорят о том, кому они в реальности принадлежат (боту).

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

Ладно, это не касается Godot. Просто я не понимаю, зачем ЭТО тащить в Godot, когда у него и без этого проблем хватает. Мало того, что ты борешься с багами и ограничениями движка, теперь будешь бороться с возмутительно противоестественным дизайном ЕЦС... Хорошо, что это пока только сторонний проект.
1638190930178.jpg36 Кб, 540x500
8 779081
>>79080
А разгадка в том, что ЭЦС - это когда зумеры придумают новое слово для того, что уже делали до них замшелые бумеры. Окей, бумер, говорят тупые зумеры, когда им объясняешь, что ЕЦС ихнее - это два паттерна проектирования: наблюдатель и композиция. Всё. Всё, блять, ты понимаешь масштаб тупости зумерья?

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

Датаориентированное программирование... Штоблять? Додики, блять.
9 779082
>>79077
вы думаете, что если в плюсах я сделаю компоненты в виде двусвязного списка (например, двусвязный список структуры позиция), то из-за того, что список хранит в каждой ноде ссылки на предыдущую и следующую ноду, то оно теряет все преимущества ECS как кеширование процессором и можно не делать?

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


импульс добавляется как компонент соответствующей сущности и следующая система Move отработает эти компоненты и удалит их

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


создается система AI_WOLF и на каждую сущность волка навешивается компонент AI_WOLF. Никакого доступа к сотням компонентов не будет, кроме подмножества тех, у которых есть компонент AI_WOLF
10 779083
>>79081

> ЕЦС ихнее - это два паттерна проектирования: наблюдатель и композиция


так комбинацию этих паттернов с некоторыми особенностями реализации и назвали ECS для более удобного и быстрого понимания, как и вводят любые другие термины
11 779085
>>79082

>импульс добавляется как компонент соответствующей сущности и следующая система Move отработает эти компоненты и удалит их


Зачем такие сложности? Особенно в плане

>удалит их


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

>Никакого доступа к сотням компонентов не будет, кроме подмножества тех, у которых есть компонент AI_WOLF


AI_WOLF должен знать положение всех ближайших AI_RABBIT, их жирноту, здоровье, скорость и направление движения, а также положение всех ближайших AI_HUNTER и PLAYER, их оружие, здоровье, скорость и направление движения. И это только базовый волчара, у которого нет стаи, потому что со стаей ему придётся знать положение всех ближайших AI_WOLF, их здоровье, настроение, текущие цели и приоритеты, и т.д. Ты не можешь создать сферический в вакууме AI, который ни к чему доступа не имеет, даже монстры в Пакмане и те опирались на положение игрока, за исключением того, который ходил полностью рандомно.

>преимущества ECS


Таки в чём преимущества, если не в кэше процессора?

>>79081
Суть ЕЦС не в названии, а в способе реализации. Ты можешь сделать что-то типа ЕЦС на ООП классах, но это не будет труЪ ЕЦС™.
12 779087
>>79085

> Зачем такие сложности?


для распараллеливания

> AI_WOLF должен знать положение всех ближайших AI_RABBIT, их жирноту.....


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

> Суть ЕЦС не в названии, а в способе реализации.


да, это просто устоявшееся название такого подхода без особых уточнений в реализации
13 779114
>>79105 (Del)

> А если ты засунешь все в один огромный файл, ничем хорошим это не кончится.


На плойке трёшке (для чудного проца которой и изобрели ЕЦС нотидоги) это закончилось успешной серией приключений Драке.
14 779115
>>79105 (Del)
>>79114
ECS вообще никак не влияет на то как разбить всё это по файлам
15 779117
>>79115
Влияет. Изучи матчасть по своей же хуите. Скорость ЕЦС напрямую зависит от того, как будут подниматься данные из файлов. В какой последовательности уложены все эти атрибуты сущностей. Иначе хвалёная кэш-магия не сработает и не даст свои 0,5 процента прироста на современных процах перед нормальным ООП здорового человека.
16 779149
Как играть в этот ваш годот?
17 779153
>>79149
там кнопочка play есть к в магнитофоне твоего бати
18 779244
>>79153
Откуда ты моего батю знаешь, ты что тоже из Саратова?
19 779258
>>79105 (Del)

>Если твой ЕЦС-бот взаимодействуетс сотнями компонентов, то и ООП бот должен будет к ним же обращаться.


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

Забавно, что в маленьком проекте от ЕЦС нет никакой пользы - намного удобнее и выгоднее иметь 2-3 ООП класса с понятными именами (wolf, rabbit, player), в то же время в большом проекте из-за ЕЦС всё становится намного сложнее - сотни, если не тысячи, отдельных компонентов, связанных между собой непонятно как непонятно где, и ни одной реальной сущности... Мне кажется, единственная область, где ЕЦС удобно и полезно - это когда тебе нужно огромное количество объектов с минимальной, очень простой логикой, скорее всего однотипной. Что-нибудь типа арканоида, только блоков сотни тысяч вместо пары сотен.

>А если ты засунешь все в один огромный файл, ничем хорошим это не кончится.


Не нужно всё один файл совать, нужно распределять данные и логику по сущностям, а не по компонентам несуществующих сущностей. Я не против переодически переходить между wolf.gd и rabbit.gd, я против постоянного поиска по нескольким десяткам файлов с компонентами, которые ещё и связаны друг с другом только в каком-то совершенно отдельном файле (скорее всего в декларативном .tscn).
20 779300
>>79244
ты знаешь еще не всю правду: я твой отец
21 779302
>>79258

> в сотнях файлов


чел, ты знаешь что такое файл? и как работает скомпилированное приложение?

> Т.е. программируя в стиле ЕЦС, ты должен держать в своей памяти или отдельной от проекта записке, какие сущности у тебя есть и какие компоненты они могут содержать, а в стиле ООП у тебя есть сущности и ты работаешь с ними не задумываясь ни о чём постороннем - всё необходимое для работы у тебя есть в коде.


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

> Забавно, что в маленьком проекте от ЕЦС нет никакой пользы


да, в маленьком проекте типа шахмат, например, лучше его не использовать и так никто и не делает кроме теориетических примеров, а вот в match-3 уже почти повсеместно

> сотни, если не тысячи, отдельных компонентов


количество данных не меняется от того ecs или ооп

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


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

> Мне кажется


а ты меньше доверяй своему малому опыту и больше читай научной литературы по этому вопросу

> а не по компонентам несуществующих сущностей


и снова читай про буковку E
22 779307
>>79302
Зачем в матч3 ецс, сетку конфеток 10x10 сильно сложнее нарисовать, чем шахматную доску?
23 779310
>>79307
ну вот сразу видно, что даже в теории не разбираешься, не то, что в практике
24 779314
>>79310
Ну я не тот, с кем ты диалог вел, и ецс никогда не использовал, вот интересуюсь. Так чем ецс так полезна для мач3?
25 779319
>>79302

>как работает скомпилированное приложение


Не важно, как оно работает, мне придётся держать 100 вкладок в окне Godot, 50 из них будут ...Component.gd, а другие 50 - ...System.gd, и ты считаешь, что это нормально? При том что игровых объектов может быть меньше десятка, но при этом свойств а.к.а. компонентов у каждого больше десятка.

>которые в том числе писали такие системы


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

>match-3


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

>количество данных не меняется


Да, но в ООП они сгруппированы удобно для разработчика, а в ЕЦС они сгруппированы неудобно для разработчика, но В ТЕОРИИ удобно для машины (но никакой гарантии тут нет).

>вот буковка E в ECS и есть та сущность


Которая выражается простым числом.

>научной литературы


С каких пор стало необходимо читать научную литературу, чтобы хотя бы разобраться, что происходит в коде простой игры "три-в-ряд"?

>>79314

>Так чем ецс так полезна для мач3?


Типа вместо экземпляров класса Candy будет массив массивов компонентов CandyComponent, обрабатываемый CandySystem. Но на самом деле нет, будет два десятка компонентов на каждую конфетку.
26 779324
>>79314
в новой создаваемой три-в-ряд ты еще не знаешь ни какие изначально будут эффекты фишек, эффекты поля, структура самого уровня - ecs в данном случае отлично помогает прямо с начальных этапов комбинировать все эти штуки в любых сочетаниях причем не программистами уже, а также легко и быстро написанной тулзой для дизайнеров
как и на более поздних этапах все быстро перестраивается после опять же удобно написанных тестов
а для шахмат уже полностью заранее известны все правила, которые не будут меняться, поэтому тут эффективнее, например, использовать ооп

>>79319
речь конечно не исключительно про godot, но раз уж так...

> 50 из них будут ...Component.gd


компонент почти сразу пишется в исходном виде и после этого закрывается, потому что он практически никогда уже не пригождается

> а другие 50 - ...System.gd


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

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


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

> Пример привести можешь?


выше в этом сообщении описал другому анону

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


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

> Которая выражается простым числом.


только id в контейнере хранилище, а вот в самом еще ссылки на каждый компонент (а еще в более сложных, но эффективных системах еще кэши)
27 779366
>>79324

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


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

>речь конечно не исключительно про godot


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

>после этого закрывается


А если я забуду, что, где и как? На автодополнение надеяться?

>из-за малой связности логики кода в ECS


Я всё понял, ЕЦС подходит только проектам с малой связностью логики, во всех остальных случаях использовать ЕЦС нерационально.

>чаще всего требуется лишь один компонент


Я в это верил, пока не попробовал сам. На практике нереально уложить логику так, чтобы был доступ только к 2-3 компонентам, постоянно нужно больше, и это ломает всю суть ЕЦС. Все эти примеры с покадровым вращением/движением всех сущностей с компонентом вращения/движения - это сферические примеры в вакууме, в реальном проекте от таких систем пользы нет.

Вот что мне больше всего не нравится в ЕЦС - невозможно интуитивно подходить к разработке. В ООП у нас объекты зачастую соответствуют реальным прототипам и/или отдельным объектам игрового мира. Мы работаем с ними почти так, как работали бы с реальными объектами или как игровой персонаж работал бы с ними в своём мире. Всё просто и понятно. В ЕЦС же нет объектов в привычном понимании, мы не можем делать привычные обращения к ним, не можем привычно у них что-то узнать, не можем ими командовать и т.д. Т.е. объектов просто нет. Да, есть entities, но объекты ли это? Нет, потому что мы не можем с ними взаимодействовать, мы можем только перебирать однотипные компоненты... ЕЦС просто противоестественна.
27 779366
>>79324

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


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

>речь конечно не исключительно про godot


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

>после этого закрывается


А если я забуду, что, где и как? На автодополнение надеяться?

>из-за малой связности логики кода в ECS


Я всё понял, ЕЦС подходит только проектам с малой связностью логики, во всех остальных случаях использовать ЕЦС нерационально.

>чаще всего требуется лишь один компонент


Я в это верил, пока не попробовал сам. На практике нереально уложить логику так, чтобы был доступ только к 2-3 компонентам, постоянно нужно больше, и это ломает всю суть ЕЦС. Все эти примеры с покадровым вращением/движением всех сущностей с компонентом вращения/движения - это сферические примеры в вакууме, в реальном проекте от таких систем пользы нет.

Вот что мне больше всего не нравится в ЕЦС - невозможно интуитивно подходить к разработке. В ООП у нас объекты зачастую соответствуют реальным прототипам и/или отдельным объектам игрового мира. Мы работаем с ними почти так, как работали бы с реальными объектами или как игровой персонаж работал бы с ними в своём мире. Всё просто и понятно. В ЕЦС же нет объектов в привычном понимании, мы не можем делать привычные обращения к ним, не можем привычно у них что-то узнать, не можем ими командовать и т.д. Т.е. объектов просто нет. Да, есть entities, но объекты ли это? Нет, потому что мы не можем с ними взаимодействовать, мы можем только перебирать однотипные компоненты... ЕЦС просто противоестественна.
28 779377
>>79366

> Думаю, в жанре "три-в-ряд" всё давно изобретено


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


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

> А если я забуду, что, где и как? На автодополнение надеяться?


а если ты забудешь после блока кода какой end if из пяти к чему относится

> На практике нереально уложить логику так, чтобы был доступ только к 2-3 компонентам, постоянно нужно больше


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

> Вот что мне больше всего не нравится в ЕЦС - невозможно интуитивно подходить к разработке


да, за ее эффективность нужно платить тем, что обучение сложнее

> Да, есть entities, но объекты ли это? Нет, потому что мы не можем с ними взаимодействовать, мы можем только перебирать однотипные компоненты


да, это тот же объект по данным так один в один. Нет, ничто не мешает перебрать компоненты нужной сущности
29 779437
>>79377

> да, это тот же объект по данным так один в один.


Я тебе больше скажу. ЕЦС это тот же ООП, а если по паттернам, так один в один.
30 779438
>>79437
по сумме данных - да
по разбиению данных на составляющие и связность логики - нет
31 779442
>>79438

> по разбиению данных на составляющие и связность логики


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

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


Предлагаешь на слабо сделать три-в-ряд?

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


Как её избежать, если не получается разделить систему на части?

>переходящие из ооп и не сумевшие перестроить парадигму в своей голове


Это логично. Я не спорю, что младенца можно обучить ЕЦС и после этого он не сможет понять ООП, а любую задачу будет решать через ЕЦС, даже если это неэффективно. Непонятно только, зачем переобучать на ЕЦС тех, кто может решить задачу на ООП.

>за ее эффективность


Эффективность в чём? В создании ста миллионов одинаковых сущностей, движущийся по одинаковой траектории? Или в возможности создать монстров из несовместимых компонентов?

>Нет, ничто не мешает перебрать компоненты нужной сущности


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

>>79438
Почему нельзя скрыть всю ЕЦС магию под капотом движка, а программисту разрешить писать привычный ООП код с классами, экземплярами классов, свойствами, методами и т.д.? Все были бы довольны - и код понятный, и производительность высокая.
33 779550
Подскажите, как мне все-таки сделать сглаженные края у Polygon2D? У меня не выходит, как с обычными спрайтами юзнуть оутлайн шейдер.
Результатом должна стать такая граница перехода с помощью SimplexNoise между текстурами, как на скриншоте ниже.
34 779567
>>79550
Самодельный шейдер нужно писать, у которого в самом простейшем случае логика такова:
1. Текстура 1
2. Текстура 2.
3. Нойз (монохромный, в один канал)
4. Функция фрагмента: Взять цвет пиксела нойза по текущим UV-координатам, взять число его яркости, смешать текстуры 1 и 2, используя взятое число как фактор, т.е. Если яркость 0,75, то пиксел текстуры 1 по этим координатам домножается на 0,75, а текстуры 2 на 0,25, затем полученные числа складываются и нормализуются до интервала 0..1 и результат подаётся на выход.

В более сложных случаях Ты делаешь 4 текстуры на каждый канал нойза, делаешь 4х-канальный нойз. И выводишь смесь из 4 текстур. Вместо нойза ещё делают 4хканальную маску, сплатмап так называемый. В аддоне террейн от Зилана например. Да и вообще, сплатмаппинг - это промышленный стандарт. Так что можешь копнуть сорцы Зилан-террейна и узнать, как там в шейдерах текстуры смешиваются.
35 779590
>>79567
Проблема в том, что смещение по uv, по пикселям и чему угодно не работает блеать. Не может шейдер взять текстуру полученную после обрезки изображения и сместить, например. Почему? А хуй его знает.
36 779597
>>79590

> Почему? А хуй его знает.


Матчасть учи. Ютуб полон туториалов, в которых всё прекрасно смещается. А у тебя почему-то не смещается.
37 779605
>>79599 (Del)
Выложить текстуру вдоль границы легко - это просто line2d. Альфаканал текстурой не потрогать.
38 779606
>>79597
Я приложил скрин, где нихуя не работает. Посмотри блять. Половину текстуры должно быть красноватой, половина простым цветом.
39 779608
>>79598 (Del)
Я тоже так понимаю. Печальный факт ещё в том, что взять текстуру экрана так же не помогает чет (
40 779614
>>79613 (Del)
Это я знаю. Но это какая-то залупа так-то. Мучить цпу созданием текстуры - бррр.
41 779618
>>79606

> Посмотри блять.


А я смотрел блять. А теперь ты посмотри, блять https://www.youtube.com/watch?v=CI3JZ-3cabg
42 779626
>>79620 (Del)

> Ты вообще не вкурил что анону нужно.


Всё я вкурил.
1. Есть область канвы.
2. Область делится полигоном на две части, внутреннюю и внешнюю.
3. По полигону отрисовывается шейп.
4. Снимается текстура.
5. В шейдере наподобие видеорилейтед эта текстура юзается, как фактор.
6. ПРОФИТ!
43 779629
>>79626
Ниче не понял. Покажи как сделать/Кинь тестовый проект.

Я только что ебался с SCREEN_TEXTURE наслаивая их с помощью ноды сверху. Нихуя не вышло, конечно же. Но уже было получше.
Потом попытался сделать вокруг полигона колбасу в виде line2d. Нихуя не вышло, т.к. у лайна своя текстура и они расходятся. А если красить сверху, то не ясно как сделать рипит нормально.
Сижу бомблю.

>>79616 (Del)
Ну тогда осталось придумать как её нарисовать.
Безымянный.png216 Кб, 990x677
44 779635
>>79629
Вот примерный эффект которого я ожидаю, только то, что SIMPLEX_NOISE, как и любая другая текстура не бесконечен и в видеопамять придется передавать огромные битмапные рисунки - это грустн.
45 779643
>>79635
У шума есть опция зацикленность (seamless)
46 779652
>>79635

> Вот примерный эффект которого я ожидаю


Тебе уже дали ответ >>79599 (Del)
47 779672
>>79036 (OP)
Вечер в хату. Поддержку .blend файлов завезли? Или пердолиться так же надо?
1638540200683.png128 Кб, 1120x563
# OP 48 779700
>>79672

> Вечер в хату.


Годотский уклад един!

> Поддержку .blend файлов завезли?


А кто спрашивает?

> Или пердолиться так же надо?


Бросаю тебе скриншот оп-поста под ноги. Твои действия?
49 779708
>>79652
У них работает иначе. Они настаивают лайн2д по периметру полигон2д. Но! Лайн2д обрабатывается шейдером потайлово, а не будто это линия, и текстура лайн2д расходится с текстурой полигон 2д. В общем, это костыльный говноспособ. Если ты знаешь как эти костыли обходить, скажи.
Безымянный.png178 Кб, 972x730
50 779712
>>79643
Который с шейдерами чет не очень работает.
Безымянный.png73 Кб, 1238x397
51 779716
>>79652
Отличный ответ. Вот что ты мне предлагаешь.
52 779739
>>79733 (Del)
Так смешение это не то. Смешение это когда ты знаешь 2 текстуры. А я знаю только одну - для текущего полигона. Я должен полигон засмузить так, чтобы лежащий под ним такой же полигон просвечивал через альфу.
53 779742
>>79740 (Del)
А если пепе будет немного зарепичен?
54 779744
Годаны, подскажите, всё ли я правильно делаю. Сейчас делаю "стареющие" предметы. Например, сырое мясо, которое должно со временем тухнуть. Чтобы правильно отображать его в инвентаре, я для предметов создаю стадии старения, каждой стадии приписан тайминг, название, иконка. И у каждого предмета есть время создания. Соответственно, при открытии инвентаря, по всему списку предметов пробегается цикл и вычисляет состояние предмета, юзая текущее время минус время создания, если стадии старения имеются. И соответственно вычислениям предметы переименовываются. Свойства предметов приаттачены к массиву стадий. Если предмет нестареющий, у него просто одна стадия по умолчанию. Соответственно, если стадия поменялась, меняются и свойства. Типа, свежее мясо +1, тухлое -10, ну ты понел.

Всё ли я правильно делаю или есть более элегантные способы?
55 779747
>>79744
У тебя должен быть пул предметов, по которым ты бегаешь и стареешь. Неважно когда. А уже иконка подтягивает из объекта его старение и отрисовывает.
Безымянный.png188 Кб, 1225x864
56 779748
Ебался пол дня. Лучший результат. Жаль только альфа канал отсутствует в SCREEN_TEXTURE, что делает мой геморрой бесполезным. Чет годот не тянет такую задачу.
57 779749
>>79744
старение не должно быть связано с открытием инвентаря
58 779755
>>79751 (Del)
С рипит текстурой у меня нихуя не получается по UV определить границы Polygon2D и соответственно сделать её прозрачной в самом Polygon2D.

1) можно попробовать ещё передать тайл без рипита и отрипитить его внутри шейдера, тем самым упростив поиск по UV границ Polygon2D
2) попробовать сделать рисовалку, когда я рисую по битовой маске, а она отображается в виде текстуры. Вопрос лишь в том, как это все нарисовать динамически, когда у меня есть только полигон.
3) можно попробовать поискать какие-нибудь там world-координаты во фрагментном шейдере и попробовать играть от них. Но судя по сообщениям в гугле - ничего не работает.
4) забить хер и юзать ноисы генерящиеся в шейдере?
Безымянный.png32 Кб, 680x633
59 779759
>>79758 (Del)
Да, работает спам текстурки. Но есть проблема, если значения отрицательные, то случается бага.
60 779761
>>79760 (Del)
не, там abs(UV) надо сделать. В общем не суть. Думаю пока что как смазать нормально границы. Т.к. в твоем примере границы смазываются альфой, но острые углы остаются. Это уродливо.
61 779762
>>79761
Ну и количество точек хотелось бы динамическое.
62 779772
>>79682 (Del)
>>79700
Спасиб, анонче. В глаза долбился
63 779794
>>79748

> годот не тянет


Ты не тянешь. > >>79597
64 779815
>>79794
Стандартные пок-пок-пок. Из-за того, что в годоте нет массивов и результат работы шейдера не передать в другой шейдер, а лучше самому себе, приходится страдать херней, пока разные умники говорят тебе, что ты не тянешь.
65 780065
Анончик скажи пожалуйста, а на этом движке на Андроиде можно игру сделать?
66 780082
>>80077 (Del)
Да, я по поводу сделать игру на Андроиде.
67 780086
>>80077 (Del)

>эмуль линукса


Не надо ничего эмулировать, есть нативные APK билды, но они пока неюзабельны без мышки, да и с мышкой тоже: >>777531 →
68 780203
>>80077 (Del)
Так а с чего начать чтобы понять как делать игру на андроид, на годоте? В основной документации на сайте это есть?
Я вот годот в Стиме скачал, вот открыл документацию
69 780204
>>79036 (OP)
Прохожу мимо треда и каждый раз глаз цепляется за картинку в ОП-посте, какая красивая девочка. Что мне делать, приходится долго отцеплять?
70 780205
>>80204
Двачую, годот смекнули как надо заманивать людей.
71 780237
Годотаны, как лучше поступать, когда от одного суперкласса должны наследоваться два объекта с сильно разными спрайтшитами? Когда я в редакторе ковыряюсь с наследником, постоянно что-то просачивается в поля суперкласса, и всё преврящается в говно, особенно анимация.
Может я тупо не понимаю, когда открыт таймлайн для суперкласса, а когда для наследника, и это я дебил? Или там действительно есть какие-то тонкости?
72 780286
Кто-нибудь в курсе как вообще с портированием на 4 годотю обстоит вопрос?
73 780287
>>80237

> как лучше поступать


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

> годотю


Ты тредом ощибся, скот. Ковыляй обратно в свой загон.
75 780290
>>80288 (Del)
>>80289
Эээ, окей, похоже ошибся бордой... Вопросов больше не имею.
76 780313
>>80287
Да, наверное так и сделаю. Надо будет тогда побольше копипастного кода оформить отдельными методами, если там больше трех строчек.
77 780317
>>80313
Оче рекомендую заранее набрасывать хоть какой-то проект-архитектуру-схему. Чтобы в целом видеть, как и что у тебя с чем должно взаимодействовать. А при реализации придерживаться архитектуры. А если при реализации приходится переделывать архитектуру - вносить изменения в схему. Лично я не могу удерживать всё в голове, а потом получается так, что у меня горы кода и хуй проссышь, что с чем взаимодействует. Если у тебя такой проблемы нет, то конечно забей на проектирование.
78 780393
>>79036 (OP)
Я хочу сделать менюбар, поиск не помог. Такое возможно и как?
79 780397
>>80396 (Del)
Благодарю.
Ещё вопрос, хочу для тренировки сделать сапёра, переношу из финформс, знаю, что есть tilemaps, нашёл как определять которая над которой из ячеек была нажата кнопка мыши. Есть ли какие-то сложности с генерацией поля из тайлов?
80 780417
>>80411 (Del)
Понял.

Ещё вопрос, а как обычно делается универсальная единица размера спрайта? Мне нужно как например при использовании OpenGL, где я я такую вычислял в пикселях как отношение высоты к числу 18, а дальше везде такой размер использовал. Это я хочу сделать чтобы разрешение текстуры спрайта могло быть любым.
81 780452
Здрасте. Скажите, а как в Годоте сделать двойную буферизацию? То есть, чтобы я сначала через скрипт сделал ряд изменений, и только потом весь результат отобразился на экране одновременно, а не по очереди, по мере выполнения скрипта.
82 780456
>>80427 (Del)
Понял, благодарю за ответы
83 780480
>>80396 (Del)
Досмотрел до 3:17 и скажу, что я бы сделал себе ноду-хелпер, которая бы ставилась в чайлды менюбаттону и у себя в ready добавляла бы элемент меню со своим именем, и с колбэком, и с иконкой и с тем, что ещё понадобится, и получил бы менюподобную иерархию у себя в редакторе, а ещё такая нода-хелпер могла бы перебирать паренты парента пока не встретит менюбаттон и запоминать иерархию и пытаться воспроизвести аналогичную, и так я бы сделал многоуровневое меню. Смотрю дальше.
84 780484
>>80480

> Смотрю дальше.


Досмотрел. Этому видосу джва года и за это время афтор вырос от перебора элементов по строковым именам до собственного аддона диалоджик. Это успех!
изображение.png9 Кб, 245x250
85 780486
Как обратиться к этому масштабу? Оно есть у всех объектов если что. Цель уменьшить масштаб tilemap через скрипт
86 780491
>>80489 (Del)
Да, только что получилось, функцию которая это делала не вызывал.
87 780549
>>79036 (OP)
Благодарю всех за подсказки, движок очень понравился. Работает быстрее WinForms
# OP 88 780553
Дурной пример заразителен: https://www.youtube.com/watch?v=ssjbt_6RmKY

Узнали? Согласны?
89 780556
>>80555 (Del)

> В чем он не прав?


Нет ничего более мерзкого и безвкусного, чем первое триде времён первой соньки. Делал бы стилизованное лоуполи - был бы от меня почёт и уважуха. Впрочем, кто я такой? Обычный безыгорный пиздабол с двачей. А тысячи мух не могут ошибаться, ностальгирующие бумеры раскупят это поделие, как горячие пирожки. Хррр-тьфу!
90 780559
>>80556
По мне так для инди разрабов количество поликов на уровне HL2 -> ME2 это более чем отлично, при условии, что возможно, ну и разумеется ZBrush + Substnace

Ща инструменты развились на отлично
91 780561
>>80556

>первое триде времён первой соньки


Да ладно, делали бы в стиле Megaman Legends или крэша - ни одной претензии к ним бы не было. Я вот, например, пытаюсь постичь этот стиль, хотя пока получается не особо. Но сейчас вошла в моду эта вырвиглазная лоуфай пс1 хоррор демо диск параша, и все бездари тут же за нее ухватились. С другой стороны, инди пуксель арт в свое время тоже у всех вызывал рвотные порывы, зато сейчас индюки намастрячились делать пуксель арт чуть ли не лучше, чем у СНК в лучшие годы. Ну то есть понятное дело, что говно никуда не делось, но оно заняло свое заслуженное место возле параши, сейчас я не вижу распиаренных проектов с макаронными человечками и пикселями на полэкрана.
92 780562
>>80560 (Del)

> А бывает вообще стилизованное лоуполи про какой-то мрачняк? Обычно там зеленые деревца от которых уже тошнит.


как ни странно, но тут очень удачно сделанное лоуполи с удачным же аудиорядом, если авторы случайно попали и там и там, то им крупно повезло
https://store.steampowered.com/app/252630/Eldritch_Reanimated/
1639165597237.png1,9 Мб, 1200x672
93 780563
>>80561

> сейчас я не вижу распиаренных проектов с макаронными человечками и пикселями на полэкрана


Я прямо щас смотрю лецплеи Куплинова с относительно свежей игрой про игру в пиксельные карты с лютым сотоной. Прям пиксель арт приксельартушный.
94 780564
>>80562

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


Пиксельные текстуры говно. Рыганул бы афтору в ебало тугой струёй. Таков уж мой вкус, без обид, пикселеёбы.
95 780568
>>80564

> Пиксельные текстуры говно


ну покажи свои векторные текстуры
96 780571
>>80566 (Del)

> Кубы немного не то


так смотри на монстров и предметы как там сделали и как их еще покрасили толково, кубы там просто особенность игры, речь про стиль
97 780572
>>80570 (Del)
ссылочку на игру скинь, где такое применяют (не то, где пиксельными шейдерами только)
98 780574
>>80566 (Del)

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


Именно такое.
>>80556-кун
Хуан 99 780594
Сборки 4 версии юзабельные? Автолоды и оклюшн кулинг работает?
100 780599
>>80563
Ты дебил, я не говорил тебе, что пикселей нет, я говорил, что сейчас уровень выше стал. Твой пик явно получше выглядит, чем какой-нибудь VVVVV, не находишь?
1606144880341.png344 Кб, 820x820
101 780600
>>80566 (Del)
Как же я этот бездушный стиль ненавижу. Рака яиц всем, кто его использует. Такая же параша, как Globohomo Corporate Style.
102 780606
>>80600
Двачую.
Прям выворачивает от подобной хуйни и хочется найти и убить того, кто так делает. Не жестоко, а просто устранить это существо, чтобы такого больше не было.
103 780613
>>80606
Не, в теории можно даже бестекстурное лоу-поли сделать годно. Вот тебе пример с форчика:
https://store.steampowered.com/app/1347550/Tiny_Combat_Arena/

Но здесь-то они не стараются, тупо делают на отъебись, бездари.
изображение.png130 Кб, 640x360
104 780624
105 780625
>>80600
>>80606
Дяденьки, графон делать сложно, вы не понимаете.
106 780643
>>80566 (Del)
Я думал этот стиль устарел лет как 8
585.png102 Кб, 1116x1018
107 780644
>>80600
Ну так потому что этот стиль ассоциируется с бездушными поделками из гуглплей, сделанные из скаченных ассетов лишь для выкачивания денег.
1639233895233.jpg32 Кб, 600x401
108 780645
>>80643

> стиль устарел


Настоящий стиль не устаревает. Если "стиль" устарел, то не стиль это вовсе, а китч.
109 780655
>>80643
Имплаин он хоть когда-то не был ебаной парашей.
110 780743
>>80727 (Del)
Спасибо за пост. Было познавательно.
111 780818
Так а как в итоге то делать на годоте андроид игру?
Создавать проект как обычно, делать, а потом экспортировать? А как экспорт проводится?
112 780845
>>80844 (Del)
Рано ещё, ИМХО.
113 780867
>>80856 (Del)

>SDFGI


Хуан зря несколько лет жизни проебал на эту систему, нужно было допиливать лайтмапы и ждать карты с ртх как юнити
114 780869
>>80867

>SDFGI


>несколько лет жизни проебал на эту систему


При том что она к железу очень требовательная и картинку выдает не хорошую. Хотя опять же, сколько ждать, когда средней станет какая-нибудь хорошая карта с лучами
115 780906
>>80867
Так лайтмапы допиливаются.
116 780940
>>80906
Да я тестил, делают годно и вроде пекутся быстро и красиво. Но он их пытался внедрять еще в годот2, и в 3 и все бросал, тратя время на свои революционные реалтайм ги. Воксельные пробы говно, sdfgi полуговно, зря он это затеял, эксперименты это удел больших команд. Он писал, что уже знает как улучшить sdfgi, но типо это случится только в 4.1, но поди опять пиздит, посмотрим
117 781191
>>79036 (OP)
Стандартный вопрос, на который я не смог найти ответа.

Есть кнопка текстурная в ноде А, есть игра в ноде БЭ.

Как мне получить состояние, что эта кнопка нажата в ноде БЭ?

Про набор стандартных методов в узлах знаю, но не хочу городить велосипед в виде дополнительных bool значений.
118 781196
>>81194 (Del)
>>81195 (Del)

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

И да, я не уточнил про ноды - в моём случае нода с кнопкой находится не в основной ноде где игра запускается, а отдельная заготовка, наверное это можно ещё назвать префабом, экземпляр которого уже и создаётся в основной ноде.
изображение.png12 Кб, 334x137
119 781206
>>81199 (Del)
Вопс, ларчик просто открывался, ахахаха. Изначально я вызывал метод с таким названием, ожидая, что он есть по умолчанию, но после экспериментов и взора на англ доки, выяснилось, что таки есть переменная, отлично.
120 781276
>>81131 (Del)
Что по фпсикам?
121 781329
>>81326 (Del)
У него там игры уровня твг же, что на них можно так подняться?
122 781431
>>79036 (OP)
Господи, какая же шняга этот годот. Я правда пытался мириться со сломанным функционалом (типо навигации, где без костылей хуй она нормально заработает), но сегодня меня доебало.
Я надеюсь движок станет лучше и пофиксит баги четырехлетней давности, которые реально мешают делать нормально без костылей.
Попробую перестать быть годо-дауном и вкачусь во что-нибудь ещё.

Да, пошёл я нахуй, просто мне больше некуда выговориться
123 781434
>>81431
ЗЫ: Я ни в коем случае не говорю что пользователи движка дауны. Это, скорее, самоирония (типо не могу выучить нормальные языки, потому юзаю гдскрипт)
124 781474
>>80624
Я бы это представил в виде кривой обучения.
Просто в какой-то момент понимаешь, что вот это, это и это не надо так делать, здесь лучше упростить, и выходит, что на всё хватает gdscript.
>>80600
Для многих графон и геймплей - два разных конца одной палки. Согнуть палку, чтобы получить обе штуки в одном месте, может не каждый.
125 781475
>>81329
Ну, по логике, можно найти привлекающий концепт так, а потом его развивать.
126 781489
Есть сцена-уровень, на которую можно попасть с разных сторон через двери. Скрипт уровня спавнит игрока на onready.

Игрока нужно спавнить перед той дверью, через которую он зашел.

Как бы вы решили эту задачу? Передавать номер нужной двери через автолоад?
# OP 127 781505
>>81489
Через конфиги.
Каждая сущность в игре при своей загрузке поднимает из хранилища свой конфиг в удобном тебе формате и читает данные из него и конфигурирует себя.
В твоём конкретном случае в конфиге должен быть как минимум флаг ИгрокВышелЧерезДверь=3 означающий собственно, что игрок вышел через дверь 3. Либо еще универсальнее, каждой двери соответствует спавн-поинт, через который игрок спавнится на уровень. Значит параметр в конфиге будет LastSpawnPoint=Door3 тут, как видим, заспавниться игрок может, как у деври, так и у окна, например, или в дымоходе, как Санта Мороз.
Все конфиги хранятся в сейв-файле.
При выгрузке локации, если игрок просто закрывает игру, этот параметр не записывается (стирается, обнуляется). Если игрок покинул локацию через один из телепортов, параметр записывается, локация выгружается.
Сейв-данные - это синглтон, открывается при старте/загрузке игры, постоянно пишется в память при изменении параметров игры (как загрузка и выгрузка локаций, вскрытие сундуков, убийства мобов) а при сохранении (хоть по точкам, хоть вручную по Ф5) сейв-данные сразу готовы и моментально сбрасываются в файл.
Соответственно, при загрузке всё в обратном направлении.
И не забудь, описывая менеджер загрузки, введи блокировки на модификацию данных при осуществляющемся сохранении/загрузке, чтобы не получилось так, что пока ты сохраняешься, половина данных уже переписалась. Нет. Как только активируется сейв, всё, данные блокируются и слепок состояния игры записывается в неизменном виде.
Так же этот подход идеально применим к быстрым загрузкам, например, когда игрока ваншотает босс, чтобы не грузиться долго из сейв-файла, в памяти висит слепок сейв-данных перед боссом. И моментально разворачивается в "продакшон".
# OP 128 781511
>>81509 (Del)
Если говорить совсем технически, то в игре с отдельными локациями вообще корректно говорить не о дверях, а о телепортах, каждый телепорт соединяет две точки, входа и выхода. В таком виде система никак не ограничивает девелоперов в полёте фантазии. Два взаимных телепорта = дверь. Если надо подменить локацию, после выхода из неё (например, подставить сгоревшую, ограбленную, или захваченную инопланетянами) то в игровой логике происходит переключение всех телепортов, ведущих в эту локацию на её модифицированный вариант. Такое навскидку часто практикуется у джастворкса всея Земли, Тодда Говарда.

В этом случае следует позаботиться об организации данных в сейве так, чтобы можно было скармливать файлу (или его инстансу в оперативке) модифицирующие запросы. Необязательно прям СУБД организовывать, разумеется, но минимально матчасть желательно знать. Чтобы по желанию девелопера можно было хотя бы циклом пробежаться по сейву и опросить все содержащиеся там объекты "телепорт", если точка спавна относится к локации = локация_несгоревшая, то точка спавна = локация_сгоревшая.координаты.

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

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

Поправьте, если ошибаюсь, годаны.
129 781521
>>81509 (Del)
>>81511
Спиздил код из документации, немного поправил. Все верно сделано?

Сейчас я просто в редакторе выбираю сцену которую надо телепортироваться, и указываю номер портала на этой сцене. Я вот думаю что когда локаций будет несколько десятков.
image.png29 Кб, 763x368
130 781522
>>81521

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


Вот так делаю
131 781542
>>81521

> Все верно сделано?


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

Телепорт должен только посылать сигналы о том, что в него зашёл игрок. Сигналы телепортов принимает единый менеджер сцен и меняет сцены, сообразно данным, переданным из телепорта. Обдумай этот подход. Это композитный подход с отношением к контенту как к данным. Известен как DOD, ECS, фанаты этого подхода видят только обертку не понимая сути, пишут плагины для реализации этого подхода в годоте. Но если открыть глаза, ты увидишь, что в годоте всё уже организовано для реализации систем, сущностей, как их не назови.

Я сам охуел, когда это осознал. Годот - это ESC-ориентированный движок. Прямо со старта игры происходит что? Движок поднимает PAK-файл с данными и движется по ним как первоначальная стартовая так сказать система, которая извлекает сущности и другие системы, сериализованные в PAK-файле, а они уже выполняя свою логику, работают. Стоит последовать этой парадигме и ты обнаружишь все инструменты в движке, позволяющие программировать игру именно как композицию сущностей и систем.
132 781606
Есть смысл учить питон?
133 781619
>>81606
Есть смысл учить паттерны. А потом, когда заучишь на зубок, просто смотришь, как реализуются те или иные паттерны в том или ином языке.
15938435030920.jpg4 Кб, 170x137
134 781706
>>79036 (OP)
Кто-нибудь мне блять может нормально простым языком объяснить, зачем нужен _ready и дрочь с oneready var?
В документации хер найдешь прямой ответ на этот простой вопрос.
135 781735
>>81709 (Del)
Спасибо
Godot, мне что-то нехорошо.png10 Кб, 168x126
136 782964
Новый год - новые открытия. Внезапно, draw calls влияют на производительность, и у меня их слишком много... Но в интернете как всегда никто не знает, к какому числу стремиться, только "чем меньше, тем лучше", а сколько нужно-то?

>>81709 (Del)

>_ready вызывается, когда нода добавляется


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

>onready var - это просто сокращенная запись


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

>зачем вообще нужен дроч с переменными?


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

>>81706

>В документации хер найдешь прямой ответ на этот простой вопрос.


В новом году научись документацией пользоваться)
https://docs.godotengine.org/en/stable/classes/class_node.html#class-node-method-ready
https://docs.godotengine.org/en/stable/getting_started/scripting/gdscript/gdscript_basics.html#onready-keyword
137 782982
>>79036 (OP)
С новым годом вас!

У меня снова вопрос

Не нашёл адекватного способа проверить зажата или клавиша мыши, отпущена, отжата ли она, лол.
138 782983
>>82964

> а сколько нужно-то?



Посмею сказать, что 1000 для 2д максимум
139 782984
>>82982
Это потому, что ты документацию не читал. Читай документацию. Желаю тебе ума в новом году.
141 782988
>>82984
>>82985

Там есть только pressed анон, я это уже смотрел. Если бы всё было так просто, я бы не стал спрашивать.

Например, когда я писал на glut + C++, там не было никаких проблем с этим, все варианты состояний клавиш были. Тут же есть только состояние ЗАЖАТА, но вот отжата или нет ты не выяснишь, из-за чего даже хитрые костыли не помогают.
1641122426283.png215 Кб, 512x384
142 782989
>>82988

> отжата или нет ты не выяснишь


pressed = false
143 782991
>>82989
И теперь все блоки под мышкой по умолчанию открываются, особенно если это запихнуть в process.
144 782992
>>82991
Нахуевертил с логикой. Нарисуй мне в пейнте и запости прямо в тред блок-схему того, как должно быть. И я на 80% уверен, что пока ты будешь рисовать блок-схему, ты увидишь свой косяк, но если не увидишь - то подскажу тогда я.
145 782993
>>82992
Разумеется, блок-схема, которую ты нарисуешь должна отражать твой реально существующий код.
146 782995
>>82991
А хотя нет, можешь не рисовать, у тебя нет разделения на сабклассы, которое рекомендуется всеми гайдами, документацией и туториалами. Вид у неё такой:

func _input(e):
__if e is InputEventMouseMotion:
____# do motion actions
__if e is InputEventMouseButton:
____if e.pressed:
______# do mouse pressed button actions
____else:
______# do mouse released button actions

у тебя же подобной конструкции нет, и какой бы ивент ни прилетал, ты пытаешься обращаться к нему, как к маузбаттону, а он-то в этом кадре маузмовшн!
147 783000
>>82995
Интересная тема, частично использую
>>82996 (Del)
Это ближе всего, ибо на это натыкался, но без весомых подробностей
изображение.png39 Кб, 318x382
148 783001
>>83000
Добавлю, что проблема скорее не в мыши, а в том, что я обработку TileMap делаю как у кнопки для каждого элемента, отсюда вся возня. Частично уже сделал
149 783003
>>83001
В сапёре тайлмап ИМХО только помешает. Я бы делал на кнопках. Выстроить их в поле и занести в массив - пять секунд делов и десяток строчек кода.
150 783004
>>83003
Щас сделою, ёпта! Никуда не разбегайтесь.
151 783005
>>83003
>>83004
Анон, я не гуру программирования, но в моей версии сапёра не всё так просто как тебе кажется. Сейчас мне осталось доделать двойное нажатие, убрать глюги, да размеры поля до 256 на 256, а то, где кнопочки отображается лишь окно, ну и вишенка на торте - самозамкнутое минное поле.
TestoMinner.webm2,4 Мб, webm,
960x540, 1:31
152 783006
153 783007
>>83003
Каждая кнопка вызывает дравкол. Не юзай кнопки! Наоборот надо где можно всегда делать тайлмап
154 783009
>>83007
Посрать на дравколлы в игре типа "сапёр", блять! Таблетки прими, у тебя дравколячка.
155 783010
>>83009
Он прав, ты бредятину пишешь. Идея делать поле сапёра из кнопок, а потом ещё всё это в цикле ебашить наитупейшая. ПК даже современный ахуеет от поля в 24 на 30, не говоря уже о том, что у меня в видео выше таких полей 9 штук для замкнутости.

Одно мне неизвестно - TileMap рисует поле спрайтов по принципу InstanceRendering как OpenGL или нет? Можно ещё процом запекать потайлово в общую текстуру.
156 783011
>>83010
Тайлмап юзает вроде как оптимизон с помощью рипита текстуры. Что там в опенгл хз.
157 783014
>>83011
Так просто повторить текстуру как ты думаешь не получится. Когда у нас есть одна, то проблем нету, но когда речь идёт про разные текстуры, то тут либо смешивать маской одну большую с разыми затайлеными кусками, либо в экран копировать с той же маской там, или по ИД рисовать. Подозреваю, что второе быстрее и реализуется быстрым даже если процессором попиксельно будут копироваться куосчки с учётом масштаба.
В OpenGL карточкой рисуется 3д один и тот же объект с немного разными параметрами и текстурой.
158 783016
>>83010

> Он прав, ты бредятину пишешь.


Признаю. Хуйню сморозил, пасаны.
159 783017
>>83016
Не получилось сапёр бахнуть кнопками?
160 783018
>>83017
Да. Оказалось, кнопки не подходят. Я начал пилить самодельную кнопку на основе Спрайта, но поймал себя на мысли, что велосипежу функционал тайлмапа. И тут твой пост. И я такой, ну лан, похоже я хуйню сморозил.
161 783019
>>83018
Я годо для 2д потому и выбрал, что немножко присел от мысли рисовать instance, ибо неудобный он в OpenGL, не шмог я кароч, а помимо него надо текст и кнопочки ещё.

Зато можно и нужно делать симуляции вселенной и взаимодействия неких минимальных элементов.
1641129584760.png36 Кб, 544x274
162 783021
>>83018

> поймал себя на мысли


Пикрелейтед.
163 783023
>>83019
Есть ещё третий вариант, отрисовать весь сапёр целиком на холсте одного объекта типа CanvasItem, но он тоже тормозной как выяснилось, ибо каждая функция вида

> draw_line


> draw_arc


> draw_text


> draw_texture


- это отдельный дравкол, со всеми вытекающими.
164 783028
>>83022 (Del)
720 вызовов на отрисовку за кадр, а их в секунду может быть и 2160, и 4320, и даже 72000 в сумме.
165 783031
>>83024 (Del)
Есть. Но там как-то сложно всё.
166 783032
>>83030 (Del)
Тогда я велосипед изобрёл. Как посчитать количество вызовов на отрисовку?
167 783037
>>83027 (Del)
В общем-то, чтобы реализовать сапёра, в такую кнопку надо ещё 10 текстур запихнуть (ссылками) и менять по необходимости. В итоге проще сделать логическую обвязку вокруг существующего тайлмапа, где нужно просто индексами тайла жонглировать.
>>83021>>83018-кун
168 783040
>>83039 (Del)
Я изначально про кнопку и сказал из-за того, что там можно было бы без задней мысли выводить цифру, сразу отцентрированную. Но немного поразмыслив, я понял что победа там окажется пирровой.
изображение.png17 Кб, 531x163
169 783044
У меня ещё вопрос. Я использую самописные библиотеки на скрипте, предзагруженные, а так же автоматически загруженный глобальный скрипт. После правки в класс из неё по обращению через точку к члену этого класса выдаёт старое имя. Удаление скрипта не помогает, он где-то закеширован. Как мне обновить? Смотрел в нете, но там велосипеды какие-то.

На картинке то как я загружаю скрипты.
170 783046
>>83038 (Del)
Попробую
171 783058
>>83044
Посмотри "настройки проекта > плагины" есть там что?
изображение.png78 Кб, 895x1202
172 783060
>>83058
Ругается на способ объявления что ли, самого объекта. Интсрукцию читал, но ноды под названием Monitor там нету, зато целый список других есть
изображение.png49 Кб, 956x562
173 783064
>>83062 (Del)
Н-не очень, кек

>>83063 (Del)
Я ща удалил папку addons и теперь у меня указанная в блоке Run нода не запускается, проверял print в _ready(), он её нагло игнорирует. Игра всё, ахаха.

Наверное я попробую обновить годо, точнее запустить новый скачанный
174 783066
>>83065 (Del)
Ща бы делать бекап после того, как всё наебнулось.
175 783075
Новый двиг скачал, проект восстановил, plug включил, но не задействовал, не ругается. Осталось только понять что добавлять или что создавать.
176 783081
>>83076 (Del)
Что-то немного я перенапряглся, в примере там надо создавать canvas layer и к нему скрипт прикреплять. Добавить ноду Monitor не очень похоже на это, что и напрягло меня.
177 783083
>>83081
Чел, ты велосипед изобретаешь...
178 783085
>>83083
Хотелось бы поподробнее узнать момент когда я начал его изобретать, а когда ещё нет.
179 783099
>>83093 (Del)
Мне скрипт пихать куда тогда? Или как? Которую tsсn добавлять? ЯННП

Так то работает, до 34 вызовов на отрисовку, в среднем 20. Отлично для 1152 кнопок. Ща попробую бахнуть поле 256 на 256, кек.

Каждый тайл 128 на 128 пикселей, масштабируется, а то вдруг я захочу погамать на монике в 2160ПЭ. Предел по графону 3456 ПЭ, на будущее лол.
А вот почему там 60 предел, видать где-то в настройках включено, ибо я сам насильно не врубал. Нашёл только предел в 60 по физике, надо поставить 30, ибо больше не надо.
180 783111
>>83104 (Del)
VSync стоит по умолчанию

> Я прямо в главную сцены игры пихаю все отладочное



Там в папке addon куча файлов, вот прямо все? И к чему тогда обращается ЭТО
$Monitor.add_perf_monitor(Performance.TIME_FPS, "FPS")
$Monitor.add_perf_monitor(Performance.RENDER_2D_DRAW_CALLS_IN_FRAME , "DrC2D")
если такой ноды или файла по умолчанию нету ни в сцене, ни в папке.

Что я понимаю не так?
181 783125
>>83117 (Del)
И правда, я совершенно по иному мыслю, вот до чего доводит программирование на ЦЭ++, уже по умолчанию привыкаешь, что ничего просто так само не создаётся и всё надо ручками с огромными усилиями, ыыыыы.

Ясно почему от других моих проектов люди часто в шоке.
182 783130
>>83129 (Del)
Я определённо правильно поступил, что не стал писать сапёр для освоения годо на шарпе.
183 783151
При попытке родить поле 128 на 128 девять раз по углам и в центре ругается на переполнение стека. Как его понимать? Это предел TileMap или чего? Указано число 1024, 128 128 9 = 147 456. Проблема в этом? Да вроде бы нет, 24 48 9 = 10 368.
Да и какого хрена, ничего я там рекурсивно не вызываю.
1641143154579.png8 Кб, 371x370
Объявлен новогодний 184 783153
Сапёр-челлендж, посаны! Чтобы к утру у всех участников были работающие сапёры. Поехали!

Призовой фонд - пак Годетты.
TestoMinner002.webm2,1 Мб, webm,
960x540, 1:23
185 783155
>>83151
64 на 64 смогло без БЭ
Объявлен новогодний 186 783162
>>83158 (Del)
Нельзя. Бомбер есть в ассетах, а майнера нету. Майнера, лол!
187 783168
>>82983

>1000 для 2д максимум


Хорошо, а 3D? А на мобилки?

Я когда-то где-то читал, что на мобилки в 3D - не более 100 вызовов отрисовки, иначе мобилка не справится. Ну это понятно, что мой попенворлд нужно оптимизировать, чтобы не было тысяч вызовов, но хотелось узнать более точные цифры, на что ориентироваться.
188 783169
>>83161 (Del)
Уже не первый раз получаю её от TextEdit, данные которого получаю как на второй.

Только что пробовал сделать сразу на 128 128 и 256, создал, да, задумался и при обработке тоже, но создал.
001.jpg565 Кб, 1582x884
189 783170
>>83168
На 100, если мобилки, на 1000 если ПК, но даже старый ПК сожрёт и 50 000 не напрягаясь. Я так думаю, выше анон тестировал на 750ТЫ, у меня вообще 290Х с 5.6 ТФлопс. Лагала только в УЕ4 когда я это без лодов рендерил.
190 783173
>>83153
Внезапно, но как и в любой игре, обвязка самой игры - гуи, настройки, всякие датчики с игровыми состояниями сложнее и скучнее делать чем саму логику игры.
191 783177
>>83044

>где-то закеширован


Проверь папку %appdata%/Godot - прям так и вводи (окно "выполнить" (winkey+R) или адресная строка Проводника (F4)), если ты на Windows.

>>83060
Там тебе красным по синему чётко сказано: у тебя скрипт наследуется от Panel (который наследуется от Control), а ты пытаешься навесить его на ноду Node2D, которая является отдельной веткой наследования и несовместима с потомками Control (и Spatial).
192 783180
>>83178 (Del)

> сохранения



Это ещё делать над для совершенства минёра, да, уныло, но не так сложно.
193 783181
>>83177

> Проверь папку


Там логи, малоинформативные

> у тебя скрипт наследуется


В итоге оказалось, что после копирования плагина надо добавлять ноду Monitor
194 783182
>>83170

>даже старый ПК сожрёт и 50 000 не напрягаясь


Смеёшься что ли? У меня лаги уже на 10 тысячах.

>750ТЫ


У меня тоже 750 Ti, но фигня в том, что видеокарта отдыхает - только одно ядро процессора (E5450) загружается на 100%. Может, конечно, это не только из-за вызовов отрисовки, раньше я видел проблему в количестве нод и физических объектов, но когда начал следить за вызовами отрисовки - заметил сильную связь между количеством отрисовок и частотой кадров, т.е. со статичным числом нод и практически отдыхающим физическим движком.
195 783185
>>83182
Смотря что рисуется. По идее всё 3д надо через instance рисовать, я потому перекатился на движки, что уныло это писать ручками. Но внезапно, ни в унити, ни в УЕ4, это не было реализованно из коробочки - создаёшь 3д объект например особенный, с пометкой, что он instance, он у себя там запоминает меш, потом при копировании он запоминает атрибуты - ид, масштаб, координаты, текстуру, шейдер, хрен знает что, и рендерит, но нет. Как я матерился когда искал нужные мне данные для унити чтобы воксели описать, это кошмар, тривиальную срань пжлст, а что-то по настоящему сложное, нет.
Новогодний уан найт гейм джем 196 783189
>>83173
Тогда юзайте челлендж этого анона: >>83155 поле сапёра должно быть тороидным - верх переходит вниз, право переходит влево, соответственно и расчёт мин в соседних клетках должен это учитывать.
Задачка на пять с плюсиком: тороидность должна быть опциональной в настройках.
Задачка на пять в четверти: обойдитесь без тайлмапов.
Новогодний уан найт гейм джем 197 783190
>>83189
Время до полудня по Москве, завтра 3 января, финалки выкладывать вебэмками прямо в тред.
198 783193
>>83185

>через instance рисовать


Ты имеешь в виду MultiMeshInstance? Потому что обычный .instance() создаёт полностью независимые объекты.

>>83189

>обойдитесь без тайлмапов


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

> Ты имеешь в виду MultiMeshInstance?



Да
200 783196
Кстати, с сапёром знаком очень давно, но я до сих пор не знаю зачем нужен вопрос. Пробовал, но разницы с простой не открытой кнопкой не нашёл. Подозреваю, что это пометка игрока для самого себя.
201 783203
>>83196

>Пробовал, но разницы с простой не открытой кнопкой не нашёл.


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

>Подозреваю, что это пометка игрока для самого себя.


Именно так. Флажок - это метка "я знаю, что тут мина, сюда кликать нельзя", а знак вопроса - "я не уверен, есть ли тут мина, нужно будет потом перепроверить".

Хотя сам я эти значки вроде не использовал, можно пройти вообще без них и даже без флажков, если память хорошая.
202 783214
>>83153

>пак Годетты


Стесняюсь спросить, это какой-то эксклюзивный NSFW контент или просто скачанные с интернетов джипеги? Если второе, лучше уж поделиться со всеми в конце конкурса.

Ощущение, что шутка прошла мимо меня...
1641152625311.png73 Кб, 624x530
Новогодний уан найт гейм джем 203 783221
Ну что вы, бэтмены?
Кто с нами?
Работа кипит! Мины уже рандомятся. Часики тикают.

>>83214
Да, просто пак. Ой, да какая шутка, ха-ха... Не смешно.
204 783222
>>83221

>Мины уже рандомятся


Кстати, буквально сегодня читал, что мины в сапёре не полностью рандомно расставляются. Tl;dr:
- первый клик всегда на чистую клетку, поскольку мины генерируются после первого клика, а не после нажатия "новая игра";
- есть разные способы расстановки мин, от них зависит геймплей;
- если мины расположены слишком плотно, играть не так интересно, но реже приходится угадывать;
- если мины расположены далеко друг от друга, чаще возникают ситуации, где приходится угадывать.
На основании этого есть мнение, что сапёр - это игра с процедурной генерацией, в отличие от солитёра или покера, в которых чистый рандом (в сапёре рандом структурирован, в нём есть правила).
http://roguelikedeveloper.blogspot.com/2008/05/minesweeper-vs-solitaire.html?m=1
1641158055180.png85 Кб, 794x548
205 783232
>>83222
Кор-механика готова. Я спать. Завтра с утреца доделаю графиниум, менюшки, расстановку бомб после первого клика и можно побеждать в своём же конкурсе.
1641158909123.png57 Кб, 962x985
206 783234
Вырвиглазненько!
image.jpg51 Кб, 600x400
207 783261
Вот блин, я почти всю ночь рисовал спрайты в Inkscape, а потом всё утро выдумывал сюжет и гэги для 19 концовок (больше делать пока лень). В Godot так и не зашёл, сил больше нет, я спать.
Zalupka.gif7,1 Мб, 1899x941
208 783270
Потихоньку кириллю свою бродиловку/говориловку на годоте. Сейчас вот допиливаю движок, чтобы в будущем просто раскидать обьекты и неписей по карте с минимумом хардкода.

Для диалогов использую Dialogic - очень удобная штука.
Новогодний уан найт гейм джем 209 783274
Пора подвести итоги.
Я выбываю из конкурса, потому что с квадратным полем всё работает, а если задать прямоугольные размеры - out of bounds.
Всё утро тупил над кодом, пихал принты куда только мог, нихуя. Чувствую, что проблема до смеха простейшая, но глаз замылен.
изображение.png43 Кб, 610x497
210 783278
>>83274
Ещё на старте искал как сделать массив в годо, в С++ обычно использовал одномерный, подразумеваемый как двухмерный, в годо просто в лоб двухмерный.
211 783280
>>83278
Я был одним из двух анонов, обсуждавших с тобой массивы, и мы оба предлагали юзать одномерный, плюс функцию-хелпер, которая по формуле x+y*max_y выдаёт элемент по двумерным координатом с фиксированной высотой столбцов. И проблема у меня походу в ней. Делаю по столбцам - вылет на строках. Делаю по строкам - вылет на столбцах. Чего-то очевидного я недовтыкаю.
212 783281
>>83280
Ну конечно же, блять!
Ебанарот!

> x+y*max_x



БЛЯТЬ!
213 783283
>>83280
Поэтому лучше делай двухмерный и не парься, проблем в скорости даже! на поле тайлов в 768 на 768 элементов не было вообще.

Касаемо переполнения стека, я вчера поздно вечером понял, что проблема в классах помощниках, которые я создаю в функции, которая в свою очередь вызывается очень много раз. Ну кароч сборщик мусора не всегда поспевает прибраться походу, так что перепишу на менее жрущий вариант.
214 783284
>>83281
И мгновенно всё заработало с любыми вариантами поля!
215 783285
>>83283

> лучше делай двухмерный и не парься


Как видишь, нет. Главное, правильно применить формулу и двумерный массив - ни-ну-жна. Твёрдо и чотко!

А вот вопрос на засыпку всем, а эту формулу как-то можно расширить на эмуляцию в одномерном массиве массивов любой размерности?
216 783286
>>83283
Кроме того у меня вообще нет дополнительного массива. Созданные кнопки - это массив чайлд-нод ноды-поля, соответственно, необходимости в дополнительных массивах вообще нет. Минимализм.
217 783288
>>83285
>>83286

Расширить не проблема вообще на любую, но тут проблема в проверках границ.
Касаемо минимализма, декомпозиция наше всё, иначе выносящие мозги формулы и код
218 783291
>>83288

> выносящие мозги формулы и код


Только так мы не дадим мозгам деградировать! Даёшь хитросплетения!
1641204137240.png30 Кб, 483x450
219 783296
Игра с самопроизвольно образовавшимся читом - не проверяются пока неправильно выставленные флажки. Без чита я такую катку бы не затащил.
1641205594833.mp412,1 Мб, mp4,
1200x900, 3:26
220 783299
>>83296
А вот как это происходит в динамике. Я выставляю флажок и прощупываю. В настоящем сапёре без чита, неправильный флажок привёл бы ко взрыву. Однако ничего не происходит, и ячейки не открываются, тогда я просто переставляю флажок. И вуаля!

Поле - сферическое в приведённом примере. Право=лево.
221 783302
>>83296
>>83299

У тебя на краях очень странно считается количество мин вокруг элемента. Есть места, где вместо 4 или 5 стоит 3 или 4.
222 783314
>>83302

> У тебя на краях очень странно считается количество мин вокруг элемента.


>>83299

> Поле - сферическое в приведённом примере. Право=лево.

223 783316
>>83314
На картинке предпростмотра ВЕБМ слева снизу 4, хотя с учётом замкнутости мин вокруг пять
1641211241722.mp4433 Кб, mp4,
1200x900, 0:14
224 783321
>>83316
Мы друг-друга не понимаем. Вот демонстрация сферической замкнутости, как это понимаю я.
225 783322
>>83321
>>83316
А, всё. Увидел. Там лишний флажок. А благодаря тому, что расчёт неправильных флажков не доделан - оно не взорвалось.
226 783323
>>83299

>Поле - сферическое в приведённом примере. Право=лево.


Может, цилиндрическое или тороидальное?
227 783324
>>83323
Пожалуй цилиндрическое точнее. Спасиб, точно!
228 783327
>>83323
>>83324

Но ведь это двухмерное пространство, для него неприменимо думать, что его размазали по тору, цилиндру или сфере.

Я прост думал на трёхмерную сферу натянуть это всё, но быстро понял, что идея так себе, наверное налезут только треугольные или шестиугольные кнопки максимум.
MugandTorusmorph.gif496 Кб, 240x240
229 783328
>>83327

>Но ведь это двухмерное пространство, для него неприменимо думать, что его размазали по тору, цилиндру или сфере.


Сразу видно, человек не знаком с топологией.

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


Гугли, как натягивают на сферу всякие тайлы и гексы. Это очень серьезная тема.
230 783330
>>83328
Как их натягивают я знаю и видел, просто пространство игры двухмерное, а замкнутость достигается МАГИЕЙ этого пространства.
231 783331
Доигрался я кароч, я всегда задачи на части мелкие дроблю, которые решают отдельные функции или классы. Сделал класс для решения одной такой задачи и на одном из его часто вызываемых методе он выдаёт переполнение стэка. Меня удивляет, что это происходит с классом, объект которого создаётся лишь однажды, а потом просто многократно используется. Моё понимание годо скрипта явно не соответствует действительности.
232 783332
>>83330

>просто пространство игры двухмерное, а замкнутость достигается МАГИЕЙ этого пространства.


Похуй, какое оно там. Топологически это тор или цилиндр.
233 783338
Как жаль, шо у годо маленький размер стека. Уж сейчас то смысла напрягать так всех нету, даже мобила понятен жирный размер стэка в 16 - 64 мб. Даже в новом шарпе почему-то сделали всего 4 МБ.
Некоторые задачи удобно решаются рекурсией, я требую прогибания под удобство программирования.
234 783346
>>83345 (Del)
Ахуеть, писал в гугле запрос, даже на англ нету ответа, а тут вона как.

Благодарю
235 783348
>>83346
Ан нет, поэкспериментировал, придётся с матами делать итерационный вариант. Как же раздражает, ПК это быстрый калькулятор, почему же мне приходится писать неудобный код.
236 783364
>>83270
Интересно. Комнаты потом будут меньше или плотнее заполнены? А то одинокий холодильник в огромной комнате выглядит как сцена из фильмов ужасов (холодильник всех сожрал).

>допиливаю движок


Движок - Godot, допиливают его на C++ на гитхабе. А ты, скорее всего, делаешь собственный фреймворк/модули/инструменты с помощью GDScript и доступных классов. В ином случае не вижу смысла ковыряться во внутренностях Godot ради 2Д бродилки.
237 783369
>>83364

>Комнаты потом будут меньше или плотнее заполнены?


Да, холодильник лишь для примера.

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


Так точно. Немного неверно назвал. Скорее фреймворк с набором сцен и контроллеров. К примеру - контроллер диалога, который я могу закинуть под любую ноду, указать нужный диалог и прокинуть сигналы. К слову таким образом этот холодильник и реализован
238 783371
>>83338

>Некоторые задачи удобно решаются рекурсией


Только при условии, что число вложений невелико. Это даже в школе на информатике говорят, что рекурсию нужно использовать очень аккуратно.

>>83348
Стек не увеличивается? Или тебе нужен слишком большой? Меня вопрос стека тоже волнует, но не из-за рекурсии, а из-за того, что я предпочитаю делить всё на мелкие функции - вложенность кода может оказаться довольно большой.

Интересно, под капотом интерпретатор гдскрипт умеет инлайнить простые функции? Типа такой:

>func is_empty(thing): return thing.size < 0


Или даже на такое тратится стек вызовов?
239 783377
>>83371

> Стек не увеличивается?



Увеличивается, можно поставить любое значение, на значении 16384 моя игра просто вылетела, так как в ОС видимо есть свой предел и он ниже. Нужен значительно больший размер стека кароч.

Второе не знаю.

По итогу, надо писать итерационный, императивный вариант.
240 783381
>>83321

>сферической замкнутости, как это понимаю я


У тебя цилиндрическая, но это уже сказали.

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

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

Думаю над тем, чтобы сделать замыкание карты в виде тора в своём 3D опенворлде, когда реализую достойную систему чанков. Просто мне не нравятся невидимые стены...
241 783387
>>83381
В далёких слезах давно решили столь сложную проблему - ОСТРОВ, а потом понеслась
1641237774125.png19 Кб, 759x487
242 783419
Вот как логически вычислить здесь?
243 783426
>>83419
левый верхний угол бомба.
244 783429
>>83419
Вычислить - никак. Один из способов исправить/облегчить такие ситуации - перемещать мины в зависимости от выбора игрока, чтобы игрок всегда побеждал. Что-то вроде суперпозиции, мина одновременно существует и не существует с точки зрения игрока, и задача игры сделать так, чтобы мина существовала не там, куда кликнет игрок, но при этом не изменяя окружающих цифр, чтобы не спалить это "читерство". Итог - игрок понадеялся на удачу и ему "повезло", он получил дозу гормонов удовольствия и доволен игрой, будет теперь охотнее донатить на лутбоксы...
1641238809264.png19 Кб, 767x489
245 783430
>>83426
Ниугодал
Кольцевая дорога.webm12,7 Мб, webm,
1152x720, 1:09
246 783433
>>83387

>ОСТРОВ


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

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

Как считаете, у меня есть шансы доделать этот прототип до более-менее интересной игры? Я имею в виду, интересной для широкой аудитории, самому мне уже сейчас норм, в GTA я точно так же круги по городу нарезал и это для меня было основным геймплеем, лол.
247 783445
>>83430
Что это за бомба с крестом?
248 783448
>>83433
Нет шансов. Я бы на твоём месте занялся чем то полезнее.
249 783473
>>83448

>Нет шансов


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

>чем то полезнее


Мне нечем заниматься. Альтернатива - лежать целыми днями на кровати и играть в гиперказуалки на телефоне, не имея сил даже встать и поесть хотя бы один раз в день.
250 783476
>>83433

>симуляции жизни сразу на множестве островов


не возникает. Зачем тебе симуляция жизни на островах, где нет игрока? Запускай эту симуляцию когда игрок туда попадет
251 783490
>>83476

>Зачем тебе симуляция жизни на островах, где нет игрока?


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

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

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

Ладно, это всё теория, нужно сначала хотя бы один город/остров симулировать, а там посмотрим, что получится.
1641282619393.png74 Кб, 975x578
252 783500
Хоспаде, как же охуенно!
Играю в своего читерского сапёра и не могу остановиться! Игра мечты, просто!

В процессе игры возникла идея сделать игровую механику из этого чита. Сделать, скажем, три супер-скана на одну партию. Суперскан, это когда неправильно выставленный флажок при скане не взрывается. Таким образом, вероятность нерешаемых ситуаций типа этой >>83430 компенсируется супер-сканом.
253 783502
>>83500
В FineSweeper тупо жизни добавили.
254 783503
>>83502
Я разновидностями сапёров ранее не интересовался. Вчера, когда гуглил подробные описания правил, обнаружил в гугле прямо в окне поиска веб-виждет с довольно красочным сапёром. Зелёная лужайка, цветочки, бабочки. И БАЦ!
255 783508
>>83429
Дану, лучше как в старых играх - хардкор, настоящая удача.

>>83500
Ты как кнопочку мену сделал? Я использовал menuButton
256 783509
И да, я получил невроз и охреневал всю ночь из-за попыток родить итерационный, императивный вариант открытия пустых кнопок. Настолько физически и ментально я не охуевал давно. Единственное, что пришло в голову это имитация распространения двухмерной волны в пространстве, переотращающейся от этой среды, рассеивающейся в ней.
chargen.gif587 Кб, 600x343
257 783511
>>83270
Написал генератор персонажей. Теперь буду прикручивать анимации
cover2.jpg95 Кб, 800x450
258 783516
>>83511
Нет, теперь ты будешь мутить NFT.
259 783517
>>83516
Я не могу. Эти ассеты не под моим авторством и лицензия мне не позволяет)
260 783518
>>83517
Поверь, в нашем деле это никакого значения не имеет.
https://twitter.com/NFTtheft/status/1471640212090470404
261 783519
>>83518
Хотелось бы быть честным с автором.
У тебя есть опыт в этом, анонче? У меня есть пара наработок которые выглядят получше
262 783523
>>83473
Займись чем то более мелким, что потянешь. Это ты не потянешь. Могу предложить тебе какой нибудь космосим или стратегию.
263 783524
>>83519
Мало ли что тебе там хочется. Если не своруешь и не запостишь на опенсеа - то сворую и запощу я. А если своруешь, то я все равно сворую и запощу.
1641295439945.png83 Кб, 802x593
264 783526
>>83508

> Ты как кнопочку мену сделал? Я использовал menuButton


Да её. Только там тааакооой головняк с построением вложенных меню, я в общем-то разобрался как делать, но пока не в кайф. И возможно есть поудобнее варианты. Потом поищу.
265 783528
>>83509

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


Ну делай на сигналах тогда, раз тебе не нравится рекурсия.
изображение.png40 Кб, 551x473
266 783531
>>83526
Я такой вариант нашёл в нете

>>83528
Тут проблема именно в том, что придумать решение без рекурсии для меня крайне сложным оказалось, любое из будет громоздким и трудно удерживаемым одномоментно в голове.
1641296011729.png21 Кб, 600x131
267 783532
>>83531
У меня на рекурсии ща. Но она не вывозит огромные поля 100х100 например, там и ФПС просаживаться начинает, а пикрелейтед переполняет стек вызовов. Выше о нём уже упомянули, что его в конфиге можно увеличить, но это игрушки дьявола, ежжи.
268 783534
>>83532
Вот поэтому у меня и начался невроз от перенапряжения, я не смог ничего родить интересного, разве что деверо или распространение волны моделировать
269 783535
>>83534
Спокойствие, бро. Нарисуй на бумаге блок-схему. Или в пейнте. Рисование схем помогает. По крайней мере мне.
270 783536
>>83511
Начал прикручивать анимации челикам. Никак не вразумлю как мне это сделать правильно и удобно.
Все кадры персонажа находятся на одном здоровом листе (пикрил 2)

Сейчас сделал так: В AnimationPlayer раскидал каждый кадр отдельно с нужными интервалами(Пик 2) Думаю, тут есть другой вариант. Как-то указать координаты первого и последнего кадра и интерполировать их с нужным фреймрейтом. Буду курит мануалы
271 783537
>>83536
Пришло время тебе познакомиться с AnimationStateMachine.
272 783538
>>83537
А куда ее тут? Любая анимация может перейти в любую.
273 783539
>>83538
Так тоже стейтмашину закодить можно. И она предоставит тебе удобный интерфейс для манипулирования переходами любых анимаций в любые из кода.
274 783540
>>83539
А зачем она мне? У меня вопрос был в том как удобнее всего внутри Одной анимации кадры раскидывать
275 783541
>>83540
По порядку и раскидывай. У тебя спрайт-лист, так что обязательно делай дискретный режим анимации, он там в виде точечек иконкой показан.
изображение.png7 Кб, 1282x90
276 783542
>>83541
Как ни странно, я уже решил задачку, используя линейный режим.

Указал только первый и последний кадр
277 783543
>>83541
В любом случае, спасибо анон, что уделил минутку
278 783545
>>83542
Могут быть потери кадров, ну смотри сам. Если что, держи в уме, что можно будет перейти на дискретный режим и все кадры поштучно выставить на таймлайн.
279 783549
>>83546 (Del)
Я планировал так сделать. В самой первой гифке так и есть. Сейчас пришлось отказаться из-за того, что теперь персонаж состоит из множества слоев. Каждый слой содержит регион и порезан на кадры. В общем синхронизировать это все было бы проблематично
280 783554
>>83545
Перепроверил. Кадры действительно теряются. Видимо придется использовать дискретный режим и ставить каждый кадр ручками
281 783557
>>83556 (Del)
Суть в том что эти листы спрайтов взаимозаменяемые. То есть я могу в коде указать нужный лист для прически, нужный для одежды, для глаз и так далее. Анимации для каждого итема одинаковые, поэтому при наложении можно будет манипулировать параметрами Frame/Frame coords синхронно. А AnimatedSprite не даст мне так просто поменять текстуру всего СпрайтЛиста, потому что не подгружает весь лист за раз, а создает текстуру для каждого кадра
282 783561
>>83560 (Del)
Так я могу менять текстуру каждому элементу, а ты нет
283 783564
>>83562 (Del)
Попробуй в коде поменять спрайт лист анимэйтед спрайту
284 783567
>>83565 (Del)
У Анимэйтед спрайта нет текстуры. Есть ресурс СпрайтФреймс, в котором каждый кадр каждой анимации - отдельная текстура
285 783569
>>83566 (Del)
А теперь посмотри как это делаю я - в одну строчку, используя обычный спрайт и плейер
image.png70x58
286 783625
Все делают сапера, а я буду делать змейку.
287 783628
Я не смог найти как код дробить по строкам без ругани. Как?

>>83625
Тоже тема. Думаю, что вызовом будет сделать змейку с крутым графоном, анимацией и всякого рода издёвками - типа отравленной еды или ломающегося забора, телепорта вне карты. Типа чел играет, ничего не предвещает беды, и тут хоба, и он проиграл.
288 783633
>>83631 (Del)
Кек, а я такой обратный символ ставил, потому что мельком видал в одном видосе, благодарю
289 783666
Чтож, произошло мною непредвиденное и мне удалось родить итерационную версию кода для попёра, теперь можно даже увеличить размеры поля хоть до 1024 на 1024

Жор памяти при карте 256 на 256 220+ МБ
290 783700
>>83666
Много жрет. Ты хранишь только бомбы?
291 783701
>>83523

>Займись чем то более мелким, что потянешь.


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

>Это ты не потянешь.


С чего именно такой вывод? Должна быть причина.

>космосим


Из годных 3D признаю только Space Engineers и несколько похожих на неё игр, из 2D только Space Impossible. Всё остальное из жанра космосимов меня обычно не привлекает или не может надолго затянуть, следовательно, и мотивации делать нет. А перечисленные игры делать, по-моему, даже сложнее моего текущего проекта.

>стратегию


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

Я не пытаюсь сделать клон или убийцу ГТА, она вообще в другом жанре. Даже симуляцию жителей пока всерьёз не рассматриваю. Сейчас главный вопрос в генерации интересного ландшафта/города, по которому можно бродить/ездить без просадки ФПС. Чисто "симулятор ходьбы" без сюжета. Потом можно будет думать дальше, что и как, нужно ли вообще и в каком виде...

И ещё я никуда не тороплюсь, лишь бы мотивация не заканчивалась и я не бросал проект в очередной раз на много месяцев. Иногда вот что-то не получается и сразу руки опускаются, не могу держать себя в руках и спокойно искать решение проблемы...
Система чанков.png172 Кб, 1024x600
292 783714
Я в каком-то из предыдущих тредов жаловался, что у меня чанковая система не даёт прироста скорости и queue_free() сажает фпс. Так вот... Сегодня наконец-то вернул чанковую систему на место. На маленькой карте всё нормально, но карта размером 10х10 км сажала фпс до 10, при том стабильно. Профайлер ничего не мог сказать, кроме того, что на один кадр тратится очень много миллисекунд. В конце концов меня осенило, что могло вызывать такую нагрузку - я выключил миникарту и получил 100-200 фпс на той же 10х10 км карте! И даже регулярное освобождение и пересоздание чанков в движении не вызывает таких тормозов, как перерисовка моей миникарты. Можно даже рандомно телепортироваться по карте и чанки будут успевать пересоздаваться, не создавая существенного лага.

Короче, вдруг кому поможет эта информация: несмотря на то, что _draw() вызывается один раз (повторный вызов через update()), все вызванные в нём функции рисования кэшируются и вызываются каждый кадр, вместо того, чтобы кэшировать изображение как текстуру. Если этих функций очень много (как у меня на карте большого мира), то перерисовка будет очень долгой. Если поместить такую ноду во Viewport, она будет перерисовываться каждый раз, когда обновляется вьюпорт. Собственно, решение: ставить отрисовку Viewport в режим ONCE, когда нужно обновить карту, а всё остальное время использовать полученную таким образом текстуру.

На скриншоте карта размером 4х4 км, карта 10х10км выглядит как губка или кусок сыра (нужно переделывать генератор), но производительность у них одинаковая. Ещё многое можно оптимизировать и многое нужно добавить, но производительность на данный момент радует. Кто там говорил, что в Godot 3.х нельзя сделать опенворлд? Всё можно, если постараться.
image.png6 Кб, 185x34
293 783715
>>83714
ЕБАТЬ ТРИ КУБА НА СЦЕНЕ ОТКУДА ТЫСЯЧА ДРОУКОЛЛОВ ПРЕСВЯТАЯ ГОДОТЯ
294 783718
>>83715
Могу предположить, что т.к. куллинга нет, рендерится вся карта, попавшая в камеру, даже далекие объекты, которые не видно.
И каждый кубик рисуется отдельным драв коллом, т.к. батчинга статики нет.
295 783719
>>83700
Несколько массивов
charactereditor.gif9,5 Мб, 1862x943
296 783729
>>83536

Замутил полноценный редактор персонажей с настройкой всех элементов. Также можно менять анимации. Самое приятное что я реализовал все так, что мне при добавлении какого-то нового элемента гардероба ВООБЩЕ не понадобится трогать код. Тупо закинуть png нужной шапкой в папку и готово.

Этот редактор больше для целей разработки. Так я смогу настроить своих npc и видеть как они будут выглядеть в игре. После этого просто закину обьект персонажа в сцену и в экспортных переменных укажу ему нужные айди элементов гардероба.
297 783742
>>83701
Никто не тянет чего то большого. Все успешные игры в ГД это одна-две механики и кучу полировки. Вроде мобилки костяк которой пишется за день, а дальше полируется. Шанс что ты шиз аутист который сделает дварфортресс около нулевой. Если это просто бродилки, то ты справишься.

>>83719
Тебе нужны только бомбы.
298 783764
>>83742

> Тебе нужны только бомбы



У меня тайлы лишь отображение, данные о цифрах в массиве хранятся.
299 783785
>>83764
Нужны только вектора где бомбы.
300 783787
>>83785
И производительность стремительно летит на дно.

Ты как области открываешь? Как определяешь цифру, что указывает наличие рядом мин? Налету?
301 783809
>>83715
На самом деле 2k - это уже неплохо. С чанками дроуколлы держатся на уровне 1500-5000, без чанков на карте того же размера их было бы несколько десятков, если не сотен тысяч (но я не дождусь создания всей карты, будет меньше 1 кадра в секунду), даже на карте намного меньших размеров (1х1 км) без чанков до 10 тысяч, с чанками вроде было 1500-2500 (зависит от леса).

>>83718

>далекие объекты, которые не видно


Чанки ограничивают зону видимости до радиуса около 150 метров (на практике больше/меньше), туман полностью отбеливает объекты на расстоянии 200 метров, так что на том скриншоте видно почти все дома (кубы), которые отображаются видеокартой, нет никаких "слишком далёких", такие были бы на 100% желтовато-белыми.

...в общем, я провёл некоторые тесты, результаты:
1. Деревья в области видимости до 5 тысяч draw call потребляют, это очевидно и я это уже давно знал, нужен мультимеш.
2. Вся область видимости без деревьев - 1 тысяча draw call, влияют домики, "тумбы" под тайлами и источник света.
3. Если скрыть почти всё вместе с источником света, оставив лишь тайлы травы (на скриншоте один тайл песка), то получается такая формула (посчитал вручную в удалённой сцене):
9 тайлов x 25 чанков x 2 (?) = 225 тайлов x 2 = 450 draw calls
+ 2 draw call на персонажа (машину скрыл).
Остаётся нерешённым вопрос, почему каждый тайл рендерится дважды? Переключение видимости тайла через удалённую сцену изменяет число вызовов ровно на 2. У меня там ещё невидимая тумба под каждым тайлом (костыль, потом сделаю генерацию полигонами), но она скрыта, и если её отображать/скрывать - тоже число вызовов меняется на 2. Хотя источника света нет и весь постпроцессинг я вроде как выключил, тут незачем повторно всю сцену рендерить.

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

>>83751 (Del)
Спасибо.

>>83742

>Шанс что ты шиз аутист который сделает дварфортресс около нулевой.


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

>Если это просто бродилки, то ты справишься.


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

И даже "симуляция жизни" в моём представлении не затрагивает оружие, оружие если и будет, то будет крайне редким предметом (особенно в плане боеприпасов, нечего таскать с собой 9999 ракет в одном кармане), т.е. ни о каких массовых боях уровня ГТА не может быть и речи - только исследование города и "общение" с жителями (чего мне всегда хотелось в ГТА - хотя бы минимальная интерактивность помимо бессмысленного убийства).

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

Вот что реально плохо - у меня за все эти годы не сформировалось чёткое видение проекта, с каждой попыткой всё меняется очень сильно. Пытался писать диздок, но там всё слишком абстрактно получилось. Каждый раз приходится напрягать извилины в стиле "так, эту фичу кое-как набросал, а что мне ещё хотелось сделать из того, что я могу сделать прямо сейчас?" - никакие планы и заметки не помогают, либо слишком абстрактно, либо нельзя сделать без какой-то фундаментальной системы, которую ещё придумать нужно. Это, как я понимаю, одна из основных причин медленной разработки многих инди-проектов, т.к. код и контент сделать не так уж и сложно, сложно придумать, что именно тебе нужно делать (в рамках реализуемого, нереализуемые идеи любой напридумывает). Видел много проектов, где какие-нибудь ассеты понаделали, а игры так и не получилось, хотя расставить ассеты по сцене - совсем уж механическая работа. Или получилось что-то банальное и скучное, т.к. скопипастили чужое, не осилив придумывать что-то своё...
301 783809
>>83715
На самом деле 2k - это уже неплохо. С чанками дроуколлы держатся на уровне 1500-5000, без чанков на карте того же размера их было бы несколько десятков, если не сотен тысяч (но я не дождусь создания всей карты, будет меньше 1 кадра в секунду), даже на карте намного меньших размеров (1х1 км) без чанков до 10 тысяч, с чанками вроде было 1500-2500 (зависит от леса).

>>83718

>далекие объекты, которые не видно


Чанки ограничивают зону видимости до радиуса около 150 метров (на практике больше/меньше), туман полностью отбеливает объекты на расстоянии 200 метров, так что на том скриншоте видно почти все дома (кубы), которые отображаются видеокартой, нет никаких "слишком далёких", такие были бы на 100% желтовато-белыми.

...в общем, я провёл некоторые тесты, результаты:
1. Деревья в области видимости до 5 тысяч draw call потребляют, это очевидно и я это уже давно знал, нужен мультимеш.
2. Вся область видимости без деревьев - 1 тысяча draw call, влияют домики, "тумбы" под тайлами и источник света.
3. Если скрыть почти всё вместе с источником света, оставив лишь тайлы травы (на скриншоте один тайл песка), то получается такая формула (посчитал вручную в удалённой сцене):
9 тайлов x 25 чанков x 2 (?) = 225 тайлов x 2 = 450 draw calls
+ 2 draw call на персонажа (машину скрыл).
Остаётся нерешённым вопрос, почему каждый тайл рендерится дважды? Переключение видимости тайла через удалённую сцену изменяет число вызовов ровно на 2. У меня там ещё невидимая тумба под каждым тайлом (костыль, потом сделаю генерацию полигонами), но она скрыта, и если её отображать/скрывать - тоже число вызовов меняется на 2. Хотя источника света нет и весь постпроцессинг я вроде как выключил, тут незачем повторно всю сцену рендерить.

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

>>83751 (Del)
Спасибо.

>>83742

>Шанс что ты шиз аутист который сделает дварфортресс около нулевой.


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

>Если это просто бродилки, то ты справишься.


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

И даже "симуляция жизни" в моём представлении не затрагивает оружие, оружие если и будет, то будет крайне редким предметом (особенно в плане боеприпасов, нечего таскать с собой 9999 ракет в одном кармане), т.е. ни о каких массовых боях уровня ГТА не может быть и речи - только исследование города и "общение" с жителями (чего мне всегда хотелось в ГТА - хотя бы минимальная интерактивность помимо бессмысленного убийства).

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

Вот что реально плохо - у меня за все эти годы не сформировалось чёткое видение проекта, с каждой попыткой всё меняется очень сильно. Пытался писать диздок, но там всё слишком абстрактно получилось. Каждый раз приходится напрягать извилины в стиле "так, эту фичу кое-как набросал, а что мне ещё хотелось сделать из того, что я могу сделать прямо сейчас?" - никакие планы и заметки не помогают, либо слишком абстрактно, либо нельзя сделать без какой-то фундаментальной системы, которую ещё придумать нужно. Это, как я понимаю, одна из основных причин медленной разработки многих инди-проектов, т.к. код и контент сделать не так уж и сложно, сложно придумать, что именно тебе нужно делать (в рамках реализуемого, нереализуемые идеи любой напридумывает). Видел много проектов, где какие-нибудь ассеты понаделали, а игры так и не получилось, хотя расставить ассеты по сцене - совсем уж механическая работа. Или получилось что-то банальное и скучное, т.к. скопипастили чужое, не осилив придумывать что-то своё...
деревья без текстур.png206 Кб, 1022x590
302 783880
>>83809

>пик1


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

Вот скриншот сцены, где те же 5000 дроуколлов, но при этом 250 фпс. Похоже, придётся все деревья делать в том же стиле, без прозрачных квадов-листьев? Обидно немного, но ладно. Мне нравилась идея деревьев с плоскими листьями, но их долго рисовать (лол, как вручную, так и программно)...
303 783898
>>83880
Антон, а может просто сделаешь гоначки с ловполе графином? С развилками там, ямами и грузовиком куном?
304 783909
>>83898
Анон, а может, ты просто ответишь ему на вопрос? Я вот тоже может быть в будущем планирую использовать текстуры с прозрачностью, хотелось бы надеяться, что годот меня в этом плане не наебет.
305 783922
>>83909
Прозрачность всегда жрала кучу ресурсов как проца в 3дмаксе и подобном, так и видяхи в игровых движках. Может видал орные скрины с соснолей, где вместо полупрозрачности битовая шахматная маска.
306 783935
>>83925 (Del)
Да я вообще не собирался использовать полупрозрачность. То бишь нужно в сторону альфа-масок смотреть и все дела?
307 783938
>>83935
Шахматная сеточка наше всё, идаче сосноль детонирует.
308 783940
>>83938
Ну меня интересует лоу-поли с пикселями и без всякого там шейдинга. Я так понимаю, нужно врубить Unshaded и отрубить Specular в первую очередь?
Внедорожник.webm5,6 Мб, webm,
720x420, 2:43
309 784096
>>83898

>может просто сделаешь гоначки с ловполе графином?


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

>с ямами


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

>>83907 (Del)

>проверить что у тебя текстура именно с прозрачностью, а не полу-прозрачная


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

>использовать билборды (плоские спрайты) после определенного расстояния


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

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


Да тут такая фигня... В общем, я пытался увеличить размер чанка, чтобы впоследствии можно было объединять объекты внутри этого чанка, но на практике быстрее всего работают мелкие чанки (48х48 метров). Будет ли эффективен мультимеш для, грубо говоря, 3-6 одинаковых деревьев? Я читал где-то, что польза от него начинается с десятков, если не сотен объектов.

Но про зависимость от расстояния и т.п. - это всё правильно, просто пока я не уверен, стоит ли этим заниматься прямо сейчас. Сперва нужно заменить "плитки" чем-то другим, надоело по голой плоскости кататься. Хотя от бордюров я в своё время отказался, потому что кинематикбоди принципиально не способен на них запрыгивать, если коллиженшейп в форме капсулы... Нужно попробовать коллиженшейп в форме луча, как где-то рекомендовали.
Внедорожник.webm5,6 Мб, webm,
720x420, 2:43
309 784096
>>83898

>может просто сделаешь гоначки с ловполе графином?


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

>с ямами


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

>>83907 (Del)

>проверить что у тебя текстура именно с прозрачностью, а не полу-прозрачная


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

>использовать билборды (плоские спрайты) после определенного расстояния


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

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


Да тут такая фигня... В общем, я пытался увеличить размер чанка, чтобы впоследствии можно было объединять объекты внутри этого чанка, но на практике быстрее всего работают мелкие чанки (48х48 метров). Будет ли эффективен мультимеш для, грубо говоря, 3-6 одинаковых деревьев? Я читал где-то, что польза от него начинается с десятков, если не сотен объектов.

Но про зависимость от расстояния и т.п. - это всё правильно, просто пока я не уверен, стоит ли этим заниматься прямо сейчас. Сперва нужно заменить "плитки" чем-то другим, надоело по голой плоскости кататься. Хотя от бордюров я в своё время отказался, потому что кинематикбоди принципиально не способен на них запрыгивать, если коллиженшейп в форме капсулы... Нужно попробовать коллиженшейп в форме луча, как где-то рекомендовали.
310 784133
На реддите такая большая драма вокруг "сексуализации" Годетты разгорелась, мол, бикини не попадает в code of conduct движка и ущемляет права малолетних девочек, которые могли заглянуть в официальный реддит движка и - о, боже! - увидеть Годетту в купальнике (даже не микро). Аргументы уровня "мы не на пляже" и "подумайте о тех, кто чувствительнее нас" прилагаются. Кто чувствителен к купальникам и может ими оскорбиться? Арабы? А меня они оскорбляют тем, во что наряжают своих женщин. Почему никто не думает о моих чувствах, когда публикует рисунки этих... людей или добавляет их в игру, тогда как о "неприемлемых" совершенно невинных купальниках заботятся все?

Но это всё мелочи.
Важны всего две вещи:
1. Где достать оригинал картинки?
2. Где искать больше артов с Годеттой?
Это очень важно для разработки игры на Godot.
В идеале, конечно, нужна сборка движка Godette Engine.

>>83153
Ты обещал пак Годетты, где он?
312 784138
>>84134
Спасибо, схоронил.

>1000Кб, 912x1375


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

Кстати, где найти оригинальную модель с пикрила? Ссылка из поисковика ведёт на турбосквид, но не на страницу модели, а общий список моделей...
313 784139
>>84133
Я слышал, что там изначально была с ней драма, что выбрали на конкурсе самый хуевый вариант маскота, чтобы ублажить транссексуалов. Или это тролли с /агдг/ напиздели?
314 784155
>>84139

>выбрали на конкурсе


Кого именно? Годетту? Годетту сделала жена Хуана к релизу 3.0, просто по фану. Оригинальный твит:
https://twitter.com/reduzio/status/958305883976536064
А безымянного (?) робота не знаю кто сделал, но их вроде несколько вариантов. Один на логотипе, другой(ие) в демках. Вряд ли робот мог "ублажить транссексуалов", он же бесполый и совсем на человека не похож, а трансгендеры поддерживают дискриминацию по полу.

>>84152 (Del)
Но логика как у ребёнка. Если уж движок нацелен на обучение детей, то и Годетта должна быть взрослой учительницей в униформе с указкой, а не школьницей. Это ведь она учит тебя разрабатывать игры, а не ты её учишь, если только ты не разработчик движка. Даже странно, что до сих пор не видно артов, где Годетта была бы милфой с садистским уклоном и в униформе, имя вроде подходит.
315 784158
>>83907 (Del)

>Тебе надо проверить не с Transparency, а с Alpha Scissor


Забавно, но галочку Transparent я вообще не трогал, и у меня уже был включён Alpha Scissor. Поиграв галочками я прихожу к выводу, что Alpha Scissor жрёт больше ресурсов чем Transparent, однако материал с Transparent не способен отбрасывать тень - с одной стороны, это снижает число дроуколлов (источник света не пытается рендерить всю эту листву), с другой вынуждает создавать скрытые полигоны только для отбрасывания тени (если нужна).

При этом текстуру я переработал, сделав все полупрозрачные пиксели непрозрачными и уменьшив размер. Судя по всему, Alpha Scissor одинаково грузит игру, независимо от количества полупрозрачных пикселей - даже ползунок ничего не меняет, что в 0.0 (все пиксели отображаются), что в 1.0 (текстура полностью скрыта), нагрузка одинаковая. Я не понял, как конвертировать Spatial Material в код шейдера (в каком-то туториале на Ютубе видел, что так можно сделать), но подозреваю, что там на каждый пиксель идёт проверка условия, а видеокарты не любят условные операторы.

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

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

>>83909

>планирую использовать текстуры с прозрачностью


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

>>83940

>интересует лоу-поли с пикселями


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

>без всякого там шейдинга


Да, Unshaded отключает тени, блики и т.д. Но вряд ли тебе нужно 3D совсем без шейдинга, возможно, ты хочешь пиксельный шейдинг? Можно сделать пиксельные нормалмапы, чтобы источники света делали на объектах эффект пиксельного освещения. Вообще, экспериментируй, там не так много параметров. Сложности начнутся, если захочешь чего-то особенного, тут нужно свой шейдер писать.
315 784158
>>83907 (Del)

>Тебе надо проверить не с Transparency, а с Alpha Scissor


Забавно, но галочку Transparent я вообще не трогал, и у меня уже был включён Alpha Scissor. Поиграв галочками я прихожу к выводу, что Alpha Scissor жрёт больше ресурсов чем Transparent, однако материал с Transparent не способен отбрасывать тень - с одной стороны, это снижает число дроуколлов (источник света не пытается рендерить всю эту листву), с другой вынуждает создавать скрытые полигоны только для отбрасывания тени (если нужна).

При этом текстуру я переработал, сделав все полупрозрачные пиксели непрозрачными и уменьшив размер. Судя по всему, Alpha Scissor одинаково грузит игру, независимо от количества полупрозрачных пикселей - даже ползунок ничего не меняет, что в 0.0 (все пиксели отображаются), что в 1.0 (текстура полностью скрыта), нагрузка одинаковая. Я не понял, как конвертировать Spatial Material в код шейдера (в каком-то туториале на Ютубе видел, что так можно сделать), но подозреваю, что там на каждый пиксель идёт проверка условия, а видеокарты не любят условные операторы.

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

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

>>83909

>планирую использовать текстуры с прозрачностью


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

>>83940

>интересует лоу-поли с пикселями


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

>без всякого там шейдинга


Да, Unshaded отключает тени, блики и т.д. Но вряд ли тебе нужно 3D совсем без шейдинга, возможно, ты хочешь пиксельный шейдинг? Можно сделать пиксельные нормалмапы, чтобы источники света делали на объектах эффект пиксельного освещения. Вообще, экспериментируй, там не так много параметров. Сложности начнутся, если захочешь чего-то особенного, тут нужно свой шейдер писать.
316 784162
>>84158

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


Воксели мне точно не нужны, ненавижу воксели.

>Но вряд ли тебе нужно 3D совсем без шейдинга, возможно, ты хочешь пиксельный шейдинг?


Я знаю, что мне нужно, ни шейдинг, ни нормалмапы мне не нужны.
317 784169
>>84133
Опять всякое говно людям жить не даёт. Ирония в том, что жирная баба типа не может травмировать психику ребёнка, мужик транс тоже, но вот обычно тян в купальнике да, кек.
318 784173
>>84158
Мне кажется, ты что-то неправильно делаешь. Над тобой вон уже в срачетреде смеются.
319 784177
>>84173

> Над тобой вон уже в срачетреде смеются.


Они надо всеми нами смеются.
320 784179
Хотелось бы узнать есть ли некий плугон, который бы мне помог найти место утечки памяти. Так же я знаю, что есть временная утечка и годо растущую память очищает через некоторое время.

>>84158
Антон, а как насчёт того чтобы вместо прозрачности бахнуть полигонами? Сделал один два мега листа угловатых, наклеил на деревяшку, да рисуешь.
321 784201
>>84179

>найти место утечки памяти


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

>Сделал один два мега листа угловатых, наклеил на деревяшку, да рисуешь.


Что-то такое хочу попробовать.

>>84180 (Del)

>надо включить depth prepass.


Спасибо, попробую.

>Это все в доках где то описано.


А я искал в интернете - единственным ответом было сделать копию объекта и как-то запретить отрисовку самого объекта, оставив только его тень (что-то со слоями отрисовки вроде). Это интересное решение, если сделать лоуполи тень сложному объекту, ведь лоуполи будет намного быстрее рендериться.
322 784203
>>84180 (Del)

>depth prepass


Точнее будет так:
Depth Draw Mode - Opaque Pre-Pass

Попробовал... Ой, всё, теперь получается, что Transparent от Alpha Scissor ничем не отличается с этой текстурой, в том числе по производительности. Ну и ладно, это всё не важно уже.
изображение.png27 Кб, 515x296
323 784207
>>84201

> У тебя прям память компа утекает



Это, растёт, потом сбрасывается до некоторого значения и снова растёт.

На картинке способ создания. Проблема в том, что если сделать на основе одномерного массива, то доступ к элементу может оказаться медленнее, так как надо будет вычислять позицию индекса. Попробую.
324 784212
>>84208 (Del)
Кстати да, а на каком из движков больше всего игор местные сделали?
godette.gif680 Кб, 597x557
325 784231
>>83729
Годетта, раз уж пошла такая пьянка
326 784287
Сап. Имею слабый компьютер (мало ОЗУ и видеокарте лет 10). Комп смогу обновить еще не скоро. В будущем хочу освоить 3д, но сейчас оставил выбор на 2д.

В качестве первого движка выбрал Godot так как сижу на линуксе и Unity по какой то причине у меня забагован в некоторых местах. Видимо порт пока хуевый.

Вопрос, как думаете, в будущем Godot обзаведется нормальным инструментарием для 3д графики? Судя по тому как развивается опер сорс (блендер, Крита и тд) перспективы большие.

Или когда уже освою разработку и куплю комп, там уже будет все равно чем пользоваться и ддя 3д смогу перейти на любой другой движок? Насколько вообще легко будет перейти и освоить второй?
327 784301
>>84300 (Del)
Там в 4.0 обещали именно этим заняться. Хотят Godot вывести на уровень с Unity и UE.

Понятно, что это не скоро произойдет, но посмотри на Бледер, он сейчас ничем не уступает другим редакторам, а в чем то даже лучше их. У Godot может случится та же история. У него уже есть плюсы, насколько я понял. Если разрабов на ютубе послушать, часто сравнивают юнити и годот, и некоторые даже переходят туда полностью, особенно те кто с 2д графикой работают.
328 784302
>>84301

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

Хотя и по godot, уверен, будет больше :)
329 784316
>>84207

>На картинке способ создания


У тебя лишние циклы, лишняя переменная и лишние затраты на увеличение массива через append(). Мой способ:

>array.resize(width)


>for x in width:


>_ array[x] = []; array[x].resize(height)


>_ for y in height: array[x][y] = 0


Пробовал сделать ещё короче, но не вышло.

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

>func f() -> void:


А в твоём случае будет

>func f() -> Array:


Это поможет при поиске ошибок в коде и теоретически может немного повысить производительность кода.

>Это, растёт, потом сбрасывается до некоторого значения и снова растёт.


Чем проверяешь? Если диспетчером задач Windows или аналогом на линуксе, то забей на это. ОС делает много разной фоновой работы с оперативной памятью, доступной приложению. Особенно если включены разные дополнительные функции для ускорения работы компьютера, на Windows они включены по умолчанию и много работают с оперативной памятью.

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

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


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

Также где-то читал про способы ускорения вычисления ячейки двумерного массива - что-то там про битовые сдвиги и т.п. Но вряд ли это имеет смысл на GDScript... Помни, что преждевременные оптимизации делать вредно)
329 784316
>>84207

>На картинке способ создания


У тебя лишние циклы, лишняя переменная и лишние затраты на увеличение массива через append(). Мой способ:

>array.resize(width)


>for x in width:


>_ array[x] = []; array[x].resize(height)


>_ for y in height: array[x][y] = 0


Пробовал сделать ещё короче, но не вышло.

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

>func f() -> void:


А в твоём случае будет

>func f() -> Array:


Это поможет при поиске ошибок в коде и теоретически может немного повысить производительность кода.

>Это, растёт, потом сбрасывается до некоторого значения и снова растёт.


Чем проверяешь? Если диспетчером задач Windows или аналогом на линуксе, то забей на это. ОС делает много разной фоновой работы с оперативной памятью, доступной приложению. Особенно если включены разные дополнительные функции для ускорения работы компьютера, на Windows они включены по умолчанию и много работают с оперативной памятью.

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

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


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

Также где-то читал про способы ускорения вычисления ячейки двумерного массива - что-то там про битовые сдвиги и т.п. Но вряд ли это имеет смысл на GDScript... Помни, что преждевременные оптимизации делать вредно)
330 784320
>>84287

>нормальным инструментарием для 3д


Что значит "нормальный инструментарий"?

>для 3д смогу перейти на любой другой движок? Насколько вообще легко будет перейти и освоить второй?


Зависит от того, на какой, и насколько хорошо освоишь первый. В целом, в геймдеве освоение инструмента занимает меньшую часть времени, главное - научиться делать сами игры. В программировании обычно первый ЯП даётся тяжело, а все остальные очень легко, если не менять парадигму, но в геймдеве, можно сказать, всего одна парадигма - императивная, остальные не прижились. Больше всего трудностей будет, если попытаешься перейти на ECS движок, т.к. там совершенно другое устройство сцены и объектов, чем в классических ООП движках. Но для абсолютного большинства игр ECS не нужно.

>>84301

>посмотри на Блендер


Попробуй https://upbge.org/ - это значительно улучшенный форк Blender Game Engine, который в прошлом был встроен в Blender. Я когда-то пробовал делать что-то на BGE, далеко не зашёл, но было просто и приятно, всё внутри одной программы и без юнитевых тормозов с глюками. Скриптовый ЯП - полноценный Python, на который похож GDScript. Физический движок, кажется, Bullet. Состояние проекта сейчас не знаю, но свежий билд 0.3 от 4 декабря, как раз через день после релиза Blender 3.0.

Но если смотреть по требованиям к ПК, то, мне кажется, редактор Godot существенно легче Blender, если у тебя простые сцены.

>>84302

>про юнити спросил, так как по нему куча классных материалов, можно практически что угодно сделать по урокам и примерам


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

Скажем, ты знаешь, что без специальной операции скорость движения персонажа по диагонали будет в sqrt(2) раз выше, чем по прямой или вбок? Т.е. во многих старых и любительских играх движение с зажатыми WA или WD быстрее просто W. Всё потому что единичные вектора суммируются и получается вектор sqrt(2). Это никак не касается игрового движка и легко исправляется на любом, но информацию об этом ты обнаружишь скорее всего в каком-нибудь туториале "делаем персонажа на юнити, часть 1: движение". Нужно ли говорить, что можно извлечь полезные знания из такого туториала, даже если вообще не планируешь использовать юнити?

А лучше вообще книги читать. Много их по геймдеву, хороших и разных. Нет, ничего не могу порекомендовать. Потому что сам ничего не читал, только скачивал или в закладки сохранял)))

ВНЕЗАПНО есть даже книги по Godot.
330 784320
>>84287

>нормальным инструментарием для 3д


Что значит "нормальный инструментарий"?

>для 3д смогу перейти на любой другой движок? Насколько вообще легко будет перейти и освоить второй?


Зависит от того, на какой, и насколько хорошо освоишь первый. В целом, в геймдеве освоение инструмента занимает меньшую часть времени, главное - научиться делать сами игры. В программировании обычно первый ЯП даётся тяжело, а все остальные очень легко, если не менять парадигму, но в геймдеве, можно сказать, всего одна парадигма - императивная, остальные не прижились. Больше всего трудностей будет, если попытаешься перейти на ECS движок, т.к. там совершенно другое устройство сцены и объектов, чем в классических ООП движках. Но для абсолютного большинства игр ECS не нужно.

>>84301

>посмотри на Блендер


Попробуй https://upbge.org/ - это значительно улучшенный форк Blender Game Engine, который в прошлом был встроен в Blender. Я когда-то пробовал делать что-то на BGE, далеко не зашёл, но было просто и приятно, всё внутри одной программы и без юнитевых тормозов с глюками. Скриптовый ЯП - полноценный Python, на который похож GDScript. Физический движок, кажется, Bullet. Состояние проекта сейчас не знаю, но свежий билд 0.3 от 4 декабря, как раз через день после релиза Blender 3.0.

Но если смотреть по требованиям к ПК, то, мне кажется, редактор Godot существенно легче Blender, если у тебя простые сцены.

>>84302

>про юнити спросил, так как по нему куча классных материалов, можно практически что угодно сделать по урокам и примерам


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

Скажем, ты знаешь, что без специальной операции скорость движения персонажа по диагонали будет в sqrt(2) раз выше, чем по прямой или вбок? Т.е. во многих старых и любительских играх движение с зажатыми WA или WD быстрее просто W. Всё потому что единичные вектора суммируются и получается вектор sqrt(2). Это никак не касается игрового движка и легко исправляется на любом, но информацию об этом ты обнаружишь скорее всего в каком-нибудь туториале "делаем персонажа на юнити, часть 1: движение". Нужно ли говорить, что можно извлечь полезные знания из такого туториала, даже если вообще не планируешь использовать юнити?

А лучше вообще книги читать. Много их по геймдеву, хороших и разных. Нет, ничего не могу порекомендовать. Потому что сам ничего не читал, только скачивал или в закладки сохранял)))

ВНЕЗАПНО есть даже книги по Godot.
331 784324
>>84132 (Del)

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


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

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


Звучит как костыль - генерировать текстуру, чтобы другой генератор сгенерировал из текстуры меш) У меня один такой "пиксель" будет размером с многоэтажный частный дом...

>>нужно ещё определять ориентацию треугольников.


>Что это значит?


Пикрил. Слева треугольники ориентированы неправильно, а справа правильно. Но слева фиксированные положения треугольников, а справа их нужно поворачивать по ситуации. Думаю, достаточно сравнивать 2-3 вершины между собой по высоте, но мне... как-то страшно к этому приступать. Осенью генерировал сетку из гексагональных призм, и это было больно( Кстати, представь на каждой паре треугольников по домику или группе деревьев - вот это и будет моя карта. Зато никаких дурацких колдобин на дорогах! Но если будет нужно, смогу сделать повышенную детализацию отдельных блоков (какие-нибудь локальные бугры в лесу или на пляже). Также планирую вертикальные стены между некоторыми блоками, типа скал/обрывов, это несложно, но как-нибудь потом.

>А вообще определяется в 3д однозначно порядком вершин (по часовой или против часовой).


Это я знаю, это просто. Сложнее всего оказалось настроить tangent space - я так и не понял, что это такое и как с ним работать, а без него нормалмапы не работают (но здесь они не понадобятся).

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


Знаю, я имел в виду... ой, я не помню, что я имел в виду. Короче, нужно настраивать уровни детализации чанков и переключать их, а чё там с билбордами это дело десятое...

>ГТА5 фары не рисуются 3д, это просто плоские спрайты (пикрил).


Это я знаю, много наблюдал за ночным городом в разных ГТА. Очень легко заметить вживую, что вместо машин спрайты огоньков. Незаметны они только если не обращать на них внимания) Меня больше интересует, как в той же ГТА делают освещение на улицах вблизи игрока, ведь больше 8 источников света OpenGL не поддерживает (вроде). Или в ГТА только имитация освещения? Я помню что фары в старых ГТА очень странно светили, как будто накладывали спрайт-маску на дорогу...

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


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

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

А ещё я убедился в который раз, что VehicleBody никуда не годится. Придётся свой велосипед делать, но так даже лучше, не люблю на всём готовом.
331 784324
>>84132 (Del)

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


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

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


Звучит как костыль - генерировать текстуру, чтобы другой генератор сгенерировал из текстуры меш) У меня один такой "пиксель" будет размером с многоэтажный частный дом...

>>нужно ещё определять ориентацию треугольников.


>Что это значит?


Пикрил. Слева треугольники ориентированы неправильно, а справа правильно. Но слева фиксированные положения треугольников, а справа их нужно поворачивать по ситуации. Думаю, достаточно сравнивать 2-3 вершины между собой по высоте, но мне... как-то страшно к этому приступать. Осенью генерировал сетку из гексагональных призм, и это было больно( Кстати, представь на каждой паре треугольников по домику или группе деревьев - вот это и будет моя карта. Зато никаких дурацких колдобин на дорогах! Но если будет нужно, смогу сделать повышенную детализацию отдельных блоков (какие-нибудь локальные бугры в лесу или на пляже). Также планирую вертикальные стены между некоторыми блоками, типа скал/обрывов, это несложно, но как-нибудь потом.

>А вообще определяется в 3д однозначно порядком вершин (по часовой или против часовой).


Это я знаю, это просто. Сложнее всего оказалось настроить tangent space - я так и не понял, что это такое и как с ним работать, а без него нормалмапы не работают (но здесь они не понадобятся).

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


Знаю, я имел в виду... ой, я не помню, что я имел в виду. Короче, нужно настраивать уровни детализации чанков и переключать их, а чё там с билбордами это дело десятое...

>ГТА5 фары не рисуются 3д, это просто плоские спрайты (пикрил).


Это я знаю, много наблюдал за ночным городом в разных ГТА. Очень легко заметить вживую, что вместо машин спрайты огоньков. Незаметны они только если не обращать на них внимания) Меня больше интересует, как в той же ГТА делают освещение на улицах вблизи игрока, ведь больше 8 источников света OpenGL не поддерживает (вроде). Или в ГТА только имитация освещения? Я помню что фары в старых ГТА очень странно светили, как будто накладывали спрайт-маску на дорогу...

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


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

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

А ещё я убедился в который раз, что VehicleBody никуда не годится. Придётся свой велосипед делать, но так даже лучше, не люблю на всём готовом.
332 784327
>>84287

> Вопрос, как думаете, в будущем Godot обзаведется нормальным инструментарием для 3д графики?


Нормальный инструментарий для 3д-графики - это Блендер. И в шапке уже указаны два плагина для упрощения взаимодействия с годотом.

> сижу на линуксе и Unity по какой то причине у меня забагован в некоторых местах


Я пробовал на убунте через appimage вроде всё работало.
333 784328
>>84320

> ВНЕЗАПНО есть даже книги по Godot.


Кстати, надо будет в шапку добавить.

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


Кстати, я джва года назад таким образом реимплементировал оси движения в годот ( x = Input.get_action_strength("ui_right") - Input.get_action_strength("ui_left") ) запостил пару раз в комментах ютуба и к своему удовольствию обнаружил, что все новые туториалы стали на осях.
334 784332
>>84233 (Del)
Всегда считал что это блик
335 784429
>>84328

>ui_right


>ui_left


Кстати, почему так часто юзают стандартные действия "ui_"? Это же горячие клавиши интерфейса (user interface), глупо управлять персонажем через них. Я всегда первым делом создаю собственную раскладку с именами вроде move_forward и move_backward отдельно от ui, даже если они пересекаются/дублируют друг друга. Код с неуместным использованием ui-действий считаю быдлокодом и хотел бы, чтобы в туториалах в первую очередь объясняли добавление новых действий, с правильным названием, чётко описывающим назначение конкретного действия.

Смысл действий (action) в том, чтобы разделить разные по смыслу элементы управления. Да, не каждой игре это нужно, но если ты делаешь меню настройки раскладки, игроку будет очень неприятно обнаружить, что смена клавиш движения портит навигацию по меню, которую он трогать не хотел. Аналогично с любыми действиями в игре, которые игрок теоретически может захотеть переназначить на клавишу, отдельную от "универсальной"/контекстной. Я считаю обучение этому таким же важным, как прикол с sqrt(2).

При этом в Годо, в отличие от Юнити, не нужно совокупляться с десятком разных непонятных интерфейсов и загружаемых ассетов, чтобы создать свои действия. Просто зашёл в настройки проекта и сделал как надо, ничего не скачивая и не компилируя... Нет, нужно юзать стандартные хоткеи не по назначению.
336 784447
>>84437 (Del)
Сделай сам один раз и потом во всех своих проектах используй, меняя только внешний вид GUI. В этом главная прелесть программирования - можно неограниченно использовать то, что было создано всего один раз.

Я пока этой темы не касался, но не думаю, что это сложно, достаточно один универсальный скрипт "нажмите кнопку" написать и дальше дело только за оформлением GUI с кучей пунктов на каждое действие, которое ты разрешаешь игроку изменять.
337 784476
>>84429

> почему так часто юзают стандартные действия "ui_"?


Я не юзаю. А в посте написал дефолт для примера.
338 784477
>>84437 (Del)

> Вот бы еще был ассет для переназначения кнопок игроком


Го вместе напишем ИТТ?
339 784695
>>84207

>Попробую.


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

Интересная особенность рендеринга: если UV координаты будут точно на границе двух цветов, между пикселей (пример с палитрой 4х4: 0.25, 0.25), тогда поверхность будет покрываться полосками двух цветов, как бы рябить разноцветными волнами. Вдруг кто-то такой же артефакт словит и будет голову ломать.
341 784798
>>84795 (Del)
Я прекрасно знаю про сглаживающий фильтр и про пиксельные текстуры. Выключил эту галочку сразу после импорта.

Проблема не в фильтре. С фильтром, я думаю, результат был бы намного лучше: цвета бы смешались, но был бы один однородный цвет. А у меня получилась именно рябь, то есть огромное количество тонких чётких полосок, сменяющих друг друга по всей поверхности. Что-то отдалённо похожее на z-fighting, но на текстурах.

Думаю, проблема в ошибках с округлением чисел с плавающей точкой. Число типа 0.25 округляется то в 16-й пиксель, то в 17-й, из-за этого два разных цвета сменяют друг друга. Ещё все вершины одного треугольника я размещаю в одну UV-координату, т.е. между вершинами на текстуре нет ни одного пикселя.

Решается проблема, повторюсь, смещением вершин в правильный пиксель или группу пикселей одного цвета. Я сместил на 0.125, 0.375, 0.625 и 0.875 - и всё заработало как предполагалось.
342 785140
Годотеры, существуют ли аддоны на плюсах которые вводят int32, int16, vec2i и массивы для них в 3 годот?
343 785142
>>85140
Я не слышал. Могу предложить, если ты знаешь плюсы, написать свои модули по аналогии с имеющимися и скомпилировать свой собственный билд.
344 785144
>>85142
Либо, что ещё лучше, сделать на плюсах ту логику, для которой тебе нужны int32, int16, vec2i и массивы для них, а в годот прокинуть интерфейс с результатом. И скомпилировать свой билд.
345 785167
Начинаю разработку 2D RPG с видом сбоку. Есть ли профиты потратить время на изучение вашей аниме девочки, а не начинать на родном юнити?
1642010236194.webm494 Кб, webm,
640x360, 0:08
346 785184
>>85167
Глупо скакать по движкам. Выбрал юнити - так делай на нём. Особой разницы нет.
347 785190
>>85150 (Del)
Мне бы конечно плагин, а не пердолится каждый раз, когда выходит новая версия с фиксами.
348 785226
Я тут подумал, у меня в генераторе карт уже частично использовались конечные автоматы (но не очень правильная реализация), но стартовые области заливались окружностями, из-за чего на большой площади эти окружности сильно бросались в глаза. Почему бы не сделать чисто на конечных автоматах? Правда, поискав в интернете, я обнаружил, что чаще всего изначальное состояние - белый шум, а мне хотелось бы что-то более сгруппированное, типа архипелага... Кстати, симуляции различных ирл сил, изменяющих форму ландшафта планеты, в общем смысле тоже являются конечными автоматами... так на реддите кто-то писал.

>>85184
Годетта бы не сказала такого никому, кто ей заинтересовался. Она добрая и открытая для всех, и не будет прогонять только потому, что человек пришёл от Юнити-чан и сомневается в выборе. Да, это мой хэдканон. Алсо жду аниме Годетта vs Юнити-чан. А в конце все персонажи будут пить чай с тортиками.

>>85167

>2D RPG с видом сбоку


Как в платформерах? Или ты имеешь в виду вид "сверху-сбоку", как в большинстве игр на RPG Maker?

>Есть ли профиты потратить время на изучение


Думаю, да.
- Редактор Годо нетребователен, не лагает и почти не глючит, запуск и перезапуск быстрый (не считая реимпорта очень больших ресурсов, но это редко нужно). Это особенно важно, если у тебя не очень сильный компьютер и ты всё равно делаешь 2D игру.
- GDScript и VisualScript в силу своей скриптовости никогда не заставляют ждать компиляцию кода, в отличие от Юнити, которая на любое изменение кода делает перекомпиляцию. На счёт C# не знаю, не пробовал. GDNative, разумеется, нужно компилировать, но тебе оно вряд ли понадобится, хватит GDScript.
- Сцена запускается в отдельном окне, если экран широкий или у тебя два экрана, можно поместить второе окно сбоку от основного. Некоторые считают это недостатком Годо, но для меня это преимущество, т.к. это окно будет выглядеть именно так, как будет выглядеть игра в релизе, а не как скукоженное в окне Юнити.
- GDScript пишется во встроенном редакторе. Можно использовать и внешний, но не нужно: встроенного полностью хватает. Много настроек, достаточно функций. Главное - что не нужно альт-табаться между редактором игры и редактором кода, всё выглядит в одном стиле и не вынуждает мозг переключаться между интерфейсами.
- Для экспорта можно скомпилировать из исходников свой собственный вариант шаблона экспорта. Можно отключить всё, что тебе не нужно: 3Д рендер, 3Д физику, сеть и т.д. Это снизит размер исполняемого файла, что полезно для мобилок и веба.
- Можно самостоятельно написать C++ модуль для движка и скомпилировать редактор вместе с ним. Т.е. ты максимально близок к ядру движка, в отличие от Юнити, на которой ты можешь только C# скрипты писать и никак не контролируешь ядро. Вообще, весь код на гитхабе и это радует, даже если ты никогда ничего там не будешь редактировать и компилировать.
- Также все или большинство обсуждений разработчиков движка идут на гитхабе. Можно почитать обо всех грядущих изменениях и планах заранее, можно поучаствовать в обсуждении, предложить новые фичи или пожаловаться на баги и получить отклик от самих разработчиков, а не каких-то наёмных посредников. По сути разработка прозрачна, никто не пытается скрыть от тебя какие-то будущие изменения. Да, это всему опенсорсу свойственно, но в разной степени. С Юнити же ты можешь только надеяться, что разрабы не учудят в следующей версии что-то совсем уж неадекватное и наконец-то пофиксят многолетние баги (знаю я про багтрекер юнити, там дохрена страниц и вряд ли у реальных разрабов есть время всё это изучать, что им менеджер проекта приказал делать - то и делают).
- Мне кажется, у Годо более приятное коммьюнити (в целом по миру). Будто на Годо перешли многие адекваты, а токсики остались таскать ассеты с ассетстора. Даже если тебе не помогут, то хотя бы попытаются, а не пошлют гуглить ассеты и туториалы со словами "всё придумано до тебя, ищи". Конечно, это из-за малоизвестности движка, с популярностью придут и легионы токсиков, срущих везде, где только могут, но пока что всё относительно спокойно.
- Документация движка достаточно полная и справка встроена прямо в движок, жмёшь F1 и в большинстве случаев быстро находишь интересующую тебя информацию (оффлайн). В целом дизайн онлайн документации получше, чем у Юнити, но это вкусовщина. В редакторе оффлайн справка открывается прямо в редакторе кода, удобно переключаться в процессе кодинга. Есть кое-какие пробелы, но только в тех местах, которые в целом крайне редко могут потребоваться - все основные инструменты документированы хорошо, разберёшься без туториалов.
- В целом Годо похож на Юнити, не считая некоторых нюансов (скажем, одна нода = один скрипт, вместо добавления компонентов в пустышку - добавление нод в дерево сцены). Т.е. перенести проект с одного движка на другой не должно составить большого труда, базовые концепции одинаковые. Для меня главное отличие Годо в удобстве и простоте использования, это важнее других отличий, особенно в рамках простой 2D игры.

>родном юнити


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

При всём при этом Годо не какой-то там конструктор для детей, на нём можно делать серьёзные проекты (просто пользуются в основном дети и нищие инди). Т.е. у Годо простота без жертвы возможностями, с минимальными жертвами по производительности билда. Согласись, все бы давно делали игры только на конструкторах игр, если бы они не сокращали возможности до очень ограниченного набора, ведь любой предпочтёт работать в большем комфорте.
348 785226
Я тут подумал, у меня в генераторе карт уже частично использовались конечные автоматы (но не очень правильная реализация), но стартовые области заливались окружностями, из-за чего на большой площади эти окружности сильно бросались в глаза. Почему бы не сделать чисто на конечных автоматах? Правда, поискав в интернете, я обнаружил, что чаще всего изначальное состояние - белый шум, а мне хотелось бы что-то более сгруппированное, типа архипелага... Кстати, симуляции различных ирл сил, изменяющих форму ландшафта планеты, в общем смысле тоже являются конечными автоматами... так на реддите кто-то писал.

>>85184
Годетта бы не сказала такого никому, кто ей заинтересовался. Она добрая и открытая для всех, и не будет прогонять только потому, что человек пришёл от Юнити-чан и сомневается в выборе. Да, это мой хэдканон. Алсо жду аниме Годетта vs Юнити-чан. А в конце все персонажи будут пить чай с тортиками.

>>85167

>2D RPG с видом сбоку


Как в платформерах? Или ты имеешь в виду вид "сверху-сбоку", как в большинстве игр на RPG Maker?

>Есть ли профиты потратить время на изучение


Думаю, да.
- Редактор Годо нетребователен, не лагает и почти не глючит, запуск и перезапуск быстрый (не считая реимпорта очень больших ресурсов, но это редко нужно). Это особенно важно, если у тебя не очень сильный компьютер и ты всё равно делаешь 2D игру.
- GDScript и VisualScript в силу своей скриптовости никогда не заставляют ждать компиляцию кода, в отличие от Юнити, которая на любое изменение кода делает перекомпиляцию. На счёт C# не знаю, не пробовал. GDNative, разумеется, нужно компилировать, но тебе оно вряд ли понадобится, хватит GDScript.
- Сцена запускается в отдельном окне, если экран широкий или у тебя два экрана, можно поместить второе окно сбоку от основного. Некоторые считают это недостатком Годо, но для меня это преимущество, т.к. это окно будет выглядеть именно так, как будет выглядеть игра в релизе, а не как скукоженное в окне Юнити.
- GDScript пишется во встроенном редакторе. Можно использовать и внешний, но не нужно: встроенного полностью хватает. Много настроек, достаточно функций. Главное - что не нужно альт-табаться между редактором игры и редактором кода, всё выглядит в одном стиле и не вынуждает мозг переключаться между интерфейсами.
- Для экспорта можно скомпилировать из исходников свой собственный вариант шаблона экспорта. Можно отключить всё, что тебе не нужно: 3Д рендер, 3Д физику, сеть и т.д. Это снизит размер исполняемого файла, что полезно для мобилок и веба.
- Можно самостоятельно написать C++ модуль для движка и скомпилировать редактор вместе с ним. Т.е. ты максимально близок к ядру движка, в отличие от Юнити, на которой ты можешь только C# скрипты писать и никак не контролируешь ядро. Вообще, весь код на гитхабе и это радует, даже если ты никогда ничего там не будешь редактировать и компилировать.
- Также все или большинство обсуждений разработчиков движка идут на гитхабе. Можно почитать обо всех грядущих изменениях и планах заранее, можно поучаствовать в обсуждении, предложить новые фичи или пожаловаться на баги и получить отклик от самих разработчиков, а не каких-то наёмных посредников. По сути разработка прозрачна, никто не пытается скрыть от тебя какие-то будущие изменения. Да, это всему опенсорсу свойственно, но в разной степени. С Юнити же ты можешь только надеяться, что разрабы не учудят в следующей версии что-то совсем уж неадекватное и наконец-то пофиксят многолетние баги (знаю я про багтрекер юнити, там дохрена страниц и вряд ли у реальных разрабов есть время всё это изучать, что им менеджер проекта приказал делать - то и делают).
- Мне кажется, у Годо более приятное коммьюнити (в целом по миру). Будто на Годо перешли многие адекваты, а токсики остались таскать ассеты с ассетстора. Даже если тебе не помогут, то хотя бы попытаются, а не пошлют гуглить ассеты и туториалы со словами "всё придумано до тебя, ищи". Конечно, это из-за малоизвестности движка, с популярностью придут и легионы токсиков, срущих везде, где только могут, но пока что всё относительно спокойно.
- Документация движка достаточно полная и справка встроена прямо в движок, жмёшь F1 и в большинстве случаев быстро находишь интересующую тебя информацию (оффлайн). В целом дизайн онлайн документации получше, чем у Юнити, но это вкусовщина. В редакторе оффлайн справка открывается прямо в редакторе кода, удобно переключаться в процессе кодинга. Есть кое-какие пробелы, но только в тех местах, которые в целом крайне редко могут потребоваться - все основные инструменты документированы хорошо, разберёшься без туториалов.
- В целом Годо похож на Юнити, не считая некоторых нюансов (скажем, одна нода = один скрипт, вместо добавления компонентов в пустышку - добавление нод в дерево сцены). Т.е. перенести проект с одного движка на другой не должно составить большого труда, базовые концепции одинаковые. Для меня главное отличие Годо в удобстве и простоте использования, это важнее других отличий, особенно в рамках простой 2D игры.

>родном юнити


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

При всём при этом Годо не какой-то там конструктор для детей, на нём можно делать серьёзные проекты (просто пользуются в основном дети и нищие инди). Т.е. у Годо простота без жертвы возможностями, с минимальными жертвами по производительности билда. Согласись, все бы давно делали игры только на конструкторах игр, если бы они не сокращали возможности до очень ограниченного набора, ведь любой предпочтёт работать в большем комфорте.
349 785248
>>85226

>Как в платформерах


this

> Думаю, да.


Звучит всё великолепно и я почти влюбился, но

>GDScript


звучит грустно. На c# писать - это плохая идея?
350 785250
>>85248

>>GDScript


>звучит грустно


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

>На c# писать - это плохая идея?


Да нет, вроде бы нормально. Сам я C# в Годо не пробовал, но что читал про него на реддите и гитхабе:
- по производительности между GDScript и модулями C++;
- нужно писать бойлерплейт код, которого нет на GDScript;
- редактор кода только отдельный от Godot (VS и т.п.);
- изначально поддержку C# запилили только в 3.х ветке, а примерно к версии 4.1 планируют переписать всё с нуля. Сейчас Godot запускает приложение C#, что требует постоянной поддержки разных версий и платформ со стороны разработчиков движка, и они хотят сделать всё наоборот, чтобы C# приложение обращалось к библиотеке Godot, но для этого они ждут релиза .NET 6, потому что .NET 5 не поддерживает мобильные платформы... Короче, Godot 4.0 будет со старой версией C# (была мысль вообще его убрать, но решили оставить), а уже к 4.1 обещают всё переделать. Главная проблема тут для тех, кто делает игру на Android с кастомным apk, т.к. вместо Java придётся делать приложение на C#/Xamarin. Всех остальных вроде это всё не должно коснуться.

Да, ещё многие (и я) рекомендуют всё же попробовать GDScript. Многие вещи решаются на GDScript ничуть не хуже и даже быстрее, потому что не нужно туда-сюда мотаться и писать лишний код. Реальная польза от C# только в большей производительности и, наверное, доступе к стандартным фичам/библиотекам C#... Но для многих игр, особенно 2D, хватит и GDScript.

А так, можно любой ЯП подключить через GDNative или модули движка. Но это всё лишняя головная боль, а на GDScript кодить - просто запустил Godot, открыл вкладку редактора кода и пишешь, сразу всё подсвечивается и автодополняется, сплошное удовольствие. В Godot 4.0 будет ещё куча нововведений в виде GDScript 2.0...

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

Извини за поток сознания)
350 785250
>>85248

>>GDScript


>звучит грустно


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

>На c# писать - это плохая идея?


Да нет, вроде бы нормально. Сам я C# в Годо не пробовал, но что читал про него на реддите и гитхабе:
- по производительности между GDScript и модулями C++;
- нужно писать бойлерплейт код, которого нет на GDScript;
- редактор кода только отдельный от Godot (VS и т.п.);
- изначально поддержку C# запилили только в 3.х ветке, а примерно к версии 4.1 планируют переписать всё с нуля. Сейчас Godot запускает приложение C#, что требует постоянной поддержки разных версий и платформ со стороны разработчиков движка, и они хотят сделать всё наоборот, чтобы C# приложение обращалось к библиотеке Godot, но для этого они ждут релиза .NET 6, потому что .NET 5 не поддерживает мобильные платформы... Короче, Godot 4.0 будет со старой версией C# (была мысль вообще его убрать, но решили оставить), а уже к 4.1 обещают всё переделать. Главная проблема тут для тех, кто делает игру на Android с кастомным apk, т.к. вместо Java придётся делать приложение на C#/Xamarin. Всех остальных вроде это всё не должно коснуться.

Да, ещё многие (и я) рекомендуют всё же попробовать GDScript. Многие вещи решаются на GDScript ничуть не хуже и даже быстрее, потому что не нужно туда-сюда мотаться и писать лишний код. Реальная польза от C# только в большей производительности и, наверное, доступе к стандартным фичам/библиотекам C#... Но для многих игр, особенно 2D, хватит и GDScript.

А так, можно любой ЯП подключить через GDNative или модули движка. Но это всё лишняя головная боль, а на GDScript кодить - просто запустил Godot, открыл вкладку редактора кода и пишешь, сразу всё подсвечивается и автодополняется, сплошное удовольствие. В Godot 4.0 будет ещё куча нововведений в виде GDScript 2.0...

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

Извини за поток сознания)
351 785286
>>85226

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


Но это не Годетта, а Гоблин. Дим Юрич.
352 785320
>>85250

> можно любой ЯП подключить через GDNative или модули движка


Но для этого нужно быть сишником уровня Хуана. Я так-то поначалу хотел FPC подключить, но оказалось, что надо низкоуровневую API-обвязку на сях переводить в FPC, я до такого уровня увы не дошёл. С тех пор FPC-проекты появились, но быстро сдулись. А жаль.
353 785356
Как нарисовать текстурированную курву (Curve) в годоте?
354 785366
>>85356
Плагин есть. Гуглить впадлу. Но базарю, есть плагин. В прошлом треде видел ссылку.
355 785375
Посоветуйте, как избавиться от квадратности?
Текстуры рисовать не очень хочу - их сложно стилизовать, сложно избавиться от "тайловости".
Шейдеры, наверное, сильно повысят нагрузку, а мне бы хотелось ещё и на мобилки билд сделать.
Если повышать число треугольников, то это требует больше памяти и времени, а в результате всё равно квадратики.
Остаётся разве что маскировать границы тайлов под какими-либо объёмными декорациями...

Проблема возникла после того, как я решил попробовать отказаться от 2D сетки тайлов дорог. Т.е. допустим, я могу сгенерировать какой-то ландшафт (пик1) и сделать на нём ровные площадки под дома и дороги (пик2), но всё снова получается квадратным. Даже если размещать процедурные модели дорог и домов под произвольными углами к ландшафту, будут проблемы из-за того, что линии дорог будут пересекать квадратные тайлы...

Ну, наверное, единственный выход - уменьшать треугольники, но это сильно усложняет их генерацию. Попробую фрактальные алгоритмы, типа от больших квадратов к маленьким квадратикам (ещё хочу попробовать квадродерево)...
356 785378
>>85375

> как избавиться от квадратности?


А что если полюбить квадратность, принять её и не мешать ей создавать игре стиль?
357 785391
>>85378

>А что если полюбить квадратность


Да люблю я игры типа Майнкрафта и Террарии - покупал многое и много играл. Но там квадратность обоснована возможностью изменять ландшафт. Бесчисленные "воксельные" игры, не имеющие ничего общего с майнкрафтом кроме "воксельного стиля", вызывают отвращение, ведь они подражают внешности, не затрагивая саму суть квадратности (возможность свободно редактировать ландшафт). У меня не кубопесочница, следовательно я не должен делать всё квадратным.

>создавать игре стиль


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

>>85379 (Del)

>нормалями


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

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

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

>А что если полюбить квадратность


Да люблю я игры типа Майнкрафта и Террарии - покупал многое и много играл. Но там квадратность обоснована возможностью изменять ландшафт. Бесчисленные "воксельные" игры, не имеющие ничего общего с майнкрафтом кроме "воксельного стиля", вызывают отвращение, ведь они подражают внешности, не затрагивая саму суть квадратности (возможность свободно редактировать ландшафт). У меня не кубопесочница, следовательно я не должен делать всё квадратным.

>создавать игре стиль


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

>>85379 (Del)

>нормалями


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

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

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

>это не Годетта, а Гоблин


Ты прилепил глаза и волосы Годетты на Гоблина, что должно подразумевать, будто это Годетта говорит слова Гоблина, не?

>>85320

>низкоуровневую API-обвязку на сях переводить в FPC


Так-то Pascal и C чуть ли не родственники. Есть некоторые нюансы работы с памятью, но компиляторы Паскаля имеют специальные ключевые слова для переключения соответствующего режима, если тебе нужно линковаться с библиотекой или программой на C/C++. В остальном должно быть не сложно, все типы кроме строк одинаковые, а для Си-подобных строк есть отдельный тип (PChar, PWideChar и другие). Я как-то транслировал код на C/C++ из туториалов на FreePascal, и это было несложно как по мне.

Также планировал подключить FPC к Godot, но попробовав GDScript так и не нашёл мотивации это делать. Для чего нужно именно Паскаль подключать? Только чтобы писать на Паскале? Дело даже не в Паскале, я не понимаю самой концепции GDNative, в чём смысл сторонних языков? Видел недавно реализацию JavaScript на Godot, с поддержкой TypeScript - лол, зачем? Тут и так есть скриптовый ЯП из коробки, зачем возиться с подключением другого. Или вот кто-то пытается Lua подключить - тоже скриптовый ЯП, а зачем? Если только для подключения каких-то сторонних библиотек на подключаемом языке... А так, без библиотек, было бы интереснее всего Forth замутить, чтоб прямо внутри игры можно было кодить скрипты, не перезапуская игру - Форт запросто позволяет так делать.

Щас почитаю, что нужно для GDNative и попробую сделать на FPC, если разберусь, как. Только если это не связано с перкомпиляцией всего Godot... Серьёзно, почему нельзя было сделать универсальный загрузчик? Я пробовал делать такой механизм на FPC, мог подключать любое количество DLL динамически, без перекомпиляции, если у них (DLL) есть необходимые моей программе интерфейсы...
1353310948778.jpg5 Кб, 175x128
359 785400
Суп, gd, я делал HUD и обосрался. Дай, пожалуйста, гайд по тому, как правильно расставлять ЕБУЧИЕ КОНТЕЙНЕРЫ внутри ЕБУЧИХ КОНТЕЙНЕРОВ, чтобы они стояли на своём месте.
Ещё у меня один из элементов HUDа состоит из тупо спрайтов, которым нужно двигаться. Я вообще смогу заставить TextureRect нормально двигаться из кода, или нунахуй? Вроде всё работает, просто НА СВОИ МЕСТА, БЛДЖАД, НЕ СТАНОВИТСЯ.
containerexample.gif176 Кб, 424x232
360 785413
>>85400

>КОНТЕЙНЕРЫ


https://docs.godotengine.org/en/stable/tutorials/gui/gui_containers.html
Первая ссылка в Гугле по "godot container".

>смогу заставить TextureRect нормально двигаться из кода,


Да, я пробовал крутить свою миникарту кодом, всё норм.

>чтобы они стояли на своём месте


Ты бы лучше скриншотами показал, что у тебя не так...

Если кратко,

>как правильно расставлять


- никак:

>When a Container-derived node is used, all children Control nodes give up their own positioning ability. This means the Container will control their positioning and any attempt to manually alter these nodes will be either ignored or invalidated the next time their parent is resized.


>Likewise, when a Container derived node is resized, all its children will be re-positioned according to it, with a behavior based on the type of container used: (пикрил)



Т.е. всё, что от тебя требуется - выбрать правильный тип контейнера, сложить в него ноды и задать размер контейнера. Всё остальное контейнер сделает автоматически.
361 785551
>>85320

>FPC-проекты появились, но быстро сдулись


А сколько их было? Я только один нашёл:
https://github.com/BenediktMagnus/godot-object-pascal

Я посмотрел, что нужно сделать для GDNative. Если кратко, то перевод биндингов с C на Pascal не самое сложное. Сложно это всё в годный вид привести, чтоб не нужно было писать тонны бойлерплейта, обращаться к C-функциям напрямую и использовать типы Годо. Нужна, я считаю, ООП-обвязка, слой абстракции или фреймворк, не знаю как лучше назвать. Короче, так, как предлагают писать натив скрипты в мануале Годо я писать не хочу.

Посмотрим, что с этим можно сделать...

Интересно, а можно сделать C++-модуль, чтобы писать на Паскале прямо в редакторе Годо? Ну там, подсветка, автодополнение, поиск по справке, компиляция перед запуском (вызовом FPC). Было бы нереально круто. Но это и очень сложно, как я понимаю.
362 785566
>>85551

> как предлагают писать натив скрипты в мануале Годо я писать не хочу


Сейм. Умом понимаю, что это сделано для универсальности, но желудок не принимает.

> Интересно, а можно сделать C++-модуль, чтобы писать на Паскале прямо в редакторе Годо?


Можно. ГДскрипт - это собственно такой модуль.
363 785671
Как вообще компилировать проект не собирая все в один exe файл? Есть какой-нибудь гайд или галочка? Или нужно как-то иначе продумывать архитектуру?
364 785695
>>85671
А что в этом плохого?
365 785698
>>85695
Я просто нуб, но как давать доступ к модингу игры? Писать апишку ?
367 785702
>>85699
>>85700 (Del)
Короче понял, нужно писать четкую архитектуру игры с айпи для модинга. Нужно поковырять это в будущем, чет мало инфы обо всем этом.
368 785706
>>85671

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


>>85698

>как давать доступ к модингу игры?


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

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

>>85702

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


Это везде так, если ты хочешь позволить игрокам безопасно (без риска сломать игру) устанавливать множество модов и делать подборки разных модов. Поэтому мало кто делает официальное апи для моддинга - это весьма сложно, я думаю.
1642313647644.png91 Кб, 500x400
ПЕРЕКАТ # OP 369 785716
370 785913
>>85716
Зачем так рано перекатываешь? Непривычно как-то, остальные треды обычно долго не перекатывают...
# OP 371 785977
>>85913
Пунктуальность, сэр.
e013112b8334408a66210269cc086a0f.jpg20 Кб, 300x256
372 787687
>>84212
Конечно-же на РЫГМУКЕРЕ!
373 791784
>>79700
Мутирую в гидралиска.
Тред утонул или удален.
Это копия, сохраненная 30 июня 2023 года.

Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее

Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
« /gd/В начало тредаВеб-версияНастройки
/a//b//mu//s//vg/Все доски