2012年8月11日土曜日

福島GameJam in 南相馬2012の感想

8/4、5に開催された東北ITコンセプト福島GameJam in 南相馬 2012に参加してきた。30時間で即興のチームでゲームを作るという催しだ。

前回、技術的な話を書いたので、今回は全体的な感想を。

福島GameJamは昨年に引き続き2回目の開催。今回は、高校生も含む地元の若い人の姿も多く、ITによる震災復興という目標に少しは近づけたかもしれない。

ぼくのチームは8名で、全員がプログラマという無茶な構成。内訳は、ある程度の経験者4名、若い人4名。

SEGAの石畑さんがチームにいたが、ぼくは開発中はバーチャロン・シリーズのプログラマの人だと気づかなかった。というか、開発で頭がいっぱいだった。バーチャロンはかなり夢中になったゲームだったので、緊張しかねないので、開発中は気づかなくてよかったかもしれない。

それぞれのメンバーの経験したことがある開発環境はバラバラだった。若い人たちはC(やC++)を習っているところだが、さすがにこれでゲームを作り始めると30時間では終わらない予感。話し合った結果、enchant.jsで開発することになった。

ゲームの企画を考えて、個々のタスクに落としていく。ぼくは、各メンバーがコーディングできるように、最初にゲームのフレームの部分を作ることになった。その間、他のメンバーはコードが書けないので、絵を描くことになった。

プログラマに絵を描かせるなんて…。

そもそも絵を描くツールすらパソコンに入っていない。スッポンを描け、ヒバリを描け、馬を描け、風船を描け…。想像を絶するタスクが割り当てられる。

ゲームのフレーム部分ができたのは、1日目の夜。2D横スクロールのマップ上をスッポンが這って移動し、風船などのNPCにつかまって障害を乗り越え、それぞれのステージのゴールを目指すというもの。

あんまりJavaScriptに慣れた人はいないので、その後も、苦しい戦いが続く。というか、Cしか習っていない若い人は、オブジェクトがどうのと言われてもよくわからなかったかもしれない。また、JavaScriptの場合、クラスベースの言語と異なるし、同じものを記述する方法が何種類もあるので、最初はわかりにくいだろう。

また、設計上、コードを再利用しようとしてコンフリクトするよりも、個々のプログラマの裁量にまかせる方針にした。しかし、その辺をうまく共有しそこねて、作業は多くなるわ、コードのコミットとマージでボトルネックが発生するわ、となかなか厳しい開発となった。

うまく基本を設計しようとすると、作業分担できるようになるまでに、時間がかなり必要となる。30時間内で、基本設計と個々のコーディングの時間配分はなかなか難しいものを感じた。

昨年参加したときは、チーム構成はプログラマ2名+グラフィッカ3名だった。ある程度の経験者のプログラマ2名だと、プログラムを完全に分業できるように分担することは容易で、ほとんどこの問題は発生しなかった。

半分が若い人で、全員プログラマだと、どう分担するかは悩ましい問題だ。経験者1名+若い人1名のサブチーム4つに分けて、個々に完全に分業できる形で開発するなど、特殊なチーム構成に応じた対応が必要だったかもしれない。

作ったゲームは、以下のリンクから遊ぶことができる。ところどころバグっていて、音が出なかったり、地面に埋もれたりする。

なお、プログラマ8名というありえないチャレンジに対して、Unity社からUnity賞をいただきました。どうもありがとうございます。

いずれにせよ、とてもチャレンジングな環境で苦しい戦いを戦ったチームのみんなに感謝します。 もちろん、運営や他のチームや関わったみなさんにも。

また、ふだんチームで開発しないので、いろいろと参考になることが多かった。

帰ってきて、リリース版のコードを読み直してみた(バグを修正しちゃおうか、敢えてこのままにしようかちょっと悩んでいる。というか、実はほとんどリファクタリングもしちゃったコードが手元にある)。若い人たちの書いたコードを見て思ったことなど。

  • コーディング規約に対する留意
    コーディング規約を決めていたわけではないが、変数、定数の命名方法などは、周りに合わせた方がいい。また、インデントは適切に行なった方がいい。
    というのも、バグを見つけて直すのは、下手をするとコードを捨てて1から書き直した方が楽なくらい激しく大変なので、読みやすく間違いを見つけやすく書いた方がいいということ。
  • 状態の管理があやしいところがある
    状態遷移図を書いてから、コードを書いた方がいい。
    というのも、状態も、バグりやすく直しにくいので、きちんと最初の段階から管理する必要があるので。
  • 他人に影響するコードの追加・修正
    コードを追加・修正するときは、他人に影響しないように行なった方がいい。難しい場合は、相談した上で。

若い人の書いたコードを見て、学校でプログラムの書き方を教えているが、そこで何が不足しているのかについて、いろいろ参考になることが多かった。今後、是非、役立てたいと思う。これは、ぼくにとっては、本当に大きな経験となった。

2012年8月7日火曜日

福島GameJam in 南相馬2012の技術的教訓

東北ITコンセプト 福島GameJam in 南相馬2012に行ってきた。

今回は、8人のチームで全員がプログラマという構成だった。その中で、結果として、前半にベースのフレームとなるプログラムを作り、後半は主にはプログラム相談に応じたような形となった。

そこで、技術的な教訓を書いておこうと思う。

今回は、enchant.js(JavaScript+HTML5なゲームフレームワーク)でゲームを開発して、次のものが必要だと思った。

1.クラスベースの言語のプログラマ向けのJavaScriptの説明資料

『Ajaxイン・アクション』の「付録B オブジェクト指向プログラマのためのJavaScript講座」でもいいかもしれない。しかし、そのために厚くて情報が古くなっている本を買うのはちょっと厳しいような。
あと、JavaScriptのデバッグ方法書いたものも欲しいかも。たとえば、たにぐちまことさんの『よくわかるJavaScriptの教科書』のFireBugの使い方の説明は詳しくていいかも。

2.enchant.jsで多人数でコーディングするときの設計とコーディング指針

3.はじめての人向きのGitなどの分散バージョン管理システムの説明資料

前回の福島GameJamでは、2人でenchant.jsでコーディングし、完全に独立に書けるように分担した(更に、わたしは途中で具合が悪くなってあんまり役に立たなかったという話も)。
今回は、8人でenchant.jsでコーディングしたところ、分担するためのベース(含む検証)のコーディングに1日目を使ってしまい、だいたい2日目から分担してコーディングに入った。
それでも、あんまりうまく設計できなかった部分があり、コード間の結合性が高くなってしまった。そして、分担時の説明がJavaScriptをやったことがない人にはあまりうまくできなかったような気がする。

また、8人でコーディングしたところ、コミットとマージで時間ロスがあった。

なお、前回のときは、シーンの結合があんまりうまくいかなくて、結局、jQueryでオープンニングつけたりした。その後、『ゼロからはじめるenchant.js入門』が出て、これを読んだところ、今回は問題なくできるようになった。