今日の面

・レーザー判定完成
太さのあるレーザーも実装。太さのないレーザーをすり抜けないように判定を取るのが面倒だったので全部ある程度の太さを持つレーザーにした。四角形でレーザーの判定を取るのは結構計算量があるので、ある程度の太さまではレーザーの四角形の中に何本か線を出して、その線に当たっているか判定を取るようにした。
残るは弾消しとカスりへの対応。予告線を出す演出はまだ作っていないがすぐにできる。
回転レーザーや、長方形にならないレーザーは作っていないが、普通に使う分は十分だと思う。必要になり次第個別対応という形。
あとは、レーザーを生かせる弾幕を作れるかどうか。

主人公の見た目がろくに決まっていない中、ボスの見た目が次々と決まっていき、絵を描き始めている状況の復讐は一体どうなっているのだか。

今日の貫通

・復讐土キャラ作成
・蘇生レーザー実装
土属性として昨日考えたキャラを試しに描いた。その結果黄色を使わないとならないはずなのにほとんど使わずベースカラーが紫になってしまった。土行のキャラクターとしてふさわしいか問題。

蘇生に、ついにレーザーを実装。暫く触っていなかったため、もともとのソースの汚さに加えてC++の文法に苦戦。もうこれ以上、システムをいじりたくないぐらい。以前に実装した、弾の連射による疑似レーザーと名前が衝突するのも厄介。
今日実装したレーザーは太さを考えない線レーザー。線なので当たり判定がすり抜ける可能性があるので、それを防止するための機構を書いたのだが、それのせいで当たり判定がうまく取れず、画面端ワープが使えなくなることもわかったので全部のレーザーに太さを持たせるように改良しようと思っている。あと、グラフィックが妙に細くなって見にくい。

日付がすでに変わっている点は無視。

今日の土

・三作目構想
・復讐キャラクター妄想
・弾幕講座ひとまず完成
三作目を、ダンジョンアクション全方位弾幕シューティングＲＰＧというジャンルだけでお腹いっぱいにするのを妄想してみたり。
3属性で行く方針にしていたのだが、やはり折角考えたのに使わないというのももったいないと思ったので、ネックとなっていた土行のキャラクターを30分ほど考えてみた。土行から思い浮かぶことを書き連ねて、それを組み合わせていった。その結果、キャラクターが出来たのだが、色々な面で紫と被る。自分の考えが無意識にそういった方向を選択したのか、それとも自分が考えた軌跡が神主のそれと重なっていたのか。黄色が似合うキャラクターになれば違ったキャラクターに出来るのだが、黄色が似合うというイメージが全然湧かない。
書いていた弾幕講座がひとまず完成。7ページ。サンプルプログラムに全くコメントがないのでまだ完成ではない。

今日の目録

・サンプル作成中
文書とともに。案外ハイペースで進む

今日の見本

・弾幕＋Ｄ＋ＳＤＬ＋ＯｐｅｎＧＬサンプル作成中
講座を書くので、3本の講座を纏めて一つのサンプルプログラムで済まそうという魂胆。分かりやすさと多彩な文法の紹介との両立が難しめ。
foreach文は、intの配列なんかを扱う場合、foreach(i;number)という形で書いていたのだが、この書き方だとiに数値を代入してもnumberの方に反映されないということに気がついた。正しくはforeach(ref i;number)と書かないといけない。クラスは元々参照渡しなので大丈夫。for文をポインタでまわすのと同じように考えて使っていたら思わぬミスを生む。

今日の現実

・ライブラリバグ修正
仕様を変更した後、それを文字列の描画に入れ忘れていたので原因不明のバグになっていた。ただリサイズのやつの動作とは関係ないので相変わらず調査が必要。
アンドロイド開発に少し興味を持ったのでJavaを見てみたら、C++風の文法で結構なじみやすかった。暇があれば触ってみようと思う。

今日の線分

・縮小機作成中
・多角形判定正確版実装
相変わらず縮小機を作っている。大方コードを書いたのだが、上手く出力が来ない。それどころか当然動くはずのコードさえ動かない。
前作った多角形の判定が、長方形同士が十字型に交差するような場合に判定が取れなかったのでアルゴリズムを変更。それぞれの多角形の辺の交差判定を取り、どれか一本でも辺が交差すれば衝突、また一方の図形の中の任意の点が他方に含まれている場合衝突。この方法であれば多角形の凹凸に関わらず正確に取れる。但し計算量は多い。

