Шапка: https://hipolink.me/godothread
Предыдущий: >>1040245 (OP)
Архивный: >>1030839 (OP)
Что надо сделать, чтобы увековечиться в шапке тредю?
1. Быть интересным.
2. Напомнить о себе под бамплимит.
Ну или угнать тред, да.
Старый треллей, как-то уныло. Неужели нечем рисануться?
На случай важных переговоров с издателем вашей игры, если вдруг спросят, а как вы будете удалять элементы из головы массива? Отвечайте, что быстрее будет реверснуть и удалять с хвоста.
О, я после похожих тестов пришел к такому решению. У меня там обычно массив 10к, который я шринкаю до 1к раз в минуту, потом снова отращиваю его до 10к и снова шринкаю. Можешь тоже потестить и сравнить со своими бенчами.
a1 = a1.slice(a1.size() - items_to_stay, a1.size());
Но подозреваю что тест наврал по времени и-за кеширования.
>На случай важных переговоров с издателем вашей игры, если вдруг спросят, а как вы будете удалять элементы из головы массива?
>Отвечайте, что быстрее будет реверснуть и удалять с хвоста.
Неправильно.
Нужно отвечать "А тебя это ебать не должно"
Ты не поверил тому, что в документации написано?
Это проблема XY. Зачем тебе это вообще нужно?
Поясняю вкратце, исходя из исходников движка:
1. В pop_back() копирования вообще нет:
- вернуть значение последней ячейки массива;
- инициализировать массив с новым размером.
2. В pop_front() идёт копирование массива -1:
- вернуть значение первой ячейки массива;
- через for сдвинуть все значения влево.
3. В reverse() идёт копирование всего массива.
4. В slice() идёт копирование части массива.
Иными словами, если у нас есть две задачи:
А. Удалить 30 тысяч элементов в одном месте.
Б. Удалить 1 элемент из 30 тысяч разных мест.
Работа в случае задачи А:
- pop_front: 30 тыс. копирований, 30 тыс. вызовов.
- reverse+back: 2 копирования, 30 тыс. + 2 вызовов.
- slice: 1 копирование остаточной части, 1 вызов API.
Работа в случае задачи Б:
- pop_front: 30 тыс. копирований, 30 тыс. вызовов.
- reverse+back: 60 тыс. копирований, 90 тыс. вызовов.
- slice: 30 тыс. копирования части, 30 тыс. вызовов.
Итого, более точным решением будет:
Задача А: использовать API-функцию slice().
Задача Б: рефакторить архитектуру приложения.
a1.reverse()
a1.resize(items_to_stay)
a1.reverse()
>>1049061
А что, с помощью реверсов, ресайзов и слайсов сможем ли мы сделать быструю замену pop_at()?
>сделать быструю замену pop_at()
https://docs.godotengine.org/en/stable/classes/class_dictionary.html
>>1049067
>>1049061
>>1049039
>>1049034
Вы не шарите, надо делать так:
Минимальные требования
ОС: Windows 11
Процессор (AMD): AMD Ryzen 7 3700X
Процессор (Intel): Intel Core i7-10700
Оперативная память: 16 ГБ
Видеокарта (AMD): AMD Radeon RX 6700-XT
Видеокарта (Nvidia): Nvidia RTX 3060Ti
Direct X: DX12
Подключение к Интернету: Да
Место на диске: :SSD — 80 ГиБ
Дополнительно: TPM 2.0 включён, Безопасная загрузка UEFI включена, Поддержка HVCI, Поддержка VBS
> надо делать так:
Чтобы получить школоассетфлип, который запускается только на топовых печах, не обладая при этом графоном? Ну, допустим.
Не, тут только ситууационно что-то придумать можно, например тебе нужно из огромного массива размером N удалить много элементов например N/2.
Тогда можно вместо удаления делать их null, потом пробежаться по массиву двумя "курсорами" делая swap для null и не null значений, а когда один курсор дойдёт до конца массива сделать resize до позиции другого курсора.
Неплохо, реально неплохо. Потом реализую. А вот если мне в массиве нулль нужен, чем его заменить? Скажем, для указания на пустое место под удаление использовать класс-пустышку?
Он не это имел ввиду.
Я кстати без понятия что писать в системках, если когда-нибудь настанет день релиза. Возможно просто напишу конфиг моего компа. Похуй что он игру может хоть в 100 окон запустить.
Если вы бездомный - просто купите дом. Если вы бесхлебный - кушайте пирожные.
>А вот если мне в массиве нулль нужен, чем его заменить?
Variant() по идее можно
Можно какой-то другой массив создать, который будет хранить индексы удалённых элементов и в какой то момент его "применить" / "скоммитить"
т.е. есть исходный массив arr и массив удаляемых элементов del,
можно что-то вроде такого сделать:
>del.sort()
>var new_arr = []
>var ind = 0
>for d in del:
> new_arr.append(a.slice(ind, d))
> ind = d + 1
(не проверял, но смысл чтобы собрать новый массив из кусков старого, за счёт памяти)
Прекращайте преждевременные оптимизации. Они усложняют код и могут оказаться хуже самого тупого решения в будущем. Если вам нужно произвольные элементы массива удалять, и код на GDScript, лучше пользоваться Dictionary и не париться. Скорость у встроенного Dictionary чуть-чуть медленнее Array, но операции добавления и удаления в середине будут значительно дешевле. Аналог обычного Array:
>var array: Dictionary[int, Variant]
Добавление элемента:
>array[key] = data
Удаление элемента:
>array.erase(key)
Проверка наличия:
>if key in array: ...
>if key not in array: ...
В других ЯП это называют associative array:
https://en.wikipedia.org/wiki/Associative_array
Dictionary может хранить null:
>array[0] = "text"
>array[1] = null
>for key in 3:
>_ if key in array: print(array[key])
>_ else: print("Key ", key, " doesn't exist!")
> Прекращайте преждевременные оптимизации.
Игры делать штоле? Штоооа?
У тебя шарики за ролики? Ты чекаешь ссылки, что они ссылки и ведут себя как ссылки?
Я в силу глубины своей некомпетентности не понимаю, как покрывать тестами код) Эффект Даунинга-Крюгера))
Так. Ни хера себе. Это кто у нас такой охуенный клоун? Рядовой Шутник, а?
>a.fill([...].pick_random())
Ты осознаёшь, что pick_random() здесь будет вызвана единожды перед вызовом fill(), а дальше fill() сделает заполнение массива единственным значением?
Если хочешь заполнить массив случайным мусором:
>a2 = a1.map(func(e): return [...].pick_random())
Правда, на тесты скорости это никак не повлияет.
Не знаю C++, как лучше писать параллельный поток? Какими-то C++ классами или через Godot API? Хочу числодробилку параллельно Godot крутить, но чтоб излучала сигнал на сторону GDScript, когда закончит.
> Правда, на тесты скорости это никак не повлияет.
Фух. Не обосрался. Ну не сильно. Обсер был, но в штанину не попало. Активно работает смена белья.
> Подводные?
Будет крошиться на десктоп как скайрим с модами.
> Не знаю C++
> Не знаю как писать параллельный поток
Так ты выучи си++ чтобы его знать ДО ТОГО как придёшь в геймдев.
https://github.com/orgs/godotengine/projects/61/views/5
когда пропадут release blcokers и по возможности very bad и bad
Жаль тебя огорчать, анон, но такая игра уже скоро выйдет https://youtu.be/yG5vZqVVCn8?si=ZaXI1c8nYIbC2yXI
Ну вряд ли он будет заметен на фоне целой команды разработчиков, которые явно собираются поддерживать игру n лет. Тем более без четкой цели. Нужно менять концепцию и браться за что-то менее масштабное
Пчел этих игр про летающие острова вагон еще в нулевых был. Твой пойнт это пойнт уровня "в гта люди, всем перестать делать игры про людей".
Летающие острова самый обычный дженерик фентези сеттинг. Удобен для разработки и на этом все.
Я думал делать редалерт1 лайк когда-то, поискал как там что было сделано - там танки отрисовывались в 3д на самом деле и были воксельными. Ну я сделал вьюпорт в котором 3д танк рендерился и передавался в 2д мир, написао конвертор координат 2д<>3д.
А ютуб такой на ка посмотри что нормальные люди делают https://www.youtube.com/watch?v=aNHMwEOJxoY
И как-то уже и не хочется
Там у них буквально полноценная постройка кораблей и полеты на них. Как раз то, что пробовал делать тот анон. В общем ему нужно допиливать концепцию и придумывать уникальные фишки.
Как ты - разработчик-одиночка (как понимаю) планировал высчитывать баланс хотя бы 2-3 фракций? Зачем вы беретесь за настолько сложные проекты со сложными механиками? У вас вообще есть горизонт планирования?
В редалерте баланс был на уровне у одних так с уроном 10 в других танк с уроном 10
>полноценная постройка кораблей и полеты на них
Бля ты рофлишь если думаешь что это редкая идея
https://store.steampowered.com/app/2644050/Echoes_of_Elysium/
https://store.steampowered.com/app/1048950/Desert_Skies/
https://store.steampowered.com/app/1931180/Lost_Skies/
https://store.steampowered.com/app/1040070/Merchant_of_the_Skies/
https://store.steampowered.com/app/271920/Worlds_Adrift_Island_Creator/
https://store.steampowered.com/app/2097190/Astoaria/
https://store.steampowered.com/app/342560/Airships_Conquer_the_Skies/
https://store.steampowered.com/app/1641960/Forever_Skies/
https://store.steampowered.com/app/982290/Airborne_Kingdom/
https://store.steampowered.com/app/1660080/Aloft/
https://en.wikipedia.org/wiki/Project_Nomads
Нет. Идеи стоят примерно нихуя, они копируются, воруются, вдохновляются, модифицируются, и в каждой голове их бесконечное количество. Трясусны за идеи - нюфаженьки, геймдева не нюхавшие.
Зачем тебе индекс если у тебя задача добавлять удалять как в очереди (алгоритм). Если у тебя и то и то нужно, та надо уже матчасть учить.
>выучи си++ чтобы его знать
Я могу читать и понимать исходники движка и могу смастерить хэллоу ворлд на C++, но я не знаю всех подводных камней C++. Знаю только что это очень костыльный язык, которому почти каждый год баги пытаются пофиксить в стандарте, но делают хуже; используется только ради скорости, скрипя зубами.
Так что использовать - Godot, OpenMP или что-то совершенно другое? Насколько я понял, в C++ нет многопоточности как таковой, её костылят васяны, поэтому просто взять и написать код не получится.
>Будет крошиться на десктоп
Кстати, почему так?.. Разве в Godot не используется exception handling? Или это снизило бы скорость для внешних модулей? По-моему, если в модуле что-то сломается, основная программа не должна падать, обрабатывая возникающие исключения на ходу.
>>1049156
>Нейросеть напишет.
Что напишет? Код для OpenMP?
>я не знаю всех подводных камней C++
По подводным надо самому походить, иначе твое знание нихуя не стоит. Разве что в срачах в интернетике козырнешь, а на пратике сразу же еблом в подводный камень да с разбегу угодишь.
>в C++ нет многопоточности как таковой
Что ты имеешь ввиду? thread потерял?
>thread потерял?
Ааа, вон оно что.
<thread> вошёл в стандарт C++11.
А OpenMP рекомендовали в 2010.
Нейронка почему-то решила, что обсуждения на StackOverflow за 2010 год более авторитетные...
Спасибо за подсказку.
>Спасибо за подсказку.
1 секунда гугла c++ threads и первая же ссылка. Я просто удивился твоим словам, типа как это так ваще, вот и загуглил. Нейронки пожрали твой мозг. Да и мой тоже, часто из-за льющегося от них говна так же туплю.
Иногда еще полезно бывает читать условие задачи. А там значится обьект типа массив, который обязан иметь функционал индекса, при чём не его o(n) суррогат, а нормальный вычесляемый индекс. И матчасть тут не поможет, потому что нет матчасти которая бы смогла к связному списку прикрутить индекс без прикручивания дополнительного массива для индексов элементов списка.
>Если у тебя и то и то нужно, та надо
>>1049265
>массив, который обязан иметь индексы
https://en.wikipedia.org/wiki/Associative_array
https://docs.godotengine.org/en/stable/classes/class_dictionary.html
>при чём не его o(n) суррогат
У Dictionary O(1) сложность доступа.
Ты хочешь и булку съесть и на годот сесть. Ты уже описываешь две задачи (рандомный доступ и очередь), так сова на глобус не налезет.
Чаще всего вообще бывает, что ты обосрался в предметной области и решаешь задачу, которая поставлена ошибочно, под все остальное всегда хватает стандартных алгоритмов.
Каким боком key value к связному списку? Тебе не кажется что сама задача "удалить элемент массива с конца" для такой вещи как словарь просто лишена смысла по той простой причине что словарь не имеет возможности укладывать элементы сообразно последовательности их добавления в словарь. У словарей нет индекса в его "массивном" понимании. А любые попытки его прикрутить значительно замедлят процесс добавления/удаления обьекта в словарь при этом не дав значительных преимуществ перед стандартными массивами.
>>1049274
>Ты хочешь и булку съесть и на годот сесть. Ты уже описываешь две задачи
Лично я ничего не описываю, только отталкиваюсь от свойств требуемых обьектов, перечитай условие задачи еще раз. Вполне обоснованная задача, которая хоть и относительно редкая но всё же встречающаяся.
> Можешь тоже потестить и сравнить со своими бенчами.
Не могу понять, где я облажался? Ресайз должен быть быстрее, но всё равно быстрее оказывается поп_бэк. Я уже на микросекунды перешёл, чтобы хоть какие-то данные увидеть.
Посмотри свежим взглядом, где неправ?
> А любые попытки его прикрутить значительно замедлят процесс добавления/удаления обьекта в словарь при этом не дав значительных преимуществ перед стандартными массивами.
Вот кстати да. Полюбуйтесь.
>быстрее оказывается поп_бэк.
у тебя массив пустой и длины 0
Возможно в глаза ебусь, но не вижу размеров твоих тестовых массивов. Сделай там 10к элементов и обрежь их до 5к каждым методом.
Не пустой.
>>1049305
> Сделай там 10к элементов и обрежь их до 5к каждым методом.
Щас погодите. Всё это время (с предыдущего поста) выполняется кейс_1. Хочу дождаться конца.
Игры дейлайте
Для истории ходов, например. Или даже для истории фреймов. Вместо постоянного дрочения на добавление-удоление обрезаешь раз в минуту.
Ты не пробовал делать как в го - слайсы делятся на чанки энного размера? Допустим у тебя кейс с историей ходов и по логике очевидно, что потребуется удалять из нее по 1к элементов за раз или близко к этому, значит делишь всю эту благодать сразу на 1к чанки либо на чанки кратные 1к, офк потребуется обертка в виде своего типа над этим говном, в любом случае ты в процессе либо рубишь на корню целыми чанками разом, либо один последний чанк хирургически, либо все вместе, но профит в том, что не ворочаешь свой массив с миллиардом элементов ради этого целиком на каждый чих. Впрочем гдскрипт массивы может внутри так и работают, это тоже глянь.
>Не пустой.
На пик2
> var arr: Array
> ...
> ..
> arr.reverse()
>...
>>Не пустой.
Да, идея хорошая. Я поленился ее делать. Подрезать массив раз в минуту проще. По таймингам фреймов там незначительный микро-пропук, который теряется на фоне активной игры.
Если очень нужно, то это просто сделать. Но зачем?
>>1049308
Годотчую. Изобретают велосипед, экономят спички.
>>1049310
Решение очень простое: не хранить историю ходов.
>>1049360
>Я поленился ее делать.
А считать спички в велосипеде не поленился?
>По таймингам фреймов
>незначительный микро-пропук
Он там всегда, даже на пустом проекте...
Спасибо. Нашёл тупейшую ошибку копипастинга. Теперь всё заработало. И действительно, ресайз решает. Удаления по одному что в массиве, что в словаре примерно равны. Ну а pop_front() как и написано в документации - слоупок.
Нашёл ещё одну ошибку. Как-то не верилось, что словарь так быстр, и действительно, я наделел лишнего, из за чего удалялись те элементы, которые должны были остаться. После исправления всё встало на свои места.
Увеличь arr_size на порядок ещё
>>1049384
Не совсем честно замерять копирование одного и того же куска в никуда. делай дубликат потом отрезай.
> в никуда
В оперативку.
> делай дубликат потом отрезай
Слайс уже возвращает дубликат.
> Увеличь arr_size на порядок ещё
Готово! Ещё вопросы?
Как ты достал своими кодом. Иди матчасть по алгоритмам учи, это не твой ньюфаг бложик, хватит срать уже. всем насрать на твои юные исследования в программировании
Не слушай его. Мне не насрать. Потестируй ещё замену pop_at() на слайсы, раз уж у тебя готовый стенд напрограммирован.
Дыши глубже. Все это напрямую касается годота и игр на нем. Полезные интересные посты. Я из похожих постов узнал что switch в гдскрипте медленнее чем портянки if-else
Результаты неочень, есличесн, пришлось сильно уменьшить входной массив, и всё равно медленно. Слайс хорош когда выполняется один раз, а тут мы возвращаемся к циклам. Остальное хоть и быстрее слайсов-в-цикле, но тоже медленное.
>Дыши глубже.
Надеюсь тебе напихают репортов за флуд.
Нужно к школе готовиться, а не операторы свитч замерять. Вниманиелять.
Всё-таки Dictionary выгоднее, когда нужна, например, разреженная 3D сетка - с адресацией по (X, Y, Z) и добавлением-удалением элементов в произвольных местах этой сетки. На массивах такое делать - голову ломать над адресацией, забивать память нулями/null и даже сам доступ к ячейкам трёхмерного массива может на практике оказаться медленнее Dictionary из-за особенностей GDScript (здесь до сих пор отсутствует JIT/AOT-компиляция, которая могла бы сильно ускорить множество мелких операций, таких, как вычисление адреса в массиве).
Пример:
>var grid: Dictionary[Vector3i, GridCell]
>grid[Vector3i(4, 5, 6)] = GridCell.new()
>grid[Vector3i(1, 50, -125)] = GridCell.new()
>grid[Vector3i(500, -250, 125)] = GridCell.new()
>if Vector3i(...) in grid: ...
>grid.erase(Vector3i(...))
Пусть и не идеальное решение, но достаточно эффективное в рамках GDScript.
А ещё это решение, теоретически, масштабируется на любое количество измерений, потому что под капотом Vector вроде бы те же структуры, что и у Array, и поэтому Dictionary должен мочь принимать на вход массивы любого размера и любого содержимого:
>var grid: Dictionary[Array, String]
>grid[[0, 1, 2, 3, 4, 5, 6, 7, 8, 9, "A", "B", "C", "D", "E", "F"]] = "16-мерное пространство"
Конечно, в данном случае вопрос не в скорости, а лишь бы оно вообще работало...
>>1049402
Ты его поругал и тред умер на полдня. Доволен?
>>1049184
>вряд ли он будет заметен на фоне целой команды
Почему ты считаешь, что разработкой игр можно заниматься лишь ради заметности на фоне других? Большинство существующих игр никому не нужны, несмотря на уникальные концепции и хорошую реализацию. Даже от больших, дорогих студий. Они собирают ничтожные 10 тысяч отзывов и всё, пока условная Terraria побила миллион отзывов и растёт. Наиболее необычные игры вообще где-то на дне.
>Доволен?
Конечно доволен, это же сренькальщик залетный.
Делайте игры и обсуждайте делание игр.
Щас буду биндить Ada к GDExtension...
Кто нибудь делал мультиплеерные игры на годоте? Есть советы по архитектуре серверов?
Я не делал. Зато я делал синглплеерный пиксельный платформер.
Тут бывает какой-то фанатик, видимо делает что-то уровня киберкотлетской доты, аж пена изо рта идет на тему мультиплеера, особенно о том как сложно кнопки нажимать. Жди его, он занят тем, что делает синхронизации для синхронизаций. А я делал хуйни попроще только, что даже хуже, чем вообще ничего не делать.
Семён, ты? Ты зачем флудишь?
Как у тебя
>мультиплеерные игры на годоте
связано с
>советы по архитектуре серверов
в твоём понимании?
Движок даёт тебе базовые инструменты, описанные здесь:
https://docs.godotengine.org/en/stable/tutorials/networking/index.html
Остальное ты должен додумывать сам под требования своей игры.
Вообще я в годот тред залетел под какой-то истеричный срач о мультиплеере. Вот и запомнил шиза.
Любой может написать 3 поста с 3 разных браузеров и сделать 3 таких же скриншота.
Но только семён попытается доказать, что он не семён, запостив 3 скриншота подряд.
>>1049531
>Ок, подожду.
Я тебе уже ответил. Ты ничего о своей игре не сказал - какого совета ты ждёшь?
>Ты его поругал
Я еще на него накляузничал (надеюсь не только я).
Чел тупо страдает фигней и вниманиелядствует в треде. Я конечно понимаю, весело вкатываться в разработку и транслировать свои изыскания, но есть для этого бложики и одноклассники.
>Ты его поругал и тред умер на полдня. Доволен?
Это хорошо, я сюда по делу и заходил, мы же не в /b чтобы тредами меряться.
>Большинство существующих игр никому не нужны, несмотря на уникальные концепции и хорошую реализацию
Значит концепция/реализация говно
А я на тебя, и надеюсь не только я, потому что ты срешь в треде своим вечным недовольством на все вообще, и мешаешь обсуждать напрямую релейтед темы. Так и представляю этого старого душного пердячего деда-вахтера, которому даже обсуждение гдскрипта и его подводных камней неподходящая тема. Что дальше, нельзя чейнджлог годота обсуждать? Приходить к тебе за справочкой о каждой теме? Хртьфу.
>я сюда по делу и заходил
Не, дед, судя по твоему поведению твое основное дело тут - вахтерство. Ну а мы не на работе, а ты нам не начальник.
В Питоне это делается с помощью named arguments, типа:
Объявление как:
func foo(a=640, b=520, c=true)
И вызов как:
foo(c=false)
Но гдскрипт в такое не умеет. Так что прописывай все.
Параметры по умолчанию.
func show_picture(a: bool, b: int = 0, c: int = 0) и так далее. Хотя точно не помню насколько хорошо гдскрипт в это умеет.
Передача дтошками.
class ShowPictureParams:
var a: bool
var b: int
var c: int
...
func show_picture(params: ShowPictureParams):
...
var params: ShowPictureParams.new()
params.a = true
show_picture(params)
Ну и методы-обертки.
func: show_picture_default(a: bool): show_picture(boo, 0, 0, 640, 520, false)
>А я на тебя, и надеюсь не только я,
Я тут практически ридонли, так что кляузничай.
Это тематика, зачем флудить в тематике? Ну подыми отдельный тред со своими замерами свитчей (которые возможно разворачиваются в if...else во время интерпретации), скинь ссылку на движкосрач, собери компашку из хрюнити и возмущайтесь вместе.
Там же непочатый край, вызов функций не бесплатный, а если не указывать типы то ваще грустно. А потом окажется, что работа с полями объектов дороже работы с глобальными переменными.
Сколько же открытий ждет нас. а... нет... каникулы кончаются
Репортнул тебя за превращение ИТТ в личный нытик-тред. И, надеюсь, не я один.
Релейтед обсуждения на гитхабе:
https://github.com/godotengine/godot/issues/6866
https://github.com/godotengine/godot-proposals/issues/902
TL;DR: много технических сложностей, из-за которых данную фичу реализовывать не планируется. Если реализуют, то это ударит по производительности.
Заголовок функции ты не показал, зову экстрасенса:
>func show_picture(p: ImageTexture, x: float, y: float, w: float, h: float, f: bool) -> void:
Эти аргументы можно сжать так:
>func show_picture(p: ImageTexture, at: Vector2, size: Vector2, f: bool) -> void:
Можно пойти дальше:
>func show_picture(p: ImageTexture, rect: Rect2, f: bool) -> void:
Дальше тебе остаётся определить, какие параметры используются в среднем чаще других, и сортировать:
>func show_picture(p: ImageTexture, f: bool = false, rect: Rect2 = Rect2(Vector2.ZERO, Vector2(640, 520))) -> void:
Либо можно пойти ещё дальше:
>func show_picture(p: ImageTexture, args := {}) -> void:
>_ var flag := args.get("flag", false)
>_ var rect := args.get("rect", Rect2(Vector2.ZERO, Vector2(640, 520)))
>_ # Или так:
>_ var at := args.get("at", Vector2.ZERO)
>_ var size := args.get("size", Vector2(640, 520))
Но в таком случае подсказки в коде лишаешься.
По производительности костыль через Dictionary, естественно, должен быть немного медленнее, чем нормальный вызов с аргументами. Но этот костыль предназначен для твоего удобства, верно? Т.е. твоё удобство как разработчика компенсирует нехватку производительности. Зато в остальных местах всё работает быстрее, чем в каком-то там питоне.
Алсо, рекомендую не делать много аргументов в собственных функциях. Скорее всего тебе нужны свойства класса, а не аргументы функции, пример:
>class_name InventoryItem extends Control
>@export var icon: ImageTexture
>@export var rect := Rect2(Vector2.ZERO, Vector2(640, 520))
>@export var flag := false
>func show_item() -> void: ...
По этой причине, например, у CharacterBody теперь move_and_slide() вообще без аргументов - всё, что передавалось аргументами, настраивается теперь свойствами самого класса. Ибо так логичнее.
>>1049580
А, точно, можно создать вложенный класс, тогда сохраняются подсказки, правда, печатать дольше:
>class_name InventoryItem extends Control
>class SPArgs # подразумевается extends RefCounted
>_ var icon: ImageTexture = null
>_ var rect := Rect2(Vector2.ZERO, Vector2(640, 520))
>_ var flag := false
>_ func _init(i: ImageTexture) -> void:
>_ _ icon = i
>func show_picture(args := SPArgs.new()) -> void: ...
Обращение будет, правда, посложнее Dictionary:
>var args := InventoryItem.SPArgs.new(image)
>args.flag = true
>item.show_picture(args)
Тот же пример через Dictionary:
>item.show_picture(image, { flag = true })
Пример через свойства:
>item.icon = image
>item.flag = true
>item.show_item()
Выбирайте на свой вкус.
Очень жаль, что в GDScript нет оператора "with"...
>Значит концепция/реализация говно
Нет, хорошие игры с интересной концепцией тоже опускаются на дно Стима, и там и остаются. Или, по крайней мере, эти игры ничем не хуже других, но не добрались до топа популярных.
Поэтому, если ищите мотивацию для разработки игр, можете сразу забыть о популярности игры. Если вы не популярный (видео)блоггер или нет бюджета на маркетинг, игра вряд ли станет популярной даже с достаточно большим бюджетом на разработку.
>>1049562
>Чел тупо страдает фигней
А что такого-то, если это касается GDScript?
>и вниманиелядствует в треде.
Раньше тут было больше узнаваемых анонов, но все, к сожалению, разбежались. Или это ты их репортил? Постите о разработке своих игр на Godot почаще, а то выглядит так, будто мы тут только код обсуждаем.
>я сюда по делу и заходил
Тогда какое тебе дело до его постов?
>>1049575
>своим вечным недовольством на все вообще
Ты его с кем-то путаешь, наверное. Это не он. Это я недоволен всеми, всем и всюду. А он кто-то другой.
>>1049594
>отдельный тред со своими замерами свитчей
Не нужен отдельный тред. Он тут несколько тредов сидит уже, насколько я понимаю. Обычно постит интересные конструкции в коде на GDScript. Чем его производительность не устроила - не знаю, но сам вопрос оптимизации кода смысл для треда имеет.
>Ща прибежит
Не раскачивай лодку.
Это тред любви и взаимопомощи.
>>1049633
>Как вкатиться в кодинг?
1. Интерактивный туториал по GDScript для нубов:
https://www.gdquest.com/learn-to-code-from-zero/
2. Официальная документация для продолжающих:
https://docs.godotengine.org/en/stable/tutorials/scripting/index.html
3. Некоторые крупные LLM могут ответить на многие программисткие вопросы более-менее хорошо, но конкретно в GDScript сильно заблуждаются. Лучше спрашивать теоретические вопросы, а не код. Дальше следуете в поисковик, далее Wikipedia, StackOverflow... Иногда что-то полезное бывает на Reddit, YouTube.
Главный практический навык кодера - умение искать необходимую информацию в интернете, желательно - на английском языке (всё основное именно на нём).
Я вот прокачал навык гуглинга за счёт кодинга...
>Ассеты то и спиздить можно
Если планируешь публиковаться и просить деньги - желательно не использовать копирайченные ассеты. Используй цветные кубы/квадратики вместо них для прототипов, иначе в будущем забудешь удалить и ВНЕЗАПНО игру удалят по DMCA от кого-нибудь. Да и нарисовать стильный программер-арт не так сложно.
>как их работать заставить
Про геймдизайн не забывай - он важнее кода и арта.
Респект.
>Если планируешь публиковаться и просить деньги - желательно не использовать копирайченные ассеты. Используй цветные кубы/квадратики вместо них для прототипов, иначе в будущем забудешь удалить и ВНЕЗАПНО игру удалят по DMCA от кого-нибудь.
Так а если чел сам пишет, что можно юзать в коммерческих проектах или это такая обманка хитрая?
Не обманка. Просто всегда надо смотреть лицензии ассетов. СС0 безопасно в любом виде в любом проекте, даже без указания авторства ассетов - сам под СС0 на итче выкладываю. СС-BY уже требует указания авторства, тут мутнее и хватает тонких моментов - ты авторство укажешь, а какой-нибудь мелкостример, играющий твою игру не укажет, и ему страйк прилетит от автоматизированной системы ютуба/твича, особенно это музыки касается.
>чел сам пишет, что можно юзать в коммерческих
Тогда у ассета свободная лицензия, чаще всего это вариант "CC". Скорее всего ты обязан в титрах игры обозначить, что используешь его ассет, добавить (не обязательно кликабельную) ссылку на его страницу. "Воровства" тут нет, "воровство" - это когда, скажем, извлекают ассет из одной игры, вставляя в другую, скачивают платные ассеты бесплатно с торрентов, нарушают условия лицензии на ассет и т.д.
Подробнее о самой популярной лицензии на ассеты:
https://en.wikipedia.org/wiki/Creative_Commons_license
>или это такая обманка хитрая?
Вряд ли. Большинство просто выкладывают своё творчество, надеясь стать популярнее, если их имя засветится в популярной игре. Но, в теории, можно провернуть манёвр, если удалить все упоминания свободной лицензии из интернета... Поэтому имеет смысл сохранять копию сайта автора в формате, который может иметь вес в суде (тут я не спец).
Главное не воруй у больших игроков (Sony, Nintendo, Rockstar, Hadbro и многие другие, кому не насрать). С рандомным Васяном из Нижнего Пердюйска скорее договоришься о компенсации без суда...
>>1049640
>СС0 безопасно в любом виде
Лол, не всё так просто. Не в каждой стране автору позволено выкладывать свой контент в публичное достояние до своей смерти + сколько-то лет.
>страйк прилетит от автоматизированной системы
Это только если музыка публиковалась каким-то музыкальным лейблом и зарегистрирована в этой автоматической системе. Нужно смотреть источник.
Ещё полезно почитать про "патентный троллинг" - в геймдеве некоторые игровые механики оч жёстко запатентованы. Стрелочку рисовать на экране стало разрешено всего несколько лет назад, например. И мини-игры на загрузочном экране делать нельзя по причине какого-то патента, а не из-за лени разрабов.
>мини-игры на загрузочном экране делать нельзя
А, тот патент в 2015 просрочился... Значит, можно.
Значит, это реально разработчики тупо ленятся.
Не ленитесь. Делайте игры на экран загрузки.
>игровые механики оч жёстко запатентованы
Какой же это сюр нахуй. А мысли то еще запатентовали?
>А мысли то еще не запатентовали?
Мысли - нет. А вот бросать шарик для призыва себе боевого питомца - это сразу иск в суд от Nintendo... Использовать питомца как глайдер тоже нельзя.
>И че сделал палворлд
1. Удалил броски шарика - теперь тупо спавн рядом.
2. Удалил петы-глайдеры - пет даёт бонус глайдеру.
Что им придётся удалить дальше - покажет время.
Если не веришь, сам гугли.
Несколько месяцев назад играл. Не обратил внимание, что шарик не бросаю для призыва. А глайдер ваще не помню, летал на пале. Ну мб, просто действительно в глаза ебался, типа не важная мне деталь. А захват шариком они не патентовали выходит? И все остальное, что полностью спизжено с покемонов?
Вот есть Camera3D и RayCast3D. По идее, рейкаст обновляется с частотой физики, 60 Гц по умолчанию, однако, камеру предлагается вращать в _process() с частотой монитора. Как это по-хорошему решается? Необходимо плавное вращение и детект коллизий одновременно - с разными частотами обновлений.
>>1049659
Там всё очень сложно. Изначально Nintendo вообще наехала без патентов, патенты зарегистрировали в процессе судебных разбирательств. Как это у них получается - непонятно, но Pocketpair им уступает.
Может, причина в том, что обе компании в Японии - кажется, это сильно упрощает судебный процесс. А Nintendo любит отжимать бабки у конкурентов...
Если я правильно понял, то тебе нужна интерполяция. Глянь вот этот видос
https://youtu.be/zfIuaRzNti4?si=UX141b_swfG3Be9w
Я джва часа заполнял форму отправки ассета на ассетлиб, и вот наконец всё готово, нажимаю отправку и получаю сабж. Вся форма сбросилась, всё что я там вписывал.
Вероятно кто-то сильно накосячил в духе начала нулевых, когда делал форму. Или что там у них. Пиши заново.
Это крч секьюрити, которую браузеры подкручивают в последние годы. Запрещает отдавать/запрашивать некоторые ресурсы между не-https доменами. Браузер на такое может ругаться даже если ты на локалхосте что-то хостишь, например верстаешь банальный index.html и подгружаешь в нем локальный ресурс.
Возможно ты тупил с отправкой слишком долго и csrf токен истек, или, скорее всего, бекенд успели рестартнуть.
>The "CSRF check failed" error usually occurs when a security token is missing or invalid during a form submission, often due to expired sessions or cookies. To resolve this, try clearing your browser's cookies or using an incognito window.
Проще говоря - ты слоупок.
На каждую форму (открытие страницы) заводится токен. У токена есть время. Это как капча на двачах, у которой тоже есть время жизни.
Если проблемы не случилось а я предполагаю, что её не случилось, то просто забей. У тебя не только рейкаст вращается с частотой в 60 кадров, у тебя и детект колизий происходит с этой частотой, т.е. если ты хочешь получить детект коллизий с частотой камеры либо вращай камеру в physics_process либо увеличивай частоту физики.
Представляю. Мне ваще приятно, если любую мою работу ценят, но поскольку я хуйло криворукое обычно получаю ведро говна.
Чел создаёт проблему двигая физический объект (персонажа) в _process и решаёт её, гениально
>нужна интерполяция
Проверил - вроде бы работает... Но _process() теперь вообще нельзя, только _physics_process().
>Глянь вот этот видос
Странное решение. Если двигать камеру в _physics_process(), движок сам всё интерполирует.
>>1049688
>я предполагаю, что её не случилось
С чего ты взял? Это не из категории преждевременных оптимизаций.
>У тебя не только рейкаст вращается с частотой в 60 кадров
В том-то и дело, что камера вращается быстрее - из-за этого проблемы.
Теперь камера вращается в _physic_process() и интерполируется.
>С чего ты взял? Это не из категории преждевременных оптимизаций.
>
Значит у тебя какая то странность с игрой если тебе надо успеть рейкастом поймать что то в промежутке между двух вызовов физического процесса.
Вообще есть механизм рейкаста из камеры, у неё вроде метод есть такой, скорее всего закроет твою проблему, а нода скорее всего делает это же самое но каждый физический тик, но это надо в исходники смотреть
1. Вращаешь камеру мышкой.
2. Повернув камеру, жмёшь левую кнопку мыши.
3. Рейкаст запаздывает и выбирает не то, на что смотрит камера.
4. ???
5. РРРРЯЯЯЯ, ДА КАК ТАК-ТО, Я ВЫБИРАЮ, А ОНО НЕ ВЫБИРАЕТСЯ!
Тру стори.
>inb4 трансформируй рейкаст перед кликом
Почему-то не работало. Или мне было лень...
>Странное решение. Если двигать камеру в _physics_process(), движок сам всё интерполирует.
Физический процесс работает с фикс частотой в 60 тиков/сек. А камера должна вращаться с частотой fps - т.е. process.
Или я что-то не вкуриваю?
>>1049676
>>1049674
>>1049672
Спасибо, человеки, со второго раза запостилось. Алсо, мои данные запомнились в автоподстановке. СПАСИ ВАС БОГ! 🙏❣❤ ХРАНИ ГОСПОДЬ АССЕТЛИБ! 💌💦
А чо там ассет стор? Туда публиковываешь?
https://store-beta.godotengine.org
Отбой! Отбой! Смотрим на быстрофикс. Думоем.
В некотором смысле появилось, опосредованно. Ты можешь унаследовать свой скрипт от SceneTree и указать его в свойствах проекта. С этого момента у тебя будет твой кастомный майнлуп, в котором ты можешь прописать свои свойства, которые хочешь юзать на топлевеле, а затем, когда аудионода загрузилась, она делает
> if get_tree() is MyZaLoop: get_tree().my_bga = self
Ну и естественно в любом другом месте, где тебе нужен доступ к аудионоде, ты делаешь
> if get_tree() is MyZaLoop and get_tree().my_bga is not null: get_tree().my_bga.volume += 5
Но есть один нюанс... Ехехе... И не один.
>камера должна вращаться с частотой fps
Да. Но если ты включаешь в настройках проекта "физическую интерполяцию", все transform у Node3D интерполируются на каждый кадр, даже если ты их изменяешь очень редко. Единственный подвох - эта интерполяция линейная, т.е. если у тебя тикрейт 10, вращение камеры будет в виде "многоугольника"...
>>1049709 >>1049712
Задавай вопросы нормально: что ты пытаешься там реализовать и зачем, и что у тебя там не получается? Например, что за "типмиксинг" такой? Зачем нужен?
>>1049704
>либо вручную геттер/сеттер на ноде нпс делать, либо ПКМ->Edit children чтобы достать до аудионоды
Другого выбора нет. Главная нода сцены - это как бы интерфейс класса ООП, т.е. то, что взаимодействует с окружающими объектами. Ноды под главной нодой - скрытые детали имплементации класса, от которых существенно зависит работа объекта. Если ты жмёшь "editable children", ты нарушаешь инкапсуляцию в ООП. Создавая геттеры и сеттеры ты создаёшь интерфейс, независящий от имплементации класса - даже удалив конкретные ноды внутри сцены, интерфейс никак не изменяется, и, соответственно, сцена будет работать.
Если ты хочешь настраивать большое количество однотипных нод из одного места, то рекомендую воспользоваться ресурсами: если не делать их явно уникальными, они будут иметь одни параметры вне зависимости от того, где используются. Пример:
>@export var audio_settings: AudioSettings
>class_name AudioSettings extends Resource
>@export var volume: float
Сохраняешь 1 экземпляр audio_settings.tres где-то в файловой системе и вставляешь его в каждую ноду, требующую AudioSettings. Тогда изменения в файле отобразятся во всех нодах, использующих его. Даже в рантайме, если ты не использовал .dublicate().
Ещё можно использовать статические поля класса.
>>1049713
Ты просто переизобрёл синглтон. Зачем? Если у тебя потребуется изменить что-то в синглтоне (например, расширить функциональность игры), то потребуется изменять все места, где у тебя к нему обращение...
С ресурсами получается более гибкий подход.
>Да. Но если ты включаешь в настройках проекта "физическую интерполяцию", все transform у Node3D интерполируются на каждый кадр, даже если ты их изменяешь очень редко. Единственный подвох - эта интерполяция линейная, т.е. если у тебя тикрейт 10, вращение камеры будет в виде "многоугольника"...
Я честно говоря не очень понял. И вообще не врубаюсь зачем в движках сделано так, чтобы это все можно было по разному настроить. По моему единственная рабочая схема такая:
1) Камера двигается плавно в зависимости от FPS
2) Физический тикрейт работает 1/60
3) Как-то все работает и вместе и хорошо куда нажать, чтобы так было
И почему везде не настроено так по умолчанию? Кому блять может понадобится по другому и зачем?
Здесь всё подробно описано:
https://docs.godotengine.org/en/stable/tutorials/physics/interpolation/index.html
>Физический тикрейт работает 1/60
>может понадобится по другому и зачем?
Ты знал, что у многих игр физика 30 Гц, а то и 15 Гц? И наоборот, у некоторых игр физика >200 Гц. В Godot по умолчанию установлено 60 Гц просто потому что это наиболее популярная частота обновления монитора.
С мониторами тоже не всё так просто. Давно уже существуют мониторы >120 Гц, но разница на глаз ощущается даже между 60 и 75 Гц, а 75 Гц уже очень древний стандарт в мониторах. Если у тебя физика зафиксирована на 60 Гц без интерполяции, на всех мониторах >60 Гц физ. объекты будут дёргаться.
Алсо, совет: если ты где-то в коде на мышь хочешь реагировать, накапливай смещение мыши в input и сбрасывай накопленное в process/physics_process. Поскольку у геймерских проводных мышей >2000 Гц обновление, даже у офисных беспроводных >125 Гц - ошибки с плавающей точкой и лишние вычисления...
>var mouse_movement: Vector2
>func _input(...): # вызывается 2000 раз в секунду
>_ if event is Mouse...:
>_ _ mouse_movement += event.relative
>func _process(...): # вызывается 60 раз в секунду
>_ react_on(mouse_movement)
>_ mouse_movement = Vector2.ZERO
Избавляет от лишней головной боли.
>mouse_movement += event.relative
А, в движке есть вроде как аккумулятор событий (?):
https://docs.godotengine.org/en/stable/classes/class_inputevent.html#class-inputevent-method-accumulate
Правда, я его пока не использовал. Новая фича?..
Мне не нравится твой смех, поэтому этим путем я не пойду.
>Если у тебя физика зафиксирована на 60 Гц без интерполяции, на всех мониторах >60 Гц физ. объекты будут дёргаться.
Я правильно понимаю, что нужно:
1) Оставить физику на 60 Гц
2) Включить (?) интерполяцию
3) Вызывать все движения физ объектов в т.ч. камеры в physics_process
И все будет тип-топ и при 30 FPS, и при 60 FPS, и при 120 FPS?
>Ты знал, что у многих игр физика 30 Гц, а то и 15 Гц?
Типа для производительности?
>Ты знал, что у многих игр физика 30 Гц, а то и 15 Гц? И наоборот, у некоторых игр физика >200 Гц. В Godot по умолчанию установлено 60 Гц просто потому что это наиболее популярная частота обновления монитора.
Ну тип это не объясняет, почему интерполяция не включена по умолчанию. Тип, какая разница какой тик пер секонд у физики. Камера то все равно должна двигаться нормально
Если ты меняешь позицию камеры без привязки к какому-либо физическому объекту, то тебе не нужна интерполяция, просто обновляй позицию камеры внутри _process и она отрендерится на следующем же визуальном фрейме. Но если ты например хочешь следить камерой за каким-то юнитом, то камера очевидно будет двигаться только при обновлении позиции этого юнита, т.е только при обновлении физики. И если у тебя физика обновляется раз в 1/60 секунды, то и камера будет залочена в 60 FPS, вот тут и нужна интерполяция.
>Необходимо плавное вращение и детект коллизий одновременно - с разными частотами обновлений.
Детект коллизий чего с чем? Если твоей камеры с условными стенами, то ты получается хочешь сделать саму камеру физическим объектом и обновляться она будет только с частотой физики. Соответственно передвигаешь камеру внутри _physics_process и на каждом визуальном фрейме интерполируешь ее позицию чтобы визуально не лочить движение в 60 FPS, в чем проблема-то?
Ну т.е. интерполяция имитирует обычное движение камеры, как внутри _process, но для камеры, которая внутри _physics_process. Т.е. по сути ее можно включать по умолчанию для всех проектов
Интерполяция движения камеры нужна только в проектах, где сама камера - физический объект. Если как в моем примере, у тебя камера просто следует за каким-то физическим объектом, то там нужно интерполировать движение этого объекта, а не камеры.
Если камеры следует за каким-то физ объектом, а не просто перемещается по воздуху (хотя тут тоже вопросы к, например, мыши, как писал анон выше), то она двигается в зависимости от движения этого объекта. Все равно что камеру повесить на голову игрока в игре от первого лица. Не?
>то она двигается в зависимости от движения этого объекта
Ну, а объект без интерполяции его движения будет двигаться только при обновлении физики, т.е в 60 FPS по умолчанию.
>Оставить физику на 60 Гц
Нужно смотреть, что нужно твоей игре. Как правило, слишком редкая симуляция пропускает коллизии; слишком частая симуляция впустую нагружает ЦПУ. Количество объектов и скорости движений влияют. Тримешам нужна точность выше, чем примитивам.
>И все будет тип-топ
Да, по идее, но в некоторых случаях нужно какое-то собственное решение, например, в мультиплеере, в хардкорных играх на высокую реакцию игрока и т.п.
>для производительности?
Да, разумеется. Это примерно как v-sync - чтобы не занимать компьютер лишними вычислениями.
>>1049731
>почему интерполяция не включена по умолчанию
>>1049737
>включать по умолчанию для всех проектов
Потому что:
1. Не всем подходит, добавляет инпут лаг.
2. Если у тебя 60 FPS + 60 TPS, то разницы нет.
3. Godot следит за тем, чтоб ты ничего не трогал вне _physics_process (warning отключается в настройках). Потому что тогда интерполяция просто ломается.
4. Телепортация объектов слегка усложняется.
Я ещё не полностью прочитал документацию...
>>1049733
>Но если ты например хочешь следить камерой
>>1049738
>проектах, где сама камера - физический объект
Во-первых, в 99% игр камера следует за каким-либо физическим объектом плюс сама имеет коллизию, предотвращающую клипинг камеры "в текстуры". Исключением будут только некоторые стратегии, фиксированная камера, простые головоломки...
Во-вторых, Godot предупреждает (warning) обо всех трансформах в проекте; скажем, MultiMeshInstance необходимо обновлять в _physics_process, если вы включили интерполяцию физики в проекте, хотя в MultiMeshInstance в принципе отсутствует физика. Достаточно странно, но, наверное, причина есть...
>Нужно смотреть, что нужно твоей игре. Как правило, слишком редкая симуляция пропускает коллизии; слишком частая симуляция впустую нагружает ЦПУ.
3d игра от первого лица. Так что 60 тиков вроде как раз
>Да, по идее
Понял, спасибо
> Не всем подходит, добавляет инпут лаг.
Он там минимальный, вроде
>Если у тебя 60 FPS + 60 TPS, то разницы нет.
Ну ща игры редко лочат на макс 60 fps.
>Телепортация объектов слегка усложняется
В смысле телепортация? Там же просто меняется global_position
>3d игра от первого лица
Есть разные "3д игры от первого лица": можно сделать спокойную бродилку с минимумом взаимодействий, а можно сделать скоростной паркур с кучей падающих обломков окружения... Вот второй игре рационально завысить тикрейт физики, а первой можно и снизить.
>В смысле телепортация?
В самом прямом: когда движение отсутствует.
>Там же просто меняется global_position
А движок пытается это изменение автоматически интерполировать, создавая видимое движение от предыдущей позиции к новой, которого нам здесь совершенно не нужно, т.к. мы телепортируемся.
Ты вообще ссылку выше по треду не открывал?
https://docs.godotengine.org/en/stable/tutorials/physics/interpolation/physics_interpolation_quick_start_guide.html
>Be sure to call Node.reset_physics_interpolation on nodes after you first position or teleport them, to prevent "streaking".
Конечно, это всего 1 вызов, но придётся держать постоянно в уме, когда что-то куда-то двигаешь.
>>1049727
>вроде как аккумулятор событий
Вспомнил, где я его видел - в классе Input:
https://docs.godotengine.org/en/stable/classes/class_input.html#class-input-property-use-accumulated-input
Но странно, что
>Note: Input accumulation is enabled by default.
А я точно помню, что на 3.x у меня процессор сильно напрягался из-за движений мышки. Изменили что ли?
Хм... Судя по документации:
Input.use_accumulated_input существует с Godot 3.5.
InputEvent.accumulate() существует с Godot 3.1.
Значит, у меня проблемы были в 3.2-3.4...
>Конечно, это всего 1 вызов, но придётся держать постоянно в уме, когда что-то куда-то двигаешь.
Речь идет именно про телепорт? Т.е. обычное перемещение, какой-нибудь apply impulse и т.п. не считается?
>Ты вообще ссылку выше по треду не открывал?
Открывал, но я не усваиваю гумозный язык документаций. Мне бы на пальцах объяснения...
>>1049791
Бля, открыл ссылку, прочел про Node.reset_physics_interpolation
Какое-то говно получается. Че, мне каждому объекту в physics_process после move_and_slide нужно вызывать reset_physics_interpolation?
>apply impulse и т.п. не считается?
>>1049792
>после move_and_slide нужно вызывать
Ещё раз. Что такое интерполяция?
https://ru.wikipedia.org/wiki/Интерполяция
Вот у тебя, допустим, 60 фпс и 30 тпс:
1 - 1 - vector2(1, 1)
2 - 1 - vector2(1, 1)
3 - 2 - vector2(1, 2)
4 - 2 - vector2(1, 2)
Как видишь, тут кадры 2 и 4 повторяют кадры 1 и 3 - поскольку физика работает в 2 раза медленнее. Мы увидим скачкообразное движение. Как исправить?
1 - 1 - vector2(1, 1)
2 - 1 - vector2(1, 1.5)
3 - 2 - vector2(1, 2)
4 - 2 - vector2(1, 2.5)
Мы вычислили промежуточные значения 1.5 и 2.5 - получилось более плавное движение. Физические вычисления происходят в 1 и 3, но выходит плавное движение между этими кадрами, будто их больше.
Теперь представим, что мы телепортируемся:
1 - 1 - vector2(1, 1)
2 - 1 - vector2(1, 1)
3 - 2 - vector2(1, 100)
Интерполяция найдёт промежуточное значение:
1 - 1 - vector2(1, 1)
2 - 1 - vector2(1, 50)
3 - 2 - vector2(1, 100)
Но нам это не нужно. Нам нужна точка 100, а не 50.
Поэтому при телепортации нужно сообщать движку: "интерполяция здесь не нужна, не интерполируй".
Так понятно?
>не усваиваю язык документаций
У Godot одна из лучших документаций в айти.
> Например, что за "типмиксинг" такой?
А у меня встречный вопрос, зачем ты пишешь "типмиксинг"? Никто так не пишет, принято говорить либо "тайп миксин" либо "смешивание типов".
> Зачем нужен?
Код - лучшая документация ©
Так понятно, да.
Спасибо большое.
И всем остальным годачерам, кто принял участие в обсуждении
1) Там один и тот же текст и для анрыла и для юнити
2) Это зависит не от самих движков, а от СДК андроида
3) Начиная с андроид АПИ версии 35 это будет по умолчанию
4) Для более ранних версий просто флаг компиляции, в Годот или добавят или напишут в статье как сделать, это в любом случае будет касаться в первую очередь шаблона экспорта, а не игры из редактора
Я текбе больше скажу, ещё в мае в разрабатываемую 4.5 её добавили https://github.com/godotengine/godot/pull/106358
И в блог посте 4.5.бета1 писали https://godotengine.org/article/dev-snapshot-godot-4-5-beta-1/
>Important (Node3D)
>Pivot (Node3D/Marker3D)
>_ Anchor (RemoteTransform3D)
Pivot ставим в точку, вокруг которой хотим вращать; Anchor ставим в позицию Important, указываем ему Important. Вращая Pivot, видим вращение Important вокруг него, несмотря на то, что он лежит отдельно. Кажется очевидным, но я не сразу додумался.
Видео 1: вращение вокруг ног (плохо).
Видео 2: вращение вокруг рук (лучше).
>>1049206
>меньше идей
Идей у меня много, но реализовать не получается.
Пример идеи: смотри видео 3. Проблемы:
1. Дизайн: одно дело - вращать машинку, другое - полноценного гуманоида. Какие анимации нужны? Процедурно-физические или хватит обычных? Как, в принципе, результат должен будет выглядеть? Стилизованно-мультяшно или реалистично? И как сглаживать переходы состояний - резко, плавно?
2. Техническое: вращать RigidBody3D легко, но тут CharacterBody3D всем управляет, как его вращать? Создавать отдельную RigidBody3D модель? Весь CharacterBody3D заменить на RigidBody3D (опять)? Физический ragdoll каким образом настраивать? А возможных глюков физики как надёжно избегать?
3. Мотивация: а нужно ли мне это вообще? В чём, собственно, фан? Может, стоит на чём-то другом сфокусироваться? Тут и без этого куча проблем... Повторение механики из GTA на гуманоиде может разочаровать, такое редко где встретишь. Если оно выглядеть будет тупо, может, и не стоит оно того...
Теперь представь, что почти каждая идея имеет как минимум столько же проблем, но чаще ещё больше. Корабли и острова - это так, мелочи. Благодаря им я значительно уменьшил масштаб игры и проблем...
>>1049393
>это не твой ньюфаг бложик
А мне постить разрешаешь?
У меня есть окошко и оно открывается и закрывается по нажатию правой кнопки мыши. Есть вот эта вот _process(_delta) которая читает инпут (ну то есть есть ли он или нет). Проблема в том, что читает так быстро, что по нажатию кнопки окошко начинает закрываться и открываться каждый кадр.
Я уверен, что это классическая проблема, но я чёт не могу придумать элегантного решения. Да я лох.
А ещё есть _input(event) которая реально читает инпут, без привязки к фреймрейту.
> if event is MouseEventButton and event.index == 1 and event.is_released(): do_left_click_stuff()
Если у тебя стандартное окно из коробки с классами, то там есть свои встроенные методы. Например, есть сигнал close_requested тебе надо просто подписаться на него и делать своему окошку hide() там в подписочном коллбэке.
Да. Вот это норм зашло. Спс.
>>1049926
Да вот в том-то и дело, что там кастомный кал поверх кастомного кала и весь код ебаная лапша. Спасибо за предложение.
> кастомный кал поверх кастомного кала и весь код ебаная лапша
Вкуснота! Пости в тред скрины лапши с пометкой "в чём он неправ?" покушоем.
Лел. Да там совсем очко. Там ещё по классике кросс-референс между нодами и т.д. Я откоментил более-менее, чтоб самому не забыть нах как оно работает и пока даже всякий раз, как приходилось там что-то менять, оно даже не ломалось.
Запилил диалоговую систему (окошко с текстом ога) с возможностью выбрать кто говорит (гг или нпс), изменить позицию окошка нпс по пресетам, звук у букв, когда они печатаются и сама "анимация" печатания, ту да же кастомные теги в тексте (типа чтобы замедлить или остановить печать на секунду), ну и так по мелочёвке.
Я знаю что есть готовые системы, но я слишком ебло чтоб в них разобраться. Я лучше буду свою ломать, но знать как она работает, чем в чужом кале ковыряться.
Даже больше скажу. Я как дятел ебаный перенёс в каком-то виде систему ивентов из рпгм, потому как просто не знаю как организовать сцену по другому и теперь весь сценарий сцены вытягивается в ебейшую лапшу. Вот у меня есть сцена, там люди говорят минут на 30. Так вот она 2000 строк бля.
> систему ивентов из рпгм
А в чём она заключается? Можешь вкратце расписать? Ну а я рискну предложить варианты замены.
Пока ты нажимаешь кнопку мыши у тебя process может и 4 раза выполниться. По правильному делай так: создай input action с кнопкой мыши, назови его CLICK и в input/ gui_input проверяй event.is_action_pressed("CLICK"), оно само срубит все ложные срабатывания, хотя при необходимости можно и их получить проверкой event.is_echo
Последовательность действий в сцене. У меня сейчас каждая сцена точно так же выглядит (ну не так красиво, конечно, но через классы удалось всё более-менее читаемо и красиво оформить).
>>1049933
Ну дыа. Я так и сделал. Только не event.is_action_pressed, а event.is_action_just_pressed потому какой-то хер на ютубе сказал, что именно джаст прессед обрабатывает типа только нажатие, а не сам факт, что кнопка нажата вот прям сейчас.
Такого метода нет у event: InputEvent, он у класса Input
А класс Input у нас синглтон. А так же InputMap у нас синглтон. Вот и думойте.
Ладно, рассортировал руками с помощью кнопочки delete - показывает все используемые ресурсы. Неудобно, но штош.
Скриптик написать уровня:
> for file in files: if file.owners > 0: do_do()
>Нужно изобрести велосипед.
Почему ты не хочешь почитать документацию?..
Я вот так у себя сделал:
>func _unhandled_input(event: InputEvent) -> void: # будет вызываться только если ничто не "съело" событие
>— if mode == Mode.POPUP and state == State.HIDDEN: # проверяем, что меню закрыто и настроено как попап; альтернативой является, например, открытие извне
>—— if popup_shortcut and popup_shortcut.matches_event(event): # проверяем настроенный шорткат и сравниваем его с событием
>——— open() # запускаем анимацию открытия и т.п.
https://docs.godotengine.org/en/stable/classes/class_shortcut.html
>func _gui_input(event: InputEvent) -> void: # вызывается исключительно Control-нодой, если курсор над ней
>— if state in [State.OPENING, State.FOCUSED]: # реагируем на клики только если открываемся или уже открыты
>—— if event is InputEventMouse: # если это мышь...
>——— if event is InputEventMouseMotion: # ...двигается
>———— _handle_focusing_at(event.position) # передаем фокусировку кнопкам (у меня вычисляется позиция сектора круга на меню, поэтому мне это здесь нужно)
>—— _handle_action(event) # если произошёл клик и т.п.
>— accept_event() # "съедаем" событие (метод Control), скрывая его от всех остальных нод под курсором, и от остальных нод в игре, имеющих _unhandled_input
https://docs.godotengine.org/en/stable/classes/class_control.html#class-control-method-accept-event
>func _handle_action(event: InputEvent) -> void:
>— if event is InputEventMouseButton: # если кнопку...
>—— if not event.pressed: # ...отпустили...
>——— match event.button_index: ...какую именно?
>———— MOUSE_BUTTON_LEFT:
>————— _handle_click() # нажимаем кнопку меню
>———— MOUSE_BUTTON_RIGHT:
>————— _cancel() # возврат назад или скрытие меню
Делал это больше года назад, что-то могло в API измениться... Сейчас глянул, нашёл _shortcut_input и InputEventShortcut - наверное, недавно добавили. Предполагаю, что лучше будет их использовать.
Рекомендую подтверждать клик/закрывать меню конкретно при отпускании клавиши/кнопки мыши, поскольку именно такое поведение используется в Windows, Android, на веб-сайтах и т.д. Если игрок уже зажал кнопку, но передумал, то он может сдвинуть курсор в сторону от кнопки, тем самым изменив свой выбор или полностью от него отказавшись. Это, как мне кажется, ожидаемое поведение в любом GUI.
Речь, разумеется, о "виртуальных" кнопках, которые отображаются на экране/в меню/окне. Исключение составляют хоткеи/шорткаты - физические кнопки (отменить нажатие технически невозможно), и ещё кнопки, действие которых растянуто во времени (длительность нажатия кнопки влияет на результат).
Ну если тебе требуется 8 часов с нейронкой это разбирать, значит это пока что не рутина.
Я архитектурный идиот, почти все что делаю сразу оформляю в периспользуемые компоненты/модули. В идеале делаю один раз. Типа. Так ускоряю свою "рутину". И проебываю время на никому не нужную архитектуру, о чем потом плачусь нейронке, а она меня по головке гладит и успокаивает. Но мне это доставляет удовольствие, а если делать в лоб, но быстро - наоборот. Поэтому никому не советую.
Еще для ускорения можешь нейронку подрубить прямо в проект, пусть она за тебя работает, чем пытается тебе, мясному куску дерьма, объяснить элементарные вещи.
Что ты там разбираешь? шизло
Конкретно, как это реализовать в коде? На ютубе тысячи видео - реализуется за пол часа.
Или с точки зрения геймдизайна? Чукча не читатель, да? Пиздец. Я конечно понимаю, что нейронку можно использовать в качестве быстрого поиска или аналитики, но 8 часов...
ЕРПшит с годеттой он. Там в длинных чатах у фильтра жопа отваливается.
2) Где удобнее тестировать для годот? (substance painter?)
3) Где удобнее делать 3D анимацию для годот? (сразу в годот, или же, скажем, в блендере?)
>fix
2) Где удобнее текстурировать для годот? (substance painter?)
Я свое 3д в блокбенче делаю. Он не только кубы, но и лоуполи. Перекидываю через глтф в годот.
Там на днях как раз 5.0 блокбенч выходит, с гитхаба уже бету взять можно.
За софт спасибо, но совет так себе, я сам моделить собираюсь. .
Проще. Я до этого проекта с 3д вообще не работал, ни в плане моделирования ни в плане движков. А теперь этот проект близок к финалу демо.
Плюс мне нужны были пикселизированные текстуры.
Можешь показать какие модельки у тебя (тоже хочу лоуполи, но не хочется в какие-то ограничение по моделингу попасть).
Такого уровня у меня. Полистай тут чужие: https://sketchfab.com/tags/blockbench
Есть написанная мною DQN нейронка, которая принимает на вход позиции фишек на доске и выдает лучший ход. Проблема: алгоритм написан и обучен на питоне, потому что по другому я не умею.
Можно ли интегрировать файл .py в проект, чтобы мой .gd-скрипт обращался к нему в реалтайме и обменивался с ним информацией?
С гдскриптом мирного решения не будет. Как вариант - поднимать вебсокет клиент который будет стучаться в вебсокет сервер на питоне, и так они будут общаться. С# - ты сможешь запустить питон как дочерний процесс и обмениваться с ним данными присоединившись к его cmd и имея возможность туда писать и оттуда читать. К самому с# из гдскрипт придется коннектиться с помощью сигналов и/или годот рефлексии позволяющей мультиязычное общение.
>С гдскриптом мирного решения не будет
Не говори ерунды, ты с движкосрача сбежал?
>>1050210
Можно через сокеты, а можно вот так:
https://docs.godotengine.org/en/stable/classes/class_os.html#class-os-method-execute-with-pipe
По идее, должно запускаться вот так:
>var pipes := OS.execute_with_pipe("py", ["script.py"], false)
Дальше ты должен обмениваться через:
>pipes.stdio
API к которому здесь:
https://docs.godotengine.org/en/stable/classes/class_fileaccess.html
Подробнее про пайпы читай тут:
https://en.wikipedia.org/wiki/Anonymous_pipe
Также ты можешь подключить сам Python к Godot.
Но если хочешь портативности (опубликовать игру), рекомендую переписать нейронку на C++ и затем подключить её как GDExtension. Иначе придётся устанавливать Python каждому игроку...
Как самое мирное решение все же будет поднять нейронку в виде отдельного сервиса и общаться с ней как твоей душе угодно. Способов тут описали множество, но этот самый бесхитростный, одноклеточный и универсальный. Остальное скорее про умственную гимнастику, потому что на выходе лучше не будет.
так я код не пишу, я в основном ищу пиздатые ассеты и пытаюсь из этого игру сделать. пока тяжело чёт.
Это часть дизайна игры. Как ты задумал - так и должно быть. Но если ты хочешь совета, делай по чекпойнтам перед боссами, костры не делай, они всем уже надоели, за костры тебя захейтят.
>>1050354
> я в основном ищу пиздатые ассеты
Мой дед говорил, делай пиздатые ассеты и бросай их в ассетлиб. Они не пропадут, игорами тебе вернутся.
Это к движку отношения не имеет. Кури основы геймдизайна, ИГРАЙ в игры сам, пиши дизайн-документы, займись левелдизайном - узнаешь ответ
Что бы ты не выбрал - всегда помни про транзакционность сохранений, чтобы ты всегда мог гарантировать что если сохранение не смогло записаться по любым причинам - всегда могло открыться предыдущее. В остальном че хошь то и делай.
пишу отчёт, я так нихуя и не понял как делать нормальное столкновение фаерболов с монстриками. они либо улетают нахуй все либо ничего не происходит
func koneц_kazhdogo_hoda() -> void:
____sozdat_cartы_vraga()
Нужно просто выработать особое программисткое мышление и уметь юзать нейронки, тогда всё получится.
Это база для необучаемого луддита. У реальных волков-базовичков имеющих за плечами крупный бэкграунд сразу в нескольких областях база совершенно другая.
Я не геймдев по основной работе, так что показывать кроме одного прототипа особенно нечего.
Ммм... Ясненько. Вот такие у нас базовики закатываются в тред и поучают, как нам игры делать.
А какая разница? Нейронки везде хороши, особенно в играх. Можешь свои ненейроночные игры показать, в противовес так сказать.
>помни про транзакционность сохранений
Поясняю нормальным человеческим языком:
1. Сохраняешь данные в save2.data
2. Файл создался? Данные корректны?
ДА: если хочется, удаляем save1.data
НЕТ: сообщаем об ошибке сохранения
Всё. Больше про это вспоминать не нужно.
Ты нормально можешь пояснить, че ты хочешь? Ты че там, пытаешься реальную симуляцию физики приделать к 2d игре? Ты совсем ебобо?
Он не программист и делает игру заказывая код у чат-бота.
да я ебу, гопота пишет добавь коллайдер и коллайдер и там как не тыкай они вообще нихуя не соприкасаются урона то есть нет нихуя.
>>1050464
Сделай пару шагов назад и пройди официальный туториал на сайте годота. Чтобы нейронка была полезна тебе нужно хотя бы в общих чертах понимать то, что она тебе говорит, и знать как это применять. Это будет быстрее, чем каждый день по 8 часов вслепую получать изнасилование от нейрокода.
https://docs.godotengine.org/en/stable/getting_started/introduction/index.html - на английском.
https://docs.godotengine.org/ru/4.x/getting_started/introduction/index.html - на русском.
Вспоминать не нужно только если изначально знаешь о таких ньюансах, а вот помнить о таком стоит.
Лол. Ебало этого вайбкодера представили? То, что можно сделать по туториалу из ютуба за пол часа он уже несколько дней пытается с помощью нейронки сотворить.
ну попробую, но мне не нравится что там дохуя знать надо для того чтобы что-то сложнее примеров сделать
>>1050478
ну это если ты опытный то тебе легко конечно, у меня бэкграунда в айти нет я чисто работяга как могу на волевых.
Лол, а ты че, думал, что ща напишешь два-три промта и игра готова? Вот ты ахуеешь, когда если дойдешь до момента, где поймешь, что движение - это не просто velocity менять.
>ты опытный то тебе легко конечно
Я нихуя не опытный. И мне постоянно приходится курить туториалы и мануалы, как и всем тут.
>как могу на волевых.
Сидеть пердеть в кресло и ныть нейронке "зделай мне збс игру" - это на волевых?
>мне не нравится что там дохуя знать надо для того чтобы что-то сложнее примеров сделать
Не нравится? Вебм релейтед
>мне не нравится что там дохуя знать надо
С нейронкой тоже дохуя знать надо. Они пока не на уровне кнопочки "сделай заебись".
>но мне не нравится что там дохуя знать
Твой юношеский максимализм радует. Как линейка прошла?
Нет, измеритель свитча это я. А ты мультиплеерные кнопки или антипаттерн-синглтон?
Ты пока брал за щеку у чатагпт похоже маски и слои у чегото вырубил.
Если что, знайте.
Можно же документацию немножко почитать, она даже частично переведена, там много интересного.
>там много интересного
Что самое интересное ты видел в документации? Я помню удаленную страницу про зашифрованные сейвы.
>удаленную
Литералли...
Всё, если ты
>узнал, что оказывается порядок нодов в сцене, влияет на их загрузку
Персонально советую изучить раздел "Руководство-Лучшие практики"
>она даже частично переведена
Ох, эти вечные обсеры ленивых помогаторов. Везде этот частичный перевод 100 летней давности. Самое ленивое комьюнити, зачем вообще браться за это?
Документация разбита на абзацы. Когда в оригинале изменяется один абзац, во всех переводах этот один абзац "слетает" - становится неактуальным. Оригинал обновляют англоговорящие люди, поэтому просто не способны обновить всё языки сразу. А энтузиасты не обязательно доступны 24/7. Вот перевод и неполный.
Вообще, в 2025 мог бы и с автопереводчиком во всём разобраться; они достаточно хороши для технической литературы. Но термины по-прежнему лучше всего в интернете искать на английском, а не на русском: там больше актуальных обучающих материалов/новостей.
С LLM тоже лучше только на английском общаться. Ломанный английский они понимают лучше русского. Возможно, из-за сложности русского языка, но точно недостаточно тренировочных данных в интернете...
ПО на ПК тоже лучше на английском держать. А то насрут в UI непонятными терминами, которые никак не переводятся обратно на английский и на русском не находятся нигде, и сиди ломай голову весь день...
Такова реальность всего айти, к сожалению.
Один стандартизированный технарский язык это не так уж плохо и даже логично. Но думаю настало время хуячить нейроперевод прям с самого начала, а не ждать пока вася почешется для перевода на русский, а выньхуй на китайский. Все же автоматически, переводят они не хуже богомерзких людишек, судя по докам годота.
>Вообще, в 2025 мог бы и с автопереводчиком во всём разобраться; они достаточно хороши для технической литературы.
С чего ты решил что я не знаю англ? Я офигеваю над ленивым комьюнити, так везде, не только в годоте.
>Я офигеваю над ленивым комьюнити, так везде
Потому что переводить с английского на локальные языки - самая бесполезная и неблагодарная трата своего времени, как бывший переводчик говорю. Всегда все отстает, всегда что-то будет неполным или коряво переведенным, всегда твоему читателю потребуется дополнительная инфа из гугла и сторонних ресурсов, а они ведь тоже не переведены, а весь интернет не переведешь - и в этом плане перевод даже вреден, гугля ошибку "Interpolated triggered from outside physics process" человек получит гораздо более полную выдачу чем по "интерполяция вызвана извне физического процесса". Больше пользы пытаться обучить весь мир английскому, чем пытаться перевести все необходимое.
Ленивая бесполезная, оправдывается.
Тут проблема в том, что ты начинал переводить и забросил, зачем тогда вообще начинал? Зачем этим маневры?
Перевод нужен для популяризации среди вкатунов. Тебе нравится теха/яп? Хочешь чтобы она стала популярнее? Берешь и облегчаешь вкат (например учить язык программирования с нуля и английский с нуля - непосильная задача). Даже хорошо владеющий английским, будет комфортнее прочитать на родном языке бегло вечерком (что опять увеличивает популяризацию).
сейчас опять сработает макакин-триггер и набегут постеры с рекомендациями чтобы я использовал переводчик или учил английский
Учи английский. Твоя проблема в том, что ты его начинал учить и забросил, и теперь тебе некомфортно, а другие тебя спасать должны.
>Один стандартизированный технарский язык это не так уж плохо и даже логично.
Никто не спорит. Печаль в том, что, скажем, в СССР существовало локальное сообщество IT с языками программирования на русском, ЭВМ на русском, всё на русском. Что от этого осталось? 1С? КуМир?..
>нейроперевод прям с самого начала
В браузерах автоперевод страниц много лет есть.
>>1050638
>офигеваю над ленивым комьюнити
Перевести могут лишь те, кто уже знает английский, но перевод необходим лишь тем, кто его не знает... Предположим, для друга ты переведёшь, а зачем переводить для каких-то рандомных школьников?
>>1050642
Верно. Хотя вместо английского пытались что-то изобрести с нуля, но те языки так и не взлетели.
>>1050654
>забросил, зачем тогда вообще начинал?
99% игр не доходят до релиза по массе причин. Ты предлагаешь 99% начинающим не начинать? И так с абсолютно любым занятием человека. Не все люди рождены достигаторами, всегда идущими до конца. Перевод документации вообще бесконечен, пока разработка движка продолжается. Ты платил им за перевод? Нет? Тогда в чём твоя претензия сейчас?
>Берешь и облегчаешь вкат
Без английского вкат всё равно будет сложным. Как минимум потому, что языки программирования на английском. Или предлагаешь 1С в Godot встроить?
>английский с нуля - непосильная задача
В нормальных школах английский вторым языком начинают преподавать где-то в 5-6 классе, я думаю. Настолько молодым вкатунам Godot не по силам. А старикам за 50, которые немецкий учили в школе, наверное, вообще геймдев не интересен, либо они постараются выучить английский без нытья. Так-то программирование учить лучше на том же КуМире, особенно если ты английский ещё не знаешь...
>комфортнее прочитать на родном языке бегло
У меня вот были двойки-тройки в школе за уроки английского, но техническую документацию бегло просматривать мне проще на английском.
Привычнее видеть все эти английские термины на латинице, без склонений по падежам, короткими и понятными с первого взгляда словами. Какая-то художественная выразительность этим текстам не требуется, поэтому русский для них - это оверкилл... Некоторые термины вообще только на английском запоминаю и не могу вспомнить русский перевод.
Например, у "anti-aliasing" официальный перевод в Википедии "экранное сглаживание", но я его так не называю никогда. И если в настройках игры увижу "экранное сглаживание", буду ломать голову. А вот недавно я ломал голову над словом "свечение" в переведённых настройках игры. Свечение чего?.. Источников света?.. Ааа, так это же "bloom", лол!..
Кстати, там на твоём скриншоте один язык долго болтался где-то внизу с остальными. Его подняли, видимо, по политическим причинам, где-то между концом 2024 и началом 2025. А один из носителей данного языка ведёт агрессивную борьбу против движка Godot - ненавидит и стремится уничтожить.
>ведёт агрессивную борьбу против движка Godot - ненавидит и стремится уничтожить
Как и за многими шизами за ним было прикольно наблюдать. Похожее сейчас с UE5 происходит, только масштабнее. Некий техноблохир Threat Interactive натравил своих миньонов на даунвотинг всех UE5 игр в стиме. Индюки на реддите плачутся.
Наш годотовский, по сравнению с, просто милый беззубый малыш.
> если хочешь портативности (опубликовать игру), рекомендую переписать нейронку на C++ и затем подключить её как GDExtension
This. Эхх, а так хотелось легкого пути.
Спасибо за советы, ананасы
Можно сколько угодно маняврировать, но перевод это популяризация техи.
Я не понимаю, почему там всё так СЛОЖНО. Какие-то ГИГАНТСКИЕ имена переменных и типов - мне что, их придётся так и использовать всегда? Почему нельзя использовать встроенные переменные целевого ЯП? Память компьютера всё равно одинаковая же.
Я уже делал DLLки на Delphi/FreePascal и понимаю принципы их использования: DLL экспортирует свои функции, а EXE их импортирует через API системы. В GDExtension же происходит какой-то странный хаос - инициализация, деструкция, бла-бла-бла, 6 МБ json с непонятными данными, 170 Кб непонятный хэдер... Понаставили каких-то избыточных преград, имхо.
Всё, что я хотел добиться от Godot, это:
1. Вызвать dll = LoadLibrary("my.dll");
2. Вызвать my_func = GetProcAddress(dll, "MyFunc");
3. Позволить мне вызывать my_func() из GDScript;
4. Вызвать FreeLibrary(dll) перед закрытием игры.
ВСЁ! Буквально 4 строчки кода на любом языке.
Так почему я должен копаться в GDExtension?
Туториал для ньюфагов, кто не знал про DLL:
https://learn.microsoft.com/en-us/cpp/build/linking-an-executable-to-a-dll?view=msvc-170#how-to-link-explicitly-to-a-dll
Видите, всё чрезвычайно просто и понятно, так ведь?
А теперь сравните с тем, как юзать GDExtension:
https://docs.godotengine.org/en/stable/tutorials/scripting/gdextension/gdextension_c_example.html
Я потерял смысл жизни за первые 5% этой страницы.
Кажется, что будет проще скачать исходники Godot и запилить велосипед, но что-то подсказывает, что создание встроенных модулей сделали ещё более сложным, чем тривиальное подключение DLL.
Есть объяснение этой проблеме? Без движкосрача.
Я использую Godot только из-за его простоты. И я надеялся, что GDExtension тоже будет крайне прост: подключился, используешь, отключился, легко же?
Алсо, в Godot есть класс OS:
https://docs.godotengine.org/en/stable/classes/class_os.html
Что им мешает сделать всего ТРИ функции:
>OS.load_library(path: String) -> int
>OS.get_proc_address(dlib_id: int, func_name: StringName) -> Callable
>OS.free_library(dlib_id: int) -> void
Это было бы чрезвычайно круто и очень просто.
Альтернативно, предлагаю класс DynamicLibrary:
>static DynamicLibrary.load(path: String) -> int # error
>DynamicLibrary.get_func(fname: StringName) -> Callable
>DynamicLibrary.free() # то же самое, что Object.free()
Почему этого всё ещё нет в GDScript? Это ж просто.
Извините за нытьё...
>класс DynamicLibrary
Не, без статика. Примерно вот так было бы:
>var dll = DynamicLibrary.new() # без загрузки
>dll.load("my.dll") # попытка загрузки
>if not dll.error: # успешно найдена и подключена
>_ var my_func: Callable = dll.get_func("MyFunc")
>_ if my_func: # если не null - нашли функцию
>_ _ result = my_func.call(arg1, arg2)
>_ dll.unload() # чтоб освободить память заранее
>dll.free() # если это потомок Object...
Остаётся только адаптировать под Linux (если вдруг понадобится написать игровой сервер на Godot), но, предполагаю, загрузка ".so" ничем не отличается.
GDExtension оставить для более сложных плагинов.
Поискал, кое-что нашлось.
Обсуждение предложения загружать DLL:
https://github.com/godotengine/godot-proposals/issues/1917
Недоделанный пулл-реквест:
https://github.com/godotengine/godot/pull/85741
Плагин GDExtension...
https://github.com/gilzoide/cffi-gdextension
...который подключает это:
https://github.com/libffi/libffi
>The libffi library provides a portable, high level programming interface to various calling conventions. This allows a programmer to call any function specified by a call interface description at run time.
Нужно попробовать...
>Так почему я должен копаться в GDExtension
1) Ты не в курсе о соглашении о вызовах и существовании ABI
2) Ты не задумываешься, что цель GDExtension не просто загрузиться, а иметь представление о его классах Godot и уметь работать с ними
3) Ты смотришь пример на C - тут накладывается ещё один уровень усложнения, т.к. сам Godot написан на C++ и оперирует классами, а в Си их нет
Технически от Dll требуется только экспорт функция инициализации, но что ты потом будешь делать - неясно. В обычной ситуации в функции инициализации происходит регистрация новых классов, а у тебя не будет к этому доступа.
>Нужно попробовать...
Явно не то что тебе нужно
Самое простое - на C++ написать GDExtension который даст в GDScript класс с нужными методами.
И вот вспомнил, если ты думаешь об одной ОС - винде, то можешь попробовать:
>OS.execute("rundll.32 my.dll,MyFunc arg1,arg2")
Надеюсь ты там не вирус делаешь
>иметь представление о его классах Godot
Но зачем? Это ж library - библиотека функций. Я не собираюсь обращаться к функциям Godot изнутри библиотеки. Мне нужно наоборот, обращаться из GDScript к своему коду на каком-то другом языке.
>>1050787
>Самое простое - на C++ написать
Не смог установить подходящий компилятор...
>OS.execute("rundll...
В таком случае проще будет написать классическую консольную утилиту и общаться с ней по "трубам"...
А что, идея-то вроде норм. Изучал эту тему - по идее, анонимные трубы будут по скорости не хуже прямого чтения/записи в оперативную память. Впрочем, если потребуется удалённое подключение, TCP лучше...
Ладно, нужно поэкспериментировать.
>Не смог установить подходящий компилятор...
Может стоит разобраться?! Тогда есть возможность даже лучше, называется CustomModule, это почти как GDExt только больше возможностей и вшито в сам движок.
https://docs.godotengine.org/en/4.4/contributing/development/core_and_modules/custom_modules_in_cpp.html
Навскидку, нужно поставить:
- Python посвежее
- scons (после установки питона выполнить команду `pip install scons` кажется )
- VSCode как редактор, он поддерживает с++ из коробки
- Компилятор - или MS Studio Community или попробовать CLang установить
Если у тебя винда после 2019 года версии (10 или 11) там есть WSL - эмулятор колнсоли линукса, там по идее через неё можно поставить
В общем думой, как-бы что не нравилось, выходы только такие.
И умпомяну что есть биндинги и под другие языки - rust, Go, Dart и на самом деле много других, если тебе с чем-то будет легче может
И ещё цикл видео о GDExt который много вопросов закрывает, от установки до примеров
https://www.youtube.com/watch?v=q2-dbwdTvck&list=PLhixpuPeRv9aDdsZbhTpsXguYRvMgyVQ-
> Видите, всё чрезвычайно просто и понятно, так ведь?
> А теперь сравните с тем, как
> Есть объяснение этой проблеме?
Да есть. Типобезопасность. Потокобезопасность. Годот по моему опыту намного сложнее уронить с крошем на десктоп. Все эти сложности с ГДЕ ящитаю сделаны для того, чтобы по максимуму сделать так, чтобы у тебя крошнулось во время девелопа, чтобы крошнулось у тебя, а не у твоих игроков.
>Python
>scons
Давно есть...
>VSCode
Не хочу...
>CLang
Не нашёл...
>rust, Go, Dart
C-подобные...
>>1050797
>безопасность
В геймдеве?..
Сижу на работе, пробую в свободную минуту начать хоть чета
Пока вот разбираюсь с базой, докуменатацию читаю когда ищу как че делать...
У меня мотивация пропала. ХЗ, просто ушла куда-то. Тупо скроллю треды.
Глянул один, но стараюсь всё дополнительно разбираться че да как
В туторе иногда не совсем ясно как именно что-то работает, нужно лезть и читать как функция работает какая-нибудь
Сделал вот в меню 2 кнопки и пустой лвл с камерой
Щас вот буду перса делать. Как я понял, нужно его сделать отдельной сценой и добавить скрипт ему просто
Вчера вытянул мотивацию из какого-то рандомного чела.
Были покалывания в кончиках пальцев? Я прям перетянул мотивации вчера.
Сколько то дней круглыми сутками кувыряю го вместо того, чтобы игорь писать. Нужда. На го может когда-нибудь смогу устроиться. Но так погано, пока этой херней страдаю забуду че у меня там как работает.
Я секунд 30 не мог понять что ты про ЯП
Я подумал, что в эту байду гоняешь сутками
Го благое дело, хотя бы потому что является частью нашего названия. И нам нем тоже игры делают. Иногда.
>>1050870
Эта байда тоже полезна. Лудшая настолка.
У говна, нет ООП и нет проверки повторного включения файлов (проблема рекурсии лежит на программисте, лол), это хрень меньше всего подходит для разработки игр.
Завис в 3D моделинге, теперь мне это нравится больше чем разработка игр, хотя делаю модели онли для игры.
Диды на ассемблере ебашили, а тебе тут бирочки-оборочки мешают. Записываю в очередные оправдания ничегонеделания.
А если бек к игре? Например не чат, а гигачатище. Ну типа он как раз для бекендских задач.
Ну, говно тоже можно съесть, никто не говорит что нельзя, но зачем?
> Диды на ассемблере ебашили
Что они ебашили? Сказал А, говори Б. Сравни софт 80х и софт 2010х.
У го есть зеленные треды и при этом парадигма одноцветных функций (встроенная асинхронщина, спрятанная под капотом). Для такого бэка он подходит очень хорошо.
мимо писал на ассемблере
Что угодно в общем то, в 80х в основном был TUI (текстовый юзер интерфейс) и сейчас он встречается. А потом что, текстовые редакторы или кнопочки в браузере, которые потребляют ресурсы видеокарты а без неё нагружают процессор?!
>Игры-то делаете?
Нет, я опять забросил.
29 августа наконец-то начал рефакторить лапшу в контроллере персонажа; ещё по-быстрому сделал замедление падения в воздухе; потом планировал реализовать наклоны с вращением через WASD... Вынужденно убрал прототип компаньона игрока - планировал сделать новую отдельную модельку.
Хочется заняться чем-то более существенным.
Как-то хочется сделать и обучить собственную специализированную языковую модель, но эти трансформеры зафлудили интернет совершенно бесполезными статьями о тупиковой архитектуре, повторять ошибки которой мне точно не хочется. Стандартные решения мне вообще не подходят.
Даже не знаю, как сформулировать свою задачу.
Непонятно, чего я хочу, но это вгоняет в тоску...
Похоже на еще одну игру про атаку титанов. Мне нравилась одна такая много много лет назад.
Попробуй создать лор к игре. Не факт что поможет, но это может возвратить к разработке старой игры.
У меня с лором/сценарием/диалогами труднее всего идет. Даже музыку ляпать кое-как осилил.
Без четкой идеи (не просто мысли "было бы круто", описанной во всех подробностях концепции) ты далеко не уедешь. Попробуй спиздить чужой концепт и подумать, что бы ты хотел сделать по другому. А если уж и с этим плохо, то ищи компашку из индюков, где будешь в роли программиста. Но этой так себе вариант, конечно
Ставил, без изменений.
Причём только в этой игре так, в других всё ок было. Впервые вынес фон музыку в отдельную сцену, мб в этом проблема?
Какие вопросы задает издатель во время переговоров? Как вообще с ними переговариваться?
>Видео
Прикольно, но я не буду в это играть из-за персонажа. Если бы он был харизматичным и интересным, а так дешевка какая-то. Работай. Отечественный геймдев сам себя с колен не поднимет.
Давай я тебе расскажу кое-что: Python в базовом исполнении как программа-интерпретатор написан C, потому он и называется высокоуровневым языком программирования, т.е когда ты используешь команды Python ты на самом деле используешь скомпилированные функции, написанные на C. Как бы такая надстройка. Базовое исполнение называется CPython (стандартный который ты скачиваешь в оф-сайта), есть еще Jython (написан на Java), IronPython (написан на .NET/C#). Т.е. по сути ты можешь сделать свой язык сам, создав собственно сам синтаксис и написав программу-интерпретатор к нему, если выучишь низкоуровневый язык программирования.
На создание низкоуровневого русского языка программирования у тебя уйдут десятилетия, и выхлоп будет не очень большой, поэтому этим никто не занимается.
Однако моя идея состоит в том, чтобы сделать набор функций, не привязанных к национальному языку - нейросеть, которая будет включать название функций на родном языке пользователя для оперирования ими. Нейросеть будет автоматизировать нейминг функций для языка. И делать это со 100% строгостью(без расхождений у разных пользователей). Допусти, для англа это будет start(), а для русского начать(), для турка başlat() и так далее. Чтобы русский смог прочитать код турка, нейросеть вернет команды в русский язык. Только так можно победить засилье гегемонии англосаксов в технологиях IT. Считаю что это первостепенная задача россиянина в этой эволюционной войне на выживание.
мимо
Платформа 1С и ее язык написаны на С++
>На создание низкоуровневого русского языка программирования у тебя уйдут десятилетия
Палю супер-имбу, которую можно сделать полностью на русском языке за неделю-другую расслабленного кодинга на ассемблере (если уже разбираешься в нужных темах), с производительностью как у чистого машинного кода и способностью собирать всё, что пожелаешь, как пожелаешь и из чего пожелаешь:
https://en.wikipedia.org/wiki/Forth_(programming_language)
>One of the early benefits of Forth was size: an entire development environment—including compiler, editor, and user programs—could fit in memory on an 8-bit or similarly limited system.
>The highest level of Forth code may resemble an English-language description of the application. Forth has been called a meta-application language: a language that can be used to create problem-oriented languages.
Спросил нейронку (DuckDuckGo):
>Are Forth language low-level?
>Forth is considered a low-level programming language because it operates closely to the hardware, allowing for direct manipulation of memory and efficient control of system resources. Its stack-based architecture and minimalistic design make it suitable for low-level programming tasks, especially in embedded systems.
Минусы языка? Это язык велосипедистов - и их велосипеды друг с другом несовместимы. Всё из-за чрезвычайной гибкости языка, в котором ничего кроме "слов" нет и можно переопределить даже символ, разделяющий слова. Программистов нужно держать под строгим контролем, иначе навелосипедят такое, что некому поддерживать...
>Нейросеть
Текущие языковые модели слишком ненадёжны для задач, где требуется точная передача смысла. Если в художественном тексте есть много пространства для манёвров - синонимов и иносказаний - то от программного кода любой адекватный человек ожидает чёткое следование заданным инструкциям, а не произвольную интерпретацию. Искусственные языки разрабатываются так, чтоб избежать любой двусмысленности (за редким исключением - не надо упоминать JS), тогда как в натуральных языках двусмысленность повсюду встречается, и в разных языках она разная. Короче, не нужно это. Оставь непредсказуемый вайб-кодинг тем, кому нравится бегать по граблям...
А когда нейронки станут очень умными и смогут писать чёткий код - программистами будут уже не люди, а машины, созданные людьми. Вот ты когда-нибудь задумывался, что такое "программатор"? Хотел бы забивать программу в память микроконтроллера ритмичным замыканием электрической цепи иголкой? Нет? Вот видишь, ты самостоятельно и безболезненно отказался от "профессии программатора". Так и от "программистов" избавимся...
>нейросеть вернет команды в русский язык. Только так можно победить засилье гегемонии англосаксов в технологиях IT. Считаю что это первостепенная задача россиянина в этой эволюционной войне на выживание.
Ну ты шиз чтоли? На русском кринжово писать, потому что язык для сухой передачи смыслов подходит херово. Русский это про охуевшее и потерявшее берега словообразование, речевые обороты и эмоциональный окрас, как под котиками. И многие языки так же этим грешат. Язык эмоций, а не логики. Английский же лучше подходит для логики. Глянь только переводы признанных классиков мировой литературы типа шекспира, где фразу типа He kiss her на русский переводят в 40 блядь слов, потому что иначе просто сухо. Так вот, эта сухость английского и его распространенность и делают его подходящим языком для технической литературы и для кода больше, чем другие языки. Даже забыв о русском на том же китайском китайцы ебали рот писать, хотя их так дохуища и они настолько дохуя айтишат, что россия со своими иванами пусть не самыми глупыми и претензией на вклад в айтишку вообще лучше бы не вякала, суньцзы++ искусство вайти. И это еще к индусам относится, на хинди не пишут, хотя индусы безоговорочные лидеры всей отрасли. Правда для образованных у них англ родной, в отличие от хинди.
Всех устраивает англ для всего, кроме нескольких идиотов. Перевод доков на другие языки как плюсик в карму, а не необходимость. И сейчас этот плюсик может сделать нейронка переведя весь док за минуту на все языки мира с меньшими косяками, чем у реальных людей.
>на том же китайском китайцы ебали рот писать
https://en.wikipedia.org/wiki/Easy_Programming_Language
На китайской версии страницы больше информации о нём.
Гугли "易语言", если хочешь посмотреть скриншоты кода...
А популярен? Великий нефритовый стержень на нем пишет? Вичат на чем? Вуконг? Дипсик?
>У меня с лором/сценарием/диалогами труднее всего идет.
На мой взгляд, большинство игроков (судя по отзывам, форумам, обсуждениям, мемам и т.д.) пропускают сюжет игры и вообще не любят много читать. А большинство игр не отличаются особой глубиной сюжета, тем более инди. Так что делай увлекательный геймплей и старайся не грузить игрока лишними стенами текста, что только зря отвлекают от геймплея. Кроме того, многие истории можно передать элементами окружения - вообще без слов, так что не нужно быть Львом Толстым, достаточно уметь изображать на экране что-то узнаваемое. И помнить, что большинство игроков всё равно всё пропустят и не оценят твоих усилий... Игра - композиция из многих движущихся частей, и гармоничность этой композиции важнее качества проработки отдельных деталей.
>>1050898
>может возвратить к разработке старой игры
Вопрос в том, а нужно ли вообще возвращаться?.. Меня всегда мучает проблема "а стоит ли этим вообще заниматься". Одно дело - когда ты получаешь удовольствие прям в процессе какого-то дела, как в случае с играми или сидением в интернете. Другое - стиснув зубы продираться сквозь унылую рутину и интеллектуально трудные задачи, и всё ради... Собственно, ради чего это делать? Одобрения? Славы? Денег? К чему мне всё это... Да и если бы хотел - мне никогда ничего не добиться, если смотреть на вещи реалистично.
>>1050915
>Без чёткой идеи ты далеко не уедешь.
Без идеи можно сделать песочницу - что я и собирался изначально сделать, потому что люблю песочницы без сюжета, где можно часами ковыряться в песочке и не отвлекаться на лишние ничего не значащие в реальной жизни стены текста. А вот без реализации я точно никуда не уеду. Всё-таки плохой из меня программист... Как был любителем, так и останусь.
Если интересно, то лор игры на данный момент примерно такой:
1. Действие происходит на гигантском газовом торе, вращающемся вокруг звезды в виде чего-то среднего между газовой планетой и поясом астероидов. Он всегда таким был (в реальности из примерно похожих колец формируются планеты) и останется стабильным в обозримое время, но мощные потоки воздуха постоянно перемешивают всё, что попадает в атмосферу, а ядро горячее и плотное - всё перемалывает. В общем, тор собирает всё в себя и не отпускает.
2. У этого тора с древних времён своя особенная биосфера, приспособленная жить на куче раздробленных и постоянно перемешивающихся астероидов. В основном это растения, которые накапливают газ легче воздуха и взлетают в верхние слои атмосферы, унося на корнях клочки почвы и всё, что на них окажется. Долго они парить не могут, теряя газ и возвращаясь обратно в плотные и опасные слои атмосферы, замыкая цикл. Из животных могут быть только те, что умеют летать или парить в воздухе, перебираясь с острова на остров, или способные выжить в плотных слоях атмосферы. Некоторые обосновались с внешней стороны тора (в тени), которая более спокойная, но холодная, сырая и тёмная. Цивилизованных аборигенов никогда не было - биосфера хоть и стабильна, но слишком нищая и в вечном цикле саморазрушения. Многие животные - агрессивные паразиты в вечной борьбе за скудные ресурсы, но могут встречаться полезные и достаточно умные.
3. Всё это так или иначе привлекло много разведывательных кораблей и роботов-разведчиков со всей галактики/ближайшей вселенной, а кого-то просто по ошибке засосало из-за сбитого курса навигации, т.к. гравитационное поле системы необычное. Космические корабли быстро разносит в хлам. Из-за суровых местных условий гуманоиды погибают, а роботы изнашиваются, теряют контроль и отключаются. Это, в свою очередь, заполняет тор инородным искусственным хламом, как очень древним, так и всё ещё шевелящимся. Но абсолютное большинство машин нейтральны или дружелюбны, так что игрок может принять их на свою сторону, если сможет извлечь их из руин, починить и помочь им выжить. Также можно найти бортовые журналы, записки, сигналы о помощи и всё такое, что мы так любим собирать в каждой первой инди-песочнице про коллекционирование барахла.
4. А главным героем является серийная модель робота-разведчика с Земли, отправленная для исследования землеподобных планет и первого контакта с внеземными цивилизациями, так что это практически человек, только компактный (условно 5 кг весом). Короче, её тоже сбило с маршрута и засосало в этот тор, так что теперь её задачей является выжить, исследовать что есть и попытаться свалить. Корабль развалился от удара об астероид и поэтому приходится мастерить хоть что-то из имеющихся поблизости ресурсов. Также у неё есть базовые спутники-помощники, одна из которых регулярно спасает резиновую задницу героини от падения в пропасть, поэтому гейм овера в игре нет.
5. Если когда-нибудь будет мультиплеер: среди обломков можно найти аномальные камни, создающие портал в параллельную реальность. Если собрать устройство на дирижабле, то его целиком можно переместить в параллельный мир, вместе со всеми пассажирами. При этом локальная игра сохраняется без изменений, и даже если в PvP игрока полностью разгромили, возвращается он к локальному чекпойнту, и может снова выйти в мультиплеер на той же копии дирижабля. Но в случае успешного выхода, например, после кооперативной игры, игроки забирают в локальную игру свои достижения. Вряд ли когда-либо я до этого доберусь, но мне хотелось бы заранее заложить в игру кастомизацию: игрок может настраивать внешность персонажа, коллекционировать элементы одежды из хлама и всё такое - юбочки, колготочки, платья горничной, в общем всё, что чрезвычайно важно роботу-разведчику для маскировки среди инопланетян.
Несмотря на всё вышесказанное, тон игры подразумевается мультяшно-комедийным. Можете игнорировать трагизм тысяч потерявшихся в космосе кораблей, экипажи которых умерли голодной смертью или от инопланетных паразитов, а автоматические системы которых бессильно пытались восстановить трупы своих хозяев и записывали бессмысленные отчёты, полные отчаяния и беспросветной тоски. Это просто записки для коллекционирования.
В остальном ты прав, анон - чёткой цели нет, только абстрактное "было бы круто".
>>1050929
>из-за персонажа
Это плейсхолдер пока что. Стараюсь следовать принципам итеративной разработки: делать лишь необходимый минимум, чтобы протестировать задуманное на практике и скорректировать планы. Наверное, я бы мог сразу проработать персонажа целиком со всеми опциями кастомизации, но... зачем? И так работает. Главное, что я тестирую переключение анимаций и то, как это будет выглядеть на чём-то более детальном, чем примитивы. Прикрутил лицо к голове, например, чтоб протестировать блендшейпы и как вообще будет выглядеть 3D лицо с имеющейся камерой. До этого несколько лет она бегала совсем без лица - думал сделать 2D лицо как в ряде мультяшных игр, но мне не понравилось - поэтому оставил без лица. А ещё раньше использовал плейсхолдер из кубиков совсем без анимаций, лишь бы было видно пропорции человеческого тела... Я понимаю, что по видео нельзя сказать, что является плейсхолдером, а что - реализацией идеи, но я эти видео не для игроков записываю.
В частности: одежда - только чтобы совсем голой не бегала - её фигура слишком отвлекает от геймплея; волосы - как накинул от балды несколько лет назад, так с тех пор и не трогал, хотя там очень кривая геометрия, но не лысой же ей быть всё это время; ушки потом нужно продумать получше, потому что они должны будут двигаться; лицо находится в промежуточной стадии ради теста и с него слетел сглаживающий модификатор; тело нужно переделывать, потому что у него кривая геометрия, из-за которой многие позы ломают ей задницу и плечи; анимации я буду переделывать практически с нуля, когда переделаю риг, когда пойму, какой риг мне нужен.
Вообще, главный герой изначально планировался как аватар игрока из ММОРПГ, то есть чтобы можно было всё подробно настраивать, а не только выбирать из пресетов. Но, поскольку я всё время теряю желание заниматься игрой, я до сих пор не дошёл до той стадии, когда можно делать настолько продвинутый редактор персонажа. И никогда не дойду такими темпами. Но это и не страшно. Главное не цель, а пройденный путь... Желательно с удовольствием. Делайте игры, только если вам нравится сам процесс создания игры, а не конечная цель, до которой мало кто дойдёт.
>Вопрос в том, а нужно ли вообще возвращаться?..
А что еще делать? Ну сядешь ты скроллить инет и игры играть - надоест снова и снова будет ощущение что ты протухаешь. И снова появиться желание в положительном созидании.
Что еще делать, найди другое хобби раз сжег все нервы на играх.
Ну так как минимум уже создал отдельную вселенную с островами, значит не все так плохо с креативом.
>1. Действие происходит на гигантском газовом торе...
Ну вот тебе и лор, ппц у тебя самокритика.
>Стараюсь следовать принципам итеративной разработки: делать лишь необходимый минимум
Мне думается ты выгораешь на минимумах. Представь игру в голове, поиграй в нее в голове, запиши ключевые моменты и только потом пробуй делать. На минимумах ты так и так будешь буксовать и в итоге игра будет ощущаться непосильным калом из плейсхолдеров и сплошных препятствий + незаконченных дел.
А так у тебя будет идеальная игра (цель) хотя бы в голове.
Да блять, ебанный годот. Перенёс плеер в сцену с теми же настройками и всё заработало. Ну и хуита. Просто пиздос.
Да, только я сцену перезапускаю, чтобы не прописывать логику перезапуска раунда. Из-за этого музыка заново начинается. Идея и была вынести в отдельную сцену, чтобы такого не происходило.
У тебя отдельная сцена с музыкой (AudioStreamPlayer) в автозагрузке стоит (Синглтон), а сцену ты перезапускаешь через
> get_tree().reload_current_scene() ?
Да. На Пк в вебе всё норм работает так, на мобилках в вебе сразу же лагает звук из этой сцены
Если проблема только на некоторых мобилках, может их браузеры старые или памяти мало, хз тогда. Ну как вариант отказаться от reload_current_scene, это в принципе не сложно или потыкать что нибудь: порядок загрузки синглтонов, preload аудио файлов, поменять формат файлов mp3<>ogg
А, ещё как вариант попробовать:
> get_tree().reload_current_scene.call_deferred()
мало ли
> порядок загрузки синглтонов, preload аудио файлов, поменять формат файлов mp3<>ogg
Это делал уже всё, да, ничего не помогло.
>>1050961
>get_tree().reload_current_scene.call_deferred()
Попробую, спасибо. Но в целом, перезагрузка музыки несильно мешает
В сцену динамически добавляются ноды, которые выполняют действия в зависимости от состояния одного из нод выше по дереву скажем, при наступлении time = night враги типа "вампир" получают бонус к атаке, а костры сжимают зону регена здоровья вокруг них. Таких сущностей много, обращаться к ним напрямую через get_node() геморно.
Окей ли передавать данные к таким дочерним узлам через сигналы, или есть более элегантный способ? Я потестил, ошибок такая связь не выкидывает, но в документации сигналы "сверху вниз" обозначены как bad practice, и я озадачен.
При генерации нод добавь их в массив, потом лупом обновляй.
Да и сигналом норм тема, пусть при создании подпишутся и все. Но в таком случан меньше контроля доставки нужного.
>только я сцену перезапускаю
Делаешь сцену game.tscn:
>Game: Node
>— Music: Player...
>— Level: Node...
Когда тебе нужно "перезапустить сцену":
>game.gd
>extends Node
>var level: Node
>func restart_level(path := "level.tscn") -> void:
>_ if level: level.queue_free()
>_ level = load(path).instantiate()
>_ add_child(level)
Должно работать без проблем.
Для красоты можно сделать так, например:
>level.gd
>extends Node
>signal restart_request()
>func _ready() -> void:
>_ restart_request.connect(
>_ _ get_parent().restart_level.bind(scene_file_path))
>...
>func...
>_ restart_request.emit()
>Таких сущностей много, обращаться к ним напрямую через get_node() геморно
1) Можно обратиться к самой ноде выше в @onready/_ready самой сущности
2) Используй группы, т.е. вампирам и кострам просто назначь группу "TIME_DEPENDENT"
И в срипте изменения дня / ночи
> var td = get_tree().get_nodes_in_group("TIME_DEPENDENT") # Все ноды зависимые
> for td_node in td:
> if td_node.has_method("on_day_changed"): td_node.on_day_changed(var_daynight)
или более просто
> get_tree().call_group("TIME_DEPENDENT", "on_day_changed", var_daynight)
>есть более элегантный способ?
Малоизвестная фича, хотя у неё целый GUI есть:
https://docs.godotengine.org/en/stable/tutorials/scripting/groups.html
>get_tree().call_group("vampires", "sucky_sucky_mode")
Только учитывай, что:
https://docs.godotengine.org/en/stable/classes/class_scenetree.html#class-scenetree-method-call-group
>Note: This method acts immediately on all selected nodes at once, which may cause stuttering in some performance-intensive situations.
В целях оптимизации, если у тебя сотни одинаковых сущностей, их стоит разбивать на маленькие группы, оповещая каждую группу на отдельном кадре/тике:
>func _process():
>_ var next_group := groups_to_call.pop_back()
>_ if next_group: # пустой массив => null = false
>_ _ get_tree().call_group(next_group, method_name)
Ну или что-то подобное, смотри по ситуации.
>сигналы "сверху вниз" обозначены как bad practice
Просто так с ними неудобнее работать... Родители щупают детей напрямую через get_children(), а вот родителям дети сообщают о событиях сигналами.
>get_node() геморно
Чем тебя не устраивает get_children()/get_child()?
>>1050990
>потом лупом обновляй
Интуиция подсказывает, что вызов сигнала/метода группы будет дешевле отдельных вызовов в цикле, поскольку в первом случае цикл на C++, во втором - интерпретатор GDScript каждую итерацию бегает...
На практике разница может быть несущественной.
>>1050961
>>1050960
>>1050956
>>1050947
Спасибо пачаны всем, я разобрался. Лагало потому что ссылку кидал себе в вк и открывал через вк. Я не ебу как это устроено, но игра открывалась во вкладке вк на телефоне. Стоило лишь скопировать ссылку и открыть её в гугле/яндексе и всё стало заебись. Я 3 дня боролся с проблемой, которой не было
>во вкладке вк на телефоне
Игра открывалась через этот браузер:
https://en.wikipedia.org/wiki/WebView
На Android он часто устаревший/глючный.
Да и само приложение ВК может тормозить.
группы годная вещь, однако контроля мало. Я группы использовал как признак максимум для проверки чего-то. А так собирал массивы всегда с ссылками на сгенерированные обьекты. Мб и медленее, яне замечал, но надежнее точно.
А мне нравится синглтон. Ещё удобнее.
Я так и не осилил, ни моделинг, ни риггинг, ни арт, ни звук. Вот и приходится дрочить код бессмысленно и беспощадно. Я проиграл.
> не делай сам, скачай бесплатно, сгенерируй нейронкой
Фу. Буэ.
>модделинг
Лоу-поли делать очень быстро. Можешь начать с блокбенча
>риггинг
Римминг. Реально дело пару видео разобраться.
>арт
Качай паралелльно. Тут нужно много тренить рисовать стадики и все время обращать внимание на теор базу. Сама база не сложная, но красиво рисовать быстро не начнешь. Можешь применять теорию на простом арте типа вектора или пиксель-арте (именно простом векторе и простом пиксель арте).
> звук
качаешь звуки - генеришь в элевен лабс. Вот делать примитивные зыук и музыку - это вообще не сложно.
Везде речь идет не про высшие формы - аля 3д как в рдр или музыку как в синематиках. За год-два можно все выучить на среднем - начинающем уровне и делать гамесы
С артом немного звездешь. Главная пропасть - перспектива. И единственный способ натренить до автомата это рисовать кубы с точками на горизонте. Талантом это не дается.
Поэтому лучше сразу в 3Д и текстуринг. Там бесплатная свето-тень и перспектива.
Про звук тоже, единственное наковыряешь из сэмплов если медведь в детстве ухо не сжувал.
Перспектива - это элементарная херня. Точки рисуешь и к ним линии. Там сложно только в ебейших ракурсах. В арте сложно с формой - там основной дроч - но его можно упростить.
Я на кубах делаю. Правда я и выбрал игру, где такое возможно, космическая тема, космические тела знаете ли. Это, конечно, печально, но зато так можно делать хоть что-то. Потом буду осторожно и скорее всего безуспешно пробовать лоуполи. А может и нет, посмотрим, пока что у меня времени нет совсем, чтобы полностью погрузиться в игру. А хочется.
Да, конечно, расскажешь. Она элементарная в теории, а на практике когда у тебя объект сложной формы (не куб, да?) в пространстве - ты даже в векторе затрахаешь подгонять.
Не, пчел выше прав, если ты в визуале ноль то лоу поли 3д самый доступный медиум для вкатуна. Главное не охуевать с анимациями. Рисовка сложнее, даже пиксельная.
Ппц ты сделал игру на денди The Legend of Kage, у меня сейчас флешбеки накрыли, даже музыка почти такая же.
Жесть как матрица сбоит, столько разработчиков игр стала, что матрице приходится из NES игры доставать.
Релиз кандидаты пошли. Скоро.
Какие там параметры крутить чтоб струя визуально на разделялась на отдельные частицы? Если увеличивать количество частиц, то какое количество можно считать потолком для лоу-энд целевых машинок?
Велика ли разница в производительности между лоу-поли объемной 3д мешкой и 2д билбордом для партикла?
Для лоу-энд машинок лучше использовать ГПУ или ЦПУ партиклы? В интернетах мнения разнятся.
>густую струю жидкости в 3д
Чего ты хочешь добиться геймплейно?
Если как в GTA SA, то, думаю, тут две части:
1. Изгибающийся процедурный меш с текстурой:
https://docs.godotengine.org/en/stable/tutorials/3d/procedural_geometry/immediatemesh.html
2. Брызги/пар, разлетающиеся от струи воды:
https://docs.godotengine.org/en/stable/tutorials/3d/particles/index.html
Также пригодится генерация шума:
https://docs.godotengine.org/en/stable/classes/class_noisetexture2d.html
>Для лоу-энд машинок
Зависит от того, что для тебя "лоу-энд"...
Всё сильно зависит от... всего. Тестируй сам.
Вот здесь пример с огнём: >>958103 →
>Чего ты хочешь добиться геймплейно?
Вообще ничего. Это для декораций только. Красивые однородные густые струи нужны, которые будут выглядеть естестевенно. Спасибо за ссылки.
>Это для декораций только.
Статичных или интерактивных?
Где-то далеко на фоне или вблизи?
Стилизованно или фотореалистично?
Если тебе нужно что-то вроде водопада, то:
1. Делаешь в Blender меш в форме водопада.
2. Пишешь свой шейдер (примеры не точные):
2.1. Внутри vertex() двигаешь вершины:
>float wave = sin(VERTEX.y + TIME); # бегущая волна
>VERTEX = VERTEX + vec3(wave, 0.0, wave);
2.2. Внутри fragment() двигаешь текстуру:
>ALBEDO = texture(noise, UV + vec2(TIME, 0)); # поток
3. Добавляешь пар и/или брызги частицами.
4. Долго подгоняешь параметры по вкусу...
Советую поискать визуальные референсы.
Про шейдеры читать тут:
https://docs.godotengine.org/en/stable/tutorials/shaders/index.html
Особенно это:
https://docs.godotengine.org/en/stable/tutorials/shaders/shader_reference/shading_language.html
https://docs.godotengine.org/en/stable/tutorials/shaders/shader_reference/shader_functions.html
https://docs.godotengine.org/en/stable/tutorials/shaders/shader_reference/spatial_shader.html
Совет. Прежде, чем писать свой шейдер:
1. Создай StandardMaterial3D в поле инспектора.
2. Выбери нужные настройки (см. uv1_triplanar).
3. В выпадающем меню жми "convert to shader".
4. Открой шейдер и правь его как пожелаешь.
Бояться шейдеров не стоит, тебе хватит простого.
Есть "визуальные" шейдеры - ИМХО, неудобные...
Кароче, скачал плагин и адаптировал под свой проект. Теперь можно косплеить райдена из мгр
Сделай как в старенькой Rune - возможность отрубить вражине руку/ногу, подобрать ее как оружие и опиздюлить еще живую вражину его же конечностью, пока он, немощный, уматывает от тебя заливая все вокруг кровью.
>пока он, немощный, уматывает от тебя заливая все вокруг кровью.
Я лох, не смогу такое сделать не загадив проект на данном этапе. В будущем запилю всякие состояния на отрубленные конечности
И это 99-2001 годы. С мультиплеерным режимом. Геймплей, который мы проебали.
Я из-за этой хуиты год или два как геймдев забросил, работать дальше хочется но в один момент любой новый проект опять ломается. Бекапил с гит но возврат к предыдущим коммитам ничего не чинит.
>Я из-за этой хуиты год или два как геймдев забросил
А Blender стоит, прописан путь к нему в настройках Godot? (Настройки -> FileSystem -> Import)
Открой Pepe.tscn текстовым редактором, найди там по тексту pepe.blend, может что-то в глаза бросится, путь какой то или ещё что-то
>А Blender стоит, прописан путь к нему в настройках Godot?
Конечно, я даже пробовал совсем от блендера отказаться и сразу в gltf экспортить, в один момент так же ломается.
>может что-то в глаза бросится, путь какой то или ещё что-то
Ничего неожиданного, правильный путь, присвоение id, дальше использование id в файле. Он ведь еще и на скрипты жалуется, а с ними что может быть не так то епрст, все на месте.
Как же это заебало.
А тебя у годота есть права на чтение вообще? Как он установлен? А у юзера?
Как они могут исчезнуть? Что годот, что проект вне диска с виндой, запуск от администратора ничего не дает. Что еще тут можно сделать? Прописывал команду fsutil file setcasesensitiveinfo для дериктории проекта чтобы все содержимое проекта было чувствительно к регистру (когда-то напарывался), так что вариант с тем что годот воспринимает Pepe за pepe отпадает.
Я на линух подумал, про винду нет предположений.
В линухе можно в контейнер запихнуть прилогу и она ваще нихуя дальше контейнера видеть не будет без особых извратов с правами на каждый чих, популярно у некоторых параноидальных извратов, сам годот так не распространяется канеш, но вдруг обернул в какой-нибудь флатпак.
Посмотри еще папку (хз где на винде) где годот хранит локальные настройки проектов. В линухе это был бы .local/share/godot вроде как, на винде какаянибудь AppData.
Есть подозрение что uid говно от хуана сломалось. Попробуй свичнуться с юид на "путевЫе" ссылки, возможно починится. Сижу на пингвине годот3, вижу такое впервые, хотя проект ездит по гиту сразу по нескольким машинам. Мейби в какой-то момент перезаписались юиды у этих ресурсов, но в сцену эта перезапись не попала.
Ну или сам попиздуй в директорию с этими ресами и посмотри на файл uid (хз как он называется, но он точно содержит в своем названии название ресурса, к которому он привязан), и там посмотри что прописано. Возможно есть маза с кодировками в файле сцены и в файле юид, они например почему-то разьебались. Или сам файл юид скорраптился.
Таки выясни, что там произошло, заодно тред предупредишь.
Может кто подскажет максимально бюджетный вариант обновления чтобы использовать базовые свистоперделки? Текущие параметры на картинках. Готов брать подержанное.
>>1051171
>Велком бэк
Пасибо, я весь запал растерял из-за этого косяка.
Они одинаково экспортируются, blend удобнее тем что сам Godot через блендер его превращает в gltf и тогда экспортирует
>>1051168
ты бы обновился ещё на 4.4.1, всё же какие то баги фиксят, а у тебя вроде 4.2.2
с такой мамашей тебе нихуя не светит. Найди какую-нибудь относительно свежую мать с am4 чтобы встали 4-5 тысячные рязани, тогда уж можно на что-то рассчитывать.
Можешь рузен бюджетный взять, если ты в РФ сейчас неплохой момент для покупки железа благодаря курсу. А вообще есть /hw, там тебе соберут пеку.
1) Если правда, с чем это связанно в сравнение с другими движками?
2) Какие еще подводные есть?
>ты бы обновился ещё на 4.4.1
Да вот не знаю как проект отреагирует. Едва ли оно спокойно откроется. Но да, там есть фичи которых не хватает, хотя бы типизированные словари.
>>1051175
>с такой мамашей тебе нихуя не светит.
Да, наверно. Я даже хз насколько соотносится важность процессора к видюхе, но у меня в любом случае формфактом матери меньше стандартного и видеокарта побольше просто не влезет, да и этот 960T это лучшее что вообще нашел на am3.
>>1051176
>А вообще есть /hw, там тебе соберут пеку.
Если для них понятна задача "бюджетный для геймдева".
Это все потому что ты лягушонка заменил, вот он тебя и проклял.
> var adr = read_byte() << 8 + read_byte()
Годот интерпретирует как
> var adr = read_byte() << (8 + read_byte())
т.е. у плюса больше порядок, чем у операции>>1051180
>Да вот не знаю как проект отреагирует.
сдвига, хотя сдвиг это умножение
>>1051180
>Да вот не знаю как проект отреагирует.
Ст авишь новую версию годота, делаешь резервную копию проекта, открываешь, он там скажет что надо под новый формат поменять (после 4.3 такое) и потребует перезапуск, профит
- газ из листвы деревьев, без которого всё падает;
- древесина из деревьев, без которых всё падает;
- руды из почвы, без которой деревья улетают;
- разный лут из сундуков, редкие чертежи и т.п.;
- мобы, держащиеся на/возле самих островов.
Т.е. у игрока выбор: что собрать, а что улетит? Это, по задумке, должно разнообразить гринд ресурсов.
Давно чувствую, что зря взялся за жанр survival... Песочницы мне нравятся, выживать прикольно, но разрабатывать до играбельной стадии очень долго. Планировать архитектуру такого проекта сложно...
>>1050940
>создал отдельную вселенную с островами
>>1050942
>Ну вот тебе и лор, ппц у тебя самокритика
Вы хоть поняли, что ответили разным людям?
Это мои посты: >>1050894 >>1050937
Обычно они либо длинные, либо с видео.
Я тут более 5 лет, могли бы и узнавать...
А это пост другого анона: >>1050914
>с лором/сценарием/диалогами труднее всего
Нет, у меня всё в порядке в этом плане - если нужно, нафантазировать лор/сценарий/диалог я могу без проблем, просто мне это НЕ НУЖНО. Ненавижу игры, заточенные на сюжет, ведь я играю в игры ради их интерактивного виртуального мира, а не фантазий сценаристов, что в "сюжетных" играх навязывают. Я лучше буду 1000 часов в GTA Online возить ящики по маршруту, чем слушать диалоги GTA V/IV/SA/VC/III...
>музыку ляпать кое-как осилил
Нет, я вообще никак не разбираюсь в музыке. Да и ненавижу музыку в играх, ведь она часто отвлекает, нарушает погружение в игру - так же, как и сюжет. Я предпочту играть в игру совсем без звуков чем если придётся слушать раздражающие звуки на повторе, доносящиеся из ниоткуда на сцене, где ничего нет (серьёзно, кто придумал эту "фоновую музыку"?)... Наихудший пример: Minecraft. Тишина-тишина... БУМ саундтрек в дикой глуши/глубоко в пешере. Зачем?!! Приходится эту музыку выключать в настройках.
>Мне думается ты выгораешь на минимумах
Ты не понял... Если бы я фокусировал свои силы на отдельном компоненте, у меня через какое-то время получился бы почти идеальный компонент, но игры вообще не было бы, даже недоделанной. Ну и зачем разрабатывать компонент без всего остального? Я стараюсь избавиться от своего перфекционизма, заставляющего ковыряться в одном компоненте до бесконечности, из-за чего целая игра не получается. Выгорание как раз происходит от фокусировки на полировании одного компонента игры до идеала.
>Представь игру в голове, поиграй в нее в голове
>будет идеальная игра (цель) хотя бы в голове
Я легко представляю себе игру, которую я не смогу реализовать в реальности; да никто не сможет. Это расстраивает, когда видишь, что в реальности всё значительно хуже получается. Т.е. в моём случае фантазирование лишь ухудшает настроение, когда осознаю, что этим фантазиям суждено оставаться бесплодными фантазиями. Это очень больно...
Ты-то сам новичок, я читаю твой тред иногда. А я в геймдев самоучкой вкатился около 16-17 лет назад, перекатился на Godot около 5.5 лет назад. Многое перепробовал и прочитал на тему геймдева...
Я, если что, один из немногих, кто реально старается помогать анонам в разных тредах, чаще всего Godot. Допускаю, что мои советы не всегда правильные...
>>1050939
>снова будет ощущение что ты протухаешь
Всё именно так, потому и возвращаюсь к играм.
>найди другое хобби раз сжег все нервы на играх
Да я пытался, только у меня других навыков нет.
>>1050941
>полосатые трусы
Хотел как-то текстуры протестировать, не придумал ничего лучше полосок. У кроссовок та же текстура. Планирую потом сделать много вариантов трусов... Настройка трусов - одна из важнейших задач для разработчиков игр, ведь без этого игры не игры.
>>1050895
>игру про атаку титанов
Не знаю, про что ты, какая-то официальная? Игр про "grappling gun" на самом деле очень много, особенно новичковых проектов, где кроме него ничего нет. Я реализовывал свою версию с нуля, только какую-то формулу для стимуляции изгиба где-то подсмотрел. Кажется, это называется "verlet integration". У меня багнутая версия, правда, надоело в ней копаться.
>>1051154
>возврат к предыдущим коммитам
Откатывай в новую папку или удаляй /.godot/. Вся информация в этой папке генерируется заново из имеющихся файлов проекта, поэтому она никак в репозитории не хранится. Но если ты хочешь откат, необходимо удалить старые файлы в /.godot/, иначе получится, что у тебя файлы проекта расходятся со сгенерированными редактором файлами. Это всё нормально и нужно понимать в самом начале.
>>1051168
>переоткрыл с долгим-долгим реимпортом
Это всё из-за .blend -> .gltf. Объясняю: внутри .blend анимации хранятся сжато, а в .gltf Blender их должен покадрово запечь и оптимизировать, на что уходит достаточно долго времени. Тем более у тебя старый процессор, а задача эта выполняется в один поток. Поскольку папку /.godot/ нужно сбрасывать, лучше использовать формат .gltf вместо .blend - так Godot значительно быстрее импортирует проект заново.
>>1051180
>Да вот не знаю как проект отреагирует
Копируешь папку "My Game" в "My Game (копия)" и открываешь "(копия)" в Godot. Если не получилось и захотелось откатиться назад - просто удаляешь эту скопированную папку и всё. Если получилось, тогда удаляешь оригинальную папку. Никаких проблем. Встроенный менеджер проектов не использую, но, кажется, там отдельная кнопка "скопировать" есть.
>>1051172
На счёт компьютера: твоя видеокарта вроде может поддерживать версию Vulkan до 1.2, но у тебя там устаревший драйвер, в котором только Vulkan 1.0. Официально GT 630 больше не поддерживается, но возможно установить драйвер 474, там Vulkan 1.2. Возможно, он будет глючным - то 472 или старше... Страница скачивания показывает версии карт, что официально поддерживаются версией драйвера.
Если будешь обновлять видеодрайвер, то заранее скачивай несколько версий. Ставишь самую новую, перезагружаешься, тестируешь тяжёлой игрой. Если Windows не падает с BSOD - радуешься, если падает, откатываешься на версию драйвера чуть постарше. Возможно, тебе придётся перезапускать Windows в безопасном режиме, но это всё несложно. Всего за несколько дней найдёшь оптимальный драйвер...
Процессора достаточно для Godot 4.4.1, но с 4.5 x64 потребуется набор инструкций SSE4.2, а значит твой процессор не запустит Godot 4.5 x64. Но ты можешь использовать Godot 4.5 x32 или собрать Godot из исходников без SSE4.2. Подробнее читай на GitHub.
Если хочешь купить самый дешёвый компьютер с поддержкой Godot - смотри на наборы инструкций процессора (SSE4.2 теперь обязателен, но заранее желательно иметь AVX2) и поддержку Vulkan. По оперативной памяти 8 GB пока хватает, а по видео желательно минимум 2-4 GB, но больше - лучше.
Алсо, если собирать, то лучше на AM5. Как я понял, ценники на AM4 не сильно ниже, а характеристики значительно слабее и нового ничего не выйдет. У оперативной памяти DDR5 скорость раза в 2 выше. Современный софт упирается в горлышко памяти - мощные процессоры простаивают в ожидании.
С другой стороны, сохрани текущий компьютер в относительно рабочем состоянии, чтоб тестировать оптимизации в своей игре. А то потом будут игроки жаловаться, что на их "2 гига 2 ядра" всё тормозит. Поэтому собирать новый комп в новом корпусе, с отдельным блоком питания и новым SSD под ОС.
Сам я хочу купить мини-пк на AMD AI MAX+ 395... Но, наверное, подожду, пока цены спадут. Может быть, вообще подожду Medusa Halo в конце 2027? Лол. Не хочется переплачивать за хайп в первый год релиза. Текущий ПК из 2007 устраивает, так зачем менять... Только ради запуска мощных нейронок локально...
Как же хочется запускать модельки оффлайн. Ещё и тренировать что-нибудь интересное можно было бы, наверное. Хочу велосипедную модельку смастерить, переизобрести колесо, так сказать. Кодить же умею. Применить как-нибудь в игре было бы идеально...
...не обращайте внимания, у меня опять эта фаза...
Решил пока ждать до ноябрьской распродажи...
> вот он тебя и проклял
Его прокляло то, что он вместо блокинга КАК Я И МНОГИЕ АНОНЫ ЕМУ СОВЕТОВАЛИ, полез импортировать кучу ВСЖ-ассетов. Результат немного предсказуем. Дизайните уровни блокингом, отрабатывайте механики, а потом уже завозите контент. И резервные копии делайте! И перемещайте файлы только редактором!
Хорошо расписал, спасибо большое, я как полез в /hw и на сайт днс вообще потерялся, что брать и к какому ценнику гатовиться вообще непонятно.
Из-за набора инструкций процессора да, у меня уже не запускает новый блендер.
>>1051215
> полез импортировать кучу ВСЖ-ассетов
Хз что такое ВСЖ. Там половина ассетов мои, вторая половина собрана из чужих наработок, но каждая моделька обрабатывалась вручную.
Появилась идея не конструировать пк с нулины а обновить плату + карту + цпу. Текущая имеет формфактов Micro-ATX, видеокарта скорее всего влезет в старый корпус, а вот охлаждение цпу даже не знаю.
Анон, не знаешь какую-площадку где можно модели заказывать чтобы из РФ оплачивать можно было? Фурнитуру я и сам намоделю, но персонажи это не мое. Заказал бы чего под SH3 или 4
>чтобы из РФ оплачивать можно было
С этим до сих пор все плохо. Либо российские площадки (дорогие, хуевые, дохлые), либо крипта (мало кто берет), либо обойти санкции и сгонять в Казахстан/Грузию чтобы банк открыть. Слышал есть сервисы которые делают последнее за тебя, удаленно, но хуй знает про доверие. Сам пользуюсь третьим способом, через иностранный банк.
>значительно слабее и нового ничего не выйдет. У оперативной памяти DDR5 скорость раза в 2 выше
Скорее латенси в 2 раза выше. А планки без этой проблемы стоят в 3 раза больше чем ддр4.
Ну и новые мамки по цене разумеется не сильно ниже, но вот свежие процы уже сильно выше чем ам4 процы. Так что если цель на апгрейде не сильно потратиться, иметь pci куда входят свежие карточки - лучше собирать на чем-то стабильно рабочем пусть и прошлого поколения.
>Только ради запуска мощных нейронок локально...
>Как же хочется запускать модельки оффлайн. Ещё и тренировать что-нибудь интересное можно было бы, наверное.
Ахах, на проце тренировать? С дуба рухнул? Какой бы там проц нейро аи хуи ультра максима не был - он с заглотом возьмет даже у 3060. Хочешь текстовые нейронки (а уж тем более тренировать) - скупай по ебеям 3090 и собирай ферму.
>переписал последний скрип с шарпа на гдскрип
Зря. Тем более раз уже начинал на шарпе, потому что в обратную сторону все равно придется переписывать, если игра до релиза дойдет. Имаджинируй свое ебало, когда релизную портянку кода придется на шарп мигрировать.
Чего за тупые набросы? Три игры в релизе, одна приносит ок деньги, ничего на шарпе нет. Если ты не пишешь еба-числодробилки, а он явно не пишет, то гдскрипт идеален. А для числодробилок все равно лучше на плюсах кусок переписать, а не на шарпе.
Пишу еба архитектуро-дробилки, шарп лучший. Но да, не призываю, кто как хочет.
Дело не в этом, хотя как бонус как бы тоже лучше пусть будет, чем его не будет. Даже не влезая в реальную киллерфичу шарпа над гдскриптом (не скорость и не ооп, ничто из очевидного) - при прочих равных если похуй на синтаксис языка, его возможности и выразительность - брать гдскрипт нет ниодного плюса, тот анон выше сделал литерали даунгрейд ненужный.
В четверке гдс работает не с гднатив апи, а с более низкоуровневым, за счёт чего обращения к движку дешевле. Если есть план просто юзать движок и не изобретать какие нибудь йоба колеса колдуя напрямую с апи движка без нод и скриптов и без желания сильно чето архитектурить - шарп только проблемы создает. Захочешь с++ модуль всунуть - будь добр пересобери моно привязки, я на этом сломался в 3 годоте, эта хуйня просто не хотела под васм собираться. В 4 годоте возможно проще но на мобилках (на правах слухов) есть неочевидные проблемы, с которыми есть риск столкнуться при массовом релизе.
Надо убрать из этой статистики безигорников и прочих твг/джемо серунов, тогда будет интереснее. Там есть еще один график где видно что процентов 70 из всех годот юзеров по факту безигорки.
Тогда любителей вылизывать яйца, по сотне раз переписывая с языка на язык и воюя с мультиплеерными антипаттерными синглтоновыми кнопками точно выкинуть стоит - эти так и помрут ничего не релизнув. У джемосерунов хоть что-то есть.
Так и их тоже. Только релизеров платных вылизанных игр ну или крутых джемов типа блендерского dogwalk.
>dogwalk
Который, кстати, и сам на гдскрипте.
>Имаджинируй свое ебало, когда релизную портянку кода придется на шарп мигрировать.
Мое ебало достаточно крючило когда я писал в годот на шарпе с
https://github.com/godotengine/godot/issues/78513
залупой в устранении которой с выхода годот 4 ни на шаг не продвинулись. Посему было принято решение переписать проект в гдскрипт.
Да это ли страх. У меня годот 3 моно на пингвине рандомно вылетает при ребилде проекта раз на 5-15 ребилдов по непонятной причине (монокраш) и в целом похуй, жить можно. Главное сейвиться перед ребилдом (годот сам всё автосейвит)
>>1051277
Шарпы в хрюньке тоже моно огрызок. Дотнет, конечно, хорошая теха, но что он делает в геймдеве я не понимаю.
Имхо, лучше был какой-то js/ts
Можешь срыгнуть на cocos, там как раз всё что нужно есть.
Подумываю забить на геймдев и сделать узкоспецифичный движок - прикрутив lua или js. Оказалось разбираться в том как все работает куда интереснее чем двигать спрайты для стимпомойки.
Успехов на кладбище никому ненужных движков, на котором ничего никогда не выйдет. Я такое сообщение каждый день вижу, но не вижу движков, а игр тем более
>Ахах, на проце тренировать?
Ты ничего кроме transformer никогда не видел?
>он с заглотом возьмет даже у 3060
https://technical.city/en/video/GeForce-RTX-3060-vs-Radeon-8060S
1. RTX 3060: 12 GB (360 GB/s), 170 W, 38 попугаев.
2. Встройка: 96 GB (256 GB/s), 55 W, 40 попугаев.
>скупай по ебеям 3090 и собирай ферму
https://technical.city/en/video/GeForce-RTX-3090-vs-Radeon-8060S
1. RTX 3090: 24 GB (936 GB/s), 350 W, 60 попугаев.
2. Встройка: 96 GB (256 GB/s), 55 W, 40 попугаев.
Вывод: встройка топ, если не нужно греть воздух.
>worms-like игра, и у снаряда есть гравитация
1. Берёшь позиции врагов из списка врагов.
2. Строишь траектории снарядов до каждого.
3. Отбрасываешь плохие траектории (в стену).
4. Из оставшихся, выбирай самую слабую цель.
Если целей не осталось - бери рандомную.
Можно ещё добавить приоритет на толпу...
>Успехов на кладбище никому ненужных движков, на котором ничего никогда не выйдет. Я такое сообщение каждый день вижу, но не вижу движков, а игр тем более
О, я даже не думаю что это будет когда-нибудь product ready.
Главное, чтобы тебе самому приятно было. Всё-таки геймдев - это всего лишь игра. А игры должны всем приносить удовольствие. Так нейронка сказала...
Ты лучше бы не занимался этой хуйней. Погоняй спрайтики лучше - хоть выхлоп будет. Поверь, уже есть движок для твоей игры
>Так нейронка сказала...
Ну раз нейронка, ок
>>1051310
>Поверь, уже есть движок для твоей игры
Кто-нибудь тут копался в коде годота? Какие впечатления?
>1. RTX 3060: 12 GB (360 GB/s), 170 W, 38 попугаев.
>2. Встройка: 96 GB (256 GB/s), 55 W, 40 попугаев.
Нахуй твоих попугаев. Как ты думаешь, почему под иишку берут строго нвидию до сих пор? Сколько бы там попугаев не рисовали, оно будет медленее раза в полтора просто потому что нету cuda и оптимизаций это точно, а бонусом еще латенси памяти это дельце умножит ровно настолько, насколько ддр хуже гддр.
>1. RTX 3090: 24 GB (936 GB/s), 350 W, 60 попугаев.
>2. Встройка: 96 GB (256 GB/s), 55 W, 40 попугаев.
Анон, подучи матчасть по нейронкам. Спасет от необдуманных трат на кал, который ты за тем на манер soc эплоблядей будешь толкать на вторичке, потому что внезвпно процессор даже мощный не может обойти ссаную 3060 и сосёт с 0.5 t/s даже на м4 pro.
>Кто-нибудь тут копался в коде годота? Какие впечатления?
Обычный ооп франкенштейн, а плюсы только дополняют антураж. Просто у юнитеков и прочих студий есть бабки гонять тесты, иметь тестовые стенды в виде разных устройств, писать свои собственные форки языков типа уе++ или юнитимоно, а у годота нихуя этого нет, потому его ооп франкенштейн порой срет под себя и зачастую не по своей воле.
ООП позволяет качественней инкапсулировать код и организовать работу множества человек (100...1000...) в одном монолите, за счет полиморфизма интерфейсов. Процедурное программирование такое не может, отсюда и успех ООП в свое время (а ФП это вообще оторванный от реальности дроч, код ради кода).
Но да, я согласен, что в тырпрайзе и в кривых руках код превращается в блинную-абстракцию над абстракцией. Но поверь, если инкапсуляция не нарушена, это все равно будет легче сопровождать, чем процедурный модульный код.
В общем, лучше когда ООП есть, чем когда его нет. Зумерам сейчас это сложно и микросервисы позволяют срать круды как угодно. Но лучше когда язык мультипарадигменный и есть полноценное ООП.
С чего у тебя так горит? Ты что-то не то купил?
>просто потому что нету cuda
Да нафиг эту куду, в Godot Vulkan Kompute есть!
https://kompute.cc/overview/game-engine-godot.html
>насколько ддр хуже гддр
Там LPDDR5x в 8 каналов @ 8 GHz, до 128 GB.
RAM для игрушек тоже, внезапно, требуется.
>не может обойти ссаную 3060
Qwen3: 235b, 22b активных:
3060: не влезет в VRAM, будет 0.01 t/s.
8060s: 10 t/s, можно сразу читать.
Llama 4 Scout: 120b, 17b активных:
3060: не влезет в VRAM, будет 0.01 t/s.
8060s: 13 t/s, можно сразу читать.
GPT-OSS: 120b, 5b активных:
3060: не влезет в VRAM, будет 0.01 t/s.
8060s: 19 t/s, можно сразу читать.
И так далее. Размер RAM >>>> скорость.
Или лучше на Xeon E5 собрать с 1TB RAM?..
Они используют несколько ограниченный сабсет плюсов, чтобы не ебать мозги контрибьютерам сложными плюсофичами. Нормальный приятный код, комментов хватает, доки окей, можно вкатиться в их рокет чат и поспрашивать если что. Патчил себе движок пару раз. А этот >>1051319 ящитаю лох сренькающий залетный движкосрачерский безыгорный нешарящий, весь день тут серет.
> Да нафиг эту куду
Отставить пиздеть на куду, без неё у меня нейроночки не запускаются
Всё так, двачую
часто копаюсь в исходнике движка
>>1051326
>Процедурное программирование такое не может
В процедурном это и не нужно, но если очень хочется ,то в том же Си делают и интерфейсы, т.к. он ниже уровнем делают руками то, что за тебя делает компилятор цэ++ - структуру функций (VTable)
> Но лучше когда язык мультипарадигменный и есть полноценное ООП.
К сожалению 99% современных языков ООП-первичные. Распознаются по ключевому слову static означающему что весь текст кода обязательно описывает ООП-класс, а необходимость писать вне ООП прибита гвоздём.
>комментов хватает
очевидный брехун, комменты в сорцах это редкость
>без неё у меня нейроночки не запускаются
Что ты там тренируешь, что тебе CUDA нужна?
Я что-то сделал, но не пойму, зачем мне это.
Это на 100% GDScript в реальном времени...
Очень интересная стена текста. Возможно для тебя будет открытием, но llm умеют параллелиться сразу на несколько видюх, потому стак из 3060 в которую влезет ллм разьебет любой проц по производительности. Но проще взять 3090, выйдет дешевле.
> 10 t/s
И на этом ты собрался тренить нейронки?))
Ты бы хоть на гитхаб сходил, ленивая жопа, прежде чем дристать тут. Совсем одебилил в своем движкосрачерском загоне, последние поинты интеллекта всрал. У меня было ровно ноль проблем найти и исправить в сорцах то, что мне нужно.
>>1051327
Ну и забыл дописать - копирование в ддр раму фулл модели и ее гонка по частям по pci в 3090 всё так же покажут куда больший перфоманс чем проц. С шиной у 3090 полный порядок.
Надристал тебе защеку с твоими комментами к функции принт, я не сказал что их нет, я сказал что они - редкость, зайди в папку с рендерами и посмотри там , а коменты уровня
> for i in 10 # цикл по I от 0 до 9
это для малышей вроде тебя
>стак
Если у тебя есть желание выделять под одни только видеокарты несколько 220V/30A линий и обустраивать в 6м2 спальне HVAC, чтобы в зимние -30C морозы охлаждать кровать, разложенную на серверных стойках с твоими видеокартами, до комфортных 40C, пока нейроночки обсуждают что-то между собой на своём нейроночном круглые сутки напролёт, и у тебя есть лишние миллионы рублей на всё это дело - вперёд и с песней, никто тебя не отговаривает. Не все настолько энтузиасты, чтобы этим заниматься.
>тренить нейронки
Нейронки изобрели в 1950-1960, тогда всё основное сделали, и даже тренировали успешно - ручками, то есть настоящими рукоятками устройств, прям пощупать можно было, словно живой мозг. Пики нейросетей пришлись на 1980, 1990, 2000... Когда видеокарты вообще появились, это был OpenGL 1.0 с фиксированным пайплайном. По сравнению с процессорами тех лет эта 50 Ватт малышка настоящий суперкомпьютер в компактном корпусе и без лишних проводов.
На самом деле, в турбо-бусте она потребляет до 140 Ватт, но если бы я приобрёл такой девайс, то держал бы в экономном режиме, чтобы не перегревалась попусту. Я вот так и не нашёл причины использовать нейронки в максимальной загрузке/скорости, это инструмент без задач...
>>1051343
>шиной
У меня PCI-E 2.0. Ты осознаёшь, что мне полностью новый компьютер нужен, а не твоя списанная с васянской криптофермы перегретая видиокарта, которая только матрицы перемножать умеет? Вот я могу получить полный фарш за 150 тысяч рублей с большой и быстрой оперативной памятью, полноценным и быстрым 16-ядерным процессором, достаточно мощным видеоядром, и всё это в компактном корпусе с минимальным тепловыделением и энергопотреблением. А могу собрать серверную башню, в которую придётся поставить процессор с водянкой, натыкать горячих DDR5 с радиаторами, натыкать туда 4 PCI-E 3090 карты с 3 гудящими вентиляторами каждая, каждая из которых в изношенном виде стоит как половина нового мини-компьютера и потребляет как минимум в два раза больше энергии, а умеет на порядки меньше - видеокарта же, "настоящего" процессора в ней нет, только тысячи огрызков. При этом на практике использовать все эти 4 видеокарты мне придётся раз в несколько дней в лучшем случае, если сравнивать с тем, как я использую бесплатный доступ через duck.ai. Ну и во что лучше вложиться?
Хуя, ты уже на что-то способен, в папки какие-то заходишь. Еще пару раз потыкать тебя носом в твое же говно и глядишь реально игры делать начнешь.
Буду честен, я стриггерился на слово "тренить". Тренить на проце это самая конченая идея, я просто надеюсь ты это осознал. Запускать какой нибудь кал типа квантованого дипсика или квена окей, но нахуя, а главное зачем? Поиграешься ты с этими тупыми ллмками, а дальше наступит понимание что они не всрались (потому что тупые, в тысячи раз тупее любого онлайн аналога) а генерить картинки будет больно потому что я уже обьяснил почему, если нейронка влезет в 3060 - она разьебет любой проц. В 3060 влазит флюкс bf16, влазит хрома, влазят все sdxl'и, плюс на ней реально можно тренить, пусть что-то уровня sd1.5. Может я конечно что-то в этой жизни не понимаю и не знаю кайфа запуска тупых обрезаных ллм с хагги, но подозреваю обратное.
> с твоими комментами к функции принт
> print.bind("A").bind("B").unbind().bind("C").call()
Сможешь без комментов (и без запуска) вычислить, что напечатает?
Создаётся впечатление, что ты вообще не знаешь, о чём идёт речь. Речь не столько о центральном процессоре (но и о нём тоже, потому что в видеокартах его просто нет, нужен внешний), сколько о "встроенном" видеоядре - это отдельный чип, который физически находится рядом с процессором, но он сам по себе работает, независимо от процессора. То есть это то же самое, что и "видеокарта", только без "карты", потому что у неё общий корпус с процессором и общие линии к оперативной памяти.
Так вот по чистой производительности видеочип 8060s обгоняет видеочип RTX 3060. То есть если ему дать графическую задачу, он её решит быстрее дискретной видеокарты и при этом потратит намного меньше энергии. По скорости памяти мини-пк (материнка + RAM) с его использованием чуть-чуть отстают от 3060, поэтому это не важно. Главное, что ему доступно в 8 раз больше "видео"-памяти, а это значит, что Mixture of Experts могут умещаться целиком в память вместо перекачивания туда-сюда. Активных параметров у них относительно мало и поэтому они быстрые и одновременно с этим умные. Для примера, Llama 4, имея всего лишь 17 миллиардов активных параметров, по интеллекту примерно как Llama 3, которой нужно активировать все 70 миллиардов параметров на генерацию каждого токена. Но у Llama 4 общее число параметров - 120 миллиардов, поэтому она в твою 3060 просто не поместится (Llama 3 70b тоже), а вот встроенный видеочип имеет доступ к просторным 96 Гб оперативки и поэтому всё у него умещается.
По генерации графики я без понятия, меня это не интересует, но предположу, что если вся эта генерация графики когда-нибудь сдвинется с мёртвой точки, там тоже найдут способ применить Mixture of Experts для ускорения (если ещё не применяют). Другого пути нет - даже биологические мозги самых разных животных эволюционировали именно по этому пути, а искусственные сети идут по пути подражания.
Про "тренировку" я тебе уже всё объяснил - тренировать можно не только "трансформеры". Что тут ещё объяснять? Даже если у тебя 1 нейрон с 1 входным параметром (в буквальном смысле одно число) и ты его ручками изменяешь (буквально с клавиатуры вводишь) - это в терминах "искусственного интеллекта" (науки, а не того, что маркетологи навесили на уши) будет считаться "тренировкой" (не "глубокой", а просто "тренировкой", потому что нет нескольких скрытых слоёв). Не нужно рассказывать о том, что для осмысленного изменения триллионов параметров за приемлемое время с текущими алгоритмами и ограничениями железа потребуется целый склад с видеокартами - это всем очевидно.
Если хочешь попробовать, вот: http://playground.tensorflow.org/ - тренировка нейронной сети прямо в браузере на любом телефоне, без регистрации и СМС, результат видно за считанные секунды. Не нужно скупать кластер из списанных 3090, чтобы "натренировать искусственную нейронную сеть", понимаешь?
Ну нравится тебе коупить, что ддр обойдет гддр а видеочип не от зеленых с уменьшенным количеством тензорных блоков выебет графический дискретный чип - коупи дальше. Я бы обьяснил, но мне похуй, в конце концов бабки не мои.
>бабки не мои
Свои-то ты уже потратил на малополезную печку? Или две?
Не беспокойся, я не собираюсь ничего покупать. Мне лень.
Ну я на своей печке могу внатуре полезными мне делами заниматься (например рисовать картиночки, так как они влазят мне в vram), а не запускать квен и радоваться 10 тупейшим токенам в секунду. Имхо лучшей инвестицией будет поддержать группу складчиков в которой я покупаю онлайн ллм сервисы за 1/5 цены имея умнейшие нейронки в прямом своем распоряжении, которые мне реально помогают работать, а не тешат меня фактом своего старта. Ну это мое видение, не вижу смысла его навязывать.
Т.е. ты ассеты флипаешь, а не разрабатываешь оригинальные технологии искусственного интеллекта специально для своих игр... Ты хотя бы пробовал подключать заранее обученные LLM внутрь своей игры? Я пробовал, мне не понравилось - мне не нравится то, чему они обычно обучены, и то, что они полностью зафиксированы/заморожены, и поэтому я хочу делать полностью кастомную архитектуру с нуля, без pretrain весов, чтобы там лишнего ничего не было, и чтобы можно было обновлять веса в реальном времени, во время игры, как в реальной жизни... или даже не игры, не важно, игра - это просто оболочка, виртуальная площадка для экспериментов, выдуманный интерактивный мир.
Но это, конечно, всё просто мой шизофренический бред, и поэтому я этого делать не буду...
>Ты хотя бы пробовал подключать заранее обученные LLM внутрь своей игры
А нахуя так делать? Ну, рил, какие плюсы от ллм в игре? Я понимаю там если на базе трансформеров обучить что-то типа npc иишки (на обучение которой понадобится покупать runpod), но просто генератор текста мне нахер в игре не упал. Возможно имеет смысл для каких-то целей пихать vision модели, но опять же, мне трудно представить куда и зачем.
>поэтому я хочу делать полностью кастомную архитектуру с нуля, без pretrain весов
Удачи, лол. Особенно зная что прогресс обучения не детерминирован (от забора до обеда) и в процессе обучения придется выбраковывать целые эпохи, потому что почему-то всё идет по пизде на текущем шаге и узнать об этом можно только постфактум. На проце занятие будет еще более увеселительное чем обычный файнтюн. Даже разрабы первых русских ллм не выебывались а взяли дипсик и его отфайнтюнили, а ты тут решил с нуля хуйнуть ллм с блекджеком и шлюхами.
>обновлять веса в реальном времени, во время игры, как в реальной жизни...
Потужность зашкалила за пределы разумного
А меня генерация картинок устраивает, я с помощью лор и openpose выставляю персонажей в нужных позах, затем генерирую, после буду анимировать в anime effects и будут готовые персы. Одежда туда же. Имхо моя 3060 полностью отрабатывает свою пайку, еще и фапконтент поставляет такой какой я хочу на сдачу.
>какие плюсы от (искусственного интеллекта) в игре?
А ты точно занимаешься геймдевом? Или только картинки генерируешь?
>на обучение которой понадобится покупать runpod
Чатботам 90-х/00-х не требовалось, а в 2020-х ВНЕЗАПНО потребовалось?
Опять же, никто не требует быть гигамозгом с 2500 ICQ на бенчмарках...
>прогресс обучения не детерминирован
>в процессе обучения придется выбраковывать целые эпохи
Проблема архитектуры и/или алгоритма обучения (бэкпроп нестабилен).
>ллм с блекджеком и шлюхами
LLM - это LARGE language model. Сами language model - старая технология.
>за пределы разумного
Учи мемы: https://en.wikipedia.org/wiki/Online_machine_learning
>...where it is computationally infeasible to train over the entire dataset...
Т.е. онлайн лёрнинг - это, внезапно, оптимизация машин лёрнинга. Лол!
>А меня генерация картинок устраивает
Ну, устраивает и устраивает. А меня интересуют конфетки, а не фантики.
И вот будущее наступило.
Нейросети растянивают 540р на 4к. Генерация фреймов делает 240 ФПС из 15-ти, только вот фреймы инпута так и остались в пределах 15-ти. Наслаждайтесь, кушойте.
>ТЕС мы мечтали, что вот создадут ИИ, и все неписи в играх будут как живые
>ТЕС
Есть такое уже, канал "ролеплей для души". Дождались. Покекали. Оказалось интересным цирком, но неиграбельно.
Вот-вот. Бойтесь желаний своих, ибо исполняются.
Настоящий ролеплей - это диалоговые шахматы, где каждая строчка и игрока и неигрока заранее прописана АВТОРОМ и игрок, жонглируя строчками диалогов разыгрывает партию, в игре, по правилам, а дурачки всё мечтают о какой-то там реалистичности. Чтобы неписи с ними о погоде, значит, рассуждали.
Какой-то троллинг тупостью пошёл, неудивительно что ты собрался тренировать нейронки уровня квен на проце с нуля ебать.
https://www.dns-shop.ru/conf/3737f0e43b2bbf0c/
1 ссд для системы, 1 ссд для геймдева, 1 хард для порно.
И это уже конечно звиздос по 70 тысяч.
Самая дешевая сборка днс
https://www.dns-shop.ru/user-pc/configuration/3c835d1bee3f1578/
Добавить оперативы и ссд получится не меньше 50к.
Никогда мне хобби столько не стоило.
Теперь хз стоит ли вообще брать ам5 вместо ам4 если я не участник пс-мастер-рэйс и мне по факту один годот нужен и максимум может быть когда-нибудь юнити.
Нахуй эти слоудиски в 2к25 нужны? ХДД, ССД, вообще охуеть. У тебя на мамке 2 слота m2 nvme, вот два nvme диска и возьми как нормальный современный человек. Я прям физически ощущаю когда работаю за системой с обычным ССД и тем более с ХДД - все пиздос какое слоу, а если уж игори гонять то за эти долгие лоадинг скрины чай успеваю сделать.
> У тебя на мамке 2 слота
Мне оно не уперлось, я просто пересажу имеющиеся ссд/хдд с текущего пк чтобы сэкономить. В список добавил для полноты картины.
По факту мне нужен копрус, плата, бп, цп, видео.
Возьми один нормальный современный nvme, поставить на него систему и держи на нем самые частоиспользуемые файлы - охуеешь с того, насколько все шустрое и отзывчивое.
Разве что дополнительные аргументы передать нельзя. Или можно?
Выглядит как грязный хак уровня синглтонов.
>Какие подводные
У ТЕБЯ ДЖВА ОБЪЕКТА
@
НО ОНИ СЛИШКОМ ДАЛЕКО
@
ОХ, КАК ЖЕ ЛЕНЬ ДЕЛАТЬ НОРМАЛЬНО
@
ЛУЧШЕ ПРОБРОШУ ГЛОБАЛЬНЫЙ СИГНАЛ
@
СПУСТЯ НЕСКОЛЬКО ДНЕЙ/НЕДЕЛЬ/МЕСЯЦЕВ
@
ТАК, ЗДЕСЬ У НАС СИГНАЛ... НО ОТКУДА???
@
ВСЁ ЧТО МОЖНО ВЫПИЛИЛ, А ОН ЕСТЬ!?
@
УУУУУ, КАКОЙ ДЕБИЛ ЭТО ПРИДУМАЛ?!
@
ИДУ ЖАЛОВАТЬСЯ НА БАГ ДВИЖКА
@
В СМЫСЛЕ В ДВИЖКЕ ЭТОГО НЕТ?
@
В СМЫСЛЕ ЭТО В МОЁМ КОДЕ???
@
Я ЧТО, ПЬЯНЫМ КОД ПИСАЛ???
@
ААААААААААААААААААА!!!
@
TODO: ВЫРЕЗАТЬ <ЭТО>
@
СПУСТЯ НЕСКОЛЬКО...
Просто ctrl+shift+f, signalname, и все находится куда и откуда.
>дополнительные аргументы передать
Я не пробовал, но должно сработать:
1. Делаешь свой класс:
>class_name SchizoEvent extends InputEvent
>var arguments: Array # или что-то другое
2. Отправляешь его этой функцией:
>var event := SchizoEvent.new()
>event.arguments = ["bla bla bla"]
>Input.parse_input_event(event)
3. Принимаешь в другом месте:
>func _input(event: InputEvent) -> void:
>_ if event is SchizoEvent:
>_ _ hallucinate(event.arguments)
>_ _ get_viewport().set_input_as_handled()
>_ else: print("what the %s???" % event)
Но так лучше не делать - лишние _input().
>>1051427
>ctrl+shift+f
Ты на Visual Studio сидишь? Сочувствую...
>Я не пробовал, но должно сработать:
Работает. Заебись. А принимать буду в _unhandled_input. Люблю годот.
Спасибо, не знал. Недавно добавили?..
Но всё равно не всё можно найти по имени. И даже найдя, не всегда понятно, как оно используется, что произойдёт, если его выпилить, чем заменить. Это и называется "лапша", которую рано или поздно долго распутывать придётся, чтобы воткнуть что-то новое, починить старое или просто понять, что происходит.
Поэтому лучше стремиться к локальным связям и организовать дальние связи как можно реже, по определённым соглашениям ("signal up, call down"). Натыкать дальних вызовов всегда успеешь, а вот распутывать этот клубок в будущем будет трудно.
Знаешь, что меня удивляет в современных кодерах? "Слишком долго печатать", говорят они, обсуждая тривиальную фичу, что они давно могли бы себе разработать и иметь в одном из своих модулей, т.е. обращаясь через API, а не печатая всё с нуля. Я вот восхитился гениальности модулей/библиотек в коде программ, когда узнал, что я сам мог бы написать универсальный код и потом просто его вызывать... Перетаскивая с проекта на проект как инструмент. Развесистую лапшу так переносить очень сложно.
>>1051430
>_unhandled_input
Этот обработчик вызывается после всех остальных вариантов инпута и поэтому твоё событие, вероятно, вызовет много лишних if event is... в других _input(). Посмотри на мониторах производительности, что вызывается и сколько раз (там прям счётчики есть).
> грязный хак уровня синглтонов
Главное чтобы была игра.
> СПУСТЯ НЕСКОЛЬКО ДНЕЙ/НЕДЕЛЬ/МЕСЯЦЕВ
Документируй. Следуй соглашениям (и своим внутренним, и общепринятым, и авторов движка). И никогда не потеряешь свой синглтон. При должной сноровке даже через 10 лет открывая свой код, всё прекрасно находишь.
>>1051422
> Какие подводные
Дичайший оверхед. Несколько тредов назад рассматривали уже. Вместо этого, у тебя уже есть глобальный кандидат на глобальную шину данных, доступный отовсюду из любого файла проекта !без дополнительных настроек! и это - get_tree() - по вызову которой возвращается ссылка на главный цикл приложения. Туда тебе достаточно пробросить своих юзер-сигналов и не надо ни с каким инпутом возиться:
> if not get_tree().has_user_signal(&"shizo_event"): get_tree().add_user_signal(&"shizo_event")
Всё, готово, у тебя есть глобальный сигнал на глобальной шине. Чтобы его испустить делаешь так:
> if get_tree().has_user_signal(&"shizo_event"): get_tree().emit_signal(&"shizo_event")
А чтобы на него подписаться
> if get_tree().has_user_signal(&"shizo_event"): get_tree().connect(&"shizo_event", on_shizo_event)
Ну и всё. Это будет работать без дополнительных телодвижений. Единственное неудобство, слишком длинно и неуклюже записывается. Можешь сделать классы-обёртки над этим кодом и удобно расставлять их по сцене, так уж точно не забудешь, где твои сигналы. Можешь еще посмотреть на ассетлибе, я там недавно похожий аддон видел с готовыми нодами-обёртками. Сам не юзаю, это же антипаттерн.
>Главное чтобы была игра.
Это в самом начале, а потом наступит рефакторинг. Особенно если делаешь игру сложнее гиперказуала. Технический долг - это не просто смешной мем от энтерпрайз бэкэнд программистов, к сожалению.
>Документируй.
Главная проблема документации - она устаревает. Т.е. хаотичные изменения в коде быстро делают все твои комментарии неправильными, особенно если они описывают взаимодействие между системами. А лапшичный код - путь к хаотичным изменениям.
>При должной сноровке...
Для неё не обязательно бегать по граблям 10 лет.
>Дичайший оверхед
Тут ты прав. Но дальше я не согласен:
>get_tree().add_user_signal()
>get_tree().emit_signal()
Откуда ты это делаешь? Из рандомных файлов? Следовательно, обвешиваешь проект "лапшой". Следовательно, накапливаешь технический долг. Следовательно, потом будет тяжело разгребать...
>Сам не юзаю, это же антипаттерн.
Зачем ты тогда это предлагаешь? Шило на мыло...
Разгребать ничего не нужно. Ты просто релизишь и идешь дальше. Уж сколько этого "технического долга" и черезжопных решений в ААА проектах видели, ууу бля, возьмешься моды делать и охуеваешь.
Технического долга у нас мало. Оттого и игор нет.
1) Мне хочется куски земли произвольной формы, с достаточно точной физикой, но чтобы они могли "покачиваться на ветру" независимо друг от друга. Прототип сейчас состоит из StaticBody3D и trimesh коллизий... Оно вроде бы работает, но хорошо ли? Я понимаю, trimesh дорогой и полый - внутрь можно провалиться, но есть ли альтернативы? Генерация выпуклых (convex) шейпов уж больно глючная - не описывает все необходимые изгибы как я хотел.
2) Пробовал цельные большие куски островов, но хочется разделить их на мелкие детали всё-таки. Возникает вопрос, как маскировать стыки? Часто получается резкий ненатуральный перелом. Очень хотелось бы сэкономить на шейдерах... поэтому сложные решения использовать не хочется. Вроде некоторые игры стыки не маскируют совсем, но выглядит это, на мой взгляд, как-то не очень.
3) И если уж буду делать из мелких частей, тогда хотелось бы разделять их на RigidBody3D в момент разрушения почвы, т.к. эффект частицами унылый. Вопрос в том, оставить ли StaticBody3D или лучше использовать RigidBody3D.freezed = true? На дереве сейчас шарик как раз в таком виде... Но, вообще, поддерживает ли RigidBody3D trimesh'и? Раньше жаловался на это, но теперь я использую Jolt. Не хочется делать везде отдельные convex шейпы...
Не смотрите на провал верёвки в почву - это моя преждевременная оптимизация виновата. Сделал слежение верёвки за объектом сцепления только при условии что этот объект RigidBody3D. Т.е. там достаточно одну строчку удалить для фикса.
Ещё планирую позже сделать потоки атмосферы, передвигающие архипелаги островов целиком, но, наверное, это будет мнимое движение, т.к., по идее, скорости получаются выше обычных в физике. Т.е. реализую через изменение горизонта и биомов.
Правда, как рисовать горизонт и облака я пока не определился, всё слишком сложно или не так, как хотелось бы. Да я и не уверен, как хотелось бы...
1. Я леплю более сложные шейпы из BoxShape и ConcaveShape.
2. Неоднократно видал на ютубе видосы, как сделать автотайловые меши в тридэ. Возможно тебе подойдёт такой способ? Минус этого способа очевиден, будет угадываться ячеистость под поверхностью, кубизм.
Вот один из https://www.youtube.com/watch?v=bwcEh2HffoY
>ConcaveShape
Concave (вогнутый) - это и есть trimesh:
>ConcavePolygonShape3D
>A 3D trimesh shape used for physics collision.
Документация рекомендует ConvexPolygonShape3D:
https://docs.godotengine.org/en/stable/classes/class_convexpolygonshape3d.html
Но их сложно делать вручную, а генерация, как минимум та, что в Godot, как-то не справляется.
>>1051463
>GridMap3D
Да это знаю, пробовал давно. Это вообще никак не касается визуальных швов на мешах: если меши не идеально стыкуются, то по нормалям (отражённому поверхностью свету) видно, где находится стык... Кажется, можно в шейдерах замаскировать, но не хочется натягивать тяжелый шейдер на всё сразу.
Представь себе склон горы... А, лучше нарисую. Вот визуально хочется 1, а на практике удобнее иметь 2.
>Вот визуально хочется 1
А если поставить в угол куб и повернуть его на 45 градусов?
Сделай уже реактивные ранцы, хватит башкой биться об острова, даже на видео это утомительно смотрится. У тебя же sci-fi, а не игра про внебрачную дочь человека паука.
> уже скоро выйдет
Любимые слова безигорника
Успех майнкрафта чешется в одном месте, но кроме как на подражание уровня карго культа мозгов не хватает.
Уже даже по видео видно, что добавляя динамику в кубо-мир ты тут же ограничиваешься анимацией и в целом иммерсивностью с реализмом.
Понятно что решает маркетинг, кормят и не таким, но нафига брать этот кубизм, если у тебя приключение?
>Урина 5
Представьте лица олдафагов, когда у них майкрафто-подобная игра будет тормозить.
>как рисовать горизонт и облака
Что-то такое хочу, но не знаю, как лучше сделать...
>>1051472
>хватит башкой биться об острова
Это из-за моих кривых рук. По задумке, она должна ненадолго терять сознание от таких ударов, а игрок вынужден избегать таких резких ударов головой. Контроллер ещё недоделан, чтоб можно было этот геймплейный элемент полноценно оценивать... Но, разумеется, мне самому неприятно так ударяться.
>Сделай уже реактивные ранцы
Ты не понимаешь, крюк-кошка тут - это ядро игры, абсолютно всё строится вокруг её использования, реактивный ранец поставит крест на этой игре.
И что именно ты ожидаешь от реактивного ранца? Прямолинейное движение? Это просто - и скучно. Хардкорное управление несколькими соплами по отдельности? Тогда я буду биться об препятствия намного чаще, чем с крюком-кошкой сейчас...
Крюк-кошка - это умеренное испытание навыков, достаточно сложное, но не слишком агрессивное. Отсутствие испытания = скучно, а если испытание агрессивное - оно будет только выводить из себя.
>даже на видео это утомительно смотрится
Ну, видимо, ты не в целевой аудитории...
>У тебя же sci-fi
https://en.wikipedia.org/wiki/Science_fantasy
>игра про внебрачную дочь человека паука
Это клон Worlds Adrift (a.k.a. Lost Skies) от Bossa. Специальный гаджет потом сделаю... Есть очень интересная идея, как совместить всё в одном. Т.е. верёвка не из рук выстреливается, а из гаджета.
>>1051476
>Gravity Rush
Спасибо, интересно будет глянуть. Но там что-то совершенно другое по геймплею. Моя игра, вроде, значительно ближе к Raft, только я ещё планирую неограниченное (в теории) число NPC спутников. Строительство и обслуживание дирижабля по идее является основным геймплеем после, собственно, перемещения по островам ради сбора ресурсов.
>>1051484
>нафига брать этот кубизм
Предположу, что факторов несколько:
1. Если хочешь разрушаемость и строительство, буквальные кубики - это самое простое как для разработчиков, так и для игроков (визуально).
2. В этом стиле дешевле делать 3D модели.
3. В этот стиль легче погрузиться игрокам.
4. У этого стиля шире целевая аудитория.
Посмотри на реалистичные 3D игры. В них:
1. Либо статичный мир, либо очень неудобный.
2. Модельки дорого-богато сделаны, но их мало.
3. Любой косяк графики выбивает из погружения.
4. Целевая аудитория непонятная/непостоянная.
Так что кубики - это вполне логичное решение.
Но лично мне они не нравятся...
> вроде, значительно ближе к Raft
Видал я тут анончика, который хотел сделать игру по мотивам рафта. Вместо плота у него был т--щ---д, вместо океана - целая в-------я н------т, в которой з---ды и п----ты это п----ти в Т. А основной геймплейный цикл ему мыслился как майнинг ресурсов в п----тях, чтобы ремонтировать и апгрейдить свой т--щ-х-д и двигаться дальше, а встречая НПЦ получать различные интересные квесты. Эх, где он теперь тот анончик? Ушёл от нас навсегда.
Как успехи? Что нового? Интересно.
>>1051499
Главное, чтобы это был не синглтон.
Это будет очень тяжело, но я постараюсь что-то базовое сделать, хотя бы пинг понг или змейку. Кодить и рисовать понятно где. Звуки где-нибудь да найду, а вот музыку свою хотелось бы делать. Хотел FL Studio скачать с рутрекера, но началась вирусная паранойя. Еще и непонятно как с лицензией, легальностью музыки с пиратки и всем таким...
>легальностью музыки с пиратки
Никак не проверяется, следовательно всем похуй. Это как те случаи когда понтовые рисоваки, продающие свои рисунки, палили на стриме свой крякнутый фотожоп.
Ну или возьми сс0 музыку.
> Главное, чтобы это был не синглтон.
Фраза ("signal up, call down") реально мозги на место вставляет. Напоминай её почаще. Многих анонов сможешь переубедить.
Ебанул первый уровень и накачал сс0 звуков и музыки, примерно так вся игра думаю и будет построена, ресаешься в одном месте, бежишь на арену и на ней мочишь всех пока враги не кончатся.
>музыку свою хотелось бы делать
Да как же вы задолбали, 3 секунды поиска:
https://en.wikipedia.org/wiki/LMMS
https://github.com/lmms/lmms
https://lmms.io/
>>1051524
>Никак не проверяется
https://ru.wikipedia.org/wiki/Цифровой_водяной_знак
Заработаешь много бабла - люди заинтересуются...
>>1051529
>signal up, call down
Главное при этом на отдельные сцены делить.
>>1051532
>бежишь на арену
В чём фан просто бежать по пустым коридорам?
Твой лес мне напомнил Etrian Odyssey (2007, NDS).
А по звукам отдалённо напоминает Serious Sam...
Молодец. Побольше бы видео с играми анонов.
>В чём фан просто бежать по пустым коридорам?
Время расстянуть, ну и в целом как-то придать атмосферы чтоль, что ты вот не просто появляешься из воздуха, а сначала идешь и тут БАЦ, че-то случилось. ПЛюс хочу ещё всякие тайные тропы сделать, по которым будут бегать гномики, но когда будешь к ним приближаться они начнут убегать, хихикать и пропадать в глуши
>Молодец
Спасиба
>Заработаешь много бабла - люди заинтересуются...
Настолько чтобы заинтересовались - не заработаешь. Это как переживать что в день перед релизом игру в мультиплеер придется переделывать.
>Оказалось разбираться в том как все работает куда интереснее чем двигать спрайты для стимпомойки.
наверно потому что из тебя плохой режиссер. придумывать механику, лор, всякие хуки, вау-штуки, анимки и сцены, всё это жуть интересно. но сложно. ведь надо фантазию врубать и головой работать. в то время как "разбираться в том как все работает" это просто ложное ощущение прогресса и развития, потому твой мозг это интересным посчитал, платит тебе удовольствием, так как видит наличие определенности в процессе красноглазия "а чо там под капотам", ведь сиди читай и ничего изобретать не надо. определенность, которая отсутствует в творческом процессе. потому этот творческий процесс твой мозг обесценил, чтоб ресурсы сэкономить. хватит рационализировать свое бездействие.
Не забудь проверить наличие синглтона у себя под подушкой перед сном, а то укусит.
>>1051436
>Это в самом начале, а потом наступит рефакторинг
Вам ехать или шашечки? Твоя проф деформация в инди геймдеве скорее минус, чем плюс
>Главная проблема документации - она устаревает
Потому что сначала вносятся изменения в доку, а потом в код. А хаотичные изменения сразу документируются.
>В чём фан просто бежать по пустым коридорам?