Добро пожаловать в тред любви и взаимопомощи, общего пула айсикью и классических языков программирования!
Шапка: https://hipolink.me/godothread
Предыдущий: >>970671 (OP)
Архивный: >>963889 (OP)
Шапка: https://hipolink.me/godothread
Предыдущий: >>970671 (OP)
Архивный: >>963889 (OP)
Вы же сделали игры, верно? Отправляйте их сюда, время до 1 ноября:
https://godotengine.org/article/submissions-open-godot-2024-showreel/
https://godotengine.org/article/submissions-open-godot-2024-showreel/
135 Кб, 573x604>>3501
Order Road 2?
Order Road 2?
>>3582
Что-то типа пазл-платформера. Сначала проходишь уровень на чилле без опасных препятствий, потом начинается пиздорезная версия уровня, а его интенсивность зависит от того как именно ты прошел чилловую версию
Что-то типа пазл-платформера. Сначала проходишь уровень на чилле без опасных препятствий, потом начинается пиздорезная версия уровня, а его интенсивность зависит от того как именно ты прошел чилловую версию
>>3586
Звучит прикольно. У меня была как то идея всех скидываемых врагов копить в одном подвале, а потом выпускать разом. Можно еще механики агро прикрутить, когда они злятся если видят как ты кого то убиваешь или прокрадываешься.
А я пока придумал, что будут ветрогенераторы, они какое то время позволяют накопить ресурсы, потом перед штормом штиль, а потом во время шторма будет небольшой бурст который можно потратить экстренно.
Звучит прикольно. У меня была как то идея всех скидываемых врагов копить в одном подвале, а потом выпускать разом. Можно еще механики агро прикрутить, когда они злятся если видят как ты кого то убиваешь или прокрадываешься.
А я пока придумал, что будут ветрогенераторы, они какое то время позволяют накопить ресурсы, потом перед штормом штиль, а потом во время шторма будет небольшой бурст который можно потратить экстренно.
>>973271 →
Вот общая схема. Называется "hub and spoke". Отличается от обычного "waterfall" возвратом. Собственно, много играл в такое, мне нравится, несмотря на повторяемость и предсказуемость - полноценный геймплей с полной свободой, и без бесполезных "концовок" - играй, сколько хочешь. Останавливаешься в любом месте и можешь на минуточку заглянуть в любое время суток. Часто глобального сюжета нет, игрок волен делать что пожелает - прокачиваться, взаимодействовать с автономными NPC, которые тоже что-то делают параллельно действиям игрока и т.д. Эта схема обеспечивает высокую степень модульности, т.е. дополнительный контент без проблем стыкуется с имеющимся, если правильно всё организовать...
>написать интересный сценарий
Вот общая схема. Называется "hub and spoke". Отличается от обычного "waterfall" возвратом. Собственно, много играл в такое, мне нравится, несмотря на повторяемость и предсказуемость - полноценный геймплей с полной свободой, и без бесполезных "концовок" - играй, сколько хочешь. Останавливаешься в любом месте и можешь на минуточку заглянуть в любое время суток. Часто глобального сюжета нет, игрок волен делать что пожелает - прокачиваться, взаимодействовать с автономными NPC, которые тоже что-то делают параллельно действиям игрока и т.д. Эта схема обеспечивает высокую степень модульности, т.е. дополнительный контент без проблем стыкуется с имеющимся, если правильно всё организовать...
парни, я ретард, есть гайд с рисуночками, стрелочками всякими по тому, что за ебаная магия творится с векторами в дирекшене, велосити, мелосити.раундед и прочем кале, я нихуя не понимаю
45 Кб, 560x273У меня с global position какие-то чудеса, сейчас принялся за эффект взрыва астероида, в общем если не указывать глобальную позицию, то он как положено воспроизводится на нулевых координатах. Но как только я добавляю позицию астероида - все, партиклов нет. Для теста добавил лейбл - и он выводится где надо. Обычную позицию чистил, результата 0
>>3648
Спасибо, работает
Спасибо, работает
>>3639
Эти читал уже?
https://docs.godotengine.org/en/stable/tutorials/math/vector_math.html
https://docs.godotengine.org/en/stable/tutorials/math/vectors_advanced.html
Самый простой способ понять, что не так - самому нарисовать стрелочки на месте своих векторов.
>гайд с рисуночками, стрелочками
>магия творится с векторами
Эти читал уже?
https://docs.godotengine.org/en/stable/tutorials/math/vector_math.html
https://docs.godotengine.org/en/stable/tutorials/math/vectors_advanced.html
Самый простой способ понять, что не так - самому нарисовать стрелочки на месте своих векторов.
>>3642
Да ладно, чего спешишь, можно 3.6.1 подождать.
Да ладно, чего спешишь, можно 3.6.1 подождать.
>>3647
Рекомендую при знакомстве с чем-то новым читать документацию, потом тыкать во все кнопки. Увидел свойство в документации - сразу потыкал в него. Так быстрее запомнишь, что, к чему и зачем.
Рекомендую при знакомстве с чем-то новым читать документацию, потом тыкать во все кнопки. Увидел свойство в документации - сразу потыкал в него. Так быстрее запомнишь, что, к чему и зачем.
почему в 2д Y это вниз, а -Y это вверх? в 3д Y это вверх, а -Y это вниз, хотя во всех 3д редакторах это вообще ось Z
это наверно везде так, почему так в геймдеве? ну типа я прочитал мотивацию, почему это в 2д, типа сверху вниз справа налево, но в 3д-то нахуя это лепить
это наверно везде так, почему так в геймдеве? ну типа я прочитал мотивацию, почему это в 2д, типа сверху вниз справа налево, но в 3д-то нахуя это лепить
180 Кб, 600x503>>3671
Y - ось вверх/вниз, X - право/лево, следовательно Z - глубина
А вообще кто как хочет, так и дрочит
Y - ось вверх/вниз, X - право/лево, следовательно Z - глубина
А вообще кто как хочет, так и дрочит
>>3675
Да я в любом случае в крысу буду делать, как мне кажется правильным и в итоге изобрету неподдерживаемый велосипед. Стандарты меня не остановят.
Да я в любом случае в крысу буду делать, как мне кажется правильным и в итоге изобрету неподдерживаемый велосипед. Стандарты меня не остановят.
>>3671
У математмков на графиках Y была всегда наверх, но в 70-80х когда программмсты делали компы, они считали пиксели с левого верхнего угла. Ну потому что буквы то в текстовом режиме оттуда идутьна принтере/экране. Опенгл кстати снизу считает, и приходится каждый раз флипать
> почему в 2д Y это вниз, а -Y это вверх?
У математмков на графиках Y была всегда наверх, но в 70-80х когда программмсты делали компы, они считали пиксели с левого верхнего угла. Ну потому что буквы то в текстовом режиме оттуда идутьна принтере/экране. Опенгл кстати снизу считает, и приходится каждый раз флипать
>>3674
В Годотне и так в 3D вперёд это -Z, если бы ещё и -Y был бы вверх, то ебанулись бы все
В Годотне и так в 3D вперёд это -Z, если бы ещё и -Y был бы вверх, то ебанулись бы все
>>3677
В OpenGL вообще из центра экрана отсчёт.
Центр экрана: (0.0; 0.0)
Левый верхний угол экрана: (-1.0; 1.0)
Правый нижний угол экрана: (1.0; -1.0)
Получается квадрат... На прямоугольный экран.
Чтоб вывести картинку ровно, нужно не просто перевернуть, а сжать в зависимости от отношения сторон экрана. Поэтому, наверное, в древних играх проблема с широкими экранами - они хардкодили соотношение 4:3, не думая о возможных других.
Хорошо хоть современные движки научились абстрагироваться от соотношений сторон экрана. Кидаешь камеру в сцену и не думаешь об экране.
>Опенгл кстати снизу считает
В OpenGL вообще из центра экрана отсчёт.
Центр экрана: (0.0; 0.0)
Левый верхний угол экрана: (-1.0; 1.0)
Правый нижний угол экрана: (1.0; -1.0)
Получается квадрат... На прямоугольный экран.
Чтоб вывести картинку ровно, нужно не просто перевернуть, а сжать в зависимости от отношения сторон экрана. Поэтому, наверное, в древних играх проблема с широкими экранами - они хардкодили соотношение 4:3, не думая о возможных других.
Хорошо хоть современные движки научились абстрагироваться от соотношений сторон экрана. Кидаешь камеру в сцену и не думаешь об экране.
А можно как-то умно синхронизировать переключение сцен и скриптов? Заёбывает иногда, интерфейс немного странный в этом плане.
Объясните мне раз и навсегда, доступно, CSG меши медленные когда именно? Если я просто их отображаю - они медленнее обычных мешей? А если я начинаю их двигать? А если скалировать?
>>3707
Достаточно просто привыкнуть, что сцена не скрипт.
Сцена - это иерархическая композиция из нод.
Скрипт - это расширение встроенных объектов.
Ты можешь расширять любые объекты без сцен.
Можешь применять один скрипт в разных сценах.
Это принципиально разные вещи.
Так что организуй работу вокруг этих концепций.
>синхронизировать переключение сцен и скриптов
Достаточно просто привыкнуть, что сцена не скрипт.
Сцена - это иерархическая композиция из нод.
Скрипт - это расширение встроенных объектов.
Ты можешь расширять любые объекты без сцен.
Можешь применять один скрипт в разных сценах.
Это принципиально разные вещи.
Так что организуй работу вокруг этих концепций.
>>3708
во спс
во спс
>>3710
Да это всё понятно, потом отключу.
Да это всё понятно, потом отключу.
>>3709
Фишка CSG мешей, ради которой они нужны - булевы операции над геометрией, т.е. сложение, вычитание, пересечение. Если тебе эти операции не нужны - не используй CSG ноды. Эти операции полезны для прототипирования геометрии уровня/объектов.
Соответственно, CSG ноды медленные, когда они производят заданные булевы операции - чтобы сгенерировать финальный меш. Например, если ты разместил 2 куба с операцией вычитания одного из другого, то перемещение одного из кубов будет требовать от движка сгенерировать новый меш - кубический с кубической дыркой в нём. Если ты перемещаешь результат, то регенерации не будет.
Также, из-за сложности булевых операций, меши в результате получаются довольно кривыми, с очень вытянутыми треугольниками, что вызывает много графических артефактов и может негативно влиять на рендеринг сцены (особенно на мобилках). Так что использовать CSG ноды в билде игры не стоит, даже если они остаются полностью неподвижны.
Рекомендуемый процесс работы с CSG нодами:
1. Быстро делаешь прототип уровня из CSG нод.
2. Играешь на своём компе, тестируя геймплей.
3. Правишь по необходимости, двигая CSG годы.
4. Экспортируешь уровень из Godot в Blender.
5. В Blender делаешь качественную модель.
6. Экспортируешь сцену из Blender в Godot.
7. Удаляешь CSG ноды, заменяя их мешем.
8. Публикуешь игру без CSG нод.
Замечу: в Blender тоже есть булевы операции над геометрией, но роль CSG нод в Godot - ускорить прототипирование, чтоб не нужно было метаться в отдельную программу ради мелких изменений.
>CSG меши медленные когда именно?
Фишка CSG мешей, ради которой они нужны - булевы операции над геометрией, т.е. сложение, вычитание, пересечение. Если тебе эти операции не нужны - не используй CSG ноды. Эти операции полезны для прототипирования геометрии уровня/объектов.
Соответственно, CSG ноды медленные, когда они производят заданные булевы операции - чтобы сгенерировать финальный меш. Например, если ты разместил 2 куба с операцией вычитания одного из другого, то перемещение одного из кубов будет требовать от движка сгенерировать новый меш - кубический с кубической дыркой в нём. Если ты перемещаешь результат, то регенерации не будет.
Также, из-за сложности булевых операций, меши в результате получаются довольно кривыми, с очень вытянутыми треугольниками, что вызывает много графических артефактов и может негативно влиять на рендеринг сцены (особенно на мобилках). Так что использовать CSG ноды в билде игры не стоит, даже если они остаются полностью неподвижны.
Рекомендуемый процесс работы с CSG нодами:
1. Быстро делаешь прототип уровня из CSG нод.
2. Играешь на своём компе, тестируя геймплей.
3. Правишь по необходимости, двигая CSG годы.
4. Экспортируешь уровень из Godot в Blender.
5. В Blender делаешь качественную модель.
6. Экспортируешь сцену из Blender в Godot.
7. Удаляешь CSG ноды, заменяя их мешем.
8. Публикуешь игру без CSG нод.
Замечу: в Blender тоже есть булевы операции над геометрией, но роль CSG нод в Godot - ускорить прототипирование, чтоб не нужно было метаться в отдельную программу ради мелких изменений.
>>3719
Лишь немного экспериментировал, так что не могу сказать точно. Разница в том, что в Blender ты всю сетку вручную можешь поправить, а в Godot нет настолько продвинутого редактора мешей. Также в блендере нужно модификаторы навешивать для булевых операций (неудобно), а в Godot ты просто ноды друг в друга вкладываешь - быстрее выходит.
Думаю, что булевы операции в блендере в первую очередь используются как начальная подготовка основы для скульптинга. В скульптинге вроде не так важна сетка - всё равно будешь делать ремеш.
Короче, цели у них разные.
Лишь немного экспериментировал, так что не могу сказать точно. Разница в том, что в Blender ты всю сетку вручную можешь поправить, а в Godot нет настолько продвинутого редактора мешей. Также в блендере нужно модификаторы навешивать для булевых операций (неудобно), а в Godot ты просто ноды друг в друга вкладываешь - быстрее выходит.
Думаю, что булевы операции в блендере в первую очередь используются как начальная подготовка основы для скульптинга. В скульптинге вроде не так важна сетка - всё равно будешь делать ремеш.
Короче, цели у них разные.
>>3724
Тебе официального не хватает?
https://docs.godotengine.org/en/stable/tutorials/3d/global_illumination/using_lightmap_gi.html
>>3725
Любая 3D игра с неподвижным светом.
У тебя из-за "лоуполи" света в игре нет?
>Почему так мало
Тебе официального не хватает?
https://docs.godotengine.org/en/stable/tutorials/3d/global_illumination/using_lightmap_gi.html
>>3725
>игры где они нужны
Любая 3D игра с неподвижным светом.
>лоуполи 3д
У тебя из-за "лоуполи" света в игре нет?
>>3726
У меня из 3д есть два проекта: один огромный город, где все динамично и запекать смысла нет, и 3д для веба, где все что можно пришлось отключить.
У меня из 3д есть два проекта: один огромный город, где все динамично и запекать смысла нет, и 3д для веба, где все что можно пришлось отключить.
>>3728
Это технология древних цивилизаций:
Рендеринг в вебе доступен:
Или у тебя 3.6? Там тоже есть.
https://docs.godotengine.org/en/3.6/tutorials/3d/baked_lightmaps.html
Если есть помещения, то можно запечь свет в них. К примеру, в GTA VC/SA так делали - динамичный свет снаружи, а внутри помещений обычно свет запечён.
Здесь показывать будешь?
>3д для веба
Это технология древних цивилизаций:
>Despite their lack of flexibility, baked lightmaps typically offer both the best quality and performance at the same time in (mostly) static scenes. This makes lightmaps still popular in game development, despite lightmaps being the oldest technique for global illumination in video games.
Рендеринг в вебе доступен:
>On Android and web platforms, only rendering lightmaps that were baked on a desktop PC is supported.
Или у тебя 3.6? Там тоже есть.
https://docs.godotengine.org/en/3.6/tutorials/3d/baked_lightmaps.html
>все динамично
Если есть помещения, то можно запечь свет в них. К примеру, в GTA VC/SA так делали - динамичный свет снаружи, а внутри помещений обычно свет запечён.
>один огромный город
Здесь показывать будешь?
>>3726
Да. В руководстве - примеры на примитивах. Я никогда свет не запекал и сложно понять, как правильно запечь обставленную комнату. Придётся тыкаться и набивать шишки.
>Тебе официального не хватает?
Да. В руководстве - примеры на примитивах. Я никогда свет не запекал и сложно понять, как правильно запечь обставленную комнату. Придётся тыкаться и набивать шишки.
>>3732
есть ещё вариант попробовать почитать уроки в других движках и потом прикинуть на Годот, логику ты уже будешь понимать, останется только реолизовать
есть ещё вариант попробовать почитать уроки в других движках и потом прикинуть на Годот, логику ты уже будешь понимать, останется только реолизовать
869 Кб, 1280x720Dev snapshot: Godot 4.4 dev 2
https://godotengine.org/article/dev-snapshot-godot-4-4-dev-2/
Погодите, это реально?
https://godotengine.org/article/dev-snapshot-godot-4-4-dev-2/
Погодите, это реально?
>>3745
Успеть бы насладиться. А то таймлайн тревожный.
Срочно пилим по 1 игре в неделю! Я уже начал ждать 4.4.1, вот тогда точно начну!
Успеть бы насладиться. А то таймлайн тревожный.
Срочно пилим по 1 игре в неделю! Я уже начал ждать 4.4.1, вот тогда точно начну!
>>3746
А я вам говорю - делайте игры, а вы все не делаете, ждете. Вот так и умрете не сделав ни одной игры.
>Успеть бы насладиться. А то таймлайн тревожный.
А я вам говорю - делайте игры, а вы все не делаете, ждете. Вот так и умрете не сделав ни одной игры.
>>3744
Интересно что если пробежаться по авторам заметных коммитов, то некоторые из них совсем ноунеймы. В релизе упоминается некий https://github.com/Hilderin, у него пустой профиль и Понг в проектах. А фичу он сделал сложную и полезную. Как это происходит? Откуда такие волонтеры, герои в плащах и масках?
Интересно что если пробежаться по авторам заметных коммитов, то некоторые из них совсем ноунеймы. В релизе упоминается некий https://github.com/Hilderin, у него пустой профиль и Понг в проектах. А фичу он сделал сложную и полезную. Как это происходит? Откуда такие волонтеры, герои в плащах и масках?
Помогите, аноны. Как максимально быстро сделать доп-даун шутер или рпг аля дьябло, если нет времени читать субтитры?
Есть хоть кто-нибудь на русском, кто рассказывает про годот 4?
Я пока смотрю Паштета и ролики двухлетней давности.
Есть хоть кто-нибудь на русском, кто рассказывает про годот 4?
Я пока смотрю Паштета и ролики двухлетней давности.
>>3752
Я максимально быстро делаю так:
Делаю сцену игрового уровня, сцену игрока (готовый контроллер из ассетов либо сам пишу, там немного), сцену врагов которые спавнятся, игровую логику, ну там пульки всякие в группах или слоях, ну и потом анимации вставляю.
Я максимально быстро делаю так:
Делаю сцену игрового уровня, сцену игрока (готовый контроллер из ассетов либо сам пишу, там немного), сцену врагов которые спавнятся, игровую логику, ну там пульки всякие в группах или слоях, ну и потом анимации вставляю.
>>3752
Я по мере надобности включаю иностранцев но с переводом от хуяндекс, основная суть переводится, да и по большей части самому нужен только код
Я по мере надобности включаю иностранцев но с переводом от хуяндекс, основная суть переводится, да и по большей части самому нужен только код
>>3758
Мое почтение. Сделай симулятор кассира типа papers please.
Мое почтение. Сделай симулятор кассира типа papers please.
А тут же вроде кто то делал игру стратегию на гексовом поле, у него вроде даже тред был. Там какие домики строить надо было и решать паззлы.
Анончики, а можно сделать шейдер ваншотным? И можно ли запускать шейдер через скрипт?
>>3787
Ну в целом да, вопрос чего ты пытаешься добиться, как вар куда смотреть * общее направление, партикл шейдеры в редакторе онашотятся, про запуск из кода - да, у тебя очевидно у шейдера есть параметры ( если ты их указал конечно ) вот отсюда и пляши. Но это в общем, тут еще есть поправка на версию годо если память не изменяет (только в 4.х этим занимался про 3ю не уверен)
Ну в целом да, вопрос чего ты пытаешься добиться, как вар куда смотреть * общее направление, партикл шейдеры в редакторе онашотятся, про запуск из кода - да, у тебя очевидно у шейдера есть параметры ( если ты их указал конечно ) вот отсюда и пляши. Но это в общем, тут еще есть поправка на версию годо если память не изменяет (только в 4.х этим занимался про 3ю не уверен)
>>3788
У меня есть компьютер в игре, решил добавить туда файлик jpg, при нажатие картинка появляется слой за слоем, как в бородатые времена. "Слой за слоем" сделал шейдером, вот хочу запускать его при нажатие на кнопку и чтобы он срабатывал один раз. Работаю в 4.3
>вопрос чего ты пытаешься добиться
У меня есть компьютер в игре, решил добавить туда файлик jpg, при нажатие картинка появляется слой за слоем, как в бородатые времена. "Слой за слоем" сделал шейдером, вот хочу запускать его при нажатие на кнопку и чтобы он срабатывал один раз. Работаю в 4.3
>>3748
А ты-то кто, чтобы обвинять их в ноунеймости?
Во-первых, может, он не хочет связывать вклад в Godot со своим основным/бизнес аккаунтом. Как минимум, могут быть легальные проблемы, если его основная работа как-то связана с геймдевом.
Во-вторых, для работы над игровым движком вовсе не обязательно уметь делать игры, и работа над движком поглощает столько времени, что на создание своих игр времени совсем не остаётся. А то и желания.
В-третьих, для тестов движка есть чужие проекты. Разработчики игр просят фичи/багфиксы - разрабы движка вносят исправления - разрабы игр тестят. Разрабатывать сразу движок и игру не нужно.
Самый популярный опенсурс движок. Куда им ещё вкладываться, в ноунейм васянку на дне гитхаба?
>совсем ноунеймы
А ты-то кто, чтобы обвинять их в ноунеймости?
>пустой профиль и Понг в проектах
Во-первых, может, он не хочет связывать вклад в Godot со своим основным/бизнес аккаунтом. Как минимум, могут быть легальные проблемы, если его основная работа как-то связана с геймдевом.
Во-вторых, для работы над игровым движком вовсе не обязательно уметь делать игры, и работа над движком поглощает столько времени, что на создание своих игр времени совсем не остаётся. А то и желания.
В-третьих, для тестов движка есть чужие проекты. Разработчики игр просят фичи/багфиксы - разрабы движка вносят исправления - разрабы игр тестят. Разрабатывать сразу движок и игру не нужно.
>Откуда такие волонтеры
Самый популярный опенсурс движок. Куда им ещё вкладываться, в ноунейм васянку на дне гитхаба?
>>3787 >>3790
Изучай вьюпорты:
https://docs.godotengine.org/en/stable/classes/class_subviewport.html
https://docs.godotengine.org/en/stable/tutorials/rendering/viewports.html
Вкратце алгоритм:
1. Создаёшь отдельный вьюпорт:
render_target_update_mode = UPDATE_DISABLED
2. Настраиваешь его как тебе угодно.
3. Вставляешь текстуру из него куда хочешь.
4. Когда нужно обновить состояние текстуры:
render_target_update_mode = UPDATE_ONCE
5. Вьюпорт делает 1 проход и отключается.
Изучай вьюпорты:
https://docs.godotengine.org/en/stable/classes/class_subviewport.html
https://docs.godotengine.org/en/stable/tutorials/rendering/viewports.html
Вкратце алгоритм:
1. Создаёшь отдельный вьюпорт:
render_target_update_mode = UPDATE_DISABLED
2. Настраиваешь его как тебе угодно.
3. Вставляешь текстуру из него куда хочешь.
4. Когда нужно обновить состояние текстуры:
render_target_update_mode = UPDATE_ONCE
5. Вьюпорт делает 1 проход и отключается.
>>3793
Спасибо, буду пробывать
Спасибо, буду пробывать
>>3752
А зачем ты видео смотришь? Читай документацию.
По геймдизайну есть книги, по левел дизайну есть книги, по всему книги. По движку - документация. Принципиально нового в видео "туториалах" нет, пережёванная сотню раз информация от древних цивилизаций, обнаруженная зумерами в архивах.
Вы б ещё в тиктоке геймдеву обучались...
>>3758
С рождения и 24/7? Английский в школе обязателен. Даже получая тройки за присутствие я в кои-то веки научился читать документацию на английском.
Ну и если у тебя нет игрового опыта - у тебя намного серьёзнее проблемы, чем отсутствие туториалов. Туториалы не научат тебя делать то, что ты никогда самостоятельно не изучал... А большинство игр на английском или с очень кривым переводом, так что проще играть на английском, чем с переводом.
>если нет времени читать субтитры?
А зачем ты видео смотришь? Читай документацию.
По геймдизайну есть книги, по левел дизайну есть книги, по всему книги. По движку - документация. Принципиально нового в видео "туториалах" нет, пережёванная сотню раз информация от древних цивилизаций, обнаруженная зумерами в архивах.
Вы б ещё в тиктоке геймдеву обучались...
>>3758
>Я в пятерочке работал
С рождения и 24/7? Английский в школе обязателен. Даже получая тройки за присутствие я в кои-то веки научился читать документацию на английском.
Ну и если у тебя нет игрового опыта - у тебя намного серьёзнее проблемы, чем отсутствие туториалов. Туториалы не научат тебя делать то, что ты никогда самостоятельно не изучал... А большинство игр на английском или с очень кривым переводом, так что проще играть на английском, чем с переводом.
>>3752
И вообще:
Геймдев, особенно в соло - это долгий и трудоёмкий процесс. Да, есть короткие джемы - это спортивное состязание типа "кто дальше закинет камень", там необходимо иметь подготовку и делать абы как, минимально рабочий продукт. Если тебе нужно разработать полноценную игру, тебе в любом случае понадобится много времени, терпения, усидчивости. Если не можешь вынести просмотр короткого видео с субтитрами - наверное, это хобби не подходит тебе.
Достаточно посмотреть на примеры успешных игр с геймджемов. Да, изначально игра "сделана" всего за пару дней, но потом её доделывают несколько ЛЕТ, прежде чем делают релиз в Стим или ещё куда. Если не готов сидеть за компом несколько лет, то смысла начинать просто нет, ты всё равно не потянешь, забросишь всю работу на полпути (как многие).
А если хочешь участвовать в геймджеме прям щас, тогда делай то, что уже умеешь - учиться поздно, на геймджеме демонстрируют уже имеющиеся скиллы.
И вообще:
>максимально быстро сделать
>если нет времени
Геймдев, особенно в соло - это долгий и трудоёмкий процесс. Да, есть короткие джемы - это спортивное состязание типа "кто дальше закинет камень", там необходимо иметь подготовку и делать абы как, минимально рабочий продукт. Если тебе нужно разработать полноценную игру, тебе в любом случае понадобится много времени, терпения, усидчивости. Если не можешь вынести просмотр короткого видео с субтитрами - наверное, это хобби не подходит тебе.
Достаточно посмотреть на примеры успешных игр с геймджемов. Да, изначально игра "сделана" всего за пару дней, но потом её доделывают несколько ЛЕТ, прежде чем делают релиз в Стим или ещё куда. Если не готов сидеть за компом несколько лет, то смысла начинать просто нет, ты всё равно не потянешь, забросишь всю работу на полпути (как многие).
А если хочешь участвовать в геймджеме прям щас, тогда делай то, что уже умеешь - учиться поздно, на геймджеме демонстрируют уже имеющиеся скиллы.
>>3795
У всех разный жизненный опыт, ну вот например я щас безработный, и в следующем году снова придется пердолить на галеру чтобы прокормить себя, очевидно разработка игры начнет буксовать а вот когда уволюсь уухх ебать... как бульдозер буду выдавать обновления.... Размусоливать это не вижу смысла, скажу только что в идеальном мире, на улице я бы встречал только хуанов.
Мне технические документы тяжело даются, и теория в целом, обычно учусь на своих ошибках и пошагово, типа как с наставником кого ютуб вполне себе компенсирует, в какой-то момент сам начинаешь всё кодить, хоть и с костылями.
Так они есть, просто на инглише в основном, но онлайн перевод вполне себе компенсирует отсутствие полных знаний языка. Ну и бля, каждый по своему усваивает информацию, главное чтобы усвоил и смог что-то сам сварганить, и чтобы было интересно.
Я мыслю на русском, поэтому предпочитаю наш православный
>С рождения и 24/7? Английский в школе обязателен
У всех разный жизненный опыт, ну вот например я щас безработный, и в следующем году снова придется пердолить на галеру чтобы прокормить себя, очевидно разработка игры начнет буксовать а вот когда уволюсь уухх ебать... как бульдозер буду выдавать обновления.... Размусоливать это не вижу смысла, скажу только что в идеальном мире, на улице я бы встречал только хуанов.
>читать документацию
Мне технические документы тяжело даются, и теория в целом, обычно учусь на своих ошибках и пошагово, типа как с наставником кого ютуб вполне себе компенсирует, в какой-то момент сам начинаешь всё кодить, хоть и с костылями.
>отсутствие туториалов
Так они есть, просто на инглише в основном, но онлайн перевод вполне себе компенсирует отсутствие полных знаний языка. Ну и бля, каждый по своему усваивает информацию, главное чтобы усвоил и смог что-то сам сварганить, и чтобы было интересно.
>так что проще играть на английском, чем с переводом.
Я мыслю на русском, поэтому предпочитаю наш православный
>>3799
При чём тут разработка, речь о "сделать быстро, не тратя время на просмотр видео с СУБТИТРАМИ". Странный акцент на субтитры, если язык знаешь.
Изучаешь какой-то объект - сразу крутишь его в редакторе. Просто так читать, конечно, бесполезно. Туториалы тоже бесполезно смотреть, если ты не повторяешь всё за ним или повторяешь бездумно.
С нейронкой попробуй... Только нужно чётко задачу сформулировать, типа "распиши по пунктам, как мне научиться делать игры такого-то жанра, что мне для этого необходимо изучить и освоить".
После обучения новому языку на достаточном уровне начинаешь непроизвольно мыслить на нём... Вообще, мышление от языка не зависит - речь о "внутреннем диалоге", который, внезапно, далеко не у всех людей.
>очевидно разработка игры начнет буксовать
При чём тут разработка, речь о "сделать быстро, не тратя время на просмотр видео с СУБТИТРАМИ". Странный акцент на субтитры, если язык знаешь.
>технические документы тяжело даются
>обычно учусь на своих ошибках
Изучаешь какой-то объект - сразу крутишь его в редакторе. Просто так читать, конечно, бесполезно. Туториалы тоже бесполезно смотреть, если ты не повторяешь всё за ним или повторяешь бездумно.
>типа как с наставником
С нейронкой попробуй... Только нужно чётко задачу сформулировать, типа "распиши по пунктам, как мне научиться делать игры такого-то жанра, что мне для этого необходимо изучить и освоить".
>Я мыслю на русском
После обучения новому языку на достаточном уровне начинаешь непроизвольно мыслить на нём... Вообще, мышление от языка не зависит - речь о "внутреннем диалоге", который, внезапно, далеко не у всех людей.
>>3803
Ну он игры вроде хотел делать, ты обвиняешь его в том что он тупой и в школе на тройки не учился, а я говорю чтобы просто включил онлайн перевод, и тогда будет прогресс.
Почему?
Это наверное самый не чётко сформулированный вопрос, на который ответит любой забулдыга. А так, хз че тебе не нравится обучение через туториалы, но через современную нейронку - ок.
Ну да
>При чём тут разработка
Ну он игры вроде хотел делать, ты обвиняешь его в том что он тупой и в школе на тройки не учился, а я говорю чтобы просто включил онлайн перевод, и тогда будет прогресс.
>Туториалы тоже бесполезно смотреть
Почему?
>С нейронкой попробуй... Только нужно чётко задачу сформулировать, типа "распиши по пунктам, как мне научиться делать игры такого-то жанра, что мне для этого необходимо изучить и освоить".
Это наверное самый не чётко сформулированный вопрос, на который ответит любой забулдыга. А так, хз че тебе не нравится обучение через туториалы, но через современную нейронку - ок.
>После обучения новому...
Ну да
>>3804
Потому что если ничего сам не делаешь, а только смотришь как кто-то делает - так и не научишься. Кроме того, в туториалах часто ошибки, которые невозможно поправить без перезалива видео, а авторам, как правило, насрать, пока их смотрят. Рискуешь вляпаться в порочный круг просмотра туториалов, которые никак не помогают, но зато накручивают просмотры на канале автора...
1. Объём знаний у нейронки шире, чем у типичного туториальщика. Ни нейронка, ни туториальщик игр не делали, но нейронка хотя бы переварила сотни книжек, пока туториальщик придумывал кликбейт получше, пережёвывая украденную у соседнего туториальщика популярную сейчас банальщину.
2. У нейронки ты можешь уточнить что-то, скинуть ей кучу кода и цитат из документации, она это всё проанализирует и даст хоть какой-то ответ, с чем ты можешь пойти гуглить или думать своей головой. На ютубе спросишь туториальщика, а он тебе вообще никак не ответит или ответит "понятия не имею".
3. У нейронки можешь запросить короткий ответ и получить сразу то, что хотел. В туториалах на ютубе придётся долго и мучительно мотать видео, чтобы пропустить лишнее и найти нужное, особенно если туториальщик неопытный и при этом болтливый.
Так что да, если выбирать из двух стульев, то запрос нейронке лучше тебя обучит чему-то, чем какой-томясной мешок, решивший подзаработать на ютубе.
>Почему?
Потому что если ничего сам не делаешь, а только смотришь как кто-то делает - так и не научишься. Кроме того, в туториалах часто ошибки, которые невозможно поправить без перезалива видео, а авторам, как правило, насрать, пока их смотрят. Рискуешь вляпаться в порочный круг просмотра туториалов, которые никак не помогают, но зато накручивают просмотры на канале автора...
>но через современную нейронку - ок.
1. Объём знаний у нейронки шире, чем у типичного туториальщика. Ни нейронка, ни туториальщик игр не делали, но нейронка хотя бы переварила сотни книжек, пока туториальщик придумывал кликбейт получше, пережёвывая украденную у соседнего туториальщика популярную сейчас банальщину.
2. У нейронки ты можешь уточнить что-то, скинуть ей кучу кода и цитат из документации, она это всё проанализирует и даст хоть какой-то ответ, с чем ты можешь пойти гуглить или думать своей головой. На ютубе спросишь туториальщика, а он тебе вообще никак не ответит или ответит "понятия не имею".
3. У нейронки можешь запросить короткий ответ и получить сразу то, что хотел. В туториалах на ютубе придётся долго и мучительно мотать видео, чтобы пропустить лишнее и найти нужное, особенно если туториальщик неопытный и при этом болтливый.
Так что да, если выбирать из двух стульев, то запрос нейронке лучше тебя обучит чему-то, чем какой-томясной мешок, решивший подзаработать на ютубе.
>>3815
А туториалы тут причем?
Не ну если тебе это действительно помогало, ничего против не имею, мне нейронка выдавала противоречащую но правдоподобную инфу, что никак не помогало, с таким же запросом проще зайти в гугл/двач, где люди хотя бы поймут что ты хочешь. Ну и на ютубе ты видишь что у человека всё работает, и если повторишь то будет работать у тебя, а там дальше со временем будешь отсебятину добавлять и думать почему один код не сочетается с другим
>Потому что если ничего сам не делаешь, а только смотришь как кто-то делает - так и не научишься
А туториалы тут причем?
>Тирада о прекрасных нейронках
Не ну если тебе это действительно помогало, ничего против не имею, мне нейронка выдавала противоречащую но правдоподобную инфу, что никак не помогало, с таким же запросом проще зайти в гугл/двач, где люди хотя бы поймут что ты хочешь. Ну и на ютубе ты видишь что у человека всё работает, и если повторишь то будет работать у тебя, а там дальше со временем будешь отсебятину добавлять и думать почему один код не сочетается с другим
>>3818
Тебе видео туториал записать нужно? >>3803
Думаю, многие тупо смотрят видосики на ютубе и считают, что они чему-то обучаются, а потом двух слов связать не могут и "это движок виноват".
А ещё есть такое понятие - "tutorial hell":
Так не спрашивай у неё то, что она знать не может по определению, а спрашивай то, с чем она может помочь как большая языковая модель. Например, разобраться в твоих очень запутанных мыслях.
Копаться целый день в совершенно не подходящих страницах, особенно там, где говорят "ты что, сам загуглить не мог?", или есть вопрос и сразу "ладно, разобрался сам" без решения, или ссылка сломана, иллюстрации отвалились и т.д. Потом ты случайно отвлекаешься на какие-то посторонние мемы...
К тому же, гуглить ты можешь по определению лишь коротко сформулированные запросы - не несколько абзацев пространных рассуждений о своей игре. С нейронкой ты можешь понять, что тебе гуглить.
Тут постоянно всплывают какие-то очень странные вопросы, которые толком не разберёшь, чего анон вообще хочет. Если спрашиваешь - "зачем тебе это нужно?", вместо контекста аноны огрызаются "рряя, нужно значит нужно, давай говори как сделоть". Как понимать и помогать, если вы даже объяснить свою проблему не можете? Вот с нейронкой тренируйтесь, пока нейронка не поймёт вопрос - на форум нельзя. Необходимо уметь правильно составлять вопросы.
- старая/кастомная версия движка;
- какие-то неназванные скрипты/аддоны;
- проблемы с ассетами (кодировка, форматы);
- разная конфигурация компьютера (да, Godot может испытывать проблемы на некоторых компьютерах; физический движок не гарантирует повторяемость);
- банально баг движка из-за которого ты даже всё повторяя шаг за шагом получаешь иной результат.
И в большинстве случаев туториалы сводятся либо к "как нарисовать сову", либо к "перепечатайте всё то, что я делаю, а объяснять зачем это всё я не буду".
Ладно если туториал о чём-то ВИЗУАЛЬНОМ, скажем, дизайн уровня. Но туториал про программированию? Полный бред. Читайте книги по программированию.
>А туториалы тут причем?
Тебе видео туториал записать нужно? >>3803
>Туториалы тоже бесполезно смотреть, если ты не повторяешь всё за ним или повторяешь бездумно.
Думаю, многие тупо смотрят видосики на ютубе и считают, что они чему-то обучаются, а потом двух слов связать не могут и "это движок виноват".
А ещё есть такое понятие - "tutorial hell":
>Tutorial hell in programming is a cycle where beginner programmers get stuck in a loop of constantly following tutorials to learn new skills, but struggle to apply that knowledge independently. It involves completing tutorials, realizing missing skills when trying to build something, then repeating the cycle. It's a challenging space to break out of without a clear understanding of what you don't know.
>нейронка выдавала противоречащую
Так не спрашивай у неё то, что она знать не может по определению, а спрашивай то, с чем она может помочь как большая языковая модель. Например, разобраться в твоих очень запутанных мыслях.
>проще зайти в гугл
Копаться целый день в совершенно не подходящих страницах, особенно там, где говорят "ты что, сам загуглить не мог?", или есть вопрос и сразу "ладно, разобрался сам" без решения, или ссылка сломана, иллюстрации отвалились и т.д. Потом ты случайно отвлекаешься на какие-то посторонние мемы...
К тому же, гуглить ты можешь по определению лишь коротко сформулированные запросы - не несколько абзацев пространных рассуждений о своей игре. С нейронкой ты можешь понять, что тебе гуглить.
>двач, где люди хотя бы поймут что ты хочешь
Тут постоянно всплывают какие-то очень странные вопросы, которые толком не разберёшь, чего анон вообще хочет. Если спрашиваешь - "зачем тебе это нужно?", вместо контекста аноны огрызаются "рряя, нужно значит нужно, давай говори как сделоть". Как понимать и помогать, если вы даже объяснить свою проблему не можете? Вот с нейронкой тренируйтесь, пока нейронка не поймёт вопрос - на форум нельзя. Необходимо уметь правильно составлять вопросы.
>видишь что у человека всё работает
- старая/кастомная версия движка;
- какие-то неназванные скрипты/аддоны;
- проблемы с ассетами (кодировка, форматы);
- разная конфигурация компьютера (да, Godot может испытывать проблемы на некоторых компьютерах; физический движок не гарантирует повторяемость);
- банально баг движка из-за которого ты даже всё повторяя шаг за шагом получаешь иной результат.
И в большинстве случаев туториалы сводятся либо к "как нарисовать сову", либо к "перепечатайте всё то, что я делаю, а объяснять зачем это всё я не буду".
Ладно если туториал о чём-то ВИЗУАЛЬНОМ, скажем, дизайн уровня. Но туториал про программированию? Полный бред. Читайте книги по программированию.
>>3818
Тебе видео туториал записать нужно? >>3803
Думаю, многие тупо смотрят видосики на ютубе и считают, что они чему-то обучаются, а потом двух слов связать не могут и "это движок виноват".
А ещё есть такое понятие - "tutorial hell":
Так не спрашивай у неё то, что она знать не может по определению, а спрашивай то, с чем она может помочь как большая языковая модель. Например, разобраться в твоих очень запутанных мыслях.
Копаться целый день в совершенно не подходящих страницах, особенно там, где говорят "ты что, сам загуглить не мог?", или есть вопрос и сразу "ладно, разобрался сам" без решения, или ссылка сломана, иллюстрации отвалились и т.д. Потом ты случайно отвлекаешься на какие-то посторонние мемы...
К тому же, гуглить ты можешь по определению лишь коротко сформулированные запросы - не несколько абзацев пространных рассуждений о своей игре. С нейронкой ты можешь понять, что тебе гуглить.
Тут постоянно всплывают какие-то очень странные вопросы, которые толком не разберёшь, чего анон вообще хочет. Если спрашиваешь - "зачем тебе это нужно?", вместо контекста аноны огрызаются "рряя, нужно значит нужно, давай говори как сделоть". Как понимать и помогать, если вы даже объяснить свою проблему не можете? Вот с нейронкой тренируйтесь, пока нейронка не поймёт вопрос - на форум нельзя. Необходимо уметь правильно составлять вопросы.
- старая/кастомная версия движка;
- какие-то неназванные скрипты/аддоны;
- проблемы с ассетами (кодировка, форматы);
- разная конфигурация компьютера (да, Godot может испытывать проблемы на некоторых компьютерах; физический движок не гарантирует повторяемость);
- банально баг движка из-за которого ты даже всё повторяя шаг за шагом получаешь иной результат.
И в большинстве случаев туториалы сводятся либо к "как нарисовать сову", либо к "перепечатайте всё то, что я делаю, а объяснять зачем это всё я не буду".
Ладно если туториал о чём-то ВИЗУАЛЬНОМ, скажем, дизайн уровня. Но туториал про программированию? Полный бред. Читайте книги по программированию.
>А туториалы тут причем?
Тебе видео туториал записать нужно? >>3803
>Туториалы тоже бесполезно смотреть, если ты не повторяешь всё за ним или повторяешь бездумно.
Думаю, многие тупо смотрят видосики на ютубе и считают, что они чему-то обучаются, а потом двух слов связать не могут и "это движок виноват".
А ещё есть такое понятие - "tutorial hell":
>Tutorial hell in programming is a cycle where beginner programmers get stuck in a loop of constantly following tutorials to learn new skills, but struggle to apply that knowledge independently. It involves completing tutorials, realizing missing skills when trying to build something, then repeating the cycle. It's a challenging space to break out of without a clear understanding of what you don't know.
>нейронка выдавала противоречащую
Так не спрашивай у неё то, что она знать не может по определению, а спрашивай то, с чем она может помочь как большая языковая модель. Например, разобраться в твоих очень запутанных мыслях.
>проще зайти в гугл
Копаться целый день в совершенно не подходящих страницах, особенно там, где говорят "ты что, сам загуглить не мог?", или есть вопрос и сразу "ладно, разобрался сам" без решения, или ссылка сломана, иллюстрации отвалились и т.д. Потом ты случайно отвлекаешься на какие-то посторонние мемы...
К тому же, гуглить ты можешь по определению лишь коротко сформулированные запросы - не несколько абзацев пространных рассуждений о своей игре. С нейронкой ты можешь понять, что тебе гуглить.
>двач, где люди хотя бы поймут что ты хочешь
Тут постоянно всплывают какие-то очень странные вопросы, которые толком не разберёшь, чего анон вообще хочет. Если спрашиваешь - "зачем тебе это нужно?", вместо контекста аноны огрызаются "рряя, нужно значит нужно, давай говори как сделоть". Как понимать и помогать, если вы даже объяснить свою проблему не можете? Вот с нейронкой тренируйтесь, пока нейронка не поймёт вопрос - на форум нельзя. Необходимо уметь правильно составлять вопросы.
>видишь что у человека всё работает
- старая/кастомная версия движка;
- какие-то неназванные скрипты/аддоны;
- проблемы с ассетами (кодировка, форматы);
- разная конфигурация компьютера (да, Godot может испытывать проблемы на некоторых компьютерах; физический движок не гарантирует повторяемость);
- банально баг движка из-за которого ты даже всё повторяя шаг за шагом получаешь иной результат.
И в большинстве случаев туториалы сводятся либо к "как нарисовать сову", либо к "перепечатайте всё то, что я делаю, а объяснять зачем это всё я не буду".
Ладно если туториал о чём-то ВИЗУАЛЬНОМ, скажем, дизайн уровня. Но туториал про программированию? Полный бред. Читайте книги по программированию.
>>3827
Ты уже определись, туториалы это плохо, или на них можно обучаться? Ты как нейронка потеряла связь буквально через пару постов.
А нахуя у неё что-то спрашивать, если тогда можно сразу открыть документацию и все по ней делать? А то ОКАЗЫВАЕТСЯ, нейронка может что-то не знать.
Если что-то не работает, и человек намерен учиться, он разберется и всё будет работать, даже если версии разные. Это и есть обучение
>Туториалы тоже бесполезно смотреть, если ты не повторяешь всё за ним или повторяешь бездумно
Ты уже определись, туториалы это плохо, или на них можно обучаться? Ты как нейронка потеряла связь буквально через пару постов.
>Так не спрашивай у неё
А нахуя у неё что-то спрашивать, если тогда можно сразу открыть документацию и все по ней делать? А то ОКАЗЫВАЕТСЯ, нейронка может что-то не знать.
>список
Если что-то не работает, и человек намерен учиться, он разберется и всё будет работать, даже если версии разные. Это и есть обучение
>>3832
А ты определись, тебе нужно пережёвывать инфу из документации и класть в рот с чайной ложечки или самостоятельно прочитать документацию можешь?
>туториалы это плохо, или на них можно обучаться?
>если тогда можно сразу открыть документацию и все по ней делать?
А ты определись, тебе нужно пережёвывать инфу из документации и класть в рот с чайной ложечки или самостоятельно прочитать документацию можешь?
>>3836
Я считаю, к каждому человеку нужен свой подход, и обучить можно всех и всему. Если не получается читать документации, значит пробуй по другому. Иначе знаешь такое чувство будто забуксовал? Где-то свернул не туда?
А ты мне про какие-то нейронки которые для порнухи только и годятся
Я считаю, к каждому человеку нужен свой подход, и обучить можно всех и всему. Если не получается читать документации, значит пробуй по другому. Иначе знаешь такое чувство будто забуксовал? Где-то свернул не туда?
А ты мне про какие-то нейронки которые для порнухи только и годятся
>>3837
Да, иди смотреть более 9001 туториалов...
Это потому что базу не изучал, только туториалы.
Не их вина, что ты только порнухой увлекаешься.
>значит пробуй по другому
Да, иди смотреть более 9001 туториалов...
>такое чувство будто забуксовал
Это потому что базу не изучал, только туториалы.
>нейронки которые для порнухи только и годятся
Не их вина, что ты только порнухой увлекаешься.
>>3838
Так не надо все подряд смотреть, только по надобности
Тот же официальный тутор от годот, где основы объясняются ну который сайт. Тебе просто индусы неправильные попадались вот и ругаешься
>иди смотреть более 9001 туториалов
Так не надо все подряд смотреть, только по надобности
>потому что базу не изучал
Тот же официальный тутор от годот, где основы объясняются ну который сайт. Тебе просто индусы неправильные попадались вот и ругаешься
121 Кб, 530x2675>>3848
Порекомендую кстати claude от antropic. По коду на гдскрипте лучшее что я видел, еще и свой контекст докидывать можно, заставлять артефакты запоминать. ГПТ тоже неплох. Лам новых не трогал, хз.
Порекомендую кстати claude от antropic. По коду на гдскрипте лучшее что я видел, еще и свой контекст докидывать можно, заставлять артефакты запоминать. ГПТ тоже неплох. Лам новых не трогал, хз.
>>3848
Как будет объяснять туториальщик:
Как будет объяснять туториальщик:
>Здравствуйте, здравствуйте, дорогие ребята и не ребята, то есть тянучки, хехе... Сегодня будем... Ээээ... Крхх-крхх... Чёт микрофон барахлит... Сегодня будем делать топ-даун... Даун, ха-ха-ха! Топ-даун... Ха... Шутер. Дааа... Шутер, значит. Что нужно шутеру? Ну, скажите мне! Ага... Мяу... А, это моя кошка, она недавно родила семеро котят... Такие милые... Вот, в общем, шутеру нужны котята. Ой. То есть меха. Хаха. Механики. Ну вы поняли, да? Гыы... В общем, сегодня мы будем делать главную механику: меню паузы. Потому что я вот ненавижу когда в шутерах нет меню паузы. Ну в смысле вот я играл в соревновательный шутер, а там, прикиньте, паузы нет. Ну то есть, да... Но для всего лобби. А мы будем делать сингл плеер. В смысле, не плеер... А игру, да. Ну это слово английское такое, "плеер"... Не помню, как оно переводится. Крхххх... Ой, это у меня соседи ремонт делают, вот ведь козлы. Ррхххх... Крркр... Кккэххх... Ппщшшш... И вот так у нас получается меню... Тут три кнопки: выход, настройки и назад... В бой, то есть... Вы наверное спросите, а как делать меню настроек? А хрен его знает, я никогда не делал. Будем с вами вместе делать на стриме в воскресенье вечером. Всё, всем чмоки, подписывайтесь, ставьте лайки, посмотрите это видео несколько раз - алгоритмы это любят. В следующей серии будем делать платформер, потому что мне надоели шутеры... Пока.
>>3851
Как правильно выше заметили, у тебя просто туториальщика хорошего не было.
Как правильно выше заметили, у тебя просто туториальщика хорошего не было.
Господа, пробовал ли кто вести более открытую разработку? Заливать билды на итч, делать инкрементальные апдейты и вести девблоги, собирать багрепорты и фидбеки? Выхлоп с этой суеты есть?
>>3851
Это бич всех русских туториальщиков по любому игровому движку. Объясняют какую-то хуйню вплоть до интерфейса, хотя у самих уже есть 15 видео с названиями "ГАЙД ДЛЯ НОВЧИКА В ГОВДОТЕ", "КУРС ДЛЯ САМЫХ МАЛЕНЬКИХ", "ОСНОВЫ ДВИЖКА"
Это бич всех русских туториальщиков по любому игровому движку. Объясняют какую-то хуйню вплоть до интерфейса, хотя у самих уже есть 15 видео с названиями "ГАЙД ДЛЯ НОВЧИКА В ГОВДОТЕ", "КУРС ДЛЯ САМЫХ МАЛЕНЬКИХ", "ОСНОВЫ ДВИЖКА"
>>3866
Звучит как говно какое-то, лично я хуярю от души. Ты ещё предложи гит завести хрррртьпфу
Звучит как говно какое-то, лично я хуярю от души. Ты ещё предложи гит завести хрррртьпфу
>>3866
Я пробую, выхлопа пока особо нет, один челик на бусти подписался, 96 на итч, и появился преданный подпещек, который качает каждый апдейт и дает фидбек.
Я пробую, выхлопа пока особо нет, один челик на бусти подписался, 96 на итч, и появился преданный подпещек, который качает каждый апдейт и дает фидбек.
>>3876
Для интенсивно-физической игры не используешь jolt.
Для интенсивно-физической игры не используешь jolt.
>>3875
Я бы ради этого чувака продолжил бы разработку. Он же тот самый второстепенный персонаж - друг, который приходит на выручку ГГ в самый тяжёлый момент.
>появился преданный подпещек, который качает каждый апдейт и дает фидбек.
Я бы ради этого чувака продолжил бы разработку. Он же тот самый второстепенный персонаж - друг, который приходит на выручку ГГ в самый тяжёлый момент.
>>3895
Разработка ПО для машин в казино:
https://hh.ru/vacancy/105459040
Разработка GUI для электромобиля:
https://hh.ru/vacancy/106244218
Базированные вакансии для Godot.
Разработка ПО для машин в казино:
https://hh.ru/vacancy/105459040
Разработка GUI для электромобиля:
https://hh.ru/vacancy/106244218
Базированные вакансии для Godot.
>>3866
Буквально мечтаю о таком, но я безыгорный же. Как мне заливать билды, если у меня игорьтонет?
>>3872
Согласен. Архивы для чего придумали? Архивируйте.
>>3874
Зачем на рабочем столе? Надо красиво:
Архивы примерно такие:
Чтобы сортировка по имени была удобной.
Кидаешь архивы на разные накопители.
>>3875
Как же я тебе завидую... Дело полезное делаешь...
>>3893
Но не стоит себя насиловать, если проект оказался неудачным, даже если у него есть фанаты. Лучше оставить проект фанатам, открыв все исходники в опенсурс - кому действительно нужно, подхватят разработку и продолжат делать опенсурс. Многие поступили так, а кто не поступил - копираст-жмот.
>Заливать билды на итч, делать инкрементальные апдейты и вести девблоги, собирать багрепорты и фидбеки?
Буквально мечтаю о таком, но я безыгорный же. Как мне заливать билды, если у меня игорьтонет?
>>3872
>Ты ещё предложи гит завести хрррртьпфу
Согласен. Архивы для чего придумали? Архивируйте.
>>3874
>10 папок на рабочем столе
Зачем на рабочем столе? Надо красиво:
>Users > UserName > Documents > MyGames > Genre > ProjectName > ProjectName.v0.6.9 > game > game.tscn
Архивы примерно такие:
>ProjectName-YYYY.MM.DD-HHmm-v0.6.9-(type).zip
Чтобы сортировка по имени была удобной.
Кидаешь архивы на разные накопители.
>>3875
>появился преданный подпещек, который качает каждый апдейт и дает фидбек.
Как же я тебе завидую... Дело полезное делаешь...
>>3893
>ради этого чувака продолжил бы разработку
Но не стоит себя насиловать, если проект оказался неудачным, даже если у него есть фанаты. Лучше оставить проект фанатам, открыв все исходники в опенсурс - кому действительно нужно, подхватят разработку и продолжат делать опенсурс. Многие поступили так, а кто не поступил - копираст-жмот.
Как же хочется быть разработчиком. Делаешь игру, тебе донатят на итче или патреоне, занимаешься творчеством + делаешь игру. Душа.
>>3876
1. Попробуй разделить пол на несколько частей. У GodotPhysics тряска, если твой пол имеет площадь больше пары сотен метров в длину. Это связано с погрешностью у вещественных чисел в формулах.
2. Если можешь, увеличивай размер объектов. Со слишком мелкими объектами физические движки плохо работают опять же из-за погрешностей в вещественных числах. Кроме того, игроку будет намного проще целиться/подбирать/попадать.
3. Попробуй включить это, может помочь с мелкими объектами, если должны много двигаться по сцене:
https://docs.godotengine.org/en/stable/classes/class_rigidbody3d.html#class-rigidbody3d-property-continuous-cd
4. Если тебе не нужно пинать кирпичи ногами, то упавшие неподвижные имеет смысл заморозить:
https://docs.godotengine.org/en/stable/classes/class_rigidbody3d.html#class-rigidbody3d-property-freeze
Хотя по-хорошему за это sleeping отвечать должен, однако такая тряска почему-то не даёт им уснуть.
5. Также можно увеличить angular_damp/linear_damp: значения по умолчанию слишком мелкие и объекты стремятся слишком долго вращаться/катиться. Эти значения, по-хорошему, должны зависеть от формы объекта, т.к. симулируют сопротивление воздуха.
6. Попробуй поднять массу и добавить трение. Если объекты слишком лёгкие, они больше подвержены колебаниям. Трение должно тормозить объект на поверхности другого объекта (но не полностью).
Альтернативные физические движки:
https://github.com/godot-jolt/godot-jolt
https://github.com/appsinacup/godot-rapier-physics
Идеальных решений нет, везде свои нюансы.
1. Попробуй разделить пол на несколько частей. У GodotPhysics тряска, если твой пол имеет площадь больше пары сотен метров в длину. Это связано с погрешностью у вещественных чисел в формулах.
2. Если можешь, увеличивай размер объектов. Со слишком мелкими объектами физические движки плохо работают опять же из-за погрешностей в вещественных числах. Кроме того, игроку будет намного проще целиться/подбирать/попадать.
3. Попробуй включить это, может помочь с мелкими объектами, если должны много двигаться по сцене:
https://docs.godotengine.org/en/stable/classes/class_rigidbody3d.html#class-rigidbody3d-property-continuous-cd
4. Если тебе не нужно пинать кирпичи ногами, то упавшие неподвижные имеет смысл заморозить:
https://docs.godotengine.org/en/stable/classes/class_rigidbody3d.html#class-rigidbody3d-property-freeze
Хотя по-хорошему за это sleeping отвечать должен, однако такая тряска почему-то не даёт им уснуть.
5. Также можно увеличить angular_damp/linear_damp: значения по умолчанию слишком мелкие и объекты стремятся слишком долго вращаться/катиться. Эти значения, по-хорошему, должны зависеть от формы объекта, т.к. симулируют сопротивление воздуха.
6. Попробуй поднять массу и добавить трение. Если объекты слишком лёгкие, они больше подвержены колебаниям. Трение должно тормозить объект на поверхности другого объекта (но не полностью).
Альтернативные физические движки:
https://github.com/godot-jolt/godot-jolt
https://github.com/appsinacup/godot-rapier-physics
Идеальных решений нет, везде свои нюансы.
40 Кб, 1024x731>>3893
Литералли
Литералли
145 Кб, 460x460Там Годоньер новый видос запилил!
Бросайте делать игоры и го Годоньера смотреть!
https://www.youtube.com/watch?v=cZ5Ang_Ji8E
Бросайте делать игоры и го Годоньера смотреть!
https://www.youtube.com/watch?v=cZ5Ang_Ji8E
Пилил один проектик как хобби, щяс понимаю что даже если что то нормальное и выйдет, то скорее всего нахуй никому не нужно.
Появилось идея совершенно в другой области adult наклепать игру, интереса всяко по итогу должно быть больше.
И вот думаю, есть ли смысл все таки допилить первый проект до хотя бы рабочего билда или просто заморозить навсегда до лучших времён и начать новый?
Появилось идея совершенно в другой области adult наклепать игру, интереса всяко по итогу должно быть больше.
И вот думаю, есть ли смысл все таки допилить первый проект до хотя бы рабочего билда или просто заморозить навсегда до лучших времён и начать новый?
>>3924
Да, всегда да. Ценный опыт, пригодится тебе в будущем, приучит доводить проекты до конца, и куча других профитов.
>есть ли смысл все таки допилить первый проект до хотя бы рабочего билда
Да, всегда да. Ценный опыт, пригодится тебе в будущем, приучит доводить проекты до конца, и куча других профитов.
На что вы живете? Никто же тут не делает игры по-настоящему. Не все же на пенсии по шизе живут? Или все?
>>3935
Мы тут все синьоры-помидоры с 50кк в запасе и пассивными доходами со своих стартапов, можем себе позволить.
Оффтоп, пчел. Игры делай и не задавай вопросов.
Мы тут все синьоры-помидоры с 50кк в запасе и пассивными доходами со своих стартапов, можем себе позволить.
Оффтоп, пчел. Игры делай и не задавай вопросов.
>>3927
Херня это всё. Лучше сбросить балласт, чем тянуть
>>3924
Что ты понимаешь под "хотя бы рабочим билдом"? Что тебе для него нужно?
Для базовой игры нужен только какой-то игровой процесс. Желательно, чтобы он представлял из себя цикл (core loop), и этот цикл было интересно повторять снова и снова. Какие-то там менюшки, гуйюшки, картинки, модельки, свистелки, перделки - это всё не обязательно, пока имеется игровой цикл с которым игрок может играть. Ты и сам наверняка много часов уже наиграл в свою игру даже без "билда", просто запуская из редактора для теста, верно? Ну вот упакуй эту играбельную часть, выложи на итч как "прототип", и... ну, не знаю, расскажи знакомым, или запости ссылку куда-то. Чтоб поиграли и сказали, как оно вообще, нужно ли им такое, нужно ли тебе продолжать. Будет обратная связь и сможешь определиться, нужна тебе эта игра или лучше бросить.
Советую подождать пока. Несколько дней, а то и недели две. У всех геймдевов часто такие мимолётные идеи возникают, типа "было бы круто сделать такую-то игру", особенно если ты недавно во что-то поиграл, что-то где-то увидел. Но такие идеи быстро оказываются либо скучными, либо вообще неосуществимыми, и ты теряешь интерес. Особенно это касается порнушных игр - пока не подрочишь, кажется чем-то очень крутым, а как подрочишь, то как-то уже и не нужно оно тебе. Или нарисуешь картинку и подрочишь. В любом случае, легко потерять мотивацию, когда ты только придумал идею и ещё ничего не имеешь кроме неё. Поэтому стоит подождать и посмотреть на свои ощущения - действительно ли хочется, или ну её, эту идею? Конечно, это в первую очередь касается хобби, но даже если ты хочешь делать игру ради прибыли, то тебе как соло инди нужно быть увлечённым проектом, иначе накатит депрессия с апатией из-за отсутствия прибыли в первые несколько лет работы. Вот если эта идея будет тебя упорно посещать на протяжении многих недель/месяцев, тогда можешь начинать её осуществлять.
>приучит доводить проекты до конца
Херня это всё. Лучше сбросить балласт, чем тянуть
>ПАТАМУШТА ПОПЫТ, ПАТАМУШТА ПРЕУЧИЛЬСЯ!!!
>>3924
>допилить первый проект до хотя бы рабочего билда
Что ты понимаешь под "хотя бы рабочим билдом"? Что тебе для него нужно?
Для базовой игры нужен только какой-то игровой процесс. Желательно, чтобы он представлял из себя цикл (core loop), и этот цикл было интересно повторять снова и снова. Какие-то там менюшки, гуйюшки, картинки, модельки, свистелки, перделки - это всё не обязательно, пока имеется игровой цикл с которым игрок может играть. Ты и сам наверняка много часов уже наиграл в свою игру даже без "билда", просто запуская из редактора для теста, верно? Ну вот упакуй эту играбельную часть, выложи на итч как "прототип", и... ну, не знаю, расскажи знакомым, или запости ссылку куда-то. Чтоб поиграли и сказали, как оно вообще, нужно ли им такое, нужно ли тебе продолжать. Будет обратная связь и сможешь определиться, нужна тебе эта игра или лучше бросить.
>Появилось идея совершенно в другой области adult наклепать игру
Советую подождать пока. Несколько дней, а то и недели две. У всех геймдевов часто такие мимолётные идеи возникают, типа "было бы круто сделать такую-то игру", особенно если ты недавно во что-то поиграл, что-то где-то увидел. Но такие идеи быстро оказываются либо скучными, либо вообще неосуществимыми, и ты теряешь интерес. Особенно это касается порнушных игр - пока не подрочишь, кажется чем-то очень крутым, а как подрочишь, то как-то уже и не нужно оно тебе. Или нарисуешь картинку и подрочишь. В любом случае, легко потерять мотивацию, когда ты только придумал идею и ещё ничего не имеешь кроме неё. Поэтому стоит подождать и посмотреть на свои ощущения - действительно ли хочется, или ну её, эту идею? Конечно, это в первую очередь касается хобби, но даже если ты хочешь делать игру ради прибыли, то тебе как соло инди нужно быть увлечённым проектом, иначе накатит депрессия с апатией из-за отсутствия прибыли в первые несколько лет работы. Вот если эта идея будет тебя упорно посещать на протяжении многих недель/месяцев, тогда можешь начинать её осуществлять.
>>3927
Херня это всё. Лучше сбросить балласт, чем тянуть
>>3924
Что ты понимаешь под "хотя бы рабочим билдом"? Что тебе для него нужно?
Для базовой игры нужен только какой-то игровой процесс. Желательно, чтобы он представлял из себя цикл (core loop), и этот цикл было интересно повторять снова и снова. Какие-то там менюшки, гуйюшки, картинки, модельки, свистелки, перделки - это всё не обязательно, пока имеется игровой цикл с которым игрок может играть. Ты и сам наверняка много часов уже наиграл в свою игру даже без "билда", просто запуская из редактора для теста, верно? Ну вот упакуй эту играбельную часть, выложи на итч как "прототип", и... ну, не знаю, расскажи знакомым, или запости ссылку куда-то. Чтоб поиграли и сказали, как оно вообще, нужно ли им такое, нужно ли тебе продолжать. Будет обратная связь и сможешь определиться, нужна тебе эта игра или лучше бросить.
Советую подождать пока. Несколько дней, а то и недели две. У всех геймдевов часто такие мимолётные идеи возникают, типа "было бы круто сделать такую-то игру", особенно если ты недавно во что-то поиграл, что-то где-то увидел. Но такие идеи быстро оказываются либо скучными, либо вообще неосуществимыми, и ты теряешь интерес. Особенно это касается порнушных игр - пока не подрочишь, кажется чем-то очень крутым, а как подрочишь, то как-то уже и не нужно оно тебе. Или нарисуешь картинку и подрочишь. В любом случае, легко потерять мотивацию, когда ты только придумал идею и ещё ничего не имеешь кроме неё. Поэтому стоит подождать и посмотреть на свои ощущения - действительно ли хочется, или ну её, эту идею? Конечно, это в первую очередь касается хобби, но даже если ты хочешь делать игру ради прибыли, то тебе как соло инди нужно быть увлечённым проектом, иначе накатит депрессия с апатией из-за отсутствия прибыли в первые несколько лет работы. Вот если эта идея будет тебя упорно посещать на протяжении многих недель/месяцев, тогда можешь начинать её осуществлять.
>приучит доводить проекты до конца
Херня это всё. Лучше сбросить балласт, чем тянуть
>ПАТАМУШТА ПОПЫТ, ПАТАМУШТА ПРЕУЧИЛЬСЯ!!!
>>3924
>допилить первый проект до хотя бы рабочего билда
Что ты понимаешь под "хотя бы рабочим билдом"? Что тебе для него нужно?
Для базовой игры нужен только какой-то игровой процесс. Желательно, чтобы он представлял из себя цикл (core loop), и этот цикл было интересно повторять снова и снова. Какие-то там менюшки, гуйюшки, картинки, модельки, свистелки, перделки - это всё не обязательно, пока имеется игровой цикл с которым игрок может играть. Ты и сам наверняка много часов уже наиграл в свою игру даже без "билда", просто запуская из редактора для теста, верно? Ну вот упакуй эту играбельную часть, выложи на итч как "прототип", и... ну, не знаю, расскажи знакомым, или запости ссылку куда-то. Чтоб поиграли и сказали, как оно вообще, нужно ли им такое, нужно ли тебе продолжать. Будет обратная связь и сможешь определиться, нужна тебе эта игра или лучше бросить.
>Появилось идея совершенно в другой области adult наклепать игру
Советую подождать пока. Несколько дней, а то и недели две. У всех геймдевов часто такие мимолётные идеи возникают, типа "было бы круто сделать такую-то игру", особенно если ты недавно во что-то поиграл, что-то где-то увидел. Но такие идеи быстро оказываются либо скучными, либо вообще неосуществимыми, и ты теряешь интерес. Особенно это касается порнушных игр - пока не подрочишь, кажется чем-то очень крутым, а как подрочишь, то как-то уже и не нужно оно тебе. Или нарисуешь картинку и подрочишь. В любом случае, легко потерять мотивацию, когда ты только придумал идею и ещё ничего не имеешь кроме неё. Поэтому стоит подождать и посмотреть на свои ощущения - действительно ли хочется, или ну её, эту идею? Конечно, это в первую очередь касается хобби, но даже если ты хочешь делать игру ради прибыли, то тебе как соло инди нужно быть увлечённым проектом, иначе накатит депрессия с апатией из-за отсутствия прибыли в первые несколько лет работы. Вот если эта идея будет тебя упорно посещать на протяжении многих недель/месяцев, тогда можешь начинать её осуществлять.
>>3937
Да твое-то весомое мнение мы уже заранее знаем, господин олимпиадник-занудник. Чего там, архитектуру кнопок нащупал верную? Через сколько лет ожидать как ты, аки гром и молния, поразишь весь мир своим чудо-проектом?
Да твое-то весомое мнение мы уже заранее знаем, господин олимпиадник-занудник. Чего там, архитектуру кнопок нащупал верную? Через сколько лет ожидать как ты, аки гром и молния, поразишь весь мир своим чудо-проектом?
>>3939
Предпочитаю классическую архитектуру обработчиков событий. Так функционал легко масштабируется до мультиплатформинга. А что?
> архитектуру кнопок нащупал верную
Предпочитаю классическую архитектуру обработчиков событий. Так функционал легко масштабируется до мультиплатформинга. А что?
142 Кб, 1280x1108
960 Кб, 1080x1485>>3938
Он думал, что со мной говорит, поэтому я ему и не отвечаю. Дождался, пока ты ответил, и теперь он думает, что ты это я.
Он думал, что со мной говорит, поэтому я ему и не отвечаю. Дождался, пока ты ответил, и теперь он думает, что ты это я.
82 Кб, 900x900>>3941
И с поддержкой мультиплеера.
И с поддержкой мультиплеера.
>>3927
>>3937
Спасибо за ответы. Я внезапно пришел к промежуточному варианту. Я придумал как в свой первый проект где уже есть мало-мальски рабочие механики прикрутить порно состовляющую. Допиливать по коду там по минимуму, сейчас все упирается только в графику.
Уже скачал криту, графический планшет уже пару недель как куплен. В общем буду вкатываться в рисование. а скорее обрисовку чужих артов
>>3937
Спасибо за ответы. Я внезапно пришел к промежуточному варианту. Я придумал как в свой первый проект где уже есть мало-мальски рабочие механики прикрутить порно состовляющую. Допиливать по коду там по минимуму, сейчас все упирается только в графику.
Уже скачал криту, графический планшет уже пару недель как куплен. В общем буду вкатываться в рисование. а скорее обрисовку чужих артов
Парни, дайте норм гайд на Basis. Я вроде читаю документацию, все слова знакомые, но что-то вообще нихуя не укладывается в голове, как баран на новые ворота смотрю. Какие-то колонки, x, y, z, вектор3 на каждый, ваще не понимаю нихуя.
>>3953
Более четырёх лет ковыряюсь в Godot 3D, но так и не разобрался, что это за базис и зачем он нужен, когда можно накрутить какой-то херни на нодах и rotate() и оно just works. Хотя иногда я всё-таки беру Z из Basis, чтобы определить, куда объект смотрит, чтобы использовать этот вектор в формуле приложения силы к RigidBody...
В общем, пока оно тебе не сильно надо - не парься...
А вообще, это из математики:
https://ru.wikipedia.org/wiki/Базис
https://en.wikipedia.org/wiki/Basis_(linear_algebra)
В Godot просто удобная обёртка над этой концепцией.
Лови мемы в тему.
>Basis
Более четырёх лет ковыряюсь в Godot 3D, но так и не разобрался, что это за базис и зачем он нужен, когда можно накрутить какой-то херни на нодах и rotate() и оно just works. Хотя иногда я всё-таки беру Z из Basis, чтобы определить, куда объект смотрит, чтобы использовать этот вектор в формуле приложения силы к RigidBody...
В общем, пока оно тебе не сильно надо - не парься...
А вообще, это из математики:
https://ru.wikipedia.org/wiki/Базис
https://en.wikipedia.org/wiki/Basis_(linear_algebra)
В Godot просто удобная обёртка над этой концепцией.
Лови мемы в тему.
>>3955
Понял, спасибо.
Понял, спасибо.
Зачем участвовать в джемах ради отработки идеи игры, если можно пройтись по успешным джемовым играм, своровать идею у них, минимально изменить, налепить свой арт и продать?
>>3982
просто так, чтобы отточить какую то идею, поставить себе дедлайны, набить какое никакое партфолио.
Зависит еще от позиции которую в разработке ты занимаешь.
просто так, чтобы отточить какую то идею, поставить себе дедлайны, набить какое никакое партфолио.
Зависит еще от позиции которую в разработке ты занимаешь.
>>3984
Хорошо.
Хорошо.
>>3995
200 рублей. Оплатил за 3 месяца на 600
200 рублей. Оплатил за 3 месяца на 600
>>3982
У меня вообще не встаёт хуй на чужие идеи. Хочется реализовать именно своё.
> своровать идею у них
У меня вообще не встаёт хуй на чужие идеи. Хочется реализовать именно своё.
>>4005
Не сравнивай чужие идеи со своими. Чужие - это одна из тысячи, которая выстрелила. А свои чтобы привести в порядок - надо очень серьезно поработать. Умение удачно спиздить чужую идею и вложить в нее свою душу это и есть то как человечество эволюционировало до этой точки.
Чужих идей вообще не бывает. Все принадлежит общему пулу идей. Колосально много ресурсов было потрачено на фуфловые идеи. И многие хорошие идеи затерялись потому что задохнулись от недостачи внимания и ресурсов.
Не сравнивай чужие идеи со своими. Чужие - это одна из тысячи, которая выстрелила. А свои чтобы привести в порядок - надо очень серьезно поработать. Умение удачно спиздить чужую идею и вложить в нее свою душу это и есть то как человечество эволюционировало до этой точки.
Чужих идей вообще не бывает. Все принадлежит общему пулу идей. Колосально много ресурсов было потрачено на фуфловые идеи. И многие хорошие идеи затерялись потому что задохнулись от недостачи внимания и ресурсов.
>>4008
База
База
>>4008
Я думаю, он имеет в виду, что не хочет воровать идею игры про фурри, глотающего живьём других фурри, или что-то подобное, чего много на итчио. А те идеи, которые он хочет реализовать, ещё никто не делал (или трудно найти сделанное).
Игры - не технологии, а использование технологий для развлечения. Никакой эволюции большинство игр не двигают и двигать не будут. Это как жвачка, которую миллионы жуют только чтобы жевать.
И вот предпочтения в развлекательном контенте (условно, вкусы жвачки) у всех людей разные.
Я думаю, он имеет в виду, что не хочет воровать идею игры про фурри, глотающего живьём других фурри, или что-то подобное, чего много на итчио. А те идеи, которые он хочет реализовать, ещё никто не делал (или трудно найти сделанное).
>человечество эволюционировало
Игры - не технологии, а использование технологий для развлечения. Никакой эволюции большинство игр не двигают и двигать не будут. Это как жвачка, которую миллионы жуют только чтобы жевать.
И вот предпочтения в развлекательном контенте (условно, вкусы жвачки) у всех людей разные.
>>3982
Для развлечения. Это что-то вроде киберспорта.
Кто тебе это сказал? На джемах обычно тебе дают конкретную идею (тему), и ты что-то с этой идеей должен сделать, чтобы получилось интересно.
Как ты поймёшь, что игра на джеме успешна лишь благодаря идее, а не благодаря исполнению или вообще благодаря фанбазе конкретного автора? Глобально это может быть провальная идея.
Если идея действительно успешна и ты её изменишь, возможно, ты испортишь её успешность, если ты не понимаешь, почему она вообще оказалась успешна.
Арт нужно сначала как-то сделать. От качества арта зависит, будет ли кто-то на твою идею обращать внимание или нет - идея ничего не стоит без качественного исполнения - у всех есть идеи. Т.е. создание качественного арта дороже идеи, и ты, возможно, не потянешь создание арта для игры даже с костылями вроде нейросетей.
А тут нужен бюджет на маркетинг, впаривание игры игрокам по всем социальным каналам несколько месяцев подряд, нагнетание хайпа или создание вокруг игры крепкой фанбазы. Ты не сможешь повторить успех флаппи берд, потому что успех заключался не в "идее" игры (идея-то говно, как и исполнение), а в удачном стечении обстоятельств. Большинство игроков даже бесплатно в твою игру играть не будут, не то, что покупать её, и нужно вкладывать деньги, чтоб заставить их играть.
>Зачем участвовать в джемах
Для развлечения. Это что-то вроде киберспорта.
>ради отработки идеи игры
Кто тебе это сказал? На джемах обычно тебе дают конкретную идею (тему), и ты что-то с этой идеей должен сделать, чтобы получилось интересно.
>пройтись по успешным джемовым играм
Как ты поймёшь, что игра на джеме успешна лишь благодаря идее, а не благодаря исполнению или вообще благодаря фанбазе конкретного автора? Глобально это может быть провальная идея.
>своровать идею у них, минимально изменить
Если идея действительно успешна и ты её изменишь, возможно, ты испортишь её успешность, если ты не понимаешь, почему она вообще оказалась успешна.
>налепить свой арт
Арт нужно сначала как-то сделать. От качества арта зависит, будет ли кто-то на твою идею обращать внимание или нет - идея ничего не стоит без качественного исполнения - у всех есть идеи. Т.е. создание качественного арта дороже идеи, и ты, возможно, не потянешь создание арта для игры даже с костылями вроде нейросетей.
>и продать?
А тут нужен бюджет на маркетинг, впаривание игры игрокам по всем социальным каналам несколько месяцев подряд, нагнетание хайпа или создание вокруг игры крепкой фанбазы. Ты не сможешь повторить успех флаппи берд, потому что успех заключался не в "идее" игры (идея-то говно, как и исполнение), а в удачном стечении обстоятельств. Большинство игроков даже бесплатно в твою игру играть не будут, не то, что покупать её, и нужно вкладывать деньги, чтоб заставить их играть.
>>3982
Забыл ещё упомянуть монетизацию. У игр с итч.ио, особенно джемных, обычно крайне малый объём контента. Вся игра порой приходится за пару минут, потому что больше за два дня джема не сделать. Возникает вопрос масштабируемости: будет ли эта игра интересна, если у неё контента на два часа? А меньше двух часов ты продать в стиме не можешь, потому что по правилам игрок может вернуть игру, если не наиграл два часа. Плюс игроки ожидают от каждой игры по сотне часов минимум. И очень ненавидят, когда время растягивают гриндом...
Если рассматривать другие способы монетизации, например, показ рекламы - там от игры требуется завлекать игрока каждый день на пару минут. Т.е. по-прежнему нужно контента на сотни часов, но механики должны заставлять возвращаться раз в день на несколько минут и не раздражать. Это совершенно другой подход к играм по сравнению с джемовыми поделками, от которых требуется выложить на стол всё сразу за одну сессию.
И потом, самые большие деньги крутятся в онлайн многопользовательских играх, а на джемах ты не найдёшь полноценных многопользовательских игр, потому что делать их технически сложно, а ещё сложнее заставить игроков играть вместе. Т.е. доступны только одноразовые игры на 5 минут.
Короче, геймджемы - это киберспортивная игра. Собираются киберкотлеты и меряются, кто из них сможет собрать лучшую игру за наименьшее время.
>и продать?
Забыл ещё упомянуть монетизацию. У игр с итч.ио, особенно джемных, обычно крайне малый объём контента. Вся игра порой приходится за пару минут, потому что больше за два дня джема не сделать. Возникает вопрос масштабируемости: будет ли эта игра интересна, если у неё контента на два часа? А меньше двух часов ты продать в стиме не можешь, потому что по правилам игрок может вернуть игру, если не наиграл два часа. Плюс игроки ожидают от каждой игры по сотне часов минимум. И очень ненавидят, когда время растягивают гриндом...
Если рассматривать другие способы монетизации, например, показ рекламы - там от игры требуется завлекать игрока каждый день на пару минут. Т.е. по-прежнему нужно контента на сотни часов, но механики должны заставлять возвращаться раз в день на несколько минут и не раздражать. Это совершенно другой подход к играм по сравнению с джемовыми поделками, от которых требуется выложить на стол всё сразу за одну сессию.
И потом, самые большие деньги крутятся в онлайн многопользовательских играх, а на джемах ты не найдёшь полноценных многопользовательских игр, потому что делать их технически сложно, а ещё сложнее заставить игроков играть вместе. Т.е. доступны только одноразовые игры на 5 минут.
Короче, геймджемы - это киберспортивная игра. Собираются киберкотлеты и меряются, кто из них сможет собрать лучшую игру за наименьшее время.
>>4015
Дальше первой строчки тебя не читал, графоман. Еще раз, украсть идею, а не игру. Кор идея часто развивается на 3-4 полноценных игры, чем ААА студии и занимаются. Кроме того, твои аргументы "РАСТЯГИВАТЬ ПЛОХО" разбиваются успешными джем-играми, допиленными до стимовских версий.
Тебе лишь бы ничего не делать и графоманить. Страшно представить твой код.
Дальше первой строчки тебя не читал, графоман. Еще раз, украсть идею, а не игру. Кор идея часто развивается на 3-4 полноценных игры, чем ААА студии и занимаются. Кроме того, твои аргументы "РАСТЯГИВАТЬ ПЛОХО" разбиваются успешными джем-играми, допиленными до стимовских версий.
Тебе лишь бы ничего не делать и графоманить. Страшно представить твой код.
>>4020
Приведи конкретные примеры "идей". Лучше из популярных игр - разберёмся, в чём их популярность.
Штамповкой они занимаются. А говноеды жрут.
Нет, не плохо, но не всё можно растянуть и при этом сохранить все ощущения, делающие короткую игру успешной. Есть такие понятия: короткометражка, рассказ и т.д. Если начать растягивать в сериал или многотомный роман, это будет что-то не то.
Таких единицы. Ну, иди допиливай, чего ждёшь?
Дыа. А ты сюда со своей гениальной идеей воровать гениальные идеи и ничего не делать зачем пришёл? Воруй гениальные идеи молча и ничего не делай.
Стараюсь писать меньше кода. Если разрастается в неуправляемую лапшу - бросаю и пишу с нуля.
>Еще раз, украсть идею, а не игру.
Приведи конкретные примеры "идей". Лучше из популярных игр - разберёмся, в чём их популярность.
>чем ААА студии и занимаются.
Штамповкой они занимаются. А говноеды жрут.
>РАСТЯГИВАТЬ ПЛОХО
Нет, не плохо, но не всё можно растянуть и при этом сохранить все ощущения, делающие короткую игру успешной. Есть такие понятия: короткометражка, рассказ и т.д. Если начать растягивать в сериал или многотомный роман, это будет что-то не то.
>успешными джем-играми, допиленными до
Таких единицы. Ну, иди допиливай, чего ждёшь?
>Тебе лишь бы ничего не делать и графоманить.
Дыа. А ты сюда со своей гениальной идеей воровать гениальные идеи и ничего не делать зачем пришёл? Воруй гениальные идеи молча и ничего не делай.
>Страшно представить твой код.
Стараюсь писать меньше кода. Если разрастается в неуправляемую лапшу - бросаю и пишу с нуля.
>>4012
Книги, аудио и видео развлечения тоже жвачка. И тоже могут оказать сильное воздействие на развитие личности, расширить кругозор, и дать пощупать то что невозможно облачить в простые слова.
Возможно в будущем намного проще будет спрвится с технической частью, и приманит в игрострой намного больше гениев с уникальным мышлением.
>Это как жвачка
Книги, аудио и видео развлечения тоже жвачка. И тоже могут оказать сильное воздействие на развитие личности, расширить кругозор, и дать пощупать то что невозможно облачить в простые слова.
Возможно в будущем намного проще будет спрвится с технической частью, и приманит в игрострой намного больше гениев с уникальным мышлением.
>>4040
Есть разница между технической, научно-популярной литературой и тупой графоманией про очередного попаданца-достигатора в стиле литРПГ. Есть разница между образовательными видео и тупыми высерами большинства ютуберов и особенно тиктокеров. Есть полезная информация и есть "цифровой мусор".
С играми проблема в том, что в них приходят играть, а не грузить себе мозг околонаучной работой. Т.е. есть образовательные игры, но они не становятся сенсационными. Для примера, есть издание Minecraft специально для школ - там, по сути, мод на химию с физикой или что-то в этом духе. Т.е. они загоняют школьников в симуляцию, чтобы они не сжигали реальную лабораторию своей химией. Хорошо, но популярность Майнкрафта не из-за этого мода.
Самые популярные игры - на мобилках, и они часто требуют не более одной извилины. Особенно если рассчитано на детей - тупо яркая, бессмысленная картинка, чтоб 3-летние дурачки тыкали в экран.
И что они сделают? Очередную интеллектуальную историю, которая соберёт от силы 1000 отзывов?
Никто не запрещает писать литРПГ про попаданца.
Никто не запрещает снимать смешные видосики.
Никто не запрещает делать тупые игры для тупых.
Но не стоит думать, будто вы сейчас придумаете (своруете) гениальную идею игры, что повлияет на развитие всего человечества. Просто делайте то, что нравится вам самим и может понравиться кому-то. Это совсем не та сфера, которая двигает весь мир. И в ближайшее лет 10 ничего не изменится даже с ИИ.
>Книги, аудио и видео
Есть разница между технической, научно-популярной литературой и тупой графоманией про очередного попаданца-достигатора в стиле литРПГ. Есть разница между образовательными видео и тупыми высерами большинства ютуберов и особенно тиктокеров. Есть полезная информация и есть "цифровой мусор".
С играми проблема в том, что в них приходят играть, а не грузить себе мозг околонаучной работой. Т.е. есть образовательные игры, но они не становятся сенсационными. Для примера, есть издание Minecraft специально для школ - там, по сути, мод на химию с физикой или что-то в этом духе. Т.е. они загоняют школьников в симуляцию, чтобы они не сжигали реальную лабораторию своей химией. Хорошо, но популярность Майнкрафта не из-за этого мода.
Самые популярные игры - на мобилках, и они часто требуют не более одной извилины. Особенно если рассчитано на детей - тупо яркая, бессмысленная картинка, чтоб 3-летние дурачки тыкали в экран.
>гениев с уникальным мышлением
И что они сделают? Очередную интеллектуальную историю, которая соберёт от силы 1000 отзывов?
Никто не запрещает писать литРПГ про попаданца.
Никто не запрещает снимать смешные видосики.
Никто не запрещает делать тупые игры для тупых.
Но не стоит думать, будто вы сейчас придумаете (своруете) гениальную идею игры, что повлияет на развитие всего человечества. Просто делайте то, что нравится вам самим и может понравиться кому-то. Это совсем не та сфера, которая двигает весь мир. И в ближайшее лет 10 ничего не изменится даже с ИИ.
2 Мб, 1200x675>>4045
Забавно, что этот пост написан в 2024 году, за 10 лет до очередного предсказанного конца света в 2034 году будет сдвиг земной коры на 15 градусов.
> И в ближайшее лет 10 ничего не изменится даже с ИИ.
Забавно, что этот пост написан в 2024 году, за 10 лет до очередного предсказанного конца света в 2034 году будет сдвиг земной коры на 15 градусов.
47 Кб, 666x466Есть одна тридэигра... Давно хочу сделать игру с процедурной генерацией, но всё что-то не то. Короч, прихожу к выводу, что бессмысленно избегать 3D моделирования: лучше сначала налепить побольше моделек, а потом уже решать, как их процедурно соединять в игровом мире. А то без моделек любой подход к генерации выглядит как белый шум; всё разнообразие может сходиться к текстуркам... Эх.
Почему-то вбил себе в голову, что прежде, чем моделировать тыщи моделек, мне нужно чётко определиться с методами генерации мира - а то получится, что модельки сделаны зря, впустую...
Просто, понимаете, не выходит придумать геймплей совершенно без графики, который бы увлекал меня дольше, чем на 10 минут. Все мои игры мечты очень красочно-разнообразные, а вот механики простые...
Фраза "графон не главное" всё же принима только когда графон есть и он достаточно разнообразен, пускай и не фотореалистичен/не очень детален.
Почему-то вбил себе в голову, что прежде, чем моделировать тыщи моделек, мне нужно чётко определиться с методами генерации мира - а то получится, что модельки сделаны зря, впустую...
Просто, понимаете, не выходит придумать геймплей совершенно без графики, который бы увлекал меня дольше, чем на 10 минут. Все мои игры мечты очень красочно-разнообразные, а вот механики простые...
Фраза "графон не главное" всё же принима только когда графон есть и он достаточно разнообразен, пускай и не фотореалистичен/не очень детален.
>>4070
Это же очевидно, что тебе нужно вкатываться в моддинг, а не в геймдев. Вот там у тебя будет готовый опенворлд-скайрим, а ты туда будешь просто свои домики деревянные впиливать.
Это же очевидно, что тебе нужно вкатываться в моддинг, а не в геймдев. Вот там у тебя будет готовый опенворлд-скайрим, а ты туда будешь просто свои домики деревянные впиливать.
>>4074
И костылить. Потому что в готовой игре обязательно найдётся какой-то фатальный недостаток, из-за чего задуманное не сделать. Некоторые моды на Майн отвалились от него в самостоятельную игру - ведь, несмотря на свободу, Майн всё-таки ограничивает. Инструменты моддинга ещё зачастую неудобные...
Чтоб это всё выглядело прилично, нужно делать на уровне оригинала. Кривые лоупольки могут быть хорошей альтернативой только на фоне таких же кривых лоуполек, чтоб это выглядело как Стиль™. Условный Скайрим я 100% не смогу сам сделать.
Взять, хотя бы, Unturned:
https://store.steampowered.com/app/304930/
Стартовало оно как мод на Roblox, но выросло в полностью самостоятельную игру. Графика будто игрушечная, лоупольно-бестекстурная, но контента огромное количество. Механик много, но если ты рассмотришь эти механики на голой плоскости без моделек - будет очень скучно и быстро надоест. Прятаться от квадратных зомби в бестекстурных квадратных домиках не так-то весело, если бы не огромное количество разнообразного контента.
Повторюсь: хочу не мод на тот же Unturned, а свою собственную игру, но ковырять механики в пустом пространстве без контента скучно, и трудно понять, работают механики или нет. Думал заполнить эту пустоту процедуркой, но и ей нужен какой-то набор контента для работы, иначе получается серая каша.
Считай, это мысли вслух. Чтоб другие почитали и не ковырялись в прототипах механик несколько лет, надеясь найти "ту самую" формулу успеха, которая вывезет на себе всю игру вообще без контента.
>вкатываться в моддинг
И костылить. Потому что в готовой игре обязательно найдётся какой-то фатальный недостаток, из-за чего задуманное не сделать. Некоторые моды на Майн отвалились от него в самостоятельную игру - ведь, несмотря на свободу, Майн всё-таки ограничивает. Инструменты моддинга ещё зачастую неудобные...
>готовый опенворлд-скайрим,
>просто свои домики деревянные впиливать.
Чтоб это всё выглядело прилично, нужно делать на уровне оригинала. Кривые лоупольки могут быть хорошей альтернативой только на фоне таких же кривых лоуполек, чтоб это выглядело как Стиль™. Условный Скайрим я 100% не смогу сам сделать.
Взять, хотя бы, Unturned:
https://store.steampowered.com/app/304930/
>Очень положительные (91% из 545,763)
Стартовало оно как мод на Roblox, но выросло в полностью самостоятельную игру. Графика будто игрушечная, лоупольно-бестекстурная, но контента огромное количество. Механик много, но если ты рассмотришь эти механики на голой плоскости без моделек - будет очень скучно и быстро надоест. Прятаться от квадратных зомби в бестекстурных квадратных домиках не так-то весело, если бы не огромное количество разнообразного контента.
Повторюсь: хочу не мод на тот же Unturned, а свою собственную игру, но ковырять механики в пустом пространстве без контента скучно, и трудно понять, работают механики или нет. Думал заполнить эту пустоту процедуркой, но и ей нужен какой-то набор контента для работы, иначе получается серая каша.
Считай, это мысли вслух. Чтоб другие почитали и не ковырялись в прототипах механик несколько лет, надеясь найти "ту самую" формулу успеха, которая вывезет на себе всю игру вообще без контента.
>>4070
Скачиваешь ассеты и процедурно генерируешь из них, если игра получится веселой и интересной, тогда постепенно заменяешь ассеты на свои
Скачиваешь ассеты и процедурно генерируешь из них, если игра получится веселой и интересной, тогда постепенно заменяешь ассеты на свои
744 Кб, 564x752Есть ли хоть сколько-то внятные туториалы по новым 2D скелетам? Я так понял в 4.3 их перелопатили, теперь непонятно как делать инверс кинематику и биндить спрайты/полигоны к костям
>>4080
С чего ты взял? В 4.3 изменили 3D скелеты - чтобы привести их в соответствие 2D скелетам. Т.е. теперь анимационный стек работает и для тех, и для других.
Или ты с 3.x переходишь?
>Я так понял в 4.3 их перелопатили
С чего ты взял? В 4.3 изменили 3D скелеты - чтобы привести их в соответствие 2D скелетам. Т.е. теперь анимационный стек работает и для тех, и для других.
Или ты с 3.x переходишь?
23 Кб, 850x229>>4081
Я имел в виду что поменяли интерфейс в редакторе, теперь старых кнопок типа "создать IK-цепь прямо из спрайтов" нет, приходится ебаться с SkeletonModificationStack2D
Я имел в виду что поменяли интерфейс в редакторе, теперь старых кнопок типа "создать IK-цепь прямо из спрайтов" нет, приходится ебаться с SkeletonModificationStack2D
>>4093
Так его ещё в 4.0 добавили:
https://docs.godotengine.org/en/4.0/classes/class_skeletonmodificationstack2d.html
Смотри туториалы по переходу с 3.x на 4.0.
>SkeletonModificationStack2D
Так его ещё в 4.0 добавили:
https://docs.godotengine.org/en/4.0/classes/class_skeletonmodificationstack2d.html
Смотри туториалы по переходу с 3.x на 4.0.
>>4045
Ты про симуляции забыл, умник . Широкое разнообразие симуляций которые можно встретить в играх. Логических, технических, социальных, политических, физических, и других которые я не назвал.
Они смогут впихнуть в этот формат вещи которые не смогли впихнуть до этого.
Как же отвратительно читать твое старческое ворчание. Я понимаю что это своего рода реализм, но блядь, ты такой невежда, и только и спешишь поскорее поныть.
Ты про симуляции забыл, умник . Широкое разнообразие симуляций которые можно встретить в играх. Логических, технических, социальных, политических, физических, и других которые я не назвал.
>И что они сделают? Очередную интеллектуальную историю, которая соберёт от силы 1000 отзывов?
Они смогут впихнуть в этот формат вещи которые не смогли впихнуть до этого.
Как же отвратительно читать твое старческое ворчание. Я понимаю что это своего рода реализм, но блядь, ты такой невежда, и только и спешишь поскорее поныть.
>>4067
Еще забавнее, что я буквально неделю назад писал, какой прорыв может появиться в играх, если туда добавить ИИ-геймдизайнера, оценивающего смысл действий игрока.
Еще забавнее, что я буквально неделю назад писал, какой прорыв может появиться в играх, если туда добавить ИИ-геймдизайнера, оценивающего смысл действий игрока.
>>4078
Или можно использовать CSG ноды...
Потому что найти даже платные ассеты нереально.
>Скачиваешь ассеты
Или можно использовать CSG ноды...
Потому что найти даже платные ассеты нереально.
>>4190
Если б все могли сами себе делать, никаких проблем бы не было.
Делаешь хорошо -> много времени впустую -> теряешь веру в игру.
Делаешь криво -> выглядит хуже других -> теряешь веру в свои силы.
Вообще не делаешь -> серые кубы -> ничего не понятно -> бросаешь.
Воруешь из интернета -> не твоя игра, а ворованная -> неинтересно.
Покупаешь -> не твоя игра, а купленная -> дорого и бессмысленно.
>самому делать
Если б все могли сами себе делать, никаких проблем бы не было.
Делаешь хорошо -> много времени впустую -> теряешь веру в игру.
Делаешь криво -> выглядит хуже других -> теряешь веру в свои силы.
Вообще не делаешь -> серые кубы -> ничего не понятно -> бросаешь.
Воруешь из интернета -> не твоя игра, а ворованная -> неинтересно.
Покупаешь -> не твоя игра, а купленная -> дорого и бессмысленно.
>>4194
Стиль > графоний. Стиль тоже скилл, конечно, но прокачивается он в разы быстрее, а применяется легче.
Стиль > графоний. Стиль тоже скилл, конечно, но прокачивается он в разы быстрее, а применяется легче.
>>4190
Представь, чтобы скачать и вставить модельки отсюда >>939370 →
займет 1-2-3 дня. За такое время такое же количество ты не сделаешь сам, ага.
Представь, чтобы скачать и вставить модельки отсюда >>939370 →
займет 1-2-3 дня. За такое время такое же количество ты не сделаешь сам, ага.
>>3902
Перепробовал всё что ты перечислил, но избавиться от кирпичечной вечеринки мне помог только джолт
Спасибо за развёрнутый ответ
Перепробовал всё что ты перечислил, но избавиться от кирпичечной вечеринки мне помог только джолт
Спасибо за развёрнутый ответ
Как снизить фпс _process одной ноды? Чтобы не каждый фрейм отрабатывало, а, допустим, каждый 3. Помимо if frames % 3 == 0: return
Короче, что делать если для моей задачи использование таймеров - слишком медленное, а _process - слишком быстрое?
Короче, что делать если для моей задачи использование таймеров - слишком медленное, а _process - слишком быстрое?
>>4206
Скорее всего, тебе нужен _physics_process, который по умолчанию фиксирован на 60 тиков в секунду, но в принципе можно снизить ещё больше, если физика не особо нужна. А вот _process зависит от частоты обновления экрана/установленного лимита кадров и у современных геймеров может быть хоть 240, хоть 480. Действительно ли тебе нужно привязывать что-то к кадрам?
Для прототипа сойдёт, а потом разберёшься, переделывать или оставить.
>снизить фпс _process одной ноды
Скорее всего, тебе нужен _physics_process, который по умолчанию фиксирован на 60 тиков в секунду, но в принципе можно снизить ещё больше, если физика не особо нужна. А вот _process зависит от частоты обновления экрана/установленного лимита кадров и у современных геймеров может быть хоть 240, хоть 480. Действительно ли тебе нужно привязывать что-то к кадрам?
>Помимо if frames % 3 != 0: return
Для прототипа сойдёт, а потом разберёшься, переделывать или оставить.
Аноны, что в годоте с разрушаемостью?
В анриле Chaos Desctruction, в Unity есть RayFire. А в годоте онли васянские плагины?
В анриле Chaos Desctruction, в Unity есть RayFire. А в годоте онли васянские плагины?
>>4242
а ты кто вообще?
а ты кто вообще?
>>4240
Ну, смотри, даже в ААА тайтлах "разрушаемость" не настоящая - там фейковые катсцены, запечённые в продвинутой проге типа Blender. Игровой движок не занимается такими вещами. Я посмотрел по твоим ссылкам - там тоже васянки, имитирующие Blender.
Дело в том, что ты не можешь "разрушить" 3D меш. Возможно математически его разрезать - но это чрезвычайно дорогая операция и она подвержена артефактам/ошибкам округления и т.д. Крайне не рекомендую использовать разрезание мешей в реальном времени, от этого нет пользы игроку.
На практике, то, что тебе нужно - то, что используют даже в дорогих ААА играх - это набор из нескольких отдельных мешей и коллизий. Базовая модель - это целый объект, плюс один или несколько "осколков" отдельными объектами. Когда игрок "разрушает" базовую модель, ты всего лишь заменяешь её на несколько "осколков". Этого достаточно для всех современных игр - и даже избыточно. Т.е. тебе не обязательно давать обломкам коллизии и крутить симуляцию в физическом движке - обычно вся эта "разрушаемость" - простая анимация. Особенно это касается больших объектов вроде зданий, мостов и прочего, что рассыпается на множество осколков - современные компы и особенно приставки не тянут подобную масштабность, что бы тебе ни говорили.
Так что Godot в этом плане ничем не отличается, но требует чуть больше работы, т.к. нет автоматизации процесса из коробки: если надо, делай инструмент самостоятельно, всё необходимое для этого есть.
Главное помнить, что разрушаемость не является самостоятельной игровой механикой. Конечно, есть игры вроде Teardown, но это нишевые продукты - их ниша, судя по всему, уже давно переполнена. Зачем создавать ещё один симулятор разрушения, когда можно просто поиграть в уже существующий? Там математика очень сложная, а результат - ну такое. Придумай лучше какую-то интересную механику.
>>4242
Ты чего такой злой сегодня? Не с той ноги встал?
>разрушаемость
Ну, смотри, даже в ААА тайтлах "разрушаемость" не настоящая - там фейковые катсцены, запечённые в продвинутой проге типа Blender. Игровой движок не занимается такими вещами. Я посмотрел по твоим ссылкам - там тоже васянки, имитирующие Blender.
Дело в том, что ты не можешь "разрушить" 3D меш. Возможно математически его разрезать - но это чрезвычайно дорогая операция и она подвержена артефактам/ошибкам округления и т.д. Крайне не рекомендую использовать разрезание мешей в реальном времени, от этого нет пользы игроку.
На практике, то, что тебе нужно - то, что используют даже в дорогих ААА играх - это набор из нескольких отдельных мешей и коллизий. Базовая модель - это целый объект, плюс один или несколько "осколков" отдельными объектами. Когда игрок "разрушает" базовую модель, ты всего лишь заменяешь её на несколько "осколков". Этого достаточно для всех современных игр - и даже избыточно. Т.е. тебе не обязательно давать обломкам коллизии и крутить симуляцию в физическом движке - обычно вся эта "разрушаемость" - простая анимация. Особенно это касается больших объектов вроде зданий, мостов и прочего, что рассыпается на множество осколков - современные компы и особенно приставки не тянут подобную масштабность, что бы тебе ни говорили.
Так что Godot в этом плане ничем не отличается, но требует чуть больше работы, т.к. нет автоматизации процесса из коробки: если надо, делай инструмент самостоятельно, всё необходимое для этого есть.
Главное помнить, что разрушаемость не является самостоятельной игровой механикой. Конечно, есть игры вроде Teardown, но это нишевые продукты - их ниша, судя по всему, уже давно переполнена. Зачем создавать ещё один симулятор разрушения, когда можно просто поиграть в уже существующий? Там математика очень сложная, а результат - ну такое. Придумай лучше какую-то интересную механику.
>>4242
Ты чего такой злой сегодня? Не с той ноги встал?
>>4262
Сложно. И затратно, если они мелкие.
Кстати, рассматривал воксели для ландшафта - как по мне, они дают слишком мало контроля, если брать большой масштаб. Для ровных плоскостей и плавных изгибов нормально, а шероховатости сделать, не уменьшая сами воксели, нельзя...
Есть ли выход? Можно, конечно, заготовить много отдельных мешей, но их как-то соединять нужно, чтоб зазоров не оставалось между разными "вокселями".
>воксели
Сложно. И затратно, если они мелкие.
Кстати, рассматривал воксели для ландшафта - как по мне, они дают слишком мало контроля, если брать большой масштаб. Для ровных плоскостей и плавных изгибов нормально, а шероховатости сделать, не уменьшая сами воксели, нельзя...
Есть ли выход? Можно, конечно, заготовить много отдельных мешей, но их как-то соединять нужно, чтоб зазоров не оставалось между разными "вокселями".
>>4266
Там только стиль воксельный.
Там специализированный движок.
Для Godot есть это:
https://github.com/Zylann/godot_voxel
Но там же вроде число под ландшафт. Пробовал его сборку движка - там совсем не то, что ты обычно делаешь с 3D модельками. Сложно разобраться.
Пока не будет поддержки видеокартами на том же уровне, что и растры, о вокселях можно забыть. А видеокартам для поддержки вокселей нужно очень много памяти. Которой NVIDIA не хочет делиться...
>Клаудпанк
Там только стиль воксельный.
>тирдаун
Там специализированный движок.
Для Godot есть это:
https://github.com/Zylann/godot_voxel
Но там же вроде число под ландшафт. Пробовал его сборку движка - там совсем не то, что ты обычно делаешь с 3D модельками. Сложно разобраться.
Пока не будет поддержки видеокартами на том же уровне, что и растры, о вокселях можно забыть. А видеокартам для поддержки вокселей нужно очень много памяти. Которой NVIDIA не хочет делиться...
Сделал прикольный индикатор. Если где-то нужна текстура, а рисовать лень - берите из SubViewport.
Формально это процедурная текстура...
Формально это процедурная текстура...
>>4273
Круто
Круто
Сильно ли влияет комплексная но скрытая из виду меш на производительность? Условно, если я спрячу модель йоба ангела из дьяблы под пол - он будет ебать мой фпс?
>>4282
Насколько я помню, некоторые расчеты продолжают выполняться, например octotree. Но сколько это в фпс, хз. Может быть 0.1%? Возьми сам и померь, делов то.
Насколько я помню, некоторые расчеты продолжают выполняться, например octotree. Но сколько это в фпс, хз. Может быть 0.1%? Возьми сам и померь, делов то.
>>4273
Там есть некоторые нюансы. Во-первых где настраивать антиалиасинг, во-вторых раньше много вьюпортов просаживало перформанс, так что много таких штук делать было рисковано (как в 4 не знаю). Хотя, в некоторых случаях можно сгруппировать несколько иконок на одном вьюпорте, хм.
Там есть некоторые нюансы. Во-первых где настраивать антиалиасинг, во-вторых раньше много вьюпортов просаживало перформанс, так что много таких штук делать было рисковано (как в 4 не знаю). Хотя, в некоторых случаях можно сгруппировать несколько иконок на одном вьюпорте, хм.
>>4286
Если в сабвьюпорте - сглаживается то, что в текстуре.
render_target_update_mode = UPDATE_ONCE
Можно вообще что угодно генерировать...
>где настраивать антиалиасинг
Если в сабвьюпорте - сглаживается то, что в текстуре.
>просаживало перформанс
render_target_update_mode = UPDATE_ONCE
>сгруппировать несколько иконок
Можно вообще что угодно генерировать...
>>4282
По умолчанию она продолжит рендериться под полом, пока ты смотришь в её направлении:
https://docs.godotengine.org/en/stable/tutorials/3d/occlusion_culling.html
Но если у модели visible = false, то проблем нет.
>если я спрячу модель... под пол
По умолчанию она продолжит рендериться под полом, пока ты смотришь в её направлении:
https://docs.godotengine.org/en/stable/tutorials/3d/occlusion_culling.html
Но если у модели visible = false, то проблем нет.
>>4389
Это же очевидно, игорь тонет!
Это же очевидно, игорь тонет!
23,3 Мб, mp4,1012x584, 0:59
>>4389
Добавил недавно мутантов в игру, лицехвата и что-то типа кентавра. Да и вообще, кучу всего по мелочи. Ещё оказалось что у всех игра просаживалась до 20 фпс, а я этого как-то не замечал. Оказалось что из-за того что я все анимированные объекты просто ставил на сцену, из-за большого количества анимейшен плееров всё просаэживалось. Сделал по итогу спавн когда камера заходит в область спавна челика/объекта, и теперь минимум 200 - 300 фпс есть на большой карте хотя мне кажется можно ещё увеличить, учитывая что на маленьких локах у меня 1500 фпс, но я пока не думаю об этом
Добавил недавно мутантов в игру, лицехвата и что-то типа кентавра. Да и вообще, кучу всего по мелочи. Ещё оказалось что у всех игра просаживалась до 20 фпс, а я этого как-то не замечал. Оказалось что из-за того что я все анимированные объекты просто ставил на сцену, из-за большого количества анимейшен плееров всё просаэживалось. Сделал по итогу спавн когда камера заходит в область спавна челика/объекта, и теперь минимум 200 - 300 фпс есть на большой карте хотя мне кажется можно ещё увеличить, учитывая что на маленьких локах у меня 1500 фпс, но я пока не думаю об этом
>>4301
Я попробовал в 4-ке и что-то не выходит. Может что-то упускаю.
Пик 1 - просто линия
Пик 2 - линия в сабвьюпорте -> вьюпорт текстура прогресс контрола
Пик 3 - настройки сабвьюпорта, вообще нет пункта anisotropic
Пик 4 - настройки зеленого контрола.
Размер контрола = размер сабвьюпорта = 512х512
(В настройках проекта по умолчанию Rendering->Textures->Anisotropic Filter-> 4x Fast
Потыкал рендеры, вроде и в GL Compatibility и в Forward+ одинаково.
Во-первых, как это поможет если делать много анимированных индикаторов как из примера выше?
Во-вторых тут мне лень измерять, но скорее всего они все идут с оверхедом, может быть видеопамять или что-то еще.
>Если в сабвьюпорте - сглаживается то, что в текстуре.
Я попробовал в 4-ке и что-то не выходит. Может что-то упускаю.
Пик 1 - просто линия
Пик 2 - линия в сабвьюпорте -> вьюпорт текстура прогресс контрола
Пик 3 - настройки сабвьюпорта, вообще нет пункта anisotropic
Пик 4 - настройки зеленого контрола.
Размер контрола = размер сабвьюпорта = 512х512
(В настройках проекта по умолчанию Rendering->Textures->Anisotropic Filter-> 4x Fast
Потыкал рендеры, вроде и в GL Compatibility и в Forward+ одинаково.
>UPDATE_ONCE
Во-первых, как это поможет если делать много анимированных индикаторов как из примера выше?
Во-вторых тут мне лень измерять, но скорее всего они все идут с оверхедом, может быть видеопамять или что-то еще.
>>4406
Просто делаешь рофельные проекты специально для двача, готово.
Просто делаешь рофельные проекты специально для двача, готово.
Я правильно понимаю, что в природе на ютубе не существует полноценных туториалов по созданию пошаговой тактической игры (с боями, как в xcom, jagged alliance и т.п.), потому что пошел я нахрен это куда более не тривиальная задача, чем очередной 2д платформер?
Пока нашел только видосы с теоритическими выкладками или по отдельным темам, но хотелось бы на сам код глянуть
Пока нашел только видосы с теоритическими выкладками или по отдельным темам, но хотелось бы на сам код глянуть
>>4256
А в red fuction разве тоже фейк разрушаемость? Да даже если так - это все равно какие-то забытые технологии.
Меня вот взаимодействие с миром и в т.ч. разрушаемость поражает больше, чем любой графон. Прям вау эффект испытываю всегда
А в red fuction разве тоже фейк разрушаемость? Да даже если так - это все равно какие-то забытые технологии.
Меня вот взаимодействие с миром и в т.ч. разрушаемость поражает больше, чем любой графон. Прям вау эффект испытываю всегда
>>4424
Игра и состоит из суммы элементов. Смотришь туториал по 2д тактической рпг, смотришь туториал по 3д анимациям, прикручиваешь, бац, готово.
Игра и состоит из суммы элементов. Смотришь туториал по 2д тактической рпг, смотришь туториал по 3д анимациям, прикручиваешь, бац, готово.
>>4424
1. Разбираться в чужом коде всегда сложнее, чем придумывать собственный. Поэтому в туториалах максимально упрощают, делая код, который ты не должен использовать в реальной большой игре.
2. Когда смотришь чужой код, рискуешь впасть в зависимость от копипасты. Ведь куда проще просто забрать рабочий код себе, не разбираясь в нём. Но когда-нибудь тебе понадобится решить задачу, под которую нет готового кода - а собственный так и не научился изобретать, привыкнув копировать чужой.
ИМХО, пошаговые игры проще платформеров, но у пошаговых игр очень узкая ниша, в то время как платформеры хорошо отражают суть экшн игр. Большинство игроков предпочитают экшн игры, а геймдевом обычно увлекаются игроки. Никому не выгодно делать туториал на, скажем, виртуальные шахматы - механически они проще платформера, но смотреть такой туториал мало кто будет.
Вкратце: двигаешь фигурки - ждёшь ход. Сложно?
>хотелось бы на сам код глянуть
1. Разбираться в чужом коде всегда сложнее, чем придумывать собственный. Поэтому в туториалах максимально упрощают, делая код, который ты не должен использовать в реальной большой игре.
2. Когда смотришь чужой код, рискуешь впасть в зависимость от копипасты. Ведь куда проще просто забрать рабочий код себе, не разбираясь в нём. Но когда-нибудь тебе понадобится решить задачу, под которую нет готового кода - а собственный так и не научился изобретать, привыкнув копировать чужой.
>пошаговой тактической игры
>очередной 2д платформер
ИМХО, пошаговые игры проще платформеров, но у пошаговых игр очень узкая ниша, в то время как платформеры хорошо отражают суть экшн игр. Большинство игроков предпочитают экшн игры, а геймдевом обычно увлекаются игроки. Никому не выгодно делать туториал на, скажем, виртуальные шахматы - механически они проще платформера, но смотреть такой туториал мало кто будет.
Вкратце: двигаешь фигурки - ждёшь ход. Сложно?
>>4432
Идея в том, чтобы два игрока мышкой пытались отобрать друг у друга кнопку. У меня есть несколько мышек, но винда позволяет управлять только одним курсором. И если кликнуть по второму окну, другие потеряют фокус (ввод с клавиатуры/геймпада). Тут нужен отдельный компьютер/телефон, но тогда демо придётся записывать на реальную камеру.
Мультиплеерные кнопки так и останутся мечтой...
Идея в том, чтобы два игрока мышкой пытались отобрать друг у друга кнопку. У меня есть несколько мышек, но винда позволяет управлять только одним курсором. И если кликнуть по второму окну, другие потеряют фокус (ввод с клавиатуры/геймпада). Тут нужен отдельный компьютер/телефон, но тогда демо придётся записывать на реальную камеру.
Мультиплеерные кнопки так и останутся мечтой...
>>4433
Я еще лет 20 назад играл на винде в хотсит матч-3 с несолькими мышками. Очевидно это можно закодить самому (различать USB мышки по HID?) или поставить какую то прогу мультиплексор, правда на гитхабе опенсорсных не нашел.
Конечно нагуглить название игры не получилось, вылезают только ответы что это невозможно, лол.
Я еще лет 20 назад играл на винде в хотсит матч-3 с несолькими мышками. Очевидно это можно закодить самому (различать USB мышки по HID?) или поставить какую то прогу мультиплексор, правда на гитхабе опенсорсных не нашел.
Конечно нагуглить название игры не получилось, вылезают только ответы что это невозможно, лол.
>>4428
Тебе повезло, потому что я делал мультиплеерные кнопки
Для начала тебе надо разобраться с @rpc вызовами
https://docs.godotengine.org/en/stable/tutorials/networking/high_level_multiplayer.html
Не буду пересказывать, только скажу, что в целом это похоже на сигналы. Ты не вызываешь функцию, а отправляешь запрос, rpc не возвращает результат функции, а статус, например дисконнект. Ах да, в идеале надо каждый вызов rpc проверять на ошибку, а еще желательно перед каждым вызовом проверять, подключен ли до сих пор клиент.
Можно навелосипедить что-то вроде await rpc
https://www.reddit.com/r/godot/comments/11zgria/have_you_ever_wanted_to_use_await_on_an_rpc_call/
Так же, важный момент, нельзя передавать аргументами rpc функции объекты, ноды, ресурсы, текстуры и так далее. Но можно строки (а значит, можно передать путь к ноде в дереве, но там вроде какой то флаг надо, readable node names), цифры (то есть можно сказать - нажми 3-ю кнопку), и словари (а значит, если написать свой сериализатор, можно передавать любые данные)
%%P.s. я не пробовал репликацию сцен в 4. Тут есть описание, не знаю насколько актуально. https://godotengine.org/article/multiplayer-in-godot-4-0-scene-replication/
55
Итак, когда кнопка нажата, ее надо задисейблить (и настроить визуал чтобы она стала серой) и отправить вызов серверу. Также на клиенте можно запустить таймер кулдауна, после которого она отлипнет.
При таймауте отправки желательно показать на клиенте какой-то красный треугольнчек (и отлепить кнопку)
Сервер может отправить потдтверждение при получении. Потом он может отсчитать кулдаун и отправить разрешение на отлипание.
Понятно что у обоих подходов свои минусы. Наверняка вы играли в ммо, где нажимаешь уже откатившуюся кнопку, а она не срабатывает, потому что на сервере таймер то стартанул чуть позже, и значит на сервере время еще не вышло. А если ждать подтверждения с сервера, то кнопка будет нажиматься с запаздыванием.
Ладно, теперь пару слов про архитектуру многопользовательских кнопок. У меня было маленькое приложение, поэтому я общий клиент-серверный код поместил в одном файле.
Не забывай, что rpc фунция может определить через if, запущена она на сервере или клиенте. А также, есть вызов rpc_id, который укажет на чем запустить функцию. А еще есть специальные аннотации, которые указывают, можно ли запустить функцию локально, может ли клиент сам себе ее вызвать по сети, и прочее.
В конце хочу поднять вопрос безопасности. И C#. и gdscript легко декомпилируются. И если просто в клиенте написать, вот эта функция вызывается только с сервера, то хакер просто уберет аннотацию и вызовет ее сам, прибавив себе сотни нефти. Надо прогонять все запросы через сервер и проверять их там. В идеале, надо чтобы в клиенте были только кнопки, а вся логика закрыта в сервере, но так не получается из за лага, поэтому добавляют все эти интерполяции, экстраполяции, предсаказания и остальное.
Тебе повезло, потому что я делал мультиплеерные кнопки
Для начала тебе надо разобраться с @rpc вызовами
https://docs.godotengine.org/en/stable/tutorials/networking/high_level_multiplayer.html
Не буду пересказывать, только скажу, что в целом это похоже на сигналы. Ты не вызываешь функцию, а отправляешь запрос, rpc не возвращает результат функции, а статус, например дисконнект. Ах да, в идеале надо каждый вызов rpc проверять на ошибку, а еще желательно перед каждым вызовом проверять, подключен ли до сих пор клиент.
Можно навелосипедить что-то вроде await rpc
https://www.reddit.com/r/godot/comments/11zgria/have_you_ever_wanted_to_use_await_on_an_rpc_call/
Так же, важный момент, нельзя передавать аргументами rpc функции объекты, ноды, ресурсы, текстуры и так далее. Но можно строки (а значит, можно передать путь к ноде в дереве, но там вроде какой то флаг надо, readable node names), цифры (то есть можно сказать - нажми 3-ю кнопку), и словари (а значит, если написать свой сериализатор, можно передавать любые данные)
%%P.s. я не пробовал репликацию сцен в 4. Тут есть описание, не знаю насколько актуально. https://godotengine.org/article/multiplayer-in-godot-4-0-scene-replication/
55
Итак, когда кнопка нажата, ее надо задисейблить (и настроить визуал чтобы она стала серой) и отправить вызов серверу. Также на клиенте можно запустить таймер кулдауна, после которого она отлипнет.
При таймауте отправки желательно показать на клиенте какой-то красный треугольнчек (и отлепить кнопку)
Сервер может отправить потдтверждение при получении. Потом он может отсчитать кулдаун и отправить разрешение на отлипание.
Понятно что у обоих подходов свои минусы. Наверняка вы играли в ммо, где нажимаешь уже откатившуюся кнопку, а она не срабатывает, потому что на сервере таймер то стартанул чуть позже, и значит на сервере время еще не вышло. А если ждать подтверждения с сервера, то кнопка будет нажиматься с запаздыванием.
Ладно, теперь пару слов про архитектуру многопользовательских кнопок. У меня было маленькое приложение, поэтому я общий клиент-серверный код поместил в одном файле.
Не забывай, что rpc фунция может определить через if, запущена она на сервере или клиенте. А также, есть вызов rpc_id, который укажет на чем запустить функцию. А еще есть специальные аннотации, которые указывают, можно ли запустить функцию локально, может ли клиент сам себе ее вызвать по сети, и прочее.
В конце хочу поднять вопрос безопасности. И C#. и gdscript легко декомпилируются. И если просто в клиенте написать, вот эта функция вызывается только с сервера, то хакер просто уберет аннотацию и вызовет ее сам, прибавив себе сотни нефти. Надо прогонять все запросы через сервер и проверять их там. В идеале, надо чтобы в клиенте были только кнопки, а вся логика закрыта в сервере, но так не получается из за лага, поэтому добавляют все эти интерполяции, экстраполяции, предсаказания и остальное.
>>4428
Тебе повезло, потому что я делал мультиплеерные кнопки
Для начала тебе надо разобраться с @rpc вызовами
https://docs.godotengine.org/en/stable/tutorials/networking/high_level_multiplayer.html
Не буду пересказывать, только скажу, что в целом это похоже на сигналы. Ты не вызываешь функцию, а отправляешь запрос, rpc не возвращает результат функции, а статус, например дисконнект. Ах да, в идеале надо каждый вызов rpc проверять на ошибку, а еще желательно перед каждым вызовом проверять, подключен ли до сих пор клиент.
Можно навелосипедить что-то вроде await rpc
https://www.reddit.com/r/godot/comments/11zgria/have_you_ever_wanted_to_use_await_on_an_rpc_call/
Так же, важный момент, нельзя передавать аргументами rpc функции объекты, ноды, ресурсы, текстуры и так далее. Но можно строки (а значит, можно передать путь к ноде в дереве, но там вроде какой то флаг надо, readable node names), цифры (то есть можно сказать - нажми 3-ю кнопку), и словари (а значит, если написать свой сериализатор, можно передавать любые данные)
%%P.s. я не пробовал репликацию сцен в 4. Тут есть описание, не знаю насколько актуально. https://godotengine.org/article/multiplayer-in-godot-4-0-scene-replication/
55
Итак, когда кнопка нажата, ее надо задисейблить (и настроить визуал чтобы она стала серой) и отправить вызов серверу. Также на клиенте можно запустить таймер кулдауна, после которого она отлипнет.
При таймауте отправки желательно показать на клиенте какой-то красный треугольнчек (и отлепить кнопку)
Сервер может отправить потдтверждение при получении. Потом он может отсчитать кулдаун и отправить разрешение на отлипание.
Понятно что у обоих подходов свои минусы. Наверняка вы играли в ммо, где нажимаешь уже откатившуюся кнопку, а она не срабатывает, потому что на сервере таймер то стартанул чуть позже, и значит на сервере время еще не вышло. А если ждать подтверждения с сервера, то кнопка будет нажиматься с запаздыванием.
Ладно, теперь пару слов про архитектуру многопользовательских кнопок. У меня было маленькое приложение, поэтому я общий клиент-серверный код поместил в одном файле.
Не забывай, что rpc фунция может определить через if, запущена она на сервере или клиенте. А также, есть вызов rpc_id, который укажет на чем запустить функцию. А еще есть специальные аннотации, которые указывают, можно ли запустить функцию локально, может ли клиент сам себе ее вызвать по сети, и прочее.
В конце хочу поднять вопрос безопасности. И C#. и gdscript легко декомпилируются. И если просто в клиенте написать, вот эта функция вызывается только с сервера, то хакер просто уберет аннотацию и вызовет ее сам, прибавив себе сотни нефти. Надо прогонять все запросы через сервер и проверять их там. В идеале, надо чтобы в клиенте были только кнопки, а вся логика закрыта в сервере, но так не получается из за лага, поэтому добавляют все эти интерполяции, экстраполяции, предсаказания и остальное.
Тебе повезло, потому что я делал мультиплеерные кнопки
Для начала тебе надо разобраться с @rpc вызовами
https://docs.godotengine.org/en/stable/tutorials/networking/high_level_multiplayer.html
Не буду пересказывать, только скажу, что в целом это похоже на сигналы. Ты не вызываешь функцию, а отправляешь запрос, rpc не возвращает результат функции, а статус, например дисконнект. Ах да, в идеале надо каждый вызов rpc проверять на ошибку, а еще желательно перед каждым вызовом проверять, подключен ли до сих пор клиент.
Можно навелосипедить что-то вроде await rpc
https://www.reddit.com/r/godot/comments/11zgria/have_you_ever_wanted_to_use_await_on_an_rpc_call/
Так же, важный момент, нельзя передавать аргументами rpc функции объекты, ноды, ресурсы, текстуры и так далее. Но можно строки (а значит, можно передать путь к ноде в дереве, но там вроде какой то флаг надо, readable node names), цифры (то есть можно сказать - нажми 3-ю кнопку), и словари (а значит, если написать свой сериализатор, можно передавать любые данные)
%%P.s. я не пробовал репликацию сцен в 4. Тут есть описание, не знаю насколько актуально. https://godotengine.org/article/multiplayer-in-godot-4-0-scene-replication/
55
Итак, когда кнопка нажата, ее надо задисейблить (и настроить визуал чтобы она стала серой) и отправить вызов серверу. Также на клиенте можно запустить таймер кулдауна, после которого она отлипнет.
При таймауте отправки желательно показать на клиенте какой-то красный треугольнчек (и отлепить кнопку)
Сервер может отправить потдтверждение при получении. Потом он может отсчитать кулдаун и отправить разрешение на отлипание.
Понятно что у обоих подходов свои минусы. Наверняка вы играли в ммо, где нажимаешь уже откатившуюся кнопку, а она не срабатывает, потому что на сервере таймер то стартанул чуть позже, и значит на сервере время еще не вышло. А если ждать подтверждения с сервера, то кнопка будет нажиматься с запаздыванием.
Ладно, теперь пару слов про архитектуру многопользовательских кнопок. У меня было маленькое приложение, поэтому я общий клиент-серверный код поместил в одном файле.
Не забывай, что rpc фунция может определить через if, запущена она на сервере или клиенте. А также, есть вызов rpc_id, который укажет на чем запустить функцию. А еще есть специальные аннотации, которые указывают, можно ли запустить функцию локально, может ли клиент сам себе ее вызвать по сети, и прочее.
В конце хочу поднять вопрос безопасности. И C#. и gdscript легко декомпилируются. И если просто в клиенте написать, вот эта функция вызывается только с сервера, то хакер просто уберет аннотацию и вызовет ее сам, прибавив себе сотни нефти. Надо прогонять все запросы через сервер и проверять их там. В идеале, надо чтобы в клиенте были только кнопки, а вся логика закрыта в сервере, но так не получается из за лага, поэтому добавляют все эти интерполяции, экстраполяции, предсаказания и остальное.
>>4433
Если игра сделана без сингтонов с глобальными переменными, то она помещается в сцену. А значит, можно сделать мета-игру-сцену, в которой добавлено несколько сцен-игр.
Если игра сделана без сингтонов с глобальными переменными, то она помещается в сцену. А значит, можно сделать мета-игру-сцену, в которой добавлено несколько сцен-игр.
>>4408
Зачем так приближать? Насколько я понимаю, все элементы GUI/HUD должны оставаться на 100%...
Здесь видеокарта закрашивает треугольники одним сплошным цветом, поэтому края будут гладкими вне зависимости от растягивания/приближения.
Здесь видеокарта натягивает текстуру на большой прямоугольник из двух треугольников. Артефакты появляются из-за того, что текстура имеет слишком маленькое разрешение для такого растягивания.
Зачем тебе анизотропный фильтр? Он используется только когда текстура накладывается на плоскость под острым углом относительно камеры, тогда как у тебя текстура лежит строго в плоскости экрана:
https://ru.wikipedia.org/wiki/Анизотропная_фильтрация
Возможно, ты спутал с антиализингом (MSAA).
Мипмапы здесь тоже не нужны. Они нужны только когда ты накладываешь текстуру на очень мелкие объекты (далеко от камеры). У мипмапов меньшее разрешение, чем у оригинальной текстуры:
https://ru.wikipedia.org/wiki/MIP-текстурирование
Мипмапы в 2D могут пригодиться только если ты сжимаешь картинку меньше 100%, скажем, до 50%.
Ты хоть иногда документацию читай. UPDATE_ONCE рендерит картинку ОДНОКРАТНО, переключая этот вьюпорт в состояние UPDATE_DISABLED. Ничто не запустит повторный рендеринг, пока ты сам не переключишь этот параметр. Анимация вообще не взаимодействует с вьюпортом и его текстурой.
У тебя, по сути, всего два пути (не считаем .svg):
- нарисовать текстуру 512x512 в любом растровом редакторе и импортировать её в Godot в виде .png;
- рендерить сцену в текстуру 512x512 прям в Godot, составляя её из любых удобных нод и шейдеров.
В обоих случаях выделяется память под 512x512 пикселей. В первом случае эти пиксели хранятся на диске. Во втором случае хранится описание сцены, а также используются дополнительные ноды. Но в первом случае у тебя будет полностью статичная картинка, а во втором - процедурно генерируемая.
Как и в случае с CSG нодами, это способ быстро и удобно прототипировать текстуры-плейсхолдеры. Ты можешь по-быстрому набросать форму из Line2D, не переключаясь в отдельный редактор и даже без скачивания каких-то специальных аддонов. И ещё сохранить доступ к её компонентам, чтобы быстро поправить, без переключения на внешний редактор. Позже нарисуешь финальную графику в отдельном редакторе, а пока хватит и такого. Просто в тот же прогресс-бар нельзя вставить ничего кроме текстур.
>377.5%
Зачем так приближать? Насколько я понимаю, все элементы GUI/HUD должны оставаться на 100%...
>Пик 1 - просто линия
Здесь видеокарта закрашивает треугольники одним сплошным цветом, поэтому края будут гладкими вне зависимости от растягивания/приближения.
>Пик 2 - линия в сабвьюпорте
Здесь видеокарта натягивает текстуру на большой прямоугольник из двух треугольников. Артефакты появляются из-за того, что текстура имеет слишком маленькое разрешение для такого растягивания.
>anisotropic
Зачем тебе анизотропный фильтр? Он используется только когда текстура накладывается на плоскость под острым углом относительно камеры, тогда как у тебя текстура лежит строго в плоскости экрана:
https://ru.wikipedia.org/wiki/Анизотропная_фильтрация
Возможно, ты спутал с антиализингом (MSAA).
>mipmap
Мипмапы здесь тоже не нужны. Они нужны только когда ты накладываешь текстуру на очень мелкие объекты (далеко от камеры). У мипмапов меньшее разрешение, чем у оригинальной текстуры:
https://ru.wikipedia.org/wiki/MIP-текстурирование
Мипмапы в 2D могут пригодиться только если ты сжимаешь картинку меньше 100%, скажем, до 50%.
>>UPDATE_ONCE
>как это поможет если много анимированных
Ты хоть иногда документацию читай. UPDATE_ONCE рендерит картинку ОДНОКРАТНО, переключая этот вьюпорт в состояние UPDATE_DISABLED. Ничто не запустит повторный рендеринг, пока ты сам не переключишь этот параметр. Анимация вообще не взаимодействует с вьюпортом и его текстурой.
>идут с оверхедом, может быть видеопамять
У тебя, по сути, всего два пути (не считаем .svg):
- нарисовать текстуру 512x512 в любом растровом редакторе и импортировать её в Godot в виде .png;
- рендерить сцену в текстуру 512x512 прям в Godot, составляя её из любых удобных нод и шейдеров.
В обоих случаях выделяется память под 512x512 пикселей. В первом случае эти пиксели хранятся на диске. Во втором случае хранится описание сцены, а также используются дополнительные ноды. Но в первом случае у тебя будет полностью статичная картинка, а во втором - процедурно генерируемая.
Как и в случае с CSG нодами, это способ быстро и удобно прототипировать текстуры-плейсхолдеры. Ты можешь по-быстрому набросать форму из Line2D, не переключаясь в отдельный редактор и даже без скачивания каких-то специальных аддонов. И ещё сохранить доступ к её компонентам, чтобы быстро поправить, без переключения на внешний редактор. Позже нарисуешь финальную графику в отдельном редакторе, а пока хватит и такого. Просто в тот же прогресс-бар нельзя вставить ничего кроме текстур.
>>4408
Зачем так приближать? Насколько я понимаю, все элементы GUI/HUD должны оставаться на 100%...
Здесь видеокарта закрашивает треугольники одним сплошным цветом, поэтому края будут гладкими вне зависимости от растягивания/приближения.
Здесь видеокарта натягивает текстуру на большой прямоугольник из двух треугольников. Артефакты появляются из-за того, что текстура имеет слишком маленькое разрешение для такого растягивания.
Зачем тебе анизотропный фильтр? Он используется только когда текстура накладывается на плоскость под острым углом относительно камеры, тогда как у тебя текстура лежит строго в плоскости экрана:
https://ru.wikipedia.org/wiki/Анизотропная_фильтрация
Возможно, ты спутал с антиализингом (MSAA).
Мипмапы здесь тоже не нужны. Они нужны только когда ты накладываешь текстуру на очень мелкие объекты (далеко от камеры). У мипмапов меньшее разрешение, чем у оригинальной текстуры:
https://ru.wikipedia.org/wiki/MIP-текстурирование
Мипмапы в 2D могут пригодиться только если ты сжимаешь картинку меньше 100%, скажем, до 50%.
Ты хоть иногда документацию читай. UPDATE_ONCE рендерит картинку ОДНОКРАТНО, переключая этот вьюпорт в состояние UPDATE_DISABLED. Ничто не запустит повторный рендеринг, пока ты сам не переключишь этот параметр. Анимация вообще не взаимодействует с вьюпортом и его текстурой.
У тебя, по сути, всего два пути (не считаем .svg):
- нарисовать текстуру 512x512 в любом растровом редакторе и импортировать её в Godot в виде .png;
- рендерить сцену в текстуру 512x512 прям в Godot, составляя её из любых удобных нод и шейдеров.
В обоих случаях выделяется память под 512x512 пикселей. В первом случае эти пиксели хранятся на диске. Во втором случае хранится описание сцены, а также используются дополнительные ноды. Но в первом случае у тебя будет полностью статичная картинка, а во втором - процедурно генерируемая.
Как и в случае с CSG нодами, это способ быстро и удобно прототипировать текстуры-плейсхолдеры. Ты можешь по-быстрому набросать форму из Line2D, не переключаясь в отдельный редактор и даже без скачивания каких-то специальных аддонов. И ещё сохранить доступ к её компонентам, чтобы быстро поправить, без переключения на внешний редактор. Позже нарисуешь финальную графику в отдельном редакторе, а пока хватит и такого. Просто в тот же прогресс-бар нельзя вставить ничего кроме текстур.
>377.5%
Зачем так приближать? Насколько я понимаю, все элементы GUI/HUD должны оставаться на 100%...
>Пик 1 - просто линия
Здесь видеокарта закрашивает треугольники одним сплошным цветом, поэтому края будут гладкими вне зависимости от растягивания/приближения.
>Пик 2 - линия в сабвьюпорте
Здесь видеокарта натягивает текстуру на большой прямоугольник из двух треугольников. Артефакты появляются из-за того, что текстура имеет слишком маленькое разрешение для такого растягивания.
>anisotropic
Зачем тебе анизотропный фильтр? Он используется только когда текстура накладывается на плоскость под острым углом относительно камеры, тогда как у тебя текстура лежит строго в плоскости экрана:
https://ru.wikipedia.org/wiki/Анизотропная_фильтрация
Возможно, ты спутал с антиализингом (MSAA).
>mipmap
Мипмапы здесь тоже не нужны. Они нужны только когда ты накладываешь текстуру на очень мелкие объекты (далеко от камеры). У мипмапов меньшее разрешение, чем у оригинальной текстуры:
https://ru.wikipedia.org/wiki/MIP-текстурирование
Мипмапы в 2D могут пригодиться только если ты сжимаешь картинку меньше 100%, скажем, до 50%.
>>UPDATE_ONCE
>как это поможет если много анимированных
Ты хоть иногда документацию читай. UPDATE_ONCE рендерит картинку ОДНОКРАТНО, переключая этот вьюпорт в состояние UPDATE_DISABLED. Ничто не запустит повторный рендеринг, пока ты сам не переключишь этот параметр. Анимация вообще не взаимодействует с вьюпортом и его текстурой.
>идут с оверхедом, может быть видеопамять
У тебя, по сути, всего два пути (не считаем .svg):
- нарисовать текстуру 512x512 в любом растровом редакторе и импортировать её в Godot в виде .png;
- рендерить сцену в текстуру 512x512 прям в Godot, составляя её из любых удобных нод и шейдеров.
В обоих случаях выделяется память под 512x512 пикселей. В первом случае эти пиксели хранятся на диске. Во втором случае хранится описание сцены, а также используются дополнительные ноды. Но в первом случае у тебя будет полностью статичная картинка, а во втором - процедурно генерируемая.
Как и в случае с CSG нодами, это способ быстро и удобно прототипировать текстуры-плейсхолдеры. Ты можешь по-быстрому набросать форму из Line2D, не переключаясь в отдельный редактор и даже без скачивания каких-то специальных аддонов. И ещё сохранить доступ к её компонентам, чтобы быстро поправить, без переключения на внешний редактор. Позже нарисуешь финальную графику в отдельном редакторе, а пока хватит и такого. Просто в тот же прогресс-бар нельзя вставить ничего кроме текстур.
>>4437
Придется завтра еще раз проверять. Я на ноуте попробовал повторить, а лесенки нет. Может настройки проекта отличаются. Может быть ты прав что метод проверки неправильный, завтра еще в лупу на пискели посмотрю без зума.
Придется завтра еще раз проверять. Я на ноуте попробовал повторить, а лесенки нет. Может настройки проекта отличаются. Может быть ты прав что метод проверки неправильный, завтра еще в лупу на пискели посмотрю без зума.
129 Кб, 479x144>>4434
Вспомнил
https://web.archive.org/web/20100706162106/https://store.steampowered.com/app/7440
Вспомнил
https://web.archive.org/web/20100706162106/https://store.steampowered.com/app/7440
>Using the revolutionary Mouse Party, you can play with multiple players on the same computer
>OS: Windows 2000, Windows XP, Windows Vista
>Release Date: Dec 22, 2004
>>4439
Плохие новости - винда блокирует чтение через HID мышки чтобы мешать кейлоггерам
https://github.com/signal11/hidapi/issues/247
Хорошие новости - как то же эти три-четыре проги работают
https://softwarerecs.stackexchange.com/questions/79650/need-two-mouse-pointers-on-windows-10-11
Плохие новости - винда блокирует чтение через HID мышки чтобы мешать кейлоггерам
https://github.com/signal11/hidapi/issues/247
Хорошие новости - как то же эти три-четыре проги работают
https://softwarerecs.stackexchange.com/questions/79650/need-two-mouse-pointers-on-windows-10-11
Заодно наткнулся на что-то полезное про управление мышкой камеры
https://yosoyfreeman.github.io/article/godot/tutorial/achieving-better-mouse-input-in-godot-4-the-perfect-camera-controller/
https://yosoyfreeman.github.io/article/godot/tutorial/achieving-better-mouse-input-in-godot-4-the-perfect-camera-controller/
>>4464
Ты не читаешь, что тебе пишут. Он пишет, что все запросы надо через сервак прогонять и верифицировать. Шифрование там есть, но ключ вшит в экзешник. Ты не сможешь защитить свой код от васянов, пока не купишь Денуву.
Ты не читаешь, что тебе пишут. Он пишет, что все запросы надо через сервак прогонять и верифицировать. Шифрование там есть, но ключ вшит в экзешник. Ты не сможешь защитить свой код от васянов, пока не купишь Денуву.
>>4464
Это совсем от школьников. Чтобы игра работала, она должна быть расшифрована на компе игрока, а значит ключ тоже на компе игрока.
Правда я немного погорячился, декомпилятор пока не обновили до 4.1 и нового байткода (но могут через месяцок-другой обновить)
Это совсем от школьников. Чтобы игра работала, она должна быть расшифрована на компе игрока, а значит ключ тоже на компе игрока.
Правда я немного погорячился, декомпилятор пока не обновили до 4.1 и нового байткода (но могут через месяцок-другой обновить)
29 Кб, 283x803Какие разделы мануала обязательно стоит прочитать и понять, прежде чем двигаться дальше после туториалов(your first 2d/3d game)?
>>4479
Если лицензия позволяет, то легально. Если нет, то нет.
Да.
На сегодняшний день только денува, насколько я знаю. Во всех остальных случаях твоя драгоценная игра окажется на торрентах через день.
Это блять. Читай что тебе пишут.
> декомпилировать легально?
Если лицензия позволяет, то легально. Если нет, то нет.
> Почему еще какие-то проекты публичные для этого есть? Охуеть
Да.
> Как еще можно защитить кусочек своего кода?
На сегодняшний день только денува, насколько я знаю. Во всех остальных случаях твоя драгоценная игра окажется на торрентах через день.
> Обфусцировать его в кашу - реальный ли вариант?
Это блять. Читай что тебе пишут.
>>4481
Пусть окажется на торрентах через день, я даже за. Не хочу чтобы мой код читали, там 360 айкью гениальные решения. Они мои личные. Как мои трусы. Личные.
Пусть окажется на торрентах через день, я даже за. Не хочу чтобы мой код читали, там 360 айкью гениальные решения. Они мои личные. Как мои трусы. Личные.
>>4494 (Del)
Чойта ты порвался? Кто из местных тебя обидел?
Чойта ты порвался? Кто из местных тебя обидел?
>>4494 (Del)
оу май
оу май
>>4479
Сложно сделать. Я пробовал с++ обфусцировать, и строки в памяти обфусцировать, но это так муторно, с учетом оптимизаций компилятора, а еще это иногда ведет к багам и UB. А чтобы сломать, часто надо пару байтов нужных исправить.
Задумался вот, сейчас делаю игру на ECS, интересно ее сложнее сломать или проще? С одной стороны код проще, компоненты четче. С другой отладка сложнее, запутано где чьи компоненты. Можно конечно поугорать делая y-координату XOR второго байта хитпоинтов или что-то подобное.
Сложно сделать. Я пробовал с++ обфусцировать, и строки в памяти обфусцировать, но это так муторно, с учетом оптимизаций компилятора, а еще это иногда ведет к багам и UB. А чтобы сломать, часто надо пару байтов нужных исправить.
Задумался вот, сейчас делаю игру на ECS, интересно ее сложнее сломать или проще? С одной стороны код проще, компоненты четче. С другой отладка сложнее, запутано где чьи компоненты. Можно конечно поугорать делая y-координату XOR второго байта хитпоинтов или что-то подобное.
>>4480
Изучи едитор - вопросов будет меньше к анонам.
Изучи едитор - вопросов будет меньше к анонам.
143 Кб, 1093x790>>4480
Можешь загуглить обзор существующих нод и посмотреть пару раз, чтобы понять какие вообще существуют.
Скриптинг желательно весь конечно. Сигналы.
Если 3д, то полезно Rendering - Materials, Shadows, Lights
Полезно Input - Using InputEvent
Введение в ГУЙ есть в Step by step - Designing main menu
Из продвинутых тем - Math- Vector Math и далее, AnimationTree, шейдеры, Misc - Pausing Game, Saving Game, Network - High level multiplayer.
Tool-скипты (Misc - Running code in editor)
Можешь почитать https://kidscancode.org/godot_recipes/4.x/basics/index.html (есть и для 3)
Там вообще много полезных рецептов.
Можешь загуглить обзор существующих нод и посмотреть пару раз, чтобы понять какие вообще существуют.
Скриптинг желательно весь конечно. Сигналы.
Если 3д, то полезно Rendering - Materials, Shadows, Lights
Полезно Input - Using InputEvent
Введение в ГУЙ есть в Step by step - Designing main menu
Из продвинутых тем - Math- Vector Math и далее, AnimationTree, шейдеры, Misc - Pausing Game, Saving Game, Network - High level multiplayer.
Tool-скипты (Misc - Running code in editor)
Можешь почитать https://kidscancode.org/godot_recipes/4.x/basics/index.html (есть и для 3)
Там вообще много полезных рецептов.
7 Кб, 337x100>>4479
Любой код декомпилируется. Всегда так было. Это никого не волнует до тех пор, пока код программы нельзя открыть буквально как plain text. Начиная с 4.3 годо обфускация идет как побочный эффект третьей опции (и второй, ЕМНИП) в gdscript export mode. Этого хватит, разрешаю не трястись.
Любой код декомпилируется. Всегда так было. Это никого не волнует до тех пор, пока код программы нельзя открыть буквально как plain text. Начиная с 4.3 годо обфускация идет как побочный эффект третьей опции (и второй, ЕМНИП) в gdscript export mode. Этого хватит, разрешаю не трястись.
>>3787
Можно шейдер контролировать через внешний параметр, а сам параметр уже в анимации/скрипте.
>можно сделать шейдер ваншотным?
Можно шейдер контролировать через внешний параметр, а сам параметр уже в анимации/скрипте.
>>4543
Тут пока что барьер только низкая популярность годота. В java и .net есть декомпиляторы которые из байткода собирают читаемый код, в частности потому что компилятор то по одним шаблонам его генерит.
Тут пока что барьер только низкая популярность годота. В java и .net есть декомпиляторы которые из байткода собирают читаемый код, в частности потому что компилятор то по одним шаблонам его генерит.
46 Кб, 408x439> Как еще можно защитить кусочек своего кода?
На сегодняшний день только денува, насколько я знаю.
>>4548
И? В чем вопрос-то состоит? Чего хотите добиться? Кода, который не будет способен понять человек, но поймет компьютер? Как вы себе представляете такое? Любой код вскрывается и приводится в читаемый вид - то вопрос времени. А простейшая деобфускация огородит от васянов. И в большем реальные разработчики реального даже проприетарного софта не нуждаются. Не еби мозги.
И? В чем вопрос-то состоит? Чего хотите добиться? Кода, который не будет способен понять человек, но поймет компьютер? Как вы себе представляете такое? Любой код вскрывается и приводится в читаемый вид - то вопрос времени. А простейшая деобфускация огородит от васянов. И в большем реальные разработчики реального даже проприетарного софта не нуждаются. Не еби мозги.
177 Кб, 1000x1000>>4401
Ты явно новичок или вообще мимо проходил.
В этом ИТТ треде поощряется постить о прогрессе разработки своих игр на Godot. Самые интересные будут добавлены в шапку следующего треда на почётное место рядом с Годеттой или лого Godot. Обсуждали это несколько раз за последние годы.
>Это тред движка, а не прогресса своих игр.
Ты явно новичок или вообще мимо проходил.
В этом ИТТ треде поощряется постить о прогрессе разработки своих игр на Godot. Самые интересные будут добавлены в шапку следующего треда на почётное место рядом с Годеттой или лого Godot. Обсуждали это несколько раз за последние годы.
>>4558
ЗЫС
ЗЫС
>>4557
Байткод намного проще восстанавливается в читаемый код, чем компилированный с/с++. Прикинь, написав на с++, ты ставишь барьер, который городит не только от васянов, но уже и от толиков.
Байткод намного проще восстанавливается в читаемый код, чем компилированный с/с++. Прикинь, написав на с++, ты ставишь барьер, который городит не только от васянов, но уже и от толиков.
>>4558
Поощрается != требовать постить прогресс. Это не субшота. Конечно никто не против когда кто-то постит про устройство игр, показывает как что можно сделать.
Поощрается != требовать постить прогресс. Это не субшота. Конечно никто не против когда кто-то постит про устройство игр, показывает как что можно сделать.
101 Кб, 957x840>>4566
Посмотри на пикчу. Я васян или толян?
> на с++, ты ставишь барьер, который городит не только от васянов, но уже и от толиков
Посмотри на пикчу. Я васян или толян?
70 Кб, 749x680Есть возможность прохудить экспорт проекта без потерь времени и каких-нибудь возможных зависимостей? А то почти пустой проект в 100 мб это перебор, ящитаю. Года джва назад весь движок с эдитором 40-50 мб весил, а сейчас один только движок с ничем в сотню обходится. Не нравится мне все это. Блоатварь чертова и до робота родненького добралась.
>>4571
Серьезных, я имею в виду. Так я, конечно, готов потратить время. Но не очень много. Если можно.
>без потерь времени
Серьезных, я имею в виду. Так я, конечно, готов потратить время. Но не очень много. Если можно.
>>4571
А, ну да, еще забыл сказать, что вопрос состоит скорее не в том "а есть ли возможность?", но больше в смысле "как это сделать, если все же возможно?". Все-таки хотелось бы экспорт уменьшить на практике, одного знания мало будет.
>Есть возможность
А, ну да, еще забыл сказать, что вопрос состоит скорее не в том "а есть ли возможность?", но больше в смысле "как это сделать, если все же возможно?". Все-таки хотелось бы экспорт уменьшить на практике, одного знания мало будет.
>>4571
Какая версия у тебя? Краем глаза в 4.3 чейнджлоге видел что-то про уменьшение размеров.
Какая версия у тебя? Краем глаза в 4.3 чейнджлоге видел что-то про уменьшение размеров.
20 Кб, 652x44>>4570
Ты глазан.
Ты глазан.
>>4435
Это тебя должно заботить только если ты делаешь:
- ММО: потому что у тебя вся экономика завязана на честный геймплей, игроки будут бугуртить с читов;
- соревнования: очевидно, будет бугурт, если читеры обходят всех в таблицах лидеров и нагибают нубов;
- гача-игры: чтобы не собрали всех тянок за 1 день, а заходили каждый день гриндить или донатить.
В остальном, на читеров насрать. Если игрок играет с читером - пускай играет, а если не хочет - просто отключается от него и играет с кем-то другим. Если игроки создают свои сервера, они имеют полное право создавать сервера специально для читеров.
Хуже читеров только анти-читы, которые банят всех подряд за "подозрительные" действия. Лучше пускай читеры балуются, но играют, а не так, что у тебя 90% плеербазы парится в бане за какую-то мелочь вроде неправильно установленного драйвера мыши.
Алсо, для создания читов не обязательно получать доступ к исходному коду игры. Если изучить трафик между игрой и сервером, можно встроить читы, что подделывают трафик, обманывая сервер. Конечно, трафик может быть зашифрован, но ключи-то где-то лежат, и хакеру достаточно узнать, в какой момент сервер с клиентом договариваются о ключах. Таким образом создаются сторонние клиенты и сторонние серверы вместо официальных, без декомпиляции.
>>4479
Потому что сам по себе процесс декомпиляции не является чем-то плохим. Компиляция - это перевод с одного компьютерного языка на другой. Вот можно перевести с русского на английский - и это легально, почему тогда должно быть нелегально переводить с английского на русский? Тут та же тема. Ты можешь перевести с машинного кода на скриптовый язык - проблемы нет, кроме лицензионного соглашения между тобой и создателем этого кода. Что это за лицензионное соглашение? Автор статьи в блоге в интернете, например, может написать "я запрещаю переводить мои статьи на другие языки" - и тогда ты нарушаешь с ним соглашение, если переводишь. Но следить за исполнением должен сам автор статьи.
Т.е. публикуя программу, даже если она в машинном коде, ты публикуешь литературное произведение с легальной точки зрения. Ну или как-то так было всего несколько лет назад. Я не юрист, просто читал статьи.
Так же как и с переводом текстов на естественных языках, есть легальные сферы применения данных инструментов и нелегальные. Тот факт, что часть авторов против перевода их статьи на другой язык, не делает все автопереводчики нелегальными.
Защитить от чего? От чтения? Тогда не публикуй.
>>4490
Скорее всего, у тебя там потешные костыли, которые никому не нужны. Ты бы лучше боялся, что над твоей программой смеяться будут (как над ЯндереДевом).
>хакер просто уберет аннотацию и вызовет ее сам, прибавив себе сотни нефти
>вся логика закрыта в сервере
Это тебя должно заботить только если ты делаешь:
- ММО: потому что у тебя вся экономика завязана на честный геймплей, игроки будут бугуртить с читов;
- соревнования: очевидно, будет бугурт, если читеры обходят всех в таблицах лидеров и нагибают нубов;
- гача-игры: чтобы не собрали всех тянок за 1 день, а заходили каждый день гриндить или донатить.
В остальном, на читеров насрать. Если игрок играет с читером - пускай играет, а если не хочет - просто отключается от него и играет с кем-то другим. Если игроки создают свои сервера, они имеют полное право создавать сервера специально для читеров.
Хуже читеров только анти-читы, которые банят всех подряд за "подозрительные" действия. Лучше пускай читеры балуются, но играют, а не так, что у тебя 90% плеербазы парится в бане за какую-то мелочь вроде неправильно установленного драйвера мыши.
Алсо, для создания читов не обязательно получать доступ к исходному коду игры. Если изучить трафик между игрой и сервером, можно встроить читы, что подделывают трафик, обманывая сервер. Конечно, трафик может быть зашифрован, но ключи-то где-то лежат, и хакеру достаточно узнать, в какой момент сервер с клиентом договариваются о ключах. Таким образом создаются сторонние клиенты и сторонние серверы вместо официальных, без декомпиляции.
>>4479
>И почему декомпилировать легально?
Потому что сам по себе процесс декомпиляции не является чем-то плохим. Компиляция - это перевод с одного компьютерного языка на другой. Вот можно перевести с русского на английский - и это легально, почему тогда должно быть нелегально переводить с английского на русский? Тут та же тема. Ты можешь перевести с машинного кода на скриптовый язык - проблемы нет, кроме лицензионного соглашения между тобой и создателем этого кода. Что это за лицензионное соглашение? Автор статьи в блоге в интернете, например, может написать "я запрещаю переводить мои статьи на другие языки" - и тогда ты нарушаешь с ним соглашение, если переводишь. Но следить за исполнением должен сам автор статьи.
Т.е. публикуя программу, даже если она в машинном коде, ты публикуешь литературное произведение с легальной точки зрения. Ну или как-то так было всего несколько лет назад. Я не юрист, просто читал статьи.
>какие-то проекты публичные для этого есть?
Так же как и с переводом текстов на естественных языках, есть легальные сферы применения данных инструментов и нелегальные. Тот факт, что часть авторов против перевода их статьи на другой язык, не делает все автопереводчики нелегальными.
>защитить кусочек своего кода?
Защитить от чего? От чтения? Тогда не публикуй.
>>4490
>чтобы мой код читали, там 360 айкью
Скорее всего, у тебя там потешные костыли, которые никому не нужны. Ты бы лучше боялся, что над твоей программой смеяться будут (как над ЯндереДевом).
>>4435
Это тебя должно заботить только если ты делаешь:
- ММО: потому что у тебя вся экономика завязана на честный геймплей, игроки будут бугуртить с читов;
- соревнования: очевидно, будет бугурт, если читеры обходят всех в таблицах лидеров и нагибают нубов;
- гача-игры: чтобы не собрали всех тянок за 1 день, а заходили каждый день гриндить или донатить.
В остальном, на читеров насрать. Если игрок играет с читером - пускай играет, а если не хочет - просто отключается от него и играет с кем-то другим. Если игроки создают свои сервера, они имеют полное право создавать сервера специально для читеров.
Хуже читеров только анти-читы, которые банят всех подряд за "подозрительные" действия. Лучше пускай читеры балуются, но играют, а не так, что у тебя 90% плеербазы парится в бане за какую-то мелочь вроде неправильно установленного драйвера мыши.
Алсо, для создания читов не обязательно получать доступ к исходному коду игры. Если изучить трафик между игрой и сервером, можно встроить читы, что подделывают трафик, обманывая сервер. Конечно, трафик может быть зашифрован, но ключи-то где-то лежат, и хакеру достаточно узнать, в какой момент сервер с клиентом договариваются о ключах. Таким образом создаются сторонние клиенты и сторонние серверы вместо официальных, без декомпиляции.
>>4479
Потому что сам по себе процесс декомпиляции не является чем-то плохим. Компиляция - это перевод с одного компьютерного языка на другой. Вот можно перевести с русского на английский - и это легально, почему тогда должно быть нелегально переводить с английского на русский? Тут та же тема. Ты можешь перевести с машинного кода на скриптовый язык - проблемы нет, кроме лицензионного соглашения между тобой и создателем этого кода. Что это за лицензионное соглашение? Автор статьи в блоге в интернете, например, может написать "я запрещаю переводить мои статьи на другие языки" - и тогда ты нарушаешь с ним соглашение, если переводишь. Но следить за исполнением должен сам автор статьи.
Т.е. публикуя программу, даже если она в машинном коде, ты публикуешь литературное произведение с легальной точки зрения. Ну или как-то так было всего несколько лет назад. Я не юрист, просто читал статьи.
Так же как и с переводом текстов на естественных языках, есть легальные сферы применения данных инструментов и нелегальные. Тот факт, что часть авторов против перевода их статьи на другой язык, не делает все автопереводчики нелегальными.
Защитить от чего? От чтения? Тогда не публикуй.
>>4490
Скорее всего, у тебя там потешные костыли, которые никому не нужны. Ты бы лучше боялся, что над твоей программой смеяться будут (как над ЯндереДевом).
>хакер просто уберет аннотацию и вызовет ее сам, прибавив себе сотни нефти
>вся логика закрыта в сервере
Это тебя должно заботить только если ты делаешь:
- ММО: потому что у тебя вся экономика завязана на честный геймплей, игроки будут бугуртить с читов;
- соревнования: очевидно, будет бугурт, если читеры обходят всех в таблицах лидеров и нагибают нубов;
- гача-игры: чтобы не собрали всех тянок за 1 день, а заходили каждый день гриндить или донатить.
В остальном, на читеров насрать. Если игрок играет с читером - пускай играет, а если не хочет - просто отключается от него и играет с кем-то другим. Если игроки создают свои сервера, они имеют полное право создавать сервера специально для читеров.
Хуже читеров только анти-читы, которые банят всех подряд за "подозрительные" действия. Лучше пускай читеры балуются, но играют, а не так, что у тебя 90% плеербазы парится в бане за какую-то мелочь вроде неправильно установленного драйвера мыши.
Алсо, для создания читов не обязательно получать доступ к исходному коду игры. Если изучить трафик между игрой и сервером, можно встроить читы, что подделывают трафик, обманывая сервер. Конечно, трафик может быть зашифрован, но ключи-то где-то лежат, и хакеру достаточно узнать, в какой момент сервер с клиентом договариваются о ключах. Таким образом создаются сторонние клиенты и сторонние серверы вместо официальных, без декомпиляции.
>>4479
>И почему декомпилировать легально?
Потому что сам по себе процесс декомпиляции не является чем-то плохим. Компиляция - это перевод с одного компьютерного языка на другой. Вот можно перевести с русского на английский - и это легально, почему тогда должно быть нелегально переводить с английского на русский? Тут та же тема. Ты можешь перевести с машинного кода на скриптовый язык - проблемы нет, кроме лицензионного соглашения между тобой и создателем этого кода. Что это за лицензионное соглашение? Автор статьи в блоге в интернете, например, может написать "я запрещаю переводить мои статьи на другие языки" - и тогда ты нарушаешь с ним соглашение, если переводишь. Но следить за исполнением должен сам автор статьи.
Т.е. публикуя программу, даже если она в машинном коде, ты публикуешь литературное произведение с легальной точки зрения. Ну или как-то так было всего несколько лет назад. Я не юрист, просто читал статьи.
>какие-то проекты публичные для этого есть?
Так же как и с переводом текстов на естественных языках, есть легальные сферы применения данных инструментов и нелегальные. Тот факт, что часть авторов против перевода их статьи на другой язык, не делает все автопереводчики нелегальными.
>защитить кусочек своего кода?
Защитить от чего? От чтения? Тогда не публикуй.
>>4490
>чтобы мой код читали, там 360 айкью
Скорее всего, у тебя там потешные костыли, которые никому не нужны. Ты бы лучше боялся, что над твоей программой смеяться будут (как над ЯндереДевом).
>>4581
У тебя травма какая-то? Над тобой смеялись? Скажи мне кто и я заспамлю их игры негативным отзывами!
> Ты бы лучше боялся, что над твоей программой смеяться будут (как над ЯндереДевом).
У тебя травма какая-то? Над тобой смеялись? Скажи мне кто и я заспамлю их игры негативным отзывами!
>>4579
Да, я про 4.3 и говорил. Он большие файлы даже с компрессией экспортирует.
Да, я про 4.3 и говорил. Он большие файлы даже с компрессией экспортирует.
>>4571
Можно для начала почитать документацию:
https://docs.godotengine.org/en/stable/contributing/development/compiling/optimizing_for_size.html
1. Делаешь игру на официальной сборке.
2. Определяешь, что из зависимостей нужно.
3. Удаляешь всё остальное по ссылке выше.
4. Публикуешь кастомный билд.
5. Если в будущем потребуется что-то из того, что ты удалил, делаешь новый билд с этой зависимостью.
Это в разжатом виде, в сжатом около 50 Мб. Если в файловой системе включено сжатие, то меньше 100.
Это по-прежнему самый компактный движок из универсальных "всё включено" с удобными GUI инструментами и малым числом багов. После перехода на 4.0 движок раздуло из-за того, что поторопились выкатить новейший вулкан, и до 4.2 фокус был на багфиксах, теперь (4.3-4.4+) обещают уделять больше внимания оптимизации размера.
>прохудить экспорт проекта без потерь
Можно для начала почитать документацию:
https://docs.godotengine.org/en/stable/contributing/development/compiling/optimizing_for_size.html
>каких-нибудь возможных зависимостей
1. Делаешь игру на официальной сборке.
2. Определяешь, что из зависимостей нужно.
3. Удаляешь всё остальное по ссылке выше.
4. Публикуешь кастомный билд.
5. Если в будущем потребуется что-то из того, что ты удалил, делаешь новый билд с этой зависимостью.
>100 мб
Это в разжатом виде, в сжатом около 50 Мб. Если в файловой системе включено сжатие, то меньше 100.
>Блоатварь
Это по-прежнему самый компактный движок из универсальных "всё включено" с удобными GUI инструментами и малым числом багов. После перехода на 4.0 движок раздуло из-за того, что поторопились выкатить новейший вулкан, и до 4.2 фокус был на багфиксах, теперь (4.3-4.4+) обещают уделять больше внимания оптимизации размера.
>>4583
Звучит как диагноз. Земля тебе донатами, товарищ...
Если серьёзно:
1. Соревновательным играм нужен чёткий баланс и дорогущий маркетинг, иначе просто не взлетит.
2. ММО и гачам нужно доставлять новый контент ежемесячно, иначе игрокам надоест и разбегутся.
И это не говоря об общих проблемах мультиплеера...
Даже более-менее крупные команды проигрывают. Да что там, даже ААА проваливаются. В соло или с парой друзей такое тащить на себе нереально. Если, конечно, не называть ММО сервер на 3.5 игрока...
>у меня соревновательная ммо гача
Звучит как диагноз. Земля тебе донатами, товарищ...
Если серьёзно:
1. Соревновательным играм нужен чёткий баланс и дорогущий маркетинг, иначе просто не взлетит.
2. ММО и гачам нужно доставлять новый контент ежемесячно, иначе игрокам надоест и разбегутся.
И это не говоря об общих проблемах мультиплеера...
Даже более-менее крупные команды проигрывают. Да что там, даже ААА проваливаются. В соло или с парой друзей такое тащить на себе нереально. Если, конечно, не называть ММО сервер на 3.5 игрока...
>>4592
Ну ладно, про соревновательную я пошутил. Хотя, лидерборд можно прикрутить для мотивации. Контента готово на несколько лет вперед, успевать бы все вставлять...
Ну ладно, про соревновательную я пошутил. Хотя, лидерборд можно прикрутить для мотивации. Контента готово на несколько лет вперед, успевать бы все вставлять...
>>4589
Внезапно. Не ждал, что такая тема затрагивается в документации. Документация вообще мне редко помогала. Прошлый раз ее читал, когда хотел разобраться с тем, как оформлять обновления в маленькие сорт оф diff PCK-файлы, а не выкатывать перекомпилированный исполняемый файл с перекомпилированным и полным PCK. Ответа там я не нашел, пришлось обидеться на оф. документацию. Такая вот история. Но вообще у кого-то чего-то спрашивать обычно не моя стратегия, я просто сегодня бездельничаю. Зашел вот к вам.
Движка билд? Зачем публиковать?
У меня в сжимающейся btrfs сотню показывает. Или ты другое имеешь в виду?
Разумеется. Я считаю его лучшим из предложенных, и учитывая проприетарные, разумеется. Но всегда можно лучше.
Это чудесно, я очень рад таким новостям. Неиронично.
>Можно для начала почитать документацию
Внезапно. Не ждал, что такая тема затрагивается в документации. Документация вообще мне редко помогала. Прошлый раз ее читал, когда хотел разобраться с тем, как оформлять обновления в маленькие сорт оф diff PCK-файлы, а не выкатывать перекомпилированный исполняемый файл с перекомпилированным и полным PCK. Ответа там я не нашел, пришлось обидеться на оф. документацию. Такая вот история. Но вообще у кого-то чего-то спрашивать обычно не моя стратегия, я просто сегодня бездельничаю. Зашел вот к вам.
>4. Публикуешь кастомный билд.
Движка билд? Зачем публиковать?
>Если в файловой системе включено сжатие, то меньше 100.
У меня в сжимающейся btrfs сотню показывает. Или ты другое имеешь в виду?
>Это по-прежнему самый компактный движок из универсальных "всё включено"
Разумеется. Я считаю его лучшим из предложенных, и учитывая проприетарные, разумеется. Но всегда можно лучше.
>теперь (4.3-4.4+) обещают уделять больше внимания оптимизации размера.
Это чудесно, я очень рад таким новостям. Неиронично.
>>4589
А, спасибо забыл сказать. Спасибо.
А, спасибо забыл сказать. Спасибо.
>>4571
Зависимости чего от чего? Ты о чем вообще? Если у тебя 99% занимает .exe, то ты его перекомпилировать только можешь, а там модули и так независимые.
Алсо, https://docs.godotengine.org/en/stable/contributing/development/compiling/optimizing_for_size.html
Зависимости чего от чего? Ты о чем вообще? Если у тебя 99% занимает .exe, то ты его перекомпилировать только можешь, а там модули и так независимые.
Алсо, https://docs.godotengine.org/en/stable/contributing/development/compiling/optimizing_for_size.html
>>4602
Патчи можно делать и внешней утилитой, вообще то. А экзешник и не перекомпилируется при экспорте, он просто копируется тот же самый.
Патчи можно делать и внешней утилитой, вообще то. А экзешник и не перекомпилируется при экспорте, он просто копируется тот же самый.
>>4606
Да, мне скинули уже эту ссылку. Спасибо.
Ну вот как параграф по ссылке, например - зарезать 3D за ненужность в 2D игре. Ну или физику движковую. Я ее не использую тоже. Напрямую, по крайней мере.
>>4610
Какой?
А я по-другому считаю.
Да, мне скинули уже эту ссылку. Спасибо.
>Зависимости чего от чего?
>модули и так независимые
Ну вот как параграф по ссылке, например - зарезать 3D за ненужность в 2D игре. Ну или физику движковую. Я ее не использую тоже. Напрямую, по крайней мере.
>>4610
>Патчи можно делать и внешней утилитой
Какой?
>экзешник и не перекомпилируется при экспорте, он просто копируется тот же самый.
А я по-другому считаю.
>>4602
Стабильная версия:
https://docs.godotengine.org/en/stable/tutorials/export/exporting_pcks.html
Версия времён динозавров:
https://docs.godotengine.org/en/3.1/getting_started/workflow/export/exporting_pcks.html
Ты ж игру вместе с движком публикуешь обычно.
Я про NTFS в Windows, точно число не помню.
Тогда делай proposals, pull requests, issues и т.д.
>>4610
Там, вроде, есть нюансы:
- можно менять иконку и другие записи в exe;
- можно склеить pck и exe в один файл;
- для Android процесс намного сложнее.
>маленькие сорт оф diff PCK-файлы
Стабильная версия:
https://docs.godotengine.org/en/stable/tutorials/export/exporting_pcks.html
Версия времён динозавров:
https://docs.godotengine.org/en/3.1/getting_started/workflow/export/exporting_pcks.html
>Движка билд? Зачем публиковать?
Ты ж игру вместе с движком публикуешь обычно.
>btrfs
Я про NTFS в Windows, точно число не помню.
>Но всегда можно лучше.
Тогда делай proposals, pull requests, issues и т.д.
>>4610
>просто копируется тот же самый.
Там, вроде, есть нюансы:
- можно менять иконку и другие записи в exe;
- можно склеить pck и exe в один файл;
- для Android процесс намного сложнее.
>>4613
Да, именно за эту страничку я и обиделся. Это надо в релизе с расчетом на последующие патчи и багфиксы писать код на подгруз дополнительных PCK с конкретным именами и в случае их наличия. Глупость полная. Ну если я, конечно, правильно все понял. Можно было бы просто заменять маленькие бинарники, а не плодить архивы патчей в корне. Меня вообще идея одного исполняемого файла и архива с незнакомым (для конечного пользователя) расширением в директории софтинки всегда пугала. А один большой исполняемый файл это еще страшнее. Но это наверно не все поймут. Я сам не понимаю.
А, ты про это. Теперь ясно.
Естественно.
>https://docs.godotengine.org/en/stable/tutorials/export/exporting_pcks.html
Да, именно за эту страничку я и обиделся. Это надо в релизе с расчетом на последующие патчи и багфиксы писать код на подгруз дополнительных PCK с конкретным именами и в случае их наличия. Глупость полная. Ну если я, конечно, правильно все понял. Можно было бы просто заменять маленькие бинарники, а не плодить архивы патчей в корне. Меня вообще идея одного исполняемого файла и архива с незнакомым (для конечного пользователя) расширением в директории софтинки всегда пугала. А один большой исполняемый файл это еще страшнее. Но это наверно не все поймут. Я сам не понимаю.
>Ты ж игру вместе с движком публикуешь обычно.
А, ты про это. Теперь ясно.
>Тогда делай proposals, pull requests, issues и т.д.
Естественно.
>>4616
Нет. Это избавляет от головной боли, когда движок автоматически вместо тебя какую-то фигню грузит у пользователя и ломается, а ты не понимаешь, в чём проблема может быть. Сейчас ты полностью сам контролируешь, что и когда тебе нужно загрузить.
Можешь в любой другой папке их хранить. Знаешь, как обновляется GTA Online? Они выпускают много бесплатных обновлений, которые создают в папке с игрой дополнительные папки с "DLC". Отказаться от этого невозможно, если хочешь играть онлайн.
Все игровые движки обычно делают что-то похожее. Причин этому довольно много, перечислять долго.
Хех, погугли "llamafile", почитай что там пишут.
Вообще, с Godot ты можешь распространять свою игру как распакованный проект. Т.е. тебе не нужно упаковывать игру в pck, достаточно вложить в папку проекта движок, запаковать папку в zip и кидать её игрокам через файлообменник или площадку. Да, конечно, они смогут прочитать и изменить все твои исходники, но разве ты не этого хочешь? Некоторые древние игры на ПК так и распространялись, и часть древних движков сохранила эту возможность - т.е. считывают голые .png, .obj, скрипты и т.д.
В таком случае "патч" у тебя будет крайне прост - распаковать zip-файл в папку игры с заменой.
Алсо, площадки вроде Стим предоставляют свои инструменты для патчей. Не знаю, как это работает.
>Глупость полная.
Нет. Это избавляет от головной боли, когда движок автоматически вместо тебя какую-то фигню грузит у пользователя и ломается, а ты не понимаешь, в чём проблема может быть. Сейчас ты полностью сам контролируешь, что и когда тебе нужно загрузить.
>не плодить архивы патчей в корне
Можешь в любой другой папке их хранить. Знаешь, как обновляется GTA Online? Они выпускают много бесплатных обновлений, которые создают в папке с игрой дополнительные папки с "DLC". Отказаться от этого невозможно, если хочешь играть онлайн.
>Меня вообще идея одного исполняемого файла и архива с незнакомым (для конечного пользователя) расширением в директории софтинки всегда пугала.
Все игровые движки обычно делают что-то похожее. Причин этому довольно много, перечислять долго.
>большой исполняемый файл это еще страшнее
Хех, погугли "llamafile", почитай что там пишут.
Вообще, с Godot ты можешь распространять свою игру как распакованный проект. Т.е. тебе не нужно упаковывать игру в pck, достаточно вложить в папку проекта движок, запаковать папку в zip и кидать её игрокам через файлообменник или площадку. Да, конечно, они смогут прочитать и изменить все твои исходники, но разве ты не этого хочешь? Некоторые древние игры на ПК так и распространялись, и часть древних движков сохранила эту возможность - т.е. считывают голые .png, .obj, скрипты и т.д.
В таком случае "патч" у тебя будет крайне прост - распаковать zip-файл в папку игры с заменой.
Алсо, площадки вроде Стим предоставляют свои инструменты для патчей. Не знаю, как это работает.
>>4518
Спасибо!
Спасибо!
>>4632
Да понятно, конечно, что у этого есть свои плюсы. Но я б хотел по-другому. Почему не сделать, как хочу я?
Да ничего удивительного, наверно, что это не пойми во что превратилось, учитывая столь длительный жизненный цикл игры.
Разве? А по-моему в общем случае игра/программа это директорая, внутри которой много других директорий с бинарниками и прочими ресурсами. И распаковать патч в такую директорию рука прям чешется. Ты же понимаешь наверняка, что это просто звучит правильно и понятно. Вообще я осознаю, что болтаю и жалуюсь буквально ни о чем, ведь большинству игроков будет плевать на то, как это устроено изнутри - их устроит и огромный стандалон .exe на винде, .appimage на линуксе или .app на макоси.
Модели это не так страшно. А вот если бы это были .exe на 30 гигов, меня б удар хватил.
О, вот это прям открытие. Сейчас попробовал. Работает и правда. Заметил очень много ошибок в терминале. Думал, что экспортировал чего не так. А нет, эти ошибки просто не крашат игру и висели в дебаггере все время. Плохой я разработчик.
А вот не знаю, если честно. Я очень люблю FOSS и пользуюсь эксклюзивно свободным ПО, но это, как понимаешь, не может относиться к играм, потому что опенсорс игр просто нет. Так сложилось. И я уже могу имаджинировать как рескины моей игры продают в стиме за 30 рублей. Мои действия? Пишу на почту Free Software Foundation и жалуюсь на то, что меня буллят в интернете, нарушая GPL. Печально все это.
Да, хотелось бы еще иметь подобную возможность и у скомпилированной и ужатой игры.
Интересно, не слышал о таком.
В любом случае, удовлетворительный выход из этой ситуации я найду. Я люблю жаловаться и искать недостатки во всяком, даже в любимых своих штуках. Ты слишком стараешься мне помочь, это необязательно. Но я очень это ценю, спасибо!
>Это избавляет от головной боли
>Сейчас ты полностью сам контролируешь, что и когда тебе нужно загрузить.
Да понятно, конечно, что у этого есть свои плюсы. Но я б хотел по-другому. Почему не сделать, как хочу я?
>Знаешь, как обновляется GTA Online?
Да ничего удивительного, наверно, что это не пойми во что превратилось, учитывая столь длительный жизненный цикл игры.
>Все игровые движки обычно делают что-то похожее.
Разве? А по-моему в общем случае игра/программа это директорая, внутри которой много других директорий с бинарниками и прочими ресурсами. И распаковать патч в такую директорию рука прям чешется. Ты же понимаешь наверняка, что это просто звучит правильно и понятно. Вообще я осознаю, что болтаю и жалуюсь буквально ни о чем, ведь большинству игроков будет плевать на то, как это устроено изнутри - их устроит и огромный стандалон .exe на винде, .appimage на линуксе или .app на макоси.
>Хех, погугли "llamafile", почитай что там пишут.
Модели это не так страшно. А вот если бы это были .exe на 30 гигов, меня б удар хватил.
>Вообще, с Godot ты можешь распространять свою игру как распакованный проект.
О, вот это прям открытие. Сейчас попробовал. Работает и правда. Заметил очень много ошибок в терминале. Думал, что экспортировал чего не так. А нет, эти ошибки просто не крашат игру и висели в дебаггере все время. Плохой я разработчик.
>они смогут прочитать и изменить все твои исходники, но разве ты не этого хочешь?
А вот не знаю, если честно. Я очень люблю FOSS и пользуюсь эксклюзивно свободным ПО, но это, как понимаешь, не может относиться к играм, потому что опенсорс игр просто нет. Так сложилось. И я уже могу имаджинировать как рескины моей игры продают в стиме за 30 рублей. Мои действия? Пишу на почту Free Software Foundation и жалуюсь на то, что меня буллят в интернете, нарушая GPL. Печально все это.
>В таком случае "патч" у тебя будет крайне прост - распаковать zip-файл в папку игры с заменой.
Да, хотелось бы еще иметь подобную возможность и у скомпилированной и ужатой игры.
>площадки вроде Стим предоставляют свои инструменты для патчей.
Интересно, не слышал о таком.
В любом случае, удовлетворительный выход из этой ситуации я найду. Я люблю жаловаться и искать недостатки во всяком, даже в любимых своих штуках. Ты слишком стараешься мне помочь, это необязательно. Но я очень это ценю, спасибо!
>>4632
Да понятно, конечно, что у этого есть свои плюсы. Но я б хотел по-другому. Почему не сделать, как хочу я?
Да ничего удивительного, наверно, что это не пойми во что превратилось, учитывая столь длительный жизненный цикл игры.
Разве? А по-моему в общем случае игра/программа это директорая, внутри которой много других директорий с бинарниками и прочими ресурсами. И распаковать патч в такую директорию рука прям чешется. Ты же понимаешь наверняка, что это просто звучит правильно и понятно. Вообще я осознаю, что болтаю и жалуюсь буквально ни о чем, ведь большинству игроков будет плевать на то, как это устроено изнутри - их устроит и огромный стандалон .exe на винде, .appimage на линуксе или .app на макоси.
Модели это не так страшно. А вот если бы это были .exe на 30 гигов, меня б удар хватил.
О, вот это прям открытие. Сейчас попробовал. Работает и правда. Заметил очень много ошибок в терминале. Думал, что экспортировал чего не так. А нет, эти ошибки просто не крашат игру и висели в дебаггере все время. Плохой я разработчик.
А вот не знаю, если честно. Я очень люблю FOSS и пользуюсь эксклюзивно свободным ПО, но это, как понимаешь, не может относиться к играм, потому что опенсорс игр просто нет. Так сложилось. И я уже могу имаджинировать как рескины моей игры продают в стиме за 30 рублей. Мои действия? Пишу на почту Free Software Foundation и жалуюсь на то, что меня буллят в интернете, нарушая GPL. Печально все это.
Да, хотелось бы еще иметь подобную возможность и у скомпилированной и ужатой игры.
Интересно, не слышал о таком.
В любом случае, удовлетворительный выход из этой ситуации я найду. Я люблю жаловаться и искать недостатки во всяком, даже в любимых своих штуках. Ты слишком стараешься мне помочь, это необязательно. Но я очень это ценю, спасибо!
>Это избавляет от головной боли
>Сейчас ты полностью сам контролируешь, что и когда тебе нужно загрузить.
Да понятно, конечно, что у этого есть свои плюсы. Но я б хотел по-другому. Почему не сделать, как хочу я?
>Знаешь, как обновляется GTA Online?
Да ничего удивительного, наверно, что это не пойми во что превратилось, учитывая столь длительный жизненный цикл игры.
>Все игровые движки обычно делают что-то похожее.
Разве? А по-моему в общем случае игра/программа это директорая, внутри которой много других директорий с бинарниками и прочими ресурсами. И распаковать патч в такую директорию рука прям чешется. Ты же понимаешь наверняка, что это просто звучит правильно и понятно. Вообще я осознаю, что болтаю и жалуюсь буквально ни о чем, ведь большинству игроков будет плевать на то, как это устроено изнутри - их устроит и огромный стандалон .exe на винде, .appimage на линуксе или .app на макоси.
>Хех, погугли "llamafile", почитай что там пишут.
Модели это не так страшно. А вот если бы это были .exe на 30 гигов, меня б удар хватил.
>Вообще, с Godot ты можешь распространять свою игру как распакованный проект.
О, вот это прям открытие. Сейчас попробовал. Работает и правда. Заметил очень много ошибок в терминале. Думал, что экспортировал чего не так. А нет, эти ошибки просто не крашат игру и висели в дебаггере все время. Плохой я разработчик.
>они смогут прочитать и изменить все твои исходники, но разве ты не этого хочешь?
А вот не знаю, если честно. Я очень люблю FOSS и пользуюсь эксклюзивно свободным ПО, но это, как понимаешь, не может относиться к играм, потому что опенсорс игр просто нет. Так сложилось. И я уже могу имаджинировать как рескины моей игры продают в стиме за 30 рублей. Мои действия? Пишу на почту Free Software Foundation и жалуюсь на то, что меня буллят в интернете, нарушая GPL. Печально все это.
>В таком случае "патч" у тебя будет крайне прост - распаковать zip-файл в папку игры с заменой.
Да, хотелось бы еще иметь подобную возможность и у скомпилированной и ужатой игры.
>площадки вроде Стим предоставляют свои инструменты для патчей.
Интересно, не слышал о таком.
В любом случае, удовлетворительный выход из этой ситуации я найду. Я люблю жаловаться и искать недостатки во всяком, даже в любимых своих штуках. Ты слишком стараешься мне помочь, это необязательно. Но я очень это ценю, спасибо!
>>4639
Сейчас разрабы всяких nethack, battle for wesnoth и cataclysm dda охуели
>опенсорс игр просто нет
Сейчас разрабы всяких nethack, battle for wesnoth и cataclysm dda охуели
>>4639
А вслед за упомянутыми выше олдами. охуели тысячи современных разрабов, которые открывают исходники на джемах типа Ludum dare
А вслед за упомянутыми выше олдами. охуели тысячи современных разрабов, которые открывают исходники на джемах типа Ludum dare
184 Кб, 349x337>>4639
Буквально каждые выходные гоняю в опенсорсный пикрил.
Буквально каждые выходные гоняю в опенсорсный пикрил.
>>4611
Ну например itch.io/butler умеет делать локальные патчи, а не только отправлять на итч. Лицензия MIT.
Да вообще на гитхабе вылезает много Game Patcher
По большому счету, это то что делает diff/patch в линуксе или git merge. Копирует совпадающие части файла и заменяет отличающиеся.
А ты мог бы просто побайтово сравнить после экспорта.
Ну считать то ты можешь конечно, только компилятор с++ с либами для сборки весил бы пару гигов, а не 100мб. Игрушечные компиляторы не рассматриваем.
Да и вообще, вместо шаблона экспорта, можно подложить в папку с .pck сам редактор годота и так же все будет работать.
Да это правда, я такие нюансы не стал рассматривать. Это примитивная операция над бинарником - развинуть место между заголовком и блоками кода, втиснуть картинку, подправить смещения-указатели.
>>4632
Написано что он разрезает файл на 1Мб кусочки и потом отправляет только изменившиеся мегабайты. Понятно что это не работает с zip или шифрованым файлом, так как он будет перефаршировываться целиком, также будет плохо если куски сильно переезжают - текстура была вначале, стала в конце. А потом эти кусочки уже на стороне стима сжимаются и шифруются. Хз честно говоря, какой формат у .pck в этом плане.
>>4639
В крупных играх так не делают, там какой нибудь один .dat. Скорее всего файловая система дает оверхед, поэтому программистам проще написать свою структуру, а там глядишь и файл получится просто memory map в память подгрузить. Да и своего шифрования можно навернуть. (Но шифрование конфликтует с патчами...)
>>Патчи можно делать и внешней утилитой
>Какой?
Ну например itch.io/butler умеет делать локальные патчи, а не только отправлять на итч. Лицензия MIT.
Да вообще на гитхабе вылезает много Game Patcher
По большому счету, это то что делает diff/patch в линуксе или git merge. Копирует совпадающие части файла и заменяет отличающиеся.
>>экзешник и не перекомпилируется при экспорте, он просто копируется тот же самый.
>А я по-другому считаю.
А ты мог бы просто побайтово сравнить после экспорта.
Ну считать то ты можешь конечно, только компилятор с++ с либами для сборки весил бы пару гигов, а не 100мб. Игрушечные компиляторы не рассматриваем.
Да и вообще, вместо шаблона экспорта, можно подложить в папку с .pck сам редактор годота и так же все будет работать.
>можно менять иконку и другие записи в exe;
Да это правда, я такие нюансы не стал рассматривать. Это примитивная операция над бинарником - развинуть место между заголовком и блоками кода, втиснуть картинку, подправить смещения-указатели.
>>4632
>Стим предоставляют свои инструменты для патчей. Не знаю, как это работает.
Написано что он разрезает файл на 1Мб кусочки и потом отправляет только изменившиеся мегабайты. Понятно что это не работает с zip или шифрованым файлом, так как он будет перефаршировываться целиком, также будет плохо если куски сильно переезжают - текстура была вначале, стала в конце. А потом эти кусочки уже на стороне стима сжимаются и шифруются. Хз честно говоря, какой формат у .pck в этом плане.
>>4639
>А по-моему в общем случае игра/программа это директорая, внутри которой много других директорий с бинарниками и прочими ресурсами
В крупных играх так не делают, там какой нибудь один .dat. Скорее всего файловая система дает оверхед, поэтому программистам проще написать свою структуру, а там глядишь и файл получится просто memory map в память подгрузить. Да и своего шифрования можно навернуть. (Но шифрование конфликтует с патчами...)
>>4655
А я все это знал, я молодец.
А я все это знал, я молодец.
>>4655
Пункты 2,3,4 не знал. Спасибо.
Пункты 2,3,4 не знал. Спасибо.
47 Кб, 700x700>>4652
Это класс, только я попросил твоей рекомендации лично, не гитхаба.
Спасибо. Это то что надо.
А я сравниввл мд5 уже, потому что слышал про одинаковые экзешники в случае внешнего PCK на выходе. Поэтому и есть мнение. Но если вдруг в итоге окажется, что я не прав или чего-то не так проверял, то я ОЧЕНЬ сильно расстроюсь.
Буду считать. Но если тебя это будет беспокоить, то ты дай знать.
Ну ты молодец, конечно, много знаешь разного. А сам-то хоть раз кому-нибудь раздвигал место между бинарником и заголовком, втискивал свою картинку? А Ежи?
Не знаю, может мы о разных вещах говорим. цп2077 - наверно единственное, что я запускал свежее 2014-2015 года выпуска и смотрел примерно чего и как там выглядит в директории игры. Может быть, это недостаточно большая игра. Может, крупная игра это калофдути. С одним .dat-файлом на добрые 160 гб. Может, сейчас все делают, как ты сказал. Не могу знать.
>вообще на гитхабе вылезает много Game Patcher
Это класс, только я попросил твоей рекомендации лично, не гитхаба.
>itch.io/butler
>это то что делает diff/patch в линуксе или git merge
Спасибо. Это то что надо.
>А ты мог бы просто побайтово сравнить после экспорта.
А я сравниввл мд5 уже, потому что слышал про одинаковые экзешники в случае внешнего PCK на выходе. Поэтому и есть мнение. Но если вдруг в итоге окажется, что я не прав или чего-то не так проверял, то я ОЧЕНЬ сильно расстроюсь.
>Ну считать то ты можешь конечно
Буду считать. Но если тебя это будет беспокоить, то ты дай знать.
>я такие нюансы не стал рассматривать. Это примитивная операция над бинарником
>развинуть место между заголовком и блоками кода, втиснуть картинку, подправить смещения-указатели.
Ну ты молодец, конечно, много знаешь разного. А сам-то хоть раз кому-нибудь раздвигал место между бинарником и заголовком, втискивал свою картинку? А Ежи?
>В крупных играх так не делают
Не знаю, может мы о разных вещах говорим. цп2077 - наверно единственное, что я запускал свежее 2014-2015 года выпуска и смотрел примерно чего и как там выглядит в директории игры. Может быть, это недостаточно большая игра. Может, крупная игра это калофдути. С одним .dat-файлом на добрые 160 гб. Может, сейчас все делают, как ты сказал. Не могу знать.
115 Кб, 1010x775> >Вообще, с Godot ты можешь распространять свою игру как распакованный проект.
> О, вот это прям открытие.
Бля. Надо что-то с шапкой делать. Давайте думать. Предлагайте. Как бы нам сделать-то. Пакрасате.
Есть character3d, который при очень низкой скорости застревает на подъеме, в месте стыка пола и склона. Я могу повысить его минимально допустимую скорость и все станет ок. Еще я обнаружил что проблема застревания решается если я меняю max_slides в его свойствах на 1, и хочу узнать - чем это чревато?
8 Кб, 640x200>>4602
Пикрил. NTFS сжатие в Windows 10. Если из экспорта выбросить лишнее (3D, физика и т.д.) - будет меньше.
>>4639
Потому что... наверное, ты в меньшинстве? Т.к. если большинство что-то не устраивает - переделывают.
Во времена HDD было удобнее упаковывать все необходимые игре ресурсы в один большой файл, который располагается на диске одним куском (при условии частой дефрагментации диска системой) и считывается за один проход считывающей головки. Конечно же, для SSD такой трюк не нужен - любые данные считываются с одной скоростью. Но раньше приходилось не просто склеивать ресурсы в общий файл, но ещё и хитрым образом располагать, чтобы считывание было в порядке, который нужен игре...
А вообще, файлы и папки - абстракция только для удобства пользователя. Если тебе не нужно, чтобы пользователь копался в файлах игры - нет нужды разделять ресурсы игры на кучу файлов. Скорее наоборот, вредно разделять ресурсы на файлы, т.к. файловая система нагружается лишней для юзера информацией (имена файлов, их положение и т.д.). Например, архивы - просто файлы с точки зрения файловой системы, но любой менеджер архивов создаёт привычный GUI с кучей файлов и папок. Собственно, большой файл с ресурсами игры - это, обычно, и есть архив, только обычно без сжатия, и зачастую в специфичном для движка формате.
В Windows .exe не может быть больше 4 Гб, но вот на Линуксе, вроде бы, можно и 30 Гб. Лламафайл - это гигантский .exe с моделью внутри, хотя можно и без модели использовать. Но всё равно, в ML почему-то гигантские исполняемые файлы, DLL на гиг - это для них фигня, никогого такие масштабы не волнуют...
Впрочем, ничего удивительного, когда у всех уже терабайтовые SSD под игрушки...
По умолчанию эти ошибки пишутся в файл где-то в системе. Не знаю, где на Линуксе, но поищи в папке пользователя или где там обычно программы/игры хранят собственные "сохранения" (%appdata%).
Вообще-то есть, и довольно много. Есть даже срачи между разработчиками с расколом игры на набор независимых форков - всё в духе оперсурса.
Ну и что? Оперсурс позволяет так делать. Никто не запрещает сделать форк Godot и продавать его на отдельной странице, просто это никому не нужно.
Я таким образом прокрастинирую.
>>4664
С чем сравнивал? Главное, как экспортировал? Там специальные поля в исполняемом файле, где указан разработчик, адрес для баг-репортов, номер билда и подобное - Godot эти поля может перезаписать при желании. Тогда хэш-сумма будет отличаться. Но это необязательные операции для "запуска" .pck-файла.
Лично я - да, но только на Windows:
https://en.wikipedia.org/wiki/Resource_Hacker
Даже игру делал чисто на этих ресурсах (на Delphi).
Никто не говорит про один файл на 160 Гб. Ресурсы разрезают на отдельные файлы. Говорю же, глянь устройство GTA 5... Нет, даже GTA 3/VC/SA - там эти огромные .img-файлы - это архивы с ресурсами в специфическом формате (его давно расшифровали, используют специальные архиваторы для модов).
>>4665
Тщетно бытие, зумеры даже документацию больше не уважают, что им твоя шапка? Им нужно летсплей игроделания записать - со смешнявками и мемами.
https://docs.godotengine.org/en/stable/tutorials/editor/command_line_tutorial.html#running-the-game
Можно даже отдельные скрипты запускать, чтобы выполнять какие-то мелкие задачи а-ля Python.
>сжимающейся btrfs сотню показывает
Пикрил. NTFS сжатие в Windows 10. Если из экспорта выбросить лишнее (3D, физика и т.д.) - будет меньше.
>>4639
>Почему не сделать, как хочу я?
Потому что... наверное, ты в меньшинстве? Т.к. если большинство что-то не устраивает - переделывают.
>в общем случае игра/программа это директорая
Во времена HDD было удобнее упаковывать все необходимые игре ресурсы в один большой файл, который располагается на диске одним куском (при условии частой дефрагментации диска системой) и считывается за один проход считывающей головки. Конечно же, для SSD такой трюк не нужен - любые данные считываются с одной скоростью. Но раньше приходилось не просто склеивать ресурсы в общий файл, но ещё и хитрым образом располагать, чтобы считывание было в порядке, который нужен игре...
А вообще, файлы и папки - абстракция только для удобства пользователя. Если тебе не нужно, чтобы пользователь копался в файлах игры - нет нужды разделять ресурсы игры на кучу файлов. Скорее наоборот, вредно разделять ресурсы на файлы, т.к. файловая система нагружается лишней для юзера информацией (имена файлов, их положение и т.д.). Например, архивы - просто файлы с точки зрения файловой системы, но любой менеджер архивов создаёт привычный GUI с кучей файлов и папок. Собственно, большой файл с ресурсами игры - это, обычно, и есть архив, только обычно без сжатия, и зачастую в специфичном для движка формате.
>если бы это были .exe на 30 гигов
В Windows .exe не может быть больше 4 Гб, но вот на Линуксе, вроде бы, можно и 30 Гб. Лламафайл - это гигантский .exe с моделью внутри, хотя можно и без модели использовать. Но всё равно, в ML почему-то гигантские исполняемые файлы, DLL на гиг - это для них фигня, никогого такие масштабы не волнуют...
Впрочем, ничего удивительного, когда у всех уже терабайтовые SSD под игрушки...
>Заметил очень много ошибок в терминале.
По умолчанию эти ошибки пишутся в файл где-то в системе. Не знаю, где на Линуксе, но поищи в папке пользователя или где там обычно программы/игры хранят собственные "сохранения" (%appdata%).
>опенсорс игр просто нет
Вообще-то есть, и довольно много. Есть даже срачи между разработчиками с расколом игры на набор независимых форков - всё в духе оперсурса.
>рескины моей игры продают в стиме за 30 руб
Ну и что? Оперсурс позволяет так делать. Никто не запрещает сделать форк Godot и продавать его на отдельной странице, просто это никому не нужно.
>слишком стараешься мне помочь
Я таким образом прокрастинирую.
>>4664
>сравнивал мд5
С чем сравнивал? Главное, как экспортировал? Там специальные поля в исполняемом файле, где указан разработчик, адрес для баг-репортов, номер билда и подобное - Godot эти поля может перезаписать при желании. Тогда хэш-сумма будет отличаться. Но это необязательные операции для "запуска" .pck-файла.
>сам-то хоть раз кому-нибудь раздвигал место между бинарником и заголовком, втискивал свою картинку?
Лично я - да, но только на Windows:
https://en.wikipedia.org/wiki/Resource_Hacker
Даже игру делал чисто на этих ресурсах (на Delphi).
>С одним .dat-файлом на добрые 160 гб.
Никто не говорит про один файл на 160 Гб. Ресурсы разрезают на отдельные файлы. Говорю же, глянь устройство GTA 5... Нет, даже GTA 3/VC/SA - там эти огромные .img-файлы - это архивы с ресурсами в специфическом формате (его давно расшифровали, используют специальные архиваторы для модов).
>>4665
>Надо что-то с шапкой делать.
Тщетно бытие, зумеры даже документацию больше не уважают, что им твоя шапка? Им нужно летсплей игроделания записать - со смешнявками и мемами.
https://docs.godotengine.org/en/stable/tutorials/editor/command_line_tutorial.html#running-the-game
Можно даже отдельные скрипты запускать, чтобы выполнять какие-то мелкие задачи а-ля Python.
8 Кб, 640x200>>4602
Пикрил. NTFS сжатие в Windows 10. Если из экспорта выбросить лишнее (3D, физика и т.д.) - будет меньше.
>>4639
Потому что... наверное, ты в меньшинстве? Т.к. если большинство что-то не устраивает - переделывают.
Во времена HDD было удобнее упаковывать все необходимые игре ресурсы в один большой файл, который располагается на диске одним куском (при условии частой дефрагментации диска системой) и считывается за один проход считывающей головки. Конечно же, для SSD такой трюк не нужен - любые данные считываются с одной скоростью. Но раньше приходилось не просто склеивать ресурсы в общий файл, но ещё и хитрым образом располагать, чтобы считывание было в порядке, который нужен игре...
А вообще, файлы и папки - абстракция только для удобства пользователя. Если тебе не нужно, чтобы пользователь копался в файлах игры - нет нужды разделять ресурсы игры на кучу файлов. Скорее наоборот, вредно разделять ресурсы на файлы, т.к. файловая система нагружается лишней для юзера информацией (имена файлов, их положение и т.д.). Например, архивы - просто файлы с точки зрения файловой системы, но любой менеджер архивов создаёт привычный GUI с кучей файлов и папок. Собственно, большой файл с ресурсами игры - это, обычно, и есть архив, только обычно без сжатия, и зачастую в специфичном для движка формате.
В Windows .exe не может быть больше 4 Гб, но вот на Линуксе, вроде бы, можно и 30 Гб. Лламафайл - это гигантский .exe с моделью внутри, хотя можно и без модели использовать. Но всё равно, в ML почему-то гигантские исполняемые файлы, DLL на гиг - это для них фигня, никогого такие масштабы не волнуют...
Впрочем, ничего удивительного, когда у всех уже терабайтовые SSD под игрушки...
По умолчанию эти ошибки пишутся в файл где-то в системе. Не знаю, где на Линуксе, но поищи в папке пользователя или где там обычно программы/игры хранят собственные "сохранения" (%appdata%).
Вообще-то есть, и довольно много. Есть даже срачи между разработчиками с расколом игры на набор независимых форков - всё в духе оперсурса.
Ну и что? Оперсурс позволяет так делать. Никто не запрещает сделать форк Godot и продавать его на отдельной странице, просто это никому не нужно.
Я таким образом прокрастинирую.
>>4664
С чем сравнивал? Главное, как экспортировал? Там специальные поля в исполняемом файле, где указан разработчик, адрес для баг-репортов, номер билда и подобное - Godot эти поля может перезаписать при желании. Тогда хэш-сумма будет отличаться. Но это необязательные операции для "запуска" .pck-файла.
Лично я - да, но только на Windows:
https://en.wikipedia.org/wiki/Resource_Hacker
Даже игру делал чисто на этих ресурсах (на Delphi).
Никто не говорит про один файл на 160 Гб. Ресурсы разрезают на отдельные файлы. Говорю же, глянь устройство GTA 5... Нет, даже GTA 3/VC/SA - там эти огромные .img-файлы - это архивы с ресурсами в специфическом формате (его давно расшифровали, используют специальные архиваторы для модов).
>>4665
Тщетно бытие, зумеры даже документацию больше не уважают, что им твоя шапка? Им нужно летсплей игроделания записать - со смешнявками и мемами.
https://docs.godotengine.org/en/stable/tutorials/editor/command_line_tutorial.html#running-the-game
Можно даже отдельные скрипты запускать, чтобы выполнять какие-то мелкие задачи а-ля Python.
>сжимающейся btrfs сотню показывает
Пикрил. NTFS сжатие в Windows 10. Если из экспорта выбросить лишнее (3D, физика и т.д.) - будет меньше.
>>4639
>Почему не сделать, как хочу я?
Потому что... наверное, ты в меньшинстве? Т.к. если большинство что-то не устраивает - переделывают.
>в общем случае игра/программа это директорая
Во времена HDD было удобнее упаковывать все необходимые игре ресурсы в один большой файл, который располагается на диске одним куском (при условии частой дефрагментации диска системой) и считывается за один проход считывающей головки. Конечно же, для SSD такой трюк не нужен - любые данные считываются с одной скоростью. Но раньше приходилось не просто склеивать ресурсы в общий файл, но ещё и хитрым образом располагать, чтобы считывание было в порядке, который нужен игре...
А вообще, файлы и папки - абстракция только для удобства пользователя. Если тебе не нужно, чтобы пользователь копался в файлах игры - нет нужды разделять ресурсы игры на кучу файлов. Скорее наоборот, вредно разделять ресурсы на файлы, т.к. файловая система нагружается лишней для юзера информацией (имена файлов, их положение и т.д.). Например, архивы - просто файлы с точки зрения файловой системы, но любой менеджер архивов создаёт привычный GUI с кучей файлов и папок. Собственно, большой файл с ресурсами игры - это, обычно, и есть архив, только обычно без сжатия, и зачастую в специфичном для движка формате.
>если бы это были .exe на 30 гигов
В Windows .exe не может быть больше 4 Гб, но вот на Линуксе, вроде бы, можно и 30 Гб. Лламафайл - это гигантский .exe с моделью внутри, хотя можно и без модели использовать. Но всё равно, в ML почему-то гигантские исполняемые файлы, DLL на гиг - это для них фигня, никогого такие масштабы не волнуют...
Впрочем, ничего удивительного, когда у всех уже терабайтовые SSD под игрушки...
>Заметил очень много ошибок в терминале.
По умолчанию эти ошибки пишутся в файл где-то в системе. Не знаю, где на Линуксе, но поищи в папке пользователя или где там обычно программы/игры хранят собственные "сохранения" (%appdata%).
>опенсорс игр просто нет
Вообще-то есть, и довольно много. Есть даже срачи между разработчиками с расколом игры на набор независимых форков - всё в духе оперсурса.
>рескины моей игры продают в стиме за 30 руб
Ну и что? Оперсурс позволяет так делать. Никто не запрещает сделать форк Godot и продавать его на отдельной странице, просто это никому не нужно.
>слишком стараешься мне помочь
Я таким образом прокрастинирую.
>>4664
>сравнивал мд5
С чем сравнивал? Главное, как экспортировал? Там специальные поля в исполняемом файле, где указан разработчик, адрес для баг-репортов, номер билда и подобное - Godot эти поля может перезаписать при желании. Тогда хэш-сумма будет отличаться. Но это необязательные операции для "запуска" .pck-файла.
>сам-то хоть раз кому-нибудь раздвигал место между бинарником и заголовком, втискивал свою картинку?
Лично я - да, но только на Windows:
https://en.wikipedia.org/wiki/Resource_Hacker
Даже игру делал чисто на этих ресурсах (на Delphi).
>С одним .dat-файлом на добрые 160 гб.
Никто не говорит про один файл на 160 Гб. Ресурсы разрезают на отдельные файлы. Говорю же, глянь устройство GTA 5... Нет, даже GTA 3/VC/SA - там эти огромные .img-файлы - это архивы с ресурсами в специфическом формате (его давно расшифровали, используют специальные архиваторы для модов).
>>4665
>Надо что-то с шапкой делать.
Тщетно бытие, зумеры даже документацию больше не уважают, что им твоя шапка? Им нужно летсплей игроделания записать - со смешнявками и мемами.
https://docs.godotengine.org/en/stable/tutorials/editor/command_line_tutorial.html#running-the-game
Можно даже отдельные скрипты запускать, чтобы выполнять какие-то мелкие задачи а-ля Python.
>>4692
Добавлю что мои поверхностные тесты не выявили никаких проблем от единички. Но хуй его знает.
Добавлю что мои поверхностные тесты не выявили никаких проблем от единички. Но хуй его знает.
>>4692
Физику используешь встроенную?
Что ты используешь в роли коллизий?
- цилиндр: застревает уголком;
- капсула: застревает из-за трения;
- рейкаст: не застревает, но резко прыгает.
Попробуй посадить персонажа на рейкаст:
https://docs.godotengine.org/en/stable/classes/class_separationrayshape3d.html
Не знаю, никогда не менял. По идее, это нужно для избегания застревания в сложных ситуациях, скажем, когда твой персонаж упирается телом в угол между несколькими объектами и его начинает трясти.
Далеко не все параметры по умолчанию выбраны адекватно, так что не стоит считать их идеальными.
Физику используешь встроенную?
Что ты используешь в роли коллизий?
- цилиндр: застревает уголком;
- капсула: застревает из-за трения;
- рейкаст: не застревает, но резко прыгает.
Попробуй посадить персонажа на рейкаст:
https://docs.godotengine.org/en/stable/classes/class_separationrayshape3d.html
>max_slides в его свойствах на 1
Не знаю, никогда не менял. По идее, это нужно для избегания застревания в сложных ситуациях, скажем, когда твой персонаж упирается телом в угол между несколькими объектами и его начинает трясти.
Далеко не все параметры по умолчанию выбраны адекватно, так что не стоит считать их идеальными.
>>4695
Спасибо за ответ. В общем, это я сам проебался, смешав логику нахождения на полу и в воздухе. Как итог в точке стыка на персонажа слишком давило, и он не мог подняться при низкой скорости.
А max_slides потестил еще и понял что лучше не ставить его в 1 - все управление становится менее плавным, втыкаясь в углы проводишь в них больше времени прежде чем соскользнешь.
Спасибо за ответ. В общем, это я сам проебался, смешав логику нахождения на полу и в воздухе. Как итог в точке стыка на персонажа слишком давило, и он не мог подняться при низкой скорости.
А max_slides потестил еще и понял что лучше не ставить его в 1 - все управление становится менее плавным, втыкаясь в углы проводишь в них больше времени прежде чем соскользнешь.
9 Мб, mp4,754x440, 2:23
>>4400
Молодец. А когда пофиксишь скольжение ног?
Если правильно помню, твоя карта генерируется?
Что-нибудь читал/смотрел по дизайну уровней?
>>4568
Придумал вот как занерфить лебёдку.
Когда делал механику верёвки, заметил: слишком сложно забраться на край объекта, если не можешь зацепиться выше этого края. Это можно исправить по-разному... Но я решил просто усилить лебёдку до состояния, когда она способна подбросить игрока как минимум на один рост персонажа выше точки крепления верёвки. Мне это понравилось, но потом обнаружил, что такая мощная лебёдка позволяет ускоряться почти бесконечно и летать на огромной скорости. Короче, зажал кнопку и летишь.
На днях попробовал добавить спецэффект к работе лебёдки и эта проблема стала ещё острее. В итоге придумал сделать "перегрев" лебёдки. Каждый тик _physics_process изменяется параметр:
Если heat > 0.99, лебёдка отключается. Как можно догадаться, "...factor" равный 1 равен 1 секунде до "перегрева" или полного "охлаждения" лебёдки.
Всё ещё нужно сбалансировать, но смысл в том, что теперь нельзя тупо зажимать кнопку. Если реже используешь сматывание, то у тебя есть ≈1 секунда непрерывного ускорения без ожидания, а вот если постоянно дёргать кнопку, придётся часто кликать с ожиданием отката ("охлаждения") способности.
По сравнению с обычным кулдауном способности (после использования нужно ждать таймер отката), перегрев позволяет использовать эту способность сразу и расходовать рационально. По сравнению с накоплением заряда (когда шкала заполняется "энергией" способности) перегрев не стимулирует израсходовать весь заряд как можно раньше, ибо отсутствует эффект "недополученной прибыли": наоборот, есть стимул избегать лишней нагрузки.
Короче: код минимальный, но психологически это внезапно сложная тема. Я даже на счёт UI теперь сомневаюсь: наверное, лучше убрать полоску; как-то завязать яркость/объём частиц на уровень нагрева - минимальный нагрев = нет частиц, максимум = дым становится чёрным и резко прекращается. Нужно интуитивное что-то, что не будет отвлекать игрока.
Ещё короче - недостаточно знать движок, чтобы сделать собственную интересную игру...
Кстати, кто-нибудь знает, что теперь с инверсной кинематикой? Её обещали переделать вроде бы, и существующее решение было нестабильно. Хочу персонажа нормально анимировать, но как?..
>Сделал по итогу спавн когда камера заходит в область спавна челика/объекта, и теперь минимум 200 - 300 фпс есть на большой карте
Молодец. А когда пофиксишь скольжение ног?
Если правильно помню, твоя карта генерируется?
Что-нибудь читал/смотрел по дизайну уровней?
>>4568
>про устройство игр
Придумал вот как занерфить лебёдку.
Когда делал механику верёвки, заметил: слишком сложно забраться на край объекта, если не можешь зацепиться выше этого края. Это можно исправить по-разному... Но я решил просто усилить лебёдку до состояния, когда она способна подбросить игрока как минимум на один рост персонажа выше точки крепления верёвки. Мне это понравилось, но потом обнаружил, что такая мощная лебёдка позволяет ускоряться почти бесконечно и летать на огромной скорости. Короче, зажал кнопку и летишь.
На днях попробовал добавить спецэффект к работе лебёдки и эта проблема стала ещё острее. В итоге придумал сделать "перегрев" лебёдки. Каждый тик _physics_process изменяется параметр:
>heat += delta × (heat_rise_factor
>if state == State.REEL_IN # намотка
>else heat_drop_factor) # размотка/бездействие
Если heat > 0.99, лебёдка отключается. Как можно догадаться, "...factor" равный 1 равен 1 секунде до "перегрева" или полного "охлаждения" лебёдки.
Всё ещё нужно сбалансировать, но смысл в том, что теперь нельзя тупо зажимать кнопку. Если реже используешь сматывание, то у тебя есть ≈1 секунда непрерывного ускорения без ожидания, а вот если постоянно дёргать кнопку, придётся часто кликать с ожиданием отката ("охлаждения") способности.
По сравнению с обычным кулдауном способности (после использования нужно ждать таймер отката), перегрев позволяет использовать эту способность сразу и расходовать рационально. По сравнению с накоплением заряда (когда шкала заполняется "энергией" способности) перегрев не стимулирует израсходовать весь заряд как можно раньше, ибо отсутствует эффект "недополученной прибыли": наоборот, есть стимул избегать лишней нагрузки.
Короче: код минимальный, но психологически это внезапно сложная тема. Я даже на счёт UI теперь сомневаюсь: наверное, лучше убрать полоску; как-то завязать яркость/объём частиц на уровень нагрева - минимальный нагрев = нет частиц, максимум = дым становится чёрным и резко прекращается. Нужно интуитивное что-то, что не будет отвлекать игрока.
Ещё короче - недостаточно знать движок, чтобы сделать собственную интересную игру...
Кстати, кто-нибудь знает, что теперь с инверсной кинематикой? Её обещали переделать вроде бы, и существующее решение было нестабильно. Хочу персонажа нормально анимировать, но как?..
9 Мб, mp4,754x440, 2:23
>>4400
Молодец. А когда пофиксишь скольжение ног?
Если правильно помню, твоя карта генерируется?
Что-нибудь читал/смотрел по дизайну уровней?
>>4568
Придумал вот как занерфить лебёдку.
Когда делал механику верёвки, заметил: слишком сложно забраться на край объекта, если не можешь зацепиться выше этого края. Это можно исправить по-разному... Но я решил просто усилить лебёдку до состояния, когда она способна подбросить игрока как минимум на один рост персонажа выше точки крепления верёвки. Мне это понравилось, но потом обнаружил, что такая мощная лебёдка позволяет ускоряться почти бесконечно и летать на огромной скорости. Короче, зажал кнопку и летишь.
На днях попробовал добавить спецэффект к работе лебёдки и эта проблема стала ещё острее. В итоге придумал сделать "перегрев" лебёдки. Каждый тик _physics_process изменяется параметр:
Если heat > 0.99, лебёдка отключается. Как можно догадаться, "...factor" равный 1 равен 1 секунде до "перегрева" или полного "охлаждения" лебёдки.
Всё ещё нужно сбалансировать, но смысл в том, что теперь нельзя тупо зажимать кнопку. Если реже используешь сматывание, то у тебя есть ≈1 секунда непрерывного ускорения без ожидания, а вот если постоянно дёргать кнопку, придётся часто кликать с ожиданием отката ("охлаждения") способности.
По сравнению с обычным кулдауном способности (после использования нужно ждать таймер отката), перегрев позволяет использовать эту способность сразу и расходовать рационально. По сравнению с накоплением заряда (когда шкала заполняется "энергией" способности) перегрев не стимулирует израсходовать весь заряд как можно раньше, ибо отсутствует эффект "недополученной прибыли": наоборот, есть стимул избегать лишней нагрузки.
Короче: код минимальный, но психологически это внезапно сложная тема. Я даже на счёт UI теперь сомневаюсь: наверное, лучше убрать полоску; как-то завязать яркость/объём частиц на уровень нагрева - минимальный нагрев = нет частиц, максимум = дым становится чёрным и резко прекращается. Нужно интуитивное что-то, что не будет отвлекать игрока.
Ещё короче - недостаточно знать движок, чтобы сделать собственную интересную игру...
Кстати, кто-нибудь знает, что теперь с инверсной кинематикой? Её обещали переделать вроде бы, и существующее решение было нестабильно. Хочу персонажа нормально анимировать, но как?..
>Сделал по итогу спавн когда камера заходит в область спавна челика/объекта, и теперь минимум 200 - 300 фпс есть на большой карте
Молодец. А когда пофиксишь скольжение ног?
Если правильно помню, твоя карта генерируется?
Что-нибудь читал/смотрел по дизайну уровней?
>>4568
>про устройство игр
Придумал вот как занерфить лебёдку.
Когда делал механику верёвки, заметил: слишком сложно забраться на край объекта, если не можешь зацепиться выше этого края. Это можно исправить по-разному... Но я решил просто усилить лебёдку до состояния, когда она способна подбросить игрока как минимум на один рост персонажа выше точки крепления верёвки. Мне это понравилось, но потом обнаружил, что такая мощная лебёдка позволяет ускоряться почти бесконечно и летать на огромной скорости. Короче, зажал кнопку и летишь.
На днях попробовал добавить спецэффект к работе лебёдки и эта проблема стала ещё острее. В итоге придумал сделать "перегрев" лебёдки. Каждый тик _physics_process изменяется параметр:
>heat += delta × (heat_rise_factor
>if state == State.REEL_IN # намотка
>else heat_drop_factor) # размотка/бездействие
Если heat > 0.99, лебёдка отключается. Как можно догадаться, "...factor" равный 1 равен 1 секунде до "перегрева" или полного "охлаждения" лебёдки.
Всё ещё нужно сбалансировать, но смысл в том, что теперь нельзя тупо зажимать кнопку. Если реже используешь сматывание, то у тебя есть ≈1 секунда непрерывного ускорения без ожидания, а вот если постоянно дёргать кнопку, придётся часто кликать с ожиданием отката ("охлаждения") способности.
По сравнению с обычным кулдауном способности (после использования нужно ждать таймер отката), перегрев позволяет использовать эту способность сразу и расходовать рационально. По сравнению с накоплением заряда (когда шкала заполняется "энергией" способности) перегрев не стимулирует израсходовать весь заряд как можно раньше, ибо отсутствует эффект "недополученной прибыли": наоборот, есть стимул избегать лишней нагрузки.
Короче: код минимальный, но психологически это внезапно сложная тема. Я даже на счёт UI теперь сомневаюсь: наверное, лучше убрать полоску; как-то завязать яркость/объём частиц на уровень нагрева - минимальный нагрев = нет частиц, максимум = дым становится чёрным и резко прекращается. Нужно интуитивное что-то, что не будет отвлекать игрока.
Ещё короче - недостаточно знать движок, чтобы сделать собственную интересную игру...
Кстати, кто-нибудь знает, что теперь с инверсной кинематикой? Её обещали переделать вроде бы, и существующее решение было нестабильно. Хочу персонажа нормально анимировать, но как?..
>>4664
Да, давно как то копался в PE формате, к чему вопрос?
>А сам-то хоть раз кому-нибудь раздвигал место между бинарником и заголовком, втискивал свою картинку? А Ежи?
Да, давно как то копался в PE формате, к чему вопрос?
367 Кб, 640x640парни, вот $Zalupa это короткая запись от get_node("Zalupa"), я также слышал, что в данном случае "Zalupa" это тип Строка и тратится время на конвертацию в тип Путь, поэтому в идеале использовать get_node(^"Zalupa"), это типа лучше и быстрее, а есть ли тогда короткая запись для ^"Zalupa"? Типа там какой-нибудь $^Zaloopa или что-то такое?
>>4727
разве это не какое-то там уникальное имя, которое дополнительно надо где-то устанавливать и только потом исползовать в коде?
разве это не какое-то там уникальное имя, которое дополнительно надо где-то устанавливать и только потом исползовать в коде?
>>4731
ну тогда это не то, что мне надо, видимо ответ тогда нет
ну тогда это не то, что мне надо, видимо ответ тогда нет
>>4726
Делай гет_нод(похуй_как) ровно ОДИН раз и загоняй в переменную - самое быстрое будет. Можешь даже в онреди пихнуть.
Делай гет_нод(похуй_как) ровно ОДИН раз и загоняй в переменную - самое быстрое будет. Можешь даже в онреди пихнуть.
>>4733
Удваиваю и добавлю, что есть причина, почему онреди лучше.
Каждый раз делая $Zalupa, ты как бы повторно вызываешь get_node("Zalupa"), что не оч хорошо для производительности. Онреди полностью устраняет эту проблему, выполняя get_node всего один раз, а дальше в переменной хранится только указатель. То есть, даже если $ встречается всего лишь в одном месте, наверняка это место выполняется чаще, чем один раз за игру.
Кто-то скажет, что это преждевременная оптимизация, а я скажу, что лучше сразу привыкать писать хороший код без дополнительных трудозатрат, дабы избавить себя от лишнего труда на этапе оптимизации.
Удваиваю и добавлю, что есть причина, почему онреди лучше.
Каждый раз делая $Zalupa, ты как бы повторно вызываешь get_node("Zalupa"), что не оч хорошо для производительности. Онреди полностью устраняет эту проблему, выполняя get_node всего один раз, а дальше в переменной хранится только указатель. То есть, даже если $ встречается всего лишь в одном месте, наверняка это место выполняется чаще, чем один раз за игру.
Кто-то скажет, что это преждевременная оптимизация, а я скажу, что лучше сразу привыкать писать хороший код без дополнительных трудозатрат, дабы избавить себя от лишнего труда на этапе оптимизации.
>>4741
А какой выигрыш это в принципе может дать? Я не эксперт, но звучит как "++i быстрее чем i++ на доли процента, используйте префиксные операторы чтобы потом ваш код кроме вас хуй кто понял"
Мимо
А какой выигрыш это в принципе может дать? Я не эксперт, но звучит как "++i быстрее чем i++ на доли процента, используйте префиксные операторы чтобы потом ваш код кроме вас хуй кто понял"
Мимо
>>4777
Взлетевшую идею не выйдет украсть, потому что автор уже заработал свой миллион. Кради идеи из треда идей >>605406 (OP)
Взлетевшую идею не выйдет украсть, потому что автор уже заработал свой миллион. Кради идеи из треда идей >>605406 (OP)
Как сделать так, чтобы Godot 4.3 не зависал каждые 15 минут без всякой причины? Работаю-работаю, раз завис на 30 секунд, отвис, работаю дальше.
>>4790
Даже ААА-хуи бессовестно воруют друг у друга, иногда вплоть до визуала и моделек. Тут достаточно визуал сменить и насыпать, так сказать, спайсов своих.
Даже ААА-хуи бессовестно воруют друг у друга, иногда вплоть до визуала и моделек. Тут достаточно визуал сменить и насыпать, так сказать, спайсов своих.
>>4796
Дада!! Вот из недавнего: авторки нашумевшей игры Dustborn спиздили ассеты в ГТАонлайн.
Дада!! Вот из недавнего: авторки нашумевшей игры Dustborn спиздили ассеты в ГТАонлайн.
>>4756
Если вызов в одном объекте пару раз за его работу - практически никакого. Если в сотне мобов каждый кадр - охуенный выигрыш, вплоть до того, что с ним сотню можно было бы заменить на тысячу.
Главный выигрыш - в формировании полезной привычки на случай, когда это реально повлияет на производительность.
>А какой выигрыш это в принципе может дать?
Если вызов в одном объекте пару раз за его работу - практически никакого. Если в сотне мобов каждый кадр - охуенный выигрыш, вплоть до того, что с ним сотню можно было бы заменить на тысячу.
Главный выигрыш - в формировании полезной привычки на случай, когда это реально повлияет на производительность.
>>4717
Не знаю, мне лень если честно. Я хочу закончить условную сюжетку до конца года, чтобы можно было с чистой душой в случае чего дропнуть игру, либо развивать в ином плане, улучшать и тп.
Нет, но вот как раз после сюжетки хочу с генерацией поиграть, для эскейп фром тарков сегмента, где нужно арты собирать и выживать
Нет
>А когда пофиксишь скольжение ног?
Не знаю, мне лень если честно. Я хочу закончить условную сюжетку до конца года, чтобы можно было с чистой душой в случае чего дропнуть игру, либо развивать в ином плане, улучшать и тп.
>твоя карта генерируется?
Нет, но вот как раз после сюжетки хочу с генерацией поиграть, для эскейп фром тарков сегмента, где нужно арты собирать и выживать
>Что-нибудь читал/смотрел по дизайну уровней?
Нет
>>4717
Тебе для удобства анимирования или чтоб сажать ступни на пол в движке? Если первое, то блендерный ригифи в связке с game rig tools в целом делают хорошо. Ну или если хочешь запотеть, то сам ее (IK) сделай. Так еще четче выйдет, анимации по ощущениям без даже малейших изменений переносятся.
>что теперь с инверсной кинематикой? Её обещали переделать вроде бы, и существующее решение было нестабильно. Хочу персонажа нормально анимировать, но как?..
Тебе для удобства анимирования или чтоб сажать ступни на пол в движке? Если первое, то блендерный ригифи в связке с game rig tools в целом делают хорошо. Ну или если хочешь запотеть, то сам ее (IK) сделай. Так еще четче выйдет, анимации по ощущениям без даже малейших изменений переносятся.