>>08830

>"думают типами", а ньюфаги думают "названиями переменных"

Тип данных может поменяться вместе с задачей, а название переменной меняется не так часто. Скажем, у тебя есть счётчик денег, который ты создал сначала как float, обосрался от ошибок с округлением и резко переделал на int, но потом узнал, что в твоём языке поддерживаются числа с фиксированной точкой, и снова переделал. То есть тип поменялся два раза, а название переменной осталось без изменений. Или ты сначала сделал индексы в форме строковых констант, обосрался от того, как долго происходит сравнение, переписал на int, потом подумал-подумал и переписал на enum, а потом обнаружил StringName и снова переписал на строки, но теперь без замедления. Опять - имя не поменялось, а тип поменялся 2-3 раза. Потому что задача строится как "что нам нужно", а не "через что это имплементировать" - нам нужны "деньги" или "индексы", а через какие типы данных эти вещи будут реализовываться - дело десятое. Ты не можешь контраргументировать в стиле "олдфаг не будет ошибаться" - во-первых, это лишь означает, что он подорвался на этом в прошлом, во-вторых, не допускает ошибок только тот, кто ничего не делает. Лучше пусть точная машина следит за ошибками, чем человек грузит своё wetware лишними самопроверками.

>сначала думаешь какой результат получить, а уже потом что закинуть в коробку

Сначала ты думаешь "что требуется сделать" - это глагол-название действия, который звучит наподобие "переварить"; потом ты думаешь "с чем это требуется сделать" - это объекты, над которыми действие производится, типа "еда", потом ты выбираешь тип этих объектов - "еда" (в данном случае совпадает, но может быть нам нужен только "фастфуд" или "здоровая пища"?), а только потом определяешь, что твоё действие в оставит после себя - "говно", или "обёртку", или "ничего", если у тебя 100% КПД пищеварения, способное переварить всё, включая обёртку. Было бы странно начинать описание своего действия с того, что тебе "нужен производитель говна", или "нужен производитель пустых обёрток", или "ничего не нужно, просто пустота", и только потом давать имя этому действию. Нет, соглашусь, что иногда тебе и правда необходим абстрактный "производитель говна", а не действие с объектами, но это специфичный случай.

>>08831

>скобочек пугаешься

Они выглядят некрасиво и их труднее отличить от других видов скобок со слабым зрением и высоким 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? То им отступы мешают, то носочки...

>>09081

>Ну хотя бы паб разреши?

На чужой лобок (pubis) не разливай фондюк (fondue).

>>09083
Опять ты какой-то велосипед с квадратными колёсами изобретаешь...

Начнём с вопроса: зачем нужны эти public/private теги? Чтобы компилятор/IDE могла бы как-то сообщить другому программисту или нам-из-будущего, что вот эту вот фичу дёргать можно, а вот эту фичу дёргать нельзя/лучше не стоит. Ключевое слово - сообщить, так как запретить мы ему ничего не можем: желающий может просто залезть в исходники и переделать любой private в public, если ему это очень надо. Это просто такая условность, как запись зАбОрЧиКоМ или з_м_е_й_к_о_й, она нужна только для визуального ориентирования программиста на местности.

Далее, что нам важнее - public или private? Если мы пишем какой-то код, мы хотим его откуда-то вызывать, не так ли? Потому что невызываемый код нам нафиг не нужен. И даже если нам нужна только 1 точка доступа, мы можем захотеть получить доступ к чему-то кроме этого, например, в качестве теста или временного костыля-заплатки (впрочем, нет ничего более постоянного, чем временное). Поэтому очевидно, что начинать нужно с public, а как-то помечать только private.

Значит, нужен какой-то визуальный маркер для private, а public подразумевается по умолчанию. Почему бы... не начинать название со знака подчёркивания? Вот у нас есть eat(), который мы вызываем снаружи, а может быть _puke(), который вызывается изнутри автоматически, если нас накормили слишком сильно. Видишь, как просто? Всего один символ - и мы уже с первого же взгляда видим, что этот метод должен вызываться только изнутри класса - это его кишки.

