Game Graphic Text Link Blog Index
2006/04/30

x[kai]

今日も静々とコードを書き続けた。

マスタースイッチ(オーバーライド)機能以外のスクリプト処理が完成。

後、内部処理もスリム化し、なんとか動く状態から綺麗に動くものへと変貌してきた。

2006/04/29

x[kai]

色々考えた末、boost::regexを使ってスクリプト処理をすることにした。主な理由は2つ。

一つは現在のスクリプトをベースにした新スクリプトの案がある程度固まっている。どっち道次のRPGで使用するなら、繰り上げて使うのも悪くないかも。

もう一つは前回も書いたけど、やはり今のスクリプト ではどうしても限界がある。特にアニメに関して。

ちなみにこういう風に変化している。

・最初・GBS・前回のデモ。
BegPos 200,100,0
EndPos 300,100,0
DurPos 5

これは始まりと終わりを指定して、5秒間で右に画像を移動させるスクリプト。

・バトルデモ。
Position 200,100,0
Position 300,100,0
Position 200,100,0
DurPos 4

これはPositionがBegPos/EndPosに代入されて、複雑なアニメを可能にしている。ちなみに、200から300まで2秒。そして300から200までまた2秒。

・今日。
Position 4
{
200,100,0
300,100,0
200,100,0
}

上の例とまったく同じだけど、見やすくなった。将来の拡張性も申し分ないはず。

2006/04/28

ゲームの良い案が浮かばなかったこともあり、今日はブログのコードを少し弄っていた。

一番追加したい機能である「コメント/拍手」ボタンはまだ少し先になりそう。ある程度完成しているけど、管理画面とでも言えるものがまだ出来ていない。

裏方の方さえ完成すれば、もっと多機能なブログになるのに・・・・・・。5月の目標の一つになるだろう。

2006/04/27

x[kai]

バトル画面でのアニメに関する手法がある程度全て完成したので、実際に動かしてみた。

攻撃アニメーションは3つのパートで構成されている。
1.攻撃を加えるドット絵が前進。
2.攻撃アニメが表示される。
3.攻撃対象が後ろに飛ばされる。

このうち、2と3は少々重複する。

プログラム上1と3は何の問題も無く動く。厄介なのが2。スクリプトには高度な表示/非表示機能とスプライトアニメ処理機能が無い。

両方とも1と3の手法を真似て追加データで処理できる。しかし、そうなると更にデータが膨大になり、不必要なデータも色々と書き込まなくてはいけなくなる。

どう処理すべきか、少々検討しないといけない。


2006/04/26

今日は製作に使っているマシンのOSを入れ直した。この間ニューマシンを作った際、RAID0を使ってみた。一つのハードディスクとRAID0の性能差を測るために色々とベンチマークソフトを入れたため、結構レジストリが汚くなっていた。

そこでそろそろ頃合かな、と思い再インストールを実行した。流石に3回目だけあって、セットアップも順調に終了した。アプリケーションも半分以上インストールし終わったし、月末の数日はプログラムに専念できるだろう。

2006/04/25

x[kai]

今回も前回同様一つのマスタースイッチで複数の画像を処理する方法を考えていた。結論として、スクリプトを大幅に変える以外、方法は無い。

しかし、このゲームにおいて、この機能が必要なのはこの一ヶ所だけ。他は既存のスクリプトで100%出来る。

そう考えると、ハーフスクリプト・ハーフハードコードが魅力的に見えてくる。いちばん簡単なオプションでもあったから、試験的に試してみた。

結果は大成功。コードが少し汚くなったけど、目に見える一番面倒な処理が完成したのだから、あまり文句は言えない。



2006/04/24



LittleBusters!の宮沢謙吾を追加。

4人目にして最後の一人でやっと自分で納得できるドット絵が打てた。以前のと見比べると、男ドットということで顔を小さく打ちすぎたのが問題みたいだ。

2006/04/23

x[kai]

