Godot 4.1 アップデート

 (godotengine.org)
1 ポイント 投稿者 GN⁺ 2023-07-07 | 1件のコメント | WhatsAppで共有
  • Godot 4.1 は 4.0 から 4か月後の段階的リリースで、安定性・性能・完成度を磨きつつ、AIナビゲーション回避や分離型コードエディタのような機能を追加
  • 今回のバージョンでは、Godot 4 の使用中に報告された、または 4.1 プレリリースで見つかった 900件以上の課題を修正し、300人を超える貢献者の提出によって作られた
  • 性能改善では、子ノードの追加・削除を高速なハッシュマップベースに変更した点が大きく、複雑なプロジェクトで高速化する一方、一部のまれな作業と Node のメモリ使用量にはコストが生じる
  • GDScript の静的変数、C# [GlobalClass]、GDExtension 拡張、分離可能なスクリプトエディタなど、スクリプティングとエディタのワークフローが拡張
  • 4.0 プロジェクトの 4.1 への移行は概ね安全だが、C# と GDExtension の利用者は非互換性の可能性と 移植・再コンパイルを先に確認する必要がある

Godot 4.1 リリース概要

  • Godot 4.1 は Godot 4.0 以降 4か月の作業を経て登場したアップデートで、4.0 を頻繁な段階的リリースで改善していく方針を継続
  • 今回のリリースの中心は 安定性、性能、仕上がり品質であり、新機能も含まれる
    • 改良された AI ナビゲーション回避
    • コードエディタを分離して別のディスプレイに配置する機能
  • ユーザーが Godot 4 の使用中に報告した、または 4.1 プレリリースのテストで見つかった 900件以上の課題が修正された
  • 4.0 で作られた大半のゲームとアプリは、4.1 へ比較的安全に移行できる
    • C# と GDExtension の利用者は一部の非互換性を想定すべき
    • 移行前にはバックアップが必要で、Git のようなバージョン管理システムでプロジェクト状態をコミットする方法が推奨される
    • 移行ガイド を準備中
  • Godot 4.1 は ダウンロードページ から入手可能

コミュニティ貢献と開発資金

  • Godot はコミュニティ主導のプロジェクトであり、個人の貢献者たちがエンジン改善に参加している
  • ここ数年、ユーザーや企業からの寄付により一部の中核貢献者を常勤で雇用できるようになり、迅速なリリースが可能になった
  • 現在は月間支出が月間寄付を上回っており、開発資金は依然として大規模な単発の企業寄付に依存している
  • Godot 4 の更新ペースを維持し、さらに多くの貢献をレビューするメンテナを雇うには、月次寄付がさらに必要
  • 金銭的支援以外にも、さまざまな形でプロジェクトに貢献できる
    • 詳細なバグレポートの作成
    • コードベースへの貢献
    • ドキュメント執筆
    • 公式ドキュメントや個人サイトへのガイド執筆
    • コミュニティプラットフォームで質問に答え、ヒントを提供すること
  • 今回のリリースは 300人以上の貢献者の提出によって成り立っており、全体のバグ修正と改善一覧は interactive changelog で確認できる

性能改善

  • Godot のゲームは、ゲームエンティティの基本構成要素である ノードツリーで構成されており、ノードの追加と削除はエンジン内で非常に頻繁に発生する作業である
  • 4.1 では、子ノードの追加・削除アルゴリズムを高速なハッシュマップベースに変更し、この作業を 数倍高速にした
    • まれなノード操作はやや遅くなる
    • 基本 Node クラスのメモリ使用量は 10% 増加する
    • ノード操作が多い複雑なプロジェクトで特に大きな利点がある
  • シーンに対する 実験的マルチスレッディングが追加された
    • 新しいノードプロパティで、ノードの処理方式を逐次または並列に制御できる
    • まだ実験的機能のため、エッジケースを見つけるための広範なテストが必要
    • 本番利用は推奨されない
  • マルチスレッド読み込みでも多くの問題と制約が修正された
  • Vulkan レンダラーには パイプラインキャッシュが追加された
    • 従来のシェーダーキャッシュはシェーダーコンパイル時のスタッターを減らしていたが、パイプラインコンパイルは依然としてスタッターや遅いロード時間の原因になり得た
    • パイプラインコンパイル時のスタッターが完全に解消されたわけではないが、RenderingDevice ベースのレンダリングバックエンドではロード時間がやや短縮される可能性がある
    • このキャッシュはプロジェクト設定で無効化でき、Godot 4.1 ではデフォルトで有効
    • すべての停止要因を解決するものではなく、今後のリリースでも作業が続く

