作成者別アーカイブ: Kensuke Shimoda

Kensuke Shimoda について

ゲームデザイナー。代表作は「BFB2015」「FFアギト」。最新作「GDH2030」は2016年にリリース予定。

Unity5.3のパーティクルで遊んでみる

この記事はUnityアドベントカレンダー12月25日分の記事です。

前日の記事はtnayukiさんの「宴のカスタムコマンド作成について」です。


Unity5.3になってParticle SysytemのEmitterの形状にSkinned Meshが利用できるようになったということでそれについての記事を書こうと思ったが、なんとバグがあって利用できない(5.3.1p1で未解決)ので、Unity5.3になってスクリプトからアクセスできるようになったParticle Systemのプロパティについて書くことにした。以下が5.3のParticle Systemの変数の一覧である。New!!と書かれているのが新しく追加された変数である。

collision New!! Access the particle system collision module.
colorBySpeed New!! Access the particle system color by lifetime module.
colorOverLifetime New!! Access the particle system color over lifetime module.
duration The duration of the particle system in seconds (Read Only).
emission Access the particle system emission module.
externalForces New!! Access the particle system external forces module.
forceOverLifetime New!! Access the particle system force over lifetime module.
gravityModifier Scale being applied to the gravity defined by Physics.gravity.
inheritVelocity New!! Access the particle system velocity inheritance module.
isPaused Is the particle system paused right now ?
isPlaying Is the particle system playing right now ?
isStopped Is the particle system stopped right now ?
limitVelocityOverLifetime New!! Access the particle system limit velocity over lifetime module.
loop Is the particle system looping?
maxParticles New!! The maximum number of particles to emit.
particleCount New!! The current number of particles (Read Only).
playbackSpeed The playback speed of the particle system. 1 is normal playback speed.
playOnAwake If set to true, the particle system will automatically start playing on startup.
randomSeed Random seed used for the particle system emission. If set to 0, it will be assigned a random value on awake.
rotationBySpeed New!! Access the particle system rotation by speed module.
rotationOverLifetime New!! Access the particle system rotation over lifetime module.
scalingMode New!! The scaling mode applied to particle sizes and positions.
shape New!! Access the particle system shape module.
simulationSpace New!! This selects the space in which to simulate particles. It can be either world or local space.
sizeBySpeed New!! Access the particle system size by speed module.
sizeOverLifetime New!! Access the particle system size over lifetime module.
startColor The initial color of particles when emitted.
startDelay Start delay in seconds.
startLifetime The total lifetime in seconds that particles will have when emitted. When using curves, this values acts as a scale on the curve. This value is set in the particle when it is create by the particle system.
startRotation The initial rotation of particles when emitted. When using curves, this values acts as a scale on the curve.
startRotation3D New!! The initial 3D rotation of particles when emitted. When using curves, this values acts as a scale on the curves.
startSize The initial size of particles when emitted. When using curves, this values acts as a scale on the curve.
startSpeed The initial speed of particles when emitted. When using curves, this values acts as a scale on the curve.
subEmitters New!! Access the particle system sub emitters module.
textureSheetAnimation New!! Access the particle system texture sheet animation module.
time Playback position in seconds.
velocityOverLifetime New!! Access the particle system velocity over lifetime module.

全てについて触れる時間はないので、効果が見て確認しやすいcolorOverLifeTimeを使って簡単なプログラムを組んでみようと思う。

まず最初に断っておきたいのだが、全てにおいてこのようなプロパティをスクリプトでコントロールすることを推奨しない。何故なら「コードを書かずにエディターだけでゲームが作れる」のが最も理想的なUnityの利用方法であって、原則としてコードを書かない手段を優先的に探したほうが良い。今回紹介するランタイムでパーティクルの色を変える方法は色の設定だけ違うprefabを複数用意すれば同じことはできる。しかし、いずれにせよコンポーネントを1つ作るならAssetsフォルダ以下のprefabの数も、一つのシーンにロードするprefabの数も少ない方が良い。そういうわけで1つのParticle SystemのcolorOverLifeTimeを次々と変える方法について紹介する。

interactiveParticleInspector

まずは、色を変更するためのコンポーネントを1つ用意する。ここではInteractiveParticleSystemと名付けた。今回はそこまで紹介できないが、ゲームプレイの展開に合わせてパーティクルの色やサイズを変化させることを想定したためにそのような名称にした。

Gradientの配列でParticleの色の設定を複数用意する。今回はColor Change Timeが経過するとランダムでそれらの設定のどれかに変更するというのを試して見る。

    public ParticleSystem particle;
    public Gradient[] colorOverLifeTime;
    public bool randomColor = false;
    public float colorChangeTime;
    float colTime;

    void Update () {
        if(particle != null && randomColor == true){
            RandomColor();
        }
    }

    public void RandomColor(){
        colTime+=Time.deltaTime;
        if(colTime >= colorChangeTime){
            colTime = 0;
            int i = Random.Range(0,colorOverLifeTime.Length);
            var col = particle.colorOverLifetime;
            col.color = new ParticleSystem.MinMaxGradient(colorOverLifeTime[i]);
        }
    }

実行結果は以下のようになる。左手首のパーティクルをこのInteractiveParticleSystemが管理している。

particleColorChange1

放出済みのパーティクルまで瞬間的に色が変わってしまっている。この表現が適している時もあるが、放出済みのパーティクルについては色を変えずに、新たに放出されるパーティクルだけ色を変えたい。

そこで、1つのParticleSystemのcolorOverLifetimeを変更するのではなく、新たに色を設定しなおしたParticleSystemを生成して、時間差で古いParticleSystemを消すことにした。複数のprefabを用意すれば同じことができると書いたのはこのことである。

   public void RandomColor(){
     colTime+=Time.deltaTime;
     if(colTime >= colorChangeTime){
        colTime = 0;
        int i = Random.Range(0,colorOverLifeTime.Length);
        StartCoroutine(ChangeColor(colorOverLifeTime[i]));
      }
    }

  IEnumerator ChangeColor(Gradient gradient){
     //既存のパーティクルをクローン
     GameObject newParticleObj = Object.Instantiate(particle.gameObject);
     newParticleObj.transform.parent = transform;
     newParticleObj.transform.localPosition = Vector3.zero;
     ParticleSystem newParticleSystem = newParticleObj.GetComponent<ParticleSystem>();
     ParticleSystem.ColorOverLifetimeModule col = newParticleSystem.colorOverLifetime;
     col.color = new ParticleSystem.MinMaxGradient(gradient);
        //既存のパーティクルを削除
     StartCoroutine(DestroyOldParticleSystem(particle));
     particle = newParticleSystem;
     yield return true;
  }

 IEnumerator DestroyOldParticleSystem(ParticleSystem oldParticleSystem){
     yield return new WaitForSeconds(1.0F);
     ParticleSystem.EmissionModule emit = oldParticleSystem.emission;
     //emissionを停止
     emit.enabled = false;
     float duration = oldParticleSystem.duration;
     //放出済みのパーティクルが消えるまで待つ
     yield return new WaitForSeconds(duration);
     Destroy(oldParticleSystem.gameObject);
     yield return true;
 }

