Краткий гайд по вкату в движок:
1. Читать документацию.
2. Качать примеры.
3. ПРОФИТ!
Ссылки
Руководство по стилю: https://docs.godotengine.org/ru/stable/tutorials/scripting/gdscript/gdscript_styleguide.html
Документация: https://docs.godotengine.org/ru/latest/ https://docs.godotengine.org/en/stable/
Скачать движок: https://godotengine.org/download/ или http://store.steampowered.com/app/404790/Godot_Engine/
Новости движка: https://godotengine.org/news/
FAQ: https://docs.godotengine.org/ru/latest/about/faq.html
Примеры качаются прямо в движке через свой магазин в отдельной вкладке AssetLib. Там есть всё - от платформера до чата.
Играть в игродела онлайн без регистрации: https://editor.godotengine.org/releases/latest/ с дивана нельзя.
Игры, созданные глобальными кириллами: 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 в папку и импортируется.
Туториал по шейдерам: https://github.com/Volkovina/GLES-2.0-2D-Fragment-Shader-Tutorial-Series-in-Godot-Beginner-to-Advanced ГЛЕС2, да, но ты сначала БАЗУ выучи, ёпт!
Для любителей пощекотать конпеляцию
Лучше кинуть ссылку на список всех языков: 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
Предыдущий: >>841833 (OP)
Архивный: >>833955 (OP)
В AndroidManifest прописываю, что нужно отключить, но всё затирается при экспорте.
В самом Годоте указываю только 2 нужных разрешения, но видимо из-за плагинов подключаются ещё 3 лишних. Как мне от них избавиться?
Могу ошибаться, но сейчас такой схемы нет, т.к. в шаблоне экспорта уже есть worker.js, то это вроде означает что она и есть многопоточная по умолчанию. А разделение версий тогда между threaded и threaded+dynamic linking
ссылки на herokuapp.com из шапки надо убрать, ведь там закрыли фри хостинг.
Настолько паршиво мне ещё никогда не было... Ещё одного провала я не выдержу! Пришло время окончательно перестать пытаться, снять розовые очки, и не обманывать себя.
А у меня наоборот сейчас все круто, очередную игру доделываю, и уже следующий протоип начал с художником пилить.
а экспорт веба теперь, что ругается, SharedArrayBuffer перевод в enabled у браузера не помогло
Error
The following features required to run Godot projects on the Web are missing:
Cross Origin Isolation - Check web server configuration (send correct headers)
SharedArrayBuffer - Check web server configuration (send correct headers)
Насколько я знаю такой экспорт уже нельзя просто в браузере открыть, надо именно минимальный вебсервер запускать, и там должны быть флаги указаны. Вот такой сейчас сервак набросал. Открывать в браузере соответственно localhost:8003, порт можно поменять.
https://gist.github.com/realgdman/4e56a02c7ed05df035673ed9c16ff1c7
ну я тоже не просто в браузере, оно и раньше не открывалось
пробую через python -m http.server
потом уже в браузере захожу на localhost
а куда-нибудь выкладывал для теста vk/yandex/itch или еще?
-m http.server не хватит потому что надо возвращать два ответа в хедере, а еще и тип для .js. Просто вместо него запускай gist выше.
>>852224
На itch должно работать, раньше надо было просить админа включить эти хидеры, но сейчас там вроде просто галочку сам ставишь.
о, благодарю, сейчас для тестирования самое оно
надеюсь, что сервисах тоже потом все нормально запустится
раньше вроде было что-то типа connect("orientation_changed", _on_orientation_changed) у дисплея рута, сейчас не нахожу где такое узнать
Сигнала такого вроде не было
Есть screen_get_orientation в VisualServer, надо проверять самому
Есть сигнал size_changed у Viewport, но я хз приходит ли он при смене ориентации.
> screen_get_orientation в VisualServer
эта штука просто возвращает то, что ты установишь через. Типа пишешь DisplayServer.screen_set_orientation(DisplayServer.SCREEN_SENSOR) и он тебе на мобилках всегда будет возвращать 6 для любого положения телефона
а попып так и не починили, сколько бэт назад я им уже скидывал код
там просто тестовая кнопка, какая игровая логика
единственный вариант, что раскопал пока - это сохранять состояние игры постоянно
Когда приложение скрывается с экрана - оно получает от системы сигнал (сообщение). Дальше сам.
Не, только что проверил, сам годот не сбрасывает.
Если у тебя сбрасывает, то это в самом андроиде из памяти приложение выкинуло.
Или память кончилась в телефоне (такое может быть если ты во время разработки на что-то другое переключаешься)
Либо грешат всякие настройки энергосбережения. Особенно xiaomi в начале таким отличилась, что даже мессенджеры выкидывала.
Можешь проверить на других играх из плейстора, выкидывает ли их при сворачивании.
ну или ты написал сам какую-то логику что она у тебя по screen_resize перезапускает сцену
Но ведь у тебя в консоли должно быть красненьким написано сто раз, что dowm не существует.
ну тут короче с одной стороны мне спать больше нужно, да..
на андроиде есть три кнопки: условное треугольник, круг, квадрат
я "сворачивал" на квадрат, а это штука видимо закрывает приложение но оставляет в памяти, поэтому проверил на других - тоже нажимаешь на запущенные приложение, оно там есть, только фон приложений черный, вот в этом случае оно и сбрасывалось до начального любое приложение, а вот когда на круг нажимаешь, то любое приложение просто мгновенно скрывается и когда начинаешь выбирать, то там уже даже на фоне видно было, что сохраняется фон и при разворачивании все норм
но вот второй вопрос, я когда квадрат нажимаю у какой-нибудь три-в-ряд скаченной, то он не сворачивает, а выкидывает в окно игры "выйти из приложения?" как мне также обработать этот сигнал нажатия на квадрат?
это вот какое-то такое как на пике уведомление обработать или это сигнал какой?
короче разобрался, чтобы он не выходил в настройках проекта в Приложение -> Конфигурация последнее поле Quit on Go Back убираем галочку, тогда не выходит при нажатии квадрата
для добавления собственного поведения прописываем:
func _notification(what):
if what == NOTIFICATION_WM_GO_BACK_REQUEST:
pass # собственное поведение
>>852762
еще раз спасибо
пиздос как пофиксить, всю ночь проебал, а всего-то хотел рекламку в мобильную игрушку подключить через плагин этого чела:
github.com/DmitriiFeshchenko/godot-appodeal-editor-plugin
юзаю апподил без всяких адмобов, а все советы по фиксу про вписывание айди адмоба......
подергал DisplayServer, viewport у рута, все вроде как положено, нигде никаких смещений
> Тот кто утверждал что у меня получится сделать игру, уебан!
Я не уебан! Я - уеьан!
Это какая версия движка/андроида? Никогда такого не встречал.
не думаю, что это из-за устройства
версия движка 4 несколько последних бэт проверил - такое же поведение
проверил только что: телефон android 8, планшет android 10
экспорт в режиме gl_compatibility, ориентация Sensor
> версия движка 4
С этого и надо было начинать.
> я - сорока-белобока, ведусь на всё новое, блестящее
Сам себе злобный буратина - лезешь в продакшон на нестабильной сырой версии движка. Бери трёшку и не выёбывайся.
А, так ты бета тесты проводишь. Тогда пиши авторам issue на гитхабе, раз баг нашел.
> Сам себе злобный буратина - лезешь в продакшон на нестабильной сырой версии движка.
в продакшене у нас пока еще тройка держится из последних сил
>>852873
ну так я и спрашиваю - это только у меня такое, что я где-то тупанул и что-то не так сделал или можно заводить ишью и разбираться уже в движке самом искать
если у кого есть четверка еще - попробуйте, отпишитесь, что как
Я вчера пробовал, нормально повернулось, beta14, в _ready DisplayServer.screen_set_orientation(DisplayServer.SCREEN_SENSOR), в настройках проекта тоже Orientation Sensor, андроид у меня нестандартный, 8 на LineageOs.
ладно, возможно это еще от версий sdk/ndk зависит, будем копать, спасибо
А пробовал по другому запускать? Ну там, наоборот начать в портретной, повернуть. Или сделать не Sensor, а указать явно Portrait или Landscape.
Вообще в моб играх редко делают смену L/P. Все же геймдизайн прибивают гвоздями к одному варианту. Если только вы какое то приложение делаете.
Мое ИМХО прежнее - раньше 4.2 в прод тащить рано, слишком много фич порезали ради ускоренного выпуска.
Я только к 3d modificators stack привык...
> раньше 4.2 в прод тащить рано, слишком много фич порезали ради ускоренного выпуска
ну если что-то масштабное и крупное - да, пока не стоит в прод тащить или расчитывать, что выход не прямо со дня на день
для многих мобило-веб игр нам уже всего хватает в четверке и багов нет, поэтому такие новые уже будем на четверке
Как с гит хаба что-то скачать? Качаю архив, там вроде файлы какие-то. Годот их не видит. Шо? Каво? Что происходит? Как это заставить работать?
class A:
var x = 5
func _init():
# большая логика
class B extends A:
func _ready():
x = 666 # ???
есть ли способ присвоить значение переменной базового класса, без использования функции _ready() и без использования _init() потому что придется выносить всю большую логику базового класса в отдельную функцию и дергать ее
Кинь ссылку, что качаешь и скажи, что хочешь получить в итоге
Типа на гите лежит чей-то проэкт и тебе его запустить нужно чи шо?
Да, хочу запустить и поковыряться в этом.
https://github.com/GDquest/godot-open-rpg
Посмотреть, что внутри написано, какие решения использованы и т.д
1) скачиваешь этот zip с гита
2) в папку со своими поектами или еще куда-то засовываешь то, что в архиве называется "godot" - это папка с проектом
3) запускаешь двиг, жмешь кнопку "сканировать" и выбираешь эту папку "godot" пик1
4) все, оно добавилось в список проектов и просто запускаешь пик2
> Годот их не видит. Шо? Каво? Что происходит? Как это заставить работать?
> я дед 35 лет
Возраст не при чём. У нас тут в прошлых тредах деды за 50 успешно вкатывались, не задавая подобных вопросов.
А оказалось пикрелейтед на встройке, пиздос.
Да, тоже пробовал на некро неттопе запустить движок, там если gl 3.3 не поддерживается, то ни 3.5 ни 4 не запустит скорее всего
Попробуй накатить драйверы Mesa, на некоторых моделях помогает
Потому что для нуба такое воссоздать нереально по моему.
>Из коробки адаптер поддерживает следующие API: DirectX версии 10.1 и OpenGL 3.3 (только на Linux или OS X, на Windows поддерживается лишь OpenGL 3.1)
Похуй короче. Буду играть в Pharaoh или еще какое говно из нулевых.
так ты бы попробовал, там не сложно, я свой древний asus, который тоже только под виндой 2.1 gl видел качнул до 4.2 и все завелось
вон, сегодня как раз новый релиз сделали, это знак
отсюда скачиваешь, если проц поддерживает sse3, то mesa3d-22.3.4-release-mingw.7z
, если нет, то mesa3d-22.3.4-release-msvc.7z
распаковываешь в любое место, там запускаешь батник systemwidedeploy, сначала текст будет, нажмешь любую кнопку появится выбор как на пике, выбираешь 1 жмешь энтер, потом все можешь закрывать и перезагружаться, хотя у меня gpu-z даже без перезагрузки сразу видела результаты, так что это для верности
https://github.com/pal1000/mesa-dist-win/releases/tag/22.3.4
Ну чет нихуя, деплойнулось норм, ребутнулся, ничего не изменилось.
на канале Heart Beast есть плейлист с созданием арпг в годоте
> пикрелейтед на встройке, пиздос
Чё у тебя тридцатки на новую печ не наберётся?
А нахуй мне вставлять тридцатку в мать 2011 года? С ксеоном конечно оно вроде нормально будет, но я лучше сначала остальное грейдану (не скоро) и посижу на некстген встройке пока на 3060 собирать буду.
Но вот теперь настало знакомство с годотом. И я вообще не понимаю каким образом мне засунуть туда саму карту.
Вернее как это у вас в геймдеве принято делать?
Есть локация, грубо говоря на ней расставлены элементы окружения - костер, заборчик, несколько деревьев, лагерь. Это все нужно переносить целиком как сцену, или сначала мне нужно перенести плейн на котором это все стоит, отдельно засунуть костер и вручную его ещё раз поставить?
Или плейн нужно вообще убирать и вместо него из куба делать террейн с нуля? Как делаете вы?
то, что ты делал - это строго говоря просто визуал, как именно ты его будешь применять зависит от жанра и поставленной задачи
если тебе сценку создать где перс бегает по какой-то условной земельке, которую ты нарисовал и стукался о деревья, которые ты нарисовал, то удобнее как и везде сформировать какой-то ассет(сцены в годоте), который ты как-то расставишь или что-то еще будешь с ним делать
в любых движках примерно одно и то же: создаешь в дереве сцены какой-то объект/узел для удобства последующей работы, в него кидаешь свою модель - это будет просто визуал, также кидаешь то, обо что физический движок будет стукаться, например, в Godot можно использовать для этого CollisionShape3D
так повторяешь со всеми своими модельками, об которые стукаться будешь, если они просто фон где-то, то можно просто модель в сцену перетащить и все
То есть нет никакой разницы будет ли это плоскость или кубик
Многое зависит от жанра и требуемой интерактивности.
Можно и просто сценой, если тебе надо например просто статичная комната на фоне.
Но лучше конечно, объекты по отдельности - ведь так потом можно будет добавить им взаимодейтсвие, дублировать, процедурно генерировать, и так далее.
>вручную его ещё раз поставить?
Не знаю как в майе, но из блендера когда импортирую сцену, там же вроде объекты и так разделены. Что-то можно автоматизировать из движка, например ты в 3д редакторе только отмечаешь места где будут объекты, а в движке уже их там спавнить.
>Или плейн нужно вообще убирать и вместо него из куба делать террейн с нуля?
В годоте есть ассет террейна, основанный на карте высот. Там или в движке горы рисуешь, или просто на 2д карте в 2д редакторе.
Если ты хочешь просто налепить свой меш, то лепи.
Как анон выше написал, это просто визуал, он не всегда совпадает с коллайдерами.
Плейн в общем ни для чего не нужен, пол в годоте можно за пару кликов добавить.
> То есть нет никакой разницы будет ли это плоскость или кубик
все очень зависит от задачи и жанра, визуал делают уже после всего этого
путей работы много, может моделлер заранее в условном блендере сделать нужную форму для столкновений объекта в игре, может быть произведена генерация из модели в движке, может быть сделано через шейдер и динамически вычисляться...
> Тут все в основном 3д делают?
у нас в компании 2d почти всё: мобилки, веб, немного есть 3d, но и там по большей части просто задники, лоу-поли модельки и тому подобное
чисто для себя тоже поровну тыкаюсь и в то и в другое
Чувствую что перед этим должен выполнить обещание по захоронению
Невозможно,Так как у игроков свое понятие лучше.
В целом уже все варианты игр придуманы
Тогда вкатывайся в разработку движка, там еще работы немеряно.
Ага, а потом выходит геншин который неплохо едет на придуманных раньше ммо и гаче, и ему норм.
> но все уже придумано
И что?
Глупейший аргумент.
Главное не то, что всё уже придумано, а то что некоторое из придуманного защищено патентом. Поэтому единственное, что тебя должно останавливать от воровства чужих идей - это патенты. Берёшь механики, которые не запатентованы, делаешь из них игру и продаёшь.
> Зачем покупать хлеб, если я могу есть пирожные?
Так вижу.
> у игроков свое понятие
У меня для тебя два простых правила:
1. Игрок не знает, чего он хочет.
2. Если тебе интересно играть в свою игру - на неё найдутся покупатели.
Попробуй скрестить жанры/игры попроще, Геншин тут как пример.
Вон недавно вышел Дом Кипер, это древний motherload с кусочком ТД, людям зашло.
Проблема когда ты не можешь сделать то, чего хочешь.. Когда даже все твои старания не достаточно для простенького результата.
> делаешь из них игру и продаёшь
подход менеджера, а не творца
> а не творца
К сожалению, в мире, в который нас занесло, победил капитализм. Вкалывают не роботы. Вкалывает человек. Сначала хлебушек, а затем высокое искусство. Я сам этого долго не мог принять. И ты это примешь.
Смешанные чувства. Многое переделывают, апи успевают поменять прямо между бетами (хотя логично было бы заморозить фичи), много фич вырезают поскольку не успевают. С одной стороны хочется, с другой - ну вот как раньше считал что раньше 4.2 нельзя переползать, так и считаю.
Анон, не ведись, тебя тролль байтит на бан. Просто репорти его молча и все.
>пусть мы будем жить во лжи, но лучше мы будем жить в мире
а так не бывает, и отрицалово особенно от вечно врущих совков ничего в этой базе уже не меняет.
доказано совками ))
Еще почему-то в 4 теперь std::cout не пишет в консоль.
Конечно можно сделать
#include <godot_cpp/variant/utility_functions.hpp>
godot::UtilityFunctions::print("godot::UtilityFunctions::print called ", godot::itos(42));
Но придется логгированию обертку написать.
Вот у меня есть _physics_process в ноде и в детях. Есть какой-то гарантированный порядок их срабатывания? Типа как с _реади, сначала опрашиваются дети, потом родитель. В смысле, я могу быстренько накидать дерево и принтами проверить. Но вдруг это рандом, и у меня сейчас сработает так, а в более комплексных сценах иначе.
Я, конечно, могу просто из родительского _процесса вызывать соответствующие функции в детях, но это как-то не кошерно. Хочется по красоте.
Не знаю, а зачем тебе такое? Если есть явная зависимость, лучше из процесс одного вызвать, скажем, функцию чайлда. Алсо есть какое-то свойство ноды priority, оно точно должно гарантировать порядок.
Ну например, чтобы стейт-машина отрабатывала стейт в предсказуемое время относительно родителя-персонажа. Персонаж должен мув_энд_слайд в своём физикс_процессе желательно тогда, когда стейт ему посчитает велосити.
Можно и вызывать из родителя, да. Но я ж говорю: некошерно как-то ощущается.
>>855799 >>855789 >>855779 >>855768 >>855759
Блять, моча, подотри, у тебя политач протёк.
Все самые продаваемые инди-игры последних лет - давно придуманные механики, вынутые из забытья и немного отполированные. Взяв концепцию из какой-нибудь древней игрули 80-90х годов и просто повторив её с современным подходом, ты имеешь некислый шанс получить на выходе большой хит.
> Есть какой-то гарантированный порядок их срабатывания?
насколько я помню это вещь распараллеливается физическим движком, чтобы это было быстро, поэтому предсказать порядок ты не сможешь
под свои задачи у тебя есть слои физики или если вдруг по какой-то причине это критично (хотя на смещение абсолютно не важно в игре кто там первый двинулся в конкретно эту 1/60 секунды), то можешь, например, после вызова обработки физики родителя, просто вызывать my_physic() у детей и так далее по иерархии, но скорость пострадаает
или добро пожаловать в код движка, берешь библиотеку для вычисления детерминированной физики и корячиваешь в движок для своей специфичной задачи (как и почти в любом крупном движке)
>для своей специфичной задачи
Наоборот, задача вполне типичная. Банальная стейт-машина, где каждый стейт это нода, которая сама за себя отвечает, сама считает персу велосити, а ему остаётся только в конце физикса подвинуться мув_энд_слайдом. Я просто думал, что есть какая-то последовательность. А если там всё параллельно, то просто из перса надо стейты опрашивать и всё.
В том то и фишка, что если у тебя система считает персу велосити, то она уже не сама за себя отвечает. Тем более если порядок вдруг важен. Но для этого можно использовать process_priority.
process_priority влияет же только на _process, а на физикс не влияет.
>...то она уже не сама за себя отвечает
Ну не душни, а. Корова даёт молоко, но в целом сама ходит по лужку, щиплет травку и в молоко её перерабатывает. Нода даёт велосити, но в целом сама внутри себя всё считает. А если так рассуждать, как ты, и делать кучу не взаимосвязанных объектов, то получится уже не игра, а просто куча объектов.
У меня так работает. Есть персонаж, он же стейт-машина. Внутри него лежат ноды-стейты. Нода "ходить", нода "стоять", например. Каждый такт перс опрашивает свои стейты, выбирает самый подходящий, затем в нём вызывает основную функцию, и стейт самостоятельно считаети говорит, как нам персонажа двинуть. Так как к физическому движку лучше обращаться непосредственно из кинематика, то стейты просто меняют велосити, а двигается уже сам перс.
С нодами ходьбы и стояния перс не умеет, например, плавать. Добавив ноду плавания, мы автоматически обучим его этому действию, не надо никаких дополнительных телодвижений. Я делаю кучку разных нод и, по-разному комбинируя их, получаю набор персонажей с разными способностями. Это при том, что сами стейты имеют экспортнутые настройки и для разных персонажей могут отличаться.
Как-то так.
кажется, что тут будет плодится очень много нод, почему не просто сделать нужные классы, а каждое уникальное существо - комбинация экземпляров
двигайся в ECS, коли на то пошли
>process_priority влияет же только на _process, а на физикс не влияет.
Почему ты так решил? В тултипе написано другое.
Если че я на 4 бета
> Это пофиксить как-то можно?
Перейти на стабильную трёшку. В остальных случаях:
>>852873
> А, так ты бета тесты проводишь. Тогда пиши авторам issue на гитхабе, раз баг нашел.
какая версия?
опиши точный порядок действий, если баг, но на выхах заведу
Я добавляю динамически из кода TextureRect, играют роль как точки, в консоли выдаёт такие вот сообщения.
Нашёл в интернете, что добавлять надо так
> get_tree().get_root().add_child(bullet.instance())
Однако добавление get_tree().get_root() и instance() проблему не решает
Как можно сделать интсанс объекта в годо?
Можно ли каким-то иным и более простым способом динамически рисовать точки?
Касаемо последнего, идея была шейдерами, но в третьей версии они не поддерживают передачу массивов, я разумеется уже подумываю перекатываться на четвёрку, где это есть, будет, обещают.
Разобрался, проблема была в постоянном добавлении одного и того же объекта
>Можно ли каким-то иным и более простым способом динамически рисовать точки?
Можно рисовать пиксели в текстуре. https://godotengine.org/qa/3804/how-to-edit-an-image-pixels
Можно рисовать Line2D с концами в одной точке.
Можно рисовать в функции _draw. В частности draw_line в одной точке.
Можно попробовать TileMap с размером ячейки = 1 пиксель, они вроде довольно оптимизированы сейчас.
> шейдерами, но в третьей версии они не поддерживают передачу массивов
Насколько я знаю, это решалось через текстуру тоже. Т.е. ты передаешь текстуру, а на самом деле там любые данные.
Например в картах нормалей, там не цвета, а векторы.
В бете17 не смог воспроизвести если с нуля проект создать. Но при импорте сцены, с которой работал в старой версии - звук есть при сохранении или запуске по ф6.
На всякий сделал проект с багом - по CTRL-S идет звук
https://gofile.io/d/gnCdiV
>>857105
Попробовал в старых версиях - тоже не получилось воссоздать вот так вот на шару. Звук при сохранении есть только если открыта вкладка с нодой, где есть аудиостримплеер и анимацияНода
Вот такой я написал код.
Как видишь, у меня тут уёбищный костыль в виде переменной-аккумулятора, которая считает входящие ивенты. А всё почему? Потому что даже когда я запускаю по Ф5, в приложение почему-то прилетает один мауз-ивент и код срабатывает. ЧЯДНТ?
очередь событий вообще наполняется постоянно всяким разным (как и везде собственно), ты лучше скажи, зачем тебе от ивента нужно что-то, кроме как поучения того, что какой-то нужный тебе ввод был
Логично, MouseEventInput это вообще общая категория всех событий мыши, не только кликов, но и MouseMove, поэтому первым прилетает стартовая позиция мыши, чтобы отработали все onMouseEnter.
Звучит легитимно. Значит костыль нужен.
>>857138
> ты лучше скажи, зачем тебе от ивента нужно что-то
Скринсейвер для венды делаю. С закрытием окна только при ивентах мыши и клавы. Но если какой ещё ивент прилетит случайно, чтобы он не закрывался.
Давайте лучше подумаем вот над чем: Когда скринсейвер отображается в окне предпросмотра, он при запуске получает командную строку с ключом /p 1639350, где число это по видимому хэндл directdraw поверхности в окне настроек. Это виндастайл, это классика, мне даже не надо открывать МСДН, чтобы это предположить. Так вот. Как бы из годота получить к ней доступ? чтобы вывести предпросмотр. Предполагаю, что никак, ибо годот это opengl приложение. Или есть варианты?
Godot 4 Tutorial - VoxelGI For Beginners
https://www.youtube.com/watch?v=c6gRGahMFlA
>>857084
> Можно рисовать Line2D с концами в одной точке
Про это подробнее, потому что, что точки, что разные отрезки было бы очень удобно рисовать через один экземпляр
> Насколько я знаю, это решалось через текстуру тоже. Т.е. ты передаешь текстуру, а на самом деле там любые данные
Я правильно понимаю, что я просто передаю в шейдер некие данные, а потом в нём я их использую как массив и это будет работать?
> Можно рисовать пиксели в текстуре
Идея очень интересная, однако мне тогда потребуется в два-три раза большее разрешение чем формат А4 - 2480 на 3504
И раз уж зашла речь про шейдеры и текстуру, то тоже вопрос. Координаты текстурные это дробные числа. Возможно ли тогда отображение точки с нецелыми координатами?
Ну а касаемо рисовки текстуры более высокого разрешения это надо проверять, потому что может и не надо делать никаких разрешений, достаточно просто сделать цветной квадрат и повесить на него шейдер
Я непонимат. Скрин должен болтаться в буфере и к нему нужен доступ. Даст ли его венда мне неизвестно.
Продолжил смотреть тот видос, так там ещё и отражения в реальном времени рисуются через этот VoxelGI, лучи похоже и правда как и шизикс потонут, получается, что Shadow Map победил, точнее его трёхмерная итерация, но что ещё интереснее, воксельный свет то можно было сделать и в конце 00х, сил процов того времени должно было хватать, так как там информации не так и много, но может я и заблуждаюсь на счёт скорости.
Выглядит как настоящее будущее, что ещё понравилось, что это не глобальный свет везде, а объект, внутри которого этот свет работает и эта область пространства разбивается, что даёт возможность делать аналог лод для света.
> болтаться в буфере и к нему нужен доступ
Не совсем так, наоборот венда предоставляет проге-скринсейверу доступ к некоторому оконному объекту с хендлом по адресу, который передаётся в командной строке. А уже скринсейвер должен суметь вывести графон не в полный экран, а на этот объект (графический контекст). Обычно это называется встраиваемым приложением. В прошлом треде анон спрашивал, можно ли годот встроить во внешнее приложение. Не помню, что нему ответили, емнип, написали, что инахуйненужон.
var huy = preload("res://govno.tscn")
var pizda = huy.instance()
add_child(pizda)
Доступ к буферу у годо вроде есть, туда по крайней мере можно постить через OS.set_clipboard()
Вот я сделал класс Gun:RigidBody3D.
В нем сделал пару виртуальных методов, проперти и все такое.
Сделал двух наследников Gun2:Gun и Gun3:Gun, по необходимости заоверрайдил всякое.
Так вот - как мне теперь у моего класса Player хранить текущее оружие?
Я сделал object CurrentWeapon и при надобности делаю (CurrentWeapon as Gun3).какаятопропертиилиметод
Так норм?
Карочи, похуй. Работает и ладно.
А чем не устраивает GDScript?
По теме, с точки зрения именно скрипта, то по мне так проще сделать несколько классов-структур для нужных типов, да всё, тем более, что в скрипте есть словари, которые могут всё вперемешку хранить
>>857275
Уважаемо
> Так норм?
Сомневаюсь. Лучше сделай, чтобы куррентган имел все необходимые методы, позволяющие ему действовать как ган. Тогда тебе не придётся тайпокастить постоянно. Ты загрузил ган и точно знаешь, что у него есть методы фаер, рилод, екип анэкип, ит сетера. Андестуд? Неважно, пистолет это или винтовка, они эти методы общего класса реализуют по своему. И тогда, кстати, общий класс ты делаешь абстрактным, чтобы по запарке не создать где-нибудь его инстанс.
> Предполагаю, что никак, ибо годот это opengl приложение. Или есть варианты?
ну начнем с того, что это скорее HWND прилетает тогда или HDC, что тоже не зависит чем ты там отрисовываешь
>>857222
> А уже скринсейвер должен суметь вывести графон не в полный экран, а на этот объект (графический контекст)
для работы со сторонними приложениями прав нужно побольше будет в разных операционках, да и годо - это больше игровой движок, не думаю, что его внешнего API хватит для таких целей, не спускаясь на уровень GDNative, написав свой плагин
> А чем не устраивает GDScript?
Я дотнетдебиловый, так привычнее. Тем более начали апи приводить в нормальный шарповый вид с 15 бетки
>>857304
> Андестуд?
Понел, пасиба
> прав нужно побольше будет
Чел... Это виндовые скринсейверы, АПИ которых не менялся с 95 года. Да и нет там никаких АПИ, тупо запуск с параметром. Какие права? Ты о чём ваще?
сижу на вин64 версии, последнее ловил рандомные вылеты, когда строку редактируешь в бете 11-12 где-то там, ничего критичного нет, пилим для прода уже на нем
Там не только вылеты бывают. А например слетающие названия нод, анимации в плеере, залипающие скрипты и т.д.
Вот у меня есть голова - рука - подбираемое оружие (через код подбирается инстанцируется)
Модельки по длине и высоте разные, потому положение в камере разное, когда подбираю(и анимация айронсайтов тоже разная вся)
Как лучше сделать? У меня из вариантов пока только кодом ноду руки двигать в зависимости от пушки + для каждой отдельную анимацию айронсайтов
Если ты про First person shooter, то в навороченом варианте там вообще сложно делается, отдельный вьюпорт со своими пропорциями.
Вот тут например чел делает шейдером
https://www.youtube.com/watch?v=NF-U5J92ivk
Вроде бы недавно кидали видос с объяснениями, но не получилось найти так что вот
https://godotforums.org/d/22576-fps-weapon-camera-fov/6
https://www.reddit.com/r/gamedev/comments/756ekj/how_do_first_person_shooters_handle_the_graphics/
Если же тебе просто побыстрее сделать, да просто ставь оружие там где оно красиво смотрится и все.
> А например слетающие названия нод, анимации в плеере, залипающие скрипты и т.д.
ну хз, у нас несколько чел пользуются, с конкретно такими на win64 под десяткой не сталкивались, хотя скрипты большие пишем
Ну вот например сегодня вешаю текстуру и шейдер на Line2D. Сохраняю сцену - линия схопывается, пока сцену не переоткроешь. А после пары кликов таки крашнулся редактор.
А например полигон создает 26 дублированных вершин вместо 4. Не, в целом как то что-то работает, но пока бетка сырая.
На начальный-средний уровень всего хватает, обычно гуглится за пару минут, но на английском.
Что они там опять навыдумывали? Платформы надо было делать комбинацией кинематик боди и ария со своей гравитацией.
Тем временем для годота запилили аналог юнити-хаба и эпик-лончера
https://github.com/eumario/godot-manager
Теперь можно удобно ИНСТАЛЛИРОВАТЬ разные версии годота, держать в одном месте свои проекты и запускать проекты с нужной версией движка, не боясь ненароком обновиться на проде.
Кому как удобнее. Мне тоже ручками норм, но надо осветить все возможности, доступные нам.
ЕМНИП если название анимации заканчивается на _loop то по умолчанию будет залуплено.
>Я так понял, что нужно отдельно анимации импортировать, чтобы они стали редактируемыми?
Не знаю как ты делаешь, я просто импортировал gltf и сохранял как tscn, соответственно потом все редактируемое.
> ЕМНИП если название анимации заканчивается на _loop то по умолчанию будет залуплено.
Работает
>импортировал gltf и сохранял как tscn
Так и делал, но не редактируется. Перепроверил еще раз с новым объектом.
1. Сразу отключил новый модно-молодёжный многооконный режим (interface/editor/single_window_mode = true), ибо с ним интерфейс становится неотзывчивым, выбираешь цвет в колорпикере в инспекторе, затем щёлкаешь по окну редактора, ожидая, что элемент, который щёлкаешь сразу активируется, но нет, колорпикер у нас отдельное окно и первым кликом вне его он закрывается, вторым кликом ты наконец активируешь виджет в предыдущем окне. По сути с многооконным интерфейсом все клики становятся у пользователя двойными. Дрисня. Отключил. У меня нет нескольких мониторов, чтобы ощутить преимущества многооконности. Кроме того, Хуану следует научиться не блокировать оконные сообщения в окнах, пока они не в фокусе, чтобы пользователям не приходилось по два раза прокликивать.
2. Наканецта завезли лигатуры! Ставишь в настройках шрифт с лигатурами, например каскадию от майков, включаешь пункт в настройках (interface/editor/code_font_contextual_ligatures = enabled) и кайфуешь. Впрочем, в гдскрипте не так-то уж и много лигатур.
3. Шрифт по умолчанию для нод теперь многоязычный, меньше мозгоебли для новичков, они теперь сразу смогут писать на кнопках и ярлыках по русски.
4. История действий. Была ли она раньше?
5. Вулкан. Прекомпиляция шейдеров. Все дела. Наконец-то можно начать делать игоры.
А не возродить ли мне мой старый проект? В трёшке у меня с ним вышел затык как раз из-за того, что возможностей гл ес мне не хватало для моих задумок. Проверим.
Хз, значит они встают в какую-то очередь (вместе со всем call_deferred) и начинают играться только следующего кадра. Не знаю что посоветовать. Попробуй не _ready, а _init или _enter_tree. Можешь еще скрыть видимость спрайта и включать с первым кадром анимации, или просто помещать куда-то за экран, но это костыли конечно.
не очень понятно цвет какой ноды ты меняешь, когда этот фон красным зарисовываешь, если ты попиксельно заполняешь
если там какая-то заливка, то попробуй поменять фон на готовую текстуру
Проверил еще два способа. Жду завершения анимации, устанавливаю флаг, проверяю его в _process(). Ну и просто переключаюсь из _process() при нажатии пробела. В обоих случаях мелькает, странно.
>>859873
>цвет какой ноды ты меняешь
Цвет ноды ColorRect (красный фон). Я его меняю в методе _ready() тоже для проверки. Подумал, вдруг может быть такое, что сцена отрисовывается до первого вызова _ready(). Тогда бы мелькнул красный цвет, а потом фон бы стал голубым. Но нет, фон всегда голубой.
ну тогда может связано с тем, что delta шатается там в разные стороны, попробуй через physics запустить или ограничить вызовы
Погонял ещё. Нет, работать пока что невозможно. Кучи фич просто нет. Например. Дублирование строки по Ctrl+D отсутствует. Как я раньше без этого жил? Теперь надо по старинке Shift+Home, Shift+End, Ctrl+C, Ctrl+V столько лишних пальцедвижений вместо одного. Пиздец.
А, ладно, доёб снимается. Они зачем-то зделоли Ctrl+Shift+D наверное редактор кода конфликтует с панелями.
>Зачем использовать сигналы, если я могу использовать сетгет?
Механизм сигналов нужен для уменьшения зацепления между разными игровыми сущностями и системами посредством инверсии управления и внедрения зависимостей.
https://ru.wikipedia.org/wiki/Зацепление_(программирование)
Объяснять в доках не будут особо, := и ->void особо не нужны.
не, если просто один раз напишут, то норм, я и так это понимаю из других языков, просто заметил такой вот контраст в синтаксисе
>Это потом будут объяснять
https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/static_typing.html
Кратко:
1. Изначально GDScript создавался как язык с динамической системой типов. То есть по умолчанию любая переменная может хранить любые данные, функции могут принимать любые данные и возвращать любые данные без каких-либо ограничений. У этого есть плюсы и минусы. Плюсы:
- проще научиться программировать, ибо не нужно держать в голове концепцию "тип данных";
- дети и инвалиды быстрее пишут код, нажимая меньше клавиш (которые они ищут глазами);
- быстрее вносятся правки в прототип, ибо для изменения поведения меняешь меньше кода.
Минусы:
- компьютер вынужден выделять больше памяти и выполнять проверки типа данных каждый раз, когда работает с этими универсальными переменными;
- код сложнее читать, потому что без типа не всегда понятно, что функция ожидает или отдаёт, и т.п.;
- баги могут скрываться в коде годами, пока не сойдутся звёзды на небе и весь проект обвалится;
- компьютер не может заранее проанализировать написанный человеком код и выявить банальнейшие ошибки вроде сложения строки с числом, а также не может дать контекстные подсказки, которые зачастую значительно ускоряют набор кода;
- взрослые программисты считают пользователя такого языка... ну, ты сам понимаешь.
2. Чтобы решить эту проблему, с версии Godot 3.1 доступна опциональная статическая типизация. Т.е. ты по-прежнему можешь писать код с динамической типизацией, а в некоторых случаях вынужден так писать, но ты можешь использовать статическую типизацию. Проще говоря, ты можешь указывать явные типы своим переменным и аргументам функций, благодаря чему интерпретатор имеет возможность ускорить выполнение твоего кода и снизить потребление памяти, а редактор кода может найти некоторые ошибки до запуска игры и дать полезные подсказки в выпадающем меню. Также это улучшает читаемость кода, что особенно важно если ты работаешь над одним проектом больше одного дня или планируешь использовать код в будущем.
3. GDScript предоставляет следующие возможности:
- явное указание типа:
var number: int = 0
var text: String = ""
var array: Array = []
var node: Node = Node.new()
- выведение типа из данных:
var number := 0
var text := ""
var array := []
var node := Node.new()
- указание типа возврата функций:
func nothing() -> void: pass
func return_hello() -> String: return "hello"
func sum(a: int, b: int) -> int: return a + b
- типизированные массивы PoolТипArray.
В Godot 4.0 будет больше возможностей.
>>860054
>:= и ->void особо не нужны.
Ловите говнокодера, пока он не наложил кучу кода!
> В Godot 4.0 будет больше возможностей.
а что там кроме нескольких новых типов поменялось?
> часто вижу в треде через :=
Это не оператор. Это два оператора идущие друг за другом без пробела. Двоеточие - оператор выведения типа, если следом за ним указать тип, то тип будет присвоен вручную, иначе - автоматически. Равенство - оператор присвоения значения (инициализатор в случае объявления переменной). То что они идут вместе - это отсылочка к паскалю. А мы в гд любим отсылочки.
> а что там кроме нескольких новых типов поменялось?
Сетгетами в коде срать больше не нужно. Вот я вчера вечером конвертировал свой примитивный минипроектик. Вот скрины одного из модулей. Там где раньше было насрано сеттерами-геттерами (которые, к слову, никак не спрятаны и их можно было вызвать по ошибке из другого объекта) теперь остались только нужные функции. Сеттеры-геттеры ушли внутрь объявления переменных. Ты их один раз настроил, свернул и не трогаешь.
И ещё в четвёрке неочевидное мне странное решение заменить высвобождаемый (disposable) класс File на референсный (RefCounted) FileAccess. Теперь высвобождением открытых файлов занимается сборщик мусора, а не я, и я не могу самостоятельно закрывать открытые файлы, когда нужно мне, а не движку. Очень странное решение. Поясните, кто шарит?
В целом у меня сложилось впечатление, будто общение Хуана с эпиками не пошло годоту на пользу. Эпики, приманили Хуана донатом и надавали ему вредных советов, чтобы устранить конкурента, а он, судя по тому, что я вижу в четвёрке, развесил уши и внимает. Годот позиционировался как движок для лёгкого вката новичков, теперь же у него старые добрые одноаргументные функции напичканы кучей аргументов, в которых чёрт ногу сломит. Мне как старичку несложно разобраться, но ИМХО вкатывающихся новичков это всё отпугнёт.
по сути у тебя все осталось по-старому:
если освобождение ресурса файла идет внутри функции, то он итак освободит ее по окончанию это функции
если вдруг планируешь файл держать открытым, то создаешь внешнюю переменную, а отличие только в том, что потом для освобождения ей просто присобачиваешь nil, вместо вызова прямой функции
>>860213
А ещё интеллисенс-подсказки превратились в говно. Выдают всё подряд кроме ожидаемого. Ожидаемое выводится внизу длинного списка ненужной хуйни. Например, раньше как, пишешь pri и в подсказке сразу print(), теперь в подсказке целая куча дебажных принтов, а простой принт внизу. Пишешь vec, в подсказке ожидаешь Vector2, Vector3, но нет, в подсказке сначала длинный список хуйни, содержащей в себе v, e, c, а потом уже идут нужные типы. Чтобы правильно вывести подсказку, нужно писать с большой буквы, а трёшка от этого отучила ранее, потому что там пишешь мелкобуквой и в подсказках выводился сразу искомый тип без учёта регистра, но с учётом положения букв.
Ждём фиксов.
Не спорю, но усложнение должно быть грамотным. На поверхности движкового АПИ должен быть медленный, неоптимальный, но простой и "новичковый" слой методов и утилит, позволяющий быстро, легко и без задней мысли накидать работающий с тормозами и пропуками прототип. Именно это привлекало массы к продукту во все времена и именно так было в трёшке. Глубже этого новичкового слоя должен лежать менее абстрагированный "сложный" слой АПИ, для шарящих, позволяющий делать магию кодинга на низком уровне. И так было в трёшке. Теперь в четвёрке наметилась тенденция глубинный слой АПИ выпихивать наружу, пугая им новичков.
Ну не стукай, нужны чтобы не обосраться в релизе, но в прототипе и так сойдет. Опять же ты сам сказал что фиксить/добавлять будет проще.
Есть такие же доки по 4+, а то там же придется переделывать все?
Игрок сможет создавать и редактировать квадратные тайлы (на видео один тайл) и затем из этих тайлов собирать большие миры (надеюсь на 10х10 и больше). Пока думаю, собирать мир из тайлов на плоскости или попробовать снова натянуть тайлы на кубосферу (надутый куб); с картой высот натягивание должно быть проще, а артефакты менее заметны, чем с жёсткими квадратами; но от этого будет очень сильно зависеть геймплей (в частности физика транспорта и симуляция жизни), так что вопрос сложный.
По сути я делаю что-то вроде этого:
https://youtu.be/Z94nvgodQHs
Но основной геймплей игры предполагается совершенно иной (GTA × The Sims), поэтому инструменты и ограничения редактора мира должны это учитывать, чтобы играбельный мир можно было создавать в несколько кликов в редакторе или путём процедурной генерации в один клик. Т.е. процедурная генерация всё ещё будет, но её уровень можно будет выбирать, от полностью случайного мира до полностью созданного вручную. Также есть мысли как сделать визуальный редактор шаблонов генерации, чтобы ещё более тонко контролировать генерацию.
Модуль с готовым ландшафтом не предлагайте, я знаю о нём, но не хочу использовать. Причины долго перечислять.
WFC (он же model synthesis) недавно пробовал - под мою задачу в исходном виде не подходит, нужно что-то другое. Для тех, кто не в курсе - принцип генерации там похож на складывание пазлов, только фрагменты картинки не уникальны (как в обычных пазлах), а многократно повторяются в разных местах. Жаль, что это не объясняют сразу, я бы тогда сразу всё понял.
Сейчас основная сложность в том, что я не могу чётко представить себе то, что хочу от игры. А развивать игру снизу вверх без чёткой общей архитектуры не получается. Внутриигровой редактор, по идее, должен помочь создавать кусочки игры снизу вверх, с минимальным хардкодом, т.к. вместе с редактором образуется скелет игры, на который можно наращивать контент прямо внутри игры, через редактор. Соответственно будут отдельные редакторы для домов, машин и т.п., особой технической сложности в этом нет. На самом общем уровне я пытаюсь сделать программу-игрушку, а не обычную игру...
https://ru.wikipedia.org/wiki/Программа-игрушка
Думаете, слишком сложно? Только не надо мне напоминать, что я уже пятый год один и тот же прототип делаю. Этому проекту 15 лет уже, если считать с самой первой моей идеи, от которой всё пошло, но большую часть времени я вообще ничего не делал.
> - типизированные массивы PoolТипArray.
> В Godot 4.0 будет больше возможностей.
Типизированные массивы подвезли. Пулы не типизированные массивы. Пулы ... это пулы.
> Модуль с готовым ландшафтом не предлагайте, я знаю о нём, но не хочу использовать. Причины долго перечислять.
На самом деле недолго. Модуль террейна от зилана - это сферический конь в вакууме, не приспособленный к продакшону. У него нет внятного АПИ, чтобы интегрировать его в свою игру. Это вещь в себе, нужная чтобы показать, что вот мол есть террейн. И чо дальше? А дальше как к нему ни подступись - он статичен, у него своя инкапсулированная внутри система ЛОДов. У него собственная система шейдеров. Часть настроек вынесена в интерфейс, но в целом модуль неудобен.
Сильнее всего меня огорчило, когда я с ним работал, что каждый инстанс террейна выставляется в глобальных нулевых координатах и таким образом, делать чанки из него не представляется возможным. Ну и пошол он нахуй тогда.
Глупости какие-то пишешь. Делал чанки из нескольких инстансов, никаких проблем не было. Не знаю что значит "статичен", я делал динамический террейн с копанием ям - берется текстура-карта высот, лочится, рисуется пикселями. Система шейдеров своя там не просто так, все объяснено в глубинах гитахаба. Чтения из текстуры дорогие, поэтому там все упаковано по каналам цвета. К лодам хз какие претензии, в движке на то время никаких лодов не было, у него есть, я бы такие не написал за разумное время.
>Движкосрачеры создали ложное впечатление того, что ландшафт на основе карты высот - это что-то очень сложное.
Там разве вообще такое обсуждали где-то? Не припомню.
Забыл дописать, что я пока даже не знаю, буду ли я текстурировать ландшафт несколькими разными текстурами (земля, трава, песок, камни и т.п.), или я остановлюсь на "плоскозаливочном" стиле графики, в котором вместо текстур ландшафт можно красить цветами вершин. Мне не очень нравится плоская заливка всего и вся, но вместе с тем не нравятся артефакты от перекрывающих друг друга текстур в других играх с похожим ландшафтом. Кроме того, качественные текстуры рисовать сложно, а если я сделаю текстуры для ландшафта, то мне потребуется рисовать текстуры в том же стиле вообще для всего в игре. Если же выбрать плоскозаливочный стиль, можно будет обойтись более простыми текстурами в отдельных случаях, когда без них полигонов слишком много (вроде пуговиц на одежде и т.п., где нужна высокая детализация мелких объектов).
>>860299
>разве вообще такое обсуждали где-то?
Один из популярных аргументов против Godot: "если нет встроенного компонента ландшафта с дорогами, то движок бесполезен для ААА игорей".
>>860290
>сферический конь в вакууме
Не в этом проблема. Основная проблема: в отличие от основного движка, модуль непопулярен, и в случае, если автор его окончательно забросит, мне придётся самому копаться в его коде, искать альтернативу или делать всё самостоятельно с нуля. Если бы он официально поддерживался, такой проблемы бы не было, но есть и другие проблемы, например, как у GridMap.
>>860296
>там все упаковано по каналам цвета
Рассматривал этот вариант, но меня напрягает то, что больше 4 текстур таким образом не упаковать, а если необходимо больше, то придётся их каким-то образом сортировать и разбирать потом в шейдере. Или делать две текстуры на канал, опять же максимум 8 текстур.
>карта высот рисуется пикселями
Вот это я тоже много где видел, но не понимаю. Зачем передавать карту высот в шейдер через текстуру, если тебе в любом случае необходимо на процессоре построить меш с вершинами в определённых высотах и затем по этому мешу сгенерировать коллижн шейп для физического движка? Я знаю, что в теории существует более оптимальный алгоритм коллизий с картой высот, но для его реализации нужно погружаться во внутренности физического движка. Поэтому в нашем случае единственный вариант - сделать тримеш на основе карты высот. Зачем тогда рисовать карту высот и передавать её в шейдер, если шейдер получает уже готовый меш, и ему достаточно наложить на этот меш какую-нибудь текстуру, или просто залить его одним цветом? Тут даже стандартный шейдер справится. А меш менять на процессоре после генерации всех LODов больше не нужно, соответственно экономим время ЦПУ и ГПУ, да ещё и память.
Вот это ещё одна проблема. Создатели модулей пихают избыточный функционал, который не нужен конкретной игре, ты его отключить не можешь и вынужден каким-то образом костылировать решение вокруг него. Скорее всего, если будет официальная нода "ландшафт" от главных разработчиков движка, конечным пользователям всё равно придётся реализовывать свои собственные ландшафты по их конкретные задачи. Поэтому разработчики не торопятся добавлять эту ноду в движок.
>оптимальный алгоритм коллизий с картой высот
А, точно, в Godot он уже есть:
https://docs.godotengine.org/en/stable/classes/class_heightmapshape.html
Нужно только его специально заполнять, метода для автоматической генерации нет. Я же использую это:
https://docs.godotengine.org/en/stable/classes/class_mesh.html#class-mesh-method-create-trimesh-shape
Скорее по привычке, т.к. раньше генерировал более сложные формы, чем простую карту высот.
Но если я захочу натянуть карту высот на сферу, то мне, по идее, в любом случае придётся генерировать тримеш, поскольку вершины на сфере уже не располагаются по равномерной сетке. Нужно сначала проверить, стоит ли вообще делать сферический мир.
>"если нет встроенного компонента ландшафта с дорогами, то движок бесполезен для ААА игорей".
Ну для ААА да, наверное бесполезен. Туда еще надо и систему трафика и пешеходов. Но Хуан официально же написал что и 4 еще не для ААА.
>напрягает то, что больше 4 текстур таким образом не упаковать, а если необходимо больше, то придётся их каким-то образом сортировать и разбирать потом в шейдере. Или делать две текстуры на канал, опять же максимум 8 текстур.
В том же ассете есть на 16 текстур, который впрочем не развивается. Но да, это уже становится похоже на паззл головоломку когда надо думать как что уложить вместе.
https://github.com/Zylann/godot_heightmap_plugin/issues/174
>Я знаю, что в теории существует более оптимальный алгоритм коллизий с картой высот,
Вовсе не в теории, а совсем даже на практике. В буллете это стандартный примитив, да и в годоте он пробрасывается на уровне ресурса, что в 3 что в 4.
>Ну для ААА да, наверное бесполезен. Туда еще надо и систему трафика и пешеходов.
Это сарказм? Высказывания про необходимость встроенного ландшафта и дорог исходят от нубов, которые не имеют отношения к крупным студиям. Крупная студия скорее всего свой движок с нуля напишет под игру, чем будет использовать готовый.
Тогда вообще не пойму, как тебя нубы могли запугать своими высказываниями.
Объясните плиз почему в первом варианте ошибка, а во втором всё ок.
В первом варианте после того как прожектайл делает КьюФри() - новый прожектайл такого же типа не создается
Я вроде понимаю почему, но точно не могу ООПешно объяснить..
Ну так во втором ты каждый раз делаешь новый инстантинейт, а в первом один раз заполнил словарь, и после первого кьюфри объект невалиден по идее.
Попробуй так:
public override void _Ready()
{
ProjectileTypes = new Dictionary<int, Projectile>()
{
{1, (Fireball)FireballScene},
{2, (Iceball)IceballScene}
};
CurrentProjectileId = 1;
Shoot();
}
public void Shoot()
{
Projectile projectileInstance = ProjectileTypes[CurrentProjectileId].Instantiate();
projectileInstance.DoSomething();
}
Либо так, в зависимости от твоей задачи:
public override void _Ready()
{
ProjectileTypes = new Dictionary<int, Projectile>()
{
{1, (Fireball)FireballScene.Instantiate()},
{2, (Iceball)IceballScene.Instantiate()}
};
CurrentProjectileId = 1;
Shoot();
}
public void Shoot()
{
Projectile projectileInstance = ProjectileTypes[CurrentProjectileId].Duplicate();
projectileInstance.DoSomething();
}
Но для стрельбы лучше не создавать новые объекты, которые после попадания уничтожаются, а иметь заранее созданный массив пуль, которые "вылетают" по мере необходимости и затем сохраняются, "возвращаясь" обратно в этот массив. Причина в том, что создание новых объектов занимает время на выделение памяти, и если ты создаешь все пули заранее, ты не будешь тратить время на выделение памяти во время стрельбы. Но тебе нужно чётко рассчитать количество пуль, одновременно возможных в мире, чтобы игрок не сталкивался с ситуацией, когда он не может выстрелить, пока предыдущие пули не долетели до цели.
>>860332
Реально, спасибо!
В итоге работает если вот так - и в обоих случаях апкаст к Прожектайлу
https://pastebin.com/vZWV6xwL
>Типизированные массивы подвезли.
Да, именно так.
>Пулы не типизированные массивы.
Это массивы. Хранящие определённый тип данных, т.е. они строго типизированные. Кстати, в 4.0 их переименовали в "packed array" и добавили функциональности:
https://docs.godotengine.org/en/latest/classes/class_packedbytearray.html
https://docs.godotengine.org/en/stable/classes/class_poolbytearray.html
>>860273
>Ну не стукай, нужны чтобы не обосраться в релизе, но в прототипе и так сойдет. Опять же ты сам сказал что фиксить/добавлять будет проще.
В некоторых случаях лучше сразу типы указывать, чтобы получать подсказки в редакторе кода и не запутаться, что у тебя куда идёт. В других случаях да, можно не указывать тип, чтобы потом быстрее поменять систему.
>Есть такие же доки по 4+, а то там же придется переделывать все?
Когда обновят, должно будет быть здесь же:
https://docs.godotengine.org/en/latest/tutorials/scripting/gdscript/static_typing.html
Но до релиза 4.0 документация пока что не вся обновлена, в частности эта страница не описывает новый синтаксис типизированных массивов.
> чётко рассчитать количество пуль, одновременно возможных в мире, чтобы игрок не сталкивался с ситуацией, когда он не может выстрелить, пока предыдущие пули не долетели до цели
Почему бы не сделать, чтобы пул пуль при достижении, скажем, 80%, заранее накидывал себе размер и понемногу, во время малой загрузки, подгружал новые инстансы. При этом, в конфиг бы сохранялся текущий размер пула, чтобы в следующий раз он сразу создавался этого размера. Такое себе автоматическое подстраивание под игрока. Если игрок много стреляет, у него пул пуль побольше.
Хех, пул пуль, как я выдал, а!
Просто просчитай пул с учетом скорости атаки/бонусов, зачем что-то на ходу делать дроча память?
> во время малой загрузки, подгружал новые инстансы
а ты это как чекать будешь, не создавая нагрузки гораздо больше, чем был бы просто пул пуль побольше?
1. Нажатие на Button
2. Проверка нажатия клавиши Пробел в _process()
3. Из анимации (Call Method Track)
4. После ожидания завершения анимации (yield)
5. Ожидание завершения анимации, установка флага, проверка флага в _process()
Только в первом случае (Button) все работает как надо, спрайт движется по голубой стрелке. В остальных случаях одно мгновение мелькает анимация RESET. Если же установлена анимация Autoplay, то мелькать будет она.
Может Хуану отправить?
Честно говоря я проверил все твои 5 способов в 3.5.1, вида 10, и не воспроизвелось. Ни разу не мигнула анимация RESET, она появилась бы в левом углу. Ну или ищи в чем разница, по сравнению с тем что ты описал.
У тебя у анимации move стоит Autoplay on Load. А у меня в корневой узел сцены добавлен скрипт, и из его метода _ready() запускается анимация. Это нужно, чтобы как в ботаникуле при загрузке сцены проигрывать разные анимации. Если ГГ пришел в сцену слева, то одна анимация, если ГГ пришел справа - другая.
Да, ты прав. Но что-то мне подсказывает, что исправлять это не будут. Если подумать, когда сцена загружается, объект должен находиться в каком-то положении. Или слева, или справа. При загрузке сцены, ДО того как сработает ready. Autoplay позволяет это обойти, потому что движок точно знает, какое будет положение. Но без него никак не получится с помощью change_scene. Если добавлять сцену как add_child- может быть, там можно успеть задать параметры между инстанцинацией и добавлением в дерево.
Поэтому предложений 2
1. Если хочется пользоваться change_scene. То сделать autoplay анимацию, где изначально объект не видимый. В анимации move на первом же кадре делать его видимым.
2. Пользоваться add_child вместо change_scene (ну то есть у тебя есть корневая сцена игры, а в ней сцены удаляешь и добавляешь сам). Вот сейчас проверил, если сделать так, то работает move и move2 без миганий, потому что до add_child движку указываешь какую анимацию autoload.
Соре за многабукв.
> Может Хуану отправить?
Советую сначала создать новый проект, ничего туда из старого не перетаскивать и полностью с нуля на новом проекте вопроизвести проблему. Этот проект потом ты отправишь Хуану как иллюстрацию проблемы...
... Если проблема воспроизведётся.
... Потому что обычно в таких случаях, на новом проекте проблема не повторяется. И в поисках ответа на вопрос "почему она не повторилась?" ты выясняешь, что это ты объебался, а не движок.
>в корневой узел сцены добавлен скрипт, и из его метода _ready() запускается анимация
Методы _ready() вызываются снизу вверх по иерархии, то есть от "листьев" дерева сцены к "корню". Пока все дочерние ноды не обработают свой _ready(), их общий предок не сможет ничего сделать. Соответственно, если твоя нода где-то в глубине дерева имеет анимацию, которую ты хочешь менять из корня, эта глубинная нода может успеть отрендерить кадр анимации до того, как запустится код в твоём корне.
Вывод - настраивать все ноды до того, как корневая нода попадёт в дерево сцены.
В остальном бага здесь нет, это ожидаемое поведение.
Просто ты плохо разбираешься в дереве сцены Godot.
Мне не удалось воспроизвести твою проблему. Мой код:
Корневая нода:
>func _ready() -> void:
>_ print(name + " ready")
>_ $AnimationPlayer.play("move")
>_ print("Scene1.tscn fully loaded")
>func _input(event: InputEvent) -> void:
>_ if event.is_action_released("ui_accept"):
>_ _ var _e := get_tree().change_scene("res://scene2.tscn")
Плеер анимаций:
>func _ready() -> void:
>_ print(name + " ready")
>_ print("%s: '%s'" % [name, current_animation])
>func _on_animation_started(anim_name: String) -> void:
>_ print("%s: '%s'" % [name, anim_name])
Аналогично настроил scene2, только там другая анимация.
Результат в консоли:
>AnimationPlayer ready
>AnimationPlayer: ''
>AnimationPlayer: 'RESET'
>Scene ready
>AnimationPlayer: 'move'
>Scene1.tscn fully loaded
Т.е. сначала загружается AnimationPlayer, выполняется его _ready, затем запускается его анимация RESET (только потому, что я нажал на ней autoplay on load, в противном случае она не запускается) и соответственно запускается обработчик события _on_animation_started, и только потом корневая нода выполняет _ready и меняет анимацию на "move".
ОДНАКО, на экране никаких артефактов я не вижу (Godot 3.5, GLES3, пробовал переключать рендеринг на многопоточный). У меня на экране сразу воспроизводится анимация "move", ни одного кадра RESET я не вижу. Я что-то неправильно понял?
>4. После ожидания завершения анимации (yield)
Проверил, по-прежнему никаких артефактов:
>func _ready() -> void:
>_ print(name + " ready")
>_ $AnimationPlayer.play("move")
>_ print("Scene2.tscn fully loaded")
>_ print("---")
>_ yield($AnimationPlayer, "animation_finished")
>_ var _e := get_tree().change_scene("res://scene2.tscn")
Точно такой же код для сцены scene2.
Сцены меняются, анимации воспроизводятся, артефактов нет.
Можешь на видео записать, как у тебя мигает всё?
Баг в том, что если указан autoplay, то это обходит иерархию сцены.
>>860808
Я же написал выше что воспроизводится.
Хорошо, мне удалось воспроизвести у себя. Этот эффект становится виден только на низкой частоте кадров, а я у себя снял ограничение и было 2000+ кадров в секунду. Если поставить ограничение, то на 60 квс кадр изредка мелькает, на 30 квс чаще, а на 5 квс заметно каждый раз. Короче, нужно ставить ограничение частоты кадров, чтобы тщательно тестировать.
>если указан autoplay
Это не обязательно, если у тебя никакая анимация не задана на воспроизведение, то по умолчанию "воспроизводится" RESET. В кавычках, потому что события animation_started не триггерится, но значения из RESET задаются...
>это обходит иерархию сцены
Насколько я понял, рендерер рендерит всего один кадр со значениями по умолчанию, при этом до вызова обработчиков _process, _draw, _ready и даже VisualServer.pre_draw. Странное поведение, но это не похоже на баг. Если рендерер ничего не будет рендерить, то что должно отображаться на экране? Заливка одним цветом? Или предыдущая сцена, которая может быть уже выгружена из памяти? По идее, рендерер делает всё правильно, отображая картинку как можно скорее.
>>860749
>1. Если хочется пользоваться change_scene. То сделать autoplay анимацию, где изначально объект не видимый. В анимации move на первом же кадре делать его видимым.
Это не решает проблему. Вместо неправильного положения на экране, объект будет полностью отсутствовать на экране один первый кадр. Хорошо заметно на низкой частоте кадров.
>2. Пользоваться add_child вместо change_scene (ну то есть у тебя есть корневая сцена игры, а в ней сцены удаляешь и добавляешь сам). Вот сейчас проверил, если сделать так, то работает move и move2 без миганий, потому что до add_child движку указываешь какую анимацию autoload.
Вот это действительно решает проблему.
Я нашёл способ решения проблемы, который работает с get_tree().change_scene():
>func _enter_tree() -> void:
>_ print("[%s] enter_tree" % [name])
>_ $AnimationPlayer.autoplay = "move"
Событие _enter_tree срабатывает после _init, но перед всеми _ready:
>[Scene #1] init
>[Scene #1] enter_tree
>[Icon] ready
>[AnimationPlayer] ready
>[AnimationPlayer] ''
>[AnimationPlayer] 'move'
>[Scene #1] ready
>[AnimationPlayer] 'move'
>[Scene #1] fully loaded
>[Icon] draw
>[Scene #1] process frame #1
Единственный нюанс, который нужно учитывать, что _enter_tree срабатывает каждый раз, кода нода добавляется в дерево, а _init и _ready вызывается только один раз. Но в обработчике _init корневой ноды данный код написать нельзя, потому что get_node() в этот момент выдаёт null. Как вариант, можно создать флаг "_first_enter_tree" и проверять его, если необходимо извлекать корневую ноду из дерева и добавлять повторно (т.е. если сцена меняется из какого-то пула сцен в оперативной памяти, а не загружается каждый раз с диска с нуля). Ну, смотрите сами, как у вас там сцены загружаются и меняются.
Есть примеры реализаций кастомизации персонажей на Godot? Я видел что-то раньше, но там было ультра-лоуполи какое-то. И в виде платного плагина, а не игры. Я знаю основные принципы, которые универсальны для любых движков (шейпкеи, кости, сдвиг текстуры, подмена кусков модели, альбедо в материале), но хотелось посмотреть, до чего дошли другие пользователи Godot.
И как это потом оптимизировать для случая "много персонажей на экране"...
У тайлмапа нужный слой стоит - у нпц соответствующие слои в маске
Ладно я еблан, были отключены галки collide with bodies/areas
>видел что-то раньше
Кажется, вот это: https://youtu.be/KHLVfrV0pIs
Аффтар запросил 35$ за версию 0.5а, распланировал роадмап и фсё. Типичный ёрли аццесс...
Вот ещё один, опенсурс (MIT):
https://github.com/Grumoth/godot-character-creator
Но тут, как я понял, только брутальные бородатые мужики.
> примеры реализаций кастомизации персонажей на Godot?
Шапку читаем
>>852131 (OP)
> - Редактор персонажей на основе makehuman: https://github.com/Lexpartizan/Go_MakeHuman_dot
Еще надо проверять что он вообще enabled, в какой то версии по умолчанию он был disabled.
Есть еще вот такой, но он без моделек, поэтому мне было лень вставлять свои и проверять, реально ли он рабочий.
https://github.com/smix8/Godot3DCharacterEditorWardrobe
Решил вкатиться в годот с идеей 2д изометричной игры в духе лутер-шутера, и элементами ВН.
Если вкратце суть предполагаемой игры - есть некая база игрока, где происходит ВН составляющая и всякий крафт, и есть динамически генерящиеся локации, где мы лутаемся ништяками.
Владею ООП на среднем уровне, пайтоном, английским, могу в 3д модельки - но не хочу дрочиться с их оптимизацией для игры. Мне проще спрайтов нарендерить.
А теперь вопрос вопросов - есть ли какие-то гайды, с которыми мне стоит в первую очередь ознакомиться, с учётом того, что я хочу сделать?
Или ещё проще - с чего, собственно, лучше начать?
>2д изометричной игры в духе лутер-шутера
Как ты себе представляешь шутер в изометрии? Пошаговый, как диды играли во времена Fallout?
>происходит ВН составляющая
Изометрия ещё ладно, а ВН рисовать потянешь?
>могу в 3д модельки
Ясно, значит, прям как в Fallout и ему подобных.
>динамически генерящиеся локации
Если ты никогда их не делал, я тебя разочарую - процедурная генерация обманчиво проста, это не волшебная кнопка "сделать 100500 уровней", тебе в любом случае придётся делать много контента вручную, если ты хочешь что-то сложное и интересное для игрока, при этом играбельное и возникающее на экране за приемлемое время. Т.е. проще сделать набор уровней вручную, чем сделать качественный генератор уровней, который не будет раздражать игрока. Поэтому мы чаще видим статичные уровни, или случайные уровни из набора бросающихся в глаза статичных фрагментов... В любом случае, контента вручную потребуется сделать много, и лучше начать со статичных уровней (делаешь ассеты и расставляешь вручную, чтобы побегать и оценить ощущения), и только потом придумать способ их рандомно перемешивать (чтобы увеличить реиграбельность за счёт немного другой комбинации элементов/путей), а не наоборот. В туториалах иногда генерят абстрактные комнаты и коридоры между ними (закономерно обрывая туториал на "ну дальше там нужно контент добавить, ну это вы как-нибудь сами, пока"), но в общем и целом это скорее неправильный подход, т.к. ты фокусируешься на генераторе, забывая об игре и игровых впечатлениях игрока, которые складываются из локальных событий, а не какой-то абстрактной цепи комнат случайных размеров.
>не хочу дрочиться с их оптимизацией для игры
Делаешь лоуполи @ запекаешь нормали. Сложно?
Лично я сомневаюсь, какая графика сегодня более тяжёлая для ПК: 2D или 3D. Во времена первых игровых консолей существовали специальные хардварные приспособления для ускорения рендера спрайтов и тайловой графики. Сегодня видеокарты оптимизированы исключительно для 3D графики, 2D ты рисуешь в виде текстур на трёхмерных треугольниках. В зависимости от детализированности твоей графики и ракурса камеры может оказаться, что лоупольки анимированные по экрану гонять дешевле, чем заранее отрендеренные гигантские спрайтшиты на прямоугольниках из двух треугольников. Вроде бы видеокарте сегодня проще переварить десятки миллионов треугольников, чем затекстурить несколько сотен квадратов с прозрачными пикселями. Отсюда, наверное, возникает неожиданная прожорливость некоторых полностью двумерных игр, в которых используется много двумерных спецэффектов.
Но в контексте Godot нужно понимать, что актуальную оптимизацию 3D (для сравнительно больших проектов) подвезли только в версии 4.0, которая уже вот-вот релизнется, но всё ещё нет.
>с чего, собственно, лучше начать?
https://docs.godotengine.org/en/stable/getting_started/introduction/index.html
И дальше все статьи из "GETTING STARTED".
После этого - статьи из "TUTORIALS".
Наконец, тебе часто понадобится "Godot API", но его удобнее читать прямо в движке (F1, кнопка в инспекторе или ctrl+клик в коде на название класса), чем на сайте... сам поймёшь, почему. Ты же уже скачал движок?
>есть ли какие-то гайды
>с учётом того, что я хочу сделать?
По Godot вообще не так много туториалов, а на твой конкретный запрос я ничего не видел. Ну, есть пара фреймворков для визуальных новелл. Есть пара фреймворков для RPG игр. Но если ты умелый программист, сделаешь всё под себя без каких-либо фреймворков, т.к. движок очень дружелюбный и всё необходимое тебе уже есть из коробки. Для изометрии смотри официальную документацию на TileMap, там легко переключиться с прямоугольной сетки на сетку для изометрических тайлов. Ну, тыжпрограммист, так что иди RTFM, а гайды "как сделоть игру жанра X" предназначены для детей и яждизайнеров, а по факту нужны для заработка того, кто эти туториалы записал.
>Как ты себе представляешь шутер в изометрии? Пошаговый, как диды играли во времена Fallout?
Не, скорее просто шутер с видом сверху-сбоку. Полно их. Не пошаговый, реалтаймовый.
>ВН рисовать потянешь?
3д картинки как-нить вытяну.
>лучше начать со статичных уровней
Безусловно именно с этого и начну. Генератор это так, в теории.
Но даже до этого пока далеко, потому что у меня из базового туториала пули летят не в том направлении, если персонаж двигается.
>Делаешь лоуполи @ запекаешь нормали. Сложно?
Нет, не сложно. Сложно это анимировать, заставить сгибаться под правильными углами и правильно деформировать тела. Да и не хочу я просто ещё и в годоте с 3д возиться. Мне и до 3д изучать его до усрачки.
А как начнёшь в 3д - это всё, это бесконечная яма с выставлением света и так далее.
>актуальную оптимизацию 3D (для сравнительно больших проектов) подвезли только в версии 4.0, которая уже вот-вот релизнется
Тем более не хочу дезть туда первым.
>Ты же уже скачал движок?
Да, уже начал ковырять этот туториал пока: https://www.youtube.com/watch?v=HycyFNQfqI0
Я если тыкаю сам - быстрее обучаюсь.
>Но если ты умелый программист, сделаешь всё под себя без каких-либо фреймворков, т.к. движок очень дружелюбный и всё необходимое тебе уже есть из коробки.
Не то, чтобы я дохуя умелый, но класс от объекта отличаю и применять умею. Чего-то готового я не прошу, я хочу именно понять как оно всё работает и понять нюансы, чтобы начать делать что-то своё.
А так спасибо, попробую почитать туториальчики, может что-то прояснится. Пока я даже структуру того, как оно всё работает и взаимодействует слабо понимаю.
как и было предсказано ранее, до 4.1 будете жрать кал
>assessing the remaining PRs and issues
>до 4.1 будете жрать
Стабильность и багфиксы.
Спасибо Хуану за это! Самый стабильный движок.
Почему у меня, например, main анимация (типа idle) не играется на постоянке, если я делаю к ней travel? Пишу если velocity.X == 0 {StateMachine.Travel("main")} - и стейт машина автоматом переходит в стейт turnright, когда игрок на месте стоит.
1) Как мне заставить спрайт постоянно быть в main, когда не двигается, а не перескакивать в другую ноду?
2)Я хочу залупить пути (main-turnX-X-turnX-main), но если соединяю и в обратное направление (а не в одно как сейчас), то в годот треде начинается сущий кошмар - вообщя непонятная мне хуйня происходит с переключение стейтов (расписывать даже смысла нет особо). ЧЯДНТ?
Разобрался перечитав ещё разhttps://docs.godotengine.org/en/latest/tutorials/animation/animation_tree.html
У пути есть параметр Advance и он был выставлен в Auto, соответственно автоматом по кругу автомат ходил. Выставил как надо и теперь всё ок (нахуй нужна енд нода пока не понял всё равно наверн для StateMachine.Stop();)
>>861618
Нраицца, в четвёрке вроде всё вполне работает что тыкал, ток дока не везде доделана
>изометрия
>сверху-сбоку
Это разные проекции. Изометрия - это, например, как в Project Zomboid. Собственно, какие ещё есть шутеры с изометрической проекцией? Я чаще топ-даун шутеры встречал, они проще и понятнее. В изометрии же обычно пошаговые, тактические, РПГ и т.п. Зомбоид в данном случае - исключение.
>3д картинки как-нить вытяну
Завидую. Тяжело было учиться?
>пули летят не в том направлении, если персонаж двигается.
Есть локальная система координат и глобальная. Глобальная не вращается и не смещается. Локальная движется и вращается вместе с нодой. У нод есть специальные методы для преобразования координат из локальной системы в глобальную. Также каждая нода автоматически двигает и вращает все свои дочерние ноды, это следствие того, что дочерние ноды размещаются в локальной системе координат ноды; есть метод для отключения этого наследования. В общем, тебе нужно размещать и направлять пули в глобальной системе координат, а ты их, видимо, либо к игроку крепишь, либо в системе игрока вычисляешь вектор направления. Читай API Node2D, там всё из названий методов понятно (сравни описания global_... и local_...).
>Да и не хочу я просто ещё и в годоте с 3д возиться.
Не так уж и сложно. Ну, не важно, просто знай, что при желании ты можешь рендерить 3D поверх 2D и наоборот, генерировать текстуры в реальном времени и так далее. У Godot отдельное API для 2D, но это не мешает смешивать графику в разных вариантах. Если вдруг захочешь, например, трёхмерную карту многоуровнего подземелья, что лучше всего будет выглядеть как 3D голограмма. Так что при планировании фич учитывай, что не ограничен 2D.
>ковырять этот туториал пока:
Ну вот там топ-даун, а не изометрия...
>Пока я даже структуру того, как оно всё работает и взаимодействует слабо понимаю.
Движок каждый кадр обходит все ноды в дереве, вызывая обработчики событий (здесь они называются "сигналами"), и в этих обработчиках работает твой код. Твой код меняет свойства нод или внутренних систем движка (здесь они называются "серверы"), и движок идёт по дереву дальше. Цикл повторяется, пока программа не завершится по требованию пользователя, твоей команде из кода или из-за критической ошибки. По умолчанию движок работает в один поток, поэтому его поведение предсказуемо и можно поверхностно изучить, натыкав print().
>Зачем вы лезет щас в 4ку?
RC - Release Candidate - Кандидат на Релиз -> версия находится на финальной стадии развития, проводятся проверки на баги и последние багфиксы. Скоро релиз.
>>861620
>У пути есть параметр Advance и он был выставлен в Auto
А ты этого не знал? В 3.х точно такие же параметры.
>А ты этого не знал? В 3.х точно такие же параметры.
Я первый раз использую, в туторах по тройке чёт особо не видел про это...
>в туторах по тройке чёт особо не видел про это
https://docs.godotengine.org/en/3.1/tutorials/animation/animation_tree.html
>Auto Advance will turn on the transition automatically when this state is reached. This works best with the At End switch mode.
>Это разные проекции.
Да бог бы с ними.
>Завидую. Тяжело было учиться?
Ну если тебе что-то нравится делать, то нет, не тяжело. Никогда себя не заставлял. 3д с 18 года занимаюсь, но набегами. Раз в пол года по месяцу-два что-то делал. Начинал с даза, потом пересел на блендер.
>Читай API Node2D
Читаю. Не скажу, что понимаю, как с этим работать. На пике код, который спавнит эту пулю. Насколько я вижу, спавниться она должна по глобальным координатам. Так она и делает. И когда перс стоит, вроде всё в нужную сторону летит, но когда он движется - нет.
Ещё у туториала, насколько я вижу, устаревший код. Метод get_root() не выпадает в списке доступных, хоть и работает.
>По умолчанию движок работает в один поток, поэтому его поведение предсказуемо и можно поверхностно изучить, натыкав print()
Спасибо, натыкал. Полезно.
Но опять таки непонятно, как мне заспавнить пулю в мире, по координатам игрока и направить её в сторону положения мышки? Сейчас, насколько я вижу, пуля вылетает в зависимости от вращения тушки. А это не совсем то, что я хочу.
Я понял, пуля коллайдится с игроком, надо просто спавнить её вне коллизии. Топаю дальше.
Вектор направления движения так определяй:
>var motion := Vector2(
>Input.get_axis("left", "right"),
>Input.get_axis("up", "down")).normalized()
Это короче и учитывает стики геймпада, если когда-нибудь захочешь реализовать поддержку геймпада. Т.е. игрок сможет двигаться медленнее, если наклоняет стик не полностью, а только слегка.
https://docs.godotengine.org/en/stable/classes/class_input.html#class-input-method-get-axis
>>861784
>Я понял, пуля коллайдится с игроком, надо просто спавнить её вне коллизии.
Ты пулю сделал как RigidBody2D. Если ты делаешь классический топ-даун шутер, а не что-то вроде Angry Birds с видом сбоку, то, ИМХО, лучше использовать Area2D, после чего двигать пулю по прямой в её собственном скрипте, пока она не зарегистрирует пересечение с чем-либо. Таким образом можно будет снизить нагрузку, исключив лишнюю физическую симуляцию (которая здесь не нужна), и точнее контролировать, что происходит на экране.
У Area2D пули можно снять галочку с Monitorable и оставить галочку Monitoring, т.к. только пуля ждёт пересечения с чем-либо. Дальше тебе нужен будет обработчик сигнала body_entered в коде пули, в котором ты проверяешь, в кого/во что попала пуля, посылаешь ему, если нужно, сигнал "в тебя попала пуля" и самоуничтожаешь пулю... или меняешь ей направление, если хочешь сделать рикошеты, но для точного вычисления угла потребуется сначала сделать рейкаст от пули в направлении того, во что она врезалась, получить нормаль столкновения и уже от нормали сделать рикошет; но RigidBody2D в такой ситуации скорее всего начал бы вращаться, т.е. всё равно пришлось бы заняться математикой вручную.
Короче, RigidBody2D используй только когда тебе реально нужны какие-то объекты, которые реалистично друг от друга отскакивают с учётом массы и трения, или на которые реалистично действует гравитация (которой в топ-даун шутере всё равно нет).
> Input.get_axis
Хуясе! Когда они добавили эту важнейшую функцию? Я пропустил момент.
Сам спросил, сам отвечаю. Добавили в 3.4. Вычисляется простым перещёлкиванием версии в доках.
Нужно ли ждать релиза 4 версии или для вкатыша это должно быть похуй и нужно только хай левел скил пацанам?
>>x или y?
>Да. # OP
ОП как всегда... Петросяна прикрепить не забудь в следующий раз, чтобы смешнее было.
>>862127
>Нужно ли ждать релиза 4 версии?
Ждать осталось немного, движок в стадии Release Candidate, что означает скорый выход в релиз. Ждать осталось максимум несколько недель.
Нужно ли? Вопрос сложный. Ты можешь уже сейчас пробовать что-то сделать на RC версии, она будет достаточно стабильна. Но большинство туториалов, примеров и т.д. пока что только для 3.x ветки, и даже официальная документация не полностью обновлена, так что о некоторых фичах можно узнать только из кода движка или обсуждения пулл реквестов на гитхабе. Однако, если ты начнёшь сейчас изучать 3.x, то в скором времени тебе придётся переходить на 4.0, запоминая отличия в API и GUI редактора. Так что если ты абсолютный новичок, никуда не торопишься и тебе есть чем заняться (рисовать спрайты или делать модели к будущим играм), я бы подождал выхода 4.0 с обновлением документации и туториалов, но если тебе очень хочется нырнуть в геймдев прямо сейчас, то можешь начать с 3.x, а потом когда-нибудь перейти на 4.x. Всё равно для первых нубских игр нововведения 4.0 тебя почти никак не касаются, там больше по 3D всё меняли.
>нужно только хай левел скил пацанам?
Версия 4.0 полностью заменяет ветку 3.x, новые фичи будут выходить только в ветке 4.x, а ветка 3.x будет получать только багфиксы. Поэтому рано или поздно все разработчики перекатятся на 4.x, как раньше перекатились с двойки на тройку. Сделано это так, потому что на ветке 3.x за эти годы выпущено много игр, которые всё ещё нужно поддерживать, но переводить на 4.0 будет слишком сложно, нерационально или недопустимо (как минимум брошена поддержка GLES2). Новые фичи этим играм не нужны, а вот багфиксы пригодятся. Поэтому новые игры будут делать только на 4.x, а игры в процессе разработки переводить с тройки на четвёрку, даже если основные нововведения четвёрки конкретной игры не касаются. Т.е. переход на новую версию растянут исключительно из необходимости поддерживать уже выпущенные игры. Godot заботится об играх, в отличие от глюкнити.
А ты что хочешь делать? 2D? 3D? Какой жанр?
Нужно ждать 4.2, потому что 4 попросту сырая. Ну или в 3.5.1 вкатываться, хотя тут хз.
>Нужно ждать 4.2, потому что 4 попросту сырая.
Да что уж там, лучше сразу 6.0 ждать, потому что в 5.0 будет новый графический API PolkanGL, но он слишком сырой пока, а вот в 6.0 допилят будущий графический API PuushkaX, вот тогда заживём, сцены из миллиардов треугольников будут ещё до нажатия на ярлык игры рендериться, а текстуры встроенная нейронка на чипе BIOS за отрицательное время генерировать ещё до сборки компонентов в целый системный блок. Нанотехнологии же. А пока версия 6.0 не вышла, придётся на 3.5 сидеть.
Спасибо большое за развёрнутый ответ!
>А ты что хочешь делать? 2D? 3D? Какой жанр?
да я прост нуб, хочу всё попробовать, а годот, мне кажется, дружелюбной штукой на которой можно попробовать всё.
Вывод:
Заморачиваться с пулом реально стоит если объектов в секунду как минимум 500 будет создаваться (и они все одновременно на экране будут).
1600 пуль на экране из пула дают где-то 100 фпс у меня, 1600 при instantiate - меньше 30
По серверам чёт находится, а по мешинстанц2д вообще пиздец, один толковый видос только видел и ничего почти в доке
>годот, мне кажется, дружелюбной штукой на которой можно попробовать всё.
Всё так.
>>862358
>кинематик боди для пуль
Зачем? Тебе нужно, чтобы пули скользили вдоль стен? Нет? Тогда используй Area, зачем тебе кинематики?
>Заморачиваться с пулом реально стоит если
Если хочешь гладкий экспириенс для всех игроков, даже с не очень мощными компьютерами. А то потом будут жаловаться, что на вид простая 2D игра тормозит больше ААА 3D, и винить в этом движок.
Если у тебя что-то двигается и требует реакцию игрока - лучше пожертвовать памятью, чем процессором, даже если тебе кажется, что потеря тактов несущественна. Потом накинешь сверху ещё что-то и внезапно обнаружишь, что экономить всё же стоило.
Тем более буллетхелл, где всего один случайный лаг компьютера может стоить игроку прохождения.
>>862359
>мешинстанц2д
>ничего почти в доке
Лол, а что тебе нужно-то?
>использованию серверов
Берёшь и используешь.
https://docs.godotengine.org/en/stable/tutorials/performance/using_servers.html
Если кратко, то ноды - это всего лишь удобные интерфейсы к серверам, позволяющие описать сцену декларативно в tscn файле. Ты можешь обращаться к серверам из кода без использования нод, облегчая дерево сцены. Все методы интуитивно понятны, главное хранить где-то RIDы, которые ты получаешь от сервера, ибо потеряешь RID - потеряешь доступ к объекту на сервере (что в общем и целом ведёт к утечкам памяти). Общая схема работы такова:
- запрашиваешь создание объекта;
- получаешь и сохраняешь RID;
- вносишь изменения по RID;
- радуешься/отдыхаешь.
Всё остальное сервер делает сам.
>>862367
>Прошло 6 недель и я понял
Ты мазохист или тебе просто не нужно было? Если бы мне нужно было, но не получалось, я бы намного раньше бросил и пошёл бы писать велосипед.
>Ты мазохист или тебе просто не нужно было?
Я уже писал о том как мне трудно это даётся. Знаю что это бессмысленно, у меня не получится реализовать свою простую задумку...
> Ждём
А часики-то тикают.
>Всё так.
Но четверка становится менее дружелюбной при этом?
Ну смотри, релиз кандидат 2 дичайше пролагиввает при запуске и при закрытии. Экспортированные проекты (примитивные из одной сцены) тоже дичайше пролагивают при открытии и закрытии, но во втором кандидате рандомно. Видно, над этим работают, но ещё не победили.
Насколько дружелюбное впечатление это оказывает на мимокрока - решай сам.
>пролагивают при открытии
Это не лаг, это компиляция шейдеров.
>при закрытии
Не замечал проблем, что ты там делаешь?
Движок шейдеры на диск пишет, у тебя HDD?
> это компиляция шейдеров
Если бы один раз, когда кэш создаётся, я бы не возражал. Но оно реально пролагивает постоянно.
> что ты там делаешь?
Фишка в том как раз таки, что ничего не делаю.
Вообще, Godot всегда тормозил на старте и особенно на открытии проекта. Но если раньше юзер сразу видел перед собой GUI, с которым невозможно взаимодействовать из-за тормозов, то сейчас просто чёрная заливка в окне, а после появления GUI он работает максимально плавно. Думаю, это очень правильно сделано, но всё же надпись вроде "подождите, идёт загрузка ресурсов/компиляция шейдеров" была бы лучше чёрного экрана.
Аналогично с проектами. Первый запуск требует компиляции множества шейдеров на диск, в процессе чего окно залито одним цветом. Но потом почти сразу 1500+ кадров в секунду на сцене с кубами. Со второго запуска, если не удалять с диска кэшированные шейдеры, игра запускается практически мгновенно.
Как я понимаю, это стандарт индустрии. Играю в разные игры и они очень долго запускаются в первый раз, но со второго раза всё быстро. На диске куча папок с огромным количеством каких-то шейдеров, некоторые из них достигают веса больше гигабайта. Так что Godot тут ни в чём не виноват, все вопросы к производителям видеокарт и разработчикам видеочипов - почему они заставляют возиться с компиляцией шейдеров.
На закрытии проблем нет вообще. Возможно, у тебя там какие-то проблемы с антивирусом или чем-то вроде того. На счёт рандомности не знаю, не замечал, но возможно что у тебя там какая-то автоочистка настроена и портит сохранённые шейдеры, вынуждая компилировать и сохранять их повторно. Или ты сам папки .godot в проектах чистишь (шейдеры теперь хранятся там).
>Если бы один раз, когда кэш создаётся, я бы не возражал. Но оно реально пролагивает постоянно.
Опиши характеристики ПК, включая модель, возраст и основные показания SMART системного SSD и того, на котором у тебя Godot с проектами. Также проверь диспетчер задач, включив высокую скорость обновления и смотря на графики дисков, следи за скоростью отклика. Также открой дефрагментацию дисков и запусти её принудительно, это отправит сигнал TRIM и позволит SSD оптимизировать их работу, ускорив отклик и снизив износ при записи. Поскольку ты сам ничего толком не говоришь, я вангую, что у тебя SSD дешёвый, изношенный или неправильно обслуживается, поэтому Godot тормозит на каждой операции чтения/записи. Другие приложения могут работать нормально, т.к. реже читают/пишут или вообще не нуждаются в постоянной работе с файлами. Или ты просто привык, что у тебя комп тормозит...
>Фишка в том как раз таки, что ничего не делаю.
Вообще? Просто открыл проект и сразу закрыл?
2. Кнопки выбора редактора. Это одна сцена, связанная несколько раз со сценой меню с заменой надписей. Нет, это не TextureButton, т.к. он имеет неудобные ограничения, поэтому я сделал это кнопки на базе обычного Button и TextureRect. Планирую вставить туда гифки с короткой демонстрацией каждого редактора, которые будут запускаться при наведении курсора. Если кому-то интересно, могу подробнее описать, как сделать такую же кнопку, чтобы она приятно работала. Правда, теперь меня напрягает слишком сильная разница между разными меню, т.к. делать всё плиточным я не хочу, а простые кнопки для редакторов не будут достаточно наглядными.
3. Набросок редактора зданий, или, скорее, шаблонов для генерации зданий. Я подумываю над тем, чтобы сделать упрощённую версию Townscaper, только помимо внешней оболочки будет генерироваться интерьер, соответствующий выбранному типу комнаты. Базовая идея в том, чтобы указать планировку первого этажа, остальные этажи с минимальными отличиями повторяют первый. Можно расширить до редактирования каждого отдельного этажа индивидуально, но зачем?.. Суть планировки: вместо расстановки отдельных стен/кубов, пользователь отмечает предназначение клетки - спальня, кухня, прихожая, санузел, лестница и так далее - а игра самостоятельно расставляет все необходимые стены и декорации с опорой на мета-параметры здания, если они указаны. Это максимально избавляет от рутины, оставляя возможность сделать что-то оригинальное без написания тонны кода. Процедурная генерация в любом случае следует шаблонам, только в данном случае шаблон визуально настраивается, а не хардкодится в скриптах игры.
4. П Р О К Р А С Т И Н А Ц И Я
> Вообще, Godot всегда тормозил на старте
Вообще-то, нет, вот прямо сейчас у меня тот же самый проект на трёшке 3.5.1 открывается без лагов.
> На закрытии проблем нет вообще. Возможно, у тебя там какие-то проблемы с антивирусом
Почему "антивирус" реагирует только на четвёрку?
>>862526
> Опиши характеристики ПК, включая модель, возраст и основные показания SMART системного SSD и того, на котором у тебя Godot с проектами.
Смарт ОК. Зиончег от анончега с Али, 8 ядер по два логических, оперативка 16 гигов ДДР4 в одноканале, ПЕЧ 1060, 6 Гб.
> Вообще? Просто открыл проект и сразу закрыл?
Да. Тупо по системной кнопке с крестом.
> открой дефрагментацию дисков и запусти её принудительно, это отправит сигнал TRIM и позволит SSD оптимизировать их работу, ускорив отклик и снизив износ при записи
Щас посмотрим.
> Также открой дефрагментацию дисков и запусти её принудительно, это отправит сигнал TRIM и позволит SSD оптимизировать их работу
> что у тебя SSD дешёвый, изношенный или неправильно обслуживается, поэтому Godot тормози
Почему трёшка не тормозит?
Почему винда не тормозит?
Почему ничего не тормозит, кроме неоптимизированного релиз-кандидата?
Малаца
Добавь простенькие движения ног, хоть процедурные, сразу презентабельность в 10 раз вырастет.
>тот же самый проект на трёшке
Так ты портируешь что-то? Сильно сложное?
Попробовал "портировать", много правил, чтобы запустить хотя бы с ошибками. Редактор работает без каких-либо "лагов", плавно. Сильно разочаровывает количество различий в API, но это цена долгой разработки мажорной версии. Было бы хуже, если бы они каждый год новую мажорную выкатывали.
>Почему "антивирус"
Лол, откуда мне знать, это просто распространённое предположение, что какое-то стороннее ПО вмешивается в работу программы.
>Зиончег от анончега с Али, 8 ядер по два логических, оперативка 16 гигов ДДР4 в одноканале, ПЕЧ 1060, 6 Гб.
Не знаю, что у тебя там лагает, у меня всё плавно:
- Xeon E5450 (4 @3.0 GHz) с алиэкспресс,
- 8 GB DDR2 в 4 слотах (2 канала),
- ඞsus 750Ti 2GB OC,
- SSD Intel (SATA2).
Да, Godot 4.0 RC2 жирнее 3.5, но не критично.
С альфами проблем было куда больше.
Напиши им на гитхаб, что на твоём конкретном ПК жуткие лаги и вообще пользоваться невозможно, раз ты вынужден сидеть на 3.5. Приложи там логи, какие требуются, пусть разбираются. Если сидеть сложа руки и жаловаться на производительность, но не говорить об этом основным разработчикам, то высока вероятность, что производительность так и останется недостаточной, по крайней мере на твоём ПК.
Для 2d и 3d игр обязательно использовать разные контролеры KinematicBody и физический пол.
Как можно добавить разные эффекты на экран?
>Для 2d и 3d игр обязательно использовать разные контролеры KinematicBody
Конечно, KinematicBody2D и KinematicBody3D никак друг с другом не связаны. Однако:
1. Ты можешь двигать KinematicBody2D без спрайта, а потом преносить его положение на KinematicBody3D:
Vector2(X; Y) -> Vector3(X; 0; Y)
2. Ты можешь написать абстрактный контроллер, который считывает нажатия кнопок и генерирует все необходимые векторы, а потом цеплять его либо на KinematicBody2D, либо на KinematicBody3D.
Только вот 3D персонажам обычно требуется намного больше всего учитывать во время движения, поэтому написать полностью универсальный контроллер хотя и возможно, но не имеет смысла. Смысл есть только если геймплей в твоей игре происходит в одной плоскости и ты хочешь реализовать два ракурса камеры - 2D и 3D, но в таком случае KinematicBody3D тебе вообще не нужен, потому что ты можешь просто переносить положение KinematicBody2D на MeshInstance3D.
>физический пол
Что? Ты про StaticBody? Зависит от игры и того, каким способом ты реализовал контроллер персонажа.
>Как можно добавить разные эффекты на экран?
Кратко: читай про шейдеры и частицы.
В коде шейдеров можно рисовать самые разнообразные спецэффекты на разных поверхностях, включая весь экран в целом. Частицы же нужны в случаях, когда ты хочешь разбросать по экрану множество похожих объектов, которые просто пролетят и исчезнут: искры, огоньки, клубы или кольца дыма и т.п.
Некоторые спецэффекты универсальны для 2D и 3D, поскольку накладываются сразу на весь экран.
Тогда я не буду делать универсальный KinematicBody. Меня бесит что после каждой неудачной попытки мне нужно начинать все с начало. Хотя можно скопировать файл со скриптом персонажа из одного места в другое, но со скриптом меню где нету привязок к кнопкам уже не выходит.
>Ты про StaticBody?
Я про обычные тайлы по которым ходит персонаж.
>Кратко: читай про шейдеры и частицы.
>В коде шейдеров можно рисовать самые разнообразные спецэффекты на разных поверхностях.
Попробую, хотя из скаченных аддонов шейдеры мне высунуть не удалось.
>Меня бесит что после каждой неудачной попытки
Рассматривай это не как неудачи, а как ценный опыт.
>мне нужно начинать все с начало
Зачем? Ты так часто меняешь жанры, что у тебя вообще ничего реюзабельного не остаётся?
>со скриптом меню где нету привязок к кнопкам уже не выходит
Чего??? Ты точно не опечатался? Менюшки в Godot чрезвычайно легко переносить с одного проекта на другой, если правильно организовать все файлы.
Создавай все сцены как самодостаточные. Т.е. сцена ни в коем случае не должна зависеть от наличия конкретного родителя или конкретных соседей. В коде обязательно делай проверки на null, если ты вынужден обращаться к каким-то другим объектам, но лучше генерировать сигналы вместо прямых обращений к чужим методам (кроме непосредственных потомков). Выноси все важные параметры в export, чтобы настраивать сцену через инспектор. Разделяй большие объекты на независимые маленькие, которые соединяются в один крупный при необходимости. Godot даёт тебе всё необходимое, чтобы сделать проект максимально модульным, тебе нужно только знать, как этим пользоваться.
>шейдеры мне высунуть не удалось
Обычно они либо в отдельных файлах (.tres), либо внутри файла сцены (.tscn). Во втором случае шейдер можно извлечь прямо из файла, открыв .tscn в блокноте и скопировав нужный кусок в редактор шейдеров Godot. Но удобнее это сделать в инспекторе Godot, там выбираешь нужный шейдер, вызываешь выпадающее меню и выбираешь, кажется, "save as", чтобы сохранить шейдер в отдельный файл.
Здесь можно найти бесплатные готовые шейдеры:
https://godotshaders.com/
> сидеть сложа руки
Там и без меня сотни ишьюсов открыто. Надо подождать релиза.
> Так ты портируешь что-то? Сильно сложное?
Ничего такого. Пару дровколлов отрисовки на канве и севлоад настроек. Вангую, что тормозит сборщик мусора, после того, как после меня остались ссылки на открывавшийся файл. Вот, попрошу ознакомиться:
О, сука!
Это издевательство какое-то!
Щас экспортировал проект в режиме отладки. Ну, думаю, там же консолечка, в консолечке будет написано, что не так. И что вы думаете? Ну вы догадались уже, да? Экспортированный в режиме дебага проект летает, как фотон! Сука!
>Рассматривай это не как неудачи, а как ценный опыт.
Опыт ценен только тогда, когда благодаря ему ты продвинулся дальше.
>Зачем? Ты так часто меняешь жанры, что у тебя вообще ничего реюзабельного не остаётся?
Все кривое и связанно со скриптами. Пытаюсь выбрать для себя наилучший вариант, который я смогу в дальнейшем дорабатывать. Пришло понимание что пытаться каждый раз думать о новом старте худшая идея. Проще когда у тебя есть модульная система которая позволяет тебе использовать наработки из прошлой работы. Как в Assassin's Creed на базе одной игры делали другие.
>Чего??? Ты точно не опечатался? Менюшки в Godot чрезвычайно легко переносить с одного проекта на другой, если правильно организовать все файлы.
Положил меню в одну папку, теперь все работает. Виноват.
>Во втором случае шейдер можно извлечь прямо из файла, открыв .tscn в блокноте и скопировав нужный кусок в редактор шейдеров Godot. Но удобнее это сделать в инспекторе Godot, там выбираешь нужный шейдер, вызываешь выпадающее меню и выбираешь, кажется, "save as", чтобы сохранить шейдер в отдельный файл.
Эту схему я понял вчера на шрифтах. Мне не понятно куда мне его нужно вставить во вкладке Инспектора.
>в отдельных файлах (.tres)
Нашёл и добавил в свой проект. Осталось только понять как послойно ставить его выше диалогов и персонажа, или ниже выплывающего меню паузы.
Тебе не хватает теоретических знаний. Типичная проблема самоучек. Рекомендую почитать/посмотреть базу по паттернам, по архитектурам, по программному дизайну. Ты охуеешь от того, что всё, о чем ты тут выше жаловался - давно решено.
>тормозит сборщик мусора
Чему там тормозить, на GDScript-то?
>Note: In C#, reference-counted objects will not be freed instantly after they are no longer in use. Instead, garbage collection will run periodically and will free reference-counted objects that are no longer in use. This means that unused ones will linger on for a while before being removed.
Так что GDScript сразу всё очищает.
>после меня остались ссылки
Они не остаются, тебе не нужно присваивать null. Если ты объявил переменную внутри if и сохранил в неё ссылку на объект, то после if переменная больше не существует, ссылки нет и объект уничтожается.
В документации показано присваивание null для глобальных переменных, когда ты постоянно что-то читаешь или пишешь. Но в случае записи лучше иногда вызывать flush(), чтобы убедиться, что файл записан на диск, не уничтожая открытый FileAccess.
"Смыв" файла, если что, фича ОС, а не движка; ОС не сразу пишет файлы на диск, а только когда заполнится буфер, файл будет закрыт или вызван flush(). Это сделано для ускорения работы всего компьютера.
Я читал. Мне показалось странным твоё понимание "сборщика мусора" в GDScript. Так вот, его нет. RefCounted уничтожаются сразу после обнуления их счётчика ссылок, а обычные Object движок за тебя чистить не будет. Во всяком случае по моему опыту это так.
Короче, опытным путём я установил, что притормаживание при закрытии окна происходит, если сразу закрывать только что открытое окно, и связано это с тем, что движок не успевает записать логи в файл (который в папке user://logs/ лежит по умолчанию). После притормаживания, файл лога остаётся пустой. Если чуток подождать - файл заполняется стандартными строками, которые мы обычно видим в окне вывода в редакторе.
> файл будет закрыт или вызван flush()
Вот кокрастоке подозреваю с этим где-то в недрах двигла проблемы и возникают.
> Так вот, его нет. RefCounted уничтожаются
В кодинге не бывает такого, чтобы что-то делалоСЯ само. В компьютере обязательно есть "делатель", который делает, без "-ся". В случае со сборкой мусора путём подсчёта ссылок, сборщик мусора есть и именно сборщик мусора занимается высвобождением памяти, после того, как ссылок становится 0.
Вот тебе инфа https://ru.wikipedia.org/wiki/Сборка_мусора#Алгоритм_подсчёта_ссылок
>Опыт ценен только тогда, когда благодаря ему ты продвинулся дальше.
Ну пока ты в интернете о своих неудачах жалуешься и больше ничего кроме жалоб не делаешь, да, бестолковый какой-то опыт. Это ведь ты?
>связанно со скриптами
Пиши скрипты, которые получают на вход ссылки и работают с этими ссылками. Пример: скрипт "оружие" требует спрайт оружия, спрайт пули и ресурс с описанием параметров оружия, таким образом ты можешь использовать всего один скрипт во всех своих шутерах для всех своих видов оружия, меняя только спрайты и параметры оружия.
>Положил меню в одну папку
Ага, это косяк абсолютных путей в tscn, не могу понять, что им мешает сделать относительные пути...
>куда мне его нужно вставить во вкладке Инспектора
Создаёшь ShaderMaterial для ноды, которая поддерживает материалы, а потом в этот материал вставляешь шейдер. Читай документацию, там всё это объяснено.
>послойно ставить его выше диалогов и персонажа, или ниже выплывающего меню паузы
Вот универсальный инструмент:
https://docs.godotengine.org/en/stable/classes/class_canvaslayer.html
Хотя есть другие способы сортировки.
>сборщик мусора есть
Я имею в виду, что он максимально простой по сравнению со сложными сборщиками, которые накапливают в памяти несколько гигабайт мусора и потом роются в нём, пытаясь определить, что нужно, а что нет. Вот в C# вроде как именно такой сложный сборщик, из-за чего игры на Unity и других подобных движках с C# могут сжирать гигабайты памяти и потом натужно кряхтеть, высвобождая эти гигабайты в рандомные моменты времени.
Просто сравни обычное ведро с педалькой, в которое ты кинул мусор и забыл, отпустив педальку, с каким-нибудь Валли, который ездит по огромной свалке и сортирует мусорные кубы. По сравнению с Валли ведро с педалькой не назовёшь "сборщиком", это максимально простой механизм. В этой аналогии явный вызов метода .free() - это не бросить мусор в ведро, а с силой его пропихнуть и ещё палкой примять.
>Добавь простенькие движения ног, хоть процедурные, сразу презентабельность в 10 раз вырастет.
Та моделька временная, только чтобы примерно оценивать пропорции объектов. Считай это линейка, изображающая персонажа средней высоты.
В идеале я хочу сделать нормальную модельку с подробной кастомизацией и множеством анимаций, которая будет использоваться для всех персонажей одновременно. В относительно оригинальном стиле и с отлаженным пайплайном, чтобы быстро добавлять новый контент - одежду, анимации и т.п. Поэтому пытаюсь сделать сам.
Попытки много лет делаю с перерывами в полгода/год, бросаю из-за того, что сложно управляться с инструментами в блендере, и ещё из-за того, что результаты чаще всего мне не нравятся визуально, последнее больше всего убивает мотивацию продолжать (игру в том числе). Совсем уж кубического человечка а-ля Майнкрафт делать не хочется.
Вот эта наиболее удачная в общем и целом. Но всё равно сомневаюсь, что удастся сделать как хочу, т.к. косяков полно и я не знаю, как их исправить. Хочется доделать, но каждый раз боюсь, что не получится ничего.
Есть вопрос. Какой алгоритм генерации меша используется?
Кстати (или нет), посмотри на Lego Worlds. Как тебе стилистика?
>Какой алгоритм генерации меша используется?
Алгоритм "метод проб и ошибок":
1. Делаешь меш ручками.
2. Оцениваешь: нравится?
3. Если нет, возврат к 1.
4. Конец алгоритма.
Я же вручную делаю меш, чтобы потом блендшейпами его подгонять из кода/GUI игры. Насколько я знаю, абсолютное большинство игр с кастомизацией персонажей используют блендшейпы на одной базовой модели. Обычно не дают вносить слишком сильные изменения, вроде сделать пузатого жирдяя или тощую спичку, но сделано это исключительно в целях игрового баланса, особенно в случае онлайн-игр с нон-таргет системой боя, как в шутерах, либо чтобы в анимациях не было провала рук в тело. В моём случае баланс не важен и анимации всё равно будут грубее, так что могу использовать этот способ на 200%.
Если ты предлагаешь генерировать меш прямо в игре из полигонов, то это крайне сложная задача, особенно с учётом одежды, если я хочу добиться чего-то более-менее привлекательного. Поэтому с самого начала рассматривал только классическое моделирование и затем изменение модели через блендшейпы, замену текстур и т.д. Мне кажется, люди недооценивают блендшейпы, т.к. они могут менять модель до неузнаваемости, и единственное ограничение - это чтоб анимации скелета не перекосило. Конечно, таким способом не сделать дополнительные конечности, но я же не Spore делаю (вот там реально базовый меш и скелет прямо в игре генерируется, заранее заготовленные меши - только отдельные части тела вроде глаз и ртов).
>посмотри на Lego Worlds. Как тебе стилистика?
Ты про ландшафт или про персонажей?
Мне такое не нравится. В детстве много играл в реальное Лего, но Lego Worlds не зашло как-то (играл на этапе предварительного доступа, когда толком ничего не было, только базовые возможности). Ландшафт там можно менять по блокам, как настоящий конструктор, но визуально это просто ад какой-то, как будто ходишь по рассыпанным деталькам Лего голыми ногами. Персонажи точно повторяют человечков из реального Лего, но мне их стиль никогда не нравился: уродливые клешни, уродливые ноги, плоское тело с текстурой и кастрюля вместо головы. Реальный конструктор такой, чтобы можно было соединять части тел человечков со всеми остальными блоками в самых разных комбинациях, но в виртуальном мире делать таких уродцев нет никакой необходимости. Хотя... человечки из Лего лучше базовой формы из Роблокс (мне кажется, Роблокс нагло скопипастили Лего, но Роблокс выглядит как какой-то китайский ноунейм клон знаменитого бренда).
Сегодня немного поменял физику машины. Пытаюсь добиться чего-то вроде GTA IV в плане подвески на поворотах с примесью чего-то вроде GTA V в плане существенных заносов с потерей управления. Почему-то не получается сделать подвеску ещё мягче - она с какого-то значения начинает проваливаться под землю. Выяснил, что можно сделать занос, но управление какое-то не такое, совсем не похоже на GTA. Да, я по-прежнему использую стандартный VehicleBody, но движок RAGE 1/2 использует внутри Bullet Physics, так что по идее должно быть возможно смоделировать их управление. Или всё же не избежать написания своей физики с нуля?
Накидал простое преследование ИИ игрока на машине и имел большое удовольствие с ним играть. Код в скрипте наипростейший, самое сложное в нём - это использование .dot(), остальное тупо if-else. Но движения машины в результате поразительно реалистичные, как будто другой игрок в мультиплеере управляет.
Собственно, есть пара мыслей про ИИ. Из чего состоит мозг? Из нейронов. Что делает нейрон? Реагирует на раздражитель синапсов (if...) генерацией сигнала на аксоне (then...). Т.е. нейрон в самом абстрактном виде - это конструкция if-then, даже не if-then-else. Разница в том, что нейроны рождаются из хаоса, умирают и рождаются вновь, а в процессе жизни меняют своё условное выражение даже несколько раз в день за счёт гормонов, влияющих на состояние синаптических связей. Искусственные нейронные сети симулируют эти изменения модификацией весов связей, но единственный ли это способ, а главное, нужно ли делать именно так? Если нейрон не делает ничего особенного, кроме if-then, то и моделировать его можно через if-then. Разве что у биологического нейрона есть эффект краткосрочной памяти, т.е. они срабатывают с определённой частотой, а не по первому требованию.
Короче, я к чему всё это. Обычно, if-then мы пишем в коде и этот код никак не меняется. Но что такое if-then? Это условие и действие. Если вынести условие и действие за пределы статичного кода, можно подменять все if-then по желанию, увеличивать их число или уменьшать, соединять друг с другом в каскады и т.д., при этом основной код останется без изменений. И если мы можем менять if-then произвольно, то мы также можем генерировать их на ходу, оценивать их ценность и удалять наименее ценное. Т.е. по сути получаем мозг, состоящий из одних только if-then, но способный учиться опытным путём.
Самый главный секрет в том, как организовать россыпь if-then в цельную систему, которая не будет метаться от одного к другому, не будет пытаться пойти налево и направо одновременно? Ответ удивительно прост, нужно менять состояние системы установкой флагов и проверять наличие этих флагов в условных выражениях, а выбор одного действия из множества несовместимых может быть произведён как сортировка всех возможных действий по уровню срабатывания группы условий, равной сумме весов каждого условия группы. В результате получаем цепочки состояний системы и связанные с ними решения, меняющие состояние системы.
Да, разумеется, этот подход не производит планы, как делает GOAP, т.е. этот "мозг" всегда реагирует только на одно конкретное состояние и по умолчанию не думает о будущем (но, теоретически, может). И в отличие от нейросетей этот мозг не решает задачу за один проход, а непрерывно думает прямо в процессе своей жизнедеятельности, что идеально подходит к симулятору жизни, который я хочу сделать - мне не нужны идеальные решатели проблем, мне нужны живые организмы, пытающиеся выжить в заданной среде. Я всё же не игру делаю, так что "проигрыша" как такового в ней нет.
Подозреваю, что вручную настраивать эту систему сложно, но тут мы вспоминаем, что if-then в этой системе не захардкожены и могут произвольно меняться. Т.е. в теории можно накидать базовых условий и затем запустить симуляцию, в результате которой условия будут меняться, дополняться и удаляться, пока не получится наиболее эффективное поведение. Вопрос в том, сколько времени займёт такая симуляция, будет ли она эффективна? Понятия не имею, но даже если это жутко неэффективно, возможность точного контроля и расшифровки такого мозга даёт преимущество перед "обычными" нейросетями, где тысячи параметров по отдельности не означают ровным счётом ничего, тогда как у моей модели условия и действия всегда конкретны... хотя, если представить себе процедурную генерацию условий, что получится в итоге? Тысячи флагов с числовыми ID, которые приводят систему к решению какой-то задачи, но при этом дать им какие-то осмысленные имена сложно. В общем, не знаю, но попробовать сделать такое нужно, т.к. хардкодить поведение вообще никакого желания нет. Главное, что мой метод подразумевает крайне высокую модульность и полную взаимозаменяемость любых модулей, т.е. легко можно заняться процедурной алхимией поведения.
Триангуляцию используешь? Или у тебя просто сетка квадратная, рассеченная на прямоугольники, и ты тягаешь Z координату?
Пока что использовал стандартный примитив в Godot, чтобы поскорее увидеть результат.
https://docs.godotengine.org/en/stable/classes/class_planemesh.html
Я знаю, в идеале треугольники нужно разворачивать в зависимости от расположения вершин, чтобы не было характерных ступенек на резких перепадах высот. Потом как-нибудь этим займусь. Это не имеет большого значения, потому что касается только визуализации. В файле сохранения всё равно будут только высоты точек, для навигации тоже нужны только высоты.
Я раньше пробовал делать меши вручную из кода, я знаю, как это делать, но не знаю, как посчитать ARRAY_TANGENT, перепробовал разные варианты и всё время какая-то фигня получается. А без этих данных карта нормалей на такой меш не ложится, ей зачем-то нужен этот "тангент спейс". Как его автоматически сгенерировать я тоже не понял, хотя где-то в движке оно генерируется.
Нашел пару видео про годот, на выходных посмотрю.
>>862830
>Это ведь ты?
Сообщение радости что получилось поменять шрифт было моим. Когда есть успехи могу с радостью с ними поделиться.
>что им мешает сделать относительные пути...
Не понял.
>Вот универсальный инструмент:
Мне по документации ничего не понятно! Какой и куда писать код?
>Создаёшь ShaderMaterial для ноды
Хотел написать что я понимаю как создать ноду, но похоже опять все напутал.
> Нашел пару видео про годот
Я предположил (и продолжаю предполагать) что ты базовых основ кодинга не знаешь. Поэтому рекомендую смотреть видео не по годоту, а общеайтишное.
Понимаешь ли в чём дело. В годоте Хуан всё делает по общеизвестным паттернам. Иногда его заносит и он даёт весьма нестандартные названия тем или иным вещам, но в целом все подходы к построению АПИ движка мною угадываются. Я не сказать, чтобы крутой профи, но кой-чего знаю-умею. Поэтому все нюансы движка вижу насквозь. И поэтому от всей души повторно рекомендую тебе это >>862783 чтобы и ты видел, насколько в годоте всё просто.
>>863548
>Поэтому рекомендую смотреть видео не по годоту, а общеайтишное.
Все видео для начинающих объясняют только простейший принцип как работает логика программирования. Есть черепашка, и мы пишем команды по которым она дойдёт до выхода. Это знание никак не помогает мне в знании годот, потому что не знаю язык на которым он говорит. Я пытаюсь разговаривать с ним на русском языке, но этот твердолобый желает говорить только на своей тарабарщине.
for x in range(width):
for y in range(height):
set_color(x, y, some_color)
Ничего из этого текста не понял, залез в словарик и нашёл там объяснение
>Для перебора диапазона, например массива или таблицы, используется цикл for. При переборе массива текущий элемент массива сохраняется в переменной цикла. При переборе словаря ключ сохраняется в переменной цикла.
Из него я тоже ничего не понял. Но погуглив я узнал что такое массив.
У меня нет денег на переводчика, который мог бы за меня поговорить с годотом. По этому я пытаюсь снова и снова сделать в нём хоть что ни будь своими силами.
>Рекомендую почитать/посмотреть базу по паттернам
На счёт ролика по паттернам, мне нравится как автор раскрыл в нём идею анимации ожидания. Хотелось бы в своей игре сделать такое же, но сам ролик толком не объясняет что куда писать. Только для новичка информация подана слишком бегло. Не понятно почему часть кода написана в extends FSM_State? Хотя по его же логике весь этот код должен быть написан в одном скрипте персонажа. Возможно анимация идёт как отдельный массив, на который после extends KinematicBody2D будет ссылаться.
>>863548
Забыл скинуть видео по анимации с помощью паттерна. Марио добавил как пример чего хотелось добавить.
https://www.youtube.com/watch?v=UKlnZWaVmC4&ab_channel=%D0%A4%D1%80%D0%BE%D0%BD%D1%82%D0%B5%D0%BD%D0%B4%D0%9F%D0%B0%D1%88%D1%82%D0%B5%D1%82
Я не понимаю, почему так сложно-то, почему нельзя ПРОСТО связать два RigidBody друг с другом, почему нужно мучиться с какими-то там джойнтами? Если б они ещё работали хоть как-то, а то не работают.
Вот предлагают взять KinematicBody вместо RigidBody и всю физику вручную симулировать, а как я буду тело вращать? KinematicBody же не имеет методов для "приложения силы", т.е. его нельзя просто взять и повернуть. Там, наверное, очень сложные формулы для поворота в 3D вокруг произвольной точки пространства. Не хочу опять вспоминать, что такое матрицы...
>Есть черепашка, и мы пишем команды по которым она дойдёт до выхода. Это знание никак не помогает мне в знании годот
Т.е. ты ленишься даже черепашку двигать...
>тарабарщине
>for x in range(width):
>for y in range(height):
>set_color(x, y, some_color)
Это та же самая черепашка:
>Для икс от 0 до ширины и для игрек от 0 до высоты выполнить процедуру с иксом, игреком и цветом.
Ты просто черепашку ленился двигать, вот и не понимаешь теперь тривиальных выражений.
>для новичка информация подана слишком бегло
Потому что новичку нужно черепашку двигать, а не анимации для персонажей. Иди черепашку двигай.
Впрочем... Впрочем, хрен с ними, с машинами. VehicleBody едет и ладно. Слишком многого хочу за раз, так нельзя, нужно ограничивать хотелки.
Простите за флуд, бомбит просто от этих багов.
https://gdquest.itch.io/learn-godot-gdscript
Проходишь это с начала и до конца. Да, нужно двигать черепашку, но тебе тут объясняют как это делать инструментами в годо, так что хавай базу.
>Т.е. ты ленишься даже черепашку двигать...
Я черепаху в школе делал. Помню по заданию нам сказали написать код где черепаха в независимости от точки старта должна была прийти в одно и тоже место. Смог самостоятельно написать этот код без помощи своих одноклассников, но проверив мою работу учитель мне не поверил что её сделал я. В принципе это единственный пример когда у меня самостоятельно получилось написать код.
>и не понимаешь теперь тривиальных выражений.
В той программе было все на русском, тут же с кривым переводчиком бывает не всё понятно.
for x in range(width):
for y in range(height):
Для x в диапазоне (ширина):
Для y в диапазоне (высота):
Как я понимаю эти команды задают размер шейдера по ширине и высоте, правильно? Почему именно шейдера, взял эти строчки из руководства по шейдерам.
>>863631
В первый раз когда я запускал это руководство не мог понять, почему нам показывают эту часть кода, если все скрипты должны быть привязаны к какому либо объекту? Я пытаюсь это повторить в самом годот, но у меня не выходит. Ещё ошибку выдаёт.
Я начинаю подумывать о том, что ты тут траллишь. В школе он видите ли код написал, а в годоте он видите ли не может, потому что годот видите ли на каком-то непонятном языке. Толсто. Вытекай в направлении пошаговых туториалов типа такого https://docs.godotengine.org/en/3.3/getting_started/step_by_step/your_first_game.html или в срачетред. Выбор за тобой.
>В школе он видите ли код написал, а в годоте он видите ли не может
Я не буду объяснять что годот и кумир разные программы, мне не хватит сил доказывать тебе очевидное.
>Я начинаю подумывать о том, что ты тут траллишь
Если ты тот самый который месяц назад надумал себе, что я делаю игру ради госфинансирования... Не удивительно почему тебе удобно называть меня троллем.
До сих пор не понял как нарисовать круг если скрипты привязаны к определенной ноде.
> если скрипты привязаны к определенной ноде.
А какая разница к чему привязаны скрипты? У тебя может быть одна нода - главный экран игры.
>как нарисовать круг
Шейдером
Спрайтом
Текстурой
Line2D
Path2D Curve
Ассетом
func _draw(): draw_circle_arc(..)
Спрайтом легко добавить рисунок на сцену. Я про это говорю.
>Я пытаюсь это повторить в самом годот, но у меня не выходит. Ещё ошибку выдаёт.
У тебя абстрактного мышления вообще нет?
Если ты хочешь узнать API движка - читай документацию. Та программа по ссылке учит основным концепциям программирования, а не API движка.
>кривым переводчиком
А ты не переводи код переводчиком литературных текстов и тогда всё будет понятно. А лучше начни учить английский, без него в айти и геймдеве тяжело.
>Как я понимаю эти команды задают размер
Это циклы со счётчиком:
https://ru.wikipedia.org/wiki/Цикл_(программирование)
Если бы ты действительно двигал черепашку, то ты бы владел такими тривиальными концепциями. Это же просто повторение одного и того же действия N раз.
>>863707
>подумывать о том, что ты тут траллишь
На 99% уверен, что это инфантильный хикка без жизни за пределами компьютера, который остановился в развитии на уровне 10 лет и поэтому так себя ведёт. Скорее всего у него СДВГ, из-за которого он не способен сфокусироваться, бросает обучение, скачет с темы на тему и т.п. Детская упрямость и закостеневший характер не дают ему смириться и согласиться с тем, что он ошибается, и начать работать над собой. Тролль так реалистично не смог бы прикидываться им.
>>863721
>годот и кумир разные программы
>очевидное.
Только ты этого почему-то не понимаешь, и пытаешься писать код из совершенно другой программы в Godot, а потом бомбишь, как видишь сообщение об ошибке (которое тебе лень прочитать и понять).
>>863722
>У тебя может быть одна нода
Можно вообще без нод обойтись, заменив SceneTree своей реализацией MainLoop, а дальше говнокодить в любом стиле без использования нод, но зачем? Это как в том меме с троллейбусом из буханки. Если бы у Godot не было редактора с нодами, то смысла в Godot вроде как и не было бы.
https://docs.godotengine.org/en/stable/classes/class_scenetree.html
https://docs.godotengine.org/en/stable/classes/class_mainloop.html
>>863729
>заработало
А что толку-то? Ты же как в той поговорке про рыбу и удочку. Тебе дают удочку, а ты кричишь как ребёнок, ломаешь удочку и плачешь, что жизнь слишком сложна, а удочкой нельзя поймать единорога в пруду. А если дают уже пойманную рыбу, писаешься от счастья, но ровно до того момента, как у тебя снова начнётся голод, потому что рыбу ловить ты до сих пор не умеешь, и через несколько постов ты снова жалуешься на жизнь...
Думаешь, не надо было ему давать рыбу? Но я сторонник подхода - показывать другим как ловлю рыбу, чтобы они не думали что это что-то сложное или страшное.
Ты ему показал просто решение, он вряд ли понял в чем его ошибка вообще была.
Я даже не уверен что у него там заработало, ошибка пропала, а круг он нарисовать смог? _draw еще вызвать нужно откуда-то.
>круг он нарисовать смог?
У него же на скриншоте есть круг.
>_draw еще вызвать нужно откуда-то.
1. Первый вызов автоматический, когда рендерер в первый раз отображает ноду. Дальше код из _draw как-то там кэшируется и не выполняется.
2. Для повторного вызова нужно запросить update():
https://docs.godotengine.org/en/stable/classes/class_canvasitem.html#class-canvasitem-method-update
>>863740
>показывать другим как ловлю рыбу, чтобы они не думали что это что-то сложное или страшное.
Но ты же не показываешь, как ты формулируешь чёткую задачу, разбиваешь её на шаги, при необходимости гуглишь, читаешь документацию, затем формируешь у себя в голове мысленный образ будущего кода, мысленно его выполняешь на своей мысленной виртуальной машине и убеждаешься, что это именно то, что тебе нужно, и только потом, быстрым, решительным взмахом руки набиваешь код за 3.5 секунды.
А он взял твой готовый код, скопировал его и всё. Он так никогда не научится программировать.
>Думаешь, не надо было
Я понятия не имею, что с ним делать. На системные ошибки в его обучении ему уже несколько раз указывали, он не хочет исправляться...
> уверен, что это инфантильный хикка без жизни
Ну ХЗ, согласно закону По мы не сможем этого определить.
>Я даже не уверен что у него там заработало, ошибка пропала, а круг он нарисовать смог? _draw еще вызвать нужно откуда-то.
Усрись! Когда мне нормально ответили что код можно писать в обычную ноду, и что без func _draw(): код не будет работать.
> _draw еще вызвать нужно откуда-то
Оттуда же, откуда вызываются _ready, _input и т.п.
>У тебя абстрактного мышления вообще нет?
Есть
>Та программа по ссылке учит основным концепциям программирования, а не API движка.
Я смотрю видео ролики, и постепенно пытаюсь вникнуть в API.
>Та программа по ссылке учит основным концепциям программирования
По этому она бесполезна. Пытаясь наглядно повторить код в годот возникают разные ошибки. Это приложение является теорией, которая никак не помогает на практике.
>А ты не переводи код переводчиком литературных текстов и тогда всё будет понятно. А лучше начни учить английский, без него в айти и геймдеве тяжело.
Я не рвусь в геймдев! Мне нужно сделать пару проектов которые засели у меня в подсознаний! Начав изучать английский в программировании я не продвинусь. По быстрому научится английскому невозможно!
Программированию тоже! Но в скрипте можно делать пометки, и кидать уже готовое в другой проект.
>На 99% уверен
Думаешь переход на личности делает тебя очень умным? Я хикка, и моя жизнь за последний год стала полна слезами и нервными срывами. Доволен?
>не дают ему смириться и согласиться с тем, что он ошибается
Я с самого первого сообщения писал тут адекватно, задавал вопросы на которые сам не знал ответа. По твоему я отрицаю что у меня много ошибок?
>начать работать над собой
Мои попытки реализовать себя в создании игры не является работа над собой? Лучше бы пошёл бухать и по помойкам шастать!
>Только ты этого почему-то не понимаешь, и пытаешься писать код из совершенно другой программы в Godot
Это приложение написано как обучающие по годот! Его советуют в треде как обучающие по годот! Почему по твоей логике код из этого приложения должен обязательно противоречить коду годот?
>А что толку-то? Ты же как в той поговорке про рыбу и удочку.
Программирование не рыбалка! Если я захочу рыбу, у меня есть много возможностей заполучить её. От ловли её голыми руками, до попросить у соседей пару кусочков. Я владею своим телом без API, что делает мою жизнь лучше программирования.
>>863740
С кругом была сложность в недосказанности.
>>863769
>А он взял твой готовый код, скопировал его и всё. Он так никогда не научится программировать.
Мне и не нужно знать код на сто процентов! Мне будет достаточно реализации своих простых идей которые у знающего программиста заняли бы 30 минут. Вспоминаем идею про танчик.
> Начав изучать английский в программировании я не продвинусь.
Продвинешься, кроме шуток.
11 лет и дополнительные курсы говорят об обратном. Без языковой среды это бесполезно.
Есть ColorRect, ParallaxBackground и KinematicBody со Sprite2D.
У меня не получается отобразить Parallax над ColorRect'ом, а спрайт игрока между слоёв параллакса. Скрины пропертей на пике.
В первую очередь хотелось бы параллакс пофиксить - даже если я слоям его Z ордер начну с 1 - хуй, колор рект все равно выше
С первым я разобрался. КолорРект надо добавить в свой канваслейер и в пропертях задать ему слой меньше слоя бэкграунда.
Засунуть спрайт игрока между слоев не получилось через З индекс пока
>Я знаю, в идеале треугольники нужно разворачивать в зависимости от расположения вершин, чтобы не было характерных ступенек на резких перепадах высот.
Проверил, HeightMapShape не разворачивает треугольники, поэтому если начать разворачивать, остаётся только обычный тримеш, который будет в точности повторять визуальный меш (чтобы предметы в "текстуры" не проваливались). Жаль... Оставлять эти ступеньки не хочу, выглядят отвратительно в любом стиле графики, потому что они такие только на одной диагонали (на второй диагонали такой же край намного более гладкий/аккуратный, потому что треугольники ориентированы правильно).
У меня вообще сомнения насчет хейтмапа как единственного инструмента. Поскольку он все равно не позволяет делать, скажем, туннели или пещеры, то там все равно должны быть декоративные холмики.
Карта высот предназначена для игр, в которых не нужны туннели и пещеры. Т.е. большинство классических 3D игр, где только поверхность с условными оврагами, холмами и скалами. Преимущество в компактности хранения, относительной простоте генерации и гладкости поверхности.
Хм, ты натолкнул меня на мысль... Я думал, что могу добавить пещеры, просто проделав дырку и вставив в эту дырку ассет "вход в пещеру", а с внутренней стороны расположить несколько "пещерных" туннелей и комнат, которые подгружаются, если игрок входит внутрь. А вот что на счёт туннелей? Мосты я точно собираюсь сделать, а вот о туннелях ни разу не думал. По идее, туннели должны быть частью системы дорог, которая автоматически выравнивает ландшафт под собой, а для туннелей, получается, должна прокалывать дырки...
Ладно, мне бы простую систему дорог сделать. У меня на днях появилась гениальная идея сделать граф дорог по точкам (узлам), которые пользователь расставляет на ландшафте и соединяет линиями. Когда-то я возился в других движках, где есть компонент "дорога" - там было сложно настраивать положение дороги и т.п. А у себя я хочу сделать так, чтобы достаточно было кликнуть в двух местах и сразу получить оптимальный сегмент дороги со всеми стыками, без копания в настройках и дёргания рычагов. Т.е. чтобы реально всё в пару кликов возникало, и потом могло стыковаться с другими тайлами (объединяясь в один общий граф дорог за счёт слияния ближайших узлов).
У дорог есть неприятная особенность, они точно не будут вдоль треугольников хейтмапа, а из-за прибиженности к поверхности, очень быстро начинается z-fighting. Особенно если с высоты птичьего полета.
С некоторым видом скал тоже проблемы
>Я смотрю видео ролики
Пустая трата времени. Большинство роликов:
>хххххрррр, всем здрасти-мордасти, вот я короче решил туториал записать, да, а ещё у моего соседа хомячок родил, вы не поверите, такая умора, ну перейдём к туториалу: открываем годот, создаём сцену, кстати, вот реклама на две минуты крема от простатита "мокрая сцена", ну, продолжим, дальше, хм, ну, вот так, допустим, тык, пык, пук, а потом ххххррррррррччпок, простите, что-то микрофон барахлит, ну вот как-то так, вооооот, дааааа, а ещё можно вот так, но я это объяснять не буду, короче дальше нужно ещё кое-что, ждите вторую часть, подписывайтесь, ставьте лайки, чмок в пупок, до скорого... (видео выложено два года назад и второй части так и не вышло, в комментариях на просьбы помочь с ошибками ни одного ответа, кое-кто из олдфагов говорит, что код в видео говно, но почему - не объясняет)
Пойми, "обучающие" ролики создаются не для того, чтобы тебя чему-то научить, а для того, чтобы автор получил прибыль с рекламы, кликов, подписок, мерча и т.п., или просто чтобы потешить эго автора. Реально полезные обучающие видео встречаются редко. Главное, что обучающие ролики записывают чаще всего те, кто сами толком не разбираются, потому что если бы разбирались, были бы заняты производством контента, а не созданием себе лишних конкурентов; при этом те, кто реально разбирается и хочет чему-то научить, чаще всего не умеет учить и не умеет записывать внятное видео. Поэтому обучение через видео - это своего рода мем с очень негативным смыслом. В теории, да, некоторые вещи (вроде 3D моделирования, рисования) лучше показать, чем описать словами, но на практике видео редко бывает полезным, особенно на тему программирования.
>теорией, которая никак не помогает на практике
Она тебе не помогает, потому что ты не пытаешься её усвоить, скачешь с темы на тему и пропускаешь важное, пытаясь сразу сделать то, для чего у тебя просто не хватает знаний. А потом винишь окружающих в своих ошибках, которые упорно не хочешь признавать.
>Мне будет достаточно реализации своих простых идей
>Мне нужно сделать пару проектов которые засели у меня в подсознаний!
Какими бы твои цели ни были, ты не можешь просто сделать их, не овладев необходимыми знаниями и навыками. Геймдев - это сложно. Это играть в игры легко, а делать их очень сложно. И разработчики прикладывают массу усилий, чтобы в игры было легко играть... А ты хочешь играючи сделать свои "пару проектов", ничего не изучая и не вырабатывая навыки. Так у тебя не получится ничего, пока не создадут ИИ, делающий игры вместо человека по простому описанию на естественном языке (такого ещё несколько лет ждать, как минимум).
>Начав изучать английский в программировании я не продвинусь. По быстрому научится английскому невозможно!
Технический английский осваивается чтением руководств с помощью англо-русского словаря. Я так английский и выучил: сначала программирование через русскоязычные книги, потом кое-как английский по англоязычным руководствам к тому, что на русском не объясняют (или объясняют плохо). Сейчас могу читать на английском и даже кое-как объясняться в тексте (чтоб понимали, что я сказать хочу), хотя некоторые слова всё ещё смотрю в словарях. Я не учил английский специально, мне это никогда не нравилось и не хотелось, а в школе мне ставили "3" за пассивное присутствие на уроке. Так что не всё так плохо, как тебе кажется.
>Программированию тоже!
Базовое программирование осваивается не дольше месяца, если по вечерам лениво почитывать книгу и делать примеры из каждой главы на практике. Это важно - закреплять теорию практикой, но важнее всего делать именно то, что сказано в книге, и учиться строго последовательно, не перескакивая главы. Но ты этим, конечно, заниматься не будешь, и вместо этого продолжишь жаловаться, что у тебя ничего не получается...
>Я хикка, и моя жизнь за последний год стала полна слезами и нервными срывами.
Я тоже хикка и испытываю депрессивные эпизоды уже много лет, частые мысли о суициде и т.д. Это не оправдывает твоё поведение. Часть твоих проблем ты мог бы решить, если бы прислушивался к тому, что тебе говорят, осознавал и не повторял свои ошибки.
>По твоему я отрицаю что у меня много ошибок?
Конечно, отрицаешь, раз тебе указывают на ошибку, а ты начинаешь психовать и ругаться, а потом снова делаешь эту ошибку, как будто назло нам.
>Это приложение написано как обучающие по годот!
Оно обучает основам GDScript (если последовательно изучать, как задумано авторами), но не предназначено для буквальной копипасты. Копипаста в программировании вообще наносит больше всего вреда, особенно если ты копируешь что-то, не понимая, как оно работает, но даже понятный код после копирования может причинить вред. Этим ты вредишь в первую очередь сам себе, но новички обычно не осознают масштабы вреда. Если не бросишь свои начинания, спустя несколько лет до тебя дойдёт, как сильно ты заблуждался, но лучше бы ты понял это раньше.
Но в чём-то ты прав, Godot необходима встроенная обучающая система для абсолютных новичков, подобная обучающей системе Unity (что-то там со словом "микро" в названии, не помню уже), где ты последовательно играешь с готовыми ассетами внутри движка и таким образом обучаешься многим прикладным вещам конкретно в данном игровом движке. Возможно, что-то такое сделают после релиза 4.0, для тройки это сейчас делать уже бессмысленно, API сильно поменялось.
>Лучше бы пошёл бухать и по помойкам шастать!
>От ловли её голыми руками, до попросить у соседей пару кусочков.
Ага, то есть ИРЛ ты предпочитаешь жить прилично, а вот побираться по техническим форумам, выпрашивая кусочки тухлого говнокода, который ты скопипастишь - это совершенно нормально?
>Мои попытки реализовать себя в создании игры не является работа над собой?
Нет, не является. Ты же повторяешь свои ошибки, которые наверняка повторял в других сферах: пытаешься с наскока сделать то, на что у других людей уходят годы последовательного обучения и практики, и не слушаешь тех, кто уже прошёл по твоим граблям и набил шишек. А потом жалуешься, что у тебя не получается, и что кто-то или что-то виновато в твоих неудачах. Твоя игра не изменит тебя в лучшую сторону, а твоё нытьё здесь демонстрирует твоё нежелание меняться.
>Я владею своим телом без API, что делает мою жизнь лучше программирования
Если уж так рассматривать, то у человеческого тела тоже есть "API", но для сознания такие технические детали недоступны (как недоступен программе её собственный код... в большинстве случаев), и, в результате привыкания, управление своим телом нам кажется очень простым и естественным, хотя это совсем не так (робототехника это подтвердила, сложнее всего ходьба двумя ногами, мозг на это очень много вычислительных мощностей отводит, хотя мы этого вообще никак не ощущаем). Нервная система вообще состоит из множества костылей и неудачных решений, и если бы мы могли, давно бы переделали хотя бы некоторые самые неудачные компоненты, но из-за привыкания ты как-то особо и не замечаешь этих костылей.
А ещё свойства мозга таковы, что когда ты чем-то очень хорошо владеешь, ты начинаешь пользоваться этим так же естественно, как и своим собственным телом - т.е. инструмент в руках опытного человека становится как бы продолжением тела, и виртуальные инструменты не исключение. Как велосипедист просто едет, не думая о педалях, рулении и балансировании, так и опытный программист создаёт сложные системы, не задумываясь о ставших естественными ему операциях. Но до такого мастерства тебе, конечно, далеко, и из-за своей упрямости ты будешь идти к этому дольше, чем мог бы.
И кстати, это хорошо объясняет, почему опытные специалисты плохи в обучении новичков - то, что для новичка тёмный лес, для специалиста так же легко и естественно, как управление своим телом. В том числе поэтому мало качественных обучающих материалов, чтобы и учили полезному, и объясняли доступно.
>ролики создаются не для того, чтобы тебя чему-то научить, а для того, чтобы автор получил прибыль с рекламы, кликов, подписок, мерча и т.п.
Анончик, тебе бы немножечко веры в человечество. А то ты сидишь в треде опенсурсного движка, но не веришь, что некоторым нравится просто делать добро и бросать его в воду. Какая может быть прибыль с рекламы, если видосы набирают в лучшем случае 1.5К просмотров? Ну да, есть пара каналов, где просмотров чуть побольше, но и они монетизируются скорее донатами, чем рекламой.
Чел, это Годот. Он не такой популярный, как Анрил или Юнити. У тех-то тоже не то чтобы огромные просмотры, потому что тема ну очень узко специализированная. А тут так вообще. Практически все, кто пилит видео-туторы по Годоту, делают это на чистом энтузиазме, ради социалайза, лайков и фор зе грейтер гуд.
А ещё огромное число людей донатит. И ещё присылают правки в опенсурсные софтины. И помогают новичкам на форумах и в чатах. И строчат тонны текста, пытаясь вразумить невразумляемых анонимусов на дваче. Помогают бездомным. Волонтёрят. Это всё части одного общего процесса, когда люди пытаются совершенно безвозмездно принести пользу. И максимум, на что они рассчитывают взамен, это лайки в той или иной форме, какая-то эмоциональная благодарность от тех, кому они помогли.
Так что не сгущай краски. Большинство роликов пилят такие же, как мы с тобой, просто они предпочитают не на дваче вправлять мозги отдельным анонам, а на ютубе делиться своими знаниями и опытом со всеми сразу.
>при этом те, кто реально разбирается и хочет чему-то научить, чаще всего не умеет учить и не умеет записывать внятное видео
Ну тут соглы отчасти. С другой стороны, чтобы делать видосы для новичков, не нужно быть прям хардкорным специалистом. А инди-геймдев это всегда человек-комбайн, которому не влом и видеоредактор освоить.
А по остальному тексту у меня не бомбит, там база.
Чет все меньше всего на картинке остается, намек на уход в закат?
Всё лучше пикрила.
Завидую, у меня могла бы быть лучше графика, но моя игра вряд ли когда-нибудь попадёт в новости движка...
суть такова, чтобы был внешний файл скрипта, только в нем нужно будет хранить не целый стандартный gd-скрипт, а как бы внутренность для вызываемой функции, т.е. в коде самой программы будет fn(): <сюда_загрузить_код_из_файла>
1. Почему удалили из документации?
2. Ваше мнение о подходе из статьи?
3. Как бы вы его предложили улучшить?
Я думаю, метод неплох, если требуется реализовать его только для одной сущности или максимум десятка сущностей. Потому что из моего опыта, частое удаление и добавление нод в дереве сцены сильно бьёт по производительности. Также я бы хранил созданные состояния в массиве и использовал remove_child() вместо queue_free(), т.к. это должно быть быстрее.
Но вообще, мне не нравится добавлять в рантайме ноды, которые никак не задействованы в редакторе. Ноды предназначены в первую очередь для визуального редактирования сцен через редактор, в рантайме от них толку мало. Так что я бы лучше реализовал это всё через пачку Resource или вообще Reference, чтобы не теребить дерево сцены.
Собственно, понятно, почему удалили из документации, подход очень сомнительный для проектов больше хеллоу ворлда и может оказать негативное влияние на восприятие движка ньюфагами.
Я не понимаю, зачем ты смешиваешь Control и Node2D ноды в иерархии. Control предназначены только для составления интерфейсов, которые, обычно, всегда на экране и большую часть времени неподвижны. У них много настроек, но все они касаются исключительно построения интерфейсов и непригодны в большинстве 2D игр. Node2D, напротив, оптимизированы для отображения чего-то в условно бесконечном двухмерном пространстве, которое может двигаться, крутиться и масштабироваться независимо от состояния интерфейса. У этих нод нет настроек, связанных с интерфейсами, но зато нет и ограничений интерфейсных нод. Связывать их между собой возможно, но нежелательно: Node2D ноды как минимум не могут органично встраиваться в интерфейс, а Control ноды как минимум имеют много лишнего в своём коде. То, что их можно совмещать, лишь следствие их родства через CanvasItem.
В твоём случае вместо TextureRect следует использовать Sprite, а его размер относительно экрана настраивать вручную, если тебе это нужно.
На счёт сортировки... Я не знаю точно, в чём твоя проблема, но важно помнить, что элементы сцены рендерятся сверху вниз по дереву и параметр Z относителен, т.е. если ты хочешь поместить спрайт позади двух предыдущих сцен, то ты должен ввести в Z отрицательное значение. Кроме того, я сомневаюсь, что тебе нужно менять Z у слоёв параллакса, т.к. они и без того последовательно друг за другом идут.
Сейчас попробую сцену накидать у себя...
>внешний файл скрипта, только в нем нужно будет хранить не целый стандартный gd-скрипт, а как бы внутренность для вызываемой функции, т.е. в коде самой программы будет fn(): <сюда_загрузить_код_из_файла>
https://docs.godotengine.org/en/stable/classes/class_script.html
Сам не делал, пишу примерно, может не работать:
>var script: Script = load(file_path)
>if script:
>_ script.source_code = "extends Reference; func fn() -> void: %s" % [script.source_code] # оборачиваем полученный код заранее заготовленной обёрткой
>_ var err := script.reload() # в случае с GDScript здесь, по всей видимости, будет попытка сформировать байт-код для виртуальной машины, ошибка - синтаксическая проблема в исходном коде скрипта
>_ if err == OK:
>_ _ var object: Reference = script.new()
>_ _ object.fn()
Если так не получится, тогда считывай код как строку из текстового файла и добавляй в чистый Script. Также можешь повесить этот script на Reference:
>var object := Reference.new()
>object.set_script(script)
>object.fn()
1 пик - дерево худа
2 пик - нажимаю пкм на игроке - все работает
3 пик - скрипт ui.gd из ready все вызывается
в скрипте оружия
[code]
func _ready():
print("gun ready") # не вызывается
mag_ammo = mag_size # в инспекторе все норм
G.ui.update_ammo(mag_ammo, mag_size) # не работает
[/code]
скрипт оружия
>Сейчас попробую сцену накидать у себя...
Попробовал.
>>864018
>ParallaxBackground
>спрайт игрока между слоёв параллакса
ParallaxBackground является потомком CanvasLayer. Механизм слоёв устроен так, что движок по порядку обходит все слои, а уже внутри слоя производится сортировка по Z-индексу.
Другими словами, используя ParallaxBackground, ты изолируешь часть сцены на отдельном "слое", в который нельзя пробраться изменением Z-индекса снаружи этого слоя (по умолчанию сцена находится в слое 0).
На первый взгляд кажется, что можно просто закинуть персонажа игрока внутрь ParallaxBackground, и тогда, действительно, Z-индекс будет менять положение игрока относительно слоёв фона. Но в таком случае нарушается поведение Camera2D, прикреплённой к персонажу.
Так что я бы на твоём месте просто реализовал свой собственный параллакс из Node2D нод и спрайтов. Очевидно, что встроенный параллакс рассчитан на классическое применение, когда персонаж не может проникать между слоями фона, а у тебя игра, видимо, предполагает совершенно другое использование.
>у оружия при спавне не срабатывает _ready()
Откуда нам знать, как ты своё оружие спавнишь?
Метод _ready() вызывается единственный раз при первом добавлении ноды в дерево сцены. Если он не вызывается, то ты, скорее всего, забываешь добавить ноду в дерево сцены. По идее, он вызывается сразу после add_child(), т.е. к следующей строчке твоей функции спавна оружие уже находится в сцене и отработало свой _ready().
Пока у тебя ошибка где-то в функции спавна, разбираться в остальном коде бесполезно.
А вот с рисованием траблы
Приятный геймплей >> сложная графика.
Графика помогает с первоначальными продажами, пока отзывов на игру нет и люди оценивают потенциальное качество игры только по скриншотам, но если игра соберёт достаточно фанатов, то дальше в неё будут играть даже с примитивной графикой благодаря обзорам и рекомендациям. Если у тебя есть способ раскрутки без графики или твоя ЦА ценит игры больше за геймплей, чем за графику (и поэтому готова оценивать ноунейм игры с плохой графикой), то не парься о том, что не умеешь рисовать как какой-то 300к/сек художник.
Но, конечно, совсем уж плохая графика будет тянуть игру на дно, так что хотя бы постарайся не размещать вплотную друг к другу #FF0000 и #00FF00, лол.
так в том и суть, что если его не добавить в дерево сцены, то оно и не отобразится в игре, добавляется оно на сцену игрока, но рэди не вызывается
>вменяемыми картинками
2D или 3D? Реализм или мультик?
>>865092
>gun_key.scene
Сделай print() этой строки и потом открой соответствующий ей файл в редакторе. Проверь, какой именно скрипт связан с нодами. Может быть, у тебя там случайно скрипт неправильный сохранился (предыдущая версия и т.п.). Также попробуй перезапустить редактор через меню "Project > Reload...", обычно это исправляет редко встречающиеся ошибки редактора, когда он отображает не то, что есть на самом деле. У меня несколько раз было такое со скриптами, когда я переименовывал или перемещал несколько файлов.
>Проверь, какой именно скрипт связан с нодами. Может быть, у тебя >там случайно скрипт неправильный сохранился (предыдущая версия >и т.п.).
Спасибо тебе, добрый человек, почему то на производных от класса ган у меня скрипт не менялся
У тебя с логикой проблема. Ты при включении анимации проверяешь, не воспроизводится ли она уже, чтобы не сбрасывать её состояние. Одновременно с этим ты устанавливаешь направление спрайта влево/вправо. Но при движении влево и вправо у тебя одна и та же анимация с именем "run", поэтому происходит следующее:
1. Игрок не двигается, анимация steady.
2. Игрок двигается вправо, анимация run.
3. Игрок резко, без остановки начинает двигаться влево, что тоже анимация run, но эта анимация уже воспроизводится и твоя функция ничего не делает, в том числе не меняет положение спрайта.
4. Если игрок остановится и после остановки пойдёт налево, то будет последовательность run > steady > run, и твоя функция установит правильное направление спрайта.
Быстрое решение - сместить конструкцию с установкой scale.x на один таб влево (кстати, у тебя там пробелы вперемешку с табами, ещё и в конце строк зачем-то пробелы валяются, чисти, чтоб аккуратно было, стиль кода важен в долгосрочных проектах), чтобы она выполнялась всегда, даже когда анимация не меняется.
Но, имхо, тут нужно какое-то более системное решение, поскольку ты ведь будешь больше анимаций добавлять и неизвестно, во что это выльется потом.
По-хорошему, нужно использовать AnimationTree с его конечным автоматом, там есть функция travel(), которая автоматически следит за порядком анимаций, даже если их очень много.
>в конце строк зачем-то пробелы валяются
Я имел в виду табы. Они на скриншоте отмечены серой стрелочкой. Хотя не, редактор вроде удаляет все лишние табы в процессе сохранения скрипта, просто на скриншоте файл не сохранён. Ошибся.
Короче, лучше вот это использовать:
https://docs.godotengine.org/en/stable/tutorials/animation/animation_tree.html#state-machine-travel
>>865203
>Но при движении влево и вправо у тебя одна и та же анимация
Спасибо, создал копию анимации и теперь запускаю её когда персонаж идет в другую сторону, больше лунной походки нет.
AnimationTree работает с DragonBones? Выглядит довольно заморочено, я честно говоря как запустить эти анимации еле разобрался с помощью ChatGPT, уроки от автора расширения просто ужасные, если ты новичок то вообще не понятно как привязать анимации к кнопкам хотя бы, хотя сейчас кажется все просто когда сделал, вообще я прохожу урок по созданию платформера и решил заодно разобраться как анимации из DargonBones запускать чтобы графон как у Vanillaware прикрутить, уже пожалел 10 раз.
не лучше ли сделать:
move_direction.x = Input.get_axis("left", "right")
if move_direction.x:
_play_move_animation(move_direction, "run")
else:
_play_move_animation(gravity, "steady")
сделать переменную для драгонбонса:
var scale_multiplier = 0.25
dragonbones.scale.x = sign(move_direction.x) * scale_multiplier
как минимум читабельнее будет и виднее где могут быть ошибки, мне кажется дело в if elif
>AnimationTree работает с DragonBones?
Понятия не имею, ты DragonBones через какой-то плагин подключил? Вообще, система анимации в Godot очень развита и может анимировать практически что угодно в движке, вроде бы любые доступные тебе обычным образом свойства можно менять с помощью анимаций. Есть скелетная анимация для 2D, не понимаю, зачем тебе пришлось подключать DragonBones.
>еле разобрался с помощью ChatGPT
Лол, что? ChatGPT выдумывает лишнее, льёт много воды, в результате ответ может быть неправильным, но выглядеть как правильный, а сама нейронка не обучена говорить "прости, я не знаю" или "я не уверена, что это правильно", т.е. несёт бред с полной уверенностью что всё так и есть. Из-за этого, имхо, лучше не использовать для изучения инструментов, особенно малоизвестных в интернете (т.к. этой нейронке для обучения нужна куча примеров в текстовой форме, в которых уже решены все проблемы, с которыми ты столкнулся, особенно если речь идёт о чём-то визуальном).
>>865262
>if move_direction.x:
>_play_move_animation(move_direction, "run")
Без изменения кода внутри _play_move_animation() будет точно такое же поведение, потому что у тебя +1 резко меняется на -1 и происходит постоянный вызов "run" без переключения на "steady".
Input.get_axis() с клавиатуры будет выдавать 1, 0 или -1, но при быстром нажатии кнопок 0 может не появляться. На геймпаде другое дело, но, я думаю, на нём тоже можно резко стик перекинуть на другую сторону, проскочив 0.
>Без изменения кода внутри _play_move_animation() будет точно >такое же поведение, потому что у тебя +1 резко меняется на -1 и >происходит постоянный вызов "run" без переключения на "steady".
так скейл драгонбонса вообще нужно вынести из метода анимации либо в процесс, либо в отдельный метод, так чтобы он менялся только когда move_direction.x != 0
>Input.get_axis() с клавиатуры будет выдавать 1, 0 или -1
это все равно лучше, чем проверять ввод через if elif, как минимум запись короче и читабельнее
> еле разобрался с помощью ChatGPT
>не лучше ли сделать
возможно, могу на слово поверить, я если что на прошлой неделе godot скачал, до этого тыкался в гейм мейкер, но у меня от него жопа сгорела потому что я туда никакими костылями не смог прикрутить костную анимацию, а за спайн надо бабки платить только такой вариант.
>Лол, что? ChatGPT выдумывает лишнее, льёт много воды, в результате ответ может быть неправильным, но выглядеть как правильный.
Да пришлось сильно постараться, но он мне в итоге вроде как помог, а больше и некому было, потому что видимо это либо не интересная тема для годотеров и все пилят пиксельарт, либо по умолчанию считается что любой кто вкатывается 200iq мегамозг и сам разберется что там как, спойлер -нет.
>Понятия не имею, ты DragonBones через какой-то плагин подключил?
Отдельная сборка Godot сразу с ним есть, но документации нормальной нету, только несколько видосов от автора после которых не сильно то понятно что делать.
Промахнулся, сори что засрал тред, всем спасибо, за помощь.
>это все равно лучше, чем проверять ввод через if elif, как минимум запись короче и читабельнее
Речь шла о том, что ты проблему не решил. Не важно, как считываются клавиши, проблема не в них.
>>865289
>на прошлой неделе godot скачал
Официальную документацию читай, чтобы не изобретать велосипеды на каждом шагу.
>не интересная тема для годотеров
Ещё раз: встроенная система анимации хорошо работает для 2D, 3D и даже GUI, что-то внешнее особо не нужно. DragonBones может быть полезен для движков без собственного редактора анимаций, либо для движков с упрощённой анимацией. Аддон с поддержкой для Godot скорее всего для тех, кому по привычке удобнее DragonBones или необходимо портировать анимации, которые уже давно были сделаны в нём (при переводе существующей игры на другой движок).
Хотя я не знаю, не пробовал этот DragonBones, вполне возможно, там есть какие-то киллерфичи. Но раз никто его особо не обсуждает в Godot сообществах, то эти фичи либо не такие уж нужные, либо уже есть в Godot, либо можно сымитировать средствами Godot.
Аналогичная ситуация с Tiled. Существует плагин для загрузки тайловых карт из Tiled в Godot. Но зачем? Да, разумеется, редактор Tiled имеет больше функций, но ты можешь делать достаточно сложные тайловые карты из Godot встроенными средствами (TileMap). Так что мне кажется, тут такая же ситуация: ты услышал, что существует плагин DragonBones для Godot, и сразу решил его использовать, не разобравшись, что можно обойтись встроенными средствами, которые хорошо объяснены в официальной документации и куче туториалов.
>Существует плагин для загрузки тайловых карт из Tiled в Godot. Но зачем?
Потому что встроеный редактор ссанина полнейшая
>>864744
>У дорог начинается z-fighting
Год назад я пытался располагать процедурные дороги на зайчаточной карте высот, и никаких артефактов не было. Тот раз я не смог создать пересечения дорог, расстроился и вернулся к генерации тайлами...
Клепают уже через день.
>считывать в таком виде
Как текст не получится, т.к. движок поддерживает только UTF-8 (что-то другое сегодня уже не нужно) и ты скорее всего получишь мусор вместо кириллицы. Ты можешь попробовать читать отдельные байты и переводить их в юникод вручную, ориентируясь по таблице символов:
https://en.wikipedia.org/wiki/Windows-1251
Либо найти/создать консольную утилиту, которая считывает заданный файл в cp1251 и возвращает UTF-8 строку, раз не хочешь забираться во внутренности движка.
Чтение отдельными байтами:
https://docs.godotengine.org/en/stable/classes/class_file.html#class-file-method-get-8
Строку можно конструировать из набора байтов, если ты в них вручную нужные UTF-8 значения запишешь. Либо попробуй декодировать из строки в URL-формате (кодировка через проценты, часто вижу в интернете кириллицу в таком формате, так что должно сработать):
https://docs.godotengine.org/en/stable/classes/class_string.html#class-string-method-http-unescape
https://en.wikipedia.org/wiki/URL_encoding
Запуск внешних программ:
https://docs.godotengine.org/en/stable/classes/class_os.html#class-os-method-execute
Позволяет получить результат, выводящийся запущенной программой в консоль.
ну вот и думаю, что только вариант через get_file_as_bytes и там табличку накидать перевода, ладно, так и сделаю, видимо
Я думаю, будет проще накидать скрипт на питоне или любом другом языке, который может работать через консоль и имеет встроенные средства для работы с разными кодировками. А потом вызывать этот скрипт через командную строку OS.execute().
Или тебе обязательно на GDScript нужно?
вот уж питон еще тянуть...
да я графическое приложение для работы сделал вот, чтобы старые базы данные текстовые и параметрические всякие, которые хранились в упаси боже windows1251, вывести красиво с UI и работать удобно было бы
просто написал перевод файла при загрузке в utf-8 и работаю дальше в обычном режиме, сохранять не придется, но если понадобится, то тоже уже все готово, теперь можно к украшательству приступить
>приложение для работы
>старые базы банных
>вывести красиво
>к украшательству приступить
Хорошая работа и базы данных интересные...
Забыл написать: выяснил, что если загружать карту высот в шейдер как текстуру, то и разрешение текстуры, и количество подразделений меша весьма незначительно влияют на результат, по крайней мере внешне. Если у текстуры включена фильтрация, то ландшафт сглаживается и становится намного привлекательнее, чем если вручную дёргать отдельные вершины. То есть текстуры 64х64 пикселей более чем достаточно для того, что я пытался сделать, двигая вершины сетки 128х128 и получая некрасивые изломы. Кроме того, с текстурой появляется возможность легко менять масштаб по высоте, но какого-то интересного применения этому я пока не придумал. Только всё это многообразие возможных решений сбивает с толку, и я уже запутался, что я хочу сделать-то, лол...
Интересное обсуждение в тему процедурных миров:
https://www.reddit.com/r/gamedesign/comments/10e975b/
После чтения комментариев мне теперь хочется снова попробовать процедурную генерацию всей карты сразу, но с отображением через сглаженную карту высот, а не заготовленными заранее тайлами; особенно привлекла идея из одного комментария - моделировать течение воды, чтобы реки образовывались естественным путём (в общем-то это несложно, особенно для клеточного автомата, который у меня уже давно есть). Вообще-то я мог бы использовать один из старых генераторов, нужно только конвертировать данные в текстуру и получится визуализация без всего того сложного кода, из-за которого я забил на генерацию тайлами (там каждый тайл приходилось вертеть и выбирать в зависимости от соседей, это сложно и очень плохо масштабируется, а тайлов мне хотелось как можно больше).
Что ж, разработка игры снова откладывается))))
Что лучше - статический класс (ну типа синглтон) и стандартные шарповые ивенты
или
годотовский автолоад и его сигналы?
Сделал потестить на статическом классе, пока все ок, только отписываться не забывать надо. Или всё-таки автолоад?..
>до-диез
Мне кажется, в этом треде большинство на GDScript программирует. Но могу предложить, что чем меньше лишних запросов к API движка, тем лучше?
Или mono встроено в exe-файл Godot?
>По-хорошему, нужно использовать AnimationTree
Удалось запустить эту штуку с DragonBones, выглядит круто, отличный совет, осталось привязать к коду это дело.
Если у меня несколько типов пуль (т.е. для каждого типа пуль свой класс от абстрактного) - пул должен быть общий или по пулу для каждого типа?
Если общий, то я не очень представляю пока как, если пул надо инстанцировать...
что делать, в лохматых кто-то так решил, что будут так хранить данные
платят много и ладно
Хули ты мне отвечаешь, ебанат малолетний, с чатгэпете общающийся? Иди нахуй и там кончись, опущ.
Дрочую.
Так же и Зиланн как ты однажды сказал и запилил свой код. А потом отдал его людям.
В первую очередь должен сказать: не занимайся преждевременной оптимизацией. От того, что ты выиграешь 1 мс на стрельбе, разработка игры дальше не продвинется. Поэтому сначала сделай самый простой вариант, с созданием и уничтожением пуль, и измерь производительность игры. Если она достаточна (стабильные 60 кадров в секунду), то занимайся другими, более важными для игры системами, а оптимизацию оставь на потом. Когда займёшься оптимизацией, тебе нужен будет этот простой вариант для сравнительных тестов, чтобы понимать, действительно ли твои оптимизации делают то, что ты от них ожидаешь, или это пустая трата времени. В контексте пуль серьёзная оптимизация требуется в буллетхеллах, где на экране тысячи снарядов и от игрока требуется быстрая реакция. А если у тебя какой-то неспешный симулятор охотника и в худшем случае на экране будет всего несколько пуль, вряд ли тебе нужна оптимизация, по крайней мере на ранних этапах разработки.
Отвечая на твой вопрос, если у тебя в пуле всё будет вперемешку, то ты будешь тратить время на поиск объекта нужного типа, что снизит эффективность пула (а то и вовсе сделает его хуже простого решения - нужно проверять, сравнивать). Тебе даже не нужно иметь один общий пул на все пули одного типа, можно заранее создать пули для всего, что может стрелять, ровно в том количестве, которое этот объект способен выстрелить, и расположить внутри этого стреляющего объекта (всё равно в памяти ООП объекты разбросаны хаотично, а в массиве хранятся только ссылки на эти объекты; можно оптимизировать расположение данных в памяти, но это отдельная тема). Если у игрока всего 30 пуль в магазине, тебе нет смысла иметь больше 30 пуль в связанном с ним пуле, а искать 30 свободных пуль в общем пуле из 1000 пуль одного типа для всех возможных юнитов в игре будет, возможно, так же неэффективно, как создавать пули по мере стрельбы, если не хуже. Ты же, похоже, хочешь не просто 1000 пуль на всех, а 1000 пуль разных типов на всех, т.е. ещё больше проверок (нужного ли типа и доступна ли для стрельбы).
Я вижу пул как один магазин с патронами, только пули магически возвращаются обратно в магазин по мере попадания в цели или выхода за пределы эффективной дальности, после чего снова доступны для стрельбы - магазин менять не нужно. Если нужны другие пули - меняешь магазин на другой. Если игрок может вставлять в магазин пули разных типов, то заполняешь магазин заранее созданными пулями в том же порядке, в котором делает это игрок (что логично), чтобы стрельба была простой последовательной операцией, и по после того, как пули в магазине закончатся, заменяешь этот магазин на тот, который игрок выберет следующим.
Также тебе не нужно сразу создавать все тысячи пуль всех типов. Ты можешь растянуть создание пуль так, чтобы они создавались заранее, но всё же не так быстро, как выстреливаются каким-нибудь боссом или пулемётом в руках игрока. Т.к. мы страдаем от скорости выделения памяти под новый объект, одновременное создание множества запасных пуль вызовет ощутимую задержку. Поэтому, если у тебя спавнится моб со скорострельным оружием и большим магазином, но не сразу начинает стрелять, разумно будет медленно наполнять его магазин, пока он не решит стрелять подготовленными нами пулями. Аналогично если игрок нашёл в рандомном луте пулемёт, но ещё не начал его использовать. Как видишь, ситуационное решение, которое нужно проверять и применять только если оно действительно необходимо конкретной игре.
Также не забывай, что твоя система должна быть достаточно надёжной, ведь если кратковременные тормоза можно перетерпеть, то баги и глюки могут вообще сломать игровой процесс и наверняка испортят игроку впечатление от игры, тогда как тормоза многие привыкли терпеть. Так что лучше пожертвовать производительностью, чем вероятностью случайно начать стрелять чем-то неподходящим или вовсе выпасть на рабочий стол из-за какого-нибудь деления на ноль.
Понел. Ну я делаю а ля буллетхелл, потестил оптимизацию без пула и с ним - фпс на большом количестве в разы отличается в итоге.
Сделаю тогда по пулу на каждый тип, их всё равно не так много
Да емае, я даже не успеваю некоторые запустить, как пора заменять.
Ну хорошо в этот раз хотя бы каких то вампирчиксурвайвалов поставили, на игру похоже.
Правда в ней спрайты не очень пиксель перфект получились, ну так это так и должно быть наверное, раз раз и в продакшн.
>Пустая трата времени. Большинство роликов:
https://www.youtube.com/watch?v=VeCrE-ge8xM&list=PLda3VoSoc_TSBBOBYwcmlamF1UrjVtccZ&ab_channel=BornCG
>чтобы автор получил прибыль с рекламы, кликов, подписок, мерча и т.п., или просто чтобы потешить эго автора
Годот слишком маленький по сравнению с другими движками, и нормально заработать на создании туториалов у человека вряд ли выйдет! Единственные кто будут делать туториалы это искренние энтузиасты.
>скачешь с темы на тему и пропускаешь важное
Я скачу с темы на тему по причине выбора более легкой реализации. Мне в другом треде сказали что в годот легко создать кликер, как оказалось нужную мне механику кликов по врагам сделать хрен получиться. Пытался на renpy с советами знакомого программиста реализовать тоже самое. Но даже его написанный код не смог заработать! Ты говоришь что я прыгаюсь с темы на тему, но срок у каждого прыжка несколько месяцев.
>Технический английский осваивается чтением руководств с помощью англо-русского словаря. Я так английский и выучил: сначала программирование через русскоязычные книги, потом кое-как английский по англоязычным руководствам к тому, что на русском не объясняют (или объясняют плохо). Сейчас могу читать на английском и даже кое-как объясняться в тексте (чтоб понимали, что я сказать хочу), хотя некоторые слова всё ещё смотрю в словарях. Я не учил английский специально, мне это никогда не нравилось и не хотелось, а в школе мне ставили "3" за пассивное присутствие на уроке. Так что не всё так плохо, как тебе кажется.
По личному опыту, смотря на людей со схожей проблемой, могу сказать только одно... Есть люди которые неспособны учиться иностранным языкам. У тебя не было взгляда со стороны, где пол класса читал книгу по слогам, в шестнадцати летнем возрасте. Проще поверить в такое если у человека есть справка с аутизмом, или по лицу виден синдром дауна. В иных случаях почему-то принято считать человека способного хоть завтра в космос полететь!
>Базовое программирование осваивается не дольше месяца.
Как я уже и сказал, это чисто твой опыт. Который ты стараешься проецировать на всех.
>Я тоже хикка и испытываю депрессивные эпизоды уже много лет, частые мысли о суициде и т.д. Это не оправдывает твоё поведение. Часть твоих проблем ты мог бы решить, если бы прислушивался к тому, что тебе говорят, осознавал и не повторял свои ошибки.
Я не переходил на личности, и не пытался никого задеть.
>и не повторял свои ошибки
Для тебя мои ошибки что я признавая что не могу сделать игру за день, не сделал готовую игру за день.
>Конечно, отрицаешь, раз тебе указывают на ошибку, а ты начинаешь психовать и ругаться, а потом снова делаешь эту ошибку, как будто назло нам.
Психовать начал только в случае где анон тему разговора перевёл с темы движка и игр, на свои странные выдумки. Что никого не слушаю... Я бросил попытки сделать кликер, и место этого сделал обычного 2d персонажа, который перемещается на wasd. Вместо простой по геймплею игры похожую на флешку, будет короткая игра в стиле undertale.
>Ага, то есть ИРЛ ты предпочитаешь жить прилично, а вот побираться по техническим форумам, выпрашивая кусочки тухлого говнокода, который ты скопипастишь - это совершенно нормально?
Сколько ещё раз мне писать что с начало я пытался найти ответ в гугл, после у друга программиста, после в самую последнею очередь тут. Сколько ещё раз мне об этом повторить? Рыбу легче достать чем код, который позволит сделать танчик стреляющий по вражеским спрайтам.
>Нет, не является. Ты же повторяешь свои ошибки, которые наверняка повторял в других сферах: пытаешься с наскока сделать то, на что у других людей уходят годы последовательного обучения и практики
Я не делаю сложную игру с красивой графикой, неожиданным сюжетом, и сложным геймплеем. Все моё воображение и задумки остались на мизерной планке ребенка которого с рождения ничего не ставят. По мне раз ты уже несколько раз утверждаешь того, что я не разу не говорил, ты решаешь тем самым меня потроллить. Для наглядного примера я нашёл критический обзор на игру от школьника на rpgm. Посмотри на пики и пойми, выше этого я прыгнуть и не надеюсь.
Некоторые моменты я опустил, достало писать то о чём уже было сказано. И философские мысли о сложности человеческого организма тоже затрагивать нихочу. Инженеру трудно создать робоногу, вместо простого создания полноценного человека через зачатие.
Что б вы понимали, в чём разница. В прошлом (те серые коробки с дырками) я пытался генерировать стены, внешние и внутренние, работая непосредственно с блоками (мешами), помещая их в GridMap с размером ячейки 4x4x4, итого дом мог бы быть описан так (вид сверху, один этаж):
2 1 2
1 0 1
2 1 2
Алгоритм должен был бы выбрать и разместить необходимые блоки на месте чисел в зависимости от их соседей: угловые двойки должны стать стенами-уголками, а прямые соседи нуля должны стать сплошными стенами или стенами с окнами и дверями.
С таким дурацким подходом я вынужден был бы сначала убедиться, что я правильно разместил стены, в соответствии с их типом (сплошная/угловая и т.д.), в массиве из типов блоков, а потом убедиться, что правильно разместил визуальные объекты, которые могли иметь множество форм и положений независимо друг от друга. При этом информация о блоках запутана между этими двумя этапами и работать становится сложно. Конечно, это позволяло бы мне делать разные глупые комбинации, но зачем они мне нужны? Мне нужны готовые домики без глюков и артефактов генерации.
Сейчас я применил следующий подход. Массив снова заполняется числами, но теперь они имеют другой смысл - обозначают тип/свойства комнаты, а не блоков, из которых эта комната могла бы состоять. Предыдущий пример выглядит теперь так:
0 0 0
0 1 0
0 0 0
Далее, алгоритм визуализации обходит каждую клетку и проверяет её непосредственных соседей. Нуль - пусто, ничего размещать не надо (пока что). Единица - комната, нужно проверить её соседей. Если рядом с единицей другая единица, то ничего не делаем (для экстерьера), а если рядом с единицей нуль - размещаем стену в координатах единицы в направлении нуля. То есть единица на схеме выше будет иметь сразу 4 стены, независимо от верхних и нижних этажей и угловых клеток, и все эти стены будут расположены в одной точке пространства.
Может быть, преимущества неочевидны, но подумайте о расширении дополнительными блоками. Для добавления балкона в первом варианте потребуется написать что-то вроде этого, добавив новые типы в генератор (вообще, я сомневаюсь, как это должно быть, не вдавался в детали):
5 4 4 5 - блоки заборчика
4 3 3 4 - заборчик, пол, пол, заборчик
1 2 1 1 - стена, дверь, стена, стена
В новом варианте можно сделать так:
0 0 0 0 - ничего нет
0 3 3 0 - двойной балкон
1 2 1 1 - комната, вход, комната, комната
И дальше на этапе визуализации все необходимые блоки выстроятся как положено, заставив балкон заборчиками с фрагментами пола или что там мы хотим видеть на балконе. Т.е. имея несколько наборов блоков, можно использовать одно и то же описание дома для разного внешнего вида.
Новый метод также позволяет по-быстрому разместить опорные балки. Если дом должен опираться на балки, не нужно вручную помечать места балок - достаточно разместить комнату над пустотой и алгоритм визуализации, проверив отсутствие опоры под комнатой разместит туда опорные балки (если они есть в наборе блоков). Хотя пока я не пробовал такое, должно будет выглядеть шикарно.
Интерьер визуализируется отдельно, но по той же схеме. То есть не нужно отдельно отмечать внутренние стены и тому подобное, алгоритм просто пройдёт по клеткам и поставит все необходимые блоки в зависимости от типа комнаты. К примеру, если комната - это лестничная клетка, то там появится лестница на соседние этажи, ориентированная соответственно соседним клеткам (я посчитал, для юзабельной лестницы нужно минимум 2 клетки, иначе лестница будет слишком крутой). А если под клеткой крыши находится комната "лифтовая шахта", то на крыше появится лифтовое оборудование в будке. Всё ещё не уверен на счёт размещения дверей, но, думаю, вопрос решаемый, а в крайнем случае лишние двери не помешают (лол).
Визуальные блоки теперь могут быть точнее ограничены, в частности, блоки экстерьера размещаются в пределах грани куба 4x4x4 и могут выпирать наружу, а блоки интерьера должны будут, наоборот, вписываться в куб 4x4x4 и могут выпирать вовнутрь. Пересечение блоками друг друга исключено или минимизировано, они будут прилегать друг к другу без каких-либо проблем на стыках (до этого мучился с исправлением дырок).
Также, по очевидным причинам, я отказался от GridMap, ведь он не позволяет заполнять пространство так, как я описывал выше. Сначала думал использовать мультимеш, но попробовал merge_meshes() и это оказалось достаточно производительно (пока что). Если что, я думаю, легко заменить на мультимеш, но merge_meshes выгоден тем, что позволяет склеивать геометрически разные блоки с одним материалом (жертвуя памятью).
Нужно только обобщить алгоритмы и вывести свойства комнат и блоков во внешний файл, чтобы можно было быстрее набивать генератор контентом (что я уже давно хотел сделать, но у меня не получалось из-за неудачного алгоритма). Тогда можно будет хоть Гигахрущ генерировать и заполнять его интерьеры всяким мусором (кстати, как-то хотел сделать такой генератор, но тогда я ещё не догадался до такой простой концепции комнат, поэтому забил).
Я понимаю, визуально выглядит как куча кубов, но это только из-за нехватки блоков и простейшего алгоритма заполнения этажей. Хочу добиться косых углов, внутренних дворов, мостиков, опор, каких-нибудь выпирающих частей побольше и т.д., тогда экстерьер будет намного привлекательнее. Интерьер, конечно, будет состоять в основном из кубов, но можно будет сделать крупные залы в два-три этажа (8-12 метров), колонны и множество разных декоративных стен. Только нужно не забывать, что интерьер должен быть проходим для ботов (по идее, всегда должна оставаться дорожка через центр комнаты)...
Внезапная идея: можно после слияния всех блоков в один меш потом смещать все вершины по каким-либо формулам. Может, кто-нибудь помнит, когда я выкладывал скриншот модели дома с пухлыми стенами? По идее, теперь я смогу сгенерировать такой пухлый дом любой высоты и с любой планировкой, как снаружи, так и изнутри. Конечно, смещение вершин займёт время и потом могут возникнуть проблемы с навигацией в таком изогнутом пространстве, но выглядело бы, на мой взгляд, шикарно, даже лучше, чем кривые домики в Townscaper - там у них только фундамент кривой, а этажи идут друг за другом линейно. О-о-о, а если ещё и перекручивать немного по оси Y, вообще офигенно получится. Всё же я хочу более-менее мультяшные, визуально забавные домики, а не унылые коробки... Но для таких операций, наверное, придётся поворотные матрицы вспоминать.
>Годот слишком маленький
Ниша пуста -> выше шансы заработать.
>будут делать туториалы это искренние энтузиасты
Видел несколько платных курсов. Пару проектов с одного такого платного курса щупал (они опенсурс) и там был какой-то быдлокод... Что только ни продают ради наживы на наивных ньюфагах.
>Я скачу с темы на тему по причине выбора более легкой реализации.
Нет, ты скачешь с темы на тему, потому что боишься трудностей и при первых трудностях бросаешь тему, переходя на что-то другое. А трудности у тебя появляются из-за отсутствия базовых знаний, через которые ты решил перепрыгнуть в стремлении поскорее сделать игру мечты. Ты пойми, этим многие страдают и ты не исключение, ты идёшь по граблям, по которым уже несколько поколений ньюфагов прошло ещё задолго до появления Godot. Только ты все замечания в штыки принимаешь и начинаешь спорить, вместо того, чтобы принять свою ошибку.
>нужную мне механику кликов по врагам сделать хрен получиться.
Опиши свою механику. Наверняка ты снова проскочил какую-нибудь тему и поэтому тебе кажется, что сделать так нельзя, а на самом деле всё просто.
>его написанный код не смог заработать
Вот опять, ты взял какой-то код, не имея ни малейшего понятия о том, как он работает и что делает, поэтому не смог его использовать. А теперь жалуешься, что "код не смог заработать" - это не код не смог, это ты не смог его понять. А не смог понять, потому что базовых знаний не имеешь. Обучение должно быть системным, даже если оно тебе не нравится и кажется пустой тратой времени. И снова, ты не один такой, много людей прошли по этим граблям из-за своего характера...
>неспособны учиться иностранным языкам
Не выдумывай, если бы у тебя были такие серьёзные дефекты мозга, ты бы здесь полотна текста не писал. Даже сравнительно примитивные нейронки уже много лет как осваивают несколько языков и могут что-то связно сочинить/перевести, а у относительно здорового человека возможностей больше, было бы желание и усидчивость учиться. Вот тебе явно усидчивости не хватает, судя по твоим постам и жалобам, но не беспокойся, её можно выработать, было бы желание работать над собой.
>читал книгу по слогам, в шестнадцати летнем
На иностранном языке - ничего необычного. Кто-то и в старости начинает учить язык, при чём тут возраст?
>Рыбу легче достать чем код
Это пока ты не пытаешься научиться кодить. Как только научишься кодить, тебе будет проще закодить робота, который самостоятельно сбегает к реке и поймает рыбу, чем встать из-за компьютера и сходить в магазин своими ногами. Пальчики-то вот они, бегают и код набирают, а ногами тушу свою тащить тяжело...
>>пытаешься с наскока сделать то, на что у других людей уходят годы последовательного обучения и практики
>Я не делаю сложную игру с красивой графикой, неожиданным сюжетом, и сложным геймплеем.
Даже для простой игры с примитивной графикой, без сюжета и единственной игровой механикой необходимо усердное последовательное обучение и практика в определённом порядке. Ты же, видимо, думаешь, что раз у тебя игра простая, учиться программировать не нужно, достаточно нахвать готового кода из туториалов... Тебе говорят: нет, нужно учиться последовательно. А ты снова сопротивляешься и обвиняешь в троллинге. Ну да, конечно, школьные учителя - главные тролли на планете, и вообще вся система образования - это троллинг, ведь всё в мире можно создать, скопипастив код из туториала. Так что ли?
>выше этого я прыгнуть и не надеюсь
Без целеустремлённости игры не сделать. Целеустремлённый человек даже с твоим методом копипасты и дефектами развития сделает всё возможное и невозможное, чтобы реализовать свою игру (пример у всех на слуху, он ещё и деньги на жизнь этим проектом зарабатывает, даже спустя все эти годы говнокода и невыполнения кучи обещаний), пока люди вокруг него жалуются на то, что "выше <этого> прыгнуть не надеются". Работай над собой и тогда разработка игры не будет таким мучением.
Смог бы Симон пробурить небеса, если бы в его жилах не текла магма, раскаляя сердце? Нет, не смог бы. А бур - это всего лишь удобный инструмент... Не будь у него бура, он бы ложкой прокопал небеса. Не будь у него ложки, он бы пальцем проковырял небеса. Ну ты понял, делай выводы.
Я пока не сталкивался с такого рода проблемами, того что есть достаточно
Не, просто нужно хорошее обучающее видео
Например по юнити находил Udemy курс 2017 года, там умные ребята делали его, начало обучения это обучение тому что такое State Machine, а всё что связано с основами и прочим по ходу выясняется, так как очень просто.
Ещё и постоянно напоминают про базовый и очень мощный принцип - декомпозиция, причём важно чтобы человек это понимал не как крутое слово, а как штамповку-дробление на простые задачи подобно автомату, иначе здраствуй ООП пиздец с кучей наследований прочей херни там, где этого не требуется вообще. У меня есть пример обучения как в вузе, где тебя учат ООП без адекватного примера его применения и задачи, на которой он себя отлично показывает в сравнении с чем-то.
В итоге, пока он будет возиться с ненужной для него основой, чел с подобным курсом уже будет не только знать тоже самое, но понимать почему так благодаря созданию чего-то полезного.
Когда человека учат использовать инструмент, ему не объясняют как добывают и обрабатывают материал из которого он сделан.
> начало обучения это обучение тому что такое State Machine
Вот это и есть основы, о которых говорили выше. Лично я в своём познании настолько преисполнился, что могу смотреть курсы по юнити и применять их в годот. Я не вижу разницы. В обоих движках главный цикл с коллбэком update/process. В одном движке все объекты это 3d-трансформ, в другом все объекты представляют три разновидности: 3d-трансформы для тридэ, 2d-трансформы для двадэ и интерфейсов и общий класс без трансформа вообще, для утилитарных нужд. В юнити все объекты выстраиваются в "иерархию сцены", в годоте все объекты выстраиваются в "дерево сцены". И да, в обоих движках есть сцены, которые используют сериализацию. Причем в юнити сериализация вшита так плотно, что её основной игровой объект в штатном режиме не создаётся конструктором, а десериализуется из префаба (который есть не что иное как сериализованные данные на диске). В юнити префабы, в годоте пакед-сцены. В годоте же игровой объект можно штатно создавать конструктором, можно и десериализовывать. В юнити скрипты - это компоненты родительского игрового объекта и они тоже игровые объекты. Один игровой объект может иметь несколько скриптов-объектов в своём списке компонентов. Каждый из объектов-скриптов, как игровой объект так же имеет список компонентов и может иметь несколько скриптов-компонентов. В годоте скрипты это ресширения базового объекта-ноды, каждая нода может иметь только один скрипт, однако, нода встроена в дерево, потому и называется нодой, а значит, она находится в списке детей своей родительской ноды, и у неё самой есть список нод-детей.
Слова разные в движках, а смысел один. И так можно до бесконечности сравнивать. Экспортированный проект юнити представляет собой юнитиплеер, и набор даных, который проигрывается юнитиплеером. Экспортированный проект в годоте представляет собой годотплеер, и набор данных, который проигрывается годотплеером.
А с определенного количества это неважно, а важно только достаточное покрытие тем. Вот мне надо было гайды на террейн, на инверсную кинематику ног, на обводку объектов, на порталы - это все нашлось хотя бы в 2-3 вариантах, а значит хватает. По сравнению со старыми опенсурс движками типа Ogre3D. А то, что для чего-то клепают намного больше новичковых гайдов вида "я сделал свой первый платформер" - это уже не так важно. Конечно, наверняка найдутся темы, на которые тут еще нет гайдов, но это уже специально искать придется теперь.
Такие вещи гораздо эффективнее текстовой документацией покрываются.
Для опенсорса у годота охуенная документация. А не как бывает, просто дамп сигнатур функций, без объяснения как это использовать.
>Ниша пуста -> выше шансы заработать.
Малый спрос -> Маленький заработок.
Те кто хотят заработать денег с обучения и продажи рекламы будут брать более популярный движок. Ведь на него клюнет больше незнающих новичков. Это тоже самое если думать что кокаколу купят меньше, чем брусничный морс.
>Видел несколько платных курсов. Пару проектов с одного такого платного курса щупал (они опенсурс) и там был какой-то быдлокод
Пару примеров на личном опыте. Где идёт отрицание действительности. Мир не чёрно-белый.
>На иностранном языке - ничего необычного. Кто-то и в старости начинает учить язык, при чём тут возраст?
Не на иностранном! А на родном русском языке!
Оговорю одно, но ты мало того что не хочешь понять, повторяешь все то, на что уже отвечал.
Ниша пуста -> меньше конкуренция.
>Пару примеров на личном опыте. Где идёт отрицание действительности.
Тоже качал разные курсы, в основном там хуйня сделанная треьтекурсниками которые возомнили что что-то умеют.
>Ниша пуста -> меньше конкуренция.
Насколько можно не разбираться в экономике для написания такого бреда?
Сделаю показательный пример на пиках: где есть популярная игра в занятой нише. И пустая ниша с умершим говном.
>качал разные курсы
Я ссылку приложил на бесплатный курс относящийся к теме.
https://www.youtube.com/watch?v=VeCrE-ge8xM&list=PLda3VoSoc_TSBBOBYwcmlamF1UrjVtccZ&ab_channel=BornCG
Почему вам удобно его игнорировать, и потом писать мне что это я игнорирую всех и вся?
>Насколько можно не разбираться в экономике для написания такого бреда?
Ну то есть ты считаешь что надо сделать еще один пиксельный платформер и пытаться втиснуться между тысячами других, или лучше сделать более оригинальную игру и конкурировать уже среди нескольких десятков?
>Почему вам удобно его игнорировать, и потом писать мне что это я игнорирую всех и вся?
И ты только что писал про личный опыт, лол.
>Ну то есть ты считаешь что надо сделать еще один пиксельный платформер и пытаться втиснуться между тысячами других, или лучше сделать более оригинальную игру и конкурировать уже среди нескольких десятков?
У непопулярного жанра будет меньше потенциальной аудитории. Если при создании платформера в твою игру заходят поиграть сто человек, при оригинальной идеи это количество будет куда меньше. Если нужен результат и волнует финансовый вопрос, лучшим решением сделать работающею игру по рабочей схеме. Чем не понятно что, для хрен пойми кого!
Ты даже не пытаешься понять что тебе говорят.
Ну хорошо, если ты такой умный, почему тогда бедный?
О, спасибо, ты открыл мне глаза на логику тех, кто делает очередной пиксельный платформер и ничего не зарабатывает, потому что они же просто делали по рабочей схеме, как так получилось, что игру никто не заметил.
>Ты даже не пытаешься понять что тебе говорят.
Посмотри во что играют люди, и в какие игры они хотят играть.
>Ну хорошо, если ты такой умный, почему тогда бедный?
Я это взял как аналогию почему на других движках гайдов больше.
Сколько времени ты провёл в вангерах? Смогла ли оригинальная игра покорить весь мир? В мор утопию играл, тебе было очень интересно?
>cs:go, dota, pubg, rust
>во что играют люди, и в какие игры они хотят играть
Твоя проблема в том, что ты не понимаешь этих людей. Ты смотришь на статистику конкретных игр и думаешь, что все эти люди играют в эти игры от безысходности, потому что не могут найти альтернативу. Ты думаешь, что если кто-то сделает игру в том же жанре, но лучше по каким-либо измеряемым параметрам, этакую типичную "убийцу %игра%", то эта новая игра перетянет на себя всю или по крайней мере большую часть аудитории лидеров.
Но на практике это не так. Да, новая игра может перетянуть на себя несколько недовольных ньюфагов, которые попытались закатиться в существующий проект и им что-то не понравилось, после чего они сразу начали искать альтернативу. Но большинство уже играющих никуда из этой конкретной игры не уйдут. Им не нужны никакие альтернативы, они будут играть в то, во что уже играют, пока у них не отберут техническую возможность (закрытие сервера и т.п.), и даже после этого они перейдут только в полный 1-в-1 клон, а не во что-то похожее, но другое. Поэтому у этих игр огромная аудитория, которая с годами никуда не утекает даже с появлением кучи альтернатив.
С более мелкими жанрами похожая ситуация. Никто не будет играть в 100500 платформеров просто потому что эти платформеры существуют. У игрока нет ни времени, ни желания играть во все возможные игры одного жанра. В лучшем случае у него будет 2-3 любимых игры одного жанра, а всё остальное того же жанра ему нет смысла покупать и пробовать. Вот разработчик видит несколько очень популярных платформеров, видит, что несколько сотен других тоже чего-то добились, и делает свой платформер, который отправляется на дно рынка к десяткам тысяч других никому не нужных платформеров. В лучшем случае ему удастся пробиться в сотню за счёт какой-то дерзкой, ни на что не похожей фичи, или какого-нибудь скандала в СМИ. Но это уже не совсем геймдев, это нужно быть маркетологом, чтобы понимать, как продать никому не нужный продукт в переполненной нише.
В то же время у экспериментальных игр есть вероятность не просто заполнить собой какую-то полупустую нишу, а буквально создать новую нишу, о которой раньше никто даже не думал. Может быть, твоя игра будет первой и затмит всех последователей, а может быть, твоя игра будет первой достойной... Как говорится, в царстве слепых и одноглазый - король. А ты предлагаешь одноглазому, тугоухому, безногому и беспалому конкурировать кибернетически улучшенными суперсолдатами... Даже если большинство людей интересуется не тем, что ты делаешь, у тебя больше шансов собрать аудиторию, если ты будешь делать то, что другие не делают или делают хуже тебя.
С движками ситуация похожая. Unity пользуются в основном из-за того, что первой её освоили и привыкли, какие-то альтернативы им не нужны, а если и нужны - то обязательно 1-в-1 как Unity. Но на рынке туториалов к Unity конкурировать бесполезно, там лидерах - сделанные по заказу владельцев Unity, и вообще количество такое, что твой ещё один туториал "как двигать кубик по сцене" никому не нужен. Godot же, хотя и менее популярен, тоже имеет свою аудиторию, и эта аудитория испытывает нехватку качественных туториалов, которую ты можешь компенсировать своими туториалами. Пусть твоя потенциальная аудитория будет меньше, но твоя реальная аудитория будет больше и благодарнее за счёт удовлетворения существующей у них потребности. То есть прибыль с платного курса по Godot в данный момент может быть куда больше, чем с платного курса по Unity, если считать только прямые покупки (Unity проплачивает всяким геймдев-школам, чтобы набирать и поддерживать свою популярность, поэтому учителя в плюсе даже если никто не берёт у них эти уроки, а у Godot на такой маркетинг, похоже, пока что денег нет).
За два дня 235 отзывов
Вы же платформеры обсуждаете, а это топ-даун рогалик, совершенно другая ниша. Пиксель-арт не ограничивает жанр игры.
>>866344
>перетянет на себя всю или по крайней мере большую часть аудитории лидеров.
Какими мне словами ещё тебе объяснить? Есть большой пирог, есть маленький пирог! Если взять маленький кусочик от обоих пирогов, у большого пирога он будет больше!
p.s.
До этого я спрашивал про платные ассеты на годот, после чего был без причины послан. До сих пор не знаю можно ли их где либо купить, или нет.
>>866347
Пускай он почувствует себя идиотом даже на своём поле шизофрении.
>надеюсь смогу сделать такую же игру
Технических сложностей не вижу. Делай.
>большой пирог, маленький пирог
Смотри. Большой пирог уже давно поделён на части серьёзными людьми, которые приставили хорошо тренированную охрану к своим кускам и никого не подпускают, ты можешь рассчитывать только на сбор грязных крошек с пола. Маленький же пирог тебе хотя и не дают целиком, но угощают, почти силой пихая крупный кусок в рот. Тебе не нужен целый пирог, чтобы наесться, но и крошками с большого пирога ты сыт не будешь. Так что лучше будет пойти к маленькому, чем побираться в радиусе крошек от большого.
>>866349
>платные ассеты на годот
>можно ли их где либо купить
Пока что нет официального рынка ассетов, потому что это требует юридического регулирования, которое сложно провести с опенсурсом. Но те, кто делают ассеты, могут продавать их на сторонних площадках. В частности, 3D модели, текстуры, спрайты, тайлсеты, музыку и звуки следует искать на общих площадках, не зависящих от конкретного движка (просто поищи в интернете). Скрипты же могут продаваться на таких площадках, как itch.io и gumroad.com, или где-либо ещё, где можно продавать цифровой контент. Некоторые публикуют свой контент на patreon.com, где нужна подписка на месяц для получения временного доступа ко всем опубликованным материалам.
В остальном, если ты серьёзно намерен делать игру, лучше будет делать всё самому, заказывать у фрилансеров или нанимать сотрудников, чем покупать ассеты без личных знаний или толкового сотрудника, который эти ассеты будет использовать. Это ведь не волшебная палочка, без понимания какой-то темы платные ассеты не будут сильно лучше бесплатных. Я смотрел платные ассеты на юнити, и там не было чего-то, оправдывающего высокие цены. Это просто жмоты, которые пользуются тем, что цифровой контент можно неограниченно продавать, затратив минимум усилий в самом начале...
Ну то есть до мора 2 осталось всего 6000?
А остальные провальные тысячи игр ты почему не посчитал, кстати, ошибка выжившего?
Ну где-то в гугле вылезает сайт с платными ассетами, но не знаю покупают ли там. Смысла в этом в любом случае немного. А, еще на итче видел парочку.
>>866136
Вы оба сильно заблуждаетесь. Базовые знания для геймдева - это устройство компьютера и разработка простейших программ. Тот анон сам признавался, что не знает, что такое цикл for, а вы ему предлагаете конечные автоматы изучать.
Он простой нытик, которому подавай готовую игру на блюдечке по нажатию пары клавиш, на которые ему однозначно укажут в весёлом видео на Ютубе. Ему нужно получать базовые знания, а он ноет, что у него не получилось скопипастить draw_circle() без красненькой полосочки снизу окошка, которую он сам читать, конечно, никогда не будет, ведь ему всегда могут пояснить люди в интернете.
А если люди в интернете не хотят пояснять - он бросает свои идеи, ноет немножечко и потом к следующей идее переходит, про которую нашёл очередное смешное видео на Ютубе с подсказками, что куда жать.
Своей головой ему нужно думать, а он не хочет.
Сделай теперь так, чтобы на экране был мигающий, с интервалами 1 в секунду, оранжевый квадрат.
>Своей головой ему нужно думать, а он не хочет.
>Когда мне нормально ответили...
Что и требовалось доказать: думать не хочет, только ждёт, когда ему скажут, как делать то-то и то-то.
Ты пойми, копипастом ты хорошую оригинальную игру не сделаешь. От разработчика игры требуется интеллектуальный труд, а ты трудиться не хочешь. Поэтому тебе не дают готовых решений: они бесполезны в реальной разработке. Ты должен уметь решать задачи самостоятельно.
Возможно, Godot тебе ещё рано изучать. Попробуй какой-нибудь детский конструктор игр, там не нужно код текстом набивать и много готовых решений на все случаи жизни уже в движке, достаточно выбрать желаемое. Туториалы обычно тоже адаптированы под детей, так что вряд ли потеряешься.
Не беспокойся, база геймдева что здесь, что в конструкторах игр одинакова. Но в конструкторах проще усвоить эту базу, не отвлекаясь на лишнее.
>>866415
Не издевайся над ним...
Молодец, анон. Продолжай изучать и делать игры. Не поддавайся дисморали от токсиков. В годоте дружное комьюнити, и ни в какие другие движки не выгоняют. Годот вполне подходит новичкам. Мы всегда поможем, спрашивай что еще подсказать.
>Если нужен результат и волнует финансовый вопрос, лучшим решением сделать работающею игру по рабочей схеме.
Ты только что юбисофт
>Не издевайся над ним...
Может это заставит его пойти и найти как это сделать...
> боюсь они правы
Я уже не помню, по какому поводу вы (мы?) там срались, но скажу так. Нужно с осторожностью относиться к видеоурокам, не только на ютубе, но даже к платным, с сервисов типа Udemy. С осторожностью. Авторы туториалов очень часто прививают зрителям вредные привычки в кодинге. Им это напрямую выгодно.
ПОДУМАЙ САМ
Если бы ты зарабатывал на продаже туториалов, или, скажем, выкладывал на ютуб и получал рекламную монетизацию, выгодно ли было тебе, чтобы после туториала зритель сразу бы всё понял и ушёл делать игры? Нет, невыгодно. Тебе было бы выгодно, чтобы зрители как можно меньше понимали бы после твоих уроков, и им бы требовались всё новые и новые уроки. А ты с удовольствием им эти новые уроки продашь.
Поэтому в подавляющем большинстве туториалов мы видим (слышим) буквально следующее:
> Так, тут кидаем эту ноду, потом объясню. Здесь добавляем этот код. Ну тут, карочи, э. Скачиваешь ассеты по ссылке в описании. И вуаля! Ты. Сделал. Свою. Первую. Игру.
Спешу расстроить. Не "ты", не "сделал", не "свою" и увы, не "игру".
А код там полный мрак, вроде дёрганья нод из дерева в колбэке _process() я лично сталкивался, скачал с гитхаба контроллер от третьего лица, с такой знаете ли няшной роботяночкой в качестве модели, являющийся проектом-ссылкой из под туториалов одного инфоцыгана с ютуба. А контроллер тормозит на моём некроговне. Я смотрю на экран - ну чему там тормозить? Ну чему? Открываю скрипты, а там пиздец, сынуля, полный пиздец.
Ну я вынес все строковые пути к нодам в onready переменные, и бац - 60 фэпесов на моей некрухе.
То есть, если следовать базовым гайдам кодинга, которые ещё на уроках информатики прививают в школах, то ты/мы/они быстрее игру сделаем, чем глядя видеоуроки.
>Если бы ты зарабатывал на продаже туториалов, или, скажем, выкладывал на ютуб и получал рекламную монетизацию, выгодно ли было тебе, чтобы после туториала зритель сразу бы всё понял и ушёл делать игры?
Ага. Возможных тем - огромное, неисчеслимое количество. Зритель, который понял и усвоил прошлый урок, с большой вероятностью вернется на следующий, у него же положительное закрепление, что ты хорошо научил. А к тому, кто не научил полезному, зритель не захочет возвращаться, скипнет с мыслью - а, это тот бесполезный челик.
Удивительное дело, да? Тем дохуя, а туториалы на 99% как сделать простой платформер для начинающих. Удивительно, да?
Они зарашили четверку, чтобы успеть к GDC, наверняка там багов выше крыши.
>Авторы туториалов очень часто прививают зрителям вредные привычки в кодинге. Им это напрямую выгодно.
Двачую, всё так, но низкое качество большинства туториалов всё-таки вряд ли умышленно - если бы автор даже хотел научить качественно, ему для этого нужны знания и навыки преподавателя. Много ли у нас реально достойных преподавателей, окончивших ВУЗ по специальности преподавателя, и при этом шарящих за геймдев? Да ещё и на не очень популярном движке. Я уверен, большинство авторов туториалов - самоучки, какие-нибудь дворники да сантехники, в лучшем случае - собственно программисты и геймдизайнеры, но никогда не настоящие преподаватели. У них ни навыка преподавания нет, ни системных знаний по теме геймдева. Одно только альтруистическое желание учить - или зарабатывать на рекламе с просмотров и продаж курсов. А по описанным тобой причинам повышать собственный уровень им невыгодно, пока их смотрят, лайкают и благодарят в комментариях.
>>866914
>Возможных тем - огромное, неисчеслимое количество.
Ты опять ничего не понял, лол. Тема - всего одна. Это разработка компьютерных игр. Тема эта по сути является комбинацией нескольких сфер - код, графика, звук, сценарий и т.п. - только они затронуты поверхностно. То есть для разработки игры тебе не нужно быть лучшим в мире программистом или художником, но нужно разбираться в программировани и рисовании хотя бы поверхностно. Далее, чтобы освоить эти темы хотя бы поверхностно, тебе нужен системный подход, который тебе должны преподать на уроках в школе, ВУЗе или специальном учреждении, а дальше ты будешь применять этот подход для повышения собственных навыков.
Приведу наглядный пример. Ты мог встретить в интернете туториалы по типу "как нарисовать сову", в которых тебе показывают набор кривых линий или последовательность штрихов, повторяя которые у тебя на листе бумаги или экране может получиться сова. Научит ли тебя это рисовать? Чтобы ответить на этот вопрос, ответь сначала на следующий: будешь ли ты после туториала про сову нуждаться в похожем туториале "как нарисовать тигра"? К сожалению, такой туториал не научит тебя рисованию, а в туториале про тигра тебе дадут очередной набор линий или штрихов, но и он тебя ничему не научит.
Чтобы по-настоящему научиться рисовать, тебе должны объяснить, как нарисовать что угодно, что пожелаешь. Это возможно, и это умеют настоящие художники. Настоящего художника можно попросить нарисовать что угодно - он сядет и нарисует это без поиска в интернете туториалов "как нарисовать то-то и то-то". Нет, этот художник никогда раньше не рисовал того, что ты попросил, и никогда не видел туториалов на эту тему. Но у него в голове есть Система, которая позволяет ему нарисовать что угодно, даже то, что он не видел, но может придумать. Ему никогда не нужны были туториалы вроде "как нарисовать сову" и он никогда эти туториалы не проходил, а всё, чему он учился - это системному подходу к рисованию.
В программировании и разработке игр всё абсолютно точно так же. Ты можешь найти туториалы "как сделать платформер", которые пошагово показывают, куда нужно тыкать мышью и какие буквы печатать. Но после таких туториалов ты не сможешь сделать что-то другое, тебе придётся искать туториал на другую тему. Вот поэтому тебе нужно системное обучение, которое позволит тебе разработать любую игру с нуля, без подсказок и пошаговых разборов, просто придумать и сразу сделать.
И не надо оправдываться своим состоянием здоровья или какими-то особенностями психики. Тебе просто запудрили мозги все эти "туториалы", которые ничему на самом деле не учат, и из-за них ты потерял веру в свои возможности. Но это не так, ты способен научиться всему, просто должен поверить в себя, спокойно относиться к обучению и не скакать с темы "как нарисовать сову (платформер)" на "как нарисовать тигра (гоночку)", а подходить к теме "разработка игр" с самых фундаментальных основ, которые ты в своё время упустил или тебе плохо преподали (наверняка у вас там в школе тоже информатика была, она вроде обязательна, но учителя в школах обычно никчёмное говно и не умеют учить, а школота не хочет учиться, поэтому на уроках чаще тупо в игрушки играют, а задания проходят списыванием у единственного умника в классе).
>Ты опять ничего не понял, лол. Тема - всего одна. Это разработка компьютерных игр
Тем - полно. Поиск пути, процедурная генерация, стратегии реального времени, тысячи тем можно раскрыть.
Ты ничего не понял - и накатал стену текста, поучая других.
Когда же уже найдётся охуенный чувак с преподавательским опытом, который в русском сегменте запилит годные мини-видосы минут на 10 по всем этим прикладным темам, начиная с подробного разбора нод. Вот прям уроки по нодам. Урок по ноде ригидбоди, все свойства, всем методы, типичные примеры использования и т.д. Чтобы можно было зайти в поисковик, набрать ноду и получить исчерпывающий видос по ней.
>Поиск пути
RTFM. Я серьёзно, RTFM.
>процедурная генерация
Это зонтичный термин, который подразумевает создание чего-либо каким-либо методом в коде. Универсальных решений не существует. Нейронки и нейроарт - это тоже процедурная генерация.
>стратегии реального времени
Ну охренеть, может тебе сразу готовую игру дать, чтобы тебе вообще ничего делать не нужно было? Просто скачаешь и будешь играть.
>можно
Но не нужно. Почему не нужно - см. >>867181
>>867190
>Вот прям уроки по нодам.
https://docs.godotengine.org/en/stable/classes/index.html
>Урок по ноде ригидбоди, все свойства, всем методы, типичные примеры использования и т.д.
https://docs.godotengine.org/en/stable/classes/class_rigidbody.html
>Чтобы можно было зайти в поисковик, набрать ноду и получить исчерпывающий видос по ней.
Нажми в редакторе F1. Попробуй, это не больно.
> Нажми в редакторе F1. Попробуй, это не больно.
Я это всё читал, знаю. Мне видео хоца.
А я не тебе на личную почту пишу, а на публичный форум. Если не хочешь, чтобы я тебе тут писал, то свои влажные фантазии о видеоуроках на каждый пук высказывай ютуберам в комментариях под их видео, как делают все дети с их дебильными просьбами "зделойте туториал как нажать на иконку додод на робочим стале, а то я нажимаю мышкой а он нинажимаица((((("
А потом такие публикуют статьи про то, как их засосало в водоворот рекомендаций Ютуба и они так и не смогли ничего сделать на практике, ведь всё время у них уходило на просмотр туториалов...
> Так, тут кидаем эту ноду, потом объясню. Здесь добавляем этот код. Ну тут, карочи, э. Скачиваешь ассеты по ссылке в описании. И вуаля! Ты. Сделал. Свою. Первую. Игру.
>Спешу расстроить. Не "ты", не "сделал", не "свою" и увы, не "игру".
Ты приходишь к плотнику на мастеркласс. Он дает тебе бруски, доску, гвозди, молоток. Ты сколачиваешь их по образцу. Да, ты не полировал бруски, не выращивал древесину, не отливал гвозди. Ты не изобретал свой дизайн табурета.
Но, тем не менее, Ты. Сделал. Свой. Первый. Табурет.
Да, этот табурет такого же дизайна, как показанный плотником. Ты не делал из него кресло или шезлонг, потому что тогда ты слишком отошел бы от туториала и не знал бы, если где-то ошибся. В следующий раз ты можешь выточить фигурные ножки и перекрасить их, это уже будет твоя кастомизация.
Да, он кривенький, потому что ты сначала не тем боком поставил ножку, а еще ты пропустил отступ между гвоздями и пришлось переделать.
Да, ты не стал гением инженерной мысли и не умеешь рассчитывать сопромат, ты просто смог повторить что-то по образцу.
Но можешь выдыхать, новичок. Ты сделал свою первую игру, просто вставив ассеты в движок, и переписав код с туториала. Это - и есть твоя работа на данный момент.
Да, просто ты пишешь фигню. Тебе умные люди объясняют, а ты не слушаешь. Но мне то пофиг, твои проблемы.
Семён, ты чего разбушевался-то? Весна только начинается, подожди немного для приличия.
>Табурет
>дизайн табурета
Проблема твоей аналогии в том, что плотник - это ремесленник, а инди-геймдев - это творец, то есть дизайнер табуретов, стульев, кресел, диванов, столов, тумбочек, кроватей, шкафов, садовой мебели и ещё очень большого количества вещей из самых разных материалов. Плотник может сделать табурет по ГОСТу №такому-то от такого-то года и больше ничего не умеет, да ему и не нужно, он живёт, зарабатывая изготовлением одних и тех же табуретов 30 лет подряд, а в инди-геймдеве такое не прокатит - ты либо дизайнер-творец всего что только может быть, либо идёшь убирать мусор под столами галерных рабов в кубиклах. Нет, если ты хочешь занять место Петровича в кубикле и делать одну и ту же 3D табуретку ближайшие 1.5 года, пока тебя не заменят из-за устаревания технологий, то вперёд и с песней, но мы не в юнити-треде, так что по умолчанию занимаемся инди-разработкой, а не изготовлением одних и тех же табуретов.
>фигурные ножки и перекрасить их
А потом ты создаёшь очередной тред/статью:
>"я пять лет делал 9001-й гениальный платформер-говоломку по самому популярному туториалу, аккуратно перекрасив все спрайты в приятные (мне) цвета блевоты, а ему всего 3.5 отзыва написали, из которых полтора я купил у знакомых, а ещё два отрицательные во время распродажи со скидкой 99% написали, короче, инди-геймдев мёртв и больше не воскреснет, ваши игры никому не нужны и вообще вы ничего не добьётесь, мой пример тому идеальное подтверждение".
>ты просто смог повторить что-то по образцу
>просто вставив ассеты в движок
>работа на данный момент
Т.е. ты полностью одобряешь создание тысяч совершенно никчёмных ассет-флипов, единственная цель которых - показать рекламный баннер наивным детям и получить донат от какого-нибудь взрослого, богатого и при этом тупого лоха? Перекрасил ножки героя - получил совершенно новый, доселе невиданный платформер-говоломку, которую игроки просто обязаны скачать и поиграть, а потом ещё и отзыв в пять звёзд влепить и друзьям рассказать?
И после этого ты что-то там вякаешь про фигню и умные вещи, плотник высшего разряда...
А сейчас ты скажешь "тебе разные люди пишут" и доставишь нотариально заверенный скриншот с (You)...
>Проблема твоей аналогии в том, что плотник - это ремесленник, а инди-геймдев - это творец
Ничто не мешает плотнику быть творцом и изобретать мебель. Если тебе не нравится плотник - поменяй на кузнеца, к примеру. Работа кузнеца сейчас - это творить узоры для заборов, например.
>Т.е. ты полностью одобряешь создание тысяч совершенно никчёмных ассет-флипов
Я полностью одобряю, что человеку, который раньше не делал табуреты, дали компоненты, и он сам их собрал инструментом, научившись делать первый шаг. Что он будет дальше делать - изобретать свои шезлонги, или работать в кубикле - это сугубо его дело как свободного человека.
>А сейчас ты
Ну раз ты сам просишь.
Конечно, можно создавать аккаунты после истечения 20 запросов, но это как вариант.
>Ничто не мешает плотнику быть творцом и изобретать мебель.
Не мешает. Но ньюфагу показывают, как сделать простую табуретку по готовым чертежам, а потом этот ньюфаг носится с этой табуреткой, повторяя её раз за разом практически без изменений, и ноет о том, что готовых чертежей на другую мебель никто почему-то не даёт. А его мечта не табуретки делать, а какие-нибудь небоскрёбы строить, да только готовых чертежей опять-таки не дают.
В нулевых часто встречалось такое, что ньюфаги постоянно ищут "движок %имя популярной ААА-игры%", рассчитывая, что уж с движком-то от их любимой игры они точно построят небоскрёб. Сейчас ньюфаги видят, что движок для небоскрёба никто не прячет, они все бесплатно доступны, бери и используй, да только внезапно оказалось, что кроме движка ещё нужен чертёж, а готовыми чертежами небоскрёбов в удобном формате пошаговых видео-инструкций люди почему-то не делятся. Вот ведь беда, правда? Как же ньюфаг построит небоскрёб без пошаговых инструкций-то? Ведь пошаговые инструкции для табуретки помогли ему сделать табуретку, а вот пошаговых инструкций для небоскрёба мечты что-то нету нигде.
>Если тебе не нравится плотник - поменяй на кузнеца
Лучше сразу на бондаря, чтоб ассоциация с ассет-флиперами была более очевидной:
https://ru.wikipedia.org/wiki/Бондарь
>дали компоненты, и он сам их собрал инструментом
Как для сборки мебели из компонентов есть ИКЕА, так и для персональных развлечений есть игры-песочницы и конструкторы игр для детей. Зачем лезть в полнофункциональный игровой движок, если ты планируешь слепить себе табуретку из любезно предоставленных ножек и сиденья, а не делать свою собственную оригинальную игру?
Godot никогда не позиционировали как конструктор игр. Аноны выше по треду берут взрослые столярные инструменты и потом жалуются, что эти инструменты сложнее в использовании, чем игра в Лего, и ожидают увидеть инструкции по созданию реальных небоскрёбов в том же формате, в котором выпускают инструкции к наборам Лего. Детей избаловали и они выросли непослушными, всё им дай и покажи...
>научившись делать первый шаг
Сборка простого платформера из готовых компонентов - это так, забавная игра, а не первый шаг в геймдев, даже на любительском уровне (инди). Программист сможет сделать платформер даже совсем без движка и каких-либо предварительных знаний кроме умения программировать на каком-либо универсальном языке, а чем ему поможет видео по сборке платформера из готовых кусочков в редакторе сцен игрового движка? Разобраться с интерфейсом и основными концепциями редактора сцен - ладно, хотя для этого видео совершенно не обязательно, ведь программист в первую очередь прочитает документацию на английском и всё поймёт, ведь концепции-то простые и знакомые ему по работе с другими программами.
А вот тому, кто совершенно никак не разбирается в компьютерных технологиях, скажем, маленькому ребёнку или престарелой бабушке, данное видео ничем не поможет. Да, они могут повторить все шаги и сделать копию платформера из туториала, но дальше они не продвинутся ни на шаг, потому что у них нет БАЗЫ. А базу они из подобных туториалов никогда не усвоят, как нельзя усвоить базу академического рисунка из мемного туториала "как нарисовать сову". Только ты этого никак понять почему-то не можешь, или не хочешь признавать свою ошибку.
>>А сейчас ты
>Ну раз ты сам просишь.
Чувства юмора у тебя нет, так и запишем...
Учи мемы, чтобы не быть баттхёртом)))
Нет никакой ошибки, анон. У меня жена - художница сама научилась писать скрипты.
>художница сама научилась писать скрипты
>сама
В каком смысле "сама"? Я не против самообучения, я против тупого бездумного следования тупым туториалам, в которых тебя учат пользоваться готовыми компонентами, но не учат собственно реальной разработке, без которых умение использовать готовые компоненты бесполезно.
Алсо, "писать скрипты" не равно "разрабатывать архитектуру приложений", для разработки новых полноценных игр нужно именно второе, а первое как бы само собой разумеется.
>>867265
>Вопрос об обучении через ИИ
Это точно не шутка? Иди в /ai/ поспрашивай, лол. Только шизов там не слушай...
>она ответит с примерами
Самоуверенно и с максимально умным видом, наполнив текст морем заумной повторяющейся воды, лишь бы дать хоть какой-то ответ, даже если он будет совершенно ошибочным по причине отсутствия данных для хотя бы минимального правильного ответа. А ты, дурак, поверишь и будешь носиться со скриншотом, говоря "ууу, а ИИ вон чё сказал, я вам не верю, ИИ не может врать". Подожди ещё несколько лет, прежде чем появится настоящий разумный ИИ, а сегодняшние нейронки бесполезны для чего-то кроме развлекательных чатботов, сочиняющих всякий бред.
Архитектуре мало где учат вообще. Да и у игр простая архитектура. Ее то как раз автор туториала может дать. Вон экскраулерам из соседнего треда нужна что ли сложная архитектура? Я понимаю что ты программист который делает свою гта с машинками, но не надо проецировать прям на всех, тем более начинающих.
>Да и у игр простая архитектура. Ее то как раз автор туториала может дать.
В том же Godot достаточно много способов сделать даже самую простую игру, и не все способы эффективны, удобны и гибки в долгосрочной перспективе, тем более всё зависит от конкретного проекта. Автору туториала неизвестно, какую игру хочет сделать ньюфаг, он просто даёт один из возможных вариантов решения простой задачи. Нет одного общего решения для всех и каждого. Если тебе просто прототип на коленке слепить и забыть о нём, то ладно, но что, если ты всерьёз хочешь заняться... А многие вкатываются с серьёзными намерениями, даже если ничего изначально не знают.
>успеть к GDC, наверняка там багов выше крыши
Если это поднимет популярность движка, то жертвы оправданы и баги простительны. Выше популярность > больше заинтересованных > больше инвестиций > быстрее разработка, внедрение фич, фикс багов > выше популярность... Все только выиграют, ну, кроме тех, кого привлекало работать на маленьком непопулярном движке, известном и понятном лишь "избранным". Но для них полно других опенсурс движков, многие из которых всё ещё более-менее живы...
Беспокоит только, что Godot может изменить курс с целью угодить AAA в ущерб инди - меня вот этот переход на вулкан вообще никогда не радовал, какая-то фича ради фичи, лишь бы подлизнуть производителям видеокарт и графодрочерам, а игры-то тут при чём вообще? Какая связь между играми и всеми этими графодрочерскими свистелками? Игровой движок нужен чтобы делать игры, а не рекламные ролики новых поколений видеокарт (которые уже давно не нужны и теперь развиваются в какие-то универсальные числодробилки для домашних распределённых вычислений, графика в "графическом ускорителе" теперь приятный бонус, а не основная фича)...
ИМХО, косяк Godot, который меня изначально напрягал и теперь напоминает о себе, в его сравнительной монолитности. Да, ты можешь его скомпилировать из исходников без части модулей, но перед ньюфагом или любителем без желания копаться в C++ предстаёт монолитный движок. Нельзя на ходу сбросить лишнее, и если основной прицел будет на ААА, для рядового инди лишнего будет всё больше и больше. Если вокруг движка будут скапливаться крупные шишки, они будут лоббировать нужные им фичи, а это будет ещё сильнее отталкивать новичков и любителей. По причине нежелания копаться в C++ годного форка от таких любителей не дождёшься, и поэтому движок может скатиться в очередную элитную подстилку под геймдев корпорации, как какой-нибудь анрил, или кто там ещё из крупных остался. Т.е. с выходом 4.0/4.1 движок может перестать быть тем тёплым и ламповым, которым был до этого. Зря беспокоюсь? Вроде состав разработчиков за эти годы не особо поменялся...
>лишь бы подлизнуть производителям видеокарт и графодрочерам, а игры-то тут при чём вообще?
Вулкан же вроде улучшает производительность, не?
Просто оставлю это здесь
https://github.com/GodotECS/godex
А смысл? Штука давно заброшена (в движке много изменений за 8 месяцев то), а когда была не заброшена, я ее щупал и она была так себе по юзабельности (там надо открывать нелепые окошки со своими интерфейсами, которые еще и падали или портили сейвы), да и код там вроде не высшего качества.
Помню автор с братом-художником пилил 3д паркур, но похоже забросил и вообще на уе4 перешел куда-то работать.
А что тут советовать? ECS будет производительным только если встроен в движок, который строится вокруг него.
Иначе у тебя просто компоненты и системы для удобства дизайна.
Так что - либо просто берешь любой аддон на гдскрипте, какой понравится. Либо пишешь свой, банально на уровне - если добавлена нода Jumpable, то выполнять ее скрипт, добавляя-удаляя ноды ты меняешь поведение объекта. Либо подключать С/С++/Rust/C# либы, я лично пользовался flecs.c. Может быть они даже дадут какое-то ускорение если там чисто рассчеты например игровой логики, баффов.
Вы продолжаете спорить не давая полезную пищу для размышления. Поймите что если человек хочет создать игру собрав её из чужого кода, значит большее ему не нужно! Он не осилит ваши сложные идеи!
Мы просто любим попиздеть ни о чём. Не парься и делай себе игру.
Ну мы два треда назад решили перекатываться на 600 - 700 постах. Или чо, прям ради четвёрочки перекатить?
Чот у них ЦДН видимо напрягся. Все качают.
> Если мой проект и на релизной четвёрке будет рандомно подвисать при закрытии окна, то перекат будет через 100 постов.
Подвисает.
Ну ладно. Всё таки релиз. Надо.
>>867751 (OP)
>>867751 (OP)
