Author Archives: ftvoid

[Departure from the Void] ゲームオーバー画面実装途中・・・

前回の制作日記からだいぶ間が空いてしまいました。
今月に入ってから、ゲームオーバー画面の実装を少しだけ進めました。

20170403_1

UIの配置をしたばかりなので、動きの実装はこれからです。
文字のアニメーションはDO Tweenで行わせようと考えています。

最近知ったのですが、DO TweenのSequenceを使えばTweenを順番に実行させたり、任意のタイミングにTweenを挿入したり複数のTweenを並列実行させることができます。

明日は上記の機能を使って文字のアニメーションを行わせるようにしたいと思います。

[お知らせ] 今月の予定

今日から4月になりました。
もう春の季節ですね。

先月はDeparture from the Voidの制作の続きをやっていましたが、今月も同じ作業を引き続きやっていく予定です。
制作スケジュールはこちらの記事に記載しています。

今月までに全ての実装を完了し、来月からはテストのみという形でスケジュールを立てています。
制作時間の確保が出来ない期間も存在し得るため、順調に制作を進められる保証はありません。
特に技術的に難しい課題に直面しているわけでは無いので、作業が難航するということは無いと思います。

若干予定より遅れ気味になってしまっていますが、制作時間を確保して今月中の完成を目指したいと思います。

[お知らせ] サイト整備について

今日はゲーム制作はお休みしておりました。

現在運用中のWebサイトですが、ここ暫く手付かずの状態になっているため、どこかのタイミングでまとめて整理したいと考えています。
その際、一時的にこのブログ含めサイト全体のメンテナンスが入る可能性があります。

もしかしたら、このタイミングでサーバーをお引越しするかもしれません。
メンテナンスする際はまた改めてブログで周知したいと思います。

恐らく来月か再来月のGWあたりになりそうです。

それでは、引き続きfrom the voidをよろしくお願いいたします。

[Departure from the Void] ステージオブジェクトのマスターデータ修正

修正した設計を元に、敵や雲などのステージオブジェクトのマスターデータ構造の修正を行いました。

これで、複数ステージ間で共有していたマスターファイルを各ステージ毎に分割でき、マスターデータのメンテナンスが楽になりました。

20170321_1

メンテナンスが楽になった一方、ステージオブジェクトを参照するときはマスターファイルとその中で定義されているIDの2つのキーが必要になるのがデメリットです。
しかし、デメリットを差し引いても上記の管理方法が良いと判断したため採用に至りました。

明日はゲームオーバー画面の実装の続きをやっていこうと思います。

[Departure from the Void] マスターデータ管理クラスの設計見直し

今日はマスタデータを管理するクラス周りの設計を見直しました。
クラス構成は以下の通りになる予定です。

20170320_1

StageObjectMasterは現在は全ステージ分の敵や雲などのオブジェクト情報を一括管理していますが、このままではステージが増えていくごとに管理しにくくなります。
そのため、ステージ毎に固有のStageObjectDataを持たせられるような設計にしました。
各ステージで使いまわす共通のオブジェクトも存在するため、ステージ共通とステージ固有のStageObjectDataが複数個存在する感じです。

明日は上記設計を実装に反映していこうかと考えています。

[Departure from the Void] ステージ2スプライト切り出し

今日はゲームオーバー画面の実装をやる予定でしたが、あまり時間が取れなかったので、ステージ2で使うスプライトの切り出しを行っていました。

20170319_1

上記は背景オブジェクト用のスプライトですが、ほかにもステージ2専用の敵キャラもあります。

必要なスプライトの切り出しはすべて終わったので、またゲームオーバー画面の実装に戻りたいと思います。

[Departure from the Void] ゲームオーバー画面遷移

今日はゲームオーバー画面に必要なクラス設計を行っていました。
クラスはまだ構想途中のため、見た目上の進捗は無しです。

また、これに伴い、自機がやられる動作ややられた後の復帰動作の実装も行っていました。
こちらも実装途中のため、明日以降の進捗報告にしたいと思います。

今日は簡単ですが、ここまでです。

[Departure from the Void] バッチコール対策実施

バッチコールが最大で20まで跳ね上がってしまっていたので、今日は無駄なバッチコールを減らす対策を施しました。

20170317_1

20170317_2

原因は異なるマテリアルのオブジェクトが交互に重なっていることでした。

今回のゲームの場合、殆どのキャラが黒一色で重なり順序は気にする必要がありません。
そのため、上記の現象を防ぐため1レイヤーに1マテリアルのオブジェクトのみ描画させるようにしました。

改善前のSortingLayerの構成は以下の通り。

20170317_4

特にStageObjectレイヤーで上記の現象が顕著に発生していました。
(自機、敵、敵弾という異なるマテリアルのオブジェクトをこのレイヤーに共存させていたため)

このレイヤーを以下のように細分化しました。

20170317_5

そもそもマテリアルをひとまとめに出来ないかという問題もありますが、今後AssetBundleも使うことを考慮して多数のマテリアルが存在しても無駄にバッチコールが増えない仕組みを目指しました。

これで以下のように10以下までバッチコールを抑えることに成功しました。

20170317_3

これでめでたしめでたしです。

[Departure from the Void] ステージ1ほぼ完成

雲の描画順序の問題をSortingLayerにより解決し、正しく描画できるようになりました。

これでステージ1の実装はほぼ完了です。

自機が敵や敵弾に当たったときの処理はまだこれから実装しますが、ステージ1そのものの実装はこれで終わりです。
ここまで実装するのに1か月半かかってしまいましたが、大きなトラブルも作業の後戻りもなく順調に来れました。

明日からは自機がやられたときの処理やゲームオーバー画面などを実装していきます。

[Departure from the Void] 雲を配置

昨日は配置クラス構成周りをリファクタリングしたので、今日はステージ1の背景に雲を配置しました。

20170315_1

今は雲が常に手前に表示されてしまう状態ですが、原因ははっきりしているため後程対処する予定です。
敵キャラと背景でマテリアルが分かれているので、レイヤーで描画順序を制御する方法で行きたいと考えています。
(Z座標での管理ではマスターデータの管理がややこしくなるため)

この問題を解消できればステージ1の実装は完成です。

次はステージ2への遷移演出を実装していきます。