Шапка: https://hipolink.me/godothread
Предыдущий: >>890164 (OP)
Архивный: >>882096 (OP)
> Чтобы к концу треда все сделали по игре.
Напомни мне через 500 постов, стелать в следующем треде такой сабж.
Добро пожаловать в тред любви и взаимопомощи, и чтобы к концу треда все сделали по игре!
Ты наверное подумаешь, что я шучу, но меня никогда никак не мотивировал, как ты, анон. Твоя стальная уверенность в ценности игр и добродушность дают сил делать игры.
Прост сам делаю, вот и ты делой.
>Чтобы к концу треда все сделали по игре.
Зачем ты это написал? Предыдущий тред аж целый месяц заполнить не могли, а этот теперь совсем умрёт. Все будут молчать, чтобы не делать игр.
Легкий способ сделать игру.
Новый бестселлер Аллена Карра! Достаточно всего лишь добампать этот тред до бамплимита.
Хорошо. Начну делать игру после 450-го поста.
Разбудите меня, когда будет пора делать игру.
анонимыш
@
(зосыпаеться)
Споке-ноке!
>А потом думаешь - и зачем я это сделал? Ради чего?
https://www.urbandictionary.com/define.php?term=Post%20Nut%20Clarity
Нужно меньше дрочить на необычный код.
>Любой, кто реально будет в это играть
Расслабься, 99% игр не доживают до релиза.
>я сделал говно
Но ведь сделал же? Молодец! Многие тужатся, а оно всё никак не выходит, так что ты молодец.
Но не любое рождение/созидание является благом. Возможно мир был бы лучше, если я бы не выпустил эту странную, несуразную, недоделанную игру. Морально заслуживаю ли я этих 65 рублей, что я за неё заработал?
Я тоже хуйню делал (делаю). Но пока её весело делать мне похуй по большому счёту.
>Мне стыдно за нелепость своих игр.
Мне чувак как-то сказал один: "Кому-то нелепо т.е. "кринжуха", а кому-то точно тоже самое покажется нормальным.". Ну и вот я делаю игры и не стыжусь, особенно перед незнакомцами из интернета. Тут я так вижу. Три причины основных делать игры. Первая - это деньги. Вторая - веселье. Третья - ты ниибаца творец и тебе есть что сказать. Если хотя бы одно выполняется, то можно пилить свои высеры и похуй на всё.
Убей часть себя, которая кринжует
>Но не любое рождение/созидание является благом. Возможно мир был бы лучше...
С этой установкой можно вообще ничего не делать, просто лечь неподвижно и умереть от голода.
>Морально заслуживаю ли я этих 65 рублей
Заслуживают ли создатели сверхпопулярных игр те миллиарды долларов, что они получили? Нет. Но при капитализме иначе быть не может.
Так что расслабься и получай удовольствие.
>>896084
>Я ненавижу каждую свою игру. Каждую свою идею. Мне стыдно за нелепость
Тебя, видимо, очень много критиковали, стыдили, ругали, или что-то в этом роде. И ты выучился критиковать сам себя заранее, как бы предвосхищая критику со стороны. Из-за этого твоя самооценка пробила дно и теперь ты не можешь выкарабкаться с этого дна. Но выход есть. Сначала ты должен осознать, что твоя заниженная самооценка предвзята. Ты не оцениваешь себя объективно, ты просто гнобишь себя за любое действие. Но это бессмысленно. Зачем ты это делаешь? Чтобы защитить себя от критики другими людьми? Другие люди не нанесут тебе столько вреда, сколько наносит внутренняя самокритика, а большинству вообще плевать на то, за что ты себя критикуешь. В общем, прекращай себя критиковать и начинай себя хвалить за каждый шаг к любой твоей цели. Проснулся? Молодец. Позавтракал? Молодец. И т.д. Постепенно сможешь вырваться из порочного круга самобичевания.
А ты сам-то как думаешь? Ну вот серьёзно без троллинга, у тебя есть какие-либо соображения на этот счёт?
Как сделать, чтобы анимация движения 2d спрайта играла в обратном порядке, если персонаж смотрит в одноу сторону, а бежит в другую (бег спиной вперед, например)
>playback_speed
Переименовали:
https://docs.godotengine.org/en/stable/classes/class_animationplayer.html#class-animationplayer-property-speed-scale
Скорость анимации - это число кадров в секунду, а данный параметр - это множитель скорости.
>>896104
>Когда там 3.6
>Чего они так замедлились с тройкой.
Официальная позиция по данным вопросам:
https://godotengine.org/article/release-management-4-1/#godot-36
>As the main focus of contributors is on Godot 4 and beyond, the development process for Godot 3 is becoming slower. As such, we don’t have an exact release date in mind, but we will be continuing to merge pull requests into the 3.x branch and will release 3.6 when it is ready.
Читай новости, всё равно игры не делаешь.
Это нормально и по-хорошему не должно тебя никак дизморалить. Творческая работа в таком и заключается. Любая идея может оказаться калом, главное пробовать, и, однажды у тебя получится что-то действительно годное
Заебашь в флке, даже искать не придётся
>неделю придумывали идею для игры и делали прототип, но поняли что надо начинать всё с начала
Во-первых, это нормально. Прототипы создаются, чтобы заранее убедиться в том, что какая-то идея работает - то есть заслуживает полноценной реализации. Поэтому прототипы должны быть сделаны быстро и дёшево, а затем выброшены независимо от результатов. Это просто набросок, эскиз. Художники делают тысячи эскизов прежде чем написать одну полноценную картину, изобретатели проводят тысячи безуспешных опытов прежде чем создать нечто великое и т.д.
Во-вторых, разве тебе было неприятно делать этот прототип? Тебе должно быть приятно работать и разрабатывать, чтобы чего-то добиться в соло, без начальника с плёткой за спиной. Если тебе это всё неприятно и хочется только результат, то геймдев скорее всего не для тебя. Плох тот художник, кому не нравится делать эскизы и хочется с первой попытки без подготовки делать одни шедевры.
>Неделя выброшена в помойку.
Ты получил ценный опыт, повысил свои навыки и отбросил нежизнеспособную идею. Это успех.
Теперь придётся делать...
>Скорость анимации - это число кадров в секунду, а данный параметр - это множитель скорости.
Спасибо!
И ещё в дополнение: вместо звука я слышу очень короткий статический шум. В чём может быть проблема хуй знает.
Годотеры, сделайте мне плз несложный проектик за деньги.
Суть токова: нужно бросать два игральных кубика на бесконечную плоскость и выводить на экране количество очков.
Модель кубика есть максовская.
Игровой процесс:
1. Игрок нажимает ролл.
2. Кубики падают сверху на бесконечную плоскость
- Краёв плоскости не должно быть видно.
- Кубики не должны укатываться за пределы камеры (можно например сделать невидимые стены, но главное чтобы кубики не вставали ребром у стены), или любой другой способ избежать укатывания.
- Изначально кубики должны быть в рандомном положении по осям + надо им придать какое-то ускорение (чтобы не падали просто плашмя без перекатов, и вообще чтобы походило на рандом). Крч, процесс должен быть похож на ирл (т.е. в игре д.б. нормальная гравитация)
3. Кубики упали, стабилизировались и на экране показывается оверлей с количеством выпавших очков и их суммой. Игрок может рерольнуть, goto 1.
Вроде как несложно для тех, кто открывал годот пару десятков раз.
Пишите в телегу lubitelivodki
Времени щас нет, а если я чем-то занимаюсь короткими промежутками времени в свободное время, начинаю все забывать и тупить
Ну и не хочу говнокода, лучше найти того, кто понимает как структура проекта должна выглядеть. Я только простые вещи в юнити делал.
>только в одном есть проблема, что AudioStreamPlayer не играет звук в игре
Так проблема с проектом или с файлами звуков?
Пробовал создать пустой проект, закинуть звуки из проблемного проекта и воспроизвести их?
Удалял импортированные файлы (.godot)? Они могли импортироваться с ошибками.
Если звуки не работают даже в пустом проекте, тогда проблема может быть в кодировке. Перекодируй.
>в игре его просто нет
DEBUG или export template? Версия Godot, ОС? Мы сами должны это угадывать или ты просто поныть хочешь, что у тебя что-то где-то не работает?
Может у тебя логика с ошибками? Скажем, ты воспроизводишь звук и тут же останавливаешь его. Если к примеру это вкл/выкл в Area
https://youtu.be/qmjbRiekW_M
Пацаны оцените делаю иммёрсив сим шутер от первого лциа сегодня додумался наконец-то доделать мувмент(Я НОВИЧОК В ГОДОТЕ...) Сука сложно пиздец мой гуманитарный мозг еле справился. Но справился. Пиздос! Уровень айкью по видео определите???
Мне интересно, зачем использовать физический движок, если простой RNG честнее и надёжнее?
Для чего нужен этот проект?
Будут ли другие кубики или нужны только 2d6?
Чтож, +1 очко телепатии.
Лень браться, потому что делал подобное и
>кубики не вставали ребром у стены
Довольно геморно делать.
У меня были некоторые идеи насчет этого, но они все не очень сработали. Типа, после остановки кубика прижимать его прессом. Или делать скаты под углом.
Так же я не 100% проверял что изначальный рандомный спин достаточно рандомен. Просто какая-то нагугленная формула где делается спин вокруг рандомной оси на рандомный угол, и немного вариацию ангулар скорости физ тела.
И рейкаст для определения выпавшей грани почему-то иногда выдавал не ту грань, редко, раз в 100 или 1000 бросков.
Так что это примерно такой же уровень говнокода получится. А учитывая, что за такое заплатят копейки, это просто не стоит того.
Если просто сделать .desktop ярлык, то он закрывает терминал после выбора проекта в проджект менеджере, и вывод в консольку я уже не увижу.
Сделал костыльно, когда ярлык запускает .sh батничек который уже запускает годот. (это нужно, чтобы терминал сразу не закрылся) Но тогда в доке висит две иконки - от шелл файла и от самого запущенного годота. То, что терминал отдельным окном, я еще на винде привык.
godot.desktop:
[Desktop Entry]
Name=Godot 3.6.beta3
Exec=gnome-terminal --tab -- "/path/godot.sh"
Comment=Best game engine
Terminal=true
Icon=/opt/godot3/godot.png
godot.sh:
#!/bin/bash
/opt/godot3/Godot_v3.6-beta3_x11.64 "$@"
/bin/bash -i
P.s. а еще костыльность означает, что надо подтверждать закрытие окна терминала, ведь он думает что в нем какой-то процесс продолжает работать, а это просто фейковый баш...
>>кубики не вставали ребром у стены
>Довольно геморно делать.
Думаю, стена тут вообще не нужна. Цель - не дать кубикам вылететь за пределы обзора камеры. В таком случае можно сделать камеру следящей за кубиками. Куда бы кубики ни укатились, они всегда останутся в поле обзора камеры.
Также можно увеличить angular_damp, чтобы кубики не катились слишком далеко. И не прикладывать к ним слишком большую силу при броске.
>Так же я не 100% проверял что изначальный рандомный спин достаточно рандомен.
Какая разница? Используй обычный RNG. Всё равно физический движок не детерминированный, тот же самый бросок может выдать другой результат.
>рейкаст для определения выпавшей грани
Разве тут нужен рейкаст? Думаю, самым простым и универсальным решением будет закрепить на гранях Node3D, а затем сравнивать глобальные координаты в поисках наиболее высоко расположенной ноды. Тогда независимо от количества граней будет точно известно, какая грань наверху.
>Если просто сделать .desktop ярлык, то он закрывает терминал после выбора проекта в проджект менеджере, и вывод в консольку я уже не увижу.
Пишет в journalctl как и положено. Запускать годот через консоль тебе не нужно.
>Мне интересно, зачем использовать физический движок, если простой RNG честнее и надёжнее?
Хз что такое RNG - это общее навание всех гпсч или что-то конкретное, что используется в годоте?
Если имеешь в виду просто выводить цифры, которые отдал гпсч на экран без графония - ну так это же совершенно другая задача, которая имеет общее с этой только то, что используется околорандомный вывод циферок
>Для чего нужен этот проект?
Можно сказать лабораторная работа
>Будут ли другие кубики или нужны только 2d6?
Только пара 2d6
Мб я понял о чем ты.
Можно сделать так, как сделал гугол у себя: https://www.google.com/search?q=2d6
Т.е. никакого виртуального стола, моделька просто крутится и выдает ченть рандомное.
Да, этот вариант тоже ок, я чет сразу не подумал, что можно не усложнять
>можно сделать камеру следящей за кубиками
> увеличить angular_damp, чтобы кубики не катились слишком
Пробовали, не понравилось, ненатурально смотрится.
>физический движок не детерминированный, тот же самый бросок может выдать другой результат.
Говорю, лень проверять было. Могу сказать, что когда не делал рандомный поворот в начале, кубик чаще падал одним значением, видимо это потому, что грани плоские и шаг угла между ними довольно большой, что сильно округляет мелкие погрешности.
>а затем сравнивать глобальные координаты в поисках наиболее высоко расположенной ноды.
Тут наверное ты прав. Не уверен что это всегда работает в 3д для скажеим 20-гранника, но с д6 проблем не должно быть.
Godot Editor 4.1.1 на Android неигрюзабелен. Постоянно какие-то рандомные проблемы с виртуальной клавиатурой Gboard при наборе кода. Намного хуже чем в любых других редакторах текста/кода что я пробовал. Я понимаю, что это не совсем проблема Godot, но другие приложения на Android как-то справляются с виртуальными клавиатурами и Godot Editor должен показывать "как надо" всем играм на Godot. Алсо, по-моему, Gboard самая популярная клавиатура - 5 миллиардов скачиваний. Если уж делают редактор на андроид, должны тестировать эту клаву, не? Я мог бы подключить к телефону физическую клавиатуру, но я скачал редактор на телефон не для таких извращений... Они что-то говорили про планшеты и типа "ноутбуки" на андроид, но кто их реально использует? Основная аудитория на смартфонах же. Ну да, GUI адаптировали получше, но без адекватной поддержки виртуальной клавиатуры редактор кода Godot теряет смысл.
Алсо, кто-нибудь знает, как отследить события возникновения клавиатуры на экране и её скрытия? Вот у меня LineEdit, под ним простой Control, я знаю функцию DisplayServer.virtual_keyboard_get_height(), но когда я должен к ней обращаться? Она 0 мне выдаёт.
> Алсо, кто-нибудь знает, как отследить события возникновения клавиатуры на экране и её скрытия?
Набросай проект, который тупо выводит события на экран, закинь на мобилу и там всё что нужно выпиши.
> Постоянно какие-то рандомные проблемы с виртуальной клавиатурой Gboard при наборе кода.
Тут надо делать ишью. Если ещё нет. Ну и ждать ебилдов.
Откуда инфа, что это баг годота, а не. GBoard? Ты уже написал авторам GBoard об их проблеме?
>используется в годоте
https://docs.godotengine.org/en/stable/classes/class_randomnumbergenerator.html
>без графония
>это же совершенно другая задача
>лабораторная работа
@ >>896420
>Т.е. никакого виртуального стола, моделька просто крутится и выдает ченть рандомное.
>Да, этот вариант тоже ок, я чет сразу не подумал, что можно не усложнять
Э??? Ну ок так ок...
>тупо выводит события
Я думал, кто-нибудь уже делал такое.
>Тут надо делать ишью.
Да ладно, мне это не особо нужно...
>>896438
>Откуда инфа, что это баг
В нескольких разных редакторах я нажимаю enter и редакторы добавляют перевод строки, а Godot - нет. Или добавляет, но лишь в некоторых случаях.
В нескольких разных редакторах я могу выделять фрагмент текста движением курсора, но в Godot курсор вообще не реагирует на эти кнопки. Как-то удалось что-то выделить, но скопировалась вся строка и только через выпадающее меню Godot.
И ещё что-то... забыл, но это не важно.
У Android своя инфраструктура, Godot в ней гость и должен понимать язык, на котором общаются приложения. Если Godot чего-то не понимает или не сообщает, это проблема Godot. Я не уверен, можно ли полностью эмулировать нативные элементы GUI, но для многих игр нужны хотя бы базовые поля ввода, нормально работающие с виртуальной клавиатурой.
> Я думал, кто-нибудь уже делал такое.
Это простая вещь в 3,5 строки кода. Её делали многие. Ну я точно делал. Но зачем публиковать 3,5 строчки кода, не нужные никому, даже мне (потому что я уже посмотрел, что мне надо и двинулся дальше).
var vpered = "vpered"
var vzad = "vzad"
rich.text = vpered.append(rich.text)
rich.text = rich.text.append(vzad)
В чём я неправ?
https://www.youtube.com/watch?v=ahkVcxJx0sc
Вот тут довольно подробно есть об этом.
ИМХО лучше таки взять бушный айфон и бушный аймак, чем вот так пердолиться.
>$130 баксов ежегодно просто за право публиковаться
Кекус. Неудивительно что они самая дорогая компания в мире. У гугла 25 за пожизненное.
Но в целом полезная инфа. Спасибо.
Ты в Европе? Надо сначала оплатить
С помощью гибкой среды разработки Adobe AIR можно создать новый экземпляр графического интерфейса iOS на базе ОС Windows. Хотя технически Adobe AIR не является эмулятором, он позволяет разработчикам оценить работу приложений iOS, не используя при этом устройство Apple.
>Э??? Ну ок так ок...
Отправлять на вывод два рандомных числа и сделать то, что описал я - разные задачи, да.
Практика показала, что не мог. Не смог.
Нет. Отличный движок для гейм джамов как раз из-за наиболее легкого веб-экспорта. И растет с каждым годом.
В 3-ке быстро, в 4-ке не очень.
Читы на годот скачать
В макабе какая нибудь регулярка которая ожидает три буквы наподобие .con
Без фотки с жабо - нещитово
Ушло в шапку. Изменения уже видны.
>Хочу получить ось
Ты имеешь в виду Input.get_axis()?
>Мышь какими то другими способами ось передает?
Ни клавиатура, ни мышь никакие оси не передают.
"Оси" хардварно есть только у геймпадов, рулей и других подобных игровых устройств с аналоговыми элементами управления. У геймпадов обычно по две оси на стик плюс может быть по одной оси на курки, но не обязательно. Они обычно имеют промежуточные значения от 0 до 1 или от -1 до 1.
Если ты делаешь игру с управлением на WASD и хочешь поддерживать стик геймпада, тебе выгоднее всего абстрагироваться от железа, представив, что WASD - это такие же две оси, только они имеют всего 3 значения на каждой: -1, 0 и 1. Вот Input.get_axis() как раз и является этой абстракцией над железом.
Как это работает? Клавиатура отправляет отдельный сигнал нажатия клавиши и отпускания клавиши. Поэтому мы почти всегда точно знаем, какая клавиша сейчас зажата. Если игрок зажимает W, то мы можем сказать, что это 1 по вертикальной шкале. Если он зажимает S, то это -1. Если обе клавиши зажаты или обе отпущены, то это 0. Такая схема позволяет эмулировать оси геймпада клавишами.
Механически, стик геймпада - это переменный резистор, он всегда находится в каком-то положении от 0 (нет сопротивления) до 1 (полное сопротивление), поэтому геймпад всегда знает точное положение стика/оси. Простые кнопки на клавиатуре, геймпаде и мыши - это замыкание и размыкание цепи, поэтому мы точно знаем, когда кнопка зажата или отпущена, но у неё нет никаких промежуточных значений. А вот у колёсика мыши вообще другой сенсор: там (вроде бы) инфракрасный светодиод просвечивает через дырочки колёсика на фоторезистор, и когда ты прокручиваешь колёсико, каждый щелчок означает прохождение одного окошка. Мышь посылает сигнал "колёсико вверх" или "колёсико вниз", но это щелчки, а не зажатие или отпускание клавиши. Т.е. щелчки колёсика никогда не бывают "зажаты", а поэтому из них невозможно сделать виртуальную "ось".
>получить ось чтобы изменять зум камеры потом
Ты хочешь изменять зум камеры аналоговым элементом управления типа стика геймпада или руля? Нет? Если нет, тогда забудь про оси.
>Хочу получить ось
Ты имеешь в виду Input.get_axis()?
>Мышь какими то другими способами ось передает?
Ни клавиатура, ни мышь никакие оси не передают.
"Оси" хардварно есть только у геймпадов, рулей и других подобных игровых устройств с аналоговыми элементами управления. У геймпадов обычно по две оси на стик плюс может быть по одной оси на курки, но не обязательно. Они обычно имеют промежуточные значения от 0 до 1 или от -1 до 1.
Если ты делаешь игру с управлением на WASD и хочешь поддерживать стик геймпада, тебе выгоднее всего абстрагироваться от железа, представив, что WASD - это такие же две оси, только они имеют всего 3 значения на каждой: -1, 0 и 1. Вот Input.get_axis() как раз и является этой абстракцией над железом.
Как это работает? Клавиатура отправляет отдельный сигнал нажатия клавиши и отпускания клавиши. Поэтому мы почти всегда точно знаем, какая клавиша сейчас зажата. Если игрок зажимает W, то мы можем сказать, что это 1 по вертикальной шкале. Если он зажимает S, то это -1. Если обе клавиши зажаты или обе отпущены, то это 0. Такая схема позволяет эмулировать оси геймпада клавишами.
Механически, стик геймпада - это переменный резистор, он всегда находится в каком-то положении от 0 (нет сопротивления) до 1 (полное сопротивление), поэтому геймпад всегда знает точное положение стика/оси. Простые кнопки на клавиатуре, геймпаде и мыши - это замыкание и размыкание цепи, поэтому мы точно знаем, когда кнопка зажата или отпущена, но у неё нет никаких промежуточных значений. А вот у колёсика мыши вообще другой сенсор: там (вроде бы) инфракрасный светодиод просвечивает через дырочки колёсика на фоторезистор, и когда ты прокручиваешь колёсико, каждый щелчок означает прохождение одного окошка. Мышь посылает сигнал "колёсико вверх" или "колёсико вниз", но это щелчки, а не зажатие или отпускание клавиши. Т.е. щелчки колёсика никогда не бывают "зажаты", а поэтому из них невозможно сделать виртуальную "ось".
>получить ось чтобы изменять зум камеры потом
Ты хочешь изменять зум камеры аналоговым элементом управления типа стика геймпада или руля? Нет? Если нет, тогда забудь про оси.
ну так-то 13-19% это дохуя в целом
Можно на английском, но только что бы инфа была чётко и понятно структурирована, всё было последовательно, и даже долбоёб в итоге понял. На крайняк через переводчик прогоню.
А у тебя какие запросы? Что собрался делать? Я вот делаю копро-игрушку где даже анимаций хуй да нихуя. И по этому мне с графикой работать приходится очень мало. Соответственно мне больших гайдов не нужно, а вот если ты йобу пилишь, то тут уже и гайды другие.
Да 2d гаме с видом сверху, боёвка примерно буллет шот примерно как в айзеке, только чуть разнообразней. Алсо, анимашки я знаю уже как делать, я скрипты писать не могу научиться из-за хуй пойми как расписаной документации.
Да, спасибо. Уже допер что нажатие клавиши и прокрутка колеса относятся к разным состояниям
>скрипты писать не могу научиться
Читал уже?
https://docs.godotengine.org/en/stable/tutorials/scripting/index.html
https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/index.html
Если тебя сама концепция программирования смущает, то начинай с чего-то проще, типа игрушек для детей, где нужно выбрать кнопочки чтобы робот прошёл уровень и закрасил клеточки.
GDScript очень прост, но всё же требует базовые знания информатики хотя бы средней школы.
Да программирование то для меня дело нормальное, сам в вузике по данному направлению учусь. Я именно синтаксис и устройство годота нормально изучить не могу, потому что инфа либо раскидана сильно, либо устарела.
>Я именно синтаксис и устройство годота нормально изучить не могу
А это ты внимательно изучал?
https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/gdscript_basics.html
>инфа либо раскидана сильно, либо устарела
Устарело там совсем немного, в крайнем случае просто скачай 3.5/3.6 и попробуй кодить там, чисто чтобы разобраться в языке. Самый большой пласт изменений касательно переименования нод с добавлением суффикса "3D", а ещё теги export и onready теперь пишутся после @ и выделяются другим цветом. Всё остальное можно легко узнать из Class Reference, просто внимательно изучая необходимые тебе классы.
На счёт раскидывания информации не понимаю, что ты имеешь в виду. В документации всё чётко по полочкам разложено и заблудиться невозможно. Да, какая-то информация могла потеряться, но вся база по движку есть в стабильной ветке и она в актуальном состоянии (4.1). Твой основной справочник по Godot встроен в редактор и вызывается нажатием F1 или ctrl+клик по имени любого встроенного класса или функции.
Кстати за ссылки мерси боку. Что-то проглядел, самое главное они у меня уже открывались, но я блять не мог чуть-чуть вниз пролистать, постараюсь подучить. И ещё вопрос – как изменить размер видимой области так, что бы даже в полноэкранном режиме зрение не выходило за рамки. В эдиторе видимое пространство вроде обведено синеньким прямоугольником, но при фулл сайз всё равно всё идёт по пизде, и видно то, что я не хотел бы показывать.
>размер видимой области
У Camera2D?
>обведено синеньким прямоугольником
В 2D редакторе два прямоугольника:
1. Обозначает размер окна, заданный в настройках проекта на вкладке window. Может отличаться от реального разрешения в рантайме, если пользователь меняет размер (пропорции) окна или если игра запускается в полноэкранном режиме с размером/пропорциями, отличающимися от заданных в настройках.
2. Обозначает область, которую "видит" Camera2D, но в сущности это тот же прямоугольник, только смещённый на вектор позиции камеры.
>что бы даже в полноэкранном режиме зрение не выходило за рамки
>видно то, что я не хотел бы показывать
Это распространённая проблема у 2D игр на ПК, мобильные устройства и мультиплатформу. Ты не можешь заранее угадать, какой дисплей будет у игрока, и можешь даже не знать каких-то редких разрешений и соотношений сторон. Поэтому дизайн игры должен быть адаптивным, то есть подходить к разным дисплеям даже с абсурдными пропорциями (как сейчас модно - "смотровая щель танка" ultra wide или супер вытянутые лопаты смартфонов).
Далее ты в зависимости от игры выбираешь способ адаптивности. Можешь просто построить уровень больше, чем доступная игроку зона для исследований, а можешь добавить декоративные картинки-заслонки по бокам от основного окна игры как часто встречалось в старых играх (только там это было необходимо для уменьшения нагрузки на процессор - чтобы перерисовывать только небольшую часть экрана). Заслонки могут быть просто чёрными полосами, так на OLED экранах они будут невидимыми в темноте, как будто физически уменьшая экран (на LCD всё равно будет засветка).
Элементы GUI ты должен размещать не в пикселях, а в процентах от сторон экрана - тогда они будут адаптивно подгоняться под конкретный экран. Но это нужно всё равно тестировать с разными пропорциями экрана, чтобы элементы GUI не перекрывали друг друга и не уходили за рамки экрана (хотя последнее обычно бывает как раз из-за положения в пикселях, но и с процентами случается). Лучше всего адаптивному дизайну поучиться на примере HTML/CSS, там принципы в основном те же.
>размер видимой области
У Camera2D?
>обведено синеньким прямоугольником
В 2D редакторе два прямоугольника:
1. Обозначает размер окна, заданный в настройках проекта на вкладке window. Может отличаться от реального разрешения в рантайме, если пользователь меняет размер (пропорции) окна или если игра запускается в полноэкранном режиме с размером/пропорциями, отличающимися от заданных в настройках.
2. Обозначает область, которую "видит" Camera2D, но в сущности это тот же прямоугольник, только смещённый на вектор позиции камеры.
>что бы даже в полноэкранном режиме зрение не выходило за рамки
>видно то, что я не хотел бы показывать
Это распространённая проблема у 2D игр на ПК, мобильные устройства и мультиплатформу. Ты не можешь заранее угадать, какой дисплей будет у игрока, и можешь даже не знать каких-то редких разрешений и соотношений сторон. Поэтому дизайн игры должен быть адаптивным, то есть подходить к разным дисплеям даже с абсурдными пропорциями (как сейчас модно - "смотровая щель танка" ultra wide или супер вытянутые лопаты смартфонов).
Далее ты в зависимости от игры выбираешь способ адаптивности. Можешь просто построить уровень больше, чем доступная игроку зона для исследований, а можешь добавить декоративные картинки-заслонки по бокам от основного окна игры как часто встречалось в старых играх (только там это было необходимо для уменьшения нагрузки на процессор - чтобы перерисовывать только небольшую часть экрана). Заслонки могут быть просто чёрными полосами, так на OLED экранах они будут невидимыми в темноте, как будто физически уменьшая экран (на LCD всё равно будет засветка).
Элементы GUI ты должен размещать не в пикселях, а в процентах от сторон экрана - тогда они будут адаптивно подгоняться под конкретный экран. Но это нужно всё равно тестировать с разными пропорциями экрана, чтобы элементы GUI не перекрывали друг друга и не уходили за рамки экрана (хотя последнее обычно бывает как раз из-за положения в пикселях, но и с процентами случается). Лучше всего адаптивному дизайну поучиться на примере HTML/CSS, там принципы в основном те же.
Спасибо ещё раз, сегодня дома займусь этим.
Что и почему должно быть написано про перформанс?
>модули для визуальных новелл
Что ты под этим понимаешь?
А вообще, слабее тем, что дохлые (старая версия), но там вроде как что-то пилят и скоро вроде как допилят. А вообще нахуй не нужны. Годот изи движек и вн на нём сделать как два пальца обосцать, даже если начать прикручивать мини-игры.
>Что ты под этим понимаешь?
Ну диалоджик например. Проблема в том, что мне нужны и боевые сцены и диалоги, где можно делать множество выборов и иметь миллион переменных. В ренпи проблема с боевыми сценами, вот и хочу узнать про годот.
>Диложки
Через json изи. Я правда долго ебался, но мне нужно было чтоб текст по буквам выводился, а ещё замедления скорости его печатания когда мне это нужно.
>где можно делать множество выборов и иметь миллион переменных
Миллион переменных не проблема, а вот с выборами уже сложнее. У меня у самого выборы и систему я собрал немного геморную. В плане что автоматизации мало. Но если там покопаться, то наверняка можно сделать лучше.
Сделать прыжок на нужную строчку при выборе не проблема так-то, а вот переменную сменить тут уже отдельный менеджер писать (лёгкий и не большой так что писаться от страха не нужно). Корочь как бы годот заебись. Я сам с рпгма, вот там пизда была.
>боевые сцены
Смотря какие, но так-то изи.
Алсо там ещё плагины были на диалоговые системы, но некоторые старые из них. Да ещё и в плагине разбираться придётся. Мне лень было и я сам писал под себя весь код с нуля.
Звучит сложно, я не программист, я художник. Если б мне не приспичило боевых сцен добавить, я б с ренпи не слезал.
Я тоже не программист. Там не сложно, просто может звучит так. Когда разбираться начинаешь, понимаешь, что всё изи. Чтобы хоть как-то работало на годоте сделать легко.
А на ренпике боевые сцены. Я с ним не работал никогда, но там же питон? У меня тоже выбор стоял между гамаком, остаться на рпгм, юнити, годот.
Вот как раз ренпик и не взял потому что хочу геймплей, а на ренпике хз как, да ещё и при том, что опыта работы с ним нет.
Просто как бы придётся потратить время на изучение годота. Я от нуля и до написания диалоговой системы потратил 2 месяца. Если что-то непонятно, то спрашивай в треде. В большинстве случаев помогут или подскажут куда копать чтоб всё понять.
Какие же они ебанутые, пиздец просто.
>А на ренпике боевые сцены.
По ренпи миллиарды доков есть, я это делал все буквально вообще без знаний, просто гуглил как что-то сделать и делал по примеру. А чтоб сделать боевые сцены на ренпи это нужно реально кодером быть и самому с нуля все делать.
Зачем с нуля, ренпи это пугейм и там все есть для этого
>я не программист, я художник
Ну смотри, чтобы научиться более-менее приемлимо рисовать, нужно лет 5 детской художественной школы, после неё лет 5 художественной академии, а потом ещё лет десять аниме рисовать на компьютере, ибо в академии совсем не тому учат. А в кодинг можно вкатиться за месяц и строчить огромные портянки кода, которые, внезапно, даже как-то работают.
Короче, если рисунок ты вымучиваешь потом и кровью, а выходит всё равно кривое говно на которое все пальцем тыкают и смеются, то в код ты можешь на расслабоне навалить кучу и тебе за это 6000$ в месяц на патроне донатить будут.
Так что не бойся кодинга.
База. Про 6к перегнул наверн, но так-то всё верно. Рисование - это пиздец. Нужно знать кучу хуйни. Кучу комплексной хуйни. А код просто пишешь как макака. Даже если там спагетина, то пока она работает всем похуй.
Да не, рисовать может научиться каждый. Главное не трогать вонючего лумиса и рисовать каждый день.
Ну знаешь следя за всякими порноделами с рисовкой, то они за пару лет научаються рисовать мультяшно( а больше и не надо)
>они за пару лет научаються рисовать мультяшно
Сходи в /pa/ и охуеей от того как люди мучаются. Там за "пару лет" охуевают никакой геймдев потом не нужен. Да и проблема ещё в чём. Ни у кого нет лишних пары лет на "вроде как бы я научусь рисовать" (только если ты не пездюк с огромным количеством свободного времени). Рисование - это пизда. Тебе любой так скажет кто учился рисовать с нуля в сознательном возрасте.
Ну а
>рисовать мультяшно( а больше и не надо)
Так-то да, но смотря что за игру ты делаешь и что ты подразумеваешь под "мультяшно" (а то есть такие, кто думает, что манямэ рисовать легко например). Даже с плохим графеном можно вытащить игру, но когда графен хорош, сделать это намного легче.
Ты случаем не амбассадор скиллбокса или другой подобной хуйни?
пиратки, которые ломануться в интернет и расскажут об установке, тоже будут учитываться в кошелек разработчика?))0
Да они сами могут накатить твою игру на мильён виртуалок, а потом сказать "плоти"
Судя по определению не исключено. Это полюбас идея Рикителло.
По сравнению с 3? Ну очевидно потому что это МАЖОРНЫЙ релиз.
мимо юнити клоун
Работал с юнькой/годотом/нереалом - в перекатах между ними сложности не вижу, просто чуть другие термины, суть везде плюс-минус одна и та же
Если можно правдиво и развернуто.
Если хуево сделаешь, то лагает, нормально делай нормально будет. Чуда ждать не надо, сцены небольшие, графон уровня 2010 года. Все что дальше уже потребует тебя руками поработать
бывший юнити клоун.
Там в глубине есть демо проект специально для годота, надо будет поразбираться, но в целом всё довольно просто
В годоте нет ecs, есть несколько ассетов, которые дают писать/разрабатывать в стиле екц, но без плюшек производительности, только сама концепция систем/сущностей (что можно и на нодах сдедать)
Есть экспериментальный модуль под 4ку но не знаю в каком он состоянии https://github.com/GodotECS/godex
(Автор кажется свалил на анрил, судя по его ютубканалу )
Продвинутые пользователи подключают любые либы C# или C++. Я пользуюсь flecs, кто то еще писал про entt. Но это все равно будет не встроено в ядро.
жди, когда Bevy допилят, перекатишься потом туда)
Ecs в любом случае роляет только от 10000+ юнитов, так что не важно. У тебя и в обычной игре на нодах не будет проблем. Тормозят то обычно постпроцесс эффекты, и физика 100 объектов если взаимодействуют все со всеми.
В смысле?
Честно говоря, не помню подробностей. Давно тестил. Просто спамил RigidBody до предела.
Также я проверял, можно VehicleBody наспамить как минимум 128, задать им подруливающий автопилот и ФПС будет около сотни.
Один RigidBody может спокойно иметь около тысячи CollisionShape, если нужно собирать большой физический объект из деталек.
С одной стороны, это сильно слабее PhysX с его многоядерностью и CUDA, но с другой, имеющегося вполне хватит на любые игры кроме грандиозных опенворлд физических песочниц.
Анон, речь про все со всеми, как в гиперказуалках когда шарики или кирпичики сыплются или домики в стиралке. А уровень игры типа пфазмафобии конечно можно сделать
>В чем профит гдскрипта
https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/gdscript_advanced.html
>GDScript is a Dynamically Typed language. As such, its main advantages are that:
>The language is easy to get started with.
>Most code can be written and changed quickly and without hassle.
>Less code written means less errors & mistakes to fix.
>The code is easy to read (little clutter).
>No compilation is required to test.
>Runtime is tiny.
>It has duck-typing and polymorphism by nature.
>Что я потеряю
Да ты хоть попробуй...
Итерации разработки быстрее. Если честно то я плюсовик (и шарповик в прошлом) и так впадлу ждать компиляции
Твое описание звучит как "если мы что-то не предусмотрели - ты сдохнешь пытаясь это реализовать".
Это опенсорс
Если что то не предусмотрели, просто пишешь соответствующую с++ функцию и пробрасываешь ее видимость в гдскрипт
Позволяет фокусироваться на деланье игры, а не на коде. Вот реально, просто и без задней мысли и выебонов, просто берешь и делаешь.
На гдскрипте написаны ассеты zylann hterrain и hungryproton scatter это довольно большие плагины по объему гдскрипта, можно оценить и архитектуру к которой приводят ограничения языка. А, еще редактор Pixelorama
Игр опенсорсных тоже много, но они в основном мелкие с джемов
Вот вы говорите опен сорс опер морс. Тут прям полное отсутствие фин. ответственности за использование движка. Меня вообще кто-нибудь как-нибудь может на шекели нагреть при его использовании?
> правдиво и развернуто
Вот тебе статья Автроа Годота Хуана Линецкого в переводе. Правдивее и развёрнутее никто кроме Автора не скажет.
https://dzen.ru/a/Y8ZA8PN5FlcYHsUh
Понял, спасибо
Мит лицензия означает что ты должен указать авторов движка в кредитсах, о шекелях речь не идет
Еще само лого может быть под лицензтей, не помню. Но его все спокойно редактирубт и стилизуют
Ты можешь даже продавать сам годот.
Ты не обязан раскрывать исходники своей игры, это не гпл
Ассеты тоже проверяй на лицензию. Мит, бсд то же самое. GPL лучше не тиогай, он обязывает всю твою игру сделать гпл
А мог бы просто ссылку на оригинал кинуть.
https://godotengine.org/article/whats-missing-in-godot-for-aaa/
> Что я потеряю если буду писать только на шарпах, там будут костыли?
Костыли минимальны, выше аноны уже описали.
1. Компиляция: на мощном пека ты её не заметишь.
2. Слабая поддержка встроенным редактором: ты юзер райдера - тебе похуй. Просто открываешь проект в райдере, дописываешь код, сохраняешься, альттабаешся в годот, запускаешь.
3. В трёшке были проблемы с добавлением коллбэков в код через инспектор, они добавлялись в конец файла, после закрывающей скобки } класса. Приходилось их вручную переносить куда следует. Не знаю, пофиксили ли в четвёрке.
4. Отсутствие нативизации искаропки. Хочешь нативизировать свою либу - юзай сторонние решения, но не факт, что собранный проект сможет с нативизированным кодом работать.
5. Ограниченное число платформ. Фактически шарпокод работает без проблем только на десктопных виндах и линуксах. С андроидом наебёшся, с иосом вообще даже притрагиваться страшно.
Ну это из того, что навскидку припомнил.
6. В трёшке использовалось моно. В четвёрке перешли таки на дотнет современный.
>если мы что-то не предусмотрели - ты сдохнешь пытаясь это реализовать
Почему? Из-за строчки "runtime is tiny"?
Во, глянь этот язык:
https://en.wikipedia.org/wiki/Forth_(programming_language)
Там интерпретатор умещается в старый чип BIOS на материнской плате. Но возможности безграничны.
Дико заебался с этим tilesetter. Пытаюсь сделать тайлсет для topdown игры, но чертова программа ломает углы. ЧЯДНТ?
Сам бы уже давно запилил по туториалам.
>>898266
>с этим tilesetter
Какое отношение он имеет к Godot? Тебе сюда:
https://docs.godotengine.org/en/stable/tutorials/2d/using_tilemaps.html
https://www.youtube.com/watch?v=qmjbRiekW_M
Мало что можно оценить, посмотри на Cruelty Squad как пример шикарного иммерсив сима на годоте
> посмотри на Cruelty Squad как пример шикарного иммерсив сима на годоте
Да-да, я от него и вдохновился и захотел сделать свою игру. Ну правда я конкретно эту игрушку уже давно держал как идею в голове, да только движка подходящего не находил. Юнити - сложно, потому что финансовые обязанности и нужно мощчное жылеза, Анрил - тоже сложно, потому что там ебанутый интерфейс и тоже нужно мощчное жылеза... Я сам вообще с рпг мейкера вкатываюсь в годот и пока мне очень нравится он своим гд скриптом который тебе мозги не ебёт при каждом неудобном случае. Мне бы вот ещё модельки научиться делать и рисовать нормально(я так-то уже приемлемо рисую, но для такого проекта как у меня мне нужно оняме хоть какое-то выдавать) и вот тогда ваще пошла бы работа. А так я пока развиваю свои навыки и в том и в сём параллельно игрушку делаю. Уооот таааак вот, да.
Бля я чё-то как дебил тут с темы на тему перескакиваю... ЕБать.
Короче я чё сказать-то хотел... Я только начал, во! Так шо пожелайте удачи братья!
Пасиба! У меня есть на гитхабе вот такая штучка, я там когда что-то сделал меняю их. Щас уже сделано нормально работающее передвижение, главное меню с настройками видео(разрешение экрана, фуллскрин/не фуллскрин). Вооооот. Но ещё делается - оружие(это будет глок, уже есть моделька); модель главной героини(скорее всего ограничусь просто руками, ну типа viewmodel от первого лица). Уоооооот.
> Кубики рандомные сможешь запилить?
На блять!
>var qubique_side = randi() % 5 +1
>var qubique_texture = load("res://qubogame/assets/images/qubicue_side_%s.png" % qubique_side)
Денги плоти!
>Играем за аниме-ангелицу
>от первого лица
Ну ясно.
>>898384
>гдскрипт мозги не ебёт при каждом неудобном случае
Ну это да, гдскрипт очень удобный. Некрасивый, франкенштейнистый, с питоноотступами, но зато очень лёгкий в освоении и подходящий для быстрой разработки.
Шо я хочу тебе сказать. Главное не пытайся сразу пилить игру мечты. Помни про первый блин. Пока ты учишься, твоё код всё равно будет говном, а к моменту, когда научишься, окажется, что слишком много надо переписывать с нуля. Так что не намечай слишком масштабный проект, сделай какую-то минимальную демку и выпусти её как можно скорее.
На личном опыте говорю.
После шарпа и плюсов действительно кажется чем-то инопланетным, но стоит хотя бы месяц без остановки посидеть и реально подрочить, тебе родной шарп будет казаться нереальным сблевом.
Ригиды все же не все со всеми, там и ускоряющие структуры типа bvh деревьев и прочие костыли. Все со всеми это типичный n-body который вообще нигде не способен работать, потому приходится костылить и резать межвзаимодействия.
Думаю куда валить с юнити. Пилю проекты исключительно в 3д.
Скажите, чего вам не хватает в годоте? Каких фич в нем недостаёт?
Есть ли там нормальный магаз ассетов? Есть ли шейдер травы, целл-шейдинг для анимешных персов? Как дела с модной нынче фигнёй типа XeSS, DLSS, FSR? Как там работает физика? Есть ли таймстеп для физики, типа чтобы физика работала всегда 50 раз в секунду, вне зависимости от ФПСов?
Некоторые вещи завязаны на внутренние классы юнити, так что надо будет внимательно переписывать
Статья по старой версии, но представление получишь https://docs.godotengine.org/en/3.1/getting_started/editor/unity_to_godot.html
Entities: Nodes
Components: Nodes
Scene settings: Nodes
Navigation: Nodes
Lightmaps: Nodes
Viewport: Nodes
Behaviours: Node+Script
Prefab: Scenes
Scene composing: Scenes
Scriptable objs: Resources
В 3д мне сейчас не хватает переключения smooth на flat shading на уровне движка. Везде пишут что это надо делать на уровне модели, но хуй там, некоторые 3д рендеры, особенно на JS, умеют это переключать прямо внутри себя.
Зделой мне плагин.
а как со скелетной анимацией обстоит вопрос? Есть animation marker типа когда анимация доходит до опр. точки, то кидается фидбек в скрипт и скрипт что то делает. Например анимация стрельбы и ты ставишь маркер на момент когда типа выстрел, поднимается ивент в скрипте и в ивенте ты уже кодом спавнишь там пулю, гильзу и тд?
> Да лень мне
Мне тоже.
> не работает
Дак ты там форсунку подкрути, масло поменяй, свечи проверь и трамблёр.
>Мне тоже.
А если бесплатно?
>Дак ты там форсунку подкрути, масло поменяй, свечи проверь и трамблёр.
Может еще прокладку поменять?
Можно просто в вершинном шейдере нормали не интерполировать, и будет плоский шейдинг.
Очень просто. По-моему даже много шаблонов готовых на топдауны есть
Сцену можно инстанцировать и добавлять, да. В юнити даже похожую тему делали, нестед префаб.
Есть в анимейшн плеере вариант создать трек Call Method.
В годоте ссылковые, емнип, только массмвы и словари.
У Array.duplicate есть параметр deep copy
Если у тебя внутри твоего массива есть другие массивы, то поверхностное копирование их не тронет (все твои новые дубликаты будут ссылаться на одни и те же данные), а глубокое тоже сделает уникальными
Скрипт - это ресурс, он в одном экземпляре и на него ссылка.
Компоненты как ноды, ну это нормально, если у тебя не 10000. До оптимизаций сначала делай бенчмарки, если увидишь затык, разберись, может там простая ошибка возникла
Но если ты только разбираешься с движком, начни с чего то попроще. Так же можно подумать о пулах объектов.
Не пытайся бездумно копировать подходы из других движков, это же не клон чего-то.
Проблема XY? Проблема XY!
Давай ты начнёшь сначала. Какую проблему X ты решаешь через сохранение состояний кнопок в левом массиве?
А ты думал, в сказку попал?
>состояние измениться у кнопки, то оно и при обращении в array2 измениться, а мне нужно сохранить состояние для референса
Зачем тебе это нужно? Для какого "референса"?
>пустой, но в него я хочу сохранить состояние кнопки. Как мне это сделать?
Ну, для начала нужно изменить размер массива:
>states.resize(btns.size())
Потом можно сделать так:
>for j in btns.size(): states[j] = btns[j].button_pressed
Это сохранит текущее состояние (нажата или нет) всех кнопок в твоём массиве btns.
>Пилю проекты исключительно в 3д.
>Скажите, чего вам не хватает в годоте? Каких фич в нем недостаёт?
Скорее всего тебе будет недоставать встроенного ландшафта, но есть сторонние плагины и вроде бы идёт работа по разработке официального.
>Есть ли там нормальный магаз ассетов?
Да, есть, можно прямо из редактора качать. Но в нём пока что нет платных ассетов, т.е. всё бесплатное и это влияет на качество ассетов. Платные ассеты существуют, но их нужно покупать где-то в другом месте - itch.io, gumroad и т.д. Добавить своё говно в официальный магазин достаточно легко. Есть ещё сторонний магазин шейдеров...
>Есть ли шейдер травы, целл-шейдинг для анимешных персов?
Встроенный cell shading очень простой. Есть куча сторонних шейдеров, см. https://godotshaders.com/
Говорят, что для качественной обводки нужен доступ к какому-то буферу, которого в шейдерах Godot пока нет или не было в 3.x, но я не шарю.
>Как дела с модной нынче фигнёй типа XeSS, DLSS, FSR?
Понятия не имею, что это, смотри сам:
https://docs.godotengine.org/en/stable/classes/class_environment.html
https://docs.godotengine.org/en/stable/tutorials/3d/index.html#rendering
https://docs.godotengine.org/en/stable/tutorials/3d/environment_and_post_processing.html
>Как там работает физика?
Приемлемо для большинства игр. В 3.x из коробки были Godot Physics и Bullet Physics, Bullet получше, надёжнее и шустрее. В 4.0 выкинули Bullet из сборок, остался только Godot Physics, но ему добавили много багфиксов и оптимизаций, так что вроде норм. Godot 4.0 позволяет подключить любой физический движок без перекомпиляции ядра, но для этого нужно писать специальный адаптер на C++ (компилировать физический движок отдельной dll). Ходят какие-то слухи про переход на какой-то другой физический движок для 3D, но он имеет больше ограничений и недоработок, так что вряд ли в ближайшее время что-то изменится. Важный момент: Godot Physics 3D и Godot Physics 2D - разные движки, их можно использовать параллельно и друг с другом они никак не взаимодействуют, так что баги одного к другому не относятся и это нужно учитывать при поиске в интернете или создании багрепортов.
>Есть ли таймстеп для физики, типа чтобы физика работала всегда 50 раз в секунду, вне зависимости от ФПСов?
Да, разумеется. Можно настраивать в настройках проекта, вводить любое число.
Метод _physics_process - это FixedUpdate из Unity.
В целом с физикой больше проблем, чем у NVIDIA PhysX, но это вполне ожидаемо, всё-таки NVIDIA в своё время выкупила производителей отдельного физического ускорителя и встроила их чипы в свои видеокарты, так что у них аппаратное преимущество.
>Пилю проекты исключительно в 3д.
>Скажите, чего вам не хватает в годоте? Каких фич в нем недостаёт?
Скорее всего тебе будет недоставать встроенного ландшафта, но есть сторонние плагины и вроде бы идёт работа по разработке официального.
>Есть ли там нормальный магаз ассетов?
Да, есть, можно прямо из редактора качать. Но в нём пока что нет платных ассетов, т.е. всё бесплатное и это влияет на качество ассетов. Платные ассеты существуют, но их нужно покупать где-то в другом месте - itch.io, gumroad и т.д. Добавить своё говно в официальный магазин достаточно легко. Есть ещё сторонний магазин шейдеров...
>Есть ли шейдер травы, целл-шейдинг для анимешных персов?
Встроенный cell shading очень простой. Есть куча сторонних шейдеров, см. https://godotshaders.com/
Говорят, что для качественной обводки нужен доступ к какому-то буферу, которого в шейдерах Godot пока нет или не было в 3.x, но я не шарю.
>Как дела с модной нынче фигнёй типа XeSS, DLSS, FSR?
Понятия не имею, что это, смотри сам:
https://docs.godotengine.org/en/stable/classes/class_environment.html
https://docs.godotengine.org/en/stable/tutorials/3d/index.html#rendering
https://docs.godotengine.org/en/stable/tutorials/3d/environment_and_post_processing.html
>Как там работает физика?
Приемлемо для большинства игр. В 3.x из коробки были Godot Physics и Bullet Physics, Bullet получше, надёжнее и шустрее. В 4.0 выкинули Bullet из сборок, остался только Godot Physics, но ему добавили много багфиксов и оптимизаций, так что вроде норм. Godot 4.0 позволяет подключить любой физический движок без перекомпиляции ядра, но для этого нужно писать специальный адаптер на C++ (компилировать физический движок отдельной dll). Ходят какие-то слухи про переход на какой-то другой физический движок для 3D, но он имеет больше ограничений и недоработок, так что вряд ли в ближайшее время что-то изменится. Важный момент: Godot Physics 3D и Godot Physics 2D - разные движки, их можно использовать параллельно и друг с другом они никак не взаимодействуют, так что баги одного к другому не относятся и это нужно учитывать при поиске в интернете или создании багрепортов.
>Есть ли таймстеп для физики, типа чтобы физика работала всегда 50 раз в секунду, вне зависимости от ФПСов?
Да, разумеется. Можно настраивать в настройках проекта, вводить любое число.
Метод _physics_process - это FixedUpdate из Unity.
В целом с физикой больше проблем, чем у NVIDIA PhysX, но это вполне ожидаемо, всё-таки NVIDIA в своё время выкупила производителей отдельного физического ускорителя и встроила их чипы в свои видеокарты, так что у них аппаратное преимущество.
Я не он, но зачем писать "аниме", если персонажа на экране даже не видно кроме аватарки в углу?
>Есть хоть какой-то адекватный аналог геймобджектов?
Node в Godot == GameObject в Unity.
>Срать объектами на каждый компонент это пиздец как не правильно.
По-твоему, компоненты в Unity - это не ООП объекты? Лол, а что это тогда? Unity такое же ООП, как и везде.
Алсо, часть "компонентов" в Godot - это Resource.
https://docs.godotengine.org/en/stable/tutorials/scripting/resources.html
>Особенно учитывая тот факт, что каждый из них ещё и имя тянет.
Чем тебе имя не нравится? В Unity ты тоже компоненты по имени запрашиваешь, нет?
В Godot 4.x завезли новый тип строк:
https://docs.godotengine.org/en/stable/classes/class_stringname.html
Они отличаются от String оптимизациями. Как раз предназначены для имён, с которыми нужно часто делать сравнения, но не нужны другие операции.
Двачую написанное
> Пизда нахуй
Вот с этого момента поподробнее и на примерах. В чём конкретно resource objects годота тебя не устраивают по сравнению со scriptable objects инстал-фи-движка?
Пиши более развернуто о своей проблеме, а то выглядит как будто ты там ящик на ногу уронил.
>Срать объектами на каждый компонент это пиздец как не правильно.
Это норма разработки годота. Привыкай, если хочешь наворачивать годот. Созда какой-нибудь объект из тысячи компонентов - считай всё, конец.
Представь только какое дерево будет у тебя в игре, охуеешь просто. А представь какие пропуки будут когда по этому дереву будут проходы!
Безыгорник, спок. Любая анимировпнная моделька человечка так и устроена - там куча узлов, пятка, колено, бедро, пальцы, плечо, локоть, кисть, оружие, и все шикарно работает влет.
>Созда какой-нибудь объект из тысячи компонентов - считай всё, конец.
KISS. Keep it simple, stupid.
>Представь только какое дерево будет у тебя в игре
Ты можешь сделать компоненты в виде Resource, чтобы добавлять их к ноде в стиле юнити: на правой панельке инспектора нод.
>когда по этому дереву будут проходы
Дерево всегда справлялось с десятками тысяч нод (на моём 2007 процессоре тормозит только 100к+ нод), плюс недавно были оптимизации, плюс готовятся оптимизации для многопоточной работы с деревом, так что всё будет норм.
Если твои компоненты выполнены в виде Resource, то дерево их никогда не обходит - ты сам к ним из своего кода обращаешься когда тебе это нужно.
Также каждой ноде можно индивидуально отключить обработчики событий. Внутре всё оптимизировано, так что выключенные ноды ничего не грузят.
Как распознать страшилки движкосрачерских шизов?
Они обращаются к эмоциям, а не фактам.
Нужно что-то представить, вообразить, или примерно почуствовать, и испугаться этого.
Вместо конкретнвх цифр - общие слова, чтобы были тысячи, тьма, ужасы.
Вместо того, чтобы просто предоставить проект с бенчмарком.
>просто предоставить проект с бенчмарком
Так ведь они никогда Godot не скачивали, а если и скачивали - не смогли разобраться с православным опенсурсным GUI, ведь они даже Blender боятся.
>тормозит только 100к+ нод
Ладно, я точно не помню, сколько я там наизмерял, давно это было. В общем-то проблема была в том, что моя видеокарта не тянет >10к дроуколлов, поэтому 10к мешей упирались в потолок по видеокарте. Я попробовал спамить пустые ноды и там вышли сотни тысяч нод без ощутимых проблем. Может быть, даже миллион? Не помню точно. Естественно, в реальном проекте результат будет зависеть от того, что именно находится в этих нодах и как оно работает. Основная проблема тут не в скорости работы, а в том, что ноды несут много информации и поэтому повышают требования по памяти. Но любые действия возможно делать через прямые обращения к API движка, полностью игнорируя дерево сцены. Можно даже написать свой собственный MainLoop, в котором не будет никакого дерева сцены, если вы его так боитесь, лол.
>Вместо того, чтобы просто предоставить проект с бенчмарком.
Основные проблемы игровых движков вылезают в эдж кейзах, когда туманное говно начинает срать тебе в RAM/VRAM или жрать мощности, а ты толком не понимаешь это твое говно, плагина/библиотеки или движок сам под себя серит.
Бенчи на тестовых локациях не делают примерно нихуя. Бенчами тебя и Фалька накормит, тоже жрать будешь?
Спасибо за то что базу накидал. Буду значит проект хуярить как игры на консоли в нулевых, с мизерными локациями, туманом и выгрузкой всего что можно при первой возможности.
или как старфилд ахахаха
>Каждый персонаж это ну в среднем 200 объектов с разными узлами в годоте
Где ты такие жирные скелеты видел? Даже в порнухе не будет столько отдельных костей. А в толпе NPC у всех кроме игрока будет намного более простой скелет, ведь их толком не видно - никакие отдельные пальчики тебе не нужны.
>50 скелетов и всё
Опять же, ты много игр видел с 50-ю скелетами на одном экране? Игр про толпу по пальцам пересчитать можно, даже в GTA народу мало - трупы копов в GTA 5 деспавнятся прямо на глазах игрока, лол, и это находясь в тупике, куда больше двух человек одновременно зайти не могут. Что, RAGE 2 от Rockstar не тянет 50 скелетов?
>DOD системы
Я не уверен точно, нужно глянуть исходники, но я подозреваю, что скелет в Godot оптимизирован внутри. Ноды нужны только для редактора сцен - чтоб ты, ассетфлипер, примерно мог почувствовать, как твой скелет устроен. Опять же, можешь инициализировать скелет кодом, без добавления нод в дерево.
>10 фпс на 2060
У меня сотни ФПС на 750 Ti, обнови драйвера.
>Террайн? Вода?
Плагины ищи, ассетфлипер.
>Тени?
Нормальные тени, как у многих игр. Игрок всё равно отключит их, потому что тени только мешают геймплею, как и твои кусты с травой и водой. Ты же в игры играешь?
>20 одновременных врагов на экране?
>Не могу.
Очевидно skill issue, о чём тут ещё говорить?
>Теперь попробуй реальную игру сделать.
А ты можешь? Ах, извини, ты ж уже ответил:
>Не могу.
>>899016
>наёмный c++ инженер за миллион рублей/месяц
Пикрил же, ассетфлипушка.
>Игрок всё равно отключит их, потому что тени только мешают геймплею, как и твои кусты с травой и водой.
что
>туманное говно начинает срать тебе в RAM/VRAM или жрать мощности, а ты толком не понимаешь это твое говно, плагина/библиотеки или движок сам под себя серит.
В Godot ты всегда можешь зайти на гитхаб, найти проблему, пофиксить её (ведь ты скилловый программист, а не какой-то ассетфлипер позорный) и накатить обновление сам себе, а может даже и для других - не ради прибыли, а чтобы почесать своё ЧСВ крутого программиста.
Алсо, утечки в Godot редко бывают. Если сравнивать, Unity будет жрать память, пока сборщик мусора внезапно не выйдет из комы и не начнёт шерстить все гигабайты в поисках мусора, что выражается в диких тормозах, особенно если часть памяти ушло в своп на диске (поэтому тяжёлые Unity игры сильнее тормозят без SSD, они просто не способны экономить RAM). В Godot сборщик мусора подскакивает кабанчиком и убирает за тобой сразу, как только объект тебе не нужен, что ты даже не заметишь в большинстве случаев. Утечка с твоей стороны может быть только если ты сделал циклическую зависимость, из-за которой сборщику мусора не понять, какой из объектов тебе не нужен (т.е. он не шерстит все твои объекты каждые несколько минут в поиске недоступных из основного потока объектов). Но это легко заметить в собственном коде.
Да, нужно подстраивать твою игру под движок, под его ограничения.
В целом, как мне кажется, для годота должны подойти какие-то проекты с небольшим террайном (большой будет пропукивать, осторожнее) небольшим кол-вом врагов и сложной логикой скилов и всякого такого. Например можно ебануть файтинг с сотнями скиллов и несколькими персонажами, до десяти, идеально под архитектуру годота будет. Какие-то очень вложенные и сложные скилухи и вот это вот всё, чтобы утилизировать дерево годота полностью. Сложные магические умения, может? Хуй знает.
Если постараться то можно утизировать приемлемо, ориентируйся на небольшое кол-во очень разных игровых объектов и их разное поведение.
Ну и жди когда сделают движок для тебя!
>>899019
> Где ты такие жирные скелеты видел?
Обычные скелеты, по две-три дополнительных костей для правильной анимации идёт.
> Опять же, ты много игр видел с 50-ю скелетами на одном экране?
Да. В каждой второй нормальной игре столько. А ведь кроме скелетов есть ещё куча объектов.
> но я подозреваю, что скелет в Godot оптимизирован внутри
Нет.
> Нормальные тени, как у многих игр. Игрок всё равно отключит их,
Ясно. Тени не нужны потому что отключают. Охуенное оправдание.
Покажешь мне как снизить кол-во дравколов в годоте, не меняя кол-во объектов?
>и несколькими персонажами, до десяти,
В смысле одновременно на экране несколько персонажей.
>документация говорит хуй забить на пуллинг
Да, причину см. во втором абзаце тут >>899032
Если кратко, в Unity ты создаёшь 100к пуль и они все будут висеть в памяти, пока сборщик мусора не решит начать великую чистку всея памяти, разбираясь, какая из пуль тебе нужна, а какая нет (спойлер: тебе уже никакая не нужна, ты отстрелялся и сдох, а игра показывает главное меню). В Godot ты создаёшь 10 пуль и они сразу исчезают из памяти, сборщик мусора не ждёт рандомное время, пока пули захламляют память. По сравнению с Unity (C#), это распределяет нагрузку равномерно.
>действительно ли вообще нет разницы
Сам проверь. Могу сказать только, что я следил за счётчиком обьектов и он всегда колеблется на несколько единиц, то есть каждую секунду движок что-то создаёт и удаляет внутри.
> с небольшим террайном (большой будет пропукивать, осторожнее)
Вон там на ютубе чувак придумал хитрый террейн для годота, щас поищу видос. Там короче меш террейна специально сделанный в блендере, включающий в себя все ЛОДы, ездит за персонажем, а смещается при движении персонажа только позиция геометрического шейдера. Таким образом террейн бесконечен (как бесконечна генерация шума шейдером) у него есть ЛОДы, у него оптимизированный меш.
Хорошая шутка, но эта техника обычно нужна для шутеров, в которых каждая пуля - отдельный объект на экране: она создаётся, летит, детектит столкновение, вызывает обработчик столкновения и самоуничтожается, либо возвращается в пул. В остальных случаях эта техника бесполезна. Ну разве что какие-то мелкие фиговины спамить гиперказуалке.
> Если кратко, в Unity ты создаёшь 100к пуль и они все будут висеть в памяти
Не будут. Это копии одного объекта, в памяти будут только массив смещений и данных для каждой конкретной пули.
>>899046
> но эта техника обычно нужна для шутеров, в которых каждая пуля - отдельный объект на экране
Нет, в шуттерах нет пуль, есть только эффекты и данные этих эффектов. Все пули это просто инстанс, либо какой угодно другой батчинг.
Ебать конечно, разработкой реальных игр в этом треде не пахнет даже, лол
99% игр сделано не на екс, шизик.
> бла бла не существует, только эффекты
Ну они то святым духом в астрале место занимают, ба шиз?
> 99% игр сделано не на екс, шизик.
Причем тут екс, шизло? Когда ты уже выучишь ебаное программирование?
Батчинг в юнити есть и без екс. И объекты тоже создаются в батчах, даже если они доступны извне как объекты, это просто интерфейс.
> Ну они то святым духом в астрале место занимают, ба шиз?
Они не занимают места как целый объект, они занимают место на структуру в массиве. И в целом в юнити многие компоненты так внутри работают, примерно так и батчинг работает.
Без скелета и анимаций всё ок.
Думал что проблема, конкретно, в том скелете который я нахуевертил. Взял скелет с анимациями с Миксамо. С ним такая же хуйня.
Что делать?
Версия годота?
При импорте попробуй отключить ЛОДы
Морфинг/блендшейпы в модели есть?
Масштабы все правильные? Не 100х?
>Версия годота?
4.1.1.
Собственно самая последняя.
>Морфинг/блендшейпы в модели есть?
Хуй знает. Узнаю, проверю.
>Масштабы все правильные? Не 100х?
Да, масштабы правильные.
Алсо, рендер - Compatibility. Потому что делаю с ноута.
Это могло повлиять?
Убрал ЛОДы, не сработало. Но спасибо за наводку. Я вообще не знал о существовании такого меню.
>Убрал ЛОДы, не сработало
Реимпорт делал? Godot кэширует все импортируемые ресурсы во внутренних форматах, они хранятся где-то в папке ".godot". Я иногда встречал ситуацию, когда импортированные данные не обновляются, пока их вручную не удалишь. Алсо, некоторые ошибки помогает исправить перезагрузка редактора. Что ж поделаешь, не все ошибки легко отловить.
>Не будут
>нет пуль
Молодой человек, вас не спрашивают, есть в наших играх пули или нет. Разраб захотел - сделал, а тебя спрашивать никто не будет. Если хочу, могу сделать хоть каждый атом ООП объектом, ну и что ты мне сделаешь? Морду скрючишь от отвращения?
Алсо, хочешь ЕЦС - подключай модуль для ЕЦС или свой пиши. Мне лично мозги парить твоим ЕЦС не нужно, у меня и без него проблем много, например, я понятия не имею, что мне вообще делать, игры?
Технодемку сделаю
Зааплаил все скейлы и трансформации. Тоже не помогло.
Штош. Видимо проблема в моей кривоватой модели.
Попробую закинуть стандартного бипеда из Миксамо. Может с другой моделью проблем не будет.
С бипедом из Миксамо такая же хуйня.
Ладно, хуй с ним. Уже завтра буду думать.
Спасибо. Посмотрю.
>>898859
Ну вот я так и решил примерно сделать. Мне нужно конкретно сохранять на кнопке параметр disable. Я решил через цикл всё в отдельный массив писать.
>Зачем тебе это нужно? Для какого "референса"?
Нужно весь интерфейс со всеми кнопками заблокировать. Потом разблокировать только те кнопки, которые были разблочены до "блокировки всех кнопок".
>Нужно весь интерфейс со всеми кнопками заблокировать.
Интересно. Для чего? В смысле, что должен видеть на экране игрок? Если нужно предотвратить клики, можно перекрыть весь экран одним, для примера, ColorRect, скажем, полупрозрачным чёрным, для стандартного эффекта "затемнения", когда поверх выводится какое-то окно/меню.
>параметр disable
Этот параметр переключает внешний вид кнопки. Классически, он используется в системных GUI для отключения индивидуальных кнопок, которые в данный момент нажать вот вообще никак нельзя. Переключать весь GUI этим параметром не имеет смысла, лучше просто скрыть/перекрыть GUI.
>Интересно. Для чего?
Чтоб игрок не кликнул и сломал всё.
>ColorRect, скажем
Я перекрывал прозрачным весь экран (затенение не вариант конкретно для этой сцены), но там как бы не очень телеграфирует, что ничего нажимать не нужно. Просто как будто бы игра зависла. Вот я и решил блочить кнопки. Тут сразу понятно что происходит.
>Переключать весь GUI этим параметром не имеет смысла, лучше просто скрыть/перекрыть GUI
Ну там как бы вот в том то и дело, что так если сделаю, то он постоянно будет мигать как бешеный. Я же не хочу какого-нибудь писюна тригернуть, да и не красиво это выглядит если так часто мигает.
Там у меня кнопки короче. Нажимаешь кнопку либо действие происходит, либо нпс фразу выдаёт. И вот пока это всё происходит нужно кнопки подблочить.
>Ты намекаешь на третье лицо?
Я намекаю, что кто-то здесь очень хочет не смотреть на аниме-ангелицу, но быть ею и видеть мир её глазами.
Не забудь запилить зеркала, так ещё сасней.
Да. Когда катка потная.
Я бы на чулки смотрел, дааа.
Ну, вообще самый простейший и тупой способ получить плоские нормали, это посчитать нормаль сразу в фрагментом шейдере, типа
В вершинном:
viewPos = modelView * vertexPos
В фрагментом:
xTangent = dFdx(viewPos)
yTangent = dFdy(viewPos)
fNormal = normalize( cross(xTangent, yTangent))
Все, в fNormal плоские нормали пофрагментно, можешь подсовывать вместо модельных нормалей, юзабельно для каких нибудь отладочных целей или для, например, ssao/ssdo если влом реальные нормали пихать туда.
Довольно распространенный метод, примеров думаю найдешь множество.
Если использовать GLES3, можно использовать ключ flat перед юниформом для нормалей, это просто отключает интерполяцию нормалей фейса.
Юнити кал говна, а анриал не хочу
Нашо шоб производительность графики и физики как в юнити, чтоб 100 врагов со скелетной анимацией + куча пропсов на уровне и фепоес не дропался ниже 200 на i9-9900 и рузен 1700х
У меня пока не очень впечатления от годоти и страйда по сравнению со срунити. Они по дефолту чуть чуть тормозят. Судя по тестам на ютупе, всё опен сорсное начинает подлагивать, когда у тебя в сцене 200-300 кубов с физикой. Срунити начинает подлагивать на 1000-1500 кубов.
Ну и стоит вопрос, можно ли так же легко таскать с гитхаба всякие ништяки, типа динамических облаков там, годрейсов, кайфовых шейдеров и тд. Что я ни вбиваю в строку поиска на гитхабе касательно страйда, почти ничего нет.
Этим движкам не хватает несколько десятков лямов баксов и команды из ебейших прогеров, которые всё знают и могут всё имплементировать и оптимизировать.
Народ, я вам точно говорю, надо чтобы 3д тоже было опен сорсным. Теперь, когда унрыло тупо монополист, недалеко время, когда и они высрут что то такое же конченое, как юнити. По поводу спайвара в эпик сторе вы уже все знаете, так что анрыл уже на пол пути.
Можешь какой нибудь булет подключить и будет тысячи ригидов вертеть со шкелетом каждый.
Можешь свое написать, на опенцл или кудах, чтобы на видеокарте аж полноценное н-боди вертеть на миллион ригидов или миллионы вершин для тряпок и софтбодей.
>По моему эта фигня с нодами какая то странная
Будешь жрать, будешь терпеть, никуда не денешься
>булет
Godot Jolt. Вероятно в будущем войдет в основную ветку, кстати.
>>899202
Из тобой перечисленного для 3д годот лучше подходит. Но не ожидай соотношения фиделити/перформанс на уровне юнити. Можешь еще o3de попробовать, это бывший ламберйард от амазона, а он бывший край-энжн от того самого КРУЗИСА. Но читал что все они - дикая жопая боль при использовании.
https://www.youtube.com/watch?v=4gzO60GhmW8
В общем случае, на винде, ты никак не обновляешь годот. Ты просто скачиваешь и запускаешь. Ты можешь держать несколько версий, которые ты скачал.
В сложном случае... Читай факин мануал.
Т.е мне его в ручную качать по новой и переносить туда проект каждый месяц условно?
Он и так будет с предыдущей минорной версии открывать (но лучше делай бекап проекта, в любом случае его лучше делать)
Я как раз узнал про джолт.
Джолт сокращает разрыв в разы.
Для полного набора ещё не хватает какого-нибудь производительного рендера. Пока мне кажется, юнити ЮРП превосходит годотовский рендерер, как он там у них называется.
Где то читал, что боссы годота против того, чтобы имплементировать сторонние штуки, слышали про такое?
> юнити ЮРП превосходит годотовский рендерер
Зато монетизация годота превосходит юнити. Вопрос закрыт.
Смотри, обесняю на пальцах. Твой проект как будто файл docx. Ты его откроешь вордом-2010, но при этом ты его откроешь и вордом-2016. Ничего никуда переносить не надо, как ты там себе нафантазировал.
>>899362
> и переносить туда проект каждый месяц
Нет, просто открыл новый скачанный godot-hurr-durr.exe и просто работаешь дальше.
>>899176
Ну хорошо, попробую сделать.
Вот кстати персонажка. Рисовал правда не я, а один мой знакомый. Слева в углу тоже не я рисовал, а знакомая, все они на основе моих рисунков но их я показывать не буду там уж очень стыдливо. Это если что не ингейм вариант а просто общий концепт внешности персонажа.
>Нет, в шуттерах нет пуль, есть только эффекты и данные этих эффектов. Все пули это просто инстанс, либо какой угодно другой батчинг.
Ты чё долбаёб на сталкер посмотри там каждая пуля объект отдельный просчитываемый.
Делаешь бэкап проекта на всякий случай
Делаешь это регулярно
Скачиваешь новый апдейт годота
Запускаешь
А там в менеджере проектов все твои проекты в списке
Открыааешь
99% все работает
Если что то глобально переделывали, меняешь это у себя (ну там функцию или вектор какую то переименовали)
Если совсем пиздец произошел, возвращаешься к предыдущему билду
Как успехи?
>Нажимаешь кнопку либо действие происходит, либо нпс фразу выдаёт. И вот пока это всё происходит нужно кнопки подблочить.
Добавляй любые нажатые кнопки в очередь. Что-то похожее ещё в первом The Sims было.
>постоянно будет мигать как бешеный
А постоянная блокировка/разблокировка не будет нервировать игрока? Звучит не очень, в общем.
Чел, сралкеру уже лет 20 и говнокодеры писали его.
Объекты которые ты видишь через апи и объекты в ооп это разное. Объект может быть просто интерфейсом до структуры, например.
Global variable означает что указанный КЛАСС будет виден по имени.
Т.е. если ты добавил скрипт(1) под именем MyWorld, то ты сможешь вызывать в нем функцию написав MyWorld.fun()
Вредный совет. Всё надо делать на стейтмашинах! Стейтмашины, охоспаде!
> действие происходит, либо нпс фразу выдаёт
В этом случае контроллер управления переводится в стейт айдл. А вообще часть пользы в твоём посте есть. Можно сделать стейт-машину со стеком-очередью (нужное подчеркнуть).
Ладно верю.
Скриншоты показывай. Скрин окна автозагрузок и скрин скрипта2, в котором вызываешь глобальное имя.
С чего ты решил что я собираюсь в это играть?
Это больше демонстрация, что на годоте можно делать типичную игру, которыми завалены все сторы.
В таком стиле 3д экшон-платформер аля пикрил был бы топ, аля пикрил. А тавер дефенс такое себе.
Оу, любопытный код. Тут мои полномочия всё. Нужны более шарящие аноны. Чисто с дивана предполагаю, что у тебя где-то там хитрое зацикливание при позднем связывании происходит. Такие баги никогда не пишут в дебаггере свою настоящую причину.
Ну так-то норм, чё. Но как-то хз в плане дизайна. Она чем по жизни занимается? Выглядит так, будто в суде адвокатом работает, ну либо прокурором. Хотя если иммерсив сим, то норм наверное? Может я вообще придираюсь потому что сам люблю что если тянка участвует в комбате, то и вид у неё должен быть как у комбатанта. Сложно рассуждать за дизайн когда даже и лора толком не знаешь, но чисто по концепту создаётся впечатление, что персонаж с бумажками часто возится.
Да я хз короче. Нужно больше арта, а лучше игра в её более менее полу-законченном состоянии. Так что пили давай.
Боже, храни Хуана!
Единственное что сейчас может спасти юнити это перевод его в опенсорс до того как хуан подтянет годотю
Тогда юнити фактически труп. За йоба-графоуни люди побегут в анрыл, остальные в годотю. А потом тим свыня повторит успехи юнити.
Если перейти в попенсорс не труп, ибо во многом даёт пососать годоте, собсно сам хуан перечислил.
Не будет никогда такая корпорация переходить в попен сорс, для них это потеря доходов, хуже чем труп.
Я не говорил про корпорацию, а про основной двиг. Деньги с гоев можно всё еще стричь при помощи ассет стора, техсаппорта, консультаций, разработки платных модулей, разработки своих игр в конце концов.
https://www.youtube.com/watch?v=_L711ozxQbw
Да, я и сам на него подписан. А инфоцыганом его любя называю. По братски. Но гомо))
сколько этот чел уже видосов напилил на эту тему за последние 3 дня? штук 10 уже?
Майк ебучий пахом, который записывает видео, первый раз открывая страничку с очередным движком и просто читает текст.
Лет 7 назад он ещё как-то старался, но сейчас занимается хайпом.
Так вот, просто нужно к ноде прикрепить потомком еще одну ноду и к ней прикрепить скрипт, в котором работать с парентом-нодой. Таких нод можно прикрепить сколько хочешь. Их можно сохранить в сцены и прикреплять когда требуется.
Я таким образом как-то писал модульный контроллер персонажа не получилось, забил
Тут чел так и делает
https://www.youtube.com/watch?v=5hkQXwDmwHE
Но он не знает, что в Юнити на один объект можно закинуть несколько скриптов напрямую.
Да, подтверждаю, ровно то же самое, что я написал. Совет от самого Хуана, как оказалось.
появляется окно проекта а потом исчезает
Вкатунов не это путает.
Они почему-то думают, что это должны быть только подноды в одну цепочку и одним полотном.
Когда на самом деле это удобные одноранковые списки и разделение по объектам в разных файлах + возможность свернуть любое поддерево.
Это окошоко посередине похоже на ошибку видеодрайвера.
Возможно у тебя линукс не тянет вулкан (как и у меня)
Отредактируй project.godot чтобы в нем было
[application]
...
config/features=PackedStringArray("4.1", "GL Compatibility")
[rendering]
renderer/rendering_method="gl_compatibility"
renderer/rendering_method.mobile="gl_compatibility"
> версию 3.5.1
Ну как бы тебе сказать? Это как если бы ты вместо питона 3 поставил питон 2. Ничего плохого, на годоте3 тоже можно писать, он еще поддерживается, но имей ввиду.
>>899862
> Они почему-то думают, что это должны быть только подноды в одну цепочку и одним полотном.
Ну я хз. Когда я вкатывался в геймдев, я скачал все движки, как тот пацан из мема. Что-то в юнити делал, что-то в анриле. По итогу мне больше всего понравился годот.
Поэтому я могу понять перекатунов с юнити. У них там была композиция, где каждый игровой объект расширяется путём наращивания линейного списка монобехов, при этом все игровые объекты на уровне сцены можно скомпоновать в иерархию. Здесь же часть монобехов становится нодами иерархии, вторая часть - скриптами, третья - ресурсами. Из знакомой и удобной системы они выкинуты в сложное-непонятное нагромождение возможностей.
>Всё надо делать на стейтмашинах!
При чём тут конечные автоматы? У него проблема юзабилити: юзер жмёт кнопку, кнопка нажимается, а ожидаемого эффекта не происходит.
>контроллер управления переводится в стейт айдл
И чё? Как это решит проблему нажимаемых кнопок, которые нажимаются, но ничего не делают?
Ты вот лезешь постоянно не думая. Чем тебе так конечные автоматы нравятся? Они же даже не лучшее решение для игрового ИИ.
Они обычно лучшие во всем, потому что подсистема находится гарантированно в только одном состоянии
>>899698
>Выглядит так, будто в суде адвокатом работает, ну либо прокурором.
>если тянка участвует в комбате, то и вид у неё должен быть как у комбатанта.
Он сам или его художники очевидно вдохновлялись пикрилом. По лору, все демоницы - падшие ангелы, в процессе теряющие ниб и седеющие. Обладают огромной боевой мощью, но ходят в стильных костюмчиках и занимаются какой-то фигнёй. Помимо игры есть длинная серия комиксов от автора, так что фандом вроде большой и неудивительно, если кто-то хочет сделать что-то похожее.
Э-э... Ну, это хорошее предположение... Но нет.
Я не вдохновлялся Helltaker. Я даже в него не играл.
Спасибо за мнение. Расскажу чуть больше про неё позже, сейчас очень мало времени у меня на разработку.
>каждый игровой объект расширяется путём наращивания линейного списка монобехов
Я вот этого так и не смог понять в Unity. Типа, WTF? Огромная портянка каких-то скриптов, ничего не разобрать, как с этим работать? Так и забил на неё. Пускай сами свои портянки колесом крутят...
>часть монобехов становится нодами иерархии, вторая часть - скриптами, третья - ресурсами
Тут всё как раз просто и понятно:
- ноды: базовые компоненты движка;
- скрипты: расширения базовых компонентов;
- ресурсы: умные контейнеры с данными для нод.
Хочешь фичу? Ищи и добавляй ноду.
Не нашёл ноду? Расширяй ноду скриптом.
Нужно закинуть данные? Прикрепляй ресурс.
У тебя некие особые данные? Расширяй ресурс.
Мне кажется очевидным, что расширить базовый компонент возможно только одним скриптом на один экземпляр, это ведь базовая база ООП. Как вы себе представляете расширение несколькими скриптами? Какие у них... семейные отношения?
Контейнеры могут быть и без данных, а только с каким-то особым поведением. Но они пассивно лежат в руках ноды, сами ничего не делают - т.е. у них нет своих _process, _input и других обработчиков.
>>899862
>должны быть только подноды в одну цепочку
Сомневаюсь, что так кто-то думает. В юнити тоже есть дерево сцены, его кто-то делает лесенкой?
>>899834
>можно прикрепить сколько хочешь
Ребят, давайте смотреть правде в глаза.
https://docs.godotengine.org/en/stable/tutorials/best_practices/node_alternatives.html
>Nodes are cheap to produce, but even they have their limits. A project may have tens of thousands of nodes all doing things. The more complex their behavior though, the larger the strain each one adds to a project's performance.
Оптимизировать можно что угодно, но лучше не срать нодами там, где они вообще не нужны. А то сейчас полезут те, кто по 2 строчки в скрипт кидает, и таких скриптов у него 100500 в дереве... Разве в юнити принято срать компонентами? Кто вообще придумал срать мелкими скриптами?
Нет, я не предлагаю делать god object. Но срать мелкими скриптами, а потом жаловаться на ООП - это какое-то совсем детское поведение.
Всего нужно в меру.
>каждый игровой объект расширяется путём наращивания линейного списка монобехов
Я вот этого так и не смог понять в Unity. Типа, WTF? Огромная портянка каких-то скриптов, ничего не разобрать, как с этим работать? Так и забил на неё. Пускай сами свои портянки колесом крутят...
>часть монобехов становится нодами иерархии, вторая часть - скриптами, третья - ресурсами
Тут всё как раз просто и понятно:
- ноды: базовые компоненты движка;
- скрипты: расширения базовых компонентов;
- ресурсы: умные контейнеры с данными для нод.
Хочешь фичу? Ищи и добавляй ноду.
Не нашёл ноду? Расширяй ноду скриптом.
Нужно закинуть данные? Прикрепляй ресурс.
У тебя некие особые данные? Расширяй ресурс.
Мне кажется очевидным, что расширить базовый компонент возможно только одним скриптом на один экземпляр, это ведь базовая база ООП. Как вы себе представляете расширение несколькими скриптами? Какие у них... семейные отношения?
Контейнеры могут быть и без данных, а только с каким-то особым поведением. Но они пассивно лежат в руках ноды, сами ничего не делают - т.е. у них нет своих _process, _input и других обработчиков.
>>899862
>должны быть только подноды в одну цепочку
Сомневаюсь, что так кто-то думает. В юнити тоже есть дерево сцены, его кто-то делает лесенкой?
>>899834
>можно прикрепить сколько хочешь
Ребят, давайте смотреть правде в глаза.
https://docs.godotengine.org/en/stable/tutorials/best_practices/node_alternatives.html
>Nodes are cheap to produce, but even they have their limits. A project may have tens of thousands of nodes all doing things. The more complex their behavior though, the larger the strain each one adds to a project's performance.
Оптимизировать можно что угодно, но лучше не срать нодами там, где они вообще не нужны. А то сейчас полезут те, кто по 2 строчки в скрипт кидает, и таких скриптов у него 100500 в дереве... Разве в юнити принято срать компонентами? Кто вообще придумал срать мелкими скриптами?
Нет, я не предлагаю делать god object. Но срать мелкими скриптами, а потом жаловаться на ООП - это какое-то совсем детское поведение.
Всего нужно в меру.
>эпиков в принципе ничего не останавливает от того чтобы подобный финт выкинуть
Все так. Задолго до фортнайта, во времена живого унрыл турнамента, они занмались хуйней с удерживанием фич/саппорта, чтобы их собственные игры выглядели лучше на фоне конкурентов. ЕМНИП с ними судились даже. Сегодня они могут себе позволить выглядеть белыми-пушистыми за счет профитов с Фортнайта. Но дойная корова сдохнет - новой коровой станешь ты, поняшка.
>Или не парится и сделать хотя бы одну игру прежде чем волноваться об этом?
Но вообще да. В первую очередь игры делай, суетись потом.
В юнити объект сцены это просто контейнер. Нетипизированный. У каждого объекта есть компоненты, их может быть сколько угодно. Скрипт это тоже компонент. Он не наследует объект сцены, он наследует MonoBehaviour - базовый класс скрипта.
>Сомневаюсь, что так кто-то думает.
Ну я такое у нюфагов видел неоднократно.
Почему так выходит? Предположу, что вот сделал сцену, что дальше? Нажимаем плюсик, чтобы добавить ноду. Она становится выделенной, что произойдет, если нажать плюсик? Правильно, продолжится цепочка вглубь, а не вширь.
>это просто контейнер
...который может быть в иерархии сцены == Node.
>У каждого объекта есть компоненты, их может быть сколько угодно. Скрипт это тоже компонент.
Вот это вот и непонятно. Как я должен увидеть взаимоотношения между этими компонентами?
Вот, скажем, простой 2D персонаж. У него:
- тело
- - одежда
- - голова
- - - лицо
- - - шапка
- - ноги
- - - штаны
- - - ботинки
- - руки
- - - рукава
- - - оружие
- - - - моды
В Godot всё +/- так и выглядит. А в Unity это будет огромная портянка ноунейм компонентов в одном player, которую хрен разберёшь. Поэтому я забил на неё ещё много лет назад, когда освоил Godot.
У компонентов нет отношения друг с другом, кроме компонента Transform - у него есть parent.
>А в Unity это будет огромная портянка ноунейм компонентов в одном player
В юнити тебя заставляют не называть объекты и не нестить их что ли?
Что несешь, охуеть вообще
У оружия есть отношение к рукам, а у рук - к телу. Пока тело на разорвётся на части взрывчаткой... Короче говоря, как я понял, в Unity точно так же необходимо заполнять дерево сцены множеством мелких объектов, у которых всего 1-2 компонента (трансформ, спрайт), иначе зачем сцена вообще.
>>900068
>заставляют не называть объекты
Так тут один анон жаловался, что в Godot у каждого компонента есть личное имя, лол. И что у них ещё и иерархия в дереве сцены может быть любой. Как я пойму, что вот этот компонент - руки, а этот - ноги?
Это главное отличие дерева сцены между юнити и годотом.
Я аниме смотреть и спать.
>Кто вообще придумал срать мелкими скриптами?
любители микросервисов, ооп, принципа солид (ван респонсебилити), любител идробить задачи на микрозадачи, а их ещё и ещё и т.д.
>Для полного набора ещё не хватает какого-нибудь производительного рендера. Пока мне кажется, юнити ЮРП превосходит годотовский рендерер, как он там у них называется.
Hold my beer!!!
Юнити рендерщик внезапно ставший безработным
Ты юнити рендерщик? Запили в годот рендер чтоб конкурировал с юнитивским!
Тут есть такое?
Не знаю, но "Дестроер" это тот, кто уничтожает, а не тот, кто уничтожается. Кто уничтожается логичнее будет "дестроебл"
Есть группы. Работает примерно так же.
Добавляешь таким объектам ноду Destroyable. При взаимодействии нода уничтожает родительскую.
Вообще на это есть ассеты какой то степени готовности (их можно взять за основу).
Есть два подхода
1. Нарезает сам движок. Тут желательно разбираться в 3d математике, потому что надо будет сообразить некоторые моменты со склеиванием и текстурами.
2. Ты свою модельку сам нарезаешь в какм нибудь блендере. Потом в момент разрушения подменяешь целую на кусочки на тех же местах и включаешь им физику.
Еще вариант делать на CSG формах. Ну это будет похоже на 1 вариант.
Лень искать, спроси антона
Я еще не на той стадии чтобы локализовывать. 2 плагина в ассетах видел, адекватные ли они? По внешнему виду не очень.
В годоте есть встроенный механизм локализаций. Думаю, что если игра маленькая, можно обойтись .po или .csv и редактировать в блокноте. Если большая - локализовать в какой нибудь спец программе для такого.
> локализовать в какой нибудь спец программе
Именно в "спец программе" на выходе будут файлы .po, которые годот распознаёт искаропки.
В подавляющем случае для игры достаточно csv со списком строк во всех поддерживаемых языках.
>>900458
И кстати, я когда изучал аддоны наподобие диалоджика, заметил, что там мало внимания уделяют локализации. Несмотря на то, что сам плагин локализован - файлы, которые создаёшь, не имеют возможности подхватывать локализацию в дизайнтайме. При попытке написать средних размеров диалоговый контент и поддерживать больше одного языка, там начнётся лютый головняк.
А локализовывать на десяток языков тебе гугл-транслейт будет?
Пора делать no-text игоры. Способов придумано миллион.
Независимо от аддона - ну и нахуй оно надо? Я когда вижу в гугл-плее корявый перевод на русский сразу дропаю игоря. Лучше никак, чем так издеваться.
Делайте без текста. Базарю, это не так сложно, и игроку играть приятней вместо чтения вашей духоты. Конечно если у вас не визуальная новелла.
Вот посмотри эту демку и реши для себя сам. Очень там или не очень.
Это то, что ты сможешь получить в движке (на четвёрке с вулканом):
https://www.youtube.com/watch?v=1ho6tbxGt4c
И самое главное - не насилуй себя гд-скриптом. Выдели себе неделю на изучение (Хуаном обещан вкат в гд-скрипт за неделю). Если не смог вкатиться в него - просто качай .Net версию движка и пили скрипты на шарпе. Во внешнем ИДЕ, как привык.
Пилить свои штучки в ассет стор это тоже вклад. Делайте так-же, раз уж донатить мы не можем. Сделаем Годот великим вместе
> чёт подлагивает в видео
Знаменитая особенность нашего движка: пропуки. Подавляющее количество годотеров ниасиливают многопоточность, в том числя я, в том числе автор видео. А без многопоточности весь рендер маслает на одном ядре проца вместе с ресурслоадером, как Старфилд Тодда Говарда.
Ну что я могу тут посоветовать? Обнови железо. Ну или осиль многопоточность.
>Подавляющее количество годотеров ниасиливают многопоточность
Пиздос, а анрыл это всё за тебя делает? Я просто тоже не умею.
>чёт подлагивает в видео
Я когда записывал себе отрывок все было плавно, но на записи заикалось. И короче протестировал несколько прог, не заикалось только в обс, так что может ютубер хуйней какой-то записывал
Наверное. Лучше у них в треде спросить.
Вот уже и умные люди как для пятилетних на пальцах объясняют, почему с гдскриптом перформанс годота в параше спустя 10 лет разработки, 24,23 μs на один рэйкаст из которых 98% - оверхед гдскрипта
То есть, в 120фпс игре можно сделать только 344 рэйкаста на кадр если вообще ничего другого больше не делать
Боже, как же унижены годотеры, это пиздец...
https://sampruden.github.io/posts/godot-is-not-the-new-unity/
Зачем в игре может понадобиться 344 рейкаста каждый кадр? Тут проблемы с геймдизайном.
Вот есть ригидбоди_1 и ригидободи_2, в дереве находятся на одной иерархии. Если я их хочу соединить джоинтом, этот джоинт надо класть тоже здесь же или чайлдом к кому-нибудь из них?
Г3.5, двадэ.
Клади здесь же. Иначе точка привязки уедет на одном из них.
В смыс... разраб на годоте должен влезать в рендер и многопоточить его? Блин, не уж то никто за все эти опен сорсные года не запилил нативный многопоточный рендер?
Проверять на какой поверхности стоит враг - на ровной или наклонной. Рейкастим и получаем нормаль поверхности, смотрим угол поверхности, если больше 45, то враг переходит в стейт типа подскользнулся и катится по наклонной поверхности, запускаем анимацию.
Примеров миллион, это только 1 из них.
Окей, может ты не будешь конкретно каждый кадр рейкастить, но и мы для примера взяли ТОЛЬКО рейкасты вообще без всей остальной логики и на сцене с 0 полигонов, чтобы проц вообще ничем не грузить кроме рейкастов. По факту ты можешь рейкастить намноооооого меньше, чем 344
Даже так нет нужды пересчитывать ВСЕХ каждый кадр. На любом движке если ты каждый кадр обрабатываешь всю логику для всех акторов, то ты впустую тратишь вычисления. Разумнее если тебе нужны именно сотни врагов, считать каждый кадр только 1/60 или сколько ты хочешь кадров в секунде от всех противников, или вообще считать их того реже.
То есть враг будет бежать целую секунду по поверхности, на которой бежать не должен. Отличная логика. Считать пополам на 2 кадра это ещё туда сюда, но не 1/60.
Секунда это достаточно мало, чтобы не принести большого вреда. Вообще в таких вычислениях есть смысл, если у тебя динамический ландшафт, в противном случае ещё на этапе составления карты ты и боты знаете где могут они ходить, а где нет. Иначе зачем они в принципе должны пытаться лезть туда, куда не могут попасть?
теперь понятно почему современные игры так лагают. Забить хер на архитектуру и оптимизацию и херачить миллиард вычислений в секунду.
Есть множество способов увеличивать количество вычислений в секунду или уменьшать в зависимости от алгоритма. Если чел бежит в середине поля 1км радиусом, то его можно считать раз в секунду. Если он подбегает к обрыву, то можно чаще
Плохому программисту язык мешает.... Если у тебя такая боль от гдскрипта, то ты можешь писать на том же шарпе в годоте, если что
Ну и кал. Почему на годоте за все эти годы никто не удосужился выпустить нормальную респектабельную 2д игрушку?
годо только последние 2-3 года более-менее популярен, а это практически время разработки большинства игр, поэтому игры только сейчас начинают на нем появляться (большинство популярных игр на нем выпущены в 22-23 году)
Берешь и выпускаешь. Ты-то наверное успешный инди-гений с многомиллионными продажами.
К счастью они уже отыграли назад и сейчас наплыв токсиков поуменьшится.
Это не пруфы. Это пиздёж на реддите беспруфный.
Смысл научного знания (в отличие от религиозного) в том, что его может проверить ЛЮБОЙ.
А если я тебе готовое принесу на блюдечке, то в ответ будет только пук гринтекстом и сектантские завывания в духе "640 килобайт хватит всем", уже три года наблюдаем.
Правильно, поэтому я и сказал тебе принести ПРОЕКТ, который смогу проверить я и любой.
А проверть все рандомные высказывания наука не обязана, потому что тогда залетные тролли могут ее задудосить.
Давно бы уже проверил, вместо того, чтобы на дваче сраться. Полагаю, всем ясно, что ты залётный троль и годот даже не скачивал, поэтому я буду тебя репортить.
Кидать проект, чтобы в ответ получить говно от залётного токсика? Нет, спасибо, я лучше буду делать игры на годоте. Я тебя уже зарепортил за движкосрач, алибедерчи, залётыш.
Я уже проверил, С# быстрее гдскрипта. Все с тобой ясно.
0 агрументов по теме, 0 понимания темы, только какое то витание в облаках и игнорирование проблемы
Очень свободный синтаксис, встроенная документация которая может тебе подсказать что угодно в 1 клик, просто как будто берешь и пишешь и всё работает.
Ну да, а в констракте еще легче события, но все это слишком слабо для игростроя. Ну реально же тормозное говно, чего вы копротивляетесь, что питон, что гдскрипт говно и точка. Заставьте хуана удалить гдскрипт, другого пути нет
С какой целью ты это написал? Чтобы меня задеть? Так меня это не цепляет, ты для меня просто буковки сбежавшие из движкосрача, а на работе мой труд по оптимизации уже много лет неплохо оценивается и оплачивается. А ты продолжай рейкастить по 344 раза в кадр, лол.
>Смотря какая цель.
Улучшать движок, тормозной гдскрипт этот серьезный недостаток. Вот реально непонятно, чего вы трясетесь за него, он не облегчает программирование сложных алгоритмов, наоборот мешает
Например, какой алгоритм ты не смог написать? Учитывая, что основной учебник по алгоритмам вообще написан на лиспе - еще более простом языке из скобочек.
Да он и не открывал никаких учебников. Пишет всякую O(n!) хуйню, а потом удивляется тормозам.
Гдскрипт - это скриптовый язык для быстрого написания игровой логики. И он реально ускоряет разработку. Это очевидно на любом геймджеме, за день на нем делается больше итераций прототипа. При том, что у меня 10 летний коммерческий опыт на C# и всего года 3 на гдскрипте. Числодробительные алгоритмы пишутся модулями на C++. Все на своем месте.
Тебе сделали разбор >>901120 есть серьезный недостаток в производительности? Что будете делать? Будете улучшать это как-то? Потому что в других движках лучше. Почему бы и не улучшить, не избавиться от медленного говна, это же нормально так поступать, признать что обосрались, в юнити три языка раньше было.
Я то знаю ответ, никаких изменений не будет
>let’s be clear here: I’m still a Godot newb, and this article will contain mistakes and misconceptions.
Перекатун - ньюфаг, который запустил незнакомый движок, не понял, прибежал на реддит говорить что не так как юнете, ему указали на ошибки. Ну ничего, еще какое-то время поразбирается и разберется. К чему такие посты всерьез воспринимать? Что он там мог за несколько дней освоить?
Алсо, Хуан уже давно ответил что все делается. Нахуй ты нам пишешь, что тебе от нас надо?
Хочу и пишу, тебя конкретно за язык не тяну, неинтересно проходи мимо
Ты либо англюсик читать не умеешь, либо читаешь его жопой.
Алсо. Джолт - охуенно. Джва года ждал. Тащите быстрее.
>Re-Logic, developer of Terraria, donates $100,000 and becomes monthly $1,000 donor of Godot
Охуенчик. Из других новостей - фонд скоро доползет до желаемых 50к. Посмотрим теперь как девелопмент ускорится. Может с тройки слезу раньше чем планировал.
>и статической типизации
Но в гдскрипте динамическая сильная типизация. Да, мы можем не писать тип переменной, но скрипт препятствует неявным преобразованиям в рантайме. Пикрелейтед пруф. При попытке сложить число и строку возникает исключение на этапе компиляции. Не предупреждение, не неявное преобразование, а исключение.
Ну хоть так, в яваскрипте он бы тебе сложил без задней мысли.
Есть, ты хотя бы знакомишься что есть в движке, где оно лежит и как им пользоваться на базовом уровне. Ты можешь усилить эффект от обучалки если помимо повторения будешь делать небольшой детур и пробовать делать что-то своё с теми знаниями что тебе дали.
там там же в читщите написано, что можно явно указывать тип переменных и тип возвращаемых значений функций
то, что годоти не пользуются этим, ну хз, пускай компьютер попробуют выключить и включить
>копипастишь код и нахуя не понимаешь
ну хз, из контекста можно много чего понять, там не то что бы рокет саенс написан
> не пользуются этим, ну хз
Для прототипирования полезно. Думаешь о реализации идеи, а не о расшаркиваниях с синтаксисом. Когда прототип готов - можно и явную типизацию сходить проставить по готовому коду.
Просто осознай.
Туториалы - это как лекции в универе. Если на лекциях сидеть на задних партах и хуярить геншин импакт на мобилке, то к сессии тоже нихуя не будешь знать.
Так же и туториалы. Нужно работать с преподаваемым материалом. Не копипастить код, а переписывать "в конспект", то есть в открытый проект у себя на компе. Включается моторная память. Начинаешь понимать, что пишешь.
Так ты не копипасти, а пытайся разобраться, что каждая строчка кода делает
Использую. Можешь ему скармливать свои крипты и просить улучшить их читаемость, провести рефакторинг. Спросить совета по выбору названий. Попросить написать алгоритм по твоему описанию. Но правда бесит, что он зачастую домысливает твой текст. Он не может что-то сам прям придумать, его как ребёночка нужно за ручку вести.
Слишком старая база, косячит больше чем если ты рандомного анона спрашиваешь.
>>901444
Двачую. Вот пример. Он шпарит код для тройки, без instancinate(), без @export, без встроенного velocity, без map_to_local()
https://www.phind.com/search?cache=qdi6ry41dl8yo9t7t9ilsjdq
Просить пофиксить помо
*не особо помогает
Сап годотер. Всвязи с последними событиями решил перекатиться на новый движок.
Я не новичок и на нём уже делал игры на твг, пару лет назад.
Но более сложные игры а 3д у меня не получались из-за низкой компетенции, а нагуглить решение проблем у меня не получалось.
Плюс я заметил, что сложные 3д игры серьёзно, так тормозили.
Поэтому вопрос номер 1 - решена ли проблема с производительность в зд?
Вопрос номер 2 - осталась ли поддержка C#?
Вопрос номер 3 - Что по мультиплееру и аи ботов?, есть ли решения из коробки?
Подозреваю что там надо слишком много скармливать.
Например, я переносил один аддон и там для рисования гизмо использовалась нода ImmediateGeometry, которые прямо в коде процедурно рисовали, что теперь надо переделывать на ресурс ImmediateMesh, довольно нетривиально составить документ описывающий такое изменение и все остальные.
C# только улучшили и еще будут улучшать
Базовый мультиплеер всегда был из коробки, аддоны с роллбеком в наличии
Аи ботов, в каком плане? Есть аддоны для GOAT, Behavior tree.
навигация базовая, пользоваться можно, у меня еще в Holer утка гонялась за игроком по лестницам и вокруг бочек. Помню есть нюанс, что не все понимают, как работает поиск пути, что его надо периодически обновлять если надо обходить движщихся врагов, потому что поиск пути != obstacle avoidance
Производительность зависит от оптимизаций которые сделаешь сам. Если просто закинуть ассеты бездумно, накидать десять постпроцесс вьюпортов, то будет тормозить. Тут могут помочь тулскрипты, я так объединял и делил объекты после процедурной генерации.
Но это уже доволньно специфично, штук типа instancinate() или @export должно хватить для основных сценариев. Вообще чагпт мне ускоряет разработку прям серьезно в других языках.
Ну тут все больше в графику упирается, и в то насколько далеко ты хочешь зайти в физичности "режешь веревки", так то что ты описал ожно успеть за пару дней джема сделать. За 2 недели точно.
>то что ты описал ожно успеть за пару дней джема сделать. За 2 недели точно.
Это для сениора питониста с 5 лет опыта в годоте или новичок тоже быстро разберётся?
Охренеть, вот это идея для таурдефенс, молодца, я о таком даже не додумался. В битве кольца есть подобная миссия, но там можно со стены спускаться.
Чувствую на следующем твг сорву куш.
Да без проблем, я такими сру как поносом. Если сделаешь заебись и выпустишься в стиме я даже куплю.
>В стим
Нет бро, так далеко я ни разу не заходил. Это для ребят из высшей лиги. Я больше для себя и для ТВГ делаю, там можно будет за бесплатно скачать и поиграть.
Это технология на которой сделаны дум/квейк/халфа. Это полезно в уровнях внутри помещений где видно содержимое только пары комнат. В игре типа фазмофобии позволит разместить больше предметов интерьера. В открытых картах, вилах сверху, разрезах не поможет
Ну если с нуля то за месяц наверное. У тебя же по сути упрощенный платформер
Сейчас тебе еще идей накидаю - у тебя корзина, ты ловишь предиеиы падающие с разных сторон
Ричителло гений, ни один человек еще столько для опенсорс геймдева не сделал как он.
Ты тупой прост, что твой пост и подтверждает.
Я отказваюсь что такой бред можно написать неиронично. Ты же тролль?
Там вроде аппловин начали пилить какую-то тулзу на основе чатгпт, для переката с юнити в годот. Геймсфромскратч недавно рассказывал.
>>901405
А я всегда сразу явную типизацию делаю. За всё время буквально пару раз столкнулся с необходимостью динамической типизации. Вообще не вижу ни одной причины, почему бы сразу не указывать var foo: float, когда точно знаешь, для чего тебе этот foo нужен.
Но, может, кому-то это удобно.
>>901343
>Может с тройки слезу раньше чем планировал.
Сейм.
Типизация в 3ке часто ломается при циклической завимиости классов. Некоторые аддоны приходилось детипизировать чтобы они работали.