コアエンジンの変更

  • Godot でモデルをインポートする際、モデルが後ろ向きになる問題がよくあった
  • 4.1 では、この問題を減らすための複数の変更が適用された
    • エディタで前方・後方のカメラ方向を入れ替えた
    • look_at() 関数に、カメラの -Z 軸ではなく モデル空間を前方基準として使う引数が追加された
    • この変更は、古いパス追従バグの修正にも役立つ
  • Godot 4 に フレームデルタスムージングが追加された
    • 動きの滑らかさを大きく改善し、よりスムーズなゲームプレイを提供できる
    • デフォルトで有効
    • VSync が有効なときにのみ動作する

スクリプティング改善

  • GDScript

    • 従来は、同じスクリプトの複数インスタンス間でデータを共有するには、リソースや autoload を使う必要があった
    • Godot 4.1 から 静的変数を作成して使用できる
    • 静的変数は各インスタンスではなくクラスにデータを保存し、同じクラスのすべてのインスタンスで値を共有する
    • スクリプト最上部の変数定義の前に static キーワードを付けて使う
    • Godot 4 で追加された名前付きクラスのドキュメント自動生成機能も改善された
    • 列挙型を型として扱うことで、生成されるドキュメントがより正確になった
    • 変数や関数定義の上にだけ書いていた docstring に加えて、インライン docstringも使える

  • C#/.NET

    • 今回のリリースにおける C# の焦点は、GDScript との 機能同等性を高めることにある
    • GDScript では、スクリプトにグローバルクラス名を追加して、エディタで使える新しいノードタイプを定義できていた
    • Godot 4.1 からは、C# でもファイルに [GlobalClass] 属性を追加して同じことが可能
    • [Icon] 属性でグローバルクラスに固有のアイコンも指定できる
    • ただし、4.1 時点で C# で作成したプロジェクトはまだ モバイルと Web プラットフォームへエクスポートできない
    • 対応作業は進行中
    • この制限の解消は、2023 年末の .NET 8 リリースにかかっている可能性が高い
    • モバイルと Web プラットフォーム対応の作業は、2023 年後半になってようやく本格化する可能性がある

  • GDExtension

    • Godot は、エンジンを再コンパイルせずに C++ のような低水準言語をゲームスクリプト言語として使える技術を提供している
    • GDExtension は今回のリリースでもまだ ベータ版
    • 4.1 では、GDExtension のスクリプティング能力が GDScript と C# にさらに近づいた
    • 新しいビジュアルシェーダーノードを実装できる
    • GDExtension でエディタプラグインを作成できる
    • 将来の API 変更後も Godot 4.1 用コードが動作し続けるのを助ける 後方互換システムが実装された
    • ただし、GDExtension の中核的な問題を修正するために、4.1 では大きな互換性破壊が必要だった
    • 既存の Godot 4.0 拡張は、4.1 向けに移植して再コンパイルする必要がある
    • GDExtension API を将来的に拡張可能にするためのアーキテクチャ作業も再び大きく進められた

エディタのワークフロー

  • Godot 4 は、プロジェクト設定、エディタ設定、各種ポップアップでマルチウィンドウをサポートしてきた
  • 4.1 からは、ドキュメントを フローティングウィンドウとして分離でき、シェーダーエディタを含むスクリプトエディタも分離して別モニターに置ける
  • エディタはウィンドウレイアウトを追跡し、閉じて再度開いたときに以前の作業位置を維持できる
  • Godot 4.0 は型付き配列の定義・エクスポートと個別ノードのインスペクタエクスポートをサポートしていたが、両者を組み合わせることはできなかった
  • Godot 4.1 からは ノード配列をインスペクタにエクスポートできるようになり、ゲームオブジェクト同士を接続しやすくなった
  • プロジェクトマネージャーには、個別プロジェクトにタグを付けてタグでフィルタリングする機能が追加された
    • 数十または数百の Godot プロジェクトを見つけやすくなる

