Шапка: https://hipolink.me/godothread
Предыдущий: >>946416 (OP)
Архивный: >>942134 (OP)
Аноны, в Disco Elysium и PoE от обсидиан, да и во многих других играх, используют в качества задника просто огромную пикчу разрезанную на куски. Как мне это реализовать в годо? Я гуглил, но нихуя не нашёл.
Всмысле реализовать? Это буквально тупо добавить спрайт в сцену. О какой реализации идет речь.
Руками. Берешь и режешь и вставляет спрайтами как тебе нужно, чтобы y-sort их учитывал. Довольно много муторной ручной и скучной работы. Поэтому теперь я предпочитаю 3д.
Чего рвонькаешь? В чем проблема? Я сейчас пихнул в сцену спрайт размером 24000x16000, фпс (без всинка) был 3200, стал 3150. Ты чет видишь проблемы там, где их нет. И хамишь еще, хоть я и не тот анон, которому ты отвечаешь.
Режут пикчу чтобы y-sort работал >>949257
Я делал игру с под 400 y-sortнутых и вручную нарезанных спрайтов на видимый экран, плюс шейдеры-партикли и прочее. Не испытывал особых проблем производительности. Еще и на мобилки ее выкатил, представляешь.
>если не понимаешь, о чём речь.
Ну расскажи нам, о великий сенсей, как делать нормальные игры с помощью 2д спрайтов. Пока ты тут только воняешь.
> иначе бы никто не ебался и не резал пикчу на сотни частей.
Чел, сейчас не 90-е.
Уже побежал деанониться ради какой-то чмони на аиб, которая даже аргументы привести не в состоянии, только апеллирует к своему, якобы, знанию, которое старательно скрывает.
В годоте не сильно шарю, перекатился с юньки, но это по логике никак не должно напрягать.
На экране отрисовывается фиксированное кол-во текстуры, остальное в памяти сидит ничего не нагружает и потребляет от силы пару мегабайт.
Теоретически если делать картинки 100000х100000 не разрезая тогда могут быть проблемы.
У меня сцены с десятками миллионов полигонов держали спокойно 150+ фпс.
О, мою шебемку закрепили, тогда вот новая.
Сейчас раскидываю торговцев по карте, и буду парится с диалоговыми окнами. Затем всякие мелкие активности для первой локи сделаю
а, ну тогда беру свои слова назад. Так годот тебе возможно даже понравиться, хотя рофлянки кидать один хуй будет
Ты тут утверждаешь что ничего не работает, все не так, и производительность должна падать. При этом не то что пруфов, а аргументов не приводишь. Интересно, как же тогда другие игры реализуют подобное? Магией? Заметь, ты даже предположений не строишь. И о чем с тобой разговаривать? Ты пустой просто.
Если отвечать на вопрос, то встроенного механизма, наверное, нет
Задача сводится к назрезанию картинки автоматически (например tool script) и стримингом. И то и другое пишется довольно просто или берется аддон (zone loading, какой нибудь sprite cropper) либо картинка нарезается imagemagic, кускам даются названия по соответствующему тайлу x, y. В общем все автоматизируется или делается в полуавтоматическом режиме.
Вот и сгрыни обратно в свой загон блевик, сиди там дальше про пропуки рассказывай.
Есть плеерконтроллер
func interacted_objects_input_event(viewport, event, shape_idx, interationObjects):
if Input.is_action_just_pressed("left_click") and (player.current_state == "Idle" or player.current_state == "Move"):
player.is_going_to_interact = true
player.interactible_object = interationObjects.get_child(shape_idx)
player.click_position = player.get_global_mouse_position()
get_tree().call_group("Player","change_to","Move")
func _input(event):
if Input.is_action_just_pressed("left_click") and (player.current_state == "Idle" or player.current_state == "Move"):
player.is_going_to_interact = false
player.click_position = player.get_global_mouse_position()
get_tree().call_group("Player","change_to","Move")
if Input.is_action_just_pressed("left_click") and (player.current_state == "Dialogue"):
dialogue_manager.get_next_line()
_input для всего подряд, interacted_objects_input_event для клика по активному объекту, сейчас при интеракте срабатывает диалог
проблема в том, что при клике по активному объекуту при нахождении в диалогое срабатывают оба инпута, первый заканчивает диалог, диалогменеджер переводит персонажа в Idle, а второй уже думает что персонаж снова хочет взаимодействовать, то есть диалог прекращается и сразу начинается новый
какой бестпрактис это починить?
Да-да, я тебя услышал, ты зашел потролить своей тупостью. Пиздуй.
Документация вроде как говорит, что два инпута не могут одновременно обрабатываться, но может дело в том, что _input в контроллере, а _on_input_event, который вызывает interacted_objects_input_event в ноде с активными объектами
>два инпута не могут одновременно обрабатываться
всмысле один импут два раза
Имхо, бестпраксис это не смешивать два подхода, пока это возможно. Ты или используешь ооп input_event(viewport, shape_idx), или возню с get_global_mouse_position() и action_pressed("left_click").
Намоделил пару стульев на примере своих кухонных, между раундами затраха с рутмоушеном. Еще сотня моделей впереди.
А персонажа сам моделил? Попка сочная, но глаза надо исправлять!
Ну вот я сделал два коллижена - коллижен локации и коллижен объекта, но они пересекаются же и все равно по клику по объекту два _on_input_event происходит.
Та нет, взял со скетчфаба, но уже думаю следовало брать лоу-польную, больно уж долго ждать ре-импорта при малейших изменениях.
> трахался с рутмоушеном, но персонаж все равно скользит
Ты что-то делаешь неправильно. Либо из контроллера не вырезаны фрагменты обычного моушена и добавляются к рутмоушену. Либо неправильно настроены масштабы. Абстрактные юниты расстояния в анимации должны быть пиксель в пиксель равны абстрактным юнитам расстояния в движке.
Проверь а от какой кости рутмоушн считается. Там были какие то нюансы, от таза или еще откуда.
Бля, точно!
>>949325
Анон, анимации с миксамо отсчитываются от бедра, а годот считает от стоп, если я правильно понял. Там есть какой-то плагин к блендеру, который ретаргетит рут. Я видел это в каком-то из уроков по рутмоушенд для годота. Щас поищу.
>Плюс какое-то непонятное дергание в моменте когда последний кадр анимации должен переходить в первый кадр в цикле.
Разобрался, проблема старая
https://github.com/godotengine/godot/issues/65513
В текущей версии завезли алочку "Trim" в разделе импорта анимаций, теперь гладко. Не идеально, но приемлемо.
>>949352
>Ты что-то делаешь неправильно.
>>949354
> Там были какие то нюансы, от таза или еще откуда.
Я беру анимации с Mixamo, но он не генерит root-кость для рутмоушена. Корневую кость генерирую аддоном для блендера godot mixamo converter, но этот аддон берет движение от кости таза, что приводит к излишним движениям. Видимо все таки видимо процесс не автоматизировать и придется ограничивать движение корня в каждой анимации дополнительно вручную.
> аддоном для блендера godot mixamo converter, но этот аддон берет движение от кости таза
О том и речь, там аддон надо правильно настроить, наверное.
Вот тут я смотрел
https://www.youtube.com/watch?v=EmQBLxxPV3E
Нихуя не приемлемо. Тебе надо рут выставить от грунта, от стопы ноги. Сам подумай. Это сродни инверсной кинематике. Тебе надо рутмоушеном полностью смоделировать зацепление с грунтом. Для этого рут-кость должна быть на нулевом расстоянии от грунта, а при боковых анимациях еще и в точке пересечения между грунтом и радиусом поворота.
Какая-то фигня. Инициализировал персонажа, нажал создание корневой кости, он мне ее в метре от персонажа над полом воткнул.
>>949361
>Нихуя не приемлемо.
Речь была про дергание из-за кривой склейки конца и начала в зацикленной анимации. А рутмоушен придется фиксить.
Персонажи за минуты. Без ебли. Без скилла. Бесплатно! Без СМС. Но скорее всего с регистрацией.
Cascadeur еще глянь, Майк на своем канале тоже его показывал.
Двачую каскадер. Он недавно стал платным, но если был установлен бесплатный, там дарят ключик на два года.
Миксамо конечно хорошо, но со временем понимаешь что там особо постпроцессинга не делали. Так что первый кадр РАЗНЫХ мувсетов вовсе не обязан совпадать.
Миксамо какой-то заброшенный. Адоб его купил и забил нахуй.
>>949381
>Он недавно стал платным
Это значит что его крякнут и он снова станет бесплатным. И если проверить рутрекер, то так и есть.
Да-да, а потом, когда ты заработаешь свой первый миллион на стиме, тебя вызовут в суд и отожмут всё заработанное, ещё и должен останешься.
> кок-пок, нидакажут!
Да конечно, не докажут. Этот софт генерирует анимации, прогоняя твой ключевые фреймы через физический движок. Кто знает, что ещё там стеганографией запрятано?
> кудах-тах, да ты хотя бы рубль заработай, о миллионе он говорит
Да, с мыслью о зарабатывании рубля рубль и заработаешь. Вот так мотивация и работает.
>>949409
Будем честны, 98% не то что рубль не заработают, но и игру не релизнут. Тем более в стиме. Тем более с санкциями.
Все трясутся и ты трясись. Там уже ии-сгенерированные игры проскакивали: https://www.youtube.com/watch?v=-ZSVkjukC1U
Сейчас буду простыню советов накатывать.
Второе, всегда муть игру при анфокусе и показе любой рекламы. Тут я столкнулся скорее не с тем что не мутил, а с проблемой годо из за которой после показа рекламы при анфокусе один хуй звук продолжал играть, либо не продолжал даже при фокусе. Советую скомбинировать годо фокус с жс коллбеком фокуса ибо в веб окно в фокусе считается когда его видно на экране в любом виде.
Треть чисто от себя, не забывай консумировать покупки, да это очевидно, но порой тупо забываешь что то сделать ибо пунктов в требованиях ебанись сколько.
Четвертое, показ рекламы. Пункт хуйня конечно, да похуй. После поражения у меня открывалось окно со счетом, блочились кнопки визуально было видно и потом через пару секунд показывалась реклама, модеру это не понравилось, хотя делал как говорилось в требованиях, так что имей ввиду.
Да и все наверное. Это все доебы которые были ко мне, только были они в разных моментах. Чет хуйни насрал бесполезной, думал пополезней будет.
Ну и технические советы:
Так как яндекс не поддерживает многопоток звук нужно обрабатывать не в движке а во внешней жс либе, иначе на слабом железе будет пердеж и треск.
Опять же, про фокус и анфокус. Не хочешь ебли, скомбинируй годо и веб фокус.
Юзай минимум сигналов, и только при жесткой необходимости. Я с этим говна нажрался поначалу.
Чтоб оффнуть скроллбары окна, если такой же тупой как и я, открой index.html через блокнот и в самом верху документа в body{} вставь эту строку "overflow: hidden;". Спасибо анону из прошлого треда за этот совет.
В целом, документация яндекса полная хуйня и шляпа, пункты описывают только общую картину, поэтому ты считай по минному полю идешь на ощупь, а узнаешь о том что наступил на мину от чмодера.
Ну вот например будут ИИ, которые просто выплевывают готовые экзешники по промпту, а будут такие, которые сгенерируют тебе проект для движка, в котором ты сам сможешь что-то исправить ручками под свои хотелки. Во втором случае тебе все еще понадобятся навыки разработчика/геймдизайнера.
Да не трясись. ИИ это кал, не более чем продвинутый гугл. Пока все паникуют, просто учись с помощью него и повышай свой скилл как программиста\художника\разработчика\дисигнера.
Наоборот короче вкидывай как всё это даванет всех, пускай зумеры идут учиться на кого угодно, но не в айтишечку. Только вот ДНО работы ИИ точно даванет, но не профессии богемы.
Какие деньги, сегодня утром только одобрили. Стату через неделю минимум кину, а с большей вероятностью через две.
А там не показывают чтоле сразу сколько игра заработала? Там ведь буквально аналог адсенса. Возможно тогда яндекс объябывает и без того нищих разработчиков на рубли.
>богемы
Проорал с тебя, богема ебаная. За ИИ будущее во всём, запомни.
Окей, разобрался, нужно было использовать get_root_motion_rotation_accumulator, иначе вращение ноды не учитывается. Я так до конца и не понял, зачем мне перемножать обратный от этого кватернион на кватернион моего CharacterBody. Потом разберусь, пока работает достаточно хорошо, блендить анимации более качественно буду на модельке ГГ, сейчас Годетта просто для тестов.
Можно начинать накидывать пустые коридоры и комнаты с простыми текстурами (а-ля пол в прикриле). Между делом буду кодить взаимодействие с предметами.
Если есть аннон с нейронкой, нагенерь портреты годетты - нормальный, уставший и ахегао. Для отражения запаса ХЗ в интерфейсе как было на демке с пепегой.
ИИ ничего кроме как извинятся бесконечно не умеет. Просто возможно ты слабый, раз решения от ИИ воспринимаешь как что-то невероятное.
Зачастую ИИ не может решить банальные задачи с уровнями папок.
Показывает, только я к тому что откуда игроки будут если игра 3 часа как релизнута и находится в очке списка "новое", тут ждать надо, пока что только 1 чел поиграл и с него я получил пикрил.
Ну норм, прикинь, у тебя не было этой половины копейки, а теперь появилась. Заебись же.
Маладца, поздравляю.
>>949490
Про локализацию дам совет из вебдева. Там тоже влом локализировать, поэтому удобно взять эмоджи-пак или шрифт и использовать их вместо текста. Например домашняя страничка - домик. Всякие звездочки, денежки, стрелочки, ноты, деревья. Все это без перевода.
https://icons.getbootstrap.com - эти можно по-отдельности в свг-формате скачивать. В третьей игре так делаю.
я выключил стики у умирающей четыре месяца игры, пусть мимокроки только за запуск и проигрыш получали в лицо фуллскрин рекламу
мимокрок, пишет в чате по годоту, не работая в годоте
1000iq
вытиран с гамаком, юнити и обоими фазерами за плечами
Приём, запрашиваю взаимопомощь!
Есть скрипт, прикреплённый к Node2D в _ready которого я задаю self.rotation_degrees и self.scale например. Таких нод у меня несколько, и мне надо задать им рандомные значения размера и поворота. Я подумал, что хорошей затеей будет создать не привязанный ни к чему скрипт, который будет мне эти рандомные значения возвращать. Я объявил его
var myscript = ("res:/hui/riddler.gd")
Годот видит скрипт, видит функцию в нем, а пользоваться не дает, говорит
Parser Error: Cannot call non-static function "riddler()" on the class "res://hui/riddler.gd" directly. Make an instance instead.
Ошибка не гуглится, и я так понимаю, что моя затея не работает на уровне концепта, а с ангельским у меня, помогите пзязь :С
тебе нужен инстанс на сцене (пустой нод2д например) с этим привязанным скриптом
иначе ты пытаешься поюзать нестатический метод, а это харам
я если что вот этот анон >>949624, только приступаю к изучению
Я бы сделал ноду-компонент, которая ротирует своего родителя по реди.
- ParentNode
-- Rotator
И крепил бы ее ко всем, кого надо проворачивать.
У меня там и так 3 ноды вложены друг в друга для каждого такого элемента, я пытаюсь сохранить рассудок порядок какой-никакой и скрипты хоть немного сократить. А логика с ротатором у меня плюс-минус такая и реализована.
>>949631 >>949634
Т.е. проблема именно в том, что этот скрипт у меня не привязан никуда и так нельзя делать просто потому что?
>Я объявил его
>var myscript = ("res:/hui/riddler.gd")
Хуйню сделал.
Если уж тебе так хочется сделать ни к чему не прикреплённый скрипт-библиотеку, то тут два варианта:
а) extends Node и объявить его как синглтон;
б) extends Object, прописать ему class_name, а все функции, которые планируешь вызывать извне, сделать static. Обращаться к нему, соответственно, по класснейму.
Короче синглтоном сделал. Тебе и всем небезразличным - спасибо за помощь.
А вообще это нормальная практика - иметь на сцене пустую ноду, чтобы в нее складывать скрипты для однотипных элементов?
Да. Не все ноды обязаны что-то делать/считать, для организации они тоже хороши. Например посмотри на === ЭТО ===
Отсюда: https://www.reddit.com/r/godot/comments/1clw6jt/concept_for_dark_souls_3_as_a_top_down_rpg/
Глобальные сигналы без шины (под капотом шина есть, и это сам майнлуп).
В комплекте поставки есть две ноды: источник и приёмник.
Ты раскидываешь источники где надо, переименовываешь их как удобно, и эти имена становятся именами сигналов, которые регистрируются под капотом.
Приёмникам назначаешь в инспекторе имя сигнала который он будет ловить. Это единственный минус - стринг в инспекторе.
Коннектишь встроенный прокси-сигнал приёмника. На источнике вызываешь встроенную прокси-функцию эмит.
Ну и всё.
Надо учить программирование, а не как только чужие ассеты пиздить
https://en.wikipedia.org/wiki/Publish–subscribe_pattern
https://hasithas.medium.com/introduction-to-message-brokers-c4177d2a9fe3
Лол, да, масштабы типичного хруща не располагают к такой камере.
> видимо, площадь слишком маленькая
Ничего не маленькая. Я как посмотрел видос, так прям сразу вайбы резидента. Там тоже в особняках много узких коридоров, в которых не развернёшься. С одной стороны, всё заебись. Делай в масштабе. С другой стороны, не стоит забывать, что если ты собрался пилить резидент-лайк, тебе необязательно возводить хрущи по ГОСТу, резидент - это про нереалистичные запутанные извилистые коридоры в загадочной резиденции злобного гения. Запутанность там не для архитектурной целесообразности, а для расстановки головоломок, ловушек и схронов.
И ещё вопрос по камере. Как у тебя она реализована? А то вижу некоторую дёрганность при переключениях видов. Есть несколько соображений по этому вопросу, но сначала надо знать как именно у тебя щас, чтобы не советовать то, что у тебя уже есть.
Как бы делал я:
1. Камера одна в корне дерева.
2. У камеры есть таргеты, Т1 к которому она следует и Т2 на который смотрит.
3. Камера принимает сигнал смены Т1 и время, за которое должна переместиться к новому Т1 (не сводя взгляда с Т2).
4. На сцене есть Т1-точки, есть area3d - зоны отслеживающие перса. Если перс вошёл - эмит смены таргета на привязанный к зоне. На выход чекается свой счётчик у перса (об этом далее).
5. Так же в некоторых сценах могут быть салазки на основе Path3D по которым таргет Т1 камеры может ездить за персом.
6. Перс всегда Т2 (ну кроме катсцен пожалуй). У перса есть свой таргет Т1 за спиной, перс входя в ту или иную зону увеличивает счётчик зон, выходя уменьшает (как в примере с лестницами ранее в треде). Если счётчик обнулился, перс сам эмитит сигнал смены таргета на свой Т1.
7. Ну и разумеется, если есть глубокие смертельные ямы, то у них на входе тоже расставляются зоны, хватающие камеру и посылающие персу гейм-овер.
Как-то так.
А ещё можно вещать камеру на босса и заставлять игрока сражаться с боссом от лица босса же. В резиках я такого не упомню, но в олдовых экшонах на дендях-сегах такое встречалось.
>придется делать комнаты нереалистично раза в полторы больше
Добро пожаловать в основы геймдизайна
>>949886
https://sketchfab.com/3d-models/godette-chan-5e5dd8978e21431f992dee953c11558d
Вот и моделька на скетчфабе есть.
>Как у тебя она реализована?
Примерно как у тебя описано.
1. Каждая комната - Area3D со своей камерой.
2. Area3D регистрирует столкновение с игроком и делает свою камеру активной.
3. Камера нацеливается на игрока (функция LookAt) с задержкой, чтобы движение камеры было плавным.
4. Камера следует за игроком в пределах CollisionShape3D родительского Area3D, сохраняя максимально возможную дистанцию (в случае квартиры, макс. дистанция следования установлена в 100, поэтому камера стоит на месте, в случае улицы, макс. дистанция установлена в 3, поэтому она следует за игроком, пока не достигнет границ CollisionShape3D).
5. Камера прикреплена к потолку CollisionShape3D родительского Area3D.
Каждая такая Area3D имеет свою собственную камеру, это позволяет настраивать каждую камеру отдельно. В моем случае FOV наружней камеры - 37, FOV камер квартиры - 60.
Данную Area3D я обозвал CameraRoomConstraint, описанная тобой рельса тоже понадобится, но буду реализовывать по мере необходимости.
>вижу некоторую дёрганность при переключениях видов.
Это из-за плавного следования за игроком, камера тратит немного времени чтобы нацелится на Годетту при переходе в новую комнату. Сейчас поменял так, чтобы нацеливание камеры в момент перехода в новую комнату было мгновенным.
> С одной стороны, всё заебись.
Базовый референсом был SH1-4. Сейчас посмотрел отрывок с помещением которое мне помнится чрезвычайно маленьким, но оно на самом деле довольно большое (в сравнении с моим)
https://youtu.be/1DS9KI7FUPo?t=1026
Но сейчас подумал, что сейф зоны можно и нужно сделать маленькими, иначе игрок затрахается ковырятся в ящиках у себя на квартире.
>>949886
>>949889
>>949890
Согласен поменять только на Slut-Godette в стиле Shadman.
>шортстак
Там формы анимировать нужно или хотя бы регдоллом для сисек/жопы заморачиваться. Кому не впадлу, сделает.
>>949790
> боссом от лица босса же
Вообще, интересная задумка. Может даже дать в процессе игры намеки, на то что ГГ-галлюцинирующий злодей.
> Согласен поменять только на Slut-Godette в стиле Shadman.
Хуясе! Наш слоняра! Одобряю!
> Сейчас поменял так, чтобы нацеливание камеры в момент перехода в новую комнату было мгновенным.
Если уж оставлять вариант с переключениями камер, то надо перед переключением новую камеру нацелить на игрока. Тогда не должно трясти.
>Тогда не должно трясти.
Не вижу тряски.
Но переход из комнаты в комнату будет точно переключением.
>>949325
>>949513
>>949763
>>949906
Охуенно, анончик, люблю сайлент хилл и резик
Сам хочу когда-нибудь сделать сайлент хилл
> Не вижу тряски.
Нет, конечно, нет. Там на видосе не тряска, а как бы это выразиться, подворот. Одна камера направлена на север, вторая на запад, при переключении камере нужно несколько кадров, чтобы повернуться на север, и это заметно.
Если бы камера была одна, а переключались бы только гнёзда, к которым она липнет, то она бы более плавно двигалась, ящитаю. Алсо FOV и любые другие параметры у камеры тоже можно менять на лету, в том числе анимировать. Как-то видел как тот же FOV подстраивают при ускорении. Знаменитый эффект.
Интерактивный предмет предоставляет арею, а перс игрока предоставляет рейкаст в точку куда смотрит игрок. Если рейкаст ловит предмет в зоне предмета, только в этом случае появляется приглашение нажать кнопку Е.
Ах, в двадэ.
В двадэ ареи у предметов, а ярлычок с буквой Е на персе игрока. Рейкаст уже не нужен (в зависимости от гемплея конечно, может и потребуется).
Перс входит в зону - приглашение появляется. Выходит - исчезает.
>>949763
Попробуй заценить данный плагин. Говорят, что годнота. Тебе, возможно, с ним проще будет.
https://phantom-camera.dev/
Area2D может зарегистрировать только выход или вход. Один раз.
А тебе надо что бы оно проверяло находится ли объект сейчас в зоне, или нет.
Сделай переменную меняющуюся при выходе и входе
Как человек не игравший в сайленты никакие, у меня вопрос, там камера так же поуебщиному просто телепортируется? Без затемнения, без плавного перемещения? У меня от такого голова кружится
> Как ето понимать?
Как движок для состоятельных парней. Элитный движок.
Если с затемнением переключать - получится смута. Но мне не выдавали денег из кубышки, чтобы я смуту делал!
Если делать с пролётом, то у зумеров голова кружится.
Тупик. Патовая ситуация.
От затемнения раз в пять секунд у игрочка все мозги вытекут на десятой минуте. Во всех японских играх времен PS1-2 так. Сайлент, резик, динокризис, ДМЦ.
И не только в японских. Принц Персии, как пример, там тоже. Хотя реже, чем у японцев. Старый юбисофт мог умеренно применять перемещение камеры. Места где камера лочилась в углу было 3,5 за всю игру.
>ез затемнения, без плавного перемещения?
Слишком медленно. Если там противник - он тебя уже захуярит, пока ты там плавно затеняешь/перемещаешь камеру.
Дело сложное! Думоем! Как бы нам сделать-то так, пакрасате?
У меня так.
Объект - ареа. Персонаж шлёт сигнал. Зашёл в арею - приконнектился; вышел из неё - дисконнектнулся. Есть мгновенно срабатывающие, которые вместо коннекта просто активируются при заходе. Ярлычок рисуют сами интерактивные объекты.
а чаму перекотился?
чемь юнька не понравилась?
>Дело сложное! Думоем! Как бы нам сделать-то так, пакрасате?
А что если просто повесить камеру за спину? Как в первом СХ.
Как в любой нормальной игре, ты хотел сказать. Эти камеры из-за угла и тогда, в дремучие года, были неиграбельным сблевом, а сейчас за это палками надо пиздить.
Afaik, она там не заспинная, она как у меня здесь >>949513
То бишь имеет границы и дистанцию, на которой начинается следование за персонажам, что на больших площадях помещает ее заспину.
Надо делать камеру как у гениального маэстро Миядзаки в солсах. Чтоб камера во время боссфайта застревала у босса под крылом, или в колоннах-стенах-камнях, чтоб игрок ничего не видел и огребал, бешенно матерясь. Вот это хардкор! Да что вы понимаете в настоящем хардкоре!
> Пояснишь за сигналы?
Что конкретно за сигналы пояснить?
>>949995
>>950020
>>950057
Спасибо, анончики! А где можно почитать про организацию этой связи между игроком и объектом? Если логику объекта я написать смогу, то как работает этот "коннект" я недопетриваю.
да просто сделай переменную, которая тру когда ты вошел и фолз когда вышел
если ты за оптимизацией, то сделай инт который равен 1 когда вошел и ноль когда вышел, когда входишь в другую ззону он будет равен 2 например
> как работает этот "коннект" я недопетриваю
Это называется. Подписка на событие.
Смотри. Вот ты подписался на тред. И в углу у тебя панелька, которая показывает 3 непрочитанных постов. Увидев эту надпись ты открываешь тред и читаешь эти новые посты.
Здесь всё ясно?
Так же и с сигналами. Есть нода1, в которой объявлен сигнал. Есть нода2, которая видит ноду2 (знает о её существовании). Нода1 подписывается на сигнал, то есть коннектит к сигналу некоторый код, который будет исполняться при испускании сигнала (окошко с непрочитанными постами). Нода2, когда у неё происходят вычисления, о которых она должна просигналить (новые посты), испускает сигнал. При этом ей неважно, получил-ли кто-либо тот сигнал, сделала emit() и дальше пошла.
> Так же и с сигналами. Есть нода1, в которой объявлен сигнал. Есть нода2, которая видит ноду1 (знает о её существовании). Нода2 подписывается на сигнал, то есть коннектит к сигналу некоторый код, который будет исполняться при испускании сигнала (окошко с непрочитанными постами). Нода1, когда у неё происходят вычисления, о которых она должна просигналить (новые посты), испускает сигнал. При этом ей неважно, получил-ли кто-либо тот сигнал, сделала emit() и дальше пошла.
Объяснятель, блять. Извините. Бистрофикс.
Ну так, что если симулировать такую камеру, чтобы она, с одной стороны, была достаточно "тяжелой" и инертной, а, с другой, была именно заспинная/заплечная, не фиксированная.
Тяжесть камеры зависит от геймплея. Если там ураганный экшон, то ни о какой инертности говорить не приходится.
>Если логику объекта я написать смогу, то как работает этот "коннект" я недопетриваю.
Да там всё просто.
1. В скрипте персонажа где-нибудь в шапке объявляешь сигнал:
signal activate_areas(sender)
Можно без аргументов, просто полезно будет знать, кто активирует нашу арею, чисто расширяемости для.
2. Там, где обрабатываешь инпуты, вызываешь сигнал:
activate_areas.emit(self)
Всё, перс будет слать этот сигнал, вне зависимости, подписан ли на него кто-либо.
3. Теперь в арее (лучше это делать в её собственной сцене) присоединяешь из редактора даблкликом сигнал body_entered к её же скрипту, функция создастся автоматически:
func _on_body_entered(body):
if body.has_signal("activate_areas"):
body.activate_areas.connect(activate_me)
3+. То же самое с body_exited, присоединяешь из редактора даблкликом:
func _on_body_exited(body):
if body.has_signal("activate_areas"):
body.activate_areas.disconnect(activate_me)
4. Ну и тут же в арее описываешь ответную функцию, к которой собсно будешь присоединять:
func activate_me(sender):
print(sender, " activated me!")
Как только принт принтит когда надо и что надо, это успех, можно переходить к описанию того, что данная арея вообще делает.
В принципе, можно было бы сделать так, чтобы персонаж запоминал в массив все ареи, в которые зашёл, а потом по команде циклом вызывал бы в каждой из них нужную функцию. Никто тебя не наругает, если ты сделаешь так. Но сигналами - чище, красивее и универсальнее.
Я не согласен. Здесь кастомный сигнал не нужен.
> if body.has_signal("activate_areas"):
> body.activate_areas.connect(activate_me)
У тебя уже есть body. Ты уже о нём знаешь. Зачем ты сам перед собой притворяешься, что ты о нём не знаешь? Приведи body к известному тебе типу и вызови известный тебе метод:
> if body is MyPlayer: #в четверке после такого ифа срабатывает тайпкаст и включаются подсказки
> body.add_to_interaction_callback_pool(activate_me)
...
> body.remove_from_interaction_callback_pool(activate_me)
А в плеере, соответственно, при жмяке на кнопку интеракции
> for callable in interaction_callback_pool: callable.call()
Разве нет? Разве так не удобнее?
Только вот в обоих случаях все интерактивные сундуки откроются разом. Хоть кастомсигналом, хоть пулом колбэков. А если они все меню открывают?
В случае с пулом я могу не вызывать все циклом, а посмотреть, сколько элементов в пуле? Вызвать крайний, например. Сигнал тупо вызовет все разом без возможности контроля.
Ну и в общем-то, почти как ты ниже написал
> В принципе, можно было бы сделать так, чтобы персонаж запоминал в массив все ареи, в которые зашёл, а потом по команде циклом вызывал бы в каждой из них нужную функцию.
Чище, красивее и универсальнее, когда интерактивные объекты сами добавляют себя в пул персонажу, сами себя удаляют. А игрок, когда жмёт кнопку, у персонажа происходят тайпкасты: для подтипа "мгновенное действие без меню" - выполнить метод "activate_me" разом у всех в цикле. Для элементов "действие с меню" вызвать activate_me у последнего из добавленных, или у первого из добавленных. В зависимости от правил игры. Вызывать меню по очереди, или отбросить все остальные. Вывести меню выбора на экран из пересекающихся интерактивных объектов. Твой кастомный сигнал ничего из этого обеспечить не сможет.
Можно пример гипотетический, где тебя сигналы говном кормили (или не гипотетический, я в треде совсем новый, мб для всех кроме меня очевидно, что за продукт ты делал)?
Меня сигналы говном не кормили.
Я знаю, где их использовать, например ГУЙ: он висит в отдельном слое, в отдельной ветке дерева сцены, ничего не знает о происходящем в игре, а просто обрабатывает сигналы типа изменить_хитпоинты_на(10) или типа показать_меню(инвентарь)
И я знаю, где их не использовать, например, пуля: Она врезалась в коллизию. У неё есть информация об объекте коллизии. Нет смысла посылать сигнал в сферический вакуум о том что "пуля_нанесла_урон(пуля, тело). Достаточно прямо сообщить этому объекту "я наношу тебе баллистический урон на 10 хитпоинтов" и удалиться. Если коллизией была стена, она обработает сообщение одним образом, если живность, то обработает другим образом.
> что за продукт ты делал
О, тут можешь не переживать, я безыгорник диванный.
>Приведи body к известному тебе типу и вызови известный тебе метод
Категорически нет. Потому что duck typing.
Со всем остальным согласен, ты всё по делу написал. Вот только анон, который изначально вопрос спрашивал, ему будет полезно освоить сигналы, научиться их применять. И самое главное - вот те проблемы, которые ты описал, будет хорошо, если он сам на них наткнётся и научится решать.
Ну и примеры у тебя, в первом СХ камера переключалась на фиксированную в самый неподходящий момент.
> Категорически нет. Потому что duck typing.
Вот здесь поподробнее. Что ты имеешь ввиду?
(Про утиную типизацию объяснять не надо. Надо объяснить почему она категорически нет в данном примере).
Анонче объясни, а зачем ты гет и сет поставил? Я у ютуберов видел, но чет не выкупил нахуй оно надо...
Я и сам не до конца понимаю, по идее в этом конкретном случае разницы большой нет, но это более хорошая практика
Компилятор шарпа автоматически генерирует полный вид. Таким образом ты вроде как для себе просто переменную объявил, а по факту у тебя свойство, которому ты в дальнейшем можешь права навесить.
погоди ка, я типо объявляю ее как переменную, и могу спокойно творить с ней че вздумается???
щас проверю
> поясните пожалуйста
Предполагаю, что сетскрипт дропает предыдущий объект и назначает новый. Чтобы проверить это предположение, поменяй местами строчки 33 и 34. Если заработает - значит так оно и есть.
А чё тебе может вздуматься-то с таким низким уровнем знаний по шарпу?
Напиши
> public Camera2D Camera { get; private set; }
И посмотри на реакцию.
Или вот ещё вариант, напиши
> Camera2D Camera => wordView.GetNode<Camera2D>("Camera");
Тоже ошибка с доступом к диспозанному объекту, но уже на попытке добавить дитя. Наверно ты прав и сетскрипт пересоздаёт объект.
Никогда в жизни не видел чтобы так делали. Зачем, если ты можешь просто спавнить сцену, в которой уже есть камера со скриптом?
Я не уверен, что здесь нужно применять сетскрипт. Я настаиваю на том, что именно он тебе всё ломает. У тебя в Camera.cs есть имя класса. В 26 строке напиши Camera = new MyCameraCS(); Затем закомменти 34ю строчку. Проверь.
я другой анон
я просто не выкупил про гетеры и сетеры и хуй забил.
В МСДН на самом деле очень грамотно всё объяснено. Рекомендую причаститься.
https://learn.microsoft.com/ru-ru/dotnet/csharp/programming-guide/classes-and-structs/using-properties
Мне показалось, что проще создавать всю сцену из кода, уже не помню почему я так решил.
>>950247
Блин, спасибо! Как я сам не сообразил, что раз у меня классы наследуются от базовых типов, то я могу не назначать скрипты, а просто создавать сходу нужные мне объекты!
Ты проверяешь, утка ли это. А надо проверить только умеет ли она крякать. Ну то есть, опять же, ничего криминального, но для гдскрипта это плохая практика. Потому что, как только ты захочешь сделать манок для уток, уткооборотня и гадкого утёнка, тебе придётся в куче мест разгребать ошибки и уточнения из-за
if node is Duck:
а всё было бы проще, если бы там изначально было
if node.has_method("quack")
Ну то есть, конечно, вряд ли конкретно тот анон захочет делать когда-нибудь, чтобы интерацию выполнял не только игрок, но и враг, и фантомная копия игрока, и мимик, и взрыв, и небо, и аллах. Но это хороший, более правильный паттерн для гдскрипта, чем приведение к фиксированному типу, когда от целого типа нам нужно всего одно его поле.
Да. Теперь понял. Но всё равно люто коробит от строковых литералов посреди кода, когда есть няшные тайпкасты с поддержкой интелисенца. Надеюсь в будущем от этого избавятся, чтобы можно было
> if node.quack is Callable: node.quack()
спасибо, намного лучше объяснено чем где либо, чет все равно не выкупаю нахера их ставят так как анон выше. Может ты знаешь?
Об этом я с самого начала написал. Перефразирую: их ставят, чтобы сразу стояло свойство, на будущее, на потом, для красоты кода и т.п. А компилятор шарпа автоматически преобразует эту запись в полную запись, где есть переменная и она подставляется в гет и в сет. Не знаю, какое у тебя ИДЕ, но у меня в мс-коде ,например, можно нажать на лампочку и самостоятельно преобразовать такую сокращенную запись свойства в полную:
> Camera2D _camera;
> public Camera2D Camera { get { return _camera; } set { if (_camera != value) _camera = value; } }
ааа, пон спс броу. Я блять наконец то понял что они делают.
Только производительность поиска метода скорее всего ниже, чем проверка типа, особенно типизированная, а не по названию.
Свойства нужны чтобы вызовы функций выглядели как переменные. Или, по другому, чтобы при присваивании переменной можно было накинуть доп. код обработки.
Ящитаю, надо от игрока как-то скрыть момент исчезновения предметов со сцены. Ну и над менюшкой поработать. Выглядит перегружено, курсор скачет во все стороны, иконка перса зачем-то выбирается. В СХ такая штоле была? Не стоит копировать 1в1. Стоит переделать поудобнее.
Ну а в целом малаца, канешн.
Показалось, или на первых кадрах от персонажа тень на пол не попала?
> В СХ такая штоле была? Не стоит копировать 1в1
Да, буквально копия. Со временем как-нибудь освежу образ, а каркас пущай и так будет.
Ну а если ничего своего не придумаю, просто реворкну СХ1.
>>950280
Просто загораживает собой.
Какова причина использования устаревшего геймдизайна меню?
Такая же, как использование устаревших камер по углам. Утизм.
Синдром утенка. Воплощаю фантазии дитеских лет на взрослую голову.
>>950288
Кстати тоже сейчас этим занимаюсь. Детская ностальгия она такая. Но стараюсь адаптировать под современные реалии.
> адаптировать под современные реалии
Minesweeper наоборот с толщетопологией.
>>949247 (OP)
У кого-нибудь есть фул рисунка Годетты из основного поста? Думаю использовать ее вместо классического СХ1 индикатора здоровья - в интерфейсе это будет кусок бумаги с карандашным портретом, с тем большим количеством пятен, дыр и жженных следов, чем меньше хп у ГГ.
Это и есть фулл. Я брал его отсюда: https://www.reddit.com/r/godot/comments/rvdvf6/another_godette_fan_art_i_made_free_for_any/
Автор разрешает использовать для любых целей.
>Автор разрешает использовать для любых целей.
Балдеж. Пасиба, анон.
Если ты выполняешь эту проверку так часто, что страдает производительность, то ты определённо делаешь что-то не так.
>>950265
>Надеюсь в будущем от этого избавятся
Это невозможно на уровне концепции. Максимум - как в луа, чтобы конструкция node.quack не вываливалась с ошибкой, если у node отсутствует поле quack, и тогда можно было бы делать
if node.quack and node.quack is Callable
Но это просто синтаксический сахар для той же самой строковой проверки. И с этим сахаром таковая проверка будет вызываться вообще всегда, а не только в явных местах, что как раз сильно замедляет весь язык.
С другой стороны, у луа есть JIT, а у гдскрипта нету, и кто из них медленнее - тот ещё вопрос.
И вообще. Гдскрипт - интерпретируемый язык с динамической типизацией. Его сильное место - быстрота разработки. И как раз утиная типизация - один из важнейших срезов, доступный исключительно благодаря этой самой динамичности.
С другой стороны, производительность - слабое место языка, ровно по той же причине.
Возможность статической типизации - это лапки ежа, пришитые к гдскриптовому ужу с целью ускорить не столько производительность, сколько разработку. Больше ошибок будет поймано на этапе спеллчека, меньше времени будет потрачено на их отлов в рантайме. Но это всё не должно идти в ущерб главному преимуществу, которое гдскрипт несёт в себе, то есть скорости разработки.
Ну а если кто-то хочет прямо упороться в производительность, тому уже улыбается Бьёрн Страуструп. В плюсах и типизация строгая, и скорострельность такая, что гдскрипту и не снилась. И каких-нибудь юнитов для РТС лично я на гдскрипте даже не пытался бы писать. Но если на уровне максимум одновременно игрок, пять врагов и десять пуль, то какой смысл пришивать к ужу ещё одну лапу?
Сорян, чёта меня понесло на философию. Половина седьмого утра, а я ещё не ложился.
>>950283
>видрил
Ъуъ сюка аж Ямаока в голове заиграл.
> Это невозможно на уровне концепции. Максимум - как в луа, чтобы конструкция node.quack не вываливалась с ошибкой, если у node отсутствует поле quack, и тогда можно было бы делать
> if node.quack and node.quack is Callable
Null is Callable?
Сначала пойди поспи, а потом ответь на этот вопрос на свежую голову.
> Это невозможно на уровне концепции.
Возможно. Концепция в том, что у класса запрашивается метод и если метода нет, необязательно вываливать экзепшн, можно и нуль возвращать. Что и показано в моём посте.
О скоростях я вообще ничего не говорил, только об удобстве. О скоростях ты сам додумал, сам приписал мне, сам блестяще опроверг.
Накидал план этажа. Все гипертрофировано и пустота снизу-слева, под лифт. Так 3-5 этажей на демку.
Ты тот анон, который типа молчаливые холмы пилит?
А что за прога, подскажи, пожалуйста. А то в draw.io не супер удобно урвони для 2d игры проектировать
Да, тот анон.
А прога, это Blender, потом экструдирую по краям и получаю стены. Накрываю плейном, и получаю потолок. По уровню удобства сравнивать не с чем.
Пытался реализовать это через bounce()
У меня сделано так. Работает надежно. Но это тройка, если что. Дирекшн в следующем фрейме пересчитывается в велосити, велосити в мув_энд_слайд
Да у меня так же. Только еще фильтр стоит, чтобы отскок был только от стен. Проверял через print(). Работает исправно, т.е. коллизии детектятся исправно.
Блендер сам по себе годнота, а ещё куча аддонов годнейших. И всё это бесплатно, т.е. даром. Ваще охуеть!
Потыкал. Впечатления смешанные.
Плюсы:
- Очень удобно задавать размеры стенам.
- Наглядная планировка
- Заготовки дверей
Минусы:
- На дверях начинает тормозить
- Раз крашнулось (не смертельно)
- Нельзя объединять комнаты
- Непонятно, как текстурить
Есть плюсы и минусы. Можно попробовать использовать только для построения стен, остальное реализовать булевыми. Если не смогу решить как работать с ним конкретно, откажусь, я слишком по долгу затыкаюсь в таких раздумьях, прям беда.
А еще есть аддон CAD Sketcher который реализует параметрическое моделирование. А еще есть геоноды.
Попробую геоноды, они должны работать быстрее любого аддона. Проблема любых Blender-аддонов - они написаны на Python и очень медленные в геометрии.
https://godotengine.org/asset-library/asset/2645
Удивительно что оно не изкоробки.
Из максимально похожего на мои хотелки нашлось только вот это
https://www.reddit.com/r/godot/comments/xshtqc/i_got_svgs_rendering_at_runtime_in_godot/
но там чувак пообещал аддон и всё.
Вчера только нашел время попробовать этот метод, заработало без каких либо проблем. Я так понимаю с такой системой можно сделать вообще вче интерактивные объекты от предметов до записок?
у svg нет "натурального представления". это вектор, ты его скейлишь как угодно, dpi/ppi важно когда тебе нужно нарисовать с конкретной плотностью на оконечном девайсе.
некоторые заморачиваются с отрисовкой под разрешение пользователя (под мобилками такое бывает) - но во первых это может быть долго, а во вторых смысла ноль - если нужны всякие эффектики их часто проще в фотожопе шлепнуть чем с шейдерами корячится.
Теперь непонятно как текстурить, если стены поделены на отдельные объекты с модификатором Solidify - то есть, для каждой стороны свою развертку не сделать.
Видимо аддоны, упрощающие разработку стен в Blender не очень подходят для импорта в Godot, просто потмому что добавляют промежуточные шаги с преобразованием в обычный меш.
Я это и имел ввиду. Контрол имеет размеры например 400 на 300 - отрисовывается свг в этом масштабе. Контрол увеличился до 2000 на 1500 - свг перерисовался в новом масштабе.
>>950549
Копируешь результат в отдельную коллекцию, применяешь на копии все модификаторы, разворачиваешь, текстуришь, экспортируешь. Если вдруг понадобится переделать, оригинал в соседней коллекции лежит. Но вообще да, как-то неудобно выходит. Кажется я где-то видел модификатор-развёртку, но не помню, где.
>Но вообще да, как-то неудобно выходит. Кажется я где-то видел модификатор-развёртку, но не помню, где.
Вернулся к предыдущему плану - плоскостями накидал план, а затем экструдировал модификатором Solidify. Все дополнительные дырки под окна сделаю через булевый модификатор. Тут модификаторы тоже нужно применять, но шагов ощутимо меньше чем с доп. аддонами.
> Контрол имеет размеры например 400 на 300 - отрисовывается свг в этом масштабе. Контрол увеличился до 2000 на 1500 - свг перерисовался в новом масштабе.
так это смысла чаще всего не имеет, рендери сразу в максимально-нужном и скалируй вниз, это бесплатно. Хотя если только у тебя там ажурный SVG где надо толщину линий выдерживать независимо от расширения - тогда наверно имеет смысл перерисовывать
Зло.
Геометрию корраптит моментально. Но! Если у тебя куб, и булём вырезается второй куб, то ты вполне можешь пофиксить косяки буля.
Не думал делать прямо в движке CSG или каким нибудь аналогом крокотайла
>О скоростях ты сам додумал, сам приписал мне, сам блестяще опроверг.
Ну, это я на самом деле не с тобой спорил, а просто в пространство выкидывал рассуждения.
А вот шас с тобой:
>Null is Callable?
Если ты не знал, сначала проверяется левая часть and'а, и если она ложная, то правая просто отбрасывается без проверки. Поэтому подобные конструкции совершенно легитимно записывать в одну строку:
if foo and foo is int and foo == 1:
И ты никогда не словишь тут краш. Ну, по крайней мере, в гдскрипте.
>Концепция в том, что у класса запрашивается метод и если метода нет
А как ты запросишь метод? Строкой. Чтобы узнать, есть ли у класса искомое поле, нужно найти строку, а это дорого. Поэтому гдскрипт по умолчанию не занимается таким. Но разрешает тебе самому поискать, если очень хочется.
Для заранее известных полей применяется оптимизация, заменяющая их имена-строки на уникальные стрингнеймы, которые по сути просто индексы в адресном массиве.
В общем, подменять не найденное поле на null не так-то просто, это потребует выполнять строковый поиск перед каждым запросом. Какой-нибудь луа может себе это позволить благодаря JITу, гдскрипт - нет.
>>950529
Предполагаешь верно. Хорошо, что ты освоил сигналы. Это один из базовых паттернов взаимодействия между нодами в Годоте, он тебе неоднократно пригодится. Особенно удобно использовать для всяких систем, находящихся в дереве далеко друг от друга, например, соединять перса с хп-баром.
Теперь учти предупреждение анона >>950134. Представь, что НПЦ стоит аккурат перед дверью, их ареи пересекаются. Сигнал в такой ситуации вызовет одновременно и открытие двери, и начало диалога. В принципе, можно просто не ставить интерактивные объекты слишком близко. Решишь эту задачу тогда, когда прокачаешь скиллы. Просто затравка на будущее, потому что сейчас тебе наверняка есть чем заняться более важным, чем переписывание работающего кода.
Задача тупая какая-то. Если вызывать дверь и разговор рейкастом, то сработает только ближний к игроку рейкаст. Сигналы вообще не причем.
Все вписал, ошибок не выдает, но ничего не двигает
Не, смотри, у тебя рейкаст пуляет в точку, куда ты мышкой смотришь. И он детектирует тела, а не ареи. И когда он что-то находит, он даёт команду показать тебе на экране "пресс Х ту экшон". Помнишь знаменитые мемы из скайримофолача, когда на экране постоянно переключаются надписи "попить-взять-попить-взять" на унитазе, в котором лежат патроны? И челик елозит-елозит мышкой и в конце концов выбирает "попить". Вот чтобы избежать таких мемов на ютубе по твоей игре, ты должен всё обнаруженное пихать в массив, и выводить списком на экране с возможностью выбрать действие из списка. Большинство современных игор делает так.
>>950604
> А как ты запросишь метод? Строкой.
Да, вот тут-то я не подумал настолько далеко. Ведь в конечном итоге где-то должна взяться строка. Но справедливости ради, она возьмётся уже в сишных потрохах движка, не в гдскрипте, и возьмётся скорее всего хэш по индексу, или как-то так. В любом случае будет быстрее, наверняка.
Хочу как в анреале визуал скрипты на всё, без кодинга, это реально? В шапке ответа не нашёл.
пытаюсь приделать базовый сигнал с параметрами к динамически создаваемой ноде
_option_node.connect("pressed", _on_answer_selected.bind("next_id",answers["next"]))
но в рантайме ошибка
E 0:00:04:0969 emit_signalp: Error calling from signal 'pressed' to callable: 'CanvasLayer(UI.gd)::_on_answer_selected': Method expected 1 arguments, but called with 2.
<C++ Source> core/object/object.cpp:1140 @ emit_signalp()
в принципе почему понятно, вижу решение проблемы как в гуе натыкать доппараметр базовому сигналу, а как мне заставить это работать в моем случае?
>она возьмётся уже в сишных потрохах движка
Дык has_method и подобные - это тоже обращение к сишным потрохам движка.
>хэш по индексу, или как-то так
Ты только что StringName https://docs.godotengine.org/en/stable/classes/class_stringname.html
>>950608
Речь шла про 2д. Там для взаимодействия используются не рейкасты и направление взглядв, а ареи и пересечение персонажа с ними.
>>950636
Ты неправильно используешь bind. Ему не нужно писать имя биндимого аргумента, только значение.
> Ты неправильно используешь bind. Ему не нужно писать имя биндимого аргумента, только значение.
Спасибо, и правда.
> без кодинга
> визуал скрипты на всё
Реально.
> как в анреале
Нет. Архитектура такова, что визуалскрипты причиняют БОЛЬ. Поэтому их выпилили в 4 версии. Но они поставляются как отдельный аддон.
> В шапке ответа не нашёл.
Недочёт. Исправим. ОП! Эй, ОП!? Сделой!
>Сигнал в такой ситуации вызовет одновременно и открытие двери, и начало диалога. В принципе, можно просто не ставить интерактивные объекты слишком близко. Решишь эту задачу тогда, когда прокачаешь скиллы.
Да, я думал об этом моменте, но его как раз легко обойти тобой же озвученным способом. Я звезд с неба не хватаю и просто потихоньку сижу и разбираюсь. Сейчас вон вообще думаю как бы все упорядочить с анимациями и обойтись без машины состояний. Чтобы без заморочек так сказать.
> обойтись без машины состояний. Чтобы без заморочек так сказать.
Машина состояний - это и есть без заморочек. Учи её. И реализуй. Спасибо скажешь.
Есть три общепризнанных подхода к стейтмашинам в годоте:
1. На нодах (поддержка редактором в дереве сцены, просто добавляешь стейты как ноды к своей сцене)
2. На ресурсах (поддержка редактором в инспекторе, просто добавляешь стейты как ресурсы в одной ноде, но уже нужно скриптом задать экспорты)
3. На простых объектах (RefCounted, без поддержки редактором, чисто в коде)
Тебе какой больше импонирует?
Две проблемы при выводе:
- Дублируются 3d объекты в камере (т.е. рисует из сцены с gui камеры (правильно, она ортогональная), и рисуется на main сцене в камере (перспектива), то что было в gui по координатам.
- При растягивании окна как я понял gui_viewport просто растягивается, а не рендерится в том же разрешении что и root.viewport из-за чего все в лесинках.
Как решить? Что-то не могу загуглить.
Скрин работающего дерева сцены (при запуске проекта, remote) - в студию!
По первому я не могу понять как разделить на слои.
>>950679
Не знаю даже, какой эмпонирует. Но уговорили. Поизучаю, посмотрю. Просто сейчас я вроде как все сделал, но это может враз поменяться и при добавлении новых анимаций все полетит.
Upd: записываем обратно, без него не рендерится одновременно 3D (патрон) и 2D (очки)
Ты помнишь фильм "кин-дза-дза"?
Извини, что издалека начинаю, но это не шутки, хотя сейчас будет похоже будто я рофлю.
Ты помнишь там цветовую дифференциацию штанов?
Так вот. В годоте именно она родимая. И ты у себя в проекте, судя по скринам её нарушаешь. Карочи. Во главе дерева стоят белые ноды. Только от белых нод могут происходить цветные. Цветные ноды нельзя смешивать. У тебя в корне сцены стоит красная, потом белые, потом вложены зелёные и синие вперемешку.
Переделывай архитектуру, по цветам. Пик самхау релейтед. Удачи!
Давай попробуем не смешивать ноды в примере
уменя не получилось
С первой проблемой разобрался. Есть оказывается волшебная галочка, чтобы посмотреть импортируемый меш и на нем можно выбрать instance layer. Закинул GUIню на второй слой.
Если еще сегодня напишу чтобы красиво патроны перезаряжались, то вообще будет здорово.
Всем невидимых лучей добра из раздела 3D.
Ограничивают, пухнут на 10 экранов, ужасно скалируются, трудно поддерживать. ГДСкрипт хорошая альтернатива - простой как два пальца, за день изучается от и до, не ебет мозги, позволяет сфокусироваться на делание игр вместо возни с языком.
4. Вообще без этого всего, на матчах.
Самый лёгкий в освоении вариант, так как для него достаточно азов программирования. А потом уже, поняв принцип работы, осознать, как это можно разбить на ноды/ресурсы/объекты.
> на матчах
Новичковый уровень, чисто для понимания сути. После этого ты рано или поздно приходишь к выводу, что стейты должны быть сущностями, не обязательно ООП-объектами, но именно сущностями со своим поведением. Вместо матча в стейт-машине переключается текущий стейт, после чего вся логика автоматически делегируется ему.
Поэтому матчам-свитчам-ифам не положен отдельный пункт, а положены только мемы.
Ты к нам по моей ссылке пришёл?
>>334729-кун из юбилейного
>>950720
Пока кстати изучаю это вариант. И возник вопрос, стоит ли, делать отдельные состояния для:
Ходьбы
Карабкания
Прыжка
Падения
Или их можно ужать до:
Ходьба (включая прыжок, падение, инерцию при этих состояниях)
Карабкание
Вот тут решение
https://www.youtube.com/watch?v=E9h9VnbPGuw
Не обязательно тот аддон ставить, главное принцип уяснить: стейтмашин может быть несколько, как параллельных, так и последовательных.
Спасибо, гляну.
>>950675
И еще к сигналам вдогонку. Как я могу со стороны игрока проверить произошел ли коннект? Есть простое решение, или надо так же посылать сигнал со стороны интерактивного объекта?
> Есть простое решение
Коннект возвращает код результата операции.
Записывай его себе
> var err = player.on_foo_bar.connect()
Шевели своей собственной мозга. Пробуй. На практике понимай, какие стейты тебе нужны, а какие нет.
И не пользуйся аддонами. Стейт-машина - базовый паттерн, который встречается в геймдеве повсеместно. Крайне необходимо освоить его, чтобы двигаться дальше. Уметь написать, уметь применить.
Приходи, когда столкнёшься с проблемами, которые не сможешь решить методом проб и ошибок. Никто твою игру за тебя не сделает, но указать путь по проторенной дорожке мимо граблей - укажем. И положим несколько тренировочных, с мягкой рукоятью.
>var data: Dictionary
>data[Vector3i(x, y, z)] = ...
>data.erase(Vector3i(x, y, z))
Ещё интереснее, самые эффективные проверки:
>if Vector3i(x, y, z) in data: ...
>if Vector3i(x, y, z) not in data: ...
Использование y.has(x) и not (x in y) медленнее.
>>914070 →
>Помощь с проектом нужна?
Спасибо, но я пока хочу сам всё делать.
>отрефакторить или допилить твой код
Так это же самое интересное в геймдеве.
>>914221 →
>верёвка крюка-кошки натягивается не по физике.
Что ты имеешь в виду, конкретно? У этой веревки высокая эластичность, т.е. способна растягиваться, оказывая сопротивление тем больше, чем сильнее растянута. Растяжение зависит от расстояния между игроком и последней точкой крепления (она может наматываться на объекты) с учётом длины верёвки. Соответственно, когда верёвка дёргает игрока, он взлетает немного выше необходимого и верёвка перестает оказывать воздействие, игрока тянет гравитация и он снова растягивает верёвку, и т.д.
Нереалистичное условие - игрок способен очень медленно двигаться, находясь в воздухе, без этой особенности в играх уже непривычно становится. Поскольку базовая скорость очень высокая, игрок может нереалистично быстро раскачиваться; если совсем не трогать WASD, раскачивание выглядит достаточно естественным. Пробовал блокировать воздействие WASD, но лично мне это не нравится.
>Или может есть способ на лету менять игроку тип тела с чарактер на ригид?
В принципе, можно просто невидимый ригидбоди использовать, копируя его положение на игрока. Но у меня с этим какие-то проблемы были, не помню уже, попробовал так и в конце концов отказался.
>тело переключается на ригид с джойнтами
Джойнтам в Godot Physics 3D стабильности и функционала не хватает, в Godot Jolt тоже какие-то проблемы (по крайней мере полгода назад были).
Да, меня тут не было больше полгода.
>Интерактивный предмет предоставляет арею
Не обязательно создавать лишнюю Area, если твой интерактивный предмет уже имеет физическое тело. Главное проверять, с чем именно пересекается луч. Изначально неосязаемым, конечно, нужна Area.
Т.е. RigidBody мячу и StaticBody двери не нужны Area для взаимодействия по кнопке, а для выключателя света на стене потребуется своя отдельная Area.
>>950020
>Area2D может зарегистрировать только выход или вход. Один раз.
Нет, можно в любой момент запросить списки всех пересекающихся тел и зон. Списки обновляются с задержкой, но существуют постоянно:
https://docs.godotengine.org/en/stable/classes/class_area2d.html#class-area2d-method-get-overlapping-areas
>как бы все упорядочить с анимациями
Просто используй встроенное решение.
https://docs.godotengine.org/en/stable/tutorials/animation/animation_tree.html#state-machine-travel
Ничего лучше тут не придумать.
>>950731
>стоит ли делать отдельные состояния
Разные анимации - разные состояния.
Практически никогда для взаимодействия не используется та же коллизия, что и для физики, и вот почему:
1. Физическая коллизия обычно значительно меньше
2. В физические объекты нельзя войти, на то они и физические
Рейкасты - не сюда. Это в 3д взаимодействие зависит от направления взгляда (и то, только если игра от первого лица); в 2д же оно зависит просто от положения персонажа в пространстве. Иначе будешь постоянно сталкиваться с кривой коллизией взаимодействия. Хочешь совершить действие, но не можешь, потому что персонаж или смотрит не в ту сторону, или стоит на один пиксель выше, или ещё какая-нибудь невидимая дребедень.
>запросить списки всех пересекающихся тел и зон
В контексте обсуждаемой задачи, как ты предполагаешь использовать эту информацию?
Второй урок по годоту от весельчака с фальшивой улыбкой
https://youtu.be/e1zJS31tr88
Ппц поверхностно. А на него так надрачивали в комментариях. Он же тупо пересказывает официальную документацию.
Так когда он вместе с командой, сидел на зарплате у юнитеков, тоже тупо пересказывал документацию.
Это гайды для ньюфагов, пчел. Хз каких секретных знаний ты там ожидал.
https://itch.io/game-assets/tag-godot/tag-shaders
Ебануться, оказывается люди свои шейдеры на итч выкладывают.
Файловая система внизу, как в юните! Бесценно для перекатунов.
Что произойдет если через охуилиард лет тайм достигнет какого-либо максимального значения? В годоте вообще есть максимум для флоата?
Двачаю.
Особенно учитывая, что у него опыт в годо - максимум полгода.
>>950904
>максимум для флоата
Ты плохо представляешь себе, что такое флоат.
https://docs.godotengine.org/en/stable/classes/class_float.html
и там по ссылкам на википедию пройдись ещё.
> Что произойдет если через охуилиард лет тайм достигнет какого-либо максимального значения? В годоте вообще есть максимум для флоата?
Всем будет глубоко похуй.
Солнце давно погаснет к тому времени, а андроиды-потомки древней цивилизации людей будут обладать такими технологиями вычислительной техники, при которой эмулятор древнего человечьего компа с вендой и годотом сможет прозрачно наращивать битность примитивных типов. Был флоат 4-байтовый, а потом хуяк и стал 16-байтовый, и твой код дальше маслает. А андроиды сели вокруг монитора с твоим проектом и смотрят как там циферки в консольке бегут.
Кстати, сделай игру по этому сюжету.
Да ладно ты сделай сначала игру с сюжетом или геймплеем с сессией на 5 суток, куда там о годах думать.
https://godotengine.org/article/dev-snapshot-godot-3-6-beta-5/
Нойс. Плюс куча других оптимизонов.
У меня есть сохраненный сценой настроенный Label
И я хочу его динамически подгружать
Я делаю что-то типа такого
var tooltip = preload("res://Scenes/UI/tooltip_label.tscn")
func _ready():
self.add_child(tooltip.instantiate())
tooltip.hide()
но получаю ошибку, потому что tooltip остается PackedScene, а не Label,и метода hide() у него нет, а если я объявляю tooltip принудительно как Label, то его не получается подгрузить из файла.
Я понимаю, что что-то делаю не так, но пути решения пока не вижу.
Мне кажется чатжпт тут врет, он же написал то же самое что у меня.
Ты неправильно понимаешь смысл PackedScene.instantiate. Эта функция не превратит ресурс в ноду. Она возвращает ноду. Так что тебе надо сделать
var my_var = tooltip.instantiate()
и дальше уже обращаться с этим как с Label'ом - добавлять в дерево, скрывать, показывать и прочая.
Вообще, не уверен, что возможно конструкцией вида foo.bar() изменить тип foo, ведь bar это поле класса foo...
Он нет. Смотри, у тебя в переменной tooltip сидит прелоад(сцена), то есть сидит PackedScene. Ты ее инстацируешь, добавляешь в дерево. А потом, не меняя переменной, дергаешь .hide(). То есть ты пытаешься дергать .hide внутри PackedScene, а тебе надо дергать в уже инстанцированной сцене. Посмотри внимательно - код разный, переменные разные.
Теперь хоть с людьми не разговаривай вообще.
Я обычно так же пишу.
var ball это игровой объект
var ball_tscn это (пред)загруженная сцена.
ball = ball_tscn.instance()
Алсо есть еще один способ немного пахнущий
Ты можешь добавить ноду в конкретное место в дереве.
Например $UI/Tooltips.add_child(your_instance)
Тогда тебе не нужна отдельная переменная и ты можешь писать
$Ui/Tooltips.get_child(0).hide.
Или даже $Tooltips.hide() если устраивает скрыть все.
Бротан, не пропадай.
Через недельку там новый жтп 4о в публичном доступе окажется
> разницу понял
Если хочешь чтобы твой код заработал, делай так:
> var tooltip = preload("res://Scenes/UI/tooltip_label.tscn")
> func _ready():
> tooltip = tooltip.instantiate()
> self.add_child(tooltip)
> tooltip.hide()
Вот так тоже заработает.
Хочу сделать обычный квестовый курсор - который меняет вид и появляется подсказка о том, куда наведен предмет
Поменять курсор несложно и собственно сделал тултип который рисуется за ним, но он рисуется при передвижении с задержкой и некрасиво, нужно сделать как-то еще.
Пока план иметь сцену с курсором и подсказкой и при необходимости настраивать ее и как-то делать из нее например png и засовывать уже картинку в системный курсор.
Это нормальная идея или лучше как-то еще?
Типичная проблема X - Y
Ты надумал себе, что в играх к системному курсору лепят внутриигровые тултипы, и бросился и скать решение. А на самом деле в играх системный курсор вовсе скрывают и заменяют своим спрайтом.
Может я неправильно понимаю что ты имеешь в виду под "заменяют своим спрайтом"
Я вижу два пути
Первый - заменить курсор на свою картинку
Второй - водить свою картинку вслед за курсором в _physics_process или _process
И во втором случае я наблюдаю задержку при движении, да, как например на видео
https://youtu.be/JrQ1-Ea6_KM?t=221
Да ты прав, скорее всего делать самому будет слишком геморно.
Не не, все верно. Инпут лаг будет, либо на вводе, либо на выводе через двойной-тройной буфер, так что да 2-3 кадра задержки наивным способом, какие то способы борьбы с этим описаны, но сходу не придумаю как это сделать только для курсора.
https://github.com/godotengine/godot/issues/75830
И тогда задержка будет 0-1 кадр.
https://docs.godotengine.org/en/stable/tutorials/inputs/custom_mouse_cursor.html
Вот решение без задержки.
Заменяешь глобально два шейпа, допустим стрелку и руку. Дальше варианты:
а) Интерактивные объекты - наследники Control, и у них задано свойство mouse_default_cursor_shape = 2. Даже кодить не надо.
б) Интерактивные объекты - наследники CollisionObject2D, тогда у них есть сигналы mouse_entered и mouse_exited, по которым ты можешь менять шейп мыши (это дешевле, чем каждый раз задавать всё изображение). Но на этом пути я вижу впереди потенциальную конструкцию из костылей и велосипедов.
С картинками понятно, я столкнулся с проблемой как сделать красиво перемещаемый текст вместе с курсором.
Как принято в квестах https://youtu.be/N1_6KBOj85s?t=715
Сорян, это не ты ли в начале треда троллил про невозможность нарезать спрайты и запихнуть их в y-sort как в Диско Элизиуме?
Так он прав про инпутлаг. Читни issue выше. Он может до 5 кадров доходить.
Ты сам же решение и предложил >>951019. Я в своих играх всинк отключаю всегда. Самая бесполезная технология во всей индустрии.
Кайф когда в настройках игры еще слайдер максимального фпс дают.
Тиринг не мешает? Я так понимаю что там бывают приколы с 59.94Hz в каком то стандарте телевидения, что может приводить к расхождению через какое то время.
Тиринг проблема редкая и микросекундная. Всинк проблема постоянная. Тот, кто придумал лечить тиринг всинком явно любитель лечить прыщи сдиранием кожи.
Нет, чел, тиринг это не редкая проблема. У меня на 40" телеке по крайней мере он всегда заметен. Может ты просто не в курсе что это.
Я замечательно в курсе что это, наблюдаю возню с тирингом и Xorg'ом уже лет 20. Я тебе не говорю что тиринг не проблема. Я говорю что всинк проблема хуже.
> задержка с позиционированием же
Да, есть задержка между системным курсором и графическим фреймом. Если на экран выводить одновременно системный курсор и графический. Так ты спрячь системный курсор-то. Игроки ничего не заметят.
>>951029
> Как принято в квестах
Выведи с помощью хаков системный курсор поверх депонии и охуеешь от задержки, так что, депония на годоте написана?
А двигаешь ты его по float координатам? Ну скажем x += 0.01
Еще в настройках шрифта есть хинтинг и антиалиасинг, фиг знает как он влияет.
>Ну скажем x += 0.01
Именно так и двигаю.
>в настройках шрифта есть хинтинг и антиалиасинг
Все потыкал. На самом деле я сейчас понял что зависит это от стретч мода, и на хуевом мониторе как у меня это никак не объехать. Либо по пиксельной сетке прыгать (по реальной мониторовской), либо все будет сжиматься-мылиться-шакалиться, что для текста критично. Ну ладно.
Может тогда есть смысл сделать через вьюпорты, а не стретч мод
> Пора топать на скетчфаб искать мебель
Тормози! Стой! У меня есть для тебя шикарное предложение! Есть такая программа Sweet Home 3D - там в комплекте огромный пак мебели. Лицензия то ли ЦЦ то ли опенсорц. А у них на сайте ещё ссылки на другие библиотеки мебели.
Интересно, нужно посмотреть. Но возможно придется доработать до какого-то пост-совкового вида.
А... ну... как бы да. Если нужно очередное ВСЖ, с совковой мебелью, набившее всем оскомину, то да, это не подойдёт, там мебель современная. Икеевская.
Работаю с чем знаком. Рисовать евроремонты которых в жввую никогда не видел займет еще больше времени.
>>951134
С чем?
Аттрибуция это когда ты обязан указать авторов ассетов в своем продукте.
> в жввую никогда не видел
Я вживую никогда не видел интерьеры космических кораблей-городов из будущего, но это мне не мешает. А даже наоборот.
Шли, хотя не факт что использую, это еще +1 софт учить, пусть и просто но время/силы/настрой жрет.
>>951143
Делать незнакомое это время и усилия, я еще и больше кодер чем дизайнер, что увеличит затраты раз в пять.
https://pastebin.com/WBj6w2tT
Пока часть переписал, бывают еще кухонные пропсы, магнитофоны импортные.
Лицензии старался отбирать CC-Attribution.
А то есть https://sketchfab.com/Valger но там только смотреть.
>Но возможно придется доработать до какого-то пост-совкового вида.
Придумал смотреть фотографии квартир на авито, бесчисленные фотографии квартир на стыке эпох. То что надо.
Если чисто для прототипирования, там прямо в ассетлибе уже есть паки с мебелью лоуполи. Совковый вид придашь им позже. Сначала прототип сделой, чтоб всё игралось.
Я серьёзно.
Не пытайся делать длительные, скучные операции без быстрого результата - это самый верный способ проебать мотивацию.
https://godotengine.org/asset-library/asset/2622
https://godotengine.org/asset-library/asset/2125
https://godotengine.org/asset-library/asset/2122
Двачую, сначала блокинг надо, иначе во что играть непонятно.
Это все хорошо если построен рабочий процесс. У меня сейчас с импортом практически каждой модели сплошной the art of zoo. Каждый раз думаешь что разобрался, делаешь в следующий раз по отработанной схеме и снова какая-то дич.
Как же годот этим надоел.
У годота с этим вообще проблемы нет.
Конечно, у тебя будет проблема зоопарка, потому что ты качаешь модели созданные разными художниками в разном софте по разному пайплайну
Если бы ты делал их все сам, то они и были бы однообразными.
Чувак, ты не слушаешь, что тебе пишут. Какой в пизду импорт? Не грузи контент, пока у тебя игры нет. Нахуй тебе этот холодильник, блять? Сделай куб потолще и куб потоньше и оттачивай алгоритмы открытия дверцы на кубах, оттачивай хранение элементов в контейнере, оттачивай перемещение элементов в инвентарь.
Еще раз: Нахуй. Тебе. Сейчас. Импорт. Контента?
Не, он все правильно делает, надо сразу делать с контентом, чтобы был look and feel. Накидает моделек 20 и уже можно их двигать. Это немного дольше, день потратит, зато блокинг уже будет делать сразу в приближенном к атмосфере реузльтату.
> У годота с этим вообще проблемы нет.
На трёшке сидишь небось?
В четвёрке есть проблемы с импортом, о чем рассказал Петя Сканер в недавнем видосе. Проблемы впрочем фиксятся самописным скриптом. подробности там: https://www.youtube.com/watch?v=R0PDD7qIHbM
> нет! яскозал! buzz word! чисто по ощущениям быстрее! диванчую!
https://www.youtube.com/watch?v=1SnMfyV5hXM
Какая именно проблема? Я в 4-ку закидывал gltf и все работает. Я же сам этот список моделек и скинул, потому что расставлял их по сцене. Может ты галочки в импорте не те выставил?
Я правильно понимаю, что в Годот 3.6 теперь будут автолоды и 3Д батчинг, а в 4.3 - нет?
Как я понял из своих тестов это не вполне 3д батчинг. Это слепление мешей в одну большую меш, буквально, и там много ограничений. Нужны одинаковые материалы, слои, светотеневые настройки. Никто из слепляемых мешей не должен двигаться по-отдельности. Для 4 хватает аналогичных плагинов.
Про автолод хз.
Лоды и автолоды давно в 4-ке есть.
Меш мерджинг - это соединение всех мешей в один, прикрутили API функцию для этого, наверное, больше года назад, а вручную всегда можно было сделать, если знать, что делаешь. Суть в том, чтобы много мелких статичных мешей сделать одним целым. Для Vulkan эта фича не особо нужна.
>1. Физическая коллизия обычно значительно меньше
Почему? Тогда меш проваливаться в опоры будет. Или хочешь увеличить зону взаимодействия? Тогда зоны соседних предметов будут мешаться.
>2. В физические объекты нельзя войти, на то они и физические
Так ты и не должен ходить сквозь дверь, например, пока не нажмёшь кнопку открытия двери. Смысл делать дверь интерактивной, если она без физики?
>Рейкасты - не сюда. Это в 3д взаимодействие зависит от направления взгляда (и то, только если игра от первого лица); в 2д же оно зависит просто от положения персонажа в пространстве.
Возьмём Terraria: чтобы открыть дверь, нужно навести мышкой на неё и нажать кнопку. Но, если не ошибаюсь, сделать это можно только если между персонажем и дверью нет препятствий, т.е. кроме положения мышки ещё делается рейкаст.
В 3D играх тем более: ты не хочешь, чтобы игрок мог случайно активировать что-то за спиной, он должен обязательно прицеливаться на конкретный объект.
>>запросить списки всех пересекающихся тел и зон
>В контексте обсуждаемой задачи, как ты предполагаешь использовать эту информацию?
Простейший пример:
>if event.is_action_pressed("interact"):
>_ for area in _interaction_area.get_overlapping_areas():
>_ _ if area.has_method("interact"):
>_ _ _ area.interact(self)
>_ _ _ break
Или так:
>if event.is_action_pressed("interact"):
>_ for area in _interaction_area.get_overlapping_areas():
>_ _ if area is InteractionTrigger:
>_ _ _ area.interact(self)
>_ _ _ break
>>951245
Понял, спасибо за объяснения. Все равно не понимаю зачем добавлять новый функционал в устаревшую ветку софта, которую неизбежно забросят в будущем, но ладно.
>Как эти дятлы докажут, что я что-то спиздил?
Тебе сюда: https://2ch.hk/law/
>зачем добавлять новый функционал в устаревшую ветку софта
На то есть несколько причин:
1. Рендерер 4 переписывали с нуля, поэтому OpenGL (compatibility) недоделанный, старых фич не хватает.
2. GLES2 в 4 нет, только GLES3.
3. Vulkan не у всех работает, особенно на мобилках.
4. В целом движок стал более требовательным, особенно это было заметно до релиза 4.0/4.1.
5. Внесли кучу изменений в GDScript, язык сцен, API движка и ещё много куда, конвертировать проект сложно, будет куча косяков, даже если получится.
Итого: новая версия движка не подходит тем, у кого слишком старый компьютер или телефон, и создаёт большие трудности с переносом большого проекта предыдущей версии. Часть уже вышедших игр отказались от перехода из-за этих проблем.
Вот для этой узкой категории пользователей они собираются выпустить 3.6 с последними фичами и дальше поддерживать только багфиксами.
Народный движок же, для всех и каждого.
>в устаревшую ветку софта, которую неизбежно забросят
Не шути так.
>Все равно не понимаю зачем добавлять новый функционал в устаревшую ветку софта, которую неизбежно забросят в будущем, но ладно.
Слышь, ты вот это не это. Я как раз на ней проект пилю, и оче жду фичи 3.6. Цикл разработки средних игр даже у компаний, а не только в соло, запросто доходит до 3-4 лет. Устраивать переход на новую мажорную версию посреди этого цикла - такая себе затея.
>там много ограничений. Нужны одинаковые материалы, слои, светотеневые настройки.
Не увидел ничего "ненастоящего". Это самый обычный, настоящий, статический батчинг.
>Я в своих играх всинк отключаю всегда. Самая бесполезная технология во всей индустрии.
>>951060
>Тиринг проблема редкая и микросекундная. Всинк проблема постоянная.
>>951063
>Я тебе не говорю что тиринг не проблема. Я говорю что всинк проблема хуже.
Почему ты так считаешь? Где пруфы?
V-sync не добавляет задержки выше одного кадра. Видеокарта просто ждёт следующего обновления дисплейных мозгов, чтобы актуальные данные не смешивались с неактуальными.
Я v-sync отключаю только когда видеокарта не справляется, ставлю ограничение на 30 кадров.
Но вначале думаю вспомнить/подтянуть матан, этого хватит или есть что-то лучше? https://www.youtube.com/playlist?list=PLImQaTpSAdsArRFFj8bIfqMk2X7Vlf3XF
И какую версию годота сейчас лучше использовать 3 или 4? Вроде и та и та обновляется...
Начинай делать игру и изучай отдельные нужные тебе темы, пока запал не пропал.
>вкатиться в разработку игр, побаловаться слегка.
>Но вначале думаю вспомнить/подтянуть матан
Матан тебе сейчас вообще не нужен. Изучай язык GDScript, основные концепции Godot и т.д.
https://docs.godotengine.org/en/stable/getting_started/introduction/index.html
По матану лучше всего читать в доках:
https://docs.godotengine.org/en/stable/tutorials/math/index.html
Делаешь что-то, не получается -> ищешь в интернете, изучаешь соответствующие темы, решаешь задачу. Абстрактный матан в геймдеве не нужен.
>версию годота
Бери актуальную стабильную 4.2.2 (x64 без C#).
https://godotengine.org/download/
Godot 3 остался ради поддержки старичков.
Я бы на твоём месте CSG кубов накидал бы.
https://docs.godotengine.org/en/stable/tutorials/3d/csg_tools.html
Порядок работы такой:
1. Создаёшь сцену table.tscn;
2. Накидываешь примерно стол из CSG кубов;
3. Расставляешь это по своей унылой локации;
4. Тестируешь...
5. Когда всё хорошо, заменяешь CSG на меши ВНУТРИ этой самой сцены table.tscn - они магическим образом встают на свои места как надо. Или не встают.
6. Тестируешь...
7. ???
8. У тебя восхитительная игра и ты молодец.
Тебе приятнее "олдфаг"? old fag = старый педик
И вообще, речь шла о старых проектах.
>надо сразу делать с контентом, чтобы был look and feel. Накидает моделек 20 и уже можно их двигать.
Надеюсь, что ты так хитро ньюфага троллишь...
>зато блокинг уже будет делать
>блокинг
Значение знаешь?
https://book.leveldesignbook.com/process/blockout
Вкратце про графику в ААА игорах с примерами:
https://youtu.be/NedDxIGQVs0
В инди эта стадия тебе тем более необходима.
Готовыми ассетами только ассетфлипы лепят.
У меня по мелким проектам уже выработалась стратегия. Сначала я полностью делаю небольшой кусочек, чтобы отработать скелет рабочего процесса - импорт, структура каталогов, освещение, текстурирование, базовые сущности, взаимодействие с объектам, перемещение. Так же будет и в этот раз. Сейчас я сделаю плюс-минус законченную квартиру ГГ с базовыми взаимодействиями, а потом пойду накидывать описанную тобой базу на остальные этажи.
Разобрался с ебучим холодильником.
Оказалось что glTF формат поддерживает только ORM материалы, то есть материалы, в которых Occlusion, Roughness и Metallic текстуры объединены в одном изображении путем их сохранения в Red, Green и Blue каналы соответственно, при этом автоматическое объединение этого дела в одну текстуру в момент конвертации blend-файла в glTF не предусмотрели. Ну а так как я скачивал FBX модель с текстурами выше по отдельности, то получалась мешанина из поста выше.
Пада-пиду-пу, хрррр тьфу.
Ну тут двоякая ситуация. Когда скачиваешь со скетчфаба, там есть glb/gltf, но они автоконвертированы самим сайтом. А вот то что идет первым файлом, там часто fbx который выложил автор, а иногда там бывает не только fbx, а и исходник или что то другое вроде obj.
Это к тому, что иногда, наоборот, gltf оказывается порченым сайтом, а модель автора можно как то самому допилить. А бывает как в этом случае, исходник глючит, а gltf нормальный. Тут не угадаешь, увы.
Нет, я абсолютно серьезно. Ты что, серьезно видишь в верхней пикче нижнюю? Я например нет. Наверное на такое способен только сеньор левелдизайнер с опытом от 5 лет. Как я уже сказал, импортировать десяток моделей - недолго, тратишь день и у тебя уже есть пропсы для блокинга, которые дают именно представление общей картины.
Честно скажу, что я кубами как то пробовал, ну и получилась игра про кубы, в кубостиле. А там, где делал хрущи сразу, получились няшные квартирки.
Опять же понятно почему так делают в студиях. Там разделение труда, левел дизигнер расставляет, потом заменяет на то, что ему моделит моделлер. Он не может этим управлять, ему сказали сделать левел к сроку и он делает, и повлиять на моделлера он тоже не может, у того свои сроки. У нас соло индюков такой проблемы нет. есть другие
Так-то половина игр из поста на который ты отвечаешь - индюки.
>>951308
>Ты что, серьезно видишь в верхней пикче нижнюю? Я например нет.
Это типичная проблема рисовак, смотрю на пустой холст и вижу ничего, пока у другого там воздушные замки. Проходит с практикой.
TLDR: Новый фуллтайм разработчик веб-экспорт подтягивает. Шаредбуффер теперь не нужен, в однотредовом веб-экспорте улучшат звук для слабых девайсов. Следующий шаг - сжимание шакалов размеров билда.
Анончик, тупой вопрос задам. На годоте возможно сделать мморпг, на 500-1000 челов? Просмотрел, и чет похожих игр не увидел. На юнити, точно знаю, что можно.
>>951316
Ты бы клон флаппи берд для начала сделал. На любом движке. Тогда не пришлось бы тупые вопрос задавать.
Чел, ты...
>1.
>2.
Тут ты жопой прочитал исходное утверждение и хуй знает с чем вообще споришь.
>Возьмём Terraria
Не возьмём. Подобное управление для 2д - большая редкость. Посмотри лучше на более типичный пример - Hollow Knight.
>В 3D играх тем более:
Про 3д мы не говорим. Вообще. Совсем. Забудь про 3д. Лучше используй этот участок памяти для того, чтобы помнить контекст разговора хотя бы на 2-3 предложения назад.
>Простейший пример
Нихуясе, ты предлагаешь инпутами дёргать все интерактивные объекты в сцене и пытаться понять, в каких из них есть персонаж? Вообще-то все нормальные люди делают наоборот: персонаж запоминает, куда он зашёл или вышел, и по инпуту тыркает те ареи, внутри которых сейчас находится.
Да, на годоте точно можно сделать. Это опен сорс движок на с++, поэтому можно написать максимально оптимизированный сервер. Если твой вопрос "можно ли просто натаскать моделек и написать говноскриптов" то конечно нет.
Насчет того, что ты написал, есть большие сомнения. В больших ммо, обычно игроков 100 только позволяют на боевых картах. Иначе потом все лагает. А во многих еще меньше, в районе 32. 500 может быть запускают в какую нибудь городскую сейф локацию, где мало событий пересылается. Ну и да, кекнул с твоего оптимизма, где ты столько игроков зазывать будешь. Не во всех коммерческих то столько приходит одновременно.
Хорошо, но мы уже научились в 3-ке прикручивать js-плеер аудио, так что пока посидим.
Два момента. Во первых, может быть ему действительно неважно как его игра выглядит, если у него аркадка, где все равно какие скины стен потом натянуть. Во вторых, может быть он тоже наслушался советов касающихся студий, и зачем то применил к себе. Знаешь, это как с git flow, кто то просто по привычке с большой работы перетаскивает в личный проект, начинает открывать новые ветки, мержить их.
Не совсем так. Аудио там только пиар, который будет экспериментальным в 4.3, а допиливать будут в 4.4
Пасиб за инфу. Я в 5 утра зачем то под пивом в тред зашел и чет написал. Меня попросили посмотреть инфу, для создания оверлея/игры для твича. Вот и "Онлайн" такой со старта. В итоге решили на годоте спратиков накидать на поле и все. Переизобретаем stream squad
>двигать не чарактер3д, а его колижн-форму
Проблема XY. Зачем тебе это делать?
>Какие подводные
1. Само движение коллизии не доставляет особых проблем, но если у тебя сотни коллизий и ты их все хочешь как-то передвинуть за один кадр, это может перегрузить процессор и вызовет "тормоза".
2. Если новая коллизия находится ВНУТРИ какого-то физического объекта, может произойти следующее:
2.1. Если это ригидбоди и он настроен регистрировать столкновения от кинематиков, то он попытается сам выбраться и улетит прочь со скоростью звука.
2.2. Если это статикбоди или любое игнорирующее кинематики тело, тогда при следующеем применении move_and_slide() кинематик резко выскочит из него.
3. В худшем случае можно застрять так, что часть коллиженшейпов с одной стороны, а часть с другой, и ты никак не можешь сдвинуть ни то, ни другое.
4. Если ты что-то с ногами делаешь и у тебя тонкий пол, игрок может провалиться в бездну, но это-то в играх легко фиксится телепортом при Y < min_height.
5. Любые застревания будут заметны для игрока невооружённым глазом и влиять на геймплей.
> в 5 утра
> под пивом
Хотел поискать мем подходящий, чтобы выразить своё фи бухающему с утра пивному алкашу, а тут нагуглилось вот такое. Не могу не поделиться. Как же велик и могуч русский язык!
Спасибо. В точности проблема XY. Но это простой как пробка объект, он один и двигается по заранее известной траектории. Думаю ни один из этих камней не вылезет. Надеюсь. Ну, просто лень рефакторить код для учета одного-единственного случая.
Потестил немного - в моих условиях ведет себя ок. Оставлю.
>Ты что, серьезно видишь в верхней пикче нижнюю? Я например нет. Наверное на такое способен только сеньор левелдизайнер с опытом от 5 лет.
Ничего подобного. Тебе не нужно видеть в кубах детализированную архитектуру. Тебе нужно видеть, сколько метров будет бежать игрок, откуда на него будут выпрыгивать враги, где будет минное поле или растяжка, где игроку нужно открыть дверь, где игрок может укрыться от пулемётной очереди, куда игрок обязан бежать и куда он может свернуть и т.д.
Только когда всё это будет определено и проверенно тестировщиками, можно начать натягивать текстуры облупленных кирпичей, заменять цилиндры на бочки, мелкие кубики на деревянные коробки и т.д.
>Как я уже сказал, импортировать десяток моделей - недолго, тратишь день и у тебя уже есть пропсы для блокинга, которые дают именно представление общей картины.
И получается у тебя ассет-флип, когда ты берёшь небольшую кучку бесплатных моделек и делаешь из них унылую сценку для симулятора ходьбы. "Общая картина" у тебя будет как в тысяче чужих ассет-флипов на том же наборе моделей.
>Честно скажу, что я кубами как то пробовал, ну и получилась игра про кубы, в кубостиле. А там, где делал хрущи сразу, получились няшные квартирки.
Симулятор ходьбы делал? Берём ситуацию: игрок в негативном отзыве написал, что в игре слишком уж далеко добираться до магазина. И он не один такой, многие игроки из ЦА жалуются на это. Что делать?
- переставишь магазин? Он встроен в модель дома.
- сожмёшь модель дома? Будет выглядеть тупо.
- переделаешь модель дома? Так ты ж не умеешь.
- увеличишь скорость игрока? Будет выглядеть тупо.
- дашь игроку велосипед? Это много работы и может значительно повлиять на другие механики игры.
В чём проблема? Ты где-то нашёл и скачал готовую модель дома и воткнул её в свой ассет-флип как было, даже не пытаясь проверить другие варианты, ведь у тебя нет альтернатив. Если б ты сначала делал из блоков и потом вручную моделировал дома или заказывал у моделлера кастомные по чётким размерам, такой проблемы бы не было.
Но это, конечно, нужно хотеть сделать хорошую игру, а не очередной ассет-флип за 29 рублей, в надежде, что его купят хотя бы по ошибке.
>>951309
>левел дизигнер расставляет, потом заменяет на то, что ему моделит моделлер. Он не может этим управлять,
>повлиять на моделлера он тоже не может
Ты вообще не понимаешь сути левел-дизайна и зачем делается блокинг уровня кубами, лол.
Сначала левел-дизайнер делает уровень из кубов, определяя точные размеры, расстояние, количество ассетов и т.д. Затем моделлеры берут эти данные от левел-дизайнера и делают модели, примерно как столяр делает мебель по заказу дизайнера.
Т.е. не левел-дизайн зависит от моделей, а модели зависят от левел-дизайна. Это ключевое отличие настоящих, качественных игр от ассет-флипов.
>>951329
>может быть ему действительно неважно как его игра выглядит, если у него аркадка, где все равно какие скины стен потом натянуть.
Что значит "как игра выглядит"? Если берешь чужие модели, то она будет выглядеть как ассет-флип из бесплатных моделек. Ты ж их "импортировал", а не разрабатывал вручную с нуля. И почему считаешь, что геймплей важен только "аркадкам"? Симуляторы ходьбы должны иметь адекватный дизайн уровней, а не абстрактный набор домиков из интернета.
От текстур стен мало что зависит, а от положения, размеров, пропорций - очень многое, буквально почти вся игра любого жанра на этом завязана, даже все эти симуляторы ходьбы с головоломками.
Конечно, ты можешь натянуть текстуру кирпичей на ранних этапах, но только чтобы примерно прикинуть, где будут целые стены, а где какие-то руины, сараи, машины и т.д. Не нужно зацикливаться на внешнем виде декораций, когда ещё нет геймплея и локаций.
Конечно, если ты делаешь виртуальный музей - тут вопросов нет, бери музейные экспонаты и ставь их как захочешь, но это вообще не игра.
>начинает открывать новые ветки, мержить их
Ветки гита в личном проекте могут быть полезны, если ты хочешь быстро пофиксить критический баг в уже опубликованной версии, но не хочешь выкладывать версию со всеми новыми фичами.
Пример:
- Версия игры в релизе: 1.2.
- Работаешь над версией 1.3, в которой добавляешь новую крутую механику, но она пока что сырая и не работает как ты планировал изначально.
- ВНЕЗАПНО игроки докладывают о критическом баге в версии 1.2, который разносит им файловую систему.
- Берёшь ветку 1.2, вносишь правки, релизишь 1.2.1 с багфиксом, но без недоработанной фичи из 1.3.
- Спокойно возвращаешься к работе над веткой 1.3.
>Оказалось что glTF формат поддерживает только ORM материалы,
>скачивал FBX модель с текстурами выше по отдельности, то получалась мешанина из поста выше.
Ты уверен, что проблема только в этом?
Я на твоём скриншоте вижу потерянные грани из-за backface culling. Проверь, что у тебя в текущем материале включён backface culling, поскольку материалы из Блендера по умолчанию рендерят все грани без разбора. Куллинг задних граней нужен, чтобы рендерер не перегружался лишним мусором, но в кривых моделях некоторые грани могут быть вывернуты наизнанку. Проверить грани можно, открыв в Блендере и выбрав Viewport Overlay -> Face Orientation. Убедись, что все видимые снаружи грани синие, а не красные - красным нужно вывернуть нормали (в режиме редактирования геометрии: shift + N для автоматического, alt + N для ручного выбора).
https://docs.blender.org/manual/en/latest/editors/3dview/display/overlays.html#geometry
Надо прозрачность проверить, вроде скетчфаб в gltf ее включает везде не к месту.
Но сегодня не субшота. Ну да ладно. Держи!
Ты зачем мной представляешься?
>>951397
>>951389
>СПЕРВА ДОБЕЙСЯ!!1
Я просто пересказываю своими словами то, что и так всем должно быть известно. У меня нет пока готовой игры, только прототипы, но они в основном в 3D. Я не стремлюсь максимально быстро выблевать в Яндекс.Игры какой-то ассет-флип, понимаешь?
Прекрасно понимаю желание накидать готовых моделек и считать дело сделанным. Сам таким был. Но потом осознал, что это просто ассет-флиперство и настоящую игру таким способом не сделать. Многие проблемы в инди сцене как раз именно из-за того, что артисты делают арт до геймплея и левел-дизайна, а потом в игре ничего хорошего кроме арта нет.
> Ты зачем мной представляешься?
Потому что твоему оппоненту похуй, он жирнющий тролль, а ты его кормишь.
Всем должно быть известно, что есть случаи для которых подходит самосвал, а для которых подходит Ламборгини. Если ты делаешь спинномозговую аркаду - вопросов нет, тебе надо больше двигать блоки. А если анон делает атмосферный хоррор, то профит от расстановки шкафа есть, а от двиганья белых кубов нет. А ментальные усилия на это одинаковые, кроме первоначального вклада времени на импорт.
>>951403
Не тролль.
>>Terraria
>Подобное управление для 2д - большая редкость.
>более типичный пример - Hollow Knight.
В 2D с видом сбоку я чаще играл в разные клоны Terraria, чем в метроидвании. Если честно, только недавно начал пробовать метроидвании, т.к. не люблю жанр платформеров. Террария, как по мне - идеальный платформер, ведь на её базе возможно реализовать что угодно, и другие 2D платформеры после неё особо не нужны.
>>В 3D играх тем более:
>Про 3д мы не говорим. Вообще. Совсем.
Интерактивность объектов не зависит от 2D/3D, если мы говорим об организации скриптов игры.
>ты предлагаешь инпутами дёргать все интерактивные объекты в сцене и пытаться понять, в каких из них есть персонаж? Вообще-то все нормальные люди делают наоборот: персонаж запоминает, куда он зашёл или вышел, и по инпуту тыркает те ареи, внутри которых сейчас находится.
С чего ты это взял? Зачем что-то запоминать?
На персонаже висит Area2D с круглой коллизией, назовём её InteractionRadius и настроим её на регистрацию коллизий с определённым слоем, который назовём Interactives. На интерактивных объектах висят Area2D, назовём их InteractiveTrigger и поместим их в слой Interactives, отключив им мониторинг, потому что сами они ничего делать не будут. В интерактивных объектах нет никакого кода, кроме одной функции interact(with_whom) и связанных с ней действий, весь код исполняется только со стороны игрока внутри его _unhandled_input(). Код игрока, при нажатии кнопки взаимодействия, спрашивает у InteractionRadius, какие InteractiveTrigger находятся в зоне досягаемости? И если какие-то доступны, а скорее всего только одна, у неё исполняется метод interact(), который делает то, для чего создан этот предмет (дверь открывается, выключатель на стене включает источник света, автоматическая турель включает боевой режим, и т.д.). Никакие сигналы тут не нужны и тем более не нужно по всем объектам в мире бегать, мы же получаем только список ближайших.
Если тебе нужно показать подсказку "нажмите E, чтобы взаимодействовать", тогда ты можешь в _physics_process игрока один раз спрашивать InteractionRadius.has_overlapping_areas(), это не будет затратной операцией, потому что всего один запрос к одной ноде, у тебя на движение A/D наверняка уходит больше времени, чем на это. Поскольку InteractionRadius настроена воспринимать только определённый слой, в котором существуют только InteractiveTrigger, её работа не должна существенно влиять на физический движок.
Впрочем, ладно, можно сигналы входа/выхода использовать, в некоторых ситуациях это проще, например, если объект должен включать контурную подсветку, пока рядом находится игрок - этим должна управлять InteractiveTrigger.
Просто у меня постоянно проблемы с этим: либо сигнал входа не срабатывает, либо сигнал выхода не срабатывает, какая-то ошибка в логике движка.
Может быть, в 4.3 наконец-то пофиксят эти баги.
>этим должна управлять InteractiveTrigger.
...ааа, не-не, в 3D этим должен рейкаст управлять, иначе все объекты возле игрока светиться будут.
Походу, универсального решения нет.
Да. В прошлом-позапрошлом треде анон страдал неделями. Можешь сходить почитать.
>ты делаешь спинномозговую аркаду
Тащем-то да, тут не поспоришь.
>тебе надо больше двигать блоки. А если анон делает атмосферный хоррор, то профит от расстановки шкафа есть, а от двиганья белых кубов нет.
Ты всё ещё не понял сути блокинга в левел-дизайне.
Разберём жанр хоррора. Хороший хоррор должен чётко отмерять время, которое нагнетает у игрока ощущение страха перед чем-то опасным. Если хоррор слишком затягивает с этим, то игроку становится скучно бродить по коридорам. Если же хоррор на каждом шагу скриммеры в лицо суёт, то игрок привыкает и перестаёт бояться. Должен быть баланс, и он зависит от того, как устроены локации и что в них игрок делает, а это, опять же, зависит от геометрии уровней, а не от текстуры кирпича на стенах и не от деталей полки в модельке холодильника.
Даже если взять мобов в хорроре - им не нужен финальный дизайн, чтобы прикинуть их работу. Для начала нужно определиться, большой это моб или маленький? Быстрый или медленный? Будет ли он неподвижно стоять, пока игрок на него смотрит, или он побежит, когда игрок пересечётся с ним взглядом? И т.д. Только после определения всех этих переменных и предварительных тестов на движке можно выдумывать, как моб должен выглядеть, и моделировать его внешность. А не так, что взял рандомного зомби из бесплатной коллекции моделей и засунул его в рандомную комнату - "на те, бойтесь его, это ж хоррор".
Но это если ты хочешь хороший хоррор сделать, а не очередной "инди-хоррор" из бесплатных моделек зомби и обосранных коридоров с мусором.
>усилия на это одинаковые
Ты просто не видишь подводных камней.
Правильный блокинг позволяет избежать переделывания ассетов в будущем. Ты заранее отменяешь участки, расставляешь триггеры событий и т.д. В дальнейшем ты это всё менять не будешь, не будешь переставлять по карте холодильники, двери и мобов. Если же ты берёшь готовые модели и пытаешься из них что-то слепить, ты можешь обнаружить, что модели к чему-то не подходят, что ты не можешь сделать из них то, что тебе хочется, и т.д. Тебе придётся править модели, искать или делать новые. В общем, без блокинга ты можешь застрять на переделывании уже готовых моделей под конкретные ситуации, что может быть даже сложнее, чем делать с нуля.
Универсального решения нет. Есть классическое. О нём я написал ещё в прошлом треде.
1. У игрока рейкаст на максимальную длину интеракций игрока, например 10 юнит-метров, на которые он может крикнуть "стой кто идёт!"
2. У интерактивных предметов область (Area) внутри которой игроку разрешено интерактировать.
3. Игрок интерактирует только с тем, на что смотрит мышкой.
4. Сообщение об интеракции выводится если игрок пересекается с зоной предмета.
> if raycast.is_colliding() and raycast,collider is Area3D and self in raycast,collider.get_overlapping_bodies(): UI.show...
Вот я вам даже пикчу нарисовал. Поймите уже наконец!
>У интерактивных предметов область (Area) внутри которой игроку разрешено интерактировать.
>self in raycast.collider.get_overlapping_bodies():
Зачем, если у тебя и так рейкаст кидается?
>>951429
А, стоп, кажись понял, т.е. если у предмета можно взаимодействовать только с одной стороны... Но в таком случае пусть луч останавливается в т.ч. препятствиями, а не только Area3D объектов.
>Как набрать бета-тестеров?
Есть куча способов. Вопрос в том, какие именно тестировщики нужны, готов ли выложить игру на публику раньше или хочешь NDA, бюджет и т.д.
Самый дешёвый и быстрый способ - на любой форум напиши, попроси рандомов потестить сборку. Но на какой-то результат особо не надейся, скорее всего попросят добавить корованы и нескучные обои.
Есть профессиональные тестировщики за деньги, по кусочкам игру разберут и все баги найдут. Но им, как я понимаю, нужно чёткое ТЗ, что тебе тестировать.
Есть вариант набрать комьюнити раньше релиза и выкладывать сборки в закрытый чатик для своих. Однако рискуешь получить эхо-камеру, в которой все тебя будут поддерживать несмотря на ошибки.
Стим тебе ничего не даст за просто так, туда ты должен со своим комьюнити приходить, иначе окажешься на дне и никто о тебе не узнает. Алсо, комьюнити на форумах в Стиме очень токсичное, готовы засрать за любой субъективный косяк.
Реддит - помойка типа Пикабу, только глобальная. Там очень не любят спам и самопиар, а в геймдев сабреддитах такие же как ты геймдевы сидят. На новом аккаунте легко попасть в шедоубан.
Я соло, масштаб маленький, сам понимаешь. Никакие NDA не нужны. Мне просто нужен десяток-два ранних и подробных отзывов, чтобы понять в том ли я направлении иду и, если что, скорректировать направление. Все друзья-знакомые уже использованы и заебаны.
>>951430
>>951429
Ну вот, смотрите сюды. Нужно три скрипта. На игрока, разумеется, скрипт-рейкаст. На интерактивный объект короткий скрипт-геттер. И на арею скрипт, который чекает вход-выход.
Всё ясно из кода, ящитаю:
И ещё один момент. Если мы посмотрим на > Сцена.png то может сложиться ошибочное мнение, что область должна быть вложенной в интерактивный объект, но нет, если мы внимательно посмотрим на скрипт > Area.gd.png то мы увидим, что объект задаётся в инспекторе, и область может быть накинута на любой объект как внешний компонент, или контроллер. Таким образом, для двигающихся объектов можно вкладывать её внутрь, а для выключателей каких-нибудь, просто разместить в нужном месте.
Пикрелейтед.
Поменял положение ареи в сцене - код работает как работал. Арея осталась перед игроком, а объект улетел. Но пока игрок не вышел из ареи, ссылка на улетевший объект висит в массиве.
Это можно использовать как геймплей.
Ну ты когда сделаешь игру по таким принципам, тогда приноси и покажешь ее, а я пока буду ставить шкафы там где хочу ставить шкафы, а не придумывать что же именно должно быть на месте белого кубика посередине комнаты. А потом сравним результаты.
Можно сделать менеджер взаимодействий. Тогда не будет проблемы, кто должен обрабатывать взаимодействие, игрок или предмет. А еще, в теории более расширяемая система, например можно добавить нескольких персонажей.
Код в предыдущих постах - это уже готовый менеджер. (Если точнее, ты просто ебанул в код экспортную переменную и у тебя уже менеджер, он уже манагерит данные, которые ты ему в инспекторе подсунешь). А вот как это выглядит с лейблом на экране. Первые две пикчи - игрок в зоне действия только "шкафчика", вторые две пикчи - игрок в зоне действия и "шкафчика" и "унитаза".
>Я на твоём скриншоте вижу потерянные грани
>>951393
>Надо прозрачность проверить
Да, это был косяк прозрачности. В текстуре холодильника, дырки под решетки нарисованы альфа каналом. Если в настройках материала выставить Alpha Hashed в Blend Mode то движок сделает прозрачным не только участки меша с альфой но и весь меш между камерой и участком с альфой - то бишь стенку холодильника между решеткой и камерой.
Удалось вылечить назначив полигонам с решеткой отдельный материал, то есть весь холодильник имеет свой материал с Blend Mode - Opaque, а 4-ем полигонам с решеткой назначена копия этого материала но с Blend Mode - Alpha Hashed.
Подробно это дерьмо нигде не описано поэтому опять пришлось всрать уйму времени на метод научного тыка.
При импорте есть пункт меню импортировать материалы отдельными .material файлами, они сохранятся отдельно и можно их менять свободно.
Еще вариант, вроде бы gltf текстовый файл наподобие json, и там где то можно тупо в текстовом редакторе (только тяжеловесном, не блокноте) или скриптом менять. Наверное. Вроде бы получалось пару лет назад.
>сохранятся отдельно и можно их менять свободно
>в текстовом редакторе (только тяжеловесном, не блокноте) или скриптом менят
Вся эта гибкость годоты замечательная, согласен. Но с точки зрения разработки игры это дополнительные расходы времени, каждый раз выявлять проблемы в самом движке. При чем проблемы, которые бы можно было сократить простым описанием в документации, как в случае с альфой.
>>951478
>Ля кокая! Скоро поиграем!
Ой не скоро, если так и буду спотыкаться.
Формат gltf описан в интернете. Поля ORM и Стандарт материала описаны в документации. 2 и 2 сопоставить уже должен ты сам. Как бы это очевидно что дело или в прозрачности или в куллинге. Документация никак не сможет угадать, какую модельку и откуда ты скачаешь. А перечислять все соответствия - бред. Это превратит документацию просто в кашу из перечислений полей, которую никто не сможет прочитать. Впрочем, тебе никто не мешает отправить пулл реквест в документацию, если ты считаешь, что можешь сформулировать что-то лучше.
Игры делойте, ну.
>>951454
>>951491
Так зачем арея-то, если луч есть? Зачееем?
>>951450
>Поменял положение ареи в сцене - код работает как работал. Арея осталась перед игроком, а объект улетел. Но пока игрок не вышел из ареи, ссылка на улетевший объект висит в массиве.
ЗАААЧЕЕЕМ???
Я понимаю, если это какой-то гениальной задумкой геймдизайнера обосновано, но ты скрестил ужа с ежом и сам объяснить не можешь, зачем это сделал.
> и сам объяснить не можешь, зачем это сделал
Объект наносит урон N в секунду, если находишься поблизости. или объект - мина с таймером, которая активируется, когда ты приблизился, и нужно успеть деактивировать.
Вариантов куча. Если ты не можешь ничего придумать - не меряй всех по себе.
>дырки под решетки нарисованы альфа
Так лучше не делать, альфа дорого стоит щас.
Лучше отсыпать полигончиков, они дешевле.
>Подробно это дерьмо нигде не описано поэтому опять пришлось всрать уйму времени на метод научного тыка.
https://docs.godotengine.org/en/stable/classes/class_basematerial3d.html#enum-basematerial3d-transparency
>>951482
>каждый раз выявлять проблемы в самом движке. При чем проблемы, которые бы можно было сократить простым описанием в документации, как в случае с альфой.
Это не проблемы движка, это проблемы бесплатной васянки, которую ты скачал с какого-то левого сайта (скетчфаб там или ещё какая свалка сомнительного контента). В документации всё описано подробно, просто ты её читаешь обрывочно скорее всего.
>>951478
>Скоро поиграем!
В симулятор ходьбы по бесплатным моделькам ты и сам можешь поиграть прямо в своём Godot.
Геймплей-то в чём? По холодильникам шариться?
Так-то он молодец, конечно, старается, камера вон какая прикольная, из-за угла следит, с зумом. Но игры в этом пока что нет и холодильник погоды не делает.
> гениальной задумкой геймдизайнера обосновано
Рад знакомству. Рад знакомству. Да, это я.
> Геймплей-то в чём? По холодильникам шариться?
Я ему предложил геймплей в прошлом треде, он проигнорировал. Ну, штош. Посмотрим, что он сам придумает.
>Объект наносит урон N в секунду
>или объект - мина с таймером
Всё это целесообразнее сделать отдельной сценой, которая вешается на другие - по необходимости.
Вот у тебя есть сцена ball.tscn, ты можешь взять её в руки и бросить куда-то, она отскакивать умеет.
Есть сцена hot.tscn, она наносит урон по области.
Есть сцена time_bomb.tscn, она взрывается.
Итого, ты можешь сделать:
- безопасный мячик для практики бросков;
- горячий мячик, обжигающий руки;
- прыгающую бомбу с таймером;
- обжигающую прыгающую бомбу с таймером.
Добавь сюда glue.tscn и получишь ещё 4 варианта.
Добавь сюда smoking.tscn - будет ещё 8 вариантов.
>https://docs.godotengine.org/en/stable/classes/class_basematerial3d.html#enum-basematerial3d-transparency
> В документации всё описано подробно,
Закрывая глаза на то что ты линкуешь не описание материала а API материала, ну как покажи мне скриншотом строчку с русским переводом где говориться что Alpha Hashed приведет к прозрачности участка объекта без прозрачности.
>time_bomb.tscn, она взрывается.
Даже не так, лучше так:
- ball.tscn - прыгает
- - bomb.tscn - способна взорваться
- - - timer.tscn - активирует предка по таймеру
- - - collision.tscn - активирует по столкновению
- - - if_wet.tscn - активирует в воде
И т.д.
Композицией можно много чего сделать...
> collision.tscn - активирует по столкновению
Ну и. Вот я и реализовал выше колижн тсцн. Чё доебался?
>Alpha Hashed приведет к прозрачности участка объекта без прозрачности.
Что ты имеешь в виду?
>The material will cut off all values below a spatially-deterministic threshold, the rest will remain opaque. This is faster to render than alpha blending, but slower than opaque rendering. This also supports casting shadows. Alpha hashing is suited for hair rendering.
>русским переводом
Твоя проблема, что прогуливал школу.
>Материал отсекает все значения ниже пространственно определяемого порога, остальные остаются непрозрачными. Это быстрее, чем альфа-смешивание, но медленнее, чем непрозрачный рендеринг. Это также поддерживает отбрасывание теней. Альфа-хэширование подходит для рендеринга волос.
Нашёл я твой лолодильник, любопытно поковырять, но сраная файлопомойка требует регистрацию...
https://sketchfab.com/models/6b2862c241754f5d81690e8664e41091/embed
Вот раньше были времена - все файлы качали без смс и регистрации, и сайты летали, не было никаких калудфаеров, не было гуглокапчи, не было 403 и 451 на каждом втором сайте, всех везде пускали и печеньками угощали без ограничений, а сейчас зумеры интернет зохватили и изуродовали, скоро вообще никуда зайти без пароля нельзя будет, а пароль по паспорту, а паспорт по анализу ДНК, а анализ ДНК через анальный зонд...
Мотивации хватает, батарейка энергии села. Поделал бы с ней игры.
>рейкастшейп
>В четвёрке я не нашёл.
>особые рейкасты для лестниц
Его просто переименовали для ясности.
https://docs.godotengine.org/en/3.6/classes/class_rayshape.html
https://docs.godotengine.org/en/stable/classes/class_separationrayshape3d.html
С кинематиками и ригидами работает хорошо, но на счёт использования в Area3D не знаю, не пробовал.
>цилиндра толщиной 0,01 аналогичен
По производительности хуже, т.к. больше проверок.
>сгрести в инвентарь всё на что смотрит перс
Для этого лучше сферический шейп, наверное.
>лучше сферический
Кстати, никого не смущает отсутствие конического шейпа? По-моему, можно найти много ситуаций, когда конус подходит лучше цилиндра и сферы, например, для поля зрения мобов. Или конус слишком сложен математически для того, чтобы быть примитивом? Конический меш-то мы можем легко сделать из цилиндра CSG, а вот цилиндрический шейп в конус не превращается.
> По производительности хуже, т.к. больше проверок.
Вот здесь поподробнее, плиз. Насколько хуже? И собственно, хуже чем что? Чем цилиндр толщиной 0.02? Или хуже чем рейкаст? Или хуже чем капсуль толщиной 0.01?
> Кстати, никого не смущает отсутствие конического шейпа?
Не смущает. Мы что, жуки-плавунцы? Нешто мы Хуана подведём? Подождём релиза. Правильно, мужики? Здесь донатных нет. Надо будет - вручную конвекс-полигон по точкам построим. И далее по тексту.
>поподробнее
RTFM
https://docs.godotengine.org/en/stable/classes/class_cylindershape3d.html
>Performance: CylinderShape3D is fast to check collisions against, but it is slower than CapsuleShape3D, BoxShape3D, and SphereShape3D.
Алсо, внезапно:
>Note: There are several known bugs with cylinder collision shapes. Using CapsuleShape3D or BoxShape3D instead is recommended.
По другим шейпам:
>Performance: CapsuleShape3D is fast to check collisions against. It is faster than CylinderShape3D, but slower than SphereShape3D and BoxShape3D.
>Performance: BoxShape3D is fast to check collisions against. It is faster than CapsuleShape3D and CylinderShape3D, but slower than SphereShape3D.
>Performance: SphereShape3D is fast to check collisions against. It is faster than BoxShape3D, CapsuleShape3D, and CylinderShape3D.
Ну, про сферу и без документации очевидно, сфера - это только проверка на расстояние и больше ничего.
>>951563
Можно проще. Создаем меш, идем в Mesh -> Create Static Body, получаем колижн шейп любой формы.
А если еще CSG to Mesh использовать ...
> получаем колижн шейп любой формы
Да чот хуйня получается, жук-плавунец. Ты к нам змеёй не прокрадёшься!
Сделал бы Хуан цилиндр с двумя радиусами - вот и конус готов.
>колижн шейп любой формы
У тебя вот это получилось на скриншоте:
https://docs.godotengine.org/en/stable/classes/class_concavepolygonshape3d.html
Там проблем много разных.
>CSG to Mesh
CSG создаёт очень кривую сетку, с которой ничего не сделаешь, а для коллизий и подавно лучше не юзать.
CSG хорош, когда тебе нужно прикинуть размеры, прототип слепить на скорую руку. Потом всё равно с нуля придётся переделывать... или через ремеш:
https://docs.blender.org/manual/en/latest/modeling/modifiers/generate/remesh.html
Впрочем, ладно. Со второго раза получается вполне себе конус, но лишних вершин всё равно больше, чем у вручную нарисованного.
Нууу? Ты же согласен со мной, чем меньше вершин, тем быстрее проверка шейпа на коллизию? И конечно же только конвекс, потому что конкейв считается по другой, ещё более тяжёлой формуле.
Придется собирать всю сцену в блендере что на выходе даст огромный glTF.
Подумаю.
Хм, может быть можно там запечь только лайтмап в текстуры. Не пробовал.
А ты в веб делаешь что ли? Но зачем тогда было брать 4й. Не понимаю, сколько раз еще про это надо написать в треде.
> жалуется на ограниченную поддержку лайтмапов
> а игры-то нет, игра-то только делается
> вместо того, чтобы делать игру, ковыряется с постпроцессингом
А ты уверен, что ты делаешь игру, а не рендер простой? Так если ты делаешь рендер, зачем тебе игровой движок?
>>951616
> Придется собирать всю сцену в блендере что на выходе даст огромный glTF.
А зачем тебе GLTF? Сразу в пикчу рендерь свой рендер, да и всё.
>А ты уверен
Я не он. Просто говорю очевидную вещь, пока игра делается успеет еще несколько версий выйти. Тут вот 4.3 за углом, в нем с вебом уже получше.
Ты не Он. Никто из нас не может быть Им, а только старается приблизиться к Нему своей жизнью на Дваче.
М-да, бро. Думал-думал, как тебе ответить, в итоге забил. Не как что-то плохое, но с моей точки зрения у тебя какое-то инопланетное мышление. Я так-то не претендую на абсолютную истину, конечно, просто вещи, которые для меня очевидны и естественны, для тебя абракадабра и алаказам, и наоборот.
Штош.
Мы все с разных планет, а жаль. Если бы не это, могли бы объединиться и запилить всем тредом одну игру мою, хехе.
У меня очень тупой вопрос возник. Как в режиме 3д управлять камерой? Я хочу приблизить камеру к модельке, кручу колесико и оно приближает немного, а потом начинает работать только на отдаление. Или движение камеры по осям до ужаса медленное.
Выделив нужный объект нажми клавишу F чтобы на нем сфокусировать камеру. Если все равно мало, зажми правую кнопку мыши и управляй полетом на клавиши WASD.
>приближает немного, а потом начинает работать только на отдаление
View -> Settings... -> View Z-Near: ставь число поменьше (0.01).
>Как в режиме 3д управлять камерой?
F: сфокусироваться на выбранной в сцене ноде.
Колёсико крутить: зум к точке/от точки фокуса.
Колёсико зажать+движение мыши: вращение вокруг точки фокуса.
Колёсико зажать+shift+движение мыши: движение камеры по осям.
Колёсико зажать+ctrl+движение мыши: зум, но быстрее колёсика.
ПКМ+движение мыши: разворот камеры вокруг самой себя.
ПКМ+QWEASD: полёт от лица камеры (Q/E - вниз/вверх, shift - бег).
ПКМ+колёсико крутить: изменить скорость движения по QWEASD.
В геймдеве, как и в программировании вообще, одну задачу обычно можно решить большим множеством способов. При этом редко бывают идеальные решения, подходящие всем сразу, всегда приходится чем-то жертвовать по ситуации. Но когда изучаешь какую-то новую фичу, учишься пользоваться ей определённым образом, привыкаешь... В итоге становится сложно воспринимать альтернативы. С этим связана проблема чтения чужого кода: язык один, команды понятны, но структура программы может сильно отличаться от привычной, поэтому сложно понять, что она делает. В Godot язык сцен (.tscn) - это декларативный язык программирования (описывает только что нужно получить, но не объясняет как), хоть и не похож на привычные языки. Так что проблемы с пониманием чужой организации сцен логичны.
> язык сцен (.tscn) - это декларативный язык программирования
Это формат сериализации. Я не спорю, если что, просто уточнил. Сериализация везде декларативна.
>Всем делать игры
>язык один, команды понятны, но структура программы может сильно отличаться от привычной, поэтому сложно понять, что она делает
Ты мне щас дал +1 аргумент в споре с "комментарии не нужны, пишите самодокументирующийся код" фанатиками. Схоронил.
Как же я ору от этого видоса в контексте /гд/! Давай ещё!
- Нода1
- Нода2
- Нода3
Мне нужно чтобы нода1 получала инпут первой. Есть CanvasLayer, но как я понял он для смены очереди _отрисовки_, а обработка ввода остается старой.
Переделал структуру, проблема не актуальна. Видимо хуйню хотел.
> Видимо хуйню хотел.
Тем не менее, в движке можно и такое замутить. Но молодец, что переделал.
Для трёшки тут >>951322
>>951231
> Какая именно проблема? Я в 4-ку закидывал gltf и все работает.
Посмотри видос, и поймешь, о какой проблеме речь.
Мне не интересно выяснять что там у него в видосе. Пиши конкретно.
Я малость косноязычен, и не могу это описать. Там окошко кароч. И при изменении файла реимпорт не происходит. Хотя странно, почему не происходит? Видимо он тоже нужные галочки не выставил в панели импорта, которую показывал в своём видосе. Ну да ладно, главное что у тебя всё работает. И карочи, там много памяти потребляется. И при реимпорте материалы вложены в меши. И вот для всего этого он написал скрипт, но скрипт - моё почтение! Вытаскивает материалы из мешей, сохраняет в файлы и не дублирует, и линкует файловые материалы к мешам при реимпорте. Автоматически. Как это сделать галочками? Я бы поглядел.
Не понятно, это нужен пк на arm?
Можно заебашить кросскомпиляцию из-под линуха. Но чёт мне кажется, без большого опыта в различных сексуальных девиациях такое не провернуть.
А, уже переделал снова. Снова неактуально. Сорян, анон! Не напрягайся с объяснениями.
А почему у тебя игра по английски?
Сначала же по русски была?
И еще тебе совет по камере. Тут недавно на стопгейме вспоминали принц Персии: пески времени, и я как вспомнил, какая же охуенная там камера была! Она в основном за персом летает, но альтернативные точки есть всегда в каждой локации, и их можно включить кнопкой Q а в некоторых ситуациях камера сама встаёт в альтернативную точку. И еще с забавным воздушным звуком камера от стен отскакивает, когда её крутишь.
Посмотри лецплеи, а лучше сам поиграй, может почерпнёшь пару идей. (Я охуел от того, что ПП1 сегодня выглядит вполне играбельно, как неплохое лоуполи-инди со дна стима!)
>А почему у тебя игра по английски?
>Сначала же по русски была?
Я обычно делаю все на английском, чтобы можно было публиковать на англоязычных ресурсах. Учитывая что как минимум квартира будет скорее всего доделана, буду делать на английском чтобы выложить на реддит.
>недавно на стопгейме вспоминали принц Персии: пески времени
Моя любимая игра в серии. Невероятно сказочная атмосфера. Нужно будет действительно переиграть.
Наверно стоит переиграть все любимые игры и почерпнуть из них что меня задело в свое время больше всего.
>буду делать на английском чтобы выложить на реддит
База. Поделись постом потом, чтобы вручную тебя не ловить.
>>951892
Помню как меня в ПП1 впечатлил откат времени. Поэтому оно стало ключевой фичей моей игры.
>>951925 (OP)
>>951925 (OP)
>>951925 (OP)