最近の CustomCrafterAPI の動向と今後の方針

Maven で配信開始

プロジェクトの依存関係として使いやすいように Maven Central に置きました。 向こう 10 年間有効な PGP 鍵を発行してあれこれしたので忘れないようにどうしようかなと思っているところ。

たまにバグが存在するバージョンを配ってしまうので、そのときには p<数字> を末尾につけたバージョンを発行することで対応しています。
出しちゃったらゴメンね。

Context を乱用

ResultSupplier や *Predicate インターフェースのような「処理を利用側で書く必要があり、なおかつ背景情報が必要な場面」に Context という名前のクラスを提供しがち。
本当はちゃんとそれぞれ名前をつけてあげるべきなんだろうけど、ネストクラスにすればだいたい 親.Context みたいな感じで使うだろうから大丈夫か！と Context 一筋でやらせてもらってます。

Java 系アノテーションの追加

Java から利用しやすいように JvmStatic, JvmOverloads などの相互運用向けのアノテーションをつけて回る作業をしました。
CustomCrafterAPI って Java からも使えるんだよ！

勝手に DI 化が進行していた

DI というのは Dependency Injection (依存性注入)の略です。
CustomCrafterAPI を設計していた当時は「インターフェースって今まであんまり使ったことないし、今回はいっぱい使ってみるか〜」くらいのノリでレシピの重要なコンポーネントなどをインターフェースで定義していたのですが、開発をし続ける中で過去の自分に感謝する場面がめっちゃ増えてきたのでおすすめです。
インターフェースを適切に定義できれば内部の処理の共通化が楽だし、利用側での拡張も楽といいことづくめでした。

当初の謎命名を改名

定形・不定形レシピをそれぞれ Normal, Amorphous として列挙型で管理していたのですが、なんとも分かりづらい上に本家 Minecraft が Shaped, Shapeless をレシピのクラス名に採用しているのを見て改名しました。
作成しはじめの頃に「形のないもの、って意味のかっこよさげな単語ないかな〜」と調べて命名した Amorphous ですが、コードはかっこよさよりもわかりやすさが言わずもがな重要ですのでこんな命名をしてはいけません。

クラフト画面のカスタマイズ機能を作成

CraftUIDesigner というインターフェースを作成してクラフト画面をいじれるようにしました。
特に要望などがあったわけではないですが、プラグインの名前に Custom と入っているんだから、構成要素はなるべくカスタムできるようにあるべきだよなと思い立って作成しました。
活用してくれると嬉しい。

公開場所を追加

GitHub のリリースだけでは多くの人に使ってもらえないなと感じ、 Paper-Hangar と Modrinth での公開を開始。
この記事を作成している段階で合計 80 ダウンロードくらいだが、以前よりは格段にダウンロード数が増えた。
自分で言うのもあれかもしれないが、CustomCrafterAPI はかなり便利なので色んな人に使ってほしい。まじで、切実に。

非同期化

正直これは結構大きい変更だと思う。検索とレシピ作成の 2 箇所を非同期対応させました。
定形レシピの方はともかく、不定形レシピは内部で組み合わせ問題を解くエンジンを利用している関係でどうあがいても 1 tick 以内に処理を終えることができなかったので、非同期化を決意して実装しました。
とは言っても CustomCrafterAPI で行う判定はほとんどが非同期で実行しても問題ないものだったので、当初ぼんやり想定していたよりは移行コストは低かった。
この変更によって、検索時間を 50ms 以内に収める必要がなくなり DB からプレイヤーのデータを持ってきてそれを判定に活用するといったことがやりやすくなりました。

ただワールドやプレイヤーに関する情報を取得する場合はそのまま呼び出すと Bukkit に「おい非同期スレッドから触ろうとしてんじゃねーよ！」と怒られるので Callable から呼び出すようにしてね。
そのための拡張関数も作成したので活用してね。

検索などを非同期化したのでもちろんですが UI も非同期化を導入しました。
まさか Minecraft のインベントリ式 UI に非同期描画なんて言葉を使う日が来るとは思ってもいなかった。

MCKotlin 必須化と Java 化断念

これは最近の動向とこれからの予定が半々になった話題ですが。
CustomCrafterAPI は Kotlin で書かれているけども、 Paper などは Java で書かれていて Kotlin の標準ライブラリが実行環境に用意されていない。
しかも様々なプラグインがそれぞれ異なるバージョンの Kotlin を FatJar として持ち込んでくるかもしれない。
こんな面倒くさい問題から目を背けるために MCKotlin という前提プラグインを導入してもらって、面倒な Kotlin 標準ライブラリの準備をしてもらうことにした。
本当はこんなユーザー側の手間が増えてしまうようなことはやりたくなかったけど、Kotlin から離れられなくなってしまった以上、これ以外の選択肢がなかったので泣く泣く選択。

Java 化断念もこれにつながる話で、Java 化と大層なことを書いているけども実際のところは関数の引数、返り値すべてで Java の型や記法を利用して、 Kotlin の依存関係を内部だけに閉じ込めてしまい Kotlin 標準ライブラリまわりの問題を解決してしまおうという話のこと。
思いついた当初はなんて良い案なんだと思っていたけれど、いざ少し実装してみると思っていた以上に Kotlin の機能を外に出すことができないというのはきついもので、あえなく断念してしまったという流れ。
前述の問題を解決した手法があれば採用して Kotlin の依存関係周りをスッキリさせたい。できるのかな。

今後の方針

CustomCrafterAPI は今の所ベータバージョンとして展開しているのでバンバン変更を入れてきたし、これから少しの間はそれが継続すると思う。
しかしある程度したらそれも落ち着くだろうし、何よりコア開発者である私がこれまでに比べてあまりコードを触れなくなってしまうこともあってそろそろ安定版を出すまでのロードマップなどを作成したほうが良いのか、などと考えている段階にある。
現時点でやろうと考えていることは Folia サポートくらいだが、使ってくれた人からのフィードバックや私の思いつきで増えていくかもしれない。
とにかく、今後どこかのタイミングで安定版に移行してリリース頻度が減少するだろうと言及するにとどめておく。
開発に携わりたいです！という人がいれば私はいつでも歓迎するので、臆せずどんどん貢献してほしい！！！まじで！！！

ただ、リリース頻度が減少しようとも、 CustomCrafterAPI はプレイヤーのより良いゲーム体験のために奔走する運営や開発者の味方になれる存在でありたいという精神で開発されていることには変わりないのでよろしくお願いします、といったところ。

2026/01/10 坂木啞ルカ