突然ですが爆ボンバーマンWikiを始めました。
なんというか、メテオスWikiに触発されました。
とりあえずWikiにしときゃあ何かあるだろう的な考えの元、深く考えずに作ってみました。
Bomber丸Worldが完成したら、私の干渉しない、ユーザーの作る攻略ページをWikiで作れたらなぁと思い、その練習もかねて作ってみたわけです。
そんなBomber丸Worldのことですが、エンディング時の強さを保ったまま最初からゲームが始められるシステムというのはどうだろうと考えてみたりしました。
これがあれば裏ボスとかを滅茶苦茶強くしても10周目ぐらいに勝てるようにしておけば問題ないし、1回目は苦戦していたボスを楽勝で倒す快感も味わえるのです。
yaneSDK.NETのことですが、セットアップが煩雑すぎるということで使わないことにしました。
コピーすべきファイルがソースファイルだけじゃないとか、初期設定が多いとか、ちょっとした事を色々試すにはあまりに面倒です。
同じような理由でyaneSDK3rdも使いません。
先にコンパイルしましょうとか、面倒すぎます。
まあ、3rdのほうは割と単体でも使いまわせそうなものが多いので、こちらは存在意義が.NETよりはありそうですが。
日記管理をPHPに移植中です。
現在は管理者の認証までできていて、これから管理者用の処理を書くところです。
まずはC#とGDI+の組み合わせを試してみました。
それが今日の画像です。
この拡大方式、自然画や写真などには威力を発揮するのですが、ドット絵に使うにはちょっと絵の端っこが問題となりそうです。
これはこれで全体としてはある意味見栄えがするので工夫次第で何とかなりそうだし、もしかしたらオプションをつけてもっといい拡大方法が選べるのかもしれないので、もう少し調べてみてもよさそうです。
あとyaneSDK.NETも一応…。
とりあえずグラフィックについて考えるとして、yaneSDKだとバグの面倒を見なければいけないがファイル読み込みあたりで色々簡単、yaneSDKなしだとバグは未知数だけどもしかしたら結構いいかもしれない、C#ではGDI+が遅いと聞いた、ということで、まあ、正直、どれとも決めかねてます。
う～ん、大規模なプログラムになりそうだから基本部分はしっかり作っていくべき…なのでしょうか。
もうちょっと整理していく必要がありそうです。
爆ボンのバトルステージのピラミッドの説明を書きました。
あと、他のページの誤記なども修正。
Bomber丸Worldについて。
なんかもう、いっそのことyaneSDK使うのすらやめちゃおうかなという気にもなってきています。
グラフィックと画面に関しては、画面の解像度変更は行わないし、画像の拡大にはバグがあるし、半透明はWindows95での動作さえ諦めればAlphaBlendというAPIがあるし、Bomber丸Worldで実質的に使える画面効果はほとんどAlphaBlendでまかなえるし、yaneSDKで描ける基本図形は長方形だけだし、少なくともグラフィックに関しては大したアドバンテージは無いと思うのです。
サウンドに関しても、DirectMusicを使っているのでyaneSDKの出番はありませんし、ウィンドウの処理なども特にyaneSDKでないといけない理由はありませんし、強いて言うならファイル関連が便利かなという程度です。
全面的に使うのでなく部分的に使ってみるというのも一つですね。
う～む……。
スクリプト講座に書いたこと……。
行き当たりばったりで書いたので、ちょっと……。
間違えただけなら訂正すればいいんですよ。
だけど、ちょっと方向性を間違えたかな、という気がするんですよ。
もしかしたら何回か分を丸ごと取り消すかもしれません。
それでも考えた軌跡として何らかの形で残すことにはしますが。
というより第10回以降はもうこっちの世界に入っちゃってるのでプログラミングのコンテンツとしての有用度はがた落ちなんですが。
ところで昨日の記録の話の続きですが、じゃあ自分のソフトではどんなことを記録すべきでどんなことを記録せざるべきなのか、そんなことを考えていました。
私の場合は基本的に記録しなさ過ぎるほうに偏っているような気がするのですが。
特に今作っているのはRPGであり、言ってみればデータの固まりなんです。
基本的にゲームの進行度や手に入れたアイテム、主人公たちの強さのパラメータや健康状態などは考えるまでもなく全て記録すべきなのですが、例えば進める必要の無いイベントや取る必要の無いコレクションアイテム、ゲームをより奥深くする様々なパラメータなどは記録すべきなのか、すなわち登場させるべきなのか、そのあたりが問題なのです。
特に思いつくままたくさんのイベントを作ってしまいましたからね、どれを入れてどれを削るべきなのか、あるいは全部入れて苦痛にならない工夫を頑張るか、そのあたりが考えどころです。
Bomber丸World、C#で作るかC++で作るかということを考えていましたが、やはり今まで通りVC++6で作ることに決めました。
今まで作ったものの資産が多少なりともありますし、手馴れている分C#よりも速くできそうな気がしますし、今やっているスクリプト作成講座はずばりこのゲームのためですし。
それでも、最後までVC++6で作るということが完全に決定したわけではないので、C#に移行する場合の労力が最低限になるようにできるだけC#との違いが少なくなるようなコードを作ろうと考えています。
コレクションの要素全てにアクセスするときはただ単純に短くなるだけだし、テンプレートがジェネリックになったり、deleteが不要になったり、形式的な違いが大半だと思うので、アルゴリズムの方面では多分大丈夫だと思うのです。
もっとも、WindowsAPIやDirectXを直接(とはいっても現状YaneSDK経由で)扱うプログラムとC#での.NETプログラミングとでは手法がかなり違うので、そのあたりはかなり厄介です。
括弧の中にYaneSDK経由と書いたのですが、.NETのYaneSDKはVC++6のものとは全く、というよりもはや根本から構造が違うので、今まで楽してた部分をそっくり自分で書かなければいけない可能性があるのです。
もちろん、YaneSDKの中にはC++という言語と標準ライブラリの不足を補う部分が数多くあるので、言語機能と標準ライブラリが強力なC#ではそれらの面倒ごとをある程度は補ってくれるのでしょうが。
ナマライザの開発を進めてます。
フィルタ機能はひとまず置いといて、エクスプローラ型表示を作ろうと試みています。
エクスプローラ型表示というのは、つまり、どのファイルにどれだけアクセスがあったのかというのを、視覚的にわかりやすく階層構造で表示するというものであります。
ディレクトリアイコンをクリックするとそのディレクトリから下の階層へのアクセス状況が見られるようになります。
さらに、特定のファイルをクリックするとそのファイルへのアクセスを詳細に解析した個別表示のウィンドウが開きます。
で、それらがまだできていないわけです。
マイクロソフトの「よく寄せられる質問 : Visual Studio と Windows Vista」を見ていました。
何せWindowsXPとは全く異なるOSがもうすぐ出るっていうときに、開発に時間がかかり、なおかつ長い間プレイしてほしいゲームをWindowsXPで作ろうとしているのですから、気になるってものです。
これを見てまず驚いたのが、WindowsVistaでもまだ現役としてVisualBasic6.0が使えるということ。
こうなったのは修得の容易さからVB6を使う人が未だ多いためにしぶしぶといったところだそうですが、もうすぐ本格的にVB6とはお別れしなければいけないと思っていたところなのでちょっぴりうれしい気持ちです。
もっとも、VB6以外については、最新のVS2005と極端に変わらないと言う理由でVistaからはサポートしなくなるそうですが。
ただ、VB6やVS2005がWindowsVistaで使えるようになるのは2007年第１四半期からだそうで、そうなるとWindowsVistaの導入もそれにあわせて4月以降になってしまいそうです。
もちろん導入できればの話ですが。
WindowsVistaでは、.NET2のプログラムがそのまま動かせるそうで、また、WindowsXPでも.NET2をインストールすれば使えるということで、今後の開発は.NET2が中心になっていきそうです。
次のバージョンの.NET3も.NET2を完全にサポートするようですし。
それで気になるのが、今から作ろうとしているBomber丸Worldです。
まだ作り直しはききますし、C++からC#への移行はある程度容易です。
しかし今現在の状況では、開発環境が重い、ウィンドウ切り替え直後の再描画がなぜか遅い、などの欠点がありますし、そもそもVC#2005での本格的なゲームの開発経験は皆無です。
しかしその代わり、標準ライブラリは確実にVC6よりは充実していますし、開発環境も重くなった分やはり圧倒的に強力になっています。
すでに1割を切った古いウィンドウズの利用者を切り捨てて自分だけさっさと先に行ってしまうか、将来動くかどうかわからないプログラムをそのまま作り続けるべきか、悩みどころではあります。
それはそうと、今日はナマライザのファイル読み込みを作りました。
テスト用の小さなファイルで動作を確認したのですが、とりあえず現状ではうまく動いていそうです。
実はコピーして一部変更しなければならなかったコードをコピーだけして変更しないという初歩的なミスを犯したりしていたのですが。
そろそろ更新したいのでスクリプト講座の続きを書いていました。
明日にでも、更新しようかと。
ゼルダの新作の発売が近付いてきて、任天堂ホームページでも早くからスタッフインタビューがあって、「ゼルダらしさ」について考えることがありまして。
で、ゼルダらしさの一つに、「文字の少なさ」というのがあると思うんですよ。
セルフ表示枠に表示されるテキストはせいぜい2～3行までで、説明的過ぎず、かといって足りなくもない、必要十分のテキストが表示されてるんです。
そして、セリフを一度に表示する量が元々少ないがゆえに、「ミンナニハナイショダヨ」や「うふっ」ぐらいの短いセルフでさえ充分な存在感を持っているんです。
で、ここから自分の話になりますが、それを考えるとBomber丸Worldのセリフはどのくらい表示すべきか、ということが問題になるんです。
ゼルダは、ある種、セリフが短くても成り立つようにできているからセリフが短くても成り立つんであって、Bomber丸Worldの場合長いテキストをしっかり表示しないといけないかもしれない、あるいは文字が小さくてたくさん表示できるスペースを設けたとしても小さなセリフが存在感を失わないでいてくれるかもしれない、そんなことを考えていました。
で、バリエーションデータの、どのデータをどのタイミングで読み込むか、というのを考えてました。
Aという基本データと、Aと少し違うBのデータがあったとして、BにはAと同じ内容のデータは記載せずに、Aとの関連と差分のみを記録するという方式でデータを扱うのがバリエーションデータなのですが、記録するほうはそれでいいとして、Bを読み込むときにはどうすればいいのか、という問題があるわけです。
基本となるAを読み込むならただ読み込むだけでいいのですが、Bを読み込むとき、同時にAをも読み込む必要はあるのか、ということです。
同時にAを読み込んで初めから完全なBのデータを用意しておくのはプログラム的にも簡単なのですが、例えばBがAとほとんど違っていた場合や、Aから派生したBから更に派生したCからまた派生した……Zなんてデータが来た場合、Zには最早Aの面影は残っていなくて、YやXまでさかのぼれば充分な場合、そもそもデータを参照する回数が少ない場合など、つまり、さかのぼりがあまり頻繁には起こらない場合などには、いちいち全部用意していると読み込み負荷ばかりが余計にかかる可能性が高いわけです。
もちろん現実的にはさかのぼるのはせいぜい５回程度までのはずなので、そんなに神経質になる必要は無いのでしょうが、auto_resourceとの相性なども考えていきたいのです。
先程とは逆にBを読み込んだときにAを読み込まない方式としては、Bのデータを参照して、該当するデータが無かったときにそのつどAを読み込んで該当するデータを探す方法を考えています。
当然のことながら性質も逆で、さかのぼりが少なければ少ないほど、効率的になります。
とりあえず前者をA方式、後者をB方式と呼ぶことにすると、基本データよりも派生データが圧倒的に多いときのメモリ効率で考えた場合、A方式だと末端に行くにつれてデータが追加されるので、メモリ消費が多くなりがちですが、逆にB方式では本当に最小限のメモリ消費しかないはずです。
とにかく、データの性質によってかなり変わりそうではあります。
Bomber丸Worldの最初に表示される画面、すなわちよく言われるところのタイトル画面について考えてみました。
最初の予定では、2002/10/05(Sat)の日記や、2003/11/19(Wed)の日記で書いていたように、普通にタイトル画像を用意しておいて、それをドカンと出す方式にしようかと思っていたのですが、どうにもこの方式だとまず画像が必要だし、タイトルからゲームに入るところのインターフェイスをどうするかに迷うし、なんとなくだけど「らしくない」気がしたりするので、よくある正攻法のタイトル画面とは違う方式にしてみようと思いました。
そこで考えたのが、ゲーム画面を最初から出しておくという方式。
具体的に言うと、タイトル画面用のマップを用意しておいてそこを自由に動き回れるようにしておいて、マップ内にある特定のオブジェクトを調べることで実際にゲームが開始されるようにします。
もちろんタイトル画面というからにはタイトルも表示しなきゃいけませんが、マップ上にタイトルを表示するのは別に難しくないと思うのでこの方法で検討してみようと思います。
そして、データをXMLとかで管理しようと考えていたのですが、目的から考えるとやっぱりXMLである必要はなさそうに思えてきました。
Bomber丸Worldに必要なデータは、多重に階層化されていて、それぞれの階層にはデータがあって、末端の階層にあるべきデータを参照して該当するデータがその階層に無ければ上位の階層に該当するデータが無いか見に行き、あればそのデータを使うという、すなわち、もっとわかりやすく例で言えば、例えば、「カイモチ民であるふにゃが困った顔をしているとき」の歩くスピードを調べたいとき、「困った顔」というのには困った顔のデータしか無くて、歩くスピードがわからないので「ふにゃ」の歩くスピードを見に行くんだけれどもふにゃの歩くスピードが標準的なカイモチ民と変わらないから特には設定されてなくて、最終的に「カイモチ民」まで見に行って、最終的には「カイモチ民であるふにゃが困った顔をしているとき」の歩くスピードは「カイモチ民」の歩くスピードとして得られるわけです。
これを使えば何がうれしいかというと、ほとんど同じだけど一部が少し違うようなデータを簡単に作れるんです。
オブジェクト指向とかがわかる人ならクラスの継承のようなもの、といえばわかるでしょうか。
詳しい実装方法は後で考えることにします。
PHPでのギャラリーページの書き換えが完了しました。
JavaScriptに依存しないブラウザに優しい形式で、コンテンツ管理もしやすく、画像一覧だけでなく別の場所でランダムイメージとして利用したりもできます。
とりあえずふにゃさんとBomber丸Worldのページに使ってみましたが、音楽も混在しているパネルγでは別の配慮が必要そうです。
新しいラインブレイカ、早くもダイアログ作成の段階で手間取ってます。
グループボックス(VBでいうフレーム)の中にコントロールを入れてもグループ化されないんですよね。
それにエクスプローラからのドラッグ＆ドロップの方法もわかってませんし。
ふにゃさんの13面の攻略ページが出来上がりました。
最難関ステージだけあって画像点数もトップクラスです。
そうそう、ふにゃさんのページのギャラリーとトップを改装中です。
JavaScriptに依存せず画像表示ができて、ギャラリーページの内容を他にも使いまわせるように、PHPで書いてみようかと考えています。
Bomber丸Worldのバトル2の曲をハーモニックマイナースケールにしてみたら暗い曲から怖い曲になりました。
特に出だし部分の印象が激しく変わるのですが、逆に後半部分は何も変わりませんでした。
更新しました。
結局書いたコードをどう扱うかでちょっと延びてしまったということなんです。
ラインブレイカのことなんですが、未来を見据えてここは.NETでやってみるか、それともマイナーバージョンアップということでVBのままいってみるか、予定通りC++でゴリゴリ書くか、迷っているところです。
C++が現実的だとは思うけど、ダイアログ作りから何から自分で作らなきゃいけないし…。
Bomber丸Worldのデータ構造読み込み機能、実は無理にXMLにする必要は無いんです。
うん、MSXMLのバージョンとかインストールとかがややこしそうだったので。
TGscriptを作っているときに見つけたPHPのserialize関数がなかなか便利なんですよ。
配列などのデータ構造をそっくりそのまま文字列にして出力できて、unserializeで復元できるんです。
で、その結果というのがいかにもコンピュータに優しい形式で、構造を表すだけならXMLよりむしろ作りやすいような気がするんです。
バトル4のMIDI、着実に進んでいます。
あの曲はバイオリン・ピアノ・フルート・太鼓の4つが入った曲なので、一つ一つにきっちり特徴をつけながら作っています。
爆ボンのページを更新しました。
最近は参考タイムばっかりですけどね。
ブラックシティ4面をクリアしてレインボーパレスへ、そしてレインボーパレスの1面をカード5狙いでクリアして、2～4面はそのまま一発で全アイテムを入手しました。
というわけで残すはレインボーパレス1面のカード5以外のアイテムです。
今更ながら、ラインブレイカ、めっちゃくちゃ遅いですね。
今日、27日から29日にかけて異常な数のアクセスがあったことに気付いて調べていたのですが、要らない情報の削除のためラインブレイカに通したら普段なら数分以内で終わるところが高々10倍程度のデータ量で数時間経っても終わらなくて、どうにも効率の悪いアルゴリズムを組んでしまったために行数の2乗以上のオーダーで増えているような感じがします。
だとするとメモリ使用量も不必要に多い可能性が考えられるので、一度根本からソースを見直そうと思います。
簡易アクセス解析でも似たようなところで高速化ができるかもしれませんね。
こちらは根本からではなくちょっと手直し程度で。
αゲームズのページを作ろうと色々やっていたのですが、ランキングのこととか、それぞればらばらのバージョンをどう統一するかなど、気になる部分が数多くあったのでなかなか作業が進みませんでした。
ファイル名に関しては全部全くばらばらだったので重複の心配は無かったのですけどね。
TGscriptの小吹き出しを改善しました。
これでFireFoxでもそれなりの表示ができますし、IEでもより見やすくなりました。
もっとも、FireFoxのほうではなぜか存在しないはずのスペースが表示されてしまって少し困っているのですが。
あと、表面上は何も起こっていませんが、共通処理と設定のファイルを分けました。
これは動作の変更をしたいときに設定の下までスクロールするのが面倒だったという、ただそれだけのことです。
昨日のMIDIをもうちょっとマシになるように改良していました。
この曲は聞いたとおりの曲名で、曲名通りの相手と戦うときのBGMだったりします。
マザー3のニューヨクバの画像からただのヨクバの戦闘画面風のドット絵を作ってみました。
どうせヨクバと戦うならサルサVSヨクバの夢の対決にしてみようじゃないかとか、サルサが戦うならいっそサルコも参戦させようじゃないかとか考えて作ってみました。
たぶん状況から考えて空白の3年間の出来事でしょうね。
CharaBoxに音楽や動画などのデータを画像の代わりに使えるようにしようと考えてました。
でも、やめました。
DirectShowを使って途中まで作っていたのですが、やめました。
画像との共存が面倒というのもあったのですが、キャラと音楽とか、キャラと動画とか、関わりが薄そうだな、と思いまして。
Bomber丸Worldに使うBGMの一つを作っていました。
6拍子で何かが混じってる曲です。
とりあえず全体的な雰囲気をつかむためにStringsだけで作ってみたもので、まだまだ本格的に作り出すのはこれからになりますが、今の段階でも結構問題が多そうです。
とにかく、いかにも急いで作ったような雰囲気が前面に出ているのを何とかしなければ。
auto_resourceができたのでそれ前提で作る予定のスクリプト作成も始められそうです。
木構造を作ったら後は実行すれば終わりですが、同じスクリプトをいろんな場所で使いまわす場合、実行するごとに結果の変わらない木構造を何度も使用するごとに毎回解析するのはばかばかしいので、実行環境(要するにスクリプト内で使われる変数の情報など)だけを個別に用意して木構造は既に解析済みのものを使いまわそうという魂胆です。
まあ要するに、スライムが10匹現れた場合行動パターンはみんな同じだからHPとかのパラメータだけ個別に持たせておいて行動パターンは一つで充分でしょって話です。
なんかCBWInputが使い勝手が悪いと思って変更を加えていたんですが、ものの見事に失敗しました。
CBWInputを使うときはInitとUpdateとQuitは必ず使う必要があるのですが、そのうちInitとQuitを不要にしたかったのです。
しかし、Initの時点ではCBWDrawや他のもっと低レベルな部分の初期化が済んでいないといけなくて、Quitは逆にそれらの終了処理は始まるまでに呼ばなくちゃいけなくて、それぞれコンストラクタとデストラクタに任せておくことができなくて、断念することになりました。
本当はやろうと思えばできなくもなかったのですが、改変したところで大して手間は軽減されないし、これに依存しているCBWWindowまで道連れで変更になっちゃったりして、仕様変更によって起こる面倒ごとのほうがずっと多かったのです。
ともかくソースの過去ログ残しておいて助かりました。
それと、Quitが実は省略可能じゃなかったのでドキュメントもこっそり修正しました。
auto_resourceも細かい部分で少し修正です。
リソース本体を格納しているautoobjectはコピーが作られるとポインタや参照カウントの関係上色々まずいことが起こるので、コピーコンストラスタや代入が行われるコードを書いた場合はエラーが起こるようにしたのです。
auto_resourceの動作チェックも完了しました。
auto_resourceはその特性上結構アバウトなメモリ管理をしているので許容量を超えてもメモリ解放されず、結果として許容量を超えるリソースが残ったりすることもあります。
このあたりは、小さなファイルを大量に読み込むことを想定して作ったということもあり、そもそも厳密にしたところで別の場所でメモリを湯水のように使ったりしてるはずなので、ここら辺は結構アバウトでもよいかと思われます。
ま、これは無難バージョンを使った場合のことなので厳密にやろうと思えば場合によっては最善バージョンを使えばいいだけの話ですが。
