Godot: C# как язык сценариев

На мой взгляд, добавление дополнительных функций в GDscript было бы лучшим подходом к написанию сценариев.

Для меня основной причиной выбора Godot среди других игровых движков является упрощенная схема скриптов. Godot не предлагает изучать новый язык программирования. Он предлагает изучить Godot и его язык сценариев в качестве комбинированного инструмента для разработки игр. Это менее пугающий подход, чем предложение новичкам изучить C++ или любой другой язык программирования для написания сценариев.

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

Наиболее важная причина, по которой существует более одного движка, заключается в том, что помимо одномерных факторов, таких как производительность в задачах общего назначения или доступность интерфейсов, существуют многомерные факторы, такие как производительность в конкретных ситуациях (нет очевидного победителя, если сравнить движок). оптимизированный для 3D-игр и один оптимизированный для 2D-игр) или удобство использования для определенных групп пользователей (интерфейс, удобный для новичков, обычно должен скрывать расширенные функции).
Итак, чтобы найти место среди других двигателей, двигатель должен выбрать «философию».

Сейчас скриптовый язык является неотъемлемой частью движка, поэтому философия языка должна соответствовать философии движка или, по крайней мере, не противоречить ей.

Так в чем же заключается философия Годо? Давайте посмотрим на некоторые факты:

• По сравнению с Godot любой другой крупный движок раздут.
  Загрузка Godot меньше 20 МБ, вся «установка» представляет собой один исполняемый файл размером менее 50 МБ. Lumberyard, с другой стороны, имеет начальный размер загрузки около 5,5 ГБ, в настоящее время размер моей установочной папки составляет 15,3 ГБ. Основная причина этого — философия Amazon в отношении зависимостей. Эта первоначальная загрузка содержит 10,5 ГБ встроенных образов 42 зависимостей, и если вы работали с веб-сервисами Amazon до того, как знаете, что AWS SDK не так уж отличается в этом аспекте, так что это не вопрос необходимости или способности, это вопрос выбора. Например, в то время как Lumberyard включает в себя boost и Lua, Godot содержит свои собственные версии наиболее важных контейнеров STL и использует GDScript, а не lua, что позволяет уменьшить размер, удалить зависимости и сделать код более читабельным и доступным.
• Исходный код Godot очень доступен.
  Это начинается с выбора системы сборки (SCons), которая использует python в качестве языка сборки. В большинстве других проектов используются существующие системы сборки с проприетарными языками сборки или пишутся собственные проприетарные системы сборки, что отрицательно сказывается на удобочитаемости кода сборки.
  Сам исходный код также выше среднего в этом аспекте. Мне потребовалось примерно столько же времени, чтобы узнать, как написать один узел Unreal Blueprint на C++, сколько мне потребовалось, чтобы написать код для моего первого запроса на включение в Godot. Это не означает, что код Unreal C++ был нечитаемым, он просто не такой чистый, как код Godot, поскольку использует больше макросов и требует от пользователя понимания большего количества кода проекта Unreal по умолчанию, чем Godot.
• Godot продвигает принципы KISS и OO.
  Чтобы проиллюстрировать это, давайте рассмотрим несколько простых объектов в Unity. Первая концепция, с которой вы сталкиваетесь в Unity, — это GameObjects с прикрепленными компонентами. «композиция важнее наследования», как ее часто называют (я предпочитаю формулировку Майкла Дж. Дикхайзера «Контейнер против наследования» из «C++ для разработчиков игр», которая не звучит как боевой клич и побуждает к размышлениям над этой темой) — успешный шаблон. из-за гибкости, которую он предлагает. Однако эта гибкость имеет свою цену. Если все в вашей игре является GameObject, вы не можете получить ссылку на "игрока", потому что нет никакого игрока, есть просто GameObject, к которому может быть или не быть прикрепленный компонент игрока (или, скорее, те несколько компонентов, которые делают поднять игрока).
  Разработчики Unity столкнулись с той же проблемой: иногда вы просто хотите создать кнопку, а не игровой объект с компонентом кнопки. Итак, что они сделали, так это: они позволили вам создать «Кнопку» через интерфейс редактора, который фактически создает GameObject с прикрепленным компонентом Button. Вдобавок к этому они перенаправили самые важные элементы GameObject через каждый компонент, так что теперь вы можете использовать ссылку на кнопку точно так же, как если бы вы использовали ссылку на GameObject. Вы можете запросить у кнопки ее позицию, вы можете запросить у нее список ее компонентов, даже если кнопка на самом деле является компонентом, а не объектом, к которому она прикреплена.
  Итак, теперь у нас есть смесь двух самых популярных способов описания игрового мира — на основе композиции и в простых объектах. Но когда вы посмотрите на проекты для начинающих (и даже на некоторые продвинутые проекты), вы обнаружите, что Unity также способствует третьему способу интерпретации игрового мира: процедурному программированию.
  В Unity каждый объект всегда является частью «сцены». В отличие от Godot, этот термин описывает часть игры верхнего уровня (отказ от ответственности: теперь в Unity есть диспетчер сцен, который находится поверх сцен, но моя точка зрения остается в силе), а это означает, что если враг хочет выстрелить в игрока, он может просто найдите текущую сцену для игрока и взаимодействуйте с ним. Это основная идея процедурного программирования — у вас есть последовательность команд, которые изменяют состояние среды независимо от владельца. Конечно, технически это по-прежнему объектно-ориентированное программирование, но поскольку каждый объект может быть частью одной и той же сцены, вы можете писать код, который ведет себя как глобальный код. Например, если вы хотите создать экземпляр объекта, все, что вам нужно сделать, это вызвать «Instantiate(templateObject)», и копия объекта templateObject будет создана и добавлена ​​на сцену. Нет необходимости спрашивать, к какой сцене добавить объект, потому что всегда есть одна сцена, частью которой все в данный момент является.
  Итак, Unity продвигает смесь композиции, объектно-ориентированного мышления и процедурного программирования.

Godot, с другой стороны, продвигает объектно-ориентированное мышление, например, каждый отдельный объект в вашей игре может быть создан как отдельная сцена. Эти сцены могут быть запущены сами по себе, что позволяет вам тестировать их, изменять их сами по себе и т. д. Это, в свою очередь, требует, чтобы вы создавали эти сцены таким образом, чтобы не требовался доступ к среде. Например, если враг хочет взаимодействовать с игроком, гораздо более целесообразно использовать сигналы, чтобы сообщить базовой сцене, что взаимодействие запрошено, или просто потребовать, чтобы сцена дала врагу ссылку на игрока. Вы по-прежнему можете искать игрока в игровой сцене, но если вы сделаете это, то вражеская сцена не сможет работать сама по себе, поэтому такой дизайн просто не соответствует инструментам.

Так как же это влияет на выбор языков сценариев?
C# для языков — то же, что Unity для движков. Философия C# всегда заключалась в том, что если какая-то функция была бы хороша, если бы она была добавлена ​​в язык. Просто взгляните на список функций, которые были добавлены с каждой версией: https://en.wikipedia.org/wiki/C_Sharp_ (programming_language)#Features_added_in_versions.
Теперь вы можете утверждать, что наличие функции не является чем-то плохим, верно? Вам не обязательно использовать его, просто оставьте, если он вам не нравится. К сожалению, это неверно для языка. Учитывая важность Интернета сегодня, языки больше не инструменты, а культуры. Рано или поздно вам придется обратиться за помощью в Google, вы будете использовать модули или объекты, созданные другими, вы будете использовать новые функции, встроенные сообществом в движок, и рано или поздно это потребует от вас использования языковых функций, которые вы никогда не планировали. использовать.
Кроме того, если вы работаете в команде, вы научитесь ценить использование языка, который продвигает общий стиль кодирования и не предлагает вам десятки способов написания одного и того же кода.

Теперь вы можете задаться вопросом, хочу ли я сказать, что язык с меньшим количеством функций всегда лучше, чем язык с большим количеством функций. Конечно, это не так. Давайте сравним, как Java решила проблему.
C# позволяет писать неуправляемый код. Просто используйте соответствующее ключевое слово, и вы сможете использовать его прямо в том же файле. Он также позволяет писать функциональный код с использованием LINQ, который читается как код SQL и ведет себя как функциональный код. Чтобы полностью понять, что делает один файл, вам может понадобиться довольно много знать о парадигмах программирования.
Если вы пишете на Java, вы также можете использовать функциональное программирование, вам просто нужно записать его в отдельный файл, использовать другой компилятор и назвать это «программированием на Clojure». Если вы предпочитаете сочетать объектно-ориентированное и функциональное программирование, вы можете назвать это «программированием на Scala». Важно то, что вы все еще пишете код для JVM, который может легко взаимодействовать с кодом из других языков JVM.
В .NET-языках есть такая же возможность, просто она не используется в C#-философии. С таким же успехом они могли бы решить придерживаться одной или двух парадигм программирования на C# и создать новый язык для добавления новых парадигм, но вместо этого они выбрали «один язык, чтобы победить их всех» — и это совершенно нормально, здорово иметь язык такой. Вы должны просто знать об этой философии и выборе, который у вас есть как у программиста.

Короче говоря: из всех языков, которые у нас есть, я думаю, что C# хуже всего подходит для Godot. Это естественно подходит для Unity, но если у вас есть все эти варианты, то зачем выбирать язык, который способствует смешиванию и сопоставлению парадигм в движке, который продвигает чистые ООП-принципы и KISS-программирование во всех остальных его частях?

Так что, если вы считаете, что C# будет хорошим дополнением к Godot, то я с вами НЕ соглашусь — я просто говорю, что существуют альтернативы, которые даже лучше, которые следует оценить в первую очередь и которые будут немедленно забыты после реализации C#.

@мужчина

На мой взгляд, добавление дополнительных функций в GDscript было бы лучшим подходом к написанию сценариев.

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

Для меня основной причиной выбора Godot среди других игровых движков является упрощенная схема сценариев. Godot не предлагает изучать новый язык программирования. Он предлагает изучить Godot и его язык сценариев в качестве комбинированного инструмента для разработки игр. Это менее пугающий подход, чем предложение новичкам изучить C++ или любой другой язык программирования для написания сценариев.

Но Godot уже можно использовать из C++, поэтому ничего не изменится (при условии сохранения GDScript), за исключением того, что кодирование на C++ станет проще для тех, кто хочет это сделать (в настоящее время для написания модулей требуется компилировать весь Godot, и он не интегрирован). в рабочий процесс).

@Warlaan хороший анализ. Если вы читали мой пост, я тоже не согласен с тем, что C# является хорошим выбором для Godot, поэтому я предложил расширить уже существующие возможности C++, чтобы можно было использовать его в качестве языка сценариев, при этом GDScript оставался языком по умолчанию для большинства пользователей.

Пользователи должны иметь возможность писать на GDScript довольно много, однако неразумно думать, что большая игра будет написана на GDScript. На мой взгляд, ничто не мешает Годоту подойти для больших игр, кроме производительности GDScript, потому что движок очень хорошо спроектирован и имеет уже неплохую производительность (а Vulkan, вероятно, сделает ее еще лучше).

На мой взгляд, производительность не нравится большинству пользователей Godot, но она может привлечь к Godot больше профессионалов, что означает больший вклад, а значит, лучший Godot для всех.

@paper-pauper Я понял, что мы на одной стороне. Когда я написал «если вы считаете, что C# будет хорошим дополнением», я обращался «к вам, анонимному читателю», а не к вам лично. ;-)
И да, любой новый язык сценариев отвлечет внимание от GDScript. Я сомневаюсь, что сообщество позаботится о более чем одном языке, рано или поздно некоторые функции будут недоступны или сломаны в любом из них, может быть, даже вплоть до того, что один из языков будет удален.

Я также согласен с тем, что единственными реальными проблемами здесь являются время компиляции C++ и производительность GDScript.
Аргумент, что люди уже знали C#, просто неверен. Я профессионально работаю с C# уже около 4 лет (в основном работаю с C++ и SQL), и единственное, чему я научился за это время, это то, что, скорее всего, я никогда не смогу сказать, что действительно знаю этот язык. В конце концов, с C# 6 и предложениями для 7 количество функций все еще растет.
Поэтому, когда мы говорим о «знании C#», все, что мы можем на самом деле иметь в виду, — это знание самого основного синтаксиса, который даже худший новичок должен быть в состоянии заново выучить за несколько дней. Недавно я читал лекцию о различных игровых движках группе гейм-дизайнеров, которые раньше использовали исключительно Unity, и никто из них не высказался плохо о синтаксисе GDScript, в то время как некоторые из тех, кто отказался от программирования, теперь снова мотивированы.

Так что да, решение, которое ускоряет GDScript и делает C++ менее громоздким для компиляции и использования, также было бы моим любимым.

Многие люди, которые «знают» C#, не используют многие из его функций, которые отличают его от Java. Просто взгляните на множество сценариев Unity, которые не идут дальше подклассов.

Только по этой причине я очень скептически отношусь к практическим преимуществам, которые может дать C#. Они хороши во многих контекстах, но не в разработке игр. Кроме того, C++1x уже предлагает многие из этих вещей (включая вывод типов, итераторы и некоторые базовые функциональные инструменты) без каких-либо накладных расходов.

Кроме того, возможно, что накладные расходы, вызванные CLR (или даже JVM), могут заставить Godot работать _хуже_, хотя я вижу некоторые преимущества в использовании сборщика мусора JVM (кто-нибудь знает больше об управлении памятью Godot)?

Я читал на форумах о людях, которые не используют Godot из-за GDScript. Я думаю, что это недальновидно, потому что в этом нет ничего плохого, кроме того факта, что у него плохой выбор библиотек, о чем я пытался рассказать в другом тикете, # 3943, предложив решение с нулевыми накладными расходами и кроссплатформенностью. служба поддержки.

Без необходимости реализовывать C++ JIT через LLVM есть решение, которое работает на нативном коде и не требует возни с исходниками Godot: динамическое связывание.

Первый позволяет использовать нативный код без перекомпиляции Godot с нуля: вы просто компилируете его как файл .so, а затем добавляете его в свой путь загрузки, а затем используете его из GDScript без дополнительных затрат (поскольку это все вызовы функций).

Это должно быть очень легко сделать (через libdl?), но, насколько я понял, это не делается из-за проблем с кроссплатформенностью.

Кроме того, есть идея компилировать GDScript в C++, как это делает ENIGMA со своим языком. Это непросто, но, очевидно, обеспечивает лучшую производительность.

кто-нибудь знает больше об управлении памятью Godot?

Из документов :

Если класс наследуется от Reference, то экземпляры будут освобождаться, когда они больше не используются. Сборщика мусора не существует, только простой подсчет ссылок. По умолчанию все классы, не определяющие наследование, расширяют Reference. Если это нежелательно, то класс должен наследовать Object вручную и вызывать instance.free(). Чтобы избежать циклов ссылок, которые нельзя освободить, предусмотрена функция weakref для создания слабых ссылок.

Просто отметить...

Основное преимущество GDscript заключается в том, что это язык, полностью находящийся под контролем Reduz и других разработчиков, то, как он работает для разработчиков Godot, не зависит от внешней команды, и поэтому его можно разрабатывать способом, специфичным для конкретного проекта. дизайн двигателя и иметь то, что просят пользователи.

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

Кроме того, есть тот факт, что GDscript не требует каких-либо знаний о компиляции и что вам не нужно ничего, кроме встроенного редактора Godot (который делает рабочий процесс красивым и аккуратным, не говоря уже о простом и быстром).

Просто вопрос, как внутри работает интерпретатор GDscript? Анализировать каждую строку во время выполнения, как старый базовый язык, или он преобразует весь скрипт в таблицы байт-кода, а затем запускает байт-код?

@RebelliousX

https://github.com/godotengine/godot/blob/master/modules/gdscript/gd_compiler.cpp
https://github.com/godotengine/godot/blob/master/modules/gdscript/gd_parser.cpp

Я не думаю, что есть какие-либо серьезные языки, которые работают так же, как Бейсик! :)

Привет!
Вот история GDScript:
///////////////////////////
История
Изначально Godot был разработан для поддержки нескольких языков сценариев (эта возможность существует и сегодня). Однако сейчас используется только GDScript. За этим стоит небольшая история.

В первые дни движок использовал скриптовый язык Lua. Lua работает быстро, но создание привязок к объектно-ориентированной системе (с использованием запасных вариантов) было сложным и медленным и требовало огромного количества кода. После некоторых экспериментов с Python его также оказалось сложно встроить.

Последним сторонним языком сценариев, использовавшимся для поставляемых игр, был Squirrel, но от него также отказались. В этот момент стало очевидно, что Godot будет работать более оптимально при использовании встроенного языка сценариев, поскольку были встречены следующие препятствия:

• Godot встраивает скрипты в узлы, большинство языков не предназначены для этого.
• Godot использует несколько встроенных типов данных для 2D- и 3D-математики, скриптовые языки этого не обеспечивают, и их привязка неэффективна.
• Godot активно использует потоки для извлечения и инициализации данных из сети или с диска, интерпретаторы сценариев для распространенных языков не подходят к этому.
• У Godot уже есть модель управления памятью для ресурсов, большинство языков сценариев предоставляют свои собственные, что привело к дублированию усилий и ошибкам.
• Код привязки всегда беспорядочный и приводит к нескольким точкам сбоя, неожиданным ошибкам и общей необслуживаемости.

Наконец, GDScript был написан как индивидуальное решение. Язык и интерпретатор для него оказались меньше, чем сам код привязки для Lua и Squirrel, и столь же функциональны. Со временем наличие встроенного языка оказалось огромным преимуществом.
/////////////////////////

