2017 ソフトウェア設計及び演習用の班Wiki

VOICE and VOICES

〜全ての音を求めて〜

魔族vs人の戦争（科学未発達）

音楽が人たちの魔法的なポジション

魔族が戦争で負けそうなピンチで、魔王は魔法を封じるために世界に音を消す呪いをかける。

音の魔力的なものがなくなった反動で人々は喋れなくなる。

戦争も形勢逆転し人たちが負けそう

主人公は生まれつき魔力0だが音楽の魔法に頼らず戦い抜いてきた唯一の兵士。→しゃべれる

魔王を倒し世界に音を戻すための冒険が今はじまる...。

主人公 アート

• 職業は歴戦の剣士

仲間　ピアノ

• 職業は見習い魔法使い

ボス　カイルス

• 必殺技は音を消す呪い

設定詳細

現在のように科学が発達していない時代、深い魔族と人との対立があった。 さまざまな魔法を使う魔族に対抗すべく、人たちは魔法の研究を行い、音を利用した魔法を唯一習得することができた。それにより、人たちは魔族を圧倒することができたが魔族の王、魔王は世界から音を消す呪いをかけた。音がなくなった反動で人々は魔法を使うどころか喋ることさえできなくなってしまった。戦争はこの呪いで一気に逆転、人たちは危機に瀕したのだった。そこに、唯一魔法を使わず魔族と闘ってきた戦士が音を取り戻すべく立ち上がった。 ...

モジュール分け

ヘッダー内部の記述のページ

班のリポジトリ

・早坂啓太

• 比較的簡単なモジュールを担当していましたが、エラーでつまずくことが多く、なかなか実装がうまくいきませんでした。ほかの難しいモジュールを担当している班員と分担して作っていければよかったのですが、実際にプログラムに取り組んで見ると難しいことが多く思うようには進みませんでした。途中で何回もプログラムを大きく書き換えることがあったので、プログラムにとりかかる以前にものと操作の洗い出し、モジュール分けをしっかり行っておくことが重要だとおもいました。また、他の班員のプログラムをみて、自分のプログラムが他の人から見て見づらく、わかりにくいことに気づきました。モジュールの統合などで班員が自分のプログラムを必ず見るので自分だけがわかればいいというわけではなく、チームでソフトウェアを作るうえでは見やすいプログラムを常に意識しながらプログラムを書いていくことが重要だと思いました。班長という役割ではありましたが、自分が中心となってこの開発を進めていったわけではなく、班員それぞれが意見を出して くれたおかげで作品を作り上げることができました。班員にはとても感謝しています。

・佐藤葉介

• 副班長ということでチームやどんなゲームにするかなどの方向性などは班長にまかせ、私はゲームが完成するようにスケジュールやプログラミングのお手伝いを意識してこのゲーム制作に取り組みました。メンバーそれぞれボイパや各個人の活動があり忙しかったにも関わらず、結果的に一通り動くものができて良かったです。プログラムの統合は思ったよりもあっさりうまくいき、原因はモジュール分けにおいて、window単位で機能を実装していたことにあると思います。windowの中で重複した機能がほとんどなく、かつ機能を追加しやすいモジュール分け結果になっていたことが大きかったです。部分的に再実装するような場面もありましたが、量がそれほど多くなかったのでスケジュール的には問題がありませんでした。gtkは古参のライブラリでありpythonやscalaといったよく抽象化されたライブラリがたくさんある言語を使っている現代プログラマからすると違和感を感じるかもしれませんが、よくできた教材は低レイヤーから学ぶように、gtkもよくできた教材なのかもしれません。来年この授業を受ける人はバイブルと言われる古書を読む気持ちでgtkを用いたプログラム製作に取り組むといいかもしれません。

・齊藤渓人

• スタート、オープニング、エンディング、ゲームオーバーの4つの画面を担当しました。大体が似ている構成だったので、スムーズに終わるかと思いましたが、背景や文章の部分で少し苦戦してしまいました。結局、自分の仕様通りに実現することができたのでよかったです。できれば、オープニングとエンディングにも背景をつけることができればよかったなと思っています。 時間が余ったので、シナリオの追記やマップ作成、モジュールの結合なども行っていました。マップはフィールドモジュールとの兼ね合いがあり、一筋縄ではいきませんでした。モジュール結合では、ものと操作の洗い出しでは見えなかったバグなどがでてきてしまって大変でした。もっと序盤のほうを丁寧に行っていくべきだと思いました。できたことを共有して、教え合って、一つのものを作り上げていくということが魅力的な講義でした。 ありがとうございました。

・下瀬川右京

• 戦闘モジュール担当でしたが、正直担当するべきではなかったなと後半に進むにつれて思いました。基本的なダメージ計算やスキルの作成はともかくウィンドウの設計や遷移方法がよく理解出来てなく、ただの足手まといにしかならず、最終的にはメンバーに手伝ってもらいながら作成しました。やはりこういったものは自分のようなプログラミングが下手な人がやるよりかはプログラミングが得意なメンバーに任せるのが得策なのかなと今更ながら改めて実感しました。自宅のPCで開発をしようとしても開発環境を整えるのが非常に難しかったので終始大学で作業をすることになりましたが、色々と辛かったので全体を通しての進捗具合は芳しくは無かったです。ただモジュール分けがうまくいったせいか、実装時に衝突が殆ど無かったのは良い点だったと思いました。やはり多人数開発をする上では、各自が全員の進捗状況を常に見れるわけではないので、後々面倒にならないようにモジュール分けの段階でしっかりと構想を練るのが重要ということが骨身に沁みました。最初から最後まで一緒に開発を進めてくれた班員には厚く御礼申し上げます。開発全体を通して9割くらい精神的に辛い時がありましたが、この程度で音をあげていたら会社に就職した時に何年も経たずに辞めるのが関の山だと思うので、これからまたゲームを作ろうとしている方たちはぜひ頑張ってください。

・遠藤良峻

• 私はプログラミングがあまり得意ではないので、ロードモジュールを担当しました。セーブモジュールでセーブしたファイルを読み込んでフィールド画面へ遷移するという簡単な作業でしたが、文字列の読み込みに苦しみました。それは文字列に対応する番号をセーブすることによりなんとか免れましたが、改めて自分のプログラミング能力の不足を感じて班員に迷惑をかけてしまったと思います。ごめんなさい。個人的な失敗としてはあまりコミュニケーションを取らなかったために突然仕様が変わっていたりして、謎のエラーが発生してしまったことです。就職したりするとこういうプロジェクトを組んで一つの製作物を作るということもあるかもしれないので、今後の参考にしていきたいと思いました。そして、班員に圧倒的感謝を送ります。ありがとうございました。

・熊谷龍之裕

• フィールドモジュール担当ということで成果が目に見えてわかり、ゲームの多くがフィールド画面なため非常にやりがいがあった。もともとプログラミングは得意な方ではなかったため先生のサンプルプログラムなどを参考にしながらすこしずつ取り組み、目指した機能ができるととても楽しかった。特に力をいれたところはマップ情報をファイル入出力で取り出し、あとからでもイベントの追加などを簡単にできるようにしたところです。マップ画像は、齊藤くんに作成してもらい、僕はイベントに合わせて村人やシンボルエンカウントなどを画像に編集していく形で作りました。来年この授業を受ける人はプログラミングが全然わからなくてもやっていくうちに楽しくなってくるので頑張ってください。モジュールの統合などは班員にまかせてしまったため本当に感謝しています。ありがとうございました。