Godot: スクリプト言語としてのC＃

私の意見では、GDscriptに機能を追加する方が、スクリプトにアプローチするためのより良い方法です。

私にとって、他のゲームエンジンよりもGodotを選択する主な理由は、単純化されたスクリプトスキームです。 Godotは新しいプログラミング言語を学ぶことを申し出ていません。 ゲーム開発のための複合ツールとして、Godotとそのスクリプト言語を学ぶことを提案しています。 これは、C ++やその他のスクリプト言語のプログラミング言語を学ぶための新参者を提供するよりも威圧的なアプローチではありません。

この号を開いてくれてありがとう、これは合理的に最良の選択と大多数が求めるものとの間に大きな違いがあるトピックだと思います。

複数のエンジンが存在する最も重要な理由は、汎用タスクのパフォーマンスやインターフェイスのアクセシビリティなどの1次元の要因に加えて、特定の状況でのパフォーマンスのような多次元の要因があるためです（エンジンを比較した場合、明らかな勝者はありません） 3Dゲーム用に最適化されたものと2Dゲーム用に最適化されたもの）または特定のユーザーグループ向けのユーザビリティ（通常、初心者向けのインターフェイスは高度な機能を非表示にする必要があります）。
したがって、他のエンジンの中で場所を見つけるために、エンジンは「哲学」を選択する必要があります。

現在、スクリプト言語はエンジンの不可欠な部分であるため、言語の哲学はエンジンの哲学に適合している必要があります。または、少なくともそれと矛盾してはなりません。

では、Godotの哲学は何ですか？ いくつかの事実を見てみましょう：

• Godotと比較すると、他のすべての主要なエンジンは肥大化しています。
  Godotのダウンロードは20MB未満であり、「インストール」全体は、サイズが50MB未満の1つの実行可能ファイルです。 一方、Lumberyardの初期ダウンロードサイズは約5.5GBですが、現在、私のインストールフォルダーのサイズは15.3GBです。 その主な理由は、依存関係に関するAmazonの哲学です。 その最初のダウンロードには、42の依存関係の10.5GBのビルドイメージが含まれています。AWSSDKがその点でそれほど変わらないことを知る前に、アマゾンウェブサービスを使用したことがある場合は、必要性や能力の問題ではありません。選択の。 たとえば、LumberyardにはboostとLuaが含まれていますが、Godotには、最も重要なSTLコンテナーの独自のバージョンが含まれており、luaではなくGDScriptを使用しています。これにより、サイズが小さくなり、依存関係が削除され、コードがより読みやすく、アクセスしやすくなります。
• Godotのソースコードは非常にアクセスしやすいです。
  それは、ビルド言語としてPythonを使用するビルドシステム（SCons）の選択から始まります。 他のほとんどのプロジェクトでは、独自のビルド言語を使用する既存のビルドシステムを使用するか、独自の独自のビルドシステムを作成します。どちらも、ビルドコードの可読性に悪影響を及ぼします。
  ソースコード自体もその点で平均を上回っています。 Godotへの最初のプルリクエストのコードを書くのにかかったのと同じくらい、C ++で単一のUnrealブループリントノードを書く方法を見つけるのに時間がかかりました。 UnrealのC ++コードが読み取れなかったというわけではありません。より多くのマクロを使用し、ユーザーがGodotよりもUnrealのデフォルトのプロジェクトコードを理解する必要があるため、Godotほどクリーンではありません。
• GodotはKISSとOOの原則を推進しています。
  それを説明するために、Unityのいくつかの単純なオブジェクトを見てみましょう。 Unityで直面する最初の概念は、コンポーネントがアタッチされたGameObjectsの概念です。 よく呼ばれる「継承よりも構成」（マイケル・J・ディックハイザーの「ゲーム開発者向けC ++」からの「封じ込めと継承」の定式化は、戦争の叫びのようには聞こえず、トピックへの反省を促進します）は成功したパターンです。それが提供する柔軟性のため。 ただし、その柔軟性にはコストがかかります。 ゲーム内のすべてがGameObjectである場合、「プレーヤー」への参照を実際に取得することはできません。プレーヤーがないため、プレーヤーコンポーネント（または、プレーヤーをアップ）。
  Unity開発者は同じ問題を認識しました。場合によっては、Buttonコンポーネントを備えたGameObjectではなく、Buttonを作成したいだけです。 つまり、彼らが行ったことはこれです。実際には、ボタンコンポーネントがアタッチされたゲームオブジェクトを作成するエディターインターフェイスを介して「ボタン」を作成することができました。 それに加えて、GameObjectの最も重要なメンバーをすべてのコンポーネントにルーティングしたため、GameObjectへの参照を使用するのと同じように、Buttonへの参照を使用できるようになりました。 ボタンにその位置を尋ねたり、そのコンポーネントのリストを求めたりすることができます。ボタンは実際にはコンポーネントであり、接続されているオブジェクトではありません。
  これで、ゲームの世界を説明するための2つの最も一般的な方法（構成ベースとプレーンオブジェクト）が混在しています。 しかし、初心者のプロジェクト（および一部の高度なプロジェクト）を見ると、Unityがゲームの世界を解釈する3番目の方法である手続き型プログラミングも容易にしていることがわかります。
  Unityでは、すべてのオブジェクトは常に「シーン」の一部です。 Godotとは異なり、この用語はゲームのトップレベルの部分を表します（免責事項：Unityにはシーンの上に配置されるSceneManagerがありますが、私のポイントは引き続き有効です）。つまり、敵がプレーヤーを撃ちたい場合は、プレーヤーの現在のシーンを検索し、操作します。 これが手続き型プログラミングの中心的な考え方です。所有権に関係なく、環境の状態を変更する一連のコマンドがあります。 もちろん、技術的にはまだオブジェクト指向プログラミングですが、すべてのオブジェクトが同じシーンの一部であると期待できるため、グローバルコードのように動作するコードを記述できます。 たとえば、オブジェクトをインスタンス化する場合は、「Instantiate（templateObject）」を呼び出すだけで、templateObjectのコピーがインスタンス化され、シーンに追加されます。 現在すべてが含まれているシーンは常に1つであるため、オブジェクトを追加するシーンを尋ねる必要はありません。
  そのため、Unityは、構成、オブジェクト指向思考、および手続き型プログラミングの混合を促進します。

一方、Godotはオブジェクト指向の思考を促進します。たとえば、ゲーム内のすべてのオブジェクトを独自のシーンとして構築できます。 これらのシーンは自分で開始できるため、テストしたり、自分で変更したりできます。そのため、環境にアクセスする必要のない方法でシーンを構築する必要があります。 たとえば、敵がプレーヤーと対話したい場合は、信号を使用して、対話が要求されていることを基になるシーンに通知したり、単にシーンに敵にプレーヤーへの参照を与えるように要求したりする方がはるかに現実的です。 プレイヤーのゲームシーンを検索することはできますが、そうすると、敵のシーンが単独で実行できなくなるため、デザインもツールに適合しなくなります。

では、これはスクリプト言語の選択に関してどのように違いを生むのでしょうか？
C＃は言語に対するものであり、Unityはエンジンに対するものです。 C＃の哲学は、ある機能が言語に追加されていればいいのではないかということです。 各バージョンで追加された機能のリストを見てください：https： //en.wikipedia.org/wiki/C_Sharp_ （programming_language）#Features_added_in_versions
今、あなたは機能を持っていることは何か悪いことではないと主張するかもしれませんね？ 使用する必要はありません。気に入らない場合はそのままにしておきます。 残念ながら、それは言語には当てはまりません。 今日のインターネットの重要性により、言語はもはやツールではなく、文化です。 遅かれ早かれ、あなたは助けを求めてグーグルする必要があります、あなたは他の人によって構築されたモジュールまたはオブジェクトを使用します、あなたはコミュニティによってエンジンに構築された新しい機能を使用します、そして遅かれ早かれあなたはあなたが意図しなかった言語機能を使用することを要求します使用します。
また、チームで作業している場合は、一般的なコーディングスタイルを促進し、同じコードを作成するための数十の方法を提供しない言語を使用することを理解することを学びます。

さて、機能の少ない言語は、機能の多い言語よりも常に優れていると言っているのではないかと思うかもしれません。 もちろんそうではありません。 Javaがどのように問題を解決したかを比較してみましょう。
C＃を使用すると、アンマネージコードを記述できます。 適切なキーワードを使用するだけで、同じファイルで直接使用できます。 また、SQLコードのように読み取り、関数型コードのように動作するLINQを使用して関数型コードを記述できます。 1つのファイルが何であるかを完全に理解するには、プログラミングパラダイムについてかなり多くのことを知る必要があるかもしれません。
Javaを作成している場合は、関数型プログラミングも使用できます。Javaを別のファイルに書き込み、別のコンパイラを使用して、「プログラミングClojure」と呼ぶだけです。 オブジェクト指向プログラミングと機能プログラミングを組み合わせたい場合は、「プログラミングScala」と呼ぶことができます。 重要な部分は、他のJVM言語のコードと簡単に対話できるJVMのコードをまだ作成していることです。
.NET言語には同じ機能があり、C＃哲学では使用されていません。 彼らは、C＃で1つまたは2つのプログラミングパラダイムに固執し、新しいパラダイムを追加するために新しい言語を作成することを決定することもできましたが、代わりに「1つの言語ですべてを征服する」ことを選択しました。そのような言語。 あなたはその哲学とあなたがプログラマーとして持っている選択を知っているべきです。

簡単に言うと、私たちが持っているすべての言語の中で、C＃はGodotに最適だと思います。 これはUnityに自然に適合しますが、これらすべてのオプションがある場合は、クリーンなOO原則とKISSプログラミングを他のすべての部分で促進するエンジンでパラダイムの混合と一致を促進する言語を選択するのはなぜですか？

したがって、C＃がGodotへの優れた追加になると思う場合、私はあなたに同意しません-私は単に、さらに優れた代替案が存在し、それを最初に評価する必要があり、C＃が実装されるとすぐに忘れられると言っています。

@hubbyist

私の意見では、GDscriptに機能を追加する方が、スクリプトにアプローチするためのより良い方法です。

それは確かに起こる可能性があります、私はそれが他の提案と互換性がないと思います。

私にとって、他のゲームエンジンよりもGodotを選択する主な理由は、単純化されたスクリプトスキームです。 Godotは新しいプログラミング言語を学ぶことを申し出ていません。 ゲーム開発のための複合ツールとして、Godotとそのスクリプト言語を学ぶことを提案しています。 これは、C ++やその他のスクリプト言語のプログラミング言語を学ぶための新参者を提供するよりも威圧的なアプローチではありません。

ただし、GodotはすでにC ++から使用できるため、C ++でのコーディングが簡単になることを除いて、実際には何も変更されません（現在、モジュールの作成にはGodotのすべてのコンパイルが必要であり、統合されていません）。ワークフローに）。

@Warlaan素晴らしい分析。 私の投稿を読んだら、私もC＃がGodotの良い選択であることに同意しませんでした。そのため、既存のC ++機能を拡張して、スクリプト言語として使用できるようにすることを提案しました。GDScriptはほとんどのユーザーのデフォルト言語のままです。

ユーザーはGDScriptでほとんど書くことができるはずですが、大きなゲームがGDScriptで書かれると考えるのは無理です。 私の意見では、エンジンは非常によく設計されており、すでにかなり良いパフォーマンスを持っているので、GDScriptのパフォーマンスを除いて、Godotが大規模なゲームに適していることを妨げるものは何もありません（そしてVulkanはおそらくそれをさらに良くするでしょう）。

私の意見では、パフォーマンスはほとんどのGodotユーザーにとって魅力的ではありませんが、より多くの専門家をGodotにもたらす可能性があります。つまり、より多くの貢献を意味し、すべての人にとってより良いGodotを意味します。

@ paper-pauper私たちは同じ側にいることを理解しました。 「C＃がいい追加だと思うなら」と書いたとき、私は個人的にではなく、「匿名の読者であるあなた」に取り組んでいました。 ;-)
そして、はい、新しいスクリプト言語はGDScriptから注意をそらします。 コミュニティが複数の言語を処理するのではないかと思います。遅かれ早かれ、一部の機能が使用できなくなったり、いずれかの機能が機能しなくなったりして、言語の1つが削除されるまでになる可能性があります。

また、ここでの唯一の実際の問題は、C ++のコンパイル時間とGDScriptのパフォーマンスであることに同意します。
人々がすでにC＃を知っているという議論は、まったく間違った私見です。 私は約4年間C＃を専門的に使用しており（主にC ++とSQLを使用しています）、その間に学んだことの1つは、その言語を本当に知っているとは言えない可能性が高いということです。 結局のところ、C＃6と7の提案では、機能の数はまだ増え続けています。
したがって、「C＃を知る」ということについて話しているとき、実際に参照できるのは、最悪の初心者でも数日で再学習できる最も基本的な構文を知っていることだけです。 私は最近、以前はUnityを独占的に使用していたゲームデザイナーのクラスにさまざまなゲームエンジンについての講義を行いましたが、GDScriptの構文について悪いコメントをした人はいませんでしたが、実際、プログラミングをあきらめた何人かは再びやる気になりました。

そうですね、GDScriptを高速化し、C ++のコンパイルと使用の煩わしさを軽減するソリューションも私のお気に入りです。

C＃を「知っている」多くの人は、Javaとは異なる機能の多くを使用していません。 サブクラスほど遠くない無数のUnityスクリプトを見てください。

この理由だけで、私はC＃がもたらす実際的な利点について非常に懐疑的です。 それらは、ゲーム開発だけでなく、多くのコンテキストで優れています。 さらに、C ++ 1xは、オーバーヘッドなしで、これらの多くのもの（型推論、イテレーター、およびいくつかの基本的な機能ツールを含む）をすでに提供しています。

また、CLR（またはJVM）によってもたらされるオーバーヘッドによって、Godotが_worse_を実行する可能性がありますが、JVMのガベージコレクターを使用することにはいくつかの利点があります（Godotのメモリ管理についてもっと知っている人はいますか？）。

GDScriptのためにGodotを使用しない人々についてのフォーラムで読んだ。 オーバーヘッドがゼロでクロスプラットフォームのソリューションを提案することで、別のチケット＃3943で対処しようとしたライブラリの選択が不十分であるという事実を除いて、それについては何も悪いことはないので、それは気が利いていると思います。サポート。

LLVMを介してC ++ JITを実装する必要がなく、ネイティブコードで実行され、Godotのソースをいじる必要のないソリューションがあります。動的リンクです。

1つ目は、Godotを最初から再コンパイルすることなく、ネイティブコードを許可します。.soファイルとしてコンパイルしてからロードパスに追加し、GDScriptからオーバーヘッドなしで使用します（すべて関数呼び出しであるため）。

これは（libdlを介して）非常に簡単に実行できるはずですが、私が理解している限り、クロスプラットフォームの問題のために実行されていません。

また、 ENIGMAがその言語で行うのと同じように、GDScriptをC ++にコンパイルするというアイデアもあります。 これは簡単ではありませんが、明らかに最高のパフォーマンスを提供します。

Godotのメモリ管理についてもっと知っている人はいますか？

ドキュメントから：

クラスがReferenceを継承している場合、インスタンスは使用されなくなったときに解放されます。 ガベージコレクターは存在せず、単純な参照カウントだけです。 デフォルトでは、継承を定義しないすべてのクラスがReferenceを拡張します。 これが望ましくない場合、クラスはObjectを手動で継承し、instance.free（）を呼び出す必要があります。 解放できない参照サイクルを回避するために、弱参照を作成するためのweakref関数が提供されています。

注意してください...

GDscriptの主な利点は、Reduzや他の開発者の完全な管理下にある言語であり、Godot開発者にとってどのように機能するかは外部チームに依存しないため、GDscriptに固有の方法で開発できることです。エンジンの設計とユーザーが要求しているものを持っています。

もう1つのことは、GDscriptは現在、実際の高性能言語ではありませんが、その単純さと動的型付けの性質を維持しながら、パフォーマンスを大幅に向上させることができる領域がたくさんある可能性が高いということです。

次に、GDscriptはコンパイルの知識をまったく必要とせず、Godotの組み込みエディター以外には何も必要ないという事実があります（これにより、ワークフローが簡単で高速になることは言うまでもなく、きれいになります）。

質問ですが、GDscriptインタープリターは内部でどのように機能しますか？ 古いBasic言語のように実行時に各行を解析しますか、それともスクリプト全体をバイトコードテーブルに変換してからバイトコードを実行しますか？

@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

BASICのように機能する真面目な言語はもうないと思います！ :)

こんにちは！
GDScriptの歴史は次のとおりです。
//////////////////////////
歴史
当初、Godotは複数のスクリプト言語をサポートするように設計されていました（この機能は現在も存在しています）。 ただし、現在使用されているのはGDScriptのみです。 この背後には少し歴史があります。

初期の頃、エンジンはLuaスクリプト言語を使用していました。 Luaは高速ですが、（フォールバックを使用して）オブジェクト指向システムへのバインディングを作成するのは複雑で時間がかかり、膨大な量のコードが必要でした。 Pythonでいくつかの実験を行った後、埋め込むことも困難であることがわかりました。

出荷されたゲームに使用された最後のサードパーティのスクリプト言語はSquirrelでしたが、これも削除されました。 その時点で、次の障壁が満たされたため、組み込みのスクリプト言語を使用することで、Godotがより最適に機能することが明らかになりました。

