Шапка: https://hipolink.me/godothread
Предыдущий: >>973473 (OP)
Архивный: >>970671 (OP)
У меня подобное >>977022 →, только вместо спрайтов тумана - тайлмапа. Если клетка открывается - ставлю очищаю значение. Аналогичным образом сделан туман войны, там вместо непроглядной тьмы - прозрачный серый
Видимо главфоркер и его опыт. Короче, даже лого сменить не осилят.
Кто обосрался? Ты обосрался!
> шизожируха по квоте
> расстрельные списки
> ковровые баны топдонатеров
Чудовищный пиздец.
Вообще, додот конечно повеселили в последние дни лол. Столько-то обсуждений и охуеваний. Но надо определиться где же обсуждать повестку: в движкосрачах, либо тут, где немного не по теме получается.
мимо_юнитигосподин
> ковровые баны топдонатеров
Фейк ньюз. 5к ушли потому что у какой-то корпорации, хуй знает какой, истекла подписка на донаты годоту. "Баны топдонатеров" привели к потерям в 170 евро и 10 донатеров. Из-за драмы набежало 74 новых донатера с 1610 евро.
Короче, визга много, а по факту пук. Особенно проигрывал с постов на реддите в духе "перестаю донатить в годот, никаких игр на нем больше не сделаю!!1", открываешь профиль, а там школьник-анимешник, и вся его активность - сраться про драгонболл.
>>977156
Нашел какой корп проебал подписку на 5к - Ramatak. Они предлагают услуги по портам годота, там рулят Ariel Manzur (один из основателей годота и братан Хуана) и Hein-Pieter van Braam. Оба они участвуют и в Godot Foundation. Думаю вернутся в ближайшие дни.
О, я с тайлмапами пока особо не разбирался. Знаю что там вроде как можно удобно и быстро рисовать уровни, создав свои правила того, как должен выглядеть, например, угол комнаты.
Тут такого тоже можно добиться, типа чтоб задать то как будет выглядеть угол, центр и край тумана? А то если делать как у меня - спрайтами, то надо и проверку на соселние клетки докручивать, что не так трудно, но тайлмапой интереснее.
> "Баны топдонатеров" привели к потерям в 170 евро и 10 донатеров. Из-за драмы набежало 74 новых донатера с 1610 евро.
Верим
Эти 1610 евро в одной комнате?
>патреон
Это рофел такой? Патреон больше года как retired, все перевели на новую систему: https://godotengine.org/article/godot-developer-fund/
Укатыайся обратно в движкосрач, залетный, и не позорься так больше.
>Тут такого тоже можно добиться, типа чтоб задать то как будет выглядеть угол, центр и край тумана?
У тайлмапов такое решение называется terrain, он очень классный, когда я понял насколько он всё упрощает, я долго и радостно хихикал
> Делайте игры
Ты хотел сказать - делать в годоте? Потому что я уже сделал, но только у себя в голове. Каждый день играю, не получается пройти даже первый уровень, слишком сложно...
ОКей.
Рабочее название: "Оторвать жопу от дивана"
Вот ты меня спросил и мне самому уже захотелось тоже подойти к игровому процессу посерьезнее. Решил для начала отрывать жопу от дивана фиксировано по три раза в день. В течение двух недель.
Пояснение. Игра не рогалик. Геймплей состоит в том чтобы жопа никогда более не касалась дивана.
>Вообще, додот конечно повеселили в последние дни лол
А чё за драма случилась? Я в танке был.
>>977230
Ничего не случилось, просто визжащие снежинки-ноудевы и залетные - >>>977164 >>977166
Всем продолжать ебашить свои проекты.
Внезапно выяснилось что движок от гомогеев для гомогеев поддерживает гомогеев. Миллионы базовых шлёп уже отменили свои подписки на Годот.
>снежинки
Повышает чсв, правда? Снежинки все кто был задет. Все вечно недовольные и ноющие по любому поводу. Кому мешают деградировать жиды, негры, пидоры, и плохой запад.
Не, прост наличие других проблем немного меняет перспективу, заставляя смотреть с удивлением на людей, жгущих свои нервы из-за какого-то твита про, блять, видео игры. Кто там кого больше обидел мне поебать.
зачем? реалистично ни одна из них не взлетит и не сделает меня долларовым миллионером, вот так чтобы как с флаппи бёрд, выпустить хуйню и залутать десятки миллионов долларов за первую неделю
мой путь будет тернист, сложен, выматывающий.. и всё ради чего? ради 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. Таков путь.
>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?
Делай сейчас. Пока ты сделаешь уже и 4.5 выйдет, сможешь апгрейднуться.
Новый снапшот. Основное:
- вернулось вертекс освещение
- экспорт кнопок
- ускоренный стартап
- чего-то про рендер, что я поленился читать
- всякая мелочь
>экспорт кнопок
@export_tool_button - это для инспектора.
>ускоренный стартап
Открытие большого проекта в редакторе.
>чего-то про рендер, что я поленился
- батчинг для 2D в Forward+ и Mobile
- REPL в редакторе (а-ля Питон)
- старт профайлеров со стартом игры
- маркеры в анимации (для удобства)
- поддержка вебкамеры в линуксе
- фолбек на OGL3 если Vulkan'а нет
>всякая мелочь
- теперь токены GDScript детерминированы
- улучшена производительность сетки GraphEdit
- починили возврат частичного пути из AStar
- физику теперь можно полностью выключить
Кстати, неделю назад приняли вот это:
https://github.com/godotengine/godot/pull/97118
Эта фича позволяет генерировать PCK-патчи.
Хотели сделать ещё во времена 2.0...
Годот умер! Да здравствует Редот!
Если форки просуществуют до бамплимита этого треда, то так уж и быть, они удостоятся занесения в шапку.
Но мы же все ИТТ прекрасно понимаем, что это срачефорки от обиды. Продержатся они максимум неделю, после чего их забросят. Как краб-язык.
У вас название двигуна в шапке направильно написано - должно быть Wokedot.
мимокрокодил
>застрял на тройке
В чём причина? Старые библиотеки GDNative?
Лень перелопачивать довольно большой для соло проект. Тем более постоянно кажется что релиз близко.
> Woked
На самом деле начиная с 20 ковидного года начался крах вок-культуры. Посмотрите новости. Вокнутых гонят повсюду.
Сорян, тоже ошибся >>977869, не Wokedot, а Wokot
>>977039 (OP)
>#OP
>крах вок-культуры
Эх, а я-то думал, ты гуманист.
Как я понимаю, вок - это типа "все равны и всем необходимо предоставить равные права", типа противодействие дискриминации отдельных категорий людей из-за старых предрассудков.
Godot вот поддерживает всех... кроме токсичных человеконенавистников. Разве это что-то плохое, поддерживать людей независимо от конфигурации биоробота и версии психологической прошивки?
Печально что такая резкая реакция на "вокот". Это означает, что люди всё ещё ненавидят друг друга...
Нужно меньше ненависти и больше любви.
Особенно любви к компьютерным играм.
Д Е Л А Й Т Е _ И Г Р Ы
>Как я понимаю, вок - это типа "все равны и всем необходимо предоставить равные права"
Неправильно понимаешь. В странах качающих эту самую вок-повестку уже давно у всех и так равные права, а вок теперь - это типа "у черных геев должно быть больше прав, чем у белых гетеро"
>>977938
Вы раздуваете несоизмеримо. Реальных последствий около нуля. Один твит и 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-клаши будут реже.
>>978057
>>978058
Спасибо, потыкаю чего-нибудь из этого, отпишусь если поможет. Видел еще в бете что-то с 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 и т.п., но не любая блочная игра требует огромных массивов, например, фермерские игры намного компактнее).
Кстати, есть ещё 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 будет содержать в себе только плоские тайлы.
Но я рекомендую, прежде чем пытаться это всё реализовать, сфокусироваться на геймплее игры. Возможно, реализовав геймплей, окажется, что механизм карты нужно полностью переделать. В прототипах визуальные артефакты не мешают.
Надо било хоронить в таких случаях, либо терпеть. Нахуя плодить форки?
>редот
Это клоуны, игнорируй их.
>>977673
>Если форки просуществуют до бамплимита
Да не нужны эти форки в шапке, лол. Не будешь же добавлять все 20 тыщ форков Godot с гитхаба? На данный момент основной Godot жив и здоров, все остальные - вкусовщина, кому нужно - найдёт сам.
Тем более не нужно добавлять "форки", в которых добавили только условные "нескучные обои".
Лучше упомянуть, например, такую сборку движка:
https://github.com/Zylann/godot_voxel/releases
Там хоть что-то полезное добавлено. И рабочее.
У тебя вот написано:
>Для любителей пощекотать конпеляцию
>>Воксельные террейны от Зилана
Но он даёт готовые сборки - компилировать не надо.
Кому нужны релизы мог самостоятельно открыть релизы. Ну ладно. Сделал равнение на отстающих. Проверяй.
Модераторов и абу набирает. Попробуй вот программистов набрать. Кстати, почему бы тебе не устроиться к ним программистом? А то там пока школьник с нулем проектов и пустой анонимус в маске анонимуса.
>>978162
Я бы еще rpg in a box порекламил. Хороший проект.
> Я бы еще 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
Про остальные твои поинты - аудитория есть, проект коммерчески успешен. Даже в годот донатят на титаниуме.
Разработчики движка: если объект с такой фичей доступен в браузере, подключаем.
Песочница хрома: ага, ты запросил объект фичи, значит ты хакер.
Там минифицированный жс
Задача убрать само упоминание, не сломав остальной код иницализации (который в развертнутом виде выглядит как цепочка if(feature1 in browser) use;
Всё правильно скинул, чтобы знали, что в эту парашу теперь вкатываться надо с очень высоким риском закрытия движка и придётся кому-то другому брать на себя попенсурс, т.к. из-за того что туда залезла сжвшная падаль, которая всё в говно скатывает, то это говорит теперь о значительной нестабильности проекта. Там даже один из разрабов попытался слово сказать, не поддержав подобную хуйню, но потом закрыл твит, всё, проекту пизда, движок не набрал такой массы пользователей, как тот же UE, чтобы такую хуйню творить. Еще не факт, что попенсурсность спасёт, если эту хуйню не поправят, ожидаем в ближайшее время форков.
>ожидаем в ближайшее время форков
Ожидаем в ближайшее время ещё форков.
Коммьюнити поддерживает проект не для того, чтобы кормить сжвшную падаль.
быстрофикс
>>978344
Хуя глубокая маняаналитика. И чего там, как этот форк поживает? Есть ли там кто-нибудь кто умеет программировать, или только такие же залетные ноускилльные визгуны как ты?
>алитика
Она у меня хотя бы есть, в отличии от недалёкого и неумеющего читать додика, типа тебя.
То что там форк какой-то появился в первые дни ничего не значит, это вполне возможно просто попытка на обсёре выехать, этов сё не быстрый процесс.
В любом случае негатив уже пошёл, уважения к своему коммьюнити нет, а что случается с такими сжв проектами уже вся индустрия полна примеров, в лучшем случае будет медленно дохнуть и терять бабло, если не исправят проблему с сжв даунами.
Есть 4.3 и 3.6. В них столько фич, что даже если больше ничего не добавят/не пофиксят, этого хватит любому вкатуну до конца жизни написать десятки игр.
Согл, поэтому особо не парюсь по текущим проектам, но хотелось бы нормального развития софта которым пользуешься, а не вот это вот всё.
>Там даже один из разрабов попытался слово сказать, не поддержав подобную хуйню, но потом закрыл твит
А кто, расскажи? Я на основных разрабов подписан давно и могу смотреть их заприваченные аккаунты. Редуз? Акиен?
Добавлю что бывший проджект менеджер годота, 100% русский чувак, и тот поддержал позицию годота. Так что, братан, сдается мне ты тут впустую пыхтишь.
Зачем ты сюда своего протыка притащил? Разработчики игр такую хуйню не смотрят, а для дебилов с повесточкой головного мозга есть /b
Не пыхчу, а изливаю недовольство ситуацией из-за негативного фона и сжвшных пидоров на админах, история хуёвенькая.
>А кто
Редуз, после чего жиденько пукнул и закрыл свиттер. Для меня это ключевые политические моменты, после которых софтина медленно идёт попизде
>а изливаю недовольство ситуацией
А тебя она как-то касается? Ты сколько-то игр на годоте сделал? Или ты в него донатил свой код/деньги? Или ты так, бегаешь по всему интернету и ищешь на что бы оскорбиться?
>после чего
После чего на него стали набегать и срать-угрожать в комментах, отчего и заприваченный аккаунт и переезд в мастодон (пик). А официальное заявление его - заявление Godot Foundation, потому что он там председатель и основатель. Висит оно в твиттерах и годота и фонда, можешь сходить прочитать. Тебе самому не смешно как вы пытаетесь взять чьи-то слова и вывернуть их наизнанку?
Спасибо большое тебе за скрин, не видел его и не знал, что главный разраб просто даун.
>А тебя она как-то касается?
Три месяца назад начал разбираться, очень рад что это произошло сейчас и я не так много успел сделать, теперь ещё больше причин дропать, попенсурсность пока перевешивает, конечно.
>Три месяца назад начал разбираться
ЧСХ почти все оскорбившиеся именно такие же мимокрокодилы, а реальные потери - около 100 евро.
>главный разраб просто даун
Не сомневаюсь, ты сделаешь лучше. Ждем от тебя коммитов в редот, а то чет я смотрю у них сайт вместо плашки under construction теперь аж днс не резолвит, лул. Беги спасай спасителей геймдева.
Не, с нуля я не буду ничего делать и в мёртвые форки что-то коммитить. Я просто, скорее всего, вернусь к первоначальному плану делать клиентскую часть на UE, т.к. имею в нём опыт + у меня уже есть знакомый эксперт, готовый помочь за бабосы. У меня первая версия бэка на AWS создана, осталось только заняться вопросами масштабирования, клиент тестовый на коленке сделанный тоже есть, мне нужен был только движок для полноценного клиента, чтобы я мог в кишки залезть в случае чего и пока это ключевой момент, буду думать над этим риском.
В UE та же самая СЖВ тема, но он крупный и стабилен, а здесь хороший небольшой движок и сразу какая-то СЖВ ебала вылезла и ебанат на разрабе, сегодня они анимеаватарками и трамподебилами галлюцинируют, а завтра вся их деятельность схлопнется до гендернонейтральных названий переменных и отработку повесточки, начнут искать обижающие кого-нибудь игры на годоте и отменять разрабов.
Что это за там такая иконка робота оранжевая красивая? Не могу видео посмотреть.
форк gotoda, под названием Reddot который запилили после драмы неадекватных модеров из лгбт.
А эти адекватные форкеры уже смогли поменять иконку внутри движка? Или до сих пор не могут понять, как это делается? Ну хоть спизженый логотип заменили, и на том спасибо.
Да там целая драма видео смотреть нужно. На рутубе посмотри
>На рутубе посмотри
Ахуеть, лахта на срачи про годот переключилась.
Так там за лого голосование все это время шло, сегодня только определили какое итоговое будет.
>Записывает видно о игровом движке и его форке
>Не знает, что такое форк, потому полез в википедику узнавать
>Не смог понять, что такое форк, но все равно идёт нести своё невежество в массы.
Идиотам неважно на какую тему вещать, идиотам нужно просто поскорее записать видосик на хайповую тему, а другие идиоты и схавают. Уноси отсюда своё говно и больше не возвращайся.
Еще парочка с одного места только с разных сторон от забора что бы уж точно понятней было.
Под эти версии нет SDK для обработки платежей в тех же Яндекс играх
И почему такая анимация редко бывает в играх?
прокрастинирую
>текстуры то пропадют то появляются
>>978418
>с разных сторон от забора
Гадать сложно, можешь модели скинуть? Либо дай ссылку, с которой их скачивал. У меня таких проблем с 3D в Godot нет - полагаю, твои модели в чём-то кривые. Тем более если скачивал бесплатные - они часто имеют много ошибок, которые приходится фиксить в Blender вручную. Но чтобы пофиксить, нужно знать, в чём могут быть проблемы, например:
- двойная геометрия: случается, когда случайно дублируешь меш и забываешь удалить/сдвинуть (исправить легко - обычно достаточно объединить вершины меша по расстоянию: m -> by distance);
- двусторонние материалы: в Blender по умолчанию материалы двусторонние, тогда как в геймдеве предпочтительнее использовать односторонние;
- разница в разрешении буфера глубины камеры: по умолчанию дальность видимости в Blender низкая.
Проблема могла начать проявляться из-за этого:
https://godotengine.org/article/introducing-reverse-z/
Вкратце - теперь разрешение буфера глубины выше вдали от камеры и меньше вблизи камеры - так сделано, например, в GTA V, чтобы рендерить на большой дистанции с меньшими проблемами.
Однако, не значит, что модели были правильными.
>завтра вся их деятельность схлопнется до гендернонейтральных названий переменных и отработку повесточки
"Завтра" наступило больше 6 лет назад, например:
https://github.com/godotengine/godot/pull/22087
Даже Хуан изначально был против такого:
https://github.com/godotengine/godot/issues/7986#issuecomment-285355251
>I'm all for stuff like inclusion, equality, human rights, etc. But using less clear and accepted technical terminology for groundless cause (IMO) is not a good idea.
>>978341
>из-за того что туда залезла сжвшная падаль, которая всё в говно скатывает, то это говорит теперь о значительной нестабильности проекта
Прочитай целиком и внимательно эту страницу:
https://godotengine.org/code-of-conduct/
Основные пункты не менялись много лет. Так что успокойтесь уже - Godot всегда был частью "SJW" и останется таким же, ничего в его управлении не изменилось радикально за последние годы, все ключевые разработчики согласны с этим, а всем несогласным уже давно указали на дверь.
Единственное, что произошло на неделе - в твиттере ультраправые ВНЕЗАПНО обнаружили, что среди инструментов разработки бывают такие, что им противны чисто идеологически. Вот и разгорелся холивар, типа "вы неправильно движок делаете", несмотря на то, что в играх они вообще не шарят - проблема для них заключается в code of conduct.
Не пойму, чего ты ожидаешь, что за тобой будут бегать уговаривать остаться? Тред не про это.
Делать какие то выводы по истерикам в соцсетях это вообще смешное занятие.
Я недавно наблюдал за скандалами в Hasbro (D&D и MtG)
И каждый раз их проеб вызывал кучу видосов с "аналитикой" что вот вот их отменят.
Сначала они отправили по ошибке стримеру раньше времени карты, он их заспойлерил, и они прислали натуральных вышибал как в ГТА "вернуть их частную собственность". Все подняли шум на беспредел - и ничего, вообще никаких последствий.
Потом повторилась история с новым рулбуком D&D. Его разослали обзорщиком, а когда те сняли видосы, начали писать им C&D письма требуя заблюрить тексты книги. Все тоже подняли волну возмущения, топовые контентмейкеры, и ничего.
Была история когда они переиздали какую то шуточную расу бегемотов из космоса 80-х которая всех оскорбила потому что нацики. Вот там писали что их сейчас как отменят! И ничего, написали какой то корпоративный пост мол это часть истории, так и надо.
Потом была волна хейта что то вводят микроплатежи, то отнимают купленные PDF, то еще что-то, скандал на скандале! Потом был скандал что планируют заменять всех живых ГМов ИИ-чатботами, и игра станет без души! Там им такууую отмену прогнозировали, что вообще не оправятся! И ничего.
В конце концов появился новый рулбук, в котором сразу нашли несколько поломных механик, ломающих всю игру! Ну вот тут то уж точно надо все отменить и они разорятся! На каналах других настольных игр в комментах было беснование - мол я так и думал, хорошо что я давно сменил ту игру на другую, поделом им.
И что в результате? А ничего, в очередной раз продажи рулбука побили все рекорды.
При этом, был случай когда фильм по D&D таки отменили, не пойдя в кинотеатры и он провалился. Ну такое угадывать 1 раз из 10.
Напомню что в твиттере многие написавшие вообще не разработчики, и не понимают как работает опенсорс (призывали "CEO" кого-то "уволить"). Потому что это вообще мало отношения к движку имеет, а имеет к проходившей в те дни агитации к выборам в США.
>https://godotengine.org/code-of-conduct/
Добавлю что похожие КОКИ лол имеют почти все опенсорс проекты, включая ядро линукса с его перманентно матерящимся Торвальдсом. Так и живем.
И кстати его по нему увольняли на полгода за мат, и что? Вернули, да и линукс никуда не исчез.
Да, gnome тоже прогнозировали смерть от засилья жопотрахов, нанятых по квоте, и воткнутого кока. Но вроде тоже живет пока, в десктоп тредах его все еще чаще вижу чем любую другую DE.
>>978379
>>978371
>>978333
Тебе хоть платят за эти посты или ты лох, бесплатно копротивляющийся за гомобарена?
Лучше! Скачиваем тулзу scc (счетчик строк кода) и запускаем на репозитории годота. Получаем минимальную оценку в $120млн. Никакие "платы" не сравняться с тем, какую ценность Хуан (внесший львиную долю в миллион строк кода) с другими контрибуторами подарили человечеству.
Когда любой может скачать бесплатно продукт ценностью 120 миллионов долларов, тут никакая оплата в +15 центов не акутальна, лол.
Вот тут ты не прав, гном стабильно деградирует скатываясь в анальный цирк. Он жив благодаря тому, что его пихают несколько крупных дистрибутивов и есть жирный пласт пользователей которым DE нужно только чтобы браузер запустить. С игровым движком такая ситуация не прокатит.
>счетчик строк кода
>миллионов долларов
Прости, но это уж слишком жырно...
>>978558
>нужно только чтобы браузер запустить
В индустрии нужно только ассеты закинуть.
>>978473
>бесплатно копротивляющийся
А за кого копротивляются хейтеры?
У любого ПО есть преданные фанаты.
Только в опенсурсе фанатизм оправдан.
>счетчик строк кода
>миллионов долларов
Я не совсем правильно посчитал, забыл удалить папку third party. чтобы считать только код годота.
Там в районе миллиона строк кода на с++. Так вышло на $50 млн долларов.
Но это некритичная неточность, ведь это оценка снизу, а ведь есть еще поддерживаемая 3-ка, в которой не весь код дублируется. А еще если прибавить некоторые мастхев ассеты.
Знаешь ли код не появляется сам по себе. Его пишут программисты. Утилита просто умножает его количество на зарплату.
>код не появляется сам по себе. Его пишут программисты. Утилита просто умножает его количество на зарплату.
Твоя утилита считает число строк и умножает их на попугаев, лол. Можно написать тупой процедурный генератор рабочего кода, который высрет за день миллиарды строчек без единой ошибки компиляции. Утилита насчитает тебе триллионы попугаев. И что?
Строчки кода в проекте зависят от принятого стиля оформления, используемых библиотек и прочего. Нормальная разработка требует не только писать дополнительные строчки, но и удалять или менять имеющиеся строчки кода. А труд программистов в разработке зависит от очень многих причин, но не количества строк кода в финальной версии.
В лучшем случае формулы в твоей утилите созданы статистически на основе нескольких известных и достаточно типичных проектов. Но даже это не гарантирует, что результаты будут хоть немного адекватны для любого другого проекта. В худшем - формулы и коэффициенты тупо взяты с потолка.
Оценка проекта по числу строк - это мем уровня зарплаты программистам по числу новых строк.
Даже читать не стал твою демагогию. Там какой нибудь торг за каждые 0,01 %
>Знаешь ли код не появляется сам по себе
Вообще-то уже появляется. гпт уже могут писать код получше местных макак. Разумеется, что код написанный сеньором будет лучше, но много ли сеньоров по сравнению с тем, что уже может выдать гпт.
>называть ноду с игроком не Player, а Gay
Ну давай разберём по частям слово player.
P = penis - популярное в английском сокращение.
Layer - это тот, кто делает lay, либо слой.
Lay - класть, накладывать.
Значит player - сокращение от penis layer:
- тот, кто накладывает пенисы друг на друга;
- слой уже наложенных кем-то пенисов.
Пенисы - это как-то по-гейски, особенно если слоями.
Вывод: player достаточно гейский, менять не нужно.
Вопросы?
Гетеросекам предлагаю Vlayer (vagina layer).
Годот уже написан, а нейронки еще только начнут писать код. Когда они напишут свой движок, тогда можно будет говорить о обесценивании других. В конце концов это нормально, поезда обесценили караваны повозок, но до них то они работали. Да и так то они тоже не бесплатно пишут, кто то считал, мол, если он тратит $20 в день за пару часов чатгпт, то в месяц это будет $600.
Не, не катит. Предлагаю переделать твою архитектуру под мультиплеер.
А то у нас в команде много людей шарящих за разработку и арты, но никто заниматься пиаром не хочет. Я вот сижу, ковыряюсь в Годоте и думаю что надо это все исправлять. Как проект продвигать еще на этапе разработки, чтобы у него больше 3 обзоров в Стиме потом было?
>гпт уже могут писать код получше местных макак
Я уже как год слышу про то что программисты вымрут нахуй, а воз и ныне там. Художники уже три года как должны бомжевать.
Самое эффективное, но и самое сложное - забрасываться к ютуберам/стримерам. Самое простое и бесполезное - забрасываться в геймдевовский эхо-чембер типа r/gamedev или /gd/
Теперь плоти за совет скрином вашей игры.
Вымрут не вымрут, но я с помощью claude "написал" себе два шейдера с нуля, третий оптимизировал чтобы он фпс не еб.
>Теперь плоти за совет скрином вашей игры.
Ну держи.
Скрин из тренчбрума. Для карт у нас через Trenchbroom + Qodot в Godot.
Хоррор, банально да, но для первого реального проекта в Стим лучше что попроще. Шутан можно полгода только балансить так чтобы в него играть приятно было.
Либо у нас в общем ньюфаготреде, либо в /b тред создай - там народу больше и игроков и школьников. Но в /б будь готово, что тебя отпидорасят намного жёстче, чем тут.
Такова современная жизнь, что есть, то есть.
А часть вообще забанена.
Похоже на z-fighting, как будто у тебя два меша слились, на одном есть текстура, на другом нет
Делаю игру с гексами. Нужно ли мне использовать "Dijkstra’s Algorithm" или Astar закрывает все мои потребности? Не особо секу в теме. Алсо, есть ли туториал? А то все видео по astar только для стандартной квадратной сетки
Разберись как в принципе работают эти алгоритмы, потом уже используй. Мне вот вообще D Star Lite зашёл
Емнип Дейкстра это для клеток с равными значениями (например шахматное поле), а A более продвинутый с весами для переходов (например поле Цивилизации, с горами, полями, лесами, дорогами).
Еще кажется читал, что Дейкстра в отличии от А работает если неизвестна конечная точка. Хз так ли это, но это может быть важно в каком-то эксплорейшене с закрытой информацией.
Обрати внимание что эти алгоритмы работают с узлами, а не квадратной сеткой, поэтому ты можешь переписать банально клеточный вариант в гексовый, просто надо в качестве соседей добавлять 6 гексов, а не 4 клетки.
Значит я неправильно понял.
Получается так
Broad Searh First без весов
Дейкстра с весами
А Стар с весами, и еще с оценочной функцией.
Оценочная функция должна быстро приблизительно оценить расстояние от текущего узла до конечного. Видимо поэтому он оптимальнее на квадратных сетках. Дейкста бы перебирал все грани по честному. АСтар может использовать оценочной функцией манхеттен и сначала проверять грани в направлении к цели.
.NET позволяет писать кроме гдскрипт на C#, билд становится чуть тяжелее (может быть неприятно на мобилке) и вроде до сих пор недопилен экспорт в веб.
Обычная только гдскрипт, которого впрочем достаточно для огромного кол-ва игр
Кроме того я ярый приверженец продолжать сидеть на годот3
Годот3 это opengl, не очень соверменный, но работает много где. Включая мобилки, веб. Для него практически перестали выходить аддоны, но существующих хватит на много чего.
Годот4 это вулкан, сам по себе дает больше возможностей который скорее для АА+ проектов на десктоп с кучей спецэффектов. Для веба там куцый порт опенжл без всех фичей.
Учитывая реалии, например веб в яндекс игры, я продолжаю сидеть на годот3, лоуполи 3д либо 2д, с фиксом звука через js.
А игру мечты точно точно когда нибудь на годот45 сделаю.
1. Имею глобальный скрипт Signals, который использую для передачи сигналов.
2. Пользователь вводит текст в соответствующее поле и нажимает отправить. Создается экземпляр сообщения. В коде отправляется сигнал с текстом.
3. Сигнал принимается всеми созданными сообщениями, а не только что созданным.
Я сталкивался с подобной проблемой, когда типа наносишь урон одному врагу, а получают все, но уже не помню, как это исправить, если вообще исправлял.
Как вариант - применять соответствующую функцию сообщения, но это вариант, т.к. мне так же нужен будет текст для обработки в других сценах(Чат-бота создаю).
Поэтому мне бы хотелось добиться того, что сигнал остается, желательно глобальным, но применяется лишь к только что созданному сообщению.
Хз, я сплю и лень вникать. Подходы такие - ты либо цепляешь сигналы ровно на нужные ноды, либо при получении сигнала через дополнительные аргументы (передаются через коннект) проверяешь а должен ли получатель вообще обрабатывать полученное.
Тут сигнал не нужен.
Там где ты делаешь add_child(message) назовем это место менеджер. Потому что он ей управляет, выставляет в нужное место.
Так вот менеджер уже и так держит в руках в этот момент объект message
Ты можешь сделать тупо вызов функции которую сам задашь message.set_message(,,,)
Или присвоить переменную message.my_text = ...
Второе может быть проперти с setget если надо дополнительная логика внутри той сцены.
Если же говорить про сигналы. Сигнал получают все объекты, которые на него подписались. Ну ты каждый подписывал, вот они все и продолжают получать. Вообще то от сообщений и отписываться можно.
Сигналы по сути это такой хитрый способ вызывать функции, так то. Просто без указания объекта.
Вместо message.function(args)
Делается message.connect(signal);
emit_signal(signal, args)
И если очень надо, то ты в аргументах можешь передать и что-то вроде айдишника объекта которому надо принять сигнал.
Конечно это будет неоптимально, ведь сигнал разошлется все равно всем, но каждый объект может проверить, ему ли это сигнал.
Также тут теоретически может быть подводный (не факт, что в этом случае). Допустим ты создаешь объект и тут же посылаешь сигнал. Вот тут я точно не помню, но не уверен, не может ли так получиться, что объект еще не зарегистрирован, и он не успеет получить сигнал.
Дальше перепутал,
some_signal.connect(signal, message)
Вообще это писал к тому, что в данном случае переменная message нужна в момент подписки, но в отличии от вызова функции, она не нужна в месте вызова функции, а будет найдена автоматически
emit_signal(signal, args)
>Ты вообще не понимаешь, как система выглядит в целом
Для этого пишут документацию проекта и всякие там uml диаграммы
Та, то есть ты хочешь сказать что в сложном проекте ты в лапше разберешься?
Если это шутка то не очень смешная.
И как быда uml никто не отменял.
Про дебагеры я вообще молчу.
Ты про удаление визуал скриптинга?
Это тупиковая херня, которая даже в ue особо нахер не нужна, по сути она нужна чтобы не ебаться с утечкой памяти и геймдизайнер мог быстро и коряво собрать какую то фишку.
Как по мне, код гораздо проще и читабельнее. У меня от лапши начинает болеть голова и я очень быстро теряю смысл. А код читается легко, а если что-то большое, то документация. Но обычно и так понятно, если программист придерживается нормального нейминга.
Собираюсь сделать игру, меня интересует редактор персонажа.
Хочу брать 3д ассеты (Daz 3d или Blender но думаю лучше Daz 3d)
и мне надо сделать редактор персонажа со сменяемой одеждой и изменениями тела.
Пока кручусь вокруг да около все гайды на ютубе как будто изобретают велосипед каждый раз c нуля. Изобретать редактор не очень охото, предвкушается уже работа только над этой частью месяцами без начала создания даже самой игры что меня очень угнетает.
Что есть готового на эту тему ?
Какой-то может плагин/екстеншен классный в библиотеке годот который решает эту задачу ?
Так же если есть текстовый гайды тоже буду благодарен
Так же интересны редакторы 2д со сменяемой одеждой но походу опять же с моего поверхностного поиска это окажется гораздо сложнее потому что неоткуда брать ассеты с одеждой и сложнее подгонять их под 2д а для 3д есть большое количество уже готовых.
Блядь, научитесь составлять реквесты нормально. Тебе надо реализовать редактор на движке или редактор чтобы картинки там делать для спрайтов? Ёбаный в рот. Если второе, то даз это литерали редактор персонажа, если первое, смотри как это кодить/пизди готовое. Накотал простыню, вопроса так и не задал.
ну надо чтоб в игре чел создавать мог персонажа и потом переодевать его и чтобы одежда менялась
>без начала создания даже самой игры что меня очень угнетает
Так и не начинай редактор персонажей.
Тебе первое что нужно собрать это минимальную демку геймплея. На остальное похуй, на графон тоже.
Самый простой вариант - делаешь в редакторе кучу пресетов-болванок, потом добавляешь их в качестве "опции" сменой по кнопке в условном "гардеробе" в игре. Ничего сложнее тебе не надо/ты не осилишь, судя по уровню вопроса.
Годот перекрывает все мои потребности в разработке, а именно ныть итт, так что иди нахуй
>Собираюсь сделать игру
>меня интересует редактор персонажа.
Буквально одна из самых простых вещей
>Что есть готового на эту тему ?
> все гайды на ютубе как будто изобретают велосипед каждый раз c нуля
Бери любое понравившееся решение и интегрируй в свой проект
>предвкушается уже работа только над этой частью месяцами
МВП редактора делается за неделю новичком в годоте
>без начала создания даже самой игры что меня очень угнетает.
Ты вообще себе представляешь процесс создания игры?
А вообще вот тут тебе анон правильно написал >>978877
Что ты вообще делаешь? Какова твоя идея? Может тебе лучше присмотреться к чему-то вроде рпг мейкера?
>Буквально одна из самых простых вещей
Ну это смотря какой редактор, если там как тут >>978878 просто 3d модельки свапать, то простая, но он там походу полноценный йоба редактор хочет иметь.
>полноценный йоба редактор хочет иметь
Ну в соло/инди разработке это особого смысла не имеет, т.к. на редакторе разработка и кончится
Смотря какой уровень детализации. Если по пресетам пощелкать на уровне моровинда - нарезаешь свои 3д/2д модельки на меши/спрайты и перещелкиваешь соответственно. Если уже как обливионе со слайдерами то хуй знает, не рекомендую туда лезть.
Я думаю она у него ещё до редактора закончится, на ютуб роликах.
Читай документацию вместо того, что читаешь.
https://docs.godotengine.org/en/stable/classes/class_signal.html
Объявить сигнал:
>signal message_sent(text: String)
Запустить сигнал:
>message_sent.emit("text")
Подключение сигнала:
>sender.message_sent.connect(_on_message)
Обработчик сигнала:
>func _on_message(text: String) -> void:
Это новый, лучший способ для Godot 4+.
>Создается экземпляр сообщения.
Ты путаешь UI ноды Godot с логикой программы. Тебе необходимо абстрагироваться от сцен и нод, если хочешь создать что-то сложное.
Тем более некорректно Control-ноды используешь:
1. Node2D здесь вообще не нужен, он портит Control.
2. Вместо Panel тебе явно нужен PanelContainer.
3. Для чата потребуется ScrollContainer.
4. Для адаптивного UI нужно больше контейнеров.
>нужен будет текст для обработки в других сценах
Так и храни этот текст в каком-то месте, например:
>var chat_history: PackedStringArray
https://docs.godotengine.org/en/stable/classes/class_packedstringarray.html
Если нужна дополнительная информация, такая, как отправитель, время отправки/получения сообщения и прочее, тогда Dictionary или свой кастомный класс.
А потомки Node, в частности Control - это "viewer":
https://en.wikipedia.org/wiki/Model–view–controller
Тебе необходимо сначала создать "model".
Алсо, глобальные сущности - опасный костыль, их желательно избегать при возможности. Чем меньше глобальных сущностей в твоём проекте, тем лучше.
>https://en.wikipedia.org/wiki/Model–view–controller
https://ru.wikipedia.org/wiki/Model-View-Controller
Изучай
Для 3ки
>>874602 →
https://github.com/fernandolv33/lowpoly-chmaker
https://github.com/smix8/Godot3DCharacterEditorWardrobe
https://github.com/Grumoth/godot-character-creator
Для 4ки
https://github.com/TaperingBirch/Character-Creation-Demo
хз
https://github.com/RiseRobotRise/CharacterStudio
https://github.com/game009f/godot-character-creation
Чел делает платный
https://thowsenmedia.itch.io/godot-character-creation-suite
Он в какой то момент выкадывал на гитхаб, но сейчас интернет архив уронили и не посмотреть.
>визуальный скриптинг они зря убрали
Не зря. Он оказался никому не нужен. Читай это:
https://godotengine.org/article/godot-4-will-discontinue-visual-scripting/
>>978811
>Годот не нужен без визуал скриптинга.
У Godot есть GDSctipt, в отличие от других движков.
Старый VisualScript можно вернуть и доработать:
https://github.com/godotengine/godot-visual-script
>Я дебил что ли, всё вручную писать?
>У меня одна жизнь.
Когда я пытался изучить VisualScript в Godot 3.x, быстро осознал, что мышкой таскать эти дурацкие ниточки намного дольше и сложнее, чем быстро, решительно строчить код. Может быть, лично ты мучаешься из-за своей низкой скорости печати?
>>978831
>насчёт наглядности, код - просто сосёт.
>Когда проект сложный, это что-то с чем-то.
Это проблема архитектуры проекта, а не кода.
>Старое забывается.
>не понимаешь, как система выглядит в целом.
Для этого существует дизайн-документ игры.
GDScript также позволяет писать документацию:
https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/gdscript_documentation_comments.html
>>978859
>где над игрой работают десятки человек.
>без визуального представления не обойтись.
ПРОСТО не подпускай слабоумных дизайнеров к редактированию кода. Это твоя работа, директор.
>А в одиночку игру высокого класса сделать невозможно.
Почему же? Возможно. Буквально сегодня читал:
https://en.wikipedia.org/wiki/UnReal_World
- начал ещё в 1992 году
- делает в гордом одиночестве
- ещё в нулевых собрал кучу наград
- продолжает развиваться до сих пор (2024)
>UnReal World has been praised for its depth, realism, atmosphere and immersion, and value. In 2015, Rock, Paper, Shotgun listed UnReal World as the 26th best role-playing game on PC.
>над игрой работают десятки человек
Ещё забыл добавить - в Godot есть это:
https://docs.godotengine.org/en/stable/classes/class_graphedit.html
Изначально эта система создавалась и до сих пор используется для визуальных шейдеров. На счёт скриптования не знаю, та же это система или нет, однако, ничто не мешает использовать её для собственных аддонов. Ограничений по сути нет, совершенно любой может создавать свой аддон.
Так вот, если представить себе абстрактную студию, работающую над игрой на Godot - у неё 100% будет специальный человечек на подскоке, который сам разработает аддон для слабоумных дизайнеров.
Более того, такой кастомный аддон будет намного полезнее любого языка общего назначения, ибо он решает конкретную, чётко поставленную задачу:
https://ru.wikipedia.org/wiki/Предметно-ориентированный_язык
VisualScript же был аналогом GDScript, и поэтому обосрался - визуально общее программирование совершенно никому не нужно, т.к. слишком много низкоуровневых операций, которые проще текстом набрать, чем ниточки между блоками натягивать.
>Хочу брать 3д ассеты
>неоткуда брать ассеты с одеждой и сложнее подгонять их под 2д а для 3д есть большое количество уже готовых.
На готовых ассетах ты далеко не уедешь...
Если у твоего 3D меша есть блендшейпы, тогда:
https://docs.godotengine.org/en/stable/classes/class_meshinstance3d.html#class-meshinstance3d-method-set-blend-shape-value
Если блендшейпов нет, то всё НАМНОГО сложнее.
Из личного опыта: лучше создавать персонажа в Блендере на собственном скелете с анимациями, экспортировать в Godot одним GLTF файлом, и вся кастомизация в Godot будет состоять из:
- значения блендшейпов (размер груди, форма лица);
- переключение видимости разных мешей (одежда);
- изменение материала (текстура, мелкие детали);
- изменение цвета (тон кожи или цвет одежды).
В Godot тебе нужно только UI сделать и всё.
Пиздец кринжуха, прямо как будто из этого раздела кто-то, нихуя не сделано, ничего не готово, задо гонору дохуя, а в планах захват мира своим продуктом.
Там в шапке есть редактор персонажей, но он довольно стар и автор куда-то пропал.
>1 пик
Почему он нажимает на кнопку "male", но генерируются одни женщины?
За такой вопрос тебя надо забанить в движке Godot, зарепортить куда надо следует.
>генерируются одни женщины?
Попробуй найти этих женщин на пикриле.
Что ты вообще делаешь? Какова твоя идея?
Adult игру дейтинг сим
> Может тебе лучше присмотреться к чему-то вроде рпг мейкера?
у отвращение к играм на нем я их даже никогда не скачиваю
>Ты вообще себе представляешь процесс создания игры?
Ну там gameloop хуе-мое, несколько механик,карта мира с переключением локаций, смена день-ночь, ходить на работу, платить за квартиру
>>978878
Ну я программист системный но абсолютно не умею рисовать ниче и тем более моделить или кастомить модели так что все собирать буду из пресетов
>>978877
Вот за это вот спасибо, такое вот и пришло первое в голову но появились сомнения и мысли что это какая-то костыльность и мб есть какие-то лучшие решения и решил спросить тут.
Я прогнал через декомпилятор и реверсинженернул одну игру свою любимую и ахуел сколько там слоев на каждую часть тела, сколько видов вариаций глаз, форм рта на каждый эвент чтоб отобразить эмоцию и там редактор персонажей встроенный но мне удалось только спрайты вытащить но даже чтобы из них из всех готовых 2д кусочков тела воссоздать просто систему всю это ебанешься просто. Там достаточно много деталей а не примитив уровня rimworld
>>978911
Спасибо
>>978940
По-моему в daz-3d все гораздо проще ну и мне нужна одежда а как и где я буду брать это для блендера я хз, на сколько я понял это нереально взять одежду с одной модели и натянуть ее на другую модель другого автора а в daz-3d одежда натягивается на любую модель изи что просто имба фича
>>978980
Я его смотрел, он вроде действительно заброшен
Не собираюсь локализировать, храню в экспорт-переменных, пишу в инспекторе.
Весь текст в csv файлах разной локализации. В конкретных узлах подвязываю к ключ-слову. Сорт оф словарь
Буквально женщина с ромбом и прямоугольником в верхнем ряду
А он нужен вообще?
И на каком языке скриптниг быстрее всего работает?
Для тебя язык узким местом не будет в любом случае, не переживай. Если С# не знаешь - бери обычный годот с гдскриптом.
Ого, так Godot автоматически csv как файлы локализации импортирует. Интересно. А как можно средствами csv полям с сообщениями присвоить актеров, что эти сообщения "производят"? Записывать в само поле имя/идентификатор, а затем его отделять? Или создать столбец искусственной локализации actors, и из него по индексу подхватывать? Или есть поудобнее способ?
А .Net версия без гдскрипта что ли?
>>979040
Что значит хуже, это может быть критично?
>>979050
А есть версия, где поддерживается всё и сразу, чтобы не париться?
А скриптинг на C++ до сих пор поддерживается или больше нет?
И этот код компилируется перед выполнением или нет?
На летку это происходит или нет?
И есть ли его интерпретатор?
C++ есть всегда и везде. Чел, раз ты задаешь такие вопросы и делаешь это так долго и упорно, ничто из этого не станет для тебя узким местом. Просто бери базовый годот и начинай делать на гдскрипте. Хватит отлынивать.
Ох уж эти вопросы в стиле - какое очко быстрее высрет кал? А то я боюсь что кал будет поступать в глодки игроков не достатично быстро и бесперебойно.
Ведь у меня 2 пульки летят и я боюсь что мой говнокод на годоскрипте будет тормозить на плюсах говнокод не будет, мне так сказали.
>Стоит ли ебаться с цветокоррекцией
Скриншот покажи хоть. Какой у тебя стиль?
>синеватые тени выглядят всрато
Тени не обязательно должны быть синеватыми. В реальности, оттенок теней зависит от цвета света, отражённого от окружающих предметов. Синими становятся из-за отражённого от синего неба света. Пасмурная погода делает тени более серыми, чем безоблачная; зимой тени более чисто-синие, т.к. в летнее время растения добавляют зеленоватый.
Так что нужно смотреть на конкретную сцену.
>А скриптинг на C++ до сих пор поддерживается
1. Можно форкнуть движок и менять его C++ код.
2. Можно https://github.com/godotengine/godot-cpp
>И этот код компилируется перед выполнением
Естественно, ты должен скомпилировать исходники.
>На лету это происходит или нет?
Не знаю; но знаю, что C++ медленно компилируется.
Вот, например, Pascal компилируется мгновенно.
>И есть ли его интерпретатор?
Зачем тебе интерпретатор C++?
>>979088
>боюсь что мой говнокод на годоскрипте будет тормозить на плюсах говнокод не будет
Неоптимальный код можно высрать на любом языке. Компилятор C++ применяет оптимизации, но если не разбираешься в C++, тогда он тебе вряд ли поможет.
Как минимум, в C++ ты должен сам следить за выделениями и освобождением памяти. Если не уследишь, то получишь утечку (RAM заполняется до переполнения и Windows останавливает твою игру).
Как разные языки решают управление памятью:
C# - лишние объекты заполняют память как будто возникла утечка, а потом сборщик мусора тормозит приложение и распутывает клубок зависимостей, определяя, какие объекты всё ещё кому-то нужны.
GDScript:
1. Потомки RefCounted, включая Resource: считают количество ссылок на них, удаляются сами сразу, как только счётчик ссылок дойдёт до нуля. Нюанс: нужно избегать циклических ссылок (А -> Б, Б -> В, В -> А).
2. Потомки Object и Node: нужно удалять вручную. Разница между free() и queue_free() в том, что free() удаляет объект сразу, а второе - под конец кадра. Поэтому для Node лучше использовать queue_free().
>Будет. 100%.
Пускай код будет на 50% медленнее, это так плохо?
По-моему, главное, чтобы:
- код был легко читаем, без лишних спецсимволов;
- его можно было быстро и просто редактировать;
- его можно было запустить на выполнение сразу.
GDScript этим параметрам удовлетворяет.
>Если есть хоть какая-то логика сложнее чем 2+2
Тут тоже не всё так однозначно.
1. Если у тебя там вызовы API движка, то ты в любом случае ограничен бутылочным горлышком API. А в некоторых случаях код на GDScript будет быстрее. Потому что GDScript оптимизируют под Godot. Это причина, по которой не взяли существующие СЯП.
2. Если ты делаешь какой-то сложный алгоритм, то удобнее и быстрее его разрабатывать на GDScript. Потенциальные задержки на компьютере игрока вообще не должны тебя волновать, ибо ты вряд ли доберёшься до этого. А потом, если вдруг, по некой волшебной причине, ты доберёшься до релиза и внезапно кто-то захочет поиграть в твою поделку, то переписать существующий код на другой язык намного проще, чем изобретать что-либо с нуля.
>По-моему в daz-3d все гораздо проще
Вот только там нужно платить за каждую шмотку:
https://bugs.daz3d.com/hc/en-us/articles/207532343-What-Can-I-Use-Daz-3D-Figures-for-Legally
>нереально взять одежду с одной модели и натянуть ее на другую модель другого автора
Реально, если разбираться в Blender.
>Adult игру дейтинг сим
>абсолютно не умею рисовать ниче и тем более моделить или кастомить модели так что все собирать буду из пресетов
Для симулятора свиданий тебе нужно очень много оригинального графического контента. Кто захочет играть в очередной ассетфлип в этом жанре? Те же модельки из Daz3D слишком бросаются в глаза - я вот вообще игнорирую всё, что похоже на Daz3D.
Так что либо учись графике сам, либо ищи кого-то, кто согласится за деньги помогать с графикой.
>Будет. 100%.
Та ну, ты угараешь 99% логики в играх (исключая некоторые жанры типо стратегий и т.д.).
Не будут тормозить пока ты массив в массив не запихнешь.
>>979091
>Если есть хоть какая-то логика сложнее чем 2+2 её надо выносить в нормальные языки.
Это из разряда вредных советов - все надо писать на c++. А потом через 7 лет разработки выкатывать рогалик на 16 отзывов в стиме
Вообщем то даже на ue шной лапше есть игры и нормально. В ue5 они даже нативизацию отключили и стало, не просто медленно, а просто ад как медленно и ничего.
>>979093
>Неоптимальный код можно высрать на любом языке. Компилятор C++ применяет оптимизации, но если не разбираешься в C++, тогда он тебе вряд ли поможет.
>
>Как минимум, в C++ ты должен сам следить за выделениями и освобождением памяти. Если не уследишь, то получишь утечку (RAM заполняется до переполнения и Windows останавливает твою игру).
ЗАчем ты мне это пишешь я имею об этом представление?
>Как вы храните т.н. data в игре?
Зависит от того, что это за данные...
>Как вы бы хранили локализацию
https://docs.godotengine.org/en/stable/tutorials/i18n/
>Каким бы образом проигрывали эти очереди диалогов? Как бы привязывали эмоции актеров к конкретным инстансам диалога?
Можешь попробовать готовые решения:
https://github.com/dialogic-godot/
https://github.com/rakugoteam/
Есть много других, но эти два вроде как основные.
>ЗАчем ты мне это пишешь
Потому что ты задаёшь вопросы, которые задают новички, которых волнует только "код быстрее". В программировании скорость рантайма не всегда настолько важна, чтобы жертвовать остальным.
>просто ад как медленно и ничего
Фотореализмодрочеры любое говно схавают, лишь бы фотореалистично выглядело. А то из подвала они никогда не выбираются, внешний мир не видят.
>пока ты массив в массив не запихнешь
Зависит от размеров массивов. Сетка 10x10 будет нормально обрабатываться даже на CPU из 2007.
>Вот только там нужно платить за каждую шмотку:
хз полно бесплатных пиратских асестов просто дохуище
ифибо:
>аряяя ты должен использовать только лицуху и за все уплатить
я так не думаю, отьебись, да я пиратская пидораха и что ты мне сделаешь ?
>Реально, если разбираться в Blender.
начну сразу как только выпущу пару коммерчески успешных проектов из пиратских ассетов и хватит открыть свою геймдев студию с нанятыми художниками а пока это просто будет синдромом вечного студента, вместо создания игры
> Для симулятора свиданий тебе нужно очень много оригинального графического контента.
Там главное история-сеттинг и нишевые фетиши.
> Кто захочет играть в очередной ассетфлип в этом жанре?
открываешь топ кассовых игр в этом жанре и обнаруживаешь там на 90% его забитым именно таким. Ты видимо не смотрел вообще ассортимент и количество этих ассетов потому что их просто нереальное количество + можешь относительно не сложно кастомить модели пересаживая им лица от других моделей и у тебя уже оригинал прессет а не просто дефолтный ассет.
>Так что либо учись графике сам, либо ищи кого-то, кто согласится за деньги помогать с графикой.
типикал усредненный двач совет, где тебе обосрут любую идею и будут убеждать что у тебя ниче не получится и что тебе не стоит и начинать и вообще надо несколько миллиардов баксов минимум иметь и нанять аж Кодзиму а то даже браться не стоит за работу.
Странно что еще не предложил изобрести свой личный гитхаб для кода а то существующий брать не комильфо и свой личный движок а перед этим свой личный язык программирования для этого.
>Так что либо учись графике сам
> либо ищи кого-то, кто согласится за деньги помогать с графикой.
Я ничего не имею против того, чтобы и учиться и брать помощь за деньги в графике если дело пойдет но на данном этапе overthinking и изучи концепцию lean startup-ов и сделай игру свою хоть какую-нибудь и доведи до стора
Я не спрашиваю а стебусь, если соорказм был не понятен ... Ну бывает.
Все прекрасно понимают что маленькие массивы быстро разберутся на любом языке.
Это утрированный пример, для понимания того что от говнокода язык не спасает и наоборот.
>Что значит хуже, это может быть критично?
Да, ну из самого очевидного и, что называется, "на поверхности" - нет поддержки интерфейсов шарпа. То есть IDE не будет жаловаться на интерфейсы, интерфейсы это ведь естественно для шарпа. Но результат в движке не будет тем, чего ты ожидаешь. Точнее результата не будет, но ошибок ты при этом не увидишь. И так на каждом шагу с С#. По крайней мере, было около года назад.
>>979113
На gdscript пиши. КОГДА, ВДРУГ и ЕСЛИ ты почувствуешь, что преисполнился, что скриптовые языки это больше не языки твоего уровня, и тебе с ними тесно, тогда уже сможешь расчехлить канпеляцию и углубляться в C++ внутрянку годота. Но до того обычно не доходит, хватает и gdscript. Дополнительные модули разве что иногда некоторые пишут на плюсах. Но это опять-таки перекомпиляции движка по полчаса - лично мне не хотелось бы таким заниматься. А про тебя я не знаю.
Ладно, спс, определился, качну обычную стандартную версию движка и на стандартном дефолтном гдскрипте буду учиться писать.
Мне бы ещё годный мануал для новичка с азов до про, английский на слух не воспринимаю.
Еще нет изменений на горячую, вообщем постоянный перезапуск проекта на шарпе, на гдс он вроде более мение нормально робит
Вообще слабо себе представляю места где прям таки тебе нужно перейти на ++ или что-то подобное. Обычно это моменты которые вызывают вопрос в стиле "а ты уверен что тебе нужен годот в принципе" или "ты уверен что в 1 лицо без опыта такое осилишь"
по годоту вообще мало чего то годного, на памяти был какой то 1 курс но не помню название.
Просто делай по годотовскому мануалу и не парься, или найди какой нить курс как сделать товер дефенс или что-то подобное.
Повтори, доделай для себя и там научишься.
>Чат-бота создаю
На GPT нейросетях или как-то иначе?
Интересно, т.к. тоже что-то такое пробовал.
>полно бесплатных пиратских асестов просто
Тогда ты можешь из чужих игр ассеты рипать...
>да я пиратская пидораха и что ты мне сделаешь
Я - ничего, но игроки, площадка и правообладатели оригинальных ассетов тебя могут и наказать.
>выпущу пару коммерчески успешных проектов из пиратских ассетов
Размечтался... Во-первых, добиться коммерческого успеха на ассетфлипах крайне сложно. Во-вторых, засветишься - и к тебе придут сдирать шкуру за ворованный контент. Притом по наводке игроков.
>открываешь топ кассовых игр в этом жанре и обнаруживаешь там на 90% его забитым
Симуляторов свиданий 3.5 на весь мир, и те японские.
Сразу скажу, что не всякая игра, что называет себя "симулятором свиданий" им является. Например, популярная Crush Crush - это кликер, а не симулятор свиданий. HuniePop - это три-в-ряд, а не симулятор. Множество игр имеют девочек и сюжет "свиданий", но это не делает их симуляторами свиданий.
>Странно что еще не предложил изобрести
Движок и язык геймплей не делают. Если у тебя все визуальные ассеты уже были в других играх, тогда игроки, пусть и тупые, но заметят и обосрут. А потом прилетит DMCA от какой-нибудь нинтенды и всё...
>сделай игру свою хоть какую-нибудь
С таким подходом можно что угодно высрать.
>и доведи до стора
На пиратских ассетах? Либо не пропустят, либо доиграешься и потом все игры удалят вместе с аккаунтом разработчика. Если это не помойка...
Воровать ассеты в геймдеве всегда было опасно, а последнее время тем более из-за прецедентов и агрессивно настроенных игроков...
>места где прям таки тебе нужно перейти на ++
По моему опыту обработка двумерных массивов, например: Game of Life, попиксельная обработка чего-то (например песочница аля нойта), динамический взрыв в радиусе с изменением тайлов аля майнкрафт.
Вон какой то свежий бенч, C# быстрее в 25 раз, с++ быстрее еще в 4 раза (в 100 раз).
Compute shaders не учитываю, поскольку их нет в 3-ке (если кто то не завез только), во вторых я ими пользоваться не умею, в третьих там вроде задержка при чтении результата обратно с видяхи, да и не у всех видяхи норм.
добавлю что чаще тормоза не от кода, а от: либо продвинутых спецэффектов (global illumination, просто много тяжелых шейдеров) или от физики 1000 объектов где все сталкиваются со всеми.
Другой анон врывается.
Опять подумываю пересесть на этот ваш годот. Пилю небольшие 3D-игрухи. 2D сейчас не интересно от слова совсем. Раньше несколько раз пытался пересесть, но каждый раз какая нибудь херня заставляла забить. Сначала сидел на гамаке и делал 2D. Это совсем древние времена были. На ныне замедленном находил полтора туториала. Хз то ли авторы рукожопами были, то ли оно так и должно быть. То же управление-перемещение перса в гамаке в строчек 10 кода делалось и работало заебца. У этих получалась простыня на 50-100 строк и по итогу говно. Я тогда знатно прихуел и забил на переезд. Потом полностью перешел на 3D. Когда вспоминал про годот, искал туториалы. По 3D толком ничего не было. Если было, то несколько серий показывали как качать движок и двигать куб на wasd. Потом мамка отбирала шнур от компа и на этом курс заканчивался. Где-то год назад опять загорелся. Туториалов с 3D было побольше и даже до конца доделанные. Но они блядь были по старой версии. Получалось, что я до какого-то момента доходил, а там разрабы все переделали. И каждый раз ты гуглишь до охуения, чтобы найти как оно сейчас реализуется и как прикрутить к тому что пилит автор.
Как там сейчас со всем эти обстоит? Реально ли найти достойную серию видосов про 3D? Азбуку размусоливать мне не нужно. С английским все норм. Нужно 1-2 туториала по текущей версии движка и с законченными проектами. Ну чтоб с контроллером, интерфейсом, просчетом столкновений для ближнего/дальнего боя етс. Чисто понять, как именно в годоте эти вещи реализуются, какие не рукожопские подходы етс.
>Вон какой то свежий бенч, C# быстрее в 25 раз, с++ быстрее еще в 4 раза (в 100 раз).
Этот твой свежий бенч это поиск простых числел от 0 до 20 миллионов компонентами языка, а не движка. Ты бы еще вычисление знаков после запятой числа пи притащил. Такое в играх не считают.
>туториалы
>видео
>гугл
Лол.
>С английским все норм.
Тогда читай всё, что найдёшь здесь:
https://docs.godotengine.org/en/stable/
И не говори, что нужны видосики смешные.
Я бы не очень смотрел в сторону годота если бы мне нужно было делать 3d.
Опять таки от проекта зависит, какой нибудь гипер казуал можно, но на него особо не нужны уроки.
Так что по 3д видосов не встречал.
Это и есть бенч языков, джениус. Он для того и делается. чтобы сравнить скорость одного алгоритма. И да, считают, неважно что не именно простые числа. Это даже в ассетах видно, например zylann hterrain содержит gdscript версию и с++ версию, также многие ассеты разрезания мешей есть в разных c++/c# версиях, потому что там много рассчетов.
>Так что по 3д видосов не встречал.
Из подвала без интернета капчуешь?
Буквально тысячи туториалов по 3д за последние 5 лет.
А тебе нужны эти алгоритмы вообще? Для игры?
А то выбирают-выбирают алгоритмы, а игры нет...
Я в первые разы пытался ворваться, когда еще 1 или 2 версия были. Траблы с переписыванием кода были, когда туториалы по трешке, а уже 4 с пол года или около того релизнулась.
Мне не совсем дефолтные вещи интересны. И не хочется на старте васянские практики перенимать. Когда у тебя в туториале вроде норм, а когда масштабировать начинаешь, все в пиздец превращается.
>>979152
Я с UE просто. Там у нас оф. документацией можно жопу подтирать. По не дефолтным моментам как раз из видосов узнаешь.
>>979153
Расскажи подробнее, молю. Фотореалистичный рендер не нужен его я и в UE получу. По графену будет всякая лоу поли стилизация. По масштабам ясное дело не асасины и не скайримы Типичная индюшня от анона по часов 5 геймплея. Боевка, задания, лут, карта, сохранения, интерфейс - все как обычно.
Я про цельные вещи в которых от и до делается какая то механника/фича/шаблон.
Вообщем то даже на unity их не так много.
Я сразу уточню, что я исключаю легаси и те видео где люди сами сражаются за свое существование когда пытаются написать супер говнокод (Типо всяких дударей-мударей хауди-чмо и т.д.)
Ну и то что я не считаю годот хорошим выбором для 3д - но это чисто мое мнение а не призыв к действию.
>Расскажи подробнее, молю.
Ну если прям лоуполи кубы то норм.
Проблема годота в пост эффектах и рендере 3д в целом.
На том же юнити ты больше по фпсам вытянешь (ну по крайней мере это будет с меньшим гемороем)
Про gds тут говорили постоянно если вдруг тебе понадобиться на половине сцены чтото найти посчитать итд ну на c# уверенности больше что это не вызовет проблем.
Меня положил именно рендер когда на годот переносил поделку.
(если не нужны эфекты освещение и всякое такое то проблем может не быть)
Но в 2д годот удобней будет.
>Симуляторов свиданий 3.5 на весь мир, и те японские.
>Сразу скажу, что не всякая игра, что называет себя
Ваще мне похуй че ты там скажешь
>но игроки, площадка и правообладатели оригинальных ассетов тебя могут и наказать.
всем похуй тем более на патрионе а для стимговна если дойдешь то можно замаскировать модели для стимовского билда и оставить возможность качнуть мод-патч на оригинал с пиратскими модельками
>Если у тебя все визуальные ассеты уже были в других играх, тогда игроки, пусть и тупые, но заметят и обосрут.
Да а если актриса снялась один раз в фильме уже то если ее заметят в другом то закидают говном фильм сразу за, что новую не нашли которую не видели нигде раньше, именно так это и работает.
>А потом прилетит DMCA от какой-нибудь нинтенды и всё...
ну да за каждым моделером adult контента стоит по Sony и Nintendo шизик
>С таким подходом можно что угодно высрать.
уж лучше так, чем сидеть высирать диванные шизопосты на дваче и ничего вообще не делать, так хоть получишь кучу опыта и итерационно на новом проекте применишь новые скиллы + переиспользуешь часть созданных наработок и следующую игру сделаешь лучше с учетом прошлых ошибок
https://store.steampowered.com/app/2956040/PVKK_Planetenverteidigungskanonenkommandant/
https://store.steampowered.com/app/1963610/Road_to_Vostok/
>годод только для 2д яскозал!
Добра тебе анончик.
А что про работу с анимацией скажешь? Как со всякими родительскими-дочерними объектами дело обстоит? Чтоб не копипастить, когда тебе только кастомизировать надо или пару фишек добавить.
Ну для постэффектов и топового рендера у меня UE есть. И фпс-ы нужные на компе я там выкручу. Только для лоупольной стилизации UE - очевидный оверкил.
Идея такая: если годот - это +- гамак очень условно с адекватной поддержкой 3D, то для меня годнота. Если вместо того, чтобы быстро запилить базовую логику, а потом возиться с геймплеем и масштабировать, получаешь костыли и пердолинг, то шло бы оно.
Я с тридэхой стилизованной работаю, мне заебись. Физику движка я разве что не использую. Проблем нет.
Мужики просто двач не читали и не знали что годот не для 3д.
https://www.youtube.com/watch?v=FCn1q6Ftr_0
Что круче - эта штука на уже древнем годот 3.х, никаких этих ваших вулканов и новых-модных освещений от Хуана.
Суровая вещь мда, за полгода не разберешься (туда плавучесть еще не прикручивали).
И кстати показательный пример рассчеттов на с++.
> Аноны, как из блендера перенести частицы в годо?
В общем случае никак, но если ты нагуглишь конвертор, то через него. Суть конвертора в том, чтобы взять блендеровые функции, вызвать их аналоги в годо и произвести тем самым эдакое транспилирование. Как у нас в русских деревнях говорят.
Мы уже поняли, что у тебя приступ нибомбита. Дело не в том, можно или нет что-то в принципе делать, а в том сколько пердолинга с этим связано и на каких подводных запнешься в процессе. Так-то и в блендере когда-то был игровой движок и демки попахивали годнотой.
>на каких подводных запнешься в процессе.
Споткнешься - встанешь и дальше пойдешь. Как маленькие блять.
Нет, у меня нет такого конвертора. Я чисто теоретически понимаю, что такой конвертор возможен. Дальше гугли сам.
Второй тоже ВСЕ. Пишут что посрались из-за донатов на патреоне - редот хотел хапнуть донатов до первого релиза.
Напоминание пойти бы тебе уже наконец на хуй. Как и просили выше.
>Траблы с переписыванием кода были, когда туториалы по трешке, а уже 4 с пол года
Я сам начинал во времена 3.2, и потом переносил прототипы на 4.0+, никаких проблем не было. Всё максимально подробно описано в документации. Разумеется, у меня не так много кода... Но там все изменения были уровня "добавить @ в начале, переименовать одну функцию в другую" и т.п.
>Мне не совсем дефолтные вещи интересны.
Конкретно что тебе интересно? К чему скрывать?
>на старте васянские практики перенимать. Когда у тебя в туториале вроде норм...
Туториалы делают только чтобы заработать на доверчивых ньюфагах, и ньюфаг приблизительно почувствовал вкус геймдева на собственном опыте.
Хочешь хорошую, расширяемую архитектуру игры? Включай собственную голову и думай. Думай, что необходимо для твоей игры, в каком месте и т.д. Туториалы по движку этому тебя не научат, это ты самостоятельно должен уметь, чтобы делать игры.
Движок - инструмент, туториалы учат назначению клавиш, а мелодию выдумывать ты сам должен.
>По не дефолтным моментам из видосов узнаешь.
В документации Godot отсутствуют только крайне специальные моменты, но о них можно узнать либо поискав по Issues на гитхабе, либо почитав код. Нет необходимости искать видео туториалы - учитывая специальность этих вещей, туториалов не будет.
Просто помни: бесплатные туториалы снимают не ради твоего обучения, а чтобы собрать побольше просмотров на рекламном блоке. Естественно, что обозревать будут только самые популярные вещи, а также затягивать видео, сознательно вставлять ошибочный код, плохие паттерны и т.д. Лишь бы ты вляпался в tutorial hell и продолжил смотреть эти бесконечные "обучающие" видосики на Ютубе.
С платными та же история, только с тебя ещё бабки требуют, а по итогу ничему хорошему не учат, а тупо заманивают купить ещё больше платных курсов. Я скачивал как-то код с одного курса - там такой тупой говнокод, что просто жуть, и ведь автору наглости хватает брать за это деньги, а кто-то покупает...
>По графену будет всякая лоу поли стилизация.
У Godot для этого даже больше, чем необходимо. Единственное что - пока что Stencil Buffer отключён, поэтому обводку делаем по старинке - вывернутым наизнанку и чуть расширенным мешем - для этого в стандартном материале даже спец настройка есть.
Но Stencil Buffer обещают добавить в ближайших версиях, уже давно работают над pull request'ом.
>Боевка,
Зависит от того, что ты хочешь. Пошаговые бои ты, скорее всего, чисто вручную пишешь, так что к 3D никакого отношения они не имеют. Если тебе нужна физика в реальном времени, тогда всё зависит от масштабности и требуемой точности; если вдруг встроенная физика не тянет, её легко заменить.
>задания, лут, карта, сохранения,
Это всё не зависит от 3D графики.
Рекомендую, особенно для квестов и лута:
https://docs.godotengine.org/en/stable/tutorials/scripting/resources.html#creating-your-own-resources
Для рендеринга мини-карты пригодится:
https://docs.godotengine.org/en/stable/tutorials/rendering/viewports.html#viewport-container
Для сохранений есть много разных способов:
https://docs.godotengine.org/en/stable/tutorials/io/saving_games.html
>интерфейс
У Godot очень мощная UI система, на которой в т.ч. Godot Editor построен. Всё очень просто и удобно, в отличие от других движков и веба (HTML/CSS). Идейно напоминает RAD IDE Delphi - единственная проблема в том, что в Godot UI не нативный для ОС - сложнее поддержка для инвалидов ("экранные читалки", например, не видят кнопки Godot).
Т.е. базовая концепция:
- кидаешь компоненты (ноды) на "форму" (сцену);
- настраиваешь параметры нод в инспекторе;
- соединяешь события (сигналы) с обработчиками.
Можно легко делать собственные UI компоненты.
Также есть поддержка тем - применение параметров интерфейса глобально ко всем UI-компонентам.
>>979160
>Проблема годота в пост эффектах и рендере 3д
Если сравнивать с OpenGL 1.0 - у Godot просто фантастический рендерер 3D, так что мне даже пожаловаться не на что. Зачем какой-то UE? Ты раскрыть весь потенциал OpenGL 3.3 попробуй. Древние игрушки начала нулевых уже страдали избыточным фотореализмом в ущерб стилю, а вы ожидаете от движка картинки как в реальности? Создание игр - это побег от реальности, не нужно отравлять геймдев фотореализмом. Он нужен исключительно для виртуальных музеев...
Я вот сейчас в основном играю в игры со старых мобильных приставок вроде Game Boy, каждый раз удивляясь, что в таких микроскопических по весу игрушках геймплея и смысла больше, чем в любом современном ААА фотореалистичном "игрокинце".
Разрабы в погоне за фотореалистичной графикой забыли, зачем вообще игроки играют в игры. Даже индюшатина давно начала страдать от "графония".
>если вдруг тебе понадобиться на половине сцены чтото найти посчитать итд
Тогда ты явно что-то не так делаешь. Зачем тебе ИСКАТЬ что-то на сцене, которую ТЫ САМ создал?
Конечно, бывают ситуации, в которых выгоднее переписать весь алгоритм на C++. Но зачастую твоя проблема в самом алгоритме, организации сцен или геймплея, а не в языке. Т.е. твой код будет тормозить независимо от языка, просто на GDScript ты это чуть раньше почувствуешь (и это хорошо).
>>979165
>А что про работу с анимацией скажешь?
Нормально всё, читай документацию:
https://docs.godotengine.org/en/stable/tutorials/animation/
>Как со всякими родительскими-дочерними объектами дело обстоит?
Это основа дерева сцены, как ещё может быть?
>Чтоб не копипастить, когда тебе только кастомизировать надо или пару фишек добавить.
Можно попробовать Scene Inheritance. Одна общая сцена-предок может иметь множество потомков, в каждом из которых есть дополнительные данные. Изменения в предке влияют на всех потомков, но изменения в потомке влияют только на него. Все импортированные 3D сцены по умолчанию будут создавать сцену-потомка от базовой GLTF-сцены.
>если годот - это +- гамак очень условно
Давно не видел GM, много времени прошло. Но фундаментальное отличие в том, что GameMaker - закрытый продукт в руках одной компании. Godot, напротив, подвержен влиянию сообщества, которое занимается им в т.ч. на уровне исходного кода. По юзабилити тут можно сказать, что Godot заточен сообществом под сообщество, а GM заточен одной компанией под очень абстрактного "потребителя".
>быстро запилить базовую логику, а потом возиться с геймплеем и масштабировать,
А это уже от тебя зависит, а не от движка. В любом движке можно наломать немасштабируемых дров.
Для масштабируемости рекомендую следующее:
1. "Call down, signal up" - вызывай методы только у непосредственных потомков (детей) ноды, никогда не взаимодействуя с внуками/братьями/предками. Оповещение предков - только через сигналы. Эта концепция позволяет сделать игровые объекты намного более независимыми друг от друга.
2. Обязательно указывай типы данных и объектов везде, где это возможно. В настройках включай предупреждение об отсутствии конкретного типа и автоматическое дополнение типов для встроенных методов. Для любых сложных объектов указывай class_name с читаемым именем, чтобы эти объекты можно было использовать по имени, с бонусом к автодополнению и статической проверке кода. Дополнительно указывай тип данных в Array, и в ближайшее время (Godot 4.4) - тип в Dictionary.
3. Предпочитай композицию наследованию. Лучше создавать новые сцены через композицию нод и имеющихся сцен, чем делать наследование. Нет, наследование полезно в определённых ситуациях, однако для расширяемости композиция удобнее. В отличие от ECS (плоская композиция), в Godot древовидный подход (в стиле ООП), проблем нет. Разделяй проект на уровни абстракции, т.е. разные компоненты принадлежат разным системам.
4. Избегай создания глобальных сущностей. Godot поддерживает создание глобальных сущностей несколькими разными способами - это может быть удобно для маленьких проектов, но на длинной дистанции ты хочешь иметь как можно меньше глобальных сущностей. Это касается статических полей классов, "autoload"-сцен, а также ресурсов, глобально передаваемых множеству объектов. Глобальные сущности усложняют поддержку из-за связывания всего кода проекта в одной точке.
5. Почаще нажимай F6 (вместо F5). F6 запускает отдельную сцену вместо главной. Если твои сцены адекватно работают после нажатия F6, то выше вероятность, что они будут работать хорошо и в композиции с другими сценами. Это ключевая концепция Godot, на мой взгляд.
6. Изучи дебаггер, способы поиска ошибок и т.д. Естественно, по официальной документации. Способность понять и исправить ошибку в своём проекте поможет лучше, чем любые туториалы.
>Создание игр - это побег от реальности, не нужно отравлять геймдев фотореализмом
Я упростил настолько, что делаю 3д модели сразу в годоте. Я молодец?
>Не будет развесёлых форков.
Они уже опять форкнули, лол:
https://xcancel.com/LifeArtStudios/status/1844917258105082310
https://github.com/blazium-engine/blazium
Blaze - вспышка огня/эмоций/жопы
Blazing - полыхающий пердачелло
Blazium - кристаллизованный баттхёрт
Продолжаем зоонаблюдение.
Продолжаем.
Ну не игры же делать в самом-то деле?
Почему никто из этих сверхразумов не догадался ПРОСТО поменять всякое точно также, как и название? Ну типа просто поиском и заменой/рефакторингом поменять название всякой залупы и троллить транс-негров-пидорасов этим?
>LifeArtStudios
Так это тот, из редота, который не осилил код и слился. Типа со второго раза прокатит?
Клоуны пиздос.
Форки пинуса (если ты про ядро) обычно накладывают свои узкоспециализированные патчи на основную ветку и этим ограничиваются. Форкать такие гига-проекты и тащить их в одиночку в ином направлении невозможно, это путь отставания, стагнации и смерти.
Я когда-то, во времена трешки, бдил за этим форком: https://github.com/RebelToolbox/RebelEngine
В отличии от истерящих редотовских даунят его сделал скилловый аутист, регулярно (на тот момент) коммитящий полезное в годот. Как сейчас вижу не осилил и безнадежно отстал, не смотря на ребрендинг, работающий сайт и попытки построить комьюнити.
Хуя ты простыню родил. Спасибо наверное пусть и выглядит как вода водовая.
>Я сам начинал во времена 3.2, и потом переносил прототипы на 4.0+, никаких проблем не было.
Наверное, мне те мои проблемы во сне приснились.
>Хочешь хорошую, расширяемую архитектуру игры? Включай собственную голову и думай. Думай, что необходимо для твоей игры, в каком месте и т.д. Туториалы по движку этому тебя не научат, это ты самостоятельно должен уметь, чтобы делать игры.
Какой-то успешный успех. Я в UE несколько лет. Я знаю, что у меня по умолчанию очень мощный контроллер, который достаточно кастомизировать, а не писать с нуля. Если мне нужны абилки, как в RPG, я подрубаю GAS или плагин с ней. Знаю, как за полтора клика подтягивать из таблиц в движок все тексты и геймплейные переменные. Знаю, как несколько родительских виджетов кастомизировать под весь интерфейс в игре. Знаю, как реализовать инверсную кинематику, скининг/морфинг, стриминг етс. Т.е. я совсем чуть-чуть понимаю, как пилится архитектура игры. Мне нужен пример, как без васянства что-то подобное реализуется в годоте. Только документация этого не даст.
У меня за все время накопились претензии к UE и на ближайшие пару лет сформировалось видение, какой мне инструмент нужен. Выше уже писал, что если в нынешнем состоянии годот - это очень условно +- гамак т.е. ты в несколько строк кода можешь запилить тот же контроллер, который будет норм, но с адекватной поддержкой 3D, то мне ок. Я даже на то, что каких-то фич нет, готов закрыть глаза. Вопрос был в этом + есть ли адекватный контент от комьюнити в качестве примера.
Но вместо простого ответа на простой вопрос вот этим >>979160 >>979167 анонам или анону спасибо, единственные адекваты, один тащит пруфы с потугами в топовый графен на годоте, теперь ты врываешься с успешным успехом. Годы идут, а /gd все так же ракует.
Ему наотвечали то, что он и сам нагуглить мог но поленился, а он морду воротит.
>кастомизировать, а не писать с нуля
>Знаю, как реализовать инверсную кинематику
Знаешь ли? Или ты про то, какие кнопки в GUI жать? Инверсная кинематика, например, это очень сложно алгоритмически, поэтому идеальных решений нет. В условном Blender нет требований работы в реальном времени, однако даже там IK алгоритмы глючные. Реализовывать такое самому крайне сложно, и в UE наверняка есть какое-то уже готовое решение. Ну и зачем реализовывать то, что уже есть из коробки?
>без васянства что-то подобное
В Godot сознательно ограничен набор встроенных инструментов. Ты можешь получить что-то очень отдалённое на "однокнопочные" решения, скачав пользовательские аддоны, где всё "васянство" уже разработано вместо тебя. Но качество у аддонов обычно так себе и на поддержку можно только надеяться. По этому на Godot ты либо сам будешь разработчиком Васяном, либо работаешь в паре со знакомым Васяном, а с тебя только арт/звук/текст.
Собственно, как и на любом другом движке. Вот за это пользователи Godot и любят его: можно просто писать код игры без лишних проблем, как раньше. Открываешь редактор за секунды и васянишь...
А вот если тебе нужен конструктор игр совсем без программирования, то ты не туда обращаешься.
>т.е. ты в несколько строк кода можешь запилить тот же контроллер, который будет норм
Максимально упрощённый контроллер:
>extends CharacterBody3D
>func _physics_process(_delta: float) -> void:
> var v := Input.get_vector("left", "right", "up", "down")
> velocity = Vector3(v.x, -9.8, v.y)
> move_and_slide()
Это заставит твою ноду CharacterBody3D двигаться соответственно нажатиям 4 клавиш, "скользить" по препятствиям и падать в случае отсутствия опоры. Достаточно для простенькой игры типа "Sokoban". Подробнее читай в документации:
https://docs.godotengine.org/en/stable/classes/class_characterbody3d.html
https://docs.godotengine.org/en/stable/classes/class_input.html
Но тебе наверняка будет мало этого. Ожидаемо. Тебе придётся написать несколько сотен строк для чего-то продвинутого (в хорошем стиле с комментариями, не складывая кучу выражений в одну строчку), либо ты можешь попробовать посмотреть готовые решения:
https://godotengine.org/asset-library/asset?filter=Character
https://godotengine.org/asset-library/asset?filter=Controller
Не обязательно брать готовое как есть. Можно взять исходники, изучить их и многие другие, и сделать собственные так, как тебе будет удобнее всего.
Разработчики движка не встраивают полностью готовый контроллер как раз потому, что у всех игр собственные требования и у всех разработчиков собственные вкусы к коду/архитектуре. Они дают достаточно гибкий скелет, а дальше работай сам.
>игры типа "Sokoban"
Не, классический сокобан вроде по клеточкам...
Хех, если подумать, код для движения по клеткам получается в несколько раз длиннее простейшего:
1. В _input проверяем нажатие 4 клавиш;
2. Если одна из клавиш нажата, блокируем ввод;
3. Смещаем персонажа ровно на одну клетку в направлении нажатой клавиши, как-то при этом проверяя достижение целевой клетки;
4. Разблокируем ввод по окончанию движения.
Я уже разработал название: /b/dot. Зделаем заебись всё. Я умею на гитхабе регаться.
Пердиксов даже на годотконе попускают.
>/b/dot
Форкнул твой бдот в /gd/ot. Идеально впишется же в наш раздел!
Годоти опять публично пытаются оскорбить часть своей аудитории. Реально необучаемая порода.
Под логикой реальной рпг гдскрипт ляжет, хз что они за пустую картинку показывают с минимумом кода, чо за наёб гоев лол?
Это не проблема языка, инструментов просто нет или они странные.
Вообще я чо т охуеваю с каких это пор стало модно гордиться что твой интерпретатор работает как говно. Я походу слишком старый стал для современного программирования.
Свежеустановленная манжара. Свежескачанный годот 4.3 (с сайта, не из реп). Свежесозданный проект, форвард+. Открываю ассетлиб, устанавливаю оттуда Tree3D и Terrain3D. Перезапускаю пару раз. Создаю 3д-сцену, добавляю в неё ноду Terrain3D. Должна появиться вертикальная панель для работы с террейном, но её нет. Лезу в гугл, смотрю видео - у всех туторщиков панель появляется.
Чозанах и где я просчитался?
>ассетлиб
>Terrain3D
Там какие-то бета-релизы под 4.3, смотри тут:
https://github.com/TokisanGames/Terrain3D/releases
А вообще, в терминале какие-то ошибки пишет?
Если не получится - нужно писать о проблеме сюда:
https://github.com/TokisanGames/Terrain3D/issues
>>979624
>инстал годот
Так он ведь с сайта скачивал, там без инсталляции.
>>979626
>включил?
Он же сказал, что перезапускал редактор...
> Он же сказал, что перезапускал редактор...
Он не сказал что проставил галочку в конфигах.
>Плагины то в настройках проекта включил?
Бля точняк. Спасибо, анонче. Так и знал, что какую-то мелочь забыл.
Давно годот не запускал, да и с плагинами раньше дела не имел.
>Под логикой реальной рпг гдскрипт ляжет
Расскажи, что за "логика реальной РПГ"?
Для начала, что это за "реальная РПГ"?
Компьютерные РПГ состоят из (по Википедии):
1. Ролевая система
2. Исследование
3. Сюжет
4. Боевая система
По пунктам:
1. Ролевая система
Как правило это значит:
- рост чисел (числодроч)
- надевание шмоток
- выбор навыков
Все эти компоненты работают по принципу "один раз присвоил и больше не трогаешь". Т.е. нет логической нагрузки на ЦПУ, пока ты не нажимаешь "+1 к силе".
2. Исследование
Это значит опенворлд в том или ином виде. Да, мир желателен насыщенный и большой, но, естественно, статичный. Спавн болванчиков привязан к точкам, например, и зависит только от приближения игрока. Поэтому этот компонент не нагружает ЦПУ больше нормального стримминга частей статичной карты.
3. Сюжет
В РПГ сюжет обычно до боли линейный или вообще отсутствует, оставляя только набор веток-квестов. Реализация квестов подобна росту чисел в ролевой системе, т.е. пока что-то не происходит, ЦПУ никак не нагружается, а потом делает "+1" к переменной.
4. Боевая система
В РПГ, в отличие от, скажем, шутеров, боевая система тривиальна: ты выбираешь врага и навык/атаку или защиту, и дальше персонажи просто проигрывают анимации. Физика тут не используется, все враги как правило бегут на игрока по прямой, рассчёты урона тривиальны по типу "здоровье -= урон - броня", там отсутствует даже понятие попадания в голову, лол. Искусственный интеллект отсутствует как класс.
Это касается большинства РПГ, включая серию TES, которую тупо расхайпили непонятно за что. Честно, пытался играть, но так и не понял, в чём там смысл.
Ну и откуда там взяться нагрузке на скрипты игры?
Алсо, РПГ вообще плохой пример: они выросли из пошаговых настолок и их любители готовы терпеть хоть 10 кадров в секунду с лагом по 500 мс, благо работают эти древние игры даже на телефоне, лол. Подходящий жанр для аргумента против GDScript: соревновательные онлайн шутеры с физикой. Там необходимо выжимать максимум, иначе дурачки обидятся на то, что их ноутбук не тянет игрушку с минимально допустым 240 фпс и <10 мс пингом.
Сегодня разобрался, как работает astar с обычной прямоугольной сеткой. Завтра буду перекладывать его на гексагоны. Вроде логика не сильно будет отличаться
>Terrain3D
Вижу этот проект снова ожил, раньше он был довольно заморожен. Но у него все равно есть некоторые минусы (бета, он сделан через gdextension, у него только экспериментальная поддержка мобилок, а веб вообще судя по описанию не грузит текстуры). https://terrain3d.readthedocs.io/en/stable/docs/mobile_web.html
Я бы по старинке пользовался Zylann HTerrain.
Ну ляжет и ляжет, хули, на Си перевести дело пары дней, вон конвертер выше кидали. Я логику к своей РПГ на годоте сразу на С++ писать стал.
>Terrain
>3D
>мобилок
>веб
В вебе вообще каждую спичку нужно экономить, чтоб работало хотя бы в 30 фпс, а на мобилках нужно всё оптимизировать под, ВНЕЗАПНО, мобилки.
Ладно уж 3D, хотя и оно перебор, но ландшафт?
Ты там браузерную убийцу ГТА 6 делаешь?
"Браузерка" для меня всегда была ярлыком чего-то совершенно несерьёзного/заведомо провального... Нормальные "браузерки" - это голый HTML + JS с графикой на <img> тегах в роли иконок к ссылкам.
Ну, это так... Ворчание.
Алсо БЕСЯТ индюки, запрещающие скачать их бесплатную игрушку с itch.io. За что? Я бы хотел сохранить их шедевр себе на память... У них там рекламы даже нет на странице, так какой смысл?
>astar с обычной прямоугольной сеткой
Ты используешь AStarGrid2D? Добавили ещё в 4.0.
Там есть поддержка гексагонов, добавили в 4.3:
https://docs.godotengine.org/en/stable/classes/class_astargrid2d.html#enum-astargrid2d-cellshape
Правда, как я понял, только две оси вместо трёх.
Вот хороший материал по гексагональным картам:
https://www.redblobgames.com/grids/hexagons/
Читал давно, понял не всё... Но очень годно.
>Там есть поддержка гексагонов
А, нет, нет поддержки. Там для изометрии:
>Diamond cell shape (for isometric look).
Т.е. для карт типа пикрила - сбоку-сбоку-сверху.
Для гексагонов придётся делать самому на AStar2D.
Жаль... Гексагоны вроде популярны. Хотя, учитывая разнообразие координат на гексагональной сетке, сомневаюсь, что они согласятся принять это в ядро. Либо получится как с GridMap и VehicleBody - штука специфичная, потыкать прикольно, а потом свой велосипед писать приходится всё равно...
Банально любой ужастик где ты можешь выйти из избушки на полянку.
Конечно можно это намоделить мешем, но смысл террейна то как раз в том что он оптимизированнее за счет лодов по сетке.
С точки зрения программирования логики и массивов не рендера с этими вот полусмещениями, вся разница в том, что клетки соседние по одной диагонали. Половинный вариант по сравнению с обычными 4- и 8- соседскими.
>Ты используешь AStarGrid2D?
Ага
>Вот хороший материал по гексагональным картам:
За ссыль спасибо. Знаю этот сайт, пока успел только бегло ознакомиться
>>979687
>Для гексагонов придётся делать самому на AStar2D.
Там вроде не сильно различается. По крайней мере вот тут https://habr.com/ru/articles/557496/ так написано:
>Основной алгоритм поиска пути тот же, что и у обычной прямоугольной сетки, отличаются только соседи и проверки на нахождение точки внутри карты.
>>979718
>что клетки соседние по одной диагонали
Хмммм, а ведь и правда
>Банально любой ужастик где ты можешь выйти из избушки на полянку
Литералли это и хочу сделать, лол. Пришла идея ужастика, прочекал - ничего подобного нету. Решил собрать прототип, дабы заплейтестить идею. Заодно погружаюсь в дивный новый мир тридэ, с которым я раньше не имел дела.
>AStarGrid2D
>Там вроде не сильно различается
Вкратце, AStar ищет оптимальный путь в графе, считая стоимость каждого возможного пути по длине ребра и дополнительному весу узла. Расположение узлов в пространстве для этого алгоритма совсем не важно.
В Godot есть три класса с реализацией AStar:
1. AStar2D/AStar3D - произвольные графы, которые необходимо заполнять по одной вершине, по одному ребру за раз. Самый базовый, но и гибкий вариант.
2. AStarGrid2D - даёт возможность заполнить граф автоматически одним присваиванием region, плюс позволяет включить/выключить прохождение по диагонали, и выбрать одну из популярных формул для рассчёта пути (в базовом AStar2D нужно делать свою реализацию двух виртуальных методов, если ты хочешь использовать другую формулу).
Так вот... AStarGrid2D умеет ходить только по 4 или 8 направлениям в зависимости от выбора, и он всегда предполагает, что сетка у тебя прямоугольная.
У гексагонов 6 направлений и расстояния у них отличаются от расстояний на отдалённо похожей прямоугольной сетке. Поэтому напрямую, пока что, использовать AStarGrid2D для гексагонов нельзя. Сомневаюсь даже, что удастся костыль сделать...
Так что придётся заполнять AStar2D вручную. Это несложно, я делал так пару раз ещё на 3.x. Просто существенно больше кода и, наверное, медленнее.
1. Заполнить сетку узлами:
for x in...: for y in...:
var id := astar.get_available_point_id()
astar.add_point(id, Vector2(x, y))
2. Соединить узлы:
for c in ...:
astar.connect_points(id1, id2)
Довольно много операций в циклах получается. Но сделать это нужно всего один раз на загрузке карты.
А вот какое решение предлагал нам годот 3, квадратный тайлмап со сдвигом рядов на половину, это внезапно хексагональный тайлмап!
В четвёрке от этого как будто ушли или я не нашёл.
Ого, интересно. Спасибо за объяснение. Поковыряюсь сегодня
Я зашёл на итч и скачал несколько более-менее человеческих моделек. Они в формате fbx, пришлось перевести в gltf, но вроде нормально получилось, открываются. У одной есть анимация ходьбы, но сама моделька всратая. Другая норм выглядит, но анимаций полторы штуки, зато блять тверк танцует на дохуя кадров.
Спрашивается: можно ли как-нибудь относительно просто перенести анимации с одной модельки на другую? В интернетах же как-то делают этих танцующих челопуков и гманов. Если не средствами годота, так хотя бы блендером?
Rokoko аддон для блендера есть. Требует регистрацию и логин внутри блендера, такую спайварь лично я бы не юзал. Как альтернативу можешь навернуть цикл видосов Bonkahe по анимациям и импорту в godot на ютубе. Там мужик fbx анимации с миксамо ретаргетит на свою модельку.
>от этого как будто ушли или я не нашёл
Плохо искал или вообще не искал.
https://docs.godotengine.org/en/stable/classes/class_tileset.html
>TileShape TILE_SHAPE_HEXAGON = 3
>Hexagonal tile shape.
Ещё смотри TileLayout:
>For all half-offset shapes (Isometric, Hexagonal and Half-Offset square), changes the way tiles are indexed in the TileMap grid.
>Делаю прототип, так что на ассеты похуй.
>@
>Я зашёл на итч и скачал несколько моделек.
>прототип
>на ассеты похуй
>@
>сама моделька всратая
>анимаций полторы штуки
>анимация ходьбы
>перенести анимации
Лол, сделай сам за 15 минут расслабленных кликов мышкой, чё тебе там надо, уровня дисней добиться?
"ПРОТОТИП" он делает, ага. Кубы подвигай, они 3D.
>В интернетах же как-то делают
Там скелеты, скорее всего, одинаковые. Читай:
https://blender.stackexchange.com/questions/315384/
>Exactly how much hassle is necessary depends on the similarity of the rigs involved. Biped to insect? Not going to happen, basically ever. Identical bone names, axes, and rest pose? Then it's a single reassignment of the action from one rig to the other. There is a wide area between those two where the retargeting becomes increasingly complicated (and increasingly error-prone.)
Вот бесплатный аддон с исходниками на питоне:
https://github.com/Mwni/blender-animation-retargeting
Но я бы на твоём месте так не парился ради ходьбы в прототипе, независимо от жанра. Геймплей делай.
Ещё поясню. Прототипы в геймдеве делают, чтобы протестировать игровые механики. Успех игры часто зависит от того, насколько "фановые" её механики. Красивая графика привлечёт первых покупателей, но именно механики задержат их в игре, подтолкнут к написанию позитивного отзыва и рекомендации их друзьям (сарафанное радио). Игра может выехать с отвратительной графикой только пока в ней фан от геймплея, без геймплея графика обычно не вывозит.
Конечно, обычно графику не делают до прототипов, чтобы не совершать лишней работы - если механики оказались плохими, карту нужно переделать или вся игровая концепция не работает, нужно что-то другое. Однако, допустим, у нас есть вся базовая графика до разработки прототипа - почему не использовать?
Потому что у нас мозг пещерной обезьяны.
"Фан" геймплея - это выброс гормонов. Но такой же выброс гормонов может быть от трясущихся сисек, нарисованных на экране. Мозг эволюционировал стремиться получать эти гормоны чаще и больше. Однако, он не способен чётко отличить, что именно приносит ему это удовольствие - сами сиськи или то, как ловко он манипулирует этими сиськами, пытаясь забросить их в дырку в полу, получив больше очков. Мозгу важно продолжать получать гормон, для чего достаточно повторять то, что ты уже делаешь - так работает обучение (закрепление связей нейронов). Результат: продолжаешь мять виртуальные сиськи, ошибочно полагая, что у тебя интересная игра. Но ты просто любишь мять сиськи, а геймплей-то унылый.
Так рождаются унылые игры с красивой графикой и интересной концепцией, но в них просто невыносимо продолжительно играть из-за унылого геймплея. Ты думаешь, "вот ща зайду получу фан" - а фана нет, вся красота только в графике, которую и на скриншотах разглядывать можно при желании. Потому что не отлаживали базу геймплея на голых примитивах.
Короче. Забудь о графике. Забудь об анимациях. На анимации приятно смотреть, но это не геймплей, а в прототипе анимации будут отвлекать тебя от того, насколько интересны твои базовые механики.
Кстати, поэтому некоторые жанры игр обходятся практически без графики. Те же рогалики: спрайты обычно несут только информационную ценность, поскольку передают больше, чем ASCII символы, а эстетическая ценность не так важна. Но они очень увлекательные и затягивают на долгие часы - ибо механически доставляют большое удовольствие.
Конечно, графика добавляет какую-то ценность, но её можно сравнить с глазурью на торте: она делает торт привлекательнее, но вкус зависит от начинки.
Даже в коллекционных играх фан от того, что ты пополняешь коллекцию, а не от самих карточек. Картинки карточек ты мог бы скачать из интернета, вытащить из ресурсов игры. А играешь ты, чтобы получать механический фан от накопления чего-то. Конечно, красивые карточки привлекут больше, но в конечном итоге жизнь игры зависит от её механик.
Вот, кстати, почему визуальные новеллы - не игры: графика там несёт ключевую роль, а механически ты нажимаешь "далее" и редко выбираешь развилку. Бессмысленно делать прототип новеллы совсем без иллюстраций, это как делать пустую книгу без текста. Речь о самостоятельных новеллах, а не катсценах в полноценных играх с геймплеем, конечно.
>визуальный новеллы
>графика там несёт ключевую роль
Сценарий и диалоги. Что, впрочем, не делает их играми бОльше, чем если бы ключевой была графика. ВРки это такой визуальный интерактивный фанфик. Убери из него графику, оставив интерактивность - получишь ии-чатбот вроде чарактер.аи или ии-данжн, убери еще и интерактивность - получишь обычный фанфик.
Да, я впервые прочитал твою портянку.
Анон, делать ретаргет анимаций в Годоте или Блендере, да еще и после конвертации в другой формат - это пиздец какой колхоз и прямо желание пердолиться. С начала века для таких дел использовали Maya и Motionbuilder, там все гарантированно работает и все процессы давно отлажены.
>>979803
Если он не решит вопрос с графоном и анимацией на стадии прототипа или вертикального среза, то позднее может оказаться что игра требует такое количество/качество контента на которое нужно несколько лямов рублей и несколько лет жизни.
1) Нужно ли будет использовать эти предопределенные объекты такие как Body2D, если мне не нужна встроенная физика, а код для движений и коллизий я буду писать сам
2) Можно ли будет создать объект типа мастер контроллер, который будет управлять структурой каждой итерации цикла игры (то есть, в нем будет скрипт, который будет по очереди обращаться к каждому объекту и вызывать его метод в порядке, определенном внутри этого контроллера и так для каждой итерации в цикле)
1. Нет, не обязательно, честно говоря я уже сам склоняюсь к тому что для всяких ретроплатформеров лучше писать свое.
2. Очень легко, ты можешь просто воспользоваться тем что уже есть в годоте (по идее _process разных скриптов и выполняются по порядку в сцене), либо просто создать какой-то массив таких объектов и вызывать в них функции по нужному тебе порядку. Или посмотреть на более навороченные либы для ECS.
Анончик, ты молодец, правда. Но не надо повторять заученные фразы. Некоторые теории при столкновении с практикой требуют значительной доводки. Вот тебе уже назвали один жанр, где геймплей не важен - ВН.
Я делаю хоррор. Геймплейная формула "сбежать от НЕХ, которая может прятаться где угодно" давно уже испытана и в тестировании не нуждается. Да и, в общем-то, не особо важна в этом жанре. Если посмотреть на все значимые тайтлы и представить их в кубах без текстур - ну унылая хуита без геймплея же получится. Но вот что действительно важно для ужастика - это атмосфера. Именно она определяет, будет ли игра действительно пугать. Следовательно, плейтестить надо именно атмосферу. А её без ассетов ну никак не сделать.
Ну и наконец, да, у меня есть геймплей. Но, опять же, тестировать его в отрыве от атмосферы нет смысла. Когда я наткнулся на эту идею в интернетах, чел плейтестил её в кубах и закономерно заключил: хуита. А я увидел и сразу понял: да, хуита, но если её применить к ужастику, должна получиться охуенная годнота. Но чтобы в этом убедиться, надо собрать прототип-ассетфлип.
Прототип хоррора должен иметь графику хотя бы какую-то. Когда играешь за реалистичную тян с нормальными анимациями в тёмном лесу, то чувство опасности есть; если ей будет не хватать нормальных человеческих анимаций или если заменить её на анимешную вайфу, то получится смешно, а не страшно. А куб просто нахер убьёт весь эмоциональный отклик, оставит голую механику, весь смысл которой состоял в том, чтобы делать страшное ещё страшнее.
Надеюсь, понятно объяснил.
>>979819
>это пиздец какой колхоз и прямо желание пердолиться
Услышал тебя.
Вообще, наверное, просто поищу модельку, которой не надо делать ретаргет. А в блендер в любом случае вкатываться надо, просто с чем-то попроще.
>>979800
>аддон
спс
>>979791
И тебе.
>Следовательно, плейтестить надо именно атмосферу. А её без ассетов ну никак не сделать.
>Ну и наконец, да, у меня есть геймплей. Но, опять же, тестировать его в отрыве от атмосферы нет смысла
Двачую. Я уж собрался опровержение писать ему в очередной раз, а ты сам все знаешь, молодец.
>Геймплейная формула "сбежать от НЕХ, которая может прятаться где угодно" давно уже испытана и в тестировании не нуждается. Да и, в общем-то, не особо важна в этом жанре
Лол, очередной говноподелие под копирку делаешь?
>Но, опять же, тестировать его в отрыве от атмосферы нет смысла
Тебе просто в голове представить недостаточно? И что, уже есть на руках концепт-арты, диздоки и прочее? Думать нужно, как геймдизайнер, а не кабанчик. Воображение там иметь, хотя бы минимальное
Хехе, не совсем. Хочу запилить что-то на подобии первой части Curious Expedition. Только чтобы исследование локаций представляло собой не текстовую мини-игру, а полноценный тактический геймплей за группу персонажей в данже.
Эдакое разделение на стратегию и тактику
https://www.youtube.com/watch?v=yN3foEzah4U
>Сценарий и диалоги.
Они везде, где хоть как-то задействуются, должны быть достойными. Однако, визуальную новеллу определяет, внезапно, визуальная составляющая.
>Убери из него графику, оставив интерактивность - получишь ии-чатбот вроде чарактер.аи
Нет, визуальная новелла без графики - это вот это:
https://en.wikipedia.org/wiki/Gamebook или это:
https://en.wikipedia.org/wiki/Interactive_fiction
>The term "interactive fiction" is sometimes used also to refer to visual novels, a type of interactive narrative software popular in Japan.
>>979819
>стадии прототипа или вертикального среза
Это разные стадии, не путай. Вертикальный срез - полностью, на 100% проработанный участок игры, включая в том числе полностью готовую графику. Вертикальный срез идёт после прототипов, когда основные механики и локации уже отлажены.
>>979839
>Я делаю хоррор.
Хороший хоррор можно сделать на простейших геометрических фигурах - см. видео как пример. Воображение достраивает всё недостающее - персонажей, их эмоции, события с ними и т.д.
>Геймплейная формула "сбежать от НЕХ, которая может прятаться где угодно" давно уже испытана
Ладно, допустим, ты делаешь очередной клон.
>и в тестировании не нуждается.
А если НЁХ слишком медленная? А если слишком быстрая? А если спрятаться игроку негде? А если спрятаться слишком легко? А если бежать долго? Представь себе, даже копировать готовое сложно. Попробуй сделать так, чтобы КУБ был страшным - получится шедевр вместо тупого "Бу! Я мооонстр".
>да, хуита, но если её применить к ужастику, должна получиться охуенная годнота.
Вдруг только хуже сделает. Если механика сама по себе не пугает (например, кровотечение, падение, утопание - пугают без графики), то бессмысленно натягивать "атмосферно страшные" декорации.
>Когда играешь за реалистичную тян с нормальными анимациями в тёмном лесу, то чувство опасности есть; если ей будет не хватать нормальных человеческих анимаций или если заменить её на анимешную вайфу, то получится смешно, а не страшно. А куб просто нахер убьёт весь эмоциональный отклик
Так ты ж в любом случае тупого болванчика по экрану двигаешь. Ещё раз посмотри видео. Там треугольники и круг, а эмоций больше чем от 99% фотореалистичных болванчиков в АААА играх. Ты должен создать чувство опасности, которое будет предследовать игрока, даже если он управляет простейшим кругом в мире геометрических фигур. Например, если круг "умирает" от прикосновения к острому углу треугольника, игрок начнёт бояться прикосновений к любым другим острым углам. Строишь механики вокруг того, что полностью избежать взаимодействия с острыми углами и завершить сюжет нельзя - и получается хоррор.
>анимешную вайфу
>смешно, а не страшно
НУ-КА ИЗВИНИСЬ БЫСТРО.
https://store.steampowered.com/app/1546860/
Сначала назвал game, потом main, потом gameplay
Зачем годот сохранил все 3 названия? Я понимаю что он их закэшировал, но удалять то он их с кампутера собирается? Я годот закрыл уже
нихуясе ты длиннопост высрал на ровном месте
Чел, я всего лишь хочу проверить, как одна конкретная механика работает в атмосфере хоррора. Без атмосферы хоррора (на кубах) она протестированно работает как душная хуита, но мне показалось, что именно эта её душность способна придать дополнительного ужаса и чувства беспомощности.
Затрата усилий на ассетфлип гораздо ниже, чем на попытки выжать ужас из кубов путём поиска художественных ухищрений и тонкой настройки баланса.
Мультик твой представляет скорее научно-историческую ценность, нежели художественную. Но да, кубизм и беспредметность - сила, проверено ещё Малевичем.
Всё.
>НУ-КА ИЗВИНИСЬ БЫСТРО.
Извени
>>979852
>Тебе просто в голове представить недостаточно?
Представил. Думаю, будет охуенно. Теперь надо посмотреть на плейтестеров, как они отреагируют.
>вебм
Это история про бать-алкаша, который сначала пиздит мать, а затем и малого?
>Heider and Simmеl
Охуенно, наблюдая за фигурками было жутко по началу и под конец облегчение. Есть ли или как можно найти подобный контент для пополнения знаний по геймдизу по такому типу, с прототипами и их откликами на восприятие зрителя и пр.? Обычные книги и статьи по геймдизайну скачаны и в закладках, плюс сторителлинг. А вот на такое уникальное не натыкался.
>>977039 (OP)
Дочитал я наконец годо треды с января 23 года и теперь приступлю делать игоры мечты.
Теперь вопросец, для мобилок и веба использовать онли 3.6?
Или 4.3 рабочий и можно на нём лепить поделки?
А то по этой теме как то стихло всё, анончики молчат.
>Дочитал я наконец годо треды с января 23 года
Вот тебе делать нечего.
>по этой теме как то стихло всё
Просто все перешли на 4.х, на тройке только слоупоки вроде меня старые проекты допиливают.
Бери 4.х, там есть мобайл и совместимость рендереры, самое то для веба и мобилок. Кроме того, пока ты допилишь свой проект до релиза пройдет год-полтора, там уже 4.6 выйдет а тройка совсем актуальность потеряет.
>Зачем годот сохранил все 3 названия?
Потому что потерял связь между файлом и кэшем.
>удалять то он их с кампутера собирается?
Нет, не собирается. Можешь удалить вручную.
>Я годот закрыл уже
Так эти файлы нужны для запуска:
- folding: хранит то, как "свёрнут" код в файле;
- editstate: хранит позицию курсора в файле.
Ну, это чисто предположение по названию.
Если эти файлы удалить, всё сбросится к умолчанию.
Там ещё есть превьюхи кода (скриншоты текста)...
Почти в каждом треде пишу брать 3 для веба, хз чем ты их читал.
Не хочешь поделиться, что за механика такая? Или боишься, что мы её украдём и сделаем быстрее?
>душность способна придать дополнительного ужаса и чувства беспомощности
Если она плохо работает сама по себе, то вряд ли. В худшем случае будет выбивать из погружения. Игрок может терпеть плохую механику ради чего-то, но это не делает эту механику полезной для игры.
>Мультик твой представляет скорее научно-историческую ценность, нежели художественную.
Мультик демонстрирует, что человеческий мозг приписывает определённые свойства буквально всему, включая такие геометрические примитивы. Поэтому не обязательно делать реалистичную тян в реалистичном лесу, если нужно напугать игрока.
>ассетфлип
>посмотреть на плейтестеров, как они отреагируют
Да блин, я ж тебе говорю - плейтестеры - всё равно что обезьяны, они будут отвечать тебе в стиле:
>гыыы, классная тянка, а можно её раздеть?
>ого, у тебя тут и физика сисек с жопой есть??
>ну ты мужыыык, давай сделай ещё секас с ней
>прикольный монстр, добавь ему огромный член
>а здлелой так чтобы деревья рубить можно было
И ни слова про тестируемую механику, если она не бросается в глаза сильнее трясущихся 3D сисек.
А что потом? Ты сам говоришь, что это тестовая графика, то есть ты планируешь её заменить. Но плейтестеры позитивно откликнулись о графике. Получается, ты удалишь то, что им понравилось?
>>979999
Извини.
>>980002
>Это история про
Движущиеся фигурки ничего не значат, но каждый генерирует какой-то свой смысл в их движениях, непроизвольно выдумывая недостающее.
>>980024
>Есть ли или как можно найти подобный контент для пополнения знаний по геймдизу по такому типу, с прототипами и их откликами на восприятие зрителя и пр.?
Можно почитать оригинальную статью (17 страниц):
>Heider and Simmel (1944) An experimental study of apparent behavior.
В целом стоит изучать психологию, в частности:
https://en.wikipedia.org/wiki/Theory_of_mind
Нашлась ещё какая-то свежая статья про VR:
https://nature.com/articles/s41598-024-65532-0
>Или 4.3 рабочий
Да всё рабочее... почти. В 4.4 батчинг для 2D будет реализован для RD (Forward+ и Mobile). Лучше взять актуальную версию - пока будешь возиться, выйдут улучшенные версии 4.x. А ветка 3.x больше не будет развиваться, на ней только очень старые проекты.
В 4.x уже столько улучшений, что отказываться в пользу устаревшего GLES2 совсем не хочется.
Пока серишь и пидорасишь только ты, чмоня. Улетай в свой срачетред.
Задача: сохранить прогресс на выходе из игры.
Проблема: на Android минимум 5 путей закрытия.
1. Нажать кнопку "назад". Легко отловить в Godot.
2. Нажать кнопку "последние приложения", смахнуть превьюшку игры с экрана или нажать "закрыть все".
3. Открыть свойства игры и нажать "Остановить". Принудительная остановка а-ля диспетчер задач.
4. Нажать "домой", перейти в другое приложение, заблокировать экран и т.д., через некоторое время Android может спонтанно закрыть висящее фоном приложение, чтобы освободить память или снизить нагрузку на аккумулятор (зависит от настроек ОС).
5. Удерживать кнопку питания, пока телефон не выключится, или выбрать выключение из меню. Впрочем, этот вариант можно не рассматривать, аналогично внезапной потери питания от разряда.
Больше всего волнуют пункты 2 и 4.
Возможно ли вообще отловить такие моменты?
Можно ли на Android понять, что "окно не в фокусе"?
Или остаётся только сохранять каждые N минут?
Желательно чтоб решение было через GDScript...
У тебя там что гта? Просто сохраняй номер уровня или чекпоинта.
https://docs.godotengine.org/en/stable/tutorials/inputs/handling_quit_requests.html
Специальный официальный туториал, про мобилки тоже говорят. Я сохранял каждые пару минут, сохранял на важных моментах и плюс пытался поймать выход, что на мобилках конечно не всегда работает. Под веб похожие проблемы.
Хочу симулятор жизни сделать. Данных много.
>>980109
Читал эту страницу когда-то давно, но забыл.
>NOTIFICATION_APPLICATION_PAUSED
Вот это то, что мне нужно. Спасибо.
>плейтестеры - всё равно что обезьяны, они будут отвечать тебе
Так а их никто и не спрашивает. Ну, разве что чисто для вежливости. На плейтестеров надо просто смотреть. Где они тупят, а где сразу соображают; какие неочевидные для тебя штуки пытаются сделать; как реагируют лицом и телом на те или иные события.
>Если она плохо работает сама по себе, то вряд ли.
Ткнул пальцем наобум в несколько хорроров:
Granny - побег от бабки, прятки, пиксельхантинг и сбор предметов;
Silent Hill - брожение по локации, пиксельхантинг, разгадывание головоломок а-ля Петка и Василий Иваныч, неудобная боёвка;
Amnesia - брожение по локации, головоломки; но её я так и не осилил, глазам тяжело в такой темноте бродить.
Продолжая тыкать, обнаружим, что большинство чистых хорроров (которые не шутаны и не выживачи) геймплейно представляет собой пару-тройку механик, имеющих две основные цели:
1. Удержать игрока в одной локации, заставить люто бэктречить - дабы повысить шансы столкнуться с бабайкой;
2. Усложнить управление и обзор - дабы создать чувство беспомощности.
И при этом отсутствуют фановые механики. Осмелюсь даже предположить, что добавление таковых сразу же сменит игре жанр, она перестанет быть чистым хоррором и станет чем-то через дефис: хоррор-шутер, сурвайвал-хоррор, иммерсивсим-хоррор и т.д.
>Не хочешь поделиться, что за механика такая? Или боишься, что мы её украдём и сделаем быстрее?
Нет, просто у меня есть такая особенность, что если я описываю кому-то свою идею, то до конца её уже не довожу, типа уже всё, в мир выкинул. А пока она сидит в голове не рассказанная - вот тогда работа по её реализации кипит.
Тащемта прототип в любом случае покажу, да и на плейтесты понесу в геймдев-тусу у себя в города; да и сам я её спиздил у чела из интернета.
>Мультик демонстрирует
что художественное произведение может существовать без определённых элементов, но другие элементы критически важны. В частности, мультикам необходима драматургия, даже если действующие лица это геометрические фигурки.
Игра, будучи комплексным, синкретическим видом искусства, оперирует разными средствами выразительности. Геймплей среди них, конечно же, важнейшее, однако не стоит забывать, что разные игры стремятся выразить разные художественные идеи или дать игрокам разные переживания. Тетрис даёт одни чувства, Халфлайф другие, Пенумбра третьи. Фановый геймплей наводит одни переживания, а душный - другие.
Щас представил себе, как бы можно было Power Wash Simulator плейтестить в кубах. Дааа...
>1. Удержать игрока в одной локации, заставить люто бэктречить - дабы повысить шансы столкнуться с бабайкой;
>2. Усложнить управление и обзор - дабы создать чувство беспомощности.
Наблюдения хорошие, но выводы неправильные. В локации тебя удерживают, т.к. контента очень мало, а время накручивать нужно. Управление сложное из-за криворуких разрабов, которые не могли его сделать нормальным, как и камеру (не считая древних игр, в которых ограниченный обзор из-за слабого железа).
Про чувство беспомощности вообще непонятно... Беспомощности же нет - ты можешь закрыть игру. Беспомощность в рамках игры только вызывает фрустрацию из-за непроработанных механик. Ну, например... Невидимые стены - это страшно? Нет. Выбешивают, когда встречаются, но не пугают. Застревание в текстурах - страшно? Нет, бесит. Беспомощности игрока нужно избегать в играх.
Т.е. даже если игрока схватил монстр, нужно избегать катсцен, давая игроку кнопку "сопротивляться", иначе теряется фан от игры; игра деградирует в тупое кино.
>отсутствуют фановые механики
Ну и зачем тогда играть в хоррор, если нет фана?
Чем прятки от монстра - не фановая механика?
>она перестанет быть чистым хоррором и станет чем-то через дефис: хоррор-шутер, сурвайвал-хоррор, иммерсивсим-хоррор и т.д.
Т.е. станет полноценной игрой? А что плохого?
>А пока она сидит в голове не рассказанная - вот тогда работа по её реализации кипит.
Тяжело тебе, без записей... Диздок всё же нужен.
>>980126
>Power Wash Simulator плейтестить в кубах.
А что не так? Зачем тебе полноценные модели для проверки чисто механического удаления грязи? Я не понимаю, чем тебе не нравится кубы отмывать?
Вообще, прототипы не предназначены для игроков. В прототипы играет сам геймдизайнер, чтобы понять, работает та или иная механика или система игры. Посторонние игроки ничего не поймут в прототипе, поэтому публике их обычно совсем не показывают.
А ты зачем-то на какую-то тусовку собрался...
Ну, дело твоё. Слепить очередной инди-хоррор не сложно, сам же в примерах привёл "granny" - там максимально всратая инди-графика. Зачем только реалистичные ассеты, ориентируясь на такое...
>на тройке только слоупоки вроде меня старые проекты допиливают
Понял, сяб.
>пока ты допилишь свой проект до релиза пройдет год-полтора
Про долгострой нормальных проектов это понятно, меня больше интересовало в вопросах по мелких проектам, которые быстрее лепить пока средне-большое параллельно потихоньку пилится.
>>980034
Видел, и пока на трёшке для мелких поделок и остановился.
На всякий случай уточняю для уверенности, чтобы потом подводные не всплыли.
>>980039
>почитать оригинальную статью
>В целом стоит изучать психологию, в частности:
>https://en.wikipedia.org/wiki/Theory_of_mind
>https://nature.com/articles/s41598-024-65532-0
Благодарю, взял на заметку.
> отказываться в пользу устаревшего GLES2 совсем не хочется
Пон, значит всё же четверка.
>На плейтестеров надо просто смотреть. Где они тупят, а где сразу соображают; какие неочевидные для тебя штуки пытаются сделать;
Где бы еще найти таких замечательных людей. Я "плейтест" получил только когда мою игру, спустя год после релиза, подхватили мелкостримеры и записали пару своих прохождений на ютуб. Вот тогда я посмотрел и понял как надо было сделать тут, тут и тут. Апдейтить эту игру для меня уже неактуально, так что хуй знает зачем мне эта информация. Машину времени бы - тогда бы все учел.
С текущей, боюсь, такая же шняга получится. Делаешь как вслепую до самого релиза.
Где найти людей, которые играют в игры, чтобы дать им поиграть в свой билд? Ты шизофреник, который считает, что на земле живет только он и таинственные виртуальные мелкостримеры внутри электрического ящика?
Который при этом напишут внятный развернутый отзыв, а лучше запишут видос своего геймплея.
>на трёшке для мелких поделок
Не всё так очевидно. В 4.x много QoL улучшений.
На 4.x, начиная с 4.0, есть типизированные массивы:
https://godotengine.org/article/gdscript-progress-report-feature-complete-40/#typed-arrays
Что крайне полезно во многих задачах.
Начиная с 4.4, наконец-то введут типы в Dictionary:
https://godotengine.org/article/dev-snapshot-godot-4-4-dev-2/#typed-dictionaries
Что тоже крайне полезно.
Также из неочевидного, в 3.x нужно писать так:
>export var node_path: NodePath
>onready var node: Node = get_node(node_path)
А в 4.x ты пишешь просто:
>@export var node: Node
И всё работает без лишнего кода.
Ещё, кажется, только в 4.x можно сделать так:
Создаём два своих ресурса:
>class_name MyData extends Resource
>class_name MySubData extends MyData
Объявляем экспорт:
>@export var data: MyData
В инспекторе, в выпадающем меню будет:
>new MyData
>new MySubData
И ничего больше. В 3.x был полный бардак с этим.
Короче, новые фичи в GDScript "2.0" решают.
Да я б и не перешёл на Godot, если б не GDScript...
И в чем проблема?
А еще можно пригласить знакомых поиграть в билд и стоять у них за спиной, а еще лучше взять ноут на тусовки
Среди моих знакомых мало геймеров, и еще меньше тех, которые шарят за мой жанр. Если я им включу похожую успешную игру из стима они ее выключат минут через 5 нихуя не поняв. Такой себе плейтест. Нужна подходящая аудитория, вот я и спрашиваю где бы ее взять. Рандомов из интернета тоже хуй заставишь в бету погонять. Их в релиз то хуй заставишь пока как-то само чудом не взлетит.
Ахах, видел я как чел с Потатой с ноутом гонялся за маленькими девочками на фесте, и все от него убегали и отказывались играть.
Ещё по инспектору нод.
Если сделать так:
>@export var array: Array
Тут можно добавить через инспектор что угодно, но сначала требуется выбрать тип данных из огромного списка всех возможных типов. В 3.x/4.x - одинаково.
Если в 4.x сделать так:
>@export var numbers: Array[int]
Можно сразу добавлять целые числа. Удобно.
Можно сделать и так:
>@export var data: Array[MyData]
Тогда ты добавляешь MyData или его потомков.
Кажется, можно сделать даже так:
>@export var sprites: Array[Sprite]
И у тебя будут кнопки выбора Sprite из дерева сцены.
Это всё может казаться мелочью или не важным для маленьких проектов... Но это очень ускоряет работу с движком, точнее, с редактором сцен. Поэтому важно.
Плюс, типизация даёт бонус к производительности, однако, это не самое важное на этапе разработки.
>(не считая древних игр, в которых ограниченный обзор из-за слабого железа)
Какая разница, как выставлять камеру, слабое железо или сильное? Ракурсы в тех же СХ или РЕ - исключительно художественное решение, работающее на саспенс.
>Про чувство беспомощности вообще непонятно
Чувство беспомощности - когда ты не можешь дать отпор монстру, а можешь только бежать и прятаться. А монстр быстрее тебя. А укрытия не дают 100% безопасности. А управление инертное.
>ты можешь закрыть игру.
В хорроры не для этого играют.
>давая игроку кнопку "сопротивляться"
Далеко не всегда. Для экшон-хорроров норм такое. В обычных - очень редко. Там бывает даже - если ебака хотя бы появилась в кадре, то ты гарантированно труп.
>Ну и зачем тогда играть в хоррор, если нет фана?
Вот! Ключевой момент. Ты не понимаешь аудиторию.
В хорроры играют не ради фана. В них играют ради страха. Если тебе в хорроре не страшно, а весело, то либо это неправильный хоррор, либо ты делаешь что-то не так.
>Диздок всё же нужен.
Несомненно. При делании игры - обязательно. И при создании полноценного проекта я обязательно выделаю неделю-две на подготовительную часть и составление диздока.
А для прототипа и так сойдёт. Он прототип, он быстрый и грязный.
>Я не понимаю, чем тебе не нравится кубы отмывать?
Ты серьёзно или иронизируешь? Просто ну очевидно же, как тут ещё аргументировать-то.
>В прототипы играет сам геймдизайнер
Нет. Плейтестить ВСЕГДА должны посторонние люди, видящие игру в первый раз. Особенно когда геймдиз это человек-оркестр. При самостоятельном плейтестировании слишком сильны когнитивные искажения.
>>980165
>Где бы еще найти таких замечательных людей.
Ты в деревне живёшь? Просто во всех крупных городах есть локальные геймдев-тусовки, которые периодически собираются и плейтестируют друг друга. Заодно на таких тусах можно понабраться опыта на чужих ошибках.
Ну и семья и друзья-знакомые, конечно. То, что они не геймеры, может быть даже неплохо - помогает понять более широкую аудиторию.
Я прошлые проекты тестировал и на тех, и на других.
>Где бы еще найти таких замечательных людей
Родственники, друзья, знакомые, форумы...
>>980169
>лучше запишут видос своего геймплея
Записывал видос своего геймплея Katabasis.
Проблемы он так и не исправил, игру забросил.
>>980176
>Рандомов из интернета тоже хуй заставишь
Что у тебя там за жанр? Соревновательный шутер?
Кидай в тред, будем тестировать всем годотчем.
>>980177
>гонялся за маленькими девочками
Лицо представили? Я представил пикрил.
>>980184
>если не боишься, что упрут идею
Да кому твоя идея сдалась, их и так много.
>исключительно художественное решение
В Silent Hill туман скрывает низкую дальность прорисовки, это не художественное решение. Для сравнения, в GTA SA тоже близкий туман и это у некоторых игроков вызывает страх... Но это тупо ограничение старых приставок, а не задумка.
Сделать следящую из углов комнат камеру проще, чем полноценную камеру от третьего лица. Сегодня следящие камеры даже в инди редко встречаются - потому что давно решены все проблемы в движках.
>А управление инертное.
Вот в GTA 5 крайне инертное управление. Это чтобы игроки боялись чего-то? Выходит, GTA 5 - хоррор? В Escape from Tarkov вообще перебор с инертностью персонажа, так, что игроки жалуются - это хоррор?
>>ты можешь закрыть игру.
>В хорроры не для этого играют.
Но ты всё же можешь закрыть, если тебе неприятно.
>В хорроры играют не ради фана.
>В них играют ради страха.
Страх в хорроре - это и есть фан (fun) от игры. Но созданием страха занимаются фановые механики.
>Если тебе в хорроре не страшно, а весело
В русском нет корректного перевода "fun" в играх: "веселье" не передаёт/искажает суть этого термина. Поэтому мы здесь говорим "фан", "фановый" и т.д.
Ты даже такой элементарной базы не знаешь?
>неправильный хоррор
Возьмём, скажем, FNaF: по нему очень много порно с персонажами-монстрами. Это неправильный хоррор, если игроки сексуально возбуждаются из-за него?
>иронизируешь? Просто ну очевидно же
Не очевидно. Чем отмывание кубов хуже отмывания модельки дома с текстурами? Механика точно та же. Разнообразие моделек не является механикой, это расширение контента игры вширь, а не вглубь.
Ты ещё скажи, что для теста Splatoon обязательно необходимы детально проработанные 3D тянки, а механика краски совсем не работает без них. Лол.
>Плейтестить ВСЕГДА должны посторонние
Где ты это вычитал? Дай ссылку что ли. Потому что обычно в прототипы игр играет их геймдизайнер, особенно если это соло инди человек-оркестр.
>При самостоятельном плейтестировании слишком сильны когнитивные искажения.
Это когда ты 5 лет над игрой работаешь и знаешь абсолютно все закоулки, а нужен свежий взгляд новичка, чтобы потестить понятность/туториал. Механические прототипы должны работать вне зависимости от того, как долго ты в них играешь. Потому что игроки будут играть 1000+ часов в твой проект, а не только первые 15 минут знакомства.
Игру в разработке можно разделить на стадии:
1. Прототипы. Это сырые демки механик, которые бессмысленно показывать игрокам - в них играет геймдизайнер, чтобы скорректировать работу. Тут практически отсутствует какой-то контент. Часто прототип сфокусирован на одном элементе игры, отвечая на какой-то конкретный вопрос дизайна. Мультиплеер, конечно, тестируется с командой, проинструктированной, что вообще нужно делать.
2. Вертикальный срез. Полностью проработанная, но оторванная от остальной игры зона/локация, чтобы продемонстрировать качество ассетов и основные игровые механики потенциальным инвесторам или будущим игрокам (демо, трейлеры всякие). Тут уже финальные или почти финальные ассеты, но мало. Полноценно играть в это не выйдет (мало контента), однако, общая суть игры уже чётко улавливается.
3. Альфа/закрытое тестирование. Игра наполняется контентом, но всё ещё слишком много багов и других проблем, которые нужно решить прежде, чем можно будет показывать эту игру широкой публике.
4. Бета/открытое тестирование/ранний доступ. Игра практически готова, но всё ещё требуется проверить потенциальные ошибки, проблемы с юзабилити и т.д.
5. Релиз. Весь основной контент в игре и багов мало.
Видно, ты полностью пропустил стадию прототипа, однако, для вертикального среза у тебя нет своего собственного контента. Т.е. тебе рано показывать "смотрите, как я могу", но и прототипов не делал.
> туман скрывает низкую дальность прорисовки, это не художественное решение
Тогда это было так. Сегодня это кря-кря-мама-утка и современный туман на рейтрейсинге наоборот нагружает систему.
>Ракурсы в тех же СХ или РЕ - исключительно художественное решение, работающее на саспенс.
Продиктовано изначальным отсутствием второго стика на геймпаде в одних играх, а в других 2дшными фонами.
>в прототипы игр играет их геймдизайнер, особенно если это соло инди человек-оркестр
Инди человек-оркестр и так постоянно играет в свою игру. Написал код - запустил протестил, нарисовал уровень - запустил протестил. К моменту, когда прототип будет готов к плейтестам, индюк его весь наизусть знает и уже там нечего плейтестировать.
>Где ты это вычитал? Дай ссылку что ли.
Очевидный GMTK, да и вообще много употребляю всякого контента про геймдев. Ну и личный опыт.
>созданием страха занимаются фановые механики.
Поиграй в хорроры. Ты явно не понимаешь, как они работают. Созданием страха занимается атмосфера, а механики его лишь усиливают через погружение, потому что игрок переносит внутриигровое на себя.
>Вот в GTA 5
Вот тут ты, кстати, приводишь аргументы в пользу моей позиции, противореча своей.
>Сделать следящую из углов комнат камеру проще, чем полноценную камеру от третьего лица.
Ну как бы и да, но проще оно чисто в плане реализации. Железу насрать, следящая у тебя камера или полноценная. Супер Марио 64 передаёт привет.
>Но ты всё же можешь закрыть, если тебе неприятно.
Да и открывать тоже не обязан...
>FNaF это неправильный хоррор
Во-первых да, это не классический хоррор чисто механически. Во-вторых не оч понятен твой ход мысли. Во фнаф играют ради страха, потому что он страшный. И повтори его в кубах - скучная духота получится.
Не совсем. Накати мод на ремейк сх2 убирающий туман и увидишь, что новые здания в 30 метрах от игрока прогружаются
Внезапно одобряю твоё решение. Годоту нужен оконный софтрендер, чтобы писать оконные приложения без графического ускорения. Чтобы на древней встройке заводилось!
А еще лучше, сделать бы автономный компилятор гдскрипта. Чтобы на нём легковесные консольные утилиты писать без привязки к годоту вообще и с опциональным подключением годота при необходимости.
> imports System, IO as console # подключаем либы как во взрослых языках
> extends System.Object # расширяем системный класс объекта
> pub func main(args: array[string]): # здесь я ворую синтаксис раста: все объявления приватны кроме "pub"
> > console.print("Hello, world!") # ввод-вывод мы подключили как console, но это врядли так будет работать, это чисто как пример
Да и так норм, включаешь low processor mode и едешь. Вот например оконное приложение на годоте, от прошлого проджект менеджера годота: https://yurisizov.itch.io/boscaceoil-blue
А вот пиксельная рисовалка на годоте: https://orama-interactive.itch.io/pixelorama
И еще куча всего.
Я знаю, что приложения есть, но они используют опенгл/вулкан рендеры. Я хочу оконный рендер, вин32 для венды, гтк для линды.
Сам я не фанат мультиплеера и шутеров, но в овервоч наиграл 700+ часов до того, как выкатили "второй" с дурацкими изменениями, из-за которых я его бросил. Скатился из золота в бронзу и так и не поднялся, т.е. игрок из меня очень слабый и вообще я играл только потому что герои прикольные и анимации забавные...
Нейронка сказала: "можно, делай", но она слишком оптимистично на все вопросы отвечает обычно...
Скорее всего, ничего я не сделаю. Но чувствую, что остальные мои проекты слишком ограничивают потанцевал. Ну т.е. в "hero shooter" можно ведь что пожелаешь напихать и потом тупо цифры урона откалибровать, чтобы баланс был. А, да и не так-то нужен строгий баланс, тот же овервоч постоянно болтало с одного героя на другого. Имхо, прикольно делать "героя недели", чтоб все на него садились, не задрачивая одну и ту же "мета-игру" из года в год...
В соло не осилишь скоп. То, что ты описал - это работа для средней студии на пару лет. Кроме того, ниша хиро шутеров и так переполнена.
Сделай змейку лучше.
>и так постоянно играет в свою игру
>когда прототип будет готов к плейтестам
>там нечего плейтестировать
В смысле? А когда ты нажимаешь F5 - ты разве не плейтестишь? Плейтест - это именно "играть в игру". Классическое тестирование - это когда компьютер выполняет код и говорит "всё ок", либо "полученные данные не сходятся с ожидаемыми". Классически, плейтесты игр откладывали на потом из-за очень медленного процесса разработки. Только движки с быстрым циклом разработки позволяют плейтестить проект хоть после каждой написанной строчки кода.
>Созданием страха занимается атмосфера
Ой, всё. Киношные хорроры страшны не потому, что атмосферные, а потому что герои-дебилы зашли в незнакомое место и трогают чужие вещи без спроса. Игровой хоррор не может завести героя куда-то без механики, заставляющей игрока идти в незнакомое место, трогать вещи и натыкаться на их хозяина. Без атмосферы хоррор работает, а вот без механик - нет.
Пример хоррора без атмосферы:
1. Игрок в комнате с единственным выходом.
2. Комната медленно заполняется жидкостью. Это МЕХАНИКА, которая требует от игрока выйти наружу.
3. Игрок пытается выйти - дверь заперта. Чтоб выйти, игроку нужно найти ключ, но жидкость мутная, скоро заполнит всю комнату. Вызывается страх, что ты не успеешь вовремя выйти. Чисто механический страх.
В кино герой будет паниковать, бегать по комнате в тщетных поисках ключа, кричать, биться об дверь. Игровой хоррор должен заставить игрока СЫГРАТЬ паникующего героя. И это делается через механики. Графически тут достаточно показать, что и где, чтоб понятно было, что вообще происходит и чем грозит. Потом, если механики работают, можно нагнетать побольше страха кровавыми следами и т.п., но это декорации, которые только усиливают механику. Декорации (атмосфера) сами по себе не работают.
>а механики его лишь усиливают через погружение, потому что игрок переносит внутриигровое на себя.
Здесь-то ты и ошибся. Безусловно, именно механики создают погружение в игру, иначе б люди говорили о погружении в статичные картинки. Но погружение-то первично. Сначала погружаешься в мир абстрактных фигурок, где круглое - хорошо, а острое - плохо. А уже потом начинаешь бояться внезапно выскочившего треугольника. Вот чётко помню, как я неоднократно пугался крипера в Майнкрафте, и видел клипы от совершенно разных стримеров, кто тоже пугался. Насколько ужасен крипер? Это тупо ходячий огурец. Однако, механически он моментально убивает, либо оставляет с минимальным здоровьем; смерть - это механическая потеря драгоценных ресурсов, тяжело добытых в пещерах, а порой и вовсе уникальных. Т.е. пугает не картинка крипера, не атмосфера пещер из кубиков. Пугает риск сдохнуть от взрыва внезапного крипера, и это работает лишь за счёт механик. Т.е. механики не усиливают, а формируют страх. Если редуцировать Майнкрафт до кубиков без текстур, то взрывоопасный моб не перестанет быть пугающим.
Отличие игры-хоррора от хоррора в Майнкрафте заключается в количестве. В хорроре ты боишься постоянно, т.к. все механики сфокусированы на устрашении игрока, а в Майнкрафте эта ситуация с крипером возникает редко и её легко избежать, как только узнаешь, что мобы спавнятся в темноте. Т.е. атмосфера тут никаким боком вообще, суть в соотношении определённых игровых механик.
Ещё замечу, что если в хоррор можно играть как-то "неправильно", то это механическая проблема. Ты не можешь требовать от игрока играть "правильно", если игровые механики позволяют играть "неправильно". И плевать, что у тебя в игре "атмосфера страшная".
>>Вот в GTA 5
>приводишь аргументы в пользу моей позиции
В GTA, начиная с IV, управление стало инертным ради кинематографичности. Читал про механику прыжка, почему в GTA IV она такая плохая и почему в GTA V пофиксили, да не полностью. Всё ради реализма. К хоррору отношения не имеет, т.к. игры не про то, а геймплейно эта инертность лишь мешает игроку.
Тарков - это "шутер с извлечением (лута)" - если ты почему-то сдох - теряешь весь лут и шмотки. Шмотки можно покупать за донат... Смекаешь? Все механики нацелены на то, чтобы игрок облажался, потерял всё говно, расстроился и купил больше говна за бабки, надеясь "отыграться", как в казино. Хоррором тут не пахнет, а официальный обоснуй - "это реализм" (ага, конечно, и смерть с одной пули в ногу тоже реализм). Конечно, игрок может бояться потери лута - но это механический страх, а не какая-то там атмосфера. В любой онлайн-игре с падающим игрока лутом и PvP большинство будет бояться потерять этот лут.
Но опять же. Почему Тарков - это шутер, а не хоррор? Потому что механики сфокусированы не на том, чтоб пугать игрока, а на том, чтобы лутать ящики и трупы. Отбери оружие, увеличь число агрессивных ботов и напряжённый шутер превратится в чистый хоррор.
>>FNaF это неправильный хоррор
>не оч понятен твой ход мысли
Ты утверждаешь: "если ты в хорроре вместо страха веселишься, то это неправильный хоррор". Я привёл пример, что монстры не страшные и вообще на них наяривают на порносайтах, делают фан-порно-игры. Получается, целевая аудитория не боится, а дрочит. Впрочем, не важно, это уже какой-то спор о вкусах.
>И повтори его в кубах - скучная духота получится.
Не знаю. Начал делать хоррор на кубах - теперь мне страшно открывать его в редакторе Godot. Может, попробовать работать с включённым светом? Хм...
>Пример хоррора без атмосферы:
>1. Игрок в комнате с единственным выходом.
>2. Комната медленно заполняется жидкостью. Это МЕХАНИКА, которая требует от игрока выйти наружу.
>3. Игрок пытается выйти - дверь заперта. Чтоб выйти, игроку нужно найти ключ, но жидкость мутная, скоро заполнит всю комнату. Вызывается страх, что ты не успеешь вовремя выйти. Чисто механический страх.
Ты только что подводные уровни в сонике записал в хорроры
В коромысле.
Я тестирую, но не плейтестирую. Я оцениваю техническую часть. А когда техническая уже доделана и надо бы оценивать эмоциональную, то я уже настолько её заиграл, что единственная эмоция - заебало.
>герои-дебилы
Есть страшные хорроры, а есть смешные. И это вот второй случай. Потому что тупые герои наоборот выбивают из саспенса, зритель перестаёт ассоциировать себя с ними. А в страшных герои не дебилы и действуют логично.
>Без атмосферы хоррор работает
Нет, чел. Никогда. Вообще. Совсем. Ни в какой ситуации. Всё наоборот. Хоррор делается атмосферой и только ей.
>Пример хоррора без атмосферы
Ну тебе уже ответили, лол
>В GTA, начиная с IV, управление стало инертным ради кинематографичности
Ну да. Одни и те же механики могут иметь разное значение в зависимости от контекста. Не вижу противоречий.
>крипер в Майнкрафте
Испуг от крипера называется скример. Когда тебе в поле внимания резко вкидывается образ, которого надо избегать. И это очень дешёвый трюк. И любители хорроров ненавидят скримеры.
И зря ты Майн приплёл. Он часто фигурирует в списках типа "топ 10 хоррор-моментов в не-хоррор играх". Но вовсе не из-за криперов, а из-за пещер, да ещё если там музычка начнёт играть - вот с этого народ обсирается. Одни и те же мобы спавнятся ночью на поверхности и в любое время в пещерах, но пещеры страшные, а поверхность нет. И почему бы это?
Из этих же списков накинем Рэвенхолм, который чисто механически не отличается от всей остальной ХЛ2, но страшный чисто из-за атмосферы. Можно возразить - а как же гравипушка? Но гравипушка как раз таки наоборот разбавляет весельем тамошнюю жуть. И ловушки тоже. Хотя ещё там есть быстрые и ядовитые крабы+зомби, и они пугают как раз через геймплей. И эта пугалочка работает во всех дальнейших главах. Комментарии разработчиков, кстати, там весьма занятные. Прямо ооочень рекомендую почитать. Да и не только там, но и во всех валвовских играх, где они есть.
А ещё, если сравнить крипера из Майнкрафта и волков из Vintage Story, то волки пострашнее будут. При том, что от крипера чисто механически больше вреда: и дамаг выше, и постройки может разрушить; а от волков помогает любая броня, начиная с медной. Зато волки рычат страшно.
>Почему Тарков - это шутер, а не хоррор? ... Отбери оружие ...
И всё равно нихуя страшно не будет.
Хотя я натуралв Тарков не играл, не могу про него ничего сказать. Зато могу сказать по Сталкеру. Где при каждом посещении лабораторий начинаешь откладывать кирпичи так, что аж смеркалось... Механически лабы не отличаются от всей остальной игры НИЧЕМ. Только страшными звуками. На Агропроме так вообще бандиты, солдаты и всего два монстра (три-четыре на высокой сложности). Но ты туда спускаешься и... Лампочка скрипит крутится, электры бахают, ветер воет. Я вообще с трудом припоминаю хоть в какой-нибудь игре локацию страшнее, чем Агропром в ТЧ. Полностью зачищенный пустой Агропром, где уже точно никого нет.
А бэкрумс? Сука да это ж просто картиночки. Не игры, не фильмы даже. Просто фотографии каких-то пустых пространств. Какие могут быть механики у фотографий? А они всё равно пугают просто вот потому что.
>аниматроники не страшные
1. Вообще-то они пиздец стрёмные. Да тащемта ирл любые аниматроники пугают сами по себе, а фнафовские так ещё и всратые.
2. Порносайты это не В хорроре, это ВНЕ его. В игре всё ещё страшно. И все нормальные люди, играющие во фнаф, боятся.
3. Правило 34 это так-то норма.
>Ты не можешь требовать от игрока играть "правильно", если игровые механики позволяют играть "неправильно".
Тащемта в любую игру можно играть "неправильно", какие бы отточенные механики ни были. И это не проблема вовсе. Просто задача геймдиза - предусмотреть разные стили игры. А задача саунддиза, левелдиза, художника и прочих дизов - предусмотреть, чтобы эти разные стили не заруинили экспириенс. Факинг инглиш. Хотя такие стили, как спидран, заруинят его в любом случае, но тут уже похеру. Мы же целимся не в двух с половиной задротов, а в сколько-нибудь массовую аудиторию.
Но это к теме не относится, это не на прототипе чинится, а выявляется на плейтестах вертикального среза.
>Начал делать хоррор на кубах
Ну так покажи, что ж там у тебя такого страшного.
>Пример хоррора без атмосферы:
>1. Игрок в комнате с единственным выходом.
>2. Комната медленно заполняется жидкостью. Это МЕХАНИКА, которая требует от игрока выйти наружу.
>3. Игрок пытается выйти - дверь заперта. Чтоб выйти, игроку нужно найти ключ, но жидкость мутная, скоро заполнит всю комнату.
Типичный trap из пилы и вообще многих пукает вода и лвл под водой/в космосе
>хорроре ты боишься постоянно
Нет игрок просто перегорит надо чередовать ,а оучше разбовлять юмором
Годно, я тоже пишу простые программы для автоматизации некоторых задач на годо
Хуй знает, я давным давно на винформах формошлепил, и чуть менее давно на гтк - по моему опыту с годотом легче договориться в плане того, как именно ты хочешь УЙ сделать. Вообще самое беcпроблемное из всех формошлеп. Разве что системные темы не подхватывает.
Ведь то и то мы можем использовать откуда угодно. Ну кроме того, что глобальный скрипт загружается раньше всего и в нем удобно инициализировать самые важные переменные
Или я чет не догоняю?
Глобальный скрипт (он же синглтон) создаёт экземпляр, но не создаёт класс (ну, по крайней мере, именованный, так-то любой скрипт это класс, к которому можно обратиться по пути к файлу). Скрипт с class_name создаёт класс с именем, но не создаёт экземпляр класса сам по себе.
Соответственно, в синглтоне можно использовать объекты и обычные функции. В скрипте-классе - только статические. Однако если сделаешь var sooqa = SOOQA.new(), то у полученного объекта можно будет использовать обычные функции и переменные, но тогда они будут находиться в созданном объекте sooqa, а не во всём классе сразу.
Примеры, когда оно может понадобиться в смысле глобальности:
Синглтон - для словаря состояния игры, для хранения настроек.
Скрипт-класс - для библиотеки вспомогательных функций.
шиз-синглтоны-не-нужны будет против Обычно синглтоны используются в обоих случаях, а скрипт-класс - когда надо именно что описать класс, из которого потом будут создаваться ресурсы или ноды. Например:
class_name Breakable
extends RigidBody2D
# дальше описываешь логику разбиваемости
или:
class_name CharacterData
extends Resource
# дальше @экспортируешь поля в этом ресурсе
С первым примером ты сможешь создавать ноды Breakable прямо в редакторе. Со вторым - персонажу дать какую-то настраиваемую инфу через @export var char_data: CharacterData
Добавлю ещё.
Ты даже можешь содать класс
class_name SOOQA
extends Node
а потом создать скрипт
extends SOOQA
и его сделать синглтоном.
Но это изврат, конечно.
Все же игровые движки не для этого делаются изначально, можно даже в этих тредах найти десяток случаев когда гуй не позволял что-то сделать, например уменьшить маргин вокруг текста на кнопке - >>933070 →
Там есть еще всякие другие нюансы типа поддержки скринридеров.
Возьмем такой пример:
Типа, вот у нас есть сущность A (текущая локация) и сущность B (массив с оружием игрока)
У каждой есть какое-то состояние.
Есть процесс сохранения:
A -> игрок заходит на локацию -> сохранение актуальной локации в A
B -> игрок получает новое оружие ->сохранение актуального оружия в B
И предположим случается ситуация, когда сущность A и B связаны. Например, игрок заходит на локацию A и должен автоматически получить новое оружие в B. И вот в этот момент происходит экстренное закрытие игры. И процесс сохранения "сломался":
A -> игрок заходит на локацию -> сохранение актуальной локации в A (тут все ок)
B -> игрок получает новое оружие -> приложение закрывается -> новое оружие не сохраняется в B
И после запуска игрок начнет на новой локации, но без нового оружия.
Вопрос. Как с таким бороться? Пилить что-то вроде транзакций, как в SQL, или такой механизм уже встроен в годот (по первым ссылкам в гугле не нашел)
Понятно, что тут можно выдавать оружие после захода на уровень, или проверять наличие перед запуском и т.п. и т.д. Но это просто пример из головы, чтобы было понятно.
Слом сохранений после краша я и в ААА играх видел. Базы данных, не смотря на их транзакционную природу, тоже бывает разваливаются после падения сервера. Всегда есть шанс упасть так, что либо все посыпется, либо ты потеряешь последнюю транзакцию. Выбирай второй путь, проверяй валидность сейва и не давай его грузить если он помят.
Сейчас ебусь с блендером, и это какой-то ад, где непонятно даже как удалить анимацию.
>как удалить анимацию
1. Нажми на крестик, чтобы открепить анимацию.
2. Выбери очистку лишнего или переоткрой файл.
Анимация без "пользователя" не сохраняется.
>простые программы для 3д лоу поли
https://duckduckgo.com/?q=easy+3d+low+poly+modeling
>спокойно переносить в годот
obj для простейшего и gltf для анимаций.
Я в блокбенче делаю. А самое простое напрямую в годоте с помощью csg мешей.
>при некорректном завершении игры
На сохранении:
1. Переименовываешь last.save в prev.save.
2. Сохраняешь игру в last.save.
На загрузке:
1. Если игра не находит last.save, грузит prev.save.
2. Если last.save повреждён, грузится prev.save.
Можно хоть 10 предыдущих хранить.
>новое оружие не сохраняется в B
Тогда у тебя конца файла не будет -> сейв сломан.
Больше волнуйся о загрузке в новой версии игры.
>Испуг от крипера называется скример
Скример - это внезапное появление. Крипер пугает присутствием даже на поверхности, когда он в 15 метрах от твоего новенького красивого домика.
>пещеры страшные, а поверхность нет
Но пещеры в Майнкрафте не страшнее поверхности...
>фотографии каких-то пустых пространств
>ирл любые аниматроники пугают сами по себе
Это вообще никак не относится к хоррорам:
https://ru.wikipedia.org/wiki/Лиминальное_пространство
https://ru.wikipedia.org/wiki/Зловещая_долина
Эти эффекты субъективны и работают на 30% людей максимум, потому что у них с мозгами что-то не так. Банальные зомби и роботы не должны пугать своим внешним видом - это какая-то проблема с психикой. Впрочем, древние люди много чего пугались из-за неопытности, может быть, в этом тоже проблема? Деревенщине покажи автомобиль - испугается, а к функционально аналогичной лошади он привык уже.
Короче, проблема в субъективности. А если хорроры субъективны, то и тестировать их бесполезно... 30% испугается твоих "лиминальных пространств" или "потрёпанных роботов", а 70% хмыкнут и скажут: "симулятор ходьбы по комнатам с роботами - херня, придумай какой-нибудь другой, фановый геймплей". Повезёт, если твою игру купят только целевые 30%.
>Эти эффекты субъективны и работают на 30% людей максимум
Верный способ отличить нпс от не нпс.
>покажи, что ж там у тебя такого страшного
Сделал ламповую МЕХАНИКУ мигающих лампочек.
Только попробуй возразить, что это не механика...
P.S. Включил свет для записи. А лампа мигает...
>Глобальный скрипт (он же синглтон)
В Godot/GDScript невозможно создать полноценный синглтон, потому что нет способов запретить создание дополнительных экземпляров класса. Вся суть этого антипаттерна в запрете создавать экземпляры, а не в глобальном доступе. На попытку вызвать Input.new(), например, Godot справедливо ругается.
У полноценного синглтона ты можешь сделать так:
>var global = Global.new()
И получить ЕДИНСТВЕННЫЙ существующий объект вместо отдельного экземпляра этого класса.
>для словаря состояния игры, для хранения настроек.
>шиз-синглтоны-не-нужны будет против
Да, против, потому что так ты связываешь состояние, настройки и всё остальное в тугой клубок, который придётся рано или поздно распутывать (разрубать, потому что хрен ты его распутаешь через год-два).
Состояние игры - совокупность состояний систем и объектов игры. Не нужно сваливать всё в кучу типа:
>var chest_in_the_room_to_the_left_from_the_door_on_the_second_floor_in_the_building_next_to_the_shop_is_opened: bool
Потому что забудешь и запутаешься.
Ещё хуже что-то из разряда "var chest_69b: bool". Ты ж синглтоны из-за лени используешь - лень печатать...
Аналогично с настройками. Если какая-то настройка принадлежит чему-то одному, этот кто-то должен быть единственным хранителем настройки. Глобальными настройки могут быть, только если они действуют на большинство элементов (тема GUI, биндинги клавиш). Нужно избегать свалки настроек типа:
>var chest_color_in_the_room_to_the_left_from_the_door_on_the_second_floor_in_the_building_next_to_the_shop: Color
Потому что забудешь и запутаешься.
Разве это не очевидно? Вряд ли ты новичок, который считает, что если что-то легко написать - будет так же легко и поддерживать на протяжении многих лет.
Или ты думаешь, что новичок не будет создавать миллион непонятных переменных в твоём любимом сингтоне, содержимое или ответственность которых он потом не сможет вспомнить? По-твоему, лучше допустить, чтобы новичок наговнокодил и осознал проблему на практике, чем сразу ему её указать?
Алсо, "autoloads" в Godot кривые и похожи на костыль, который когда-то очень давно сунули, а убрать теперь нельзя из-за того, что много проектов сломаются. Собственно, главная проблема с синглтонами - наговнокодив однажды, изменить потом тяжело.
Т.е. твоя "chest_69b" в настройках/состоянии игры отвечает непонятно за что, но если её случайно неправильно изменить - игра ломается непонятным образом, и ты потратишь кучу времени на поиск проблемного кода в неизвестном месте. А корень проблемы - в создании глобальной сущности, что не должна была быть глобальной изначально.
Глобальное состояние - это как оператор "goto". На первый взгляд, упрощает код, но потом обосрёшься выискивать причины сотен непонятных ошибок.
Но, если ты делаешь только простые игры за месяц, заполняя их в основном картинками - тогда ты вряд ли когда-нибудь осознаешь проблему с синглтонами.
>>980789
Воу-воу, так ты один и тот же анон. Ну, всё становится на свои места.
Крч не вижу смысла дальше пережёвывать эти несчастные хорроры. Все аргументы озвучены, дальше уже идёт повторение по кругу. Стороны остались при своём, но мудрый читатель сможет сделать выводы, если захочет. Не будем больше засирать годотред чем-то не относящимся к Годоту напрямую.
>Не будем больше засирать годотред чем-то не относящимся к Годоту напрямую.
Согласен. Тем более что уже сказано, что хорроры субъективны, а о вкусах спорить бесполезно.
>всё становится на свои места
Чего становится? Ты мне скажи, зачем новичкам рекомендуешь обмазывать проекты автолодами ("синглтонами", которые не синглтоны, а костыль конкретно Godot), если от этого в будущем у них проблемы будут? Это всё равно что предлагать новичку объявлять глобальные переменные вместо использования аргументов функций для передачи локальных данных. Что-то из разряда:
>var a; var b; var c
>func sum() -> void: c = a + b
>func _process(delta) -> void: a = delta; sum()
Вот скажи мне, тебе такой код нравится? Почему? Синглтоны по сути то же самое: хранят неизвестные данные неизвестно где, а корректность твоего кода в другом месте зависит от корректности синглтона.
Я просто неоднократно на эти грабли наступал в прошлом и не хочу, чтобы другие шли по ним же. Проблема становится очевидной, когда начинаешь разрабатывать что-то сложнее условной "змейки", продолжая обмазываться глобальными костылями.
У тебя просто баттхерт от того что в голове насрано ООП из какого-то языка который ты знаешь и ты пытаешься натянуть этот язык на годот. В годоте есть автолоад и есть сигналы и есть ноды. А ты думаешь какими-то синглтонами, классами. Да, это можно делать, но как ты и сам заметил - это не путь годот. В годоте мы инстансим ноды и управляем ими с помощью сигналов. Все наследования и интерфейсы можно настроить прямо в дереве нодов.
>корректность твоего кода в другом месте зависит от корректности синглтона.
Более того, корректная работа твоего кода зависит от любой другой функции, плагинов, библиотек, от самого годота, от системы на которой он работает и вообще, представляешь!
В любых языках бывают антифичи, если они возможны, это еще не значит что ими надо пользоваться.
Отбой, сделал с помощью нейронки консоль, выводящую логи на игровой экран и поставил ее подгружаться самой первой.
Лог файл там где и положено (либо настраиваешь местоположение в настройках проекта)
https://docs.godotengine.org/en/stable/tutorials/io/data_paths.html#accessing-persistent-user-data-user
Например если ты напишешь такой батник, или другим способом запустишь процесс, например из гдскрипта OS.execute()
start %APPDATA%\Godot\app_userdata\DUMER\logs
То у тебя откроется папка логов соответствующей игры.
Чем годот лучше/хуже юнити?
почему именно годот?
Годот проще в изучении. В юнити слишком много функционала. Если твоя цель не пилить AA, то выбирай годот.
А, все, нашел is_class(string). Странно, что поведение у него отличное от кейворда is. Да и принимает он строку. Но хоть что-то.
Способов то много, но скорее всего таким инструментом пользоваться не надо, потому что ты себя загонишь в полный ад.
Но если говорить в рамках ООП. Во-первых, по твоему описанию ты дублируешь механизмы ООП. Если у тебя поведение разное, то оно и должно описываться в перегруженных функциях самих классов, а не проверятся извне через is, да это и медленнее скорее всего. У каждого класса должны быть свой say(): meow() или say(): bark(), а не общий say() который проверяет is cat: meow() elif is dog: bark()
Во-вторых, ты можешь просто воспользоваться логикой. Ну типа ты мог бы проверять не is C, а not is A. Но это все равно приведет к аду.
В-третьих есть еще всякие инструменты типа Class.get_global_name, get_instance_base_type и так далее
Но в целом наверняка это можно сделать без ООП, какими нибудь компонентами.
Компоненты на самом деле никогда не противоречили ООП, я хз какой шизоид это придумал а остальные подхватили.
Это вообще никак не противоречит сказанному. Но можно переформулировать "это наверняка можно сделать без наследования".
Вообще, для таких вопросов тут на доске целый тред есть, не рекомендуется их спрашивать в тредах движков.
>Чего становится?
А то, что с тобой спорить бесполезно, ты игнорируешь неудобные аргументы, подстраиваешь чужие формулировки под свою логику и разбиваешь соломенные чучела, которые сам же и выстраиваешь. Другими приёмами демагогии тоже пользуешься, просто эти три прям выше присутствуют.
Спасибо за рекомендации. Я знаю, что это не по ООП-шному. Посижу подумаю.
Поздно рыпатца. Вы все уже зашкварены. Петушары.
Кстати тюринг тоже из этих был. Так что вдвойне петушары.
Единственное верный способ не зашкваритца это надеть лапти и вязать лукошки.
> какой шизоид это придумал
Школьник, который предыдущие джва года нахваливал ЕЦС по всем тредам гдача. Щас чот притих. Повзрослел видать.
Строй табличку 2 на 2, если у тебя понимание вызывает затруднения. Итого возможны: ООП с компонентами, ООП без компонентов, компоненты без ООП, что-то без ООП и компонентов.
>в голове насрано ООП из какого-то языка
Начинал вообще с чисто процедурного кода, на ООП перешёл только спустя много месяцев процедурки. Проблема с глобальным доступом к чему-либо не зависит от парадигмы, в которой ты работаешь.
>и ты пытаешься натянуть этот язык на годот
Godot, ВНЕЗАПНО, целиком построен на ООП и даже принуждает к ООП - в GDScript отсутствует способ объявления процедур/функций отдельно от класса.
Вот статья Хуана с официального сайта:
https://godotengine.org/article/why-isnt-godot-ecs-based-game-engine/#why-does-godot-not-use-ecs
>Godot uses more traditional OOP by providing Nodes, that contain both data and logic. It also makes heavy use of inheritance.
Godot == ООП. Это база, это знать нужно.
>В годоте есть
Ну есть и есть. В других языках оператор goto есть:
https://ru.wikipedia.org/wiki/Goto#Критика
>сигналы
Их обычно называют событиями, т.е. Events, и они применяются в любом современном ООП языке.
https://ru.wikipedia.org/wiki/Событие_(объектно-ориентированное_программирование)
>ноды
Это базовые классы и их экземпляры (объекты).
>В годоте мы инстансим ноды
Создаём объекты - экземпляры классов.
>управляем ими с помощью сигналов
Это событийно-ориентированная архитектура:
https://ru.wikipedia.org/wiki/Событийно-ориентированная_архитектура
>is_class(string)
Этот метод работает только с базовыми классами:
https://docs.godotengine.org/en/stable/classes/class_object.html#class-object-method-is-class
>Note: This method ignores class_name declarations in the object's script.
Обсуждение этой темы:
https://github.com/godotengine/godot/issues/21789
>>980948
>"экземляр C is B" выдает false.
Странно. У тебя там не сломался кэш скриптов? В некоторых случаях Godot забывает, какие скрипты от каких наследуются, и тогда самым простым рабочим решением будет: сбросить кэш, перезапустить Godot.
И в чём проблема добавить ещё одну проверку?
>_ elif node is B or node is C: ...
Если сброс кэша не поможет решить этот баг.
>>980952
>У каждого класса должны быть свой say(): meow() или say(): bark(), а не общий say() который проверяет is cat: meow() elif is dog: bark()
Зависит от задачи. Ты рассматриваешь ситуацию, в которой ты вызываешь метод объекта. Но в другой ситуации тебе нужно сделать что-то снаружи этого объекта в зависимости от его класса. Банальная сортировка как пример:
>for animal in animals:
>_ if animal is Herbivore: herbivores.add_child(animal)
>_ elif animal is Predator: predators.add_child(animal)
В данном примере мы не можем сделать метод "put_yourself_in_category()", потому что тогда все наследники Animal должны будут знать о нодах в какой-то совершенно посторонней сцене - обычно требуется абстрагировать животных от этого.
Если дерево наследования такое:
>Animal
>_ Predator
>_ _ Cat
>_ _ Dog
Тогда "animal is Predator" должно выдавать true и для Cat, и для Dog, а не только для Predator. Ведь, по логике наследования, Cat и Dog являются Predator.
>сделать без ООП, какими нибудь компонентами
1. Компоненты никак не противоречат ООП.
2. Там в любом случае ООП. В базе движка.
Компонентами ты будешь делать как-то так:
>for animal in animals:
>_ if "diet" in animal.traits: # есть компонент диеты?
>_ _ match animal.traits["diet"]: # проверяем значение
>_ _ _ "plant": herbivores.add_child(animal)
>_ _ _ "meat": predators.add_child(animal)
Это разве не ООП? Это всё то же ООП. Но вместо наследования используется экземпляр Dictionary с методами и данными, встроенный в объект animal. Использование метода add_child() класса Node тут вообще никак не изменилось - значит, это ООП.
Если хотел написать "без наследования", так и пиши.
>put_yourself_in_category
Конечно так делать не надо, а вот отвечать какой они категории, без наследования - вполне. Что-то типа get_category, а там хоть битовые флаги, хоть json, хоть sqlite.
>Если хотел написать "без наследования", так и пиши.
Вообще-то позже я так и написал, а еще и тебя поправлю:
> Компоненты никак не противоречат ООП.
Я и не писал такого. Использовать компоненты без ООП не означает, что они противоречат.
>работа для средней студии на пару лет
А с чего такой вывод, интересно?
Что нужно для геройского шутера?
1. Одна карта на CSG примитивах.
2. Один режим игры с win/lose условием.
3. Базовый контроллер героя: бег, прыжок.
4. Пара героев с парой разных способностей.
5. Простейший авторитарный сервер...
Меня беспокоит только сервер. Никогда не делал.
Мне однажды снилось что я игру релизнул и заработал на этом. Вот это хуйня так хуйня.
Ну и получишь и не преальфу, и не тестовый прототип даже. Смысл?
Возможно упакованная-наследуемая подтягивает куски из родителя? А может в туторе ошибка.
Можно как-нибудь отключить сортировку по Y для одной конкретной ноды?
Никогда не пользовался инхеритед сценами. Всегда с ними что-то да по другому происходило.
И какой же результат ты хочешь получить отключив сортировку? Неопределенный? Всегда сверху?
Чтобы всегда был под тем, что сортируется. Как другие ноды, которые не являются дочерними Y-sort. Я знаю, что могу выставлять Z-index, но тогда мне придется проставлять его в большей части нод, что не очень адекватно звучит.
Сделай два слоя ysort. Один внизу (сверху в древе сцен), другой наверху (ниже в древе сцен). Ноды которые "под" отправляй на первый, которые "над" на второй.
У меня на трешке была игра с шестью такими слоями, лол.
Ну а если z-indexc задавать только самой этой ноде? Или не добавлять ее под y-sort? Не знаю что будет если ноде выставить set_as_toplevel и поменять z. А еще есть z as relative. Что если именно этой ноде сделать.
Такая была?
Еще есть 4, но не знаю откуда оригинал
>Смысл?
Чтобы было где реализовывать девочек-монстров?
Узнал, что hero shooter может быть синглплеерным.
Т.е. можно сервер вообще не делать - ещё проще!
>The argument "delta" is never used...
ТОП КЕК + ЖИЗА! ОП, ставь эту!
>хотя в туторе именно так
В каком? Это официальный?
>change_scene_to_packed
>change_scene_to_file
Эти функции подходят только очень простым играм, сколько-либо большие проекты их не используют. Практически то же самое, как если сделать так:
>scene.queue_free()
>scene = load("res://path/file.tscn").instantiate()
>root_node.add_child(scene)
На практике тебе обычно нужно больше, чем это, и поэтому эти функции не подходят многим играм.
Наследуемые сцены иногда глючат, но не страшно.
Ты лучше скажи, зачем тебе загонять спрайт под все остальные спрайты. Он же тогда невидимым будет?
Может, тебе CanvasLayer нужен отдельный?
К сожалению, это рушит всю структуру моего дерева.
>>981356
Оно не должно быть под всеми спрайтами, а только под теми, которые сортируются. Например, он будет рисоваться над тайлмапой с полом, но под персонажем игрока.
>>981386 (OP)
>>981386 (OP)