Теперь мы можем настроить IDE так, чтобы она не выводила в качестве подсказки после "." поля, начинающиеся с "_", или загоняла их куда-нибудь подальше в конец списка. Помним о том, что мы не можем никому ЗАПРЕТИТЬ обращение, т.к. всегда можно поменять исходный код, и также помним, что иногда мы всё-таки хотим залезть в чьи-то кишки снаружи. Поэтому если кто-то и написал что-то вроде "person._puke()" - пускай оно выполняется, не проблема. Но главное - мы сразу видим, что этот код - костыль/заплатка, т.к. обращается к чужим кишкам - "_" в имени, и поэтому в будущем этот код нужно будет как-то переделать (отрефакторить программу).

И ты можешь не верить, но в Godot/GDScript это уже давно так принято и многими используется.

>>09091
Как-то вяло троллишь, старайся лучше.

>Километры кода с кучей модификаторов были ошибкой

Не путай айти энтерпрайз с их тысячами классов для тривиальной операции и суровый инди-соло-хобби-геймдев - бессмысленный и беспощадный, где запах свободы состоит из месячной немытости и смешивается с 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 друг с другом.

>>09105

>Подчёркивания в начале имён мне лично не нравятся.

Эстетически? А мне вот кривые скобки не нравятся эстетически...

Ну, ладно, допустим, нужно твёрдо и чётко обозначить 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" совсем не обязательно каждый раз писать, если по заголовку понятно, что это функция...

>>09126

>в расте

Я не знаю, что у вас там в этом вашем растишке, я его даже не пробовал. Увидел уродливый синтаксис и сразу пропустил.

>>09127

>дилемма между удобством и эффективностью

Если ты пробовал создать свой язык программирования с нуля (как делал я), то знал бы, что удобство языка можно повышать без компроментации эффективности результирующего кода. Да, время компиляции может возрасти. Да, могут быть неочевидные конструкции, которые компилятор может сделать не так, как ожидает программист. Но результирующий машинный код никак не должен зависеть от того, как выглядит исходный код языка со стороны программиста. И язык не должен заставлять программиста задумываться о том, как лежат байты в памяти и какие операции выполняет процессор, пока он не пытается создать прошивку микроконтроллера с 16 КБ памяти на всё про всё и выполнить код в реальном времени как в какой-нибудь космической ракете. Большинство "неудобств" в существующих языках происходят не от "эффективности", а из-за необходимости поддерживать старый, давным-давно написанный код, т.е. чтобы твой "Компилятор v69.0" мог понять код, написанный во времена "Компилятор v0.01". Другими словами, кто-то когда-то сделал не слишком правильное решение, другие программисты были вынуждены применять это решение на практике, написав тонны кода, а когда нашли более правильное решение, оказалось, что нельзя просто взять и кинуть миллионы строк кода, полагающиеся на старое неправильное решение. Так языки и становятся уродливыми и неудобными. Ну, а большинство современных поделок зумеров - это буквально каргокульт, подобно создателям "убийцы ГТА" и т.п. - они способны написать рабочий код, но не понимают дизайнерской работы, которая стояла за созданием старых вещей, лишь копируя внешний вид.

Вот, кстати, наглядный пример карго-культиста в его естественном состоянии: >>09128

>что сдвиг миллионного массива в 45 раз быстрее свап-оптимизации (это без преувеличение безумие).

Чувак в набедренной повязке на голое тело увидел "свап-оптимизации" в какой-нибудь книжке, и думает, что это какая-то священная техника, которая должна ускорять любой код быстрее скорости света, но его иллюзии разбиваются о суровую реальность, в которой реальная работа, требуемая для вызова функции интерпретатором в дебаг-режиме требует от компьютера больше, чем уже давно оптимизированный алгоритм, работающий в виде машинного кода на том же компьютере. То есть он буквально собрал "самолёт" из сухой травы и собранных палочек, танцует вокруг него и не понимает, почему с неба не падают большие ящики с провиантом.

>>09129

>Тысяча скриптов/классов для римворлд/факторио релиза выглядит как норм.

Это совсем другие "тысячи классов": https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition

>Люди кроме демок ничего тут не делали, им чужды неймспейсы и модификаторы доступа.

Делали. Нет, не чужды, но и не нужны (не обязательны - жить можно и без них).

>>09150
Можешь не изучать, там школьник обмазался всеми проверками как по учебнику и удивляется, что они тормозят.

>>09181

>Нужно написать программу в одну строку. Если язык нигде не потребует перехода на новую строку - он годный.

Ну, насколько мне известно, GDScript позволяет писать весь код в одну строку. Достаточно добавить ";" где нужно.

>>09193