• Godotはノードにスクリプトを埋め込みますが、ほとんどの言語はこれを念頭に置いて設計されていません。
• Godotは2Dおよび3D数学にいくつかの組み込みデータ型を使用しますが、スクリプト言語はこれを提供せず、それらをバインドすることは非効率的です。
• Godotは、ネットまたはディスクからデータを持ち上げて初期化するためにスレッドを多用します。一般的な言語のスクリプトインタープリターはこれに適していません。
• Godotにはすでにリソースのメモリ管理モデルがあり、ほとんどのスクリプト言語は独自のモデルを提供しているため、重複した作業とバグが発生しました。
• コードのバインドは常に厄介であり、いくつかの障害点、予期しないバグ、および一般的な保守不能が発生します。

最後に、GDScriptはカスタムソリューションとして作成されました。 そのための言語とインタプリタは、LuaとSquirrelのバインディングコード自体よりも小さくなり、機能も同様になりました。 時間の経過とともに、組み込みの言語を持つことは大きな利点であることが証明されています
////////////////////////

私の意見では、C ++が最適です。 次のような解決策があります。
https://github.com/RuntimeCompiledCPlusPlus/RuntimeCompiledCPlusPlus
エンジェルスクリプトでさえ、通常、コンパイルされたランタイムのようになります。
スクリプトでは、ゲームと科学シミュレーションを組み合わせたソリューションが大好きなので、Pythonが大好きです（Pythonには多くの科学ライブラリがあります）。 だから私は文句を言う！ 別の問題では、godotが独自の物理ライブラリを持っている理由： https ：//github.com/godotengine/godot/issues/4217
C＃のような言語にはいくつかの問題があります： https ：//github.com/godotengine/godot/issues/2790

素晴らしい発見、 @ alabd14313 -GDScriptをそのままにして、ほとんどの問題を解決します。

RCCPPについては、非常に良い考えです。 Godotがエディターモードでサポートし、ビルドで無効にした場合、パフォーマンスが最大になり、反復時間がかなり速くなると思います。 UnrealEngineのような他のエンジンがC ++と似たようなことをするのを聞いたことがありますが、GodotがC ++コーディングのようなシームレスなスクリプトを許可すればかなりいいと思います。

このページでは、彼らのアプローチのほとんどの代替案（私が言及したもの、LLVM JITを含む）をリストしているので、著者は彼らのことを知っているようです。

GodotはC ++で記述されているため（C ++が数年でさらに良くなることを考えると、これが変わることはないと思います）、このアプローチが最も理にかなっていると思います。すでにC ++ APIとC ++が機能しています。オーバーヘッドがゼロで、ほぼ最大の望ましいパフォーマンスがあり、追加のランタイムやメモリマネージャーはありません。 開発者がそれを見てくれることを願っています。

スクリプト言語としてC＃を追加するという提案への反応としてafaikが開始されたこのスレッドには、6人が意見を述べた後でも、C＃の引数が1つも含まれていないことに少し驚いています。
たぶん、C＃を追加するという決定は、私が聞いた噂から推測したほど計画的ではありません。

@WarlaanこのURLをFacebookグループに投稿するとどうなりますか？ :)

タイトルを「スクリプト言語としてのC ++」のように変更してください。
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（レベルデザイナーおよびアーティスト向け）の間のワークフローを次のように実装できます。
UE4でのC ++プログラミングの概要
C ++とブループリント
そのため、グループ内で、プログラマーはアーティスト向けの新しいブループリントクラスを開発でき、アーティストは直接コーディングする代わりにこれらを使用します。

@Warlaan IMHOは、C＃の話の多くが、GodotをUnityのリップオフにしたいと思っている人々によって刺激されたためですが、幸いなことに、ここの多くの人は、Godotがそれ自体のものであり、多くの点でUnityよりも進んでいることを認識しています。同じ問題の影響を受けるようにします。

@ alabd14313タイトルを変更しますが、後世のために別の問題を作成して保持し、誰かがC＃を提案したときにリンクできるようにすることをお勧めします（よくあることですが）。

正直なところ、ビジュアルスクリプティングには躊躇していますが、モジュールとして実装できるのであれば、どうでしょうか。 もちろん、ビジュアルスクリプティング（デザイナーと初心者）、GDScript（プログラミングできる、または学ぶ意欲のある人）、C ++（プログラマー）があれば、Godotはすべてのレベルのスキルに適したかなりバランスの取れたプログラムになりますが、C ++コーディングは少なくなります。面倒でサードパーティのライブラリとのインターフェースを容易にすることは、多くのプロのユーザー（およびその結果として寄稿者）を呼び込む可能性があるため、IMHOの優先度を高くする必要があります。

Imhoのビジュアルスクリプティングは、意味をなすほど洗練されたものではありません。 マーケティングや初心者のプログラミングへの会話には最適ですが、私の経験から、初心者がフローグラフを好む学習フェーズは非常に短いです。
私が知っているシステム（Unreal、Cryengine、Fungus、Stingray）の最も基本的な一連の呼び出し以外は、まったく役に立ちません。 たとえば、このスクリーンショットは、Stingrayエンジンの公式広告ビデオからのものです。 これが私がスパゲッティコードと呼んでいるものです。 また、Cryエンジンの公式の例は、コメント要素の量からグラフを読みやすくするために多大な労力が費やされたことがわかりますが、見栄えは良くありません。
それがそれほど悪くないと思うなら、テキストベースの言語でそのコードを見た場合、画面外で始まるすべての接続線は（うまくいけば）意味のある名前の変数になることを思い出させてください。

フローグラフは、中間結果を表示できるため、シェーダー/マテリアルに関しては多少役立ちますが、システムでさえ、次のような短い方程式という事実に大きく悩まされています。
float x =（ab）*（a + b）/（1-（a + b））
すべての乗算、合計、または差は2つの入力と1つの出力を持つノードであるため、グラフとして実行すると、画面全体を簡単に埋めることができます。 上記の式では少なくとも10ノードです。接続の混乱を引き起こしたくない場合は、aノードとbノードを複製する必要があります。

現在使用しているフローグラフシステム（少なくとも私が知っているもの）では、結果を中間の名前付き変数に入れる代わりに、次のノードに接続するだけなので、値に意味のある名前を付けるオプションがなくなります。 そのため、自己文書化コードはほとんど不可能になり、文書化により多くの労力を費やす必要があります。
これらのシステムが追加するのは、ノードを好きな場所に配置するオプションです。これにより、私の経験では、読みやすいコードではなく、読みにくいコードになることがよくあります。

また、フローグラフについてコーディングしていないかのように話さないでください。 それらは他のプログラミング言語と同じくらい多くのコーディングです。 彼らはタイピングしていません、それだけです。

ビジュアルスクリプティングは、デザイナーやアーティストがコーディング方法を学ぶことなく変更を加えるためのものです。 一部のアーティストは、それを使用して簡単なインタラクティブゲームを作成することもできます。 それは間違いなくusefuであるという目標を持っています、それはプログラマーのためだけではありません。

@Warlaanまあ、それはあなたが「プログラミング」をどのように定義するかに依存します。 確かに、ビジュアルスクリプティングはアルゴリズムの定義に似ているので、プログラミングからそう遠くはありませんが、プログラミングは他のことでもあります。

ただし、ビジュアルプログラミングにはいくつかの優れた実装があります。 PureDataはその1つであり、 GDevelopもあります。これは、かなり優れたFLOSSゲーム作成プログラムです（あまり人気がないのは残念です）。 要するに、私は個人的には好きではありませんが（あなたが言及したいくつかの理由で）、私たち両方がプログラミングできることも事実です。したがって、私たちにとってビジュアルプログラミングは、比較的悪い結果を達成するのに時間がかかり、面倒です。

それでも、 @ reduzにアピールする人がいることに同意します。 彼らはこのようなスレッドをぶらぶらしている人ではありませんが、ゲームも作っています。 彼らはGodotに何かをもたらすことができると思います。

フローグラフがシェーダー編集に適している理由は、非常に視覚的であるためです（ファイルパスと値を手動で入力しなくても、画像の読み込み、色の選択などを行うことができるノードがあります）。 また、構文が正しく、関数のスペルが正しいことを確認する心配もまったくありません。 また、マトリックスの操作方法などの複雑なタスクを理解する必要もありません（すべて計算されます）。

シェーダー編集のためのGodotの方法論は、頂点、フラグメント、およびライトコンポーネントを明確に分離し、操作しているデータのタイプ（通常の情報かカメラ情報か）に関する明確なガイダンスを提供するため、優れたアプローチになります。

ビジュアルスクリプティングを使用すると、ノードがゲームの仕組みに関して十分に高いレベルにあり（より複雑なことを行い、いくつかの入力がある）、ノードが存在する場合は、中程度に複雑なものでも役立つと思います。スクリプトを実行したり、式/式を作成したりできます（これを使用して、複雑な方法で値を操作できます）。 このタイプの他のビジュアルノードシステムで私が見た問題は、それらが可能な限りリテラルプログラミングに近づこうとしていることです（つまり、ノードバージョンのようなものではなく、ノードとして低レベルの関数をたくさん持っている） BlenderのロジックブリックまたはGameMakerのドラッグアンドドロップ）。

もちろん、純粋なスクリプトで実行できるほどきめ細かく高度なものは許可されませんが、ゲーム内の単純なオブジェクトタイプ（非常に複雑なロジックを必要としない）などには使用できます。 ）または、何かをすばやく叩き出す必要がある場合。

一部の人々がそれに魅力を感じることに同意します。また、プログラマー向けではないことにも同意します（異なるのは「プログラマー」の定義だけです;-)）。それで、それはややオフトピックなので、議論を残すことをお勧めします。

C ++のもう1つの便利な機能は、静的型です。 「auto」および「decltype」機能は、オブジェクトのタイプを検出できます。 エディターとコードの補完が簡単になります。 内部コードエディタに焦点を合わせる代わりに、別の外部IDEを使用できます。 今のところ、codeliteとqtcreatorの方がコード完了のステータスが良いと思います。 コードブロックには、c ++ 11キーワードでいくつかの問題があります。 また、eclipse-cdtのコード補完は良好です。 qtcreatorのプラグインは良いアイデアです（unreal-visual studioやUnity-Monodevelopなど）。 外部IDEは、godot設定（/ use / bin / qtcreatorなど）のシステムパスで識別できます。コンパイルしてgodotをパックする必要はありません（Unityパッケージにmonodevelopが組み込まれている場合とは異なります）。
qtcreatorにプラグインを持つcppcheckやvalgrindのような別のツールがあります。
RCCPPとは何かのプレビューが必要な場合：
デモ

Godot用のC ++ベースのスクリプト言語を見たいのですが、テンプレートプログラミングなど、すべてのC ++機能を実装するのは面倒です。 この種のスクリプト言語（STL）にはいくつかの制限が必要であり、テンプレートは使用しないでください。 また、RTTIはパフォーマンスの問題を引き起こす可能性があります。

私はGDscriptが大好きです。それについての唯一の不満は、変数の名前空間の汚染です。大きなスクリプトを処理する場合、ready（）の前の変数定義が非常に乱雑になり、同じスクリプトファイルの関数間で変数を共有するためにコードにバグが発生しやすくなります。 。

私の3セント。 （ええと...それは20になりましたが、それをそのままにしてください...）

先に述べた@ alabd14313のように、godotを今日の形に導いた長年にわたる進化のために、「それはその時点にあります」。
自然がこれを行うか、私たち人間がこれを行うかどうかに関係なく、作成時に物事を修正することが開発の最良の方法であるように思われます。これのおかげで、私はGodotをそのまま楽しんでいます。

必要なものはすべて揃っています。

より複雑なオブジェクトに結合し、シーンとして保存し、別のシーンで「単純な」オブジェクトとして再利用できるノード。これは、ユーザー自身の想像力と創造性の境界によってのみ制限される、非常に柔軟な機能です。

GDScriptの使用と学習は簡単で、コードの行を入力することで、コーダーが使用する方法ですべてのノードを制御するのに十分強力です。
さらに、コンパイルせずにすばやく簡単な方法（コード補完/組み込みのドキュメント/便利なツールチップ）でそれを実行し、入力し、試して、調整し、もう一度、完全に磨きます。

本当にワンクリックで複数のプラットフォームに展開する（wifi / adbを介したAndroidへの展開、ライフ編集、デバッグなどは言うまでもなく、芸術の傑作です。それ以上に、魔法です！）

さらに、blenderectのような一般的に使用されるツールに関するこれらすべての知識。
（ものをインポートすると、箱から出してすぐに機能します。すべてがどこにどのようにあるべきかです）

そして最後に、ループで何百万回も実行し、1つのフレームに収まる場合、超創造性でさえ十分でない場合があることを認めます。 そこでCのものが登場します。Cを知っていて、それが必要な場合は、プラグイン、独自のカスタムノードなどを作成することを妨げるものは何もありません。

それはほとんどすべてを持っています、そしてやがて、私はそれをすべて持っていると信じています。
（つまり、今日は「まだ実装されていない」ものであり、「どういうわけか」または「素手」で行う必要があります（読んでください：外部ツールを使用してください）。たとえば、3Dリギングされたものを簡単な方法で調整します（ブレンダーを使用してください） ）。

Godotは素晴らしく、魔法のようなもので、行く道にぴったりです。調整とあちこちに何かを追加する必要がありますが、それだけです。

ビジュアルスクリプティング？
ええと。 それは私たちのコーダーに異常な方法で「少し」考え方を変えることを強いる可能性があります、そして私はそれが通常のコードのように柔軟で読みやすいとは思わない。
あなたがコーディングしていて、このような単純な1行があると想像してください（abc / def）* ghi
次に、通常どおり（？）入力を節約するための高速な方法で、何かの一部をマークし、ここに貼り付け、そこに切り取り、もう一度貼り付け、5秒以内に数回キーを押すと、「単純」になります（それが何をするかを知っているため） （（（（abc / def +（（abc / def）_ghi ^ 4））_ ghi）+（abc / def_（100））_ ghi）+ abc）のような1つのライナー
その一般的な、おそらく私たちの多くは、超高速の方法でこのようにそれを行います。
今それを視覚的な方法で行うことを想像してください...
画面全体、多くのマウス作業が必要になる可能性があり、本来のように読みやすく見えません。
（もちろん、そのようなワンライナーも1年後には簡単に見えませんが、それがコメントの目的です）

誰かがそのような線を100本並べている場合はどうなりますか？
視覚的に彼はそれを表示するためにサッカーのピッチを得ることができました。 それを分析し、変更するのはどうですか、それは混乱と大きな頭痛の種です。
もちろん、コーダーはこれを行うことができます。なぜなら、それは使用される言語ではなく、誰かをコーダーにするからですが、特定の考え方、アルゴリズムの作成、小さな部分として、そして全体としてのデータの操作です。
C、Python、PHP、Java、またはビジュアルスクリプトが、考えを書き留めるためのツールにすぎないかどうかに関係なく、言語。
そしてここで、Imho、キーボードを使った通常のタイピングは、それを書き留めるのに最も速くて読みやすい形式です。
反対に、誰かがコーディングできない場合、ゲームを考えるとき、2つのボールをバッシングするよりも複雑なことについて話していることを考えると、彼が突然、アルゴリズムの天才と知覚力を明らかにして、自分のアイデアとその視覚的表現の中で迷子にならないようにすることを期待しますか？物理学でお互い。

では、誰にとって本当にビジュアルスクリプティングは誰になるのでしょうか？
コーダーの生活を困難にするため、またはgodotをレベルに制限するため-初心者向けの「シンプルなゲーム」のエンジン？

人々、＃1220でビジュアルスクリプティングについて長い議論があります。 ここで同じトピックについて再度議論しないようにしましょう。

人々、＃1220でビジュアルスクリプティングについて長い議論があります。 ここで同じトピックについて再度議論しないようにしましょう。

ここの投稿のほとんどはとても長いので、おそらく読んでいる間に私は自分自身を失いました。
申し訳ありませんが：リラックス：

@RebelliousX RTTIを使用しても、C ++のパフォーマンスはGDScriptよりもはるかに優れています。 テンプレートが問題になる可能性があるのは事実ですが。

@reduzが＃3936で提案したソリューションでは、C ++でのコーディングはすでにかなり簡単になります。選択したエディターとコンパイラーを使用して、GodotのAPIにリンクするだけです。 これが実装されている場合、C ++でのスクリプト作成が優れていても、パフォーマンスの点で、C ++でコードを記述してGDScriptから呼び出すのと大差ありません。 要するに、私は＃3936（これは単純な解決策です）に焦点を合わせると大幅に改善されると思います：

• パフォーマンス（C ++でパーツを作成するのは非常に簡単なので）
• サードパーティライブラリの可用性（ラッパーはより簡単に配布できますが、＃3943ほど簡単ではないため）
• ユーザーベースと貢献者（多くのC ++プログラマーはGodotを採用します）

次に、GDScriptでの静的型付けとインタープリターの最適化（JITを介して、またはGDScriptをC ++にコンパイルすることによる）に焦点を当てることができますが、モジュールの作成が容易になれば、これは後で実現できます。

この議論に潜入しているが、まだ取り上げられていないいくつかの点に言及したいだけです。