今回は前回の入力受付を更に進めて、コマンド選択を出来るようにした。実は結構大変だった。

コマンドの表示には複数の画像が関係しているから、それを全て処理するための手を考えたり、コマンドの画像もバーによって変えたり、と色々実装した。

一つのスクリプトアイテムで複数のスクリプトアイテムに影響を及ぼすのは思った程綺麗に出来なかったので、そこらへんは将来的に変更を考えるべきかもしれない。

2006/04/22



LittleBusters!の直枝理樹を追加。

上手く打てたはずなんだけど、雰囲気が・・・・・・。

公式絵で後ろを向いている主人公というのも面白い。何か理由があるんだろうけど、ドット絵でそれを再現しようとすると何か企んでいる危ない男にしか見えない。

2006/04/21

x[kai]

今回は前回の続きで入力受付を実装した。入力自体はGBS!でもやっているから簡単に出来た。

ただ、ループさせているものを途中で止めたり、再始動させるのには少々手間がかかった。どうしようか迷ったあげく、ループには手をつけず、ループの「更新せよ」という命令を止める方法にした。これにより、停止と再始動が一つの場所で管理できるようになった。

2006/04/20



LittleBusters!の棗恭介を追加。

男4人の中では一番上手く打てているドット絵。ただし、元絵に一番似ていないドット絵でもある。

2006/04/19



LittleBusters!の井ノ原真人を追加。

初のリクエストが男というのも珍しい、と思う。良い機会だから打ってみたけど、まだまだ精進しないといけない。

女性ドットより一回り高くして、顔を小さく打ってみた。ただ、「これだ!」と思えるバランスにいまいちなっていない。

2006/04/18

x[kai]

今日は自動ループの機能を完成させた。前回用意した完成バーは一度100%まで行くと止まった。しかし、本来なら、入力を受け付けてから0%に戻らないといけない。

最初は入力受付をやろうと思ったけど、それだと問題がおこった時に入力が失敗しているのかバーのリセットが失敗しているのか解らなくなる可能性があった。

そこで、とにかくバーのリセットを先にやることにした。機能そのものは成功した。しかし、コードそのものを弄らないと上手くいかない個所も見つかった。入力受付を実装した後に少々コードの整理整頓をしないといけない。

2006/04/17

さて、今日もリトルバスターズ!のドット絵の続きを打っていた。4人全員ある程度完成した。

明後日くらいから二日に一枚のペースで公開できるはず。

2006/04/16

リトルバスターズ!の男ドット絵を現在打っている最中。以前は一人完成、全員完成、一人一人リミックスという3段手順を用いていたけど、それだと一人完成するまで時間がかかりすぎる。

そこで、一人一人8割完成させたところで一旦止め、全員出揃ってからリミックスをかけるようにしたら良いのでは、と思い立った。

この方法だと必要な時間を2/3に短縮できそうだ。それにこの方法だと最低二人を一緒の日に打つため、どっと絵間の統一をはかりやすい。

途中製作物を公開できないのは少々マイナス。まあ、出来は見てのお楽しみ。

2006/04/15

RPG



これが現在の画面写真。赤の四角がプレイヤーが操作できるスプライト。白が境界線のため、赤は白枠の外に出ることが出来ない。

ただ、今は4つの端しかチェックしていないため、背景に不自然にのめりこむこともある。外のピクセル全てを確認していたら時間がかかりすぎる。その中間である、4ピクセルごとにチェックをやるとちょうど良い具合になる。

2006/04/14

RPG

マップを表示する際、タイルを使うのが一般的。しかし、個人製作だと膨大なタイルを作るのは非現実的。そこで、3Dでごまかせないか、と考えている。2Dのアングルでカメラを固定すればなんとかなりそう。

しかし、そうなるともう一つの問題がある。ゲームでは見えるタイル一つ一つに色々な附加情報がある。一つはそのタイルの上に乗れるかどうか。例えば壁のタイルがあれば大抵は通過不可になっている。

