NEWS

こんにちは。Temple改め卍です。
「Advent Calendar」への参加はこれが初となりますが、まあこれまでに書いていたブログと同じ気分で書いていきます。
そして今回のテーマは、実際のコードのお話ではなく「勉強法」についてのお話です。

Game a Week

さて、この単語について聞いたことがあるという人のほうが少ないかと思います。

この「Game a Week(以下、GAW)」は、オランダ在住のインディーズゲームデベロッパーのRami Ismail氏が提唱した勉強法で、要は「1週間に1つ、ゲームをつくる」というものです。(記事元 : Game A Week: Getting Experienced At Failure)

ただ作るだけではなく、以下のような定義があります。

1. 毎週ゲームを作る
2. 毎週ゲームをリリースする
3. 作り終えたゲームは修正しない
4. パターン化を避ける
5. 振り返りを行う

この5つが主たる定義です。それぞれにさらに細かく定義が設定されていますが、ひとつ難しい点があります。

それは、これはあくまでも1週間を丸ごと使ったものなので、朝9時に家を出て、夜8時頃に家に帰る私としては、けっこう厳しいものがありました。

そこで今回、このGAWの定義の一部をちょっと弄って、外で働いている人でもやりやすく、かつスキルアップを目指せるようにこの定義を改造したものを試しました。

以下のお話では、この定義を改造したものを試した結果を書いていきます。

「週」の定義は変更できない

まずは「毎週ゲームを作る」という定義です。そもそも毎週やることの目的は、「ゲームを作り続けることが、開発の経験を積むためにとてもよい」ためです。なので、いくら仕事をして1日の時間が取れないからといって、「じゃあその分2週間にしよう」という訳にはいきません。

そこで、毎週作り続けるための方法として、ひとつの「機能」に着目して毎週ゲームを作ることとしました。

例えば、「上から落ちてくるボールを地面に当たる前に消すゲームを作る」ということを月曜日に決め、それだけを作っていきます。

ゲームを作るとなると「時間経過によってボールを増やそう」とか「色違いのボールは得点が多い」とか「金色のボールを消したらフィーバーモード」とかが考えられますが、そういうのはすべて無視します。

もしやるとしたら、まずは「上から落ちてくるボールを地面に当たる前に消すゲーム」を完成させたあと、GitHubとかに一度コミットし、そのあと変更を加えていく、くらいのほうがいいでしょう。

「リリース」ではなく「身近な人に遊んでもらう」

次に「毎週ゲームをリリースする」という定義です。

弊社ではそのようなルールはないのですが、会社によっては「勝手にアプリをリリースするな」とか「リリースする場合は許可を取れ」とかもありそうなので、リリースは難しいという人もいるかもしれません。

かくいう私もリリースは行っていませんが、その代わり、知り合いに「こんなのできたわー」と見せることにしています。

そのときに「このゲームに似てね？」とか「こういった動きのほうが難しいんじゃね？」とかそういう話になるときがありますので、その内容は覚えておいて次の糧とします。

すぐ見せられる人がいない場合は、趣味で使っているツイッターやブログに公開してもいいかと思います。

ちなみにこの「知人に見せる」というのは、GAWを実践していた某インディーズゲームデベロッパーの方が話していたことでもあります。

この方も「作ったゲームは仲の良い知人にしか見せなかった」と話しているので、リリースが厳しいという人はこの手法にするとよいかもしれません。

作り終えたゲームはGitHubにコードを上げる

ここで作ったゲームをやってみて「もっと面白くできそう」とか「作り込んでリリースしたい」という場合を除いて、ソースコードはGitHubに上げます。

バックアップという意味合いではなく、後でコードを見直したりするのにも適しています。特に、readmeに「どういうゲーム」かを書いておくことで、GAWの定義である「パターン化を避ける」を守ったり、修正後にはコミットとして上げることで「作り終えたゲームは修正しない」も守ることができます。

まだ「作り込んでリリースしたい」というものに出会っていないので、そういうものが出たらプロジェクトをどう管理していくかはまだわかっていませんが、恐らくはBitBucketなど、他からは見えないプライベートな場所で管理すると思います。

製作中に思ったことはメモ書きしておく

今回GAWをやるうえで最も難しかったのは「振り返りを行う」でした。なにしろ、身近にこういった話ができる人がいなかったので。

こうなるとセルフレビューするしかないのですが、次に「どのような基準でレビューするか」となります。

これはGAWをやる人によって変わりますが、私の場合は「どうすればよりイケてるコードになったか」を考えています。

例えば、「ここをインタフェースにすればよかったかなー」とか、「ここはこのデザインパターンあてはめればよかったかなー」とかです。

これらがレビューで上がった課題ではありますが、この課題の反省を振り返りを行った作品に対して適用することはしません。

そしてこれらをメモ書きしておきます。Evernoteに書くなり、いつも持ち歩いているメモ帳に書くなり、GitHubに上げるreadmeに書くなり、なんでもいいです。

ここでメモするのは、次にやるGAWの作品に振り返りができるようにするためです。そうしていくことで、ゲームの種類に応じて開発の手法を変えることができるようになりました。

まとめ

ここまでで、GAWを自分なりにアレンジして実践していきましたが、じゃあ実際のところ「うまくいってるの？」と質問されるとすれば、答えとしては「100点満点のうち80点くらい」です。

  GAWの手法ができているかどうかを判断するとき、完ぺきにできている状態を100点としたとき、私は「継続してできているか」が80点、「経験を積んでいるか」が20点という分配をしています。なので、今回実践した結果としては「経験を積めたかどうかはわからないが、継続はできた」ということになります。

これは、あくまで個人的な考えではありますが、ゲーム開発の経験を積むためには、まず何よりも「継続して作り続ける」ことが最重要ですので、「経験を積めたか」という点で見るより、「きちんと継続しているか」に比率を置くことが大切だと思います。

そしてこの記事を公開したのは月曜日です。ちょうど今日からGAWを始めれば日曜日には完成して振り返りができます。

それではこれで。みなさんもLet's Game a Week !