Этого треда уже нет.
Это копия, сохраненная 30 июня 2023 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Это копия, сохраненная 30 июня 2023 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
1,7 Мб, 1920x2592Добро пожаловать в тред любви, взаимопомощи и многопоточной загрузки!
Краткий гайд по вкату в движок:
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/
Краткий гайд по вкату в движок:
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/
Godot ECS = godex щупал кто?
https://github.com/GodotECS/godex
https://github.com/GodotECS/godex
>>79055
я в курсе
я в курсе
>>79049
Не труъ DOD ECS:
https://github.com/GodotECS/godex-examples/blob/main/HierarchicalTransformation/Components/Velocity.gd
https://github.com/GodotECS/godex-examples/blob/main/GodexPinball/Components/BounceComponent.gd
Вся суть™ 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
Здесь мы неявно вызываем Dictionary.new(), выделяем в RAM память под него, записываем туда данные и передаём ссылку на эти данные в массив. К тому же работаем со строками, что требует от Dictionary хэширования этих строк... И это каждый кадр, для каждого компонента Bounce. Эффективно ли это? Не думаю. Во всяком случае это лишает смысла подход "все необходимые компоненты в одном массиве в кэше процессора и доступ к ним мгновенный".
А главная проблема ECS для пользователя - неочевидность происходящего в коде. Вот тот же пример, мы каким-то образом получаем какой-то импульс, который потом куда-то суём и... всё? Что этот код делает с точки зрения геймплея? Без комментариев не разберёшься, а код, в котором не разберёшься без комментариев - это плохой код. В обычном ООП у нас были бы платформы, которые каждый физический тик назначали импульс всем, кто с ними соприкасается, и это было бы понятно из кода: вот платформа, вот она вот это делает каждый тик, вот на кого она влияет. А тут это непонятно, нужно искать какие-то подсказки в декларативном коде сцены или в отдельной документации...
В общем, из-за сложности с пониманием кода в ECS, единственное её практическое применение - ускорение работы с массивами компонентов, но здесь на первый взгляд нет никакого ускорения, потому что всё обмазано переходами по ссылкам. Чисто как реализация ECS - ок, но практическая польза сомнительна без правильной реализации DOD:
https://en.wikipedia.org/wiki/Data-oriented_design
...лол, там всё ещё круче должно быть: каждый int в своём отдельном массиве, т.е. "структура с массивами", а не "массив структур".
Но я, конечно, исходный код не смотрел, может там есть какие-то ухищрения, позволяющие обернуть DOD стандартным ООП-кодом GDScript, но очень в этом сомневаюсь.
Не труъ 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, но очень в этом сомневаюсь.
>>79049
Не труъ DOD ECS:
https://github.com/GodotECS/godex-examples/blob/main/HierarchicalTransformation/Components/Velocity.gd
https://github.com/GodotECS/godex-examples/blob/main/GodexPinball/Components/BounceComponent.gd
Вся суть™ 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
Здесь мы неявно вызываем Dictionary.new(), выделяем в RAM память под него, записываем туда данные и передаём ссылку на эти данные в массив. К тому же работаем со строками, что требует от Dictionary хэширования этих строк... И это каждый кадр, для каждого компонента Bounce. Эффективно ли это? Не думаю. Во всяком случае это лишает смысла подход "все необходимые компоненты в одном массиве в кэше процессора и доступ к ним мгновенный".
А главная проблема ECS для пользователя - неочевидность происходящего в коде. Вот тот же пример, мы каким-то образом получаем какой-то импульс, который потом куда-то суём и... всё? Что этот код делает с точки зрения геймплея? Без комментариев не разберёшься, а код, в котором не разберёшься без комментариев - это плохой код. В обычном ООП у нас были бы платформы, которые каждый физический тик назначали импульс всем, кто с ними соприкасается, и это было бы понятно из кода: вот платформа, вот она вот это делает каждый тик, вот на кого она влияет. А тут это непонятно, нужно искать какие-то подсказки в декларативном коде сцены или в отдельной документации...
В общем, из-за сложности с пониманием кода в ECS, единственное её практическое применение - ускорение работы с массивами компонентов, но здесь на первый взгляд нет никакого ускорения, потому что всё обмазано переходами по ссылкам. Чисто как реализация ECS - ок, но практическая польза сомнительна без правильной реализации DOD:
https://en.wikipedia.org/wiki/Data-oriented_design
...лол, там всё ещё круче должно быть: каждый int в своём отдельном массиве, т.е. "структура с массивами", а не "массив структур".
Но я, конечно, исходный код не смотрел, может там есть какие-то ухищрения, позволяющие обернуть DOD стандартным ООП-кодом GDScript, но очень в этом сомневаюсь.
Не труъ 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, но очень в этом сомневаюсь.
>>79077
На самом деле это не совсем так. В некоторых ЯП есть структуры с включёнными в них функциями, которые хранятся на стеке, т.е. передаются целиком, без использования ссылок, например:
https://wiki.freepascal.org/Object
То есть массив таких объектов может, теоретически, умещаться в кэш процессора, но обращение к функциям, скорее всего, опять же вызовет лишние переходы. Так что лучше иметь массивы максимально простых данных (int, float), так будет точно быстрее.
Да, кстати. Может, кто-то считает, что ECS удобно использовать даже если она не даст роста производительности? Я имею в виду удобство с точки зрения разработчика игры. Я в этом сильно сомневаюсь - слишком много кода разбросано по разным файлам (компоненты, системы) и нет чёткой связи между кодом логики и объектами в сценах кроме как в декларативных файлах.
>Сам компонент, разумеется, тоже не должен быть объектом ООП, то есть он не может иметь никаких функций, только тупые данные
На самом деле это не совсем так. В некоторых ЯП есть структуры с включёнными в них функциями, которые хранятся на стеке, т.е. передаются целиком, без использования ссылок, например:
https://wiki.freepascal.org/Object
То есть массив таких объектов может, теоретически, умещаться в кэш процессора, но обращение к функциям, скорее всего, опять же вызовет лишние переходы. Так что лучше иметь массивы максимально простых данных (int, float), так будет точно быстрее.
Да, кстати. Может, кто-то считает, что ECS удобно использовать даже если она не даст роста производительности? Я имею в виду удобство с точки зрения разработчика игры. Я в этом сильно сомневаюсь - слишком много кода разбросано по разным файлам (компоненты, системы) и нет чёткой связи между кодом логики и объектами в сценах кроме как в декларативных файлах.
>>79078
Ну вот, допустим, я хочу сделать бота для игры. В ООП я просто создаю класс бота и дальше вся его логика у меня лежит в одном месте. Этой логике не нужно никуда двигаться, она будет только тут и нигде больше. В ЕЦС я вынужден создавать компонент AI и систему AI, которой потребуется доступ к сотням компонентов сразу, потому что бот должен иметь полноценный контроль за всеми возможными игровыми объектами, с которыми он может взаимодействовать. В результате система AI будет содержать в себе большую часть кода из обычного ООП класса, но этот код будет менее логичным из-за того, что данные вынесены из него в отдельные места, по которым приходится регулярно бегать... А если логику разделить на несколько компонентов и систем, то вся разработка превращается в ад из постоянных переходов между файлами и участками кода, которые никак не говорят о том, кому они в реальности принадлежат (боту).
Да, может быть, яжгеймдизайнеру будет потом легко соединять между собой мои компоненты в разные физически невозможные варианты eldritch abomination, но так ли нужно это для типичной игры и действительно ли это стоит той боли, которую я должен буду вынести, храня в своей краткосрочной памяти сотни компонентов за раз на каждом этапе разработки (кто не знает, краткосрочная у человека ограничена примерно семью разными сущностями)? А хранить их в своей памяти придётся, иначе как я просчитаю все возможные несовместимости всех комбинаций компонентов? Типа, вот у нас коробка, вот прыгающая коробка, вот летающая коробка, вот квакающая коробка, вот пушистая коробка, вот быстрая коробка, вот коробка красного цвета, вот коробка синего цвета, вот коробка коробки, вот коробка с коробками...
Ладно, это не касается Godot. Просто я не понимаю, зачем ЭТО тащить в Godot, когда у него и без этого проблем хватает. Мало того, что ты борешься с багами и ограничениями движка, теперь будешь бороться с возмутительно противоестественным дизайном ЕЦС... Хорошо, что это пока только сторонний проект.
>удобство с точки зрения разработчика
Ну вот, допустим, я хочу сделать бота для игры. В ООП я просто создаю класс бота и дальше вся его логика у меня лежит в одном месте. Этой логике не нужно никуда двигаться, она будет только тут и нигде больше. В ЕЦС я вынужден создавать компонент AI и систему AI, которой потребуется доступ к сотням компонентов сразу, потому что бот должен иметь полноценный контроль за всеми возможными игровыми объектами, с которыми он может взаимодействовать. В результате система AI будет содержать в себе большую часть кода из обычного ООП класса, но этот код будет менее логичным из-за того, что данные вынесены из него в отдельные места, по которым приходится регулярно бегать... А если логику разделить на несколько компонентов и систем, то вся разработка превращается в ад из постоянных переходов между файлами и участками кода, которые никак не говорят о том, кому они в реальности принадлежат (боту).
Да, может быть, яжгеймдизайнеру будет потом легко соединять между собой мои компоненты в разные физически невозможные варианты eldritch abomination, но так ли нужно это для типичной игры и действительно ли это стоит той боли, которую я должен буду вынести, храня в своей краткосрочной памяти сотни компонентов за раз на каждом этапе разработки (кто не знает, краткосрочная у человека ограничена примерно семью разными сущностями)? А хранить их в своей памяти придётся, иначе как я просчитаю все возможные несовместимости всех комбинаций компонентов? Типа, вот у нас коробка, вот прыгающая коробка, вот летающая коробка, вот квакающая коробка, вот пушистая коробка, вот быстрая коробка, вот коробка красного цвета, вот коробка синего цвета, вот коробка коробки, вот коробка с коробками...
Ладно, это не касается Godot. Просто я не понимаю, зачем ЭТО тащить в Godot, когда у него и без этого проблем хватает. Мало того, что ты борешься с багами и ограничениями движка, теперь будешь бороться с возмутительно противоестественным дизайном ЕЦС... Хорошо, что это пока только сторонний проект.
>>79078
Ну вот, допустим, я хочу сделать бота для игры. В ООП я просто создаю класс бота и дальше вся его логика у меня лежит в одном месте. Этой логике не нужно никуда двигаться, она будет только тут и нигде больше. В ЕЦС я вынужден создавать компонент AI и систему AI, которой потребуется доступ к сотням компонентов сразу, потому что бот должен иметь полноценный контроль за всеми возможными игровыми объектами, с которыми он может взаимодействовать. В результате система AI будет содержать в себе большую часть кода из обычного ООП класса, но этот код будет менее логичным из-за того, что данные вынесены из него в отдельные места, по которым приходится регулярно бегать... А если логику разделить на несколько компонентов и систем, то вся разработка превращается в ад из постоянных переходов между файлами и участками кода, которые никак не говорят о том, кому они в реальности принадлежат (боту).
Да, может быть, яжгеймдизайнеру будет потом легко соединять между собой мои компоненты в разные физически невозможные варианты eldritch abomination, но так ли нужно это для типичной игры и действительно ли это стоит той боли, которую я должен буду вынести, храня в своей краткосрочной памяти сотни компонентов за раз на каждом этапе разработки (кто не знает, краткосрочная у человека ограничена примерно семью разными сущностями)? А хранить их в своей памяти придётся, иначе как я просчитаю все возможные несовместимости всех комбинаций компонентов? Типа, вот у нас коробка, вот прыгающая коробка, вот летающая коробка, вот квакающая коробка, вот пушистая коробка, вот быстрая коробка, вот коробка красного цвета, вот коробка синего цвета, вот коробка коробки, вот коробка с коробками...
Ладно, это не касается Godot. Просто я не понимаю, зачем ЭТО тащить в Godot, когда у него и без этого проблем хватает. Мало того, что ты борешься с багами и ограничениями движка, теперь будешь бороться с возмутительно противоестественным дизайном ЕЦС... Хорошо, что это пока только сторонний проект.
>удобство с точки зрения разработчика
Ну вот, допустим, я хочу сделать бота для игры. В ООП я просто создаю класс бота и дальше вся его логика у меня лежит в одном месте. Этой логике не нужно никуда двигаться, она будет только тут и нигде больше. В ЕЦС я вынужден создавать компонент AI и систему AI, которой потребуется доступ к сотням компонентов сразу, потому что бот должен иметь полноценный контроль за всеми возможными игровыми объектами, с которыми он может взаимодействовать. В результате система AI будет содержать в себе большую часть кода из обычного ООП класса, но этот код будет менее логичным из-за того, что данные вынесены из него в отдельные места, по которым приходится регулярно бегать... А если логику разделить на несколько компонентов и систем, то вся разработка превращается в ад из постоянных переходов между файлами и участками кода, которые никак не говорят о том, кому они в реальности принадлежат (боту).
Да, может быть, яжгеймдизайнеру будет потом легко соединять между собой мои компоненты в разные физически невозможные варианты eldritch abomination, но так ли нужно это для типичной игры и действительно ли это стоит той боли, которую я должен буду вынести, храня в своей краткосрочной памяти сотни компонентов за раз на каждом этапе разработки (кто не знает, краткосрочная у человека ограничена примерно семью разными сущностями)? А хранить их в своей памяти придётся, иначе как я просчитаю все возможные несовместимости всех комбинаций компонентов? Типа, вот у нас коробка, вот прыгающая коробка, вот летающая коробка, вот квакающая коробка, вот пушистая коробка, вот быстрая коробка, вот коробка красного цвета, вот коробка синего цвета, вот коробка коробки, вот коробка с коробками...
Ладно, это не касается Godot. Просто я не понимаю, зачем ЭТО тащить в Godot, когда у него и без этого проблем хватает. Мало того, что ты борешься с багами и ограничениями движка, теперь будешь бороться с возмутительно противоестественным дизайном ЕЦС... Хорошо, что это пока только сторонний проект.
36 Кб, 540x500>>79080
А разгадка в том, что ЭЦС - это когда зумеры придумают новое слово для того, что уже делали до них замшелые бумеры. Окей, бумер, говорят тупые зумеры, когда им объясняешь, что ЕЦС ихнее - это два паттерна проектирования: наблюдатель и композиция. Всё. Всё, блять, ты понимаешь масштаб тупости зумерья?
Настоящему программисту ничего не мешает в зависимости от требований проекта объединять И композицию, И наследование. Это у тупых фанбоев в голове не укладывается.
Датаориентированное программирование... Штоблять? Додики, блять.
А разгадка в том, что ЭЦС - это когда зумеры придумают новое слово для того, что уже делали до них замшелые бумеры. Окей, бумер, говорят тупые зумеры, когда им объясняешь, что ЕЦС ихнее - это два паттерна проектирования: наблюдатель и композиция. Всё. Всё, блять, ты понимаешь масштаб тупости зумерья?
Настоящему программисту ничего не мешает в зависимости от требований проекта объединять И композицию, И наследование. Это у тупых фанбоев в голове не укладывается.
Датаориентированное программирование... Штоблять? Додики, блять.
>>79077
вы думаете, что если в плюсах я сделаю компоненты в виде двусвязного списка (например, двусвязный список структуры позиция), то из-за того, что список хранит в каждой ноде ссылки на предыдущую и следующую ноду, то оно теряет все преимущества ECS как кеширование процессором и можно не делать?
импульс добавляется как компонент соответствующей сущности и следующая система Move отработает эти компоненты и удалит их
создается система AI_WOLF и на каждую сущность волка навешивается компонент AI_WOLF. Никакого доступа к сотням компонентов не будет, кроме подмножества тех, у которых есть компонент AI_WOLF
вы думаете, что если в плюсах я сделаю компоненты в виде двусвязного списка (например, двусвязный список структуры позиция), то из-за того, что список хранит в каждой ноде ссылки на предыдущую и следующую ноду, то оно теряет все преимущества ECS как кеширование процессором и можно не делать?
> мы каким-то образом получаем какой-то импульс, который потом куда-то суём
импульс добавляется как компонент соответствующей сущности и следующая система Move отработает эти компоненты и удалит их
> Ну вот, допустим, я хочу сделать бота для игры.
создается система AI_WOLF и на каждую сущность волка навешивается компонент AI_WOLF. Никакого доступа к сотням компонентов не будет, кроме подмножества тех, у которых есть компонент AI_WOLF
>>79081
так комбинацию этих паттернов с некоторыми особенностями реализации и назвали ECS для более удобного и быстрого понимания, как и вводят любые другие термины
> ЕЦС ихнее - это два паттерна проектирования: наблюдатель и композиция
так комбинацию этих паттернов с некоторыми особенностями реализации и назвали ECS для более удобного и быстрого понимания, как и вводят любые другие термины
>>79082
Зачем такие сложности? Особенно в плане
- это же лишние операции добавления/удаления.
Учитывая, что добавляется/удаляется Dictionary, здесь ещё и конструирование/освобождение объекта с выделением/освобождением памяти в куче. На простую передачу информации из одной системы в другую.
AI_WOLF должен знать положение всех ближайших AI_RABBIT, их жирноту, здоровье, скорость и направление движения, а также положение всех ближайших AI_HUNTER и PLAYER, их оружие, здоровье, скорость и направление движения. И это только базовый волчара, у которого нет стаи, потому что со стаей ему придётся знать положение всех ближайших AI_WOLF, их здоровье, настроение, текущие цели и приоритеты, и т.д. Ты не можешь создать сферический в вакууме AI, который ни к чему доступа не имеет, даже монстры в Пакмане и те опирались на положение игрока, за исключением того, который ходил полностью рандомно.
Таки в чём преимущества, если не в кэше процессора?
>>79081
Суть ЕЦС не в названии, а в способе реализации. Ты можешь сделать что-то типа ЕЦС на ООП классах, но это не будет труЪ ЕЦС™.
>импульс добавляется как компонент соответствующей сущности и следующая система Move отработает эти компоненты и удалит их
Зачем такие сложности? Особенно в плане
>удалит их
- это же лишние операции добавления/удаления.
Учитывая, что добавляется/удаляется Dictionary, здесь ещё и конструирование/освобождение объекта с выделением/освобождением памяти в куче. На простую передачу информации из одной системы в другую.
>Никакого доступа к сотням компонентов не будет, кроме подмножества тех, у которых есть компонент AI_WOLF
AI_WOLF должен знать положение всех ближайших AI_RABBIT, их жирноту, здоровье, скорость и направление движения, а также положение всех ближайших AI_HUNTER и PLAYER, их оружие, здоровье, скорость и направление движения. И это только базовый волчара, у которого нет стаи, потому что со стаей ему придётся знать положение всех ближайших AI_WOLF, их здоровье, настроение, текущие цели и приоритеты, и т.д. Ты не можешь создать сферический в вакууме AI, который ни к чему доступа не имеет, даже монстры в Пакмане и те опирались на положение игрока, за исключением того, который ходил полностью рандомно.
>преимущества ECS
Таки в чём преимущества, если не в кэше процессора?
>>79081
Суть ЕЦС не в названии, а в способе реализации. Ты можешь сделать что-то типа ЕЦС на ООП классах, но это не будет труЪ ЕЦС™.
>>79085
для распараллеливания
точно как и в другом представлении данных, но перебор будет по такому же количеству: просто то, что обчычно представляется перебором по клеткам вокруг волка - это компонент, хранящий ссылки и координаты нужных сущностей(например, зайцев) из-за чего логика отработает быстрее, т.к. не нужно перебирать все клетки, а только работать с нужным массивом сущностей
да, это просто устоявшееся название такого подхода без особых уточнений в реализации
> Зачем такие сложности?
для распараллеливания
> AI_WOLF должен знать положение всех ближайших AI_RABBIT, их жирноту.....
точно как и в другом представлении данных, но перебор будет по такому же количеству: просто то, что обчычно представляется перебором по клеткам вокруг волка - это компонент, хранящий ссылки и координаты нужных сущностей(например, зайцев) из-за чего логика отработает быстрее, т.к. не нужно перебирать все клетки, а только работать с нужным массивом сущностей
> Суть ЕЦС не в названии, а в способе реализации.
да, это просто устоявшееся название такого подхода без особых уточнений в реализации
>>79105 (Del)
На плойке трёшке (для чудного проца которой и изобрели ЕЦС нотидоги) это закончилось успешной серией приключений Драке.
> А если ты засунешь все в один огромный файл, ничем хорошим это не кончится.
На плойке трёшке (для чудного проца которой и изобрели ЕЦС нотидоги) это закончилось успешной серией приключений Драке.
>>79115
Влияет. Изучи матчасть по своей же хуите. Скорость ЕЦС напрямую зависит от того, как будут подниматься данные из файлов. В какой последовательности уложены все эти атрибуты сущностей. Иначе хвалёная кэш-магия не сработает и не даст свои 0,5 процента прироста на современных процах перед нормальным ООП здорового человека.
Влияет. Изучи матчасть по своей же хуите. Скорость ЕЦС напрямую зависит от того, как будут подниматься данные из файлов. В какой последовательности уложены все эти атрибуты сущностей. Иначе хвалёная кэш-магия не сработает и не даст свои 0,5 процента прироста на современных процах перед нормальным ООП здорового человека.
>>79105 (Del)
Вот только у ЕЦС-бота обращения к сотням ничем не связанных компонентов в сотнях файлов, а у ООП-бота обращения к десятку сущностей в их личных файлах, у которых даже если и есть по десятку внутренних компонентов, бота это не волнует - он работает с сущностями, а не с компонентами. Т.е. программируя в стиле ЕЦС, ты должен держать в своей памяти или отдельной от проекта записке, какие сущности у тебя есть и какие компоненты они могут содержать, а в стиле ООП у тебя есть сущности и ты работаешь с ними не задумываясь ни о чём постороннем - всё необходимое для работы у тебя есть в коде. В этом суть ООП - ты работаешь с сущностями, которые можешь "пощупать" или с которыми можешь "поговорить", а подход ЕЦС полностью лишает тебя этих возможностей.
Забавно, что в маленьком проекте от ЕЦС нет никакой пользы - намного удобнее и выгоднее иметь 2-3 ООП класса с понятными именами (wolf, rabbit, player), в то же время в большом проекте из-за ЕЦС всё становится намного сложнее - сотни, если не тысячи, отдельных компонентов, связанных между собой непонятно как непонятно где, и ни одной реальной сущности... Мне кажется, единственная область, где ЕЦС удобно и полезно - это когда тебе нужно огромное количество объектов с минимальной, очень простой логикой, скорее всего однотипной. Что-нибудь типа арканоида, только блоков сотни тысяч вместо пары сотен.
Не нужно всё один файл совать, нужно распределять данные и логику по сущностям, а не по компонентам несуществующих сущностей. Я не против переодически переходить между wolf.gd и rabbit.gd, я против постоянного поиска по нескольким десяткам файлов с компонентами, которые ещё и связаны друг с другом только в каком-то совершенно отдельном файле (скорее всего в декларативном .tscn).
>Если твой ЕЦС-бот взаимодействуетс сотнями компонентов, то и ООП бот должен будет к ним же обращаться.
Вот только у ЕЦС-бота обращения к сотням ничем не связанных компонентов в сотнях файлов, а у ООП-бота обращения к десятку сущностей в их личных файлах, у которых даже если и есть по десятку внутренних компонентов, бота это не волнует - он работает с сущностями, а не с компонентами. Т.е. программируя в стиле ЕЦС, ты должен держать в своей памяти или отдельной от проекта записке, какие сущности у тебя есть и какие компоненты они могут содержать, а в стиле ООП у тебя есть сущности и ты работаешь с ними не задумываясь ни о чём постороннем - всё необходимое для работы у тебя есть в коде. В этом суть ООП - ты работаешь с сущностями, которые можешь "пощупать" или с которыми можешь "поговорить", а подход ЕЦС полностью лишает тебя этих возможностей.
Забавно, что в маленьком проекте от ЕЦС нет никакой пользы - намного удобнее и выгоднее иметь 2-3 ООП класса с понятными именами (wolf, rabbit, player), в то же время в большом проекте из-за ЕЦС всё становится намного сложнее - сотни, если не тысячи, отдельных компонентов, связанных между собой непонятно как непонятно где, и ни одной реальной сущности... Мне кажется, единственная область, где ЕЦС удобно и полезно - это когда тебе нужно огромное количество объектов с минимальной, очень простой логикой, скорее всего однотипной. Что-нибудь типа арканоида, только блоков сотни тысяч вместо пары сотен.
>А если ты засунешь все в один огромный файл, ничем хорошим это не кончится.
Не нужно всё один файл совать, нужно распределять данные и логику по сущностям, а не по компонентам несуществующих сущностей. Я не против переодически переходить между wolf.gd и rabbit.gd, я против постоянного поиска по нескольким десяткам файлов с компонентами, которые ещё и связаны друг с другом только в каком-то совершенно отдельном файле (скорее всего в декларативном .tscn).
>>79244
ты знаешь еще не всю правду: я твой отец
ты знаешь еще не всю правду: я твой отец
>>79258
чел, ты знаешь что такое файл? и как работает скомпилированное приложение?
ты хотя бы теорию почитай как это все делается, а не пытайся умничать с дядями, которые в том числе писали такие системы
да, в маленьком проекте типа шахмат, например, лучше его не использовать и так никто и не делает кроме теориетических примеров, а вот в match-3 уже почти повсеместно
количество данных не меняется от того ecs или ооп
вот буковка E в ECS и есть та сущность, которая является аналогом простой композиции данный внутри класса в ооп
а ты меньше доверяй своему малому опыту и больше читай научной литературы по этому вопросу
и снова читай про буковку E
> в сотнях файлов
чел, ты знаешь что такое файл? и как работает скомпилированное приложение?
> Т.е. программируя в стиле ЕЦС, ты должен держать в своей памяти или отдельной от проекта записке, какие сущности у тебя есть и какие компоненты они могут содержать, а в стиле ООП у тебя есть сущности и ты работаешь с ними не задумываясь ни о чём постороннем - всё необходимое для работы у тебя есть в коде.
ты хотя бы теорию почитай как это все делается, а не пытайся умничать с дядями, которые в том числе писали такие системы
> Забавно, что в маленьком проекте от ЕЦС нет никакой пользы
да, в маленьком проекте типа шахмат, например, лучше его не использовать и так никто и не делает кроме теориетических примеров, а вот в match-3 уже почти повсеместно
> сотни, если не тысячи, отдельных компонентов
количество данных не меняется от того ecs или ооп
> компонентов, связанных между собой непонятно как непонятно где, и ни одной реальной сущности
вот буковка E в ECS и есть та сущность, которая является аналогом простой композиции данный внутри класса в ооп
> Мне кажется
а ты меньше доверяй своему малому опыту и больше читай научной литературы по этому вопросу
> а не по компонентам несуществующих сущностей
и снова читай про буковку E
>>79302
Зачем в матч3 ецс, сетку конфеток 10x10 сильно сложнее нарисовать, чем шахматную доску?
Зачем в матч3 ецс, сетку конфеток 10x10 сильно сложнее нарисовать, чем шахматную доску?
>>79310
Ну я не тот, с кем ты диалог вел, и ецс никогда не использовал, вот интересуюсь. Так чем ецс так полезна для мач3?
Ну я не тот, с кем ты диалог вел, и ецс никогда не использовал, вот интересуюсь. Так чем ецс так полезна для мач3?
>>79302
Не важно, как оно работает, мне придётся держать 100 вкладок в окне Godot, 50 из них будут ...Component.gd, а другие 50 - ...System.gd, и ты считаешь, что это нормально? При том что игровых объектов может быть меньше десятка, но при этом свойств а.к.а. компонентов у каждого больше десятка.
Я пытался писать ЕЦС с нуля. Забил, когда в папке компонентов стало больше десятка файлов, а я тратил больше времени на переключение между вкладками в редакторе, чем на чтение самого кода. И это я почти ничего не реализовал, прототипа игры по сути ещё не было - а путаница в компонентах и системах уже была.
Пример привести можешь? Ты из тех, кто создаёт отдельный экземпляр класса на каждую конфетку на поле, а потом регулярно их конструирует и освобождает? Тогда тебя никакая ЕЦС не спасёт...
Да, но в ООП они сгруппированы удобно для разработчика, а в ЕЦС они сгруппированы неудобно для разработчика, но В ТЕОРИИ удобно для машины (но никакой гарантии тут нет).
Которая выражается простым числом.
С каких пор стало необходимо читать научную литературу, чтобы хотя бы разобраться, что происходит в коде простой игры "три-в-ряд"?
>>79314
Типа вместо экземпляров класса Candy будет массив массивов компонентов CandyComponent, обрабатываемый CandySystem. Но на самом деле нет, будет два десятка компонентов на каждую конфетку.
>как работает скомпилированное приложение
Не важно, как оно работает, мне придётся держать 100 вкладок в окне Godot, 50 из них будут ...Component.gd, а другие 50 - ...System.gd, и ты считаешь, что это нормально? При том что игровых объектов может быть меньше десятка, но при этом свойств а.к.а. компонентов у каждого больше десятка.
>которые в том числе писали такие системы
Я пытался писать ЕЦС с нуля. Забил, когда в папке компонентов стало больше десятка файлов, а я тратил больше времени на переключение между вкладками в редакторе, чем на чтение самого кода. И это я почти ничего не реализовал, прототипа игры по сути ещё не было - а путаница в компонентах и системах уже была.
>match-3
Пример привести можешь? Ты из тех, кто создаёт отдельный экземпляр класса на каждую конфетку на поле, а потом регулярно их конструирует и освобождает? Тогда тебя никакая ЕЦС не спасёт...
>количество данных не меняется
Да, но в ООП они сгруппированы удобно для разработчика, а в ЕЦС они сгруппированы неудобно для разработчика, но В ТЕОРИИ удобно для машины (но никакой гарантии тут нет).
>вот буковка E в ECS и есть та сущность
Которая выражается простым числом.
>научной литературы
С каких пор стало необходимо читать научную литературу, чтобы хотя бы разобраться, что происходит в коде простой игры "три-в-ряд"?
>>79314
>Так чем ецс так полезна для мач3?
Типа вместо экземпляров класса Candy будет массив массивов компонентов CandyComponent, обрабатываемый CandySystem. Но на самом деле нет, будет два десятка компонентов на каждую конфетку.
>>79314
в новой создаваемой три-в-ряд ты еще не знаешь ни какие изначально будут эффекты фишек, эффекты поля, структура самого уровня - ecs в данном случае отлично помогает прямо с начальных этапов комбинировать все эти штуки в любых сочетаниях причем не программистами уже, а также легко и быстро написанной тулзой для дизайнеров
как и на более поздних этапах все быстро перестраивается после опять же удобно написанных тестов
а для шахмат уже полностью заранее известны все правила, которые не будут меняться, поэтому тут эффективнее, например, использовать ооп
>>79319
речь конечно не исключительно про godot, но раз уж так...
компонент почти сразу пишется в исходном виде и после этого закрывается, потому что он практически никогда уже не пригождается
и вот как раз из-за малой связности логики кода в ECS, то и системы ты легко открываешь парочку и только их пишешь и потом также спокойно закрываешь
только вот для каждой системы чаще всего требуется лишь один компонент, значительно реже 2-3
выше в этом сообщении описал другому анону
тоже удобно, но другим подходом, а если привык к другому, например, ооп, то перестраиваться на другой мозги сложнее
только id в контейнере хранилище, а вот в самом еще ссылки на каждый компонент (а еще в более сложных, но эффективных системах еще кэши)
в новой создаваемой три-в-ряд ты еще не знаешь ни какие изначально будут эффекты фишек, эффекты поля, структура самого уровня - ecs в данном случае отлично помогает прямо с начальных этапов комбинировать все эти штуки в любых сочетаниях причем не программистами уже, а также легко и быстро написанной тулзой для дизайнеров
как и на более поздних этапах все быстро перестраивается после опять же удобно написанных тестов
а для шахмат уже полностью заранее известны все правила, которые не будут меняться, поэтому тут эффективнее, например, использовать ооп
>>79319
речь конечно не исключительно про godot, но раз уж так...
> 50 из них будут ...Component.gd
компонент почти сразу пишется в исходном виде и после этого закрывается, потому что он практически никогда уже не пригождается
> а другие 50 - ...System.gd
и вот как раз из-за малой связности логики кода в ECS, то и системы ты легко открываешь парочку и только их пишешь и потом также спокойно закрываешь
> но при этом свойств а.к.а. компонентов у каждого больше десятка
только вот для каждой системы чаще всего требуется лишь один компонент, значительно реже 2-3
> Пример привести можешь?
выше в этом сообщении описал другому анону
> они сгруппированы неудобно для разработчика
тоже удобно, но другим подходом, а если привык к другому, например, ооп, то перестраиваться на другой мозги сложнее
> Которая выражается простым числом.
только id в контейнере хранилище, а вот в самом еще ссылки на каждый компонент (а еще в более сложных, но эффективных системах еще кэши)
>>79324
1. Думаю, в жанре "три-в-ряд" всё давно изобретено и все "новые" игры собираются на готовых фреймворках/ассетах. Велосипеды пилят только клинические велосипедисты да ньюфаги. Даже если ты изобрёл что-то новое - не факт, что оно кому-нибудь нужно, все привыкли играть по стандартным правилам этого жанра.
2. Перед разработкой любой игры должен быть этап написания дизайн-документа. Да, можно оправдать постепенное изменение диздока в процессе разработки большой игры типа РПГ, но три-в-ряд легко распланировать заранее и ничего не менять после - все механики давно известны и изобретать ничего не нужно.
Мы в треде Godot и обсуждение началось вокруг какого-то сомнительного модуля специально для Godot.
А если я забуду, что, где и как? На автодополнение надеяться?
Я всё понял, ЕЦС подходит только проектам с малой связностью логики, во всех остальных случаях использовать ЕЦС нерационально.
Я в это верил, пока не попробовал сам. На практике нереально уложить логику так, чтобы был доступ только к 2-3 компонентам, постоянно нужно больше, и это ломает всю суть ЕЦС. Все эти примеры с покадровым вращением/движением всех сущностей с компонентом вращения/движения - это сферические примеры в вакууме, в реальном проекте от таких систем пользы нет.
Вот что мне больше всего не нравится в ЕЦС - невозможно интуитивно подходить к разработке. В ООП у нас объекты зачастую соответствуют реальным прототипам и/или отдельным объектам игрового мира. Мы работаем с ними почти так, как работали бы с реальными объектами или как игровой персонаж работал бы с ними в своём мире. Всё просто и понятно. В ЕЦС же нет объектов в привычном понимании, мы не можем делать привычные обращения к ним, не можем привычно у них что-то узнать, не можем ими командовать и т.д. Т.е. объектов просто нет. Да, есть entities, но объекты ли это? Нет, потому что мы не можем с ними взаимодействовать, мы можем только перебирать однотипные компоненты... ЕЦС просто противоестественна.
>в новой создаваемой три-в-ряд ты еще не знаешь ни какие изначально будут эффекты фишек, эффекты поля, структура самого уровня
1. Думаю, в жанре "три-в-ряд" всё давно изобретено и все "новые" игры собираются на готовых фреймворках/ассетах. Велосипеды пилят только клинические велосипедисты да ньюфаги. Даже если ты изобрёл что-то новое - не факт, что оно кому-нибудь нужно, все привыкли играть по стандартным правилам этого жанра.
2. Перед разработкой любой игры должен быть этап написания дизайн-документа. Да, можно оправдать постепенное изменение диздока в процессе разработки большой игры типа РПГ, но три-в-ряд легко распланировать заранее и ничего не менять после - все механики давно известны и изобретать ничего не нужно.
>речь конечно не исключительно про godot
Мы в треде Godot и обсуждение началось вокруг какого-то сомнительного модуля специально для Godot.
>после этого закрывается
А если я забуду, что, где и как? На автодополнение надеяться?
>из-за малой связности логики кода в ECS
Я всё понял, ЕЦС подходит только проектам с малой связностью логики, во всех остальных случаях использовать ЕЦС нерационально.
>чаще всего требуется лишь один компонент
Я в это верил, пока не попробовал сам. На практике нереально уложить логику так, чтобы был доступ только к 2-3 компонентам, постоянно нужно больше, и это ломает всю суть ЕЦС. Все эти примеры с покадровым вращением/движением всех сущностей с компонентом вращения/движения - это сферические примеры в вакууме, в реальном проекте от таких систем пользы нет.
Вот что мне больше всего не нравится в ЕЦС - невозможно интуитивно подходить к разработке. В ООП у нас объекты зачастую соответствуют реальным прототипам и/или отдельным объектам игрового мира. Мы работаем с ними почти так, как работали бы с реальными объектами или как игровой персонаж работал бы с ними в своём мире. Всё просто и понятно. В ЕЦС же нет объектов в привычном понимании, мы не можем делать привычные обращения к ним, не можем привычно у них что-то узнать, не можем ими командовать и т.д. Т.е. объектов просто нет. Да, есть entities, но объекты ли это? Нет, потому что мы не можем с ними взаимодействовать, мы можем только перебирать однотипные компоненты... ЕЦС просто противоестественна.
>>79324
1. Думаю, в жанре "три-в-ряд" всё давно изобретено и все "новые" игры собираются на готовых фреймворках/ассетах. Велосипеды пилят только клинические велосипедисты да ньюфаги. Даже если ты изобрёл что-то новое - не факт, что оно кому-нибудь нужно, все привыкли играть по стандартным правилам этого жанра.
2. Перед разработкой любой игры должен быть этап написания дизайн-документа. Да, можно оправдать постепенное изменение диздока в процессе разработки большой игры типа РПГ, но три-в-ряд легко распланировать заранее и ничего не менять после - все механики давно известны и изобретать ничего не нужно.
Мы в треде Godot и обсуждение началось вокруг какого-то сомнительного модуля специально для Godot.
А если я забуду, что, где и как? На автодополнение надеяться?
Я всё понял, ЕЦС подходит только проектам с малой связностью логики, во всех остальных случаях использовать ЕЦС нерационально.
Я в это верил, пока не попробовал сам. На практике нереально уложить логику так, чтобы был доступ только к 2-3 компонентам, постоянно нужно больше, и это ломает всю суть ЕЦС. Все эти примеры с покадровым вращением/движением всех сущностей с компонентом вращения/движения - это сферические примеры в вакууме, в реальном проекте от таких систем пользы нет.
Вот что мне больше всего не нравится в ЕЦС - невозможно интуитивно подходить к разработке. В ООП у нас объекты зачастую соответствуют реальным прототипам и/или отдельным объектам игрового мира. Мы работаем с ними почти так, как работали бы с реальными объектами или как игровой персонаж работал бы с ними в своём мире. Всё просто и понятно. В ЕЦС же нет объектов в привычном понимании, мы не можем делать привычные обращения к ним, не можем привычно у них что-то узнать, не можем ими командовать и т.д. Т.е. объектов просто нет. Да, есть entities, но объекты ли это? Нет, потому что мы не можем с ними взаимодействовать, мы можем только перебирать однотипные компоненты... ЕЦС просто противоестественна.
>в новой создаваемой три-в-ряд ты еще не знаешь ни какие изначально будут эффекты фишек, эффекты поля, структура самого уровня
1. Думаю, в жанре "три-в-ряд" всё давно изобретено и все "новые" игры собираются на готовых фреймворках/ассетах. Велосипеды пилят только клинические велосипедисты да ньюфаги. Даже если ты изобрёл что-то новое - не факт, что оно кому-нибудь нужно, все привыкли играть по стандартным правилам этого жанра.
2. Перед разработкой любой игры должен быть этап написания дизайн-документа. Да, можно оправдать постепенное изменение диздока в процессе разработки большой игры типа РПГ, но три-в-ряд легко распланировать заранее и ничего не менять после - все механики давно известны и изобретать ничего не нужно.
>речь конечно не исключительно про godot
Мы в треде Godot и обсуждение началось вокруг какого-то сомнительного модуля специально для Godot.
>после этого закрывается
А если я забуду, что, где и как? На автодополнение надеяться?
>из-за малой связности логики кода в ECS
Я всё понял, ЕЦС подходит только проектам с малой связностью логики, во всех остальных случаях использовать ЕЦС нерационально.
>чаще всего требуется лишь один компонент
Я в это верил, пока не попробовал сам. На практике нереально уложить логику так, чтобы был доступ только к 2-3 компонентам, постоянно нужно больше, и это ломает всю суть ЕЦС. Все эти примеры с покадровым вращением/движением всех сущностей с компонентом вращения/движения - это сферические примеры в вакууме, в реальном проекте от таких систем пользы нет.
Вот что мне больше всего не нравится в ЕЦС - невозможно интуитивно подходить к разработке. В ООП у нас объекты зачастую соответствуют реальным прототипам и/или отдельным объектам игрового мира. Мы работаем с ними почти так, как работали бы с реальными объектами или как игровой персонаж работал бы с ними в своём мире. Всё просто и понятно. В ЕЦС же нет объектов в привычном понимании, мы не можем делать привычные обращения к ним, не можем привычно у них что-то узнать, не можем ими командовать и т.д. Т.е. объектов просто нет. Да, есть entities, но объекты ли это? Нет, потому что мы не можем с ними взаимодействовать, мы можем только перебирать однотипные компоненты... ЕЦС просто противоестественна.
>>79366
вот из диванных переквалифицируешься в обычных разработчиков, тогда и поговорим
а если ты забудешь после блока кода какой end if из пяти к чему относится
скорее всего Вам не хватило опыта сконструировать компоненты и системы таким образом
скорее всего была одна из типичных проблем - раздутия систем (часто, страдают как раз переходящие из ооп и не сумевшие перестроить парадигму в своей голове)
да, за ее эффективность нужно платить тем, что обучение сложнее
да, это тот же объект по данным так один в один. Нет, ничто не мешает перебрать компоненты нужной сущности
> Думаю, в жанре "три-в-ряд" всё давно изобретено
> но три-в-ряд легко распланировать заранее и ничего не менять после - все механики давно известны и изобретать ничего не нужно
вот из диванных переквалифицируешься в обычных разработчиков, тогда и поговорим
> А если я забуду, что, где и как? На автодополнение надеяться?
а если ты забудешь после блока кода какой end if из пяти к чему относится
> На практике нереально уложить логику так, чтобы был доступ только к 2-3 компонентам, постоянно нужно больше
скорее всего Вам не хватило опыта сконструировать компоненты и системы таким образом
скорее всего была одна из типичных проблем - раздутия систем (часто, страдают как раз переходящие из ооп и не сумевшие перестроить парадигму в своей голове)
> Вот что мне больше всего не нравится в ЕЦС - невозможно интуитивно подходить к разработке
да, за ее эффективность нужно платить тем, что обучение сложнее
> Да, есть entities, но объекты ли это? Нет, потому что мы не можем с ними взаимодействовать, мы можем только перебирать однотипные компоненты
да, это тот же объект по данным так один в один. Нет, ничто не мешает перебрать компоненты нужной сущности
>>79377
Я тебе больше скажу. ЕЦС это тот же ООП, а если по паттернам, так один в один.
> да, это тот же объект по данным так один в один.
Я тебе больше скажу. ЕЦС это тот же ООП, а если по паттернам, так один в один.
>>79438
Взятые с потолка критерии по которым умелый демагог может выписать, скажем рено из автомобилей.
> по разбиению данных на составляющие и связность логики
Взятые с потолка критерии по которым умелый демагог может выписать, скажем рено из автомобилей.
>>79377
Предлагаешь на слабо сделать три-в-ряд?
Как её избежать, если не получается разделить систему на части?
Это логично. Я не спорю, что младенца можно обучить ЕЦС и после этого он не сможет понять ООП, а любую задачу будет решать через ЕЦС, даже если это неэффективно. Непонятно только, зачем переобучать на ЕЦС тех, кто может решить задачу на ООП.
Эффективность в чём? В создании ста миллионов одинаковых сущностей, движущийся по одинаковой траектории? Или в возможности создать монстров из несовместимых компонентов?
Мешает. Мешает концепция "только прямой перебор списка компонентов одного типа". Потому что если ты будешь произвольно перебирать компоненты произвольной сущности, вся эта кэш-магия улетучится, останется только неудобный код.
>>79438
Почему нельзя скрыть всю ЕЦС магию под капотом движка, а программисту разрешить писать привычный ООП код с классами, экземплярами классов, свойствами, методами и т.д.? Все были бы довольны - и код понятный, и производительность высокая.
>вот из диванных переквалифицируешься в обычных разработчиков, тогда и поговорим
Предлагаешь на слабо сделать три-в-ряд?
>скорее всего была одна из типичных проблем - раздутия систем
Как её избежать, если не получается разделить систему на части?
>переходящие из ооп и не сумевшие перестроить парадигму в своей голове
Это логично. Я не спорю, что младенца можно обучить ЕЦС и после этого он не сможет понять ООП, а любую задачу будет решать через ЕЦС, даже если это неэффективно. Непонятно только, зачем переобучать на ЕЦС тех, кто может решить задачу на ООП.
>за ее эффективность
Эффективность в чём? В создании ста миллионов одинаковых сущностей, движущийся по одинаковой траектории? Или в возможности создать монстров из несовместимых компонентов?
>Нет, ничто не мешает перебрать компоненты нужной сущности
Мешает. Мешает концепция "только прямой перебор списка компонентов одного типа". Потому что если ты будешь произвольно перебирать компоненты произвольной сущности, вся эта кэш-магия улетучится, останется только неудобный код.
>>79438
Почему нельзя скрыть всю ЕЦС магию под капотом движка, а программисту разрешить писать привычный ООП код с классами, экземплярами классов, свойствами, методами и т.д.? Все были бы довольны - и код понятный, и производительность высокая.
Подскажите, как мне все-таки сделать сглаженные края у Polygon2D? У меня не выходит, как с обычными спрайтами юзнуть оутлайн шейдер.
Результатом должна стать такая граница перехода с помощью SimplexNoise между текстурами, как на скриншоте ниже.
Результатом должна стать такая граница перехода с помощью SimplexNoise между текстурами, как на скриншоте ниже.
>>79550
Самодельный шейдер нужно писать, у которого в самом простейшем случае логика такова:
1. Текстура 1
2. Текстура 2.
3. Нойз (монохромный, в один канал)
4. Функция фрагмента: Взять цвет пиксела нойза по текущим UV-координатам, взять число его яркости, смешать текстуры 1 и 2, используя взятое число как фактор, т.е. Если яркость 0,75, то пиксел текстуры 1 по этим координатам домножается на 0,75, а текстуры 2 на 0,25, затем полученные числа складываются и нормализуются до интервала 0..1 и результат подаётся на выход.
В более сложных случаях Ты делаешь 4 текстуры на каждый канал нойза, делаешь 4х-канальный нойз. И выводишь смесь из 4 текстур. Вместо нойза ещё делают 4хканальную маску, сплатмап так называемый. В аддоне террейн от Зилана например. Да и вообще, сплатмаппинг - это промышленный стандарт. Так что можешь копнуть сорцы Зилан-террейна и узнать, как там в шейдерах текстуры смешиваются.
Самодельный шейдер нужно писать, у которого в самом простейшем случае логика такова:
1. Текстура 1
2. Текстура 2.
3. Нойз (монохромный, в один канал)
4. Функция фрагмента: Взять цвет пиксела нойза по текущим UV-координатам, взять число его яркости, смешать текстуры 1 и 2, используя взятое число как фактор, т.е. Если яркость 0,75, то пиксел текстуры 1 по этим координатам домножается на 0,75, а текстуры 2 на 0,25, затем полученные числа складываются и нормализуются до интервала 0..1 и результат подаётся на выход.
В более сложных случаях Ты делаешь 4 текстуры на каждый канал нойза, делаешь 4х-канальный нойз. И выводишь смесь из 4 текстур. Вместо нойза ещё делают 4хканальную маску, сплатмап так называемый. В аддоне террейн от Зилана например. Да и вообще, сплатмаппинг - это промышленный стандарт. Так что можешь копнуть сорцы Зилан-террейна и узнать, как там в шейдерах текстуры смешиваются.
>>79567
Проблема в том, что смещение по uv, по пикселям и чему угодно не работает блеать. Не может шейдер взять текстуру полученную после обрезки изображения и сместить, например. Почему? А хуй его знает.
Проблема в том, что смещение по uv, по пикселям и чему угодно не работает блеать. Не может шейдер взять текстуру полученную после обрезки изображения и сместить, например. Почему? А хуй его знает.
>>79590
Матчасть учи. Ютуб полон туториалов, в которых всё прекрасно смещается. А у тебя почему-то не смещается.
> Почему? А хуй его знает.
Матчасть учи. Ютуб полон туториалов, в которых всё прекрасно смещается. А у тебя почему-то не смещается.
>>79599 (Del)
Выложить текстуру вдоль границы легко - это просто line2d. Альфаканал текстурой не потрогать.
Выложить текстуру вдоль границы легко - это просто line2d. Альфаканал текстурой не потрогать.
>>79597
Я приложил скрин, где нихуя не работает. Посмотри блять. Половину текстуры должно быть красноватой, половина простым цветом.
Я приложил скрин, где нихуя не работает. Посмотри блять. Половину текстуры должно быть красноватой, половина простым цветом.
>>79598 (Del)
Я тоже так понимаю. Печальный факт ещё в том, что взять текстуру экрана так же не помогает чет (
Я тоже так понимаю. Печальный факт ещё в том, что взять текстуру экрана так же не помогает чет (
>>79613 (Del)
Это я знаю. Но это какая-то залупа так-то. Мучить цпу созданием текстуры - бррр.
Это я знаю. Но это какая-то залупа так-то. Мучить цпу созданием текстуры - бррр.
>>79606
А я смотрел блять. А теперь ты посмотри, блять https://www.youtube.com/watch?v=CI3JZ-3cabg
> Посмотри блять.
А я смотрел блять. А теперь ты посмотри, блять https://www.youtube.com/watch?v=CI3JZ-3cabg
>>79620 (Del)
Всё я вкурил.
1. Есть область канвы.
2. Область делится полигоном на две части, внутреннюю и внешнюю.
3. По полигону отрисовывается шейп.
4. Снимается текстура.
5. В шейдере наподобие видеорилейтед эта текстура юзается, как фактор.
6. ПРОФИТ!
> Ты вообще не вкурил что анону нужно.
Всё я вкурил.
1. Есть область канвы.
2. Область делится полигоном на две части, внутреннюю и внешнюю.
3. По полигону отрисовывается шейп.
4. Снимается текстура.
5. В шейдере наподобие видеорилейтед эта текстура юзается, как фактор.
6. ПРОФИТ!
>>79626
Ниче не понял. Покажи как сделать/Кинь тестовый проект.
Я только что ебался с SCREEN_TEXTURE наслаивая их с помощью ноды сверху. Нихуя не вышло, конечно же. Но уже было получше.
Потом попытался сделать вокруг полигона колбасу в виде line2d. Нихуя не вышло, т.к. у лайна своя текстура и они расходятся. А если красить сверху, то не ясно как сделать рипит нормально.
Сижу бомблю.
>>79616 (Del)
Ну тогда осталось придумать как её нарисовать.
Ниче не понял. Покажи как сделать/Кинь тестовый проект.
Я только что ебался с SCREEN_TEXTURE наслаивая их с помощью ноды сверху. Нихуя не вышло, конечно же. Но уже было получше.
Потом попытался сделать вокруг полигона колбасу в виде line2d. Нихуя не вышло, т.к. у лайна своя текстура и они расходятся. А если красить сверху, то не ясно как сделать рипит нормально.
Сижу бомблю.
>>79616 (Del)
Ну тогда осталось придумать как её нарисовать.
216 Кб, 990x677>>79629
Вот примерный эффект которого я ожидаю, только то, что SIMPLEX_NOISE, как и любая другая текстура не бесконечен и в видеопамять придется передавать огромные битмапные рисунки - это грустн.
Вот примерный эффект которого я ожидаю, только то, что SIMPLEX_NOISE, как и любая другая текстура не бесконечен и в видеопамять придется передавать огромные битмапные рисунки - это грустн.
>>79036 (OP)
Вечер в хату. Поддержку .blend файлов завезли? Или пердолиться так же надо?
Вечер в хату. Поддержку .blend файлов завезли? Или пердолиться так же надо?
128 Кб, 1120x563>>79672
Годотский уклад един!
А кто спрашивает?
Бросаю тебе скриншот оп-поста под ноги. Твои действия?
> Вечер в хату.
Годотский уклад един!
> Поддержку .blend файлов завезли?
А кто спрашивает?
> Или пердолиться так же надо?
Бросаю тебе скриншот оп-поста под ноги. Твои действия?
>>79652
У них работает иначе. Они настаивают лайн2д по периметру полигон2д. Но! Лайн2д обрабатывается шейдером потайлово, а не будто это линия, и текстура лайн2д расходится с текстурой полигон 2д. В общем, это костыльный говноспособ. Если ты знаешь как эти костыли обходить, скажи.
У них работает иначе. Они настаивают лайн2д по периметру полигон2д. Но! Лайн2д обрабатывается шейдером потайлово, а не будто это линия, и текстура лайн2д расходится с текстурой полигон 2д. В общем, это костыльный говноспособ. Если ты знаешь как эти костыли обходить, скажи.
178 Кб, 972x730>>79643
Который с шейдерами чет не очень работает.
Который с шейдерами чет не очень работает.
73 Кб, 1238x397>>79652
Отличный ответ. Вот что ты мне предлагаешь.
Отличный ответ. Вот что ты мне предлагаешь.
>>79733 (Del)
Так смешение это не то. Смешение это когда ты знаешь 2 текстуры. А я знаю только одну - для текущего полигона. Я должен полигон засмузить так, чтобы лежащий под ним такой же полигон просвечивал через альфу.
Так смешение это не то. Смешение это когда ты знаешь 2 текстуры. А я знаю только одну - для текущего полигона. Я должен полигон засмузить так, чтобы лежащий под ним такой же полигон просвечивал через альфу.
>>79740 (Del)
А если пепе будет немного зарепичен?
А если пепе будет немного зарепичен?
Годаны, подскажите, всё ли я правильно делаю. Сейчас делаю "стареющие" предметы. Например, сырое мясо, которое должно со временем тухнуть. Чтобы правильно отображать его в инвентаре, я для предметов создаю стадии старения, каждой стадии приписан тайминг, название, иконка. И у каждого предмета есть время создания. Соответственно, при открытии инвентаря, по всему списку предметов пробегается цикл и вычисляет состояние предмета, юзая текущее время минус время создания, если стадии старения имеются. И соответственно вычислениям предметы переименовываются. Свойства предметов приаттачены к массиву стадий. Если предмет нестареющий, у него просто одна стадия по умолчанию. Соответственно, если стадия поменялась, меняются и свойства. Типа, свежее мясо +1, тухлое -10, ну ты понел.
Всё ли я правильно делаю или есть более элегантные способы?
Всё ли я правильно делаю или есть более элегантные способы?
>>79744
У тебя должен быть пул предметов, по которым ты бегаешь и стареешь. Неважно когда. А уже иконка подтягивает из объекта его старение и отрисовывает.
У тебя должен быть пул предметов, по которым ты бегаешь и стареешь. Неважно когда. А уже иконка подтягивает из объекта его старение и отрисовывает.
188 Кб, 1225x864Ебался пол дня. Лучший результат. Жаль только альфа канал отсутствует в SCREEN_TEXTURE, что делает мой геморрой бесполезным. Чет годот не тянет такую задачу.
>>79744
старение не должно быть связано с открытием инвентаря
старение не должно быть связано с открытием инвентаря
>>79751 (Del)
С рипит текстурой у меня нихуя не получается по UV определить границы Polygon2D и соответственно сделать её прозрачной в самом Polygon2D.
1) можно попробовать ещё передать тайл без рипита и отрипитить его внутри шейдера, тем самым упростив поиск по UV границ Polygon2D
2) попробовать сделать рисовалку, когда я рисую по битовой маске, а она отображается в виде текстуры. Вопрос лишь в том, как это все нарисовать динамически, когда у меня есть только полигон.
3) можно попробовать поискать какие-нибудь там world-координаты во фрагментном шейдере и попробовать играть от них. Но судя по сообщениям в гугле - ничего не работает.
4) забить хер и юзать ноисы генерящиеся в шейдере?
С рипит текстурой у меня нихуя не получается по UV определить границы Polygon2D и соответственно сделать её прозрачной в самом Polygon2D.
1) можно попробовать ещё передать тайл без рипита и отрипитить его внутри шейдера, тем самым упростив поиск по UV границ Polygon2D
2) попробовать сделать рисовалку, когда я рисую по битовой маске, а она отображается в виде текстуры. Вопрос лишь в том, как это все нарисовать динамически, когда у меня есть только полигон.
3) можно попробовать поискать какие-нибудь там world-координаты во фрагментном шейдере и попробовать играть от них. Но судя по сообщениям в гугле - ничего не работает.
4) забить хер и юзать ноисы генерящиеся в шейдере?
32 Кб, 680x633>>79758 (Del)
Да, работает спам текстурки. Но есть проблема, если значения отрицательные, то случается бага.
Да, работает спам текстурки. Но есть проблема, если значения отрицательные, то случается бага.
>>79760 (Del)
не, там abs(UV) надо сделать. В общем не суть. Думаю пока что как смазать нормально границы. Т.к. в твоем примере границы смазываются альфой, но острые углы остаются. Это уродливо.
не, там abs(UV) надо сделать. В общем не суть. Думаю пока что как смазать нормально границы. Т.к. в твоем примере границы смазываются альфой, но острые углы остаются. Это уродливо.
>>79761
Ну и количество точек хотелось бы динамическое.
Ну и количество точек хотелось бы динамическое.
>>79794
Стандартные пок-пок-пок. Из-за того, что в годоте нет массивов и результат работы шейдера не передать в другой шейдер, а лучше самому себе, приходится страдать херней, пока разные умники говорят тебе, что ты не тянешь.
Стандартные пок-пок-пок. Из-за того, что в годоте нет массивов и результат работы шейдера не передать в другой шейдер, а лучше самому себе, приходится страдать херней, пока разные умники говорят тебе, что ты не тянешь.
Анончик скажи пожалуйста, а на этом движке на Андроиде можно игру сделать?
>>80077 (Del)
Да, я по поводу сделать игру на Андроиде.
Да, я по поводу сделать игру на Андроиде.
>>80077 (Del)
Не надо ничего эмулировать, есть нативные APK билды, но они пока неюзабельны без мышки, да и с мышкой тоже: >>777531 →
>эмуль линукса
Не надо ничего эмулировать, есть нативные APK билды, но они пока неюзабельны без мышки, да и с мышкой тоже: >>777531 →
>>80077 (Del)
Так а с чего начать чтобы понять как делать игру на андроид, на годоте? В основной документации на сайте это есть?
Я вот годот в Стиме скачал, вот открыл документацию
Так а с чего начать чтобы понять как делать игру на андроид, на годоте? В основной документации на сайте это есть?
Я вот годот в Стиме скачал, вот открыл документацию
>>79036 (OP)
Прохожу мимо треда и каждый раз глаз цепляется за картинку в ОП-посте, какая красивая девочка. Что мне делать, приходится долго отцеплять?
Прохожу мимо треда и каждый раз глаз цепляется за картинку в ОП-посте, какая красивая девочка. Что мне делать, приходится долго отцеплять?
>>80204
Двачую, годот смекнули как надо заманивать людей.
Двачую, годот смекнули как надо заманивать людей.
Годотаны, как лучше поступать, когда от одного суперкласса должны наследоваться два объекта с сильно разными спрайтшитами? Когда я в редакторе ковыряюсь с наследником, постоянно что-то просачивается в поля суперкласса, и всё преврящается в говно, особенно анимация.
Может я тупо не понимаю, когда открыт таймлайн для суперкласса, а когда для наследника, и это я дебил? Или там действительно есть какие-то тонкости?
Может я тупо не понимаю, когда открыт таймлайн для суперкласса, а когда для наследника, и это я дебил? Или там действительно есть какие-то тонкости?
>>80237
Не использовать наследование. Суперкласс пусть занимается общим функционалом, а функционал анимации подключай компонентом в каждый сабкласс свой, в том числе автоматически, при инициализации сабкласса пусть ищет свою ноду с уникальными анимациями и подгружает себе в чайлды. Сделай это сейчас, меньше времени потеряешь.
> как лучше поступать
Не использовать наследование. Суперкласс пусть занимается общим функционалом, а функционал анимации подключай компонентом в каждый сабкласс свой, в том числе автоматически, при инициализации сабкласса пусть ищет свою ноду с уникальными анимациями и подгружает себе в чайлды. Сделай это сейчас, меньше времени потеряешь.
>>80287
Да, наверное так и сделаю. Надо будет тогда побольше копипастного кода оформить отдельными методами, если там больше трех строчек.
Да, наверное так и сделаю. Надо будет тогда побольше копипастного кода оформить отдельными методами, если там больше трех строчек.
>>80313
Оче рекомендую заранее набрасывать хоть какой-то проект-архитектуру-схему. Чтобы в целом видеть, как и что у тебя с чем должно взаимодействовать. А при реализации придерживаться архитектуры. А если при реализации приходится переделывать архитектуру - вносить изменения в схему. Лично я не могу удерживать всё в голове, а потом получается так, что у меня горы кода и хуй проссышь, что с чем взаимодействует. Если у тебя такой проблемы нет, то конечно забей на проектирование.
Оче рекомендую заранее набрасывать хоть какой-то проект-архитектуру-схему. Чтобы в целом видеть, как и что у тебя с чем должно взаимодействовать. А при реализации придерживаться архитектуры. А если при реализации приходится переделывать архитектуру - вносить изменения в схему. Лично я не могу удерживать всё в голове, а потом получается так, что у меня горы кода и хуй проссышь, что с чем взаимодействует. Если у тебя такой проблемы нет, то конечно забей на проектирование.
>>79036 (OP)
Я хочу сделать менюбар, поиск не помог. Такое возможно и как?
Я хочу сделать менюбар, поиск не помог. Такое возможно и как?
>>80396 (Del)
Благодарю.
Ещё вопрос, хочу для тренировки сделать сапёра, переношу из финформс, знаю, что есть tilemaps, нашёл как определять которая над которой из ячеек была нажата кнопка мыши. Есть ли какие-то сложности с генерацией поля из тайлов?
Благодарю.
Ещё вопрос, хочу для тренировки сделать сапёра, переношу из финформс, знаю, что есть tilemaps, нашёл как определять которая над которой из ячеек была нажата кнопка мыши. Есть ли какие-то сложности с генерацией поля из тайлов?
>>80411 (Del)
Понял.
Ещё вопрос, а как обычно делается универсальная единица размера спрайта? Мне нужно как например при использовании OpenGL, где я я такую вычислял в пикселях как отношение высоты к числу 18, а дальше везде такой размер использовал. Это я хочу сделать чтобы разрешение текстуры спрайта могло быть любым.
Понял.
Ещё вопрос, а как обычно делается универсальная единица размера спрайта? Мне нужно как например при использовании OpenGL, где я я такую вычислял в пикселях как отношение высоты к числу 18, а дальше везде такой размер использовал. Это я хочу сделать чтобы разрешение текстуры спрайта могло быть любым.
Здрасте. Скажите, а как в Годоте сделать двойную буферизацию? То есть, чтобы я сначала через скрипт сделал ряд изменений, и только потом весь результат отобразился на экране одновременно, а не по очереди, по мере выполнения скрипта.
>>80427 (Del)
Понял, благодарю за ответы
Понял, благодарю за ответы
>>80396 (Del)
Досмотрел до 3:17 и скажу, что я бы сделал себе ноду-хелпер, которая бы ставилась в чайлды менюбаттону и у себя в ready добавляла бы элемент меню со своим именем, и с колбэком, и с иконкой и с тем, что ещё понадобится, и получил бы менюподобную иерархию у себя в редакторе, а ещё такая нода-хелпер могла бы перебирать паренты парента пока не встретит менюбаттон и запоминать иерархию и пытаться воспроизвести аналогичную, и так я бы сделал многоуровневое меню. Смотрю дальше.
Досмотрел до 3:17 и скажу, что я бы сделал себе ноду-хелпер, которая бы ставилась в чайлды менюбаттону и у себя в ready добавляла бы элемент меню со своим именем, и с колбэком, и с иконкой и с тем, что ещё понадобится, и получил бы менюподобную иерархию у себя в редакторе, а ещё такая нода-хелпер могла бы перебирать паренты парента пока не встретит менюбаттон и запоминать иерархию и пытаться воспроизвести аналогичную, и так я бы сделал многоуровневое меню. Смотрю дальше.
>>80480
Досмотрел. Этому видосу джва года и за это время афтор вырос от перебора элементов по строковым именам до собственного аддона диалоджик. Это успех!
> Смотрю дальше.
Досмотрел. Этому видосу джва года и за это время афтор вырос от перебора элементов по строковым именам до собственного аддона диалоджик. Это успех!
9 Кб, 245x250Как обратиться к этому масштабу? Оно есть у всех объектов если что. Цель уменьшить масштаб tilemap через скрипт
>>80489 (Del)
Да, только что получилось, функцию которая это делала не вызывал.
Да, только что получилось, функцию которая это делала не вызывал.
>>79036 (OP)
Благодарю всех за подсказки, движок очень понравился. Работает быстрее WinForms
Благодарю всех за подсказки, движок очень понравился. Работает быстрее WinForms
>>80555 (Del)
Нет ничего более мерзкого и безвкусного, чем первое триде времён первой соньки. Делал бы стилизованное лоуполи - был бы от меня почёт и уважуха. Впрочем, кто я такой? Обычный безыгорный пиздабол с двачей. А тысячи мух не могут ошибаться, ностальгирующие бумеры раскупят это поделие, как горячие пирожки. Хррр-тьфу!
> В чем он не прав?
Нет ничего более мерзкого и безвкусного, чем первое триде времён первой соньки. Делал бы стилизованное лоуполи - был бы от меня почёт и уважуха. Впрочем, кто я такой? Обычный безыгорный пиздабол с двачей. А тысячи мух не могут ошибаться, ностальгирующие бумеры раскупят это поделие, как горячие пирожки. Хррр-тьфу!
>>80556
По мне так для инди разрабов количество поликов на уровне HL2 -> ME2 это более чем отлично, при условии, что возможно, ну и разумеется ZBrush + Substnace
Ща инструменты развились на отлично
По мне так для инди разрабов количество поликов на уровне HL2 -> ME2 это более чем отлично, при условии, что возможно, ну и разумеется ZBrush + Substnace
Ща инструменты развились на отлично
>>80556
Да ладно, делали бы в стиле Megaman Legends или крэша - ни одной претензии к ним бы не было. Я вот, например, пытаюсь постичь этот стиль, хотя пока получается не особо. Но сейчас вошла в моду эта вырвиглазная лоуфай пс1 хоррор демо диск параша, и все бездари тут же за нее ухватились. С другой стороны, инди пуксель арт в свое время тоже у всех вызывал рвотные порывы, зато сейчас индюки намастрячились делать пуксель арт чуть ли не лучше, чем у СНК в лучшие годы. Ну то есть понятное дело, что говно никуда не делось, но оно заняло свое заслуженное место возле параши, сейчас я не вижу распиаренных проектов с макаронными человечками и пикселями на полэкрана.
>первое триде времён первой соньки
Да ладно, делали бы в стиле Megaman Legends или крэша - ни одной претензии к ним бы не было. Я вот, например, пытаюсь постичь этот стиль, хотя пока получается не особо. Но сейчас вошла в моду эта вырвиглазная лоуфай пс1 хоррор демо диск параша, и все бездари тут же за нее ухватились. С другой стороны, инди пуксель арт в свое время тоже у всех вызывал рвотные порывы, зато сейчас индюки намастрячились делать пуксель арт чуть ли не лучше, чем у СНК в лучшие годы. Ну то есть понятное дело, что говно никуда не делось, но оно заняло свое заслуженное место возле параши, сейчас я не вижу распиаренных проектов с макаронными человечками и пикселями на полэкрана.
>>80560 (Del)
как ни странно, но тут очень удачно сделанное лоуполи с удачным же аудиорядом, если авторы случайно попали и там и там, то им крупно повезло
https://store.steampowered.com/app/252630/Eldritch_Reanimated/
> А бывает вообще стилизованное лоуполи про какой-то мрачняк? Обычно там зеленые деревца от которых уже тошнит.
как ни странно, но тут очень удачно сделанное лоуполи с удачным же аудиорядом, если авторы случайно попали и там и там, то им крупно повезло
https://store.steampowered.com/app/252630/Eldritch_Reanimated/
1,9 Мб, 1200x672>>80561
Я прямо щас смотрю лецплеи Куплинова с относительно свежей игрой про игру в пиксельные карты с лютым сотоной. Прям пиксель арт приксельартушный.
> сейчас я не вижу распиаренных проектов с макаронными человечками и пикселями на полэкрана
Я прямо щас смотрю лецплеи Куплинова с относительно свежей игрой про игру в пиксельные карты с лютым сотоной. Прям пиксель арт приксельартушный.
>>80562
Пиксельные текстуры говно. Рыганул бы афтору в ебало тугой струёй. Таков уж мой вкус, без обид, пикселеёбы.
> тут очень удачно сделанное лоуполи
Пиксельные текстуры говно. Рыганул бы афтору в ебало тугой струёй. Таков уж мой вкус, без обид, пикселеёбы.
>>80566 (Del)
так смотри на монстров и предметы как там сделали и как их еще покрасили толково, кубы там просто особенность игры, речь про стиль
> Кубы немного не то
так смотри на монстров и предметы как там сделали и как их еще покрасили толково, кубы там просто особенность игры, речь про стиль
>>80570 (Del)
ссылочку на игру скинь, где такое применяют (не то, где пиксельными шейдерами только)
ссылочку на игру скинь, где такое применяют (не то, где пиксельными шейдерами только)
>>80566 (Del)
Именно такое.
>>80556-кун
> я думал под стилизованным лоуполи подразумевается что-то такое
Именно такое.
>>80556-кун
Сборки 4 версии юзабельные? Автолоды и оклюшн кулинг работает?
>>80563
Ты дебил, я не говорил тебе, что пикселей нет, я говорил, что сейчас уровень выше стал. Твой пик явно получше выглядит, чем какой-нибудь VVVVV, не находишь?
Ты дебил, я не говорил тебе, что пикселей нет, я говорил, что сейчас уровень выше стал. Твой пик явно получше выглядит, чем какой-нибудь VVVVV, не находишь?
344 Кб, 820x820>>80566 (Del)
Как же я этот бездушный стиль ненавижу. Рака яиц всем, кто его использует. Такая же параша, как Globohomo Corporate Style.
Как же я этот бездушный стиль ненавижу. Рака яиц всем, кто его использует. Такая же параша, как Globohomo Corporate Style.
>>80600
Двачую.
Прям выворачивает от подобной хуйни и хочется найти и убить того, кто так делает. Не жестоко, а просто устранить это существо, чтобы такого больше не было.
Двачую.
Прям выворачивает от подобной хуйни и хочется найти и убить того, кто так делает. Не жестоко, а просто устранить это существо, чтобы такого больше не было.
>>80606
Не, в теории можно даже бестекстурное лоу-поли сделать годно. Вот тебе пример с форчика:
https://store.steampowered.com/app/1347550/Tiny_Combat_Arena/
Но здесь-то они не стараются, тупо делают на отъебись, бездари.
Не, в теории можно даже бестекстурное лоу-поли сделать годно. Вот тебе пример с форчика:
https://store.steampowered.com/app/1347550/Tiny_Combat_Arena/
Но здесь-то они не стараются, тупо делают на отъебись, бездари.
>>80566 (Del)
Я думал этот стиль устарел лет как 8
Я думал этот стиль устарел лет как 8
102 Кб, 1116x1018>>80600
Ну так потому что этот стиль ассоциируется с бездушными поделками из гуглплей, сделанные из скаченных ассетов лишь для выкачивания денег.
Ну так потому что этот стиль ассоциируется с бездушными поделками из гуглплей, сделанные из скаченных ассетов лишь для выкачивания денег.
32 Кб, 600x401>>80643
Настоящий стиль не устаревает. Если "стиль" устарел, то не стиль это вовсе, а китч.
> стиль устарел
Настоящий стиль не устаревает. Если "стиль" устарел, то не стиль это вовсе, а китч.
>>80643
Имплаин он хоть когда-то не был ебаной парашей.
Имплаин он хоть когда-то не был ебаной парашей.
>>80727 (Del)
Спасибо за пост. Было познавательно.
Спасибо за пост. Было познавательно.
Так а как в итоге то делать на годоте андроид игру?
Создавать проект как обычно, делать, а потом экспортировать? А как экспорт проводится?
Создавать проект как обычно, делать, а потом экспортировать? А как экспорт проводится?
>>80844 (Del)
Рано ещё, ИМХО.
Рано ещё, ИМХО.
>>80856 (Del)
Хуан зря несколько лет жизни проебал на эту систему, нужно было допиливать лайтмапы и ждать карты с ртх как юнити
>SDFGI
Хуан зря несколько лет жизни проебал на эту систему, нужно было допиливать лайтмапы и ждать карты с ртх как юнити
>>80867
При том что она к железу очень требовательная и картинку выдает не хорошую. Хотя опять же, сколько ждать, когда средней станет какая-нибудь хорошая карта с лучами
>SDFGI
>несколько лет жизни проебал на эту систему
При том что она к железу очень требовательная и картинку выдает не хорошую. Хотя опять же, сколько ждать, когда средней станет какая-нибудь хорошая карта с лучами
>>80906
Да я тестил, делают годно и вроде пекутся быстро и красиво. Но он их пытался внедрять еще в годот2, и в 3 и все бросал, тратя время на свои революционные реалтайм ги. Воксельные пробы говно, sdfgi полуговно, зря он это затеял, эксперименты это удел больших команд. Он писал, что уже знает как улучшить sdfgi, но типо это случится только в 4.1, но поди опять пиздит, посмотрим
Да я тестил, делают годно и вроде пекутся быстро и красиво. Но он их пытался внедрять еще в годот2, и в 3 и все бросал, тратя время на свои революционные реалтайм ги. Воксельные пробы говно, sdfgi полуговно, зря он это затеял, эксперименты это удел больших команд. Он писал, что уже знает как улучшить sdfgi, но типо это случится только в 4.1, но поди опять пиздит, посмотрим
>>79036 (OP)
Стандартный вопрос, на который я не смог найти ответа.
Есть кнопка текстурная в ноде А, есть игра в ноде БЭ.
Как мне получить состояние, что эта кнопка нажата в ноде БЭ?
Про набор стандартных методов в узлах знаю, но не хочу городить велосипед в виде дополнительных bool значений.
Стандартный вопрос, на который я не смог найти ответа.
Есть кнопка текстурная в ноде А, есть игра в ноде БЭ.
Как мне получить состояние, что эта кнопка нажата в ноде БЭ?
Про набор стандартных методов в узлах знаю, но не хочу городить велосипед в виде дополнительных bool значений.
>>81194 (Del)
>>81195 (Del)
Благодарю за ответы, в итоге выбрал вариант использования дополнительной переменной bool и обращение к ней. Спрашивал, потому что думал, что есть некий другой, более простой вариант.
И да, я не уточнил про ноды - в моём случае нода с кнопкой находится не в основной ноде где игра запускается, а отдельная заготовка, наверное это можно ещё назвать префабом, экземпляр которого уже и создаётся в основной ноде.
>>81195 (Del)
Благодарю за ответы, в итоге выбрал вариант использования дополнительной переменной bool и обращение к ней. Спрашивал, потому что думал, что есть некий другой, более простой вариант.
И да, я не уточнил про ноды - в моём случае нода с кнопкой находится не в основной ноде где игра запускается, а отдельная заготовка, наверное это можно ещё назвать префабом, экземпляр которого уже и создаётся в основной ноде.
12 Кб, 334x137>>81199 (Del)
Вопс, ларчик просто открывался, ахахаха. Изначально я вызывал метод с таким названием, ожидая, что он есть по умолчанию, но после экспериментов и взора на англ доки, выяснилось, что таки есть переменная, отлично.
Вопс, ларчик просто открывался, ахахаха. Изначально я вызывал метод с таким названием, ожидая, что он есть по умолчанию, но после экспериментов и взора на англ доки, выяснилось, что таки есть переменная, отлично.
>>81131 (Del)
Что по фпсикам?
Что по фпсикам?
>>81326 (Del)
У него там игры уровня твг же, что на них можно так подняться?
У него там игры уровня твг же, что на них можно так подняться?
>>79036 (OP)
Господи, какая же шняга этот годот. Я правда пытался мириться со сломанным функционалом (типо навигации, где без костылей хуй она нормально заработает), но сегодня меня доебало.
Я надеюсь движок станет лучше и пофиксит баги четырехлетней давности, которые реально мешают делать нормально без костылей.
Попробую перестать быть годо-дауном и вкачусь во что-нибудь ещё.
Да, пошёл я нахуй, просто мне больше некуда выговориться
Господи, какая же шняга этот годот. Я правда пытался мириться со сломанным функционалом (типо навигации, где без костылей хуй она нормально заработает), но сегодня меня доебало.
Я надеюсь движок станет лучше и пофиксит баги четырехлетней давности, которые реально мешают делать нормально без костылей.
Попробую перестать быть годо-дауном и вкачусь во что-нибудь ещё.
Да, пошёл я нахуй, просто мне больше некуда выговориться
>>81431
ЗЫ: Я ни в коем случае не говорю что пользователи движка дауны. Это, скорее, самоирония (типо не могу выучить нормальные языки, потому юзаю гдскрипт)
ЗЫ: Я ни в коем случае не говорю что пользователи движка дауны. Это, скорее, самоирония (типо не могу выучить нормальные языки, потому юзаю гдскрипт)
>>80624
Я бы это представил в виде кривой обучения.
Просто в какой-то момент понимаешь, что вот это, это и это не надо так делать, здесь лучше упростить, и выходит, что на всё хватает gdscript.
>>80600
Для многих графон и геймплей - два разных конца одной палки. Согнуть палку, чтобы получить обе штуки в одном месте, может не каждый.
Я бы это представил в виде кривой обучения.
Просто в какой-то момент понимаешь, что вот это, это и это не надо так делать, здесь лучше упростить, и выходит, что на всё хватает gdscript.
>>80600
Для многих графон и геймплей - два разных конца одной палки. Согнуть палку, чтобы получить обе штуки в одном месте, может не каждый.
>>81329
Ну, по логике, можно найти привлекающий концепт так, а потом его развивать.
Ну, по логике, можно найти привлекающий концепт так, а потом его развивать.
Есть сцена-уровень, на которую можно попасть с разных сторон через двери. Скрипт уровня спавнит игрока на onready.
Игрока нужно спавнить перед той дверью, через которую он зашел.
Как бы вы решили эту задачу? Передавать номер нужной двери через автолоад?
Игрока нужно спавнить перед той дверью, через которую он зашел.
Как бы вы решили эту задачу? Передавать номер нужной двери через автолоад?
>>81489
Через конфиги.
Каждая сущность в игре при своей загрузке поднимает из хранилища свой конфиг в удобном тебе формате и читает данные из него и конфигурирует себя.
В твоём конкретном случае в конфиге должен быть как минимум флаг ИгрокВышелЧерезДверь=3 означающий собственно, что игрок вышел через дверь 3. Либо еще универсальнее, каждой двери соответствует спавн-поинт, через который игрок спавнится на уровень. Значит параметр в конфиге будет LastSpawnPoint=Door3 тут, как видим, заспавниться игрок может, как у деври, так и у окна, например, или в дымоходе, как Санта Мороз.
Все конфиги хранятся в сейв-файле.
При выгрузке локации, если игрок просто закрывает игру, этот параметр не записывается (стирается, обнуляется). Если игрок покинул локацию через один из телепортов, параметр записывается, локация выгружается.
Сейв-данные - это синглтон, открывается при старте/загрузке игры, постоянно пишется в память при изменении параметров игры (как загрузка и выгрузка локаций, вскрытие сундуков, убийства мобов) а при сохранении (хоть по точкам, хоть вручную по Ф5) сейв-данные сразу готовы и моментально сбрасываются в файл.
Соответственно, при загрузке всё в обратном направлении.
И не забудь, описывая менеджер загрузки, введи блокировки на модификацию данных при осуществляющемся сохранении/загрузке, чтобы не получилось так, что пока ты сохраняешься, половина данных уже переписалась. Нет. Как только активируется сейв, всё, данные блокируются и слепок состояния игры записывается в неизменном виде.
Так же этот подход идеально применим к быстрым загрузкам, например, когда игрока ваншотает босс, чтобы не грузиться долго из сейв-файла, в памяти висит слепок сейв-данных перед боссом. И моментально разворачивается в "продакшон".
Через конфиги.
Каждая сущность в игре при своей загрузке поднимает из хранилища свой конфиг в удобном тебе формате и читает данные из него и конфигурирует себя.
В твоём конкретном случае в конфиге должен быть как минимум флаг ИгрокВышелЧерезДверь=3 означающий собственно, что игрок вышел через дверь 3. Либо еще универсальнее, каждой двери соответствует спавн-поинт, через который игрок спавнится на уровень. Значит параметр в конфиге будет LastSpawnPoint=Door3 тут, как видим, заспавниться игрок может, как у деври, так и у окна, например, или в дымоходе, как Санта Мороз.
Все конфиги хранятся в сейв-файле.
При выгрузке локации, если игрок просто закрывает игру, этот параметр не записывается (стирается, обнуляется). Если игрок покинул локацию через один из телепортов, параметр записывается, локация выгружается.
Сейв-данные - это синглтон, открывается при старте/загрузке игры, постоянно пишется в память при изменении параметров игры (как загрузка и выгрузка локаций, вскрытие сундуков, убийства мобов) а при сохранении (хоть по точкам, хоть вручную по Ф5) сейв-данные сразу готовы и моментально сбрасываются в файл.
Соответственно, при загрузке всё в обратном направлении.
И не забудь, описывая менеджер загрузки, введи блокировки на модификацию данных при осуществляющемся сохранении/загрузке, чтобы не получилось так, что пока ты сохраняешься, половина данных уже переписалась. Нет. Как только активируется сейв, всё, данные блокируются и слепок состояния игры записывается в неизменном виде.
Так же этот подход идеально применим к быстрым загрузкам, например, когда игрока ваншотает босс, чтобы не грузиться долго из сейв-файла, в памяти висит слепок сейв-данных перед боссом. И моментально разворачивается в "продакшон".
>>81509 (Del)
Если говорить совсем технически, то в игре с отдельными локациями вообще корректно говорить не о дверях, а о телепортах, каждый телепорт соединяет две точки, входа и выхода. В таком виде система никак не ограничивает девелоперов в полёте фантазии. Два взаимных телепорта = дверь. Если надо подменить локацию, после выхода из неё (например, подставить сгоревшую, ограбленную, или захваченную инопланетянами) то в игровой логике происходит переключение всех телепортов, ведущих в эту локацию на её модифицированный вариант. Такое навскидку часто практикуется у джастворкса всея Земли, Тодда Говарда.
В этом случае следует позаботиться об организации данных в сейве так, чтобы можно было скармливать файлу (или его инстансу в оперативке) модифицирующие запросы. Необязательно прям СУБД организовывать, разумеется, но минимально матчасть желательно знать. Чтобы по желанию девелопера можно было хотя бы циклом пробежаться по сейву и опросить все содержащиеся там объекты "телепорт", если точка спавна относится к локации = локация_несгоревшая, то точка спавна = локация_сгоревшая.координаты.
И тут опять же, внимательный девелопер наперёд позаботится о том, чтобы точки телепортов хранились в формате: уникальный_айди_локации.координаты даже если телепорт внутренний, локальный. Потом по сюжету понадобится, а нихуя нельзя, придётся городить огород из кучи вызовов.
Вообще, мне нравится организация данных в нет-иммёрс, который беседка перекупила у каких-то своих корешей. Там втупую все объекты списком хранятся. Но иногда втупую - это умнее всего. Плоский список перебирается одним циклом. Ставишь лоадскрин и не паришься. Или, если хочется париться, ставишь блокировку и в отдельном потоке шерстишь. Любые модные оптимизации, если потребуется, прекрасно юзают плоский список в качестве сырых данных, формируя из них хоть деревья, хоть что.
Поправьте, если ошибаюсь, годаны.
Если говорить совсем технически, то в игре с отдельными локациями вообще корректно говорить не о дверях, а о телепортах, каждый телепорт соединяет две точки, входа и выхода. В таком виде система никак не ограничивает девелоперов в полёте фантазии. Два взаимных телепорта = дверь. Если надо подменить локацию, после выхода из неё (например, подставить сгоревшую, ограбленную, или захваченную инопланетянами) то в игровой логике происходит переключение всех телепортов, ведущих в эту локацию на её модифицированный вариант. Такое навскидку часто практикуется у джастворкса всея Земли, Тодда Говарда.
В этом случае следует позаботиться об организации данных в сейве так, чтобы можно было скармливать файлу (или его инстансу в оперативке) модифицирующие запросы. Необязательно прям СУБД организовывать, разумеется, но минимально матчасть желательно знать. Чтобы по желанию девелопера можно было хотя бы циклом пробежаться по сейву и опросить все содержащиеся там объекты "телепорт", если точка спавна относится к локации = локация_несгоревшая, то точка спавна = локация_сгоревшая.координаты.
И тут опять же, внимательный девелопер наперёд позаботится о том, чтобы точки телепортов хранились в формате: уникальный_айди_локации.координаты даже если телепорт внутренний, локальный. Потом по сюжету понадобится, а нихуя нельзя, придётся городить огород из кучи вызовов.
Вообще, мне нравится организация данных в нет-иммёрс, который беседка перекупила у каких-то своих корешей. Там втупую все объекты списком хранятся. Но иногда втупую - это умнее всего. Плоский список перебирается одним циклом. Ставишь лоадскрин и не паришься. Или, если хочется париться, ставишь блокировку и в отдельном потоке шерстишь. Любые модные оптимизации, если потребуется, прекрасно юзают плоский список в качестве сырых данных, формируя из них хоть деревья, хоть что.
Поправьте, если ошибаюсь, годаны.
>>81509 (Del)
>>81511
Спиздил код из документации, немного поправил. Все верно сделано?
Сейчас я просто в редакторе выбираю сцену которую надо телепортироваться, и указываю номер портала на этой сцене. Я вот думаю что когда локаций будет несколько десятков.
>>81511
Спиздил код из документации, немного поправил. Все верно сделано?
Сейчас я просто в редакторе выбираю сцену которую надо телепортироваться, и указываю номер портала на этой сцене. Я вот думаю что когда локаций будет несколько десятков.
29 Кб, 763x368>>81521
Вот так делаю
>Сейчас я просто в редакторе выбираю сцену которую надо телепортироваться, и указываю номер портала на этой сцене
Вот так делаю
>>81521
Нет. Не совсем. У тебя телепорт занимается сменой сцен. Это вероятно приведёт к путанице в дальнейшем, когда сцены будут менять хаотично разные наборы объектов и твой код обрастёт кучей костылей, запрещающих менять сцены в одних случаях, разрешать в других. И эта мешанина костылей будет расти как снежный ком, пока в один момент ты не осознаешь, что игра настолько кривая, что ты не можешь добавить нужный функционал, потому что придётся переписывать 100500 строк кода в разных местах, причем, как только ты начнёшь переписывать в одном месте, игра сломается и не будет работать, пока не перепишешь всё. И всё это время тебе придётся ебашить код без возможности проверить его на ошибки. Потому что игра не работает.
Телепорт должен только посылать сигналы о том, что в него зашёл игрок. Сигналы телепортов принимает единый менеджер сцен и меняет сцены, сообразно данным, переданным из телепорта. Обдумай этот подход. Это композитный подход с отношением к контенту как к данным. Известен как DOD, ECS, фанаты этого подхода видят только обертку не понимая сути, пишут плагины для реализации этого подхода в годоте. Но если открыть глаза, ты увидишь, что в годоте всё уже организовано для реализации систем, сущностей, как их не назови.
Я сам охуел, когда это осознал. Годот - это ESC-ориентированный движок. Прямо со старта игры происходит что? Движок поднимает PAK-файл с данными и движется по ним как первоначальная стартовая так сказать система, которая извлекает сущности и другие системы, сериализованные в PAK-файле, а они уже выполняя свою логику, работают. Стоит последовать этой парадигме и ты обнаружишь все инструменты в движке, позволяющие программировать игру именно как композицию сущностей и систем.
> Все верно сделано?
Нет. Не совсем. У тебя телепорт занимается сменой сцен. Это вероятно приведёт к путанице в дальнейшем, когда сцены будут менять хаотично разные наборы объектов и твой код обрастёт кучей костылей, запрещающих менять сцены в одних случаях, разрешать в других. И эта мешанина костылей будет расти как снежный ком, пока в один момент ты не осознаешь, что игра настолько кривая, что ты не можешь добавить нужный функционал, потому что придётся переписывать 100500 строк кода в разных местах, причем, как только ты начнёшь переписывать в одном месте, игра сломается и не будет работать, пока не перепишешь всё. И всё это время тебе придётся ебашить код без возможности проверить его на ошибки. Потому что игра не работает.
Телепорт должен только посылать сигналы о том, что в него зашёл игрок. Сигналы телепортов принимает единый менеджер сцен и меняет сцены, сообразно данным, переданным из телепорта. Обдумай этот подход. Это композитный подход с отношением к контенту как к данным. Известен как DOD, ECS, фанаты этого подхода видят только обертку не понимая сути, пишут плагины для реализации этого подхода в годоте. Но если открыть глаза, ты увидишь, что в годоте всё уже организовано для реализации систем, сущностей, как их не назови.
Я сам охуел, когда это осознал. Годот - это ESC-ориентированный движок. Прямо со старта игры происходит что? Движок поднимает PAK-файл с данными и движется по ним как первоначальная стартовая так сказать система, которая извлекает сущности и другие системы, сериализованные в PAK-файле, а они уже выполняя свою логику, работают. Стоит последовать этой парадигме и ты обнаружишь все инструменты в движке, позволяющие программировать игру именно как композицию сущностей и систем.
>>81606
Есть смысл учить паттерны. А потом, когда заучишь на зубок, просто смотришь, как реализуются те или иные паттерны в том или ином языке.
Есть смысл учить паттерны. А потом, когда заучишь на зубок, просто смотришь, как реализуются те или иные паттерны в том или ином языке.
4 Кб, 170x137>>79036 (OP)
Кто-нибудь мне блять может нормально простым языком объяснить, зачем нужен _ready и дрочь с oneready var?
В документации хер найдешь прямой ответ на этот простой вопрос.
Кто-нибудь мне блять может нормально простым языком объяснить, зачем нужен _ready и дрочь с oneready var?
В документации хер найдешь прямой ответ на этот простой вопрос.
>>81709 (Del)
Спасибо
Спасибо
10 Кб, 168x126Новый год - новые открытия. Внезапно, draw calls влияют на производительность, и у меня их слишком много... Но в интернете как всегда никто не знает, к какому числу стремиться, только "чем меньше, тем лучше", а сколько нужно-то?
>>81709 (Del)
Неправда, _ready - это когда нода готова к работе. А готова она после того, как она и всё её потомки войдут в дерево сцены в первый раз, при этом сначала готовы все потомки, и только потом их предок, это нужно учитывать. Последующие вхождения _ready не вызывают, только _tree_enter, но вход в дерево в обратном порядке - сначала предок, потом потомки.
Правильнее сказать, что это отсроченная инициализация, т.е. инициализация задерживается до полной готовности ноды со всеми её потомками. Обычная инициализация происходит, вроде как, намного раньше, и в это время потомки просто не существуют.
Много зачем, например, чтобы иметь указатель на ноду, которая способна произвольно перемещаться по дереву и быть вне дерева сцены - через путь ты её не поймаешь, нужно хранить указатель, который возвращает 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
>>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
>>79036 (OP)
С новым годом вас!
У меня снова вопрос
Не нашёл адекватного способа проверить зажата или клавиша мыши, отпущена, отжата ли она, лол.
С новым годом вас!
У меня снова вопрос
Не нашёл адекватного способа проверить зажата или клавиша мыши, отпущена, отжата ли она, лол.
>>82982
Это потому, что ты документацию не читал. Читай документацию. Желаю тебе ума в новом году.
Это потому, что ты документацию не читал. Читай документацию. Желаю тебе ума в новом году.
>>82984
>>82985
Там есть только pressed анон, я это уже смотрел. Если бы всё было так просто, я бы не стал спрашивать.
Например, когда я писал на glut + C++, там не было никаких проблем с этим, все варианты состояний клавиш были. Тут же есть только состояние ЗАЖАТА, но вот отжата или нет ты не выяснишь, из-за чего даже хитрые костыли не помогают.
>>82985
Там есть только pressed анон, я это уже смотрел. Если бы всё было так просто, я бы не стал спрашивать.
Например, когда я писал на glut + C++, там не было никаких проблем с этим, все варианты состояний клавиш были. Тут же есть только состояние ЗАЖАТА, но вот отжата или нет ты не выяснишь, из-за чего даже хитрые костыли не помогают.
>>82989
И теперь все блоки под мышкой по умолчанию открываются, особенно если это запихнуть в process.
И теперь все блоки под мышкой по умолчанию открываются, особенно если это запихнуть в process.
>>82991
Нахуевертил с логикой. Нарисуй мне в пейнте и запости прямо в тред блок-схему того, как должно быть. И я на 80% уверен, что пока ты будешь рисовать блок-схему, ты увидишь свой косяк, но если не увидишь - то подскажу тогда я.
Нахуевертил с логикой. Нарисуй мне в пейнте и запости прямо в тред блок-схему того, как должно быть. И я на 80% уверен, что пока ты будешь рисовать блок-схему, ты увидишь свой косяк, но если не увидишь - то подскажу тогда я.
>>82992
Разумеется, блок-схема, которую ты нарисуешь должна отражать твой реально существующий код.
Разумеется, блок-схема, которую ты нарисуешь должна отражать твой реально существующий код.
>>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
у тебя же подобной конструкции нет, и какой бы ивент ни прилетал, ты пытаешься обращаться к нему, как к маузбаттону, а он-то в этом кадре маузмовшн!
А хотя нет, можешь не рисовать, у тебя нет разделения на сабклассы, которое рекомендуется всеми гайдами, документацией и туториалами. Вид у неё такой:
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
у тебя же подобной конструкции нет, и какой бы ивент ни прилетал, ты пытаешься обращаться к нему, как к маузбаттону, а он-то в этом кадре маузмовшн!
>>82995
Интересная тема, частично использую
>>82996 (Del)
Это ближе всего, ибо на это натыкался, но без весомых подробностей
Интересная тема, частично использую
>>82996 (Del)
Это ближе всего, ибо на это натыкался, но без весомых подробностей
39 Кб, 318x382>>83000
Добавлю, что проблема скорее не в мыши, а в том, что я обработку TileMap делаю как у кнопки для каждого элемента, отсюда вся возня. Частично уже сделал
Добавлю, что проблема скорее не в мыши, а в том, что я обработку TileMap делаю как у кнопки для каждого элемента, отсюда вся возня. Частично уже сделал
>>83001
В сапёре тайлмап ИМХО только помешает. Я бы делал на кнопках. Выстроить их в поле и занести в массив - пять секунд делов и десяток строчек кода.
В сапёре тайлмап ИМХО только помешает. Я бы делал на кнопках. Выстроить их в поле и занести в массив - пять секунд делов и десяток строчек кода.
>>83003
Каждая кнопка вызывает дравкол. Не юзай кнопки! Наоборот надо где можно всегда делать тайлмап
Каждая кнопка вызывает дравкол. Не юзай кнопки! Наоборот надо где можно всегда делать тайлмап
>>83007
Посрать на дравколлы в игре типа "сапёр", блять! Таблетки прими, у тебя дравколячка.
Посрать на дравколлы в игре типа "сапёр", блять! Таблетки прими, у тебя дравколячка.
>>83009
Он прав, ты бредятину пишешь. Идея делать поле сапёра из кнопок, а потом ещё всё это в цикле ебашить наитупейшая. ПК даже современный ахуеет от поля в 24 на 30, не говоря уже о том, что у меня в видео выше таких полей 9 штук для замкнутости.
Одно мне неизвестно - TileMap рисует поле спрайтов по принципу InstanceRendering как OpenGL или нет? Можно ещё процом запекать потайлово в общую текстуру.
Он прав, ты бредятину пишешь. Идея делать поле сапёра из кнопок, а потом ещё всё это в цикле ебашить наитупейшая. ПК даже современный ахуеет от поля в 24 на 30, не говоря уже о том, что у меня в видео выше таких полей 9 штук для замкнутости.
Одно мне неизвестно - TileMap рисует поле спрайтов по принципу InstanceRendering как OpenGL или нет? Можно ещё процом запекать потайлово в общую текстуру.
>>83011
Так просто повторить текстуру как ты думаешь не получится. Когда у нас есть одна, то проблем нету, но когда речь идёт про разные текстуры, то тут либо смешивать маской одну большую с разыми затайлеными кусками, либо в экран копировать с той же маской там, или по ИД рисовать. Подозреваю, что второе быстрее и реализуется быстрым даже если процессором попиксельно будут копироваться куосчки с учётом масштаба.
В OpenGL карточкой рисуется 3д один и тот же объект с немного разными параметрами и текстурой.
Так просто повторить текстуру как ты думаешь не получится. Когда у нас есть одна, то проблем нету, но когда речь идёт про разные текстуры, то тут либо смешивать маской одну большую с разыми затайлеными кусками, либо в экран копировать с той же маской там, или по ИД рисовать. Подозреваю, что второе быстрее и реализуется быстрым даже если процессором попиксельно будут копироваться куосчки с учётом масштаба.
В OpenGL карточкой рисуется 3д один и тот же объект с немного разными параметрами и текстурой.
>>83017
Да. Оказалось, кнопки не подходят. Я начал пилить самодельную кнопку на основе Спрайта, но поймал себя на мысли, что велосипежу функционал тайлмапа. И тут твой пост. И я такой, ну лан, похоже я хуйню сморозил.
Да. Оказалось, кнопки не подходят. Я начал пилить самодельную кнопку на основе Спрайта, но поймал себя на мысли, что велосипежу функционал тайлмапа. И тут твой пост. И я такой, ну лан, похоже я хуйню сморозил.
>>83018
Я годо для 2д потому и выбрал, что немножко присел от мысли рисовать instance, ибо неудобный он в OpenGL, не шмог я кароч, а помимо него надо текст и кнопочки ещё.
Зато можно и нужно делать симуляции вселенной и взаимодействия неких минимальных элементов.
Я годо для 2д потому и выбрал, что немножко присел от мысли рисовать instance, ибо неудобный он в OpenGL, не шмог я кароч, а помимо него надо текст и кнопочки ещё.
Зато можно и нужно делать симуляции вселенной и взаимодействия неких минимальных элементов.
>>83019
Есть ещё третий вариант, отрисовать весь сапёр целиком на холсте одного объекта типа CanvasItem, но он тоже тормозной как выяснилось, ибо каждая функция вида
- это отдельный дравкол, со всеми вытекающими.
Есть ещё третий вариант, отрисовать весь сапёр целиком на холсте одного объекта типа CanvasItem, но он тоже тормозной как выяснилось, ибо каждая функция вида
> draw_line
> draw_arc
> draw_text
> draw_texture
- это отдельный дравкол, со всеми вытекающими.
>>83022 (Del)
720 вызовов на отрисовку за кадр, а их в секунду может быть и 2160, и 4320, и даже 72000 в сумме.
720 вызовов на отрисовку за кадр, а их в секунду может быть и 2160, и 4320, и даже 72000 в сумме.
>>83024 (Del)
Есть. Но там как-то сложно всё.
Есть. Но там как-то сложно всё.
>>83030 (Del)
Тогда я велосипед изобрёл. Как посчитать количество вызовов на отрисовку?
Тогда я велосипед изобрёл. Как посчитать количество вызовов на отрисовку?
>>83027 (Del)
В общем-то, чтобы реализовать сапёра, в такую кнопку надо ещё 10 текстур запихнуть (ссылками) и менять по необходимости. В итоге проще сделать логическую обвязку вокруг существующего тайлмапа, где нужно просто индексами тайла жонглировать.
>>83021>>83018-кун
В общем-то, чтобы реализовать сапёра, в такую кнопку надо ещё 10 текстур запихнуть (ссылками) и менять по необходимости. В итоге проще сделать логическую обвязку вокруг существующего тайлмапа, где нужно просто индексами тайла жонглировать.
>>83021>>83018-кун
>>83039 (Del)
Я изначально про кнопку и сказал из-за того, что там можно было бы без задней мысли выводить цифру, сразу отцентрированную. Но немного поразмыслив, я понял что победа там окажется пирровой.
Я изначально про кнопку и сказал из-за того, что там можно было бы без задней мысли выводить цифру, сразу отцентрированную. Но немного поразмыслив, я понял что победа там окажется пирровой.
17 Кб, 531x163У меня ещё вопрос. Я использую самописные библиотеки на скрипте, предзагруженные, а так же автоматически загруженный глобальный скрипт. После правки в класс из неё по обращению через точку к члену этого класса выдаёт старое имя. Удаление скрипта не помогает, он где-то закеширован. Как мне обновить? Смотрел в нете, но там велосипеды какие-то.
На картинке то как я загружаю скрипты.
На картинке то как я загружаю скрипты.
>>83038 (Del)
Попробую
Попробую
78 Кб, 895x1202>>83058
Ругается на способ объявления что ли, самого объекта. Интсрукцию читал, но ноды под названием Monitor там нету, зато целый список других есть
Ругается на способ объявления что ли, самого объекта. Интсрукцию читал, но ноды под названием Monitor там нету, зато целый список других есть
49 Кб, 956x562>>83062 (Del)
Н-не очень, кек
>>83063 (Del)
Я ща удалил папку addons и теперь у меня указанная в блоке Run нода не запускается, проверял print в _ready(), он её нагло игнорирует. Игра всё, ахаха.
Наверное я попробую обновить годо, точнее запустить новый скачанный
Н-не очень, кек
>>83063 (Del)
Я ща удалил папку addons и теперь у меня указанная в блоке Run нода не запускается, проверял print в _ready(), он её нагло игнорирует. Игра всё, ахаха.
Наверное я попробую обновить годо, точнее запустить новый скачанный
>>83065 (Del)
Ща бы делать бекап после того, как всё наебнулось.
Ща бы делать бекап после того, как всё наебнулось.
Новый двиг скачал, проект восстановил, plug включил, но не задействовал, не ругается. Осталось только понять что добавлять или что создавать.
>>83076 (Del)
Что-то немного я перенапряглся, в примере там надо создавать canvas layer и к нему скрипт прикреплять. Добавить ноду Monitor не очень похоже на это, что и напрягло меня.
Что-то немного я перенапряглся, в примере там надо создавать canvas layer и к нему скрипт прикреплять. Добавить ноду Monitor не очень похоже на это, что и напрягло меня.
>>83083
Хотелось бы поподробнее узнать момент когда я начал его изобретать, а когда ещё нет.
Хотелось бы поподробнее узнать момент когда я начал его изобретать, а когда ещё нет.
>>83093 (Del)
Мне скрипт пихать куда тогда? Или как? Которую tsсn добавлять? ЯННП
Так то работает, до 34 вызовов на отрисовку, в среднем 20. Отлично для 1152 кнопок. Ща попробую бахнуть поле 256 на 256, кек.
Каждый тайл 128 на 128 пикселей, масштабируется, а то вдруг я захочу погамать на монике в 2160ПЭ. Предел по графону 3456 ПЭ, на будущее лол.
А вот почему там 60 предел, видать где-то в настройках включено, ибо я сам насильно не врубал. Нашёл только предел в 60 по физике, надо поставить 30, ибо больше не надо.
Мне скрипт пихать куда тогда? Или как? Которую tsсn добавлять? ЯННП
Так то работает, до 34 вызовов на отрисовку, в среднем 20. Отлично для 1152 кнопок. Ща попробую бахнуть поле 256 на 256, кек.
Каждый тайл 128 на 128 пикселей, масштабируется, а то вдруг я захочу погамать на монике в 2160ПЭ. Предел по графону 3456 ПЭ, на будущее лол.
А вот почему там 60 предел, видать где-то в настройках включено, ибо я сам насильно не врубал. Нашёл только предел в 60 по физике, надо поставить 30, ибо больше не надо.
>>83104 (Del)
VSync стоит по умолчанию
Там в папке addon куча файлов, вот прямо все? И к чему тогда обращается ЭТО
$Monitor.add_perf_monitor(Performance.TIME_FPS, "FPS")
$Monitor.add_perf_monitor(Performance.RENDER_2D_DRAW_CALLS_IN_FRAME , "DrC2D")
если такой ноды или файла по умолчанию нету ни в сцене, ни в папке.
Что я понимаю не так?
VSync стоит по умолчанию
> Я прямо в главную сцены игры пихаю все отладочное
Там в папке addon куча файлов, вот прямо все? И к чему тогда обращается ЭТО
$Monitor.add_perf_monitor(Performance.TIME_FPS, "FPS")
$Monitor.add_perf_monitor(Performance.RENDER_2D_DRAW_CALLS_IN_FRAME , "DrC2D")
если такой ноды или файла по умолчанию нету ни в сцене, ни в папке.
Что я понимаю не так?
>>83117 (Del)
И правда, я совершенно по иному мыслю, вот до чего доводит программирование на ЦЭ++, уже по умолчанию привыкаешь, что ничего просто так само не создаётся и всё надо ручками с огромными усилиями, ыыыыы.
Ясно почему от других моих проектов люди часто в шоке.
И правда, я совершенно по иному мыслю, вот до чего доводит программирование на ЦЭ++, уже по умолчанию привыкаешь, что ничего просто так само не создаётся и всё надо ручками с огромными усилиями, ыыыыы.
Ясно почему от других моих проектов люди часто в шоке.
>>83129 (Del)
Я определённо правильно поступил, что не стал писать сапёр для освоения годо на шарпе.
Я определённо правильно поступил, что не стал писать сапёр для освоения годо на шарпе.
При попытке родить поле 128 на 128 девять раз по углам и в центре ругается на переполнение стека. Как его понимать? Это предел TileMap или чего? Указано число 1024, 128 128 9 = 147 456. Проблема в этом? Да вроде бы нет, 24 48 9 = 10 368.
Да и какого хрена, ничего я там рекурсивно не вызываю.
Да и какого хрена, ничего я там рекурсивно не вызываю.
8 Кб, 371x370Сапёр-челлендж, посаны! Чтобы к утру у всех участников были работающие сапёры. Поехали!
Призовой фонд - пак Годетты.
Призовой фонд - пак Годетты.
>>83158 (Del)
Нельзя. Бомбер есть в ассетах, а майнера нету. Майнера, лол!
Нельзя. Бомбер есть в ассетах, а майнера нету. Майнера, лол!
>>82983
Хорошо, а 3D? А на мобилки?
Я когда-то где-то читал, что на мобилки в 3D - не более 100 вызовов отрисовки, иначе мобилка не справится. Ну это понятно, что мой попенворлд нужно оптимизировать, чтобы не было тысяч вызовов, но хотелось узнать более точные цифры, на что ориентироваться.
>1000 для 2д максимум
Хорошо, а 3D? А на мобилки?
Я когда-то где-то читал, что на мобилки в 3D - не более 100 вызовов отрисовки, иначе мобилка не справится. Ну это понятно, что мой попенворлд нужно оптимизировать, чтобы не было тысяч вызовов, но хотелось узнать более точные цифры, на что ориентироваться.
>>83161 (Del)
Уже не первый раз получаю её от TextEdit, данные которого получаю как на второй.
Только что пробовал сделать сразу на 128 128 и 256, создал, да, задумался и при обработке тоже, но создал.
Уже не первый раз получаю её от TextEdit, данные которого получаю как на второй.
Только что пробовал сделать сразу на 128 128 и 256, создал, да, задумался и при обработке тоже, но создал.
565 Кб, 1582x884>>83168
На 100, если мобилки, на 1000 если ПК, но даже старый ПК сожрёт и 50 000 не напрягаясь. Я так думаю, выше анон тестировал на 750ТЫ, у меня вообще 290Х с 5.6 ТФлопс. Лагала только в УЕ4 когда я это без лодов рендерил.
На 100, если мобилки, на 1000 если ПК, но даже старый ПК сожрёт и 50 000 не напрягаясь. Я так думаю, выше анон тестировал на 750ТЫ, у меня вообще 290Х с 5.6 ТФлопс. Лагала только в УЕ4 когда я это без лодов рендерил.
>>83153
Внезапно, но как и в любой игре, обвязка самой игры - гуи, настройки, всякие датчики с игровыми состояниями сложнее и скучнее делать чем саму логику игры.
Внезапно, но как и в любой игре, обвязка самой игры - гуи, настройки, всякие датчики с игровыми состояниями сложнее и скучнее делать чем саму логику игры.
>>83044
Проверь папку %appdata%/Godot - прям так и вводи (окно "выполнить" (winkey+R) или адресная строка Проводника (F4)), если ты на Windows.
>>83060
Там тебе красным по синему чётко сказано: у тебя скрипт наследуется от Panel (который наследуется от Control), а ты пытаешься навесить его на ноду Node2D, которая является отдельной веткой наследования и несовместима с потомками Control (и Spatial).
>где-то закеширован
Проверь папку %appdata%/Godot - прям так и вводи (окно "выполнить" (winkey+R) или адресная строка Проводника (F4)), если ты на Windows.
>>83060
Там тебе красным по синему чётко сказано: у тебя скрипт наследуется от Panel (который наследуется от Control), а ты пытаешься навесить его на ноду Node2D, которая является отдельной веткой наследования и несовместима с потомками Control (и Spatial).
>>83177
Там логи, малоинформативные
В итоге оказалось, что после копирования плагина надо добавлять ноду Monitor
> Проверь папку
Там логи, малоинформативные
> у тебя скрипт наследуется
В итоге оказалось, что после копирования плагина надо добавлять ноду Monitor
>>83170
Смеёшься что ли? У меня лаги уже на 10 тысячах.
У меня тоже 750 Ti, но фигня в том, что видеокарта отдыхает - только одно ядро процессора (E5450) загружается на 100%. Может, конечно, это не только из-за вызовов отрисовки, раньше я видел проблему в количестве нод и физических объектов, но когда начал следить за вызовами отрисовки - заметил сильную связь между количеством отрисовок и частотой кадров, т.е. со статичным числом нод и практически отдыхающим физическим движком.
>даже старый ПК сожрёт и 50 000 не напрягаясь
Смеёшься что ли? У меня лаги уже на 10 тысячах.
>750ТЫ
У меня тоже 750 Ti, но фигня в том, что видеокарта отдыхает - только одно ядро процессора (E5450) загружается на 100%. Может, конечно, это не только из-за вызовов отрисовки, раньше я видел проблему в количестве нод и физических объектов, но когда начал следить за вызовами отрисовки - заметил сильную связь между количеством отрисовок и частотой кадров, т.е. со статичным числом нод и практически отдыхающим физическим движком.
>>83182
Смотря что рисуется. По идее всё 3д надо через instance рисовать, я потому перекатился на движки, что уныло это писать ручками. Но внезапно, ни в унити, ни в УЕ4, это не было реализованно из коробочки - создаёшь 3д объект например особенный, с пометкой, что он instance, он у себя там запоминает меш, потом при копировании он запоминает атрибуты - ид, масштаб, координаты, текстуру, шейдер, хрен знает что, и рендерит, но нет. Как я матерился когда искал нужные мне данные для унити чтобы воксели описать, это кошмар, тривиальную срань пжлст, а что-то по настоящему сложное, нет.
Смотря что рисуется. По идее всё 3д надо через instance рисовать, я потому перекатился на движки, что уныло это писать ручками. Но внезапно, ни в унити, ни в УЕ4, это не было реализованно из коробочки - создаёшь 3д объект например особенный, с пометкой, что он instance, он у себя там запоминает меш, потом при копировании он запоминает атрибуты - ид, масштаб, координаты, текстуру, шейдер, хрен знает что, и рендерит, но нет. Как я матерился когда искал нужные мне данные для унити чтобы воксели описать, это кошмар, тривиальную срань пжлст, а что-то по настоящему сложное, нет.
>>83173
Тогда юзайте челлендж этого анона: >>83155 поле сапёра должно быть тороидным - верх переходит вниз, право переходит влево, соответственно и расчёт мин в соседних клетках должен это учитывать.
Задачка на пять с плюсиком: тороидность должна быть опциональной в настройках.
Задачка на пять в четверти: обойдитесь без тайлмапов.
Тогда юзайте челлендж этого анона: >>83155 поле сапёра должно быть тороидным - верх переходит вниз, право переходит влево, соответственно и расчёт мин в соседних клетках должен это учитывать.
Задачка на пять с плюсиком: тороидность должна быть опциональной в настройках.
Задачка на пять в четверти: обойдитесь без тайлмапов.
>>83189
Время до полудня по Москве, завтра 3 января, финалки выкладывать вебэмками прямо в тред.
Время до полудня по Москве, завтра 3 января, финалки выкладывать вебэмками прямо в тред.
>>83185
Ты имеешь в виду MultiMeshInstance? Потому что обычный .instance() создаёт полностью независимые объекты.
>>83189
Не понимаю, зачем вообще тайлмапы, если ты генерируешь игровое поле процедурно, а не ручками выставляя тайлы. Всегда воспринимал тайлмапы как инструмент по типу редактора уровней, а не как средство отрисовки процедурных уровней...
>через instance рисовать
Ты имеешь в виду MultiMeshInstance? Потому что обычный .instance() создаёт полностью независимые объекты.
>>83189
>обойдитесь без тайлмапов
Не понимаю, зачем вообще тайлмапы, если ты генерируешь игровое поле процедурно, а не ручками выставляя тайлы. Всегда воспринимал тайлмапы как инструмент по типу редактора уровней, а не как средство отрисовки процедурных уровней...
Кстати, с сапёром знаком очень давно, но я до сих пор не знаю зачем нужен вопрос. Пробовал, но разницы с простой не открытой кнопкой не нашёл. Подозреваю, что это пометка игрока для самого себя.
>>83196
В отличие от открытой кнопки, вопрос ни на что не влияет. В отличие от флажка, если не ошибаюсь, на знак вопроса можно кликнуть, флажок вроде должен блокировать клик.
Именно так. Флажок - это метка "я знаю, что тут мина, сюда кликать нельзя", а знак вопроса - "я не уверен, есть ли тут мина, нужно будет потом перепроверить".
Хотя сам я эти значки вроде не использовал, можно пройти вообще без них и даже без флажков, если память хорошая.
>Пробовал, но разницы с простой не открытой кнопкой не нашёл.
В отличие от открытой кнопки, вопрос ни на что не влияет. В отличие от флажка, если не ошибаюсь, на знак вопроса можно кликнуть, флажок вроде должен блокировать клик.
>Подозреваю, что это пометка игрока для самого себя.
Именно так. Флажок - это метка "я знаю, что тут мина, сюда кликать нельзя", а знак вопроса - "я не уверен, есть ли тут мина, нужно будет потом перепроверить".
Хотя сам я эти значки вроде не использовал, можно пройти вообще без них и даже без флажков, если память хорошая.
>>83153
Стесняюсь спросить, это какой-то эксклюзивный NSFW контент или просто скачанные с интернетов джипеги? Если второе, лучше уж поделиться со всеми в конце конкурса.
Ощущение, что шутка прошла мимо меня...
>пак Годетты
Стесняюсь спросить, это какой-то эксклюзивный NSFW контент или просто скачанные с интернетов джипеги? Если второе, лучше уж поделиться со всеми в конце конкурса.
Ощущение, что шутка прошла мимо меня...
73 Кб, 624x530Ну что вы, бэтмены?
Кто с нами?
Работа кипит! Мины уже рандомятся. Часики тикают.
>>83214
Да, просто пак. Ой, да какая шутка, ха-ха... Не смешно.
Кто с нами?
Работа кипит! Мины уже рандомятся. Часики тикают.
>>83214
Да, просто пак. Ой, да какая шутка, ха-ха... Не смешно.
>>83221
Кстати, буквально сегодня читал, что мины в сапёре не полностью рандомно расставляются. Tl;dr:
- первый клик всегда на чистую клетку, поскольку мины генерируются после первого клика, а не после нажатия "новая игра";
- есть разные способы расстановки мин, от них зависит геймплей;
- если мины расположены слишком плотно, играть не так интересно, но реже приходится угадывать;
- если мины расположены далеко друг от друга, чаще возникают ситуации, где приходится угадывать.
На основании этого есть мнение, что сапёр - это игра с процедурной генерацией, в отличие от солитёра или покера, в которых чистый рандом (в сапёре рандом структурирован, в нём есть правила).
http://roguelikedeveloper.blogspot.com/2008/05/minesweeper-vs-solitaire.html?m=1
>Мины уже рандомятся
Кстати, буквально сегодня читал, что мины в сапёре не полностью рандомно расставляются. Tl;dr:
- первый клик всегда на чистую клетку, поскольку мины генерируются после первого клика, а не после нажатия "новая игра";
- есть разные способы расстановки мин, от них зависит геймплей;
- если мины расположены слишком плотно, играть не так интересно, но реже приходится угадывать;
- если мины расположены далеко друг от друга, чаще возникают ситуации, где приходится угадывать.
На основании этого есть мнение, что сапёр - это игра с процедурной генерацией, в отличие от солитёра или покера, в которых чистый рандом (в сапёре рандом структурирован, в нём есть правила).
http://roguelikedeveloper.blogspot.com/2008/05/minesweeper-vs-solitaire.html?m=1
85 Кб, 794x548>>83222
Кор-механика готова. Я спать. Завтра с утреца доделаю графиниум, менюшки, расстановку бомб после первого клика и можно побеждать в своём же конкурсе.
Кор-механика готова. Я спать. Завтра с утреца доделаю графиниум, менюшки, расстановку бомб после первого клика и можно побеждать в своём же конкурсе.
57 Кб, 962x985Вырвиглазненько!
51 Кб, 600x400Вот блин, я почти всю ночь рисовал спрайты в Inkscape, а потом всё утро выдумывал сюжет и гэги для 19 концовок (больше делать пока лень). В Godot так и не зашёл, сил больше нет, я спать.
7,1 Мб, 1899x941Потихоньку кириллю свою бродиловку/говориловку на годоте. Сейчас вот допиливаю движок, чтобы в будущем просто раскидать обьекты и неписей по карте с минимумом хардкода.
Для диалогов использую Dialogic - очень удобная штука.
Для диалогов использую Dialogic - очень удобная штука.
Пора подвести итоги.
Я выбываю из конкурса, потому что с квадратным полем всё работает, а если задать прямоугольные размеры - out of bounds.
Всё утро тупил над кодом, пихал принты куда только мог, нихуя. Чувствую, что проблема до смеха простейшая, но глаз замылен.
Я выбываю из конкурса, потому что с квадратным полем всё работает, а если задать прямоугольные размеры - out of bounds.
Всё утро тупил над кодом, пихал принты куда только мог, нихуя. Чувствую, что проблема до смеха простейшая, но глаз замылен.
43 Кб, 610x497>>83274
Ещё на старте искал как сделать массив в годо, в С++ обычно использовал одномерный, подразумеваемый как двухмерный, в годо просто в лоб двухмерный.
Ещё на старте искал как сделать массив в годо, в С++ обычно использовал одномерный, подразумеваемый как двухмерный, в годо просто в лоб двухмерный.
>>83278
Я был одним из двух анонов, обсуждавших с тобой массивы, и мы оба предлагали юзать одномерный, плюс функцию-хелпер, которая по формуле x+y*max_y выдаёт элемент по двумерным координатом с фиксированной высотой столбцов. И проблема у меня походу в ней. Делаю по столбцам - вылет на строках. Делаю по строкам - вылет на столбцах. Чего-то очевидного я недовтыкаю.
Я был одним из двух анонов, обсуждавших с тобой массивы, и мы оба предлагали юзать одномерный, плюс функцию-хелпер, которая по формуле x+y*max_y выдаёт элемент по двумерным координатом с фиксированной высотой столбцов. И проблема у меня походу в ней. Делаю по столбцам - вылет на строках. Делаю по строкам - вылет на столбцах. Чего-то очевидного я недовтыкаю.
>>83280
Поэтому лучше делай двухмерный и не парься, проблем в скорости даже! на поле тайлов в 768 на 768 элементов не было вообще.
Касаемо переполнения стека, я вчера поздно вечером понял, что проблема в классах помощниках, которые я создаю в функции, которая в свою очередь вызывается очень много раз. Ну кароч сборщик мусора не всегда поспевает прибраться походу, так что перепишу на менее жрущий вариант.
Поэтому лучше делай двухмерный и не парься, проблем в скорости даже! на поле тайлов в 768 на 768 элементов не было вообще.
Касаемо переполнения стека, я вчера поздно вечером понял, что проблема в классах помощниках, которые я создаю в функции, которая в свою очередь вызывается очень много раз. Ну кароч сборщик мусора не всегда поспевает прибраться походу, так что перепишу на менее жрущий вариант.
>>83281
И мгновенно всё заработало с любыми вариантами поля!
И мгновенно всё заработало с любыми вариантами поля!
>>83283
Как видишь, нет. Главное, правильно применить формулу и двумерный массив - ни-ну-жна. Твёрдо и чотко!
А вот вопрос на засыпку всем, а эту формулу как-то можно расширить на эмуляцию в одномерном массиве массивов любой размерности?
> лучше делай двухмерный и не парься
Как видишь, нет. Главное, правильно применить формулу и двумерный массив - ни-ну-жна. Твёрдо и чотко!
А вот вопрос на засыпку всем, а эту формулу как-то можно расширить на эмуляцию в одномерном массиве массивов любой размерности?
>>83283
Кроме того у меня вообще нет дополнительного массива. Созданные кнопки - это массив чайлд-нод ноды-поля, соответственно, необходимости в дополнительных массивах вообще нет. Минимализм.
Кроме того у меня вообще нет дополнительного массива. Созданные кнопки - это массив чайлд-нод ноды-поля, соответственно, необходимости в дополнительных массивах вообще нет. Минимализм.
>>83288
Только так мы не дадим мозгам деградировать! Даёшь хитросплетения!
> выносящие мозги формулы и код
Только так мы не дадим мозгам деградировать! Даёшь хитросплетения!
30 Кб, 483x450Игра с самопроизвольно образовавшимся читом - не проверяются пока неправильно выставленные флажки. Без чита я такую катку бы не затащил.
12,1 Мб, mp4,1200x900, 3:26
>>83296
А вот как это происходит в динамике. Я выставляю флажок и прощупываю. В настоящем сапёре без чита, неправильный флажок привёл бы ко взрыву. Однако ничего не происходит, и ячейки не открываются, тогда я просто переставляю флажок. И вуаля!
Поле - сферическое в приведённом примере. Право=лево.
А вот как это происходит в динамике. Я выставляю флажок и прощупываю. В настоящем сапёре без чита, неправильный флажок привёл бы ко взрыву. Однако ничего не происходит, и ячейки не открываются, тогда я просто переставляю флажок. И вуаля!
Поле - сферическое в приведённом примере. Право=лево.
>>83314
На картинке предпростмотра ВЕБМ слева снизу 4, хотя с учётом замкнутости мин вокруг пять
На картинке предпростмотра ВЕБМ слева снизу 4, хотя с учётом замкнутости мин вокруг пять
433 Кб, mp4,1200x900, 0:14
>>83316
Мы друг-друга не понимаем. Вот демонстрация сферической замкнутости, как это понимаю я.
Мы друг-друга не понимаем. Вот демонстрация сферической замкнутости, как это понимаю я.
>>83299
Может, цилиндрическое или тороидальное?
>Поле - сферическое в приведённом примере. Право=лево.
Может, цилиндрическое или тороидальное?
496 Кб, 240x240>>83327
Сразу видно, человек не знаком с топологией.
Гугли, как натягивают на сферу всякие тайлы и гексы. Это очень серьезная тема.
>Но ведь это двухмерное пространство, для него неприменимо думать, что его размазали по тору, цилиндру или сфере.
Сразу видно, человек не знаком с топологией.
>Я прост думал на трёхмерную сферу натянуть это всё, но быстро понял, что идея так себе, наверное налезут только треугольные или шестиугольные кнопки максимум.
Гугли, как натягивают на сферу всякие тайлы и гексы. Это очень серьезная тема.
>>83328
Как их натягивают я знаю и видел, просто пространство игры двухмерное, а замкнутость достигается МАГИЕЙ этого пространства.
Как их натягивают я знаю и видел, просто пространство игры двухмерное, а замкнутость достигается МАГИЕЙ этого пространства.
Доигрался я кароч, я всегда задачи на части мелкие дроблю, которые решают отдельные функции или классы. Сделал класс для решения одной такой задачи и на одном из его часто вызываемых методе он выдаёт переполнение стэка. Меня удивляет, что это происходит с классом, объект которого создаётся лишь однажды, а потом просто многократно используется. Моё понимание годо скрипта явно не соответствует действительности.
>>83330
Похуй, какое оно там. Топологически это тор или цилиндр.
>просто пространство игры двухмерное, а замкнутость достигается МАГИЕЙ этого пространства.
Похуй, какое оно там. Топологически это тор или цилиндр.
Как жаль, шо у годо маленький размер стека. Уж сейчас то смысла напрягать так всех нету, даже мобила понятен жирный размер стэка в 16 - 64 мб. Даже в новом шарпе почему-то сделали всего 4 МБ.
Некоторые задачи удобно решаются рекурсией, я требую прогибания под удобство программирования.
Некоторые задачи удобно решаются рекурсией, я требую прогибания под удобство программирования.
>>83346
Ан нет, поэкспериментировал, придётся с матами делать итерационный вариант. Как же раздражает, ПК это быстрый калькулятор, почему же мне приходится писать неудобный код.
Ан нет, поэкспериментировал, придётся с матами делать итерационный вариант. Как же раздражает, ПК это быстрый калькулятор, почему же мне приходится писать неудобный код.
>>83270
Интересно. Комнаты потом будут меньше или плотнее заполнены? А то одинокий холодильник в огромной комнате выглядит как сцена из фильмов ужасов (холодильник всех сожрал).
Движок - Godot, допиливают его на C++ на гитхабе. А ты, скорее всего, делаешь собственный фреймворк/модули/инструменты с помощью GDScript и доступных классов. В ином случае не вижу смысла ковыряться во внутренностях Godot ради 2Д бродилки.
Интересно. Комнаты потом будут меньше или плотнее заполнены? А то одинокий холодильник в огромной комнате выглядит как сцена из фильмов ужасов (холодильник всех сожрал).
>допиливаю движок
Движок - Godot, допиливают его на C++ на гитхабе. А ты, скорее всего, делаешь собственный фреймворк/модули/инструменты с помощью GDScript и доступных классов. В ином случае не вижу смысла ковыряться во внутренностях Godot ради 2Д бродилки.
>>83364
Да, холодильник лишь для примера.
Так точно. Немного неверно назвал. Скорее фреймворк с набором сцен и контроллеров. К примеру - контроллер диалога, который я могу закинуть под любую ноду, указать нужный диалог и прокинуть сигналы. К слову таким образом этот холодильник и реализован
>Комнаты потом будут меньше или плотнее заполнены?
Да, холодильник лишь для примера.
>делаешь собственный фреймворк/модули/инструменты
Так точно. Немного неверно назвал. Скорее фреймворк с набором сцен и контроллеров. К примеру - контроллер диалога, который я могу закинуть под любую ноду, указать нужный диалог и прокинуть сигналы. К слову таким образом этот холодильник и реализован
>>83338
Только при условии, что число вложений невелико. Это даже в школе на информатике говорят, что рекурсию нужно использовать очень аккуратно.
>>83348
Стек не увеличивается? Или тебе нужен слишком большой? Меня вопрос стека тоже волнует, но не из-за рекурсии, а из-за того, что я предпочитаю делить всё на мелкие функции - вложенность кода может оказаться довольно большой.
Интересно, под капотом интерпретатор гдскрипт умеет инлайнить простые функции? Типа такой:
Или даже на такое тратится стек вызовов?
>Некоторые задачи удобно решаются рекурсией
Только при условии, что число вложений невелико. Это даже в школе на информатике говорят, что рекурсию нужно использовать очень аккуратно.
>>83348
Стек не увеличивается? Или тебе нужен слишком большой? Меня вопрос стека тоже волнует, но не из-за рекурсии, а из-за того, что я предпочитаю делить всё на мелкие функции - вложенность кода может оказаться довольно большой.
Интересно, под капотом интерпретатор гдскрипт умеет инлайнить простые функции? Типа такой:
>func is_empty(thing): return thing.size < 0
Или даже на такое тратится стек вызовов?
>>83371
Увеличивается, можно поставить любое значение, на значении 16384 моя игра просто вылетела, так как в ОС видимо есть свой предел и он ниже. Нужен значительно больший размер стека кароч.
Второе не знаю.
По итогу, надо писать итерационный, императивный вариант.
> Стек не увеличивается?
Увеличивается, можно поставить любое значение, на значении 16384 моя игра просто вылетела, так как в ОС видимо есть свой предел и он ниже. Нужен значительно больший размер стека кароч.
Второе не знаю.
По итогу, надо писать итерационный, императивный вариант.
>>83321
У тебя цилиндрическая, но это уже сказали.
Лично я, когда слышу про имитацию сферы на плоской квадратной карте, сразу представляю себе тор (бублик), потому что именно при замыкании всех сторон карты ты можешь гулять в любом направлении неограниченно как по поверхности сферы, хотя топологически это, конечно, тор, а не сфера.
Замыкать карту в цилиндр имеет смысл в играх с видом сбоку: всякие платформеры и т.п. В таких играх было бы странно проваливаться в пол, чтобы упасть с потолка в той же комнате, хотя это может быть интересно. А вот в играх с видом сверху, к которым и относится сапёр (мы смотрим на минное поле, а не на стену), имеет смысл только замыкание в виде тора, чтобы игрок мог пройти в любом направлении, а не только по горизонтали. Да, топологически это будет тор, но по ощущениям игрок будет чувствовать себя как на планете, если карта достаточно большая. Имхо.
Думаю над тем, чтобы сделать замыкание карты в виде тора в своём 3D опенворлде, когда реализую достойную систему чанков. Просто мне не нравятся невидимые стены...
>сферической замкнутости, как это понимаю я
У тебя цилиндрическая, но это уже сказали.
Лично я, когда слышу про имитацию сферы на плоской квадратной карте, сразу представляю себе тор (бублик), потому что именно при замыкании всех сторон карты ты можешь гулять в любом направлении неограниченно как по поверхности сферы, хотя топологически это, конечно, тор, а не сфера.
Замыкать карту в цилиндр имеет смысл в играх с видом сбоку: всякие платформеры и т.п. В таких играх было бы странно проваливаться в пол, чтобы упасть с потолка в той же комнате, хотя это может быть интересно. А вот в играх с видом сверху, к которым и относится сапёр (мы смотрим на минное поле, а не на стену), имеет смысл только замыкание в виде тора, чтобы игрок мог пройти в любом направлении, а не только по горизонтали. Да, топологически это будет тор, но по ощущениям игрок будет чувствовать себя как на планете, если карта достаточно большая. Имхо.
Думаю над тем, чтобы сделать замыкание карты в виде тора в своём 3D опенворлде, когда реализую достойную систему чанков. Просто мне не нравятся невидимые стены...
>>83419
Вычислить - никак. Один из способов исправить/облегчить такие ситуации - перемещать мины в зависимости от выбора игрока, чтобы игрок всегда побеждал. Что-то вроде суперпозиции, мина одновременно существует и не существует с точки зрения игрока, и задача игры сделать так, чтобы мина существовала не там, куда кликнет игрок, но при этом не изменяя окружающих цифр, чтобы не спалить это "читерство". Итог - игрок понадеялся на удачу и ему "повезло", он получил дозу гормонов удовольствия и доволен игрой, будет теперь охотнее донатить на лутбоксы...
Вычислить - никак. Один из способов исправить/облегчить такие ситуации - перемещать мины в зависимости от выбора игрока, чтобы игрок всегда побеждал. Что-то вроде суперпозиции, мина одновременно существует и не существует с точки зрения игрока, и задача игры сделать так, чтобы мина существовала не там, куда кликнет игрок, но при этом не изменяя окружающих цифр, чтобы не спалить это "читерство". Итог - игрок понадеялся на удачу и ему "повезло", он получил дозу гормонов удовольствия и доволен игрой, будет теперь охотнее донатить на лутбоксы...
12,7 Мб, webm,1152x720, 1:09
>>83387
Ну так и у меня остров(а). И в GTA всегда были острова, не считая одного куска материка в GTA 3. Но меня всегда раздражало в GTA то, что тебе разрешают уплыть/улететь далеко от острова, а там, примерно через километр-два - невидимая стена, в которую транспорт тупо врезается.
Если мне удастся сделать быструю чанковую систему и бесконечную генерацию ландшафта (не хочу использовать шум, шум слишком банальные паттерны генерирует, хочется чего-то разнообразнее), то можно было бы генерировать новые острова, но тогда возникает проблема симуляции жизни сразу на множестве островов... Короче, пока что мне кажется интересной идея "проклятого" острова, с которого невозможно убраться - всегда возвращаешься обратно, пока не начнёшь игру в новом мире. Это лучше, чем ломать транспорт любопытного игрока невидимой стеной.
Как считаете, у меня есть шансы доделать этот прототип до более-менее интересной игры? Я имею в виду, интересной для широкой аудитории, самому мне уже сейчас норм, в GTA я точно так же круги по городу нарезал и это для меня было основным геймплеем, лол.
>ОСТРОВ
Ну так и у меня остров(а). И в GTA всегда были острова, не считая одного куска материка в GTA 3. Но меня всегда раздражало в GTA то, что тебе разрешают уплыть/улететь далеко от острова, а там, примерно через километр-два - невидимая стена, в которую транспорт тупо врезается.
Если мне удастся сделать быструю чанковую систему и бесконечную генерацию ландшафта (не хочу использовать шум, шум слишком банальные паттерны генерирует, хочется чего-то разнообразнее), то можно было бы генерировать новые острова, но тогда возникает проблема симуляции жизни сразу на множестве островов... Короче, пока что мне кажется интересной идея "проклятого" острова, с которого невозможно убраться - всегда возвращаешься обратно, пока не начнёшь игру в новом мире. Это лучше, чем ломать транспорт любопытного игрока невидимой стеной.
Как считаете, у меня есть шансы доделать этот прототип до более-менее интересной игры? Я имею в виду, интересной для широкой аудитории, самому мне уже сейчас норм, в GTA я точно так же круги по городу нарезал и это для меня было основным геймплеем, лол.
>>83430
Что это за бомба с крестом?
Что это за бомба с крестом?
>>83448
Почему? Godot не потянет? Или ты судишь по плейсхолдерам? Графику я буду ещё много раз переделывать, пока даже со стилем не определился (это сложно, стилей много и все не очень).
Мне нечем заниматься. Альтернатива - лежать целыми днями на кровати и играть в гиперказуалки на телефоне, не имея сил даже встать и поесть хотя бы один раз в день.
>Нет шансов
Почему? Godot не потянет? Или ты судишь по плейсхолдерам? Графику я буду ещё много раз переделывать, пока даже со стилем не определился (это сложно, стилей много и все не очень).
>чем то полезнее
Мне нечем заниматься. Альтернатива - лежать целыми днями на кровати и играть в гиперказуалки на телефоне, не имея сил даже встать и поесть хотя бы один раз в день.
>>83433
не возникает. Зачем тебе симуляция жизни на островах, где нет игрока? Запускай эту симуляцию когда игрок туда попадет
>симуляции жизни сразу на множестве островов
не возникает. Зачем тебе симуляция жизни на островах, где нет игрока? Запускай эту симуляцию когда игрок туда попадет
>>83476
Под симуляцией жизни я подразумеваю не движущиеся по маршрутам модельки персонажей, это само собой можно скрыть и нужно будет скрывать даже в пределах одного острова. Я говорю о полноценной симуляции, когда ты можешь отъехать куда-нибудь на несколько игровых недель, вернуться назад - а там уже многое изменилось, и все изменения имеют логичную причину, а не выбраны случайно в момент возвращения. Если что-то существует в мире, оно не должно застывать вне присутствия игрока, иначе это не симуляция.
В общем, если игрок заперт в одной локации и не может никуда из неё выбраться, то мир за пределами этой локации абстрактен и может быть упрощён до всего нескольких параметров (типа "население планеты"). Если же игрок может посетить другие места, то они уже не могут быть полностью заморожены, а упростить до тех же нескольких параметров не факт что просто, если вообще возможно.
В теории можно очень быстро "перематывать время" в момент следующего посещения игроком отдалённой территории, чтобы обновить состояние этой территории. Типа "ленивая симуляция", только по требованию. Но что, если персонажи могут переезжать с острова на остров? Симуляция замороженного острова говорит, что персонаж уехал с острова неделю назад, но неделю назад никто с острова не выезжал, потому что он был заморожен. Тут уже ленивая симуляция никак не подходит.
Ладно, это всё теория, нужно сначала хотя бы один город/остров симулировать, а там посмотрим, что получится.
>Зачем тебе симуляция жизни на островах, где нет игрока?
Под симуляцией жизни я подразумеваю не движущиеся по маршрутам модельки персонажей, это само собой можно скрыть и нужно будет скрывать даже в пределах одного острова. Я говорю о полноценной симуляции, когда ты можешь отъехать куда-нибудь на несколько игровых недель, вернуться назад - а там уже многое изменилось, и все изменения имеют логичную причину, а не выбраны случайно в момент возвращения. Если что-то существует в мире, оно не должно застывать вне присутствия игрока, иначе это не симуляция.
В общем, если игрок заперт в одной локации и не может никуда из неё выбраться, то мир за пределами этой локации абстрактен и может быть упрощён до всего нескольких параметров (типа "население планеты"). Если же игрок может посетить другие места, то они уже не могут быть полностью заморожены, а упростить до тех же нескольких параметров не факт что просто, если вообще возможно.
В теории можно очень быстро "перематывать время" в момент следующего посещения игроком отдалённой территории, чтобы обновить состояние этой территории. Типа "ленивая симуляция", только по требованию. Но что, если персонажи могут переезжать с острова на остров? Симуляция замороженного острова говорит, что персонаж уехал с острова неделю назад, но неделю назад никто с острова не выезжал, потому что он был заморожен. Тут уже ленивая симуляция никак не подходит.
Ладно, это всё теория, нужно сначала хотя бы один город/остров симулировать, а там посмотрим, что получится.
74 Кб, 975x578Хоспаде, как же охуенно!
Играю в своего читерского сапёра и не могу остановиться! Игра мечты, просто!
В процессе игры возникла идея сделать игровую механику из этого чита. Сделать, скажем, три супер-скана на одну партию. Суперскан, это когда неправильно выставленный флажок при скане не взрывается. Таким образом, вероятность нерешаемых ситуаций типа этой >>83430 компенсируется супер-сканом.
Играю в своего читерского сапёра и не могу остановиться! Игра мечты, просто!
В процессе игры возникла идея сделать игровую механику из этого чита. Сделать, скажем, три супер-скана на одну партию. Суперскан, это когда неправильно выставленный флажок при скане не взрывается. Таким образом, вероятность нерешаемых ситуаций типа этой >>83430 компенсируется супер-сканом.
>>83502
Я разновидностями сапёров ранее не интересовался. Вчера, когда гуглил подробные описания правил, обнаружил в гугле прямо в окне поиска веб-виждет с довольно красочным сапёром. Зелёная лужайка, цветочки, бабочки. И БАЦ!
Я разновидностями сапёров ранее не интересовался. Вчера, когда гуглил подробные описания правил, обнаружил в гугле прямо в окне поиска веб-виждет с довольно красочным сапёром. Зелёная лужайка, цветочки, бабочки. И БАЦ!
И да, я получил невроз и охреневал всю ночь из-за попыток родить итерационный, императивный вариант открытия пустых кнопок. Настолько физически и ментально я не охуевал давно. Единственное, что пришло в голову это имитация распространения двухмерной волны в пространстве, переотращающейся от этой среды, рассеивающейся в ней.
587 Кб, 600x343>>83270
Написал генератор персонажей. Теперь буду прикручивать анимации
Написал генератор персонажей. Теперь буду прикручивать анимации
>>83517
Поверь, в нашем деле это никакого значения не имеет.
https://twitter.com/NFTtheft/status/1471640212090470404
Поверь, в нашем деле это никакого значения не имеет.
https://twitter.com/NFTtheft/status/1471640212090470404
>>83518
Хотелось бы быть честным с автором.
У тебя есть опыт в этом, анонче? У меня есть пара наработок которые выглядят получше
Хотелось бы быть честным с автором.
У тебя есть опыт в этом, анонче? У меня есть пара наработок которые выглядят получше
>>83473
Займись чем то более мелким, что потянешь. Это ты не потянешь. Могу предложить тебе какой нибудь космосим или стратегию.
Займись чем то более мелким, что потянешь. Это ты не потянешь. Могу предложить тебе какой нибудь космосим или стратегию.
>>83519
Мало ли что тебе там хочется. Если не своруешь и не запостишь на опенсеа - то сворую и запощу я. А если своруешь, то я все равно сворую и запощу.
Мало ли что тебе там хочется. Если не своруешь и не запостишь на опенсеа - то сворую и запощу я. А если своруешь, то я все равно сворую и запощу.
83 Кб, 802x593>>83508
Да её. Только там тааакооой головняк с построением вложенных меню, я в общем-то разобрался как делать, но пока не в кайф. И возможно есть поудобнее варианты. Потом поищу.
> Ты как кнопочку мену сделал? Я использовал menuButton
Да её. Только там тааакооой головняк с построением вложенных меню, я в общем-то разобрался как делать, но пока не в кайф. И возможно есть поудобнее варианты. Потом поищу.
>>83509
Ну делай на сигналах тогда, раз тебе не нравится рекурсия.
> я получил невроз и охреневал всю ночь из-за попыток родить итерационный, императивный вариант открытия пустых кнопок.
Ну делай на сигналах тогда, раз тебе не нравится рекурсия.
40 Кб, 551x473
21 Кб, 600x131>>83531
У меня на рекурсии ща. Но она не вывозит огромные поля 100х100 например, там и ФПС просаживаться начинает, а пикрелейтед переполняет стек вызовов. Выше о нём уже упомянули, что его в конфиге можно увеличить, но это игрушки дьявола, ежжи.
У меня на рекурсии ща. Но она не вывозит огромные поля 100х100 например, там и ФПС просаживаться начинает, а пикрелейтед переполняет стек вызовов. Выше о нём уже упомянули, что его в конфиге можно увеличить, но это игрушки дьявола, ежжи.
>>83532
Вот поэтому у меня и начался невроз от перенапряжения, я не смог ничего родить интересного, разве что деверо или распространение волны моделировать
Вот поэтому у меня и начался невроз от перенапряжения, я не смог ничего родить интересного, разве что деверо или распространение волны моделировать
>>83534
Спокойствие, бро. Нарисуй на бумаге блок-схему. Или в пейнте. Рисование схем помогает. По крайней мере мне.
Спокойствие, бро. Нарисуй на бумаге блок-схему. Или в пейнте. Рисование схем помогает. По крайней мере мне.
>>83511
Начал прикручивать анимации челикам. Никак не вразумлю как мне это сделать правильно и удобно.
Все кадры персонажа находятся на одном здоровом листе (пикрил 2)
Сейчас сделал так: В AnimationPlayer раскидал каждый кадр отдельно с нужными интервалами(Пик 2) Думаю, тут есть другой вариант. Как-то указать координаты первого и последнего кадра и интерполировать их с нужным фреймрейтом. Буду курит мануалы
Начал прикручивать анимации челикам. Никак не вразумлю как мне это сделать правильно и удобно.
Все кадры персонажа находятся на одном здоровом листе (пикрил 2)
Сейчас сделал так: В AnimationPlayer раскидал каждый кадр отдельно с нужными интервалами(Пик 2) Думаю, тут есть другой вариант. Как-то указать координаты первого и последнего кадра и интерполировать их с нужным фреймрейтом. Буду курит мануалы
>>83538
Так тоже стейтмашину закодить можно. И она предоставит тебе удобный интерфейс для манипулирования переходами любых анимаций в любые из кода.
Так тоже стейтмашину закодить можно. И она предоставит тебе удобный интерфейс для манипулирования переходами любых анимаций в любые из кода.
>>83539
А зачем она мне? У меня вопрос был в том как удобнее всего внутри Одной анимации кадры раскидывать
А зачем она мне? У меня вопрос был в том как удобнее всего внутри Одной анимации кадры раскидывать
>>83540
По порядку и раскидывай. У тебя спрайт-лист, так что обязательно делай дискретный режим анимации, он там в виде точечек иконкой показан.
По порядку и раскидывай. У тебя спрайт-лист, так что обязательно делай дискретный режим анимации, он там в виде точечек иконкой показан.
7 Кб, 1282x90>>83541
Как ни странно, я уже решил задачку, используя линейный режим.
Указал только первый и последний кадр
Как ни странно, я уже решил задачку, используя линейный режим.
Указал только первый и последний кадр
>>83541
В любом случае, спасибо анон, что уделил минутку
В любом случае, спасибо анон, что уделил минутку
>>83542
Могут быть потери кадров, ну смотри сам. Если что, держи в уме, что можно будет перейти на дискретный режим и все кадры поштучно выставить на таймлайн.
Могут быть потери кадров, ну смотри сам. Если что, держи в уме, что можно будет перейти на дискретный режим и все кадры поштучно выставить на таймлайн.
>>83546 (Del)
Я планировал так сделать. В самой первой гифке так и есть. Сейчас пришлось отказаться из-за того, что теперь персонаж состоит из множества слоев. Каждый слой содержит регион и порезан на кадры. В общем синхронизировать это все было бы проблематично
Я планировал так сделать. В самой первой гифке так и есть. Сейчас пришлось отказаться из-за того, что теперь персонаж состоит из множества слоев. Каждый слой содержит регион и порезан на кадры. В общем синхронизировать это все было бы проблематично
>>83545
Перепроверил. Кадры действительно теряются. Видимо придется использовать дискретный режим и ставить каждый кадр ручками
Перепроверил. Кадры действительно теряются. Видимо придется использовать дискретный режим и ставить каждый кадр ручками
>>83556 (Del)
Суть в том что эти листы спрайтов взаимозаменяемые. То есть я могу в коде указать нужный лист для прически, нужный для одежды, для глаз и так далее. Анимации для каждого итема одинаковые, поэтому при наложении можно будет манипулировать параметрами Frame/Frame coords синхронно. А AnimatedSprite не даст мне так просто поменять текстуру всего СпрайтЛиста, потому что не подгружает весь лист за раз, а создает текстуру для каждого кадра
Суть в том что эти листы спрайтов взаимозаменяемые. То есть я могу в коде указать нужный лист для прически, нужный для одежды, для глаз и так далее. Анимации для каждого итема одинаковые, поэтому при наложении можно будет манипулировать параметрами Frame/Frame coords синхронно. А AnimatedSprite не даст мне так просто поменять текстуру всего СпрайтЛиста, потому что не подгружает весь лист за раз, а создает текстуру для каждого кадра
>>83560 (Del)
Так я могу менять текстуру каждому элементу, а ты нет
Так я могу менять текстуру каждому элементу, а ты нет
>>83562 (Del)
Попробуй в коде поменять спрайт лист анимэйтед спрайту
Попробуй в коде поменять спрайт лист анимэйтед спрайту
>>83565 (Del)
У Анимэйтед спрайта нет текстуры. Есть ресурс СпрайтФреймс, в котором каждый кадр каждой анимации - отдельная текстура
У Анимэйтед спрайта нет текстуры. Есть ресурс СпрайтФреймс, в котором каждый кадр каждой анимации - отдельная текстура
>>83566 (Del)
А теперь посмотри как это делаю я - в одну строчку, используя обычный спрайт и плейер
А теперь посмотри как это делаю я - в одну строчку, используя обычный спрайт и плейер
Я не смог найти как код дробить по строкам без ругани. Как?
>>83625
Тоже тема. Думаю, что вызовом будет сделать змейку с крутым графоном, анимацией и всякого рода издёвками - типа отравленной еды или ломающегося забора, телепорта вне карты. Типа чел играет, ничего не предвещает беды, и тут хоба, и он проиграл.
>>83625
Тоже тема. Думаю, что вызовом будет сделать змейку с крутым графоном, анимацией и всякого рода издёвками - типа отравленной еды или ломающегося забора, телепорта вне карты. Типа чел играет, ничего не предвещает беды, и тут хоба, и он проиграл.
>>83631 (Del)
Кек, а я такой обратный символ ставил, потому что мельком видал в одном видосе, благодарю
Кек, а я такой обратный символ ставил, потому что мельком видал в одном видосе, благодарю
Чтож, произошло мною непредвиденное и мне удалось родить итерационную версию кода для попёра, теперь можно даже увеличить размеры поля хоть до 1024 на 1024
Жор памяти при карте 256 на 256 220+ МБ
Жор памяти при карте 256 на 256 220+ МБ
>>83523
Думал много раз об этом, но мне ничего из "мелкого" не доставляет удовольствия. Иногда записываю идеи таких игр или даже пытаюсь начать делать, но мотивации совершенно нет.
С чего именно такой вывод? Должна быть причина.
Из годных 3D признаю только Space Engineers и несколько похожих на неё игр, из 2D только Space Impossible. Всё остальное из жанра космосимов меня обычно не привлекает или не может надолго затянуть, следовательно, и мотивации делать нет. А перечисленные игры делать, по-моему, даже сложнее моего текущего проекта.
Никогда ими не увлекался. В конце 00-х играл в несколько разных, купленных на дисках, но весь мой игровой опыт очень казуальный - против игроков по сети я вообще ничего сделать не смог. Короче, жанр стратегий для меня закрыт.
Я не пытаюсь сделать клон или убийцу ГТА, она вообще в другом жанре. Даже симуляцию жителей пока всерьёз не рассматриваю. Сейчас главный вопрос в генерации интересного ландшафта/города, по которому можно бродить/ездить без просадки ФПС. Чисто "симулятор ходьбы" без сюжета. Потом можно будет думать дальше, что и как, нужно ли вообще и в каком виде...
И ещё я никуда не тороплюсь, лишь бы мотивация не заканчивалась и я не бросал проект в очередной раз на много месяцев. Иногда вот что-то не получается и сразу руки опускаются, не могу держать себя в руках и спокойно искать решение проблемы...
>Займись чем то более мелким, что потянешь.
Думал много раз об этом, но мне ничего из "мелкого" не доставляет удовольствия. Иногда записываю идеи таких игр или даже пытаюсь начать делать, но мотивации совершенно нет.
>Это ты не потянешь.
С чего именно такой вывод? Должна быть причина.
>космосим
Из годных 3D признаю только Space Engineers и несколько похожих на неё игр, из 2D только Space Impossible. Всё остальное из жанра космосимов меня обычно не привлекает или не может надолго затянуть, следовательно, и мотивации делать нет. А перечисленные игры делать, по-моему, даже сложнее моего текущего проекта.
>стратегию
Никогда ими не увлекался. В конце 00-х играл в несколько разных, купленных на дисках, но весь мой игровой опыт очень казуальный - против игроков по сети я вообще ничего сделать не смог. Короче, жанр стратегий для меня закрыт.
Я не пытаюсь сделать клон или убийцу ГТА, она вообще в другом жанре. Даже симуляцию жителей пока всерьёз не рассматриваю. Сейчас главный вопрос в генерации интересного ландшафта/города, по которому можно бродить/ездить без просадки ФПС. Чисто "симулятор ходьбы" без сюжета. Потом можно будет думать дальше, что и как, нужно ли вообще и в каком виде...
И ещё я никуда не тороплюсь, лишь бы мотивация не заканчивалась и я не бросал проект в очередной раз на много месяцев. Иногда вот что-то не получается и сразу руки опускаются, не могу держать себя в руках и спокойно искать решение проблемы...
172 Кб, 1024x600Я в каком-то из предыдущих тредов жаловался, что у меня чанковая система не даёт прироста скорости и queue_free() сажает фпс. Так вот... Сегодня наконец-то вернул чанковую систему на место. На маленькой карте всё нормально, но карта размером 10х10 км сажала фпс до 10, при том стабильно. Профайлер ничего не мог сказать, кроме того, что на один кадр тратится очень много миллисекунд. В конце концов меня осенило, что могло вызывать такую нагрузку - я выключил миникарту и получил 100-200 фпс на той же 10х10 км карте! И даже регулярное освобождение и пересоздание чанков в движении не вызывает таких тормозов, как перерисовка моей миникарты. Можно даже рандомно телепортироваться по карте и чанки будут успевать пересоздаваться, не создавая существенного лага.
Короче, вдруг кому поможет эта информация: несмотря на то, что _draw() вызывается один раз (повторный вызов через update()), все вызванные в нём функции рисования кэшируются и вызываются каждый кадр, вместо того, чтобы кэшировать изображение как текстуру. Если этих функций очень много (как у меня на карте большого мира), то перерисовка будет очень долгой. Если поместить такую ноду во Viewport, она будет перерисовываться каждый раз, когда обновляется вьюпорт. Собственно, решение: ставить отрисовку Viewport в режим ONCE, когда нужно обновить карту, а всё остальное время использовать полученную таким образом текстуру.
На скриншоте карта размером 4х4 км, карта 10х10км выглядит как губка или кусок сыра (нужно переделывать генератор), но производительность у них одинаковая. Ещё многое можно оптимизировать и многое нужно добавить, но производительность на данный момент радует. Кто там говорил, что в Godot 3.х нельзя сделать опенворлд? Всё можно, если постараться.
Короче, вдруг кому поможет эта информация: несмотря на то, что _draw() вызывается один раз (повторный вызов через update()), все вызванные в нём функции рисования кэшируются и вызываются каждый кадр, вместо того, чтобы кэшировать изображение как текстуру. Если этих функций очень много (как у меня на карте большого мира), то перерисовка будет очень долгой. Если поместить такую ноду во Viewport, она будет перерисовываться каждый раз, когда обновляется вьюпорт. Собственно, решение: ставить отрисовку Viewport в режим ONCE, когда нужно обновить карту, а всё остальное время использовать полученную таким образом текстуру.
На скриншоте карта размером 4х4 км, карта 10х10км выглядит как губка или кусок сыра (нужно переделывать генератор), но производительность у них одинаковая. Ещё многое можно оптимизировать и многое нужно добавить, но производительность на данный момент радует. Кто там говорил, что в Godot 3.х нельзя сделать опенворлд? Всё можно, если постараться.
6 Кб, 185x34>>83714
ЕБАТЬ ТРИ КУБА НА СЦЕНЕ ОТКУДА ТЫСЯЧА ДРОУКОЛЛОВ ПРЕСВЯТАЯ ГОДОТЯ
ЕБАТЬ ТРИ КУБА НА СЦЕНЕ ОТКУДА ТЫСЯЧА ДРОУКОЛЛОВ ПРЕСВЯТАЯ ГОДОТЯ
>>83715
Могу предположить, что т.к. куллинга нет, рендерится вся карта, попавшая в камеру, даже далекие объекты, которые не видно.
И каждый кубик рисуется отдельным драв коллом, т.к. батчинга статики нет.
Могу предположить, что т.к. куллинга нет, рендерится вся карта, попавшая в камеру, даже далекие объекты, которые не видно.
И каждый кубик рисуется отдельным драв коллом, т.к. батчинга статики нет.
9,5 Мб, 1862x943>>83536
Замутил полноценный редактор персонажей с настройкой всех элементов. Также можно менять анимации. Самое приятное что я реализовал все так, что мне при добавлении какого-то нового элемента гардероба ВООБЩЕ не понадобится трогать код. Тупо закинуть png нужной шапкой в папку и готово.
Этот редактор больше для целей разработки. Так я смогу настроить своих npc и видеть как они будут выглядеть в игре. После этого просто закину обьект персонажа в сцену и в экспортных переменных укажу ему нужные айди элементов гардероба.
Замутил полноценный редактор персонажей с настройкой всех элементов. Также можно менять анимации. Самое приятное что я реализовал все так, что мне при добавлении какого-то нового элемента гардероба ВООБЩЕ не понадобится трогать код. Тупо закинуть png нужной шапкой в папку и готово.
Этот редактор больше для целей разработки. Так я смогу настроить своих npc и видеть как они будут выглядеть в игре. После этого просто закину обьект персонажа в сцену и в экспортных переменных укажу ему нужные айди элементов гардероба.
>>83701
Никто не тянет чего то большого. Все успешные игры в ГД это одна-две механики и кучу полировки. Вроде мобилки костяк которой пишется за день, а дальше полируется. Шанс что ты шиз аутист который сделает дварфортресс около нулевой. Если это просто бродилки, то ты справишься.
>>83719
Тебе нужны только бомбы.
Никто не тянет чего то большого. Все успешные игры в ГД это одна-две механики и кучу полировки. Вроде мобилки костяк которой пишется за день, а дальше полируется. Шанс что ты шиз аутист который сделает дварфортресс около нулевой. Если это просто бродилки, то ты справишься.
>>83719
Тебе нужны только бомбы.
>>83785
И производительность стремительно летит на дно.
Ты как области открываешь? Как определяешь цифру, что указывает наличие рядом мин? Налету?
И производительность стремительно летит на дно.
Ты как области открываешь? Как определяешь цифру, что указывает наличие рядом мин? Налету?
>>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 обслуживает с десяток домов, многовато на мой взгляд, а по расстоянию пешком дойти чуть ли не проще, чем на машине. Чёт даже обидно, что машины как таковые становятся бесполезны, если делать компактный город с адекватным числом жителей, поэтому я и стараюсь отладить систему чанков - так хотя бы можно растянуть маленький город на большую площадь, снабдив декорациями (парки, площади, мосты через реки и т.п. нежилые территории, интересные для исследования).
Вот что реально плохо - у меня за все эти годы не сформировалось чёткое видение проекта, с каждой попыткой всё меняется очень сильно. Пытался писать диздок, но там всё слишком абстрактно получилось. Каждый раз приходится напрягать извилины в стиле "так, эту фичу кое-как набросал, а что мне ещё хотелось сделать из того, что я могу сделать прямо сейчас?" - никакие планы и заметки не помогают, либо слишком абстрактно, либо нельзя сделать без какой-то фундаментальной системы, которую ещё придумать нужно. Это, как я понимаю, одна из основных причин медленной разработки многих инди-проектов, т.к. код и контент сделать не так уж и сложно, сложно придумать, что именно тебе нужно делать (в рамках реализуемого, нереализуемые идеи любой напридумывает). Видел много проектов, где какие-нибудь ассеты понаделали, а игры так и не получилось, хотя расставить ассеты по сцене - совсем уж механическая работа. Или получилось что-то банальное и скучное, т.к. скопипастили чужое, не осилив придумывать что-то своё...
На самом деле 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 обслуживает с десяток домов, многовато на мой взгляд, а по расстоянию пешком дойти чуть ли не проще, чем на машине. Чёт даже обидно, что машины как таковые становятся бесполезны, если делать компактный город с адекватным числом жителей, поэтому я и стараюсь отладить систему чанков - так хотя бы можно растянуть маленький город на большую площадь, снабдив декорациями (парки, площади, мосты через реки и т.п. нежилые территории, интересные для исследования).
Вот что реально плохо - у меня за все эти годы не сформировалось чёткое видение проекта, с каждой попыткой всё меняется очень сильно. Пытался писать диздок, но там всё слишком абстрактно получилось. Каждый раз приходится напрягать извилины в стиле "так, эту фичу кое-как набросал, а что мне ещё хотелось сделать из того, что я могу сделать прямо сейчас?" - никакие планы и заметки не помогают, либо слишком абстрактно, либо нельзя сделать без какой-то фундаментальной системы, которую ещё придумать нужно. Это, как я понимаю, одна из основных причин медленной разработки многих инди-проектов, т.к. код и контент сделать не так уж и сложно, сложно придумать, что именно тебе нужно делать (в рамках реализуемого, нереализуемые идеи любой напридумывает). Видел много проектов, где какие-нибудь ассеты понаделали, а игры так и не получилось, хотя расставить ассеты по сцене - совсем уж механическая работа. Или получилось что-то банальное и скучное, т.к. скопипастили чужое, не осилив придумывать что-то своё...
>>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 обслуживает с десяток домов, многовато на мой взгляд, а по расстоянию пешком дойти чуть ли не проще, чем на машине. Чёт даже обидно, что машины как таковые становятся бесполезны, если делать компактный город с адекватным числом жителей, поэтому я и стараюсь отладить систему чанков - так хотя бы можно растянуть маленький город на большую площадь, снабдив декорациями (парки, площади, мосты через реки и т.п. нежилые территории, интересные для исследования).
Вот что реально плохо - у меня за все эти годы не сформировалось чёткое видение проекта, с каждой попыткой всё меняется очень сильно. Пытался писать диздок, но там всё слишком абстрактно получилось. Каждый раз приходится напрягать извилины в стиле "так, эту фичу кое-как набросал, а что мне ещё хотелось сделать из того, что я могу сделать прямо сейчас?" - никакие планы и заметки не помогают, либо слишком абстрактно, либо нельзя сделать без какой-то фундаментальной системы, которую ещё придумать нужно. Это, как я понимаю, одна из основных причин медленной разработки многих инди-проектов, т.к. код и контент сделать не так уж и сложно, сложно придумать, что именно тебе нужно делать (в рамках реализуемого, нереализуемые идеи любой напридумывает). Видел много проектов, где какие-нибудь ассеты понаделали, а игры так и не получилось, хотя расставить ассеты по сцене - совсем уж механическая работа. Или получилось что-то банальное и скучное, т.к. скопипастили чужое, не осилив придумывать что-то своё...
На самом деле 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 обслуживает с десяток домов, многовато на мой взгляд, а по расстоянию пешком дойти чуть ли не проще, чем на машине. Чёт даже обидно, что машины как таковые становятся бесполезны, если делать компактный город с адекватным числом жителей, поэтому я и стараюсь отладить систему чанков - так хотя бы можно растянуть маленький город на большую площадь, снабдив декорациями (парки, площади, мосты через реки и т.п. нежилые территории, интересные для исследования).
Вот что реально плохо - у меня за все эти годы не сформировалось чёткое видение проекта, с каждой попыткой всё меняется очень сильно. Пытался писать диздок, но там всё слишком абстрактно получилось. Каждый раз приходится напрягать извилины в стиле "так, эту фичу кое-как набросал, а что мне ещё хотелось сделать из того, что я могу сделать прямо сейчас?" - никакие планы и заметки не помогают, либо слишком абстрактно, либо нельзя сделать без какой-то фундаментальной системы, которую ещё придумать нужно. Это, как я понимаю, одна из основных причин медленной разработки многих инди-проектов, т.к. код и контент сделать не так уж и сложно, сложно придумать, что именно тебе нужно делать (в рамках реализуемого, нереализуемые идеи любой напридумывает). Видел много проектов, где какие-нибудь ассеты понаделали, а игры так и не получилось, хотя расставить ассеты по сцене - совсем уж механическая работа. Или получилось что-то банальное и скучное, т.к. скопипастили чужое, не осилив придумывать что-то своё...
206 Кб, 1022x590>>83809
Стыдно признать, но я всё понял. Просадка фпс на том скриншоте не из-за дроуколлов, а из-за текстур с полупрозрачностью. Я уже давно об этом догадывался, но как-то сомневался - всё же во многих играх деревья именно такие, с полупрозрачностью.
Вот скриншот сцены, где те же 5000 дроуколлов, но при этом 250 фпс. Похоже, придётся все деревья делать в том же стиле, без прозрачных квадов-листьев? Обидно немного, но ладно. Мне нравилась идея деревьев с плоскими листьями, но их долго рисовать (лол, как вручную, так и программно)...
>пик1
Стыдно признать, но я всё понял. Просадка фпс на том скриншоте не из-за дроуколлов, а из-за текстур с полупрозрачностью. Я уже давно об этом догадывался, но как-то сомневался - всё же во многих играх деревья именно такие, с полупрозрачностью.
Вот скриншот сцены, где те же 5000 дроуколлов, но при этом 250 фпс. Похоже, придётся все деревья делать в том же стиле, без прозрачных квадов-листьев? Обидно немного, но ладно. Мне нравилась идея деревьев с плоскими листьями, но их долго рисовать (лол, как вручную, так и программно)...
>>83880
Антон, а может просто сделаешь гоначки с ловполе графином? С развилками там, ямами и грузовиком куном?
Антон, а может просто сделаешь гоначки с ловполе графином? С развилками там, ямами и грузовиком куном?
>>83898
Анон, а может, ты просто ответишь ему на вопрос? Я вот тоже может быть в будущем планирую использовать текстуры с прозрачностью, хотелось бы надеяться, что годот меня в этом плане не наебет.
Анон, а может, ты просто ответишь ему на вопрос? Я вот тоже может быть в будущем планирую использовать текстуры с прозрачностью, хотелось бы надеяться, что годот меня в этом плане не наебет.
>>83909
Прозрачность всегда жрала кучу ресурсов как проца в 3дмаксе и подобном, так и видяхи в игровых движках. Может видал орные скрины с соснолей, где вместо полупрозрачности битовая шахматная маска.
Прозрачность всегда жрала кучу ресурсов как проца в 3дмаксе и подобном, так и видяхи в игровых движках. Может видал орные скрины с соснолей, где вместо полупрозрачности битовая шахматная маска.
>>83925 (Del)
Да я вообще не собирался использовать полупрозрачность. То бишь нужно в сторону альфа-масок смотреть и все дела?
Да я вообще не собирался использовать полупрозрачность. То бишь нужно в сторону альфа-масок смотреть и все дела?
>>83938
Ну меня интересует лоу-поли с пикселями и без всякого там шейдинга. Я так понимаю, нужно врубить Unshaded и отрубить Specular в первую очередь?
Ну меня интересует лоу-поли с пикселями и без всякого там шейдинга. Я так понимаю, нужно врубить Unshaded и отрубить Specular в первую очередь?
5,6 Мб, webm,720x420, 2:43
>>83898
Ты имеешь в виду без генерации карты? Не, гонки меня никогда особо не интересовали, кроме гонок с реалистичной физикой повреждений (FlatOut), которую реализовать слишком сложно. В остальном, гонки - это соревнования, а я такое не люблю, т.к. могу выиграть лишь против очень слабых ботов, которые специально поддаются. Я хочу больше созерцательную игру, за которой было бы интересно наблюдать, не пытаясь никого обогнать или перебороть. Поэтому и начал с генератора местности, за его работой интересно наблюдать с самого начала, даже если результат очень примитивен. Потом можно рандомные машинки и болванчиков пустить, пока без какой-либо симуляции, по случайным маршрутам...
Собственно уже несколько дней думаю над тем, как лучше всего реализовать холмы и овраги. Пока что я понял только то, что просто взять и разбить всё на треугольники не получится - нужно ещё определять ориентацию треугольников.
>>83907 (Del)
Именно так, у меня там очень много полупрозрачных пикселей на листве. А разве можно сделать листву без полупрозрачных пикселей? Я пытался обрезать все полупрозрачные, выглядит отвратительно (хотя и оригинал я по-быстрому накидал только для тестов).
Знаю, но ведь билборды будут иметь полупрозрачные пиксели? В мануале Godot сказано, что нужно балансировать между билдбордами и полупрозрачными пикселями, т.е. нельзя просто взять и всё заменить билбордами. К тому же они не спасут от лишних дроуколлов.
Да тут такая фигня... В общем, я пытался увеличить размер чанка, чтобы впоследствии можно было объединять объекты внутри этого чанка, но на практике быстрее всего работают мелкие чанки (48х48 метров). Будет ли эффективен мультимеш для, грубо говоря, 3-6 одинаковых деревьев? Я читал где-то, что польза от него начинается с десятков, если не сотен объектов.
Но про зависимость от расстояния и т.п. - это всё правильно, просто пока я не уверен, стоит ли этим заниматься прямо сейчас. Сперва нужно заменить "плитки" чем-то другим, надоело по голой плоскости кататься. Хотя от бордюров я в своё время отказался, потому что кинематикбоди принципиально не способен на них запрыгивать, если коллиженшейп в форме капсулы... Нужно попробовать коллиженшейп в форме луча, как где-то рекомендовали.
>может просто сделаешь гоначки с ловполе графином?
Ты имеешь в виду без генерации карты? Не, гонки меня никогда особо не интересовали, кроме гонок с реалистичной физикой повреждений (FlatOut), которую реализовать слишком сложно. В остальном, гонки - это соревнования, а я такое не люблю, т.к. могу выиграть лишь против очень слабых ботов, которые специально поддаются. Я хочу больше созерцательную игру, за которой было бы интересно наблюдать, не пытаясь никого обогнать или перебороть. Поэтому и начал с генератора местности, за его работой интересно наблюдать с самого начала, даже если результат очень примитивен. Потом можно рандомные машинки и болванчиков пустить, пока без какой-либо симуляции, по случайным маршрутам...
>с ямами
Собственно уже несколько дней думаю над тем, как лучше всего реализовать холмы и овраги. Пока что я понял только то, что просто взять и разбить всё на треугольники не получится - нужно ещё определять ориентацию треугольников.
>>83907 (Del)
>проверить что у тебя текстура именно с прозрачностью, а не полу-прозрачная
Именно так, у меня там очень много полупрозрачных пикселей на листве. А разве можно сделать листву без полупрозрачных пикселей? Я пытался обрезать все полупрозрачные, выглядит отвратительно (хотя и оригинал я по-быстрому накидал только для тестов).
>использовать билборды (плоские спрайты) после определенного расстояния
Знаю, но ведь билборды будут иметь полупрозрачные пиксели? В мануале Godot сказано, что нужно балансировать между билдбордами и полупрозрачными пикселями, т.е. нельзя просто взять и всё заменить билбордами. К тому же они не спасут от лишних дроуколлов.
>Также одинаковые деревья имеет смысл загонять в мультимеш, если ты еще не. Только не все на уровне, а скажем по мультимешу на чанк.
Да тут такая фигня... В общем, я пытался увеличить размер чанка, чтобы впоследствии можно было объединять объекты внутри этого чанка, но на практике быстрее всего работают мелкие чанки (48х48 метров). Будет ли эффективен мультимеш для, грубо говоря, 3-6 одинаковых деревьев? Я читал где-то, что польза от него начинается с десятков, если не сотен объектов.
Но про зависимость от расстояния и т.п. - это всё правильно, просто пока я не уверен, стоит ли этим заниматься прямо сейчас. Сперва нужно заменить "плитки" чем-то другим, надоело по голой плоскости кататься. Хотя от бордюров я в своё время отказался, потому что кинематикбоди принципиально не способен на них запрыгивать, если коллиженшейп в форме капсулы... Нужно попробовать коллиженшейп в форме луча, как где-то рекомендовали.
5,6 Мб, webm,720x420, 2:43
>>83898
Ты имеешь в виду без генерации карты? Не, гонки меня никогда особо не интересовали, кроме гонок с реалистичной физикой повреждений (FlatOut), которую реализовать слишком сложно. В остальном, гонки - это соревнования, а я такое не люблю, т.к. могу выиграть лишь против очень слабых ботов, которые специально поддаются. Я хочу больше созерцательную игру, за которой было бы интересно наблюдать, не пытаясь никого обогнать или перебороть. Поэтому и начал с генератора местности, за его работой интересно наблюдать с самого начала, даже если результат очень примитивен. Потом можно рандомные машинки и болванчиков пустить, пока без какой-либо симуляции, по случайным маршрутам...
Собственно уже несколько дней думаю над тем, как лучше всего реализовать холмы и овраги. Пока что я понял только то, что просто взять и разбить всё на треугольники не получится - нужно ещё определять ориентацию треугольников.
>>83907 (Del)
Именно так, у меня там очень много полупрозрачных пикселей на листве. А разве можно сделать листву без полупрозрачных пикселей? Я пытался обрезать все полупрозрачные, выглядит отвратительно (хотя и оригинал я по-быстрому накидал только для тестов).
Знаю, но ведь билборды будут иметь полупрозрачные пиксели? В мануале Godot сказано, что нужно балансировать между билдбордами и полупрозрачными пикселями, т.е. нельзя просто взять и всё заменить билбордами. К тому же они не спасут от лишних дроуколлов.
Да тут такая фигня... В общем, я пытался увеличить размер чанка, чтобы впоследствии можно было объединять объекты внутри этого чанка, но на практике быстрее всего работают мелкие чанки (48х48 метров). Будет ли эффективен мультимеш для, грубо говоря, 3-6 одинаковых деревьев? Я читал где-то, что польза от него начинается с десятков, если не сотен объектов.
Но про зависимость от расстояния и т.п. - это всё правильно, просто пока я не уверен, стоит ли этим заниматься прямо сейчас. Сперва нужно заменить "плитки" чем-то другим, надоело по голой плоскости кататься. Хотя от бордюров я в своё время отказался, потому что кинематикбоди принципиально не способен на них запрыгивать, если коллиженшейп в форме капсулы... Нужно попробовать коллиженшейп в форме луча, как где-то рекомендовали.
>может просто сделаешь гоначки с ловполе графином?
Ты имеешь в виду без генерации карты? Не, гонки меня никогда особо не интересовали, кроме гонок с реалистичной физикой повреждений (FlatOut), которую реализовать слишком сложно. В остальном, гонки - это соревнования, а я такое не люблю, т.к. могу выиграть лишь против очень слабых ботов, которые специально поддаются. Я хочу больше созерцательную игру, за которой было бы интересно наблюдать, не пытаясь никого обогнать или перебороть. Поэтому и начал с генератора местности, за его работой интересно наблюдать с самого начала, даже если результат очень примитивен. Потом можно рандомные машинки и болванчиков пустить, пока без какой-либо симуляции, по случайным маршрутам...
>с ямами
Собственно уже несколько дней думаю над тем, как лучше всего реализовать холмы и овраги. Пока что я понял только то, что просто взять и разбить всё на треугольники не получится - нужно ещё определять ориентацию треугольников.
>>83907 (Del)
>проверить что у тебя текстура именно с прозрачностью, а не полу-прозрачная
Именно так, у меня там очень много полупрозрачных пикселей на листве. А разве можно сделать листву без полупрозрачных пикселей? Я пытался обрезать все полупрозрачные, выглядит отвратительно (хотя и оригинал я по-быстрому накидал только для тестов).
>использовать билборды (плоские спрайты) после определенного расстояния
Знаю, но ведь билборды будут иметь полупрозрачные пиксели? В мануале Godot сказано, что нужно балансировать между билдбордами и полупрозрачными пикселями, т.е. нельзя просто взять и всё заменить билбордами. К тому же они не спасут от лишних дроуколлов.
>Также одинаковые деревья имеет смысл загонять в мультимеш, если ты еще не. Только не все на уровне, а скажем по мультимешу на чанк.
Да тут такая фигня... В общем, я пытался увеличить размер чанка, чтобы впоследствии можно было объединять объекты внутри этого чанка, но на практике быстрее всего работают мелкие чанки (48х48 метров). Будет ли эффективен мультимеш для, грубо говоря, 3-6 одинаковых деревьев? Я читал где-то, что польза от него начинается с десятков, если не сотен объектов.
Но про зависимость от расстояния и т.п. - это всё правильно, просто пока я не уверен, стоит ли этим заниматься прямо сейчас. Сперва нужно заменить "плитки" чем-то другим, надоело по голой плоскости кататься. Хотя от бордюров я в своё время отказался, потому что кинематикбоди принципиально не способен на них запрыгивать, если коллиженшейп в форме капсулы... Нужно попробовать коллиженшейп в форме луча, как где-то рекомендовали.
На реддите такая большая драма вокруг "сексуализации" Годетты разгорелась, мол, бикини не попадает в code of conduct движка и ущемляет права малолетних девочек, которые могли заглянуть в официальный реддит движка и - о, боже! - увидеть Годетту в купальнике (даже не микро). Аргументы уровня "мы не на пляже" и "подумайте о тех, кто чувствительнее нас" прилагаются. Кто чувствителен к купальникам и может ими оскорбиться? Арабы? А меня они оскорбляют тем, во что наряжают своих женщин. Почему никто не думает о моих чувствах, когда публикует рисунки этих... людей или добавляет их в игру, тогда как о "неприемлемых" совершенно невинных купальниках заботятся все?
Но это всё мелочи.
Важны всего две вещи:
1. Где достать оригинал картинки?
2. Где искать больше артов с Годеттой?
Это очень важно для разработки игры на Godot.
В идеале, конечно, нужна сборка движка Godette Engine.
>>83153
Ты обещал пак Годетты, где он?
Но это всё мелочи.
Важны всего две вещи:
1. Где достать оригинал картинки?
2. Где искать больше артов с Годеттой?
Это очень важно для разработки игры на Godot.
В идеале, конечно, нужна сборка движка Godette Engine.
>>83153
Ты обещал пак Годетты, где он?
>>84134
Спасибо, схоронил.
Тоже считаю Годетту робо-тян. На реддите одна тян сказала что-то вроде "у Годетты нет каноничного возраста, но т.к. движок ориентирован на обучение новичков, я воспринимаю Годетту как подростка, поэтому бикини на ней неуместно". Лол! А я воспринимаю Годетту как абстрактного робота-гиноида, потому что она маскот компьютерной программы. И бикини на ней совершенно уместно, потому что она, как любой человекоподобный робот, стремится подражать людям, чтобы быть привлекательной для них. Тем более что оригинальный маскот однозначно робот, с чего вдруг Годетта должна быть девочкой-подростком?
Кстати, где найти оригинальную модель с пикрила? Ссылка из поисковика ведёт на турбосквид, но не на страницу модели, а общий список моделей...
Спасибо, схоронил.
>1000Кб, 912x1375
Тоже считаю Годетту робо-тян. На реддите одна тян сказала что-то вроде "у Годетты нет каноничного возраста, но т.к. движок ориентирован на обучение новичков, я воспринимаю Годетту как подростка, поэтому бикини на ней неуместно". Лол! А я воспринимаю Годетту как абстрактного робота-гиноида, потому что она маскот компьютерной программы. И бикини на ней совершенно уместно, потому что она, как любой человекоподобный робот, стремится подражать людям, чтобы быть привлекательной для них. Тем более что оригинальный маскот однозначно робот, с чего вдруг Годетта должна быть девочкой-подростком?
Кстати, где найти оригинальную модель с пикрила? Ссылка из поисковика ведёт на турбосквид, но не на страницу модели, а общий список моделей...
>>84133
Я слышал, что там изначально была с ней драма, что выбрали на конкурсе самый хуевый вариант маскота, чтобы ублажить транссексуалов. Или это тролли с /агдг/ напиздели?
Я слышал, что там изначально была с ней драма, что выбрали на конкурсе самый хуевый вариант маскота, чтобы ублажить транссексуалов. Или это тролли с /агдг/ напиздели?
>>84139
Кого именно? Годетту? Годетту сделала жена Хуана к релизу 3.0, просто по фану. Оригинальный твит:
https://twitter.com/reduzio/status/958305883976536064
А безымянного (?) робота не знаю кто сделал, но их вроде несколько вариантов. Один на логотипе, другой(ие) в демках. Вряд ли робот мог "ублажить транссексуалов", он же бесполый и совсем на человека не похож, а трансгендеры поддерживают дискриминацию по полу.
>>84152 (Del)
Но логика как у ребёнка. Если уж движок нацелен на обучение детей, то и Годетта должна быть взрослой учительницей в униформе с указкой, а не школьницей. Это ведь она учит тебя разрабатывать игры, а не ты её учишь, если только ты не разработчик движка. Даже странно, что до сих пор не видно артов, где Годетта была бы милфой с садистским уклоном и в униформе, имя вроде подходит.
>выбрали на конкурсе
Кого именно? Годетту? Годетту сделала жена Хуана к релизу 3.0, просто по фану. Оригинальный твит:
https://twitter.com/reduzio/status/958305883976536064
А безымянного (?) робота не знаю кто сделал, но их вроде несколько вариантов. Один на логотипе, другой(ие) в демках. Вряд ли робот мог "ублажить транссексуалов", он же бесполый и совсем на человека не похож, а трансгендеры поддерживают дискриминацию по полу.
>>84152 (Del)
Но логика как у ребёнка. Если уж движок нацелен на обучение детей, то и Годетта должна быть взрослой учительницей в униформе с указкой, а не школьницей. Это ведь она учит тебя разрабатывать игры, а не ты её учишь, если только ты не разработчик движка. Даже странно, что до сих пор не видно артов, где Годетта была бы милфой с садистским уклоном и в униформе, имя вроде подходит.
>>83907 (Del)
Забавно, но галочку Transparent я вообще не трогал, и у меня уже был включён Alpha Scissor. Поиграв галочками я прихожу к выводу, что Alpha Scissor жрёт больше ресурсов чем Transparent, однако материал с Transparent не способен отбрасывать тень - с одной стороны, это снижает число дроуколлов (источник света не пытается рендерить всю эту листву), с другой вынуждает создавать скрытые полигоны только для отбрасывания тени (если нужна).
При этом текстуру я переработал, сделав все полупрозрачные пиксели непрозрачными и уменьшив размер. Судя по всему, Alpha Scissor одинаково грузит игру, независимо от количества полупрозрачных пикселей - даже ползунок ничего не меняет, что в 0.0 (все пиксели отображаются), что в 1.0 (текстура полностью скрыта), нагрузка одинаковая. Я не понял, как конвертировать Spatial Material в код шейдера (в каком-то туториале на Ютубе видел, что так можно сделать), но подозреваю, что там на каждый пиксель идёт проверка условия, а видеокарты не любят условные операторы.
С галкой Transparent другие проблемы - мало того, что даже полностью непрозрачная текстура перестаёт отбрасывать тень с этой галкой, так ещё появляются различные глюки (особенно заметно на горизонте и под какими-то рандомными углами зрения) и внутренняя сторона полигона как-то странно выглядит. Кстати, про тени больше всего обидно, я ожидал, что смогу сделать цветные тени, просто пропуская свет через полупрозрачные предметы, но, видимо, это настолько затратная операция, что её даже не реализовали. А вот в Blender особых проблем с полупрозрачностью я не испытывал, разве что выглядит она там довольно странно (несколько режимов).
В общем, ну их, эти дырявые текстуры, лучше сделать какие-нибудь процедурные деревья из абстрактных кубов - и быстрее, и геометрически может быть интереснее, и визуально может оказаться привлекательнее. И не придётся ничего рисовать вручную...
>>83909
Планируй так, чтобы их было мало. Лучше полигонами выстроить сложную поверхность с дырками, чем текстурами, потому что полигоны рисовать сегодня можно миллионами без проблем. К тому же геометрия, по-моему, меньше весит, чем текстуры, т.е. лучше пара лишних полигонов, чем рисунок на текстуре, если тебе нужно что-то очень простое. 3D - это как векторная графика (за исключением вокселей), текстуры - это растровая графика, отсюда все особенности, преимущества и ограничения. Возможно, тебе вообще воксели нужны, попробуй MagicaVoxel, вдруг понравится.
>>83940
В первую очередь выключи Filter в панели импорта текстуры, это позволит увидеть тексели без размазывания. Остальное легко найти на ютубе, видел там несколько туториалов.
Да, Unshaded отключает тени, блики и т.д. Но вряд ли тебе нужно 3D совсем без шейдинга, возможно, ты хочешь пиксельный шейдинг? Можно сделать пиксельные нормалмапы, чтобы источники света делали на объектах эффект пиксельного освещения. Вообще, экспериментируй, там не так много параметров. Сложности начнутся, если захочешь чего-то особенного, тут нужно свой шейдер писать.
>Тебе надо проверить не с 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 совсем без шейдинга, возможно, ты хочешь пиксельный шейдинг? Можно сделать пиксельные нормалмапы, чтобы источники света делали на объектах эффект пиксельного освещения. Вообще, экспериментируй, там не так много параметров. Сложности начнутся, если захочешь чего-то особенного, тут нужно свой шейдер писать.
>>83907 (Del)
Забавно, но галочку Transparent я вообще не трогал, и у меня уже был включён Alpha Scissor. Поиграв галочками я прихожу к выводу, что Alpha Scissor жрёт больше ресурсов чем Transparent, однако материал с Transparent не способен отбрасывать тень - с одной стороны, это снижает число дроуколлов (источник света не пытается рендерить всю эту листву), с другой вынуждает создавать скрытые полигоны только для отбрасывания тени (если нужна).
При этом текстуру я переработал, сделав все полупрозрачные пиксели непрозрачными и уменьшив размер. Судя по всему, Alpha Scissor одинаково грузит игру, независимо от количества полупрозрачных пикселей - даже ползунок ничего не меняет, что в 0.0 (все пиксели отображаются), что в 1.0 (текстура полностью скрыта), нагрузка одинаковая. Я не понял, как конвертировать Spatial Material в код шейдера (в каком-то туториале на Ютубе видел, что так можно сделать), но подозреваю, что там на каждый пиксель идёт проверка условия, а видеокарты не любят условные операторы.
С галкой Transparent другие проблемы - мало того, что даже полностью непрозрачная текстура перестаёт отбрасывать тень с этой галкой, так ещё появляются различные глюки (особенно заметно на горизонте и под какими-то рандомными углами зрения) и внутренняя сторона полигона как-то странно выглядит. Кстати, про тени больше всего обидно, я ожидал, что смогу сделать цветные тени, просто пропуская свет через полупрозрачные предметы, но, видимо, это настолько затратная операция, что её даже не реализовали. А вот в Blender особых проблем с полупрозрачностью я не испытывал, разве что выглядит она там довольно странно (несколько режимов).
В общем, ну их, эти дырявые текстуры, лучше сделать какие-нибудь процедурные деревья из абстрактных кубов - и быстрее, и геометрически может быть интереснее, и визуально может оказаться привлекательнее. И не придётся ничего рисовать вручную...
>>83909
Планируй так, чтобы их было мало. Лучше полигонами выстроить сложную поверхность с дырками, чем текстурами, потому что полигоны рисовать сегодня можно миллионами без проблем. К тому же геометрия, по-моему, меньше весит, чем текстуры, т.е. лучше пара лишних полигонов, чем рисунок на текстуре, если тебе нужно что-то очень простое. 3D - это как векторная графика (за исключением вокселей), текстуры - это растровая графика, отсюда все особенности, преимущества и ограничения. Возможно, тебе вообще воксели нужны, попробуй MagicaVoxel, вдруг понравится.
>>83940
В первую очередь выключи Filter в панели импорта текстуры, это позволит увидеть тексели без размазывания. Остальное легко найти на ютубе, видел там несколько туториалов.
Да, Unshaded отключает тени, блики и т.д. Но вряд ли тебе нужно 3D совсем без шейдинга, возможно, ты хочешь пиксельный шейдинг? Можно сделать пиксельные нормалмапы, чтобы источники света делали на объектах эффект пиксельного освещения. Вообще, экспериментируй, там не так много параметров. Сложности начнутся, если захочешь чего-то особенного, тут нужно свой шейдер писать.
>Тебе надо проверить не с 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 совсем без шейдинга, возможно, ты хочешь пиксельный шейдинг? Можно сделать пиксельные нормалмапы, чтобы источники света делали на объектах эффект пиксельного освещения. Вообще, экспериментируй, там не так много параметров. Сложности начнутся, если захочешь чего-то особенного, тут нужно свой шейдер писать.
>>84158
Воксели мне точно не нужны, ненавижу воксели.
Я знаю, что мне нужно, ни шейдинг, ни нормалмапы мне не нужны.
>Возможно, тебе вообще воксели нужны, попробуй MagicaVoxel, вдруг понравится.
Воксели мне точно не нужны, ненавижу воксели.
>Но вряд ли тебе нужно 3D совсем без шейдинга, возможно, ты хочешь пиксельный шейдинг?
Я знаю, что мне нужно, ни шейдинг, ни нормалмапы мне не нужны.
>>84133
Опять всякое говно людям жить не даёт. Ирония в том, что жирная баба типа не может травмировать психику ребёнка, мужик транс тоже, но вот обычно тян в купальнике да, кек.
Опять всякое говно людям жить не даёт. Ирония в том, что жирная баба типа не может травмировать психику ребёнка, мужик транс тоже, но вот обычно тян в купальнике да, кек.
>>84158
Мне кажется, ты что-то неправильно делаешь. Над тобой вон уже в срачетреде смеются.
Мне кажется, ты что-то неправильно делаешь. Над тобой вон уже в срачетреде смеются.
Хотелось бы узнать есть ли некий плугон, который бы мне помог найти место утечки памяти. Так же я знаю, что есть временная утечка и годо растущую память очищает через некоторое время.
>>84158
Антон, а как насчёт того чтобы вместо прозрачности бахнуть полигонами? Сделал один два мега листа угловатых, наклеил на деревяшку, да рисуешь.
>>84158
Антон, а как насчёт того чтобы вместо прозрачности бахнуть полигонами? Сделал один два мега листа угловатых, наклеил на деревяшку, да рисуешь.
>>84179
У тебя прям память компа утекает или растёт число orphans? Смотри какой код недавно правил, где ты там что-то создаёшь и не освобождаешь. Может, перезаписываешь ссылку на объект ссылкой на другой такой же объект, поэтому не замечаешь. Ещё я заметил, что при перезагрузке сцены все старые orphans теряются со стороны GDScript, но остаются висеть в числе orphans, т.е. если у тебя часто сцены меняются, может копиться число этих orphans. У меня они никак автоматически не очищаются, только целиком проект перезапускать, не знаю как с этим быть (кроме как никогда не перезагружать сцену).
Что-то такое хочу попробовать.
>>84180 (Del)
Спасибо, попробую.
А я искал в интернете - единственным ответом было сделать копию объекта и как-то запретить отрисовку самого объекта, оставив только его тень (что-то со слоями отрисовки вроде). Это интересное решение, если сделать лоуполи тень сложному объекту, ведь лоуполи будет намного быстрее рендериться.
>найти место утечки памяти
У тебя прям память компа утекает или растёт число orphans? Смотри какой код недавно правил, где ты там что-то создаёшь и не освобождаешь. Может, перезаписываешь ссылку на объект ссылкой на другой такой же объект, поэтому не замечаешь. Ещё я заметил, что при перезагрузке сцены все старые orphans теряются со стороны GDScript, но остаются висеть в числе orphans, т.е. если у тебя часто сцены меняются, может копиться число этих orphans. У меня они никак автоматически не очищаются, только целиком проект перезапускать, не знаю как с этим быть (кроме как никогда не перезагружать сцену).
>Сделал один два мега листа угловатых, наклеил на деревяшку, да рисуешь.
Что-то такое хочу попробовать.
>>84180 (Del)
>надо включить depth prepass.
Спасибо, попробую.
>Это все в доках где то описано.
А я искал в интернете - единственным ответом было сделать копию объекта и как-то запретить отрисовку самого объекта, оставив только его тень (что-то со слоями отрисовки вроде). Это интересное решение, если сделать лоуполи тень сложному объекту, ведь лоуполи будет намного быстрее рендериться.
>>84180 (Del)
Точнее будет так:
Depth Draw Mode - Opaque Pre-Pass
Попробовал... Ой, всё, теперь получается, что Transparent от Alpha Scissor ничем не отличается с этой текстурой, в том числе по производительности. Ну и ладно, это всё не важно уже.
>depth prepass
Точнее будет так:
Depth Draw Mode - Opaque Pre-Pass
Попробовал... Ой, всё, теперь получается, что Transparent от Alpha Scissor ничем не отличается с этой текстурой, в том числе по производительности. Ну и ладно, это всё не важно уже.
27 Кб, 515x296>>84201
Это, растёт, потом сбрасывается до некоторого значения и снова растёт.
На картинке способ создания. Проблема в том, что если сделать на основе одномерного массива, то доступ к элементу может оказаться медленнее, так как надо будет вычислять позицию индекса. Попробую.
> У тебя прям память компа утекает
Это, растёт, потом сбрасывается до некоторого значения и снова растёт.
На картинке способ создания. Проблема в том, что если сделать на основе одномерного массива, то доступ к элементу может оказаться медленнее, так как надо будет вычислять позицию индекса. Попробую.
>>84208 (Del)
Кстати да, а на каком из движков больше всего игор местные сделали?
Кстати да, а на каком из движков больше всего игор местные сделали?
680 Кб, 597x557>>83729
Годетта, раз уж пошла такая пьянка
Годетта, раз уж пошла такая пьянка
Сап. Имею слабый компьютер (мало ОЗУ и видеокарте лет 10). Комп смогу обновить еще не скоро. В будущем хочу освоить 3д, но сейчас оставил выбор на 2д.
В качестве первого движка выбрал Godot так как сижу на линуксе и Unity по какой то причине у меня забагован в некоторых местах. Видимо порт пока хуевый.
Вопрос, как думаете, в будущем Godot обзаведется нормальным инструментарием для 3д графики? Судя по тому как развивается опер сорс (блендер, Крита и тд) перспективы большие.
Или когда уже освою разработку и куплю комп, там уже будет все равно чем пользоваться и ддя 3д смогу перейти на любой другой движок? Насколько вообще легко будет перейти и освоить второй?
В качестве первого движка выбрал Godot так как сижу на линуксе и Unity по какой то причине у меня забагован в некоторых местах. Видимо порт пока хуевый.
Вопрос, как думаете, в будущем Godot обзаведется нормальным инструментарием для 3д графики? Судя по тому как развивается опер сорс (блендер, Крита и тд) перспективы большие.
Или когда уже освою разработку и куплю комп, там уже будет все равно чем пользоваться и ддя 3д смогу перейти на любой другой движок? Насколько вообще легко будет перейти и освоить второй?
>>84300 (Del)
Там в 4.0 обещали именно этим заняться. Хотят Godot вывести на уровень с Unity и UE.
Понятно, что это не скоро произойдет, но посмотри на Бледер, он сейчас ничем не уступает другим редакторам, а в чем то даже лучше их. У Godot может случится та же история. У него уже есть плюсы, насколько я понял. Если разрабов на ютубе послушать, часто сравнивают юнити и годот, и некоторые даже переходят туда полностью, особенно те кто с 2д графикой работают.
Там в 4.0 обещали именно этим заняться. Хотят Godot вывести на уровень с Unity и UE.
Понятно, что это не скоро произойдет, но посмотри на Бледер, он сейчас ничем не уступает другим редакторам, а в чем то даже лучше их. У Godot может случится та же история. У него уже есть плюсы, насколько я понял. Если разрабов на ютубе послушать, часто сравнивают юнити и годот, и некоторые даже переходят туда полностью, особенно те кто с 2д графикой работают.
>>84301
Но я про юнити спросил, так как по нему куча классных материалов, можно практически что угодно сделать по урокам и примерам. Есть очень крутые каналы на ютуб с разборами всяких фич.
Хотя и по godot, уверен, будет больше :)
Но я про юнити спросил, так как по нему куча классных материалов, можно практически что угодно сделать по урокам и примерам. Есть очень крутые каналы на ютуб с разборами всяких фич.
Хотя и по godot, уверен, будет больше :)
>>84207
У тебя лишние циклы, лишняя переменная и лишние затраты на увеличение массива через append(). Мой способ:
Пробовал сделать ещё короче, но не вышло.
Кстати, если придерживаешься типизированного подхода, то нужно обязательно указывать тип возвращаемого значения из функции. Если ничего не возвращаешь, то
А в твоём случае будет
Это поможет при поиске ошибок в коде и теоретически может немного повысить производительность кода.
Чем проверяешь? Если диспетчером задач Windows или аналогом на линуксе, то забей на это. ОС делает много разной фоновой работы с оперативной памятью, доступной приложению. Особенно если включены разные дополнительные функции для ускорения работы компьютера, на Windows они включены по умолчанию и много работают с оперативной памятью.
Если смотришь по графику памяти в самом Godot, то тут не знаю, сам только на днях узнал о существовании этого графика. Но, я думаю, тут тоже можно забить, если оно не мешает игровому процессу и не вызывает переполнения памяти.
Нужно протестировать. Сами по себе универсальные массивы в Godot медленные потому, что могут хранить любые данные. Т.е. прежде чем выдать значение из ячейки двумерного массива, интерпретатору придётся сначала определить, что в ячейке внешнего массива хранится ссылка на другой массив, найти его в памяти и запросить требуемый элемент. Лишние переходы в RAM - лишние запросы между CPU и RAM - потраченные на ожидание RAM такты CPU. Если ты вычисляешь сразу нужную ячейку, то это может оказаться даже быстрее, т.к. получишь нужный элемент за одно обращение к RAM. Но это всё теория и она сильно зависит от конкретного процессора, оперативной памяти и, возможно, даже материнской платы)
Также где-то читал про способы ускорения вычисления ячейки двумерного массива - что-то там про битовые сдвиги и т.п. Но вряд ли это имеет смысл на GDScript... Помни, что преждевременные оптимизации делать вредно)
>На картинке способ создания
У тебя лишние циклы, лишняя переменная и лишние затраты на увеличение массива через 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... Помни, что преждевременные оптимизации делать вредно)
>>84207
У тебя лишние циклы, лишняя переменная и лишние затраты на увеличение массива через append(). Мой способ:
Пробовал сделать ещё короче, но не вышло.
Кстати, если придерживаешься типизированного подхода, то нужно обязательно указывать тип возвращаемого значения из функции. Если ничего не возвращаешь, то
А в твоём случае будет
Это поможет при поиске ошибок в коде и теоретически может немного повысить производительность кода.
Чем проверяешь? Если диспетчером задач Windows или аналогом на линуксе, то забей на это. ОС делает много разной фоновой работы с оперативной памятью, доступной приложению. Особенно если включены разные дополнительные функции для ускорения работы компьютера, на Windows они включены по умолчанию и много работают с оперативной памятью.
Если смотришь по графику памяти в самом Godot, то тут не знаю, сам только на днях узнал о существовании этого графика. Но, я думаю, тут тоже можно забить, если оно не мешает игровому процессу и не вызывает переполнения памяти.
Нужно протестировать. Сами по себе универсальные массивы в Godot медленные потому, что могут хранить любые данные. Т.е. прежде чем выдать значение из ячейки двумерного массива, интерпретатору придётся сначала определить, что в ячейке внешнего массива хранится ссылка на другой массив, найти его в памяти и запросить требуемый элемент. Лишние переходы в RAM - лишние запросы между CPU и RAM - потраченные на ожидание RAM такты CPU. Если ты вычисляешь сразу нужную ячейку, то это может оказаться даже быстрее, т.к. получишь нужный элемент за одно обращение к RAM. Но это всё теория и она сильно зависит от конкретного процессора, оперативной памяти и, возможно, даже материнской платы)
Также где-то читал про способы ускорения вычисления ячейки двумерного массива - что-то там про битовые сдвиги и т.п. Но вряд ли это имеет смысл на GDScript... Помни, что преждевременные оптимизации делать вредно)
>На картинке способ создания
У тебя лишние циклы, лишняя переменная и лишние затраты на увеличение массива через 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... Помни, что преждевременные оптимизации делать вредно)
>>84287
Что значит "нормальный инструментарий"?
Зависит от того, на какой, и насколько хорошо освоишь первый. В целом, в геймдеве освоение инструмента занимает меньшую часть времени, главное - научиться делать сами игры. В программировании обычно первый ЯП даётся тяжело, а все остальные очень легко, если не менять парадигму, но в геймдеве, можно сказать, всего одна парадигма - императивная, остальные не прижились. Больше всего трудностей будет, если попытаешься перейти на 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.
>нормальным инструментарием для 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.
>>84287
Что значит "нормальный инструментарий"?
Зависит от того, на какой, и насколько хорошо освоишь первый. В целом, в геймдеве освоение инструмента занимает меньшую часть времени, главное - научиться делать сами игры. В программировании обычно первый ЯП даётся тяжело, а все остальные очень легко, если не менять парадигму, но в геймдеве, можно сказать, всего одна парадигма - императивная, остальные не прижились. Больше всего трудностей будет, если попытаешься перейти на 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.
>нормальным инструментарием для 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.
>>84132 (Del)
Не хочу использовать аддон. Это избыточная функциональность, копание в чужом коде, костыли для соединения своего кода с чужим и так далее. Я хочу всё сам... попробовать хотя бы. Поэтому даже шум не использую, только велосипед на Random(), пусть у него и есть существенные ограничения (вряд ли получится генерировать бесконечную карту моим методом; вряд ли получится генерировать одну и ту же карту из одного зерна; большие затраты по скорости и памяти). Также у меня есть некоторые идеи на счёт того, как размещать объекты по сетке, имея при этом меш поверхности из огромных треугольников; боюсь, будет сложно костылировать это на готовом генераторе ландшафта.
Звучит как костыль - генерировать текстуру, чтобы другой генератор сгенерировал из текстуры меш) У меня один такой "пиксель" будет размером с многоэтажный частный дом...
Пикрил. Слева треугольники ориентированы неправильно, а справа правильно. Но слева фиксированные положения треугольников, а справа их нужно поворачивать по ситуации. Думаю, достаточно сравнивать 2-3 вершины между собой по высоте, но мне... как-то страшно к этому приступать. Осенью генерировал сетку из гексагональных призм, и это было больно( Кстати, представь на каждой паре треугольников по домику или группе деревьев - вот это и будет моя карта. Зато никаких дурацких колдобин на дорогах! Но если будет нужно, смогу сделать повышенную детализацию отдельных блоков (какие-нибудь локальные бугры в лесу или на пляже). Также планирую вертикальные стены между некоторыми блоками, типа скал/обрывов, это несложно, но как-нибудь потом.
Это я знаю, это просто. Сложнее всего оказалось настроить tangent space - я так и не понял, что это такое и как с ним работать, а без него нормалмапы не работают (но здесь они не понадобятся).
Знаю, я имел в виду... ой, я не помню, что я имел в виду. Короче, нужно настраивать уровни детализации чанков и переключать их, а чё там с билбордами это дело десятое...
Это я знаю, много наблюдал за ночным городом в разных ГТА. Очень легко заметить вживую, что вместо машин спрайты огоньков. Незаметны они только если не обращать на них внимания) Меня больше интересует, как в той же ГТА делают освещение на улицах вблизи игрока, ведь больше 8 источников света OpenGL не поддерживает (вроде). Или в ГТА только имитация освещения? Я помню что фары в старых ГТА очень странно светили, как будто накладывали спрайт-маску на дорогу...
Да... Просто у меня там куча всего лишнего была в каждом блоке. Этой ночью попробовал разные варианты уже с генерацией треугольниками целого чанка (вместо сборки чанка из блоков), и вроде неплохо получается с чанками любых размеров. Главное деревья склеить в один меш на чанк и будет норм. Или мультимеш.
Вообще-то деревья меня не должны заботить. Не знаю, почему я на них так сфокусировался. Нужны вариации ландшафта, предметы вокруг дорог, дома нормальные, вот это всё, а деревья потом как-нибудь. inb4 демонстрирую генератор деревьев всё на той же пустой карте с кубами, что и была, дроуколлов в 10 раз больше прежнего
А ещё я убедился в который раз, что VehicleBody никуда не годится. Придётся свой велосипед делать, но так даже лучше, не люблю на всём готовом.
>традиционно используют аддон
Не хочу использовать аддон. Это избыточная функциональность, копание в чужом коде, костыли для соединения своего кода с чужим и так далее. Я хочу всё сам... попробовать хотя бы. Поэтому даже шум не использую, только велосипед на Random(), пусть у него и есть существенные ограничения (вряд ли получится генерировать бесконечную карту моим методом; вряд ли получится генерировать одну и ту же карту из одного зерна; большие затраты по скорости и памяти). Также у меня есть некоторые идеи на счёт того, как размещать объекты по сетке, имея при этом меш поверхности из огромных треугольников; боюсь, будет сложно костылировать это на готовом генераторе ландшафта.
>карта задается текстурой, а пиксели можно редактировать.
Звучит как костыль - генерировать текстуру, чтобы другой генератор сгенерировал из текстуры меш) У меня один такой "пиксель" будет размером с многоэтажный частный дом...
>>нужно ещё определять ориентацию треугольников.
>Что это значит?
Пикрил. Слева треугольники ориентированы неправильно, а справа правильно. Но слева фиксированные положения треугольников, а справа их нужно поворачивать по ситуации. Думаю, достаточно сравнивать 2-3 вершины между собой по высоте, но мне... как-то страшно к этому приступать. Осенью генерировал сетку из гексагональных призм, и это было больно( Кстати, представь на каждой паре треугольников по домику или группе деревьев - вот это и будет моя карта. Зато никаких дурацких колдобин на дорогах! Но если будет нужно, смогу сделать повышенную детализацию отдельных блоков (какие-нибудь локальные бугры в лесу или на пляже). Также планирую вертикальные стены между некоторыми блоками, типа скал/обрывов, это несложно, но как-нибудь потом.
>А вообще определяется в 3д однозначно порядком вершин (по часовой или против часовой).
Это я знаю, это просто. Сложнее всего оказалось настроить tangent space - я так и не понял, что это такое и как с ним работать, а без него нормалмапы не работают (но здесь они не понадобятся).
>Я имел в виду заменить в далеких чанках. Там, где игрок, останутся полноценные модели.
Знаю, я имел в виду... ой, я не помню, что я имел в виду. Короче, нужно настраивать уровни детализации чанков и переключать их, а чё там с билбордами это дело десятое...
>ГТА5 фары не рисуются 3д, это просто плоские спрайты (пикрил).
Это я знаю, много наблюдал за ночным городом в разных ГТА. Очень легко заметить вживую, что вместо машин спрайты огоньков. Незаметны они только если не обращать на них внимания) Меня больше интересует, как в той же ГТА делают освещение на улицах вблизи игрока, ведь больше 8 источников света OpenGL не поддерживает (вроде). Или в ГТА только имитация освещения? Я помню что фары в старых ГТА очень странно светили, как будто накладывали спрайт-маску на дорогу...
>у тебя видимо другая крайность, у меня наоборот большие чанки
Да... Просто у меня там куча всего лишнего была в каждом блоке. Этой ночью попробовал разные варианты уже с генерацией треугольниками целого чанка (вместо сборки чанка из блоков), и вроде неплохо получается с чанками любых размеров. Главное деревья склеить в один меш на чанк и будет норм. Или мультимеш.
Вообще-то деревья меня не должны заботить. Не знаю, почему я на них так сфокусировался. Нужны вариации ландшафта, предметы вокруг дорог, дома нормальные, вот это всё, а деревья потом как-нибудь. inb4 демонстрирую генератор деревьев всё на той же пустой карте с кубами, что и была, дроуколлов в 10 раз больше прежнего
А ещё я убедился в который раз, что VehicleBody никуда не годится. Придётся свой велосипед делать, но так даже лучше, не люблю на всём готовом.
>>84132 (Del)
Не хочу использовать аддон. Это избыточная функциональность, копание в чужом коде, костыли для соединения своего кода с чужим и так далее. Я хочу всё сам... попробовать хотя бы. Поэтому даже шум не использую, только велосипед на Random(), пусть у него и есть существенные ограничения (вряд ли получится генерировать бесконечную карту моим методом; вряд ли получится генерировать одну и ту же карту из одного зерна; большие затраты по скорости и памяти). Также у меня есть некоторые идеи на счёт того, как размещать объекты по сетке, имея при этом меш поверхности из огромных треугольников; боюсь, будет сложно костылировать это на готовом генераторе ландшафта.
Звучит как костыль - генерировать текстуру, чтобы другой генератор сгенерировал из текстуры меш) У меня один такой "пиксель" будет размером с многоэтажный частный дом...
Пикрил. Слева треугольники ориентированы неправильно, а справа правильно. Но слева фиксированные положения треугольников, а справа их нужно поворачивать по ситуации. Думаю, достаточно сравнивать 2-3 вершины между собой по высоте, но мне... как-то страшно к этому приступать. Осенью генерировал сетку из гексагональных призм, и это было больно( Кстати, представь на каждой паре треугольников по домику или группе деревьев - вот это и будет моя карта. Зато никаких дурацких колдобин на дорогах! Но если будет нужно, смогу сделать повышенную детализацию отдельных блоков (какие-нибудь локальные бугры в лесу или на пляже). Также планирую вертикальные стены между некоторыми блоками, типа скал/обрывов, это несложно, но как-нибудь потом.
Это я знаю, это просто. Сложнее всего оказалось настроить tangent space - я так и не понял, что это такое и как с ним работать, а без него нормалмапы не работают (но здесь они не понадобятся).
Знаю, я имел в виду... ой, я не помню, что я имел в виду. Короче, нужно настраивать уровни детализации чанков и переключать их, а чё там с билбордами это дело десятое...
Это я знаю, много наблюдал за ночным городом в разных ГТА. Очень легко заметить вживую, что вместо машин спрайты огоньков. Незаметны они только если не обращать на них внимания) Меня больше интересует, как в той же ГТА делают освещение на улицах вблизи игрока, ведь больше 8 источников света OpenGL не поддерживает (вроде). Или в ГТА только имитация освещения? Я помню что фары в старых ГТА очень странно светили, как будто накладывали спрайт-маску на дорогу...
Да... Просто у меня там куча всего лишнего была в каждом блоке. Этой ночью попробовал разные варианты уже с генерацией треугольниками целого чанка (вместо сборки чанка из блоков), и вроде неплохо получается с чанками любых размеров. Главное деревья склеить в один меш на чанк и будет норм. Или мультимеш.
Вообще-то деревья меня не должны заботить. Не знаю, почему я на них так сфокусировался. Нужны вариации ландшафта, предметы вокруг дорог, дома нормальные, вот это всё, а деревья потом как-нибудь. inb4 демонстрирую генератор деревьев всё на той же пустой карте с кубами, что и была, дроуколлов в 10 раз больше прежнего
А ещё я убедился в который раз, что VehicleBody никуда не годится. Придётся свой велосипед делать, но так даже лучше, не люблю на всём готовом.
>традиционно используют аддон
Не хочу использовать аддон. Это избыточная функциональность, копание в чужом коде, костыли для соединения своего кода с чужим и так далее. Я хочу всё сам... попробовать хотя бы. Поэтому даже шум не использую, только велосипед на Random(), пусть у него и есть существенные ограничения (вряд ли получится генерировать бесконечную карту моим методом; вряд ли получится генерировать одну и ту же карту из одного зерна; большие затраты по скорости и памяти). Также у меня есть некоторые идеи на счёт того, как размещать объекты по сетке, имея при этом меш поверхности из огромных треугольников; боюсь, будет сложно костылировать это на готовом генераторе ландшафта.
>карта задается текстурой, а пиксели можно редактировать.
Звучит как костыль - генерировать текстуру, чтобы другой генератор сгенерировал из текстуры меш) У меня один такой "пиксель" будет размером с многоэтажный частный дом...
>>нужно ещё определять ориентацию треугольников.
>Что это значит?
Пикрил. Слева треугольники ориентированы неправильно, а справа правильно. Но слева фиксированные положения треугольников, а справа их нужно поворачивать по ситуации. Думаю, достаточно сравнивать 2-3 вершины между собой по высоте, но мне... как-то страшно к этому приступать. Осенью генерировал сетку из гексагональных призм, и это было больно( Кстати, представь на каждой паре треугольников по домику или группе деревьев - вот это и будет моя карта. Зато никаких дурацких колдобин на дорогах! Но если будет нужно, смогу сделать повышенную детализацию отдельных блоков (какие-нибудь локальные бугры в лесу или на пляже). Также планирую вертикальные стены между некоторыми блоками, типа скал/обрывов, это несложно, но как-нибудь потом.
>А вообще определяется в 3д однозначно порядком вершин (по часовой или против часовой).
Это я знаю, это просто. Сложнее всего оказалось настроить tangent space - я так и не понял, что это такое и как с ним работать, а без него нормалмапы не работают (но здесь они не понадобятся).
>Я имел в виду заменить в далеких чанках. Там, где игрок, останутся полноценные модели.
Знаю, я имел в виду... ой, я не помню, что я имел в виду. Короче, нужно настраивать уровни детализации чанков и переключать их, а чё там с билбордами это дело десятое...
>ГТА5 фары не рисуются 3д, это просто плоские спрайты (пикрил).
Это я знаю, много наблюдал за ночным городом в разных ГТА. Очень легко заметить вживую, что вместо машин спрайты огоньков. Незаметны они только если не обращать на них внимания) Меня больше интересует, как в той же ГТА делают освещение на улицах вблизи игрока, ведь больше 8 источников света OpenGL не поддерживает (вроде). Или в ГТА только имитация освещения? Я помню что фары в старых ГТА очень странно светили, как будто накладывали спрайт-маску на дорогу...
>у тебя видимо другая крайность, у меня наоборот большие чанки
Да... Просто у меня там куча всего лишнего была в каждом блоке. Этой ночью попробовал разные варианты уже с генерацией треугольниками целого чанка (вместо сборки чанка из блоков), и вроде неплохо получается с чанками любых размеров. Главное деревья склеить в один меш на чанк и будет норм. Или мультимеш.
Вообще-то деревья меня не должны заботить. Не знаю, почему я на них так сфокусировался. Нужны вариации ландшафта, предметы вокруг дорог, дома нормальные, вот это всё, а деревья потом как-нибудь. inb4 демонстрирую генератор деревьев всё на той же пустой карте с кубами, что и была, дроуколлов в 10 раз больше прежнего
А ещё я убедился в который раз, что VehicleBody никуда не годится. Придётся свой велосипед делать, но так даже лучше, не люблю на всём готовом.
>>84287
Нормальный инструментарий для 3д-графики - это Блендер. И в шапке уже указаны два плагина для упрощения взаимодействия с годотом.
Я пробовал на убунте через appimage вроде всё работало.
> Вопрос, как думаете, в будущем Godot обзаведется нормальным инструментарием для 3д графики?
Нормальный инструментарий для 3д-графики - это Блендер. И в шапке уже указаны два плагина для упрощения взаимодействия с годотом.
> сижу на линуксе и Unity по какой то причине у меня забагован в некоторых местах
Я пробовал на убунте через appimage вроде всё работало.
>>84320
Кстати, надо будет в шапку добавить.
Кстати, я джва года назад таким образом реимплементировал оси движения в годот ( x = Input.get_action_strength("ui_right") - Input.get_action_strength("ui_left") ) запостил пару раз в комментах ютуба и к своему удовольствию обнаружил, что все новые туториалы стали на осях.
> ВНЕЗАПНО есть даже книги по Godot.
Кстати, надо будет в шапку добавить.
> Нужно ли говорить, что можно извлечь полезные знания из такого туториала, даже если вообще не планируешь использовать юнити?
Кстати, я джва года назад таким образом реимплементировал оси движения в годот ( x = Input.get_action_strength("ui_right") - Input.get_action_strength("ui_left") ) запостил пару раз в комментах ютуба и к своему удовольствию обнаружил, что все новые туториалы стали на осях.
>>84233 (Del)
Всегда считал что это блик
Всегда считал что это блик
>>84328
Кстати, почему так часто юзают стандартные действия "ui_"? Это же горячие клавиши интерфейса (user interface), глупо управлять персонажем через них. Я всегда первым делом создаю собственную раскладку с именами вроде move_forward и move_backward отдельно от ui, даже если они пересекаются/дублируют друг друга. Код с неуместным использованием ui-действий считаю быдлокодом и хотел бы, чтобы в туториалах в первую очередь объясняли добавление новых действий, с правильным названием, чётко описывающим назначение конкретного действия.
Смысл действий (action) в том, чтобы разделить разные по смыслу элементы управления. Да, не каждой игре это нужно, но если ты делаешь меню настройки раскладки, игроку будет очень неприятно обнаружить, что смена клавиш движения портит навигацию по меню, которую он трогать не хотел. Аналогично с любыми действиями в игре, которые игрок теоретически может захотеть переназначить на клавишу, отдельную от "универсальной"/контекстной. Я считаю обучение этому таким же важным, как прикол с sqrt(2).
При этом в Годо, в отличие от Юнити, не нужно совокупляться с десятком разных непонятных интерфейсов и загружаемых ассетов, чтобы создать свои действия. Просто зашёл в настройки проекта и сделал как надо, ничего не скачивая и не компилируя... Нет, нужно юзать стандартные хоткеи не по назначению.
>ui_right
>ui_left
Кстати, почему так часто юзают стандартные действия "ui_"? Это же горячие клавиши интерфейса (user interface), глупо управлять персонажем через них. Я всегда первым делом создаю собственную раскладку с именами вроде move_forward и move_backward отдельно от ui, даже если они пересекаются/дублируют друг друга. Код с неуместным использованием ui-действий считаю быдлокодом и хотел бы, чтобы в туториалах в первую очередь объясняли добавление новых действий, с правильным названием, чётко описывающим назначение конкретного действия.
Смысл действий (action) в том, чтобы разделить разные по смыслу элементы управления. Да, не каждой игре это нужно, но если ты делаешь меню настройки раскладки, игроку будет очень неприятно обнаружить, что смена клавиш движения портит навигацию по меню, которую он трогать не хотел. Аналогично с любыми действиями в игре, которые игрок теоретически может захотеть переназначить на клавишу, отдельную от "универсальной"/контекстной. Я считаю обучение этому таким же важным, как прикол с sqrt(2).
При этом в Годо, в отличие от Юнити, не нужно совокупляться с десятком разных непонятных интерфейсов и загружаемых ассетов, чтобы создать свои действия. Просто зашёл в настройки проекта и сделал как надо, ничего не скачивая и не компилируя... Нет, нужно юзать стандартные хоткеи не по назначению.
>>84437 (Del)
Сделай сам один раз и потом во всех своих проектах используй, меняя только внешний вид GUI. В этом главная прелесть программирования - можно неограниченно использовать то, что было создано всего один раз.
Я пока этой темы не касался, но не думаю, что это сложно, достаточно один универсальный скрипт "нажмите кнопку" написать и дальше дело только за оформлением GUI с кучей пунктов на каждое действие, которое ты разрешаешь игроку изменять.
Сделай сам один раз и потом во всех своих проектах используй, меняя только внешний вид GUI. В этом главная прелесть программирования - можно неограниченно использовать то, что было создано всего один раз.
Я пока этой темы не касался, но не думаю, что это сложно, достаточно один универсальный скрипт "нажмите кнопку" написать и дальше дело только за оформлением GUI с кучей пунктов на каждое действие, которое ты разрешаешь игроку изменять.
>>84429
Я не юзаю. А в посте написал дефолт для примера.
> почему так часто юзают стандартные действия "ui_"?
Я не юзаю. А в посте написал дефолт для примера.
>>84207
Напиши потом, что получилось. Интересно, что же у тебя за утечка такая и будет ли одномерный массив заметно лучше/хуже двумерного (да, мне лень самому делать синтетический тест).
>Попробую.
Напиши потом, что получилось. Интересно, что же у тебя за утечка такая и будет ли одномерный массив заметно лучше/хуже двумерного (да, мне лень самому делать синтетический тест).
Смотрите какую приколюху сделал. Последовал советам сделать текстуру-палитру и размещать на ней все вершины в определённых точках. Сезон переключается всего одной переменной в настройках мира. Но это пока очень грубый прототип, текстуру и цвета на ней точно поменяю. Сперва хотел сделать сразу градиентом, для плавных переходов, но передумал и решил для начала сделать квадратиками, чтобы просто идею протестировать. Если делать градиентом, можно будет сделать вариации цвета хоть на каждый день в году... Хотя, конечно, такой метод не очень подходит, если нужен интерактивный снег на каждом участке карты.
Интересная особенность рендеринга: если UV координаты будут точно на границе двух цветов, между пикселей (пример с палитрой 4х4: 0.25, 0.25), тогда поверхность будет покрываться полосками двух цветов, как бы рябить разноцветными волнами. Вдруг кто-то такой же артефакт словит и будет голову ломать.
Интересная особенность рендеринга: если UV координаты будут точно на границе двух цветов, между пикселей (пример с палитрой 4х4: 0.25, 0.25), тогда поверхность будет покрываться полосками двух цветов, как бы рябить разноцветными волнами. Вдруг кто-то такой же артефакт словит и будет голову ломать.
>>84795 (Del)
Я прекрасно знаю про сглаживающий фильтр и про пиксельные текстуры. Выключил эту галочку сразу после импорта.
Проблема не в фильтре. С фильтром, я думаю, результат был бы намного лучше: цвета бы смешались, но был бы один однородный цвет. А у меня получилась именно рябь, то есть огромное количество тонких чётких полосок, сменяющих друг друга по всей поверхности. Что-то отдалённо похожее на z-fighting, но на текстурах.
Думаю, проблема в ошибках с округлением чисел с плавающей точкой. Число типа 0.25 округляется то в 16-й пиксель, то в 17-й, из-за этого два разных цвета сменяют друг друга. Ещё все вершины одного треугольника я размещаю в одну UV-координату, т.е. между вершинами на текстуре нет ни одного пикселя.
Решается проблема, повторюсь, смещением вершин в правильный пиксель или группу пикселей одного цвета. Я сместил на 0.125, 0.375, 0.625 и 0.875 - и всё заработало как предполагалось.
Я прекрасно знаю про сглаживающий фильтр и про пиксельные текстуры. Выключил эту галочку сразу после импорта.
Проблема не в фильтре. С фильтром, я думаю, результат был бы намного лучше: цвета бы смешались, но был бы один однородный цвет. А у меня получилась именно рябь, то есть огромное количество тонких чётких полосок, сменяющих друг друга по всей поверхности. Что-то отдалённо похожее на z-fighting, но на текстурах.
Думаю, проблема в ошибках с округлением чисел с плавающей точкой. Число типа 0.25 округляется то в 16-й пиксель, то в 17-й, из-за этого два разных цвета сменяют друг друга. Ещё все вершины одного треугольника я размещаю в одну UV-координату, т.е. между вершинами на текстуре нет ни одного пикселя.
Решается проблема, повторюсь, смещением вершин в правильный пиксель или группу пикселей одного цвета. Я сместил на 0.125, 0.375, 0.625 и 0.875 - и всё заработало как предполагалось.
Годотеры, существуют ли аддоны на плюсах которые вводят int32, int16, vec2i и массивы для них в 3 годот?
>>85140
Я не слышал. Могу предложить, если ты знаешь плюсы, написать свои модули по аналогии с имеющимися и скомпилировать свой собственный билд.
Я не слышал. Могу предложить, если ты знаешь плюсы, написать свои модули по аналогии с имеющимися и скомпилировать свой собственный билд.
>>85142
Либо, что ещё лучше, сделать на плюсах ту логику, для которой тебе нужны int32, int16, vec2i и массивы для них, а в годот прокинуть интерфейс с результатом. И скомпилировать свой билд.
Либо, что ещё лучше, сделать на плюсах ту логику, для которой тебе нужны int32, int16, vec2i и массивы для них, а в годот прокинуть интерфейс с результатом. И скомпилировать свой билд.
Начинаю разработку 2D RPG с видом сбоку. Есть ли профиты потратить время на изучение вашей аниме девочки, а не начинать на родном юнити?
494 Кб, webm,640x360, 0:08
>>85167
Глупо скакать по движкам. Выбрал юнити - так делай на нём. Особой разницы нет.
Глупо скакать по движкам. Выбрал юнити - так делай на нём. Особой разницы нет.
>>85150 (Del)
Мне бы конечно плагин, а не пердолится каждый раз, когда выходит новая версия с фиксами.
Мне бы конечно плагин, а не пердолится каждый раз, когда выходит новая версия с фиксами.
Я тут подумал, у меня в генераторе карт уже частично использовались конечные автоматы (но не очень правильная реализация), но стартовые области заливались окружностями, из-за чего на большой площади эти окружности сильно бросались в глаза. Почему бы не сделать чисто на конечных автоматах? Правда, поискав в интернете, я обнаружил, что чаще всего изначальное состояние - белый шум, а мне хотелось бы что-то более сгруппированное, типа архипелага... Кстати, симуляции различных ирл сил, изменяющих форму ландшафта планеты, в общем смысле тоже являются конечными автоматами... так на реддите кто-то писал.
>>85184
Годетта бы не сказала такого никому, кто ей заинтересовался. Она добрая и открытая для всех, и не будет прогонять только потому, что человек пришёл от Юнити-чан и сомневается в выборе. Да, это мой хэдканон. Алсо жду аниме Годетта vs Юнити-чан. А в конце все персонажи будут пить чай с тортиками.
>>85167
Как в платформерах? Или ты имеешь в виду вид "сверху-сбоку", как в большинстве игр на RPG Maker?
Думаю, да.
- Редактор Годо нетребователен, не лагает и почти не глючит, запуск и перезапуск быстрый (не считая реимпорта очень больших ресурсов, но это редко нужно). Это особенно важно, если у тебя не очень сильный компьютер и ты всё равно делаешь 2D игру.
- GDScript и VisualScript в силу своей скриптовости никогда не заставляют ждать компиляцию кода, в отличие от Юнити, которая на любое изменение кода делает перекомпиляцию. На счёт C# не знаю, не пробовал. GDNative, разумеется, нужно компилировать, но тебе оно вряд ли понадобится, хватит GDScript.
- Сцена запускается в отдельном окне, если экран широкий или у тебя два экрана, можно поместить второе окно сбоку от основного. Некоторые считают это недостатком Годо, но для меня это преимущество, т.к. это окно будет выглядеть именно так, как будет выглядеть игра в релизе, а не как скукоженное в окне Юнити.
- GDScript пишется во встроенном редакторе. Можно использовать и внешний, но не нужно: встроенного полностью хватает. Много настроек, достаточно функций. Главное - что не нужно альт-табаться между редактором игры и редактором кода, всё выглядит в одном стиле и не вынуждает мозг переключаться между интерфейсами.
- Для экспорта можно скомпилировать из исходников свой собственный вариант шаблона экспорта. Можно отключить всё, что тебе не нужно: 3Д рендер, 3Д физику, сеть и т.д. Это снизит размер исполняемого файла, что полезно для мобилок и веба.
- Можно самостоятельно написать C++ модуль для движка и скомпилировать редактор вместе с ним. Т.е. ты максимально близок к ядру движка, в отличие от Юнити, на которой ты можешь только C# скрипты писать и никак не контролируешь ядро. Вообще, весь код на гитхабе и это радует, даже если ты никогда ничего там не будешь редактировать и компилировать.
- Также все или большинство обсуждений разработчиков движка идут на гитхабе. Можно почитать обо всех грядущих изменениях и планах заранее, можно поучаствовать в обсуждении, предложить новые фичи или пожаловаться на баги и получить отклик от самих разработчиков, а не каких-то наёмных посредников. По сути разработка прозрачна, никто не пытается скрыть от тебя какие-то будущие изменения. Да, это всему опенсорсу свойственно, но в разной степени. С Юнити же ты можешь только надеяться, что разрабы не учудят в следующей версии что-то совсем уж неадекватное и наконец-то пофиксят многолетние баги (знаю я про багтрекер юнити, там дохрена страниц и вряд ли у реальных разрабов есть время всё это изучать, что им менеджер проекта приказал делать - то и делают).
- Мне кажется, у Годо более приятное коммьюнити (в целом по миру). Будто на Годо перешли многие адекваты, а токсики остались таскать ассеты с ассетстора. Даже если тебе не помогут, то хотя бы попытаются, а не пошлют гуглить ассеты и туториалы со словами "всё придумано до тебя, ищи". Конечно, это из-за малоизвестности движка, с популярностью придут и легионы токсиков, срущих везде, где только могут, но пока что всё относительно спокойно.
- Документация движка достаточно полная и справка встроена прямо в движок, жмёшь F1 и в большинстве случаев быстро находишь интересующую тебя информацию (оффлайн). В целом дизайн онлайн документации получше, чем у Юнити, но это вкусовщина. В редакторе оффлайн справка открывается прямо в редакторе кода, удобно переключаться в процессе кодинга. Есть кое-какие пробелы, но только в тех местах, которые в целом крайне редко могут потребоваться - все основные инструменты документированы хорошо, разберёшься без туториалов.
- В целом Годо похож на Юнити, не считая некоторых нюансов (скажем, одна нода = один скрипт, вместо добавления компонентов в пустышку - добавление нод в дерево сцены). Т.е. перенести проект с одного движка на другой не должно составить большого труда, базовые концепции одинаковые. Для меня главное отличие Годо в удобстве и простоте использования, это важнее других отличий, особенно в рамках простой 2D игры.
Смотря насколько она тебе родная. Судя по тому, что делаешь 2D, вряд ли у тебя много проектов на Юнити. Освоить такой сложный инструмент на уровне "родного" вообще нереально, разве что ты имеешь в виду, что Юнити твой первый игровой движок. Если так, то готовься к синдрому утёнка, с которым придётся бороться. Для меня родной язык/инструмент - это Pascal, долго плевался от других языков и готовых движков, но всё-таки смирился с тем, что на Годо намного удобнее и проще реализовывать свои идеи, чем на всём том, что я пробовал раньше. А вот Юнити как-то не зашла, слишком сложно, медленно, глючно, много места занимает и не даёт достаточного контроля ни за движком, ни за проектом. Возможно, игры на Юнити производительнее игр на Годо, но до релиза игры ещё дожить надо, я лично не хочу страдать годами из-за редактора Юнити.
При всём при этом Годо не какой-то там конструктор для детей, на нём можно делать серьёзные проекты (просто пользуются в основном дети и нищие инди). Т.е. у Годо простота без жертвы возможностями, с минимальными жертвами по производительности билда. Согласись, все бы давно делали игры только на конструкторах игр, если бы они не сокращали возможности до очень ограниченного набора, ведь любой предпочтёт работать в большем комфорте.
>>85184
Годетта бы не сказала такого никому, кто ей заинтересовался. Она добрая и открытая для всех, и не будет прогонять только потому, что человек пришёл от Юнити-чан и сомневается в выборе. Да, это мой хэдканон. Алсо жду аниме Годетта vs Юнити-чан. А в конце все персонажи будут пить чай с тортиками.
>>85167
>2D RPG с видом сбоку
Как в платформерах? Или ты имеешь в виду вид "сверху-сбоку", как в большинстве игр на RPG Maker?
>Есть ли профиты потратить время на изучение
Думаю, да.
- Редактор Годо нетребователен, не лагает и почти не глючит, запуск и перезапуск быстрый (не считая реимпорта очень больших ресурсов, но это редко нужно). Это особенно важно, если у тебя не очень сильный компьютер и ты всё равно делаешь 2D игру.
- GDScript и VisualScript в силу своей скриптовости никогда не заставляют ждать компиляцию кода, в отличие от Юнити, которая на любое изменение кода делает перекомпиляцию. На счёт C# не знаю, не пробовал. GDNative, разумеется, нужно компилировать, но тебе оно вряд ли понадобится, хватит GDScript.
- Сцена запускается в отдельном окне, если экран широкий или у тебя два экрана, можно поместить второе окно сбоку от основного. Некоторые считают это недостатком Годо, но для меня это преимущество, т.к. это окно будет выглядеть именно так, как будет выглядеть игра в релизе, а не как скукоженное в окне Юнити.
- GDScript пишется во встроенном редакторе. Можно использовать и внешний, но не нужно: встроенного полностью хватает. Много настроек, достаточно функций. Главное - что не нужно альт-табаться между редактором игры и редактором кода, всё выглядит в одном стиле и не вынуждает мозг переключаться между интерфейсами.
- Для экспорта можно скомпилировать из исходников свой собственный вариант шаблона экспорта. Можно отключить всё, что тебе не нужно: 3Д рендер, 3Д физику, сеть и т.д. Это снизит размер исполняемого файла, что полезно для мобилок и веба.
- Можно самостоятельно написать C++ модуль для движка и скомпилировать редактор вместе с ним. Т.е. ты максимально близок к ядру движка, в отличие от Юнити, на которой ты можешь только C# скрипты писать и никак не контролируешь ядро. Вообще, весь код на гитхабе и это радует, даже если ты никогда ничего там не будешь редактировать и компилировать.
- Также все или большинство обсуждений разработчиков движка идут на гитхабе. Можно почитать обо всех грядущих изменениях и планах заранее, можно поучаствовать в обсуждении, предложить новые фичи или пожаловаться на баги и получить отклик от самих разработчиков, а не каких-то наёмных посредников. По сути разработка прозрачна, никто не пытается скрыть от тебя какие-то будущие изменения. Да, это всему опенсорсу свойственно, но в разной степени. С Юнити же ты можешь только надеяться, что разрабы не учудят в следующей версии что-то совсем уж неадекватное и наконец-то пофиксят многолетние баги (знаю я про багтрекер юнити, там дохрена страниц и вряд ли у реальных разрабов есть время всё это изучать, что им менеджер проекта приказал делать - то и делают).
- Мне кажется, у Годо более приятное коммьюнити (в целом по миру). Будто на Годо перешли многие адекваты, а токсики остались таскать ассеты с ассетстора. Даже если тебе не помогут, то хотя бы попытаются, а не пошлют гуглить ассеты и туториалы со словами "всё придумано до тебя, ищи". Конечно, это из-за малоизвестности движка, с популярностью придут и легионы токсиков, срущих везде, где только могут, но пока что всё относительно спокойно.
- Документация движка достаточно полная и справка встроена прямо в движок, жмёшь F1 и в большинстве случаев быстро находишь интересующую тебя информацию (оффлайн). В целом дизайн онлайн документации получше, чем у Юнити, но это вкусовщина. В редакторе оффлайн справка открывается прямо в редакторе кода, удобно переключаться в процессе кодинга. Есть кое-какие пробелы, но только в тех местах, которые в целом крайне редко могут потребоваться - все основные инструменты документированы хорошо, разберёшься без туториалов.
- В целом Годо похож на Юнити, не считая некоторых нюансов (скажем, одна нода = один скрипт, вместо добавления компонентов в пустышку - добавление нод в дерево сцены). Т.е. перенести проект с одного движка на другой не должно составить большого труда, базовые концепции одинаковые. Для меня главное отличие Годо в удобстве и простоте использования, это важнее других отличий, особенно в рамках простой 2D игры.
>родном юнити
Смотря насколько она тебе родная. Судя по тому, что делаешь 2D, вряд ли у тебя много проектов на Юнити. Освоить такой сложный инструмент на уровне "родного" вообще нереально, разве что ты имеешь в виду, что Юнити твой первый игровой движок. Если так, то готовься к синдрому утёнка, с которым придётся бороться. Для меня родной язык/инструмент - это Pascal, долго плевался от других языков и готовых движков, но всё-таки смирился с тем, что на Годо намного удобнее и проще реализовывать свои идеи, чем на всём том, что я пробовал раньше. А вот Юнити как-то не зашла, слишком сложно, медленно, глючно, много места занимает и не даёт достаточного контроля ни за движком, ни за проектом. Возможно, игры на Юнити производительнее игр на Годо, но до релиза игры ещё дожить надо, я лично не хочу страдать годами из-за редактора Юнити.
При всём при этом Годо не какой-то там конструктор для детей, на нём можно делать серьёзные проекты (просто пользуются в основном дети и нищие инди). Т.е. у Годо простота без жертвы возможностями, с минимальными жертвами по производительности билда. Согласись, все бы давно делали игры только на конструкторах игр, если бы они не сокращали возможности до очень ограниченного набора, ведь любой предпочтёт работать в большем комфорте.
Я тут подумал, у меня в генераторе карт уже частично использовались конечные автоматы (но не очень правильная реализация), но стартовые области заливались окружностями, из-за чего на большой площади эти окружности сильно бросались в глаза. Почему бы не сделать чисто на конечных автоматах? Правда, поискав в интернете, я обнаружил, что чаще всего изначальное состояние - белый шум, а мне хотелось бы что-то более сгруппированное, типа архипелага... Кстати, симуляции различных ирл сил, изменяющих форму ландшафта планеты, в общем смысле тоже являются конечными автоматами... так на реддите кто-то писал.
>>85184
Годетта бы не сказала такого никому, кто ей заинтересовался. Она добрая и открытая для всех, и не будет прогонять только потому, что человек пришёл от Юнити-чан и сомневается в выборе. Да, это мой хэдканон. Алсо жду аниме Годетта vs Юнити-чан. А в конце все персонажи будут пить чай с тортиками.
>>85167
Как в платформерах? Или ты имеешь в виду вид "сверху-сбоку", как в большинстве игр на RPG Maker?
Думаю, да.
- Редактор Годо нетребователен, не лагает и почти не глючит, запуск и перезапуск быстрый (не считая реимпорта очень больших ресурсов, но это редко нужно). Это особенно важно, если у тебя не очень сильный компьютер и ты всё равно делаешь 2D игру.
- GDScript и VisualScript в силу своей скриптовости никогда не заставляют ждать компиляцию кода, в отличие от Юнити, которая на любое изменение кода делает перекомпиляцию. На счёт C# не знаю, не пробовал. GDNative, разумеется, нужно компилировать, но тебе оно вряд ли понадобится, хватит GDScript.
- Сцена запускается в отдельном окне, если экран широкий или у тебя два экрана, можно поместить второе окно сбоку от основного. Некоторые считают это недостатком Годо, но для меня это преимущество, т.к. это окно будет выглядеть именно так, как будет выглядеть игра в релизе, а не как скукоженное в окне Юнити.
- GDScript пишется во встроенном редакторе. Можно использовать и внешний, но не нужно: встроенного полностью хватает. Много настроек, достаточно функций. Главное - что не нужно альт-табаться между редактором игры и редактором кода, всё выглядит в одном стиле и не вынуждает мозг переключаться между интерфейсами.
- Для экспорта можно скомпилировать из исходников свой собственный вариант шаблона экспорта. Можно отключить всё, что тебе не нужно: 3Д рендер, 3Д физику, сеть и т.д. Это снизит размер исполняемого файла, что полезно для мобилок и веба.
- Можно самостоятельно написать C++ модуль для движка и скомпилировать редактор вместе с ним. Т.е. ты максимально близок к ядру движка, в отличие от Юнити, на которой ты можешь только C# скрипты писать и никак не контролируешь ядро. Вообще, весь код на гитхабе и это радует, даже если ты никогда ничего там не будешь редактировать и компилировать.
- Также все или большинство обсуждений разработчиков движка идут на гитхабе. Можно почитать обо всех грядущих изменениях и планах заранее, можно поучаствовать в обсуждении, предложить новые фичи или пожаловаться на баги и получить отклик от самих разработчиков, а не каких-то наёмных посредников. По сути разработка прозрачна, никто не пытается скрыть от тебя какие-то будущие изменения. Да, это всему опенсорсу свойственно, но в разной степени. С Юнити же ты можешь только надеяться, что разрабы не учудят в следующей версии что-то совсем уж неадекватное и наконец-то пофиксят многолетние баги (знаю я про багтрекер юнити, там дохрена страниц и вряд ли у реальных разрабов есть время всё это изучать, что им менеджер проекта приказал делать - то и делают).
- Мне кажется, у Годо более приятное коммьюнити (в целом по миру). Будто на Годо перешли многие адекваты, а токсики остались таскать ассеты с ассетстора. Даже если тебе не помогут, то хотя бы попытаются, а не пошлют гуглить ассеты и туториалы со словами "всё придумано до тебя, ищи". Конечно, это из-за малоизвестности движка, с популярностью придут и легионы токсиков, срущих везде, где только могут, но пока что всё относительно спокойно.
- Документация движка достаточно полная и справка встроена прямо в движок, жмёшь F1 и в большинстве случаев быстро находишь интересующую тебя информацию (оффлайн). В целом дизайн онлайн документации получше, чем у Юнити, но это вкусовщина. В редакторе оффлайн справка открывается прямо в редакторе кода, удобно переключаться в процессе кодинга. Есть кое-какие пробелы, но только в тех местах, которые в целом крайне редко могут потребоваться - все основные инструменты документированы хорошо, разберёшься без туториалов.
- В целом Годо похож на Юнити, не считая некоторых нюансов (скажем, одна нода = один скрипт, вместо добавления компонентов в пустышку - добавление нод в дерево сцены). Т.е. перенести проект с одного движка на другой не должно составить большого труда, базовые концепции одинаковые. Для меня главное отличие Годо в удобстве и простоте использования, это важнее других отличий, особенно в рамках простой 2D игры.
Смотря насколько она тебе родная. Судя по тому, что делаешь 2D, вряд ли у тебя много проектов на Юнити. Освоить такой сложный инструмент на уровне "родного" вообще нереально, разве что ты имеешь в виду, что Юнити твой первый игровой движок. Если так, то готовься к синдрому утёнка, с которым придётся бороться. Для меня родной язык/инструмент - это Pascal, долго плевался от других языков и готовых движков, но всё-таки смирился с тем, что на Годо намного удобнее и проще реализовывать свои идеи, чем на всём том, что я пробовал раньше. А вот Юнити как-то не зашла, слишком сложно, медленно, глючно, много места занимает и не даёт достаточного контроля ни за движком, ни за проектом. Возможно, игры на Юнити производительнее игр на Годо, но до релиза игры ещё дожить надо, я лично не хочу страдать годами из-за редактора Юнити.
При всём при этом Годо не какой-то там конструктор для детей, на нём можно делать серьёзные проекты (просто пользуются в основном дети и нищие инди). Т.е. у Годо простота без жертвы возможностями, с минимальными жертвами по производительности билда. Согласись, все бы давно делали игры только на конструкторах игр, если бы они не сокращали возможности до очень ограниченного набора, ведь любой предпочтёт работать в большем комфорте.
>>85184
Годетта бы не сказала такого никому, кто ей заинтересовался. Она добрая и открытая для всех, и не будет прогонять только потому, что человек пришёл от Юнити-чан и сомневается в выборе. Да, это мой хэдканон. Алсо жду аниме Годетта vs Юнити-чан. А в конце все персонажи будут пить чай с тортиками.
>>85167
>2D RPG с видом сбоку
Как в платформерах? Или ты имеешь в виду вид "сверху-сбоку", как в большинстве игр на RPG Maker?
>Есть ли профиты потратить время на изучение
Думаю, да.
- Редактор Годо нетребователен, не лагает и почти не глючит, запуск и перезапуск быстрый (не считая реимпорта очень больших ресурсов, но это редко нужно). Это особенно важно, если у тебя не очень сильный компьютер и ты всё равно делаешь 2D игру.
- GDScript и VisualScript в силу своей скриптовости никогда не заставляют ждать компиляцию кода, в отличие от Юнити, которая на любое изменение кода делает перекомпиляцию. На счёт C# не знаю, не пробовал. GDNative, разумеется, нужно компилировать, но тебе оно вряд ли понадобится, хватит GDScript.
- Сцена запускается в отдельном окне, если экран широкий или у тебя два экрана, можно поместить второе окно сбоку от основного. Некоторые считают это недостатком Годо, но для меня это преимущество, т.к. это окно будет выглядеть именно так, как будет выглядеть игра в релизе, а не как скукоженное в окне Юнити.
- GDScript пишется во встроенном редакторе. Можно использовать и внешний, но не нужно: встроенного полностью хватает. Много настроек, достаточно функций. Главное - что не нужно альт-табаться между редактором игры и редактором кода, всё выглядит в одном стиле и не вынуждает мозг переключаться между интерфейсами.
- Для экспорта можно скомпилировать из исходников свой собственный вариант шаблона экспорта. Можно отключить всё, что тебе не нужно: 3Д рендер, 3Д физику, сеть и т.д. Это снизит размер исполняемого файла, что полезно для мобилок и веба.
- Можно самостоятельно написать C++ модуль для движка и скомпилировать редактор вместе с ним. Т.е. ты максимально близок к ядру движка, в отличие от Юнити, на которой ты можешь только C# скрипты писать и никак не контролируешь ядро. Вообще, весь код на гитхабе и это радует, даже если ты никогда ничего там не будешь редактировать и компилировать.
- Также все или большинство обсуждений разработчиков движка идут на гитхабе. Можно почитать обо всех грядущих изменениях и планах заранее, можно поучаствовать в обсуждении, предложить новые фичи или пожаловаться на баги и получить отклик от самих разработчиков, а не каких-то наёмных посредников. По сути разработка прозрачна, никто не пытается скрыть от тебя какие-то будущие изменения. Да, это всему опенсорсу свойственно, но в разной степени. С Юнити же ты можешь только надеяться, что разрабы не учудят в следующей версии что-то совсем уж неадекватное и наконец-то пофиксят многолетние баги (знаю я про багтрекер юнити, там дохрена страниц и вряд ли у реальных разрабов есть время всё это изучать, что им менеджер проекта приказал делать - то и делают).
- Мне кажется, у Годо более приятное коммьюнити (в целом по миру). Будто на Годо перешли многие адекваты, а токсики остались таскать ассеты с ассетстора. Даже если тебе не помогут, то хотя бы попытаются, а не пошлют гуглить ассеты и туториалы со словами "всё придумано до тебя, ищи". Конечно, это из-за малоизвестности движка, с популярностью придут и легионы токсиков, срущих везде, где только могут, но пока что всё относительно спокойно.
- Документация движка достаточно полная и справка встроена прямо в движок, жмёшь F1 и в большинстве случаев быстро находишь интересующую тебя информацию (оффлайн). В целом дизайн онлайн документации получше, чем у Юнити, но это вкусовщина. В редакторе оффлайн справка открывается прямо в редакторе кода, удобно переключаться в процессе кодинга. Есть кое-какие пробелы, но только в тех местах, которые в целом крайне редко могут потребоваться - все основные инструменты документированы хорошо, разберёшься без туториалов.
- В целом Годо похож на Юнити, не считая некоторых нюансов (скажем, одна нода = один скрипт, вместо добавления компонентов в пустышку - добавление нод в дерево сцены). Т.е. перенести проект с одного движка на другой не должно составить большого труда, базовые концепции одинаковые. Для меня главное отличие Годо в удобстве и простоте использования, это важнее других отличий, особенно в рамках простой 2D игры.
>родном юнити
Смотря насколько она тебе родная. Судя по тому, что делаешь 2D, вряд ли у тебя много проектов на Юнити. Освоить такой сложный инструмент на уровне "родного" вообще нереально, разве что ты имеешь в виду, что Юнити твой первый игровой движок. Если так, то готовься к синдрому утёнка, с которым придётся бороться. Для меня родной язык/инструмент - это Pascal, долго плевался от других языков и готовых движков, но всё-таки смирился с тем, что на Годо намного удобнее и проще реализовывать свои идеи, чем на всём том, что я пробовал раньше. А вот Юнити как-то не зашла, слишком сложно, медленно, глючно, много места занимает и не даёт достаточного контроля ни за движком, ни за проектом. Возможно, игры на Юнити производительнее игр на Годо, но до релиза игры ещё дожить надо, я лично не хочу страдать годами из-за редактора Юнити.
При всём при этом Годо не какой-то там конструктор для детей, на нём можно делать серьёзные проекты (просто пользуются в основном дети и нищие инди). Т.е. у Годо простота без жертвы возможностями, с минимальными жертвами по производительности билда. Согласись, все бы давно делали игры только на конструкторах игр, если бы они не сокращали возможности до очень ограниченного набора, ведь любой предпочтёт работать в большем комфорте.
>>85226
this
Звучит всё великолепно и я почти влюбился, но
звучит грустно. На c# писать - это плохая идея?
>Как в платформерах
this
> Думаю, да.
Звучит всё великолепно и я почти влюбился, но
>GDScript
звучит грустно. На c# писать - это плохая идея?
>>85248
Почему? Синтаксис похож на Питон, но по скорости выполнения лично я пока что не замечаю проблем. Неуловимых ошибок с неправильными отступами у меня тоже пока не было, скорее всего они проявляются у тех, кто любит бездумно копипастить чужой код.
Да нет, вроде бы нормально. Сам я 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 мне больше по душе, там весь код разбит на чёткие блоки, строгий порядок функций, обязательное указание типов и т.д. Чем меньше свободы, тем лучше, особенно для новичков, но если не лениться и не полагаться на подсказки компилятора, то на любом языке хороший код написать сможешь. Единственная строгость в питон-подобных языках - отступы на каждой строке, но по сравнению со всем остальным хаосом в коде отступы вообще погоды не делают, увы. А так идея с обязательными отступами хорошая, приучивает визуально структурировать код...
Извини за поток сознания)
>>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 мне больше по душе, там весь код разбит на чёткие блоки, строгий порядок функций, обязательное указание типов и т.д. Чем меньше свободы, тем лучше, особенно для новичков, но если не лениться и не полагаться на подсказки компилятора, то на любом языке хороший код написать сможешь. Единственная строгость в питон-подобных языках - отступы на каждой строке, но по сравнению со всем остальным хаосом в коде отступы вообще погоды не делают, увы. А так идея с обязательными отступами хорошая, приучивает визуально структурировать код...
Извини за поток сознания)
>>85248
Почему? Синтаксис похож на Питон, но по скорости выполнения лично я пока что не замечаю проблем. Неуловимых ошибок с неправильными отступами у меня тоже пока не было, скорее всего они проявляются у тех, кто любит бездумно копипастить чужой код.
Да нет, вроде бы нормально. Сам я 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 мне больше по душе, там весь код разбит на чёткие блоки, строгий порядок функций, обязательное указание типов и т.д. Чем меньше свободы, тем лучше, особенно для новичков, но если не лениться и не полагаться на подсказки компилятора, то на любом языке хороший код написать сможешь. Единственная строгость в питон-подобных языках - отступы на каждой строке, но по сравнению со всем остальным хаосом в коде отступы вообще погоды не делают, увы. А так идея с обязательными отступами хорошая, приучивает визуально структурировать код...
Извини за поток сознания)
>>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 мне больше по душе, там весь код разбит на чёткие блоки, строгий порядок функций, обязательное указание типов и т.д. Чем меньше свободы, тем лучше, особенно для новичков, но если не лениться и не полагаться на подсказки компилятора, то на любом языке хороший код написать сможешь. Единственная строгость в питон-подобных языках - отступы на каждой строке, но по сравнению со всем остальным хаосом в коде отступы вообще погоды не делают, увы. А так идея с обязательными отступами хорошая, приучивает визуально структурировать код...
Извини за поток сознания)
>>85226
Но это не Годетта, а Гоблин. Дим Юрич.
> Годетта бы не сказала такого никому, кто ей заинтересовался.
Но это не Годетта, а Гоблин. Дим Юрич.
>>85250
Но для этого нужно быть сишником уровня Хуана. Я так-то поначалу хотел FPC подключить, но оказалось, что надо низкоуровневую API-обвязку на сях переводить в FPC, я до такого уровня увы не дошёл. С тех пор FPC-проекты появились, но быстро сдулись. А жаль.
> можно любой ЯП подключить через GDNative или модули движка
Но для этого нужно быть сишником уровня Хуана. Я так-то поначалу хотел FPC подключить, но оказалось, что надо низкоуровневую API-обвязку на сях переводить в FPC, я до такого уровня увы не дошёл. С тех пор FPC-проекты появились, но быстро сдулись. А жаль.
>>85356
Плагин есть. Гуглить впадлу. Но базарю, есть плагин. В прошлом треде видел ссылку.
Плагин есть. Гуглить впадлу. Но базарю, есть плагин. В прошлом треде видел ссылку.
Посоветуйте, как избавиться от квадратности?
Текстуры рисовать не очень хочу - их сложно стилизовать, сложно избавиться от "тайловости".
Шейдеры, наверное, сильно повысят нагрузку, а мне бы хотелось ещё и на мобилки билд сделать.
Если повышать число треугольников, то это требует больше памяти и времени, а в результате всё равно квадратики.
Остаётся разве что маскировать границы тайлов под какими-либо объёмными декорациями...
Проблема возникла после того, как я решил попробовать отказаться от 2D сетки тайлов дорог. Т.е. допустим, я могу сгенерировать какой-то ландшафт (пик1) и сделать на нём ровные площадки под дома и дороги (пик2), но всё снова получается квадратным. Даже если размещать процедурные модели дорог и домов под произвольными углами к ландшафту, будут проблемы из-за того, что линии дорог будут пересекать квадратные тайлы...
Ну, наверное, единственный выход - уменьшать треугольники, но это сильно усложняет их генерацию. Попробую фрактальные алгоритмы, типа от больших квадратов к маленьким квадратикам (ещё хочу попробовать квадродерево)...
Текстуры рисовать не очень хочу - их сложно стилизовать, сложно избавиться от "тайловости".
Шейдеры, наверное, сильно повысят нагрузку, а мне бы хотелось ещё и на мобилки билд сделать.
Если повышать число треугольников, то это требует больше памяти и времени, а в результате всё равно квадратики.
Остаётся разве что маскировать границы тайлов под какими-либо объёмными декорациями...
Проблема возникла после того, как я решил попробовать отказаться от 2D сетки тайлов дорог. Т.е. допустим, я могу сгенерировать какой-то ландшафт (пик1) и сделать на нём ровные площадки под дома и дороги (пик2), но всё снова получается квадратным. Даже если размещать процедурные модели дорог и домов под произвольными углами к ландшафту, будут проблемы из-за того, что линии дорог будут пересекать квадратные тайлы...
Ну, наверное, единственный выход - уменьшать треугольники, но это сильно усложняет их генерацию. Попробую фрактальные алгоритмы, типа от больших квадратов к маленьким квадратикам (ещё хочу попробовать квадродерево)...
>>85375
А что если полюбить квадратность, принять её и не мешать ей создавать игре стиль?
> как избавиться от квадратности?
А что если полюбить квадратность, принять её и не мешать ей создавать игре стиль?
>>85378
Да люблю я игры типа Майнкрафта и Террарии - покупал многое и много играл. Но там квадратность обоснована возможностью изменять ландшафт. Бесчисленные "воксельные" игры, не имеющие ничего общего с майнкрафтом кроме "воксельного стиля", вызывают отвращение, ведь они подражают внешности, не затрагивая саму суть квадратности (возможность свободно редактировать ландшафт). У меня не кубопесочница, следовательно я не должен делать всё квадратным.
Тут проблемы, мне кажется, глубже просто стиля. От генерации ландшафта и города зависит форма хранения данных о мире; от этих данных зависят возможности симуляции жизни, навигации ботов и так далее. Именно поэтому я не могу просто взять готовый генератор ландшафта и не могу просто взять и нарисовать сетку треугольников, тут нужно думать, как всё собрать в единую систему с минимальным количеством костылей.
>>85379 (Del)
Ты про жёсткие грани? Не, жёсткие грани - это норм. Тут никаких вопросов, это стиль "лоуполи", а не квадраты, и если нормали сгладить, то получится фигня. Квадраты - это цветные квадратики, изображающие землю/песок/воду/бетон. Они мне нужны хотя бы потому, что от них зависит форма ландшафта (вода на уровне воды, песок рядом с водой и более гладкий, трава на возвышенности и может иметь больше складок, бетон ровный и т.д.), и дальше, по идее, должны зависеть многие другие вещи (на песке плохое сцепление с дорогой и любят отдыхать жители, на траве растут деревья и грибы, на бетоне можно строить новые дома и т.д.). Вот как эти квадраты избавить от их квадратности, не уменьшая их до уси-пуси барбисайз квадратюлечек - непонятно. Хотя можно и квадратюлечки, но тогда нужно хранить карту в квадродереве, а я пока не знаю, как соединить квадродерево с доступом по x/y координатам. Да и даже с квадродеревом - чем меньше квадраты, тем больше затраты на работу с ними, а я не хочу возиться с низкоуровневыми оптимизациями.
Где-то видел туториалы про "ландшафт из неквадратной сетки", но выглядит такая сетка отвратительно, там вместо треугольников многоугольники и это просто ужасно, как какая-то кожная болезнь. К тому же это не решает вопроса со свойствами, которые описывают квадраты.
Ещё знаю про сетку... не помню фамилию автора. Она вроде как могла бы подойти для создания "биомов" неквадратной формы, но я так и не понял, в каком формате её хранить. Пишут про вычисление расстояния до ближайшей точки, но как всем известно, вычисление расстояния - затратная операция, нельзя делать её часто. Определение координат в строго квадратной сетке намного быстрее и проще, а результат всегда однозначен (вроде).
>А что если полюбить квадратность
Да люблю я игры типа Майнкрафта и Террарии - покупал многое и много играл. Но там квадратность обоснована возможностью изменять ландшафт. Бесчисленные "воксельные" игры, не имеющие ничего общего с майнкрафтом кроме "воксельного стиля", вызывают отвращение, ведь они подражают внешности, не затрагивая саму суть квадратности (возможность свободно редактировать ландшафт). У меня не кубопесочница, следовательно я не должен делать всё квадратным.
>создавать игре стиль
Тут проблемы, мне кажется, глубже просто стиля. От генерации ландшафта и города зависит форма хранения данных о мире; от этих данных зависят возможности симуляции жизни, навигации ботов и так далее. Именно поэтому я не могу просто взять готовый генератор ландшафта и не могу просто взять и нарисовать сетку треугольников, тут нужно думать, как всё собрать в единую систему с минимальным количеством костылей.
>>85379 (Del)
>нормалями
Ты про жёсткие грани? Не, жёсткие грани - это норм. Тут никаких вопросов, это стиль "лоуполи", а не квадраты, и если нормали сгладить, то получится фигня. Квадраты - это цветные квадратики, изображающие землю/песок/воду/бетон. Они мне нужны хотя бы потому, что от них зависит форма ландшафта (вода на уровне воды, песок рядом с водой и более гладкий, трава на возвышенности и может иметь больше складок, бетон ровный и т.д.), и дальше, по идее, должны зависеть многие другие вещи (на песке плохое сцепление с дорогой и любят отдыхать жители, на траве растут деревья и грибы, на бетоне можно строить новые дома и т.д.). Вот как эти квадраты избавить от их квадратности, не уменьшая их до уси-пуси барбисайз квадратюлечек - непонятно. Хотя можно и квадратюлечки, но тогда нужно хранить карту в квадродереве, а я пока не знаю, как соединить квадродерево с доступом по x/y координатам. Да и даже с квадродеревом - чем меньше квадраты, тем больше затраты на работу с ними, а я не хочу возиться с низкоуровневыми оптимизациями.
Где-то видел туториалы про "ландшафт из неквадратной сетки", но выглядит такая сетка отвратительно, там вместо треугольников многоугольники и это просто ужасно, как какая-то кожная болезнь. К тому же это не решает вопроса со свойствами, которые описывают квадраты.
Ещё знаю про сетку... не помню фамилию автора. Она вроде как могла бы подойти для создания "биомов" неквадратной формы, но я так и не понял, в каком формате её хранить. Пишут про вычисление расстояния до ближайшей точки, но как всем известно, вычисление расстояния - затратная операция, нельзя делать её часто. Определение координат в строго квадратной сетке намного быстрее и проще, а результат всегда однозначен (вроде).
>>85378
Да люблю я игры типа Майнкрафта и Террарии - покупал многое и много играл. Но там квадратность обоснована возможностью изменять ландшафт. Бесчисленные "воксельные" игры, не имеющие ничего общего с майнкрафтом кроме "воксельного стиля", вызывают отвращение, ведь они подражают внешности, не затрагивая саму суть квадратности (возможность свободно редактировать ландшафт). У меня не кубопесочница, следовательно я не должен делать всё квадратным.
Тут проблемы, мне кажется, глубже просто стиля. От генерации ландшафта и города зависит форма хранения данных о мире; от этих данных зависят возможности симуляции жизни, навигации ботов и так далее. Именно поэтому я не могу просто взять готовый генератор ландшафта и не могу просто взять и нарисовать сетку треугольников, тут нужно думать, как всё собрать в единую систему с минимальным количеством костылей.
>>85379 (Del)
Ты про жёсткие грани? Не, жёсткие грани - это норм. Тут никаких вопросов, это стиль "лоуполи", а не квадраты, и если нормали сгладить, то получится фигня. Квадраты - это цветные квадратики, изображающие землю/песок/воду/бетон. Они мне нужны хотя бы потому, что от них зависит форма ландшафта (вода на уровне воды, песок рядом с водой и более гладкий, трава на возвышенности и может иметь больше складок, бетон ровный и т.д.), и дальше, по идее, должны зависеть многие другие вещи (на песке плохое сцепление с дорогой и любят отдыхать жители, на траве растут деревья и грибы, на бетоне можно строить новые дома и т.д.). Вот как эти квадраты избавить от их квадратности, не уменьшая их до уси-пуси барбисайз квадратюлечек - непонятно. Хотя можно и квадратюлечки, но тогда нужно хранить карту в квадродереве, а я пока не знаю, как соединить квадродерево с доступом по x/y координатам. Да и даже с квадродеревом - чем меньше квадраты, тем больше затраты на работу с ними, а я не хочу возиться с низкоуровневыми оптимизациями.
Где-то видел туториалы про "ландшафт из неквадратной сетки", но выглядит такая сетка отвратительно, там вместо треугольников многоугольники и это просто ужасно, как какая-то кожная болезнь. К тому же это не решает вопроса со свойствами, которые описывают квадраты.
Ещё знаю про сетку... не помню фамилию автора. Она вроде как могла бы подойти для создания "биомов" неквадратной формы, но я так и не понял, в каком формате её хранить. Пишут про вычисление расстояния до ближайшей точки, но как всем известно, вычисление расстояния - затратная операция, нельзя делать её часто. Определение координат в строго квадратной сетке намного быстрее и проще, а результат всегда однозначен (вроде).
>А что если полюбить квадратность
Да люблю я игры типа Майнкрафта и Террарии - покупал многое и много играл. Но там квадратность обоснована возможностью изменять ландшафт. Бесчисленные "воксельные" игры, не имеющие ничего общего с майнкрафтом кроме "воксельного стиля", вызывают отвращение, ведь они подражают внешности, не затрагивая саму суть квадратности (возможность свободно редактировать ландшафт). У меня не кубопесочница, следовательно я не должен делать всё квадратным.
>создавать игре стиль
Тут проблемы, мне кажется, глубже просто стиля. От генерации ландшафта и города зависит форма хранения данных о мире; от этих данных зависят возможности симуляции жизни, навигации ботов и так далее. Именно поэтому я не могу просто взять готовый генератор ландшафта и не могу просто взять и нарисовать сетку треугольников, тут нужно думать, как всё собрать в единую систему с минимальным количеством костылей.
>>85379 (Del)
>нормалями
Ты про жёсткие грани? Не, жёсткие грани - это норм. Тут никаких вопросов, это стиль "лоуполи", а не квадраты, и если нормали сгладить, то получится фигня. Квадраты - это цветные квадратики, изображающие землю/песок/воду/бетон. Они мне нужны хотя бы потому, что от них зависит форма ландшафта (вода на уровне воды, песок рядом с водой и более гладкий, трава на возвышенности и может иметь больше складок, бетон ровный и т.д.), и дальше, по идее, должны зависеть многие другие вещи (на песке плохое сцепление с дорогой и любят отдыхать жители, на траве растут деревья и грибы, на бетоне можно строить новые дома и т.д.). Вот как эти квадраты избавить от их квадратности, не уменьшая их до уси-пуси барбисайз квадратюлечек - непонятно. Хотя можно и квадратюлечки, но тогда нужно хранить карту в квадродереве, а я пока не знаю, как соединить квадродерево с доступом по x/y координатам. Да и даже с квадродеревом - чем меньше квадраты, тем больше затраты на работу с ними, а я не хочу возиться с низкоуровневыми оптимизациями.
Где-то видел туториалы про "ландшафт из неквадратной сетки", но выглядит такая сетка отвратительно, там вместо треугольников многоугольники и это просто ужасно, как какая-то кожная болезнь. К тому же это не решает вопроса со свойствами, которые описывают квадраты.
Ещё знаю про сетку... не помню фамилию автора. Она вроде как могла бы подойти для создания "биомов" неквадратной формы, но я так и не понял, в каком формате её хранить. Пишут про вычисление расстояния до ближайшей точки, но как всем известно, вычисление расстояния - затратная операция, нельзя делать её часто. Определение координат в строго квадратной сетке намного быстрее и проще, а результат всегда однозначен (вроде).
>>85286
Ты прилепил глаза и волосы Годетты на Гоблина, что должно подразумевать, будто это Годетта говорит слова Гоблина, не?
>>85320
Так-то Pascal и C чуть ли не родственники. Есть некоторые нюансы работы с памятью, но компиляторы Паскаля имеют специальные ключевые слова для переключения соответствующего режима, если тебе нужно линковаться с библиотекой или программой на C/C++. В остальном должно быть не сложно, все типы кроме строк одинаковые, а для Си-подобных строк есть отдельный тип (PChar, PWideChar и другие). Я как-то транслировал код на C/C++ из туториалов на FreePascal, и это было несложно как по мне.
Также планировал подключить FPC к Godot, но попробовав GDScript так и не нашёл мотивации это делать. Для чего нужно именно Паскаль подключать? Только чтобы писать на Паскале? Дело даже не в Паскале, я не понимаю самой концепции GDNative, в чём смысл сторонних языков? Видел недавно реализацию JavaScript на Godot, с поддержкой TypeScript - лол, зачем? Тут и так есть скриптовый ЯП из коробки, зачем возиться с подключением другого. Или вот кто-то пытается Lua подключить - тоже скриптовый ЯП, а зачем? Если только для подключения каких-то сторонних библиотек на подключаемом языке... А так, без библиотек, было бы интереснее всего Forth замутить, чтоб прямо внутри игры можно было кодить скрипты, не перезапуская игру - Форт запросто позволяет так делать.
Щас почитаю, что нужно для GDNative и попробую сделать на FPC, если разберусь, как. Только если это не связано с перкомпиляцией всего Godot... Серьёзно, почему нельзя было сделать универсальный загрузчик? Я пробовал делать такой механизм на FPC, мог подключать любое количество DLL динамически, без перекомпиляции, если у них (DLL) есть необходимые моей программе интерфейсы...
>это не Годетта, а Гоблин
Ты прилепил глаза и волосы Годетты на Гоблина, что должно подразумевать, будто это Годетта говорит слова Гоблина, не?
>>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) есть необходимые моей программе интерфейсы...
5 Кб, 175x128Суп, gd, я делал HUD и обосрался. Дай, пожалуйста, гайд по тому, как правильно расставлять ЕБУЧИЕ КОНТЕЙНЕРЫ внутри ЕБУЧИХ КОНТЕЙНЕРОВ, чтобы они стояли на своём месте.
Ещё у меня один из элементов HUDа состоит из тупо спрайтов, которым нужно двигаться. Я вообще смогу заставить TextureRect нормально двигаться из кода, или нунахуй? Вроде всё работает, просто НА СВОИ МЕСТА, БЛДЖАД, НЕ СТАНОВИТСЯ.
Ещё у меня один из элементов HUDа состоит из тупо спрайтов, которым нужно двигаться. Я вообще смогу заставить TextureRect нормально двигаться из кода, или нунахуй? Вроде всё работает, просто НА СВОИ МЕСТА, БЛДЖАД, НЕ СТАНОВИТСЯ.
176 Кб, 424x232>>85400
https://docs.godotengine.org/en/stable/tutorials/gui/gui_containers.html
Первая ссылка в Гугле по "godot container".
Да, я пробовал крутить свою миникарту кодом, всё норм.
Ты бы лучше скриншотами показал, что у тебя не так...
Если кратко,
- никак:
Т.е. всё, что от тебя требуется - выбрать правильный тип контейнера, сложить в него ноды и задать размер контейнера. Всё остальное контейнер сделает автоматически.
>КОНТЕЙНЕРЫ
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: (пикрил)
Т.е. всё, что от тебя требуется - выбрать правильный тип контейнера, сложить в него ноды и задать размер контейнера. Всё остальное контейнер сделает автоматически.
>>85320
А сколько их было? Я только один нашёл:
https://github.com/BenediktMagnus/godot-object-pascal
Я посмотрел, что нужно сделать для GDNative. Если кратко, то перевод биндингов с C на Pascal не самое сложное. Сложно это всё в годный вид привести, чтоб не нужно было писать тонны бойлерплейта, обращаться к C-функциям напрямую и использовать типы Годо. Нужна, я считаю, ООП-обвязка, слой абстракции или фреймворк, не знаю как лучше назвать. Короче, так, как предлагают писать натив скрипты в мануале Годо я писать не хочу.
Посмотрим, что с этим можно сделать...
Интересно, а можно сделать C++-модуль, чтобы писать на Паскале прямо в редакторе Годо? Ну там, подсветка, автодополнение, поиск по справке, компиляция перед запуском (вызовом FPC). Было бы нереально круто. Но это и очень сложно, как я понимаю.
>FPC-проекты появились, но быстро сдулись
А сколько их было? Я только один нашёл:
https://github.com/BenediktMagnus/godot-object-pascal
Я посмотрел, что нужно сделать для GDNative. Если кратко, то перевод биндингов с C на Pascal не самое сложное. Сложно это всё в годный вид привести, чтоб не нужно было писать тонны бойлерплейта, обращаться к C-функциям напрямую и использовать типы Годо. Нужна, я считаю, ООП-обвязка, слой абстракции или фреймворк, не знаю как лучше назвать. Короче, так, как предлагают писать натив скрипты в мануале Годо я писать не хочу.
Посмотрим, что с этим можно сделать...
Интересно, а можно сделать C++-модуль, чтобы писать на Паскале прямо в редакторе Годо? Ну там, подсветка, автодополнение, поиск по справке, компиляция перед запуском (вызовом FPC). Было бы нереально круто. Но это и очень сложно, как я понимаю.
>>85551
Сейм. Умом понимаю, что это сделано для универсальности, но желудок не принимает.
Можно. ГДскрипт - это собственно такой модуль.
> как предлагают писать натив скрипты в мануале Годо я писать не хочу
Сейм. Умом понимаю, что это сделано для универсальности, но желудок не принимает.
> Интересно, а можно сделать C++-модуль, чтобы писать на Паскале прямо в редакторе Годо?
Можно. ГДскрипт - это собственно такой модуль.
Как вообще компилировать проект не собирая все в один exe файл? Есть какой-нибудь гайд или галочка? Или нужно как-то иначе продумывать архитектуру?
>>85699
>>85700 (Del)
Короче понял, нужно писать четкую архитектуру игры с айпи для модинга. Нужно поковырять это в будущем, чет мало инфы обо всем этом.
>>85700 (Del)
Короче понял, нужно писать четкую архитектуру игры с айпи для модинга. Нужно поковырять это в будущем, чет мало инфы обо всем этом.
>>85671
>>85698
Если ты хочешь разрешить игроку свободно редактировать любые файлы, тогда вообще ничего делать не надо, просто кидаешь шаблон экспорта Годо в папку проекта, архивируешь и выкладываешь это как игру. Простой игрок сможет запустить игру с шаблона экспорта, а моддер сможет отредактировать любые файлы. Правда, я обнаружил один нюанс: шаблон экспорта не сможет запустить игру, если не найдёт .import-файлы, т.е. он не умеет их автоматически обновлять/создавать, поэтому для некоторых модификаций моддеру всё равно потребуется редактор Годо.
Если же ты хочешь скрыть от игрока исходники скриптов, можно написать их на GDNative, тогда в папке проекта/у игрока останется только нативный билд кода, а исходники будут только у тебя.
>>85702
Это везде так, если ты хочешь позволить игрокам безопасно (без риска сломать игру) устанавливать множество модов и делать подборки разных модов. Поэтому мало кто делает официальное апи для моддинга - это весьма сложно, я думаю.
>компилировать проект не собирая все в один exe файл
>>85698
>как давать доступ к модингу игры?
Если ты хочешь разрешить игроку свободно редактировать любые файлы, тогда вообще ничего делать не надо, просто кидаешь шаблон экспорта Годо в папку проекта, архивируешь и выкладываешь это как игру. Простой игрок сможет запустить игру с шаблона экспорта, а моддер сможет отредактировать любые файлы. Правда, я обнаружил один нюанс: шаблон экспорта не сможет запустить игру, если не найдёт .import-файлы, т.е. он не умеет их автоматически обновлять/создавать, поэтому для некоторых модификаций моддеру всё равно потребуется редактор Годо.
Если же ты хочешь скрыть от игрока исходники скриптов, можно написать их на GDNative, тогда в папке проекта/у игрока останется только нативный билд кода, а исходники будут только у тебя.
>>85702
>нужно писать четкую архитектуру игры с айпи для модинга
Это везде так, если ты хочешь позволить игрокам безопасно (без риска сломать игру) устанавливать множество модов и делать подборки разных модов. Поэтому мало кто делает официальное апи для моддинга - это весьма сложно, я думаю.
>>85716
Зачем так рано перекатываешь? Непривычно как-то, остальные треды обычно долго не перекатывают...
Зачем так рано перекатываешь? Непривычно как-то, остальные треды обычно долго не перекатывают...
>>85913
Пунктуальность, сэр.
Пунктуальность, сэр.
20 Кб, 300x256>>84212
Конечно-же на РЫГМУКЕРЕ!
Конечно-же на РЫГМУКЕРЕ!
>>79700
Мутирую в гидралиска.
Мутирую в гидралиска.
Тред утонул или удален.
Это копия, сохраненная 30 июня 2023 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Это копия, сохраненная 30 июня 2023 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.