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

19::gr08::最終発表

TOP

プロジェクト名

脱出ゲームツクール

プロジェクト説明

脱出ゲームをユーザーが作成し、作ったゲームをプレイできるゲームの作成。
・ユーザーが用意した画像をゲームの背景、アイテムのグラフィックとして利用できる。
・東西南北の4方向をそれぞれシーンとして管理し、アイテムやオブジェクトを自由に配置できる。
・各オブジェクトに効果を加えられ、制作するゲームのフラグとして作成できる。

ものと操作の洗い出し

モジュール分け

ゲーム説明

詳細な操作はリポジトリ上のREADMEファイルを参照。 「最終発表」を開いてください

  • htmlファイルを開くとツールが起動し、タイトル画面が表示される。
  • 初めに画像編集を行う。
    • 画像変更には画面のリロードが伴い、編集がリセットされてしまうため最初に一回しか実行できない。
    • 指定したディレクトリの中の画像を外側から同じ名前で置き換えて、プログラム内部で呼び出すファイルを変更させる。
    • 書き換えたらリロードする。
  • 次にアイテムの編集を行う。
    • アイテムの名前、効果(カギ、ハコ、ドア、カザリ:見た目だけの物)、対応先を指定させる。
    • 配列の中に格納されるため、編集画面にも対応できる
  • 最後にシーン毎の編集を行う。
    • 制作したアイテムを設置する。
    • ハコの効果を与えたアイテムは中からアイテムを取り出せる。
    • ドアはゴールの条件となる。
  • そして作成したゲームをプレイできる。
    • 何度もテストプレイと編集を行き来できる。

プログラム概要

  • pushsceneでの変遷の間に、配列に保管した座標や画像、効果を呼び出し、それを引数にして関数を実行するなどして作成→実行を実現している。
    • 作成ゲームデータの保存、再現までは断念・・・
  • ハコはアイテムを取り出し、カギはハコかドアを開け、ドアでクリアできる。見た目だけのアイテム(ヒントのアイテムなどに使用)も実現。
    • 入力フォームやマウス操作などによる謎解きを作成できるようにしたかったが、それも断念。
  • ドアのカギを開けることでゲームクリアのシーンに飛ぶ。

ツールのスクリーンショット


Screenshot from 2019-08-02 12-20-46.png
Screenshot from 2019-08-01 20-38-57.png
Screenshot from 2019-08-01 20-39-20.png
Screenshot from 2019-08-01 20-40-37.png
Screenshot from 2019-08-01 20-42-36.png
Screenshot from 2019-08-01 20-49-22.png
Screenshot from 2019-08-01 20-49-28.png


個人の感想、苦労・工夫した点

高橋司

主に、アイテムに効果を持たせることを実現するモジュールを作成した。
pushscene、addchildの仕様を理解する段階で時間をかけてしまい、実際に効果を持たせる方法を考えるまでになかなか到達できなかった。 しかし、ボタンによるアイテムタイプの規定に成功してからは意外とスムーズに進行できた。 橋本君が作ってくれた、アイテムの名前、画像、効果の配列を要素に持つ二次元配列を使わせてもらえたので(それと文字入力フォーム)、そのうち名前の配列をユーザの操作に合わせて指定された要素を上書きするようにして、実現できた。

実際の操作は、ボタンのクリック判定をイベント発生のトリガーとし、アイテムの種類それぞれのイベント内で、「ユーザにより変更されたアイテム名」「そのアイテムが四種類のうちどれか」「どのアイテムと対応しているか」をそれぞれの配列に格納し、適切に呼び出されるように頑張った。

実際のアイテムの効果(カギを開けるプログラム、ハコから取り出すプログラム、ゴールするプログラム)は谷口君が作ってくれているので、実際やったことといえばたくさん配列を定義したくらいである。イベントごとに配列をわけたり、アイテム全体の配列を使ったりと使い分けをするところが工夫と言えるかもしれない。
あと、アイテムの対応がきちんと規定された時にテキストの表示で「〜を開けます」などと表示されるようにした。これがあるとないとで結構安心感が違う。

谷口隆一

作ったものはアイテム配置、アイテムの効果、ちょっとだけテキスト。
もっとアイテム効果を増やしたかった!
セーブ機能は時間がなくて実装できなかった。時間があれば実装したい。
もっとはやく作ってテストプレイするべきだった。
つくってから、あの機能がほしい。と思うことが多かった。

阿部修也

シーン編集やテストシーンでの画面の管理を担当した。 最初にSceneごとで分割しようとしたために、pop・replace・pushでSceneを切り替えた配置したアイテムのデータの保持がうまく行かず、とても時間がかかってしまった。結局、Sceneで分けることは断念し、背景画像を方角ごとにわけてそれを切り替える方法にした。実際やってみて、この方法のほうが、もしズームアップする箇所を実装する時(今回は時間の都合でできなかったが)、別の背景画像を用意して追加するだけなので楽だと感じた。アイテムの配置に関しては、関数を用意してくれた隆一のおかげで実現することができた。自分のプログラミング知識が浅いために単純なことでも時間がかかってしまったりして、本当に勉強不足だった。そして最終的な統合がとても大変で、最終的な統合を担当してくれた隆一には感謝しかない。

