godotengine

GodotのゲームをWebにエクスポートして、プレイできるリンクを共有する方法 この記事は<ziva.sh>の日本語版です（英語の原文はZiva.shが2026年11月5日に公開）。 はじめに GodotのゲームをWebブラウザーで遊べるようにして、リンクで共有したい人向けの記事です。次の内容を扱います。 - Godot 4.7.2でのWebエクスポートの手順と、出力されるファイルのサイズ - 「Cross Origin Isolation」と「SharedArrayBuffer」がないというエラーの3つの直し方 - itch.io、GitHub Pages、Netlify、Cloudflare Pages、Lobsite、ZivaのShare Web buildでのリンクの共有と、各ホストの制限 Godot 4のゲームをブラウザーで動かすには、Webプリセット（シングルスレッド。Godot 4.3以降のデフォルト）でエクスポートし、フォルダーをHTTPで配信して、リンクを発行できるホストにアップロードします。ホストには、itch.io、GitHub Pagesのような静的ホスト、またはZivaを使っている場合はZivaのShare Web buildメニュー項目があります。Share Web buildは、Godotエディターの中からエクスポートとアップロードを行い、play.ziva.shのリンクを返します。 :::note info このページはZiva.shが公開しており、ZivaもZiva.shが開発しています。他のツールの情報は各ツールの公式ページをもとにした、2026年11月5日時点のものです。 ::: このページのGodotのコマンドはすべて、2026年11月5日にLinux上のGodot 4.7.2で、公開されているStar Catcherサンプルを使って実行し（C#のテストはスクリプトが1つだけのC#プロジェクトで実行）、各ビルドをChromiumで読み込みました。Safariではテストしていません。 プレイできるリンクを得る方法 | ホスト | 価格 | 制限 | 非公開のリンク | スレッド対応のビルド | | --- | --- | --- | --- | --- | | itch.io | itch.io：無料 | itch.io：展開後500MB、1,000ファイル、1ファイルあたり200MB | itch.io：Draftのシークレットリンク、またはパスワード付きのRestricted | itch.io：SharedArrayBuffer supportのチェックボックス | | GitHub Pages | GitHub Pages：公開リポジトリーなら無料 | GitHub Pages：1サイトあたり1GB、帯域幅は月100GBのソフトリミット | GitHub Pages：この記事では扱わない | GitHub Pages：ドキュメントにヘッダー設定の記載なし。PWAの回避策を使う | | Netlify | Netlify：月ごとのクレジット付きの無料プラン | Netlify Drop：「individual files over 10MB may cause your deploy to get stuck」（10MBを超える個別のファイルがあるとデプロイが止まることがある）との記載 | Netlify Drop：サイトを自分のアカウントに引き継ぐ（claim）までの一時的なパスワード | Netlify：_headersファイル | | Cloudflare Pages | Cloudflare Pages：無料プラン | Cloudflare Pages：1ファイルあたり25MiB、20,000ファイル | Cloudflare Pages：この記事では扱わない | Cloudflare Pages：_headersファイル | | Lobsite | Lobsite：無料、Godot 4なら年$20 | Lobsiteの無料プラン：1ファイルあたり5MB。Standard：1ファイルあたり100MB、1サイトあたり2GB | Lobsite：Standardでパスワードを設定できる | Lobsite：CLI経由のlobsite.tomlでヘッダーを設定 | | Ziva Share Web build | Ziva：無料のHobbyを含むすべてのプラン | Ziva：圧縮後300MB | Ziva：限定公開のプレビューのみ。公開したゲームは誰でも見られる | Ziva：ヘッダーは自動で設定。Godot 4.3以降はシングルスレッド | Godot 4.7.2のシングルスレッドのindex.wasmは、圧縮前で39,514,754バイトです。これはCloudflare Pagesの1ファイルあたり25MiBの制限と、Lobsiteの無料プランの5MBの制限を超えており、NetlifyがDropのデプロイが止まることがあるとしている10MBも超えています。そのため、無料のホストを選ぶ前に1ファイルあたりの制限を確認してください。古い回答ではいまでもGodotのゲーム向けに挙げられているGotm.ioは、すでに動いていません。ドメインの登録が切れています。 Godot 4のゲームをWeb向けにエクスポートする 1. Compatibilityレンダラーを使います。Godotのドキュメントによると、Godot 4は「can only target WebGL 2.0 (using the Compatibility rendering method)」（対象にできるのはWebGL 2.0だけで、Compatibilityレンダリング方式を使う）とされています。 2. Project > Exportを開き、「Add...」をクリックしてWebを選びます。 3. エクスポートテンプレートがないとGodotに表示されたら、Manage Export Templatesをクリックしてダウンロードします。Linuxでは~/.local/share/godot/export_templates/4.7.2.stable/に入ります。Godot 4.7.2のテンプレート一式はすべてのプラットフォームに対応しており、約1.2GBです。 4. Variant > Thread Supportはオフのままにします。Godotのドキュメントでは、Godot 4.3以降、シングルスレッドは「the preferred and now default way to export your games on the Web」（Webでゲームをエクスポートする推奨の方法で、現在はデフォルト）とされています。 5. Export Projectをクリックし、空のフォルダーにindex.htmlとして保存します。 コマンドラインからは、export_presets.cfgにWebという名前のプリセットがある状態で次のように実行します。 godot --headless --path my-game --export-release "Web" ../build/index.html 手元のマシンでは約3秒かかり、合計39.9MBの9ファイルができました。 | ファイル | バイト数 | gzip -9 | | --- | --- | --- | | index.wasm | 39,514,754 | 10,084,297 | | index.js | 279,815 | 68,400 | | index.pck | 7,316 | 3,487 | | index.html、オーディオワークレット2つ、アイコン3つ | 55,307 | - | ほとんどはエンジンです。その場でgzip圧縮するホストでは、送られるのはこのバイト数の約4分の1です。Godotのドキュメントでは、GitHub Pagesはその場でgzip圧縮するホスト、itch.ioは圧縮しないホストとして挙げられています。 4.7.2で警告なしにエクスポートできる最小限のexport_presets.cfgです。 [preset.0] name="Web" platform="Web" runnable=true export_filter="all_resources" include_filter="" exclude_filter="" export_path="../build/index.html" [preset.0.options] variant/thread_support=false include_filter、exclude_filterと、少なくとも1つのオプションがないと、エクスポート自体は成功しますが、ERROR: Couldn't find the given section "preset.0" and key "include_filter"と出力されます。 ブラウザーでビルドをテストする index.htmlをダブルクリックしても動きません。ChromiumではGodotのロゴの上にFailed to fetchと表示され、コンソールにはindex.wasmとindex.pckについてURL scheme "file" is not supportedと出ました。代わりにフォルダーを配信します。 cd build python3 -m http.server 8000 そのあと<localhost>を開きます。シングルスレッドのビルドは、追加のヘッダーなしでこの単純なサーバーから動きました。コンソールにはsingle-threadedと出力され、右矢印キーを押し続けるとプレイヤーが星に触れ、スコアが1になりました。Godotのドキュメントには、実行可能なWebプリセットとテンプレートがあるときにStopとPlay Edited Sceneの間に表示され、既定のブラウザーでゲームを開くボタンの説明もあります。 「Cross Origin Isolation」と「SharedArrayBuffer」がないというエラーを直す Thread Supportをオンにして特別なヘッダーなしで配信すると、Godot 4.7.2はロゴの上に次のエラーを表示して止まりました（Godotのドキュメントによると、Extensions Supportにも同じヘッダーが必要です）。 The following features required to run Godot projects on the Web are missing: Cross-Origin Isolation - Check that the web server configuration sends the correct headers. SharedArrayBuffer - Check that the web server configuration sends the correct headers. スレッド対応のビルドはSharedArrayBufferを使いますが、ブラウザーはクロスオリジン分離されたページでしかSharedArrayBufferを許可しません。直し方は3つあり、試す順に並べると次のとおりです。 1. シングルスレッドでエクスポートする：Thread SupportとExtensions Supportをオフにして、もう一度エクスポートします。GDExtensionで必要な場合を除けば、これがいちばん簡単な直し方です。Godotのドキュメントでは、シングルスレッドのエクスポートは「more compatible overall with stores like itch.io」（itch.ioのようなストアとの互換性が全体的に高い）とされ、Webポータルについても同様とされています。 2. 2つのヘッダーを送る：GodotのドキュメントにはCross-Origin-Opener-Policy: same-originとCross-Origin-Embedder-Policy: require-corpが挙げられています。ローカルなら、次の小さなサーバーで十分です。 import http.server, sys class COIHandler(http.server.SimpleHTTPRequestHandler): def end_headers(self): self.send_header("Cross-Origin-Opener-Policy", "same-origin") self.send_header("Cross-Origin-Embedder-Policy", "require-corp") super().end_headers() http.server.ThreadingHTTPServer(("127.0.0.1", int(sys.argv[1])), COIHandler).serve_forever() このサーバーを使うと、スレッド対応のビルドはmulti-threadedと出力して動きました。NetlifyとCloudflare Pagesは、同じヘッダーを_headersファイルから読み込みます。itch.ioでは、Embed options > Frame optionsの下にあるSharedArrayBuffer supportにチェックを入れます。itch.ioのお知らせでは、この機能は実験的とされています。 3. ヘッダーを設定できない場合はPWAの回避策を使う：エクスポートプリセットでProgressive Web Appを有効にし、Ensure Cross Origin Isolation Headersをオンのままにします（デフォルトでオンです）。するとService Workerがヘッダーを追加します。HTTPSかlocalhostが必要です。今回のテストでは、初回アクセス4回中4回でメッセージのない黒い画面になり、手動で1回再読み込みするとゲームが動きました。そのため、プレイテスターには1回再読み込みするよう伝えてください。 友人やプレイテスターにリンクを共有する itch.io 1. シングルスレッドでエクスポートします。 2. エクスポートしたフォルダーの中身をZIPにして、index.htmlがZIPの最上位に来るようにします。今回の9ファイルのビルドでは、10.2MBのZIPになりました。 3. itch.ioで新しいプロジェクトを作り、種類をHTMLにして、ZIPをアップロードし、This file will be played in the browserにチェックを入れます。 4. 埋め込みのサイズをゲームのビューポートに合わせ、スマートフォンで動くならMobile friendlyにチェックを入れます。 5. プロジェクトをDraftのままにしてシークレットリンクを共有するか、公開します。 itch.ioのドキュメントによると、HTML5のZIPは最大1,000ファイル、展開後500MB、1ファイルあたり200MBまでで、Draftは「only accessible by people who can edit it, and people with the secret link」（編集できる人と、シークレットリンクを持っている人だけがアクセスできる）とされています。承認したテスターだけに見せるには、ページをRestrictedにしてパスワードを追加します。itch.ioによると、「include the password directly in the URL」（パスワードをURLに直接含める）こともできます。Godotの中からアップロードしたい場合、無料でMITライセンスのプラグインであるShipItch、Itch Exporter & Uploader、Greenlightは、itch.ioのbutlerツールを使ってエクスポートとアップロードを行います。Majordomoは、butlerでitch.ioにビルドをプッシュします。 GitHub Pages、Netlify、Cloudflare Pages エクスポートしたフォルダーをリポジトリーにコミットしてPagesを有効にするか、フォルダーをNetlifyにドロップします。github.com向けのGitHub Pagesのドキュメントには、カスタムのレスポンスヘッダーを設定する方法が書かれていません。そのため、GitHub Pagesでは、シングルスレッドのエクスポートか、前述のPWAの回避策を使います。1ファイルあたりの制限に注意してください。Cloudflare Pagesは1ファイルを25MiBまでに制限しており、Godot 4.7.2のindex.wasmは39.5MBです。 ZivaのShare Web build：エディターからplay.ziva.shのリンクを作る Zivaは、Godotエディターの中で動くAIアシスタントです。Zivaのチャットヘッダーにある「⋮」メニューのShare Web build項目が、エクスポートとホスティングを代わりに行います。 1. Zivaは、Ziva自身のアドオンを除いたプロジェクトのコピーに対して、開発者自身のGodotエディターでGodotのWebエクスポートを実行します。プロジェクトにWebエクスポートのプリセットがなければ追加します。 2. エクスポートテンプレートがない場合、Zivaは先にGodotの公式テンプレートをダウンロードします。 3. Godot 4.3以降では、Zivaはシングルスレッドでエクスポートします。ただし、GDExtensionがスレッド対応のWebライブラリーしか同梱していない場合は例外で、そのときはゲームがiPhoneやSafariで動かないと警告します。シングルスレッドのテンプレートがないGodot 4.2では、ビルドはスレッド対応になります。 4. Zivaがビルドを圧縮してアップロードし、試すための限定公開のプレビューリンクが発行されます。 5. タイトル、説明、カバー画像を追加してApprove and publishを選ぶと、共有用のplay.ziva.shのリンクが発行されます。 2026年11月5日に、エクスポートテンプレートのない新規インストールのZivaにサインインした状態で、Star Catcherサンプルをこの方法で共有しました。Godot 4.7.2のテンプレート（1,222MB）のダウンロードには、手元の回線で約21分かかりました。テンプレートの展開、エクスポート、圧縮した9ファイル（13.5MB）のアップロードには、さらに1分もかかりませんでした。ゲームは<play.ziva.sh>にあり、Chromiumでサインインせずにプレイできました。 !Star Catcherサンプルを、サインアウトした状態のChromiumでplay.ziva.shのページから実行している画面。青緑の四角形が星を1つ取り、ラベルはScore: 1になっている Share Web buildは、サインインしていれば無料のHobbyプランを含むすべてのZivaのプランで、圧縮後300MBまでのビルドに使えます。再ビルドしても同じリンクのままで、ゲームを削除するまでリンクの期限は切れません。チャットでZivaに公開の準備を頼むこともできます。Zivaはプレビューをビルドして掲載内容を表示し、自動承認がオンでも、承認したあとにだけ公開します。更新、削除、別のコンピューターからゲームをリンクする方法は、Share web buildsのドキュメント（英語）にあります。 Godot 4のC#プロジェクトはWebにエクスポートできる？ できません。Godot 4.7.2の.NETエディターは、スクリプトが1つだけのC#プロジェクトのエクスポートを拒否しました。 Exporting to Web is currently not supported in Godot 4 when using C#/.NET. Use Godot 3 to target Web with C#/Mono instead. Godotのドキュメントには「Projects written in C# using Godot 4 currently cannot be exported to the web.」（Godot 4でC#を使って書かれたプロジェクトは、現在Webにエクスポートできない）とあります。追跡用のissueであるgodotengine/godot#70796は、2026年6月19日に「The foundation is evaluating solutions for C# web support.」（財団がC#のWeb対応の解決策を検討している）というコメントとともにロックされました。いまブラウザー向けのビルドを作るには、GDScriptを使うか、Godot 3とC#を使います。ZivaのShare Web buildにも同じ制限があります。 ZivaのShare Web buildにできないこと - Zivaがアップロードできるのはplay.ziva.shだけで、itch.io、GitHub Pages、その他のホストにはアップロードしません。 - 公開したZivaのビルドは誰でも見られます。play.ziva.shに掲載され、プレイヤーが評価やコメントでき、新しいゲームはZivaのDiscordで告知されます。限定公開なのはプレビューだけです。 - Zivaには、独自ドメインやパスワード保護されたビルドの機能はありません。 - Godot 4がC#プロジェクトをWebにエクスポートできないため、ZivaもC#プロジェクトをWebにエクスポートできません。 - Share Web buildはGodot専用で、Zivaをインストールした状態のGodotエディターと、Zivaへのサインインが必要です。 - Zivaがアップロードするのは、GodotのWebエクスポートだけです。プロジェクトのフォルダーやチャットはアップロードしません。どのWebビルドでも同じですが、エクスポートにはゲームのシーンとスクリプトが含まれます。 関連記事（英語） - Share web builds：Zivaの手順ドキュメント - Godot online multiplayer without a server：Webエクスポートも扱っています - How to automate playtesting in Godot - Godot's "Exporting for the Web" docs まとめ - シングルスレッドのエクスポート（Godot 4.3以降のデフォルト）なら、特別なヘッダーなしで動きます。index.htmlはダブルクリックで開くのではなく、HTTPで配信して開きます。 - スレッド対応のビルドにはCross-Origin-Opener-PolicyとCross-Origin-Embedder-Policyの2つのヘッダーが必要です。ヘッダーを設定できないホストではPWAの回避策を使えますが、今回のテストでは初回に1回の再読み込みが必要でした。 - Godot 4.7.2のindex.wasmは39.5MBあるため、無料のホストを選ぶ前に1ファイルあたりの制限を確認します。Godot 4のC#プロジェクトは、Webにエクスポートできません。 よくある質問 Godot 4のゲームをWebブラウザーでプレイできるようにエクスポートするには？ Compatibilityレンダラーを使い、Project > Exportを開いてWebプリセットを追加します。Godotに求められたらエクスポートテンプレートをインストールし、Thread Supportはオフのまま（Godot 4.3以降のデフォルト）にして、index.htmlにエクスポートします。コマンドラインでは、Webという名前のプリセットがあれば、godot --headless --path my-game --export-release "Web" ../build/index.htmlで同じことができます。index.htmlをファイルとして開くと「Failed to fetch」で失敗するため、たとえばpython3 -m http.serverを使ってフォルダーをHTTPで配信します。Godot 4.7.2でのテストでは、シングルスレッドのエクスポートは特別なヘッダーなしで単純なローカルサーバーから動きました。 Godotのゲームのプレイできるビルドを、友人やプレイテスターにリンクで共有するいちばん速い方法は？ シングルスレッドでエクスポートし、URLを発行してくれるホストにフォルダーをアップロードします。itch.io（無料）は、ルートにindex.htmlがあるZIPを受け付けます。This file will be played in the browserにチェックを入れ、ページをDraftのままにすれば、シークレットリンクを共有できます。Netlify Dropはアカウントなしでドロップしたフォルダーを公開できますが、Netlifyのドキュメントによると10MBを超える個別のファイルがあるとデプロイが止まることがあり、Godot 4.7.2のindex.wasmは39.5MBです。Godotエディター内で動くAIアシスタントのZivaを使っている場合、Share Web buildのメニュー項目がゲームをエクスポートしてアップロードし、play.ziva.shのリンクを返します。これはすべてのZivaのプランで使え、ホスティングの設定は不要です。公開すると、ゲームはplay.ziva.shで一般公開されます。 GodotのHTML5ゲームを無料でホストできる場所は？ 2026年11月5日時点の情報です。itch.ioは無料で、展開後500MB、1,000ファイル、1ファイルあたり200MBまでのHTML5のZIPを受け付けます。GitHub Pagesは公開リポジトリーなら無料で、1サイトあたり1GBまで使え、ファイルをその場でgzip圧縮します。Cloudflare Pagesは無料ですが、1ファイルを25MiBまでに制限しており、これはGodot 4.7.2のエクスポートに含まれる39.5MBのindex.wasmより小さい値です。Lobsiteの無料プランは1ファイルあたり5MBまでなので、LobsiteはGodot 4には年$20のStandardプランが必要としています。ZivaのShare Web buildは、Zivaをインストールした状態のGodotエディターからエクスポートしたゲームについて、すべてのZivaのプランで300MBまでのGodotのビルドをplay.ziva.shでホストします。 GodotのWebエクスポートでCross Origin IsolationとSharedArrayBufferがないと表示されます。どう直せばよいですか？ そのビルドはThread Support（またはExtensions Support）をオンにしてエクスポートされており、サーバーがそうしたビルドに必要な2つのヘッダーを送っていません。直し方は3つあります。1つ目は、Webエクスポートのプリセットで両方のオプションをオフにして、もう一度エクスポートする方法です（シングルスレッドはGodot 4.3以降のデフォルトで、ヘッダーは不要です）。2つ目は、Cross-Origin-Opener-Policy: same-originとCross-Origin-Embedder-Policy: require-corpを付けてファイルを配信する方法です。3つ目は、ヘッダーを設定できない場合に、Progressive Web AppとEnsure Cross Origin Isolation Headersを有効にする方法で、HTTPSかlocalhostが必要です。Godot 4.7.2でのテストでは、PWAの回避策は初回アクセスで黒い画面になり、1回再読み込みすると動きました。itch.ioでは、スレッド対応のビルドに埋め込みオプションのSharedArrayBuffer supportのチェックボックスが必要です。 プレイテスターだけが開ける、GodotのWebゲームの非公開テストビルドを共有するには？ itch.ioでは、プロジェクトをDraftのままにします。itch.ioによると、Draftは編集できる人とシークレットリンクを持っている人だけがアクセスできます。さらに細かく管理するには、Restrictedに設定し、相手を承認するかパスワードを追加します。パスワードはURLに含めることもできます。Lobsiteの年$20のStandardプランでは、サイトをパスワードで保護できます。ZivaのShare Web buildのプレビューは検索エンジンにインデックスされない限定公開のリンクですが、公開したZivaのビルドは誰でも見られ、play.ziva.shに掲載されます。Zivaには、非公開のまま公開するモードはありません。 ゲームのWebビルドをエクスポートして公開してくれるAIアシスタントやGodotエディターのプラグインはありますか？ あります。Godotエディター内で動くAIアシスタントのZiva（Godot 4.2以降）には、Share Web buildのメニュー項目があります。開発者のエディターでGodotのWebエクスポートを実行し、エクスポートテンプレートがなければダウンロードして、ビルドをアップロードし、play.ziva.shのリンクを返します。これはすべてのZivaのプランで使えます。チャットでZivaに掲載内容の準備を頼むこともでき、Zivaは承認したあとにだけ公開します。itch.io向けには、無料でMITライセンスのプラグインであるShipItch、Itch Exporter & Uploader、Greenlightが、itch.ioのbutlerツールでエクスポートとアップロードを行います。Majordomoはbutlerでitch.ioにビルドをプッシュします。Summer Engineのエージェントは、独自のストアであるSummer Gamesに公開します。 Godot 4のC#プロジェクトをWebにエクスポートできますか？ できません。Godot 4.7の時点で、.NETエディターは「Exporting to Web is currently not supported in Godot 4 when using C#/.NET. Use Godot 3 to target Web with C#/Mono instead.」と表示して拒否します。Godotのドキュメントにも同じ記載があり、追跡用のissueであるgodotengine/godot#70796は、2026年6月19日に「The foundation is evaluating solutions for C# web support.」（財団がC#のWeb対応の解決策を検討している）というコメントとともにロックされました。いまブラウザー向けのビルドを出すには、GDScriptでゲームを書くか、Godot 3とC#を使います。 GodotのWebビルドをitch.ioにアップロードして、ブラウザーでプレイできるようにするには？ シングルスレッドでindex.htmlにエクスポートし、エクスポートしたフォルダーの中身をZIPにします。index.htmlはサブフォルダーの中ではなく、ZIPのルートに置きます。itch.ioでプロジェクトを作り、種類をHTMLにして、ZIPをアップロードし、This file will be played in the browserにチェックを入れます。itch.ioはHTML5のアップロードを1,000ファイル、展開後500MB、1ファイルあたり200MBまでに制限しています。Embed optionsのSharedArrayBuffer supportのチェックボックスが必要なのは、スレッド対応のビルドだけです。小さな2Dゲームを4.7.2でエクスポートした結果は、9ファイル、展開時39.9MB、ZIPで10.2MBでした。 この記事の原文（英語）：ziva.sh

