2018 ソフトウェア設計及び演習用の班Wiki
18::gr04::玉川皓規
8/2
electronに対応させた。
OP画像をGIMPでセピア色に加工し、元ネタへ近づけた。
敵の攻撃パターンを増やしたり、隠しボスを追加したりした。クラス化、モジュール化がうまくいっていたおかげで、変更は最小限かつ見やすい形で済んだ。
ゲームオーバー画面の表示がうまく行かないバグを修正した。丸一日原因がわかっていなかったバグだった。
その他バグフィックス等々。新機能追加はバグの追加であるということを痛感した。
個人個人で作成していたBGM処理を統合し、煩雑だったBGM切り替え処理を１行で行えるように改造した。
8/1
各モジュールでの数値のやりとりを簡単にするためにグローバル変数の仕様を班で策定。これにより以下の統合処理が可能になった。
敵の攻撃力と自分の防御力をダメージ計算に使うようになった。
敵の種類に応じて戦闘時に出てくる画像を変化させるようにした。
7/31
直進する弾の発射角度を変更できるようにした。今まで真下にしか飛んでいなかったが、これで複雑な制御が出来るようになった。
sceneを使わずにオブジェクトを一括で表示したり消したりする方法を見つけたので、sceneを削除した。 今思うとenchant.Groupで良かったような気もする。
7/20
配列を用いたオブジェクト管理法ページ公開 7/20 Sceneを使わないオブジェクトの一括管理方法
6/13
ソース分割法を公開 6/14 ソース分割 これにしたがってソースを分割し、他の班員のコードから戦闘システムを１行で呼び出せるようにした。
プロトタイプ作成
(重要なものだけ)モジュール説明
自分の担当モジュールはシューティングゲーム部分。 battle.jsをhtmlで読み込んで、Shooting_part();と記述すると敵の攻撃が始まり、5秒経つと制御を返す。
Shooting_part();
プレイヤーインスタンスや、弾が画面外に飛び出さないようにする枠などの様々なオブジェクトを出現させる。
新しいシーンを出現させるのが普通のやり方だが、それでは下のシーンが停止してしまうため配列とfor in文を利用して既存シーンにオブジェクトをまとめて出したり消したりしている。
現在のenemyidに応じて敵にどんな攻撃をさせるかをif文で制御している。
ongrid(target, mode="bullet");
枠の中にオブジェクトが入ってるかを判定する関数である
基本的に敵の弾に用いるもので、枠の外に出ると弾が消える処理に使うが、modeを変えることでプレイヤーなどを指定することも可能。実際にプレイヤーが壁から出ないように制御するために使っている。
TestGroup(x, y);
Groupオブジェクトである 中にはSpriteが２つ入っていて、片方を見た目用、もう片方を当たり判定専用にすることが可能であり、弾幕STGに不可欠な「極端に見た目より小さい当たり判定」等が実現できる
Player(x, y);
TestGroupを継承した、プレイヤーのクラスである。 この中に、自分の体力が0になったらゲームオーバーにする処理を行う文がある。
また、壁の外に出たら進んだ分の逆方向に２倍進むようになっているので、跳ね返るような独特な挙動になる
感想
初めてのグループ開発、初めての自主テーマ設定、意味不明なgitの概念、Cの常識が通じないjavascript等、数々の困難があったが班全員の高いモチベーションによって乗り越えることができた。タイトルからラスボスを倒してエンディングまでの流れを、短いながらもしっかり作ることができたことをとても嬉しく思う。
うまくいったこと
-
モジュール分担
- 共有変数や他人の進捗に依存する部分をかなり小さくすることが出来たため、個人での開発がとてもやりやすかった。（他の班員も自分にはそう見える） 統合処理は期限間近だったが、個人で開発できる部分は８０％ほど開発出来ていたため統合自体は予想より早く終わった。
-
クラスの概念の習得
- Cには無いクラスの概念に慣れるのに時間がかかったが、開発中期からは似たオブジェクトを継承させて作ったりしてクラスの利便性を実感することができた。
-
開発環境構築
- atomエディタに統合ターミナルやリアルタイムHTMLプレビュー機能などを追加したり、atom付属のGUI gitクライアントの使い方を班で共有した。更新ボタンを押したりctrl + alt + tを押す回数が格段に減って快適になった。
-
ソース分割
- 普通ソースファイルは分割できるものだと思っていたが、enchant.jsを用いた状態でのソース分割についてのノウハウはネット上に全然無かったので苦労した。ui.enchant.jsのようなプラグインがどのように定義されたり呼び出されているのかを解読し、それを真似ることによってクラスや関数を分割することが出来た。(一部の班がもっと名前空間的に安全で簡潔な記法を用いていたのでそこは少し悔しい）
-
Electron対応
-
別に使わなくてもゲームにはなるが、折角node.jsをインストールしたので使ってみることにした。
ネイティブアプリ開発フレームワークとしてはかなり手軽で使いやすく、node.jsの豊富なライブラリを使えるので大きな可能性を感じた。
-
別に使わなくてもゲームにはなるが、折角node.jsをインストールしたので使ってみることにした。
うまくいかなかったところ
-
スケジュール、共通仕様の管理
- 予定を事前に立てて行動していれば進捗管理で焦ることは無かったのではないかと思う。
- キャラクターのステータスといった共有変数の仕様を最初から細かく規定していれば統合がさらにスムーズになったと思う。ソフトウェア開発手法について学ぶべきだと思った。
- とはいえこれは作業分担と個人でのテストがとても上手くいっていたことの裏返しであると思う。統合処理を振り返る限り、おおまかな完成形のビジョンの共有には成功していた。
-
通信などのサーバサイド処理の未実装
- ゲームのコンセプト的に不要だったという明確な理由はあるものの、通信に関する技術を学ぶチャンスを生かせなかった。通信機能実装を手軽にするために推奨言語を変えるという英断を下した先生方には大変申し訳ない。
最終更新日：2018/08/08 02:24:23