その問題を打破するには通過できる場所と出来ない場所を3Dにも簡単に応用できるシステムがいる。簡単に言うと、通過可能・不可のデータがそのまま3Dの世界の基礎になる。

テレインと呼ばれる3Dの世界は基本的に0から255で高さを表している。そうなると、テレインみたいな2色の画像を用意して、1が通過、0が通過不可にしたら良い。その後、テレインを作る際、その画像を読み込んで、そこからテレインを作れば良い。

2Dの画像のほうは出来たら、まずはそれの画像を明日公開する。

2006/04/13

x[kai]



昨日1ピクセル幅を伸ばしてなんて言ったけど、実装してみたら上手く動かなかった。伸ばした画像がなんらかの理由で滲んで見えた。で、理由を探してみると、スプライトの透明色が問題だった。伸ばしたとき、伸ばされた部分は見える色と透明色の中間色になっていた。

代案として、透明色無しにしてみた。そしてそれはある程度見事に成功した。

唯一の問題は左右1ピクセルほど隣のスプライトが滲みこむこと。ダブルバッファでは処理が追いつかず、残像のように見えるのだろうか?トリプルバッファに移行したら直る可能性もあるけど、今はこのまま行く。

見た目が問題だから、ここは伸びるスプライトを伸びないスプライトに1ピクセルだけ重ね合わせた。伸びるスプライトが下にあるため、滲みこんだデータが表示されない。

アップした画像は左が行動バーのサンプル。同時刻に開始したけど、片方のほうは早く終わる。右はクロスフェードのテスト。服を着ている画像がフェードアウトして、服を着ていない画像がフェードインしているところ。


2006/04/12

x[kai]

今日は行動可能になるまでの時間が視覚的に判るよバーを用意してみた。FFのATBを思い出したら良いと思う。

幅を大きくするのだから1ピクセル幅の画像を用意して、それを100ピクセルまで伸ばす。それをするにはスケール変更をするのだけど、GBS!時代にはそんなのは必要なかったので、当然未実装。

そこで、またスプライト関連のコードを弄って、スケール変更を可能にしておいた。

明日にも新しい機能を見せびらかしている画像を用意する。

2006/04/11

x[kai]

今日はバトル画面に画像を表示させることを主眼において作業をした。

ゲームの仕様上、ダメージをある程度受けると、服が無くなっていく。以前は画像を差し替えていただけだけど、大幅にパワーアップしたスクリプトエンジンを使ってクロスフェードが出来ないか、試してみた。

最初は少々梃子摺ったけど、5分くらいで完全に制御できるようになった。良く考えると、シナリオ本編でも色々使えそうな場面がある・・・・・・。特に背景チェンジの時なんかに。

2006/04/10

x[kai]

新しいシステムに合わせるために画像のフォーマットやサイズを変更していた。他には無い背景画像のリストを作ったりして、裏方作業に徹した。

そこで一つ気付いたのは、一昔のドット絵の出来の悪さ。8割以上はなんとか見るに耐えるけど、他の2割は壊滅的。特にモンスター系ドットの出来には軽いショックを受けた。

デパオクの怪獣ショーに出てくるようなのは避けようと努力したけど、やはり関節の不自然さが目立つ。

打ち直す時間は無いけど、このまま世に出すのも辛い。出来のもっとも悪いのを8体位選んで、それだけ変更する、というのも手かもしれない。

2006/04/09

x[kai]

今日は紙にこれからどうするかをだらだらと書き連ねていた。仕様なんかはどんなに上手く決めてもコロコロ変わるものだけど、ある程度の道筋を立てないと遠回りは避けられなくなる。

カードバトルはシナリオパートと同じスクリプトエンジンを使うとはいえ、かなり勝手が違う。そこで、今ある機能とこれから追加しないといけない機能のことを考えていた。