На мой взгляд, С++ может быть лучшим. Есть некоторые решения, такие как:
https://github.com/RuntimeCompiledCPlusPlus/RuntimeCompiledCPlusPlus
Даже скрипт Angel обычно может быть скомпилирован во время выполнения.
В написании сценариев я люблю python, потому что мне всегда нравились решения, сочетающие игровые и научные симуляции (у python много научных библиотек). Так что я жалуюсь! в другом выпуске, почему у godot есть собственная физическая библиотека: https://github.com/godotengine/godot/issues/4217
Есть некоторые проблемы с такими языками, как C#: https://github.com/godotengine/godot/issues/2790 .

Хорошая находка, @alabd14313 - это решило бы почти большинство проблем, оставив GDScript в покое.

Насчёт RCCPP, это очень хорошая идея. Я думаю, что если бы Godot поддерживал его в режиме редактора, а затем отключал в сборках, производительность была бы максимальной, а время итерации было бы довольно быстрым. Я слышал, что другие движки, такие как Unreal Engine, делают что-то подобное с C++, и я думаю, что было бы неплохо, если бы Godot позволял бесшовное кодирование, подобное написанию сценариев на C++.

Кажется, авторы знают свое дело, потому что на этой странице они перечислили большинство альтернатив своему подходу (включая тот, который я упомянул, LLVM JIT).

Я думаю, что этот подход имеет наибольший смысл, потому что Godot написан на C++ (и я не думаю, что это когда-либо изменится, учитывая, что C++ будет еще лучше через несколько лет), у него уже есть работающий C++ API и C++. имеет почти максимально желаемую производительность с нулевыми накладными расходами, и не будет дополнительных сред выполнения или менеджеров памяти. Я надеюсь, что разработчики обратят внимание на это.

Я немного удивлен, обнаружив, что эта ветка, которая, афаик, была начата как реакция на предложение добавить C# в качестве языка сценариев, до сих пор не содержит ни одного аргумента ЗА C#, даже после того, как шесть человек высказали свое мнение.
Возможно, решение о добавлении C# не является заранее обдуманным, как я предполагал из слухов, которые до меня доходили.

@Warlaan , что произойдет, если опубликовать этот URL-адрес в группе Facebook? :)

Пожалуйста, измените заголовок на что-то вроде «C++ как язык сценариев».
С++ 17 имеет больше возможностей:
http://blog.mattnewport.com/why-c17-is-the-new-programming-language-for-games-i-want/
Я восхищаюсь разработчиками godot и благодарю их за работу. но я против библиотек Box2D/LiquidFun/Bullet. Таким образом, разработчики могут сосредоточиться на конвейере, а не на таких компонентах, как физика. С C++ они могут сосредоточиться на производительности, а не на поддержке и обновлении gdscript. Теоретически RCCPP может лучше реализовать некоторые новые функции, такие как режим инструмента. Может быть...

Несколько месяцев назад @reduz упомянул, что хочет реализовать визуальные сценарии, что-то вроде нереальных чертежей. С RCCPP рабочий процесс между C++ (для программистов) и Visualscripting (для дизайнеров уровней и художников) может быть реализован следующим образом:
Введение в программирование на C++ в UE4
C++ и чертежи
Таким образом, в группе программисты могут разрабатывать новые классы чертежей для художников, а художники используют их вместо прямого кодирования.

@Warlaan ИМХО, это потому, что многие разговоры о C # были вызваны людьми, которые хотят, чтобы Godot был грабежом Unity, но, к счастью, многие здесь понимают, что Godot - это свое собственное дело и уже опережает Unity во многих отношениях, и это было бы несправедливо. чтобы на него повлияли одни и те же проблемы.

@ alabd14313 alabd14313 Я бы изменил название, но, возможно, лучше создать отдельную проблему и сохранить ее для потомков, чтобы ее можно было связать, когда кто-то предложит C # (как это часто бывает).

Если честно, я сомневаюсь в визуальном скриптинге, но если его можно реализовать как модуль, то почему бы и нет? Конечно, я думаю, что наличие визуальных сценариев (для дизайнеров и новичков), GDScript (для людей, которые умеют программировать или хотят учиться) и C++ (для программистов) сделали бы Godot довольно сбалансированной программой, подходящей для всех уровней навыков, но уменьшающей кодирование на C++. громоздкий и позволяющий упростить взаимодействие со сторонними библиотеками, ИМХО, должен иметь более высокий приоритет, потому что он может привлечь много профессиональных пользователей (и, следовательно, участников).

Имхо, визуальные сценарии далеко не настолько совершенны, чтобы иметь смысл. Это отлично подходит для маркетинга и обучения новичков программированию, но, по моему опыту, фаза обучения, во время которой новички предпочитают блок-схемы, очень короткая.
Для всего, кроме самых простых последовательностей вызовов, известные мне системы (Unreal, Cryengine, Fungus, Stingray) просто бесполезны. Я имею в виду, что этот скриншот , например, из официального рекламного ролика двигателя Stingray. Вот это я называю спагетти-кодом. Да и официальные примеры в движке Cry выглядят ничуть не лучше, хотя по количеству элементов комментариев видно, что было приложено много усилий, чтобы сделать график читабельным, вернее, пытались.
Если вы думаете, что это не так уж плохо, позвольте мне напомнить вам, что если бы вы видели этот код на текстовом языке, каждая соединительная строка, начинающаяся за кадром, была бы переменной с (надеюсь) осмысленным именем.

Графы потока несколько помогают, когда речь идет о шейдерах/материалах, так как можно отобразить промежуточные результаты, но и там система сильно страдает от того, что короткое уравнение типа
число с плавающей запятой x = (ab)*(a+b)/(1-(a+b))
легко заполняет весь экран, когда это делается в виде графика, поскольку каждое умножение, сумма или разность являются узлом с двумя входами и выходом. Это как минимум 10 узлов для приведенной выше формулы, и если вы не хотите вызывать хаос соединений, вам придется дублировать узлы a и b.

Современные системы потоковых графов (по крайней мере те, что я знаю) не позволяют давать значениям осмысленные имена, потому что вместо того, чтобы помещать результат в промежуточную именованную переменную, вы просто соединяете его со следующим узлом. Это делает самодокументирование кода почти невозможным и требует гораздо больше усилий для документирования.
Что добавляют эти системы, так это возможность размещать узлы там, где вы хотите, что, по моему опыту, чаще приводит к менее читаемому коду, чем к тому, который легче читать.

И, пожалуйста, не говорите о потоковых графах так, как будто они не программируют. Они так же кодируют, как и любой другой язык программирования. Они не печатают, вот и все.

Визуальные скрипты предназначены для дизайнеров и художников, чтобы вносить изменения без необходимости учиться программировать. Некоторые художники также могут делать с ним простые интерактивные игры. У него есть цель, где он определенно полезен, просто он не для программистов.

@Warlaan Ну, это зависит от того, как вы определяете «программирование». Конечно, визуальные скрипты сродни определению алгоритмов, так что это недалеко от программирования, но программирование также связано с другими вещами.

Однако есть несколько хороших реализаций визуального программирования. Одним из них является PureData, а также есть GDevelop , довольно хорошая программа для создания игр на FLOSS (жаль, что она не более популярна). Короче говоря, хотя лично мне это не нравится (по некоторым причинам, которые вы упомянули), верно и то, что мы оба умеем программировать, поэтому для нас визуальное программирование является медленным и громоздким для достижения сравнительно плохих результатов.

Тем не менее, я согласен с @reduz , что некоторые люди видят в этом привлекательность. Это не те люди, которые будут зависать в таких тредах, но они тоже делают игры. Думаю, они могли бы что-то привнести в Годо.

Причина, по которой потоковые графы хорошо подходят для редактирования шейдеров, заключается в том, что они очень наглядны (у вас есть узлы, которые позволяют загружать изображения, выбирать цвета и т. д. без ручного ввода путей к файлам и значений). Вы также можете совершенно не бояться убедиться в правильности синтаксиса и правильности написания функций. Также нет необходимости разбираться в таких сложных задачах, как работа с матрицей (это все просчитывается за вас).

Методология Godot для редактирования шейдеров оказывается хорошим подходом, поскольку она четко разделяет вершины, фрагменты и световые компоненты, а также дает четкое указание относительно того, с каким типом данных вы работаете (будь то обычная информация или информация о камере).

Теперь с визуальным сценарием, я думаю, что он может быть полезен даже для умеренно сложных вещей, если узлы находятся на достаточно высоком уровне с точки зрения игровой механики (они делают более сложные вещи и имеют несколько входов) и если есть узлы, которые позволяют запустить скрипт или создать выражение/уравнение (которое, в свою очередь, можно использовать для сложных операций со значениями). Проблемы, которые я видел с другими системами визуальных узлов этого типа, заключаются в том, что они пытаются быть как можно ближе к буквальному программированию (т. е. имеют кучу низкоуровневых функций в качестве узлов, а не больше похожи на узловую версию Логические блоки Blender или перетаскивание GameMaker).

Конечно, он по-прежнему не позволяет делать что-то настолько тонкое и продвинутое, как то, что вы можете сделать с помощью чистого скрипта, но он все равно будет полезен для таких вещей, как простые типы объектов в игре (которые не требуют очень сложной логики). ) или если вам нужно просто быстро что-то грохнуть.

Я согласен с тем, что некоторые люди видят в этом привлекательность, и я также согласен с тем, что это не для программистов (просто наши определения «программиста» различаются ;-) ), поэтому я предлагаю оставить дискуссию на этом, поскольку это несколько оффтоп.

Еще одна полезная функция C++ — статический тип. Средства "auto" и "decltype" могут определить тип объекта. Редактор и завершение кода могут быть проще. Вместо того, чтобы сосредоточиться на внутреннем редакторе кода, мы можем использовать другую внешнюю IDE. На данный момент я думаю, что codelite и qtcreator имеют лучший статус в автодополнении кода. Кодовые блоки имеют некоторые проблемы с ключевыми словами С++ 11. Также eclipse-cdt имеет хорошее завершение кода. Плагин для qtcreator — хорошая идея (например, unreal-visual studio и Unity-Monodevelop). Внешняя IDE может быть идентифицирована с помощью системного пути в настройках godot (например, /use/bin/qtcreator), нет необходимости компилировать и упаковывать его с помощью godot (в отличие от пакета Unity, в котором есть встроенный monodevelop).
Есть и другие инструменты, такие как cppcheck и valgrind, которые имеют плагины в qtcreator.
Если вы хотите ознакомиться с тем, что такое RCCPP:
демо

Я хотел бы видеть язык сценариев на основе C++ для Godot, но реализация всех функций C++ была бы громоздкой, такой как программирование шаблонов. Должны быть некоторые ограничения для этого типа скриптового языка (STL), и шаблоны не должны использоваться. Также RTTI может вызвать проблемы с производительностью.

Я люблю GDscript, моя единственная жалоба на это - это загрязнение пространства имен переменных, при работе с большими скриптами определения переменных перед ready() могут стать очень запутанными и склонными к ошибкам в коде из-за совместного использования переменных между функциями одного и того же файла скрипта. .

Мои 3 цента. (э... получилось 20, но пусть будет...)

Как @alabd14313 упоминал ранее, «он находится в той точке, где он есть» из-за многолетней эволюции, которая привела годот к форме, которой он является сегодня.
Независимо от того, делаем ли это природа или мы, люди, исправление вещей во время творения кажется лучшим способом развития, и я должен признать, благодаря этому, я очень наслаждаюсь Годо таким, какой он есть и куда его привела эволюция.

В нем есть все необходимые детали.

Узлы, которые можно объединить в более сложный объект, сохранить как сцену, а затем повторно использовать как «простой» объект в другой сцене, что является потрясающей и мега гибкой функцией, действительно ограниченной только собственным воображением пользователя и границами творчества.

Простой в использовании и изучении GDScript, достаточно мощный, чтобы управлять всеми узлами так, как мы, программисты, просто привыкли это делать — вводя строки кода.
Кроме того, делая это быстро и легко (дополнение кода/документация по сборке/полезные всплывающие подсказки здесь и там) без необходимости компиляции, просто введите, попробуйте, настройте и снова отполируйте до совершенства.

Развертывание на нескольких платформах ДЕЙСТВИТЕЛЬНО одним щелчком мыши (не говоря уже о том, что развертывание на Android через Wi-Fi/adb, редактирование жизни, отладку и т. д. — это просто шедевр искусства, нет... Более того, это волшебство!)

Кроме того, все эти знакомства с часто используемыми инструментами, такими как блендер и т. Д.
(импортный хлам и работает из коробки, все где и как должно быть)

И, наконец, я признаю, что иногда даже сверхтворчества может быть недостаточно, когда нужно сделать что-то миллион раз за цикл и уместиться в 1 кадр. Вот тут-то и появляется материал C. Если вы знаете C, он вам нужен, ничто не мешает вам создать плагин, собственный пользовательский узел и т. Д., Которые делают именно то, что вы хотите.

