Краткий гайд по вкату в движок:
1. Читать документацию.
2. Качать примеры.
3. ПРОФИТ!
Ссылки
Скачать движок: https://godotengine.org/download/ или http://store.steampowered.com/app/404790/Godot_Engine/
Теперь прямо онлайн - можно и с дивана: https://godotengine.org/online/godot.tools.html
FAQ: https://docs.godotengine.org/ru/latest/about/faq.html
Документация: https://docs.godotengine.org/ru/latest/ https://docs.godotengine.org/en/stable/
Примеры качаются прямо в движке через свой магазин в отдельной вкладке AssetLib. Там есть всё - от платформера до чата.
Игры, созданные глобальными кириллами: https://steamcommunity.com/app/404790/discussions/0/412448792354265655/
Изумительный Годот: https://github.com/Calinou/awesome-godot - подборка дополнений, модулей и минишоукейс от одного из авторов.
Годнота от анона
- Для приверженцев опенсорца существует возможность распространять проекты в незапакованном формате. Просто скачай темплейт с оф.сайта и положи экзешник/эльфешник в папку с проектом, этого достаточно. Дополнительно можешь вшить свою иконку в экзешник. После этого, запустившийся файл темплейта обнаружит рядом с собой файл project.godot и начнет грузить проект из него и из файлов, лежащих в распакованном виде в той же директории.
- В версии 3.2 появилась возможность прикреплять pck к бинарнику. Бриллиант для любителей однофайлового продукта!
- Редактор персонажей на основе makehuman: https://github.com/Lexpartizan/Go_MakeHuman_dot
- Тест-бенчмарк:
- - Веб-версия - https://govdot.herokuapp.com
- - Вишмастер для винды - https://govdot.herokuapp.com/4Anon.rar
Предыдущий тонет там: >>698054 (OP)
Архивы:
1 https://arhivach.ng/thread/207802/
2 https://arhivach.ng/thread/388500/
3 https://arhivach.ng/thread/388501/
4 https://arhivach.ng/thread/388502/
5 https://arhivach.ng/thread/388503/
6 https://arhivach.ng/thread/432708/
7 https://arhivach.ng/thread/433902/
8 https://arhivach.ng/thread/436355/
9 https://arhivach.ng/thread/455461/
10 https://arhivach.ng/thread/479963/
11 https://arhivach.ng/thread/489815/
12 https://arhivach.ng/thread/494513/
13 https://arhivach.ng/thread/515567/
14 https://arhivach.ng/thread/533171/
15 https://arhivach.ng/thread/555441/
16 https://arhivach.ng/thread/592945/
17 https://arhivach.ng/thread/592946/
18 https://arhivach.ng/thread/614942/
Неплохо, но бессмысленно. Как раз задумка в том, чтобы не читать сейв-файл при открытии диалогового окна. Этот-то проект мелкий, но я планирую и в большом так же делать, а там сейвы покрупнее будут, читать каждый ради получения превьюх - не гуд.
>>712309 →
>А на андроидах такое будет работать?
Если не сработает, подгрузится дефолтная иконка. И буду думать, как починить.
Подключившимся к беседе спасибо. Я сделал самым простым способом: при нажатии кнопки сохранения берётся скриншот, хранится в памяти, а обрезается и ужимается уже непосредственно при сохранении файла. Таким образом, под долгий процесс отведено то время, когда игрок всё равно ожидает каких-то подтормаживаний. А что скриншот в памяти сохраняется, так это не страшно. Тем более что кнопка сохранения вызывает только окно сохранения, никаких других менюшек.
> чтобы не читать сейв-файл при открытии диалогового окна
> а там сейвы покрупнее будут
Ты предполагаешь чтение файла целиком. Но движок имеет функционал для чтения файла по частям. Текстовый файл можно читать построчно. Бинарный побуферно.
Чтение одной строчки текстовика, длиной в размер пикчи будет несколько дольше чтения файла пикчи, из-за накладных расходов текстовика. Чтение же буфера из бинарного файла вообще предположительно (sic!) ничем не будет отличаться от аналогичного ПНГ, ибо он читается с диска так же (!?!sic!?!) в бинарном режиме. Но зато ты не срёшь файлами в папке с сейвами.
Ну опять, же я не настаиваю. Ничто не мешает заводить под каждый сейв папочку и хуярить в неё несколько пикч, несколько конфигов, несколько БД-шек. О, можно же пакануть потом эти файлы в ПАК, средствами самого движка или в ЗИП. В общем, вариантов куча.
Прикольно было бы сохранять игру в ПНГ-файл вообще. Надо изучить формат ПНГ, выяснить, как он читается программами просмотра, найти места для безболезненного инжекта метаданных и хуярить. Круто же будет. Заходит игрок в папку с сейвами, чтобы сохранить важные из них, а там - одни пикчи. И он такой, ЕБАААТЬ! А ГДЕ МОИ СЕЙВЫ??? Троллинг 80 левела!
> Ты только что раржипег.
Я думал о раржпеге, но когда писал тот пост, в голове держал стегхайд (если ты его помнишь). Потому что ящитаю, раржпег или пнгзип (он возможен), являясь приписанным в конец пикчи архивом, уязвимы к всевозможным чистильщикам, умным просмотрщикам, антивирусам и прочим мокрописькам, которых игроки обязательно понаставят на свои компы. И вот представь: твой игрок поставил себе какой-нибудь очередной SickLeaner и тот нашёл у него твои сейвы-пнгзипы и пишет юзеру "мы можем высвободить у вас 60 Мб свободного места!" а юзер "Да!", и потом открывает игру, жмёт "продолжить" а ему "файл сохранения повреждён". И он плачет, рыдает у тебя в техподдержке "Я джва месяца играаал! У меня эльф 80го левела и 50 лутбоксов на аккаунте!"
Такшта, только сохранение в метаданных без потери консистентности формата, только хардкор.
>>712433
Они не были анонимусами и не знали.
>Где их лучше качать?
Качаешь мастер-ветку https://github.com/godotengine/godot и билдишь сам. Есть шанс, что сбилдится и запустится)
Смысла в распространении этих билдов нет, исходники обновляются каждый день, багов наверняка много, версия сырая...
Ящитаю, лучше качать померженный бранч отдельно https://github.com/godotengine/godot/tree/vulkan потому что (я так предполагаю) в бранче всё оттестировано и работает, а в мастере работа ведётся наживую и анону может не повезти именно в момент закачки закачать код с поломанным функционалом. А бранч он уже всё. Застыл в истории после мержа. Поправьте, если я не так понимаю.
В связи с чем вопрос:
А хули так сложно то?
Смотрю уроки на ютубе, читаю эту самую документацию и нихера понять не могу.
Наприме надо сделать так, чтобы статичный спрайт спаунил другой спрайт (пулю) раз в 5 секунд. В констракте это делается буквально 3мя кликами, + еще и условия всяких накидать можно. В Годо же кучу всякой херни написать надо. Какого блядь черта? Вот как этот ебучий таймер делать? На сцене со спаунером, или на сцене с уровнем? Нихенра не понятно.
Или вот еще - "пишу" код, обозначить переменные это понятно, дальше надо писать "func _тут_какая_то_херня (а скобки зачем?)"
ни в одном уроке не нашел ничего подробного про эту "func" - название любое что ли можно? Или список есть? В примерах всегда почти одни и те же названия, типа "_rеdy". А в скобках что? Или для того,чтобы писать на гдскрипте нужно питон знать?с нуля вкатиться в гд не получится?
визуальный скрипт пробовал но даже не понял с чего начать
>В констракте это делается буквально 3мя кликами, + еще и условия всяких накидать можно. В Годо же кучу всякой херни написать надо. Какого блядь черта?
Ну так констракт это и не движок, а "конструктор", где код нельзя писать в принципе, естественно, что там проще.
>Вот как этот ебучий таймер делать? На сцене со спаунером, или на сцене с уровнем?
Таймер это обычный node, добавляешь его ребенком к херне, которая создает у тебя пули. Потом еще нужно соединить его timeout сигнал, если ты хочешь, чтобы что-то произошло, когда время выйдет.
>.func _тут_какая_то_херня (а скобки зачем?)"
В скобках указываются аргументы, если их нет, то тогда они пустые. Сама по себе функция это просто какой-то изолированный блок кода, который исполняется только тогда, когда ты вызываешь саму функцию.
>В примерах всегда почти одни и те же названия, типа "_rеdy"
'_ready' это "встроенная" функция, которая автоматически вызывается, как только node создается в сцене. Ты можешь создавать свои функции и называть их в принципе почти как угодно.
>Или для того,чтобы писать на гдскрипте нужно питон знать
В принципе не нужно, но знание основ программирования на любом языке помогло бы значительно.
>ни в одном уроке не нашел ничего подробного про эту "func"
В уроках, наверное, самые основы не объясняют. Читай официальную документацию.
https://docs.godotengine.org/en/stable/getting_started/scripting/gdscript/gdscript_basics.html
Ну блин. А зачем ты в школе прогу продалбывал? Сейчас у тебя был бы какой-никакой опыт алгоритмоёбства, архитектуры, всей херни. С наследованиями бы проблем не было.
Тебе нужно подтянуть совершенно любую прогу на любом языке. Нужны совершенно базовые вещи вроде функций и переменных, немножко про объекты и поля объектов и указатели (только без хардкорного указателеёбства как в C любят). Ну и про дерево прочесть что-нибудь можно. Лучше на Питуне, потому что синтаксис похожий, если в школе Паскаль учил, будешь постоянно об «=» и «==» спотыкаться и на циклах материться.
Вкратце, весь скрипт состоит из функций, в которые ты свои команды и напихиваешь. Их называй как хочешь, лишь бы ты сам понял, чо хотел (какие-то ключевые слова или уже имеющиеся функции не надо использовать, но я на такое особо не натыкался). Скобки после названия функции нужны для аргументов.
Например если тебе нужна функция, которая стирает пули, она должна иметь вид func remove_nahui (bullet). Тогда внутри функции ты сможешь обращаться с объектом bullet как с астоящей пулей. Потом где-то в другом месте, где тебе понадобиться удалить пулю bullet_96_ot_mahmuda ты сможешь взять и вызвать remove_nahui (bullet_96_ot_mahmuda), и пропадёт именно та пуля, которая тебе нужна.
Пустые скобки (как у _ready()) — это по большей части формальность, но она позволяет самому компилятору отличать функции от переменных.
>Например, "койот-тайм", зависание в воздухе за краем платформы перед падением, сам бы я никогда не додумался, что он используется в платформерах, и что его нужно использовать для удобства игрока.
Мне нравится как молодеж, открывает для себя вещи придуманные в геймдеве более 20 лет назад. Джампбуфер и обход краев для тебя наверное тоже откровением были.
https://www.youtube.com/watch?v=pqrD3B75yKo
билд Godot 3.2.2 html5 компиляция.
Глес 3й, сейчас знакомому скинул на вин10 через разные браузеры, тоже все норм.
>Собери пустой проект и скинь ему
Я думаю он не будет этим заниматься. Там поток огромный.
ссылка на билд: https://cubic321.itch.io/panda-jumper?secret=mGHLkHarvMHMz2Pmimm2pvgNjj0
>Хардкорная игра! Не против, если я её в шапке размещу?
Не надо, она еще не вышла и ссылка будет меняться.
>Любой хтмл-экспорт автоматически дропает рендер до глес2. Это знать надо, это классика!
Ты думаешь у паблишера розовый экран из-за глес3? Странно, но почему тогда у других все работает... я попытаюсь, но не хотелось бы этого делать, так как в глес2 половина эффектов не работает
> почему тогда у других все работает
Например у издателя машина загажена кучей фреймворков и либ, ведь он потоком принимает игоры и вынужден их запускать. Возможно там кодеки через кодеки, вплоть до того, что они в браузеры лезут.
На твоём месте я бы не стремался и поговорил с ними ещё раз. Уточни, какой у них браузер, и могут ли они запустить в другом? По факту есть только три браузера сейчас: всё хромиумное, мозилла и сафари.
Предложи им бинарник запускной. Чисто чтобы потанцевал заценить. С веб-версией позднее разберётесь если им понравится.
Мне понравилось.
Привет, годаны! Кажется, я уже готов написать свой первый нормальный топдаун-двадэ-контроллер персонажа. Предыдущие были ненормальны и не устраивали меня по разным причинам.
Теперь я узнал, кмк, всё необходимое:
1. Инпут осями (x = r - l, y = d - u)
2. Стейт-машина.
3. Разгон до максимальной скорости через интерполяцию, торможение до нуля тоже. Коэффициенты задаются конфигом.
Ну всё, запускаю редактор.
Ну вроде все устраивает. Хотя, что-то всё равно гложет. Что-то не нравится. Не пойму, что.
Пользуйтесь!
Поправки и замечания принимаются.
А то! Я с утра замыслил вот такое:
> enum MOVING { IDLE, WALK, CROUCH, JUMP, FALL }
> enum STAYING { LAND, WATER, AIR, SPACE }
> enum GROUNDING { FIRM, CRUMB, EDGE, HOT, WET, SLIP, SLIM }
> enum ARMING { SHEATHE, STEELARM, FIREARM, THROWING, RANGED, EXPLOSIVE }
И охуел, сколько мне вложенных дублирующихся match придётся делать. И принялся думоть над решением. И тут - БАЦ! Эвриак!
Более того, все подстановки, указанные в доках - работают. То есть, при добавлении анимаций можно добавлять условия, а закрывать каждый такой "блок условий" общим шаблоном:
match [moving_state, staying_state, ground_state, arming_state]:
# блок IDLE
[MOVING.IDLE, _, GROUNDING.EDGE, _]: anim.play("idle_with_sway")
[MOVING.IDLE, STAYING.LAND, _, ARMING.FIREARM]: anim.play("idle_with_gun")
[MOVING.IDLE, STAYING.WATER, _, _]: anim.play("water_idle")
[MOVING.IDLE, _, _, _]: anim.play("common_idle")
# конец блока IDLE
Ля как охуенно всё работает! Все компоненты общего состояния переключаются независимо. Вхожу на лёд, включается компонент скользко. Контроллер перемещения включает модификаторы для скользящего движения. Выхожу - выключает. Класс!
> что-то всё равно гложет. Что-то не нравится
От теперь заебись!
Когда вынес весь функционал в компоненты.
От теперь ваще каеф!
Целей достиг. Можно ещё месяц видосики смотреть.
>>713380
>>713361
так, пажжи.
Т.е. условно у меня есть состояния "ходьба стоя", "покой стоя", "бег стоя", "ходьба раком", "покой раком", "бег раком" итоде. В итоге это может сократить кол-во этих состояний? Если зажат шифт, то хоть раком, хоть буераком, будет включаться режим бега и не придётся делать его для обеих поз?
Ну да. Главное - правильно всё спроектировать и раскидать по категориям. На каждую категорию свой "слой" в комбинированной стейтмашине. И разумеется, это должно соответствовать задуманным тобой игровым механикам. Если ты хочешь, чтобы из положения раком персонаж резко срывался на бег, то делаешь так. Если не хочешь - делаешь иначе.
Основная проблема, которую решает такой подход - лёгкость программирования поведения в разных средах. Персонаж не может, скажем, доставать оружие, если находится в воде. Или, если есть холодное и огнестрельное оружие, он не может доставать в воде только огнестрельное.
В воде, на суше (причем на твёрдой и на крошашейся поверхности, на скользких или липких поверхностях), в воздухе, в космосе - у персонажа разные анимации. В каждой из анимаций, в любой момент, если это разрешено, персонаж может вытянуть оружие и начать им махать/стрелять, либо наоборот, остановиться, спрятать оружие и перейти в режим IDLE. Соответственно, должна быть система, которая всё это учитывает и запускает в воде автоматически анимации для пребывания в воде, в воздухе - анимации воздуха и т.д. И когда персонаж переходит в другую среду (о чем получает входящий сигнал среды) он меняет своё состояние в соответствующем слое, не затрагивая других слоёв и анимация плавно переключается.
Эта комбинированная стейтмашина может всё это обеспечить. И даже, как я показал выше >>713361 в строке 21, может выводить имена ключей как текст, чтобы получить автоматически имена требуемых анимаций.
С нуля сложно, понимаю. Что-нибудь смотрел/читал обучающее по общей информатике? Если нет - рекомендую посмотреть/почитать. Если да, но не понял, рекомендую погуглить из других источников, пока не найдёшь достаточно доходчивый материал.
Ведь в программировании всё просто: 1 и 0 = 0, 1 или 0 = 1. Вот и всё программирование. Всё остальное надстройка над этой очобой.
Ну машинно-логическую базу я болие лимени знаю. Собсно, простенькую стейт-машину кое-как написал сам(после гугла, что такое стейт-машина и как пишется). Состоит из сплошных ифов.
А вот задачи уровня "сделать движущийся лифт" или "прикрутить поворот головы к курсору при зажатом ПКМ" уже сложнее. Хоть я за них ещё и не брался
>This method should be used in Node._physics_process (or in a method called by Node._physics_process), as it uses the physics step's delta value automatically in calculations.
А кто-нибудь в курсе, почему они сделали именно так, а не добавили для дельты отдельную позицию в передаваемых аргументах?
Чисто с дивана могу предположить, что там внутри, в буллете, на крестах, это компактный, скоростной алгоритм, использующий дельту (приращение) и нет смысла им манипулировать снаружи, потому что скорость упадёт или типа того. Можно поискать реализацию в сорцах (опенсорц же, ёпт), вдруг там в комментах оставили заметки? Но лень.
> Но лень.
Поборол лень.
https://github.com/godotengine/godot/blob/master/scene/3d/physics_body_3d.cpp
> 938: // Hack in order to work with calling from _process as well as from _physics_process; calling from thread is risky
> 939: Vector3 motion = (floor_velocity + body_velocity) * (Engine::get_singleton()->is_in_physics_frame() ? get_physics_process_delta_time() : get_process_delta_time());
Примерный перевод коммента:
> Хак для работы через вызов из _process точно так же, как через вызов из _physics_process; вызов через [отдельный?] тред - рискован
Таким образом, дельту физического движка засунули в мув_и_слайд ради нубасов, которые без задней мысли пытаются обрабатывать физику в _process, который не для физики, а для графики, математики и всего такого химии, истории, лит-ры, физ-ры и природоведения, но не физики.
Только я всё равно смысла этого хака не понимаю. Он всё равно в тернарной операции выдает простофрейму простодельту, физикфрейму физикдельту. В чём сакральный смысл делать это там, а не домножать на дельту вектор движения в гдскрипте?
Сложно понять сишников, когда ты старый бейсиковец-паскалист.
Я просто посмотрел на свою стейт-машину и подумал, что многовато в ней кода, надо выделить в отдельный класс. А потом как-то само вышло.
Так вот. Годаны, а попадались кому-нибудь видосы на тему стейт-машины из нод? Наверняка ведь не я один такой хитрый, но вот внятной инфы по теме я не встречал.
А вот я придумал, юзать графическую стейтмашину из объекта AnimationTree! Для него создаётся отдельный AnimationPlayer, в котором создаются особые, уличные анимации, длительностью 0.1 и шагом 0.1, то есть, одношаговые. И в каждой из них содержится только один ключ - ключ вызова метода. И мы имеем графическую стейтмашину с графом переходов любой сложности, которая работает по факту с кодом.
На словах всё звучит красиво, на деле, я ниасилил, как это применять.
> Что-то со стороны это выглядит, как будто суп есть вилкой, а стейк - ложкой. Технически можно, но нахуя?
Академический интерес.
> А непосредственно с анимацией, что делаешь? Через код пилишь?
Ну нет, академический интерес к этому был удовлетворён еще во времена 3.0.6. Так что пилю как обычно.
И чёт я плавлюсь. Никак не получается реализовать это на имеющихся нодах анимации. Я сделал две анимации: замах (просто зацикленная статичная поза длительностью в секунду) и удар. Вроде бы нужен ваншот, но с ним неправильно ведёт себя зацикленная анимация: постоянно повторяется с начала. Окей, тогда в стейт-машине последовательно ставим замах и удар. Но как тогда реализовать переключение на удар не тогда, когда закончится переход, а сразу же по команде?
В запасе я держу вариант с тем, чтобы поставить тупо бленд, а за ним ваншот с ударом; и просто в физикс_процессе менять силу бленда. Но всё-таки хочется, чтобы анимация рулила событиями, а не наоборот. К тому же я испытываю некоторые сомнения насчёт того, насколько физикс_процесс может сказаться на производительности, даже если у него в первой строчке написано if a: return; конечно, если он один, то плевать, но вот если их много...
Как у тебя машина перешла в состояние замаха?
Правильно, ты из кода сказал ей travel("замах")
Значит, при отпускании клавиши ты должен из кода сказать ей travel("удар")
Анимация замаха не должна быть зацикленной и транзишен не должен быть автоматическим. То есть машина остаётся в состоянии замаха, на последнем кадре, пока ты вручную не переведёшь её в состояние удара. После чего уже автоматические транзишены по заваршении удара переведут машину в айдл.
Альтернативный вариант (для более живого визуала) - бесконечная анимация замах-айдл, на которую замах выходит автоматически, но выход из неё в удар - вручную из кода. В этой анимации оружие занесено перед ударом и слегка покачивается.
Вот хочу я себе накодить редахтур уровней, чтобы было удобнее работать и мне, и воображаемым помощникам. Он, например, схороняет сцены в папке memes scenarios/levels/l1-l2-l3-...-l100500. Просто папка, не архив с неизвестным науке форматом. И в ней файлов так 100+
Это насколько тупо по шкале от одного до десяти?
И реально ли сделать так, что по выходу из локации сцена схороняет все изменения/сдвинутые ящики/трупы врагов/етц?
> Это насколько тупо по шкале от одного до десяти?
Это вообще не тупо. Функционал по созданию текстур из внешних пикч на лету имеется. Главное - нетупо реализовать.
> И реально ли сделать так, что по выходу из локации сцена схороняет все изменения/сдвинутые ящики/трупы врагов/етц?
Вполне реально.
> воображаемым помощникам
Эй, а как же я? :о
>Только типы файлов и что с ними делать будем
ТЦСН, наверное. Их ведь можно будет редачить в редакторе, верно?
>О, и примерно, какую структуру загружаемых левелов планируешь?
Да как и в первой Хаудее, закрытые пространства из различных тайлов, детализацию можно и самому. Лови пример тестовой комнаты с лифтом и рандомскрин из оригинала
ТСЦН можно. Но тупо. Лучше хранить данные расположения ассетов на уровне и иметь одну динамическую сцену, которая по умолчанию пуста, но при загрузке читает этот файл и расставляет ассеты согласно данным из файла.
Я предлагаю это.
А чтобы была возможность редактировать в редакторе и сохранять файлы, я предлагаю тебе сцену-шаблон, которая будет юзаться только при девелопе и в релиз не пойдёт. От неё будет требоваться сохранять ассеты, установленные на ней в файл данных.
>ТСЦН можно. Но тупо.
В каком-то смысле согласен, но будут же некоторые моменты, которые с дефолтным редактором не осилить. Вдруг кто кастомный сценарий решит запилить, а там, например, лифту больше двух положений нельзя назначить?
>А чтобы была возможность редактировать в редакторе и сохранять файлы, я предлагаю тебе сцену-шаблон, которая будет юзаться только при девелопе и в релиз не пойдёт
Звучит сложно, но, думаю, полезно
> некоторые моменты
Недооцениваешь редактор. Во-первых, есть тулскрипты, позволяющие запускать код прямо в нём. Так что, если ты хочешь, чтобы игроки сами делали уровни, просто предоставишь им комплект тулскриптов и ссылку на скачивание годота.
Во-вторых: В этом смысле мы с тобой можем сильно облегчить задачу, если моды мы будем вообще грузить через встроенную систему, без велосипедов. Годот позволяет делать моды/патчи, используя основной PCK создавая к нему инкрементный PCK. Как тебе такая возможность? Если требование открытости ресурсов принципиально, то там можно ещё и в ZIP паковать. Причём (я правда не пробовал) но думаю, ничто не помешает паковать моды сторонним ZIP-архиватором.
Набросал каркас https://pastebin.com/pvASh6Jd
>Правильно, ты из кода сказал ей travel("замах")
>Значит, при отпускании клавиши ты должен из кода сказать ей travel("удар")
А теперь игрок отпускает кнопку раньше, чем замах завершился. И тут у меня два стула:
1. Переход на анимацию удара не произойдёт до тех пор, пока не завершится переход на замах. Потому что стейт-машина так работает, она совершает переходы последовательно и не может их просто взять и оборвать, уж тем более она не может сблендить состояние посреди перехода со следующим переходом. Или может?
2. Переход на замах можно сделать мгновенным, но сама анимация замаха должна каким-то образом блендиться с любым предыдущим состоянием. Но со стейт-машиной это в любом случае не выйдет, так как она берёт на себя все бленды на переходах.
> Или может?
Может.
Изучи внимательно свойства транзишенов. У них всего три режима (немедленно, синхронно, вконце) и флаг автоматического применения.
> игрок отпускает кнопку раньше, чем замах завершился
Это вопрос твоей игровой механики. Вот в дарк соулс, например, на таймингах анимаций построен весь геймплей боёвки. Ты не можешь просто взять и оборвать анимацию замаха и переключиться на блокирование - и тебе прилетает ваншот от босса нахуй. И это логично - в реале тоже не сможешь мгновенно без инерции убрать замахнувшуюся руку и уйти в блок.
Такшта ты либо делаешь один вид транзишенов, который аркадно дёргает персонажа из замаха в удар, игнорируя оставшийся хвост предыдущей анимации, либо иммерсивно даёшь анимации отработать, а персонажу пропустить удар моба и пригореть.
>Это вопрос твоей игровой механики
У меня простая механика "дольше замахивался - сильнее ударил". Без этих ваших соулсов.
>>714288
>У них всего три режима (немедленно, синхронно, вконце)
И какой же из этих режимов должен немедленно прервать предыдущий транзишен, по-твоему? Анимацию они успешно прерывают, да.
Слушай, а не проще сделать это так, что
Зажимаешь, ЛКМ, идёт замах. Состояние замаха включается тут же. Анимация меееедленно идёт.
Запускается таймер, который каждые полсекунды увеличивает множитель урона на 1. Ну или на сколько там тебе надо.
Отпускаешь кнопку - хуяг-пездыг. Урон нанесён, множитель посчитан.
>Анимация меееедленно идёт.
А как она будет блендиться с предыдущим состоянием?
Вот тестовый проект: https://dropmefiles.com/kVIhb- по пробелу фигура начинает подниматься, отпускаешь - падает. Задача: сделать так, чтобы падение наступало в тот момент, когда отпускаешь пробел; ну, и чтобы всё блендилось хоть как-то. Я вот так и не смог подобрать подходящие параметры транзишенов для этого.
И да, я очень надеюсь обойтись без дополнительного кода, кроме того, который запускает анимации. Просто в анимациях будет дорожка управления параметром power, плавно изменяющая его значение от 0.0 до 1.0; а потом при подсчёте урон будет домножаться на этот параметр. Почему так: потому что анимации в годо работают точнее всех прочих процессов во времени.
https://dropmefiles.com/kVIhb
Фикс. А то дефис прилепился к урлу.
>Или есть несколько тайлмап-слоёв?
Видеорилейтед
Ну, может, сделать фоновый слой, понятно для чего, и основной, с коллизиями
>>714297
Это нужно делать через advance_condition, но я не разобрался как. Потыкал твой проект, добавил кондишон, выставляю его в false / true - а нихуя не меняется. Полез в гугл, там у пацанов всё работает, и ещё просят инверсный кондишон им запилить. Но у меня щас голова занята другим проектом, такшта воть.
>>714303
Окей, буду исходить пока что из этих вводных - два слоя.
Отакая структура файла получается.
Перечисляем имеющиеся ассеты на локации. Указываем дополнительные параметры самой локации. В качестве ассета на пикрелейтеде тайлмап со списком всех задействованных тайлов.
Собсна, принцип тот же, что и при создании сейв-файла. И собсна, сейвы будет делать тот же код. Отличие только в том, что при девелопе игры создаётся на специальной карте-заглушке особый уличный дефолтный сейв. И старт новой игры - это по факту загрузка дефолтного сейва.
Ну, как видишь по скринам, я в большинстве случаев статически типизирую, Но бывают случаи, когда динамический тип чертовски удобен, невозможно отказаться. Например, несколько проверок, одни функции возвращают код ошибки int, а другие - bool. Заводишь один динамический error и когда надо он int, а потом bool, а потом опять int.
Да чё там раазбираться?
У тебя будут твои сцены-уровни. Ты будешь кидать в них ноду с моим скриптом и настраивать её из инспектора. В скрипт вообще заглядывать не будешь. Но даже если и заглянуть, там ничего экстраординарного нет, всё это можно найти в той же документации.
У тебя будет кнопка сделать зае "выгрузить сцену в файл". Этой кнопкой ты сформируешь набор уровней для будущей игры.
Сама игра будет из сцены с моим скриптом, которому ты будешь из меню подавать на вход имя уровня в качестве параметра, после чего он будет этот уровень загружать. Загрузка будет представлять из себя расстановку по уровню ассетов, начиная с мебели и заканчивая врагами и интерактивными объектами.
Ничего нетривиального - просто долго и муторно.
Самое муторное то, что каждый ассет следует создать как отдельную сцену и снабдить отдельным скриптом, который будет реализовывать две функции: 1) подготовка данных о себе для выгрузки, 2) загрузка данных о себе из поданной на вход переменной и установка своих параметров.
Повторюсь, в упрощённом виде это описано в документации, как система сохранения, но там меня не устраивает, что в файл сохранения пишутся пути нод. Это дичь. Мы с тобой будем писать только заранее утверждённые типы ассетов, которые будут в одном большом match выбираться и подтягиваться.
> Этой кнопкой ты сформируешь набор уровней для будущей игры.
Причем это можно делать в отдельном проекте вообще. В основном проекте будут только ассеты и локация-загрузчик, инстансы которой будут превращаться в те или иные уровни.
Если игрок сохраняется, локация-загрузчик уже выгружается тем же методом, что и в проекте-редакторе, но выгружается в файл сохранения, со всеми изменениями, которые сделал игрок.
Потом при загрузке уже уровень грузится из файла сохранения, а не из файла-эталона.
>>714608
Как обсуждали в прошлом треде, изменение значка при экспорте вызывает проблемы. Например, при упаковке пака в один экзешник. А при работе с моноверсией проблемы гарантированы в принципе. Поэтому в прошлом треде пришли к выводу, что следует загрузить свою иконку прямо в файл шаблона. А заодно и описание файла своё загрузить туда же. А чтобы не пришлось переделывать шаблон под каждую игру - можно скопировать шаблон в отдельную директорию и указать её в свойствах экспорта и носить проект вместе с шаблоном в отдельной подпапочке, если ты из нескольких мест работаешь, например (как я).
Без прописанного в настройках экспорта рцэдита годот никак не воздействует на файл, при создании вложенного PAK годот просто создаёт эдакий раржпег с приписанным паком в конце.
В годоте есть https://godotengine.org/asset-library/asset/291
Вдруг это то что тебе нужно?
>advance_condition
Прочекал имеющиеся туториалы. Чёт я всё равно не понимаю, как с его помощью сблендить несколько анимаций. И не понимаю, чем это принципиально отличается от travel. В любом случае, когда я ставлю этот адванс, он проигрывает переход до конца и только тогда переходит дальше. В любом случае в один момент времени воспроизводится только одна позиция: один узел анимации или один переход между узлами. Выглядит так, будто, вся эта тема с адвансами была оставлена как костыль для некоторых стейт-машин.
Давай обратимся к словарику англо-русского. Адванс - это выполнение. Адванс кондишн - это условие выполнения. Если я всё правильно понимаю, ты сначала задаёшь тип транзакции. Ты задаёшь "немедленно". Выставляешь галочку "авто адванс". И треугольник вовсе не поднимается. Трэвел моментально трэвелит в айдл. Ой, стоп, нам это не подходит! И тут на сцену выходит адванс кондишон. Адванс транзишона должен произойти моментально. Но только если кондишен - тру. А когда у тебя кондишен тру? Правильно, когда ты отпускаешь клавишу. Ты выставляешь тру и происходит мгновенный переход, дропая анимацию поднятия на текущем кадре.
Так оно должно работать, но у меня вчера не заработало. Я нипонил, что я сделал не так, поэтому не предоставил работающего решения. Но повторюсь, чуваки в интернете вовсю используют это и даже реквестируют инверсный функционал. Мне бы прямой функционал заставить работать, чтоб нуждаться в инверсном...
>чуваки в интернете
Ты бы хоть ссылками на чуваков поделился. Я что нашёл по advance_condition, это вот https://www.youtube.com/watch?v=rGd-B6heyKs и вот https://www.youtube.com/watch?v=zVTlBsoozlE - в обоих случаях речь просто про способ создания стейт-машины.
Я говорил вот про этот пост, он первый в результатах поиска, поэтому я даже не подумал скопировать ссылку
https://godotengine.org/qa/79382/animator-advance-conditions-but-if-the-value-is-false
Тем более, это не то, что тебе нужно сейчас.
Я тут подумал ещё один момент, тебе действительно нужен какой-то блендинг, потому что даже если заставить этот кондишен работать, анимация удара-то начинается со скажем, позиции 10, образно выражаясь, которая представляет позицию полностью занесённого над головой топора, а адванс кондишон прервёт анимацию занесения на значении, скажем, 3, после чего топор мгновенно скакнёт на позицию 10 и уже оттуда начнёт ударять. Бля, геймдев, это так ложно. Я кажется видел что-то подходящее в приложении к прыжкам на разную высоту у гейм эндевора. Но щас уже не нагуглю, это ж придётся кучу видосов пересматривать.
> может, разберусь со временем
Вот такой интерфейс я пока что тебе замутил в инспекторе.
Есть вопросы?
Да не, меня оттуда интересует только создание объекта-доски. Указываешь стартовую точку, указываешь конечную точку(в разумных пределах длины, ессно). Между ними протягивается довольно хрупкий проп-доска, имеющий физику. Что-то такое.
Хотел заебашить зону, единственной целью которой будет добраться до какого-то нужного инструмента и съебать за 60 секунд, как в том же Тирдауне.
З.Ы. А хотя... Может, заменить доски на какие-то "мосты плотного света" а-ля Портал2.
> зовите меня Какерман
Какермаааан! Ты тут?
Я вплотную подошёл к созданию базы данных ассетов. Есть пожелания по интерфейсу работы с ней? Если нет - я сделаю, как мне удобно:
1. База данных ассетов - синглтон, сидит в отдельном скрипте, автозагружается, доступна из любого другого скрипта.
2. Содержимое БДА конфигурируется отдельным словарём, в котором перечисляется всё что есть в игре с путями к файлу scn/tscn каждого ассета.
3. Есть метод asset_register(new_asset : Dictionary) который добавляет в словарь-описатель новый подсловарь. Этот метод будут юзать моды, для будущего добавления ассетов в уже имеющуюся игру. И asset_unregister(asset_name : String) для замены модами существующих изначально ассетов.
4. Есть метод get_asset(asset_name : String) который выдаёт новый экземпляр ассета по его имени в БД.
Так норм? Есть замечания? Предложения?
И таки поискал. Но не нашёл. Но я уже реализовал работающий механизм через связку StateMachine <- AnimationNodeTransition <- AnimationNodeOneShot. Логика такая:
Кнопку нажали: транзишон переходит ко второму состоянию "замах". Кнопку отпустили: транзишон переходит к первому состоянию "стейт-машина", в это же время прямо перед ним срабатывает ваншот удара.
А вот со временем удара пришлось заморочиться таким вот образом:
>anim_tree.tree_root.get_node(current_direction).get_node(current_weapon).get_node("swing_transition").xfade_time = time
И это работает. Вот только код некрасивый. Но как сделать красиво, я чёт так и не понял.
>подозрения
Вообще-то я изначально и писал, что при помощи стейт-машины реализовать у меня не получается, памагити, я только придумал как при помощи дерева сделать, и то не всё гладко. И вот что же тебя навело на такие подозрения? Может, вот это:
>StateMachine <- AnimationNodeTransition <- AnimationNodeOneShot
?
Я с самого начала писал, что стейт-машина умеет одно состояние в один момент времени, блендинг разных состояний она не умеет. И что адванс_кондишон нужен вовсе не для этого.
Вот тебе набросок простейшей стейтмашины для персонажа, который может ходить, плавать, переходить из воды на сушу и обратно, на суше может прыгать, в том числе в воду, из воды может выпрыгивать, в том числе на сушу.
Это набросок и он не учитывает кучи ньюансов. Но как отправная точка.
> Не командуй,
Если тобой не командовать - игор я не дождусь!
Gamedev aint easy
Кто догадается зачем переходы из крайних нижних положений между собой - получает пятёрку!
То есть, например, вся нода walk это на самом деле бленд-дерево, да ещё и из блендспейсов. И работает оно только, когда перс на суше и может махать мечом-топором. Как только родительская машина уходит в другое состояние, все внутри автоматически дропается.
Вот тебе и решение падающего треугольника.
Неудобно же. Придётся в каждом мини-дереве городить целый огород из дополнительных состояний.
Чел, я уже пробовал делать большую стейт-машину с деревцами внутри. Мне удобнее делать ветвящееся дерево со стейт-машинами внутри.
К тому же, при большом количестве элементов на одном уровне (в дереве или стейт-машине) Годот начинает падать. И так можно вообще сцену запороть.
У меня никакой путаницы нет. Всё удобно и раскидано по иерархии. И никаких проблем с тем, чтобы добавить ещё сколько угодно состояний на соответствующем уровне иерархии.
Да, забыл добавить к предыдущему усложнению. Ведь помимо разных видов оружия есть же симметрия. Нельзя просто отразить анимированного персонажа по горизонтали, ему нужно продублировать все анимации и стейты. Если бы был пикселярт, то можно было бы. Но с анимацией "по частям" такой фокус уже не проходит.
> У меня никакой путаницы нет.
Ну не и нет. Чего бухтеть-то?
Вот смотрю я на твои посты и вспоминается мне старинная эйчаровская притча про двух джунов, которым не перезвонили. Обоим дали одинаковое тестовое задание, состоящее из двух этапов. На первом этапе перед ними поставили простую задачку, типа 2+2 сложить. Первый (назовём его Чувак) взял Main(string[] args) {} и хуйнул решение туда. Второй (назовём его Перец) нахуярил кучу бойлерплейта, фабрику классов, класс сумматора, вся жопа в мыле, сроки завалил, штрафные баллы получил, потому что Чувак уже справился. Но дальше началась вторая часть задания, самая интересная. В течение месяца им поступали дополнительные требования к первоначальной задаче. Пересекающиеся, повторяющиеся, противоречащие тем или иным предыдущим. Чувак продолжал лепить в Main по паре ифоф на каждое требование, а Перец порождал фабрикой всё новые классы, комбинируя паттерны.
И случилось так, что к концу тестового месяца оба соискателя так запутались в своём коде, что обоих пидорнули.
А мораль сей басни такова... Впрочем, мораль я забыл.
Просто ты начал давать советы, которых не просили; а о чём просили, там ничего посоветовать не смог. Это очень раздражающая модель поведения, не важно, насколько доброжелательно она преподносится. Я понимаю, что ты из лучших побуждений, а не чтобы насрать в обсуждении, как это на ру-форумах водится; но всё равно не надо так.
Ну это да. Не на идеальному уровне, но всё-таки близко к оригиналу
> Главное чтобы было внятное ТЗ.
Haydee знаешь? Геймплей примерно представляешь? Теперь представь, что это пиксельный платформер с загадками. Состоит из отдельных комнат. Комнаты есть простые (релакс эмбиент), с загадками (загадочный эмбиент), с врагами (тревожный эмбиент). Когда враги детектят персонажку нужен файтинговый экшон трек.
Пока так.
Но собирая треки держи в уме, что возможно, каждый из них нужно будет два раза замиксовать с атмосферными вариациями (фабрика/завод, вода/бассейн).
Ну и музон на главное меню нужен, пожалуй.
И звуки интерфейса.
в гугле чёт про настройку пресетов для всех текстурок, но переключение кнопочек там чёт не помогло
В словосочетании "внятное ТЗ" акцент на слове "внятное". Оно состоит из трёх частей:
1. Описание художественной идеи. При каких обстоятельствах будет звучать трек, в каком окружении, какое настроение должен передавать игроку. Возможно, какие-то ассоциирующиеся визуальные образы или палитра цветов на экране - эти вещи тоже неплохо доносят художественную идею.
2. Два-три референса. По одному невозможно понять, в каком аспекте на него ориентироваться, так как у музыканта профдеформация, я слышу музыку вовсе не так же, как ты.
3. Всякие технические детали, например, длительность трека, громкость (лучше сразу свести под нужный уровень). Для платформера имеет значение темп, его можно понять через такие цифры, как длительность прыжка, скорость перемещения персонажа по тайлам; если он будет совершать повторяющиеся действия, то важен их тайминг. Если в интерфейсе и/или в игре будут какие-то звуки, то музыке надо быть с ними в одной тональности.
Всё это для каждого трека. И да, "замиксованные вариации" трека чаще всего следует считать отдельными треками, так как общего у них могут быть лишь один-два семпла в основе.
В общем, если не распишешь по каждому треку все три пункта, то получишь не подходящее к игре графоманство, которое ещё и не в твоём вкусе. А если распишешь, то релевантность треков будет пропорциональна квадратному корню того, насколько подробно распишешь.
Кстати, если планируется динамически менять музыку (например, персонаж нырнул в воду, трек сменился на подводную версию себя), то в Годоте с этим надо отдельно заморачиваться; помню, когда-то попадалась соответствующая статья в доках. Это так, к слову.
То был не я, если что. Не знаю, кто автор того поста.
Я определился только с тематикой жёлтой зоны, так что вряд ли запросов в ближайшее время будет много.
1. Жёлтой зоной должен быть ещё строящийся недоскрёб. По мере подъёма он постепенно превращается в голый каркас из толстенных балок. На заднем фоне не слишком живописный пейзаж из бетонных коробок того комплекса, где бродит протагонист_ка и других таких же недоскрёбов, уже достроенных.
2. В качестве референсов могу дать это:
https://www.youtube.com/watch?v=A5gfWgBXM7Y
https://www.youtube.com/watch?v=I3sKIV6KugA
https://www.youtube.com/watch?v=YK3ZP6frAMc
3. Не слишком-то громкий, ибо АДОВОГО ЭКШОНА не будет(кроме верхушки башни, но это отдельный разговор). Скорость персонажа - видеорилейтед, она небольшая. Тайминг остального подсказать не могу - ибо это самое остальное ещё надо как-то сделать. Звуки интерфейса отсутствуют(как и сам интерфейс). "Замиксованных" или подводных версий не нужно, разве что под боссов, но до боссов ещё как пешком до Египта. Под водой можно разве что чуть изменить звук, чтобы он звучал глухо, но это, думаю, программно делается.
Такие вот дела. Ничего не готово, но планы уже наполеоновские.
Не обращай внимания на этого толстяка. Перечитай его пост. Он разве что трек тебе самому не предлагает написать - столько манятребований выкатил. Проще на opengameart по тэгам подобрать подходящие треки, и не надо напрягаться перед морщащим жопу вонабикомпозитором, и лицензия CC0 (общественное достояние, никаких упоминаний).
https://opengameart.org/content/loading-screen-loop
https://opengameart.org/content/desolate
https://opengameart.org/content/underwater-theme
https://opengameart.org/content/heart-of-machine
ношол ответ, мона выставить нужные настроечки текстуры через сет флажков:
https://www.reddit.com/r/godot/comments/6h048b/how_to_disable_mipmaps_and_filter_with_gdscript/
Гуд. Если к понедельнику что-то сделаю, значит я в деле. Если нет, значит не справился и слился.
То, что все три референса это каверы на одну и ту же композицию, это просто потому что она звучала в "Ну погоди" на стройке?
>По мере подъёма он постепенно превращается
Напомнило Celeste. Там музыка менялась по чуть-чуть по мере прохождения.
>изменить звук, чтобы он звучал глухо, но это, думаю, программно делается
Делается. LowPassFilter на аудио-шину закидываешь и крутишь ему cutoff_hz, пока не будет звучать збс.
>>715199
>opengameart
Музыка с опенгеймарта, ассеты оттуда же. Код стащить со стаковерфлоу. Руководитель проекта и пиар-менеджер - робот Максим.
Или всё-таки можно сделать цельное художественное произведение, где все части будут между собой согласованы. Но для этого надо приложить усилия к координации исполнителей. Тем более художественное видение - штука комплексная, сложная и не поддающаяся формализации в своей основе. Не могу ж я у анона в голове покопаться и понять, что он там внутри себя слышит для каждого отельного уровня.
> художественное видение - штука комплексная, сложная и не поддающаяся формализации в своей основе
Формализации в виде внятного ТЗ?
Окей, окей.
>То, что все три референса это каверы на одну и ту же композицию, это просто потому что она звучала в "Ну погоди" на стройке?
Ах, я вижу, вы человек высокой культуры.
>Музыка с опенгеймарта, ассеты оттуда же. Код стащить со стаковерфлоу. Руководитель проекта и пиар-менеджер - робот Максим.
Ну, тащта, проект уже это напоминает. Текстуры персонаж_ки - отредаченные ассеты Старбаунда, тайлы - спыжжены из Classicube и слегка отредачены потому что Goodlyay - пидр, так ему и надо, коды движения - монстр Франкенштейна из разных туториалов, музыка на фоне теструма даже не маскируется.
https://www.youtube.com/watch?v=Y5_XBpjpMGU&list=OLAK5uy_m-TvPbfZv9cvM9NzxbmaheqYnYrB_3Zfw
https://www.youtube.com/watch?v=dLQzmMUcxic&list=OLAK5uy_m9p2Pg6u4GcAitpBrXznv4Cwchq1I-Yb8
Держи ещё оригинальный саундтрек обеих частей. Для сравнения и примерного понимания темпа
Вот есть платформер, человечек должен подобрать патроны. КАК?
ДЕлал через ебучий сигнал у Area2D ничего не работает.
А как стрелять?
А как моба стрелять заставить?
ты пытался, спасибо и на этом. Проблема в том, что будучи совсем не программистом и совсем зеленым, такие туторы, как в шапке читать смысла не имеет.ПОтому что стопаришься буквально на мелочах о которых хоть сколько то продвинутые чуваки даже и не думают. А ты сидишь и ломаешь голову как правильно этот area2D юзать.
Ну да, хз, как тебе помочь. Тут надо начинать с азов. Как единички и нолики в компе превращаются в программы. Информатика, 10 класс.
И всё это изучение азов должно быть помножено на неподдельный интерес, иначе не взлетит. У меня так с рисованием было. Сел, начал малевать, весь прошлый год малевал. Но интереса вообще никакого. Соответственно и выхлопа - ноль.
ну так я в школе как то паскаль учил, норм было. Ща за питон сел и хули, ни как это мне не помогает патроны подобрать.
Вот как понять когда скрипт пишешь, для какого действия че после "func" писать например? Вот в уроках же об этом не говорят. Они просто берут и пишут "вот здесь физикс процесс вощьмем, а здесьсвою напишем"
> Вот есть платформер, человечек должен подобрать патроны. КАК?
Предположим, что при приближении к патронам, у человечка над головой должна появиться надпись "Е - подобрать патроны", при нажатии Е патроны должны исчезнуть с локации, а в инвентаре человечка должно начислиться столько патронов, сколько было в этом объекте.
Вот решение в лоб:
1. Объект-патроны - это Area2D ей на сигнал on_body_enter(body) вешаешь код if body.name == "Player": body.show_message("Е - подобрать патроны")
2. Player это KinematicBody2D
3. У него есть функция show_message(msg_text) и объект-Label над головой, без текста. В функции пишешь label.text = msg_text
4. Точно так же обрабатываем выход человечка из зоны патронов:
Area2D | on_body_exit(body): if body.name == "Player": body.hide_message()
Player | hide_message(): label.text = ""
5. Теперь главное. КАК ВЗЯТЬ ПАТРОНЫ: наш человечек уже в зоне патронов и у него над головой надпись. Мы у него в _input(event) отслеживаем нажатие кнопки взаимодействия, которая, допустим Е и есть. И тут мы сталкиваемся с проблемой, зона2д знает, что человечек в неё вошёл, а человечек - нет. Как нам это исправить?
Вот решение по лбу:
1. Объект-патроны - это Area2D ей на сигнал on_body_enter(body) вешаешь код if body.is_in_group("Player"): body.post_message("entity", self) мы выявляем объекты не по именам, а по группам, и функция теперь другая, она сообщает человечку 2 аргумента, текстовый тип сообщения и ссылку на себя. тип сообщения "entity" взят с потолка, означает что поблизости сущность и вот второй аргумент - ссылка на неё.
2. Теперь при входе в разные зоны2д человечек может знать о них и ему для этого нужен только один метод. post_message(msg_type, sender). Внутри этого метода большой match msg_type в котором для каждого типа сообщения выполняются разные действия. Допустим, для "entity" он должен взять sender.hint_text и поместить себе над головой.
3. А теперь возвращаемся к _input(event) отслеживаем нажатие кнопки взаимодействия, которая, допустим Е и есть. И тут мы уже знаем, что у нас есть ссылка на зону2д с патронами и она к нам пришла через сообщение "entity" а это значит, мы можем взять у неё количество патронов и прибавить к своему инвентарю. И даже мы можем ей послать queue_free()
> Вот как понять когда скрипт пишешь, для какого действия че после "func" писать например?
Поступательно.
Знаешь мем про "нарисовать сову"?
1. Нарисуйте два овала.
2. Нарисуйте всю остальную сову.
Так же и тут.
Паскаль ты изучал. А в питоне разницы нет вообще. Вместо begin end отступ вправо, вместо := просто =, вместо = двойное ==, вместо <> будет != и не нужны ; в конце строк. Вот и вся разница. Проблема не в синтаксисе, проблема в отсутствии неподдельного интереса, который я упомянул выше. Это не фигура речи, это реальная проблема. Ты хочешь создать игру, и твоё желание настолько велико, что оно блокирует попытки интересоваться мелочами. Кодинг оно воспринимает, как мелочь, да. Так же, как и у меня моё воспринимает как мелочь рисование арта. Типа твоё подсознание такое думает "блять, точки-хуёчки, объекты-хуекты, ГДЕ МОЯ ИГРА, БЛЕАТЬ!"
Решение "по лбу" не просто так названо. Оно такое же хуёвое. Оно предлагает в коде игрока заводить код на каждую группу сущностей в игре. А если мы захотим добавить новую, нам придётся лезть в код игрока. правильное решение, когда каждый объект в игре делает только самый минимум действий. Объект-патроны должен содержать унифицированный метод, например action() который сам делает необходимые действия, когда игрок нажимает Е.
Таким образом мы убираем все эти post_message() а вешаем на Player обработчики сигналов on area enter/exit Теперь у нас и игрок автоматически знает о зоне в которую вошёл и зона знает об игроке. Зона поставляет сведения, что вывести над головой у игрока. Игрок выводит текст. Зона поставляет метод action() который может быть вызван игроком, при нажатии на кнопку экшона. Игрок безо всяких match просто вызывает этот метод у зоны, если он у неё есть: if area.has_method("action"): area.action() Зона знает об игроке и может положить ему в инвентарь нужное количество патронов, а затем самоуничтожиться.
Вот этот метод гораздо продуктивнее. Самое главное тут то, что нет прибитых гвоздями привязок одних объектов к другим. Излучается сигнал - в его аргументе есть ссылка на объект, с этим объектом выполняются нужные действия. И всё. Объект забывается навсегда при выходе из коллизии.
>Вот решение по лбу:
вот за это сспасибо, завтра буду разбираться, а то у меня 4 утра
>отсутствии неподдельного интереса,
вот тут ты ошибаешься, чувак. Интерес интересом, но вот у тебя, например, есть база програмиста наверное, тебе легче через эти дебри пробираться, а я гуманитарий неделю бьюсь по 4 часа в день и нихера. Те уроки что на ютубе есть - линейные, по ним сделать можно только то, что автор показывает, а понять и того меньше. Они не учат логике движка, они вообще нахер так то не нужны, их можно заменить одним сайтом, где будет кусок кода и пояснение что он делает, для кнтрц\кнтрлв.
Вот поэтому я и взялся за питон, но где ж его за неделю осилить то. Синтаксис не проблема.
Я конечно же искренне надеюсь, что здесь я не ошибаюсь. Неподдельный интерес к программированию у меня был 20 лет назад. И сейчас мой скилл разработан настолько, что в моей голове без труда уместится .NET5
Извини, если выразился невнятно, вот более точно:
Неподдельный интерес сегодня означает более-менее средний скилл через 20 лет.
Свет - это проблема всех движков. Свет и тени. Чем больше источников света, тем тяжелее. И точнее говоря, это не проблема движков, а проблема вычислительная вообще. Эту проблему призван решить хвалёный аппаратный рейтрейсинг. Без него освещение сцен оптимизируется всевозможными трюками. Кто во что горазд.
>вот у тебя, например, есть база програмиста
Зря ты так, бро. Бьюсь об заклад, что хоть какая-то база по программированию есть меньше чем у половины анонов в треде. Я вот (не тот анон, кому ты отвечал) музыкант по образованию, но вот не ною, кодю себе потихоньку. Никогда не получал по этой теме сколько-нибудь системной инфы, это сугубо хобби.
>>715246
>Ну, тащта, проект уже это напоминает.
А, ну, может, я тогда действительно зря впрягся? Так-то я планировал за сегодня дорисовать анимации для своего персонажа, после чего сразу же приступить к музыке. Но если проекту не планируется в других аспектах придавать уникальный облик, может, и тут заморачиваться тогда тоже не надо?
Пока что приходится одноразово исполнять чумовые конструкции вроде: if self.my_foo_bar: pass чтобы однократно лениво проинициализировать my_foo_bar через его геттер и в дальнейшем не городить режущий глаза self.
>Напрягает необходимость указывать self.varname чтобы задействовать геттер ДАЖЕ В ПОТОМКАХ! Жду четверочку, надеюсь пофиксят.
>Пока что приходится одноразово исполнять чумовые конструкции вроде: if self.my_foo_bar: pass чтобы однократно лениво проинициализировать my_foo_bar через его геттер и в дальнейшем не городить режущий глаза self.
Блин, ну как же хорошо, что я слезс с иглы гдскрипта. Прям аж подташивает от этого питоносинтаксиса.
>я гуманитарий неделю бьюсь по 4 часа в день и нихера
Вот так ты зря. Ты думал, программы делаются так: пришёл программист, легко разжал уста, и сразу запел, вдохновенный простак - пожалуйста! А кодинг по большей части состоит из "эта херня не работает, хотя я всё сделал правильно, нушонетакта!!11"
>>715359
>необходимость указывать self.varname
Шта? Это ещё зачем?
>>715365
Дело не в желании. Мне в любом случае нужно отвлечься - почти неделю выстраивал анимации. Просто а насколько оно будет уместно?
> слезс с иглы гдскрипта
Нормальный язык, чо ты? Ну, впрочем, дело вкуса. Хотя, это ещё может быть дело привычки. Меня, например, после VB5/6 подташнивало от паскаля. А потом, когда привык к паскалю, прошёл с ним от дельфи7 до ХЕ11, а потом лазарус, начало тошнить уже от VB. И всё это время тошнило от си/сиподобных. А вот уже второй год как врываюсь в шарп и теперь тошнит и от паскаля, и от VB.
Советов мудрых прошу - лучше анимировать вне годота или в нем уже? Слышал где то, что лучше анимировать уже в самом движке, хотелось бы узнать, правда ли это, и почему?
> скрафтил себе лоупольного долбоеба Боба
Глянь вот в шапке у нас есть вот такое:
>>712330 (OP)
> - Редактор персонажей на основе makehuman: https://github.com/Lexpartizan/Go_MakeHuman_dot
Анимировать лучше вне. Годот пока не доразвился до полноценной работы с тридэ-анимированием (есть сторонние модули, но это всё несерьёзно). Инструментарий скудный. На практике большинство девелоперов импортируют из блендера с уже готовым сетом анимаций. Туториалов на эту тему - море.
А вот когда у тебя модель с сетом анимаций уже загнана в годот, всё остальное (блендинг, стейтмашины) всё уже имеется, на весьма комфортном уровне.
Вы что-то делаете для своего ааа проекта?
Есть конечно, я вот тож решил один делать. Думаю вопрос о качестве ты как то странно оставил, быть универсалом это нормально, просто потребуется в разы больше времени на каждый навык и работу. Если время есть - пили в одно рыло. Хочешь быстрее - ищи команду. Некоторые вещи можешь упростить, и обыграть так чтобы это было только в плюс.
Но это всё в теории, я еще нихуя не сделал кроме долбоеба лоупольного с неправильными текстурами, который ходит, сидит и стоит, озираясь. Так что не слушай меня)
Но из своего опыта в других сферах - прокачка одного навыка не уменьшает прогресса в других, ты можешь качать ВСЕ до охуенного состояния, главное это время. Вот правильно распределять время - это самый сложный и охуенный навык, без которого нихуя и никогда у тебя не выйдет.
Я не слился, если чо.
Работаю над пикрелейтедом.
Ну и чтобы можно было лучше прописать систему хватания за уступ при прыжке. За трубы-то в оригинальной игре нельзя хвататься.
Мавр может уходить
В официльный плагин искаропки
https://www.youtube.com/watch?v=6J43yo1RXpY
Ваще не проблема. Заводи. Изначальный вопрос был (если я правильно понял), как инкапсулировать внутри тайлмапа данные о кастомных свойствах его тайлов. Это можно сделать, как предложено выше, через встроенный механизм метаданных. Можно через скрипт с массивом. Все пути открыты тебе, о юный подаван.
Но нахуя?
Речь про 2д и скелетную анимацию, есичо.
Есть две анимации: одна направо, другая налево. Допустим, это удар оружием. Кнопки "отразить по горизонтали", увы, не придумали, так что две анимации - это необходимость.
И есть дерево/стейт-машина. Вообще не важно. Важно то, что во время воспроизведения анимации игрок пытается развернуться. И что же происходит? Поскольку мы находимся в стейте "удар", то анимация переходит из правого удара в левый удар. НО (вот суть проблемы) в новом направлении анимация начинается ЗАНОВО. Таким образом, можно бесконечно разворачиваться влево-вправо, пока не доиграла анимация, она будет при каждом повороте проигрываться заново, потому что это две разные анимации.
Единственный работающий костыль, который я придумал для решения этой проблемы, это вместо нормальных переходов использовать blend2, выставленный на очень маленькое значение: тогда обе анимации начинают воспроизведение одновременно в любом случае, просто одна делает это совсем чуточку, незаметно. Но с бленд2 геморно делать плавные переходы, придётся использовать анимацию для изменения анимации, такая рекурсия мне не по нраву.
Какие ещё варианты? Адванс_кондишон тоже не подходит. Есть принципиальное ограничение движка: если анимация не воспроизводится, то положение её воспроизведения не меняется; так что, даже если адвансы из разных стейтов ведут к разным анимациям, неактивные всё равно начнут воспроизводиться с начала, как только к ним произойдёт переход. Можно просто вырубать стейт удара при развороте; но у меня есть и другие подобные ваншотные анимации, с ними так не получится по геймплейным причинам: например, перезарядка.
И да, я не помню, чтобы кто-то жаловался на подобное поведение, так как в основном Годо используют с пиксельной покадровой анимацией. Может, в треде кто-то что-то такое встречал?
Обнаружил странный баг:
Сохраняю вектор в ЖСОН. Размеется, в спецификации ЖСОНа нет векторов. Годот сохраняет его, как строку вида (х,у). Потом я в другом участке кода читаю ЖСОН. И он вместо вектора даёт мне строку. Функций конвертации я не нашёл с наскока, пните в нужном направлении, если кто знает.
Но в общем, я решил действовать исключая УБ, то есть, раз в спецификации формата нет векторов, я их и не буду писать, я всё переделал и теперь пишу массив [x,y] потом двумя лишними строчками кода читаю и формирую вектор.
> в новом направлении анимация начинается ЗАНОВО
Помнишь мы с тобой обсуждали ранее? Я предложил делать вложенные стейтмашины. И предположил, что при смене стейта во внешней машине, любые анимации внутренней будут дропнуты. Но проверять мне лень. Это ж надо городить огромный тестовый проект. (Я кидал скрины с машиной-пустышкой, но чтобы на ней оттестить, нужно анимаций наделать, а лень). А у тебя уже есть проект. Запили в нём.
Если ты придумал дохуя интересный геймплей то делай. Сделать игру и красивую и технически совершенную скорее всего не получится потому что оба эти навыка требуют дохуя времени на прокачку и у тебя они либо олба есть на среднем уровне либо один норм а второй днище.
Так например world of goo сделали два чувака. И fez помоему один или какая-то маленькая команда.
Тебе не нравится, что при быстром переключении начинает играть сначала некая долгая анимация?
Насколько я знаю, для решения этой проблемы, каждое состояние должно состоять (тавталогия, лол) из трёх анимаций: анимация входа, циклическая анимация середины, анимация выхода.
Вход и выход короткие, что органично смотрится при блендах. Середина при любом положении примерно одинакова и сносно выглядит при рандомном переключении из неё на анимацию выхода.
>Везде, если ты жмёшь разворот, то либо атака отменяется, либо поворот не срабатывает, пока атака не завершится.
Это частный случай. Вообще, на мой взгляд, разворачиваться в процессе атаки совершенно нормально, это улучшает управляемость персонажа, особенно когда нет задачи сделать хардкорную боёвку ближними орудиями.
А что скажешь про перезарядку? Понимаю, для двадэ нехарактерное действие, но всё же оно у меня есть и принимает участие в геймплее. И анимация не цикличная.
У годота есть пачка предустановленных синглтонов: Сам движок, сервер аудио, сервер физики и т.п., полный список в доках.
Так вот, все они унаследованы от Object и у всех у них есть поле script и оно у всех пустое, null. И для всех них имеется и корректно срабатывает метод set_script!
Чуешь, какие возможности появляются?
Можно расширять возможности искаробочных синглтонов, не плодя свои. Я например, пихал в автозагрузку скрипт с глобальными константами. Теперь не буду, теперь пихану их прямо в Engine.
> теперь пихану их прямо в Engine
А хотя нет, не всё туда впихнётся. В них нет доступа к дереву. Если уж и вешать глобальный скрипт, так на само дерево!
get_tree().set_script(preload("res://global_overscript_lol.gd"))
В дальнейшем можно в любом скрипте делать get_tree().my_global_something
Но есть одна проблема - нет интерфейса и следовательно, нет подсветки.
Тогда задаём глобальному скрипту class_name например GlobalScript, и затем в любом другом скрипте пишем:
var tree = get_tree() as GlobalScript
Всё, у нас есть с ссылка на дерево сцены с нашим интерфейсом (который включает наши добавочные методы и проперти).
Внутри скрипта дерева уже имеется удобная переменная root, через которую можно с лёгкостью реализовать свой собственный велосипед по менеджменту сцен (ветвей этого root)
мне нужна функция которой скажешь например 100
и она наспавнит 100 кубиков в виде пирамидки снизу верх
а теперь поясните мне почему это хуевый вариант
Примерно на 250-ом вручную прописанном кубе у тебя начнут болеть руки.
в моём случае больше кубов и не нужно
Вкачусь в соревнование.
Тайлмап не позволяет делать анимацию, как на видосе выше. Впрочем, решить эту проблему можно анимированным прокси-объектом. Объект становится по координатам следующего тайла, проигрывает анимацию выпадения, вместо него ставится тайл. Повторить.
Но вообще, хотелось бы, чтобы в искаробочном тайлмапе были индивидуальные офсеты для каждой ячейки. Чтобы создавать такие анимации выпадения, построения, наложения.
Впрочем, велосипедный тайлмап делается за пять минут. С любыми своими фичами, какие надо. Я в прошлом году делал как-то рофла ради. Код не схоронился увы. Но там даже искаробочный тайлсет-ресурс юзался.
Смотри, стрелочки доворачиваются по хитрой формуле, симулируя реальную механику.
Точнее, могли конечно и так, но копипасты было бы - мама не горюй.
А в 2020 году - хуяк-хуяк префаб на сцену и в продакшон!
func _ready() -> void:
TextEdit.text = getSource()
pass
func getSource():
var file = File.new()
file.open("user://test.txt", File.READ)
var content = file.get_as_text()
file.close()
return content
делаю так получаю пикрелатед
Залип в крите и гимпе на 2 дня. Научился обводкой обводить фотки из интернета. Фотки стрелок.
Читай файл построчно:
https://pastebin.com/d8i9hubq
Каеф!
Смотришь на ход часов и медитируешь...
>>716815
Небольшие правки
https://pastebin.com/NETDabx4
https://godotforums.org/discussion/21285/how-do-you-get-godot-internal-widgets-in-your-own-game
4ый пост в этой ссылке.
По сути нужно просто считать data и получить PoolByteArray - синусоида звукового файла.
Новости движка от Пети
https://www.youtube.com/watch?v=IZc0DYXUijQ
новая физика
новые названия нод
столкновения частиц
многооконный режим редактора
поддержка многооконности в проектах
И многое другое.
беда в том что у меня нету вулкана, а для 2D, того что есть сегодня, мне больше и не надо
Сишарп сам по себе крут, особенно с выходом .NET5, но Хуан почему-то упёрся в mono и не желает слезать. А за mono я уже ранее подробно обеснял, в чём там хуйня. Если вкратце, моно, это когда ты конпелируешь приложухи под вайн, когда есть возможность собирать нативные ELF бинарники. Иными словами, моно это сторонний костыль, когда дотнет не был кроссплатформой. Теперь дотнет кроссплатформа и держаться за моно нет никаких внятных причин.
Траблы с моно выражаются в том, что туда хочется присобачить нугет-пакеты (а иначе зачем вообще эту хуйню разводить? хочешь скорости - собери модуль на крестах, сука, вконпелируй в движок) а они не присобачиваются. Вылазит куча ошибок с зависимостями и шлёт нахуй.
С самодельно собранными модулями на крестах работа в редакторе превращается в конструктор.
Без модулей ты добавляешь ноду, прикрепляешь скрипт (гд, вижуал, шарп, раст, питон, любой имеющийся), пишешь код, нода начинает действовать как ты закодил.
С модулями: ты добавляешь ноду из модуля, и она сразу работает, выполняя высоконагруженные действия своим скомпилированным кодом. Например, ты на крестах формируешь для примера, контроллер персонажа. Добавляешь ноду MyCharacter и она сразу бегает! По нажатию клавиш/кнопок. Да, отладки не будет. Если ты ошибся, то разворачиваешься и идёшь в ИДЕ/блокнот, правишь код, конпелируешь (при наличии предкомпилированных объект-файлов движка конпеляция будет быстрее, фактически пересоберётся только твой изменившийся модуль, а потом всё слинкуется с уже сконпелированным в прошлый раз движком), тестируешь заново.
Зато никто не мешает тебе к твоей ноде прикрепить обслуживающий гд-скрипт, который будет мелочёвку выполнять, пока нода на крестах ебашит в 100500 ФПС.
Вот и получается, что шарп, особенно на моно, ни нахуй, ни впизду не нужен. Полумера. Решение для слабаков, которые не хотят стать мужиками и выучить наконец кресты.
сам проверил же? не работает
во общем не важно, подсветка синтаксиса кривая, комментарий не подсвечивает. как сделать чтоб код показывало так же как в редакторе?
add_keyword_color("Godot", Color(0.6, 1.0, 0.6, 1.0))
https://www.reddit.com/r/godot/comments/86k01c/texteditadd_keyword_color_usage/
Для тех, кто ждёт 4-ку:
Когда 4-ка релизнется, вы начнёте ждать 5-ку.
Хватит ждать! Начните прототипить игру мечты сегодня!
Это знать надо! Это классика, блять.
Задаёшь фи, предел точности, равный желаемому тебе минимуму, например 0.0001
Сравниваешь не флоаты между собой, а разность между ними по модулю и с фи. Если больше фи - значит не равны, если меньше или равно фи - значит равны.
const phi : float = 0.0001
func float_equal(f1: float, f2: float) -> bool: return true if abs(f1-f2)<=phi else false
func _on_CheckButton_pressed() -> void:
print(_checkButton.toggle_mode)
всегда пишет true
баг на баге багом погоняет...
Баги в движке есть. Но когда ты с ними реально столкнёшься, ты наоборот будешь думать, что у тебя где-то в коде ошибка или в параметрах импорта. Тру стори. Как-то в прошлом году гуглил свои проблемы с девелопом своих игор и к своему ужасу натыкался на открытые ишью по загугленной проблеме. Не помню уже, о чем речь была. Но удалось обойти.
https://www.youtube.com/watch?v=XHuB6zCQZpU
Ньюфажина врывается в тред с ноги.
1) Правильно ли я понял, что в годоте можно работать на чистом c++?
2) Есть ли гайды годота на плюсах? я их не знаю - буду учить параллельно
Задача - сделать гексогональную стратегию-тактику (я нашел хороший гайд на плюсах по гексам, а годот как раз позволяет с плюсами работать). Что в целом можете посоветовать, за исключением ссылок в оп-посте, которые я сейчас прочту?
1) Правильно. ноесть один маааалеееенький нюанс. Вся мощь редактора тебе будет недоступна. Ты будешь кодить просто модуль просто в ИДЕ.
2) Для истинного сишника лучшим гайдом являются исходники.
> Что в целом можете посоветовать
Не лезь туда, она тебя сожрёт.
> я нашел хороший гайд на плюсах по гексам, а годот как раз позволяет с плюсами работать
Вычленяешь в гайде части, которые отвечают за отрисовку, физику, звук, сеть. Переписываешь эти части с учётом нод. Конпелируешь. Запускаешь.
я просто под впечатлений от wasm в целом и мне кажется он более ближе к железу чем джаваскримпт, а godot похоже единственный кто юзает wasm
a wasm рулит, как пример raylib портированый на wasm
https://www.raylib.com/examples.html
Алсо, AudioStreamPlayer кажись багнутый в последнем релизе, т.к. даже если отключить у stream loop он все равно зацикливает, а когда в _ready stream.loop = false прописываешь - все норм.
> Открываю ассетлиб в самом годоте и он их не находит.
Есть такое.
Как-то смотрел туториал не помню по какойму вопросу, и автор презентовал собственный ассет в ассетлибе. И его тоже не было видно. Вангую, что это потому что автор указал точную версию, например 3.1.1., и теперь, для 3.2.3. её не видно. Качать браузером и устанавливать вручную.
> AudioStreamPlayer кажись багнутый
Главное, что ты решил проблему и можешь двигаться дальше.
> Главное, что ты решил проблему и можешь двигаться дальше.
Это да, не то чтобы жалуюсь сильно, просто пол часа наверное убил на то чтобы понять что я не так написал, а оказалось проблема не во мне.
>>717527
Да нет, вроде качается с сайта и дата релиза недавняя.
Уже, просто гитхаба нету и issue не открыть, а выговариваться где-то надо, кек.
>>717532
Интересненько.
Извините? Это вкладка через которую скачиваются ассеты как раз.
https://github.com/0xBFE1A8/Unity3dAndroidLiveWallpaper/tree/master/Assets/Plugins/Android
думаю с этим можно что то попытаться
Всё!
Прошлый год был весьма сложным. Но движок продолжает развиваться невзирая на сложности.
Желаю вам в наступающем году осуществить свои мечты. Преодолеть трудности. Сделать свою игру мечты. Ну а мы поможем. Подхватим.
Поднимем же бокалы под бой курантов и с новыми силами в путь - к новым свершениям.
Впереди Godot 4, с новыми, улучшенными функциями. Позади чумной ебанутый 20-тый год.
Всё, кароч, меньше слов, больше дела.
1. Насколько гдскрипт подходит для написания игрового ИИ?
Пилю подобие(надеюсь, это пока) пошаговой игры, но карта в раунде достаточно большая - от 100х100 до 250х250 клеток. В принципе, пережёвывание голых данных в питоновском прототипе работает сносно. Но это именно тупо расчёт, а не даже подобие ИИ. ИИ, насколько понимаю, ещё надо будет решать задачу поиска оптимального пути/действия, а это расчёты и нагрузка?
По сути, написание ИИ - это написание бота?
2. Использование c++ кода. Насколько понял, то он работает в виде модулей/либ/плагинов. То есть я пишу код плагина, компилю, а потом просто подключаю по условной инструкции https://docs.godotengine.org/en/3.0/tutorials/plugins/gdnative/gdnative-cpp-example.html#using-your-gdnative-module и радуюссь результату?
https://www.youtube.com/watch?v=okpKdrh3lZc
> Хочу тайловую карту, основанную на мозаике Пенроуза.
Гугл говорит, что это интересная хуйня, похожая на калейдоскоп, но я сходу не придумал применений. может ты подробнее обеснишь, зачем тебе апериодичные мозаики?
За икосферу я могу внятно обеснить, например. У неё икосаэдрическая развёртка, которая позволяет с минимальными искажениями натянуть на собственно сферу плоские карты (в том числе на полюсах). Даже на видосе видно, что весь шар состоит из четырехугольных полигонов. Но они там художественно покорёжены, идеальный же икосаэдр ровнее. Максимальные искажения находятся в 10 точках икосферы, в которых вместе сходятся 5 полигонов.
Таким образом, с точки зрения проектирования геймплея, девелопер может спроектировать плоскую карту игровых земель, развернуть её на икосаэдрическую сферу, для получения опенворлда. Стримить каждую четырёхугольную секцию общей карты при приближении игрока.
>Пусть думает столько, сколько ему нужно.
ИИ, обдумывающий ход 5-10 секунд, и ИИ, обдумывающий ход 2-3 минуты - разные вещи.
Есть у меня на работе решение, которое используют многие облачные провайдеры среднего размера. Так вот один из компонентов - некоторое количество скриптов, писанных на питоне, функции и действия там вполне себе линейные, но из-за объёмов это работает реально медленно. Потому что часть этих питонячьих скриптов имеет по 12-15к строк кода. И это тормознутая боль, а по факту чуть ли не стандарт для этой области. Для понимания. Просто вывод списка элементов, безсортировки и обработки, может занимать секунд 7. При том, что этих элементов может быть всего пара тысяч.
Есть у меня короче переменная состояния в синглтоне. Я хочу чтобы на основе значения в ней менялось управление и UI. Реализовать я думал это все через сигнал типа состояние_изменилось(прошлое, новое), чтоб ноды получали его и разбиралсь что делать. Вот только загвоздка - как элегантно динамически привязывать сигнал к определенным нодам из кода при смене сцены.
Глобальные сигналы в синглтоне спешат на помощь!
Объявляешь сигналы в синглтоне, подписываешь на них ноды. Отписывать не нужно, они это сами делают. Очень удобно. В любом месте игры излучаешь сигнал синглтона и куча подписанных на него нод автоматически выполняет действия.
Я имел ввиду циклом for пройтись по нодам и с помощью connect() привязать к ним сигнал, а потом где он не нужен просто функцию не прописывать.
Ну или можно засунуть ноды которые используют сигнал в отдельную группу и также пройтись, немного муторнее, но тогда он будет превязан только к тому что нужно.
> циклом for пройтись по нодам и с помощью connect() привязать к ним сигнал
Не. Я имел ввиду другое. Смотри, у тебя есть нода, назовём её global, в которой есть сигнал, например bullet_hit(damage, to_object). Далее, у тебя есть сцена bullet, которая собственно, олицетворяет выстрелившую пулю, которая летит, достигает любого препятствия и... И? Ты в коде этой пули, в методе move_and_collide ты получаешь коллизию, в коллизии есть ссылка на коллайдирующий объект, ты пишешь там: global.emit_signal("bullet_hit", урон_твоей_конкретной_пули, ссылка_на_объект)
И что мы получаем?
Global виден всем. Допустим, у нас есть интерфейс, который спавнит на экране циферки урона при попаданиям по объектам. Прямо в ready коннектишь ноду с этим интерфейсом к сигналу global.connect("bullet_hit", self, "on_bullet_hit") далее, создаёшь вышеуказанную функцию on_bullet_hit(damage, to_object) и можешь там работать с координатами объекта, кастуя эти координаты из тридэ на плоскость экрана, и выводя там циферки урона, который пришёл в функцию из сигнала, как в японских слешерах или файтингах.
Нода игрока так же (да что там, все ноды, принимающие урон), при своём создании подписывается на этот глобальный сигнал. И обрабатывает полученный урон.
> засунуть ноды которые используют сигнал в отдельную группу
С группами можно организовать подобие интерфейсов. Если чётко следовать самостоятельно установленному правилу, что в определённой группе могут быть только объекты с определёнными функциями, то группы становятся типа как интерфейсы, достаточно чекнуть is_in_group для входящего объекта, чтобы в дальнейшем не чекать вызываемые на нём методы.
С какой стороны браться? Слабо представляю. Вроде нужно поднять сервер, к которому игрушка будет обращаться, и его можно так понял на чём угодно писать..
>>718276
Вообще говоря, от годота вообще ничего по части сервера не требуется. Сервер - это такая стэндэлон приложуха, которая просто обрабатывает приходящие соединения, пережовывает по заложенной логике пришедшие данные, опционально, работает с БД.
В бытность моего знакомства с юнити в 2015, несмотря на наличие там сетевой компоненты, оказалось проще клиента на чистом c# по примерам с msdn написать (но в рамках юнити, тогда ещё был моно без бгмерзкой ms vs), а сервер я накидал на c++ (по старой памяти, ибо до 2010 года всё клиент-серверное писал на плюсах, потому что другого сильно и не было) и запускал его на центосе (при этом клиент, написанный в юнити, естественно, работал под виндой). Сейчас с этим проще. Есть вроде как ебово быстрый, простой и с кучей библиотек go. Но я таки и не разродился начать писать на нём, потому что по научной сфере уже не нужно стало, а в сфере работы я занимаюсь скорее инженерными делами, нежели написанием кода. Да и то, баш и питоноскрипты для управления приложениями в докере - очень условное написание кода.
Простой udp-клиент на сисярпе занимает треть страницы кода, udp-сервер на cpp - пол страницы кода.
tl;dr
Сервер можешь писать на чём угодно/удобно, от годота тебе понадобится изучить только то, как поднять соединение как клиенту и обмениваться данными.
> один из вариантов - сервер с логикой это просто игра на годоте, запущенная на сервере
> Она может не рисовать графику, но рассчитывать физику и тому подобное
Именно!
Если делать стандалон-приложуху, как предложил анон выше, придётся либо велосипедить весь движковый АПИ, либо тянуть зависимостями.
Но зачем, если есть >>718326 ?
Ну в принципе, да. Можно принимать и отдавать абстрактные метаданные собственного формата. Этим и хороша клиент-серверная технология. Сервер может быть вообще хоть на лиспе написан. А клиенты на годоте(пека/линукс), юнити(мобилки/консоли) и уе(пека/виндовс).
Есть гексагональная решётка, я могу определить над каким тайлом мышка, и мне надо тайл подсветить. Как это лучше сделать? Из мыслей, только сделать прозрачный гридмап сверху, заполнить его гексагонами, а при наведении мыши на определённый - подсвечивать его, меняя характеристики material в surface для этого мешлиба.
Но тут вопрос. Я так вообще взаимодействовать с мешами на гридмапе могу? Может есть какой другой способ более православный?
Отдельный сервер со своим форматом хорош тем, что ты не привязан к платформе клиента, поэтому переход с движка на движок, или даже с одной мажорной версии в другую в рамках одного движка, не станет головной болью. Ну и плюс если есть ошибки на сервере, то ты точно будешь уверен, что это именно твои ошибки и не будешь грешить почём зря на тот же годот/движокнейм.
Православных способов тут нет. Ты можешь
1. Наложить спрайт с эффектом поверх тайла. Координаты тебе тайлмап отдаст.
2. Наложить тайлмап поверх тайлмапа.
3. Предусмотреть подсвеченные версии тайлов в тайлсете.
И ещё куча способов, которые я с наскоку не припомнил.
Всё зависит от твоих личных предпочтений. Что тебе удобнее - то и используй.
Это отдельная тема для разговора, кстати. Но в любом клиент-серверном приложении как аксиому надо принимать утрверждение "никаким данным, приходящим от клиента, доверять нельзя".
Это, кстати, одна из причин говен, случившихся с fallout 76. Насколько я помню, там скорость персонажа зависила от фпс, например, а данные считались локально у каждого клиента, а через сервер только пересылались. При этом беседка таки неиллюзорные баны выписывала налево и направо, разобравшись как следует, и наказав, кого попало, за читы, дюпы и баги. Причём порой и неумышленные.
По логике вещей, правильно написанный сервер приводит к отпаданию необходимости думать об античитах.
Хотя, нечестная игра может и через локальный клиент может быть устроена, но это редкие частности. Помню, что во времена конца лича и цлк - катаклизма и сумеречного бастиона в вове был аддон, который проецировал на текстуры локального клиента зоны, куда боссы будут/могут ложить говно, отчего юзавшие аддон резко начали по эффективности приближаться к мастерам выбегания из огня, кто это делал своим скиллом. Естественно, что после того, как аддон побанили, то и скилл у новоявленных героев пве резко протух. И при этом, как я сказал, этот аддон никак с сервером не взаимодействовал и влияния не оказывал.
На хабре, помнится, по тэгу геймдева за последние лет 6 немало материала было на предмет того, где можно накосячить, когда пишешь свой собственный сервер.
От дудосов ты никуда не денешься. Причём от ddos игроделы страдают очень сильно, и, самое обидное, им никто помочь не может. Работаю на удалёнке в одной зарубежной конторе, занимающейся ддос-защитой. К нам приходят держатели серверов, но защищаются на общих основаниях. Отсюда проблемы - системы могут легко сильно порезать и легитимный udp-трафик при ddos.
А помочь чувакам ничем толком и не можем (о чём сразу предупреждаем). Потому что, считай, что под каждую конкретную игру надо отдельно изучить игровые протоколы и писать реализацию фильтров, что будут работать. Но это немалые человекочасы, а приходящие игроделы просто не платят столько денег. Патовая ситуация.
Из вариантов, что вижу лично я, это писать сервер, который логикой устоит против большого потока трафика, ставить несколько серверов по всему миру + искать хостера, где ты сможешь ставить свой сервер, и который тебя бы не начал выгонять при ddos на тебя. Вот с последним это самая жопа. Потому что народ к нам приходит, кого хостеры выгоняют даже с дедиков просто при ddos мощностью всего 20-30 Гбит-сек, не говоря уж о более мощеых атаках.
Но в реальности я бы назвал обдумывание этой проблемы преждевременной оптимизацией. У тебя ещё не написан сервер, а ты уже начинаешь обдумывать проблемы, которые будут очень нескоро и вообще могут не случиться. Я бы на этот момент забил бы и просто писал бы игру сервер. А потом уже думал бы над защитой, потому что против ddos в одиночку ты ничего не придумаешь, тебе придётся продумывать потом использование возможностей провайдеров защиты. А у них там и за пол года всё может сильно поменяться.
Урааааа!Заработало.Нужно было загрузить нативные скрипты как новый ресурс в памяти,точно также,как и нативную либу.Но это только начало.Ничего не заработало,хотя и ошибок не было(были ошибки открытия либы,но после передергивания годота они ушли).Начал пихать Godot::print() в класс push_me,и куда бы я его не пихал,результата не получил.Проблема была в функции godot_nativescript_init(void*handle).Там был зарегистрирован класс GDExample(которую я переделал под класс падения сцены).Нужно было зарегистрировать класс push_me.После этого отладочный сообщения заработали,однако сцена упрорно не хотела появлятся.И тут я,как долбан понял,что не инициализировал переменную new_position.Там было говно,очень большое число.Ну я и присвоил 0,и все заработало.Все офигенно.Спасибо за помощь.
Ищу разработчика на годоте для своей игры.
>>718332
>>718372
Смог установить TCP соединение между годот-игрулей и приложухой-сервом на плюсах, а как обмениваться инфой не выкупил)))
Объясните нубу-нуфагу разницу между велосити и позишин
А, как у Фрикционалов. Не, я такого дзюцу пока не знаю, но могу поманяфантазировать по поводу создания объекта grab, двигающегося к центру экрана, к которому ящик липнет, плюс какие-либо рельсы, на которых ящик стоит. Если скорость >50, проиграть hurr_durr.ogg.
Лол, блять. В такие моменты создаётся впечатление, что Анонимуус Всевидящий Един, но Бес-Пределен, следит за мной, ибо только что закончил просмотр пикрелейтеда.
Пока что думаю насчет рельсов, плюс перехватывать управление осями мышки на время захвата ящика/двери/вентиля. После чего, вытягивание мышки на себя двигает объект вперёд, оттягивание от себя - назад, круговые движения - вращение.
А зачем CollisionShape сделаны отдельными нодами, а не полем для соответствующих им нод?
Пока вижу только одну гипотетическую модель использования - это навешиваем на один меш кучу разных таких shape-ов, затем каждому shape-у навешимаем отдельный свой скрипт с какой-то логикой.. или в родительскую ноду засовываем скрипт, который отключает эти фигуры коллизий по отдельности каждую.. Но зачем это нужно городить в обоих этих случаях непонятно.
Может это как-то еще очевидно используется и я туплю?
Вот эта функция, например
https://docs.godotengine.org/ru/stable/classes/class_collisionobject.html#class-collisionobject-method-shape-owner-add-shape
Если я правильно понял, тут идёт обращение к буллету напрямую, потому что АПИ пестрит непривычными для всего остального годота интами-индексами.
Впервые слышу. Можно ссылочку на твит?
Когда я делал клон бомбермена джва года назад, со светом проблем не испытывал. Проблемы испытывал кокрастоке с отсутствием батчинга спрайтов огня и дыма, спавнящихся партикл-материалом. А свет (вспышка от взрыва) отрабатывал норм (по моим субъективным ощущениям).
Хочу ещё убрать архивы. Если они кому-то реально нужны, архивировать их всё равно буду, и оставлять ссылку на крайний.
Что ещё вы бы хотели видеть или не видеть в шапке?
Дискасс.
>переделать нумерацию в стиле год.месяц.номер_треда,
Дата публикации и так заголовке поста присутствует. Смысл её дублировать?
>архивировать их всё равно буду, и оставлять ссылку на крайний
Тащемта общепринятая практика. Нет смысла хранить все ссылки на все прошлые треды.
Если ли для годота возможность работать с векторной графикой? Ищу либы или движки чтобы один проект реализовать, где будет смесь 3д и 2д (векторной) графики.
Нужен либо модуль либо хотя бы возможность встроить чистую либу для работы с векторной графикой.
Суть именно в том, что множество объектов 2д графики будут параметризируемыми. Тобишь будут условно шаблонные части рукоятки, лезвия и прочего, и с помощью определенных тегов можно будет задавать ширину, высоту, морфить объекты или применять текстуры и прочее.
Само собой объекты после параметризации будут растеризироваться (рендеринг более оптимален), но я пока не нашел в интернете чтобы годот вообще умел общаться с вектором.
Рандомпиковый римворлд не на векторной графике, но выглядит будто бы на ней.
Есть, но скудноваты. Например, сглаживание не имплементировано.
На уровне кода графика векторная, однако, нарисованные фигуры внутри движка конвертируются в текстуру на спрайтовом меше. Технологическое ограничение жи есть.
Если тебя это устраивает, то создаёшь на пустом потомке CanvasItem (а это зелёные и синие ноды) функцию-колбэк _draw():
И в ней вызываешь функции векторного рисования draw_чонибудь(), например draw_line(), draw_circle()
Подробности в документации.
Пример векторной графики был прямо ИТТ: >>716647 >>716654 >>716667 >>716821 >>716834
Вообще, есть вот такая библиотека https://blend2d.com/, и по идее ее должно быть достаточно, но я пока не знаю можно ли ее вообще подружить с годотом.
>>719931
Я ошибся, я имел ввиду ВЕКТОРИК. :^)
Вот мне нужно именно это, то что ты описал.
Вообще я хотел использовать годот только как готовый рендер движок. Большиснтво логики будет вынесено в одтельный ехешник, сделано на entt, и будет технически являться сервером. С клиентом серверы будут разделять только ресурсы и возможно попробую встроить daScript для AOT скриптинга
Мгновенный гугл в соседней вкладке говорит мне, что существующие импортеры свг искаропки растеризуют свг при импорте. Стало быть, тебе как минимум придётся писать собственный парсер свг, который динамически отрисовывает примитивы оттуда вышеописанными функциями в колбэке отрисовки: >>719929
... если конечно, кто-то уже не написал такой парсер.
> можно ли ее вообще подружить с годотом
Всё, что написано на одном языке можно подружить ПАТТЕРНОМ ПРОЕКТИРОВАНИЯ АДАПТЕР, а годот и вышеуказанная либа оба написаны на крестах.
Следовательно, ты можешь написать на крестах модуль-адаптер, добавляющий в годот ноду-отрисовщик бленд2д и переконпелировать.
А вот этот видос видел?
https://www.youtube.com/watch?v=RTfPIK4sAd0
Есть там что полезное? Я просто с работы. Не могу видосы смотреть, коллеги палят.
Ну делать нечего. Моя идея мне уже какой год жжот жопу, я всё отнекивался думал ничего не сделаю (за это время накириллил на 170 страниц в надежде что наваждение уйдёт. Не ушло.). Но видимо пора.