• 私たちの中には、C ++の開発を促進し、GDScriptのパフォーマンスを向上させることによって、既存のシステム（スクリプト言語としてのGDScript、バックエンド言語としてのC ++）を改善することについて話している人もいます。 スクリプト言語としてC ++（またはJava / C＃/ ...）を使用することについて話している人もいます。 高速C ++開発を有効にすることと、スクリプト言語にすることの間に実際の違いはないように思われるかもしれませんが、強力なスクリプト言語がゲームデザインの品質に及ぼす悪影響をどのように経験し、観察したかを喜んで説明します。 そして、これが議論のトピックにならない限り、私はフォーラムや、このスレッドを乗っ取らない他の場所で喜んでそれを行います。
• @RebelliousX ：「変数の名前空間」、「大きなスクリプト」、「関数間での変数の共有」について話すとき、GDScriptのオブジェクト指向の性質を完全に理解していないように聞こえます（不快感はありません）。 すべてのGDScriptファイルはクラスであるため、（メンバー）変数間の名前の衝突は、他のオブジェクト指向言語とまったく同じ頻度で発生するはずです。 スクリプト間で変数を共有しているのではなく、包含オブジェクトの状態にアクセスできるいくつかの関数を記述しています。

@Warlaan最初のポイントについては、トピックに関連しているので、ここに投稿できると思います。

@Warlaan攻撃は受けていません。 GDscriptはそれ自体のクラスであり、変数はC ++クラスの通常のメンバー変数に似ていることを知っていますが、私の主張を完全に見逃しているようです。 1000行を超えるコードを含むスクリプトがあると理解できます。 私が欲しいのは、無数のメンバー変数を作成する代わりに、参照またはポインターであり、メンバー関数間でそれらを渡すだけです。 そうすればより安全です。

私はC＃が好きですが、長所と短所があります。

長所：

• 優れたツールサポート（それに直面しましょう。VisualStudioまたはMonoDevelopを使用せずにC＃でコーディングしますか？）
• 大規模プロジェクトに最適
• 広く使用され成熟しているため、インターネット上には大量のサポートスレッドがあります。
• 優れたパフォーマンス、クロスプラットフォームでありながらC ++とスクリプト言語間のトレードオフ
• C ++にバインドするのは比較的簡単です

短所：

• 収集されたガベージ：大規模なゲームプロジェクトでも、GCキックが頻繁に発生するのを防ぐために、割り当て戦略を実装する必要があります。これは厄介な場合があります。
• GDScriptほど統合されていません（ノードパスの完了？ノード上のスクリプトメンバー変数？メモリ割り当てモデル？）
• ランタイムは重く、.NETFrameworkはさらに多くなります。 Unityと同様に、標準ライブラリはGodotに再マッピングする必要があります。
• 作業をすばやく汚くするという意味では、実際のスクリプトには最適ではありません。 C＃は、GDScriptよりも冗長で制限があります。
• Godotの開発に関するガイドラインはまだありません。 この言語は一般的で多くのことを実行できます。Warlaanが言ったように、開発者にはさまざまな文化があります（WPFコーダーがGodotを試し、GUIを作成するMVVMの方法がないのはなぜか疑問に思うかもしれません：p）

これのほとんどはJavaにも当てはまります。
ここが遅いので他のことを忘れたのかもしれません。

わかりました、これは機能豊富なスクリプト言語またはそれぞれに関する私の経験です。 「スクリプト言語」の定義によっては、スクリプト言語が完全に欠如している。 短くしていきます。 ;-)

私はここ数年、ドイツのベルリンにあるSchool4Gamesで工学部長として働いています。 その学校には「純粋な」ゲームデザインの能力はありませんが、私たちのゲームデザインコースは「ゲーム開発」と呼ばれ、ゲームデザイナーに独自のプロトタイプを開発する方法を教え、可能性と限界を理解するのに十分なプログラミングレッスンが含まれていますハードウェアと一般的なソフトウェアアーキテクチャの。
ですから、私が教えている学生は、プログラミングに興味を持っていることもありますが、プログラマーになることを申し込んだ人はいません。
学期ごとに、チームを編成して1つのゲームを開発する必要があります。 学生の将来の雇用主のほとんどすべてがUnityを使用しているため、最初の2学期はそのエンジンを使用する必要があります。

それでは、スクリプト言語の効果に関するポイントに取り掛かりましょう。
これらの学生は2つのグループに分かれました。 プログラミングを避けようとするか、希望を失ったもの（つまり、プログラミングクラスに参加するが、問題が発生しても助けを求めないが、黙って諦める）と、プログラミングに深く入り込んで、次のトピックにスキップするもの通常、ゲームのプロトタイプを作成するときは気にしません。 たとえば、最初の学期の私の学生の1人が、ジェネリックを使用してC＃でシングルトンを作成する方法に関するチュートリアルを最近公開しました。チュートリアルのジェネリッククラスから継承することで、Unityコンポーネントクラスをシングルトンに変換できます。 興味深い点は、彼がその記事を書くことができたということではありません。結局のところ、彼はもちろん先生から助けを受けており、インターネット上にはこのトピックに関する多くのリソースがあります。 興味深い点は、プログラミングではなくゲームデザインに主に焦点を当てたコースに応募した学生は、そのような特定のプログラミングトピックに興味があるということです。 そのチュートリアルのコードは、ゲームデザインの変更によって変更されることはなく、純粋なプログラミング構造です。
あるゲームシーンから別のゲームシーンに情報を転送するために同様のクラスを使用した別の学生でも、同様のことが起こりました。 私が彼に公共の静的メンバーで同じことができることを示したとき、彼は非常に驚いていました。これは、彼がその中のすべての基本要素を完全に理解する前に、完全で複雑な解決策を探していたことを示しています。

したがって、先にスキップした場合、これまでのテキストを要約します。機能豊富な言語で単純なコードを書くことは可能ですが、複雑な代替手段が存在する場合、人々が単純な解決策を却下する可能性が高いことを何度か観察しました。

これは偏見だけによるものではありません。 確かに、それはおそらく1つの要因です。 プロジェクト内のチュートリアル、例、またはその他のクラスのコードが複雑に見える場合は、自分のコードも複雑に見えるはずであると結論付けることができます。 しかし、本当の理由は、プログラミングではエラーのないコードを作成しようとするのが理にかなっているからだと思います。 別の場所で使用されたり、別の入力を受け取ったりするとすぐに壊れないコードを書くのは当然のことです。 そして、それはあなたがあなたが準備しなければならないかもしれないどんなオプションがあるかを見つけることをあなたに要求します。
あらゆる不測の事態をチェックしなければならないというこの感覚が、私の生徒をC＃の膨大な数の機能に溺れる生徒と、すぐに飛び込んで言語に集中できなくなる生徒に分けていると思います。

Zylannは、「迅速で汚い」というフレーズに言及しました。 私たちはしばしばこれらの2つの用語をフレーズとして使用しますが、それについて考えると、実際には2つの異なる要素です。 迅速にコーディングできるかどうかはかなり測定可能です。 一方、結果のコードがダーティであるかどうかは、多くの要因に依存します。最も重要なものは、使用される言語が持つ機能の数です。
たとえば、GDScriptは、C＃などの言語と同じようにパターンを実装するために必要な機能を提供していないため、トップレベルノードを作成してGodotでシングルトンとして使用することはまったく問題ありません。 確かに、自動ロード機能を使用する方が、他の開発者がシングルトンを探す最初の場所であるため（そして構文が少し良くなります）、より良いでしょうが、チームがそれをそのように実装することを決定した場合、私は多くの口論。 一方、誰かがパブリック静的メンバーをクラスに追加するだけでUnityにシングルトンを実装したと想像してみてください。 同じように高速です（どちらも最もパブリックな場所のクラスインスタンスです）が、C＃にはコンストラクターをプライベートにするオプションがあるため、レイジー初期化などを使用してプロパティを介してシングルトンにアクセスします。そうしないと、コードが壊れていないと非常に汚れていると認識されます。

ゲームデザインの学生がこのようなトピックに飛び込むという事実は、私のポイントが何であるかについて漠然としたヒントかもしれませんが、大規模なF2PMMO開発者での最初の仕事の状況について話すことでさらによく説明できると思います。 私が参加したチームは、ドイツで最も経験豊富なゲーム開発者の1人です。 彼らの開発責任者は1995年以来、独自の自社エンジンを作成しており、他の会社に買収されたばかりであったとしても、当時最も成功した開発者の1人でした。
私がチームに参加するまでに、彼らはスクリプト言語を持たない社内エンジンの3番目のバージョンを使用していました。 彼らは以前に1つ実装していましたが、そのバージョンのエンジンでは、ゲームデザイナーが提供したコード品質に問題があったため、スクリプト言語がない状態に戻りました。 言い換えれば、スクリプト言語が強力すぎるため、プログラマーとゲームデザイナーの間の障壁を、プログラマーがすべてのプログラミングを行っている間、ゲームデザイナーがレベルを編集し、構成シートの設定を変更するだけになるようにするという決定がなされました-振り返ってみると私はこれは、私の学生が最終的に直面する状況とほぼ同じであることに気づきました（そして、Unityを使用する多くのプロのスタジオが最終的に遭遇するようです）。
なぜ私は気にするのでしょうか？ これが何度も起こっている場合、それはそれがうまくいく方法であることを証明しませんか？ 私の答えはノーです。技術的な問題とゲームデザインの両方の問題があり、プログラマーとゲームデザイナーの間のコミュニケーションが、一方の方向にタスクを記述し、もう一方の方向に設定を公開することに限定されたという事実によって簡単に説明できます。 ゲームデザイナーの観点からは、機能は有効または無効にできるブラックボックスになりましたが、チームのその側には、代替案について話し合ったり、プロトタイプを作成したりできる人は誰もいませんでした。
一方、プログラマーはほぼ自然にバックエンドの精神に追い込まれました。 構築した機能がどのように使用されるかを誰も予測できなかったため、「迅速で汚い」KISSの考え方はなくなりました。 ゲームデザイナーがイースターエッグハントを実装したためにデータベースが故障したために、在庫が以前よりもはるかに大きくなったのを鮮明に覚えています。 機能の要件はおそらくほぼ同じであると私が思ったのはこれが最後でした。

そのため、ゲームコードの定義領域として機能の少ないスクリプト言語を使用することは非常に重要であり、使用しないとゲームデザインに悪影響を与えると思います。

• クイックコードを書くということは、それを「クイックでダーティな」コードに変える機能を無視することを意味します。
• クリーンなコードを書きたいという願望は、開発者をコーディングしない開発者と、コーディングについて考える時間を増やし、ゲームについて考える時間を減らす開発者に分けます。
• これにより、チーム全体が、コードベースを知らずにゲームデザインに取り組む半分と、機能がどのように使用されるかを知らずに機能に取り組む半分に分割され、ゲームに基づいてエンジン機能を思い付くことができる人は誰もいなくなります。簡単に実装できる機能に基づいてゲームデザインを設計または提案します。

事前に構築されたクラスのライブラリを使用せずに今日のゲーム開発を想像することは不可能です。結局のところ、それがGodot、Unity、Unrealなどのツールセットを備えたエンジンを成功させる理由です。 しかし、これらすべてのエンジンの違いは、プログラミングとゲームデザインの間に線が引かれ、両者の間にどれだけのギャップが生じるかということです。
そして、私の観察に基づいて、スクリプト言語の選択は、そのようなギャップを作成したり、それを埋めたりすることができる最も重要な要因の1つであると思います。

ちなみに、私がGodotに深く関わってきたのは、前期の必須エンジンとしての確立に取り組んでいるからです。 私が話しているだけでなく、私の結果を引き出していることをあなたは知っています。 ;-)

@RebelliousX私はあなたが何をしているのかまだよく理解していないことを認めなければなりません。 しかし、必要なのは参照またはポインターであると言ったので、新しい機能要求を開いて、そこに問題のコード例を投稿できますか？ 正直なところ、問題は言語機能の欠落ではなく、コードアーキテクチャの1つであるように思われます。

私は、KISSが主に小さなチームに利益をもたらすことを付け加えるべきでした。 Godotは機能満載なので、1人の開発者がゲームを作成できます。 しかし、プロジェクトに開発者が増えるとすぐに、「迅速で汚い」ことが起こりにくくなり、プロトタイピングや一時的な修正が必要になります。その後、ルール/ガイドラインを設定する必要があります。 ですから、それは本当に誰が、そして何のためにエンジンを使用しているかに依存します。

Godotは一般的に、私たちが思っているよりも多くの制約があります。 「c-static-style」シングルトンまたはグローバル変数を作成することはできません。理由は、メモリリークとスレッドの使いやすさです。 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アセットとしてコンパイル（またはオンザフライで実行）できます。 しかし、これについて言えば、Unityのようなcsprojを生成する必要がありますか？

@Warlaanあなたの経験を共有してくれてありがとう。 間違えた場合は訂正してください（長い投稿でした）が、プログラマーにとっては、オーバーコーディングではなくゲームの開発に集中できるように、機能の少ない言語を提供する方が良いと言っていますか？

もしそうなら、これは非常に微妙な観察です。 Godotの開発者は、ユーザーベースに最適なことをしなければならないと思います。彼らは何が最善かを知っています。

そして、私自身、今日、ここにいる人（私も含めて）がUrho3Dを微妙に求めているだけでなく、他の人がGDevelopを求めているのではないかと考えていました。 Godotは明らかにこれら2つの中途半端なツールであり（ただし、Urho3Dのようにプロに最適です）、そのままにしておくべきだと思いますが、Unityは常に影を落とします。なぜなら、ここには多くの人がいるからです。それから来ます。

GodotがUnityのリップオフであると期待するのは公平ではないと思います。Godotのデザインは明らかに優れており、私が知る限り、パフォーマンスも優れています。 しかし、一部の人々は、GDScriptは「深刻な」開発には適しておらず、Unityが使用する古いバージョンのMonoもある意味で「カスタム」ランタイムであるにもかかわらず、カスタムランタイムであるためにそうなることはないと考えています。 さらに、UnityでC＃を作成する場合、ほとんどの場合Unityでのみ機能するコードを作成し、それらのデザインパターンに従うため、別の言語を使用することをお勧めします。

C＃を望んでいる人は間違っていると思いますが、私の意見では、次のような妥協案を提示することをお勧めします。

1）パフォーマンスの向上（静的型付け、おそらくJIT）
2）サードパーティライブラリのサポートの向上（FFIおよびより簡単なC ++統合による）

GDScriptの場合。 残りはC ++で行うことができ、他のスクリプト言語を実装するモジュールを作成することもできます（ファーストパーティである必要はありません。必要に応じて、誰でもC＃モジュールを作成できます）。

@Zylann正直なところ、同等のC ++の代わりにそのコードを書くことに利点はありません。そうすれば、C ++コードのパフォーマンスが向上します。

@ paper-pauperこのコードを書くことの利点は、GDScriptと同じです。エクスポート先のプラットフォームごとにエンジンを再コンパイルする必要はありません。そして、言語を選択できます（パフォーマンスは先に述べたように、1つのポイントだけではありません）。 現在、GDScriptのエクスペリエンスが優れており、純粋なパフォーマンスにはC ++が最適であることに同意します。 しかし、C ++がどんなに優れていても、やりたくないという人もいます。
私はGodot + C＃に個人的には興味がなく、Godotに追加するとどうなるかを評価するだけです。 そして、それはそれほど単純ではありません：p

素晴らしい本GameScripting Masteryを読んだ後（Red Dragonのコンパイラに関する非ゲームの本を除いて、この主題に関する多くの本を見つけることはできません）。 私の結論は、GDscriptは適切であり、スクリプト言語に機能を追加し続けるのは非常に簡単であるため、その能力が失われるということです。 最も重要なことは、肥大化していないスクリプト言語を実装し、さまざまなプロジェクトに適したものにするために可能な限り一般的なものにすることです。 同じ本から、UnrealはLLVMでC ++を使用していると書かれています。

別のランタイムを実装するよりも軽量かもしれない別のアイデア：TypeScript（ランタイムなしのC＃に非常に似ています）のようなトランスパイラーをJavaScriptの代わりにGDScriptを出力するように適応させるのはどうですか？ これはGodotに含める必要はありません。実際、サードパーティのモジュールである可能性があります。 少なくとも静的型付け（コンパイル時）と多数のライブラリを提供し、GDScriptと同じパフォーマンスを発揮します（GDScriptであるため）。

私はTypeScriptが好きですが、そのような複雑さを追加する意味がわかりません。 誰かがそうする場合、彼らはそれを維持して新しいバージョンのTSと互換性を持たせる必要があります。 また、TSはJSのスーパーセットなので、これでJSをGDScriptにトランスパイルできますか？ そして、トランスパイラーにバグがある人がいて、それがエンジンのバグだと思っている人もいます。

それでも、JITをより簡単に利用でき、エンジンおよび現在のGDScript自体と密接に関連する静的バージョンのGDScriptを使用することをお勧めします。

C＃のポイントは、Godotの外部でも使用できる確立された言語を使用することです。 TypeScriptはこれに合うかもしれませんが、Monoランタイムを埋め込むよりもTSトランスパイラーを作成する方が簡単だとは思いません。

私にとって、IRCで述べたように、最良のオプションは動的にリンクされたモジュールを作成する機能です。 そのため、C ++での作業がより簡単になり、スクリプト言語としてのC＃用とC ++用など、さまざまな言語のサードパーティモジュールが存在する可能性があります。 これにより、メインエンジンのバイナリを肥大化させることなく、Godotのリソースを増やす能力が向上します。

@vnen

私にとって、IRCで述べたように、最良のオプションは動的にリンクされたモジュールを作成する機能です。 そのため、C ++での作業がより簡単になり、スクリプト言語としてのC＃用とC ++用など、さまざまな言語のサードパーティモジュールが存在する可能性があります。 これにより、メインエンジンのバイナリを肥大化させることなく、Godotのリソースを増やす能力が向上します。

