【cluster】外部通信するクラフトアイテムの開発ノウハウ（１）・・・概要編
第１回、概要編です。
※ プログラミング初心者向けの解説ではなく、ほどほどに開発経験がある方に、自分の事例などを紹介するシリーズ記事です。
（N&C's べいべー誕生を勝手に祝って贈るシリーズ記事です）
cluster、ワールドクラフト、クラフトアイテムとは
国産メタバースプラットフォーム cluster には、Minecraft に代表されるようなクラフト系ゲームアプリに似た操作で、一般ユーザーがメタバース空間（ワールド）を自由に作成することができる「ワールドクラフト」という機能があります。
ワールドクラフトでは、最初は何もないバーチャル空間に「クラフトアイテム」と呼ばれる３Dオブジェクトを自由に置いていくことができます。クラフトアイテムは、単なる静止オブジェクトから、振る舞いを Javacript で定義された動的なオブジェクトまで、多数のクリエイターが制作したものが大量に用意されていて、アプリ利用者は誰でもそれらを無料または有料で入手して利用することができます。
クラフトアイテムを制作して公開するには？
クラフトアイテムを制作～公開するには、Windows か Mac が動作するパソコンと、cluster 社が配布している CCK (Cluster Creator Kit) を導入した Unity というソフトが必要です。CCK と Unity は無料で入手できます。
制作したクラフトアイテムは cluster にアップロードすることで、自分がワールドクラフトする時に利用できるようになります。また、アップロードしたクラフトアイテムを「ワールドクラフトストア」に商品として登録することで、他のユーザーが購入したり、アプリ内のポイントでチケット交換して入手したりできるようになります。
アイテムが外部通信するための callExternal API
３Dオブジェクトの振る舞いを Javascript で定義できると紹介しましたが、利用できる API は Cluster Creator Kit Script Reference で定められています。
その中には cluster アプリ内から外部（クリエイターが別途用意したインターネット上の API）に通信（リクエスト送信）するための callExternal という関数と、その応答（レスポンス）を処理するコールバック関数を登録するための onExternalCallEnd という関数があります。
https://docs.cluster.mu/script/interfaces/ClusterScript.html#callExternal
これらを利用することで、cluster の外にあるデータやロジックによって３Dオブジェクト（アイテム）の振る舞いを制御することができます。
通信先（外部サーバー）をどう作るかが問題
ドキュメントにある通り、開発者自身が外部のサーバーを用意する必要があります。
cluster 公式のクリエイターズガイドにはサンプルを含む解説記事があります。こちらの「サーバーを用意する」セクションには、Google App Script (GAS) で通信先を作る方法が紹介されています。
この GAS を使う方法は「誰でも手軽に無料で試せる」という大きなメリットがある一方で、自分以外のユーザーに使ってもらう製品として使うには以下のような問題があって、本格的な実用に即した方法ではありません。
GAS は合計実行時間の上限がある。（使いすぎると動かなくなる。）
データベースの代替として Spreadsheet を使うがゆえに、データ件数の増加や処理の複雑化によって応答に時間がかかるようになり、5秒のタイムアウト上限を超過してしまう可能性が高い。
通信先（endpoint）の URL はアイテムクリエイターひとりにつき1つしか登録できない仕様上、1つのGASトリガーに様々なアイテムからの要求を処理するロジックを詰め込まざるを得ず、管理の複雑化やソースコードの肥大化による処理性能の低下に対して有効な対策をとるのが困難。
サーバーを用意する、あるいはクラウドサービス（AWSやGCP）を使う
個人が「サーバーを用意する」というと、昔であれば「レンタルサーバーを借りる」か「自宅でサーバーを運営する」しかありませんでしたが、いずれにせよ必要な知識やノウハウが多岐にわたります。
すでにサーバーを所有している（自由に使えるサーバーがある）場合はそれを使ってもよいのですが、そうでなければ、クラウドサービスを利用するほうが比較的ラクだろうと思います。
具体的には、Amazon が提供する AWS (Amazon Web Services) や Google が提供する GCP (Google Cloud Platform) のアカウントを作成し、それらのサービスである AWS Lambda や Google Cloud Function を利用することになります。
私の場合は AWS のクラウドサービスを使っています
私の場合は、AWS が提供する SAM (Serverless Application Model) という仕組みを使っています。
SAM を使うと、必要なリソース（サーバーやデータベース）の手配や、それらを実際にインターネットから使えるようにするための多岐にわたる設定の大部分を自分でやらずにシステムに任せてしまうことができます。
用意するのは、有効な AWS アカウント、SAM の設定ファイル、そして実際に動かしたいプログラムのソースコード（Javascriptファイル）です。
書いたプログラムを実際にサーバー上で動く状態にする（AWS の環境にデプロイする）には `sam deploy` コマンドを実行する必要があるのですが、私の場合は GitHub Actions を使ってその作業を自動化してあります。
継続可能にするため、サーバー運用コストを熟慮すること
サーバーの運用には相応のコストがかかります。
レンタルサーバーであれば、月額料金が決まっているのでコストを見積もりやすいですが、必ず固定で費用が発生します。必要なスペックを考えて選定するのも意外と難しいです。
クラウトサービスであれば、実際に使った分だけ従量制で費用が発生します。固定費がかからないので一定ラインまでは安く使えますが、それを超えると青天井で費用が発生する可能性があります。赤字にならないようにするためには、作るアイテムがどのくらい通信してどのくらい利用されるかをしっかり計算して、リスクを受け入れられるかどうかを考えましょう。
プログラムは TypeScript 言語で書くのが便利
サーバー上で動くプログラム（Lambda 関数）は、様々なプログラミング言語で書くことができますが、クラフトアイテム内で動作するプログラムと並行して開発する都合上、共通言語である Javascript を使うのが便利です。
Javascript のコードを作成するには、自分自身が生の Javascript を書く方法と、別の言語で書いたソースコードを Javascript に変換する方法があります。
近年は圧倒的に後者が支持されていて、よほど簡単なプログラムを書く場面でなければ、TypeScript 言語で開発することが実質的なスタンダードになっています。TypeScript 言語は「Javascript 言語にちょっと毛が生えた程度の」言語なので、Javascript を書ける人であれば簡単に習得できるものですし、その手間を補って余りあるメリットがあります。（不用意なコードが減り、バグによる手戻りが激減し、開発効率が格段に高くなり、ストレスが激減します。）
先述の Cluster Creator Kit Script Reference （アイテム用スクリプトの公式APIドキュメント）も TypeScript で開発することが想定された記述が見受けられますので、お試しから一歩先に進んで本格的に取り組む際には TypeScript を採用すると良いと思います。
エディター（IDE）の支援をしっかり受けられるように開発環境を整える
Visual Studio Code (VSCode) は無料で使えるエディタとしてはとても良くできていますね。入力補間や文法・スペルチェックはもちろん、拡張機能で静的解析ツールを導入するとより捗るでしょう。
個人的には JetBrains 社の IDE (PyCharm, PHP Storm, Rider など) を愛用しています。TypeScript で型を導入したうえで IDE の強力な支援を受けられれば、不用意なバグの多くはタイピングしている時点で指摘してくれますし、最近はさらに AI によるコードの提案もしてくれるようになって、捗り具合がやばいです。
git と GitHub を活用する
ソースコードのバージョン管理に git を使うことで、ソースコードの履歴管理ができ、「間違っても任意時点まで巻き戻せる」という安心感があるので、試行錯誤がしやすくなります。またソースコードを GitHub にアップロード（push）しておけば、バックアップにもなって安心です。
さらに、GitHub には Actions という便利な機能があります。これを活用すると、サーバーで動かしたいソースコードを書いて GitHub にプッシュするだけで、サーバーにデプロイ（実際に動く状態に）する作業を自動化したりできます。
実際のアイテムのコード例
続編記事に続きます。
この記事が気に入ったらサポートをしてみませんか？