В нем есть почти все, и со временем, я думаю, все будет.
(Имеются в виду вещи, которые сегодня «еще не реализованы» и нужно делать это «как-то» или «голыми руками» (читай: использовать для этого внешний инструмент), например, настроить 3D-ригинг что-то простым способом (надо использовать блендер )

Godot — удивительная и волшебная вещь, совершенно совершенная на своем пути, куда бы она ни пошла.Нужны корректировки и добавление материала здесь и там, но это все.

Визуальный скрипт?
Эм-м-м. Это может заставить нас, программистов, «немного» изменить образ мышления необычным образом, плюс я не верю, что он может быть таким же гибким и читаемым, как обычный код.
Представьте, что вы кодируете и имеете простую строку, подобную этой ( abc / def ) * ghi
затем быстрый способ, как обычно (?), Чтобы не печатать, вы отмечаете часть чего-то, вставляете сюда, вырезаете там, снова вставляете и через 5 секунд и несколько нажатий клавиш получаете «простой» (потому что вы знаете, что он делает) один вкладыш типа ((((abc/def+((abc/def)_ghi^4))_ghi)+(abc/def_(100))_ghi)+abc)
Это обычное дело, возможно, многие из нас делают это очень быстро.
Теперь представьте, что вы делаете это визуально...
Это может занять весь экран, много работы с мышью, и это не будет выглядеть так читабельно, как должно.
(конечно, такой вкладыш через год тоже выглядит не просто, но на то и комментарии)

А если у кого-то 100 таких строк одна под другой?
Визуально он мог получить футбольное поле, чтобы показать это. А как насчет того, чтобы анализировать это, менять, это беспорядок и большая головная боль.
Конечно, кодеры могут это делать, потому что не язык делает кого-то кодером, а особый образ мышления, создание алгоритмов, манипулирование данными как небольшими частями, так и в целом.
Язык, будь то C, Python, PHP, Java или Visual scripting, — это всего лишь инструмент для записи мыслей.
И вот, имхо, обычный набор текста на клавиатуре - это самый быстрый и читабельный способ записать это.
С другой стороны, если кто-то не умеет кодировать, ожидаете ли вы, что он вдруг проявит алгоритмическую гениальность и проницательность, чтобы не потеряться в собственной идее и ее визуальном представлении, учитывая, что когда мы думаем об игре, мы говорим о чем-то более сложном, чем столкновение двух мячей? друг друга с физикой.

Так для кого на самом деле Visual Scripting?
Усложнить жизнь кодерам или ограничить годот уровнем - движком для "простых игр" для начинающих?

Люди, в #1220 есть длинная дискуссия о Visual Scripting. Давайте, пожалуйста, больше не будем обсуждать здесь одни и те же темы.

Люди, в #1220 есть длинная дискуссия о Visual Scripting. Давайте, пожалуйста, больше не будем обсуждать здесь одни и те же темы.

Большинство сообщений здесь были такими длинными, что, возможно, я потерялся во время чтения.
Извините :расслабился:

@RebelliousX Даже с RTTI C ++ все равно будет иметь гораздо лучшую производительность, чем GDScript. Хотя это правда, что шаблоны могут быть проблемой.

Решение, предложенное @reduz в #3936, уже сделало бы кодирование на C++ довольно тривиальным - вы просто делаете это с помощью выбранного вами редактора и компилятора и связываетесь с API Godot. Если это будет реализовано, даже если писать сценарии на C++ было бы неплохо, с точки зрения производительности это не будет сильно отличаться от написания кода на C++ и последующего вызова его из GDScript. Короче говоря, я думаю, что фокусировка на # 3936 (что является простым решением) значительно улучшит:

• Производительность (поскольку писать части на C++ было бы очень просто)
• Наличие сторонних библиотек (поскольку обертки могут распространяться легче, но не так легко, как # 3943)
• Пользовательская база и участники (многие программисты на C++ приняли бы Godot)

Затем можно было бы сосредоточиться на статической типизации в GDScript и оптимизации интерпретатора (через JIT или путем компиляции GDScript в C++), но это может произойти позже, если написание модулей будет проще.

Я просто хочу упомянуть пару моментов, которые пробрались в это обсуждение, но еще не были рассмотрены:

• Некоторые из нас говорят об улучшении существующей системы (GDScript в качестве языка сценариев, C++ в качестве внутреннего языка) за счет облегчения разработки на C++ и повышения производительности GDScript. Другие говорят об использовании C++ (или Java/C#/...) в качестве языка сценариев. Может показаться, что нет никакой реальной разницы между возможностью быстрой разработки на C++ и превращением его в язык сценариев, но я с удовольствием объясню, как я испытал и наблюдал негативное влияние мощных языков сценариев на качество игрового дизайна. И если это не станет темой обсуждения, я с радостью сделаю это на форумах или где-то еще, где это не захватит эту ветку.
• @RebelliousX : Когда вы говорите о «пространстве имен переменных», «больших сценариях» и «совместном использовании переменных между функциями», это звучит так, как будто вы не до конца поняли объектно-ориентированную природу GDScript (без обид). Каждый файл GDScript является классом, поэтому конфликты имен между переменными (членами) должны происходить точно так же часто, как и в любом другом объектно-ориентированном языке. Вы не делите переменные между сценариями, вы пишете несколько функций, которые могут получить доступ к состоянию охватывающего объекта.

@Warlaan Что касается первого пункта, я думаю, вы могли бы опубликовать здесь, так как он связан с темой.

@Warlaan без обид. Я знаю, что GDscript — это отдельный класс, и я знаю, что переменные похожи на обычные переменные-члены в классе C++, но, похоже, вы полностью упустили мою мысль. Вы поймете это, когда у вас будет скрипт с более чем 1000 строк кода. То, что я хочу, это ссылки или указатели, вместо того, чтобы создавать мириады переменных-членов, просто передавать их между функциями-членами. Так безопаснее.

Мне нравится C#, но я вижу плюсы и минусы.

Плюсы:

• Хорошая поддержка инструментов (скажем прямо, стали бы вы кодировать на C# без Visual Studio или MonoDevelop?)
• Подходит для масштабных проектов
• Широко используемый и зрелый, в Интернете есть множество потоков поддержки.
• Хорошая производительность, компромисс между C++ и языками сценариев при кроссплатформенности
• Относительно легко связать с C++

Минусы:

• Сбор мусора: крупномасштабные игровые проекты также должны реализовывать стратегии распределения, чтобы предотвратить слишком частые выбросы GC, это может быть неприятно.
• Не так интегрирован, как GDScript (завершение пути к узлу? Переменные-члены скрипта на узлах? Модель распределения памяти?)
• Среда выполнения тяжелая, а .NET framework еще больше. Как и в Unity, стандартные библиотеки должны быть переназначены на Godot.
• Не лучший вариант для реального написания сценариев, в смысле делать что-то быстро и грязно. C# более многословен и ограничен, чем GDScript.
• Пока нет рекомендаций относительно разработки Godot. Язык является общим и может делать много вещей, и, как сказал Варлаан, у разработчиков разные культуры (у вас может быть кодировщик WPF, пробующий Godot и задающийся вопросом, почему нет способа MVVM для создания графических интерфейсов: p)

Большая часть этого также относится к Java.
Может быть, я забыл другие вещи, потому что здесь уже поздно.

Хорошо, это мой опыт работы с многофункциональными языками сценариев, соответственно. полное отсутствие языка сценариев в зависимости от вашего определения «языка сценариев». Я постараюсь быть кратким. ;-)

Я работаю деканом по инженерии в School4Games в Берлине, Германия, уже несколько лет. В этой школе у ​​нас нет факультета «чистого» гейм-дизайна, но наш курс гейм-дизайна называется «разработка игр» и включает в себя достаточно уроков программирования, чтобы научить гейм-дизайнеров разрабатывать свои собственные прототипы и понимать возможности и ограничения. аппаратных и общих программных архитектур.
Так что студенты, которых я обучаю, — это люди, которые иногда проявляют повышенный интерес к программированию, но ни один из них не подал заявку на профессию программиста.
Каждый семестр они должны формировать команды и разрабатывать одну игру. Поскольку почти все потенциальные будущие работодатели наших студентов используют Unity, в течение первых двух семестров необходимо было работать с этим движком.

Теперь давайте перейдем к вопросу о влиянии языков сценариев:
Эти студенты разделились на две группы. Тот, кто либо старается избегать программирования, либо потерял надежду (имеется в виду, что они будут посещать занятия по программированию, но не будут просить о помощи, если у них возникнут проблемы, а молча сдаются), и тот, кто погружается в программирование так глубоко, что сразу переходит к темам, которые ему не интересны. обычно вы не будете беспокоиться при написании прототипов игр. Например, один из моих студентов с первого семестра недавно опубликовал учебник о том, как написать синглтон на C# с использованием дженериков, чтобы вы могли превратить класс компонентов Unity в синглтон, наследуя от универсального класса из учебника. Интересно не столько то, что он смог написать эту статью, в конце концов, ему, конечно же, помогали его учителя, а ресурсов на эту тему в Интернете довольно много. Интересно, что студент, подавший заявку на курс, ориентированный в основном на игровой дизайн, а не на программирование, будет заинтересован в такой конкретной теме программирования. Код из этого туториала никогда не изменится из-за изменений в дизайне игры, это чисто программная конструкция.
Нечто подобное произошло с другим учеником, который использовал аналогичный класс для переноса информации из одной игровой сцены в другую. Он был очень удивлен, когда я показал ему, что он может сделать то же самое с общедоступным статическим членом, что показывает, что он искал полные, сложные решения, прежде чем он полностью понял все основные элементы в нем.

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

Это происходит не только из-за предрассудков. Конечно, это, вероятно, один из факторов. Если вы видите, что код в учебниках, примерах или других классах вашего проекта выглядит сложным, вы можете сделать вывод, что ваш код тоже должен выглядеть сложным. Но я думаю, что настоящая причина в том, что в программировании имеет смысл пытаться создавать код, защищенный от ошибок. Это естественное желание писать код, который не ломается, как только он используется в другом месте или как только он получает другой ввод. И это требует от вас выяснить, какие есть варианты, к которым вам, возможно, придется подготовиться.
Я думаю, что это чувство необходимости проверять каждую возможность и есть то, что разделяет моих студентов на тех, кто тонет в огромном количестве возможностей C#, и на тех, кто сразу бросается в язык и теряет фокус.

Зиланн упомянул фразу «быстро и грязно». Мы часто используем эти два термина как фразу, но если подумать, то на самом деле это два разных фактора. Возможность быстрого кодирования вполне измерима. С другой стороны, является ли полученный код грязным, зависит от множества факторов, наиболее важным из которых является количество функций, которые имеет используемый язык.
Например, создание узла верхнего уровня и использование его в качестве синглтона в Godot совершенно нормально, поскольку GDScript не предлагает функций, необходимых для реализации шаблона, как в таких языках, как C#. Конечно, использование функции автозагрузки было бы лучше, так как это первое место, где другие разработчики будут искать синглтоны (и это делает синтаксис немного приятнее), но если команда решит реализовать ее таким образом, я сомневаюсь, что будет много проблем. аргумент. С другой стороны, представьте, что кто-то реализовал синглтон в Unity, просто добавив открытый статический член в класс. Это так же быстро, в некотором смысле это даже одно и то же (оба являются экземплярами класса в самом общедоступном месте), но поскольку C# предлагает возможность сделать конструктор закрытым, получить доступ к синглтону через свойство с ленивой инициализацией и т. д., это ожидается, что вы это сделаете, иначе код будет восприниматься как очень грязный, если не сломанный.

Тот факт, что студенты, занимающиеся игровым дизайном, погружаются в такие темы, может быть смутным намеком на мою точку зрения, но я думаю, что могу проиллюстрировать это еще лучше, рассказав о ситуации на моей первой работе в крупном разработчике F2P MMO. Команда, к которой я присоединился, является одним из самых опытных разработчиков игр в Германии. Их глава отдела разработки создает свои собственные двигатели с 1995 года, и даже несмотря на то, что они были только что куплены другой компанией, они по-прежнему оставались одними из самых успешных разработчиков в то время.
К тому времени, когда я присоединился к команде, они использовали третью версию внутреннего движка, в котором не было языка сценариев. Они реализовали его раньше, но в этой версии движка они вернулись к отсутствию языка сценариев, поскольку возникли проблемы с качеством кода, предоставленного разработчиками игр. Другими словами, поскольку язык сценариев был слишком мощным, было принято решение сдвинуть барьер между программистами и гейм-дизайнерами до такой степени, что геймдизайнеры могли только редактировать уровни и изменять настройки в конфигурационных листах, в то время как программисты выполняли все программирование — оглядываясь назад. заметил, что это примерно та же ситуация, в которой оказываются мои студенты (и, похоже, в нее попадают многие профессиональные студии, работающие с Unity).
Теперь, почему меня это должно волновать? Если это происходит снова и снова, то разве это не доказывает, что это успешный способ работы? Мой ответ — нет, потому что были проблемы, как технические, так и в геймдизайне, которые легко объяснялись тем, что общение между программистами и геймдизайнерами сводилось к написанию задач в одном направлении и выставлении настроек в другом. С точки зрения гейм-дизайнеров функции стали черными ящиками, которые можно было включать и отключать, но со стороны команды не было никого, кто мог бы обсуждать или даже прототипировать альтернативы.
С другой стороны, программисты почти естественным образом были вынуждены придерживаться бэкэнд-менталитета. Менталитет KISS «быстро и грязно» исчез, потому что никто из нас не мог предсказать, как будут использоваться созданные нами функции. Я отчетливо помню, как однажды база данных сломалась из-за того, что гейм-дизайнер внедрил охоту за пасхальными яйцами, в результате чего запасы стали намного больше, чем раньше. Это был последний раз, когда я предполагал, что требования к функции, вероятно, останутся примерно такими же.

Вот почему я считаю, что наличие малофункционального скриптового языка в качестве определенной области для игрового кода чрезвычайно важно, и почему я думаю, что его отсутствие плохо сказывается на дизайне игр.

• Написание быстрого кода означает игнорирование функций, превращая его в «быстрый и грязный» код.
• Желание писать чистый код разделяет разработчиков на тех, кто не пишет код, и тех, кто тратит больше времени на размышления о коде и меньше времени на игру.
• Это, в свою очередь, разделяет всю команду на одну половину, которая работает над игровым дизайном, не зная кодовой базы, и другую, которая работает над функциями, не зная, как они будут использоваться, не оставляя никого, кто мог бы придумать функции движка на основе игры. разработать или предложить дизайн игры на основе функций, которые можно легко реализовать.

Сегодня невозможно представить разработку игр без использования готовых библиотек классов, в конце концов, именно это делает движки с такими наборами инструментов, как Godot, Unity, Unreal и т. д., такими успешными. Но разница между всеми этими движками заключается в том, где проходит грань между программированием и гейм-дизайном и насколько велик разрыв между двумя сторонами.
И исходя из своих наблюдений я думаю, что выбор скриптового языка — это один из важнейших факторов, который может создать такой разрыв или закрыть его.

Кстати, причина, по которой я так увлекся Годо, заключается в том, что я работаю над тем, чтобы сделать его обязательным двигателем первого семестра. Просто чтобы вы знали, что я не просто говорю, но и рисую свои последствия. ;-)

@RebelliousX Я должен признать, что до сих пор не совсем понимаю, к чему ты клонишь. Но поскольку вы сказали, что вам нужны ссылки или указатели, не могли бы вы открыть новый запрос функции и опубликовать там пример кода для вашей проблемы? Честно говоря, все еще звучит так, будто ваша проблема связана с архитектурой кода, а не с отсутствующими языковыми функциями.

Я должен был добавить, что KISS больше подходит для небольших команд. Godot настолько многофункционален, что один разработчик может создать игру. Но как только в проекте появляется больше разработчиков, «быстрые и грязные» вещи становятся менее вероятными и остаются для прототипирования или временных исправлений, тогда должны быть установлены правила/рекомендации. Таким образом, это действительно зависит от того, кто использует двигатель и для чего.

Годо в целом также имеет больше ограничений, чем мы думаем. Вы не можете создавать синглтоны или глобальные переменные в стиле c-static по одной причине: утечка памяти и удобство работы с потоками. GDScript не так популярен, как Python, по одной причине: он ориентирован на задачи разработки игр и производительность. Система сцен также объектно-ориентирована по одной причине: вы можете создавать независимые «коробки», которые можно тестировать и использовать повторно :)

Этот раздел посвящен добавлению поддержки модуля C# (или Java), но я не вижу примера кода. Давайте попробуем что-нибудь на лету :)

using GodotEngine;

// Inherit a node type
public class Spikeball : RigidBody2D {

    // Exported variables
    [Export] public float damage = 60f;
    [Export] public float rotationSpeed = 2f;

    // Notice the naming convention. Should Godot API follow languages or should languages follow Godot?

    void _Ready() {
        SetProcess(true);
        // Should we use the generic system?
        Connect("BodyEnter", this, "_OnBodyEnter")
        // Or use C# features?
        this.bodyEnterEvent += _OnBodyEnter;
    }

    void _Process(delta) {
        var sprite = (Sprite)GetNode("Sprite");
        sprite.SetRot(sprite.GetRot() + delta*rotationSpeed);
        // Or we can have properties
        sprite.rot = sprite.rot + delta*rotationSpeed;
    }

    public void _OnBodyEnter(PhysicsBody2D body) {
        // We cannot invent C# members on the fly, so we can do this if the other script is in C# too.
        // ScriptInstance GetScript();
        var health = body.GetScriptInstance() as IHaveHealth;
        if(health != null) {
            health.TakeDamage(damage);
        }
        // But what if the other is GDScript?

        // A generic approach would look like this, a bit like SendMessage in Unity3D
        // object Call(string funcname, object arg1, ...); // where object can be seen as Variant
        body.GetScriptInstance().Call("TakeDamage", damage);

        // Same thing if we want to get a script variable
        var category = (string)body.GetScriptInstance().Get("category")
        Console.Print(category);
    }

}

Что вы думаете?
Затем этот файл может быть скомпилирован как актив DLL (или запущен на лету). Но говоря об этом, нужно ли нам создавать csproj, как Unity?

@Warlaan спасибо, что поделились своим опытом. Поправьте меня, если я ошибаюсь (это был длинный пост), но вы говорите, что предлагать язык с меньшим количеством функций лучше для программистов, чтобы они могли сосредоточиться на разработке своих игр, а не на перекодировании?

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

И мне самому сегодня было интересно, не просят ли здесь некоторые люди (включая меня) просто незаметно Urho3D , в то время как другие просят GDevelop . Godot явно является промежуточным инструментом между этими двумя (но идеально подходит для профессионалов, больше похожих на Urho3D), и я думаю, что так и должно оставаться, но Unity всегда будет бросать тень на него, потому что здесь много людей. исходить из него.

Я не думаю, что справедливо ожидать, что Godot будет грабежом Unity — у Godot явно лучший дизайн и, насколько я знаю, лучшая производительность. Но некоторые люди думают, что GDScript не подходит для «серьезной» разработки и никогда не будет им подходить, потому что это пользовательская среда выполнения, несмотря на то, что старая версия Mono, которую использует Unity, также является своего рода «специальной» средой выполнения. Кроме того, когда вы пишете C# в Unity, вы пишете код, который по большей части работает только в Unity, и следуете их шаблонам проектирования, поэтому вы можете использовать другой язык.

Я думаю, что те люди, которые хотят С#, ошибаются, но, на мой взгляд, хорошим компромиссом было бы предложить:

1) Лучшая производительность (статическая типизация, возможно, JIT)
2) Улучшенная поддержка сторонних библиотек (через FFI и упрощенную интеграцию с C++)