ああ、私は100％同意します-実際、私は＃3936で同様の見解を表明しました。 欠点としてC＃のランタイムについて言及したので、私はそれを捨てていました:)

私にとって、 @ Zylannによるその例のC＃モジュールは素敵です。それが利用可能であれば、今すぐUnityから切り替えます。C++のパフォーマンスの向上やGDScriptの「使いやすさ」ではなく、快適さです。

私はまだGodotに慣れていないので、テストゲームを作成する機会はほとんどないので、私の意見は有効ではないかもしれませんが、私にとってGDScriptは最大のハードルであり、ノードでの動作方法ではありません。とシーン-私はそれを理解しています（そしてそれはかなりきれいです！）。

しかし、私にとっては、文字通りGDScriptの構文であり、控えめに言っても、コードエディターが大幅に不足していることは言うまでもありません。すでにすべてのショートカットを知っているので、VSを使用したいと思います。
私は何年にもわたってC＃を書いてきましたが、正直なところ、GDScriptで書き込もうとしている子供のように感じます。

開発者が快適に書くことができるようにすることで何が失われるでしょうか？ モノラルやLinqのような空想的なものは必要ありません。コードを書いている間、快適に過ごしたいだけです。
私はGDScriptのC＃のような構文、少なくとも中括弧、セミコロン、および明示的な型を使用するオプションを受け入れるでしょう-私は暗黙的な型に個人的に耐えることができません、それらは私を夢中にさせます。
GameMakerでは、さまざまな人口統計に対応するために構文を変えることができると思います。

もちろん、これはGodotでの数時間からの私の2セントです-同意しないでください（ほとんどの人がそうすると確信しています）。

また、私は何かが欠けていると思います-誰もがとても愛しているのはGDScriptについて正確には何ですか？
私は気分を害しようとはしていません、私はまだそれを見ていません。
私はPerlに精通しているので、暗黙の型の力などを知っていますが、それ以上のものが必要ですよね？

@Pikl ：

また、私は何かが欠けていると思います-誰もがとても愛しているのはGDScriptについて正確には何ですか？
私は気分を害しようとはしていません、私はまだそれを見ていません。

GDScriptのポイントは、構文（Pythonesque）ではなく、エンジンとの統合性に関するものです。 衒学的に聞こえるかもしれませんが、別のシステムに移行する場合、構文は最も懸念事項ではありません。 最も重要なのはAPIです。 今すぐC＃を追加したとしても、Unityでの方法は、Godotでの方法と同じではないため、新しいパラダイムに不快感を覚えるでしょう。

申し訳ありませんが、すべてのプログラマーの快適ゾーンに参加するために言語を追加した場合、私たちは永遠にそれを行うことになります。 Unityユーザーにストレスを最小限に抑えることは理にかなっているかもしれませんが（現在、Unityユーザー向けのGodotガイドを作成しようとしています）、GodotがUnityのように機能するように適応する必要はないと思います。 それ以外の場合は、Unreal、Urho3D、GameMakerなどのユーザーに対して同じことを行う必要があります。

これは、C＃が発生していないということではありません（実行可能であり、エンジンの利益の範囲内である可能性があります）。これらの議論が他の多くの言語やエンジンにも当てはまるということだけです。

@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の開発者は、インデントを必須にし、冗長な中括弧を削除することにしました。
この場合、すべてのスクリプトファイルが1つのクラスとして定義されているため、クラスレベルでインデントする必要はありません（インデントでマークされたサブクラスを使用している場合を除く）。
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キーワードの単なる追加情報です。

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

したがって、このC＃コードの違い

    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のパラダイムに慣れるまでには数日かかると言わざるを得ませんが、その単純さが「クリック」されると、入力するのと同じくらい速くアイデアから実行に移ることができます。

@vnen ：

これらの議論が他の多くの言語やエンジンにも当てはまるというだけです

十分に公平です、私は息を止めていませんし、収容されることも期待していません-これは私の領土ではありません。

現在、Unityユーザー向けのGodotガイドを作成しようとしています

多分私はそれを手伝うことができますか？ 私はUnityを数年間使用しており、他のエンジンと比較してそのことをよく知っています。私はこのガイドの優れた実験用ネズミになるでしょう。

@Warlaan ：

私は今、GDScriptについて人々が何を好むかがかなり明確になっていると思います。 意味のないものや冗長なものを入力する必要はありません。構文は、Godotに存在しないオプションや言語機能をほのめかす代わりに、使用しているオプションを反映しています。

これは完全に理にかなっています。これは、スクリプトの入力に必要なキーストロークの量を減らすというPerlのイデオロギーに沿ったものです。 しかし実際には、その例で実際に入力するキーストロークの量は同じです。VSのオートコンプリートを最大限に使用し、スペースを押すか開く前に、キーワード、タイプ、または変数名に3文字を超える文字を入力する必要はほとんどありません。それを完了するためのブラケット。 そして、そこにある実際の余分な「不要な」文字については、私はそれらをそこに置くことを好みます。それは単なる構文上の砂糖の好みです。
Godotにはオートコンプリートがありますが、時間がかかります。非常に時間がかかるため、ほとんどの場合に表示される前に、コードの行全体を入力することがよくあります。

したがって、GDScriptについて人々が気に入っているのは、GDScriptを可能な限り最小限に抑えて、使用可能な正確な機能を提供し、キーストロークを削減することです。

私はそれを理解しましたが、それは私がそれをもう楽しむのに何の役にも立ちません-私はGDScriptをタイプするのが苦手ですが、それでも完全にうまく読むことができます。 私はそれを学ぶのに苦労していません、私はそれが好きではないようです。
スペースインベーダーのクローンを作成するのにあと数時間かかると、私を納得させるのに役立つかもしれません。GDScriptが好きです。

結果論：
GodotでC ++のみを使用することは可能ですか？ 私は正直に言って、C ++を学び、GDScriptよりもそれを使用したいと思っています。

多分私はそれを手伝うことができますか？ 私はUnityを数年間使用しており、他のエンジンと比較してそのことをよく知っています。私はこのガイドの優れた実験用ネズミになるでしょう。

@StraToNは、この種の支援を求めるFacebookグループに投稿しました。 彼に連絡してください（他に誰かがそれに取り組んでいるかどうかはわかりません）。

@neikeqありがとう、完了！

@Warlaanコードの比較は理解していますが、私にとっては、主にC＃がより多くの機能を備えていることを証明しているため、より冗長です。

多くのクラスとの名前の衝突を回避するための名前空間があるため、 usingが必要です（これは私自身のゲームプロジェクトですでに発生しています）。
時間の経過とともにコーダーエラーを防ぐためのカプセル化の概念があるため、 publicが必要です。
さまざまなプロジェクトのニーズに合わせて組み込みのアノテーションを拡張し、ツールを改善できるため、 [SomeClass]があります。
中かっこについては...スコープを定義する以外に利点はありません。

これらの機能には理由があります。 その中でも、スケーラビリティと言えます。 GDScriptのすべてのコードベースを使用して巨大なクロスプラットフォームの3Dゲームを開発しますか？ ええ、できます。 しかし、私がリストした長所のために、多くのユーザーはC ++、C＃、またはJavaを好むでしょう（そして私はフレームワークではなく言語について純粋に話します）。

しかし同時に、Godotで開発されていることを私が知っている「巨大な」ゲームプロジェクトはないので、それほど多くの例はありません：p
また、C＃にはいくつかの悪い機能があります（警告：個人的な意見が先にあります）：

静的変数を持つことができます。 これは間違っているので、グローバルな状態/シングルトンから多くのエラーが発生します。 自動ロードとは異なり、これらはどのシーンスコープにもバインドされていません。
if（）ステートメントのwhile（）の最後にセミコロンを誤って入力すると、セミコロンが役に立たなくなり、見つけにくくなる可能性があります。
オーバーコーディングできます。 私は、間違った方法で使用すると、C＃コードが非常に複雑になる可能性がある一方で、別のより単純なコードでも同じことを行うことに同意します。 しかし、それは人/経験に依存します。

ああ。 preload()については触れませんでした。 コンパイラのトリックに頼らない限り、これはC＃/ Javaに到達することはできません：p

誰かがすでにMonoモジュールの実験を始めましたか？

C＃開発者としての私の最も謙虚な意見をこれに追加するには...

GodotにC＃を追加することにはあまり価値がないと思います。何かを成し遂げるには、Godotのクラスを学ぶ必要があり、C＃を追加することで実際に得られるのは、より馴染みのある（多くの）Cスタイルだけだからです。構文と静的型付け。
構文については議論の余地があります。Pythonは初心者にとって習得しやすいという評判があり、GDScriptはPythonと非常に似ているため、同じことが当てはまると思います。
ある程度経験豊富なプログラマーは、とにかくその構文を理解するのに問題はないはずです。一貫性があり、より自由な形式のCスタイルの構文よりも落とし穴がかなり少なくなります。

一方、静的型付けは、パフォーマンスを向上させるだけでなく、いくつかの点で開発の速度を向上させるのにも役立つ可能性があります。 オートコンプリートツールは、give関数/メソッドがどのタイプを期待して返すかを教えられるのが大好きですが、タイプヒントだけでそれを実現できます。
ただし、これはGDScriptに追加できますが、追加の言語は必要ありません。

また、C＃の実装はそれほど簡単ではなく、エンジンを現在の状態にするだけでかなりの時間と労力が費やされますが、現在はC＃が上にあるかGDScriptの代わりになっています。

締めくくりのコメントとして、私は一部の人々が間違った方法をとることを知っています、私はこれを言う必要があります：

私の観察では、私たちの技術にあるべきほどしっかりと足を踏み入れていないかもしれない一部のプログラマーは、彼らが利用できるすべての力で彼らが知っているものにしがみつく傾向があります。
この現象は、C＃開発コミュニティで特に広まっているように見えますが、これは私の偏見かもしれません。
これを読んでいる人の誰かがその説明に合うかもしれないと思うなら、私はこのおなじみの箱の外に出て新しいことを学び始めることをお勧めすることができます、それはあなたが思っているほど難しい仕事ではありません、そしてあなたがしっかりしているとその新しいことを理解すれば、おそらくあなたはすでに知っていることについての理解を深めることができるでしょう。 それだけの価値があります。

静的型が好きですが、それが起こった場合、ジェネリックスをどのように扱いますか？ そのインスタンスで単に動的型を使用しますか、それとも制約を使用できるようにしたいですか？ -たとえば、intとboolのみを許可します。

名前空間は大歓迎です。GDScriptにまだ存在していないことに驚いています。

メソッドにコロンの代わりに中かっこを使用するオプションも素敵です。中かっこは不要ですが、そこに置くのが好きです。終止符なしで本を読むようなもので、耳障りです。

タイプヒントは、コードの完了が完全に機能するのを妨げるギャップを埋める可能性があります。 私はかつてLuaを使ったプロジェクトに取り組んだことがあり、彼らもこれを望んでいました。 調査によって私はここに導かれました： https ：//github.com/andremm/typedlua/blob/master/examples/http-digest/http-digest.tl#L48
これは、xDを示唆する型を深く掘り下げた場合に、関数パラメーターがどのようになるかを示しています。
しかし、トレードオフがあるはずだと思います。 TypeScriptまたはHaxeがどのように機能するかをご覧ください（どちらもバリアントの混合と型指定を許可しています）。 また、タイプヒントはすでにGodotにあります。 export（）でのみ使用されます:)

誰かがすでにMonoモジュールの実験を始めましたか？
@Zylann

GodotSharpをチェックしてください。 リポジトリ内の現在の状態はまだ使用できません。 私のローカルリポジトリでは、2D /プラットフォーマーのデモをC＃に変換するのに十分なもの（Vector2とMatrix32のみが基本タイプとして使用可能）を実装できました。ただし、参照がまだ機能していないため、GDScriptから実行される敵と弾丸のインスタンス化は除きます。
これはプレーヤークラスの例です： https ：//github.com/neikeq/GodotSharp/blob/master/platformer_cs/Player.cs

@Pikl

結果論：
GodotでC ++のみを使用することは可能ですか？ 私は正直に言って、C ++を学び、GDScriptよりもそれを使用したいと思っています。

はい、可能ですが、現時点ではそれほど簡単および/または便利ではなく、Godotを最初から再コンパイルする必要があります。 C ++が第一級市民であることに興味がある場合は、＃3936のサポートを示してください。そうすれば、多くの作業をせずにGDScriptと一緒に（または排他的に）使用できます。

@Zylann Piklは、GDScriptの構文をC＃の構文に似るように変更して、Unity開発者が読みやすくすることについて質問しました。 それが私がコメントしていたことです。 はい、C＃にはさらに多くの機能があります。これが、削除したキーワードと文字がそもそもそこにあった唯一の理由です。 そのため、C＃コードのように見えるGDScriptコードを作成するためだけに追加する必要はありません。GDScriptにはない言語機能を示唆する構文を使用するため、これは間違いです。

@Piklキーストロークの量ではなく、選択肢の数と追加の文字の暗黙の意味についてです。 GDScriptには、追加のキーワードを正当化する機能の一部がありません。 たとえば、C＃のデフォルトの可視性修飾子はパブリックではないため、すべての変数、クラス、関数の前にキーワード「public」を付ける必要があります（名前空間を除く-ユースケースに基づいて変更されます... Microsoftが次のように判断した別の状況KISSは80年代のバンドであり、GDScriptではすべてが公開されています。

では、すべての機能を備えたC＃を追加してみませんか？
Zylannがすでに述べたように、C＃をGodotに追加した場合の影響は、予測するのがそれほど簡単ではありません。 まだ読んでいない場合は、このスレッド（https://github.com/godotengine/godot/issues/5081#issuecomment-225226235）の私の長い投稿を読んでいただければ幸いです。 開発者として、私は常により強力な言語を求めていたでしょう。 余暇には、paper-pauperが最初の投稿でKotlinについて言及したという理由だけで、現在Kotlinを見ています。
しかし、プログラミング言語がゲーム開発者の結果と行動に与える影響を調べる機会があったので、強力な言語ではなく適切な言語を選択することがいかに重要であるかを理解しました。
リンクされた投稿で説明したように、C＃は、プログラマーを

• アセットストア用のものを書く
• チュートリアルを書く
• バグを修正します。

私の経験では、Unityにはゲームプレイプログラミング文化はあまりありません。 何らかの問題が発生するとすぐに、それを解決するためのパターンまたは事前に構築されたアセットを探し始めます。 実際、プロジェクトについて何も知る前にパターンを選択する人はかなり多く、そのような精神的な柔軟性の欠如はゲームプレイの結果に影響を与えます。

そして、それは私のお気に入りの反論です。最初の投稿には他にもいくつかの良い議論がありました。 ;-)

JVMの問題は、JVMが重すぎることです。 誰かが鳥を見ましたか？ Javaの世界との互換性はどれくらいですか？

@neikeqこれは、パフォーマンスが悪いことを意味するわけではありません。AFAIKJVMのパフォーマンスはCLRよりも優れており、ゲーム開発にはるかに適したガベージコレクターでもあります。 また、Windows、Mac、GNU / Linuxのいずれであっても、ほとんどのコンピューターにインストールされます。

また、より高品質のFLOSSライブラリが豊富にあり、一部の人の意見に関係なく、クロスプラットフォームのサポートが向上しています。

2つの間で、JVMはゲーム開発に明らかに優れていると思います（ただし、JVMとCLRの両方を同じように回避します）。

鳥は面白そうです。 私はそれを使った経験がないので、あなたの質問に答えることはできません。その互換性はUnityのMonoバージョンと同じくらい問題になるかもしれないので、あなたがいない限りサードパーティのライブラリを使うのは本当に厄介です。提供された.NETバージョンの1つにたまたま1つ見つかりました。

ただし、GDScriptとC ++に加えて、軽量のJava実装を追加オプションとして使用すると、迅速なターンアラウンドタイムが必要で、コード品質を犠牲にする可能性があります（ゲームジャムや新しいバックエンドアイデアのラピッドプロトタイピングなど）。

@neikeq Avianは、c ++プロジェクトにjavaスクリプトを提供することを念頭に置いているため、これは本当に良い候補です。 それは非常に小さい場合があります（正しく思い出せば100kbのようなものです）。 Avianを使用してiOSポートをリリースしていたlibGDXゲームについて聞いたことがあります... jMonkeyエンジンはiOSでもAvianを使用しています）。 一般に、Avianには、sun / oracleクラスのようなJVMに通常付属しているパッケージ全体が付属していません。 ただし、「元の」Javaクラスはゲームにはまったく適していないため、問題はないと思います。これが、libGDXなどのライブラリがベクトルまたはデータ構造に独自の実装を提供する理由です。これらのクラスも再実装する必要があります。 （ただし、元のJavaクラスのさまざまな部分を埋め込むのは簡単ですが、含めるほど、Avianは大きくなります）

@ paper-pauperゲームにバンドルされると仮定して、サイズが重いことを意味しました。 しかし、あなたが言ったように、それはほとんどのコンピューターにインストールされており、libGDXのようなフレームワークの人気を考えると、それは最良の選択肢かもしれません。
GDScriptの代わりとしてのC ++に関する私の問題は、その構文がひどいことです。 それは生産性のキラーです。 エンジンとモジュールの開発には問題ありませんが、ゲーム全体を作成することはしません。 そうは言っても、私は＃3936に賛成で、Unrealのようなものを持っていますが、それを代替の「スクリプト」言語とは見なしません。

