以前から、「プログラマやグラフィッカーのノウハウに比べ、ゲームデザイナー／プランナーのノウハウは、圧倒的に流れている情報が少ない」と感じています。原因としては、すでにリリース済みのタイトルであっても、その内部仕様の権利は発売元や開発元（つまり会社）に依存するので、容易に公開することができない、という部分があります（守秘義務ってやつですね）。

たまにあったとしても、大元のコンセプトデザインの話であったり、観念的な話であったりして、現場で即役に立つローレベル・超具体的ノウハウというのは極めて限られているのが実情です。

とは言え、「無い無い」と嘆いていても仕方がないので、自分で書いていく事にしました。
正直「俺なんかが…」という部分もあり、先ほどの守秘義務に抵触しないように何か書く、というのは意外と難しく、ちょっと途方に暮れそうになったのですが、ふと思い出しました。

もう2年半も前のことになりますが、「俺の屍を越えてゆけ」等で著名な桝田省治さんが、Twitterで「戦闘計算式初級講座」を呟いていたことがあったのです。

大変参考になったTogetter
http://togetter.com/li/15113

これを読むだけでも十分ためになるんですが、個人的に読み返しやすいようにまとめ直してみました。
「最初から他人の褌かよ！」という感じですが、まあ…試運転ということで…。

・適切なバランス取り
　　ゲーム内の戦闘におけるプレイヤーの緊張感の維持
　　　　いくつかのミスや不運が重なれば「死ぬ」というリスクを感じること
　　　　　・何発殴れば敵を倒せるか
　　　　　・敵に何発殴られればやられるか
　　※ボス戦では当然変わる
　　※マップの広さや体力の回復手段によっても変わる
　　※想定するターゲットによっても変わる

・ごくオーソドックスなＲＰＧの標準的なバランスをイメージ
　　・４対４あたりの集団戦が普通
　　・雑魚戦なら２発か３発殴れば敵を倒せる
　　・１戦闘で平均２発殴られ、それを回復せず放置すれば５戦闘(１０発)で死ぬ。
　　　＝１発殴られると最大体力の１／１０が削られる。
　　　　　Ｎ発で死ぬなら、１発あたり１／Ｎのダメージを受ける。

・話をわかりやすくするために

　とする。

・攻撃力100 － Ａ ×　守備力100。
　　Ａ ＝ Ｎ発で死ぬ補正値 ＝ １ － (１／Ｎ)

　　　　Ｎの値の例
　　　　　　味方→雑魚敵：２.５(２発か３発で敵は死ぬ)
　　　　　　雑魚敵→味方：１０(１戦闘２発くらっても５戦闘保つ)
　　　　　　味方→ボス：　２０(回復魔法を使うボスなら１６など)
　　　　　　強力なボス→味方：　３

・「攻撃力＜Ａ×守備力」のとき、「攻撃力－Ａ×守備力」ではダメージが出ない。
　そういうときのためによくやるのは、
　　（攻撃力－Ａ×守備力）＋ｐ
　　ｐの値は、
　　　・ＤＱなら０～４あたり
　　　・いわゆる桝田ゲーなら攻撃力／６４～攻撃力／３２とか

・パラメータの最大値は999、レベル50、全パラメータが600でラスボスに勝てる。
　ゲームスタート時は全部100。
　　※目安を立てるため単純にしている。

・1レベルでパラメータ10上昇？
　　→攻撃力や守備力はその半分程度が武器防具に依存する
　　　　→1レベルあたり5前後が妥当。
　なので、例：20レベルなら体力は300、攻撃力も300（腕力200＋剣100）

・20レベルの主人公がそれなりの緊張感を維持しつつ戦う適正な敵は、体力、攻撃力、守備力がすべて300。
　　※こういう管理にしておけば、常に体力、攻撃力、守備力が同じ数値になり、
　　　先の「攻撃力－Ａ×守備力」が、そのまま使用できる。

これで各レベルの主人公の強さ、各レベルの敵の標準的な強さ、各レベルの主人公の標準的な装備の値が大まかに決まった。
これらはここで固定してしまう。どうせ強さは相対で決まる。
何かを最初に固定して基準にしないと先に進まない。

