今日のクロックアップ

・シューティング作成

・スクリプトいじり

第2回3時間コンテストということで、「アイテムをとってゲームスピードを上げて、早くクリアすることで得点を荒稼ぎ」というコンセプトの横STGを作ってみた。しかし、まともなシューティングの土台を作るのに1.5時間以上かかって、まともにゲームとして成立しなかった。コンセプト的にもあまり自分の趣味に合わないのでお蔵入り。ランクを能動的に調整できて、それに毛が生えたという程度。

復讐のスクリプトをいじっていた。だいぶいい実装が出来そうになったのだが、最後の壁として型情報が立ちはだかって詰んだ。型の情報を保存する型、というものでもあればよかったのだが見つからない。sizeofやstringofプロパティが取れるのに、型は型ではないというのは、型とはいったい何なのか。Phobosで型情報を触っているモジュールがあり、それを参考にして、テンプレートとaliasとを組み合わせて乗り越えられるか、と思ったが越えられず。stringofプロパティを利用してコンパイル時にコードを生成する、というようなことも考えたのだが、ややこしかったのでやめた。

それで結局妥協して、関数を呼び出すためのラップ関数を一つずつ作って、それへのデリゲートを連想配列に格納する、という方法での実装にした。ラップ関数を作った労力のリターンとして、関数を呼び出すときに引数をどうするのかを意識せずとも使えるようになったので、これで妥協。その実装の進行具合は、構文解析のあたりで機嫌が悪くなっていて、ごく単純な命令しか実行できないという状況。

今日の混迷

・スクリプト

・XNA

テンプレートと可変個引数の項目を読んでみたら、昨日当たりかと思ったのは別に使えなかった。それでもう少しコードを書きながらいろいろと試してみたりもしたのだが、やはり手段がなさそう。

それで仕方なくコードを手書きしていくことにしたのだが、それがまた混迷している。さすがに一つ一つの関数ごとに愚直に書く様なことは避けたいので、引数の数ごとに関数を分類する、ということをやっている。そのときに関数の引数として任意の型の関数ポインタを渡すようにしているのだが、それをどう渡すかで詰んでいる。Phobosにもそのようなことをしているものがあって、それを参考にしてはいるのだが上手くいかない。テンプレートで何とかしたいのに上手くいかない。あんまり上手くいかなくて憂鬱。

 

XNAの本を買ってきた。飛行シューティングを作る前に物理ゲームが大量の壁として立ちはだかっていたことを思い出して、それもまた憂鬱の種。Poseidonが不機嫌なのも憂鬱の種。

今日の事前

・XNAさわり
・スクリプト
XNAを触っていた。頂点としてベクトルの配列を指定してそれを描画する、というクラスを実装しようとしていたら既に存在していた。XNAは何かやろうとすると既にそれが準備されている、という感じがして変な気分。慣れれば便利なのだろうけど。

スクリプトの課題となっている、関数の呼び出しらしきものがD言語のページに書かれていることに気がついた。問題は、まだろくに使ったことのないテンプレートや可変個引数がコアに使われていて、そのコードの理解が上手く行かないこと。

今日の入力

・飛行ゲーム考察
昨日から考えている飛行ゲームの入力について考えていた。少なくとも上下左右の舵と、加減速のキー、それと攻撃をするためのキーが最低限必要で、それをやるには普通の2Dシューティングのキー配置では出来ない。かといってアルファベットのキーに色々役割を振り当てるのは自分の好みではなく、テンキーを使うことも考えたが、ノートPCにはテンキーがないことがほとんどなのでそれも出来ない。残る手段としてマウスがあるのだが直感的に分かりやすい操作体系がなかなか浮かばない。ジョイパッドを使えばいいのだろうがジョイパッドが好きではない。Wiiリモコンなんかは舵の操作にかなりよさそうだがそれだと遊べる環境がほとんどない。
やはり、全ての軸に自由な3Dゲームを作ろうと思うとどうしても入力の面で壁にぶつかる。分かりやすい3D用入力装置が普及すればPCゲームの世界は大きく広がるのではないか、といつも思う。

今日の束縛

・スクリプト
・作りたいもの
スクリプトを作るうえで、ホスト側のプログラムの関数をどう呼び出すかが一番の課題となっていて、それについて考えていた。昨日書いた、関数ポインタを連想配列を使って選択するというのは悪くないと思っているのだが、それにどうやって引数を渡すのかが問題になっている。Phobosにbindというモジュールがあって、それとタプルを組み合わせれば上手く行きそうだと思って試してみたのだが、bindモジュールにバグがあるそうで使えない。タプルを上手く使えばbindなしでいけないか、と解決法を模索しているところ。
上手く行かなくても、関数ポインタの型ごとに関数呼び出しをラッピングする関数を一つ一つ作っていけば、難しく考えなくても済むし、実用的にも現在想定している範囲内において問題は発生しないのだが、それは美しさ的に納得できないので行き詰るまでは粘ってみる。