すると以下のように自然に色がグラデーションしていく。

particleColorChange2

どちらかというと、先に挙げた放出済みのパーティクルも含めて色を変える方が以前はできなかったことであり、今回のアップデートの恩恵を受けているのだが、いずれにせよcolorOverLifetimeにアクセスできるようになったことにより、色については自由にどうとでも変化させられるようになった。

今回紹介したのは非常に初歩的な手法であるが、スクリプトからいずれの変数にもアクセスできるようになったことで、一段とパーティクルの表現力が増したと思う。

パーティクルを使った表現はモデリングやテクスチャと違って、絵が描けない人でも工夫次第でゲームのグラフィックスの品質をあげることできるし、アニメーションち違ってUnityの中だけで作業が完結する。そしてシェーダーほどプログラミングは難しくない。GDH2030のように予算も時間も限られたプロジェクトにおいては大変重宝するといえる。ちなみに画像のキャラクターはGDH2030に登場するオリジナルキャラクターである。今回はアドベントカレンダーということで初めてUnityに関する記事を書いたが、今後はこのキャラクターの紹介も兼ねてこのような記事を書いていくかもしれない。

「ファイナルファンタジー アギト」のサービス終了について思うこと

先月末のことだが、1つのスマフォ用ゲームがサービス終了した。BFBが順調にサービス継続されFF11でさえ未だに続いているが、自分が開発に大きく関わったゲームが市場から消えて一切プレイができなくなるという体験は初めてであった。(コーエー時代に関わった「三國志 Online」もサービス終了しているが、あれは開発ではなく運営として関わっていたしそこまで中心的なポジションではなかった。)

僕は2012年末のプロジェクト立ち上げからサービス開始直前の2014年3月までFFアギトの開発チームにいて、主に戦闘部分の仕様設計とプログラム実装を行っていた。サービス終了のこのタイミングで自分にとってこのプロジェクトは何だったのかを色々と振り返ったので、それをここに記す。ここではギョーカイ評論家の人達が喜びそうな話をするつもりはない。2年経たずにサービス終了したからには商業的な失敗と言わざるを得ないが、何が原因で失敗したとかの分析はここでは一切やらない。もちろん仕事としてゲームを作ってる以上、反省や分析は行っているが、それを公開してもギョーカイ分析芸人の皆様をただ喜ばせるだけだし、途中でチームを抜けた人間がそれをやってるのを見たって最後までこのゲームの運営・開発に携わった方達は良い気はしないだろう。自分にも他者にもメリットが全然ない。今自分にとって最も大切なことは、この失敗したFFアギトにも一定数のファンの方達がいたこと、サービス終了を惜しむファンの中に、自分に温かい声をかけてくれた人がいたことである。今回はその人たちのために何か書こうと思った。

また、一緒に仕事をしたスクエニの方達のことは尊敬しているが、具体的にどのようなやりとりがあったかもゲーム業界オタクの人たちを喜ばせるだけなので、割愛する。よって必然的にスクエニの方達の成果についてはあまり言及できない形となってしまうことをご了承いただきたい。スクエニの方達の努力があり、その成果があったことは十分に認識しているし、尊敬していることだけは伝えたい。

プロジェクト参加の経緯

2012年末にBFBがリリースされた。当時の主幹開発会社は株式会社たゆたうで、僕はゲームデザイナーとしてたゆたうと業務委託契約を結んでBFBの中心的な部分を作っていた。当時のたゆたうとの契約は必要な作業単位での契約であり、作業が段々と落ち着いてくる開発後期にはパートタイムの仕事になっていたし、BFBが完成したら次はどうなるかも分かっていなかった。BFBの開発が終わる頃、たゆたうから「スクエニとの新しいUnity案件が始まるから、BFBと並行してそちらにも参加してくれないか?」という話を頂いた。僕は以下の点を鑑みてプロジェクトへの参加を決めた。

  1. 目標だったオリジナルゲーム開発のための資金が足りない
  2. BFBはなんとか作れたが、Unityで1人でゲームを作り切るスキルも足りない
  3. 上記2点のために1年単位のまとまったUnityの仕事がしたかった
  4. スクエニ在籍時の待遇が酷かったのでいつか見返してやりたいと思っていた
  5. FFに思い入れがあり、もう一度くらいFFに関われたらと思っていた
  6. BFBに対しても、もっと貢献したいと思っていた
  7. たゆたうに常駐するならBFBの仕事ももっとやれると思った

当時は船橋の自宅で仕事をしていたが、たゆたうに常駐することになったために、たゆたうから徒歩5分の所に部屋を借りて、平日はそこから通うことにした。

チーム内におけるポジション

たゆたうの社員でもスクエニの社員でもない僕は、両社における分業制度の範疇外となり、両社でプランナーと呼ばれる人達がやってる仕様考案や設計の仕事とプログラマーの仕事である実装の両方を手掛けた。自分で思いついたアイディアをすぐにプログラミングして、ゲームとして動く形でスクエニに対してプレゼンする。このやり方のおかげで開発初期のプロトタイピングでは大きな成果が出た。BFBとこのプロジェクトで実績のあったこの仕事スタイルのメリットについては2014年のCEDECで紹介し、大きな反響をいただいた。

Game Watch 記事【CEDEC 2014】雑用ばかりの「プランナー」から脱するには?

FFアギトで目指したこと

FFアギトはPSPで出た「ファイナルファンタジー零式」のフランチャイズ展開という企画だった。僕はFF零式については、とてもスピード感ある戦闘が印象として残っていた。「クラスゼロ」と呼ばれる少年少女の戦闘エリートが戦場を素早く動き回り、武器や魔法を駆使して勢いよく敵を「殲滅」して行くのがFF零式の魅力だと思っていた。FFアギトの戦闘の内容について最初に提案する機会があった時、僕は迷わずターン制の戦闘ではなくAIがリアルタイムでFF零式と同じようなテンポの戦闘を繰り広げるデモを作った。その内容がスクエニからも好評いただけてFFアギトの戦闘の原型ができた。そこから先はスクエニの方達と一緒にUIの試行錯誤の連続だった。そのスピード感ある戦闘をスマフォゲームユーザーに気軽に楽しんで貰うためにUIや行為に対するフィードバックの表現を改善していくというのが、プロジェクトを通した目標になった。