・仲間キャラや敵の個性づけ
　　・魔法使いなら体力が主人公の２割引
　　・戦士なら攻撃力は１割増
　　　　→「攻撃力100－Ａ×守備力100」に放り込んでシミュレート。
　　　　　　→イメージに合う数値Ｂを見つけら、「Ｂ：100」の比でもって、
　　　　　　　各レベルの魔法使いや戦士のパラメータを割り出す
　　　　　　　　→そこから武器防具の数値を決める。

・敵のパラメータ
　　・妙に硬い奴
　　・体力は少ないが攻撃力が高いヤツ
　　　　→「攻撃力100－Ａ×守備力100」に適当な数値を放り込んで、イメージに合う数値を見つける。
　　　　→その比を汎用化して各レベルの曲者を同じ手順で作る。

私がRPGを作った時も、色々と分析や試行錯誤の結果、同じような式と手法になりました。

10/21(日) 、「ゲーム・開発・UXD情報交換会」に行ってきました。
http://kokucheese.com/event/index/55576/

NAVERまとめ
http://matome.naver.jp/odai/2135083108152832201?utm_medium=twitter&utm_source=twitterfeed

ゲーム開発者・ソフトウェア開発エンジニア・UX(ユーザーエクスペリエンス)研究者が集って情報交換しようという会。
15分単位の短めの発表・ダイアログ(4～5人グループでの対話)・ビアバッシュという構成。

冒頭「ブログに書くまでが勉強会」というお話があり、「自分なりに解釈してアウトプットして、他人と共有可能な状態にしないと勉強会を受けた意義が薄くなる」という意味だと解釈しました。
私は勉強会ちょいちょい出る方ですが、確かにまとめるのは面倒がってあまりできてませんでした。
今回はきちんとまとめようと思います。

会の趣旨や参加コミュニティの紹介は上記リンクに詳しいので割愛。
各発表を見ての個人的にポイントだと思った部分と所感(青文字)をつらつらと。

■コミュニティ・団体紹介
▼hcdvalue
http://www.slideshare.net/hcdvalue/hcdvalue-14642843
・学術研究が現場に活かせていない

　　強く同意。今回のような会がもっと開かれると良いのでしょうね。

・HCD=人間中心デザイン(Human Centered Design) 。

・UXD= User eXprerience Dsign だが、これだと「ユーザー体験をデザインする」という感じがする。
　「Design for UX」という表現の方が良いのでは？

　　ゲームデザインにおいても、「ユーザーの感情を誘導する・操作する」
　　という主張をたまに見るけど、健全でない感じがします。
　　強制的ではなく、自然に感情が動くようなデザインを心がけたいところ。

・デザインする際には、ヒト(&UX)・UI・モノやサービスを取り巻くContext(どういう環境で使うか)も大事。

　　確かにターゲットが「どういうユーザーか？（年齢・性別・嗜好）」が意識されることが多いけど、
　　とりまく環境（プレイ時間・ユーザーの立場・生活スタイル）などの考慮は見落とされがち。
　　考慮ポイントをあらかじめポイントとしてまとめておくのも良さそう。

▼DevLOVE
https://speakerdeck.com/u/papanda/p/devlove-in-a-nutshell
・自分の仕事を憎むには人生はあまりにも短い
・自分たちのことは自分たちでやるしかない
・一生涯ソフトウェア開発　たかだか300人月

　　状況を変えるためには動くしか無い。
　　自ら帆を張った方々の行動力は素晴らしいと思います。

▼IGDA日本

・南米にもIGDAの支部がいくつかできた。最近勢いがある
・アフリカにも1つ支部ができた

　　この前のGCSで新清士さんが東南アジアのゲーム市場の盛り上がりについて公演されていましたが
　　（https://sites.google.com/site/gamecomsummit/session#session03_2001）
　　南米、アフリカも盛り上がってきている様子。
　　今まで東アジア・北米・欧州が話題の中心になってきましたが、今後は中東なども含め、
　　全世界の動向にも注目ですね。

