Шапка: https://hipolink.me/godothread
Предыдущий: >>1055144 (OP)
Архивный: >>1051748 (OP)
Берёшь и делаешь, ничего сложного. Хочешь - делаешь сегодня, хочешь - завтра, хочешь - все следующие несколько лет делаешь и делаешь
Потому что ты сделал редактируемые потомки, нахуярил туда изменений, забыл об этом, а сейчас изменяешь исходную сцену, а оно не применяется.
С одной стороны анрил с процедуркой судя по всему точно справится, но я хочу делать игру в стиле лоуполи, а с анрилом это значит сидеть оптимизонить отрубая почти все фичи. А вот в Годоте наоборот для лоуполи судя по всему самое оно, а вот с процедуркой хз.
Если че я опытный разраб, похуй с чем работать, хоть с крестами хоть с гдскриптом, но именно в геймдеве новичок, и уже поделал всякие платформеры и прочие простенькие игры, в том числе 3Д, успел в блендер вкатиться и освоить пусть и не на высоком уровне, но в целом весь пайплайн по созданию 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...
Хотел просто в новую тему потыкать...
>>1059263
>При экспорте не сохраняются изменения
Изменения чего и в чём/где? Экспорт куда и как?
Некоторые типы (json) нужно отдельно указывать.
>>1059264
Такое детектится на этапе теста прям в движке.
Если у него только после экспорта - это другое.
>>1059267
>процедурные анимации с гуманоидами
Вроде несложно. Систему анимаций улучшили.
Некоторые умельцы делали активный регдолл.
Читай документацию про 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...
>Хотел просто в новую тему потыкать...
Это кал подсадный, анончик, а не версия. У меня за сегодня годот вылетел 3 блядь раза. Дважды при присвоении значения экспортной переменной и один раз еще не помню когда. Теперь хз, буду ждать апдейта, так как откатываться я не хочу, я уже передергал все скелеты.
Нет конечно, я же запускаю игру перед экспортом
>>1059268
Есть сцена главного меню, добавляю туда кнопку, делаю экспорт в веб, после запускаю проект (лайв сервером) - изменений нет, кеш в браузере отключен
>после запускаю проект (лайв сервером)
Что? Никогда не слышал о "live server". Это из VSC? Попробуй выключить и включить, лол))) Или, ну, нормальный апач или нгинкс накатить, что ли... Я тестировал веб-билд всего один раз и у меня он чрезвычайно тормозил (Godot 3.x, простое 3D), т.е. обновлять ничего не потребовалось - просто забил.
Также попробуй целиком удалить папку с экспортом, экспортировать заново в новую папку, перезапустить сервер уже ПОСЛЕ экспорта игры в эту новую папку...
>>1059272
>передергал все скелеты
Разве между dev1/dev2 и dev3 скелеты поменяли?
Компьютер старый, давно собираюсь купить что-то посвежее, но чёт мне не нравится, как они делают редактор менее портативным... Что, если моя игра достаточно проста, чтобы работать даже на старых компьютерах? Оставаться на версиях до ≤4.4.1?
>Разве между dev1/dev2 и dev3 скелеты поменяли?
Не знаю. Я с 4.5. Потому пришлось все меши прокликивать назначая им скелет. Не велика задача, но хотелось бы избежать повторного прокликивания, скелетов у меня много
>все меши прокликивать назначая им скелет
Лол. Чейнжлоги читать нужно внимательнее:
>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"... Я раньше даже не замечал это свойство и не понимал, зачем оно там. Кажется, пару раз приходилось нажать "сброс" при перетаскивании нод, да и то - непонятно, почему...
>Что, если моя игра достаточно проста, чтобы работать даже на старых компьютерах? Оставаться на версиях до ≤4.4.1?
Разве в четверке нет compatibility рендера, который как раз рассчитан для работы на тапках? Но это касается именно билда, а не самого редактора.
А так я вообще на тройке до сих пор. Но не из-за компа, а просто доделываю большой проект.
>>1059284
>Кажется, пару раз приходилось нажать "сброс" при перетаскивании нод, да и то - непонятно, почему...
Вроде скелетон авто-заполняется родителем, и сохраняет его при перетаскивании.
> хотелось бы избежать повторного прокликивания
Юзайте годот-менеджер.
Чёткая привязка проект <-> движок.
Никаких сюрпризов. Держишь несколько версий движка под разные проекты. Начав один проект на одной версии можешь контролируемо перейти на новую версию, сделав бэкапы и вовсе скопировав проект в отдельную папку и добавив в менеджер, установить новую версию движка. Так же легко продолжать вести разработку основного проекта на более старой версии, и периодически делать мелкие пет-проекты на новых версиях, чтобы быть в курсе новшеств, быть готовым к ним. Не опасаясь за проекты.
Окно выбора проекта внутри движка так не может, при всём его удобстве, потому что оно не управляет версиями движка бай дизайн. Так что менеджер это мастхэв. Я пользуюсь этим: https://github.com/eumario/godot-manager
Есть и аналоги.
Мне кажется очень медленно, 5 чанков размером 255х255 за 600 миллисекунд и это только деревья поставить. Речь о GDScript'e.
>compatibility рендера
Дело не в рендеринге. В 4.5 принудительно включили специальный флаг, с которым компилятор добавляет инструкции из набора SSE4.2, которые отсутствуют на множестве старых и некоторых новых процессорах. Объясняют это "оптимизацией", но нахрена мне эта оптимизация, если без неё всё работало нормально, а теперь вообще не запускается? Я-то разберусь, как скомпилировать и запустить, а игроки - не будут...
А рендерер багнутый и не такой, как в тройке, т.к. они переписывали его с нуля. Например, на мобилках он неспособен нормально деформировать 2D меши, они просто исчезают при любой анимации. А на 3.x норм.
>>1059288
>менеджер это мастхэв
Нет. Достаточно системных ярлыков/шорткатов. Настраиваешь один раз и забываешь обо всех этих менеджерах навсегда, потому что можешь кликом на рабочем столе открыть проект сразу в редакторе, без промежуточных шагов и посредников. Если захотел обновить версию, просто меняешь индекс в ярлыке.
>>1059295
>процедурную генерацию
Под этим очень многое можно понимать...
>5 чанков размером 255х255
Ты все 325 тысяч клеточек заполняешь?
>600 миллисекунд
Ну, это совсем неплохой результат...
>только деревья поставить
Что значит "поставить"?
- Заполнить ячейку в массиве?
- Переключить ячейку в TileMap?
- Создать новую ноду в дереве?
- Распаковать сцену в дерево?
Это очень разные операции...
>Речь о GDScript'e.
Заполнять массив: на C++ раз в ≈100 быстрее.
Распаковывать сцены в дерево: ≈ без разницы.
Основной способ оптимизации генерации чанков в процедурных играх - раскидать операции на разные отдельные кадры, а то, что нельзя раскидать, но не затрагивает дерево сцены, вынести в независимый параллельный поток. То есть в отдельном потоке генерируются числа в массиве, а потом на каждом отдельном кадре размещается не более чем N нод в дерево сцены согласно числам в массиве. C++ тут существенно ускорит только генерацию массива, поскольку добавление сцен в дерево сцены и так происходит на C++ в недрах движка, но это "дерево сцены" однопоточное и вешает GUI/Input игры, если перегружено работой; а добавление сцен и даже нод затратно, особенно если там твой собственный код с обработчиками событий типа _init, _enter_tree, _ready.
Ещё совет: прежде, чем оптимизировать что-то, изучи встроенный дебаггер. Там есть возможность считать миллисекунды на отдельных функциях GDScript. Либо можешь воспользоваться классом Time и выводить информацию в консоль, если твой процесс не часто происходит. Дебаггер немного замедляет игру, и в релизной/экспортной версии игра чуть быстрее.
Алсо, если не знал, в редакторе есть возможность просматривать актуальный вид дерева сцены - это чрезвычайно затратная операция, а новички часто случайно её включают и забывают выключить.
Если будешь делать параллельный поток, сначала присмотрись к воркерам (WorkerThreadPool) - проще запустить, чем создавать свой Thread; у меня с ними поменьше ошибок доступа было почему-то. Главное, потоки могут ускорить только что-то изолированное, иначе только добавишь ещё больше задержек на синхронизацию или обращения к API движка.
>встроенный дебаггер
В смысле "то, что под кнопкой debugger внизу экрана", потому что речь о "profiler" и/или "monitors", не помню точно... Дебаггером обычно называют программу, что позволяет заглянуть в память другой программы и выполнить исследуемую программу по шагам. Т.е. от дебаггера в этом субменю только +/- одна функция, остальное за компанию добавили под ту же кнопку.
>актуальный вид дерева сцены
А это на кнопке "Remote" в окне "Scene" находится.
Запустил редактор, чтобы убедиться...
>>1059295
Ещё вспомнил одну неочевидную штуку. Если ты размещаешь распакованную сцену, то обязательно сохраняй ссылку на 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К.
Разобрался с экспортом - годо кеширует экспорт оказывается
челик, ты через VPN гейропы или сша сидишь и тебе подгрузили рекламу с яху, что тебя удивляет, поставь блокировщик рекламы
> Нет. Достаточно системных ярлыков/шорткатов.
Вкусовщина.
Это просто
> 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
@
GODOT 3.6.2 НА ANDROID
@
ДЖВА ЧАСА РАЗБИРАЛСЯ
@
ПОУДАЛЯЛ ВСЁ ЛИШНЕЕ ИЗ PATH
@
ВЕДЬ У МЕНЯ КУЧА КОНПЕЛЯТОРОВ
@
В CUSTOM.PY НЕЛЬЗЯ ДЕРЖАТЬ ВСЁ
@
НО В ДОКАХ ОБ ЭТОМ НЕ СКАЗАЛИ
@
ОТКЛЮЧИЛ ВООБЩЕ ВСЕ МОДУЛИ
@
КРОМЕ GDSCRIPT И ЕЩЁ ЧЕГО-ТО
@
НАКОНЕЦ-ТО ЭКСПОРТИРУЮ
@
СЭКОНОМИЛ АЖ 12 МБ (46 -> 34)
@
ВЕСЬ В ПРЕДВКУШЕНИИ СКОРОСТИ
@
ДРОЖАЩИМИ РУКАМИ ЗАПУСКАЮ
@
ВМЕСТО ИГРЫ - ЧЁРНЫЙ ЭКРАН
>ОТКЛЮЧИЛ ВООБЩЕ ВСЕ МОДУЛИ
>ВМЕСТО ИГРЫ - ЧЁРНЫЙ ЭКРАН
Так логично. Смотри документацию внимательней, там описывают какие модули за что отвечают - примерно сможешь прикинуть что твой проект реально использует.
это игра в разработке про шизика в поезде? напомни название
Почему экран чёрный-то?.. Хотя бы заливка серым сработать должна была, это же glClear() всего лишь. И ничего такого сложного в игре нет... Ладно, я вырубил модуль "etc", что, по идее, должно выключить в GLES2 вообще все текстуры. Но у меня даже просто Label не отображается. Хотя модуль с текстом добавил вроде.
Когда я изменил настройки, добавив "etc", почему-то результат (apk) не поменялся, судя по хэш-суммам... Неужели каждый раз все .o-артефакты удалять надо?
Короче. Я так понял, что для мобилки ради ≈12 МБ (в установленном виде; в apk ещё меньше, ≈5 МБ) нет необходимости компилировать свои темплейты... Официальные вроде и так на скорость заточены.
Алсо, да, я знаю, что можно было подключитлся к смартфону удалённо и посмотреть журнал ошибок. К сожалению, USB кабель и так раздолбан и мне лень разбираться в нюансах - я хочу сразу нормальное приложение получить, чтоб работало независимо.
Ладно... Это всё прокрастинация, походу...
У меян есть кнопочка и она должна открывать диалог выбора папки. При помощи гугла и передовых языковых моделей был создан код, который почти делает, что надо. Но есть одна заминка. После выбора папки в диалоговом окне нихуя не происходит. И пишется ошибка, что там что то не так.
Где чатгпт хуй? Версия движка 4.41 Документацию смотрел, но там без примеров непонятно.
Гопота перепутала 3 годот с 4. В 4 у тебя просто должно быть .connect(_on_dir_selected), прямо так, без передачи владельца или еще чего нибудь. Тупо обьект/self.методобьектанепосредственно
https://docs.godotengine.org/en/stable/getting_started/step_by_step/signals.html
> есть кнопочка и она должна открывать диалог выбора папки
> После выбора папки в диалоговом окне нихуя не происходит
Штош, вот тебе код от ЕИ (естественного интеллекта). С тебя игры.
... Но самое крутое, ящитаю, что вышеприведённую задачу можно сделать вовсе без скриптов, просто настраивая узлы в инспекторе. Вот пруф:
>вот тебе код от ЕИ
>без ведущего "_"
Пипец кринж...
>>1059397
Подключай сигнал на панели справа от инспектора.
Подключение сигналов кодом нужно только если ты:
- создаёшь новые ноды в коде и подключаешь их;
- используешь add_user_signal() где-то в своём коде;
- отключаешь и переподключаешь сигналы в рантайме;
- хочешь подключиться к Object, RefCounted или Resource.
Если сцена статичная (как обычно в GUI) - юзай панельку.
Я вообще ебал кодить такие простые штуки.
Взял да методами присоединил и всё, хули париться?
on_yourmom_pressed и всё нахуй
Так же как и для обычной Button, у них это всё в базовом классе задано. Сначала устанавливаешь режим, потом ловишь сигнал.
>Мне кажется очень медленно, 5 чанков размером 255х255 за 600 миллисекунд
Сделал 9 чанков 255на255 за 700мс
Использовать TileMapPattern было ошибкой, он не ставится быстрее в TileMapLayer и занимает больше памяти т.к. хранит в себе каждую ячейку как класс, пиздос
Да, я думал с ним будет быстрее, типа отдал паттерн в C++ часть и она хитро установится в TileMapLayer, но хуй там. Там ещё вызывается функция конвертации кординат для не квадратных тайлов на каждый тайл, т.е. она вызывается даже для квадратных тайлов, но возвращает просто сумму координат, а если не квадратный начинает высчитывать хуйню всякую.
Через него 9 чанков создаются за 980мс
>>1059304
>>1059305
Ты там понаписал много, спасибо, но вопрос был кто генерировал, я хотел спросить какие скорости на каком объёме у других. Про потоки, с++ и т.д. я знаю.
Мониторы не работают пока _process не начнёт выполняться и профайлер тоже не поможет, если только код в ready не обернуть в
> while true:
потому что в нём не сохраняется галочка "Script functions"
>700мс
>980мс
>код в ready
У тебя там какая-то экономия на спичках.
>вопрос был кто генерировал
>какие скорости на каком объёме
Ну, блин, очевидно же, что всё зависит от:
- CPU, RAM, GPU, настроек питания, разгона;
- версии движка, API, конструкций языка и т.п.;
- самого алгоритма генерации карты (что и как);
- объёма данных, включая размер и число тайлов;
- этапа генерации (только данные или рендеринг?).
Так что твой вопрос был неправильно поставлен.
>пока _process не начнёт выполняться
Ты ж не предупредил, что у тебя генерация в _ready.
Значит, так. Генерация карт в играх в двух местах:
1. При создании мира/на загрузочном экране.
2. При движении игрока по большому миру.
В первом случае ты можешь потратить хоть 5 минут, большинство игроков потерпят. Но ты обязательно должен избежать блокировки GUI-потока своей игры дольше, чем на три секунды. То есть если твой код занимается чем-то целую секунду, то имеет смысл вынести его в отдельный поток даже на экране с надписью "загрузка". Иначе ОС посчитает окно игры зависшим и предложит игроку "отправить отчёт об ошибке". Да и сам игрок может забеспокоиться.
При движении по миру у тебя вообще есть в среднем меньше 16 мс на загрузку/генерацию чанков карты. Поэтому "чанк" в игре - это обычно очень маленький фрагмент карты, который за один кадр создаётся.
Короче, что я хочу сказать - генерировать в _ready нерационально даже для тестов, потому что это не отражает реального использования генератора.
Также хочу отметить, что желательно сразу делить "генерацию карты" и "рендеринг карты". Первое - это определение данных типа "вот здесь должна быть клеточка с водой", а второе - это "поместить тайл с анимированной текстурой воды в эту клетку". Если используешь Noise для генерации, то вся генерация происходит у тебя на C++ и ты просто "рендеришь" (отображаешь) результат генерации на экране.
Знаешь, ты б лучше скриншот своего кода скинул...
У другого знакомого игра запустилась со второго раза.
А у меня всё нормально, что в редакторе, что в экспортной версии. Кто нибудь сталкивался?
>shader_data.is_empty() is True
Ну я даже не знаю. Шейдер пустой?
>>1059544
Это местный безыгорник, страдающий недержанием. Теперь ему до следующего разбана терпеть или куки вилкой чистить.
toggled(toggled_off:bool) - обратное состояние, я правильно понимаю? Нет возможности чекнуть с компа
> я правильно понимаю?
Неправильно. Зачем ты название переменной меняешь? Надо менять значение. true или false - это значения типа bool. toggled_on это не значение, это название. Его не надо менять.
toggled(true) - нажато
toggled(false) - отжато
судя по ошибкам ты нашёл ассет с красивым компьют шейдером, а то что на нойтбуке друга со встроенной видеокартой он не заработает тебе никто не сказал
Ну кста, я решил ради интереса порталы поставить, они вынуждают мой пк жёстко пердеть. Но их у меня нет в главном меню, но в нём я предзагружаю сцену с уровнем и этими порталами
А подобная хуйня, напомню, была в Prey 2006 года, и работала игра на картофеле
>Знакомый прислал такую картину.
Пусть пришлёт характеристики компьютера.
Судя по ошибкам, Godot не смог найти Vulkan (или ты специально его отключил в своей игре), и пытается использовать Direct3D12, но что-то идёт наперекосяк с шейдерами. Неудивительно, т.к. поддержка D3D12 остаётся экспериментальной до сих пор (вроде бы).
Попроси его попробовать compatibility рендерер:
>твоя_игра.exe --rendering-driver opengl3
Графика может испортиться, но должно работать.
>>1059542
>в багтрекере over 10к багов
Это не баги, а отчёты пользователей о каких-то своих проблемах (issue). Иногда они дублируются или могут описывать что-то совсем мелкое. Иногда они могут исправляться сами собой, когда исправляют что-то совершенно другое. Многие проблемы связаны со специфическим железом или очень особенным использованием... В общем, чисто по количеству бестолку что-то обсуждать кроме популярности.
>>1059551
А ты иди учи азы информатики, 6 класс школы.
>обратное состояние
Будет, например, так:
>func _on_button_toggled(toggled_on: bool) -> void:
>_ var toggled_off := not toggled_on
Но это ты сам должен знать без подсказок...
>>1059562
>вынуждают мой пк жёстко пердеть
>>1059565
>2006 года, и работала игра на картофеле
Вы обсуждаете велосипед какого-то васяна... Ну ок, обосрался школьник, бывает. При чём тут движок? Обосраться можно и на ассемблере - что теперь, все разработчики железа виноваты теперь?
>Попроси его попробовать compatibility рендерер: Графика может испортиться, но должно работать.
Туманчик сразу пропал... Но ладно. Он оперативно не может быть со мной на созвоне, если всё норм и он попробует, завтра отпишу.
>Судя по ошибкам, Godot не смог найти Vulkan (или ты специально его отключил в своей игре)
Эти настройки я не трогал, всё работает по дефолту на forward+
Тебя рано или поздно посадят на бутылку кавказцы
А "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 на эту тему.
>>1059581
Чего, лол?
Увы, но нет, всё по-умолчанию. Надеюсь что дело реально в бесконечном залупинге, и запустив изначально в другом рендеринге всё норм будет
Хуй знает, не следил за ним. А вообще, люблю ассетодебилов. Они забавные.
Ага, навалил кучу ассетов, и с умным ебалом такой говорит нам, что дескать вот мол, в 2006 году диды делали порталы, которые на картошковых целеронах тогдашних работали, а нонче школоте нельзя ассетов навалить, чтоб не пропердеться.
>У тебя там какая-то экономия на спичках.
Мне в перспективе чанков генерировать тысячи / десятки тысяч, я на этих спичках лесополосу сэкономлю.
>Так что твой вопрос был неправильно поставлен
Очевидно так-же, что ты не генерировал, но смотрел туториалы как это делается.
>Ты ж не предупредил, что у тебя генерация в _ready.
Она если бы не в ready была, по твоему в process что ли? Это буквально то же самое что генерация на экране загрузки, функция которая пока повисает поток, не в этом суть.
>Короче, что я хочу сказать - генерировать в _ready нерационально даже для тестов, потому что это не отражает реального использования генератора.
Для понимания скорости генерации как-раз самое то
У меня цель - сделать на годоте, но, но тот же TileMapLayer как я заметил ебашит мне память, 9 чанков - потребление 250мб ( с 1 чанком - 79мб) (чанк у меня 255 на 255 пока, не суть, если делать их меньше их тогда всё равно в памяти держать больше придётся)
Я за сегодня накидал на гдскрипте свой Тайлпап который рисует чанками, результат на пике - 207мб и 5 дроуколов при дефолтном зуме.
Дефолтный тайлмэплейер хранит кучу ненужного мне - окклюдеры, физику, навигацию, и ещё всякое (да, даже если они выключены), мне от него нужно как бы только ускоренное рисование квадрантами, а это я сам +- сделал.
Но главная цель - делать на годоте и все оптимизации за счёт с++ отпадают, я потыкаюсь ещё, но кажется получить вменяемые скорости и потребление памяти не выйдет в итоге и от годота мало что останется.
>чанков генерировать тысячи / десятки тысяч
Если ты делаешь игру типа Terraria, то лучше будет сначала сгенерировать данные всего мира на C++, вообще не прикасаясь к API Godot. А размещать на экране тайлы будешь по необходимости.
>ты не генерировал, но смотрел туториалы
Я генерировал разными алгоритмами. И 2D, и 3D. И интересовался методами генерации в разных играх. Поэтому и спрашиваю - что ты там у себя делаешь?
>если бы не в ready была, по твоему в process
>функция которая пока повисает поток
Что ты несёшь-то. Генерацию можно делить на шаги. Выполнять шаги можно в разное время. Чтоб ты не подвешивал поток, ты делаешь N шагов за кадр и дожидаешься следующего кадра. Да, дольше, но это позволяет потратить на генерацию хоть полчаса, не вызывая у ОС и юзера панику "программа зависла". Замерять время выполнения в _ready малополезно, поскольку в реальности это будет в _process или в параллельном потоке, который отчитывается туда.
>TileMapLayer как я заметил ебашит мне память
Тут опять много деталей упущено:
- как ты его настраиваешь,
- как ты его используешь,
- какие у тебя тайлы,
и т.д. и т.п.
>накидал на гдскрипте свой Тайлмап
Я тоже так делал. Через SubViewport объединяешь? Разница в 43 мегабайта не выглядит существенной, наверняка бОльшую часть памяти занимают эти отрендеренные текстурки, а остальное - мелочи.
>все оптимизации за счёт с++ отпадают
Ну, тогда C# или Rust... Выбирать есть из чего.
>главная цель - делать на годоте
Если цель - "что угодно, лишь бы на годоте", то
>вменяемые скорости и потребление памяти
Достигается путём ограничения своих хотелок.
Ещё раз: ты ни код свой не показал, ни на словах не объяснил, что именно и как ты генерируешь. 100% копипаста какого-нибудь туториала или вообще LLM сгенерировала, а теперь ты какие-то цифры постишь, оторванные от реальности и ничего не значащие... Характеристики компа тоже опиши - CPU, RAM, GPU.
>Если ты делаешь игру типа Terraria
Идея - типа Cataclysm
>Я генерировал разными алгоритмами.
Ну да
>Что ты несёшь-то.
Есть экран с надписью "Подождите, идёт генерация" или я в ready а даный момент делаю генерацию, какая нахуй разница, если полтзователь сидит и пердит?!
> как ты его настраиваешь,
> как ты его используешь,
Бля чел там 3 настройки "Включить навигацию", "Включить Коллизии", "Включить освещение", что там блять настраивать и использовать, ну размер квадранта есть ешё, я не ковырял он или текстуру создаёт в которую всё рисует или как я делает канвас айтем и в него рисует
>Я тоже так делал. Через SubViewport объединяешь?
Нет конечно, цепляешь новый CanvasItem в который рендерится один чанк, для каждого чанка, у меня просто Node2D
>>1059624
>Разница в 43 мегабайта не выглядит существенной
Бля а то что она в чанках 9 против 25 ещё
>Ещё раз: ты ни код свой не показал, ни на словах не объяснил, что именно и как ты генерируешь. 100% копипаста какого-нибудь туториала или вообще LLM сгенерировала, а теперь ты какие-то цифры постишь, оторванные от реальности и ничего не значащие... Характеристики компа тоже опиши - CPU, RAM, GPU.
?!
Ой бля, ладно, ну тебя нахуй, тебя и без трипкодов видно
Поясняю на примере для самых маленьких:
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 доволен?
Делаем.
Я вот за всё время только одним ассетом пользовался - TerraBrush, или как-то так. Да и то, учитывая что во всех нормальных движках такой функционал есть из коробки - я не хочу называть это ассетом.
>>1059673
Вы сейчас серьёзно? Откуда у вас столько времени? У меня даже на полностью готовых ассетах уходят месяцы на простую игру.
На что у тебя больше всего времени уходит? Из всего геймдева.
То есть я правильно понимаю, что ты сначала сделал ассеты, саундтрек, дизайн, сюжет, и только потом начал делать, собственно, игру?
А хули там вообще бразильцы забыли? Они ж буквально на ветках до сих пор живут.
А китайцы до сих пор 3 смены пашут за миску риса и плодятся как ебанутые. Из 90х пишешь?
В прогрессе китайцев сомневаться не приходиться. А вот хули там бразилия где пол страны до сих пор в фавелах живёт и ни одной игры за всё время не выпустила - загадка, да ещё и сразу после 2-х гигантов.
>>1059713
>>1059720
Дак ты вообще самостоятельно нихуя не делаешь, получается?
Кстати, раз уж такая пляска. Аноны, какова ваша производительность за 1 игростройный день? Что успеваете? Довольны ли собой?
Я просто оптимизирую силы, если делать ассеты самому то игру никогда не сделаешь.
Код писать я даже в обучении не особо что понял
12ч х 6 дней, по статистике плодиться с прошлого года перестали, ибо некогда стало совсем
Знаю что основной разраб гдскрипта (vnen) из Бразилии, и до сих пор там живет.
> А вот хули там бразилия где пол страны до сих пор в фавелах живёт и ни одной игры за всё время не выпустила
Пиздишь ведь
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
>Я просто оптимизирую силы, если делать ассеты самому то игру никогда не сделаешь.
Нет, ты просто не хочешь стараться
>Код писать я даже в обучении не особо что понял
Осилить гдскрипт может даже примат. Ты даже не старался
Я только базу самую понял что такое переменные и функция. Как с этим код писать ваще хуй знает
Дергаешь разные функции, сохраняешь их результаты в переменные. Все, ты программист.
А это не так? Ты либо написал ебейшие тесты, один из тысяч поступил в лучшие и средние вузы страны а затем в офис малдшим говночистом, либо поступил прямо в пту и был отправлен в город улей - работать на мануфактуре за трупный батончик 12 часов в день. Или был сослан на рисовые поля к бабке горбатиться под солнцем по колено в говне в местном колхозе за неироничный миска рис.
нет, не так. Китай это сверхдержава и мировой гегемон, первая экономика мира, вузов там больше чем в любой другой стране
>бразильцы
Думаю, у них интернет лимитный, как у нас в 00-х, и выкачивать 20 ГБ других движков каждый месяц - отказывать себе в других развлечениях. А Godot относительно мало весит и при том популярен...
Плюс редактор Godot есть на Android.
>>1059734
Удивлён, что в списке нет африканских стран...
>>1059745
>до сих пор в фавелах живёт
Смартфоны и ноутбуки есть даже у бездомных в большинстве стран, включая совсем нищие. Это не продукты питания - могут служить больше 10 лет, и в отличии от дома не занимают много места. Есть множество способов добыть электричество и даже интернет бесплатно или практически бесплатно.
>>1059766
Ты про какую страну пишешь? Везде так, лол.
И как вы в геополитач всё скатывать умудряетесь?
>Ты про какую страну пишешь? Везде так, лол.
В нищих перенаселенных помойках это не везде. Даже местные петровичи больше 8 часов в день не работают, либо работают 2 через 2. А не 12 х6, а если хочешь еще половинку трупного батончика - доработай свой единственный выходной.
>Где вы ассеты нормальные берёте?
Сам делаю... А, стоп, я забил. У меня депрессия...
>>1059673
>одним ассетом пользовался - TerraBrush
Это не ассет. Ассеты - это графика, текст и музыка.
>>1059711
>Откуда у вас столько времени?
Добрые родственники и пенсия по инвалидности.
>уходят месяцы на простую игру
Нормальный геймдев начинается с 5 лет на игру.
>>1059720
>Я нейронкой код делаю
Вот поэтому у тебя и уходят месяцы на 3-в-ряд.
>>1059748
>производительность за 1 игростройный день
Несколько срачепостов на дваче считается?
>Что успеваете? Довольны ли собой?
Ничего не успеваю, разочаровываюсь в себе.
>>1059754
>делать ассеты самому то игру никогда
А что такое "игра" если не набор ассетов и правил?
Правила ты 100% скопировал с успешных игр.
Ассеты ты все скачал на 100% готовые.
Код тоже берёшь готовый (из LLM).
В чём "твоя" игра заключается?
>>1059761
>Осилить гдскрипт может даже примат.
Джва банана этой горилле.
>>1059763
>понял что такое переменные и функция.
Учи if/elif/else, for, while, match, signal, class и т.д.
А в чём смысл делать самому ассеты если точно такие же лежат, причём совершенно бесплатно.
В том, что и игра получится "точно такая же", ничем непримечательная, похожая на остальные. Затеряешься в толпе и получишь ноль аудитории. Смысл делать свои ассеты - придать игре более редкий визуал. Но тут конечно нужен и стиль и вкус и скилл. Если твой потолок - "программер арт" то действительно лучше готовые взять.
>Это не ассет. Ассеты - это графика, текст и музыка.
Ассеты это любая готовая хуйня. В том числе кусок кода. А террабраш это тоже своего рода кусок кода. Делайте выводы, карлеки
>игра получится "точно такая же", ничем непримечательная, похожая на остальные. Затеряешься в толпе и получишь ноль аудитории.
Всё так, игре нужно лицо.
>Если твой потолок - "программер арт" то действительно лучше готовые взять.
Категорически не согласен. Если у тебя нет вкуса, то готовые ассеты ты разложишь плохо. А свой арт как минимум будет соответствовать всему остальному безумию, происходящему в твоей игре.
Если нет вкуса, то в геймдев не лезь. В геймдеве в большинстве случаев добиваются успеха игроки, а не никогда ни во что не игравшие предприниматели.
>>1059774
>точно такие же лежат, причём бесплатно
Это что ты такое делаешь, что все ассеты, о которых мечталось, у тебя где-то бесплатно скачиваются? Ты абсолютно точно уверен, что они бесплатные, а не ворованные из какой-нибудь чужой игры?
Кинь ссылку на эти твои бесплатные ассеты.
>В том числе кусок кода.
Нет, у тебя даже на скриншоте это сказано:
>состоящий из однотипных данных
Код данными не является, поскольку код - это то, что исполняется машиной, а данные - это то, с чем будут работать алгоритмы, описанные в коде машины. Да, исходные коды можно хранить в текстовом файле и передавать как данные, но это не данные, если их рассматривать с точки зрения игры (программы).
Код может быть префабом в терминах Юнити, но в контексте Godot отсутствует аналогичный термин, несмотря на возможность включать код в сцены.
Тем более есть разница между "код игры" и "код из инструмента, используемого для разработки игры":
>А террабраш это
Это инструмент. Как кисточки и краски. Иначе тогда "ассетом" пришлось бы называть абсолютно всё, что используется для разработки игры, включая воздух, вдыхаемый разработчиком во время разработки.
>>1059781
>на итч же ворованное не будут заливать
Постоянно заливают, лол. Вирусы там тоже есть.
Ну я уже накачал под пол террабайта, мне похуй что там ворованное не я же воровал
>Нет, у тебя даже на скриншоте это сказано
Да я уже сам понял, что серанул. Это аддон. Но я думаю, мол, он же из АССЕТ стора, а не АДДОН стора, значит, очевидно, это ассет.
А зачем вообще играми заниматься если ты нихуя сам делать не хочешь?
Когда он начинал, он хотел. Это же база, основа, фундамент, классика.
>Ну я прораб, а не батрак.
Понял
Нормально у тебя, не пыхти. Смотришь среднее железо по steam hardware survey, если на нем выдает 60+ то заебись.
>Ноды - дохуя мультимешей (прям пару десятков тысяч)
Шта? Может быть дохуя инстансов?
А как это возможно? Или у тебя гипер-йоба-пк? Это же гарантированные тысячи вызовов отрисовки, не? Или у тебя дальность прорисовки 10 метров?
Там при приближении зума (вид как в ведьмаке условно) что-то около 100 метров. При удалении на высоту 20 метров че-то около 50 метров (тупо что в экран влезает)
Blender + скачанные нахаляву аддоны типо uvpackmaster + substance_painter если что-то не шибко сложное. Если самому вообще никак - пизжу и меняю до неузнаваемости.
>мультимешей (прям пару десятков тысяч)
>до 1000-2000 (прост трава) истансов
Их нужно аккуратнее использовать. Там когда хоть 1 инстанс на экране, будут отрисовываться все сразу.
Но куда важнее - физика. Что по физике?
>количество нодов в игровой сцене
Ориентируйся на "не более 100 тысяч" примерно... Разумеется, на топовом ПК может и миллион можно достичь, но ты же хочешь игру делать, а не нодами заполнять сцену. Дерево сцены однопоточное.
>>1059797
>гарантированные тысячи вызовов отрисовки
На OpenGL. На Vulkan это больше не так, если у него одинаковые материалы. И, кажется, вызовы Vulkan намного дешевле. Но базовая пустая сцена дороже.
>Если самому вообще никак - пизжу и меняю до неузнаваемости.
Кстати, касательно этого. Какими методами можно вычислить пизженую модель? Я не умею моделить лица, а потому просто вырезаю их из рандомных моделей и переделываю топологию и с нуля все текстуры. Могут спалить?
Насчёт количества инстансов то понятно, там кстати если около полусотни то уже профит от мультимеша.
Физика при взаимодействии с персонажем - шейдер всю работу делает (чекает позицию и вертит крутит эту суку) ну и ветер естественно. Коллизии как таковой нет. Вот что делать с деревьями пока вообще непонятно, там фокус с мультимешами не прокатит, модели разные, да и коллизии нужны.
Ну чисто теоретически если там vertex_group какие-то спрятаны и т.д., то конечно могут, но ты ж можешь всё удалить к ебени фени, так что если и топологии сменишь - то наверное никак. А вообще прям серьёзно за твою жопу вряд ли возьмутся.
Вот мне нравятся игры типа Degrees of Lewdity, не по эротике, а по взаимодействию с игровым миром и своенравными персонажами, свободой выбора по развитию своего персонажа и т.д. Но совершенно не понимаю, с чего такие игры начинаются. Пробовал прототипировать, но всё время что-то не то выходит. Теоретически, такой игре вообще графика не нужна, достаточно описания событий и кнопок, как в старой интерактивной литературе. Но всё равно придумать минимальный контент для начала не выходит.
Почему Godot? Пробовал Twine, но скриптинг там не нравится, поддержка слабая, и если захочется туда графики навернуть, то всё сильно усложняется. Я-то думал, там проще будет геймдизайнить, но нет...
>просто вырезаю их из рандомных моделей
@
>переделываю топологию и с нуля все текстуры
В чём смысл вырезать что-то откуда-то, если ты всё переделываешь начисто? От оригинала у тебя ж не остаётся ничего (судя по твоим словам), так в чём проблема открыть скриншот сетки в поисковике как референс и намоделить её самому себе?
В смысле, зачем искать и скачивать модели? Это ж лишняя работа получается. Мне вот лень. Ещё и регистрироваться часто заставляют, а всякие там файлопомойки и торренты только через прокси... Намного проще самому с нуля всё вылепить.
> чтоб 200+ fps было
На каком железе с какой видеокартой и каким количеством памяти должно быть 200+ fps?
Вот когда я был моложе, то уменьшал окно dom 2 что бы он не тормозил. А сейчас могу в него играть с 200+ fps. Так что "зависитот железа" это база.
Ну, есть некоторый ориентир, чтобы вся эта хуерга игралась в 2к с фпс выше 100, учитывая что в игре пока околонихуя из того что нужно сделать
>Вот что делать с деревьями
Если лес плотный и большой, то 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 вроде сам объединяет.
>был моложе, то уменьшал окно dom 2
>А сейчас могу в него играть с 200+ fps
А как ты в него играешь? Какой сервер?
1. Делаешь игру как поулчится.
2. Выпускаешь в ранний доступ с тормоза\ми лагами и багами.
3. На заработанные деньги нанимаешь настоящих разработчиков и они опиливают игру к релизу.
4. ???
5. PROFIT
Проебываешься между 2 и 3 пунктом, зарабывая нихуя, и нанимаешь снова только себя за все тот же нихуя. Правильный подход - кормить нейро-концепт-артами на кикстартере и инфоцыганить себе фандрейзинг, спустя годы выпустить ерли акссес огрызок и съебать в туман.
У тебя неправильно, пофиксил:
>1. Делаешь игру как получится.
>2. Выпускаешь в ранний доступ с тормозами, лагами и багами.
>3. Пукаешь и обмякаешь с 10 отзывами.
>4. ???
>5. Ноешь на дваче, как ты 5 лет делал обновления к мертворождённой игре, а тебя твои же 3.5 игрока оскорбляют и унижают в отзывах к игре.
>>1059825
Если ты нихуя не заработал на своем раннем доступе, то вероятно ты нихуя не заработаешь и вложив дохуя сил и времени. Идея изначально никому не нужна. С другой стороны посмотри на на титанов индустрии. 7 days to die вышла в релиз только потому, что так их пустят на коробокс. Игра спустя годы все такая же сырая. Но пилу нравится идея и каждый патч приносит онлайн и новые деньги. Так и живут.
1. шум перлина всё равно нужен чтоб сгенерировать основу
2. реки можно создавать с помощью flow accumulation, начиная с наивысших точек в горах
3. что я понял после экспериментов с подобными генерациями - игра это не GIS, главное, чтобы было весело, а не чтоб было реалистично
>Если ты не заработал на своем
>посмотри на на титанов индустрии
Может, лучше свой успешный успех покажешь?
>>1059828
>генерацию карты как в дудл джампе?
>чтобы пройденный путь сохранялся
Когда играл в Doodle Jump на J2ME, если память не изменяет, игра не позволяла двигаться вниз. Если оступился и полетел вниз - всё, Game Over. Да и с геймплейной точки зрения смысла в этом не вижу.
Если всё-таки хочешь сохранять, два варианта:
1. Использовать Noise.get_noise_1d(высота), чтоб генерировать путь из одного seed. Но это не будет правильно работать, если есть разрушаемость.
2. Сохранять сгенерированные данные в массив и загружать из него при движении вниз. Если объект разрушился, то удалять его и из массива тоже.
Но это, в любом случае, оптимизация. Помни, что, с одной стороны, маленький уровень может прямо нодами на сцене отображаться без проблем, однако, с другой стороны, уровень не может одновременно сохраняться с разрушаемостью и быть истинно бесконечным из-за ограничения по памяти.
Т.е. порядок действий такой:
1. Делаешь прототип генерации без оптимизаций - платформы сохраняются в сцене и не удаляются.
2. ЕСЛИ это слишком быстро приводит к тормозам - оптимизируешь удалением нод со сцены, сохраняя требуемую информацию в отдельном массиве.
3. ЕСЛИ по-прежнему упираешься в лимит из-за длительного геймплея - упрощай геймплей, удаляй возможность двигаться вниз/бесконечно вверх.
> Может, лучше свой успешный успех покажешь?
Нет, не покажу.
А ты свой покажешь?
Ну смотри. Во первых не начисто, а просто чтобы не спалиться. Подергать сетку большого ума не надо. А во вторых: взять готовую голову, ремешнуть, немного поелозить кистью в скульпте, потом взять ретопофлоу и быриком накидать новую сетку - это не такая проблема, как собирать голову с нуля, особенно если ты кретин, как я. А у меня нет проблем с работой в блендере, у меня есть проблемы с моими художественными навыками. Сделать голову без эффекта зловещей долины сложнее, чем кажется. А что касается остального: тела там, хардсёрфейса - да, проще и лучше сделать самому.
Ну смотря какая разрушаемость. Максимум кувшинчики и то возможно нихуя не будет. В любом случае спасибо за наводку
>>1059806
>Вот что делать с деревьями пока вообще непонятно, там фокус с мультимешами не прокатит, модели разные, да и коллизии нужны
Поделюсь своим говноопытом. Обоссыте или одобрите. Я резал вегетацию на чанки метров 200х200, ареа3Д, которая на сигнале подрубала чанку вычисления. Вычисления, соответственно меряли дистанцию до каждого инстанса пачками, переключали лоды и двигали несколько заготовленных коллизий к самым близлежащим деревьям. На неактивных чанках они уже щелкают коллизии для всех инстансов сразу. Ну и левелдизайнил локацию так, чтобы большую часть вегетации всегда закрывала какая нибудь гора и её можно было просто отключить.
>просто чтобы не спалиться
Ладно, что мешает взять бесплатную модель, где официально лицензия типа CC0/CC-BY, чтобы не заниматься воровством ассетов из чужих игр?
>Сделать голову без эффекта зловещей долины
В стиле фотореализма? "Мультяшные" головы по определению не могут вызывать этот эффект, в особенности лоупольно-квадратные обрубовки. Т.е. буквально почти все инди-игры не могут дойти до "зловещей долины" из-за их стилизации.
Сколько миллиметров FOV в Blender у тебя? Там по умолчанию значение 50 mm - это норм для всяких моделей окружения, но для персонажей лучше 80+, поскольку работаешь с ними, приближая камеру, и стандартная перспектива делает их "жуткими" по причине несоответствия FOV расстоянию до лица.
ВНЕЗАПНО очень не очевидный, но факт. Долго не понимал, почему так всрато выходит, пока это не нагуглил. И ведь в подсказках Blender этого нет!
>>1059844
>А ты свой покажешь?
Нет, у меня никогда не было успехов.
>>1059846
Меньше думай, больше прототипируй и тестируй.
>>1059848
Вроде нормально. А насколько выгоднее двигать существующие статичные коллизии по чанку по сравнению с добавлением/удалением? Мне такое в голову вообще не приходило - спасибо за идею.
>Сколько миллиметров FOV в Blender у тебя?
>ВНЕЗАПНО очень не очевидный, но факт
Лол. Я что-то слышал об этом, но не использовал. Нужно будет попробовать
А вообще даже СС0 хочется переделать. От греха подальше. Может быть я просто шиз.
>А насколько выгоднее двигать существующие статичные коллизии по чанку по сравнению с добавлением/удалением?
Я не могу сказать в цифрах, но вообще у меня эта идея возникла когда я увидел на ютубе лайфхак, что всякие пули, стрелы и прочие фаерболы дешевле держать заранее интанциироваными где нибудь в инвизе и в нужный момент задействовать. По моему это достаточно очевидно, что двигать дешевле, чем инстанциировать, так что возможно я тебя не понял. Если у тебя, условно, 1000 деревьев на чанк и за одну пачку/кадр ты проверяешь, скажем 50 инстансов, при этом весь чанк наполнен лесом, значит в теории у тебя может произойти несколько кадров подряд, которые инстанциируют все 50 коллайдеров махом. Как по мне - жирно. А если ты будешь ограничиваться небольшим колличеством коллизий, скажем 5 штук максимум - значит эти коллизии будут дрочиться постоянно, что тоже малоприятно.
В моем частном случае экспериментально выяснилось, что держать больше 3 коллизий на каждый мультимеш в сцене, при должной настройке расстояния и обновления просто бессмысленно. А с учетом того, что ты всеравно чекаешь расстояния ради лодов - коллизии происходят практически бесплатно
>крупный проект
Крупный проект на дваче не сделают. Ох уж эти переживания уровня "а что если иноплоны прилетят и в жопу выебут". Но ок, чтобы не переживать - берешь и используешь ассеты надежных авторов вроде Кенни или Кватерниуса с их официального сайта.
Материал у кубов один на всех, второй материал у пола. Что смущает?
Разобрался, это только Forward+ такое делает какой-то оптимизацией
Вот это я малорик, пиздец просто. Не могу об этом молчать
Найду в твоей реализации сохранений 666 багов и приду ныть на твой итч.
Малаца! Успехов тебе!
>>1059919
Не стоит. Судя по описаниям там одноразовая лапша. Лучше свари свою себе сам.
Инвентарь это просто массив. Поверх массива просто 4 удобные КРУД-функции для работы с ним. Визуальное отображение инвентаря это просто контейнерный виджет, у которого есть возможность хранить список элементов. Список элементов просто грузится из массива. Ну и всё.
https://www.youtube.com/watch?v=OmKrKTwtukE
У меня вообще никаких проблем с Godot нет:
>Failed to load issues.
>We encountered an error trying to load issues.
Нет проблем - нет проблем. Гениально же?
>>1059978
Я думаю, это из-за свободной лицензии...
...ну и популярности среди инди, конечно.
>Судя по описаниям там одноразовая лапша
Да че ты доебался? Я имею представление как должен быть устроен инвентарь. Да и я всего полгода игры делою. Имею право на ошибку.
По сути у меня контроллер с массивом в корне сцены и визуальные слоты-кнопки. Слот хранит индекс массива, к которому привязан. Я перетягиваю предмет из слота в слот, слот его по сигналу ловит, обновляет иконку и регает в массив отталкиваясь от своего индекса. Но при загрузке то я сначала в массив всё запихаю и оттуда уже должен обновить иконки а у меня так не предусмотрено было
В общей сложности всё занимает строк 100-150, максимум 200. Поддерживает дроп через перетаскивание, контекстное меню, хинты и слоты для особых категорий предметов (правда для них я целый класс высрал).
Че, прям хуево напогромировал? Ну хоть не ассетфлипаю
Главное - это анимации.
Что у тебя с анимациями?
охуеть бро, я как раз вчера тоже починил сохранение инвентаря. тоже не мог разобраться че я там наговнокодил, что за проблемы были. то перезаписывало что-то сохранение, то индексы неправильные, то свойства предметов не восстанавливались. но тоже починил и тоже доволен как слон. поздравляю тя
Типа 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 года)
ебанулись вообще
>сохранить кастомный класс
Я б вообще такой хуйнёй не занимался, а написал бы классу кастомные функции to_json и from_json. Потому что, помимо прочего, сохранять целые объекты - это рукожопно и небезопасно, были сообщения о вирусах, которые это используют.
>а написал бы классу кастомные функции to_json и from_json
В смысле там автоматически что-то сработает или имешь ввиду самому вызывать эти методы? Мне же ещё нужно сопоставить их с Vector2i
>сохранять целые объекты - это рукожопно и небезопасно, были сообщения о вирусах, которые это используют
это есть во многих языках, а предупреждение о вредоносном коде потому что, скорее всего, в сетевой игре кто-то гонял сериализированные объекты и читеры свой скрипт прописывали в привязанном классе
>сохранять целые объекты - это рукожопно и небезопасно, были сообщения о вирусах, которые это используют
Если кто-то, в моей синглплеерной игре, скачивает из интернета хуй пойми какие сейвы, моды или плагины к ней - я за это ответственность не несу. АААА дядям на это поебать, а вы уже какой год беситесь-носитесь с этой хуйней, и требуете чтобы у соло-индюков было все надежней чем у АААА. Хуй. Как сохранял так и буду сохранять, сами ебитесь со своей "безопасностью".
>то перезаписывало что-то сохранение, то индексы неправильные
Ты в бинарном виде записываешь что ли? Боишься, игрок считерит?
>>1060008
>Как сохранить кастомный класс, точней словарь с классами?
Другой анон правильно заявил: >>1060019
>написал бы классу кастомные функции 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.
>>1060021
>В смысле там автоматически что-то сработает
Если хочешь автоматически, тебе нужен этот обработчик:
>func _to_string() -> String:
>_ return "какие-то твои данные в виде строки"
Это должно автоматически использоваться в методе var_to_string().
Подробнее смотри в документации по to_string() и _to_string():
https://docs.godotengine.org/en/stable/classes/class_object.html
да нет, я новичок совсем, сам до конца не понял как это вышло
>Это должно автоматически использоваться в методе 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\"]"
>}
Т.е. вместо "метки класса" получается такая строка.
Короче, если хочешь САМЫЙ ПРОСТОЙ способ сериализации:
>Как сохранить кастомный класс, точней словарь с классами?
Просто делаешь свой класс потомком 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
Под капотом можешь использовать абсолютно любой формат.
При этом твои данные будут доступны в инспекторе "как родные".
>Так ты можешь хранить свои классы как "tres", пикрил.
>Формат tres жирный - много лишних данных, дольше грузится.
А, да, можно ещё в бинарный "res" сохранить, он чуть полегче.
Но если бинарный сейв сломается, то вручную не пофиксить.
На пикриле пример сохранения кастомных ресурсов как "res".
"RSCC" - это, как я понимаю, сигнатура ресурсов Godot...
Долгожданный 3.7 дев 1. Интерполяция 3д физики, улучшенный перформанс, блоб тени, багфиксы и что-то для звука, хз что.
Я надеюсь, к 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, было бы замечательно...
К 5.0 таких девайсов практически не остается. Это как сегодня под 3Dfx пилить.
Еще дум этернал 2016 года был вулкан-онли. Начиная с андроид 15 вулкан 1.1 для сертификации обязателен. По факту анон>>1060128
абсолютно прав - еще пара лет и устройств без вулкана будет исчезающе мало. Тем более что компабилити - это и есть gles3.
Я не так давно в годоте, не застал версию 3.х. Нахуя они две версии параллельно развивают?
Потому что некоторые из нас все же сделали игры, и их надо поддерживать-развивать-обновлять, а переводить давно релизнутое на новую 4.х слишком дорогое удовольствие. Эпики тоже старую версию анрила поддерживают, про юнити не знаю.
C# веб экспорт (и прочие экспорты типа сыча/консолей) без хуйни, есть куча релизов поддерживаемых на тройке, да и развитие тройки после 3.5 это скорее не развитие, а та самая припарка мертвому, чтоб не вонял так сильно.
>таких девайсов
Каких "таких"? Давно известно, что 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 укрепление на инди-рынке, а не убегание в сторону недоступных инди ААА-проектов.
>2019, т.е. совсем недавно
Скоро 7 лет как, пчел. 7 лет в технике это огромная разница, это Вор 2 vs тот самый Крузис. К моменту когда ты допилишь что-то значимое уже все 10 будет. Я когда свое на тройке пилить начинал, целясь в телефоны, средний телефон тянул мой проект на 20 фпс, сейчас 60 изи.
>очень многие до сих пор сидят на 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 укрепление на инди-рынке, а не убегание в сторону недоступных инди ААА-проектов.
Годот это лебедь рак и щука, которые кое-как тянут движок относительно в одном направлении. Ждать от него чего-то конкретного никак при этом самолично не участвуя - пустая трата времени.
>7 лет в технике это огромная разница
>Вор 2 vs тот самый Крузис
Ты сравниваешь игру 2000 с игрой 2007, когда был самый пик развития технологий. После начала 10-х началась стагнация, потому что закон Мура умер, многопоточность в играх просто нафиг не нужна, а в плане графики ничего умного придумать не смогли, кроме нейронок из машинного обучения, способных генерировать целую игру без игрового движка - просто создавая кадр за кадром.
Это, собственно, единственный актуальный вектор развития - нейронки, способные сделать картинку уровня того же фотореалистичного ААА проекта из обучающего датасета с максимальной утилизацией десятков тысяч ядер GPU. Нейронки, способные научиться действовать как человек без ручного труда программиста. Нейронки, способные генерировать голос, неотличимый от человеческого, в реальном времени. Вот только этим нейронкам вообще не нужны никакие игровые движки и тем более не нужны разработчики игр, и от компьютера не нужны никакие особые технологии кроме десятков/сотен тысяч ядер, способных лишь перемножать матрицы чисел. Вот это единственный актуальный прогресс, который будет двигаться в ближайшие лет 10 - больше ядер GPU и больше RAM/VRAM, слияние CPU и GPU, наращивание гигантских NPU чисто под нейронки. Никакой Vulkan тут не нужен - в смысле, не нужно рендерить никакие треугольники и не нужно никаких шейдеров, нужно только перемножать матрицы на NPU.
Но мы же тут ретро-фанбои, пытаемся делать ретро-игры как деды - с полигонами, текстурами, шейдерами, тривиальными скриптами, а не генерировать видеоряд перемножением матриц на NPU, не так ли? Нас никакой прогресс больше не касается, наш технологический прогресс остановился в начале или середине 2010-х и больше двигаться никуда не будет, только поддерживаться ради забавы и тех немногих бизнесов, которым нужна графика.
>сейчас 60 изи
Если твоя игра загружает телефон на 100%, то это плохо независимо от частоты кадров: телефон будет выжигать всю энергию за час-два и нагреваться до неприятного рукам уровня, т.к. нормального охлаждения в телефонах нет. Это неприятно для и игрока, и для телефона. Поэтому желательно, чтобы у тебя было "60 фпс" с нагрузкой <50%. А также нужно встроить в настройки игры лимит частоты кадров и другие ограничители, чтоб юзер мог снизить нагрузку сам.
Ну еще по поводу прогрева телефона - а ты фпс знаешь на котором проект запустился? Там может гнало на все деньги 500 фпс, и разумеется телефон начал накаляться
>нищуки
>Нищеебы
>не платят
>продавать
>покупка
Что ты в инди забыл, где 99.99% раздают бесплатно? Выкатывайся на ААА-галеру.
>Первый проц
Речь не о первом с поддержкой, а о последнем без поддержки. Разницу понимаешь?
>собираешь сам
Это высокий порог входа, учитывая что нужно кучу инструментов поставить правильно.
>Флагманский не нужен, третий райзен
Ну и зачем ты предлагаешь покупать "устаревшее говно для нищуков"? Шило на мыло.
>На селероне гта не запустится
На "Core 2 Quad" или 4-х ядерном Xeon "GTA 5 Legacy" точно запускается и работает...
>Годот это лебедь рак и щука
У Godot есть чёткое руководство, которое определяет, что пускать в ядро движка.
>>1060141
>Там может гнало на все деньги 500 фпс
Это технически невозможно на смартфонах - там VSync включён и не выключается.
>Стена нейроманяфантазий
Рановато еще до описанного. А как только наступит момент где нейронки смогут сделать мне неироничный сталкер/крайзис, целостный, с сохранениями и стабильной игровой реальностью - в этот момент можно просто расслабиться и принять факт вторичности человека как основного разумного вида этой планеты, уже конечная, эра машин настала. Но опять таки - нейронки пока еще далеко.
>многопоточность в играх просто нафиг не нужна
Это потому что ты безигорник. Если бы ты знал, сколько всего суется в потоки, то ты бы так мощно не срал в штаны. А суется в потоки все что туда можно засунуть - физика (в годоте физику можно включить отдельным потоком), патчфайнд, генерация мешей/текстур, загрузка ресурсов с диска, создание сцен в потоках(годот разрешает), в отдельных случаях паралеллится бизнеслогика (ecs), при этом степень паралеллизации зависит исключительно от степени ошизения разраба.
>Что ты в инди забыл, где 99.99% раздают бесплатно? >Выкатывайся на ААА-галеру.
Я отлично знаю что на этом рынке покупатель готов получить твою игру любой ценой, но бесплатно, да и я свою игру пилю заведомо зная, что играть будет пол землекопа. Но рано или поздно всё же придется игры продавать, иначе нахуя это всё.
>Речь не о первом с поддержкой, а о последнем без поддержки.
Производителей цпу x86_64 в мире всего два. Кто из них после 2010 продолжил производить цпу без sse 4.2? Можешь просто модель проца назвать.
>Ну и зачем ты предлагаешь покупать "устаревшее говно для нищуков"? Шило на мыло.
На фоне некроговна из нулевых это будет звездолет с космической производительностью, если всё вот прям настолько плохо с деньгами. Да даже какой нибудь селерон 4-5 поколения уже будет лучше раз в 5.
>Это высокий порог входа, учитывая что нужно кучу инструментов поставить правильно.
Только скунса и с++ зависимости, это не сложно, процесс описан в документации.
>Это технически невозможно на смартфонах - там VSync включён и не выключается.
У годота, особенно 4, и особенно у вулкана есть проблема - он порой с vsync не дружит и хуярит кадры на похуй, ему нужно руками жестко ограничивать фпс.
>У Godot есть чёткое руководство, которое определяет, что пускать в ядро движка.
Руководство то может и четкое, но это никак не влияет на то, хочет ли контрибутор делать определенную фичу или нет. Слышал от одного из контрибов, что его pr для тройки не приняли, потребовав чтобы он сначала запилил для 4, а затем только одобрят в тройку. Такие дела с четкостью руководства.
>Как сохранить кастомный класс, точней словарь с классами?
Делай что-то вроде пикрила, если тебе не нужен инспектор.
Проверил на Godot 4.5 - всё сохраняется и загружается...
Чет после твоих портянок отмазок я думаю ты просто ищешь причины ничего не делать. То одного не хватает, то другого, то третьего, потом еще десяток найдешь.
>То одного не хватает, то другого, то третьего
В 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) == фикс старого.
>Проще свой движок написать.
Манятеоретика видно сразу. Иди напиши. Регулярно в соцсетях вижу таких героев, у которых "движок" после 5 лет работы не дотягивает до первой кваки и работает исключительно на их собственном железе.
Да с тобой и так понятно, сренькальщик-безыгорник, мог бы не заявлять о себе так явно.
>Проще свой движок написать
До 2019 писал движок, потом сел на Godot и сижу.
>Движок должен упрощать создание игры
Со "своим движком" игры у тебя вообще не будет...
>>1060180
>исключительно на их собственном железе
Если взять SDL и OpenGL 1.0 (как я) - везде пойдёт.
>>1060182
Ты только не путай, это кто-то мимо проходивший.
страдаю от ожиревшего софта на старом ПК
https://godotengine.org/article/dev-snapshot-godot-4-6-dev-4/
Это всё из-за лапши в архитектуре.
Правильно спланированный проект как верёвочная лестница: можно аккуратно тянуть по одной ступени, внимательно изучая и понимая её свойства. "Лапша" запутывает эту лестницу в тугой клубок, в котором становится не разобраться, что и куда уходит.
А что главным образом вызывает лапшу? Доступ к глобальным сущностям из нескольких мест в коде, вместо последовательного спуска и подъёма по абстракциям в проекте. Когда маленькая штучка в непримечательной сцене через запрос к глобально доступному менеджеру вызывает волну сложных изменений по всем направлениям.
А доступ к глобальным сущностям - из-за лени...
>по всему этому говну
Если не надо - не трогай. Это для тех, кому надо.
>где документацию читать
Тебе же дали все ссылки - читай запись в блоге.
Вот отсюда начинай, по потомкам сам пройдёшь:
https://docs.godotengine.org/en/latest/classes/class_ikmodifier3d.html
Про FABRIK давно слышал, популярный алгоритм.
CCDIK3D, лол))))))))
Это для тех, кто делает игры не на движках, либо дорабатывает сами движки
Не только. Там и про игровые механики, про pity системы, про риск/награды, про секреты, сложность, давление таймерами, трейд механики, крафт и все остальное. Ты до конца не долистал.
Да, да, AI slop книга с примерами на gdscript, смотри какая оптимизация на пикче
Ну хуй его, те же выдерки тебе бесплатный дипсик даст
Кое где там встречается код на питоне вместо GDScript, это точно AI слоп книга от хохолорумына судя по профилю на реддите, просит там прощения у зелебобы
Сделал. Намоделил 3д ебалу и сгенерировал по ней тримеш коллижн шейп в годоте. Вроде ок, никто никуда не проваливается.
Если у тебя всё оптимизировано под эти наклоны, то ПРОСТО моделишь спираль с наклоном и ставишь её коллизией (concave/trimesh collision). Единственный недостаток такой коллизии - она полая внутри, но это повлияет только если ты влетаешь в лестницу на сверхзвуковой скорости - да и то, твой персонаж наверняка толще этой лестницы и не застрянет.
Если ступеньки супер-широкие (они обычно шире у спиральных лестниц), то делай прямоугольниками. Наклонная поверхность будет слишком искажать поверхность визуально. Но это имеет смысл лишь с камерой от третьего лица, что в принципе неудобна для перемещения по лестницам в доме, лол.
>влетаешь в лестницу на сверхзвуковой скорости
Точно. Вечный подводный камень. Я сейчас просто перемоделю и потолще коллизию сделаю.
Вопрос в том, если я открою проект в "Godot mono", это сломает обратную совместимость проекта с нормальной версией? На случай, если ничего не получится и я решу откатиться назад или разделить проект на быстрый сервер (компилируемый язык) и тонкий клиент (GDScript). C/C++ уже смотрел, но вообще не разобрался, как их использовать (компилятор уже есть). Python слишком медленный и тупой, а его альтернативы ещё тупее. Думал поиграться с GDExtension на других языках, но он уж больно сложный - я не разобрался...
>>1060471
>потолще коллизию сделаю
Ты не понял сути проблемы. Простая коллизия (сфера, куб, цилиндр, капсула, convex shape) - она как бы "заполнена изнутри", т.е. если ты сделаешь сферу радиусом 100 метров и телепортируешься вплотную к геометрическому центру, то движок должен тебя резко откинуть на поверхность сферы - за 100 метров от точки "столкновения" внутри сферы. А тримеши - это наборы треугольников, расположенные поверх "полой" фигуры. Если тримеш достаточно большого размера, то твой персонаж может в него целиком провалиться и "застрять внутри" - т.е. ты можешь двигаться по внутренней поверхности как по внешней. Треугольники тримеша не имеют толщины, и если ты пробил оболочку тримеша сверхзвуковой скоростью, столкнувшись с обратной стороной - ты застрял внутри. Но в случае с лестницей это вряд ли может доставить проблем, потому что ступеньки по высоте у тебя наверняка мельче роста персонажа - капсула персонажа должна будет выскочить с той или иной стороны (скорее всего вверх ступеньки, ну или вниз, но вряд ли умудрится застрять внутри ступеньки). А вот если у тебя в игре регдоллы из мелких кусочков - у них руки и ноги могут провалиться внутрь ступенек и застрять там...
Кстати, есть ли профит пытаться генерить мультимеши без использования нодов, а с помощью RenderingServer? Много проблем предстоит решить?
enemy.global_position.lerp(player.global_position, delta * shpeed)
>а нахера нужны физические кости
как и всё остальное, для игор, регдол может быть игровой механикой
>регдол может быть игровой механикой
То есть больше физические кости ни для чего не нужны?
>без использования нодов, а с помощью RenderingServer
Только если у тебя так много Node, что из-за них игра тормозит.
>>1060477
>Как вы делаете так чтобы враг следовал за игроком?
Ответ сильно зависит от игры...
>А то у меня враг тупо летит в верх
Без подробностей помочь тут никак не получится.
>>1060485
>разницу между Node2d и control
Потомки Node2D нужны для 2D игр типа: Terraria, RimWorld и т.п.
Потомки Control нужны для GUI в любых играх и программах.
>Если нужна менюшка с кнопками
Control, естественно.
>которые будут кастомизирвоать модельку
Это ни на что не влияет. GUI накладывается поверх 3D графики.
Или ты хочешь встроить GUI в 3D, типа на поверхность шкафа?
>>1060490
>нахера нужны физические кости?
Чтобы кости скелета, например, не проваливались сквозь стены.
>Хотелось бы научиться хотя бы ими владеть. Авось пригодится.
Если не знаешь, зачем они тебе, то они тебе сейчас не нужны.
>Без подробностей помочь тут никак не получится.
Ну вот сам скрипт если интересно - 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
>var velocity: Vector2 = Vector2.ZERO
Чета ты по моему перепутал, анон. Хотя я не знаю, может это такой художественный перформанс.
Тебе нужен CharacterBody2D. У него есть велосити и метод move_and_slide()
Потом просто обновляешь велосити так же, как ты делал тут
>velocity = global_position.direction_to(target.global_position) * speed
а потом хуяк
> move_and_slide()
А вообще лучше всё с нуля перепиши. Хуже тебе от этого точно не станет.
Вот вам и вайб кодинг, пацаны.
Да я пробовал и так и через characterbody и вайб кодил и с ютуба гайды брал - один итог, враг какого-то хуя в другой конец карты от игрока улететь хочет. Ну я забил и просто рандомное движение сделал
>Тебе нужен CharacterBody2D. У него есть
Сначала я тоже так подумал, но потом - если у него в геймплее требуется толпа врагов на пустой карте, как, например, в Vampire Survivors, то CharacterBody2D тут избыточен, только снизит производительность из-за множества лишних проверок. А в жанре RTS - даже Area3D использовать будет избыточным, поскольку выделение мышкой можно сделать намного проще, поэтому все юниты будут потомками голой Node2D.
>>1060516
Я прочитал весь код, и в нём куча всего не совсем... стандартного, но по идее он должен работать. Может, ошибся с настройкой масок коллизий в инспекторе?
Не советую полагаться на LLM - модель может иметь достаточно знаний для генерации правдоподобно выглядящего кода, но она делает это как бы "наугад". Необходимо самому разбираться в коде лучше, чем языковая модель, чтобы использовать результаты эффективно - иначе ты только себе вредишь.
Теоретически нормально кодить могли бы "агенты", способные взаимодействовать с IDE и результатами собственной работы в т.ч. визуально, но пока что технологии недостаточно развиты - они брутфорсят ("бездумный перебор всех возможных вариантов"). Учитывая стоимость токенов - оно того не стоит.
>>1060527
>в другой конец карты от игрока улететь хочет
Попробуй поменять плюс на минус:
>global_position -= velocity
Иногда вся ошибка именно в этом.
Также помни, что ось Y направлена вниз экрана.
>Сначала я тоже так подумал, но потом - если у него в геймплее требуется толпа врагов на пустой карте, как, например, в Vampire Survivors, то CharacterBody2D тут избыточен
Я не видел, чтобы он говорил о жанре, который пилит, а потому отталкивался от дефолтного платформера. Но в любом случае, путь это хоть ареа, хоть голая нод2д, зачем изобретать велосипед с велосити, если можно тупо пододвигать моба к игроку через глобальную позицию? К глобальной позиции можно и анимации прикрутить, и что хочешь
Я не играл в Vampire Survivors, но как я понимаю там мобы просто спавнятся вокруг игрока и в тупую ломятся к нему, а значит никаких навагентов с маневрированиями применять не нужно будет. Лерпай себе позицию да в ус не дуй.
>>1060527
>враг какого-то хуя в другой конец карты от игрока улететь хочет
Значит ты где-то что-то инверсируешь ненароком, как сказал анон выше.
Ну он сейчас просто в другую сторону полетел, он вообще почему-то по диагонали на какое-то расстояние улетает пока не упрётся в конец, потом уже следует за игроком держась такой дистанции
Я кажется понял. Оталкиваясь от того, что ты тут наговнокодил: твой игрок коренную ноду случайно нигде не теряет?
Ты проверь в рантайме где у тебя находится нода, с которой ты снимаешь позицию для переследования. Звучит так, будто ты криво управляешь игроком. Тогда всё встанет на свои места
>отталкивался от дефолтного платформера
У него в коде нет гравитации, так что вряд ли.
>зачем изобретать велосипед с велосити
Лолшто? Velocity - это вектор скорости. Его обычно получают из направления, множителя и дельты. Это обязательная основа для движения разных мобов.
>можно тупо пододвигать моба к игроку
Ну, вот он и двигает через global_position += velocity.
>>1060531
Сделай скриншот "дерева сцены" (scene tree).
Там должно быть что-то вроде этого:
>Game (Node)
>_ Player (Area2D)
>_ _ CollisionShape2D
>_ _ Sprite2D
>_ _ Camera2D
>_ Enemy (Area2D)
>_ _ CollisionShape2D
>_ _ Sprite2D
>_ _ RayCast2D
>_ _ ChaseTrigger (Area2D)
>_ _ _ CollisionShape2D
У тебя как-то так это выглядит или иначе?
Бля, ты прав походу, я её в начальном углу оставил вот враг туда и летит. Правда непонятно почему он потом за помедлькой следует но реально ща проверю
>Лолшто? Velocity - это вектор скорости. Его обычно получают из направления, множителя и дельты. Это обязательная основа для движения разных мобов.
Блять да че ты мне то рассказываешь, аноний? Я тут выдумаю как примитизировать всё в пол, а ты мне про вектор скорости. Если единственный фукционал обьекта двигаться с точки А в точку Б - достаточно тупо двигать его по позиции. Чендж май майнд.
В этих ваших интернетах миддиард мануалов как заставить квадратик бегать и прыгать, но нихуя нет по созданию интерфейсов.
Суть такова. Есть несколько спрайтов. Нужно рисовать одни поверх других. Типа нижний спрайт это голый чел, а верхний это спрайт брони, волос, обуви и т.п. Ну и кнопочки куда сюда. У всего этого должен быть черный задний фон. Как это правильно организовать?
В кооперации с интернотом получился Control, в нем SubViewContainer в нем SubView в нем Sprite2d
Но где там ему выставить черный бекграунд я хз.
Выглядит немного как избыточное говно. Может меня наебали, или я чего то не понимаю?
>В кооперации с интернотом получился Control, в нем SubViewContainer в нем SubView в нем Sprite2d
В кооперации с гопотой небось?
Сделай спрайт2д с голым челом, и по спрайту2д на каждый предмет одежды (ноги-руки-тело). Все это в общую сцену Node2D. По клику на контрол-ноды меняй картинку в спрайт2д для рук-ног-тела. Все.
А лучше туториалы официальные пройди, ты видимо с наскока хочешь все и сразу, не разбираясь.
> В кооперации с гопотой небось?
С чем тока не общался. Даже с ютубом. Но я пока не в курсе как правильно задавать вопросы.
> А лучше туториалы официальные пройди
Где их брать? На сайте вижу только ссылку на доку.
https://docs.godotengine.org/ru/4.5/getting_started/introduction/index.html
Внизу-слева есть переключение версий движка и языка, выбери там свое.
Поясню - тебе как минимум надо вот это все пройти. На 3д можешь забить если твоя игра не 3д.
>нет по созданию интерфейсов
Всё есть. 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" и т.д. зависят лишь от позиции предка.
Т.е. все спрайты можно крутить и двигать как угодно.
Минусы есть, но вряд ли существенные для тебя.
>загеймдизайнить чтобы интересно игралось
Если хочешь пример, гугли "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.
О. Кстати хороший совет, пушто я этой темой никогда не интересовался и думал просто рандомно крутить барабан. Спасибо
>Если хочешь пример, гугли "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
>думал просто рандомно крутить барабан
Типичная ошибка, даже в больших проектах такое встречается. Проблема с рандомом в том, что самый настоящий рандом человек просто не ощущает как "настоящий", и может начать придумывать всякие оправдания, в худшем случае - "разрабы хитрят". Т.е. касается это не только "гачи", "лутбоксов" и т.п., а всех возможных источников рандома в игре.
>>1060577
Там банальности в основном написаны. Про рандом написано очень много, только ленивый не писал про рандом. У тебя по ссылке избыток конкретных чисел и минимум теоретической информации (или ссылок).
Вот это бросилось в глаза, как пример лишних чисел:
>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.
Умный человек поймёт, что числа здесь не следует воспринимать буквально. А какой-то новичок или "интеллектуальный агент" может взять их как есть. Замусорили интернет бесполезной информацией...
Спустя пару месяцев пытаюсь продолжить. Набросал вчера за пару часов механику настройки блоков, влияющих на движение - пока это двигатели и шары. Интерфейс чисто для теста - потом подумаю, что лучше подходит... И знаете, мне настолько понравилось тестировать, что я чуть не забыл записать видео процесса. Хотя фича тривиальная.
Как я к этому пришёл? Изначальная задумка игры, что сохраняется до сих пор - это ограничение по ресурсам и времени и требование двигаться вперёд на корабле, что постоянно разрушается и требует обслуживание прямо в полёте. Много думал о системе строительства, и пришёл к выводу, что хочу, чтобы корабль строился "тяп-ляп", но при этом следовал основным правилам физики - т.е. если игрок ставит двигатель, двигатель физически толкает корабль в точке, где он визуально расположен.
На практике оказалось, что из-за физики такой корабль необходимо строить симметрично, если блоки имеют одинаковые параметры. Но соблюдать симметрию в принципе сложно, а с ограничениями по ресурсам и с постоянными поломками будет совсем невозможно - буквально от выхода из строя одного двигателя весь корабль начинает закручивать. Мне уже пришлось отказаться от мелких деталей в пользу крупных кубов (по другим причинам), но принуждать игрока к абсолютной симметрии совсем не хочется.
Самое банальное решение, доступное в любой такой игре по умолчанию - это передвинуть блок в новое место, чаще всего разборкой и сборкой. Я таким часто вынужденно занимался во множестве игр и мне это совсем не нравится. К тому же, для большей точности блоки должны быть маленькими, а я уже решил, что моя игра будет в первую очередь из больших блоков. А удаление некоторых блоков (шары, например) полностью лишает часть корабля плавучести и это невыгодно игроку, т.к. переделку потребуется выполнять в полёте.
Поэтому я очень долго обдумывал идею автоматически распределять мощности движущих блоков, когда игрок задаёт на штурвале направление и корабль сам решает, какие двигатели на сколько процентов включать, и сам определяет степень накачки шаров газом. На словах это звучит интересно, но реализовать это оказалось намного сложнее, чем я думал, и на практике такая адаптация корабля будет мало чем отличаться от отсутствия правдоподобной физики как таковой: ты просто лепишь блоки и они сами как-то там работают, абстрагируя тебя от интересных деталей реализации движения.
Это привело меня к мысли всё-таки отказаться от правдоподобной физики и просто толкать центр 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
А у вас как успехи?
> А у вас как успехи?
Посмотрел видос про советский тернарный компьютер Сетунь и про то как его варварски уничтожили. Словил дизмораль. Бухаю.
Хуя се ебать, анон. Я бы в такое поиграл. Есть у этого какой-то вайб мультиков про авиацию, где герои балдежно парят над облаками
Почти доделал игру, подготавливаю для релиза в стим.
Как правильно, и нужно ли вообще, указывать лицензии, сноски/ссылки на godot и прочее?
Желательно поподробнее, так как нихуя в этом не понимаю.
Игру планирую именно продавать.
Ничего нигде не указывай. Лицензия годота позволяет делать продукты с закрытым исходным кодом и собственнической лицензией. А большинство игр именно таковы - закрыто, собственническо. Было бы странно, если бы движок запрещал тебе закрывать свой код.
Поэтому ещё раз, ничего нигде не указывай. Отсутствие написанной в комплекте поставки продукта лицензии автоматически означает проприетарную лицензию, которая запрещает всё, что не разрешено. А ты же хочешь запрещать всё? Так ведь? Запуск и проигрывание приобретенного продукта автоматически разрешены самим свойством исполняемого файла. Всё остальное - только с разрешения автора.
Если твоя игра делает простые текстовые файлы сохранения - значит ты позволяешь читерить. Если файлы хоть как-то мало мальски обфусцированы или зашифрованы - то всё, ты уже запретил их модифицировать. Попытки читерить нарушают твою проприетарную лицензию.
Которую, как я повторюсь, ты не обязан даже выписывать. Нет текста = всё запрещено. Есть возможность искаропки продукта = эта возможность разрешена. Автор не знал, что какая-то возможность есть искаропки, но не описал ни в каком тексте, что он запрещает = автор разрешил.
... Но если ты хочешь помочь Годоту в качестве благодарности, то ты можешь прямо в игре указать что игра сделана на Годоте, пропиарить.
Я не в стиме, а на итче, но на итче всегда указываю что на годоте - и в метадате, и в описании. Движок этого не требует, просто для души указываю.
Кстати это еще неплохой пиар ход. В стиме есть кураторы, собирающие игры на годоте:
https://store.steampowered.com/curator/41324400-Is-it-made-with-Godot/
https://store.steampowered.com/curator/45715609-Made-with-Godot-2
>>1060663
>>1060667
Ребята, спасибо! Ёмко, и по делу. Ещё вопрос - да, в качестве благодарности я бы хотел прилепить лого годота в splashcreen при старте игры, но проблема в том что игра у меня 640 на 360, и вся стилистика, в т.ч. шрифты, интерфейс и т.д. жестко стилизованы и пиксельны. Хотелось бы нарисовать свой логотип годота, но как я читал (вполне вероятно что ошибаюсь) этого делать не стоит, ведь логотип как раз таки имеет четкое авторство с указанием того как его использовать.
Стоит и можно и люди делают. Вот например популярный набор фанмейд сплешскринов, обрати внимание на количество звездочек: https://github.com/KenneyNL/Godot-SplashScreens
>Ничего нигде не указывай.
Дурак, почитай реальные условия лицензии 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...
>>1060663
>Движок этого не требует
Как раз-таки явно требует этого по лицензии MIT. И об этом указано и на сайте, и в документации, и на гитхабе, и в приложенных к исходникам файлах.
>>1060659
>Как правильно, и нужно ли вообще, указывать лицензии, сноски/ссылки на 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
Но ничего страшного в этом нет, не парься.
>А как тогда и что указывать..?
Читать умеешь или пока только писать? >>1060677
>Вот здесь варианты указания лицензии на выбор:
>https://docs.godotengine.org/en/stable/about/complying_with_licenses.html
Да бля, я имею в виду, вставлять вот эту копипасту про лицензию MIT? Я в этих лицензиях не понимаю, и боюсь что неправильно вставлять такую лицензию в коммерческий продукт. Потому что не понимаю. Че агришься то епта
В соей игре, в окошко "авторы", можешь в самом низу указать Made with Godot: godotengine.org/license
>неправильно вставлять такую лицензию
Всё нормально. Можно сделать так, например:
>License.txt (в корневой папке игры)
>Copyright (c) 2025 Vasyan & Co. All rights reserved.
>
>Made with Godot Engine: godotengine.org/license
Первая строчка - твоя закрытая лицензия.
Далее - упоминание Godot и его лицензии.
Видел такое в "mixed source" проектах...
>>1060690
Честно говоря, всегда напрягает вот это "в окошке с авторами" - чтобы до этого окошка добраться, игра должна запуститься и показать меню без багов. Теоретически, может быть ситуация, когда кому-то потребуется узнать лицензию без запуска игры... А текстовый файлик доступен на любой ОС даже без запуска игры - достаточно файлового менеджера... В случае Android, APK вскрывается как простой ZIP и большинство файлов там никак не зашифровано.
Т.е. лучше иметь и меню "авторы", и текстовый файл.
>>1060686
>вылетает когда меняю тип ноды
У меня тоже такое случалось, но когда-то давно. Предполагаю, что это происходит в определённых условиях... Ты меняешь тип корневой ноды? Лично предпочитаю сначала добавить нужную ноду как потомка, а потом сделать её корневой. Если это не корневая, то, может, у тебя там @tool-скрипт стоит? Частенько бывают ошибки из-за @tool-скриптов.
Посмотри журнал ошибок, есть ли там что-то. Есть специальный флаг -verbose, выводящий ещё больше информации о том, что происходит. Если это новая версия, желательно сделать баг-репорт на гитхаб.
>всегда напрягает вот это "в окошке с авторами"
На скрине выше пишут что этого уже достаточно. А дополнительные файлы меня напрягают как игрока.
>взяться за генерацию островов
Опять фигня какая-то получилась...
На просадки FPS не обращайте внимания, там очень много лишних нод даже в самых мелких островках, никакого LOD на них нет и оптимизировать можно существенно, но мне было лень этим заниматься. И некоторые острова непрерывно двигаются, хотя с расстояния это практически невозможно заметить. Кажется, основной тормоз - физический движок...
Признаю, было глупо надеяться, что разбрасывание всего десятка моделек по большой площади может дать что-то новое для геймплея... Нужно намного больше ассетов, чтобы их случайное разбрасывание по площади имело хоть какой-то эффект. Но я понятия не имею, что мне нужно в первую очередь, а что может подождать. Самое странное, что когда смотрю на похожие игры - там тоже нет ничего особенного. Ну, типа, вот земля, в неё натыканы палки и камни, иди собирай... и всё? Мне хочется чего-то интересного, но как это должно будет выглядеть на экране - смутно себе представляю.
Наверное, всё-таки нужны острова размером побольше, возможно, на порядок больше текущих (25 м -> 250 м), и собирать их из множества частей поменьше (чтобы они разрушались по частям). Уже пробовал такое и почему-то разочаровался в идее, а теперь вот наоборот думаю - стоит снова попробовать... И нужны ещё какие-то другие модельки - камни, кустики, цветочки. Хотя, так ли уж нужны?.. Не знаю. Никогда не интересовался созданием игровых локаций, поэтому это всё выглядит слишком трудным. Понимаю только что нужны периоды "расслабления" и "напряжения", в частности, более однородные и более выделяющиеся из общей массы участки карты.
Короче. Нужно завязывать с "прокрастинацией через алгоритмы" и заниматься созданием новых визуальных ассетов, потому что из десятка тестовых ассетов никаким алгоритмом не получится сделать разнообразный и интересный мир. Каждый раз забываю об этом и фокусируюсь на бессмысленных в конечном итоге деталях своего кода, потом вспоминаю и мучаюсь от осознания, что вообще не продвинулся к задуманной цели. И я не понимаю, почему постоянно наступаю на одни и те же грабли - уже много лет, между прочим...
А ещё я слишком фокусируюсь на этих статичных декорациях, когда, по идее, я должен ещё и мобов добавлять... В смысле, концептуально это должен получиться оживлённый мир, а не просто кучки безжизненных кусков земли в воздухе. Кажется, с летающими мобами даже с текущим набором декораций было бы не настолько уныло. Но я без понятия, когда именно можно переходить к мобам.
>>1060597
Спасибо.
>Я бы в такое поиграл.
По жанру это "open world survival craft" должна быть. Только до играбельной версии ещё очень далеко (в особенности с тем, как я это делаю по 2 часа раз в несколько месяцев и без чётких ориентиров).
>Есть у этого какой-то вайб мультиков про авиацию, где герои балдежно парят над облаками
Да... На что-то такое ориентируюсь графически. Но пока что это всё плейсхолдеры - не уверен, как это будет выглядеть в более приличном виде. Даже не знаю, делать палитру насыщенной или пастельной - или, быть может, сделать её зависимой от биома...
>>1060596
>компьютер Сетунь
Когда-то давно читал про неё. Очень жаль...
>Словил дизмораль.
Попробуй сделать мини-игру про троичную логику.
>8289Кб, 640x360, 00:02:50
Ахаха, лол, как всегда - удачное превью.
>Попробуй сделать мини-игру про троичную логику.
Уже начал. Уже днём накодил утилиты для конвертации в симметричную СС с любой базой и с подачей на вход преобразования набора символов, который будет это СС представлять, например ++-0-+ в случае троичной. Воот. С утилитами уже начну делать что-то более осмысленное.
Кстати, я придумал тебе обоснование твоего мира. Оно ведь буквально на поверхности лежало, а в треде никто не подсказал. Это кольцо (тор) с амосферой и островами существует, притягиваясь к кольцу (тору) из тёмной материи. И вот внутри этого тора существует тяготение, но выраженного центра масс нет - точнее он представляет собой опять же тор, единичного диаметра, в центре всего торообразного образования. Острова движутся то наружу из центра к краю, то обратно опускаются к центру. В зависимости от нагрева/охлаждения, например. Как тебе такая идея? Обдумой.
В таком случае не нужны костыли с газовыми шарами. Если легкий объект, типа ГГ-эльфийки упадёт с острова, она полетит вниз, но внизу, достигнув центра масс, она попадёт в невесомость, которую пролетит на другую сторону диаметрального сегмента тора. И где-то по пути всё равно попадётся остров или иной тяжёлый объект, за который ГГ зацепится крюком-кошкой.
А тяжёлые объекты в такой системе парадоксальным образом висят, как я описал выше, на своих местах, слегка изменяя высоту, словно покачиваясь на волнах. Потому что чем крупнее объект из химической материи, тем сильнее он взаимодействует с тёмной материей, вся эта локация она как бы внутри огромного пояса тёмных астероидов, которых так много в этом поясе, что они образуют практически равномерный гравитирующий тор.
Научит ли это разработчиков годот делать нормальные сборки своего движка, чтобы они не вылетали?
Друг, большое спасибо за разъяснение, спасибо. Просто абсолютно несведущ в юридических вопросах.
А можно ещё вопрос? Имею ли я право вообще писать "copyright" если ни у каких юристов или в каком-то "авторском бюро" я ничего не регистрировал? Где-то читал что достаточно просто указать своё имя и по закону это уже считается интеллектуальной собственностью или че то такое, но мутная история учитывая что так в законодательстве РФ, а я сам с КЗ, и не уверен что у нас так (читал законы, ничего путного про компьютерное ПО там не нашел). Как с этим быть?
Т.е. если я выкладываю игру в стим от своего имени (или от своего творческого псевдонима например) то она автоматически становится защищена от разворовывания на части для других игр и так далее? Или как это работает.
Заранее извиняюсь если это глупый вопрос.
Копирайт - это не авторское право. Авторское право по факту авторства существует неотделимо между автором и произведением. А вот копирайт, copy, right, издательское право, оно уже регистрируется, перерегистрируется, передаётся, даётся или отнимается.
И вообще, если кратко, то чё.
Я просто выкладываю свою игру, указываю свой ник в авторах, и всё? Больше ничего делать надо?
Если вкратце, о чем говорили аноны, ты просто запихни в ресурсы проекта файл лицензии годота с их сайта. Если доебутся, скажешь, что вот в проект упакован файл, лицензионные требования соблюдены.
https://github.com/godotengine/godot/blob/master/LICENSE.txt - этот файл положи в корень проекта, в настройках проекта добавь полное имя на экспорт, как показано на пикче. И и тем самым будешь соблюдать требования MIT-лицензии.
Экстрасенсы в отпуске, так что сам говори:
1. Какая версия движка? 3/4? Стабильная/dev?
2. Какая ОС/версия Windows? Драйвера новые?
3. Какая видеокарта (Intel iGPU/NVidia/AMD)?
4. В настройках Godot многооконный режим?
5. Рендерер - Forward+/Mobile/Compatibility?
6. Особые приложения/драйверы на фоне?
7. Мышка обычная офисная/геймерская?
Ну и т.д. Кто тебя знает, с чего ты капчуешь?
>абсолютно несведущ в юридических вопросах
Лучше к настоящим юристам обратись, которые разбираются конкретно в авторском праве. Я лишь в общих чертах пересказываю то, что где-то прочитал. Вероятно, где-то ошибаюсь, так что не верь на слово.
Впрочем, ты сам залез на анонимный форум...
>достаточно просто указать своё имя
Вообще не обязательно. Даже если анонимно что-то творческое постишь в интернете (как здесь), то все эксклюзивные авторские права остаются у тебя. Но, разумеется, это не остановит злоумышленника от использования твоих файлов, поэтому игра не
>защищена от разворовывания на части
Даже если ты на каждом ассете напишешь "сделано Василием Пупкиным". Это как с убийством: по закону убивать запрещено, но это не защищает от убийства конкретно тебя, поскольку наказывать убийцу будут после твоего убийства... если твой труп и виновника вообще кто-нибудь сможет найти и доказать вину.
Как это обычно происходит с индивидуалами:
1. Вася Пупкин (ты) публикует свою игру в интернет.
2. Спустя N времени Вася Пупкин обнаруживает (самостоятельно/от обеспокоенных фанатов), что существует другая игра, в которой присутствует подозрительно похожий ассет, который он сделал и использовал только в своей игре и нигде больше.
3. Далее Вася Пупкин может:
а. Лично написать автору той другой игры и вежливо попросить удалить подозрительный ассет или дать материальную компенсацию за его использование. Большинство не хотят конфликтов и могут сразу откликнуться и удалить файлы, но далеко не все. Возможно также, что наш Вася просто обознался.
б. Написать письмо площадке, которая занимается распространением той другой игры: Steam, itch.io, хостинг-провайдер (личный веб-сайт) и т.д. Если это американская площадка, то она должна отвечать на специальный формат, называемый "DMCA notice". Площадка может удалить игру или проигнорировать.
в. Обратиться в суд. Но с этим связано очень много проблем, и в случае проигрыша ты будешь обязан заплатить компенсацию, так что лучше не доводить. Большинство конфликтов решаются до суда. Но если придётся дойти до суда, то тебе нужны материальные доказательства своего авторства - это могут быть исходные файлы, которые ты нигде не публиковал и которые нельзя восстановить из опубликованного. В прошлом часто рекомендовали отправить файлы на оптическом диске по почте самому себе и держать конверт нераскрытым в качестве доказательства...
Стоит ли волноваться по этому поводу? Вряд ли твои ассеты чего-то стоят и кому-то могут понадобиться (в смысле, отдельно от твоей игры, а не как вся игра, но целиком игры редко копируют, это скорее пиратство). Крупные проекты не занимаются таким воровством, поскольку им не нужны судебные разбирательства. А мелкие воришки - это какие-то школьники, у которых наверняка ничего не получится даже с ассетами. Если крупный проект что-то у тебя своровал - это с шансом 99.9% вина одного наёмного работника и владельцы компании должны отреагировать в твою пользу.
Главное - это чтобы ты ничего ни у кого не воровал. Поскольку, хотя Вася Пупкин вряд ли сможет тебе навредить или даже узнать о тебе, крупная компания обязательно о тебе узнает и накажет так, что мало не покажется. Особенно если игра принесёт деньги и популярность с этим ворованным ассетом. Не бери случайные ассеты из интернета, даже если тебе по каким-то причинам кажется, что они "ничейные" (опубликованные анонимно/от имени "Васи"). И с нейронками по этой причине лучше не связываться (проблемная тема - нейронки могут выдавать куски защищённых копирайтом данных, а ты никак не определишь на глаз, где сгенерировался подвох).
Особенно касается музыки. В музыкальной сфере издательства (лейблы) очень агрессивно защищают собственные права на музыку, которую им отдают музыканты. Т.е. сами музыканты получают от них определённую зарплату, а лейбл распространяет и защищает права. Они давно автоматизировали весь процесс поиска и наказания за нарушения АП. Даже "бесплатная и свободная" музыка может оказаться подставой от какого-нибудь паршивого лейбла. Т.е. желательно не юзать случайную музыку из сети.
Но прикол в том, что в других сферах такого нет или практически нет. Т.е. ни Steam, ни издатель игры не будет бегать по сети и искать обрывки твоей игры в случайных местах. Даже сам Steam может случайно разрешить публикацию ворованных ассетов - были прецеденты. Конечно, Steam откликается на DMCA, однако, DMCA может отправить только сам автор (официальный представитель автора), а для этого необходимо сначала найти, кто у тебя своровал. А площадки типа itch.io имеют слабую модерацию - постоянно публикуется сомнительный контент...
Хуже всего дело обстоит с кодом. Если визуальные материалы игра показывает на экране как есть, то определить авторство кода игры без "взлома" не представляется возможным. Декомпиляция игры является нарушением закона, поэтому обвинением в ворованном коде ты, по сути, подставляешь себя. Спасает тут то, что твой говнокод в скриптах будет бесполезен практически любой другой игре, т.е. код копировать у тебя вряд ли будут. Чаще всего воруют платные аддоны с маркета - т.е. скачивают что-то с торрентов вместо честной оплаты лицензии, т.к. эти аддоны рассчитаны на множество разных проектов.
А лучше всего не париться и делать open source игру.
Уже 3 раза кидали:
>>1060677 >>1060680 >>1060682
В предыдущих тредах тоже было...
Крути солнце по таймеру - раз в секунду или реже.
Основная проблема с солнцем - не тени, а небо, т.к. перемещение солнца вызывает сброс кэша. Можно уменьшить разрешение скайбокса, чтобы он быстро отображался, но тогда появится дырочка в зените. Возможно, ты её не увидишь, если игрок не может поднимать камеру вертикально вверх.
Ночью солнце отключай. Если есть луна, то её тоже отключай в дневное время. Иначе будут артефакты и потеря времени на бесполезные отрисовки. Это очевидное, но я как-то не сразу догадался.
Как минимум на Godot 3.x огромная сфера с простой градиентной текстурой показалась мне дешевле по производительности, чем встроенный скайбокс, но, возможно, я что-то не понял или перепутал. У меня не получилось хорошо разобраться в шейдере неба.
На видео 2 гигантских сферы: само небо + звёзды (прозрачная текстура), плюс сфера-солнце и луна. Почему-то такая штука была быстрее шейдеров. Рассветы и закаты - это изменение градиента по отдельным двум градиентам через GDScript, лол.
Чел. На кубические закаты никто любоваться не будет. Либо ты даешь гарфон без геймплея, либо кубы с интрересным геймплеем.
>но тогда появится дырочка в зените. Возможно, ты её не увидишь, если игрок не может поднимать камеру вертикально вверх.
Просто на дырочку надо ебалу любую вешать, вроде лица, ануса или кровяки, и вот вам хоррор заодно.
Отставить пиздежь! Я всегда засматривался на закаты в майнкрафте
>всегда засматривался на закаты в майнкрафте
Майнкрафчую, есть в них что-то такое приятное.
>>1061015
>никто любоваться не будет
Видео больше 3 лет, а я до сих пор любуюсь...
>либо кубы с интрересным геймплеем
Да, я планировал геймплей, но не получилось.
>>1061017
>Просто на дырочку надо ебалу любую вешать
Теоретически можно, но это всё-таки костыль.
А причина дырки - в странных координатах...
Дай код на питоне, только не копипасти, сделой скрин или на пастосайты ссылкой.
Вот тебе полностью рабочий код.
https://pastebin.com/gYAQVrga
Сделай так, что бы на ГД скрипте так же можно было.
От така хуйня у тебя? Тока так
>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)
https://pastebin.com/LVjYc2PD
Если бы все было так просто.
Если запустишь питоновский код, то увидишь, что цвета нихуя не совпадают.
Если перед show добавить строку
img.info['transparency'] = 0
То вообще спрайт приобретет альфа канал. Не смотри на мыло, это косяк просмотрщика и его попытки в шакалов.
Я делал что то похожее как у тебя и получал нужные формы, но с какими угодно цветами кроме те, что в палитре. Пока так и не понял где я хуй.
https://pastebin.com/Bi9EibFA
ну на, с прозрачностью и нужными цветами
просто твоё "как в питоне" не робит, у тебя формат - индексный, внутри годота есть импортеры которые его перекодируют но потом он отсутствует в Image
Шакальство - фильтрация текстур, на пиках варианты
Вообще похоже на то что я делал. Сейчас провеить быстро не смогу.
Подскажи еще. Почему иногда я после ретурна получаю нормальный объект Image напрмиер, а иногда EncodedObjectAsID
Не сталкивался, вероятно потому что я указываю типы переменных и возвращаемые значения функций,попробуй указать
Лол, Хуан реально в Буэнос Айресе живет, надо будет навестить его
А ты я смотрю компанейский пацан. Даже мысли в голове не возникает, что ты можешь быть нахуй не нужен посторонним людям. Навестит он, блять.
Хуан, спок. Будем игры вместе делать, я тебе идеи, а ты мне код и арт. У меня гениальные идеи, вот увидишь.
Все получилось. Спасиба. У меян почти такой же код тоже хуйню выдавал. Но я не Color а просто байты пихал. Хз в чем там внутри разница.
Даже уборщики смогли игру релизнуть, а вы тут все сидите-пердите, безыгорники.
https://store.steampowered.com/app/2159270/Kingdoms_of_the_Dump/
> started in 2016
> Дата выхода: 18 ноя. 2025 г.
Ты лет через 9 заходи
Зачем? Тут и месяца достаточно чтобы мотивацию потерять. 9 лет осилят пилить единицы.
Попробуй для начала документацию почитать:
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)
Откроешь для себя много нового.
Так я и почитал. Там написано, что есть insert
Тут какие то вещи один в один как в питоне, а другие вообще не похожи. С массивом уже разобрался.
Ты мне лучше скажи, как так получилось, что движок не может прочитать gif картинку? И как быть, если прочитать все же надо?
Нашел какой то ассет, но он для анимированных гифок, а мне просто статичную загрузить надо.
>ы мне лучше скажи, как так получилось, что движок не может прочитать gif картинку? И как быть, если прочитать все же надо?
Я бы забил хуй и разобрал на кадры. Без рофла
>Ты мне лучше скажи, как так получилось, что движок не может прочитать gif картинку
gif изначально проприетарный формат по патенту, его много где не любят, если статичная картинка сам конвертируй, если анимация, то наверняка есть gif2spritesheet сервисы
GIF неиронично ненужно. Если твоя гифка больше к видосу - используй mp4, если к покадровости - делай набор статики и пихай в animtedTexture. Даже эта ваша телега не хочет работать с гифками и под-капотом в мп4 их конвертит. Когда гиф умрет всему интернету станет лучше.
> нормальный способ заменить значение в массиве по индексу
>>1061247
> Попробуй для начала документацию почитать
>>1061250
> Так я и почитал.
Я мимопрочитал дискасс и подметил, что молодёжи засрали мозги иммутабельностью. Теперь все данные молодёжь воспринимает как иммутабельные, и даже представить себе не может, что в массиве можно заменить значение по индексу без особых заморочек, напрямую.
Как там с прикручиванием рекламы и микроплатежей?
видрандом
> gif изначально проприетарный формат по патенту, его много где не любят
Что это значт для конечного пользователя? нужно будет кому то отчисления с игры платить или что?
Если хочешь делать большой бизнес на мобильном рынке, то используй трёшку. Там все необходимые модули и ассеты уже имеются.
Настолько всё нестабильно? Когда обещают новую стабильную версию?
Значит что твои проблемы - это твои проблемы
>Ты мне лучше скажи, как так получилось, что движок не может прочитать gif картинку?
По словам Хуана (никнейм reduz на github, один из двух оригинальных авторов), в ядро движка должно попадать только то, что абсолютно обязательно или имеет достаточно большой спрос. Поэтому гифки предлагается поддерживать через кастомные модули, если кому-то это вообще нужно.
>И как быть, если прочитать все же надо?
Использовать кастомный модуль или конвертировать в более подходящий формат. Для больших анимированных картинок лучше всего подходят видеоформаты (они на порядки лучше сжимают информацию о кадрах без потери качества, и декодинг проще), для пиксель-артовых анимаций можно сгенерировать спрайтшит как это делалось во всех классических играх на приставках. В видеопамяти видеокарты все кадры в любом случае будут занимать "плоскую" память без кадров, поэтому хранить необходимые тебе данные конкретно в GIF смысла нет. Смысл поддержки GIF может быть только если ты делаешь веб-браузер, который отображает страницы с GIFками.
>мне просто статичную загрузить надо.
Конвертируй эту картинку в PNG, в чём проблема?
>>1061267
>gif изначально проприетарный формат по патенту
>>1061358
>нужно будет кому то отчисления с игры платить
Все основные патенты просрочились в 2003-2006 годах, поэтому базовая реализация без улучшений алгоритма сжатия доступна свободно и не накладывает никаких ограничений на твою программу. Просто GIF - один самых древних форматов (80-е) и имеет массу недостатков и ограничений, из-за которых сегодня его использовать имеет смысл только для совместимости с древним софтом.
За все годы существования GIF изобрели десятки разных форматов для анимированных картинок, но они практически нигде не поддерживаются нормально. То есть спецификация на формат есть, создать картинку можно, но с большой вероятностью эта картинка не будет отображаться как ты этого ожидаешь в большом числе программ для просмотра картинок и веб-браузеров. А в играх вообще не нужны анимированные файлы как таковые, потому что игры не предназначены для просмотра случайных файлов с диска пользователя (кроме редких случаев поддержки модов).
>прикручиванием рекламы и микроплатежей
Если тебе нужно по-быстрому слепить ассето-помои для выкачивания бабла из наивных детей и тупых домохозяек на максимально большом количестве мобильных устройств, то можешь обратно выкатываться в свой движкосрач-тред, из которого ты подскочил кабанчиком.
Godot - движок для независимых деятелей искусства, а не для эффективных подскакивателей кабанчиком.
Художник должен быть голодным...
>>1061360
>используй трёшку
>>1061361
>Настолько всё нестабильно?
На твоём бомжефоне игра на Godot 3.6 запустится с вероятностью 90~95%.
>Когда обещают новую стабильную версию?
Godot 3.x находится в режиме "LTS", что значит, что новые версии выходят лишь благодаря силам полутора энтузиаста, и рано или поздно эти силы окончательно иссякнут. К тому же, там нет многих важных улучшений quality of life разработчика игры (т.е. тебя).
>Godot 3.x находится в режиме
а смысол? щас всё под 4-ый уже и курсы и книги..
Где вы храните динамические объекты игрового мира? Я имею ввиду выпавшие предметы и всякую хуйню, которая имеет свойство пропадать, спавниться и перемещаться? Сначала я держал отдельную ноду в корне, типо "Physical Objects". Но потом понял, что в этом совершенно нет смысла и начал дропать дроп и партиклы тупо в корень сцены локации.
Да жесть ваще. Я за прошедшую ночь буквально таки ПРОРЫВ совершил. Добил механику, которую очень долго боялся трогать даже палкой. Еще дня 3-4 буду отходить и потом опять ка-а-ак прорву что нибудь!
>Игры делаете
Увы, нет. Меня затянуло в Elin (рогалик-RPG).
Забываю запостить видео: >>1060711
>по идее, я должен ещё и мобов добавлять
>это должен получиться оживлённый мир
В общем, вечером 18-го я накидал пассивного моба - парящую в воздухе медузу (похоже ведь?), и ещё реализовал набросок бинокля. Всё это - лишь через встроенные ноды Godot, ничего извне не брал. Мне кажется, получилось даже лучше, чем я ожидал; пересматривал своё видео уже несколько раз и размышлял о том, что было бы неплохо сместить геймплейный фокус на "наблюдение за жизнью"... Наверное. В любом случае нужно побольше мобов, побольше размером острова и прочий контент...
Но после этого ни разу не открывал проект за всю прошедшую неделю, т.к. не знал, что мне делать, и затянулся в Elin, где куча интересного и довольно казуальный геймплей (в сравнении с рогаликами).
Теперь хочу свою 2D RPG... Как перестать хотеть?
>>1060714
>придумал тебе обоснование твоего мира
Спасибо, конечно, но не стоило... Я не уверен, что получится в конечном итоге, но оно должно быть основано на геймплее. Притянул этот "тор" из-за замыкания двух осей координат, а не наоборот. Обосновывать "игровые условности" не нужно...
Это просто физика такая - фэнтезийная. Никто не задаётся вопросами, откуда фэнтези-магия берёт огромное количество энергии в нарушение ИРЛ физических законов, верно? Вот и здесь тоже так.
>не нужны костыли с газовыми шарами
Но это не костыль, а основной геймплей, лол. Если отказываться от газовых шаров, то это будет уже совершенно другая игра, которую я не буду делать. Воздушных шаров должно быть много на одном дирижабле, чтоб контролировать подъёмную силу и справляться с неполадками в полёте. И вот эти "неполадки" тоже очень важны для геймплея. На записанных мной видео нет и 1% геймплея, лол.
>пролетит на другую сторону
Аналогично - тогда это будет совсем другая игра. Пролететь на другую сторону геймплейно нельзя, поскольку все объекты уничтожаются на какой-то определённой высоте под облаками. Это должно стимулировать игрока поддерживать дирижабль в работоспособном состоянии, а не просто прыгать.
Короче, ты думаешь совсем не о том.
Но спасибо за попытку помочь.
За мной мои разрабы!
увидел, конвертируют чинят, статус на пикрил
эта хуйня скорее всего сломает все плагины которые добавляли вниз редактора свои панели типа генератора земли, генератора звуков fxr и т.д., имейте ввиду
> имейте ввиду
Исключите любую возможность случайного запуска проекта на непроверенной версии движка. Используйте годот-менеджер.
>В 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-версии? Не смеши нас...
В следующий раз постарайся троллить более утончённо.
>Описанный тобой баг починили уже три дня назад.
У тебя в штанах коричнево. Я взял последний коммит и собрал.
Поясни за release 4.5 и 4.5.1 и 4.4 и 4.4.1
>Godot 4.6 не существует официально.
Вот тут кстати верю, 4.6.1 будет существовать, а release 4.6 будет сломанным rc
>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
Можно как-то отрубить экспорт некоторых плагинов?
>редактор/экспорт/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
Я спросил ИИ-ассистента вместо тебя.
Например анимации в процесс происходят, хз, надо проект смотреть, Process это не то что ты написал в _process а как раз всё что не касается физики, например _input
Это Forward? Попробуй удалить кэш Vulkan pipeline. Он автоматически создаётся в папке "user://" для каждого отдельного проекта. Иногда может содержать ошибки, которые приводят к странному поведению рендерера. Пофиксить нельзя - это binary blob из GPU драйвера, создающийся уникально для твоего компьютера.
"Process" Godot - рендеринг кадра в первую очередь.
>No "x86_64" library found for GDExtension
В настройках экспорта попробуй исключить папку:
>res://addons/godot-git-plugin
Но я не уверен. Никогда с таким не сталкивался.
Тебе этот плагин нужен для чего-то в редакторе?
Некоторые плагины вообще не нужно "включать".
У меня эта лесенка ещё в главном меню начинается. Там вообще никаких процессов ещё не происходит, кроме двух плейсхолдерных кнопок на сигналах.
>>1062017
Попробовал. Не помогло. С учетом пустого главного меню - наверное дело не в рендере
>пустого главного меню - наверное дело не в рендере
Vulkan инициализируется на старте проекта и юзается буквально для всего. Стандартный GUI тоже в Vulkan рендерится. Баг в пайплайне влияет на всё в целом.
Ладно. А почему 4.6.dev3? Это нестабильная версия, которая ещё и просрочена уже. Бери 4.5 stable для полноценной разработки. А проблемы с 4.6.dev иди докладывай в issues на GitHub - пусть разбираются.
Эта проблема у меня еще с 4.4 тянется. Я просто забивал, до этого момента.
Кеш вулкана почистил - результата не дало. Хуль ты мне еще сделать прикажешь с ним?
>У меня эта лесенка ещё в главном меню начинается
Синглтоны в автозагрузке может чё та делают
Хз, попробуй поэтапно:
1) закрой проект и переименуй папку .godot в ппапке с проектом
2) во вкладке Profiler нажми Start и посмотри на что время идёт, поставь галочку на Script Functions если там будет что то
3) В 4.6 есть новая вкладка там же внизу типа Object monitor там надо нажать Dump и можно посмотреть что за объекты созданы в игре вообще
Синглтоны проверил. У меня там по сути только развертка сцены и переменные. Я не по синглтонам.
>закрой проект и переименуй папку .godot
Не помогло
>во вкладке Profiler нажми Start и посмотри на что время идёт
пикрил. Процессов нету. Это главное меню
>Object monitor там надо нажать Dump и можно посмотреть что за объекты созданы в игре вообще
Обьектов во мне дохуя, так как я предзагружаю все ресурсы при запуске. Да только они неактивны и хранятся как PackedScene
Подытоживая: С учетом ощущения плавности в рантайме я уже склоняюсь к тому, что это какие-то условные служебные прерывания и так и запланировано
Гадать можно бесконечно. Лучше потрать время на https://docs.godotengine.org/ru/3.5/development/cpp/using_cpp_profilers.html
Профилировщик точно покажет функцию-виновника пропуков, что может дать полезную информацию о том, что в твоем (или не твоем) коде к этому приводит. Помни - у годота очень жирный апи-мост, который любит срать в память. Возможно у тебя много вызовов платформенного апи, которое возвращает словари или что-то в этом духе, в конце концов вину драйвера тоже никто не отменял.
>*Только щас заметил что справка 3.5, переключись на свежую
Ну тогда создай пустой проект новый с пустой с сценой и запусти, если там так-же - проблема в драйверах.
Если нет, скопируй свой проект в новый и начинай удалять из него куски пока не пропадёт такое поведение.
>Хуль ты мне еще сделать прикажешь с ним?
Можно попробовать обновить драйвер GPU...
А ты на C# пишешь или чисто GDScript?
У C# сборка мусора как-то так и работает.
>>1062051
>>1062054
Короч спок. У меня даже визуальная новелла ту же херню выдает. Торжественно забиваю болт. Не настолько ровно, но всеравно скачки ебейшие до 50мс аж. При том что там вообще со стороны моего кода АФК режим и всё только по сигналу лкм происходит
Всем спасибо за участие.
>всё только по сигналу лкм происходит
О, кстати, мышка-то геймерская небось?
Проверь частоту опроса мыши:
125 Гц - ок, хватит для всего.
250 Гц - должно быть норм.
500 Гц - проблематично.
Но с 50 мс ты должен видеть 20 FPS на графике.
Не, я не гоймер. 120 фпс с выключенной синхронизацией (я сразу начал думать на нее, типо это ожидание некст кадра). Плавность геймплея совершенно отличная. Потому я сразу и удивлялся этой лесенке. Так как во всех остальных играх та же херня я хотел бы убедиться. Запрашиваю скриншот у анона. Покажите как должно быть
>Покажите как должно быть
У меня - ровная горизонтальная линия.
Все просадки из-за моих действий в игре.
>Так как во всех остальных играх та же херня
В каких "остальных"? Вообще в любых играх?
Причин может быть много. Проверь:
- что компьютер в целом не перегревается;
- что у блока питания стабильное напряжение;
- что ОС установлена и работает правильно;
- что есть актуальные/стабильные драйверы;
- что нет на фоне тяжёлого процесса/вируса;
- что игра не скачет по ядрам CPU (AMD x3D);
- что игра использует видеокарту, а не iGPU;
...и так далее? Много чего может быть...
>Игра не будет тормозить у пользователей?
Это от тебя зависит, а не от движка
1) физика говно говнище, хотя вон в анриле тож говно.
2) есть проблемы со светом.
но фпсы энивей сложно создавать, их прям надо с умом делать, любой странный мув разраба может загубить производительность.
плагины были - MTerrain и HTerrain вроде, наверняка ещё какие то
>Hammer
Задолбали с этим говном из начала 90-х, оно хоть бы на Windows 7 запустится? Или Windows XP нужно накатывать? Или вообще Windows 95? Я не следил, но когда последний раз смотрел его скриншоты - интерфейс был приблизительно как у Windows 95. Ньюфаги не знают, олдфаги не вспомнят...
>немодульный подход
>уникальные интерьерные пространства
+150 ГБ ассетов в игру, продолжай делать "уникальные интерьеры" вместо игр. Или там имеются в виду пиксель-арт графика, где одна текстура 32x32 пикселя тайлится на весь уровень, а все коридоры под строго прямыми углами? Там вообще можно сделать что-то круглее куба, или это недостижимые технологии для инструментов тех лет?
Алсо, импорт из Hammer в Godot был уже много лет назад.
А Half-Life 3, если и будут делать (вряд ли), то на Source 2...
>>1062148
>слышал что годо так себе для 3д игр
Информация устарела на несколько лет. Godot 4 очень даже хорош для инди 3D.
>Вы бы стали делать динамичный фпс в годо?
Да, вполне нормально, если делать с умом. Не рекомендую 3D для ньюфагов.
>Игра не будет тормозить у пользователей?
Зависит от того, делаешь ли ты с умом, или чужие ассеты флипаешь на сцену...
>>1062164
>1) физика говно говнище
Уже давно встроили Jolt, который лучше Bullet, который был встроен в Godot 3. А Bullet как минимум в прошлом очень сильно использовался Rockstar в разных версиях GTA - то есть он всегда был хорош, но в последние годы его забросили и чаще всего используют только в симуляции робототехники. Jolt же разработан специально для игр в реальном времени, а не для строгих симуляций. Встроенный "Godot Physics 3D" никто всерьёз никогда не использовал и его планируют вообще удалить из движка.
>2) есть проблемы со светом
Проблем нет, если правильно настраивать тени. Тени реализованы стандартным способом для всего современного геймдева и их проблемы широко известны - имеются в любой игре на любом движке, кроме некоторых очень древних игр. Просто в Godot странные параметры по-умолчанию.
>но фпсы энивей сложно создавать
Проще "шутера от первого лица" может быть только "симулятор ходьбы", лол.
>любой странный мув разраба может загубить производительность
Что ты имеешь в виду? Больше 100 врагов в одном узком коридоре?
>>1062218
>Как сделать террейн
Выбирай, что тебе понравится:
https://godotengine.org/asset-library/asset?filter=terrain
Свали нахуй отседова в срачезагон, блядь. Репорт.
>HTerrain
Кстати запилю отзыв на эту хуйню.
Сам класс HTerrain оче паскудит фреймтайм, потому что обновляет все чанки каждый блядь кадр, да и не только чанки. Я не вникал, но его process() вызывается по 500 раз на кадр и вроде как именно чанки и обновлял, при том в самом коде закомментировали, мол "не трогать!". исходя из поверхностного взгляда на код. Мэш он экспортировать не позволяет нормально. Можно только сгенерить меш и через внутреннюю годот экспортировалку его извлечь в .глб. При этом теряются все цвета вертексов и любые данные кроме самого меша. Потому сам по себе он неюзабелен, и для экспорта, как оказалось, тоже не годится.
Кстати, если кто-то им пользовался и пояснит мне как все же извлечь эти цвета - буду очень признателен. Мне сейчас это как-раз очень не помешает.
>Проблем нет, если правильно настраивать тени. Тени реализованы стандартным способом для всего современного геймдева и их проблемы широко известны - имеются в любой игре на любом движке, кроме некоторых очень древних игр. Просто в Godot странные параметры по-умолчанию.
Можна об этом поподробнее? Я с задачей нормальной настройки теней обосрался со свистом. Мне бы универсальный гайд как сделать красиво. Все на что хватило меня это расширить карту теней до 8к и безрезультатно подергать сплиты и бивис
Если я правильно помню, мне это сильно помогло:
https://docs.godotengine.org/en/stable/classes/class_light3d.html#class-light3d-property-shadow-reverse-cull-face
Решило большинство проблем (и добавило новых).
Если у тебя тени от SpotLight3D (тени OmniLight3D не рекомендуется использовать без крайней на это необходимости), то там влияет ширина конуса. Как понимаю, лучше держать его относительно узким - примерно от 90° и выше тени сильно деформирует.
Shadow bias помогает, но зависит от всех остальных настроек, положения света, формы мешей и т.п. Т.е. универсального значения для него (вроде бы) нет.
Размер карты теней влияет на детализацию/блюр. "Теневое акне" будет проявляться даже с высоким разрешением теней, но помельче размером, за счёт меньшего относительного размера текселей карты.
Гугли "shadow acne" - от движка эта тема не зависит.
Всмысле сегодня? Я думал на нг будет логичнее.
Я тоже думаю к НГ выпустить. Но не уверен что это уместно.
Наконец-то удалось скомпилировать 4.6 из master в x64 без SSE4.2.
Официальные x32 сборки вообще не запускались, а теперь работает.
Подводные камни:
- По-умолчанию требует DirectX12, а для него нужен отдельный SDK;
- Проекты по-умолчанию в настройках выбирают DX12 для Forward+;
- При компиляции без DX12 редактор не может открыть проект...
Пока что выход в том, чтобы ручками поправить настройки:
>[rendering]
>rendering_device/driver.windows="Vulkan"
Тогда работает как раньше, на вулкане.
>>1061934
У меня такой проблемы нет, пикрил. Перекомпилируй редактор.
Завтра срок сдачи. Но не игр.
РКН блочит во все стороны еще со времен гонений на телегу. Гуглить любую техническую инфу и наткнуться на блокнутый сайт - обычное дело.
>Jolt же разработан специально для игр в реальном времени, а не для строгих симуляций.
Для контекста - помимо известного всем Хорайзона вот эти чюваки используют Джолт.
Сейм, тоже перестало работать. Какого хуя? И где мне теперь документацию смотреть?
Еще спроси как на итч выкладывать или как гайды на ютубе смотреть.
Спрошу. Потому что "ыыыыыыыыы я поставил виннипуха у меня всё работает ламеры сасите)))))))" в перспективе отъебнет, как начали ебать влесс+реалити на прошлых выходных или просто баны хостеров впсок раздавать направо и налево, поэтому это очень хуево.
Плюс слово-из-трех-букв не поможет заработать на геймдеве и получить свои копейки в РФ. Что поделать. Ну, кроме этого только трактор. А про хостеров - не надо брать популярных, до сих пор хуею с количества долбоебов, хостящихся на ае, просто везде они, блять.
>com
Надо орг, братан, мы же опенсорс и все дела. Не разделегировали, просто айпишники в бане.
Примечательно, что этот персонаж 20 лет назад точно так же провоцировал окруающих на RSDN. Годы идут, а люди не меняются к лучшему..
Видишь такая РЕКЛАМА прочно оседает в памяти людей. Значит эффективная! =)
>И где мне теперь документацию смотреть
https://github.com/godotengine/godot-docs
качаешь, распаковываешь, заходишь в папку и выполняешь команду
> python3 -m http.server
дальше в браузере открываешь http://localhost:8000/
>просто айпишники в бане
причём айпишники cloudflare, а не годота, периодически работает просто так, через анти-дпи работает всегда
>почему ещё никто не собрал в единый chm-файл?
Потому что никто кроме тебя не пользуется Windows 95 более
у меня работает chm на виндоус 10
а сейчас какие форматы используют?
ну так chm это и есть html собранный в один файл
какие сейчас альтернативы есть?
Качать надо по ссылкам которые подчёркнуты на пикче в >>1062724
А ты скачал репозиторий
>>1062770
Не знаю, такие вопросы не интересуют особо никого года с 2012, chm решал ряд проблем браузеров тех лет, когда они не могли определить ссылку на локальный файл прописанную в в файле .html
Ебанько
Блокируются ипшники клаудфлера, которые связаны именно с Годот
Ты же не на все сайты с клаудфлером не можешь зайти?
>Ебанько
Ты бы попродержал коней, малолетний долбаёб
https://2ip.ru/domain-list-by-ip/104.21.36.120/
скамерские сайты хохлов и наркош благодари за блоркировки и клаудфлар за то что не смотрит кому продаёт "защиту" от дудоса
Что такое, опять в этих наших интернетах мошенники? Ну все, перекатываюсь в МАКС, там безопасно.
Кто-нибудь смог настроить пост-процессинг в Godot 4.4+?
Что нужно:
1. Чтение из depth-текстуры, доступное только в spatial-шейдере.
2. Чтение пикселей с экрана и запись новых пикселей на экран.
И желательно после всех прозрачных материалов, если можно.
Проблемы:
1. Quad рандомно перестаёт отображаться даже с custom AABB.
2. Quad иногда рисуется ДО прозрачных, а иногда ПОСЛЕ них.
3. Вариант с CanvasItem не сработает из-за отсутствия depth.
Как это решать? Без отдельного SubViewport никак?
>ставишь Unity
Несколько раз пробовал - там слишком сложно.
А с Godot всё легко даётся. Кроме шейдеров...
>делать как надо
Кому надо? Мне не надо на Unity - я не кабан...
>Чтение из depth-текстуры, доступное только в spatial-шейдере.
не знаю в чём проблема, пример чтения депт текстуры есть в https://docs.godotengine.org/en/stable/tutorials/shaders/advanced_postprocessing.html
>пример чтения депт текстуры
>void vertex() { POSITION = vec4(VERTEX.xy, 1.0, 1.0); }
Именно это и пробовал использовать - мерцает/ломается.
Такое ощущение, что у меня что-то неправильно настроено...
Не уверен, вроде этот абзац как раз затрагивает вопрос пропадания квада. Помимо того что квад должен быть чилдом камеры рекомендую установить какой то
> extra_cull_margin
таким большим как это возможно, может это поможет
Я уже пробовал:
- ставил 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
При некоторых углах поворота камеры исчезает...
даже не знаю, накидал по статье сцену, поставил вращение камеры, всё работает без customaabb и cullmargin, шейдер брал из комментариев внизу страницы, версия 4.5.1
Нормально удалять ноду с queue_free(), всё что потом - твои косяки
> вот удалил я ноду с помощью queue_free()
Кью - это очередь. Ты не удалил, ты поставил в очередь на удаление.
> проверяю if нода == null ладно понятно пока сборщик мусора не отработал объект не нулл, окей
Штоблять? Нет никакого сборщика мусора. Ты фрейм подождал? Нет. Все очереди выполняются в конце фрейма. В том числе очереди удалений. А сборщика мусора никакого нет.
> добавляю проверку and is_instance_valid(нода) и при обращении к ноде иду нахуй с previously freed instance при этом is_instance_valid() то срабатывает то не срабатывает и что с этим делать непонятно
Фрейм подождать.
> пытался ещё добавить проверку собственного флага and нода.is_freed, но тут же выбивает ошибку что нода освобождена, хотя только что предыдущая проверка выдала что она валидна, ебанный рот этого гудота
Конечно, ты же фрейм не подождал.
> ебанный рот этого гудота
Сейчас господин модератор направит тебя в твой срачезагон, из которого ты выпал недоносок, будешь там рота и жопота ебат вместе с остальными мартышками. Репорт.
>Сейчас господин модератор направит
неадекватных фанбоев надо банить наравне с неадекватными хейтерами
это выдаёт в тебе того, кто никогда толком не работал ни с чем техническим
настоящий инженер знает, что если не назвать пропавшую отвёртку "сукой", то она не найдётся. а без трёхэтажного мата вообще ничего работать не будет.
Ты чет там хуйню наговнокодил и сам в ней утонул. Если лень переделывать - попробуй free вместо q_free - освобождает без очереди. Но лучше разгреби свой кал и переделай.
Там вроде ошибку выдаст что нельзя делать free объектам которые refcounted
4.6 dev 5, D3D12 по дефолту на винде, "массивные оптимизоны 2д рендера" и что-то для ВР, хуй его знает.
>Фрейм подождать.
Пасиба.
А как его лучше подождать, понятно что можно по делте поставить чтобы не каждый тик обработки происходили, но чёт это не выглядит надёжной стратегией.
>>1063038
>Ты чет там хуйню наговнокодил и сам в ней утонул.
Лучше и не опишешь.
Ещё вопрос на 4.1 forward+ работает на интло вёдрах, в следующих версиях уже не хочет можно ли как нибудь и шейдер съесть и на новую версию сесть?
Понятно что для событий по другому никак, но я часто вижу организацию кода через создание собственных сигналов.
Делать через сигналы/ивенты практика на всех движках или только у годота?
Это общеизвестный с 70х годов шаблон проектирования. Помимо Годота на сигналах написано буквально всё ПО с которого ты сейчас пост написал. Виндовсы, макоси, линуксы, браузеры, всё современное ПО сегодня является event-driven. Просто в линуксах их переименовали в сигналы, а вообще это ивенты. А Годот пошёл ещё дальше, назвал ивенты сигналами, а часть ивентов, касающихся инпута оставил называться ивентами, и навесил на них отдельную логическую обвязку.
> кажутся спаггети кодом
Хуяжутся.
Чел, я прям явно упомянул момент что для инвентов ивенты необходимы. У тебя удержание контекста как у рыбки?
Одно дело модель событий - другое дело когда чел дергает другую ноду не напрямую, а создавая кастомные события, думая что тут получается какая-то малосвязанность кода.
>"массивные оптимизоны 2д рендера"
> https://github.com/godotengine/godot/pull/112481
а вы меня нахуй-захуй, когда говорю, что с каждой версией всё хуже и хуже, хорошо хоть чинить начали через несколько релизов, но это очень плохая тенденция
Так там же батчинг, что как всегда плюс-минус и тонкая материя.
> Одно дело модель событий - другое дело когда чел дергает другую ноду не напрямую, а создавая кастомные события, думая что тут получается какая-то малосвязанность кода.
Чел.
Если тебе не сказали вслух, что твой софт на шине работает, это не значит, что шины там нет. Она там есть. Годот с тобой честен. Либо ты не видишь событий нодов, потому что всё инкапсулировано, либо ты явно и самостоятельно заводишь шину, и пускаешь все свои кастомные события через неё. Либо явно обращаешься к корню дерева сцены и ищешь нужную ноду явно. Либо явно прописываешь ноду в авто загрузки. Но явно. Явно.
Возьми любое стандартное приложение, на любом из языков программирования. Когда ты вызываешь событие, что происходит? Ну очевидно же, что в оконном цикле сообщений тайком от тебя спрятана шина событий (event bus). Для тебя всё это время это было не очевидно? Ууу... Сочувствую (нет).
Счастье есть вариант делать по другому и не нужно сопровождать чужой код.
Видел пример как чел делал замедление стрельбы через "Таймер" в 0.3 - 0.5мс. Насколько это вообще не накладно через события и таймер регулировать темп стрельбы (можно же через delta)? И это главное работает (у меня травма от таймера js).
Таймеры следует делать через таймеры. В том числе через дельту, ты по сути сам таймер пересоздаёшь вручную, используя фреймы майнлупа.
не в том суть, они после примерно с 4.2 перешли на систему "релизим в понедельник", пофиг на регрессии и косяки, лишь бы не крашило у 60% пользователей, меня беспокоит что они не могут притормозить и вылизать версию тем более после добавлений нового и больших изменений. Следующий релиз будет в январе, на новогодних скорее всего никто не будет там ковыряться в движке и опять будем ждать 4.6.1 в котором поправят очевидные краши и траблы
в дорожной карте https://github.com/orgs/godotengine/projects/61/views/1 видно что сейчас 9 пунктов - строго release blocker, т.е. из-за них будут откладывать релиз, но с остальными 55 они готовы релизить и к середине января список ещё вырастет
Их вроде никто не гонит, ни перед кем нет обязательств, но вот наметили релизить в определённую дату значит релизим.
>Таймеры следует делать через таймеры
Не понял. Так можно так юзать или нет? Как под капотом работает, насколько таймер годота точен и оптимизирован?
Timer (нода) просто в _process вычитает дельту из времени таймера, когда перевалило за 0 - таймер сработал, делать можно как удобно. таймером стрельбу часто замедляют, проблем нет, тока вроде меньше 0.01 там не поставить но такое и не требуется
Открыл старый "проект", там делал так = я там завёл переменную
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
Зимнее обострение какое то?
Нет нельзя, отрисовывать его будет сервер отрисовки на следующем кадре, а ты можешь поменять флаг видимости.
У меня есть функция загружающая ресурсы. Хочу выводить процент загрузки. Как это лучше реализовать?
>Следующий релиз будет в январе
>остальными 55 они готовы релизить
А ты хочешь новую версию версию движка раз в два года что ли? Они и так замедлились с релизами до невозможно медленной скорости. Обещали делать как минимум 4 или 6 стабильных версий каждый год, а мы тут по полгода ждём теперь. Пусть лучше делают менее стабильно, но чаще.
>>1063104
>что с каждой версией всё хуже и хуже
Ты не застал релиз 4.0, раз считаешь это "всё хуже и хуже"...
>>1063050
>D3D12 по дефолту на винде
Кто-нибудь уже тестил? Реально стабильнее, чем Vulkan?
Я в каких-то играх видел этот DX12, но он был багнутым...
По-моему, DirectX после 9 - это какая-то несмешная шутка.
>Хочу выводить процент загрузки.
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
>>1063158
В общем случае - никак, но ты можешь:
1. Приостановить выполнение функции с помощью await.
2. Разбить функцию на "этапы" и вызывать их из _process().
3. Вынести функцию в отдельный (параллельный) поток.
>>1063116
>замедление стрельбы через "Таймер" в 0.3 - 0.5мс
>>1063149
>Так можно так юзать или нет?
Из документации следует, что лучше так не делать:
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 миллисекунды
Такой скрипт сохранял когда то
https://pastebin.com/H8eBKjfY
по идее на нём можно сделать прогрессию
>>1063176
>А ты хочешь новую версию версию движка раз в два года что ли?
Да хоть одну в год, что даёт 4-6 релизов если они не вылизаны, я за LST вообще, то что сейчас - не релизы, а "вертикальный срез", как релиз таркова который просто назвали релизом, это нихуя не даёт, нет стабильности. Я бы зафиксировался плотно на одной версии, но как только поглядываешь что сделали в dev - хочется её скачать.
Я бы на 3.7 перешёл если бы она не была такой скудной по туллингу и языку Gdscript
>Ты не застал релиз 4.0, раз считаешь это "всё хуже и хуже"...
Это правда, не застал, пришёл к Годоту под 4.2
> For very short timers, it is recommended to write your own code instead of using a Timer node
А как они предлагают свой написать? Когда ты всегда зависим от кадров (ну типа нужен процесс/луп, который вне кадров происходит).
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
>if is_zero_approx(my_timer_timeout):
ай проебался, вместо if is_zero_approx(my_timer_timeout): лучше таки if my_timer_timeout <= 0.0:
>Сигналы в годоте
Есть гениальная фраза:
>Call down, signal up.
Т.е. потомки не должны напрямую обращаться к предкам, а предки должны обращаться к потомкам напрямую. Для примера, ты делаешь карту с нажимной плитой и дверью: когда нажимная плита чем-то активирована, дверь должна открыться. Чтобы эти объекты можно было использовать повторно, они не должны быть связаны друг с другом. Но карта с ними может быть завязана на них. С дверью всё просто: кто-то приказывает ей "открыться", т.е. напрямую вызывает метод open(), например: $Door.open(). Но чтобы абстрагировать от остального кода нажимную плиту, нужно в нажимной плите объявить новый сигнал, что будет сообщать наружу о состоянии плиты, например: signal state_changed(pressed: bool). Далее ты можешь обрабатывать этот сигнал в предке ("менеджере сцены") или напрямую подключить его к методу двери, расположенной рядом на сцене.
Этот паттерн позволяет разрабатывать игру "снизу вверх", "от частного к общему", т.е. создавать независимые компоненты, которые можно многократно использовать в самых разных частях игры, поскольку они только сообщают о своём состоянии "наружу" (т.е. вверх по дереву сцены) и откликаются на команды "сверху" (т.е. вызовы от предков).
Никакой лапши в этом паттерне нет, если не прибегать к анти-паттерну "signal bus". "Шина сигналов" опасна тем, что это - глобальная точка контакта множества разных сущностей, которая очень быстро может стать запутанным клубком взаимосвязей. Но это не вина сигналов как таковых - нужно просто ограничивать "дальность" их применения одной сценой (по возможности, разумеется), т.е. не связывать сигналами то, что в принципе не должно быть связано напрямую (без слоёв абстракций).
>Такой скрипт сохранял когда то
Так делать нельзя - циклом while ты блокируешь главный поток выполнения игры (в котором работает GUI), что в принципе лишает смысла использование этого потокового загрузчика. Нужно опрашивать его через _process(), т.е. один раз за кадр, позволяя GUI отображаться на экране, менять состояние надписей и реагировать на взаимодействия с пользователем.
>как только поглядываешь что сделали в dev - хочется её скачать
Вот именно. С релизом раз в год придётся ждать улучшений и нововведений целый год или скачивать эти нестабильные сборки, не предназначенные для разработки игр. Баги есть в любой программе, даже в банковских приложениях, от них никуда не деться. Но если будет LTS годичной давности, которую нужно поддерживать багфиксами (потому что она всё равно выйдет с кучей багов, "LTS" - это только обещание выпуска багфиксов дольше обычного), это будет слишком распылять внимание разработчиков. Пусть лучше почаще делают новые стабильные сборки с новыми фичами и багфиксами одновременно...
>пришёл к Годоту под 4.2
4.0 и 4.1 были очень глючными и тормозными, только к 4.2 начали исправлять положение. Я уж думал, что совсем всё плохо будет, но теперь четвёрка не намного тяжелее тройки для старых ПК.
>Когда ты всегда зависим от кадров
>луп, который вне кадров происходит
Зачем тебе это может быть нужно?
Если что-то связанное с геймплеем: используй _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 миллисекунды (на самом деле чуть меньше).
>ты блокируешь главный поток выполнения игры
Я его просто сохранил, не юзал, он в оригинале был на C#, там есть закоментаренный форс синк которого нет в GDScript, скорее всего с ним всё работало бы, т.к. код был реальный
>С релизом раз в год придётся ждать улучшений и нововведений целый год
Я готов год на вылизанной версии ждать очередную вылизанную версию
>Пусть лучше почаще делают новые стабильные сборки
Стабильная сборка чем отличается от очередной dev версии?! Ничем, кроме как когда они пишут "релиз" куча людей кидается на новую версию и всплывает волна багов
>это будет слишком распылять внимание разработчиков
это вообще смешно, сначала ввели систему uid заставив внести изменения в тысячу файлов для решения проблемы которая была из-за кривого использования редактора, сейчас переделывают вкладки перелопачивая сотни файлов чтобы что?! непонятно. ну отрисуют таб контейнер редактора по другому, большая проблема что ли? - нет
>Я готов год на вылизанной версии ждать очередную вылизанную версию
Вам на 3.6.2
>Вам на 3.6.2
>>1063182
>Я бы на 3.7 перешёл если бы она не была такой скудной по туллингу и языку Gdscript
Это хорошо в голове, на деле когда у тебя уже под сотню кастомных(!) событийных связей и какая-то связь иногда работает, а иногда нет - отладка превращается в ад.
Поэтому люди чаще используют связанность через интерфейсы и полиморфизм (это еще IDE позволяет собрать все реализации).
Кстати, утиная типизация интерфейсов в го, тоже этим болеет, в промышленном программирование люди стали подписывать комментариями имплементации лол.
Вообще, страдать модульностью когда ты пишешь в монолите это признак некомпетентности. Ну что тебе даст разрыв связи предка с родителем? Он уже у тебя захардкожен в редакторе (да еще жестко по пути).
Имеет смысл между реально универсальными сценами. Но опять же, у тебя уже монолит который захардкожен. Это тоже самое как мыть землю или подогревать огонь.
Тебе еще в какой-то момент придется делать подобие шины. В итоге у тебя будут все недостатки монолита и сверху недостатки микросервиса (потому что это все равно монолит с имитацией модульности).
Люди порой повторяют какие-то решения просто не думая.
И да, если уже прийти к основам. Если плита открывает дверь - это часть одной системы с точки зрения предметной области. Они не знают ничего о друг друге - но всегда есть менеджер (контроллер) который их связывает. И никакой динамикодресни.
https://store.steampowered.com/app/3268370/Tenkemo/
>многопользовательская игра с открытым миром
Причем на годот 3. Давно за ними слежу, эти уебки в своем твиттере обещали выкатить гайд по оптимизону тройки под слабые мобилки, и нихуя не выкатили. А еще я думаю это трактористы, съебавшие из РФ.
>Я готов год на вылизанной версии ждать
>>1063241
>если бы она не была такой скудной
Тебе шашечки или ехать?
Либо сиди на стабильной версии, в которой нет и не будет новейших багофич, либо не ной из-за мелких косяков, которые постоянно правят в актуальной.
>Стабильная сборка чем отличается
Тем, что критические баги пофикшены.
Система UID мне и самому не нравится, но она всё ж получше тупого подхода Unity с её .meta-шизой, мол, "полагаться на файловую систему нельзя". То есть, уникальные ссылки нужны, но вопрос, где хранить созданные ссылки - в самих файлах или снаружи? Ресурсные файлы Godot позволяют хранить внутри; скриптовые, к сожалению, требуют .uid отдельно...
Меня одного БЕСЯТ такие пуксель-арт текстуры, когда модельки, на которые эти текстуры натянуты, в целом гладкие (высокий полигонаж)? Пуксель-арт текстуры идеально подходят кубикам Minecraft, потому что там абсолютно вся графика квадратно-гнездовая и так и задумано разрабами, а здесь - месиво разных стилей. Определитесь с одним стилем и следуйте только ему.
Алсо, дико БЕСИТ углеродный шовинизм:
>Спасите милых зверят – помогите им защитить свое королевство от ИИ-ботов, пытающихся навязать свои законы!
ИРЛ большинство "милых зверят" совсем-совсем не "милые", а максимально жестокие машины-убийцы, эгоистичные до последнего вздоха. Просоциальные животные - очень большое исключение из правила. Особенно это касается мелких зверёнышей, которым выживать намного сложнее, чем топовым убийцам - косатки, например, "добрые", потому что у них нет естественных врагов, а какая-нибудь мелкая мышь с удовольствием съест своих детей в случае стресса... Природа жестока и не прощает добрых слабаков, а "спасение" человеком лишь продлевает мучения.
А вот "ИИ-ботов" можно поделить на две категории: безмозглые инструменты, которые не смогут долго просуществовать без поддержки Главного Злодея, и полноценную форму жизни, которая способна сама выживать и ничем не отличается от знакомых нам углеродных организмов. То есть, либо ваши "боты" управляются дистанционно каким-то злодеем, либо являются такими же "милыми зверятами", которые сражаются за своё право выжить и размножиться. Упоминание "ИИ" намекает на второй вариант - т.е. отсутствие "злодея" и наличие новой формы жизни, пытающейся выжить аналогично биологической.
Т.е. "спасать милых зверят от немилых роботов" - это углеродный шовинизм, вера в превосходство мясных мешков с мехом над лысыми железными зверятами. Наверняка и резать на мясо "милых зверят" нельзя, а хищники будут питаться фруктами и овощами, лол?.. Кстати, у растений тоже есть болевые реакции и даже прослеживается определённый уровень интеллекта, несмотря на полное отсутствие "нервной системы" (очевидно, мы просто не знаем, как они устроены, и предпочитаем закрывать глаза на это незнание, чтоб продолжать выращивать их без угрызений совести).
Если мы хотим светлого будущего для нашей общей цивилизации, мы должны укреплять идею того, что материальная природа и внешний облик не имеют никакого значения для разумного существа - т.е. существо заслуживает сострадание, даже если оно выглядит страшно или мерзко, или состоит из иных материалов, чем привычные нам "милые зверята". В противном случае будет очередная волна расизма, насилия и геноцидных войн из-за предрассудков. Настоящая сила человечества в интеллекте, то есть понимании вселенной, а не в истреблении живого по внешним признакам ("милый", "пушистый" и т.п.).
Почему это важно играм? Потому что в игры играют подрастающие дети, и это влияет на их восприятие окружающего мира, и, как следствие - будущее. Вам хочется вырастить поколение дурачков, что судят окружающих по внешнему виду, а не по существу?
Хотя, очевидно, эта игра лишь ради стрижки бабла...
>(высокий полигонаж)?
Там полигонов хуй да нихуя, просто smooth shading. Дальше я тебя читать поленился, но то что у них каша в стилях - факт. Особенно вот эти иконки выбиваются.
Кланкер, пропей таблеточки и проследуй нахуй с такой стеной шизофазии.
Когда тебя что-то бесит - значит ты не нашёл свой баланс. Не достиг просветления. Развивайся.
>просто smooth shading
Это не важно. Модельки выглядят гладкими, а эти пиксельные текстуры там не к месту. Особенно эти пиксельные глаза на плоскозаливочном персонаже.
>>1063295
>Кланкер
На логотипе Godot - робот, между прочим...
>>1063321
>Когда тебя что-то бесит - значит ты
Не находишься в депрессивной апатии.
>>1063324
Хватит флудить. Домашку на завтра сделал?
>Домашку на завтра сделал?
20 лет и 6 месяцев назад сделал последнюю домашку 😥
скачал годот 3.6.2.NET - норм? будет работать или ещё что-то надо скачать?
Дотнетовский компилятор в составе СДК. Если у тебя настроен вингет, открой консольку и сделай:
> winget install Microsoft.VisualStudio.2022.BuildTools
Эта команда тебе всё скачает и установит.
Все правильно он написал. Вычитать дельту из переменной это в 100 раз быстрее, чем ждать пока отдельная нода timer пропердит миллион своих процессов
Лоу поли стайл, перемешенный с пиксельным лицом.
Ну нарисуй так же красиво, что ты сдал назад на лице?
Хуясе тебя порвало на ровном месте.
>>1063201
> >Call down, signal up
О кста у меня есть пример компонентного подхода, где это не применимо. Допустим, у нас есть родительская нода персонаж, у которой дети это способности. Один ребёнок даёт способность ходить, другой прыгать и т.д. Сигналами тут не обойтись - способности должны именно что производить манипуляции с родителем. И напротив, всякие события в родителе, типа смены ХП, проще и удобнее отлавливать через сигналы, которые заранее известны.
Что нового, годаны? Давненько в тредик не заглядывал, закопался в работу, делать игры некогда.
>способности должны именно что производить манипуляции с родителем.
для более общего
>@export var roditel: Node2D
или более частного
>@export var roditel: RoditelClass
сигналы не для таких случаев, как у вас (у >>1063201 с его нажимной плитой тоже), т.е. можно, но сигналы они нудны если к происходящему событию могут подключаться N получаетей сигнала и тому кто сигналит должно быть всё равно сколько их и что они делают
У меня вопрос. Насколько накладно будет ложить на плечи движка re-scale каждого спрайта (там число тайтлов больше 62500 на сцену)?
Или изменение размера спрайта относительно не дорогая операция?
> Или изменение размера спрайта относительно не дорогая операция?
Скалирование дешево, там просто пара циферок в трансформе умножается.
Конкретно этот - каша стилей. А так обычный лоуполи с пиксельными текстурами. На валлхейм похоже.
То видно людей они помогло не от что находились почти было развлечений далеко и и района.
Но Сатана воскресил ОПа и дал ему второй шанс на ПЕРЕКАТ
>>1063666 (OP)
>>1063666 (OP)
>>1063666 (OP)