@ kubecz3k他のJVM言語をサポートしていますか？ 例：Kotlin

@neikeqええ、私が知る限り、Javaバイトコードと完全に互換性があるため、jvm対応言語（kotlin、scala、jpythonなど）をサポートします。
鳥のグーグルグループについていくつか質問するかもしれないと思います： https ：//groups.google.com/forum/#！forum / avian
かなり活発なようです

+1を使用して、C ++を代替スクリプト言語として表示しないようにします。 前に言ったように、Godotには、スクリプト用に最適化された1つの言語と、バックエンド開発用に最適化された1つの言語があり、両方の領域で一種の「まあ」である1つの言語があるのは良いことです。

それは、動的なlibサポートとより高速なC ++開発が私が見たいものではなかったということではありません。

しかし、Avianに熱狂しすぎないように、libGDXのメイン開発者からのブログ投稿があります。libGDXがiOSポートにAvianを使用していない理由を説明しています。 http://www.badlogicgames.com/wordpress/?p=3925 （鳥の部分までスクロールダウン）
私はjvmプログラマー/ハッカーではありません（しかし、作者は-RoboVm（Microsoftによって購入されて閉じられた別のjvm）にも取り組んでいたので）、これが実際にどれだけに変換されるかはわかりませんAvianがスクリプト言語としてのみ使用されている状況（コアエンジンに電力を供給していない）

あなたのほとんどはおそらく私よりも経験豊富なプログラマーですが、私の2セントがあります。 1年前、私はC＃を応援していました。 しかし、GDScriptの構文をすぐに学びました。 結局のところ、APIを学ぶ必要があり、それはおそらく学ぶのに最も時間のかかることです。 そうですね、C＃は必要ありません。 @Warlaanは、C＃に対して多くの正当な理由を引き出しました。 C＃の実装にも多くの時間がかかります。 それはまた、より多くのバグを意味するでしょう。 ええ、コードベースに貢献する素晴らしいコミュニティがありますが、 @ reduzはまだ1つしかありません。C＃の実装に必要な時間は、本当に必要な機能に投資する必要があると思います。 何人のGodot開発者がGDScriptに満足していますか？ はい、もっと速くなる可能性がありますが、他に問題はありません。 あまり良くない2つのスクリプト言語よりも、1つの素晴らしいスクリプト言語が欲しいです。 Unityでさえ古いMonoに遅れをとっています。

私が欲しいのは、GDScriptでの静的型付けです。 スクリプト言語としてのC ++ではなく、C＃ではありません。 GDScriptに焦点を当てて、現在よりもさらに優れたものにしましょう。

私が14年間開発を主導してきたエンジンは、ビジュアルスクリプティングスレッドで言及されていたので、完全に独自のC＃のような言語で記述された新しいエンジンを開発していたので、ここに2セントを追加すると思いました。

独自のコンパイラ（C ++でブートストラップした後に独自の言語で記述）を作成し、C ++（ほぼ純粋なC）コードにコンパイルして、サポートするすべてのプラットフォーム（XBox / PS / PC / Wii /）のコンパイラにフィードしました。等）。 必要に応じてパフォーマンスを調整できるように、独自の世代別ガベージコレクターを作成しました。このようにすることで、エンジン全体で使用され、十分にテストされ、プロファイルが作成されました。 また、C ++にクロスコンパイルしていたため、必要に応じてシステムAPIを呼び出したり、プラットフォーム固有の操作（SIMD）を組み込んだりできる「ネイティブ」関数でC ++コードを簡単に記述できました。

Unityが大量のC ++コードをMonoとマージしなければならなかったことがどれほど苛立たしいことか、私には想像できません。これは、 @ GlaDOSikが指摘したように遅れている理由をおそらく説明しています。 それは確かに私たちの誰もがやりたいと思ったことではありませんでした。

私たちの主な目標は、エンジン、エディターとツール、およびゲームプレイコード間で使用される言語を単一の言語に統合することでした。 以前は、エンジンとツールは完全にC ++であり、レベルデザイナーが好むすべてのゲームプレイに視覚的なスクリプト言語（少なくともCコードのように見えました）が使用されていましたが、大多数を書いていたゲームプレイプログラマーの大多数を悩ませていましたコードの。 また、ゲームプレイ開発に必要となる可能性のあるもの（ステートマシンのサポートなど）に合わせて言語を調整することもできました。

_しかし、みんなを喜ばせることはできません。_誰かがスパゲッティの青写真などのノードベースの「コード」の厄介な混乱に取り組んだり、デバッグを手伝ったりする必要がある場合は、報復に目をつぶってみたいと思います。 私は、C ++コードを読み込もうとしているアーティストが同じことをすることを期待しています。 あなたができることは、_最良の_解決策が何であるかについて議論するために_多くの_時間を無駄にし、さらにすべての人を喜ばせようとすることです。 ある時点で、適切な人々のためにできる最も生産的なツールを作ることに集中する必要があります-そして時にはそれは少数の人々が何か新しいことを学ばなければならないかもしれないことを意味します。

「C ++でなければ遅い」というのがよくあるようですが、最近のゲームプレイコードでは、_shipped_ゲームの大部分がC ++以外のもので書かれていると思います。 特にGDScriptからパフォーマンスの問題を投稿している人を見たことがありませんが、何が遅いのかを聞いてみたいと思います。

GDScriptの紹介に関する限り、次のようになりました。

• OMG Pythonのような！？ それはナッツです、空白は重要ではありません！
• うーん、「小文字」スタイルのファンではありません（みんなを喜ばせることはできません）。
• さて、これは実際にはちょっとクールでよく考えられています。
• ええ、これはエディターとうまく統合されています、私は確かにゲームプレイコードといくつかのエディタープラグインのためにこれで非常に生産的であるのを見ることができました！

GDScriptには多大な労力と時間が費やされているようで、適切なツールのようです。 だから私は本当にそれを作ることに取り組んだ人々に称賛を言いたかったのです！

@Ziflinねえ！ ここでお会いできてうれしいです。Viciousは私たちがプロとして使用した最初のゲームエンジンの1つでした（ただし、実際に使用するよりもハッキングして問題を修正するために@ punto-に雇われました）。

ビジュアルスクリプト言語は本当に悪夢でしたが、ソースコードは本当によくできていて、きれいで、整理されていました。 Torqueで作業した後、それは至福でした。 私はそれを使って多くのことを学びました。 ソニーは、10年前に誰もがここでそれを使用していたので、ラテンアメリカでそれを販売する素晴らしい仕事をしました。

それを使って作業したときに覚えている最も驚くべき瞬間は、言語をリストしたコードに偶然出くわしたことだと思います。「ポルトガル語はサポートされていません」というコメントがありました。

私たちは本当に笑って冗談を言っていました。ゲームプロデューサー（私たちの後ろにいて、彼に気づかなかった）は恐怖に震え、「待ってください。今残っているのは、ゲームをポルトガル語に翻訳することだけです。 、これは冗談ですよね？」

しかし、ポルトガル語に中国語を使用しただけで、すべて正常に機能し、ゲームが出荷されました。 あなたたちがまだそれを開発していることを知ってうれしいです！

（ @Ziflinからの引用）私は実際に誰かがGDScriptから特にパフォーマンスの問題を投稿するのを見たことがありませんが、彼らから何が遅いのか聞いてみたいと思います。

私は個人的にこのプロジェクトでCPU / Gdscriptのボトルネックに達しました： http ：//godotdevelopers.org/index.php？topic = 15519.0

私は、8台の車のそれぞれを制御するためにGDscriptでいくつかの基本的なAIと基本的な古い学校の疑似物理学を書きました。
まだ最適化の余地があったので、このパフォーマンスの問題について公の場で大声で叫ぶことはありませんでした。
しかし、もっと車を追加したいのであれば、C ++用のGdscriptを削除せざるを得なかったでしょう（編集：何度もコンパイルする必要がないので避けたいです）。

また、昨年、バグ（動物）ごとに基本的なAIにGDscriptを使用していたこの他のプロジェクトで同じCPU / Gdscriptのボトルネックに遭遇したと思います：http： //ludumdare.com/compo/ludum-dare-32/？ action = Preview＆uid = 50893
バグ（動物）を追加すればするほど、パフォーマンスは低下しました。

誰かが望むなら、私はそれについての私の経験を共有することができます。

@SuperUserNameManどうぞどうぞ、しかし私が開いたこの他のチケット＃5049（GDScriptのパフォーマンスについて具体的に説明しています）はそれに適していると思います。

@ paper-pauper：＃5049に貢献できるかどうかわからない（これは、JITを追加することについて、親指を立てるだけで何ができるかについてです）。 私が共有できる経験は、私が到達したボットネックの種類、特定の症状、回避する方法、最適化する方法、および犠牲にしなければならなかった「godotの設計上の利点」に関するものです。

@SuperUserNameMan型推論によるJITの実装についてはまだあまり考えていませんが、そのためには、VMは最初に静的型付けをサポートする必要があります

あなたがどのようなAIコードを参照しているのか聞いてみたいと思います。
私の先入観は、8つのエンティティで実行したときにパフォーマンスの問題を引き起こす可能性のあるコードは、おそらく実際にはゲームコードではないため、とにかくC ++クラスに配置する必要があるということです。そのため、私は質問しています。

@reduzハハ、どうやらそれは小さな世界です！ そして、ええ、ビジュアルスクリプティングの種類は制御不能になりました（実際には、トリガーとイベントロジックの小さなビットを処理するためだけのものでした）。 ヴィシャスは今年初めに実際にドアを閉めましたが、そこで働くのはとても楽しかったです。

@ paper-pauperあなたが言及した他のトピックをチェックします。 私は、人々がこのスレッドでパフォーマンスの問題を投稿し始めることを本当に意味していませんでした。

GDScriptが静的型付けを追加する場合、IL-> C ++遷移による余分なオーバーヘッドを回避し、ランタイムを小さく保つ（JITコンパイラーなどがない）C ++に直接変換するオプションがある方が簡単かもしれません。 次に、GDScriptでプロトタイプを作成するか、GDScriptを使用してモッドを作成できますが、最終的なビルドに必要な場合は、C ++に自動変換して速度を上げることもできます。

そうすることで、人々が使用していた既存のIDE（VC ++などとGodotエディター）も維持されます。 実際には、VC ++を使用して言語をデバッグし、コンパイラーが.cppファイルに#LINEディレクティブを生成したため、元のコードを簡単にステップ実行してブレークポイントを設定できます。 したがって、理論的には、エディターで通常のGDScriptを使用してプロトタイプを作成し、デバッグすることができますが、「GDScript-> C ++」が有効なビルド中も、C ++ IDE /デバッガーを使用して、gdscriptファイルにブレークポイント/デバッグを設定できます。 私たちにとって、生成されたC ++ファイルは一時的なものであり、コード生成の問題があった場合にのみそれらを調べました。

とにかく、ただの考え。 あなたが今素晴らしいスクリプト言語を持っているという事実は間違いなくプラスであり、それは確かにユーザー作成のmod、高速プロトタイピング、そして言語への新しい機能の追加のようなことを可能にします。

実際、パフォーマンスの問題をこのスレッドにも投稿することになっていることを理解していませんでした。 ここがより適切でした： https ：//github.com/SuperUserNameMan/kart-zero/issues/1

@Ziflin実際、他の問題で話し合っていたのは、最初に、GodotのリフレクションAPI全体を公開する最小限のAPIを介してプレーンCを使用してgodotモジュール/スクリプトを記述するための最小限のC APIを追加することです。これにより、バインディングの配布に関する一般的な問題が解決されます。 Godotを再コンパイルせずにさまざまな種類のライブラリに

この例としては、Steam API、ODBC、SQLite、Kinectなどをバインドしたい人がいます。これらはすべてC ++でモジュールを作成する必要があります。 これをCAPIで行うと、C ++に対して動的にリンクする問題が解決されます（これは、すべてのコンパイラー、または独自のABIを持つコンパイラーバージョン、およびGodotバージョン間で発生する可能性のあるシンボルサイズの不一致の問題のために非常に制限されます）。 Cにはこれらの問題はありません。

それが機能すれば、GDScriptをCにコンパイルし、ゲームの実行時またはエクスポート時に実行時にロードするのは非常に簡単です。

@reduzああかっこいい。 つまり、基本的には、GDScriptに必要なものを公開できる「プラグイン」DLLを作成できるということですか？ （または私は誤解しましたか？）

それが機能すれば、GDScriptをCにコンパイルし、ゲームの実行時またはエクスポート時に実行時にロードするのは非常に簡単です。

これは、いくつかの新しいC ++ノードから派生した型を含むdllを作成したい人にとっては機能しますか？

ただし、DLLの問題のいくつかを修正するには、新しいC ++の「モジュール」のサポートで十分であるように思われるのは少し悲しいことです。

luaやRubyなどの埋め込み可能なスクリプト言語を使用してみませんか？

ドキュメントを読むため@ jersten - http： //docs.godotengine.org/en/latest/reference/gdscript.html

@Ziflinええ、しかし、リフレクションを介してC APIを使用する必要があります（ただし、リフレクションを介して関数ポインターを要求できるため、十分に高速である必要があります）。 目標は主に、ABIの問題を回避するDLLをロードする簡単な方法と、GDScriptをCにコンパイルして.soとしてロードする簡単な方法を持つことです。

私はここで私の2セントを価値のあるもののためにチップするつもりです。 私はC＃でコーディングしたことはなく、Javaでのみコーディングしました。 私はJavaを使用して気に入ったので、個人的にはJavaを好みますが、実際にはJavaよりもC＃をサポートしています。 C＃はUnityゲーム開発者が使用するものであるため、C＃を組み込むと、GodotはUnityが作成したこのインディー開発エコシステムの一部になります。 また、JVM言語が必要な場合は、Javaも適切な選択ではありません。 JVMにコンパイルする他のより良い言語があります。

とにかく人々は要点を見逃していると思います。 C＃/ Java！=スクリプト言語。 GDScriptで十分です。 学ぶのに十分簡単など。

Java（どのような目的でJVMを構築しますか？！構文？！機能するには特定のバージョンのJVMが必要ですか？！？）またはC＃（モノラルを実装してエンジンを破壊します;または独自に構築しますか？）のような言語を追加すると、エンジンが汚染されます。

GDScriptに問題がある場合は、指摘する必要があります。 その後、修正を試みました。

同意しません。 C＃は、GDScriptのようなPythonの優れた代替手段を提供する、Cのような言語に精通している多くのUnity開発者または開発者を引き付けると思います。 パズルの最後のピースは、コーディングに慣れていないアーティストを引き付けるビジュアルスクリプトです。 これはほとんどすべての人をカバーするはずです。
また、何をコーディングしても、どの言語でも同じであるGodotのクラスと関数を学ぶ必要があります。

Unity開発者がC＃を知っているために、C＃を主張するすべての人にとって、これを考慮してください。多くのUnity開発者は、C＃でのプログラミング方法についてがらくたを知りません。 彼らが知っているのは、Unity APIの使用方法です。これはたまたまC＃バインディングを持っています。 あなたは彼らをGodotに連れて行きます、たとえそれがC＃であっても、彼らはとにかく彼らが何をしているのかわからず、彼らに別のプログラミング言語を提供するのと同じように失われます。

追加の言語を含めることは、オーバーヘッドが大きくなり、プロジェクトが維持しなければならないことよりも多くなります。

私はこれについて多くのことを考えていました。C＃のようなものをサポートすることについての私の主な懸念は、それを使用するほとんどの人がGodotに来るUnityユーザーであるということです。 明らかに、公式テンプレートにはC＃を含めないので、モジュールを自分でビルドするのではないかと疑っています...
ほんの数人で使用される言語をサポートすることは、大きな努力になる可能性があります。

私は誤解があると思います：

• 彼らはGDScriptを見て、GDScriptはC＃と同等であると考えています。 C＃はスクリプト言語ではないという基本的なポイントが欠けています。
• 上記の事実のために、誰かが「JavaまたはC＃」と言うと、 彼らが本当に求めているのは、エンジンをC＃/ Javaに書き直すか、それらの言語をサポートするためにいくつかのバインディングを追加することです（笑いいえ）。

私は後者を想定しているので; C＃/ Javaでのデバッグは、複数のプラットフォームでの悪夢です。 これらの言語はどちらもプラットフォームに依存しないため（inb4では事実上すべてのOSにランタイムがあります）。 これは「一度書けばどこでもデバッグ」に変わります（これが、Monogameに書き込まれたゲームが最初にWindowsで公開され、次に開発者がそれらのプラットフォーム用にデバッグする必要があるため、最終的にLinux / Macで公開される理由です）。 これが、JVMアップデートがアプリケーションを破壊する理由です。

これらの言語のサポートを追加しても、エンジンに価値はありません。

引数が「moarUnitydevs」の場合。 次に、Unity開発者の移行に役立つドキュメントを作成する必要があります。 そのレイアウトの違いなど。

そのため、最終的に、どの言語を使用するかは問題ではなく、GodotAPIクラスなどすべてを学習する必要があると言いました。 Unityの開発者はC＃を知っているのでインスタの専門家になるつもりではありません。 C＃をサポートしている場合、Godotにとっては「善のオーラ」であると思います。 人々はもっと知っているように感じ、突然のGodotはよりアクセスしやすくなり、それほど怖くなくなりました。 Godot以外のユーザーからのGodotの最大の欠点は、独自のスクリプト言語を使用していることです。 Godotユーザーは、GDScriptが楽しくてシンプルな言語であるため、BSを知っていますが、部外者にとっては魅力的ではないように思われるかもしれません。
私は開発者の観点から話すことはできませんが、開発者がC＃の実装から何かを得て、それだけの価値がない限り、おそらく価値があるよりも多くの努力が必要です。 結局のところ、リード開発者の決定であり、彼らが決定したものは何でも私はそれで転がります。 それは良い決断になると確信しています。