自分には思いつかなかった「アビリティチェーン」

FFアギトでは、プレイヤーは武器による技や魔法などの「アビリティ」を用いて戦う。海外製のPC用MMORPGなどでよく見る画面下部に並ぶアイコンをタップすると「スキル」が発動するあれである。僕自身そのようなゲームが好きなこともあり、デファクトスタンダードであるそのUIを踏襲することにした。画面下部にボタンとして並ぶアイコンをタップすればアビリティが発動するのである。しかし、ここで問題があった。戦闘中に多くのアビリティを使えるようにしないとプレイヤーが取り得る戦略が広がらないが、そんなに多くのアイコンを画面上に並べることはできなかった。そこでスクエニの方達と何度もミーティングして、試作を繰り返して生まれたのが、1つのボタンの中に連続して発動する複数のアビリティをセットできる「アビリティチェーン」の仕組みだった。例えばMMORPGをプレイしていると、魔法使い系のクラスのプレイヤーが同じタイミングで複数の種類のバフ(強化)スキルを発動するのをよく目にすると思うが、使いたいタイミングが同じアビリティというのは必ずある。それらをひとまとめに発動できるようにして、画面上のボタンの数を減らすことと戦闘に持っていけるアビリティの数を増やすことを両立できた。また、攻撃系アビリティの連続発動はゲームプレイにFFらしい派手さを加えてくれた。実は最初このような提案を受けた時に僕はあまり乗り気ではなかった。どうしても戦闘のUIやアビリティの位置付けをPC用MMORPGのスタンダードに近づけたいという思いがあった。それは長続きするゲームのモデルでもあったし、確実に面白さがわかっているものに近づけて失敗を防いでからゲームバランスを作り込むことでゲームプレイのクオリティアップを図りたいという狙いがあった。結果的には、前述したように連続発動によってスピード感が向上し、ボタンが減ったことでPC用MMORPGなどに馴染みのない人もプレイしやすくなった。これに関してはスクエニとのコラボレーションの1つの成果だと思っている。自分の好きなゲームの姿に囚われないということを1つ学んだ。

ユーザーテストでの確信

開発期間の後期において、プロジェクトの部外者にテストプレイして頂く機会があった。その時、何の説明をしていないのにも関わらず前述のアビリティを駆使してゲームを進めていくテスターの姿を見て鳥肌がたった。プロジェクト上様々な課題は残っていたのだが、このゲームは通用する、受け入れられるという自信がついた。結果的には失敗したゲームであったが、このテストプレイの時からサービス終了の時まで、ゲームプレイそれ自体の評価は決して低くなかったということを伝えておきたい。

リリース直前のチーム離脱

そのように開発に深く関わっていて最後にこんな文章書くくらいには思い入れのあったゲームであったが、リリースの直前に開発会社たゆたうとの契約を終えて開発チームから離れることになった。理由はいくつかある。

  1. たゆたうの近所に部屋を借りていたのは期間限定と思っていたから
  2. 度重なるリリースの延期でその期間が延長されていた
  3. オリジナルゲームの開発を2014年から始めたかった
  4. 並行して参加していたBFBの開発・運営がたゆたうから他社に移管された
  5. スクエニ及びたゆたうがBFBの都合を一切考慮してくれなくなると考えた

当初の考えでは、ゲームがリリースされたら一区切りして、その後運営・開発に参加し続けるにしても100%ではなく30%くらいの関わり方にするつもりだった。しかし、そのリリースがいつになるか分からなくなってしまったため、リリースを迎える前に区切りを付けることにした。また、当時の状況では100%参加するか0%とかどちらか一つであり、時間を減らして関わり続けるという選択肢はなかった。リリース直前にチームを抜けるのは迷惑と思う人もいるだろうが、当時はゲームデザイン自体は既に終わっていて、その実装を僕以外の専業のプログラマーがリファクタリングするという段階だったので、仕様書さえあれば僕がいなくてもなんとかなった。その当時僕が心配していたことは僕がいなくなってゲームがダメになることではなかった。むしろこのゲームが大成功した時に僕がチームを抜けたことを後悔しないだろうかということだった。最後の最後まで、僕はこのゲームの成功を信じていた。

リリース後の評判

結局FFアギトは2014年の5月にリリースされたのだが、当時としてはハイスペック過ぎてプレイできる端末が限られたこと、それまで類を見ない膨大なサイズのデータを扱うために、通信時間やロード時間などでストレスを与えてしまったことなどが災いして、ゲームプレイ以前の問題として叩かれてしまった。また、僕の作った戦闘の部分にしても、PSPのFF零式のアクションのクオリティが高かったため、同じように自分でキャラクターを操作して戦うのを期待していた人たちからの評価は芳しくなかった。FF零式のファンはこのゲームのリリースと同時に絶対飛びついたはずなので、最初の評価としては当然覚悟していた。そしてその不満というのが僕にも直接ぶつけられることとなった。

僕にしかできなかったこと

スクエニの社員でもたゆたうの社員でもない、そして既にチームを抜けている僕は、Twitterで唯一FFアギトの開発スタッフだったことを公言してゲームについて自由に発言していた。そのため、ゲームに不満がある人たちからも目につく存在となった。忘れられないのは、FFアギトの戦闘がFF零式の戦闘と違うことに不満があったある一人のユーザーである。その人は最初とても厳しい口調で僕に意見を寄せてきた。それに対して僕はじっくりとFFアギトの戦闘の実装意図について説明をした。すると段々と分かってきてくれて、最後には「応援してます」とまで言ってくださった。また、他にもFFアギトに不満があるというのをきっかけとしてよく話をするようになって、今でもゲーム以外の話題で交流が続いてる人がいる。自分のゲームをプレイしてくださった人とはできるだけ交流したいと常に思っている。こういうことがあったから評判は別としてFFアギトを作ってよかったと思っている。これから作るゲームでその人たちを楽しませたいと思う。

このプロジェクトから得たもの

FFアギトはリリース時の躓きから大きくユーザー数や売り上げを増やすことができずにサービス終了を迎えた。リリース後の運営・開発についてどのような意思決定があったかは僕には知る由もないし、知っていたとしてもそれを批評したくはない。確かなことは僕はこのゲームを作ることを楽しんだし、このゲームを作る過程でスキルアップできたし、ユーザーの方を含めていろんな方と知り合えたし、得るものが多かった。もちろん、このゲームをプレイして残念に思った人たちのことは忘れてはならない。商業的な失敗について自分の責任が全然ないとはいえない。しかしその失敗についても「ここまで予算が大きく有名なIPで失敗した」という経験はなかなかできるものではない。改めて、スクエニにもたゆたうにもユーザーの皆様にもお礼を申し上げたい。そしてこの恩返しというのはこれからもゲームを作り続けることで果たして行きたいと思う。FFアギトの開発を抜けてまで作り始めたGDH2030というゲームを来年は必ずリリースさせる。

