全体の進行及びwikiへの記載

班員への仕事の振り分け

俺ウィキいじったり喋ったりしてるだけで実際の中身を何も考えてないなって

病欠

病欠を取り戻すため統合を中間発表までに完成させることを決意

結局統合は終わらせられず、他の班員が作ってくれたものを他の班員が少し繋いでくれて、それを俺がしゃべるだけだった。リーダーとして頑張らなければいけない。

今後統合までにそれぞれ完成させるべきものをまとめ、ステップを踏んで目的を目指すための手はずを整えた。

インターフェースの書き出しをした。 今夜中に画像をスキャンして書きだした表をwikiに貼り付ける。
フラグ管理のモジュールの担当に戻り、カギ、ハコ、ドア、カザリという四つにアイテムを分類できるようなモジュールを作ることが目標。

↓自分用メモ
テスト用プログラムを作成する。
kagi,hako,door,kazariの配列をもとに、
kagiはhakoかdoorのどちらかをopenにする効果、hakoはopenになったとき別のkagiアイテムを入手できる、doorはクリアの条件か視点変更の条件、kazariは完全に見た目だけのアイテム

テスト期間が終了し、時間を割けるようになったため連日端末室に通った。声をかけて集まってくれる班員に心から感謝をしている。 自身のモジュール、及び全体のレイアウトを慎重に編集した。 なるべく班員がスムーズに作業を進められるよう、現時点での目標、最終的に動くものにするための妥協点、それぞれの作業を班員全体に指示するように心がけた。

総括

あまり大きな声では言えないが、初めは脱出ゲームを作る予定だった。プロ演室からの脱出ってテーマで山中先生に見せたら、つまんなくな〜い？そんなの毎年あるよ〜。みたいに言われて、例えば生徒が脱出ゲームを作れるとかさ〜。とか言ってきて、多分なんとなく思いつかれたのだと思いますが、ああなるほど、それいいかも、とか言っちゃって、第三週目にしてテーマが変更になった。
先生の思いつきを具体的にするために、かなり頭をひねった。そりゃあ「脱出ゲームを作るツール」って言われて思いつく機能はいくつかあるが、それを作れってか？みたいに、班員に案を出してはええ〜みたいな顔をされ（役割分担は先に決まっていたので、思いつく機能が該当するモジュールの担当者に無茶振りをしていた）、俺はなんて班長なんだと思い悩むことも多かったが、なんとか以下のような苦労を通して完成した。今となってはいい思い出だ、といいたいところだが班員はたまったものじゃなかっただろう。

• フラグ管理のモジュール訳を担当になった。 最初まず分担が決まった後、自身が何を作れば「フラグ」というものを実現できるのか全くピンときてなかったうえ、後述の班長かつプロジェクト提案者としての雑務（班wikiの編集や班員とのイメージ共有）に時間を咲くだけの日が多かった。
  
  
• 実際にモジュール作成を本格的に始めたのは第十回以降である。さらに言えば、授業期間の間はモジュールを見た目でわかりやすくするためのボタンなどのレイアウトで苦戦していたため補講期間のみで作成したとも言える。
  • 何に苦戦したかというと、pushSceneの使用上、一度定義したボタンクラスを何度もシーンいaddChildできないという仕様を理解するのに時間がかかり、何度も治るはずのないボタンの表示バグと戦っていた。
    • TAさんもボタンクラスの仕様をよくわかっていなかったようで、何が原因なのかすぐに発見できなかったこと、そして僕自身が無駄に粘ってしまったことも敗因である。
    • 結果うまく行ったからいいが。
    • ちなみにボタンクラスを使う回数個分用意しないといけないよ、と谷口君にあっさり解決された。この時から僕は谷口君に頭が上がらない。
      
      
• 補講期間ではかなり頑張った。配列をたくさん作って、アイテム名、その効果、効果先を別で保存し、かつ他のシーンで呼び出せるようにした。
  • 実際配列の作り方は橋本君のものをガッツリ参考にした。
    • 入力フォームなんて彼の丸パクリだ。
    • 彼にも頭があがらない。
      
      
• そこから先は統合作業だ。本当にガッツリと谷口君に頼りっきりだった。
  • 本当は谷口君の功績を、彼のwikiに勝手に書きたいくらいだ。
  • 流石にそこまで勝手な真似はできないので、代わりにここに記して先生に報告しようと思う。
    1. 全体のレイアウト（タイトル画面、メニュー画面）
    2. メニュー画面からのシーン遷移
    3. シーン編集画面の作成（東に置いたアイテムは西では当たり判定が消え、もう一度東を向くと復活する仕様）
    4. シーン編集とテストプレイの座標データの橋渡し（阿部君との合作）
    5. 僕が渡した配列に応じたアイテムの効果
       • カギでハコを開けると次のカギが手に入る、カギでドアを開けるとクリアする、カザリは使うとズームされる、といった操作はすべて彼が作った。
    6. デバック、全体の統合
       
       以上６つ（把握してる限りで）が彼の功績である。もちろん彼のワンマンプレイではなく、他の班員や僕も関わって刺突のものに向かったわけではあるが、それでもすべての橋渡しをした彼には本当に感謝している。
       
       さて、話が脱線したが、とにかく僕が作ったのは、いくつかの配列にそれぞれ別の要素を入れ、その配列の要素を持ってくるだけでユーザが設定した効果を自由にもたせられるよ。という部分だ。
       
       

前述の通り副班長の谷口君にはお世話になりっぱなしだったが、一応班長としては結構頑張った。