今日の縮小

・縮小機製作中
前見つけたものでは透過色を思い通りに処理できなさそうだったので自作することにした。ピクセルの色を取得するのが意外と大変だった。二次元配列を一次元のポインタにするのがややこしい。
あとはテンプレートの文法を見てみたり。ただゲームを作るぶんには使わないと思う。

今日の全方位

・多角形判定実装
・SS第3弾案
・復讐構成案
多角形同士の当たり判定を実装。凸多角形であればなんでも判定できる。面白い。ここまで作ってしまうと蘇生にレーザーを実装しないのはもったいないように思えてきた。なので、まだほとんど作っていない5,6面限定にレーザーを出してみようかと考えている。

SS三作目についてやや構想。戦略シュミレーションと考えていたのだが、実際に作るとなるとAIを作ったりパラメーターを調整したりで相当に大変そう。なので、一度その案を捨てて新しく練り直してみた。
蘇生がシューティングRPG,復讐がアクションRPG、と来たので、次は全方位シューティングアクションRPGが妥当、と思った。現在の構想段階だと両者を足して√2で割った感じ。もっとも復讐もまだ形になっていない。今のところ考えてある戦略シュミレーション向きのストーリーをどのように組み込むかが重要な要素。

復讐のボスの案についても練ってみた。近頃は五行に基づいてボスを作ろうと思っていたのだが、それだと上手く蘇生とのストーリーが繋げられない。それで蘇生と同じ3属性での構成を検討し始めた。五行の場合はどうしても土行のキャラクターが浮かばなかったのも一因。

今日のベクトル

・ベクトル勉強
四角形との当たり判定を取りたくなったのでベクトルを勉強した。これまで書いてきた処理の内結構な量がベクトル演算で楽に計算出来そう。まずは多角形オブジェクトを作り始めた。
学校教育では実用的なことを教えるべきだと思う。三角関数とかベクトルとか行列とか複素平面とか。少なくとも軌跡を求めるよりはずっと役に立つ

今日の壁

・壁反射実装
Re:Actionの完成目標が今日だったわけだが、一番ややこしい衝突周りの処理が書き終わったので、期限を完全に破ったわけではない、と言い訳。復讐を作り始めたことが主たる原因。
昨日大部分書いたのに実装に時間がかかったのは、衝突後の位置あわせと、クラスの参照に関する問題があったから。前者は、暫定的に書いた頭の悪い手法をスマートな方法に書き換えたのだが、式を間違えているのか、それともどこかで浮動小数点が整数に丸められているのかで、上手く行かない場合が出る。色々と試しているが未だ解決には至らず。
後者は、クラスは常に参照渡しされるというDの使用に則って書いていたつもりが、何かが上手く行かずクラスの参照を変更したはずなのに変更されていなかったことに気がつかず、色々な部分をいじっては悩んでいた。
一段落したことにするので、SSの製作に移行する。

復讐で使う画像データをドット絵で書こうと思っていたのだが、アクションゲームはSTGよりも絵をアニメーションさせる必要が多いことを忘れていた。そこで、以前考えていた3Dで作った絵を2Dにする、という方法を改良し、2Dのモデルにドット絵のテクスチャを貼り付けてそれをアニメーションさせて、キャプチャするというのも考えた。しかし、この方法は小さい絵に使うのには向いていない気もする。漫画的手法を使うことで少ない絵の枚数でも納得の行く動きにするのがいいかもしれない。

頭が放物線の人間と、双曲線の人間を書いてみたが、放物線の方がよさそうだった。それだけ。双曲線も悪くはなかった。

今日の埴輪