для GDScript. Остальное можно сделать на C++, включая написание модулей, реализующих другие языки сценариев (которые не обязательно должны быть собственными — каждый может написать модуль на C#, если захочет).

@Zylann Честно говоря , я не вижу преимуществ в написании этого кода вместо эквивалентного C ++, и код C ++ будет иметь лучшую производительность.

@paper-pauper Преимущество написания этого кода такое же, как у GDScript: вам не нужно перекомпилировать движок для каждой платформы, на которую вы хотите экспортировать, и... ну, вы получаете выбор языка (и производительность не единственный момент, как я упоминал ранее). Я согласен с тем, что в настоящее время возможности GDScript лучше, а C++ — лучший выбор для чистой производительности. Но есть люди, которые просто не хотят заниматься C++, каким бы хорошим он ни был.
Меня лично не интересует Godot+C#, я просто оцениваю, что произойдет, если вы добавите его в Godot. И это не так просто :p

После прочтения отличной книги Game Scripting Mastery (вы не можете найти много книг на эту тему, кроме неигровой книги о компиляторах Red Dragon). Мой вывод заключается в том, что GDscript адекватен, так легко продолжать добавлять функции к языку сценариев, что он теряет свою силу. Самое главное реализовать не раздутый скриптовый язык и как можно более общий сделать его подходящим для разных проектов. В той же книге говорится, что Unreal использует C++ с LLVM.

Еще одна идея, которая может быть более легкой, чем реализация отдельной среды выполнения: как насчет адаптации транспилятора, такого как TypeScript (который очень похож на C#, но без среды выполнения), для генерации GDScript вместо JavaScript? Это не обязательно должно быть включено в Godot, на самом деле это может быть сторонний модуль. По крайней мере, он будет предлагать статическую типизацию (во время компиляции) и ряд библиотек с той же производительностью, что и GDScript (потому что это будет GDScript).

Мне нравится TypeScript, но я не вижу смысла добавлять такое усложнение. Если кто-то это сделает, ему придется поддерживать его, чтобы он был совместим с более новыми версиями TS. Кроме того, TS является надмножеством JS, так сможет ли он транспилировать JS в GDScript? И тогда у нас будут некоторые люди с ошибками в транспиляторе, которые будут думать, что это ошибка в движке.

Я по-прежнему считаю, что лучше иметь статическую версию GDScript, которая может легче обращаться к JIT и по-прежнему тесно связана с движком и с самим текущим GDScript.

Смысл C# в том, чтобы использовать устоявшийся язык, который можно было бы использовать и за пределами Godot. TypeScript может подойти для этого, но я не уверен, что проще сделать транспилятор TS, чем встроить среду выполнения Mono.

Для меня, как я сказал в IRC, лучшим вариантом была бы возможность создавать динамически подключаемые модули. Таким образом, вы можете легче работать на C++, а также могут быть сторонние модули с разными языками, например, один для C# и один для C++ в качестве языка сценариев. Это увеличило бы возможности увеличения ресурсов Godot без необходимости раздувать двоичный файл основного движка.

@внен

Для меня, как я сказал в IRC, лучшим вариантом была бы возможность создавать динамически подключаемые модули. Таким образом, вы можете легче работать на C++, а также могут быть сторонние модули с разными языками, например, один для C# и один для C++ в качестве языка сценариев. Это увеличило бы возможности увеличения ресурсов Godot без необходимости раздувать двоичный файл основного движка.

О, я согласен на 100% - на самом деле я высказал аналогичную точку зрения в # 3936. Я просто бросил это, так как мы упомянули среду выполнения С# как недостаток :)

Для меня этот пример модуля C # от @Zylann прекрасен, я бы переключился с Unity прямо сейчас, если бы он был доступен - речь идет не о более высокой производительности C ++ или «легкости» GDScript, а о удобстве.

Я все еще супер новичок в Godot, и у меня едва была возможность сделать тестовую игру, так что вы, ребята, можете не считать мое мнение верным, но для меня GDScript является самым большим препятствием, а не в том, как он должен работать с узлами. и Сцены - это я понимаю (и это довольно аккуратно!).

Но для меня буквально синтаксис GDScript действительно отталкивает, если не сказать больше, не говоря уже о том, что редактора кода очень не хватает — я бы с удовольствием использовал VS, поскольку я уже знаю все ярлыки.
Я много лет писал на C#, и, честно говоря, я чувствую себя ребенком, пытающимся писать на GDScript.

Что будет потеряно, если позволить разработчикам писать с комфортом? Мне не нужно изобилие, которое есть в Mono, или причудливость, как в Linq, я просто хочу чувствовать себя комфортно, пока пишу свой код.
Я бы согласился на C#-подобный синтаксис для GDScript, по крайней мере, возможность использовать фигурные скобки, точки с запятой и явные типы — лично я терпеть не могу неявные типы, они сводят меня с ума.
Я думаю, что Game Maker допускает вариации синтаксиса для разных демографических групп.

Это, конечно, всего лишь мои 2 цента за несколько часов с Годо — не стесняйтесь не соглашаться (как, я уверен, и большинство из вас).

Кроме того, мне кажется, я что-то упускаю — что же такого в GDScript, что все так любят?
Я не пытаюсь обидеть, я просто еще не вижу.
Я довольно хорошо знаком с Perl, поэтому я знаю силу неявных типов и многого другого, но должно быть что-то большее, верно?

@Pikl :

Кроме того, мне кажется, я что-то упускаю — что же такого в GDScript, что все так любят?
Я не пытаюсь обидеть, я просто еще не вижу.

Суть GDScript не столько в синтаксисе (который похож на Python), сколько в том, насколько он интегрирован с движком. Это может показаться педантичным, но синтаксис — это наименьшая проблема при переходе на другую систему. Самое главное — это API. Даже если мы добавим C# прямо сейчас, вы, вероятно, будете чувствовать себя некомфортно в новой парадигме, поскольку то, как вы делаете это в Unity, отличается от того, как вы делаете это в Godot.

Извините, но если бы мы добавили языки для комфортной работы каждого программиста, мы бы потратили вечность только на это. Хотя может иметь смысл привлекать пользователей Unity с наименьшим стрессом (сейчас мы пытаемся сделать руководство по Godot для пользователей Unity), я не думаю, что Godot следует адаптировать к работе, как Unity. В противном случае нам пришлось бы делать то же самое для пользователей Unreal, Urho3D, GameMaker и т. д.

Это не означает, что С# не существует (может быть, если это осуществимо и в интересах движка), просто эти аргументы применимы и ко многим другим языкам и движкам.

@Pikl Прежде всего спасибо за предоставление первого аргумента в пользу C#. Теперь позвольте мне объяснить, почему я считаю ваше мнение неверным. ;-П

Давайте внимательнее посмотрим на начало примера кода Zylann:

    using GodotEngine;

    public class Spikeball : RigidBody2D {

    [Export] public float damage = 60f;
    [Export] public float rotationSpeed = 2f;

Как правило, каждое ключевое слово и каждый символ, не являющийся ключевым словом, имеет значение. Если это не так, то его там быть не должно.
Это начинается с
using GodotEngine;
это означает, что этот код относится к функциям, импортированным из пакета GodotEngine. Поскольку каждый скрипт в Godot ссылается на эти функции, а других пакетов для импорта нет, добавлять эту строку бессмысленно, поэтому давайте удалим ее.

Далее у нас есть
public class Spikeball : RigidBody2D {
Все в GDScript общедоступно, так зачем упоминать об этом?
class Spikeball : RigidBody2D {
Каждый файл GDScript содержит класс с тем же именем, что и скрипт. Это не просто соглашение о кодировании, как в других языках, оно так определено, так какой смысл повторять имя класса?
: RigidBody2D {
Теперь, поскольку : является единственным осмысленным «ключевым словом» в этой строке, давайте заменим его чем-то более читабельным.
extends RigidBody2D {
Любой программист с небольшим опытом будет использовать отступы для обозначения различных областей кода. Это означает, что код внутри класса может быть идентифицирован по окружающим фигурным скобкам И по отступу, поэтому разработчики Python решили сделать отступ обязательным и избавиться от лишних фигурных скобок.
В нашем случае отступ даже не нужен на уровне класса, поскольку каждый файл сценария определяется как один класс (если только вы не используете подклассы, отмеченные отступом).
extends RigidBody2D

Далее у нас идут линии экспорта.

    [Export] public float damage = 60f;
    [Export] public float rotationSpeed = 2f;

[]-символы помечают атрибуты, которые определены в классах с тем же именем, что является механизмом, не существующим в Godot, поэтому вместо него просто используются ключевые слова.

    export public float damage = 60f;
    export public float rotationSpeed = 2f;

Опять же, все публично:

    export float damage = 60f;
    export float rotationSpeed = 2f;

и вам не нужно указывать тип данных.

    export var damage = 60f;
    export var rotationSpeed = 2f;

Экспорт является исключением, потому что инспектор должен знать, какой виджет вам показать, поэтому тип на самом деле является просто дополнительной информацией для ключевого слова экспорта.

    export(float) var damage = 60f;
    export(float) var rotationSpeed = 2f;

Итак, разница между этим кодом С#

    using GodotEngine;

    public class Spikeball : RigidBody2D {

    [Export] public float damage = 60f;
    [Export] public float rotationSpeed = 2f;

и этот код GDScript

extends RigidBody2D

export(float) var damage = 60f;
export(float) var rotationSpeed = 2f;

просто были удалены все символы и ключевые слова, которые не описывали возможности, которые есть у вас в Godot.
Я предполагаю, что теперь довольно ясно, что людям нравится в GDScript. Вас не заставляют вводить бессмысленные или избыточные данные, а синтаксис отражает имеющиеся у вас возможности, а не намекает на опции или особенности языка, которых нет в Godot.

Имея опыт работы с C++/C#/TorqueScript, я должен сказать, что парадигма Godot требует нескольких дней, чтобы привыкнуть к ней, но как только ее простота «щелкнет», вы сможете переходить от идеи к реализации так же быстро, как вы можете печатать.

@внен :

просто эти аргументы применимы и ко многим другим языкам и движкам.

Честно говоря, я не задерживаю дыхание и не ожидаю, что меня приспособят - это не моя территория.

прямо сейчас мы пытаемся сделать руководство по Godot для пользователей Unity

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

@Варлаан :

Я предполагаю, что теперь довольно ясно, что людям нравится в GDScript. Вас не заставляют вводить бессмысленные или избыточные данные, а синтаксис отражает имеющиеся у вас возможности, а не намекает на опции или особенности языка, которых нет в Godot.

Это совершенно логично — это соответствует идеологии Perl по уменьшению количества нажатий клавиш, необходимых для ввода сценария. Но на самом деле количество нажатий клавиш, которые я на самом деле набрал бы для этого примера, было бы таким же - я использую автозаполнение VS по максимуму и редко должен набирать более 3 символов для любого ключевого слова, типа или имени переменной, прежде чем я нажимаю пробел или открываю кронштейн, чтобы завершить его. А что касается фактических дополнительных «ненужных» символов, я предпочитаю, чтобы они были там, это просто предпочтение синтаксического сахара.
У Godot есть автозаполнение, но оно медленное, оно занимает так много времени, что я часто набираю всю строку кода, прежде чем оно появляется в большинстве случаев.

Итак, что людям нравится в GDScript, так это то, что он урезан до минимально возможного, предоставляя именно ту функциональность, которая доступна для использования, и ничего больше, а также сокращает количество нажатий клавиш.

Я понимаю это, но это не помогает мне больше наслаждаться этим - мне просто неудобно печатать GDScript, хотя я могу читать его прекрасно. Я не борюсь, чтобы выучить это, мне просто не нравится это, кажется.
Может быть, еще несколько часов работы над клоном Space Invaders помогут мне убедить меня в том, что я хочу любить GDScript больше, чем сейчас.

Запоздалая мысль:
Можно ли использовать в Godot только C++? Честно говоря, я бы предпочел изучить C++ и использовать его, а не GDScript.

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

@StraToN опубликовал пост в группе facebook с просьбой о такой помощи. Свяжитесь с ним (я не уверен, что кто-то еще работает над этим).

@neikeq Спасибо, готово!

@Warlaan Я понимаю ваше сравнение кода, но для меня оно в основном доказывает, что C # имеет больше возможностей и, следовательно, более многословен.

Вам нужно using , потому что есть пространства имен, чтобы избежать конфликта имен с большим количеством классов (что уже происходит со мной в моем собственном игровом проекте).
Вам нужно public , потому что существует понятие инкапсуляции для предотвращения ошибок кодировщика с течением времени.
У вас есть [SomeClass] , потому что мы можем расширить встроенные аннотации в соответствии с потребностями различных проектов и улучшить инструменты.
Что касается фигурных скобок... Я не вижу преимущества, кроме определения областей видимости.

Эти функции здесь не просто так. Среди них я бы назвал масштабируемость. Хотели бы вы разработать огромную кроссплатформенную 3D-игру со всей кодовой базой на GDScript? Ну, ты можешь. Но многие пользователи предпочтут C++, C# или Java из-за перечисленных мной плюсов (и я говорю исключительно о языке, а не о фреймворке).

Но в то же время я не знаю ни одного «огромного» игрового проекта, который бы разрабатывался с помощью Godot, так что примеров не так много :p
Кроме того, я вижу несколько плохих функций в C# (предупреждение: личное мнение впереди):

У вас могут быть статические переменные. Это неправильно, так много ошибок возникает из-за глобальных состояний/синглетонов. В отличие от автозагрузки, они не привязаны ни к какой области сцены.
Вы можете ошибиться при вводе точки с запятой в конце оператора while() оператора if(), что сделает его бесполезным и трудным для поиска.
Вы можете перекодировать. Я согласен с тем, что при неправильном использовании код C# может стать очень запутанным, в то время как другой более простой код сделает то же самое. Но это зависит от людей/опыта.

Ой. Я не упомянул preload() . Это просто не может сделать это для C#/Java, если вы не полагаетесь на трюки компилятора: p

Кто-нибудь уже начал экспериментировать с модулем Mono?

Чтобы добавить мое самое скромное мнение, как разработчика C#, к этому...

Я не думаю, что есть большая ценность в добавлении C# к Godot, так как вам все равно придется изучать классы Godot, чтобы что-то сделать, и единственное, что вы действительно выиграете от добавления C#, это более знакомый (многим) стиль C синтаксис и статическая типизация.
Синтаксис вызывает споры, Python имеет репутацию легкого для изучения новичками, и, поскольку GDScript очень похож на Python, я думаю, что то же самое относится и к нему.
В любом случае у опытных программистов не должно возникнуть проблем с пониманием этого синтаксиса, он согласован и имеет значительно меньше подводных камней, чем более свободный синтаксис в стиле C.

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

Кроме того, реализация C#, вероятно, будет не такой уж простой, и значительное количество времени и усилий будет потрачено только на то, чтобы привести движок в состояние, в котором он находится в настоящее время, но теперь с C# поверх или вместо GDScript.

В качестве заключительного комментария, который, я знаю, некоторые люди воспримут неправильно, я хочу сказать следующее:

По моему наблюдению, некоторые программисты, которые могут быть не так твердо уверены в своем ремесле, как они должны быть, имеют тенденцию цепляться за то, что они знают, со всей доступной им силой.
Мне кажется, это явление особенно широко распространено в сообществах разработчиков C#, хотя это может быть просто мое предубеждение.
Если кто-то из читающих это думает, что он может соответствовать этому описанию, я могу только порекомендовать выйти за рамки этой знакомой рамки и начать изучать что-то новое, это не такая сложная задача, как вы могли бы подумать, и как только у вас появится твердая понимание этой новой вещи, вы, вероятно, также расширите свое понимание того, что вы уже знали. Это того стоит.

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

Пространства имен были бы крайне кстати, я удивлен, что их еще нет в GDScript.

Возможность использовать фигурные скобки вместо двоеточий для методов тоже была бы прекрасна, я знаю, что они не нужны, но мне нравится, когда они есть - это как читать книгу без точек, это раздражает.

Подсказки типа могут закрыть пробел, препятствующий полной работе автодополнения кода. Я когда-то работал над проектом, использующим Lua, и они тоже хотели иметь его. Исследования привели меня сюда: https://github.com/andremm/typedlua/blob/master/examples/http-digest/http-digest.tl#L48 .
Вот чем может стать параметр функции, если слишком углубиться в подсказки типов xD
Но я думаю, что должен быть компромисс. Просто посмотрите, как работают TypeScript или Haxe (они оба позволяют смешивать варианты и типизировать). Кроме того, в Godot уже есть подсказка типов. Он используется только в export() :)

Кто-нибудь уже начал экспериментировать с модулем Mono?
@Зиланн

Проверьте GodotSharp . Текущее состояние в репозитории еще не используется. В моем локальном репозитории мне удалось реализовать достаточно материала (в качестве базовых типов доступны только Vector2 и Matrix32), чтобы перевести демонстрацию 2D/платформера на C#, за исключением создания экземпляров врагов и пуль, которые выполняются из GDScript, поскольку ссылки еще не работают.
Это пример класса игрока: https://github.com/neikeq/GodotSharp/blob/master/platformer_cs/Player.cs .

@Pikl

Запоздалая мысль:
Можно ли использовать в Godot только C++? Честно говоря, я бы предпочел изучить C++ и использовать его, а не GDScript.

Да, это возможно, но пока это не так просто и/или удобно, и вам придется перекомпилировать Godot с нуля. Пожалуйста, поддержите #3936, если вы заинтересованы в том, чтобы C++ был первоклассным гражданином, чтобы его можно было использовать вместе с GDScript (или исключительно) без особых усилий.

@Zylann Pikl спросил об изменении синтаксиса GDScript, чтобы он напоминал синтаксис C#, чтобы разработчикам Unity стало легче читать. Это то, что я комментировал. Да, у C# действительно больше возможностей, и это единственная причина, по которой ключевые слова и символы, которые я удалил, были там изначально. И именно поэтому добавление их только ради того, чтобы код GDScript выглядел как код C#, не просто не нужен, имхо, это неправильно, поскольку вы будете использовать синтаксис, намекающий на языковые функции, которых нет в GDScript.

@Pikl Дело не в количестве нажатий клавиш, а в количестве вариантов и подразумеваемом значении дополнительных символов. GDScript просто не имеет некоторых функций, которые узаконили бы дополнительные ключевые слова. Например, каждой переменной, классу и функции должно предшествовать ключевое слово «public», поскольку модификатор видимости C# по умолчанию не является общедоступным (за исключением пространств имен — он меняется в зависимости от варианта использования... еще одна ситуация, когда Microsoft решила, что KISS это просто группа из 80-х) и так как в GDScript все публично.

Так почему бы не добавить C# со всеми его возможностями?
Как уже упоминал Зиланн, эффект от добавления C# в Godot не так просто предсказать. Если вы еще этого не сделали, я был бы признателен, если бы вы прочитали мой длинный пост в этой теме (https://github.com/godotengine/godot/issues/5081#issuecomment-225226235). Как разработчик, я всегда просил более мощные языки. В свободное время я сейчас смотрю на Kotlin только потому, что бумажник упомянул об этом в первом посте.
Но с тех пор, как у меня появилась возможность посмотреть на влияние языков программирования на результат и поведение разработчиков игр, я понял, насколько важно выбрать адекватный язык, а не мощный.
Как я объяснил в связанном посте, я уверен, что C# оказывает заметное влияние на культуру в сообществе Unity, которое рассматривает программистов как людей, которые

• написать материал для хранилища активов
• писать учебники
• исправить ошибки.

По моему опыту, в Unity не так много культуры программирования геймплея. Как только вы сталкиваетесь с какой-либо проблемой, вы начинаете искать шаблоны или готовые ресурсы для ее решения. На самом деле есть значительное количество людей, которые выбирают свои шаблоны еще до того, как узнают что-либо о проекте, и такая умственная негибкость влияет на результаты игрового процесса.

И это только мой любимый контраргумент, в первых постах было еще несколько хороших. ;-)

Проблема JVM в том, что она слишком тяжелая. Кто-нибудь смотрел Авиан ? Насколько это совместимо с миром Java?

@neikeq Это не означает, что у него худшая производительность - насколько мне известно, JVM имеет лучшую производительность, чем CLR, а также сборщик мусора, который намного лучше подходит для разработки игр. Он также установлен на большинстве компьютеров, независимо от того, являются ли они Windows, Mac или GNU/Linux.

Он также имеет большее количество библиотек FLOSS более высокого качества и, независимо от того, что говорят некоторые люди, лучшую кроссплатформенную поддержку.

Я бы сказал, что между ними JVM явно лучше подходит для разработки игр (но я бы все равно избегал как ее, так и CLR).

Авиан выглядит интересно. У меня нет опыта работы с ним, поэтому я не могу ответить на ваш вопрос, и я боюсь, что его совместимость может оказаться такой же проблематичной, как и версия Unity Mono, что делает очень неудобным использование сторонних библиотек, если вы не случайно найти один для одной из предоставленных .NET-версий.

Но было бы неплохо иметь облегченную реализацию Java в качестве дополнительной опции, помимо GDScript и C++, для случаев, когда вам нужно быстрое время выполнения и вы можете пожертвовать качеством кода (например, игровые джемы или быстрое прототипирование новых бэкэнд-идей).

@neikeq Avian предназначен для обеспечения java-скриптов для проектов C++, поэтому это действительно хороший кандидат. Он может быть очень маленьким (что-то около 100 КБ, если я правильно помню). Слышал о некоторых играх libGDX, которые использовали Avian для выпуска портов iOS... Движок jMonkey также использует Avian на iOS). В общем, Avian поставляется без целой упаковки, которая обычно поставляется с JVM, такой как классы sun/oracle. Однако я не думаю, что это проблема, поскольку «оригинальные» классы Java вообще не подходят для игр, поэтому такие библиотеки, как libGDX, предоставляют свою собственную реализацию векторов или структур данных.. и, в конце концов, я думаю, что мы также необходимо повторно реализовать эти классы. (Однако легко встроить различные части исходных классов Java, но чем больше мы включим, тем больше станет Avian)

@paper-pauper Я имел в виду тяжелый по размеру, если он будет в комплекте с игрой. Но, как вы сказали, он установлен на большинстве компьютеров, и, учитывая популярность таких фреймворков, как libGDX, это может быть лучшим вариантом.
Моя проблема с C++ как альтернативой GDScript заключается в том, что его синтаксис ужасен. Это убийца производительности. Это хорошо для разработки движка и модулей, но я бы не стал писать на нем целую игру. Сказав это, я за #3936 и что-то похожее на то, что делает Unreal, но я бы не рассматривал его как альтернативный «скриптовый» язык.

@ kubecz3k Поддерживает ли он другие языки JVM? например: Котлин

@neikeq да, насколько я знаю, он полностью совместим с байт-кодом java, поэтому поддерживает любой готовый язык jvm (kotlin, scala, jpython и т. д.)
Я думаю, мы могли бы задать несколько вопросов в группе avian google: https://groups.google.com/forum/#!forum/avian
вроде довольно активно

+1 к тому, чтобы не рассматривать C++ как альтернативный язык сценариев. Как я уже говорил, хорошо, что в Godot есть один язык, оптимизированный для написания сценариев, а другой — для бэкенд-разработки, а не один язык, который не очень хорош в обеих областях.

Это не значит, что поддержка динамических библиотек и более быстрая разработка на C++ не были чем-то, что я хотел бы видеть.

Но чтобы не переусердствовать с Avian, вот сообщение в блоге от главного разработчика libGDX, в котором он объясняет, почему libGDX не использует Avian для портов ios. http://www.badlogicgames.com/wordpress/?p=3925 (прокрутите вниз до части с птицами)
Я не программист / хакер jvm (но автор - так как он также работал над RoboVm (еще один jvm, который был куплен и закрыт Microsoft)) поэтому я не знаю, сколько из этого действительно превратится в ситуация, в которой Avian используется только как язык сценариев (без поддержки основного движка)

Большинство из вас, вероятно, программисты с большим опытом, чем у меня, но есть и мои 2 цента. Год назад я бы болел за C#. Но я очень быстро выучил синтаксис GDScript. В конце концов, вам все еще нужно изучить API, и это, вероятно, самая трудоемкая вещь для изучения. Так что да, мне не нужен C #. @Warlaan выдвинул множество веских доводов против C#. Внедрение C# также заняло бы много времени. Это также означало бы больше ошибок. Да, у нас есть отличное сообщество, которое вносит свой вклад в кодовую базу, но у нас все еще есть только один @reduz. Я думаю, что время, необходимое для реализации C #, должно быть потрачено на функции, которые нам действительно нужны. Сколько разработчиков Godot довольны GDScript? Да, это могло бы быть быстрее, но у меня нет других проблем с этим. Я бы предпочел иметь один классный язык сценариев, чем два не очень хороших. Даже Unity отстает от старого Mono.

То, что я хотел бы иметь, это статическая типизация в GDScript. Не C++ как язык сценариев, не C#. Давайте сосредоточимся на GDScript и сделаем его еще лучше, чем сейчас.

Поскольку движок, над которым я веду разработку в течение 14 лет, упоминался в ветке Visual Scripting, я решил добавить сюда свои 2 цента, поскольку мы разрабатывали новый движок, полностью написанный на нашем собственном C#-подобном языке.

Мы написали собственный компилятор (также написанный на нашем языке после начальной загрузки на C++), который скомпилировал код на C++ (почти чистый C), который затем был загружен в компиляторы всех поддерживаемых нами платформ (XBox/PS/PC/Wii/ и т.д). Мы написали свой собственный сборщик мусора поколения, чтобы иметь возможность настраивать его производительность по мере необходимости — это означало, что он использовался во всем движке, что означало, что он был хорошо протестирован и профилирован. А поскольку мы выполняли кросс-компиляцию на C++, мы могли легко написать код C++ в «родных» функциях, которые могли бы вызывать системные API по мере необходимости или включать специфичные для платформы операции (SIMD).

Я действительно не могу себе представить, насколько разочаровывающим должно быть то, что Unity пришлось объединить кучу кода C ++ с Mono - что, вероятно, объясняет, почему он отстает, как указал @GlaDOSik . Хотя это определенно не было чем-то, чем кто-либо из нас интересовался.

Нашей главной целью было объединить языки, используемые между движком, редактором и инструментами, а также код игрового процесса в единый язык. Раньше движок и инструменты были полностью C++, а визуальный язык сценариев (по крайней мере, он выглядел как код C) использовался для всего игрового процесса, который предпочитали дизайнеры уровней, но раздражал большинство программистов геймплея, которые писали большинство кода. Это также позволило нам адаптировать язык к вещам, которые могут нам понадобиться для разработки игрового процесса (например, поддержка конечного автомата).

_Однако всем не угодишь._ Если бы мне пришлось работать или пытаться помочь кому-то отладить неприятный беспорядок спагетти-проектов/и т. д. «кода», основанного на узлах, я бы хотел выколоть себе глаза в отместку. Я ожидаю, что художник, пытающийся читать код C++, сделает то же самое. Что вы можете сделать, так это потратить _много_ времени на споры о том, какое _лучшее_ решение есть, и еще больше на попытки угодить всем. В какой-то момент вам просто нужно сосредоточиться на создании наиболее продуктивных инструментов для нужных людей, а иногда это означает, что нескольким людям, возможно, придется научиться чему-то новому.

«Если это не C++, то это медленно», кажется, часто звучит мантра, но я бы сказал, что большинство _поставляемых_ игр в наши дни написаны на чем-то другом, а не на C++ для кода геймплея. На самом деле я не видел, чтобы кто-то сообщал о проблемах с производительностью именно из GDScript, хотя мне, конечно, было бы любопытно услышать от них, что было медленным.

Что касается моего знакомства с GDScript, то оно было примерно таким:

• OMG Python-подобный!? Это безумие, пробелы не должны иметь значения!
• Хм, не поклонник стиля «lower_case» (видите, всем не угодишь).
• Ну ладно, это на самом деле круто и хорошо продумано.
• Да, это хорошо интегрировано с редактором, я определенно вижу, что это очень продуктивно для кода игрового процесса и некоторых плагинов редактора!

Похоже, что в GDScript было вложено много усилий и времени, и это кажется правильным инструментом. Так что я просто хотел поблагодарить тех, кто работал над этим!

@Зифлин Привет! рад познакомиться с вами здесь, Vicious был одним из первых игровых движков, которые мы использовали профессионально (хотя нас наняли вместе с @punto-, чтобы взломать его и решить проблемы с ним, а не использовать его на самом деле).

Язык визуальных сценариев был настоящим кошмаром, но исходный код был действительно хорошо сделан, чист и организован. После работы с Torque это было счастьем. Я многому научился, работая с ним. Sony проделала большую работу, продав его в Латинской Америке, потому что все использовали его здесь десять лет назад.

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

Мы действительно смеялись над этим и шутили, а продюсер игры (который был позади нас, и мы его не заметили) дрожал от страха и сказал: «Подожди что? Осталось только перевести игру на португальский». , это шутка да?"

Но мы просто использовали китайский для португальского, все работало нормально, и игра была отправлена. Рад узнать, что вы, ребята, все еще развиваете его!

(цитата из @Ziflin ) На самом деле я не видел, чтобы кто-то писал о проблемах с производительностью именно из GDScript, хотя мне, конечно, было бы любопытно услышать от них, что было медленным.

Я лично достиг узкого места CPU/Gdscript в этом проекте: http://godotdevelopers.org/index.php?topic=15519.0

Я написал базовый ИИ и базовую псевдофизику старой школы в GDscript для управления каждой из 8 машин.
Я не стал публично кричать об этой проблеме с производительностью, потому что еще оставались небольшие возможности для оптимизации.
Но если бы я хотел добавить больше автомобилей, я был бы вынужден отказаться от Gdscript для C++ ( редактировать: чего я хотел бы избежать, так как я действительно не хочу компилировать снова и снова).

Кроме того, я думаю, что в прошлом году я столкнулся с тем же самым узким местом ЦП / Gdscript с этим другим проектом, который использовал GDscript для базового ИИ для каждой ошибки (животных): http://ludumdare.com/compo/ludum-dare-32/? действие=предварительный просмотр&uid=50893
Чем больше я добавлял жуков (животных), тем ниже была производительность.

Я мог бы поделиться своим опытом, если кто-то хочет.

@SuperUserNameMan Пожалуйста, продолжайте, но я думаю, что другой билет, который я открыл # 5049 (в котором конкретно говорится о производительности GDScript), больше подходит для этого.

@paper-pauper : не уверен, что смогу внести свой вклад # 5049 (это больше о добавлении JIT, о том, что я мог бы просто добавить большой палец вверх). Опыт, которым я могу поделиться, больше касается того, какого узкого места я достиг, каковы были конкретные симптомы, как мне пришлось обходиться, как я оптимизировал и какими «преимуществами дизайна Godot» мне пришлось пожертвовать.

@SuperUserNameMan Я еще не особо задумывался о реализации JIT через вывод типов, но для этого виртуальная машина должна сначала поддерживать статическую типизацию.

Мне было бы очень интересно услышать, о каком коде ИИ вы говорите.
Мое предубеждение состоит в том, что любой код, который может вызвать проблемы с производительностью при запуске всего на 8 объектах, вероятно, не является кодом игры, и поэтому его все равно следует помещать в класс C++, поэтому я и спрашиваю.

@reduz Ха-ха, видимо, мир тесен! И да, визуальные сценарии как бы вышли из-под контроля (на самом деле они предназначались только для работы с триггерами и небольшими фрагментами логики событий). Vicious фактически закрыл свои двери в начале этого года, но работать там было очень весело.

@ paper-pauper Я посмотрю другую тему, которую вы упомянули. На самом деле я не хотел, чтобы люди начали публиковать сообщения о проблемах с производительностью в этой теме.

Если GDScript должен был добавить статическую типизацию, _возможно_ было бы проще просто иметь возможность конвертировать его непосредственно в C++, что позволило бы избежать дополнительных накладных расходов на переходы IL-> C++ и сохранить малую среду выполнения (без JIT-компилятора и т. д.). Затем вы можете создавать прототипы в GDScript или создавать с его помощью моды, но затем вы также можете автоматически конвертировать его в C++ для дополнительной скорости, когда это необходимо для окончательных сборок.

Это также позволит сохранить существующие IDE (VC++ и т. д. и редактор Godot), к которым люди привыкли. На самом деле мы просто использовали VC++ для отладки нашего языка, и наш компилятор сгенерировал директивы #LINE в файлах .cpp, чтобы вы могли легко пройти исходный код и установить точки останова. Таким образом, теоретически вы могли бы создавать прототипы и отлаживать с помощью обычного GDScript в редакторе, но во время сборок с поддержкой «GDScript-> C++» вы все равно могли бы использовать свою IDE/отладчик C++ и устанавливать точки останова/отладки в файлах gdscript. Для нас сгенерированные файлы C++ были временными, и мы обращались к ним только в случае возникновения проблемы с генерацией кода.

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

Действительно, я не понял, что я должен был публиковать свои проблемы с производительностью в этой теме. Тут больше подошло: https://github.com/SuperUserNameMan/kart-zero/issues/1

@Ziflin На самом деле то, что мы обсуждали в других вопросах, это, во-первых, добавление минимального API C для написания модулей/скриптов godot с использованием простого C через минимальный API, который предоставляет весь API отражения Godot, это решило бы общую проблему, с которой мы сталкиваемся в отношении распределения привязок. к разным типам библиотек без перекомпиляции Godot

Примеры тому — ребята, которые хотят привязать steam API, ODBC, SQLite, Kinect и т. д. Все это требует написания модулей на C++. Выполнение этого с помощью C API решает проблему динамического связывания с C++ (что очень ограничено из-за того, что каждый компилятор или версия компилятора имеет свой собственный ABI, а также проблемы несоответствия размера символов, которые могут возникнуть между версиями Godot). C не имеет ни одной из этих проблем.

Как только это сработает, будет очень легко скомпилировать GDScript в C и загрузить его во время выполнения, когда игра запускается или экспортируется.

@reduz О, круто. То есть, по сути, вы говорите о возможности написать «подключаемую» DLL, которая может предоставлять GDScript то, что она хочет? (или я неправильно понял?)

Как только это сработает, будет очень легко скомпилировать GDScript в C и загрузить его во время выполнения, когда игра запускается или экспортируется.

Работает ли это для тех, кто хочет написать dll, в которой есть, скажем, несколько новых типов, производных от C++ Node?

Немного грустно, что новой поддержки «модулей» C++, кажется, достаточно, чтобы исправить некоторые проблемы с DLL.

Почему бы не использовать встраиваемый язык сценариев, такой как lua ​​или Ruby?

@jersten, потому что читал документы - http://docs.godotengine.org/en/latest/reference/gdscript.html

@Ziflin да, но вам придется использовать C API через отражение (хотя вы можете запросить указатели функций через отражение, так что это должно быть достаточно быстро ..). Цель состоит в том, чтобы в основном иметь простой способ загрузки DLL, который позволяет избежать проблемы с ABI, а также простой способ скомпилировать GDScript в C и загрузить его как .so.

Я собираюсь скинуть свои 2 цента здесь за то, что стоит. Я никогда не программировал на C#, а только на Java. Хотя я лично предпочел бы Java, потому что использовал ее и она мне понравилась, на самом деле я предпочитаю C# Java. C# — это то, что используют разработчики игр Unity, поэтому его использование сделало бы Godot частью экосистемы инди-разработчиков, созданной Unity. Кроме того, Java даже не является хорошим выбором, если вам нужен язык JVM. Есть и другие лучшие языки, которые компилируются в JVM.

Я думаю, что люди все равно упускают суть. C#/Java != язык сценариев. GDScript достаточно; достаточно прост в освоении и т. д.

Добавление такого языка, как Java (создать JVM для каких целей?! Синтаксис?! Требовать JVM с определенной версией для работы?!?) или C# (Реализовать моно и клаудить движок или создать свой собственный?) отравит движок .

Если есть проблема с GDScript, на нее нужно указать; а потом попытались исправить.

Я не согласен. Я чувствую, что C# привлечет множество разработчиков Unity или разработчиков, знакомых с C-подобными языками, предоставляя хорошую альтернативу Python, такому как GDScript. Последней частью головоломки будет визуальный сценарий, который привлечет художников, не привыкших к программированию. Это должно охватывать практически всех.
Также независимо от того, что вы кодируете, вам все равно нужно изучить классы и функции Godot, которые будут одинаковыми на любом языке.

Всем тем, кто спорит о C#, потому что разработчики Unity знают его, обратите внимание: многие разработчики Unity ни хрена не знают о том, как программировать на C#. Что они знают, так это как использовать API Unity, который так уж получилось, что имеет привязки к C#. Вы приводите их в Godot, даже если это C#, они все равно не будут знать, что, черт возьми, они делают, и будут так же потеряны, как предоставление им другого языка программирования.

Включение любых дополнительных языков — это просто дополнительные накладные расходы и больше, чем проект должен поддерживать, чего в нем не должно быть.

Я много думал об этом, и моя главная забота о поддержке чего-то вроде C# заключается в том, что большинство людей, которые будут его использовать, будут пользователями Unity, пришедшими в Godot. Понятно, что мы не будем включать C# в официальные шаблоны, и я очень сомневаюсь, что они сами будут собирать модуль...
Может оказаться, что поддержка языка, которым будут пользоваться лишь немногие, потребует больших усилий.

Я думаю, что есть недоразумение:

• Они видят GDScript и думают, что GDScript не уступает C#; отсутствует фундаментальный момент, что C# не является языком сценариев.
• Из-за вышеуказанного факта, когда кто-то говорит "Java или C#"; на самом деле они просят переписать движок на C#/Java или добавить некоторые привязки для поддержки этих языков (смеется, нет).

Поскольку я предполагаю последнее; отладка в C#/Java — кошмар на многих платформах; поскольку оба эти языка не являются независимыми от платформы (в b4 есть среды выполнения практически для всех ОС); это превращается в «Пиши один раз, отлаживай везде» (вот почему игры, написанные для Monogame, сначала выходят для Windows, а затем, в конечном итоге, для Linux/Mac, потому что разработчикам приходится отлаживать для этих платформ). Вот почему обновления JVM ломают приложения.

Добавление поддержки этих языков не добавляет ценности движку.

Если аргумент «жаловаться на разработчиков Unity»; затем необходимо подготовить документацию, чтобы помочь разработчикам Unity перейти; что различия в планировке и т. д.

Вот почему я сказал в конце, что не имеет значения, какой язык вы используете, вам все равно нужно будет изучать классы Godot API и все такое. Разве разработчики Unity не станут экспертами по инстаграму, потому что они знают C#. Я думаю, это скорее "аура добра" для Godot, если он поддерживает C #. Люди чувствуют, что знают больше, и внезапно Годо стал более доступным и не таким страшным. Самый негативный момент в Godot от пользователей, не являющихся пользователями Godot, заключается в том, что у него есть собственный язык сценариев. Как пользователь Godot знаю, что это чушь, потому что GDScript — забавный и простой язык, но для постороннего он может показаться непривлекательным.
Я не могу говорить с точки зрения разработчиков, но, возможно, это больше усилий, чем того стоит, если только разработчики не получат что-то от реализации C #, тогда оно того стоит. В конце концов, это решение ведущих разработчиков, и что бы они ни решили, я буду с ним согласен. Уверен, это будет хорошее решение.

Я согласен с вами в том, что GDScript немного отталкивает, потому что это практически неизвестный язык. Но после того, как я прочитал, почему Lua и Python были удалены, и о преимуществах добавления GDScript, я стал меньше беспокоиться.

Еще один момент, который может иметь значение: есть еще один движок под лицензией MIT, который уже поддерживает C# и больше похож на Unity, Atomic Game Engine . Я предлагаю всем людям, которым отчаянно нужно что-то максимально близкое к Unity, попробовать это.

Я просто добавлю свои 2 цента здесь. Для меня большим преимуществом C# является производительность, хотя с ним проще работать, чем с C++. GDScript, будучи динамически типизированным и все такое, очень быстро пишется, но никогда не будет сверхбыстрым в работе (хотя он может быть довольно сильно оптимизирован, что и планируется). Модули C++ работают очень быстро, но с ними неудобно работать; C++ не совсем дружелюбный язык, и необходимость перекомпилировать движок для их использования не совсем оптимальна. Для меня C# — своего рода компромисс: намного быстрее, чем GDScript, и при надлежащей поддержке с ним намного проще работать, чем с модулями C++.

При всем при этом это не обязательно должен быть С#. Насколько я понимаю, все, что имело бы аналогичный эффект, подойдет, будь то статически типизированный скомпилированный / JIT GDScript или что-то еще, например Swift или что-то в этом роде. C# может быть лучшим для «маркетинговых целей»; даже без подобного API разработчикам из других движков/фреймворков, вероятно, будет с ним удобнее. Модифицированный GDScript может быть проще в реализации и, вероятно, будет намного лучше интегрирован.

Я знаю, что ветка уже очень длинная, но, пожалуйста, прочитайте все вышеприведенные сообщения, прежде чем публиковать что-то свое. Аргумент, что C# собирался привлечь людей и был очень удобен для пользователей Unity, не станет более весомым, если его упомянут дюжину раз.

Посмотрите здесь, почему imho C# отлично подходит для Unity и плохо для Godot, посмотрите здесь, почему imho добавление C# приведет к грязному коду не только в ваших собственных проектах, но и в онлайн-руководствах, грядущем хранилище ресурсов и т. д., и посмотрите здесь, почему imho Аргумент о том, что людям пришлось узнавать много нового при переходе с C# на GDScript, недействителен.

Позвольте мне добавить комментарий к аргументу о том, что C# привлечет новых людей.
Почему мы хотим, чтобы больше людей использовали Godot? Я полностью понимаю, что проекты с открытым исходным кодом нуждаются в сообществе, которое

• добавляет функции
• исправляет ошибки
• создает повторно используемые активы
• вносит предложения по новым функциям
• находит ошибки или проблемы с рабочим процессом
• пишет учебники

но всем вышеперечисленным нужны люди, которые понимают и ценят основную идею движка. Люди, которые добавляют ненужные функции в библиотеку, не помогают, и было более одного проекта, пострадавшего от таких функций, иногда вплоть до того, что проект был заброшен или разделен.
Unity особенно страдает от людей, которые пишут учебники, даже если они на самом деле не понимают, что делают, что в значительной степени является ошибкой C#.

Если люди даже не хотят или не могут изучать такой простой язык, как GDScript, то весьма сомнительно, что они потратят время, чтобы полностью понять философию дизайна, лежащую в основе Godot, прежде чем они начнут активно вносить свой вклад в сообщество. («Активный вклад» означает что угодно, от отправки запросов на вытягивание до публикации своего мнения о Godot на Facebook.)

Godot не коммерческий двигатель. Unity заинтересована в том, чтобы привлечь как можно больше людей, потому что все они являются потенциальными клиентами и рекламой движка. Конечно, было бы неплохо иметь большое сообщество пользователей, которые ценят Godot таким, какой он есть, но нет смысла жертвовать некоторыми качествами Godot, чтобы угодить большему сообществу.

Люди @Warlaan обычно не хотят тратить время впустую, и они будут использовать любые фрагменты кода, которые найдут, при создании своих проектов, особенно в начале, когда вы учитесь. Для новичков ваши пункты имеют небольшое значение, потому что они в конечном итоге изучат тот язык, на котором написаны фрагменты кода, которые они используют. Я знаю это, потому что именно так я учился, глядя на примеры, и я не знал GD Script, но я выучил его. Проблема не в том, что лучше или как это повлияет или усложнит учебные пособия и т. д. Проблема (для меня) в том, что C# в большей степени, чем любой другой язык, сделает Godot частью этой инди-экосистемы разработчиков, частью которой является Unity. Дело даже не в Юнити, а в Годо.

РЕДАКТИРОВАТЬ: удалены некоторые излишне резкие выражения ;-)

@trollworkout Без обид, но ты не совсем понял мою мысль, и у меня такое ощущение, что ты тоже не очень хорошо обдумал то, что сказал.

1. Да, люди не хотят терять время. Полные спецификации GDScript: несколько экранов. Книги, объясняющие C#: обычно не менее 500 страниц. Я потратил несколько дней на изучение GDScript и совершенно уверен, что в нем нет ни одной функции, о которой я не знал бы. Я много лет работал с C# как профессионально, так и в свободное время (используя Window Forms, WPF, XNA и Unity), и до сих пор нахожу фрагменты кода, в которых используются функции, которые я не до конца понял. Просить С#, потому что это было менее пустой тратой времени, на самом деле не имеет смысла.
2. «новички в конечном итоге изучают тот язык, на котором написаны фрагменты кода, которые они используют» — см. пункт 1. Представление о том, что вы можете изучать C# по фрагментам кода, далеко от истины. Вещи, которые вы можете выучить таким образом, настолько просты, что вам потребуется не более нескольких дней, чтобы «выучить» другой язык. Вы сами сказали, что таким образом выучили GDScript.
3. «C# сделает Godot частью этой экосистемы инди-разработчиков». И что это должно означать?
   Не могли бы вы использовать фрагменты кода Unity в C#-Godot? Нет.
   Можно ли повторно использовать активы Unity в C#-Godot? Нет.
   Не могли бы вы прочитать руководства по Unity и дословно применить их к C#-Godot? Нет.
   Итак, о какой «экосистеме инди-разработчиков» вы говорите?

Как сказал бумажный нищий, есть много движков и библиотек на выбор.
Вы хотите систему компонентов, как у Unity? Посмотрите на Atomic Game Engine.
Вы хотите продолжать использовать C# в движке, но хотите отказаться от системы компонентов? Посмотрите на CryEngine/Luberyard.
Вы хотите продолжать использовать C#, но хотите отказаться от движка? Посмотрите на моногейм.

Мысль о том, что добавление C# в Godot помогло новичкам, ошибочна, поскольку вы сами сказали, что научились писать сценарии в Godot, просматривая фрагменты кода. Если вы учитесь работать с движком, разве вам не нужен язык, который неявно сообщает вам, как работает движок, а не тот, который предназначен для тысяч различных вариантов использования?

Я просто добавлю свои 2 цента здесь. Для меня большим преимуществом C# является производительность, хотя с ним проще работать, чем с C++. GDScript, будучи динамически типизированным и все такое, очень быстро пишется, но никогда не будет сверхбыстрым в работе (хотя он может быть довольно сильно оптимизирован, что и планируется). Модули C++ работают очень быстро, но с ними неудобно работать; C++ не совсем дружелюбный язык, и необходимость перекомпилировать движок для их использования не совсем оптимальна. Для меня C# — своего рода компромисс: намного быстрее, чем GDScript, и при надлежащей поддержке с ним намного проще работать, чем с модулями C++.

Все упомянутые вами проблемы с С++ действительны и могут быть исправлены с помощью # 3936. Мы обсуждали это уже много раз, но просто для ясности вот проблемы с GDScript, которые мы можем объективно распознать:

1. Плохая поддержка сторонних библиотек.
2. Плохая работа

Возможность писать части на C++ легко устраняет обе эти проблемы. C# (или другой язык) также исправит это, но с дополнительным временем выполнения, худшей производительностью и кросс-платформенной поддержкой, а также необходимостью большого количества дополнительной работы (тогда как Godot уже написан на C++). Таким образом, рациональным выбором является использование того, что уже есть (C++), и его улучшение, и, конечно же, устранение этих проблем с помощью GDScript.

Я быстро прочитал эту ветку и увидел, что GDScript to C был предусмотрен.

Если это выбранный путь, было бы неплохо подумать о встраивании компилятора tcc C в редактор для компиляции сгенерированного C. Он имеет очень быстрое время компиляции, очень мал и легко встраивается. Возможно, это был бы лучший способ ускорить процесс.

TCC распространяется под лицензией GNU Lesser General Public License.

(источник)

Это делает его, вероятно, непригодным для включения в Godot. Он также, похоже, больше не поддерживается.

@Warlaan Мне не нужно слишком много думать. К этому моменту мы все сказали одно и то же уже около 10 раз, я думаю, мы в значительной степени знаем, на чем мы все стоим. Кроме моих 2 центов и нескольких идей, мне больше нечего добавить, так как я не разработчик и не знаю движок наизнанку. Я позволю тем, кто лучше знает, говорить. Я просто хотел выразить свою поддержку и все.
Не по теме:
Но да, что касается пункта 2, из-за которого вы подняли много шума, вам пришлось отредактировать свой комментарий. Итак, вы говорите, что не можете выучить язык на примерах? Я думаю, что вы ПРЕДПОЛАГАЕТЕ, что люди не могут его изучить, если они не прочитают 500-страничные руководства, которые известны С#, потому что вы говорите, что причина 1 отклонить его. Что ж, я живое доказательство того, что вы не правы. Как вы думаете, как я выучил GDScript? С API и демонстрационными примерами и задавая вопросы. Имейте в виду, что до того, как я начал, у меня не было знаний о Python, поэтому все в нем было довольно чуждым. В качестве примечания мне интересно, сколько людей покупают руководства по libGDX по сравнению с тем, сколько людей на самом деле гуглят «как сделать X в libGDX», возможно, почему хранилище активов такое крутое в Unity. На этом я пока закончил, потому что мне больше нечего сказать.

( @Calinou : Беллард позволил форку TCC стать BSD или MIT. Но в прошлый раз, когда я проверял, разработчик форка не выпустил исходный код. Так что, может быть, Беллард согласился бы позволить сообществу Godot повторно лицензировать TCC?)

Я не уверен, что TCC так же хорош, как GCC или Clang в качестве компилятора - их размер позволяет поддерживать множество архитектур и довольно оптимизированную генерацию кода (более высокую производительность).

Как насчет Godot, опционально зависящего либо от GCC, либо от Clang для компиляции C? Они устанавливаются на машины большинства людей, которые в любом случае будут создавать игры (поэтому размер не имеет особого значения), и это делается так, как это делают другие языки, которые компилируются в C (например, Chicken ). Они также поддерживают C++, если это когда-нибудь понадобится.

Если они сделаны необязательными зависимостями, те, у кого не установлены GCC или Clang (что странно для разработчика, который должен создавать игру для распространения, но в любом случае), могут просто использовать интерпретатор GDScript, как он есть прямо сейчас.

Я предложил использовать TCC в качестве JIT для GDScripts. Так что самой важной особенностью была скорость компиляции. И я думаю, что результаты уже могут быть намного быстрее, чем текущее решение.

Большинству людей нужны C/C++ из-за производительности и Lua/Javascript из-за того, что их проще и быстрее писать, так почему бы не взять лучшее из обоих миров?

Ним - http://nim-lang.org/

Эффективный, как C, выразительный, как Python, и гибкий, как Lisp

Плюсы:

• Компилируется в C, C++, Obj-C или JS (http://nim-lang.org/docs/backends.html)
• (Python/Pascal), как (https://learnxinyminutes.com/docs/nim/)
• GC или руководство ( http://nim-lang.org/docs/gc.html )
• Может использоваться в другом месте, кроме godot
• Кроссплатформенность (Windows, Linux, OSX, Mobile)
• Помогает преобразовать код C в Nim
• Поддерживает библиотеки C
• Настраиваемый компилятор
• Лицензия Массачусетского технологического института
• Открытый источник
• Безопасный тип

Минусы:

• Требуется компилятор C/C++ на компьютере разработчика -> gcc , vcc , llvm_gcc , icc , clang или ucc _(на мой взгляд, не совсем афера)_
• Небольшое сообщество
• Еще не 1.0

Список TODO Нима невелик, он близок к 1.0:
https://github.com/nim-lang/Nim/blob/devel/todo.txt

как сказал бумажный нищий (о наличии компилятора на компьютере разработчика):

Они установлены на машинах большинства людей, которые в любом случае будут создавать игры.
https://github.com/godotengine/godot/issues/5081#issuecomment -227706106

https://hookrace.net/blog/what-is-special-about-nim/
https://hookrace.net/blog/what-makes-nim-practical/

https://github.com/nim-lang/Nim/wiki/Nim-для-C-программистов
https://github.com/nim-lang/Nim/wiki/Nim-for-Python-программисты

Это не мое любимое решение, но если вам нужно пойти по этому пути, я настоятельно рекомендую вам использовать Haxe ( haxe.org ) вместо Nim.

Я не могу комментировать лицензию Haxe (сам компилятор использует «GPLv2+», стандартная библиотека использует MIT), но все остальные факторы делают его лучшим выбором, имхо.
Это проверенная платформа (в настоящее время в версии 3.2.1), в отличие от Nim, у которого еще даже нет версии 1.0, но, что для меня намного важнее, синтаксис намного ближе к другим известным языкам. Читая примеры Nim, мне кажется, что разработчики этого языка пытались найти необычные и/или некрасивые решения.

Но, как я уже упоминал, это не мое любимое решение, и вот почему:
Промежуточные языки, такие как Nim или Haxe, имеют много «семантических зависимостей». Я не имею в виду зависимости от библиотек или исполняемых файлов, которые должны присутствовать, я имею в виду, что они относятся к другим языкам. Теперь, как я уже сказал, языки больше не инструменты, это культуры. И даже если вы рассматриваете их только как инструменты, у них разные основные домены, для которых они были созданы. Например, вполне логично, что команда "echo" выводит текст на стандартный вывод при вводе на стандартный ввод. Использование одной и той же команды в пакетном сценарии имеет смысл. Следуя этой логике, понятно, что PHP использует ту же команду. Использование его в языке общего назначения, таком как Nim, не имеет смысла, так как в основном все другие языки общего назначения имеют методы, называемые чем-то с «записью» или «печатью» в имени.
Я понятия не имею, почему Nim до сих пор использует «echo» в качестве имени для этой команды, но это то, что вы можете часто наблюдать с Haxe, и я ожидаю от Nim в будущем, если не уже в первом выпуске. . Например, стандартная библиотека Haxe содержит как метод substr(int, int), так и метод substring(int, int). Один из двух возвращает подстроку из первого во второй индекс, другой возвращает подстроку из первого индекса с длиной второго аргумента. Причина, по которой оба существуют, заключается в том, что, поскольку язык может использоваться для замены языков разных типов, у него есть пользователи с разных платформ, и если только кто-то с очень сильной рукой не решает, что входит в эту библиотеку с открытым исходным кодом, а что нет. вы легко получите такую ​​смесь стилей кодирования.

Очень важно выбрать правильные инструменты для правильной работы. Такие языки, как Haxe (или C#, если уж на то пошло), пытаются дать вам один язык, который подходит всем, поэтому чаще всего вы используете «только один инструмент», который, к сожалению, выглядит вот так .

Я хотел бы добавить свои 2 цента после того, как некоторое время поработал с Godot.
То, что я хотел бы видеть (и также рассматривал, с... ограниченным успехом), это C++ как первоклассный язык в Godot.
Написание сложной вычислительной логики (разрешение столкновений, физика, преобразования и ИИ) на C++ и создание сценариев узлов с использованием GDScript (триггеры, условия, анимация и звуки).

GDScript довольно прост в освоении, поэтому в этом отношении Godot немного ближе к Gamemaker, чем к Unity.
Но после того, как я написал 3 небольшие игры и поигрался с кучей демок, я должен сказать, что GDScript не хватает ни на что, кроме самых простых игр.

Файлы кода становятся слишком длинными, а в редакторе кода отсутствует множество полезных функций, которые можно найти в других IDE, таких как: свертывание областей, областей, переход к началу/концу текущей области.

GDScript также не хватает многих основных функций процедурных языков, таких как: правильные _ для _ циклов, правильные _ do...while _ циклы (он поддерживает _ while _ циклы), _ switch...case _, _ тернарный оператор _ , _ перечисления _.
_ Отсутствует осведомленность об отношениях между классом и сценой _, поэтому, если он не создан заранее, это «внешний» класс, и его необходимо предварительно загрузить.

Кроме того, учитывая природу GDScript, в нем нет ссылок на функции и шаблонов.
В этом нет ничего примечательного, но это очень раздражает.

Глаз776; GDscript непригоден только для простых игр, если вы решите игнорировать другие функции (например, использование узлов и обратных вызовов, где это возможно) вместо того, чтобы придерживаться исключительно таких функций, как _get_overlapping_bodies()_

Причина в том, что упомянутые обратные вызовы и использование узлов намного быстрее, чем попытки сделать все с помощью одного большого скрипта и очень небольшого количества узлов. Дерево становится больше, но это не проблема с системой инстансов сцен Godot.

Например, объекты, которым нужна постоянная скорость вращения, могут просто использовать для этого анимацию вместо того, чтобы задавать вращение вручную с помощью GDscript, объекты, зависящие от времени, могут использовать узлы таймера и так далее. Я думаю, что одним из непосредственных (и простых) способов обеспечить более быструю игру будет выбор из большего количества типов узлов (каждый со своими обратными вызовами и соединениями).

Файлы кода становятся слишком длинными

Вы имеете в виду такие скрипты? https://github.com/Algorithmus/CastlevaniaClone/blob/master/game/players/player.gd
Как вы думаете, C# может предотвратить это? Лично я не знаю. На самом деле это упрощает рефакторинг и обнаружение ошибок на ранних этапах в этих длинных сценариях из-за инструментов (да, когда люди имеют в виду C#, они часто неявно имеют в виду VS) и статической типизации, хотя ошибки пути к узлу невозможно обнаружить, пока игра не запустится. Но помимо этого, хороший дизайн и использование узлов могут значительно упростить скрипты.

в редакторе кода отсутствует множество полезных функций, которые можно найти в других IDE, таких как: свертывание областей, областей, переход к началу/концу текущей области.

Они могут быть добавлены в будущем, если вы попросите об этом, хотя вы можете без проблем использовать внешний редактор (https://atom.io/packages/lang-gdscript), у Godot даже есть службы автозаполнения.

Если вы на самом деле делаете ОГРОМНУЮ игру, вероятно, вы захотите расширить Godot с помощью C++.
На самом деле, в настоящее время я нахожу это немного пугающим из-за процесса восстановления двигателя, но для этого есть причины .

Нет осознания отношения класс-сцена

Что ты имеешь в виду? Вы знаете, что можете поместить сценарий в корень сцены, верно? Также редакторы C# не могут угадать, что находится в сцене, где они используются, в то время как GDScript может.

Кроме того, учитывая природу GDScript, в нем нет ссылок на функции и шаблонов.

Есть funcref и signal , если вы ищете что-то похожее на лямбда-выражения и события, а шаблоны не нужны, потому что язык динамичен. Динамические языки часто предпочитают использовать утиную типизацию вместо интерфейсов и дженериков. Кроме того, композиция над наследованием очень хорошо работает, если вы хотите повторно использовать вещи.

В GDScript также отсутствуют многие базовые функции процедурных языков.

Я немного согласен. Некоторые из них были запрошены, но я не помню выпусков, вам придется поискать. Например, я хотел бы видеть for , который может перебирать что-то еще, кроме целочисленных диапазонов и контейнеров (с плавающей запятой?), поэтому я использую while . Это действительно немного раздражает, но ничего серьезного.

Вы имеете в виду такие скрипты? https://github.com/Algorithmus/CastlevaniaClone/blob/master/game/players/player.gd

Я должен сказать, что даже если файл длинный, я видел намного хуже, и он все еще довольно читабелен, несмотря на то, что код довольно процедурный. Теперь я наконец понял, почему простой синтаксис лучше для GDScript: он лучше всего подходит для средней игровой логики, которая в основном состоит из if и вызовов функций.

Я бы хотел, чтобы кто-нибудь утверждал, что один и тот же файл, написанный на C#, легче читать или писать или предлагает какие-либо практические преимущества, кроме производительности (которая в любом случае хуже, чем у C++). Я думаю, что C# был бы излишним для такого рода сценариев, которые более сложны, чем сценарии, используемые в некоторых профессиональных 2D-играх.

Я немного согласен. Некоторые из них были запрошены, но я не помню выпусков, вам придется поискать. Например, я хотел бы видеть for, который может перебирать что-то еще, кроме целочисленных диапазонов и контейнеров (с плавающей запятой?), поэтому я использую while. Это действительно немного раздражает, но ничего серьезного.

Не могли бы вы немного подробнее остановиться на части for и некоторых примерах того, что вы имеете в виду в псевдо-GDScript?

@paper-pauper то, чего не хватает GDScript, не связано с C#, но, например, for i in range(-PI, PI) не работает в GDScript, как и for i=0, i < size and stuff, ++i . Я также хотел бы написать троичное вместо того, чтобы писать три строки-если. Но, как я уже сказал, в трекере уже есть проблемы с ним, и это не помешает мне использовать GDScript :p

Но даже если все ваши сценарии состоят максимум из 200 строк и относительно хорошо спроектированы, если в вашей игре их тысячи, у вас возникнут проблемы с поддержкой и рефакторингом этой кодовой базы: и это не столько из-за языка, сколько из-за из-за инструментов : большая часть популярности C# связана с тем, что Visual Studio чертовски хорошая IDE для него. Я почти уверен, что если Godot интегрирует подходящие инструменты (определение перехода, надежное переименование классов/функций/членов, поиск всех ссылок и т. д.), работа с огромными кодовыми базами GDScript станет намного проще. Вообще говоря, это то, что я хотел бы видеть в Godot, как он может хорошо масштабироваться для БОЛЬШИХ игр, потому что пока я не видел (включая свои собственные проекты).

for i in range(-PI, PI)

Это заставляет мою голову вращаться вокруг своей оси, пока не достигнет деления на ноль и не начнет разрушать энтропию. Я надеюсь, что ни один язык не реализует такое непредсказуемое утверждение. Что оно делает? Перебирать целые числа между -PI и PI (т.е. -3, -2,..., 2, 3) или между кратными PI (т.е. -PI и 0), или перебирать числа с плавающей запятой, которые представляют собой шаг по умолчанию вуду, например 0.176 или ln(2) , который какой-то языковой программист счел наиболее подходящим?

@akien-mga ой извините. Я действительно должен был добавить аргумент шага xD, но он все еще не работает. Вот проблема, которую я сделал для нее https://github.com/godotengine/godot/issues/4164

Я согласен, что Годо скучает по инструментам. Основная проблема заключается в том, что GDScript использует утиную типизацию, что затрудняет понимание того, что есть что, и, таким образом, затрудняет выполнение некоторых действий, таких как «найти ссылки» или «перейти к определению».

Планируется добавить в GDScript подсказки типов, но, поскольку это будет необязательным, я не уверен, насколько это можно улучшить. Это, безусловно, значительно улучшит завершение кода и может облегчить работу над лучшими инструментами.

@vnen Режим EMACS для GDScript в (M)ELPA уже был бы шагом в правильном направлении, в моей книге :)

Ах да, почти забыл об этих двух проблемах, которые, как ни странно, на самом деле замедляли меня на практике:

• Аргументы не являются частью сигнатуры функции. Это означает, что вы не можете переопределить функции.
  На практике наличие function doFoo(a,b,c,d) и function doFoo(a,b) в одном классе приведет к сбою компиляции. В итоге я переименовал их в doFoo4(a,b,c,d) и doFoo2(a,b) и провел рефакторинг нескольких файлов сценариев.
• Поскольку нет поддержки перечислений, все флаги и коды возврата по необходимости являются целыми числами, поэтому вам нужно угадать их, и многие из них до сих пор недокументированы.

PS: очевидно, что функции не были буквально названы doFoo . ;)

РЕДАКТИРОВАТЬ: @Ace-Dragon: Другие движки научили меня, что сложные встроенные узлы/компоненты/и т. д. может и будет меняться, ломая игру в процессе. Вот почему, кроме базовых обратных вызовов триггеров (коллизии, значения, таймеры), я предпочитаю не слишком полагаться на них.
Я также не очень большой поклонник парадигмы сигнальных слотов, поэтому стараюсь избегать ее, если это возможно. С другой стороны, я также предпочитаю потоки сопрограммам, называйте меня луддитом :)

@Zylann : ~ 1200 LOC? ... пфффф Нет, я говорю о реальной сделке ... 20 000 + LOC на файл. У разработчика RPG, использующего Unity, название которой должно оставаться неназванным (нет, я на них не работаю), обычно есть классы с более чем 25 000 локаций. Затем они снова делают все свои функции статическими и используют C#, как если бы это был C. :fearful:

Извините за не по теме.

@eye776 Eye776 Я не могу придумать ни одного динамического языка, который позволял бы переопределять (в некоторых случаях его можно подделать с аргументами по умолчанию), но было бы неплохо использовать его в GDScript.

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

@eye776 Я также никогда не видел динамических языков с переопределением функций. GDScript имеет параметры по умолчанию, поэтому их можно использовать вместо них.

Кроме того, кто тот сумасшедший, который делает 20K+ LOC в одном файле? Проблема здесь не в инструменте... Во всем исходнике Godot я не смог найти ни одного файла с 10K LOC.

С чем я согласен, так это с тем, что нужно немного больше любить C++. Но для использования, которое вы указали ранее, я согласен только с ИИ. И еще процедурная генерация. Теперь, если вы переделываете физику движка, рендеринг и т. д., то я говорю, что вы даже больше не используете Godot, вы просто сделали форк. Если вы не можете полагаться на встроенные типы, зачем вам движок?

Конечно, GDScript не идеален (как и любой другой язык). Он также не высечен в камне. Перечисления, switch/case и троичные операции — некоторые вероятные дополнения в будущем (по ним уже есть открытые вопросы). Просто потому, что у него чего-то нет прямо сейчас, это не значит, что этого никогда не будет.

Наконец, «сомнения» не очень помогают. Что нам нужно, так это тесты и варианты использования. Уже есть довольно сложные игры, написанные на GDScript, так что я не вижу, чего на самом деле не хватает.

@vnen просто для удовольствия: godot/drivers/gles2/rasterizer_gles2.cpp - это 11K LOC :p (это самое большое, что я нашел, но это редкое исключение).

@внен

Если вы не можете полагаться на встроенные типы, зачем вам движок?
Ну и как качественный кроссплатформенный контекст для начала. Но это не значит, что я буду писать свои собственные классы спрайтов или моделей.

Годо однажды сжег меня еще в марте (v 2.0.1). Я возился с камерой и персонажем от 3-го лица и пытался использовать собственную физику Годо для движения (перетаскивание и силы) и заставил его работать.
Следующее обновление минорной версии (v 2.0.2) в основном ломало скорость персонажа (в 2-3 раза быстрее) для тех же самых значений.
Выяснил, что лучше просто оставить Kinematic и делать свою собственную "физику".

Кроме того, независимо от Godot, я много раз обжигался, полагаясь на автоматизированные вещи, такие как раскадровки XCode.
Я как бы перестал заискивать перед блестящими и молиться о том, чтобы любой код, автоматически сгенерированный IDE за моей спиной, не мешал моему.

В любом случае, мне очень, очень жаль, что я сорвал ветку.

@eye776 Вы проверяли изменения коммитов с 2.0.1 на 2.0.2, чтобы увидеть, что сломало вашу игру? Это могла быть ошибка, и сообщение о ней могло бы принести пользу всему сообществу.

Моно или CoreCLR? И почему?

Мононуклеоз:

• Лицензия Массачусетского технологического института
• стабильный
• возможность быть брошенным
• хорошая документация

CoreCLR:

• Лицензия Массачусетского технологического института
• все еще не 1.0 (в настоящее время это RC2)
• маленький
• плохая документация

Мы используем Mono, потому что он развертывается на мобильных устройствах и в Интернете. я думаю вот
нулевой шанс, что его забросят, потому что он гораздо более портативный. Моя догадка
заключается в том, что обе кодовые базы в конечном итоге сольются.

В четверг, 4 августа 2016 г., в 13:45, Хуберт Ярош, [email protected]
написал:

Моно или CoreCLR? И почему?

Мононуклеоз:

• Лицензия Массачусетского технологического института
• стабильный
• возможность быть брошенным
• хорошая документация

CoreCLR:

• Лицензия Массачусетского технологического института
• все еще не 1.0 (в настоящее время это RC2)
• маленький
• плохая документация

—
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/godotengine/godot/issues/5081#issuecomment-237611905 ,
или заглушить тему
https://github.com/notifications/unsubscribe-auth/AF-Z2zRjC8u_owFzCCyeqIhF8W5XqCtLks5qchchgaJpZM4Ivn7R
.

В дополнение к тому, что @reduz упоминал выше, API инкапсулирован, поэтому при необходимости несложно перейти на CoreCLR позже.

CoreCLR: все еще не 1.0 (сейчас это RC2)

Он достиг стабильной версии 1.0 14 июня.

Моно: возможность быть брошенным

На основании чего?

Моно: хорошая документация

Ах ах ах

На основании чего?

Зачем Microsoft разрабатывать три стека .NET? Это не хорошо с точки зрения ресурсов. (.NET Framework, моно, .NET Core)

Ах ах ах

Я проверил оба документа о взаимодействии C++/C# (что нам нужно для godot), и это вполне нормально задокументировано в Mono. В coreCLR мне пришлось копаться в их коде и просить разработчиков о помощи, чтобы мое приложение заработало.

В справочнике слишком много недокументированных функций, битые ссылки...

Теоретически я здесь необъективен... Но надеюсь, что мои доводы объективны...

• Я не вижу спада в развитии Mono: https://github.com/mono/mono/graphs/contributors
• Разработка для Mono для Windows никогда не была такой сильной, как сегодня (своеобразное доказательство (без привязки тонны коммитов) https://github.com/mono/mono/pull/3231 Мигель говорит: «Поскольку у нас теперь есть настоящие сопровождающие»). Создание предыдущий пункт еще понятнее
• Встраивание API в Mono проверено в бою (не только Unity, есть много других частных пользователей)
• Mono TODAY работает на PS4, Android, Windows, iOS BITCODE (на это ушли годы работы), AppleTV и многих других платформах...

Так что имхо, если вы хотите реализовать это в ближайшем (менее 3 лет) будущем и на большинстве игровых платформ... Выбирайте Mono.

Привет,

Некоторые комментарии:

• В дополнение к платформам, перечисленным Дэвидом Карласом, мы также добавляем встроенную поддержку WebAssembly, XboxOne, UWP и Win64.
• Совместно используемый образец можно также выполнить либо с помощью виртуальных методов (более быстрая отправка), либо с помощью событий C#.
• C# исторически был в авангарде многих языковых инноваций, черпая хорошие идеи из любого места. Он популяризировал и вывел на массовый рынок многие идеи из языковых исследований, которые мы сейчас принимаем как должное, такие как итераторы, нестираемые дженерики, лямбда-выражения, асинхронное программирование, свойства, вызов платформы, но это один из языков, которые наиболее активно развивались на публике . Например, в следующей версии будет добавлено множество новых функций, в том числе мое любимое сопоставление с образцом.
• Как правило, Unity не демонстрирует современный C#, поскольку использует более старую среду выполнения. Надеюсь, это скоро изменится. Тем не менее, текущий Mono поддерживает все новые функции C#, в том числе «асинхронное» программирование, которое идеально подходит для игрового кода, поскольку вы можете писать его линейно, а компилятор автоматически переписывает ваш код как конечный автомат — например, сопрограммы или расширенные версия yield, используемая в Unity.
• Контексты синхронизации означают, что вы можете написать асинхронный код, который выполняется в определенном контексте. Например, у вас может быть выполнение, связанное с игрой, или выполнение, связанное с вводом-выводом, или выполнение, связанное с основным или фоновым потоком, — все это является частью системы.
• Во время развертывания у вас есть выбор между JIT-компиляцией или статической компиляцией (AOT) с LLVM или без него, так что вы в значительной степени работаете так же быстро, как C++, по модулю того факта, что C# выполняет проверки границ массивов (при этом, если вы используете собственный буферы, вы возвращаете свою производительность за счет безопасности)
• За последние несколько лет, учитывая сильное внимание Mono к мобильным устройствам, GC Mono был настроен не для серверов, а для интерактивных рабочих нагрузок. Наш новый GC представляет собой несколько поколений с небольшими питомниками, которые можно собрать очень быстро и не требуют сканирования всей кучи.

Что касается того, почему Microsoft разрабатывает несколько CLR (у нас есть три: CoreCLR для рабочих нагрузок JIT, семейство CoreRT для статической компиляции в UWP и Mono для мобильных рабочих нагрузок), это потому, что все они служат для немного разных целей. Внутренние компоненты сходятся там, где это возможно, например, в Mono теперь заменено около 60% основного кода кодом, который напрямую используется остальной частью .NET. Остается только выяснить, какая рабочая нагрузка лучше подходит для вас.

Вы можете начать с одной виртуальной машины сегодня и переключиться на другую в будущем. В настоящее время Mono имеет большую поверхность API, работает на мобильных устройствах, оптимизирован для интерактивных рабочих нагрузок и поддерживает больше архитектур (например, ARM64).

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

@migueldeicaza Добро пожаловать! Здорово, что вы решили принять участие в нашем обсуждении и заинтересовались Годо :+1: Надеюсь, вы останетесь с нами на некоторое время :)

Спасибо за хороший разбор @migueldeicaza! У меня есть два коротких вопроса к вам или другим разработчикам Mono.

1) Какова текущая настройка для отладки встроенного Mono в Windows с помощью Visual Studio? У Unity есть свой плагин, но мне не удалось найти ничего, кроме плагинов, которые подключаются к машинам Linux/OSX.

2) Каков рекомендуемый способ обработки перекомпиляции во время выполнения (компиляции, выгрузки и перезагрузки, скажем, сборки для игрового процесса или плагинов инструментов в редакторе)? C# (очень), к сожалению, не предоставляет метод Assembly.Unload(), а работа с AppDomains и проблемами между AppDomain кажется чрезмерно раздражающей в этой ситуации.

Для справки: не только Unity использует Mono — https://github.com/xamarin/urho (привязки C#/Mono для движка Urho3D) — он находится под лицензией MIT, поэтому мы можем легко найти их решение.

Мои два цента:

C# намного лучше подходит для программирования игр, чем другие языки аналогичного уровня, поскольку он поддерживает пользовательские типы значений. Это чрезвычайно важная функция для производительности, альтернативы которой у Java (и JVM в целом) буквально нет.

Ты получаешь:

• Математические типы с выделенным стеком, которые поддерживают математические операции и временные объекты без выделения кучи.
• Оптимизированные, удобные для кэширования непрерывные коллекции.
• Обобщения, использующие типы значений (включая примитивные типы)

Кроме того, в C# есть и другие функции, облегчающие вашу жизнь. Я не вижу смысла в использовании Java вместо C#, когда C# просто превосходит Java практически во всем, что имеет значение в программировании игр.

Всем привет,
Я не читал все вышеперечисленное (просто слишком много :) )
но у меня было несколько выходных, поэтому я сделал прототип модуля для godot, который действует как msDotNetHost, поэтому я могу предоставить некоторые результаты, которые я прошел, может быть, они будут полезны. К сожалению, мои каникулы закончились, и я снова стал кодить за деньги :), но это было/было весело :)

текущее состояние:
o) модуль расширяет класс узла, чтобы отображать события узла в netCode.
(init, tree_entered, ready, process, fixedprocess....)),
o) «сетевой модуль хоста/оболочки» выполнен (с использованием механизма хоста Microsoft dotNet)
он инкапсулирован в динамическую библиотеку, поэтому переход на Mono позже должен быть легким
o) методы dotNet связаны и вызываются (init, tree_entered, ready, process, fixedprocess....)
o) класс узла обернут и привязан к netAssembly (код, написанный вручную для прототипирования)
о) вызовы godot (из netCode) работают через самописный механизм привязки
(из dll в godot-exe), поэтому exe не нужно экспортировать функции.
o) из-за использования msDotNet в ближайшем будущем он привязан к Windows.

