もう連休も最終日ですね。

5月6日。15:00。

ちょっとブルーな気持ちになるときです。

毎年、GWといえば。

箱庭開発まつりです。

ぼくは、どこにもいきません。

ただ、ひたすら、

「箱庭を開発する。」

仕事ではなかなか踏み込めなかった、技術の極（きわ）へ。

Godot（ゴドー）

ここ数ヶ月、週末、すこしずつ、箱庭の Godot 対応をしてました。（ひっそりと

そして、やっと、一気に進捗爆速させる機会がきました。

はい。

ごーるでん、うぃーくですーー！（待ち望んでたやつ

箱庭ラボにとって、Godot対応はMUST要件ではありません。

だからこそ、ぼくは自分に縛りをかけていました。

「それ、仕事じゃないよね？」

ってね。

制約と誓約。

ゴンとかクラピカのやつです。（←ハンターハンター

やりたい、やりたい..。でも、がまん。
ずっと耐えてきました。

思い返せば。

いつものやつです。

朝、目覚めた時に、とつぜん、降ってくるやつ。

「あ、Godot と MuJoCo と箱庭を接続したチュートリアル、やらんと」

ってね。

でも、箱庭ラボのビジネスの中では、
これは、まぁ、
「趣味の世界のはなし」
です。

箱庭ラボも、そろそろ自立して独り立ちする時期です。

そんな時期に、

「遊んでばっかりいちゃダメでしょ。」

っていう心の声が聞こえてきます。

はい。
いつも鳴り響いています。

（もう、ほっといてくれ。

でも。

考えてみるとですね。（←いいわけが始まります。

箱庭って、ぼくの趣味から始まったわけで。（←いや、その原理主義やめろ

でも、ほんとうにそうなのです。

最初から、ビジネスとして、設計されたものではありません。

「箱庭って、こうだよ！」

「こんなふうに、きれいに設計したい！」

「いろんな技術組み合わせて！」

とかとか。

やりたいことを、やりたいように。

でも、かなり真剣に。（ｷﾞｷﾞｷﾞｷﾞ

だから、箱庭にとって「趣味」は、ただの寄り道ではありません。

むしろ、源泉です。（←かんぜんに、自己正当化

動いた！

(Godotで動いた瞬間の動画)

思い返すと

きっかけは、hakonwia-pdu-endpoint のPython 対応やり始めたときだったと思います。

これ、ほんとうに、ぼくのお気に入りでして。

これまで、ずっと言ってきました。

PDU は通信を隠蔽します。
ROS IDL ベースでデータ構造を定義し、通信方式に依存しない形でデータを扱えるようにします。
箱庭では、それを使って、シミュレータや制御アプリや可視化アプリをつなぎます。

いろんな人に、いろんな場所で、そう語ってきました。

でも、正直に言うと、まだ実装が追いついていませんでした。

だから、これをようやく形にできたことが、すごく嬉しかったのです。

Python 対応をやるなら、C/C++ の実装を Python から安全に呼び出せるようにしたい。

それなら、cffi が良さそうだ。

でも、やるなら Windows にも対応しないといけない。

そして、そこまで来たところで、

えー！

「そんなら、
　ついでに
　Godot 対応もやっちゃう？
　」（←こころの声

やろう。（←もう決まりです

いまは、AI時代です。

昔のように、全部を自分の手でコーディングすることは、かなり少なくなりましたよね。

自分のリポジトリを読み込ませる。
やりたいことを伝える。
必要なら、タスクリストや設計ドキュメントを作ってもらう。
方針が怪しければ、議論する。
実装案を出してもらい、レビューして、修正する。

あとは、指示するだけ。

……と言うと、すごく楽に見えます。

でも、実際にはそうでもありません。

ぼくが決めないとい局面も出てくるわけで。

たとえば、

• 箱庭の PDU 定義は、GDScript or C# ？
• メッセージ実装は全て同梱型 or 共有ライブラリで分離？
• ユーザ提供形態は？

