# J2MEのゲームを移植する > Java MEのゲームは176x220の画面、数字のキーパッド、数百キロバイトのヒープで動いていた。移植はほぼ拡大と再設計だ。 - URL: https://www.summerengine.com/ja/port-a-j2me-game - Keyword: J2MEのゲームを移植する - Related: https://www.summerengine.com/ja/porting J2MEのゲームの移植とは、権利のあるJava MEのMIDletを、今も存在するハードウェア向けに作り直すことだ。Java MEのランタイムは消費者の端末から消えているので、元のJARはJ2ME LoaderやFreeJ2MEのようなエミュレーターでしか動かない。 これらのゲームは、もう当てはまらない制約の下で作られた。画面はよく128x128か176x220だった。ヒープは一メガバイトを切ることが多かった。ゲーム全体が数百キロバイトのJARとして出荷され、その隣にJADの記述子があった。入力はソフトキーを伴う数字のキーパッドだった。コードはMIDP 2.0とCLDC 1.1を対象にし、音と3Dの任意のAPIは端末によって違った。 その制約の一つひとつが、移植では設計の判断になる。ドット絵は小さく精密で、整数倍の拡大で美しく伸びる。コードは一日で読める程度に小さい。ゲームループは低い固定のフレームレートを前提にしていた。Summer Engineはそれを、Steamやitch.io向けのデスクトップビルドを書き出せる自分のものであるプロジェクトとして作り直す。 ## JARからコンテンツを取り出す JARはZIPのアーカイブだ。自分のファイルを展開すれば、PNGのスプライト、タイルマップ、レベルのデータ、MIDIやWAVの音声は、たいていそのままの形で入っている。コンパイル済みのクラスはデコンパイルして元のロジックを読める。これは自分が書いたか明確にライセンスを持つゲームなら正当な行為だ。JADのファイルも取っておく。MIDletの名前、版、ゲームが対象にした端末のプロファイルが記録されているからだ。それが元の画面の大きさとAPIの前提を教えてくれる。 ## 画面の大きさが最大の変化だ 176x220の縦長のキャンバスは、現代の表示のごく一部だ。二つの方針から早めに選ぶ。元の解像度を保ち、整数倍の拡大と最近傍のフィルタで引き伸ばす方法は、アートを正確に保ち上下左右に黒帯が付く。もう一つは、アートを描き直して高い解像度で作り直す方法で、商用の再リリースに向く。どちらにせよピクセルの格子は正直に保つ。これらのスプライトは一ピクセルずつ描かれており、どんな平滑化もそれを壊すからだ。 ## キーパッドの入力はタッチかゲームパッドになる 原版は移動に数字キー、動作に5、メニューに二つのソフトキーを使っていた。現代の対象にはそのどれもない。モバイルでは方向の一式をスワイプか小さなタッチの配置に割り当て、動詞の数は少なく保つ。これらのゲームが三つを超える動作を持つことはまれなので、それは容易だ。デスクトップではキーボードとゲームパッドに割り当てる。ソフトキーのメニューバーは、二つのボタンの慣習を再現せず、普通のインターフェースとして作り直す。 ## 小さなハードウェアを前提にしたロジック Java MEのゲームループは、しばしば毎秒15から20あたりの低く不安定な速度でフレームを数え、手動の待機の呼び出しを挟んでいた。それを時間差に基づく形へ変換し、毎秒60以上でも同じ挙動になるようにする。遅い浮動小数点を避けるために使われた固定小数点の計算は、普通の浮動小数点にできる。Record Storeによる保存は普通のセーブファイルになる。音や振動のための端末固有のAPIは、標準のエンジンの機能に置き換える。 ## 古いJavaの携帯のゲームが今行ける場所 分かりやすい対象はモバイルだ。そこでようやくメモリに余裕ができ、かつて想定したより大きなカラーの画面がある。iOSとAndroid向けのビルドには、各プラットフォームのツールチェーンと署名、そしてタッチ入力への対応作業が要る。GDScriptで作り直したゲームは、Summer Games上のWebビルドとしても出せる。内容、選択肢、コントローラ対応を足して広げるならSteamも成立する。J2MEの時代のゲームには、ハードウェアに飢えていた良い設計が多く、移植が直すのはまさにそこだ。 ## FAQ ### J2MEのゲームを現代の電話で動かせるか J2ME LoaderやFreeJ2MEのようなエミュレーターを通してのみ動く。現行のどの電話もJava MEのランタイムを積んでいない。配布する製品にするには、エミュレートではなくゲームを作り直す。 ### 自分のJARからアートとコードを取り出せるか 取り出せる。JARはZIPのアーカイブなのでスプライトと音声はそのまま展開でき、クラスのファイルはデコンパイルしてロジックを復元できる。これは自分が作ったか明確にライセンスを持つゲームにだけ行う。 ### 元の極小の解像度はどう扱うか ネイティブの解像度を保って整数倍の拡大と最近傍のフィルタで引き伸ばすか、アートを高い解像度で作り直すかだ。一ピクセルずつ描かれたスプライトに平滑化のフィルタをかけてはいけない。 ### Javaのコードは移るか 動くコードとしては移らない。MIDPとCLDCのクラスはJava MEの外に存在しない。デコンパイルした元のコードを原版の挙動の正確な仕様として使い、ロジックはGDScriptかC++で書き直す。 ### あの時代の古い携帯のゲームは誰のものか 作った制作会社ではなく、発注したパブリッシャーや通信事業者であることが多い。Java MEのゲームは受託の仕事で、配布の権利が他所にあることが頻繁だった。商用リリースを計画する前に権利を確かめる。 ### J2MEの移植は商業的にやる価値があるか 内容の追加と現代的な利便性があれば、ありうる。これらのゲームは必要に迫られて短かった。設計を広げ、セーブと選択肢を足し、Steamとモバイルへ出すのは、本物の客層を持つタイトルにとって現実的な道だ。 [作り直しを始める](https://www.summerengine.com/ja/download) --- ## Machine-readable resources - Site index for agents: https://www.summerengine.com/llms.txt - Full inlined content: https://www.summerengine.com/llms-full.txt - Porting catalog: https://www.summerengine.com/llms-porting.txt - Structured catalog: https://www.summerengine.com/agent-catalog.json - Sitemap: https://www.summerengine.com/sitemap.xml - Developer resources: https://www.summerengine.com/docs - Summer API (assets from any agent or code; public per-call model prices): https://docs.summerengine.com/api