小説を読んでいて飛行機にあこがれたので、この頃無性に作りたくなっている横スクロールSTGと組み合わせて妄想してみたり。発想して、すぐに作れる時間が無いことは不幸。

今日の危険

・絵
・スクリプト関数呼び出し作成開始
大量の裏紙が提供されたので紙を贅沢に使って色々な絵を試していた。主に目の表現。その成果で目に感情をこめることが少しずつ出来るようになってきた。しかし相変わらずネックとなるのは髪の毛。

スクリプトについては今日はほとんど考えていなかったのだが、プログラミングがしたかったので、とりあえず考えてる実装が可能であるかの実験を行った。関数のポインタをBox型の、スクリプトでの関数の名前の文字列をキーとする連想配列に登録。Boxから直接関数ポインタ型へのunboxが出来なかったので、一旦voidポインタとして取り出してそれをキャストして関数を呼び出す。この手法でスクリプト上から引数1つでのwritefln関数の呼び出しに成功した。

昨晩よさそうな短編小説のネタを思いついたのだが、そのネタを生かす枠組みをどう構築するかがなかなか浮かばないので保留。そのうち書く。

今日の追尾

・弾幕作成

PythonDをやろうとしたら、使われているDのバージョンがだいぶ古かったようでコンパイルが出来なかった。そこで気合でコードを直してコンパイル通るようにしても良かったのだが、それは大変そうだったのでやめておいた。

それでパラボラをやろうと思ったのだがどうも見る気も起きなかったので、昨日作成したホーミングを使って弾幕を書いた。そのデバッグ中にプラクティスメニューのバグが出てきたので直した。現行のバージョンには関係のないバグなのでパッチは出さない。

PythonDが駄目だったのでもうひとつスクリプト言語として載っていたLuaを導入してみたが、まだ試していない。GimpのスクリプトとしてSchemeも調べてみた。文法はかなり気持ち悪く感じるが理解できないものではなさそう。

今日のなでしこ

・ホイール調査

・なでしこ

昨日に続いてSDLでのマウスホイールの動作について調べていた。SDLのソースを探していたらマウスホイールの上下を処理する部分が見つかったのだが、それが#ifdefとかで囲われていて実際にコンパイルされているのかがわからない。それともうひとつ、SDLでは本来はイベントを利用して入力を処理することを想定しているようだが、自分ではイベントをろくに使っていないのでそれが原因である可能性もある。ただそうだとすればなぜホイールだけ動かないのかという原因がわからない。結局調べても良くわからなかった上、他の操作方法も思いついたのでホイールは諦めることにする。

パラボラの物体の軌道を計算するために必要な積分を解いてみようと取り組んでいたが、どうにも解けそうな気がしなかったのでやはり力押しで攻めることにする。その他の課題となりそうな場所についてもいろいろと対策を考えてみているが、まだ実装していないのでどうなるかがわからない。

なでしこはプログラミング初心者へ教えるのに、どれぐらい良いのかと思って試しに使ってみた。第一印象としては構文を覚えようという意思がなくても、結構自然な日本語で記述ができるのでわかりやすいという印象。しかし、グループと配列とを組み合わせて使い始めてからわかりにくく感じた。ドキュメントを見た限りでは意味が同じであるように感じられた複数の記法が、別のものを組み合わせると違った意味となってくるという点で難しかった。具体的には、配列の要素番号の書き方。文法が厳格なほうが使いやすいということもある。Pythonなんかは多分その究極。

今日のりんご

・パラボラ製作

・復讐絵

今日は主にパラボラを作っていた。とはいっても暇すぎて積分を解いている暇がなかったのでシステムを組んでいた。重力といったらりんご、ということで、物体のクラスの名称をAppleにしてみた。本当はObjectとか使いたかったのだけれど、それは全ての根本クラスの名前として使われているから使えない。

で、マウスでの操作を作っていたら上手く動かないところがあって、原因を調査したらSDLではマウスホイール上下が宣言はされているけれども、実装がされていないらしいという事実が判明。SDLのソースをざっと見たがそれらしい部分も見つからない。なので自前で実装するか、それとも他の操作方法を考えるかしないといけない。

