GameMaker 日本語掲示板

【動画】GameMaker(2026)についてのライブトーク配信

0 コメント
views

Screaming About/With GameMaker (2026) - TabularElf, Russell Kay, Gleb Tsereteli, Nik Krapivin
https://www.youtube.com/watch?v=bnCplHAWlHw

以下はClaudeによる翻訳と要訳です。AIによる翻訳と要訳であることを留意してお読みください。

2026/05/15

GameMaker コミュニティ配信 詳細要約(約6分)


🔧 プレハブ・マーケットプレイス

プレハブビルダーは現在内部テスト中。これまでプレハブはシェルスクリプトで手動作成していたが、GUIツールとして整備中。スクリプト・マクロ・UIレイヤーのエクスポートに対応しており、ルームのエクスポートは対象外。LTS 26初期リリースには間に合わないが、Q2にプラグインとして公開され、LTS 26.1に統合予定。ベータで先行公開されるため、早めに触ることができる。

マーケットプレイスはEUの決済規制変更や、世界各国の開発者への送金問題(ロシア等へのPayPal送金不可など)から当面開設しない。マーケットプレイスを2年前に閉鎖した際の未払い送金が今も未解決のケースがあるほど、支払い問題は根深い。

代替案としてnpmjsをスコープ付きで参照できるようにする(GameMakerスコープのみ)。TabularElfがGameMaker Kitchen向けの独自レジストリサーバーを構築中で、GitHub認証の導入を検討している。人気の高いコミュニティサーバーはデフォルト登録も検討中だが、公式が特定サーバーを推薦するわけではない。


⚙️ GMRT(新ランタイム)

0.20はLTS直後にリリース。Android正式対応とSwitch(初のコンソール対応)を追加。Switchは自前実装のWebGPUを使用するため、初期は問題が出る可能性が高く、テスターからのバグ報告を歓迎している。次のリリースではデスクトップ向けも追加され、バージョン1.0相当になる予定。

アーキテクチャ面の特徴として、コンパイルの流れは「GML/JS → GMIR(独自中間言語)→ LLVMで最適化 → 実行バイナリ」となっている。VMモードではGMIRをそのまま実行し、ネイティブモードではLLVMを通して最適化したバイナリを生成する。GMLとJavaScriptは同じGMIRを共有するため、最適化の恩恵を両方が受けられる。

パフォーマンスはYYC(ネイティブコンパイル)に近い水準に近づいており、変数サイズの削減(16→8バイト)、整数ループの型推論改善、未使用関数のリンカレベルでの削除などを実施済み。現状ではまだ「低い果実を取っている段階」であり、今後さらに大きな最適化が控えている。GMLの1命令が現行VMでは約10,000アセンブリ命令、YYCで約1,000命令に対し、GMRTでは数十命令を目指している。

LTS期間中の方針として、現行ランタイムに対するバグ修正はGMRTにも並行して適用し続ける。GMRTが現行ランタイムを完全に置き換えるのはLTS 26の2年間のサポート終了後。

ソースコード公開については、コンパイラ・ランタイム・ツールチェーン含めて公開予定。コンソール向け部分はNDAの関係で完全オープンソースにはできないが(MITやApacheライセンスは採用できない)、ソース参照・コントリビューション可能な形にする。HTML5ランナーと同様の「ソース利用可能」な形式になる予定。


🌐 新言語サポート

なぜ複数言語を追加するか:GMLという独自言語が原因で教育機関や業界からの採用を妨げているケースがあるため。ただしGMLはなくならず、引き続き開発継続。GMLv3についてはコミュニティと共同で設計する予定で、それまでGMLへの新機能追加は行わない。

  • JavaScript:独自コンパイラ実装でGMIRに変換。GMLとの相互呼び出し可能で、オブジェクトイベントでも使用できる
  • TypeScript:JavaScript後にリリース。GLIDL(GameMaker Interface Description Language)を使って型安全なバインディングを自動生成する仕組みを開発中。現時点でも手動でコンパイラを組み込めば動作確認はできる
  • C#:.NETランタイムをそのまま使用。現時点ではスクリプトのみ対応で、オブジェクトイベントに直接書くことはできない。C#のオブジェクトモデルとGameMakerのインスタンスモデル(selfとthisの違い等)が相容れないため
  • C++:翌年以降に検討。クロスプラットフォームのハッシュインクルードや32bitシステムコール問題など課題が多い

npmパッケージについてdocument等のブラウザAPIやNode.js固有の機能を使うライブラリは動作しない。文字列・配列ライブラリや正規表現など純粋なJavaScript機能のみ利用可能。つまりnpmをベースにしていても、すべてのnpmパッケージが使えるわけではない。

言語間の相互運用:どの言語で書かれたコールバックでも、受け取り側の言語は意識せずに呼び出せる。マーシャリング(型変換)は自動的に行われる。プレハブも言語を問わず使用可能で、内部実装を意識せずに外部インターフェースだけを使えばよい。


