2009/02/28

今日の自前

・スクリプト構想

スクリプトのことを考えていたら、自前で新しいスクリプトエンジン実装する、という虚数解が導かれてきた。せっかくD言語というマイナー言語を使っているのだから、「ないものは作るしかない」の精神で自作。どういう言語にするか考えて、作りやすそうなLispのような設計にすることに暫定決定。Gimpのスクリプトをいじっていてだいぶ慣れてきたことが影響している。現在の進行状況はファイルを開いてコメント行を処理する機能を作ったところ。

ここ2日間、夢に弾幕が出るようになってきている。たまたま夢に出てきたので記録することもろくに出来ずにほとんど忘れてしまって、覚えているのが弾源が画面端を回りながら弾を撃ってきているという光景だけ。今晩見たら今度こそ記録する。

今日の分離

・絵

・スクリプト調べ

先日からの絵の仕上げ。気になる部分にアンチエイリアスをかけて完成。明日にでも公開予定。

復讐に使うスクリプトについて考えていた。Pythonは既存のものは古くて使えず、自前で作るのもC言語版ヘッダを見た限りでは難しそう。Luaは、新しいはドキュメントがややこしいサンプルコード一本でわからず、古いものは自前でいじる必要がありそう。あと、Luaに馴染めない。D言語をDLLを利用してスクリプト風に使うする、という手があるそうなのだが設計が難しい。結局どうするかが決まらない状況。メイン部分とスクリプトにしたい部分をコンパイルしわけて、スクリプト部分のコードをコンパイルしてリンクするだけで動かせるようにする、という手も考えたがメリットが薄そうで微妙。結局まだ解決していない。

2009/02/26

今日の陰影

・絵

プログラムを書かずに絵ばかり描いている今日この頃。先日からの絵に陰影をつけたりしていた。あとは一度描いた他のキャラクターを没にして新しく下絵を描いたところ。

2009/02/25

今日の全身

・絵

D+Luaを調べていて、サンプルの意味が良くわからなくなったのでLuaのリファレンスを読んだら、却ってスタックとかでよくわからなくなった。

それでLuaについては本に頼って勉強することにして、パラボラとかもやる気がしなかったので先日から描いていた絵をとりあえず完成させた。残すは陰影付けとアンチエイリアス。

最初の予定では顔だけのつもりだったのだが、せっかくなので全身絵にした。思いつくままに描いていたら、ちびキャラで以前書いたデザインとの間に若干の相違点が出てきたのでちびキャラをそちらに合わせることにする。

絵を描いているのもこの頃楽しくなってきた。

2009/02/24

今日の追尾

・弾幕作成

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

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

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

2009/02/23

今日のぼかし

・絵

・蘇生ホーミング作成

Gimpのガウシアンぼかしを使って、蘇生の絵をいじっていた。ぼかしをするだけでドットが滑らかに見えるようになって、フルスクリーン表示にも耐えうる見た目になって強力。ぼかしのやりかたで少し詰まった部分があったのでメモ。

ここで使用する画像は普通のビットマップファイル。まず、このファイルをGimpで開く。次に、レイヤのリストのレイヤ(背景という名前になっているはず)を右クリックして、アルファチャンネルを作成。それから、画像の透明色にしたい部分を選択してデリート。「色域を選択」とかがあるのでそれを使うと便利。そして一番罠となっているのがここで、画像メニュー→モードがインデックスになっているのをRGBに変更。あとはガウシアンぼかしを適用して、pngで保存。透過色がいらなければアルファチャンネルとかの操作は不要。

これで蘇生の絵をどんどん変換していたわけだが、やはり面倒で人間がやる作業ではないと感じた。そこで、スクリプトを書いて処理しようと思っているのだが、その言語がLisp。

それとは関係なしに、暇があったので落書きした絵が気に入ってそれをドット絵にして描いているところ。表情をつけるとなると目が結構繊細になってきて難しい。

あと、特に使う予定は立っていないのだが蘇生にホーミング弾機能を実装した。力押しで美しくないアルゴリズムなのだが、いつもの「プログラミングはパワーだぜ!」とでも。

2009/02/22

今日の落下

・パラボラメイン作成中
・絵
時間があって気力もあったのでパラボラのメイン、軌道の計算を書いた。しかし、というより予想通り、上手く動かない。どこかで単位が食い違っているのが原因ではないかと思っているのだが、それらしいところが見つからない。
もう一つありえる可能性として空間の曲がりによって半径方向にずれている可能性も考えられるのだが、そうだとしても解決方法が思いつかない。と書いたところで、日記の魔力によって解決法が少し見えてきた。正しいかは分からない。

パラボラを一通り書いたところで、絵の勉強を始めた。顔のアップを描いてみているところ。やっぱり髪は上手く描けない。

今日の複合

・パラボラ視点変更完成

