Годнота от анона - Для приверженцев опенсорца существует возможность распространять проекты в незапакованном формате. Просто скачай темплейт с оф.сайта и положи экзешник/эльфешник в папку с проектом, этого достаточно. Дополнительно можешь вшить свою иконку в экзешник. После этого, запустившийся файл темплейта обнаружит рядом с собой файл project.godot и начнет грузить проект из него и из файлов, лежащих в распакованном виде в той же директории. - В версии 3.2 появилась возможность прикреплять pck к бинарнику. Бриллиант для любителей однофайлового продукта! - Редактор персонажей на основе makehuman: https://github.com/Lexpartizan/Go_MakeHuman_dot - Тест-бенчмарк: - - Веб-версия - https://govdot.herokuapp.com - - Вишмастер для винды - https://govdot.herokuapp.com/4Anon.rar
>>698054 (OP) > В версии 3.2 появилась возможность прикреплять pck к бинарнику. Бриллиант для любителей однофайлового продукта! Кстати на TWG не сработало, некогда было разбираться почему.
Ебашу сейчас стейтмашину на гдскрипт. Почувствовал, что доразвился до реализации собственной стейтмашины. Состоит она из трёх классов: 1. собственно сама машина (FSM) 2. класс-состояние (state) 3. класс-передача (transition) Все классы наследуются от Reference, то есть, это не ноды и не могут входить в дерево сцены. И разумеется, у них нет коллбэков к мэйнлупу. Машина содержит в себе массив состояний и массив передач. Передача содержит в себе ссылки на состояние-откуда и состояние-куда. Класс-состояние содержит в себе функции start, stop и update. Состояние это базовый класс с пустыми функциями, в си, это был бы абстрактный класс, требующий наследовать от него специализированных потомков с реализацией этих функций. Алгоритм работы таков. У машины есть своя функция update, которая пробегает по массиву состояний, чекает у них внутреннюю переменную mode которая enum { Active, Idle } и у найденных активных выполняет их функцию update. Каждая передача создаётся с обязательным указанием ссылок на состояния, и при своём создании подписывается на их сигналы activated и finished, которые сигналы излучают при переходе из режима в режим. Соответственно, при переходе состояния в idle состояние излучает finished и если в какой либо из передач оно указано состоянием-откуда, оно активирует эту передачу, а она активирует состояние-куда согласно своему режиму либо сразу, либо ждёт, когда то состояние будет idle. Можно запрограммировать машину так, что из одного состояния будет выходить несколько передач к другим состояниям, активируя их одновременно. Это несколько расходится с классическим определением конечного автомата, который должен иметь одно активное состояние в единицу времени, но звучит интригующе. Я предполагаю использовать данную машину, объявляя её переменной, а затем вручную вызывая у неё update там, где мне надо, когда по таймеру, когда в _process. Программирование машины пока что предполагается из кода, без каких бы то ни было визуальных компонентов. Создаются состояния-потомки, реализующие требуемый функционал. Объявляется машина, объявляются состояния, в машину специальной функцией добавляются передачи вместе с состояниями. Стартовому состоянию выставляется режим Active и начинает вызываться update из машины, как описано выше, по требованию. Если всё получится, то следующим шагом прикручу конфигурирование из текстового конфига. В чём вопрос? Спросишь ты. Этот пост скорее минидиздок для себя, чтобы собрать мысли в кучу.
>>698115 И да, я не сильно вникал в твою писанину, но навскидку, вот это: >которая пробегает по массиву состояний, чекает у них внутреннюю переменную mode которая enum { Active, Idle } и у найденных активных выполняет их функцию update. и вот, это: >Можно запрограммировать машину так, что из одного состояния будет выходить несколько передач к другим состояниям, активируя их одновременно. выглядят, как крайне хреновые идеи. ------- >Это несколько расходится с классическим определением конечного автомата, который должен иметь одно активное состояние в единицу времени, но звучит интригующе. Это звучит так, что ты наебешься, когда будешь делать отладку этого франкенштейна. Не трахай себе мозг и делай отдельные стейтмашины.
>>698164 О, спасибо, а я вчера мучительно подбирал русскоязычный термин, так и не подобрал. Код универсален, можно и гонки на нём сделать. >>698165 > хреновые идеи > наебешься Ну а щито поделать, программирование не лишено некоторой доли мазохизма.
Алсо, всё заработало. Пикрелейтед. Доволен как слон. ЧСВ +10
>>698513 2d? 3d? Можно на физике, у rigibody тела можно создать физический материал, там есть bounciness. А само вращение можно задавать какими-то пропертями angular_... Но может быть без импульсов не обойтись будет. Можно и без физики, просто обычный контроллер, только при движении спрайт/меш выставляешь на угол, пропорциональный пройденному расстоянию (чет там на пи поделить). Подпрыгивать, соответственно, так же как прыгают в обычном контроллере вычитая из .y и потом прибавляя гравитацию.
>>698173 > всё заработало Чтобы эта машина не казалась абстрактным экспериментом, приведу пример использования, пиклелейтед класс-состояние, который при его достижении, управляет персонажем с клавиатуры. Можно активировать другие состояния, в которых персонаж управляется компом, в катсценках например, или использовать несколько типов управления (на земле, под водой, в полёте, и т.п.), или реализовать геймплей майнд-контроля, когда вашего персонажа контроллит лич, а вы судорожно стучите по клавише хила, чтобы управление вернулось.
>>698693 Да, я же говорю, тупо забомбил от того, что не могу карточки нормально по столу на рандоме расположить так, чтобы они не пересекались и перегорел, лол. + без понятия как сделать нормально кастомные вызовы функций с передачей туда параметров.
>>698831 > как сделать нормально кастомные вызовы функций с передачей туда параметров Эмм, поподробнее здесь. Я вызывал кастомные параметрические методы несколькими способами. Чаще всего через встроенный механизм .call(), .callv()
>>698831 Я на твг делал карты на сигналах. Правда, толком не доделал. Идея простая - кому надо, тот на те сигналы и подписан. Например, карта может получить сигнал пора лететь в такую-то точку. Начинается анимация, когда анимация закончится, карта получит сигнал об окончании анимации и разошлет сигнал о том, что она на месте. В простых случаях вызывающий код просто ждал по yield(...). В сигнале можно передавать данные. Это может быть массив, или к примеру, словарь. [location:"лес", action:"мамку твою любил"]
>>698863 Все верно. А теперь представим, что для части действий, которые должен сделать пользователь, ты должен передать урон этой же карте, другой, герою, печенью на столе. Меняется только объект. И вот это разделение говнокодом на matchс каким-нибудь текстом из жсона меня выбесило чето.
>>698900 > для части действий, которые должен сделать пользователь, ты должен передать урон этой же карте, другой, герою, печенью на столе Анон выше верно заметил, это делается через сигналы. > это разделение говнокодом на match с каким-нибудь текстом из жсона Возможно, твоя задача более удобно решится через глобальные сигналы. Объясню: делаешь синглтон, в нём объявляешь сигналы. Излучает сигналы только этот синглтон. Объекты, когда им нужно, подписываются на глобальные сигналы своим коллбэком. После чего ты единожды излучив нужный сигнал (signal_hub.emit_signal make_damage(10), будешь уверен, что эта же карта, другая, герой, печенье на столе, обработают глобальный сигнал и нанесут себе урон.
>>698947 Не нужны сигналы. У моего персонажа есть ссылка и на первую карту и на выбранную и на себя. Он вполне может агрегировать внутри себя эту логику. Да и сигналы много кушают, как бы они не были удобны. Нотификациями быстрее.
>>699179 Я уже сам разглядел. Да ещё и хуже, надо вручную дисконнектить. Я думал, этот код юзает встроенный механизм нотификаций, а это просто название в коде.
>>699181 На моём примере. У чувака есть 3 спелла. Первый юзается на себя, второй на героя, третий на комбо карту. Все что они делают - передают дамаг. Причем тут сигналы? Мне надо прокинуть верный референс без заеба, считав из жсона ноду.
>>699198 > считав из жсона ноду Нирикаминдую такой подход, несмотря на то, что он показан в официальной документации (навскидку, в статье по сохранениям игор). Моё мнение - игровые данные (которые считываются из текстовых жсон-файлов) должны быть отделены от внутренней логики движка. Это значит, что никаких нод и путей к нодам в жсон быть не должно. В терминологии жсон объект - это ассоциативный массив, который в терминологии годота - словарь. Вот единственное, что я сериализую и всем рекомендую. Приложения перекидываются между собой словарями. Этого необходимо и достаточно для подавляющего большинства задач.
Если же тебе для поднятия карты, нужно десериализовать ноду, сохранённую в жсон - это, по моему глубокому убеждению, ошибка архитектуры твоего проекта.
>>699210 Есть синглтон-персонаж. У него есть методы взаимодействия с миром. И вот каждая карточка спела несет в себе action_id, который является ссылкой в жссон на такой экшон. В будущем этот жсон сменится на бд. И он такой считывает жсон и вызывает то, что надо.
>>699215 Я знаю. И я по этому сгорел. Как указать одностроково в коде таргет который описан в скролле жсона, чтобы это могли быть разные таргеты. Не ясно.
>>699537 Подойдёт ли тебе метод Пети "Сканера" с ютуба? Он добавляет в проект единственный синглтон для глобальных вещей G - Global. В нём он заводит переменные для сущностей, которые должны быть видимы глобально, например var player : Node, а потом при загрузке сущности игрока, у неё в _ready пишется G.player = self Но этот метод статичный, а у тебя, как я понимаю, таргеты будут динамически появляться и исчезать в течение игры, поэтому я бы попробовал завести словарь, но я подозреваю, что быстродействие такого решения будет медленнее, чем ранее посоветованный способ с сигналами. Потому что хоть хэш, хоть хуэш - поиск таргетов будет происходить по строковым ключам.
Я сам не уважаю этот модный молодёжный подход, когда части приложения обмениваются между собой строковыми идентификаторами. Как серпом по яйцам, когда вижу emit_signal("string_signal_name"). Зумеры уверяли меня неоднократно, что строки в современных средах исполнения хэшируются и их быстродействие якобы не отличается от именованных целочисленных констант. Но я во первых не проверял, а во вторых всё равно хочется emit_signal(INT_SIGNAL_CONSTANT)
>>699556 >Зумеры уверяли меня неоднократно, что строки в современных средах исполнения хэшируются и их быстродействие якобы не отличается от именованных целочисленных констант. Я хз, но я не нашел (может плохо искал) описания того как это реализовано в годоте. Зная гений Хуана, там вполне может быть обычная цепочка "ссылка-длина-побайтово" >>699556 Но я во первых не проверял, а во вторых всё равно хочется emit_signal(INT_SIGNAL_CONSTANT) Вот да, я бы тоже не отказался от возможности присваивать объектам обычные человеческие числовые статические ID
>>699556 >Подойдёт ли тебе метод Пети "Сканера" с ютуба? Он добавляет в проект единственный синглтон для глобальных вещей G - Global. В нём он заводит переменные для сущностей, которые должны быть видимы глобально, например var player : Node, а потом при загрузке сущности игрока, у неё в _ready пишется G.player = self Жесть, как же это плохо выглядит.
>>699580 Вовсе да. Метод Пети жоска абузит принцип инкапсуляции. В глобальном объекте прямые ссылки на разные части программы. Какая уж тут инкапсуляция когда всем всё видно? Сначала возможность напрямую обращаться к игровому персу, неписям, сундукам на сцене выглядит заманчиво, но потом наступит путаница и пиздец. Неизбежно наступит путаница и обязательно придёт пиздец. Гораздо корректнее выглядит описанный выше принцип глобальных сигналов. Игровым объектам всё так же нужно у себя в _ready обращаться к глобальному объекту, но в этом случае они не оставляют там прямую ссылку на себя, а регистрируются на глобальные сигналы. Глобальный объект может дёргать эти сигналы, но ни он, ни другие объекты не могут обратиться к получателям сигналов напрямую. Я настолько глубоко изучил данную тему, что даже научился возвращать данные с излученных сигналов. Просто регистрируешь сигнал с аргументом и следуешь соглашению о том, что аргументом должен быть словарь, в который все зарегистрированные на сигнал обработчики добавляют запись о результатах своей работы. Например, в глобальном объекте: signal query_something(query_result) #Пока что язык не позволяет задекларировать в аргументе статический тип, увы.
>>698900 > А теперь представим, что для части действий, которые должен сделать пользователь, ты должен передать урон этой же карте, другой, герою, печенью на столе. Меняется только объект. И вот это разделение говнокодом на matchс каким-нибудь текстом из жсона меня выбесило чето. >>699198 > У чувака есть 3 спелла. Первый юзается на себя, второй на героя, третий на комбо карту. Все что они делают — передают дамаг. Причем тут сигналы? Мне надо прокинуть верный референс без заеба, считав из жсона ноду. > Причем тут сигналы? Я всё больше убеждаюсь, что именно сигналы здесь притом и к месту. >>698997 > Да и сигналы много кушают, как бы они не были удобны. Нотификациями быстрее. Я так и не увидел примера твоей работы с нотификациями. Я бы освоил эту подсистему. Если конечно имеются ввиду те самые нотификации, которые идут через _notification(what)
>>699670 Сигналы нужны, когда я хочу десятку неизвестных сказать - вперед/назад/стань красным, на какое-то событие. А когда у меня четкое ограниченное число лиц, на которых я имею референс, тогда не надо. Вопрос только в том, как использовать референс адекватно.
Но спорить об этом без смыслено. Давай на практике.
Есть dict спелов. var mayspelldict = { 0: {"name":"damage spell", "damage":5, "func":"hello_world"}} Как заставить пикачу юзнуть это на всех/одного себя/вызвавшего и т.п.?
>>699741 Если у тебя есть референсы на все нужные тебе объекты, то наиболее адекватным решением будет вызывать у требуемых тебе объектов нужный метод. И всё.
Практически это означает, что у тебя есть скажем, несколько объектов, которые реализуют интерфейс "ПринимательСпеллов" (разумеется, в гдскрипте нет интерфейсов и возможности объектами указанный интерфейс реализовывать, потому в гдскрипте, это всё следует сделать ручками). Допустим, принимателями спеллов у нас являются сами карты, игроки, игровой стол. Как у принимателей спеллов у любого из них есть созданный тобою лично метод .accept_spell(spell_data : Dictionary)
Таким образом, наш пикачу, когда ему необходимо, берёт имеющиеся у него референсы, согласно игровым правилам, и пишет:
Ну а приниматели спеллов у себя в вышеуказанном методе применяют полученный из аргумента спелл на себя. Разумеется, проверяя, что в метод прилетел спелл, а не словарь с прогнозом погоды в Мозамбике. Парсить словарь придётся в любом случае.
Есть ещё вот такой вариант, тоже с серпояйцевыми стрингами: call_group("spell_acceptors", "accept_spell", myspelldict[0]) В этом варианте роль интерфейсов частично берут на себя группы. Включая объект в группу, ты "должен" позаботиться, чтобы в нём были реализованы методы, которые ты потом будешь дёргать через call_group.
Если хочется кодить нормально, с соблюдением парадигм и паттернов, чтобы классы принудительно реализовали интерфейсы, чтобы данные между инстансами передавались по числовым ключам, минуя явные и неявные преобразования в строки, то тогда рекомендую заюзать годот-шарп и кодить всю ключевую логику на шарпе. А уж мелочи вроде загрузить/выгрузить, показать/скрыть/задать-цвет-прозрачность - на гдскрипте.
>>699741 Для простоты проверки можно типизировать данные отдельным ключом в словаре: var mayspelldict = { 0: {"type" : "spell", "name":"damage spell", "damage":5, "func":"hello_world"}}
После чего, кастуем спелл на имеющиеся референсы: ref1.accept_spell(myspelldict[0])
После чего объекты по референсам у себя в методе делают так: func accept_spell(spell_data : Dictionary): ___ if !spell_data or !(spell_data.has("type") and spell_data.type == "spell"): return Этим условиями мы убедились, что в аргумент прилетел строго типизированный спелл, в котором точно есть name:String, damage:int, func:String и далее можем не выполнять утомительные перепроверки, но в случае, если юзеры залезут шаловливыми пальчиками в наши файлы данных (юзеры даже в БД смогут залезть через сторонние утилиты, даже зашифрованные данные расшифруют), то наша игора будет падать как тот скайрим, крошиться на десктоп после каждого чиха. Поэтому тут решай сам: удобство сейчас или головняк с саппортом потом.
Парни, подскажите пожалуйста, как в годоте сделать диалоги с вариантами ответов?
Мне надо чтобы были скилл-чеки и эквип-чеки (это когда у гироя на поясе весит легендарный ибанитовый меч +2 к ловкости и он может в диалогах поугражать что дастанет мечь и уебет).
>>699961 В треде тут обычно все свои велосипедят. Что такое варианты ответа? Это кнопки какого то вида (не обязательно кнопки, может быть спрайты). Они собираются в список, например в VBoxContainer. Тут я вижу два варианта. Первый - набирать список по пунктам в коде, например из какого-то массива вариантов ответа. И по условию не добавлять твой пункт, если меча нет. Второй - наоборот, накидать сразу все возможные ответы, а отсутствующие по условию скрывать. В реале, там будет не массив, а скорее какой то словарь.
>>700018 Это объявление функции. В скобках - параметры, которая она принимает. Пример из математики - функция синус принимает параметром угол. При вызове функции эти параметры будут заполнены значениями. Вызов смотри в 16 строчке.
>>699821 Бля, о принимателе спелов я не подумал. Годная страта. А что скажешь о расположении объектов на местности в генерирующемся случайном/псевдослучайной порядке, но при этом объект не должен наслаиваться на другой обьект?
>>700026 Откуда этот параметр будет браться? Переменная input_vector в нескольких функциях задействуется. Или в скобках ничего общего с переменной не имеет?
>>700060 Для того, чтобы функция работала с тем, что ей передали. А не с оригинальной переменной. Например, на тело действует ветер, и ты вызываешь с другой переменной apply_horizontal_force(input_vector, delta) apply_horizontal_force(wind_vector, delta)
Если тебя смущает совпадение имени, то просто переименуй.
>>700062 Ну смотри - как бы ты написал функцию возведения в квадрат? Она получает параметр и возвращает значение. func square(x): return x*x
Этот x определен как псевдо-переменная внутри функции. Ты можешь вызывать эту функцию square(2) #вернет 4 var x = 3 #завели переменную x square(5) #вернет 25, потому что ВНУТРИ функции x означает по прежнему то, что в нее передали, а не этот новый x
Сап годотач. Делаем кликер и не знаем как заставить лэйбел прибавлять и отображать кол-во очков, по нажатию на кнопку. Скрин с кодом предоставил Гугл ответов не дал
>>700181 Все правильно, но надо подкчлючить сигнал. Либо из UI редактора (справа вкладка Узел, рядом с Инспектором) Либо из кода: $Button.connect("pressed", self, "_on_Button_pressed")
>>700054 Накинь на объекты дополнительную area и пусть генератор перед тем, как выставить следующий объект, проверяет нет ли в сгенерированном месте чьих-либо area, если есть - значит будет наслоение, значит надо сгенерировать другую точку.
>>700321 Нормаль столкновения физический сервер возвращает. Согласно направлению нормали можешь посчитать с какой стороны столкновение и теоретически определить подходящую грань.
>>700323 >конкурента Ты бы своей кпыше крикнул остановится. Какой конкурент, он в каждом видео говорит о точ, что сам учится и не является последней инстанцией и внезапно оказался прав о том что рускоязычных полных туторов по годоту на ютубе нет. Если у тебя есть примеры опровергающие это, то почему они не в шапке?
>>700336 Точка - это просто координата в пространстве, она так же не помогает узнать грань. А шейп-индексы действительно "какие-то", это если у тебя несколько коллизий на одном объекте. Ты же понимаешь, что я сначала все это почитал а потом перепробовал. Пришлось написать свой tool скрипт который дублирует геометрию и строит ареа и коллижншейпы, но это же костыль оверхедный.
>>700337 Давай зайдём с другой стороны. Какую вообще задачу ты решаешь?
(просто я сейчас после твоих слов о тулскриптах почувствовал главную болезнь форумов, когда приходит пользователь, который поставил себе задачу, начал её решать неправильно и уже после этого обратился на форум за советом, как ему заставить работать своё неправильное решение)
>>700351 Это уже для следующего этапа, когда я захочу модифицировать полигон. Сначала мне надо узнать, какой именно полигон столкнулся. Представь себе следующую ситуацию - игрок кидает нож во врага. Я хочу чтобы мигнул тот полигон в который он попал. Движок эту инфу судя по всему не пробрасывает https://github.com/godotengine/godot/issues/684 Поэтому я решил временно написав тул, который создает для каждого треугольника меша area, который уже сможет отозваться на рейкаст. Видимо без с++ никак.
Итак, вот мои результаты исследования стейтмашин. Я написал две.
Первая по принципам ООП, стейты - это классы, транзишоны - классы. Стейты наследуешь от базового стейта из комплекта поставки и таким образом программируешь машину. Транзишоны у себя в инит принимают обязательными параметрами стейт-откуда и стейт-куда и подписываются на сигнал "завершен" у стейта-откуда. Таким образом переходы работают автоматически по сигналам стейтов. Узнать текущий стейт машины возможно, опросив список её стейтов на предмет активированности, что выглядит тупо. Если неправильно запрограммировать логику, возможна одновременная активация нескольких стейтов, для чего в транзишоны введены режимы на манер искаробочной анимационной стейтмашины (немедленно, ждать начала, ждать конца), но это тоже тупенько.
Вторая по олдовым дидовским императивным принципам. Стейты - это текстовый конфиг (жсон), преобразующийся в словарь. Каждый конкретный стейт - тоже словарь, имеющий имя-ключ, имеющий поле некст с именем следующего стейта, имеющий поля с именами функций, которые должны быть вызваны при старте, при апдейте, при стопе. Вызваны у кого? - Сама машина у себя в ините принимает обязательным параметром ссылку на объект-процессор, в котором предполагается наличие функций из вышеуказанного конфига. Без валидного инстанса процессора - работать отказывается с сообщением об ошибке. Процессором может быть сама нода, создающая стейтмашину, сторонний скрипт, да хоть глобальный синглтон, здесь ограничений нет. Получить текущий стейт можно просто прочитав текстовую переменную куррент_стейт. Внутри машины специальная функция умно парсит поданный при ините словарь стейтов на предмет наличия опций и соответствие их процессору и грамотно вызывает функции через искаробочный метод колл(). Таким образом машина может быть естественным (для годоскрипта) образом интегрирована куда угодно. Самый главный её минус - работа с текстом, горы текста, тысячи их!
Я просмотрел имеющиеся в наличии стейтмашины на ассетлибе и выяснил, что они в том или ином виде относятся к одному из двух вышеописанных типов. При этом они тянутся со времён 3.0, в них перемешивается старый синтаксис с новым. И в общем-то, ассеты, они и тут ассеты - работать с ними непривычно, неудобно, демотивирующе.
Продолжу изыскания, попробую совместить оба принципа.
>>701031 Мой дидовский подход к стейтмашинам выглядит очень просто. Смущают строки или классы? Идут нахуй - стейты это просто enum интов. Смущают косяки в транзишнах? Транзишны идут нахуй, все возможные переходы описаны в обработчике конкретного стейта через switch (или match), для необрабатываемых в default вывод ошибки.
>>701042 Это говно теоретически исправляется разделением логики и данных. В твоём случае логика включения стейта пытается смешаться с данными о предыдущем стейте. Значит надо добавить в класс данные, набор флагов, включаемых стейтами и при старте стейтов смотреть не на предыдущий стейт, а на интересующие конкретно этот стейт флаги.
И разумеется, поскольку флаги - это данные, они с лёгкостью вынесутся из класса в БД, потом, на стадии оптимизации.
>>701378 В одиночку ты не сможешь запилить реалистичный графониум уровня трипл-эй. Получится какое-нибудь корявое ассетоговно уровня 35мм. Поэтому как ни крути - нужно делать упор на стиль и геймплей. Стилизованный графон может быть пиксельный, может быть под первую плойку, или сингл-колор-лоу-поли.
>>701382 Какой у тебя опыт? Про арт ничего не скажу. Если умеешь кодить, механики тут пишутся за неделю (а может быть есть и пример игры с исходниками - не помню попадались ли такие), но если не знаешь - прибавь пару месяцев на изучение языков программирования и прохождение туториалов конкретно по top-down rpg и менюшкам в стиле ВНок.
>>701394 Ну вот для интерфейса то как раз во-первых есть искаробочный гуй с кастомизацией тем, потом есть 9-patch rect, и в конце концов для диалогов-инвентарей есть хоть какие то ассетики.
>>701425 Так в скинутой игре логики почти не наблюдается (один раз двигается ящик по принципу сокобана и 1 раз вводится число в кодовый замок), в остальном это просто зашел в ареа-сработал триггер, логику топ-даун бродилки можно найти в туторах за указанную неделю, а логика ассетов-диалогов будет работать из коробки, или ты про общую логику типа завести переменные-флаги- isHauntedHouseVisited, isNpcBartenderKnowsAboutGhost?
Запилил генератор херни через surface tool Но вообще не понимаю, как к этому объекту прилепить UV развёртку и повесить текстуру. По сути надо лишь развернуть планарной проекцией с видом сверху и на неё назначить текстуру Но я вообще не пойму - через что это можно сделать?
3 часа назад релизнулась бета 0.3.1 тайлового редактор LEd https://github.com/deepnight/led/releases/ Его пишет автор dead cells, которому надоели неудобные редакторы. Фишка редактора в автотайлинге - задаешь правила, какие тайлы могут появляться слева, с краю, сверху от каких - и просто рисуешь кистью по карте, а он все расставляет. В чем магический эффект? Вот этот ассет годота позволяет импотировать файлы редактора Tiled .tmx https://godotengine.org/asset-library/asset/158 А LEd 0.3.1 научился экспортировать в этот формат, если поставить галочку. Таким образом, практически в два клика получаем в Годоте то, что рисуем в LEd. Из замеченных косяков - при экспорте правила применяются в обратном порядке - поэтому при финальном экспорте надо будет переставить их (думаю быстро поправят), во-вторых расставленные объекты (враги, паверапы) промахнулись на 1 клетку вниз, в-третьих не нашел куда деваются кастомные проперти (если им там задавать здоровье, лут и т.д.) Мржет быть кому то понравится.
>>701913 А, еще минус - там пока нет полигонных коллизий - под скосы и склоны. Вообще, по-моему там вообще нет коллизий - просто один из слоев данных можно трактовать как поклеточные коллизии.
>>701913 > кастомные проперти (если им там задавать здоровье, лут и т.д.) Обесни вот это, плиз. Что это, можно делать игру прямо в тайл-редакторе, без кодинга?
>>701919 В самом редакторе заявляется вот такой пример использования. Как ты потом распорядишься данными в игре - дело за тобой. В принципе можно представить себе следующий воркфлоу - программист пишет логику, а предметы уже раздает дизайнер, главное чтобы называл их по ожидаемой кодом схеме.
>>701913 >во-вторых расставленные объекты (враги, паверапы) промахнулись на 1 клетку вниз, Ха, я знаю как это поправить. Там в плагине всего в одной строке надо true/false переключиь. Доберусь до компа - посмотрю и отпишусь где.
>>701913 >во-вторых расставленные объекты (враги, паверапы) промахнулись на 1 клетку вниз >>701948 >Ха, я знаю как это поправить. Там в плагине всего в одной строке надо true/false переключиь. Доберусь до компа - посмотрю и отпишусь где. Добрался, отписываюсь. Плагин писался еще под версию годота 3.1, а там был косяк со сдвигом объектов в тайлмапах. В плагине добавили костыль для его обхода. В 3.2 косяк исправили, а в плагине костыль не отключили. ------- Короче. В каталоге с проектом где используется плагин, находишь вот этот файл: addons/vren.tiled_importer/tiled_import_plugin.gd в нем находишь строку: options.apply_offset = true и меняешь значение на false. И все должно быть нормально.
Неспешно перекатываюсь на сишарп На гдскрипте ждать следующий кадр будет так yield(get_tree(), "idle_frame") В C# нашел такое: await ToSignal(this, "idle_frame"); Но требует чтобы я пометил функцию async. А тогда же покрасятся все функции откуда и куда вызовы, то есть всю программу что ли придется делать async? Или я переусложняю.
>>702089 Придется посмотреть попозже, просто функционал один и тот же, думал одной строчкой получится сделать.
На самом деле похоже столкнулся с особенностью таймлайна анимейшн плеера - хоть события и нанесены в одну точку, но сработать могут не одновременно, в моем случае смена кадра анимации и смена оффсета спрайта привели к промигиванию (кадр менялся но скакал в другую точку и потом возвращался обратно)
>>702163 Есть такое понятие как хиральность. Это когда есть два вида одинакового объекта, только различающихся зеркально, оптические изомеры в общем. И вот такая проблема - молекулы разной хиральности не подходят друг к другу. Не встраиваются в организм. Был такой случай, когда от лекарства Талидамид много выкидышей было. Так вот это я к чему веду. Если у тебя что-то не получилось в Годоте - есть неиллюзорный шанс, что проблема в тебе. Что ты ему не подходишь, потому что у тебя руки не той хиральности вырасли.
Если кто пользовался C# - API годота никогда не кидает исключения, только возвращает коды ошибки как в GDScript? Речь не про то что куда-то передал Null
https://2ch.hk/news/res/8465940.html#8466083 >Это те которые ничего не разрабатывали в своей жизни? Как я люблю их называть "Годот разработчики" Вот это остряк. Но впринципе верно подметил.
>>702813 У меня такое бывает, когда я качаю ассеты из ассетстора, там какого-то хуя часть ассетов, по видимому какими-то гитхабовскими алгоритмами преобразует табы в двухпробельные отступы (или авторы этих проблемных ассетов за каким-то хуем настраивают двухпробельные отступы у себя в проектах). После чего годот пытается автоматически заменить уже 4 по его дефолту пробела, после чего код всирается, и если код длинен и сложен, то хуй ты уже восстановишь оригинал.
Костыльное и неудобное решение в таком случае, чтобы не портить свой код, создать отдельный проект, в его настройках выставить отступ в два пробела, скачать туда проблемный ассет, компильнуть проект один раз, чтобы годот заменил там по два каждых пробела на табы, после чего скопировать файлы ассета в рабочий проект.
Но воще это серьёзная проблема и надо создавать ишью. Но мне впадлу.
>>702813 Двачую табы vs пробелы. Отступы работают так: Все строки одного блока кода должны быть на одинаковых отступах. Они делаются табами. Например func somefun(): [tab]var x = 0 #эта [tab]call1(x) #и эта [tab]if x == 0: #и эта на одном уровне [tab][tab]x = 1 #а этот вложенный блок [tab][tab]call2(x) #на втором [tab]x = 3 #вернулись на первый [tab] call3(x) # ошибка - лишний пробел
>>702813 А вообще, немношк покрутил опции, попробуй вот эту опцию отключить, пикрелейтед:
... И вот этот совет следует пофиксить, так как настройки редактора глобальны для всех проектов, то: >>702814 > создать отдельный проект > настроить вооще редактор на двухпробельный таб с выставленной конвертацией при сохранении > скачать двухпробельный ассет > сохранить > сбросить настройки вооще редактора на 4-пробельный таб > перекинуть файлы > ПРОФИТ
(А ищью Хуану надо закинуть следующего содержания: В файлы .gd следует добавить нечитаемую редактором, ну или содержащуюся в комментарии а-ля xml мета-инфу, содержащую как минимум, сколько пробелов следует рассматривать в данном скрипте как один таб. Закиньте, годаны.) > #!tab:4!# > extends Node > > func _ready(): pass
>>702817 > попробуй вот эту опцию отключить После этого, разумеется, придётся перекачать заново все испорченные автоконвертацией ассеты с заменой gd-скриптов.
>>702851 Майкрософтовская студия традиционно сама автоматически формирует отступы блоков, ещё с 90х, а может с 80х. Так же поступают все уважаемые ИДЕ, от дельфи до райдера. Так что визуально разницы нет, только кроме отступов у тебя ещё скобачьки сверху-снизу для сиподобных, бегин-энд для паскальподобных, энд %операторнейм% для бейсика, торобоан ротарепо для шеллскрипта. Именно это легло в основу философии питона: "Если отступы и так ставят почти все (кроме школокульхацкеров с их кодом в одну строку), то чобы не сделать отступы синтаксическим элементом?" Так был рождён питон, бейсик 21 века.
>>702860 >Если отступы и так ставят почти все, то чобы не сделать отступы синтаксическим элементом? Это и есть главный фейл. Rак раз на днях искал пару часов баг, из-за поехавшего при копи пасте отступа в if.
>>702860 >Так что визуально разницы нет, только кроме отступов у тебя ещё скобачьки сверху-снизу для сиподобных, бегин-энд для паскальподобных, энд %операторнейм% для бейсика, торобоан ротарепо для шеллскрипта. Весь финт в том, что в этих языках ситуация "удалил пару пробелов в начале строки - программе пиздец", в принципе невозможна. Ты можешь вообще удалить все пробелы/табы в начале всех строк и код будет работать точно так же без изменений. Может быть его будет не так удобно читать, но работать он все равно будет. А вот у питухона, даже обычное действие сохранить-закрыть-открыть файл уже может похерить программу, если редактор в котором ты это делал, решит, что табы должны быть в 2 пробела, а не 4. А выкрики вроде, "код все равно открывают только в специализированных IDE где все настроено" идут нахуй, т.к. это просто не соответствует реальному положению вещей. Та же шняга с гитхабом все это показывает.
>Именно это легло в основу философии питона: "Если отступы и так ставят почти все (кроме школокульхацкеров с их кодом в одну строку), то чобы не сделать отступы синтаксическим элементом?" Их проблема не в том, что они сделали отступы элементом синтаксиса, а то как они это сделали. Можно было взять любой другой символ, кроме пробела/таба и использовать его как отступ. Да даже сраное подчеркивание или точку, либо вообще свой выдумать. Тогда путаницы в принципе бы не было, т.к. при открытии в специальных питухонских IDE их можно было бы отображать как пробелы, а в любых других это были бы символы, которые ни человек, ни IDE-шка не спутает по случайности с пробелом/табом и не похерит листинг. >>702860 >Так был рождён питон, бейсик 21 века. Тру стори. И лет через 20 в учебниках про питон будут писать то же самое, что и про бейсик сейчас (вкатиться легко, но станешь калекой от программирования)
>>702865 > Это и есть главный фейл. На вкус и цвет товарищей нет. Вон выше по треду ОП обеснил, как решается проблема с отступами всего одной галочкой в настройках. >>702871 > И лет через 20 в учебниках про питон будут писать то же самое, что и про бейсик сейчас (вкатиться легко, но станешь калекой от программирования) Ну ХЗ, будем посмотреть. В отличие от своего духовного отца, питон таки вкатился в большой продакшон, на ём нейроночки пишут, например. И ничо, калеками не становятся. И с отступами проблем не имеют.
>>702874 Ты вообще ерунду пишешь. >В отличие от своего духовного отца, питон таки вкатился в большой продакшон Бейсик был повсеместно в большом продакшне (в винде настройки тыкал когда нибудь? А там vbs скрипты, ага) >на ём нейроночки пишут Никто не пишет на нем нейроночки. На нем пишут конфиги к нейроночкам, а тот же numpy это Си. >калеками не становятся Становятся, становятся. Большинство ученых очень хуевые программисты. > И с отступами проблем не имеют. Конечно не имеют - это же не программа, а просто линейный конфиг.
>>702874 >На вкус и цвет товарищей нет. Вон выше по треду ОП обеснил, как решается проблема с отступами всего одной галочкой в настройках. Ага, а потом еще не забудь вернуть галочку обратно, а то другой проект по пизде разъедется. Да и вообще попробуй угадай, а нужно ли конкретно для этого исходника ее включать или нет. Ну и пиздецовые ситуации, когда ты случайно, стер отступ и у тебя инструкция выскочила за пределы if-а или цикла и все продолжает работать, но совсем не так как должно, и хуй ты это отследишь. Нахуй такие фломастеры.
>>702875 Поддвачну, все либы для машоба типа tensorflow - это высокопроизводительный многопоточный код на плюсах/сишке. Питон нужен только для того, чтобы дата саентист (это ученый, математик, аналитик, а не программист) сформировал конфиг для этих нейроночек и запустил процесс обработки, дальше работает уже плюсовый код, заслуги питона в этом нет никакой, он нужен только для того, чтобы этот аналитик по быстрому накидал конфиг и получил результат без необходимости разбираться с плюсами/конпелять нативный код. Ровно как и никакого программерского скилла для этого не нужно - надо знать математику, статистику, теорию вероятности, свою предметную область, никакого программирования как такового при этом не осуществляется. >>702874 >большой продакшен >нейроночки И правда ерунду пишешь. "Нейроночки" это не большой продакшен, а скриптики на 100, 200, в редких случаях больше строк. Задача этих скриптов - взять данные, прогнать через сконфигуренную нейронку, сохранить/отдать другому сервису результат. Всё. Там кода и бизнес-логики как таковой нет. А большой продакшен - это джава, .net, плюсы, там нет места слаботипизированным языкам.
Вот, кароч, чел предлагает свой метод борьбы с отступами https://habr.com/ru/post/501538/ статья про питон, но рассмотренные методы подходят и к гдскрипту. Самое интересное, как водится, в комментах.
>>702889 Ты просто думаешь что раз они разбираются в матане или физике то и кодинг у них на уровне Александреску. Но это далеко не так. И это ты еще не видел как они хуево Вордом пользуются.
>>702892 Шедеврально. Питухонист по факту изобрел для питона аналог скобочек в других языках. И стоила ебля с отступами того, чтобы вернутся, к тому от чего отказались?
>>702860 >Именно это легло в основу философии питона: "Если отступы и так ставят почти все (кроме школокульхацкеров с их кодом в одну строку), то чтобы не сделать отступы синтаксическим элементом?" Мне кажется, авторы этой идеи так и не поняли, что отступы и скобочки нужны для разного. Отступы это удобный инструмент улучшения читаемости, но ужасно неудобный элемент синтаксиса. Скобочки это отличный и вполне естественный элемент синтаксиса, но читаемость они засоряют. Но если выбирать между языками со скобочками без отступов и с отступами без скобочек, я выберу первый. Потому что код пишут всё-таки для компиляторов, а не для людей. Всё сказал.
>>703060 Он работает в том режиме, который выставлен в правом верхнем углу. Емнип есть какая то настройка в домашней директории Или ты просто можешь поменять текстовым редактором в файле проекта, который открываешь. Пишу по памяти, не за компом.
>>703062 То есть если у проекта gles2, то у самого редактора тоже становится gles2? Ясненько, ну тогда intel-дрова для линупса не очень хорошо дружат и с gles2 и с gles3 godot-ом, что печаль.
>>703065 > не очень хорошо дружат А если использовать открытые дрова линукса? У меня искаробочный драйвер убунты поддерживал глес2. Потом я всё равно проприетарный поставил на свою ПЕЧ.
>>703066 Так интел вроде сам и выпускает только открытые дрова, а не как нвидия где есть и открытые и закрытые. Причем смешно, то что при этом блендер на винде работал как говно, а под линем летает. Так что на обоих системах пайплайн мой сломан.
>>702817 Спасибо, попробую. >>702851 >Блин, как же хорошо, что я слез с иглы питоновсратого гдскрипта и пересел на лицо сишарпа Так как я изучал его тоже, попробовал настроить, но как понял, это жутко геморойно и проще писать на гдскрипте и не выёживаться.
>>703074 > жутко геморойно и проще писать на гдскрипте и не выёживаться Вопрос привычки. Я сам тоже не смог привыкнуть именно к связке шарпа с годотом, хотя сам шарп понравился и просто на формсах я чота своё мелкое пописываю. Но люди есть, которые на шарп перешли, наш анон выше по треду, и вообще куча народу, даже на ютубе есть блогер, который пилит серию туториалов по годот-шарпу. https://www.youtube.com/watch?v=ra-BJ-fJ6Qo
>>703074 >Так как я изучал его тоже, попробовал настроить, но как понял, это жутко геморойно и проще писать на гдскрипте и не выёживаться. Нет там ничего геморойного. Все на изи.
>>703078 Недавно переехал на C#, настроено примерно как на видео, только другой плагин в vs code (C# Tools for Godot) Примерный сетап: Моно и .Net Core 3.1 - не знаю что из этого нужно, ставил полгода назад vs code + плагины C#, Mono Debug, C# Tools for Godot, прикручиваю Roslynator для линтера (через StyleCop(Omnisharp)) В папке проекта настроены .vscode/launch.json и tasks.json по образцу коммента под видео. Таким образом, запуск по F5 настроен на Attach, у которого предварительным таском прописан запуск Годота В Годоте в настройках проекта убрана галочка wait for debugger, а в настройках редактора - внешним редактором прописан vs code с флагами {project} --goto {file}:{line}:{col} Автодополнение работает учитывая текущую выбранную сцену в редакторе Годота (т.е. если редактируешь Player.cs и отрыта Player.tscn, то дополнение есть, а если Level.tscn - то нет) GD.Print срет в терминал VS Code. Работают брейкпоинты, просмотр переменных, стек вызовов.
>>703084 > предварительным таском прописан запуск Годота Вот этого не понел, когда смотрел видосы по этим плагинам и тулзам. Редактор всегда запущен же. По крайней мере у меня. Я ж там собственно сцены редактирую.
>>703090 >>703088 Сейчас проверил с закрытым редактором - если в task не указать путь до бинарника, то ничего не запускается. А если указать, то запускается только рантайм с игрой (не редактор). И уже к нему аттачится дебаггер.
>>703327 > Я сам без уроков делаю, внутренней документации достаточно. Удваиваю. Видеоуроки - чисто как развлечение. С говнокода поугарать, с картавости и/или всратости ютубера. Покекать в комментах. Ну а потом опять за работу.
>>703373 И поддержу, и не соглашусь. Для меня, как вообще не программиста, видеоуроки оказались хорошим стартом, чтобы увидеть, как вообще на этом творят настоящие живые люди. Но дальше - только доки, потому что в них проще найти ответы на бесконечно подкидываемые моим воображением вопросы "а можно ли сделать вот так". Если уж совсем не нахожу ответа, спрашиваю тут в тредике, пару раз получал довольно неожиданные советы, которые в итоге реализовывал.
>>703376 Для старта - всё верно, ютуб помогает. Но потом наступает момент, когда ты перерастаешь уровень ютуб-учителей, видишь, что они делают упрощённые проекты для новичков, пишут упрощённый код для новичков, понимаешь, что ничего нового в течение следующих N минут видоса ты не узнаешь.
>>703293 Как вариант могу предложить изучать туториалы по GDScript и отдельно уроки по C#. Ведь алгоритм можно воспроизвести практически построчно. (единственное что я так и не придумал как заменить однострочник yield(get_tree().create_timer(1.0), "timeout")
>>704384 Я имел в виду скрытые по visible=false Сейчас чекнул, там почти не жрут, в пределах погрешности. На время разработки пойдет. Просто так вышло, что я импортировал все уровни отдельными слоями.
В общем, анончик спрашивал как делать по быстрому логические игры. Я не очень понял, интересует его 2д или 3д. Но неважно. Для 2д в Годоте есть TileMap, а для 3д - GridMap. Соответственно в случае 2д мы закидываем в папку проекта картинку с фигурами. (или по одной). Потом в тайлмапе создаем тайлсет, в нем добавляем атлас на эту картинку. Все, с этого момента можно работать с тайлмапом просто как с двухмерным массивом. В 3д примерно так же, создаем GridMap, закидываем модельки фигур в папку (лучше по одной), создаем новую сцену закидываем все фигурки в новую сцену, конвертируем и сохраняем ее как библиотеку тайлов (meshlib), возможно тут захочется поменять моделькам материалы. Все, опять можем работать как с 3д массивом. Надо добавить само поле - это можно сделать хоть тупо сделав бокс, на который натянуть текстуру в клеточку. Другой подход будет заключаться в, например, создании сцены-объекта для фигур. В него кидаем все виды фигур и пишем простенький скрипт, который делает только одну из них видимой. Эти объекты можно расставлять по игровому уровню. Если ты включишь режим snap, то и расставляться они будут по сетке. Но тебе уже придется самому вычислять их координаты потом. Но в принципе ничего сложного, особенно если ты сделаешь их с шагом 1. Для выделения и перемещения фигур код придется спиздить, ну или если надо я потом с ним могу помочь. Менюшки рисуются довольно просто и быстро, накидываешь на сцену лейблы, кнопки, по вкусу задаешь им визуальные стили покрасивее, шрифты, все это надо сначала закинуть в проект. И добавляешь обработчики нажатий. Если что то будет не понятно - спрашивай, тут всегда ответят.
Привет анон! В ньюфаня треде задал вопрос, мол, без программирования реально художнику сделать хоть что-нибудь - желательно с мультиплеером На мои глупые маняфантазии пришло 2 серьезных ответа - годот и юнити (плеймейкер + фотон для мультика) Спрошу пожалуй тут - как считаешь, что лучше мне подойдет? Годот кажется мне лучше ибо он насколько я понял полностью бесплатный, а на юнити придётся скрабить этот самый плеймейкер ибо платить за него деньги ради мелкого хобби я не желаю Но вдруг у тебя есть доводы/аргументы за и против, был бы очень рад их послушать
>>705431 Без программирования вряд ли выйдет. Визуал скрипт это то же замаскированное программирование. Завтра могу подробнее, сейчас уже сплю. Если хочешь можешь почитать в прошлом треде в конце. >>697739 → >>697740 → >>697741 → Мультиплеер думаю без программирования тоже не выйдет. Хотя примеры есть, надо смотреть. В принципе есть какой то ассет который тупо реплицирует положение объекта с сервера на клиент.
>>705431 >Привет анон! В ньюфаня треде задал вопрос, мол, без программирования реально художнику сделать хоть что-нибудь - желательно с мультиплеером А реально ли программисту без рисования сделать графон для своей игры? Технически реально, практически - говно на выходе. Программировать все равно придется. Так что либо кооперируйся с кем-нибудь, либо сам изучай кодинг. Как показывает опыт научить художника минимальным скилам программирования намного легче, чем программиста рисованию.
>>705444 > научить художника минимальным скилам программирования намного легче, чем программиста рисованию Вот с этого больше всего горит. Особенно, когда художники жалуются > кококодинг этоо таак слоожно! Кодинг - это сложно, но намного легче вкатиться в кодинг с нуля, чем в рисование с нуля. Я рисую уже джва года и до сих пор нихуя не получается. За эти джва года я освоил две новые парадигмы в кодинге и выучил два новых языка. Был бы я художником. Эх, были бы у бабушки яйца, а у дедушки сиськи...
>>705524 Представь себе что у них другая половина лучше развита - и у них то же самое, они могут за джва года освоить пару техник рисования задрочить там свето тень и анатомию, и не быть в состоянии написать что то сложнее if.
Основная суть художника - запрограммировать у себя в голове встроенный RTX.
По этой причине у личинусов на уроках ИЗО первому чему учат - это нахуярить на листе бумаги кубики пирамидки и прочие шарики и сделать с помощью того же карандаша им PBR.
Потом уже идет надроч силуэта и в ход идут те самые кружки с последующим усложнением формы силуэта
>>705542 Представляю и теряю сознание. >>705543 Дрочил квадраты. Только квадраты и могу обсветотенить. Шары уже всё - не дрочатся. О чём-то большем речи не идёт.
Кто-нибудь реализовывал шаблон MVVM на GDScript'е? Я тут курю мануалы по MVVM и задумался, насколько он применим к играм? Насколько он реализуем в годоте? Подписаться на изменения данных средствами языка можно. Разделить данные и логику тоже можно, средствами файловой системы. Описание интерфейса языком разметки присутствует, хоть и не ХАМЛо. Остаётся только прикрутить аналог INotifyPropertyChanged к каждому требующемуся контролу/виджету через сабкласс - и готово! или нет?
>>705937 Или всё же придётся использовать существующие фреймворки в шарпе, типа авалонии, а годот прикрутить как визуальный бэк-энд вместо, скажем avalonia.win32 или avalonia.x11 ?
>>705948 > что ты хочешь получить > на примере? Честно говоря, я только начал вплотную изучать вопрос и ещё сам не понял, что конкретно мне тулят под этой волшебной фразой MVVM. Из статей и документации я почерпнул пока что только абстрактные лозунги, типа Хочу получить динамически подстраивающийся под меняющиеся условия интерфейс, действующий по заложенным внутрь него правилам, легко масштабируемый от мини-проекта инди-студии из одного человека, до масштабов корпоративного продукта. Шаблон состоит из трёх частей: Model - непосредственно логика, может быть написана на любом языке, любой среды и лежать где угодно, хоть в сети, отдавая данные по запросу, принимая запросы, похожа на сервер. ViewModel - Самая сложная часть, которая являет собой связку между остальными двумя частями. Если View и Model представить себе, как слепых мудрецов из знаменитой притчи, до ViewModel для View выглядит как View, для Model выглядит как Model. View - это собственно сам интерфейс, который строится динамически, получая данные из ViewModel.
>>705950 Ну хз я MVVM сам толком никогда не понимал. На примере я имел в виду на каком то конкретном. То есть какой нибудь контрол, например слайдер с цифиркой. У нас есть модель - собственно переменная с цифиркой Допустим у модели есть какая то логика - хотя бы ограничивать минимальное/максимальное значение У нас есть вью - это отображение цифирки и отображение слайдера, и еще в него можно кликать. Допустим у вью тоже есть своя логика - слайдер двигается к месту куда кликнули постепенно, с определенной скоростью. Ну вот я просто создам сцену, заведу переменную target_value, move_speed, и буду в process двигать к ней. Может быть, добавлю сигналы on_changed и on_finished_animation. Это, наверное, MVP? А что предлагает MVVM? Там есть декларативные связывания. Ну писать TSCN ручками вряд ли кто то захочет в здравом уме. Тогда надо экспортить какие то переменные, чтобы можно было в редакторе их редактировать. А что туда писать? Пути к переменным, по аналогии к путям к нодам? В принципе в редакторе уже что-то подобное есть, ведь в анимейшн плеере можно анимировать, например, чей-то position:x
>>698054 (OP) Привет, я нюфаня. Нубский вопрос. Я думаю. Сейчас собрался скомпилировать игру на ПК, но что-то пошло не так. У меня годот стимовский и я нашёл только компиляцию для планшетов, а как для пк компилировать? Или это уже нужно платную версию годота покупать?
>>706066 Всё разобрался, спасибо. Оказывается всё делается в одну кнопку, если уже скачен пакет, хрен пойми чего. И главное сишарп работает! А есть какой ни будь способ подключить вижуал студию?
>>706079 Но наверняка ты следующим вопросом спросишь, а как сделоть механизм сохранений?
Я всем рекомендую антипаттерн "синглтон". В случае с сохранениями, синглтоном является игровой мир, состоящий из объекта с полями и функций чтения записи в поля этого мира. Игровой мир существует всегда. Каждый объект подлежащий сохранению пишет в игровой мир данные о себе, ровно в тот момент, когда данные эти изменились. По твоему запросу игровой мир отдаёт подготовленный жсон-объект, пригодный для записи в сейв-файл или для записи в переменную как чек-поинт из которого можно быстро загрузиться, не прибегая к файловым операциям. По твоему запросу игровой мир получает подготовленный тобой сейв-словарь и загружает его в себя. На периоды сохранения и загрузки, игровой мир должен переходить в режим только-чтение, не давая существующим объектам производить запись.
Это в общих чертах система сохранения.
Теперь, как нам её задействовать в твоём вопросе >>706076 думаю ты уже догадался. При выгрузке сцены все необходимые данные уже записаны в игровом мире, так как запись ведется постоянно, по факту появляения изменений. А вот при загрузке новой сцены, новая сцена сразу пишет туда, что сейчас она является активной сценой. И она читает оттуда переменные, относящиеся к ней: таак, читает сцена, сундук_3 опустошён, дерево_6 срублено, моб_5 убит, труп лежит в точке (1108, 637), инвентарь трупа опустошён, расставим остальные объекты по дефолту, время суток - вечер, загрузим вечерний скайбокс, ветер северо-западный, 3 м/с, загрузим данные в шейдер листвы и травы.
>>706076 Заводишь отдельную сцену, например GameState. И в ней скрипт, в котором будут собственно глобальные переменные (или геттеры-сеттеры). И все это удовольствие в настройках проекта - в автолоад. И там хрванить состояние игры (например isBossDead = false, и т.д.)
>>706615 Опенворлд? Да? Да? Загружаешь первую и единственную сцену World и подгружаешь локации к ней чайлдами по мере приближения к ним игрока. По мере удаления - выгружаешь. Но есть один нюанс. Загрузка и выгрузка должна работать умно, в объектном пуле, потому что создание объекта (выделение памяти в куче) - затратная операция. Поэтому тебе нужно организовать пул объектов, которые будут держателями локаций и будут крутиться каруселью перед глазами игрока, показывая ему то рифтен, то винтерхолд с солитьюдом.
>>706727 > Как ты себе это представляешь в случае годота? Два треда назад подробно рассмотрели. В качестве пулов объектов прекрасно подходит механизм чайлдов в нодах. Заводишь ноду, которая не вводится в дерево сцены (далее: Бэкап-нода). К этой ноде в потомки добавляешь нужные ноды (далее: Чанки). При добавлении идёт нагрузка на комп, так что делаешь это один раз при создании абстракции игрового мира / игрового поля (далее: Игра). Далее, при необходимости ввести чанк в игру, меняешь ему парента с бэкап-ноды на игру. При необходимости вывести - меняешь парента с игры на бэкап-ноду. Все выведенные из дерева сцены ноды вызывают колбэк _exit_tree и перестают обрабатывать _process... колбэки. Соответственно, все введённые репарентом в дерево сцены - снова выполняют _enter_tree и возобновляют вызов _process... коллбэков. Это нужно знать и активно использовать в этом, не побоюсь этого слова, паттерне. Загрузку ресурсов следует делать в несколько этапов и в несколько потоков. Следует завести себе не менее двух уровней детализации в зависимости от дальности от игрока. Назовём их ближний, средний и дальний. Приближение игрока: На дальнем уровне активных чанков нет, на среднем уровне чанков всё ещё нет, но они уже начали фоновую загрузку ресурсов, на ближнем уровне чанки с загруженными ресурсами вводятся в дерево сцены репарентом из бэкап-ноды в игру. Отдаление игрока: На ближнем уровне чанки работают в сцене, но уже помечены в очередь на вывод, на среднем чанки выведены из сцены, но сохраняют загруженные в себя ресурсы, на случай, если игрок пойдёт обратно, на дальнем чанки выгружают из себя ресурсы и помечаются, как свободные. Свободные чанки не имеют ни типа, ни координат в игре, они получают тип и координаты, когда получают данные о ресурсах, которые им следует загрузить. Таким образом я в самом начале выразил это как карусель: Чанки как бы вращаются всё время вокруг игрока, выгружая из себя объекты позади и загружая объекты впереди. И ещё раз повторю, загрузка ресурсов должна идти в несколько потоков. Без этого даже не пытайся зделоть опенворлд с корованами. Должна быть возможность не только быстро и одновременно, не нагружая основной поток, загружать ресурсы, но и возможность отменять начатую загрузку на любом этапе. Потому что игрок ходит рандомно. Только что он шёл на север и там прогружались замки, горы, тролли, и вдруг он резко развернулся назад и пошёл на юг, и надо срочно бросать загрузку и грузить лес, эльфов, домики деревянные.
>>706739 Я не очень понимаю, или ты не очень понимаешь, что такое "фоновая загрузка ресурсов" и как ты собираешься ее делать без "выделения памяти в куче".
>>706747 https://ru.wikipedia.org/wiki/Куча_(структура_данных) >Реализации >Стандартная библиотека шаблонов языка C++ предоставляет шаблоны функций для управления кучей make_heap, push_heap и pop_heap (обычно реализуются бинарные кучи), которые оперируют с итераторами произвольного доступа ... к данным, в оперативной памяти, при работе с инстансами классов, которые в этой памяти (и этой куче) лежат.
Штош, по вопросу ресурсов. Для центрального процессора ресурсами являются эти самые данные в куче. Для видеокарты же ресурсами являются данные о геометрии и шейдерах. Для звуковой карты - данные о звуке.
Так что да, ты не понимаешь. Ты уцепился за один аспект значения "ресурсов".
>>706763 Это все замечательно, но ты попробуй как то внятно объяснить, что именно ты собираешься пулить, если все загружаешь в фоне и все равно выделяешь память пачками.
>>706935 Что ты имеешь в виду? var child = obj1.get_child(i) obj1.remove_child(child) some_other.add_child(child) Возможно понадобится писать через call_deferred
>>706959 Вообще говоря в годоте это штатная операция. Пример: у тебя игра типа кваки, сцена - уровень у которому прикреплен игрок и вращающаяся пушка. Когда игрок подходит и поднимает пушку, можно ее открепить от сцены и пприкрепить к руке игрока через boneattachment. Надо только учесть нюансы, типа упомянутого вызова add/remove через call deferred, и сработающих эффектов типа area enter/exit
>>706999 Вообще, всё ещё проще, начиная с 3.2.1, ЕМНИП, ввели ноду, которая синхронизирует координаты. Вот тебе и готовый аттач чего угодно к чему угодно, без возни с репарентом.
>>707241 >импортирую и ничего не происходит Что по-твоему должно произойти? Файл должен отобразиться в инспекторе, все. >даже в сцену не могу его добавит. Аудиофайлы это ресурс, который используют AudioStreamPlayer, их нельзя самостоятельно добавить в сцену.
>>707245 Не поверишь, но с документации я и начал. Вот только там наглядно не показывается, что перед началом работы нужно сначала добавить AudioStreamPlayer на сцену, потом загрузить трек, переимпортировать его и написать скрипт, чтобы всё заработало.
>>707249 Вообще-то, поверю. Я на неделе изучал некоторые UI-фреймворки для шарпа (более для ентерпрайза, чем для геймдева) и наткнулся на множество вещей, которые не понимаю, даже интуитивно не вдупляю. Тыкаюсь, как слепой котёнок, а фронтендеры в шарпотреде посмеиваются над моими жалобами. И в гугле не могу найти ответы. И в документации написано лунным языком, который влетает мне в один глаз, а вылетает через второе ухо. Такшта, вот.
>>707249 >Не поверишь Я не верю. Вот смотри чего нашёл: https://docs.godotengine.org/en/stable/tutorials/audio/audio_streams.html Вообще, советую по непоятным темам заглядывать не только в CLASS REFERENCE, но и в TUTORIALS. Поначалу не очень очевидно, что они там есть и что их сколько-нибудь достаточно, однако, если внимательно пролистать всю левую колонку (которая с оглавлением), то обнаружишь много нового. Я так годоту учился в своё время.
Чо как, пацаны? Полгода не заглядывал. Кто-нибудь релизнул свою игру мечты?
>>707274 >Я не верю. Зря. >>707253 И в документации написано лунным языком, который влетает мне в один глаз, а вылетает через второе ухо. +++ >>707264 Да, спасибо, что напомнил. Примеры проектов по умолчанию встроены, там и посмотрел.
Ошибка CS0012 Тип "Object" определен в сборке, на которую нет ссылки. Следует добавить ссылку на сборку "netstandard, Version=2.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51".
>>707348 Вот так должен выглядеть сгенерированный редактором файл проекта. Там свой собственный СДК, прямо зависящий от моно.
Я в прошлом году тоже пытался напихать в проект пакетов нюгета через студию. В принципе, большинство пакетов работают. А ты что пытался затянуть в проект?
> нужно налепить типа галереи материалов на прямоугольниках под полом карты, что бы никто не видел, да?
Da.
> а что за "пропуки" о которых тут весь тред ниже уши прожужжал
В целом, "пропуками" в нашем соседнем срачетреде обезумевших пуконюхов, называются проседания ФПС. Проседания ФПС случаются по разным причинам.
Управление загрузкой шейдеров в видеокарту отдано в твои руки, как полновластному разработчику твоей игры. По дефолту шейдеры грузятся лениво, в момент первого вхождения в пространство обзора камеры. Ты можешь загрузить их "трудолюбиво" при начальной загрузке сцены.
Так же ФПС может просесть при любой ленивой инициализации тех или иных сущностей объектной системы. Бороться с ними следует разными методами. Описанными не только в документации годота, но так же и в классической технической литературе. Потому что проблема времени на выполнение тех или иных алгоритмов - проблема фундаментальная. И оптимальные алгоритмы, эффективные решения, они являются ценностью, которую никто не раздаёт бесплатно. Либо реализуй самостоятельно - либо покупай библиотеку, пиши класс-адаптер к ней, используя покупное же API.
Но, повторюсь. Движок опенсорсный и модульный и даёт тебе полную власть над реализацией алгоритмов. Свою игру ты сможешь оптимизировать до бесконечности, вклиниваясь в исходники, заменяя модули на собственные. Ничто из этого не запрещено лицензией. Такие дела. Это сложно. За ручку тебя никто не поведёт.
Однако, на этапе полировки игры никто не мешает нанять грамотного кодера для оптимизации. Была бы игра. Есть у тебя игра-то? А если найду?
>>707729 Ты по инструкции делал? С rcedit? На самом деле виндовый проводник кеширует. Попробуй скопировать экзешник с новым именем. Если там будет новая иконка то все ок.
>>707742 > С rcedit? >>707729 > иконка годота не меняется ИМХО, гораздо проще и удобнее поменять иконку своим любимым сторонним инструментом. Я, например, юзаю RecourceHacker. Можно вообще прошить иконку шаблону экспорта и не париться. Но в таких прогах как редакторы ресурсов нужно матчасть знать. Иконгруп - не то же самое, что икон.
>>707823 Конечно плохое. Такие вещи настраиваются один раз и просто работают. Представь себе что тебе надо сдавать игру на конкурс, у тебя последние баг фиксы новые версии каждые 15 минут, экспортишь, отправляешь и... понимаешь что забыл сделать ручную операцию в последний момент.
>>707828 Я только что проверил - и действительно. Замена иконки в файле шаблона windows_XX_YY.exe, где X - 32 или 64, а Y - debug или release, работает прекрасно, проект экспортируется с кастомной иконкой и даже со встроенным PCK все запускается нормально.
Разумеется, это не подойдёт разрабам, которые активно выпускают патчи сразу для нескольких игор. Но я лично как правило только с одной игрой работаю, мне норм. Хотя, чего это я туплю? Свой кастом темплейт скопировать в отдельную папочку для каждой игры и юзать его для экспорта. Тем более, если игра серьёзнее туториалов и тестов, у неё будет как минимум один сторонний модуль вкомпилен и в редактор и в темплейт, что потребует юзать именно кастом.
>>707890 > и не перепутать Не перепутаешь. Кастомный темплейт задаётся один раз в настройках проекта и дальше работаешь с ним. Автоматически, как анон выше и желал.
>>708055 >>708082 Епт. С пробуждением. Это появилось уже пару месяцев как. И кстати это будет охуенный ход, если они до ума доведут эту версию. Т.к. это прямой заход в различные школы и прочие обучающие структуры на изи в недалеком будущем.
>>708177 > прямой заход в различные школы Скачать селфконтейнед приложуху (корректно подписанную к тому же) тоже не сильно сложно. Уже 2к2д и даже учителя информатики в школах умеют скачивать софт.
Короче, собираю команду для создания опенворлда на годоте. Там в соседнем треде неосиляторы пишут что не получится. Если же мы выкатим рабочий прототип, они уже охуеют, а если мы доведём прототип до релиза - будет эпик вин.
>>708552 Я особо гнать не буду - дел много. Могу пока просто делиться ресерчем. Из готового террейна у нас есть только heightmap террейн. А по хорошему нужен бы vertex displacement (VDM) Без него не получится делать террейном нависающие уступы. Только объектами, а это мне кажется уже не совсем рационально. Также придется как то дополнительно обрабатывать пещеры и вообще все двух+ ярусное. Как минимум с точки зрения коллайдеров и навигации. Т.е. пол пещеры будет еще террейном - а потолок уже отдельным объектом. Также я не знаю, как в случае с дисплейсментом вершин будут работать встроенные тени. (В процессе написания родилась идея на пробу - сделать для скал дополнительные полоски террейна, повернутые на ребро на 90 градусов... Надо потестить на производительность)
Второе наблюдение касается текстур. Из коробки террейн поддерживает смешивание 4 текстур, из которых на последнюю можно включить трипланар, то есть только она может играть роль скал - остальные будут растянуты. Впрочем, в шейдере написано что это можно изменить, ценой производительности. Также есть экспериментальная ветка где можно блендить до 16 текстур (но только до 4-х в каждой конкретной точке - что-то типа тайлсета выходит). Но там, вроде бы, трипланар вообще не сделан сейчас. https://www.youtube.com/watch?v=sbADtAkh92w
Стриминг еще не продумывал. Попробую сначала просто несколько чанков террейнов и лоу-поли версию меша для дальних пейзажей. Также подумываю о том чтобы коллайдеры шли отдельно, и может быть тоже нарезаны на небольшие чанки. По идее мобы рисуются только в каком то радиусе от игрока, в ближнем радиусе будет детальный коллайдер, а подальше, там где враги просто несагрившиеся стоят - возможно просто плоскости для экономии.
>>708655 Ща пойду загуглю ВДМ, но, по идее плагин Зилана так и работает, дисплейсом вершин. По крайней мере я такой вывод сделал, разглядывая шейдеры в его комплекте.
А вот зацени мою идею. Чтобы сделать сложный террейн с поддержкой нависающих скал, пещер и даже терраформирования, но (ПРЕДПОЛОЖИТЕЛЬНО) производительнее, чем воксели, нужно помимо карты высот использовать инверсную карту высот снизу, две карты ширин, справа и слева, и карту длин, спереди и сзади. То же самое триде. Все шесть карт совмещаются генератором и на их основе строится один или несколько мешей, подобно тому, как в черчении из трёх видов строится проекция объёмной модели, а у нас натурально вся модель строится из окружающих кубемапом видов. Но только получается, что для пещер всё равно придётся завозить в генератор дополнительные карты. Ведь кубемап даст нам только наружною поверхность - как только глубина впадины в поверхности увеличится настолько, что её не будет видно ни сверху, ни с боков, она перестанет вычисляться. Очевидным решением в таком случае будет от генератора запросить локальный кубемап для отрисовки этой зоны, в которм и будет закодирована полость внутри террейна (пещера).
Сложность алгоритма на первый взгляд не должна быть очень большой. Но я не спец в вычислении сложностей алгоритмов. Основной сложностью в этой идее я вижу само получение набора кубемапов. Как вариант, можно написать плагин для блендера. В блендере строится/генерируется террейн со всеми пещерами, уступами, скалами. Прямо хайполи со всеми скульптингами. Потом запускается плагин, который с этого набора мешей снимает кубемап-карты. Сначала внешнюю, глобальную, потом локальные для всех вершин, которые не видны на глобальной, затем рекурсивно со всех вершин, которые не видны на локальных картах. Каждому сгенерированному кубемапу присваивается идентификатор, или координаты, ну не знаю.
Генератор действует наоборот и уже с ЛОДами, для всей карты генерируется крупноячеистый меш, затем, при приближении к координатам нашего игрока меш уточняется так, что рассматривая поверхность вблизи игрок видит хайполи, а глядя вдаль полигональность пропорционально углу обзора падает.
Только вот тот же Зилан уже написал си++ модуль с поддержкой воксельных террейнов и эта идея в принципе нафиг не нужна. Я её реализовать сам вряд ли смогу. Проще скомпилировать редактор и шаблоны с модулем Зилана и наслаждаться готовой реализацией.
>>708655 > Стриминг еще не продумывал. Главное, при продумывании стриминга чтобы не произошло путаницы между ресурсами процессора (объектами в куче, которая в оперативной памяти) и ресурсами диска (которые есть файлы на диске), как это случилось ИТТ десятком постов выше.
>>708711 Heightmap дисплейсит только по вертикали, вот в чем дело. Как в предыдущем посте на 2-м пике. Как на 1-м и 3-м пике - не может. То, что у него есть воксельный, я забыл, но мне они не очень нравятся
>>708714 > vertex displacement Эх, если бы разбираться во всём этом, можно крутые вещи творить! Вот нашёл простенький примерчик: https://www.youtube.com/watch?v=4zhTtOuLpjA >>708715 Ну да, поверх первоначальной генерации нужно накладывать фильтры, имитирующие природные эффекты: выветривание, вымывание, выплавление и т.п. И сдаётся мне, плоскими картами это будет накладываться гораздо производительнее, чем вокселями. Но опять же, я не уверен. Да и вообще, может под вокселями Зилан как раз и подразумевает примерно то, что я описал выше. Ведь каждый пиксель, описанный шестью хайтмапами кубемапа из примера выше, это по факту и есть - волюметрик пиксель - воксель.
>>708180 >Скачать селфконтейнед приложуху (корректно подписанную к тому же) тоже не сильно сложно. Уже 2к2д и даже учителя информатики в школах умеют скачивать софт. А теперь даже устанавливать ничего не надо будет. "Дети, переходим по ссылке и ебашим игру своей мечты".
Годаны, поясните за 2д-скелеты. Хочу сделать по уму. Создаю Skeleton2D, к нему потомки Bone2D. Дальше ему устанавливаю позицию покоя. Дальше выбираю все кости, составляющие одну конечность (например, руку) и жму "создать цепь ИК". Двигаю конец руки, но предыдущая кость растягивается, а не идёт следом. Делаю по простому. Создаю дерево из обычных 2д-нод. Потом из него создаю пользовательский скелет. У этого скелета выбираю кости одной конечности, создаю цепь ИК - вуаля, при движении последней кости предыдущая не растягивается, а тащит и поворачивает следом всю конечность, сохраняя длину каждой кости. ЧЯДНТ? Это так и задумано? Или баг? Или я чего-то не знаю?
>>709070 Я с 2д не работаю, так что могу только вечером попозже глянуть Вроде бы читал что с IK что то меняли в последнее время. Вполне возможно что там что то не работает.
>>709102 Какой ты молодец. Сам-то туда заглядывал? Я вот тщательно всё прогуглил, прежде чем спрашивать.
>>709106 >в последнее время Как минимум полгода назад всё работало ровно так же, как сейчас. Именно поэтому у меня закралось сомнение, а баг ли это или всё же фича.
>>709070 > Дальше выбираю все кости, составляющие одну конечность (например, руку) и жму "создать цепь ИК". Может там как в блендере, важен порядок выбора нод?
>>709193 Судя по тому что пишут, баг заключается в том, что кнопка Make IK chain не работает, а работает кнопка Make custom bones при выделенных костях.
>>709198 Посмотри с 15-й минуты, я сам не понял, но вроде у него работает. https://youtu.be/QL57J3anDTU?t=905 Может есть какой то сторонний модуль? Смущает отсутствие аттрактора для локтя
>>709201 сцуко. Всё затевалось для того, чтобы НЕ делать custom bones. А тут выходит, что делать это надо в любом случае, потому что кости это на самом деле не настоящие кости, а настоящие кости это те, которые не кости. Точнее, просто кости нужны не для того, чтобы строить из них скелет, а для того, чтобы привязывать к ним искажения меша. А для построения скелета подойдут любые ноды, просто в режиме отображения как будто это кость. Я понял. Спасибо, анончик, ты мне действительно помог.
>>709901 Не меньше четырех, по крайней мере художник, аниматор, дизайнер уровней и программист. Может быть больше. У них оказывается еще и кикстартер 2 года назад был, собрали $5000.
визуальный скриптинг рабочая тема или костыль лютый? Никогда в жизни не программировал, занимался исключительно цг, а на погромиста денег нет, что очевидно
>>709992 Не попадайся в эту ловушку. Визуальный скриптинг - ЭТО ТОЖЕ ПРОГРАММИРОВАНИЕ. Если у тебя нет кодерского скилла - ты ничего толкового на нодах не соберёшь.
Но вообще, ВС полноценен. Но не нравится лично мне излишней громоздкостью. Все ноды соединяются слева-направо. А мне бы хотелось, чтобы ноды вращались таким образом, чтобы соединять их можно было в любом направлении. В отсутствие этого визуальный скрипт неприлично разрастается в ширину.
>>709992 На мой (программистский) взгляд не стоит того. Дело в том, что в Годоте ВС делали люди с программистским мышлением. ИМХО стоило загнать в ВС предметную область, а они загнали программерские конструкции. В самом деле, вместо "создать случайное число" они используют "вызов встроенной функции" в которой параметром "rand_range". Вместо проверки "столкнулись с шаром" там нода "приведение типа" с параметром "ball.vs". Вместо какой нибудь ноды "создать вектор 2d" там нода "конструктор" с параметром "new Vector2()", а вместо "нормализовать" там "базовый вызов" с параметром "Vector2.normalized()". Лучше уж тогда учить простенький кодинг по туториалам, и спрашивать совета как что делать ИТТ.
>>710039 >Лучше уж тогда учить простенький кодинг по туториалам Я очень плохо понимаю в вашей теме, но из того что я успел понять, что если я буду использовать куски чужого кода это равноценно воровству трейсу чужих рисунков у нас в цг, правильно? Что тогда насчёт кода из туториалов, я могу использовать их в коммерческом проекте?
>>710061 Начав кодить, ты неизбежно начнёшь понимать, как это работает. Копируя код из туториалов, обнаружишь, что тебе надо его допилить под свой проект. И вообще, если ты из туториала "как нарисовать сову" скопируешь начальные овалы, а потом нарисуешь совсем другую сову, это будет считаться воровством? Вообще, я вот прямо сейчас сижу и рассказываю ребёнку (8 лет), как кодить в Годоте. Это вот настолько просто.
>>710061 > если я буду использовать куски чужого кода это равноценно воровству Воровство - когда забираешь то, что тебе не хотели отдавать. Когда ты берёшь опенсорс, это не воровство. Потому что опенсорс тебе хотели отдать и отдали.
>>710061 Как и в цг все зависит от лицензии - у вас бывает все что угодно начиная от all rights reserved, когда нельзя ничего, от CC-ND когда можно только смотреть, до CC-0 когда можно все. Обычно код туториала выложен на гитхаб, и там есть лицензия. Часто это MIT или BSD, грубо аналог CC-BY - если используешь должен упомянуть авторство оригинала. Второй момент заключается в том, что туториалы покрывают базовые вещи, то есть практически азы. Там сложно что то предъявить, это как туториал на рисование квадратов и кубов - что же теперь, никто не может их рисовать?
>>710116 >Часто это MIT или BSD, грубо аналог CC-BY - если используешь должен упомянуть авторство оригинала. С чего ты это взял? Не нужно этого делать.
>>710116 > MIT или BSD, грубо аналог CC-BY Насчёт бсд не интересовался, а мит - аналог цц-0. Я специально интересовался. Делая игры на годоте, ты можешь отключить сплеш-скрин. Ну ты понел.
>>710135 > мит - аналог цц-0. Нет, даже не близко. Ты обязан include copyright. Это сказано в самом тексте лицензии: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. Более того, в годоте используются либы под apache лицензией, а она требует так же указывать авторство. Это значит что просто указать мит лицензию годота с копирайтом хуана, скорее всего, юридически недостаточно Так что я бы советовал вообще куда то в about тиснуть содержимое этого файла https://github.com/godotengine/godot/blob/3.2/COPYRIGHT.txt Даю ссылку на версию 3.2., но надо учитывать что состав либ мог поменяться между билдами
> ты можешь отключить сплеш-скрин. Да, можешь. Нет лицензии которая обязывала бы тебя его показывать.
>>710147 Перестал смотреть этого инфоцыгана, и вам рекомендую. Начал делать фундаментальный гайд по движку, забросил и хуярит вот такое. Позор. Презрение. Дизлайк. Отписка.
Кто ни будь подскажите почему мой код не работает? Я даже упростил назначение клавиш и всё равно кубик стоит. Сначала всё делал через список действий, но и там ничего не работает.
>>710211 Velocity - это твоя переменная. Она ни к чему не подключена.¯\_(ツ)_/¯ Очевидно тебе надо делать Position += Velocity или какой нибудь MoveAndSlide.
>>710211 Потому что ты просто написал, что у тебя velocity чему-то равна. Для движения kinematic body нужно вызвать метод move_and_slide/move_and_collide. Еще я не понял, зачем тебе вообще spatial node.
>>710215 > Еще я не понял, зачем тебе вообще spatial node. Просто неудачно гайды посмотрел и не правильно понял. Простим нашему новому брату сию оплошность?
Ловлю очередное подгорание от загрузки игры. Делаю так. Сначала очищаю игровое поле. Потом подгружаю тайлмап (словарь, у которого ключи это вектора, а значения это виды тайлов). После тайлмапа загружаю всякие дополнительные объекты-сцены. После загрузки всё молча падает. Файл сейва не битый, загружается корректно. Игровое поле очищается корректно, если запускать очистку без загрузки. Какую бы часть из непосредственно загрузки ресурса я ни удалял, падает всё равно. Предохранился, обернул все добавления в дерево при помощи call_deferred. Не помогло. По точкам останова прошёл весь процесс загрузки, никаких проблем. Падение наступает позже. Проект довольно простой, загружается, кроме тайлов, всего два объекта.
>>710245 > Вот как это отлавливать? Лично я в таких ситуациях начинаю логгировать все действия. Чем подробнее, тем лучше. Необязательно в файл, можно прям в консоль. На чём вылетит, на той строке лог и прервётся. С теми переменными, которые ты подозреваешь. Если и так не получается отладить - пили модульные тесты, как настоящий программист.
>>710253 >На чём вылетит, на той строке лог и прервётся Ни на чём. В момент вылетания не выполняется никакой мой код. Загрузка всего завершена, все ноды выполнили свои _ready, а ноды, имеющие _physics_process, будут созданы позже игроком. >как настоящий программист Я не настоящий программист. Погуглил, чоэтотакое. По частям-то у меня всё работает. Не работает только всё вместе.
>>710274 Выкладывай проект на любой файлообменник (ну или копию проекта без твоих ресурсов, но с воспроизводящейся проблемой) и ссылку сюда. Будем посмотреть, что у тебя там.
А теперь у меня >>710245 подгорает от собственной тупости. Я не делал сохранению и загрузке какого-либо интерфейса, просто повесил на привычные по большинству игр клавиши F5 и F8. Катарсис наступил, когда я закомментил вообще весь код, срабатывающий после выполнения клавиши F8, а игра всё равно молча падала. Ну да, я ж её, получается, сам и останавливал.
>>710401 1. закидываешь Zip. Он заливается в файл preload.zip 2. нажимаешь Import, выбираешь preload.zip 3. во второй строчке создаешь новую папку под проект. Например /home/web_user/projects/your_excellent_game
>>710611 Сомневаюсь. Оружие-то всё равно своё приделывать, следовательно и анимации свои подгонять. Но я уверен ты найдёшь с ригом рук и анимированным базовым пистолетиком. Надо только загуглить. Всё, я спать.
>>710613 Я имею ввиду, риг - это не проблема. Проблема в анимациях на нём основанных. Гораздо проще сразу заанимированные руки-крюки-базуки экспортнуть в глтф какой-нибудь, чем вытаскивать из ассетного глтф в блендер модель, ебаться с ней, а потом переэкспортировать обратно? Честное слово - проще самому всё сделать. Ну всё, ушёл.
>>710613 Ну в этом же тоже модельку подменять, однако она есть. >Оружие-то всё равно своё приделывать, следовательно и анимации свои подгонять. Можно же просто подсунуть другие модельки рук, и переименовать анимации, не? >>710614 Те что я смотрел были довольно куцыми по функционалу, приседаний нет, ступеньки низкие не перешагивают. Хотя при этом встречается и бег по стенам, и зацепление крюком.
>>710606 >Хуёво что от третьего лица, воспринимать как шутер трудно Меня в последнее время стало укачивать от первого лица особенно быстрых шутерах типа халфы. А здесь ничего так, можно модельку ГГ забабахать красивую, анимацию приделать, опять же боёвка будет более наглядной. Меня кстати всегда это добивало. Шутер от первого лица вижу врагов, вижу обстановку, но не вижу себя кроме 2х рук и если повезёт ног. Не логично.
>>710617 > Те что я смотрел были довольно куцыми по функционалу Возьми этот и перемести точку крепления камеры на переносицу персонажа. Получишь современный FPC с видимыми ногами и сисечками.
У меня другая проблема с ассетными контроллерами. Все они предполагают базовый функционал. Чтобы допилить мне свой, мне придётся привыкать к привычкам кодинга автора ассета. Например, у него в туториалах все переменные нетипизированные. Мне, как диду-паскалисту, это как серпом по яйцам. То есть первое же, что мне придётся сделать с ассетом, это переписать все определения вида var velocity = Vector3() на var velocity : Vector3 = Vector3.ZERO Далее. Множество ассетов тянется с версии 3.0 а то и с 2.0. И там уже на сегодняшний день существует легаси натуральное. Например, подгрузка скриптов через preload вместо раздачи нужным скриптам имён и конструированием их классов через new(). Это тоже весьма раздражает. Хочется взять и переписать. И самое главное. Контроллер-ассеты (если вернуться к ним) предоставляют базовую функциональность. Мне кроме ходьбы/бега нужно перемещение по лестницам (вертикальным). А ещё мне хочется, чтобы колёсиком мыши менялась длина плеча камеры за спиной и в крайнем ближнем положении переключалась на вид от первого лица. Как я описал в первом предложении. Бленд-дерево слишком простое. Помимо перекатов туда ещё следует добавить анимации активностей, добавить логику, при которой проигрывается короткая анимация начала активности, потом играется бесконечная анимация тела активности, а потом следует предусмотреть несколько коротких конечных анимаций конца активности (нормальная при окончании активности, при прерывании игроком, при уроне мобом, при изменении условий на локации). А ещё я хочу, чтобы при получении абилки, персонаж мог летать. Следовательно, при активации абилки игроком, бленд-дерево переключается на анимацию полёта, а стейт-машина персонажа должна переключиться с логики ходьбы/бега на логику полёта на крыле. А ещё я хочу, чтобы в режиме боя включалась имитация пошаговой боёвки, при которой локация дробится на кубы, персонаж перемещается из одного центра куба в другой, когда у него есть ОД (очки действия, ходы) и их хватает на перемещение туда. При этом персонаж переключается в режим ожидания, когда ОД нет и ходят мобы, и получая урон от них, проигрывает соответствующую анимацию.
Такие задачи в принципе нерешаемы дженерик-контроллерами. Допустим, некоторая фирма продаёт сложный модульный контроллер, со своим фактически АПИ. Который может ходить (тремя способами искаропки с возможностью написать свой модуль ходьбы), летать (двумя способами), ползать, карабкаться, взбираться, имеет расширяемое бленд-дерево, в которое простыми жсон-файлами мы можем добавить логику с путями к анимациям. Допустим я купил его. И теперь помимо основного движка мне нужно учить АПИ ассета. Охуеть просто какой геймдев!
Реально проще изучить матчасть и запилить свой контроллер с нуля. С твоими привычками кодинга и с удобным тебе расположением ресурсов.
>>710706 Ах да, если я хочу контроллер в слешерную игору, я автоматически иду нахуй, потому что 99% ассетов дженерик-сцай-файные с пистолетиком и механикой стрельбы. А для слешера мне мало того, что придётся переделывать скелет. Мне под каждое холодное оружие придётся добавить свои мувсеты и добавить их целой пачкой в бленд-дерево. (Держим в уме, что персонаж в любой момент может получить абилку полёта и махать клинком в полёте нужен отдельный мувсет). (И не забываем, что карабкаясь по лестницам персонаж может отмахиваться от набигающих вражин ещё одним отдельным мувсетом). (И имеем ввиду, что мувсет не даётся игроку целиком, а постепенно открывается при прокачке, следовательно следует предусмотреть блокировку частей каждого мувсета по отдельности).
И ещё. Если я хочу, чтобы контроллеры персонажей не были жестко прибиты к игроку гвоздями, а могли своей стейт-машиной переключаться с AI на управление игроком когда надо - то я тоже иду нахуй.
>>710706 > Возьми этот и перемести точку крепления камеры на переносицу персонажа. Даже эта простая операция на чужом ассете обладает подводными камнями. Попробовал сейчас. Результат пикрелейтед. Когда стоишь на месте выглядит неплохо. Когда бежишь - лицо маячит перед камерой. Лень видос записывать. В общем: 1. добавляем на кончик носа отдельную камеру. 2. добавляем флаг FPC в код. 3. по нажатию F (или прокрутке колёсика до упора вперёд) меняем значение флага. 4. переключаемся между камерами искаропки (да их там две, зачем - не вникал) (FPC=false) и камерой на носу (FPC=true). 5. ПРОФИТ(?)
Годотаны, есть у меня такой вопрос. Двумерный изометрический пруф оф концепт. Есть две тайлмапы для пола и стенок, пол в том числе под стенками (стенки не занимают весь ромб, да ещё и торчат наверх, как обычно). Есть ли способ сделать красиво сделать автоматическую навигацию «вычитая» из общего навигационного полигона стенки? Или лучше добавить к тайлсету стенок прозрачный и проходимый тайл и впихивать повсюду в пустые места? Или с навигацией в тайлах есть подводные камни и стоит не сношать мозги, а нарисовать полигон вручную? Всё равно тестовый уровень тестового уровня. И второй вопрос: простого способа организовать правильную сортировку тайловой карты и спрайтов, чтобы видеть ровно то, что нужно, не существует? Понятное дело, что это не очень тривиальная задача, но очевидно, что её уже кто-то решил. Опять-таки, если нет — я забью, у меня там сейчас спрайты на три кадра, и дрочить нужно не это, а игромеханики.
>>710796 Я не очень понял твой вопрос, но я писал импортер из редактора уровней и никаких проблем с генерацией кастомных полигонов коллизий нужной формы из кода не было.
>>710800 Кстати, да, Ysort я для этого не пробовал, потому что думал, что он всю тайлокарту одним объектом считать будет.
А про первый вопрос — всё просто: навигация возможна везде, где не стоит стена, поэтому помимо инструмента «вот тут можно пройти» хорошо бы иметь инструмент «нет, вот тут пройти низзя». Тогда можно было бы все тайлы пола покрыть навигационным полигоном, а тайлы стен тогда вырезали бы из него непроходимые куски. Но ладно, это уже раскат губы, пойду немножко по-другому сделаю, спасибо.
>>710802 Kurwa! А навигацию на тайлах-то не видно в редакторе. Придётся для дебага чего-нибудь рисовать, видимо. Или действительно не сношать мозги и импортировать из файла, но тайлоредактор-то в целом сносный.
>>710875 Если бы ещё обладать скиллом сразу находить нужный туториал... Иногда задают вопрос, и помню же, что видел такой видос с детальным разбором проблемы. Но найти не могу.
>>710902 > ecs Мне казалось это такой прикол был: Форсить ЕЦС, который придумали кодеры нотидог для обхода ограничений плойки. Плойки, Карл! Всё что даёт ЕЦС на современных ИГРОВЫХ пека, это тысячные доли секунды выигрыша. Зато эти доли секунды ты покупаешь ценой отказа от удобных кодерских инструментов и задрачивания сотен текстовых датафайлов. Мда.
>>710907 > автор у себя в синтетике намерял 5х прирост в синтетике (саркастический жест) > если я его на ООП напишу ЕЦС - это паттерн ООП, такшта в любом случае ты пишешь на ООП, системы - есть классы, компоненты - классы, сущности - классы. Накладные расходы ООП известны и описаны в литературе ещё 80х годов. Ты отказываешься от наследования и гоняешь текстовые конфиги между компонентами и системами. И тебе тупо удобно. Да. ЕЦС в случае плойки - жёсткая необходимость и ловкое решение. ЕЦС в остальных случаях - подростковый нигилизм по типу "МАМ, НЕ ХОЧУ ЗАМШЕЛЫЙ ООП, ХОЧУ ЧТО-ТО МОЛОДЁЖНОЕ" >>710914 > это пиздец как важно Как по мне - важнее качественный арт и эффекты. А ещё важнее - интересный геймплей. А выигрывать кадр на синтетическом тесте, когда ещё игоря тонет - это ящитаю преждевременная оптимизация во всей красе.
>>710943 Я пробовал esc. Очень удобный модульный подход, но его работоспособность в разы медленнее дефолтного наследования. А если юзать не наследование, а структуры, так вообще слоупочная хуйня.
>>710961 >его работоспособность в разы медленнее дефолтного наследования. А если юзать не наследование, а структуры, так вообще слоупочная хуйня. Толсто.
>>711087 Слушай, ECS не так работает, массивы компонентов-pod структур, (даже в C# это делается через unmanaged доступ к памяти) никаких "объявлений функций" они с собой не возят, у нас тут не JS, системы это просто функции, сущности это вообще просто int id. Если у тебя что то тормозило, то это значит у тебя неправильная реализация, вот и все.
>>711270 Я ошибочно прочитал за одну неделю как за один месяц, my bad. Да, если он за 6 дней надизайнил 50 уровней, это конечно респект. В общем моя основаня придирка к поставленному свету. Во-первых, "честный" космический свет не работает. Он смотрится паршиво, с резким перепадом в темноту. Во-вторых, он не озаботился частицами. Пули хоть и яркие, не производят свет, двигатели аналогично. Не пульсируют, не оставляют шлейфов. Взрывы не освещают. И вообще, кажется, тупо 2д круги. Однообразные астероиды без вариативности, обломки тоже однообразные. Обломки можно было кстати и не в 2д плоскости раскидывать, а "в глубину" тоже. Космолет выглядит серым, безжизненным. При этом, он таки знает какие приемы использовать. Он применяет easing к барьеру, который пружинит после столкновения. Он анимирует слои заставки. Просто он не применил этот juice ко всем элементам игры.
Пагни, я с тачскрином в выборе между двумя стульями. На одном TextureButton, который не работает с тачем, если не включить эмуляцию мыши (а включать её я не хочу, так как это создаст новые проблемы с управлением). На другом TouchScreenButton, который вообще не наследник контрола, следовательно имеет кучу проблем с масштабированием. Шоделоть? Кагбыдь?
>>711354 Хз, я разные варианты пробовал. В лучшем случае просто крутит часики. Не нашёл ни одного сигналау текстурбаттона, который бы отзывался на прикосновение. Вообще, у я разрабатываю на ноуте с тачскрином и убунтой. Но сомневаюсь, что тут порылась какая-нибудь собака, так как TouchScreenButton и всякие тачевые инпуты работают без нареканий. Годот, няп, хандлит ввод напрямую, ему наплевать на установленные в системе прослойки для тача.
>>711369 Попробовал. Работает. Но возникла проблема с тем, что FileDialog не умеет в тач. Сцуко. А я хотел сделать сохранение/загрузку. Но вообще, тот факт, что интерфейсные ноды не дружат с тачем, создаёт огромные проблемы. Эмуляция нажатия мыши - ужасный костыль так-то. Как в такой ситуации определить отдельно перетаскивание левой кнопкой и СкринДраг? Ну, то есть, понятно, что можно, но кривизна прям буэээ.
>>711384 М-да. Попытался накостылить, чтобы при вводе с тача события мыши не обрабатывались бы как мышь. Хер там плавал. Проблема в том, что при включённом режиме эмуляции мыши всё равно сначала отправляется клик, а потом касание (при том, что реально это просто касание). И я не вижу способа в момент клика понять, последует ли за ним касание. Был вариант просто спросить систему, а есть ли у неё сенсорный экран, но вот у моего ноута и тачскрин, и мышь. Попробовал запоминать ввод, а потом реагировать на него в _physics_process; помогло, но вместо этого теперь я не могу распознать касание без перетаскивания.
В общем, что я пытаюсь запилить: 1. Щелчок мышью - заполнить клетку на тайлмапе 2. Перетаскивание мышью - заполнить все клетки на тайлмапе, через которые прошла мышь 3. Короткое касание - заполнить клетку на тайлмапе 4. СкринДраг - переместить камеру 5. Щелчок мышью ИЛИ короткое касание по кнопке интерфейса - нажатие кнопки интерфейса Вроде бы наборчик вполне стандартный, ничего уникального. Но постоянно один-два пункта не получается приклеить, когда все остальные исправно работают. Есть какие-то готовые решения? Может, внятный видос по теме?
>>711393 Я бы делал обработку тача и мыши в отдельных методах. Подробно тому, как игры работают с геймпадом: прошёл инпут с геймпада -> стейтмашина инпута перешла в режим геймпада, прошел инпут с клавы или мыши -> режим клавомышь. В соответствующем режиме вызывается только соответствующий обработчик.
>>710906 ЕЦС придуман может и для обхода ограничений плойки (в чём я сомневаюсь, так как не видел никакой информации про это), но так как он эксплуатирует особенности работы кеша и процессоров в принципе, то он применим не только лишь на Cell, но и на x86 и на ARM и дает хороший прирост где угодно.
>>710920 >ЕЦС - это паттерн ООП Очевидно нет, так по нормальному он нарушает принцип инкапсуляции и очень редко следует наследованию и полиморфизму. Также ЕЦС прекрасно имплементируется в языках без поддержки ООП вроде раста и даже на чистейшем ФП. >системы - есть классы Или функция-редьюсер. >компоненты - классы Или структуры, содержащие лишь данные, которыми оперирует система-редьюсер. >сущности - классы Или кортежи компонентов. Или опять таки структуры, содержащие лишь данные.
>ЕЦС в остальных случаях - подростковый нигилизм по типу "МАМ, НЕ ХОЧУ ЗАМШЕЛЫЙ ООП, ХОЧУ ЧТО-ТО МОЛОДЁЖНОЕ" То что за 40 лет от ООП никто не умер не значит, что это что-то хорошее и нам не нужно искать более удобные альтернативы. За всю свою жизнь я никогда не видел удобночитаемого ООП кода, в какие бы сорцы я не залезал. Весь мир сейчас движется в сторону отделения данных от кода и лишь история рассудит, что лучше.
>Как по мне - важнее качественный арт и эффекты. А ещё важнее - интересный геймплей. А выигрывать кадр на синтетическом тесте, когда ещё игоря тонет - это ящитаю преждевременная оптимизация во всей красе. Это правда, но если вдруг ботлнеком станет архитектура, то придётся переписывать абсолютно всё. Лично для меня ЕЦС удобнее для организации кода, повышенная производительность это скорее побочный эффект.
>>711393 В общем, я бы на твоем месте делал так: -либо drag работает в зависимости от того, куда кликнул. Если кликнул по рабочим тайлам - то рисуешь, если по пустому месту - двигаешь карту. Это вообще говоря много где используется. -либо таскание работает только двумя пальцами. Это же вроде сейчас стандарт уже? обычно в связке с зумом, и иногда поворотом. Но тогда надо решить как таскать одной мышкой, возможно правой кнопкой.
>>711414 >Разве это не противоречит друг другу? В режиме эмуляции мыши - противоречит. В режиме здорового человека это выполняется разными устройствами и потому не возникает противоречий. Вообще, если ивент _gui_input() прописывать интерфейсным кнопкам реакцию на ИнпутИвентСкринТач, то можно обойтись без режима эмуляции. Но возникает проблема с диалоговыми окнами (в частности, FileDialog), которые уже на тач не отзываются от слова никак.
>>711418 >либо drag работает в зависимости от того, куда кликнул Не работает, если я делаю инструмент рисования, рисующий тайлы там, где пока ещё пусто. >либо таскание работает только двумя пальцами Вынос костыля на обозрение игроку. Не могу навскидку вспомнить ни одного мобильного приложения, внутри которого навигация осуществлялась бы двумя пальцами. И не мобильного тоже, если оно нативно поддерживает тач. Прямо сейчас я пишу этот пост в гуглхроме, мышью таскаю по текстовому полю - выделяется текст; пальцем вожу по экрану, вне зависимости от места на странице, - двигается страница; тыкаю пальцем или мышкой в ссылку или кнопку - она срабатывает. Это абсолютный стандарт де-факто с самого появления управления пальцами. >Но тогда надо решить как таскать одной мышкой, возможно правой кнопкой. Правой, средней - это вообще не представляет сложности. Прямо сейчас у меня это выполняется средней кнопкой. Пожалуй, правую тоже добавлю, она всё равно не задействована.
На крайний случай можно вернуть эмуляцию мыши и отказаться от навигации тачем при включённом рисовании. Но ведь предполагается, что это основной игровой режим. ИЛИ убрать возможность рисовать тасканием, а для установки тайла требовать полного цикла "нажал-отпустил".
>>711399 А как ты обошёл проблему диалоговых окон, типа FileDialog? Просто не использовал их?
>>711435 Я вижу ситуацию немного по другому - у 99% обычных людей или комп с мышкой без тача, или смартфон/планшет с тачем без мышки. Поэтому в твоем дизайне управления половина не получает одну четверть функционала, а другая половина - другую четверть. Ну если ты делаешь только для себя, то это другая история.
>>711435 > А как ты обошёл проблему диалоговых окон, типа FileDialog? Просто не использовал их? Именно так. Комповские диалоговые окна сами по себе неудобны на тач-устройствах. Там надо "диалоговые панели" однопанельного режима. Вместо тонкой строки с выбранным файлом - толстая строчища с огромными буквищами. Чтобы толстые пальцы жырных американцев попадали в неё. Большие кнопки. Список файлов не в диалоге, а вызывается отдельно поверх, модально. И тоже с жырными строками.
>>711458 В связи с вышесказанным я предлагаю ОДИН РАЗ написать себе велосипедистый тач-диалог на тач-нодах и юзать его в проектах. Сам проект при запуске знает в каокй он системе, какие у него в наличии имеются методы ввода. Сообразно этим данным проект может переключать интерфейс с того на этот и обратно.
>>711460 Слоты везде ящитаю надо делать. Большинству игроков нахуй не всралось управлять файлами из игры, отвлекаясь от ПОГРУЖЕНИЯ. Кому надо - те самостоятельно папку с сейвами забэкапят.
Всё гениальное - просто: https://www.youtube.com/watch?v=Ip5SlTlF2iQ Как я сам до этого не додумался? (А всё потому, что ещё не начал мыслить стейтмашинами. Всё есть стейтмашины!)
>>711466 Потому что честная гравитация в 9,5 метров в секунду не подходит для аркадности большинства игор. Ты когда в какую-нибудь кваку играешь, там гравитация вообще всё 100 жэ.
>>711437 Не понимаю тебя. У меня выбор: сесть на стул эмуляции мыши и лишить пользователей компьютера непрерывного рисования или посадить мать на стул раздельного тача и лишить мобильных игроков нормальной навигации. А благодаря тому, что у меня ноут с тачем, я своими руками ощущаю обе эти проблемы.
>>711475 Так ощущения от игр надо регулировать массой объекта и силой прыжка, гравитация то тут причем? Ну диды косячили, а сейчас зачем? з.ы. чекнул кваку 3, там написано sv_gravity 800, НО в коде есть умножение на 0.5. Высота персонажа 64 юнита, возьмем средний рост 180см, 1 юнит ~= 2.8125см, ускорение 400 х 0,028125м = 11,25м/c2. Что довольно близко к земному. В халве гравитация 600, то есть 8,4375м/с2
>>711479 >Не понимаю тебя. Есть клик, который приводит к драгу. Это может быть только одно действие в приложении. В тач версии ты хочешь прокрутку экрана. В ПК версии ты хочешь закрашивание тайлов. У тебя устройство где есть два разных клика. У твоих пользователей где будет только один вариант клика. Да, тебе нужно определиться что именно будет делать драг - или то, или другое.
>>711484 > гравитация то тут причем? Я сам не понимаю, причём. Все туториалы говорят, что надо настраивать ощущения гравитацией. Зделой свой туториал - с удовольствием изучу.
>>711484 >массой объекта и силой прыжка, гравитация то тут причем? Физику прогуливал? Ускорение свободного падения не зависит от массы. Есть несколько простых объяснений, почему G в играх отличается от земного. 1. Масштаб. Если персонаж ростом с человека, то всё ок, но все размеры во всей игре могут отличаться от настоящих. Потому что метрами в играх бывает неудобно пользоваться. Или потому что разрешение текстур не позволяет. Особенно актуально для двадэ. 2. Высота прыжка. Бывает так, что надо наделить персонажа более высоким (относительно его роста) прыжком. Но в таком случае он при нормальной гравитации будет прыгать слишком долго. Увеличиваем силу прыжка, увеличиваем гравитацию - готово, теперь прыжок высокий и быстрый. 3. Скорость перемещения. Прыжок должен восприниматься адекватно ей. Иначе у игрока будет ощущение, что он на Луне. А скорость перемещения обычно увеличивают в сравнении с реальным миром, чтобы не так нудно было. 4. Общая динамика. В общем случае прыжок на экране обычно ощущается вовсе не так же, как прыжок в реальности, если просто задать персонажу все характеристики, соответствующие реальному миру. Поэтому все физические параметры так, чтобы получить задуманный гейм-дизайнером геймплейный экспириенс. Или делают на отъебись, просто хоть как-то.
>>711490 Я только что привел пример квейка и халвы где гравитация примерно земная, с ощущениями все в порядке. Дальше, у тебя что у каждого существа своя гравитация будет что ли? Потому что если у тебя одна на всех, то увеличив персонажу, ты поменяешь и всем монстрам.
>>711491 И что нам до ощущений тех монстров? И, кстати, они могут и не обращаться к физическому серверу, а иметь своё ускорение падения. В твоих примерах гравитация ощутимо отличается от земной. Что таки говорит, что её настраивали в угоду геймплею.
>>711499 Не вижу в этом ничего такого. Один моб у тебя прыгает, другой летает, третий ползает, четвёртый плавает. Зачем им всем одинаковое ускорение свободного падения? Зачем этому параметру совпадать с таковым для игрока и/или физического движка?
>>711505 > Пчел, ты. Нет ты. Пролетай уже своей дорогой. Пчевелопер, блять.
Алсо, годаны, мне тут на ютубе снова советуют перекатываться на шарп с гдскрипта. Как считаете? Стоит? Полюбил я уже гдскрипт за эти джва года, но сука, и медленный же он.
>>711508 Вот мои аргументы, а ты смотри сам: 1. На гдскрипте ты можешь писать только в годоте, а сишарп много где используется. 2. С версии 4.0 мы получим уже какой-то совсем другой гдскрипт. Его очень сильно перепиливают, придётся ко многому заново привыкать. Сравнимо с освоением нового языка. Вооот.
>>711509 > какой-то совсем другой гдскрипт И кстати, в той же ветке комментов обещают устранение ботлнека. Но... Сишарп-то, он уже здесь и сейчас. А будет ли реальное устранение ботлнека в будущем?
Впрочем, надо без фанатизма. Простенькие скрипты в пару строк, из которых обе строки - дефайны переменных для редактора - вполне ок делать на гдскрипте. А вот игровую логику, со всякими сложными вычислениями октодеревьев поведения, это всё таки надо на шарпе. А лучше сразу конпелять модули на си. Но в настоящий си я пока ещё не могу. Увы.
>>711511 > Сишарп-то, он уже здесь и сейчас А ещё в сишарп-солшене, как я заметил, можно прокидывать ссылки из проекта в проект, и следовательно, можно прикрутить к игровой сборке внешний экзешник. Возможностей море: Конфигуратор? Да! Сервер? Да! Интеграция с СУБД? Да! Драйвер защиты? Да! И это только навскидку.
>>711506 Я думаю что ты споришь просто ради того чтобы спорить, и зачем то защищаешь плохой подход. Например у Area и Area2D есть свойство gravity, по умолчанию равное 9.8. То есть ты можешь его изменять, создавая области с другой гравитацией. А у тебя уже везде своя вписана, то 20, то 25. >>711490 >Физику прогуливал? Ускорение свободного падения не зависит от массы. Перечитал с утра свой пост. Там сказано что ощущения от игры должны зависеть от массы. Так что все верно. Масса влияет на действующую на объект силу. Я не предлагал менять массой ускорение свободного падения.
>>711556 > Я думаю что ты споришь просто ради того чтобы спорить, и зачем то защищаешь плохой подход. И БАЦ > Например у Area и Area2D есть свойство gravity, по умолчанию равное 9.8 Пчел, ты... Во всех примерах выше, к которым ты (или кто там) доебался до гравитации, используется, блять, KINEMATICBODY, у которого главная фишка в упрощенном взаимодействии с физическим сервером. Всю кинематику разраб должен реализовать сам: движение, ускорение и т.п. Классика геймдева, блять, это знать надо!
Хочешь делать контроллер персонажа на RigidBody? С достоверными физическими параметрами? Как тебе уже указали выше, готовься к скучному и медленному геймплею. Окажется, что персонаж не носится по карте, как паровоз, при это мне разгоняется мгновенно, не тормозит мгновенно. А медленно ходит!! Оказывается, персонаж не может прыгнуть выше, чем на 20 см! Ни о каких прыжках через бочки и заборы речи быть не может.
>>711576 Пчел, ты... Где ты увидел хоть слово про RigidBody? Почему ты не можешь для KinematicBody подхватывать значение гравитации из того в какой зоне находишься? > Оказывается, персонаж не может прыгнуть выше, чем на 20 см! За это отвечает jump_force, а не гравитация, даже в самых парашных туторах.
Предлагаю лучше вот что обсудить. Как правильно делать лифты? Меня интересует, чтобы персонажи не падали следом за лифтом, если лифт движется быстро: как знаете, в старых игорах, когда садишься в лифт и чувствуешь заметное неприятное дрожание вверх-вниз из-за того, что лифт уезжает из под ног персонажа, персонаж переходит в режим падения, потом моментально касается пола и переходит обратно в режим стояния, но лифт продолжает уходить вниз. И так с частотой 60 герц нахуй. А если подпрыгнуть - получишь дамаг от падения! Неприемлемо! Как грамотно реализовать правильную кинематику с накладными силами и относительными системами отсчёта?
Я щас капчую с калькулятора, поэтому не могу проверить, решает ли проблему прикрученная к лифту Area с параметром Replace? По идее этот параметр для этого и нужен, чтобы персонажа тянуло за платформой?
>>711556 >Перечитал с утра свой пост. Возможно, ты не заметил, но я тут не один с тобой спорю. Как минимум ещё один анон на стороне раздельных гравитаций. И в моём посте вообще нет ни слова про массу.
Кстати, вспоминай: за что отвечает масса в реальном мире? Помнишь, как на БАКе искали бозон Хиггса? А зачем он нужен? А он нужен для инерции. Масса отвечает за инерцию, и это ныне считается одним из фундаментальных взаимодействий. Так вот. Если у тебя есть массивный объект, который движется по всем законам физики, он будет, как верно заметил анон выше, жутко инертный. Он, в отличие от живого персонажа, не сможет а) сохранять вертикальное положение тела, б) резко тормозить, перемещая центр тяжести. Но это всё ладно. Мы же тут о прыжках говорим. И вот, в этом-то процессе масса влияет на высоту прыжка, но не влияет на скорость. Потому что Velocity.y += G * delta, массы в этой формуле нет. Как видно из формулы, для регулировки скорости прыжка единственная доступная переменная это гравитационная постоянная.
>>711576 >Хочешь делать контроллер персонажа на RigidBody? Кстати, а я делал. Только это был вертолёт. Для вертолёта такой подход очень даже гуд. Хотя, конечно, управлять им оказалось довольно сложно. Но весело, особенно когда сначала побегаешь по уровням как человек-кинематик, а потом садишься за штурвал тяжёлой неповоротливой машины, вооружённой бесконечным пулемётом и ракетами.
>>711609 >лифты Тут было бы что обсудить, но у геймэндевора эта тема полностью раскрыта. Вопросы могут быть только с конкретной реализацией.
>>711610 У геймэндевора забавная дикция. И юморок такой, тролячий характерный. Смотрю щас. И он такой > мы работали над проектом с pigdev, райаном флури и > МЗЫЗЫ, ЗЫ-ЗЫ, ЗЫ-ЗЫЗОМ От так прям нараспев и прожужжал, >_<, пчел...
>>711509 > С версии 4.0 мы получим уже какой-то совсем другой гдскрипт С сеттерами-геттерами прямо в инициализаторе, прямо как в шарпе. Первый шаг к лямбдам. А с лямбдами это будет просто топ-писечка, а не язык. И с доведённой до ума типизацией методов.
Чайник спрашивает. Как сделать персонажу возможность "подниматься" по ступенькам? Ну или подниматься на небольшие выступы, не подпрыгивая, аки на трамплине.
>>711833 Самый простой способ - делать коллайдер наклонным, без всяких ступенек. Более сложный - там делается рейкаст. Если на пальцах, то если "ботинок" уперся в ступеньку, но на уровне коленки нет препятствия, то ты делаешь небольшой подпрыг.
>>711837 >делать коллайдер наклонным У меня тогда на платформе "лифта" ГГ или залезает, подпрыгивая, или не залезает. А вот за способы с рейкастом пасыбо, попробую.
З.Ы.: Изменил полигон ГГ в состоянии стояния обратно на коллижншейп - и её перестало коноёбить на быстро поднимающемся лифте. Две проблемы решены.
>>711833 Гораздо круче завязать подъём по ступенькам на инверсную кинематику: у каждой кости ступней ног персонажа приаттачена нода с коллиженшейпом. При анимации ноги перемещаются. Если нога на что-то встала, персонаж перемещается относительно ноги так, что поднимается вверх на высоту ступеньки. Потом движение продолжается и другая нога становится на следующую ступеньку. А рейкасты и подпрыгивания - это прошлый век. Век капсулей вместо полноценного кинематического тела.
>>711929 >у каждой кости ступней ног Ну, это, конечно, интересно, но для моих навыков ЖДскрипта уровня "посмотрел три туториала, вырвал по куску кода и собрал гомункула" это непосильное дзюцу.
>>711943 > непосильное дзюцу Я тут в соседнем разделе скроллил глагне и там кароч написали, что программисты переоценены, потому что занимаются примитивными вещами, для которых большого ума не надо. Ну, типа кодинг - это настолько просто, что непонятно за что там всяким сеньорам-девелоперам плотют такие сотни космокредов? Я хотел было возразить, но поразмыслив, не стал ввязываться. Потому что программирование (для меня) это в основном однообразно и муторно. Кодогенерация лепит хуйню, которая меня не устраивает, приходится копипастить тысячи строк бойлерплейта ручками. Для того, чтобы в конце сложить 2 + 2 и разделить на 3 и помножить на дельту. А в нашем годоте кодогенерации и подавно нет. Да я только за эту муторность и требовал бы 100500баксовый оклад. А сложного для меня тут давно ничего нет. Аттач нод к костям скелета? Что тут может пойти не так?
>>711929 Смотрю современные игры и там капсула, а ик ног только для красоты, часто проваливается.в ступеньки иди висит в воздухе. Видать сильно ненадежно, застрять может.
>>711955 Ну смотри, шейпы на ногах не ВМЕСТО капсулы, а вместе с ней. Тут я немного приукрасил, признаю. В целом, удобное и универсальное перемещение (как это вижу я) реализовано, как две ноги с жопой. Персонаж постоянно сидит на жопе, а ногами передвигает жопу в нужном направлении. Сорян за лексику. Это не троллинг, просто так короче передать образную суть.
>>711958 Ах да, в случае со ступеньками, ноги работают как детекторы поверхностей, почти как рейкаст, но во первых, они завязаны на анимацию, у тебя всё равно будет анимация ходьбы, и всё равно инверсная кинематика будет, так почему бы не задействовать имеющуюся систему, чем лепить рейкаст? Во вторых, рейкаст во всех имеющихся примерах завязан на подпрыгивание персонажа, а вариант с капсулой и ногами похож на лебёдку. Нога на ступеньке плавно подтягивает остальное туловище наверх.
Я только что подумал, что идеально это реализовать приделав капсуле на джойнтах две палки. Завтра потестирую, если не лень будет. Две палки начинают вращаться, как водяные колёса у парохода, когда игрок нажимает клавишу или кнопку ВПЕРЕД. Палки прикручены джойнтами так, что они чуточку длиннее капсулы внизу таким образом они толкают капсулу мелкими шажками вперёд, и если впереди ступени, то одна из палок, попав на ступеньку, перекатит всю конструкцию дальше. При этом, если упрёшься в стену, длины палок не хватит, чтобы заползти вверх. Впрочем, если стена ячеистая. Хммм.... Надо потестить.
>>711966 В общем, это работает. Но надо подгонять параметры. И работает только на ригидах. То есть все туториалы по контроллеру на кинематиках сразу идут лесом.
И да, идея не моя, видел такую игру у китайцев. Там ещё надо себе ноги нарисовать, потом включается забег и твой куб должен обогнать куб соперника, бешенно вращая нарисованными тобой ногами.
Антон, в чём может быть причина? Тайлы в тайлмапе отрисовываются в виде чёрных квадратиков. Но только в веб-версии, запущенной с мобилы. Веб-версия на десктопе и полнокомпьютерные версии рисуются нормально. Тайлсет обычный, атласом, без шейдеров. Поверх тоже никаких шейдеров не накладывается. Может, какую где компрессию текстур подкрутить? Погуглил, нашёл похожий симптом, но только платформонезависимый.
>>712086 > сверхбыстро работающий дварфортресс с миллионом юнитов Сто раз обсуждали, что такие вещи делаются на самописных узкоспециализированных движках. Впрочем, ты можешь скачать исходники годо, переписать часть модулей под свою задачу, дописать свои модули, выкинуть лишние. Собрать. Сделать игру.
> Зачем мне ковыряться в чужом движке, если я могу написать свой? Действительно. Тред движкописей тут недалеко.
> Зачем мне ковыряться в чужом движке, если я могу взять %движокнейм%, в котором есть %фичанейм%? С такими вопросами в движкосрач тред. Пропукайся там и как попустит - возвращайся. Или не возвращайся.
>>712086 Сомневаюсь что компьют шейдер поможет - вроде бы они помогают при распараллеливании, а у тебя будет зависимость гнумов от действий других, то есть последовательно.
>>712109 Те коллизии и физику считают на видюхе, а гнумов нельзя? Так то это как-то не честно. В общем, вполне в шейдер можно передать массив гнумов и их определенным способом двигать. Либо сделать кучу текстур, которые бы цветом кодировали переменные и состояния гнумов. В общем, вариаций моего доблоебства можно придумать много. >>712095 Такие вещи делаются в Юнити, тк оно может ретурнить текстуру, которую поменял шейдер, чтобы снова пихнуть ее в шейдер. Это позволяет писать на шейдерах божественную физику, которая не требует почти никаких ресурсов. Это довольно неплохо. Как минимум для годота, спамящего дравколы на каждую букву.
>>712058 >Дак прям в настройках экспорта и крути. Ничего не поменялось. >>712064 >GLES2 включил? Изначально на нём и делал.
А ещё я тут заметил, что кисть, которой внутри игры рисуются тайлы, тоже отображается чёрным квадратом. А кисть это просто спрайт, берущий текстуру тайлмапа и обрезающий её необходимым образом. Может ли быть проблема в текстуре? Она довольно большая, 5120х1024.
>>712122 Таки да, дело оказалось в размере тайлмапы. Сжал её в два раза, стало всё нормально рисоваться. Теперь вот только предстоит развлекаться с масштабированием всего в игре, потому что в годот не завезли нормальный скейл для тайлмапа, который бы не затрагивал его потомков, координаты мыши и прочие важные характеристики.
Хочу запилить модную фичу: при сохранении игры берётся скриншот, кладётся в папку с сейвами, в списке сохранений отображается миниатюрка. Но не тут-то было. Как взять скриншот игрового поля, если поверх прямо в данный момент отрисовывается окно сохранения? Ну, допустим, как-то взяли. Но Годот не умеет подгружать текстуры без предварительного импорта. И как это обойти, тоже чёт хз. Годаны, вы бы как это решали? В общих чертах.
>>712183 С подгрузкой текстур таки разобрался: var image = Image.new() var err = image.load("path/to/the/image.png") if err == OK: texture = ImageTexture.new() texture.create_from_image(image, 0) Работает, миниатюры успешно отрисовывает. А вот как делать скриншот-не-скриншот, когда поверх открыто окно, я чёт пока не понимаю.
>>712183 1. Делать скриншот ДО вывода окна сохранения? Ты же контролируешь когда оно появится при нажатии на кнопку. 2. Рендерить игру куда то во Viewport
>>712232 Если ему понадобится сохранять игру в диалоге списка сейвов? Как это практиковалось в ряде игор 2000х годов? Либо трюк со скрытием этого диалога на один фрейм для скриношота. Либо ебаться с вьюпортами.
>>712230 Эммм... пиздос. Это всё работало в 2017 году. Сегодня все эти кэпчуры выпилили. попытка декодировать текстуру вьюпорта у меня только что провалилась (выдаёт сырые гл-данные, которые надо хитрым образом конвертировать, попытка их напрямую заюзать приводит к созданию пустого объекта-пикчи). Надо убегать по делам. Напомни вечером тебе рабочий пример допилить.
>>712257 Откуда ты знаешь, что он схороняться собрался, а не звуку прибавить? В принципе можно при каждом входе в менюшки делать скриншоты, а потом удолять, но зачем?
>>712273 Он этого не говорил. Это я говорил. И ещё я сразу написал, зачем: >>712237 > Если ему понадобится сохранять игру в диалоге списка сейвов? Как это практиковалось в ряде игор 2000х годов? Либо трюк со скрытием этого диалога на один фрейм для скриношота. Либо ебаться с вьюпортами.
>>712274 Так если он быстрый что быстрее кадра, то что плохого в том чтобы делать скрин в момент нажатия кнопки меню? Вот если скрин делается медленно, тогда уже да. Надо потестить.
>>712276 > что плохого в том чтобы делать скрин в момент нажатия кнопки меню В том, что это оверхэд. Неизвестно где и когда он выскочит. Следует избегать оверхэда в проектировании проектов.
>>712278 Пока что у меня get_viewport().get_texture().get_data() возвращает чёрный квадрат. Как разберусь с этим - так и узнаю, быстро или нет. И если окажется, что нет, у тебя будет ещё один повод попукать в срачетреде одебилевших пуконюхов.
>>712280 Что, даже в оф демке? Возможно трабла в дровах? https://godotengine.org/asset-library/asset/130 (у меня есть один забавный ноут, на котором opengl не умеет рисовать прозрачные окна. На всех умеет, а на нем черный фон)
Если просто доставать вьюпорт 65 миллисекунд, если ресайзить (нам ведь миниатюра нужна, не так ли?) то ещё больше выходит 100 миллисекунд. Конвертация в Б64 с сохранением в ЖСОН, полной текстуры цельная секунда! Но это безумие, если и схоронять, то миниатюру, миниатюра 160x120 пикселов - 130 миллисекунд и 200Кб текстового файла вида {"image" : "HURRRDURRDURRRRRDRAAAAAAAAGHHHH="}
>>712301 Можно написать свой ресайзер на с++, который считывает точки только через каждые N координат, и записывает байты сразу в неупакованный png к примеру.
>>712303 Можно. На этапе постпродакшена. Когда уже есть игра и автором-художником нанимается кодер-сишник за понюшку творожка в час, чтобы её оптимизировать.