・縮小機探し
・FPS調整実装
・直線演算機能実装
ドット絵の縮小ソフトを探した結果、Yukari（ユーカリ、紫ではない）というソフトが一番自分の用途に合っているように感じた。これで上手く行くようならそのまま使い続ける。ドット絵は、１ドットごとに考えてドットをおいていく作業も含めてドット絵と呼ぶ、というの言葉を見たが、大きめなドット絵を小さいドット絵に変える、という手法はドット絵と呼ぶのだろうか。
Re:Actionを再び作り始めた。まずはFPS調整の作成。表示機能の一部を流用して作った。PhobosにCで言うsleep関数がなかったのは意外。垂直同期を使うのは、Dだとやり方がよくわからなく、ABAGamesのやつもタイマーで作っていたので諦めた。
そして、壁との当たり判定を取り始めた。前作ったやつはソースが汚く、汎用性がなく、しかも動かなかったので没にし、新しく数学的な当たり判定を書いた。壁との反射は簡単だったが、壁との当たり判定を取ったり衝突した点を取ったりするのがややこしそうだったので直線クラスを作成。線分を扱うことも出来るはず。
これを蘇生に流用してレーザーを作りたいとも思ったが今更付け足すのも微妙。キャラクターのグラフィックは大きく書いたのを縮小するという技法を取り入れたいと思っている。

棒人間の代わりとなる新しい簡易人間を考えてみた。ジャガイモ、記号、色違いの記号、兵馬俑、埴輪、蝋人形、双子など。こう纏めると意味不明だがどれも長所も短所も持っている。

今日の縮小

・ライブラリ画像描画修正
・復讐仕様書執筆
画像サイズが2の累乗サイズでないと異常になるのを放置していたことに気がついたので直した。ずっとそのサイズにあわせて画像を作ってきたから気がつかなかった。

復讐のキャラクターを考え始めたのでそれを仕様書に書いた。名前が元ネタそのままなのはイマイチだと思い始めたので、適当に名前をつけてみた。蘇生もそのようなネーミングにしていいかもしれないと思っているが今更変えるのも良くないか。
復讐のマップチップが16*16なので、それにあわせてキャラチップもその大きさで描き始めてみたが、情報量がどうしても少ない。そこで、大きめに描いた後に縮小するということを考えたのだが、どうもぴったり来る縮小ソフトがない。画像を縮小して、きれいに見えるアルゴリズムでの縮小は、縁の部分が黒くなる。ふちがきれいなアルゴリズムだと情報が失われすぎてなんだか分からなくなる。もう少し縮小ソフトを探してみるが、もしなければ自作しようかと思っている。
半分の大きさに縮小するのであれば、4ピクセルごとに画像を区切って、その4ピクセルのRGB値を平均して縮小後の画像に入れれば上手く行くと思う。透過色を指定して、透過に設定されているピクセルはその平均を取る対象から外す。こうする事で、ふちが汚くなることもないはず。
何故、このような手法を使った縮小ソフトがないのか。この方法では上手く縮小できないのか、それともこのような汎用性の全くない方法は使わないのか。

Re:Action完成まで後2日。システムを再考したが、プログラムは全く進んでいない。

今日の式神

・文字列描画機能強化
・キャラクター部分製作開始
昨晩思いついた、文字列描画の強化を作り始めた。今までコンストラクタ以外は普通の画像描画と全く同じようにしていたのを、文字列に特化させる。
復讐のキャラクターの周りを作り始めた。まずは描画。RPGツクール2000ではマップチップが16四方の正方形で、キャラクターチップが48×32。それにあわせて作り始めたが、使い勝手が悪そうなので画像ごとに大きさを変えるほうが適当だと見た。

ゲーム以外のネタを考えたので記録。妖怪が式神を使い、その式神が式神を使う。これを言い換えると人間がコンピューターを使い、コンピューターがコンピューターを使う。そこから思考を飛躍させ、卓上式神という物を考えた。
普段はデスクトップ上をうろうろしていて、命令を与えることでちょっとした機能を行うユーティリティ式神。機能を実行するのはWindowsAPIを使えば大体足りるのと思うが、常駐のデスクトップマスコットの作り方について要調査。

今日の大きさ

・弾幕発案
・BulletML環境導入
蘇生の弾幕を考えた。名前ありきの弾幕。なかなか絶妙なネーミングだと自分では思っているが、掛詞という文化を駄洒落という今の世の中は嫌いだ。
使うかもしれないのでBulletMLの環境を構築。具体的に言うとBulletML,libBulletML,Bulletnoteの導入。
Eclipseのバージョンが、Bulletnoteが開発された当時からだいぶ変わっていたのでインストールに苦戦。Pluginフォルダに解凍したファイルを入れたり、プラグインのインストールの画面にそのフォルダ名を入力してみたり、プラグイン開発として開いたりしていたら何時の間にかインストールできた。プレビューアが動かない原因が分からない他は上手く行っている。