🏗️ シーングラフ・コンポーネント設計

現在のスプライトはコリジョン・アニメーション・オフセット・Spine・SWF・SVGなどをC++レベルの一つの巨大クラスに詰め込んだ「モンスタークラス」になっている。これをシーングラフのノードとして分解し、コンポーネントを自由に組み合わせられる設計に移行する。

具体的には:

  • 九スライスのビットマップ、コリジョン形状、スケルトンアニメーションなどがそれぞれ独立したノードになる
  • オブジェクトにシーングラフをアタッチでき、そのグラフ内に任意のノードを配置できる
  • ユーザーが独自ノードを作成してシーングラフに組み込むことも可能になる

これにより長年の懸案事項が解決される:

  • スプライトへのアタッチポイント(最多要望機能)はシーングラフ上の名前付きポイントとして実現
  • コリジョンの無効化は「コリジョンコンポーネントを持たない」ことで自然に解決(現在は空スプライトを使う回避策が必要)
  • Spineなどサードパーティアニメーションも独立したモジュールとして管理でき、アップデートのたびにコンパイラ・ランナー全体を更新する必要がなくなる

🎮 3D対応の方針

「3Dエンジンになる」わけではなく、アイソメトリック・2.5D・法線マップ付き2Dゲームといった「3D要素を使う2Dゲーム」を作りやすくする方向。GameMakerのDNAは「使いやすさ」であり、それは変わらない。ただしビットマップ主体からベクター・3Dモデルベースへと移行していく。

近い将来(コードAPIとして)提供されるもの

  • glTF/glbモデルのロード・アニメーション制御
  • 3D数学関数(行列・ベクトルなど、構造体として実装。内部的には16要素の値を持つ)
  • シェーダーにSlangコンパイラを採用(HLSL・Slang入力 → WGSL出力)。#includeやヘッダーファイルにも対応予定
  • デバッグオーバーレイでの3Dシーン可視化ツール
  • 法線マップのサポート:ビットマップコンポーネントと法線マップコンポーネントを組み合わせる形で、UVの手動管理が不要になる

カメラについても複数カメラの作成が可能になり、2D・3D両方に使えるカメラとして整備される。

Blender連携:3Dモデル作成は外部ツール(主にBlender)で行い、インポートパイプラインを大幅改善する方針。BlenderはPythonベースで連携しやすく、blendファイルの変更をIDEにリアルタイム反映する仕組みを検討中。blend・PNG・SVGなどを一元管理できるリアクティブなインポートパイプラインが目標。

ルームエディタへの統合は数年先。3D専用のポリゴンエディタは作らず、あくまで外部で作成した3Dコンポーネントを配置・スケール・変換できるツールとしての位置づけ。


🏠 新ルームエディタ

現行のエディタとは根本的に異なる再設計であり、「現行エディタに毛を生やしたもの」ではない。

主な変更点:

  • ルームはシーングラフのルートノードとして扱われ、ルームの内容(レイヤー・オブジェクト等)はすべてシーングラフに
  • レイヤーはシーングラフのノードになる
  • 複数ルームを並べて同時に表示・編集可能(シームレスな接続確認が容易に)
  • ルームを別ルームに配置するネスト構造が可能(Room Loader的な機能が組み込まれる)
  • ルームには概念的な幅・高さ・位置があるが、その外側に置いたオブジェクトも編集可能
  • タイルマップが部屋全体を覆わなくてもよくなり、部分的な配置・移動が可能に
  • ビューポートとカメラの設定がルームに紐付かなくなる
  • トリガーゾーン(ポリゴン形状の当たり判定領域)もレガシーサポート終了後に追加予定

インスペクターについては現在も改善が進んでいるが、まだUXの課題が残っている(例:ルームエディタを離れてもレイヤービューが消えない等)。今後はエディタの数を減らしてインスペクター中心のUIに移行し、一貫性を高める方針。


⏱️ タイムソース・時間管理

レガシーサポート終了後にタイムソース機能を拡張。デフォルトで「ウォールクロック(実時間)」と「ゲームクロック」の2種類を提供し、ユーザーが派生クロックを自作することも可能。

オブジェクト・シーケンスごとに異なるクロックを割り当てることで:

  • ゲームクロックを止めるだけでポーズが実現(ポーズメニューはウォールクロックで動き続ける)
  • 特定エリア内のオブジェクトだけスローモーにしつつ、プレイヤーは通常速度
  • オーディオのピッチ変更なども同じ仕組みで対応
  • 「ゲームクロックが停止している間もdelta_timeが前回のステップ値を保持する」ため、ゼロ除算などの問題も考慮された設計になる予定

現状ではゲーム開発の後半でスローモーを追加しようとするとゲーム全体の書き直しが必要になるケースが多く、この機能により大幅に解決される。


🌐 マルチプレイヤー

現在はPhoton・Calyssious・Steamworks・Namazu Elementsなどのエクステンションでサポート。完全な内蔵実装はレガシーサポート終了後。