まずは分岐をどうするか。一つのスクリプトファイルにフラグを立て、飛び飛びにするのが一つ。もう一つはフラグごとに別ファイルに行く方法。現在は処理の簡単さから後者に傾いている。前者も前者でメリットがあるので一概にどっちが良いとはいえない。

次は時間停止。各キャラの行動順は時間によって決定される。しかしプレイヤーが行動を決定している間、時間は凍結される。ただし、プログラムで時間を凍結する方法は無い。ここはこれから追加しないといけない。ただし、全凍結は駄目。なぜなら、キャラの攻撃アニメーションの最中にプレイヤー選択がまわってくる可能性があるため。

ということはプレイヤー選択画面が出ている間のみ特殊なフラグが立っているスクリプトの項目だけアップデートを禁止する、という風に処理することになる。上手くいくかどうかは試してみないと判らない。

2006/04/08

RPG

RPGと一言で言っても星の数ほどある。近々取り掛かるRPGはこんな感じにしようと思っている。

マップ画面での動きはSFC時代のもの。上からの見下ろし型になる。FF6を思い浮かべたら私の考えに近い。バトルはクォータービュー。今公開しているドット素材と同じ感じ。

バトルシステムはターン制では無くATBを発展させたものにしようと考えている。詳しくは上手くプログラムできてから解説する。

キャラクターはほとんど固定してクラスチェンジによりゲームの幅を広げようと考えている。理想としてはFF3かな。FF5も良いけど、FF5は万能キャラが作れてしまってFF3ほど楽しめない。

基本的にはこんな感じ。次からはもっと具体的に書いていく。

2006/04/07

x[kai]

前回ゲームをアップする少し前、少々気になることがあった。ゲームそのものが起動するまで少し時間がかかりすぎていた。実際はロゴが入るためあまり気にならないと思っていたけど、それにしても遅い。

それと出力していたデバッグテキストも少々妙なことをしていた。画像であるスプライトを処理するコードが何回もイニシャライズ(=始めて読み込まれること)していた。画像が一つなんだから1回、又は2回のはずなのに。

そこで一つ考えてみた。スクリプトでは何回も同じ画像の違う部分を表示(=スプライト化)している。その際に画像を新たに読み込む必要は無い。しかし、この動作は画像を何回もハードディスクから読み込んでいるようにも見える。

で、画像ロードの部分を確認したら、確かにスプライトが呼ばれるたびに新しく画像をロードしていた。遅いはずだ!

画像がロードされたら同じ画像をロードしないようにコードを変えたら一発で問題が解決した。これで更に快適にゲームが遊べるはず。

2006/04/06

リトルバスターズ!のドット絵を某所で公開したら、男性キャラのドット絵も欲しい、とリクエストされてしまった。

原則的には女の子(とモンスター?)オンリーなんだけど、せっかくのリクエストを却下するのも忍びないから、4人分用意することにした。

今回はとにかくリミックスしないでも良いように最初から全力で打つことを目標に頑張ってみる。

2006/04/05

x[kai]



x[kai]1.3.1

さて、今回は試作品を公開。基本的にシナリオに必要な機能が全て動いている。時間が無かったから顔とテキストだけしか入れられなかったけど、次は背景とSEも足せると思う。

以前は二人のキャラが重なるとき、どっちが上に来るか決定できなかった。後に読み込まれた画像が常に上にあった。今回はそれを打破するためにZ軸に値を持たせた。2Dのスプライトでは見えないけど、後ろに表示されているスプライトは前のスプライトよりかなり後ろにある。で、その後ろに背景を置く予定。

重ねる時の表示が上手くいったら、今度は透過処理が出来ないのに気付いた。普通のフェードなら問題ないけど、フェードする画像が他の画像に重なっていると、フェードしたところが背景色で塗りつぶされるという問題に直面した。スプライトのレンダリングオプションでD3DXSPRITE_SORT_DEPTH_FRONTTOBACKを追加するだけで問題が直った。