それと、気が向いたので復讐の絵をいじっていた。主人公の正面からの絵をとりあえず描き終えて、その他キャラクターの絵を微調整。ゲーム内では使う場所がないと思っているが原画として使うので形は細かく描き込んでいる。そしてさらに暇だったので会話窓用の大きい顔グラフィックを描き始めてみた。目は練習している成果かそれなりになってきたのだが、今度は小さいサイズでは全く気にしていなかった髪が問題として立ちはだかってきた。

今日の部分

・遺伝的AI考察続き
何故か今日はずっと遊んでいたのであまり書くネタがない。ので、昨日の遺伝的アルゴリズムによる格ゲーAIについて。
遺伝的アルゴリズム単体を使用してAIを作るには格ゲーのAIは複雑すぎる。そこで、行動パターンをAIにあらかじめいくつか与えておいて、それに優先度を設定して動くAIという設計にする。そしてその優先度をどう設定するかを遺伝的アルゴリズムを使って求める。問題としては相変わらず遺伝子の評価値がある。格ゲーだと同じ状況でも乱数によって違う行動ため、一度の対戦だけでは評価値を正確に求められない。その結果対戦数を更に増やさないといけない。
状況を適当に区切って、その状況内での優劣を計測すると速くなるかもしれない。
どうにしても、実際に作ってみないことにはどうなるのかが分からないのが難しいところ。

今日の遺伝

・遺伝的アルゴリズム考察

・育成型弾幕STG試作

もう日付が変わっているわけだが。

巨大なボスが出るようなSTGを妄想していたら、多関節→ツリー構造→遺伝的アルゴリズムと変な具合に思考が飛躍したので、遺伝的アルゴリズムについて調べてみた。AI関係の本とかをあさったりもしたが結局Wikipedia以上の情報はなかったし、それで恐らく全てなのだろう。

興味深いので使ってみたいと思っているのだが、思いつく使い道がAIの作成と弾幕の作成しかない。しかし遺伝的アルゴリズムの前提として、遺伝子の評価値の導出が簡単であるということがあるそうなので、AIも弾幕もあまり合わない。

AIは格ゲーか戦略系のゲームを考えているが、評価値を求めるにはAI同士を戦わせる程度しか思い浮かばず、十種類の個体を十世代進めるだけでも結構な時間を要しそうなので厳しい。それで作るAIが一つだけならまだしも、格ゲーであればキャラクターごとに別のAIにする必要があるのでさらに時間がかかる。あとひとつの遺伝子に相当する、AIの思考モジュールの単位をどう扱うかという問題もあって難しそう。

弾幕は、評価値を求めるには人間が避けるか弾幕を避けるAIを作って避けさせるぐらいしか浮かばないのだが、前者では人間の労力が大きすぎ、後者ではまともなAIをどう作るかという問題が生じる。弾避けAIを作るには、人間が作ったまともな弾幕を使って学習させるのがいいのだろうが、それもまた手間がかかる。

 

遺伝的アルゴリズムについてこういった思考を展開したあと、ツリー構造が使いたくなったので育成型弾幕STGを試作してみた。ボスを育成して大きく・強くしていくというコンセプトで試作してみたのだが、頭に描いていたイメージよりも美しさが全くなかったので没ろうかと思っている。ボスのデザインをもっと愛着がわくようなものにすればいいのかもしれないが、それだと巨大化させていくうちにどんどん妖怪になっていくので幾何学的な図形にするしかない。

構造がいかにも遺伝的アルゴリズムを使いたくなる形だったのだが、やはり評価値が越えられない壁として立ちはだかる。

今日の制御

・ピストンコラージュD言語対応
・パラボラ曲試作
・文字列描画強化
・復讐会話スクリプト試作
昨日日記を書いた後、WindowsAPIをいじったのだからピストンコラージュのDLLのインポートヘッダをD用に書くぐらい簡単ではないかと思ってやってみた。以前やってみようとしたときはLPSTRとかのWindows関係の型を見て嫌になったのだが、耐性が付いて無事に書けて実際に動かすことにも成功。

更に昨晩深夜、眠れなかったので妄想をしていたら曲のような物が浮かんできたので打ち込んでみた。頭の中にある短いフレーズを実際に鳴らすというだけで苦労したので、やはり向いていないのだと改めて思った。昔習った音楽理論もすっかり頭から抜け落ちているし。