今後の課題

プロジェクトの失敗は抜きにして自分のゲームの作り方や仕事の進め方は間違っていたか?と聞かれれば、それは良いところも悪いところもあったとしか言いようがない。Unityでのプロトタイピングは確実に成果があったものの、プロトタイプから内容を膨らませていく段階において、効率の低下があったのは事実である。現在開発中のGDH2030においては適切なタイミングでリファクタリングを行うなど効率化を図って既に成果が出ている。その辺の話については今年のUniteで話をすることができた。

ゲーム開発の. 始め方、育て方、終わらせ方. 「Game Dev Heroes」. における生産性チャレンジ

スライドはこちら

Unityによる開発の効率化はまだまだ改善の余地がある。せっかくUnityを使っているのにFFアギト以上に非効率な開発になってしまうこともある。これからの自分の仕事を通してUnityやその他ゲームエンジンの上手い使い方を伝えていけたら良いと思う。全てはもっと面白いゲームを作るために。

C言語のポインタとギターのFコード

「プログラミングをやろうと思ったけどC言語のポインタで躓いた」なんてのはよく聞く話だが、似たような話として「ギター始めたけどFコードが抑えられなくて挫折した」というのがある。ギターやったことない人のために説明すると、ギターというのは6本の弦でコード(和音)を作るのが基本的な奏法で初心者が買うギターの教則本では大抵いくつかのコードを覚えて有名な歌の伴奏をしてみる事を教えている。そしてFコードというのは、人差し指を寝かせて6本の弦を全て押さえることが必要なのだが、初心者の場合握力が弱かったり指を棒のように伸ばす事に神経が慣れていなかったりで、まずちゃんと抑えられない。やってもやっても抑えられない。そしてFコードが押さえられないと次の段階に進んではいけないと思い込み、ギターの練習そのものに飽きてしまう。

しかし、「ギター弾きたい」と思う人が本当に弾きたいロックやポップスの曲では、まずその人差し指で6弦全て抑えるFコードを弾く場面なんてものは出てこない。もちろんF(ファ)を基音とする和音はいくらでも出てくるのだが、大抵省略形になっていたりして、少なくとも教則本に載っているような形で6弦全てを1フレット目で押さえる場面は少ない。僕は中学1年生の時にギターを始めて、同じように初心者向けの教則本から始めたのだが、6弦全て使う形のコードを押さえて好きでもないJ-POPsの課題曲をやることにすぐに飽きて来た。ある日大好きなバンドKISSのアルバム「LOVE GUN」の楽譜を楽器屋で見つけたので買って見たらそこに載ってるのは教則本に載ってるコードより押さえるのがずっと簡単な省略形の「パワーコード」ばかりであった。すぐに好きな曲に挑戦してみたら自分でも弾けることに興奮した。その体験のおかげで20年以上ギターを続けている。

プログラミングの話に移ると、僕がUnityとC#を使って一人でもゲームを作れるようになる過程において、Unityの教則本もC#の教則本も見なかった。ただ、「FPSが作りたい」という思いがあったためUnityに付属のTPSのデモの中身を見たりして、真似してみる所から始まった。ギターのFコードで挫折する人とC言語のポインタで挫折する人に共通するのは「弾きたい曲」や「作りたい物」がないことだと思う。このバンドのこの曲を弾いてみたいというのがなしに「ギター弾ける俺」を目指したって、ゲーム作りたいわけでもなく「今の時代文系でもプログラミングくらいできなきゃ」とか思ったって、そこには自分の人生を豊かにするような体験は待っていないだろう。

何故こんな話をしたかというと、直接のきっかけは「プログラミング初心者が躓く点」のような話を目にしたことだが、この手の話は前から社会の闇として気になっているのである。特にやりたいことや好きなこともなしにただ人から評価されることやかっこいい自分を目指して挫折する、いや正確には挫折感もなしにただ無かったことにする人は多い。まあそれだけなら害はない。10代の時に楽器を触って3日坊主なんてことは誰にでもある話だ。しかし、20代、30代でプログラミングの本を買っては積んだり、開発環境をインストールするだけで終わったりすることを繰り返して自己承認欲求をどんどんこじらせていく人たちがいる。何をした方が良い、何をするべき、そういう話ばかり聞かされて来た人たちが特に興味もないことをかじって時間や金を無駄にする。そしてしまいには「趣味がない」とか「友達がいない」とか「仕事に未来がない」とか言い出す。音楽が好きだから楽しみたいとかなくて「twitterで音楽の話をできる人はかっこよくて羨ましい」とか言い出す。「なんでも良いからプロフェッショナル仕事の流儀や情熱大陸に出られる人になりたい。」とか言う人はマジに存在する。イケてる自分になるためのスキルアップとライフハック、それを煽る空気がある。なんか呆れてくるしムカついてくる。わかるかなこれ。

10年間デジタルゲームの仕事を続けて分かってきたこと

僕の誕生日は7月2日で、スクウェア・エニックスで働き始めたのが2005年の7月1日。今1人でやってる株式会社degGの創立日が2010年6月30日。それぞれのタイミングがほぼ重なっていて、1歳年齡を重ねるとキャリアが1年積み重なって会社も1年続いた事になるから、誕生日に自分のそれまでのキャリアや1年間の実績を振り返るのが習慣となっている。ちょうど今年で年齡が35歳となりゲームの仕事をして10年という大きな区切りになるので、10年続けて分かってきた事をシェアしようと思う。

プランナーはやばい

僕はゲームデザイナーになりたくてスクウェア・エニックスでゲームデザイナーにあたるプランナーという肩書きでキャリアをスタートさせたが、プランナーというのは色々とやばい。具体的にどうやばいかを話すとCEDECのセッション1回分になってしまうので、ここでは割愛。

【CEDEC 2014】雑用ばかりの「プランナー」から脱するには? 「ゲームの面白さ作り」に特化する専門職業としての「ゲームデザイナー」の話

CEDECに出るのは当たり前の事

CEDECと言えば今年もCEDECでセッションを持つ。

絶対に夢を叶える!〜オリジナルゲーム開発への挑戦〜

