お久しぶりです。まーぼうです。 最近暑すぎで溶けそうです。はよ冬になってくれ～～～～～
今日は、6月上旬になったハッカソンの話をしようと思います。割と雑な文になっています。 Q.なんで今更？ A.ずっと書くのサボってたからです。
だいたいどんな事したの？
traPハッカソンは2018年の6/10(日)に開催された部内ハッカソンです。3～4人でチームを組んで、8時間くらいでお題を満たす作品を作るという行事でした。チームによってはTAが入る事があり、自分はTAとしてチームに参加しました。
自分のチームは学部1年生が4人で、全員初心者というチームでした。事前準備として6/7までに使用言語の決定と制作物のアイデア出しをチーム内チャットで行い、6/7に顔合わせと制作物の作り方決めをし、そのまま6/10に突入しました。ある程度動くものができたんじゃないかなと思いました。 チームとしての報告記事はこちら。 trap.jp
自分は、制作に関わらずにひたすらサポートに回っていました。
具体的にやったこと
１本ゲームを作った
最初に使用言語を決めました。そしたらjavascriptを使うことになりました……が、この言語は自分は使い慣れていないものだったので、とりあえず練習しないと、という事になったので、習作として1つ簡単なゲームを作ることにしました。チームの人の練習教材になる可能性も考慮し、丁寧に書いたつもりです……と思ったけど、だいぶコメントが端折られてるし初学者が読めるかというと疑問ですね。 ゲーム内容としては、アクションゲームの制作までは参考プログラムとして耐えられるように「当たり判定がある」「毎フレーム移動処理をする」という仕様を入れることにしました。
だいたい7～10時間くらいかけたらこんなものができました。避けゲーです。
先週の土曜日と今日を使ってjavascriptで避けゲーを作ってみました。javascriptは慣れなくて難しいですね…… pic.twitter.com/iDKdjMqG3M
— まーぼう@1日目西ら43b (@mabo_game) June 8, 2018
ソースコードはこちらに置いています。
出てきたアイデアからゲームの仕様に落とし込む手伝い
ゲームを作ること自体ははじめの方に決まっていたので、顔合わせの際にどんなゲームを作りたいかを聞いてみました。
- 帰る、2DRPGのマップ画面
- 家に帰るすごろく
- 上から降ってくるマスを避ける、避けた増すを踏み台にして登っていく
- マリオみたいなやつ、桝太一を取ると強くなる、レベルアップで卵からカエルへ
ゲームの概要は上から降るやつ以外は上手く合成できそうな感じがしたのと、上から降るやつは初心者4人だと技術的に難しいのが明確だったので、難易度について説明しながらそれ以外の３つを融合していく方針で誘導しました。また、イメージがファミコンゼルダに近いんだろうなと感じたので、実際にプレイ動画を見せてゲームの完成イメージを全員で共有しました。
アイデアを深めていく段階では、桝太一のアイデアが秀逸でメンバーがそこから話を広げていってました。最終的にこの4つがゲームのアイデアとして進めていくことにしました。
ちなみに、ゲームの枠組みについて実装がどれくらい難しいかは次のように説明しました。
そのあとはゲームの仕様を細かく話し合って列挙しました。また、実装の優先順位をつけると良いので、それをつける作業もさせてみました。
S+:作らないと他の機能が作れなくなる機能
- キャラが十字キーで動かせる
S:絶対に作らないといけない機能
- マップにスタートとゴールがある
- ゲームクリアする
- ゲームオーバーする
S-:作らないとコンセプトが消えてしまう機能
- 桝太一がいる
- 進化制度がある
A:できれば付けたい機能
- タイトル画面からの遷移
- マップに障害物がある
- 敵（山口）がいる
- 敵にぶつかると退化する
B:時間があれば付けたい機能(上)
- 敵が動く
C:時間があれば付けたい機能(下)
- 桝太一が動く
- 時間制限（立ちすぎると冬になってゲームオーバー）
- タイトル画面にステージセレクト
- 敵の種類を増やす
- 敵の動き方を増やす
そして、その他実装のために決めておかないといけない部分を指摘しました。
- ステージの大きさは何マス*何マス？
- 1510?→実際にゲームを触ってみて考えて2217
- 1マスの大きさは何px？
- 32px
- どんなグラフィックが必要？
- カエル
- 蛙
- おたまじゃくし（手足）
- おたまじゃくし（手）
- おたまじゃくし（何も生えていない）
- 卵
- 桝太一
- 山口
- マップ（なくてもよい）
- カエル
- タイトル
- 宿題
- サウンド
- BGM
- フリーでとってくる
- なーるほどマスカレッジのオープニング
- 効果音
- フリー
- BGM
最後に作業担当を決め、参考資料の共有をしました。
出てきたバグや実装の疑問点への対応
当日に色々わからない部分が出てきたので対応です。ぶっちゃけ休んでいる暇がなくて大変だった。どんな質問が飛んできたかも覚えてないです。反省。
意識したことは？
全員が初心者なので、ハッカソンで身につけて欲しい・体験してほしいことの優先順位を次のように考えました。
- とりあえず何か作ってみていったん完成させる
- 何か作りたいとなった時の作り方を身に付ける
- gitの使い方
そのため、プログラムの質問には「これをヒントに考えてみよう」というのを投げてみて、それでも分からなかったら手とり足とり教える、というのを心がけようと思っていた。ただ実際は質問攻めになったしまったので、ヒントを出しすぎたり出さなさすぎたりしてしまった。
得た知見とか反省点とか
TAってムズイ。というのは置いておいて思ったことを書きます。
サンプルコードの用意は微妙そうだった
質問対応の際に１回だけサンプルコードのここを参考にしてみてみたいな感じで対応をした。しかしよく分からず結局丁寧に教えた。そもそもソースコード読める人はつまりにくいからあまり意味ないなと思った。やるのであれば、ソースコードを要素要素に分解して解説まで入れないと初心者にはきつい。そこまでやると結構手間になるだろうから、TAガチ勢にならないとあまり効果を発揮しないと思う。
ただし、事前課題として「これを真似して実装して」みたいな事をやるのは効果が大きいと思う。というか、事前課題を明示しておいてスキルアップさせておくのは大事な気がする。まず「なにをすればいいか分からない」という状態になっているように感じた。 これに関連して、最初のとっかかりとしてハッカソンを位置づけるなら、「ハッカソンを通じて今後どんな事をしていくか」という事を具体的に明示化する活動をさせるべきだと思う。今後何するかが曖昧なまま最初のとっかかりが終わってしまうのは勿体無いと思う。
体験優先なら基盤部分についてはバッサリ教えてしまって拡張・改善の時間がとれるようにすべきだった
今回は基盤部分も最初はヒントを与えるだけにしたが、普通に答えを言って良かった気がしました。（ゲームは特に）どう装飾・改善・拡張するかの方がゲーム制作の面白さを感じやすい気がします。プログラムの文法を学ぶのもそこを足がかりにしたほうが身につきやすい気もします。初めから基盤を学ぶのって割と苦痛なので、自分がそうだったからといって他の人にもそうさせる必要はないと思いました。 ここまで書いて思いましたが、こういう指導方針はチームを組んだ時にメンバーに聞けば良かった気がします。隠す必要ないし。
今回は以上です。想像以上に雑な文章になってしまった気がします。やっぱりこういう記事はイベント終わったらすぐに書くべきですね…… ここまで読んでくださりありがとうございました。