最後にテキストを自動改行できるようにした。以前はDT_NOCLIPを使っていたけど、DT_WORDBREAKに変更することである程度問題は解決した。ただし、DT_WORDBREAKを使うには幅を指定しないといけない。以前は右と上だけで良かったからかなり大変。現在は「画面端 - 右」で計算している。

この方法ではテキストが中央に行けば行くほど、幅が狭くなる。そして真中から左側に始るテキストが表示不可能に。

そこで考えたのが、テキストでは未使用のZ軸を使うこと。Z軸に幅(正確には左)の値を記憶させれた万事解決。それにZ軸が0ならDT_NOCLIPで表示すれば良い。

3Dテキストがクルクル回転する際のことは考えていない。そういうのが無いことを祈るのみ。

2006/04/04

x[kai]

以前実装した機能がより高度に再実装されるところを見れるのは楽しい。それに懲りすぎて何も完成しない、というのも問題だが・・・・・・。

さて、今回はテキストが一文字ずつ表示されるように改良を加えた。テキストを一文字一文字表示するのは意外にもかなり簡単だった。前回までは更新の同期にさんざんてこずったのに。基本をしっかり作った分だけ、新機能の追加が簡単になっているのか、追加しないといけない機能がある程度解っているから、無意識のうちに実装しやすいようにプログラムしたのか。まあ、要は動けば問題なし。

唯一の欠点は文字列を表示するためのカウンタが無かったこと。プログラム内部で用意しようかと思ったけど、これが思ったより大変だった。

そこで、スクリプトエンジンにまた白羽の矢が立てた。テキスト表示をする際、画像に使う各種変数が未使用状態にある。そこでそれの一つを流用して文字の最大表示数の値を記録させておいた。

これで問題解決。スクリプトパートを動かすのに必要な全てのプログラムが完成した。少なくとも、そう見える。明日は実際に最初のバトルまでのスクリプトを書き上げてみる。問題がなければダウンロードできるものが出来るかも?


2006/04/03

x[kai]

快進撃は更に続く。

スクリプトで左に表示される顔は反転して表示させている。3Dで言うと、Y軸の回転ということにもなる。すなわち、昨日実装しなかった回転機能を実装しないといけないはめになった。そのうち、とは思っていたけど、まさか次の日になるとは・・・・・・。

クオータニオンなんてほとんど触ったことが無いから、上手くいくか不安だったけど、要はマトリックスと同じように扱えば良いだけだった。(原理不明でもアタリと思える数値を入力して上手くいくまで粘る。)5分もかからずこの課題をクリアできたのは良かった。

次の問題がテキスト削除関連。上と下にテキストが表示されるから、新しいテキストが表示されるたびに上か下のテキストを消さないといけない。そして、どっちを消すのか簡単にわかる方法は無い。前回は世にも恐ろしい方法でごまかしていたけど、今回はせっかくのスクリプトエンジンを無駄にしない意味でもスクリプトで直接処理させる方法を考えてみた。

解決方法はユニーク件(プログラム的に)美しい。スクリプトのテキストそのものにカウンタを用意し、更新されるごとにカウンタを更新すれば良いだけ。そのカウンタが0になると、自動的にそのテキストは消える、という仕組み。ちなみに負の値なのは動作終了後に画面に残す・残さないを管理しているKeepを拡張して使っているため。

そして、今日最後の難題が一度表示された画像をどうやって再処理するか。簡単に言うと、フェードインした画像を今度はフェードアウトさせるにはどうしたら良いか。表示されている画像を発見して、内部で書き換えるのは至難の業。特に特定できるものが無い場合。画像名ではスプライトを複数表示すれば候補が多すぎるし、複数のフィールドで一致を探せば処理が複雑になる。

逆に言うと、特定できるものがあれば簡単にことが運ぶ。そして、その機能はGBS!の時点で既に実装されている。それがユニークID。GBS!では船の名前の点灯と消灯に使っていた。それをスクリプトから使えるように直した。



2006/04/02

x[kai]