■発表
▼hcdvalue発表
▽「ヒューマンインタフェースな学会に参加してみた」(ちゃちゃきさん @chachaki)
http://www.slideshare.net/hcdvalue/ss-14820829

・UXには4つの期間がある（利用前／利用中／利用後／利用時間全体）

　　「プレイしていない時間も、そのゲームの事を考えているようなら、それは良いゲーム」
　　と言われたりしますね。
　　どうやって攻略しようかな…どんなキャラにしようかな…名前は…カスタマイズは…
　　などと考える余地があるゲームは、継続率が高くて長くプレイしてもらえる可能性が高い、
　　というのは経験則として知っていたけど、それが明文化された感じ。
　　後できちんと追ってみたいです。

▽「APCHI2012にて、アイデアを伝える」(白澤さん @shirasy)
http://www.slideshare.net/shirasy/20121021hcdvalueshirasy

・APCHI = Asia Pacific Conference on Computer Human Interaction

・ゲームをあつかったセッションも

・ペーパーホワイトボードワイヤフレーミング
　　・ノートに書いて説明すると、口頭よりも共有効率高い。

　　　　とても当たり前の事だけど、当たり前のことをきっちりやるというのは意外と難しい。

▼IGDA日本発表
▽「ゲーム業界から見たUX」(小野憲史さん @kono3478)
http://www.slideshare.net/kono3478/ux-14827357
・ゲーム業界不変の法則：
　　1.ゲームは技術進化に裏打ちされた遊び
　　2.技術の進化で領域が拡大する
　　3.領域の拡大でクリエイターが広がる

・ゲーム業界は「KGN=こんなのゲームじゃない」の繰り返しの歴史だった

　　現在「ソーシャルゲームはゲームか？」が盛り上がっていますが、
　　極端な形(かつてはサン牧のような育成、今ではカードソーシャル)だけに囚われた議論は
　　不毛だなあと思っていました。
　　確かにファミコンが出た時も、アーケード界隈からは「しょぼい子供のオモチャ」
　　と言われていたということですし、
　　どんなモノも、出始めは多くの問題を抱えてるもんだと思います。

　　新しい芽を潰すのではなく、「どうやったらもっと良く・面白く・健全に収益を上げられるようになるのか」
　　を考えた方が建設的だよね。

・ゲーム業界にとって、UXとはファン＝楽しさ　として認識されていた。

・ソーシャルゲームがもたらしたゲームの広がり
　　・ユーザーの拡大(無料ゲーム)
　　・ファンの変化(課題解決→社会承認)
　　・ゲームの変容(企画重視→運用重視)

　　ゲームの変容については、私個人も「職人芸的作品の販売業」から「サービス業」に
　　急速にシフトしていると感じていて、サービス寄りになりすぎなんじゃないか？と思っています。

　　KPIによるユーザー動向分析に合わせて改善するのもいいけど、
　　「俺はコレが面白いと思う！ついて来いよ！」的な熱さを失ってきているんじゃないかと。
　　まあそのカウンターとしての現状なんでしょうけど。

　　今後は、この両極のバランスをどうとっていくのか、が重要なポイントになるのだろうと思っています。

▽「ゲーム業界から見たアジャイル開発」(長久勝さん @mnagaku)
http://www.slideshare.net/mnagaku/ss-14819297

・ゲーム開発でアジャイルを選んだ場合の注意点
　　・「変化を抱擁する」→ただの朝令暮改　になる危険性
　　・アジャイルは本来、「強すぎる管理を緩めて、自主的な規律で代替しよう」というものだが、
　　　ゲーム業界の場合「弱すぎる管理の引き締め」に使おうとしていて、本来の文脈外

　　「安易にアジャイルを取り入れてもうまくいかない可能性が高いよ」ということなんですが、
　　そもそも新しい手法に対しての拒否感というのはまだまだ強い気がします。

　　アジャイルが銀の弾丸ではないということは早くから指摘されていることで、
　　重要なのは手法ではなく、「現状がダメなんだったらなんとかしなくちゃいけない」
　　という原則を忘れないことなのではないかと。

▼DevLOVE発表
▽「学び方を学ぶことを学ぶ」(伊藤宏幸さん @hageyahhoo)
http://www.slideshare.net/ssuser968fab/ss-14807961

