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

主に、アイテムに効果を持たせることを実現するモジュールを作成した。

仕様としては、グローバル的なアイ列にITEMNAME、ITEMFOR、ITEMTYPEresultという、それぞれアイテムの名前、対応先、そのアイテムの効果を、ボタンのクリックをトリガーとして配列に格納するようになっている。
橋本君が作ったアイテム編集ページで作られた配列をそのまま使ったり、その名前の要素だけ取り出して別で格納したりして引っ張ってきやすくなっている。 あとは、それぞれのアイテムにボタンを四つ表示し、押されたらひとつだけ色の違うボタンになって、カギを押したらそのアイテムはカギということが格納され、対応先を入力するフォームのシーンを出す、という条件分岐も丁寧に作った。

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

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

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

作ったものはアイテム配置、アイテムの効果、ちょっとだけテキスト。(アイテム使用時、入手時)アイテム効果が思いの外難しく、時間がかかってしまった。バグも多く、取り除くのが大変だった。
つかさから渡された配列を元に効果を設定。アイテムを配置しそれを阿部修也に渡した
もっとアイテム効果を増やしたかった！
セーブ機能は時間がなくて実装できなかった。時間があれば実装したい。
もっとはやく作ってテストプレイするべきだった。
つくってから、あの機能がほしい。と思うことが多かった。

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

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

• 作ったものに関して
  アイテム管理の担当で、主にアイテム一覧画面での画像と名前の表示、そこから名前やアイテムの効果などを編集する画面への遷移、またその編集を行う部分を製作した。高橋くんに効果の付与の部分を作ってもらっらので、自分は名前の変更を反映させたり、作ってもらった部分と統合してそれに合わせてボタンを配置したりした。
  
  
• 工夫した点
  • 当初、編集画面に遷移してからでないとアイテム名の変更ができなかったところを、アイテム一覧の画面から名前の部分をクリックすることで、同じ画面内で入力フォームを出して名前だけ先に編集できるようにした点。
  • アイテム名を編集する入力フォームを出した時に、フォーム内にその時点でのアイテム名（「item1」や「鍵」など）を書いておくようにしたことで、今どのアイテムを編集しているのかをわかりやすくした点。
    
    どちらも些細なことではあるが、ユーザーの使用感的にも、自分たちの製作におけるテストプレイにおいても、割とストレスフリーになったと思うし、何より、意外と便利って言ってもらえてよかった。本来はもっと担当すべきところがあったのに、能力不足で足を引っ張りまくってしまったので、ちょっとでも便利にしたかった。
    
    
• 苦労した点・感想
  アイテム管理の担当だったにもかかわらず、自分はただ表示をしたり名前の変更をする部分だけになってしまって、肝心なアイテムの効果を付与する部分や、アイテムの配置なども他のメンバーに作ってもらうことになってしまった。作ってくれたメンバーには感謝をしてもしきれないし、本来はそこまでが自分の担当であり、それが計画通り進んでいればもっと充実した機能をつけられたり他のことにも時間を使えたはずなので、自分の能力不足を痛感した。
  思い通りのものを実現するためにはどのように進めて行くべきか。言語の知識すらないまま書いているのに、さらにサーバーという触れたことのないものを１から勉強して機能を実現するべきなのか。このやり方で本当に実現できるのか。本当に難しいことばかりだったし、「できない」繰り返しだったが、とりあえず動くものができたということは間違い無く今回の成果だし、初めてグループで１つのものを作ることができてとても良い経験ができた。
  話し合って勉強して考えてコードを書くことを、限られた時間の中で行わなければならないため、もっと時間を見つけてコツコツ進めるべきだった。なるべくみんなが集まる時間は話し合ったり考えたりする時間に使い、個人で勉強したりコードを書いたりする時間をつくるべきだったと今になって気付いて後悔している。とりあえず動くものを作り、そこから少しずつ手直しをしたり機能を増やしたりしたかったが、少ししか実現できなかった。ただ、これも１つの経験と捉え、次の製作であったり、また他のことにおいても時間を有効に使い、早い段階から少しずつでも取り組むことをこれからに活かしたい。

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