壊）最適化が済んだので、ネットワーク対戦の本格実装

最適化が済んだので、3日ほど休暇を頂きました。
これから、コワリス壊のネットワーク対戦完成に向けて色々やります。

ネットワークのメニューの作り替えとかあるんですが、
階層構造が変わるようなデザイン変更が結構だるい。

まぁ、ここを過ぎれば、あとはα版の動画制作に王手なのですがね。

αが過ぎたら、様々なオプションの実装と、NPC対戦でβ版へ移行、
完成版は、要望を聞きながら突き詰めていきたいと思います。

予定
α版完成：3月3日前後
β版完成：3月17日前後
完成版：4月4日前後

壊）ブロックをこするときの当たり判定を最適化

検証用バージョンv2

今までは、Flash独自の機能を使って当たり判定を出していました。
しかし、その機能が重いのに結構大雑把なため、実装を変えてみました。

ブロックを回転させたときに、溜まっている300個のブロックすべてを検索対象にし、
それを落下ブロック分だけ繰り返すということをしていました。
つまり、「300×落下ブロックの個数」のコストでした。

今回からは、ブロックの位置を検索しない事で高速化しました。
原理を簡単に言うと、一つの落下ブロック当たり25箇所の地点が、
ブロック溜りのどこに相当する位置であるかを計算で求めています。
計算でブロックの位置が分かるので、その場所にブロックがあるかを調べるだけです。
これにより、「25×落下ブロックの数」の大幅な最適化。

これにより、当たり判定が高速化しました。
調べる地点が、25箇所という大雑把さなのに、
Flashの機能を使うより精度が高いという、驚きの結果。
これで、いくらか軽くなると良いのですが。

コワリス壊のネットワーク対戦のチューニング その5くらい

検証用のバージョン

直接オブジェクトのディープコピーを渡して検証したら、
RTMFP経由よりちょっと軽くなりました。
でも、何故か重いです。

データは次のとおり

単体での処理速度
メイン : 平均 0.29623893805309737 ms　最大 10ms
トータルの最大 : 10ms

RTMFP経由
メイン: 平均 0.9333838001514004 ms　 最大 39ms
サブ 1: 平均 0.4125662376987131 ms　 最大 07ms
サブ 2: 平均 0.39137017411052233 ms　最大 07ms
サブ 3: 平均 0.38152914458743376 ms　最大 09ms
サブ 4: 平均 0.37395912187736563 ms　最大 16ms
トータルの最大 : 41ms

オブジェクト直接コピー
メイン: 平均 1.7802850356294537 ms 　最大 68ms
サブ 1: 平均 0.850356294536817 ms　　最大 25ms
サブ 2: 平均 0.8218527315914489 ms　 最大 25ms
サブ 3: 平均 0.8242280285035629 ms　 最大 26ms
サブ 4: 平均 0.8390736342042755 ms　 最大 27ms
トータルの最大 : 101ms

オブジェクトの直接コピーでちょっと軽いのに、
これの処理時間が長いのは、見えなかった処理部分が出てきたのだと思います。
それにしても、単体では以前とは比較にならない位軽くなりました。

ゲームそのものは軽くなったけど・・・。

ゲームそのものは、とても軽くなったけど、
ネットワーク周りでどうも遅くなるみたい。
色々検索してみているけど、なかなか良い案に辿りつかない。

AS3のプレレンダリングがすごい高速な件

さて、ちょっと耳にした、「プリレンダリング」を試してみました。
方法は、こちらに説明されている通り。
Bitmapを AddChild して、BitmapDataの中身を入れ替えるだけ。
MovieClipを継承したクラスを利用すると、扱いやすいです。

普通のMovieClip（≒ MC）と、プリレンダリングとの比較。

5000個のブロックを、色を変更しながらヒビの加減を変えたとき。
普通のMC：10233.6ms
ビットMAPを貼ったMC：5786.1ms
プリレンダリング：22.9ms

普通のMCが10秒超で、15秒のタイムアウト寸前ですね。
それに比べて、圧倒的すぎる速度ですね。なんと、446倍速！！
コードの最適化で120%の高速化をしましたが、
44688.2%とか、正気の沙汰ではないです。
さらに、維持にかかるコストも低く、美味しいです。

これを使えば、とても重いFlashですら楽に動画化できます。
では、これで、実装を進めていきたいと思います。

フレームをばらしてみたけど、余計重くなった

コワリス壊の方で、ちょっと失敗談。
フレームの切り替えがとても重くて困っていたので、
この際、全部1フレーム目に描写したら、余計に重くなりました。

なので、最終手段として、プレレンダリングを使います。
こんどこそ、速くなるといいなぁ・・・。

コワリス壊のネットワーク対戦が重い原因

いろいろ試した結果、「プログラムそのもの」は、とても軽いことがわかりました。
一番重い連鎖落下の部分の処理ですら、0.00001～0.002秒の処理時間でした。
コードの最適化をした結果、ここまで軽くなったのかもしれませんけどね。

負荷を計算すると、以下のようになります。
60フレームで必要な処理時間は0.016666秒以下(1/60秒)なので、
最大負荷でも 7人(最大人数) × 0.002秒(最大負荷) ＝ 0.014秒(全体の最大負荷)
つまり、プログラム自体は7人対戦でもそこそこ耐えられます。

それで、肝心の重い原因は何かというと、「ブロックのフレーム変え」でした。
ブロックのフレームが変わるたびに、0.051～0.112秒もかかっており、
全体としてカクカクになる理由がこれでした。

これに対し、メモリを多めに消費する代わりに、
スムーズな描写を可能にする技術の搭載の検討をはじめています。
実装したプログラムでは、消費メモリが500MBくらいですので、
プレイには1GB以上のRAMを搭載したPCが必要になります。
といっても、最近のPCなら、2GB以上当たり前ですね。

コワリス壊のネットワーク対戦が、思ったよりも重い件。

途中まで実装してみたところ、
コワリス壊のネットワーク対戦が、
思ったよりもかなり重くて、泣きそうです。

果たして、最適化できるのかどうか・・・。

壊リス・壊のネット対戦搭載まで、あと少し・・・。

壊リス・壊のネット対戦搭載まで、あともうちょっとです。
長かった内部の整理が終わって、ようやくネットワーク周りにたどり着きました。
あともうちょっとという感じです。

最近の変更点
1.プレイ画面用のインターフェイスの変更。
2.Conboの表示が復活し、獲得ポイントを消えたラインから表示。
3.Line・連鎖・Comboの表示方法を変更。
4.ボーナスゲームがアイテム扱いになり、爆発も爆弾と同じものに修正。
5.爆弾とボーナスゲームを同じ箇所で処理するようにしました。
6.ボーナスゲームのクリアに特典がつくようになりました。
7.ボーナスゲームのレーザーを3段階に変更。
8.壊モードで、Lineの消滅で同じ色のブロックを消滅させると、ボーナスが付くように変更。
9.スコアが動的に変更されるようになりました。