моя дорожная карта для включения .Net будет:

1. модуль для Godot с использованием механизма хостинга Microsoft .Net (сделано)
2. обертка godotКлассы
   (мое текущее состояние: пишу генератор обертки, который анализирует код godot C++,
   парсинг сделан, генерация продолжается)
3. вывести проект из состояния прототипа (завершить ребра, протестировать...)
4. написать механизм хостинга Mono, чтобы избавиться от оконных связей
5. каким-то образом включить Visual Studio для отладки моно, чтобы избавиться от xamarin/monodev (например, unity vs-plugin)
6. получайте удовольствие сотни новых разработчиков godot .net :)

некоторые вопросы:

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

2.
в настоящее время я создаю оболочку, которая оборачивает все методы godot в функции, чтобы их можно было легко вызывать через границу dll и границу c++/netCode. (собственный механизм привязки для netCode)
я не хочу менять код Godot (кроме кода моего модуля), чтобы оставаться совместимым.
также статичное, нестатическое, виртуальное невиртуальное заставило меня плакать, поэтому я выбрал этот путь.
любое лучшее решение для этого?

некоторые дополнительные мысли:

Microsoft .Net против моно:

я думаю, что не имеет значения, используете ли вы моно или msDotNet, потому что в большинстве случаев код dotNet работает без изменений на обоих. Единственная попытка поддержать оба — написать «хост» для каждого из них (это самая маленькая часть «GodotDotNet»). Я выбрал msDotNet для прототипирования.
ну, моно поддерживает многие платформы, msDotNet только окна, так зачем поддерживать/использовать msDotNet?
Ответ: производительность, отладка

