Шапка: https://hipolink.me/godothread
Предыдущий: >>973473 (OP)
Архивный: >>970671 (OP)
У меня подобное >>977022 →, только вместо спрайтов тумана - тайлмапа. Если клетка открывается - ставлю очищаю значение. Аналогичным образом сделан туман войны, там вместо непроглядной тьмы - прозрачный серый
Ясно
Я тож хз братан, делаю свои 3д частицы сразу в годоте.
Видимо главфоркер и его опыт. Короче, даже лого сменить не осилят.
Кто обосрался? Ты обосрался!
> повесточка
> шизожируха по квоте
> расстрельные списки
> ковровые баны топдонатеров
Чудовищный пиздец.
Вообще, додот конечно повеселили в последние дни лол. Столько-то обсуждений и охуеваний. Но надо определиться где же обсуждать повестку: в движкосрачах, либо тут, где немного не по теме получается.
мимо_юнитигосподин
> ковровые баны топдонатеров
Фейк ньюз. 5к ушли потому что у какой-то корпорации, хуй знает какой, истекла подписка на донаты годоту. "Баны топдонатеров" привели к потерям в 170 евро и 10 донатеров. Из-за драмы набежало 74 новых донатера с 1610 евро.
Короче, визга много, а по факту пук. Особенно проигрывал с постов на реддите в духе "перестаю донатить в годот, никаких игр на нем больше не сделаю!!1", открываешь профиль, а там школьник-анимешник, и вся его активность - сраться про драгонболл.
О, я с тайлмапами пока особо не разбирался. Знаю что там вроде как можно удобно и быстро рисовать уровни, создав свои правила того, как должен выглядеть, например, угол комнаты.
Тут такого тоже можно добиться, типа чтоб задать то как будет выглядеть угол, центр и край тумана? А то если делать как у меня - спрайтами, то надо и проверку на соселние клетки докручивать, что не так трудно, но тайлмапой интереснее.
> "Баны топдонатеров" привели к потерям в 170 евро и 10 донатеров. Из-за драмы набежало 74 новых донатера с 1610 евро.
Верим
Эти 1610 евро в одной комнате?
>патреон
Это рофел такой? Патреон больше года как retired, все перевели на новую систему: https://godotengine.org/article/godot-developer-fund/
Укатыайся обратно в движкосрач, залетный, и не позорься так больше.
>Тут такого тоже можно добиться, типа чтоб задать то как будет выглядеть угол, центр и край тумана?
У тайлмапов такое решение называется terrain, он очень классный, когда я понял насколько он всё упрощает, я долго и радостно хихикал
> Делайте игры
Ты хотел сказать - делать в годоте? Потому что я уже сделал, но только у себя в голове. Каждый день играю, не получается пройти даже первый уровень, слишком сложно...
ОКей.
Рабочее название: "Оторвать жопу от дивана"
Вот ты меня спросил и мне самому уже захотелось тоже подойти к игровому процессу посерьезнее. Решил для начала отрывать жопу от дивана фиксировано по три раза в день. В течение двух недель.
Пояснение. Игра не рогалик. Геймплей состоит в том чтобы жопа никогда более не касалась дивана.
Внезапно выяснилось что движок от гомогеев для гомогеев поддерживает гомогеев. Миллионы базовых шлёп уже отменили свои подписки на Годот.
Где же ссылки на новостные издания, газеты?
>снежинки
Повышает чсв, правда? Снежинки все кто был задет. Все вечно недовольные и ноющие по любому поводу. Кому мешают деградировать жиды, негры, пидоры, и плохой запад.
Не, прост наличие других проблем немного меняет перспективу, заставляя смотреть с удивлением на людей, жгущих свои нервы из-за какого-то твита про, блять, видео игры. Кто там кого больше обидел мне поебать.
Заходи, сладенький
зачем? реалистично ни одна из них не взлетит и не сделает меня долларовым миллионером, вот так чтобы как с флаппи бёрд, выпустить хуйню и залутать десятки миллионов долларов за первую неделю
мой путь будет тернист, сложен, выматывающий.. и всё ради чего? ради 14 рублей в год(до налогов)?
>как с флаппи бёрд, выпустить хуйню и залутать десятки миллионов долларов за первую неделю
Не было такого, он зарабатывал всего лишь 50к в день
Реалистично тебя ничто не сделает долларовым миллионером. Тогда в чем смысл чего-либо? Заткнись и делай.
Только вот не потеряли...
Кликбейт
Понятно короче. ПохуйХПохуй можно пилить никому не нужные говновысеры дальше.
Любитель мыслить позитивно, ты?
Кто вы то? Я один здесь. В геймдев не взяли, я просил слишком высокую зарплату....
>Подожду 5
Так для веба есть 3. Но конечно веб это про лоуполи с минимумом теней, постэффектов и прочего.
https://github.com/godotengine/godot/issues/80057
Совет из комментариев "выключить кэш" не помог.
Т.е. единственный выход юзать Vulkan Mobile, но он запускается несколько секунд и у него официально отсутствует батчинг, т.е. движок спамит дроуколы, получается, даже если использовать TileMap...
Попробовал снижать FPS, по моим ощущениям 20 нормально выглядит. Разница в нагрузке ощутима. Физический движок пока замедлил до 30 тиков.
А что по разрешению экрана? У меня 1080x2340, и разрешение 540x1170 выглядит нормально, но я не понимаю, улучшает ли это производительность - рендеринг на мобилках отличается "тайловостью".
Короче, есть ещё какие-то варианты сделать игру экономной, но чтобы были скелетные анимации?
>gl_compatibility
Увы, он очень сильно отстает от вулкана, ведь смысл годота 4 был переписывание на вулкан. К тому же где то писали что считают его уже feature complete Для галочки и дальше развивать вряд ли будут. Хочешь gl - тоже пробуй godot3. Там конечно тоже будут приколы с gles2 или gles3. Таков путь.
Пользуйся js аддоном.
>feature complete
Это значит "фокус смещён на багфиксы". В данной ситуации фича есть, но она почему-то не работает.
>пробуй godot3
Я на Godot с 2020 и не хочу возвращаться на 3.x, т.к. множество удобных фич ввели только в 4.x. Больше всего мне нравятся нововведения GDScript "2.0".
Мне просто кажется, что Vulkan Mobile избыточен...
Будет ли быстрее запуск игры, если собрать без 3D?
>официально отсутствует батчинг
Сам себе отвечаю: нужно попробовать 4.4-dev3:
https://godotengine.org/article/dev-snapshot-godot-4-4-dev-3/#add-batching-to-renderercanvasrenderrd
>This release brings the same performance benefits to the other backends by implementing batching when using the Forward+ and Mobile backends. Now 2D performance is comparable between all backends.
Интересно:
>We have further improvements planned for batching on the RD backends that should allow it to be even faster than the Compatibility backend. Stay tuned for updates in later dev releases!
На старом телефоне это ускорение будет ощутимо?
В смысле экономии энергии...
получается осталось немного подождать и можно будет начать делать игры, или всё же будем ждать 4.5.1?
Новый снапшот. Основное:
- вернулось вертекс освещение
- экспорт кнопок
- ускоренный стартап
- чего-то про рендер, что я поленился читать
- всякая мелочь
>экспорт кнопок
@export_tool_button - это для инспектора.
>ускоренный стартап
Открытие большого проекта в редакторе.
>чего-то про рендер, что я поленился
- батчинг для 2D в Forward+ и Mobile
- REPL в редакторе (а-ля Питон)
- старт профайлеров со стартом игры
- маркеры в анимации (для удобства)
- поддержка вебкамеры в линуксе
- фолбек на OGL3 если Vulkan'а нет
>всякая мелочь
- теперь токены GDScript детерминированы
- улучшена производительность сетки GraphEdit
- починили возврат частичного пути из AStar
- физику теперь можно полностью выключить
Кстати, неделю назад приняли вот это:
https://github.com/godotengine/godot/pull/97118
Эта фича позволяет генерировать PCK-патчи.
Хотели сделать ещё во времена 2.0...
Их много и они на get_tree()...
Годот умер! Да здравствует Редот!
Если форки просуществуют до бамплимита этого треда, то так уж и быть, они удостоятся занесения в шапку.
Но мы же все ИТТ прекрасно понимаем, что это срачефорки от обиды. Продержатся они максимум неделю, после чего их забросят. Как краб-язык.
Логотип то поменяли?
Все так. И ешьте по одной большой пицце в день.
1280x720, 0:11
Лень перелопачивать довольно большой для соло проект. Тем более постоянно кажется что релиз близко.
> Woked
На самом деле начиная с 20 ковидного года начался крах вок-культуры. Посмотрите новости. Вокнутых гонят повсюду.
>#OP
>крах вок-культуры
Эх, а я-то думал, ты гуманист.
Как я понимаю, вок - это типа "все равны и всем необходимо предоставить равные права", типа противодействие дискриминации отдельных категорий людей из-за старых предрассудков.
Godot вот поддерживает всех... кроме токсичных человеконенавистников. Разве это что-то плохое, поддерживать людей независимо от конфигурации биоробота и версии психологической прошивки?
Печально что такая резкая реакция на "вокот". Это означает, что люди всё ещё ненавидят друг друга...
Нужно меньше ненависти и больше любви.
Особенно любви к компьютерным играм.
Д Е Л А Й Т Е _ И Г Р Ы
>Как я понимаю, вок - это типа "все равны и всем необходимо предоставить равные права"
Неправильно понимаешь. В странах качающих эту самую вок-повестку уже давно у всех и так равные права, а вок теперь - это типа "у черных геев должно быть больше прав, чем у белых гетеро"
>>7938
Вы раздуваете несоизмеримо. Реальных последствий около нуля. Один твит и 100 евро кто-то из донатов унес, а визга на весь интернет, что на фоне тех же юнитипроблем с роялти вообще смех. У меня знакомый, который в геймдеве/программировании ни ногой, и то повизжать успел. Просто есть определенная аудитория которая ищет на что бы оскорбиться, и каждый раз это примерно одинаковый набор людей, не обязательно заинтересованный в Х, на который они в данный момент оскорбляются.
Так что да, это все так, шум. Делайте игры и не отвлекайтесь на шум.
> есть определенная аудитория которая ищет на что бы оскорбиться
Завсегдатаи срачетреда.
> Делайте игры и не отвлекайтесь на шум.
Да.
>ничего не могу сделать без гайдов
Гугли "tutorial hell", частая проблема ньюфагов. Тебе не хватает свободного экспериментирования без подсказок со стороны туториалов. Чаще пробуй разрабатывать что-то самостоятельно.
>я не программист,
В большинстве игр код не очень-то и важен, так что не зацикливайся - с опытом будет полегче. Важнее разбираться в геймдизайне и базовой математике.
>не художник,
Есть очень упрощённые стили, которые освоить без академической базы легче, чем другие. Также есть существенная разница между 2D и 3D. В крайнем случае, если у тебя на руках рабочая демка с очень интересным геймплеем, художника найти проще.
>даже идей нету.
Попробуй с нейронкой обсудить: http://duck.ai
Метод мозгового штурма работает и в соло.
$Button.connect("pressed", get_tree(), "change_scene", ["res://gamescene.tscn"])
Не все сразу, анон. Скиллы приходят с опытом. Сделаешь игр 10 - научишься. Нет идей - бери классику, переделывай, добавляй свои маленькие элементы. Либо вообще пизди взлетевшие идеи с итча.
В чём смысл так делать?
>$Button.connect
Зачем подключать в коде? А если переименуешь?
>change_scene
Это работает только для совсем уж микроигрушек.
>"res://gamescene.tscn"
Сломается при переименовании/перемещении.
>тестировать уровни удобней станет
F6 никогда не пробовал нажимать? Попробуй.
угрюмо архитектурю мультиплеерные кнопки
>В чём смысл так делать?
Чтобы не писать отдельную функцию которая не делает ничего кроме этого.
>переименуешь
Пример [redacted], на самом деле у меня там %Button, а сцену можно занести в константы.
>для микроигрушек
Ну да. Джем же. По большому счету это надо только для стартового меню чтобы перейти в игру уже.
>В чём смысл так делать?
Фишка в самой идее. Такая эрзац лямбда. Можно и с другими сигналами применение найти.
Вообще я другое хотел сделать, чтобы вписать это в редакторе в коннектор нод, тогда вообще бы не пришлось писать эту функцию.
> для стартового меню чтобы перейти в игру уже
Сначала пилишь гейм-менеджер, у которого есть АПИ для старта новой игры с заданным уровнем сложности. Затем
$Button.pressed.connect(get_game_manager(), change_scene, get_config().selected_game_mode)
Соответственно мультиплеер этой кнопке прикрутить легко, достаточно лишь
1. Не допускать такой ситуации, не размещать так объекты.
2. Придумать какой нибудь шейдер который их смешает
3. Не помню, помогает ли тут приоритет рендера (можно ли задать какие объекты нарисуются после каких)
Попробуй sorring offset / render priority
https://docs.godotengine.org/en/stable/classes/class_visualinstance3d.html#class-visualinstance3d-property-sorting-offset
https://docs.godotengine.org/en/stable/classes/class_material.html#class-material-property-render-priority
4. Читал что может помочь разрешение z-буфера, но это сильно зависит от камеры и жанра игры. Иными словами можно сделать zNear подальше а zFar поближе, чтобы только необходимый объем был в камере, соответственно точность значений вырастет и z-клаши будут реже.
Это скорее всего тебя не затронет, раз ты видишь z-fighting.
Инверснутый z-buffer распределяет разрешение равномерно по дистанции, вместо ненужной плотности только вблизи камеры, так что это важно для игр с большими дистанциями.
В 4-ке для этого есть Vector2i и Vector3i, которые содержат только целые числа. Они не подвержены ошибкам округления, а еще наверное быстрее. Ограничены 32 битами, это которое ±2,147,483,647
>кто-то спрашивал как использовать Vector2(x,y) в качестве координат в массиве
Там вопрос был типа "не плохо ли это в контексте производительности игры". Ответ: зависит способа использования. На реддите недавно пост был с подробным сравнением: подтвердилось, что Array немножко быстрее Dictionary в линейных операциях, однако, всё-таки хуже в рандомных операциях.
Ускорение Array зависит от кэша процессора. У более старых процессоров маленький кэш, а стандартные Array очень жирные (8 байт на каждую запись), так что преимущество от их использования только если у вас совершенно линейные данные и операции с ними.
Также зависит от плотности заполнения. Если у вас разреженная сетка, заполненная нулями ("воздухом"), гораздо выгоднее использовать Dictionary, тем более трёхмерный. Следующие операции:
>dictionary[Vector3i(x, y, z)] = 0 # создание записи
>if Vector3i(x, y, z) in dictionary: # проверка наличия
У меня выполняются быстрее любых аналогичных действий с Array, когда я недавно это всё тестил.
В 4.4 завозят типизацию Dictionary, можно будет так:
>var cells: Dictionary[Vector3i, CellType]
Интересно будет проверить производительность...
Также нужно помнить, что вызов функций добавляет оверхед на любые операции. Если вы хотите трюк с вычислением позиции внутри одномерного массива - ради производительности придётся писать каждый раз вручную вместо вызова функции. Потому что кастомная функция наподобие таких:
>func get_cell(x, y, z) -> CellType
>func set_cell(x, y, z) -> CellType
>func cell_id(x, y, z) -> int
Делает обращения к Array медленнее Dictionary. Это означает, что писать dictionary[Vector3i(x, y, z)] будет надёжнее против случайных ошибок, достаточно производительно и при этом данные разрежены (отсутствующие данные не заполняются нулями).
Конечно, если у вас огромные данные и с ними производится много операций каждый тик, тогда придётся переписывать на C++ или хотя бы C#. Но подобное редко встречается в играх (как правило "блочные" игры типа Minecraft, Terraria и т.п., но не любая блочная игра требует огромных массивов, например, фермерские игры намного компактнее).
>кто-то спрашивал как использовать Vector2(x,y) в качестве координат в массиве
Там вопрос был типа "не плохо ли это в контексте производительности игры". Ответ: зависит способа использования. На реддите недавно пост был с подробным сравнением: подтвердилось, что Array немножко быстрее Dictionary в линейных операциях, однако, всё-таки хуже в рандомных операциях.
Ускорение Array зависит от кэша процессора. У более старых процессоров маленький кэш, а стандартные Array очень жирные (8 байт на каждую запись), так что преимущество от их использования только если у вас совершенно линейные данные и операции с ними.
Также зависит от плотности заполнения. Если у вас разреженная сетка, заполненная нулями ("воздухом"), гораздо выгоднее использовать Dictionary, тем более трёхмерный. Следующие операции:
>dictionary[Vector3i(x, y, z)] = 0 # создание записи
>if Vector3i(x, y, z) in dictionary: # проверка наличия
У меня выполняются быстрее любых аналогичных действий с Array, когда я недавно это всё тестил.
В 4.4 завозят типизацию Dictionary, можно будет так:
>var cells: Dictionary[Vector3i, CellType]
Интересно будет проверить производительность...
Также нужно помнить, что вызов функций добавляет оверхед на любые операции. Если вы хотите трюк с вычислением позиции внутри одномерного массива - ради производительности придётся писать каждый раз вручную вместо вызова функции. Потому что кастомная функция наподобие таких:
>func get_cell(x, y, z) -> CellType
>func set_cell(x, y, z) -> CellType
>func cell_id(x, y, z) -> int
Делает обращения к Array медленнее Dictionary. Это означает, что писать dictionary[Vector3i(x, y, z)] будет надёжнее против случайных ошибок, достаточно производительно и при этом данные разрежены (отсутствующие данные не заполняются нулями).
Конечно, если у вас огромные данные и с ними производится много операций каждый тик, тогда придётся переписывать на C++ или хотя бы C#. Но подобное редко встречается в играх (как правило "блочные" игры типа Minecraft, Terraria и т.п., но не любая блочная игра требует огромных массивов, например, фермерские игры намного компактнее).
Кстати, есть ещё Vector4i(w, x, y, z):
https://docs.godotengine.org/en/stable/classes/class_vector4i.html
Не знаю, зачем он нужен, но может пригодиться, например, если у вас 3D сетка со слоями (w - слой):
>cell[Vector4i(CellLayer.PLANTS, x, y, z)] = CellType.TREE
Мне кажется, это лучше, чем массив из Dictionary.
>Чтобы не писать отдельную функцию которая не делает ничего кроме этого.
Сейчас ничего не делает.
Потом тебе может понадобиться делать что-то в дополнение к смене сцены перед/после этого. Специальный обработчик события вроде такого:
>func _on_menu_button_pressed(...)
Позволяет в будущем быстро, решительно вписать дополнительную логику, которой изначально не планировалось, но без которой никак. Если такого обработчика нет, придётся его завести и изменить подключающий кнопки к обработчикам код.
Т.е. на каждое событие должен быть обработчик, специально предназначенный для этого события (категории событий - если похожих кнопок много).
Можно, конечно, написать анонимную функцию, но обмазывать код анонимными функциями некрасиво.
А скорость разработки лежит не только в том, как быстро ты стряпаешь код прямо сейчас, но и в том, насколько быстро ты будешь стряпать код потом. Хорошо продуманная система потратит немного времени в начале, чтобы позже сэкономить много.
> обмазывать код анонимными функциями некрасиво
Зависит от синтаксиса. В гдскрипте не смогли в красоту, увы.
> var foo = func(bar): return bar
Зачем было что-то выдумывать, когда есть простая стрелка?
> var foo = bar => bar
>победить z-fighting
>Помимо сделать одну ниже?
Опиши ситуацию, почему у тебя этот артефакт вообще возникает. Скорее всего, ты делаешь что-то не то, что получается артефакт и просто сдвинуть не можешь.
Если ты делаешь 3D тайлы внутри GridMap, тогда они должны быть в рамках своей клетки. Если почему-то хочется растянуть их шире, тогда одно из интересных решений - подразделить тайл и немного выгнуть его:
>\____/ - один тайл
>\____/\____/ - стандартный тайлинг
>\____\/____/ - тайминг с пересечением тайлов
Тогда пересечение треугольников будет под углом, несмотря на то, что тайлы на одном уровне, и этот артефакт будет если не устранён, то минимален.
Если твои 3D тайлы абсолютно плоские без какой-то геометрии и ты не хочешь их выгибать, тогда другой вариант - использовать SubViewport для рендеринга большой текстуры "запечённых" тайлов, которые ты рендеришь на большом PlaneMesh. GridMap можешь использовать для дополнительной геометрии вроде торчащих кустиков/деревьев, а PlaneMesh будет содержать в себе только плоские тайлы.
Но я рекомендую, прежде чем пытаться это всё реализовать, сфокусироваться на геймплее игры. Возможно, реализовав геймплей, окажется, что механизм карты нужно полностью переделать. В прототипах визуальные артефакты не мешают.
Надо било хоронить в таких случаях, либо терпеть. Нахуя плодить форки?
Учи давай, не ленись.
>редот
Это клоуны, игнорируй их.
>>7673
>Если форки просуществуют до бамплимита
Да не нужны эти форки в шапке, лол. Не будешь же добавлять все 20 тыщ форков Godot с гитхаба? На данный момент основной Godot жив и здоров, все остальные - вкусовщина, кому нужно - найдёт сам.
Тем более не нужно добавлять "форки", в которых добавили только условные "нескучные обои".
Лучше упомянуть, например, такую сборку движка:
https://github.com/Zylann/godot_voxel/releases
Там хоть что-то полезное добавлено. И рабочее.
У тебя вот написано:
>Для любителей пощекотать конпеляцию
>>Воксельные террейны от Зилана
Но он даёт готовые сборки - компилировать не надо.
Кому нужны релизы мог самостоятельно открыть релизы. Ну ладно. Сделал равнение на отстающих. Проверяй.
> Я бы еще rpg in a box порекламил. Хороший проект.
Всё равно шапку никто не читает. Её надо конкретно перерабатывать, но времени конкретно нет.
>есть простая стрелка
>>var foo = bar => bar
Это слишком запутывает - с первого взгляда нельзя понять, что здесь происходит:
- к foo присваивается bar?
- или foo является bar?
- а что значит "из bar следует bar"?
- или это "из foo, что равно bar, следует bar"?
- или это проверка какого-то условия следования?
И т.д.
В GDScript сделали хорошо, читабельно:
>var foo = func(bar): return bar
- переменная foo хранит ссылку на функцию (func);
- функция принимает аргумент bar (скобочки);
- функция возвращает (return) аргумент bar.
Всё понятно с первого взгляда и легко разбить на несколько строчек, если код достаточно длинный.
Я считаю анонимные функции некрасивыми лишь потому, что у них нет собственного имени и они вплетаются в посторонний для них код, что снижает читабельность кода. Предложенный синтаксис ещё больше снижает читабельность такого кода, ведь он ухудшает разделение на "код здесь"/"код где-то там". Лучше всего выделить функцию и дать ей читаемое название, по которому к ней будешь обращаться.
>Я бы еще rpg in a box порекламил.
Но он же платный. Ты сам-то им пользуешься? А то я пробовал как-то демку, не понял, в чём смысл. Это ж просто игрушка для детей. Но у детей есть роблокс...
Проблема большинства "конструкторов игр без программирования" в том, что они очень сильно ограничивают полёт фантазии. Шаг в сторону - необходимо ковырять сторонние DLL или нырять в исходники на C++. Если они вообще доступны. Тут преимущество модулей Godot в том, что они не отбирают у тебя возможности ванильного Godot, который универсален - подойдёт почти для всего.
Хочу сказать, что если "RPG in a Box" может сделать экспорт своего проекта для редактирования в Godot, тогда хорошо, а если это какой-то независимый "конструктор игр без программирования" на основе Godot, но без совместимости проектов, тогда ему в этом треде, имхо, не место. Можно было бы создать отдельный тред, как в случае с RPG Maker, если б достаточно пользователей здесь было (хоть один).
Я вчера прочитал шапку. А там, вроде, пропало все что аноны писали, только ссылки на сторонние сайты остались. Надо бы свою БАЗУ знаний завести.
За рпг мейкер и гейммейкер и тоже башлять придется если хочешь релизнуть коммерчески. Не мешает им жить, а релевантным тредам регулярно всплывать в /gd
Про остальные твои поинты - аудитория есть, проект коммерчески успешен. Даже в годот донатят на титаниуме.