GDScriptは事実上未知の言語であるため、少し不快であることに同意します。 しかし、LuaとPythonが削除された理由と、GDScriptを追加することの利点を読んだ後は、あまり心配していませんでした。

関連するかもしれないもう一つのこと：すでにC＃をサポートし、Unity、 Atomic GameEngineにもっと似ている別のMITライセンスエンジンがあります。 Unityにできるだけ近いものがどうしても必要な人はぜひ試してみることをお勧めします。

ここに2セントを追加します。 私にとって、C＃の大きな利点はパフォーマンスですが、C ++よりも操作が簡単です。 GDScriptは動的に型付けされており、すべてが非常に高速に記述されますが、実行が超高速になることは決してありません（ただし、かなり最適化される可能性がありますが、これは計画されています）。 C ++モジュールは非常に高速ですが、操作が面倒です。 C ++は必ずしも使いやすい言語ではなく、それらを使用するためにエンジンを再コンパイルする必要があることは、実際には最適ではありません。 私にとって、C＃は一種の妥協案です。GDScriptよりもはるかに高速であり、適切なサポートがあれば、C ++モジュールよりもはるかに簡単に操作できます。

そうは言っても、C＃である必要はありません。 静的に型付けされたコンパイル済み/ JITGDScriptであろうと、Swiftのようなものであろうと、私に関する限り、同様の効果を持つ他のすべてのものは問題なく機能します。 C＃は「マーケティング目的」に最適な場合があります。 同様のAPIがなくても、他のエンジン/フレームワークの開発者はおそらくそれをより快適に使用できます。 変更されたGDScriptは実装が簡単で、おそらくはるかにうまく統合されるでしょう。

スレッドが非常に長いことはわかっていますが、自分で投稿する前に、上記の投稿をすべて読んでください。 C＃は人々を惹きつけ、Unityユーザーにとって非常に便利であるという議論は、それが12倍以上言及された場合、それ以上有効になりません。

ここで、imho C＃がUnityに最適で、Godotに悪い理由を確認し、imhoがC＃を追加すると、独自のプロジェクトだけでなく、オンラインチュートリアル、今後のアセットストアなどでも、コードがダーティになる理由を確認し、imhoがなぜC＃からGDScriptに変更するときに人々が多くの新しいことを学ばなければならなかったという議論は無効です。

C＃が新しい人々をもたらすという議論についてコメントを追加しましょう。
なぜもっと多くの人にGodotを使ってもらいたいのですか？ オープンソースプロジェクトには、次のようなコミュニティが必要であることを完全に理解しています。

• 機能を追加します
• バグを修正
• 再利用可能なアセットを作成します
• 新機能の提案をします
• ワークフローのバグや問題を見つけます
• チュートリアルを書く

しかし、上記のすべてには、エンジンのコアアイデアを理解して評価する人々が必要です。 ライブラリに不要な機能を追加する人々は助けにならず、プロジェクトが放棄または分割されるまで、そのような機能に苦しむプロジェクトが複数ありました。
Unityは、自分が何をしているのかを本当に理解していなくても、チュートリアルを書く人々に特に苦しんでいます。これは、大部分がC＃のせいです。

GDScriptのように単純な言語を学ぶ気がない、または学ぶことができない場合、コミュニティに積極的に貢献し始める前に、Godotの背後にある設計哲学を完全に理解するために時間をかけるかどうかは非常に疑わしいです。 （「積極的に貢献する」とは、プルリクエストの送信からFacebookへのGodotに関する意見の投稿までを意味します。）

Godotは商用エンジンではありません。 Unityは、すべての潜在的な顧客であり、エンジンの広告を掲載しているため、できるだけ多くの人を呼び込むことに関心を持っています。 Godotをそのまま評価するユーザーの大きなコミュニティがあればいいのですが、より大きなコミュニティに対応するためにGodotの品質の一部を犠牲にする意味はありません。

@Warlaanの人々は一般的に時間を無駄にしたくないので、プロジェクトを構築するときに見つけたコードスニペットを使用します。 初心者にとって、使用するコードスニペットが記述されている言語を学習することになるため、あなたのポイントはやや関連性があります。これは、例を見て学んだ方法であり、GDスクリプトを知らなかったので、それを学びました。 問題は、何が最善であるか、またはこれがチュートリアルなどにどのように影響を与えるか、複雑にするかではありません。問題は（私にとって）C＃であるため、他のどの言語よりもGodotがこのインディー開発エコシステムの一部になります。Unityはその一部です。 これはUnityについてではなく、Godotについてです。

編集：いくつかの不必要に過酷な言葉を削除しました;-)

@trollworkout不快感はありませんが、あなたは私の主張を本当に理解していなかったし、あなたが言ったことについてもあなたが本当に考えていなかったような気がします。

1. はい、人々は時間を無駄にしたくありません。 GDScriptの完全な仕様：いくつかの画面。 C＃を説明する本：通常、少なくとも500ページ。 私はGDScriptの学習に数日を費やしましたが、私が知らない機能が1つもないことは間違いありません。 私はプロとして、そして余暇にC＃で何年も（Window Forms、WPF、XNA、Unityを使用して）作業してきましたが、まだ完全には理解していない機能を使用するコードスニペットを見つけています。 時間の無駄が少ないという理由でC＃を要求することは、実際には意味がありません。
2. 「初心者は、使用するコードスニペットが記述されている言語を学習することになります」-ポイント1を参照してください。コードスニペットからC＃を学習できるという考えは、真実からはほど遠いものです。 その方法で学ぶことができることは非常に基本的なことなので、別の言語を「学ぶ」のに数日以上かかることはありません。 あなたはGDScriptをそのように学んだと自分自身に言いました。
3. 「C＃はGodotをこのインディー開発エコシステムの一部にします」。 そして、それはどういう意味ですか？
   C＃-GodotでUnityコードスニペットを使用できますか？ いいえ。
   UnityアセットをC＃-Godotで再利用できますか？ いいえ。
   Unityチュートリアルを読んで、C＃-Godotに一語一語適用していただけませんか？ いいえ。
   では、あなたが言及しているこの「インディー開発エコシステム」とは何ですか？

paper-pauperが言ったように、選択できるエンジンとライブラリはたくさんあります。
Unityのようなコンポーネントシステムが必要ですか？ アトミックゲームエンジンを見てください。
エンジンでC＃を使い続けたいが、コンポーネントシステムを捨てたいですか？ CryEngine / Luberyardを見てください。
C＃を使い続けたいが、エンジンを捨てたいですか？ MonoGameを見てください。

コードスニペットを見てGodotでスクリプトを学んだと自分自身に言ったので、GodotにC＃を追加することが初心者を助けるという考えは誤りです。 それがエンジンの操作方法を学ぶ方法である場合、何千もの異なるユースケース向けに設計された言語ではなく、エンジンがどのように機能するかを暗黙的に伝える言語が必要ではないでしょうか。

ここに2セントを追加します。 私にとって、C＃の大きな利点はパフォーマンスですが、C ++よりも操作が簡単です。 GDScriptは動的に型付けされており、すべてが非常に高速に記述されますが、実行が超高速になることは決してありません（ただし、かなり最適化される可能性がありますが、これは計画されています）。 C ++モジュールは非常に高速ですが、操作が面倒です。 C ++は必ずしも使いやすい言語ではなく、それらを使用するためにエンジンを再コンパイルする必要があることは、実際には最適ではありません。 私にとって、C＃は一種の妥協案です。GDScriptよりもはるかに高速であり、適切なサポートがあれば、C ++モジュールよりもはるかに簡単に操作できます。

あなたが言及したC ++で言及したすべての問題は有効であり、＃3936を介して修正できます。 これについてはすでに何度も説明しましたが、わかりやすくするために、客観的に認識できるGDScriptの問題を以下に示します。

1. サードパーティライブラリのサポートが不十分
2. 業績不振

C ++でパーツを記述できると、両方を簡単に修正できます。 C＃（または別の言語）でもこれらは修正されますが、ランタイムが追加され、パフォーマンスとクロスプラットフォームのサポートが低下し、多くの追加作業が必要になります（GodotはすでにC ++で記述されています）。 したがって、合理的な選択は、すでに存在するもの（C ++）を使用してそれを改善し、もちろんGDScriptでこれらの問題を修正することです。

このスレッドをすぐに読んで、GDScriptからCへの移行が想定されていることを確認しました。

これを選択した場合は、 tcc Cコンパイラをエディタに埋め込んで、生成されたCをコンパイルすることを検討することをお勧めします。コンパイル時間は非常に速く、非常に小さく、簡単に埋め込むことができます。 多分これは物事をスピードアップするための最良の方法でしょう。

TCCは、GNU劣等一般公衆利用許諾契約書に基づいて配布されています。

（ソース）

これにより、Godotに含めるのはおそらく不適切になります。 また、もう維持されていないようです。

@Warlaanあまり考える必要はありません。 この時点で、私たちは皆、すでに約10回同じことを言っていました。私たちは、私たち全員が立っていることをほぼ知っていると思います。 私は開発者ではなく、エンジンの裏返しもよくわからないので、2セントといくつかのアイデアを除けば、貢献することはあまりありません。 よく知っている人に話させます。 私は自分のサポートを表明したかっただけで、それだけです。
オフトピック：
しかし、あなたがコメントを編集しなければならなかったことについてあなたが大騒ぎしたポイント2に関してはそうです。 それで、あなたは例に基づいて言語を学ぶことができないと言っているのですか？ C＃がそれを拒否する理由1を言うことで知られている500ページのマニュアルを読まない限り、人々はそれを学ぶことができないと思います。 さて、私はあなたが間違っているという生きた証拠です。 GDScriptをどのように学んだと思いますか？ APIとデモの例を使用して、質問をします。 始める前はPythonの知識がなかったので、それに関するすべてはかなり異質なものでした。 ちなみに、libGDXのマニュアルを購入する人は何人いるのか、実際に「libGDXでXを実行する方法」をグーグルで検索する人は何人いるのだろうか。 そして、それで私は当分の間終わりました。なぜなら私はこれ以上何も言うことができませんでした。

（ @Calinou ：BellardはTCCのフォークをBSDまたはMITにすることを許可しました。しかし、前回チェックしたとき、フォークの開発者はソースコードをリリースしていませんでした。したがって、BellardはGodotコミュニティにTCCの再ライセンスを許可することを受け入れるでしょう？）

TCCがコンパイラーとしてGCCやClangと同じくらい優れているかどうかはわかりません。それらのサイズは、多くのアーキテクチャーとかなり最適化されたコード生成（パフォーマンスの向上）をサポートするのに相当します。

オプションでCをコンパイルするためにGCCまたはClangのいずれかに依存するGodotはどうですか？ それらはとにかくゲームを構築するほとんどの人のマシンにインストールされ（サイズは実際には問題ではありません）、Cにコンパイルされる他の言語（ Chickenなど）がそれを行う方法です。 また、必要になった場合に備えて、C ++もサポートしています。

オプションの依存関係になっている場合、GCCまたはClangがインストールされていない人（配布用のゲームを作成することになっている開発者にとっては奇妙ですが、とにかく）は、現在のGDScriptインタープリターをそのまま使用できます。

GDScriptのJITとしてTCCを使用することを提案しました。 したがって、最も重要な機能はコンパイル速度でした。 そして、結果はすでに現在のソリューションよりもはるかに速い可能性があると思います。

ほとんどの人は、パフォーマンスのためにC / C ++を、書き込みをより簡単かつ高速にするためにLua / Javascriptを望んでいます。それでは、両方の長所を活用してみませんか？

Nim- http：//nim-lang.org/

Cのように効率的で、Pythonのように表現力があり、Lispのように柔軟です。

長所：

• C、C ++、Obj-C、またはJSにコンパイルします（http://nim-lang.org/docs/backends.html）
• （Python / Pascal）like（https://learnxinyminutes.com/docs/nim/）
• GCまたはマニュアル（http://nim-lang.org/docs/gc.html）
• godot以外の場所で使用できます
• クロスプラットフォーム（Windows、Linux、OSX、モバイル）
• CコードをNimに変換するのに役立ちます
• Cライブラリをサポート
• 微調整可能なコンパイラ
• MITライセンス
• オープンソース
• タイプセーフ

短所：

• 開発者のコ​​ンピューターにC / C ++コンパイラーが必要-> gcc 、 vcc 、 llvm_gcc 、 icc 、 clangまたはucc _（私の意見では、実際には短所ではありません）_
• 小さなコミュニティ
• まだ1.0ではありません

NimのTODOリストは小さく、1.0に近いです。
https://github.com/nim-lang/Nim/blob/devel/todo.txt

paper-pauperが言ったように（開発者のコ​​ンピューターにコンパイラーを持っていることについて）：

それらはとにかくゲームを構築するほとんどの人のマシンにインストールされます
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-for-C-programmers
https://github.com/nim-lang/Nim/wiki/Nim-for-Python-Programmers

これは私のお気に入りのソリューションではありませんが、その道を進む必要がある場合は、Nimの代わりにHaxe（ haxe.org ）を使用することを強くお勧めします。

Haxeのライセンスについてコメントすることはできません（コンパイラ自体は「GPLv2 +」を使用しており、標準ライブラリはMITを使用しています）が、他のすべての要因により、Haxeは優れた選択肢となっています。
Nimがまだバージョン1.0でさえないのとは対照的に、これはテスト済みのプラットフォーム（現在はバージョン3.2.1）ですが、構文が他のよく知られた言語にはるかに近いことが私にとってはるかに重要です。 Nimの例を読むと、その言語の背後にいる開発者は、変わった、および/または醜い解決策を見つけようとしたようです。

しかし、私が言ったように、それは私のお気に入りの解決策ではありません、そしてここに理由があります：
NimやHaxeのような中間言語には、多くの「意味的な依存関係」があります。 存在する必要のあるライブラリや実行可能ファイルへの依存関係を意味するのではなく、他の言語に関連していることを意味します。 さて、前に言ったように、言語はもはやツールではなく、文化です。 そして、それらをツールとしてのみ見たとしても、それらはそれらが構築された異なるコアドメインを持っています。 たとえば、コマンド「echo」が標準入力で入力されたときにテキストを標準出力に出力することは完全に理にかなっています。 バッチスクリプトで同じコマンドを使用することは重要です。 その論理に従うと、PHPが同じコマンドを使用することは理解できます。 基本的に他のすべての汎用言語には、名前に「write」または「print」が含まれるものと呼ばれるメソッドがあるため、Nimのような汎用言語で使用しても意味がありません。
Nimがそのコマンドの名前として「echo」を使用する理由はわかりませんが、これはHaxeでよく観察できる種類のことであり、最初のリリースにまだ含まれていない場合は、将来Nimに期待するものです。 。 たとえば、Haxeの標準ライブラリには、substr（int、int）-メソッドとsubstring（int、int）-メソッドの両方が含まれています。 2つのうちの1つは、最初のインデックスから2番目のインデックスまでの部分文字列を返し、もう1つは、2番目の引数の長さを持つ最初のインデックスからの部分文字列を返します。 両方が存在する理由は、言語を使用してさまざまな種類の言語を置き換えることができるため、さまざまなプラットフォームからのユーザーがいることと、そのオープンソースライブラリに何を入れるか、何を入れないかを決定する非常に強い手を持つ人がいない限りです。あなたは簡単にそのようなコーディングスタイルの混合に終わるでしょう。

適切な仕事のために適切なツールを選ぶことは非常に重要です。 Haxe（またはC＃）のような言語は、すべてに適合する1つの言語を提供しようとするため、多くの場合、残念ながらこのように見える「1つのツール」を使用することになります。

しばらくGodotと仕事をした後、2セントを追加したいと思います。
私が見たいのは（そして、これまでも見てきましたが、成功は限られています）、Godotのファーストクラスの言語としてのC ++です。
C ++で計算量の多いロジック（衝突解決、物理学、変換、AI）を記述し、GDScript（トリガー、条件、アニメーション、サウンド）を使用してノードをスクリプト化します。

GDScriptは習得が非常に簡単で、その点でGodotをUnityよりもGamemakerに少し近づけています。
しかし、3つの小さなゲームを作成し、たくさんのデモをいじった後、GDScriptには非常に基本的なゲーム以外のものが不足していると言わざるを得ません。

コードファイルが長くなりすぎて、コードエディタには、スコープの折りたたみ、領域、現在のスコープの開始/終了へのジャンプなど、他のIDEにある多くの便利な機能がありません。

GDScriptには、手続き型言語の多くの基本機能もありません。たとえば、適切な_ for _ループ、適切な_ do ... while _ループ（_ while _ループをサポート）、_ switch ... case _、_三項演算子_ 、_列挙型_。
_クラスとシーンの関係の認識はありません_したがって、事前に構築されていない場合は「外部」クラスであり、事前にロードする必要があります。

また、GDScriptの性質上、関数参照やテンプレートはありません。
それは目を見張るようなものではありませんが、非常に迷惑です。

Eye776; GDscriptは、_get_overlapping_bodies（）_のような関数だけに固執するのではなく、他の機能（可能な場合はノードやコールバックの使用など）を無視することにした場合にのみ、単純なゲーム以上に使用できません。