発表者としてCEDECに参加するのはこれで5回目となる。よくこの事について「凄いですね」と言われるのだが、ゲームデザイナーは作ったゲームが全てなのでそれ以外の事で凄いですねとか言われても反応に困る。よく勘違いされているのだが、ゲームデザイナーとして認められているからCEDECでセッションを持てる訳ではない。CEDECの公募の審査は応募者の名前を伏せてそのセッションの内容だけで判断される。また、ここまで大規模でセッション枠が多いカンファレンスだと競争倍率が低いのでとりあえず誰でも公募に出せば通る可能性は高い。僕は「スピーカーになればパスが無料で手に入る」って理由でセッション案を公募に出している。CEDECのセッションは「講演」とは違う。日本社会における講演という言葉の意味は「成功者がためになる話をする」であり、CEDECもそういうものだと勘違いしている人が多い。CEDECに権威のイメージを感じとりセッション内容やスピーカーに対して過度に反発する人も見受けられる。しかしCEDECはカンファレンスであって、カンファレンスというのは情報共有の場である。それ以上でもそれ以下でもないので大げさに捉えず気軽にセッション案を公募に出した方が良い。CEDEC行っただけで何か成長した気分になるのも、セッション内容の揚げ足とるのも同様に時間の無駄である。

プラットフォームが変わっても仕事は変わらない

僕は最近仕事としてスマートフォン用のゲームを作りながら自分のお金と時間を使ってPC/MAC用のゲームを作っている。どちらもUnityで作っているし、まず面白いゲームを作る事を最優先している。仕事の質としては何も変わらない。ネットを見るとコンソール用ハイエンドゲームを作ってる人とスマフォ用ゲームを作ってる人で二分対比して前者を応援するつもりで後者を叩く人をよく見かける。けど人材の流動性から言って両者の区別ってさほどない。それにスマフォ用ゲームも既に「ハイエンド」の域に達してるし、「スマフォ用ゲームばっか作ってるとコンソールのゲーム作れなくなる」ってのも実感としてない。ゲームはゲームだ。

議論はあまり必要ない

議論してる暇あったらとにかくゲームを出して一般の消費者に評価を問う方が明らかに得る物が大きい。失敗のリスクを減らすために議論しようという意見もあると思うが、ゲーム会社でも個人でも最大のリスクは成果を出せないまま時間を過ごす事だと思う。

読書量とかどんだけ映画観たとかあまり関係ない

この業界では物凄い読書家や映画マニアと出会う事がある。ではそういう人が凄いストーリー書いてるかと言ったら必ずしもそうじゃないし、逆に読書も特にしないし、映画も人並みにしか観ないけど良い仕事する人はたくさんいる。なので僕は読書にしろ映画にしろ「数ある趣味の一つ」という評価しかしない。もちろん夢中になれる趣味を1つ持っている事それ自体は素晴らしいと思うけど。

コミュニケーション能力は必須

勘違いしてる人多いけどコミュニケーション能力って大学生とかが言う「コミュ力(ステレオタイプなリア充として立ち回るうまさ)」の事ではない。仕事で必要なのは自分の仕事の進捗や直面している問題や作業指示に対する疑問点、あるいは自分で思いついたもっと良いアイディアを自分の言葉で速く正確に伝える能力の事であって別に飲み会の幹事なんかやってくれなくて良い。そしてゲーム開発の仕事ではそれは全職種に要求される。繰り返す。全職種に要求する僕は。前述したステレオタイプなリア充(ネットスラングでは「ウェーイ」とか呼ぶのかな?)への嫌悪感からか「職人や技術者は寡黙であるべき」とか「言葉で仕事をしてはならない」とか思い込んでる人が多いけど、ディレクターの視点では勝手に一人で仕事抱え込んで自分からは何も話そうとしないプログラマーやCGアーティストの存在はプロジェクト進行上のリスクとみなす。メールで進捗確認すると自分で納得行く成果物が出来上がるまで返信してくれない人とかいるけど、そういう時って本人が思ってる以上に発注側はストレスを感じている。中途半端な物見せてはならないとかそういう精神論はいらない。「コミュニケーションが苦手な人でもプログラミングや絵のスキルが高ければ認めて欲しい。そもそも両立する能力じゃない。」って意見もあると思うが、僕が知ってる限り本当に凄いプログラマーやアーティストはコミュニケーションもしやすいんだよなこれが。

プログラミングと英語は誰でもやった方が良い

プログラマーじゃなくてもUnityのC#を使って簡単なデモを動かせるくらいになると自分のアイディアを仕事と実現しやすくなる。アーティストの場合はMELで仕事を効率化する事ができるし、Unityでエフェクトを作る場合は、プログラムも書けると表現の幅が広がる。また、英語が書けなくても読めた方がマニュアルの日本語化を待つ事なく最新のツールに触れる事ができる。もちろん海外のゲームをいち早くプレイできる。Gamastraに載ってるようなゲームデザイン関連の小論文も読むことが出来る。英語が読めると確かに知識がつく。もちろん読むだけでなく書くこともできればリモートで海外と仕事をする事もできる。

収入は上げられる

ゲームの仕事は低収入と思われてる。実際僕もスクエニ時代は死ぬほど給料少なかったが、結局の所この10年で年収は3.5倍以上になった。経営者からすれば「この人を1ヶ月働かせれば確実にこれだけの成果がある」というのが分かっていてなおかつ「この人に辞められたら困る」と思えればお金を出すことができる。僕は今オリジナルゲーム「Game Dev Heroes」の開発において人にお金を払って仕事をしてもらう立場でもあるが、パートタイムで開発に参加してもらっているある優秀な学生プログラマーには時給換算で明らかにゲーム会社の平均値を上回る報酬を支払っている。それは仕事したもらった分の成果が明らかなのと、ゲームが完成するまでいて欲しいからである。

ゲーム産業におけるブラック企業/ホワイト企業の判断基準

ゲームは複雑高度な知識集約産業であり開発スタッフそれぞれのキャリアパスはその知識やスキルに大きく依存する。そのため、開発スタッフが専門家として成長できる環境こそがホワイト環境と言える。そして開発スタッフの成長は実務や成果物の評価を伴う研修においてしかなし得ないし、一緒に仕事をするスタッフのレベルにも左右される。そこを勘違いして熟練スタッフの中途採用に力を入れずにただ本棚に最新の書籍を揃えるだけで「学習できる環境です」と言ってる会社さんは気をつけた方が良い。「自主性に任せる」という言葉もそうだが、それぞれが作った成果物の内容についての評価をおざなりにしてホワイト企業を気取るのは、知識集約産業においては形を変えたブラック企業と言える。これからゲーム産業で働きたい人はステレオタイプなブラック/ホワイトのイメージにとらわれる事なく吟味した方が良い。