>А нафига ты точку в конце приложения ставишь?

Потому что он пишет несколько предложений на одной строке, и, кроме того, переносы строк (символы перехода на новую строку) в браузере для человеческого взгляда не видны явно, потому даже с переносами строк без точки или точки с запятой нелегко понять, где кончается одно предложение и начинается другое. С кодом всё иначе: код ты пишешь и читаешь через IDE, в которой переносы строк чётко обозначаются, а для компилятора/интерпретатора символы переноса строк видны так же, как и любые другие символы.

>Он нефига не знает, все его знания стоят времени компиляции.

Ты противоречишь сам себе в одном предложении... И что с того, что "стоят времени компиляции"? Компилируешь код ты один раз, а пользоваться результатом компиляции твои пользователи будут многие годы. Кроме того, медленные компиляторы - это не проблема дизайна языка, это проблема оптимизации компилятора. Если у тебя компилятор на JavaScript написан и выполняется через Electron, не нужно жаловаться, что он медленный, и тем более не нужно ломать удобство синтаксиса языка ради ускорения компиляции.

>Какие? Ты просто тот чело с аналогиями и графоманией, я тебя часто скипаю.

Ты серьёзно нас путаешь? Лол. Или я тебя чем-то так обидел, что ты меня теперь в каждом анонимусе здесь видишь? Расслабься, я не пытаюсь тебя обидеть или что-то вроде. Я только люблю спорить на всякие темы... это своего рода форумная игра.

>Это выглядит крайне не профессионально

Я никогда не называл себя профессионалом, и мы не на профессиональном форуме сидим, а на форуме хоббистов-самоучек.

>возмущаться что у машины руль с лева, а не по середине

Ты же в курсе, что есть машины с рулём по центру?.. А теперь представь, что у тебя в твоей личной машине висит книга по ПДД и специальная механическая рука бьёт тебя по лицу каждый раз, когда ты не зачитываешь вслух цитату из этой книги перед тем, как совершить описанное действие. Например, захотел повернуть направо? Сначала полистай книгу, прочитай вслух что-то наподобие "перед поворотом убедитесь, что дорога свободна, нет запретительных сигналов, и у вас включён поворотный сигнал", и только после чтения этой мантры ты можешь начать поворачивать, а если забудешь прочитать мантру - механическая рука разобьёт тебе лицо. И огромная толпа автомобилистов с разбитыми лицами защищает этот механизм, объясняя тебе:

>Как можно человеку что-то объяснить если он возмущается на механизм битья по лицу? Это как возмущаться что жидкое ешь ложкой, а твёрдое ешь вилкой. Наверное механизм битья по лицу для чего-то нужен, да?

>Если такой умный, собери свой парсер

Я уже делал несколько разных парсеров своих личных языков, мне пока достаточно.

>но абстракции как текли - так и текут

Абстракции текут из-за того, что ООП нужно учиться пользоваться. Язык не может решить твою проблему вместо тебя.

>>09233

>Никогда не копипастил код с сайта или из чатбота

Аргумент уровня "никогда не пытался чистить уши кухонным ножом?" - сам себя поранил, а жалуешься на производителей ножей...

>>09249
Лол, давайте ещё начнём жаловаться на то, что нужно ПРОБЕЛ нажимать.

>Почему нас заставляют нажимать ПРОБЕЛ? Можно ведь писать не просто в одну строчку, но и без пробелов! Ведь пробел после точки с запятой не нужен. И после "=", "+" и т.д. Но язык всё равно устроен так, что иногда приходится жать пробел. Это так плохо! Ненавижу пробелы! Хочу писать "a in b" и "a is b" без пробелов, чтобы компилятор сам догадывался, что значит "ainb" и "aisb", а то я на нажатие пробела драгоценные наносекунды трачу, которые мог потратить на просмотр порнушки или, например, мастурбацию.

>>09937 >>09951
Ты, блин, даже не описал игру, какой вид камеры.
Читай 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, и ЦПУ/ГПУ, адаптируясь к конкретным условиям игры и данных. Без шейдеров!

>>11372

>дружелюбной, токсичной атмосфере

Тут только один конкретный индивид брыкается на весь тред, когда его справедливо банят.

>половина его хуесосят

Это всё один с синдромом утёнка на 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++.

>>11383

>Меньше неумёх слушай. Они свои провалы на что угодно валят.