• まず、僕が「脱出ゲームを作ろう」と言い出したので、完成図のイメージ共有にはかなり気を使った。
  • 紙に図を書いて説明したり、各班員がそれぞれどの部分をつくるかにも丁寧に伝えたつもりだ。
  • 最終的に各班員にかかるウェイトに差が生まれてしまったが、それも勉強になった。
• 自分が作っているものに気を張り続けられず、他の班員に任せた部分でどういうふうな仕様にするかも考えていたので、第７回目の授業くらいまで本当に苦しかった。
  • しかし、その後任せた部分を一人ひとりがしっかり目標達成してくれていたので、結果オーライというか、なんとかゴール出来たなという気持ちだ。
• 後半は僕はモジュールづくりに専念し（LINEなどでスケジュール調整をしたり各班員のそれぞれの現時点での目標を伝えたりは頑張ったが)、統合は谷口君が頑張ってくれていたので、大変ではあったし時間もかかったが、スムーズにことが運べた。

最初の七回のうちは、毎週金曜日が苦痛で仕方がなかった。 そんな状況から、発表では、閑静な教室でみんなの感性を動かし歓声があがるものを完成させられたので本当に良かったし、たくさん学ぶことがあった。
それも、毎回きちんと自身の達成度を報告し、次に何をするべきかを確認してくれる班員がいてくれたからだと思うし、そのおかげで僕自身も何が作りたいか固まっていった。 しかし進行の早い班員に、「こういうものを作って欲しい」とお願いするだけの、班長というよりクライアントみたいなムーブをしてしまったことは本当に申し訳ないと思っている。
しかし、ある意味では提案者として最後まで責任を持っていたということだし、自分も全く何もしていなかったわけではないので今となっては悪くはなかったのかなと思う。班員には謝罪よりも感謝を述べたい。

複数人数でのモジュール分けによる一つのコンテンツ作りがここまで大変だとは思わなかったし、僕自身のスキル不足も痛感した。今回はリーダーとしての働きだったので全体の管理を見渡すことを大きな動きとして、スキル不足によって迷惑をかけることは（ヘイトは集まるが）あまりなく、むしろ他の班からよく聞く情報共有のミスの多くを防げたなと思う。しかし、次にいちプログラマーとして、クライアントから指定されたものを作るとなると、今回のようにはいかないなと感じた。自分自身がうまく出来たこと、うまく行かなかったことを含めて、本当に勉強になった。

先輩たちがみんなこれをやってきたんだと思うと敬意を払わずにはいられないし、後輩たちがみんなこれをやるんだと思うと幸運を祈らずにはいられない。かなり険しい道だったので「いい授業だった！！」と心からの笑顔で言うことはできないが、得られるものは非常に大きかったし、これがないと情報科を卒業できないなと思う。

もしこのページを後輩が見ていたら、アドバイスをいくつか送りたい。参考にしてほしい。

• プロジェクトを提案した人へ
  • もし、全員一致って感じではなく、一人が挙げた案をぬるっと採用した感じだったら、製作中に「これってどうすればいい？」みたいに聞かれることが多いだろう。
  • そしてその場合、おそらく「提案したし班長になるわ」って言わなきゃいけない感じになるだろう。（俺が完全にそうだったってわけではないけど、そういう発想もよぎった）
  • そんな君は絶対に製作にとりかかる前に全体図みたいのものを紙に書いたりして早めにイメージを共有したほうがいい。
  • そして、「もしもっと良くなりそうなアイディアがあったら、作る前でも後でもいいからみんなに報告して」と伝えたほうがいい。
  • 俺は前者はやったが後者はやらなかったので、「できたけど次何したらいい？」という質問に苦しめられた。俺の作業が遅いのが悪いんだけどね。
  • 仲の良い友達二人と相談するのは簡単だが、班全体の注目を集めて発言するのは知メ情の僕らには困難なのでみんなやりたがらないが、無理矢理にでもやらせていこう。
    
    
• 二人で一個のものを作ってたり、自分が作ったものが必須なものを周りが作っている人へ
  • 前準備とか表示の書き方とか、プラグインの使い方とか、そういうものはすぐに周りに相談しよう。似たものを作っている人が班の中でも外でもいたら、やりかたをすぐ聞こう。
  • あるいは去年以前のwikiを見てみよう。
  • 少しでも出来たらgitに上げて、周りも少しでも出来たら上げるように言おう。上がったら何を上げたか見よう。
  • 配列は便利だからどんどん使おう。使い方はうちの班のやつを見てもらえば結構わかると思う。
    
    
• 全体を通して
  • 統合は本当にしんどいから複数人でやろう。特に、統合するプログラムを作った人は居合わせたほうがいい。
  • 統合のやりかたは一個のスクリプトファイルにまとめる、で本当にいいだろうか？僕らはそうしたが、結局外に２つ目３つ目のスクリプトを作った。分けて出来そうかも考えてみてほしい。
  • javascriptはマジで勝手に動く。多少のミスを無視して動いて、後から変な挙動になったりする。コンソールとにらめっこしよう。
  • enchant.jsもatomも本当にすごいから色いろなプラグインとかパッケージを探してみてほしい。「えっそんな便利な機能があったのか」とあとから知ったとき割と凹む。
    • atomだと「log」とだけ書いてtabキーを押すとコンソールログがすぐ出せたり、対応する括弧がどこにあるかわかったり、htmlのプレビューをatomの中で見れたり..
    • enchant.jsだといちいちvar ~ = new ~みたいにしなくてもクラスを呼び出せたりする。
  • そもそもクラスって何？見たいん段階なら先生やTAにガンガン聞こう。 .
    .
    .
    .
    .
    .
    .
• 思いついたら追記しようと思う。