行動が全て

色んな人と会って来た。時には「創りたい物がある!」と熱く語り合って意気投合したつもりになった事もあった。しかし、多くの人はその後何もしない。僕もかつてはそうだったが、とにかく語ってる暇あったら成果を出した方が良い。ゲームってのはプログラミングかCGのどちらかができれば成果が出しやすい。どっちもできなかったらとにかく学習すれば良い。本もネット上の資料もたくさんある。勉強会とかその後の懇親会とか行って何かした気になる前に、家で集中して勉強したほうが良い。

10年間でインパクトがあった事その1

GREE/Mobageブームとその後に続くスマフォゲーム市場の好景気。既存のゲーム業界の外から一気にお金が流れて来てゲーム業界としても顧客層を一気に拡大したのは大きい。最初のうちはDeNAとグリーのお金の儲け方に反発する空気があったけど、今となってはDeNAとグリーが作った市場を既存のゲーム会社が食ってしまう形となった。このおかげで既存のゲーム業界の平均収入も上がったはずだと思う。僕自身もこれによってオリジナルのゲームを開発する資金を得る事ができた。

10年間でインパクトがあった事その2

Unity3Dの登場とそれに伴うゲーム開発の民主化。僕はバージョン2の頃から触れているが、豊富なAPIとWYSIWYPなエディターによりゲームデザイナーが自分のアイディアをすぐにゲームにできるようになった。また、同じツールとプログラミング言語を使う人たちの開かれたコミュニティが出来上がった事により、学習効率が明らかに上がった。もちろん市場のニーズに応えるようなゲームを作ろうと思ったら何もかも1人で作るというのは無理な話だが、最初に自分でゲームメカニクスを実装する所に限って言えばもうこれで作れないゲームはないと感じる。

10年間でインパクトがあった事その3

twitterで自分が作ったゲームのユーザーと交流できるようになった事。僕の場合は会社員じゃないので自由に発言できるからというのもあるが、自分が作ったゲームのユーザーがそのゲームを辞めた後も声をかけてくれるのは嬉しい。それは、ゲームの向こう側に作り手の人格を認めてくれた事の証拠であり、これがあるからゲームの仕事を続けて行ける。

これから楽しみなこと

Game Dev Heroesが完成したら次はVRのゲームを作りたいと思っている。次の10年間でゲームのプラットフォームや人々のゲームへの接し方がどう変わるかは分からないが、絶対に変わる事だけは確かだと思う。どうなろうがゲームはゲームだと仕事を続けて行きたい。

書評:ゲームデザイナーのための空間設計 歴史的建造物から学ぶレベルデザイン

Level Design

この度、出版社のボーンデジタルさんより新刊のゲームのレベルデザインの専門書「ゲームデザイナーのための空間設計 歴史的建造物から学ぶレベルデザイン」を店頭発売より一足先に頂いてレビューする事となった。以前からTwitter等でレベルデザインの話をしていた事に先方が関心を持って頂いていたという経緯である。私も最近は元来の意味でのレベルデザインが必要な世界体験型のゲームを作っていない事もあり、この機会にこの本でもう一度学び直そうと考えた。ボーンデジタルさんによると本書で学べる事は、

・現代のレベルデザインの慣習、手法、ツールに関するケーススタディ
・歴史的建造物の考察から優れたレベルデザインについて学ぶ
・空間を使用してプレイヤーの感情を導いたり、引き出したりする方法
・現実世界に影響を与える目的で作られた空間デザインの考察
・ストーリーの伝達、アクションの促進、交流を推進する空間作成

であるらしい。

なお、本書の内容についてのレビューの前に一つ言及したいことがある。日本においてはレベルデザインという言葉が「難易度調整」や「オンラインゲームにおけるコンテンツ消費速度の調整」という意味で使われることが多い。しかしそれは明らかな誤訳であり、本来の言葉の意味とはかけ離れている。レベルデザインのレベルとは、難度やプレイヤーの成長を示す数値のことではなく区切られたゲームプレイの一単位を示す。ゲームプレイの単位をマップで区切るゲームでは、マップの空間設計をしてゲームプレイの内容を形作ることをレベルデザインと呼ぶ。その目的はプレイヤーにエモーショナルな体験を提供する事であり、体験の種類に対する適切な空間設計を現実の建築から学ぶことが本書の目的である。よって、「難易度調整」や「オンラインゲームにおけるコンテンツ消費速度の調整」に関する話はほとんで出てこないので、そういったトピックを求めている人は注意が必要である。もっとも、そのように言葉の意味を誤解している人にとっても本書で正しい意味のレベルデザインを知るのは大変価値があると言える。

多角的な視点からの深い考察

実際に本の中を見ると以下のような章立ての構成だが、レベルデザインという一ジャンルに対してこれだけ多様で多角的な視点からその原理原則について論じている。
  • Chapter1 建造物からレベルデザインを学ぶ準備

建築の歴史を振り返り、古くから建築は訪問者に何かを体験させるという観点から設計されていた事、それはゲームデザインやレベルデザインの本質に繋がるという話。建築の三大要素である「強」「用」「美」をそれぞれゲームレベルの「機能要件」「ユーザビリティ」「喜び」に置き換え、同時に「建物を理解するための10の方法」を「レベルデザインの10の方法」に置き換える視点を提供する。

  • Chapter2 レベルデザインのツールとテクニック

レベルデザインの具体的な作業内容やワークフローについての説明。UnityやUnrealやHammerといったエディター統合型ゲームエンジンについてはもちろん触れているが、興味深いのはアナログのツールについての話である。また、日本のゲーム開発の現場ではあまり見ないCADツールについての説明もある。ここで重視してるのは、ツールの使い方それ自体ではなくてそれぞれのツールにメリットとデメリットがあり、最終的なゲームの要求スペックやレベルデザインの発想の方法によって適したツールが変わることである。例えばUnityのスケール1が1mをあらわす事と頂点スナップの機能によって、方眼紙によってスケッチしたレベルを正確にプロトタイピング出来ると述べている。

  • Chapter3 基本的な空間配置とゲーム空間の種類

2D/3D問わずあらゆるゲームジャンルのレベルデザインにおける効果的な空間設計の例を紹介している。空間設計のルールは一定ではなく、ジャンルによってあるいはユーザーに提供したい体験の種類によって適した設計は異なる。また、カメラの仕様を考慮した適切な設計についても言及されている。もし、レベルデザインの初心者で今すぐ知識が必要な人はこの章から読み始めたらいいかもしれない。

  • Chapter4 ビジュアル要素によるチュートリアル