内蔵実装に向けての課題:

  • オブジェクトの状態差分(スナップショット)を効率的にシリアライズするインフラが必要
  • ロールバック方式・状態同期方式の両方にこのインフラが必要
  • 現行GameMakerはドロー・ステップイベントの制約が緩すぎてルール強制が難しく、旧ロールバック実装の失敗の原因になった
  • 将来的には「ネットワーク対応オブジェクト」と「非対応オブジェクト」を明示的に区別できる仕組みを導入(Unrealのレプリケーションフラグ・Unityのネットワーク属性に相当)
  • ロールバックはユーザー目線ではシンプルに使えるものを目指す

📝 テキストレンダリング

draw_textは残るが(毎フレーム文字列を再処理する非効率な実装のまま)、新たにMarkdown対応テキストオブジェクトを開発予定。Scribleに近い設計で:

  • テキストオブジェクトを一度生成してレイアウトを確定させ、変更がなければ毎フレーム再計算しない
  • Markdown(拡張版)で色・スタイル・スプライト埋め込みが可能
  • レイアウトオブジェクトから個別グリフの位置を操作でき、波打つテキストや揺れるテキストなどのエフェクトが実現可能
  • レンダリングとレイアウトが分離された設計

🤖 AI・CLIツール

AIについて:OperaはAI全面推進の会社だが、GameMakerチームとしてはIDEへのAI組み込みは行わない方針。すべて任意・Bring Your Own AI。プレスリリースを「GameMakerがAI特化エンジンになる」と誤解したクリックベイト記事が多数出たが、完全に誤り。AI機能ではなく、CI/CDや自動化のためのCLIツールが本質。

GM CLIについて:スクリプトでプロジェクトを操作(リソース追加・変更など)できるツールで、フォント追加など機能を拡充中。GUIなしにGM CLIとNotepad++だけでプロジェクトを構築することも技術的には可能。リソース操作ツールのリポジトリも近日公開予定。デバッグモードやデバッグAPIの公開は現時点で計画なし(GMRTではVisual Studioでのネイティブデバッグが可能)。


🏷️ GMLビジュアル(ドラッグ&ドロップ)

内部的に大きな改善はしない方針。現在は巨大な1つのXMLファイルで構成されており、これを複数ファイルに分割してドキュメント化し、コミュニティが独自ブロックを追加できるようにすることを検討している。プレハブへの組み込みも検討中。利用者が少なく優先度は低いが、コミュニティからのコントリビューションは歓迎。


🔴 ライブリロード

レガシーサポート終了後に実装予定。IDEからゲームを実行中に、コード・アセットの変更をリアルタイムで反映する機能。ただし以下の制約は残る:

  • 新変数を追加した場合、既存インスタンスはその変数を持たないためクラッシュの可能性あり
  • 初期化コード(ルームスタート・ゲームスタート)の再実行は行われない
  • IDE外部からの実行(スタンドアロン)には対応しない

📦 物理エンジン・ECS

物理エンジンについては、特定のエンジン(Box2D・Jolt等)に縛られない、差し替え可能なモジュール設計を目指している。物理コンポーネントをオブジェクトに付け外しできる形になることで、現在のような「物理プロパティがオブジェクトに直接紐付いている」状態から脱却する。

ECS(Entity Component System)については「レガシーサポート終了後にノーコメント」としつつも、コンポーネントシステムが整備されれば設計パターンとして自然に使えるようになる見込み。現行ランタイムでECSを実装すると変数アクセスに複数のジャンプテーブルが必要でオーバーヘッドが大きいが、GMRTでは大幅に改善される予定。


💰 ライセンス・リリース形態

  • ライセンス体系の変更なし
  • 既存のプロフェッショナル・エンタープライズライセンスはGMRTでも有効(ただしアクティブなサブスクリプションが必要。コンソールリリース中は有効なサブスクリプションを維持する必要あり)
  • GMS2ライセンスのみの場合、LTS 26サポート終了後は有料リリース不可(無料リリースは引き続き可能)
  • 未アクティベートのGMS2エンタープライズコードはアクティベートが必要
  • LTS 26はSteamで別製品(別App ID)として提供予定。月次版と設定・ランタイムフォルダが分離される
  • LTS 26がメインダウンロードとなり、Webサイトからもこちらが案内される

📺 コミュニティへの発信

内部開発者による技術的な解説ストリームを検討中。候補トピック:

  • ゲームのポーティング方法
  • UIレイヤー・フレックスパネルの活用法
  • シーケンスの使い方と考え方
  • プレハブの作り方
  • 不要アセットの整理方法

コミュニティからの要望はGameMaker Discord・Reddit・GameMaker KitchenのスレッドでRussell氏に伝えることができる。地域ごとのGameMakerミートアップも世界各地で開催中で、地域担当者を募集している。

asa
作成: 2026/05/15 (金) 11:28:35
通報 ...