мсдотнет:
Особенно при написании/прототипировании DotNetModule мне нужна/хочется FAST-компиляция и отладка, что означает, что ваш отладчик должен перейти в netCode из C++ и наоборот.
я выбираю VisualStudio, потому что он может отлаживать и то, и другое. НО только если вы используете msDotNet.
При этом вы меняете кусок netCode, нажимаете run и через 1сек! он скомпилирован и работает!!! включая возможность отладки в godot. (если вы ничего не изменили в годоте, то вам придется ждать обычно от 30 секунд до 1 минуты ... черт возьми, медленные scons! :) )

Мононуклеоз:
Mono должен быть конечной целью, об этом не говорится (независимость от платформы), но:
если кто-то использует моно, у вас большие проблемы с отладкой: у моно есть свой собственный механизм отладки!
для меня это большой удар по производительности, потому что, если вы не напишете моноотладочный плагин для VisualStudio (это сделала Unity), вы не сможете отлаживать моно-сетевой код в Visual Studio и отлаживать код С++ (есть хакерские решения, но ...).
Я попытался настроить решение на основе Mono, но в итоге я использовал параллельно VisualStudio (для С++) и xamarin/monodev (сетевой код).

Вывод:
состояние прототипа: msDotNet
Lateron: mono, для пользователей, не заинтересованных в отладке в godot/c++ и независимости от платформы.
после этого: создайте vs-плагин для отладки моно