・学び方にもパターンがある→「学習パターン」
　例）どっぷりつかる→プロトタイピング→「まねぶ」

・「コツ（how）」と「こだわり（what/why）」の違いを意識することが重要

　　スライドにはありませんが、「守破離」のお話もありました。
　　（守破離とは：http://www9.ocn.ne.jp/~kihunkan/syu_ha_ri.htm）

　　何にせよ先人が「こういういい方法があるぜよ」という事はまずちゃんと真似してみること、
　　それによって自分に合わないところが出るだろうから、
　　そのカスタマイズを次の段階として行う。
　　先ほどのアジャイルの導入にもつながるところがありますね。

▽「Lean!!Lean!!Lean!! – 開発現場から愛をこめて -」(及部敬雄さん @TAKAKING22)
http://www.slideshare.net/TakaoOyobe/20121021-leanleanleandev-love
・リーンスタートアップの「MVP」= MinimumVariableProduct(実用最小限の製品)だが、
　小さすぎて価値のないものでは意味が無い。

・ドラクエで学ぶ「リーンスタートアップ」
　　・価値：平和
　　・ユーザー：人類全員
　　・何をすれば良いか判らないので手頃なスライムを倒す→最小の価値
　　・ユーザー中心：村人に話をして次を計測する
　　・学ぶ：毒消し草
　　これを回していくのがリーンスタートアップ

　　リーンスタートアップは気になってますがまだちゃんと追えてないです…。
　　今回の発表でさらに興味が増したので後でちゃんと追いたいなと。

　　発表の手法として、ドラクエのように皆の共通体験に根ざした例を用いる、というのはGoodですね。

▽「『Experience Visionのはじめかた』に見るDevLOVE勉強会のススメ」(滝川さん @takigawa401)
http://www.slideshare.net/takigawa401/experience-vision-devlove

・ユーザーの要求に対して直接的な解決を与えるのではなく、ユーザーの本質的要求に響く提案型
　例）「朝起きられない→目覚まし」ではなく
　　　「朝起きられない→可愛い子のモーニングコール」の方がイイよね！

　　ちょっと上記の例についてはピンときませんでした。
　　私の中の直接的解決と提案型解決というと、ゲームで例えるとこんな感じ。

　　　問題：「敵が固すぎて勝てねえ。クソゲー。」というプレイヤーからの不満
　　　　直接的解決：敵の防御パラメータを下げる
　　　　提案型解決：
　　　　　１.実は進行度に対して、敵の強さが上がる率と、プレイヤーの成長速度のバランスが悪かった。
　　　　　　　　→味方のパラメータが上がりやすいように調整
　　　　　２.実は弱点をつけばすぐ倒せるのに気づかれてなかった
　　　　　　　　→弱点であるポイントをプレイヤーに気づかせる仕組みを入れる
　　　つまりは
　　　　・直接的解決…「不満だと言われた事に関する場当たり的対応」（マイナス→ゼロにする）
　　　であるのに対し、
　　　　・提案型解決…「不満の発生原因を分析し、根本的に解決する、あるいは付加価値を与える」
　　　　　　　　　　　　（マイナス→プラスにする）
　　　という考え方なのではないかと思ってました。

　　Experience Visionは初耳だったので誤解があるのかも。また気になるものが増えたｗ

・スケッチング
　　・コーディングを始める前に、同様の機能を人力でシミュレートし、素早く評価する。

　　たまに結構ガッツリコーディングして組み込んでから「やっぱダメだったね」となっちゃって、
　　それを「ゲームはトライ＆エラーが当たり前だ！」として正当化してしまうことがままありますが、
　　できるだけ無駄なトライ＆エラーは減らしたいものであります。

　　人力(ボードゲーム風に紙とコマで試す)や、簡単なシミュレート(Excelの関数とかマクロとか)で
　　さっとシミュレートして手早く評価するのは有効だと思います。
　　…が、「作るの面倒～」とか「実装まで時間がない～」とかで見切り発車することも多いんですが…。