GUIによるガイドを使わずに地形や空間の特徴やランドマークによってプレイヤーの行動をアフォードする事について書かれている。GUIを一切使わないのはレベルデザイナーの究極の目標と言っても良い。私の考えでは、ここで紹介されている環境にシンボルを取り入れる例については単にGUIによるガイドがゲーム内のオブジェクトになっただけと言えなくもないが、それでもプレイヤーはGUIで表示されるガイドよりは100倍もゲーム世界に没入できるというのは分かる。また、カットシーン(スクリプトシーケンス)によるゲームプレイのデモンストレーションについても紹介されているが、これはいかにもゲームという表現方法で私自身は好きではない。しかしここで重要なのはそのようなやりつくされた方法について全て網羅して、その意図を解説している事である。そしてそれは読者にとって新たな発想のヒントとなる。例えば、構成主義によるティーチングというメソッドが紹介されている。それは「プレイ結果の観察と省察、戦略の作成、新しい戦略のテスト、障害の克服」という4つの要素を順にイタレーションするプレイヤーの学習モデルの事だが、一見すると以前私がCEDECでのポスター発表で紹介した「Operation(観察), Plan(計画), and Action(実行)の原則」と呼んでいたものと全く同じ話をしているように見える。しかし、本書に書かれているのはプレイヤーの失敗とリトライを前提とした話で、私がOPAの原則と呼んでいるものはプレイヤーに失敗させないレベルデザインの理論である。そのような違いを認識するだけでもこの章は読む価値がある。(全体的にこの章は失敗とリトライによる学習の価値を評価する向きにあり、それが嫌いなプレイヤーが一定数いる事も念頭に置いて読まなければならない。)

  • Chapter5 生存本能を利用したレベルデザイン

リスクのデザイン、危険性の表現について。現実の建築が危険から安全に人を誘導するのに対して、時にゲームレベルはプレイヤーを意図的に危険へと誘う。この章では眺望空間(危険地帯)と避難空間(安全地帯)からなる設計に対して眺望空間を越えた先にある2次避難空間を作ってプレイヤーを誘導する手法などが紹介される。また、眺望空間と避難空間の関係性についてはル・コルビジェやフランク・ロイド・ライトの建築を例に掘り下げて説明している。なお、この章は過去にGamasutraに寄稿したこの記事が元になっているらしい。 Designing Better Levels Through Human Survival Instincts

  • Chapter6 報酬の空間でプレイヤーを誘い込む

報酬によってプレイヤーを誘導する理論と、建築の知識によって報酬を見え隠れさせる手法についての説明。ここではレベルデザインにおける報酬の目的を以下の3つに定義している。

1.ゲーム内の行動を奨励する
2.探索に誘い出す
3.好奇心をかき立てる

1,2は例えばRPGのダンジョンにおいて、ゴールとは関係ない所に宝箱を置いて、結局はプレイヤーにダンジョンをくまなく探索させるような設計である。これについて私の考えを言うなら、報酬を提示してプレイヤーに回り道やリスクある行動をさせる設計には「やらされてる感」というリスクが伴うので、レベルデザインにおける報酬はまず好奇心をかき立てる事から発想しないとならない。好奇心によって突き動かされた体験それ自体を報酬とする事で、レベルデザインをナラティブデザインへと近づけるのが私自身が課題として考えている事である。本書でもその場の景色それ自体や物語に関する情報を報酬とする方法を紹介し、次章のストーリーテリングに話を繋げている事から、ナラティブデザインとレベルデザインが同義になるゲームの未来を見据えていると言える。

  • Chapter7 ゲーム空間におけるストーリーテリング

最も重要な章かもしれない。特に言葉の誤訳からレベルデザインという仕事が認知されていない日本においては、この領域はシナリオライターの仕事と環境アーティストの仕事に分断されてしまっている現実がある。ゲーム空間は、プレイヤーが物語を体験すること、その物語の理解を助ける情報を提供すること、それとプレイヤーが自分自身の物語を作るためにある。本書では歴史的建造物や歴史的事件の記念館がそのデザインによって物語を伝えた例を紹介し、また、オンラインゲームの世界においてプレイヤーの間で語り継がれる物語が生まれた事例も紹介する。ゾンビゲームでよく見られる、小物アセットを散乱させる事で過去にその場で悲惨なできごとがあったと表現する例や、Portalにおける隠し部屋等のイースターエッグの例はやり方としてすぐに真似できる物だが、具体的な手法そのものより大事なのは、この章で紹介される英雄物語の構造や、ドラマティックアークの構造等を知り、空間デザインやゲームプレイの進行の設計において常に意識する事に思える。

  • Chapter8 インタラクティブ空間とワールドデザイン

実は最も理解に苦しんだ章である。この章のレビューをどう書けば良いか悩んだのでこの記事の公開が遅れた。ここでは、英語圏のゲームデザイン関連書籍を見ると必ずと言って良いほど目にする「創発性(emergent)」という概念について触れている。これは、ゲームプレイ中のある特殊な条件が揃った時に、ゲームデザイナーにとって想定外のゲームプレイが生まれる事を指す。例えばMMORPGのプレイヤーなら、本来タンク(盾)としてデザインされていないクラス(職種)が特定の装備品や消費アイテムやスキルを掛け合わせてタンクの役割を担う光景等は目にしたことがあるはずだ。また、私の作ったゲームだとBFBというサッカーシミュレーションゲームで、センターバックをポストプレイヤーとしてワントップに置いたり、クロスの得意なサイドバックの選手をウィングに起用するプレイヤーがいたのも創発の例と言える。そのようなゲームプレイの創発の重要性は私も以前から意識していた事であるが、本書では創発されるプレイヤー自身の物語とデザイナーの意図した物語が相反するリスクについて言及したうえで、創発性を取り入れるデザインとして「可能性空間」という概念を提示している。マリオやゼルダのレベルデザインの例を挙げ、可能性空間とはマップの概観を見せる事でプレイヤーがその場で取り得る行動の可能性を複数提示し、プレイヤーの選択に対する意識や順番に行動の可能性限界を越えていく事の達成感を高める事を目的とする物としている。それ自体はよく分かるし、宮本茂氏がヒントを得ていたという日本庭園の構造についての説明は大変興味深い内容であるのだが、私には創発性とは無関係のトピックに思えた。というのも、環境とプレイヤーのインタラクションという観念だけでは創発性は生み出せない。何故なら環境の与えた情報から想像されるゲームプレイを超越する事こそがプレイヤーにとってもデザイナーにとっても驚きであるからだ。そのためには場所や特定の環境に縛られないゲーム要素の存在が必要不可欠であり、多くの場合それはアイテムやスキル(魔法)や乗り物等、場所の制限を受けずに移動可能、携帯可能な物として提供される。本書で創発性の例として挙げられているFPSの「ロケランジャンプ」にしても、ロケットランチャーというアイテムの仕様が環境を無視する例である。この章では、先に創発性を提示したのにその後環境に縛られた行動選択肢の提示という方法を紹介してしまっているので、創発性について大きな誤解を生むリスクがある。それを除けば可能性空間という考え方それ自体はレベルデザインの原理原則として価値あるものなので、創発性については一旦脇に置いて読むのが良いだろう。

  • Chapter9 プレイヤーの交流を生み出すレベルデザイン