С# против Java:
ответ ясен С#! Java для детей-скриптов! (о, что кодер С++ думает о разработчиках С# :))
нет, это была шутка :)
я не понимаю обсуждения ... когда система .net будет реализована, вы сможете использовать любой язык, который поддерживает dotNet, включая оба языка и многое другое.
это не тот случай, если система java поддерживается...

@Зифлин :
Вопрос 1:
тоже искал ... только monoRemotedebugger - это (не) решение atm :(
моя рекомендация, как указано выше: использовать хостинг Microsoft dotNet для прототипирования
затем в какой-то момент переключитесь на моно.
альтернатива:
запустите xamarin в его взломанном режиме, дайте ему прослушать локальный хост, установите точки останова, затем запустите свой проект в сравнении с тем, что я тестировал, он работает, но...
для меня это не решение! я хочу, чтобы "запустить и отладить за 1 секунду" - механизм, и это с 1 щелчком мыши!
В свободное время у меня не так много времени, поэтому моя главная цель — производительность.

вопрос 2:
еще не очень хорошо знаю моно, но я думаю, что вам нужно это сделать на С++, реализовать моно-хостинг, управлять им «извне» на С++.

Официальные привязки C# @CharlesWoodhill уже находятся в стадии разработки, и их можно увидеть здесь https://github.com/neikeq/GodotSharp/

круто, спасибо, тогда я знаю, как проведу следующие выходные ;)

