BREWとは
- 最近ではSnapdragonで有名なクアルコムがかつて開発していたOS
- 日本人的には auの KCP/KCP+ だ
- ガラケー全盛のauを支えようとしていた、かつての
クソOSだ - 2010年代が終わり、記憶が消えてしまう前に、彼について記録と記憶を留めておこうと思う
BREWとの出会い
- 新卒で入社し、手取り17万円で働いていた会社で、 Javaに似たへんな言語 で作られたゲームを、BREWへ移植する仕事が降ってきた
- ゲームの内容自体は面白かったが、ソレは別な話だ
- 当時docomoユーザーだった俺は、BREWやKCP/KCP+なんて全く知らない
- なので、手探りで開発をスタートすることとなった
- 会社的には、前任者のコードがサンプルとして存在していた
- 2010年前後の、お話である
BREWのざっくりとした開発環境
- Windowsで開発環境が構築できる
- Windowsでは
x86環境で動作するシミュレータが提供されている- これが後に悲劇を起こす
- 会社の公式開発環境はVisual C++ 6.0だった
- どういうわけか、会社には
無償で使えるインストーラが社内サーバーにあった - 新卒で入り、毎月17万円（手取り）ものお賃金をいただき、キラキラしていた俺は、ソレに目をつむった
- Visual Studio 2008（無償版）を途中から使い始めた
- どういうわけか、会社には
- 実機動作時はARM環境向けにクロスコンパイルを行う必要がある
- 開発言語は公式にはC言語のサブセット、コンパイラはC/C++対応されていた
- これが後に悲劇を起こす
- ハードウェアの仕様上、float演算が行えないことが再三警告されていた
- これが後に悲劇を起こす
- もとのゲームはJavaにプリプロセッサを適用するような当時のガラケーらしいJavaのような言語で開発されていた
- これが後に悲劇を起こす
- 詳細な公式ドキュメントは手に入らない
- これが後に悲劇を起こす
- アプリの容量（プログラムと、ゲームリソースの容量合計）が1.5MB前後
- これが後に悲劇を起こす
- アプリをリリースするためには、KDDIのストア審査が必須である
- これが後に悲劇を起こす
起こった悲劇たち
アプリ容量天元突破
- この問題にぶち当たるのは２度めである
- 1度目は入社直後dojaでやらかしている
- もともとの容量が大きいゲームだったため、プログラムもしくはグラフィックリソースを大幅に簡略化しなければならない
- が、そんな開発リソースはない
- そんなときに見つけたのが当時の2chの戦士たちである
BREWはメモリ保護がない（ので、下手なメモリにアクセスするとOSごとクラッシュもまれによくある） ことを生かして、- というワンダフルな手法が紹介されていたので、それを参考にさせてもらった
C言語のサブセットで開発するゲーム
- 基本的にはC/C++言語であるが、現代に比べてハードウェア・ソフトウェア共に低性能だったため、言語のフル機能が使えるわけではなかった
- 特に、 グローバル変数が使えない という点については頭を悩まさせてくれた
- なにせ、もとのゲームプログラムがstatic変数もりもりマッチョマン（constではなく、書き換えもしてる）なので、この制限をどうにか突破しなければならなかった
- 前述のように、このBREWが動く環境にはメモリ保護がない
- 解凍したプログラムも、実行ポインタを書き換えれば普通に動く
- なので、
自己書き換えもいけるんじゃね？ というひらめきを実行した
// 実行バイナリに4byteぶんの領域を確保 // この先頭ポインタを int* にキャストして、無理やり自分自身を書き換える // 普通にint変数を用意するとコンパイラが最適化しやがるので、文字列を使う const char STATIC_MEMORY = "012"
- この手段はARM（実機）ではうまくいくが、Windows シミュレータでは動作しない
- シミュレータはWindows用のDLLファイルを作って読み込むので、メモリ保護がビンビンに働いてアクセスエラーになる
- なので、
GLOBAL_VAR()SET_GLOGAL_VAR()GET_GLOBAL_VAR()のようなマクロを使ってアクセスすることで切り抜けた
Javaの配列.length問題
方法1, コンパイラの手を借りる
- ソースコードにベタ打ちされた配列は
sizeof()でbyte数を取得できる - sizeof(array) / sizeof(array[0]) とすると、
配列全体のbyte数 / 1要素のbyte数 = 配列の要素数を求めることができる - なので、定数的に定義されているジグ配列はチクチクとこの方法でlenを取り出すようにマクロへ置き換えた
方法2, new演算子をオーバーロード
- 動的に確保している配列のlengthは、sizeofじゃとれない
- 例えばint配列はnewで確保すると int* なので、sizeofしても容量はポイント１個分なのだ
- なので、メモリアロケータを加工して次のようなデータを返すようにした
[隠しヘッダ ここにbyte数とか書いとく][実データ]- new関数のなかで、ヘッダ + 実データ容量を確保して、実データの先頭アドレスを返す
- lengthにアクセスしたいときは、隠しヘッダの中身を見て計算する
- ついでに、Javaの初期化を再現するためにゼロ値埋めも行っている
これらを簡易的に行うためにtemplateを使う
- templateで↑を自動的に扱えるように、ラッパーを作成した
.length()のようなメソッドを提供したり
- おかげで、lengthに関わる移植が終わる頃にはだいぶコードがスッキリとしていた
template便利だな
そして次の悲劇が起きる
templateサポートの悲劇 / シミュレータはエミュレータじゃない
- BREW用のARMコンパイラはtemplateもサポートしていた
- なので、例えば
vector3<int>みたいなtemplateを作り、それを別なtemplateの引数（templateの入れ子）をしていた - ある日、大量のコンパイルエラーが発生
- シミュレータ（Windows環境）ではMicrosoft様の優秀なC++コンパイラによってサポートされていたtemplate入れ子が、ARMコンパイラでは非サポートだった
- ドキュメントに書いとけボケぇ！
- すまん、言える立場じゃなかったな。。。
- template入れ子を排除すべく、ひたすらマクロに入れ替える日々が始まった
- シミュレータはシミュレータであって、ARM実機を再現するわけじゃないと、このとき強く意識に根付いた
- なので、iOS
シミュレータに対しては言いたいことあるが、まあコイツほどクソ独特じゃないのでとても快適である
- なので、iOS
float演算が使えない とは
- たしかに、当時のARM CPUはfloat演算が行えない
- 代わりに、同等のソフトウェア命令にコンパイラによって置き換えられる
- そんなコンパイラの知識なんてなかったので、
float変数を作ったら実機でコンパイルエラーになると思い込んでた - セコセコと固定小数演算したり
- 気づいたのは、だいぶ後の祭りである
公式ドキュメントが手に入らない
- 正確には、正規コンテンツプロバイダーが手に入るようなドキュメントが手に入らない
- 零細ゲーム会社なんてそんなもんだ
- 手取り17万円しか払えないんだぞ
- なので、普通にネット上からDLできるざっくりとしたドキュメントを使用した
- ほんとざっくりだったなお前
- 例えば、ネットワーク通信時にAPIに渡す構造体のメモリをいつ開放していいのか、失敗時のハンドリングどうするのか、ほとんど書かれてなかった
- 仕方ないので四六時中保持してた
そして悲劇が起こる
- 課金APIの詳細な動作仕様が手に入らなかったことにより、課金で問題を起こす
- 多大な残業と休日出勤と、パブリッシャーサイドの寛大な対応により、なんとか許しを得たはず
- なお、残業代も割増賃金も辞退した
- 自責なので仕方がないよね、と新卒のキラキラした目の僕は自分に言い聞かせた
- んなわけない
- 17万円しか払えない会社やぞ
- 発生するわけないやろ
文字が描画できない
- グラフィックス系のAPIさわってたら、「せやな」程度だけど
- 当時のdojaのプログラムは、3Dの描画をした上に文字を描画できた
- BREWは文字描画が専用APIで、3Dの描画と排他仕様だった記憶がある
- 記憶が曖昧だ
- つらい過去だったのかもしれない
- 頑張ってそれっぽく見せるようにした思い出
半透明が描画できない
- BREWの2D APIの仕様である
- dojaはそこそこ高速に半透明が2D APIで描画できたのである
- なんか、全部3Dに入れ替えたんだっけかな
- 記憶が曖昧だ
- つらい過去だったのかもしれない
- 頑張ってそれっぽく見せるようにした思い出
KDDI検証
- 俺はエクセルを書くためにゲーム会社に入社したわけではなかったんだ
- ゲーム仕様をひたすらエクセル方眼紙に書き出し、検証資料を作り上げた
- 記憶が曖昧だ
- つらい過去だったのかもしれない
実機実行の壁
- 当時のガラケーはどいつもコイツも実機でプログラムを実行するのが大きな壁だった
- dojaはネットワーク越しでしかインストールできないため、ゲーム開発のパケ代が自腹である
- BREWは安っぽいケーブルを接続して転送できるが、実機を転送モードにできるのは正規コンテンツプロバイダーだけである
- なので、実機で画像ペラ１枚出ただけでも「うううおおおおおおおおおおお！！！！！」みたいな感動があった
そして、2010年代
- そんな状態だったので、
誰でも無償で開発できて、誰でもマーケットへ公開できるAndroidに心惹かれたのは当然であり、きっとBREWに触ってなかったら別なことを思っていたかもしれない - Androidに注力した2010年以降は、手取り17万円からは想像もできないほど金も時間も心も豊かになった
BREW、君は僕の2010年代を豊かにする大きなターニングポイントの役割を果たしてくれたのかもしれない
今はただ、安らかに眠れ
補足
- 2010年1月現在の手取り、正確には17.6万円弱だった
当時の給与明細
