ふにゃさんのとげとげの拡張をするついでに、最後に一つ余ったキャラ枠をどう使うか考えてました。
順当なところで１アップか、あるいは取らなくてもいいけど取ったバナナの数にカウントされるボーナスアイテムか、それとも他のものにするべきか、そして決まったところで、アイテムの外観はどうするか、そのあたりが決まっていないのです。
それはそうと、画像フォーマットを一つ考えてみました。
インデックスカラーの長所で、パレットを差し替えれば画像全体の色が変えられたり、パレット番号何番は服の色、などと色に論理的な意味がつけられたり、そういうところを活かしつつ、なおかつたくさんの色を無理なく表現できてインデックスカラーの苦手そうなアンチエイリアシングもしやすい形式です。
まず、パレットは意味のある必要最低限の色だけを用意しておいて、画像本体には、どの色とどの色をどんな割合で混ぜ合わせるかのデータを入れるのです。
もしかしたら似たようなのが既にあるかもしれないのでまた調べてみます…。
Frieve Editor、使い始めてみました。
コンセプト的にはうちにあるメモちらしと似たようなもの、というか、ああいうのを作ろうと思っていて撃沈したのが今のメモちらしだったりするのですが。
というわけで、実に使いやすいです。
機能がいいくせにメモちらしより起動も動作も軽快と来たもんだ。
まだまだ使いこなすには程遠いようですが、テキトーにカードを散らかして遊ぶのもなかなか良いです。
こんなところでまでメモちらし負けてるよぅ…。
NeoMuplはリストと設定の読み書きまで。
識別子として「NeoMupl015」と書くべきところを間違えて「NeoMuol015」にしてしまったせいで読み込めなかったりもしましたが、もう大丈夫です。
読み書きの処理自体は今のところ問題はないようです。
ふにゃさんの裏話を一つ更新しました。
とげとげの話です。
…が、どうやら次のバージョンでまた何かあるようです。
NeoMuplのファイル読み書きを作り始めました。
VB版とは互換性を持たせない方向で。
う～ん、もしかすると読み込みだけなら旧バージョンのものも可能かもしれませんが…。
ふにゃさんの広いステージ、7割ぐらいできてきました。
いやー。のってくると楽しいもんですね。
部分部分で一つのステージとして成り立つほどのボリュームがありながら、更に他の部分での行動を受けて変化してゆき、取れなかったアイテムが取れるようになったりアクセスが楽になったり。
さすがに滅茶苦茶時間のかかるステージなのであっさり死んでしまうような嫌な仕掛けは少ないですが、それでもところどころに失敗するとそれで終わりという場所、特に順番を考えるべき場所は数箇所設けています。
ふにゃさんの追加用極悪ステージを作っています。
なんというか、もう、めげそうです。
ふにゃさんのスペックの限界まで広いステージを作ってるんですが、やっと今下から2割ほど使い切ったところです。
空間を広く使うとどうしても大きな空白ができてしまうのですが、その部分にまで意味のあるコースを作ってしまうといくらなんでも探すのが大変すぎるということで、その部分にはわざわざ来てくれた人のために何かブロックで絵でも描いておこうかと思っています。
NeoMuplは、DirectShowだけでなくMIDIに関してはDirectMusicも使えるように方法を思案中です。
やっぱりMIDIのループ再生にはDirectMusicが一番向いていると思うのですよ。
ふにゃさん更新しました。
まだやるべきことはあったのですが小出しにしていきます。
ファイルサイズが結構大きくなっていますが、これは一部ファイルの形式をプログラムから使いやすい形式にしたのと、いちいちステージデータをコピーして作っているリプレイデータの同梱が大きく出ています。
それで、今回から、最新版に限って、最小限のファイルのみを入れたアーカイブも配布し始めました。
需要はなさそうな気もしますが、一応色々バリエーションがあるほうがいいと思いまして。
今日プログラム的にやったのは、エディタのシフト移動の改善と、操作説明でのシークレット機能の無効化です。
一方まだできていないのは、
・せっかくなのでもう一つぐらいシークレット
・無重力室へようこそ！
・ステージ遷移時のフェードアウト
・エディタからネット上に自作ステージを公開
・エディタでネット上からみんなのステージをダウンロード
などなど。
やりたいこと全部できたら、今度こそ本当に本当の完成で、開発終了ということになります。
本当は今日やろうと思えば更新できたのですが、やっぱり時間がなくてうまくチェックできていない状態でアップするのはよくないので明日更新することにしました。
今日やったことは、リプレイの演出の改良、つまり本当のリプレイの完成。
そして、今更ながらふにゃの動きに関する不具合の修正。
この不具合は本当はずっと前からわかっていたことなのですが、それによってふにゃの動きが変わってしまうため、改善に踏み切れないでいました。
ただ、今度リプレイを実装するともう本格的に手遅れになるため、今回を改善の最後のチャンスとして、思い切ってみました。
もちろん、今まで放置できたのだから重大なバグであるはずがないのですが、ふにゃの向きに関するバグなので、見た目に左右非対称で不自然ですし、もしかしたらどこかで向きが違うために変な動きになる可能性もあるということで、修正することにしました。
あと、リプレイに関しては、にっこりキーが記録されていなかったので、それも記録するようにしました。
これもこれで一度公開してからでは修正できない部分だったので、なんとか間に合ったというところです。
あと、内部的にゲーム本編とテストプレイのプログラムを統合しました。
これによる大きな違いはありませんが、今後の改良の際に両方に反映するのを忘れてテストプレイだけ古いということはなくなるはずです。
そういえば、そろそろスクリプトのほうも進めてやるかと思い、久しぶりに見てみたら、全然わからなくなっていました。
元々方針を間違えていたのは明らかだったのですが、ちょっと今はそれを修正することはできそうにもありません。
なんだか色々ありましたがとうとうリプレイが完成しました！
細かい演出は後回しにしているため多少そっけないところがありますが、基本機能としては十分に出来上がっているはずです。
listにpush_backしたらそれまでのendイテレータが無効になることに気付かずデータが壊れてしまったりとか、設定を使ってしまった後に設定変更を入れてしまって実際には設定が反映されなかったりとか、面倒くさい設計にしていたのを忘れて簡単に実装したらうまく動かなかったりとかしましたが、なんとか原因を突き止めて全部何とかしました。
ところで今気になっているのですが、ふにゃさんについて実装したい機能は現在結構たくさんあって、全部入れてこうとすると次の更新がどんどん先延ばしになっちゃうんですよね。
結構すぐ修正が必要だったものもあるし、こまめに更新していったほうがいいのか、それともどっちみち後でアップデートするから後でまとめて公開したほうがいいのか、悩みどころなのであります。
リプレイは最初のメインメニューのところで流れますが、今回録画した中にはかなりの割合で弟の作った面が混じってます。
今日はなぜかVBがよく落ちます。
実行した瞬間に不正な処理をしたためどうのこうのと因縁をつけられて。
まあ、実行する直前に保存する癖をつけてるので実害はないのですが、やはりどこか気持ち悪いです。
VBじゃなくて私のプログラム自体に問題があるならば実害があるわけですしね。
ふにゃさんの本編のほうは、リプレイの記録が出来上がったところで、記録しながらテストプレイ中です。
リプレイデータは、ステージデータの必要な部分を切り出して、更にキー入力情報や更に必要なデータなどを付加して、形式上はステージファイルと同じ方法で記録されます。
リプレイデータの記録に関しては設定プログラムで設定してやらないと全く保存されないので、プレイする前に、クリアしたときに自動的にリプレイ記録する確率、ミスしたときの確率、記録するファイルの最大個数、手動で保存するときに使うボタンを設定してやります。
クリアしたときの自動セーブは適当でいいのですが、ミスしたときの記録はあまり確率を高くすると難しいステージなどでは全部が一つのステージの苦難の記録になってしまって楽しくないので、確率を低めに設定しておくとよさそうです。
ふにゃさん、リプレイデータ記録のため、内部的に地味なところで改良を重ねていました。
それはもう、ステージファイル中の画像読み込みとか、クラス同士の無駄な依存関係を減らしたりとか。
ふにゃさんのリプレイ記録・再生を作ってました。
最初記録と再生は別々のクラスで別々のファイルに作っていたのですが、同じデータを扱うのに別々のファイルにプログラムを書いていたのでは不都合があるということで同じファイルにまとめて書くことにして、そうすると別々のクラスに書くこと自体がなんだか面倒になってきて、結局同じクラスに記録・再生の両方の機能を持たせることにしました。
とりあえず今日のところは両方ともキー状態の保持と再生は出来上がり、対応するステージデータとまとめてファイルに記録することが出来ればもう完成になるということになります。
えっとですね。
まずふにゃさんの反則的シークレット機能2つが、非常に高い確率で、両方同時に出てしまうことがわかったので、ある程度の期間はどっちか片方だけが出ている状態にするために、全く違う条件を設定しました。
で、現在考えているシークレット機能に関する実装は全て終わって、あとはシークレット以外の追加項目を作るだけになりました。
これがまた難儀なのですがね…。
んで、ドラクエ8やってました。
深緑の巨竜倒しましたよぉ。
ただ、レティス戦の時のようにまたハーゴン(主人公)が肝心なところで倒れて経験値が得られませんでした。
大事なところでククールの回復が遅いんですよね。
ゼシカもザオリクを覚えるそうですが好みの問題からザオリクを覚えるスキルには手をつけていませんし。
ふにゃさんのほうは、シークレット出現条件が全て出来上がり、そのうち内容を実装していないのは残り2つ、プログラム自体の変更を伴う部分です。
ちなみにあんこのグラフィックではバナナがブドウに変わったりします。
ふにゃさんは今度の更新でかなりたくさんの部分を改良したり追加したりします。
それはもう、なんで今まで1年間以上も未完成を提供していたんだと思わせるほどに…したいのですが。
とりあえず、昨日の続きで、無重力状態での上下左右の接続はさすがにむちゃくちゃすぎるので廃止し、逆に場外負けを上方向にもつけるようにしました。
そして、キャラ絵をあんこ、サングラスをかけたふにゃの2バージョンを作ってオプションで変更できるようにしてみたりもしました。
あと、操作説明のところで、終了できなくなるバグを修正したつもりが、更に別の操作をするともっと悪い状態になってしまうことがわかったので、逆にどんな悪い状態になっても終われるように修正しておきました。
で、サングラスのことなんですが、サングラスをかけさせると黒背景のタイトルではサングラスが見えなくなるんですよね。
そこで、絶対に改悪にならないように、背景を黒以外にする方法を考えていると、デモプレイを背景に流すというのを思いつきました。
なんだか難しそうな気もしますが、しかし何とかできるような気もします。
を、今日勢いで一気に動くところまで作ってしまいました。
ふにゃさんの話です。
地上のアクションができない以外は普通のふにゃよりも明らかに性能が高く、最高速も大きければ加速もよく、ステージの上下左右が繋がっているとみなして動くから、場外負けもなければステージ端の部分に反対側から侵入することもできてしまいます。
シークレット機能のうち、かなり条件が厳しいほうに入る予定なので、それ相応にかなりむちゃくちゃな性能にしてあります。
ちなみに、移動性能のよさは、普通と同じ性能だとものすごくとろかったために調整したものです。
動画を見てわかるとおり、移動しているとくるくる回りますが、とりあえずこれに関しては今後実装する氷の息の射出方向に影響を与えるようにしようかなと思っています。
ふにゃさんのグラフィックやらなにやらを作っていました。
なんとなく余ったスペースがもったいなく感じたので使わなかった絵を入れてみたりけち臭く他の画像リソースも空きスペースに詰め込んでみたり。
使わない画像を入れるというのは実際のところファイル容量的にはよくないのですが。
そして、ふわふわふにゃ計画とかグラフィック差し替えようの画像も作ってみたり。
昨日言っていたauto_resourceですが、書き換えられるところを全部書き換えたところで、実は一番威力を発揮するはずだった場所でauto_resourceが全く役に立たず、そこで使わなかったせいでauto_resourceがその最大の特徴を活かすことができなくなり、せっかく全部書き換えたのですがまた全部書き直すことになってしまいました。
まあ、せっかくまた全部書き直すことになったので、今までともまた違う方法でリソースの効率のよい管理を考えてみました。
元々ふにゃさんのリソースは必要になったときに初めて読み込まれ、その後は必要なくなってもプログラム終了までは解放せず、ずっと使いまわすようにしていました。
そこで、必要がなくなったら解放できるように、しかし使いまわしは効率よくできるように、という2つを両立させるためにauto_resourceの利用を考えたわけです。
ところがauto_resourceの仕組みはいらなくなったリソースが増えてきたらいらないもののうち古いものから消していくというものだったのですが、増えていくべきいらないリソースはauto_resourceの管轄外でいらなくなった瞬間に解放され、一方auto_resouce適用可能なリソースはいつでも必要になる可能性が高くてあまり増えたり減ったりしないということで、どのみちauto_resourceではうまくいかないということだったのです。
結局のところよく使われるリソースはいつでもメモリ上に常駐しているということになり、それだったらいちいちプレイ中に動的に読み込んだりせずに最初に一気に全部読み込んでしまおうというのが、新しく考えた方法です。
結局一番古臭い方法に行き着いてしまったわけですが、プレイを一時中断して画像を読みにいったりしなくて済むし、一気に読み込む画像は全部同じファイル内にあるのでディスクキャッシュを使って非常に高速に読み込めるはずなので、実は一番効率がよいのではないかと思います。
実際計測してみると、読み込み時間は0.1秒程度で、GIFのデコードにそれなりの時間がかかることを考えれば、十分な読み込み時間だと考えられます。
そうそう、操作説明である操作をすると、操作説明が終わらなくなるというバグを発見したので修正しておきました。
ふにゃさんの画像をauto_resourceに移行中です。
ただ、主人公の絵だけは特別な処理をしているためにauto_resourceへの移行は無理そうです。
それと、ヒートゾーンやアイスゾーンなどの半透明グラフィックは、実行時にYGAを生成していましたが、これを最初からYGAファイルにすることによってちょっとぐらいは読み込み負荷を減らせたような気がします。
CharaBox3バージョン1.01をアップしました。
いくらなんでも改良したのに何ヶ月も放置というのはいけない気がしまして。
そうそう、今、ふにゃさんのプログラムの見直しをやっています。
何しろCDIB32を使っているはずなのにCPlaneBaseの機能しか今まで使っていなかったので。
とりあえず今度は回転系を使って何かしてみようと考えてます。
リソース関係も、Bomber丸Worldに使う予定のauto_resourceを使って色々改善していきたいと思っています。
ふにゃさんの氷のステージの動画をアップしてみました。
元々動画の元になるデータはPNGで保存してあって、非常にファイルサイズが小さかったので、どうにかこのデータをそのまま動画にできないかと探していたら、PNGと同じ圧縮方式のLCLを見つけました。
http://www.geocities.jp/sandk_project/LRC.htm
どうにも必要な手続きを踏んでいない非公式コーデックだったそうですが、問題なくYouTubeにアップできたようです。
ふにゃさんプレイムービー全ステージ分アップし終わりました！
最難関のギロチン台は時間のかけすぎでうまく録画できなかったので改めて録画しなおしたのですが、他は滞りなく一発で録画成功しました。
あと、二重起動すると白い四角が出る問題を調べてみたのですが、原因はよくわかりませんでした。
もしかしたらShowWindowで間違ったウィンドウをアクティブにしているのではないかとも思うのですが、なぜ間違ったウィンドウが出るのかもわからないのです。
Bomber丸Worldの高さマップは廃止することになりました。
詳しいことはWikiに書いてありますが、主な理由はたいした利点がないことと、様々な欠点があったことです。
のんびりナマライザ、とは直接的には関係ないのですが、gzファイルの中に圧縮してあるアクセスログを解凍した上に適切なファイルに内容を書き込むソフトを作り始めました。
完全に自分専用に特化したソフトなので他の人にはほとんど使えない代物ですが、一部にナマライザのコードを流用してたりします。