SDL+OpenGLでの、実行速度の調整法について色々調べていたが、垂直同期の使用はグラフィックカードの設定によって変わるらしい。wglを使えばプログラム側でも変更できるがWindows専用。垂直同期が可能な場合は使って、使えない場合はタイマーを作って調節するのが妥当のよう。

画面の縮尺、特に自分でスクロールのできるタイプのゲームについて少し考えてみる。
倍率が大きい、つまり拡大される場合、一つの画面内の情報量が少なくなり、画面端から画面端までのゲーム内の距離が短くなる。その一方、物が見やすい。これをSTGに当てはめると、画面に表示される弾数が少ないので関係のない弾に惑わされにくくなり、大局的に見られないのでパターンを把握しにくく、画面外から突っ込んでくる弾が画面中央の自機に届くまでの時間が短い、つまり処理が難しくなり、弾の狭い隙間が見やすくなる。
倍率が小さい、つまり縮小される場合はその逆。これを当てはめると、パターンを把握しやすい代わり関係ない弾に惑わされやすく、画面外から弾が飛んできても十分に処理でき、高密度の弾幕はスキマが見えない。
これらを考えると、遅い弾を気合避けは画面を拡大して、速い弾をパターン避けは画面を縮小するとやさしい。
結局何を言いたいのか分からない当たり前の結論に達してしまった。

今日の巻物

・FPS計測機能作成
・マップエディタひと段落
FPSを計る機能作成。ミリ秒単位を秒に直していなかったのが失敗の原因だった。それで、FPSを測ったところ160程度。どうやら自動で調整はしてくれないらしいことが判明。フルスクリーンは試していない。画面サイズが1100*750と普通よりも大きい他はほとんど処理をしていないのにこのFPSしか出ないというのは、動作の重さに若干の不安がある。

マップエディタもひとまず出来た。まず、マウス入力でマップチップをマップに配置する機能を作成。その結果、マップの読み書きを行う際にチップが一行ずれるという問題が出てきて格闘していた。それを直して、マップの描画位置のずれも解決して、最低限のマップチップ配置機能は完成。
ゲームのほうからマップを表示するのも滞りなく進んだ。キャラクターとチップとの当たり判定の取り方の構想を纏めたので、今度はそれをしようかと思う。

Re:Actionは絶賛放置中。ゲームのコンセプトを守ろうとするとプレイヤーに不親切になるジレンマに陥っている。

エレベーターで、押されたボタンに応じてエレベーターを操作するというゲームを少し妄想してみたが、考えて1分ぐらいで止めた。

今日の初期化

・パラボラ改良
・復讐問題解決
パラボラを、有効ポテンシャルを利用することで改良。軌道がまともになった。しかし、未だに計算中に虚数が出て詰む場合が多く、最終的に落下する軌道しか描けない。
PCが重くなった原因は、メモリの浪費にあったらしい。時刻の画像を実際に必要な量の300倍作っていたらメモリが数秒で500MBぐらい消費されていた。
本を返却したので、12月半ばぐらいまではパラボラは置いておく。

復讐の画像表示の問題が解決した。SDLの初期化の前に、画像の読み込み処理をおいていたのが原因。初期化前にSDLの機能を使おうとして、バグの原因になることがしょっちゅうあるので、初期化前に呼び出したら例外を投げるよう改良しようと思っている。
OpenGLはウィンドウモードでも垂直同期が取れるのでFPSが安定する、という情報を見たので、確認する為にFPS表示機能を作っている。だが、何故か上手く行かない。

今日の楕円

・一般相対性理論的軌道シュミレーション動作
昨日上手く行かなかった原因は、半径の扱いもあったのだが、時間の増分が暗黙のキャストによって1/60が0に切り捨てられていた為。本当に良く引っかかる。
それ以外にも色々と式を直して、ひとまずブラックホールに落下していく軌道を描くことは出来た。または円を描いて公転。
ただ、現状だと天体の質量をある程度以上に上げるとPCの時間が遅くなったかのごとく重くなったり、本来楕円軌道を描く場所がそうでなかったり、ブラックホールに落下する以外の軌道が描けなかったりと色々問題。
ただ、本の返却期限なので一旦この問題はおいて置き、完成予定まで1週間となったRe:Actionや序盤で組むのが楽しい復讐なんかをいじる。