その理由は、前述のコールバックとノードの使用は、1つの大きなスクリプトとごく少数のノードですべてを実行しようとするよりもはるかに高速であるためです。 ツリーは大きくなりますが、Godotのシーンインスタンス化システムでは問題になりません。

たとえば、一定の回転速度が必要なオブジェクトは、GDscriptを使用して手動で回転を設定する代わりに、そのためのアニメーションを使用できます。タイミングに依存するものは、タイマーノードなどを使用できます。 より高速なゲームを可能にするための1つの即時の（そして簡単な）方法は、より多くのノードタイプから選択することだと思います（それぞれが独自のコールバックと接続を持っています）。

コードファイルが長くなりすぎる

このようなスクリプトを意味しますか？ https://github.com/Algorithmus/CastlevaniaClone/blob/master/game/players/player.gd
C＃でこれを防ぐことができると思いますか？ 個人的にはしません。 実際には、ツール（C＃を意味する場合、暗黙的にVSを意味することが多い）と静的型付けにより、これらの長いスクリプトの早い段階でリファクタリングとエラーの検出が容易になりますが、ノードパスエラーはゲームが実行されるまで検出できません。 ただし、それとは別に、ノードの優れた設計と使用により、スクリプトを大幅に簡素化できます。

コードエディタには、スコープ、リージョンの折りたたみ、現在のスコープの開始/終了へのジャンプなど、他のIDEにある多くの便利な機能がありません。

これらは将来追加することができますが、外部エディターを問題なく使用できますが（https://atom.io/packages/lang-gdscript）、Godotにはオートコンプリートサービスもあります。

実際に巨大なゲームを作成する場合は、C ++を使用してGodotを拡張することをお勧めします。
実際、これはエンジンの再構築プロセスのために現在少し気が遠くなると思いますが、それには理由があります。

クラスシーンの人間関係の認識はありません

どう言う意味ですか？ シーンのルートにスクリプトを配置できることをご存知ですか？ また、C＃エディターは、それらが使用されているシーンに何があるかを推測できませんが、GDScriptは推測できます。

また、GDScriptの性質上、関数参照やテンプレートはありません。

ラムダやイベントに似たものを探す場合はfuncrefとsignalがあり、言語は動的であるため、テンプレートは重要ではありません。 動的言語は、インターフェースやジェネリックの代わりにダックタイピングを使用することを好むことがよくあります。 また、再利用可能なものが必要な場合は、継承に対するコンポジションが非常にうまく機能します。

GDScriptには、手続き型言語の基本的な機能も多くありません。

少し同意します。 それらのいくつかは要求されましたが、私は問題を覚えていません、あなたは検索しなければならないでしょう。 たとえば、整数の範囲とコンテナ（float？）以外のもので反復できるforを見たいので、 whileを使用します。 それは確かに少し厄介ですが、それほど深刻なことではありません。

このようなスクリプトを意味しますか？ https://github.com/Algorithmus/CastlevaniaClone/blob/master/game/players/player.gd

ファイルが長い場合でも、私ははるかに悪い状況を経験しており、コードがかなり手続き型であるにもかかわらず、それでもかなり読みやすいと言わざるを得ません。 これで、GDScriptに単純な構文が適している理由がついにわかりました。これは、ほとんどがifと関数呼び出しである平均的なゲームロジックに最適です。

C＃で書かれた同じファイルは、読み取りや書き込みが簡単であるか、パフォーマンス以外の実用的な利点がある（とにかくC ++よりも悪い）と誰もが主張することを望んでいます。 C＃は、この種のスクリプトではやり過ぎだと思います。これは、一部のプロの2Dゲームで使用されるスクリプトよりも複雑です。

少し同意します。 それらのいくつかは要求されましたが、私は問題を覚えていません、あなたは検索しなければならないでしょう。 たとえば、整数範囲とコンテナ（float？）以外のもので反復できるforを確認したいので、whileを使用します。 それは確かに少し厄介ですが、それほど深刻なことではありません。

forの部分と、疑似GDScriptで参照しているものの例についてもう少し詳しく説明していただけますか？

@ paper-pauper GDScriptに欠けているものはC＃とは関係ありませんが、たとえばfor i in range(-PI, PI)はGDScriptやfor i=0, i < size and stuff, ++iでは機能しません。 また、3行のifを書く代わりに、三元を書きたいと思います。 しかし、私が言ったように、トラッカーにはすでに問題があり、GDScriptの使用を止めることはできません：p

ただし、すべてのスクリプトが最大200行で、比較的適切に設計されている場合でも、ゲームに数千のスクリプトがあると、そのコードベースの維持とリファクタリングに問題が発生します。これは言語のせいではありませんが、ツールのおかげで：C＃の人気の大部分は、VisualStudioがそのための優れたIDEの地獄であるためです。 Godotが適切なツール（goto定義、信頼できるクラス/関数/メンバーの名前変更、すべての参照の検索など）を統合すれば、巨大なGDScriptコードベースでの作業がはるかに簡単になると確信しています。 より一般的に言えば、これは私がGodotで見たいものです。これまでのところ、（自分のプロジェクトを含めて）何も表示されなかったため、BIGゲームでどのようにうまくスケーリングできるでしょうか。

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

Godotが見逃しているのはツーリングであることに同意します。 主な問題は、GDScriptのダックタイピングの性質です。これにより、何が何であるかを知ることが難しくなり、「参照の検索」や「定義への移動」などのアクションを実行することが困難になります。

GDScriptにタイプヒントを追加する予定ですが、これはオプションであるため、どれだけ改善できるかわかりません。 それは確かにコードの完成に大いに役立ち、より良いツールの作業を容易にするかもしれません。

@vnen （M）ELPAのGDScriptのEMACSモードは、私の本ではすでに正しい方向への一歩です:)

そうそう、これらの2つの問題をほとんど忘れてしまいました。これは、おかしなことに、実際に私を遅くしました。

• 引数は関数のシグネチャの一部ではありません。 つまり、関数をオーバーライドすることはできません。
  実際には、同じクラスにfunction doFoo(a,b,c,d)とfunction doFoo(a,b)があると、コンパイルに失敗します。 最終的に、名前をdoFoo4(a,b,c,d)とdoFoo2(a,b)に変更し、多数のスクリプトファイルをリファクタリングしました。
• 列挙型はサポートされていないため、すべてのフラグと戻りコードは必然的にintであるため、推測する必要があり、多くは現在も文書化されていません。

PS：明らかに、関数は文字通りdoFooという名前ではありませんでした。 ;）

編集：@ Ace-Dragon：他のエンジンは、複雑な組み込みノード/コンポーネントなどを教えてくれました。 変化する可能性があり、変化し、その過程でゲームを壊します。 そのため、基本的なトリガーコールバック（衝突、値、タイマー）以外は、それらに過度に依存することは避けたいと思います。
また、私は信号スロットパラダイムの大ファンではないので、可能であればそれを避ける傾向があります。 それからまた、私はコルーチンよりもスレッドを好みます、私をラッダイトと呼んでください:)

@Zylann ：〜1200 LOC？... pffftいいえ、実際の取引について話しています...ファイルあたり20k以上のLOC。 Unityを使用するRPG開発者は、名前が付けられていないままであり（私は彼らのために働いていません）、通常、25k以上のlocを持つクラスを持っています。 次に、すべての関数を静的にし、C＃をCであるかのように使用します。：fearful：

話題から外れてすみません。

@ eye776オーバーライドを許可する動的言語は考えられませんが（場合によってはデフォルトの引数で偽造される可能性があります）、GDScriptに含めることをお勧めします。

また、エンジンに対するゲームを壊すような変更は、Godotのようなlibreプログラムで簡単に検出して元に戻すことができるため、心配する必要はありません。

@ eye776また、関数をオーバーライドする動的言語を見たことがありません。 GDScriptにはデフォルトのパラメータがあるため、代わりに使用できます。

また、1つのファイルで20K以上のLOCを実行しているクレイジーな人は誰ですか？ ここでの問題はツールにありません... Godotのソース全体で、10KLOCで見つけることができるファイルは1つもありません。

私が同意するのは、C ++にもう少し愛を与えることです。 しかし、先に引用した用途については、AIにのみ同意します。 また、手続き型生成、もう1つ引用します。 エンジンの物理演算やレンダリングなどを作り直している場合は、Godotをもう使用していないと言いますが、フォークを実行しただけです。 組み込みのタイプに頼ることができない場合、エンジンは何のために必要ですか？

もちろん、GDScriptは完璧ではありません（言語は完璧ではありません）。 また、石に刻まれていません。 列挙型、switch / case、および三項演算は、将来追加される可能性があります（これらについては、すでに未解決の問題があります）。 今何かがないからといって、決して持っていないという意味ではありません。

最後に、「疑い」は実際には役に立ちません。 必要なのはベンチマークとユースケースです。 GDScriptで書かれた非常に複雑なゲームがすでにあるので、本当に欠けているものはわかりません。

@vnen楽しみのために： godot/drivers/gles2/rasterizer_gles2.cppは11K LOC：pです（これは私が見つけた中で最大ですが、まれな例外です）。

@vnen

組み込みのタイプに頼ることができない場合、エンジンは何のために必要ですか？
さて、初心者のための質の高いクロスプラットフォームコンテキストとして。 しかし、それは私が自分のスプライトやモデルクラスを書くという意味ではありません。

Godotは3月に一度私を燃やしました（v2.0.1）。 私はサードパーソンのカメラとキャラクターをいじっていて、Godot自身の物理学を使って動き（ドラッグとフォース）を試み、それを機能させました。
次のマイナーバージョン（v 2.0.2）のアップデートは、基本的にまったく同じ値でキャラクターの速度（2〜3倍高速）を壊しました。
それをキネマティックに保ち、私自身の「物理学」を行う方が良いと考えました。

また、Godotとは関係なく、XCodeのストーリーボードのような自動化されたものに頼って何度もやけどを負いました。
私はちょっと光沢のあるものに夢中になるのをやめ、私の後ろにあるIDEによって自動生成されたコードが私のものを台無しにしないように祈っています。

とにかく、スレッドを狂わせて本当にすみません。

@ eye776 2.0.1から2.0.2までのコミット差分をチェックして、ゲームを壊したものを確認しましたか？ それはバグであった可能性があり、それを報告することはコミュニティ全体に利益をもたらす可能性があります。

モノまたはCoreCLR？ なぜ？

単核症：

• MITライセンス
• 安定
• 放棄される可能性
• 良いドキュメント

CoreCLR：

• MITライセンス
• まだ1.0ではありません（現在はRC2です）
• 小さい
• 貧弱なドキュメント

モバイルとウェブに展開するため、Monoを使用しています。 ここにあると思います
持ち運びに便利なため、放棄される可能性はありません。 私の予感
両方のコードベースが最終的にマージされるということです。

2016年8月4日木曜日午後1時45分、Hubert [email protected]
書きました：

モノまたはCoreCLR？ なぜ？

単核症：

• MITライセンス
• 安定
• 放棄される可能性
• 良いドキュメント

CoreCLR：

• MITライセンス
• まだ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です）

6月14日に1.0安定に達しました。

モノ：放棄される可能性

何に基づいて？

モノ：良いドキュメント

ああああああ

何に基づいて？

マイクロソフトが.NETの3つのスタックを開発するのはなぜですか？ リソース的には良くありません。 （.NET Framework、Mono、.NET Core）

ああああああ

C ++ / C＃相互運用機能（godotに必要なもの）に関する両方のドキュメントを確認しましたが、Monoで文書化されていても問題ありません。 coreCLRでは、コードの一部を掘り下げて、アプリを機能させるために開発者に支援を求める必要がありました。

リファレンスガイドには、文書化されていない、壊れたリンクの機能が多すぎます...

理論的にはここで偏見があります...しかし、私の議論が客観的であることを願っています...

• Mono開発の低下は見られません： https ：
• WindowsでのMonoの開発は、今日ほど強力ではありませんでした（ちょっとした証拠（大量のコミットをリンクせずに）https://github.com/mono/mono/pull/3231 Miguelが「今は本当のメンテナーがいるので」と言っています）前のポイントがさらに明確に
• MonoへのAPIの埋め込みは、バトルテスト済みです（Unityだけでなく他の多くのプライベートユーザーもいます）
• Mono TODAYは、PS4、Android、Windows、iOS BITCODE （長年の作業がこれに

だから私見、これを近い将来（3年未満）そしてほとんどのゲームプラットフォームで提供したいのなら... Monoを使ってください。

こんにちは、

いくつかのコメント：

• David Karlasによってリストされたプラットフォームに加えて、WebAssembly、XboxOne、UWP、およびWin64ネイティブサポートも追加しています。
• 共有されているサンプルは、仮想メソッド（より高速なディスパッチ）を使用して実行することも、C＃イベントを使用して実行することもできます。
• C＃は歴史的に多くの言語革新の最前線にあり、あらゆる場所から優れたアイデアを引き出してきました。 イテレータ、消去されていないジェネリック、ラムダ、非同期プログラミング、プロパティ、プラットフォーム呼び出しなど、言語研究からの多くのアイデアが普及し、マスマーケットにもたらされましたが、これは言語の1つです。公共の場で最も活発に
• 一般に、Unityは古いランタイムを使用しているため、最新のC＃を紹介していません。 これはうまくいけばすぐに変わるでしょう。 とは言うものの、現在のMonoは、ゲームコードに理想的な「非同期」プログラミングの中でも、線形に記述できるため、すべての新しいC＃機能をサポートし、コンパイラーはコードをコルーチンや高度なものなどのステートマシンとして自動的に書き換えます。 Unityで使用される「yield」のバージョン。
• 同期コンテキストとは、特定のコンテキスト内で実行される非同期コードを記述できることを意味します。 たとえば、ゲームバウンド実行、IOバウンド実行、またはメインスレッドとバックグラウンドスレッドバウンドの実行がある場合、それはすべてシステムの一部です。
• デプロイ中は、JITコンパイル、またはLLVMの有無にかかわらず静的コンパイル（AOT）を選択できるため、C＃が配列境界チェックを実行するという事実を法として、C ++で可能な限り高速になります（つまり、ネイティブを使用する場合バッファ、安全性を犠牲にして、パフォーマンスを取り戻します）
• 過去数年間、Monoはモバイルに重点を置いているため、MonoのGCはサーバーではなく、インタラクティブなワークロード向けに調整されてきました。 私たちの新しいGCは世代を超えており、非常に迅速に収集でき、ヒープ全体をスキャンする必要がない小さな苗床を備えています。

Microsoftが複数のCLRを開発している理由（JITワークロード用のCoreCLR、UWPでの静的コンパイル用のCoreRTファミリー、モバイルワークロード用のMono）は、すべてサーバーの目的がわずかに異なるためです。 内部は可能な限り収束しています。たとえば、Monoはコアコードの約60％を、残りの.NETと直接共有されるコードに置き換えました。 どのワークロードが自分に適しているかを見つけるのは問題です。

今日は1つのVMから始めて、将来は別のVMに切り替えることができます。 現在、Monoはより大きなAPIサーフェスを備えており、モバイルで動作し、インタラクティブなワークロード用に最適化されており、より多くのアーキテクチャ（ARM64など）をサポートしています。

幸いなことに、あるVMを別のVMに交換したり、両方をサポートしたりするのは数日分の作業であるため、特定の実装に縛られることはありません。

@migueldeicazaようこそ！ あなたが私たちの議論に参加することを決めたこと、そしてあなたがGodotに興味を持っていることを素晴らしいです：+1：あなたがしばらく私たちと一緒にいることを願っています:)

素敵な内訳@migueldeicazaをありがとう！ あなたや他のMono開発者に2つの簡単な質問があります。

1）Visual Studioを使用してWindowsで組み込みMonoをデバッグするための現在の設定は何ですか？ Unityにはプラグインがありますが、Linux / OSXマシンに接続するプラグイン以外は見つかりませんでした。

2）ランタイムの再コンパイル（エディターでのゲームプレイまたはツールプラグインのアセンブリなどのコンパイル、アンロード、およびリロード）を処理するための推奨される方法は何ですか？ 残念ながら、C＃はAssembly.Unload（）メソッドを公開しておらず、AppDomainsとクロスAppDomainの問題を処理することはこの状況では非常に煩わしいようです。

参考までに、UnityがMono（ Urho3DエンジンのC＃/ Monoバインディング）を使用しているだけでなく、MITライセンスを使用しているため、ソリューションを簡単に検索できます。

私の2セント：

C＃は、カスタム値型をサポートするという点で、他の同様のレベルの言語よりもゲームプログラミングにはるかに優れています。 これはパフォーマンスにとって非常に重要な機能であり、Java（および一般的にはJVM）には文字通りそれに代わるものがありません。

あなたが得る：

• スタック割り当ての数学タイプ。ヒープ割り当てなしで数学演算と一時オブジェクトをサポートします。
• 最適化された、キャッシュに適した継続的なコレクション。
• 値型（プリミティブ型を含む）を使用するジェネリック

その上、C＃にはあなたの生活を楽にする他の機能があります。 _game_プログラミングで重要なほとんどすべての点でC＃がJavaに勝るだけの場合、C＃の代わりにJavaを使用するメリットはありません。

こんにちは、みんな、
私は上記のすべてを読んだことがありません（単に多すぎます:)）
しかし、私はいくつかの休日を過ごしたので、msDotNetHostとして機能するgodotのプロトタイプモジュールを作成しました。それで、私はいくつかの調査結果を提供するかもしれません。 悲しいことに、私の休日は終わり、お金のために再びコードを書くことにしました:)、しかしそれは/楽しかったです:)

