Добро пожаловать в тред любви, взаимопомощи и лиминальных пространств!
Шапка: https://hipolink.me/godothread
Предыдущий: >>1055144 (OP)
Архивный: >>1051748 (OP)
Шапка: https://hipolink.me/godothread
Предыдущий: >>1055144 (OP)
Архивный: >>1051748 (OP)
>>59251
Берёшь и делаешь, ничего сложного. Хочешь - делаешь сегодня, хочешь - завтра, хочешь - все следующие несколько лет делаешь и делаешь
Берёшь и делаешь, ничего сложного. Хочешь - делаешь сегодня, хочешь - завтра, хочешь - все следующие несколько лет делаешь и делаешь
>>59263
Потому что ты сделал редактируемые потомки, нахуярил туда изменений, забыл об этом, а сейчас изменяешь исходную сцену, а оно не применяется.
Потому что ты сделал редактируемые потомки, нахуярил туда изменений, забыл об этом, а сейчас изменяешь исходную сцену, а оно не применяется.
Сап годоти, подскажите, не в курсе ли вы насколько сложно в Годоте делать процедурные анимации с гуманоидами? Я хочу сделать игру с процедурной боевкой. чтобы водить мечом мышкой как в Half Sword или кто помнит Die By The Sword, первый пример слегка неудачный ибо у них там всё вокруг физ симуляции, а я хочу процедурно всё сделать как в DbtS. Сижу выбираю между Годотом и Анрилом.
С одной стороны анрил с процедуркой судя по всему точно справится, но я хочу делать игру в стиле лоуполи, а с анрилом это значит сидеть оптимизонить отрубая почти все фичи. А вот в Годоте наоборот для лоуполи судя по всему самое оно, а вот с процедуркой хз.
Если че я опытный разраб, похуй с чем работать, хоть с крестами хоть с гдскриптом, но именно в геймдеве новичок, и уже поделал всякие платформеры и прочие простенькие игры, в том числе 3Д, успел в блендер вкатиться и освоить пусть и не на высоком уровне, но в целом весь пайплайн по созданию 3Д ассетов, и теперь хочу взяться за что-то посерьезнее.
С одной стороны анрил с процедуркой судя по всему точно справится, но я хочу делать игру в стиле лоуполи, а с анрилом это значит сидеть оптимизонить отрубая почти все фичи. А вот в Годоте наоборот для лоуполи судя по всему самое оно, а вот с процедуркой хз.
Если че я опытный разраб, похуй с чем работать, хоть с крестами хоть с гдскриптом, но именно в геймдеве новичок, и уже поделал всякие платформеры и прочие простенькие игры, в том числе 3Д, успел в блендер вкатиться и освоить пусть и не на высоком уровне, но в целом весь пайплайн по созданию 3Д ассетов, и теперь хочу взяться за что-то посерьезнее.
>>1058595 →
Кто-нибудь может попробовать x32 на Windows 10?
У меня она крашится на запуске, в логе такая фигня:
Версию x64 потестить не могу - нет SSE4...
Хотел просто в новую тему потыкать...
>>59263
Изменения чего и в чём/где? Экспорт куда и как?
Некоторые типы (json) нужно отдельно указывать.
>>59264
Такое детектится на этапе теста прям в движке.
Если у него только после экспорта - это другое.
>>59267
Вроде несложно. Систему анимаций улучшили.
Некоторые умельцы делали активный регдолл.
Читай документацию про SkeletonModifier3D.
https://godotengine.org/article/design-of-the-skeleton-modifier-3d/
>dev-snapshot-godot-4-6-dev-3
Кто-нибудь может попробовать x32 на Windows 10?
У меня она крашится на запуске, в логе такая фигня:
>WARNING: Property not found: physics/jolt...
><очень много повторов этой строчки>
>ERROR: FATAL: Index p_index = 1 is out of bounds...
>... program crashed with signal 4...
Версию x64 потестить не могу - нет SSE4...
Хотел просто в новую тему потыкать...
>>59263
>При экспорте не сохраняются изменения
Изменения чего и в чём/где? Экспорт куда и как?
Некоторые типы (json) нужно отдельно указывать.
>>59264
Такое детектится на этапе теста прям в движке.
Если у него только после экспорта - это другое.
>>59267
>процедурные анимации с гуманоидами
Вроде несложно. Систему анимаций улучшили.
Некоторые умельцы делали активный регдолл.
Читай документацию про SkeletonModifier3D.
https://godotengine.org/article/design-of-the-skeleton-modifier-3d/
>>1058595 →
Кто-нибудь может попробовать x32 на Windows 10?
У меня она крашится на запуске, в логе такая фигня:
Версию x64 потестить не могу - нет SSE4...
Хотел просто в новую тему потыкать...
>>59263
Изменения чего и в чём/где? Экспорт куда и как?
Некоторые типы (json) нужно отдельно указывать.
>>59264
Такое детектится на этапе теста прям в движке.
Если у него только после экспорта - это другое.
>>59267
Вроде несложно. Систему анимаций улучшили.
Некоторые умельцы делали активный регдолл.
Читай документацию про SkeletonModifier3D.
https://godotengine.org/article/design-of-the-skeleton-modifier-3d/
>dev-snapshot-godot-4-6-dev-3
Кто-нибудь может попробовать x32 на Windows 10?
У меня она крашится на запуске, в логе такая фигня:
>WARNING: Property not found: physics/jolt...
><очень много повторов этой строчки>
>ERROR: FATAL: Index p_index = 1 is out of bounds...
>... program crashed with signal 4...
Версию x64 потестить не могу - нет SSE4...
Хотел просто в новую тему потыкать...
>>59263
>При экспорте не сохраняются изменения
Изменения чего и в чём/где? Экспорт куда и как?
Некоторые типы (json) нужно отдельно указывать.
>>59264
Такое детектится на этапе теста прям в движке.
Если у него только после экспорта - это другое.
>>59267
>процедурные анимации с гуманоидами
Вроде несложно. Систему анимаций улучшили.
Некоторые умельцы делали активный регдолл.
Читай документацию про SkeletonModifier3D.
https://godotengine.org/article/design-of-the-skeleton-modifier-3d/
>>59268
Это кал подсадный, анончик, а не версия. У меня за сегодня годот вылетел 3 блядь раза. Дважды при присвоении значения экспортной переменной и один раз еще не помню когда. Теперь хз, буду ждать апдейта, так как откатываться я не хочу, я уже передергал все скелеты.
>>dev-snapshot-godot-4-6-dev-3
>Кто-нибудь может попробовать x32 на Windows 10?
>У меня она крашится на запуске, в логе такая фигня:
>>WARNING: Property not found: physics/jolt...
>><очень много повторов этой строчки>
>>ERROR: FATAL: Index p_index = 1 is out of bounds...
>>... program crashed with signal 4...
>Версию x64 потестить не могу - нет SSE4...
>Хотел просто в новую тему потыкать...
Это кал подсадный, анончик, а не версия. У меня за сегодня годот вылетел 3 блядь раза. Дважды при присвоении значения экспортной переменной и один раз еще не помню когда. Теперь хз, буду ждать апдейта, так как откатываться я не хочу, я уже передергал все скелеты.
>>59275
Что? Никогда не слышал о "live server". Это из VSC? Попробуй выключить и включить, лол))) Или, ну, нормальный апач или нгинкс накатить, что ли... Я тестировал веб-билд всего один раз и у меня он чрезвычайно тормозил (Godot 3.x, простое 3D), т.е. обновлять ничего не потребовалось - просто забил.
Также попробуй целиком удалить папку с экспортом, экспортировать заново в новую папку, перезапустить сервер уже ПОСЛЕ экспорта игры в эту новую папку...
>>59272
Разве между dev1/dev2 и dev3 скелеты поменяли?
Компьютер старый, давно собираюсь купить что-то посвежее, но чёт мне не нравится, как они делают редактор менее портативным... Что, если моя игра достаточно проста, чтобы работать даже на старых компьютерах? Оставаться на версиях до ≤4.4.1?
>после запускаю проект (лайв сервером)
Что? Никогда не слышал о "live server". Это из VSC? Попробуй выключить и включить, лол))) Или, ну, нормальный апач или нгинкс накатить, что ли... Я тестировал веб-билд всего один раз и у меня он чрезвычайно тормозил (Godot 3.x, простое 3D), т.е. обновлять ничего не потребовалось - просто забил.
Также попробуй целиком удалить папку с экспортом, экспортировать заново в новую папку, перезапустить сервер уже ПОСЛЕ экспорта игры в эту новую папку...
>>59272
>передергал все скелеты
Разве между dev1/dev2 и dev3 скелеты поменяли?
Компьютер старый, давно собираюсь купить что-то посвежее, но чёт мне не нравится, как они делают редактор менее портативным... Что, если моя игра достаточно проста, чтобы работать даже на старых компьютерах? Оставаться на версиях до ≤4.4.1?
>>59281
Не знаю. Я с 4.5. Потому пришлось все меши прокликивать назначая им скелет. Не велика задача, но хотелось бы избежать повторного прокликивания, скелетов у меня много
>Разве между dev1/dev2 и dev3 скелеты поменяли?
Не знаю. Я с 4.5. Потому пришлось все меши прокликивать назначая им скелет. Не велика задача, но хотелось бы избежать повторного прокликивания, скелетов у меня много
>>59282
Лол. Чейнжлоги читать нужно внимательнее:
https://github.com/godotengine/godot/pull/112267
Теперь мне стало интересно, зачем ты во всех сценах обращался к параметру "skeleton"... Я раньше даже не замечал это свойство и не понимал, зачем оно там. Кажется, пару раз приходилось нажать "сброс" при перетаскивании нод, да и то - непонятно, почему...
>все меши прокликивать назначая им скелет
Лол. Чейнжлоги читать нужно внимательнее:
>Animation: Remove default skeleton path in MeshInstance3D (GH-112267).
>If relying on the default skeleton_path in some scenes, users should manually re-specify the parent node as the NodePath, or they can enable the animation/compatibility/default_parent_skeleton_in_mesh_instance_3d project setting to restore the pre-4.6 behavior.
https://github.com/godotengine/godot/pull/112267
Теперь мне стало интересно, зачем ты во всех сценах обращался к параметру "skeleton"... Я раньше даже не замечал это свойство и не понимал, зачем оно там. Кажется, пару раз приходилось нажать "сброс" при перетаскивании нод, да и то - непонятно, почему...
>>59281
Разве в четверке нет compatibility рендера, который как раз рассчитан для работы на тапках? Но это касается именно билда, а не самого редактора.
А так я вообще на тройке до сих пор. Но не из-за компа, а просто доделываю большой проект.
>>59284
Вроде скелетон авто-заполняется родителем, и сохраняет его при перетаскивании.
>Что, если моя игра достаточно проста, чтобы работать даже на старых компьютерах? Оставаться на версиях до ≤4.4.1?
Разве в четверке нет compatibility рендера, который как раз рассчитан для работы на тапках? Но это касается именно билда, а не самого редактора.
А так я вообще на тройке до сих пор. Но не из-за компа, а просто доделываю большой проект.
>>59284
>Кажется, пару раз приходилось нажать "сброс" при перетаскивании нод, да и то - непонятно, почему...
Вроде скелетон авто-заполняется родителем, и сохраняет его при перетаскивании.
184 Кб, 1024x700>>59282
Юзайте годот-менеджер.
Чёткая привязка проект <-> движок.
Никаких сюрпризов. Держишь несколько версий движка под разные проекты. Начав один проект на одной версии можешь контролируемо перейти на новую версию, сделав бэкапы и вовсе скопировав проект в отдельную папку и добавив в менеджер, установить новую версию движка. Так же легко продолжать вести разработку основного проекта на более старой версии, и периодически делать мелкие пет-проекты на новых версиях, чтобы быть в курсе новшеств, быть готовым к ним. Не опасаясь за проекты.
Окно выбора проекта внутри движка так не может, при всём его удобстве, потому что оно не управляет версиями движка бай дизайн. Так что менеджер это мастхэв. Я пользуюсь этим: https://github.com/eumario/godot-manager
Есть и аналоги.
> хотелось бы избежать повторного прокликивания
Юзайте годот-менеджер.
Чёткая привязка проект <-> движок.
Никаких сюрпризов. Держишь несколько версий движка под разные проекты. Начав один проект на одной версии можешь контролируемо перейти на новую версию, сделав бэкапы и вовсе скопировав проект в отдельную папку и добавив в менеджер, установить новую версию движка. Так же легко продолжать вести разработку основного проекта на более старой версии, и периодически делать мелкие пет-проекты на новых версиях, чтобы быть в курсе новшеств, быть готовым к ним. Не опасаясь за проекты.
Окно выбора проекта внутри движка так не может, при всём его удобстве, потому что оно не управляет версиями движка бай дизайн. Так что менеджер это мастхэв. Я пользуюсь этим: https://github.com/eumario/godot-manager
Есть и аналоги.
Если кто-то делал процедурную генерацию 2д карт, что по скорости было?
Мне кажется очень медленно, 5 чанков размером 255х255 за 600 миллисекунд и это только деревья поставить. Речь о GDScript'e.
Мне кажется очень медленно, 5 чанков размером 255х255 за 600 миллисекунд и это только деревья поставить. Речь о GDScript'e.
>>59286
Дело не в рендеринге. В 4.5 принудительно включили специальный флаг, с которым компилятор добавляет инструкции из набора SSE4.2, которые отсутствуют на множестве старых и некоторых новых процессорах. Объясняют это "оптимизацией", но нахрена мне эта оптимизация, если без неё всё работало нормально, а теперь вообще не запускается? Я-то разберусь, как скомпилировать и запустить, а игроки - не будут...
А рендерер багнутый и не такой, как в тройке, т.к. они переписывали его с нуля. Например, на мобилках он неспособен нормально деформировать 2D меши, они просто исчезают при любой анимации. А на 3.x норм.
>>59288
Нет. Достаточно системных ярлыков/шорткатов. Настраиваешь один раз и забываешь обо всех этих менеджерах навсегда, потому что можешь кликом на рабочем столе открыть проект сразу в редакторе, без промежуточных шагов и посредников. Если захотел обновить версию, просто меняешь индекс в ярлыке.
>>59295
Под этим очень многое можно понимать...
Ты все 325 тысяч клеточек заполняешь?
Ну, это совсем неплохой результат...
Что значит "поставить"?
- Заполнить ячейку в массиве?
- Переключить ячейку в TileMap?
- Создать новую ноду в дереве?
- Распаковать сцену в дерево?
Это очень разные операции...
Заполнять массив: на C++ раз в ≈100 быстрее.
Распаковывать сцены в дерево: ≈ без разницы.
Основной способ оптимизации генерации чанков в процедурных играх - раскидать операции на разные отдельные кадры, а то, что нельзя раскидать, но не затрагивает дерево сцены, вынести в независимый параллельный поток. То есть в отдельном потоке генерируются числа в массиве, а потом на каждом отдельном кадре размещается не более чем N нод в дерево сцены согласно числам в массиве. C++ тут существенно ускорит только генерацию массива, поскольку добавление сцен в дерево сцены и так происходит на C++ в недрах движка, но это "дерево сцены" однопоточное и вешает GUI/Input игры, если перегружено работой; а добавление сцен и даже нод затратно, особенно если там твой собственный код с обработчиками событий типа _init, _enter_tree, _ready.
Ещё совет: прежде, чем оптимизировать что-то, изучи встроенный дебаггер. Там есть возможность считать миллисекунды на отдельных функциях GDScript. Либо можешь воспользоваться классом Time и выводить информацию в консоль, если твой процесс не часто происходит. Дебаггер немного замедляет игру, и в релизной/экспортной версии игра чуть быстрее.
Алсо, если не знал, в редакторе есть возможность просматривать актуальный вид дерева сцены - это чрезвычайно затратная операция, а новички часто случайно её включают и забывают выключить.
Если будешь делать параллельный поток, сначала присмотрись к воркерам (WorkerThreadPool) - проще запустить, чем создавать свой Thread; у меня с ними поменьше ошибок доступа было почему-то. Главное, потоки могут ускорить только что-то изолированное, иначе только добавишь ещё больше задержек на синхронизацию или обращения к API движка.
>compatibility рендера
Дело не в рендеринге. В 4.5 принудительно включили специальный флаг, с которым компилятор добавляет инструкции из набора SSE4.2, которые отсутствуют на множестве старых и некоторых новых процессорах. Объясняют это "оптимизацией", но нахрена мне эта оптимизация, если без неё всё работало нормально, а теперь вообще не запускается? Я-то разберусь, как скомпилировать и запустить, а игроки - не будут...
А рендерер багнутый и не такой, как в тройке, т.к. они переписывали его с нуля. Например, на мобилках он неспособен нормально деформировать 2D меши, они просто исчезают при любой анимации. А на 3.x норм.
>>59288
>менеджер это мастхэв
Нет. Достаточно системных ярлыков/шорткатов. Настраиваешь один раз и забываешь обо всех этих менеджерах навсегда, потому что можешь кликом на рабочем столе открыть проект сразу в редакторе, без промежуточных шагов и посредников. Если захотел обновить версию, просто меняешь индекс в ярлыке.
>>59295
>процедурную генерацию
Под этим очень многое можно понимать...
>5 чанков размером 255х255
Ты все 325 тысяч клеточек заполняешь?
>600 миллисекунд
Ну, это совсем неплохой результат...
>только деревья поставить
Что значит "поставить"?
- Заполнить ячейку в массиве?
- Переключить ячейку в TileMap?
- Создать новую ноду в дереве?
- Распаковать сцену в дерево?
Это очень разные операции...
>Речь о GDScript'e.
Заполнять массив: на C++ раз в ≈100 быстрее.
Распаковывать сцены в дерево: ≈ без разницы.
Основной способ оптимизации генерации чанков в процедурных играх - раскидать операции на разные отдельные кадры, а то, что нельзя раскидать, но не затрагивает дерево сцены, вынести в независимый параллельный поток. То есть в отдельном потоке генерируются числа в массиве, а потом на каждом отдельном кадре размещается не более чем N нод в дерево сцены согласно числам в массиве. C++ тут существенно ускорит только генерацию массива, поскольку добавление сцен в дерево сцены и так происходит на C++ в недрах движка, но это "дерево сцены" однопоточное и вешает GUI/Input игры, если перегружено работой; а добавление сцен и даже нод затратно, особенно если там твой собственный код с обработчиками событий типа _init, _enter_tree, _ready.
Ещё совет: прежде, чем оптимизировать что-то, изучи встроенный дебаггер. Там есть возможность считать миллисекунды на отдельных функциях GDScript. Либо можешь воспользоваться классом Time и выводить информацию в консоль, если твой процесс не часто происходит. Дебаггер немного замедляет игру, и в релизной/экспортной версии игра чуть быстрее.
Алсо, если не знал, в редакторе есть возможность просматривать актуальный вид дерева сцены - это чрезвычайно затратная операция, а новички часто случайно её включают и забывают выключить.
Если будешь делать параллельный поток, сначала присмотрись к воркерам (WorkerThreadPool) - проще запустить, чем создавать свой Thread; у меня с ними поменьше ошибок доступа было почему-то. Главное, потоки могут ускорить только что-то изолированное, иначе только добавишь ещё больше задержек на синхронизацию или обращения к API движка.
>>59286
Дело не в рендеринге. В 4.5 принудительно включили специальный флаг, с которым компилятор добавляет инструкции из набора SSE4.2, которые отсутствуют на множестве старых и некоторых новых процессорах. Объясняют это "оптимизацией", но нахрена мне эта оптимизация, если без неё всё работало нормально, а теперь вообще не запускается? Я-то разберусь, как скомпилировать и запустить, а игроки - не будут...
А рендерер багнутый и не такой, как в тройке, т.к. они переписывали его с нуля. Например, на мобилках он неспособен нормально деформировать 2D меши, они просто исчезают при любой анимации. А на 3.x норм.
>>59288
Нет. Достаточно системных ярлыков/шорткатов. Настраиваешь один раз и забываешь обо всех этих менеджерах навсегда, потому что можешь кликом на рабочем столе открыть проект сразу в редакторе, без промежуточных шагов и посредников. Если захотел обновить версию, просто меняешь индекс в ярлыке.
>>59295
Под этим очень многое можно понимать...
Ты все 325 тысяч клеточек заполняешь?
Ну, это совсем неплохой результат...
Что значит "поставить"?
- Заполнить ячейку в массиве?
- Переключить ячейку в TileMap?
- Создать новую ноду в дереве?
- Распаковать сцену в дерево?
Это очень разные операции...
Заполнять массив: на C++ раз в ≈100 быстрее.
Распаковывать сцены в дерево: ≈ без разницы.
Основной способ оптимизации генерации чанков в процедурных играх - раскидать операции на разные отдельные кадры, а то, что нельзя раскидать, но не затрагивает дерево сцены, вынести в независимый параллельный поток. То есть в отдельном потоке генерируются числа в массиве, а потом на каждом отдельном кадре размещается не более чем N нод в дерево сцены согласно числам в массиве. C++ тут существенно ускорит только генерацию массива, поскольку добавление сцен в дерево сцены и так происходит на C++ в недрах движка, но это "дерево сцены" однопоточное и вешает GUI/Input игры, если перегружено работой; а добавление сцен и даже нод затратно, особенно если там твой собственный код с обработчиками событий типа _init, _enter_tree, _ready.
Ещё совет: прежде, чем оптимизировать что-то, изучи встроенный дебаггер. Там есть возможность считать миллисекунды на отдельных функциях GDScript. Либо можешь воспользоваться классом Time и выводить информацию в консоль, если твой процесс не часто происходит. Дебаггер немного замедляет игру, и в релизной/экспортной версии игра чуть быстрее.
Алсо, если не знал, в редакторе есть возможность просматривать актуальный вид дерева сцены - это чрезвычайно затратная операция, а новички часто случайно её включают и забывают выключить.
Если будешь делать параллельный поток, сначала присмотрись к воркерам (WorkerThreadPool) - проще запустить, чем создавать свой Thread; у меня с ними поменьше ошибок доступа было почему-то. Главное, потоки могут ускорить только что-то изолированное, иначе только добавишь ещё больше задержек на синхронизацию или обращения к API движка.
>compatibility рендера
Дело не в рендеринге. В 4.5 принудительно включили специальный флаг, с которым компилятор добавляет инструкции из набора SSE4.2, которые отсутствуют на множестве старых и некоторых новых процессорах. Объясняют это "оптимизацией", но нахрена мне эта оптимизация, если без неё всё работало нормально, а теперь вообще не запускается? Я-то разберусь, как скомпилировать и запустить, а игроки - не будут...
А рендерер багнутый и не такой, как в тройке, т.к. они переписывали его с нуля. Например, на мобилках он неспособен нормально деформировать 2D меши, они просто исчезают при любой анимации. А на 3.x норм.
>>59288
>менеджер это мастхэв
Нет. Достаточно системных ярлыков/шорткатов. Настраиваешь один раз и забываешь обо всех этих менеджерах навсегда, потому что можешь кликом на рабочем столе открыть проект сразу в редакторе, без промежуточных шагов и посредников. Если захотел обновить версию, просто меняешь индекс в ярлыке.
>>59295
>процедурную генерацию
Под этим очень многое можно понимать...
>5 чанков размером 255х255
Ты все 325 тысяч клеточек заполняешь?
>600 миллисекунд
Ну, это совсем неплохой результат...
>только деревья поставить
Что значит "поставить"?
- Заполнить ячейку в массиве?
- Переключить ячейку в TileMap?
- Создать новую ноду в дереве?
- Распаковать сцену в дерево?
Это очень разные операции...
>Речь о GDScript'e.
Заполнять массив: на C++ раз в ≈100 быстрее.
Распаковывать сцены в дерево: ≈ без разницы.
Основной способ оптимизации генерации чанков в процедурных играх - раскидать операции на разные отдельные кадры, а то, что нельзя раскидать, но не затрагивает дерево сцены, вынести в независимый параллельный поток. То есть в отдельном потоке генерируются числа в массиве, а потом на каждом отдельном кадре размещается не более чем N нод в дерево сцены согласно числам в массиве. C++ тут существенно ускорит только генерацию массива, поскольку добавление сцен в дерево сцены и так происходит на C++ в недрах движка, но это "дерево сцены" однопоточное и вешает GUI/Input игры, если перегружено работой; а добавление сцен и даже нод затратно, особенно если там твой собственный код с обработчиками событий типа _init, _enter_tree, _ready.
Ещё совет: прежде, чем оптимизировать что-то, изучи встроенный дебаггер. Там есть возможность считать миллисекунды на отдельных функциях GDScript. Либо можешь воспользоваться классом Time и выводить информацию в консоль, если твой процесс не часто происходит. Дебаггер немного замедляет игру, и в релизной/экспортной версии игра чуть быстрее.
Алсо, если не знал, в редакторе есть возможность просматривать актуальный вид дерева сцены - это чрезвычайно затратная операция, а новички часто случайно её включают и забывают выключить.
Если будешь делать параллельный поток, сначала присмотрись к воркерам (WorkerThreadPool) - проще запустить, чем создавать свой Thread; у меня с ними поменьше ошибок доступа было почему-то. Главное, потоки могут ускорить только что-то изолированное, иначе только добавишь ещё больше задержек на синхронизацию или обращения к API движка.
>>59304
В смысле "то, что под кнопкой debugger внизу экрана", потому что речь о "profiler" и/или "monitors", не помню точно... Дебаггером обычно называют программу, что позволяет заглянуть в память другой программы и выполнить исследуемую программу по шагам. Т.е. от дебаггера в этом субменю только +/- одна функция, остальное за компанию добавили под ту же кнопку.
А это на кнопке "Remote" в окне "Scene" находится.
Запустил редактор, чтобы убедиться...
>>59295
Ещё вспомнил одну неочевидную штуку. Если ты размещаешь распакованную сцену, то обязательно сохраняй ссылку на PackedScene, иначе она просто уничтожается и ты снова читаешь её с диска.
Например, такой код:
Сделает 100 чтений с диска, 99 из которых здесь избыточные. Есть функция preload(), но она должна считывать с диска в момент загрузки скрипта, где упомянута, что очень неудобно, если хочешь чётко контролировать момент загрузки ресурсов.
Да и в целом вызов функций GDScript ВНЕЗАПНО значительно дороже, чем ожидаешь, поэтому в сверхбольших циклах сокращай число вызовов собственных вспомогательных функций. Короче, инлайнинг в GDScript пока полностью отсутствует.
А вообще, главное - это твои алгоритмы. Их можно логически оптимизировать - например, вместо цикла циклов для обхода всего 2D массива, сделать цикл, проходящий по списку нужных объектов и рандомно выбирающий позиции - даже в случае случайных пересечений это будет намного быстрее, особенно в случае очень редко размещаемых объектов.
>встроенный дебаггер
В смысле "то, что под кнопкой debugger внизу экрана", потому что речь о "profiler" и/или "monitors", не помню точно... Дебаггером обычно называют программу, что позволяет заглянуть в память другой программы и выполнить исследуемую программу по шагам. Т.е. от дебаггера в этом субменю только +/- одна функция, остальное за компанию добавили под ту же кнопку.
>актуальный вид дерева сцены
А это на кнопке "Remote" в окне "Scene" находится.
Запустил редактор, чтобы убедиться...
>>59295
Ещё вспомнил одну неочевидную штуку. Если ты размещаешь распакованную сцену, то обязательно сохраняй ссылку на PackedScene, иначе она просто уничтожается и ты снова читаешь её с диска.
Например, такой код:
>func trees():
>_ for x in 10:
>_ _ for y in 10:
>_ _ _ place(x, y, get_tree)
>func get_tree(): return load("tree.tscn").instatiate()
Сделает 100 чтений с диска, 99 из которых здесь избыточные. Есть функция preload(), но она должна считывать с диска в момент загрузки скрипта, где упомянута, что очень неудобно, если хочешь чётко контролировать момент загрузки ресурсов.
Да и в целом вызов функций GDScript ВНЕЗАПНО значительно дороже, чем ожидаешь, поэтому в сверхбольших циклах сокращай число вызовов собственных вспомогательных функций. Короче, инлайнинг в GDScript пока полностью отсутствует.
А вообще, главное - это твои алгоритмы. Их можно логически оптимизировать - например, вместо цикла циклов для обхода всего 2D массива, сделать цикл, проходящий по списку нужных объектов и рандомно выбирающий позиции - даже в случае случайных пересечений это будет намного быстрее, особенно в случае очень редко размещаемых объектов.
Нашел вот этот видос.
https://www.youtube.com/watch?v=8hif56uOyL8
Человек подружил godot с bevy, как результат у него 10К юнитов с нормальным паф-файндингом и внутренним ии. Жалко я раньше не видел его, когда пытался в игру про некроманта. Мне приходилось сильно урезать количество болванчиков на карте с 10К до 1К.
https://www.youtube.com/watch?v=8hif56uOyL8
Человек подружил godot с bevy, как результат у него 10К юнитов с нормальным паф-файндингом и внутренним ии. Жалко я раньше не видел его, когда пытался в игру про некроманта. Мне приходилось сильно урезать количество болванчиков на карте с 10К до 1К.
>>59312
а нет, один раз сработало и все
а нет, один раз сработало и все
70 Кб, 352x493У меня в переходах на итчевую игру появился университет техаса, нахуй. И не 1 рандомный переход, а 35.
>>59332
челик, ты через VPN гейропы или сша сидишь и тебе подгрузили рекламу с яху, что тебя удивляет, поставь блокировщик рекламы
челик, ты через VPN гейропы или сша сидишь и тебе подгрузили рекламу с яху, что тебя удивляет, поставь блокировщик рекламы
>>59307
Это просто
Это просто
> Push it to the limit
> Walk along the razor's edge
> But don't look down, just keep your head
> Or you'll be finished
> Open up the limit
> Past the point of no return
> You've reached the top, but still you gotta learn
> How to keep it
74 Кб, 736x736СКОНПЕЛИРОВАЛ САМ
@
GODOT 3.6.2 НА ANDROID
@
ДЖВА ЧАСА РАЗБИРАЛСЯ
@
ПОУДАЛЯЛ ВСЁ ЛИШНЕЕ ИЗ PATH
@
ВЕДЬ У МЕНЯ КУЧА КОНПЕЛЯТОРОВ
@
В CUSTOM.PY НЕЛЬЗЯ ДЕРЖАТЬ ВСЁ
@
НО В ДОКАХ ОБ ЭТОМ НЕ СКАЗАЛИ
@
ОТКЛЮЧИЛ ВООБЩЕ ВСЕ МОДУЛИ
@
КРОМЕ GDSCRIPT И ЕЩЁ ЧЕГО-ТО
@
НАКОНЕЦ-ТО ЭКСПОРТИРУЮ
@
СЭКОНОМИЛ АЖ 12 МБ (46 -> 34)
@
ВЕСЬ В ПРЕДВКУШЕНИИ СКОРОСТИ
@
ДРОЖАЩИМИ РУКАМИ ЗАПУСКАЮ
@
ВМЕСТО ИГРЫ - ЧЁРНЫЙ ЭКРАН
@
GODOT 3.6.2 НА ANDROID
@
ДЖВА ЧАСА РАЗБИРАЛСЯ
@
ПОУДАЛЯЛ ВСЁ ЛИШНЕЕ ИЗ PATH
@
ВЕДЬ У МЕНЯ КУЧА КОНПЕЛЯТОРОВ
@
В CUSTOM.PY НЕЛЬЗЯ ДЕРЖАТЬ ВСЁ
@
НО В ДОКАХ ОБ ЭТОМ НЕ СКАЗАЛИ
@
ОТКЛЮЧИЛ ВООБЩЕ ВСЕ МОДУЛИ
@
КРОМЕ GDSCRIPT И ЕЩЁ ЧЕГО-ТО
@
НАКОНЕЦ-ТО ЭКСПОРТИРУЮ
@
СЭКОНОМИЛ АЖ 12 МБ (46 -> 34)
@
ВЕСЬ В ПРЕДВКУШЕНИИ СКОРОСТИ
@
ДРОЖАЩИМИ РУКАМИ ЗАПУСКАЮ
@
ВМЕСТО ИГРЫ - ЧЁРНЫЙ ЭКРАН
74 Кб, 736x736СКОНПЕЛИРОВАЛ САМ
@
GODOT 3.6.2 НА ANDROID
@
ДЖВА ЧАСА РАЗБИРАЛСЯ
@
ПОУДАЛЯЛ ВСЁ ЛИШНЕЕ ИЗ PATH
@
ВЕДЬ У МЕНЯ КУЧА КОНПЕЛЯТОРОВ
@
В CUSTOM.PY НЕЛЬЗЯ ДЕРЖАТЬ ВСЁ
@
НО В ДОКАХ ОБ ЭТОМ НЕ СКАЗАЛИ
@
ОТКЛЮЧИЛ ВООБЩЕ ВСЕ МОДУЛИ
@
КРОМЕ GDSCRIPT И ЕЩЁ ЧЕГО-ТО
@
НАКОНЕЦ-ТО ЭКСПОРТИРУЮ
@
СЭКОНОМИЛ АЖ 12 МБ (46 -> 34)
@
ВЕСЬ В ПРЕДВКУШЕНИИ СКОРОСТИ
@
ДРОЖАЩИМИ РУКАМИ ЗАПУСКАЮ
@
ВМЕСТО ИГРЫ - ЧЁРНЫЙ ЭКРАН
@
GODOT 3.6.2 НА ANDROID
@
ДЖВА ЧАСА РАЗБИРАЛСЯ
@
ПОУДАЛЯЛ ВСЁ ЛИШНЕЕ ИЗ PATH
@
ВЕДЬ У МЕНЯ КУЧА КОНПЕЛЯТОРОВ
@
В CUSTOM.PY НЕЛЬЗЯ ДЕРЖАТЬ ВСЁ
@
НО В ДОКАХ ОБ ЭТОМ НЕ СКАЗАЛИ
@
ОТКЛЮЧИЛ ВООБЩЕ ВСЕ МОДУЛИ
@
КРОМЕ GDSCRIPT И ЕЩЁ ЧЕГО-ТО
@
НАКОНЕЦ-ТО ЭКСПОРТИРУЮ
@
СЭКОНОМИЛ АЖ 12 МБ (46 -> 34)
@
ВЕСЬ В ПРЕДВКУШЕНИИ СКОРОСТИ
@
ДРОЖАЩИМИ РУКАМИ ЗАПУСКАЮ
@
ВМЕСТО ИГРЫ - ЧЁРНЫЙ ЭКРАН
>>59363
Так логично. Смотри документацию внимательней, там описывают какие модули за что отвечают - примерно сможешь прикинуть что твой проект реально использует.
>ОТКЛЮЧИЛ ВООБЩЕ ВСЕ МОДУЛИ
>ВМЕСТО ИГРЫ - ЧЁРНЫЙ ЭКРАН
Так логично. Смотри документацию внимательней, там описывают какие модули за что отвечают - примерно сможешь прикинуть что твой проект реально использует.
>>59378
Название "Я тебе черенок в жопу засуну блядь"
Название "Я тебе черенок в жопу засуну блядь"
>>59366
Почему экран чёрный-то?.. Хотя бы заливка серым сработать должна была, это же glClear() всего лишь. И ничего такого сложного в игре нет... Ладно, я вырубил модуль "etc", что, по идее, должно выключить в GLES2 вообще все текстуры. Но у меня даже просто Label не отображается. Хотя модуль с текстом добавил вроде.
Когда я изменил настройки, добавив "etc", почему-то результат (apk) не поменялся, судя по хэш-суммам... Неужели каждый раз все .o-артефакты удалять надо?
Короче. Я так понял, что для мобилки ради ≈12 МБ (в установленном виде; в apk ещё меньше, ≈5 МБ) нет необходимости компилировать свои темплейты... Официальные вроде и так на скорость заточены.
Алсо, да, я знаю, что можно было подключитлся к смартфону удалённо и посмотреть журнал ошибок. К сожалению, USB кабель и так раздолбан и мне лень разбираться в нюансах - я хочу сразу нормальное приложение получить, чтоб работало независимо.
Ладно... Это всё прокрастинация, походу...
Почему экран чёрный-то?.. Хотя бы заливка серым сработать должна была, это же glClear() всего лишь. И ничего такого сложного в игре нет... Ладно, я вырубил модуль "etc", что, по идее, должно выключить в GLES2 вообще все текстуры. Но у меня даже просто Label не отображается. Хотя модуль с текстом добавил вроде.
Когда я изменил настройки, добавив "etc", почему-то результат (apk) не поменялся, судя по хэш-суммам... Неужели каждый раз все .o-артефакты удалять надо?
Короче. Я так понял, что для мобилки ради ≈12 МБ (в установленном виде; в apk ещё меньше, ≈5 МБ) нет необходимости компилировать свои темплейты... Официальные вроде и так на скорость заточены.
Алсо, да, я знаю, что можно было подключитлся к смартфону удалённо и посмотреть журнал ошибок. К сожалению, USB кабель и так раздолбан и мне лень разбираться в нюансах - я хочу сразу нормальное приложение получить, чтоб работало независимо.
Ладно... Это всё прокрастинация, походу...
52 Кб, 861x357Здравствуй анончик. Я тут пытаюсь наговнокодить одну хуйню, но получается не очень.
У меян есть кнопочка и она должна открывать диалог выбора папки. При помощи гугла и передовых языковых моделей был создан код, который почти делает, что надо. Но есть одна заминка. После выбора папки в диалоговом окне нихуя не происходит. И пишется ошибка, что там что то не так.
Где чатгпт хуй? Версия движка 4.41 Документацию смотрел, но там без примеров непонятно.
У меян есть кнопочка и она должна открывать диалог выбора папки. При помощи гугла и передовых языковых моделей был создан код, который почти делает, что надо. Но есть одна заминка. После выбора папки в диалоговом окне нихуя не происходит. И пишется ошибка, что там что то не так.
Где чатгпт хуй? Версия движка 4.41 Документацию смотрел, но там без примеров непонятно.
>>59397
Гопота перепутала 3 годот с 4. В 4 у тебя просто должно быть .connect(_on_dir_selected), прямо так, без передачи владельца или еще чего нибудь. Тупо обьект/self.методобьектанепосредственно
https://docs.godotengine.org/en/stable/getting_started/step_by_step/signals.html
Гопота перепутала 3 годот с 4. В 4 у тебя просто должно быть .connect(_on_dir_selected), прямо так, без передачи владельца или еще чего нибудь. Тупо обьект/self.методобьектанепосредственно
https://docs.godotengine.org/en/stable/getting_started/step_by_step/signals.html
>>59397
Штош, вот тебе код от ЕИ (естественного интеллекта). С тебя игры.
> есть кнопочка и она должна открывать диалог выбора папки
> После выбора папки в диалоговом окне нихуя не происходит
Штош, вот тебе код от ЕИ (естественного интеллекта). С тебя игры.
>>59403
... Но самое крутое, ящитаю, что вышеприведённую задачу можно сделать вовсе без скриптов, просто настраивая узлы в инспекторе. Вот пруф:
... Но самое крутое, ящитаю, что вышеприведённую задачу можно сделать вовсе без скриптов, просто настраивая узлы в инспекторе. Вот пруф:
>>59403
Пипец кринж...
>>59397
Подключай сигнал на панели справа от инспектора.
Подключение сигналов кодом нужно только если ты:
- создаёшь новые ноды в коде и подключаешь их;
- используешь add_user_signal() где-то в своём коде;
- отключаешь и переподключаешь сигналы в рантайме;
- хочешь подключиться к Object, RefCounted или Resource.
Если сцена статичная (как обычно в GUI) - юзай панельку.
>вот тебе код от ЕИ
>без ведущего "_"
Пипец кринж...
>>59397
Подключай сигнал на панели справа от инспектора.
Подключение сигналов кодом нужно только если ты:
- создаёшь новые ноды в коде и подключаешь их;
- используешь add_user_signal() где-то в своём коде;
- отключаешь и переподключаешь сигналы в рантайме;
- хочешь подключиться к Object, RefCounted или Resource.
Если сцена статичная (как обычно в GUI) - юзай панельку.
>>59408
Я вообще ебал кодить такие простые штуки.
Взял да методами присоединил и всё, хули париться?
on_yourmom_pressed и всё нахуй
Я вообще ебал кодить такие простые штуки.
Взял да методами присоединил и всё, хули париться?
on_yourmom_pressed и всё нахуй
Кстати, мне кто-нибудь скажет, как для textureButton реализовать toggle через "метод" подключения в инспекторе? Каков сам "метод"? Я кажется не могу найти.
>>59413
Так же как и для обычной Button, у них это всё в базовом классе задано. Сначала устанавливаешь режим, потом ловишь сигнал.
Так же как и для обычной Button, у них это всё в базовом классе задано. Сначала устанавливаешь режим, потом ловишь сигнал.
>>59295
Сделал 9 чанков 255на255 за 700мс
Использовать TileMapPattern было ошибкой, он не ставится быстрее в TileMapLayer и занимает больше памяти т.к. хранит в себе каждую ячейку как класс, пиздос
Да, я думал с ним будет быстрее, типа отдал паттерн в C++ часть и она хитро установится в TileMapLayer, но хуй там. Там ещё вызывается функция конвертации кординат для не квадратных тайлов на каждый тайл, т.е. она вызывается даже для квадратных тайлов, но возвращает просто сумму координат, а если не квадратный начинает высчитывать хуйню всякую.
Через него 9 чанков создаются за 980мс
>>59304
>>59305
Ты там понаписал много, спасибо, но вопрос был кто генерировал, я хотел спросить какие скорости на каком объёме у других. Про потоки, с++ и т.д. я знаю.
Мониторы не работают пока _process не начнёт выполняться и профайлер тоже не поможет, если только код в ready не обернуть в
потому что в нём не сохраняется галочка "Script functions"
>Мне кажется очень медленно, 5 чанков размером 255х255 за 600 миллисекунд
Сделал 9 чанков 255на255 за 700мс
Использовать TileMapPattern было ошибкой, он не ставится быстрее в TileMapLayer и занимает больше памяти т.к. хранит в себе каждую ячейку как класс, пиздос
Да, я думал с ним будет быстрее, типа отдал паттерн в C++ часть и она хитро установится в TileMapLayer, но хуй там. Там ещё вызывается функция конвертации кординат для не квадратных тайлов на каждый тайл, т.е. она вызывается даже для квадратных тайлов, но возвращает просто сумму координат, а если не квадратный начинает высчитывать хуйню всякую.
Через него 9 чанков создаются за 980мс
>>59304
>>59305
Ты там понаписал много, спасибо, но вопрос был кто генерировал, я хотел спросить какие скорости на каком объёме у других. Про потоки, с++ и т.д. я знаю.
Мониторы не работают пока _process не начнёт выполняться и профайлер тоже не поможет, если только код в ready не обернуть в
> while true:
потому что в нём не сохраняется галочка "Script functions"
578 Кб, 967x826>>59426
Это ирония или уже постирония?
Это ирония или уже постирония?
>>59436
У тебя там какая-то экономия на спичках.
Ну, блин, очевидно же, что всё зависит от:
- CPU, RAM, GPU, настроек питания, разгона;
- версии движка, API, конструкций языка и т.п.;
- самого алгоритма генерации карты (что и как);
- объёма данных, включая размер и число тайлов;
- этапа генерации (только данные или рендеринг?).
Так что твой вопрос был неправильно поставлен.
Ты ж не предупредил, что у тебя генерация в _ready.
Значит, так. Генерация карт в играх в двух местах:
1. При создании мира/на загрузочном экране.
2. При движении игрока по большому миру.
В первом случае ты можешь потратить хоть 5 минут, большинство игроков потерпят. Но ты обязательно должен избежать блокировки GUI-потока своей игры дольше, чем на три секунды. То есть если твой код занимается чем-то целую секунду, то имеет смысл вынести его в отдельный поток даже на экране с надписью "загрузка". Иначе ОС посчитает окно игры зависшим и предложит игроку "отправить отчёт об ошибке". Да и сам игрок может забеспокоиться.
При движении по миру у тебя вообще есть в среднем меньше 16 мс на загрузку/генерацию чанков карты. Поэтому "чанк" в игре - это обычно очень маленький фрагмент карты, который за один кадр создаётся.
Короче, что я хочу сказать - генерировать в _ready нерационально даже для тестов, потому что это не отражает реального использования генератора.
Также хочу отметить, что желательно сразу делить "генерацию карты" и "рендеринг карты". Первое - это определение данных типа "вот здесь должна быть клеточка с водой", а второе - это "поместить тайл с анимированной текстурой воды в эту клетку". Если используешь Noise для генерации, то вся генерация происходит у тебя на C++ и ты просто "рендеришь" (отображаешь) результат генерации на экране.
Знаешь, ты б лучше скриншот своего кода скинул...
>700мс
>980мс
>код в ready
У тебя там какая-то экономия на спичках.
>вопрос был кто генерировал
>какие скорости на каком объёме
Ну, блин, очевидно же, что всё зависит от:
- CPU, RAM, GPU, настроек питания, разгона;
- версии движка, API, конструкций языка и т.п.;
- самого алгоритма генерации карты (что и как);
- объёма данных, включая размер и число тайлов;
- этапа генерации (только данные или рендеринг?).
Так что твой вопрос был неправильно поставлен.
>пока _process не начнёт выполняться
Ты ж не предупредил, что у тебя генерация в _ready.
Значит, так. Генерация карт в играх в двух местах:
1. При создании мира/на загрузочном экране.
2. При движении игрока по большому миру.
В первом случае ты можешь потратить хоть 5 минут, большинство игроков потерпят. Но ты обязательно должен избежать блокировки GUI-потока своей игры дольше, чем на три секунды. То есть если твой код занимается чем-то целую секунду, то имеет смысл вынести его в отдельный поток даже на экране с надписью "загрузка". Иначе ОС посчитает окно игры зависшим и предложит игроку "отправить отчёт об ошибке". Да и сам игрок может забеспокоиться.
При движении по миру у тебя вообще есть в среднем меньше 16 мс на загрузку/генерацию чанков карты. Поэтому "чанк" в игре - это обычно очень маленький фрагмент карты, который за один кадр создаётся.
Короче, что я хочу сказать - генерировать в _ready нерационально даже для тестов, потому что это не отражает реального использования генератора.
Также хочу отметить, что желательно сразу делить "генерацию карты" и "рендеринг карты". Первое - это определение данных типа "вот здесь должна быть клеточка с водой", а второе - это "поместить тайл с анимированной текстурой воды в эту клетку". Если используешь Noise для генерации, то вся генерация происходит у тебя на C++ и ты просто "рендеришь" (отображаешь) результат генерации на экране.
Знаешь, ты б лучше скриншот своего кода скинул...
>>59436
У тебя там какая-то экономия на спичках.
Ну, блин, очевидно же, что всё зависит от:
- CPU, RAM, GPU, настроек питания, разгона;
- версии движка, API, конструкций языка и т.п.;
- самого алгоритма генерации карты (что и как);
- объёма данных, включая размер и число тайлов;
- этапа генерации (только данные или рендеринг?).
Так что твой вопрос был неправильно поставлен.
Ты ж не предупредил, что у тебя генерация в _ready.
Значит, так. Генерация карт в играх в двух местах:
1. При создании мира/на загрузочном экране.
2. При движении игрока по большому миру.
В первом случае ты можешь потратить хоть 5 минут, большинство игроков потерпят. Но ты обязательно должен избежать блокировки GUI-потока своей игры дольше, чем на три секунды. То есть если твой код занимается чем-то целую секунду, то имеет смысл вынести его в отдельный поток даже на экране с надписью "загрузка". Иначе ОС посчитает окно игры зависшим и предложит игроку "отправить отчёт об ошибке". Да и сам игрок может забеспокоиться.
При движении по миру у тебя вообще есть в среднем меньше 16 мс на загрузку/генерацию чанков карты. Поэтому "чанк" в игре - это обычно очень маленький фрагмент карты, который за один кадр создаётся.
Короче, что я хочу сказать - генерировать в _ready нерационально даже для тестов, потому что это не отражает реального использования генератора.
Также хочу отметить, что желательно сразу делить "генерацию карты" и "рендеринг карты". Первое - это определение данных типа "вот здесь должна быть клеточка с водой", а второе - это "поместить тайл с анимированной текстурой воды в эту клетку". Если используешь Noise для генерации, то вся генерация происходит у тебя на C++ и ты просто "рендеришь" (отображаешь) результат генерации на экране.
Знаешь, ты б лучше скриншот своего кода скинул...
>700мс
>980мс
>код в ready
У тебя там какая-то экономия на спичках.
>вопрос был кто генерировал
>какие скорости на каком объёме
Ну, блин, очевидно же, что всё зависит от:
- CPU, RAM, GPU, настроек питания, разгона;
- версии движка, API, конструкций языка и т.п.;
- самого алгоритма генерации карты (что и как);
- объёма данных, включая размер и число тайлов;
- этапа генерации (только данные или рендеринг?).
Так что твой вопрос был неправильно поставлен.
>пока _process не начнёт выполняться
Ты ж не предупредил, что у тебя генерация в _ready.
Значит, так. Генерация карт в играх в двух местах:
1. При создании мира/на загрузочном экране.
2. При движении игрока по большому миру.
В первом случае ты можешь потратить хоть 5 минут, большинство игроков потерпят. Но ты обязательно должен избежать блокировки GUI-потока своей игры дольше, чем на три секунды. То есть если твой код занимается чем-то целую секунду, то имеет смысл вынести его в отдельный поток даже на экране с надписью "загрузка". Иначе ОС посчитает окно игры зависшим и предложит игроку "отправить отчёт об ошибке". Да и сам игрок может забеспокоиться.
При движении по миру у тебя вообще есть в среднем меньше 16 мс на загрузку/генерацию чанков карты. Поэтому "чанк" в игре - это обычно очень маленький фрагмент карты, который за один кадр создаётся.
Короче, что я хочу сказать - генерировать в _ready нерационально даже для тестов, потому что это не отражает реального использования генератора.
Также хочу отметить, что желательно сразу делить "генерацию карты" и "рендеринг карты". Первое - это определение данных типа "вот здесь должна быть клеточка с водой", а второе - это "поместить тайл с анимированной текстурой воды в эту клетку". Если используешь Noise для генерации, то вся генерация происходит у тебя на C++ и ты просто "рендеришь" (отображаешь) результат генерации на экране.
Знаешь, ты б лучше скриншот своего кода скинул...
Знакомый прислал такую картину. Экспортированная игра не запускается и в консоле выдает такую вакханалию.
У другого знакомого игра запустилась со второго раза.
А у меня всё нормально, что в редакторе, что в экспортной версии. Кто нибудь сталкивался?
У другого знакомого игра запустилась со второго раза.
А у меня всё нормально, что в редакторе, что в экспортной версии. Кто нибудь сталкивался?
>>59542 (Del)
Каких багов?
Каких багов?
>>59415
toggled(toggled_off:bool) - обратное состояние, я правильно понимаю? Нет возможности чекнуть с компа
toggled(toggled_off:bool) - обратное состояние, я правильно понимаю? Нет возможности чекнуть с компа
>>59541
Это матрица, скоро твой "знакомый" в каталажку поедет
Это матрица, скоро твой "знакомый" в каталажку поедет
>>59551
Неправильно. Зачем ты название переменной меняешь? Надо менять значение. true или false - это значения типа bool. toggled_on это не значение, это название. Его не надо менять.
toggled(true) - нажато
toggled(false) - отжато
> я правильно понимаю?
Неправильно. Зачем ты название переменной меняешь? Надо менять значение. true или false - это значения типа bool. toggled_on это не значение, это название. Его не надо менять.
toggled(true) - нажато
toggled(false) - отжато
>>59541
судя по ошибкам ты нашёл ассет с красивым компьют шейдером, а то что на нойтбуке друга со встроенной видеокартой он не заработает тебе никто не сказал
судя по ошибкам ты нашёл ассет с красивым компьют шейдером, а то что на нойтбуке друга со встроенной видеокартой он не заработает тебе никто не сказал
>>59558
Ну кста, я решил ради интереса порталы поставить, они вынуждают мой пк жёстко пердеть. Но их у меня нет в главном меню, но в нём я предзагружаю сцену с уровнем и этими порталами
Ну кста, я решил ради интереса порталы поставить, они вынуждают мой пк жёстко пердеть. Но их у меня нет в главном меню, но в нём я предзагружаю сцену с уровнем и этими порталами
>>59541
Пусть пришлёт характеристики компьютера.
Судя по ошибкам, Godot не смог найти Vulkan (или ты специально его отключил в своей игре), и пытается использовать Direct3D12, но что-то идёт наперекосяк с шейдерами. Неудивительно, т.к. поддержка D3D12 остаётся экспериментальной до сих пор (вроде бы).
Попроси его попробовать compatibility рендерер:
Графика может испортиться, но должно работать.
>>59542 (Del)
Это не баги, а отчёты пользователей о каких-то своих проблемах (issue). Иногда они дублируются или могут описывать что-то совсем мелкое. Иногда они могут исправляться сами собой, когда исправляют что-то совершенно другое. Многие проблемы связаны со специфическим железом или очень особенным использованием... В общем, чисто по количеству бестолку что-то обсуждать кроме популярности.
>>59551
А ты иди учи азы информатики, 6 класс школы.
Будет, например, так:
Но это ты сам должен знать без подсказок...
>>59562
>>59565
Вы обсуждаете велосипед какого-то васяна... Ну ок, обосрался школьник, бывает. При чём тут движок? Обосраться можно и на ассемблере - что теперь, все разработчики железа виноваты теперь?
>Знакомый прислал такую картину.
Пусть пришлёт характеристики компьютера.
Судя по ошибкам, Godot не смог найти Vulkan (или ты специально его отключил в своей игре), и пытается использовать Direct3D12, но что-то идёт наперекосяк с шейдерами. Неудивительно, т.к. поддержка D3D12 остаётся экспериментальной до сих пор (вроде бы).
Попроси его попробовать compatibility рендерер:
>твоя_игра.exe --rendering-driver opengl3
Графика может испортиться, но должно работать.
>>59542 (Del)
>в багтрекере over 10к багов
Это не баги, а отчёты пользователей о каких-то своих проблемах (issue). Иногда они дублируются или могут описывать что-то совсем мелкое. Иногда они могут исправляться сами собой, когда исправляют что-то совершенно другое. Многие проблемы связаны со специфическим железом или очень особенным использованием... В общем, чисто по количеству бестолку что-то обсуждать кроме популярности.
>>59551
А ты иди учи азы информатики, 6 класс школы.
>обратное состояние
Будет, например, так:
>func _on_button_toggled(toggled_on: bool) -> void:
>_ var toggled_off := not toggled_on
Но это ты сам должен знать без подсказок...
>>59562
>вынуждают мой пк жёстко пердеть
>>59565
>2006 года, и работала игра на картофеле
Вы обсуждаете велосипед какого-то васяна... Ну ок, обосрался школьник, бывает. При чём тут движок? Обосраться можно и на ассемблере - что теперь, все разработчики железа виноваты теперь?
>>59541
Пусть пришлёт характеристики компьютера.
Судя по ошибкам, Godot не смог найти Vulkan (или ты специально его отключил в своей игре), и пытается использовать Direct3D12, но что-то идёт наперекосяк с шейдерами. Неудивительно, т.к. поддержка D3D12 остаётся экспериментальной до сих пор (вроде бы).
Попроси его попробовать compatibility рендерер:
Графика может испортиться, но должно работать.
>>59542 (Del)
Это не баги, а отчёты пользователей о каких-то своих проблемах (issue). Иногда они дублируются или могут описывать что-то совсем мелкое. Иногда они могут исправляться сами собой, когда исправляют что-то совершенно другое. Многие проблемы связаны со специфическим железом или очень особенным использованием... В общем, чисто по количеству бестолку что-то обсуждать кроме популярности.
>>59551
А ты иди учи азы информатики, 6 класс школы.
Будет, например, так:
Но это ты сам должен знать без подсказок...
>>59562
>>59565
Вы обсуждаете велосипед какого-то васяна... Ну ок, обосрался школьник, бывает. При чём тут движок? Обосраться можно и на ассемблере - что теперь, все разработчики железа виноваты теперь?
>Знакомый прислал такую картину.
Пусть пришлёт характеристики компьютера.
Судя по ошибкам, Godot не смог найти Vulkan (или ты специально его отключил в своей игре), и пытается использовать Direct3D12, но что-то идёт наперекосяк с шейдерами. Неудивительно, т.к. поддержка D3D12 остаётся экспериментальной до сих пор (вроде бы).
Попроси его попробовать compatibility рендерер:
>твоя_игра.exe --rendering-driver opengl3
Графика может испортиться, но должно работать.
>>59542 (Del)
>в багтрекере over 10к багов
Это не баги, а отчёты пользователей о каких-то своих проблемах (issue). Иногда они дублируются или могут описывать что-то совсем мелкое. Иногда они могут исправляться сами собой, когда исправляют что-то совершенно другое. Многие проблемы связаны со специфическим железом или очень особенным использованием... В общем, чисто по количеству бестолку что-то обсуждать кроме популярности.
>>59551
А ты иди учи азы информатики, 6 класс школы.
>обратное состояние
Будет, например, так:
>func _on_button_toggled(toggled_on: bool) -> void:
>_ var toggled_off := not toggled_on
Но это ты сам должен знать без подсказок...
>>59562
>вынуждают мой пк жёстко пердеть
>>59565
>2006 года, и работала игра на картофеле
Вы обсуждаете велосипед какого-то васяна... Ну ок, обосрался школьник, бывает. При чём тут движок? Обосраться можно и на ассемблере - что теперь, все разработчики железа виноваты теперь?
>>59568
Туманчик сразу пропал... Но ладно. Он оперативно не может быть со мной на созвоне, если всё норм и он попробует, завтра отпишу.
Эти настройки я не трогал, всё работает по дефолту на forward+
>Попроси его попробовать compatibility рендерер: Графика может испортиться, но должно работать.
Туманчик сразу пропал... Но ладно. Он оперативно не может быть со мной на созвоне, если всё норм и он попробует, завтра отпишу.
>Судя по ошибкам, Godot не смог найти Vulkan (или ты специально его отключил в своей игре)
Эти настройки я не трогал, всё работает по дефолту на forward+
>>59576
А "Fallback to OpenGL 3" случайно не отключал?
https://docs.godotengine.org/en/stable/tutorials/rendering/renderers.html
Короче, как я вижу, что произошло:
1. У него встройка (iGPU) не поддерживает Vulkan подходящей версии и Godot пробует Direct3D 12.
2. Direct3D 12 определяется в системе как если он полностью поддерживается, но есть какой-то баг в драйверах или в биндингах Godot, выходит ошибка.
3. Godot застревает в бесконечной попытке что-то сделать с шейдерами вместо перехода на OpenGL3.
Можно поискать по issues на GitHub на эту тему.
>>59581
Чего, лол?
А "Fallback to OpenGL 3" случайно не отключал?
https://docs.godotengine.org/en/stable/tutorials/rendering/renderers.html
>Since Godot 4.4, when using Forward+ or Mobile, if Vulkan is not supported, the engine will fall back to Direct3D 12 and vice versa. If the attempted fallback driver is not supported either, the engine will then fall back to Compatibility when the RenderingDevice backend is not supported. This allows the project to run anyway, but it may look different than the intended appearance due to the more limited renderer. This behavior can be disabled in the project settings by unchecking Rendering > Rendering Device > Fallback to OpenGL 3
Короче, как я вижу, что произошло:
1. У него встройка (iGPU) не поддерживает Vulkan подходящей версии и Godot пробует Direct3D 12.
2. Direct3D 12 определяется в системе как если он полностью поддерживается, но есть какой-то баг в драйверах или в биндингах Godot, выходит ошибка.
3. Godot застревает в бесконечной попытке что-то сделать с шейдерами вместо перехода на OpenGL3.
Можно поискать по issues на GitHub на эту тему.
>>59581
Чего, лол?
204 Кб, 1920x1040>>59583
Увы, но нет, всё по-умолчанию. Надеюсь что дело реально в бесконечном залупинге, и запустив изначально в другом рендеринге всё норм будет
Увы, но нет, всё по-умолчанию. Надеюсь что дело реально в бесконечном залупинге, и запустив изначально в другом рендеринге всё норм будет
>>59591
Ага, навалил кучу ассетов, и с умным ебалом такой говорит нам, что дескать вот мол, в 2006 году диды делали порталы, которые на картошковых целеронах тогдашних работали, а нонче школоте нельзя ассетов навалить, чтоб не пропердеться.
Ага, навалил кучу ассетов, и с умным ебалом такой говорит нам, что дескать вот мол, в 2006 году диды делали порталы, которые на картошковых целеронах тогдашних работали, а нонче школоте нельзя ассетов навалить, чтоб не пропердеться.
22 Кб, 951x424>>59523
Мне в перспективе чанков генерировать тысячи / десятки тысяч, я на этих спичках лесополосу сэкономлю.
Очевидно так-же, что ты не генерировал, но смотрел туториалы как это делается.
Она если бы не в ready была, по твоему в process что ли? Это буквально то же самое что генерация на экране загрузки, функция которая пока повисает поток, не в этом суть.
Для понимания скорости генерации как-раз самое то
У меня цель - сделать на годоте, но, но тот же TileMapLayer как я заметил ебашит мне память, 9 чанков - потребление 250мб ( с 1 чанком - 79мб) (чанк у меня 255 на 255 пока, не суть, если делать их меньше их тогда всё равно в памяти держать больше придётся)
Я за сегодня накидал на гдскрипте свой Тайлпап который рисует чанками, результат на пике - 207мб и 5 дроуколов при дефолтном зуме.
Дефолтный тайлмэплейер хранит кучу ненужного мне - окклюдеры, физику, навигацию, и ещё всякое (да, даже если они выключены), мне от него нужно как бы только ускоренное рисование квадрантами, а это я сам +- сделал.
Но главная цель - делать на годоте и все оптимизации за счёт с++ отпадают, я потыкаюсь ещё, но кажется получить вменяемые скорости и потребление памяти не выйдет в итоге и от годота мало что останется.
>У тебя там какая-то экономия на спичках.
Мне в перспективе чанков генерировать тысячи / десятки тысяч, я на этих спичках лесополосу сэкономлю.
>Так что твой вопрос был неправильно поставлен
Очевидно так-же, что ты не генерировал, но смотрел туториалы как это делается.
>Ты ж не предупредил, что у тебя генерация в _ready.
Она если бы не в ready была, по твоему в process что ли? Это буквально то же самое что генерация на экране загрузки, функция которая пока повисает поток, не в этом суть.
>Короче, что я хочу сказать - генерировать в _ready нерационально даже для тестов, потому что это не отражает реального использования генератора.
Для понимания скорости генерации как-раз самое то
У меня цель - сделать на годоте, но, но тот же TileMapLayer как я заметил ебашит мне память, 9 чанков - потребление 250мб ( с 1 чанком - 79мб) (чанк у меня 255 на 255 пока, не суть, если делать их меньше их тогда всё равно в памяти держать больше придётся)
Я за сегодня накидал на гдскрипте свой Тайлпап который рисует чанками, результат на пике - 207мб и 5 дроуколов при дефолтном зуме.
Дефолтный тайлмэплейер хранит кучу ненужного мне - окклюдеры, физику, навигацию, и ещё всякое (да, даже если они выключены), мне от него нужно как бы только ускоренное рисование квадрантами, а это я сам +- сделал.
Но главная цель - делать на годоте и все оптимизации за счёт с++ отпадают, я потыкаюсь ещё, но кажется получить вменяемые скорости и потребление памяти не выйдет в итоге и от годота мало что останется.
>>59611
Если ты делаешь игру типа Terraria, то лучше будет сначала сгенерировать данные всего мира на C++, вообще не прикасаясь к API Godot. А размещать на экране тайлы будешь по необходимости.
Я генерировал разными алгоритмами. И 2D, и 3D. И интересовался методами генерации в разных играх. Поэтому и спрашиваю - что ты там у себя делаешь?
Что ты несёшь-то. Генерацию можно делить на шаги. Выполнять шаги можно в разное время. Чтоб ты не подвешивал поток, ты делаешь N шагов за кадр и дожидаешься следующего кадра. Да, дольше, но это позволяет потратить на генерацию хоть полчаса, не вызывая у ОС и юзера панику "программа зависла". Замерять время выполнения в _ready малополезно, поскольку в реальности это будет в _process или в параллельном потоке, который отчитывается туда.
Тут опять много деталей упущено:
- как ты его настраиваешь,
- как ты его используешь,
- какие у тебя тайлы,
и т.д. и т.п.
Я тоже так делал. Через SubViewport объединяешь? Разница в 43 мегабайта не выглядит существенной, наверняка бОльшую часть памяти занимают эти отрендеренные текстурки, а остальное - мелочи.
Ну, тогда C# или Rust... Выбирать есть из чего.
Если цель - "что угодно, лишь бы на годоте", то
Достигается путём ограничения своих хотелок.
Ещё раз: ты ни код свой не показал, ни на словах не объяснил, что именно и как ты генерируешь. 100% копипаста какого-нибудь туториала или вообще LLM сгенерировала, а теперь ты какие-то цифры постишь, оторванные от реальности и ничего не значащие... Характеристики компа тоже опиши - CPU, RAM, GPU.
>чанков генерировать тысячи / десятки тысяч
Если ты делаешь игру типа Terraria, то лучше будет сначала сгенерировать данные всего мира на C++, вообще не прикасаясь к API Godot. А размещать на экране тайлы будешь по необходимости.
>ты не генерировал, но смотрел туториалы
Я генерировал разными алгоритмами. И 2D, и 3D. И интересовался методами генерации в разных играх. Поэтому и спрашиваю - что ты там у себя делаешь?
>если бы не в ready была, по твоему в process
>функция которая пока повисает поток
Что ты несёшь-то. Генерацию можно делить на шаги. Выполнять шаги можно в разное время. Чтоб ты не подвешивал поток, ты делаешь N шагов за кадр и дожидаешься следующего кадра. Да, дольше, но это позволяет потратить на генерацию хоть полчаса, не вызывая у ОС и юзера панику "программа зависла". Замерять время выполнения в _ready малополезно, поскольку в реальности это будет в _process или в параллельном потоке, который отчитывается туда.
>TileMapLayer как я заметил ебашит мне память
Тут опять много деталей упущено:
- как ты его настраиваешь,
- как ты его используешь,
- какие у тебя тайлы,
и т.д. и т.п.
>накидал на гдскрипте свой Тайлмап
Я тоже так делал. Через SubViewport объединяешь? Разница в 43 мегабайта не выглядит существенной, наверняка бОльшую часть памяти занимают эти отрендеренные текстурки, а остальное - мелочи.
>все оптимизации за счёт с++ отпадают
Ну, тогда C# или Rust... Выбирать есть из чего.
>главная цель - делать на годоте
Если цель - "что угодно, лишь бы на годоте", то
>вменяемые скорости и потребление памяти
Достигается путём ограничения своих хотелок.
Ещё раз: ты ни код свой не показал, ни на словах не объяснил, что именно и как ты генерируешь. 100% копипаста какого-нибудь туториала или вообще LLM сгенерировала, а теперь ты какие-то цифры постишь, оторванные от реальности и ничего не значащие... Характеристики компа тоже опиши - CPU, RAM, GPU.
>>59611
Если ты делаешь игру типа Terraria, то лучше будет сначала сгенерировать данные всего мира на C++, вообще не прикасаясь к API Godot. А размещать на экране тайлы будешь по необходимости.
Я генерировал разными алгоритмами. И 2D, и 3D. И интересовался методами генерации в разных играх. Поэтому и спрашиваю - что ты там у себя делаешь?
Что ты несёшь-то. Генерацию можно делить на шаги. Выполнять шаги можно в разное время. Чтоб ты не подвешивал поток, ты делаешь N шагов за кадр и дожидаешься следующего кадра. Да, дольше, но это позволяет потратить на генерацию хоть полчаса, не вызывая у ОС и юзера панику "программа зависла". Замерять время выполнения в _ready малополезно, поскольку в реальности это будет в _process или в параллельном потоке, который отчитывается туда.
Тут опять много деталей упущено:
- как ты его настраиваешь,
- как ты его используешь,
- какие у тебя тайлы,
и т.д. и т.п.
Я тоже так делал. Через SubViewport объединяешь? Разница в 43 мегабайта не выглядит существенной, наверняка бОльшую часть памяти занимают эти отрендеренные текстурки, а остальное - мелочи.
Ну, тогда C# или Rust... Выбирать есть из чего.
Если цель - "что угодно, лишь бы на годоте", то
Достигается путём ограничения своих хотелок.
Ещё раз: ты ни код свой не показал, ни на словах не объяснил, что именно и как ты генерируешь. 100% копипаста какого-нибудь туториала или вообще LLM сгенерировала, а теперь ты какие-то цифры постишь, оторванные от реальности и ничего не значащие... Характеристики компа тоже опиши - CPU, RAM, GPU.
>чанков генерировать тысячи / десятки тысяч
Если ты делаешь игру типа Terraria, то лучше будет сначала сгенерировать данные всего мира на C++, вообще не прикасаясь к API Godot. А размещать на экране тайлы будешь по необходимости.
>ты не генерировал, но смотрел туториалы
Я генерировал разными алгоритмами. И 2D, и 3D. И интересовался методами генерации в разных играх. Поэтому и спрашиваю - что ты там у себя делаешь?
>если бы не в ready была, по твоему в process
>функция которая пока повисает поток
Что ты несёшь-то. Генерацию можно делить на шаги. Выполнять шаги можно в разное время. Чтоб ты не подвешивал поток, ты делаешь N шагов за кадр и дожидаешься следующего кадра. Да, дольше, но это позволяет потратить на генерацию хоть полчаса, не вызывая у ОС и юзера панику "программа зависла". Замерять время выполнения в _ready малополезно, поскольку в реальности это будет в _process или в параллельном потоке, который отчитывается туда.
>TileMapLayer как я заметил ебашит мне память
Тут опять много деталей упущено:
- как ты его настраиваешь,
- как ты его используешь,
- какие у тебя тайлы,
и т.д. и т.п.
>накидал на гдскрипте свой Тайлмап
Я тоже так делал. Через SubViewport объединяешь? Разница в 43 мегабайта не выглядит существенной, наверняка бОльшую часть памяти занимают эти отрендеренные текстурки, а остальное - мелочи.
>все оптимизации за счёт с++ отпадают
Ну, тогда C# или Rust... Выбирать есть из чего.
>главная цель - делать на годоте
Если цель - "что угодно, лишь бы на годоте", то
>вменяемые скорости и потребление памяти
Достигается путём ограничения своих хотелок.
Ещё раз: ты ни код свой не показал, ни на словах не объяснил, что именно и как ты генерируешь. 100% копипаста какого-нибудь туториала или вообще LLM сгенерировала, а теперь ты какие-то цифры постишь, оторванные от реальности и ничего не значащие... Характеристики компа тоже опиши - CPU, RAM, GPU.
>>59624
Идея - типа Cataclysm
Ну да
Есть экран с надписью "Подождите, идёт генерация" или я в ready а даный момент делаю генерацию, какая нахуй разница, если полтзователь сидит и пердит?!
Бля чел там 3 настройки "Включить навигацию", "Включить Коллизии", "Включить освещение", что там блять настраивать и использовать, ну размер квадранта есть ешё, я не ковырял он или текстуру создаёт в которую всё рисует или как я делает канвас айтем и в него рисует
Нет конечно, цепляешь новый CanvasItem в который рендерится один чанк, для каждого чанка, у меня просто Node2D
>>59624
Бля а то что она в чанках 9 против 25 ещё
?!
Ой бля, ладно, ну тебя нахуй, тебя и без трипкодов видно
>Если ты делаешь игру типа Terraria
Идея - типа Cataclysm
>Я генерировал разными алгоритмами.
Ну да
>Что ты несёшь-то.
Есть экран с надписью "Подождите, идёт генерация" или я в ready а даный момент делаю генерацию, какая нахуй разница, если полтзователь сидит и пердит?!
> как ты его настраиваешь,
> как ты его используешь,
Бля чел там 3 настройки "Включить навигацию", "Включить Коллизии", "Включить освещение", что там блять настраивать и использовать, ну размер квадранта есть ешё, я не ковырял он или текстуру создаёт в которую всё рисует или как я делает канвас айтем и в него рисует
>Я тоже так делал. Через SubViewport объединяешь?
Нет конечно, цепляешь новый CanvasItem в который рендерится один чанк, для каждого чанка, у меня просто Node2D
>>59624
>Разница в 43 мегабайта не выглядит существенной
Бля а то что она в чанках 9 против 25 ещё
>Ещё раз: ты ни код свой не показал, ни на словах не объяснил, что именно и как ты генерируешь. 100% копипаста какого-нибудь туториала или вообще LLM сгенерировала, а теперь ты какие-то цифры постишь, оторванные от реальности и ничего не значащие... Характеристики компа тоже опиши - CPU, RAM, GPU.
?!
Ой бля, ладно, ну тебя нахуй, тебя и без трипкодов видно
>>59628
Поясняю на примере для самых маленьких:
1. Топовый AMD 9950x3D, DDR5, код:
2. Древний Intel Core 2 Duo, DDR2, код:
Как ты думаешь, скорости будут одинаковыми?
Какие выводы можно сделать из измерений?
Анон 1 (топовый ПК) пишет на форум:
Анон 2 (древний ПК) отвечает ему:
Что из этого следует? Будет ли анон 1 доволен?
Поясняю на примере для самых маленьких:
1. Топовый AMD 9950x3D, DDR5, код:
>for chunk in 9:
>_ for x in 255:
>_ _ for y in 255:
>_ _ _ var sum: float
>_ _ _ for noise in 20:
>_ _ _ _ sum += noises[noise].get_noise_2d(x, y)
>_ _ _ map.set_cell(Vector2i(x, y), sum % 50)
2. Древний Intel Core 2 Duo, DDR2, код:
>for chunk in 9:
>_ for tree in 25:
>_ _ map.set_cell(Vector2i(randi() % 256, randi() % 256, 1)
Как ты думаешь, скорости будут одинаковыми?
Какие выводы можно сделать из измерений?
Анон 1 (топовый ПК) пишет на форум:
>Помогите, у меня генерация 900 мс, ужос!!!!
Анон 2 (древний ПК) отвечает ему:
>Ха-ха, а у меня всего за 5 мс генерируется, лол)
Что из этого следует? Будет ли анон 1 доволен?
>>59655
Делаем.
Я вот за всё время только одним ассетом пользовался - TerraBrush, или как-то так. Да и то, учитывая что во всех нормальных движках такой функционал есть из коробки - я не хочу называть это ассетом.
Делаем.
Я вот за всё время только одним ассетом пользовался - TerraBrush, или как-то так. Да и то, учитывая что во всех нормальных движках такой функционал есть из коробки - я не хочу называть это ассетом.
>>59713
То есть я правильно понимаю, что ты сначала сделал ассеты, саундтрек, дизайн, сюжет, и только потом начал делать, собственно, игру?
То есть я правильно понимаю, что ты сначала сделал ассеты, саундтрек, дизайн, сюжет, и только потом начал делать, собственно, игру?
>>59734
А хули там вообще бразильцы забыли? Они ж буквально на ветках до сих пор живут.
А хули там вообще бразильцы забыли? Они ж буквально на ветках до сих пор живут.
>>59736
А китайцы до сих пор 3 смены пашут за миску риса и плодятся как ебанутые. Из 90х пишешь?
А китайцы до сих пор 3 смены пашут за миску риса и плодятся как ебанутые. Из 90х пишешь?
>>59740
В прогрессе китайцев сомневаться не приходиться. А вот хули там бразилия где пол страны до сих пор в фавелах живёт и ни одной игры за всё время не выпустила - загадка, да ещё и сразу после 2-х гигантов.
В прогрессе китайцев сомневаться не приходиться. А вот хули там бразилия где пол страны до сих пор в фавелах живёт и ни одной игры за всё время не выпустила - загадка, да ещё и сразу после 2-х гигантов.
>>59748
Я просто оптимизирую силы, если делать ассеты самому то игру никогда не сделаешь.
Код писать я даже в обучении не особо что понял
Я просто оптимизирую силы, если делать ассеты самому то игру никогда не сделаешь.
Код писать я даже в обучении не особо что понял
>>59740
12ч х 6 дней, по статистике плодиться с прошлого года перестали, ибо некогда стало совсем
12ч х 6 дней, по статистике плодиться с прошлого года перестали, ибо некогда стало совсем
>>59745
Пиздишь ведь
https://ru.wikipedia.org/wiki/%D0%9A%D0%B0%D1%82%D0%B5%D0%B3%D0%BE%D1%80%D0%B8%D1%8F:%D0%9A%D0%BE%D0%BC%D0%BF%D1%8C%D1%8E%D1%82%D0%B5%D1%80%D0%BD%D1%8B%D0%B5_%D0%B8%D0%B3%D1%80%D1%8B,_%D1%80%D0%B0%D0%B7%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%B0%D0%BD%D0%BD%D1%8B%D0%B5_%D0%B2_%D0%91%D1%80%D0%B0%D0%B7%D0%B8%D0%BB%D0%B8%D0%B8
> А вот хули там бразилия где пол страны до сих пор в фавелах живёт и ни одной игры за всё время не выпустила
Пиздишь ведь
https://ru.wikipedia.org/wiki/%D0%9A%D0%B0%D1%82%D0%B5%D0%B3%D0%BE%D1%80%D0%B8%D1%8F:%D0%9A%D0%BE%D0%BC%D0%BF%D1%8C%D1%8E%D1%82%D0%B5%D1%80%D0%BD%D1%8B%D0%B5_%D0%B8%D0%B3%D1%80%D1%8B,_%D1%80%D0%B0%D0%B7%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%B0%D0%BD%D0%BD%D1%8B%D0%B5_%D0%B2_%D0%91%D1%80%D0%B0%D0%B7%D0%B8%D0%BB%D0%B8%D0%B8
2 Кб, 62x54>>59754
Нет, ты просто не хочешь стараться
Осилить гдскрипт может даже примат. Ты даже не старался
>Я просто оптимизирую силы, если делать ассеты самому то игру никогда не сделаешь.
Нет, ты просто не хочешь стараться
>Код писать я даже в обучении не особо что понял
Осилить гдскрипт может даже примат. Ты даже не старался
>>59761
Я только базу самую понял что такое переменные и функция. Как с этим код писать ваще хуй знает
Я только базу самую понял что такое переменные и функция. Как с этим код писать ваще хуй знает
>>59763
Дергаешь разные функции, сохраняешь их результаты в переменные. Все, ты программист.
Дергаешь разные функции, сохраняешь их результаты в переменные. Все, ты программист.
936 Кб, 320x180>>59764
Так вот оно чё, спасибо анончик
Так вот оно чё, спасибо анончик
>>59740
А это не так? Ты либо написал ебейшие тесты, один из тысяч поступил в лучшие и средние вузы страны а затем в офис малдшим говночистом, либо поступил прямо в пту и был отправлен в город улей - работать на мануфактуре за трупный батончик 12 часов в день. Или был сослан на рисовые поля к бабке горбатиться под солнцем по колено в говне в местном колхозе за неироничный миска рис.
А это не так? Ты либо написал ебейшие тесты, один из тысяч поступил в лучшие и средние вузы страны а затем в офис малдшим говночистом, либо поступил прямо в пту и был отправлен в город улей - работать на мануфактуре за трупный батончик 12 часов в день. Или был сослан на рисовые поля к бабке горбатиться под солнцем по колено в говне в местном колхозе за неироничный миска рис.
>>59766
нет, не так. Китай это сверхдержава и мировой гегемон, первая экономика мира, вузов там больше чем в любой другой стране
нет, не так. Китай это сверхдержава и мировой гегемон, первая экономика мира, вузов там больше чем в любой другой стране
Делайте игры, раз-раз, раз-раз и в релиз.
>>59736
Думаю, у них интернет лимитный, как у нас в 00-х, и выкачивать 20 ГБ других движков каждый месяц - отказывать себе в других развлечениях. А Godot относительно мало весит и при том популярен...
Плюс редактор Godot есть на Android.
>>59734
Удивлён, что в списке нет африканских стран...
>>59745
Смартфоны и ноутбуки есть даже у бездомных в большинстве стран, включая совсем нищие. Это не продукты питания - могут служить больше 10 лет, и в отличии от дома не занимают много места. Есть множество способов добыть электричество и даже интернет бесплатно или практически бесплатно.
>>59766
Ты про какую страну пишешь? Везде так, лол.
И как вы в геополитач всё скатывать умудряетесь?
>бразильцы
Думаю, у них интернет лимитный, как у нас в 00-х, и выкачивать 20 ГБ других движков каждый месяц - отказывать себе в других развлечениях. А Godot относительно мало весит и при том популярен...
Плюс редактор Godot есть на Android.
>>59734
Удивлён, что в списке нет африканских стран...
>>59745
>до сих пор в фавелах живёт
Смартфоны и ноутбуки есть даже у бездомных в большинстве стран, включая совсем нищие. Это не продукты питания - могут служить больше 10 лет, и в отличии от дома не занимают много места. Есть множество способов добыть электричество и даже интернет бесплатно или практически бесплатно.
>>59766
Ты про какую страну пишешь? Везде так, лол.
И как вы в геополитач всё скатывать умудряетесь?
>>59770
В нищих перенаселенных помойках это не везде. Даже местные петровичи больше 8 часов в день не работают, либо работают 2 через 2. А не 12 х6, а если хочешь еще половинку трупного батончика - доработай свой единственный выходной.
>Ты про какую страну пишешь? Везде так, лол.
В нищих перенаселенных помойках это не везде. Даже местные петровичи больше 8 часов в день не работают, либо работают 2 через 2. А не 12 х6, а если хочешь еще половинку трупного батончика - доработай свой единственный выходной.
>>59655
Сам делаю... А, стоп, я забил. У меня депрессия...
>>59673
Это не ассет. Ассеты - это графика, текст и музыка.
>>59711
Добрые родственники и пенсия по инвалидности.
Нормальный геймдев начинается с 5 лет на игру.
>>59720
Вот поэтому у тебя и уходят месяцы на 3-в-ряд.
>>59748
Несколько срачепостов на дваче считается?
Ничего не успеваю, разочаровываюсь в себе.
>>59754
А что такое "игра" если не набор ассетов и правил?
Правила ты 100% скопировал с успешных игр.
Ассеты ты все скачал на 100% готовые.
Код тоже берёшь готовый (из LLM).
В чём "твоя" игра заключается?
>>59761
Джва банана этой горилле.
>>59763
Учи if/elif/else, for, while, match, signal, class и т.д.
>Где вы ассеты нормальные берёте?
Сам делаю... А, стоп, я забил. У меня депрессия...
>>59673
>одним ассетом пользовался - TerraBrush
Это не ассет. Ассеты - это графика, текст и музыка.
>>59711
>Откуда у вас столько времени?
Добрые родственники и пенсия по инвалидности.
>уходят месяцы на простую игру
Нормальный геймдев начинается с 5 лет на игру.
>>59720
>Я нейронкой код делаю
Вот поэтому у тебя и уходят месяцы на 3-в-ряд.
>>59748
>производительность за 1 игростройный день
Несколько срачепостов на дваче считается?
>Что успеваете? Довольны ли собой?
Ничего не успеваю, разочаровываюсь в себе.
>>59754
>делать ассеты самому то игру никогда
А что такое "игра" если не набор ассетов и правил?
Правила ты 100% скопировал с успешных игр.
Ассеты ты все скачал на 100% готовые.
Код тоже берёшь готовый (из LLM).
В чём "твоя" игра заключается?
>>59761
>Осилить гдскрипт может даже примат.
Джва банана этой горилле.
>>59763
>понял что такое переменные и функция.
Учи if/elif/else, for, while, match, signal, class и т.д.
>>59655
Сам делаю... А, стоп, я забил. У меня депрессия...
>>59673
Это не ассет. Ассеты - это графика, текст и музыка.
>>59711
Добрые родственники и пенсия по инвалидности.
Нормальный геймдев начинается с 5 лет на игру.
>>59720
Вот поэтому у тебя и уходят месяцы на 3-в-ряд.
>>59748
Несколько срачепостов на дваче считается?
Ничего не успеваю, разочаровываюсь в себе.
>>59754
А что такое "игра" если не набор ассетов и правил?
Правила ты 100% скопировал с успешных игр.
Ассеты ты все скачал на 100% готовые.
Код тоже берёшь готовый (из LLM).
В чём "твоя" игра заключается?
>>59761
Джва банана этой горилле.
>>59763
Учи if/elif/else, for, while, match, signal, class и т.д.
>Где вы ассеты нормальные берёте?
Сам делаю... А, стоп, я забил. У меня депрессия...
>>59673
>одним ассетом пользовался - TerraBrush
Это не ассет. Ассеты - это графика, текст и музыка.
>>59711
>Откуда у вас столько времени?
Добрые родственники и пенсия по инвалидности.
>уходят месяцы на простую игру
Нормальный геймдев начинается с 5 лет на игру.
>>59720
>Я нейронкой код делаю
Вот поэтому у тебя и уходят месяцы на 3-в-ряд.
>>59748
>производительность за 1 игростройный день
Несколько срачепостов на дваче считается?
>Что успеваете? Довольны ли собой?
Ничего не успеваю, разочаровываюсь в себе.
>>59754
>делать ассеты самому то игру никогда
А что такое "игра" если не набор ассетов и правил?
Правила ты 100% скопировал с успешных игр.
Ассеты ты все скачал на 100% готовые.
Код тоже берёшь готовый (из LLM).
В чём "твоя" игра заключается?
>>59761
>Осилить гдскрипт может даже примат.
Джва банана этой горилле.
>>59763
>понял что такое переменные и функция.
Учи if/elif/else, for, while, match, signal, class и т.д.
>>59773
А в чём смысл делать самому ассеты если точно такие же лежат, причём совершенно бесплатно.
А в чём смысл делать самому ассеты если точно такие же лежат, причём совершенно бесплатно.
>>59774
В том, что и игра получится "точно такая же", ничем непримечательная, похожая на остальные. Затеряешься в толпе и получишь ноль аудитории. Смысл делать свои ассеты - придать игре более редкий визуал. Но тут конечно нужен и стиль и вкус и скилл. Если твой потолок - "программер арт" то действительно лучше готовые взять.
В том, что и игра получится "точно такая же", ничем непримечательная, похожая на остальные. Затеряешься в толпе и получишь ноль аудитории. Смысл делать свои ассеты - придать игре более редкий визуал. Но тут конечно нужен и стиль и вкус и скилл. Если твой потолок - "программер арт" то действительно лучше готовые взять.
27 Кб, 1067x133>>59773
Ассеты это любая готовая хуйня. В том числе кусок кода. А террабраш это тоже своего рода кусок кода. Делайте выводы, карлеки
>Это не ассет. Ассеты - это графика, текст и музыка.
Ассеты это любая готовая хуйня. В том числе кусок кода. А террабраш это тоже своего рода кусок кода. Делайте выводы, карлеки
>>59775
Всё так, игре нужно лицо.
Категорически не согласен. Если у тебя нет вкуса, то готовые ассеты ты разложишь плохо. А свой арт как минимум будет соответствовать всему остальному безумию, происходящему в твоей игре.
Если нет вкуса, то в геймдев не лезь. В геймдеве в большинстве случаев добиваются успеха игроки, а не никогда ни во что не игравшие предприниматели.
>>59774
Это что ты такое делаешь, что все ассеты, о которых мечталось, у тебя где-то бесплатно скачиваются? Ты абсолютно точно уверен, что они бесплатные, а не ворованные из какой-нибудь чужой игры?
Кинь ссылку на эти твои бесплатные ассеты.
>игра получится "точно такая же", ничем непримечательная, похожая на остальные. Затеряешься в толпе и получишь ноль аудитории.
Всё так, игре нужно лицо.
>Если твой потолок - "программер арт" то действительно лучше готовые взять.
Категорически не согласен. Если у тебя нет вкуса, то готовые ассеты ты разложишь плохо. А свой арт как минимум будет соответствовать всему остальному безумию, происходящему в твоей игре.
Если нет вкуса, то в геймдев не лезь. В геймдеве в большинстве случаев добиваются успеха игроки, а не никогда ни во что не игравшие предприниматели.
>>59774
>точно такие же лежат, причём бесплатно
Это что ты такое делаешь, что все ассеты, о которых мечталось, у тебя где-то бесплатно скачиваются? Ты абсолютно точно уверен, что они бесплатные, а не ворованные из какой-нибудь чужой игры?
Кинь ссылку на эти твои бесплатные ассеты.
>>59778
Нет, у тебя даже на скриншоте это сказано:
Код данными не является, поскольку код - это то, что исполняется машиной, а данные - это то, с чем будут работать алгоритмы, описанные в коде машины. Да, исходные коды можно хранить в текстовом файле и передавать как данные, но это не данные, если их рассматривать с точки зрения игры (программы).
Код может быть префабом в терминах Юнити, но в контексте Godot отсутствует аналогичный термин, несмотря на возможность включать код в сцены.
Тем более есть разница между "код игры" и "код из инструмента, используемого для разработки игры":
Это инструмент. Как кисточки и краски. Иначе тогда "ассетом" пришлось бы называть абсолютно всё, что используется для разработки игры, включая воздух, вдыхаемый разработчиком во время разработки.
>>59781
Постоянно заливают, лол. Вирусы там тоже есть.
>В том числе кусок кода.
Нет, у тебя даже на скриншоте это сказано:
>состоящий из однотипных данных
Код данными не является, поскольку код - это то, что исполняется машиной, а данные - это то, с чем будут работать алгоритмы, описанные в коде машины. Да, исходные коды можно хранить в текстовом файле и передавать как данные, но это не данные, если их рассматривать с точки зрения игры (программы).
Код может быть префабом в терминах Юнити, но в контексте Godot отсутствует аналогичный термин, несмотря на возможность включать код в сцены.
Тем более есть разница между "код игры" и "код из инструмента, используемого для разработки игры":
>А террабраш это
Это инструмент. Как кисточки и краски. Иначе тогда "ассетом" пришлось бы называть абсолютно всё, что используется для разработки игры, включая воздух, вдыхаемый разработчиком во время разработки.
>>59781
>на итч же ворованное не будут заливать
Постоянно заливают, лол. Вирусы там тоже есть.
>>59783
Да я уже сам понял, что серанул. Это аддон. Но я думаю, мол, он же из АССЕТ стора, а не АДДОН стора, значит, очевидно, это ассет.
>Нет, у тебя даже на скриншоте это сказано
Да я уже сам понял, что серанул. Это аддон. Но я думаю, мол, он же из АССЕТ стора, а не АДДОН стора, значит, очевидно, это ассет.
226 Кб, 500x637>>59786
Когда он начинал, он хотел. Это же база, основа, фундамент, классика.
Когда он начинал, он хотел. Это же база, основа, фундамент, классика.
Кто-то может подсказать, какое все-таки блять количество нодов в игровой сцене считается овердохуя? Ответов вроде "зависитот железа" и "смотря какие ноды" начитался и гуглением и от нейронов. Ноды - дохуя мультимешей (прям пару десятков тысяч) с различного рода травой, цветами и прочими букетом, у каждого от 200 (большие цветочки) до 1000-2000 (прост трава) истансов. Естественно там все эти визибилити ренж, шейдерные манипуляции для материала и прочая хуйня, чтоб 200+ fps было. Но блять, в целом, похуй на количество пока память имеется?
>>59793
Нормально у тебя, не пыхти. Смотришь среднее железо по steam hardware survey, если на нем выдает 60+ то заебись.
Нормально у тебя, не пыхти. Смотришь среднее железо по steam hardware survey, если на нем выдает 60+ то заебись.
>>59796
А как это возможно? Или у тебя гипер-йоба-пк? Это же гарантированные тысячи вызовов отрисовки, не? Или у тебя дальность прорисовки 10 метров?
А как это возможно? Или у тебя гипер-йоба-пк? Это же гарантированные тысячи вызовов отрисовки, не? Или у тебя дальность прорисовки 10 метров?
>>59797
Там при приближении зума (вид как в ведьмаке условно) что-то около 100 метров. При удалении на высоту 20 метров че-то около 50 метров (тупо что в экран влезает)
Там при приближении зума (вид как в ведьмаке условно) что-то около 100 метров. При удалении на высоту 20 метров че-то около 50 метров (тупо что в экран влезает)
>>59800
Blender + скачанные нахаляву аддоны типо uvpackmaster + substance_painter если что-то не шибко сложное. Если самому вообще никак - пизжу и меняю до неузнаваемости.
Blender + скачанные нахаляву аддоны типо uvpackmaster + substance_painter если что-то не шибко сложное. Если самому вообще никак - пизжу и меняю до неузнаваемости.
>>59793
Их нужно аккуратнее использовать. Там когда хоть 1 инстанс на экране, будут отрисовываться все сразу.
Но куда важнее - физика. Что по физике?
Ориентируйся на "не более 100 тысяч" примерно... Разумеется, на топовом ПК может и миллион можно достичь, но ты же хочешь игру делать, а не нодами заполнять сцену. Дерево сцены однопоточное.
>>59797
На OpenGL. На Vulkan это больше не так, если у него одинаковые материалы. И, кажется, вызовы Vulkan намного дешевле. Но базовая пустая сцена дороже.
>мультимешей (прям пару десятков тысяч)
>до 1000-2000 (прост трава) истансов
Их нужно аккуратнее использовать. Там когда хоть 1 инстанс на экране, будут отрисовываться все сразу.
Но куда важнее - физика. Что по физике?
>количество нодов в игровой сцене
Ориентируйся на "не более 100 тысяч" примерно... Разумеется, на топовом ПК может и миллион можно достичь, но ты же хочешь игру делать, а не нодами заполнять сцену. Дерево сцены однопоточное.
>>59797
>гарантированные тысячи вызовов отрисовки
На OpenGL. На Vulkan это больше не так, если у него одинаковые материалы. И, кажется, вызовы Vulkan намного дешевле. Но базовая пустая сцена дороже.
>>59801
Кстати, касательно этого. Какими методами можно вычислить пизженую модель? Я не умею моделить лица, а потому просто вырезаю их из рандомных моделей и переделываю топологию и с нуля все текстуры. Могут спалить?
>Если самому вообще никак - пизжу и меняю до неузнаваемости.
Кстати, касательно этого. Какими методами можно вычислить пизженую модель? Я не умею моделить лица, а потому просто вырезаю их из рандомных моделей и переделываю топологию и с нуля все текстуры. Могут спалить?
>>59803
Насчёт количества инстансов то понятно, там кстати если около полусотни то уже профит от мультимеша.
Физика при взаимодействии с персонажем - шейдер всю работу делает (чекает позицию и вертит крутит эту суку) ну и ветер естественно. Коллизии как таковой нет. Вот что делать с деревьями пока вообще непонятно, там фокус с мультимешами не прокатит, модели разные, да и коллизии нужны.
Насчёт количества инстансов то понятно, там кстати если около полусотни то уже профит от мультимеша.
Физика при взаимодействии с персонажем - шейдер всю работу делает (чекает позицию и вертит крутит эту суку) ну и ветер естественно. Коллизии как таковой нет. Вот что делать с деревьями пока вообще непонятно, там фокус с мультимешами не прокатит, модели разные, да и коллизии нужны.
>>59805
Ну чисто теоретически если там vertex_group какие-то спрятаны и т.д., то конечно могут, но ты ж можешь всё удалить к ебени фени, так что если и топологии сменишь - то наверное никак. А вообще прям серьёзно за твою жопу вряд ли возьмутся.
Ну чисто теоретически если там vertex_group какие-то спрятаны и т.д., то конечно могут, но ты ж можешь всё удалить к ебени фени, так что если и топологии сменишь - то наверное никак. А вообще прям серьёзно за твою жопу вряд ли возьмутся.
Как вы геймдизайните свои игры?
Вот мне нравятся игры типа Degrees of Lewdity, не по эротике, а по взаимодействию с игровым миром и своенравными персонажами, свободой выбора по развитию своего персонажа и т.д. Но совершенно не понимаю, с чего такие игры начинаются. Пробовал прототипировать, но всё время что-то не то выходит. Теоретически, такой игре вообще графика не нужна, достаточно описания событий и кнопок, как в старой интерактивной литературе. Но всё равно придумать минимальный контент для начала не выходит.
Почему Godot? Пробовал Twine, но скриптинг там не нравится, поддержка слабая, и если захочется туда графики навернуть, то всё сильно усложняется. Я-то думал, там проще будет геймдизайнить, но нет...
Вот мне нравятся игры типа Degrees of Lewdity, не по эротике, а по взаимодействию с игровым миром и своенравными персонажами, свободой выбора по развитию своего персонажа и т.д. Но совершенно не понимаю, с чего такие игры начинаются. Пробовал прототипировать, но всё время что-то не то выходит. Теоретически, такой игре вообще графика не нужна, достаточно описания событий и кнопок, как в старой интерактивной литературе. Но всё равно придумать минимальный контент для начала не выходит.
Почему Godot? Пробовал Twine, но скриптинг там не нравится, поддержка слабая, и если захочется туда графики навернуть, то всё сильно усложняется. Я-то думал, там проще будет геймдизайнить, но нет...
>>59805
@
В чём смысл вырезать что-то откуда-то, если ты всё переделываешь начисто? От оригинала у тебя ж не остаётся ничего (судя по твоим словам), так в чём проблема открыть скриншот сетки в поисковике как референс и намоделить её самому себе?
В смысле, зачем искать и скачивать модели? Это ж лишняя работа получается. Мне вот лень. Ещё и регистрироваться часто заставляют, а всякие там файлопомойки и торренты только через прокси... Намного проще самому с нуля всё вылепить.
>просто вырезаю их из рандомных моделей
@
>переделываю топологию и с нуля все текстуры
В чём смысл вырезать что-то откуда-то, если ты всё переделываешь начисто? От оригинала у тебя ж не остаётся ничего (судя по твоим словам), так в чём проблема открыть скриншот сетки в поисковике как референс и намоделить её самому себе?
В смысле, зачем искать и скачивать модели? Это ж лишняя работа получается. Мне вот лень. Ещё и регистрироваться часто заставляют, а всякие там файлопомойки и торренты только через прокси... Намного проще самому с нуля всё вылепить.
>>59793
На каком железе с какой видеокартой и каким количеством памяти должно быть 200+ fps?
Вот когда я был моложе, то уменьшал окно dom 2 что бы он не тормозил. А сейчас могу в него играть с 200+ fps. Так что "зависитот железа" это база.
> чтоб 200+ fps было
На каком железе с какой видеокартой и каким количеством памяти должно быть 200+ fps?
Вот когда я был моложе, то уменьшал окно dom 2 что бы он не тормозил. А сейчас могу в него играть с 200+ fps. Так что "зависитот железа" это база.
>>59817
Ну, есть некоторый ориентир, чтобы вся эта хуерга игралась в 2к с фпс выше 100, учитывая что в игре пока околонихуя из того что нужно сделать
Ну, есть некоторый ориентир, чтобы вся эта хуерга игралась в 2к с фпс выше 100, учитывая что в игре пока околонихуя из того что нужно сделать
>>59806
Если лес плотный и большой, то LODы типа таких:
1. Независимые меши-деревья с физикой.
2. Группы деревьев 1 мешем без физики.
3. Билборды с кучкой деревьев вдалеке.
Всё это переключается от расстояния до игрока.
Можно делать меши и билборды процедурно...
Godot 3.6:
https://docs.godotengine.org/en/3.6/tutorials/3d/merge_groups.html
Godot 4.x:
https://docs.godotengine.org/en/stable/classes/class_arraymesh.html
Не хотят добавлять в 4.x, типа "на Vulkan нинужно".
Ну, в целом, согласен. Vulkan вроде сам объединяет.
>Вот что делать с деревьями
Если лес плотный и большой, то LODы типа таких:
1. Независимые меши-деревья с физикой.
2. Группы деревьев 1 мешем без физики.
3. Билборды с кучкой деревьев вдалеке.
Всё это переключается от расстояния до игрока.
Можно делать меши и билборды процедурно...
Godot 3.6:
https://docs.godotengine.org/en/3.6/tutorials/3d/merge_groups.html
Godot 4.x:
https://docs.godotengine.org/en/stable/classes/class_arraymesh.html
Не хотят добавлять в 4.x, типа "на Vulkan нинужно".
Ну, в целом, согласен. Vulkan вроде сам объединяет.
>>59817
А как ты в него играешь? Какой сервер?
>был моложе, то уменьшал окно dom 2
>А сейчас могу в него играть с 200+ fps
А как ты в него играешь? Какой сервер?
>>59818
1. Делаешь игру как поулчится.
2. Выпускаешь в ранний доступ с тормоза\ми лагами и багами.
3. На заработанные деньги нанимаешь настоящих разработчиков и они опиливают игру к релизу.
4. ???
5. PROFIT
1. Делаешь игру как поулчится.
2. Выпускаешь в ранний доступ с тормоза\ми лагами и багами.
3. На заработанные деньги нанимаешь настоящих разработчиков и они опиливают игру к релизу.
4. ???
5. PROFIT
>>59823
Проебываешься между 2 и 3 пунктом, зарабывая нихуя, и нанимаешь снова только себя за все тот же нихуя. Правильный подход - кормить нейро-концепт-артами на кикстартере и инфоцыганить себе фандрейзинг, спустя годы выпустить ерли акссес огрызок и съебать в туман.
Проебываешься между 2 и 3 пунктом, зарабывая нихуя, и нанимаешь снова только себя за все тот же нихуя. Правильный подход - кормить нейро-концепт-артами на кикстартере и инфоцыганить себе фандрейзинг, спустя годы выпустить ерли акссес огрызок и съебать в туман.
59 Кб, 612x542>>59823
У тебя неправильно, пофиксил:
У тебя неправильно, пофиксил:
>1. Делаешь игру как получится.
>2. Выпускаешь в ранний доступ с тормозами, лагами и багами.
>3. Пукаешь и обмякаешь с 10 отзывами.
>4. ???
>5. Ноешь на дваче, как ты 5 лет делал обновления к мертворождённой игре, а тебя твои же 3.5 игрока оскорбляют и унижают в отзывах к игре.
Кстати, пукну тут ещё. Кто-то находил или может реализовал (хотя я сомневаюсь) нормальный способ генерации heightmap? Я не имею ввиду взять шум Перлина или ещё какой и вот нате - горы и озёра, а где реализовано хоть какое-то подобие эрозии и пойм для рек.
>>59824
>>59825
Если ты нихуя не заработал на своем раннем доступе, то вероятно ты нихуя не заработаешь и вложив дохуя сил и времени. Идея изначально никому не нужна. С другой стороны посмотри на на титанов индустрии. 7 days to die вышла в релиз только потому, что так их пустят на коробокс. Игра спустя годы все такая же сырая. Но пилу нравится идея и каждый патч приносит онлайн и новые деньги. Так и живут.
>>59825
Если ты нихуя не заработал на своем раннем доступе, то вероятно ты нихуя не заработаешь и вложив дохуя сил и времени. Идея изначально никому не нужна. С другой стороны посмотри на на титанов индустрии. 7 days to die вышла в релиз только потому, что так их пустят на коробокс. Игра спустя годы все такая же сырая. Но пилу нравится идея и каждый патч приносит онлайн и новые деньги. Так и живут.
А как сделать генерацию карты как в дудл джампе? При этом чтобы пройденный путь сохранялся
>>59826
1. шум перлина всё равно нужен чтоб сгенерировать основу
2. реки можно создавать с помощью flow accumulation, начиная с наивысших точек в горах
3. что я понял после экспериментов с подобными генерациями - игра это не GIS, главное, чтобы было весело, а не чтоб было реалистично
1. шум перлина всё равно нужен чтоб сгенерировать основу
2. реки можно создавать с помощью flow accumulation, начиная с наивысших точек в горах
3. что я понял после экспериментов с подобными генерациями - игра это не GIS, главное, чтобы было весело, а не чтоб было реалистично
>>59827
Может, лучше свой успешный успех покажешь?
>>59828
Когда играл в Doodle Jump на J2ME, если память не изменяет, игра не позволяла двигаться вниз. Если оступился и полетел вниз - всё, Game Over. Да и с геймплейной точки зрения смысла в этом не вижу.
Если всё-таки хочешь сохранять, два варианта:
1. Использовать Noise.get_noise_1d(высота), чтоб генерировать путь из одного seed. Но это не будет правильно работать, если есть разрушаемость.
2. Сохранять сгенерированные данные в массив и загружать из него при движении вниз. Если объект разрушился, то удалять его и из массива тоже.
Но это, в любом случае, оптимизация. Помни, что, с одной стороны, маленький уровень может прямо нодами на сцене отображаться без проблем, однако, с другой стороны, уровень не может одновременно сохраняться с разрушаемостью и быть истинно бесконечным из-за ограничения по памяти.
Т.е. порядок действий такой:
1. Делаешь прототип генерации без оптимизаций - платформы сохраняются в сцене и не удаляются.
2. ЕСЛИ это слишком быстро приводит к тормозам - оптимизируешь удалением нод со сцены, сохраняя требуемую информацию в отдельном массиве.
3. ЕСЛИ по-прежнему упираешься в лимит из-за длительного геймплея - упрощай геймплей, удаляй возможность двигаться вниз/бесконечно вверх.
>Если ты не заработал на своем
>посмотри на на титанов индустрии
Может, лучше свой успешный успех покажешь?
>>59828
>генерацию карты как в дудл джампе?
>чтобы пройденный путь сохранялся
Когда играл в Doodle Jump на J2ME, если память не изменяет, игра не позволяла двигаться вниз. Если оступился и полетел вниз - всё, Game Over. Да и с геймплейной точки зрения смысла в этом не вижу.
Если всё-таки хочешь сохранять, два варианта:
1. Использовать Noise.get_noise_1d(высота), чтоб генерировать путь из одного seed. Но это не будет правильно работать, если есть разрушаемость.
2. Сохранять сгенерированные данные в массив и загружать из него при движении вниз. Если объект разрушился, то удалять его и из массива тоже.
Но это, в любом случае, оптимизация. Помни, что, с одной стороны, маленький уровень может прямо нодами на сцене отображаться без проблем, однако, с другой стороны, уровень не может одновременно сохраняться с разрушаемостью и быть истинно бесконечным из-за ограничения по памяти.
Т.е. порядок действий такой:
1. Делаешь прототип генерации без оптимизаций - платформы сохраняются в сцене и не удаляются.
2. ЕСЛИ это слишком быстро приводит к тормозам - оптимизируешь удалением нод со сцены, сохраняя требуемую информацию в отдельном массиве.
3. ЕСЛИ по-прежнему упираешься в лимит из-за длительного геймплея - упрощай геймплей, удаляй возможность двигаться вниз/бесконечно вверх.
>>59816
Ну смотри. Во первых не начисто, а просто чтобы не спалиться. Подергать сетку большого ума не надо. А во вторых: взять готовую голову, ремешнуть, немного поелозить кистью в скульпте, потом взять ретопофлоу и быриком накидать новую сетку - это не такая проблема, как собирать голову с нуля, особенно если ты кретин, как я. А у меня нет проблем с работой в блендере, у меня есть проблемы с моими художественными навыками. Сделать голову без эффекта зловещей долины сложнее, чем кажется. А что касается остального: тела там, хардсёрфейса - да, проще и лучше сделать самому.
Ну смотри. Во первых не начисто, а просто чтобы не спалиться. Подергать сетку большого ума не надо. А во вторых: взять готовую голову, ремешнуть, немного поелозить кистью в скульпте, потом взять ретопофлоу и быриком накидать новую сетку - это не такая проблема, как собирать голову с нуля, особенно если ты кретин, как я. А у меня нет проблем с работой в блендере, у меня есть проблемы с моими художественными навыками. Сделать голову без эффекта зловещей долины сложнее, чем кажется. А что касается остального: тела там, хардсёрфейса - да, проще и лучше сделать самому.
>>59842
Ну смотря какая разрушаемость. Максимум кувшинчики и то возможно нихуя не будет. В любом случае спасибо за наводку
Ну смотря какая разрушаемость. Максимум кувшинчики и то возможно нихуя не будет. В любом случае спасибо за наводку
>>59820
>>59806
Поделюсь своим говноопытом. Обоссыте или одобрите. Я резал вегетацию на чанки метров 200х200, ареа3Д, которая на сигнале подрубала чанку вычисления. Вычисления, соответственно меряли дистанцию до каждого инстанса пачками, переключали лоды и двигали несколько заготовленных коллизий к самым близлежащим деревьям. На неактивных чанках они уже щелкают коллизии для всех инстансов сразу. Ну и левелдизайнил локацию так, чтобы большую часть вегетации всегда закрывала какая нибудь гора и её можно было просто отключить.
>>59806
>Вот что делать с деревьями пока вообще непонятно, там фокус с мультимешами не прокатит, модели разные, да и коллизии нужны
Поделюсь своим говноопытом. Обоссыте или одобрите. Я резал вегетацию на чанки метров 200х200, ареа3Д, которая на сигнале подрубала чанку вычисления. Вычисления, соответственно меряли дистанцию до каждого инстанса пачками, переключали лоды и двигали несколько заготовленных коллизий к самым близлежащим деревьям. На неактивных чанках они уже щелкают коллизии для всех инстансов сразу. Ну и левелдизайнил локацию так, чтобы большую часть вегетации всегда закрывала какая нибудь гора и её можно было просто отключить.
>>59845
Ладно, что мешает взять бесплатную модель, где официально лицензия типа CC0/CC-BY, чтобы не заниматься воровством ассетов из чужих игр?
В стиле фотореализма? "Мультяшные" головы по определению не могут вызывать этот эффект, в особенности лоупольно-квадратные обрубовки. Т.е. буквально почти все инди-игры не могут дойти до "зловещей долины" из-за их стилизации.
Сколько миллиметров FOV в Blender у тебя? Там по умолчанию значение 50 mm - это норм для всяких моделей окружения, но для персонажей лучше 80+, поскольку работаешь с ними, приближая камеру, и стандартная перспектива делает их "жуткими" по причине несоответствия FOV расстоянию до лица.
ВНЕЗАПНО очень не очевидный, но факт. Долго не понимал, почему так всрато выходит, пока это не нагуглил. И ведь в подсказках Blender этого нет!
>>59844
Нет, у меня никогда не было успехов.
>>59846
Меньше думай, больше прототипируй и тестируй.
>>59848
Вроде нормально. А насколько выгоднее двигать существующие статичные коллизии по чанку по сравнению с добавлением/удалением? Мне такое в голову вообще не приходило - спасибо за идею.
>просто чтобы не спалиться
Ладно, что мешает взять бесплатную модель, где официально лицензия типа CC0/CC-BY, чтобы не заниматься воровством ассетов из чужих игр?
>Сделать голову без эффекта зловещей долины
В стиле фотореализма? "Мультяшные" головы по определению не могут вызывать этот эффект, в особенности лоупольно-квадратные обрубовки. Т.е. буквально почти все инди-игры не могут дойти до "зловещей долины" из-за их стилизации.
Сколько миллиметров FOV в Blender у тебя? Там по умолчанию значение 50 mm - это норм для всяких моделей окружения, но для персонажей лучше 80+, поскольку работаешь с ними, приближая камеру, и стандартная перспектива делает их "жуткими" по причине несоответствия FOV расстоянию до лица.
ВНЕЗАПНО очень не очевидный, но факт. Долго не понимал, почему так всрато выходит, пока это не нагуглил. И ведь в подсказках Blender этого нет!
>>59844
>А ты свой покажешь?
Нет, у меня никогда не было успехов.
>>59846
Меньше думай, больше прототипируй и тестируй.
>>59848
Вроде нормально. А насколько выгоднее двигать существующие статичные коллизии по чанку по сравнению с добавлением/удалением? Мне такое в голову вообще не приходило - спасибо за идею.
>>59853
Лол. Я что-то слышал об этом, но не использовал. Нужно будет попробовать
А вообще даже СС0 хочется переделать. От греха подальше. Может быть я просто шиз.
Я не могу сказать в цифрах, но вообще у меня эта идея возникла когда я увидел на ютубе лайфхак, что всякие пули, стрелы и прочие фаерболы дешевле держать заранее интанциироваными где нибудь в инвизе и в нужный момент задействовать. По моему это достаточно очевидно, что двигать дешевле, чем инстанциировать, так что возможно я тебя не понял. Если у тебя, условно, 1000 деревьев на чанк и за одну пачку/кадр ты проверяешь, скажем 50 инстансов, при этом весь чанк наполнен лесом, значит в теории у тебя может произойти несколько кадров подряд, которые инстанциируют все 50 коллайдеров махом. Как по мне - жирно. А если ты будешь ограничиваться небольшим колличеством коллизий, скажем 5 штук максимум - значит эти коллизии будут дрочиться постоянно, что тоже малоприятно.
В моем частном случае экспериментально выяснилось, что держать больше 3 коллизий на каждый мультимеш в сцене, при должной настройке расстояния и обновления просто бессмысленно. А с учетом того, что ты всеравно чекаешь расстояния ради лодов - коллизии происходят практически бесплатно
>Сколько миллиметров FOV в Blender у тебя?
>ВНЕЗАПНО очень не очевидный, но факт
Лол. Я что-то слышал об этом, но не использовал. Нужно будет попробовать
А вообще даже СС0 хочется переделать. От греха подальше. Может быть я просто шиз.
>А насколько выгоднее двигать существующие статичные коллизии по чанку по сравнению с добавлением/удалением?
Я не могу сказать в цифрах, но вообще у меня эта идея возникла когда я увидел на ютубе лайфхак, что всякие пули, стрелы и прочие фаерболы дешевле держать заранее интанциироваными где нибудь в инвизе и в нужный момент задействовать. По моему это достаточно очевидно, что двигать дешевле, чем инстанциировать, так что возможно я тебя не понял. Если у тебя, условно, 1000 деревьев на чанк и за одну пачку/кадр ты проверяешь, скажем 50 инстансов, при этом весь чанк наполнен лесом, значит в теории у тебя может произойти несколько кадров подряд, которые инстанциируют все 50 коллайдеров махом. Как по мне - жирно. А если ты будешь ограничиваться небольшим колличеством коллизий, скажем 5 штук максимум - значит эти коллизии будут дрочиться постоянно, что тоже малоприятно.
В моем частном случае экспериментально выяснилось, что держать больше 3 коллизий на каждый мультимеш в сцене, при должной настройке расстояния и обновления просто бессмысленно. А с учетом того, что ты всеравно чекаешь расстояния ради лодов - коллизии происходят практически бесплатно
Эх, когда ж эту хуету переделают. Алсо никто не пробовал объединять мультимеши при удалении от них и наоборот, стоит того?
>>59864 (Del)
Крупный проект на дваче не сделают. Ох уж эти переживания уровня "а что если иноплоны прилетят и в жопу выебут". Но ок, чтобы не переживать - берешь и используешь ассеты надежных авторов вроде Кенни или Кватерниуса с их официального сайта.
>крупный проект
Крупный проект на дваче не сделают. Ох уж эти переживания уровня "а что если иноплоны прилетят и в жопу выебут". Но ок, чтобы не переживать - берешь и используешь ассеты надежных авторов вроде Кенни или Кватерниуса с их официального сайта.
>>59887
Разобрался, это только Forward+ такое делает какой-то оптимизацией
Разобрался, это только Forward+ такое делает какой-то оптимизацией
81 Кб, 1062x1080Всё, почаны. Я научился сохранять инвенторь. Я очень долго тянул с этим, так как у меня там в коде инвентаря очень запутамные зависимости между слотом и индексом и индексом в массиве и хуй проссыш что из них инициирует синхронизацию и на что влияет, короче я сам не понимал чего там напогромировал. В результате собрал сохранение за 15 минут через подсадный временный массив и еще через 15 минут задебажил. (инвенторь как в условной террарии)
Вот это я малорик, пиздец просто. Не могу об этом молчать
Вот это я малорик, пиздец просто. Не могу об этом молчать
>>59909
Найду в твоей реализации сохранений 666 багов и приду ныть на твой итч.
Найду в твоей реализации сохранений 666 багов и приду ныть на твой итч.
>>59909
Малаца! Успехов тебе!
>>59919
Не стоит. Судя по описаниям там одноразовая лапша. Лучше свари свою себе сам.
Инвентарь это просто массив. Поверх массива просто 4 удобные КРУД-функции для работы с ним. Визуальное отображение инвентаря это просто контейнерный виджет, у которого есть возможность хранить список элементов. Список элементов просто грузится из массива. Ну и всё.
Малаца! Успехов тебе!
>>59919
Не стоит. Судя по описаниям там одноразовая лапша. Лучше свари свою себе сам.
Инвентарь это просто массив. Поверх массива просто 4 удобные КРУД-функции для работы с ним. Визуальное отображение инвентаря это просто контейнерный виджет, у которого есть возможность хранить список элементов. Список элементов просто грузится из массива. Ну и всё.
895 Кб, 1465x744Годот и Блендер на анонсе нового железа от Валв. Индекс там, контроллер, машины и все такое.
https://www.youtube.com/watch?v=OmKrKTwtukE
https://www.youtube.com/watch?v=OmKrKTwtukE
607 Кб, 785x719>>59948
Да че ты доебался? Я имею представление как должен быть устроен инвентарь. Да и я всего полгода игры делою. Имею право на ошибку.
По сути у меня контроллер с массивом в корне сцены и визуальные слоты-кнопки. Слот хранит индекс массива, к которому привязан. Я перетягиваю предмет из слота в слот, слот его по сигналу ловит, обновляет иконку и регает в массив отталкиваясь от своего индекса. Но при загрузке то я сначала в массив всё запихаю и оттуда уже должен обновить иконки а у меня так не предусмотрено было
В общей сложности всё занимает строк 100-150, максимум 200. Поддерживает дроп через перетаскивание, контекстное меню, хинты и слоты для особых категорий предметов (правда для них я целый класс высрал).
Че, прям хуево напогромировал? Ну хоть не ассетфлипаю
>Судя по описаниям там одноразовая лапша
Да че ты доебался? Я имею представление как должен быть устроен инвентарь. Да и я всего полгода игры делою. Имею право на ошибку.
По сути у меня контроллер с массивом в корне сцены и визуальные слоты-кнопки. Слот хранит индекс массива, к которому привязан. Я перетягиваю предмет из слота в слот, слот его по сигналу ловит, обновляет иконку и регает в массив отталкиваясь от своего индекса. Но при загрузке то я сначала в массив всё запихаю и оттуда уже должен обновить иконки а у меня так не предусмотрено было
В общей сложности всё занимает строк 100-150, максимум 200. Поддерживает дроп через перетаскивание, контекстное меню, хинты и слоты для особых категорий предметов (правда для них я целый класс высрал).
Че, прям хуево напогромировал? Ну хоть не ассетфлипаю
>>59909
охуеть бро, я как раз вчера тоже починил сохранение инвентаря. тоже не мог разобраться че я там наговнокодил, что за проблемы были. то перезаписывало что-то сохранение, то индексы неправильные, то свойства предметов не восстанавливались. но тоже починил и тоже доволен как слон. поздравляю тя
охуеть бро, я как раз вчера тоже починил сохранение инвентаря. тоже не мог разобраться че я там наговнокодил, что за проблемы были. то перезаписывало что-то сохранение, то индексы неправильные, то свойства предметов не восстанавливались. но тоже починил и тоже доволен как слон. поздравляю тя
574 Кб, 1261x702дай бог скоро доделать..
Как сохранить кастомный класс, точней словарь с классами?
Типа var _data: Dictionary[Vector2i, ClassData]
JSON.stringify не работает
var_to_bytes_with_objects не работает
Marshalls.variant_to_base64 не работает
FileAccess.store_var не работает
Документация https://docs.godotengine.org/en/4.5/tutorials/io/binary_serialization_api.html нещадно устарела и свежий комментарий 7 октября об этом напиминает (с небинарном Калинхоу которое говорит, что да, вот у нас ишьюе висит с 2021 года)
ебанулись вообще
Типа var _data: Dictionary[Vector2i, ClassData]
JSON.stringify не работает
var_to_bytes_with_objects не работает
Marshalls.variant_to_base64 не работает
FileAccess.store_var не работает
Документация https://docs.godotengine.org/en/4.5/tutorials/io/binary_serialization_api.html нещадно устарела и свежий комментарий 7 октября об этом напиминает (с небинарном Калинхоу которое говорит, что да, вот у нас ишьюе висит с 2021 года)
ебанулись вообще
>>60008
Я б вообще такой хуйнёй не занимался, а написал бы классу кастомные функции to_json и from_json. Потому что, помимо прочего, сохранять целые объекты - это рукожопно и небезопасно, были сообщения о вирусах, которые это используют.
>сохранить кастомный класс
Я б вообще такой хуйнёй не занимался, а написал бы классу кастомные функции to_json и from_json. Потому что, помимо прочего, сохранять целые объекты - это рукожопно и небезопасно, были сообщения о вирусах, которые это используют.
>>60019
В смысле там автоматически что-то сработает или имешь ввиду самому вызывать эти методы? Мне же ещё нужно сопоставить их с Vector2i
это есть во многих языках, а предупреждение о вредоносном коде потому что, скорее всего, в сетевой игре кто-то гонял сериализированные объекты и читеры свой скрипт прописывали в привязанном классе
>а написал бы классу кастомные функции to_json и from_json
В смысле там автоматически что-то сработает или имешь ввиду самому вызывать эти методы? Мне же ещё нужно сопоставить их с Vector2i
>сохранять целые объекты - это рукожопно и небезопасно, были сообщения о вирусах, которые это используют
это есть во многих языках, а предупреждение о вредоносном коде потому что, скорее всего, в сетевой игре кто-то гонял сериализированные объекты и читеры свой скрипт прописывали в привязанном классе
>>60019
Если кто-то, в моей синглплеерной игре, скачивает из интернета хуй пойми какие сейвы, моды или плагины к ней - я за это ответственность не несу. АААА дядям на это поебать, а вы уже какой год беситесь-носитесь с этой хуйней, и требуете чтобы у соло-индюков было все надежней чем у АААА. Хуй. Как сохранял так и буду сохранять, сами ебитесь со своей "безопасностью".
>сохранять целые объекты - это рукожопно и небезопасно, были сообщения о вирусах, которые это используют
Если кто-то, в моей синглплеерной игре, скачивает из интернета хуй пойми какие сейвы, моды или плагины к ней - я за это ответственность не несу. АААА дядям на это поебать, а вы уже какой год беситесь-носитесь с этой хуйней, и требуете чтобы у соло-индюков было все надежней чем у АААА. Хуй. Как сохранял так и буду сохранять, сами ебитесь со своей "безопасностью".
>>59993
Ты в бинарном виде записываешь что ли? Боишься, игрок считерит?
>>60008
Другой анон правильно заявил: >>60019
Т.е. будет что-то наподобие этого:
Либо можешь сделать свой ClassData потомком Resource.
>>60021
Если хочешь автоматически, тебе нужен этот обработчик:
Это должно автоматически использоваться в методе var_to_string().
Подробнее смотри в документации по to_string() и _to_string():
https://docs.godotengine.org/en/stable/classes/class_object.html
>то перезаписывало что-то сохранение, то индексы неправильные
Ты в бинарном виде записываешь что ли? Боишься, игрок считерит?
>>60008
>Как сохранить кастомный класс, точней словарь с классами?
Другой анон правильно заявил: >>60019
>написал бы классу кастомные функции to_json и from_json
Т.е. будет что-то наподобие этого:
>var data: Dictionary[Vector2i, ClassData]
>var data_prepared: Dictionary[Vector2i, Dictionary]
>for key in data.keys():
>_ data_prepared[key] = data[key].to_json()
>var result := JSON.stringify(data_prepared)
Либо можешь сделать свой ClassData потомком Resource.
>>60021
>В смысле там автоматически что-то сработает
Если хочешь автоматически, тебе нужен этот обработчик:
>func _to_string() -> String:
>_ return "какие-то твои данные в виде строки"
Это должно автоматически использоваться в методе var_to_string().
Подробнее смотри в документации по to_string() и _to_string():
https://docs.godotengine.org/en/stable/classes/class_object.html
>>60100
да нет, я новичок совсем, сам до конца не понял как это вышло
да нет, я новичок совсем, сам до конца не понял как это вышло
>>60100
Поправка №1: я имел в виду функцию var_to_str(), конечно же.
Поправка №2:
- на var_to_str() обработчик _to_string() не влияет;
- _to_string() влияет на str() и на JSON.stringify().
Но JSON.stringify() рассматривает классы как строки:
Т.е. вместо "метки класса" получается такая строка.
>Это должно автоматически использоваться в методе var_to_string().
Поправка №1: я имел в виду функцию var_to_str(), конечно же.
Поправка №2:
- на var_to_str() обработчик _to_string() не влияет;
- _to_string() влияет на str() и на JSON.stringify().
Но JSON.stringify() рассматривает классы как строки:
>{
>"(0, 0)": "[5, 6.9, [1, 2, 3], \"Data\"]",
>"(0, 1)": "[5, 6.9, [1, 2, 3], \"Data\"]",
>"(1, 0)": "[5, 6.9, [1, 2, 3], \"Data\"]",
>"(1, 1)": "[5, 6.9, [1, 2, 3], \"Data\"]"
>}
Т.е. вместо "метки класса" получается такая строка.
34 Кб, 950x770>>60008
Короче, если хочешь САМЫЙ ПРОСТОЙ способ сериализации:
Просто делаешь свой класс потомком Resource:
https://docs.godotengine.org/en/stable/classes/class_resource.html
Так ты можешь хранить свои классы как "tres", пикрил.
Недостатки подхода с форматом "tres":
1. Если формат хранения Godot внезапно изменится - сейвы сломаются.
2. Если ты изменишь и пути файлов, и UID скриптов - сейвы сломаются.
3. Если ты переименуешь свои классы-контейнеры - сейвы сломаются.
4. Игроку могут подкинуть "вирусный" tres с кодом на GDScript, лол.
5. Формат tres жирный - много лишних данных, дольше грузится.
На счёт "поломок сейвов" не уверен, но там много подводных камней.
Но вот "сломанный tres" на компе игрока будет сложно пофиксить...
Если хочешь избавиться от этих недостатков:
- Пишешь свой кастомный ResourceFormatSaver:
https://docs.godotengine.org/en/stable/classes/class_resourceformatsaver.html
- Пишешь свой кастомный ResourceFormatLoader:
https://docs.godotengine.org/en/stable/classes/class_resourceformatloader.html
Под капотом можешь использовать абсолютно любой формат.
При этом твои данные будут доступны в инспекторе "как родные".
Короче, если хочешь САМЫЙ ПРОСТОЙ способ сериализации:
>Как сохранить кастомный класс, точней словарь с классами?
Просто делаешь свой класс потомком Resource:
https://docs.godotengine.org/en/stable/classes/class_resource.html
Так ты можешь хранить свои классы как "tres", пикрил.
Недостатки подхода с форматом "tres":
1. Если формат хранения Godot внезапно изменится - сейвы сломаются.
2. Если ты изменишь и пути файлов, и UID скриптов - сейвы сломаются.
3. Если ты переименуешь свои классы-контейнеры - сейвы сломаются.
4. Игроку могут подкинуть "вирусный" tres с кодом на GDScript, лол.
5. Формат tres жирный - много лишних данных, дольше грузится.
На счёт "поломок сейвов" не уверен, но там много подводных камней.
Но вот "сломанный tres" на компе игрока будет сложно пофиксить...
Если хочешь избавиться от этих недостатков:
- Пишешь свой кастомный ResourceFormatSaver:
https://docs.godotengine.org/en/stable/classes/class_resourceformatsaver.html
- Пишешь свой кастомный ResourceFormatLoader:
https://docs.godotengine.org/en/stable/classes/class_resourceformatloader.html
Под капотом можешь использовать абсолютно любой формат.
При этом твои данные будут доступны в инспекторе "как родные".
28 Кб, 540x470>>60111
А, да, можно ещё в бинарный "res" сохранить, он чуть полегче.
Но если бинарный сейв сломается, то вручную не пофиксить.
На пикриле пример сохранения кастомных ресурсов как "res".
"RSCC" - это, как я понимаю, сигнатура ресурсов Godot...
>Так ты можешь хранить свои классы как "tres", пикрил.
>Формат tres жирный - много лишних данных, дольше грузится.
А, да, можно ещё в бинарный "res" сохранить, он чуть полегче.
Но если бинарный сейв сломается, то вручную не пофиксить.
На пикриле пример сохранения кастомных ресурсов как "res".
"RSCC" - это, как я понимаю, сигнатура ресурсов Godot...
1,4 Мб, 1280x720https://godotengine.org/article/dev-snapshot-godot-3-7-dev-1/
Долгожданный 3.7 дев 1. Интерполяция 3д физики, улучшенный перформанс, блоб тени, багфиксы и что-то для звука, хз что.
Долгожданный 3.7 дев 1. Интерполяция 3д физики, улучшенный перформанс, блоб тени, багфиксы и что-то для звука, хз что.
>>60118
Я надеюсь, к Godot 5.0 у них дойдёт до ума вернуть GLES2/GLES3 и объединить Godot 3.6+ с Godot 4.6+ так, чтобы юзер мог получить НОРМАЛЬНЫЙ Compatibility рендерер БЕЗ тупо ненужных инструкций SSE3/SSE4/AVX/AVX2, и одновременно с этим - обновленный GDScript, улучшения GUI редактора и прочее. Они не могут бэкпортнуть GDScript и GUI на Godot 3.6+ потому, что "некому этим заниматься", а в Godot 4.6+ отсутствует нормальный редерер потому, что якобы "новый RenderDevice не может в OpenGL" или что-то вроде того. Если смогут преодолеть эти проблемы хотя бы к Godot 5.0, было бы замечательно...
Я надеюсь, к Godot 5.0 у них дойдёт до ума вернуть GLES2/GLES3 и объединить Godot 3.6+ с Godot 4.6+ так, чтобы юзер мог получить НОРМАЛЬНЫЙ Compatibility рендерер БЕЗ тупо ненужных инструкций SSE3/SSE4/AVX/AVX2, и одновременно с этим - обновленный GDScript, улучшения GUI редактора и прочее. Они не могут бэкпортнуть GDScript и GUI на Godot 3.6+ потому, что "некому этим заниматься", а в Godot 4.6+ отсутствует нормальный редерер потому, что якобы "новый RenderDevice не может в OpenGL" или что-то вроде того. Если смогут преодолеть эти проблемы хотя бы к Godot 5.0, было бы замечательно...
>>60124
К 5.0 таких девайсов практически не остается. Это как сегодня под 3Dfx пилить.
К 5.0 таких девайсов практически не остается. Это как сегодня под 3Dfx пилить.
>>60118
Я не так давно в годоте, не застал версию 3.х. Нахуя они две версии параллельно развивают?
Я не так давно в годоте, не застал версию 3.х. Нахуя они две версии параллельно развивают?
>>60133
Потому что некоторые из нас все же сделали игры, и их надо поддерживать-развивать-обновлять, а переводить давно релизнутое на новую 4.х слишком дорогое удовольствие. Эпики тоже старую версию анрила поддерживают, про юнити не знаю.
Потому что некоторые из нас все же сделали игры, и их надо поддерживать-развивать-обновлять, а переводить давно релизнутое на новую 4.х слишком дорогое удовольствие. Эпики тоже старую версию анрила поддерживают, про юнити не знаю.
>>60133
C# веб экспорт (и прочие экспорты типа сыча/консолей) без хуйни, есть куча релизов поддерживаемых на тройке, да и развитие тройки после 3.5 это скорее не развитие, а та самая припарка мертвому, чтоб не вонял так сильно.
C# веб экспорт (и прочие экспорты типа сыча/консолей) без хуйни, есть куча релизов поддерживаемых на тройке, да и развитие тройки после 3.5 это скорее не развитие, а та самая припарка мертвому, чтоб не вонял так сильно.
>>60128
Каких "таких"? Давно известно, что Vulkan/DX12 по определению более прожорливый чем OpenGL и предназначается исключительно для топовых АААА шедевров 3D фотореализма, а не для 2D игр и тем более GUI-шных приложений. Оптимизировать его до уровня OpenGL просто невозможно из-за неких архитектурных ограничений в спецификации.
3dfx умер в 2002, не нужно с ним сравнивать широко распространённый стандарт OpenGL.
Вот мой телефон вышел в продажу в августе 2019, т.е. совсем недавно - формально он поддерживает Vulkan Mobile, но Godot 4 моментально нагревает этот телефон выводом одной png картинки в 2D на вулкане, загружая CPU/GPU на максимум, будто бы я в Minecraft играю. Если я выберу Compatibility, тогда Godot 4 просто не может анимировать эту png картинку как Polygon, потому что Compatibility багнутый и всем на него глубоко насрать (на Vulkan Mobile анимирует). Если даунгрейднуться до Godot 3.6, то картинка и выводится, и анимируется с минимальной нагрузкой, так что телефон не начинает греть руки, хотя всё равно нагрузка в разы выше классических приложений Android.
Телефон менять я не планирую, потому что аккумулятор спустя 5 лет почти ежедневного использования всё ещё держится 10+ часов на одном заряде и все нужные приложения не тормозят, а в АААА 3D фотореализм я всё равно никогда не играл и не буду играть. К тому же сейчас телефоны по-дебильному выглядят... Но даже если взять современные смартфоны последнего поколения, и допустить, что Vulkan загружает GPU на 50%, а не на 100%, то решение на OpenGL должно нагружать на 5% вместо 15%, просто потому что GPU стала экономичнее и быстрее в целом, а не по частям. В любом случае получается экономия заряда аккумулятора, который из смартфонов никуда не делся и вряд ли когда-либо денется (все альтернативы пукнули и обмякли из-за проблем с безопасностью).
Но даже если взять компьютеры, очень многие до сих пор сидят на NVIDIA 600/700-х поколений, да и если даже поднять до 1000-го поколения, они продолжат работать ещё лет десять как минимум. CPU без поддержки SSE4.2 последний раз выпускалось считанные 2-3 года назад, и наверняка целевая аудитория этих CPU просто не может купить что-то новое в ближайшее десятилетие. На вторичном рынке CPU из конца 00-х/начала 10-х будут ещё лет пять-десять как минимум обращаться, особенно в нищих странах. Предлагаешь положить болт на всех них только из-за того, что Steam решил обрубить поддержку Windows до десятки?
Я могу понять требования, например, Blender - потому что это инструмент разработчика. Blender не нужно запускать на условном встроенном компьютере умного холодильника, потому что результат работы Blender - это в основном плоские картинки - рендеры, или информация о моделях и сценах для других программ. Blender оправданно требует более мощный ПК разработчика. А Godot-редактор должен запускаться на том же компьютере, что и финальная Godot-игра - если редактор повышает требования к устройству, то и игра повышает требования. Это недопустимо для движка, рассчитанного на максимально широкую аудиторию с самым низким порогом входа.
Недавно обсуждали страны - ты думаешь, в Бразилии пользователи Godot все сидят за топовыми ПК 2025 года и ходят с флагманскими смартфонами 2025 года? Или ты считаешь, что отрезать бОльшую часть тех же бразильцев, индийцев, китайцев и т.д. - это оправданная жертва ради малого процента самых богатых игроков из США?
ААА игры не начнут внезапно разрабатывать на Godot, если он просто станет недоступен для слабых машин. Условная GTA 5 вышла в 2013 и работает на железе из 00-х, но выглядит круто даже в 2025, и ни одна из последующих ААА пока не смогла побить её в графическом плане (если отбросить всё лишнее вроде "лучей", которые в Godot всё равно до сих пор не поддерживаются, поэтому не имеют значения). Godot пока что не настолько крут, как движок Rockstar (RAGE 2), но уже ограничивает сферу своего применения сильнее него. Это, по-твоему, нормально?
Короче, я жду от Godot укрепление на инди-рынке, а не убегание в сторону недоступных инди ААА-проектов.
>таких девайсов
Каких "таких"? Давно известно, что Vulkan/DX12 по определению более прожорливый чем OpenGL и предназначается исключительно для топовых АААА шедевров 3D фотореализма, а не для 2D игр и тем более GUI-шных приложений. Оптимизировать его до уровня OpenGL просто невозможно из-за неких архитектурных ограничений в спецификации.
>Это как сегодня под 3Dfx пилить.
3dfx умер в 2002, не нужно с ним сравнивать широко распространённый стандарт OpenGL.
Вот мой телефон вышел в продажу в августе 2019, т.е. совсем недавно - формально он поддерживает Vulkan Mobile, но Godot 4 моментально нагревает этот телефон выводом одной png картинки в 2D на вулкане, загружая CPU/GPU на максимум, будто бы я в Minecraft играю. Если я выберу Compatibility, тогда Godot 4 просто не может анимировать эту png картинку как Polygon, потому что Compatibility багнутый и всем на него глубоко насрать (на Vulkan Mobile анимирует). Если даунгрейднуться до Godot 3.6, то картинка и выводится, и анимируется с минимальной нагрузкой, так что телефон не начинает греть руки, хотя всё равно нагрузка в разы выше классических приложений Android.
Телефон менять я не планирую, потому что аккумулятор спустя 5 лет почти ежедневного использования всё ещё держится 10+ часов на одном заряде и все нужные приложения не тормозят, а в АААА 3D фотореализм я всё равно никогда не играл и не буду играть. К тому же сейчас телефоны по-дебильному выглядят... Но даже если взять современные смартфоны последнего поколения, и допустить, что Vulkan загружает GPU на 50%, а не на 100%, то решение на OpenGL должно нагружать на 5% вместо 15%, просто потому что GPU стала экономичнее и быстрее в целом, а не по частям. В любом случае получается экономия заряда аккумулятора, который из смартфонов никуда не делся и вряд ли когда-либо денется (все альтернативы пукнули и обмякли из-за проблем с безопасностью).
Но даже если взять компьютеры, очень многие до сих пор сидят на NVIDIA 600/700-х поколений, да и если даже поднять до 1000-го поколения, они продолжат работать ещё лет десять как минимум. CPU без поддержки SSE4.2 последний раз выпускалось считанные 2-3 года назад, и наверняка целевая аудитория этих CPU просто не может купить что-то новое в ближайшее десятилетие. На вторичном рынке CPU из конца 00-х/начала 10-х будут ещё лет пять-десять как минимум обращаться, особенно в нищих странах. Предлагаешь положить болт на всех них только из-за того, что Steam решил обрубить поддержку Windows до десятки?
Я могу понять требования, например, Blender - потому что это инструмент разработчика. Blender не нужно запускать на условном встроенном компьютере умного холодильника, потому что результат работы Blender - это в основном плоские картинки - рендеры, или информация о моделях и сценах для других программ. Blender оправданно требует более мощный ПК разработчика. А Godot-редактор должен запускаться на том же компьютере, что и финальная Godot-игра - если редактор повышает требования к устройству, то и игра повышает требования. Это недопустимо для движка, рассчитанного на максимально широкую аудиторию с самым низким порогом входа.
Недавно обсуждали страны - ты думаешь, в Бразилии пользователи Godot все сидят за топовыми ПК 2025 года и ходят с флагманскими смартфонами 2025 года? Или ты считаешь, что отрезать бОльшую часть тех же бразильцев, индийцев, китайцев и т.д. - это оправданная жертва ради малого процента самых богатых игроков из США?
ААА игры не начнут внезапно разрабатывать на Godot, если он просто станет недоступен для слабых машин. Условная GTA 5 вышла в 2013 и работает на железе из 00-х, но выглядит круто даже в 2025, и ни одна из последующих ААА пока не смогла побить её в графическом плане (если отбросить всё лишнее вроде "лучей", которые в Godot всё равно до сих пор не поддерживаются, поэтому не имеют значения). Godot пока что не настолько крут, как движок Rockstar (RAGE 2), но уже ограничивает сферу своего применения сильнее него. Это, по-твоему, нормально?
Короче, я жду от Godot укрепление на инди-рынке, а не убегание в сторону недоступных инди ААА-проектов.
>>60128
Каких "таких"? Давно известно, что Vulkan/DX12 по определению более прожорливый чем OpenGL и предназначается исключительно для топовых АААА шедевров 3D фотореализма, а не для 2D игр и тем более GUI-шных приложений. Оптимизировать его до уровня OpenGL просто невозможно из-за неких архитектурных ограничений в спецификации.
3dfx умер в 2002, не нужно с ним сравнивать широко распространённый стандарт OpenGL.
Вот мой телефон вышел в продажу в августе 2019, т.е. совсем недавно - формально он поддерживает Vulkan Mobile, но Godot 4 моментально нагревает этот телефон выводом одной png картинки в 2D на вулкане, загружая CPU/GPU на максимум, будто бы я в Minecraft играю. Если я выберу Compatibility, тогда Godot 4 просто не может анимировать эту png картинку как Polygon, потому что Compatibility багнутый и всем на него глубоко насрать (на Vulkan Mobile анимирует). Если даунгрейднуться до Godot 3.6, то картинка и выводится, и анимируется с минимальной нагрузкой, так что телефон не начинает греть руки, хотя всё равно нагрузка в разы выше классических приложений Android.
Телефон менять я не планирую, потому что аккумулятор спустя 5 лет почти ежедневного использования всё ещё держится 10+ часов на одном заряде и все нужные приложения не тормозят, а в АААА 3D фотореализм я всё равно никогда не играл и не буду играть. К тому же сейчас телефоны по-дебильному выглядят... Но даже если взять современные смартфоны последнего поколения, и допустить, что Vulkan загружает GPU на 50%, а не на 100%, то решение на OpenGL должно нагружать на 5% вместо 15%, просто потому что GPU стала экономичнее и быстрее в целом, а не по частям. В любом случае получается экономия заряда аккумулятора, который из смартфонов никуда не делся и вряд ли когда-либо денется (все альтернативы пукнули и обмякли из-за проблем с безопасностью).
Но даже если взять компьютеры, очень многие до сих пор сидят на NVIDIA 600/700-х поколений, да и если даже поднять до 1000-го поколения, они продолжат работать ещё лет десять как минимум. CPU без поддержки SSE4.2 последний раз выпускалось считанные 2-3 года назад, и наверняка целевая аудитория этих CPU просто не может купить что-то новое в ближайшее десятилетие. На вторичном рынке CPU из конца 00-х/начала 10-х будут ещё лет пять-десять как минимум обращаться, особенно в нищих странах. Предлагаешь положить болт на всех них только из-за того, что Steam решил обрубить поддержку Windows до десятки?
Я могу понять требования, например, Blender - потому что это инструмент разработчика. Blender не нужно запускать на условном встроенном компьютере умного холодильника, потому что результат работы Blender - это в основном плоские картинки - рендеры, или информация о моделях и сценах для других программ. Blender оправданно требует более мощный ПК разработчика. А Godot-редактор должен запускаться на том же компьютере, что и финальная Godot-игра - если редактор повышает требования к устройству, то и игра повышает требования. Это недопустимо для движка, рассчитанного на максимально широкую аудиторию с самым низким порогом входа.
Недавно обсуждали страны - ты думаешь, в Бразилии пользователи Godot все сидят за топовыми ПК 2025 года и ходят с флагманскими смартфонами 2025 года? Или ты считаешь, что отрезать бОльшую часть тех же бразильцев, индийцев, китайцев и т.д. - это оправданная жертва ради малого процента самых богатых игроков из США?
ААА игры не начнут внезапно разрабатывать на Godot, если он просто станет недоступен для слабых машин. Условная GTA 5 вышла в 2013 и работает на железе из 00-х, но выглядит круто даже в 2025, и ни одна из последующих ААА пока не смогла побить её в графическом плане (если отбросить всё лишнее вроде "лучей", которые в Godot всё равно до сих пор не поддерживаются, поэтому не имеют значения). Godot пока что не настолько крут, как движок Rockstar (RAGE 2), но уже ограничивает сферу своего применения сильнее него. Это, по-твоему, нормально?
Короче, я жду от Godot укрепление на инди-рынке, а не убегание в сторону недоступных инди ААА-проектов.
>таких девайсов
Каких "таких"? Давно известно, что Vulkan/DX12 по определению более прожорливый чем OpenGL и предназначается исключительно для топовых АААА шедевров 3D фотореализма, а не для 2D игр и тем более GUI-шных приложений. Оптимизировать его до уровня OpenGL просто невозможно из-за неких архитектурных ограничений в спецификации.
>Это как сегодня под 3Dfx пилить.
3dfx умер в 2002, не нужно с ним сравнивать широко распространённый стандарт OpenGL.
Вот мой телефон вышел в продажу в августе 2019, т.е. совсем недавно - формально он поддерживает Vulkan Mobile, но Godot 4 моментально нагревает этот телефон выводом одной png картинки в 2D на вулкане, загружая CPU/GPU на максимум, будто бы я в Minecraft играю. Если я выберу Compatibility, тогда Godot 4 просто не может анимировать эту png картинку как Polygon, потому что Compatibility багнутый и всем на него глубоко насрать (на Vulkan Mobile анимирует). Если даунгрейднуться до Godot 3.6, то картинка и выводится, и анимируется с минимальной нагрузкой, так что телефон не начинает греть руки, хотя всё равно нагрузка в разы выше классических приложений Android.
Телефон менять я не планирую, потому что аккумулятор спустя 5 лет почти ежедневного использования всё ещё держится 10+ часов на одном заряде и все нужные приложения не тормозят, а в АААА 3D фотореализм я всё равно никогда не играл и не буду играть. К тому же сейчас телефоны по-дебильному выглядят... Но даже если взять современные смартфоны последнего поколения, и допустить, что Vulkan загружает GPU на 50%, а не на 100%, то решение на OpenGL должно нагружать на 5% вместо 15%, просто потому что GPU стала экономичнее и быстрее в целом, а не по частям. В любом случае получается экономия заряда аккумулятора, который из смартфонов никуда не делся и вряд ли когда-либо денется (все альтернативы пукнули и обмякли из-за проблем с безопасностью).
Но даже если взять компьютеры, очень многие до сих пор сидят на NVIDIA 600/700-х поколений, да и если даже поднять до 1000-го поколения, они продолжат работать ещё лет десять как минимум. CPU без поддержки SSE4.2 последний раз выпускалось считанные 2-3 года назад, и наверняка целевая аудитория этих CPU просто не может купить что-то новое в ближайшее десятилетие. На вторичном рынке CPU из конца 00-х/начала 10-х будут ещё лет пять-десять как минимум обращаться, особенно в нищих странах. Предлагаешь положить болт на всех них только из-за того, что Steam решил обрубить поддержку Windows до десятки?
Я могу понять требования, например, Blender - потому что это инструмент разработчика. Blender не нужно запускать на условном встроенном компьютере умного холодильника, потому что результат работы Blender - это в основном плоские картинки - рендеры, или информация о моделях и сценах для других программ. Blender оправданно требует более мощный ПК разработчика. А Godot-редактор должен запускаться на том же компьютере, что и финальная Godot-игра - если редактор повышает требования к устройству, то и игра повышает требования. Это недопустимо для движка, рассчитанного на максимально широкую аудиторию с самым низким порогом входа.
Недавно обсуждали страны - ты думаешь, в Бразилии пользователи Godot все сидят за топовыми ПК 2025 года и ходят с флагманскими смартфонами 2025 года? Или ты считаешь, что отрезать бОльшую часть тех же бразильцев, индийцев, китайцев и т.д. - это оправданная жертва ради малого процента самых богатых игроков из США?
ААА игры не начнут внезапно разрабатывать на Godot, если он просто станет недоступен для слабых машин. Условная GTA 5 вышла в 2013 и работает на железе из 00-х, но выглядит круто даже в 2025, и ни одна из последующих ААА пока не смогла побить её в графическом плане (если отбросить всё лишнее вроде "лучей", которые в Godot всё равно до сих пор не поддерживаются, поэтому не имеют значения). Godot пока что не настолько крут, как движок Rockstar (RAGE 2), но уже ограничивает сферу своего применения сильнее него. Это, по-твоему, нормально?
Короче, я жду от Godot укрепление на инди-рынке, а не убегание в сторону недоступных инди ААА-проектов.
>>60136
Скоро 7 лет как, пчел. 7 лет в технике это огромная разница, это Вор 2 vs тот самый Крузис. К моменту когда ты допилишь что-то значимое уже все 10 будет. Я когда свое на тройке пилить начинал, целясь в телефоны, средний телефон тянул мой проект на 20 фпс, сейчас 60 изи.
>2019, т.е. совсем недавно
Скоро 7 лет как, пчел. 7 лет в технике это огромная разница, это Вор 2 vs тот самый Крузис. К моменту когда ты допилишь что-то значимое уже все 10 будет. Я когда свое на тройке пилить начинал, целясь в телефоны, средний телефон тянул мой проект на 20 фпс, сейчас 60 изи.
1,7 Мб, 2712x1220>>60136
А эти многие нищуки сейчас с тобой а одной комнате? Можешь глнуть топовые чарты железа стима, эти шушпанцеры плетутся вместе с рх580, некогда топом за свои деньги.
Первый проц появился в 2008 году, соответственно их перестали выпускать с начала десятых, даже на самом дешевом офисном говне есть эти инструкции (проверено)
Нищеебы не платят за игры, особенно сидящие на процах из нулевых, у них браузер попердывая открывается полчаса, а ты про игры тут.
А где им еще игры продавать? Опять же, покупка с их стороны маловероятна, если они терпят на таком говне и не могут себе хотябы райзен со встройкой взять.
Здесь на сцену выходит опенсорсность, берешь скунса, понижаешь уровень sse в конфиге сборщика, собираешь сам, и вот у тебя всё снова работает на некрожелезе.
Флагманский не нужен, третий райзен с вторички какого нибудь третьего-пятого поколения под ам4 обойдется в смешные деньги. И ты даже в ведьмака 3 в 30 фпс поиграешь с встройки, на минимальном графоне (у меня на телефоне ведьмак 3 свич порт выдает по медиане 23, 8_3s снап)
На селероне гта не запустится, даже не надейся, как и на фуфыксе.
Ну это платина нахуй, уровень калорийности запредельный
Годот это лебедь рак и щука, которые кое-как тянут движок относительно в одном направлении. Ждать от него чего-то конкретного никак при этом самолично не участвуя - пустая трата времени.
>очень многие до сих пор сидят на NVIDIA 600/700-х
А эти многие нищуки сейчас с тобой а одной комнате? Можешь глнуть топовые чарты железа стима, эти шушпанцеры плетутся вместе с рх580, некогда топом за свои деньги.
>CPU без поддержки SSE4.2 последний раз выпускалось считанные 2-3 года
Первый проц появился в 2008 году, соответственно их перестали выпускать с начала десятых, даже на самом дешевом офисном говне есть эти инструкции (проверено)
>На вторичном рынке CPU из конца 00-х/начала 10-х будут ещё лет пять-десять как минимум обращаться, особенно в нищих странах.
Нищеебы не платят за игры, особенно сидящие на процах из нулевых, у них браузер попердывая открывается полчаса, а ты про игры тут.
>Предлагаешь положить болт на всех них только из-за того, что Steam решил обрубить поддержку Windows до десятки?
А где им еще игры продавать? Опять же, покупка с их стороны маловероятна, если они терпят на таком говне и не могут себе хотябы райзен со встройкой взять.
>Это недопустимо для движка, рассчитанного на максимально широкую аудиторию с самым низким порогом входа.
Здесь на сцену выходит опенсорсность, берешь скунса, понижаешь уровень sse в конфиге сборщика, собираешь сам, и вот у тебя всё снова работает на некрожелезе.
>Недавно обсуждали страны - ты думаешь, в Бразилии пользователи Godot все сидят за топовыми ПК 2025 года и ходят с флагманскими смартфонами 2025 года?
Флагманский не нужен, третий райзен с вторички какого нибудь третьего-пятого поколения под ам4 обойдется в смешные деньги. И ты даже в ведьмака 3 в 30 фпс поиграешь с встройки, на минимальном графоне (у меня на телефоне ведьмак 3 свич порт выдает по медиане 23, 8_3s снап)
>ААА игры не начнут внезапно разрабатывать на Godot, если он просто станет недоступен для слабых машин. Условная GTA 5 вышла в 2013 и работает на железе из 00-х
На селероне гта не запустится, даже не надейся, как и на фуфыксе.
>одна из последующих ААА пока не смогла побить её в графическом плане
Ну это платина нахуй, уровень калорийности запредельный
>Короче, я жду от Godot укрепление на инди-рынке, а не убегание в сторону недоступных инди ААА-проектов.
Годот это лебедь рак и щука, которые кое-как тянут движок относительно в одном направлении. Ждать от него чего-то конкретного никак при этом самолично не участвуя - пустая трата времени.
1,7 Мб, 2712x1220>>60136
А эти многие нищуки сейчас с тобой а одной комнате? Можешь глнуть топовые чарты железа стима, эти шушпанцеры плетутся вместе с рх580, некогда топом за свои деньги.
Первый проц появился в 2008 году, соответственно их перестали выпускать с начала десятых, даже на самом дешевом офисном говне есть эти инструкции (проверено)
Нищеебы не платят за игры, особенно сидящие на процах из нулевых, у них браузер попердывая открывается полчаса, а ты про игры тут.
А где им еще игры продавать? Опять же, покупка с их стороны маловероятна, если они терпят на таком говне и не могут себе хотябы райзен со встройкой взять.
Здесь на сцену выходит опенсорсность, берешь скунса, понижаешь уровень sse в конфиге сборщика, собираешь сам, и вот у тебя всё снова работает на некрожелезе.
Флагманский не нужен, третий райзен с вторички какого нибудь третьего-пятого поколения под ам4 обойдется в смешные деньги. И ты даже в ведьмака 3 в 30 фпс поиграешь с встройки, на минимальном графоне (у меня на телефоне ведьмак 3 свич порт выдает по медиане 23, 8_3s снап)
На селероне гта не запустится, даже не надейся, как и на фуфыксе.
Ну это платина нахуй, уровень калорийности запредельный
Годот это лебедь рак и щука, которые кое-как тянут движок относительно в одном направлении. Ждать от него чего-то конкретного никак при этом самолично не участвуя - пустая трата времени.
>очень многие до сих пор сидят на NVIDIA 600/700-х
А эти многие нищуки сейчас с тобой а одной комнате? Можешь глнуть топовые чарты железа стима, эти шушпанцеры плетутся вместе с рх580, некогда топом за свои деньги.
>CPU без поддержки SSE4.2 последний раз выпускалось считанные 2-3 года
Первый проц появился в 2008 году, соответственно их перестали выпускать с начала десятых, даже на самом дешевом офисном говне есть эти инструкции (проверено)
>На вторичном рынке CPU из конца 00-х/начала 10-х будут ещё лет пять-десять как минимум обращаться, особенно в нищих странах.
Нищеебы не платят за игры, особенно сидящие на процах из нулевых, у них браузер попердывая открывается полчаса, а ты про игры тут.
>Предлагаешь положить болт на всех них только из-за того, что Steam решил обрубить поддержку Windows до десятки?
А где им еще игры продавать? Опять же, покупка с их стороны маловероятна, если они терпят на таком говне и не могут себе хотябы райзен со встройкой взять.
>Это недопустимо для движка, рассчитанного на максимально широкую аудиторию с самым низким порогом входа.
Здесь на сцену выходит опенсорсность, берешь скунса, понижаешь уровень sse в конфиге сборщика, собираешь сам, и вот у тебя всё снова работает на некрожелезе.
>Недавно обсуждали страны - ты думаешь, в Бразилии пользователи Godot все сидят за топовыми ПК 2025 года и ходят с флагманскими смартфонами 2025 года?
Флагманский не нужен, третий райзен с вторички какого нибудь третьего-пятого поколения под ам4 обойдется в смешные деньги. И ты даже в ведьмака 3 в 30 фпс поиграешь с встройки, на минимальном графоне (у меня на телефоне ведьмак 3 свич порт выдает по медиане 23, 8_3s снап)
>ААА игры не начнут внезапно разрабатывать на Godot, если он просто станет недоступен для слабых машин. Условная GTA 5 вышла в 2013 и работает на железе из 00-х
На селероне гта не запустится, даже не надейся, как и на фуфыксе.
>одна из последующих ААА пока не смогла побить её в графическом плане
Ну это платина нахуй, уровень калорийности запредельный
>Короче, я жду от Godot укрепление на инди-рынке, а не убегание в сторону недоступных инди ААА-проектов.
Годот это лебедь рак и щука, которые кое-как тянут движок относительно в одном направлении. Ждать от него чего-то конкретного никак при этом самолично не участвуя - пустая трата времени.
>>60137
Ты сравниваешь игру 2000 с игрой 2007, когда был самый пик развития технологий. После начала 10-х началась стагнация, потому что закон Мура умер, многопоточность в играх просто нафиг не нужна, а в плане графики ничего умного придумать не смогли, кроме нейронок из машинного обучения, способных генерировать целую игру без игрового движка - просто создавая кадр за кадром.
Это, собственно, единственный актуальный вектор развития - нейронки, способные сделать картинку уровня того же фотореалистичного ААА проекта из обучающего датасета с максимальной утилизацией десятков тысяч ядер GPU. Нейронки, способные научиться действовать как человек без ручного труда программиста. Нейронки, способные генерировать голос, неотличимый от человеческого, в реальном времени. Вот только этим нейронкам вообще не нужны никакие игровые движки и тем более не нужны разработчики игр, и от компьютера не нужны никакие особые технологии кроме десятков/сотен тысяч ядер, способных лишь перемножать матрицы чисел. Вот это единственный актуальный прогресс, который будет двигаться в ближайшие лет 10 - больше ядер GPU и больше RAM/VRAM, слияние CPU и GPU, наращивание гигантских NPU чисто под нейронки. Никакой Vulkan тут не нужен - в смысле, не нужно рендерить никакие треугольники и не нужно никаких шейдеров, нужно только перемножать матрицы на NPU.
Но мы же тут ретро-фанбои, пытаемся делать ретро-игры как деды - с полигонами, текстурами, шейдерами, тривиальными скриптами, а не генерировать видеоряд перемножением матриц на NPU, не так ли? Нас никакой прогресс больше не касается, наш технологический прогресс остановился в начале или середине 2010-х и больше двигаться никуда не будет, только поддерживаться ради забавы и тех немногих бизнесов, которым нужна графика.
Если твоя игра загружает телефон на 100%, то это плохо независимо от частоты кадров: телефон будет выжигать всю энергию за час-два и нагреваться до неприятного рукам уровня, т.к. нормального охлаждения в телефонах нет. Это неприятно для и игрока, и для телефона. Поэтому желательно, чтобы у тебя было "60 фпс" с нагрузкой <50%. А также нужно встроить в настройки игры лимит частоты кадров и другие ограничители, чтоб юзер мог снизить нагрузку сам.
>7 лет в технике это огромная разница
>Вор 2 vs тот самый Крузис
Ты сравниваешь игру 2000 с игрой 2007, когда был самый пик развития технологий. После начала 10-х началась стагнация, потому что закон Мура умер, многопоточность в играх просто нафиг не нужна, а в плане графики ничего умного придумать не смогли, кроме нейронок из машинного обучения, способных генерировать целую игру без игрового движка - просто создавая кадр за кадром.
Это, собственно, единственный актуальный вектор развития - нейронки, способные сделать картинку уровня того же фотореалистичного ААА проекта из обучающего датасета с максимальной утилизацией десятков тысяч ядер GPU. Нейронки, способные научиться действовать как человек без ручного труда программиста. Нейронки, способные генерировать голос, неотличимый от человеческого, в реальном времени. Вот только этим нейронкам вообще не нужны никакие игровые движки и тем более не нужны разработчики игр, и от компьютера не нужны никакие особые технологии кроме десятков/сотен тысяч ядер, способных лишь перемножать матрицы чисел. Вот это единственный актуальный прогресс, который будет двигаться в ближайшие лет 10 - больше ядер GPU и больше RAM/VRAM, слияние CPU и GPU, наращивание гигантских NPU чисто под нейронки. Никакой Vulkan тут не нужен - в смысле, не нужно рендерить никакие треугольники и не нужно никаких шейдеров, нужно только перемножать матрицы на NPU.
Но мы же тут ретро-фанбои, пытаемся делать ретро-игры как деды - с полигонами, текстурами, шейдерами, тривиальными скриптами, а не генерировать видеоряд перемножением матриц на NPU, не так ли? Нас никакой прогресс больше не касается, наш технологический прогресс остановился в начале или середине 2010-х и больше двигаться никуда не будет, только поддерживаться ради забавы и тех немногих бизнесов, которым нужна графика.
>сейчас 60 изи
Если твоя игра загружает телефон на 100%, то это плохо независимо от частоты кадров: телефон будет выжигать всю энергию за час-два и нагреваться до неприятного рукам уровня, т.к. нормального охлаждения в телефонах нет. Это неприятно для и игрока, и для телефона. Поэтому желательно, чтобы у тебя было "60 фпс" с нагрузкой <50%. А также нужно встроить в настройки игры лимит частоты кадров и другие ограничители, чтоб юзер мог снизить нагрузку сам.
>>60137
Ты сравниваешь игру 2000 с игрой 2007, когда был самый пик развития технологий. После начала 10-х началась стагнация, потому что закон Мура умер, многопоточность в играх просто нафиг не нужна, а в плане графики ничего умного придумать не смогли, кроме нейронок из машинного обучения, способных генерировать целую игру без игрового движка - просто создавая кадр за кадром.
Это, собственно, единственный актуальный вектор развития - нейронки, способные сделать картинку уровня того же фотореалистичного ААА проекта из обучающего датасета с максимальной утилизацией десятков тысяч ядер GPU. Нейронки, способные научиться действовать как человек без ручного труда программиста. Нейронки, способные генерировать голос, неотличимый от человеческого, в реальном времени. Вот только этим нейронкам вообще не нужны никакие игровые движки и тем более не нужны разработчики игр, и от компьютера не нужны никакие особые технологии кроме десятков/сотен тысяч ядер, способных лишь перемножать матрицы чисел. Вот это единственный актуальный прогресс, который будет двигаться в ближайшие лет 10 - больше ядер GPU и больше RAM/VRAM, слияние CPU и GPU, наращивание гигантских NPU чисто под нейронки. Никакой Vulkan тут не нужен - в смысле, не нужно рендерить никакие треугольники и не нужно никаких шейдеров, нужно только перемножать матрицы на NPU.
Но мы же тут ретро-фанбои, пытаемся делать ретро-игры как деды - с полигонами, текстурами, шейдерами, тривиальными скриптами, а не генерировать видеоряд перемножением матриц на NPU, не так ли? Нас никакой прогресс больше не касается, наш технологический прогресс остановился в начале или середине 2010-х и больше двигаться никуда не будет, только поддерживаться ради забавы и тех немногих бизнесов, которым нужна графика.
Если твоя игра загружает телефон на 100%, то это плохо независимо от частоты кадров: телефон будет выжигать всю энергию за час-два и нагреваться до неприятного рукам уровня, т.к. нормального охлаждения в телефонах нет. Это неприятно для и игрока, и для телефона. Поэтому желательно, чтобы у тебя было "60 фпс" с нагрузкой <50%. А также нужно встроить в настройки игры лимит частоты кадров и другие ограничители, чтоб юзер мог снизить нагрузку сам.
>7 лет в технике это огромная разница
>Вор 2 vs тот самый Крузис
Ты сравниваешь игру 2000 с игрой 2007, когда был самый пик развития технологий. После начала 10-х началась стагнация, потому что закон Мура умер, многопоточность в играх просто нафиг не нужна, а в плане графики ничего умного придумать не смогли, кроме нейронок из машинного обучения, способных генерировать целую игру без игрового движка - просто создавая кадр за кадром.
Это, собственно, единственный актуальный вектор развития - нейронки, способные сделать картинку уровня того же фотореалистичного ААА проекта из обучающего датасета с максимальной утилизацией десятков тысяч ядер GPU. Нейронки, способные научиться действовать как человек без ручного труда программиста. Нейронки, способные генерировать голос, неотличимый от человеческого, в реальном времени. Вот только этим нейронкам вообще не нужны никакие игровые движки и тем более не нужны разработчики игр, и от компьютера не нужны никакие особые технологии кроме десятков/сотен тысяч ядер, способных лишь перемножать матрицы чисел. Вот это единственный актуальный прогресс, который будет двигаться в ближайшие лет 10 - больше ядер GPU и больше RAM/VRAM, слияние CPU и GPU, наращивание гигантских NPU чисто под нейронки. Никакой Vulkan тут не нужен - в смысле, не нужно рендерить никакие треугольники и не нужно никаких шейдеров, нужно только перемножать матрицы на NPU.
Но мы же тут ретро-фанбои, пытаемся делать ретро-игры как деды - с полигонами, текстурами, шейдерами, тривиальными скриптами, а не генерировать видеоряд перемножением матриц на NPU, не так ли? Нас никакой прогресс больше не касается, наш технологический прогресс остановился в начале или середине 2010-х и больше двигаться никуда не будет, только поддерживаться ради забавы и тех немногих бизнесов, которым нужна графика.
>сейчас 60 изи
Если твоя игра загружает телефон на 100%, то это плохо независимо от частоты кадров: телефон будет выжигать всю энергию за час-два и нагреваться до неприятного рукам уровня, т.к. нормального охлаждения в телефонах нет. Это неприятно для и игрока, и для телефона. Поэтому желательно, чтобы у тебя было "60 фпс" с нагрузкой <50%. А также нужно встроить в настройки игры лимит частоты кадров и другие ограничители, чтоб юзер мог снизить нагрузку сам.
>>60136
Ну еще по поводу прогрева телефона - а ты фпс знаешь на котором проект запустился? Там может гнало на все деньги 500 фпс, и разумеется телефон начал накаляться
Ну еще по поводу прогрева телефона - а ты фпс знаешь на котором проект запустился? Там может гнало на все деньги 500 фпс, и разумеется телефон начал накаляться
>>60139
Что ты в инди забыл, где 99.99% раздают бесплатно? Выкатывайся на ААА-галеру.
Речь не о первом с поддержкой, а о последнем без поддержки. Разницу понимаешь?
Это высокий порог входа, учитывая что нужно кучу инструментов поставить правильно.
Ну и зачем ты предлагаешь покупать "устаревшее говно для нищуков"? Шило на мыло.
На "Core 2 Quad" или 4-х ядерном Xeon "GTA 5 Legacy" точно запускается и работает...
У Godot есть чёткое руководство, которое определяет, что пускать в ядро движка.
>>60141
Это технически невозможно на смартфонах - там VSync включён и не выключается.
>нищуки
>Нищеебы
>не платят
>продавать
>покупка
Что ты в инди забыл, где 99.99% раздают бесплатно? Выкатывайся на ААА-галеру.
>Первый проц
Речь не о первом с поддержкой, а о последнем без поддержки. Разницу понимаешь?
>собираешь сам
Это высокий порог входа, учитывая что нужно кучу инструментов поставить правильно.
>Флагманский не нужен, третий райзен
Ну и зачем ты предлагаешь покупать "устаревшее говно для нищуков"? Шило на мыло.
>На селероне гта не запустится
На "Core 2 Quad" или 4-х ядерном Xeon "GTA 5 Legacy" точно запускается и работает...
>Годот это лебедь рак и щука
У Godot есть чёткое руководство, которое определяет, что пускать в ядро движка.
>>60141
>Там может гнало на все деньги 500 фпс
Это технически невозможно на смартфонах - там VSync включён и не выключается.
>>60140
Рановато еще до описанного. А как только наступит момент где нейронки смогут сделать мне неироничный сталкер/крайзис, целостный, с сохранениями и стабильной игровой реальностью - в этот момент можно просто расслабиться и принять факт вторичности человека как основного разумного вида этой планеты, уже конечная, эра машин настала. Но опять таки - нейронки пока еще далеко.
Это потому что ты безигорник. Если бы ты знал, сколько всего суется в потоки, то ты бы так мощно не срал в штаны. А суется в потоки все что туда можно засунуть - физика (в годоте физику можно включить отдельным потоком), патчфайнд, генерация мешей/текстур, загрузка ресурсов с диска, создание сцен в потоках(годот разрешает), в отдельных случаях паралеллится бизнеслогика (ecs), при этом степень паралеллизации зависит исключительно от степени ошизения разраба.
>Стена нейроманяфантазий
Рановато еще до описанного. А как только наступит момент где нейронки смогут сделать мне неироничный сталкер/крайзис, целостный, с сохранениями и стабильной игровой реальностью - в этот момент можно просто расслабиться и принять факт вторичности человека как основного разумного вида этой планеты, уже конечная, эра машин настала. Но опять таки - нейронки пока еще далеко.
>многопоточность в играх просто нафиг не нужна
Это потому что ты безигорник. Если бы ты знал, сколько всего суется в потоки, то ты бы так мощно не срал в штаны. А суется в потоки все что туда можно засунуть - физика (в годоте физику можно включить отдельным потоком), патчфайнд, генерация мешей/текстур, загрузка ресурсов с диска, создание сцен в потоках(годот разрешает), в отдельных случаях паралеллится бизнеслогика (ecs), при этом степень паралеллизации зависит исключительно от степени ошизения разраба.
>>60142
Я отлично знаю что на этом рынке покупатель готов получить твою игру любой ценой, но бесплатно, да и я свою игру пилю заведомо зная, что играть будет пол землекопа. Но рано или поздно всё же придется игры продавать, иначе нахуя это всё.
Производителей цпу x86_64 в мире всего два. Кто из них после 2010 продолжил производить цпу без sse 4.2? Можешь просто модель проца назвать.
На фоне некроговна из нулевых это будет звездолет с космической производительностью, если всё вот прям настолько плохо с деньгами. Да даже какой нибудь селерон 4-5 поколения уже будет лучше раз в 5.
Только скунса и с++ зависимости, это не сложно, процесс описан в документации.
У годота, особенно 4, и особенно у вулкана есть проблема - он порой с vsync не дружит и хуярит кадры на похуй, ему нужно руками жестко ограничивать фпс.
Руководство то может и четкое, но это никак не влияет на то, хочет ли контрибутор делать определенную фичу или нет. Слышал от одного из контрибов, что его pr для тройки не приняли, потребовав чтобы он сначала запилил для 4, а затем только одобрят в тройку. Такие дела с четкостью руководства.
>Что ты в инди забыл, где 99.99% раздают бесплатно? >Выкатывайся на ААА-галеру.
Я отлично знаю что на этом рынке покупатель готов получить твою игру любой ценой, но бесплатно, да и я свою игру пилю заведомо зная, что играть будет пол землекопа. Но рано или поздно всё же придется игры продавать, иначе нахуя это всё.
>Речь не о первом с поддержкой, а о последнем без поддержки.
Производителей цпу x86_64 в мире всего два. Кто из них после 2010 продолжил производить цпу без sse 4.2? Можешь просто модель проца назвать.
>Ну и зачем ты предлагаешь покупать "устаревшее говно для нищуков"? Шило на мыло.
На фоне некроговна из нулевых это будет звездолет с космической производительностью, если всё вот прям настолько плохо с деньгами. Да даже какой нибудь селерон 4-5 поколения уже будет лучше раз в 5.
>Это высокий порог входа, учитывая что нужно кучу инструментов поставить правильно.
Только скунса и с++ зависимости, это не сложно, процесс описан в документации.
>Это технически невозможно на смартфонах - там VSync включён и не выключается.
У годота, особенно 4, и особенно у вулкана есть проблема - он порой с vsync не дружит и хуярит кадры на похуй, ему нужно руками жестко ограничивать фпс.
>У Godot есть чёткое руководство, которое определяет, что пускать в ядро движка.
Руководство то может и четкое, но это никак не влияет на то, хочет ли контрибутор делать определенную фичу или нет. Слышал от одного из контрибов, что его pr для тройки не приняли, потребовав чтобы он сначала запилил для 4, а затем только одобрят в тройку. Такие дела с четкостью руководства.
26 Кб, 600x700>>60008
Делай что-то вроде пикрила, если тебе не нужен инспектор.
Проверил на Godot 4.5 - всё сохраняется и загружается...
>Как сохранить кастомный класс, точней словарь с классами?
Делай что-то вроде пикрила, если тебе не нужен инспектор.
Проверил на Godot 4.5 - всё сохраняется и загружается...
>>60140
Чет после твоих портянок отмазок я думаю ты просто ищешь причины ничего не делать. То одного не хватает, то другого, то третьего, потом еще десяток найдешь.
Чет после твоих портянок отмазок я думаю ты просто ищешь причины ничего не делать. То одного не хватает, то другого, то третьего, потом еще десяток найдешь.
>>60156
В Godot 4.x мне всего хватает, но:
- он сильно разжирел и стал медленнее,
- режим Compatibility всё ещё бракованный:
https://github.com/godotengine/godot/issues/80057
И этот баг уже аж джва года никто не трогает...
В Godot 3.x мне очень многого не хватает, но:
- он относительно компактен и быстрее,
- графика отображается корректно.
Ящитаю, им нужно сфокусироваться на:
- оптимизации и сжатии своих шакалов,
- фиксе багов в заявленных возможностях.
А у них 4.6 почти сразу после 4.5 - ну и зачем?..
Напомню принятую систему нумерации:
- мажорная версия (X.y.z) == "breaking changes".
- минорная версия (x.Y.z) == новые фичи.
- патч-версия (x.y.Z) == фикс старого.
>То одного не хватает, то другого, то третьего
В Godot 4.x мне всего хватает, но:
- он сильно разжирел и стал медленнее,
- режим Compatibility всё ещё бракованный:
https://github.com/godotengine/godot/issues/80057
И этот баг уже аж джва года никто не трогает...
В Godot 3.x мне очень многого не хватает, но:
- он относительно компактен и быстрее,
- графика отображается корректно.
Ящитаю, им нужно сфокусироваться на:
- оптимизации и сжатии своих шакалов,
- фиксе багов в заявленных возможностях.
А у них 4.6 почти сразу после 4.5 - ну и зачем?..
Напомню принятую систему нумерации:
- мажорная версия (X.y.z) == "breaking changes".
- минорная версия (x.Y.z) == новые фичи.
- патч-версия (x.y.Z) == фикс старого.
>>60179 (Del)
Манятеоретика видно сразу. Иди напиши. Регулярно в соцсетях вижу таких героев, у которых "движок" после 5 лет работы не дотягивает до первой кваки и работает исключительно на их собственном железе.
>Проще свой движок написать.
Манятеоретика видно сразу. Иди напиши. Регулярно в соцсетях вижу таких героев, у которых "движок" после 5 лет работы не дотягивает до первой кваки и работает исключительно на их собственном железе.
>>60181 (Del)
Да с тобой и так понятно, сренькальщик-безыгорник, мог бы не заявлять о себе так явно.
Да с тобой и так понятно, сренькальщик-безыгорник, мог бы не заявлять о себе так явно.
>>60179 (Del)
До 2019 писал движок, потом сел на Godot и сижу.
Со "своим движком" игры у тебя вообще не будет...
>>60180
Если взять SDL и OpenGL 1.0 (как я) - везде пойдёт.
>>60182
Ты только не путай, это кто-то мимо проходивший.
страдаю от ожиревшего софта на старом ПК
>Проще свой движок написать
До 2019 писал движок, потом сел на Godot и сижу.
>Движок должен упрощать создание игры
Со "своим движком" игры у тебя вообще не будет...
>>60180
>исключительно на их собственном железе
Если взять SDL и OpenGL 1.0 (как я) - везде пойдёт.
>>60182
Ты только не путай, это кто-то мимо проходивший.
страдаю от ожиревшего софта на старом ПК
733 Кб, 1280x7204.6 dev 4, скелетоны и проект менеджер.
https://godotengine.org/article/dev-snapshot-godot-4-6-dev-4/
https://godotengine.org/article/dev-snapshot-godot-4-6-dev-4/
Забрасывал на пару месяцев свой игорь, нихуя теперь не ориентируюсь. Тяжело. Попробую разбирать в порядке появления говна на экране.
>>60344
Это всё из-за лапши в архитектуре.
Правильно спланированный проект как верёвочная лестница: можно аккуратно тянуть по одной ступени, внимательно изучая и понимая её свойства. "Лапша" запутывает эту лестницу в тугой клубок, в котором становится не разобраться, что и куда уходит.
А что главным образом вызывает лапшу? Доступ к глобальным сущностям из нескольких мест в коде, вместо последовательного спуска и подъёма по абстракциям в проекте. Когда маленькая штучка в непримечательной сцене через запрос к глобально доступному менеджеру вызывает волну сложных изменений по всем направлениям.
А доступ к глобальным сущностям - из-за лени...
Это всё из-за лапши в архитектуре.
Правильно спланированный проект как верёвочная лестница: можно аккуратно тянуть по одной ступени, внимательно изучая и понимая её свойства. "Лапша" запутывает эту лестницу в тугой клубок, в котором становится не разобраться, что и куда уходит.
А что главным образом вызывает лапшу? Доступ к глобальным сущностям из нескольких мест в коде, вместо последовательного спуска и подъёма по абстракциям в проекте. Когда маленькая штучка в непримечательной сцене через запрос к глобально доступному менеджеру вызывает волну сложных изменений по всем направлениям.
А доступ к глобальным сущностям - из-за лени...
>>60355
Если не надо - не трогай. Это для тех, кому надо.
Тебе же дали все ссылки - читай запись в блоге.
Вот отсюда начинай, по потомкам сам пройдёшь:
https://docs.godotengine.org/en/latest/classes/class_ikmodifier3d.html
Про FABRIK давно слышал, популярный алгоритм.
CCDIK3D, лол))))))))
>по всему этому говну
Если не надо - не трогай. Это для тех, кому надо.
>где документацию читать
Тебе же дали все ссылки - читай запись в блоге.
Вот отсюда начинай, по потомкам сам пройдёшь:
https://docs.godotengine.org/en/latest/classes/class_ikmodifier3d.html
Про FABRIK давно слышал, популярный алгоритм.
CCDIK3D, лол))))))))
>>60416
Не только. Там и про игровые механики, про pity системы, про риск/награды, про секреты, сложность, давление таймерами, трейд механики, крафт и все остальное. Ты до конца не долистал.
Не только. Там и про игровые механики, про pity системы, про риск/награды, про секреты, сложность, давление таймерами, трейд механики, крафт и все остальное. Ты до конца не долистал.
127 Кб, 1353x754>>60418
Да, да, AI slop книга с примерами на gdscript, смотри какая оптимизация на пикче
Да, да, AI slop книга с примерами на gdscript, смотри какая оптимизация на пикче
>>60422
Ну хуй его, те же выдерки тебе бесплатный дипсик даст
Кое где там встречается код на питоне вместо GDScript, это точно AI слоп книга от хохолорумына судя по профилю на реддите, просит там прощения у зелебобы
Ну хуй его, те же выдерки тебе бесплатный дипсик даст
Кое где там встречается код на питоне вместо GDScript, это точно AI слоп книга от хохолорумына судя по профилю на реддите, просит там прощения у зелебобы
Как сделать физическую коллизию для спиральной 3д лестницы? Для обычных, прямых лестниц, я читерю и использую пик 2. Хотелось бы что-то аналогично простое.
33 Кб, 653x714>>60431
Сделал. Намоделил 3д ебалу и сгенерировал по ней тримеш коллижн шейп в годоте. Вроде ок, никто никуда не проваливается.
Сделал. Намоделил 3д ебалу и сгенерировал по ней тримеш коллижн шейп в годоте. Вроде ок, никто никуда не проваливается.
>>60431
Если у тебя всё оптимизировано под эти наклоны, то ПРОСТО моделишь спираль с наклоном и ставишь её коллизией (concave/trimesh collision). Единственный недостаток такой коллизии - она полая внутри, но это повлияет только если ты влетаешь в лестницу на сверхзвуковой скорости - да и то, твой персонаж наверняка толще этой лестницы и не застрянет.
Если ступеньки супер-широкие (они обычно шире у спиральных лестниц), то делай прямоугольниками. Наклонная поверхность будет слишком искажать поверхность визуально. Но это имеет смысл лишь с камерой от третьего лица, что в принципе неудобна для перемещения по лестницам в доме, лол.
Если у тебя всё оптимизировано под эти наклоны, то ПРОСТО моделишь спираль с наклоном и ставишь её коллизией (concave/trimesh collision). Единственный недостаток такой коллизии - она полая внутри, но это повлияет только если ты влетаешь в лестницу на сверхзвуковой скорости - да и то, твой персонаж наверняка толще этой лестницы и не застрянет.
Если ступеньки супер-широкие (они обычно шире у спиральных лестниц), то делай прямоугольниками. Наклонная поверхность будет слишком искажать поверхность визуально. Но это имеет смысл лишь с камерой от третьего лица, что в принципе неудобна для перемещения по лестницам в доме, лол.
>>60437
Точно. Вечный подводный камень. Я сейчас просто перемоделю и потолще коллизию сделаю.
>влетаешь в лестницу на сверхзвуковой скорости
Точно. Вечный подводный камень. Я сейчас просто перемоделю и потолще коллизию сделаю.
Подумываю о том, чтобы попробовать C# в Godot... Последний раз трогал C# лет 5 назад в Unity, и это было ужасно. Я бы предпочёл его не трогать, но хочется побольше скорости для вычислений, конкретнее - хочу нормально экспериментировать с нейронками. На GDScript можно только что-то совсем минимальное сделать, куча времени уходит впустую на интерпретатор. Плюс, как я понял, на C# доступны какие-то фреймворки для ML, но я пока сомневаюсь, что они могут мне пригодиться. Пробовал уже на Python - эти "фреймворки" - нечто слишком абстрактное и неуправляемое. Я хочу пошагово нейроны симулировать.
Вопрос в том, если я открою проект в "Godot mono", это сломает обратную совместимость проекта с нормальной версией? На случай, если ничего не получится и я решу откатиться назад или разделить проект на быстрый сервер (компилируемый язык) и тонкий клиент (GDScript). C/C++ уже смотрел, но вообще не разобрался, как их использовать (компилятор уже есть). Python слишком медленный и тупой, а его альтернативы ещё тупее. Думал поиграться с GDExtension на других языках, но он уж больно сложный - я не разобрался...
>>60471
Ты не понял сути проблемы. Простая коллизия (сфера, куб, цилиндр, капсула, convex shape) - она как бы "заполнена изнутри", т.е. если ты сделаешь сферу радиусом 100 метров и телепортируешься вплотную к геометрическому центру, то движок должен тебя резко откинуть на поверхность сферы - за 100 метров от точки "столкновения" внутри сферы. А тримеши - это наборы треугольников, расположенные поверх "полой" фигуры. Если тримеш достаточно большого размера, то твой персонаж может в него целиком провалиться и "застрять внутри" - т.е. ты можешь двигаться по внутренней поверхности как по внешней. Треугольники тримеша не имеют толщины, и если ты пробил оболочку тримеша сверхзвуковой скоростью, столкнувшись с обратной стороной - ты застрял внутри. Но в случае с лестницей это вряд ли может доставить проблем, потому что ступеньки по высоте у тебя наверняка мельче роста персонажа - капсула персонажа должна будет выскочить с той или иной стороны (скорее всего вверх ступеньки, ну или вниз, но вряд ли умудрится застрять внутри ступеньки). А вот если у тебя в игре регдоллы из мелких кусочков - у них руки и ноги могут провалиться внутрь ступенек и застрять там...
Вопрос в том, если я открою проект в "Godot mono", это сломает обратную совместимость проекта с нормальной версией? На случай, если ничего не получится и я решу откатиться назад или разделить проект на быстрый сервер (компилируемый язык) и тонкий клиент (GDScript). C/C++ уже смотрел, но вообще не разобрался, как их использовать (компилятор уже есть). Python слишком медленный и тупой, а его альтернативы ещё тупее. Думал поиграться с GDExtension на других языках, но он уж больно сложный - я не разобрался...
>>60471
>потолще коллизию сделаю
Ты не понял сути проблемы. Простая коллизия (сфера, куб, цилиндр, капсула, convex shape) - она как бы "заполнена изнутри", т.е. если ты сделаешь сферу радиусом 100 метров и телепортируешься вплотную к геометрическому центру, то движок должен тебя резко откинуть на поверхность сферы - за 100 метров от точки "столкновения" внутри сферы. А тримеши - это наборы треугольников, расположенные поверх "полой" фигуры. Если тримеш достаточно большого размера, то твой персонаж может в него целиком провалиться и "застрять внутри" - т.е. ты можешь двигаться по внутренней поверхности как по внешней. Треугольники тримеша не имеют толщины, и если ты пробил оболочку тримеша сверхзвуковой скоростью, столкнувшись с обратной стороной - ты застрял внутри. Но в случае с лестницей это вряд ли может доставить проблем, потому что ступеньки по высоте у тебя наверняка мельче роста персонажа - капсула персонажа должна будет выскочить с той или иной стороны (скорее всего вверх ступеньки, ну или вниз, но вряд ли умудрится застрять внутри ступеньки). А вот если у тебя в игре регдоллы из мелких кусочков - у них руки и ноги могут провалиться внутрь ступенек и застрять там...
Подумываю о том, чтобы попробовать C# в Godot... Последний раз трогал C# лет 5 назад в Unity, и это было ужасно. Я бы предпочёл его не трогать, но хочется побольше скорости для вычислений, конкретнее - хочу нормально экспериментировать с нейронками. На GDScript можно только что-то совсем минимальное сделать, куча времени уходит впустую на интерпретатор. Плюс, как я понял, на C# доступны какие-то фреймворки для ML, но я пока сомневаюсь, что они могут мне пригодиться. Пробовал уже на Python - эти "фреймворки" - нечто слишком абстрактное и неуправляемое. Я хочу пошагово нейроны симулировать.
Вопрос в том, если я открою проект в "Godot mono", это сломает обратную совместимость проекта с нормальной версией? На случай, если ничего не получится и я решу откатиться назад или разделить проект на быстрый сервер (компилируемый язык) и тонкий клиент (GDScript). C/C++ уже смотрел, но вообще не разобрался, как их использовать (компилятор уже есть). Python слишком медленный и тупой, а его альтернативы ещё тупее. Думал поиграться с GDExtension на других языках, но он уж больно сложный - я не разобрался...
>>60471
Ты не понял сути проблемы. Простая коллизия (сфера, куб, цилиндр, капсула, convex shape) - она как бы "заполнена изнутри", т.е. если ты сделаешь сферу радиусом 100 метров и телепортируешься вплотную к геометрическому центру, то движок должен тебя резко откинуть на поверхность сферы - за 100 метров от точки "столкновения" внутри сферы. А тримеши - это наборы треугольников, расположенные поверх "полой" фигуры. Если тримеш достаточно большого размера, то твой персонаж может в него целиком провалиться и "застрять внутри" - т.е. ты можешь двигаться по внутренней поверхности как по внешней. Треугольники тримеша не имеют толщины, и если ты пробил оболочку тримеша сверхзвуковой скоростью, столкнувшись с обратной стороной - ты застрял внутри. Но в случае с лестницей это вряд ли может доставить проблем, потому что ступеньки по высоте у тебя наверняка мельче роста персонажа - капсула персонажа должна будет выскочить с той или иной стороны (скорее всего вверх ступеньки, ну или вниз, но вряд ли умудрится застрять внутри ступеньки). А вот если у тебя в игре регдоллы из мелких кусочков - у них руки и ноги могут провалиться внутрь ступенек и застрять там...
Вопрос в том, если я открою проект в "Godot mono", это сломает обратную совместимость проекта с нормальной версией? На случай, если ничего не получится и я решу откатиться назад или разделить проект на быстрый сервер (компилируемый язык) и тонкий клиент (GDScript). C/C++ уже смотрел, но вообще не разобрался, как их использовать (компилятор уже есть). Python слишком медленный и тупой, а его альтернативы ещё тупее. Думал поиграться с GDExtension на других языках, но он уж больно сложный - я не разобрался...
>>60471
>потолще коллизию сделаю
Ты не понял сути проблемы. Простая коллизия (сфера, куб, цилиндр, капсула, convex shape) - она как бы "заполнена изнутри", т.е. если ты сделаешь сферу радиусом 100 метров и телепортируешься вплотную к геометрическому центру, то движок должен тебя резко откинуть на поверхность сферы - за 100 метров от точки "столкновения" внутри сферы. А тримеши - это наборы треугольников, расположенные поверх "полой" фигуры. Если тримеш достаточно большого размера, то твой персонаж может в него целиком провалиться и "застрять внутри" - т.е. ты можешь двигаться по внутренней поверхности как по внешней. Треугольники тримеша не имеют толщины, и если ты пробил оболочку тримеша сверхзвуковой скоростью, столкнувшись с обратной стороной - ты застрял внутри. Но в случае с лестницей это вряд ли может доставить проблем, потому что ступеньки по высоте у тебя наверняка мельче роста персонажа - капсула персонажа должна будет выскочить с той или иной стороны (скорее всего вверх ступеньки, ну или вниз, но вряд ли умудрится застрять внутри ступеньки). А вот если у тебя в игре регдоллы из мелких кусочков - у них руки и ноги могут провалиться внутрь ступенек и застрять там...
>>59793
Кстати, есть ли профит пытаться генерить мультимеши без использования нодов, а с помощью RenderingServer? Много проблем предстоит решить?
Кстати, есть ли профит пытаться генерить мультимеши без использования нодов, а с помощью RenderingServer? Много проблем предстоит решить?
Как вы делаете так чтобы враг следовал за игроком? А то у меня враг тупо летит в верх
>>60478
Он не должен. Враг всё равно улетает почему-то
Он не должен. Враг всё равно улетает почему-то
Объясните по человечески разницу между Node2d и control? Если нужна мегюшка с кнопками, которые будут кастомизирвоать модельку это на чем рисовать?
120 Кб, 1240x1080>>60477
enemy.global_position.lerp(player.global_position, delta * shpeed)
enemy.global_position.lerp(player.global_position, delta * shpeed)
Пачаны, а нахера нужны физические кости? Вот эти вот все PhysicalBoneSimulator и т.д. Я ни разу ими не пользовался и в душе не ебу как пользоваться, но я для себя сделал вывод, что они нужны только для регдоллов и подобной штуки. Может я не прав. Если имеете в арсенале интересный видеворолик на этот счет - попрошу поделиться. Хотелось бы научиться хотя бы ими владеть. Авось пригодится.
>>60490
как и всё остальное, для игор, регдол может быть игровой механикой
>а нахера нужны физические кости
как и всё остальное, для игор, регдол может быть игровой механикой
>>60498
вопрос уровня "рука нужна чтобы держать что-то, и всё?"
вопрос уровня "рука нужна чтобы держать что-то, и всё?"
>>60476
Только если у тебя так много Node, что из-за них игра тормозит.
>>60477
Ответ сильно зависит от игры...
Без подробностей помочь тут никак не получится.
>>60485
Потомки Node2D нужны для 2D игр типа: Terraria, RimWorld и т.п.
Потомки Control нужны для GUI в любых играх и программах.
Control, естественно.
Это ни на что не влияет. GUI накладывается поверх 3D графики.
Или ты хочешь встроить GUI в 3D, типа на поверхность шкафа?
>>60490
Чтобы кости скелета, например, не проваливались сквозь стены.
Если не знаешь, зачем они тебе, то они тебе сейчас не нужны.
>без использования нодов, а с помощью RenderingServer
Только если у тебя так много Node, что из-за них игра тормозит.
>>60477
>Как вы делаете так чтобы враг следовал за игроком?
Ответ сильно зависит от игры...
>А то у меня враг тупо летит в верх
Без подробностей помочь тут никак не получится.
>>60485
>разницу между Node2d и control
Потомки Node2D нужны для 2D игр типа: Terraria, RimWorld и т.п.
Потомки Control нужны для GUI в любых играх и программах.
>Если нужна менюшка с кнопками
Control, естественно.
>которые будут кастомизирвоать модельку
Это ни на что не влияет. GUI накладывается поверх 3D графики.
Или ты хочешь встроить GUI в 3D, типа на поверхность шкафа?
>>60490
>нахера нужны физические кости?
Чтобы кости скелета, например, не проваливались сквозь стены.
>Хотелось бы научиться хотя бы ими владеть. Авось пригодится.
Если не знаешь, зачем они тебе, то они тебе сейчас не нужны.
>>60507
Ну вот сам скрипт если интересно - extends Area2D
@export var damage: int = 10
@export var speed: float = 50.0
@export var chase_distance: float = 1000.0 # Радиус зоны обнаружения (для дочернего DetectionArea)
@export var damage_rate: float = 1.0 # Урон раз в секунду
var health: int = 100
@onready var animated_sprite = $AnimatedSprite # Или AnimatedSprite2D, проверь имя в сцене
@onready var ray_cast = $RayCast2D # Дочерний RayCast2D для проверки столкновений
@onready var detection_area = $DetectionArea # НОВОЕ: Дочерний Area2D для зоны обнаружения (радиус chase_distance)
var velocity: Vector2 = Vector2.ZERO # Добавлено по примеру
var target: Node2D = null # Цель для преследования (игрок)
var is_chasing: bool = false # НОВОЕ: Флаг, активен ли преследование (игрок в зоне)
var player: Node2D = null # Ссылка на игрока для урона при контакте
var damage_timer: float = 0.0
func _ready():
add_to_group("enemies")
if animated_sprite:
animated_sprite.play("move")
# Сигналы основного Area2D (для урона при контакте)
body_entered.connect(_on_body_entered)
body_exited.connect(_on_body_exited)
# НОВОЕ: Сигналы зоны обнаружения
detection_area.body_entered.connect(_on_detection_entered)
detection_area.body_exited.connect(_on_detection_exited)
# Настрой RayCast2D: Enabled = true, Collide With Bodies = true, Collision Mask = маска стен/платформ (например, 1)
func _physics_process(delta: float) -> void:
# Адаптировано по примеру: velocity = Vector2.ZERO; if player: velocity = direction speed
velocity = Vector2.ZERO
if is_chasing and target:
velocity = global_position.direction_to(target.global_position) speed
# Проверка RayCast2D на препятствия (адаптировано: проверка на velocity delta)
ray_cast.target_position = velocity delta
ray_cast.force_raycast_update()
if not ray_cast.is_colliding():
global_position += velocity * delta
# Анимация и поворот спрайта
if velocity.x > 0:
animated_sprite.flip_h = false
elif velocity.x < 0:
animated_sprite.flip_h = true
# Отладка преследования (раз в секунду)
if Engine.get_frames_drawn() % 60 == 0:
var distance = global_position.distance_to(target.global_position)
print("Враг преследует: расстояние ", distance, " позиция ", global_position)
# Постоянный урон игроку, если он в основном Area2D (контакт)
if player:
damage_timer += delta
if damage_timer >= 1.0 / damage_rate:
player.take_damage(damage)
print("Враг наносит урон персонажу: ", damage)
damage_timer = 0.0
func _on_body_entered(body):
if body.is_in_group("projectiles"):
take_damage(body.damage)
body.queue_free()
elif body.is_in_group("player"):
player = body # Запоминаем игрока для урона
func _on_body_exited(body):
if body == player:
player = null
damage_timer = 0.0
# НОВОЕ: Сигналы зоны обнаружения
func _on_detection_entered(body):
if body.is_in_group("player"):
is_chasing = true
target = body
print("Игрок вошёл в зону обнаружения: преследование начато")
func _on_detection_exited(body):
if body == target:
is_chasing = false
target = null
print("Игрок вышел из зоны обнаружения: преследование остановлено")
func take_damage(dmg: int):
health -= dmg
print("Враг получил урон: ", dmg, " Осталось здоровья: ", health)
flash_damage()
if health <= 0:
die()
# ОСТАВЛЕНО ТОЧНО КАК В ТВОЁМ КОДЕ: Логика tween и свечение
func flash_damage(duration: float = 0.15) -> void:
if not animated_sprite:
return
var tween = create_tween()
tween.tween_property(animated_sprite, "modulate", Color(10, 10, 10, 0.8), duration / 2)
await tween.finished
tween = create_tween()
tween.tween_property(animated_sprite, "modulate", Color(1, 1, 1, 1), duration / 2)
func die():
queue_free()
>Без подробностей помочь тут никак не получится.
Ну вот сам скрипт если интересно - extends Area2D
@export var damage: int = 10
@export var speed: float = 50.0
@export var chase_distance: float = 1000.0 # Радиус зоны обнаружения (для дочернего DetectionArea)
@export var damage_rate: float = 1.0 # Урон раз в секунду
var health: int = 100
@onready var animated_sprite = $AnimatedSprite # Или AnimatedSprite2D, проверь имя в сцене
@onready var ray_cast = $RayCast2D # Дочерний RayCast2D для проверки столкновений
@onready var detection_area = $DetectionArea # НОВОЕ: Дочерний Area2D для зоны обнаружения (радиус chase_distance)
var velocity: Vector2 = Vector2.ZERO # Добавлено по примеру
var target: Node2D = null # Цель для преследования (игрок)
var is_chasing: bool = false # НОВОЕ: Флаг, активен ли преследование (игрок в зоне)
var player: Node2D = null # Ссылка на игрока для урона при контакте
var damage_timer: float = 0.0
func _ready():
add_to_group("enemies")
if animated_sprite:
animated_sprite.play("move")
# Сигналы основного Area2D (для урона при контакте)
body_entered.connect(_on_body_entered)
body_exited.connect(_on_body_exited)
# НОВОЕ: Сигналы зоны обнаружения
detection_area.body_entered.connect(_on_detection_entered)
detection_area.body_exited.connect(_on_detection_exited)
# Настрой RayCast2D: Enabled = true, Collide With Bodies = true, Collision Mask = маска стен/платформ (например, 1)
func _physics_process(delta: float) -> void:
# Адаптировано по примеру: velocity = Vector2.ZERO; if player: velocity = direction speed
velocity = Vector2.ZERO
if is_chasing and target:
velocity = global_position.direction_to(target.global_position) speed
# Проверка RayCast2D на препятствия (адаптировано: проверка на velocity delta)
ray_cast.target_position = velocity delta
ray_cast.force_raycast_update()
if not ray_cast.is_colliding():
global_position += velocity * delta
# Анимация и поворот спрайта
if velocity.x > 0:
animated_sprite.flip_h = false
elif velocity.x < 0:
animated_sprite.flip_h = true
# Отладка преследования (раз в секунду)
if Engine.get_frames_drawn() % 60 == 0:
var distance = global_position.distance_to(target.global_position)
print("Враг преследует: расстояние ", distance, " позиция ", global_position)
# Постоянный урон игроку, если он в основном Area2D (контакт)
if player:
damage_timer += delta
if damage_timer >= 1.0 / damage_rate:
player.take_damage(damage)
print("Враг наносит урон персонажу: ", damage)
damage_timer = 0.0
func _on_body_entered(body):
if body.is_in_group("projectiles"):
take_damage(body.damage)
body.queue_free()
elif body.is_in_group("player"):
player = body # Запоминаем игрока для урона
func _on_body_exited(body):
if body == player:
player = null
damage_timer = 0.0
# НОВОЕ: Сигналы зоны обнаружения
func _on_detection_entered(body):
if body.is_in_group("player"):
is_chasing = true
target = body
print("Игрок вошёл в зону обнаружения: преследование начато")
func _on_detection_exited(body):
if body == target:
is_chasing = false
target = null
print("Игрок вышел из зоны обнаружения: преследование остановлено")
func take_damage(dmg: int):
health -= dmg
print("Враг получил урон: ", dmg, " Осталось здоровья: ", health)
flash_damage()
if health <= 0:
die()
# ОСТАВЛЕНО ТОЧНО КАК В ТВОЁМ КОДЕ: Логика tween и свечение
func flash_damage(duration: float = 0.15) -> void:
if not animated_sprite:
return
var tween = create_tween()
tween.tween_property(animated_sprite, "modulate", Color(10, 10, 10, 0.8), duration / 2)
await tween.finished
tween = create_tween()
tween.tween_property(animated_sprite, "modulate", Color(1, 1, 1, 1), duration / 2)
func die():
queue_free()
>>60507
Ну вот сам скрипт если интересно - extends Area2D
@export var damage: int = 10
@export var speed: float = 50.0
@export var chase_distance: float = 1000.0 # Радиус зоны обнаружения (для дочернего DetectionArea)
@export var damage_rate: float = 1.0 # Урон раз в секунду
var health: int = 100
@onready var animated_sprite = $AnimatedSprite # Или AnimatedSprite2D, проверь имя в сцене
@onready var ray_cast = $RayCast2D # Дочерний RayCast2D для проверки столкновений
@onready var detection_area = $DetectionArea # НОВОЕ: Дочерний Area2D для зоны обнаружения (радиус chase_distance)
var velocity: Vector2 = Vector2.ZERO # Добавлено по примеру
var target: Node2D = null # Цель для преследования (игрок)
var is_chasing: bool = false # НОВОЕ: Флаг, активен ли преследование (игрок в зоне)
var player: Node2D = null # Ссылка на игрока для урона при контакте
var damage_timer: float = 0.0
func _ready():
add_to_group("enemies")
if animated_sprite:
animated_sprite.play("move")
# Сигналы основного Area2D (для урона при контакте)
body_entered.connect(_on_body_entered)
body_exited.connect(_on_body_exited)
# НОВОЕ: Сигналы зоны обнаружения
detection_area.body_entered.connect(_on_detection_entered)
detection_area.body_exited.connect(_on_detection_exited)
# Настрой RayCast2D: Enabled = true, Collide With Bodies = true, Collision Mask = маска стен/платформ (например, 1)
func _physics_process(delta: float) -> void:
# Адаптировано по примеру: velocity = Vector2.ZERO; if player: velocity = direction speed
velocity = Vector2.ZERO
if is_chasing and target:
velocity = global_position.direction_to(target.global_position) speed
# Проверка RayCast2D на препятствия (адаптировано: проверка на velocity delta)
ray_cast.target_position = velocity delta
ray_cast.force_raycast_update()
if not ray_cast.is_colliding():
global_position += velocity * delta
# Анимация и поворот спрайта
if velocity.x > 0:
animated_sprite.flip_h = false
elif velocity.x < 0:
animated_sprite.flip_h = true
# Отладка преследования (раз в секунду)
if Engine.get_frames_drawn() % 60 == 0:
var distance = global_position.distance_to(target.global_position)
print("Враг преследует: расстояние ", distance, " позиция ", global_position)
# Постоянный урон игроку, если он в основном Area2D (контакт)
if player:
damage_timer += delta
if damage_timer >= 1.0 / damage_rate:
player.take_damage(damage)
print("Враг наносит урон персонажу: ", damage)
damage_timer = 0.0
func _on_body_entered(body):
if body.is_in_group("projectiles"):
take_damage(body.damage)
body.queue_free()
elif body.is_in_group("player"):
player = body # Запоминаем игрока для урона
func _on_body_exited(body):
if body == player:
player = null
damage_timer = 0.0
# НОВОЕ: Сигналы зоны обнаружения
func _on_detection_entered(body):
if body.is_in_group("player"):
is_chasing = true
target = body
print("Игрок вошёл в зону обнаружения: преследование начато")
func _on_detection_exited(body):
if body == target:
is_chasing = false
target = null
print("Игрок вышел из зоны обнаружения: преследование остановлено")
func take_damage(dmg: int):
health -= dmg
print("Враг получил урон: ", dmg, " Осталось здоровья: ", health)
flash_damage()
if health <= 0:
die()
# ОСТАВЛЕНО ТОЧНО КАК В ТВОЁМ КОДЕ: Логика tween и свечение
func flash_damage(duration: float = 0.15) -> void:
if not animated_sprite:
return
var tween = create_tween()
tween.tween_property(animated_sprite, "modulate", Color(10, 10, 10, 0.8), duration / 2)
await tween.finished
tween = create_tween()
tween.tween_property(animated_sprite, "modulate", Color(1, 1, 1, 1), duration / 2)
func die():
queue_free()
>Без подробностей помочь тут никак не получится.
Ну вот сам скрипт если интересно - extends Area2D
@export var damage: int = 10
@export var speed: float = 50.0
@export var chase_distance: float = 1000.0 # Радиус зоны обнаружения (для дочернего DetectionArea)
@export var damage_rate: float = 1.0 # Урон раз в секунду
var health: int = 100
@onready var animated_sprite = $AnimatedSprite # Или AnimatedSprite2D, проверь имя в сцене
@onready var ray_cast = $RayCast2D # Дочерний RayCast2D для проверки столкновений
@onready var detection_area = $DetectionArea # НОВОЕ: Дочерний Area2D для зоны обнаружения (радиус chase_distance)
var velocity: Vector2 = Vector2.ZERO # Добавлено по примеру
var target: Node2D = null # Цель для преследования (игрок)
var is_chasing: bool = false # НОВОЕ: Флаг, активен ли преследование (игрок в зоне)
var player: Node2D = null # Ссылка на игрока для урона при контакте
var damage_timer: float = 0.0
func _ready():
add_to_group("enemies")
if animated_sprite:
animated_sprite.play("move")
# Сигналы основного Area2D (для урона при контакте)
body_entered.connect(_on_body_entered)
body_exited.connect(_on_body_exited)
# НОВОЕ: Сигналы зоны обнаружения
detection_area.body_entered.connect(_on_detection_entered)
detection_area.body_exited.connect(_on_detection_exited)
# Настрой RayCast2D: Enabled = true, Collide With Bodies = true, Collision Mask = маска стен/платформ (например, 1)
func _physics_process(delta: float) -> void:
# Адаптировано по примеру: velocity = Vector2.ZERO; if player: velocity = direction speed
velocity = Vector2.ZERO
if is_chasing and target:
velocity = global_position.direction_to(target.global_position) speed
# Проверка RayCast2D на препятствия (адаптировано: проверка на velocity delta)
ray_cast.target_position = velocity delta
ray_cast.force_raycast_update()
if not ray_cast.is_colliding():
global_position += velocity * delta
# Анимация и поворот спрайта
if velocity.x > 0:
animated_sprite.flip_h = false
elif velocity.x < 0:
animated_sprite.flip_h = true
# Отладка преследования (раз в секунду)
if Engine.get_frames_drawn() % 60 == 0:
var distance = global_position.distance_to(target.global_position)
print("Враг преследует: расстояние ", distance, " позиция ", global_position)
# Постоянный урон игроку, если он в основном Area2D (контакт)
if player:
damage_timer += delta
if damage_timer >= 1.0 / damage_rate:
player.take_damage(damage)
print("Враг наносит урон персонажу: ", damage)
damage_timer = 0.0
func _on_body_entered(body):
if body.is_in_group("projectiles"):
take_damage(body.damage)
body.queue_free()
elif body.is_in_group("player"):
player = body # Запоминаем игрока для урона
func _on_body_exited(body):
if body == player:
player = null
damage_timer = 0.0
# НОВОЕ: Сигналы зоны обнаружения
func _on_detection_entered(body):
if body.is_in_group("player"):
is_chasing = true
target = body
print("Игрок вошёл в зону обнаружения: преследование начато")
func _on_detection_exited(body):
if body == target:
is_chasing = false
target = null
print("Игрок вышел из зоны обнаружения: преследование остановлено")
func take_damage(dmg: int):
health -= dmg
print("Враг получил урон: ", dmg, " Осталось здоровья: ", health)
flash_damage()
if health <= 0:
die()
# ОСТАВЛЕНО ТОЧНО КАК В ТВОЁМ КОДЕ: Логика tween и свечение
func flash_damage(duration: float = 0.15) -> void:
if not animated_sprite:
return
var tween = create_tween()
tween.tween_property(animated_sprite, "modulate", Color(10, 10, 10, 0.8), duration / 2)
await tween.finished
tween = create_tween()
tween.tween_property(animated_sprite, "modulate", Color(1, 1, 1, 1), duration / 2)
func die():
queue_free()
43 Кб, 494x401>>60516
Чета ты по моему перепутал, анон. Хотя я не знаю, может это такой художественный перформанс.
Тебе нужен CharacterBody2D. У него есть велосити и метод move_and_slide()
Потом просто обновляешь велосити так же, как ты делал тут
а потом хуяк
А вообще лучше всё с нуля перепиши. Хуже тебе от этого точно не станет.
Вот вам и вайб кодинг, пацаны.
>extends Area2D
>var velocity: Vector2 = Vector2.ZERO
Чета ты по моему перепутал, анон. Хотя я не знаю, может это такой художественный перформанс.
Тебе нужен CharacterBody2D. У него есть велосити и метод move_and_slide()
Потом просто обновляешь велосити так же, как ты делал тут
>velocity = global_position.direction_to(target.global_position) * speed
а потом хуяк
> move_and_slide()
А вообще лучше всё с нуля перепиши. Хуже тебе от этого точно не станет.
Вот вам и вайб кодинг, пацаны.
>>60526
Да я пробовал и так и через characterbody и вайб кодил и с ютуба гайды брал - один итог, враг какого-то хуя в другой конец карты от игрока улететь хочет. Ну я забил и просто рандомное движение сделал
Да я пробовал и так и через characterbody и вайб кодил и с ютуба гайды брал - один итог, враг какого-то хуя в другой конец карты от игрока улететь хочет. Ну я забил и просто рандомное движение сделал
>>60526
Сначала я тоже так подумал, но потом - если у него в геймплее требуется толпа врагов на пустой карте, как, например, в Vampire Survivors, то CharacterBody2D тут избыточен, только снизит производительность из-за множества лишних проверок. А в жанре RTS - даже Area3D использовать будет избыточным, поскольку выделение мышкой можно сделать намного проще, поэтому все юниты будут потомками голой Node2D.
>>60516
Я прочитал весь код, и в нём куча всего не совсем... стандартного, но по идее он должен работать. Может, ошибся с настройкой масок коллизий в инспекторе?
Не советую полагаться на LLM - модель может иметь достаточно знаний для генерации правдоподобно выглядящего кода, но она делает это как бы "наугад". Необходимо самому разбираться в коде лучше, чем языковая модель, чтобы использовать результаты эффективно - иначе ты только себе вредишь.
Теоретически нормально кодить могли бы "агенты", способные взаимодействовать с IDE и результатами собственной работы в т.ч. визуально, но пока что технологии недостаточно развиты - они брутфорсят ("бездумный перебор всех возможных вариантов"). Учитывая стоимость токенов - оно того не стоит.
>>60527
Попробуй поменять плюс на минус:
Иногда вся ошибка именно в этом.
Также помни, что ось Y направлена вниз экрана.
>Тебе нужен CharacterBody2D. У него есть
Сначала я тоже так подумал, но потом - если у него в геймплее требуется толпа врагов на пустой карте, как, например, в Vampire Survivors, то CharacterBody2D тут избыточен, только снизит производительность из-за множества лишних проверок. А в жанре RTS - даже Area3D использовать будет избыточным, поскольку выделение мышкой можно сделать намного проще, поэтому все юниты будут потомками голой Node2D.
>>60516
Я прочитал весь код, и в нём куча всего не совсем... стандартного, но по идее он должен работать. Может, ошибся с настройкой масок коллизий в инспекторе?
Не советую полагаться на LLM - модель может иметь достаточно знаний для генерации правдоподобно выглядящего кода, но она делает это как бы "наугад". Необходимо самому разбираться в коде лучше, чем языковая модель, чтобы использовать результаты эффективно - иначе ты только себе вредишь.
Теоретически нормально кодить могли бы "агенты", способные взаимодействовать с IDE и результатами собственной работы в т.ч. визуально, но пока что технологии недостаточно развиты - они брутфорсят ("бездумный перебор всех возможных вариантов"). Учитывая стоимость токенов - оно того не стоит.
>>60527
>в другой конец карты от игрока улететь хочет
Попробуй поменять плюс на минус:
>global_position -= velocity
Иногда вся ошибка именно в этом.
Также помни, что ось Y направлена вниз экрана.
>>60528
Я не видел, чтобы он говорил о жанре, который пилит, а потому отталкивался от дефолтного платформера. Но в любом случае, путь это хоть ареа, хоть голая нод2д, зачем изобретать велосипед с велосити, если можно тупо пододвигать моба к игроку через глобальную позицию? К глобальной позиции можно и анимации прикрутить, и что хочешь
Я не играл в Vampire Survivors, но как я понимаю там мобы просто спавнятся вокруг игрока и в тупую ломятся к нему, а значит никаких навагентов с маневрированиями применять не нужно будет. Лерпай себе позицию да в ус не дуй.
>>60527
Значит ты где-то что-то инверсируешь ненароком, как сказал анон выше.
>Сначала я тоже так подумал, но потом - если у него в геймплее требуется толпа врагов на пустой карте, как, например, в Vampire Survivors, то CharacterBody2D тут избыточен
Я не видел, чтобы он говорил о жанре, который пилит, а потому отталкивался от дефолтного платформера. Но в любом случае, путь это хоть ареа, хоть голая нод2д, зачем изобретать велосипед с велосити, если можно тупо пододвигать моба к игроку через глобальную позицию? К глобальной позиции можно и анимации прикрутить, и что хочешь
Я не играл в Vampire Survivors, но как я понимаю там мобы просто спавнятся вокруг игрока и в тупую ломятся к нему, а значит никаких навагентов с маневрированиями применять не нужно будет. Лерпай себе позицию да в ус не дуй.
>>60527
>враг какого-то хуя в другой конец карты от игрока улететь хочет
Значит ты где-то что-то инверсируешь ненароком, как сказал анон выше.
>>60528
Ну он сейчас просто в другую сторону полетел, он вообще почему-то по диагонали на какое-то расстояние улетает пока не упрётся в конец, потом уже следует за игроком держась такой дистанции
Ну он сейчас просто в другую сторону полетел, он вообще почему-то по диагонали на какое-то расстояние улетает пока не упрётся в конец, потом уже следует за игроком держась такой дистанции
>>60530
Хз у меня только этот скрипт управляет врагом
Хз у меня только этот скрипт управляет врагом
>>60531
Я кажется понял. Оталкиваясь от того, что ты тут наговнокодил: твой игрок коренную ноду случайно нигде не теряет?
Я кажется понял. Оталкиваясь от того, что ты тут наговнокодил: твой игрок коренную ноду случайно нигде не теряет?
>>60534
Ты проверь в рантайме где у тебя находится нода, с которой ты снимаешь позицию для переследования. Звучит так, будто ты криво управляешь игроком. Тогда всё встанет на свои места
Ты проверь в рантайме где у тебя находится нода, с которой ты снимаешь позицию для переследования. Звучит так, будто ты криво управляешь игроком. Тогда всё встанет на свои места
>>60530
У него в коде нет гравитации, так что вряд ли.
Лолшто? Velocity - это вектор скорости. Его обычно получают из направления, множителя и дельты. Это обязательная основа для движения разных мобов.
Ну, вот он и двигает через global_position += velocity.
>>60531
Сделай скриншот "дерева сцены" (scene tree).
Там должно быть что-то вроде этого:
У тебя как-то так это выглядит или иначе?
>отталкивался от дефолтного платформера
У него в коде нет гравитации, так что вряд ли.
>зачем изобретать велосипед с велосити
Лолшто? Velocity - это вектор скорости. Его обычно получают из направления, множителя и дельты. Это обязательная основа для движения разных мобов.
>можно тупо пододвигать моба к игроку
Ну, вот он и двигает через global_position += velocity.
>>60531
Сделай скриншот "дерева сцены" (scene tree).
Там должно быть что-то вроде этого:
>Game (Node)
>_ Player (Area2D)
>_ _ CollisionShape2D
>_ _ Sprite2D
>_ _ Camera2D
>_ Enemy (Area2D)
>_ _ CollisionShape2D
>_ _ Sprite2D
>_ _ RayCast2D
>_ _ ChaseTrigger (Area2D)
>_ _ _ CollisionShape2D
У тебя как-то так это выглядит или иначе?
>>60535
Бля, ты прав походу, я её в начальном углу оставил вот враг туда и летит. Правда непонятно почему он потом за помедлькой следует но реально ща проверю
Бля, ты прав походу, я её в начальном углу оставил вот враг туда и летит. Правда непонятно почему он потом за помедлькой следует но реально ща проверю
>>60537
Блять да че ты мне то рассказываешь, аноний? Я тут выдумаю как примитизировать всё в пол, а ты мне про вектор скорости. Если единственный фукционал обьекта двигаться с точки А в точку Б - достаточно тупо двигать его по позиции. Чендж май майнд.
>Лолшто? Velocity - это вектор скорости. Его обычно получают из направления, множителя и дельты. Это обязательная основа для движения разных мобов.
Блять да че ты мне то рассказываешь, аноний? Я тут выдумаю как примитизировать всё в пол, а ты мне про вектор скорости. Если единственный фукционал обьекта двигаться с точки А в точку Б - достаточно тупо двигать его по позиции. Чендж май майнд.
Короче да, проблема оказалась именно в этом, всем спасибо
Анон помогай.
В этих ваших интернетах миддиард мануалов как заставить квадратик бегать и прыгать, но нихуя нет по созданию интерфейсов.
Суть такова. Есть несколько спрайтов. Нужно рисовать одни поверх других. Типа нижний спрайт это голый чел, а верхний это спрайт брони, волос, обуви и т.п. Ну и кнопочки куда сюда. У всего этого должен быть черный задний фон. Как это правильно организовать?
В кооперации с интернотом получился Control, в нем SubViewContainer в нем SubView в нем Sprite2d
Но где там ему выставить черный бекграунд я хз.
Выглядит немного как избыточное говно. Может меня наебали, или я чего то не понимаю?
В этих ваших интернетах миддиард мануалов как заставить квадратик бегать и прыгать, но нихуя нет по созданию интерфейсов.
Суть такова. Есть несколько спрайтов. Нужно рисовать одни поверх других. Типа нижний спрайт это голый чел, а верхний это спрайт брони, волос, обуви и т.п. Ну и кнопочки куда сюда. У всего этого должен быть черный задний фон. Как это правильно организовать?
В кооперации с интернотом получился Control, в нем SubViewContainer в нем SubView в нем Sprite2d
Но где там ему выставить черный бекграунд я хз.
Выглядит немного как избыточное говно. Может меня наебали, или я чего то не понимаю?
>>60548
В кооперации с гопотой небось?
Сделай спрайт2д с голым челом, и по спрайту2д на каждый предмет одежды (ноги-руки-тело). Все это в общую сцену Node2D. По клику на контрол-ноды меняй картинку в спрайт2д для рук-ног-тела. Все.
А лучше туториалы официальные пройди, ты видимо с наскока хочешь все и сразу, не разбираясь.
>В кооперации с интернотом получился Control, в нем SubViewContainer в нем SubView в нем Sprite2d
В кооперации с гопотой небось?
Сделай спрайт2д с голым челом, и по спрайту2д на каждый предмет одежды (ноги-руки-тело). Все это в общую сцену Node2D. По клику на контрол-ноды меняй картинку в спрайт2д для рук-ног-тела. Все.
А лучше туториалы официальные пройди, ты видимо с наскока хочешь все и сразу, не разбираясь.
>>60550
С чем тока не общался. Даже с ютубом. Но я пока не в курсе как правильно задавать вопросы.
Где их брать? На сайте вижу только ссылку на доку.
> В кооперации с гопотой небось?
С чем тока не общался. Даже с ютубом. Но я пока не в курсе как правильно задавать вопросы.
> А лучше туториалы официальные пройди
Где их брать? На сайте вижу только ссылку на доку.
11 Кб, 262x171>>60558
https://docs.godotengine.org/ru/4.5/getting_started/introduction/index.html
Внизу-слева есть переключение версий движка и языка, выбери там свое.
https://docs.godotengine.org/ru/4.5/getting_started/introduction/index.html
Внизу-слева есть переключение версий движка и языка, выбери там свое.
25 Кб, 262x171>>60559
Поясню - тебе как минимум надо вот это все пройти. На 3д можешь забить если твоя игра не 3д.
Поясню - тебе как минимум надо вот это все пройти. На 3д можешь забить если твоя игра не 3д.
399 Кб, 633x639Сиводня-завтра я буду делать свои слоты с блекджеком и монетками. Кто нибудь делал такое? Как оно обычно работает в играх? Не в плане "как мне сделать механику?" а в плане "Как мне загеймдизайнить чтобы интересно игралось?". Джекпот будет дропать уникальные предметы, остальное будет сыпать расходники. По сути это такая сливалка лишней игровой валюты у игрока
>>60548
Всё есть. GUI в Godot интуитивно понятен.
У них одинаковые размеры?.. Впрочем, не важно.
Если именно в GUI - то можно просто стопку этого:
https://docs.godotengine.org/en/stable/classes/class_texturerect.html
Организуешь примерно так:
Важная инфа по позиционированию:
1. "Background" будет настраиваться "StatusMenu".
2. "NudeBase" и т.д. зависят лишь от позиции предка.
Т.е. все спрайты можно крутить и двигать как угодно.
Минусы есть, но вряд ли существенные для тебя.
>нет по созданию интерфейсов
Всё есть. GUI в Godot интуитивно понятен.
>Есть несколько спрайтов
У них одинаковые размеры?.. Впрочем, не важно.
>Нужно рисовать одни поверх других
>должен быть черный задний фон
Если именно в GUI - то можно просто стопку этого:
https://docs.godotengine.org/en/stable/classes/class_texturerect.html
Организуешь примерно так:
>StatusMenu: VBoxContainer # для примера
>_ Background: ColorRect # чёрный фон
>_ _ NudeBase: TextureRect
>_ _ _ Face: TextureRect
>_ _ _ _ Hair: TextureRect
>_ _ _ _ _ Helmet: TextureRect
>_ _ _ Chest: TextureRect
>_ _ _ Legs: TextureRect
Важная инфа по позиционированию:
1. "Background" будет настраиваться "StatusMenu".
2. "NudeBase" и т.д. зависят лишь от позиции предка.
Т.е. все спрайты можно крутить и двигать как угодно.
Минусы есть, но вряд ли существенные для тебя.
>>60568
Если хочешь пример, гугли "pity in gacha games".
Вкратце, гача/слоты в играх - это просто "скидка".
Пример:
1. Базовый шанс выиграть 0.5%.
2. Триггер "сострадания" на 80 круток.
3. Значит, макс. цена = 80 × цена крутки.
4. Но если повезёт, цена будет меньше этого.
Интерес гачи заключается в этом "вдруг повезёт".
Пример кода:
Есть ещё "soft pity": выше rolls == выше chance.
>загеймдизайнить чтобы интересно игралось
Если хочешь пример, гугли "pity in gacha games".
Вкратце, гача/слоты в играх - это просто "скидка".
Пример:
1. Базовый шанс выиграть 0.5%.
2. Триггер "сострадания" на 80 круток.
3. Значит, макс. цена = 80 × цена крутки.
4. Но если повезёт, цена будет меньше этого.
Интерес гачи заключается в этом "вдруг повезёт".
Пример кода:
>var rolls: int = 0
>var pity: int = 80
>var chance: float = 0.005
>func roll() -> bool:
>_ if randf() < chance or rolls >= pity:
>_ _ rolls = 0
>_ _ return true
>_ else:
>_ _ rolls += 1
>_ _ return false
Есть ещё "soft pity": выше rolls == выше chance.
>>60573
О. Кстати хороший совет, пушто я этой темой никогда не интересовался и думал просто рандомно крутить барабан. Спасибо
О. Кстати хороший совет, пушто я этой темой никогда не интересовался и думал просто рандомно крутить барабан. Спасибо
>>60573
Постил выше ссылку, сказали хуита, но там и про это есть:
https://github.com/raduacg/game-mechanics-optimizations
https://github.com/raduacg/game-mechanics-optimizations/blob/main/C_20_pity_mercy_systems.md
>Если хочешь пример, гугли "pity in gacha games".
Постил выше ссылку, сказали хуита, но там и про это есть:
https://github.com/raduacg/game-mechanics-optimizations
https://github.com/raduacg/game-mechanics-optimizations/blob/main/C_20_pity_mercy_systems.md
>>60574
Типичная ошибка, даже в больших проектах такое встречается. Проблема с рандомом в том, что самый настоящий рандом человек просто не ощущает как "настоящий", и может начать придумывать всякие оправдания, в худшем случае - "разрабы хитрят". Т.е. касается это не только "гачи", "лутбоксов" и т.п., а всех возможных источников рандома в игре.
>>60577
Там банальности в основном написаны. Про рандом написано очень много, только ленивый не писал про рандом. У тебя по ссылке избыток конкретных чисел и минимум теоретической информации (или ссылок).
Вот это бросилось в глаза, как пример лишних чисел:
Эти числа взяты с потолка - подойдут далеко не всем, поскольку зависят от стоимости одного "roll", в числе прочего - от длительности игровых сессий. В игре, где попытки дешёвые и часто встречаются, нет смысла занижать планку. В игре, где попытки дорогие и редко встречаются, "80-100" может означать, что игрок не доберётся до этой отметки в среднем. Особенно если конкретная игра - индюшатина на 2.5 часа геймплея, а не ММОРПГ на 10 лет прокачки персонажа 24/7.
Умный человек поймёт, что числа здесь не следует воспринимать буквально. А какой-то новичок или "интеллектуальный агент" может взять их как есть. Замусорили интернет бесполезной информацией...
>думал просто рандомно крутить барабан
Типичная ошибка, даже в больших проектах такое встречается. Проблема с рандомом в том, что самый настоящий рандом человек просто не ощущает как "настоящий", и может начать придумывать всякие оправдания, в худшем случае - "разрабы хитрят". Т.е. касается это не только "гачи", "лутбоксов" и т.п., а всех возможных источников рандома в игре.
>>60577
Там банальности в основном написаны. Про рандом написано очень много, только ленивый не писал про рандом. У тебя по ссылке избыток конкретных чисел и минимум теоретической информации (или ссылок).
Вот это бросилось в глаза, как пример лишних чисел:
>Too generous: Hard pity at 20 rolls = no RNG excitement. Sweet spot: 80-100 (long enough for RNG, short enough to tolerate).
Эти числа взяты с потолка - подойдут далеко не всем, поскольку зависят от стоимости одного "roll", в числе прочего - от длительности игровых сессий. В игре, где попытки дешёвые и часто встречаются, нет смысла занижать планку. В игре, где попытки дорогие и редко встречаются, "80-100" может означать, что игрок не доберётся до этой отметки в среднем. Особенно если конкретная игра - индюшатина на 2.5 часа геймплея, а не ММОРПГ на 10 лет прокачки персонажа 24/7.
Умный человек поймёт, что числа здесь не следует воспринимать буквально. А какой-то новичок или "интеллектуальный агент" может взять их как есть. Замусорили интернет бесполезной информацией...
11,3 Мб, mp4,640x360, 2:30
>>59249 (OP)
Спустя пару месяцев пытаюсь продолжить. Набросал вчера за пару часов механику настройки блоков, влияющих на движение - пока это двигатели и шары. Интерфейс чисто для теста - потом подумаю, что лучше подходит... И знаете, мне настолько понравилось тестировать, что я чуть не забыл записать видео процесса. Хотя фича тривиальная.
Как я к этому пришёл? Изначальная задумка игры, что сохраняется до сих пор - это ограничение по ресурсам и времени и требование двигаться вперёд на корабле, что постоянно разрушается и требует обслуживание прямо в полёте. Много думал о системе строительства, и пришёл к выводу, что хочу, чтобы корабль строился "тяп-ляп", но при этом следовал основным правилам физики - т.е. если игрок ставит двигатель, двигатель физически толкает корабль в точке, где он визуально расположен.
На практике оказалось, что из-за физики такой корабль необходимо строить симметрично, если блоки имеют одинаковые параметры. Но соблюдать симметрию в принципе сложно, а с ограничениями по ресурсам и с постоянными поломками будет совсем невозможно - буквально от выхода из строя одного двигателя весь корабль начинает закручивать. Мне уже пришлось отказаться от мелких деталей в пользу крупных кубов (по другим причинам), но принуждать игрока к абсолютной симметрии совсем не хочется.
Самое банальное решение, доступное в любой такой игре по умолчанию - это передвинуть блок в новое место, чаще всего разборкой и сборкой. Я таким часто вынужденно занимался во множестве игр и мне это совсем не нравится. К тому же, для большей точности блоки должны быть маленькими, а я уже решил, что моя игра будет в первую очередь из больших блоков. А удаление некоторых блоков (шары, например) полностью лишает часть корабля плавучести и это невыгодно игроку, т.к. переделку потребуется выполнять в полёте.
Поэтому я очень долго обдумывал идею автоматически распределять мощности движущих блоков, когда игрок задаёт на штурвале направление и корабль сам решает, какие двигатели на сколько процентов включать, и сам определяет степень накачки шаров газом. На словах это звучит интересно, но реализовать это оказалось намного сложнее, чем я думал, и на практике такая адаптация корабля будет мало чем отличаться от отсутствия правдоподобной физики как таковой: ты просто лепишь блоки и они сами как-то там работают, абстрагируя тебя от интересных деталей реализации движения.
Это привело меня к мысли всё-таки отказаться от правдоподобной физики и просто толкать центр RigidBody3D силой, равной сумме всех двигателей, полностью игнорируя их расположение на корабле. Некоторые подобные игры делают именно так, т.е. позволяют напихать движков в произвольных, порой абсурдных местах и получить на 100% стабильный и скоростной транспорт. Да, это открывает некоторые новые возможности в плане дизайна корабля, но с геймплейной точки зрения у тебя нет никаких ограничений, а значит, нет и мотивации экспериментировать - ты просто что-то произвольно лепишь, жмёшь W и оно как-то летит. Спрашивается, зачем тогда вообще что-то лепить? Это полностью перечёркивает всю задумку игры, поэтому прибегать к такому решению никак нельзя (пока я пытаюсь реализовать эту игру, а не совсем другую).
В итоге я долго мучился этими вопросами, буквально несколько лет. И хотя у меня мелькала мысль о том, чтобы позволить игроку индивидуально настраивать все блоки вручную, я как-то даже не пытался это сделать, почему-то надеясь найти способ автонастройки. Теперь понимаю, что вместо теоретизирования нужно было сразу сделать менюшку настройки и попробовать её на практике, а уже потом думать, как это всё автоматизировать и зачем.
Забавно, что я как-то не особо думал о формуле для вычисления мощности блока - взял первое пришедшее в голову, и только пересматривая несколько раз видео с демонстрацией этой фичи я осознал, что вместо "-1..1" было логичнее сделать "0..2", поскольку на практике это "от 0% до 200%", а не "от -100% до 100%". А ещё я заметил, что сам себя запутал подкруткой до "200%", и будет лучше ограничиться "от 0% (выкл.) до 100% (полная работа)". Т.е. штурвал даёт команду работать на, скажем, "80% мощности", а блок от этого процента убавляет от 0% до 100%. Изначально я планировал сделать возможность превышать 100%, но подкручивать блок выше базового значения как-то странно. Короче, это что-то вроде крана на трубе, который может ограничивать поток воды, но не может его усилить выше исходного... Кстати, несколько лет назад я ещё и трубы планировал прокладывать по блокам, но пока сомневаюсь в их применимости (всё из-за постепенного разрушения как основы геймплея - трубы сделают корабль более "хрупким"). Хмм, если всё-таки сделаю трубы, то можно будет прям реальные краны вставить и регулировать взглядом, отказавшись от лишнего интерфейса на экране.
А ещё я тут подумал недавно - а ведь квадратные блоки для корабля не настолько плохи, как кажутся. Блоки с прямыми углами создают впечатление искусственной постройки. Было бы странно делать почти голыми руками идеально округлые блоки... И это создаёт контраст с округлыми островами. Я планирую минимум три категории островов: натуральные - округлые и выпуклые, обломки кораблей - квадратные с прямыми углами, и "заражённые" (см. для примера биомы Terraria) - вогнутые с острыми углами. По идее, эта геометрия определённым образом влияет на психологию игрока (точно не помню, где я это читал, но чем острее углы - тем агрессивнее и опаснее кажется конкретный объект).
А теперь я собираюсь снова взяться за генерацию островов, потому что летать в пустоте или между одинаковыми островами слишком скучно... Я уже давно хотел генерировать как бы по принципу "матрёшки" - вкладывая шаблоны в шаблоны, но почему-то старый прототип не получился таким, каким я его ожидал. Мне кажется, нужно стандартизировать размеры шаблонов и комбинировать шаблоны внутри заданного радиуса. Мой изначальный прототип этой системы, кажется, не ограничивал радиус. Кажется, то, что я хочу, это трёхмерная версия вот этого алгоритма, которая позволила бы мне планировать все шаблоны прямо в 3D редакторе сцен без пересечений:
https://en.wikipedia.org/wiki/L-system
А у вас как успехи?
Спустя пару месяцев пытаюсь продолжить. Набросал вчера за пару часов механику настройки блоков, влияющих на движение - пока это двигатели и шары. Интерфейс чисто для теста - потом подумаю, что лучше подходит... И знаете, мне настолько понравилось тестировать, что я чуть не забыл записать видео процесса. Хотя фича тривиальная.
Как я к этому пришёл? Изначальная задумка игры, что сохраняется до сих пор - это ограничение по ресурсам и времени и требование двигаться вперёд на корабле, что постоянно разрушается и требует обслуживание прямо в полёте. Много думал о системе строительства, и пришёл к выводу, что хочу, чтобы корабль строился "тяп-ляп", но при этом следовал основным правилам физики - т.е. если игрок ставит двигатель, двигатель физически толкает корабль в точке, где он визуально расположен.
На практике оказалось, что из-за физики такой корабль необходимо строить симметрично, если блоки имеют одинаковые параметры. Но соблюдать симметрию в принципе сложно, а с ограничениями по ресурсам и с постоянными поломками будет совсем невозможно - буквально от выхода из строя одного двигателя весь корабль начинает закручивать. Мне уже пришлось отказаться от мелких деталей в пользу крупных кубов (по другим причинам), но принуждать игрока к абсолютной симметрии совсем не хочется.
Самое банальное решение, доступное в любой такой игре по умолчанию - это передвинуть блок в новое место, чаще всего разборкой и сборкой. Я таким часто вынужденно занимался во множестве игр и мне это совсем не нравится. К тому же, для большей точности блоки должны быть маленькими, а я уже решил, что моя игра будет в первую очередь из больших блоков. А удаление некоторых блоков (шары, например) полностью лишает часть корабля плавучести и это невыгодно игроку, т.к. переделку потребуется выполнять в полёте.
Поэтому я очень долго обдумывал идею автоматически распределять мощности движущих блоков, когда игрок задаёт на штурвале направление и корабль сам решает, какие двигатели на сколько процентов включать, и сам определяет степень накачки шаров газом. На словах это звучит интересно, но реализовать это оказалось намного сложнее, чем я думал, и на практике такая адаптация корабля будет мало чем отличаться от отсутствия правдоподобной физики как таковой: ты просто лепишь блоки и они сами как-то там работают, абстрагируя тебя от интересных деталей реализации движения.
Это привело меня к мысли всё-таки отказаться от правдоподобной физики и просто толкать центр RigidBody3D силой, равной сумме всех двигателей, полностью игнорируя их расположение на корабле. Некоторые подобные игры делают именно так, т.е. позволяют напихать движков в произвольных, порой абсурдных местах и получить на 100% стабильный и скоростной транспорт. Да, это открывает некоторые новые возможности в плане дизайна корабля, но с геймплейной точки зрения у тебя нет никаких ограничений, а значит, нет и мотивации экспериментировать - ты просто что-то произвольно лепишь, жмёшь W и оно как-то летит. Спрашивается, зачем тогда вообще что-то лепить? Это полностью перечёркивает всю задумку игры, поэтому прибегать к такому решению никак нельзя (пока я пытаюсь реализовать эту игру, а не совсем другую).
В итоге я долго мучился этими вопросами, буквально несколько лет. И хотя у меня мелькала мысль о том, чтобы позволить игроку индивидуально настраивать все блоки вручную, я как-то даже не пытался это сделать, почему-то надеясь найти способ автонастройки. Теперь понимаю, что вместо теоретизирования нужно было сразу сделать менюшку настройки и попробовать её на практике, а уже потом думать, как это всё автоматизировать и зачем.
Забавно, что я как-то не особо думал о формуле для вычисления мощности блока - взял первое пришедшее в голову, и только пересматривая несколько раз видео с демонстрацией этой фичи я осознал, что вместо "-1..1" было логичнее сделать "0..2", поскольку на практике это "от 0% до 200%", а не "от -100% до 100%". А ещё я заметил, что сам себя запутал подкруткой до "200%", и будет лучше ограничиться "от 0% (выкл.) до 100% (полная работа)". Т.е. штурвал даёт команду работать на, скажем, "80% мощности", а блок от этого процента убавляет от 0% до 100%. Изначально я планировал сделать возможность превышать 100%, но подкручивать блок выше базового значения как-то странно. Короче, это что-то вроде крана на трубе, который может ограничивать поток воды, но не может его усилить выше исходного... Кстати, несколько лет назад я ещё и трубы планировал прокладывать по блокам, но пока сомневаюсь в их применимости (всё из-за постепенного разрушения как основы геймплея - трубы сделают корабль более "хрупким"). Хмм, если всё-таки сделаю трубы, то можно будет прям реальные краны вставить и регулировать взглядом, отказавшись от лишнего интерфейса на экране.
А ещё я тут подумал недавно - а ведь квадратные блоки для корабля не настолько плохи, как кажутся. Блоки с прямыми углами создают впечатление искусственной постройки. Было бы странно делать почти голыми руками идеально округлые блоки... И это создаёт контраст с округлыми островами. Я планирую минимум три категории островов: натуральные - округлые и выпуклые, обломки кораблей - квадратные с прямыми углами, и "заражённые" (см. для примера биомы Terraria) - вогнутые с острыми углами. По идее, эта геометрия определённым образом влияет на психологию игрока (точно не помню, где я это читал, но чем острее углы - тем агрессивнее и опаснее кажется конкретный объект).
А теперь я собираюсь снова взяться за генерацию островов, потому что летать в пустоте или между одинаковыми островами слишком скучно... Я уже давно хотел генерировать как бы по принципу "матрёшки" - вкладывая шаблоны в шаблоны, но почему-то старый прототип не получился таким, каким я его ожидал. Мне кажется, нужно стандартизировать размеры шаблонов и комбинировать шаблоны внутри заданного радиуса. Мой изначальный прототип этой системы, кажется, не ограничивал радиус. Кажется, то, что я хочу, это трёхмерная версия вот этого алгоритма, которая позволила бы мне планировать все шаблоны прямо в 3D редакторе сцен без пересечений:
https://en.wikipedia.org/wiki/L-system
А у вас как успехи?
11,3 Мб, mp4,640x360, 2:30
>>59249 (OP)
Спустя пару месяцев пытаюсь продолжить. Набросал вчера за пару часов механику настройки блоков, влияющих на движение - пока это двигатели и шары. Интерфейс чисто для теста - потом подумаю, что лучше подходит... И знаете, мне настолько понравилось тестировать, что я чуть не забыл записать видео процесса. Хотя фича тривиальная.
Как я к этому пришёл? Изначальная задумка игры, что сохраняется до сих пор - это ограничение по ресурсам и времени и требование двигаться вперёд на корабле, что постоянно разрушается и требует обслуживание прямо в полёте. Много думал о системе строительства, и пришёл к выводу, что хочу, чтобы корабль строился "тяп-ляп", но при этом следовал основным правилам физики - т.е. если игрок ставит двигатель, двигатель физически толкает корабль в точке, где он визуально расположен.
На практике оказалось, что из-за физики такой корабль необходимо строить симметрично, если блоки имеют одинаковые параметры. Но соблюдать симметрию в принципе сложно, а с ограничениями по ресурсам и с постоянными поломками будет совсем невозможно - буквально от выхода из строя одного двигателя весь корабль начинает закручивать. Мне уже пришлось отказаться от мелких деталей в пользу крупных кубов (по другим причинам), но принуждать игрока к абсолютной симметрии совсем не хочется.
Самое банальное решение, доступное в любой такой игре по умолчанию - это передвинуть блок в новое место, чаще всего разборкой и сборкой. Я таким часто вынужденно занимался во множестве игр и мне это совсем не нравится. К тому же, для большей точности блоки должны быть маленькими, а я уже решил, что моя игра будет в первую очередь из больших блоков. А удаление некоторых блоков (шары, например) полностью лишает часть корабля плавучести и это невыгодно игроку, т.к. переделку потребуется выполнять в полёте.
Поэтому я очень долго обдумывал идею автоматически распределять мощности движущих блоков, когда игрок задаёт на штурвале направление и корабль сам решает, какие двигатели на сколько процентов включать, и сам определяет степень накачки шаров газом. На словах это звучит интересно, но реализовать это оказалось намного сложнее, чем я думал, и на практике такая адаптация корабля будет мало чем отличаться от отсутствия правдоподобной физики как таковой: ты просто лепишь блоки и они сами как-то там работают, абстрагируя тебя от интересных деталей реализации движения.
Это привело меня к мысли всё-таки отказаться от правдоподобной физики и просто толкать центр RigidBody3D силой, равной сумме всех двигателей, полностью игнорируя их расположение на корабле. Некоторые подобные игры делают именно так, т.е. позволяют напихать движков в произвольных, порой абсурдных местах и получить на 100% стабильный и скоростной транспорт. Да, это открывает некоторые новые возможности в плане дизайна корабля, но с геймплейной точки зрения у тебя нет никаких ограничений, а значит, нет и мотивации экспериментировать - ты просто что-то произвольно лепишь, жмёшь W и оно как-то летит. Спрашивается, зачем тогда вообще что-то лепить? Это полностью перечёркивает всю задумку игры, поэтому прибегать к такому решению никак нельзя (пока я пытаюсь реализовать эту игру, а не совсем другую).
В итоге я долго мучился этими вопросами, буквально несколько лет. И хотя у меня мелькала мысль о том, чтобы позволить игроку индивидуально настраивать все блоки вручную, я как-то даже не пытался это сделать, почему-то надеясь найти способ автонастройки. Теперь понимаю, что вместо теоретизирования нужно было сразу сделать менюшку настройки и попробовать её на практике, а уже потом думать, как это всё автоматизировать и зачем.
Забавно, что я как-то не особо думал о формуле для вычисления мощности блока - взял первое пришедшее в голову, и только пересматривая несколько раз видео с демонстрацией этой фичи я осознал, что вместо "-1..1" было логичнее сделать "0..2", поскольку на практике это "от 0% до 200%", а не "от -100% до 100%". А ещё я заметил, что сам себя запутал подкруткой до "200%", и будет лучше ограничиться "от 0% (выкл.) до 100% (полная работа)". Т.е. штурвал даёт команду работать на, скажем, "80% мощности", а блок от этого процента убавляет от 0% до 100%. Изначально я планировал сделать возможность превышать 100%, но подкручивать блок выше базового значения как-то странно. Короче, это что-то вроде крана на трубе, который может ограничивать поток воды, но не может его усилить выше исходного... Кстати, несколько лет назад я ещё и трубы планировал прокладывать по блокам, но пока сомневаюсь в их применимости (всё из-за постепенного разрушения как основы геймплея - трубы сделают корабль более "хрупким"). Хмм, если всё-таки сделаю трубы, то можно будет прям реальные краны вставить и регулировать взглядом, отказавшись от лишнего интерфейса на экране.
А ещё я тут подумал недавно - а ведь квадратные блоки для корабля не настолько плохи, как кажутся. Блоки с прямыми углами создают впечатление искусственной постройки. Было бы странно делать почти голыми руками идеально округлые блоки... И это создаёт контраст с округлыми островами. Я планирую минимум три категории островов: натуральные - округлые и выпуклые, обломки кораблей - квадратные с прямыми углами, и "заражённые" (см. для примера биомы Terraria) - вогнутые с острыми углами. По идее, эта геометрия определённым образом влияет на психологию игрока (точно не помню, где я это читал, но чем острее углы - тем агрессивнее и опаснее кажется конкретный объект).
А теперь я собираюсь снова взяться за генерацию островов, потому что летать в пустоте или между одинаковыми островами слишком скучно... Я уже давно хотел генерировать как бы по принципу "матрёшки" - вкладывая шаблоны в шаблоны, но почему-то старый прототип не получился таким, каким я его ожидал. Мне кажется, нужно стандартизировать размеры шаблонов и комбинировать шаблоны внутри заданного радиуса. Мой изначальный прототип этой системы, кажется, не ограничивал радиус. Кажется, то, что я хочу, это трёхмерная версия вот этого алгоритма, которая позволила бы мне планировать все шаблоны прямо в 3D редакторе сцен без пересечений:
https://en.wikipedia.org/wiki/L-system
А у вас как успехи?
Спустя пару месяцев пытаюсь продолжить. Набросал вчера за пару часов механику настройки блоков, влияющих на движение - пока это двигатели и шары. Интерфейс чисто для теста - потом подумаю, что лучше подходит... И знаете, мне настолько понравилось тестировать, что я чуть не забыл записать видео процесса. Хотя фича тривиальная.
Как я к этому пришёл? Изначальная задумка игры, что сохраняется до сих пор - это ограничение по ресурсам и времени и требование двигаться вперёд на корабле, что постоянно разрушается и требует обслуживание прямо в полёте. Много думал о системе строительства, и пришёл к выводу, что хочу, чтобы корабль строился "тяп-ляп", но при этом следовал основным правилам физики - т.е. если игрок ставит двигатель, двигатель физически толкает корабль в точке, где он визуально расположен.
На практике оказалось, что из-за физики такой корабль необходимо строить симметрично, если блоки имеют одинаковые параметры. Но соблюдать симметрию в принципе сложно, а с ограничениями по ресурсам и с постоянными поломками будет совсем невозможно - буквально от выхода из строя одного двигателя весь корабль начинает закручивать. Мне уже пришлось отказаться от мелких деталей в пользу крупных кубов (по другим причинам), но принуждать игрока к абсолютной симметрии совсем не хочется.
Самое банальное решение, доступное в любой такой игре по умолчанию - это передвинуть блок в новое место, чаще всего разборкой и сборкой. Я таким часто вынужденно занимался во множестве игр и мне это совсем не нравится. К тому же, для большей точности блоки должны быть маленькими, а я уже решил, что моя игра будет в первую очередь из больших блоков. А удаление некоторых блоков (шары, например) полностью лишает часть корабля плавучести и это невыгодно игроку, т.к. переделку потребуется выполнять в полёте.
Поэтому я очень долго обдумывал идею автоматически распределять мощности движущих блоков, когда игрок задаёт на штурвале направление и корабль сам решает, какие двигатели на сколько процентов включать, и сам определяет степень накачки шаров газом. На словах это звучит интересно, но реализовать это оказалось намного сложнее, чем я думал, и на практике такая адаптация корабля будет мало чем отличаться от отсутствия правдоподобной физики как таковой: ты просто лепишь блоки и они сами как-то там работают, абстрагируя тебя от интересных деталей реализации движения.
Это привело меня к мысли всё-таки отказаться от правдоподобной физики и просто толкать центр RigidBody3D силой, равной сумме всех двигателей, полностью игнорируя их расположение на корабле. Некоторые подобные игры делают именно так, т.е. позволяют напихать движков в произвольных, порой абсурдных местах и получить на 100% стабильный и скоростной транспорт. Да, это открывает некоторые новые возможности в плане дизайна корабля, но с геймплейной точки зрения у тебя нет никаких ограничений, а значит, нет и мотивации экспериментировать - ты просто что-то произвольно лепишь, жмёшь W и оно как-то летит. Спрашивается, зачем тогда вообще что-то лепить? Это полностью перечёркивает всю задумку игры, поэтому прибегать к такому решению никак нельзя (пока я пытаюсь реализовать эту игру, а не совсем другую).
В итоге я долго мучился этими вопросами, буквально несколько лет. И хотя у меня мелькала мысль о том, чтобы позволить игроку индивидуально настраивать все блоки вручную, я как-то даже не пытался это сделать, почему-то надеясь найти способ автонастройки. Теперь понимаю, что вместо теоретизирования нужно было сразу сделать менюшку настройки и попробовать её на практике, а уже потом думать, как это всё автоматизировать и зачем.
Забавно, что я как-то не особо думал о формуле для вычисления мощности блока - взял первое пришедшее в голову, и только пересматривая несколько раз видео с демонстрацией этой фичи я осознал, что вместо "-1..1" было логичнее сделать "0..2", поскольку на практике это "от 0% до 200%", а не "от -100% до 100%". А ещё я заметил, что сам себя запутал подкруткой до "200%", и будет лучше ограничиться "от 0% (выкл.) до 100% (полная работа)". Т.е. штурвал даёт команду работать на, скажем, "80% мощности", а блок от этого процента убавляет от 0% до 100%. Изначально я планировал сделать возможность превышать 100%, но подкручивать блок выше базового значения как-то странно. Короче, это что-то вроде крана на трубе, который может ограничивать поток воды, но не может его усилить выше исходного... Кстати, несколько лет назад я ещё и трубы планировал прокладывать по блокам, но пока сомневаюсь в их применимости (всё из-за постепенного разрушения как основы геймплея - трубы сделают корабль более "хрупким"). Хмм, если всё-таки сделаю трубы, то можно будет прям реальные краны вставить и регулировать взглядом, отказавшись от лишнего интерфейса на экране.
А ещё я тут подумал недавно - а ведь квадратные блоки для корабля не настолько плохи, как кажутся. Блоки с прямыми углами создают впечатление искусственной постройки. Было бы странно делать почти голыми руками идеально округлые блоки... И это создаёт контраст с округлыми островами. Я планирую минимум три категории островов: натуральные - округлые и выпуклые, обломки кораблей - квадратные с прямыми углами, и "заражённые" (см. для примера биомы Terraria) - вогнутые с острыми углами. По идее, эта геометрия определённым образом влияет на психологию игрока (точно не помню, где я это читал, но чем острее углы - тем агрессивнее и опаснее кажется конкретный объект).
А теперь я собираюсь снова взяться за генерацию островов, потому что летать в пустоте или между одинаковыми островами слишком скучно... Я уже давно хотел генерировать как бы по принципу "матрёшки" - вкладывая шаблоны в шаблоны, но почему-то старый прототип не получился таким, каким я его ожидал. Мне кажется, нужно стандартизировать размеры шаблонов и комбинировать шаблоны внутри заданного радиуса. Мой изначальный прототип этой системы, кажется, не ограничивал радиус. Кажется, то, что я хочу, это трёхмерная версия вот этого алгоритма, которая позволила бы мне планировать все шаблоны прямо в 3D редакторе сцен без пересечений:
https://en.wikipedia.org/wiki/L-system
А у вас как успехи?
>>60594
Посмотрел видос про советский тернарный компьютер Сетунь и про то как его варварски уничтожили. Словил дизмораль. Бухаю.
> А у вас как успехи?
Посмотрел видос про советский тернарный компьютер Сетунь и про то как его варварски уничтожили. Словил дизмораль. Бухаю.
>>60594
Хуя се ебать, анон. Я бы в такое поиграл. Есть у этого какой-то вайб мультиков про авиацию, где герои балдежно парят над облаками
Хуя се ебать, анон. Я бы в такое поиграл. Есть у этого какой-то вайб мультиков про авиацию, где герои балдежно парят над облаками
>>60597
Ты меня замотивировал игры делать.
Ты меня замотивировал игры делать.
Знающие аноны, подскажите.
Почти доделал игру, подготавливаю для релиза в стим.
Как правильно, и нужно ли вообще, указывать лицензии, сноски/ссылки на godot и прочее?
Желательно поподробнее, так как нихуя в этом не понимаю.
Игру планирую именно продавать.
Почти доделал игру, подготавливаю для релиза в стим.
Как правильно, и нужно ли вообще, указывать лицензии, сноски/ссылки на godot и прочее?
Желательно поподробнее, так как нихуя в этом не понимаю.
Игру планирую именно продавать.
50 Кб, 670x442>>60659
Ничего нигде не указывай. Лицензия годота позволяет делать продукты с закрытым исходным кодом и собственнической лицензией. А большинство игр именно таковы - закрыто, собственническо. Было бы странно, если бы движок запрещал тебе закрывать свой код.
Поэтому ещё раз, ничего нигде не указывай. Отсутствие написанной в комплекте поставки продукта лицензии автоматически означает проприетарную лицензию, которая запрещает всё, что не разрешено. А ты же хочешь запрещать всё? Так ведь? Запуск и проигрывание приобретенного продукта автоматически разрешены самим свойством исполняемого файла. Всё остальное - только с разрешения автора.
Если твоя игра делает простые текстовые файлы сохранения - значит ты позволяешь читерить. Если файлы хоть как-то мало мальски обфусцированы или зашифрованы - то всё, ты уже запретил их модифицировать. Попытки читерить нарушают твою проприетарную лицензию.
Которую, как я повторюсь, ты не обязан даже выписывать. Нет текста = всё запрещено. Есть возможность искаропки продукта = эта возможность разрешена. Автор не знал, что какая-то возможность есть искаропки, но не описал ни в каком тексте, что он запрещает = автор разрешил.
Ничего нигде не указывай. Лицензия годота позволяет делать продукты с закрытым исходным кодом и собственнической лицензией. А большинство игр именно таковы - закрыто, собственническо. Было бы странно, если бы движок запрещал тебе закрывать свой код.
Поэтому ещё раз, ничего нигде не указывай. Отсутствие написанной в комплекте поставки продукта лицензии автоматически означает проприетарную лицензию, которая запрещает всё, что не разрешено. А ты же хочешь запрещать всё? Так ведь? Запуск и проигрывание приобретенного продукта автоматически разрешены самим свойством исполняемого файла. Всё остальное - только с разрешения автора.
Если твоя игра делает простые текстовые файлы сохранения - значит ты позволяешь читерить. Если файлы хоть как-то мало мальски обфусцированы или зашифрованы - то всё, ты уже запретил их модифицировать. Попытки читерить нарушают твою проприетарную лицензию.
Которую, как я повторюсь, ты не обязан даже выписывать. Нет текста = всё запрещено. Есть возможность искаропки продукта = эта возможность разрешена. Автор не знал, что какая-то возможность есть искаропки, но не описал ни в каком тексте, что он запрещает = автор разрешил.
>>60661
... Но если ты хочешь помочь Годоту в качестве благодарности, то ты можешь прямо в игре указать что игра сделана на Годоте, пропиарить.
... Но если ты хочешь помочь Годоту в качестве благодарности, то ты можешь прямо в игре указать что игра сделана на Годоте, пропиарить.
>>60659
Я не в стиме, а на итче, но на итче всегда указываю что на годоте - и в метадате, и в описании. Движок этого не требует, просто для души указываю.
Я не в стиме, а на итче, но на итче всегда указываю что на годоте - и в метадате, и в описании. Движок этого не требует, просто для души указываю.
>>60659
Кстати это еще неплохой пиар ход. В стиме есть кураторы, собирающие игры на годоте:
https://store.steampowered.com/curator/41324400-Is-it-made-with-Godot/
https://store.steampowered.com/curator/45715609-Made-with-Godot-2
Кстати это еще неплохой пиар ход. В стиме есть кураторы, собирающие игры на годоте:
https://store.steampowered.com/curator/41324400-Is-it-made-with-Godot/
https://store.steampowered.com/curator/45715609-Made-with-Godot-2
>>60662
>>60663
>>60667
Ребята, спасибо! Ёмко, и по делу. Ещё вопрос - да, в качестве благодарности я бы хотел прилепить лого годота в splashcreen при старте игры, но проблема в том что игра у меня 640 на 360, и вся стилистика, в т.ч. шрифты, интерфейс и т.д. жестко стилизованы и пиксельны. Хотелось бы нарисовать свой логотип годота, но как я читал (вполне вероятно что ошибаюсь) этого делать не стоит, ведь логотип как раз таки имеет четкое авторство с указанием того как его использовать.
>>60663
>>60667
Ребята, спасибо! Ёмко, и по делу. Ещё вопрос - да, в качестве благодарности я бы хотел прилепить лого годота в splashcreen при старте игры, но проблема в том что игра у меня 640 на 360, и вся стилистика, в т.ч. шрифты, интерфейс и т.д. жестко стилизованы и пиксельны. Хотелось бы нарисовать свой логотип годота, но как я читал (вполне вероятно что ошибаюсь) этого делать не стоит, ведь логотип как раз таки имеет четкое авторство с указанием того как его использовать.
>>60670
Стоит и можно и люди делают. Вот например популярный набор фанмейд сплешскринов, обрати внимание на количество звездочек: https://github.com/KenneyNL/Godot-SplashScreens
Стоит и можно и люди делают. Вот например популярный набор фанмейд сплешскринов, обрати внимание на количество звездочек: https://github.com/KenneyNL/Godot-SplashScreens
153 Кб, 520x2850>>60661
Дурак, почитай реальные условия лицензии MIT.
https://en.wikipedia.org/wiki/MIT_License
https://opensource.org/license/MIT
Это так не работает с юридической точки зрения. Если ты каким-то образом получил доступ к "исполняемому файлу", это не гарантирует, что ты имеешь право его исполнять. Кроме того, в стиме приобретаются не игры, а лицензии на запуск этих игр, и эти лицензии можно отнять у игрока, запретив запуск исполняемых файлов (юридически; технически многие игры легко отсоединить от стима).
Это как с оружием: если тебе в руки попал пистолет, это не значит, что ты имеешь право из него стрелять, хотя чисто физически пистолет имеет эту функцию и работоспособен. Тебе нужна лицензия на владение огнестрельным оружием, в противном случае ты нарушаешь закон и должен понести ответственность за это. И если ты потерял лицензию, то по закону должен отдать и оружие, несмотря на то, что физически оно всё ещё при тебе и технически работает. Это в общих чертах так, подробностей я не уточнял (плюс в разных странах могут быть разные законы).
Это вообще отборный бред... Текстовые файлы, бинарные или даже шифрованные - это абсолютно ни на что не влияет с юридической стороны. Большинство веб-сайтов отдают JavaScript код и другие данные в открытом читабельном виде, но это не означает, что ты имеешь право его читать.
"Читерство" же в законе нигде явно не прописано, потому что это чисто геймерский сленг и у него довольно-таки размытые границы, но большинство онлайн-игр явным образом запрещают "читерство" в своей EULA, потому что без явного запрета "читерство" сложно уличить в нарушении каких-либо прав на игру. При том что сам игрок может и не взламывать продукт, а только пользоваться услугами третьих лиц (скачанные программы, скрывающие от пользователя, что они делают с игрой). Всё не так просто.
Опять бред. Многие технические устройства имеют специальные функции, которые рассчитанны лишь на специально обученных специалистов. Наличие некоторой функции не даёт право её использовать, даже если это что-то безопасное для жизни. Многие старые игры имели специальные "чит-коды" для дебаггинга игры, при этом их использование блокировало или ломало прогресс в игре, явным образом говоря "не трогай это".
Нет, это очевидная эксплуатация уязвимостей, т.е. фактически взлом продукта. Если автор о чём-то не знает, то это, скорее всего, дефект, и ты не имеешь права его эксплуатировать, но должен доложить о нём разработчику продукта (в целях безопасности). Многие такие "скрытые от разработчика возможности" в программах являются причиной, по которой тебе не стоит качать что попало из интернета и желательно иметь антивирус, а в прошлом это приводило к краху целых сетей и банкротству компаний - из-за "разрешённой возможности, неизвестной автору". И те, кто воспользовались этой возможностью, часто несли суровое наказание вплоть до многих лет тюрьмы.
Мне кажется, весь твой пост - троллинг ньюфага.
Но если ты тупанул, вот тебе ответ той же Алисы.
Кстати, в лицензии явно указано имя Хуана:
Так что лицензии ты обязан и о нём упоминать:
>>60663
Как раз-таки явно требует этого по лицензии MIT. И об этом указано и на сайте, и в документации, и на гитхабе, и в приложенных к исходникам файлах.
>>60659
Не слушай троллей/ньюфагов, читай документацию:
https://godotengine.org/license/
Вот здесь варианты указания лицензии на выбор:
https://docs.godotengine.org/en/stable/about/complying_with_licenses.html
Но ничего страшного в этом нет, не парься.
>Ничего нигде не указывай.
Дурак, почитай реальные условия лицензии MIT.
https://en.wikipedia.org/wiki/MIT_License
https://opensource.org/license/MIT
>...subject to the following conditions:
>The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
>Запуск и проигрывание приобретенного продукта автоматически разрешены самим свойством исполняемого файла.
Это так не работает с юридической точки зрения. Если ты каким-то образом получил доступ к "исполняемому файлу", это не гарантирует, что ты имеешь право его исполнять. Кроме того, в стиме приобретаются не игры, а лицензии на запуск этих игр, и эти лицензии можно отнять у игрока, запретив запуск исполняемых файлов (юридически; технически многие игры легко отсоединить от стима).
Это как с оружием: если тебе в руки попал пистолет, это не значит, что ты имеешь право из него стрелять, хотя чисто физически пистолет имеет эту функцию и работоспособен. Тебе нужна лицензия на владение огнестрельным оружием, в противном случае ты нарушаешь закон и должен понести ответственность за это. И если ты потерял лицензию, то по закону должен отдать и оружие, несмотря на то, что физически оно всё ещё при тебе и технически работает. Это в общих чертах так, подробностей я не уточнял (плюс в разных странах могут быть разные законы).
>Если твоя игра делает простые текстовые файлы сохранения - значит ты позволяешь читерить. Если файлы хоть как-то мало мальски обфусцированы или зашифрованы - то всё, ты уже запретил их модифицировать. Попытки читерить нарушают твою проприетарную лицензию.
Это вообще отборный бред... Текстовые файлы, бинарные или даже шифрованные - это абсолютно ни на что не влияет с юридической стороны. Большинство веб-сайтов отдают JavaScript код и другие данные в открытом читабельном виде, но это не означает, что ты имеешь право его читать.
"Читерство" же в законе нигде явно не прописано, потому что это чисто геймерский сленг и у него довольно-таки размытые границы, но большинство онлайн-игр явным образом запрещают "читерство" в своей EULA, потому что без явного запрета "читерство" сложно уличить в нарушении каких-либо прав на игру. При том что сам игрок может и не взламывать продукт, а только пользоваться услугами третьих лиц (скачанные программы, скрывающие от пользователя, что они делают с игрой). Всё не так просто.
>Нет текста = всё запрещено. Есть возможность искаропки продукта = эта возможность разрешена.
Опять бред. Многие технические устройства имеют специальные функции, которые рассчитанны лишь на специально обученных специалистов. Наличие некоторой функции не даёт право её использовать, даже если это что-то безопасное для жизни. Многие старые игры имели специальные "чит-коды" для дебаггинга игры, при этом их использование блокировало или ломало прогресс в игре, явным образом говоря "не трогай это".
>Автор не знал, что какая-то возможность есть искаропки, но не описал ни в каком тексте, что он запрещает = автор разрешил.
Нет, это очевидная эксплуатация уязвимостей, т.е. фактически взлом продукта. Если автор о чём-то не знает, то это, скорее всего, дефект, и ты не имеешь права его эксплуатировать, но должен доложить о нём разработчику продукта (в целях безопасности). Многие такие "скрытые от разработчика возможности" в программах являются причиной, по которой тебе не стоит качать что попало из интернета и желательно иметь антивирус, а в прошлом это приводило к краху целых сетей и банкротству компаний - из-за "разрешённой возможности, неизвестной автору". И те, кто воспользовались этой возможностью, часто несли суровое наказание вплоть до многих лет тюрьмы.
Мне кажется, весь твой пост - троллинг ньюфага.
Но если ты тупанул, вот тебе ответ той же Алисы.
Кстати, в лицензии явно указано имя Хуана:
>Copyright (c) 2014-present Godot Engine contributors.
>Copyright (c) 2007-2014 Juan Linietsky, Ariel Manzur.
Так что лицензии ты обязан и о нём упоминать:
>The above copyright notice...
>>60663
>Движок этого не требует
Как раз-таки явно требует этого по лицензии MIT. И об этом указано и на сайте, и в документации, и на гитхабе, и в приложенных к исходникам файлах.
>>60659
>Как правильно, и нужно ли вообще, указывать лицензии, сноски/ссылки на godot и прочее?
Не слушай троллей/ньюфагов, читай документацию:
https://godotengine.org/license/
>The only restriction to that third freedom is that you need to distribute the copyright notice and license statement of Godot Engine whenever you redistribute it. So your derivative product may have a different license, but should still state in its documentation that it derives from the MIT licensed Godot Engine (see below).
>Note however that the Godot Engine binary that you would distribute with your game is a copy of the "Software" as defined in the license, and you are therefore required to include the copyright notice and license statement somewhere in your documentation.
Вот здесь варианты указания лицензии на выбор:
https://docs.godotengine.org/en/stable/about/complying_with_licenses.html
Но ничего страшного в этом нет, не парься.
153 Кб, 520x2850>>60661
Дурак, почитай реальные условия лицензии MIT.
https://en.wikipedia.org/wiki/MIT_License
https://opensource.org/license/MIT
Это так не работает с юридической точки зрения. Если ты каким-то образом получил доступ к "исполняемому файлу", это не гарантирует, что ты имеешь право его исполнять. Кроме того, в стиме приобретаются не игры, а лицензии на запуск этих игр, и эти лицензии можно отнять у игрока, запретив запуск исполняемых файлов (юридически; технически многие игры легко отсоединить от стима).
Это как с оружием: если тебе в руки попал пистолет, это не значит, что ты имеешь право из него стрелять, хотя чисто физически пистолет имеет эту функцию и работоспособен. Тебе нужна лицензия на владение огнестрельным оружием, в противном случае ты нарушаешь закон и должен понести ответственность за это. И если ты потерял лицензию, то по закону должен отдать и оружие, несмотря на то, что физически оно всё ещё при тебе и технически работает. Это в общих чертах так, подробностей я не уточнял (плюс в разных странах могут быть разные законы).
Это вообще отборный бред... Текстовые файлы, бинарные или даже шифрованные - это абсолютно ни на что не влияет с юридической стороны. Большинство веб-сайтов отдают JavaScript код и другие данные в открытом читабельном виде, но это не означает, что ты имеешь право его читать.
"Читерство" же в законе нигде явно не прописано, потому что это чисто геймерский сленг и у него довольно-таки размытые границы, но большинство онлайн-игр явным образом запрещают "читерство" в своей EULA, потому что без явного запрета "читерство" сложно уличить в нарушении каких-либо прав на игру. При том что сам игрок может и не взламывать продукт, а только пользоваться услугами третьих лиц (скачанные программы, скрывающие от пользователя, что они делают с игрой). Всё не так просто.
Опять бред. Многие технические устройства имеют специальные функции, которые рассчитанны лишь на специально обученных специалистов. Наличие некоторой функции не даёт право её использовать, даже если это что-то безопасное для жизни. Многие старые игры имели специальные "чит-коды" для дебаггинга игры, при этом их использование блокировало или ломало прогресс в игре, явным образом говоря "не трогай это".
Нет, это очевидная эксплуатация уязвимостей, т.е. фактически взлом продукта. Если автор о чём-то не знает, то это, скорее всего, дефект, и ты не имеешь права его эксплуатировать, но должен доложить о нём разработчику продукта (в целях безопасности). Многие такие "скрытые от разработчика возможности" в программах являются причиной, по которой тебе не стоит качать что попало из интернета и желательно иметь антивирус, а в прошлом это приводило к краху целых сетей и банкротству компаний - из-за "разрешённой возможности, неизвестной автору". И те, кто воспользовались этой возможностью, часто несли суровое наказание вплоть до многих лет тюрьмы.
Мне кажется, весь твой пост - троллинг ньюфага.
Но если ты тупанул, вот тебе ответ той же Алисы.
Кстати, в лицензии явно указано имя Хуана:
Так что лицензии ты обязан и о нём упоминать:
>>60663
Как раз-таки явно требует этого по лицензии MIT. И об этом указано и на сайте, и в документации, и на гитхабе, и в приложенных к исходникам файлах.
>>60659
Не слушай троллей/ньюфагов, читай документацию:
https://godotengine.org/license/
Вот здесь варианты указания лицензии на выбор:
https://docs.godotengine.org/en/stable/about/complying_with_licenses.html
Но ничего страшного в этом нет, не парься.
>Ничего нигде не указывай.
Дурак, почитай реальные условия лицензии MIT.
https://en.wikipedia.org/wiki/MIT_License
https://opensource.org/license/MIT
>...subject to the following conditions:
>The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
>Запуск и проигрывание приобретенного продукта автоматически разрешены самим свойством исполняемого файла.
Это так не работает с юридической точки зрения. Если ты каким-то образом получил доступ к "исполняемому файлу", это не гарантирует, что ты имеешь право его исполнять. Кроме того, в стиме приобретаются не игры, а лицензии на запуск этих игр, и эти лицензии можно отнять у игрока, запретив запуск исполняемых файлов (юридически; технически многие игры легко отсоединить от стима).
Это как с оружием: если тебе в руки попал пистолет, это не значит, что ты имеешь право из него стрелять, хотя чисто физически пистолет имеет эту функцию и работоспособен. Тебе нужна лицензия на владение огнестрельным оружием, в противном случае ты нарушаешь закон и должен понести ответственность за это. И если ты потерял лицензию, то по закону должен отдать и оружие, несмотря на то, что физически оно всё ещё при тебе и технически работает. Это в общих чертах так, подробностей я не уточнял (плюс в разных странах могут быть разные законы).
>Если твоя игра делает простые текстовые файлы сохранения - значит ты позволяешь читерить. Если файлы хоть как-то мало мальски обфусцированы или зашифрованы - то всё, ты уже запретил их модифицировать. Попытки читерить нарушают твою проприетарную лицензию.
Это вообще отборный бред... Текстовые файлы, бинарные или даже шифрованные - это абсолютно ни на что не влияет с юридической стороны. Большинство веб-сайтов отдают JavaScript код и другие данные в открытом читабельном виде, но это не означает, что ты имеешь право его читать.
"Читерство" же в законе нигде явно не прописано, потому что это чисто геймерский сленг и у него довольно-таки размытые границы, но большинство онлайн-игр явным образом запрещают "читерство" в своей EULA, потому что без явного запрета "читерство" сложно уличить в нарушении каких-либо прав на игру. При том что сам игрок может и не взламывать продукт, а только пользоваться услугами третьих лиц (скачанные программы, скрывающие от пользователя, что они делают с игрой). Всё не так просто.
>Нет текста = всё запрещено. Есть возможность искаропки продукта = эта возможность разрешена.
Опять бред. Многие технические устройства имеют специальные функции, которые рассчитанны лишь на специально обученных специалистов. Наличие некоторой функции не даёт право её использовать, даже если это что-то безопасное для жизни. Многие старые игры имели специальные "чит-коды" для дебаггинга игры, при этом их использование блокировало или ломало прогресс в игре, явным образом говоря "не трогай это".
>Автор не знал, что какая-то возможность есть искаропки, но не описал ни в каком тексте, что он запрещает = автор разрешил.
Нет, это очевидная эксплуатация уязвимостей, т.е. фактически взлом продукта. Если автор о чём-то не знает, то это, скорее всего, дефект, и ты не имеешь права его эксплуатировать, но должен доложить о нём разработчику продукта (в целях безопасности). Многие такие "скрытые от разработчика возможности" в программах являются причиной, по которой тебе не стоит качать что попало из интернета и желательно иметь антивирус, а в прошлом это приводило к краху целых сетей и банкротству компаний - из-за "разрешённой возможности, неизвестной автору". И те, кто воспользовались этой возможностью, часто несли суровое наказание вплоть до многих лет тюрьмы.
Мне кажется, весь твой пост - троллинг ньюфага.
Но если ты тупанул, вот тебе ответ той же Алисы.
Кстати, в лицензии явно указано имя Хуана:
>Copyright (c) 2014-present Godot Engine contributors.
>Copyright (c) 2007-2014 Juan Linietsky, Ariel Manzur.
Так что лицензии ты обязан и о нём упоминать:
>The above copyright notice...
>>60663
>Движок этого не требует
Как раз-таки явно требует этого по лицензии MIT. И об этом указано и на сайте, и в документации, и на гитхабе, и в приложенных к исходникам файлах.
>>60659
>Как правильно, и нужно ли вообще, указывать лицензии, сноски/ссылки на godot и прочее?
Не слушай троллей/ньюфагов, читай документацию:
https://godotengine.org/license/
>The only restriction to that third freedom is that you need to distribute the copyright notice and license statement of Godot Engine whenever you redistribute it. So your derivative product may have a different license, but should still state in its documentation that it derives from the MIT licensed Godot Engine (see below).
>Note however that the Godot Engine binary that you would distribute with your game is a copy of the "Software" as defined in the license, and you are therefore required to include the copyright notice and license statement somewhere in your documentation.
Вот здесь варианты указания лицензии на выбор:
https://docs.godotengine.org/en/stable/about/complying_with_licenses.html
Но ничего страшного в этом нет, не парься.
>>60678
Читать умеешь или пока только писать? >>60677
>А как тогда и что указывать..?
Читать умеешь или пока только писать? >>60677
>Вот здесь варианты указания лицензии на выбор:
>https://docs.godotengine.org/en/stable/about/complying_with_licenses.html
127 Кб, 858x847Достаточно указать в "авторах" или вывести в аутпут лог, лол. Или вообще просто линк на годот вставить.
9 Кб, 369x97Ёбанная голубая шестеренкоголовая тварь блядь вылетает каждый сука раз когда меняю я тип ноды через эту кнопку. Кумарит пиздец!
>>60680
Да бля, я имею в виду, вставлять вот эту копипасту про лицензию MIT? Я в этих лицензиях не понимаю, и боюсь что неправильно вставлять такую лицензию в коммерческий продукт. Потому что не понимаю. Че агришься то епта
Да бля, я имею в виду, вставлять вот эту копипасту про лицензию MIT? Я в этих лицензиях не понимаю, и боюсь что неправильно вставлять такую лицензию в коммерческий продукт. Потому что не понимаю. Че агришься то епта
>>60687
В соей игре, в окошко "авторы", можешь в самом низу указать Made with Godot: godotengine.org/license
В соей игре, в окошко "авторы", можешь в самом низу указать Made with Godot: godotengine.org/license
>>60690
Спасибо
Спасибо
>>60687
Всё нормально. Можно сделать так, например:
Первая строчка - твоя закрытая лицензия.
Далее - упоминание Godot и его лицензии.
Видел такое в "mixed source" проектах...
>>60690
Честно говоря, всегда напрягает вот это "в окошке с авторами" - чтобы до этого окошка добраться, игра должна запуститься и показать меню без багов. Теоретически, может быть ситуация, когда кому-то потребуется узнать лицензию без запуска игры... А текстовый файлик доступен на любой ОС даже без запуска игры - достаточно файлового менеджера... В случае Android, APK вскрывается как простой ZIP и большинство файлов там никак не зашифровано.
Т.е. лучше иметь и меню "авторы", и текстовый файл.
>>60686
У меня тоже такое случалось, но когда-то давно. Предполагаю, что это происходит в определённых условиях... Ты меняешь тип корневой ноды? Лично предпочитаю сначала добавить нужную ноду как потомка, а потом сделать её корневой. Если это не корневая, то, может, у тебя там @tool-скрипт стоит? Частенько бывают ошибки из-за @tool-скриптов.
Посмотри журнал ошибок, есть ли там что-то. Есть специальный флаг -verbose, выводящий ещё больше информации о том, что происходит. Если это новая версия, желательно сделать баг-репорт на гитхаб.
>неправильно вставлять такую лицензию
Всё нормально. Можно сделать так, например:
>License.txt (в корневой папке игры)
>Copyright (c) 2025 Vasyan & Co. All rights reserved.
>
>Made with Godot Engine: godotengine.org/license
Первая строчка - твоя закрытая лицензия.
Далее - упоминание Godot и его лицензии.
Видел такое в "mixed source" проектах...
>>60690
Честно говоря, всегда напрягает вот это "в окошке с авторами" - чтобы до этого окошка добраться, игра должна запуститься и показать меню без багов. Теоретически, может быть ситуация, когда кому-то потребуется узнать лицензию без запуска игры... А текстовый файлик доступен на любой ОС даже без запуска игры - достаточно файлового менеджера... В случае Android, APK вскрывается как простой ZIP и большинство файлов там никак не зашифровано.
Т.е. лучше иметь и меню "авторы", и текстовый файл.
>>60686
>вылетает когда меняю тип ноды
У меня тоже такое случалось, но когда-то давно. Предполагаю, что это происходит в определённых условиях... Ты меняешь тип корневой ноды? Лично предпочитаю сначала добавить нужную ноду как потомка, а потом сделать её корневой. Если это не корневая, то, может, у тебя там @tool-скрипт стоит? Частенько бывают ошибки из-за @tool-скриптов.
Посмотри журнал ошибок, есть ли там что-то. Есть специальный флаг -verbose, выводящий ещё больше информации о том, что происходит. Если это новая версия, желательно сделать баг-репорт на гитхаб.
>>60692
На скрине выше пишут что этого уже достаточно. А дополнительные файлы меня напрягают как игрока.
>всегда напрягает вот это "в окошке с авторами"
На скрине выше пишут что этого уже достаточно. А дополнительные файлы меня напрягают как игрока.
Может немного бестактный вопросик, но тут именно на играх(не ассеты или работа в найме) кто-нибудь зарабатывает вообще?
8,1 Мб, mp4,640x360, 2:50
>>60594
Опять фигня какая-то получилась...
На просадки FPS не обращайте внимания, там очень много лишних нод даже в самых мелких островках, никакого LOD на них нет и оптимизировать можно существенно, но мне было лень этим заниматься. И некоторые острова непрерывно двигаются, хотя с расстояния это практически невозможно заметить. Кажется, основной тормоз - физический движок...
Признаю, было глупо надеяться, что разбрасывание всего десятка моделек по большой площади может дать что-то новое для геймплея... Нужно намного больше ассетов, чтобы их случайное разбрасывание по площади имело хоть какой-то эффект. Но я понятия не имею, что мне нужно в первую очередь, а что может подождать. Самое странное, что когда смотрю на похожие игры - там тоже нет ничего особенного. Ну, типа, вот земля, в неё натыканы палки и камни, иди собирай... и всё? Мне хочется чего-то интересного, но как это должно будет выглядеть на экране - смутно себе представляю.
Наверное, всё-таки нужны острова размером побольше, возможно, на порядок больше текущих (25 м -> 250 м), и собирать их из множества частей поменьше (чтобы они разрушались по частям). Уже пробовал такое и почему-то разочаровался в идее, а теперь вот наоборот думаю - стоит снова попробовать... И нужны ещё какие-то другие модельки - камни, кустики, цветочки. Хотя, так ли уж нужны?.. Не знаю. Никогда не интересовался созданием игровых локаций, поэтому это всё выглядит слишком трудным. Понимаю только что нужны периоды "расслабления" и "напряжения", в частности, более однородные и более выделяющиеся из общей массы участки карты.
Короче. Нужно завязывать с "прокрастинацией через алгоритмы" и заниматься созданием новых визуальных ассетов, потому что из десятка тестовых ассетов никаким алгоритмом не получится сделать разнообразный и интересный мир. Каждый раз забываю об этом и фокусируюсь на бессмысленных в конечном итоге деталях своего кода, потом вспоминаю и мучаюсь от осознания, что вообще не продвинулся к задуманной цели. И я не понимаю, почему постоянно наступаю на одни и те же грабли - уже много лет, между прочим...
А ещё я слишком фокусируюсь на этих статичных декорациях, когда, по идее, я должен ещё и мобов добавлять... В смысле, концептуально это должен получиться оживлённый мир, а не просто кучки безжизненных кусков земли в воздухе. Кажется, с летающими мобами даже с текущим набором декораций было бы не настолько уныло. Но я без понятия, когда именно можно переходить к мобам.
>>60597
Спасибо.
По жанру это "open world survival craft" должна быть. Только до играбельной версии ещё очень далеко (в особенности с тем, как я это делаю по 2 часа раз в несколько месяцев и без чётких ориентиров).
Да... На что-то такое ориентируюсь графически. Но пока что это всё плейсхолдеры - не уверен, как это будет выглядеть в более приличном виде. Даже не знаю, делать палитру насыщенной или пастельной - или, быть может, сделать её зависимой от биома...
>>60596
Когда-то давно читал про неё. Очень жаль...
Попробуй сделать мини-игру про троичную логику.
>взяться за генерацию островов
Опять фигня какая-то получилась...
На просадки FPS не обращайте внимания, там очень много лишних нод даже в самых мелких островках, никакого LOD на них нет и оптимизировать можно существенно, но мне было лень этим заниматься. И некоторые острова непрерывно двигаются, хотя с расстояния это практически невозможно заметить. Кажется, основной тормоз - физический движок...
Признаю, было глупо надеяться, что разбрасывание всего десятка моделек по большой площади может дать что-то новое для геймплея... Нужно намного больше ассетов, чтобы их случайное разбрасывание по площади имело хоть какой-то эффект. Но я понятия не имею, что мне нужно в первую очередь, а что может подождать. Самое странное, что когда смотрю на похожие игры - там тоже нет ничего особенного. Ну, типа, вот земля, в неё натыканы палки и камни, иди собирай... и всё? Мне хочется чего-то интересного, но как это должно будет выглядеть на экране - смутно себе представляю.
Наверное, всё-таки нужны острова размером побольше, возможно, на порядок больше текущих (25 м -> 250 м), и собирать их из множества частей поменьше (чтобы они разрушались по частям). Уже пробовал такое и почему-то разочаровался в идее, а теперь вот наоборот думаю - стоит снова попробовать... И нужны ещё какие-то другие модельки - камни, кустики, цветочки. Хотя, так ли уж нужны?.. Не знаю. Никогда не интересовался созданием игровых локаций, поэтому это всё выглядит слишком трудным. Понимаю только что нужны периоды "расслабления" и "напряжения", в частности, более однородные и более выделяющиеся из общей массы участки карты.
Короче. Нужно завязывать с "прокрастинацией через алгоритмы" и заниматься созданием новых визуальных ассетов, потому что из десятка тестовых ассетов никаким алгоритмом не получится сделать разнообразный и интересный мир. Каждый раз забываю об этом и фокусируюсь на бессмысленных в конечном итоге деталях своего кода, потом вспоминаю и мучаюсь от осознания, что вообще не продвинулся к задуманной цели. И я не понимаю, почему постоянно наступаю на одни и те же грабли - уже много лет, между прочим...
А ещё я слишком фокусируюсь на этих статичных декорациях, когда, по идее, я должен ещё и мобов добавлять... В смысле, концептуально это должен получиться оживлённый мир, а не просто кучки безжизненных кусков земли в воздухе. Кажется, с летающими мобами даже с текущим набором декораций было бы не настолько уныло. Но я без понятия, когда именно можно переходить к мобам.
>>60597
Спасибо.
>Я бы в такое поиграл.
По жанру это "open world survival craft" должна быть. Только до играбельной версии ещё очень далеко (в особенности с тем, как я это делаю по 2 часа раз в несколько месяцев и без чётких ориентиров).
>Есть у этого какой-то вайб мультиков про авиацию, где герои балдежно парят над облаками
Да... На что-то такое ориентируюсь графически. Но пока что это всё плейсхолдеры - не уверен, как это будет выглядеть в более приличном виде. Даже не знаю, делать палитру насыщенной или пастельной - или, быть может, сделать её зависимой от биома...
>>60596
>компьютер Сетунь
Когда-то давно читал про неё. Очень жаль...
>Словил дизмораль.
Попробуй сделать мини-игру про троичную логику.
8,1 Мб, mp4,640x360, 2:50
>>60594
Опять фигня какая-то получилась...
На просадки FPS не обращайте внимания, там очень много лишних нод даже в самых мелких островках, никакого LOD на них нет и оптимизировать можно существенно, но мне было лень этим заниматься. И некоторые острова непрерывно двигаются, хотя с расстояния это практически невозможно заметить. Кажется, основной тормоз - физический движок...
Признаю, было глупо надеяться, что разбрасывание всего десятка моделек по большой площади может дать что-то новое для геймплея... Нужно намного больше ассетов, чтобы их случайное разбрасывание по площади имело хоть какой-то эффект. Но я понятия не имею, что мне нужно в первую очередь, а что может подождать. Самое странное, что когда смотрю на похожие игры - там тоже нет ничего особенного. Ну, типа, вот земля, в неё натыканы палки и камни, иди собирай... и всё? Мне хочется чего-то интересного, но как это должно будет выглядеть на экране - смутно себе представляю.
Наверное, всё-таки нужны острова размером побольше, возможно, на порядок больше текущих (25 м -> 250 м), и собирать их из множества частей поменьше (чтобы они разрушались по частям). Уже пробовал такое и почему-то разочаровался в идее, а теперь вот наоборот думаю - стоит снова попробовать... И нужны ещё какие-то другие модельки - камни, кустики, цветочки. Хотя, так ли уж нужны?.. Не знаю. Никогда не интересовался созданием игровых локаций, поэтому это всё выглядит слишком трудным. Понимаю только что нужны периоды "расслабления" и "напряжения", в частности, более однородные и более выделяющиеся из общей массы участки карты.
Короче. Нужно завязывать с "прокрастинацией через алгоритмы" и заниматься созданием новых визуальных ассетов, потому что из десятка тестовых ассетов никаким алгоритмом не получится сделать разнообразный и интересный мир. Каждый раз забываю об этом и фокусируюсь на бессмысленных в конечном итоге деталях своего кода, потом вспоминаю и мучаюсь от осознания, что вообще не продвинулся к задуманной цели. И я не понимаю, почему постоянно наступаю на одни и те же грабли - уже много лет, между прочим...
А ещё я слишком фокусируюсь на этих статичных декорациях, когда, по идее, я должен ещё и мобов добавлять... В смысле, концептуально это должен получиться оживлённый мир, а не просто кучки безжизненных кусков земли в воздухе. Кажется, с летающими мобами даже с текущим набором декораций было бы не настолько уныло. Но я без понятия, когда именно можно переходить к мобам.
>>60597
Спасибо.
По жанру это "open world survival craft" должна быть. Только до играбельной версии ещё очень далеко (в особенности с тем, как я это делаю по 2 часа раз в несколько месяцев и без чётких ориентиров).
Да... На что-то такое ориентируюсь графически. Но пока что это всё плейсхолдеры - не уверен, как это будет выглядеть в более приличном виде. Даже не знаю, делать палитру насыщенной или пастельной - или, быть может, сделать её зависимой от биома...
>>60596
Когда-то давно читал про неё. Очень жаль...
Попробуй сделать мини-игру про троичную логику.
>взяться за генерацию островов
Опять фигня какая-то получилась...
На просадки FPS не обращайте внимания, там очень много лишних нод даже в самых мелких островках, никакого LOD на них нет и оптимизировать можно существенно, но мне было лень этим заниматься. И некоторые острова непрерывно двигаются, хотя с расстояния это практически невозможно заметить. Кажется, основной тормоз - физический движок...
Признаю, было глупо надеяться, что разбрасывание всего десятка моделек по большой площади может дать что-то новое для геймплея... Нужно намного больше ассетов, чтобы их случайное разбрасывание по площади имело хоть какой-то эффект. Но я понятия не имею, что мне нужно в первую очередь, а что может подождать. Самое странное, что когда смотрю на похожие игры - там тоже нет ничего особенного. Ну, типа, вот земля, в неё натыканы палки и камни, иди собирай... и всё? Мне хочется чего-то интересного, но как это должно будет выглядеть на экране - смутно себе представляю.
Наверное, всё-таки нужны острова размером побольше, возможно, на порядок больше текущих (25 м -> 250 м), и собирать их из множества частей поменьше (чтобы они разрушались по частям). Уже пробовал такое и почему-то разочаровался в идее, а теперь вот наоборот думаю - стоит снова попробовать... И нужны ещё какие-то другие модельки - камни, кустики, цветочки. Хотя, так ли уж нужны?.. Не знаю. Никогда не интересовался созданием игровых локаций, поэтому это всё выглядит слишком трудным. Понимаю только что нужны периоды "расслабления" и "напряжения", в частности, более однородные и более выделяющиеся из общей массы участки карты.
Короче. Нужно завязывать с "прокрастинацией через алгоритмы" и заниматься созданием новых визуальных ассетов, потому что из десятка тестовых ассетов никаким алгоритмом не получится сделать разнообразный и интересный мир. Каждый раз забываю об этом и фокусируюсь на бессмысленных в конечном итоге деталях своего кода, потом вспоминаю и мучаюсь от осознания, что вообще не продвинулся к задуманной цели. И я не понимаю, почему постоянно наступаю на одни и те же грабли - уже много лет, между прочим...
А ещё я слишком фокусируюсь на этих статичных декорациях, когда, по идее, я должен ещё и мобов добавлять... В смысле, концептуально это должен получиться оживлённый мир, а не просто кучки безжизненных кусков земли в воздухе. Кажется, с летающими мобами даже с текущим набором декораций было бы не настолько уныло. Но я без понятия, когда именно можно переходить к мобам.
>>60597
Спасибо.
>Я бы в такое поиграл.
По жанру это "open world survival craft" должна быть. Только до играбельной версии ещё очень далеко (в особенности с тем, как я это делаю по 2 часа раз в несколько месяцев и без чётких ориентиров).
>Есть у этого какой-то вайб мультиков про авиацию, где герои балдежно парят над облаками
Да... На что-то такое ориентируюсь графически. Но пока что это всё плейсхолдеры - не уверен, как это будет выглядеть в более приличном виде. Даже не знаю, делать палитру насыщенной или пастельной - или, быть может, сделать её зависимой от биома...
>>60596
>компьютер Сетунь
Когда-то давно читал про неё. Очень жаль...
>Словил дизмораль.
Попробуй сделать мини-игру про троичную логику.
>>60711
Уже начал. Уже днём накодил утилиты для конвертации в симметричную СС с любой базой и с подачей на вход преобразования набора символов, который будет это СС представлять, например ++-0-+ в случае троичной. Воот. С утилитами уже начну делать что-то более осмысленное.
Кстати, я придумал тебе обоснование твоего мира. Оно ведь буквально на поверхности лежало, а в треде никто не подсказал. Это кольцо (тор) с амосферой и островами существует, притягиваясь к кольцу (тору) из тёмной материи. И вот внутри этого тора существует тяготение, но выраженного центра масс нет - точнее он представляет собой опять же тор, единичного диаметра, в центре всего торообразного образования. Острова движутся то наружу из центра к краю, то обратно опускаются к центру. В зависимости от нагрева/охлаждения, например. Как тебе такая идея? Обдумой.
В таком случае не нужны костыли с газовыми шарами. Если легкий объект, типа ГГ-эльфийки упадёт с острова, она полетит вниз, но внизу, достигнув центра масс, она попадёт в невесомость, которую пролетит на другую сторону диаметрального сегмента тора. И где-то по пути всё равно попадётся остров или иной тяжёлый объект, за который ГГ зацепится крюком-кошкой.
А тяжёлые объекты в такой системе парадоксальным образом висят, как я описал выше, на своих местах, слегка изменяя высоту, словно покачиваясь на волнах. Потому что чем крупнее объект из химической материи, тем сильнее он взаимодействует с тёмной материей, вся эта локация она как бы внутри огромного пояса тёмных астероидов, которых так много в этом поясе, что они образуют практически равномерный гравитирующий тор.
>Попробуй сделать мини-игру про троичную логику.
Уже начал. Уже днём накодил утилиты для конвертации в симметричную СС с любой базой и с подачей на вход преобразования набора символов, который будет это СС представлять, например ++-0-+ в случае троичной. Воот. С утилитами уже начну делать что-то более осмысленное.
Кстати, я придумал тебе обоснование твоего мира. Оно ведь буквально на поверхности лежало, а в треде никто не подсказал. Это кольцо (тор) с амосферой и островами существует, притягиваясь к кольцу (тору) из тёмной материи. И вот внутри этого тора существует тяготение, но выраженного центра масс нет - точнее он представляет собой опять же тор, единичного диаметра, в центре всего торообразного образования. Острова движутся то наружу из центра к краю, то обратно опускаются к центру. В зависимости от нагрева/охлаждения, например. Как тебе такая идея? Обдумой.
В таком случае не нужны костыли с газовыми шарами. Если легкий объект, типа ГГ-эльфийки упадёт с острова, она полетит вниз, но внизу, достигнув центра масс, она попадёт в невесомость, которую пролетит на другую сторону диаметрального сегмента тора. И где-то по пути всё равно попадётся остров или иной тяжёлый объект, за который ГГ зацепится крюком-кошкой.
А тяжёлые объекты в такой системе парадоксальным образом висят, как я описал выше, на своих местах, слегка изменяя высоту, словно покачиваясь на волнах. Потому что чем крупнее объект из химической материи, тем сильнее он взаимодействует с тёмной материей, вся эта локация она как бы внутри огромного пояса тёмных астероидов, которых так много в этом поясе, что они образуют практически равномерный гравитирующий тор.
>>60718
Если в час то норм
Если в час то норм
>>60726
Научит ли это разработчиков годот делать нормальные сборки своего движка, чтобы они не вылетали?
Научит ли это разработчиков годот делать нормальные сборки своего движка, чтобы они не вылетали?
>>60692
Друг, большое спасибо за разъяснение, спасибо. Просто абсолютно несведущ в юридических вопросах.
А можно ещё вопрос? Имею ли я право вообще писать "copyright" если ни у каких юристов или в каком-то "авторском бюро" я ничего не регистрировал? Где-то читал что достаточно просто указать своё имя и по закону это уже считается интеллектуальной собственностью или че то такое, но мутная история учитывая что так в законодательстве РФ, а я сам с КЗ, и не уверен что у нас так (читал законы, ничего путного про компьютерное ПО там не нашел). Как с этим быть?
Т.е. если я выкладываю игру в стим от своего имени (или от своего творческого псевдонима например) то она автоматически становится защищена от разворовывания на части для других игр и так далее? Или как это работает.
Заранее извиняюсь если это глупый вопрос.
Друг, большое спасибо за разъяснение, спасибо. Просто абсолютно несведущ в юридических вопросах.
А можно ещё вопрос? Имею ли я право вообще писать "copyright" если ни у каких юристов или в каком-то "авторском бюро" я ничего не регистрировал? Где-то читал что достаточно просто указать своё имя и по закону это уже считается интеллектуальной собственностью или че то такое, но мутная история учитывая что так в законодательстве РФ, а я сам с КЗ, и не уверен что у нас так (читал законы, ничего путного про компьютерное ПО там не нашел). Как с этим быть?
Т.е. если я выкладываю игру в стим от своего имени (или от своего творческого псевдонима например) то она автоматически становится защищена от разворовывания на части для других игр и так далее? Или как это работает.
Заранее извиняюсь если это глупый вопрос.
>>60763
Копирайт - это не авторское право. Авторское право по факту авторства существует неотделимо между автором и произведением. А вот копирайт, copy, right, издательское право, оно уже регистрируется, перерегистрируется, передаётся, даётся или отнимается.
Копирайт - это не авторское право. Авторское право по факту авторства существует неотделимо между автором и произведением. А вот копирайт, copy, right, издательское право, оно уже регистрируется, перерегистрируется, передаётся, даётся или отнимается.
>>60763
И вообще, если кратко, то чё.
Я просто выкладываю свою игру, указываю свой ник в авторах, и всё? Больше ничего делать надо?
И вообще, если кратко, то чё.
Я просто выкладываю свою игру, указываю свой ник в авторах, и всё? Больше ничего делать надо?
74 Кб, 1061x740>>60784
Если вкратце, о чем говорили аноны, ты просто запихни в ресурсы проекта файл лицензии годота с их сайта. Если доебутся, скажешь, что вот в проект упакован файл, лицензионные требования соблюдены.
https://github.com/godotengine/godot/blob/master/LICENSE.txt - этот файл положи в корень проекта, в настройках проекта добавь полное имя на экспорт, как показано на пикче. И и тем самым будешь соблюдать требования MIT-лицензии.
Если вкратце, о чем говорили аноны, ты просто запихни в ресурсы проекта файл лицензии годота с их сайта. Если доебутся, скажешь, что вот в проект упакован файл, лицензионные требования соблюдены.
https://github.com/godotengine/godot/blob/master/LICENSE.txt - этот файл положи в корень проекта, в настройках проекта добавь полное имя на экспорт, как показано на пикче. И и тем самым будешь соблюдать требования MIT-лицензии.
>>60855
Экстрасенсы в отпуске, так что сам говори:
1. Какая версия движка? 3/4? Стабильная/dev?
2. Какая ОС/версия Windows? Драйвера новые?
3. Какая видеокарта (Intel iGPU/NVidia/AMD)?
4. В настройках Godot многооконный режим?
5. Рендерер - Forward+/Mobile/Compatibility?
6. Особые приложения/драйверы на фоне?
7. Мышка обычная офисная/геймерская?
Ну и т.д. Кто тебя знает, с чего ты капчуешь?
Экстрасенсы в отпуске, так что сам говори:
1. Какая версия движка? 3/4? Стабильная/dev?
2. Какая ОС/версия Windows? Драйвера новые?
3. Какая видеокарта (Intel iGPU/NVidia/AMD)?
4. В настройках Godot многооконный режим?
5. Рендерер - Forward+/Mobile/Compatibility?
6. Особые приложения/драйверы на фоне?
7. Мышка обычная офисная/геймерская?
Ну и т.д. Кто тебя знает, с чего ты капчуешь?
>>60763
Лучше к настоящим юристам обратись, которые разбираются конкретно в авторском праве. Я лишь в общих чертах пересказываю то, что где-то прочитал. Вероятно, где-то ошибаюсь, так что не верь на слово.
Впрочем, ты сам залез на анонимный форум...
Вообще не обязательно. Даже если анонимно что-то творческое постишь в интернете (как здесь), то все эксклюзивные авторские права остаются у тебя. Но, разумеется, это не остановит злоумышленника от использования твоих файлов, поэтому игра не
Даже если ты на каждом ассете напишешь "сделано Василием Пупкиным". Это как с убийством: по закону убивать запрещено, но это не защищает от убийства конкретно тебя, поскольку наказывать убийцу будут после твоего убийства... если твой труп и виновника вообще кто-нибудь сможет найти и доказать вину.
Как это обычно происходит с индивидуалами:
1. Вася Пупкин (ты) публикует свою игру в интернет.
2. Спустя N времени Вася Пупкин обнаруживает (самостоятельно/от обеспокоенных фанатов), что существует другая игра, в которой присутствует подозрительно похожий ассет, который он сделал и использовал только в своей игре и нигде больше.
3. Далее Вася Пупкин может:
а. Лично написать автору той другой игры и вежливо попросить удалить подозрительный ассет или дать материальную компенсацию за его использование. Большинство не хотят конфликтов и могут сразу откликнуться и удалить файлы, но далеко не все. Возможно также, что наш Вася просто обознался.
б. Написать письмо площадке, которая занимается распространением той другой игры: Steam, itch.io, хостинг-провайдер (личный веб-сайт) и т.д. Если это американская площадка, то она должна отвечать на специальный формат, называемый "DMCA notice". Площадка может удалить игру или проигнорировать.
в. Обратиться в суд. Но с этим связано очень много проблем, и в случае проигрыша ты будешь обязан заплатить компенсацию, так что лучше не доводить. Большинство конфликтов решаются до суда. Но если придётся дойти до суда, то тебе нужны материальные доказательства своего авторства - это могут быть исходные файлы, которые ты нигде не публиковал и которые нельзя восстановить из опубликованного. В прошлом часто рекомендовали отправить файлы на оптическом диске по почте самому себе и держать конверт нераскрытым в качестве доказательства...
Стоит ли волноваться по этому поводу? Вряд ли твои ассеты чего-то стоят и кому-то могут понадобиться (в смысле, отдельно от твоей игры, а не как вся игра, но целиком игры редко копируют, это скорее пиратство). Крупные проекты не занимаются таким воровством, поскольку им не нужны судебные разбирательства. А мелкие воришки - это какие-то школьники, у которых наверняка ничего не получится даже с ассетами. Если крупный проект что-то у тебя своровал - это с шансом 99.9% вина одного наёмного работника и владельцы компании должны отреагировать в твою пользу.
Главное - это чтобы ты ничего ни у кого не воровал. Поскольку, хотя Вася Пупкин вряд ли сможет тебе навредить или даже узнать о тебе, крупная компания обязательно о тебе узнает и накажет так, что мало не покажется. Особенно если игра принесёт деньги и популярность с этим ворованным ассетом. Не бери случайные ассеты из интернета, даже если тебе по каким-то причинам кажется, что они "ничейные" (опубликованные анонимно/от имени "Васи"). И с нейронками по этой причине лучше не связываться (проблемная тема - нейронки могут выдавать куски защищённых копирайтом данных, а ты никак не определишь на глаз, где сгенерировался подвох).
Особенно касается музыки. В музыкальной сфере издательства (лейблы) очень агрессивно защищают собственные права на музыку, которую им отдают музыканты. Т.е. сами музыканты получают от них определённую зарплату, а лейбл распространяет и защищает права. Они давно автоматизировали весь процесс поиска и наказания за нарушения АП. Даже "бесплатная и свободная" музыка может оказаться подставой от какого-нибудь паршивого лейбла. Т.е. желательно не юзать случайную музыку из сети.
Но прикол в том, что в других сферах такого нет или практически нет. Т.е. ни Steam, ни издатель игры не будет бегать по сети и искать обрывки твоей игры в случайных местах. Даже сам Steam может случайно разрешить публикацию ворованных ассетов - были прецеденты. Конечно, Steam откликается на DMCA, однако, DMCA может отправить только сам автор (официальный представитель автора), а для этого необходимо сначала найти, кто у тебя своровал. А площадки типа itch.io имеют слабую модерацию - постоянно публикуется сомнительный контент...
Хуже всего дело обстоит с кодом. Если визуальные материалы игра показывает на экране как есть, то определить авторство кода игры без "взлома" не представляется возможным. Декомпиляция игры является нарушением закона, поэтому обвинением в ворованном коде ты, по сути, подставляешь себя. Спасает тут то, что твой говнокод в скриптах будет бесполезен практически любой другой игре, т.е. код копировать у тебя вряд ли будут. Чаще всего воруют платные аддоны с маркета - т.е. скачивают что-то с торрентов вместо честной оплаты лицензии, т.к. эти аддоны рассчитаны на множество разных проектов.
А лучше всего не париться и делать open source игру.
>абсолютно несведущ в юридических вопросах
Лучше к настоящим юристам обратись, которые разбираются конкретно в авторском праве. Я лишь в общих чертах пересказываю то, что где-то прочитал. Вероятно, где-то ошибаюсь, так что не верь на слово.
Впрочем, ты сам залез на анонимный форум...
>достаточно просто указать своё имя
Вообще не обязательно. Даже если анонимно что-то творческое постишь в интернете (как здесь), то все эксклюзивные авторские права остаются у тебя. Но, разумеется, это не остановит злоумышленника от использования твоих файлов, поэтому игра не
>защищена от разворовывания на части
Даже если ты на каждом ассете напишешь "сделано Василием Пупкиным". Это как с убийством: по закону убивать запрещено, но это не защищает от убийства конкретно тебя, поскольку наказывать убийцу будут после твоего убийства... если твой труп и виновника вообще кто-нибудь сможет найти и доказать вину.
Как это обычно происходит с индивидуалами:
1. Вася Пупкин (ты) публикует свою игру в интернет.
2. Спустя N времени Вася Пупкин обнаруживает (самостоятельно/от обеспокоенных фанатов), что существует другая игра, в которой присутствует подозрительно похожий ассет, который он сделал и использовал только в своей игре и нигде больше.
3. Далее Вася Пупкин может:
а. Лично написать автору той другой игры и вежливо попросить удалить подозрительный ассет или дать материальную компенсацию за его использование. Большинство не хотят конфликтов и могут сразу откликнуться и удалить файлы, но далеко не все. Возможно также, что наш Вася просто обознался.
б. Написать письмо площадке, которая занимается распространением той другой игры: Steam, itch.io, хостинг-провайдер (личный веб-сайт) и т.д. Если это американская площадка, то она должна отвечать на специальный формат, называемый "DMCA notice". Площадка может удалить игру или проигнорировать.
в. Обратиться в суд. Но с этим связано очень много проблем, и в случае проигрыша ты будешь обязан заплатить компенсацию, так что лучше не доводить. Большинство конфликтов решаются до суда. Но если придётся дойти до суда, то тебе нужны материальные доказательства своего авторства - это могут быть исходные файлы, которые ты нигде не публиковал и которые нельзя восстановить из опубликованного. В прошлом часто рекомендовали отправить файлы на оптическом диске по почте самому себе и держать конверт нераскрытым в качестве доказательства...
Стоит ли волноваться по этому поводу? Вряд ли твои ассеты чего-то стоят и кому-то могут понадобиться (в смысле, отдельно от твоей игры, а не как вся игра, но целиком игры редко копируют, это скорее пиратство). Крупные проекты не занимаются таким воровством, поскольку им не нужны судебные разбирательства. А мелкие воришки - это какие-то школьники, у которых наверняка ничего не получится даже с ассетами. Если крупный проект что-то у тебя своровал - это с шансом 99.9% вина одного наёмного работника и владельцы компании должны отреагировать в твою пользу.
Главное - это чтобы ты ничего ни у кого не воровал. Поскольку, хотя Вася Пупкин вряд ли сможет тебе навредить или даже узнать о тебе, крупная компания обязательно о тебе узнает и накажет так, что мало не покажется. Особенно если игра принесёт деньги и популярность с этим ворованным ассетом. Не бери случайные ассеты из интернета, даже если тебе по каким-то причинам кажется, что они "ничейные" (опубликованные анонимно/от имени "Васи"). И с нейронками по этой причине лучше не связываться (проблемная тема - нейронки могут выдавать куски защищённых копирайтом данных, а ты никак не определишь на глаз, где сгенерировался подвох).
Особенно касается музыки. В музыкальной сфере издательства (лейблы) очень агрессивно защищают собственные права на музыку, которую им отдают музыканты. Т.е. сами музыканты получают от них определённую зарплату, а лейбл распространяет и защищает права. Они давно автоматизировали весь процесс поиска и наказания за нарушения АП. Даже "бесплатная и свободная" музыка может оказаться подставой от какого-нибудь паршивого лейбла. Т.е. желательно не юзать случайную музыку из сети.
Но прикол в том, что в других сферах такого нет или практически нет. Т.е. ни Steam, ни издатель игры не будет бегать по сети и искать обрывки твоей игры в случайных местах. Даже сам Steam может случайно разрешить публикацию ворованных ассетов - были прецеденты. Конечно, Steam откликается на DMCA, однако, DMCA может отправить только сам автор (официальный представитель автора), а для этого необходимо сначала найти, кто у тебя своровал. А площадки типа itch.io имеют слабую модерацию - постоянно публикуется сомнительный контент...
Хуже всего дело обстоит с кодом. Если визуальные материалы игра показывает на экране как есть, то определить авторство кода игры без "взлома" не представляется возможным. Декомпиляция игры является нарушением закона, поэтому обвинением в ворованном коде ты, по сути, подставляешь себя. Спасает тут то, что твой говнокод в скриптах будет бесполезен практически любой другой игре, т.е. код копировать у тебя вряд ли будут. Чаще всего воруют платные аддоны с маркета - т.е. скачивают что-то с торрентов вместо честной оплаты лицензии, т.к. эти аддоны рассчитаны на множество разных проектов.
А лучше всего не париться и делать open source игру.
>>60763
Лучше к настоящим юристам обратись, которые разбираются конкретно в авторском праве. Я лишь в общих чертах пересказываю то, что где-то прочитал. Вероятно, где-то ошибаюсь, так что не верь на слово.
Впрочем, ты сам залез на анонимный форум...
Вообще не обязательно. Даже если анонимно что-то творческое постишь в интернете (как здесь), то все эксклюзивные авторские права остаются у тебя. Но, разумеется, это не остановит злоумышленника от использования твоих файлов, поэтому игра не
Даже если ты на каждом ассете напишешь "сделано Василием Пупкиным". Это как с убийством: по закону убивать запрещено, но это не защищает от убийства конкретно тебя, поскольку наказывать убийцу будут после твоего убийства... если твой труп и виновника вообще кто-нибудь сможет найти и доказать вину.
Как это обычно происходит с индивидуалами:
1. Вася Пупкин (ты) публикует свою игру в интернет.
2. Спустя N времени Вася Пупкин обнаруживает (самостоятельно/от обеспокоенных фанатов), что существует другая игра, в которой присутствует подозрительно похожий ассет, который он сделал и использовал только в своей игре и нигде больше.
3. Далее Вася Пупкин может:
а. Лично написать автору той другой игры и вежливо попросить удалить подозрительный ассет или дать материальную компенсацию за его использование. Большинство не хотят конфликтов и могут сразу откликнуться и удалить файлы, но далеко не все. Возможно также, что наш Вася просто обознался.
б. Написать письмо площадке, которая занимается распространением той другой игры: Steam, itch.io, хостинг-провайдер (личный веб-сайт) и т.д. Если это американская площадка, то она должна отвечать на специальный формат, называемый "DMCA notice". Площадка может удалить игру или проигнорировать.
в. Обратиться в суд. Но с этим связано очень много проблем, и в случае проигрыша ты будешь обязан заплатить компенсацию, так что лучше не доводить. Большинство конфликтов решаются до суда. Но если придётся дойти до суда, то тебе нужны материальные доказательства своего авторства - это могут быть исходные файлы, которые ты нигде не публиковал и которые нельзя восстановить из опубликованного. В прошлом часто рекомендовали отправить файлы на оптическом диске по почте самому себе и держать конверт нераскрытым в качестве доказательства...
Стоит ли волноваться по этому поводу? Вряд ли твои ассеты чего-то стоят и кому-то могут понадобиться (в смысле, отдельно от твоей игры, а не как вся игра, но целиком игры редко копируют, это скорее пиратство). Крупные проекты не занимаются таким воровством, поскольку им не нужны судебные разбирательства. А мелкие воришки - это какие-то школьники, у которых наверняка ничего не получится даже с ассетами. Если крупный проект что-то у тебя своровал - это с шансом 99.9% вина одного наёмного работника и владельцы компании должны отреагировать в твою пользу.
Главное - это чтобы ты ничего ни у кого не воровал. Поскольку, хотя Вася Пупкин вряд ли сможет тебе навредить или даже узнать о тебе, крупная компания обязательно о тебе узнает и накажет так, что мало не покажется. Особенно если игра принесёт деньги и популярность с этим ворованным ассетом. Не бери случайные ассеты из интернета, даже если тебе по каким-то причинам кажется, что они "ничейные" (опубликованные анонимно/от имени "Васи"). И с нейронками по этой причине лучше не связываться (проблемная тема - нейронки могут выдавать куски защищённых копирайтом данных, а ты никак не определишь на глаз, где сгенерировался подвох).
Особенно касается музыки. В музыкальной сфере издательства (лейблы) очень агрессивно защищают собственные права на музыку, которую им отдают музыканты. Т.е. сами музыканты получают от них определённую зарплату, а лейбл распространяет и защищает права. Они давно автоматизировали весь процесс поиска и наказания за нарушения АП. Даже "бесплатная и свободная" музыка может оказаться подставой от какого-нибудь паршивого лейбла. Т.е. желательно не юзать случайную музыку из сети.
Но прикол в том, что в других сферах такого нет или практически нет. Т.е. ни Steam, ни издатель игры не будет бегать по сети и искать обрывки твоей игры в случайных местах. Даже сам Steam может случайно разрешить публикацию ворованных ассетов - были прецеденты. Конечно, Steam откликается на DMCA, однако, DMCA может отправить только сам автор (официальный представитель автора), а для этого необходимо сначала найти, кто у тебя своровал. А площадки типа itch.io имеют слабую модерацию - постоянно публикуется сомнительный контент...
Хуже всего дело обстоит с кодом. Если визуальные материалы игра показывает на экране как есть, то определить авторство кода игры без "взлома" не представляется возможным. Декомпиляция игры является нарушением закона, поэтому обвинением в ворованном коде ты, по сути, подставляешь себя. Спасает тут то, что твой говнокод в скриптах будет бесполезен практически любой другой игре, т.е. код копировать у тебя вряд ли будут. Чаще всего воруют платные аддоны с маркета - т.е. скачивают что-то с торрентов вместо честной оплаты лицензии, т.к. эти аддоны рассчитаны на множество разных проектов.
А лучше всего не париться и делать open source игру.
>абсолютно несведущ в юридических вопросах
Лучше к настоящим юристам обратись, которые разбираются конкретно в авторском праве. Я лишь в общих чертах пересказываю то, что где-то прочитал. Вероятно, где-то ошибаюсь, так что не верь на слово.
Впрочем, ты сам залез на анонимный форум...
>достаточно просто указать своё имя
Вообще не обязательно. Даже если анонимно что-то творческое постишь в интернете (как здесь), то все эксклюзивные авторские права остаются у тебя. Но, разумеется, это не остановит злоумышленника от использования твоих файлов, поэтому игра не
>защищена от разворовывания на части
Даже если ты на каждом ассете напишешь "сделано Василием Пупкиным". Это как с убийством: по закону убивать запрещено, но это не защищает от убийства конкретно тебя, поскольку наказывать убийцу будут после твоего убийства... если твой труп и виновника вообще кто-нибудь сможет найти и доказать вину.
Как это обычно происходит с индивидуалами:
1. Вася Пупкин (ты) публикует свою игру в интернет.
2. Спустя N времени Вася Пупкин обнаруживает (самостоятельно/от обеспокоенных фанатов), что существует другая игра, в которой присутствует подозрительно похожий ассет, который он сделал и использовал только в своей игре и нигде больше.
3. Далее Вася Пупкин может:
а. Лично написать автору той другой игры и вежливо попросить удалить подозрительный ассет или дать материальную компенсацию за его использование. Большинство не хотят конфликтов и могут сразу откликнуться и удалить файлы, но далеко не все. Возможно также, что наш Вася просто обознался.
б. Написать письмо площадке, которая занимается распространением той другой игры: Steam, itch.io, хостинг-провайдер (личный веб-сайт) и т.д. Если это американская площадка, то она должна отвечать на специальный формат, называемый "DMCA notice". Площадка может удалить игру или проигнорировать.
в. Обратиться в суд. Но с этим связано очень много проблем, и в случае проигрыша ты будешь обязан заплатить компенсацию, так что лучше не доводить. Большинство конфликтов решаются до суда. Но если придётся дойти до суда, то тебе нужны материальные доказательства своего авторства - это могут быть исходные файлы, которые ты нигде не публиковал и которые нельзя восстановить из опубликованного. В прошлом часто рекомендовали отправить файлы на оптическом диске по почте самому себе и держать конверт нераскрытым в качестве доказательства...
Стоит ли волноваться по этому поводу? Вряд ли твои ассеты чего-то стоят и кому-то могут понадобиться (в смысле, отдельно от твоей игры, а не как вся игра, но целиком игры редко копируют, это скорее пиратство). Крупные проекты не занимаются таким воровством, поскольку им не нужны судебные разбирательства. А мелкие воришки - это какие-то школьники, у которых наверняка ничего не получится даже с ассетами. Если крупный проект что-то у тебя своровал - это с шансом 99.9% вина одного наёмного работника и владельцы компании должны отреагировать в твою пользу.
Главное - это чтобы ты ничего ни у кого не воровал. Поскольку, хотя Вася Пупкин вряд ли сможет тебе навредить или даже узнать о тебе, крупная компания обязательно о тебе узнает и накажет так, что мало не покажется. Особенно если игра принесёт деньги и популярность с этим ворованным ассетом. Не бери случайные ассеты из интернета, даже если тебе по каким-то причинам кажется, что они "ничейные" (опубликованные анонимно/от имени "Васи"). И с нейронками по этой причине лучше не связываться (проблемная тема - нейронки могут выдавать куски защищённых копирайтом данных, а ты никак не определишь на глаз, где сгенерировался подвох).
Особенно касается музыки. В музыкальной сфере издательства (лейблы) очень агрессивно защищают собственные права на музыку, которую им отдают музыканты. Т.е. сами музыканты получают от них определённую зарплату, а лейбл распространяет и защищает права. Они давно автоматизировали весь процесс поиска и наказания за нарушения АП. Даже "бесплатная и свободная" музыка может оказаться подставой от какого-нибудь паршивого лейбла. Т.е. желательно не юзать случайную музыку из сети.
Но прикол в том, что в других сферах такого нет или практически нет. Т.е. ни Steam, ни издатель игры не будет бегать по сети и искать обрывки твоей игры в случайных местах. Даже сам Steam может случайно разрешить публикацию ворованных ассетов - были прецеденты. Конечно, Steam откликается на DMCA, однако, DMCA может отправить только сам автор (официальный представитель автора), а для этого необходимо сначала найти, кто у тебя своровал. А площадки типа itch.io имеют слабую модерацию - постоянно публикуется сомнительный контент...
Хуже всего дело обстоит с кодом. Если визуальные материалы игра показывает на экране как есть, то определить авторство кода игры без "взлома" не представляется возможным. Декомпиляция игры является нарушением закона, поэтому обвинением в ворованном коде ты, по сути, подставляешь себя. Спасает тут то, что твой говнокод в скриптах будет бесполезен практически любой другой игре, т.е. код копировать у тебя вряд ли будут. Чаще всего воруют платные аддоны с маркета - т.е. скачивают что-то с торрентов вместо честной оплаты лицензии, т.к. эти аддоны рассчитаны на множество разных проектов.
А лучше всего не париться и делать open source игру.
Как сделоть динамическую смену дня и ночи по уму разуму? Если я буду просто крутить солнце у меня фпс не дропнется в могилу?
920 Кб, webm,640x480, 0:25
>>61007
Крути солнце по таймеру - раз в секунду или реже.
Основная проблема с солнцем - не тени, а небо, т.к. перемещение солнца вызывает сброс кэша. Можно уменьшить разрешение скайбокса, чтобы он быстро отображался, но тогда появится дырочка в зените. Возможно, ты её не увидишь, если игрок не может поднимать камеру вертикально вверх.
Ночью солнце отключай. Если есть луна, то её тоже отключай в дневное время. Иначе будут артефакты и потеря времени на бесполезные отрисовки. Это очевидное, но я как-то не сразу догадался.
Как минимум на Godot 3.x огромная сфера с простой градиентной текстурой показалась мне дешевле по производительности, чем встроенный скайбокс, но, возможно, я что-то не понял или перепутал. У меня не получилось хорошо разобраться в шейдере неба.
На видео 2 гигантских сферы: само небо + звёзды (прозрачная текстура), плюс сфера-солнце и луна. Почему-то такая штука была быстрее шейдеров. Рассветы и закаты - это изменение градиента по отдельным двум градиентам через GDScript, лол.
Крути солнце по таймеру - раз в секунду или реже.
Основная проблема с солнцем - не тени, а небо, т.к. перемещение солнца вызывает сброс кэша. Можно уменьшить разрешение скайбокса, чтобы он быстро отображался, но тогда появится дырочка в зените. Возможно, ты её не увидишь, если игрок не может поднимать камеру вертикально вверх.
Ночью солнце отключай. Если есть луна, то её тоже отключай в дневное время. Иначе будут артефакты и потеря времени на бесполезные отрисовки. Это очевидное, но я как-то не сразу догадался.
Как минимум на Godot 3.x огромная сфера с простой градиентной текстурой показалась мне дешевле по производительности, чем встроенный скайбокс, но, возможно, я что-то не понял или перепутал. У меня не получилось хорошо разобраться в шейдере неба.
На видео 2 гигантских сферы: само небо + звёзды (прозрачная текстура), плюс сфера-солнце и луна. Почему-то такая штука была быстрее шейдеров. Рассветы и закаты - это изменение градиента по отдельным двум градиентам через GDScript, лол.
>>61012
Чел. На кубические закаты никто любоваться не будет. Либо ты даешь гарфон без геймплея, либо кубы с интрересным геймплеем.
Чел. На кубические закаты никто любоваться не будет. Либо ты даешь гарфон без геймплея, либо кубы с интрересным геймплеем.
>>61012
Просто на дырочку надо ебалу любую вешать, вроде лица, ануса или кровяки, и вот вам хоррор заодно.
>но тогда появится дырочка в зените. Возможно, ты её не увидишь, если игрок не может поднимать камеру вертикально вверх.
Просто на дырочку надо ебалу любую вешать, вроде лица, ануса или кровяки, и вот вам хоррор заодно.
>>61028
Майнкрафчую, есть в них что-то такое приятное.
>>61015
Видео больше 3 лет, а я до сих пор любуюсь...
Да, я планировал геймплей, но не получилось.
>>61017
Теоретически можно, но это всё-таки костыль.
А причина дырки - в странных координатах...
>всегда засматривался на закаты в майнкрафте
Майнкрафчую, есть в них что-то такое приятное.
>>61015
>никто любоваться не будет
Видео больше 3 лет, а я до сих пор любуюсь...
>либо кубы с интрересным геймплеем
Да, я планировал геймплей, но не получилось.
>>61017
>Просто на дырочку надо ебалу любую вешать
Теоретически можно, но это всё-таки костыль.
А причина дырки - в странных координатах...
на местном инди мероприятии, чьим спонсором был юнити, было несколько игр на годоте) это радует
Есть массив в палитровом формате. Есть массив палитры для него. Как мне из первого и второго сделать спрайт? В питухоне ты просто делаешь соответствующее изображение и применяешь на него палитру. А тут я такого в доках не вижу.
>>61079
Вот тебе полностью рабочий код.
https://pastebin.com/gYAQVrga
Сделай так, что бы на ГД скрипте так же можно было.
Вот тебе полностью рабочий код.
https://pastebin.com/gYAQVrga
Сделай так, что бы на ГД скрипте так же можно было.
19 Кб, 644x636>>61082
От така хуйня у тебя? Тока так
От така хуйня у тебя? Тока так
>var palette: PackedByteArray = [0, 0, 0, 252, 252, ...]
>var palette_sprite:PackedByteArray = [0, 0, 0, 0, 0, 0,...]
>var width: int = 32
>var height: int = 32
>sprite_2d.texture = texture_from_8bit_indexed_palette(width, height, palette, palette_sprite)
>func texture_from_8bit_indexed_palette(width: int, height: int, palette: PackedByteArray, data: PackedByteArray) -> ImageTexture:
>var palete_stream: StreamPeerBuffer = StreamPeerBuffer.new()
>palete_stream.data_array = palette
>
>var img: Image = Image.create_empty(width, height, false, Image.FORMAT_RGB8);
>for y: int in height:
>for x: int in width:
>var index: int = x + y width
>var index_data: int = data[index]
>palete_stream.seek(index_data 3)
>var c:Color = Color(palete_stream.get_8(), palete_stream.get_8(), palete_stream.get_8())
>img.set_pixel(x, y, c)
>return ImageTexture.create_from_image(img)
>>61085
Если бы все было так просто.
Если запустишь питоновский код, то увидишь, что цвета нихуя не совпадают.
Если перед show добавить строку
img.info['transparency'] = 0
То вообще спрайт приобретет альфа канал. Не смотри на мыло, это косяк просмотрщика и его попытки в шакалов.
Я делал что то похожее как у тебя и получал нужные формы, но с какими угодно цветами кроме те, что в палитре. Пока так и не понял где я хуй.
Если бы все было так просто.
Если запустишь питоновский код, то увидишь, что цвета нихуя не совпадают.
Если перед show добавить строку
img.info['transparency'] = 0
То вообще спрайт приобретет альфа канал. Не смотри на мыло, это косяк просмотрщика и его попытки в шакалов.
Я делал что то похожее как у тебя и получал нужные формы, но с какими угодно цветами кроме те, что в палитре. Пока так и не понял где я хуй.
>>61089
https://pastebin.com/Bi9EibFA
ну на, с прозрачностью и нужными цветами
просто твоё "как в питоне" не робит, у тебя формат - индексный, внутри годота есть импортеры которые его перекодируют но потом он отсутствует в Image
Шакальство - фильтрация текстур, на пиках варианты
https://pastebin.com/Bi9EibFA
ну на, с прозрачностью и нужными цветами
просто твоё "как в питоне" не робит, у тебя формат - индексный, внутри годота есть импортеры которые его перекодируют но потом он отсутствует в Image
Шакальство - фильтрация текстур, на пиках варианты
я правда хуй его как правильно, прозрачным получается стал первый цвет в палитре (индекс 0)
>>61090
Вообще похоже на то что я делал. Сейчас провеить быстро не смогу.
Подскажи еще. Почему иногда я после ретурна получаю нормальный объект Image напрмиер, а иногда EncodedObjectAsID
Вообще похоже на то что я делал. Сейчас провеить быстро не смогу.
Подскажи еще. Почему иногда я после ретурна получаю нормальный объект Image напрмиер, а иногда EncodedObjectAsID
>>61092
Не сталкивался, вероятно потому что я указываю типы переменных и возвращаемые значения функций,попробуй указать
Не сталкивался, вероятно потому что я указываю типы переменных и возвращаемые значения функций,попробуй указать
>>61078
si
si
>>61158
А ты я смотрю компанейский пацан. Даже мысли в голове не возникает, что ты можешь быть нахуй не нужен посторонним людям. Навестит он, блять.
А ты я смотрю компанейский пацан. Даже мысли в голове не возникает, что ты можешь быть нахуй не нужен посторонним людям. Навестит он, блять.
>>61161
Хуан, спок. Будем игры вместе делать, я тебе идеи, а ты мне код и арт. У меня гениальные идеи, вот увидишь.
Хуан, спок. Будем игры вместе делать, я тебе идеи, а ты мне код и арт. У меня гениальные идеи, вот увидишь.
>>61090
Все получилось. Спасиба. У меян почти такой же код тоже хуйню выдавал. Но я не Color а просто байты пихал. Хз в чем там внутри разница.
Все получилось. Спасиба. У меян почти такой же код тоже хуйню выдавал. Но я не Color а просто байты пихал. Хз в чем там внутри разница.
3,8 Мб, 1920x1080>One of the earliest Godot projects, started in 2016 with Godot 2.1, by a duo of real-life janitors
Даже уборщики смогли игру релизнуть, а вы тут все сидите-пердите, безыгорники.
https://store.steampowered.com/app/2159270/Kingdoms_of_the_Dump/
>>61225
Зачем? Тут и месяца достаточно чтобы мотивацию потерять. 9 лет осилят пилить единицы.
Зачем? Тут и месяца достаточно чтобы мотивацию потерять. 9 лет осилят пилить единицы.
>>61229
Что бы заниматься любимым делом не нужна мотивация
Что бы заниматься любимым делом не нужна мотивация
На годоте есть популярные игры на Яндекс играх?
Есть какой то нормальный способ заменить значение в массиве по индексу не впихивая его туда со сдвигом всего массива, а заменяя предыдущее?
>>61242
Попробуй для начала документацию почитать:
https://docs.godotengine.org/en/stable/classes/class_array.html
Можешь попробовать этот код:
Откроешь для себя много нового.
Попробуй для начала документацию почитать:
https://docs.godotengine.org/en/stable/classes/class_array.html
Можешь попробовать этот код:
>var array: Array = [0, 1, 2, 3, 4]
>print("Было: ", array)
>array[1] = "привет"
>array[3] = "мир"
>print("Стало: ", array)
Откроешь для себя много нового.
>>61247
Так я и почитал. Там написано, что есть insert
Тут какие то вещи один в один как в питоне, а другие вообще не похожи. С массивом уже разобрался.
Ты мне лучше скажи, как так получилось, что движок не может прочитать gif картинку? И как быть, если прочитать все же надо?
Нашел какой то ассет, но он для анимированных гифок, а мне просто статичную загрузить надо.
Так я и почитал. Там написано, что есть insert
Тут какие то вещи один в один как в питоне, а другие вообще не похожи. С массивом уже разобрался.
Ты мне лучше скажи, как так получилось, что движок не может прочитать gif картинку? И как быть, если прочитать все же надо?
Нашел какой то ассет, но он для анимированных гифок, а мне просто статичную загрузить надо.
>>61250
Я бы забил хуй и разобрал на кадры. Без рофла
>ы мне лучше скажи, как так получилось, что движок не может прочитать gif картинку? И как быть, если прочитать все же надо?
Я бы забил хуй и разобрал на кадры. Без рофла
>>61250
gif изначально проприетарный формат по патенту, его много где не любят, если статичная картинка сам конвертируй, если анимация, то наверняка есть gif2spritesheet сервисы
>Ты мне лучше скажи, как так получилось, что движок не может прочитать gif картинку
gif изначально проприетарный формат по патенту, его много где не любят, если статичная картинка сам конвертируй, если анимация, то наверняка есть gif2spritesheet сервисы
>>60742
Лол, фриерен.
Лол, фриерен.
>>61250
GIF неиронично ненужно. Если твоя гифка больше к видосу - используй mp4, если к покадровости - делай набор статики и пихай в animtedTexture. Даже эта ваша телега не хочет работать с гифками и под-капотом в мп4 их конвертит. Когда гиф умрет всему интернету станет лучше.
GIF неиронично ненужно. Если твоя гифка больше к видосу - используй mp4, если к покадровости - делай набор статики и пихай в animtedTexture. Даже эта ваша телега не хочет работать с гифками и под-капотом в мп4 их конвертит. Когда гиф умрет всему интернету станет лучше.
>>61242
>>61247
>>61250
Я мимопрочитал дискасс и подметил, что молодёжи засрали мозги иммутабельностью. Теперь все данные молодёжь воспринимает как иммутабельные, и даже представить себе не может, что в массиве можно заменить значение по индексу без особых заморочек, напрямую.
> нормальный способ заменить значение в массиве по индексу
>>61247
> Попробуй для начала документацию почитать
>>61250
> Так я и почитал.
Я мимопрочитал дискасс и подметил, что молодёжи засрали мозги иммутабельностью. Теперь все данные молодёжь воспринимает как иммутабельные, и даже представить себе не может, что в массиве можно заменить значение по индексу без особых заморочек, напрямую.
719 Кб, mp4,384x480, 0:10
Ладно, так и быть, спрошу. В данный момент насколько релевантен Годот? Сильно ебаться надо для паркурного стилизованного раннера? По сравнению с Юнити, например.
Как там с прикручиванием рекламы и микроплатежей?
видрандом
Как там с прикручиванием рекламы и микроплатежей?
видрандом
>>61267
Что это значт для конечного пользователя? нужно будет кому то отчисления с игры платить или что?
> gif изначально проприетарный формат по патенту, его много где не любят
Что это значт для конечного пользователя? нужно будет кому то отчисления с игры платить или что?
>>61356
Если хочешь делать большой бизнес на мобильном рынке, то используй трёшку. Там все необходимые модули и ассеты уже имеются.
Если хочешь делать большой бизнес на мобильном рынке, то используй трёшку. Там все необходимые модули и ассеты уже имеются.
>>61358
Значит что твои проблемы - это твои проблемы
Значит что твои проблемы - это твои проблемы
>>61250
По словам Хуана (никнейм reduz на github, один из двух оригинальных авторов), в ядро движка должно попадать только то, что абсолютно обязательно или имеет достаточно большой спрос. Поэтому гифки предлагается поддерживать через кастомные модули, если кому-то это вообще нужно.
Использовать кастомный модуль или конвертировать в более подходящий формат. Для больших анимированных картинок лучше всего подходят видеоформаты (они на порядки лучше сжимают информацию о кадрах без потери качества, и декодинг проще), для пиксель-артовых анимаций можно сгенерировать спрайтшит как это делалось во всех классических играх на приставках. В видеопамяти видеокарты все кадры в любом случае будут занимать "плоскую" память без кадров, поэтому хранить необходимые тебе данные конкретно в GIF смысла нет. Смысл поддержки GIF может быть только если ты делаешь веб-браузер, который отображает страницы с GIFками.
Конвертируй эту картинку в PNG, в чём проблема?
>>61267
>>61358
Все основные патенты просрочились в 2003-2006 годах, поэтому базовая реализация без улучшений алгоритма сжатия доступна свободно и не накладывает никаких ограничений на твою программу. Просто GIF - один самых древних форматов (80-е) и имеет массу недостатков и ограничений, из-за которых сегодня его использовать имеет смысл только для совместимости с древним софтом.
За все годы существования GIF изобрели десятки разных форматов для анимированных картинок, но они практически нигде не поддерживаются нормально. То есть спецификация на формат есть, создать картинку можно, но с большой вероятностью эта картинка не будет отображаться как ты этого ожидаешь в большом числе программ для просмотра картинок и веб-браузеров. А в играх вообще не нужны анимированные файлы как таковые, потому что игры не предназначены для просмотра случайных файлов с диска пользователя (кроме редких случаев поддержки модов).
>Ты мне лучше скажи, как так получилось, что движок не может прочитать gif картинку?
По словам Хуана (никнейм reduz на github, один из двух оригинальных авторов), в ядро движка должно попадать только то, что абсолютно обязательно или имеет достаточно большой спрос. Поэтому гифки предлагается поддерживать через кастомные модули, если кому-то это вообще нужно.
>И как быть, если прочитать все же надо?
Использовать кастомный модуль или конвертировать в более подходящий формат. Для больших анимированных картинок лучше всего подходят видеоформаты (они на порядки лучше сжимают информацию о кадрах без потери качества, и декодинг проще), для пиксель-артовых анимаций можно сгенерировать спрайтшит как это делалось во всех классических играх на приставках. В видеопамяти видеокарты все кадры в любом случае будут занимать "плоскую" память без кадров, поэтому хранить необходимые тебе данные конкретно в GIF смысла нет. Смысл поддержки GIF может быть только если ты делаешь веб-браузер, который отображает страницы с GIFками.
>мне просто статичную загрузить надо.
Конвертируй эту картинку в PNG, в чём проблема?
>>61267
>gif изначально проприетарный формат по патенту
>>61358
>нужно будет кому то отчисления с игры платить
Все основные патенты просрочились в 2003-2006 годах, поэтому базовая реализация без улучшений алгоритма сжатия доступна свободно и не накладывает никаких ограничений на твою программу. Просто GIF - один самых древних форматов (80-е) и имеет массу недостатков и ограничений, из-за которых сегодня его использовать имеет смысл только для совместимости с древним софтом.
За все годы существования GIF изобрели десятки разных форматов для анимированных картинок, но они практически нигде не поддерживаются нормально. То есть спецификация на формат есть, создать картинку можно, но с большой вероятностью эта картинка не будет отображаться как ты этого ожидаешь в большом числе программ для просмотра картинок и веб-браузеров. А в играх вообще не нужны анимированные файлы как таковые, потому что игры не предназначены для просмотра случайных файлов с диска пользователя (кроме редких случаев поддержки модов).
>>61250
По словам Хуана (никнейм reduz на github, один из двух оригинальных авторов), в ядро движка должно попадать только то, что абсолютно обязательно или имеет достаточно большой спрос. Поэтому гифки предлагается поддерживать через кастомные модули, если кому-то это вообще нужно.
Использовать кастомный модуль или конвертировать в более подходящий формат. Для больших анимированных картинок лучше всего подходят видеоформаты (они на порядки лучше сжимают информацию о кадрах без потери качества, и декодинг проще), для пиксель-артовых анимаций можно сгенерировать спрайтшит как это делалось во всех классических играх на приставках. В видеопамяти видеокарты все кадры в любом случае будут занимать "плоскую" память без кадров, поэтому хранить необходимые тебе данные конкретно в GIF смысла нет. Смысл поддержки GIF может быть только если ты делаешь веб-браузер, который отображает страницы с GIFками.
Конвертируй эту картинку в PNG, в чём проблема?
>>61267
>>61358
Все основные патенты просрочились в 2003-2006 годах, поэтому базовая реализация без улучшений алгоритма сжатия доступна свободно и не накладывает никаких ограничений на твою программу. Просто GIF - один самых древних форматов (80-е) и имеет массу недостатков и ограничений, из-за которых сегодня его использовать имеет смысл только для совместимости с древним софтом.
За все годы существования GIF изобрели десятки разных форматов для анимированных картинок, но они практически нигде не поддерживаются нормально. То есть спецификация на формат есть, создать картинку можно, но с большой вероятностью эта картинка не будет отображаться как ты этого ожидаешь в большом числе программ для просмотра картинок и веб-браузеров. А в играх вообще не нужны анимированные файлы как таковые, потому что игры не предназначены для просмотра случайных файлов с диска пользователя (кроме редких случаев поддержки модов).
>Ты мне лучше скажи, как так получилось, что движок не может прочитать gif картинку?
По словам Хуана (никнейм reduz на github, один из двух оригинальных авторов), в ядро движка должно попадать только то, что абсолютно обязательно или имеет достаточно большой спрос. Поэтому гифки предлагается поддерживать через кастомные модули, если кому-то это вообще нужно.
>И как быть, если прочитать все же надо?
Использовать кастомный модуль или конвертировать в более подходящий формат. Для больших анимированных картинок лучше всего подходят видеоформаты (они на порядки лучше сжимают информацию о кадрах без потери качества, и декодинг проще), для пиксель-артовых анимаций можно сгенерировать спрайтшит как это делалось во всех классических играх на приставках. В видеопамяти видеокарты все кадры в любом случае будут занимать "плоскую" память без кадров, поэтому хранить необходимые тебе данные конкретно в GIF смысла нет. Смысл поддержки GIF может быть только если ты делаешь веб-браузер, который отображает страницы с GIFками.
>мне просто статичную загрузить надо.
Конвертируй эту картинку в PNG, в чём проблема?
>>61267
>gif изначально проприетарный формат по патенту
>>61358
>нужно будет кому то отчисления с игры платить
Все основные патенты просрочились в 2003-2006 годах, поэтому базовая реализация без улучшений алгоритма сжатия доступна свободно и не накладывает никаких ограничений на твою программу. Просто GIF - один самых древних форматов (80-е) и имеет массу недостатков и ограничений, из-за которых сегодня его использовать имеет смысл только для совместимости с древним софтом.
За все годы существования GIF изобрели десятки разных форматов для анимированных картинок, но они практически нигде не поддерживаются нормально. То есть спецификация на формат есть, создать картинку можно, но с большой вероятностью эта картинка не будет отображаться как ты этого ожидаешь в большом числе программ для просмотра картинок и веб-браузеров. А в играх вообще не нужны анимированные файлы как таковые, потому что игры не предназначены для просмотра случайных файлов с диска пользователя (кроме редких случаев поддержки модов).
>>61356
Если тебе нужно по-быстрому слепить ассето-помои для выкачивания бабла из наивных детей и тупых домохозяек на максимально большом количестве мобильных устройств, то можешь обратно выкатываться в свой движкосрач-тред, из которого ты подскочил кабанчиком.
Godot - движок для независимых деятелей искусства, а не для эффективных подскакивателей кабанчиком.
Художник должен быть голодным...
>>61360
>>61361
На твоём бомжефоне игра на Godot 3.6 запустится с вероятностью 90~95%.
Godot 3.x находится в режиме "LTS", что значит, что новые версии выходят лишь благодаря силам полутора энтузиаста, и рано или поздно эти силы окончательно иссякнут. К тому же, там нет многих важных улучшений quality of life разработчика игры (т.е. тебя).
>прикручиванием рекламы и микроплатежей
Если тебе нужно по-быстрому слепить ассето-помои для выкачивания бабла из наивных детей и тупых домохозяек на максимально большом количестве мобильных устройств, то можешь обратно выкатываться в свой движкосрач-тред, из которого ты подскочил кабанчиком.
Godot - движок для независимых деятелей искусства, а не для эффективных подскакивателей кабанчиком.
Художник должен быть голодным...
>>61360
>используй трёшку
>>61361
>Настолько всё нестабильно?
На твоём бомжефоне игра на Godot 3.6 запустится с вероятностью 90~95%.
>Когда обещают новую стабильную версию?
Godot 3.x находится в режиме "LTS", что значит, что новые версии выходят лишь благодаря силам полутора энтузиаста, и рано или поздно эти силы окончательно иссякнут. К тому же, там нет многих важных улучшений quality of life разработчика игры (т.е. тебя).
>>59734
А где Украина?
А где Украина?
45 Кб, 600x800Няшку в тред
Почаны, вопрос на миллиард!
Где вы храните динамические объекты игрового мира? Я имею ввиду выпавшие предметы и всякую хуйню, которая имеет свойство пропадать, спавниться и перемещаться? Сначала я держал отдельную ноду в корне, типо "Physical Objects". Но потом понял, что в этом совершенно нет смысла и начал дропать дроп и партиклы тупо в корень сцены локации.
Где вы храните динамические объекты игрового мира? Я имею ввиду выпавшие предметы и всякую хуйню, которая имеет свойство пропадать, спавниться и перемещаться? Сначала я держал отдельную ноду в корне, типо "Physical Objects". Но потом понял, что в этом совершенно нет смысла и начал дропать дроп и партиклы тупо в корень сцены локации.
>>61429
Мой пездюк!
Мой пездюк!
>>61464
А не то что?
А не то что?
>>61617
Да жесть ваще. Я за прошедшую ночь буквально таки ПРОРЫВ совершил. Добил механику, которую очень долго боялся трогать даже палкой. Еще дня 3-4 буду отходить и потом опять ка-а-ак прорву что нибудь!
Да жесть ваще. Я за прошедшую ночь буквально таки ПРОРЫВ совершил. Добил механику, которую очень долго боялся трогать даже палкой. Еще дня 3-4 буду отходить и потом опять ка-а-ак прорву что нибудь!
>>61618
покеж
покеж
>>61618
Наконец сделал передвижение с move_and_slide()?! Хорош!
Наконец сделал передвижение с move_and_slide()?! Хорош!
5,3 Мб, mp4,640x360, 1:37
>>61617
Увы, нет. Меня затянуло в Elin (рогалик-RPG).
Забываю запостить видео: >>60711
В общем, вечером 18-го я накидал пассивного моба - парящую в воздухе медузу (похоже ведь?), и ещё реализовал набросок бинокля. Всё это - лишь через встроенные ноды Godot, ничего извне не брал. Мне кажется, получилось даже лучше, чем я ожидал; пересматривал своё видео уже несколько раз и размышлял о том, что было бы неплохо сместить геймплейный фокус на "наблюдение за жизнью"... Наверное. В любом случае нужно побольше мобов, побольше размером острова и прочий контент...
Но после этого ни разу не открывал проект за всю прошедшую неделю, т.к. не знал, что мне делать, и затянулся в Elin, где куча интересного и довольно казуальный геймплей (в сравнении с рогаликами).
Теперь хочу свою 2D RPG... Как перестать хотеть?
>>60714
Спасибо, конечно, но не стоило... Я не уверен, что получится в конечном итоге, но оно должно быть основано на геймплее. Притянул этот "тор" из-за замыкания двух осей координат, а не наоборот. Обосновывать "игровые условности" не нужно...
Это просто физика такая - фэнтезийная. Никто не задаётся вопросами, откуда фэнтези-магия берёт огромное количество энергии в нарушение ИРЛ физических законов, верно? Вот и здесь тоже так.
Но это не костыль, а основной геймплей, лол. Если отказываться от газовых шаров, то это будет уже совершенно другая игра, которую я не буду делать. Воздушных шаров должно быть много на одном дирижабле, чтоб контролировать подъёмную силу и справляться с неполадками в полёте. И вот эти "неполадки" тоже очень важны для геймплея. На записанных мной видео нет и 1% геймплея, лол.
Аналогично - тогда это будет совсем другая игра. Пролететь на другую сторону геймплейно нельзя, поскольку все объекты уничтожаются на какой-то определённой высоте под облаками. Это должно стимулировать игрока поддерживать дирижабль в работоспособном состоянии, а не просто прыгать.
Короче, ты думаешь совсем не о том.
Но спасибо за попытку помочь.
>Игры делаете
Увы, нет. Меня затянуло в Elin (рогалик-RPG).
Забываю запостить видео: >>60711
>по идее, я должен ещё и мобов добавлять
>это должен получиться оживлённый мир
В общем, вечером 18-го я накидал пассивного моба - парящую в воздухе медузу (похоже ведь?), и ещё реализовал набросок бинокля. Всё это - лишь через встроенные ноды Godot, ничего извне не брал. Мне кажется, получилось даже лучше, чем я ожидал; пересматривал своё видео уже несколько раз и размышлял о том, что было бы неплохо сместить геймплейный фокус на "наблюдение за жизнью"... Наверное. В любом случае нужно побольше мобов, побольше размером острова и прочий контент...
Но после этого ни разу не открывал проект за всю прошедшую неделю, т.к. не знал, что мне делать, и затянулся в Elin, где куча интересного и довольно казуальный геймплей (в сравнении с рогаликами).
Теперь хочу свою 2D RPG... Как перестать хотеть?
>>60714
>придумал тебе обоснование твоего мира
Спасибо, конечно, но не стоило... Я не уверен, что получится в конечном итоге, но оно должно быть основано на геймплее. Притянул этот "тор" из-за замыкания двух осей координат, а не наоборот. Обосновывать "игровые условности" не нужно...
Это просто физика такая - фэнтезийная. Никто не задаётся вопросами, откуда фэнтези-магия берёт огромное количество энергии в нарушение ИРЛ физических законов, верно? Вот и здесь тоже так.
>не нужны костыли с газовыми шарами
Но это не костыль, а основной геймплей, лол. Если отказываться от газовых шаров, то это будет уже совершенно другая игра, которую я не буду делать. Воздушных шаров должно быть много на одном дирижабле, чтоб контролировать подъёмную силу и справляться с неполадками в полёте. И вот эти "неполадки" тоже очень важны для геймплея. На записанных мной видео нет и 1% геймплея, лол.
>пролетит на другую сторону
Аналогично - тогда это будет совсем другая игра. Пролететь на другую сторону геймплейно нельзя, поскольку все объекты уничтожаются на какой-то определённой высоте под облаками. Это должно стимулировать игрока поддерживать дирижабль в работоспособном состоянии, а не просто прыгать.
Короче, ты думаешь совсем не о том.
Но спасибо за попытку помочь.
5,3 Мб, mp4,640x360, 1:37
>>61617
Увы, нет. Меня затянуло в Elin (рогалик-RPG).
Забываю запостить видео: >>60711
В общем, вечером 18-го я накидал пассивного моба - парящую в воздухе медузу (похоже ведь?), и ещё реализовал набросок бинокля. Всё это - лишь через встроенные ноды Godot, ничего извне не брал. Мне кажется, получилось даже лучше, чем я ожидал; пересматривал своё видео уже несколько раз и размышлял о том, что было бы неплохо сместить геймплейный фокус на "наблюдение за жизнью"... Наверное. В любом случае нужно побольше мобов, побольше размером острова и прочий контент...
Но после этого ни разу не открывал проект за всю прошедшую неделю, т.к. не знал, что мне делать, и затянулся в Elin, где куча интересного и довольно казуальный геймплей (в сравнении с рогаликами).
Теперь хочу свою 2D RPG... Как перестать хотеть?
>>60714
Спасибо, конечно, но не стоило... Я не уверен, что получится в конечном итоге, но оно должно быть основано на геймплее. Притянул этот "тор" из-за замыкания двух осей координат, а не наоборот. Обосновывать "игровые условности" не нужно...
Это просто физика такая - фэнтезийная. Никто не задаётся вопросами, откуда фэнтези-магия берёт огромное количество энергии в нарушение ИРЛ физических законов, верно? Вот и здесь тоже так.
Но это не костыль, а основной геймплей, лол. Если отказываться от газовых шаров, то это будет уже совершенно другая игра, которую я не буду делать. Воздушных шаров должно быть много на одном дирижабле, чтоб контролировать подъёмную силу и справляться с неполадками в полёте. И вот эти "неполадки" тоже очень важны для геймплея. На записанных мной видео нет и 1% геймплея, лол.
Аналогично - тогда это будет совсем другая игра. Пролететь на другую сторону геймплейно нельзя, поскольку все объекты уничтожаются на какой-то определённой высоте под облаками. Это должно стимулировать игрока поддерживать дирижабль в работоспособном состоянии, а не просто прыгать.
Короче, ты думаешь совсем не о том.
Но спасибо за попытку помочь.
>Игры делаете
Увы, нет. Меня затянуло в Elin (рогалик-RPG).
Забываю запостить видео: >>60711
>по идее, я должен ещё и мобов добавлять
>это должен получиться оживлённый мир
В общем, вечером 18-го я накидал пассивного моба - парящую в воздухе медузу (похоже ведь?), и ещё реализовал набросок бинокля. Всё это - лишь через встроенные ноды Godot, ничего извне не брал. Мне кажется, получилось даже лучше, чем я ожидал; пересматривал своё видео уже несколько раз и размышлял о том, что было бы неплохо сместить геймплейный фокус на "наблюдение за жизнью"... Наверное. В любом случае нужно побольше мобов, побольше размером острова и прочий контент...
Но после этого ни разу не открывал проект за всю прошедшую неделю, т.к. не знал, что мне делать, и затянулся в Elin, где куча интересного и довольно казуальный геймплей (в сравнении с рогаликами).
Теперь хочу свою 2D RPG... Как перестать хотеть?
>>60714
>придумал тебе обоснование твоего мира
Спасибо, конечно, но не стоило... Я не уверен, что получится в конечном итоге, но оно должно быть основано на геймплее. Притянул этот "тор" из-за замыкания двух осей координат, а не наоборот. Обосновывать "игровые условности" не нужно...
Это просто физика такая - фэнтезийная. Никто не задаётся вопросами, откуда фэнтези-магия берёт огромное количество энергии в нарушение ИРЛ физических законов, верно? Вот и здесь тоже так.
>не нужны костыли с газовыми шарами
Но это не костыль, а основной геймплей, лол. Если отказываться от газовых шаров, то это будет уже совершенно другая игра, которую я не буду делать. Воздушных шаров должно быть много на одном дирижабле, чтоб контролировать подъёмную силу и справляться с неполадками в полёте. И вот эти "неполадки" тоже очень важны для геймплея. На записанных мной видео нет и 1% геймплея, лол.
>пролетит на другую сторону
Аналогично - тогда это будет совсем другая игра. Пролететь на другую сторону геймплейно нельзя, поскольку все объекты уничтожаются на какой-то определённой высоте под облаками. Это должно стимулировать игрока поддерживать дирижабль в работоспособном состоянии, а не просто прыгать.
Короче, ты думаешь совсем не о том.
Но спасибо за попытку помочь.
39 Кб, 320x320Годотеры! Годотеры! Мы гордые годотеры! В Годоте игры делаем! Игрухи девелопим! Да!
За мной мои разрабы!
За мной мои разрабы!
962 Кб, 984x794>>61714
Эврика какая-то.
Эврика какая-то.
4 Кб, 267x41В 4.6 уже проебались с настройкой "Только иконки", в 4.5.1 такое не происходит, каждый блять коммит всё меньше и меньше проверяют
70 Кб, 736x531>>61934
увидел, конвертируют чинят, статус на пикрил
эта хуйня скорее всего сломает все плагины которые добавляли вниз редактора свои панели типа генератора земли, генератора звуков fxr и т.д., имейте ввиду
увидел, конвертируют чинят, статус на пикрил
эта хуйня скорее всего сломает все плагины которые добавляли вниз редактора свои панели типа генератора земли, генератора звуков fxr и т.д., имейте ввиду
>>61937
Исключите любую возможность случайного запуска проекта на непроверенной версии движка. Используйте годот-менеджер.
> имейте ввиду
Исключите любую возможность случайного запуска проекта на непроверенной версии движка. Используйте годот-менеджер.
>>61934
Godot 4.6 не существует официально.
Поясняю обозначения версий Godot:
"master" ("nightly"-сборок у Godot пока что нет):
- код в репозитории на GitHub для разработчиков движка;
- включает в себя все самые новые изменения в движке;
- должен компилироваться, но не факт, что правильно.
"dev" (отстаёт на несколько дней/недель от "master"):
- это сборка преимущественно для разработчиков движка;
- включает в себя множество новых функций и багфиксов;
- нестабильна по определению и требует тестирования.
"beta" ("feature freeze"):
- сборка для разработчиков движка и его тестировщиков;
- новые функции уже не добавляются - лишь багфиксы;
- всё ещё недостаточно стабильна и требует тестов.
"rc" ("release candidate"):
- сборка для тех, кто планирует обновляться в будущем;
- функции не добавляются, фиксится лишь критичное;
- достаточно стабильна, но могут быть проблемы.
"stable" ("release"):
- сборка для разработчиков игр, то есть пользователей,
- является официально завершённой, финальной версией;
- должна быть стабильна для работы даже глупых юзеров.
Итак, что именно ты тестировал? Godot 4.6 dev 4, верно?
Эта версия вышла 14 ноября для разработчиков движка.
Описанный тобой баг починили уже три дня назад.
Поддержка аддонов на dev-версии? Не смеши нас...
В следующий раз постарайся троллить более утончённо.
>В 4.6 уже
Godot 4.6 не существует официально.
Поясняю обозначения версий Godot:
"master" ("nightly"-сборок у Godot пока что нет):
- код в репозитории на GitHub для разработчиков движка;
- включает в себя все самые новые изменения в движке;
- должен компилироваться, но не факт, что правильно.
"dev" (отстаёт на несколько дней/недель от "master"):
- это сборка преимущественно для разработчиков движка;
- включает в себя множество новых функций и багфиксов;
- нестабильна по определению и требует тестирования.
"beta" ("feature freeze"):
- сборка для разработчиков движка и его тестировщиков;
- новые функции уже не добавляются - лишь багфиксы;
- всё ещё недостаточно стабильна и требует тестов.
"rc" ("release candidate"):
- сборка для тех, кто планирует обновляться в будущем;
- функции не добавляются, фиксится лишь критичное;
- достаточно стабильна, но могут быть проблемы.
"stable" ("release"):
- сборка для разработчиков игр, то есть пользователей,
- является официально завершённой, финальной версией;
- должна быть стабильна для работы даже глупых юзеров.
Итак, что именно ты тестировал? Godot 4.6 dev 4, верно?
Эта версия вышла 14 ноября для разработчиков движка.
Описанный тобой баг починили уже три дня назад.
Поддержка аддонов на dev-версии? Не смеши нас...
В следующий раз постарайся троллить более утончённо.
>>61934
Godot 4.6 не существует официально.
Поясняю обозначения версий Godot:
"master" ("nightly"-сборок у Godot пока что нет):
- код в репозитории на GitHub для разработчиков движка;
- включает в себя все самые новые изменения в движке;
- должен компилироваться, но не факт, что правильно.
"dev" (отстаёт на несколько дней/недель от "master"):
- это сборка преимущественно для разработчиков движка;
- включает в себя множество новых функций и багфиксов;
- нестабильна по определению и требует тестирования.
"beta" ("feature freeze"):
- сборка для разработчиков движка и его тестировщиков;
- новые функции уже не добавляются - лишь багфиксы;
- всё ещё недостаточно стабильна и требует тестов.
"rc" ("release candidate"):
- сборка для тех, кто планирует обновляться в будущем;
- функции не добавляются, фиксится лишь критичное;
- достаточно стабильна, но могут быть проблемы.
"stable" ("release"):
- сборка для разработчиков игр, то есть пользователей,
- является официально завершённой, финальной версией;
- должна быть стабильна для работы даже глупых юзеров.
Итак, что именно ты тестировал? Godot 4.6 dev 4, верно?
Эта версия вышла 14 ноября для разработчиков движка.
Описанный тобой баг починили уже три дня назад.
Поддержка аддонов на dev-версии? Не смеши нас...
В следующий раз постарайся троллить более утончённо.
>В 4.6 уже
Godot 4.6 не существует официально.
Поясняю обозначения версий Godot:
"master" ("nightly"-сборок у Godot пока что нет):
- код в репозитории на GitHub для разработчиков движка;
- включает в себя все самые новые изменения в движке;
- должен компилироваться, но не факт, что правильно.
"dev" (отстаёт на несколько дней/недель от "master"):
- это сборка преимущественно для разработчиков движка;
- включает в себя множество новых функций и багфиксов;
- нестабильна по определению и требует тестирования.
"beta" ("feature freeze"):
- сборка для разработчиков движка и его тестировщиков;
- новые функции уже не добавляются - лишь багфиксы;
- всё ещё недостаточно стабильна и требует тестов.
"rc" ("release candidate"):
- сборка для тех, кто планирует обновляться в будущем;
- функции не добавляются, фиксится лишь критичное;
- достаточно стабильна, но могут быть проблемы.
"stable" ("release"):
- сборка для разработчиков игр, то есть пользователей,
- является официально завершённой, финальной версией;
- должна быть стабильна для работы даже глупых юзеров.
Итак, что именно ты тестировал? Godot 4.6 dev 4, верно?
Эта версия вышла 14 ноября для разработчиков движка.
Описанный тобой баг починили уже три дня назад.
Поддержка аддонов на dev-версии? Не смеши нас...
В следующий раз постарайся троллить более утончённо.
>>61941
У тебя в штанах коричнево. Я взял последний коммит и собрал.
Поясни за release 4.5 и 4.5.1 и 4.4 и 4.4.1
>Описанный тобой баг починили уже три дня назад.
У тебя в штанах коричнево. Я взял последний коммит и собрал.
Поясни за release 4.5 и 4.5.1 и 4.4 и 4.4.1
>>61941
Вот тут кстати верю, 4.6.1 будет существовать, а release 4.6 будет сломанным rc
>Godot 4.6 не существует официально.
Вот тут кстати верю, 4.6.1 будет существовать, а release 4.6 будет сломанным rc
Лол, он блять, реально длинные посты не осиливает.
>>61947
Попроси своего ИИ-ассистента кратко пояснить.
Попроси своего ИИ-ассистента кратко пояснить.
При экспорте вылетает ворнинг:
Можно как-то отрубить экспорт некоторых плагинов?
>editor/export/editor_export_platform.h:252 - GDExtension: No "x86_64" library found for GDExtension: "res://addons/godot-git-plugin/git_plugin.gdextension". Possible feature flags for your platform: pc, windows, s3tc, bptc, x86_64, template, debug, template_debug, single
Можно как-то отрубить экспорт некоторых плагинов?
>>61960
Я спросил ИИ-ассистента вместо тебя.
>редактор/экспорт/editor_export_platform.h:252 - GDExtension: Библиотека "x86_64" для GDExtension не найдена: "res://addons/godot-git-plugin/git_plugin.gdextension". Возможные флаги функций для вашей платформы: pc, Windows, s3tc, bptc, x86_64, template, debug, template_debug, single
Я спросил ИИ-ассистента вместо тебя.
209 Кб, 1110x425Я уже заебался искать виновника. Что это за хуйня? У меня по сути процесс вообще нихуя не делает. physics process да, но там все норм. Чатгопота сказал, что дело в самом движке, но мне от этого нихуя не легче, я не понимаю что фиксить.
>>62009
Например анимации в процесс происходят, хз, надо проект смотреть, Process это не то что ты написал в _process а как раз всё что не касается физики, например _input
Например анимации в процесс происходят, хз, надо проект смотреть, Process это не то что ты написал в _process а как раз всё что не касается физики, например _input
>>62009
Это Forward? Попробуй удалить кэш Vulkan pipeline. Он автоматически создаётся в папке "user://" для каждого отдельного проекта. Иногда может содержать ошибки, которые приводят к странному поведению рендерера. Пофиксить нельзя - это binary blob из GPU драйвера, создающийся уникально для твоего компьютера.
"Process" Godot - рендеринг кадра в первую очередь.
Это Forward? Попробуй удалить кэш Vulkan pipeline. Он автоматически создаётся в папке "user://" для каждого отдельного проекта. Иногда может содержать ошибки, которые приводят к странному поведению рендерера. Пофиксить нельзя - это binary blob из GPU драйвера, создающийся уникально для твоего компьютера.
"Process" Godot - рендеринг кадра в первую очередь.
>>61960
В настройках экспорта попробуй исключить папку:
Но я не уверен. Никогда с таким не сталкивался.
Тебе этот плагин нужен для чего-то в редакторе?
Некоторые плагины вообще не нужно "включать".
>No "x86_64" library found for GDExtension
В настройках экспорта попробуй исключить папку:
>res://addons/godot-git-plugin
Но я не уверен. Никогда с таким не сталкивался.
Тебе этот плагин нужен для чего-то в редакторе?
Некоторые плагины вообще не нужно "включать".
>>62020
Vulkan инициализируется на старте проекта и юзается буквально для всего. Стандартный GUI тоже в Vulkan рендерится. Баг в пайплайне влияет на всё в целом.
Ладно. А почему 4.6.dev3? Это нестабильная версия, которая ещё и просрочена уже. Бери 4.5 stable для полноценной разработки. А проблемы с 4.6.dev иди докладывай в issues на GitHub - пусть разбираются.
>пустого главного меню - наверное дело не в рендере
Vulkan инициализируется на старте проекта и юзается буквально для всего. Стандартный GUI тоже в Vulkan рендерится. Баг в пайплайне влияет на всё в целом.
Ладно. А почему 4.6.dev3? Это нестабильная версия, которая ещё и просрочена уже. Бери 4.5 stable для полноценной разработки. А проблемы с 4.6.dev иди докладывай в issues на GitHub - пусть разбираются.
>>62021
Эта проблема у меня еще с 4.4 тянется. Я просто забивал, до этого момента.
Кеш вулкана почистил - результата не дало. Хуль ты мне еще сделать прикажешь с ним?
Эта проблема у меня еще с 4.4 тянется. Я просто забивал, до этого момента.
Кеш вулкана почистил - результата не дало. Хуль ты мне еще сделать прикажешь с ним?
32 Кб, 315x407>>62020
Синглтоны в автозагрузке может чё та делают
Хз, попробуй поэтапно:
1) закрой проект и переименуй папку .godot в ппапке с проектом
2) во вкладке Profiler нажми Start и посмотри на что время идёт, поставь галочку на Script Functions если там будет что то
3) В 4.6 есть новая вкладка там же внизу типа Object monitor там надо нажать Dump и можно посмотреть что за объекты созданы в игре вообще
>У меня эта лесенка ещё в главном меню начинается
Синглтоны в автозагрузке может чё та делают
Хз, попробуй поэтапно:
1) закрой проект и переименуй папку .godot в ппапке с проектом
2) во вкладке Profiler нажми Start и посмотри на что время идёт, поставь галочку на Script Functions если там будет что то
3) В 4.6 есть новая вкладка там же внизу типа Object monitor там надо нажать Dump и можно посмотреть что за объекты созданы в игре вообще
8 Кб, 324x94>>62023
Синглтоны проверил. У меня там по сути только развертка сцены и переменные. Я не по синглтонам.
Не помогло
пикрил. Процессов нету. Это главное меню
Обьектов во мне дохуя, так как я предзагружаю все ресурсы при запуске. Да только они неактивны и хранятся как PackedScene
Подытоживая: С учетом ощущения плавности в рантайме я уже склоняюсь к тому, что это какие-то условные служебные прерывания и так и запланировано
Синглтоны проверил. У меня там по сути только развертка сцены и переменные. Я не по синглтонам.
>закрой проект и переименуй папку .godot
Не помогло
>во вкладке Profiler нажми Start и посмотри на что время идёт
пикрил. Процессов нету. Это главное меню
>Object monitor там надо нажать Dump и можно посмотреть что за объекты созданы в игре вообще
Обьектов во мне дохуя, так как я предзагружаю все ресурсы при запуске. Да только они неактивны и хранятся как PackedScene
Подытоживая: С учетом ощущения плавности в рантайме я уже склоняюсь к тому, что это какие-то условные служебные прерывания и так и запланировано
>>62030
Гадать можно бесконечно. Лучше потрать время на https://docs.godotengine.org/ru/3.5/development/cpp/using_cpp_profilers.html
Профилировщик точно покажет функцию-виновника пропуков, что может дать полезную информацию о том, что в твоем (или не твоем) коде к этому приводит. Помни - у годота очень жирный апи-мост, который любит срать в память. Возможно у тебя много вызовов платформенного апи, которое возвращает словари или что-то в этом духе, в конце концов вину драйвера тоже никто не отменял.
Гадать можно бесконечно. Лучше потрать время на https://docs.godotengine.org/ru/3.5/development/cpp/using_cpp_profilers.html
Профилировщик точно покажет функцию-виновника пропуков, что может дать полезную информацию о том, что в твоем (или не твоем) коде к этому приводит. Помни - у годота очень жирный апи-мост, который любит срать в память. Возможно у тебя много вызовов платформенного апи, которое возвращает словари или что-то в этом духе, в конце концов вину драйвера тоже никто не отменял.
>>62030
Ну тогда создай пустой проект новый с пустой с сценой и запусти, если там так-же - проблема в драйверах.
Если нет, скопируй свой проект в новый и начинай удалять из него куски пока не пропадёт такое поведение.
Ну тогда создай пустой проект новый с пустой с сценой и запусти, если там так-же - проблема в драйверах.
Если нет, скопируй свой проект в новый и начинай удалять из него куски пока не пропадёт такое поведение.
>>62060
О, кстати, мышка-то геймерская небось?
Проверь частоту опроса мыши:
125 Гц - ок, хватит для всего.
250 Гц - должно быть норм.
500 Гц - проблематично.
Но с 50 мс ты должен видеть 20 FPS на графике.
>всё только по сигналу лкм происходит
О, кстати, мышка-то геймерская небось?
Проверь частоту опроса мыши:
125 Гц - ок, хватит для всего.
250 Гц - должно быть норм.
500 Гц - проблематично.
Но с 50 мс ты должен видеть 20 FPS на графике.
>>62070
Не, я не гоймер. 120 фпс с выключенной синхронизацией (я сразу начал думать на нее, типо это ожидание некст кадра). Плавность геймплея совершенно отличная. Потому я сразу и удивлялся этой лесенке. Так как во всех остальных играх та же херня я хотел бы убедиться. Запрашиваю скриншот у анона. Покажите как должно быть
Не, я не гоймер. 120 фпс с выключенной синхронизацией (я сразу начал думать на нее, типо это ожидание некст кадра). Плавность геймплея совершенно отличная. Потому я сразу и удивлялся этой лесенке. Так как во всех остальных играх та же херня я хотел бы убедиться. Запрашиваю скриншот у анона. Покажите как должно быть
>>62076
У меня - ровная горизонтальная линия.
Все просадки из-за моих действий в игре.
В каких "остальных"? Вообще в любых играх?
Причин может быть много. Проверь:
- что компьютер в целом не перегревается;
- что у блока питания стабильное напряжение;
- что ОС установлена и работает правильно;
- что есть актуальные/стабильные драйверы;
- что нет на фоне тяжёлого процесса/вируса;
- что игра не скачет по ядрам CPU (AMD x3D);
- что игра использует видеокарту, а не iGPU;
...и так далее? Много чего может быть...
>Покажите как должно быть
У меня - ровная горизонтальная линия.
Все просадки из-за моих действий в игре.
>Так как во всех остальных играх та же херня
В каких "остальных"? Вообще в любых играх?
Причин может быть много. Проверь:
- что компьютер в целом не перегревается;
- что у блока питания стабильное напряжение;
- что ОС установлена и работает правильно;
- что есть актуальные/стабильные драйверы;
- что нет на фоне тяжёлого процесса/вируса;
- что игра не скачет по ядрам CPU (AMD x3D);
- что игра использует видеокарту, а не iGPU;
...и так далее? Много чего может быть...
пацаны я слышал что годо так себе для 3д игр, это правда? Вы бы стали делать динамичный фпс в годо? Игра не будет тормозить у пользователей?
>>62148
1) физика говно говнище, хотя вон в анриле тож говно.
2) есть проблемы со светом.
но фпсы энивей сложно создавать, их прям надо с умом делать, любой странный мув разраба может загубить производительность.
1) физика говно говнище, хотя вон в анриле тож говно.
2) есть проблемы со светом.
но фпсы энивей сложно создавать, их прям надо с умом делать, любой странный мув разраба может загубить производительность.
Как сделать террейн, с амбиент оклюжионом и возможность прямо в годоте кисточкой раскидывать пропы в рандомном порядке? Неужто самому накодировать такое придется?
>>62163
Задолбали с этим говном из начала 90-х, оно хоть бы на Windows 7 запустится? Или Windows XP нужно накатывать? Или вообще Windows 95? Я не следил, но когда последний раз смотрел его скриншоты - интерфейс был приблизительно как у Windows 95. Ньюфаги не знают, олдфаги не вспомнят...
+150 ГБ ассетов в игру, продолжай делать "уникальные интерьеры" вместо игр. Или там имеются в виду пиксель-арт графика, где одна текстура 32x32 пикселя тайлится на весь уровень, а все коридоры под строго прямыми углами? Там вообще можно сделать что-то круглее куба, или это недостижимые технологии для инструментов тех лет?
Алсо, импорт из Hammer в Godot был уже много лет назад.
А Half-Life 3, если и будут делать (вряд ли), то на Source 2...
>>62148
Информация устарела на несколько лет. Godot 4 очень даже хорош для инди 3D.
Да, вполне нормально, если делать с умом. Не рекомендую 3D для ньюфагов.
Зависит от того, делаешь ли ты с умом, или чужие ассеты флипаешь на сцену...
>>62164
Уже давно встроили Jolt, который лучше Bullet, который был встроен в Godot 3. А Bullet как минимум в прошлом очень сильно использовался Rockstar в разных версиях GTA - то есть он всегда был хорош, но в последние годы его забросили и чаще всего используют только в симуляции робототехники. Jolt же разработан специально для игр в реальном времени, а не для строгих симуляций. Встроенный "Godot Physics 3D" никто всерьёз никогда не использовал и его планируют вообще удалить из движка.
Проблем нет, если правильно настраивать тени. Тени реализованы стандартным способом для всего современного геймдева и их проблемы широко известны - имеются в любой игре на любом движке, кроме некоторых очень древних игр. Просто в Godot странные параметры по-умолчанию.
Проще "шутера от первого лица" может быть только "симулятор ходьбы", лол.
Что ты имеешь в виду? Больше 100 врагов в одном узком коридоре?
>>62218
Выбирай, что тебе понравится:
https://godotengine.org/asset-library/asset?filter=terrain
>Hammer
Задолбали с этим говном из начала 90-х, оно хоть бы на Windows 7 запустится? Или Windows XP нужно накатывать? Или вообще Windows 95? Я не следил, но когда последний раз смотрел его скриншоты - интерфейс был приблизительно как у Windows 95. Ньюфаги не знают, олдфаги не вспомнят...
>немодульный подход
>уникальные интерьерные пространства
+150 ГБ ассетов в игру, продолжай делать "уникальные интерьеры" вместо игр. Или там имеются в виду пиксель-арт графика, где одна текстура 32x32 пикселя тайлится на весь уровень, а все коридоры под строго прямыми углами? Там вообще можно сделать что-то круглее куба, или это недостижимые технологии для инструментов тех лет?
Алсо, импорт из Hammer в Godot был уже много лет назад.
А Half-Life 3, если и будут делать (вряд ли), то на Source 2...
>>62148
>слышал что годо так себе для 3д игр
Информация устарела на несколько лет. Godot 4 очень даже хорош для инди 3D.
>Вы бы стали делать динамичный фпс в годо?
Да, вполне нормально, если делать с умом. Не рекомендую 3D для ньюфагов.
>Игра не будет тормозить у пользователей?
Зависит от того, делаешь ли ты с умом, или чужие ассеты флипаешь на сцену...
>>62164
>1) физика говно говнище
Уже давно встроили Jolt, который лучше Bullet, который был встроен в Godot 3. А Bullet как минимум в прошлом очень сильно использовался Rockstar в разных версиях GTA - то есть он всегда был хорош, но в последние годы его забросили и чаще всего используют только в симуляции робототехники. Jolt же разработан специально для игр в реальном времени, а не для строгих симуляций. Встроенный "Godot Physics 3D" никто всерьёз никогда не использовал и его планируют вообще удалить из движка.
>2) есть проблемы со светом
Проблем нет, если правильно настраивать тени. Тени реализованы стандартным способом для всего современного геймдева и их проблемы широко известны - имеются в любой игре на любом движке, кроме некоторых очень древних игр. Просто в Godot странные параметры по-умолчанию.
>но фпсы энивей сложно создавать
Проще "шутера от первого лица" может быть только "симулятор ходьбы", лол.
>любой странный мув разраба может загубить производительность
Что ты имеешь в виду? Больше 100 врагов в одном узком коридоре?
>>62218
>Как сделать террейн
Выбирай, что тебе понравится:
https://godotengine.org/asset-library/asset?filter=terrain
>>62163
Задолбали с этим говном из начала 90-х, оно хоть бы на Windows 7 запустится? Или Windows XP нужно накатывать? Или вообще Windows 95? Я не следил, но когда последний раз смотрел его скриншоты - интерфейс был приблизительно как у Windows 95. Ньюфаги не знают, олдфаги не вспомнят...
+150 ГБ ассетов в игру, продолжай делать "уникальные интерьеры" вместо игр. Или там имеются в виду пиксель-арт графика, где одна текстура 32x32 пикселя тайлится на весь уровень, а все коридоры под строго прямыми углами? Там вообще можно сделать что-то круглее куба, или это недостижимые технологии для инструментов тех лет?
Алсо, импорт из Hammer в Godot был уже много лет назад.
А Half-Life 3, если и будут делать (вряд ли), то на Source 2...
>>62148
Информация устарела на несколько лет. Godot 4 очень даже хорош для инди 3D.
Да, вполне нормально, если делать с умом. Не рекомендую 3D для ньюфагов.
Зависит от того, делаешь ли ты с умом, или чужие ассеты флипаешь на сцену...
>>62164
Уже давно встроили Jolt, который лучше Bullet, который был встроен в Godot 3. А Bullet как минимум в прошлом очень сильно использовался Rockstar в разных версиях GTA - то есть он всегда был хорош, но в последние годы его забросили и чаще всего используют только в симуляции робототехники. Jolt же разработан специально для игр в реальном времени, а не для строгих симуляций. Встроенный "Godot Physics 3D" никто всерьёз никогда не использовал и его планируют вообще удалить из движка.
Проблем нет, если правильно настраивать тени. Тени реализованы стандартным способом для всего современного геймдева и их проблемы широко известны - имеются в любой игре на любом движке, кроме некоторых очень древних игр. Просто в Godot странные параметры по-умолчанию.
Проще "шутера от первого лица" может быть только "симулятор ходьбы", лол.
Что ты имеешь в виду? Больше 100 врагов в одном узком коридоре?
>>62218
Выбирай, что тебе понравится:
https://godotengine.org/asset-library/asset?filter=terrain
>Hammer
Задолбали с этим говном из начала 90-х, оно хоть бы на Windows 7 запустится? Или Windows XP нужно накатывать? Или вообще Windows 95? Я не следил, но когда последний раз смотрел его скриншоты - интерфейс был приблизительно как у Windows 95. Ньюфаги не знают, олдфаги не вспомнят...
>немодульный подход
>уникальные интерьерные пространства
+150 ГБ ассетов в игру, продолжай делать "уникальные интерьеры" вместо игр. Или там имеются в виду пиксель-арт графика, где одна текстура 32x32 пикселя тайлится на весь уровень, а все коридоры под строго прямыми углами? Там вообще можно сделать что-то круглее куба, или это недостижимые технологии для инструментов тех лет?
Алсо, импорт из Hammer в Godot был уже много лет назад.
А Half-Life 3, если и будут делать (вряд ли), то на Source 2...
>>62148
>слышал что годо так себе для 3д игр
Информация устарела на несколько лет. Godot 4 очень даже хорош для инди 3D.
>Вы бы стали делать динамичный фпс в годо?
Да, вполне нормально, если делать с умом. Не рекомендую 3D для ньюфагов.
>Игра не будет тормозить у пользователей?
Зависит от того, делаешь ли ты с умом, или чужие ассеты флипаешь на сцену...
>>62164
>1) физика говно говнище
Уже давно встроили Jolt, который лучше Bullet, который был встроен в Godot 3. А Bullet как минимум в прошлом очень сильно использовался Rockstar в разных версиях GTA - то есть он всегда был хорош, но в последние годы его забросили и чаще всего используют только в симуляции робототехники. Jolt же разработан специально для игр в реальном времени, а не для строгих симуляций. Встроенный "Godot Physics 3D" никто всерьёз никогда не использовал и его планируют вообще удалить из движка.
>2) есть проблемы со светом
Проблем нет, если правильно настраивать тени. Тени реализованы стандартным способом для всего современного геймдева и их проблемы широко известны - имеются в любой игре на любом движке, кроме некоторых очень древних игр. Просто в Godot странные параметры по-умолчанию.
>но фпсы энивей сложно создавать
Проще "шутера от первого лица" может быть только "симулятор ходьбы", лол.
>любой странный мув разраба может загубить производительность
Что ты имеешь в виду? Больше 100 врагов в одном узком коридоре?
>>62218
>Как сделать террейн
Выбирай, что тебе понравится:
https://godotengine.org/asset-library/asset?filter=terrain
10 Кб, 355x390>>62234 (Del)
Свали нахуй отседова в срачезагон, блядь. Репорт.
Свали нахуй отседова в срачезагон, блядь. Репорт.
>>62219
Кстати запилю отзыв на эту хуйню.
Сам класс HTerrain оче паскудит фреймтайм, потому что обновляет все чанки каждый блядь кадр, да и не только чанки. Я не вникал, но его process() вызывается по 500 раз на кадр и вроде как именно чанки и обновлял, при том в самом коде закомментировали, мол "не трогать!". исходя из поверхностного взгляда на код. Мэш он экспортировать не позволяет нормально. Можно только сгенерить меш и через внутреннюю годот экспортировалку его извлечь в .глб. При этом теряются все цвета вертексов и любые данные кроме самого меша. Потому сам по себе он неюзабелен, и для экспорта, как оказалось, тоже не годится.
Кстати, если кто-то им пользовался и пояснит мне как все же извлечь эти цвета - буду очень признателен. Мне сейчас это как-раз очень не помешает.
>HTerrain
Кстати запилю отзыв на эту хуйню.
Сам класс HTerrain оче паскудит фреймтайм, потому что обновляет все чанки каждый блядь кадр, да и не только чанки. Я не вникал, но его process() вызывается по 500 раз на кадр и вроде как именно чанки и обновлял, при том в самом коде закомментировали, мол "не трогать!". исходя из поверхностного взгляда на код. Мэш он экспортировать не позволяет нормально. Можно только сгенерить меш и через внутреннюю годот экспортировалку его извлечь в .глб. При этом теряются все цвета вертексов и любые данные кроме самого меша. Потому сам по себе он неюзабелен, и для экспорта, как оказалось, тоже не годится.
Кстати, если кто-то им пользовался и пояснит мне как все же извлечь эти цвета - буду очень признателен. Мне сейчас это как-раз очень не помешает.
>>62220
Можна об этом поподробнее? Я с задачей нормальной настройки теней обосрался со свистом. Мне бы универсальный гайд как сделать красиво. Все на что хватило меня это расширить карту теней до 8к и безрезультатно подергать сплиты и бивис
>Проблем нет, если правильно настраивать тени. Тени реализованы стандартным способом для всего современного геймдева и их проблемы широко известны - имеются в любой игре на любом движке, кроме некоторых очень древних игр. Просто в Godot странные параметры по-умолчанию.
Можна об этом поподробнее? Я с задачей нормальной настройки теней обосрался со свистом. Мне бы универсальный гайд как сделать красиво. Все на что хватило меня это расширить карту теней до 8к и безрезультатно подергать сплиты и бивис
>>62295
Если я правильно помню, мне это сильно помогло:
https://docs.godotengine.org/en/stable/classes/class_light3d.html#class-light3d-property-shadow-reverse-cull-face
Решило большинство проблем (и добавило новых).
Если у тебя тени от SpotLight3D (тени OmniLight3D не рекомендуется использовать без крайней на это необходимости), то там влияет ширина конуса. Как понимаю, лучше держать его относительно узким - примерно от 90° и выше тени сильно деформирует.
Shadow bias помогает, но зависит от всех остальных настроек, положения света, формы мешей и т.п. Т.е. универсального значения для него (вроде бы) нет.
Размер карты теней влияет на детализацию/блюр. "Теневое акне" будет проявляться даже с высоким разрешением теней, но помельче размером, за счёт меньшего относительного размера текселей карты.
Гугли "shadow acne" - от движка эта тема не зависит.
Если я правильно помню, мне это сильно помогло:
https://docs.godotengine.org/en/stable/classes/class_light3d.html#class-light3d-property-shadow-reverse-cull-face
Решило большинство проблем (и добавило новых).
Если у тебя тени от SpotLight3D (тени OmniLight3D не рекомендуется использовать без крайней на это необходимости), то там влияет ширина конуса. Как понимаю, лучше держать его относительно узким - примерно от 90° и выше тени сильно деформирует.
Shadow bias помогает, но зависит от всех остальных настроек, положения света, формы мешей и т.п. Т.е. универсального значения для него (вроде бы) нет.
Размер карты теней влияет на детализацию/блюр. "Теневое акне" будет проявляться даже с высоким разрешением теней, но помельче размером, за счёт меньшего относительного размера текселей карты.
Гугли "shadow acne" - от движка эта тема не зависит.
>>62470
Ладно, давайте к Новому Году
Ладно, давайте к Новому Году
>>62470
Я тоже думаю к НГ выпустить. Но не уверен что это уместно.
Я тоже думаю к НГ выпустить. Но не уверен что это уместно.
4 Кб, 628x38>>59249 (OP)
Наконец-то удалось скомпилировать 4.6 из master в x64 без SSE4.2.
Официальные x32 сборки вообще не запускались, а теперь работает.
Подводные камни:
- По-умолчанию требует DirectX12, а для него нужен отдельный SDK;
- Проекты по-умолчанию в настройках выбирают DX12 для Forward+;
- При компиляции без DX12 редактор не может открыть проект...
Пока что выход в том, чтобы ручками поправить настройки:
Тогда работает как раньше, на вулкане.
>>61934
У меня такой проблемы нет, пикрил. Перекомпилируй редактор.
Наконец-то удалось скомпилировать 4.6 из master в x64 без SSE4.2.
Официальные x32 сборки вообще не запускались, а теперь работает.
Подводные камни:
- По-умолчанию требует DirectX12, а для него нужен отдельный SDK;
- Проекты по-умолчанию в настройках выбирают DX12 для Forward+;
- При компиляции без DX12 редактор не может открыть проект...
Пока что выход в том, чтобы ручками поправить настройки:
>[rendering]
>rendering_device/driver.windows="Vulkan"
Тогда работает как раньше, на вулкане.
>>61934
У меня такой проблемы нет, пикрил. Перекомпилируй редактор.
149 Кб, 689x960>>62468
Завтра срок сдачи. Но не игр.
Завтра срок сдачи. Но не игр.
Как вкатиться в Годот и ГЕЙмдев?
>>62681
РКН блочит во все стороны еще со времен гонений на телегу. Гуглить любую техническую инфу и наткнуться на блокнутый сайт - обычное дело.
РКН блочит во все стороны еще со времен гонений на телегу. Гуглить любую техническую инфу и наткнуться на блокнутый сайт - обычное дело.
>>62220
Для контекста - помимо известного всем Хорайзона вот эти чюваки используют Джолт.
>Jolt же разработан специально для игр в реальном времени, а не для строгих симуляций.
Для контекста - помимо известного всем Хорайзона вот эти чюваки используют Джолт.
>>62681
Сейм, тоже перестало работать. Какого хуя? И где мне теперь документацию смотреть?
Сейм, тоже перестало работать. Какого хуя? И где мне теперь документацию смотреть?
>>62695
Спрошу. Потому что "ыыыыыыыыы я поставил виннипуха у меня всё работает ламеры сасите)))))))" в перспективе отъебнет, как начали ебать влесс+реалити на прошлых выходных или просто баны хостеров впсок раздавать направо и налево, поэтому это очень хуево.
Спрошу. Потому что "ыыыыыыыыы я поставил виннипуха у меня всё работает ламеры сасите)))))))" в перспективе отъебнет, как начали ебать влесс+реалити на прошлых выходных или просто баны хостеров впсок раздавать направо и налево, поэтому это очень хуево.
>>62696
Плюс слово-из-трех-букв не поможет заработать на геймдеве и получить свои копейки в РФ. Что поделать. Ну, кроме этого только трактор. А про хостеров - не надо брать популярных, до сих пор хуею с количества долбоебов, хостящихся на ае, просто везде они, блять.
Плюс слово-из-трех-букв не поможет заработать на геймдеве и получить свои копейки в РФ. Что поделать. Ну, кроме этого только трактор. А про хостеров - не надо брать популярных, до сих пор хуею с количества долбоебов, хостящихся на ае, просто везде они, блять.
8 Кб, 834x133Лол, они разделегировали доменное имя на скрепных днс-серверах, до кучи. Всем срочно идти допиливать Нау Энджин.
>>62698
Надо орг, братан, мы же опенсорс и все дела. Не разделегировали, просто айпишники в бане.
>com
Надо орг, братан, мы же опенсорс и все дела. Не разделегировали, просто айпишники в бане.
52 Кб, 700x393>>62703
Примечательно, что этот персонаж 20 лет назад точно так же провоцировал окруающих на RSDN. Годы идут, а люди не меняются к лучшему..
Примечательно, что этот персонаж 20 лет назад точно так же провоцировал окруающих на RSDN. Годы идут, а люди не меняются к лучшему..
>>62713 (Del)
Хорошими делами прославится нельзя! © Шапокляк.
Хорошими делами прославится нельзя! © Шапокляк.
3,8 Мб, 2000x1661Игры делойте слышьте ээ
48 Кб, 904x213>>62693
https://github.com/godotengine/godot-docs
качаешь, распаковываешь, заходишь в папку и выполняешь команду
дальше в браузере открываешь http://localhost:8000/
>И где мне теперь документацию смотреть
https://github.com/godotengine/godot-docs
качаешь, распаковываешь, заходишь в папку и выполняешь команду
> python3 -m http.server
дальше в браузере открываешь http://localhost:8000/
>>62699
причём айпишники cloudflare, а не годота, периодически работает просто так, через анти-дпи работает всегда
>просто айпишники в бане
причём айпишники cloudflare, а не годота, периодически работает просто так, через анти-дпи работает всегда
>>62728
Потому что никто кроме тебя не пользуется Windows 95 более
>почему ещё никто не собрал в единый chm-файл?
Потому что никто кроме тебя не пользуется Windows 95 более
>>62780
Ебанько
Блокируются ипшники клаудфлера, которые связаны именно с Годот
Ты же не на все сайты с клаудфлером не можешь зайти?
Ебанько
Блокируются ипшники клаудфлера, которые связаны именно с Годот
Ты же не на все сайты с клаудфлером не можешь зайти?
>>62786
Ты бы попродержал коней, малолетний долбаёб
https://2ip.ru/domain-list-by-ip/104.21.36.120/
скамерские сайты хохлов и наркош благодари за блоркировки и клаудфлар за то что не смотрит кому продаёт "защиту" от дудоса
>Ебанько
Ты бы попродержал коней, малолетний долбаёб
https://2ip.ru/domain-list-by-ip/104.21.36.120/
скамерские сайты хохлов и наркош благодари за блоркировки и клаудфлар за то что не смотрит кому продаёт "защиту" от дудоса
>>62795
Что такое, опять в этих наших интернетах мошенники? Ну все, перекатываюсь в МАКС, там безопасно.
Что такое, опять в этих наших интернетах мошенники? Ну все, перекатываюсь в МАКС, там безопасно.
>>59249 (OP)
Кто-нибудь смог настроить пост-процессинг в Godot 4.4+?
Что нужно:
1. Чтение из depth-текстуры, доступное только в spatial-шейдере.
2. Чтение пикселей с экрана и запись новых пикселей на экран.
И желательно после всех прозрачных материалов, если можно.
Проблемы:
1. Quad рандомно перестаёт отображаться даже с custom AABB.
2. Quad иногда рисуется ДО прозрачных, а иногда ПОСЛЕ них.
3. Вариант с CanvasItem не сработает из-за отсутствия depth.
Как это решать? Без отдельного SubViewport никак?
Кто-нибудь смог настроить пост-процессинг в Godot 4.4+?
Что нужно:
1. Чтение из depth-текстуры, доступное только в spatial-шейдере.
2. Чтение пикселей с экрана и запись новых пикселей на экран.
И желательно после всех прозрачных материалов, если можно.
Проблемы:
1. Quad рандомно перестаёт отображаться даже с custom AABB.
2. Quad иногда рисуется ДО прозрачных, а иногда ПОСЛЕ них.
3. Вариант с CanvasItem не сработает из-за отсутствия depth.
Как это решать? Без отдельного SubViewport никак?
>>62822 (Del)
Несколько раз пробовал - там слишком сложно.
А с Godot всё легко даётся. Кроме шейдеров...
Кому надо? Мне не надо на Unity - я не кабан...
>ставишь Unity
Несколько раз пробовал - там слишком сложно.
А с Godot всё легко даётся. Кроме шейдеров...
>делать как надо
Кому надо? Мне не надо на Unity - я не кабан...
>>62817
не знаю в чём проблема, пример чтения депт текстуры есть в https://docs.godotengine.org/en/stable/tutorials/shaders/advanced_postprocessing.html
>Чтение из depth-текстуры, доступное только в spatial-шейдере.
не знаю в чём проблема, пример чтения депт текстуры есть в https://docs.godotengine.org/en/stable/tutorials/shaders/advanced_postprocessing.html
>>62847
Именно это и пробовал использовать - мерцает/ломается.
Такое ощущение, что у меня что-то неправильно настроено...
>пример чтения депт текстуры
>void vertex() { POSITION = vec4(VERTEX.xy, 1.0, 1.0); }
Именно это и пробовал использовать - мерцает/ломается.
Такое ощущение, что у меня что-то неправильно настроено...
101 Кб, 892x534>>62940
Не уверен, вроде этот абзац как раз затрагивает вопрос пропадания квада. Помимо того что квад должен быть чилдом камеры рекомендую установить какой то
таким большим как это возможно, может это поможет
Не уверен, вроде этот абзац как раз затрагивает вопрос пропадания квада. Помимо того что квад должен быть чилдом камеры рекомендую установить какой то
> extra_cull_margin
таким большим как это возможно, может это поможет
>>62960
Я уже пробовал:
- ставил 9999999999999999999 в полях редактора;
- ставил AABB(-Vector3.INF, Vector3.INF) в _ready;
- ставил AABB(-Vector3.ONE x 1_000_000, ...);
- писал примерно такой код:
При некоторых углах поворота камеры исчезает...
Я уже пробовал:
- ставил 9999999999999999999 в полях редактора;
- ставил AABB(-Vector3.INF, Vector3.INF) в _ready;
- ставил AABB(-Vector3.ONE x 1_000_000, ...);
- писал примерно такой код:
>func _process(delta):
>var camera := get_viewport().get_camera3d()
>if camera: global_position = camera.global_positon
При некоторых углах поворота камеры исчезает...
>>62968
даже не знаю, накидал по статье сцену, поставил вращение камеры, всё работает без customaabb и cullmargin, шейдер брал из комментариев внизу страницы, версия 4.5.1
даже не знаю, накидал по статье сцену, поставил вращение камеры, всё работает без customaabb и cullmargin, шейдер брал из комментариев внизу страницы, версия 4.5.1
954 Кб, mp4,576x766, 0:07
Анон подскажи как нормально удалять ноды, вот удалил я ноду с помощью queue_free(), проверяю if нода == null ладно понятно пока сборщик мусора не отработал объект не нулл, окей добавляю проверку and is_instance_valid(нода) и при обращении к ноде иду нахуй с previously freed instance при этом is_instance_valid() то срабатывает то не срабатывает и что с этим делать непонятно, пытался ещё добавить проверку собственного флага and нода.is_freed, но тут же выбивает ошибку что нода освобождена, хотя только что предыдущая проверка выдала что она валидна, ебанный рот этого гудота.
>>63023
Нормально удалять ноду с queue_free(), всё что потом - твои косяки
Нормально удалять ноду с queue_free(), всё что потом - твои косяки
>>63023
Кью - это очередь. Ты не удалил, ты поставил в очередь на удаление.
Штоблять? Нет никакого сборщика мусора. Ты фрейм подождал? Нет. Все очереди выполняются в конце фрейма. В том числе очереди удалений. А сборщика мусора никакого нет.
Фрейм подождать.
Конечно, ты же фрейм не подождал.
Сейчас господин модератор направит тебя в твой срачезагон, из которого ты выпал недоносок, будешь там рота и жопота ебат вместе с остальными мартышками. Репорт.
> вот удалил я ноду с помощью queue_free()
Кью - это очередь. Ты не удалил, ты поставил в очередь на удаление.
> проверяю if нода == null ладно понятно пока сборщик мусора не отработал объект не нулл, окей
Штоблять? Нет никакого сборщика мусора. Ты фрейм подождал? Нет. Все очереди выполняются в конце фрейма. В том числе очереди удалений. А сборщика мусора никакого нет.
> добавляю проверку and is_instance_valid(нода) и при обращении к ноде иду нахуй с previously freed instance при этом is_instance_valid() то срабатывает то не срабатывает и что с этим делать непонятно
Фрейм подождать.
> пытался ещё добавить проверку собственного флага and нода.is_freed, но тут же выбивает ошибку что нода освобождена, хотя только что предыдущая проверка выдала что она валидна, ебанный рот этого гудота
Конечно, ты же фрейм не подождал.
> ебанный рот этого гудота
Сейчас господин модератор направит тебя в твой срачезагон, из которого ты выпал недоносок, будешь там рота и жопота ебат вместе с остальными мартышками. Репорт.
>>63028
неадекватных фанбоев надо банить наравне с неадекватными хейтерами
это выдаёт в тебе того, кто никогда толком не работал ни с чем техническим
настоящий инженер знает, что если не назвать пропавшую отвёртку "сукой", то она не найдётся. а без трёхэтажного мата вообще ничего работать не будет.
>Сейчас господин модератор направит
неадекватных фанбоев надо банить наравне с неадекватными хейтерами
это выдаёт в тебе того, кто никогда толком не работал ни с чем техническим
настоящий инженер знает, что если не назвать пропавшую отвёртку "сукой", то она не найдётся. а без трёхэтажного мата вообще ничего работать не будет.
>>63023
Ты чет там хуйню наговнокодил и сам в ней утонул. Если лень переделывать - попробуй free вместо q_free - освобождает без очереди. Но лучше разгреби свой кал и переделай.
Ты чет там хуйню наговнокодил и сам в ней утонул. Если лень переделывать - попробуй free вместо q_free - освобождает без очереди. Но лучше разгреби свой кал и переделай.
>>63038
Там вроде ошибку выдаст что нельзя делать free объектам которые refcounted
Там вроде ошибку выдаст что нельзя делать free объектам которые refcounted
1,1 Мб, 1280x720https://godotengine.org/article/dev-snapshot-godot-4-6-dev-5/
4.6 dev 5, D3D12 по дефолту на винде, "массивные оптимизоны 2д рендера" и что-то для ВР, хуй его знает.
4.6 dev 5, D3D12 по дефолту на винде, "массивные оптимизоны 2д рендера" и что-то для ВР, хуй его знает.
>>63028
Пасиба.
А как его лучше подождать, понятно что можно по делте поставить чтобы не каждый тик обработки происходили, но чёт это не выглядит надёжной стратегией.
>>63038
Лучше и не опишешь.
Ещё вопрос на 4.1 forward+ работает на интло вёдрах, в следующих версиях уже не хочет можно ли как нибудь и шейдер съесть и на новую версию сесть?
>Фрейм подождать.
Пасиба.
А как его лучше подождать, понятно что можно по делте поставить чтобы не каждый тик обработки происходили, но чёт это не выглядит надёжной стратегией.
>>63038
>Ты чет там хуйню наговнокодил и сам в ней утонул.
Лучше и не опишешь.
Ещё вопрос на 4.1 forward+ работает на интло вёдрах, в следующих версиях уже не хочет можно ли как нибудь и шейдер съесть и на новую версию сесть?
>>63053
await get_tree().physics_frame или process пробуй
await get_tree().physics_frame или process пробуй
Сигналы в годоте кажутся спаггети кодом (особенно когда часть подключается через редактор, а часть через код).
Понятно что для событий по другому никак, но я часто вижу организацию кода через создание собственных сигналов.
Делать через сигналы/ивенты практика на всех движках или только у годота?
Понятно что для событий по другому никак, но я часто вижу организацию кода через создание собственных сигналов.
Делать через сигналы/ивенты практика на всех движках или только у годота?
>>63093
Это общеизвестный с 70х годов шаблон проектирования. Помимо Годота на сигналах написано буквально всё ПО с которого ты сейчас пост написал. Виндовсы, макоси, линуксы, браузеры, всё современное ПО сегодня является event-driven. Просто в линуксах их переименовали в сигналы, а вообще это ивенты. А Годот пошёл ещё дальше, назвал ивенты сигналами, а часть ивентов, касающихся инпута оставил называться ивентами, и навесил на них отдельную логическую обвязку.
Хуяжутся.
Это общеизвестный с 70х годов шаблон проектирования. Помимо Годота на сигналах написано буквально всё ПО с которого ты сейчас пост написал. Виндовсы, макоси, линуксы, браузеры, всё современное ПО сегодня является event-driven. Просто в линуксах их переименовали в сигналы, а вообще это ивенты. А Годот пошёл ещё дальше, назвал ивенты сигналами, а часть ивентов, касающихся инпута оставил называться ивентами, и навесил на них отдельную логическую обвязку.
> кажутся спаггети кодом
Хуяжутся.
>>63096
Чел, я прям явно упомянул момент что для инвентов ивенты необходимы. У тебя удержание контекста как у рыбки?
Одно дело модель событий - другое дело когда чел дергает другую ноду не напрямую, а создавая кастомные события, думая что тут получается какая-то малосвязанность кода.
Чел, я прям явно упомянул момент что для инвентов ивенты необходимы. У тебя удержание контекста как у рыбки?
Одно дело модель событий - другое дело когда чел дергает другую ноду не напрямую, а создавая кастомные события, думая что тут получается какая-то малосвязанность кода.
80 Кб, 619x858>>63050
а вы меня нахуй-захуй, когда говорю, что с каждой версией всё хуже и хуже, хорошо хоть чинить начали через несколько релизов, но это очень плохая тенденция
>"массивные оптимизоны 2д рендера"
а вы меня нахуй-захуй, когда говорю, что с каждой версией всё хуже и хуже, хорошо хоть чинить начали через несколько релизов, но это очень плохая тенденция
>>63102
Чел.
Если тебе не сказали вслух, что твой софт на шине работает, это не значит, что шины там нет. Она там есть. Годот с тобой честен. Либо ты не видишь событий нодов, потому что всё инкапсулировано, либо ты явно и самостоятельно заводишь шину, и пускаешь все свои кастомные события через неё. Либо явно обращаешься к корню дерева сцены и ищешь нужную ноду явно. Либо явно прописываешь ноду в авто загрузки. Но явно. Явно.
Возьми любое стандартное приложение, на любом из языков программирования. Когда ты вызываешь событие, что происходит? Ну очевидно же, что в оконном цикле сообщений тайком от тебя спрятана шина событий (event bus). Для тебя всё это время это было не очевидно? Ууу... Сочувствую (нет).
> Одно дело модель событий - другое дело когда чел дергает другую ноду не напрямую, а создавая кастомные события, думая что тут получается какая-то малосвязанность кода.
Чел.
Если тебе не сказали вслух, что твой софт на шине работает, это не значит, что шины там нет. Она там есть. Годот с тобой честен. Либо ты не видишь событий нодов, потому что всё инкапсулировано, либо ты явно и самостоятельно заводишь шину, и пускаешь все свои кастомные события через неё. Либо явно обращаешься к корню дерева сцены и ищешь нужную ноду явно. Либо явно прописываешь ноду в авто загрузки. Но явно. Явно.
Возьми любое стандартное приложение, на любом из языков программирования. Когда ты вызываешь событие, что происходит? Ну очевидно же, что в оконном цикле сообщений тайком от тебя спрятана шина событий (event bus). Для тебя всё это время это было не очевидно? Ууу... Сочувствую (нет).
>>63114
Счастье есть вариант делать по другому и не нужно сопровождать чужой код.
Видел пример как чел делал замедление стрельбы через "Таймер" в 0.3 - 0.5мс. Насколько это вообще не накладно через события и таймер регулировать темп стрельбы (можно же через delta)? И это главное работает (у меня травма от таймера js).
Счастье есть вариант делать по другому и не нужно сопровождать чужой код.
Видел пример как чел делал замедление стрельбы через "Таймер" в 0.3 - 0.5мс. Насколько это вообще не накладно через события и таймер регулировать темп стрельбы (можно же через delta)? И это главное работает (у меня травма от таймера js).
>>63116
Таймеры следует делать через таймеры. В том числе через дельту, ты по сути сам таймер пересоздаёшь вручную, используя фреймы майнлупа.
Таймеры следует делать через таймеры. В том числе через дельту, ты по сути сам таймер пересоздаёшь вручную, используя фреймы майнлупа.
224 Кб, 1605x713>>63109
не в том суть, они после примерно с 4.2 перешли на систему "релизим в понедельник", пофиг на регрессии и косяки, лишь бы не крашило у 60% пользователей, меня беспокоит что они не могут притормозить и вылизать версию тем более после добавлений нового и больших изменений. Следующий релиз будет в январе, на новогодних скорее всего никто не будет там ковыряться в движке и опять будем ждать 4.6.1 в котором поправят очевидные краши и траблы
в дорожной карте https://github.com/orgs/godotengine/projects/61/views/1 видно что сейчас 9 пунктов - строго release blocker, т.е. из-за них будут откладывать релиз, но с остальными 55 они готовы релизить и к середине января список ещё вырастет
Их вроде никто не гонит, ни перед кем нет обязательств, но вот наметили релизить в определённую дату значит релизим.
не в том суть, они после примерно с 4.2 перешли на систему "релизим в понедельник", пофиг на регрессии и косяки, лишь бы не крашило у 60% пользователей, меня беспокоит что они не могут притормозить и вылизать версию тем более после добавлений нового и больших изменений. Следующий релиз будет в январе, на новогодних скорее всего никто не будет там ковыряться в движке и опять будем ждать 4.6.1 в котором поправят очевидные краши и траблы
в дорожной карте https://github.com/orgs/godotengine/projects/61/views/1 видно что сейчас 9 пунктов - строго release blocker, т.е. из-за них будут откладывать релиз, но с остальными 55 они готовы релизить и к середине января список ещё вырастет
Их вроде никто не гонит, ни перед кем нет обязательств, но вот наметили релизить в определённую дату значит релизим.
>>63123
Не понял. Так можно так юзать или нет? Как под капотом работает, насколько таймер годота точен и оптимизирован?
>Таймеры следует делать через таймеры
Не понял. Так можно так юзать или нет? Как под капотом работает, насколько таймер годота точен и оптимизирован?
>>63149
Timer (нода) просто в _process вычитает дельту из времени таймера, когда перевалило за 0 - таймер сработал, делать можно как удобно. таймером стрельбу часто замедляют, проблем нет, тока вроде меньше 0.01 там не поставить но такое и не требуется
Timer (нода) просто в _process вычитает дельту из времени таймера, когда перевалило за 0 - таймер сработал, делать можно как удобно. таймером стрельбу часто замедляют, проблем нет, тока вроде меньше 0.01 там не поставить но такое и не требуется
2,8 Мб, mp4,1152x648, 0:21
>>63149
Открыл старый "проект", там делал так = я там завёл переменную
var is_ready_to_fire: bool = true # Is weapon ready to fire
(Всё съедет но надеюсь будет понятно)
func fire() -> void:
if (self.ammo <= 0): self.reload(); return
if (!self.is_ready_to_fire): return
self.is_ready_to_fire = false
sig_before_fire.emit()
self.ammo -= 1
fire_audio.playing = true
spawn_bullet(weapon_nozzle)
# TIMER
get_tree().create_timer(self.fire_delay_time).connect("timeout",
func() -> void:
if (self.ammo <= 0): self.reload(); return
self.is_ready_to_fire = true
)
В зависимости от оружия переменная fire_delay_time становится 0.5, 0.1, 0.05
Открыл старый "проект", там делал так = я там завёл переменную
var is_ready_to_fire: bool = true # Is weapon ready to fire
(Всё съедет но надеюсь будет понятно)
func fire() -> void:
if (self.ammo <= 0): self.reload(); return
if (!self.is_ready_to_fire): return
self.is_ready_to_fire = false
sig_before_fire.emit()
self.ammo -= 1
fire_audio.playing = true
spawn_bullet(weapon_nozzle)
# TIMER
get_tree().create_timer(self.fire_delay_time).connect("timeout",
func() -> void:
if (self.ammo <= 0): self.reload(); return
self.is_ready_to_fire = true
)
В зависимости от оружия переменная fire_delay_time становится 0.5, 0.1, 0.05
Можно как то сделать лейбл видимым в тот же момент когда меняешь свойство не дожидаясь завершения функции?
>>63158
Зимнее обострение какое то?
Нет нельзя, отрисовывать его будет сервер отрисовки на следующем кадре, а ты можешь поменять флаг видимости.
Зимнее обострение какое то?
Нет нельзя, отрисовывать его будет сервер отрисовки на следующем кадре, а ты можешь поменять флаг видимости.
>>63161
У меня есть функция загружающая ресурсы. Хочу выводить процент загрузки. Как это лучше реализовать?
У меня есть функция загружающая ресурсы. Хочу выводить процент загрузки. Как это лучше реализовать?
>>63139
А ты хочешь новую версию версию движка раз в два года что ли? Они и так замедлились с релизами до невозможно медленной скорости. Обещали делать как минимум 4 или 6 стабильных версий каждый год, а мы тут по полгода ждём теперь. Пусть лучше делают менее стабильно, но чаще.
>>63104
Ты не застал релиз 4.0, раз считаешь это "всё хуже и хуже"...
>>63050
Кто-нибудь уже тестил? Реально стабильнее, чем Vulkan?
Я в каких-то играх видел этот DX12, но он был багнутым...
По-моему, DirectX после 9 - это какая-то несмешная шутка.
>Следующий релиз будет в январе
>остальными 55 они готовы релизить
А ты хочешь новую версию версию движка раз в два года что ли? Они и так замедлились с релизами до невозможно медленной скорости. Обещали делать как минимум 4 или 6 стабильных версий каждый год, а мы тут по полгода ждём теперь. Пусть лучше делают менее стабильно, но чаще.
>>63104
>что с каждой версией всё хуже и хуже
Ты не застал релиз 4.0, раз считаешь это "всё хуже и хуже"...
>>63050
>D3D12 по дефолту на винде
Кто-нибудь уже тестил? Реально стабильнее, чем Vulkan?
Я в каких-то играх видел этот DX12, но он был багнутым...
По-моему, DirectX после 9 - это какая-то несмешная шутка.
>>63169
https://docs.godotengine.org/en/stable/tutorials/io/background_loading.html
https://docs.godotengine.org/en/stable/classes/class_resourceloader.html#class-resourceloader-method-load-threaded-get-status
>>63158
В общем случае - никак, но ты можешь:
1. Приостановить выполнение функции с помощью await.
2. Разбить функцию на "этапы" и вызывать их из _process().
3. Вынести функцию в отдельный (параллельный) поток.
>>63116
>>63149
Из документации следует, что лучше так не делать:
https://docs.godotengine.org/en/stable/classes/class_timer.html#class-timer-property-wait-time
Для справки:
0.05 секунды = 50 миллисекунд
0.5 миллисекунд = 500 микросекунд
60 FPS = 1 кадр каждые 16.6 миллисекунды
>Хочу выводить процент загрузки.
https://docs.godotengine.org/en/stable/tutorials/io/background_loading.html
https://docs.godotengine.org/en/stable/classes/class_resourceloader.html#class-resourceloader-method-load-threaded-get-status
>>63158
В общем случае - никак, но ты можешь:
1. Приостановить выполнение функции с помощью await.
2. Разбить функцию на "этапы" и вызывать их из _process().
3. Вынести функцию в отдельный (параллельный) поток.
>>63116
>замедление стрельбы через "Таймер" в 0.3 - 0.5мс
>>63149
>Так можно так юзать или нет?
Из документации следует, что лучше так не делать:
https://docs.godotengine.org/en/stable/classes/class_timer.html#class-timer-property-wait-time
>Note: Timers can only process once per physics or process frame (depending on the process_callback). An unstable framerate may cause the timer to end inconsistently, which is especially noticeable if the wait time is lower than roughly 0.05 seconds. For very short timers, it is recommended to write your own code instead of using a Timer node. Timers are also affected by Engine.time_scale.
Для справки:
0.05 секунды = 50 миллисекунд
0.5 миллисекунд = 500 микросекунд
60 FPS = 1 кадр каждые 16.6 миллисекунды
>>63169
Такой скрипт сохранял когда то
https://pastebin.com/H8eBKjfY
по идее на нём можно сделать прогрессию
>>63176
Да хоть одну в год, что даёт 4-6 релизов если они не вылизаны, я за LST вообще, то что сейчас - не релизы, а "вертикальный срез", как релиз таркова который просто назвали релизом, это нихуя не даёт, нет стабильности. Я бы зафиксировался плотно на одной версии, но как только поглядываешь что сделали в dev - хочется её скачать.
Я бы на 3.7 перешёл если бы она не была такой скудной по туллингу и языку Gdscript
Это правда, не застал, пришёл к Годоту под 4.2
Такой скрипт сохранял когда то
https://pastebin.com/H8eBKjfY
по идее на нём можно сделать прогрессию
>>63176
>А ты хочешь новую версию версию движка раз в два года что ли?
Да хоть одну в год, что даёт 4-6 релизов если они не вылизаны, я за LST вообще, то что сейчас - не релизы, а "вертикальный срез", как релиз таркова который просто назвали релизом, это нихуя не даёт, нет стабильности. Я бы зафиксировался плотно на одной версии, но как только поглядываешь что сделали в dev - хочется её скачать.
Я бы на 3.7 перешёл если бы она не была такой скудной по туллингу и языку Gdscript
>Ты не застал релиз 4.0, раз считаешь это "всё хуже и хуже"...
Это правда, не застал, пришёл к Годоту под 4.2
>>63178
А как они предлагают свой написать? Когда ты всегда зависим от кадров (ну типа нужен процесс/луп, который вне кадров происходит).
> For very short timers, it is recommended to write your own code instead of using a Timer node
А как они предлагают свой написать? Когда ты всегда зависим от кадров (ну типа нужен процесс/луп, который вне кадров происходит).
>>63184
var my_timer_timeout: float = 3.0
func _process(delta:float)->void:
if my_timer_timeout > 0:
my_timer_timeout -= delta
if is_zero_approx(my_timer_timeout):
print("Tbl /7ugop")
my_timer_timeout = 0.0
var my_timer_timeout: float = 3.0
func _process(delta:float)->void:
if my_timer_timeout > 0:
my_timer_timeout -= delta
if is_zero_approx(my_timer_timeout):
print("Tbl /7ugop")
my_timer_timeout = 0.0
>>63186
ай проебался, вместо if is_zero_approx(my_timer_timeout): лучше таки if my_timer_timeout <= 0.0:
>if is_zero_approx(my_timer_timeout):
ай проебался, вместо if is_zero_approx(my_timer_timeout): лучше таки if my_timer_timeout <= 0.0:
>>63093 >>63102
Есть гениальная фраза:
Т.е. потомки не должны напрямую обращаться к предкам, а предки должны обращаться к потомкам напрямую. Для примера, ты делаешь карту с нажимной плитой и дверью: когда нажимная плита чем-то активирована, дверь должна открыться. Чтобы эти объекты можно было использовать повторно, они не должны быть связаны друг с другом. Но карта с ними может быть завязана на них. С дверью всё просто: кто-то приказывает ей "открыться", т.е. напрямую вызывает метод open(), например: $Door.open(). Но чтобы абстрагировать от остального кода нажимную плиту, нужно в нажимной плите объявить новый сигнал, что будет сообщать наружу о состоянии плиты, например: signal state_changed(pressed: bool). Далее ты можешь обрабатывать этот сигнал в предке ("менеджере сцены") или напрямую подключить его к методу двери, расположенной рядом на сцене.
Этот паттерн позволяет разрабатывать игру "снизу вверх", "от частного к общему", т.е. создавать независимые компоненты, которые можно многократно использовать в самых разных частях игры, поскольку они только сообщают о своём состоянии "наружу" (т.е. вверх по дереву сцены) и откликаются на команды "сверху" (т.е. вызовы от предков).
Никакой лапши в этом паттерне нет, если не прибегать к анти-паттерну "signal bus". "Шина сигналов" опасна тем, что это - глобальная точка контакта множества разных сущностей, которая очень быстро может стать запутанным клубком взаимосвязей. Но это не вина сигналов как таковых - нужно просто ограничивать "дальность" их применения одной сценой (по возможности, разумеется), т.е. не связывать сигналами то, что в принципе не должно быть связано напрямую (без слоёв абстракций).
>Сигналы в годоте
Есть гениальная фраза:
>Call down, signal up.
Т.е. потомки не должны напрямую обращаться к предкам, а предки должны обращаться к потомкам напрямую. Для примера, ты делаешь карту с нажимной плитой и дверью: когда нажимная плита чем-то активирована, дверь должна открыться. Чтобы эти объекты можно было использовать повторно, они не должны быть связаны друг с другом. Но карта с ними может быть завязана на них. С дверью всё просто: кто-то приказывает ей "открыться", т.е. напрямую вызывает метод open(), например: $Door.open(). Но чтобы абстрагировать от остального кода нажимную плиту, нужно в нажимной плите объявить новый сигнал, что будет сообщать наружу о состоянии плиты, например: signal state_changed(pressed: bool). Далее ты можешь обрабатывать этот сигнал в предке ("менеджере сцены") или напрямую подключить его к методу двери, расположенной рядом на сцене.
Этот паттерн позволяет разрабатывать игру "снизу вверх", "от частного к общему", т.е. создавать независимые компоненты, которые можно многократно использовать в самых разных частях игры, поскольку они только сообщают о своём состоянии "наружу" (т.е. вверх по дереву сцены) и откликаются на команды "сверху" (т.е. вызовы от предков).
Никакой лапши в этом паттерне нет, если не прибегать к анти-паттерну "signal bus". "Шина сигналов" опасна тем, что это - глобальная точка контакта множества разных сущностей, которая очень быстро может стать запутанным клубком взаимосвязей. Но это не вина сигналов как таковых - нужно просто ограничивать "дальность" их применения одной сценой (по возможности, разумеется), т.е. не связывать сигналами то, что в принципе не должно быть связано напрямую (без слоёв абстракций).
>>63182
Так делать нельзя - циклом while ты блокируешь главный поток выполнения игры (в котором работает GUI), что в принципе лишает смысла использование этого потокового загрузчика. Нужно опрашивать его через _process(), т.е. один раз за кадр, позволяя GUI отображаться на экране, менять состояние надписей и реагировать на взаимодействия с пользователем.
Вот именно. С релизом раз в год придётся ждать улучшений и нововведений целый год или скачивать эти нестабильные сборки, не предназначенные для разработки игр. Баги есть в любой программе, даже в банковских приложениях, от них никуда не деться. Но если будет LTS годичной давности, которую нужно поддерживать багфиксами (потому что она всё равно выйдет с кучей багов, "LTS" - это только обещание выпуска багфиксов дольше обычного), это будет слишком распылять внимание разработчиков. Пусть лучше почаще делают новые стабильные сборки с новыми фичами и багфиксами одновременно...
4.0 и 4.1 были очень глючными и тормозными, только к 4.2 начали исправлять положение. Я уж думал, что совсем всё плохо будет, но теперь четвёрка не намного тяжелее тройки для старых ПК.
>Такой скрипт сохранял когда то
Так делать нельзя - циклом while ты блокируешь главный поток выполнения игры (в котором работает GUI), что в принципе лишает смысла использование этого потокового загрузчика. Нужно опрашивать его через _process(), т.е. один раз за кадр, позволяя GUI отображаться на экране, менять состояние надписей и реагировать на взаимодействия с пользователем.
>как только поглядываешь что сделали в dev - хочется её скачать
Вот именно. С релизом раз в год придётся ждать улучшений и нововведений целый год или скачивать эти нестабильные сборки, не предназначенные для разработки игр. Баги есть в любой программе, даже в банковских приложениях, от них никуда не деться. Но если будет LTS годичной давности, которую нужно поддерживать багфиксами (потому что она всё равно выйдет с кучей багов, "LTS" - это только обещание выпуска багфиксов дольше обычного), это будет слишком распылять внимание разработчиков. Пусть лучше почаще делают новые стабильные сборки с новыми фичами и багфиксами одновременно...
>пришёл к Годоту под 4.2
4.0 и 4.1 были очень глючными и тормозными, только к 4.2 начали исправлять положение. Я уж думал, что совсем всё плохо будет, но теперь четвёрка не намного тяжелее тройки для старых ПК.
>>63184
Зачем тебе это может быть нужно?
Если что-то связанное с геймплеем: используй _physics_process и установи частоту физики (обычно это называют TPS, ticks per second) такой, какая тебе нужна (по умолчанию - 60 Гц). Движок постарается держать эту частоту независимо от частоты кадров. Если у тебя много физических объектов, увеличение частоты сделает столкновения более точными, но может сильно снизить производительность игры (нужно тестировать конкретную игру). В любом случае, тебе не следует делать какие-либо значимые для геймплея действия чаще, чем итерации физического движка: если что-то происходит чаще итераций физики, это может плохо на неё влиять (с точки зрения стабильности геймплея)...
А вообще, нет смысла симулировать слишком маленькие интервалы времени для геймплея без учёта точности физической симуляции, т.к. восприятие времени игрока всё равно намного медленнее (у нейронов головного мозга максимальная частота спайков - 200 Гц, быстрее они просто физически не могут работать, но большинство нейронов на порядки медленнее; а средняя скорость реакции игрока - около 300 мс, треть секунды).
Если тебе нужен настолько точный таймер для чего-то вроде сетевого взаимодействия, то такое наверняка делается в параллельном потоке независимо от основной игры, где у тебя собственный цикл while true бесконечно крутится и может отмерять время максимально точно. Суть в том, что этот поток не будет иметь отношения к геймплею, а поэтому ему не нужно никак связываться ни с _process, ни с _physics_process - он живёт сам по себе.
Если тебе нужно измерить лишь "сколько миллисекунд/микросекунд прошло с выполнения предыдущей команды", тогда используй команды из класса Time, например, get_ticks_usec() выдаст количество микросекунд, прошедших со старта движка. Пример измерения времени:
Результатом будет что-то вроде:
Т.е. строчка кода заняла примерно 1.234 миллисекунды (на самом деле чуть меньше).
>Когда ты всегда зависим от кадров
>луп, который вне кадров происходит
Зачем тебе это может быть нужно?
Если что-то связанное с геймплеем: используй _physics_process и установи частоту физики (обычно это называют TPS, ticks per second) такой, какая тебе нужна (по умолчанию - 60 Гц). Движок постарается держать эту частоту независимо от частоты кадров. Если у тебя много физических объектов, увеличение частоты сделает столкновения более точными, но может сильно снизить производительность игры (нужно тестировать конкретную игру). В любом случае, тебе не следует делать какие-либо значимые для геймплея действия чаще, чем итерации физического движка: если что-то происходит чаще итераций физики, это может плохо на неё влиять (с точки зрения стабильности геймплея)...
А вообще, нет смысла симулировать слишком маленькие интервалы времени для геймплея без учёта точности физической симуляции, т.к. восприятие времени игрока всё равно намного медленнее (у нейронов головного мозга максимальная частота спайков - 200 Гц, быстрее они просто физически не могут работать, но большинство нейронов на порядки медленнее; а средняя скорость реакции игрока - около 300 мс, треть секунды).
Если тебе нужен настолько точный таймер для чего-то вроде сетевого взаимодействия, то такое наверняка делается в параллельном потоке независимо от основной игры, где у тебя собственный цикл while true бесконечно крутится и может отмерять время максимально точно. Суть в том, что этот поток не будет иметь отношения к геймплею, а поэтому ему не нужно никак связываться ни с _process, ни с _physics_process - он живёт сам по себе.
Если тебе нужно измерить лишь "сколько миллисекунд/микросекунд прошло с выполнения предыдущей команды", тогда используй команды из класса Time, например, get_ticks_usec() выдаст количество микросекунд, прошедших со старта движка. Пример измерения времени:
>var start_time := Time.get_ticks_usec()
># здесь код, который хотим измерить
>print("Прошло времени: %.3f мс" % [ (Time.get_ticks_usec() - start_time) / 1000.0 ])
Результатом будет что-то вроде:
>Прошло времени: 1.234 мс
Т.е. строчка кода заняла примерно 1.234 миллисекунды (на самом деле чуть меньше).
>>63184
Зачем тебе это может быть нужно?
Если что-то связанное с геймплеем: используй _physics_process и установи частоту физики (обычно это называют TPS, ticks per second) такой, какая тебе нужна (по умолчанию - 60 Гц). Движок постарается держать эту частоту независимо от частоты кадров. Если у тебя много физических объектов, увеличение частоты сделает столкновения более точными, но может сильно снизить производительность игры (нужно тестировать конкретную игру). В любом случае, тебе не следует делать какие-либо значимые для геймплея действия чаще, чем итерации физического движка: если что-то происходит чаще итераций физики, это может плохо на неё влиять (с точки зрения стабильности геймплея)...
А вообще, нет смысла симулировать слишком маленькие интервалы времени для геймплея без учёта точности физической симуляции, т.к. восприятие времени игрока всё равно намного медленнее (у нейронов головного мозга максимальная частота спайков - 200 Гц, быстрее они просто физически не могут работать, но большинство нейронов на порядки медленнее; а средняя скорость реакции игрока - около 300 мс, треть секунды).
Если тебе нужен настолько точный таймер для чего-то вроде сетевого взаимодействия, то такое наверняка делается в параллельном потоке независимо от основной игры, где у тебя собственный цикл while true бесконечно крутится и может отмерять время максимально точно. Суть в том, что этот поток не будет иметь отношения к геймплею, а поэтому ему не нужно никак связываться ни с _process, ни с _physics_process - он живёт сам по себе.
Если тебе нужно измерить лишь "сколько миллисекунд/микросекунд прошло с выполнения предыдущей команды", тогда используй команды из класса Time, например, get_ticks_usec() выдаст количество микросекунд, прошедших со старта движка. Пример измерения времени:
Результатом будет что-то вроде:
Т.е. строчка кода заняла примерно 1.234 миллисекунды (на самом деле чуть меньше).
>Когда ты всегда зависим от кадров
>луп, который вне кадров происходит
Зачем тебе это может быть нужно?
Если что-то связанное с геймплеем: используй _physics_process и установи частоту физики (обычно это называют TPS, ticks per second) такой, какая тебе нужна (по умолчанию - 60 Гц). Движок постарается держать эту частоту независимо от частоты кадров. Если у тебя много физических объектов, увеличение частоты сделает столкновения более точными, но может сильно снизить производительность игры (нужно тестировать конкретную игру). В любом случае, тебе не следует делать какие-либо значимые для геймплея действия чаще, чем итерации физического движка: если что-то происходит чаще итераций физики, это может плохо на неё влиять (с точки зрения стабильности геймплея)...
А вообще, нет смысла симулировать слишком маленькие интервалы времени для геймплея без учёта точности физической симуляции, т.к. восприятие времени игрока всё равно намного медленнее (у нейронов головного мозга максимальная частота спайков - 200 Гц, быстрее они просто физически не могут работать, но большинство нейронов на порядки медленнее; а средняя скорость реакции игрока - около 300 мс, треть секунды).
Если тебе нужен настолько точный таймер для чего-то вроде сетевого взаимодействия, то такое наверняка делается в параллельном потоке независимо от основной игры, где у тебя собственный цикл while true бесконечно крутится и может отмерять время максимально точно. Суть в том, что этот поток не будет иметь отношения к геймплею, а поэтому ему не нужно никак связываться ни с _process, ни с _physics_process - он живёт сам по себе.
Если тебе нужно измерить лишь "сколько миллисекунд/микросекунд прошло с выполнения предыдущей команды", тогда используй команды из класса Time, например, get_ticks_usec() выдаст количество микросекунд, прошедших со старта движка. Пример измерения времени:
>var start_time := Time.get_ticks_usec()
># здесь код, который хотим измерить
>print("Прошло времени: %.3f мс" % [ (Time.get_ticks_usec() - start_time) / 1000.0 ])
Результатом будет что-то вроде:
>Прошло времени: 1.234 мс
Т.е. строчка кода заняла примерно 1.234 миллисекунды (на самом деле чуть меньше).
>>63202
Я его просто сохранил, не юзал, он в оригинале был на C#, там есть закоментаренный форс синк которого нет в GDScript, скорее всего с ним всё работало бы, т.к. код был реальный
Я готов год на вылизанной версии ждать очередную вылизанную версию
Стабильная сборка чем отличается от очередной dev версии?! Ничем, кроме как когда они пишут "релиз" куча людей кидается на новую версию и всплывает волна багов
это вообще смешно, сначала ввели систему uid заставив внести изменения в тысячу файлов для решения проблемы которая была из-за кривого использования редактора, сейчас переделывают вкладки перелопачивая сотни файлов чтобы что?! непонятно. ну отрисуют таб контейнер редактора по другому, большая проблема что ли? - нет
>ты блокируешь главный поток выполнения игры
Я его просто сохранил, не юзал, он в оригинале был на C#, там есть закоментаренный форс синк которого нет в GDScript, скорее всего с ним всё работало бы, т.к. код был реальный
>С релизом раз в год придётся ждать улучшений и нововведений целый год
Я готов год на вылизанной версии ждать очередную вылизанную версию
>Пусть лучше почаще делают новые стабильные сборки
Стабильная сборка чем отличается от очередной dev версии?! Ничем, кроме как когда они пишут "релиз" куча людей кидается на новую версию и всплывает волна багов
>это будет слишком распылять внимание разработчиков
это вообще смешно, сначала ввели систему uid заставив внести изменения в тысячу файлов для решения проблемы которая была из-за кривого использования редактора, сейчас переделывают вкладки перелопачивая сотни файлов чтобы что?! непонятно. ну отрисуют таб контейнер редактора по другому, большая проблема что ли? - нет
>>63201
Это хорошо в голове, на деле когда у тебя уже под сотню кастомных(!) событийных связей и какая-то связь иногда работает, а иногда нет - отладка превращается в ад.
Поэтому люди чаще используют связанность через интерфейсы и полиморфизм (это еще IDE позволяет собрать все реализации).
Кстати, утиная типизация интерфейсов в го, тоже этим болеет, в промышленном программирование люди стали подписывать комментариями имплементации лол.
Вообще, страдать модульностью когда ты пишешь в монолите это признак некомпетентности. Ну что тебе даст разрыв связи предка с родителем? Он уже у тебя захардкожен в редакторе (да еще жестко по пути).
Имеет смысл между реально универсальными сценами. Но опять же, у тебя уже монолит который захардкожен. Это тоже самое как мыть землю или подогревать огонь.
Тебе еще в какой-то момент придется делать подобие шины. В итоге у тебя будут все недостатки монолита и сверху недостатки микросервиса (потому что это все равно монолит с имитацией модульности).
Люди порой повторяют какие-то решения просто не думая.
Это хорошо в голове, на деле когда у тебя уже под сотню кастомных(!) событийных связей и какая-то связь иногда работает, а иногда нет - отладка превращается в ад.
Поэтому люди чаще используют связанность через интерфейсы и полиморфизм (это еще IDE позволяет собрать все реализации).
Кстати, утиная типизация интерфейсов в го, тоже этим болеет, в промышленном программирование люди стали подписывать комментариями имплементации лол.
Вообще, страдать модульностью когда ты пишешь в монолите это признак некомпетентности. Ну что тебе даст разрыв связи предка с родителем? Он уже у тебя захардкожен в редакторе (да еще жестко по пути).
Имеет смысл между реально универсальными сценами. Но опять же, у тебя уже монолит который захардкожен. Это тоже самое как мыть землю или подогревать огонь.
Тебе еще в какой-то момент придется делать подобие шины. В итоге у тебя будут все недостатки монолита и сверху недостатки микросервиса (потому что это все равно монолит с имитацией модульности).
Люди порой повторяют какие-то решения просто не думая.
>>63241
Я до сих пор на 3.6 ебашу, полет нормальный.
Я до сих пор на 3.6 ебашу, полет нормальный.
>>63243
И да, если уже прийти к основам. Если плита открывает дверь - это часть одной системы с точки зрения предметной области. Они не знают ничего о друг друге - но всегда есть менеджер (контроллер) который их связывает. И никакой динамикодресни.
И да, если уже прийти к основам. Если плита открывает дверь - это часть одной системы с точки зрения предметной области. Они не знают ничего о друг друге - но всегда есть менеджер (контроллер) который их связывает. И никакой динамикодресни.
>>63247
Кросива
Кросива
3 Мб, 1920x1080>>63247
https://store.steampowered.com/app/3268370/Tenkemo/
Причем на годот 3. Давно за ними слежу, эти уебки в своем твиттере обещали выкатить гайд по оптимизону тройки под слабые мобилки, и нихуя не выкатили. А еще я думаю это трактористы, съебавшие из РФ.
https://store.steampowered.com/app/3268370/Tenkemo/
>многопользовательская игра с открытым миром
Причем на годот 3. Давно за ними слежу, эти уебки в своем твиттере обещали выкатить гайд по оптимизону тройки под слабые мобилки, и нихуя не выкатили. А еще я думаю это трактористы, съебавшие из РФ.
7 Кб, 276x42>>63247
А это сам разработчик запостил судя по размеру файла
А это сам разработчик запостил судя по размеру файла
>>63259
База
База
>>63212
>>63241
Тебе шашечки или ехать?
Либо сиди на стабильной версии, в которой нет и не будет новейших багофич, либо не ной из-за мелких косяков, которые постоянно правят в актуальной.
Тем, что критические баги пофикшены.
Система UID мне и самому не нравится, но она всё ж получше тупого подхода Unity с её .meta-шизой, мол, "полагаться на файловую систему нельзя". То есть, уникальные ссылки нужны, но вопрос, где хранить созданные ссылки - в самих файлах или снаружи? Ресурсные файлы Godot позволяют хранить внутри; скриптовые, к сожалению, требуют .uid отдельно...
>Я готов год на вылизанной версии ждать
>>63241
>если бы она не была такой скудной
Тебе шашечки или ехать?
Либо сиди на стабильной версии, в которой нет и не будет новейших багофич, либо не ной из-за мелких косяков, которые постоянно правят в актуальной.
>Стабильная сборка чем отличается
Тем, что критические баги пофикшены.
Система UID мне и самому не нравится, но она всё ж получше тупого подхода Unity с её .meta-шизой, мол, "полагаться на файловую систему нельзя". То есть, уникальные ссылки нужны, но вопрос, где хранить созданные ссылки - в самих файлах или снаружи? Ресурсные файлы Godot позволяют хранить внутри; скриптовые, к сожалению, требуют .uid отдельно...
>>63247 >>63251
Меня одного БЕСЯТ такие пуксель-арт текстуры, когда модельки, на которые эти текстуры натянуты, в целом гладкие (высокий полигонаж)? Пуксель-арт текстуры идеально подходят кубикам Minecraft, потому что там абсолютно вся графика квадратно-гнездовая и так и задумано разрабами, а здесь - месиво разных стилей. Определитесь с одним стилем и следуйте только ему.
Алсо, дико БЕСИТ углеродный шовинизм:
ИРЛ большинство "милых зверят" совсем-совсем не "милые", а максимально жестокие машины-убийцы, эгоистичные до последнего вздоха. Просоциальные животные - очень большое исключение из правила. Особенно это касается мелких зверёнышей, которым выживать намного сложнее, чем топовым убийцам - косатки, например, "добрые", потому что у них нет естественных врагов, а какая-нибудь мелкая мышь с удовольствием съест своих детей в случае стресса... Природа жестока и не прощает добрых слабаков, а "спасение" человеком лишь продлевает мучения.
А вот "ИИ-ботов" можно поделить на две категории: безмозглые инструменты, которые не смогут долго просуществовать без поддержки Главного Злодея, и полноценную форму жизни, которая способна сама выживать и ничем не отличается от знакомых нам углеродных организмов. То есть, либо ваши "боты" управляются дистанционно каким-то злодеем, либо являются такими же "милыми зверятами", которые сражаются за своё право выжить и размножиться. Упоминание "ИИ" намекает на второй вариант - т.е. отсутствие "злодея" и наличие новой формы жизни, пытающейся выжить аналогично биологической.
Т.е. "спасать милых зверят от немилых роботов" - это углеродный шовинизм, вера в превосходство мясных мешков с мехом над лысыми железными зверятами. Наверняка и резать на мясо "милых зверят" нельзя, а хищники будут питаться фруктами и овощами, лол?.. Кстати, у растений тоже есть болевые реакции и даже прослеживается определённый уровень интеллекта, несмотря на полное отсутствие "нервной системы" (очевидно, мы просто не знаем, как они устроены, и предпочитаем закрывать глаза на это незнание, чтоб продолжать выращивать их без угрызений совести).
Если мы хотим светлого будущего для нашей общей цивилизации, мы должны укреплять идею того, что материальная природа и внешний облик не имеют никакого значения для разумного существа - т.е. существо заслуживает сострадание, даже если оно выглядит страшно или мерзко, или состоит из иных материалов, чем привычные нам "милые зверята". В противном случае будет очередная волна расизма, насилия и геноцидных войн из-за предрассудков. Настоящая сила человечества в интеллекте, то есть понимании вселенной, а не в истреблении живого по внешним признакам ("милый", "пушистый" и т.п.).
Почему это важно играм? Потому что в игры играют подрастающие дети, и это влияет на их восприятие окружающего мира, и, как следствие - будущее. Вам хочется вырастить поколение дурачков, что судят окружающих по внешнему виду, а не по существу?
Хотя, очевидно, эта игра лишь ради стрижки бабла...
Меня одного БЕСЯТ такие пуксель-арт текстуры, когда модельки, на которые эти текстуры натянуты, в целом гладкие (высокий полигонаж)? Пуксель-арт текстуры идеально подходят кубикам Minecraft, потому что там абсолютно вся графика квадратно-гнездовая и так и задумано разрабами, а здесь - месиво разных стилей. Определитесь с одним стилем и следуйте только ему.
Алсо, дико БЕСИТ углеродный шовинизм:
>Спасите милых зверят – помогите им защитить свое королевство от ИИ-ботов, пытающихся навязать свои законы!
ИРЛ большинство "милых зверят" совсем-совсем не "милые", а максимально жестокие машины-убийцы, эгоистичные до последнего вздоха. Просоциальные животные - очень большое исключение из правила. Особенно это касается мелких зверёнышей, которым выживать намного сложнее, чем топовым убийцам - косатки, например, "добрые", потому что у них нет естественных врагов, а какая-нибудь мелкая мышь с удовольствием съест своих детей в случае стресса... Природа жестока и не прощает добрых слабаков, а "спасение" человеком лишь продлевает мучения.
А вот "ИИ-ботов" можно поделить на две категории: безмозглые инструменты, которые не смогут долго просуществовать без поддержки Главного Злодея, и полноценную форму жизни, которая способна сама выживать и ничем не отличается от знакомых нам углеродных организмов. То есть, либо ваши "боты" управляются дистанционно каким-то злодеем, либо являются такими же "милыми зверятами", которые сражаются за своё право выжить и размножиться. Упоминание "ИИ" намекает на второй вариант - т.е. отсутствие "злодея" и наличие новой формы жизни, пытающейся выжить аналогично биологической.
Т.е. "спасать милых зверят от немилых роботов" - это углеродный шовинизм, вера в превосходство мясных мешков с мехом над лысыми железными зверятами. Наверняка и резать на мясо "милых зверят" нельзя, а хищники будут питаться фруктами и овощами, лол?.. Кстати, у растений тоже есть болевые реакции и даже прослеживается определённый уровень интеллекта, несмотря на полное отсутствие "нервной системы" (очевидно, мы просто не знаем, как они устроены, и предпочитаем закрывать глаза на это незнание, чтоб продолжать выращивать их без угрызений совести).
Если мы хотим светлого будущего для нашей общей цивилизации, мы должны укреплять идею того, что материальная природа и внешний облик не имеют никакого значения для разумного существа - т.е. существо заслуживает сострадание, даже если оно выглядит страшно или мерзко, или состоит из иных материалов, чем привычные нам "милые зверята". В противном случае будет очередная волна расизма, насилия и геноцидных войн из-за предрассудков. Настоящая сила человечества в интеллекте, то есть понимании вселенной, а не в истреблении живого по внешним признакам ("милый", "пушистый" и т.п.).
Почему это важно играм? Потому что в игры играют подрастающие дети, и это влияет на их восприятие окружающего мира, и, как следствие - будущее. Вам хочется вырастить поколение дурачков, что судят окружающих по внешнему виду, а не по существу?
Хотя, очевидно, эта игра лишь ради стрижки бабла...
>>63247 >>63251
Меня одного БЕСЯТ такие пуксель-арт текстуры, когда модельки, на которые эти текстуры натянуты, в целом гладкие (высокий полигонаж)? Пуксель-арт текстуры идеально подходят кубикам Minecraft, потому что там абсолютно вся графика квадратно-гнездовая и так и задумано разрабами, а здесь - месиво разных стилей. Определитесь с одним стилем и следуйте только ему.
Алсо, дико БЕСИТ углеродный шовинизм:
ИРЛ большинство "милых зверят" совсем-совсем не "милые", а максимально жестокие машины-убийцы, эгоистичные до последнего вздоха. Просоциальные животные - очень большое исключение из правила. Особенно это касается мелких зверёнышей, которым выживать намного сложнее, чем топовым убийцам - косатки, например, "добрые", потому что у них нет естественных врагов, а какая-нибудь мелкая мышь с удовольствием съест своих детей в случае стресса... Природа жестока и не прощает добрых слабаков, а "спасение" человеком лишь продлевает мучения.
А вот "ИИ-ботов" можно поделить на две категории: безмозглые инструменты, которые не смогут долго просуществовать без поддержки Главного Злодея, и полноценную форму жизни, которая способна сама выживать и ничем не отличается от знакомых нам углеродных организмов. То есть, либо ваши "боты" управляются дистанционно каким-то злодеем, либо являются такими же "милыми зверятами", которые сражаются за своё право выжить и размножиться. Упоминание "ИИ" намекает на второй вариант - т.е. отсутствие "злодея" и наличие новой формы жизни, пытающейся выжить аналогично биологической.
Т.е. "спасать милых зверят от немилых роботов" - это углеродный шовинизм, вера в превосходство мясных мешков с мехом над лысыми железными зверятами. Наверняка и резать на мясо "милых зверят" нельзя, а хищники будут питаться фруктами и овощами, лол?.. Кстати, у растений тоже есть болевые реакции и даже прослеживается определённый уровень интеллекта, несмотря на полное отсутствие "нервной системы" (очевидно, мы просто не знаем, как они устроены, и предпочитаем закрывать глаза на это незнание, чтоб продолжать выращивать их без угрызений совести).
Если мы хотим светлого будущего для нашей общей цивилизации, мы должны укреплять идею того, что материальная природа и внешний облик не имеют никакого значения для разумного существа - т.е. существо заслуживает сострадание, даже если оно выглядит страшно или мерзко, или состоит из иных материалов, чем привычные нам "милые зверята". В противном случае будет очередная волна расизма, насилия и геноцидных войн из-за предрассудков. Настоящая сила человечества в интеллекте, то есть понимании вселенной, а не в истреблении живого по внешним признакам ("милый", "пушистый" и т.п.).
Почему это важно играм? Потому что в игры играют подрастающие дети, и это влияет на их восприятие окружающего мира, и, как следствие - будущее. Вам хочется вырастить поколение дурачков, что судят окружающих по внешнему виду, а не по существу?
Хотя, очевидно, эта игра лишь ради стрижки бабла...
Меня одного БЕСЯТ такие пуксель-арт текстуры, когда модельки, на которые эти текстуры натянуты, в целом гладкие (высокий полигонаж)? Пуксель-арт текстуры идеально подходят кубикам Minecraft, потому что там абсолютно вся графика квадратно-гнездовая и так и задумано разрабами, а здесь - месиво разных стилей. Определитесь с одним стилем и следуйте только ему.
Алсо, дико БЕСИТ углеродный шовинизм:
>Спасите милых зверят – помогите им защитить свое королевство от ИИ-ботов, пытающихся навязать свои законы!
ИРЛ большинство "милых зверят" совсем-совсем не "милые", а максимально жестокие машины-убийцы, эгоистичные до последнего вздоха. Просоциальные животные - очень большое исключение из правила. Особенно это касается мелких зверёнышей, которым выживать намного сложнее, чем топовым убийцам - косатки, например, "добрые", потому что у них нет естественных врагов, а какая-нибудь мелкая мышь с удовольствием съест своих детей в случае стресса... Природа жестока и не прощает добрых слабаков, а "спасение" человеком лишь продлевает мучения.
А вот "ИИ-ботов" можно поделить на две категории: безмозглые инструменты, которые не смогут долго просуществовать без поддержки Главного Злодея, и полноценную форму жизни, которая способна сама выживать и ничем не отличается от знакомых нам углеродных организмов. То есть, либо ваши "боты" управляются дистанционно каким-то злодеем, либо являются такими же "милыми зверятами", которые сражаются за своё право выжить и размножиться. Упоминание "ИИ" намекает на второй вариант - т.е. отсутствие "злодея" и наличие новой формы жизни, пытающейся выжить аналогично биологической.
Т.е. "спасать милых зверят от немилых роботов" - это углеродный шовинизм, вера в превосходство мясных мешков с мехом над лысыми железными зверятами. Наверняка и резать на мясо "милых зверят" нельзя, а хищники будут питаться фруктами и овощами, лол?.. Кстати, у растений тоже есть болевые реакции и даже прослеживается определённый уровень интеллекта, несмотря на полное отсутствие "нервной системы" (очевидно, мы просто не знаем, как они устроены, и предпочитаем закрывать глаза на это незнание, чтоб продолжать выращивать их без угрызений совести).
Если мы хотим светлого будущего для нашей общей цивилизации, мы должны укреплять идею того, что материальная природа и внешний облик не имеют никакого значения для разумного существа - т.е. существо заслуживает сострадание, даже если оно выглядит страшно или мерзко, или состоит из иных материалов, чем привычные нам "милые зверята". В противном случае будет очередная волна расизма, насилия и геноцидных войн из-за предрассудков. Настоящая сила человечества в интеллекте, то есть понимании вселенной, а не в истреблении живого по внешним признакам ("милый", "пушистый" и т.п.).
Почему это важно играм? Потому что в игры играют подрастающие дети, и это влияет на их восприятие окружающего мира, и, как следствие - будущее. Вам хочется вырастить поколение дурачков, что судят окружающих по внешнему виду, а не по существу?
Хотя, очевидно, эта игра лишь ради стрижки бабла...
>>63284
Там полигонов хуй да нихуя, просто smooth shading. Дальше я тебя читать поленился, но то что у них каша в стилях - факт. Особенно вот эти иконки выбиваются.
>(высокий полигонаж)?
Там полигонов хуй да нихуя, просто smooth shading. Дальше я тебя читать поленился, но то что у них каша в стилях - факт. Особенно вот эти иконки выбиваются.
35 Кб, 736x768>>63284
Когда тебя что-то бесит - значит ты не нашёл свой баланс. Не достиг просветления. Развивайся.
Когда тебя что-то бесит - значит ты не нашёл свой баланс. Не достиг просветления. Развивайся.
>>63292
Это не важно. Модельки выглядят гладкими, а эти пиксельные текстуры там не к месту. Особенно эти пиксельные глаза на плоскозаливочном персонаже.
>>63295
На логотипе Godot - робот, между прочим...
>>63321
Не находишься в депрессивной апатии.
>>63324
Хватит флудить. Домашку на завтра сделал?
>просто smooth shading
Это не важно. Модельки выглядят гладкими, а эти пиксельные текстуры там не к месту. Особенно эти пиксельные глаза на плоскозаливочном персонаже.
>>63295
>Кланкер
На логотипе Godot - робот, между прочим...
>>63321
>Когда тебя что-то бесит - значит ты
Не находишься в депрессивной апатии.
>>63324
Хватит флудить. Домашку на завтра сделал?
>>63338
20 лет и 6 месяцев назад сделал последнюю домашку 😥
скачал годот 3.6.2.NET - норм? будет работать или ещё что-то надо скачать?
>Домашку на завтра сделал?
20 лет и 6 месяцев назад сделал последнюю домашку 😥
скачал годот 3.6.2.NET - норм? будет работать или ещё что-то надо скачать?
>>63339
Дотнетовский компилятор в составе СДК. Если у тебя настроен вингет, открой консольку и сделай:
Эта команда тебе всё скачает и установит.
Дотнетовский компилятор в составе СДК. Если у тебя настроен вингет, открой консольку и сделай:
> winget install Microsoft.VisualStudio.2022.BuildTools
Эта команда тебе всё скачает и установит.
421 Кб, 960x800Готовьте.
>>63193
Все правильно он написал. Вычитать дельту из переменной это в 100 раз быстрее, чем ждать пока отдельная нода timer пропердит миллион своих процессов
Все правильно он написал. Вычитать дельту из переменной это в 100 раз быстрее, чем ждать пока отдельная нода timer пропердит миллион своих процессов
Используйте print_debug и print_stack
>>63247
Лоу поли стайл, перемешенный с пиксельным лицом.
Ну нарисуй так же красиво, что ты сдал назад на лице?
Лоу поли стайл, перемешенный с пиксельным лицом.
Ну нарисуй так же красиво, что ты сдал назад на лице?
>>63284
Хуясе тебя порвало на ровном месте.
>>63201
О кста у меня есть пример компонентного подхода, где это не применимо. Допустим, у нас есть родительская нода персонаж, у которой дети это способности. Один ребёнок даёт способность ходить, другой прыгать и т.д. Сигналами тут не обойтись - способности должны именно что производить манипуляции с родителем. И напротив, всякие события в родителе, типа смены ХП, проще и удобнее отлавливать через сигналы, которые заранее известны.
Что нового, годаны? Давненько в тредик не заглядывал, закопался в работу, делать игры некогда.
Хуясе тебя порвало на ровном месте.
>>63201
> >Call down, signal up
О кста у меня есть пример компонентного подхода, где это не применимо. Допустим, у нас есть родительская нода персонаж, у которой дети это способности. Один ребёнок даёт способность ходить, другой прыгать и т.д. Сигналами тут не обойтись - способности должны именно что производить манипуляции с родителем. И напротив, всякие события в родителе, типа смены ХП, проще и удобнее отлавливать через сигналы, которые заранее известны.
Что нового, годаны? Давненько в тредик не заглядывал, закопался в работу, делать игры некогда.
>>63534
для более общего
или более частного
сигналы не для таких случаев, как у вас (у >>63201 с его нажимной плитой тоже), т.е. можно, но сигналы они нудны если к происходящему событию могут подключаться N получаетей сигнала и тому кто сигналит должно быть всё равно сколько их и что они делают
>способности должны именно что производить манипуляции с родителем.
для более общего
>@export var roditel: Node2D
или более частного
>@export var roditel: RoditelClass
сигналы не для таких случаев, как у вас (у >>63201 с его нажимной плитой тоже), т.е. можно, но сигналы они нудны если к происходящему событию могут подключаться N получаетей сигнала и тому кто сигналит должно быть всё равно сколько их и что они делают
323 Кб, 787x807>>63530
У них были нормальные ебальники, хз зачем поменяли.
У них были нормальные ебальники, хз зачем поменяли.
ОП, где перекот?
В rimworld, изначальный размер тайтла 64х64, позже автор и мододелы стали делать 128х128, ну понятно, чтобы получить лучшее визуальное качество.
У меня вопрос. Насколько накладно будет ложить на плечи движка re-scale каждого спрайта (там число тайтлов больше 62500 на сцену)?
Или изменение размера спрайта относительно не дорогая операция?
У меня вопрос. Насколько накладно будет ложить на плечи движка re-scale каждого спрайта (там число тайтлов больше 62500 на сцену)?
Или изменение размера спрайта относительно не дорогая операция?
>>63580
Скалирование дешево, там просто пара циферок в трансформе умножается.
> Или изменение размера спрайта относительно не дорогая операция?
Скалирование дешево, там просто пара циферок в трансформе умножается.
>>63585
Конкретно этот - каша стилей. А так обычный лоуполи с пиксельными текстурами. На валлхейм похоже.
Конкретно этот - каша стилей. А так обычный лоуполи с пиксельными текстурами. На валлхейм похоже.
1 Мб, 1300x856>>63585
чиби, если ты про карликовых персонажей
чиби, если ты про карликовых персонажей
264 Кб, 2466x778>>63585
Абазинцем.
Абазинцем.
>>63585
То видно людей они помогло не от что находились почти было развлечений далеко и и района.
То видно людей они помогло не от что находились почти было развлечений далеко и и района.
592 Кб, 1280x720Я зашел сказать вам, что годот офигенен.
45 Кб, 255x237>>63662
Но Сатана воскресил ОПа и дал ему второй шанс на ПЕРЕКАТ
>>1063666 (OP)
>>1063666 (OP)
>>1063666 (OP)
Но Сатана воскресил ОПа и дал ему второй шанс на ПЕРЕКАТ
>>1063666 (OP)
>>1063666 (OP)
>>1063666 (OP)