ここでも創発という言葉が使われているが、やはり本題とはあまり関係ない。というより筆者は常にゲームデザイン用語としての創発ではなくて一般名詞として創発という言葉を用いているのかもしれない。あるいは翻訳の段階で複数の異なる言葉が同じ創発という語に訳されてしまっているのかもしれない。さて、この章は現実の都市計画からオンラインゲームにおけるプレイヤー同士の交流機会の設計を学ぶ内容となっている。都市を機能別のディストリクトに分けた結果住人同士の交流がなくなったモダニズムへの反省から、機能の混用というコンセプトを提唱したニューアーバニズムという流れを紹介し、そのニューアーバニストの原理原則から設計されたゲーム内都市の例としてWorld Of WarcraftのStromwindを挙げている。余談だが、ここで例に挙げられているStormwindの正門周辺の地区についてだが、私がWorld Of Warcraftで初めて訪れた時にはどちらかというと前章の「可能性空間」としてのデザインのクオリティに感嘆してしまった記憶がある。正門から足を踏み入れると各商店の看板がUI的に画面に整然と並ぶ概観が意図的にデザインされていて、明らかにレベルデザイナーにアフォーダンスデザインの素養が備わってる事が分かった。話を本題に戻すと、この章ではそのような緻密に設計された大都市の他に、ゲーム世界の各地に点在する小集落といった、クエストハブの重要性も指摘する。それは、文字通りクエストの発給場所であるが、そこに熟練プレイヤーも繰り返し実行できるようなクエストを置くと初心者プレイヤーとの交流機会になると書かれている。私自身も過去にMMORPGの開発に携わったが、そのような世界設計については「とりあえず広大な世界を作ってユーザーを放り込めばあとはユーザー同士が勝手に楽しんでくれる」という考えの人が多く、このように空間から交流をデザインするという考えはあまり見られなかった。創発という言葉に捉われなければこの章の内容も多くの知見に満ちていると言える。

  • Chapter10 サウンドによるレベルデザインの強化

ゲームデザインもレベルデザインもやりながら音楽を作る私にとっては最も興味深い章。マップの特定箇所に音楽再生のトリガーを仕込むとかいう単純な話ではなく、空間設計自体に音楽的なリズムを取り入れる手法を紹介している。ゲームプレイの短期的目標と長期的目標がポリリズムを成すという観点は興味深い。思い返すとファイナルファンタジーというゲームは5か6のあたりから序盤においてボス戦やダンジョンの攻略という短期的目標で躓く事が減ったのでそのリズムが崩れる事がなく、ストーリーという長期的目標に対してテンポよく向かっていくのが熱中の理由だったと思う。その他もちろん、ゲームにおける効果的なBGMの事例等も紹介されている。また、プレイヤーの行動によって変化するインタラクティブなサウンドデザインについても触れている。ちなみにこの章で度々名前が上がるのが「スキタイのムスメ」なのだが、あのゲームのサウンドが業界最高レベルにある点については異論はない。

  • Chapter11 現実世界を舞台にしたレベルデザイン
ゲームのレベルデザインを現実の都市設計に応用する話かと思ったら、いわゆるARG等の現実世界を舞台にしたゲームのレベルデザインの話だった。興味深いのはドラクエIXのすれ違い通信への言及がある点である。すれ違い通信を使ったゲームには「公と私のゲームプレイ」の行き来があるとしている。また、この章では「適応型ゲーム再利用(Adaptive Game Reuse)」という概念が紹介される。現実世界の空間をゲームメカニクスによって新たない意味や価値を付加して再利用することである。例えばIngressのポータル等がそうだろう。現実世界のレベルデザインの目的として、プレイヤーを公共空間に呼び出す事、社会的な行動を促す事等が挙げられている。まだ始まったばかりのジャンルで先行研究や参考事例が少ないため、そこまで深い考察はないのだが、最終章が扱う内容がこれである事に、未来に向けて原理原則を語り継ぐ意思を感じた。

筆者の膨大な知識に支えられた良書。全ゲームデザイナー必読。

本書を見てまず驚いたのが大量のゲームに対する言及であった。帯には、「名作ゲーム136点」と書かれているが、MGSやHALO等誰でも知ってるゲームからスキタイのムスメといった最近注目のインディー/アート系作品まで幅広く網羅されている。また、英語圏の本なので北米のゲームについての言及が多いのかと思いきや、日本のゲームやゲーム開発者への言及が多い。とにかく筆者のトッテン氏は古今東西様々なゲームに触れており、その知識量はゲーム博士としか言いようがない。大学のゲームデザイン学科の助教授だから当たり前と思うかもしれないが、では、日本のゲーム研究者やゲーム開発関連学科の教員に同等の知識量を持つ人がいるかと言うとすぐに思いつかない。

人々のゲームリテラシーは時代とともに向上し、この本で紹介されている初歩的なレベルデザインのテクニックは、逆にユーザーからすると「お約束感」や「やらされてる感」を感じさせるリスクがある。例えば枝分かれした道を見つけたらそのどちらにも報酬が用意されているのは明らかである。そしてそれを見逃すのは損なので結局は、片方の道を進んで引き返してもう一方の道へ進む事となり、そこには選択や決断の意識等存在しない。そういう意味でこの本はずぶの素人を一流のレベルデザイナーにしてくれる本ではなく、読者自身にも内容をよく吟味し検証するだけの開発経験や、ゲームリテラシーが求められる。ただし、本書の目的はここの方法論それ自体の紹介ではなく、ゲームジャンルを越えた原理原則である。レベルデザインの目的は環境によるアフォーダンスであり、建築やインテリアデザインの分野では既にアフォーダンスについての先行研究が積み重なっている。本書の内容それ自体が確かな知識ではあるのだが、それだけではゲームデザイナーやレベルデザイナーが追求すべき学問としては入り口に過ぎず、各章の末尾に載る膨大な参考文献にあたる事まで含めた知的体験を提供してると言える。ともかく日本語でこのような本を読めるだけでも貴重な知的体験と言えるのでまずは手に取ることをおすすめする。