GBS!と同じシステムで製作を再々開始。GBS!の製作を始める前から基本プラットフォームとして使えるアプリを目指すと言ったけど、それが妄想かどうかこれで解る。

顔のスプライトは問題なく表示できた。船のスプライトを表示したり出来るんだから、ここら辺は出来て当然。

次にテキストを表示してみた。なぜか必ずスプライトの後ろにしか表示されない。すなわち、スプライトに隠れて文字が読めない、ということ。

文字とスプライトのZ軸が関係しているというのは直ぐ解ったけど、両方とも0のはず。そして、0なら描画された順に積み上げられるはず。文字とスプライトの描かれる順は問題ない。

内部的なことだろうから、スプライトのZ軸を0.01に設定。問題は瞬時に解決した。しかし、Z軸が0じゃないため、2Dマトリックス変形から3Dマトリックス変形に変えないといけなかった。その際、回転機能の再実装をしなかった。スプライトがクルクル回転することは無いと思うけど、将来的には直さないといけない問題。

最後に、スクリプトファイルが複数の行にわたったデータを読めないことが解り、そこでも頭を悩ませた。

例えば、ゲーム画面でこの文章が表示されるとする。

優花
おはよう、恵!
調子はどう?


スクリプト内部ではそのまま保存できたほうが編集しやすいし、プログラムに入れなくても話がだいたい解る。

ただし、複数行に跨ぐデータはプログラム上の処理が面倒になる。回避策としては、

優花_おはよう、恵!_調子はどう?

という具合に保存することも出来る。この場合、プログラムが_に直面すると、改行に変える。以前はこの方法を取っていたけど、やはり校正が面倒。

結果的には前者の方法をちょっと工夫して実装した。

この分だとスクリプト部分だけのバージョンを思ったよりかなり早く公開できそう。

2006/04/01

4月になったことだし、今回は3月の総括と今月の目標を立てようと思う。

3月の目標は「ブログ更新週五日、ドット絵追加週二日、Great Battleship!マスターアップの3つ。」前に二つは数字に換算すると、ブログ20回、ドット絵8枚になる。

実際は:
ブログ31回
ドット絵8枚
GBS!マスターアップ

今回はブログを始めてから初めてドット絵のペース配分が成功した。ゲームも予定通り完成したし、3月はほぼ思い通りに行った。

今月の目標:
ブログ更新週五回
ドット絵追加週一回
[x]kaiニューバージョン公開
RPGシステム周り解説
GBS!ページ作成

4月は以前に比べてかなり特色のあるものになると思う。ドット絵の追加がかなり不定期になるかわりに、動きを追加しようと考えている。

[x]kaiのほうはいつまでたっても最後の一山を越えられない状態が続いているけど、そろそろ逃げるのをやめて完成を強行しようと思っている。望みどおりいくかは判らないけど、遊べるものは完成するはず。4月で音以外を完成させて、5月で音+バグ取りで終わらせてみせる。

RPGの方は次のゲームと位置付けている。しかし、GBS!よりも管理しないといけないことが多いため、今月から基本的なシステム周りの話を進めていく。一つか二つ動いているものを見せられたら最高だけど・・・・・・。

GBS!ページ作成ではゲームコーナーに専用ページを設ける。これは簡単だけど、簡単故に後回しになる可能性がある。今月の目標に設定しておけば脳内重要度がアップして優先的に作るはず。


意見や拍手があればよろしく!

201210
201208
201206
201205
201204
201203
201202
201201
201112
201012
201011
201010
201009
201008
201007
201006
201005
201004
201003
201002
201001
200912
200911
200910
200909
200908
200907
200906
200905
200904
200903
200902
200901
200812
200811
200810
200809
200808
200807
200806
200805
200804
200803
200802
200801
200712
200711
200710
200709
200708
200707
200706
200705
200704
200703
200702
200701
200612
200611
200610
200609
200608
200607
200606
200605
200604
200603
200602
200601
200512