レンダリング変更

  • パーティクル乱流はアーティストからのフィードバックをもとに再設計され、創作上の制御力が高まった
  • 乱流は、現代のゲームで見られる豊かで広がりのある効果を作るためによく使われる
  • 新しい 3D ノイズテクスチャで、ボリューメトリックフォグの密度を簡単に制御できる
    • 特定の領域で霧をより薄くできる
  • NoiseTexture3D は、パーティクルアトラクタのベクトルフィールド作成にも使える
    • パーティクルに影響する風をシミュレートするのに便利
  • Godot レンダラーにはまだ多くの計画済み改善があり、その大半は今後のリリースに入る予定
  • レンダリングチームと貢献者たちは、新機能よりも バグ修正と安定性を優先している
  • 3D GLES3 レンダラーはまだ完成しておらず、今後数か月にわたって相当な作業が進められる予定

ナビゲーション改善

  • Godot 4.0 は AI ナビゲーション向けのリアルタイム回避を導入したが、単一平面に制限されていた
  • Godot 4.1 には完全に書き直された回避アルゴリズムが含まれる
    • より良い挙動と、より大きな制御性を提供する
    • 回避は теперь 2D または 3D で動作できる
    • 飛行エージェントが地上歩行エージェントの上を移動できる
  • レイヤーを使って、どのエージェントがどのエージェントを回避するかを制御できる
  • 優先度を指定して、一部のエージェントが他のエージェントを押しのけるようにもできる
  • 改善されたナビゲーション挙動は 更新されたドキュメント で確認できる

プラットフォーム対応と Web の制約

  • Godot 4.1 のプラットフォーム対応範囲は Godot 4.0 と同じ
  • 標準エンジンと .NET 版のどちらでも、すべてのデスクトッププラットフォームへエクスポートできる
  • プロジェクトで C# を使っていない場合は、モバイルと Web へエクスポートできる
  • 4.1 時点の Web エクスポートには、一部の最新機能に対するベンダーサポート不足のため制限がある
    • macOS の Chrome のように WebGL 2 対応が弱いブラウザでは問題が発生する
    • Google の修正や専用 WebGL 1 / GLES2 レンダラー対応に相当な労力を投じない限り、解決は難しい
  • SharedArrayBuffer 対応に必要な CORS ヘッダーを設定できないホスティングプラットフォームでは、Web ゲームの設定が複雑になる
    • この問題は主に Safari における coep:credentialless ヘッダー対応の実装にかかっている
    • Chromium ベースのブラウザと Firefox はすでに良好に動作する
    • itch.io への配信では特にうまく動く
    • 可能な回避策を調査中

既知の問題と次のリリース

  • Godot 4.1 には、リリース前に解決できなかった問題が残っている
  • バグトラッカーは Godot GitHub issues で確認できる
  • 確認されている主要問題のひとつは、エクスポートプリセットのユーザー定義構成プロパティを定義する新 API がユーザー設定を保持できないこと
    • エディタを再起動すると構成オプションが初期化されて消える
    • 修正は 4.1.1 で提供予定
    • 関連 PR は GH-79025
  • Godot 4.2 の作業はすでに始まっており、4か月後にリリース予定
  • Godot は安定したリリースサイクルを維持し、次の改善や新機能を長く待たせない方針を続けている

関連記事