今回1からjavascriptを学び、初めてチームでプログラミングをしてみて、モジュール分けの段階からもっと細かく分担をきめて、モジュールごとの関わりなどをしっかり把握した上で、作業にとりかかることが大切だということがわかった。
一つのjsファイルにまとめなければならなくなった時の大変さをよく知ることができた。

橋本裕太

  • 作ったものに関して
    アイテム管理の担当で、主にアイテム一覧画面での画像と名前の表示、そこから名前やアイテムの効果などを編集する画面への遷移、またその編集を行う部分を製作した。高橋くんに効果の付与の部分を作ってもらっらので、自分は名前の変更を反映させたり、作ってもらった部分と統合してそれに合わせてボタンを配置したりした。

  • 工夫した点
    • 当初、編集画面に遷移してからでないとアイテム名の変更ができなかったところを、アイテム一覧の画面から名前の部分をクリックすることで、同じ画面内で入力フォームを出して名前だけ先に編集できるようにした点。
    • アイテム名を編集する入力フォームを出した時に、フォーム内にその時点でのアイテム名(「item1」や「鍵」など)を書いておくようにしたことで、今どのアイテムを編集しているのかをわかりやすくした点。

      どちらも些細なことではあるが、ユーザーの使用感的にも、自分たちの製作におけるテストプレイにおいても、割とストレスフリーになったと思うし、何より、意外と便利って言ってもらえてよかった。本来はもっと担当すべきところがあったのに、能力不足で足を引っ張りまくってしまったので、ちょっとでも便利にしたかった。

  • 苦労した点・感想
    アイテム管理の担当だったにもかかわらず、自分はただ表示をしたり名前の変更をする部分だけになってしまって、肝心なアイテムの効果を付与する部分や、アイテムの配置なども他のメンバーに作ってもらうことになってしまった。作ってくれたメンバーには感謝をしてもしきれないし、本来はそこまでが自分の担当であり、それが計画通り進んでいればもっと充実した機能をつけられたり他のことにも時間を使えたはずなので、自分の能力不足を痛感した。
    思い通りのものを実現するためにはどのように進めて行くべきか。言語の知識すらないまま書いているのに、さらにサーバーという触れたことのないものを1から勉強して機能を実現するべきなのか。このやり方で本当に実現できるのか。本当に難しいことばかりだったし、「できない」繰り返しだったが、とりあえず動くものができたということは間違い無く今回の成果だし、初めてグループで1つのものを作ることができてとても良い経験ができた。
    話し合って勉強して考えてコードを書くことを、限られた時間の中で行わなければならないため、もっと時間を見つけてコツコツ進めるべきだった。なるべくみんなが集まる時間は話し合ったり考えたりする時間に使い、個人で勉強したりコードを書いたりする時間をつくるべきだったと今になって気付いて後悔している。とりあえず動くものを作り、そこから少しずつ手直しをしたり機能を増やしたりしたかったが、少ししか実現できなかった。ただ、これも1つの経験と捉え、次の製作であったり、また他のことにおいても時間を有効に使い、早い段階から少しずつでも取り組むことをこれからに活かしたい。

熊谷太翼

画像のアップロードするシーンのモジュールを担当した。本来はブラウザの画面上で使用したい画像のアップロード、管理をしたかった。しかし、javascriptだとできず、直接ファイルを編集することになってしまった。また、画像を変更した後にリロードをする場面でもenchant.jsではできず、ブラウザのリロードでするしか無いが、他のモジュールとの兼ね合いでとても使いづらい仕様になってしまった。これらの不本意な結果となってしまって、自分の能力が足りないことを深く実感した。
また、使うプログラミング言語やライブラリによってできることとできないことがあるということを実感し、自分たちのやりたいことに合わせて選択することが大事だと学んだ。また、メンバーとのコミュニケーションが足らず、他のメンバーの進行具合や、プロトタイプがどこまで進んでいるか、どういう形で統合するかということを知らなかったり、わかるのに時間がかかってしまったことが多々あった。だから、gitlabなどコードを共有するツールがあっても、直接情報を共有することが大事だとわかった。また、自分もコミュニケーション不足だったと思うので、もっと情報を共有する必要があったと感じた。
他にも、今回初めて他の人と共同でプログラムを作ったが、他の人のコードが読みにくかったり、理解しづらいことがあった。翻って、自分のコードもとても読みにくかったり、理解しづらかったはずだと思う。このことから、コードの読みやすさや、コメントアウト、変数の名前の付け方等の重要性がわかった。これからは、他人がコードを読むのかにかかわらずそれらの点について気をつける必要があると実感した。


最終更新日:2019/08/02 12:31:24