　　↓ともつながる話ですね。
　　『失敗してもいい方法でとにかく試そう！マイクロビジョン西田竜太氏が提案する
　　“デジカメプロトタイピング”【CEDEC 2012】』
　　http://www.famitsu.com/news/201208/23020022.html

・「サポーターの1人が、誰かの手をつないでスタジアムに来てくれれば、観客は倍になる。
　両手をつないでくれれば3倍になる。
　俺達は誰かを誘いたくなるサッカーを見せなければいけない。」大熊清　前FC東京監督

　　いい言葉。サポーター(ファン)が増えるようなコンテンツを作って行きたいものですね。
　　金払いのいい一見さんとかばかり大事にするのでなく…。

■ダイアログ
　・いい企画のためのコツ・こだわり
　・いい開発のためのコツ・こだわり
について、4～5人のグループでそれぞれ10分で話し合いました。
色々な話が聞けて面白かったですが、やっぱり10分は短いですね。
これ中心の会とかあってもいいんじゃないかと思いました。
1つのテーマ30分くらいで話して、またメンツをシャッフルするとか。

■ビアバッシュ
いわゆる飲み会ですが、発表の会場そのままでやったので、移動の手間が無いのはいいですね！
また立食なので、話すメンツが固定化されにくいのも良かった。
飲食OKで電源まで取れるステキ会場を提供していただいたオラクルさんには大感謝！です。

■全体を通して
今回は第0回だったそうで、お試し開催ということなんですかね？
ゲーム業界は少し前まで非常に閉鎖的で、横のつながりが薄いものでした。
業界内部での交流もまだまだだと思いますが、業界内部だけでなく、
学術方面や隣接業種との関わりも大事だと思います。

ソーシャルの盛り上がりによってWEB業界はかなりオーバーラップしてきてますしね。
学術方面の知見を現場にフィードバックする流れは全然足りてない感じですし。

そういった意味で今回の会は非常に意義深いものだと思います。
ビアバッシュまで含めて1000円という超リーズナブル価格もありがたかった！
ぜひ次回も＆定期的に開催していただけると嬉しいです～

去る3/20(土)、GamePM（ゲームプロジェクトマネジメント）勉強会に参加してきましたー！

祝1周年！えーと、私は第5回から参加しているから（忘年会も入れて）4回目ですね。

当日の内容に関してはminamoさんのレポートに詳しいので割愛。
以下ちくちくと感想など。

「３DCG映像製作の現場の声とマネージメントの声」
by 森田佑貴さん

「日々の作業確認ができていれば、マネジメントの大半はできていると言える」という言葉に納得。ものすごく初歩的なことだけど、出来ていない現場は多いのではないだろうか。ボトルネックになっている部分の洗い出しや、問題点を早めに見つけて大事になる前に処理できればそれだけで立派なマネジメント。

３DCGにおいて「セットアップ」の重要性のお話。要はモデリング後のボーンの仕込みやウェイトの調整のことだけど、会社（や場合によってはチーム）によって定義が異なるし、専門性も高いので下手に外部に任せると大変な事になるよ。ということだと理解したのだけど、確かにセットアップの重要性はわかりにくい。現場に入りたての頃とかほんとに良く分からなかったなあ。場所によって作業分担や呼び方までバラバラなこともあるし。

あと印象深かったのはモデリング工数のお話。長髪やヒラヒラした服は大変だから可能な限り避けよう、ってお話はよく出るところだけど、キャラクターデザインの段階で、その辺のジレンマを解消したデザインにするってのは、覚えておきたいポイント。
確かに某超有名RPGのヒロインは、袖がヒラヒラした着物っぽい服なのに、袖を胴部分と分けてしまうという思い切ったデザインでありましたね。あれは機能美であったと。

まとめの「プロジェクトマネージメントとは、止めない、目を背けない、逃げないことに尽きる」という言葉は心に沁みました…。

「Scrum 始めました」
by 田中 宏幸さん

第6回でminamoさんが発表したScrumをいち早く導入し、しかも自社向けにカスタムした結果を報告するという、実に参考になる導入事例でありました。ダメだった部分、というのはなかなか外に出て来にくいものなので、そのあたりの赤裸々な部分まできっちり押さえていた部分は大変ありがたい。