などなど。

さらに、

hakoniwa-pdu-registry

です。

このあたりは、たしか 2 ヶ月前。

GDScript ベースの
PDU データ型定義と、
変換スクリプトを作成してもらいました。

たぶん、喫茶店でカレーを待っている間にできた感じです。

カレー注文してから、届く前までの間に、
スマホで指示しながら…。

いや、あのときは焦りました。

ただ、その時点では、
まだ「部品」ができただけだけで、
なんも動きません。

PDU の GDScript 定義はある。
変換スクリプトもある。
Godot から扱えそうな感じだけする。

ゲームエンジンに組み込む

以前の日記でも少しお話ししましたが、Unityに箱庭を組み込むことをやってました。

その経験から、だいたい、ゲームエンジンに箱庭を組み込むためのノウハウはあったので、
codexと議論して、
あーだ、こーだとなり、
設計ができました。

で、その設計をドキュメントにして、あとは、

「コーディングとスモークテスト」

お願いします！

それだけ。

……と言うと、本当に丸投げしているように見えますが、

ときどき、ちゃんとデバッグしたり、コード眺めたりはします。

でも、Unityで初めてゲームエンジンと格闘していた時の苦労はなくなりました。

本当に、時代の流れは・・・

ありがたいですけど、
「これでいいのか」
という、戸惑いはいつもあります。

今日はカメラセンサ作ってました。

さいきん、本当に、境界といいますか。
モート、つまり「堀」といいますか。

そういうものが、どんどん低くなっている気がします。

散歩しながら、ChatGPT に聞いてみました。

「センサーシミュレーションって、もしかして、もうコモディティ化してない？ この時代」

って。

たとえば、
カメラ。
Depth。
LiDAR。
IMU。

昔なら、それぞれをシミュレータに組み込むだけでも、かなり大変でした。

カメラなら、レンダリングパイプライン。 
Depth なら、深度画像の扱い。 
LiDAR なら、レイキャストやノイズモデル。 
IMU なら、加速度、角速度、座標系、ドリフト。

それぞれに専門知識が必要でした。

でも、いまは、その境界がほんとうに低くなったなと。

だから、GW最終日は、カメラセンサー、スキーマをSDF風に定義して、MuJoCoで実装してやろうと。

１時間程度できちゃいましたね。

本当にすごい時代です。

対応したのは、

• Depthカメラ
• RGBカメラ
• RGBDカメラ
• ステレオカメラ

スキーマを定義してしまえば、要件はかなり決まります。
あとは、インタフェースをヘッダで作らせて、実装する。

そんだけ。

……と言いたいところですが、もちろん、それで全部終わりではありません。

ただ、昔に比べると、「まず動くところまで持っていく」までの距離は、ほんとうに短くなりました。

しかも、面白いのはここからです。

ぼくは、Depth カメラのことを、実はそんなによく知りません。

実装が終わってから、ChatGPT に聞きました。

「で、Depth カメラって、要するに何なの？」

と。

順番が逆です。

でも、いまは、それができてしまう時代なんですよね。

これが、その一枚絵です。

たぶん。

おそらくなんですが。

これからの時代、どれだけ技術を知っているかっていうのは、あんまり価値にならない気がしてきました。

いや、もちろん、知らなくていいわけではありません。

基礎は大事です。
原理も大事です。
実装を読む力も、デバッグする力も、まだまだ大事です。

でも、単に「知っている」ということの価値は、どんどん下がっていくのだと思います。

カメラとは何か。
Depth とは何か。
LiDAR とは何か。
IMU とは何か。

そういう知識は、聞けばかなりの精度で返ってきます。
実装の雛形も出てきます。
スキーマも作れる。
インタフェースも作れる。
テストの方針も出せる。

では、人間に何が残るのか。

たぶん。

「あそぶこと」

今日が、まさにその日でした。

おしまい。