視点を回転させる機能を作り忘れていたのでつけておいた。これで多分視点関係は完成。そろそろ本丸の軌道の演算を実装しないといけない。

復讐を作るのにPythonスクリプトを組み込もうと思ってPythonDを調べている。しかしドキュメントを見たところDのコードをPythonから呼ぶ方法はわかりやすく載っているのだが、PythonコードをDから呼ぶ方法が良くわからない。多分書いてはあるのだろうが例が見当たらないので困っている。

2009/02/20

今日の視点

・パラボラ視点操作作成
ホイールのことはすっぱりと諦めて視点操作を作った。操作がモデリングソフト風になってきている。
あと、折角クラス名をAppleにしたので投げる物体をリンゴの絵にした。縮尺がおかしい化け物リンゴ。

この頃作業ペースが落ちているので加速しないといけない。

2009/02/19

今日のなでしこ

・ホイール調査

・なでしこ

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

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

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

2009/02/18

今日のりんご

・パラボラ製作

・復讐絵

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

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

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

今日の積分

・弾幕作成

・パラボラいじり

弾幕を書いた。また特に必要でもないのにレーザーを使っている。下手すると弾幕の半分にはレーザーが登場することになるのではないかというぐらい。レーザーは弾消しが効かなかったりカスれなかったりと根本的にプレイヤーにやさしくない。

パラボラの背景を作成。時計の針を背景にすることで時間の進みとデザイン性とを両方得られる。

相対論の本がついに解くべき式までたどり着いた。が、微妙にややこしそうな積分の式が必要になっている。解けないようであれば力押しで区間を細かく区切ってそれぞれ演算してから足し合わせるという手段をとろうかと思っている。

2009/02/16

今日の上下

・蘇生バグ修正パッチ

・会話スクリプト強化

蘇生0.62パッチ。難易度が常に『小説』になる問題を修正。デバッグ用のコードが残っていたのが原因。正式な修正版のりリースはまた明日か明後日に。

復讐の会話スクリプトを微妙に強化。蘇生で作ろうと思っていながら諦めた、行ごとの色変えを実装した。あとは主人公の横顔を紙に書いてみたり。

2009/02/15

今日の部分

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

今日の遺伝

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

・育成型弾幕STG試作

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

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

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

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

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

 

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

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

2009/02/13

今日の鎖

・会話機能製作中

・弾幕作成

会話機能を昨日書いてから、設計を特に考えずに書いていたということに気が付いて、設計を一度落ち着いて考えてから書き直した。それで設計段階で決めた、改ページ処理とイベントからの会話呼び出しを製作。あまり意味もないのに再帰を使って遊んでみた。

以前書き留めてあった弾幕のアイデアを思い出して、それをアレンジして作った。レーザーを乱用しすぎている今日この頃。

 

復讐のToDoがもはや絵を描くぐらいしか残っていない。いまだに主人公のデザインが確定していない困った状況。

2009/02/12

今日の制御

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

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

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

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

2009/02/11

今日のフォント

・蘇生情報追加

・システムフォント読み込み作成

ウェブサイトを更新。蘇生の情報を書き足しておいた。

ゲームを配布するにあたって、わざわざフォントを配布するのは容量が大きすぎて面倒なのでシステムフォントを読み込む機能をライブラリに追加した。DでWindowsAPIを使うのは初めてだったが、extern(Windows)のあとに関数宣言を書くだけでいけた。見づらいように感じたが妥協する。

今日の遠方

・相対論勉強
・弾幕進行
相対論の勉強を続けている。シュワルツシルト解が出てきて、もうすぐ座標を時間の関数で表せるようになる。あと表現の仕様も固めておいた。
弾幕は中途半端だったものを進めておいた。弾幕を書くペースも随分落ちていると感じる。

実は作ろうとしている物理ゲームでRe:Actionが一番難しいのではないかと思い始めた。技術的には2Dで質点の古典物理しか扱っていないけれど、ゲームにするという点で難しい。

2009/02/09

今日の計量

・弾幕作成

・相対論勉強

弾幕を書いた。ネタ切れ感あふれる弾幕。

JOIが終わって一息ついたので相対論の勉強を久しぶりに再開。以前一度ざっと読んだ本をもう一度最初からゆっくりと読み進めている。二週目だと理解度が上がる。数日のうちに必要な式へたどり着きそう。

2009/02/08

今日の本選

・JOI本選

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

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

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

 

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

2009/02/06

今日のピラミッド

・弾幕作成

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

 

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

2009/02/05

今日の素朴

・絵制作

・JOI勉強

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

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

2009/02/04

今日の輪郭

・Re:Action構想いろいろ

・絵作成