今日の半径

・パラボラマスター製作開始
５つ又開始。ようやく軌道の計算が出来そうな段まで差し掛かったのでプログラムを書いた。角運動量の算出が上手く行かない。シュヴァルツシルト半径との比として中心からの距離は表せるのだが、そのまま扱う場合が上手く行かない。明日までにベースの軌道計算は確立したい。

戻り弾幕の作り方について考えてみた。途中で軌道が変化することのない単純な式で表せる弾幕は、射出直後に弾の位置から速度を何回か引いて、初期位置を設定し、その後速度を足していけば自然な動きに出来る。

今日の警告

・改良型マップシステム実装中
パレット＋圧縮のマップシステム作成中。ファイルの入出力が出来るようになった。容量が従来の100分の1まで減ったがそれは圧縮効率しだい。
ファイルの入出力が出来るようになったので、マップエディット機能を作り始めようとしたが、読み込んだ画像が真っ白になるという原因不明のバグが発生中。パレットエディタとほとんど変わらないコードのはずなのに真っ白。画像を保存してあるメモリ領域が使われている、なんてことはないだろうに。

ネタゲームを思いついたのでそのうち作る。

今日のパレット

・マップ機能改善中
・蘇生作成
ファイルの容量が何とかならないかと思案した結果、3つの解決案。一つは、何も埋めないチップのデータは書かず、何か書くチップのところだけ、座標を指定してチップを置く。もう一つは圧縮。同じ内容のチップを圧縮する。そして最後に思いついた最良の方法が、パレット形式。256色ビットマップの要領で、パレットデータをあらかじめ置いておいて、マップチップ一つを1バイトで表す。パレット形式の場合は圧縮との相性もいい。1番目との併用は効果が薄くなりそう。
それで、パレットエディタを作成した。ファイル読み書きのインターフェース以外は出来た。マップエディタはファイル読み書きだけ出来た。

蘇生も久々にいじった。命名規則の適当さや、ショートカットキーの違いに戸惑った。4面の耐久弾幕を少し作った。5面前後のシナリオもだいぶ練れてきている。

今日の二次元

・マップファイル読み書き作成
まずはマップ機能から作るということで、マップファイルの読み書きを作成した。ファイルを開くときの設定を間違えていて30分詰まり、動的配列の長さをのばした後クラスのコンストラクタを呼び忘れて1時間詰まった。
SDLを使いながらメニューバーなどのGUI環境の使い方を知らないのでエディット画面以外をCUIで作っている。WxWidgetでも勉強するのがいいかも。
D言語、というよりPhobosの関数を使ってCUIアプリケーションを作るときに引っかかった点があったので一つ。
文字列を読むときなどにC言語で言うscanf関数としてPhobosのreadln関数を使っているのだが、同じように使うと、readlnでは読み込んだ一行に改行文字（Windowsでは\n）が含まれている。これで得た文字列をそのまま使うと上手く行かないので、文字列（char[]型）の最後の一文字を消してから使わないといけない。

300×100の二次元配列というと軽く感じるが実際には3万ある。3万ものオブジェクトをGCに管理させると突然動きが止まったりしそうで怖いので、自力でメモリ管理している。あとこの配列をファイルに書き出すとintegerの配列でも100KBぐらいに届く。二次元恐ろしや。

イベントの管理にSQLiteを使ってみようと思い、データベースを作ってみているが使い方が良く分からない。OpenOffice Baseも試したが分からない。データベースの基礎ぐらいは勉強しておかないといけないらしい。

今日の始まり

・復讐本格製作開始
製作開始宣言からやっと本格的な製作の開始。思えばその間にDirectXからSDLからOpenGL、CからDへと随分と方針が変わった。
今日はプログラムの基礎の方針と、マップチップの表示を作成。蘇生では適当だった命名規則を統一し、D言語の分かりやすい関数ポインタを生かした設計を行う。
マップシステムの設計は今まで考えていた方針をベースに４０分ほどで考えた。
目標は、今年中に基本的なシステムを完成させること。