今日の作業はここから。
物理ゲームはどうにもモチベーションが湧かないので久しぶりに復讐をいじっていた。
まずは前々から作ろうと思っていたが放置されていた文字列描画の強化。改行のある文字列を簡単に扱えるようにした。その際にフォント周りも一緒にいじっていたら、書き間違えて文字サイズが小さくなるというバグを作ってしまった。文字描画には地雷があるというような話を聞いていたせいで、バグの原因がそれにあると思い込んで大変な目にあった。
それが済んだ後本題であった会話スクリプトの実装を開始。文法を決めて、それを読み込む部分と、読み込んだ文字列をとりあえず描画する機能を作成。蘇生の文章管理の方法がかなり酷く、シナリオを書くのから遠ざかる一因にまでなっているので、その二の舞にならないように力を入れている。

D1.040がリリースされていた。MacOSXについに対応したらしいが、Macは使ったことがない。

今日の本選

・JOI本選

昨日今日とJOI本選にいってきた。今年ずっとの連続更新記録が途絶えた無念。

本選問題はやや解けた。クイックソートの使い方を知らなかったことと、scanfの使い方を十分把握していなかったことで得点がだいぶ落ちた。高速なソートぐらい勉強しておけばよかった。

JOIでやったことがゲームプログラミングにおいてどう役立つかを考えてみたが、どうも当たり判定の軽量化ぐらいしかないらしい。でもそれも2Dでは実際に効果があるかわからない。ホーミングの処理に使えるのではないかと思ったがそれも微妙。

 

ゲームの面白さについて考察してみた。「一杯のお汁粉はおいしいけれど面白くない。百杯のお汁粉はおいしくないけれど面白い」という理論で、ゲームの正統な面白さの方向で行き詰ったら、別の軸へ向かって伸ばすことでゲーム全体の面白さが成立する、というもの。問題はその別の軸をどう見つけるか。お汁粉は量という軸でいけるが、ゲームは別の軸がグラフィックやら音楽やらシナリオやらとすでに出尽くしている感がある。

今日のピラミッド

・弾幕作成

暫くぶりの弾幕作成。レーザーで遊んでいる。それと、蘇生5面の道中の構成を妄想してみたり。今までと製作の順序が逆転している。弾幕のネタが浮かばないのが大きな要因。

 

明後日はJOIなのだがろくに準備をしていない。アルゴリズムを広く浅く学ぶなんてことはできないし、ヤマを張って当てたところでそれが何かの役に立つわけでもないから。行雲流水の如く。

今日の素朴

・絵制作

・JOI勉強

描きかけだった絵を仕上げた。これで主要なボスキャラクターの正面からの絵が揃ったわけだが、肝心の主人公の絵はデザインすら、ちゃんと決まっていない。主人公はただの人間なので装飾をつけにくいのが問題のひとつ。それにしても目のデザインが違うだけで印象が大きく変わる。

JOI三日前なので最低限の勉強を開始した。DでやっていたことがCでもできるようになったところで、昨年の本選の1番を素朴に解いた。ソートのアルゴリズムも勉強したが役に立つかは不明。予選でやっていたことからのパラダイムシフトがないとまともに解ける問題がないように見えるが、3日程度でそう考え方を変えることができるかは甚だ疑問。

今日の設計

・復讐設計変更

昨日課題として出てきたステージの管理方法。もともとは敵をステージ内でどのように管理するかというところからでてきたのだが、その設計を考えていたら、ステージを使ってゲーム内の全てのオブジェクトを管理してしまうということになった。

大幅な設計の変更だったので、Poseidon付属のファイル圧縮機能を使ってバックアップをとってから組み始めた。それで、予測したとおりに動かなくなったので、バックアップを参考にして調べようということになったら、圧縮されたファイルが解凍できなくてはまった。結局フラッシュメモリに以前バックアップしたソースを参照した。

それでも詰んでいて、原因不明で呻っていたら原因が見つかった。原因は、コンストラクタ内で生成中のオブジェクトを参照していることだった。冷静になって考えてみれば、

hoge = new Hoge();

と書いた時に、コンストラクタが終わるまではhogeに値は返されず、そのためコンストラクタの中ではhogeは初期化されないのだから当たり前といえば当たり前。結局コンストラクタ内に書いてあった処理を丸々別の関数に移転して、コンストラクタが終わったあとにその関数を呼び出して解決。

今日のXNA

・C#とXNA導入

興味があったので導入してみた。感想としては、C#は結構使いやすい。D言語と似ている部分が結構あるので習得も簡単そう。VisualC#はC++よりも機能が強力に感じる。