アイデアが降っては来ないが、暇があったのでどうすればバランスが取れるかを考えてみた。およびその案を実装している。その案だとシステムの車輪の片方が崩れてきて、それとフィーチャーとして考えているアクションの存在意義が薄れてきそうな見込み。その案の一部は採用して、他のアイデアが降って来るのを待つということになりそう。

それで時間を持て余したので復讐の絵を描いていた。今までは紙にはほとんど書き出さず直接ドット絵を描いていたのを、趣向を変えて紙に下絵をある程度書いたあとその輪郭をドットで打って塗るという方式に変えてみた。それで今は水のボスを描いた。主人公は横顔問題含めて絶賛放置中。横顔も紙に書き出したりすれば何とかなると楽観視している。

2009/02/03

今日のマウス

・Re:Actionマウス操作対応

・Re:Action新背景製作

・新作製作開始

ゲームをやっていたらRe:Actionの入力にはキーボードよりもマウスのほうが向いているのではないか、と思ってマウス操作に対応させてみた。それに伴いライブラリのマウス関係の機能を強化。

それと背景に内トロコイドを使っていたのをいじって、背景に線を使うようにしてみた。どうしてかはわからないが3Dのように見えて綺麗。

そのあとRe:Actionを暫くテストしていたのだが、質量が重いと敵との衝突でぜんぜん動じないため、下手に動かずにいたほうが安全という状態。なのでそれを改善しようと思っているのだが、今思いつく限りの方法では上手くいかないのでアイデアが降ってくるまで熟成させておくことにした。

 

その間物理ゲームを進めないで置くのもどうかと思ってパラボラマスターのシステムを組むことにした。物体の挙動は式を使える形に整理できるまで書けない。

opCallとopIndexが便利。

2009/02/02

今日の模様替え

・サイト模様替え

・Re:Action進行

・復讐絵制作

数日前に書いた、模様替えを適用。フレームを廃止して、CSSを使ったデザインにした。HTML,CSSは手書き。あまり変な事をやろうとしなければ、HTMLはあまり覚えることがなくて楽。メニューの項目を毎回コピーして書いているのだが、それを外部ファイルにまとめるようなことはできないものか。出来るのであれば教えてもらいたい。あと、地味にディレクトリの区切り文字がローカルのものと違っていて嵌った。

Re:Actionもちまちまと。壁との衝突処理で、テストとして書いた部分を直していなかった場所があったのでそれを直して、それと演算子オーバーロードの間違いを修正。画面がさびしかったので内トロコイドを使って背景を作ってみたが、背景としては主張が強すぎるのが悩み。そのまま弾幕になりそうな感じの背景。

昨日いろいろとやっていたので今日も結構絵を描いていた。主人公の横顔を書いていてどうにも上手く描けなかったので、思い切って正面からも新しく描き直して見た。しかし締まりがなくて困ったので放置した。

その代わりに、二転三転していた土属性のボスを描いた。結局虚数方向へと転んで天使だかシスターだか死神だかわからないものへと落ち着いた。それで残るは水属性のボスだけとなり、描いてみたが思ったように描けない。実際の設定と脳内設定で矛盾しているのが原因かもしれない。

2009/02/01

今日の崩し

・絵いろいろ

どうもプログラムを書く気がおきなかったので絵を描いていた。プログラムを書かなかった一日というのは何日ぶりか。JOIまであと1週間だというのに。

前から溜めてあったキャラを実際にゲーム中で使うために、横を向いた姿を描こうとしたのだが全く描き方がわからない。特に横顔にどうパーツを配置すればいいのかがかなりきつい。ゲーム中としては正面向きよりも横向きのほうが見る機会が圧倒的に多いため、まともに描けないといけないので困った問題。

描けない理由の分析。

・人間の顔は横から見ることよりも正面から見ることのほうが多い。横から見る場合よりも正面から見るほうがまじめに見ている。その結果横顔についてのデータベースが自分に不足している

・リアル以外の人間の顔も真横から描かれることが少ない。やはりこれも横顔のほうが印象が薄い。

・Z軸のない世界に生きている。そのためX-Y方向から見てばかりでZ-Y方向から見ないし、見えない。

解決策

・髪などで全部隠す。-表情が見えない。アニメーションさせるときに髪をいちいち揺らさないと不自然なので描くのに手間がかかる

・そもそも描かない。-開き直ってZ軸なしにするということ。つまりみんなペラペラ。見分けをつけにくい。

・常にカメラ目線のキャラクターたち。-キャラクターが自意識過剰になりすぎる

・常にややカメラ目線のキャラクターたち。-斜め前を向いている。微妙に描きにくい。微妙に自意識過剰。

4番目をとりあえず採用してみることにする。

 

あと、気晴らしに蘇生の5面の雑魚敵を描いて見ている。小さなサイズでそれなりに描き込む必要性があるので、デフォルメをどうするのか考えている。デフォルメは苦手なのでこれもまた難しい。