それでもってネタを色々妄想。
まずは豆電球STG。画面が真っ暗で、豆電球と、普通の弾が飛んでくる。豆電球は光源になっていて、豆電球の光で弾を照らして避ける。豆電球を撃ってくる敵に挑発ビーム的な物を当てると豆電球を沢山撃ってきて明るくなるが、豆電球も弾扱いなので弾幕が濃くなる。豆電球を出しすぎると明るすぎてかえって弾が見えなくなる。
実際に作るとなると、点光源をどうするかが問題。OpenGLでの光源については知らないが、DirectXでは５０個も使えなかった気がする。2Dで作るのも有りだが結局自前で光源の計算をしないといけない。

もう一つはカードゲーム。こちらは二つ案がある。一つは戦略シュミレーションと混ぜた物で、毎ターンカードを引いて手札にして、手札を使って何かイベントを起こしたり、ユニットを出現させたりする。敵と自分のユニットの間で交戦して、カードのパラメーターや、イベントの使用によって対決する。戦闘にはランダム性がない代わりにカードの引きの面にランダム性を与える。
もう一つはRPG。キャラクターにカードを装備させて自由度の高いカスタマイズをして、装備カードとは別に、戦闘するときにカードを使って色々と。

SS3弾目に2番目に書いたネタを使うかも。作り始めるのはいつになるか分からないが。

今日の壁

・壁との当たり判定実装
衝突の式も入れたが適当にやったので予想通り上手く行かない。汎用性がない上に汚いので作り直し必須。

再びOpenCVやOpenALに興味を持ってみた。特に後者の日本語情報の少なさが魅力。OpenCVでもカメラの画像の取得にはDirectShowを使っているようなので微妙。どちらもC言語で書かれているので、大きな面倒はなくD言語のインポートヘッダを書ける。

今日の時計

・エネルギー計算
昨日に引き続き。式は変わっていないはずなのに、今日試したら直感にあまり背かなかった。衝突面の角度によって大きく差が出る模様。

一般相対性理論勉強中。シュヴァルツシルトの解をだいぶ理解した。今の状態でもプログラムが書けそうだが、この先の章に具体的に運動の計算が載っているのでそこを読んでから。

SQLiteに興味を持ってみた。ただ、蘇生に使うのは今更感があるし、復讐では必要性を感じない上D言語用にするのが大変そう。現状使い道があるとすればパラボラマスター程度だが、毎回ランダムで設定をしたほうがいい気もする。

今日の直感

・エネルギー計算
衝突によるエネルギーの損失が、どうも変なように感じたので損失を直接計算する公式を使うのをやめて、前後それぞれの運動エネルギーの和を求めてその差を取るという方式に変更したのだが、結果が変わらない。その式はあっているはずなのだが、どうも直感的に変に感じる。運動エネルギーの損失はそんなに直感から背く結果となるのだろうか。

Re:Actionで、ボス敵を出そうと思って暫く構想。普通に大きいだけの丸では面白みがないので、もう少し複雑な形を取りたい。だが、衝突判定の都合上円以外のものを使うの大変。ということで、円をいくつかつなげた物をボスにする事に。ただ円を繋げるだけでもあまり面白くないので、化学からネタを引っ張ってくることにした。

相対性理論の勉強を開始。学部3,4年生向けと書かれていたので、4年生の自分にはぴったり。まだあまり進んでいないが、ややこしさがなさそうでいい感じ。

OpenGLでモデルファイルを読み込むライブラリを見つけた。まだ試していないが、これで上手く行くようであればフォトンとかもOpenGLで作りたい。

今日の鵺

・Re:Action進行
全方位シューにしようと思っていたが結構きつかったので横シューにした。弾と敵との間の判定実装。

Re:Actionの完成日を宣言しておいてなんだがそろそろSSも作りたくなってきた。

それから少し考えたこと。「個性的な鵺」について
鵺というのは西洋で言うキメラのような物だが、キメラ程はパーツになっているのが変な動物ではない。でも個性的な見た目をしている。
しかし、平凡な要素を沢山足し合わせたゲームや物語というのはたいてい没個性的。奇抜な要素を組み合わせても個性的になれないことがある。この鵺と、ゲームや物語の間の差は一体何であろうか。

今日のトンネル