一番大変だったのがScrumを導入するための「説得」だった、というお話には涙を禁じ得ません…。現状の開発環境に不満はいだいているものの、いざ新しい体制を導入しようとすると反発が出たりすることはよくあるもので、このハードルを越えただけでも素晴らしい。こういった事例が増えるほど、より頑なな組織への導入の障壁も下がろうというものなので、どんどん広まっていって欲しいものですね。

「毎朝のスクラムミーティングだけでも効果が高いのでオススメ！」というのは心強い報告。朝礼というのは得てして形骸化しやすいのですが、「立って」「15分で」というルールを徹底することがポイントなのでしょう。redmine等のチケット駆動型開発とも相性が良かったものと思われます。

スプリントレビュー（成果物の確認会）で、狭い部屋に大勢を詰め込んだら酸欠になった、という下りは生々しくて大変面白かったですｗ。しかしそこで「失敗だったね…」と諦めるのではなく、きちんとカスタマイズして改善に結びつけているところはお見事。

今回の田中さんの事例は、ある程度勝手知ったるメンバーであった、ということなので、あまり馴染みのないチームではどうなるのか…といった事例が知りたくなりました。

ライトニングトークスとは、5分で強制打ち切りとなる発表。

「認定スクラムマスターについて」
by 今給黎隆さん

何につけても資格というものはあるもので。上記のスクラムにも「認定スクラムマスター」というものがあるそうです。今給黎さんも取られたとのこと。しかし2日で20万（旅費・宿泊費等を除く）は厳しいな～…。
現場レベルでしっかり継承されていくと良いと思います！ｗ

「5分でわかるARG」
by 松尾直貴

不肖私の発表でした。いやー、前回40分の発表やったから5分くらい大丈夫だろ！とか思ったら、コッチの方が辛かった気がする罠ｗ。やっぱ20数ページの内容を5分でやるのは無理だった orz。というか体感時間3分くらいで、どこで息継ぎしたらいいのかわからないくらいのハイペースになってしましました。ちゃんとリハーサルやっとけよ俺…。という学びを得ました(｀・ω・´)ｷﾘｯ。前向きな俺カコイイ！　…orz。

…ふぅ。当日使用した資料貼っときますね。（多少表示が崩れています）

で、一番言いたかった「俺もイベント企画してるからヨロシクね！」という部分がタイムアップになってしまい残念賞～であったとさ。せっかくだから俺はコッチのブログで宣伝するぜ！

シモキタ＠クエスト

「参加したい！」という方はこちらのブログをチェックしていてください～。

「自分もイベント作りやってみてぇ！」って方は大歓迎です。横っちょのメールフォームでもTiwtterのリプライやダイレクトメッセージでもかまいませんのでご連絡ください！

「Vimエディタを使おう」
by thincaさん

エディタはソフト開発者にとっては商売道具の一つなわけで、愛用のエディタたるや、長年使いなじんだ万年筆にも匹敵するこだわりが生まれるわけです。ということで、thincaさんの愛あふれるVimエディタのご紹介。プログラマさんにとっては使いごなし甲斐のありそうなエディタだなと感じました。

私も今のところ秀丸エディタを愛用しておりますが、まだそんなに「秀丸LOVE！」て感じではないので、機会があったらVimエディタも試してみようと思います。

ワークショップでは、模造紙に2009年度を4半期に分けてラインを引き、ポジティブなことは赤い付箋に、ネガティブなことは青い付箋に書いて貼りつけていくという「タイムライン」という方法で振り返りました。その後１年のアップダウンを線グラフにして描き、漢字一文字で表わしてみました。さらに2010年度の意気込みをまた漢字一文字で表現。個々人の個性の出た、直感的な図が出来上がりました。

やはり勉強会に参加するような方は危機意識が強いですね。プロジェクトの体制やマネジメントには皆さん苦慮されている模様。今回の勉強会で蒔かれた種が、それぞれのチームで良い結果を生みますように。

しかし毎度思うのはグラフィッカーさんが少ない印象。人数比としては多い職種だし、決してマネジメントと無縁だとは思えないので、今後参加者が増えると良いなと思います。