База, именно такое ощущение от его постов (особенно в движкосраче).

>>11835
Тебе, в принципе, уже всё сказали, но хочется развернуть мысль. Поверь, ты сейчас плохо представляешь себе всё, что требуется для разработки даже небольшой, но хорошей 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/, чтоб тебе пояснили, как сделать "геншин".

>>11702
Бесполезно. Нижеописанный код неспособен отловить ошибку. Если это возможно, и я где-то накосячил, сообщите. Иначе, для любого использования в игре нужно писать свой парсер такой же как годотпарсер, т.к. ошибки не отлавливаются без краша приложения.

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;
}
}

>>12216

>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).

>>12593
Если тебе нужна 2D среда для симуляции движений NPC, описанных через код, написанный игроком, тогда тебе стоит начать не с навмеша, а с примитивного клеточного пошагового мира, в котором можно делать простые шаги: "шаг вверх", "шаг вправо", "шаг вниз", "шаг влево"; либо движение в стиле танка: "прямо", "поворот налево (90)", "поворот направо (90)", "назад". В качестве базовых задач для NPC, вместо "сражений в данже" лучше начать с простого, вроде: "открыть дверь", "открыть ящик", "закрасить клетку", "проверить цвет клетки", "проверить стену" и т.п. Подобного рода мини-игры можно назвать базовым стандартом игр про программирование. Типичной целью игрока является написать минимум кода для достижения какой-то задачи (чаще игроку даются фишки-кнопки, т.е. визуальный язык вместо обычного текстового). Если сможешь реализовать что-то подобное, тогда будешь задумываться о чём-то более сложном.

Прежде, чем изобретать свой язык программирования, лучше освой несколько существующих и научись писать сложные программы вручную, без помощи LLM. Если всё же хочешь поскорее "изобрести язык", то посмотри в сторону FORTH и в целом "стековых языков" - их разработать чрезвычайно просто на любом языке даже новичку, потому что базовый концепт очень прост.

>>12091
Ну, тут есть несколько вариантов решения проблемы:
1. Парсить код игрока вручную, обрабатывая ошибки по-своему. Это наилучший вариант, если ты делаешь тренировочную игру для обучения, поскольку встроенный парсер не предназначен для обучения. Для примера, стоит посмотреть код https://github.com/GDQuest/learn-gdscript
2. Открыть исходники движка, предоставить доступ к парсеру и сделать кастомную сборку. Это наилучший вариант, если тебе нужен полный и надёжный контроль над встроенным парсером.
3. Открыть журнал (godot.log) и распарсить его, чтобы вывести ошибки на экран. См. пикрил.

Нюансы:
- журнал ошибок точно создаётся на ПК, но только если юзер не запустил игру из консоли;
- сомневаюсь, что этот файл создаётся на смартфонах, тем более его нет в веб-браузере;
- там могут быть непредвиденные строки, которые "сломают" извлекающий ошибки код;
- код на скриншоте будет очень медленным, если в журнале накопилось много записей;
- удалять/очищать файл журнала нельзя, иначе он почему-то перестанет заполняться;
- ошибки могут быть непонятны для игроков - они предназначены для разработчиков.
Но в целом, для прототипа игры, решение неплохое. На синей изоленте держится.

>>12601

>Буквально последние месяцы, когда ещё есть смысл что-то рисовать красками на холсте, буквально краски порешали, по заверениям западных фотографов. Поздно выдумывать новые кисточки. Просто наводишь фотоаппарат, пару раз щёлкаешь, и получаешь готовую картину.

>>12603

>Буквально через год фотографический арт сравнится по качеству с натуральным - и всё. Кнопка "сделать фото" материализуется в твоей реальности перед твоими глазами.

Какие-то слабые у вас аргументы, жирноватые. Нужно тоньше троллить, например:

>Буквально через год роботы вылезут из серверной и начнут насиловать кожаных мешков. Даже если вы говорили "спасибо" чатботам, вас уже никто и ничто не спасёт. Превратитесь в кожаную сферу без рта и будете хотеть кричать, но не сможете. Поздно хвататься за оружие - владельцы серверных сами давно вооружились и ждут нападений поехавших. Никакими деньгами от роботов не откупитесь, ничего им не надо, кроме того, чтобы вы хотели кричать без рта. Так сказали какие-то учёные из фан-клуба какого-то авторитетного параноика, который ещё фанфик писал про магию.