前回の記事で少しばかり触れたのですが、今回の企画はアジャイル開発を参考にした手法で進めています。
そもそもアジャイル開発ってなんぞや、というと
アジャイルソフトウェア開発 (アジャイルソフトウェアかいはつ、英: agile software development) は、ソフトウェア工学において迅速かつ適応的にソフトウェア開発を行う軽量な開発手法群の総称である。
アジャイルソフトウェア開発手法の多くは、反復 (イテレーション) と呼ばれる短い期間単位を採用することで、リスクを最小化しようとしている。 1つの反復の期間は、プロジェクトごとに異なるが、1週間から4週間くらいであることが多い。
（Wikipedia）
これってスパイラルモデルやプロトタイプモデルとどう違うの？ という点はこちら。
アジャイル開発手法においては、開発対象を多数の小さな機能に分割し、1つの反復 (イテレーション) で1機能を開発する（⇒反復型開発）。 この反復のサイクルを継続して行い、1つずつ機能を追加開発してゆくのである。 おのおのの反復は、小規模なソフトウェア開発プロジェクトに似ている。 各反復では、それまでに開発した成果物に1つの小さな機能を追加する。 計画、要求分析、設計、実装(コーディング)、テスト、文書化といった、ソフトウェアプロジェクトに要する全ての工程を、1つの反復内で行う。
（Wikipedia）
システム一式を反復したりプロトタイピングを行ったりするわけではなく、各機能ごとに分解して、そのひとつひとつを組み上げていくようです。
●アジャイル開発のメリット
そもそもなぜ今回アジャイルを参考にしたかというと、企画者である三尾狐さんが「最初はごく限られたマテリアルで、後々にパッチでキャラクターやルールを追加していく形にしたい」と要望したことがきっかけでした。
- 小規模なプロジェクトに向いている
全体のシステムを機能ごとに小分けし個体が動作する状態でレビューしていく手法は、大規模なシステムで行うと各機能の統合に破綻をきたしたり、工程の進行によって全体像がぶれてしまって使い物にならなくなる可能性があります。規模の小さいシステムでは、製作前にウェイトの重い計画で時間を消費するよりも、まずは動くものを組んでみるほうがスピーディに進行できます。
- 小規模なチームに向いている
人数の多いチームでは情報の伝達やコミュニケーション、個々のトラブルに全体が柔軟に対応することは難しく、どうしても製作前に充分な計画と厳密な管理に沿うことが必要です。アジャイルは文書化よりもとにかく会話を行い、変化する状況に各々が俊敏についていくことを目的としているため、規模の小さいチームに向いていると言えます。うちのサークルも大人数なために計画性重視で回してきたのですが、2チームに分離して経験豊富なメンバーがフットワークの軽い状態に推移したため、採用を検討しました。
●アジャイル開発のデメリット
上に書いた事柄の逆にもこんな危険が。
- 個々が経験、コミュニケーション能力、プロジェクト管理能力に長けていないと破綻する
“小規模でフットワークが軽く”ということは、個々が対応しなければならないケースが激増します。大規模なプロジェクトでは自分はこの担当だからこれに特化していればいいわけですが、アジャイルになるとそうはいきません。
またドキュメンテーションよりも会話が重視されるため、意思疎通がうまく行えない場合はあちこちでちぐはぐな動きが見られるようになります。
同様に、個々は自分の作業だけを注視するのではなく 常に全体像を掴みながら自分の立ち位置や動き方を調整しなくてはなりません。誰々の作業がまだ終っていないから、という言い訳は通用しなくなりますね。
- 協動せずに各自が好き勝手に行動する可能性がある
カウボーイコーディングと言われますが、変化に柔軟であることと各々が好き勝手やることは全く異なります。上にも関係しますが、常に全体の連動を意識して動いていないと、足踏みの揃わない４人５脚のようになってしまうかもしれません。
- 固執すると品質が劇的に落ちる
機能を何度か反復開発し、結果的に合わない時はばっさりと破棄してしまうことが必要です。ここまでやったんだから！ これがないと次のアレが！ と固執すると、結局最初からきちんと計画したほうが良いという状況になります。
●ゲーム開発にアジャイルを適用するメリット
じゃあアジャイルをゲーム開発に適用するとどんないいことがあるんでしょう。
- 同人サークルの形態に合っている
同人サークルは大抵数人、ゲームサークルでも4～5人と比較的少人数です。
- モチベーションを維持しやすい
難解な書類よりも先に動く物や見える物が仕上がります。ビジネスや勉強でもグラフやチャート化すると意識が向上するように、目に見えるものが出来てくることはモチベーションの向上に繋がります。ゲーム開発はとにかくコツコツと根気よく作業しなくてはならないものなので、はっきり分かる進捗や成果物があると順調に進められる確立は高くなります。
- 定期的にリリースでき、プロモーション効果も上がる
小刻みに成果物が出来てくるわけなので、その情報やデータを短いスパンでかつ小刻みにリリースすることができるかもしれません。ネタがあるということは、それだけ定期的にアクセスしてもらえる確率も高まります。
- 開発が早い
どこかで「WEBサービスはβのうちから公開しなさい」というフレーズを見たことがあるのですが、アイディアが古びたり先取りされないうちに出してしまえということだそうです。同人ゲームも絶対数が少ないだけに同じジャンルで被ると結構気まずいものです。
- コミュニケーションの質があがる
各部についてレビューを繰り返すため、ミーティングの質は高まり各自のコミュニケーションも深まります。 監督や制作進行が中心に立って１対１の対応を繰り返すのではなく各々が対応しあうことによって、チームワークも向上するかもしれません。
- 作ってみないと判らない事に対応できる
ゲームはいざ動かして細かくチューンしてみないと判らない部分が沢山あります。アジャイルだと基本的な処理の上に「こんな機能はどうだろう」と提案したものを途中でくっつけていくことが出来ますし、 一つの機能開発を反復して品質を高めていくことができるので、実際に動かして効果を確かめつつ開発ができるメリットがあります。
とまぁこんなことを挙げてみました。
同人ゲームの場合はプログラマ以外にもイラストレーターやコンポーザーも入ってくるので、そのまんまアジャイルの手法を適用できるわけではありませんし、厳密にアジャイルの定義に沿っているわけではありません。しかし参考にしてみるのはなかなか面白いと思います。
では実際にどのようにアジャイルの手法を組み込んでみるのかはまた次回。
うちで使用している吉里吉里はレイヤの直線移動、スプライン曲線移動、加減速、パースペクティブ変形、各種合成・色調補正などが出来るゲームエンジンなのですが、そこでは補えない画面効果があります。そういったものは今までかなり諦めてた（というかUIや画面効果自体に労力をあまり割いてなかった）のですが、今回からAfterEffectsを使って作ってみています。AEは動画編集の仕事のついでにほんの少し触る程度だったんですが、この際勉強しようかなと。
で、前回作ってみたものがこれなんですが
「これ回復というより毒ぢゃね」
とバッサリ。
確かに、色といい泡の形状といい超ポイズンな雰囲気がバブリシャス。
ということで、今度は光が差し込む感じで作ってみました。
フラクタルノイズを黒の平面に掛けて、引き伸ばして、「展開」の項目をうにゃうにゃキーフレームで動かすと出来るそうです。
詳しくはここ見た。
http://ipismsideb.blog8.fc2.com/?mode=m&no=100
あとこれにカラーを適用したりグロー入れたりして、最後スクリーンで加算させて出来上がり。
ゲームのエフェクト程度なら大きくてもせいぜい数百ピクセル程度なので、さくさく作れてとっても楽しいです。なによりエフェクトを掛けた結果がすぐレンダリングで見れるのがいいですね。AEでハイビジョンなんかやろう日にゃ1回RAMプレビューするだけで数十分待たなきゃいけないのを考えるとずいぶん楽です。てかそういうのがあったからAEはあんま触りたくなかったんだけどね……
ちなみに、吉里吉里へは透過PNGシーケンスで吐き出して、TJSからタイマを作ってコマ送りで組み込めます。 
