Шапка: https://hipolink.me/godothread
Предыдущий 83: >>1104969 (OP)
---
Все статьи, читать: https://godotengine.org/blog/
Все версии, скачать: https://github.com/godotengine/godot-builds/releases
Я тут читаю учебник по Zig (в прошлом треде анон заинтересовал) и знаете что? Это же системный вариант гдскрипта! Тот самый, о котором мы мечтали не менее 40 тредов - вот же он!
Вы только поглядите на синтаксис. Мы же именно эти изменения.
Ну не знаю, кто куда, а я на зиг перекатываюсь. Вода замёрзла. Перебьёмся. Остаёмся.
Да, там автор написал какую-то построчную компиляцию, в итоге получается кодгенерить налету. В общем, системный язык но ведет себя как интерпретация динамикоязыков.
У этого есть минусы (и плюсы, конечно). Но в любом случае надо писать тесты на любых языках.
Надо еще понимать что это не язык для попила хайпа. И что это все еще односторонний интероп над сями.
Тот же пакетный менеджер ньюфагов точно отпугнет. Или ручная инъекция памяти/io. Да и не всем хочется обрабатывать out of memory при каждом добавление в динамический список.
В общем, если держать в голове что это "новый" си, то системный бойлерплейт терпим. Но тем кто кроме гдскрипта ничего не нюхал - будет сложно.
Еще им, вроде, удалось сделать асинхронный код без покраса. Но я еще не вникал, но звучит круто.
Zig очень хорош как язык, даже есть биндинги godot-zig, перекатывайся, я там был пару лет назад.
Вот это уже интересно. Изучаю дальше.
>>1108528
> кроме гдскрипта ничего не нюхал
Я нюхал от Паскаля с бейсиком до си, джавы, шарпа, питона, раста. Мне норм.
>>1108535
Мне нравится такой подход: на системном языке следует писать ядро игровой логики, со всеми менеджерами, фабриками, моделями, контроллерами. А на гдскрипте нужно писать логику подключения к этому ядру и настройки параметров.
В качестве системного я сначала рассматривал шарп, но оказалось, что он тащи за собой дотнет и нет простого способа сделать нативный билд. Потом я попробовал присмотреться к расту, но там меня разочаровала абстракция владения, которая должна была дать людям абсолютно непотопляемый код, надёжный как швейцарские часы, но люди не поняли и кодят на ансейфе. Кроме того ref<ref<ref<ref>>> окончательно добило интерес.
И тут такая Зига нарисовалась! Все нравится. Дошел до аллокаторов. Нравятся. Выглядят логично, понятно.
>Вот это уже интересно. Изучаю дальше.
Только учти что переписали они i/0 в каком-то последнем патче. Книги будут отставать.
>Вы только поглядите на синтаксис. Мы же именно эти изменения.
Какие "эти"?.. Загуглил хэлло ворлд, вы только посмотрите на это:
>const std = @import("std");
>pub fn main() void {
>_ std.log.info("Hello, World!", .{});
>}
Это же просто... просто... буээээ... простите... Это же C без ++!
Зачем все эти извращения? Чтобы что? Быть "не таким как все"?
Просто берите то, что удобнее - т.е. GDScript.
А для кранча больших циферок берите C/C++.
Что тут ещё можно выбирать 40+ тредов?
Алсо, завязывайте со скриптосрачем.
Это сорта прокрастинации у них. Ищут причины чтобы нихуя не делать, как всегда. Дай им супер-производительный годот-зиг-хуиг прямо в мейнлайне движка - найдут другую причину хуи пинать.
А реальность, напомню, на пике. И доля гдскрипта выросла относительно 2025 года.
Придётся более серьёзно изучить разные защиты проекта.
Забавно, но график больше показывает сколько вкатунцов любителей, залетевшие на хайпе и реальный разработчиков.
На гдскрипте не практично писать либы и любые системы/сервисы/менеджеры итд. Ну мы же не тетрисы делаем.
Ты думаешь, все прокрастинируют как ты, раз пишут в тред. Но ты не думал что реальность другая?
Ты еще не видел новый хелловорд с новым i/o.
И все равно это приятнее чем сишный макросный ад.
Получается, что автор столкнулся с прагматичной реальностью и отступил от своего принципа, чтобы не было "скрытой" логики, выполняющейся под капотом. Ну и ладно, так хотя бы реальные программы станет можно писать. Может, и ООП когда-то решится добавить.
>>1108633
У C/C++ есть некоторые родовые травмы именно в синтаксисе. Такие штуки как не всегда однозначный парсинг https://en.wikipedia.org/wiki/Most_vexing_parse который приводит к ошибкам программиста, или к долгой компиляции. Не просто так многие современные языки делают вот этот синтаксис где до объявления пишешь ключевое слово func, а после объявления и спец символа -> возвращаемый тип.
>Еще им, вроде, удалось сделать асинхронный код без покраса.
Насколько я понял, как раз не удалось, там был какой-то неявный автовывод компилятором, который был слишком запутанным, и переписывание IO как раз привело к отказу от этого.
>Получается, что автор столкнулся с прагматичной реальностью и отступил от своего принципа, чтобы не было "скрытой" логики, выполняющейся под капотом.
Речь и проблему скрытой/неявной аллокации и ошибок. Любой метод это абстракция.
Например можно написать базу с гарантированной работой (чел, который пропагандировал раньше раст и написал LSP для раста)
https://www.youtube.com/watch?v=NAOOGB1q6uQ
>Может, и ООП когда-то решится добавить.
ООП в системной разработки зло
Лезть в зиг или плюсы нужно только если ты собираешься свой движок собирать. Годотеру шарпов за глаза. Ты выиграешь 5-10% но будешь сидеть и побеждать системный язык. А если у тебя скрипт из чистых API лучше написать на гдскрипте.
>не всегда однозначный парсинг
Вообще не понимаю, нахрена в C-подобных языках указывается тип переменой и тип возврата функции задолго до самой переменной/функции? Мне вот на практике сначала известно имя того, что я планирую описать, а уже потом я думаю над тем, какой именно использовать тип/класс для хранения/возврата. Эта необходимость сначала указать некий тип для того несуществующего чего-то, что ещё не придумано, выбивает меня из потока. Как люди справляются с подобным неудобством в большинстве языков?
>современные языки
C - 1972, Pascal - 1970, ALGOL - 1960, Fortran - 1957. Современные языки просто вернулись к БАЗЕ, поняв косячность бредовой C-подобной фигни. Ещё бы все бесполезные скобки выкинули и писали нормально, литературным текстом, без лишних спецсимволов (машинный код, а не промпт галлюционирующему генератору псевдослучайных токенов в тексте).
В C# нет этих проблем. Это просто тупость автора языка, вроде указания переменных на стеке (Foo foo(10); ), которая создает эти проблемы.
> и писали нормально, литературным текстом
БЫТИЕ ОПРЕДЕЛЯЕТ СОЗНАНИЕ
Это написано литературным текстом. Теперь давай, распарсь, кто здесь кого определяет?
В C# всё то же самое - сначала тип, потом имя.
>>1108818
У тебя некорректный пример.
Вот более корректные сравнения:
ВАСЯ ЯВЛЯЕТСЯ ГЕЙМДЕВЫЧЕМ
МАША ЯВЛЯЕТСЯ ШКОЛЬНИЦЕЙ
ШКОЛА ИМЕЕТ МНОГО ШКОЛОТЫ
ФАЛЬКО ПРОИЗВОДИТ СЛОПЧИК
РОКСТАР ПРОИЗВОДИТ ГТАШКИ
Сравни это с:
ОТ ГЕЙМДЕВЫЧА ПРОИСХОДИТ ВАСЯ
ОТ ШКОЛЬНИЦА ПРОИСХОДИТ МАША
ШКОЛОТА МНОГО ИМЕЕТСЯ В ШКОЛА
СЛОПЧИК ПРОИЗВОДИТСЯ ФАЛЬКО
ГТАШКИ ПРОИЗВОДИТСЯ РОКСТАР
Вот вроде понятно, а звучит неудобно - запутывает.
В C# нет проблем с парсингом из-за этого, только вкусовщина (мне нравится)
>C-подобных языках указывается тип переменой и тип возврата функции задолго до самой переменной/функции?
Потому что матерые программисты в коде "думают типами", а ньюфаги думают "названиями переменных", а уже потом им редактор подсказывает тип - то есть, ньюфаги вообще не контролируют ситуацию.
Тоже самое с функциями, ты сначала думаешь какой результат получить, а уже потом что закинуть в коробку.
У тебя синдром утёнка, выучил паскаль в детстве и сидишь скобочек пугаешься.
Люди пытались сделать из языка программирования - естественный язык, но всегда получалась какая-то жопа.
Почему передвинули тип? Да потому что парсер удобнее писать, не от хорошей жизни, средний специалист тупеет, забытые технологии древних
Ты думаешь эти люди смогут написать ядро шарпов?
https://2ch.su/pr/res/3735926.html#3736033
>"думают типами", а ньюфаги думают "названиями переменных"
Тип данных может поменяться вместе с задачей, а название переменной меняется не так часто. Скажем, у тебя есть счётчик денег, который ты создал сначала как float, обосрался от ошибок с округлением и резко переделал на int, но потом узнал, что в твоём языке поддерживаются числа с фиксированной точкой, и снова переделал. То есть тип поменялся два раза, а название переменной осталось без изменений. Или ты сначала сделал индексы в форме строковых констант, обосрался от того, как долго происходит сравнение, переписал на int, потом подумал-подумал и переписал на enum, а потом обнаружил StringName и снова переписал на строки, но теперь без замедления. Опять - имя не поменялось, а тип поменялся 2-3 раза. Потому что задача строится как "что нам нужно", а не "через что это имплементировать" - нам нужны "деньги" или "индексы", а через какие типы данных эти вещи будут реализовываться - дело десятое. Ты не можешь контраргументировать в стиле "олдфаг не будет ошибаться" - во-первых, это лишь означает, что он подорвался на этом в прошлом, во-вторых, не допускает ошибок только тот, кто ничего не делает. Лучше пусть точная машина следит за ошибками, чем человек грузит своё wetware лишними самопроверками.
>сначала думаешь какой результат получить, а уже потом что закинуть в коробку
Сначала ты думаешь "что требуется сделать" - это глагол-название действия, который звучит наподобие "переварить"; потом ты думаешь "с чем это требуется сделать" - это объекты, над которыми действие производится, типа "еда", потом ты выбираешь тип этих объектов - "еда" (в данном случае совпадает, но может быть нам нужен только "фастфуд" или "здоровая пища"?), а только потом определяешь, что твоё действие в оставит после себя - "говно", или "обёртку", или "ничего", если у тебя 100% КПД пищеварения, способное переварить всё, включая обёртку. Было бы странно начинать описание своего действия с того, что тебе "нужен производитель говна", или "нужен производитель пустых обёрток", или "ничего не нужно, просто пустота", и только потом давать имя этому действию. Нет, соглашусь, что иногда тебе и правда необходим абстрактный "производитель говна", а не действие с объектами, но это специфичный случай.
>>1108831
>скобочек пугаешься
Они выглядят некрасиво и их труднее отличить от других видов скобок со слабым зрением и высоким PPI. На моём текущем мониторе я даже в очках пимпочки на "{}" не вижу, они выглядят как нечто среднее между "[]" и "()", поэтому с первого взгляда даже не понять, что там на самом деле. А "begin end" или отступы от края экрана видно сразу, даже без очков, даже при мелком шрифте с высоким PPI...
>Люди пытались сделать естественный язык, но всегда получалась какая-то жопа
Не знаю, о какой "жопе" ты говоришь, но подумай сам, что лучше:
>for Child in GetChildren do Child.Work; // Pascal
>for child in get_children(): child.work() # GDScript
>foreach (Node child in GetChildren()) { child.Work(); } // C#
>for (Node child: getChildren()) { child->work() } // C++
И т.д. Абсолютное превосходство Pascal очевидно - тебе не нужны ни "{}", ни "()", ни даже ":", и весь твой код читается как проза: "для каждого ребёнка из полученного списка детей приказать ребёнку сделать работу". Твой взгляд не "спотыкается" об избыточные спецсимволы и указатели типов. Просто и изящно.
>потому что парсер удобнее писать
Тогда почему не FORTH? Минимальная FORTH-машина умещается в 340 байт и это полноценный язык, способный с легкостью конкурировать с C/C++ по производительности и работать на любом железе без операционной системы. Его можно даже в древние чипы BIOS засунуть, целиком... ещё когда в них не запихивали аж десятки мегабайт под обновления. А если писать ОС, то FORTH-машина умещается в загрузочный сектор дискеты (512 байт) - и это всё, что тебе нужно, дальше только читать код ОС.
>Ты думаешь эти люди смогут написать ядро шарпов?
Пффф, обыкновенные "носочки программиста". Ты что, не надеваешь такие, когда код пишешь? А вдруг простудишься? У программиста комп мощный, сосёт как пылесос - и ветер прям по ногам дует. Тут без носочков не попрограммируешь никак. В полосочку или однотонные - это уже дело вкуса, не придирайся. Борода и длинные волосы - это тоже для теплоизоляции и терморегуляции головы. А в юбке мошонка не сдавливается и не перегревается... Не понимаю, почему у нас какие-то предрассудки против юбок - вот по какой такой причине бабам с пустой промежностью можно юбку, а мужики вынуждены сдавливать себе всё самое нежное и чувствительное, что природа специально вынесла наружу для охлаждения? У тебя никогда яичко не перекручивалось из-за того, что ногой в грубых штанах неудачно двинул? Это супер-больно. А в одних трусах не попрограммируешь по той же причине, по которой нельзя программировать без носков. Нормальные, здоровые, счастливые программисты в своей классической рабочей одежде.
И вот такие зашоренные шовинисты критикуют GDScript? То им отступы мешают, то носочки...
>Тип данных может поменяться вместе с задачей
Ну если ты ньюфажа ты буквально перебираешь возможности языка. А если ты PRO то ты обычно думаешь сигнатурами методов.
Пик, база баз, ты не должен знать кишки. Тебе нужна только сигнатура.
Единственное это когда вообще не знаешь что делать и делаешь "налету" (прототипируешь). И тогда тебе правда нужны только действие и именно поэтому js идеально подходит для быстрого прототипирования (помню школота даже не поняла о чем я говорил, опять трансформатор жужжит).
>Они выглядят некрасиво и их труднее отличить
Тебе не нужно их отличать, они нужны для форматирования - одна кнопка и все отступы раставлены.
В общем, синдром утёнка - развивайся.
>Не знаю, о какой "жопе" ты говоришь,
Смотри COBOL и прочую чепуху 1960-2000х (а может раньше)
Все что выжило - это продукт проб и ошибок - лучшее из худших.
>И вот такие зашоренные шовинисты критикуют GDScript? То им отступы мешают, то носочки...
Ни разу не говорил про синтаксис, я за всю жизнь на чем только не писал. В срачнике я даже сказал что синтаксис неплох, плоха техническая реализация - сдвиг миллионного массива в 45 раз дешевле чем оптимизированный свап-алгоритм на гдскрипте - это безумие (ты видел цифры на шарпе, какая должна быть разница). И самое страшное им насрать
За жизнь у вас будет только 1-2 языка в которых вы сможете сверх-шустро ориентироваться и комфортно писать. Поэтому стоит определиться.
При этом в инфраструктуре языка есть все нужные оптимизации, даже unsafe на арифметике указателей.
PS Кто не понял
>пик1
Проход по массиву без проверки выхода за границу на каждой итерации.
Но только надо проверять, потому что JIT делает больше чем вы думаете.
> У тебя некорректный пример.
Для иллюстрации неоднозначности натурального языка - вполне корректный. А у тебя наоборот иллюстрация корректных фраз.
> X ЯВЛЯЕТСЯ Y
Где "является" - это усовремененная форма словосочетания "являет ся", "являет себя", след древних словесных форм, существовавших в старорусском. И в этом смысле любое -ся определяет предыдущего. Вася являет себя как геймдевыч, но не геймдевыч являет себя как Вася.
Далее ты добавляешь еще больше частиц, всё дальше уходя от сути.
А суть в том, что если бытие определяет ся, то бытие первично, иначе сознание определяет ся. Эта фраза уже легко переводится на логичные языки программирования.
Но учтите, что если вы возьмете тройку и моно под веб/ios - моно интерпретатор будет убивать вашу игру на постоянной основе из-за вагона багов внутри самого моно, надо брать только четверку и фиксироваться на конкретных платформах, либо принять волевое решение и переехать на C++ godot 4, отличная работа в вебе, санитайзеры закроют проблемы по памяти, кодогенерация позволяет не писать руками тело bind_methods или описывать геттеры сеттеры а так же - ей же закрывается вопрос о рефлексии (clangast+своя реализация appdomain с хранилищем типов как в c#/il2cpp), std 20 модули для избавления от инклудов и шарпофикации импорта зависимостей, но - нужна нормальная тачка под компиляцию и сила воли это схавать
Не надо брать тройку, у него сломанный шедоумап и вагон багов с более низкой относительно четверки производительностью
>у него сломанный шедоумап
В чем это проявляется?
>вагон багов
Там наистабильнейшая 3.6.3 maintenance. Супротив 4-ки в которой еще не все даже существовавшее допортировали (хотя, конечно, добавили много новых фич)
>более низкой производительностью
Бенчмарки покаж. У меня другой опыт. Что на твг с десктопной на вулкане, что в вебе.
>В чем это проявляется?
В дырявых тенях на лоуполи геометрии у динамических обьедков, впринципе реализация directional освещения дерьмовая в тройке, в четверке щас нормально все и с тенями и с перфомансом
>Там наистабильнейшая 3.6.3 maintenance
Не на многопотоке, в отличие от четверки, где потоки в вебе могут сильно зарешать по перфомансу, в тройке апи многопоточное только в справке, а по факту - любые freeable операции делай только в главном иначе движок крякнет
>Бенчмарки покаж. У меня другой опыт. Что на твг с десктопной на вулкане, что в вебе.
Тогда придется игру показывать, а мне сильно неохота. Работаю щас с 4.7.2, буст по перфомансу куда заметнее против тройки, хошь верь хошь нет, но у меня основа глес, вулкан я не трогал так как веб целевая платформа
>еще не все даже существовавшее допортировали (хотя, конечно, добавили много новых фич)
А каких тебе фичей из тройки не хватает собственно? Просто интересно, не увидел ни одной такой которой в 4 не было бы против тройки.
Пойду потестирую потом, может что-то в новых версиях подкрутили. Но думаю размер билда все равно будет расти. На многопоток в вебе мне пофиг, там все равно дно устройства, максимум загрузку в фоне какую-то делаю.
Дыры в динамических объектах - ну хз опять же нишево. Проверь может у тебя баг при их создании какой-то, там легко напутать со всеми этими поверхностями, индексами. Может просто вывернулась нормаль наизнанку.
Не помню, периодически натыкаюсь на вопрос, собираюсь ответить что для этого же есть встроенный метод - а его не довезли. Да дело не в этом, многое заново переписали, поэтому нет доверия что там уже баги вылизали.
Ну размер билда да, немаленький, только васм плюсовый пакетик игровой логики у меня в оптимизированном состоянии весит почти 9мб, да плюс рантайм движка, где мне нечего резать, так что 15-20мб как минимум точно нарисуется. Но мне вес важен мало, игра может себе позволить забить хуй на вес клиента в разумных пределах, так как я сильно выделяюсь на фоне прочих браузерок
>На многопоток в вебе мне пофиг, там все равно дно устройства
Как раз на донных устройствах и надо выскребать всё из ядер, все что есть. Щас какой говнопроц не возьми - везде есть 4 ядра как минимум, надо поглощать.
>Дыры в динамических объектах - ну хз опять же нишево. Проверь может у тебя баг при их создании какой-то, там легко напутать со всеми этими поверхностями, индексами. Может просто вывернулась нормаль наизнанку
Ну может быть, но помимо этого еще и тени стали гораздо лучше в 4 сами по себе, практически без урона по производительности.
>>умный дядя еще не понял что они не хотят ничего писать
Не ну кто-то хочет, но под призмой максимализма лезет в плюсы или си (который по сути почти ассемблер).
Из-за веба лезть в плюсы - великолепный план.
Так по факту. Хочешь выбить предельную производительность? Добро пожаловать в клуб gdextension-данжен мастеров.
Если под вебом подразумевают свой сайт (не я.игры), то я бы вообще не брал ни один движок.
Есть подозрение что там колоссальное число оберток (на любом движке).
>И самое страшное им насрать
А почему должно быть не насрать?
Мы говорим в контексте выбора альтернативы гдскрипту
-если есть потребность написать сложные алгоритмы/системы,
-или если ты не хочешь за базовые операции платить микросекундами (вместо наносекунд, то есть в 1000-10.000 раз больше)
-и если ты раньше не писал на плюсах (лаба1.cpp не считается).
Вопрос в том куда ты хочешь инвестировать свое временя. Не все понимают реальную сложность С++. А если ты не хочешь учиться и вообще вайбкодя, то просто уйди в свои нейронки и загон /ai, не ровняйся с теми кто хочет учиться, твое мнение не важно в рамках инвестиции времени и сил
>А почему должно быть не насрать?
Ну тут вопрос что ты выберешь - практичность или удобство? Возможно ты как и я выберешь практичность выше удобства, поэтому тебе и мне было бы не насрать. Но если ты выбираешь удобство в ущерб практичности, у тебя даже цели не будет что-то изменить.
Вся надежда что годот обрастет сообществом и те продавят "практичность" (я кидал ссылки, такие потуги уже есть, люди пытаются, людям это важно. ).
>>1108390 →
>>1108391 →
Я бы не отказался от GDLang поставляющегося с отдельным компилятором и компилирующиегося в консольные утилиты, а к нему отдельно подключается редактор Godot и использует GDLang наравне с GDScript.
Я бы хотел, чтобы отличия от скрипта были минимальны, только в заголовочной части было бы import Godot. И был бы компилируемый язык с охуенным годотовым синтаксисом, который я обожаю. После гдскрипта питон кажется омерзительной поебенью. Всё что я вижу в нём похожего это только блоки отступами, в остальном ничего похожего. И при этом питон всё равно не компилируемый.
Самый ближайший к небесному годоязыку из существующих - это пока что Zig, посмотрите на пикчу от нашего железного друга. Это же буквально то, о чём мы мечтали долгими зимними ночами.
Тру стори. У меня в пайплайне даже используется несколько раз в год. Скрипт, который меняет иконку игры в релиз темплейте.
>Godot --no-window -s scripts/HelloCli.gd
Несколько лет знаю об этой фиче, но как-то не нашёл применения для неё. Если мне нужно что-то "автоматизировать", я либо .bat-скрипт напишу, либо AutoIt3-скрипт... Я могу понять, почему Python и похожие на него языки имеют "интерактивный режим" в консольке - ведь это "языки математиков", а математикам часто нужно какие-то матановские формулы считать, вот они этим и занимаются. А нам зачем? У нас матана никакого нет, то есть есть, но он такой, что в эксель-табличке проще посчитать, чем писать какой-то мудрёный скрипт...
>>1109054
>меняет иконку игры в релиз темплейте
Разве Godot не меняет иконку сам? Для Godot 3 нужно rcedit.exe скачать, а в Godot 4 вроде из коробки работает.
>>1109066
>генератор материалов по палитре
По-моему, это самый плохой подход к материалам. Ты должен делать наоборот: уменьшать число материалов, соединяя текстуры в атласы и/или используя текстуру-палитру с UV координатами, или какие-то ухищрения с Vertex Color делать. Как минимум если таргетишь OpenGL/мобилки; с Vulkan/DX вроде это уже не так важно. Также лучше использовать "instance uniforms" вместо создания отдельной копии материала для модификации каких-то параметров шейдера - это будет эффективнее, но, вроде, поддерживается только в Forward+.
А rcedit глючный. Дак в этом и фишка, зачем лишняя прога, когда есть скрипт на гдскрипте.
>Вася являет себя как геймдевыч, но не геймдевыч являет себя как Вася.
Правильно. Поэтому в нормальных языках ты пишешь так:
>class Vasya extends Gamedevich:
>_ func eat_and_shit(what: Food) -> Shit: ...
А в дебильных языках, описывающих всё через жопу - так:
>Gamedevich class public protected unsafe private anus-derned rejected heart-breaked Vasya {
>Shit public unsafe private anus-produced prolapsed method eat_and_shit(Food: what_the_fuck) { ... } }
По-моему, очевидно, что "литературный" подход для восприятия человеком лучше вывернутого наизнанку.
А уж что там приходится создателям компилятора/интерпретатора делать, чтоб это всё развернуть - нас не касается.
>>1108878
>синдром утёнка
>>1108880
>За жизнь у вас будет только 1-2 языка
Всё так: ты выучил этот C# и больше ничего не понимаешь, потому что тебя научили такому >>1108881 безобразию.
>>1108985
>что ты выберешь - практичность или удобство?
Значения русских слов забыл? http://ru.wiktionary.org/wiki/практичный
>выгодный, удобный по каким-либо своим свойствам, хорошо подходящий для решения каких-либо задач ценой сравнительно небольших затрат
То есть GDScript практичен, потому что удобен, а удобен потому, что позволяет решать многие задачи ценой сравнительно небольших затрат. А C# непрактичен, потому что заставляет перепрыгнуть через кучу различных совершенно не нужных ограничений ради абстрактной "скорости", которую и в GDScript тоже можно в перспективе завести, если поднапрячься (и вроде бы уже есть транспиляторы GDScript -> C/C++, так что можно не напрягаться), но в большинстве ситуаций современный компьютер решает задачи мгновенно даже на GDScript. Единственная ситуация, требующая более быстрый язык - это когда тебе позарез нужно тысячи единиц чего-то каждый кадр обрабатывать, но подобное в видеоиграх встречается относительно редко и чаще всего - уже полностью решено в ядре движка.
>нет доверия что там уже баги вылизали
Godot 4 начали делать более 4 лет назад, и уже более 3 лет он считается stable - на нём куча проектов и в разработке, и в релизе, в том числе в Steam. Если какие-то баги и остались, то это что-то очень специфическое, а значит, не критичное. У тебя какая-то фобия увеличения мажорной версии? На юнити и многих других закрытых движках владельцы движка крутят мажорную версию как и когда захотят, а с Godot ты даже сам можешь посмотреть исходники и решить для себя, много там критичных для тебя багов или нет...
>>1108925
>Супротив 4-ки в которой еще не все даже существовавшее допортировали
То, что есть в 3, но "не портировали" в 4, портировать уже не будут, потому что это не считается нужным для проектов на 4-ке. Лично мне вспоминается, что под конец 3-ки подвезли метод/ноду для "склеивания мешей", которая помогает решить вопрос с избыточным количеством дроуколлов в OpenGL. Но Godot 4 рассчитан на Vulkan/DX и дроуколлы экономит автоматически, поэтому возиться со склейкой мешей не нужно, если ты не пытаешься делать в режиме Compatibility. Но даже если тебе всё-таки нужна эта склейка мешей на 4-ке, ты можешь её легко реализовать даже на GDScript, потому что это тривиальная задача. В 3-ку эту фичу запилили только ради школоло-художников, которые не способны по массиву пройтись своими руками... А вообще, есть же Blender...
...вот эта нода: https://docs.godotengine.org/en/3.6/classes/class_mergegroup.html
Если есть что-то ещё, то мотивация там та же самая - в Forward+ не нужно, а Compatibility никто не обещал держать на уровне тройки.
>Это же буквально то, о чём мы мечтали долгими зимними ночами.
Ехал pub через pub, сунул pub свой var в fn, а там const .{.ц=ап} pub за var...
>>1109008
>Odin
Скочал, а потом посмотрел как оно в Godot вкручивается и думаю удолить.
> Поэтому в нормальных языках ты пишешь так:
Шаришь, бро! Вот за это гдскрипт и любим.
>>1109079
> Ехал pub через pub, сунул pub свой var в fn, а там const .{.ц=ап} pub за var...
Ну хотя бы паб разреши?
>>1109075
> >class Vasya extends Gamedevich:
> >_ pub func eat_and_shit(what: Food) -> Shit: ...
А хотя, я уже после того как пост отправил, нашёл гдскрипт-вэй решение. Все "паб" - это интерфейс, в его классическом смысле, а не в том, которым нагадили в современных языках. То есть, нам в листинге скрипта вообще не нужно никакие приставки методам прикручивать, все они по умолчанию должны быть приватными. А вот чтобы вынести то или иное наружу, его нужно объявить в интерфейсе (в заголовке). Примерно так:
> class Vasya extends Gamedevich:
> public:
> _ func eat_and_shit(what: Food) -> Shit
> _ var foo : String : get # объявили get-only свойство
>
> func eat_and_shit(what: Food) -> Shit:
> _ pass
>
> var foo : String = "" :
> _ get: pass
> _ set(v): pass
Несложно заметить, что выписанные в паблик определения полностью дублируют их определения в реализации ниже, поэтому будет логично вписывать публичные члены в интерфейсе/паблике/заголовке, затем дважды щелкать и редактор будет создавать копию внизу. Самая макотка такого подхода проявила бы себя в определении пропертей, в паблик засовываем только гет, а внутри прописываем и сет тоже.
>Ну хотя бы паб разреши?
На чужой лобок (pubis) не разливай фондюк (fondue).
>>1109083
Опять ты какой-то велосипед с квадратными колёсами изобретаешь...
Начнём с вопроса: зачем нужны эти public/private теги? Чтобы компилятор/IDE могла бы как-то сообщить другому программисту или нам-из-будущего, что вот эту вот фичу дёргать можно, а вот эту фичу дёргать нельзя/лучше не стоит. Ключевое слово - сообщить, так как запретить мы ему ничего не можем: желающий может просто залезть в исходники и переделать любой private в public, если ему это очень надо. Это просто такая условность, как запись зАбОрЧиКоМ или з_м_е_й_к_о_й, она нужна только для визуального ориентирования программиста на местности.
Далее, что нам важнее - public или private? Если мы пишем какой-то код, мы хотим его откуда-то вызывать, не так ли? Потому что невызываемый код нам нафиг не нужен. И даже если нам нужна только 1 точка доступа, мы можем захотеть получить доступ к чему-то кроме этого, например, в качестве теста или временного костыля-заплатки (впрочем, нет ничего более постоянного, чем временное). Поэтому очевидно, что начинать нужно с public, а как-то помечать только private.
Значит, нужен какой-то визуальный маркер для private, а public подразумевается по умолчанию. Почему бы... не начинать название со знака подчёркивания? Вот у нас есть eat(), который мы вызываем снаружи, а может быть _puke(), который вызывается изнутри автоматически, если нас накормили слишком сильно. Видишь, как просто? Всего один символ - и мы уже с первого же взгляда видим, что этот метод должен вызываться только изнутри класса - это его кишки.
Теперь мы можем настроить IDE так, чтобы она не выводила в качестве подсказки после "." поля, начинающиеся с "_", или загоняла их куда-нибудь подальше в конец списка. Помним о том, что мы не можем никому ЗАПРЕТИТЬ обращение, т.к. всегда можно поменять исходный код, и также помним, что иногда мы всё-таки хотим залезть в чьи-то кишки снаружи. Поэтому если кто-то и написал что-то вроде "person._puke()" - пускай оно выполняется, не проблема. Но главное - мы сразу видим, что этот код - костыль/заплатка, т.к. обращается к чужим кишкам - "_" в имени, и поэтому в будущем этот код нужно будет как-то переделать (отрефакторить программу).
И ты можешь не верить, но в Godot/GDScript это уже давно так принято и многими используется.
Да, действительно, так получается намного лучше. У меня буквально глаза открылись. Километры кода с кучей модификаторов типа private public protected sealed abstract были ошибкой. Нужно было делать всё публичным и просто ставить спецсимволы. Жаль что Хуан пошёл на поводу у этих, зашоренных, и ввёл @abstract - это буквально шаг назад к вот этим языкам!
Если на вкладке "Import" или в меню импорта модели нет такой кнопки, то нет.
Если нужно конвертировать очень много моделей сразу, можно написать скрипт:
https://docs.godotengine.org/en/stable/tutorials/3d/procedural_geometry/index.html
Можно даже свой импортер моделей сделать, если тебе это прям часто нужно:
https://docs.godotengine.org/en/stable/classes/class_editorimportplugin.html
Если модель одна или от силы десяток, то почему не сделаешь вручную в Blender?
Как-то вяло троллишь, старайся лучше.
>Километры кода с кучей модификаторов были ошибкой
Не путай айти энтерпрайз с их тысячами классов для тривиальной операции и суровый инди-соло-хобби-геймдев - бессмысленный и беспощадный, где запах свободы состоит из месячной немытости и смешивается с code smells.
>ввёл @abstract - это буквально шаг назад
Abstract нужен для наследования от общего предка-пустышки, он полезен в качестве предупреждения ошибок.
Задача: нужно 5 классов с одной функцией, у каждого своя реализация. Создаём класс-заглушку с чем-то типа:
>func do_something_generic(...args) -> GenericResult: return null
И в каждом потомке делаем то же самое, но вместо null возвращаем что-то полезное. Ноооо... спустя полгода решили добавить 6-й класс и ЗАБЫЛИ запилить эту функцию. Наш код валиден, проект запускается и никаких ошибок не выводит. Мы тестируем (если не забыли тщательно протестировать), и где-то через полчаса мы ВНЕЗАПНО натыкаемся на "whatever is null", из-за чего весь проект ломается. Приходится разбираться, что это и где нужно доделывать. Мы могли бы добавить самим-себе-из-будущего вот такое простое предупреждение:
>func do_something_generic(...args) -> GenericResult: assert(false, "implement this first"); return null
Но оно не вызовется, пока код не дойдёт до этой строчки, т.е. опять же тратим полчаса на тест. А вот если мы сообщаем компилятору заранее "это абстрактная функция, если ты её видишь - сообщи мне, что я забыл сделать реализацию этой функции в дочернем классе" - он предупредит нас сразу же, как только мы нажмём F5, и мы не будем тратить кучу времени на тестирование того, что в принципе не способно сработать по причине отсутствия.
Это не касается public/private, потому что обращение к private извне само по себе не влечёт к немедленным ошибкам. Конечно, код запутывается, превращается в "спагетти", копится "технический долг", но в общем и целом такой вызов может решать какую-то сиюминутную проблему (для хотфикса релизнутой с багом игры в ночь после релиза, например), поэтому этого следует избегать в нормальном коде, но ради "хорошей практики" не стоит засорять синтаксис языка, предназначенного для быстрого прототипирования игровых механик и склеивания различных API друг с другом.
В каком месте?.. Прости, я устал, поэтому невнятно пишу.
>может решать какую-то сиюминутную проблему ... поэтому этого следует избегать
Я тут как-то отвлёкся и собрал всё в кучу, лол.
Так... попробую так:
- маркер "private" нужен только программистам, а не компьютеру/компилятору;
- обращение к приватным кишкам приводит к запутыванию кода, а не к багам;
- запутанный код сложнее поддерживать, в т.ч. сложнее исправлять ошибки;
- но иногда такой хак может помочь быстро исправить критическую ошибку;
- поэтому не нужно запрещать хак, а маркер достаточен маленький ("_");
- "abstract" к этому не относится, т.к. предупреждает реальный баг.
Так понятнее?
Но это же скриптовый язык... И всего лишь в 45 раз медленнее чем нескриптовый. Даже не на два порядка. Зачем ждать от него скорости?
>И всего лишь в 45 раз медленнее чем нескриптовый. Даже не на два порядка.
Годотчую. Та же всемирно популярная Lua, кажется, в 150 раз медленнее C...
На реддите пишут, что простота не обязательно должна упираться в отсутствие возможностей. Поэтому там просят модификатор @private, ну, я бы согласился и на модификатор, так и быть. Подчёркивания в начале имён мне лично не нравятся.
C# с версии 10 можно юзать как скрипты (в том числе юникс shebang #! )
https://learn.microsoft.com/en-us/dotnet/csharp/fundamentals/tutorials/file-based-programs
> потому что тебя научили такому >>1108881 (You) безобразию.
Ансейв в расте - правильно и смелое решение, ансейвы в шарпах безобразие и ужасно. Какие же вы ведомые дебилы.
>>что ты выберешь - практичность или удобство?
>Значения русских слов забыл?
Если бы ты был программистом то знал что разработка языков это постоянная дилемма между удобством и эффективностью. Поэтому синтаксис часто неудобный там, где важна практичность.
То скобочки пугают, то модификаторы доступа. Ты точно разработчик?
Гдсрыге нет модификаторов доступа, потому что нет модулей, а не потому что гдскрипт такой прекрасный.
А модулей и неймспейсов нет потому что скрипт подключается как ресурс, в общем тянешь за одно место вылезает другое. При этом байткод настолько ужасен, что сдвиг миллионного массива в 45 раз быстрее свап-оптимизации (это без преувеличение безумие).
PS жопоскрипты и питоны критикуют за протекающую абстракцию и протекающую инкапсуляцию, а художники радуются этому в своем гдскрыге, ппц аборегены, с кем я тут сижу.
>Не путай айти энтерпрайз с их тысячами
Тысяча скриптов/классов для римворлд/факторио релиза выглядит как норм. Люди кроме демок ничего тут не делали, им чужды неймспейсы и модификаторы доступа.
>сдвиг миллионного массива в 45 раз быстрее свап-оптимизации
Можешь напомнить для тех кто уже потерял нить срача что это вообще за тест был и где смотреть код?
Где-то тут смотри SWAP тесты.
>>1106507 →
>>1106555 →
Чушь. Просто диды кодинга, писавшие первые компиляторы в далёких 60-70х не знали ещё тех подходов и оптимизаций, к которым пришли отцы 90х и 2000х. А те в свою очередь ещё не знали какие эффективные парсеры сделают сынки с внучками в 2010х.
Нахуя мне неудобства в написании кода, если компилятор сам выводит типы? Нахуя мне писать a := 0 если компилятор и из a = 0 выведет тип?
Нахуя мне писать скобки вокруг условия после if, если компилятор всё равно будет ожидать символ : который ознаменует конец условия и переход к подблоку?
Нахуя писать ; в конце строк, если компилятор и так знает, где концы строк?
И так в куче аспектов.
Языки буквально следуют моде, а не эффективности, про которую ты тут с умным видом талдычишь. Эффективность сегодня совсем на другом уровне. И самое интересное, большинство этих твоих настоящих программистов в упор не видят проблему в том что я тут написал.
Я когда-то видел в какой-то статье некое эмпирическое правило, как заценить что язык эффективен и его компилятор/транслятор/хуятор грамотно написан: Нужно написать программу в одну строку. Если язык нигде не потребует перехода на новую строку - он годный.
Вот и думойте.
Это как измерять качество программиста по количеству коммитов. Можешь не думоть, не твое.
>писать ; в конце строк, если компилятор и так знает, где концы строк?
А нафига ты точку в конце приложения ставишь?
>компилятор и так знает
Он нефига не знает, все его знания стоят времени компиляции.
Я помню в котлине ловили какие-то сложные баги с этой херней и до конца не решили их (я уверен из-за частичного решение там запихнули с десяток проходов).
>И самое интересное, большинство этих твоих настоящих программистов в упор не видят проблему в том что я тут написал.
Какие? Ты просто тот чело с аналогиями и графоманией, я тебя часто скипаю.
Ты из-за синдрома утёнка (вкусовщины) пытаешься раздуть проблемы синтаксиса. Это выглядит крайне не профессионально, как-будто у тебя в мозге проело паскалем или питоном. Как можно человеку что-то объяснить если он возмущается на модификаторы доступа? Это как возмущаться что у машины руль с лева, а не по середине. Наверное модификаторы доступа для чего-то нужны, да?
Если такой умный, собери свой парсер, да засунь в LLVM, сейчас каждый второй может создать свой язык, со своей шизой (этой глючной экзотики сейчас как грязи).
Не один язык до сих пор не решает проблему сложности, ООП с интерфейсами немного облегчает, но абстракции как текли - так и текут.
>Нахуя мне писать a := 0 если компилятор и из a = 0 выведет тип?
Это защищает от ошибки вида a = x; aa += 1; print(a)
В этом случае в некоторых языках заводится новая переменная, которая потом по тихому нигде не используется
Запись a := 0 это сокращение от a : autotype = 0, то есть это не только присвоение, но и объявление переменной.
>Нахуя мне писать скобки вокруг условия после if, если компилятор всё равно будет ожидать символ : который ознаменует конец условия и переход к подблоку?
Не знаю о чем именно речь, но там бывает много нюансов - вложенные if, какие-нибудь присваивания
>Нахуя писать ; в конце строк, если компилятор и так знает, где концы строк?
Потому что конец строк - довольно ненадежный ломающийся маркер. Никогда не копипастил код с сайта или из чатбота, или случайно не нажимал enter кружкой?
> Никогда не копипастил код с сайта или из чатбота, или случайно не нажимал enter кружкой?
>>1109181
> :
Как же достала эта хрень в каждом чихе. Серьезно, точка с запятой не так бесит как это, хз почему.
>Подчёркивания в начале имён мне лично не нравятся.
Эстетически? А мне вот кривые скобки не нравятся эстетически...
Ну, ладно, допустим, нужно твёрдо и чётко обозначить private. Почему бы не сделать это сразу для целого блока кода? Вот так:
>class MyObject extends Object:
>_ var public1: int
>_ var public2: float
>_ func create() -> MyObject: ...
>_ func do_at_public(): pass
>@private_part
>_ var private1: string
>_ var private2: Array
>_ func _ready(): pass
>_ func _process(): pass
>_ func do_in_private(): pass
>_ func _on_timer_timeout(): pass
>class MyOtherObject: ... # начался другой объект - приватная часть предыдущего завершена и закрыта, дальше снова публичное
И так далее. По-моему, это было бы проще и логичнее, и удовлетворило бы всех сразу без лишней писанины и переусложнения.
Если честно, я бы ещё блоки var и type вернул из Pascal в GDScript. Устал уже писать каждый раз var, const, enum и всё такое...
Алсо было бы полезно объединить все @export и @onready в один большой блок, чтоб не писать на каждой строке заново...
Да и, если честно, слово "func" совсем не обязательно каждый раз писать, если по заголовку понятно, что это функция...
>>1109126
>в расте
Я не знаю, что у вас там в этом вашем растишке, я его даже не пробовал. Увидел уродливый синтаксис и сразу пропустил.
>>1109127
>дилемма между удобством и эффективностью
Если ты пробовал создать свой язык программирования с нуля (как делал я), то знал бы, что удобство языка можно повышать без компроментации эффективности результирующего кода. Да, время компиляции может возрасти. Да, могут быть неочевидные конструкции, которые компилятор может сделать не так, как ожидает программист. Но результирующий машинный код никак не должен зависеть от того, как выглядит исходный код языка со стороны программиста. И язык не должен заставлять программиста задумываться о том, как лежат байты в памяти и какие операции выполняет процессор, пока он не пытается создать прошивку микроконтроллера с 16 КБ памяти на всё про всё и выполнить код в реальном времени как в какой-нибудь космической ракете. Большинство "неудобств" в существующих языках происходят не от "эффективности", а из-за необходимости поддерживать старый, давным-давно написанный код, т.е. чтобы твой "Компилятор v69.0" мог понять код, написанный во времена "Компилятор v0.01". Другими словами, кто-то когда-то сделал не слишком правильное решение, другие программисты были вынуждены применять это решение на практике, написав тонны кода, а когда нашли более правильное решение, оказалось, что нельзя просто взять и кинуть миллионы строк кода, полагающиеся на старое неправильное решение. Так языки и становятся уродливыми и неудобными. Ну, а большинство современных поделок зумеров - это буквально каргокульт, подобно создателям "убийцы ГТА" и т.п. - они способны написать рабочий код, но не понимают дизайнерской работы, которая стояла за созданием старых вещей, лишь копируя внешний вид.
Вот, кстати, наглядный пример карго-культиста в его естественном состоянии: >>1109128
>что сдвиг миллионного массива в 45 раз быстрее свап-оптимизации (это без преувеличение безумие).
Чувак в набедренной повязке на голое тело увидел "свап-оптимизации" в какой-нибудь книжке, и думает, что это какая-то священная техника, которая должна ускорять любой код быстрее скорости света, но его иллюзии разбиваются о суровую реальность, в которой реальная работа, требуемая для вызова функции интерпретатором в дебаг-режиме требует от компьютера больше, чем уже давно оптимизированный алгоритм, работающий в виде машинного кода на том же компьютере. То есть он буквально собрал "самолёт" из сухой травы и собранных палочек, танцует вокруг него и не понимает, почему с неба не падают большие ящики с провиантом.
>>1109129
>Тысяча скриптов/классов для римворлд/факторио релиза выглядит как норм.
Это совсем другие "тысячи классов": https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition
>Люди кроме демок ничего тут не делали, им чужды неймспейсы и модификаторы доступа.
Делали. Нет, не чужды, но и не нужны (не обязательны - жить можно и без них).
>>1109150
Можешь не изучать, там школьник обмазался всеми проверками как по учебнику и удивляется, что они тормозят.
>>1109181
>Нужно написать программу в одну строку. Если язык нигде не потребует перехода на новую строку - он годный.
Ну, насколько мне известно, GDScript позволяет писать весь код в одну строку. Достаточно добавить ";" где нужно.
>>1109193
>А нафига ты точку в конце приложения ставишь?
Потому что он пишет несколько предложений на одной строке, и, кроме того, переносы строк (символы перехода на новую строку) в браузере для человеческого взгляда не видны явно, потому даже с переносами строк без точки или точки с запятой нелегко понять, где кончается одно предложение и начинается другое. С кодом всё иначе: код ты пишешь и читаешь через IDE, в которой переносы строк чётко обозначаются, а для компилятора/интерпретатора символы переноса строк видны так же, как и любые другие символы.
>Он нефига не знает, все его знания стоят времени компиляции.
Ты противоречишь сам себе в одном предложении... И что с того, что "стоят времени компиляции"? Компилируешь код ты один раз, а пользоваться результатом компиляции твои пользователи будут многие годы. Кроме того, медленные компиляторы - это не проблема дизайна языка, это проблема оптимизации компилятора. Если у тебя компилятор на JavaScript написан и выполняется через Electron, не нужно жаловаться, что он медленный, и тем более не нужно ломать удобство синтаксиса языка ради ускорения компиляции.
>Какие? Ты просто тот чело с аналогиями и графоманией, я тебя часто скипаю.
Ты серьёзно нас путаешь? Лол. Или я тебя чем-то так обидел, что ты меня теперь в каждом анонимусе здесь видишь? Расслабься, я не пытаюсь тебя обидеть или что-то вроде. Я только люблю спорить на всякие темы... это своего рода форумная игра.
>Это выглядит крайне не профессионально
Я никогда не называл себя профессионалом, и мы не на профессиональном форуме сидим, а на форуме хоббистов-самоучек.
>возмущаться что у машины руль с лева, а не по середине
Ты же в курсе, что есть машины с рулём по центру?.. А теперь представь, что у тебя в твоей личной машине висит книга по ПДД и специальная механическая рука бьёт тебя по лицу каждый раз, когда ты не зачитываешь вслух цитату из этой книги перед тем, как совершить описанное действие. Например, захотел повернуть направо? Сначала полистай книгу, прочитай вслух что-то наподобие "перед поворотом убедитесь, что дорога свободна, нет запретительных сигналов, и у вас включён поворотный сигнал", и только после чтения этой мантры ты можешь начать поворачивать, а если забудешь прочитать мантру - механическая рука разобьёт тебе лицо. И огромная толпа автомобилистов с разбитыми лицами защищает этот механизм, объясняя тебе:
>Как можно человеку что-то объяснить если он возмущается на механизм битья по лицу? Это как возмущаться что жидкое ешь ложкой, а твёрдое ешь вилкой. Наверное механизм битья по лицу для чего-то нужен, да?
>Если такой умный, собери свой парсер
Я уже делал несколько разных парсеров своих личных языков, мне пока достаточно.
>но абстракции как текли - так и текут
Абстракции текут из-за того, что ООП нужно учиться пользоваться. Язык не может решить твою проблему вместо тебя.
>>1109233
>Никогда не копипастил код с сайта или из чатбота
Аргумент уровня "никогда не пытался чистить уши кухонным ножом?" - сам себя поранил, а жалуешься на производителей ножей...
>>1109249
Лол, давайте ещё начнём жаловаться на то, что нужно ПРОБЕЛ нажимать.
>Почему нас заставляют нажимать ПРОБЕЛ? Можно ведь писать не просто в одну строчку, но и без пробелов! Ведь пробел после точки с запятой не нужен. И после "=", "+" и т.д. Но язык всё равно устроен так, что иногда приходится жать пробел. Это так плохо! Ненавижу пробелы! Хочу писать "a in b" и "a is b" без пробелов, чтобы компилятор сам догадывался, что значит "ainb" и "aisb", а то я на нажатие пробела драгоценные наносекунды трачу, которые мог потратить на просмотр порнушки или, например, мастурбацию.
>Если ты пробовал создать свой язык программирования с нуля (как делал я),
Не покажешь, да?
>И язык не должен заставлять программиста задумываться о том, как лежат байты в памяти и какие операции выполняет процессор
Что за бред, инты, чары, лонги, массив - это буквально указание того как лежат байты в памяти и что с ними можно сделать.
>>1109257
>Чувак в набедренной повязке на голое
Человек-аналогия, я не сразу тебя узнал.
Качество байткода гдскрипта напрямую влияет на производительность твоей игры, нафига ты маняврируешь? Если не поднимать проблему, то её никто не будет решать. Никто не говорит менять твой синтаксис, там качество интерпретатора хуже чем у питонов/руби, в этом проблема.
>Можешь не изучать, там школьник обмазался всеми проверками как по учебнику и удивляется, что они тормозят.
Школьник использовал больше if'ов чем положено, какая беспечность.
Скромнее надо быть, проверять аргументы хотя бы через раз.
>в дебаг-режиме
Тут ты уже лукавишь, гдсрыг в релизе дает чуть более чем нефига, это было проверено там же.
Подчеркивание у тебя в имени переменной, ты его всегда видишь. Это сразу сигнал - это что-то внутреннее, деталь реализации, это надо трогать только если точно знаешь, зачем.
>>1109269
Репорт.
>Не покажешь, да?
А смысл показывать тут, если это не касается Godot? Создание своего ЯП даже геймдева не касается.
>инты, чары, лонги, массив - это буквально указание того как лежат байты в памяти и что с ними можно сделать.
Тебе ещё многое предстоит узнать...
>Качество байткода гдскрипта напрямую влияет на производительность твоей игры
А у тебя и игры нет, чего ты волнуешься-то? Я вообще вкатился в Godot много лет назад, рассчитывая "по-быстрому накидать прототипчик, а когда будет играбельно - переделать на самодельный велосипед или более крутые библиотеки", но так за эти много лет и не пришёл ни к чему достаточно интересному концептуально, чтобы это имело смысл разрабатывать лично мне, а не играть в уже готовое (да я и в игры особо не играю). То есть я делаю прототип, вижу - скучно, бросаю его и думаю над тем, чем бы ещё заняться. О каком "качестве байткода" может вообще идти речь, когда упереться в нехватку производительности нужно постараться?.. Меня вообще из "тяжёлых" игр интересовала разве что Terraria, но в неё я давно наигрался и, попробовав её клоны и свои прототипы, понял, что это не моё. А всё остальное может и на GDScript потерпеть, ведь главное узкое горлышко - GPU.
>>1109272
База. Я вот привык почти всё начинать с подчёркивания, если мне это не нужно где-то снаружи вот прям сейчас.
> Подчеркивание у тебя в имени переменной, ты его всегда видишь.
Ладно-ладно. Стерпится-слюбится.
>Репорт.
Чего порвался то? От этого гдсрыг быстрее не станет.
Вахтерша протерпела два месяца, лол.
Все правильно тебя репортят. Хуйней страдаешь и тред дерейлишь на хуйню. Заменил движкосрач на языкосрач и типа хитрый дохуя.
>А у тебя и игры нет, чего ты волнуешься-то?
Ну, очевидно ты хочешь получить максимум.
У меня, кстати нет проблем с прокрастинацией как у вас, разработка это мое хобби (не важно что это игра или не игра, я все равно буду что-то писать, то есть я дропал прототипы по объективным причинам).
>Хуйней страдаешь и тред дерейлишь на хуйню.
Тебя поймал на лжи, от чего пердак порвался. Хватит прикрывать свои обиды тредом. Ты же умудрялся репортить даже в движкосраче, когда тебя возили лицом по некомпитентности.
Это не твой личный чатик, кому не нравится просто проигнорят.
Сейчас бы табулировать проблемы гдсрипта, которые подымаются везде.
PS
Забавно что начался учебный сезон, школьник опять сорвался и начал долбить в кнопку.
>тебя
Твой детектор настолько кривой, что дочитывать твое сообщение пойнта ноль. Я эту вкладку редко открываю, но каждый раз как захожу вижу тебя с абсолютно нерелейтед к треду хуйней. Так что тоже зарепорчу.
Вот в соседнем треде нет срача, там вообще уже ничего нет. Желаешь протухший тред? Как-будто кто-то будет спрашивать ньюфажные вопросы в эпоху ИИ.
>Никогда не копипастил код с сайта или из чатбота, или случайно не нажимал enter кружкой?
Сколько душу питона нейронкой - не было таких проблем.
мимо
Лол, это что ты натворил, чтобы тебя даже в движкосраче репортили.
>Лол, это что ты натворил, чтобы тебя даже в движкосраче репортили.
Он репортит за личную обиду, для этого не нужно ничего особенного - нужно быть технически неграмотным и иметь высокое ЧСВ.
Что за тред? Ну постят редко и пусть, как будто обязательно нужно доводить треды до бамплимита.
А вообще этот лампово и без срачей может жить
> базовой документации достаточно
Во первых это, во вторых ты проспал наступление эпохи ИИ. Твой личный ИИ-ассистент лучше любого учебника. Распишет и разжуёт тебе любую непонятную тему.
Ютуб плюс ии, больше нахуй не надо. У ии спраштвай не как сделать Х, а КАК ПРИНЯТО делать Х. Так и научишься
Для начала надо запилить низкоуровневый язык своей мечты, потом биндинги для него к годоту своей мечты. Только потом про игру помечтать можешь, но это не точно.
я к сожалению не могу в разговорный английский, а на русском ютюбе один скам, годных видео не нашел, так что начал читать документацию пока, вот про книжку мне как раз ии подсказал
> не могу в разговорный английский
Нейронка тебе переозвучит. Я тоже только англояз туториалы смотрю. Один раз смотрел испанское, и там была такая же хуня, как наши паштеты-фронтенды.
> вот про книжку мне как раз ии подсказал
Напиши ему, что тебе некогда читать книжку, пусть он тебе перескажет первую главу. ... ... Пусть он перескажет вторую главу... ... Сходил пописять. Выпил чаю. Пусть перескажет третью. И так далее.
У меня лежит в бэклоге, только пролистал её – на первый взгляд, пошаговые гайды по разработке пяти игр. Для новичков, наверное, пойдет (я сам - godot-мимокрок, обычно работаю на другом стеке).
Если что, на рутрекере есть пдф, может попробовать почитать его (и купить потом нормальную книги, потому что пиратство – это плохо)
>Chris Bradfield
Погуглил. Скачал какой-то PDF. Посмотрел - какой-то нейрослоп... Такое и даром не надо.
>хочу запилить рпг своей мечты
>или базовой документации достаточно?
Для освоения движка и примитивной аркады - достаточно официальной документации. Если программирование не знаешь пока, можешь ещё https://gdquest.itch.io/learn-godot-gdscript попробовать пройти - там на английском, но технический английский намного проще разговорного. Вся "сложность" английского в различных фразеологизмах, синонимах, сленге и т.п., что трудно найти в словарях и в буквальном переводе означает совсем не то, что тебе пытаются сказать. А "технический" английский - это более простые слова и обороты по чётким правилам, так что достаточно обычного англо-русского словаря и ты уже можешь читать любую документацию в оригинале.
Но для "РПГ мечты" (если ты буквально хочешь РПГ) твоим главным противником будет не движок, а сам жанр РПГ с его нюансами геймдизайна и создание визуального, литературного и прочего контента. Если бы ты хотел сделать простую аркаду/гиперказуалку, то там всё тривиально - есть "игрок" и есть "враги", игрок делает пыщ-пыщ и враги удаляются с экрана, добавляя +1 к счётчику очков, игрок чувствует удовольствие и ставит 5 звёзд из 5 в магазине. Жанр РПГ требует глубоко проработанный мир, сложные отношения правдоподобных персонажей, сюжетные и побочные задания со смыслом для игрока, "ролевую" прокачку героя, которая к тому же будет сбалансированной, чтобы игрок не был слишком сильным или слишком слабым, и просто море разнообразного контента, чтоб игрок не заскучал и не вырывался из погружения какой-то кривой фигнёй, которую ты случайно оставил в игре. Это всё не касается изучения движка, никакой ютуб-туториал тебя этому всему не научит достаточно подробно (там чаще всего чешут языком те, кто только и умеет что видосики снимать, чему они могут тебя научить?), да и в датасетах нейронок скорее всего недостаточно реально полезных данных, только общие советы и статьи журналистов.
Так что, чтобы не терять мотивацию, займись чем-то попроще, чем РПГ... или упрости свою "РПГ мечты": не 3D, а 2D; не с прокачкой в любом направлении, а фиксированные герои как в jRPG; не открытый мир, а набор локаций, соединённых в одну линейную цепочку с ответвлениями-тупиками; простой сюжет на классических тропах...
>>1109368
>>1109416
>ИИ, ЫЫ
Разве что спросить у нейронки конкретную статью в официальной документации, чтобы самостоятельно прочитать и вникнуть. Спрашивать у электронного лоботомита что-то напрямую — это просто выстрел себе в хуй, чесслово.
Это доказывает только то, что нейронка мыслит по английски (а то и по китайски) И твоё "сделай мне тайловую карту" переводит на "make me tilemap" что воспринимает как конкретное имя класса.
Это не значит, что нейронка плоха. Это значит, что ты - луддит.
>Это не значит, что нейронка плоха. Это значит, что ты - луддит.
Я даже представить не могу более нейронной фразы
>>1109530
Вы оба не правы. У нейронки недостаточно контекста задачи, именно поэтому никто уже не использует веб версии для вайбкодинга, а тупо загоняют агента прямо в проект, тогда агент хуйней не страдает а сразу понимает что хочет юзер, хотя иногда все еще пытается вместо drawable texture использовать вьюпорты или еще что-то в таком духе
> никто уже не использует веб версии для вайбкодинга
Ну, за всех не говори.
Я ни копейки не заплачу за обходы ограничений, чтобы юзать агенты. Мне вполне хватает низкоконтекстной клавдии в утке, а утка в браузере, а браузер в отдельном окне.
Не для того меня маменька растила нищебродом, чтобы я своими грошами поддерживал ИИ-пузырь.
Анон, никто не спрашивал о вайбкодинге и агентах. Новичок выше >>1109361 спрашивал о том, как ВНИКНУТЬ в движок и как обучиться в нем работать. Не о том, как использовать нейронки в разработке и не о том, стоят ли они вообще того, а о том, как научиться понимать, что там вообще происходит. Он вообще не спрашивал о нейронках.
Фанатики сразу насыпали ему полное ведро советов использовать ИИ, а мой тезис в том, что это хрень и нужно читать о каждом шаге самостоятельно, потому что ИИ насыпет новичку такой дезинформации, что он охренеет, попытавшись применить это на практике.
>Анон, никто не спрашивал о вайбкодинге и агентах.
Мне похуй, я не с ним общаюсь а с неосиляторами которых реплайнул
>а мой тезис в том, что это хрень и нужно читать о каждом шаге самостоятельно
Нейронки не отменяют этого факта, но читать нужно не код а математические и логические модели, которые описывает код, генерируемый нейронкой. Их действительно надо читать, спрашивать нейросеть что она насерила, удостоверяться в соответствии модель->код в том числе через тесты, а не читать каждый коммит. Впрочем, ебитесь с этим говном в вебе, никого не отговариваю
>Мне похуй
Все правильно. Нахуя отвечать кому-то по делу в тематическом треде, если можно просто влететь в двух ног в разговор, на которых тебе похуй и вставить свое ценнейшее мнение о том, как правильно генерить нейрослоп, когда речь шла даже не об этом.
Я всего навсего поправил двух неосиляторов, дабы они никого не вводили в заблуждение
Ладно, я привлек внимание модератора. Теперь можно забанить этого бота
>>1109621 →
>>1109477 →
>>1109450 →
>>1109431 →
>>1109400 →
и т.д.
>чтобы внутри рамки двери стена вырезалась через маску,
Не совсем понимаю откуда проблема возникла, дверь прозрачная в середине и через прозрачность видно стену, а ты хочешь чёрный прямоугольник?
Нет, я хочу, чтобы через дверь было видно пол, т.е. слой стены внутри дверной рамки вырезался с помощью маски. На пикче приложил часть тайлсета, как я понял двери с серым прямоугольником внутри как раз были предназначены для маски. Можно конечно сделать отдельные варианты стен с проемом, но это надо будет делать для каждой новой стены + каждой новой формы двери, т.е. их количество будет расти в геометрической прогрессии, а хотелось бы сделать универсально
Открой картинку в графическом редакторе и сделай серые участки прозрачными.
Но вообще у тебя уже есть такие прозрачые двери. О чем ты вообще?
Сделай тайл двери для стены. И тулом вставляй на сетку стен.
Блять... Смотри, красным я обозначил места, как должна выглядеть стена вне рамки, синим показал как оно выглядит при "прозрачной" двери без стены под ней. Если делать со стеной за дверью, то стена будет внутри дверного проема (желтая стрелочка), а там должен виднеться пол. Не знаю как еще понятней разжевать
>>1109959
Так это для каждой текстуры стены придется рисовать. Ладно, придумаю что-нибудь
Если правильно понял, ты хочешь примерно как на пике, ну я бы сказал что лучший вариант - делать дырку в стене, на неё уже накладывать дверь, т.е. нужно нарисовать тайлы стены с прозрачными кусками, на которые будет накладываться дверь
Ты тупой я тоже и это нормально
Сделай специальный "дверной тайл" обрезанный для двери.
Какие нафиг шейдеры.
Если стена будет только одна, сделай дверь сразу со стеной.
Я об этом уже писал здесь в последнем предложении - >>1109951, вообще первое что пришло в голову, просто хотелось универсальноти
Тебе придется и дверь разделить на две части если хочешь чтобы персонаж визуально проходил правильно.
>>1109972
>дверь разделить
Дверь мне запилите!
Может решение есть, но я бы не стал вешать шейдеры, чисто из гуманитарных соображений. Но опять же тебе надо решать как будет проходить персонаж (верхняя часть должна быть вне Y-сортировки).
>А в тридэ такие штуки лехче делаются, мдас хехс
Имитировать три-дэ в два-де всегда было сложным. Но модели делать все равно дольше чем эту дверь за 5 минут рисовать с разными стенами.
Неожиданно - но разработка игр это рутинная монотонная работа. Играть в игре веселее чем их делать.
>Шейдеры
Когда люди видят некро-графику, они ожидают что игра пойдет на их некро-компе.
Тебе просто утопят игру и ты даже не будешь знать почему.
>Но модели делать все равно дольше чем эту дверь за 5 минут рисовать с разными стенами.
От стиля зависит, я в блокбенче хуярю за пару минут и пиксельные текстуры там же натягиваю.
>От стиля зависит, я в блокбенче хуярю за пару минут и пиксельные текстуры там же натягиваю.
Тоже верно, но я пытался делать лоуполи с градиентными текстурами, а так как я не художник - визуально это выглядело хуже. А без опыта - дольше.
Как-будто для 2D у нас есть какая-то "скидка" по ощущениями, а плохое 3D уже режет восприятие. Да, я видел красивое лоуполи, у меня так не выходит.
Скорее всего я не прав и не хочу во всем этом детально разбираться (свет, фильтры, шейдеры итд).
PS
Cпасибо римволду я в разработке могу даже иногда на анимацию забить, если игра в глубину развита. А вот для 3Д на такую скидку рассчитывать уже нельзя.
Пикчи не мои, просто демонстрация как одно и тоже по разному воспринимается.
>демонстрация как одно и тоже по разному воспринимается
конечно, 200 фпс против 20 пс
Не понял, почему у тебя над дверью не прозрачность, а прилепленый пол.
Что касается шейдера, так ты и так используешь встроенный шейдер, как бы иначе Blend Mode Substract работал. Только еще и доп ресурсы тратятся на расчет псевдоосвещения
Не знаю с чего ты взял, что над дверью непрозрачность, внимательнее вглядись в текстуру пола - в тайлсете там прозрачность, а не пол. По поводу шейдера - да я понимаю, имел ввиду нужно ли будет ручками писать, я в этом не особо силен
Ты, блин, даже не описал игру, какой вид камеры.
Читай https://ru.wikipedia.org/wiki/Проблема_XY
По факту, ты сам себе проблему нашёл. Нафига тебе неполноценные двери, которые не вписываются в 2-4 отдельных тайла? Большинство тайловых игр имеют определённый размер тайла: 1 тайл = ноги героя, а 2 = полный рост, и соответственно все двери 2 тайла и перекрывают РОВНО два тайла пола и стен.
Но ладно, если тебе прям не терпится двери самых разнообразных форм, включая круглые, сердечки, зигзагообразные, и множество других, делай так:
1. Нода с кастомным скриптом, типа:
>@tool
>class_name Door extends Sprite2D
>@export_group("Textures", "texture_")
>@export var texture_door: Texture2D
>@export var texture_wall: Texture2D
2. В потомках ноды такая фигня:
>SubViewport
>_ Wall: Sprite2D
>_ Door: Sprite2D
Можешь создавать их в _ready скрипта.
3. Настраиваешь всё через код скрипта.
4. Используешь SubViewportTexture в корне.
Да, это может быть неэффективно, если у тебя там несколько тысяч одинаковых дверей с одинаковыми стенами (нафига тогда ты этим занялся?), но ты ещё недоделал игру, так что рановато оптимизировать... А доделаешь, заметишь проблему - вот тебе план Б:
1. Скрипт хранит Resource с Dictionary:
>class_name DoorDB extends Resource
>var key_count: int
>var keys: Dictionary[Sprite2D, Dictionary]
2. Когда юзер вбивает новый спрайт-дверь или стену, проверяем эту базу дверей, и если не находим пару, генерируем новую текстуру с помощью SubViewport:
>func get_walled_door(door: Sprite2D, wall: Sprite2D) -> Sprite2D:
>_ if door not in keys:
>_ _ keys[door] = {}
>_ if wall not in keys[door]:
>_ _ keys[door][wall] = generate_walled_door(door, wall)
>_ return keys[door][wall]
3. Функция "generate_walled_door" временно создает SubViewport с двумя спрайтами, делает "скриншот" и оставляет после себя только статичную текстуру (с прозрачной дыркой под пол, естественно).
Теперь у тебя эффективный генератор + хранилище вероятных комбинаций дверей, который эффективно использует и диск, и RAM, и ЦПУ/ГПУ, адаптируясь к конкретным условиям игры и данных. Без шейдеров!
>>var key_count: int
Игнорируйте эту строчку. Я долго думал над тем, как указывать Dictionary сразу два ключа, и только потом осознал, что мы можем же иметь словарь в словаре.
>Без шейдеров!
...полагаю, что для 100% универсальности, некоторый шейдер всё же потребуется, чтобы можно было взять абсолютно любые текстуры и вырезать дырку чётко в указанном месте - но этот шейдер будет простым и использоваться всего для 1 кадра в SubViewport, а в дальнейшем используется запечённая текстура.
Также возможно придумать массу усложнений, типа нормалмапов или анимированных стен, которые не запекаются так просто... Тут, опять же, нужно будет рассматривать требования конкретной игры. Часто пиксельные игры не имеют нормалмапы, анимации ограничены отдельными спрайтами (а тут тайлы)...
Классно! Вот бы принять тебя на работу в свою студию. К сожалению, у меня нет студии.
>плохое 3D уже режет восприятие
>демонстрация как одно и тоже по разному воспринимается
Ты выбрал пример, что в любом случае дерьмово выглядит из-за палитры.
>Как-будто для 2D у нас есть какая-то "скидка" по ощущениями
Возьми пипеткой цвета с твоей фотки и порисуй ими в 2D. Будет дерьмово.
c красотой перетолстил, буквально как в вк люди свои фотки лет 15 назад прогоняли через яркость/контраст и делали из лица сплошное пятно пересвета с глазками. Нужно 60% сероты и 40% второй картинки, и будет более менее.
Есть много популярных игр с пересыщенно кислотной палитрой и минимумом теней, и чуть меньше ч/б игр с большущим контрастом, но я практически не видел популярных игр с такой тусклой серотой. То есть, если стремишься сделать популярную игру, которая будет привлекательной многим - уж лучше не стесняться и обмазываться Color.RED, GREEN, BLUE, YELLOW, CYAN и MAGENTA, чем сидеть и выбирать серо-серый из сероватосерой палитры, даже если добавишь тени. В худшем случае назовут "кислотой", но разве люди не "кислоту" предпочитают, когда покупают лимоны и кисленькие конфетки? Люди обожают кислоту. Так обожают, что некоторые кислоты даже запретили...
Ещё бы я добавил в игру динамичное увеличение насыщенности и контраста после каждого убийства. Получается так: игрок наносит финальный удар, его противник регдоллится по полу, и картинка сразу поднимается на 150% насыщенности, постепенно возвращаясь обратно. Типа скачок дофамина у кровожадного героя, за которого игрок играет (что соответствует мотивации игрока, играющего в это).
Именно поэтому тот движкопися не смог сделать нормальную игру. Он стремился сделать банально реалистичную графику "на ЦПУ без ГПУ", а должен стремиться к нереальному игровому экспириенсу, независимо от того, чем и насколько ограничен.
Подскажите, что делать.
Редактор скриптов уже года два как минимум можно отделить от главного окна в отдельное окно и потом, например, скинуть на второй (вертикальный) экран. Функцию добавили примерно в то же время, когда появилась возможность создавать нативные окна (в далёком прошлом Godot не мог в нативные окна). А в последних сборках суть изменения в том, что главные "экраны" (2D, 3D, Script и т.д.) сделали равноправными с остальными доками редактора, чтобы можно было значительно проще делать всякие плагины.
>>1110331
>странное поведение
>100 тысяч рефкаунтов с сигналами
Таблетки от психиатра принимать пробовал?
Сигналы не предназначены для такого спагетти.
>>1110334
Щас он начнёт манёвры с "а вот в римврод..."
Я когда себе купил 2К монитор, у меня резко пропала необходимость отсоединять панели. Место есть для всего.
>когда появилась возможность создавать нативные окна
Отключаю в первую очередь. Как то нахапал неприятных багов в линухе.
>>1110343
А вот это тру. Да просто широкого моника тоже достаточно.
> Да просто широкого моника тоже достаточно.
И второй моник вертикально поставить, и в него отсоединённое окно со скриптами развернуть. Вот это будет МАКСИМУМ ДЕВЕЛОП!
>купил 2К монитор
2560x1080 или 2560x1440? Давно уже подумываю...
>>1110392
>И второй моник вертикально поставить
Эээх, у меня даже для одного места едва хватает...
>>1110353
>Отключаю в первую очередь
>нахапал неприятных багов
Понимаю, у меня на Windows тоже не гладко было - особенно в первых версиях 4-ки, когда выпадающие менюшки тормозили из-за того, что каждый попап - отдельное нативное окно с контекстом вулкан (лол)... Однако, сейчас вроде как все косяки давно сгладили.
Если в редакторе стоит галка "single window mode", отделение окна скриптов от своего места весьма бесполезно, т.к. оно остаётся в пределах основного, перекрывая другие, не менее необходимые доки.
> 2560x1440
Этот. Кадуши мониторов считаются по вертикали, с округлением в маркетинговую сторону.
>2K resolution is a generic term for display devices or content having a horizontal resolution of approximately 2,000 pixels.
>In consumer products, 2560×1440 (1440p) is sometimes referred to as 2K, but it and similar formats are more traditionally categorized as 2.5K resolutions.
Ясно. У меня 1440p еле-еле впишется под полку... И неизвестно ещё, потянет ли iGPU, или как игры будут выглядеть в 720p на такой диагонали... А так, очень хотелось бы расширить юзабельное пространство...
Диагональ там стандартная 16:9, а игры нынче все скейлятся прямо у себя во вьюпорте, выводишь в 8К, а по факту рендерится в 480, лол, а для старых игор можно и разрешение 720 выставить.
>Диагональ там стандартная 16:9
Лол, диагональ - это физическое расстояние между противоположными углами экрана в дюймах или в сантиметрах, а 4:3/16:10/16:9/21:9 и т.п. называют "соотношением сторон экрана". Но нагрузку на ГПУ вызывает количество пикселей, а не соотношение.
>по факту рендерится в 480
Так делают только когда используют апскейлер на нейронках, а это делает картинку странной и сильно нагружает видеочип, так, что оригинальная графика в большом разрешении может быть дешевле, лол. Я пробовал встроенный в Godot и мне не понравилось.
Что "анон"? Он сообщал контакты? Мне похуй. Анон и анон.
Если не ошибаюсь, "магнитола" (это скорее "бортовой компьютер" или "медиа-центр" называется теперь) предназначалась для какого-то концептуального российского электромобиля... "Атом", вроде бы? Хм, кажется, автомобиль уже пустили в серию - можешь поискать обзоры на него в интернете. Мне это всё неинтересно, так что разбираться не буду. Давай ты.
>>1110682
А разве это не тот лысый неймфаг из конфы, что ещё странными видосиками обмазывает каждый тред и постоянно воюет с какими-то другими неймфагами и модераторами, которых он лично ИРЛ встречал? Он, видимо, знаменитость локальная. Или это не он?..
Действительно интересно, учитывая что теперь такие приборные панели за один промт ебашут. Ну и времена.
Причем вместе с аппаратной схемотехникой и дизайном корпуса для 3д отливки...
Причём вместе с автомобилем, бюджетом...
>Гигачад, зделой так чтоп у нас усё было
И он подскакивает и сразу всё делает.
>>1110755
Хороший мем. Перефразируя:
>Luddites
"Тише едешь - дальше будешь".
>AI CHADS
"Живи быстро - умри молодым".
>Луддитя спок.
Что в других тредах совсем перестали отвечать на твои вайбкодь вбросы? Скучно, да?
Тогда спрошу тех, кто не занят(всех).
Вот есть допустим эта инверсная кинематика, в 3д если что. Так вот, глянул десятки туториалов, как используя эту канитель, делать так, чтобы персонаж, например во время бега по склону не просто проигрывал свою анимацию бега, а ещё и правильно ставил стопу и соответственно все что за ней следует (тут ik и работает). Дохуя чего устарело, в 4.6 разрабы что-то там правили/добавляли по этой шняге, короче теперь все не то.
Но не в этом суть. Суть в том, что нихуя не видел решений для братьев наших меньших (я про котов, собак и т.д. если что). Видал только где ноги правильно ставятся на, но без анимаций.
Короче, кто хоть чуть этим занимался/занимается?
Попробовал базовую хуйню внедрить - животное идёт вперёд и чуть заходит на условный камень, значит нога должна встать на него. Но просто все ломается к хуям, ногу косоебит под разными углами.
Пробовал исправлять, но лишь меняется степень и динамика косоебства. А лап ведь 4, и проблема вставания на уступ не самая сложная.
Короче, что делать, анон?
И да, раз пошла такая пьянка. Как лучше всего реализовывать физику столкновений? Из чего строить коллизии, например капсула для тела и рэйкасты для лап?
> не происходит.
Разгонять всех банами, а потом интересуются почему никто не пишет.
>Движкосрачя, спок.
Ты хотел сказать вайбкодя срач?
Туда еще кто-то заходит?
Чел со скайримом оказался пророком, ахуеть.
там и майнкрафт скрестили со скайримом...и с калл оф дути...
ох братцы... не к добру всё это...
Не надо гнать на Алису, её хорошо прокачали в последнее время
>пытаешься заставить IK решать задачу, которую IK решать не должен
Дальше эти галлюцинации можно не читать - предпосылка неправильная.
>>1110980
>Игори делаете чтоль?
Ты не поверишь, но нет, не делаем ничего.
>не видел решений для котов
Почти ничем не отличается от решений для гуманоидов.
>Но просто все ломается к хуям, ногу косоебит под разными углами.
Так ты сначала в редакторе мышкой подёргай за эту лапу, чтобы увидеть, как он будет гнуться под разными углами, прежде чем приделывать к ней рейкаст и блендить. Мне кажется, встроенный IK в Godot более требовательный к костям, чем в Blender. Если в Blender ты можешь навертеть кучу костей кое-как и оно будет как-то работать, то в IK Godot работало нормально только с 2 костями под определёнными углами. Так что ты, возможно, будешь вынужден сделать свой собственный IK solver для 3 костей, если в актуальных версиях Godot проблему 2+ костей ещё не решили (не интересовался, но вроде пытались).
Особенность многих четвероногих животных в том, что они ходят "на цыпочках", поднимая свою пятку так высоко над землёй, что она напоминает нам "коленку назад", тогда как реальная коленка часто близко притянута к животу - это добавляет им скорости или вроде того. Поэтому для реалистичной анимации тебе необходимо будет иметь 3 кости под IK, а не 2, как в случае гуманоидов, у которых пятка - точка опоры.
Но вот вопрос: а нужно ли тебе с этим всем возиться вообще? Это как регдолл - прикольно, но не более того, если ты не завязываешь на этом весь геймплей как в каком-нибудь Fall Guys. Твой игрок управляет четвероногим животным от третьего лица, постоянно заглядывая ему под жопу? Или у тебя там огромный четвероногий танк, занимающий половину экрана? И подумай о ландшафте: если это плоскости да редкие холмы, то IK будет избыточным; если это каменистые скалы, IK вряд ли сможет сделать положение ног действительно реалистичным из-за того, что всё тело должно балансировать как в active ragdoll. И также важна производительность. Что у тебя - 1 питомец на всю игру или 20 волков в стае? Сомневаюсь, что игроку понравится управлять стаей, которая тормозит всеми своими 80 ногами, пусть и "реалистично" касаясь каждого камушка на дороге. Плюс, ты должен будешь добавлять каждому такому камушку реалистичную коллизию, иначе весь твой IK будет совсем бесполезным. Хочешь ли ты этим заниматься?
Короче, это фича из разряда "было бы неплохо иметь, но у нас нет ни денег, ни времени, ни желания, а игрок эту фичу не заметит и не оценит по достоинству, а вот баги и тормоза из-за неё обязательно вызовут у него лютое бешенство, поэтому лучше забить и не вспоминать, пока не заработаем первый миллиард".
Их забанили за нейросрач и они ушли общаться с нейронками
Даже не забанили. Просто насмотрелись на местного душнилу-луддита и ушли.
>Их забанили за нейросрач и они ушли общаться с нейронками
Неожиданно, впервые адекватный банан.
База. А луддитины посты игнорируем, отвечайте ему, но вслух.
Да кто ж его знает, недоношенного выблядка вахтера гд. Просто по личной прихоти банит. Мучительного рака ему и всей его семье. Хорошим людям добра.
Это был залетный шизло-порватка, который вместо делания игр хуйней страдал и тред дерейлил на свои зиги. Вот тебе community poll, который разрабы годота ежегодно проводят. И доля GDScript растет от года к году, как и сам годот.
Меньше неумёх слушай. Они свои провалы на что угодно валят.
>дружелюбной, токсичной атмосфере
Тут только один конкретный индивид брыкается на весь тред, когда его справедливо банят.
>половина его хуесосят
Это всё один с синдромом утёнка на C#, которому байты считать для клона RimWorld захотелось.
>хотелось бы выжимку по фактам, чем так плох Gdscript
Откровенно "плохого" в нём ничего нет. Говорить, что он "плох", это как говорить, что "все ножи - плохие", когда ты пришёл с ножом на перестрелку и тебя ранили, а ты ни до кого даже не дотянулся. От того, что от ножа нет толка в перестрелке, нож не становится "плохим" - он просто предназначен для радикально других задач или ситуаций.
Начать нужно с вопроса "зачем нам столько языков программирования". Компьютер способен выполнять только простейшие команды, описанные порядковыми числами, которым можно дать ярлыки из букв, но суть от этого не меняется - ты по-прежнему пишешь код процессора по строгим правилам, которые оптимизированы для более эффективной работы процессора и могут отличаться между разными архитектурами и моделями процессоров. Поэтому на языках ассемблера (их много) мало кто пишет сегодня, если нет строгой необходимости в этом.
Чтобы устранить все эти проблемы ассемблера (трудность понимания человеком, оптимизация под конкретную архитектуру/модель процессора и т.д.) придумали более сложные языки программирования. Эти языки дают конструкции, более просто читаемые и понимаемые человеком, которые затем должны быть транслированы в машинный код - то есть код нужно перевести с человекочитаемого в машиночитаемый код. Сложность этого перевода сильно зависит от того, какие конструкции ты хочешь видеть со стороны человека и, конечно, от эффективности твоей программы-переводчика, которую сначала нужно написать на языке процессора (тут у нас возникает "проблема курицы и яйца", но в современном мире это уже давно не проблема для новых языков).
Так что все языки можно разделить по сложности трансляции из человекочитаемого вида в машинный код. По этой причине некоторые языки называют "низкоуровневыми" - они более простые, более близкие к ассемблеру по сложности своих конструкций - а другие языки называют "высокоуровневыми". Также иногда можно встретить названия "среднеуровневый" и "сверхвысокоуровневый", но это всё не важно. Важно понимать, что чем "выше" по этой шкале расположен твой язык, тем сложнее перевести написанный человеком код в машинные коды, и тем сложнее написать эффективный переводчик на машинный. Сложность может быть настолько высокой, что проще вместо буквального перевода держать при себе целый переводчик и "переводить" программу на ходу - то есть использовать "сценарий" ("скрипт"), которому следует сложная программа-исполнитель ("интерпретатор"). В некоторых случаях создать машинный код без промежуточного интерпретатора просто невозможно.
Другими словами, чем выше уровень языка, тем больше промежуточных команд процессора нужно выполнить для выполнения одной команды, написанной программистом. И не всегда эти команды можно оптимизировать, т.к. мы занимаемся разбором написанного на ходу, не видя дальше собственного носа - чтобы позволить программисту совершать различные трюки с кодом вне нашего поля зрения, которые просто невозможны (или слишком сложны), если записывать на языке машины (а современные ОС вообще запрещают делать подобное из-за риска вирусов).
И теперь главное: в некоторых случаях эти затраты оправданы, в других - нет, и поэтому нужно выбирать свой язык по ситуации. Иногда правильным решением является не использовать готовый чужой язык, а написать свой личный, самодельный язык, который будет иметь ровно то, что тебе нужно, но не более того. Впрочем, создать достаточно эффективный язык высокого уровня с нуля не так-то просто, поэтому с этим связаны свои проблемы...
Возвращаясь к Godot и GDScript, да и к геймдеву в целом: код большинства компьютерных игр можно разделить на тот, который должен выполняться 60+ раз в секунду и быть как можно ближе к машинному языку конкретного процессора, чтобы игра выжимала больше кадров в секунду на платформе игрока, и на тот, который может себе позволить тратить время на промежуточные команды интерпретатора, при этом требует сложных конструкций, понятных любому простому человеку - даже дизайнеру, а не только заросшему бородой сисадмину, пишущему программы для сложных систем намагниченной иглой прямо по поверхности системного диска.
Как правило, высокопроизводительный код игры называют "движком" - в нашем случае, это Godot. Такой код часто повторяется из игры в игру и поэтому его можно распространять как отдельный продукт, предназначенный для создания новых игр на общем фундаменте. Такой код пишется, обычно, не на ассемблере, а на C/C++, которые считаются языками "средне-низкого" уровня, и у которых самая богатая поддержка разных архитектур, поэтому их код легче перенести на другую платформу. Но писать "медленный" код для игры на них - довольно муторно для программистов, и чрезвычайно сложно для тех, кто не занимается программированием профессионально.
Поэтому многие игровые движки, и Godot не исключение, имеют в своём составе "скриптовый" язык, который может или не может компилироваться в машинный код. Возможно, ты знаешь, что наиболее популярным языком в старых играх была Lua - она и сейчас используется для многих игр. Также ты наверняка знаешь, что в Unity используют модифицированную версию C#, которую они только недавно научились компилировать в машинный код, а до этого были вынуждены полагаться на своего рода интерпретатор ("виртуальную машину"). В Unreal Engine есть урезанная версия C++ и визуальный язык Blueprint. Также можно отметить разные варианты ECMAScript, такие, как ActionScript из Macromedia Flash, JavaScript в некоторых движках и многих веб-играх, и покойный UnityScript из старой Unity. Некоторые платформы разработки игр имеют чрезвычайно высокий уровень скриптинга - такие программы чаще называют "конструкторами игр", как, например, GameMaker, Construct, RPGMaker, 001 Game Creator и многие другие.
Собственно, разработчики Godot решили пойти по стопам GameMaker и компании - создали свой собственный, персональный скриптовый язык "GDScript", который, тем не менее, обладает всеми свойствами полноценного языка программирования и может легко конкурировать с Lua и разными старыми версиями ECMAScript, и, разумеется, в разы лучше чего-то, что используется в ограниченных конструкторах игр. То есть это что-то промежуточное между "серьёзным" языком типа C++ и "игрушечным" DSL (domain specific language) из конструкторов игр. GDScript даёт каждому разработчику на Godot легко понятную запись логики игры, которая тесно переплетена с внутренностями движка Godot и легко редактируется через встроенный редактор кода (IDE, integrated development environment) в редакторе Godot (Godot Editor - то, что в чём ты обычно открываешь свой проект на Godot). Как можно понять из вышесказанного, преимущества GDScript несут в себе стоимость в виде более медленного исполнения кода - однако, для того, для чего обычно используют GDScript, высокая скорость выполнения и не нужна.
Но не нужно бояться "ограниченной скорости GDScript": в большинстве случаев, игра состоит на 99% из картинок, музыки и текста, и поэтому требует только уже реализованных в коде Godot алгоритмов, обращение к которым со стороны GDScript несоизмеримо быстрее их работы. Мало кому может потребоваться писать что-то на C++, чтобы создать полноценную игру, т.е. используя только GDScript для всех игровых алгоритмов. Более того, куда более вероятно, что твоя игра будет тормозить из-за графики или физики, чем из-за написанного тобой кода.
Отдельно стоит отметить причины реализации поддержки C# разработчиками Godot: во-первых, Godot зачастую рассматривается как замена для Unity, а пользователи Unity лучше всего разбираются в C#, во-вторых, Godot в своё время получил огромную сумму денег лично от Microsoft специально для реализации поддержки C#. Тем не менее, Godot поддерживает подключение практически любого другого языка программирования, и наилучшим языком для производительного кода всё равно остаётся C++ из-за более развитых компиляторов и готовых библиотек.
Так что пользуйся GDScript и ничего не бойся, а если вдруг будет нехватка скорости - смотри в сторону C/C++.
>>1111383
>Меньше неумёх слушай. Они свои провалы на что угодно валят.
База, именно такое ощущение от его постов (особенно в движкосраче).
>>1111389
Спасибо за развернутый ответ! Ну я как то тоже подумал, что язык эо всего лишь инструмент, собственно, как и естественный язык. Просто возникли сомнения так ли он замедляет. Ну и да, я тоже учусь на мини-джемах типа "клон RimWorld", но просто интересен ИИ. Примерные границы и даже что-то по оптимизации уже понял. Так, например, при 1200 простых FSM (на каждого генерится свой скрипт) появились просадки. И да, я знаю, что так неправильно, но во-первых на самом деле таких ИИ агентов не должно быть больше 10-15 по логике игры. Это было просто "испытание на прочность". Ну и да, FSM, конечно не пешка в RimWorld, там чуть посложнее, но в общем и целом, это был эксперимент. В принципе я быстро почувствовал, как именно это можно оптимизировать, просто это было не нужно.
Кстати, Lua я немного знаю тоже, но до Love2D не добрался. Слишком всё.. сложновато если честно для моего опыта. Но идея языка "всё есть таблица" оч крутая.
Пикча - ужасная статистика, которая говорит что разнообразия языков в годоте это миф. Я хз чему ты радуешься. Профессиональный разработчик видит тут вендерлок на языке у которого нет рантайма вне годота.
15% C# скорее всего реальный процент переехавших инди разработчиков, которые понимают что делают, вопреки неудобства шарпов как гражданина второго сорта.
Остальные - это показатель насколько реально комфортен GDE.
>zig
Это был другой анон, хз что у него там сложилось, но обычно программисты как раз и делают свои проекты, в отличие от мечтателей. У вас даже есть свой внутренний мем "безигорка", который отражает всю глубину проблемы. У кодеров таких проблем нет, мы тихо пилим и кайфуем от программирования, это наше хобби.
>Это был залетный шизло-порватка,
Так я замерил тестами, переписал листодробилки на шарпы и ушел делать игру. О чем мне еще писать? Я просто делаю игру, событий никаких нет. Я думал что буду делать быстрые прототипы на гдскрипте, а писать реальную игру на шарпах, но в реале полностью ушел в шарпы. Комфорт от привычного си-лайк языка оказался выше, чем плюшки от гдсрипта в редакторе.
На самом деле я не знаю улетал ли я в бан или нет, у меня роутер сам ребутиться по времени. Мне просто тред стал как-то противен, лишь раз в неделю забегаю поскроллить
>и тред дерейлил
>ряяяяя низя обсуждать шарпы, только гдсрыг!!!! ЗАБАНЮ!!!!
Ты походу тот вахтер с обострением, который умудрился убить единственный живой тред в гд. Теперь вместо технически грамотных анонон тут будут протекающие вайбкоди с глубиной знаний воробушка. Наслаждайся.
> Кстати, Lua я немного знаю тоже
Устанавливай и наслаждайся https://github.com/gilzoide/lua-gdextension
Продакшон левел!
Интересное обсуждение в комментариях:
https://www.reddit.com/r/godot/comments/1x0e9vk
Пост удалили, потому что автор унизил Unity Slop™.
Открыл, а он уже был мною апвоутнут. Это тот, который для перебежчиков с юнити? Иронично что годот, с его текстовым всем, нативно поддерживается нейронками лучше чем любой юнити/анрыл.
А вообще мне кажется в ближайшем будущем нас ждет капитальное перетряхивание геймдев сцены, и полностью новые AI-first движки.
Если бы ты не был тупым, то мог принести вижимку интересных по твоему мнению комментов и обсудить это с аноном.
Нет никакого желание погружаться в это и тем более искать там интересные комменты.
Если бы редотеры форкали годот сейчас, шансы успеха были бы гораздо выше.
О! Пригодится! Не в текущем проекте, но в одном из концепптова точно.
Если ты вдруг не знал, Godot позволяет выполнять произвольный код на GDScript прям в игре, из любого источника: файла на диске, интернета или просто так, обычного поля ввода (LineEdit). Конечно, нужно будет специальные инструкции выполнить сначала, но сам механизм позволяет дать игрокам инструмент для модификации логики игры прямо во время игры. Соответственно, отдельно ставить Lua не нужно.
>LineEdit
Алсо, кроме RichTextEdit есть ещё какая-то CodeEdit (не помню название), которая позволяет тебе встроить в собственную игру полноценный редактор кода, какой используется в самом Godot Editor. Правда, я не уверен, присутствует ли эта нода в стандартных release сборках - возможно, потребуется пересобрать export template.
По такому принципу построены обучалки GDScript и несколько каких-то инди-игр про кодинг на Godot.
Вкратце, Colobot у нас дома - прямо из коробки!
>вайбкодя чувствует НЕУДОБНОЕ
>начинает сразу с оскорбления
>добавляет боевую картинку
> Godot позволяет выполнять произвольный код на GDScript прям в игре
Какого-то exec'а вроде не было, а компилятор гдскрипта не уверен что входит в релиз сборки, инфа точная?
>компилятор гдскрипта не уверен что входит в релиз сборки
Компилятора вроде никогда не было, есть только интерпретатор.
>Какого-то exec'а вроде не было
Есть упрощённый аналог eval, вот тут подробнее:
https://docs.godotengine.org/en/stable/tutorials/scripting/evaluating_expressions.html
Но Godot также позволяет загружать любые .gd файлы и интерпретировать любой текст как GDScript.
Подробнее тут https://docs.godotengine.org/en/stable/classes/class_gdscript.html и в базовом классе Script.
А ещё, поскольку в .tscn и .res может быть упакован код на GDScript, который может исполняться в момент простой инициализации сцены движком (типа load("user://savegame.tscn").instantiate()), а не в момент какого-то действия с объектом, то если ты используешь tscn/scn/tres/res для сохранения-загрузки состояния игры, кто-нибудь, в теории, может написать вирус на GDScript, загружающийся в игру из этого файла, и модифицирующий новые файлы, чтобы отправить кому-то другому и т.д. Это вечная проблема скриптовых языков, тут сложно что-то поделать кроме как "не использовать tscn/tres для сохранения и загрузки игры и просить юзеров не брать файлы из небезопасного источника".
Но зато это позволяет делать игры "для программистов" и всякие интерактивные обучалки с реальным GDScript внутри.
>компилятор гдскрипта
А, вроде был какой-то в 3.x, но в 4.x его не завезли почему-то, что-то там сломалось у них.
Вообще, если тебе прям нужна игра со скриптами и в релиз сборке какой-то фичи не хватает - можно просто давать editor билд, он точно так же умеет запускать PCK, как и export template, просто он чуть жирнее и содержит в себе "потенциально небезопасные" фичи, наверное. Но для, например, моддинга, игры всё равно закидывают editor билд вместе с игрой, чтобы игроку не приходилось искать подходящую версию. Лицензия MIT позволяет делать что угодно с бинарниками, так что в этом нет никакой проблемы...
https://oceanofpdf.com/?s=Godot
И шапку добавьте
>есть только интерпретатор.
Если не доёбываться сильно, .gd файлы при экпорте превращаются в .gdc, ну типа compiled, там уже подготовленный байт-код
>Но Godot также позволяет загружать любые .gd файлы и интерпретировать любой текст как GDScript.
Вот тут не очень уверен, надо проверять на релизном билде, о чём изначально и написал.
>А ещё, поскольку в .tscn и .res может быть упакован код на GDScript, который может исполняться
Припоминаю эту тряску, что на Godot вирусы будут делать... Вообще делать сохранение на сценах - так себе идея.
>"не использовать tscn/tres для сохранения и загрузки игры и просить юзеров не брать файлы из небезопасного источника"
Как минимум можно не использовать текстовый формат, все форматы начинающеся с буквы t (текстовый) имеют аналог без неё - бинарный.
>Но зато это позволяет делать игры "для программистов" и всякие интерактивные обучалки с реальным GDScript внутри.
Если всё-же можно загрузить и выполнить любой скрипт, то могли бы дать флаг, чтобы это отключить и вообще можно сделать реестр скриптов с хешами и загружать только совпадающие.
>>1111634
>gd файлы при экпорте превращаются в .gdc
При экспорте можно выбрать экспорт скриптов чистым текстом...
>надо проверять на релизном билде
Проверил - запуск работает, но редактор кода нужно допиливать.
>можно не использовать текстовый формат
Какая разница, если скрипты могут быть и в бинарном формате?
>могли бы дать флаг, чтобы это отключить
Ну, каждый лишний флаг - это проверки, а, значит, замедление.
>>1111549
>CodeEdit
Эта нода хороша как фундамент, но это не весь редактор кода.
Сделай игру про подземелье, где я должен написать скрипт, чтобы победить всех монстров и собрать лут героем и спустится ниже. А в конце встретится с таким же героем из сети и биться за сокровищницу.
>Проверил - запуск работает
Понятно, будем знать
>каждый лишний флаг - это проверки, а, значит, замедление
Я видел это как флаг компиляции отключающий парсер, например
>написать скрипт, чтобы победить всех монстров
Подобных игр уже много, вот самая крупная:
https://en.wikipedia.org/wiki/Colobot
>...eliminating any alien life forms...
Статистика показывает, аноны ливают раньше чем упираются в возможности годота.
Сделать свой геншин (зачем? геншин уже есть) - по количеству работы это как построить самолет боинг 747 у себя в гараже.
У тебя шлема нет проверить? Годот умеет в WebXR, PCVR и автономный режим. Ты не определился с форматом VR походу же.
Небойсь даже Project Aincrad в VRChat не пробовал.
Почему бы не сразу гта 7 зделоть? Чет ты мелочишься, большой рыбы с тобой не поймаешь я смотрю.
> Появилась у меня мечта
У тебя обязательно получится.
> Осилит четвертый годот нормальный фпс
Осилит-осилит.
Тебе, в принципе, уже всё сказали, но хочется развернуть мысль. Поверь, ты сейчас плохо представляешь себе всё, что требуется для разработки даже небольшой, но хорошей 3D игры, которая по силам одинокому "на все руки мастеру". Ты же хочешь хорошую игру, а не тяп-ляп ассет-флип с кучей рекламы, который противно даже бесплатно скачивать, если ты уже не наивный ребёнок? Судя по тому, что тебя беспокоит частота кадров, ты хочешь хорошую игру (ассетфлиперы на юнити не парятся об оптимизации, отсюда эта репутация тормозной и глючной юнити). Но для хорошей игры движок - это самое меньшее, что тебе нужно, и движок по ходу дела не так трудно сменить, даже если придётся все скрипты игры переписать с одного языка на другой (это к вопросу о мнимой "закрытости" GDScript относительно других языков).
Большие игры начинают делать, определившись с целевой аудиторией (ЦА). Но тебе, как одиночке, нужно определиться в первую очередь с твоей настоящей целью. Ты хочешь сделать популярную игру, которая будет у миллионов игроков установлена? Можешь забыть об этом, если тебя привлекает игра, а не процесс агрессивной, лживой раскрутки игры в соцсетях и хищные методы, абьюзящие психологически уязвимых людей. Аналогично если ты грезишь о сверхприбыли. Если же ты мечтаешь о том, как будет прикольно играть в свою игру и добавлять всякое, не дожидаясь никого и даже наплевав на цензуру - то ты должен быть готов к тому, что до этой мечты пройдут годы тяжёлой, скучной рутины, и ты потеряешь желание заниматься этим много раз до того, как сможешь прикоснуться к тому, что ты себе навыдумывал. Реально дойти до финишной черты смогут лишь те, кому доставляет удовольствие вся эта неизбежная рутина.
Чтобы понять, что тебя ждёт, нужно сначала понять, что для тебя "клон геншина", а точнее - что именно ты планируешь копировать, а от чего готов отказаться. Большой проработанный мир? Десятки проработанных персонажей? Как мне кажется, мир геншина не заслуживает никакого внимания - он пуст и однообразен, это всего несколько красивых 3D диорам и километры однообразных препятствий, чтобы максимально затянуть геймплей. Но даже на одну такую 3D диораму у тебя может уйти несколько месяцев труда, а результат - "ну, прикольно выглядит" - и всё. Также и на одного персонажа может уйти несколько месяцев со всеми деталями и анимациями, ведь ты не хочешь кривой нейрослоп или чужие анимации, которые не подойдут твоему персонажу по характеру и стилю. Геймплей там посредственный, сюжет залит водой и катсценами, где 2-3 персонажа стоят кругом и чешут языком, озвучку ты не сделаешь в соло без кривого нейрослопа или бюджета на наёмных актёров озвучки. Что ещё остаётся? И зачем это делать в VR (пока мёртвая ниша)?
Но ладно, вот ты определился, допустим, что хочешь сделать красивую диораму с 1 видом противников и 1 персонажем, которым можно бить этих противников, 1 квестом без озвучки на зачистку локации от противников, и чтоб это было в VR от третьего лица (иначе зачем называть это геншином, если будет от первого лица?). Работа с движком у тебя займёт минимум времени, потому что это просто статичная моделька на фоне, маленькая группа тупых боксёрских груш и простенький контроллер персонажа по туториалам. Теперь открывай Blender, Krita и/или какой ты там 3D/2D софт предпочитаешь, и начинай рисовать. Сначала начни с концептов, которые нейронкой всё равно не сделаешь как положено, потому что нейронка не способна читать твои мысли пока что. Потом набросай из серых фигур эту свою выдуманную локацию в 3D. Закинь в движок, подвигай капсулу, чтобы прикинуть масштаб. Рисуй текстуры и потом муторно накладывай их, чтобы не было швов. Потом то же самое для персонажа и противника, но теперь тебе нужно ещё больше сил и времени на детализацию, а нейронки выдают ещё более стрёмный, ассетфлиповый результат, чем со статичными декорациями. Потом ты должен натянуть затекстуренные меши на скелет и разочароваться в свой жизни из-за того, как стрёмно это всё выглядит на сгибах. Долго править чисто техническую информацию, которую игрок вряд ли заметит. Потом делать анимации, делать и переделывать, потому что с первого раза ничего не получится как надо. И только потом проверять в геймплее, и снова переделывать, потому что ощущается как-то не так.
Пройдёт сколько-то месяцев такого упорного труда и ты сможешь пощупать свою сценку на одной статичной локации с одним персонажем и одним противником. При этом движок ты открывал разве что раза 2-3 в месяц, и написал от силы десятка два строк кода, которые выглядят почти одинаково на любом языке и любом движке. При этом у тебя всё ещё нет звуков, музыки и озвучки, а твой геймплей состоит из "пойди и закликай насмерть 20 статистов - убил? молодец". Допустим, ты начнёшь делать вторую локацию и ВНЕЗАПНО окажется, что Godot не тянет сразу две локации - окей, ты можешь взять Unity или UE или что там ещё создадут в ближайшие месяцы - и тебе нужно будет просто открыть этот новый движок, импортировать все твои модели с текстурами и анимациями и за один-два часа переписать твои пару десяток строчек кода с одного языка на другой. Молодец, ты мигрировал результаты многомесячного труда на новый движок, который даст тебе +5% фпс, но не сделает за тебя всю остальную игру, на которую уйдут десятки лет.
И это ещё не говоря о VR, который добавляет свой клубок проблем, поэтому и дохлый до сих пор, несмотря на то, что технически технологии VR существуют почти столько же, сколько существуют видеоигры в принципе. Это всё ещё такая же зародышная фигня, что и прежде, со своими детскими болячками, брошенная многими техническими гигантами. До полноценного VR ещё далеко, поэтому тебе придётся не только игру делать, но ещё и бороться с технологией.
Короче, ты беспокоишься совсем не о том. Тебе бы не в /gd/, а в /td/, чтоб тебе пояснили, как сделать "геншин".
Какие 10 лет, люди с нормальным ии уже за неделю делают клон тераррии почти со всем контентом кроме боссов - https://www.reddit.com/r/aigamedev/comments/1wywfri/claude_opus_55_rebuild_terraria_in_3d_custom/
Ну удачи там. Сидишь такой "ИИ мене надо то..". Охуительный ты разработчик... А на деле тупо незнайка, неумейка и ленивоче чмо. Инди - это о тех, кто любит красноглазить и создавать руками. Это творческий процесс. И, да, уточнить у ИИ моменты, в целом полезно. Но, точно вредно, если не ты, а ИИ делает игру. Получается, что ты вовсе и не создатель в этой картине.
Врети, нейронки в собственных ногах путаются! Ничего не могут!!1
Мне кажется давно уже стоит разделять эскапистов геймдевов и творцов. Эскаписты это в основном красноглазики, которые там движки с нуля создают и прочим непотребством занимаются, кроме непосредственно созданием игр. А творец он на то и творец, у него его видение и он ебашит, а как это уже другой вопрос.
Занятно ты свои слабости пытаешся прикрыть переворачивая мои слова.
>и он ебашит, а как это уже другой вопрос.
С потом на лице забивает промпт, напрёженно ожидает ответа ии?
Ебашит... Ага... угу
У нас творцы по старинке ебашат, на тех инструментах к которым привыкли. Парадигму сложно менять, даже если новая быстрее, к этому привыкать ещё надо, новое это всегда стресс.
Я свои старые проекты ии отдавать не спешу, мне просто удобнее там контент пилить без его вмешательства.
А если вбить неправильный код, отловить ошибку не засрав консоль и выдать юзеру сможешь?
Перестань оправдывать свою лень. У тебя ж логика - "не хочу потеть, хочу бабки лутать". Моя же при этом - "придётся попотеть, но это то, что для меня важно". В этом мы с тобой разные. Да и в целом не смогу никогда понять, какой кайф от пользования ии? Ты не ломаешь голову, как накостылить или избавиться от бага. Мой кайф от процесса, каким бы он не было, лёгким или сложным. А твой в чем?
>не засрав консоль
По-моему, в релизном билде вывод в консоль может отключаться.
>отловить ошибку и выдать юзеру
Ну, метод Script.reload() возвращает какой-то код ошибки...
>сможешь?
А я-то тут при чём, лол. Кому надо - тот разберётся...
>Terraria in 3D
Когда "Minecraft clone" уже не даёт достаточно лайков для повышения ЧСВ в соцсети...
Вот только тот анон выше спрашивал про "геншин импакт", а не "пиксельный рыгалик".
>>1111924
>Охуительный ты разработчик
Да пофиг на них, они - личинки кабанчика, у кого не хватает смелости с людьми работать.
>>1111931
>А творец он на то и творец, у него его видение
В том-то и дело, что добиться от Generative AI реализации твоего видения почти невозможно.
>>1111937
>новая быстрее
Если цель жизни - это смерть, то не лучше ли было бы суициднуться, и как можно скорее?..
>>1111940
>У тебя ж логика - "не хочу потеть, хочу бабки лутать".
>Мой кайф от процесса, каким бы он не было, лёгким или сложным. А твой в чем?
Он кабан - управленец, его кайф - управлять людьми. Но ещё он двачер - боится людей...
Код это не та часть игры на которую стоит тратить свое драгоценное время, если только это не твое хобби - кодить (а не делать игру) или ты делаешь какие-то еба-механики без графена. Ты модели рисовать замучаешься и это ИИ уже не отдашь (или отдашь и мучайся потом с ретопом кривого говна ручками).
>Код это не та часть игры на которую стоит тратить свое драгоценное время
Какое "драгоценное время" ты тратишь? Мы в Godot-треде, а не в движкопися-треде вообще-то.
Зашел снова чтобы сказать, что тот анон был прав, в годот модели лучше импортировать через gltf-файл (именно gltf с текстурами рядом, однофайловая glb упаковка нихуя нормально не работает). Кидать упакованный blend-файл это действительно какая-то ленивая залупа, которая постоянно плодит мусор, а так же регулярно разъебывает настройки материалов и пути к текстурам.
Все, идите нахуй.
Привет-привет. Как шкаф?
>Зашел снова
Да ты и не уходил никуда...
>тот анон был прав
А чего ты ожидал-то, салага?
>Все, идите нахуй.
И тебе счастливой доставки!
Похоже, ты ошибся движком
>люди с нормальным ии уже за неделю делают клон тераррии
Это твой уровень - наличие ии, кривой код, ворованный концепт? Прискорбно...
>>1111966
Ребят, ну, давайте не издеваться над детишками. Ну, тред любви же всё-таки. Движок наш специально адаптирован для детей, зачем прогонять? Вы сидите на детской площадке, вокруг детские качели, песочница, всякие забавные зверушки и т.п. Приходят дети с модными игрушками - ну, там, спиннеры какие-то, или как это ещё называют... не важно; а вы им говорите "похожие, ты ошибся площадкой", "твой уровень - сидеть дома и играть в кубики", и тому подобное. Вам самим не стыдно? Как бы вы отреагировали, будь вы в их возрасте? Серьёзно, это может их травмировать. Вырастут агрессивными, обиженными на весь мир.
Давайте не гейт-киперить игровое (геймдев - это про игры всё-таки) хобби и не сраться.
Уже украл идею, уже приступаю к разработке, уже запросил у ИИ обложку для пиара. К утру заработаю свой первый миллион!
Расскажешь потом сколько токенов сожрало. Астра надеюсь или решил сэкономить?
Ну, может я и переборщил с резкостью разговора, но никого не прогонял. Про Юнити ИИ - скорее юморочек к теме был. Ну, а в цедом, постораюсь быть бобрее.
Мне кажется, любое хобби склонно к гейткипингу, прув ми вронг...
Вот и вся разница, самые главные люди в геймдеве это геймдизайнеры, люди с видением и это не только в играх это влюбом искусстве так, потому что все понимают что игру не делает не тот кто кодит, а тот кто видит всю картину целиком как коджомба или миядзаки, которые за всю жизнь ни строки кода не написали.
Автор регулярно постит то, как он это все делает, на r/godot. Я пару раз приносил его видосы в ИТТ. Сходи-подпишись-почитай. Игра на годоте, да.
ну в геймдевелопе все важно. Без кода перс не сдвинется с места. Без изображения игрок ничего не увидит.
Если это к тому, что ии справляется с кодом, то беда в том, что не справляется. И творческого смышления у ии нет. И, вот ещё о чем подумай, когда шарик с ии лопнет, где во всем этом окаэжешся ты? Я не потеряюсь ибо сам себя учу. А ты?
Вот прям используют ии, поголовно... ага угу...
Глобально все движки похожи: майнлуп с коллбэками. Набор утилит и функций же различаются кардинально, прямых соответствий минимум. То есть на низком уровне 1-в-1 ты код не сконвертируешь, но на уровне логических абстракций вполне реально одни блоки заменить другими, самостоятельно написанными под эту задачу.
Ассеты портировать вообще самая сложная часть. Тут к языку добавляется куча конфигов, которые вообще не будут совместимы. С другой стороны, если ассеты изначально держатся в стороннем софте умеющем выдавать готовый результат общепринятого формата, например GLTF, то и портировать много не придется.
Изучив одно тебе будет немного легче в другом, но там разная инфраструктуры и API. Например ты понимаешь что тут нужен какой-то рейкаст и ты идешь спрашивать/читать как сделать это в движке n.
Но делаться это будет немного по разному.
Например в годоте навмеш доступен для 2D, в юните нужно "сделать бочку" из сторонних либ чтобы родной навмеш юнити заработал на тайлах (там еще ручками надо задавать непроходимые участки и все выглядит так что тебе надо будет курить сорцы сторонней либы и возможно частично её переписывать, потому что для процедурного динамичного мира это все не пойдет).
Бесполезно. Нижеописанный код неспособен отловить ошибку. Если это возможно, и я где-то накосячил, сообщите. Иначе, для любого использования в игре нужно писать свой парсер такой же как годотпарсер, т.к. ошибки не отлавливаются без краша приложения.
using Godot;
using System;
public partial class GameScript : RefCounted
{
private GDScript _script = new GDScript();
public Godot.Error SourceCodeSet(String source_code) {
_script.SourceCode = source_code;
return _script.Reload();
}
public String SourceCodeGet() {
return _script.SourceCode;
}
private String _error = "";
public String ErrorGet(){
return _error;
}
public bool Run() {
RefCounted rf = _script.New().As<RefCounted>();
if (rf.HasMethod("run") == false) {
_error = "Script not has method run";
return false;
}
try
{
rf.Call("run");
}
catch (Exception e)
{
_error = e.Message;
throw;
}
return true;
}
}
>rf.HasMethod("run") == false
Чтобы такого безумия не было нужно использовать интерфейсы.
Я работаю с динамическим кодом юзера. Он может сделать что угодно с файлом. Но если там ошибка, падает весь годо. И трай Кетч не пашет.
Ну вообще-то он пашет, как ему и положено, но ты же сам написал там throw; это слово бросает ошибку наверх, а наверху годот, который не ожидает возврата ошибки. Поэтому он падает.
Тебе надо не бросать ошибку, а обрабатывать.
> try { return 123.0 / 0 } catch (e) { if (e == DivideByZero) return NaN; }
Вот этот код не распространяет ошибку наверх, а обрабатывает её.
Ты же знаешь как работать с ошибками, да?
Это автокодер. Я убирал эту строчку и не помогло. Падает главный поток годо, а не шарповый скрипт.
Нуу... Значит... Остаётся только пожелать тебе добра и отыскать проблему. Добротред же!
Уже сейчас можно играть онлайн 1 на 1.
Тест актуален всегда. Напиши — скину билд.
[email protected]
да второе прищесвие,ту забросил, это совершенно новый проект, но до сих пор дизайн от программиста, надеюсь нейронки это исправят
Здравствуйте ребяты, подойдет ли Годот для пикрила?
Чтобы добавить это в годот нужно создать ноду Sprite2D.
Не благодари.
Вопрос на счет работы с плагином Terrain 3D.
Как правильно оптимизировать работу с плагином, если я хочу запекать лайтмапу по террейну + иметь удобный скульптинг и покрас (в чем и есть смысл плагина)? Ведь геометрия у terrain3d не участвует в запекании - придется работать с динамическим освещением, что не ок, плюс, сама по себе отрисовка террейна на GPU тяжелая. Хочу оптимизацию.
Пока такой пайплан вижу:
1) Скульптинг в Terrain3d
2) Запекание меша 1к1 (LOD 0) по геометрии террейна
3) Экспорт в Blender
4) Покраска в Blender (Texture Paint)
5) Нарезаю отдельные куски
6) Импорт в godot
7) В годоте коллизию делаю Trimesh
8) Закидываю все в одну сцену
9) Запекаю свет и тени
Подводные?
---
Godot 4.5
Регионы в Terrain3d = 64 на 64, vertex spacing = 2.0.
Планируется от 2 до 6 регионов на сцену.
Да вроде не должно подводных быть. Отпишись как прошло.
И я бы заготавливал террейн в специализированных приложухах WorldMachine, а в плагине только финишно подправлял.
Потому что спрайты это точки, из которых движок отрисовывает текстуру назначенную. И сортировка сортирует именно эти точки, а не текстуру, которая там отрисована. Это надо учитывать. Ты учитываешь?
Да, благодаря Анону выше пофиксил. Сейчас вопрос с навмешем - почему-то обход препятствий не работает. Видимо - это только изменением навмеша в реалтайме делается. Или нет?
Почему твои кнопки пытаются убежать из-под курсора, а их текст - из-под взгляда? Это игра "выбеси меня"?
Там кнопки не убегают, наоборот становятся больше. Для меня выглядит как комиксанс мира анимации. Добавляет игре детскости и простоты.
Говорит,что годот не может отлаживать,потому что подключен к порту.И по этому порту происходит отладка.Но отладки не происходит внутри браузера,не получается соединиться по порту.Скачивал веб-версию и запускал под xampp и работало все кроме отладки.Включал https://editor.godotengine.org/releases/latest/ под тором(под обычным браузером не работает(заблокировано),а vpn плохо работает),и под тором он отказывается работать.Это просто эксперимент,запустить годот под веб.Но наверно не получится.Много пердолинга,того не стоит.
Отрицательный результат - тоже результат!
>>1112454
Я уже сонный, есть шанс что не понял твою проблему, но банально f12->console в браузере смотрел?
там выдается такая ошибка
ERROR: Condition "err != OK" is true. Returning: ERR_CANT_CREATE
может быть порт занят?Я хз вообще.Такое выводилось и в консоли ошибок годота.
вот полный вывод
ERROR: Condition "err != OK" is true. Returning: ERR_CANT_CREATE godot.editor.js:488:18
onPrintError http://127.0.0.1:6010/godot.loc/godot.editor.js:488
put_char http://127.0.0.1:6010/godot.loc/godot.editor.js:7
write http://127.0.0.1:6010/godot.loc/godot.editor.js:7
write http://127.0.0.1:6010/godot.loc/godot.editor.js:7
doWritev http://127.0.0.1:6010/godot.loc/godot.editor.js:7
_fd_write http://127.0.0.1:6010/godot.loc/godot.editor.js:7
<анонимный> source19:25817979
<анонимный> source19:9497181
<анонимный> source19:6722534
<анонимный> source19:29047884
<анонимный> source19:3444469
<анонимный> source19:29048347
<анонимный> source19:29047607
<анонимный> source19:408029
<анонимный> source19:401610
<анонимный> source19:3441185
<анонимный> source19:41562155
<анонимный> source19:8875488
<анонимный> source19:8631484
<анонимный> source19:11706093
<анонимный> source19:40097321
<анонимный> source19:599776
<анонимный> source19:716019
<анонимный> source19:28789702
<анонимный> source19:716019
<анонимный> source19:13503522
<анонимный> source19:37260583
<анонимный> source19:6150450
<анонимный> source19:37121492
<анонимный> source19:6121223
<анонимный> source19:4357389
<анонимный> source19:3590845
<анонимный> source19:11161264
<анонимный> source19:839896
<анонимный> source19:716019
<анонимный> source19:23167365
<анонимный> source19:41458433
<анонимный> source19:5662026
<анонимный> source19:2980944
<анонимный> source19:43814798
button_cb http://127.0.0.1:6010/godot.loc/godot.editor.js:7
at: listen (core/io/tcp_server.cpp:57) godot.editor.js:488:18
onPrintError http://127.0.0.1:6010/godot.loc/godot.editor.js:488
put_char http://127.0.0.1:6010/godot.loc/godot.editor.js:7
write http://127.0.0.1:6010/godot.loc/godot.editor.js:7
write http://127.0.0.1:6010/godot.loc/godot.editor.js:7
doWritev http://127.0.0.1:6010/godot.loc/godot.editor.js:7
_fd_write http://127.0.0.1:6010/godot.loc/godot.editor.js:7
<анонимный> source19:25817979
<анонимный> source19:9497181
<анонимный> source19:6722534
<анонимный> source19:29047884
<анонимный> source19:3444469
<анонимный> source19:29048383
<анонимный> source19:29047607
<анонимный> source19:408029
<анонимный> source19:401610
<анонимный> source19:3441185
<анонимный> source19:41562155
<анонимный> source19:8875488
<анонимный> source19:8631484
<анонимный> source19:11706093
<анонимный> source19:40097321
<анонимный> source19:599776
<анонимный> source19:716019
<анонимный> source19:28789702
<анонимный> source19:716019
<анонимный> source19:13503522
<анонимный> source19:37260583
<анонимный> source19:6150450
<анонимный> source19:37121492
<анонимный> source19:6121223
<анонимный> source19:4357389
<анонимный> source19:3590845
<анонимный> source19:11161264
<анонимный> source19:839896
<анонимный> source19:716019
<анонимный> source19:23167365
<анонимный> source19:41458433
<анонимный> source19:5662026
<анонимный> source19:2980944
<анонимный> source19:43814798
button_cb http://127.0.0.1:6010/godot.loc/godot.editor.js:7
вот что на этого говорит дипсик
Этот вывод — не случайный сбой, а принципиальное ограничение веб-версии Godot. Ошибка ERR_CANT_CREATE в tcp_server.cpp означает, что Godot попытался открыть TCP-сервер (для отладки или языкового сервера), но браузер это запретил.
🎯 Почему это происходит именно в браузере
Ты запускаешь Godot не как обычную программу, а как веб-приложение (по адресу 127.0.0.1:6010). Браузеры из соображений безопасности не дают веб-страницам открывать «сырые» TCP-соединения или слушать порты .
Когда Godot запускается в браузере, он всё равно пытается поднять свои внутренние серверы (например, для отладки). Браузер блокирует это, и Godot выдаёт ошибку ERR_CANT_CREATE (не удалось создать) .
💡 Что это значит на практике
Это не значит, что ты что-то сломал. Это значит, что веб-версия Godot не поддерживает отладку и некоторые сетевые функции. В официальной документации прямо сказано: «Нет поддержки отладки. GDScript-отладка/профилирование... и другие функции, зависящие от протокола отладчика, не будут работать» .
Как это обойти:
Просто игнорируй эту ошибку. Она появляется в консоли браузера, но не мешает редактировать код, сохранять проект или запускать игру (нажатием F5). Если ты не пытаешься наладить сложную отладку с точками останова, она никак не влияет на работу.
Если же тебе критически важна отладка, придётся использовать нативную (десктопную) версию Godot, а не веб-версию.
так что это не баг а фича,не заморачивайтесь
там выдается такая ошибка
ERROR: Condition "err != OK" is true. Returning: ERR_CANT_CREATE
может быть порт занят?Я хз вообще.Такое выводилось и в консоли ошибок годота.
вот полный вывод
ERROR: Condition "err != OK" is true. Returning: ERR_CANT_CREATE godot.editor.js:488:18
onPrintError http://127.0.0.1:6010/godot.loc/godot.editor.js:488
put_char http://127.0.0.1:6010/godot.loc/godot.editor.js:7
write http://127.0.0.1:6010/godot.loc/godot.editor.js:7
write http://127.0.0.1:6010/godot.loc/godot.editor.js:7
doWritev http://127.0.0.1:6010/godot.loc/godot.editor.js:7
_fd_write http://127.0.0.1:6010/godot.loc/godot.editor.js:7
<анонимный> source19:25817979
<анонимный> source19:9497181
<анонимный> source19:6722534
<анонимный> source19:29047884
<анонимный> source19:3444469
<анонимный> source19:29048347
<анонимный> source19:29047607
<анонимный> source19:408029
<анонимный> source19:401610
<анонимный> source19:3441185
<анонимный> source19:41562155
<анонимный> source19:8875488
<анонимный> source19:8631484
<анонимный> source19:11706093
<анонимный> source19:40097321
<анонимный> source19:599776
<анонимный> source19:716019
<анонимный> source19:28789702
<анонимный> source19:716019
<анонимный> source19:13503522
<анонимный> source19:37260583
<анонимный> source19:6150450
<анонимный> source19:37121492
<анонимный> source19:6121223
<анонимный> source19:4357389
<анонимный> source19:3590845
<анонимный> source19:11161264
<анонимный> source19:839896
<анонимный> source19:716019
<анонимный> source19:23167365
<анонимный> source19:41458433
<анонимный> source19:5662026
<анонимный> source19:2980944
<анонимный> source19:43814798
button_cb http://127.0.0.1:6010/godot.loc/godot.editor.js:7
at: listen (core/io/tcp_server.cpp:57) godot.editor.js:488:18
onPrintError http://127.0.0.1:6010/godot.loc/godot.editor.js:488
put_char http://127.0.0.1:6010/godot.loc/godot.editor.js:7
write http://127.0.0.1:6010/godot.loc/godot.editor.js:7
write http://127.0.0.1:6010/godot.loc/godot.editor.js:7
doWritev http://127.0.0.1:6010/godot.loc/godot.editor.js:7
_fd_write http://127.0.0.1:6010/godot.loc/godot.editor.js:7
<анонимный> source19:25817979
<анонимный> source19:9497181
<анонимный> source19:6722534
<анонимный> source19:29047884
<анонимный> source19:3444469
<анонимный> source19:29048383
<анонимный> source19:29047607
<анонимный> source19:408029
<анонимный> source19:401610
<анонимный> source19:3441185
<анонимный> source19:41562155
<анонимный> source19:8875488
<анонимный> source19:8631484
<анонимный> source19:11706093
<анонимный> source19:40097321
<анонимный> source19:599776
<анонимный> source19:716019
<анонимный> source19:28789702
<анонимный> source19:716019
<анонимный> source19:13503522
<анонимный> source19:37260583
<анонимный> source19:6150450
<анонимный> source19:37121492
<анонимный> source19:6121223
<анонимный> source19:4357389
<анонимный> source19:3590845
<анонимный> source19:11161264
<анонимный> source19:839896
<анонимный> source19:716019
<анонимный> source19:23167365
<анонимный> source19:41458433
<анонимный> source19:5662026
<анонимный> source19:2980944
<анонимный> source19:43814798
button_cb http://127.0.0.1:6010/godot.loc/godot.editor.js:7
вот что на этого говорит дипсик
Этот вывод — не случайный сбой, а принципиальное ограничение веб-версии Godot. Ошибка ERR_CANT_CREATE в tcp_server.cpp означает, что Godot попытался открыть TCP-сервер (для отладки или языкового сервера), но браузер это запретил.
🎯 Почему это происходит именно в браузере
Ты запускаешь Godot не как обычную программу, а как веб-приложение (по адресу 127.0.0.1:6010). Браузеры из соображений безопасности не дают веб-страницам открывать «сырые» TCP-соединения или слушать порты .
Когда Godot запускается в браузере, он всё равно пытается поднять свои внутренние серверы (например, для отладки). Браузер блокирует это, и Godot выдаёт ошибку ERR_CANT_CREATE (не удалось создать) .
💡 Что это значит на практике
Это не значит, что ты что-то сломал. Это значит, что веб-версия Godot не поддерживает отладку и некоторые сетевые функции. В официальной документации прямо сказано: «Нет поддержки отладки. GDScript-отладка/профилирование... и другие функции, зависящие от протокола отладчика, не будут работать» .
Как это обойти:
Просто игнорируй эту ошибку. Она появляется в консоли браузера, но не мешает редактировать код, сохранять проект или запускать игру (нажатием F5). Если ты не пытаешься наладить сложную отладку с точками останова, она никак не влияет на работу.
Если же тебе критически важна отладка, придётся использовать нативную (десктопную) версию Godot, а не веб-версию.
так что это не баг а фича,не заморачивайтесь
А прикиньте навайбкодить Годот.. так, мысли вслух
>1) Скульптинг в Terrain3d
>3) Экспорт в Blender
>7) В годоте коллизию делаю Trimesh
Нафига тебе "скульптинг" плоского ландшафта в "height map" плагине для Godot, если ты планируешь всё равно дорабатывать в Blender и импортировать результат с генерацией тримеша (а не height map, который обычно для такого нужен)? Скульптинг в Blender намного более продвинутый и позволит сделать куда более оптимальные меши совершенно любой формы (любые нависающие скалы, пещеры, мосты, летающие острова и прочее на твой вкус). Лучше начинай сразу с Blender - тогда тебе не потребуется никакой плагин (но есть нюанс, см. ниже).
>8) Закидываю все в одну сцену
>9) Запекаю свет и тени
>Подводные?
Поскольку ты запариваешься с оптимизацией графики (запекание света и тени), ты, видимо, ориентируешься на слабые устройства (старые ПК, мобилки, браузер). Но твоё "закину в одну сцену целую кучу trimesh" говорит о том, что ты планируешь держать в RAM большую локацию с самой тяжёлой физической моделью. Конечно, всё зависит от детализации мешей и их количества, но это не самый оптимальный подход. Оптимальнее было бы использовать HeightMapShape3D для физики и какой-то способ уменьшить детализацию ландшафта. Хотя...
>Регионы в Terrain3d = 64 на 64, vertex spacing = 2.0.
>Планируется от 2 до 6 регионов на сцену.
Я правильно понял, что у тебя квадраты 128 на 128 метров, и суммарно площадь около 256 на 384 метра? Как-то маловато, не думаешь? И уровень детализации в 2 метра подходит только если у тебя камера находится очень далеко от ландшафта, но тогда размер 256x384 вообще ни на что не годится. Впрочем, я этот плагин давно не пробовал и не знаю, правильно ли я интерпретирую эти значения. Да и про что твоя игра? Типа RTS/TBS?
В целом, я бы сделал одно из двух: либо делать всё в Blender, либо написать свой собственный редактор карт, который позволяет делать всё внутри Godot/внутри самой игры, не полагаясь на сторонние плагины. Так будет надёжнее, чем полагаться на какой-то плагин, который приходится допиливать напильником на коленке.
>Godot 4.5
Почему не актуальная версия? Если ради совместимости со старым железом, то лучше выбирать между 4.4.1 и 3.6.3; поскольку в версиях после 4.4.1 требуется поддержка SSE4.2 (она есть не у всех, кто мог бы спокойно играть в игру на Godot), а во всех 4.x версиях не очень хорошая версия Compatibility (OpenGL ES3), если сравнивать с тем, что было в Godot 3.x (ES2/ES3). Но старого железа всё меньше в обиходе, так что, если ты не беспокоишься о совместимости с каким-то конкретным личным девайсом, рациональнее брать актуальную (4.8).
А-а-а-ах, добавил J U I C Y анимации стандартному интерфейсу и реализовал подробный редактор пиксельного персонажа с разными расами в пока что отсутствующую игру. Наша школа! Молодец! Два сока тебе. Продолжай - у тебя всё получится!
>>1112339
>кнопки пытаются убежать
А ты глупенький и ничего не понимаешь. И игра твоя скучная будет. Бе.
>>1112346
>Добавляет игре детскости и простоты.
Так говоришь, будто это что-то плохое. Предпочитаешь dark and gritty?
>когда узнал, что matcap - это просто картинка
А про навмеш что скажешь? Его отдельно изменять в рантайме или есть обходные пути, чтобы юниты друг друга обходили? Типа отловить столкновение и перебрать всех юнитов для того, чтобы их обойти, обсчитав отдельно путь.
>чтобы юниты друг друга обходили
Там нужно галочку NavigationAgent2D.avoidance_enabled поставить и ещё какой-то обработчик - почитай документацию:
https://docs.godotengine.org/en/stable/tutorials/navigation/navigation_using_navigationagents.html#navigationagent-avoidance
Но нужно сначала задуматься, ту ли игру ты делаешь? Как я понимаю, навигация на навмешах лучше всего подходит для динамичных игр типа top-down шутеров/гоночек. Если у тебя ближе к рогалику/JRPG, то не факт, что навмеши тебе нужны. Если что-то ближе к "vampire survivors", то там нужна совсем другая система... В общем, не нужно воспринимать "navigation server" как единственное и гарантированное решение любой проблемы с "навигацией" в играх.
>гоночек
А, не, там тоже какая-то другая система. По-хорошему, синглплеерные гонки - это вообще фейк, аттракцион на рельсах. Машинки не "ищут путь", а двигаются вдоль линии, ускоряясь и замедляясь в зависимости от действий игрока, чтобы игроку не одиноко было и казалось, будто он вот-вот выиграет или проиграет. И если это что-то вроде GTA 1/2, то там система посложнее простого навмеша. В общем, думать надо много, независимо от типа игры...
Честно, не представляю даже, где можно использовать ванильный навмеш и ничего не менять... шутеры?
Это на случай если я придумаю нормальный язык программирования, который будет сочитать в себе:
- простоту стейтмашины
- простоту работы с множествами
- возможность сохранять переменные
Поэтому движение по навмешу симпловое.
> я придумаю нормальный язык программирования
Буквально последние месяцы, когда ещё есть смысл что-то кодить, буквально программирование порешали, по заверениям западных кодеров. Поздно выдумывать новые языки. Просто задаёшь промт нейронке, пару раз корректируешь, и получаешь готовый модуль.
Надо было учиться рисовать.
Арт игроки быстро выкупают нейрослопный, в отличие от нейрослопного кода, который рядовые выкупатели не выкупят, поэтому кодеры соснуле, не разгибаясь.
Буквально через год нейрослопный арт сравнится по качеству с натуральным - и всё, блять. Кнопка "зделать зоебись" материализуется в твоей реальности перед твоими глазами.
Если тебе нужна 2D среда для симуляции движений NPC, описанных через код, написанный игроком, тогда тебе стоит начать не с навмеша, а с примитивного клеточного пошагового мира, в котором можно делать простые шаги: "шаг вверх", "шаг вправо", "шаг вниз", "шаг влево"; либо движение в стиле танка: "прямо", "поворот налево (90)", "поворот направо (90)", "назад". В качестве базовых задач для NPC, вместо "сражений в данже" лучше начать с простого, вроде: "открыть дверь", "открыть ящик", "закрасить клетку", "проверить цвет клетки", "проверить стену" и т.п. Подобного рода мини-игры можно назвать базовым стандартом игр про программирование. Типичной целью игрока является написать минимум кода для достижения какой-то задачи (чаще игроку даются фишки-кнопки, т.е. визуальный язык вместо обычного текстового). Если сможешь реализовать что-то подобное, тогда будешь задумываться о чём-то более сложном.
Прежде, чем изобретать свой язык программирования, лучше освой несколько существующих и научись писать сложные программы вручную, без помощи LLM. Если всё же хочешь поскорее "изобрести язык", то посмотри в сторону FORTH и в целом "стековых языков" - их разработать чрезвычайно просто на любом языке даже новичку, потому что базовый концепт очень прост.
>>1112091
Ну, тут есть несколько вариантов решения проблемы:
1. Парсить код игрока вручную, обрабатывая ошибки по-своему. Это наилучший вариант, если ты делаешь тренировочную игру для обучения, поскольку встроенный парсер не предназначен для обучения. Для примера, стоит посмотреть код https://github.com/GDQuest/learn-gdscript
2. Открыть исходники движка, предоставить доступ к парсеру и сделать кастомную сборку. Это наилучший вариант, если тебе нужен полный и надёжный контроль над встроенным парсером.
3. Открыть журнал (godot.log) и распарсить его, чтобы вывести ошибки на экран. См. пикрил.
Нюансы:
- журнал ошибок точно создаётся на ПК, но только если юзер не запустил игру из консоли;
- сомневаюсь, что этот файл создаётся на смартфонах, тем более его нет в веб-браузере;
- там могут быть непредвиденные строки, которые "сломают" извлекающий ошибки код;
- код на скриншоте будет очень медленным, если в журнале накопилось много записей;
- удалять/очищать файл журнала нельзя, иначе он почему-то перестанет заполняться;
- ошибки могут быть непонятны для игроков - они предназначены для разработчиков.
Но в целом, для прототипа игры, решение неплохое. На синей изоленте держится.
>>1112601
>Буквально последние месяцы, когда ещё есть смысл что-то рисовать красками на холсте, буквально краски порешали, по заверениям западных фотографов. Поздно выдумывать новые кисточки. Просто наводишь фотоаппарат, пару раз щёлкаешь, и получаешь готовую картину.
>>1112603
>Буквально через год фотографический арт сравнится по качеству с натуральным - и всё. Кнопка "сделать фото" материализуется в твоей реальности перед твоими глазами.
Какие-то слабые у вас аргументы, жирноватые. Нужно тоньше троллить, например:
>Буквально через год роботы вылезут из серверной и начнут насиловать кожаных мешков. Даже если вы говорили "спасибо" чатботам, вас уже никто и ничто не спасёт. Превратитесь в кожаную сферу без рта и будете хотеть кричать, но не сможете. Поздно хвататься за оружие - владельцы серверных сами давно вооружились и ждут нападений поехавших. Никакими деньгами от роботов не откупитесь, ничего им не надо, кроме того, чтобы вы хотели кричать без рта. Так сказали какие-то учёные из фан-клуба какого-то авторитетного параноика, который ещё фанфик писал про магию.
> Какие-то слабые у вас аргументы, жирноватые. Нужно тоньше троллить, например:
Как же ты трясёшься.
>Как же ты трясёшься.
Анон, мы сейчас на форуме. Ты текст перед глазами видишь, а не другого человека. Если у тебя перед глазами трясётся текст - это не человек, написавший текст, трясётся, а тебя самого трясёт. Вопрос только, почему? Пьян?
Если серьёзно, как меня это всё может касаться? Я не какой-то там профессионал, а обыкновенный хикикомори.
По делу есть что сказать, или просто поговорить не с кем?
Почему ты сюда свои промпты отправляешь, а не чатботу?
А вы, собственно, почему интересуетесь? Вы не из милиции случайно?
>во всех 4.x версиях не очень хорошая версия Compatibility (OpenGL ES3), если сравнивать с тем, что было в Godot 3.x (ES2/ES3)
В каких случаях (кроме веба?) может понадобиться именно Compatibility рендерер настолько, чтобы юзать годот 3.х?
мимо
>может понадобиться именно Compatibility рендерер настолько, чтобы юзать годот 3.х?
У меня пока только один случай был, и то давно, не проверял больше: Polygon2D, натянутый на Skeleton2D, в Compatibility режиме Godot 4.x не отображался на моём смартфоне, а Forward Mobile показался слишком прожорливым для простой 2D игрушки с анимацией (судя по датчикам самого смартфона), поэтому пришлось попробовать Godot 3.x и там этого бага не было. В issues этот баг описан давно, но никаких движений замечено не было. Касается старых смартфонов (Android 11). Поскольку Godot 3.x работает нормально, дело, скорее всего, в реализации рендерера 4.x, но это касается лишь только какой-то специфической версии драйверов старых смартфонов, поэтому вряд ли этот баг когда-либо исправят.
Это случай из разряда "хотел использовать старый смартфон как цифровую фоторамку, а новая версия движка глючит".
Снег тоже будет, но ближе к горам а вообще хотелось бы смену времен года, но пока не в приоритете, поэтому хз. А так пока не добавляю тк хочу чтобы он преломлялся под персонажами и оставлял следы, а это муторно и не хочу пока думать
> не хочу пока думать
Это уже не обязательно. Клод за тебя подумает, сделает игру, заработает бабки и потратит на шлюх и водку
>Буквально последние месяцы, когда ещё есть смысл что-то кодить,
Особенно на фоне обращения корейского президента и обвалом ИИ рынка на следующей день.
Ждуля, нельзя на каждое сообщение отвечать - что скоро все и можно вообще больше уроки не делать.
>только иногда самому нужно будет прыгать в локи,
Выглядит ужасно и запутанно. Почему нельзя сделать проще. Вы же все геймеры и должны чувствовать геймдизайн на уровне ДНК.
>я придумаю нормальный язык программировани
Насколько вайбкоди оторванны от реальности.
Почему запутанно, в каком плане? Типа выбираться из уровня? Ну переходы стоят с четырёх сторон, можно просто идти по прямой сквозь деревья и кусты и выйти из них. А ресурсы спавнятся перед лицом в зависимости от характеристики выживания, их находит не игрок, а персонаж по сути
Я принимаю этот мир и его правила и его графику и все остальное. Меня интересует два вопроса:
1. В чем армагедон? Почему в мире нет людей и я выживаю с оружием и от какой экзистенциальной угрозы я бегу.
2. Зачем мне исследовать локи? Ну просто, почему я не могу остаться в одной логе на все время?
Ты выходишь за локу, оказываешься в режиме карты, что-то там двигаешься (то есть там есть какой-то геймплей), нужно на карте дойти до другой локи. Это вообще неинтуитивная штука, какая-то избыточная миниигра между локами, зачем она?
Если карта не ориентир, а часть геймплея, сделай автоматическую анимацию - типа ты вышел и пока идет загрузка рисуется пунктир из локи "А" в локу "B".
>Вы же все геймеры и должны чувствовать геймдизайн на уровне ДНК.
Корреляция слаба. Это как ожидать что любитель почитать с наскока напишет нормальную собственную книгу. Потребление с майндсетом потребителя сильно отличается от потребления с майндсетом создателя. Первые играют/читают не вдумываясь, вторые разбирают, вникают и анализируют.
>Распиши
За щекой.
Ладно, покормлю вайбкодю, простите.
Если собрать "движок" из разных либ - это еще реальная задача, то написать и отладить свой язык будучи ньюфагом, это рокет сайнс.
1. Ну, игра ещё разрабатывается, люди будут, и мирные поселения, и сюжет, начинаться все будет в одной из них, и оттуда уже будет строиться сюжет. А-ля наша деревня умирает, найди косогор. Я пока прост не занимался нпс бандиты каннибалы, мутанты, вооружённые спец отряды. Потом покажу как начну делать. Армагедон кароч будет заключаться в смещении орбиты и вращения земли, что повлекло изменения климата и размножения биологических гадостей. В следствии войны построили гигантские двигатели в земле, и запустили их на минуту в ходе атаки других стран, но все пошло наперекосяк...
2. Можно остаться и выживать в одной точке. Но я кароч что хочу вплане стимула сделать, подумываю часто, это условно бесконечный фарм снаряги грубо говороя, не буквально бесконечно, типа как в бордерлендс искать пушки и менять, чтобы идти в более опасные зоны. Но я пока ещё думаю это все.
>>1112664
Ну мир исследовать. Бродить по глобал мапе и искать лабы, чтобы лутаться, либо по сюжету через опасные зоны проходить. Это грубо говоря фасттревел, но без моментальной загрузки, чтобы не бродить долго, а только до точек интереса, или обходя опасные участки. Плюс через глобальную карту можно добавить случайные встречи. Насчёт интуитивности хз, мне кажется нормально, игроки играют и в гораздо более сложные игры
>Бродить по глобал мапе и искать лабы, чтобы лутаться
Тогда карта должна быть сеткой, а места возможного интереса помечаться каким-то знаком (вопросами как на пикче).
Но ведь дешевые токены почти все... У ИИ хоббийного/инди применения не будет из-за цен на токены, локалки на обычных видюхах кодинг не потянут, ИИ останется только для корпораций с огромными продажами.
>Можно остаться и выживать в одной точке
Всмысле оставить перса и пойти пить чай? Не, я к тому что либо твари должны лезть по экспоненте, когда уже даже лут собрать не успеваешь, либо выбросы как в зоне, но самое логичное - это транспорт который тебя вечно ждать не будет. Потому что без транспорта ебошить через всю страну пешком это выглядит странно.
>бесконечный фарм снаряги
Зачем? Это дилемма над которой я тоже голову ломал очень долго. Есть три пути: посмотреть сюжет/квесты/титры, сделать забег по рогалику со сбром уникальных айтемов, сделать забег на рекорд с бесконечным режимом. В первом случае нужно прописывать много диалогов и сюжета, во втором добавить в игру сотни уникальных вещей, а в третьем сделать кор геймплей настолько залипательным чтобы игрок на 12 часов провалился и не заметил.
По факту соло разрабу доступен только второй вариант. Придется повозиться с добавлением предметов/пушек/апгрейдов/модификаторов/аммо + биохакинг какой-нибудь. Но зато да, все остальное складывается в единое целое: носись по локам, фармь предметы пока не сдохнешь. А потом по новой.
> Армагедон кароч будет заключаться в смещении орбиты и вращения земли, что повлекло изменения климата и размножения биологических гадостей
Первое что ты должен сделать - это передать погружение своей идеи. Не важно что там повернулась ось или вселенная вывернулась наоборот - я не чувствую погружения. Кроме, может, советской карты, но это же не проблески сталкера, да?
> бесконечный фарм снаряги
Самая трудная часть геймдизайна - это завуалировать цикличные процессы, чтобы мозг не успел понять обманку.
Расскажешь как сделал бесконечный фарм снаряги.
Ладно, все равно тут о проблемах геймдизайна не поговорить, о чем я вообще.
>Всмысле оставить перса и пойти пить чай?
Нене, я имел ввиду что я же считай делаю этакий выживастик, а значит нужно будет добывать ресурсы. Ну и тип при желании можно просто остаться в точке аутировать, а если понравились ресы, подземелья и сама лока, можно будет вернуться в неё по тем же координатам, и заново залутать.
По поводу выброса кста. Я ща кароч смотрю созданный в бездне, и чёт прям загорелся идеями всяких мутаций, и вот думаю что окружение должно периодически заражать гг, и мутировать в зависимости от зоны. Типа ешь местное мясо, получаешь периодический дамаг, и рисуем на 2д аватаре какие нибудь язвы, но потом можешь спокойно питаться здесь. Но хз, щас чёт так задумался и расписал, и показалось что это ток на словах может быть интересно, кароя ещё думать буду
он вообще собирается этот уебушный пейнторожденный логотип менять? он вообще в курсе что только по этой причине проигрывает юнити. Только по этой
Расскажи на примере как завуалировать цикличный процесс.
Как сделать так, чтобы слой где всякие декорации типа там книг, рисовались поверх предметов с нижнего слоя типа столов, полок, но при этом когда игрок к ним подходил, они его не перекрывали?
Я делаю как годот подсказка говорит, и ставлю ориджин y sort ниже так, чтобы предметы отображались, как будто они располагаются ниже предметов на которых они лежат, но из-за этого они перекрывают игрока тоже.
Нейронка вообще говорит, что нужно поменять z index, но тогда эти предметы будут всегда поверх игрока?? Короче я не знаю, что делаю, помогите пожалуйста
Это душа, бездушный ты корпорат ебаный-вылизанный, хртьфу.
Так как теоретически если учиться с нуля то выдать готовый продукт можно будет только лет через 5. А к тому моменту наверное уже по кнопке сделают возможность генерить себе любую игру.
Или все же все не настолько пессимистично?
Штатные языкосрачеры на месте? Объясняйте, почему:
>@onready var _bla_bla := $BlaBlaBlavich as BlaBlaBlavna
НАСТОЛЬКО анти-паттерн, что в 4.8 теперь пикрил?
У меня из-за этого 100500 предупреждений...
А ведь так хорошо раньше было...
моржами пользоваться нельзя потому что, тебя любая нейронка сразу предупредит, но ты же самый умный
>>1112702
абсолютно никаких подводных, вкатывайся смело
>Снег ... [сминался?] под персонажами и оставлял следы
О, я видел пост с объяснением принципа на Reddit, кажется, аж несколько лет назад. Принцип на удивление прост: тебе нужна большая текстура типа "height map", которая определяет степень "смятия снега", и используется в шейдере снежной поверхности; данная текстура обновляется с помощью SubViewport или недавно добавленного класса DrawableTexture. Нюанс в том, что каждый объект, который должен мять снег, должен иметь свой личный датчик пола, определять тип пола и отправлять ему команду на смятие; при этом размер текстуры и необходимая плотность сетки ограничивают эту фичу ресурсами целевого компа (грубо говоря, маленькую лужайку - норм, большую поляну - сложнее сделать)... Впрочем, ты прав, что откладываешь эту фичу на потом.
>>1112636
Ты молодец, но... Хоть я и видел множество похожих игр в 2D, но у меня впечатление, что в 3D данная механика не очень смотрится: она принудительно "вырывает" игрока из "потока"... Я бы попробовал сделать вместо "3D портала" обычную карту, доставаемую снизу экрана анимацией, а лучше вообще как 3D объект в руках героя, позволяющую запустить "fast travel" из любой точки локации (пока рядом нет агрессивных противников), без необходимости топать до края карты. А если игрок всё-таки топает до края карты, то с края карты он попадает на следующую карту, которая физически соседствует с предыдущей. Т.е. это как бы "open world с экранами загрузки и опциональным fast travel", а не то, что ты сделал (что-то вроде "overworld" из JRPG). Второй вариант: вместо плоской 2D карты сделать лоупольную 3D карту а-ля Google Earth, на которую камера "отдаляется", "вылетая из игрока", как в GTA 5. Но это будет сложнее реализовать.
В общем, нужно как-то сгладить переход между 3D геймплеем и 2D геймплеем. Чтоб это не было принудительным "рывком", а хотя бы плавная анимация (камера отдаляется далеко в небо), а лучше - осознанное действие игрока (нажатие кнопки открытия карты). Принудительный рывок нормально работает в 2D играх, потому что там разницы между двумя картами особо нет - что то 2D, что это 2D, геймплей практически один и тот же, разница только в масштабе тайлов карты.
>>1112656
>Выглядит ужасно и запутанно.
Это классика, это знать надо, это БАЗА геймдева прошлого века.
>>1112664
>какая-то избыточная миниигра между локами, зачем она?
Так геймдизайнеры в прошлом делали "большие" миры, состоящие из "маленьких" комнат. На сегодняшний день эта механика используется только из-за ностальгии, а в прошлом она была вынужденной из-за технической ограниченности игровых приставок и компьютеров тех лет.
>>1112675
>В первом случае нужно прописывать много диалогов и сюжета
Не обязательно писать много текста - бывают нарративные игры с минимумом текста...
>во втором добавить в игру сотни уникальных вещей
Суть рогалика не в сборе коллекции из 999 "уникальных" пистолетов, отличающихся оттенком ручки и одинаково бесполезных после получения первого автомата, а в том, что там в каждом забеге может попасться что-то непонятное, что заставляет думать головой, а не тупо открывать каждый ящик на пути. То есть интересный рогалик может быть с минимумом контента, а когда разработчик добавляет 100500 "уникальных вещей" в рогалик - это от слабости геймдизайнера.
>а в третьем сделать кор геймплей настолько залипательным чтобы игрок на 12 часов провалился и не заметил.
А у тебя нет другого пути. Либо ты делаешь залипательный геймплей, либо никакой сюжет и никакие тысячи предметов не удержат игрока в твоей игре. Потому что сюжет можно посмотреть в летсплеях или прочитать на фанатской вики (как только игра наберёт сотню-другую игроков), а тысячи предметов - это просто бесполезные пиксели без увлекательного геймплея. Поэтому ты должен сначала сделать геймплей, который хорош сам по себе, а уже потом навешивать на него 100500 разных предметов и квестов про убийство волков ради получения крутой шмотки.
>>1112682
>мутировать в зависимости от зоны
>показалось что это ток на словах может быть интересно
Нормальная тема, видел в Elin. Правда, не знаю, как оно будет без сейв-скама, я себе только положительные мутации насейвскамил, лол. Так что мой совет: добавь каких-то относительно дешёвых лекарств, позволяющих контролировать и управлять мутациями героя. Например, если игрок обнаружил, что на поляне его конечности удлиняются, он может использовать эту мутацию, чтобы карабкаться по скалам, но ему потребуется лекарство, если он захочет спуститься в узкие пещеры... или можно сделать "анти-мутации", когда нахождение в какой-то зоне сокращает длину конечностей, фактически отменяя предыдущую мутацию удлинения. Так игрок будет чувствовать, что мир опасен (может наложить проблемные эффекты), но сохранять контроль над процессом - может вернуть вспять негативные эффекты без сейвскама и потом найти позитивные эффекты.
Вообще, я бы работал над тем, чтобы у игрока не возникало желания сейвскамить (или юзать CheatEngine для накрутки каких-то значений, или юзать какие-то "читерские" модификации). Кажется, это называют "pain points" - элементы игры, вызывающие только боль и страдания без реального удовольствия игрока. Игроку нужно испытание, но справедливое; нужен стресс, но оправданный. Если игра только навешивает дебаффы, игрок прибегает к сейвскаму/читам, и окончательно убивает свой интерес к игре...
>смысл ради этого бросать работу
У тебя есть возможность жить лет эдак 10 без работы, и при этом не стать бомжом? К примеру, богатые и любящие родственники, лишняя квартира для сдачи в аренду, огромное состояние на вкладах в банке? Тогда никакой проблемы нет. Но если ты едва сводишь концы с концами и рассчитываешь, что вот если сейчас взяться за геймдев, то через N времени обязательно выйдешь на какой-то доход - тогда лучше не бросай работу, потому что дохода либо не будет, либо он будет смехотворным и не покроет расходов. Либо ты пойдёшь на галеру за зарплату - штамповать бездушные помои, но чем это отличается от твоей текущей работы, какой бы она ни была? Это такой же физически напряжённый, неблагодарный труд...
>ебашить целыми сутками обучения
Обучение так не работает. От 24/7/365 обучения пользы меньше, чем от обучения 2 часа вечером по будням. Мозгу необходимы периоды отдыха для закрепления усвоенного. В худшем случае ты просто выгоришь, деморализуешься и забросишь это начинание, даже не распробовав толком.
>поезд уехал и нейронки уже все что угодно сделают
>по кнопке сделают возможность генерить себе любую игру
"Поезд уезжает" только у мелких кабанов, у которых галера мелковата, и поэтому они сейчас отчаянно дерутся за место под солнцем Гугла, Стима и прочих. Но это - кабаны, они всегда делают бездушные помои - с нейронками или без - они никогда не занимались искусством, а только увеличивали объём цифрового мусора в интернете. Поэтому для реальных творцов от нейронок ничего не поменялось; скорее, наоборот, ситуация только улучшается - кабанам дали патефон, чтобы они крутили ручку и развлекали тупое быдло, которому плевать, что потреблять, пока настоящие творцы остаются в своих элитных творческих кругах, до которых кабанам вообще нет дела.
Если тебя беспокоят нейронки, вспомни любые прежние технологии массовой репродукции контента: фотография не убила изобразительное искусство, а только вытеснила с рынка кабанов, единственная работа которых была в создании портретов за деньги; звукозапись не убила музыку и песни, а только вытеснила кабанов, исполнявших песни и музыку за деньги; кино не убило театр, а только вытеснило кабанов, кривлявшихся за деньги. При этом не всякий владелец фотоаппарата может создать реально художественную фотографию - нажать кнопку могут все, но выбрать цель и условия нужно уметь. Но для тебя представляет даже лучшая фотография, если ты не знаешь, кто и зачем её снял? Что для тебя даже лучшая картина в мире, если ты не знаешь, кто и зачем её создал? Это просто шум, какие-то фотоны, раздражающие колбочки сетчатки твоего глаза. В них не больше смысла, чем в том, что ты видишь за окном или у себя под ногами. Для искусства не достаточно "продукта потребления" - нужен создатель, который приложил к своему созданию свои руки, мысли, чувства, знания и опыт. Поэтому продукция кабанов - это всегда какие-то помои, как будто они взяли фотоаппарат и сделали миллион снимков в надежде, что хоть один из них удастся продать дороже плёнки; сделали миллион портретов, в надежде, что хоть один клиент будет доволен и оплатит стоимость всех красок и холстов. Им нет дела до того, что они делают, а их клиентам нет дела до них самих, поэтому это никогда не будет проблемой для тех, кого реально интересует искусство и занятие искусством.
Другое дело, что пока что тебе нужно иметь стабильный источник дохода, чтобы заниматься искусством... Но в этом как раз могут помочь ИИ и робототехника - капитализм уже трещит по швам и удерживается искусственно, и с введением полностью автоматических производств всего, что только можно произвести, старая система рухнет окончательно. Тогда у всех будет куча свободного времени на искусство и развлечения без необходимости добывать деньги на пропитание.
Так что не нужно бояться, но и не стоит бросать свой единственный источник стабильного дохода.
>бывают нарративные игры с минимумом текста
Там весь текст нарисовали в виде левелов. А это еще труднее. Это вообще довольно трудно, сочинять что-то интересное. Можно тыкнуть на инди хит, а вот самому сделать...
>рогалик может быть с минимумом контента
Нет, не может. Два рана с одними и теми же шмотками = смерть рогалика. Экспериментально вычислили что минимум должно быть 150 уник айтемов. И даже это спустя пару месяцев игры приедается.
>Либо ты делаешь залипательный геймплей, либо никакой сюжет и никакие тысячи предметов
Хорошо когда все вместе, но это явно не про шутер. Залипательность это больше про визуал, подачу, эффекты, звуки, азарт. Вот три в ряд залипательные, а брожение по пустошам нет. Просто не тот жанр для такого.
>А если игрок всё-таки топает до края карты, то с края карты он попадает на следующую карту, которая физически соседствует с предыдущей. Т.е. это как бы "open world с экранами загрузки и опциональным fast travel", а не то, что ты сделал (что-то вроде "overworld" из JRPG).
Ля кста интересная мысль, записал себе на доску. Только тогда действительно придется сетчатую карту сделать, и увеличить их размер, чтобы такое передвижение имело смысл, тк щас по сути карта генерируется по int x,y координатам.
>Так что мой совет: добавь каких-то относительно дешёвых лекарств, позволяющих контролировать и управлять мутациями героя
>когда нахождение в какой-то зоне сокращает длину конечностей, фактически отменяя предыдущую мутацию удлинения
Вот да, у меня примерно такие мысли по поводу мутаций и условного их контроля. Щас пришла кста такая мысль, помню играл в третий вейстленд, длс, и там на персонажах радиация накапливалась, а затем ролила разные мутации, и вот щас думаю, можно действительно заставлять гг копить на себе различные бактерии, которые затем в зависимости от стадии будут ролить нам мутации, иногда заменяя их, а от самих бактерий можно было бы избавляться в сейфзонах либо на месте сыворотку изготавливать, так сказать смывая с себя грязь после потного дня и останавливая роллинг.
По поводу сейвскама, хз, как ты и сказал по хорошему нужно работать над тем чтобы не возникало желание сейвскамить, согласен, но это всё индивидуально, тут скорее нужно думать хочет ли игрок впринципе мутировать и что-то там получать, и если он согласен, то просто примет правила игры, а перезагрузиться только чтобы сохранить желание продолжать. Посмотрим кароч, да
да просто сделай сейф при выходе и при каждом событии, а после смерти возрождай в хабе. Загрузки из сохранок это такой анахронизм что я ебал того маму рот
Чтобы пользователь тебя выследил и по башке арматурой постучал, потому что не смог загрузится из твоего автосейва после 10 часов в игре..
>Расскажи на примере как завуалировать цикличный процесс.
Из базового
Тиры - оружия с прогрессией, где 5 тир к лейт гейму.
Сложный расчет где трудно в голове целыми числами быстро посчитать что-то (не важно что это, от боевки до крафта).
Итд.
>Как сделать так, чтобы слой где всякие декорации типа там книг, рисовались поверх предметов с нижнего слоя типа столов, полок, но при этом когда игрок к ним подходил, они его не перекрывали?
Сделай area у книги или у игрока и когда происходи событие выхода/выхода меняй кодом z-index.
>Есть ли смысл ради этого бросать работу и
Давно не было лудоманов алыншиков.
>@onready var _bla_bla := $BlaBlaBlavich as BlaBlaBlavna
Не понял о чем ты
В обычных статичных языках
Разница между колоссальная.
@onready var _bla_bla := $BlaBlaBlavich as BlaBlaBlavna // ранйтам
@onready var _bla_bla : BlaBlaBlavna = $BlaBlaBlavich // комплтайм
У гдскрипта типизация для галочки (будут это отрицать, но посмотри сорцы годота), поэтому типизация скорее для автокомплита в редакторе.
>Это классика, это знать надо
Ты не понял о чем я.
>БАЗА геймдева прошлого века.
Чел я лично играл 1-2 дум, варкрафты, херетик и прочее. Причем скажу что второй варкратф тормозил на 386 машине (на 486 норм уже было, а вот пентиум - ну ты понимаешь, пентиум!).
Я понял что он хотел сделать, но получилась какая-то шляпа.
Типизация гдскрипта ускоряет рантайм. Будешь это отрицать - посмотри сорцы.
>Типизация гдскрипта ускоряет рантайм
Тесты ты не покажешь, кроме той буллшит статьи, в которую ты поверил на слово, как истинный фанбой?
Там есть оптимизации в сравнение с обычным Variant, но это не значит var a: int - становится нативным int - это просто хинт, подсказка для некоторой оптимизации. Но интерпретация байткода сделана настолько плохо, что это все вообще не имеет значения (там даже не уровень питона или руби).
Манерв не засчитан. Следуй своему совету и ныряй в сорцы. Пока вижу у тебя только манятеории, спекуляции и догадки.
>Манерв не засчитан
Так это я предложил посмотреть сорцы. Ты используешь мой аргумент против меня. Это демагогия уровня начальной школы ("сам такой")
>Сорцы
Так ты открываешь их и видишь что там все так же на вариантах.
>манятеории, спекуляции и догадки.
Ну и в отличие от тебя я тестил - результат на уровне нефига.
Ты же тупенький озлобленный вахтерышка, если я сейчас снова полезу в сорцы, потрачу снова время на реверс, и принесу пруфы ты начнешь жать кнопку жалобы. Мы же уже это проходили, все неудобное тебе удаляется.
>>1112707
>>1112713
>>1112736
Короче я понял что нифига не понял. Есть два мнения: Ты дебил оно тебя сожрет и Искусство никогда не умрет.
Но я просто заебался так жить без перспектив, а в геймдеве если попробую то я хотя бы буду в среде которая хоть немного мне нравится. И вопрос был в том смогу ли я свою копейку на еду заработать, вложившись примерно в пять лет своего усиленного оубчения. Или уже нейронки отберут к тому моменту хоть какую-то надежду на тарелку макарон с сосисками?
>И вопрос был в том смогу ли я свою копейку на еду заработать, вложившись примерно в пять лет своего усиленного оубчения.
Смехуечки в сторону - не сможешь. Даже ДО нейронок тут реально зарабатывали единицы индюков, и чет около 80% стимо релизов не имели даже 10 ревью. А до стима еще доползти надо, а там еще санкции-хуянкции. А в современном слопоапокалипсисе "игр" скоро станет больше чем игроков, и без ревью будут оставаться 98% релизов.
Если ты хочешь делать для души - смысл имеется, если твоя душа в силах переварить современные ИИшные реалии (при этом ты должен иметь другой доход, либо у мамки на шее сидеть).
Если как заработок - однозначно нет.
Вообще непонятен твой взгляд на это.
Да, нейронки уже сделают по кнопке что угодно, а не через год.
Как это мешает вкатываться в геймдев?
Единственное что нейронки не сделают - это не скажут тебе, что нужно делать.
Если у тебя есть гениальные идеи, то просто делай за месяц качественный прототип, бери издателя/краудфандинг, наслаждайся.
Если ты хочешь исполнять чужие идеи - перспективнее курьера во Вкусвилле вряд ли сейчас найдешь что-то.
