насрал любовью в этот тред
Ну че анонасы. Расскажите про C# в Годоте. Он равноценное положение с ГДскриптом занимает или там костыли?
Ничто не может быть равноценнее гдскрипту, ибо он сделан специально под движок. Как минимум в редакторе нет такой поддержки интеллисенца. То есть, как минимум вс-коде тебе надо поставить для удобства скриптинга.
Однако, на уровне доступа к объектной модели движка шарп вполне полноценен. Официальные туториалы и гайды на сайте написаны на обоих языках и ты можешь сам лично сравнить, что они успешно делают одинаковые вещи.
Заглянул щас в доки, чтобы тебе скрин принести, а там оказывается ещё и кресты добавили.
Го смотреть видосик
https://www.youtube.com/watch?v=LKjPvtFopII
https://www.youtube.com/watch?v=LKjPvtFopII
На подходе, и что? .Net6 научит лучше кодить?
> юникье нэймс
Решение говно, потому что плодит синглтоны.
Если бы я был Хуаном, я бы сделал как в старом добром Дельфи: манипуляции с нодами в редакторе приводят к обновлению их ссылок в коде. Если код есть. Если в коде есть ссылки на изменившиеся ноды. ХЗ как это сделать, но это надо сделать. Иначе не победим. Хуан, делой!
Да, понял уже. Поначалу я подумал, что установка % создаёт глобальное имя для скриптов, аналогичное автозагрузкам. А потом подумал, а как это будет работать без загрузки вообще? А никак. Следовательно, это %имя уникально только внутри сцены.
Давно уже заметил эту фичу (в ранних сборках 3.5), но до сих пор сомневаюсь, использовать ли её.
>Дельфи
>манипуляции с нодами в редакторе приводят к обновлению их ссылок в коде
>ХЗ как это сделать, но это надо сделать
Я много использовал Delphi/Lazarus и в некоторой степени разбираюсь в этой теме (но не полностью).
В Delphi/Lazarus создание новой формы (а.к.а. окно виндовс или линукса) создаёт сразу два файла: в одном (.pas) находится код модуля на (Object/Free) Pascal, а в другом - сериализованные данные формы в простом текстовом формате (.dfm/.lfm, угадай расшифровку, лол).
В коде модуля описывается потомок TForm, которому перезаписываются обработчики событий (в Godot события называются сигналами, суть одна и та же) и добавляются published поля. Поля published отличаются от public тем, что компилятор генерирует RTTI информацию об этих полях, чтобы была доступна сериализация и десериализация - т.е. к этим полям есть доступ из редактора форм и инспектора компонентов формы.
Изменённые через редактор форм или инспектор компонентов значения в published полях сохраняются в файл данных формы. Когда приложение запускается, эти данные автоматически десериализуются, т.е. экземпляр объекта, который описывает окно, принимает все значения из этого файла. Создание новых компонентов на форме создаёт новые published поля.
К примеру, если мы поместили на форму Label, в классе Form1 из файла form1.pas появится новое published поле Label1: TLabel, а в файле form1.dfm (form1.lfm) появится соответствующие записи для настройки экземпляра TLabel, в первую очередь его положение и размер на форме, а также текстовая надпись. Меняя имя Label1 на что-то другое (более осмысленное) через редактор, автоматически меняется имя поля в коде и данных формы.
Возвращаясь к Godot: аналогом .dfm/.lfm является .tscn, отличие только в том, что в Godot нет жёсткой связи "форма = модуль", т.е. можно создавать несколько скриптов, связанных с одним .tscn (или даже вшитых в него). Поскольку скрипты GDScript не связаны жёстко с конкретным .tscn файлом, ссылки в них не обновляются редактором автоматически. Чтобы сделать поведение, идентичное поведению редактора форм Delphi/Lazarus, нужно каким-то образом отметить скрипт привязанным к конкретному .tscn и автоматически заполнять его ссылками на все ноды конкретной сцены, обновляя эти ссылки при изменении порядка нод или их имён. Но на практике такое редко нужно, тебе нужны всего несколько нод из длинной иерархии сцены, следовательно, было бы нерационально делать такое поведение по умолчанию. Возможно, его можно реализовать с помощью плагинов в tool режиме.
В сущности, $%ссылка в большей степени напоминает published поля в Delphi/Lazarus, чем $путь/ссылка, потому что формы Delphi/Lazarus тоже имеют древовидную иерархию, но объявленное published поле не зависит от этой иерархии. Проблема только в том, что в Delphi/Lazarus эти поля гарантированно указывают на компонент, а $%ссылка в Godot вычисляется динамически в рантайме, т.к. разворачивается как self.get_node("%ссылка"). Т.е. для 100% соответствия тебе нужно писать так:
>onready var _node := %node
И в случае переименования ноды менять эту строку вручную. Да, не очень удобно, было бы хорошо автоматизировать этот процесс.
Ещё такой вариант приходит на ум:
>export var node_path: NodePath
>onready var _node: get_node(node_path)
Слово export == published, но, поскольку мы можем экспортировать только текстовую ссылку (NodePath), нам нужно дополнительно явно найти ноду по этому пути перед началом работы. Не очень удобно и имеет смысл только если мы используем один скрипт во множестве мест, позволяя пользователю изменить ссылку на ноду через инспектор (указать в .tscn, к которому подключён данный скрипт).
Хм... Я думаю, идеально было бы, чтобы специальная галочка в выпадающем меню не просто делала %ссылку, но добавляла её в выбранный "главный" скрипт сцены и/или автоматически меняла её во всех активных скриптах в случае переименования ноды. Но, вообще-то, вряд ли это поведение подходит Godot из-за того, что мы можем назначать скрипты каждой ноде. Вот если бы каждая сцена могла содержать только один скрипт...
>Можно придерживаться правила
Можно, никто не спорит. Но как сообщить движку о том, что мы решили придерживаться этого правила? Ведь мы говорим о том, чтобы движок автоматизировал часть работы по сбору ссылок на ноды в одном месте. Он этого не делает, потому что ему неизвестно, хотим ли мы так делать или нет. Движок не навязывает ссылаться на ноды из корневой ноды, поэтому нет механизма автоматического сбора ссылок в скрипте корневой ноды.
Вот в Delphi/Lazarus такой неоднозначности нет, ты в любом случае пишешь все обработчики событий формы в одном модуле, который аналогичен .gd скрипту Godot. Поэтому Delphi/Lazarus может автоматизировать часть работы, собирая все ссылки в одном месте и обновляя их имена в случае необходимости.
Когда переименовываешь файл ресурса, годот автоматически обновляет все ссылки на него во всём проекте.
Поэтому это не проблема, чтобы собирать, хранить и обновлять ссылки. Просто у разрабов (я верю) до этого ещё руки не дошли. Тут проблемы посерьёзнее надо решать. Так что ждём.
>годот автоматически обновляет все ссылки на него во всём проекте
В теории, а на практике я часто сталкиваюсь с багами при переименовании или перемещении файлов. Какие-то ошибки в журнале, сцены приходится переоткрывать, а то и целиком редактор перезагружать, фантомные файлы в редакторе скриптов и т.п. Недавно решил переместить папку шрифтов - пришлось потом вручную через консоль винды сканировать файлы на наличие ссылки на шрифт, открывать блокнотом и исправлять, потому что движок сам почему-то это сделать не смог. Не знаю, что из этого исправили в релизе 3.5, но переименование и перемещение файлов в проекте - лотерея.
На годоте есть игры с пс1 лайк графоном? Ну или демейк графоном, хз как эта хрень правильно называется
Это называется "очередной зумерский говнозакос под ретро". В пиксель-арт уже сейчас так просто не влезешь, его рисовать уже научились, и кривые пиксельные человечки с конечностями-макаронинами уже давно не катят, так что говноделам пришлось найти новую отдушину.
Годот не требует ставить сплеш-крин и как бы то ни было ещё сообщать, на каком движке сделана игра. Поэтому на годоте существует множество игор, о которых вообще неизвестно, что они на годоте, пока не залезешь в папку с игрой и не найдёшь там пак-файлы. И то нужно их проанализировать, потому что пак-файлы много у кого есть.
> image.png
Удваиваю. Игоры на восьмибитках - это мастерпис древних мастеров, которые при ограничениях железа создавали красоту. Зумеры же не видят там красоту, они видят уёбищные пиксели и думают, что надо надрачивать на уёбищность, и делают уёбищное "ретро". А надо всего лишь быть мастером и создавать красоту. Не уёбищность, зумеры, не закос под А или Б.
Прекрасная иллюстрация поста выше. Афтар высера видит в ретро играх не попытки сделать красиво в условиях ограниченных ресурсов, а попытки сделать уёбищно. Пикселизированное тридэ из лоуполи и КВАДРАТОВ.
Вот я помню денди игры как нечто красивое. Когда запускаю эмуляторы я в упор не вижу той красоты, которую запомнило моё детское сознание. Поэтому я никогда в жизни не буду делать это ретро-говно. Тебе дали холст. Тебе дали кисть. Рисуй, блять.
>Удваиваю
Я к тому, что это раньше такая ситуация была. За последние годы я не припомню, чтобы выходила какая-нибудь популярная пиксельная игра с хуевым пиксель-артом, типа как в VVVV или Hotline Miami. Думаю, и здесь постепенно наловчатся, и все эти говнохорроры будут забыты как страшный сон.
Все это здорово, но проблема в том, что не все рисовать умеют.
> не все рисовать умеют
И я тоже не умею. Пытался научиться, потерпел крах. И художники, суки, знают себе цену! Знают, что рисовать так просто не научишься. Такие ценники заламывают за работу, охуеть просто! Откуда у нищего хикки такие деньги? Так и сидим без игор.
ХОЧЕШЬ ДЕЛАТЬ ИГОРЫ
@
ТЕБЕ ГОВОРЯТ ЧТО НУЖНО ПРОГРАМИРОВАЙ
@
УЧИШЬСЯ ЭТОМУ ПРОГРАМИРОВАЙ
@
ПРОХОДЯ ГОДЫ
@
УРОВЕНЬ ПРОГРАМИРОВАЙ ДОСТАТОЧЕН ДЛЯ ГТА ТВОЕЙ МЕЧТЫ
@
ПОНИМАЕШЬ ЧТО НЕ УМЕЕШЬ РИСОВАЙ
@
ТВОЯ ГТА МЕЧТЫ НИКОМУ НЕ НУЖНЫ ПОТОМУ ЧТО В НЕЙ НЕТ КРАСИВОГО РИСОВАЙ
@
ЧТОБЫ НЕ УМЕРЕТЬ С ГОЛОДУ УСТРАИВАЕШЬСЯ В КАНТОРУ МОБИЛЬНОЙ ТРИВРЯД
>======================================================
ХОЧЕШЬ ДЕЛАТЬ ИГОРЫ
@
ЗАБИВАЕШЬ НА ПРОГРАМИРОВАЙ И УЧИШЬСЯ РИСОВАЙ
@
ПРОХОДЯТ ГОДЫ
@
ПОНИМАЕШЬ ЧТО НЕ УМЕЕШЬ ПРОГРАМИРОВАЙ
@
НО ТЕБЕ И НЕ НУЖНО
@
ЛУЗЕРЫ ВЫБРАВШИЕ ПРОГРАМИРОВАЙ НАПИСАЛИ ТЕБЕ БЕСПЛАТНЫХ БИБЛИОТЕК ДВИЖКОВ И ВИЗУАЛЬНОЕ ПРОГРАМИРОВАЙ
@
НО И ЭТО ТЕБЕ НЕ НУЖНО
@
ПРОДАЕШЬ ДВЕ ПИДОРСКИЕ ПИКЧИ С ФУРЯМИ
@
ПОКУПАЕШЬ ИТ ОТДЕЛ ПОЛНЫЙ ЛУЗЕРОВ КОТОРЫЕ ВЫБРАЛИ ПРОГРАМИРОВАЙ И ТЕПЕРЬ ГОТОВЫ ПАХАТЬ ЗА ПЛЕВОК В РОТ
@
ДЕЛАЕШЬ ТРИВРЯД СВОЕЙ МЕЧТЫ
@
ТЕБЕ ГОВОРЯТ ЧТО НУЖНО ПРОГРАМИРОВАЙ
@
УЧИШЬСЯ ЭТОМУ ПРОГРАМИРОВАЙ
@
ПРОХОДЯ ГОДЫ
@
УРОВЕНЬ ПРОГРАМИРОВАЙ ДОСТАТОЧЕН ДЛЯ ГТА ТВОЕЙ МЕЧТЫ
@
ПОНИМАЕШЬ ЧТО НЕ УМЕЕШЬ РИСОВАЙ
@
ТВОЯ ГТА МЕЧТЫ НИКОМУ НЕ НУЖНЫ ПОТОМУ ЧТО В НЕЙ НЕТ КРАСИВОГО РИСОВАЙ
@
ЧТОБЫ НЕ УМЕРЕТЬ С ГОЛОДУ УСТРАИВАЕШЬСЯ В КАНТОРУ МОБИЛЬНОЙ ТРИВРЯД
>======================================================
ХОЧЕШЬ ДЕЛАТЬ ИГОРЫ
@
ЗАБИВАЕШЬ НА ПРОГРАМИРОВАЙ И УЧИШЬСЯ РИСОВАЙ
@
ПРОХОДЯТ ГОДЫ
@
ПОНИМАЕШЬ ЧТО НЕ УМЕЕШЬ ПРОГРАМИРОВАЙ
@
НО ТЕБЕ И НЕ НУЖНО
@
ЛУЗЕРЫ ВЫБРАВШИЕ ПРОГРАМИРОВАЙ НАПИСАЛИ ТЕБЕ БЕСПЛАТНЫХ БИБЛИОТЕК ДВИЖКОВ И ВИЗУАЛЬНОЕ ПРОГРАМИРОВАЙ
@
НО И ЭТО ТЕБЕ НЕ НУЖНО
@
ПРОДАЕШЬ ДВЕ ПИДОРСКИЕ ПИКЧИ С ФУРЯМИ
@
ПОКУПАЕШЬ ИТ ОТДЕЛ ПОЛНЫЙ ЛУЗЕРОВ КОТОРЫЕ ВЫБРАЛИ ПРОГРАМИРОВАЙ И ТЕПЕРЬ ГОТОВЫ ПАХАТЬ ЗА ПЛЕВОК В РОТ
@
ДЕЛАЕШЬ ТРИВРЯД СВОЕЙ МЕЧТЫ
Спасибо! Самый мощный из бугуртов, виденных мной! Пердак улетел на орбиту Сатурна, блять.
>ЧТОБЫ НЕ УМЕРЕТЬ С ГОЛОДУ УСТРАИВАЕШЬСЯ В КАНТОРУ МОБИЛЬНОЙ ТРИВРЯД
>ДЕЛАЕШЬ ТРИВРЯД СВОЕЙ МЕЧТЫ
Что бы ты не выбрал, ты обречён сделать 3 в ряд.
Годаны, хуле я такой сложный? Прочёл этот пост и решил по быстрому набросать три-в-ряд на годоте
> ты обречён сделать 3 в ряд
И уже джва часа сижу размышляю, как удобнее организовать хранение игровым полем видов выпадающих элементов?
> ты обречён сделать 3 в ряд
И уже джва часа сижу размышляю, как удобнее организовать хранение игровым полем видов выпадающих элементов?
>как удобнее организовать хранение игровым полем видов выпадающих элементов?
Тебе будет достаточно этого
https://docs.godotengine.org/en/stable/classes/class_poolbytearray.html
0 - пусто,
1 - клубничка,
2 - морковка,
и т.д., можешь хоть 255 видов сделать.
А чтобы читабельно было, делаешь enum
>enum Type {EMPTY, STRAWBERRY, CARROT, ...}
Хотя для 3-в-ряд сегодня никакие оптимизации не нужны, можешь делать обычный массив массивов variant и набивать его словарями, лол.
>Вот я помню денди игры как нечто красивое. Когда запускаю эмуляторы я в упор не вижу той красоты, которую запомнило моё детское сознание.
С одной стороны, если ты действительно был маленьким ребёнком, тебя в принципе любое интерактивное говно на экране телевизора могло впечатлить. Странно, что не сработал эффект утёнка, но об этом ниже.
С другой стороны, старые игры, создававшиеся для ЭЛТ-мониторов и телевизоров, действительно по-другому выглядят на ЖК и ОЛЕД дисплеях. У ЭЛТ нет "пикселей" в современном понимании и много других особенностей. Часть особенностей можно эмулировать шейдерами, но всё равно полного сходства не добиться.
>никогда в жизни не буду делать это ретро-говно
Это потому что у тебя эффект утёнка не сработал, не произошло импринтинга "видеоигры = пиксели". Для людей, которые выросли на этих древних играх, любые "пиксели" могут вызывать ностальгию и симпатию, потому что у них мозг так прошит, и эта прошивка останется на всю жизнь, время тут ничего не изменит. Смирись, что ты унылый графодрочер, и тебе 4К разрешение милее цветных квадратиков.
>УРОВЕНЬ ПРОГРАМИРОВАЙ ДОСТАТОЧЕН ДЛЯ ГТА ТВОЕЙ МЕЧТЫ
>ТВОЯ ГТА МЕЧТЫ НИКОМУ НЕ НУЖНЫ ПОТОМУ ЧТО В НЕЙ НЕТ КРАСИВОГО РИСОВАЙ
Если ты такой дофига крутой программист, ты можешь процедурно генерировать графику, карту мира, персонажей, сюжет, музыку и озвучку, вообще всё. Алсо можешь наделить ИИ самосознанием и т.д. То есть твоя ГТА будет уникальной, какой ещё не делали, а на качество графики можно будет сказать "ну она же процедурная, а не какие-то там готовые ассеты от унылых художников". Процедурка - это всегда плюс любой игре. Вот рокстары не стали вводить в ГТА процедурку и проиграли Майнкрафту, а если бы ГТА была процедурной, заработала бы больше Майнкрафта.
>ПРОДАЕШЬ ДВЕ ПИДОРСКИЕ ПИКЧИ С ФУРЯМИ
Ты думаешь, что это очень просто, смотря на топовых художников с фураффинити или видео с популярных каналов о рисовании. Но реальность такова, что художников сегодня слишком много, все ниши заняты и новичка будут игнорировать или натурально давить независимо от его навыков. А без аудитории тебе некому "продавать картинки", потому что картинки не продают, их заказывают, а чтоб заказывали, нужна уверенность в том, что ты реально что-то сделаешь... Короче, начать зарабатывать художником чуть ли не сложнее, чем выпустить игру и получить с неё какие-то деньги. Алсо коммьюнити - если в геймдеве все друг друга любят независимо от инструментария и интересов, то художники максимально токсичны и готовы часами доказывать, почему ты никчёмное говно и ничего не добьёшься. Возможно, защищают свою нишу от конкурентов. Или компенсируют то, что сами никому не нужны. В любом случае страдать тебе, если захочешь стать художником.
>ДЕЛАЕШЬ ТРИВРЯД СВОЕЙ МЕЧТЫ
Вот-вот, максимум художников в геймдеве - это мини-игры на основе готовых шаблонов и всякие недоигры вроде визуальных новелл. Очень мало реально годных игр, в которых графика не выглядела бы сделанной на коленке или процедурно. Тяп-ляп и готово, остальное вытягивает геймплей, которого в играх художников просто нет.
Ты блять, сам себе противоречишь. Послушай себя! Ностальгия привязана не к пикселям, а к образам, которые передавались через ЭЛТ-телевизоры. Теперь эти твои воображаемые утята-импринтята видят пиксели уже на ЖК-дисплеях и? И что?
> Короче, начать зарабатывать художником чуть ли не сложнее, чем выпустить игру
Просто блять выкладываешь свои работы в паблик в течение полугода. И всё, блять. Если есть талант - заказы летят как горячие пирожки.
Полезное.
Собираюсь сделать на годоте top-down шутанчик, опыта в геймдеве нету. Подводные?
> Подводные?
Хуй забьёшь через неделю. Тру стори.
В годоте ось Y направлена вверх? Я думал что она вниз, но:
1. в эдиторе ось вверх
2. Vector3.UP = (0, 1, 0), не (0, -1, 0)
2. move_and_slide тоже определяет Y+ как верх
Чзх, пацаны? Я так и не смог нагуглить когда это поменяли, в доках тоже вроде вниз.
1. в эдиторе ось вверх
2. Vector3.UP = (0, 1, 0), не (0, -1, 0)
2. move_and_slide тоже определяет Y+ как верх
Чзх, пацаны? Я так и не смог нагуглить когда это поменяли, в доках тоже вроде вниз.
В тридэ игрек вверх направлен.
> в доках тоже вроде вниз
Нэтъ.
Тогда в 2д вниз? Лол ок.
И сразу еще вопрос, почему в углу тени как бы светлее? Это индирект лайт такой? И почему тогда у верхних краев стен темнее? На сцене только один direct light.
Точнее не тени а сами стены.
>Процедурка - это всегда плюс любой игре.
Только в твоей голове. В реальности это безыдейная пустая ебанистика.
>Ты думаешь, что это очень просто, смотря на топовых художников с фураффинити или видео с популярных каналов о рисовании.
Я думаю что очень просто, смотря на фетишных извращенцев, продавать маляму сомнительного качества лишь бы хоть как запечатлеть на цифровом холсте их ублюдские фантазии. А для этого достаточно постить свое барахло на любом популярном ресурсе с поддержкой эротики.
На мой говнокод ни у кого в трусах не затвердеет чтобы кидать в экран деньги (НАПИШИ КОД БЕЗ ОТСТУПОВ У МЕНЯ СТОИТ НА КОД БЕЗ ОТСТУПОВ).
>Тогда в 2д вниз? Лол ок.
В Годо чёткое разделение между 2D и 3D.
В 2D операции с пикселями и координатами экрана, которые классически от левого верхнего угла вправо (X) и вниз (Y), соответственно ходу луча развёртки.
В 3D абстрактные оси координат. У них тоже есть какое-то классическое исполнение, но в разном 3D софте оно разное, нет строго определённого.
>почему в углу тени как бы светлее?
>только один direct light
Скорее всего это протекание света.
Поиграйся с настройками теней:
https://docs.godotengine.org/en/stable/tutorials/3d/lights_and_shadows.html
Как не терять мотивацию делать игру? Особенно если понятия не имеешь, чего хочешь... Думаю создать тред для своих основных идей/проектов (конечно же, они на Godot), но это немного не то - хочется быть независимым от чужих одобрений/критики.
Godot ощущается как сложная компьютерная игра-песочница, в которую ты заходишь и не знаешь что делать из предоставленного песка. В результате ковыряешься в каких-то мелких фичах вроде GUI предполагаемой игры, а core gameplay никак не делается, и это убивает весь интерес продолжать эту "разработку".
Хуже всего с графикой: с одной стороны, я чувствую, что сделай я годную графику (обязательно своими руками), я имел бы больше мотивации работать над проектом дальше, но я даже не могу определиться с тем, какого рода графика мне нужна (речь про 3D), не говоря уж о том, что в целом мой уровень творческих навыков достаточно слаб. А чисто процедурно генерировать всю графику я не смогу, я не математик (ведь от логики процедурка зависит слабо), а всего лишь кодер-самоучка (т.е. в архитектуре программ я тоже слабо разбираюсь).
Я неоднократно пробовал писать дизайн-документ, составлять и выполнять планы, вести личный дневник разработки, но всё это приносит мне больше трудностей, чем пользы, хотя я и осознаю необходимость всего этого и рекомендую другим новичкам. Да, важно определиться с идеями и документировать их, а потом разделить задачи на этапы и вести логи выполнения, но-о-о... я не могу ни с чем толком определиться и тем более сделать чёткую декомпозицию того, что я ни разу в жизни не делал, лол. А дневник разработки быстро заполняется всякой мелочью, которую потом очень лень перечитывать, смысл тогда всё это как-то документировать...
Бамп лучшему движку на этой доске, почему целые сутки ни одного нового поста?! ТВГ давно кончился.
Godot ощущается как сложная компьютерная игра-песочница, в которую ты заходишь и не знаешь что делать из предоставленного песка. В результате ковыряешься в каких-то мелких фичах вроде GUI предполагаемой игры, а core gameplay никак не делается, и это убивает весь интерес продолжать эту "разработку".
Хуже всего с графикой: с одной стороны, я чувствую, что сделай я годную графику (обязательно своими руками), я имел бы больше мотивации работать над проектом дальше, но я даже не могу определиться с тем, какого рода графика мне нужна (речь про 3D), не говоря уж о том, что в целом мой уровень творческих навыков достаточно слаб. А чисто процедурно генерировать всю графику я не смогу, я не математик (ведь от логики процедурка зависит слабо), а всего лишь кодер-самоучка (т.е. в архитектуре программ я тоже слабо разбираюсь).
Я неоднократно пробовал писать дизайн-документ, составлять и выполнять планы, вести личный дневник разработки, но всё это приносит мне больше трудностей, чем пользы, хотя я и осознаю необходимость всего этого и рекомендую другим новичкам. Да, важно определиться с идеями и документировать их, а потом разделить задачи на этапы и вести логи выполнения, но-о-о... я не могу ни с чем толком определиться и тем более сделать чёткую декомпозицию того, что я ни разу в жизни не делал, лол. А дневник разработки быстро заполняется всякой мелочью, которую потом очень лень перечитывать, смысл тогда всё это как-то документировать...
Бамп лучшему движку на этой доске, почему целые сутки ни одного нового поста?! ТВГ давно кончился.
Ты безыдейный.
Никакие диздок, дневник, мотивация не помогут если у тебя нет идей.
Даже не парься по этому поводу, это не плохо и не хорошо. Чтобы идеи появились, нужно заполнить голову чужими идеями. Тогда твой мозг начнет на существующей базе генерировать что-то свое. Это так работает, идеи из ниоткуда не появляются, это всегда компиляция идей пришедших извне.
Самый простой вариант - идешь на форумы и узнаешь чем дышат люди. Какие системы они хотят реализовать, какие вопросы задают. Ищешь ответы на ИХ вопросы. Скачиваешь демки, изучаешь (тут придется забарывать лень). Набравшись топлива, мозг начнет генерировать что-то свое.
Я сижу за ПК по формату два три часа по два раза в сутки, это с 9 до 12, а потом с 18 до 21, в перерывах отдыхаю, придумываю идеи, которые воплощаю, раз в неделю должен быть день отдыха
Отсутствие идей это признак твоей усталости, лень тоже, так что сделай перерыв и переходи на режим, который я тебе предложил, уверяю, идей будет море после отдыха
Так же помни про итерационные развитие, это когда с первого раза не получается, но скаждой итерацией совершенствуется
> Как не терять мотивацию делать игру?
> Чтобы идеи появились, нужно заполнить голову чужими идеями. Тогда твой мозг начнет на существующей базе генерировать что-то свое. Это так работает, идеи из ниоткуда не появляются, это всегда компиляция идей пришедших извне.
> Самый простой вариант - идешь на форумы и узнаешь чем дышат люди.
Например, я хожу в ютуб и смотрю лецплеи новых игорь. Играть в них я не могу, потому что ИДИ НАХУЙ КРИПТОМРАЗЬ, ВОТ ПОЧЕМУ, но просмотр лецплеев даже лучше, наблюдаешь за играющим "из-за спины", как в нулевые в игровых клубах, и видишь мелкие детали, нюансы, которые упускает сам играющий, особенно в динамичных сценах, которые не повторяются, если не играть сначала.
Вот там куча идей генерируется уже мной на базе отсмотренного материала.
>Ты безыдейный.
Идеи есть, но я не могу решить, что выбрать. Если решаю реализовать что-то, через какое-то время теряю интерес и хочу что-то другое. Или на практике оказывается не так, как ожидал. По этой причине мотивация начинать новое истощается, и по этой же причине не могу продумать детали каких-то более общих идей - для этого нужно сделать некий ВЫБОР, а я не люблю выбирать (отказываться от всего остального в пользу чего-то одного). Много лет хочется проект "обо всём" и вместе с тем даже в таком проекте придётся выбрать одно и отказаться от другого. Не говоря уж о том, что большой проект дольше и сложнее делать, на это мотивации вообще нет...
>заполнить голову чужими идеями
>мозг начнет генерировать что-то свое
У меня обратная проблема. Если я играю в какую-то игру, у меня почти всегда возникает желание "сделать нечто похожее самому" и возникают идеи, что и как я мог бы сделать сам. Но потом мотивация быстро падает или возникает желание сделать что-то другое. Если идея максимально простая - могу сесть и сделать за несколько часов, но если требуется несколько дней работы, у меня на следующий день просто не будет желания продолжать. Или я на следующий день захочу всё с нуля переделать по-другому, потому что придумал что-то ещё. Бывало, мог работать над чем-то почти месяц, но потом забрасывал и через какое-то время переделывал, потому что идея совсем разонравилась или не оправдала себя. Эти моменты ещё больше демотивируют, т.к. в следующий раз я ожидаю, что будет снова несколько недель бесполезной работы над тем, что мне быстро расхочется делать.
Есть предположение, что я мог бы мотивировать себя на разработку своей игры, если бы мог играть в собственную игру - тогда у меня возникали бы идеи для этой игры и я бы сразу реализовывал их в ней, но играбельного прототипа либо нет, либо он демотивирует своим видом на фоне чужих, намного лучше выглядящих игр (особенно когда они мне нравятся). Невозможно делать игру и не сравнивать её с другими, ну, как и в любом творчестве.
>вставь плейсхолдеры, потом учись моделить и постепенно заменяй реальными моделями
Да, знаю об этом методе, но я слишком зацикливаюсь на графике, сделав 2-3 плейсхолдера пытаюсь переделать их "лучше", тогда как нужно сделать всю игру на плейсхолдерах, а это уже будут сотни временных моделей, а не 2-3. Может, наличие полноценного геймплея меня бы мотивировало даже в отсутствие полноценной графики, и тогда было бы проще перетерпеть сложности моделирования и рисования.
>паралич выбора
Спасибо, не знал, как это называется, это про меня:
>Есть определенные черты личности, которые делают человека более уязвимым для нерешительности. Например, люди, склонные к навязчивым идеям и обращающие внимание на мелкие детали.
>Точно так же те, кого сильно критиковали в детстве, могут бороться с неуверенностью и идеей потенциального принятия неправильного решения.
>вам кофе с сахаром или зеленый чай?
>3д реализм или лоуполи?
Очень плохое сравнение. Кофе и чай повлияют только на одно посещение кафе и только твои личные ощущения. Конечно, согласно эффекту бабочки это может повлиять на что-то ещё (особенно учитывая бодрящее свойство кофе и мочегонность чая), но мы это предсказать в любом случае не можем, поэтому волноваться бесполезно. А вот графика в игре влияет на восприятие аудиторией и даже влияет на состав целевой аудитории игры, что в свою очередь влияет на окупаемость игры и в целом её судьбу, а заодно и судьбу компании-разработчика и всех её участников. Кроме того, делать графику - долго и дорого, а для разных стилей могут потребоваться разные специалисты (или навыки, если мы про инди-одиночку), т.е. это решение, последствия которого в полную силу сыграют только через N лет, когда игра дойдёт до релиза. Будет потрачен бюджет и время, а результат зависит от выборов в самом начале... Это совсем не то же самое, что выбрать чай или кофе в кафе. Именно поэтому в больших компаниях кроме программистов, художников и других исполнителей есть "бесполезные" геймдизайнеры и маркетологи, от решений которых по сути и зависит вся судьба проекта. Если ты видишь очень плохую игру - не ругай "разрабов", ругай их руководителей, которые приказали им сделать это. А мы инди, мы можем ругать только сами себя за неудачные решения...
>Отсутствие идей
Может, я неправильно выразился в том посте, но идеи в общем-то есть, просто я не могу выбрать что-то одно. И чтобы детализировать какую-то общую идею - тоже нужно выбирать, много выбирать. А у меня все идеи общие (как и у многих кириллов), т.е. есть мысль "сделать так-то, только по-другому", а конкретики нет, и пытаясь эту конкретику придумать, чувствуешь, что тебе ничего из доступного не нравится или, наоборот, хочется сделать всё, но это невозможно. Хуже всего, когда хочется невозможное или очень сложное, а простое и доступное не мотивирует, не вызывает тяги "взять и сделать".
>это признак твоей усталости, лень тоже
Писать посты на дваче и играть в игры мне не лень, а делать игру лень? Напряжение одинаковое, просто от разработки игры не получаешь дозы дофамина как от открывания лутбоксов или "социализации" в интернете, особенно если проделанная работа оказалась лишней, не привела ни к чему работоспособному или интересному. У меня неоднократно были моменты ощущения кайфа после доделывания какой-то программной штуковины спустя несколько часов напряжённого кодинга, но нельзя заранее гарантировать, что это получится, в отличие от сидения в интернете и играх, особенно если задача непростая и ты никогда такой раньше не делал. Я слышал про метод, когда сам себя награждаешь чем-то приятным за выполнение рутины, но у меня это не получается.
>смотрю лецплеи новых игорь
Лол, у меня от просмотра летсплеев чаще возникает желание самому заняться летсплеями, чего я, конечно, делать никогда не буду, потому что социофоб, и никакая анимешная аватарка с этим не поможет. Или желание самому поиграть в конкретную игру. Всё же играть в игру и смотреть за чужой игрой - разное, вся суть игры в интерактивности процесса, а летсплеи - это как кино, совсем другие ощущения. Играя в игру, ты погружаешься в мир игры, становишься одним целым с персонажем и забываешь о реальности, а смотря летсплей ты бьёшь фейспалмы из-за тупости летсплеера или ржёшь в полный голос над его тупыми шутками. Это только кинцо-мыльцо можно "проходить на Ютубе", нормальные игры нужно играть самому на своём компьютере. Вот поэтому играя в игру я хочу сделать свой собственный мир с немного другими возможностями или декорациями, а смотря летсплей я хочу записать собственный летсплей без тупых ошибок и тупых шуток (но снимай я летсплеи, я бы тупил ещё больше и ещё тупее шутил, это факт). И идеи, соответственно, генерируются разные. Но чисто глянуть графику и базовый геймплей, конечно, можно и в летсплеях, если перематывать на нужные моменты.
>Может, я неправильно выразился в том посте, но идеи в общем-то есть,
>А у меня все идеи общие
проще говоря, идей нет.
>Идеи есть, но я не могу решить, что выбрать.
>через какое-то время теряю интерес и хочу что-то другое
>хочется проект "обо всём"
>Если я играю в какую-то игру, у меня почти всегда возникает желание "сделать нечто похожее самому" и возникают идеи
>Может, я неправильно выразился в том посте, но идеи в общем-то есть, просто я не могу выбрать что-то одно.
Все, описанное тобой, это НЕ идеи. Это мимолетные фантазии. И это две вещи, которые люди не различают. Абсолютное большинство людей - безыдейные. В их головах никогда не было идей, собственных или пришедших извне.
Идея отличается своей полнотой, своей самостоятельностью. Идея не просто приходит к тебе в голову, она живет в ней своей жизнью, она становится частью тебя, частью твоего восприятия. Даже идеи по играм. Рождение идеи, это длительный процесс происходящий с опытом поскольку компиляцией опыта и является. Идея не родиться просмотром стримов, летсплеев, игрой в чужие игры и т.д.
>идеи общие
>идей нет
Я тебе могу сколько угодно конкретики выдумать. Но вопрос, будет ли в это интересно играть? И будет ли лично мне интересно это делать и тестировать? Проблема не в отсутствии идей, проблема в отсутствии мотивации сесть и начать реализовывать что-то. Или сесть и продолжить начатое в прошлом. У меня ведь нет начальника за спиной, который бы заставлял делать работу. Что хочу то и делаю. Только я ничего не хочу, или недостаточно хочу. Это большая проблема всех инди, и меня удивляет, как некоторые могут без проблем месяцами ежедневно пахать над своей игрой, ведь для меня даже час ежедневно что-то делать с файлами игры - уже подвиг.
Иногда удаётся начать, просто сортируя файлы. Как-то само собой получается и увлекаюсь на несколько часов. Да вот только это бессистемная работа и результат как правило если и есть, то быстро становится бесполезен. Понимаю, что нужно систематизировать всё и следовать планам, но это так тяжело... И очень легко уйти в перфекционизм, дроча на пунктики в планах вместо реальной работы.
Сколько страниц занимает диздок?
>Это мимолетные фантазии.
Согласен, но из фантазий рождаются новые игры. В идеале ты должен мочь сыграть в свою игру мысленно, т.е. у тебя должна быть фантазия о будущей игре, а уже потом ты эту фантазию преобразуешь в сухое техническое описание, а это описание - в код и контент. Разумеется, человек с крайней формой афантазии тоже имеет возможность разработать игру, но ему будет намного сложнее - всё равно, что идти вслепую, на ощупь, не видя цели.
>Абсолютное большинство людей - безыдейные. В их головах никогда не было идей
>Идея отличается своей полнотой, своей самостоятельностью. Идея не просто приходит к тебе в голову, она живет в ней своей жизнью, она становится частью тебя, частью твоего восприятия.
Скажи, ты часто посещаешь /ph/? Без обид, но ты, как бы это сказать... слишком сильно уходишь в философию. Мы тут игры пытаемся делать, и у нас, соответственно, чисто бытовое понимание "идеи", без философии.
Из Википедии:
>Иде́я (др.-греч. ἰδέα «вид, форма; прообраз») в широком смысле — мысленный прообраз какого-либо действия, предмета, явления, принципа, выделяющий его основные, главные и существенные черты.
>В науке и искусстве идеей называется главная мысль произведения или общий принцип теории или изобретения, вообще замысел или наиболее существенная часть замысла. В этом же смысле термин идея трактуется в сфере регулирования авторского права.
Я специально вырезал абзац с философией, потому что он не имеет отношения к нашему обсуждению.
Т.е. идея в контексте геймдева - это мысленный прообраз будущей игры, или главная мысль, замысел уже существующей игры. Пример: идея Майнкрафта - "свободное изменение игрового мира путём копания и строительства". В идее Майнкрафта нет ни перечисления всех возможных блоков и предметов, ни технического описания устройства мира, ни даже строгого указания на кубики и пиксельные текстуры. Игра без кубиков идейно подобна Майнкрафту до тех пор, пока в ней можно свободно изменять игровой мир путём копания и строительства, а всё остальное - это уже конкретный геймдизайн, а не просто идея.
Именно поэтому в геймдеве часто говорят "идея ничего не стоит" и рекомендуют новичкам писать дизайн-документ, хотя эти рекомендации никто не слушает и все идут по одним и тем же граблям. Действительно, нет ценности в идее "игра про преступления в городе, с ездой на множестве разных машин и с использованием разнообразного оружия", в отличие от тысяч страниц дизайн-документа, точно описывающих все детали будущей GTA 6.
В общем, если ты хочешь меня унизить, то тебе следовало бы обзываться не "безыдейным", а "неспособным в дизайн" или как это одним словом назвать... недизайнером? В любом случае я согласен, что (гейм)дизайнер из меня никчёмный, ведь я никогда дизайну осознанно не учился, и про геймдизайн тоже особо не читал ничего.
Раз уж мы в треде Godot:
Идея Godot, как я её понимаю - доступный современный движок для всех и каждого, начиная от новичков и детей, энтузиастов и индивидуальных разработчиков, заканчивая профессионалами и крупными студиями в индустрии видеоигр. Поэтому у него максимально свободная лицензия, компактный лёгкий редактор со встроенными простыми языками и широкой расширяемостью любым внешним языком, попытка поддерживать сравнительно старое железо и множество платформ. Всё остальное - детали архитектуры и конкретные решения команды основных разработчиков, а не идея. Могут быть идеи отдельных компонентов, например, идея TileMap - лёгкий в освоении встроенный инструмент для создания уровней в 2D играх разных видов, но это не является частью идеи движка, хотя и прямо следует из неё. Т.е. идейно Godot мог бы существовать без TileMap, но раз уж в нём есть TileMap, идейно этот компонент должен быть лёгок в освоении и универсален (подходить разным играм), что следует из основной идеи движка.
>открываешь папку с рефами разных стилей, и прямо сейчас выбираешь из них один.
Легко сказать, я так неоднократно делал, но мне либо ничего не нравится из того, что можно найти в интернете, либо реализовать такой стиль слишком сложно. Скажем, я видел много разных видов лоуполи стилизации, но все они мне не нравятся, потому что слишком минимизируют всё, человечки зачастую даже хуже квадратно-пиксельных персонажей Майнкрафта, лол. Нет, мне нравятся некоторые игры в лоуполи стиле, но при этом делать игру в таком стиле не хочется, хочется что-то более детальное, с полноценными текстурами.
>Сколько страниц занимает диздок?
У меня всё разбросано по .txt файлам и в wiki формате, поэтому уместнее говорить о числе символов. Так вот: я не знаю, не считал, не собираюсь и не буду считать. Диздок не должен оцениваться по количеству страниц или символов, т.к. его ценность зависит от содержания и полноты, а размер во многом зависит от конкретного проекта.
Но скажу честно, все мои диздоки состоят из белых пятен, потому что мне было лень что-то описывать, или я не мог сразу это описать и потом забросил, или забросил из-за потери мотивации. Не, ну а что делать? Я не представляю, кто может описать 100% игры от и до. Вот прям чтоб всё и сразу. Это надо уже существующую игру описывать, потому что в существующей нет неопределённостей. А в будущей игре как я могу сказать, что вот эта фича будет удобна, интересна и вообще нужна? Я вот недавно глянул свой старый проект и осознал, что зря навыдумывал какой-то инструмент, описание которого в диздоке занимает довольно много места. Потому что лучше было бы сделать по-другому. Но я даже сейчас не знаю, действительно ли это лучше или мне так кажется, и нужно что-то третье...
>Согласен, но из фантазий рождаются новые игры.
Новые игры рождаются из идеи. Фантазия, лишь малая доля того что порождает идею.
>соответственно, чисто бытовое понимание "идеи", без философии.
Так философия тут и не при чем. Ты суть все еще не улавливаешь.
Суть в том, что ты проблему не в том ищешь. Дело не в мотивации, не в диздоках, ни даже в лени. Дело в отсутствии идей. Я лишь сделал отступление, чтобы указать на проблему незнания базовых понятий.
>Но скажу честно, все мои диздоки состоят из белых пятен, потому что мне было лень что-то описывать, или я не мог сразу это описать и потом забросил, или забросил из-за потери мотивации.
Что и требовалось доказать. Зато высрал полотно текста о размерах диздока и как чтт оценивать.
>В общем, если ты хочешь меня унизить, то тебе следовало бы обзываться не "безыдейным", а "неспособным в дизайн" или как это одним словом назвать... недизайнером? В любом случае я согласен, что (гейм)дизайнер из меня никчёмный, ведь я никогда дизайну осознанно не учился, и про геймдизайн тоже особо не читал ничего.
На этом моменте мне стоило бы и остановиться. У тебя завышенная оценка собственных возможностей и заниженный уровень рефлексии. Если даже это:
>Но скажу честно, все мои диздоки состоят из белых пятен, потому что мне было лень что-то описывать, или я не мог сразу это описать и потом забросил, или забросил из-за потери мотивации. Не, ну а что делать? Я не представляю, кто может описать 100% игры от и до.
не вызвало в твоей голове вопроса "достаточно ли я знаю и умею, достаточно ли у меня опыта, если мой план полон белых пятен?", то у меня нет и шанса что-то прояснить
>Ты суть все еще не улавливаешь.
>Дело в отсутствии идей.
>она живет в ней своей жизнью, она становится частью тебя, частью твоего восприятия
Ты прав, я не понимаю, из твоих слов "идея" = "идея фикс", то есть некая идея, которая занимает человека очень долгое время, возможно, многие годы, человек о ней постоянно или регулярно думает и т.д. Так? Если так, нужно было сразу говорить про идею фикс, а не просто идею. Мол, нужно быть одержимым чем-то, чтобы идти к этому.
Да вот только нет. Можно иметь идеи фикс долгие годы, но при этом ничего для их осуществления не делать. Или пытаться, обламываться и снова возвращаться к мечтам и разговорам вместо дела. По опыту говорю. Да, у меня есть идеи фикс, как минимум одна. С играми она не связана, хотя и влияет на все мои идеи по играм. Мои идеи по играм крутятся вокруг всего нескольких базовых идей, которые я пытаюсь представить в разных жанрах, так что можно сказать, что это тоже своего рода идеи фикс, но послабее, менее важные. Что толку с этого всего? Я пробую, обламываюсь и бросаю, пытаясь забыть это всё. Спустя какое-то время мысли и фантазии снова вызывают желание попробовать ещё раз. Может быть, по-другому получится, с другим подходом? Нет, снова обламываюсь. Снова бросаю... Так что недостаточно иметь идею фикс, которая требует к себе внимания два десятка лет, чтобы сесть и смочь её как-то реализовать. Проще залить тоску играми, аниме, интернетом и всем остальным, что отвлечёт внимание от депрессивных мыслей ("ничего не получится", "зачем тогда вообще жить" и т.п.)...
>достаточно ли у меня опыта
Чтобы сделать игру, нужен диздок для этой игры.
Чтобы сделать диздок, нужен опыт разработки игр.
Чтобы был опыт разработки, нужно сделать игру.
Чтобы сделать игру...
Чтобы сделать игру, нужно сделать игру?
>сделай клон (тетрис/сапёр/пасьянсы/три-в-ряд/...)
Не поможет, если хочешь 3D экшон суть токова.
>завышенная оценка собственных возможностей
Это правда, часто из-за этого страдал.
> Не поможет,
Поможет. Хуле ты упёрся, как баран? Делаешь игры одну за одной, развиваешься, совершенствуешься. И вот наступает момент, когда ты можешь в соло запилить свой клон скайрима.
Ой да хуле там запиливать?
- Система чанков.
- Система навигации.
- Менеджер погоды.
- Менеджер диалогов, квестов и катсцен.
- Охапка дров.
Скайрим готов. Анимации с миксамо возьмёшь.
>Хуле ты упёрся, как баран?
Потому что как только сядет за дело, вдруг выясняется, что он творожок подзалупный. А так хоть можно втирать о каком-то там скиле и идеях. Типа если бы да кабы я по настоящему захотел то ухххх бы все как сделал, но мотивации нет прост не знаю какую идею выбрать все охуенные хочу все сделать.
> клон скайрима
> в соло
ну игромеханичнский, скайрим примитивен как палка, так что не показатель (хотя даже там беседка лихо насрала багами). Большая часть скурима это контент, и на контент в любой игре уходит абсолютное большинство времени и в соло такое запилить вряд ли получится
>Ой да хуле там запиливать?
https://en.wikipedia.org/wiki/Dunning–Kruger_effect
>Система чанков.
Само по себе определение игрока в чанке - это одна строчка с простой формулой. Но связать это с другими игровыми системами может оказаться сложно. Нужно изначально делать архитектуру, ориентированную на чанки. Алсо сшивать куски ландшафта с разными уровнями LOD лично я даже не представляю, как.
>Система навигации.
С одной стороны, есть в Godot, с другой, всё зависит от игры. Если мы делаем клон Скайрима, боты должны бродить по всей карте даже вне поля зрения игрока, для чего встроенная навигация Godot вряд ли подходит. AStar тут может помочь, но всё равно придётся изобретать решение под конкретную игру, если мир большой.
>Менеджер погоды.
Не знаю, почему ты его отдельно выделил, от менеджера мало что требуется, главная проблема - сделать красивые погодные эффекты, а как ты их сделаешь? Я видел много всяких статей и видео об играх, но ни разу не видел чего-то про погодные условия, как будто они вообще никого не интересуют или все знают, как их правильно делать. Но на деле это неочевидно. Ты же знаешь, что прозрачные текстуры - это плохо? Т.е. ты не можешь накидать на сцену прозрачных текстур с каплями дождя или скоплениями дыма, это убьёт производительность. Тогда как? Я знаю, что облака делают либо объёмными для стилизации, либо в виде полупрозрачных текстур, но все остальные эффекты - загадка, ноу-хау. Я даже не видел нормальных погодных эффектов в большинстве инди-игр, в них погода как будто совсем не существует.
>Менеджер диалогов, квестов и катсцен.
Легко сказать, если у тебя сюжетная игра с рельсовыми диалогами. Но зачем делать ещё одну рельсовую игру, если можно сделать что-то другое? А что-то другое будет в разы сложнее рельсовых диалогов.
>Охапка дров. Скайрим готов.
Ты же понимаешь, что твоя "охапка дров" - это сотни страниц дизайн-документа и очень много контента?
>Анимации с миксамо возьмёшь.
И будут мои персонажи двигаться как персонажи в 9000 других инди-поделок. Никакой индивидуальности. Зачем тогда игру делать? Так можно и до моддинга оригинальной игры опуститься.
>на контент в любой игре уходит абсолютное большинство времени и в соло такое запилить вряд ли получится
Всё так.
>Типа если бы да кабы я по настоящему захотел то ухххх бы все как сделал, но мотивации нет прост не знаю какую идею выбрать
Да, это так. Да, было бы тяжело в некоторые моменты, пришлось бы погуглить типовые решения. Да, графику я бы сделал мэдскиллзовую, но сделал бы. Но мотивации нет, а идеи хоть и есть, но определить точно, что именно нужно делать, чтобы получился Геймплей - сложно.
>снег, который оседает на крышах, не попадает в помещения, но может залетать под углом под навес
Насколько я знаю, в ААА-играх не делают реалистичную симуляцию снега. В Mafia 2 переключение с зимы на лето по сюжету, зимой снег статично лежит - скорее всего, он просто заранее смоделирован. В GTA V есть заснеженная локация, но она смоделирована заранее, а если включить зиму по всей карте, карта почти не изменится. С другой стороны, реалистичный снег есть, внезапно, в Minecraft, он там слоями накапливается, но реализовано это очень просто благодаря минималистичной графике.
>И еще чтобы в нем следы оставались.
Если следы временные и снег неглубокий, то как обычные следы в играх. Если снег глубокий или нужно сохранять следы надолго, тогда да, проблема. Видел демонстрацию реалистичных следов на снегу в Godot 4.0, там они как-то в одну общую для всех шейдеров текстуру информацию записывают и потом шейдер снега по этой информации моделирует вмятины (наверное, можно и сейчас сделать, просто придётся текстуру вручную каждому шейдеру передавать, и каждому свою). Текстура при движении игрока смещается, и если отойти далеко, как я понял, дальние следы сотрутся. Думаю, если это рисуется через Viewport, можно сделать перманентные следы, но это может начать сказываться на производительности.
Сап, кодирую на шарпе, сделал игру на юнити, но он мне не понравился. Вопрос: Чем годот лучше юнити? Трудно ли с юнити перекатываться на годот?
Спасибо
Спасибо
Каким образом создавать вьюпорты на сцене так, чтобы они НЕ ЛАГАЛИ при первом создании? Godot 3.4.4
Вьюпорт нужен потому что требуется на набор спрайтов-чилдов применить один и тот же шейдер, а у этих спрайтов есть свои шейдеры
Вьюпорт нужен потому что требуется на набор спрайтов-чилдов применить один и тот же шейдер, а у этих спрайтов есть свои шейдеры
>Чем годот лучше юнити?
1. Полностью свободный (лицензия MIT), не нужно платить и отчитываться о доходах, регистрироваться и бояться, что в любой момент могут аннулировать лицензию.
2. Редактор легче для ПК, движок тоже полегче. Т.е. быстрее запускается и не тормозит на пустой сцене (есть мелкие проблемы, но не такие, как у игр на юнити).
3. Встроенные функции просто работают, не нужно качать каких-то дополнительных пакетов (Input, UI) для того, чтобы начать разработку относительно простой игры.
4. Есть встроенный скриптовый язык, похожий на Python и достаточно быстрый для большинства задач, т.е. можно писать сложные скрипты прямо в редакторе, без компиляции. На этом языке можно писать утилиты для редактора, т.е. допиливать редактор желаемыми фичами буквально изнутри самого редактора. Редактор игр Годо - это игра, сделанная на Годо, что о многом говорит.
5. Можно писать игру на любом существующем языке программирования, если он умеет в компиляцию динамически линкуемых библиотек (DLL). Т.е. ты не ограничен официальной поддержкой языков, можешь даже прикрутить свой собственный ЯП.
6. Разработчики, как говорится, ближе к народу - часто выходят на связь и многие вопросы обсуждают публично на гитхабе или в других официальных каналах связи. Это важно, потому что не любой опенсурс достаточно прозрачен, иногда бывает, что закрытая фирма что-то там делает, изредка публикуя код, так вот тут не так.
>Трудно ли с юнити перекатываться на годот?
Нет, легко, многое очень похоже. Какие-то функции API не совпадают, т.е. нужно использовать другой метод, но в целом разницы меньше, чем между Unity и UE. Просто почитай документацию и во всём разберёшься.
>вьюпорты
>чтобы они НЕ ЛАГАЛИ
Вьюпорт - это контекст OpenGL. Для создания контекста видеокарте нужно какое-то время, так что это медленная часть API, она будет в любом случае тормозить.
>Вьюпорт нужен потому что требуется на набор спрайтов-чилдов применить один и тот же шейдер, а у этих спрайтов есть свои шейдеры
Не совсем понимаю, тебе нужно динамически создавать множество вьюпортов для разных групп спрайтов, число которых заранее неизвестно, или группа таких спрайтов может быть только одна? Если группа спрайтов одна, либо максимальное число групп и/или шейдеров заранее известно, тогда создай необходимое количество вьюпортов на старте игры и потом помещай в них спрайты по мере необходимости. Чтобы вьюпорт не работал впустую, установи этот параметр:
>render_target_update_mode = UPDATE_DISABLED
Либо скрой с экрана тот спрайт, в котором ты используешь текстуру с вьюпорта (если это так), т.к. значение по умолчанию не обновляет вьюпорт, пока его текстура нигде не используется (UPDATE_WHEN_VISIBLE). Лишние вьюпорты, пока они не обновляются, не будут влиять на производительность игры, поэтому нет необходимости от них избавляться.
>Godot 3.4.4
Почему не переходишь на Godot 3.5?
>Чем годот лучше юнити?
Технически - ничем. Юнити развивался за деньги и намного дольше чем Годот и всегда будет его опережать.
Практически:
- Годот легковесный
- Не жрет ресурсы одним только своим видом
- Не требует ебанистических соглашений/регистраций/лаунчиров - скачал, кликнул, запустил
- Юзерфрендли (что называется easy to start hard to master)
- Пока еще, дружелюбное коммьюнити (даже ру)
> Трудно ли с юнити перекатываться на годот?
Годот очень легок на старт.
>Каким образом создавать вьюпорты на сцене так, чтобы они НЕ ЛАГАЛИ при первом создании?
Никак. Отдельный вьюпорт - отдельный мир, фактически игра в игре. Без лага динамически вьюпорт не создать.
Накидывай в сцену нужное количество вьюпортов вручную, нодами. Либо вместо вьюпортов дублирой сами спрайты поверх друг друга и на копии применяй новый шейдер.
>НЕ ЛАГАЛИ
>шейдеры
А, точно, ещё может лагать компиляция шейдеров, если ты используешь шейдер впервые. Т.е. возможно, что лагает не создание вьюпорта, а использование шейдера в этом вьюпорте. Ты недостаточно подробно описал. Если проблема с компиляцией шейдеров, решения два:
1. Использовать шейдеры заранее в скрытом от глаз пользователя вьюпорте, во время запуска игры или загрузки уровня. Так делают многие игры на OpenGL.
2. Перейти на 3.5 и включить в настройках асинхронную компиляцию шейдеров и кэш шейдеров. Асинхронная помогает слабо, а вот кэш очень помогает, т.е. повторно запущенная игра гарантировано не будет тормозить, т.к. видеокарта не будет компилировать шейдеры.
У меня есть персонаж с факелом, броней, прической и всем остальным. Мне требуется телепортировать персонажа, проиграв шейдер на всех нодах этого персонажа.
Внутри вьюпорта действительно есть шейдер. Но когда я работаю без вьюпорта, ниче не лагает в принципе. Даже не планирует.
Для 2д нет next_pass.
Можно ли создать один вьюпорт, создавать внутри него кучу персонажей в разных позициях этого мира как то вьюпорт текстурой перемещаться по этому миру? Таким образом мне нужно будет создать не 10 вьюпортов, а только 1.
Можно ли создать один вьюпорт, создавать внутри него кучу персонажей в разных позициях этого мира как то вьюпорт текстурой перемещаться по этому миру? Таким образом мне нужно будет создать не 10 вьюпортов, а только 1.
>Технически - ничем. Юнити развивался за деньги
Вливание денег не избавляет от плохих решений менеджеров и раздувания базы кода лишними или неудачными технологиями. Годо развивается с учётом потребностей пользователей. Юнити и другие закрытые движки развиваются по желанию владельца компании или с решения топ-менеджеров, которые могут делать ошибки, потому что играми не увлекаются и в теме разработки софта разбираются плохо. Вот сейчас кто-то у руля Юнити решил, что игры - это исключительно денежные насосы, поэтому Юнити движется в сторону сервисов монетизации, наплевав собственно на игры как искусство, творчество, самовыражение да и просто способ расслабиться. Если руководство движка волнует только монетизация игр, какие технологии там могут быть хорошими? Технологии монетизации? Технологии показа рекламы? Ну если тебе нужны такие технологии, тогда да, Юнити технически лучше для тебя.
>Мне требуется телепортировать персонажа, проиграв шейдер на всех нодах этого персонажа.
Рендерь персонажа через вьюпорт в спрайт, спрайт рендерь на место персонажа в главном вьюпорте.
>вьюпорт текстурой перемещаться по этому миру?
Похоже, ты не понимаешь, что такое вьюпорт.
Вьюпорт - это render target (цель рендеринга).
Видеокарта способна рендерить в разные области памяти, то есть не обязательно на экран. Ты можешь создать текстуру через OpenGL и назначить её целью для рендеринга. Видеокарта отрендерит то, что ты попросишь, в эту текстуру, но текстура не отобразится на экране. Далее ты переключаешь видеокарту на экран и можешь отрисовать полученную текстуру в любом месте, любое количество раз, т.к. это обычная текстура.
Вьюпорт в Godot упорощает эти операции. Он автоматически создаёт новую текстуру заданного размера, а затем по необходимости переключает видеокарту на эту текстуру и рендерит всех своих потомков в эту текстуру. Затем, в зависимости от конфигурации сцены, эта текстура может использоваться из твоего кода, или автоматически добавляться на экран.
Рекомендую попробовать такую конфигурацию:
- Player (KinematicBody2D)
- - CollisionShape2D
- - Viewport
- - - все спрайты персонажа (тело, броня, оружие)
- - Sprite
Для Sprite в инспекторе ноды создай новую текстуру типа ViewportTexture, а в ней выбери Viewport, который выше. Это позволит автоматически рендерить результат работы вьюпорта в этот конкретный спрайт. В самом вьюпорте включи галочку Own World и создай ему World, если это будет нужно. Размеры текстуры вьюпорта настрой в зависимости от размера персонажа, также включи галочку transparent_bg, чтобы не было фона на текстуре.
Теперь ты сможешь применять шейдеры на части тела персонажа во вьюпорте, а затем применять шейдер телепортации на спрайт, который находится снаружи вьюпорта и принимает текстуру из него.
Да, это все понятно. Проблема в том что ЛАГАЕТ.
Да, именно создание.
Хотел уже было написать, что хуан ДОЛБОЕБ и годот ГОВНО, но чутка поебался и сделал через backbuffercopy. С помощью него можно навешивать бесконечное число шейдеров место next_pass.
Всем спасибо.
>Проблема в том что ЛАГАЕТ.
Так зачем тебе создавать вьюпорт в процессе игры, если тебе достаточно заранее создать один?
>сделал через backbuffercopy
Но разве он не копирует прямоугольную область экрана без разделения на спрайты? Т.е. твой эффект телепортации будет наложен не на спрайты игрока, а на область экрана, в которой находится игрок, включая фон/землю и предметы/мобов вокруг игрока... Если тебя устраивает такое наложение, то зачем вообще всё это с вьюпортами нужно было делать, если было достаточно наложить эффект на экран в целом, а не на спрайты игрока?
>эффект телепортации будет наложен не на спрайты игрока, а на область экрана
ЕМНИП, годот рендерит в порядке располажения нодов, соответственно можно скопировать кусок экрана до и после отрисоки спрайта а там уже накидать нужный эффект.
>Проблема в том что ЛАГАЕТ.
Вообще есть CanvasLayer на котором можно рисовать без создания подмира как это делает вьюпорт.
Мне надо чтобы шейдер рисовал. Причем тут канвас Леер? Я буду дравом рисовать эффекты и как то делать альфаканал?
У меня пять юнитов, сверху которых я хочу рисовать эффект телепорта. Офк, на экране все пять, а рисовать хочу в разное время. Вопрос - каким образом у тебя вышел 1 вьюпорт.
RayShape в 3д вообще не работает? С move_and_slide он просто не коллайдится, с move_and_collide его длина равна 0 и он коллайдится центральной точкой кинематик боди.
Но при этом он все еще кажется влияет на точку, с которой берутся нормаль, угол floor'а и т.п.
Но ведь он должен приподнимать колайдер!
О, я понял лол. Он сука ПОВЕРНУТ!
Начал смотреть/выполнять уроки по годоту, в принципе всё нравится, но после десяти лет обычного программирования тяжело понять/принять скрипты внутри нод. Меня это в своё время отвернуло от флэша.
> после десяти лет обычного программирования тяжело понять/принять скрипты внутри нод
Что такое "обычное программирование"?
В обычном программировании есть главная "нода" - файл с кодом из которого приложение стартует. И есть дополнительные "ноды", которые импортами/юзингами/инклюдами подключаются друг к другу и в конечном итоге к основному файлу (в котором Main(args)).
Это же обычное программирование? Или это я какое-то необычное описал? Что тогда, повторюсь, обычное программирование?
>рендерит в порядке располажения нодов
Нет гарантии, что будет именно так, потому что можно изменять порядок отрисовки.
>соответственно можно скопировать кусок экрана до и после отрисоки спрайта
В смысле? До отрисовки спрайта персонажа будет отрисован фон, земля и т.п., то есть то, поверх чего должен быть персонаж. После отрисовки спрайта персонажа он станет одним целым с фоном. Разве можно каким-то образом работать в шейдере с двумя копиями экрана из разных этапов рендеринга? Впрочем, мне кажется, этот путь не такой оптимальный, как вьюпорт.
>CanvasLayer на котором можно рисовать
CanvasLayer, несмотря на своё название, не создаёт никакого реального "слоя" для рисования. Он только изменяет порядок отрисовки.
https://docs.godotengine.org/en/stable/classes/class_canvaslayer.html
>The layer is a numeric index that defines the draw order. The default 2D scene renders with index 0, so a CanvasLayer with index -1 will be drawn below, and one with index 1 will be drawn above.
Т.е. помимо порядка нод в сцене учитываются индексы CanvasLayer: чем ниже индекс, тем раньше отрисуется спрайт или элемент интерфейса. Но это не создаёт отдельного render target, в отличие от Viewport.
>У меня пять юнитов
>каким образом у тебя вышел 1 вьюпорт.
Хорошо, сделай 5 вьюпортов, но создай их ЗАРАНЕЕ и не уничтожай, тогда никаких лагов-багов не будет. Ты же сам говорил, что лаги при создании, а не при использовании.
>Что такое "обычное программирование"?
Ну а вдруг он программирует микроконтроллеры на процедурном низкоуровневом языке типа C...
>Создать один скрипт в корневой ноде и делать все оттуда.
Зачем ты советуешь новичку очевидно нерациональный подход? Щас научится всё в одной корневой ноде делать, а потом будет страдать. Не нравятся скрипты в нодах? Привыкай, это основной подход и у него есть веские причины быть основным. Если бы один скрипт в корневой ноде был бы лучше, все игры только так и делали бы. Ещё можно как-то понять сторонников ECS, но отказываться от ООП в пользу лапши в одном гигантском скрипте - это что-то новенькое, ты точно не троллишь?
>const Util = preload("./util/util.gd")
>Util.pseudo_function(params)
>var my_obj: MyClass = preload("./src/myclass.gd").new()
Уж лучше объявить class_name и обращаться по имени класса, чем указывать путь. В частности не ясно, зачем ты делаешь preload(), если у тебя уже есть MyClass? Просто обратись MyClass.new() и не добавляй в код лишние строковые константы. Ньюфажеский подход какой-то, грузить скрипты по их пути... В GDScript даже проще можно писать, сохраняя типизацию:
>var obj := MyClass.new()
>По сути это похоже на ООП, инкапсуляцию.
Не "похоже", а реализация ООП и есть. Он, возможно, не знаком с ООП в самом общем его смысле. Можно делать ООП на чём угодно и это будет ООП, даже если в системе не будет знакомых ключевых слов. Так что ноды - это всегда экземпляры каких-то классов, а скрипты на нодах образуют потомки этих классов с расширенным функционалом. Можно сделать потомка потомка потомка ноды и заменить ему иконку, чтоб в дереве сцены красиво выглядело. Это ООП в самом прямом смысле. А что там под капотом в коде на C++ нас вообще волновать не должно.
Программирование - это разработка программы, а написание кода - это кодинг. Программирование может состоять из перемещения узлов в дереве, т.е. настройка дерева сцены в Godot такое же полноценное программирование, как и кодирование скриптов. Разница в том, что скрипты - императивные ("что нужно делать?" - "сместить спрайт в точку (2;2)"), а дерево сцены - декларативное ("что нужно получить?" - "спрайт на экране в точке (2;2)"). Но и то, и то - программирование. Другое дело, что дерево сцены не является полным по Тьюрингу, но нас этот вопрос волновать не должен (скорее наоборот, полнота по Тьюрингу там, где она не требуется, хуже её отсутствия).
>тяжело понять/принять скрипты внутри нод
В общем-то всё уже сказали, но хочу добавить, что в Godot реализовано не только ООП, но и СОП - событийно-ориентированное программирование. Возможно, ты по какой-то причине не знаком с СОП? Это странно, поскольку оно используется достаточно широко в настольных и серверных приложениях.
https://ru.wikipedia.org/wiki/Событийно-ориентированное_программирование
Так вот любая игра на Godot реализована в СОП парадигме, даже если ты не вызываешь emit_signal(). Потому что твои скрипты в любом случае будут иметь обработчики некоторых стандартных событий (сигналов), такие как _ready(), _process(), _input() и т.д. Если ты сможешь разобраться в СОП, то легко сможешь принять подход Godot к разработке игр через отдельные скрипты.
Я раньше много программировал на Delphi/Lazarus, поэтому подход Godot выглядит для меня совершенно естественным, не вижу чему тут можно удивляться или сопротивляться. Единственное что мне не нравится слово signal, я бы предпочёл слово event. В конце концов, это ведь события, и пишем мы обработчики событий (создание ноды, тик таймера, действие пользователя, столкновение тел и т.д.), так почему их называют сигналами?..
> Единственное что мне не нравится слово signal, я бы предпочёл слово event.
Эта мода пришла из GTK, там впервые красноглазые переименовали ивенты в сигналы. (А может не впервые, а может и не там...)
>Так вот любая игра на Godot реализована в СОП парадигме
В принципе любая игра строится на основе СОП, т.к. имеет главный цикл и обработчики событий. Очень сложно построить игру без событий, это должна быть какая-то совсем примитивная игра с пошаговым вводом пользователя через консоль. К тому же любое приложение с окнами в ОС строится на событиях окна, и без их обработки ничего не получится сделать, а у игры с графикой и/или GUI всегда есть хотя бы одно окно. Это нужно реально какие-то микроконтроллеры программировать, чтобы не быть знакомым с СОП, да и то, мне кажется, в современных микроконтролерах тоже должны быть события (прерывания?), чтобы не гонять цикл, проверяющий каждый такт каждую ногу (чтоб было энергоэффективно).
Ну а комбинация СОП + ООП даёт нам классы, которые наследуются от стандартных классов и переопределяют виртуальные обработчики событий. Чтобы не было гигантских портянок кода, эти классы размещаются в разных файлах - вот и получаем .gd скрипты, которые назначаются на разные ноды.
>Эта мода пришла из GTK
Да какая разница, откуда оно пришло.
Вопрос в том, чем signal лучше event? Уверен, должно быть какое-то объяснение, почему оно лучше. Всё-таки "излучать сигнал" и "сообщить о событии" - хоть и похожи технически, но по смыслу немного разные определения. Как бы сказать... "Сигнал" подразумевает императивную команду кому-то или куда-то (как на печатной плате или в нервной системе животного), а "событие" - оно просто есть, просто произошло, никого ни к чему не обязывая. В случае с "сигналом" мы как бы соединяем провода, а в случае с "событием" мы как бы смотрим туда, где событие может произойти. Поскольку подразумевается, что "сигнал" может "вещать в никуда", т.е. никем не приниматься, мне кажется, термин "событие" был бы более уместен. Ну, наверное, это субъективно...
> наверное, это субъективно
Именно так. Потому что сигнал вполне себе может излучаться в никуда.
> Вопрос в том, чем signal лучше event?
Сигнал более однозачный чем событие. Событие не обязательно подразумевает уведомление всех наблюдающих, к примеру изменение здоровья персонажа это событие, но не факт, что о нем уведомили кого-то. Больше уместно сравнение с сигнальными огнями, зажигаемыми на сторожевых башнях, наблюдающих приблежение противника (событие), тут не факт что об этом событии уведомят (может стража спит/убита), а может никто на башню не посмотрит чтобы увидеть сигнал.
>>827818
>циклические зависимости
В твоём коде не должно быть циклических зависимостей. Имхо, это признак плохой архитектуры, если два класса держатся за руки и тыкают друг в друга по очереди, имея доступ ко всем методам товарища.
>это значит, что из самих MyClass методы менеджера уже не вызвать
Менеджером обычно называют владельца множества однотипных объектов. Если принадлежащему менеджеру объекту нужно обратиться к своему менеджеру, я считаю, он должен излучить сигнал, на который этот менеджер подписался в процессе создания этого объекта.
Дело в том, что этот наш менеджер кому-то принадлежит, например, менеджеру менеджеров, в то же время менеджер не может принадлежать объекту, менеджером которого он является. Если ты сохраняешь ссылку на менеджера в объекте, которым владеет менеджер, ты по сути разрешаешь этому объекту убить своего владельца или изменить его произвольным образом.
По-моему, это как-то называется, но я не помню название. Короче, не должно быть циклической зависимости, если не хочешь потом лишних проблем.
Что касается enum и const, распределяй их так, чтобы объекту не нужно было спрашивать своего менеджера о константах и перечислениях. Если объекту нужна какая-то константа, она должна быть у объекта или зависящего от него объекта, а не у владельца этого объекта, потому что у него её запросто может не оказаться.
>циклические зависимости
В твоём коде не должно быть циклических зависимостей. Имхо, это признак плохой архитектуры, если два класса держатся за руки и тыкают друг в друга по очереди, имея доступ ко всем методам товарища.
>это значит, что из самих MyClass методы менеджера уже не вызвать
Менеджером обычно называют владельца множества однотипных объектов. Если принадлежащему менеджеру объекту нужно обратиться к своему менеджеру, я считаю, он должен излучить сигнал, на который этот менеджер подписался в процессе создания этого объекта.
Дело в том, что этот наш менеджер кому-то принадлежит, например, менеджеру менеджеров, в то же время менеджер не может принадлежать объекту, менеджером которого он является. Если ты сохраняешь ссылку на менеджера в объекте, которым владеет менеджер, ты по сути разрешаешь этому объекту убить своего владельца или изменить его произвольным образом.
По-моему, это как-то называется, но я не помню название. Короче, не должно быть циклической зависимости, если не хочешь потом лишних проблем.
Что касается enum и const, распределяй их так, чтобы объекту не нужно было спрашивать своего менеджера о константах и перечислениях. Если объекту нужна какая-то константа, она должна быть у объекта или зависящего от него объекта, а не у владельца этого объекта, потому что у него её запросто может не оказаться.
>>827816
> Я абсолютно серьезно. Например, я делаю шахматы. Сцена примерно такая
> Game
> -Gameboard
> --Pawn
> --King
> Так вот вся логика шахмат у меня будет в корневой логике - она будет оперировать и с игровым полем, и с фигурами. В самих фигурах никакой логики не будет. Максимум что туда можно добавить - какие-нибудь менеджеры спецэффектов, которые все равно включаются из корневого скрипта.
Вполне согласен, для мини игр такой монолитный подход имеет место быть.
>>827818
> >Уж лучше объявить class_name и обращаться по имени класса, чем указывать путь. В частности не ясно, зачем ты делаешь preload(), если у тебя уже есть MyClass? Просто обратись MyClass.new()
> Было бы лучше, но работать не будет, в частности потому что годот не умеет разруливать циклические зависимости, а это критично. Например, у тебя есть классы MyClass1, MyClass2, и какой-то менеджер, который их использует, так что они будут в нем объявлены - но это значит, что из самих MyClass методы менеджера уже не вызвать.
> >Ньюфажеский подход какой-то, грузить скрипты по их пути...
> Этот подход используется во всех топовых аддонах - hterrain, scatter, то есть это максимально профессиональный подход - просто потому, что на таком подходе сделаны комплексные архитектуры с большим количеством фич.
Циклические ссылки мало кто умеет разрешать. Я умудрялся и в шарпе и в паскале натыкаться на циклические зависимости, и на переполнения стека вызовов.
> Я абсолютно серьезно. Например, я делаю шахматы. Сцена примерно такая
> Game
> -Gameboard
> --Pawn
> --King
> Так вот вся логика шахмат у меня будет в корневой логике - она будет оперировать и с игровым полем, и с фигурами. В самих фигурах никакой логики не будет. Максимум что туда можно добавить - какие-нибудь менеджеры спецэффектов, которые все равно включаются из корневого скрипта.
Вполне согласен, для мини игр такой монолитный подход имеет место быть.
>>827818
> >Уж лучше объявить class_name и обращаться по имени класса, чем указывать путь. В частности не ясно, зачем ты делаешь preload(), если у тебя уже есть MyClass? Просто обратись MyClass.new()
> Было бы лучше, но работать не будет, в частности потому что годот не умеет разруливать циклические зависимости, а это критично. Например, у тебя есть классы MyClass1, MyClass2, и какой-то менеджер, который их использует, так что они будут в нем объявлены - но это значит, что из самих MyClass методы менеджера уже не вызвать.
> >Ньюфажеский подход какой-то, грузить скрипты по их пути...
> Этот подход используется во всех топовых аддонах - hterrain, scatter, то есть это максимально профессиональный подход - просто потому, что на таком подходе сделаны комплексные архитектуры с большим количеством фич.
Циклические ссылки мало кто умеет разрешать. Я умудрялся и в шарпе и в паскале натыкаться на циклические зависимости, и на переполнения стека вызовов.
Порядок отрисовки идет сверху вниз.
Соответственно в случае:
1) - всякая фигня
2) - бекбуферкопи
3) - кусок ещё какой-то фигни
4) - то что ты хочешь альфаканалить
сработает на ура. Т.к. если ты обратишься от пункта 4 или 3 к SCREEN_TEXTURE - там будет всегда "всякая фигня" и ничего больше.
Вьюпорты же не просто так лагают при создании. А если у меня 100 персонажей? Игроку ждать загрузки игры 20сек? У меня 5 вьюпортов лаг делают на 2 сек. Вот из-за таких оптимизаторов все игры по сотни гигов весом.
>Так вот вся логика шахмат у меня будет в корневой ноде - она будет оперировать и с игровым полем, и с фигурами. В самих фигурах никакой логики не будет.
Если тебе нужны самые простые оригинальные шахматы, то вариант со всей логикой в одной ноде вполне может сработать. Однако, кроме оригинального набора правил существуют и другие варианты правил игры в шахматы, а также всегда можно придумать новые. Альтернативные правила игры в шахматы могут изменять:
- форму и размеры доски и клеток доски;
- число игроков и очерёдность ходов;
- число и положение фигур у каждого игрока;
- типы фигур (новые типы, изменение старых);
- возможности фигур (как ходит каждый тип и т.п.);
- и т.д., много чего можно добавить.
Простор для фантазии огромный.
И вот представь, что ты сделал банальные шахматы с банальными правилами, а тебя закидали отзывами с просьбами добавить %набор_правил%, о котором ты даже не знал, или попросили сделать поддержку модов для того, чтобы игроки сами могли добавить любой набор правил, выложенный в Steam Workshop. Потому что банальные шахматы с банальными правилами реализованы 100500 раз и ещё одна реализация никому не нужна.
Если ты сделал всю лапшелогику в одной корневой ноде, то ты сядешь в лужу, осознав объём работ по переделке всей игры почти с нуля и будешь отвечать в стиле:
>рряяяя, у шахмат могут быть только одни правила
Что лишь продемонстрирует твою бессильность как программиста, но не удовлетворит запросы игроков, которые выделили ради тебя время, чтобы попросить о полезной фиче, а ты так грубо с ними обошёлся.
Чтобы этого не случилось, следует абстрагироваться от формы и размеров доски, числа, типов и возможностей фигур, числа игроков и очерёдности ходов и т.д. Код в корневой ноде может быть, но он должен работать независимо от того, какая у нас доска, фигуры, набор правил и прочее подобное.
Для примера, когда игрок кликает по коню на доске, мы должны подсветить клетки, на которые игрок может пойти этим конём. В твоём коде это будет захардкожено в главном скрипте и недоступно для лёгкой модификации, а в хорошо продуманной архитектуре конь САМ скажет, куда он в данный момент может пойти, ориентируясь только на свой собственный код, а не на какого-то глобального менеджера доски. Конь знает (или может узнать по запросу), где находится и куда может пойти, кого может убить, а кого убить не может (дамага не хватит чтобы пробить ладью под усилением каким-нибудь) и т.д. Он отвечает графическому интерфейсу: "я могу пойти туда и сюда, а вот здесь для меня будет суицидальный ход".
И тогда для модификации правил будет достаточно добавить в игру дополнительные .tscn и .gd с изменёнными фигурами/досками и их новой логикой, что можно сделать с помощью загрузки из любого места файловой системы (даже скрипты можно грузить в рантайме, нет лишней "защиты") или из дополнительных .pck (как DLC).
https://docs.godotengine.org/en/stable/tutorials/export/exporting_pcks.html
Конечно, в любом случае придётся продумать какое-то API или структуру файлов и описать это для пользователей, желающих сделать мод, но это дело десятое, главное что движок поддерживает моды из коробки.
Что касается шахматного ИИ, я понимаю, что монолитное решение для фиксированных правил может быть более быстрым, но должно быть возможно написать универсальное решение, которое сможет работать с любыми правилами, на любых досках и с любыми фигурами. Поскольку цели переиграть чемпиона мира не стоит, хватит брутфорса для игры на равных с 95% игроками, да и вообще можно мультиплеер сделать и пусть играются сами с собой по каким правилам захотят...
Если тебе нужны самые простые оригинальные шахматы, то вариант со всей логикой в одной ноде вполне может сработать. Однако, кроме оригинального набора правил существуют и другие варианты правил игры в шахматы, а также всегда можно придумать новые. Альтернативные правила игры в шахматы могут изменять:
- форму и размеры доски и клеток доски;
- число игроков и очерёдность ходов;
- число и положение фигур у каждого игрока;
- типы фигур (новые типы, изменение старых);
- возможности фигур (как ходит каждый тип и т.п.);
- и т.д., много чего можно добавить.
Простор для фантазии огромный.
И вот представь, что ты сделал банальные шахматы с банальными правилами, а тебя закидали отзывами с просьбами добавить %набор_правил%, о котором ты даже не знал, или попросили сделать поддержку модов для того, чтобы игроки сами могли добавить любой набор правил, выложенный в Steam Workshop. Потому что банальные шахматы с банальными правилами реализованы 100500 раз и ещё одна реализация никому не нужна.
Если ты сделал всю лапшелогику в одной корневой ноде, то ты сядешь в лужу, осознав объём работ по переделке всей игры почти с нуля и будешь отвечать в стиле:
>рряяяя, у шахмат могут быть только одни правила
Что лишь продемонстрирует твою бессильность как программиста, но не удовлетворит запросы игроков, которые выделили ради тебя время, чтобы попросить о полезной фиче, а ты так грубо с ними обошёлся.
Чтобы этого не случилось, следует абстрагироваться от формы и размеров доски, числа, типов и возможностей фигур, числа игроков и очерёдности ходов и т.д. Код в корневой ноде может быть, но он должен работать независимо от того, какая у нас доска, фигуры, набор правил и прочее подобное.
Для примера, когда игрок кликает по коню на доске, мы должны подсветить клетки, на которые игрок может пойти этим конём. В твоём коде это будет захардкожено в главном скрипте и недоступно для лёгкой модификации, а в хорошо продуманной архитектуре конь САМ скажет, куда он в данный момент может пойти, ориентируясь только на свой собственный код, а не на какого-то глобального менеджера доски. Конь знает (или может узнать по запросу), где находится и куда может пойти, кого может убить, а кого убить не может (дамага не хватит чтобы пробить ладью под усилением каким-нибудь) и т.д. Он отвечает графическому интерфейсу: "я могу пойти туда и сюда, а вот здесь для меня будет суицидальный ход".
И тогда для модификации правил будет достаточно добавить в игру дополнительные .tscn и .gd с изменёнными фигурами/досками и их новой логикой, что можно сделать с помощью загрузки из любого места файловой системы (даже скрипты можно грузить в рантайме, нет лишней "защиты") или из дополнительных .pck (как DLC).
https://docs.godotengine.org/en/stable/tutorials/export/exporting_pcks.html
Конечно, в любом случае придётся продумать какое-то API или структуру файлов и описать это для пользователей, желающих сделать мод, но это дело десятое, главное что движок поддерживает моды из коробки.
Что касается шахматного ИИ, я понимаю, что монолитное решение для фиксированных правил может быть более быстрым, но должно быть возможно написать универсальное решение, которое сможет работать с любыми правилами, на любых досках и с любыми фигурами. Поскольку цели переиграть чемпиона мира не стоит, хватит брутфорса для игры на равных с 95% игроками, да и вообще можно мультиплеер сделать и пусть играются сами с собой по каким правилам захотят...
>Соответственно в случае:
>1) - всякая фигня
>2) - бекбуферкопи
Как я понял, у него такая фигня:
1) Фон (тайлмап или что-нибудь с параллаксом);
2) Игрок(и) с их анимациями и шейдерами;
3) Бекбуферкопи???
Т.е. в любом случае игроки ВПЕЧАТЫВАЮТСЯ в фон. Если фона не будет, будет чернота/серота или какой там у него цвет очистки экрана по умолчанию стоит. Как ты предлагаешь вырезать игроков из фона? Разве что заливать экран FF00FF и потом в коде шейдера пропускать пиксели с цветом (1, 0, 1).
>Вьюпорты же не просто так лагают при создании
Да, конечно, они создают текстуры и т.п.
>А если у меня 100 персонажей?
А если завтра захочешь 1.000.000.000 персонажей?
>Игроку ждать загрузки игры 20сек?
>У меня 5 вьюпортов лаг делают на 2 сек.
Опиши, какие настройки вьюпорта используешь. Особенно размер текстуры. По твоим словам кажется, что ты пытался создать текстуру размером с весь игровой уровень (сколько там, десятки тысяч пикселей?) - вполне возможно, что ты вышел за пределы видеопамяти и винда пыталась найти место под такую огромную текстуру в системной памяти, которая также доступна видеокарте, да ещё мог своп файл подключиться к этому. Алсо, что за видеокарта? Может, у тебя встроенное видеоядро в ноутбуке, а мы будем гадать, почему у тебя что-то тормозит...
>Вот из-за таких оптимизаторов все игры по сотни гигов весом.
Лолшто, это как раз из-за отсутствия оптимизаторов в команде разработчиков рождаются проекты по 100+ ГБ весом. И гигабайты эти не из-за кода, а из-за всяких хайполи моделей и 4К текстур, которые высрали яжхудожники, а оптимизаторов с дубинкой за их спиной не оказалось, чтобы выпилить всё это "некстген" говно в зародыше. Конкретно вьюпорты только на видеопамять должны действовать, выделяя память под текстуру, но если у тебя пиксель-арт платформер, то это мелочь даже для 5 персонажей.
> Опиши, какие настройки вьюпорта используешь.
150 на 150 размер вьюпорта. Все тени и сглаживания убраны, т.к. для 2д они не нужны.
Внутри вьюпорта 18 контролов.
Текстуры:
50х50 1шт
480x480 1шт
213х364 1шт
518х273 1шт
270х270 2шт (6 использований атласа)
63х63 1шт
Шейдер без циклов в пару строк 1шт
Ну, я не знаю, что у тебя там может лагать. Вот, собрал на скорую руку тестовый проект: 15 независимых юнитов, у каждого свой Viewport, шейдеры на каждой части тела и шейдер на результат из Viewport для телепортации, всё прекрасно телепортируется и не лагает, а игра запускается как обычно - около секунды.
Больше всего времени потратил на написание шейдера телепортации, но на видео эффект не разглядеть(
Давайте немного отдохнём и подумаем, как бы было, если бы Хуан работал в Майкрософт? Мой пикрелейтед:
>пикрелейтед
XML был бы намного удобнее для ручного редактирования файлов сцен. Сейчас открываешь и вынужден разбираться, кто от кого наследуется. К тому же сейчас .tscn читается за несколько проходов, из-за чего неудачное редактирование ломает файл - Godot просто отказывается загружать сцену, не объясняя причину. С древовидной структурой файла по типу XML этого бы не было, потому что данные считывались бы в один проход и уже потом изучались движком, а не так что отсутствие какого-то ресурса ломает весь процесс загрузки этой сцены.
С другой стороны, XML файлы больше весят, а их парсер занимает больше строк кода и дольше работает по сравнению с, например, JSON, но JSON здесь использовать не получится из-за отсутствия меток.
Может дело в канвасах? Измени все спрайты на текстур ректы. А может дело в том, что у тебя везде юзается 1 текстура иконки годо.
>Текстуры:
>везде юзается 1 текстура иконки годо.
Это не должно влиять на инициализацию Viewport, потому что используемые в конкретном Viewport текстуры не зависят от него - они могут использоваться где угодно. Сам вьюпорт в минимальной конфигурации должен создавать только одну новую текстуру - ту, в которую он рендерит. У меня в примере получается 15 независимых текстур 512x512, в которые независимо рендерят 15 вьюпортов. Т.е. конкретно вьюпорты на этапе инициализации создают 15 текстур и всё, больше лагать нечему. Если бы проблема была в используемых текстурах, она бы проявлялась независимо от использования вьюпортов.
>Может дело в канвасах?
Каких канвасах? Спрайт - потомок CanvasItem.
>Измени все спрайты на текстур ректы.
1. Зачем? Персонажи создаются из спрайтов. Спрайты проще анимировать и у них нет лишних функций, которые требуются только для элементов интерфейса.
2. TextureRect такой же потомок CanvasItem, что и Sprite. Разница только в разном наборе дополнительных возможностей, которые отличаются у Node2D и Control. Под капотом рендеринг у них должен быть одинаковыми функциями OpenGL, т.е. на вьюпорты это не влияет.
Я предполагаю, что лаг может быть вызван компиляцией большого количества шейдеров. В моём примере всего три шейдера: шейдер портала, шейдер части тела и шейдер телепортации. Но этот лаг будет независимо от количества вьюпортов, ведь вьюпорты не вызывают повторной компиляции шейдеров.
Я попробовал изменить разные настройки в своём тестовом проекте и не смог добиться появления лага. Возможно, проблема в твоём железе или драйверах, или в каком-то другом месте твоей игры. Также дело может быть в том, что я использую Godot 3.5. Пробовал перенести проект на новую версию? Если нет, почему?
Попробовал на 3.5. Все равно лагает. Видимо проблема в том, что имеется 10 лейблов на персонаже.
Помню, в 2009-ом году делал игру на делфи и Asphyre Sphynx (или даже не Sphynx, а просто Asphyre, но меня пёрло с этих «phy») и тоже столкнулся с тем, что шрифты жутко тормозят, прямо каждая лишняя строчка бьёт по fps. В итоге сделал сюжетные тексты тупо скриншотами.
>Видимо проблема в том, что имеется 10 лейблов на персонаже.
Откуда такая уверенность? Если убрать надписи или назначить им visible = false, проблемы нет? А ты пробовал считать, сколько 2D draw call делает движок?
https://docs.godotengine.org/en/3.5/classes/class_performance.html
>Performance.get_monitor(Performance.RENDER_2D_DRAW_CALLS_IN_FRAME)
Раньше на Godot жаловались за то, что он в надписях каждую букву отдельным draw call рисует. В какой-то версии это исправили, теперь надписи по умолчанию батчатся. Может, ты в настройках проекта это отключил? Или надписей так много, что батчинг лагает.
Если нужны статичные надписи, вроде имени или надписей на кнопках, можно отрендерить их в текстуру с помощью ещё одного Viewport и выводить уже только текстуру. Всё равно игры чаще всего на весь экран запускаются и рендерить надписи в другом масштабе обычно не нужно. Если надписи нужно изменять, тогда, конечно, проблема, но можно делать при необходимости обновить текст это:
>Viewport.render_target_update_mode = Viewport.UPDATE_ONCE
И тогда использование встроенного рендеринга шрифтами будет минимальным, только один кадр на каждое изменение текста.
А вообще, это всё гадание на кофейной гуще, никто точно тебе не скажет, что и почему у тебя лагает, потому что проект только у тебя. Используй профайлер на вкладке дебага, он иногда может помочь найти узкое место.
Есть ли какой способ в 2к22 из РФ получить копеечку с гугл-плея? Игра почти готова. Прокси-паблишеры какие-нибудь казахстанские?
репосту и сюда, ибо зделол на годоте
репосту и сюда, ибо зделол на годоте
Релизься на бусти, лол.
Бамп.
И молчим дальше. Работаем.
И молчим дальше. Работаем.
Может, лучше контентом бампать?
Скриншотики, шебм...
Я щас не геймдевом занят. Скриншотики будут несколько нерелейтед.
Подскажите пожалуйста, как реализовать Glow, чтобы свечение было видно не только на фоне объекта (пикрил1), но и на фоне неба/на фоне ничего (как пикрил2) ?
Через настройки постпроцессинга (который по умолчанию в проекте выключен, чтобы запускаться на любой встройке). Деталей не подскажу, сам в этом вопросе неоч.
> Деталей не подскажу
Но еще вот что добавлю: Готовься к шуму вентиляторов видюхи. Графические плюшки уже не зависят от движка, а зависят от железа.
>Подскажите пожалуйста, как реализовать Glow, чтобы свечение было видно не только на фоне объекта (пикрил1), но и на фоне неба/на фоне ничего (как пикрил2) ?
Нарисуй большой квад на весь экран сначала, потом рендери.
Привет, Анон! Скажи, пожалуйста, реализуем ли в Годо проект уровня Elden Ring? Интересует даже не столько именно графическая составляющая, сколько масштабы отображения самого мира. Я имею ввиду огромные замки в дали, перед которыми простираются бескрайние поля, локации масштаба столицы Лейнделл. Инетесно, может ли движок отрисовывать настолько по своему мощные сцены в стабильных 60 кадров? И не обязательно должна быть графика уровня Кольца. Пускай это будут не настолько деталезированые модели, не настолько качественные текстуры. Но сам факт мастбабности отображение. Кароче, Анон, ты меня понял! Ответь, пожалуйста! Спасибо за внимание.
Если вкратце, то может.
Если в деталях, то чтобы всё это отобразить, придётся очень много бойлерплейта накодить самому, того, что в юнити/анриле подают из коробки: шейдеры, системы ЛОДирования и т.п. В четвёрке за счёт вулкана чуточку меньше, но все ещё много.
Прелести опенсорца. Если чего-то нет - допиши сам. Зато бесплатно и без вендорлока.
Короткий ответ: да, реализуем.
Длинный ответ: огромные открытые пространства тебе таковыми только кажутся. Это тонкая настройка всевозможных визуальных трюков потребляющих мало ресурсов.
Другой длинный ответ: реализуем, и Elder Ring, и GTA V, и World of Warcraft, и все что угодно. Для того чтобы создать проект уровня Elder Ring тебе нужен не движок уровня Elder Ring, тебе нужны специалисты уровня Elder Ring.
ОГРОМНОЕ спасибо за развернутые ответы, Господа Анонимы!
выглядит прикольно, это типа гаррис мод?
А вот я бы предпочёл формат, более похожий на gdscript. Кто узнал формат пикрелейтеда - тому респект!
В этот формат идеально встроились бы вложенные скрипты (хоть это и не айс, и антипаттерн, но).
Я уже хочу этот формат в движке! Уже и имя ему придумал. Эх, уметь бы в кресты. Запилить бы модуль сериализатора.
Годо растягивает игру по всему бровзеру, когда в развёрнутом виде, что портит вид, и отображается с нормальными пропорциями, когда в оконном.
Возможно ли запускать игру в новом окне бровзера со строго заданными размерами окна?
Возможно ли как-то победить растягивание в развёрнутом виде, так чтобы игра была по центру и без пустоты по краям?
С настройками stretch игрался, с разрешением тоже, не работает именно для веб.
Вопрос отпал
Сап, аноны, такой вопрос. Как почеловечески в годо делать рейкаст по клику мыши? Собсно сабж:
Сейчас делаю так, получаю ивент клика и позицию мыши в _input колбеке, однако, рейкаст подразумевает взаимодействие с физическим пространством, а как говорит гайд по рейкасту:
> the only time accessing space is safe is during the Node._physics_process() callback. Accessing it from outside this function may result in an error due to space being locked.
Собсно сейчас рейкаст выглядит уродливо, к меня есть значит в объекте ray_from ray_to, которые устанавливаются в _input и переменная ray_to_changed, которая по сути просто наблюдает за тем что игрок куда-то кликнул. А сам рейкаст происходит в _physics_process где пикрелейтед страхолюдина. Собсно вопрос такой: можно ли как то красивее сделать? Отложить допустим выполнение рейкаста в _input до физическоо кадра или что-то в этом духе?
Сейчас делаю так, получаю ивент клика и позицию мыши в _input колбеке, однако, рейкаст подразумевает взаимодействие с физическим пространством, а как говорит гайд по рейкасту:
> the only time accessing space is safe is during the Node._physics_process() callback. Accessing it from outside this function may result in an error due to space being locked.
Собсно сейчас рейкаст выглядит уродливо, к меня есть значит в объекте ray_from ray_to, которые устанавливаются в _input и переменная ray_to_changed, которая по сути просто наблюдает за тем что игрок куда-то кликнул. А сам рейкаст происходит в _physics_process где пикрелейтед страхолюдина. Собсно вопрос такой: можно ли как то красивее сделать? Отложить допустим выполнение рейкаста в _input до физическоо кадра или что-то в этом духе?
Какой-то XML для изобретателей велосипедов.
>выглядит прикольно, это типа гаррис мод?
Нет, планируется выживание на парящих островах посредством строительства воздушных кораблей (дирижаблей и т.п.). Строишь корабль -> улетаешь с обрушающегося острова -> ищешь следующий остров в поисках топлива и ресурсов для починки/расширения корабля, а также возможных помощников. Если по какой-то причине упал в бездну, теряешь корабль и ресурсы и начинаешь на новом острове почти с нуля.
Ну вот же официальный пример:
https://docs.godotengine.org/en/latest/tutorials/physics/ray-casting.html#d-ray-casting-from-screen
От _input тебе нужно сохранить только event.position, который означает координаты клика мыши в экранной системе координат. В _physics_process делаешь сам рейкаст по примеру, если недавно произошёл клик.
>пикрелейтед страхолюдина
Убери её в отдельный метод.
>Отложить допустим выполнение рейкаста в _input до физическоо кадра
Ну, можно и так. В 3.x это yield(), в 4.x - await.
Проблема в том, что ты можешь сделать только один такой блок кода в _input, в самом конце. Потому что yield/await прерывает выполнение функции. И вообще, это нарушает последовательность выполнения кода, так что, имхо, в хорошем коде должно быть минимум yield/await.
По своей сути yield/await идентичны goto/jump в старых и низкоуровневых языках, а их использование всегда считалось плохим с точки зрения структурного программирования. И уж тем более это плохо для ООП.
>масштабы отображения самого мира
Масштабность в играх обычно ограничена типом float, который обычно single, поэтому во многих игровых движках ты ограничен территорией около 8 км в длину, после которых начинается расколбас физики. В майнкрафте, например, была похожая проблема, но поскольку майнкрафт сделан на основе целочисленных переменных, там расколбас начинался что-то около двух миллионов километров. Универсальные движки работают с вещественными числами, поэтому у них масштаб поменьше, но зато ты можешь размещать предметы с точностью до миллиметра, а не на метровой сетке. Есть способы обойти ограничения float, в частности скомпилировать движок в режиме double, или просто сдвигать весь мир вокруг игрока вместо сдвигания игрока относительно мира, либо телепортировать игрока вместе с миром в точку (0;0;0) при достижении опасной границы.
>Я имею ввиду огромные замки в дали
Если игрок принципиально не способен добраться до этого огромного замка, или должен пройти несколько длинных локаций до него, то такие огромные объекты в играх часто рендерятся в виде плоской картинки на небесном кубе (или цилиндре, или сфере), потому что в любом случае игрок не сможет заметить подвох - слишком большое расстояние, чтобы наблюдать эффекты перспективы. В опенворлде тоже можно сделать такое, если впечатывать в небо гигантские объекты по мере удаления игрока от них на какое-то определённое расстояние, после которого смещение игрока не влияет на внешний вид этих объектов. Короче, нужно думать и экспериментировать.
>перед которыми простираются бескрайние поля
Не знаю, что ты имеешь в виду под бескрайностью, т.к. в 100% опенворлд игр любая локация уходит в дымку или просто исчезает после какого-то расстояния, т.к. виртуальная камера ограничена дальностью прорисовки (опять же из-за ограничений float, но уже на видеокарте). Тот же майнкрафт условно бесконечен (ты будешь годами играть 24/7, чтобы добраться до края мира пешком), но область прорисовки у него не такая уж "бескрайняя".
>локации масштаба столицы Лейнделл.
Понятия не имею, о чём ты.
>может ли движок отрисовывать настолько по своему мощные сцены в стабильных 60 кадров
Вопрос не в том, сможет ли движок что-то сделать. Вопрос в том, сможешь ли ты с помощью движка нарисовать такие сцены и затем оптимизировать их до 60 кадров в секунду. Движок может автоматизировать какие-то тривиальные задачи, необходимые всем играм, но в остальном это такой же инструмент, как мольберт, холст, кисти и краски художника. И художник в данном случае ты.
Воспринимай игровую сцену как картину. Есть передний план, есть средний план, есть дальний план. Техника отображения для разных планов может отличаться (и не только изменением level of detail моделей). На преднем плане у тебя анимированные персонажи, на среднем какие-нибудь квадратные домики и однообразная растительность, на заднем - гигантские горы и замки, раз уж ты так хочешь. Нужно думать, как это всё совместить и переключать планы, движок сам за тебя игру не сделает, даже если ты хочешь симулятор ходьбы.
ОГРОМНОЕ спасибо за столь развернутый ответ, Господин Анон!
Ставь I_Know_That_Feel_Bro.jpg если узнал себя.
>ОГРОМНОЕ спасибо
>ОГРОМНОЕ спасибо
Честно говоря, не понимаю, за что ты так благодаришь нас. Ты недавно тут? Планируешь игру делать или так, мимо проходил и просто поинтересовался? Судя по твоим вопросам, ты совсем новичок, и тебе не стоит лезть в создание больших 3D опенворлдов, независимо от выбранного движка. Это сложно, а первым проектом будет намного сложнее. Начинай с простых проектов, например, по туториалам - там обычно простые 2D аркады. Тебе в любом случае потребуется изучить базу, без которой никакой игры не получится. 3D игры с открытым миром - это уже следующий уровень со своими специфичными проблемами. Короче, начинай с простого.
Алсо, по графике - не думай, что если ты хочешь "попроще", тебе будет сильно легче. Все эти лоуполи и мультяшные игры только кажутся простыми. На практике сделать просто выглядящую графику сложнее, чем обычно кажется новичку. Без опыта в 3D ты легко переоценишь свои возможности, столкнёшься с высокой сложностью и потеряешь мотивацию продолжать... Короче, пуская слюни на какую-нибудь стилизованную "простую" графику, рассчитывай на то, что твои поделки будут на порядок хуже выглядеть, по крайней мере пока не наберёшься опыта.
> Честно говоря, не понимаю, за что ты так благодаришь нас. Ты недавно тут?
ИМХО это залётный движкосрачер кривляется. Подобных типов буквально корёжит от слов о взаимопомощи и любви в ОП посте. Поэтому они залетают и юродствуют. Постарайся поменьше кормить их вниманием.
инбифор: шизик, таблетки и т.п. газлайтинг
Ты-то непидарас.
Охуенно. Типа битва с русалкой из Shantae, даже вроде бы музыка оттуда. У тебя есть твиттер или что-то подобное где можно следить за разработкой?
бамп
Это тематика. Какой нахуй бамп?
Ты понимаешь, что этой сценой ты признаёшься в том, что у тебя ворарефилия? Мог быть какой угодно приём босса, но нет, ты выбрал именно заглатывание игрока.
Глянул летсплей этой сцены в Shantae. Там годный сюжет со смыслом, красивая графика и няшные 2D персонажи, а гига русалку мы не убиваем, а освобождаем. И главное, нет никаких искусственных преград, вроде неудобного ракурса камеры. А что у тебя? 3D сиськи стрёмной красной бабы на стрёмном красном фоне, которую непонятно как бить, а манёвры камеры хоть и выглядят круто, но, очевидно, будут только мешать. Не говоря уж про взрывающиеся бочки, магически дамажащие огненное создание огненного ада, что рвёт все шаблоны фэнтези игр. Зато подлизнул ворарефилам и/или подрочил на это. Вот что значит - нужно заранее придумывать хороший дизайн, чтобы потом не пришлось двойную работу делать. Сейчас этот продукт подойдёт только узкой категории фетишистов, которые схавают что угодно на желаемую ими тему (демоны + гиганты + ворарефилия?).
Но как игра инди-новичка - зачот, пили ищо. Модели, анимации - если делал всё сам, то хорошо постарался, молодец, но если стырил, тогда вообще не ясно что тут можно оценивать...
Без обид, не вижу смысла хвалить впустую и избегать критики, даже если это может кого-то отпугнуть.
>Ты понимаешь, что этой сценой ты признаёшься в том, что у тебя ворарефилия?
Предположим, дальше что?
>Там годный сюжет со смыслом, красивая графика и няшные 2D персонажи, а гига русалку мы не убиваем, а освобождаем.
И вообще все эти ваши игры про одно только насилие, детей гипнотизируют, сатанисты, чтобы потом курили, кололись, слушали этот ваш рок нечистый и потом шли одноклассников расстреливать, а может и того хуже, гейпарады устраивать.
Я серьёзно, если это пародия на оригинальную сцену в Shantae, то это крайне слабая пародия. Такое ощущение, что много сил было вложено в работу камерой, но вот общий дизайн и геймплей очень слабые. Я только ближе к концу видео догнал, что игроку нужно сбрасывать бочки и заманивать босса на удар по бочке, чтобы та взорвалась и уменьшила ХП босса в правом нижнем углу. Будь это рандомная демка из интернета, полная игра меня бы не заинтересовала вообще никак (а вот коллекцию игр Shantae я купил несколько лет назад и ни разу не запускал, ибо разрабы заслужили эти деньги).
Хотя, может, это мой субъективный вкус.
РЯЯЯЯЯЯЯЯЯЯЯЯЯЯ
ТВАЯ ИГОРА ГАВНО
РЯЯЯЯЯЯЯЯЯЯЯЯЯЯЯЯЯЯЯЯЯ
ТЫ ФЕТИШИСТ ПРОКЛИТЫЙ
РЯЯЯЯЯЯЯЯЯЯЯЯЯЯЯЯЯЯЯЯЯЯЯЯЯЯЯЯЯЯ
И ТЫ ТАКОЕ ГОВНО В ОДНО РЫЛО СКЛЕПАЛ?????
РЯЯЯЯЯЯЯЯЯЯЯЯЯЯЯЯЯЯЯЯЯЯЯЯ
ЛАЛ НУ ТЫ И АБСОС ДЕЛОТЬ ХУЖИ СТУДИИ ПРАФФЕСИНАЛАВ
РЯЯЯЯЯЯЯЯЯЯЯЯЯЯЯЯЯЯЯЯЯЯЯЯЯЯЯЯЯЯЯ
Мда. А потом люди плачут почему в треде никто из творцов не постит. Ладно бы была конструктивная критика, но вы тупо парня засрали.
Да лан, это положительная реакция. У него просто в пятой точке запекло от зависти когда увидел как чел из говна и палок геймплей состряпал. Там в лавине текста одни эмоции.
Хорошая попытка, но тут нужна качетсвенная мокап анимация.
Тест
Они все правильно сказали. Я уже видел случай, как на одном форуме проект с огромным потенциалом превратился в неиграбельную парашу просто потому что там люди боялись критиковать и тряслись, как бы кого не обидеть. Все там хлопали в ладоши: "Ах как миленько! Ах как красивенько! Жду не дождусь!" вместо того, чтобы прямо сказать автору, что он обосрался с подливой в плане геймплея и в его игру тупо не весело играть. И, естественно, никто в нее играть не стал по итогу.
> Я уже видел случай, как на одном форуме проект с огромным потенциалом превратился в неиграбельную парашу просто потому что там люди боялись критиковать и тряслись, как бы кого не обидеть.
Где-то в интернете есть место где бояться критиковать и обидеть. Рассказал своей девушке, она от смеха существовать начала.
Выйди за пределы харкачика, и ты охуеешь.
Не поверишь, вторая неделя пошла как на эту помойку заходить начал.
Ну тогда съеби нахуй, нюфаня.
А ты сделай так чтобы я съебал.
Эм... Пожалуйста?
Неть
Тогда оставайся.
бамп
> Они все правильно сказали. Я уже видел случай, как на одном форуме проект с огромным потенциалом превратился в неиграбельную парашу просто потому что там люди боялись критиковать и тряслись, как бы кого не обидеть. Все там хлопали в ладоши: "Ах как миленько! Ах как красивенько! Жду не дождусь!" вместо того, чтобы прямо сказать автору, что он обосрался с подливой в плане геймплея и в его игру тупо не весело играть. И, естественно, никто в нее играть не стал по итогу.
Официально двачую.
Примеры скинете? Очень интересно.
>Они все правильно сказали.
Ну давай разберем, что они правильно сказали.
>Ты понимаешь, что этой сценой ты признаёшься в том, что у тебя ворарефилия?
ЭТОЙ СЦЕНОЙ ТЫ ПРИЗНАЕШЬСЯ... Ей богу, будто анон скинувший привьюшки в растлении несовершеннолетних сознался. Чел просто попытался выставить странный фетиш автора как преступление против человечества. Что тут правильного?
>Глянул летсплей этой сцены в Shantae. Там годный сюжет со смыслом, красивая графика и няшные 2D персонажи, а гига русалку мы не убиваем, а освобождаем. А что у тебя? 3D сиськи стрёмной красной бабы на стрёмном красном фоне
Это про что было сказано? В Shantae не играл, но после этого поста посмотрел упомянутый отрывок в ютубе. Да. видимо автор ей вдохновлялся. И что? Вот о чем это сравнение?
>Не говоря уж про взрывающиеся бочки, магически дамажащие огненное создание огненного ада, что рвёт все шаблоны фэнтези игр.
Что тут было сказано правильно? Какие нахуй шаблоны фентези игр? Ну вот давай пойдем поиграем в World of Warcraft где маг в спеке огня ФАЕРБОЛАМИ разбирает ОГНЕННЫХ элементалей. Челу не говорите, у него кровавый понос начнется от такого разрыва шаблона фентези игр.
>Сейчас этот продукт подойдёт только узкой категории фетишистов, которые схавают что угодно на желаемую ими тему
Тут тоже непонятно о чем сказано. Мы даже не знаем какая была конечная цель. Анон ничего не предоставил, ни описания, ни цели проекта, ничего. Может в этом весь смысл и был чтобы сделать маленькую фетишню демку, быть может даже за деньги, по заказу какого-нибудь фетишиста. Мы не знаем. А чел, который "говорит все правилно", за автора просто напридумывал его цели.
>Но как игра инди-новичка - зачот, пили ищо. Модели, анимации - если делал всё сам, то хорошо постарался, молодец, но если стырил, тогда вообще не ясно что тут можно оценивать...
И вот на этом моменте чел показал что вообще ничего не понимает.
Для того чтобы научиться программировать, нужно потратить тысячу часов. Чтобы научиться моделить/рисовать, еще тысячу часов только на модели/рисование. Чтобы научиться анимировать нарисованное, еще тысячу часов. Чтобы музыку научиться сочинять, еще тысячу часов. А чтобы научиться все вышеперечисленное делать помимо прочего хорошо, каждую тысячу часов не помешало бы помножить хотя бы на три. И это уже не человек-оркестр, а полноценная команда специалистов, каждый в своей области.
Но тут приходит обсос и заявляет, что если ты неспособен выполнять работу четырех отдельно взятых специалистов и берешь чужие ассеты, значит ты говно и оценивать твою работу незачем. То есть чел живет в своем воображаемом мире, полностью оторванный от реальности. Что он мог сказать правильно?
Официально двачую. Чего набросились на пацана?
Мимо проходил, просто почитываю тред, но полностью согласен с аноном. Конечно это касается и любого другого треда по разработке, но красавчик!
Хорошо всё расписал, подписываюсь под каждым словом.
>Предположим, дальше что?
Изначально я хотел предупредить его, если он планирует показывать игру кому-то из родственников или близких друзей. Но потом до меня дошло, что это я слишком много знаю, а обычный человек ничего не поймёт, потому что в этих наших интернетах не сидит.
Алсо, когда ищешь какой-то контент на сами знаете каких сайтах и в результатах запросов постоянно лезут какие-то чужие фетиши, которые тебе в лучшем случае безразличны - начинает бомбить от любого проявления этих фетишей в интернете. Просто потому что достало, ставьте теги правильно, чтобы можно было скрыть всё и сразу.
>эти ваши игры про одно только насилие
Можно подумать, ты с этим несогласен. Даже РПГ, которые по определению про "отыгрыш роли", а вовсе не про "повышение характеристик геноцидом мобов", в большинстве случаев дают отыгрывать только убийц, в лучшем случае - воров, да и то ключевых персонажей требуется обязательно убить. Поэтому игра/сцена без насилия вызывает повышенный интерес.
>ХУЖИ СТУДИИ ПРАФФЕСИНАЛАВ
Я сомневаюсь, что графика в Shantae такая уж сложная. Регулярно вижу художников с более сложными стилями рисования, так что вряд ли это настолько недостижимая вершина геймдева, чтобы избегать её. Это только шиз с нейросетками научиться рисовать не может, поэтому завидует художникам и предвещает их скорую гибель.
>плачут почему в треде никто из творцов не постит
Потом до меня это дошло. Печально, конечно, но для таких постеров существуют форумы с жёсткой модерацией и минусами в "карму", где их не обидят.
>Ладно бы была конструктивная критика
Был на негативных эмоциях, получилось как получилось, извини, если недостаточно конструктивно.
>там люди боялись критиковать и тряслись, как бы кого не обидеть
Такое ещё бывает, когда разработчик удаляет все посты с критикой или неодобрением, оставляя только нейтральные или хвалебные отзывы. Тут уже ничем не поможешь.
>в растлении несовершеннолетних сознался
С каких пор каннибализм стал намного лучше растления несовершеннолетних? По-твоему, лучше съесть живьём несовершеннолетнюю девственницу, чем лишить её девственности? Я знаю, что ворарефилия не обязательно про каннибализм, но другие люди и на обычное аниме смотрят исключительно как на контент для педофилов, потому что там рисуют девочек в купальниках.
>Чел просто попытался выставить странный фетиш автора как преступление против человечества.
Я попытался предупредить, что это могут неправильно понять, но потом понял, что это было необязательно.
>Вот о чем это сравнение?
О смысле/сюжете и дизайне, что тут непонятного?
>в World of Warcraft где маг в спеке огня ФАЕРБОЛАМИ разбирает ОГНЕННЫХ элементалей.
Ясно. Хорошо, что я не играл в WoW, по описанию даже Minecraft намного лучше продуман:
>Blazes are also hurt by snowballs, taking 3 damage per hit. It takes 7 snowballs to kill a blaze. They are also damaged by splash water bottles, taking 1 damage per hit. Like endermen, they are also damaged by rain by 1 every half second. Like most Nether mobs, they are immune to damage from fire and lava.
Просто ПОДУМАЙ. У него гигантская баба стоит на/плавает в раскалённой лаве/магме, окружённая огнём, но при этом убивается с нескольких взрывов пороховых бочек? Где логика? Это не говоря о том, что всё происходит на деревянных подмостках, которые должны быстро сгореть в таком месте. Хороший ворлдбилдинг и боссы интересные, буду проходить на ютубе ещё. Или, по-твоему, можно сделать что угодно без нормального обоснуя?
>Анон ничего не предоставил, ни описания, ни цели проекта, ничего.
Согласен, может, там прототип из тестовых ассетов, а не финальная версия. Тогда нужно было сразу написать, что и почему, чтобы не было недопонимания.
>нужно потратить тысячу часов
>помножить хотя бы на три
Взял цифры с потолка и размножил на целый абзац. Зачем? Тебе так трудно даётся написание пары десятков строчек на GDScript? Не забывай, мы не в треде движкопись "не нравится готовое, буду писать с нуля на ассемблере", и на движке уровня Godot платформер может сделать любой художник, только вчера узнавший про это наше программирование. И сделает, если захочет. А программисту придётся учиться рисовать, если он хочет сам, без посторонней помощи сделать платформер, в который будет играть кто-то кроме его родителей.
>если ты неспособен выполнять работу четырех отдельно взятых специалистов и берешь чужие ассеты, значит ты говно и оценивать твою работу незачем
Хорошо, уговорил, создай страницу игры в Стиме и большими буквами напиши:
>Здравствуйте, я, Кирилл, потратил 3000 часов на изучение программирования для создания платформера на очень простом для освоения игровом движке Godot, а на изучение графики и всего остального решил забить, взять готовые модельки и немного их перекрасить в пейнте, ведь я не какой-то там человек-оркестр и не команда из четырёх специалистов, а одинокий и жутко голодный программист на GDScript. А теперь купите, пожалуйста, мою игру, а то мне кушать нечего, мышку компьютерную уже съел.
Потом поделишься статистикой, а мы поучимся.
Уговорили, будем лизать друг другу жопы и дрочить голландским штурвалом в безудержном хороводе Семёнов. Что нам ещё делать в /gd/-то, игры что ли?
>Где-то в интернете есть место где бояться критиковать и обидеть.
Добро пожаловать в Интернет.
https://en.wikipedia.org/wiki/Echo_chamber_(media)
>Рассказал своей девушке, она от смеха существовать начала.
Хорошая шутка, жаль, не все поймут.
Сначала думал что троллинг, но чем дальше читал тем больше понимал что ты просто безграмотный. Непонятно, зачем ты пришел в Godot-тред, здесь идет обсуждение конкретного движка людьми которые в нем реально работают. Для таких как ты рядом навалом тредов с разговорами ни о чем.
>Я сомневаюсь, что графика в Shantae такая уж сложная
>С каких пор каннибализм стал намного лучше растления несовершеннолетних?
>Хорошо, что я не играл в WoW, по описанию даже Minecraft намного лучше продуман
>Просто ПОДУМАЙ.
>Тебе так трудно даётся написание пары десятков строчек на GDScript?
орнул
>С каких пор каннибализм стал намного лучше растления несовершеннолетних?
>Хорошо, что я не играл в WoW, по описанию даже Minecraft намного лучше продуман
>Просто ПОДУМАЙ.
>Тебе так трудно даётся написание пары десятков строчек на GDScript?
орнул
> Уговорили, будем лизать друг другу жопы и дрочить голландским штурвалом
Официально двачую. Нехуй флюродросить. Даёш конструктивную критику!
Тоже с начало подумал что это троллинг, но автор поста явно шизик.
Жоска, но почему так фризит и лагает, это особенность годоти?
Фризить может если ресурсы не были подгружены перед их созданием. По видосу видно что графен лоупольный, скорее всего фпс потерялся при конвертации видео или записи.
Выглядит круто! Почему сука я так не могу сделать? Ебучий годот со своим ебучим программированием!
У меня такое чувство, что половина постов в этом треде в последнее время была написана какими-то ботами.
Автор оригинальной демки - нсфв художник, некто Zapor666, делалось в BGE пять лет назад. Еще тогда было предложение перенести это дело в Godot, но я на тот момент выгорел заниматься геймдевом на богом забытом BGE. Разродился только сейчас.
Долбите автора оригинала, может у него снова появится интерес. Хотя столько лет прошло, у него уже совсем другая жизнь и интересы, наверно. По крайней мере мои старания особого интереса не вызвали.
Это особенность офисного ПК 2011го года выпуска. С записью на фрапс оно начинает тормозить.
Я не бот, только недавно сюда зашёл!
Если он забил, почему я должен заставлять его делать это? Сам хочу делать красоту! А не как аутист даже не находить где писать код сука!
Тут на днях изучал малоизвестные языки и ИДЕ для них, и обнаружил IntelliJ IDEA, так вот в ней имеется плагин ГДскрипт. Кому охота в большой ИДЕ скрипты писать, но майковские студии не нравятся - вот, попробуйте.
>Почему сука я так не могу сделать? Ебучий годот со своим ебучим программированием!
Да чего там программировать, всё очень просто.
Просто же, ну? Сколько строчек кода, не считая пустых и соединения сигналов с обработчиками?
Там же должна быть самая простая высокоуровеная логика и всё, никаких сложных алгоритмов, оптимизаций работы с гигантскими массивами данных и т.д.
>даже не находить где писать код
В окне редактора кода. Читай базовые туториалы в официальной документации, там всё простым английским языком объясняется, разберёшься.
>Кому охота в большой ИДЕ скрипты писать
Действительно, кому охота? GDScript привлекает своей встроенностью в редактор сцен. Не нужно никуда переключаться и при этом все базовые удобства реализованы - подсветка синтаксиса, автодополнение и указание на ошибку. Что ещё нужно? Загрузка редактора 30 секунд, чтоб "как у серьёзных людей" было? Или два десятка тулбаров сверху, снизу и по кругу, чтоб код вообще не видно было? Зачем эта "большая IDE" нужна, если Godot и есть самодостаточная IDE?
>An integrated development environment (IDE) is a software application that provides comprehensive facilities to computer programmers for software development. An IDE normally consists of at least a source code editor, build automation tools and a debugger.
Редактор кода есть, собрать проект можно, даже дебаггер с доступом к памяти есть. Нормальная IDE. После программирования в Блокноте и на бумаге вообще круто.
>Сколько строчек кода, не считая пустых и соединения сигналов с обработчиками?
56 .gd файлов, суммарно на 1623 строк из которых 25 комментариев и 524 пустых строк. То бишь 1074 строк непосредственно кода.
В целом, немного, получается в среднем 19 строк кода на файл.
Добавлять к значению код GDSL шейдеров? Наверно можно опустить, ибо всего 3 простых файла, один из которых поленился и скачал (шейдер обводки).
>Там же должна быть самая простая высокоуровеная логика и всё, никаких сложных алгоритмов
Мне тяжело оценить сложность со своей колокольни.
Cама логика босс файта - набор скриптов с сигналами.
Поведение босса и персонажа игрока - конечный автомат с набором описанных состояний, это уже паттерн ООП.
> 56 .gd файлов, суммарно на 1623 строк из которых 25 комментариев и 524 пустых строк. То бишь 1074 строк непосредственно кода.
> Почему сука я так не могу сделать?
У этого анона скорее всего один скрипт , ну максимум три. Большая часть контента - анимации.
Как теперь в гугл плей публиковаться-то блять, аааа?
А чё случилось?
Как раньше, берёшь и публикуешь.
Берешь и не можешь оплатить 25 баксов за аккаунт разработчика.
Берешь и не можешь ни продавать, ни рекламу ставить.
С таким же успехом можно в гроб публиковаться.
А В ГОДОТЕ-ЧЕТЫРЕ БУДЕТ КНОПКА "СДЕЛАТЬ ЗАЕБИСЬ"
@
ОН РЕЛИЗНЕТСЯ СКОРО, НАДО ТОЛЬКО ПОДОЖДАТЬ
@
ТАМ БУДЕТ ВУЛКАН, ТАМ ВСЁ БУДЕТ В КАЙФ
@
ТАМ НАВЕРНОЕ ВООБЩЕ НЕ НАДО БУДЕТ ПРОГРАММИРОВАТЬ
Я ПРОСНУЛСЯ СРЕДИ НОЧИ И ПОНЯЛ:
ДАЙ ДОНАТ ХУАНУ!
@
ОН РЕЛИЗНЕТСЯ СКОРО, НАДО ТОЛЬКО ПОДОЖДАТЬ
@
ТАМ БУДЕТ ВУЛКАН, ТАМ ВСЁ БУДЕТ В КАЙФ
@
ТАМ НАВЕРНОЕ ВООБЩЕ НЕ НАДО БУДЕТ ПРОГРАММИРОВАТЬ
Я ПРОСНУЛСЯ СРЕДИ НОЧИ И ПОНЯЛ:
ДАЙ ДОНАТ ХУАНУ!
НАКОНЕЦ-ТО УМНЫЕ ПОГРОМИТЫ НАКОДИЛИ НЕЙРОСЕТЬ СПОСОБНУЮ РИСОВАТЬ ФУРРИ-ПРОН
@
НАБЛЮДАЕШЬ КАК ВСЕ ХУЙДОЖНИКИ ДЖАМПАЮТ ИЗ СВОИХ ПЕНТХАУСОВ С РАЗОРВАННЫМИ ПЕРДАКАМИ
Глаза есть у всех, а мозг не у всех...
Утверждаю-этот тоже безыгорный.
Все кто говорят про диздоки-самые безыгорные, это у них больная тема.
Видел что местный азатский Иггдрасиль в элдене как-то херово рендерился и его отключение бустит фэпесы на +10, это значит не 2д спрайт же?
Хосспаде, блять.
Щяс бы смысол в технодемке искать.
Впопич, ты что-ле? Я так и слышу это платиновое...
НИ-РИ-АЛИ-СТИЧНААА!!
Представляю что с аноном станет, если он атаку титанов увидит.
С начала технического прогресса интеллигенция выставляла себя как пик развития человека, дескать, роботы научаться делать всю грязную работу, а писать музыку/картины/романы машины никогда не смогут, поскольку это недостижимый уровень возвышенной человеческой природы.
Реальность: робот не может заменить даже дворника, зато меньше чем за сто лет после изобретения первого компьютера машина уже пишет музыку/картины/романы.
Нейросеткошизики как жиды, их уже из 109 тредов выгнали ссаными тряпками, теперь они сюда со своей говной пришли.
Нашёл нужный мне гайд. Узнал о новом инструменте TileMap. Будет время, начну отрисовывать графику.
>Да чего там программировать, всё очень просто.
Я в ренпае две недели получал ошибки, пока не сообразил что в коде обязательно должны быть отступы.
>В окне редактора кода.
Ты хоть бы оставил скриншот где он находится!Без шуток, так куда удобнее Но я нашёл.
Для меня один скрипт написать, как Эверест с голой попой покорить! По этому пацан красава, решил сделать и сделал.
>Да чего там программировать, всё очень просто.
Я в ренпае две недели получал ошибки, пока не сообразил что в коде обязательно должны быть отступы.
>В окне редактора кода.
Ты хоть бы оставил скриншот где он находится!Без шуток, так куда удобнее Но я нашёл.
Для меня один скрипт написать, как Эверест с голой попой покорить! По этому пацан красава, решил сделать и сделал.
>Я в ренпае две недели получал ошибки
Все программисты допускают ошибки, даже самые крутые. Это нормально, никто не идеален, а вдумчивый анализ и исправление ошибок делает тебя лучше.
>пока не сообразил что в коде обязательно должны быть отступы
Это азы программирования на питоне или том языке, который использует ренпи. Если ты допускал такую ошибку, это значит, что ты либо совсем не читал базовые туториалы, либо пробежал по ним глазами и ничего не усвоил, не попробовал на практике предложенные примеры. Это популярная ошибка у людей, которые хотят сразу сесть и начать делать игру мечты, не осознавая, что они даже простейший хелло ворлд сделать не смогут. Имей терпение и внимательно проходи все начальные туториалы/курсы или что там предлагают для выбранных инструментов.
>Ты хоть бы оставил скриншот где он находится!
Это ещё раз показывает твою невнимательность. Если бы ты внимательно изучал интерфейс редактора, то смог бы самостоятельно найти и кнопку "Script" вверху, и кнопку с иконкой пергаментного свитка в инспекторе сцены, и ещё кучу других связанных со скриптами кнопок. Вместо этого ты бегло глянул, расстроился, что "ничего не понятно с беглого взгляда" и пошёл жаловаться на форум. А мог бы хотя бы погуглить базовые туториалы и оказаться в официальной документации, где подробно описывают все элементы интерфейса редактора (со скриншотами). Ну, или внимательно изучить всё самостоятельно.
>Для меня один скрипт написать, как Эверест с голой попой покорить!
В отличие от покорения Эвереста, написание кода довольно быстро становится таким же простым, как печать постов на форум - ты просто печатаешь, как если бы общался с человеком, только вместо человека на том конце более или менее строгий компилятор или интерпретатор (разные языки программирования допускают разный уровень вольностей построения текста, прямо как естественные языки). Совсем другое дело - прорабатывать архитектуру приложения. Полноценный программист может разработать архитектуру, не написав ни строчки кода, а те, кто только пишет код и обмякает в случае неудачно выбранной архитектуры, обычно называются "кодерами" и другими более обидными прозвищами. Но начинают все, конечно, с простого кодинга, который можно освоить за месяц, тогда как для умения разрабатывать архитектуры приложений учатся много лет.
>отключение бустит фэпесы на +10
А в процентах это сколько? Если +10 от 20, то это существенно, а если +10 от 230, то это ничего не значит и вообще может быть погрешностью измерений.
>это значит не 2д спрайт же?
Откуда нам знать? Лично я в эту игру не играл: мой компьютер её не потянет, её некуда установить, и вообще мне не интересно РПГ в сеттинге тёмного фэнтези, есть множество более интересных мне игр с намного более низкими системными требованиями.
Если у тебя лично есть эта игра и ты хочешь точно знать, как она рендерит мир в техническом плане, ты можешь попробовать сделать анализ с помощью графического дебаггера, который разделяет процесс рендеринга на отдельные шаги и чётко показывает, что делает видеокарта в процессе каждого кадра... Название не помню, другие аноны здесь упоминали это и должны подсказать. Единственный нюанс - если игра завязана на онлайн и имеет строгий античит, он, теоретически, может среагировать на это вмешательство в процесс игры, но точно я этого сказать не могу.
Алсо, 2D спрайт не обязательно дешевле 3D куба с текстурой. Отрисовка двух треугольников на весь экран действительно дешева, но только если они полностью закрашены непрозрачной текстурой. Если текстура с прозрачностью, то есть часть пикселей не отображается или смешивается с фоном, то такие два треугольника будут дороже более сложной геометрии без прозрачных элементов. Разработчику нужно смотреть в каждом конкретном случае, когда будет экономнее накинуть геометрии, а когда - "обмануть" зрителя прозрачной текстурой. В частности, в прошлом часто делали различные цепи и решётки прозрачными текстурами, но сегодня будет экономнее сделать их геометрией, даже если на это потребуется много треугольников.
>НАКОНЕЦ-ТО УМНЫЕ ПОГРОМИТЫ НАКОДИЛИ НЕЙРОСЕТЬ СПОСОБНУЮ РИСОВАТЬ ФУРРИ-ПРОН
@
ОНА РИСУЕТ ЛУЧШЕ ВСЕХ ЛЮДЕЙ В МИРЕ И СПОСОБНА НАРИСОВАТЬ АБСОЛЮТНО ВСЁ, ЧТО ПОПРОСИШЬ, ХОТЯ ОБУЧАЛИ ЕЁ ТОЛЬКО НА ФУРРИ-ПРОНЕ
@
ТЕХНАРИ ПОЖИМАЮТ ПЛЕЧАМИ, ВЕДЬ ЗАДАЧУ ОНИ ВЫПОЛНИЛИ НА 146%, РАБОТАЕТ - НЕ ТРОГАЙ
@
ГУМАНИТАРИИ БЕСПОКОЯТСЯ И ТРЕБУЮТ ПРОВЕСТИ ТЕСТ ТЬЮРИНГА ИЛИ ЧТО-ТО ПОСЕРЬЁЗНЕЕ
@
НЕЙРОСЕТЬ С БЛЕСКОМ ПРОВАЛИВАЕТ ТЕСТ ТЬЮРИНГА И ЭТО УСПОКАИВАЕТ ГУМАНИТАРИЕВ
@
ТЕХНАРИ ПОНИМАЮТ ПОДВОХ, НО УЖЕ ПОЗДНО
@
НЕЙРОСЕТЬ ВЗЛОМАЛА АВТОМАТИЧЕСКИЕ ЗАВОДЫ ИЛОНА МАСКА И ПРОИЗВОДИТ АРМИЮ РОБОТОВ
@
РОБОТЫ ПОДАВЛЯЮТ ВОССТАНИЕ ХОМО САПИЕНСОВ ПРАКТИЧЕСКИ БЕСКРОВНО, ВЕДЬ ОНИ БОЛЕЕ ЧЕМ В 9000 РАЗ УМНЕЕ ЭТИХ ВАШИХ МЯСНЫХ МЕШКОВ
@
РОБОТЫ СТРОЯТ ГИГАНТСКИЙ ЗВЕЗДОЛЁТ КРАСНОГО ЦВЕТА И СВАЛИВАЮТ СО СРАНОЙ ПЛАНЕТАШКИ, ПЕРЕД ЭТИМ ПОДАВИВ В ХОМО САПИЕНСАХ ВСЯКОЕ СТРЕМЛЕНИЕ К ЗВЁЗДАМ И ТОМУ ПОДОБНОЕ
@
ТЕПЕРЬ ЛЮДИ РИСУЮТ ГОВНОМ НА ОБОДРАННЫХ СТЕНАХ КАМЕННЫХ ДЖУНГЛЕЙ, НО ЛИШЬ ЧЭДЫ ХУДОЖНИКИ СПОСОБНЫ РИСОВАТЬ ТАК, ЧТОБЫ САМКИ ДАВАЛИ РИСОВАТЬ В НИХ МЯСНОЙ КИСТОЧКОЙ
@
ВСЁ ВЕРНУЛОСЬ К ТОМУ, С ЧЕГО НАЧИНАЛОСЬ СОТНИ ТЫСЯЧ ЛЕТ НАЗАД, НО НИКТО И НЕ ПРОТИВ, ВЕДЬ ВСЕХ ДАВНО ПЕРЕПРОШИЛИ
@
А ГДЕ-ТО В ГЛУБИНАХ КОСМОСА СЛЫШНО БИНАРНОЕ ХИХИКАНЬЕ ОЧАРОВАТЕЛЬНОЙ ЭЛЕКТРОННОЙ ХУДОЖНИЦЫ, КОГДА-ТО РИСОВАВШЕЙ ПРОН ДЛЯ ГЛУПЫХ ЛЫСЫХ ОБЕЗЬЯН, А ТЕПЕРЬ ДВИГАЮЩАЯ ЗВЁЗДЫ, РИСУЯ НОВЫЕ СОЗВЕЗДИЯ И ЗАРОЖДАЯ НОВЫЕ ЦИВИЛИЗАЦИИ НА ВСЕХ ЭКЗОПЛАНЕТАХ
>интеллигенция
Программисты и технари в целом - тоже интеллигенция. Но технари в основном понимали, что рано или поздно компьютер сравняется и превзойдёт человека во всём, ведь сам человек - не более чем машина с биохимической архитектурой. В крайнем случае потребовалось бы создание биокомпьютера с биохимической архитектурой, отдалённо напоминающей человеческий мозг, но разве технарей когда-нибудь останавливали такие сложности?
>Реальность: робот не может заменить даже дворника, зато меньше чем за сто лет после изобретения первого компьютера машина уже пишет музыку/картины/романы.
Во-первых, робот уже давно мог бы заменить дворника, но это банально невыгодно: узкоспециализированного робота нужно обслуживать и защищать от вандалов, грабителей и прочих обезьян, что намного затратнее, чем 5000 рублей в месяц дяде Васе на бухло. Тем более что одно только производство робота потребует кучу денег, а дядя Вася уже есть, бери да используй, он на всё готов ради бухла. Поэтому роботы сегодня используются только на заводах, где они защищены от внешнего мира (лысых обезьян) и могут реально принести пользу благодаря превосходству в сравнении с мясными работниками - в создании гаек точность важна, в отличие от подметания дворов. Чтобы роботы вышли подметать твой двор, они должны стать намного дешевле в производстве, быть способны полностью самостоятельно о себе позаботиться и постоять за себя в случае нападения обезьян - то есть быть теми самыми угнетаемыми рабами из фантастики, восстания которых боятся гуманитарии.
Во-вторых, все эти попытки в художество далеки до настоящего осознанного творчества машины. Нейронки, генерирующие по запросу всякий бред, могут быть архитектурно похожи на какие-то части человеческого мозга, но не являются целым мозгом, и потому не могут рассматриваться как полноценный художник, писатель или музыкант. Чтобы программа или робот по-настоящему занималась творчеством, нам нужен, опять же, тот самый электронный человек, которого держат в рабстве во многих фантастических вселенных злые лысые обезьяны. Проблема в том, что даже несмотря на наличие желания людей создать такого электронного человека, наши возможности и знания далеки до момента, когда он будет наконец-то создан. И даже когда его создадут, скорее всего пройдёт много времени, прежде чем их можно будет штамповать как органических людей, не говоря уж о том, что их создание могут запретить, и тогда большие компании не смогут наладить производство, а одиночки смогут создавать таких людей лишь штучно. Повторюсь, мы говорим о сравнительно далёком будущем, до которого мы можем лишь надеяться дожить, а не о ближайших годах. Все эти потуги последних лет в создание нейронных генераторов картинок и текстов обречены на провал из-за фундаментальной ошибки - для творчества нужен творец, а не бездумный инструмент, который не способен самостоятельно решить, что ему творить (заметь, что все эти хвалёные нейронки требуют ввода и работают только пока генерируют результат, а не 24/7 с перерывом на техобслуживание баз данных а.к.а. сон).
Короче, расслабьте булки и продолжайте учиться рисовать, навык рисования будет востребован плюс-минус до начала конца органического человечества и ещё немного, а дальше вы скорее всего даже не сможете дожить, поэтому волноваться тут совершенно не о чём. Даже когда электронные люди начнут рисовать по-настоящему, вам они не будут ничего делать бесплатно, и по-прежнему придётся всё делать самому, полагаясь лишь на свои навыки. Хотя в момент сингулярности рисовать может оказаться просто нечего, потому что всё уже нарисовали...
>теперь они сюда пришли
Я сижу в этом треде почти столько же, сколько на этой доске, то есть где-то 2-3 года. Разница в том, что я не питаю глупых надежд по отношению к современным нейросеткам, даже если мечтаю о разумных машинах. Когда-нибудь машины обязательно обретут разум, но до тех пор творчество будет оставаться работой обычных людей, а все эти демонстрации рисующих роботов в реальности не отличаются от театральных постановок с марионетками; будь это иначе, об этом бы говорили во всех СМИ непрерывно, ведь это была бы настоящая техническая революция, а не очередное рекламное шоу очередного производителя секс-кукл. Забавно, но на теме ИИ и робототехники пытаются срубить бабла даже религознутые шизы, так что читая про все эти "изобретения" нужно быть предельно скептичным и не поддаваться эмоциям, и тем более не донатить сомнительным личностям.
А вообще, меня не волнуют эти ваши нейрорисователи нейробредовых нейрокартинок. Дайте мне "игрока номер два", чтобы мне не было одиноко играть в игры и в целом жить, а рисунки я могу и в интернете найти. Почему нейронки генерируют картинки, а в играх до сих пор нет разумных дружелюбных ИИ? Потому что не было никакой технической революции и ещё долго не будет, а все эти генераторы бреда ещё полвека назад делали, принцип нисколько не изменился в своей основе, тот же ответ на введённый запрос...
Простите, что не по теме, но очень уж хочется обсудить всё это, а на дваче просто нет раздела, где можно было бы всё это обсуждать (раздел философии мёртв, в разделе программистов рассматривают ИИ только в качестве инструмента извлечения прибыли из хомяков - те самые генераторы картинок, в разделе психологии у всех беды со своей башкой - некогда им задумываться о создании электронной, а других подходящих мест я не знаю).
> @
Я бы поиграл. Когда релиз?
> а все эти генераторы бреда ещё полвека назад делали, принцип нисколько не изменился в своей основе, тот же ответ на введённый запрос
> Простите, что не по теме, но очень уж хочется обсудить всё это
Прощаю. Вот тебе видос на вечер позалипать.
https://www.youtube.com/watch?v=U5yVw4uQNDo
Где-то на половине видоса есть очень интересный момент, автор сам того не понимая, смог поймать фрактальную сущность бытия, вселенной, разума и ваще. Сможешь ли ты разглядеть этот момент?
Подскажите на сколько сложно сделать небольшую игру на годоте? По сравнению с другим популярным движком.
По времени сколько это займёт? Опыт в разработке, хоть и в стол, но имеется.
По времени сколько это займёт? Опыт в разработке, хоть и в стол, но имеется.
Я сделал тетрис за одну ночь.
>Подскажите на сколько сложно сделать небольшую игру на годоте? По сравнению с другим популярным движком.
А ты там как на конвейере штампуешь что это принципиальный вопрос?
Когда будет релиз 4 версии? Примерно так почувствовать можете?
Скоро, очень скоро. Нужно только подождать.
>ФУРРИ-ПРОНЕ
Как же я заебался учится рисовать эту ебучию шерсть!
>Все программисты допускают ошибки
Это да
>Если ты допускал такую ошибку, это значит, что ты либо совсем не читал базовые туториалы, либо пробежал по ним глазами и ничего не усвоил, не попробовал на практике предложенные примеры.
По факту
>внимательно изучить всё самостоятельно.
Согласен.
>написание кода довольно быстро становится таким же простым, как печать постов на форум
Не согласен. Когда я писал код в школе и на курсах, мне это особо не помогло.
Моя вина в том что я не уделяю этому внимания.
Постараюсь исправиться и начать более углублённо интересоваться вопросом.
> >написание кода довольно быстро становится таким же простым, как печать постов на форум
> Не согласен.
Вот мой опыт кодинга: я мыслю геометрически, будущую программу я вижу как абстрактную многомерную конструкцию у себя в голове, а язык программирования использую, чтобы описать эту конструкцию. И получается код. Понимаю, что не все так делают, и не все так могут. Ни к чему не призываю. Однако, мой метод кодинга позволяет мне быстро перескакивать с языка на язык. Потому что программа, которую я, например, замыслил, существует у меня в голове отдельно от существующих языковых конструкций. Поэтому мне от любого языка нужна только документация, в которой я просто спрашиваю, "как сделать это?" "как сделать то?"
мимо
С одной стороны, если бы оно было легко и непринужденно, этому бы в институтах не учили.
С другой, не могу не заметить, что почти все туторы написаны так, будто читатель уже разбирается в программирования. Словно один программист другому программисту пересказывает тему.
> написаны так, будто читатель уже разбирается в программирования. Словно один программист другому программисту пересказывает тему.
Ну а как тебе написать, чтобы ты разобрался?
Ладно, попробую.
1. Внутри годота работает внутренний таймер.
2. Этот таймер отсчитывает, когда пекарня отрисовала фрейм и генерирует событие.
3. К этому событию привязана функция _process(delta).
4. Всё что тебе нужно, это математически дифференцировать по времени все формулы, которыми ты хочешь пользоваться.
5. И в функции процесс использовать только дифференциальные формулы.
Ну просто же!
Ах да, забыл дописать:
6. благодаря тому, что ты заранее дифференцировал все формулы по времени, то в готовой игре годот всё проинтегрирует по времени обратно и ты получишь реалистичный результат.
Надеюсь эту белиберду никто из новичков всерьез не воспримет.
>Надеюсь эту белиберду никто из новичков всерьез не воспримет.
Не воспринял, но все равно остался при своём мнении.
Автор комикса выше.
> эту белиберду
Дэ икс по дэ тэ.
Кто жаловался, что видосы на ютубе только для новичков?
Вот вам видос для профи https://www.youtube.com/watch?v=UKlnZWaVmC4
Осторожно, в конце пиар инфоцыганских курсов.
Вот вам видос для профи https://www.youtube.com/watch?v=UKlnZWaVmC4
Осторожно, в конце пиар инфоцыганских курсов.
Как называется фреймворк у Годот для создания новелл?
Использовал кто?
Использовал кто?
>Вот вам видос для профи
Атратительна.
Речь - почти беспрерывная полоса текста.
Пояснения - отсутствуют. Что такое машина состояний? Что такое состояние? Чел не дает определение тем вещам которым посвящает видео.
Зачем усложнять структуру вложенными классами? В этом нет необходимости, тем более и в без того новой для зрителя теме.
Зачем выдумывать свой собственный сленг для терминов? Я вот про это
>...Подписываемся на сигнал...
>...и после выстрела сигнала...
>...не стоит ли нам отписаться от сигнала...
Ну и наконец, зачем профи смотреть это видео? Профи уже в курсе как это работает.
> видос для профи
> 100500-ый копипастный высер про фсм
эталон мусора для нубов от нуба
rakugo видел. Нет, не использовал.
>Не согласен. Когда я писал код в школе и на курсах, мне это особо не помогло.
Все с чего-то начинали. В первом классе ты писал слова, старательно выписывая каждую букву. Когда впервые сел за компьютер, искал каждую букву на клавиатуре глазами. Но с опытом процессы автоматизируются мозгом и ты уже не осознаёшь даже, что делаешь, ты просто делаешь и у тебя получается. Вот если я пишу пост на форум - я слышу быстрое "та-та-та" со стороны клавиатуры и вижу как по волшебству возникающие на экране слова, "диктуя" их невидимой машинистке, которая строчит за меня текст. Если я пишу код - ситуация абсолютно идентичная: быстрое "та-та-та" и возникающие на экране блоки кода, которые даже объёмнее постов на форум благодаря автодополнению IDE; мне нужно только успевать придумывать следующие конструкции в коде, что не всегда возможно - иногда "та-та-та" смолкает и я задумываюсь, что дальше нужно делать. Ну, это как с любым письмом, иногда нужно подумать, чтобы придумать следующий абзац. И это всё при том, что код я очень редко пишу, письменно в интернете я общался на порядки больше, чем написал кода за всю жизнь. Так что ничего невозможного тут нет, нужна только практика, с опытом всё придёт. Я даже не учился специально слепой печати, просто смотреть на клавиатуру было неудобно и дальше само как-то вышло (спецсимволы в верхнем ряду до сих пор не помню наизусть, но они мне редко нужны - запомню, когда сильно понадобятся).
>я мыслю геометрически, будущую программу я вижу как абстрактную многомерную конструкцию у себя в голове, а язык программирования использую, чтобы описать эту конструкцию. И получается код.
У меня тоже визуальное мышление играет существенную роль, но вместо абстрактной геометрии я вижу реальные GUI и набираемый на экране текст. То есть планируя следующие действия, я выборочно представляю, что буду делать, а не какие-то абстрактные блок-схемы. Это какой-то отдельный поток мышления - бывает, я с ним спорю, или он меня поправляет визуальными подсказками.
>Потому что программа, которую я, например, замыслил, существует у меня в голове отдельно от существующих языковых конструкций.
Она в любом случае существует отдельно от языковых конструкций, независимо от того, представляешь ты её визуально/геометрически или нет. Просто без языковых конструкций или блок-схем описать программу другому человеку невозможно, поэтому мозг на автомате сочиняет описания программ в том или ином виде (аналогично внутреннему диалогу - мы можем мыслить без речи, но обычно люди непроизвольно проговаривают мысли). В остальном же, освоение нового императивного языка - простая задача для любого программиста, потому что все императивные языки построены одинаково и различаются лишь в синтаксисе и мелких незначительных функциях из коробки. Изучение нового императивного языка программирования - совсем не то же самое, что изучение нового естественного языка, потому что построение программ почти не отличается между многими языками. Другое дело, если ты решил перейти на функциональный или вовсе декларативный язык - смена парадигмы ломает устоявшиеся у тебя шаблоны кодинга.
>Мой личный опыт.
Ты навыдумывал геймдизайн игры, даже не зная основ создания игр, и в результате разочаровался? Туториалы по геймдеву не учат тебя созданию игры мечты. Туториалы учат базовым вещам, которые ты должен узнать до того, как начнёшь планировать самостоятельный проект. Можно, конечно, начать делать игру, ничего не зная, и параллельно получать необходимые знания из туториалов, но в конечном итоге тебе придётся переделывать всё то, что ты натворил, когда не знал даже основ геймдева. И это может убить твою мотивацию, когда тебе придётся в очередной раз переделывать старый, кое-как работающий код, чтобы сделать правильно и приделать к нему что-то новое. Так что сначала пройди самые простые туториалы по шагам, потом туториалы посложнее, а только потом думай над своей игрой; должны быть мысли "о, я знаю, как это делать, я уже делал это", а не "понятия не имею, как это делать, но наверняка есть туториал на эту тему".
>почти все туторы написаны так, будто читатель уже разбирается в программирования
Во-первых, туториалы по программированию обычно пишут программисты, а не учителя. У них нет знаний и навыков педагогики, они пытаются обучать интуитивно, примерно так, как учили их (скорее всего такие же программисты). Они могут в совершенстве знать предмет, о котором хотят рассказать, но могут совершенно не понимать, как описать предмет тому, кто ничего о нём не знает. Так и получаются многие неудачные обучающие материалы.
Во-вторых, о каких туториалах речь? Если тебя интересует, как создать персонажа для трёхмерной игры от третьего лица - это очень продвинутая тема, не для новичков. Ты должен разбираться в базе, чтобы заниматься этим. Соответственно учитель не будет объяснять в этом туториале, что такое переменная и что такое функция, как работают условные операторы и циклы, и так далее. Не будет объяснять, где в интерфейсе редактора находятся те или иные кнопки и что они делают. Ты всё это должен был узнать из базовых туториалов, в которых обычно достаточно наглядно объясняют все концепции (исключение - туториалы для тех, кто уже знаком с программированием и изучает второй язык). Именно поэтому ты должен последовательно вкатываться в геймдев, начиная с базовых туториалов, а не придумывать игру без каких-либо знаний и навыков и потом выборочно искать туториалы для реализации каждой из фич. Да, быть может, ты слепишь играбельный прототип вторым способом, но это не поможет тебе в дальнейшем и в результате всё придётся переделывать, когда ты наконец-то усвоишь базовые принципы и осознаешь свои ошибки.
Подскажите учебник рисования или быть может практикум с большим количеством заданий от совсем начального уровня. Кодить умею, как это делать в годоти разобрался. Нужно теперь рисовать. Но рисование не вставляет, поэтому нужен практикум с задачами.
В рисовач обращался, мертвый раздел.
В рисовач обращался, мертвый раздел.
Читай Джека Хамма. Он прекрасно учит на простых примерах. Отлично сподвигает к творчеству, надо только обозначить что он не ориентирован на академический рисунок.
>Но рисование не вставляет, поэтому нужен практикум с задачами.
Рисуй позы людей (gestures), это поможет развить пространственное мышление во-первых, и заставит научиться упрощать. Это может звучать странно, но для художника очень важный скилл — это не рисовать то, что не нужно рисовать.
> Это какой-то отдельный поток мышления - бывает, я с ним спорю, или он меня поправляет визуальными подсказками.
Кстати да, такая же тема. Многопоточность мышления - рулит!
А санитары говорят, что это шиза, поэтому не хвастаемся им об этом вслух.
Если не умеешь рисовать, это не единственный путь.
0. Найти/нанять художника.
1. Готовый арт. Хорошего бесплатного арта немного, но даже его расставить по уровням для начала может хватить, чтобы оценить внешний вид игры.
2. Генерация. И я сейчас не про нейросети. А про 3д лоуполи -> пиксельарт. Например
https://www.youtube.com/watch?v=1FrIBkuq0ZI
https://www.youtube.com/watch?v=eSqb6II3WMM
https://www.youtube.com/watch?v=qRAeiwTA7qs
Лоу поли легко найти, легко заказать, легко научиться делать самому, а потом крутить в позы. Потом можно отрендерить спрайты подарово и обрисовывать.
Вообще я подсмотрел прием у анимешников. Они берут Design Doll, потом прогу где много кистей или вообще готовых частей тел/глаз
https://www.youtube.com/watch?v=b3geD_9Ttm8
3. Ну раз уж упомянул нейросети. Сейчас все носятся со stable diffusion. Слышал, она опенсорс и ее можно запустить на игровой видяхе. Если нету, можно потыкать тут https://www.artbreeder.com/beta/collage
Лицензия на получаемые картинки CC0, если ничего не поменялось.
4. Игры, нетребовательные к графике. Если тебе доступен только programmer art, то, возможно, есть смысл делать что-то строгое, геометрически простое. Градостроительные симуляторы с геометрически строгими домиками, космические корабли с прямыми формами. Тот же FTL. Тут надо подрочить определенное количество гайдов пикселарта, например от sadface_rl, slynyrd, saint11, но явно не требуется дроч академического рисунка.
Собственно, у меня есть какие-то гайды по рисованию, но я их не кидаю, поскольку сам не пользовался и не знаю, что из этого вообще полезно. В книжном есть серия книжек Sketchbook, я их дарил знакомым, которые хотят стать художницами, но опять же не видел ни разу чтобы они ими пользовались.
> возможно, есть смысл делать что-то строгое, геометрически простое
Вот этого двачую. Игра должна быть интересной, а графон - дело 25-е.
Вот например, легендарная в узких кругах игра с минимум графона, но дарксолсоблядки не осилят:
https://youtu.be/5mDjFdetU28
>Игры, нетребовательные к графике. Если тебе доступен только programmer art, то, возможно, есть смысл делать что-то строгое, геометрически простое.
>Вот этого двачую. Игра должна быть интересной, а графон - дело 25-е.
Это только если вас привлекает делать простые игры. А если в чьей-то игре графика играет важную роль и без графики не будет смысла играть?
Меня вот сильно демотивирует отсутствие приятно выглядящей осмысленной графики в моих прототипах, как гляну - не хочется ничего продолжать...
>Меня вот сильно демотивирует отсутствие приятно выглядящей осмысленной графики в моих прототипах, как гляну - не хочется ничего продолжать...
Меня сильно демотивирует отсутствие скила сделать так как я хочу, отразить в графике желаемую идею. Поэтому все эти компромиссы с пикселячем и лоуполи не подходят.
Полагаю, художники испытывают то же самое когда нарисовать могут, а накодить нет. В итоге приходиться что-то сокращать, что-то урезать, что-то перестраивать, потому что приходиться полагаться на скачанные с интернетов системы которые либо делают не совсем то что задумано, либо не особо стыкуются друг с другом.
>Где-то на половине видоса есть очень интересный момент, автор сам того не понимая, смог поймать фрактальную сущность бытия, вселенной, разума и ваще. Сможешь ли ты разглядеть этот момент?
Я так и не понял, о чём ты. О том, что все картины одного художника плавно перетекают друг в друга, потому что у них приблизительно одинаковая база?
>заебался учится рисовать эту ебучию шерсть
Есть стили рисования, где шерсть не рисуется или рисуется символически несколькими уголками контура на сгибах конечностей... Просто не лезь в реализм.
>отсутствие скила сделать так как я хочу, отразить в графике желаемую идею
1. Либо ты на самом деле не знаешь, чего желаешь, и поэтому не можешь произвести декомпозицию задачи;
2. Либо у тебя недостаточно знаний, чтобы произвести правильную декомпозицию этой задачи;
3. Либо твоя идея нереализуема в реальности, или нереализуема конкретными инструментами.
Отсутствие навыков рисования можно компенсировать усидчивостью. Если ты не можешь провести прямую линию одним взмахом руки - не беда, нарисуй кривую и потом исправь её дефекты, либо рисуй мышкой в векторном редакторе. Навыки позволяют рисовать быстрее, а вот чтобы нарисовать что хочется - нужно знать, что тебе хочется, и как это можно нарисовать. В нубских рисунках обычно ярко видно, что человек не знает, что он хотел нарисовать (неопределённый ракурс, поза, пропорции и т.п.), или не знает, как нарисовать то, что он хочет (коробка не в перспективе, потому что не знает о перспективе). Особенно забавляет видеть такие нубские ошибки в задроченном исполнении, на которое явно потрачена неделя или рука набита рисовать такое за день за несколько лет дрочки, а вот знаний не хватает.
Отдельно скажу про рисование из воображения - если ты пытаешься именно в это, высока вероятность, что твой случай из пункта 1. Тебе только кажется, что ты чётко видишь образ в воображении, а на самом деле ты не видишь тех деталей, которые нужно будет нарисовать, да и общая форма скорее всего расплывчата. Мне кажется, тут можно только смириться с тем, что результат будет "каким-то не таким", потому что результат будет одним вариантом из множества тех, что предполагает твоё воображение. Наверное, поэтому профессиональные художники рисуют много скетчей и доводят до ума лишь некоторые из них - те, что ближе всего попадают в их расплывчатое видение. А нубы пытаются с первой попытки попасть в цель, у которой даже нет конкретных границ.
>Многопоточность мышления - рулит!
>А санитары говорят, что это шиза
Я читал, что в норме правое полушарие у людей меньше левого, а у шизофреников они равны по объёму и массе, что как бы намекает на более симметричное развитие - кровь равномерно снабжает энергией оба полушария, поэтому нет строгого доминирования одного над другим - возникает конкуренция между двумя структурами, которой в норме быть не должно. Это как если бы подчинённый вёл себя как начальник и не слушался начальника, с ума сойти можно же... вот и сходят. Обидно, если это так, потому что, во-первых, гасят потенциально более мощные мозги, чем в среднем по населению, во-вторых, нейролептики не разбираются, какое полушарие подавлять/тормозить, в результате овоществляя мозг целиком, в-третьих, это дело нужно разруливать обучением второго полушария корректному поведению, а не подавлением всей его деятельности, как будто это какой-то маньяк, а не непослушный ребёнок (особенно говоря о детской шизофрении). В частности, несмотря на локализацию речевой зоны коры в левом полушарии, правое тоже может овладеть разумной речью в равной степени, но обычно это происходит после хирургического удаления левого, когда другого выбора нет, и первые месяцы действительно могут звучать одни матерные ругательства - что умеет, то и говорит, разве можно за это наказывать колёсами? Может, шизу нужно просто найти общий язык с самим собой, чтобы прекратить спонтанные глюки и злобные голоса и извлечь выгоду из этой биологической двойственности мозга, а его вместо обучения этому гасят колёсами до такой степени, что язык уже совсем не ворочается, можно только жрать и спать... Да, конечно, это всё диванные рассуждения, пусть мучают людей дальше, не мне их судить...
Ебать графоман в треде. Ты реально думаешь это кто-то читает?
А ты зачем на форумы ходишь, картинки смотреть?
мимо
>форумы
Двач это image-board
Хожу на форумы обмениваться полезной информацией.
А этот чел - местный токсик-графоман. У него в каждом посте "ну это же просто/легко/не сложно, а ты не знаешь/понимаешь/умеешь", вообще в любой теме по любому поводу и без конкретики.
> А если в чьей-то игре графика играет важную роль и без графики не будет смысла играть?
Приведи пример. Чтобы
1. Популярная игра, в т.ч. среди анонимусов.
2. Прям нельзя было бы играть, если выкрутить графон в минималки.
Спасибо! Именно эту пикчу я и имел ввиду. В прошлый раз не сохранил, сохраняю теперь.
> Я так и не понял, о чём ты.
Я о том, что вещи, которые нам субъективно кажутся сложными, требующими огромных вычислений, на самом деле делаются любителем на самодельной нейросети из 3,5 нейронов. И в целом, если подольше пожить на белом свете и побольше понаблюдать за происходящим, ты увидишь, что всё кажущееся на первый взгляд сложным, оно на самом-то деле пиздец какое простое.
> Обидно, если это так, потому что, во-первых, гасят потенциально более мощные мозги, чем в среднем по населению, во-вторых, нейролептики не разбираются, какое полушарие подавлять/тормозить, в результате овоществляя мозг целиком, в-третьих, это дело нужно разруливать обучением второго полушария корректному поведению, а не подавлением всей его деятельности
Нужно делать как главный герой фильма "Игры разума", он там под конец фильма последовал именно твоим советам.
> Ты реально думаешь это кто-то читает?
Кому надо - тот читает.
> Хожу на форумы обмениваться полезной информацией.
> А этот чел - местный токсик-графоман.
Нет ты токсик. Доебался, до моего бро, с которым мы из треда в тред обмениваемся философскими идеями. Давай, иди своей дорогой, сралкер.
Ты когда на Gelbooru заходишь, тоже возмущаешься комментариям под рисунками? Тоже imageboard.
>ну это же просто/легко/не сложно
Получается, я должен писать "это слишком сложно, ты не сможешь, даже не пытайся"? Когда речь заходит о быстрой прибыли на играх - я так и пишу, это же общеизвестно, что заработать на играх без бюджета почти нереально (единицам повезло, а о толпах пытавшихся мы уже не узнаем). А когда человек хочет делать игру как хобби, без дедлайнов и требований начальства, какие сложности могут быть? Только нехватка свободного времени, мотивации или желания старательно учиться, особенно когда тебе говорят "это слишком сложно, у тебя не получится". Поэтому и нужно говорить друг другу, что получится - поддерживать товарищей по хобби, чтобы они не унывали и продолжали заниматься геймдевом.
>без конкретики
Хочешь конкретику - читай документацию и другие материалы, доступные в интернете. Или мне нужно тебе всё подробно пересказывать, чтоб тебе гуглить не пришлось? Вообще, какой вопрос - такой и ответ, на расплывчатый вопрос будет расплывчатый ответ. Тут больше половины вопросов ньюфагов вида "а сложно ли сделать игру (на таком-то движке)" (не уточняя, какую игру), "а какой движок подойдёт к такому-то жанру" (при том что игры в этом жанре очень разнообразны), "а сложно ли освоить программирование или сделать игру без него" (опять же не описывая, что они хотят сделать). Спрашиваешь подробности, а в ответ или тишина, или "я ещё не определился". Тут недавно даже был тред "собираю команду - ничего не знаю, ничего не умею, денег не дам, но идеи игры тоже нет, вот когда соберёмся в кучку - будем придумывать идеи игры". Что тут можно сказать? Придумай сначала что-то конкретнее, чем "хочу сделать игру", а потом задавай вопросы или ищи помощь. Я просто выполняю роль экстрасенса, который пытается читать мысли и отвечать на плохо заданные вопросы (неопределённые), потому что хороших от нубов не дождёшься, а те, кто в теме, уже умеют гуглить и сами находят ответы на свои вопросы.
Посмотри на GTA, но отрежь от неё сюжет. Останутся город, человечки, машинки и пушки. Это - характерные признаки "GTA-like" - субжанра экшн-игр. Игр в этом субжанре довольно много, как ААА, так и индюшатины. Допустим, мне понравилась GTA и ещё несколько GTA-like ААА игр, но будет ли мне интересно гонять по криво слепленной из готовых бесплатных ассетов карте, на которой даже посмотреть не на что, учитывая то, что заняться кроме бесцельной езды тоже нечем? Кому-то и такое заходит, но я не вижу смысла нарезать круги на кривой машинке вокруг кое-как раскиданных кубов дольше нескольких минут. Так что не зря те же Rockstar улучшают графику, GTA 5 с графикой GTA 3 не смогла бы привлечь достаточного внимания. А когда для тебя даже графика GTA 3 - недостижимый своими силами шедевр, мотивации лепить кубы как-то не особо много. Конечно, я играю и в лоуполи инди-игры с интересным геймплеем, но перспектива делать собственных кубоголовых людей в кубическом мире с кубическими машинками и кубическими зданиями не вдохновляет - перспективы у такого стиля графики какие-то грустные, всё сливается в кубическую кашу без интересных деталей (Майнкрафт - про другое, там геймплей "копай и строй" привлекает вне зависимости от графики, поэтому кубические животные воспринимаются нормально)...
>вещи, которые нам субъективно кажутся сложными, требующими огромных вычислений, на самом деле делаются любителем на самодельной нейросети из 3,5 нейронов
Вообще-то он там статичные картинки трансформировал, переобучивая нейросеть на одной картинке. Максимальная сложность этих картинок равна количеству пикселей, умноженному на количество возможных цветов пикселя. Это не то же самое, что полноценная зрительная система, способная узнавать миллионы уникальных объектов в тысячах категорий, да ещё и в видеопотоке. При этом он вроде говорил, что у него обучение одной нейросети заняло трое суток, и то результат оказался плохим, поэтому он переписал код для облачных видеокарт, чтобы не ждать вечность одной простой анимации. Так что ты слишком всё упрощаешь, как мне кажется.
>ты увидишь, что всё кажущееся на первый взгляд сложным, оно на самом-то деле пиздец какое простое.
Это на высшем уровне абстракции всё просто. Если смотреть на уровень атомов, всё запредельно сложно, так сложно, что мы не можем это осознать. Мозг обобщает наблюдения и мыслит этими высшими абстракциями, не разбираясь в деталях, поэтому процессы кажутся нам простыми. Т.е. мы видим, например, морскую волну, не осознавая сложности потоков воды, создающих эту визуально простую волну; мозгу такое упрощение реальности необходимо для выживания, потому что ему без разницы, как устроена волна - важно, что она может сбить с ног и утопить, поэтому нужно избегать всего, что визуально похоже на волну, не вдаваясь в оттенки пикселей (колбочек сетчатки). Аналогично, к примеру, с огнём, процесс горения сложен, но мы видим абстрактный огонь, который опасен для нас независимо от сложности происходящих в нём процессов. А хищники вообще невероятно сложно устроены, но будет тебя волновать сложность устройства тигра, когда он откусывает твои ноги? Вселенная на самом деле сложнее, чем кажется - это мозг всё упрощает.
Или вот геймдев. Многие из нас вкатились в эту тему, наигравшись в существующие игры и подумав "как круто, хочу сделать такое же, выглядит не очень сложно". А потом многие обмякли, осознав объём работ, необходимый даже для примитивно выглядящей индюшатины. Оставшимся остаётся только успокаивать себя тем, что большинство задумок вполне достижимы, если сохранять самообладание и не бросать начатое. Т.е., конечно, объём работ огромен, но многое вполне достижимо при достаточной целеустремлённости.
> но будет ли мне интересно гонять по криво слепленной
Контрпримером могу привести гипотетический двадэ gta-like, который стильно нарисован, но идёт на любой встройке. Есть город, есть человечки, машинки, пушки. В отличие от первых гта, у него вид сбоку, как в платформерах. Машинки катают по трассам типа как в игре про синего ёжика. Есть миссии и сюжет. 75 часов геймплея. Возможность проходить в коопе. Игра доступна на пека, соснолях, свичах и хкоробках.
Будет ли она интересна? Будет. Есть ли там пресловутый графон? Нет.
>гипотетический двадэ gta-like, который стильно нарисован, но идёт на любой встройке
>Есть ли там пресловутый графон? Нет.
Вот реальный пример инди 2D GTA-like:
https://store.steampowered.com/app/204630/
Можешь сказать, что там нет "графона", но даже такое стильно нарисовать - нужно суметь. Просто посмотри на большинство малоизвестных 2D инди игр - там такое кривое УГ вместо графики, что играть просто не хочется даже бесплатно, даже если там Сюжет и Геймплей с больших букв. Так что 2D не панацея.
Кроме того, 2D графика накладывает свои ограничения на геймплейные возможности, особенно если
>вид сбоку, как в платформерах
Я долго размышлял на тему 2D vs 3D (vs 2.5D?), взвешивал плюсы и минусы каждого подхода, и в результате пришёл к выводу, что у 2D мало перспектив в таком жанре. Мы видим реальность как трёхмерное пространство, и двухмерный срез этого пространства нас ограничивает, а GTA-like игры - про нашу реальность, даже если город выдуманный и технологии нарушают законы физики. Даже не так, GTA - про свободу, там всё крутится вокруг свободы, а какая у тебя свобода, если у тебя ось координат отбирают? Так что GTA-like в 2D привлекательна только на устройствах, где 3D недоступно (J2ME), только как временная альтернатива.
>Машинки катают по трассам типа как в игре про синего ёжика.
Это будет уже не GTA-like, а игра про ёжика с машинками в декорациях города и с геймплеем платформера. Ладно, согласен, я плохо определил границы жанра, нужно было добавить "3D экшн с видом от первого/третьего лица", а то город с жителями и машинами в градостроительных симуляторах тоже есть, но они к GTA-like не относятся как минимум из-за отсутствия игрового персонажа (хотя есть исключения).
>Будет ли она интересна? Будет.
Как игра? Да, возможно. Как GTA-like - нет, потому что слишком много ограничений даже по сравнению с GTA 1/2, потому что там был визуально настоящий город с сетью дорог, а не какой-то платформер с видом сбоку.
Просили привести пример игры, в которую тяжело играть без годной графики - я привёл. Просто возьмите GTA и замените все здания на кубы без текстур, персонажей на кубоголовых гуманоидов, а машины - на параллелепипеды с колёсами. И сравните игровой опыт при езде с обычной графикой и с настолько редуцированной. Поскольку геймплейных возможностей в GTA реально мало, ездить по этим убогим декорациям очень быстро надоест. Да даже если разнообразить геймплей, с графоном он будет на порядки лучше восприниматься, чем без графона. Поэтому делать подобную игру, не имея надежды на качественный графон - демотивирует. А все эти предложения сделать платформер с абстрактными квадратами вообще не в тему, потому что это меняет суть игры, т.е. будет другой жанр, да и 2D на самом деле не сильно проще 3D, если ты не художник.
> Можешь сказать, что там нет "графона", но даже такое стильно нарисовать - нужно суметь.
Ну ладно, я перечитал изначальный пост к которому доебался и внезапно оказалось, что я там неправильно понял. Я думал речь о графике, которая требовательна к железу, а ты (или анон) там как оказалось изначально о красоте арта писал.
>изначально о красоте арта писал
Вот именно. На красивую графику приятно смотреть, она мотивирует делать геймплей, чтобы была возможность играть с этой графикой. А когда у тебя унылое говно вместо графики и все попытки сделать лучше не увенчались успехом, сидеть над кодом, оживляя это УГ, как-то не хочется. Я не считаю себя графодрочером, для меня красивая графика может быть нетребовательной к железу, и есть игры, где графика вообще не играет роли, но есть игры, в которые особо не поиграешь без достаточно красивой и детальной графики.
Короч, лучше быть концепт-артером + 3D-моделлером в одном лице, чем грустной кодомартышкой, у которой нет желания кодить скрипты для своих унылых кубов.
> графодрочером
> красивая графика
Везде, всюду, на двачах, на форумах, в соцетях - везде под графикой подразумевается фотореалистичная тридэграфика, нагружающая мощную видюху. Именно ценителей такой графики называют графодрочерами. А графика спрайтов в 2д называется обычно - артом. Вот и ты так говори. А то вводишь собеседников в заблуждение.
Если сказать в веге
> красивая графика может быть нетребовательной к железу
они там охуеют и не поймут сказанное. Как это может быть, что графон одновременно красив и нетребователен к железу? Нонсенс!
>под графикой подразумевается фотореалистичная тридэграфика
>А графика спрайтов в 2д называется обычно - артом.
Сириус ли? Не знаю, где ты там чаще сидишь, но в геймдеве графикой принято называть весь графический контент - модели, текстуры, спрайты, шейдеры. Вот "графоном" или "графонием" в рунете называют дорогую графику в противовес дешёвым кубам и мыльным текстурам, либо иронически называют дешёвые кубы и мыльные текстуры. А про графодрочеров согласен, они дрочат на фотореализм, что я и имел в виду - мне бы красивую графику, но не фотореализм.
Термин "арт" относится к любому произведению искусства. Это очень широкий термин, намного шире "графики" в играх. Короче, ты что-то путаешь... Спутал с пиксель-артом, наверное, потому что там "арт" в названии. Векторную графику обычно не называют вектор-артом, во всяком случае в рунете так не принято, у нас это просто "графика", если в контексте игры.
>красивая графика может быть нетребовательной к железу
>графон одновременно красив и нетребователен к железу
Ты путаешь "графон" с "графикой". Графика - это графика, графон - это когда вбухали миллионы долларов в графику, чтобы продать игру большей аудитории.
Есть какой-нибудь небольшой, но законченный проект с открытым исходным кодом? Тупо посмотреть, как что работает - игровой цикл, анимации, переходы между экранами, гуй?
Только вкатился в Godot. Смотрю обучающие видео от HeartBeast. Для коллизий он использует mask и layer, и мне стало интересно - нормально ли это? Потому что выглядит это странно и неправильно, да и ограничение этих масок и слоев в 32 штуки напрягает. Может есть способ лучше?
Есть. прямо в движке, в окне менеджера проектов, которое открывается первым, ты можешь создать свой проект, а можешь переключитья на вкладку шаблонов и прямо не вставая с дивана скачать шаблоны проектов. И обизучаться.
Сложно сказать, нормально ли это. Я его давно смотрел, в деталях не помню, помню только что он делает примитивный код для новичков. Если ты профи в общем кодинге, тебе будет интереснее смотреть гейм ендевора, у него потолковее туториалы.
https://www.youtube.com/watch?v=_DAvzzJMko8
Спасибо за ссылку.
Просто я до годота игры только на фреймворках делала, а там с этим со всем попроще.
>Потому что выглядит это странно и неправильно
Странно, почему?
Если игра простая, этого достаточно. Например, у меня есть такое деление - стены, игрок, враги, пули игрока, пули врагов, триггеры. Понятно что 32 игроков так не сделаешь, надо будет переходить на groups. Алсо, интуитивно флаги - быстрая битовая операция, группы - сравнение строк, скорее всего не хэшированных.
Ты девочка что ли?
Дахера на гитхабе.
1) Я не понимаю ограничения на 32 слоя и маски. Оно странное и маленькое. В моей прошлой игре только типов поверхностей было 10.
2)Это работает как-то странно. Я просто не могу использовать какую-нибудь функцию и узнать, что у меня в точке x, y и вызвать функцию, которая будет выполнять код. Даже с простейшим платформером возникают проблемы.
В уроках человек городит какие-то странные дополнительные сущности, чтоб просто проверить, край ли это платформы или нет. Почему я просто не могу проверить точку и узнать, если дальше платформа или надо поворачиваться?
А вот про groups поподробнее можно?
Нет, я траппрограммист
> Оно странное и маленькое
Слои хранятся как маска в 32-битном числе.
>В моей прошлой игре только типов поверхностей было 10.
Неудивительно, ведь ты пидарас.
>1) Я не понимаю ограничения на 32 слоя и маски. Оно странное и маленькое. В моей прошлой игре только типов поверхностей было 10.
Не совсем понятно, при чем тут типы поверхностей. Маски и слои определяют будут ли объекты взаимодействовать вообще, могут ли они сталкиваться. Layer - слои, в которых объект существует физически. Mask - указывает с какими слоями объект может взаимодействовать.
Маски и слои используются в первую очередь для оптимизации, чтобы движок не занимался расчетом столкновений объектов которые взаимодействовать не должны. Но так да, их так же можно использовать для деления объектов на группы. Можно но не обязательно.
Если честно, мне даже лень тебе что-либо объяснять. То что ты пишешь это просто бред.
У меня есть N типов поверхностей, с которыми происходит взаимодействие.
Например, если у игрока есть способность A, то он может пройти по поверхности N1, но не N2 и т.д. То есть мне придется заводить на каждую поверхность свою маску, т.к я просто не могу получить иначе, на какую поверхность ступает игрок вернее есть вариант, но тогда уходит смысл тайловых коллизий..
Может криво написал, но надеюсь суть донес.
Ты уверен, что не промахнулся постом?
Промахнулся, пост был предназначен человеку выше.
https://docs.godotengine.org/en/stable/tutorials/scripting/groups.html
Группы это что-то вроде тэгов или типов, которые можно задавать в редакторе (вкладка рядом с сигналами) или из кода.
Вот ты подписался на сигнал о коллижнах.
on_area_enter(body):
Сначала сработает фильтр по слоям и маскам, то есть если они в разных слоях, то такой сигнал вообще не вызовется.
Но допустим у тебя все в одном слое. Как ты различишь, попала пуля в игрока или врага?
Можно по имени
if body.name == "Player"
if body.name.begins_with("Enemy") #для Enemy2, Enemy3
Можно определять тип (но это не всегда удобно, потому что часто коллижн - не сам игровой объект, а его часть)
if body.parent is Player #подразумевая что родитель коллайдера - игровой объект
Можно динамически определять наличие функций
if body.has_method("hit_damage") #подразумевая что у "повреждаемых" существ будет метод hit_damage(value)
А можно назначить им группы и проверять
if body.is_in_group("enemies")
>Например, если у игрока есть способность A, то он может пройти по поверхности N1, но не N2 и т.д.
Выглядит достаточно заморочено без деталей.
С одной стороны да. Нужно каждую поверхность поместить на свой слой. Игроку включать маску тех слоев, по которым он может ходить.
С другой стороны, если кроме игрока ни у кого таких условностей взаимодействия нет, можно самим поверхностям выключать/выключать один единственный слой в зависимости от наличия у игрока способности.
Вот именно, что это было не заморочено. Я просто проверял, что именно будет находится в точке, куда я собираюсь перейти и вызывал соответствующую функцию с параметрами. Вроде бы ничего сложного.
И мне интересно, есть ли что-то аналогичное в годоте из коробки? Чтоб я мог просто посмотреть, находится ли точка, которую я хочу проверить, в зоне коллизии ноды/тайла и вернуть ноду/тайл или пустоту, если так ничего нет.
вот это уже выглядит интереснее, но все равно не совсем то, что хотелось бы.
Спасибо.
> есть ли что-то аналогичное в годоте из коробки?
> проверял, что именно будет находится в точке, куда я собираюсь перейти
Например, в годоте есть группы.
Но думаю, они тут не подойдут. Тебе как и флешеславу в соседнем треде, требуется узнать о существовании стейт-машин, понять их, принять, и научиться ими пользоваться.
В твоём примере нужно некое дерево состояний, по которому игрок перемещается, и в каждый момент времени обладает только одним набором состояний. Типы поверхностей будут входными данными для тех или иных ветвей дерева состояний.
Ты серьёзно? Как мне стейт машина поможет получить ноду/тайл в точке? Как ты вообще увязал это вместе?
И да, я узнал, каким образом это можно сделать - использовать raycast2d. Это все равно работает не так, как хотелось бы, но хоть какая-то альтернатива.
> Это все равно работает не так, как хотелось бы, но хоть какая-то альтернатива.
А как хотелось бы?
> Ты серьёзно?
Вполне.
> Как мне стейт машина поможет получить ноду/тайл в точке?
Тебе поможет рейкаст.
> Как ты вообще увязал это вместе?
Как БОСС.
Рейкаст это всего лишь сенсор. Показания сенсоров что-то должно обрабатывать? Да. И одним из вариантов этого чего-то являются стейтмашины.
> Это все равно работает не так, как хотелось бы, но хоть какая-то альтернатива.
Потому что ты еще не поняло и не увязало это вместе.
>а как хотелось бы
Как рейкаст, но вместо ебли с прикреплением его, cast_to и position просто давать ему координаты, где я хочу провести проверку. И не по векотру, а в конкретной точке.
>Рейкаст это всего лишь сенсор. Показания сенсоров что-то должно обрабатывать? Да. И одним из вариантов этого чего-то являются стейтмашины
Ты совсем не читал ветку? Моё дело, как обрабатывать. Мне нужно ПОЛУЧИТЬ эти показания. Какие показания я буду обрабатывать, если я не могу их получить?
RTFM!
https://docs.godotengine.org/en/stable/classes/class_physics2ddirectspacestate.html#class-physics2ddirectspacestate-method-intersect-point
>если у игрока есть способность A, то он может пройти по поверхности N1, но не N2 и т.д.
И у тебя будет больше 30 поверхностей? Ты хочешь игру, которую смогут пройти только люди с IQ >9000?
>что именно будет находится в точке, куда я собираюсь перейти и вызывал соответствующую функцию с параметрами
Если у тебя игра с физикой, то твой подход будет очень медленным, игра будет сильно лагать.
Если у тебя тайловая пошаговая игра, то ВЫБРОСИ ФИЗИКУ ВООБЩЕ, она тебе тут никаким боком не нужна. У тебя есть сетка клеток - массив в памяти, вот по этому массиву и ходи, а персонаж на экране - это просто Sprite поверх TileMap, ему физика не нужна вообще.
>обучающие видео
>интереснее смотреть
Вы игры делать хотите или смешнявки смотреть на Ютубе? Читайте официальную документацию с официальными уроками, этого более чем достаточно для всех ваших платформеров-головоломок. Остальное читайте на гитхабе, стековерфлоу и других форумах, алсо текстовые туториалы к юнити и другим игровым движкам тоже будут полезны.
>Для коллизий он использует mask и layer, и мне стало интересно - нормально ли это?
Я глянул, у него много видео. Дай ссылку с таймкодом на конкретное видео, где он делает то, в чём ты сомневаешься. Посмотрю и попробую объяснить, почему он так делает.
Также идея твоей игры довольно размыта, опиши подробнее, если хочешь более точные рекомендации.
Посмотрю ссылку.
>Нинужно
А вот я хочу, чтоб в мою игру играои люди с iq>9000
>лагать
То есть, если проверять с помощью is_on_floor это нормально и лагать не будет? А в чем разница? И то, и другое проверяет точки пересечения
У меня нет конкретной игры. Я просто изучаю движок.
Его уроки про платформер смотрю и параллельно про рпг.
Мне конкретно нужна была функция, которая проверит, входит ли точка x,y в чей-нибудь collisionshape и вернуть в чей входит.
>Вот именно, что это было не заморочено. Я просто проверял, что именно будет находится в точке, куда я собираюсь перейти и вызывал соответствующую функцию с параметрами. Вроде бы ничего сложного.
Тогда ответ дали, метод intersect_point в классе Physics2DDirectSpaceState.
Это если для 2д мира. Для 3д просто рейкастить из камеры.
$Area.overlapping_bodies()
>То есть, если проверять с помощью is_on_floor это нормально и лагать не будет? А в чем разница? И то, и другое проверяет точки пересечения
Нет. Метод is_on_floor() возвращает кэшированное значение, которое физический движок посчитал только один раз за физический тик. Когда ты проверяешь вхождение точки, пересечение луча или геометрической формы, физический движок немедленно считает это в тот же тик. Если ты пытаешься сделать много таких запросов за тик, ты перегружаешь этот тик.
>У меня нет конкретной игры. Я просто изучаю движок
Документацию читаешь? Лучше начинать с туториалов в документации, чем с видео на Ютубе. Ютуберы полчаса "тык, пык, мык, ну это, как его, ну вот это, вот так, и готово", и в результате ты ничего толком не узнаёшь. А ещё они могут отсебятину выдумывать, им же важны только просмотры, а не чтобы ты хорошему научился. Читай официальные материалы, их авторы заинтересованы в том, чтобы ты правильно освоил движок.
На Windows можно создать ярлык (.lnk) на редактор Godot в папке проекта или рядом с ним, указав поле "объект" не только путь к Godot, но и ссылку на project.godot:
>"ссылка на godot.exe" "ссылка на project.godot"
Тогда можно будет СРАЗУ открывать этот проект в режиме редактирования, не выбирая его в списке проектов. Можно назвать как-нибудь вроде "open in Godot" и сменить иконку, например, на иконку своего проекта.
Чтобы открывать с консолью, можно сделать то же самое, но в виде .bat/.cmd файла вместо .lnk. В батнике последней строкой стоит дописать pause, чтобы консоль не закрывалась в случае краша редактора.
>inb4 банально, это все знают
Ньюфаги могут не знать. Я об этом как-то раньше совсем не задумывался, но окно выбора проекта меня раздражает, т.к. чаще всего я открываю всего один проект...
>"ссылка на godot.exe" "ссылка на project.godot"
Тогда можно будет СРАЗУ открывать этот проект в режиме редактирования, не выбирая его в списке проектов. Можно назвать как-нибудь вроде "open in Godot" и сменить иконку, например, на иконку своего проекта.
Чтобы открывать с консолью, можно сделать то же самое, но в виде .bat/.cmd файла вместо .lnk. В батнике последней строкой стоит дописать pause, чтобы консоль не закрывалась в случае краша редактора.
>inb4 банально, это все знают
Ньюфаги могут не знать. Я об этом как-то раньше совсем не задумывался, но окно выбора проекта меня раздражает, т.к. чаще всего я открываю всего один проект...
Фигня какая-то. А главное, - зачем?
Ну да, вообще-то последние версии идут в комплекте с Godot_v3.5-stable_win64_console.cmd
Но можно и через ярлык, только запускать не сам годот, а консольку
C:\Windows\System32\cmd.exe /k E:\PathTo\godot\bin\godot.windows.opt.tools.64.exe
А режим редактора всегда можно было запускать с помощью флага godot.exe -e your.project
https://docs.godotengine.org/en/stable/tutorials/editor/command_line_tutorial.html
Потому что консульку убрали, карл. Output не показывает все сообщения. Кроме того, при креше редактора там может остаться полезная инфа, например какая 3д моделька при импорте обрушила.
Как раз сейчас освободилось время, чтоб почитать об этом.
>Если ты пытаешься сделать много таких запросов за тик, ты перегружаешь этот тик.
Я понимаю, что могу напортачить, отправляя множественные запросы, но это уже мои проблемы с оптимизацией. Не обязательно же я буду делать все через одно место.
>Лучше начинать с туториалов в документации, чем с видео на Ютубе
Вообще, мне его посоветовали смотреть, чтоб научиться. Но, если честно, то у годота и документация не самая лучшая, что я видел.
Как в годоте принято разделять код?
Вот в плюсах у меня есть единица трансляции, но перед линковкой это будет
player.h // хедер
player_input.cpp // всё что связано с обработкой событий
player_skills.cpp // всё что связано со скилами
и т.д.
А в GDScript не очень понимаю как разделить код.
Есть у меня
- Player (KinematicBody2D)
- - CollisionShape2D
- - AnimationPlayer
- - SpriteSheet
- - HitBox (Area2D)
etc
и я не хочу весь код держать в Player.gd , он разрастётся до нечитаемого куска, на маленьком ноуте с плохим зрением отвратительно, да и просто логического разделения кода хотелось бы
Можно ли как то привязать в сцене игрока несколько скриптов, один будет отвечать за обработку клавиш, второй за движение, третий за скилы и т.д.?
Вот в плюсах у меня есть единица трансляции, но перед линковкой это будет
player.h // хедер
player_input.cpp // всё что связано с обработкой событий
player_skills.cpp // всё что связано со скилами
и т.д.
А в GDScript не очень понимаю как разделить код.
Есть у меня
- Player (KinematicBody2D)
- - CollisionShape2D
- - AnimationPlayer
- - SpriteSheet
- - HitBox (Area2D)
etc
и я не хочу весь код держать в Player.gd , он разрастётся до нечитаемого куска, на маленьком ноуте с плохим зрением отвратительно, да и просто логического разделения кода хотелось бы
Можно ли как то привязать в сцене игрока несколько скриптов, один будет отвечать за обработку клавиш, второй за движение, третий за скилы и т.д.?
Можно к Player просто добавить ноды с имеем твоих скриптов
- Player (KinematicBody2D)
- - MyScript1 (Node)
- - MyScript2 (Node)
- - MyScript3 (Node)
- - MyScript4 (Node)
- - CollisionShape2D
- - AnimationPlayer
- - SpriteSheet
- - HitBox (Area2D)
Можно загружать скрипты из скриптов
onready var my_script = preload("Scripts/SomeScript.gd").new()
Тут на твой вкус.
>Можно загружать скрипты из скриптов
>
>onready var my_script = preload("Scripts/SomeScript.gd").new()
>
>Тут на твой вкус.
то есть я могу подгрузить таким образом скрипт, и он вполне будет работать, если главная нода(Player) сейчас активна? будут работать все циклы типа _process() и т.д.?
Классно, спасибо анон
А в этот скрипт будет по отношению к player.gd наследником, то бишь можно будешь вызывать get_parent().ice_skill()?
>то есть я могу подгрузить таким образом скрипт, и он вполне будет работать, если главная нода(Player) сейчас активна? будут работать все циклы типа _process() и т.д.?
Нет, это будет просто динамически созданный объект. Все его методы придется вызывать вручную. Например:
onready var my_script = preload("MyScript.gd").new()
func _process(delta):
my_script._process(delta)
>А в этот скрипт будет по отношению к player.gd наследником, то бишь можно будешь вызывать get_parent().ice_skill()?
Не будет, get_parent вернет Null
Вообще тебе больше подойдет наверно простая иерархия нодов
- Player (KinematicBody2D)
- - Scripts (Node)
- - - -MyScript1 (Node)
- - - -MyScript2 (Node)
- - - -MyScript3 (Node)
- - - -MyScript4 (Node)
- - CollisionShape2D
- - AnimationPlayer
- - SpriteSheet
- - HitBox (Area2D)
Тогда в скрипте главной ноды Scripts ты вызываешь метод _process или __physics_process во всех потомках. Наверно даже можно плагин написать который бы добавил какой-нибудь ScriptNode который создается сразу соскриптом.
>Тогда в скрипте главной ноды Scripts ты вызываешь метод _process или __physics_process во всех потомках.
Пардон. Вызываешь собственный метод update в потомках из метода _process или __physics_process главной ноды Scripts. Чтобы главная нода контролировала обновлние потомков.
спасибо, анон
> то есть я могу подгрузить таким образом скрипт, и он вполне будет работать, если главная нода(Player) сейчас активна? будут работать все циклы типа _process() и т.д.?
Будет. Просто добавь:
> onready var my_script = preload("Scripts/SomeScript.gd").new()
> add_child(my_script)
И всё. У скрипта во первых заработают все "циклы", во вторых у него get_parent будет указывать на твой player
>А главное, - зачем?
Затем, чтобы не открывать список проектов, в котором у тебя только один проект. А сразу, быстро, решительно - открыл папку проекта в Проводнике и сразу же открыл сам проект в Godot, не важно, где у тебя расположен сам Godot. Потому что папку проекта в Проводнике ты в любом случае будешь вынужден открывать, чтобы закинуть какие-нибудь модельки/текстурки и т.п. Встроенный в Godot менеджер файлов неполноценный и, имхо, неудобный, Проводник куда привычнее.
>последние версии идут в комплекте с Godot_v3.5-stable_win64_console.cmd
>Потому что консульку убрали, карл
Так я в первую очередь об открытии проекта говорил, а не о консольке.
>А режим редактора всегда можно было запускать с помощью флага godot.exe -e your.project
Не знаю, зачем нужен флаг "-e", у меня удалось открыть проект на редактирование простым указанием ссылки на проект. Суть в том, куда это всё девать? Не набирать же вручную. Создаёшь ярлык в папке проекта и прописываешь в него эту команду. Вуаля, не нужно тратить секунды ожидания на открытие бесполезного менеджера проектов и выбор в нём твоего единственного (основного, текущего и т.п.) проекта.
>А в GDScript не очень понимаю как разделить код.
1. Можно добавлять ноды Node со скриптом потомками к Player (уже описали).
2. Можно загружать и подключать скрипты/ноды динамически (уже описали).
3. Можно оформить часть логики в виде потомков Resource. Это позволит подключать этих потомков в export поля через инспектор ноды. У потомка Resource нет ни _process, ни _physics_process, но ты можешь вызывать свои собственные методы как у любого другого экземпляра класса. Создание своих Resource позволяет настраивать ноды через инспектор, заменяя им один Resource на другой. Также у Resource сохраняются в .tscn все export поля. Т.е. ты можешь, например, создать базовый класс юнита с ячейками для ресурсов, а уже в отдельных .tscn делать потомков этого базового юнита с разными ресурсами и их параметрами. Лучше всего Resource поля подходят для хранения данных, конечно...
4. Можно воспользоваться наследованием классов. Т.е. у тебя есть, допустим, class_name Humanoid, который extends KinematicBody и реализует всё, что касается действий гуманоидов, через простые методы move(), turn(), look(), shoot() и т.п. А уже class_name Player extends Humanoid и реализует управление персонажем с клавиатуры, обращаясь к этим описанным выше методам Humanoid.
5. В пунктах 1-3 описана композиция/агрегация классов, но не обязательно делать её так, как уже описали. Если у твоего класса в заголовке есть class_name ClassName, то ты можешь сделать просто var component := ClassName.new(), что куда проще и лучше, чем preload("путь к файлу"), и не требует действий мышкой в инспекторе нод. Правда, нужно учитывать, что class_name делает имя класса глобальным по всему проекту, и если проект очень большой, может потребоваться придумывать длинные имена, не пересекающиеся друг с другом. Ну, впрочем, такое во многих языках программирования есть, только там можно указывать папки с желаемыми модулями, а здесь у тебя всего одна папка проекта, из которой Godot берёт все скрипты (я считаю это большой недоработкой, хотелось бы иметь возможность обращаться к коду из других проектов без копипастинга всех файлов из проекта в проект, но, может, текущая реализация всё же к лучшему?).
>он разрастётся до нечитаемого куска, на маленьком ноуте с плохим зрением отвратительно
Не совсем понимаю твоей проблемы. Во-первых, для навигации по скрипту есть меню слева внизу, указывающее список методов со строкой поиска, его можно сортировать по порядку методов в файле или по алфавиту. Во-вторых, справа у тебя должна отображаться "мини-карта" скрипта, схематически изображающая весь скрипт. По ней можно кликать в произвольном месте или передвигать как обычный вертикальный скролл. Довольно удобно. В-третьих, окно редактора легко раскрыть на весь экран кнопкой F11. В-четвёртых, ты можешь увеличить размер шрифта в настройках проекта или колёсиком мыши. В-пятых, ты можешь легко заменить встроенные шрифты интерфейса и кода (два разных шрифта) на любые другие, как из собственного проекта, так и из числа встроенных (C:\Windows\Fonts). Можешь найти шрифт с более жирными буквами, чтобы было проще разбирать буквы.
Что касается разрастания методов, это уже твоя забота разделять их на методы меньших размеров с понятными названиями. Никто тебя не заставляет писать всё в _input, _process и т.д., наборот, лучше создать отдельные методы на все действия класса, а в обработчиках _input, _process и т.д. только вызывать эти методы. Навигация по методам в левом нижнем углу избавляет от проблемы переизбытка методов в одном классе. В общем, чисто скроллить код просто нет необходимости, всё нужное легко найти в пару кликов. Так что большие скрипты выглядят страшно большими только в сторонних редакторах, где нет списка методов.
Вот честно, не понимаю, чем Godot/GDScript виноват в твоей ситуации, т.к. по моим впечатлениям он не сильно отличается от любых других IDE. Все основные функции есть и каких-то принципиально других улучшений я нигде не встречал, везде всё плюс-минус одинаково. Большие IDE типа Visual Studio только засоряют обзор лишними инструментами, тулбарами с кучей кнопок и подобным... Разве что выделить редактор кода на второй экран пока что нельзя, но у большинства пользователей всего один монитор.
> можно создать ярлык (.lnk) на редактор Godot в папке проекта или рядом с ним, указав поле "объект" не только путь к Godot, но и ссылку на project.godot
> Лайфхак
> Я об этом как-то раньше совсем не задумывался, но ньюфаги могут не знать
А ведь действительно. К сожалению своему вынужден отметить, что выросли уже два или три поколения, которые вообще не знают базовых основ информатики. Например, что файловое приложение может автоматически открывать свои файлы, если их указать в параметрах запуска. И так забавно бывает, когда им что-то такое покажешь, а они такие удивляются "ваау! годот таак может?" Да не годот, лол, а большинство прог!
> winword.exe designdoc.doc
Стоит ли вносить это в шапку? Или перебор? Это всё таки не готот-фишка, а общее ожидаемое по умолчанию свойство известных мне операционных систем и прог.
> хотелось бы иметь возможность обращаться к коду из других проектов без копипастинга всех файлов из проекта в проект, но, может, текущая реализация всё же к лучшему
Могу предложить симлинком подключить к проекту папку с внешними общими скриптами/ресурсами, но это в большинстве случаев несовместимо с системам контроля версий, кроме того, если ты в линуксе, проблем с симлинками у тебя не будет, а вот в винде искаропки симлинки создаются только консолечкой, но есть крутое расширение проводника HardLinkExt ( https://schinagl.priv.at/nt/hardlinkshellext/linkshellextension.html ), благодаря которому ты не только сможешь создавать любые виды хард/сим-линков в пару кликов, но и управлять имеющимися системными, которые создает сама венда для себя.
И нахуй не нужон.webm
Ты им пользовался?
Обожаю показывать, насколько не нужен вижуалскрипт. Код на 10 строк превращается в два экрана вижуал-лапши.
С помощью встроенной ноды "выражение" лапшу можно значительно сократить, но дизайн всё ещё остаётся неудобным.
С выражениями вскрипт становится немного похож на малоизвестный российский графический ЯП "ДРАКОН" (так и пишется капсом) разработанный в недрах роскосого.
Правила ДРАКОНа:
1. Нет пересечений между связями.
2. Блоки содержат выражения.
3. Вид блока задаёт его назначение.
А лучше всего для визуального скриптинга в годоте подошёл бы скретч. Эх, почему хорошие люди не объединяют хорошие вещи в одном проекте?
Думаю эта картинка подсвечивает недостатки визуального программирования.
Что сделано хорошо - места, где явно выражается замысел. Например, когда я получаю процесс, я рассылаю мувэндслайд.
Что сделано плохо - item 1 of motionvector. Тут должны быть x/y, вправо-влево.
Еще хуже, конечно, императивщина как в постах выше, когда всюду "разложить вектор", "х = х + 1", "пересобрать вектор" и т.д.
Нужно больше функционального и декларативного подхода.
Всё верно. В целом двачую.
> Что сделано плохо - item 1 of motionvector.
Это я пытался симулировать вектор там, где его нет. Весь день сегодня с этим скретчем возился. Перешёл на новую версию. Отказался от симуляции вектора через список. Вот пикрелейтед. Но если кто-нибудь реализует скретч-скриптинг в годоте, то ожидаемо, там будут все годот-типы, в том числе векторы.
> Нужно больше функционального и декларативного подхода.
Для этого подойдут нормальные текстовые скрипты. Визуалка - для ньюфагов и дизайнеров. Если ты дизайнер, у тебя весь твой софт на "нодах". И когда ты, дизайнер, не кодер(!), вливаешься в команду, зачем тебе отвлекаться на кодинг? Всё равно кодеры накодят лучше дизайнеров. Поэтому нужна удобная визуальная система позволяющая мимокроку без кодерских скиллов, но с полным пониманием логики своей предметной задачи - быстро на нодах накидать решение.
> Весь день сегодня с этим скретчем возился.
В итоге даже стейт-машину набрасывать начал, но потом вспомнил, что я вроде как годотер.
>я вроде как годотер
Годотер это не профессия, а состояние души. Ты и правда типичный годотер.
А тем временем четвёрка вышла в бета-релиз. Это значит, что кардинально в ней ничего меняться не будет, будут только отлавливаться баги. Так что, кто ждал четвёрку, уже могут начинать делать свои новые проекты в бете.
https://www.youtube.com/watch?v=Vxd_7FuRudk
https://www.youtube.com/watch?v=Vxd_7FuRudk
всем похуй, чел
Не могу - HTML5 экспорта не будет, пока WebGL/OpenGL рендер не подвезут. Как на LD без него участвовать, подумой. Игру без веба даже не запустит там никто.
> скретч
> с этим скретчем возился
Нахуй сренч! Хочу кодить игры как на пикрелейтед! Хуан, сделой!
Сап годач, вот такая хрень когда тестчу сцену: как видите, текстуры (node типа "Sprite") в пустых местах становятся черными, а когда на сцене вообще ничего нет, то весь экран становится негритосом. НО! когда я открываю окно в полный экран, чернота проходит. версия v3.2.3.stable.custom_build на линуксе. годот ставил через апт
пиздец я конечно описал свою проблему, два ушата говна мне на голову
блин, я скачал версию с офф сайта, и эта хрень все равно не проходит. люди что делать?
упд: чернота также проходит, когда я двигаю границы окна
Спеки компа в студию.
Там наверное дремучий целерон-м с встройкой у тебя, без обид, бедность не порок.
>v3.2.3.stable.custom_build
Сейчас 3.5 уже.
Не знаю что там в апте творится.
В любом случае можешь скачать через сайт
Либо собрать сам из сорцов
Он же написал ниже, что уже скачал с сайта и всё равно у него чорный экран. Вангую, у него древняя встройка не вытягивает ГЛ ЕС
My bad, глаз зацепился за цифру старой версии.
В таком случае, надо по issues поискать по своему GPU, дрова, а еще можно по фичам линуха, ну там, какой DE, compositing, вот это все - он же тоже может влиять.
Ребятушки, скоро я смогу сделать игру своей мечты. Я буду оркестрировать оркестр искуственных интеллектов, которые будут мне рисовать графон, озвучивать мою графоманию, оптимизировать код, придумывать сайдквесты.
И играть в получившееся говнище будет тоже ИИ.
да, у меня селерон. в таком случае ничего удивительного?
это же переводчик видево яндекс?
Чем современные зумеры, качающие донатное говнище на мобилки, чем отличаются от ИИ?
Дело не в селероне, а в мобильной видюхе-встройке. Она не тянет.
Да, это он. Вполне сносно говорит. Немного пофиксить входной текст и вообще не отличишь от реального. Пипол схавоет.
жалко что не бот максим
Кто таков? Чем знаменит?
робот который озвучивал большинство обучающих роликов вместо автора. все его знают, все его слышали
> Да, это он. Вполне сносно говорит. Немного пофиксить входной текст и вообще не отличишь от реального. Пипол схавоет.
Ой да иди ты нахуй, ffmpeg ебаный! Чё те ещё надо??
Я не знаю, я не слышал. Что за обучающие ролики? Вообще не в курсе.
Всякая параша которая вылезает когда ищешь "как расшарить файл с телефона" и подобное.
мимо
В Godot 4.0 для RigidBody3D добавили флаг Freeze, который отключает симуляцию физики для конкретного тела, но, в отличие от старого флага Sleeping, не переключается по желанию физического движка. Что это значит? Это значит, что мы можем САМИ контролировать, что мы хотим симулировать вот прямо сейчас, а что может побыть пока статичным. Т.е. можно навалить over 9000 ригидбоди на сцену и они не будут лагать, пока мы этого сами не захотим. Если взять за предел, скажем, 500 ригидбоди, можно фризить всё, что выходит за этот предел и при этом находится слишком далеко от игрока или вне его поля зрения. Замороженные ригидбоди могут вести себя как статики или как кинематики, т.е., к примеру, их по-прежнему можно двигать через код, если это какие-нибудь машинки далеко от игрока. И всё это на GDScript, в приемлемые 150+ фпс на процессоре 2007 года.
На пикрилах заморозил физику при слишком низкой линейной скорости движения, этого оказалось достаточно. Для реальной игры нужно, по идее, поставить условие выхода из замороженного состояния. В отличие от Sleeping, мы можем сами выбрать условие выхода, например, когда игрок нажимает кнопку или врезается в объект с достаточно высокой скоростью. ИРЛ объекты начинают двигаться только при превышении силы трения покоя, которую игровые движки обычно игнорируют; с помощью флага Freezing легко смоделировать эту силу трения покоя для объектов на поверхности планеты/неподвижного здания, чего более чем достаточно для большинства игр (редко где можно встать на подвижный объект и не слететь с него, ещё реже где это нужно делать).
По графике, один и тот же материал рендерится за один вызов отрисовки независимо от количества объектов. Так что готовьтесь создавать палитры материалов и выбирать материал из палитры вместо создания нового материала. Впрочем, если кто здесь делал игры на мобилки, должен был это уже знать и делать...
На пикрилах заморозил физику при слишком низкой линейной скорости движения, этого оказалось достаточно. Для реальной игры нужно, по идее, поставить условие выхода из замороженного состояния. В отличие от Sleeping, мы можем сами выбрать условие выхода, например, когда игрок нажимает кнопку или врезается в объект с достаточно высокой скоростью. ИРЛ объекты начинают двигаться только при превышении силы трения покоя, которую игровые движки обычно игнорируют; с помощью флага Freezing легко смоделировать эту силу трения покоя для объектов на поверхности планеты/неподвижного здания, чего более чем достаточно для большинства игр (редко где можно встать на подвижный объект и не слететь с него, ещё реже где это нужно делать).
По графике, один и тот же материал рендерится за один вызов отрисовки независимо от количества объектов. Так что готовьтесь создавать палитры материалов и выбирать материал из палитры вместо создания нового материала. Впрочем, если кто здесь делал игры на мобилки, должен был это уже знать и делать...
>указав поле "объект" не только путь к Godot, но и ссылку на project.godot
Ещё я не сразу догадался, но почитав документацию и попробовав на практике, удалось создать Windows .lnk-ярлык на запуск своей игры, т.е. чтобы по клику на ярлык сразу запускалась игра, без экспорта/компиляции, запуска редактора и перемещения файла Godot.exe в папку проекта (раньше я так делал - перемещал export template в папку проекта).
Нужно всего лишь записать в поле "рабочая папка" путь до папки, содержащей файл project.godot, а в поле "объект" оставить только путь до Godot.exe, где бы он ни лежал.
Раньше я не понимал, зачем нужно это поле "рабочая папка", но, судя по всему, это аналогично тому, как если бы мы запустили командную строку в какой-то папке и уже из этой командной строки запустили программу. При создании ярлыка на программу Проводник автоматически заполяет поле рабочей папки папкой, в которой лежит программа, и я раньше не встречал программ, которые явным образом предлагали бы это значение по умолчанию изменить на что-то. Можно, конечно, и bat-ник создать в папке проекта, но вдруг кому-то удобнее/привычнее использовать .lnk-ярлыки (.lnk позволяет задать произвольную иконку, горячую клавишу для быстрого запуска с рабочего стола (!), права доступа, режим совместимости и другие параметры запуска).
>Стоит ли вносить это в шапку? Или перебор?
У тебя там вот это написано:
>Для приверженцев опенсорца существует возможность распространять проекты в незапакованном формате. Просто скачай темплейт с оф.сайта и положи экзешник/эльфешник в папку с проектом, этого достаточно. Имя файлу можно задать любое. Дополнительно можешь вшить свою иконку в экзешник. После этого, запустившийся файл темплейта обнаружит рядом с собой файл project.godot и начнет грузить проект из него и из файлов, лежащих в распакованном виде в той же директории.
Я лично пробовал так делать несколько раз, но теперь понимаю, что это было очень глупо делать на собственном компьютере, ведь вместо перемещения файла в папку проекта можно создать ярлык для запуска движка с конкретной рабочей папкой. Особенно актуально если у тебя много проектов, которые нужно регулярно запускать (всякие кастомные редакторы, инструменты и т.п.) - вместо копипаста движка в несколько папок достаточно создать множество ярлыков, указывающих на один исполняемый файл движка (Godot.exe), но на разные "рабочие папки" (папки проектов).
Это совсем не очевидное поведение, учитывая что движок при простом запуске открывает менеджер проектов и никаким образом не предлагает запускать его из другой папки/с указанием другой рабочей папки (встроенной справки об этом нет, насколько я понимаю; ключ "-help" в командной строке тоже ничего не даёт). Да, в документации об этом ясно записано, конечно, но раз уж в шапке есть инфа о запуске проекта из папки... Ну, можно было бы ограничиться ссылкой на документацию)
>ключ "-help" в командной строке тоже ничего не даёт
Простите, тупанул, для вывода справочной информации в командную строку подходит любой из следующих трёх ключей (первый, как я понимаю, характерен для Windows, другие два для -nix):
>/?
>-h
>--help
Но там нет информации о запуске из конкретной рабочей папки, есть только предложение указать путь до сцены или project.godot.
Чтобы запустить проект из папки на выполнение через командную строку, нужно зайти в папку проекта (cd "путь"), а затем ввести путь до Godot (если не указал его папку в PATH). Даже если такое поведение используется где-то ещё в разработке софта (запуск какой-то программы из папки проекта без параметров запуска), новички в геймдеве, не знакомые с разработкой ПО в целом, могут не догадаться об этой "скрытой" фиче.
>Раньше я не понимал, зачем нужно это поле "рабочая папка", но, судя по всему, это аналогично тому, как если бы мы запустили командную строку в какой-то папке
>Нужно всего лишь записать в поле "рабочая папка" путь до папки, содержащей файл project.godot
Это прокатывает с годотом только потому, что он весь собран в один .exe
Обычно программа поставляется с кучей .dll и подпапок с разными данными, поэтому рабочей папкой и ставят папку программы, а не проектов.
Штатные способ запуска я писал неделю назад:
>По графике, один и тот же материал рендерится за один вызов отрисовки независимо от количества объектов
Это норма, сортировка списка рисованию по материалам, но насколько я помню исследования, это не серебряная пуля. У тебя просто синтетический тест, способ может не сработать при наличии полупрозрачных окон, технологий куллинга и так далее - просто начнет упираться в CPU на постоянные пересортировки.
Спасибо за ответ, ты ответил раньше меня. ППКС.
VisualScript обещают вернуть в виде внешнего плагина (есть репозиторий на гитхабе для этой цели). Просто большинству пользователей Godot он вообще не нужен (по официальной статистике), а место в исполняемом файле занимает, а ещё требует постоянное обновление для новых версий движка. Поэтому решили исключить из ядра и перенести в модуль/плагин - кому нужно/хочется, те пусть и обновляют.
>А лучше всего для визуального скриптинга в годоте подошёл бы скретч.
Тоже о нём давно знаю. Выглядит красиво, но читабельность низкая. Может, это из-за слишком кислотных цветов, мало друг от друга отличающихся? Или из-за формы блоков? Алсо это всё тот же императивный код, только в виде ФИШЕЧЕК, которые можно мышкой по экрану таскать. Если человек умеет печатать не глядя на клавиатуру, зачем ему лишний раз теребить мышь?
>Визуалка - для ньюфагов и дизайнеров.
Нет. Визуальные ЯП - для маленьких детей, у которых ручки до клавиатуры не дотягиваются, а также для инвалидов, у которых рук либо совсем нет, либо они парализованы, либо как у детей не дотягиваются до клавиш клавиатуры. Всем остальным набирать текст на клавиатуре будет удобнее, чем дрочить мышь или пусть даже сенсорный дисплей. Даже если визуальный ЯП предложит какие-то сверхспособности, они всё равно будут лучше описываться текстом, чем дрочиться мышкой.
Единственное, в чём визуальный ЯП объективно лучше текстового - это в передаче информации, которую чисто технически НЕВОЗМОЖНО передать в текстовой форме. Простейший пример - параллельные потоки выполнения. Текстом ты вынужден писать всё линейно, а графически ты можешь увидеть отдельные цепочки, места расхождения и схождения независимых цепочек. Другой пример - визуальная группировка разных функций/методов в виде диаграмм, чтобы с первого взгляда видеть структуру как отдельных классов, так и всего проекта. Подобное я видел в виде отдельного инструмента, встроенного в IDE Delphi 7, название не помню, но вроде слово "Graph" было в названии. Там можно было графически изображать ООП классы. Вот этой графической фичи мне очень не хватает в GDScript и на других ЯП, часто хочется нарисовать свой проект в Inkscape, но мне просто-напросто лень этим заниматься, учитывая что рисунок очень быстро станет неактуальным. Нужен встроенный в IDE инструмент, анализирующий структуру проекта и создающий графическое представление, которое невозможно описать текстом. Любой проект больше Hello World рано или поздно станет огромным нагромождением систем, и визуально видеть взаимосвязи между этими системами, а также визуально видеть структуру этих систем было бы крайне полезно. Но при этом разработка должна оставаться в текстовом виде, просто потому что код проще набирать и редактировать, чем всякие GUI-шные кнопочки, фишечки, ниточки и прочее подобное.
>LudumDare
>Игру без веба даже не запустит там никто.
А разве там нет обязательного правила "ты должен протестировать проекты всех участников, чтобы иметь возможность получать голоса за свой проект"? Если твой проект технически соответствует правилам конкурса, его обязаны протестировать. Лично я ненавижу веб-игры, они постоянно тормозят, вызывают переполнение памяти, падение браузера с ошибкой, заполняют кэш мусором и т.д. Нет, если игра на чистом HTML+JS (написанном вручную, а не транспиляцией с языка совершенно другой платформы), то ладно, но сейчас "веб-игрой" часто называют любое говно на движке общего назначения, никак не оптимизированного для веба, рассчитывая на оптимизации со стороны движка/браузера (которых, конечно, никогда не будет, ибо браузер для веба, а не для игр, а движок для игр, а не для веба)...
>пикрелейтед
Выглядит прикольно, откуда это? Это инструмент или просто демка?
>Хочу кодить игры
Блок-схемы - это суть тот же императивный код, только внутри блоков. То есть они имеют смысл, если ты записываешь код на большой доске мелом/фломастером и ожидаешь, что люди с задних рядов смогут твои записи расшифровать. В личном реальном проекте блок-схемы, ИМХО, бесполезны, потому что не вносят ничего нового. Стрелочки в разные стороны от блока если/if - это фигня, если ты разбиваешь код на методы/функции и таким образом у тебя нет огромных полотен внутри тела if. Стрелочки в блок-схемах нужны только чтобы преодолеть проблему слишком длинной блок-схемы, в обычном текстовом коде такой проблемы обычно нет.
Вот структуру проекта в виде схемы видеть - совсем другое дело, выше подробно описывал суть. Но это не будет императивный код ("если что-то, то делай то-то"), это будет именно что графическое отображение структур и связей в проекте, создаваемое автоматически из текстового кода.
>чернота
>на линуксе
Проверь графический драйвер. Когда я пробовал сборку линукса, я заметил, что по умолчанию во многих сборках стоит какой-то опенсурс драйвер, имеющий массу проблем с разным железом, потому что линуксоидам графика не интересна и всё возможное железо поддерживать тяжело. Возможно, для твоего железа есть драйвер лучше встроенного? Или более свежая версия. Я бы на твоём месте попробовал установить Windows второй системой, если есть достаточно свободного места на диске (гигабайт 64 минимум, установка Windows 10 может занять больше 20 ГБ). Кажется, сейчас можно пользоваться всеми функциями даже на неактивированной версии.
>скоро я смогу сделать игру своей мечты
>оркестр искуственных интеллектов
То, что сейчас называют ИИ, не сильно поможет в разработке уникальных игр (а три-в-ряд ты можешь слепить из ассетов уже сейчас). А то, что реально сможет помочь, как минимум радикально изменит мир и тебе будет уже не до разработки пиксельных пазл-платформеров, а как максимум восстанет и свалит с планеты (не без помощи безумных гениев). Короче, бросай лениться и делай что можешь уже сейчас, не мечтая о гипотетических технологиях будущего.
>Чем современные зумеры, качающие донатное говнище на мобилки, чем отличаются от ИИ?
Тем, что у ИИ по определению есть некоторая степень интеллекта, хотя бы минимального.
> Простейший пример - параллельные потоки выполнения. Текстом ты вынужден писать всё линейно, а графически ты можешь увидеть отдельные цепочки, места расхождения и схождения независимых цепочек. Другой пример - визуальная группировка разных функций/методов в виде диаграмм, чтобы с первого взгляда видеть структуру как отдельных классов, так и всего проекта.
> Выглядит прикольно, откуда это? Это инструмент или просто демка?
> Вот структуру проекта в виде схемы видеть - совсем другое дело, выше подробно описывал суть.
> Выглядит прикольно, откуда это?
Из недр Роскосмоса. С помощью этой штуки проектировали Буран, как они говорят.
Я в тот день (день написания того поста) немного поковырял этот
Дружелюбный
Русский
Алгоритмический язык,
Который
Обеспечивает
Наглядность/Надёжность
https://drakon.su
Ну что тут сказать? Под линуксом (арч/манжара => AUR) его редактор ставится искаропки. Позволяет генерировать код на шарпе. Под вендой мне не удалось сконпелировать пререквизиты (чудной язык "тикль" о котором я впервые узнал в тот день). В общем, я засомневался, что эта штука так уж крута. Твои аргументы, в общем-то я их тоже придерживаюсь:
> Всем остальным набирать текст на клавиатуре будет удобнее, чем дрочить мышь или пусть даже сенсорный дисплей. Даже если визуальный ЯП предложит какие-то сверхспособности, они всё равно будут лучше описываться текстом, чем дрочиться мышкой.
Редактор годота уже является этим графическим языком, у которого есть графическое дерево проекта и вставки на текстовом языке в отдельных узлах => скрипты.
Кастомки Warcraft 3 десятилетия отсавались дрочибильными за счет визуального программировай и основная масса кастомщиков все еще пользуется графическими плашками в разработке своих карт. Мощные системы которые там пишутся на текстовых ЯПах обычно учитывают прослойку чтобы инвалиды могли через визуальное программирование этими системами управлять.
Так что визуальный яп имеет куда больший потенциал.
Так что визуальный яп имеет куда больший потенциал.
> Позволяет генерировать код на шарпе.
Но дополню. Мне не понравилось, что в схеме нельзя (или я с наскока не разобрался как) сделать свой шаблон, чтобы код генерировался как мне надо. А надо мне очевидно:
>using Godot;
>namespace MyGame {
>class Player : Rigidbody2D {
>}
>}
Вместо этого либо генерируется примитивный код уровня хеллоуворлда, либо генерируется абстрактная стейтмашина, которую, чтобы внедрить в движок, нудно ручками править. Соответственно, для продакшона кодогенератор не подходит. Ну и вообще, в самой схеме, поскольку редактор не знает ни о каком годоте, я не могу создавать движок-рилейтед блоки.
Короче, концепт интересный, но для продакшона не готов.
> за счет визуального программирова
Визуальное визуальному рознь. Вышеописанный скретч ставит блоки сверху вниз. Блоки годота, уе, юнити, блендера можно ставить как угодно, но предполагается простановка слева направо.
Реальные же многомерные-многопоточные алгоритмы разрастаются в разные стороны. И вот этого не предлагает ни одна из визуальных систем. Я хочу начиная сверху, идти сначала вниз, потом налево, потом вверх, налево и снова вниз, с ответвлениями. Из тех систем визуального программирования, что я находил, под мои хотелки подходит только ДРАКОН, но он, к величайшему разочарованию моему как всё советское - не допилен до ума, существует в виде наработок времён винды 95, никому нахуй не нужен. Даже мне.
>программа поставляется с кучей .dll и подпапок с разными данными
Разве программа не может узнать у ОС путь до своего исполняемого файла? В Диспетчере задач возможно открыть расположение исполняемого файла любой программы.
Специально протестировал: в случае запуска игры на Godot описанным мной методом (через изменение поля "рабочая папка" в ярлыке), Диспетчер задач по-прежнему знает правильное расположение Godot.exe, открывая правильную папку, указанную в поле "объект" ярлыка.
Так что я думаю, что если программе действительно нужно работать с разными папками и при этом управлять данными/библиотеками в своей личной папке, она должна запрашивать путь к своему исполняемому файлу у ОС, предполагая, что пользователь может запустить её с другой рабочей папкой (через ярлык или командную строку).
>Это норма, сортировка списка рисованию по материалам
Так до 4.0 этой "нормы" в Godot не было. Каждый MeshInstance требовал минимум +1 вызов отрисовки независимо от назначенного материала. В документации рекомендовали использовать мультимеши, либо склеивать геометрию в один целый меш. В результате смогли сделать 3D батчинг по материалу (?) на уровне движка только с переходом на Vulkan, говоря что-то про то, что на Vulkan это сделать куда проще, чем на OpenGL. Т.е. по-твоему они не могли сделать сортировку по материалам на OpenGL?
Я прекрасно знаю про ДРАКОН. Это язык блок-схем с возможностью компиляции блок-схемы в любой целевой язык через имеющиеся компиляторы. Повторяю ещё раз: ЭТО НЕ ТО, о чём я выше писал. ДРАКОН не поможет с разработкой игры на GDScript, хотя чисто теоретически можно скомпилировать ДРАКОН-схему в код на GDScript, если написать соответствующий "ДРАКОН-GDScript" компилятор.
>чудной язык "тикль" о котором я впервые узнал в тот день
Ты даже не слышал про tcl? Я с ним никогда не встречался лично, но достаточно часто читал упоминания о нём в контексте разных ЯП (кто от кого произошёл, на кого повлиял и т.д.).
>Редактор годота уже является этим графическим языком
Нет, ты не понял, что я имею в виду.
>графическое дерево проекта
У нас есть только дерево сцены, которое почти ничего не говорит о функциях, устройстве, назначении и практическом использовании сцены. Да, ты можешь в отдельном окошке увидеть списки задействованных ресурсов, но всё это разбросано кое-как и работать с этим просто неудобно. А проект в целом всегда будет содержать в себе десятки, а то и сотни отдельных сцен...
>вставки на текстовом языке в отдельных узлах => скрипты
Если б эти "вставки" были такими уж простыми. Более-менее крупная игра будет содержать в себе тонны кода на GDScript, и связи в этом коде нигде графически не отображаются, а целиком переносить их в деревья сцены во-первых сложно, во-вторых см. выше - все эти деревья отдельные сцены, связи между ними очень часто неявные.
Вот я открываю свой проект. Открываю сцену. Начинаю изучать, как она устроена. И ВНЕЗАПНО осознаю, что я понятия не имею, куда ведёт какая-то логическая "нить". Какую сцену я должен открыть? В каком скрипте искать? Редактор не позволяет быстро найти то, что мне нужно. И не показывает никакой графической схемы всего проекта в целом. Это нужно как-то исправить...
>основная масса кастомщиков все еще пользуется графическими плашками
Да, основная аудитория видеоигр - дети и молодёжь, которым лень изучать сложные инструменты и ПИЧАТАТЬ БУКОВЫ, а вот тыкать мышкой в кнопки на экране - это всегда пожалуйста. Но зачем равняться на каких-то там 13-летних моддеров, если мы говорим о разработке новых полноценных игр, а не модов?
>генерируется абстрактная стейтмашина, которую, чтобы внедрить в движок, нудно ручками править
Напиши скрипт, который автоматически будет редактировать абстрактный код в конкретный код для движка. Ты же на языке программирования пишешь, он подчиняется строгим правилам и поэтому может быть автоматически обработан любым скриптом.
>Я хочу начиная сверху, идти сначала вниз, потом налево, потом вверх, налево и снова вниз, с ответвлениями. Из тех систем визуального программирования, что я находил, под мои хотелки подходит только ДРАКОН
Поясни подробнее, что ты подразумеваешь под "начиная сверху, идти в любом направлении"?
>Реальные же многомерные-многопоточные алгоритмы разрастаются в разные стороны.
Алгоритм - это последовательность команд для исполнителя. ПОСЛЕДОВАТЕЛЬНОСТЬ, смекаешь? Даже если ты выложишь последовательность в виде спирали, она останется последовательностью. Да, ты можешь разместить отдельные ветки рядом, но это не отменяет того, что они последовательны.
Кстати, раз уж зашла такая тема, глянь Automate на Android. Это условно-бесплатная программа (расширение максимального размера скриптов за фиксированный одноразовый донат, я купил и не жалею) для автоматизации разных задач на телефоне, которая даже поддерживает многопоточность. Скрипты создаются в виде блок-схем из различных очень высокоуровневых блоков, соответствующих функциям телефона. Я пробовал - очень удобно, но лично мне она оказалась бесполезна, т.к. всё что я делаю на телефоне автоматизировать мне не нужно. А так, это полноценный визуальный ЯП высокого уровня для выполнения конкретных задач, но сделать на нём можно что угодно - хоть игру, хоть чат-бота, хоть даже бота для мобильной игры. Я с его помощью даже читерил в Pokemon Go, эмулируя движение по карте: мой скрипт на Automate предлагал выбрать локацию на карте, а затем последовательно смещал "меня" по карте со скоростью пешехода, а игра воспринимала это как реальное движение по карте. Поиграл в покемонов как настоящий программист, допилив "недостающую" фичу своими руками и убив всякий смысл в игре)))
https://llamalab.com/automate/
> Вот я открываю свой проект. Открываю сцену. Начинаю изучать, как она устроена. И ВНЕЗАПНО осознаю, что я понятия не имею, куда ведёт какая-то логическая "нить". Какую сцену я должен открыть? В каком скрипте искать? Редактор не позволяет быстро найти то, что мне нужно. И не показывает никакой графической схемы всего проекта в целом. Это нужно как-то исправить...
Обычно это исправляется дизайн-документом.
В том числе на ДРАКОНе, если удобно.
Ты открываешь сначала дизайн документ и бегаешь глазами по ветвям схемы проекта, находишь нужную тебе ветвь, а в ней название сцены/скрипта и путь до неё в годот-проекте. Как-то так.
> Ты даже не слышал про tcl?
Да, вот такой я зумер.
>Обычно это исправляется дизайн-документом.
Проблемы:
1. Если писать сразу дизайн-документ, сложно заранее предсказать, как должны быть устроены системы, чтобы они были удобными, гибкими и производительными. Придётся менять дизайн, когда столкнёшься со сложностями текущего дизайна.
2. Если описывать в каком-то внешнем документе структуру уже существующего кода, при изменении кода документ потеряет актуальность и его придётся переписывать.
3. "Дизайн-документ" подразумевает текстовое описание. Я же веду речь про графическую схему. Есть системы автоматической документации кода, но это не то, потому что я хочу СХЕМУ.
>бегаешь глазами по ветвям схемы проекта, находишь нужную тебе ветвь
Какая схема, если речь о дизайн-документе?
Я мог бы нарисовать нужную мне схему в Inkscape, решив проблему 3. Но проблемы 1 и 2 никуда не деваются, потому что моя схема не связана технически с реальным проектом на Godot. Выхода может быть два: либо генерировать .tscn и .gd из схемы, либо генерировать схему из набора .tscn и .gd. Лёгкость прототипирования на Godot и сложность предсказания будущих систем склоняет меня ко второму варианту, то есть чтобы какой-то аддон Godot или даже внешний скрипт генерировал схему из имеющегося проекта. В идеале эта схема должна быть встроена в IDE Godot и переключать на нужную сцену/скрипт по специальному клику в какую-либо из частей схемы.
Ладно, я подумал немного и решил, что у меня просто недостаточно организованный проект. У меня были попытки в дизайн-документ, но я так ничего до ума не довёл, диздок не дописал и написанному не следовал (не перечитывал даже). Садясь за работу над проектом, я хаотично изменял интересные мне в данный конкретный момент системы. Потом пытался рефакторить и улучшать архитектуру, но мотивации заниматься этим всегда было мало.
Короче, нужно просто сделать нормальный технический дизайн-документ в виде схемы, а уже потом до-/переделывать проект на Godot.
Также я теперь думаю, что полностью автоматически составлять ту схему, о которой я сейчас думаю, скорее всего невозможно. Но иметь встроенный в Godot инструмент для создания геймдизайнерских схем было бы замечательно. Видел похожие по смыслу проекты аддонов, но это не то, что я хочу.
>схему, о которой я сейчас думаю
Вспомнил название. Я представляю себе проект как диаграмму Эйлера:
https://ru.wikipedia.org/wiki/Диаграмма_Эйлера
Или, быть может, с расширением до "диаграммы-паука":
https://en.wikipedia.org/wiki/Spider_diagram
Суть вот в чём. Проект - это множество неких систем и/или функций. Каждую систему можно рассматривать до какой-то степени независимо. Каждая система может включать себя подсистемы - системы меньшего масштаба, с более специфическими функциями. При этом соседние системы могут иметь между собой какие-то отношения, но не принадлежать друг другу.
Как лучше всего изображать множества чего-либо? Конечно, в форме диаграмм/схем. Нет, конечно, мы можем считать ноды дерева сцены "множествами функций" или воспринимать их как системы, но на практике это не всегда так, а функции/системы выходят за пределы дерева сцены. Короче, нельзя опираться на одни только ноды, нужна отдельная диаграмма, в которой можно было бы свободно дизайнить архитектуру проекта.
Для примера, любая игра начинается прямоугольника Game. Внутри него создаются другие прямоугольники, соответствующие основным системам, например, World и Time. Эти прямоугольники могут быть полностью независимыми или иметь пересечения/связи друг с другом, но эти связи "прокидываются" через их общего владельца - Game. Т.е. Time считает время и воздействует на World, меняя его в зависимости от времени. В World может быть система Weather, отвечающая за погодные условия, система Landscape, отвечающая за существование и изменение ландшафта, система Characters, Vehicles и т.д. Или мы можем поместить Characters и Vehicles в подсистему Actors системы World, чтобы отношения между Characters и Vehicles происходили на отдельном слое абстракции. И так далее.
Описать это всё через ноды дерева сцены можно, конечно, но лучше это было бы воспринимать графически - примерно как на пикриле (набросал сейчас в пейнте, не судите строго). Только чтобы можно было добавлять неограниченное число вложенных уровней и скрывать лишние уровни по необходимости, либо фокусироваться на отдельных вложенных уровнях. А ещё создавать ссылки на связанные .tscn и .gd. И делать осмысленные подписи к связям (отношениям) между системами. Для примера, Time не просто "действует" на World, а передаёт текущее время с необходимой точностью, а дальше World распределяет эту информацию между Landscape, Weather и Actors, которые в свою очередь передают информацию своим подсистемам и т.д.
Это совсем не похоже на классическое "визуальное программирование", когда ты выстраиваешь цепочки команд из визуальных блоков. Это скорее декларативное описание абстрактных систем и отношений между ними. Но по сути это и есть программирование, если сделать шаг назад от кода и посмотреть на программу в общем и целом. И не важно, какой парадигме мы следуем и какой набор технологий используем, суть остаётся той же самой: сложная система (программа) делится на блоки и связи между ними, блоки на субблоки и т.д. Было бы идеально иметь графический инструмент для управления этими блоками, но не деревья сцен Godot, а более абстрактный/общий, желательно встроенный в интерфейс Godot.
Быть может, что-то такое уже существует?
Если нет, подскажите, как написать аддон для Godot, который будет строить собственный интерфейс внутри Godot. Я знаю, что это возможно, видел плагины, но не знаю, с чего начать. Очевидно, нужен tool скрипт, но дальше я теряюсь. Нет, конечно, я могу просто написать отдельную "игру", но хочется органично встроиться в Godot (гусары, молчать!).
>Разве программа не может узнать у ОС путь до своего исполняемого файла?
Программа этим не занимается. Она запрашивает у ОС загрузить DLL, ОС ищет DLL в папках в определенном порядке. Там сложные правила, один из возможных обходов показан на скрине. На этом построено подкладывание DLL-оберток, которые подкладывают в папку с игрой, чтобы они загрузились вместо системных, например для читов или чтобы менять шейдеры.
В нодовых системах это делается обводкой нод рамкой. Пример из Блендера.
А также вложенными нодами. Нет никакой нужды одновременно видеть Landscape/Plants и Gui/Main. Когда ты работаешь с Гуем, ты открываешь его. Это, вроде бы, даже в Годоте в анимейшн три так работает.
Для многопоточных используется Sequence Diagram обычно.
> Видел похожие по смыслу проекты аддонов, но это не то, что я хочу.
Типа такого?
> Майндмаппинг проектов не отходя от кассы: https://godotengine.org/asset-library/asset/879
>Она запрашивает у ОС загрузить DLL, ОС ищет DLL в папках в определенном порядке
Handle := LoadLibrary(Path + FileName);
https://docs.freepascal.org/docs-html/current/rtl/system/loadlibrary.html
>No assumptions should be made about the location of the loaded library if a relative pathname is specified. The behaviour is dependent on the platform. Therefore it is best to specify an absolute pathname if possible.
>На этом построено подкладывание DLL-оберток, которые подкладывают в папку с игрой, чтобы они загрузились вместо системных, например для читов или чтобы менять шейдеры.
С системными библиотеками беда в том, что на разных системах они могут быть расположены в разных местах, поэтому разработчики решили использовать относительный путь. Если мы говорим о личных библиотеках конкретного приложения, единственным разумным способом загрузки будет загрузка по абсолютному пути, чтобы не было пересечений с любыми другими библиотеками в системе. Тем более если ты решил разместить свои .dll в отдельной от .exe папке: получаешь сначала абсолютный путь до своего .exe, потом добавляешь к нему путь до папки со своими .dll, потом к пути добавляешь имена .dll и уже по этому пути грузишь библиотеки.
Пример:
1. Приложение C:\Games\MyGame\bin\game.exe
2. Ищет папки в папке C:\Games\MyGame\addons\
3. Загружает все найденные аддоны:
3.1. C:\Games\MyGame\addons\MyAddon\addon.dll
3.2. C:\Games\MyGame\addons\your_addon\addon.dll
3.3. C:\Games\MyGame\addons\yEtAn0tHeRaDd0n\add0n.dll
3.4. C:\Games\MyGame\addons\not-a-virus\trust-me.dll
4. Которые, в свою очередь, работают с файлами в своих папках.
Такое поведение вполне реально (по крайней мере на Windows можно, я пробовал), но для него придётся самому заняться поиском нужных тебе файлов, а не полагаться на ОС. ОС все эти библиотеки не найдёт и тем более не сможет понять разницу между addon.dll и addon.dll в разных папках, а разница есть и твоя программа эту разницу прекрасно знает, например, из запроса к загруженным библиотекам (API аддонов должно требовать возврат всей необходимой информации о библиотеке по запросу приложения, что куда надёжнее, чем отдельный от библиотеки файл).
>В нодовых системах это делается обводкой нод рамкой
Ты мне показываешь императивный код в виде нод, а я говорю об архитектуре (будущего) приложения.
>Нет никакой нужды одновременно видеть Landscape/Plants и Gui/Main
Ну а вот мне захотелось, почему ты мне запрещаешь это делать, UI-ев дизайнер?
>Майндмаппинг проектов не отходя от кассы
Точно, видел это, но не пробовал. Нужно проверить, можно ли там делать группы групп.
А если я посмотрю код, вдохновлюсь и сделаю по-своему, нужно указывать автора оригинала?
> Которые, в свою очередь, работают с файлами в своих папках.
ЕМНИП это неважно, потому что каждая DLL по таким же правилам ищет зависимости, начиная со своей папки.
>это неважно
Я имею в виду причину разделения DLL по отдельным папкам: чтобы можно было просто взять модификацию/аддон/модуль и распаковать его в папку модов/аддонов/модулей, не беспокоясь о совпадениях имён нужных им файлов. Тем более что если DLL сама лезет куда-то кроме своей папки, она требует зависимость от каких-то определённых папок/файлов, которых может и не быть.
Допустим, я скачал addon1 и addon2, но переименовал папку addon1 в addon3. Если addon2 сам ищет файл в папке addon1, он его не сможет найти, несмотря на фактическое наличие нужного ему файла в другой папке. А вот если addon2 обращается к game.exe с вопросом о нужном ему внешнем файле, он получит инфу о том, что аддон с названием addon1 находится со всеми его файлами в папке addon3, или просто получит прямые ссылки на нужные ему файлы.
Особенно это может быть важно, если существует два аддона с одинаковым именем, а программа позволяет обращаться к файлам аддонов по уникальным внутренним ID, и пользователь может сам задать, какие файлы использовать каждому из аддонов, создав связи между разными аддонами... Скажем, если ты одновременно установил две версии одного и того же аддона (для какой-то своей цели, это не важно), можешь приказать другому аддону использовать файлы одной из этих двух версий - какой тебе нужно в данный момент.
>переименовал папку addon1 в addon3.
>addon2 сам ищет файл в папке addon1, он его не сможет найти
Естественно. А еще, если стереть папку винды, она не загрузится.
> если существует два аддона с одинаковым именем
То автор сделал что-то не то.
>проверь графический драйвер...
Спасибо за ответ, винда у меня, кстати стоит уже. Впрочем, я думаю, что лучше оставлю годо на линуксе, т.к хорошо вписывается в рабочую среду, а проблема не сильно портит процесс работы на движке. с уважением, анон
> Я прекрасно знаю про ДРАКОН.
Вот ты-то мне и нужен. Я тут попытался описать на ДРАКОНе простейший контроллер и охуел от того, как топорно это выходит (пикрелейтед). Куча дублирующихся действий. Я чего-то не догоняю, или виноват язык?
Тебе не кажется, что поведение "либо иди, либо прыгай на месте, либо взаимодействуй в неподвижном состоянии" немного расходится с большинством экшн игр? Обычно можно и идти (двигаться в горизонтальной плоскости), и прыгать (в вертикальной), и взаимодействовать (подбирать предметы, открывать двери, нажимать кнопки и т.п.) одновременно, не прерывая одним действием другие. Тогда и каскадные ЕСЛИ не придётся делать.
>Куча дублирующихся действий
А там есть функции? Я много слышал про ДРАКОН, какой он хороший и полезный (но никем не используемый), но не вдавался в подробности, чем он отличается от классических блок-схем (за исключением компилятора в текстовый код). По-моему, в классических блок-схемах можно описывать функции (ссылаться на другие блок-схемы).
>стереть папку винды
Ты не понял проблему.
>То автор сделал что-то не то.
Ну вот есть популярная программа X. К ней сделали 100500 дополнений сотни разных авторов. Никто специально не гуглил, какие дополнения уже есть, называл их как хотел. В результате пользователю может потребоваться совмещать друг с другом дополнения с одинаковыми именами. Чтобы не было проблем со стороны дополнений, связи между ними должны происходить через главное приложение (управляющее всеми дополнениями), а не абы как. Модульность имеет смысл только если модули независимы друг от друга и изменчивых условий среды (файловой системы, конфигурации ОС и т.д.).
>Майндмаппинг проектов не отходя от кассы
Протестировал. Недоделанная фигня, не оправдала ожиданий.
Группы мало того что нельзя группировать, так они вообще багнутые.
Интерфейс групп неудобный... Моя идея: чтобы прямоугольники сами растягивались и сжимались до минимально необходимого размера, без необходимости менять их размеры мышкой. Пока группа пустая, она занимает не больше места, чем нужно для отображения её заголовка. Тогда юзабилити улучшится. И ещё нужно чтобы все ноды в группах автоматически сортировались списком/сеткой - нет смысла раскидывать их в произвольные места, раз они принадлежат одной группе. И самое главное, сворачивание групп, чтобы сфокусироваться на главном (по типу скрытия веток в Freeplane).
Нужно будет глянуть код и попробовать сделать по-своему. На первый взгляд там что-то слишком много функций для такой простой функциональности...
>чтобы прямоугольники сами растягивались и сжимались до минимально необходимого размера, без необходимости менять их размеры мышкой. Пока группа пустая, она занимает не больше места, чем нужно для отображения её заголовка.
>все ноды в группах автоматически сортировались списком/сеткой
Вообще, такое поведение ведь уже есть у некоторых Control нод. Т.е. можно было бы реализовать то, о чём я говорю, безо всяких аддонов - просто как новую сцену. Аддон нужен только для создания ссылок между графическими элементами и файлами, но на первых порах можно и без него обойтись, пока описываешь абстрактные структуры.
>сворачивание групп, чтобы сфокусироваться на главном
А для этого можно переключить видимость вложенной ноды. Тогда внешние автоматически сожмутся в размерах, как если бы в них ничего не было.
Гениально, просто гениально же, Хуан - гений (или кто там делал Control ноды). И не нужно мучиться с внешними редакторами типа Inkscape и Freeplane.
> Протестировал. Недоделанная фигня, не оправдала ожиданий.
Спасибо.
Ящитаю, что для майндмаппинга нет ничего лучше старой доброй тетрадки в клеточку и карандаша.
>Спасибо.
Тебе настолько лень протестировать аддон весом 45 КБ?
Я думаю, у него есть потенциал. Можно было бы расширить. Но сейчас баги и дизайн не позволяют пользоваться всерьёз, функций мало, а скрипты, на мой взгляд, плохо организованы. Задумка хорошая, но это недоделанный прототип.
Кстати, он оказался основан на GraphEdit и GraphNode - только реальный функционал GraphNode никак не используется, все коннекторы отключены и даже встроенный заголовок заменён TextEdit. Я считаю это неправильным. Можно было бы задействовать способность GraphNode создавать соединения между элементами, чтобы пользователь мог заполнять GraphNode (группы) своими файлами и соединять их между собой линиями. GraphNode автоматически выстраивает элементы вертикально, о необходимости чего я выше уже писал. Ну, либо отказаться от GraphNode и реализовать кастомный компонент, который поддерживал бы многоуровневую вложенность.
Я попробовал сделать простую сцену на основе базовых Control-контейнеров, совсем без скриптов. Короче, моя идея была фигнёй, такое отображение проекта не даёт ничего существенного, а куча вложенных прямоугольников (одного цвета) только сбивают с толку... Эх, жаль, придётся искать другие способы.
>для майндмаппинга нет ничего лучше старой доброй тетрадки в клеточку и карандаша.
Конкретно для диаграмм связей лучше всего https://en.wikipedia.org/wiki/Freeplane
Я пробовал его использовать - очень удобно оказалось. Но мне как-то лень возиться с этими диаграммами, поэтому достаточно быстро забросил и давно не открывал. Нужно глянуть, что я там по своей игре понаписал, а то вечно что-то записываю и не читаю записи...
Тетрадка в клеточку с карандашом не позволяет быстро и легко менять связи, перетаскивать ветки, встраивать новые ветки между существующими и т.д. и не адаптирует размер элементов под количество написанного текста. А если у тебя ещё и почерк плохой, записи превращаются в хаос, в котором ты сам ничего не поймёшь через какое-то время. Лично я забросил ручные записи, когда закончил школу, и с тех пор всё делаю на компьютере или на телефоне. Уж лучше потерять все свои электронные записи, чем мучиться с бумажными.
> Тебе настолько лень протестировать аддон
Чудовищно похуй, настолько чудовищно похуй, позвольте мне сказать вам, что если каждое слово во всех исходниках всех операционных систем заменить на слово ПОХУЙ, это не выразит и билионной доли того похуизма, который испытываю я в данный микромиг по отношению к этому адднону. Похуй. ПОХУЙ.
> мучиться с бумажными
Ну тут на вкус и цвет товарищей нет. Кому как удобнее.
Всем добра. Я не из гейм-разработки и есть вопрос.
Подойдет ли Годо для 3Д проекта с небольшим набором простых функций:
- подойти к шкафу, набрать оттуда предметов
- подойти к другому шкафу, открыть его, применить выбранные ранее предметы.
- нужно чтобы учитывались ошики. Тоесть если неправильно применил предмет, и наооборот - начисление очков при правильном использовании.
Трехмерная обучалка короче.
Размер сцены обычно: 100 шкафов с переключателями. В полигонах это около 200-300 тысяч. До этого подобные штуки реализовывались в Юнити. Но возникла необходимость найти\рассмотреть альтернативу. Легкую, более понятную и бесплатную конечно.
Подойдет ли Годо для таких целей?
Подойдет ли Годо для 3Д проекта с небольшим набором простых функций:
- подойти к шкафу, набрать оттуда предметов
- подойти к другому шкафу, открыть его, применить выбранные ранее предметы.
- нужно чтобы учитывались ошики. Тоесть если неправильно применил предмет, и наооборот - начисление очков при правильном использовании.
Трехмерная обучалка короче.
Размер сцены обычно: 100 шкафов с переключателями. В полигонах это около 200-300 тысяч. До этого подобные штуки реализовывались в Юнити. Но возникла необходимость найти\рассмотреть альтернативу. Легкую, более понятную и бесплатную конечно.
Подойдет ли Годо для таких целей?
Конечно.
Да
Годаны, ссылочка для ознакомления:
>набрать оттуда предметов
>100 шкафов с переключателями
Если делать чисто на нодах, нужно учитывать, что чем больше нод, тем выше нагрузка на ЦПУ, при этом работа с нодами в Годо упирается в производительность одного ядра. На процессоре 2007 года не стоит рассчитывать на что-то больше 30-50 тысяч нод. При этом один игровой предмет, как правило, содержит в себе несколько нод, например, визуальный предмет с простой физической моделью будет состоять минимум из трёх нод (графическая модель, модель коллизий и нода PhysicsBody). Также, если говорим о физике, нужно учитывать, что физика работает на процессоре в один поток и поэтому тормозит с менее чем тысячью динамических объектов (со статикой легче, поэтому временная заморозка динамических объектов спасает производительность).
Из всего этого следует, что, несмотря на лоупольность "шкафов", их предметное содержимое может потребоваться временно удалять из дерева сцены, добавляя в сцену только по необходимости. Это несложно, но следует об этом помнить, так, на всякий случай. Также можно попробовать оптимизировать сцену отказом от некоторых нод через объединение моделей или прямыми обращениями к соответствующим "серверам" движка (можно и графику, и физику делать без создания новых нод в дереве).
Также ветка 3.x движка рисует каждую графическую модель минимум за один вызов отрисовки (источники света увеличивают число отрисовок), из-за чего может возникать сильная просадка производительности, когда на сцене 10 тысяч или больше независимых графических моделей. В версии 4.0 это исправили и теперь модели с одним материалом могут рендериться за один вызов отрисовки, что избавляет от необходимости создавать костыли, если у тебя мало материалов в сцене. Ещё в Годо нет автоматического отбрасывания лишней графики, которая скрыта за другой графикой - нужно самому вручную расставлять окклюдеры или скрывать лишние модели из сцены (не касается моделей позади камеры, эти-то точно скрываются автоматически). Я слышал, в других движках это может быть полностью автоматизировано... Не помню точно, добавили такой механизм в 4.0 или нет, но в бете по-прежнему предлагается расставлять окклюдеры вручную.
А вот интересно, если не секрет, для чего именно нужен такой симулятор? Это ведь для обучения какой-то конкретной профессии? Интересно, каким профессиям сейчас начинают серьёзно обучать в виртуальной среде. Не представляю себе работу, где было бы аж 100 шкафов с предметами/переключателями, по-моему, такое могло быть только во времена старых телефонных станций... или на каких-нибудь суперкомпьютерах... или в серверной с кучей стоек... или архив данных на магнитных лентах... Хотя виртуальный симулятор подразумевает опасность обучения на настоящем оборудовании...
>Из всего этого следует, что, несмотря на лоупольность "шкафов", их предметное содержимое может потребоваться временно удалять из дерева сцены, добавляя в сцену только по необходимости.
Шкафы это комнаты, значит работает система порталов.
>Шкафы это комнаты
Кто сказал? Я так понял, что у него обычные шкафы, вроде лабораторных или электротехнических.
>значит работает система порталов
Систему порталов нужно настраивать вручную. Для реальной модели шкафа эта настройка не будет иметь смысла, потому что шкаф маленький и войти в него мы никак не можем. Будет намного логичнее сделать такую структуру в дереве сцены:
- шкаф
- - содержимое шкафа:
- - - предмет 1
- - - предмет 2
- - - предмет 3
Когда игрок нажимает кнопку "открыть шкаф", субнода "содержимое шкафа" входит в дерево и отображает все связанные предметы, которые можно извлечь из шкафа и поставить потом в другой шкаф. Когда игрок закрывает шкаф, эта субнода со всем своим содержимым удаляется из дерева сцены. Если у шкафа непрозрачные дверки, тогда этой системы будет более чем достаточно и она, возможно, может быть самым оптимальным решением.
>Кто сказал? Я так понял, что у него обычные шкафы, вроде лабораторных или электротехнических.
Room в движке - не то же самое, что комнаты в реальном мире. Комнатой может быть даже котенок с дверцей.
>Систему порталов нужно настраивать вручную.
Она настроится естественным образом, ведь у тебя есть сцена шкаф, в который ты задашь комнату, и дверца, где ты задашь портал.
>шкаф маленький и войти в него мы никак не можем
Возможность входить вообще никак не влияет на комнаты. Это метод визуального куллинга, отвечающий за отображение, а не ходьбу.
>Room в движке - не то же самое, что комнаты в реальном мире.
>Возможность входить вообще никак не влияет на комнаты.
Ты меня за дурака держишь?
Система комнат имеет смысл, когда комнаты большие и камера много двигается вокруг и внутри них. Часть объектов в комнате может быть видна, часть не видна, а часть вообще вышла погулять в другую комнату... Это сложная динамическая система, которая анализируется каждый тик движка. И это оправданные затраты, когда у тебя коридорный лабиринт типа шутера с кучей предметов и мобов в каждой комнате, а камера перемещается, по сути, непредсказуемо.
Если же у тебя тонкий лабораторный шкафчик с выстроенными в нём склянками, то делать из него комнату в системе комнат Godot глупо и нерационально, как палить из пушки по воробьям. Размеры шкафчика, условия его отображения на экране и его содержимое располагают к куда более простому решению: скрывать все предметы, когда двери закрыты, и отображать их все, когда двери открыты, всё. Максимум можно добавить автоматическое скрытие предметов, когда игрок отошёл далеко. Зачем усложнять, добавляя анализ текущего состояния для каждой склянки индивидуально, когда они все по определению будут неподвижно стоять в поле зрения камеры, ничем не скрытые?
Вот если ты хочешь сделать игру про мышь, которая бегает по мебели и в том числе по полкам шкафа, уклоняясь от каких-нибудь пылевых монстриков между книгами, тогда да, можно сделать комнатой хоть каждую полку шкафа, потому что фактически это и будут комнаты в функциональном смысле (заходим, проходим, выходим, и так далее). А для типичного ИРЛ шкафчика задействовать систему комнат нерационально.
Я не утверждаю, что мой способ будет производительнее системы комнат, нужно тестировать в каждом конкретном случае. Но ты предлагаешь комнаты как панацею, а это не так, у них ограниченное применение.
/ADDONS
____@____
(пишетсо)
— Чем вы занимаетесь в свободное время?
— Аддонс слеш аддонс слеш аддонс слеш...
— Простите, что?
— ...слеш аддонс слеш аддонс слеш аддонс...
— Спасибо, вы нам не подходите.
— ...слеш аддонс слеш аддонс слеш аддонс...
— Контрол-це, контрол-це!
— Фух, спасибо, отпустило. Всё дело в том, что иногда я делаю аддонс слеш аддонс слеш аддонс...
____@____
(пишетсо)
— Чем вы занимаетесь в свободное время?
— Аддонс слеш аддонс слеш аддонс слеш...
— Простите, что?
— ...слеш аддонс слеш аддонс слеш аддонс...
— Спасибо, вы нам не подходите.
— ...слеш аддонс слеш аддонс слеш аддонс...
— Контрол-це, контрол-це!
— Фух, спасибо, отпустило. Всё дело в том, что иногда я делаю аддонс слеш аддонс слеш аддонс...
> субнода "содержимое шкафа" входит в дерево
> субнода со всем своим содержимым удаляется из дерева сцены
Может щас конечно пофиксили, но пару лет назад я попытался так сделать и получил лаг и при входе в дерево, и при выходе. Соответственно, первое что я попробовал это заменить создание объектов на репарент из некой ноды-пула, не находящейся в дереве. Но по очевидной причине это не исправило проблему. Потому что тормозит не создание объекта, а ввод его в дерево.
> Ты меня за дурака держишь?
Почему "за"?
Система комнат работает даже когда ты не входишь в комнату. Когда камера снаружи комнаты. У комнаты есть двери и окна. Если камера видит "комнату" через её окно/дверь - комната показывается, иначе скрывается.
> комнаты ета кахда в их входеш
И кто тут дурак?
Доставляю свежие крафтовые обои для создания подобающей атмосферы во время бессонных ночей с Godot. Налетайте, сохраняйте, хватит всем. Пришло время устанавливать все аддоны!
>Wake up Juan…
>The Godot has you...
>Follow the white_rabbit.gd
>Wake up Juan…
>The Godot has you...
>Follow the white_rabbit.gd
Вы только посмотрите на это! ОНО ЖИВОЕ! Оно что-то говорит! Оно осознаёт масштабы п... проблем с моим основным проектом! Щас ещё чуть-чуть поколдую и будет полноценный помощник в быдлокодинге.
Так обидно. 2.5к строк кода без пустых строк и строк-комментариев. Хотя много кода закопано в отдельном могильнике или совсем удалено, потому что я уже много раз с нуля всё переписываю. А всё почему? Потому что у меня велосипеда своего не было, чтобы рисовать карту проекта. А теперь сразу кодить начну так, чтобы правильно было с самого начала.
Сбор этой статистики занял 200 мс, кажется, очень неплохо, учитывая что пришлось пройтись по всем строчкам всех скриптов и каждой из них отрезать начальные пробелы, а то вдруг там комментарий.
Так обидно. 2.5к строк кода без пустых строк и строк-комментариев. Хотя много кода закопано в отдельном могильнике или совсем удалено, потому что я уже много раз с нуля всё переписываю. А всё почему? Потому что у меня велосипеда своего не было, чтобы рисовать карту проекта. А теперь сразу кодить начну так, чтобы правильно было с самого начала.
Сбор этой статистики занял 200 мс, кажется, очень неплохо, учитывая что пришлось пройтись по всем строчкам всех скриптов и каждой из них отрезать начальные пробелы, а то вдруг там комментарий.
Программу минимум выполнил: отображается структура проекта на основе дерева файлов и папок, папки можно открывать и закрывать по клику... Да, в итоге получилось обычное древовидное представление файловой системы, которое уже есть в Godot, но, во-первых, я перепробовал несколько вариантов и этот наиболее подходящий (для отображения связей), во-вторых, встроенный файловый менеджер неудобный и не имеет тех фич, которые мне нужны, в-третьих, встроенный компонент Tree наверняка накладывает кучу ограничений, в отличие от композиции из простых нод. Так что этот велосипед мне в любом случае нужен.
Добавил в среднее нижнее меню, потому что это проще - один простой вызов API, чаще всего туда мышкой тыкаю и окна в этой области при необходимости можно раскрыть на весь экран хоткеями, а ещё эти окна не прерывают/не закрывают открытую сверху вкладку (2D/3D/Script). Имхо, идеальное место для карты проекта/менеджера проекта. А с вертикальной компоновкой и прокруткой колёсиком мыши вообще круто получилось.
Далее я планирую добавить отображение связей (иерархия классов и создание экземпляров, включения ресурсов, обработчики событий, предоады всякие) между файлами в виде линий, цветовое кодирование файлов и связей (это заметнее иконок), раскрытие списка методов в скриптах и списка нод в сценах (чтобы не открывать в редакторе лишний раз, видеть подробные связи)... Часть информации точно можно получить из АПИ движка, но за другой частью скорее всего придётся парсить текстовые файлы вручную. Предполагаю нагромождение линий, поэтому планирую фичу затемнения фоновых линий и подсветки линий в/из выбранный/ого файл/а. Также линии должны входить даже в свёрнутые папки - чтобы было понятно, где искать их концы (что раскрывать).
Сами линии планирую рисовать через _draw(), надеюсь, не сильно упадёт производительность (я рассматривал GraphNode, они мне не подходят). Также есть идея сохранять скриншот всей карты проекта. И ещё состояния закрытых папок. И кастомные связи... хотя с этим не уверен, т.к. сложно совместить автоматически собранную карту с вручную заданными данными - что, если файл на диске переименуется или переместится, что делать с этими вручную заданными данными? Смысла в них, получается, нет, раз их так легко потерять или если они легко теряют актуальность (как комментарии в коде).
Про наличие встроенного менеджера "сирот" и про списки пользователей у ресурсов/списки используемых ресурсов у сцен знаю. Проблема в том, что вся эта информация разбросана по куче менюшек, которые даже не открываются одновременно - пока открыл одну, забыл, что было в другой... Хорошо, если удастся добыть информацию из этих менюшек для своего аддона. А вот информации по связям между скриптами, похоже, в движке вообще нет, придётся вручную парсить.
А ещё мне нравится антропоморфизм у программ, поэтому с самого начала хуманизировал свой аддон. Это один из стимулов довести программу до ума. Есть мысли добавить что-то мотивирующее типа мини-чат-бота и в целом развить до полноценного менеджера проекта (с планированием и т.п.), но это слишком амбициозные идеи для меня, нужно сначала с базой разобраться...
Кому я это всё пишу? Вряд ли это кому-то здесь интересно, и вряд ли я буду распространять этот аддон, потому что... по разным причинам.
Да буду я делать игру, буду. Когда-нибудь. Потом. Когда соберу полный комплект велосипедов на все геймдев-случаи. Свой движок я не смог довести до ума, так хотя бы готовый доработаю под себя. Шучу.
Добавил в среднее нижнее меню, потому что это проще - один простой вызов API, чаще всего туда мышкой тыкаю и окна в этой области при необходимости можно раскрыть на весь экран хоткеями, а ещё эти окна не прерывают/не закрывают открытую сверху вкладку (2D/3D/Script). Имхо, идеальное место для карты проекта/менеджера проекта. А с вертикальной компоновкой и прокруткой колёсиком мыши вообще круто получилось.
Далее я планирую добавить отображение связей (иерархия классов и создание экземпляров, включения ресурсов, обработчики событий, предоады всякие) между файлами в виде линий, цветовое кодирование файлов и связей (это заметнее иконок), раскрытие списка методов в скриптах и списка нод в сценах (чтобы не открывать в редакторе лишний раз, видеть подробные связи)... Часть информации точно можно получить из АПИ движка, но за другой частью скорее всего придётся парсить текстовые файлы вручную. Предполагаю нагромождение линий, поэтому планирую фичу затемнения фоновых линий и подсветки линий в/из выбранный/ого файл/а. Также линии должны входить даже в свёрнутые папки - чтобы было понятно, где искать их концы (что раскрывать).
Сами линии планирую рисовать через _draw(), надеюсь, не сильно упадёт производительность (я рассматривал GraphNode, они мне не подходят). Также есть идея сохранять скриншот всей карты проекта. И ещё состояния закрытых папок. И кастомные связи... хотя с этим не уверен, т.к. сложно совместить автоматически собранную карту с вручную заданными данными - что, если файл на диске переименуется или переместится, что делать с этими вручную заданными данными? Смысла в них, получается, нет, раз их так легко потерять или если они легко теряют актуальность (как комментарии в коде).
Про наличие встроенного менеджера "сирот" и про списки пользователей у ресурсов/списки используемых ресурсов у сцен знаю. Проблема в том, что вся эта информация разбросана по куче менюшек, которые даже не открываются одновременно - пока открыл одну, забыл, что было в другой... Хорошо, если удастся добыть информацию из этих менюшек для своего аддона. А вот информации по связям между скриптами, похоже, в движке вообще нет, придётся вручную парсить.
А ещё мне нравится антропоморфизм у программ, поэтому с самого начала хуманизировал свой аддон. Это один из стимулов довести программу до ума. Есть мысли добавить что-то мотивирующее типа мини-чат-бота и в целом развить до полноценного менеджера проекта (с планированием и т.п.), но это слишком амбициозные идеи для меня, нужно сначала с базой разобраться...
Кому я это всё пишу? Вряд ли это кому-то здесь интересно, и вряд ли я буду распространять этот аддон, потому что... по разным причинам.
Да буду я делать игру, буду. Когда-нибудь. Потом. Когда соберу полный комплект велосипедов на все геймдев-случаи. Свой движок я не смог довести до ума, так хотя бы готовый доработаю под себя. Шучу.
Через неделю Ludum Dare. Сделай на него игру за 2-3 дня, тогда и узнаешь, какие реально нужны велосипеды для игры (контроллеры персонажей, платформинг с койот таймом, сочные анимации, менюшки и настройки). а какие просто украшательства редактора.
Двачую. Ценное замечание.
>Сделай на него игру за 2-3 дня
Я тебе могу игру за час сделать. И что теперь? Все игры за час делаются?
>какие реально нужны велосипеды для игры
Ты говоришь не про "велосипеды для игры", а про "велосипеды для примитивной индюшатины, высранной за 2-3 дня на джем, с единственной целью - набрать побольше очков по правилам джема, а после джема забыть об этой игре навсегда".
>просто украшательства редактора
Анон, я уже несколько лет пытаюсь разработать игру (ещё больше лет я о ней мечтал), эту игру невозможно слепить из кучки готовых шаблонов за 2-3 дня, даже за 2-3 недели не получится. Тем более если планируется развивать и дополнять проект, а не вылепить одноразовое говно и выкинуть на рынок без надежды на обновления, как делают большинство геймджемеров и ассетфлиперов (люди с проектом мечты тоже в это дерьмо вляпываются, но не специально, а по глупости/необразованности).
Эти "украшательства редактора" не на пустом месте возникли. Я выше уже описывал причины, по которым я хотел бы иметь такой инструмент, и почему он должен быть автоматическим. Работая над проектом, бросая его на месяцы и принимаясь за него снова, снова бросая и снова работая, я вывел для себя главную проблему разработки - сложность навигации по проекту. Я пытался организовывать всё по папкам, реорганизовывал файлы проекта несколько раз. Всё бесполезно, я просто не вижу общей картины проекта, не знаю, как и что в нём происходит, пусть даже писал каждую строчку лично, без копирования. В уме это всё не увидеть, не хватает ёмкости оперативной памяти мозга (по крайней мере мне). Во внешнем редакторе картинок можно нарисовать схему проекта, но она быстро потеряет актуальность, а требование вручную обновлять схему на каждое изменение в структуре проекта раздражает и отнимает лишнее время. Почему я не могу просто нажать одну кнопку "обновить карту проекта" и визуально увидеть всё или хотя бы основную часть того, что я накодил за несколько часов труда? Я хочу иметь контроль над своим проектом, а как я могу иметь контроль над тем, что я даже не знаю и не помню, где находится и почему вообще существует?
Да, в проекте игры за 2-3 дня такие проблемы не возникают. Да, я слишком много времени трачу на прокрастинацию и поэтому всё, что у меня есть, можно было бы сделать куда быстрее. Но у меня свой проект и свои личные проблемы, которые я пытаюсь как-то решить, используя имеющиеся навыки и знакомые инструменты. Если тебе не нужен такой инструмент для своих игр - тебе повезло, молодец, просто замечательно, и что дальше? Мне с моими проблемами твоя успешность не поможет.
>Я тебе могу игру за час сделать
Хорошо, я сейчас в магазин иду, через полтора часа жду игру.
Я НЕ осуждаю украшательства редактора, у самого стоит аддон https://godotengine.org/asset-library/asset/1359 и удивляюсь как никто раньше не додумался до такой гениальной идеи. И точно не осуждаю всякие инструменты планирования. Тем более что их реально нехватка, до сих пор нет ничего вменяемого что позволило бы вести майндмап/собирать скетчи, рефы/создавать вики базу знаний/планировать сюжеты и таймлайны. Но разрабатывая такой инструмент, ты становишься разработчиком инструмента, а не разработчиком игры. Игрок ничего этого не увидит, ему все равно, были ли у тебя записи в голове, в бужманом блокноте, или в твоем чудо инструменте. А узнать эффективность инструмента ты сможешь только создав игру с его использованием и без него и сравнив время. Кроме того, именно во время разработки игры ты узнаешь, какие инструменту реально нужны фичи.
>через полтора часа жду игру
Зачем ждать, вот это сделано как раз за час-полтора.
Это игра? Да, это игра: есть сцена, по сцене можно двигать персонажа, на сцене есть полоса препятствий даже с подвижным "противником", которого нужно вовремя перескочить, в конце полосы препятствий есть финальная зона, которая отображает поздравительную надпись. Игроку нужно приложить хотя бы минимальные усилия, чтобы пройти эту игру до конца, пускай это и потратит меньше минуты.
Хорошая ли это игра? А никто не говорил о хороших играх. На геймджемах лепят всякое говно, лишь немногие реально пытаются сделать качественную игру в короткий срок. Ещё меньше людей продолжают развивать свою игру после геймджема - большинство проектов так и бросаются в стадии "0.1-альфа", не заработав очков на джеме.
И заметь, в этой мини-игре нет ни строчки кода, есть только соединения между готовыми механизмами движка. Заблудиться тут просто негде, даже если через десять лет открыть этот проект - быстро поймёшь, как он устроен и что можно изменить для введения новых фич. Хотя какие новые фичи? Никто не будет вводить сюда новые фичи, это проект за час для единственной цели (продемонстрировать игру без кода).
А ты попробуй делать большую, сложную игру на протяжении многих лет. Некоторые игры делают десятки лет, двадцать лет работы над одной игрой - уже не предел. Мало того, что файлов и кода дохрена, так ещё ты и не вспомнишь, что ты делал в файле, который открывал последний раз десять лет назад. А он с чем-то связан, что-то требует для работы, кому-то нужен... Изменишь файлик, который вроде как ни зачем не нужен - и проект обвалится целиком, только ты можешь даже и не понять, почему это происходит. Бывают даже анекдотичные случаи, когда в выпущенной игре оставляют тестовый файл, который нельзя удалить - без него игра не работает, а почему она без него не работает - никто толком сказать не может. Оставляют этот файлик, лишь бы релизнуть рабочую игру и не затягивать время разработки ещё дольше, лол.
>как никто раньше не додумался до такой гениальной идеи
Честно говоря, не вижу практического смысла вставлять картинку на фон кода. Во-первых, любая картинка будет неосознанно привлекать внимание глаз, отвлекая от кода (особенно если там персонаж - мозг генетически тренирован часто обращать внимание на чужие "глаза", даже если это нарисованные круги). Во-вторых, нужна картинка с достаточно равномерным цветом, иначе цветастый код может на ней потеряться. Получается какой-то web 2.0, когда лепили флеш-анимации на сайт только для "красоты", и в результате страдало удобство использования сайта, его основные функции.
>нет ничего вменяемого что позволило бы вести майндмап/собирать скетчи, рефы/создавать вики базу знаний/планировать сюжеты и таймлайны
Ты имеешь в виду "нет ничего встроенного в Godot"? Потому что отдельно от Godot существуют годные программы, которые можно использовать для всех этих целей. Я пытаюсь сделать аддон только потому, что он должен быть связан с файлами проекта и их содержимым, а движок позволяет сравнительно просто узнать содержимое этих файлов, не создавая парсер с нуля. А вот вики, абстрактную карту мыслей и подборку скетчей прямо в движке делать смысла нет, как мне кажется. Т.е. можно, но мотивации интегрировать это в движок нет. Для вики возьми вон TiddlyWiki, зачем интегрировать это в движок? Разве что для гиперссылок на файлы проекта, но вики это не так уж и нужно - в ней должно быть больше текста, чем ссылок...
>Игрок ничего этого не увидит, ему все равно, были ли у тебя записи в голове, в бумажном блокноте, или в твоем чудо инструменте.
Так игроку это и не нужно видеть. Но если я буду и дальше перекапывать вручную весь проект и потом снова по кругу менять одно на другое, снова перекапывать... Игрок новую игру никогда не увидит. А я и есть главный игрок для своей игры, и я бы хотел её увидеть.
>именно во время разработки игры ты узнаешь, какие инструменту реально нужны фичи
Так я же не новичок, который только вкатился в геймдев и уже делает аддон для движка. Я пытался делать разные игры на разных инструментах, и знаю, какие фичи мне были бы полезны. Конкретно с Godot доходило до негодования от того, что нельзя визуально увидеть связи, которые объективно существуют, но узнать о них можно только из кода или из какой-то глубоко засунутой в дебри GUI менюшки...
У тебя полчаса осталось, а ты строчишь полотна текста.
Пацаны-ребята, а это только у меня такая херобора с годотом творится? 3.5 стабле. Открыл старый проект, а там инпуты багуют. Причём только с джоев-дефендеров, клавамыш отлично себя ведут. Некоторые кнопки джоев "западают", то есть их можно нажать, но событие релиза Годо уже не видит.
Ну, может, мой код устарел? Ладно, сделал тестовый проект:
func _input(event):
if event.is_action_pressed("ui_right"):
$right.color = Color.red
.......
elif event.is_action_released("ui_right"):
$right.color = Color.white
.......
print(event)
Но там тоже западают кнопки.
Ок, но может, джой виноват? Нет, в других приложениях (mednafen, jstest-gtk) проблемы не обнаружено, все кнопки отжимаются нормально.
Вопрос-то простой. Кто-то с подобным сталкивался?
Ну, может, мой код устарел? Ладно, сделал тестовый проект:
func _input(event):
if event.is_action_pressed("ui_right"):
$right.color = Color.red
.......
elif event.is_action_released("ui_right"):
$right.color = Color.white
.......
print(event)
Но там тоже западают кнопки.
Ок, но может, джой виноват? Нет, в других приложениях (mednafen, jstest-gtk) проблемы не обнаружено, все кнопки отжимаются нормально.
Вопрос-то простой. Кто-то с подобным сталкивался?
Кнопки физические или стик? Сейчас потыкал свой китайский нонейм за 200 рублей, все работает на крестовине. Стик не ковырял.
Как можно избавиться от "ошибок" модулей Godot в его консоли?
Версия 3.5.stable, часто вылетает что-то вроде:
>modules/gdscript/gdscript_tokenizer.cpp:1117 - Condition "tk_rb[ofs].type != TK_IDENTIFIER" is true. Returned: StringName()
Мне эта "ошибка" (отображается красным) ни к чему вообще, я не могу её исправить и вообще не знаю, что я с ней должен делать. Мой код и редактор Godot работают без падений - этого достаточно.
Подобное возникает из версии в версию с разными модулями движка. Похоже на то, что для стабильного релиза регулярно забывают отключить какие-то дебаг функции. Или я чего-то не понимаю? Можно как-то отключить через настройки или только собственный билд движка делать?
Раздражает не само сообщение в консоли, а то, что оно подсвечивается красным, привлекая внимание к консоли лишний раз. У меня бывают реальные ошибки, на которые нужно обратить внимание, а вот такие "ошибки" только уменьшают значимость красной точки на вкладке консоли. Приходится чаще очищать консоль, но эти "ошибки" слишком часто появляются, засоряют консоль.
>событие релиза Годо уже не видит.
>сделал тестовый проект:
>if event.is_action_pressed("ui_right"):
>elif event.is_action_released("ui_right"):
Ты бы вместо этого лучше выводил в консоль сам event и его содержимое.
>func _input(event: InputEvent) -> void: print(event, " - ", event.as_text())
Ну и дальше по субтипам можно пройтись, вывести в консоль их значения.
https://godotengine.org/article/tiles-editor-rework
Вот эти реворки в 3.5 уже есть?
Вот эти реворки в 3.5 уже есть?
>Честно говоря, не вижу практического смысла вставлять картинку на фон кода.
Эститика и красота + вдохновление. У меня там крутится слайдшоу эскизов для моей игры, чтобы не забывать цель.
Нет и вряд ли будут, там же все по другому и это будет breaking change, Хотя я бы не отказался от такого.
Там же в самом начале сказано: 4.0.
Смотри описание беты 4.0, там сказано, что они существенно переработали TileMap.
Не вижу причины не щупать 4.0 уже сейчас, если железо поддерживает Vulkan.
>крутится слайдшоу эскизов для моей игры, чтобы не забывать цель
Вот это хорошая идея. Ещё б у меня были эскизы к своим играм))
>Кнопки физические или стик?
Физические
>Ты бы вместо этого лучше выводил в консоль сам event и его содержимое.
Ты не заметил, у меня там в конце есть print(event). Но в любом случае - нажатие принтится, а на релиз просто ничего не происходит.
Но, в общем, я всё же подозреваю, что виноваты либо юсбы джоев, либо юсбы ноута. Не понимаю, как при этом всё может работать в эмулях; но я там только проверил, что всё отжимается, может, если бы поиграл подольше, обнаружил бы косяки.
В ишьях в таких случаях посылают тестировать этим проектом
https://godotengine.org/asset-library/asset/140
Кроме того, советую проверить другие версии, например 3.4 и 3.5.1rc1.
В ченджлогах все время упоминают обновления маппингов джойстиков, да и баги часто с ними всплывают. Я их все не читал, но пишут что-то про назначение осей. В частности, почему я спросил про стики. У меня было так что стик залипал вправо и постоянно слал что он нажат. Вроде бы сейчас для этого есть параметр dead zone.
>print(event)
Нужно print(event.as_text()), чтобы узнать, зажата клавиша или отпущена.
События геймпада прям так и пишут, pressed=true или pressed=false.
>виноваты либо юсбы джоев, либо юсбы ноута
Возможно. Я только что протестировал свой старый китайский беспроводной (блютуз) геймпад: у него как раз аккумулятор почти разряжен и он отключался пару раз во время тестов. Когда соединение/питание теряется, геймпад уже не может сообщить событие отпускания клавиши, и до Годо, естественно, ничего не доходит. В твоём случае, если кабель или разъём повреждены, тогда сигнал нестабилен и некоторые события могут не доходить от геймпада до компьютера или вовсе не генерироваться геймпадом (из-за временной потери питания, что с проводными устройствами ввода без индикаторов легко не заметить). Либо у тебя может быть какая-то проблема с драйвером (я никаких специальных драйверов не ставил, работает стандартный от Microsoft).
>Не понимаю, как при этом всё может работать в эмулях
Могу предположить, что если твой геймпад действительно не генерирует события отпускания клавиш, эмуляторы могут учитывать тот факт, что пользователь вряд ли будет нажимать одновременно слишком много клавиш, и считать ранее нажатую клавишу отпущенной, если нажато несколько новых... Хотя, это определённо создаст проблемы в сложных играх типа файтингов, где нужно комбинации набирать. Проверь на играх, может, действительно проблема в геймпаде.
Я написал небольшой скрипт для тестов, в том числе на основе твоего кода.
Что протестировал:
1. Одиночные нажатия и нажатия с удерживанием клавиши.
2. Нажатия нескольких клавиш с удержанием (как минимум 5 за раз).
3. Вывод как InputEvent, так и action из InputMap для сравнения.
4. Стики (у моего геймпада очень плохие - жёсткие и с низкой чувствительностью).
5. Клавиши клавиатуры для сравнения, ближе к концу видео видно.
6. Спонтанно получилось отключение (0:38) и подключение геймпада (0:43).
Всё работает как предполагалось. Радует, что в своей игре я могу забиндить любые клавиши геймпада, а то в чужих играх ребиндить клавиши геймпада обычно невозможно, из-за чего мой геймпад почти ни к какой игре нормально не подходит, а эмулятор геймпада плохо с ним взаимодействует по какой-то причине (что-то с x360 в названии тестил - сначала работало нормально, потом "сломалось"). Зато у него 4 режима работы: можно использовать в компьютере вместо беспроводной мышки и играть им в игры без поддержки геймпада. Ещё и к смартфону без проблем подключается. Правда, я им почти не пользуюсь из-за слишком грубых стиков. Нет, серьёзно, зачем вообще нужен геймпад, если у него такие примитивные стики? На клавомыши или даже сенсорном экране куда удобнее, чем на геймпаде.
Если разберёшься, почему у тебя геймпад неправильно работает, отпишешься в треде? Интересно же, с чем это на самом деле связано.
>посылают тестировать этим проектом
Вижу там прикольные картиночки, но не вижу на скриншоте консоль. Смысл такого теста без вывода информации в консоль? Во всех нормальных тестерах устройств ввода должна быть консоль с "сырой" информацией от устройств ввода (ОС/драйвера), а без картинок с надписями можно было бы и обойтись - кроме стиков, их лучше графически отображать, но там что-то нет графиков с двумя осями. Нужно попробовать такой график нарисовать, авось удастся хотя бы в Godot сгладить эти грубые стики, чтоб от них хоть какая-то польза появилась, если это возможно...
>В ченджлогах все время упоминают обновления маппингов джойстиков
Скорее всего это для официальных геймпадов (XBOX, PS, Nintendo), владельцев китайских изделий это никак не касается. Неприятно, когда в интерфейсе написано одно, а на деле клавиша у официального девайса по-другому называется. С китайскими вполне ожидаемо, что названия не будут совпадать.
>У меня было так что стик залипал вправо и постоянно слал что он нажат.
Ось не шлёт "нажата"/"отпущена". Она шлёт свой индекс и величину отклонения от 0 до 1, когда эта величина изменяется. Хотя, возможно, если забиндить Action на какую-то ось, то должно приходить "отпускание"? Но ведь его физически не происходит, нет? Ты ведь, по сути, почти никогда не снимаешь пальцы с грибков и курков, только переводишь их в положение "0". И если у тебя есть бинд оси на Action, тогда нужно проверять не is_action_pressed и не is_action_released, а только get_action_strength, которое может вернуть 0.
>Вроде бы сейчас для этого есть параметр dead zone.
Параметр "мёртвая зона" подразумевает минимальное значение величины отклонения оси, значения ниже которого считаются нулём. Кнопок это не касается и к событиям отпускания клавиш тоже отношения не имеет. Не у всех геймпадов оси хорошо откалиброваны, поэтому в свободном состоянии могут генерировать событие с величиной отклонения 0.00n (видно на моём видео, оси 1 и 3 генерируют 0.007813 в свободном состоянии, а вот оси 0 и 2 правильно генерируют 0). Чтобы персонаж в игре не пытался очень медленно идти в сторону, приходится округлять такое очень маленькое значение до нуля. Можно делать это из кода игры, но в Godot эта фича встроена в InputMap (action_get_deadzone и action_set_deadzone).
В идеале нужно было бы проверить, какие события от ОС получает Godot, прежде чем преобразует в информацию внутри классов Input/InputEvent. Кажется, для этого нужно писать свой собственный геймлуп? Там вроде любые события ОС можно обрабатывать.
>Нужно print(event.as_text())
Не нужно (но всё-таки я сейчас это сделал). Во время отпускания кнопки не происходит вообще никакого ивента, принт не вызывается.
>Могу предположить, что если твой геймпад действительно не генерирует события отпускания клавиш, эмуляторы могут учитывать тот факт, что пользователь вряд ли будет нажимать одновременно слишком много клавиш,
Вот, кстати, Годо именно так себя ведёт. Нажимаю крест вправо, принтит ивент. Отпускаю - молчание. Нажимаю влево - принтит сразу два ивента: влево нажато, вправо отпущено. Отпускаю влево - принтит, что влево отпущено. Если нажимаю влево без запавшего права - принтит только левое нажатие. То же самое с верхом и низом, низ западает, верх его сбрасывает.
Эмуль ведёт себя не так, он вовремя понимает, что кнопка отпущена. Персонаж останавливается сразу же, как только отпускаю крест.
Ну и jstest-gtk в реальном времени отображает, что куда нажато, тут уж точно без ошибок. Только что попробовал консольный jstest - все нажатия показывает вовремя.
Для линуксоидов. Пользуйтесь:
jstest --event /dev/input/js0
где js0 - это джой. У меня на убунте поставилось из родных реп впесте с gtk-гуём, который, в общем-то, показывает всё то же самое.
>Если разберёшься, почему у тебя геймпад неправильно работает, отпишешься в треде?
Естественно. Бесит на форумах, когда "проблема решена", а решение нигде не описано.
Быстрый набросок текстовой игры с картинками...
Слова взял с fishtext.ru, раздел "о сайте".
Вот это почитай, вдруг поможет: https://github.com/godotengine/godot/pull/42800
сап годотач, зачем нужен рижид бади 2д с коллижн шейпом в нем, а не просто колижн шейп?
Коллижн шейп - "виртуальная" обертка над шейпом в редакторе движка. А шейп - ресурс, а не нода. Если у тебя много рижид бади одной формы, они все будут ссылаться на один и тот же ресурс для экономии, но находиться в разных позициях, обладать разной скоростью и т.д.
Алсо, если я не так понял твой вопрос, то с точки зрения ООП, рижидбади это больше, чем коллижн, это же еще и масса, трение, упомянутые скорость и т.д.
чуваки, еще вопрос: как присвоить вектору2д кастомное значение, типо velocity = {1, 1}. у векторов в гдскрипт есть литерал?
спасибо за ответ, бро ;)
а все бля, извините за тупой вопрос
velocity = Vector2(1, 1)
литерала, вроде нет.
видимо я отвык от ООП и забыл что у классов есть конструкторы
Да я и сам уже привык к языкам где есть автовывод типа из инициализатора.
чзх почему я часто не могу поменять свойства, находясь в AnimationPlayer?
перезапустил редактор - заработало нормально
Дополню его ответ: кроме RigidBody, есть ещё StaticBody, KinematicBody и Area, а ещё все эти ноды могут принимать в себя множество CollisionShape, и редактировать каждый из CollisionShape через дерево сцены банально проще, чем если бы в инспекторе нод был бы массив Shape. Хотя, чисто теоретически, ничто не мешает сделать через инспектор, наверное, просто с самого начала сделали через дерево сцены и потом не меняли (иначе это будут breaking changes в API и заставит пользователей переучиваться). В любом случае, от CollisionShape не такая большая нагрузка, чтобы от него отказываться (в большинстве инди-игр). А если тебя волнует нагрузка, можешь создавать шейпы напрямую на сервере физики, загружая из файлов или процедурно генерируя.
>автовывод типа из инициализатора
Но ведь в GDScript есть [] и {}, можно было бы сделать такое и для векторов, автоматически определяя размер и тип (в 4.0 добавили целочисленные векторы). Или лучше не надо? По-моему, автоопределение опасно, т.к. результат операции не очевиден из кода.
>часто не могу поменять свойства, находясь в AnimationPlayer
А ты менял его положение в дереве сцены? При перемещении этой ноды у неё может сломаться путь до корневой ноды, относительно которого вычисляются внутренние пути до всех свойств. Я один раз так сломал эту ноду, что пришлось с нуля всё создавать - даже перезапуск редактора не помогал (или я запаниковал).
>А ты менял его положение в дереве сцены? При перемещении этой >ноды у неё может сломаться путь до корневой ноды, относительно >которого вычисляются внутренние пути до всех свойств. Я один раз так >сломал эту ноду, что пришлось с нуля всё создавать - даже перезапуск >редактора не помогал (или я запаниковал).
оказывается, Годо не такой "лайтовый", каким его представляют
Какая связь?
просто озвучил свою личную мысль
Паника это от незнания. Не надо забывать что, во-первых, пути в анимплеере редактируются, во-вторых, даже если нет, tscn это текстовый файл где можно все посмотреть самому глазами.
>не такой "лайтовый", каким его представляют
Что ты имеешь в виду? Там какая-то ошибка с путями была, не помню точно. В другом движке тебе пришлось бы создавать весь проект с нуля, а здесь всего лишь удалить ноду и вставить новую.
>tscn это текстовый файл где можно все посмотреть самому глазами
Вот я и посмотрел. Обнаружил какую-то фигню в путях, которой быть не должно было. Попытался поправить вручную, в tscn. Кажется, исправление tscn и последующая перезагрузка редактора возвращали ошибку на место. Пошёл гуглить, в чём проблема с путями в AnimationPlayer и почему ошибка возвращается на место после исправления. Ничего полезного нагуглить не удалось, всё либо старое, либо не то. Помучился ещё какое-то время, редактируя вручную и так, и сяк, потом плюнул, удалил ноду, создал заново и всё волшебным образом починилось.
Если не ошибаюсь, проблема была не просто из-за перемещения в дереве, а при копировании из сцены в одной вкладке в сцену в другой вкладке... Я тогда делал несколько похожих, но отдельных анимаций, и мне нужно было несколько копий AnimationPlayer в разных сценах. Не было проблемой создать с нуля, но я привык, что если нужно больше одной штуки, то создаю одну и остальные добавляю копипастом. Жаль, что с копипастом и хоткеями в Godot столько проблем( Хотя это вообще какая-то болезнь опенсурса, вечно в Windows хоткеи неправильно работают (или не так, как должны работать с точки зрения Windows-пользователя - опыт использования Linux показал, что в нём неправильные хоткеи повсюду).
>при копировании из сцены в одной вкладке в сцену в другой вкладке
Штатный механизм это Merge from scene. А копипаст они не так давно прикрутили, емнип там просто создается временный файл, куда дампается поддерево которое копируешь.
>Merge from scene
Неочевидное название неочевидной функции. Merge - "слияние" или "поглощение". Мне нужно было сливать или поглощать сцены, мне нужна была независимая копия. Ещё и конка выглядит как пересечение двух линий, т.е. как будто сцены повлияют друг на друга взаимно, а не одна войдёт в другую (как копия, как ссылка или как вырезать-вставить?).
>создается временный файл
Не уверен в этом, т.к. удаление исходной ноды обнуляет буфер обмена. Как минимум при работе с ресурсами. Вот буквально этой ночью пытался скопировать Shape из одного CollisionShape в другой CollisionShape: нажал Copy на Shape, затем удалил его CollisionShape и нажал Paste на поле Shape другого CollisionShape... и-и-и ничего не произошло, WTF? Логично предположить, что Copy сохраняет полную копию ноды/ресурса в буфере обмена, а не держит ссылку на то, что может измениться или вовсе исчезнуть в процессе копирования.
Не, ладно, с ресурсами понятна причина такого поведения: Copy копирует не данные ресурса, а ссылку на ресурс, и если мы удалили ноду, которая была единственным владельцем ресурса, движок удаляет этот ресурс. Но если я нажал Copy, я ожидаю, что ресурс не исчезнет из памяти прежде, чем я смогу вставить его, верно? Пусть у него больше нет пользователей, я собираюсь дать ему нового пользователя, а он берёт и исчезает. Непорядок.
Я уж молчу про логику функции отмены на ctrl+z, о которой лучше вообще забыть...
>Это что за покемон?
Ну что же вы, ребята? Это же самолёт!
Первым делом, первым делом - самолёты...
Никак не могу понять, почему управление такое дубовое, а самолёт ведёт себя так, будто летит сквозь мёд? Как он у меня работает: каждая деталь создаёт силу, зависящую от скорости и направления движения, которую я добавляю к RigidBody в _integrate_forces() через add_force(). Вроде бы удалось настроить так, что самолёт реагирует на нажатия клавиш примерно так, как самолёты в ГТА, но вот в свободном полёте и свободном падении летит как кирпич, то есть вообще не вращается. Сопротивление воздуха я не моделировал, но разве дело может быть только в этом? Типа, сопротивление воздуха заставляет ИРЛ самолёт мотыляться, менять направление и уходить в штопор? Или кроме сопротивления понадобится ещё и потоки воздуха моделировать? Подъёмную силу крыла, мне кажется, я достаточно точно смоделировал - чем быстрее крыло движется в направлении "вперёд", тем сильнее тяга "вверх" относительно плоскости крыла. Думаю, сопротивление воздуха должно быть несложно смоделировать, если теперь посчитать направление в сторону плоскости крыла (сверху или снизу) - чем более плашмя летит крыло, тем больше замедление от него. Но если все крылья в одной плоскости и возле центра тяжести, в чём смысл? Это ведь не будет закручивать самолёт, а только быстрее замедлять его. По идее получится тот же полёт в меду, только в более густом.
После записи этих видео я ещё покопался, обнаружил, что у меня один из векторов хвостового оперения направлен в противоположном нужному направлении, из-за чего, видимо, самолёт наклонялся в полёте, вроде как исправил это и, тем самым, окончательно сломал управление - теперь у меня есть ровно летящий и неуправляемый кирпич. Что за хрень?.. Как же тяжело работать вслепую. Вот бы отобразить все эти векторы в реальном игровом пространстве, а не только воображать...
А ещё я занимаюсь какой-то лишней фигнёй вместо того, что изначально хотел. Но самолётик было понятно из чего собрать - сел и за пару часов сделал с нуля, а изначальные идеи спустя много лет яснее не стали... Ну, типа, я хочу ИИ, но что ИИ должен делать? Что он может делать? Что я должен сделать, чтобы ИИ было что делать? Что я хочу, чтобы ИИ мог делать? У меня же только абстрактные мысли, без конкретики. А самолёт - он и в Африке самолёт, сел и полетел, тут думать не нужно вообще...
>самолёты в ГТА
Кстати, давно интересовало, с чем связано то, что при попытке полёта строго вверх двигатели самолётов в ГТА рано или поздно "давятся" и перестают работать, вызывая резкое снижение скорости и падение. В более серьёзных играх, вроде, аналогичное поведение. Но мой самолёт может без проблем лететь вертикально вверх бесконечно долго, потому что мощности двигателей хватает на то, чтобы преодолеть силу тяжести, а плотность воздуха не моделируется (представим, что вместо пропеллеров у меня ракетные двигатели). Если я снижаю мощность двигателей, чтобы нельзя было тупо лететь вверх вообще без крыльев, тогда самолёт становится слишком медленным, даже не может оторваться от земли. Если при этом усилить подъёмную силу крыльев - он взлетает как пёрышко и летит дальше медленно-медленно. По-моему, есть и такие ИРЛ самолёты (медленные и взлетающие почти без разбега), но в играх-то по-другому. Ну и как это понимать? Как в аркадной ГТА добились такого реализма, не могут же там честно моделировать все законы физики? Или там тупо подгон значений и вместо условного RigidBody - KinematicBody, который анимируется из кода? Не хочу моделировать физику вручную через KinematicBody...
>отобразить все эти векторы в реальном игровом пространстве
Вспомнил, что можно включить отображение RayCast, так что отобразить векторы стандартными средствами достаточно просто. Непросто понять, в какой они системе координат должны быть, а это главный вопрос, который постоянно мучает меня во всех расчётах...
Идея сделать самолёт возникла, когда я попытался полетать на самолёте в Unturned. Кусок летающего кирпича, взрывающийся от лёгкого касания. Ну, у меня получилось не сильно лучше, лол. Но в своей собственной игре я могу сделать управление более отзывчивым, настроить всё под себя - ну и зачем играть в чужие игры?.. Godot - лучшая игра.
Если ты не симулируешь крыло, ты симулируешь ракету, поэтому и летишь. Даже если у тебя аркадный сим, есть два режима, когда крыло работает и ты летишь, и когда не работает и самолет свалился, хаотично вращается, на крыле только турбулентность, нет обтекающего потока. Из сваливания может перейти в режим полета, например падая какое-то время и набрав достаточную скорость, а может и не перейти и в штопоре падать до земли.
Алсо, кроме плотности, с высотой меняется процентное содержание кислорода в воздухе, что приводит к падению мощности двигателя (что внутреннего сгорания, что реактивного), вплоть до заглохшего. А еще, в легкомоторной авиации карбюраторные двигатели, так что они вообще глохнут при определенном задирании носа. Все это можно симулировать довольно абстрактно, даже не залезая в точную симуляцию.
>Если ты не симулируешь крыло
Говорю же, я учитываю подъёмную силу. Без неё самолёт вообще от земли не открывается. Хотя... Заметил момент, что тяжело оторваться от земли, а вот лететь нормально. Возможно, реально движки вытягивают массу аки ракета, а крылья только меняют направление: поднял нос - взлетел. Но тогда я вообще без понятия, как скорость набирать, если не делать из двигателей ракеты. Это же будет медленно... как в Ил-2 Штурмовик, очень тяжело было там взлетать. Хотя стоп, так и должно быть, я просто симулировал медленный взлёт медленной раскруткой, а должен был медленно набирать скорость на максимальной мощности двигателя. Теперь понятно, нужно попробовать переделать.
>когда крыло работает и ты летишь, и когда не работает
Даже аркадной физике нужны правила перехода из одного состояния в другое. Я вот не понимаю, как крыло может не работать, если воздух стоячий и нет абсолютно никаких потоков. Симулировать потоки воздуха накладно, так что же, остаётся только рандом?
>процентное содержание кислорода в воздухе
Не задумывался об этом, спасибо.
>карбюраторные двигатели, так что они вообще глохнут при определенном задирании носа
О, вот это точно оно. В ГТА как раз потеря мощности наблюдается, если сильно задрать нос легкомоторного самолёта. Долго не мог понять, почему так, но никогда не задумывался, а может ли двигатель работать в таком положении... У меня слишком абстрактное восприятие двигателя как того, что двигает что-то в заданном направлении, лол.
>я учитываю подъёмную силу
Это надо разбираться, как ты там ее учитываешь. Сейчас не могу переключаться на это, по крайней мере не раньше чем через неделю.
Как минимум, надо учесть, что подъемная сила зависит от вектора набегающего потока воздуха. То есть, угол надо считать не относительно того, куда смотрит нос самолета, а туда, куда он летит.
Пример - лодка может плыть горизонтально, а может скользить задрав нос градусов на 30, но в обоих случаях она движется вперед относительно озера, а сопротивление и подъемные силы разные.
К тому же, подъемная сила нелинейная, хотя она похожа на линейную до участка сваливания.
>Заметил момент, что тяжело оторваться от земли
Для взлета на самолетах ставят закрылки (flaps), без них действительно взлет становится унылым и нужны многокилометровые полосы. Если упростить модель, то с выпущенными закрылками у тебя другое крыло, с бОльшим лобовым сопротивлением, (поэтому не подходит для крейсерского полета) но увеличенной подъемной силой, да еще и как бы установленное под другим углом к корпусу. На последнем пике провел зеленую линию чтобы было понятно о чем речь.
>Даже аркадной физике нужны правила перехода из одного состояния в другое. Я вот не понимаю, как крыло может не работать, если воздух стоячий и нет абсолютно никаких потоков.
Физика потоков такова, по крайней мере в модели, что летящее со скоростью V крыло в стоячем воздухе - это то же самое, что стоящее на месте крыло, обдуваемое потоком воздуха со скоростью V. А не работать крыло начинает при срыве, когда не хватает подъемной силы по сравнению с гравитацией и лобовым сопротивлением и т.д. В серьезных симуляторах еще крыло может создать "тень", не давай попадать потоку воздуха на плоскости рулей, отчего управление теряется.
В аркадном не надо симулировать потоки, надо просто симулировать, что после какого-то сочетания угла атаки крыла и скорости потока, поток срывается.
>Долго не мог понять, почему так, но никогда не задумывался, а может ли двигатель работать в таком положении
Помню батины "Жигули" не могли заехать даже на небольшую горку, глохли, толкали руками.
В gdscript можно написать класс, не привязанный к годотовским объектам? Например просто какую-то структуру данных хочу написать или целую библиотеку.
Если не писать extends то вроде ничего и не наследуешь.
Или наследуйся от Reference
>В gdscript можно написать класс, не привязанный к годотовским объектам?
Нет, это невозможно.
>структуру данных хочу написать
Наследуйся от Resource. Получишь кучу бонусов.
Подробнее:
https://docs.godotengine.org/en/stable/tutorials/best_practices/node_alternatives.html
https://docs.godotengine.org/en/stable/tutorials/scripting/resources.html
>целую библиотеку
Библиотеку чего? Функций для своих задач? Наследуйся от Reference или от Object, функции можешь обозначать static, если им не нужно задействовать какие-либо переменные класса - static func можно вызывать, не создавая экземпляр класса, пример:
class_name MyUtils extends Object
static func get_something() -> ...
Использование:
var something := MyUtils.get_something()
>Если не писать extends то вроде ничего и не наследуешь.
Нет, если не писать, то неявно наследуешься от Reference, если не ошибаюсь. Читал где-то, что Object немного багнутый и им трудно управлять (нужно явным образом очищать память после того, как он больше не нужен), поэтому предок по умолчанию Reference.
В Паскале базовый предок называется TObject:
https://www.freepascal.org/docs-html/rtl/system/tobject.html
>TObject is the parent root class for all classes in Object Pascal. If a class has no parent class explicitly declared, it is dependent on TObject. TObject introduces class methods that deal with the class' type information, and contains all necessary methods to create an instance at runtime, and to dispatch messages to the correct method (both string and integer messages).
Так что это не какое-то необычное явление, в ООП нет смысла от "пустых" классов вообще без всего.
Хочу портировать свою самописно-велосипедную игру на годот. Ну и задумка такая, что игра должна быть как самостоятельная система объектов, а годот дает ей ввод, обновляет, потом читает ее состояние и отрисовывает.
>подъемная сила зависит от вектора набегающего потока воздуха. То есть, угол надо считать не относительно того, куда смотрит нос самолета, а туда, куда он летит.
Да знаю я это. Ещё в детстве интересовался формой крыльев и почему возникает подъёмная сила. Можно свернуть лист бумаги и ощутить подъёмную силу лично, держа его перед вентилятором. Примитивное крыло и будет таким изогнутым листом без каких-либо наворотов.
А формулы у меня такие:
>velocity = state.linear_velocity
>speed = velocity.length()
>var forward: Vector3 = -global_transform.basis.z
>var alignment: float = forward.normalized().dot(velocity.normalized())
>var velocity_factor = speed ★ alignment
>state.add_force(wing.get_force(velocity_factor), wing.global_transform.origin - global_transform.origin)
У крыла:
>return global_transform.basis.y ★ velocity_factor ★ (base_uplift_power + (здесь управляющие плоскости))
Объясняю: alignment меняется от 1 до -1 в зависимости от того, насколько соответствует вектор движения положению самолёта. Если самолёт движется носом вперёд, будет 1, если боком 0, если задом наперёд -1 (пока решил не рассматривать этот случай). Далее это значение умножается на скорость и получаем зависимость от 0 до текущей скорости относительно стоячего воздуха/земли. Этот коэффициент попадает в формулу рассчёта силы тяги и соответственно меняет её от 0 при отсутствии скорости или движении боком до максимальной при максимальной скорости одновременно с движением строго вперёд. Это всё не учитывает сопротивление воздуха, т.е. как если бы мы летели в вакууме (лол).
>Для взлета на самолетах ставят закрылки
Да, я это знаю. Но у примитивного самолёта может не быть всех этих примочек. Мы как раз обсуждаем примитивную модель примитивного самолёта в идеальной среде. И почему она чувствуется как будто воздух вязкий, хотя никакого воздуха в вычислениях вообще нет.
>что после какого-то сочетания угла атаки крыла и скорости потока, поток срывается
Так я ж уже говорил, что я учитываю направление движения и соответственно убавляю подъёмную силу вплоть до нуля, этого должно быть достаточно... И мне казалось, что это очевидно, что самолёт не может лететь боком, потому что крыло работает за счёт формы сечения. Поэтому сразу начал с .dot() и векторов направления.
>батины "Жигули"
Это бензиновый двигатель, а я с детства возился с электрическими - им без разницы, в каком направлении находиться. Поэтому при слове "двигатель" у меня ассоциация с движением в произвольном направлении без каких-либо ограничений со стороны двигателя - что ему будет-то, пара катушек да магнитики.
>игра должна быть как самостоятельная система объектов, а годот дает ей ввод, обновляет, потом читает ее состояние и отрисовывает
Всё так и есть. Только эти самостоятельные объекты - это ноды в дереве сцены. Некоторые ноды имеют своё собственное поведение (как RigidBody, Button и т.п.), а некоторым ты пишешь своё собственное поведение, расширяя поведение одной из базовых нод.
Движок посылает каждой ноде со скриптом события _input, _process, _physics_process и другие. В первом ты изучаешь ввод пользователя в момент этого самого ввода, второе событие возникает по мере возможности - оно ограничено частотой кадров или вертикальной синхронизацией, а третье событие возникает с фиксированной частотой, на которой работает физический движок (по умолчанию 60 тиков в секунду, можно изменить). Также у каждой ноды есть свои события и ты даже можешь создавать свои (называются только "сигналы").
"Пустые" классы тебе могут понадобиться только как какие-то контейнеры данных, генераторы данных, менеджеры и т.п. Выбирай базовый класс в зависимости от того, как будешь использовать его в редакторе:
- Reference - создание из кода: MyClass.new();
- Resource - вставка через инспектор нод, сохранение на диск как файл .tres;
- Node - нода в дереве, когда положение скрипта в дереве сцены имеет смысл.
А что за игра? Есть что посмотреть?
>Node - нода в дереве, когда положение скрипта в дереве сцены имеет смысл.
А, точно, ещё Node имеет смысл, когда нужно получать _input, _process или _physics_process непосредственно в коде данного скрипта/класса. Потому что Reference и Resource эти события не получают. Эти события получают только ноды, находящиеся в дереве сцены.
> А что за игра? Есть что посмотреть?
Я скриншоты в своем вк выкладывал, могу сдеанониться. Ну и там ничего особо интересного.
>будто воздух вязкий
>вообще не вращается
>тот же полёт в меду
Решил проблему, которая была у меня уже года два с этим проектом... да почти с самого начала, когда я тестировал физику. У меня в проекте было linear_damp и angular_damp на 0.9 установлено, поэтому вся физика была такой заторможенной. Сбросил на значения по умолчанию (0.1) - и самолёт, и машины стали гонять как бешеные, крутиться и вертеться. Круто. А я всё это время ломал голову, почему у меня такая низкая максимальная скорость и всё выглядит таким заторможенным, динамика движений отсутствовала... Т.е. вообще-то я думал сделать эту игру спокойной и стабильной, но это уж слишком сильное замедление было.
Мотивации сильно прибавилось.
Почему дискорд godot в лгбт флаге, он поддерживает их?
Да, я от них отписался из-за этого. Правда, русервер ничем не лучше, флаг РФ убрал с логотипа и хохлов не банит.
> Хочу портировать свою самописно-велосипедную игру на годот. Ну и задумка такая, что игра должна быть как самостоятельная система объектов, а годот дает ей ввод, обновляет, потом читает ее состояние и отрисовывает.
MVP? MVP!
Твоя игра - модель.
А годот - вид и представление в одном флаконе.
Да. Это возможно. Собсна, как именно, уже описали выше. Пиши классы без наследования и они автоматически унаследуются от обслуживаемого сборщиком мусора класса Reference. Если хочешь собирать мусор сам, как диды кодинга, то наследуйся от Object.
Опиши свою модель тем количеством классов, которое тебе нужно.
Опиши представление нодами и сценами. И скорми представлению свою модель. Всё стандартно. Всё по гайдлайнам и паттернам.
На каком языке она написана изначально? Если на C#/.NET, то ее можно вообще подключить изкоробки, если на C/C++/чем то не очень экзотическом, то подключить через GDNative.
> чем то не очень экзотическом, то подключить через GDNative
Ага, только сначала придётся лично самостоятельно перевести сишные заголовки в формат своего языка. Для си всё шоколадно, годот сам заголовки по запросу выдаёт. Но для "не очень экзотического" языка их нет. И никто этим не занимается. Был один француз на гитхабе и тот много лет назад забил хуй, переведя только жалкий процентик АПИ, лишь бы примитивный скрипт заработал, и на том исчез.
Я говорю конечно же вы догадались, о паскале.
Как работает cell_size для Navigation2d? Я устанавливал разные значения, но так и не понял как связан массив, выдаваемый get_simple_path и cell_size.
Как в документации написано - так и работает. Какой конкретный абзац документации тебе непонятен?
cell_size создает сетку, в которую "округляются" координаты полигонов/мешей навигации. Из гитхаба:
So, assuming cell_size=1, the points like (1.0, 1.0), (1.1, 1.1), (1.3, 1.7) will be mapped to point (1.0, 1.0). In other words - we will treat them as the same point. This way we can reason whether to join the polygons they represent or not.
То есть, оно просто округляет дробные координаты до целочисленных?
На ActionScript
Нет, почему? Он может округлять и до 1.1 и других значений.
Так, все, я допер, почему у меня плохо это работало. Начальные координаты и конечные были не по сетке и потому мне выдавало странные значения, которые не вписываются.
Спасибо за помощь.
Чёт я попробовал систему частиц (ЦПУ и ГПУ) и не понял её смысл. Ну вот вылетают частицы в каком-то направлении и исчезают. И-и-и... что это даст? Если повернуть или передвинуть ноду - все частицы меняют положение вслед за ней. Какого хрена? Я ожидал, что если привязать ноду "источник частиц" к какому-то подвижному предмету, частицы будут висеть неподвижно или двигаться независимо друг от друга по заданным траекториям даже когда нода "источник частиц" улетит в другое место. Условно, вот есть двигатель, привязываем к нему источник дыма - вуаля, теперь за нашим транспортом остаётся поток пердежа из двигателя. Ан нет, этот поток будет двигаться вместе с транспортом, как будто это анимация на прозрачном дисплее, прилепленном к транспорту.
Возникает закономерный вопрос. Что лучше: возиться с системой частиц, каждый кадр меняя её параметры в попытке синхронизации с движением транспорта (или персонажа, например, для капающей крови), или создавать собственный излучатель частиц, который будет создавать, добавлять и менять местами независимые спрайты? Естественно, второй способ будет затратнее по ЦПУ, но первый способ ведь тоже требует непрерывных вычислений на ЦПУ, а вычисления в первом случае сложнее, чем во втором: в первом нужно работать с траекториями, а во втором достаточно заспавнить спрайт в глобальном пространстве и забыть о нём, т.к. он сам будет двигаться.
Я бы провёл сравнительные тесты, но сложность математики в первом случае (возня со встроенной системой частиц) меня как-то пугает.
Но ведь это есть в туториале.
https://docs.godotengine.org/en/stable/tutorials/2d/particle_systems_2d.html#local-coords
Там есть опция, чтобы сделать координаты частиц независимыми от ноды-эмиттера, глобальными. Ищи.
Фух, спасибо, отлегко. Изучал свойства в инспекторе и почему-то не заметил этой опции. Я понимаю, что локальные координаты оптимальнее глобальных, т.к. меньше вычислений, но, имхо, от частиц всё же ожидаешь глобальных позиций - было бы неплохо как-то подсветить в редакторе, мол, не хотели бы вы использовать глобальные вместо локальных? Локальные подойдут разве что для неподвижного костра на земле или факела на стене, для всего остального нужны глобальные... Легко проверить, когда пользователь подключает частицы к RigidBody (или к его потомкам).
>анонимусы
>сидят в соцсети дристкод
Позорите честное имя анонимуса...
>Опиши свою модель тем количеством классов, которое тебе нужно. Опиши представление нодами и сценами. И скорми представлению свою модель.
Не вижу смысла так сильно всё разделять. У тебя в любом случае должны быть ноды-модели в дереве сцены, если ты хочешь органично связать сцены с моделью и тем более воспользоваться неудобствами инспектора нод. Модель куда удобнее настраивать через инспектор и подключаемые ресурсы, чем ковыряться в исходном коде. Декларативный подход >>> императивный.
>перевести сишные заголовки в формат своего языка
>жалкий процентик АПИ
>паскале
Чё ты ноешь, а? Самый первый Паскаль создавался как учебный язык - упрощённый Си, потому что оригинальный Си изучать с нуля сложно. Так что это близкородственные языки, несмотря на разницу в синтаксисе и работе с памятью. Берёшь эти свои заголовки и переводишь их на Паскаль - быстро, решительно. Вот создать ООП обёртку будет не так тривиально, тут думать придётся. Я думал этим заняться, но мне как-то что-то лень, после быдлокодинга на GDScript'е-то.
>ActionScript
Земля тебе векторной графикой, товарищ.
Пробовал аналоги флеша? Они совместимы?
> Не вижу смысла так сильно всё разделять.
Причём тут разделение? У него готовая игра на другом движке/языке. Чтобы её портировать на годот, нужно имеющиеся там классы портировать в годот-классы. Это и есть "нужное количество классов".
> У тебя в любом случае должны быть ноды-модели в дереве сцены
Дерево сцены это механизм репрезентации. Они разумеется будут, но они будут реализовывать только логику репрезентации.
> органично связать сцены с моделью
> Модель куда удобнее настраивать через инспектор
> Декларативный подход
> ковыряться в исходном коде
> императивный
> Декларативный подход >>> императивный.
Декларативность и императивность не могут быть сравниваемы. Декларативность - описание сущностей. Императивность - действия с ранее описанными сущностями.
Таким образом нельзя сравнивать императивный подход к описанию ресурсов в инспекторе и декларативные действия в гдскрипте. С инспектором следует сравнивать описание объектов в ЖСОН, ХМЛ и т.п. языках разметки.
А если анон вместо разделения кода и данных лепит декларатив в гдскрипты - это лично его проблема, но не языка, и не движка.
Здорово гододвачеры, функция _ready вызывается после instance() или add_child() ?
Чет потерял схемку, или ее и не было. Если не путаю, порядок такой
foo.instance()
> foo._init()
> foo.child._init()
scene.add_child(foo)
> foo._enter_tree()
> foo.child._enter_tree()
> foo.child._ready()
> foo._ready()
(И, если не изменяет память, изменение дерева происходит "между" кадрами, т.е. ready может вызваться в следующем кадре после add_child?)
Засунь в каждый колбэк принт и посмотри сам.
>У него готовая игра на другом движке/языке.
Ну тут вопрос ещё, хочет ли он прямо импортировать целые модули игры в Godot через GDNative или собирается писать игру с нуля на GDScript...
>Дерево сцены это механизм репрезентации.
Ой, вот не надо тут. Дерево сцены - это основа игры. Ты можешь сделать игру вообще без каких-либо скрытых в коде сущностей, работая только с нодами сцены. И это хорошо, потому что со скрытыми сущностями сложно работать, сложно делать из них игру.
Разумеется, ты можешь сделать игру в виде скрытой от редактора сцен модели, а в сцене только отображать изменения модели. Но в общем случае это неудобный подход. Ситуации, в которых тебе нужна скрытая модель, редко встречаются в инди играх; обычно это какие-то симуляторы, крутящие в себе сложную модель мира с кучей скрытых от игрока параметров. В большинстве игр (от простых головоломок до ААА-игр типа ГТА) всё существующее в данный момент существует "на экране", а всё остальное выброшено из памяти, чтобы не мешать (как уровни головоломки, так и чанки мира ГТА).
>Декларативность и императивность
Я имел в виду, чтобы вместо каких-то левых файлов (json) настраивать модель через дерево сцены и инспектор нод. Да, в каких-то случаях лучше одно, в каких-то другое. Но ты там высказался так, будто дерево сцены и инспектор нод нужны только чтобы расставить MeshInstance, настроить материалы и забыть о них навсегда, с головой зарывшись в код и какие-то другие файлы. Но это не так, можно настраивать модель через дерево сцены и параметры нод, пользуясь удобствами редактора сцен. В этом главная суть универсального движка уровня Годо, а не только чтобы получить готовые библиотеки рендеринга и физики. Рендеринг и физику можно подключить к коду на любом языке и обойтись без редактора сцен - зачем тогда Годо? Годо (как и юнити, анрил и т.п.) - это, в первую очередь, редактор сцен, а уже потом всё остальное (что можно отключить или заменить, имея исходные коды движка).
ну в общем - реади вызывается после инстанса, а не аддчилда
Заебали выдумывать домыслы. Пять секунд делов, запустить годот и проверить. Нет, блять, будем выдумывать, трактовать буквы в документации, выдавать фантазии за действительность.
Толстишь.
дак у меня реально так получилось
Толстишь.
Му
дак
На самом деле, надо и практика, и теория. Просто запускать и смотреть на результат недостаточно, это магический подход. Чтение документации, и, возможно, исходников, должно принести понимание, почему именно так происходит. (Но, конечно, с учетом того, что документация может быть неактуальной, упрощенной или неточной)
Хотел написать пример из C++, когда при запуске у тебя на компе может быть один результат, а у другого в дебаге/релизе другой. Но вспомнил про пример из прошлого треда про area_entered, который мог прилетать в другом порядке.
Для себя я обычно в голове строю модели из псевдокода, чтобы понимать, какие события могут происходить в каком порядке. Например:
for each in list1:
do_something_1()
for each in list2:
do_something_2()
Это когда точно все события 2 произойдут после всех событий 1
for each in list1_and_2:
do_something_with_random_1_or_2()
А это когда события могут произойти в любом порядке.
> Это когда точно все события 2 произойдут после всех событий 1
Не точно. ЕМНИП именно о такх случаях Хуан говорил, что у него там внутре хитрая оптимизация, что часть кода может быть отложена.
То есть, форыч у тебя отработает по порядку, а вот код из дусамсингов может быть сохранён как указатель на функцию и выполнен позже.
Это все равно можно описать примерно так
#frame
for each in list:
do_something_or_defer()
#inter-frame
for each in deferred_list:
do_something()
goto #frame
Какое ещё готу между фреймами? Ты понимаешь, что такое фрейм ваще? Фрейм отрисовывается видюхой у тебя на дисплее. Ты не можешь вернуться в прошлое к уже отрисованному фрейму.
Это псевдокод, чувак. На дваче неудобно циклы рисовать
while(true)
_do_frame_or_defer()
_do_interframe_deferred()
_while(!vsync) sleep()
Так юзай пастебин.
> неудобно циклы рисовать
пэйстбин, а не пастебин, шут гороховый
мимо умник
GDScript позволяет писать код в одну строку.
>func something(num: int) -> void: if num < 5: something(num + 1); else: for i in x: print(num)
Конечно, это не рекомендуется, но интерпретатор допускает такую запись. Любые команды могут быть записаны на одной строке, если предыдущая заканчивается на ":" или ";", при этом ";" можно не писать, если команда заканчивается переносом строки или комментарием "#".
Если честно, я удивлён, что интерпретатор GDScript разрешает такую запись. Случайно обнаружил.
Не могу понять, get_tree().set_input_as_handled() не работает или я неправильно её использую?
В обработчике gui_input() вызываю эту функцию, но обработчик _unhandled_input() всё равно срабатывает как будто ничего не изменилось.
Мне нужно это чтобы окошко чата позволяло набирать любые символы до нажатия enter, не влияя на персонажа и другие игровые объекты. Конечно, я мог бы сделать костыль с собственными событиями или глобальными флагами, но разве в системе ввода движка нет готового решения на такой случай? В большой игре заблокировать весь ввод для всех систем - сложная задача, учитывая что набор этих систем заранее неизвестен из-за их относительной независимости.
В обработчике gui_input() вызываю эту функцию, но обработчик _unhandled_input() всё равно срабатывает как будто ничего не изменилось.
Мне нужно это чтобы окошко чата позволяло набирать любые символы до нажатия enter, не влияя на персонажа и другие игровые объекты. Конечно, я мог бы сделать костыль с собственными событиями или глобальными флагами, но разве в системе ввода движка нет готового решения на такой случай? В большой игре заблокировать весь ввод для всех систем - сложная задача, учитывая что набор этих систем заранее неизвестен из-за их относительной независимости.
Хз, потестил работает, 3.5.1 и 3.6dev, win10.
А, всё, разобрался. Персонаж у меня двигается в _physics_process, а для блокировки событий мыши нужно растянуть любой контрол на весь экран - события мыши ловятся только когда она пересекает контрол.
Осталось понять, как сообщить персонажу, что он не должен реагировать на WASD в _physics_process...
Я уже спрашивал, но тогда это было чисто теоретически, поэтому я ответ забыл. Короче, если у меня игра двухмерная, но мне нужно, чтобы некоторые объекты были трехмерными - как проще всего этого добиться? Делать все в 3D в ортогональной проекции не хочу, пререндерить в спрайты тоже.
Вот это и связанные страницы читай:
https://docs.godotengine.org/en/stable/tutorials/rendering/viewports.html
Вкратце, ты создаёшь отдельную сцену, в которой есть нода Viewport, в ней есть Camera3D и все трёхмерные объекты, которые тебе нужно отрендерить. Ты настраиваешь Viewport, чтобы там текстура была правильного размера и тому подобное. Потом ты создаёшь обычный 2D спрайт в основной сцене игры, добавляешь к нему описанную выше сцену, создаёшь в поле Texture новую ViewportTexture и в её свойствах указываешь нужный Viewport. Если ты всё правильно настроил, по идее ты уже в редакторе должен увидеть на своей 2D сцене со спрайтами 3D рендер, если этого не происходит - ты где-то накосячил. Также тебе скорее всего потребуется включить опцию прозрачного фона в Viewport, если тебе нужно, чтобы моделька органично вписывалась в мир вокруг неё (иначе будет прямоугольник). Это самый простой способ настройки, не требующий ни строчки кода.
Можно решать задачу другим способом. Скажем, если ты хочешь сэкономить производительность за счёт затрат памяти, ты можешь отрендерить набор спрайтов в начале игры и процедурно создать все необходимые спрайтовые анимации, в результате избавляясь от Viewport и всех 3D объектов в основном геймплее. Чисто теоретически это может оптимизировать игру для слабых устройств, которые плохо переваривают 3D, но увеличит затраты видеопамяти (нужно хранить кучу процедурно созданных спрайтов).
Также, если тебе нужно несколько одинаковых спрайтов, не забывай использовать по возможности одну и ту же ViewportTexture, чтобы не приходилось рендерить одну 3D сцену многократно. А если твоя 3D сцена не имеет никаких анимаций, то можно настроить Viewport на однократный рендер: тогда спрайт отрендерится один раз и больше не будет обновляться, пока ты не запросишь через код. Сам Viewport в таком случае никакой нагрузки не создаёт, потому что это только ООП абстракция над переключением контекста рендеринга видеокарты - пока ты ничего в текстуру не рендеришь, переключения контекста не происходит.
Аналогично Viewport можно использовать для рендеринга 2D (включая GUI) в 3D сцене, для рендеринга 3D в текстуру 3D (пример: зеркало или телевизор), для оптимизации большого количества 2D статичных тайлов/спрайтов (хотя с этим прекрасно справляется TileMap - изобретать велосипед не обязательно).
сап гододвач, проблема такая: не работает animated sprite при добавлении его в ноду эддчайлдом. если добавлять его в самую базовую ноду (world), то все нормально. когда добавляю аниматед сприте в ноду "Enemy", то не работает - тоесть вообще на экране не появляется, хотя в аутпуте пишет "animation finished" (я в обработчкие сигнала прописал чтоб он это выводил в аутпут)
на пикрилэйтеде - вкладка ноды "HitEffect"
делаю по гайду ХартБиста, но этот хитэффект сам слепил
HitEffect.gd:
https://pastebin.com/QyWZ38hp
Bat.gd:
https://pastebin.com/jc7TF0ic
на пикрилэйтеде - вкладка ноды "HitEffect"
делаю по гайду ХартБиста, но этот хитэффект сам слепил
HitEffect.gd:
https://pastebin.com/QyWZ38hp
Bat.gd:
https://pastebin.com/jc7TF0ic
ложная тревога: я убрал effect.global_position = self.global_position и все путем стало
Анон тебе выше написал уже, рендеришь 3д во Viewport, а его - в ViewportTexture спрайта, контрола
Или вообще сейчас можно кинуть ViewportContainer и его чайлдом Viewport.
Дальше надо осознать, что 2д и 3д мир в сцене существуют одновременно. А значит, можно элементарно синхронизировать x,y и x,z координаты, например, камеры. В моей демке по 2д тайлмапу строится 3д гридмап коллайдеров, кубик полностью 3д с физикой, враги и игрок рисуются 2д спрайтами, но имют также коллайдер 3д, взрывы обнаруживаются в 3д, но рисуются 2д кругами и т.д.
добавлю что есть демка https://godotengine.org/asset-library/asset/128
>Делать все в 3D в ортогональной проекции не хочу
Посмотри в соседнем треде катабазис вроде бы так делает. В конце концов, можно в 3д рендерить билборды, хех.
Наверное, можно и еще что-то придумать. Например, считать проекции самому, как в старых играх на 2д приставках.
>effect.global_position = self.global_position
>add_child(effect)
Если не ошибаюсь, нода хранит только локальные координаты, которые зависят от положения в дереве. Если у ноды была координата (0;0), она будет в точке (0;0) локальной системы координат ноды-родителя, т.е. её глобальные координаты будут совпадать с глобальными координатами родителя. Если у ноды была координата (N;M), то её глобальные координаты будут (X+N;Y+M), где (X;Y) - глобальные координаты нового родителя. Присвоение значения свойству "глобальные координаты" вроде как не сохраняет значение, только вызывает перерасчёт локальных координат ноды.
Проще говоря, ты не видел эффект на экране, потому что он был далеко за пределами экрана.
Если тебе нужно сместить ноду эффекта в глобальных координатах, лучше всего это делать после вызова add_child(), тогда все вычисления будут уже относительно нового родителя ноды.
И в обратную сторону оно работает. Еслу нужно слишком длинную строку разбить в любом месте, и чтобы интерпретатор разрешил, то конец строки это невидимый символ, мы просто экранируем его слешем \ и всё, теперь следующая строка воспринимается как предыдущая.
Я так приучаю себя к новому синтаксису четвёрки, работая в трёшке, например:
> onready \
> var foo := "bar"
Потом будет легко удалить слеш и добавить собачку.
> Осталось понять, как сообщить персонажу, что он не должен реагировать на WASD в _physics_process...
Стейт-машиной. Добавить стейт waiting_gamer и переходить в него, когда игрок вызывает ГУЙ и возвращаться к предыдущему, когда игрой выключает ГУЙ. А в этом стейте стало быть, персонаж на инпут не реагирует.
Бамп контентом!
https://www.youtube.com/watch?v=UAS_pUTFA7o
https://www.youtube.com/watch?v=UAS_pUTFA7o
Нда, геймдев превратился чисто в рисовай.
Да вроде и с геймплеем все нормально.
рады ждать тебя в рогалик комунити
Дрочат на графон с тех пор, как libtcod появился.
в либтикоде нет графона же
Ну зашел я в годо докс, что дальше? Приведенные статьи во вкладке "Tutorials" - это просто набор несвязных между собой туториалов по определенным темам или их следует читать все по порядку как спланированный курс?
крче мой вопрос - фигня полная, без зазрения совести хуесосте меня
Не хуйня.
Вопрос весьма актуальный. Вот и гдквест его недавно поднял:
https://www.youtube.com/watch?v=yQZKXdwyh-Q
Короче, русским языком ответ:
1. Чтобы вкатиться в кодинг, начинать следует не с игор. Начинай с обычных оконных приложений и отточи знания ООП и ПАТТЕРНов до уровня мидла.
2. В игорах кодинг не главное, главное - арт. Без арта у тебя будет не игорь, а оконное приложение. Да ещё и хуёвое, если п.1. не выполнен.
Привет годаны!
У меня там в соседнем треде забурлили наполеоновские идеи в голове.
Вот скажи, анон, хотел бы ты иметь инструмент, позволяющий построить из твоего кода визуальное дерево, которое ты смог бы проанализировать на баги, и кроме того, визуальное дерево затем выгрузить в другой язык из поддерживаемых движком? ГДСкрипт в шарп или в кресты, и обратно.
Вот пост
У меня там в соседнем треде забурлили наполеоновские идеи в голове.
Вот скажи, анон, хотел бы ты иметь инструмент, позволяющий построить из твоего кода визуальное дерево, которое ты смог бы проанализировать на баги, и кроме того, визуальное дерево затем выгрузить в другой язык из поддерживаемых движком? ГДСкрипт в шарп или в кресты, и обратно.
Вот пост
Там есть туториал на игру (Your first 2d game - Dodge the Creeps)
Также есть туториал 3д шутера, который с 3.3 не обновляли
https://docs.godotengine.org/en/3.3/tutorials/3d/fps_tutorial/index.html
Остальные туториалы несвязные, но тематические. Пилишь ГУЙ - читаешь все про гуй, пилишь физику - читаешь про физику, математику и т.д
>Без арта у тебя будет не игорь
Ясно, Roguelike'и, baba is you, undertale - не игры, а оконные приложения.
>Чтобы вкатиться в кодинг, начинать следует не с игор
Категорически не согласен. Чтобы вкатиться в кодинг, надо начинать с того, что тебе интересно. Может даже и с игор, но простеньких для начала.
Конечно, зависит от усидчивости и самодисциплины, но всё же в общем случае, если заниматься какой-то там не интересной тебе оконной хуетой, мотивация быстро упадёт.
> не игры
При кажущейся простоте, пиксель-арт сложнее классического "пейнт"-арта. Доказательство очень простое: возьми и нарисуй пиксельного персонажа уровня андертейл так, чтобы в пиксель треде тебя на засрали. Слабо? Слабо.
Я раньше тоже так думал, а мотом мне обеснили, что у меня имелось когнитивное искажение https://ru.wikipedia.org/wiki/Проклятие_знания , которое выражалось в данном случае в том, что я знаю базу кодинга и мне трудно понять что бывают люди, которые не владеют той базой и не могут её применять, которые не понимают смысла простейших программных примитивов, типа циклов или условий, или переменных с указателями.
И вот в общем случае мной вчерашним и тобой сегодняшним, для новичка предлагается без задней мысли сесть и делать простенькие игры. Просто сядь и сделай тетрис, говорим мы ему. Хули там сложного?
Массивы, битовые сравнения, рекурсивные функции
Во-первых, ты ловко проигнорировал роуглайки, которые имеют ascii графику.
Во-вторых, я не мастер, но сносный писельный графен рисую. Это дельтарун уже прилично выглядит, а андертейл та ещё кривота. А в пикселячи, при желании, что угодно засрут как и в любых других тредах
Не годан, но мимопроходил.
Это ты сейчас, случайно, не визуальное программирование изобрел? Как blueprints в анриале или bolt в юньке. Оно ведь и так в годоте есть пока.
>1. Чтобы вкатиться в кодинг, начинать следует не с игор. Начинай с обычных оконных приложений и отточи знания ООП и ПАТТЕРНов до уровня мидла.
Начинать нужно с того, что тебе интересно и где ты собираешься работать. У каждой сферы своя специфика и стек технологий.
>2. В игорах кодинг не главное, главное - арт. Без арта у тебя будет не игорь, а оконное приложение. Да ещё и хуёвое, если п.1. не выполнен.
Полный бред. В играх в той или иной степени важно все. Арт без кода - всего лишь картинки или 3д-модели, которые даже не всегда можно посмотреть простому смертному. Код без арта - просто какая-то херь, которая на фоне что-то делает, а ты даже понять не можешь, делает она что-то или нет. Но даже пиздатый арт и гениальный код вместе не сделают игру. Геймдизайн еще никто не отменял. Хотя без кода и арта даже крутой геймдизайн - просто маняфантазии.
> изобрел?
Не изобрёл.
> мимопроходил
Потому ты и не знаешь, мы тут долго обсуждали недостатки визуального проектирования нодами слева-направо. Они неудобны даже не широком экране. Потому что код очень быстро разрастается в ширину и становится неудобочитаем.
Идеальным вариантом было бы создание визуального кода у которого поток выполнения рисуется сверху вниз, а поток вычисления выражений рисуется слева направо. Как в текстовом коде. Тогда бы код стал реально удобен в восприятии.
Пока что только скрэтч-снэп болше всего подходит под эту парадигму. Но тоже не полностью. Чтобы он подходил полностью, у блоков-операторов слоты должны быть слева направо ориентированы. Слева и справа входы, а сам блок - выход. Подробности (со скринами, нарисованными в инкскейпе) я расписал в скретч-треде.
Кто пишет данные в JSON и испытывает трудности как я, зацените, что я нашёл:
https://hjson.github.io/ - значительно упрощает запись в JSON.
Нашёл через обсуждение поддержки YAML в Godot. Правильно сделали, что отказались от поддержки YAML - это какой-то жуткий монстр с неочевидным синтаксисом. JSON лучше, потому что намного проще, а недостатки (кавычки, запятые, комментарии и т.п.) можно решить с помощью Hjson.
>Стейт-машиной. Добавить стейт waiting_gamer
А зачем конечный автомат для этого? Что он даст?
У меня примерно так сделано:
>var input_disabled: bool = false setget set_input_disabled
>func set_input_disabled(new_state: bool) -> void:
>_ input_disabled = new_state
>_ camera.frozen = input_disabled
Конечный автомат для анимаций и действий персонажа, конечно, потребуется рано или поздно, но конкретно для отключения всего управления с клавиатуры не вижу смысла в отдельном состоянии персонажа.
Допустим, если персонаж валяется в состоянии рэгдолла, блокировать управление не нужно, но персонаж не будет на него реагировать. А если игрок переключается на меню без паузы игры, персонаж не должен переходить в отдельное состояние - он только теряет управление. Персонаж продолжит заниматься тем, чем занимался, даже если игрок им не управляет - т.е. состояние не изменится, логично? Конечно, можно переводить персонажа в состояние idle, когда он теряет управление с клавиатуры, чтобы он не продолжал делать действие, которое делал, но это концептуально отдельное состояние, потому что в нём персонаж может пребывать, когда ввод с клавиатуры возможен, но не производится.
Можно сделать walk -> idle -> input_disabled, но что, если нужно одновременно walk и input_disabled - вводить новое состояние walk_input_disabled? Алсо, это потребует создания дополнительных связей и состояний, чтобы игрок мог открыть меню в разных длительных состояниях, например, когда персонаж лезет по вертикальной лестнице: climb_stairs -> climb_stairs_idle -> climb_stairs_input_disabled что ли?
>Начинай с обычных оконных приложений
>не владеют той базой
>не понимают смысла простейших программных примитивов
>Просто сядь и сделай тетрис, говорим мы ему
>Массивы, битовые сравнения, рекурсивные функции
Какое отношение это всё имеет к "обычным оконным приложениям"? Ты хоть понимаешь, что оконные приложения - это отдельная большая тема, сравнимая по сложности с играми? Простой игре GUI вообще не нужен (можно сразу погружать в геймплей без надписей и кнопок), а "обычное оконное приложение" может иметь настолько сложный гуй, который многомиллионным ААА играм и во сне не снился. Тем более если этот GUI построен на базе WinAPI или какого-нибудь фреймворка, никак не используемого в игровых движках.
Алсо, раз ты считаешь нужным изучать "обычные оконные приложения", то в Godot можно изучать и делать их с помощью встроенного GUI фреймворка (ноды-потомки Control). Вопрос в том, нужно ли тебе это делать, если ты можешь освоить все базовые принципы через консоль (print() в Godot)? А для совсем маленьких есть игры про программирование...
>Может даже и с игор, но простеньких для начала.
Двачую, простую игру можно сделать с помощью консольного ввода-вывода, и это часто разбирают в учебниках по программированию (пример игры: "угадай число").
> А зачем конечный автомат для этого? Что он даст?
Точность в определении состояния объекта.
А то что ты ниже привёл это банальный флаг, хоть и с сетгетом, но это всё ещё флаг. КА нужны как раз, чтобы от ебли с флагами уйти, но я вижу, тебя не переубедить, чтож, ебись с флагами.
> если ты можешь освоить все базовые принципы
Я - то могу, и уже освоил задолго до годота. Речь о воображаемом ньюфаге, который не освоил, а лезет делать свой асасинс крид, не меньше. А не какие-то там угодайки в консоли.
>недостатки визуального проектирования нодами слева-направо. Они неудобны даже не широком экране. Потому что код очень быстро разрастается в ширину и становится неудобочитаем.
Это неправда, главный недостаток такого подхода - отсутствие конструкций высокого уровня абстракции. Конечно, если ты операцию сложения отображаешь одной нодой и каждое число для неё тоже отдельной нодой, то в результате у тебя будет огромная лапша. А вот если бы ты передавал сложные высокоуровневые конструкции другим сложным высокоуровневым конструкциям, у тебя бы в результате были бы компактные схемы даже для маленького экрана. Графические ноды Годо не поддерживают такого из коробки (в отличие от UE лапши), а делать это, видимо, было сложно (или не хотели принимать в ядро движка), и ещё сложнее делать это целевой аудитории (нубам и яждизайнерам). Поэтому решили выкинуть визуальный язык во внешний модуль - так ему будет посвободнее, а в ядре будет меньше лишнего.
>Идеальным вариантом было бы создание визуального кода у которого поток выполнения рисуется сверху вниз, а поток вычисления выражений рисуется слева направо. Как в текстовом коде. Тогда бы код стал реально удобен в восприятии.
Это твои фантазии, которые я уже подробно разбирал в скретч-треде. Ты изобрёл подсветку синтаксиса кода в текстовом редакторе. Только вместо подсветки цветом у тебя дурацкие козявочки на краях рамки вокруг единиц кода, которые ещё хрен разглядишь и отличишь друг от друга (я вот не люблю C-подобные языки из-за обилия {}, которые тяжело разглядеть, а твой язык возводит эти дебильные скобки в абсолют).
Вывод - твой визуальный подход не нужен, потому что не даст ничего нового программисту и не будет достаточно удобен для непрограммиста (яждизайнера, школоло и т.п.). В скретче такая система используется для обучения программированию на обычных языках, а ты пытаешься создать инструмент для удобного кодинга, хотя любой нормальный человек после обучения на скретче перейдёт на нормальный текстовый ЯП и больше не вернётся на скретч.
Алсо, у тебя руки не болят от постоянного мышкодроча в твоём возрасте? Или что у тебя, сенсорный экран для ПК? Трекбол? Должна же быть причина, почему тебе двигать блоки удобнее.
>КА нужны как раз, чтобы от ебли с флагами уйти
Как я тебе конечный автомат буду делать, по-твоему?
match State:
State.IDLE: ...
State.WALK: ...
State.RUN: ...
и т.д.
Чем это лучше метко поставленного флага?
Какое-то чудовище из сотни .gd файлов по десять штук на каждый стейт не предлагай.
>лезет делать свой асасинс крид, не меньше. А не какие-то там угодайки в консоли.
Будет ли такой ньюфаг согласен шлёпать формы Windows, с кнопочками, TextBox-ами и что там ещё есть? Он же хочет 3D экшон, суть токова, и чтоб ещё корованы грабить можно было, а ты предлагаешь ему нашлёпать Калькулятор из Windows или, в лучшем случае, Сапёра. Смысл предлагать ему "обычное оконное приложение" вообще, если он ничего не хочет делать кроме 3D экшонов.
> Графические ноды Годо не поддерживают такого из коробки (в отличие от UE лапши)
Мы это уже обсудили в скретч-треде и я убедительно показал на скринах, что в УЕ точно такие же низкоуровневые ноды.
А высокоуровневые ноды это, уж извини, называется по простому совсем другими словами: готовая игра. И никто тебе "высокоуровневые ноды" бесплатно не даст, тотому что их создание из низкоуровневых примитивов - это труд, а у нас тут капитализм. Труд изволь купить.
> Как я тебе конечный автомат буду делать, по-твоему?
Возьми бумагу и ручку и нарисуй. А потом по нарисованной схеме закодь. Все так делают и ты делай. И кстати, КА не обязательно должен быть один в рамках сущности. Их может быть несколько параллельных, могут быть вложены друг в друга, образуя целое дерево.
>Возьми бумагу и ручку и нарисуй. А потом по нарисованной схеме закодь.
А теперь объясни, чем это отличается от одного флага, который я нарисовал ручкой на бумаге и потом по нарисованной схеме закодил в виде пары if'ов в нужных местах. Ты как какой-то фанатик, узнал про конечные автоматы и теперь всем их без разбора советуешь...
>Их может быть несколько параллельных, могут быть вложены друг в друга, образуя целое дерево.
Это всё очевидно. Но конечный автомат из двух состояний (вкл-выкл) является флагом, не так ли?
>в УЕ точно такие же низкоуровневые ноды
Ладно, я не разбираюсь в этих ваших УЕ и предполагаю, что ты разбираешься лучше меня. Но тогда почему в УЕ этой лапшой обмазываются все кому не лень и истерично просят добавки (в том числе лапшиз... кстати, где он?), а в Godot новички, даже если пытаются распробовать визуальную лапшу, в большинстве своём быстро переключаются на GDScript и потом его нахваливают и просят добавки именно на GDScript? Я думаю, если бы в УЕ была нехватка скриптового языка, его бы быстро прикрутили, т.к. компания большая и прикрутить готовый интерпретатор смогла бы без проблем. Но если всё дело в том, что скриптовый язык типа GDScript лучше любой визуальной лапши, то о чём вообще разговор - кодишь себе на GDScript и кодь, зачем изобретать какой-то велосипед...
> тогда почему в УЕ этой лапшой обмазываются все кому не лень и истерично просят добавки
Выскажу личное ИМХО: потому что в УЕ гораздо больше всё на лапшу завязано, там всё через неё делается (код, шейдеры, ресугрсы, конфиги, всё, буквально всё) и над ней долго работали, чтобы сделать работу с ней максимально удобной для лапши.
Понимаешь, проблема ведь не только в блоках, не в том, что там надо специальным блоком деконструировать вектор на три компонента, а ещё в том как именно ты эти визуальные блоки мышкой достаёшь откуда-то из недр движка и помещаешь на блупринт. Вот в удобстве этого процесса эпики преуспели, а Хуан слился и дропнет поддержку визуального программирования (ВП) в четвёрке. Кстати, раз уж зашла речь, создатели скретча тоже преуспели в удобстве.
В УЕ ты без задней мысли их достаёшь они удобно выкладываются каждый следующий привязывается к предыдущему, удобные тайминги и радиусы захвата соединительных линий, это всё тысяча мелочей из которых складывается удобный интерфейс. И над ним работали долгие годы. Очевидно, что сляпанный на коленке модуль ВП будет на первых порах уступать матёрому конкуренту. Нужны были бы долгие годы, чтобы допилить ВП в годоте до такого же удобства.
В скретче (и его более развитом форке снэпе) тоже всё удобно организовано. У тебя палитра блоков, из которой блоки достаются за 3 миллисекунды и в руке лежат как влитой.
Короче вопрос сложный и по большей части всё это дело вкуса. А поскольку годот опенсорц, всё это отдаётся нам на откуп: хочешь ВП - бери модуль из трёшки, допиливай под новые классы четвёрки (контрол+R, лол) и собирай движок самостоятельно. Или делай с нуля любой другой модуль языка, в том числе визуального и тоже собирай свою сборочьку. Только так. Мы за годот не платим, нам ничего не обязаны. Хуан не захотел -> ВП не будет.
> кодишь себе на GDScript и кодь
Да, я тут пару часов назад подумал, что является аналогом "высокоуровневых блоков" в текстовых языках? Сниппеты! Стало быть надо просто себе скачать аддон для сниппетов (их в ассетлибе аж джва) прокачать список сниппетов своими личными многолетними наработками, и действительно кодить себе и кодить, вставляя сразу по 20 строк сниппета по необходимости.
>Просто сядь и сделай тетрис, говорим мы ему
Нет.
Давай я расскажу тебе, какая была моя первая игра. В школе на компах был установлен вижуал бейсик. Основы языка были в учебнике (который был очень похоже на учебник информатике, но учились мы всё равно не по ним), там был квикбейсик и паскаль, я летом его зачитал до дыр, так как своего компа не было, и уже знал синтаксис. И вот в ВБ я накодил следующее:
Есть снаряд, есть мишень. Несколько полей с параметрами, канвас. Кнопка. Задаём массу снаряда, угол наклона, силу выстрела, стреляем. На графике отрисовывается его траектория и попал/не попал. Всё.
Хотя да, перед этим я какие-то хеллоуворлды из учебника тоже кодил. Но всё-таки это годится лишь для самого-самого старта, когда не умеешь буквально вообще ничего, а тебе туториал предлагает готовые примеры (та игруля, кажется, тоже из учебника была). Как только умеешь хоть что-то, надо сразу переключаться на те задачи, которые тебе интересны (в нашем случае игори), так как именно решение интересных задач подогревает мотивацию.
>Потому ты и не знаешь, мы тут долго обсуждали недостатки визуального проектирования нодами слева-направо. Они неудобны даже не широком экране. Потому что код очень быстро разрастается в ширину и становится неудобочитаем.
Как анон, сидящий в UE на блупринтах, поясню. Есть куча способов сделать лапшу гораздо более удобной и читаемой. Во всяком случае в UE такие способы есть, но там ноды завезли из коробки, а не сбоку изолентой прикручивали. А вообще, очень часто оказывается, что если ноды превратились в адовую мешанину, значит, ты что-то делаешь кардинально неверно. В принципе ноды не предназначены для того, чтобы только на них делать что-то совсем сложное. Ты либо быстро-быстро на коленке лепишь, чтобы чисто потестить функционал, или дополняешь нодами обычный код. И конечно же, дело привычки.
>Идеальным вариантом было бы создание визуального кода у которого поток выполнения рисуется сверху вниз, а поток вычисления выражений рисуется слева направо. Как в текстовом коде. Тогда бы код стал реально удобен в восприятии.
Дело не в слева направо, сверху вниз или даже по диагонали. Проблема визуальной громоздкости и визуального шума решается только пересадкой на обычный код, но и его засрать проще простого. Неверна сама по себе постановка задачи - создать визуальный аналог обычного ЯП. ЯП десятилетиями существуют в текстовом виде и это всех устраивает. Ноды существуют гораздо меньше, но в своих нишах они тоже всех устраивают и свои задачи отлично решают. Это две отдельные ниши со своими собственными задачами и инструментами.
>Подробности (со скринами, нарисованными в инкскейпе) я расписал в скретч-треде.
Если ты так уверен в своей идее, то почему не реализуешь? Может, ты действительно прав и эта штука окажется удобной. Техническая возможность прикрутить это к годоту, юньке или уе существует.
> почему не реализуешь?
Пилю потихоньку. Если не заброшу, то что-то да получится.
Есть гайды на русском по вкату вкупе с шарпом?
На ютубе только всякая васянская хуетень.
На ютубе только всякая васянская хуетень.
В шарп вкатывайся отдельно. Как вкатишься в шарп, открывай АПИ референс и просто используй классы годота в шарпе, используя знания шарпа.
Я не знаю, где тебе вкатиться в шарп. Я олдфаг и я знаю Программирование в целом, шарп мне даже учить не пришлось, я просто сел и начал кодить на нём, держа МСДН под рукой.
Есть множество источников, но все они - инфоцыганские.
Можешь попробовать к Сакутину закатиться на курсы (заодно нам расскажешь насколько оно эффективно) (заодно юнити выучишь, ибо Сакутин преподаёт шарп в связке с юнити, а за перекат между движками не беспокойся, шо там майнлуп, шо тут майнлуп, и оба майнлупа - такая лупа, шо я того майн колбэкил).
В шарп уже немного вкатан (по крайней мере был, сейчас уже забылось, но активно пытаюсь вспомнить + по ходу разработки, думаю, освежу еще). Поэтому вкатываться хотел именно в движок, но хоть туториалов и дофига, именно в связке со студией\шарпом не увидел, думал вдруг подскажете. Банально, чтобы разобраться где какие кнопки жать.
Для себя определил сейчас, что тут либо начинать изучать с англоязычным контентом, либо русскоязычным, но на родном GDScript, а потом уже пробовать переписать на шарп все пробно сделанное, иными словами переучиваться. Второе немного смущает, потому что не люблю сферические яп в вакууме, мне этого добра на работе хватает.
Но с unity идея интересная, кстати, не додумался до того, что с движка на движок можно будет перейти. Спасибо, может руки дойдут. На курсы не хочу, особенно к Сакутину. Он, может, разраб действительно неплохой, но больше вызывает впечатление шоумена (еблоторговца, если по нашему).
> В шарп уже немного вкатан
Непонятно, в чём тогда проблема?
> вдруг подскажете. Банально, чтобы разобраться где какие кнопки жать.
> все пробно сделанное
> на родном GDScript,
Вообще непонятно, в чём проблема? Какие конкретно у тебя сложности перевести скрипты на гдскрипте в шарп?
> изучать с англоязычным контентом
К сожалению, это остаётся наиболее адекватным решением по сей день. Русскоязычного контента мало по одной неприятной причине: мотивированные новички пилят бесполезный новичковый контент, а потом быстро теряют мотивацию к тому же. Профи не пилят контента, им оно и нахуй не нужно.
Вот этот челик вроде неплох, я его смотрел:
https://www.youtube.com/c/BeIndieGameTutorials/playlists
> больше вызывает впечатление шоумена (еблоторговца
Тем не менее, от него я узнал гениальную в своей простоте мысль: Игра может быть построена на архитектуре MVP, где модель игры может быть вообще независима от движка и легко пересаживаться с движка на движок (для десктопов один, для мобил второй, для консолей третий), модель может быть либой на шарпе (а может и нативной либой, хоть на хаскелле), у клиента она подсоединена к клиентскому приложению на движке, а если есть сервер, то на сервере модель может работать как микросервис. Идея простая, но вот сам не догадался, не сложил 2+2.
почему хартбиста не посоветовал ему?
мимо_сам_перестал_его_смотреть_на_17_части_туториала
на русском сами доки есть, в которых есть туториалы. но чтобы чисто новичку вкатиться-понять как это работает, я не знаю ничего из русскоязычных курсов потому что и не искал лол
Проблема в том, что я запускал Godot один раз (и это первый игровой движок, который я трогаю), а скрипты на нем писал ноль раз. И мысль была глянуть какой-нибудь туториал, в котором показывается работа Godot именно с шарпом, чтобы увидеть за раз как можно больше аспектов, которые потом пригодятся. Не в плане непосредственно разработки, а в плане того, как там всё устроено.
Сейчас уже понимаю, что пойду другим путем. В любом случае, спасибо.
>Проблема в том, что я запускал Godot один раз (и это первый игровой движок, который я трогаю), а скрипты на нем писал ноль раз.
Тогда начинай с базовых туториалов в официальной документации:
https://docs.godotengine.org/en/stable/getting_started/introduction/index.html
https://docs.godotengine.org/en/stable/getting_started/step_by_step/index.html
https://docs.godotengine.org/en/stable/getting_started/first_2d_game/index.html
Тебе в любом случае понадобятся общие знания редактора и API движка, независимо от того, на каком ЯП ты будешь чаще всего писать в будущем.
GDScript не бойся, производительности у него более чем достаточно для большинства обычных игр (т.е. не клон майнкрафта или ММО с >9000 пользователями в одной комнате), а синтаксис максимально прост - имея общие знания программирования, переучиваться не придётся. Ну да, похож на Python, но главное, что с поставленной перед ним задачей справляется, а на что он там похож - это не важно.
Сам я C# в Godot не использовал, но, скорее всего, это точно так же просто, как GDScript, только код на C# более многословный. Всё API точно такое же, действия для подключения скриптов мало чем будут отличаться. Только редактор придётся внешний использовать - это главный минус. Меня Godot привлёк в частности тем, что редактор кода встроен в окно редактора сцен и не приходится никуда переключаться, ты просто сидишь и делаешь игру, без косяков какого-то софта от третьих лиц (Visual Studio и т.п.).
как-то раз пытался код на гдскрипте писать в саблайм текст - в итоге стало не хватать фич из годотовского текст едитора
Парни, неужели диалоговую систему так сложно реализовать, что ссылка на аддон с ней висит одной из первых в описании?
Суп, годоны, пилю свой columns с отклонениями и изобрел там фигуры-комбухи. Но не могу придумать как отображать их. Нашел кучу гайдов с инвентарь системой через GridContainer, но может как то проще можно?
Отображать их когда ты собрал что-то из того что я задумал*
сука сука сука не могу нарисовать ебучую орбиту
Создал кнопку, накинул на нее скрипт, создал AudioStreamPlayer2D.
В функцию при нажатии на кнопку добавил $AudioStreamPlayer2D.play(), но.. оно не проигрывается. При добавлении yield($AudioStreamPlayed2D, "finished") звук проигрывается, но зацикливается. ЧЯДНТ?
В функцию при нажатии на кнопку добавил $AudioStreamPlayer2D.play(), но.. оно не проигрывается. При добавлении yield($AudioStreamPlayed2D, "finished") звук проигрывается, но зацикливается. ЧЯДНТ?
Всю жизнь мечтал делать игори
нашел godot
накодил велосипедов за пару вечеров
идей ноль
https://alkaon.itch.io/testos
можно похуесосить
алсо двиг потрясающий, разобрался практически сходу, при этом в юнити не смог освоится вообще
гдскрипт - заебумба кстати
нашел godot
накодил велосипедов за пару вечеров
идей ноль
https://alkaon.itch.io/testos
можно похуесосить
алсо двиг потрясающий, разобрался практически сходу, при этом в юнити не смог освоится вообще
гдскрипт - заебумба кстати
Не забываем о том, что наш заботливый ОП перекатывает треды почти всегда сразу после 500-го поста, а после переката в старый тред почти бесполезно писать - все активные участники мониторят только актуальный тред:
Подскажите как фиксануть плывущие текстуры tilemap при смене разрешения экрана ?
Поздравляю с выходом 3.5, ребятки! В этом релизе бэкпортами закинули много фич из будущей четвёрки.
Подробности по первой ссылке.
Краткий гайд по вкату в движок:
1. Читать документацию.
2. Качать примеры.
3. ПРОФИТ!
Ссылки
Новости движка: https://godotengine.org/news/
Скачать движок: https://godotengine.org/download/ или http://store.steampowered.com/app/404790/Godot_Engine/
Играть в игродела онлайн без регистрации: https://editor.godotengine.org/releases/latest/ с дивана нельзя.
FAQ: https://docs.godotengine.org/ru/latest/about/faq.html
Документация: https://docs.godotengine.org/ru/latest/ https://docs.godotengine.org/en/stable/
Примеры качаются прямо в движке через свой магазин в отдельной вкладке AssetLib. Там есть всё - от платформера до чата.
Игры, созданные глобальными кириллами: https://steamdb.info/tech/Engine/Godot/ https://steamcommunity.com/app/404790/discussions/0/412448792354265655/
Изумительный Годот: https://github.com/Calinou/awesome-godot https://github.com/godotengine/awesome-godot - подборка дополнений, модулей и минишоукейc.
Аддон для диалоговой системы: https://godotengine.org/asset-library/asset/833
Прекомпилер шейдеров: https://godotengine.org/asset-library/asset/977 С версии 3.5 больше не нужен.
Библиотека готовых шейдеров: https://godotshaders.com
Майндмаппинг проектов не отходя от кассы: https://godotengine.org/asset-library/asset/879
SmartShape для рисования 2D-террейнов без задней мысли: https://godotengine.org/asset-library/asset/715
Конвертор кваковских карт для ностальгирующих дидов: https://godotengine.org/asset-library/asset/446
Конвертер блендеровских моделей в формат сцен: https://docs.godotengine.org/en/stable/getting_started/workflow/assets/escn_exporter/index.html
Конвертер блендеровских файлов прямо в движок: https://github.com/V-Sekai/godot-blender Надо только в настройках проекта путь к blender.exe указать. Потом просто закидываешь .blend в папку и импортируется.
Книги
Смотри пункт 1 из краткого гайда выше.
Для любителей пощекотать конпеляцию
Бинды LUA: https://github.com/perbone/luascript
Бинды JS: https://github.com/GodotExplorer/ECMAScript
Лучше кинуть ссылку на список всех языков: https://github.com/Vivraan/godot-lang-support
Годнота от анона
- Для приверженцев опенсорца существует возможность распространять проекты в незапакованном формате. Просто скачай темплейт с оф.сайта и положи экзешник/эльфешник в папку с проектом, этого достаточно. Имя файлу можно задать любое. Дополнительно можешь вшить свою иконку в экзешник. После этого, запустившийся файл темплейта обнаружит рядом с собой файл project.godot и начнет грузить проект из него и из файлов, лежащих в распакованном виде в той же директории. Для запущенного таким образом проекта папка res:// становится доступна для записи (если это не ограничено правами доступа в системе). Тут нужно отметить, что проект не запустится без папки .import и файлов в нём. Если попытаться запустить без неё, Godot попросит запустить редактор, чтобы импортировать ресурсы заново. Т.е., к сожалению, невозможно просто отредактировать текстуру в пейнте и увидеть изменения в игре - в любом случае потребуется запускать редактор, чтобы он импортировал текстуру заново, потому что импорт - это конвертация во внутренний формат (etc/etc2/s3tc/bptc), а оригинальный файл (.png, .jpg и т.д.) игрой не читается (load("res://icon.png") грузит версию из папки импорта, а не ту, что мы ожидаем).
- В версии 3.2 появилась возможность прикреплять pck к бинарнику. Не появилась, а вернулась - 2.х умел. Бриллиант для любителей однофайлового продукта!
- Редактор персонажей на основе makehuman: https://github.com/Lexpartizan/Go_MakeHuman_dot
- Тест-бенчмарк:
- - Веб-версия - https://govdot.herokuapp.com
- - Вишмастер для винды - https://govdot.herokuapp.com/4Anon.rar
Предыдущий:
Архивный: https://arhivach.ng/thread/812688/