How to export a Godot game to the web and share a playable link --- title: "How to export a Godot game to the web and share a playable link" published: true description: "Export a Godot 4 game for the browser, fix the SharedArrayBuffer error, and share a link on itch.io, GitHub Pages or play.ziva.sh. Tested on Godot 4.7.2." tags: godot, gamedev, webdev, tutorial canonical_url: ziva.sh cover_image: ziva.sh --- To put a Godot 4 game in a browser, export it with the Web preset (single-threaded, the default since Godot 4.3), serve the folder over HTTP, and upload it to a host that gives you a link: itch.io, a static host such as GitHub Pages, or, if you use Ziva, its Share Web build menu item, which exports, uploads and returns a play.ziva.sh link from inside the Godot editor. Disclosure: Ziva.sh publishes this page and makes Ziva. Facts about other tools come from their own pages, as of 5 November 2026. We ran every Godot command on this page on 5 November 2026 with Godot 4.7.2 on Linux, on the public Star Catcher sample (and the C# test on a one-script C# project), and loaded each build in Chromium. We did not test Safari. Ways to get a playable link | Host | Price | Limits | Private link | Threaded builds | | --- | --- | --- | --- | --- | | itch.io | itch.io: free | itch.io: 500 MB extracted, 1,000 files, 200 MB per file | itch.io: Draft secret link, or Restricted with a password | itch.io: SharedArrayBuffer support checkbox | | GitHub Pages | GitHub Pages: free for public repositories | GitHub Pages: 1 GB per site, 100 GB a month soft bandwidth | GitHub Pages: not covered here | GitHub Pages: no header settings in its docs; PWA workaround | | Netlify | Netlify: free plan with monthly credits | Netlify Drop: "individual files over 10MB may cause your deploy to get stuck" | Netlify Drop: temporary password until you claim the site | Netlify: _headers file | | Cloudflare Pages | Cloudflare Pages: free plan | Cloudflare Pages: 25 MiB per file, 20,000 files | Cloudflare Pages: not covered here | Cloudflare Pages: _headers file | | Lobsite | Lobsite: free, or $20 a year for Godot 4 | Lobsite free: 5 MB per file; Standard: 100 MB per file, 2 GB per site | Lobsite: password on Standard | Lobsite: lobsite.toml headers via its CLI | | Ziva Share Web build | Ziva: every plan, including free Hobby | Ziva: 300 MB after compression | Ziva: unlisted preview only; published games are public | Ziva: headers set for you; single-threaded on Godot 4.3+ | Godot 4.7.2's single-threaded index.wasm is 39,514,754 bytes before compression. That is above Cloudflare Pages' 25 MiB per-file limit and Lobsite's free 5 MB limit, and over the 10 MB at which Netlify says Drop deploys may stall, so check per-file limits before you pick a free host. Gotm.io, which older answers still list for Godot games, no longer works: its domain registration has expired. Export a Godot 4 game for the web 1. Use the Compatibility renderer. Godot's docs say Godot 4 "can only target WebGL 2.0 (using the Compatibility rendering method)". 2. Open Project > Export, click Add... and choose Web. 3. If Godot says export templates are missing, click Manage Export Templates and download them. They go in ~/.local/share/godot/export_templates/4.7.2.stable/ on Linux; the Godot 4.7.2 template bundle covers every platform and is about 1.2 GB. 4. Leave Variant > Thread Support off. Godot's docs call single-threaded "the preferred and now default way to export your games on the Web" since Godot 4.3. 5. Click Export Project and save as index.html in an empty folder. From the command line, with a preset named Web in export_presets.cfg: godot --headless --path my-game --export-release "Web" ../build/index.html On our machine that took about 3 seconds and produced 9 files, 39.9 MB in total: | File | Bytes | gzip -9 | | --- | --- | --- | | index.wasm | 39,514,754 | 10,084,297 | | index.js | 279,815 | 68,400 | | index.pck | 7,316 | 3,487 | | index.html, two audio worklets, three icons | 55,307 | - | Almost all of it is the engine. Hosts that gzip on the fly send about a quarter of those bytes; Godot's docs list GitHub Pages as one that does and itch.io as one that doesn't. A minimal export_presets.cfg that exports without warnings in 4.7.2: [preset.0] name="Web" platform="Web" runnable=true export_filter="all_resources" include_filter="" exclude_filter="" export_path="../build/index.html" [preset.0.options] variant/thread_support=false Without include_filter, exclude_filter and at least one option, the export still succeeds but prints ERROR: Couldn't find the given section "preset.0" and key "include_filter". Test the build in your browser Double-clicking index.html does not work. Chromium showed Failed to fetch over the Godot logo, and the console said URL scheme "file" is not supported for index.wasm and index.pck. Serve the folder instead: cd build python3 -m http.server 8000 Then open localhost. Our single-threaded build ran from this plain server with no extra headers: the console printed single-threaded, and holding the right arrow moved the player into a star and the score went to 1. Godot's docs also describe a button between Stop and Play Edited Scene, shown when a runnable web preset and templates exist, that opens the game in your default browser. Fix "Cross Origin Isolation" and "SharedArrayBuffer" missing With Thread Support on and no special headers, Godot 4.7.2 stopped with this error over the logo (Godot's docs say Extensions Support needs the same headers): The following features required to run Godot projects on the Web are missing: Cross-Origin Isolation - Check that the web server configuration sends the correct headers. SharedArrayBuffer - Check that the web server configuration sends the correct headers. Threaded builds use SharedArrayBuffer, which browsers only allow on cross-origin isolated pages. Three fixes, in the order we'd try them: 1. Export single-threaded. Turn Thread Support and Extensions Support off and export again. Unless a GDExtension needs them, this is the simplest fix; Godot's docs call single-threaded exports "more compatible overall with stores like itch.io" and web portals. 2. Send the two headers. Godot's docs list Cross-Origin-Opener-Policy: same-origin and Cross-Origin-Embedder-Policy: require-corp. Locally, this tiny server is enough: import http.server, sys class COIHandler(http.server.SimpleHTTPRequestHandler): def end_headers(self): self.send_header("Cross-Origin-Opener-Policy", "same-origin") self.send_header("Cross-Origin-Embedder-Policy", "require-corp") super().end_headers() http.server.ThreadingHTTPServer(("127.0.0.1", int(sys.argv[1])), COIHandler).serve_forever() With it, the threaded build printed multi-threaded and ran. Netlify and Cloudflare Pages read the same headers from a _headers file. On itch.io, tick SharedArrayBuffer support under Embed options > Frame options; itch.io's announcement calls it experimental. 3. Use the PWA workaround when you can't set headers. In the export preset, enable Progressive Web App and keep Ensure Cross Origin Isolation Headers on (it is on by default). A service worker then adds the headers. It needs HTTPS or localhost. In our tests, 4 out of 4 first visits showed a black screen with no message, and the game ran after one manual reload, so tell playtesters to reload once. Share the link with friends or playtesters itch.io 1. Export single-threaded. 2. ZIP the contents of the export folder, so index.html is at the top of the ZIP. Our 9-file build made a 10.2 MB ZIP. 3. On itch.io, create a new project, set its kind to HTML, upload the ZIP and tick This file will be played in the browser. 4. Set the embed size to your game's viewport, and tick Mobile friendly if it works on phones. 5. Leave the project as a Draft and share the secret link, or publish it. itch.io's docs say HTML5 ZIPs must have at most 1,000 files, 500 MB extracted and 200 MB per file, and that a Draft is "only accessible by people who can edit it, and people with the secret link". For testers you approve, set the page to Restricted and add a password; itch.io says you can "include the password directly in the URL". To upload from inside Godot, the free MIT-licensed plugins ShipItch, Itch Exporter & Uploader and Greenlight export and upload with itch.io's butler tool, and Majordomo pushes builds to itch.io with butler. GitHub Pages, Netlify or Cloudflare Pages Commit the export folder to a repository and turn on Pages, or drop the folder on Netlify. GitHub's Pages docs for github.com describe no way to set custom response headers, so on GitHub Pages use the single-threaded export or the PWA workaround above. Watch per-file limits: Cloudflare Pages caps each file at 25 MiB, and Godot 4.7.2's index.wasm is 39.5 MB. Ziva's Share Web build: a play.ziva.sh link from the editor Ziva is an AI assistant that runs inside the Godot editor. Its Share Web build item, in the ⋮ menu of the Ziva chat header, does the export and the hosting for you: 1. Ziva runs Godot's web export with your own Godot editor, on a copy of your project without Ziva's own addon, and adds a Web export preset if your project has none. 2. If the export templates are missing, Ziva downloads Godot's official templates first. 3. On Godot 4.3 and later, Ziva exports single-threaded unless a GDExtension ships only threaded web libraries, and then warns that the game won't run on iPhone or Safari. On Godot 4.2, which has no single-threaded templates, builds are threaded. 4. Ziva compresses and uploads the build, and you get an unlisted preview link to try it. 5. You add a title, description and cover, choose Approve and publish, and get a play.ziva.sh link to share. We shared the Star Catcher sample this way on 5 November 2026, signed in on a fresh Ziva install with no export templates. Downloading Godot 4.7.2's templates (1,222 MB) took about 21 minutes on our connection; extracting them, exporting and uploading the 9 compressed files (13.5 MB) took under a minute more. The game is at play.ziva.sh, and it played in Chromium without signing in. !The Star Catcher sample running on its play.ziva.sh page in Chromium, signed out: the teal square has collected a star and the label reads Score: 1 Share Web build works on every Ziva plan, including the free Hobby plan, once you're signed in, for builds up to 300 MB after compression. Rebuilding keeps the same link, and links don't expire until you delete the game. You can also ask Ziva in chat to prepare the game for publishing; Ziva builds the preview and shows the listing, and publishes only after you approve, even with auto-approve on. The Share web builds docs cover updating, deleting and linking a game from another computer. Can you export a Godot 4 C# project to the web? No. Godot 4.7.2's .NET editor refused our one-script C# project: Exporting to Web is currently not supported in Godot 4 when using C#/.NET. Use Godot 3 to target Web with C#/Mono instead. Godot's docs say "Projects written in C# using Godot 4 currently cannot be exported to the web." The tracking issue, godotengine/godot#70796, was locked on 19 June 2026 with the comment "The foundation is evaluating solutions for C# web support." For a browser build today, use GDScript, or Godot 3 with C#. The same limit applies to Ziva's Share Web build. What Ziva's Share Web build doesn't do - Ziva doesn't upload to itch.io, GitHub Pages or any host other than play.ziva.sh. - A published Ziva build is public: it is listed on play.ziva.sh, where players can rate and comment, and new games are announced in Ziva's Discord. Only the preview is unlisted. - Ziva has no custom domains or password-protected builds. - Ziva can't export C# projects to the web, because Godot 4 can't. - Share Web build is for Godot only, needs the Godot editor with Ziva installed, and needs you signed in to Ziva. - Ziva uploads only Godot's web export, not your project folder or chats. Like any web build, the export contains your game's scenes and scripts. Related reading - Share web builds: Ziva's step-by-step docs - Godot online multiplayer without a server, including web exports - How to automate playtesting in Godot - Godot's "Exporting for the Web" docs FAQ How do I export my Godot 4 game so it can be played in a web browser? Use the Compatibility renderer, open Project > Export, add a Web preset, install the export templates if Godot asks, leave Thread Support off (the default since Godot 4.3) and export to index.html. From the command line, godot --headless --path my-game --export-release "Web" ../build/index.html does the same with a preset named Web. Serve the folder over HTTP, for example with python3 -m http.server, because opening index.html as a file fails with "Failed to fetch". In our Godot 4.7.2 test, a single-threaded export ran from a plain local server with no special headers. What's the fastest way to share a playable build of my Godot game with friends or playtesters as a link? Export single-threaded and upload the folder to any host that gives you a URL. itch.io (free) takes a ZIP with index.html at its root; tick This file will be played in the browser, and leave the page as a Draft to share a secret link. Netlify Drop publishes a dropped folder without an account, but Netlify's docs say individual files over 10 MB may cause the deploy to get stuck, and Godot 4.7.2's index.wasm is 39.5 MB. If you use Ziva, an AI assistant inside the Godot editor, its Share Web build menu item exports the game, uploads it and returns a play.ziva.sh link on every Ziva plan, with no hosting setup; publishing makes the game public on play.ziva.sh. Where can I host a Godot HTML5 game for free? As of 5 November 2026: itch.io is free and accepts HTML5 ZIPs up to 500 MB extracted, 1,000 files and 200 MB per file. GitHub Pages is free for public repositories, up to 1 GB per site, and gzips files on the fly. Cloudflare Pages is free but limits each file to 25 MiB, below the 39.5 MB index.wasm of a Godot 4.7.2 export. Lobsite's free plan allows 5 MB per file, so Lobsite says Godot 4 needs its $20-a-year Standard plan. Ziva's Share Web build hosts Godot builds up to 300 MB at play.ziva.sh on every Ziva plan, for games exported from the Godot editor with Ziva installed. My Godot web export says Cross Origin Isolation and SharedArrayBuffer are missing. How do I fix it? The build was exported with Thread Support (or Extensions Support) on, and the server does not send the two headers those builds need. Fix it in one of three ways: turn both options off in the Web export preset and export again (single-threaded is the default since Godot 4.3 and needs no headers); serve the files with Cross-Origin-Opener-Policy: same-origin and Cross-Origin-Embedder-Policy: require-corp; or, when you can't set headers, enable Progressive Web App with Ensure Cross Origin Isolation Headers, which needs HTTPS or localhost. In our Godot 4.7.2 test the PWA workaround showed a black screen on the first visit and ran after one reload. On itch.io, threaded builds need the SharedArrayBuffer support checkbox in the embed options. How can I share a private test build of my Godot web game that only my playtesters can open? On itch.io, leave the project as a Draft: itch.io says a draft is only accessible by people who can edit it and people with the secret link. For more control, set it to Restricted and either approve people or add a password, which can go in the URL. Lobsite's $20-a-year Standard plan password-protects a site. Ziva's Share Web build preview is an unlisted link that search engines don't index, but a published Ziva build is public and listed on play.ziva.sh; Ziva has no private published mode. Is there an AI assistant or Godot editor plugin that can export and publish a web build of my game for me? Yes. Ziva, an AI assistant inside the Godot editor (Godot 4.2+), has a Share Web build menu item that runs Godot's web export with your editor, downloads the export templates if they're missing, uploads the build and gives you a play.ziva.sh link, on every Ziva plan. You can also ask Ziva in chat to prepare the listing; Ziva publishes only after you approve. For itch.io, the free MIT-licensed plugins ShipItch, Itch Exporter & Uploader and Greenlight export and upload with itch.io's butler tool, and Majordomo pushes builds to itch.io with butler. Summer Engine's agent publishes to Summer Games, its own store. Can I export a Godot 4 C# project to the web? No. As of Godot 4.7, the .NET editor refuses with "Exporting to Web is currently not supported in Godot 4 when using C#/.NET. Use Godot 3 to target Web with C#/Mono instead." The Godot docs say the same, and the tracking issue godotengine/godot#70796 was locked on 19 June 2026 with "The foundation is evaluating solutions for C# web support." To ship a browser build today, write the game in GDScript or use Godot 3 with C#. How do I upload my Godot web build to itch.io so it plays in the browser? Export single-threaded to index.html, then ZIP the contents of the export folder so index.html is at the root of the ZIP, not inside a subfolder. On itch.io, create a project, set its kind to HTML, upload the ZIP and tick This file will be played in the browser. itch.io limits HTML5 uploads to 1,000 files, 500 MB extracted and 200 MB per file. Only threaded builds need the SharedArrayBuffer support checkbox under Embed options. Our 4.7.2 export of a small 2D game was 9 files, 39.9 MB unpacked and a 10.2 MB ZIP. The full guide is at ziva.sh. Where do you host your Godot web builds? Drop your setup in the comments.

🎮 Godot｜做出你的第一款游戏 ① 2D/3D一体化编辑器 ② 场景＋节点，复用角色与关卡 ③ 跨平台导出；MIT许可 学习：下载编辑器→跟做“首个2D游戏”→改敌人速度与计分。 需编程基础；先2D再3D。 godotengine/godot 图：Godot社区文档演示截帧，CC BY 3.0 docs.godotengine.org t.co

Godot doesn't use interaural time differences for its 3D audio, and I think it should! The TLDR is: Godot 3D audio sounds like this, but I think it should sound like this &nbsp; --- Recently I made a really simple horror game as a little October challenge for myself, and I was struggling with getting the 3D audio to sound right. I tried out 2 different community-made raytraced-audio plugins before realizing that neither the default AudioStreamPlayer3D node, or either of the plugins I tried, added any kind of interaural time differences to the spacial audio, which really surprised me. I already opened a discussion on the godot-proposals repo about this, but I also wanted to post about it here, since my experience with the spacial audio plugins makes me think this may be an under-appreciated topic. My full discussion post: &nbsp; --- From Wikipedia: _The interaural time difference (or ITD) when concerning humans or animals, is the difference in arrival time of a sound between two ears. It is important in the localization of sounds, as it provides a cue to the direction or angle of the sound source from the head. If a signal arrives at the head from one side, the signal has further to travel to reach the far ear than the near ear. This pathlength difference results in a time difference between the sound's arrivals at the ears, which is detected and aids the process of identifying the direction of sound source._ &nbsp; Currently, Godot's AudioStreamPlayer3D and AudioListener3D use only panning to clue you in to what direction a sound is coming from, which creates a very weak illusion of spacial direction for 3D audio. However, interaural time differences are much more important for creating the illusion of 3d audio, and Godot doesn't provide a built-in way to create that effect. &nbsp; I whipped up 3 demo samples in Audacity to showcase this: - Water droplet panned 40% to the left. - Water droplet panned 40% to the left AND the left channel plays slightly sooner than the right. - Water droplet panned 40% to the left AND the right channel plays slightly sooner than the left. The first example mimics what Godot already does if an AudioStreamPlayer3D if far to your left. To my ears, it sounds like the drop is coming from the center of my head, just slightly to the left. The second example is what I'm asking to be added. To my ears, it sounds like the drop is coming from the far left, providing a much stronger spatial effect than the first. The third example is just here to showcase the difference in "feel" between the panning effect and the interaural effect (the sound is panned to the left, but the right plays first). To my ears, it sounds like the sound is coming slightly from my right, but with something obstructing the sound. _(This is also what it sounds like currently when you use a stereo audio sample with an AudioStreamPlayer3D node, and the directionality of the sample conflicts with the direction of the audio in-game)_ &nbsp; This issue can be overcome through the use of custom scripts, plus separate audio buses and AudioEffectDelays for each AudioStreamPlayer3D. Here's a small partial snippet from a recent project of mine that added this effect in a simplified way: var interaural_delay_effect: AudioEffectDelay # ... ## Update the interaural_delay_effect with the current delays for each ear. ## Note that this implementation always pins the closer ear to 0.0 milliseconds of delay, ## but a physically accurate effect should actually just apply the full delay to each ear. func _update_interaural(listener: AudioListener3D) -> void: const SPEED_OF_SOUND: float = 340.29 const SOUND_SECONDS_PER_METER: float = 1.0 / SPEED_OF_SOUND const SOUND_MS_PER_METER: float = SOUND_SECONDS_PER_METER * 1000 var relative_sound_pos: Vector3 = listener.to_local(global_position) var left_ear_travel_time: float = Vector3(-0.1075, 0, 0).distance_to(relative_sound_pos) * SOUND_MS_PER_METER var right_ear_travel_time: float = Vector3(0.1075, 0, 0).distance_to(relative_sound_pos) * SOUND_MS_PER_METER if left_ear_travel_time < right_ear_travel_time: # Right ear delay is longer, remove left delay, add delay to right. interaural_delay_effect.tap1_delay_ms = 0.0 interaural_delay_effect.tap2_delay_ms = right_ear_travel_time - left_ear_travel_time else: # Left ear delay is longer, remove right delay, add delay to left. interaural_delay_effect.tap2_delay_ms = 0.0 interaural_delay_effect.tap1_delay_ms = left_ear_travel_time - right_ear_travel_time &nbsp; However, I personally think this should be added directly into Godot's built-in 3D audio nodes, because this is the minimum requirement for audio to actually sound 3D, and I think that most users of the AudioStreamPlayer3D and AudioListener3D nodes would be hoping to achieve this kind of directional effect. I'm suggesting this being added as an option just for compatibility reasons, but I don't think the average user would actually want this option disabled. EDIT: Just a quick note because I realized a potential issue with understanding my examples; if you have "spacial sound for headphones" (or whatever it's called on your device) turned on, you'll have to turn it off to properly hear the difference between the examples, because that filter essentially operates by trying to guess at the effect I'm describing :)

Wow! I never thought I'd make my own game, let alone find a bug in the @godotengine 🤯 On Android, after ~600 mouse clicks the game stopped responding to input. Diagnosed, worked around and reported 👇 #GodotEngine #gamedev godot#124965

Godotのクォータニオンの正規化にIEEE-754を見出した話 正規化メソッドを見てみる ベクトルの計算でもおなじみの正規化ですがクォータニオンはコンストラクタを実行するときは大体やっております。 ここは前回取り上げました。 zenn.dev 今回はこちらのクォータニオンの正規化メソッドについてみていきたいと思います。 なお、私は数学がわからないため、あまりそこは深堀せずに見ていきます。 Godot Engineのバージョンは4.8.0 devです。 core\math\quaternion.cpp void Quaternion::normalize() { #ifdef MATH_CHECKS // 有限数であるかをデバッグ時に推測する。 if (!is_finite()) { WARN_PRINT("Quaternion cannot be normalized, the elements should be finite."); } #endif // MATH_CHECKS *this /= length(); } 内積とそれを元にした長さを図るメソッドも実装されております。 計算式の実装 正規化がやっていることは普通に計算なので当然、計算式をチェックしておく必要があります。以下は先に出てきた割り算です。 core/math/quaternion.h constexpr Quaternion Quaternion::operator/(real_t p_s) const { return *this * (1 / p_s); } その実態は掛け算となっており掛け算はこのようになっております。 core/math/quaternion.h constexpr Quaternion Quaternion::operator*(real_t p_s) const { return Quaternion(x * p_s, y * p_s, z * p_s, w * p_s); // 普通に掛け算、合成につながるけど } このように一回の除算で求めた (1 / p_s) の値のことを逆数といい、これを掛ける方式で求めれば単純に高速化が期待できます。 コンパイラのオプションを使って最適化しようとしないの？という疑問が湧きますが以下はマイクロソフトのドキュメントです。 learn.microsoft.com 以下のように書かれております。 注目点はこちらの引用 作成する浮動小数点コードが、浮動小数点ステートメントでの演算や式の順序に依存していない場合 (たとえば、a * b + a * c が (b + c) * a として、または 2 * a が a + a として計算されるかどうかを気にしない場合) は、より高速で効率的なコードを生成できる /fp:fast オプションを検討します。 作成するコードが、演算と式の順序に依存し、かつ、浮動小数点環境にアクセスしたりそれを変更したりする (たとえば、丸めモードを変更したり、浮動小数点例外をトラップしたりする) 場合は、/fp:strict を使用します。 どうも読んでみるとコンパイラは基本的にIEEE-754にのっとった浮動小数点の仕様にのっとって動作しますがコンパイルする際に最適化をしようとすると計算結果が微妙に変わってしまうようです。 それを見ると ゲームエンジン側で予期せぬバグが発生してしまう可能性をつぶすため 逆数を求めてそれを掛けるやり方にすればコンパイラのオプションに左右されることなく計算効率の良さを維持できる これらを踏まえてこのような実装に至ったのかな？と私は推測しております。 次の計算、長さを図る やってることはベクターでもおなじみ、内積で求めた値の平方根を求めるだけ core/math/quaternion.cpp // 内積、ベクトルと変わらない real_t Quaternion::dot(const Quaternion &p_q) const { return x * p_q.x + y * p_q.y + z * p_q.z + w * p_q.w; } // 長さを図るために自分自身の値を内積に適用 real_t Quaternion::length_squared() const { return dot(*this); } real_t Quaternion::length() const { return Math::sqrt(length_squared()); } 正規化自体はベクトルのそれと大差ありません。 有限値であることをチェックするメソッド 一方でこのようなコミットが見つかりました。 github.com/godotengine/godot/commit/db90de4dbdbe2… ここからはこれが実装された背景について考察していきます。 有限値とは桁に限りがあるごく普通の数値全般のことです。 1とか2とか1000万とかあの辺は有限値、お金も有限値ということになります。対になるのは無限です。このメソッドではNaNとInf（無限値）であるかどうかをチェックしております。 core/math/quaternion.cpp bool Quaternion::is_finite() const { // 計算できないNaNであるか無限になっちゃってるかをチェックしている return Math::is_finite(x) && Math::is_finite(y) && Math::is_finite(z) && Math::is_finite(w); } これを突破できなかった場合、このクォータニオンは計算できない代物であると判定されます。MATH_CHECKマクロが有効な時に実行されているのでデバッグのために用意されたメソッドですね。 クォータニオン以外にも有限数をチェックするメソッドが実装され、実際にチェックされています。例えば Vector3 にも実装がされております。 core/math/vector3.h void Vector3::normalize() { // ここにも有限値チェックメソッドが if (!is_finite()) { #ifdef MATH_CHECKS WARN_PRINT("Vector3 cannot be normalized, the elements must be finite. Making (0, 0, 0) as a fallback."); #endif // MATH_CHECKS zero(); // 正規化できないであれば全部ゼロの値にした方がよいという判断 return; } real_t l = length_squared(); if (l == 0) { zero(); } else { l = Math::sqrt(l); x /= l; y /= l; z /= l; } } これはIEEEにて策定された計算式がうまくいかなかったときに返ってくるNaN、Infを回避するために設計されたと私は考えます。 learn.microsoft.com learn.microsoft.com learn.microsoft.com learn.microsoft.com 具体的な仕様としてNaNという計算ができないものが発生した状態でそれを計算するとNaNになるという仕様があります、Infだと多少過程が変わりますが最終的にNaNになるのは変わりません。これで何が起きるのかというとゲームのキャラクターのサイズが勝手にゼロになって突然消滅したり逆に必要以上に巨大化したりしてグラフィックからしてゲームが成り立たなくなる可能性があるのです。 正規化されているかをチェックするメソッド もちろん自分自身が正規化されているかをチェックするメソッドも用意してありました。 core/math/quaternion.cpp bool Quaternion::is_normalized() const { return Math::is_equal_approx(length_squared(), 1, (real_t)UNIT_EPSILON); //use less epsilon } 謎 何故か次のメソッドには件の有限値チェックメソッド is_finite が通ってません。 core/math/quaternion.cpp Quaternion Quaternion::normalized() const { return *this / length(); } あくまであれはチェックなのですが万が一無限数とか計算不能な値が出たらバグが発生してしまいます。自身の内部の数値が変わる際には有限数チェックが入るのですがこちらは呼び出した側で処理を行う際に異常を検知する前提で動くのでしょうか？ 私には判断ができませんでした。 最後に 私は毎週月曜日にGodotのソースコードを読む配信をしております。 以下の再生リストは今回のソースコードを読んだ配信が入っているものです。 youtube.com 良かったら見ていってください。 次回は逆クォータニオンを求めるinverse()のソースコードから入っていきたいと思っております。

[RELEASE] GODOT ENGINE 4.x for Vita (v0.1) Hey everyone! A few days ago, I sharedan update on my PS Vita homebrew projects and mentioned that I'd been working on bringing Godot 4 to the PS Vita. Well... here we are! I'm happy to finally share the first public release of Godot 4 for PS Vita! hehehe The goal is pretty simple: give the homebrew community another way to create new games or port existing Godot projects to the Vita, whether they're open-source or closed-source (as long as you have the necessary rights to use the game files). I've spent quite a bit of time working on the engine itself, especially optimizing the native GXM rendering backend for both 2D and 3D. There's still plenty of work ahead, but I've already managed to get several games running on actual hardware! What's included in this first release? - Godot 4.8-dev7 adapted for PS Vita. - Native GXM 2D renderer, with experimental 3D rendering support. - A portable Windows editor with built-in PS Vita export support. - Export compatible projects directly to VPK, without needing to install VitaSDK, WSL, or additional tools. - Support for Vita controls, analog sticks, touchscreen, audio, and more. - Customizable LiveArea templates and game icons. - Optional separate game data folders, making updates easier. - Experimental trophy integration (still a WIP). - A native animated loading screen. Games I've been working on... These are some of the projects I've worked on while developing and testing the engine, listed from oldest to newest: 1. Dodge the Creeps – My first test project. Basically where it all started. 2. Ambidextro – A more complex 2D project that helped me identify and fix several rendering and performance issues. 3. Tenebrarium – Another 2D port that pushed the rendering backend further. 4. OVERBURDEN – One of my first major experiments with native GXM 3D rendering. 5. Deltarune: Lightners Live Plus – Another project I've been testing with the engine. >I've also been experimenting with other games, including Buckshot Roulette, although that one's still in a very early experimental stage. Some of these projects are already playable, while others still need more work. I'm planning to release more of them publicly as I continue improving the engine. A bit of background This whole thing started because I wanted to build on the work done by SonicMastr, whose Godot Vita port was itself based on contributions from Stary2001 and EIREXE, using PVR_PSP2. Their work was a huge inspiration. I wanted to take things further by bringing Godot 4 to the Vita, improving compatibility, and exploring what could be achieved with native GXM rendering. It's been a pretty challenging project, especially considering the Vita's hardware limitations, but seeing modern Godot projects running on this little handheld has been incredibly rewarding. A few things to keep in mind... This is v0.1, so please don't expect everything to work perfectly just yet. 2D support is already functional for several projects, but some shaders and visual effects are still missing. 3D is even more experimental, and performance will vary depending on the game. Not every Godot 4 project will work out of the box. Some games will require modifications, optimizations, or workarounds. For closed-source Godot games, you might find these tools useful when exploring how a project works: - Decompiling with Godot RE Tools - GDRETools / gdsdecomp Ofc, make sure you respect the original developers' rights and any applicable licenses. Download and Source Code GitHub: WolffsRoom/godot4-psvita Wolff´s Room Discord (for the news): discord.com You can grab the first release, check out the source code, and find instructions in the README. The project is open-source, and contributions, bug reports, testing, and feedback are very welcome! I'd especially love to see what other devs in the Vita community can do with it. If you've got a Godot project you'd like to try porting, give it a shot! Huge thanks to everyone who has contributed to the Vita homebrew scene over the years. This wouldn't have been possible without the work of the people who came before. Anyway, that's it for now! Hope you guys enjoy it, and let me know what you think! :) I'll keep working on compatibility, performance, and the rendering backend. Vita Means Life :) Edit 1: added Wolff's Room discord Servers link

Twine: From Branching Stories to a Browser Game and Godot Twine — turn linked passages into a playable story. In our lighthouse story, bringing tea raises trust. Later, that choice decides whether the keeper shares a secret. ① Publish to File → one HTML file you can play in a browser or host on itch.io. ② Export as Twee → plain text that a game engine can read with a suitable parser. We ran our story in Twine 2.12.1 and Godot 4.3. The Godot parser was written for this episode: it supports only the passages, links and Harlowe macros used here. It is not an official integration or a general Harlowe runtime. What earlier choice would you let a character remember? Twine — 연결한 단락을 플레이할 수 있는 이야기로 만듭니다. 직접 만든 등대지기 이야기에서 차를 건네면 신뢰가 올라가요. 나중에 등대지기가 비밀을 알려 줄지는 그 선택에 달려 있습니다. ① Publish to File → 브라우저에서 열거나 itch.io에 올릴 수 있는 HTML 파일 한 장. ② Export as Twee → 알맞은 파서를 통해 게임 엔진에서 읽을 수 있는 텍스트. 같은 이야기를 Twine 2.12.1과 Godot 4.3에서 실행했습니다. Godot 파서는 이 편을 위해 작성했으며 여기 쓰인 단락·링크·Harlowe 매크로만 처리해요. 공식 연동이나 범용 Harlowe 실행기는 아닙니다. 캐릭터가 어떤 이전 선택을 기억하게 만들고 싶으신가요? Twine · Chris Klimas & contributors · GPL-3.0 github.com/klembot/twinejs/tree/4ebcce6a69c62b1c4… github.com/klembot/twinejs/blob/4ebcce6a69c62b1c4… Harlowe 3.3.9 · Leon Arnott · Zlib Godot 4.3 · contributors · MIT github.com/godotengine/godot/blob/4.3-stable/LICE… Bandersnatch screenshot / 캡처: Wikipedia contributors · CC BY-SA 4.0; emphasis added / 밑줄·굵기 추가 en.wikipedia.org creativecommons.org Site/game-list screenshots have separate rights. 사이트·게임 목록 캡처의 권리는 각각 다릅니다. Story & Godot example / 이야기·Godot 예제: our own / 직접 제작 Curated by instagram.com Publishing / HTML 내보내기: twinery.org

Another #Godot #Multiplayer PR! godot#124801 This one is a whole new Feature I think improves usability. I like Godot's multiplayer a lot, but for Data like "Peer 100 is named Colin", using RPCs, Synchronizers, or Spawners through the Node Tree is pretty unwieldy. #GameDev

High-quality character shadows without increasing shadow atlas resolution (Godot feature proposal) While making a space game I struggled to keep directional shadow quality high for my player while increasing max shadow distance so fairly distant objects dont lose shadows. Tweaking cascades helped but required me to keep increasing directional atlas until 8192x8192 until I got results I could tolerate. But since one of my targets was Quest 3 I had to look for another solution. So I learned about per object shadows where projection fits tightly to the shadow casting object instead of capturing large distances as cascades. Cascades can waste a lot of shadow map space when only a few objects actually need detailed shadows. One of the closest related proposals on Github made by another dev is here: godot-proposals#5841 After some time tweaking the Godot internals, I created a node type ShadowGroup3D. It is an editor node that acts like a container that tracks all meshes inside, excludes them from standard cascades and renders their shadows using a separate projection fitted tightly around those meshes. So if you'd want to get crisp shadows, you'd just create ShadowGroup3D and put your character inside. Where I think it may be useful: - If you're building a mobile or a VR game and want high quality shadows for your characters without being forced to increase your global directional atlas size (doubling the atlas resolution increases its pixel count by 4x). With ShadowGroup3D you'd even be able to actually reduce your current atlas size if the only reason you increased it in the first place was to just make your character shadow look less blurry/shimmery. - Especially in VR where you'd want your character's hands and weapons to cast a really good looking shadow, given that the player can see things up close. - For worlds that want to have shadows at large distances while keeping high quality shadows focused on things that matter: characters, weapons, important objects, npc. - For games aiming for high end graphics standards where you'd want your main character to have the best possible shadow resolution above everything else. - Fighting games where you have 2 characters and want to maximize their shadow quality I haven't done thorough benchmarking yet and my implementation only supports Mobile renderer, however I'm planning to add support for Forward+ renderer as well and make a PR to the Godot repo after some more testing, polishing and refactoring. Video recorded with Godot 4.8 beta (custom build, dev branch). Params shared by all 3 video clips: - Mobile renderer - Sun shadows: 2 cascade splits (PSSM), 80 m max distance, blend splits off - Soft shadow filter quality: Soft Very Low - Shadow blur 1.0, bias 0.1, normal bias 2.0 - 16-bit shadow depth - 4× MSAA Would you like to have ShadowGroup3D as a feature in Godot? Let me know.