1件のコメント

 
GN⁺ 2023-07-07
Hacker Newsの意見

  • 最近 Unity から Godot 4.0 にほぼ完全に移行した。職業のゲーム開発者ではないが、小さなインディー / itch.io系のゲームを作る立場としては本当に満足している。
    軽量で高速で、学びやすく、1人開発/インディー開発者に必要なことの90%はこなせる。
    ただし macOS ユーザーが itch.io でゲームを開くと読み込みに時間がかかりすぎて、壊れていると思ってタブを閉じてしまうバグのせいで、Unity を完全には捨てられていない。
    自分が作るゲームは教育用だったり、iPad/MacBook を使う子ども向けだったりすることが多いので、ローカルインストールを教えて端末の所有者を説得するより、itch.io のリンクを渡すほうがずっと簡単だ。
    Godot 側でも解決中とのことだが、それまではいくつかのプロジェクトで引き続き Unity を使う必要がある。この問題が解決すれば、Godot は itch.io / ゲームジャム界隈で大きく伸びるかもしれない。

    As of 4.1 web exports still have some limitations due to poor vendor support of certain modern features. Browsers with bad WebGL 2 support, such as Chrome on macOS, unfortunately suffer from issues which we cannot address without a fix from Google or a significant amount of effort put into supporting a dedicated WebGL 1 / GLES2 renderer.
    We are also aware of the complexity setting up web games on hosting platforms which don’t let you set the required CORS headers for SharedArrayBuffer support. This mostly depends on Safari implementing the coep:credentialless header support, while Chromium-based browsers and Firefox already work fine (especially if you publish on itch.io). There is a possible workaround that we are investigating.

    • 自分も似たような状況だったが、結局 Godot 3.5.2 がまだ長期サポート版で、Web エクスポートも非常によく動くことに気づいた。移行を決めるきっかけになった例はこちら: https://yet-another-lucas.github.io/plumbing-adventure/
      その後、Godot 4.0 C# から Godot 3.5.2 + GDScript に移行し、満足している。
      master にコミットするたびに GitHub Pages へ自動でビルド/デプロイされる CI/CD パイプライン も構築したが、こうしたパイプラインはかなり良い。
      https://www.reddit.com/r/godot/comments/q25riu/hosting_on_gi...
    • 今年 Godot 3.5 でブラウザベースの小さなゲームジャム風ゲームを5本作ったが[1]、概ね体験は良かった。Godot 4 の Web エクスポートがきちんと動くようになるまでは、Godot 3.5 を使っていて十分満足できる。
      Godot 4 には、より良い型サポートやマジック文字列を減らせる改善、たとえばシグナルを名前で参照できる機能のような、期待している言語改善がある。
      ただ、それが大きな障害なら待ったほうがよいかもしれない。
      ときどき Godot 4 チームが macOS の問題を Godot のリグレッションではなく Chrome のバグとして捉えている姿勢にはもどかしさを感じる[2]。
      意味論と優先順位の問題に近いが、Godot 3 で頼っていた機能が Godot 4 で壊れたのなら、リグレッションと見なさないのは難しい。
      それでも Godot 4 と以前のバージョンに注がれたすべての作業にはとても感謝しており、いつか Godot 4 を使える日を楽しみにしている。
      [1] 気になるなら全部 https://eieio.games/ にある
      [2] https://github.com/godotengine/godot/issues/70691
    • 「macOS の Chrome のように WebGL 2 のサポートが悪いブラウザ」という部分が気になった。
      これまで Chrome/macOS で WebGL2 の問題に遭遇したことがないので、具体的にどういう問題なのか知りたい。
      ただ、自分も WebGL2/GLES3 機能のうち問題を起こすと知られているものは避けている。主に uniform buffer や、ネイティブではうまく動いても WebGL ではそうならないバッファ更新パターン、たとえば「buffer orphaning」のようなものだ。
    • Godot の VR サポートの状況 が気になる。UE4 は9年使ってきたし Unity はあまり好きではないが、Godot は一度試してみたい。
    • macOS で Godot を使ってゲームを作り、itch.io に配布しているが、この問題に遭遇したことはない。問題が起きる具体例とビルドのエクスポート設定情報を教えてもらえるだろうか？

  • Godot は本当に印象的なツールだ。新しいゲームプロジェクトを始める理由ができたら、もっと本格的に学んでみたいし、比較的小さなチームでここまでやっているのを見ると Unity が恥ずかしくなるほどだ。
    「Godot 4 の使用中に報告された問題と、4.1 プレリリースのテスト中に報告された問題を900件以上修正した」という点も印象的だ。
    性能と安定性をさらに改善しつつ、それだけ多くの問題を修正したこと自体が称賛に値する。

    • 900件の問題修正はたしかに印象的だが、Godot は GitHub でオープンな issue が最も多いリポジトリの1つかもしれない。今でも 5,000件以上 が開いている。
      もちろん、オープン issue の数はソフトウェア品質を判断する良い指標ではない。

  • Godotは好きだが、いくつか物足りない点がある。GDScriptはPythonではなく、Pythonを魅力的にしている細かな機能、たとえばリスト/辞書内包表記、.items()、集合などが不足している
    それでもゲーム開発用としては十分で、ネイティブ型など環境との相性も良く、かなり良い言語ではある
    GDNativeを使ったことがあり、GDExtensionももっと使ってみる必要はあるが、これまでのところGodot向けのC++記述はかなり荒削りに感じる。プログラマーがGodotの型やnew()をあちこちで使わなければならず、扱いやすいとは言い難い
    そのためGodotは本当のC++エンジンというより、普段はスクリプト言語を使い、スクリプトで十分な速度が出ない時だけC++で最適化する方向に近い
    GDScriptが他の言語と比べて実際どれほど速いのかももっと確認したいし、Mono/.NETのほうが速いのかも分からない。環境設計と完全に統合された言語である点は良いが、改善計画があるのか気になる
    マルチプレイFPSを作る予定だが、Godotはネットワーク予測を提供していないように見えるので、対応してほしい
    今後のOpenGLサポートも心配だ。まだ完全に終わったわけではないが、VulkanやDX12のような新しいAPIとはあまりに違いすぎて、きちんと実装するのが難しくなるのではと不安がある
    全体として、Godotはオープンソースとゲーム開発に起きた最高の出来事だ。ゲーム開発はオープンソースが根付きにくい分野だったし、Godotの軽量な設計はUnrealやUnityのような巨大なツールと比べると大きな安心感がある

    • Godotで最大の問題もそこだ。ただしGDScriptがPythonではないことではなく、汎用言語ではないことが問題だ。Unityで恋しく感じるほぼ唯一の部分でもある
      もちろんPythonを直接選ぶことはないと思うし、好きな言語ではあるが、もう少し性能重視の言語を選ぶはずだ。Goも悪くない選択かもしれない
      GDScript自体が悪いわけではなく、他の言語と比較しなければかなり優れている。だが汎用言語と比べると失うものが多すぎる
      バインディングがあるのは知っているが、Raylibで似た経験をした限りでは、非公式の言語サポートは実質的に存在しないも同然だった。公式バインディングのMonoもかなり出来が悪い
    • .NETのほうが速い
      ただしAAAゲームでさえ、ゲームロジックには遅いスクリプト言語をよく使う。多くのゲームではゲームロジックはCPUを大きく消費する部分ではないので、重要でないことも多い
    • ゲームフレームワークでいうネットワーク予測がどんな形なのか気になる。オブジェクトのどのプロパティを補間するか指定すれば、エンジンが自動で処理してくれるようなものなのか?

  • Electronのようなものの代わりに、クロスプラットフォームアプリ開発にGodotを使う用途はあるのか?

    • 可能。とはいえ、第1世代のアプリがようやく出始めた段階だ。GitHubにあるかなり完成度の高いプロジェクトをいくつか挙げると次の通り
      ピクセルアート編集器: https://github.com/Orama-Interactive/Pixelorama
      無限キャンバス描画ツール: https://github.com/mbrlabs/Lorien
      Trello風かんばんボード: https://github.com/alfredbaudisch/Godello
      ゲーム向けナラティブデザイナー: https://github.com/mhgolkar/Arrow
    • Material Maker: https://www.materialmaker.org
      SubstanceがAdobeに買収されたときに使ってみたが、驚くほど簡単で楽しく使えた。Substance Designerはかなり鈍重に感じる
      もちろんSubstance DesignerにはSubstance Painterとの統合という独自の強みがある。Material Makerにも手動ペイント機能はいくらかあるが、完全なペイントアプリではない
    • Godot IDE自体もGodotで作られているのか?
    • 可能
      OpenSCAD Graph Editorは以前のバージョンのGodotで作られており、Mac OS、Windows、Linuxで動作する:
      https://github.com/derkork/openscad-graph-editor
    • 一部の人はGodotをGUIフレームワークとして使っている

  • Godotの主要な貢献者/開発者の一人が、Godotで作ったものを完全にデコンパイルできる便利な小さなツールも公開している
    https://github.com/bruvzg/gdsdecomp

    • いいツールだが、Godotのメイン・リード・筆頭開発者はreduz、つまりJuan Linietskyだ

  • Godot は本当に素晴らしい。チームの進捗とプロジェクト全体の方向性に深く感銘を受けた。
    もともとゲーム開発にはずっと関心があり、ゲームを作りたくてコンピューターサイエンスを学び、ソフトウェアエンジニアになった面も大きい。小さなゲームを自分で作りたかったが、実際にはうまくできなかった。
    フルタイムのソフトウェアエンジニアになってからは、趣味で小さなゲームを作る時間も適切なツールも見つけられなかった。
    最近 Bevy を見つけて使ってみたが、ECS は良い概念である一方、Bevy はライブラリ寄りで、SDL のようなものを使うのと同じく、完成度の高いゲームを作るのはかなり難しい。
    Godot を見つけて使ってみたときは本当に感動した。初心者に優しく、それでいて十分に高速で、コミュニティも素晴らしい。まさに自分が探していたもので、存在していること自体がとてもうれしいし、今後の発展も楽しみだ。
    一つ残念なのは、ネイティブかつ「公式」の言語選択だ。GDScript は悪くなく、初心者や素早いプロトタイピングにはかなり良い Python 風言語であり、C# も Unity から移ってくる人には良いかもしれない。
    個人的には、より良い C++ サポート、あるいは何か別のものがあればもっと満足できたと思う。GDNative インターフェースがあり、4.0 で改善されたことも知っている。
    C# は良い言語だが、ゲーム開発で存在感が大きいのは Unity のおかげだという気がする。冗長すぎるし、Visual Studio の外ではツール支援もそれほど良くない。
    ただ、ゲーム開発では「実際のプログラミング」部分はそれほど重要ではないのかもしれないし、素直に受け入れて GDScript を使うべきなのかもしれない。

  • Godot が Unreal に対抗するのは難しいかもしれないが、Unity の代替として伸びていくことは間違いなく応援している。
    素晴らしいエンジンであり、ますます多くの開発者がその可能性を正しく評価し始めている。

    • Unity は Unreal とは異なる形で独自のエコシステムを持っている。Unity はプラットフォームとして モバイル収益化 を他のプラットフォームにはできない形で支援しており、Godot がそのエコシステムをすぐに奪うのは難しい。
      ただしインディー開発の話なら完全に同意する。Godot は、人々が Unity に期待していた、軽量で邪魔をせず、すぐ作り始められるフレームワークだ。その用途では Godot の方がはるかに優れている。
    • 何十年も続く AAA ゲーム中心のエンジンで、大規模なフルタイム体制を持つ Unreal と競争しようとするのは無謀だ。オープンソースのプロジェクトが、そうした動く目標を追いかけるのは難しい。
      幸い、Unreal Engine は多くの種類のゲームには向いておらず、Godot は 2D ゲームやシンプルな 3D ゲームの分野でうまく自分の立ち位置を築いている。
      2D ゲーム市場は依然として大きく、意外にも 2D をしっかりサポートするエンジンは多くない。Godot は容易に最上位クラスに入る。
    • マーケットプレイス を再現できれば Unity とも競争できそうだ。

  • Godot は本当にすごいし、このようなソフトウェアや Blender のようなツールを素晴らしいものにするために時間を注いでいるすべての人に大きな敬意を抱いている。

  • Godot はリリースのたびに本当に良くなっている。今後 Godot に入ってほしい機能がいくつかある。
    FSR2、優れた Wayland サポート、そして LLM 統合だ。LLM は NPC をより現実的にできるかもしれない。

    • LLM 統合については確信が持てない。ゲームエンジン関連というより、ゲーム個別の機能 に近く見える。LLM の統合はゲーム内でスクリプティングすればよさそうだ。
      人工知能統合という観点では、AI 支援デザインの方が興味深い。地形、キャラクター、シナリオを説明すると AI が何かを生成し、その後ユーザーがカスタマイズして調整する、といった形だ。
      しかしそれでさえ、ゲームエンジンの中核の外で行う方がよい可能性が高い。
    • ハードウェアアクセラレーション・レイトレーシング は？

  • おすすめの Godot チュートリアル はあるだろうか？
    コンソールで動く小さな RPG のプロトタイプがあるので、実際の GUI やスプライトグラフィックを付けてみたい。

    • Godot 4 向けの無料チュートリアルがあり、最初からおよそ 2 時間で完成したゲームまで作れる: https://quiver.dev/tutorials/create-your-first-godot-4-game/
      念のため言っておくと、私はこのコースを作った会社の創業者だ。それでもチュートリアルは無料で、そこで使われているカスタムアセットも寛容なライセンスで提供されている。
    • GD Quest が現在の定番と見なされている。Godot における W3Schools のような存在だ。
      ただし Unity から Godot に移る立場としては、Godot のチュートリアルエコシステムはまだかなり遅れていると思う。
    • Heartbeast のコースの一つを受講したことがあり、おすすめできる。
      最近 Godot 4 専用の講座も公開した。
      https://www.youtube.com/watch?v=M8-JVjtJlIQ
    • YouTube に自分のプログラミングチュートリアル一覧があり、その中に Godot チュートリアルもいくつかある。
      https://www.youtube.com/playlist?list=PLwYfcDZR0fFcROLjkiyBW...
      見つかるチュートリアルの多くは Godot 3 向けだろうから、フィルタで Godot 4 を明示して検索した方がよい。
      そうしないと、チュートリアルのコードが自分の Godot バージョンで動くように自分で合わせる必要があり、それもそれで学びになるかもしれない。
    • 公式ドキュメント[0] が間違いなく王道だ。
      [0] https://docs.godotengine.org/en/stable/getting_started/intro...