Привет, я только что наткнулся на godotSharp, но он упал.

это его уронили.

Официальная версия, которую я слышал в IRC, была примерно такой:

@neikeq не любит выкладывать незавершенный код, поэтому работает в своем локальном филиале.

Что ж, приятно знать, что я собирался сделать свой собственный модуль, но, думаю, я мог бы также сделать это для Godot 2.2 или 3.0.

Релиза 2.2 не будет, разработчики Godot перенесли все функции 2.2 в 3.0.

Это мой первый комментарий. Я перешел из Unity, и переход на GDscript был мечтой. Я выучил язык менее чем за день. Мне нравится, насколько хорошо язык реализован в движке, и моя продуктивность значительно возросла.

Меня больше всего беспокоит то, что с добавленной поддержкой C# GDscript останется позади или увидит меньше развития после наплыва разработчиков Unity. C# — прекрасный язык, но не мой фаворит

Также меня беспокоит то, что Годо пытается быть больше похожим на другой двигатель, а не стоять сам по себе. Unity — невероятная история успеха, но не лучший движок, который я когда-либо использовал. Он раздут и глючит. Однажды он удалил весь мой проект без подтверждения. Работа с ошибками и вещами, которые не работали должным образом, была постоянной борьбой. Я не могу сосчитать, сколько раз мне приходилось полностью перестраивать сцену, над которой я работал, потому что что-то работало неправильно. Однажды я скопировал и вставил весь контент из старой сцены с ошибками в новую сцену, чтобы она внезапно заработала, несмотря на то, что обе сцены идентичны. Я потерял недели, охотясь за ошибками в физике, которые волшебным образом появлялись и волшебным образом исчезали.

Мне очень нравится, что Годо скудный и простой для понимания. Работать с Godot было все равно что играть на хорошо настроенном музыкальном инструменте. После почти года работы в нем я просто знаю, как делать все, что мне нужно, даже если я не делал этого раньше. Я просто надеюсь, что приток пользователей Unity не приведет к тому, что движок будет больше двигаться в сторону Unity. Если бы я хотел Unity, я бы использовал Unity.

@zaywolfe Ваша обеспокоенность несколько раз выражалась другими пользователями. Вам не о чем беспокоиться. GDScript останется основным языком в Godot.

Мне не нравится GDScript . Я понимаю, что он был создан по образцу Python, но я чувствую себя очень слабым. На мой взгляд, C++ или Java (из коробки) были бы отличной идеей. Лично мне противно использовать GDScript в разработке, вплоть до того, что я задаюсь вопросом, стоит ли оставить Godot и вернуться снова, когда будет реализован новый (или альтернативный) язык. Извините, но если вам нужны неопровержимые факты от программиста, вы их получили.

Кроме того, я хотел бы упомянуть, что иногда я даже использую Godot для создания некоторых простых прототипов программного обеспечения. Таким образом, глубоко интегрированный язык программирования, возможно, откроет двери для разработки программного обеспечения внутри движка. Это было бы настоящим убийцей Unity. (Если, конечно, была выбрана Java или C++)

Спасибо лояльным разработчикам за вашу тяжелую работу, я смотрю на вас всех и с нетерпением жду будущих обновленных выпусков!

@VenHayz Я не знаю, читали ли вы документацию Godot, но вы уже можете писать свои игры на C++, начиная с первой версии Godot — http://docs.godotengine.org/en/stable/reference/custom_modules_in_c++.html

как насчет использования ядра Microsoft .net? он кроссплатформенный и ориентирован на производительность, а также имеет открытый исходный код и активно развивается

Привет, просто случайный парень, проходящий мимо.

Я хотел сообщить вам, что я не использую Godot, потому что мне не нравится язык сценариев, который вы используете.

Если вы добавите Java или C#, то я установлю и буду использовать godot сразу после вашего объявления :)

@RUSshy , тогда до свидания, это ваша потеря, godot великолепен, GDScript великолепен, если вы настоящий программист, вам потребуется буквально два часа, чтобы узнать более чем достаточно, чтобы начать любой проект. Настоящие программисты должны владеть многими языками, вы можете придерживаться своего java/C# и быть "случайным" парнем, проходящим мимо как любитель навсегда. Я не пытаюсь быть грубым, просто констатирую факты. Если вам что-то не нравится в этом движке, добавьте код, он бесплатный, в отличие от большинства других движков.

Бог маркетинга благоволит C#. :смеющийся:

@RebelliousX Выбор Java или C# означает, что у вас будет НАГРУЗКА библиотеки для использования

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

Выбор безумен в наши дни, не будьте закрытыми

@RUSshy Ты издеваешься? Я (и несколько других) написал буквально страницы объяснений о преимуществах GDscript по сравнению с C#, и вы думаете, что сможете разрешить дискуссию одним коротким абзацем, не читая ничего из того, что было сказано ранее?

«Не быть ограниченным» — отличная идея, как насчет того, чтобы начать с непредубежденности в отношении GDscript?
"твои новые знания не будут применимы где-либо еще" - это просто ложь. Вы не сможете компенсировать недостаток знаний, копируя код, который вы не понимаете.
«вы не сможете найти тонны библиотек» — узнайте разницу между языком сценариев и языком бэкенда. Или - бредовая идея - прочитайте, что я об этом написал.

Серьезно, наглость некоторых людей...

Несколько раз в разных местах говорилось, что модуль интеграции C# находится в разработке. Это происходит так же быстро, как и количество времени, которое у людей есть на это. Единственный способ сделать это быстрее - внести свой вклад в эту интеграцию :)

@Warlaan о втором моменте: если вы раньше писали много кода на C #, вы не сможете использовать его повторно, если не перенесете его полностью. Вам также не нужно понимать код библиотеки, чтобы иметь возможность ее использовать. Дело в том, что если вам нужно что-то, что было в C# раньше (один файл или набор библиотек, потенциально закрытый исходный код), вам нужно либо портировать все это, встроить среду выполнения C#, либо найти реализацию C. Это не невозможно, но требует времени.
Это не означает, что Godot не может использовать множество существующих библиотек... В C/C++ их тоже множество.

Это рискует стать флеймовой войной.
Журнал настолько длинный, что люди будут повторять одни и те же вопросы или темы вместо того, чтобы читать его.
Технических вещей для обсуждения тоже не так много.

Будущее Godot с точки зрения сценариев уже довольно ясно:

• GDScript останется основным языком, и есть планы или идеи по его оптимизации (но это не то место, чтобы обсуждать это).
• Начиная с версии 3.0 C# будет поддерживаться в качестве альтернативы сценариям. Мы предоставим отдельные двоичные файлы, чтобы избежать форсирования дополнительного размера, вызванного монофонической средой выполнения, для людей, которые не будут ее использовать.
• DLScript также находится в работе. Это позволит людям использовать общие библиотеки для сценариев. Эти библиотеки могут быть написаны на любом языке, который поддерживает связь c и общие библиотеки (за исключением таких языков, как Rust и D). Пока не ясно, будет ли он готов к 3.0 (если только я не устарел).
• Не забывайте, что в версии 3.0 также будет Visual Scripting!

Если кто-то планирует внести что-то еще, это также не будет подходящим местом для обсуждения.

Я думаю, что этот вопрос можно и нужно закрыть.

Согласованный.

Не могли бы вы предоставить ссылку на исходные коды интеграции С#?

https://github.com/neikeq/GodotSharp

Насколько функциональна интеграция GodotSharp? Готов использовать для тестирования?
Можно использовать с исходным кодом от godot master?

@nictaylr В настоящее время сборка с мастером не ведется. Если вы хотите протестировать его, вам нужно использовать версию 2.2. Он работает с этой версией очень хорошо

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

Случайная идея, но после глубоких размышлений о C++ с Godot я подумал о чем-то, возможно, лучшем. Язык Д. Возможно, он подпадает под языковую квоту «низкого уровня» с интерфейсом для C и (некоторой) поддержкой C++. В нем есть классы, и он очень современный. Хотя это звучит пугающе, это очень похоже на GDScript , и я видел, как его используют для поддержки очень больших проектов. Он достаточно мощный, чтобы конкурировать с C и C++ (gcc/g++) с помощью компилятора под названием GDC. (DMC также можно использовать для компиляции, но GDC компилируется непосредственно в gcc) подробнее о GDC см. здесь

В любом случае, просто быстрое предложение или, может быть, для идей.

@VenHayz Я работаю над модулем, который позволяет использовать общие библиотеки для сценариев. Я уже приложил некоторые усилия, чтобы упростить использование C++. Вы также можете использовать D для создания этих библиотек. Если вы заинтересованы в создании привязок D, свяжитесь со мной в IRC или Discord.

@karroffel это действительно круто. У меня нет опыта написания библиотек и API (ссылка на ваше упоминание о «привязках»), хотя, вероятно, я мог бы просто изучить это в течение дня и сделать это; Я гордо быстро учусь. Я хотел бы связаться с вами в Discord, вы не против? Мой дискорд: _hasCat#3941

@VenHayz Я не могу добавить тебя, ты не разрешаешь другим добавлять тебя. Karroffel#8409 или присоединяйтесь к серверу Godot

@neikeq Является ли ваш репозиторий GodotSharp кодовой базой, которая используется для поддержки C# в Godot 3.0? Просто спрашиваю, потому что я пытаюсь получить приблизительное представление о том, какие функции будут доступны, и если это так, я покопаюсь в этой кодовой базе. Спасибо!

я смотрю godotsharp, устарело? Новая функция ? или готов к использованию в разработке сборки?

как я могу скомпилировать godosarp из источника для меня?

@nictaylr Вам нужно будет использовать устаревшую ветку 2.2 в качестве сборки для разработки.

Я думаю, что прочитал достаточно, чтобы понять, упоминал ли об этом кто-то еще.

Лично я просто не хочу учить еще один язык, который я больше нигде не использую. Я не планирую много заниматься 3D-программированием, просто кое-что тут и там.

Да, есть много контраргументов против этого, но... это проект с открытым исходным кодом. Нет необходимости ненавидеть кого-то, кто создает новый язык программирования.

Представьте, что вы приносите пиво на детский праздник. Могли бы вы сказать, что «нет необходимости ненавидеть кого-то, кто предлагает новый напиток»? Есть большая вероятность, что добавление C# навредит разработке GDscript. Я знаю, что все полны решимости сохранить GDscript в качестве основного языка для Godot, но меня все еще раздражает, когда мне несколько раз объясняли, почему добавление новых функций имеет недостатки, и люди все еще спрашивают «в чем вред?».

Также просьба использовать C# вместо GDscript, потому что «вы не хотите учиться» — действительно глупый аргумент. Из всех языков, которые я знаю в разработке игр, GDscript имеет наименьшее количество возможностей, а C# — больше всего. Если вы не хотите учиться, вы должны быть благодарны за GDscript.

Я действительно не хочу разогревать эту дискуссию снова и снова, поэтому, пожалуйста, если кто-то хочет прокомментировать эту тему, ПОЖАЛУЙСТА, ПРОЧИТАЙТЕ ЭТО С НАЧАЛА.

Также просьба использовать C# вместо GDscript, потому что «вы не хотите учиться» — действительно глупый аргумент.

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

Просто заблокируйте ветку, она становится подлой.

Это правда, что эта ветка выполнила свою задачу, давайте закроем ее.