そしてXNAも導入。ほとんどコードを書かなくても動くのが不思議な感覚。今のところは2Dのテクスチャの描画と2Dの文字列の描画と入力を受け取るところ。3Dモデルの描画を試してみようと思ったが標準で付いていなかったことには若干驚いた。手書きしてもOpenGLで自作するよりははるかに短いコードで済むようだけど。

少し触った感想としては悪くない感じ。機能の全貌をまだ見ていないからまだはっきりとしたことはわからないが、こだわって作るのには向いていそう。ひとまず卓球をXNAで作ってみようと思っている。

今日の3次元

・復讐構想

・3Dシューティング風作成

昨晩、イベントエディタができてそれでイベントを書いていて、セーブイベントを作るかどうかと考えたときに、復讐をいったいどのようなゲームにするのかを明確に決めていないことに気が付いた。

横スクロールアクションということは、作っていたのだから決まっているのだが、それでシナリオ性のある長いマップにするのか、それともストーリーはあまり語らない短いマップにするのかが未定だった。で、そのときに思いついたコンセプトが「スコアアタック」。クリアするだけであればあまり難しくないが、スコアを稼ぐための高度なパターン化や精密操作を要求するというやりこみ属性。いわばシューティングの精神をアクションゲームに当てはめたという感じ。

 

今日作ったのは3Dシューティング風。弾幕を3Dにしたら面白いという話があがって1時間程度で作ってみた。弾が3Dで飛んできて当たり判定も3D。ただ、3Dで何かを作るときに常に壁となるのが操作方法。ボタンを押すことで操作する座標軸を切り替える、というようなシステムを考えては見たが多分使いにくい。

これはもうこれ以上作り進める気はないが、卓球に向けた3Dの練習にはなった。あとglutを使うと落ちることも確認。gluは使えた。

今日のループ

・全方位STG製作中
ロックシステムを改良した。具体的には、ロックボタンを押すとロックの射程内に入っている敵全部を仮ロックして、仮ロックされた敵をロックする。ロックした対象はA/Sキーもしくはロックしている敵を倒すことで他の仮ロック中の敵に切り替える。
これの、A/Sキーで対象を切り替える処理を書いているときに詰んだ。原因は配列のlengthプロパティの型がintではなく符号なしであったことだった。たしかにlengthは負の値をとらないので当たり前といえば当たり前なのだがわかりにくいと思う。あと%演算子の動作が正確にわからなくなって、調べようと思ったのだがあまりに当たり前のこと過ぎて載っていなかった。
結局％演算子を使わずにいちいちキャストすることで解決したのだがうまく書けない物か。

ロックする順番を敵配列のインデックス順から距離の近い順に変えたら全方位STGとして特徴的なシステムは完成。どこまで作りこむかが問題。どうせなら遊べる形にまで作ってしまいたい気もするけれどそれをやっても特に得られるものがない。と、いうわけでリクエストがあれば作る。なければ復讐の製作を再開するなり蘇生のレーザー周りを使えるようにするなり。物理ゲームもそろそろ再開しないといけない。

今日の平

・新年
・全方位STGプロトタイプ作成
新年記念。http://cid-eccdf3ba5a7e82b6.skydrive.live.com/self.aspx/.Public/nenga.lzh
だいぶ前に作ったものであるのは秘密。何が記念かは知らない。よくわからないバグがあるけれど動くから気にしない。

SSが一段落したので前々から作りたかった全方位STGを作り始めた。以前作ったシューティングテンプレートをベースに進めている。その前に自作D言語SDL+OpenGLライブラリの整理と、FPS管理の修正を行ってすっきり。
今日作ったのは照準の操作と、敵をロックオンする機能。現状では一番近い敵を毎回ロックオンして、範囲内に敵がいなければロックオンを解除するという形。これでは使い勝手が悪いので一番近い敵以外にも切り替えられるような方式にしたいのだが、敵との距離が変化するのでどのようなシステムにすればいいのかを考えている。

昨日出した蘇生についても触れておくと、蘇生の完成期日が5月の末ごろ。そろそろストーリーも書きたくなってきたので5面の作成とストーリー執筆とを並行して進めていく予定。5面ではレーザーを登場させたり、ビットを使う弾幕を出したりといろいろ新しいこともやりたい。あと道中も激しくしないといけない道中なので激しくする。5面の完成は3月中が目標。

とまあ、今年も特に代わり映えなく過ごしている。この一週間ぐらいはこの全方位STGと復讐とをちまちまといじっていようと思う。今年はプログラムを書く時間をPC使う時間中で半分以上の比率にするのが抱負。そうでもしないと復讐が間に合わない。