・デバッガ使用成功
・Re:Action進行
Code::BlocksでのDdbgの使用に成功。デバッガを指定するところに、ddbg.exeではなくもう一つのバッチファイルの方を指定すると使えるようになる。その際、ファイルを選択するダイアログではExeファイルしか指定できないようになっていて、ファイル名を手書きで指定するのがミソ。使ってみた感じ、Descentから使ったときよりも使いやすく感じたが、何故かSDLの初期化が異様に遅くなる。

乱数を使いたかったので、ドキュメントを参考にしてやったら何故か未定義と出る。良く見れば使っているDMDのバージョンが1.0系列で、使おうと思っていた乱数の機能はDMD2.0系列からのサポートだった。そこで、2.0を入れてコンパイルして、最初に文字列がconstであることに引っかかった。これはキャストを使って解決したが、今度はOpenGLのリンクでずっと文句を言い続けた。インポートヘッダを書き直したり、インポートライブラリを作り直したりしてリンクが通ったと思えば、変数を使うと変なタイミングで例外が出て、OpenGLの関数を使うと確実に落ちる。
色々試したが上手く行かなかったので諦めて1.0の乱数を使っている。マルチスレッドを使わない限りは大きな問題が発生することはないそうなので妥協。1.0に戻すとき、ライブラリファイルを変えたまま戻し忘れていたせいでOpenGLの機嫌を損ねてその原因の究明にも時間がかかった。

なんだかんだあってD1.0でRe:Actionの開発を進行。仕様書を書いて仕様を固め、その実装に入った。現在敵を沢山出して動かすまで。ランダムの関数の戻り値がuintだったことで微妙に詰まったり。
ゲームの救済システムにトンネル効果が登場予定となった。トンネル効果が意味を持つスケールよりも明らかに大きすぎるのだが、トンネル効果と呼ぶのが一番しっくり来る。
Re:Actionの完成目標は今月20日に設定。

今日の演習

・開発環境変更
・反動ゲームタイトル決定・進行
・蘇生ストーリー発案
D言語の開発環境を、DescentからCode::Blocksに変更した。Descentに比べて、正式にコンパイラがサポートされているのがいい。コード補完機能はある程度動くが不完全。Descentでは他のファイルに書かれたものは補完されないようだったが、こちらはまだ基準が分からない。このIDEは本来はC++用なのでC++の文法で通じるように書いたところは利くのかもしれない。
デバッガは動かない。Ddbgと連携できると公式には書かれていて、スクリーンショットもあるのだがその設定方法が書いていないように見える。

反動ゲームのタイトルを決定。「Re:Action」。つまりは反作用。アクションゲームに対する一つの回答、とかいう訳ではない。そもそもアクションゲームというよりはシューティングに近くなりそう。GIMPを使ってロゴを描いたりもしてみた。
衝突の式を自分で計算せずに他のところを見て実装。これから一般相対性理論を自力で学ぶのだからこれぐらいわざわざ車輪の際発明をしなくても許される、と無理やり妥協。めり込む問題は美しくない形で解決。そのうち直す。
衝突によるエネルギーの損失に比例した量のパーティクルを出す機能を付けた。パーティクルをただの演出から、ゲームの重要なアイテムに格上げ予定。

蘇生の4面から5面へのストーリーの展開も考えてみた。これまで考えていた案に比べてより筋が通っていて、且つキャラクターの名誉を傷つけない妙案。ついでに5面のコンセプトを考えてみて、その結果奥義の名前が決定。

今日の回転

・衝突仮実装
物理のノートを読んだら式が出てきた。複素平面を利用して、速度ベクトルを衝突面に沿うように回転させ、衝突の法線方向の要素に関して衝突の演算。その後保存されている衝突の水平方向の要素と合成して、最後にXY座標に合うように再び回転させる。
行列が出来なくても複素平面を使えば2次元なら簡単に出来る。3次元も多分可能。
今のところは、衝突した後相対速度が落ちて、物と物がめり込むようになっているが、衝突後に適当な距離に矯正してやれば解決するはず。

ブロック崩し風の背景に、色々とグラフを書こうかと思っていたが、数式をそのまま背景に描画するのも悪趣味でいいと思った。衝突するたびに背景に衝突の数式を出してみたり。ブロック崩し風の演出のコンセプトは数学、反動ゲームのコンセプトはパーティクル。
画面が見えなくなるぐらいにパーティクルを出すネタというのはいいと思う。