現在の状態は次のとおりです。
o）モジュールはノードクラスを拡張して、ノードイベントをnetCodeに公開します
（init、tree_entered、ready、process、fixedprocess ....））、
o）「ネットホスト/ラッパーモジュール」が完了しました（Microsoft dotNetホストメカニズムを使用）
ダイナミックライブラリにカプセル化されているため、後でMonoに簡単に切り替えることができます。
o）dotNetメソッドがバインドされ、呼び出されます（init、tree_entered、ready、process、fixedprocess ....）
o）ノードクラスがラップされてnetAssemblyにバインドされます（プロトタイピング用に手動で記述されたコード）
o）（netCodeからの）godotへの呼び出しは、自己記述のバインディングメカニズムを介して機能しています
（dllからgodot-exeに）したがって、exeは関数をエクスポートする必要はありません。
o）msDotNetを使用しているため、近い将来、ウィンドウにバインドされます。

.Netを含めるための私のロードマップは次のようになります。

1. microsoft .Netホスティングメカニズムを使用したGodotのモジュール（完了）
2. wrappin godotClasses
   （私の現在の状態：godot c ++コードを解析するラッパージェネレーターを作成しています。
   解析が行われ、生成が進行中）
3. プロジェクトをプロトタイプ状態から外します（エッジを完成させ、テストします...）
4. Windowsの結合を取り除くために、Monoホスティングメカニズムを作成します
5. どういうわけか、Visual Studioがmonoをデバッグできるようにして、xamarin / monodevを削除します（unity vs-pluginなど）
6. 何百人もの新しいgodot.net開発者を楽しんでください:)

いくつかの質問：

1. gdscriptに使用されているバインディングメカニズムを再利用できるのではないかと思います。 しかし、idはそれをすべて評価する時間がありません、それは私にとっていくつかの良いtutまたはいくつかのhighlvlヒントがありますか？

2.2。
現在、すべてのgodotメソッドを関数にラップするラッパーを生成しているため、dll-boundaryおよびc ++ / netCode境界を介して簡単に呼び出すことができます。 （netCodeの自己記述型バインディングメカニズム）
互換性を維持するためにgodotコード（モジュールコードを実行）を変更したくありません。
また、静的、非静的、仮想非仮想は私を泣かせました、それが私がこの方法を選んだ理由です。
これに対するより良い解決策はありますか？

いくつかの追加の考え：

Microsoft .NetとMono：

ほとんどの場合、dotNetコードは両方で変更されずに実行されるため、monoとmsDotNetのどちらを使用するかは問題ではないと思います。 両方をサポートする唯一の取り組みは、各emの「ホスト」（「GodotDotNet」の最小部分）を作成することです。 私はプロトタイピングにmsDotNetを選びました。
まあ、monoは多くのプラットフォームmsDotNetのみのウィンドウをサポートしているのに、なぜmsDotNetをサポート/使用するのですか？
答え：生産性、デバッグ

msDotNet：
特に、DotNetModuleを作成/プロトタイピングする場合、高速コンパイルとデバッグスルーが必要/必要です。つまり、デバッガーはc ++からnetCodeにジャンプする必要があります。その逆も同様です。
両方をデバッグできるので、VisualStudioを選択します。 ただし、msDotNetを使用する場合のみ。
そうすることで、netCodeの一部を変更し、runを押して1sekで実行します。 そのコンパイルされ、実行されています!!! godotにデバッグする可能性を含みます。 （godotで何かを変更していない場合は、通常30sekから1分待つ必要があります...くそー遅いscons！:)）

単核症：
モノは最終的なターゲットでなければなりませんが、それについての議論はありません（プラットフォームの独立性）。
モノを使用する場合、デバッグに関しては大きな問題があります。モノには独自のデバッグメカニズムがあります。
私にとっては、生産性に大きな打撃を与えました。なぜなら、visualstudio用のmonodebug-pluginを作成しない限り（ユニティがこれを行った場合）、Visual Studioでモノホストされたネットコードをデバッグしたり、c ++コードにデバッグしたりすることはできません（ハックソリューションはありますが...）。
私はMonoベースのソリューションをセットアップしようとしましたが、VisualStudio（c ++用）とxamarin / monodev（ネットコード）の両方を並行して使用することになりました。

結論：
プロトタイプの状態：msDotNet
後で：mono、godot / c ++およびプラットフォームに依存しないようにデバッグすることに関心のないユーザー向け
その後：モノをデバッグするためのvsプラグインを作成します

c＃vs java：
答えは明確ですc＃！ javaはscritpkids用です！ （ああ、c ++コーダーはc＃devsについてどう思いますか:)）
いいえ、これは冗談でした:)
議論がわかりません.... netシステムが実装されている場合、両方の言語に加えて、dotNetをサポートするすべての言語を使用できます。
これは、Javaシステムがサポートされている場合には当てはまりません...

@Ziflin ：
質問1：
その検索も行いました... monoRemotedebuggerだけが（ではなく）ソリューションatmです:(
上記のように、私の推奨事項は、プロトタイピングにmicrosoftsdotNetホスティングを使用することです。
その後、ある時点でモノラルに切り替えます。
別：
xamarinをハッキングモードで起動し、ローカルホストをリッスンさせ、ブレークポイントを設定してから、urプロジェクトをvs. iveでテストしましたが、動作しますが...
私にとっては解決策はありません！ 「ヒットランとデバッグを1秒で」-メカニズムとこれを1クリックで実行したい！
余暇はあまりないので、生産性を第一に考えています。

質問2：
モノはまだよくわかりませんが、c ++でそれを実行し、モノホスティングを実装し、c ++の「外部」から管理する必要があると思います。

@CharlesWoodhillの公式C＃バインディングはすでにWIPであり、ここで確認できますhttps://github.com/neikeq/GodotSharp/

クールなtnx、それから私は私の次の休日のいくつかをどのように過ごすかを知っています;）

こんにちは、godotSharpに出くわしましたが、これは削除されました。

これは落とされました。

IRCで聞いた公式バージョンは次のようなものでした。

@neikeqは未完成のコードをプッシュするのが好きではないので、ローカルブランチで作業します

知っておくと良いことですが、私は自分のモジュールをやろうとしていましたが、Godot2.2または3.0の方がいいと思います

2.2のリリースはありません。Godotの開発者は、2.2のすべての機能を3.0に移行しました。

コメントは初めてです。 Unityからやって来て、GDscriptへの移行は夢でした。 私は1日足らずでその言語を習得しました。 言語がエンジンにどれだけうまく実装されているかが大好きで、生産性が大幅に向上しました。

私の主な懸念は、C＃のサポートが追加されると、Unity開発者が殺到した後、GDscriptが取り残されるか、開発が少なくなることです。 C＃はすばらしい言語ですが、私の個人的なお気に入りではありません

また、Godotが自立するのではなく、別のエンジンのようになろうとしているのを見るのも心配です。 Unityは素晴らしいサクセスストーリーですが、私が今まで使用した中で最高のエンジンではありません。 それは肥大化していてバグだらけです。 プロジェクト全体が確認なしに削除された後。 バグや本来のように機能しないものに対処することは、絶え間ない苦労でした。 うまくいかなかったので、作業中のシーンを完全に再構築しなければならなかった回数は数えられません。 私はかつて、古いバギーシーンから新しいシーンにすべてのコンテンツをコピーして貼り付け、両方のシーンが同一であるにもかかわらず、突然機能するようにしました。 魔法のように現れたり消えたりする物理学のバグを探して何週間も失いました。

Godotが無駄がなく、理解しやすいのが本当に好きです。 Godotでの作業は、よく調整された楽器を使用するようなものです。 ほぼ1年間そこで働いた後、私は以前にそれをやったことがなくても、私がする必要があることを何でもする方法を知っています。 Unityユーザーの流入によって、エンジンの方向がUnityに向けられないことを願っています。 Unityが必要な場合は、Unityを使用します。

@zaywolfeあなたの懸念は他のユーザーから数回表明されています。 心配することは何もありません。 GDScriptは、Godotの主要言語であり続けます。

GDScriptは好きではありません。 Pythonをモデルにしていることは理解していますが、非常に貧弱です。 私の意見では、C ++またはJavaが（箱から出して）含まれているのは素晴らしいアイデアです。 私は個人的に、開発でGDScriptを使用することにうんざりしていて、新しい（または代替の）言語が実装されたときにGodotを離れて、また戻ってくるかどうかを疑問視しています。 申し訳ありませんが、プログラマーからの難しい事実が必要な場合は、それらを入手してください。

また、単純なソフトウェアプロトタイピングにGodotを使用することもあります。 したがって、深く統合されたプログラミング言語は、エンジン内のソフトウェア開発への扉を開く可能性があります。 それは本当にUnityキラーになるでしょう。 （もちろん、JavaまたはC ++が選択された場合）

熱心な開発者の皆さんの努力に感謝します。皆さんを尊敬しています。今後の更新リリースを楽しみにしています。

@VenHayzあなたはゴドーのドキュメントを読んでいる場合、私は知りませんが、あなたはすでにゴドーの最初のバージョン以来、C ++であなたのゲームを書くことができます- http://docs.godotengine.org/en/stable/reference/custom_modules_in_c++.html

microsoft .netコアを使用するのはどうですか？ クロスプラットフォームでパフォーマンスに重点を置いているだけでなく、オープンソースであり、積極的に開発されています

こんにちは、通りすがりのランダムな男

使用しているスクリプト言語が気に入らないため、Godotを使用していないことをお知らせしたいと思います。

JavaまたはC＃を追加する場合は、アナウンスの直後にgodotをインストールして使用します:)

@RUSshyさようなら、それはあなたの損失です、godotは素晴らしいです、GDScriptは素晴らしいです、あなたが本物のプログラマであるならば、プロジェクトを始めるのに十分以上を知るのに文字通り2時間かかります。 本物のプログラマは多くの言語を習得する必要があります。Java/ C＃に固執し、趣味として永遠に通り過ぎる「ランダムな」男になることができます。 私は失礼なことをしようとしているのではなく、ただ事実を述べているだけです。 このエンジンについて何か気に入らない場合は、コードを追加してください。他のほとんどのエンジンとは異なり、無料です。

マーケティングの神はC＃を支持しています。 ：笑い：

@ RebelliousX JavaまたはC＃を選択すると、使用するライブラリのロードが手元にあることを意味します

自家製のスクリプト言語に制限することはまったく役に立たず、新しい知識は他の場所には適用できず、大量のライブラリを見つけることができず、知識や既存の学習リソースを再利用することもできません。

選択は最近非常識です気にしないでください

@RUSshy冗談でしょ？ 私（および他の何人か）は、C＃に対するGDscriptの利点についての説明のページを文字通り書きましたが、前に言われたことを何も読まなくても、1つの短い段落で議論を解決できると思いますか？

「気にしないでください」-素晴らしいアイデアです。GDscriptについて心を開いて始めるのはどうですか。
「あなたの新しい知識は他の場所には当てはまりません」-それは単に誤りです。 理解していないコードをコピーして貼り付けることで、知識の不足を補うことはできません。
「たくさんのライブラリを見つけることはできません」-スクリプト言語とバックエンド言語の違いを学びましょう。 または-クレイジーなアイデア-私がそれについて書いたことを読んでください。

真剣に、何人かの人々の大胆さ...

C＃統合モジュールが機能しているとさまざまな場所で何度か言われています。 それは人々がそれをしなければならない時間と同じくらい速く進みます。 それをより速くする唯一の方法は、その統合に貢献することです:)

@Warlaanの2番目のポイントについて：以前にC＃で大量のコードを記述した場合、すべてを移植しない限り、それを再利用することはできません。 また、ライブラリを使用するためにライブラリのコードを理解する必要はありません。 重要なのは、以前にC＃にあったもの（単一のファイルまたはライブラリのセット、潜在的にクローズドソース）が必要な場合は、すべてを移植するか、C＃ランタイムを埋め込むか、C実装を見つける必要があるということです。 それは不可能ではありませんが、時間がかかります。
これは、Godotが既存のライブラリを大量に使用できないという意味ではありません... C / C ++にも大量のライブラリがあります。

これは炎上戦争になる危険性があります。
ログは非常に長いため、人々はそれを読む代わりに同じ質問やトピックを繰り返すでしょう。
議論するための技術的なものはあまり残っていません。

スクリプトに関するGodotの将来は、すでにかなり明確です。

• GDScriptは引き続き主要言語であり、それを最適化するための計画やアイデアがあります（ただし、これはそれについて議論するのに適切な場所ではありません）。
• 3.0から、スクリプトの代替としてC＃がサポートされるようになります。 モノラルランタイムがそれを使用しない人々に引き起こされる余分なサイズを強制することを避けるために、別々のバイナリを提供します。
• DLScriptも作業中です。 これにより、人々はスクリプトに共有ライブラリを使用できるようになります。 これらのライブラリは、cリンケージと共有ライブラリをサポートする任意の言語で記述できます（RustやDなどの言語を想定）。 ただし、3.0の準備ができているかどうかはまだ明確ではありません（私が時代遅れでない限り）。
• 3.0にもビジュアルスクリプティングがあることを忘れないでください！

誰かが何か他のものを提供することを計画している場合、これもそれについて議論するのに適切な場所ではありません。

この問題は解決できるし、解決すべきだと思います。

同意しました。

C＃統合ソースコードへのリンクを提供していただけますか？

https://github.com/neikeq/GodotSharp

GodotSharp統合はどのように機能しますか？ テストに使用する準備はできていますか？
godotマスターからのソースビルドで使用できますか？

@nictaylr現在、マスターでビルドしていません。 テストする場合は、2.2レガシーを使用する必要があります。 そのバージョンで非常にうまく機能しています

4月に3.0アルファ版の準備をしています。

ランダムなアイデアですが、GodotでC ++を深く考えた後、おそらくもっと良いものを考えました。 D言語。 これは、 Cおよび（一部の）C ++サポートとのインターフェースを備えた、ほぼ間違いなく「低レベル」の言語割り当てに該当します。 クラスがあり、とてもモダンです。 怖いように聞こえますが、 GDScriptによく似ており、非常に大きなプロジェクトに使用されていることがわかりました。 これは、GDCと呼ばれるコンパイラでCおよびC ++（gcc / g ++）と競合するのに十分強力です。 （DMCを使用してコンパイルすることもできますが、GDCはgccに直接コンパイルされます） GDCの詳細についてはこちらをご覧ください

とにかく、ただの簡単な提案または多分アイデアのために。

@VenHayz私はスクリプト用の共有ライブラリの使用を可能にするモジュールに取り組んでいます。 私はすでにC ++を使いやすくするためにいくらかの努力を払っています。 Dを使用して、これらのライブラリを作成することもできます。 Dバインディングを作成することに興味がある場合は、IRCまたはDiscordにアクセスしてください。

@karroffelそれは本当にクールです。 私はライブラリとAPI（「バインディング」についてのあなたの言及を参照）を書いた経験はありませんが、おそらく1日だけ調べて、それを行うことができます。 私は誇りを持って素早い学習者です。 よろしければ、Discordについてご連絡させていただきます。 私の不和：_hasCat＃3941

@VenHayz私はあなたを追加できません、あなたは他の人があなたを追加することを許可していません。 Karroffel＃8409またはGodotサーバーに参加する

@neikeq GodotSharpリポジトリはGodot3.0のC＃サポートに使用されているコードベースですか？ どの機能が利用可能になるかを大まかに把握しようとしているので、質問します。利用できる場合は、そのコードベースを調べます。 ありがとう！

私はgodotsharpに見えます、時代遅れですか？ 新機能 ？ または、開発ビルドで使用する準備ができていますか？

どうすればソースからgodosarpをコンパイルできますか？

@nictaylr開発ビルドとして2.2レガシーブランチを使用する必要があります。

他の誰かがこれについて言及したかどうかを理解するのに十分読んだと思います。

私は個人的にはまだ学びたくありません-他のどこでも使用できない別の言語。 私は多くの3Dプログラミングを行う予定はなく、あちこちでいくつかのことを行う予定です。

はい、これに対して多くの反論がありますが...それはオープンソースプロジェクトです。 新しいプログラミング言語を提供している人を憎む必要はありません。

キッズパーティーにビールを持ってくることを想像してみてください。 「誰かが新しい飲み物を提供するのを嫌う必要はない」とあなたは言いますか？ C＃を追加すると、GDscriptの開発に悪影響が及ぶ可能性があります。 GDscriptをGodotの主要言語として維持することを誰もが決意していることは知っていますが、新しい機能を追加することには欠点があり、人々が「何が害になるのか」と尋ねる理由が何度か説明されていると、それでも私を悩ませます。

また、「学びたくない」というのは本当にばかげた議論なので、GDscriptの代わりにC＃を要求します。 私がゲーム開発で知っているすべての言語の中で、GDscriptの機能は最も少なく、C＃の機能ははるかに多いです。 学びたくない場合は、GDscriptに感謝する必要があります。

私は本当にこの議論を何度もウォームアップしたくないので、誰かがこのスレッドにコメントしたい場合は、上から読んでください。

また、「学びたくない」というのは本当にばかげた議論なので、GDscriptの代わりにC＃を要求します。

C＃は別の場所で使用できる可能性があるため、学習してもかまいません。

スレッドをロックするだけで、意味がわかります。

このスレッドがその目的を果たしたことは事実です。ロックしましょう。