得体の知れないものには命名できない
まだ決定ではないけどSubversionを使おうかなぁと考えていた段階で、SSH周りの設定も興味があったので、SourceForge.JPのサーバとの間で通信できるか設定してみようとしました。
が、SourceForge.JP内で参加しているプロジェクトが1つも無いと、設定自体ができませんでした。
そこで、せっかくだからプロジェクト作ってみるかー、と思ったのですが、プロジェクト名が問題に。
以前の記事でMGBとかMRPとか書いたものの、もうちょっとましな名前にしようと画策。しかしなかなかいい名前が出てきません。
なぜなのかを考えてみると、そもそもプロジェクトの構成がはっきりしていませんでした。
思考をまとめるために、とりあえずMGB、MRPという仮の名前で、考えていることをつらつら書いてみます。
MGB
オープンアプリ(auケータイ)／iアプリ(docomoケータイ)／アプレット(Webブラウザ)といったプラットフォーム間の差異を吸収するための基盤です。
実際にはプラットフォーム毎にMGB_o / MGB_i / MGB_aのように実装が分かれますが、これらに含まれるJavaソースファイル名、クラス名、メソッド名などは同じにしておきます。こうすることで、上位レイヤー(MRPなど)のソースを完全に共通化*1できるようにします(あくまで予定)。
なおMGBの上に載せるものとして、MRP以外にもう一つ、できたらいいなと思っているものがあります。(いつになるか分かりませんが……) それは、ゲームではないです。
MRP
RPGを動作させるためのシステムです。これはあくまでシステムであり、ゲーム自体の名前は別になります。
懸念点
- MGBが、ゲームに限らない汎用基盤を目指すなら、それなりの名前に変えたい。(MGBの'G'はGameの意)
- MRPをプラットフォーム非依存にできるとすれば、ソース管理上は1本にしたいが、はたしてそれで使いやすいか。
- MRPもプラットフォーム毎にMRP_o / MRP_i / MRP_aなどとして、そこにMGB_*も含めたほうがよいのでは。
- それならMRPとMGBを分けずに1つのプロジェクトにまとめてもいいのでは。その場合、別アプリを作る際にはMGBに相当する部分を適宜切り出して使う。
- MRPの上に載せるゲーム(のマップ／スクリプト／絵／音など)は、やはり別プロジェクトとして管理すべきか。
などなど……。特にMGBとMRPの境界線が曖昧なせいで、名前も付けられないという現状。
さらに、リポジトリ構成とか成果物のパッケージングを考えると悩みは尽きず。
