読者です 読者をやめる 読者になる 読者になる

Beginning 3D Game Development With Unity: The World's Most Widely Used Multi-platform Game Engine

Beginning 3D Game Development With Unity: The World's Most Widely Used Multi-platform Game Engine

この本の筆者の経歴

Sue Blackman has been an instructor in the 3D field for nearly 20 years at art schools and community colleges. She has been involved with the commercial development of real-time 3D engines for more than 10 years. In the past, she has been a contributing author for New Riders Press (Max4 Magic) and written for AMC Siggraph on serious games. She has written product training materials and instruction manuals for developing content with real-time 3D applications, used by multimedia departments in Fortune 1000 companies including Boeing, Raytheon, and Lockheed Martin, among others. In addition to writing and teaching, Sue has been the lead 3D artist on several games for Activision and its subsidiaries.

専門学校の先生。
Unity本については以前のエントリーでも扱いました。
ページ数が900ページを超えているということで、内容はたしかにもりだくさんと
いっていいと思いますが。Unity - book-loverの日記
CGやゲーム数学など、ほかの分野での有益な文献のガイダンスがついているし、簡潔に
まとまっているという点では、以前の本のほうがよくできているかもしれない。
(本書では最後に登場するデザイン関連のドキュメントが、Michelle本では最初に
登場する。つまりゲームを制作・開発する流れに沿っている。)
現在、Sampleを確認していますが、こちらはトラブルが多い。
「あれ、宝箱をあけたら、ここでエリクサーが入手できるはずでは?」
「あれ、もう宝箱にカギを挿入したから、開くのではないの?」
とか、いろいろとトラブルが多いです。
そのかわり、いろいろなオブジェクトのアニメーションはこちらのほうがふんだんに
もりこまれています。
それと、できあがった「ゲーム」の「完成度」はこちらのほうがいいかな。
ゲームの「始まり」と「終わり」がはっきりしています。
ステージにある宝箱を入手するところから始まり、
「伝説の果物」を手に入れるところで終わり。
そのあいまに、いろいろな謎解きをしていかないといけない。
「脱出ゲーム」に近いような気がします。
それと、メニュー画面のようなインターフェースの整備はこちらに分があるかな。
Michell本のほうが、動く敵キャラのロボットうさぎの実装の仕方とか載っていて、
読んでいても楽しかったな。
ライフゲージの設定もあったし。
Blackman本のほうは、3DCGなどを、やっている人むけ。
だから、CG関連の用語などが、あまり丁寧な説明もなく、「知っているもの」として
出てくる。
いままで、ゲームの開発に直接タッチしたことのない人たちが、「越境」するのを
助けるという意図があるようだ。
本当に、Unityで開発コストが下がるということが実現できるのだろうかなと。
ステージをつくるにしても、キャラクターのアニメーションをつくっていくのも、
Unityがいくら便利になっても消える作業ではない。
プログラミングそのものは楽になったかもしれないけど、プログラミングとは直接関係
しないところでのコストはあまり変化しないかもしれない。
どういったらいいのか。
今時の豪華なゲームというものを完成にまでもっていこうと思ったら、
プログラマーの仕事というのはあくまで膨大な作業の一部でしかないという
ことが明るみにでたのではないかなと。
その一部が、簡略になりましたよと。たしかに、こういったエンジンがないと、
プログラマの人はもっといろいろなことを勉強しないといけないのだろうけど。
ゲームエンジンは、その性質上、プログラマーの人から取り上げられることが多い。
だから、開発作業の変化ということも、プログラマーの視点からだけ論じられている。
そういう点では、このBlackmanの本は貴重なのかも。
記述が、あっちこっちにいって、もうしわけないけど。
本書もStepByStep方式です。
「理論」的には、「その通り」にボタンをクリックしていったらできると。
それと、JavaScriptのプログラミングも必要です。


このゲームが大ヒットを記録したそうです。
今ではもうありえないことだろうけど。いや
でも、iPhoneでヒットしているのがAngryBirdsである
ことを考えると、今も、昔もあまり変わらないのかも
しれない。携帯電話のゲームは、あまり豪華なつくりには
できないから。

この本の筆者が「授業」をしているかもしれない学校の
映像資料。こういうところで勉強するのですね。
Activisionという会社の歴史

Before the formation of Activision, software for video game consoles were published exclusively by makers of the systems for which the games were designed. For example, Atari was the only publisher of games for the Atari 2600. This was particularly galling to the developers of the games, as they received no financial rewards for games that sold well, and did not receive credit for their games. This caused several programmers to resign from their jobs. Activision became the first third-party game publisher for game consoles.[12]
The company was founded by former music industry executive Jim Levy, venture capitalist Richard Muchmore, and former Atari programmers David Crane, Larry Kaplan, Alan Miller and Bob Whitehead. Atari's company policy at the time was not to credit game creators for their individual contributions; Levy took the approach of crediting and promoting game creators along with the games themselves. The steps taken for this included devoting a page to the developer in their instruction manuals[13][14][15] and challenging players to send in a high score (usually as a photograph, but sometimes as a letter) in order to receive an embroidered patch.[16][17][18][19] These approaches helped the newly formed company attract experienced talent. Crane, Kaplan, Levy, Miller, and Whitehead received the Game Developers Choice "First Penguin" award in 2003, in recognition of this step.

まだ、テレビゲームというものが、世に出たばかりの時、プログラマーの社会的地位
というものがあまり認められていなかったということが伺える。
たしか、ElectronicArtsという会社のことを調べていたときも似たような記述が
出てきていたなと思う。
ゲームというものが世に出るとき、「誰がプログラミングをしても同じ物ができる」
という、よくよく考えると、あながちそう間違いではないことについて、本人たちである
プログラマーたちが反発して、反旗を翻したような経緯がある。
プログラマーはArtistなんだと。
今回の本を読んでいても、Artistという言葉随所に出てくる。そして、Creditという
ものに対する、常人にはちょっとうかがい知れないものへの強力なこだわりの
ようなものが見受けられる。

Alan Miller

Click Health
In 1997, Miller co-founded Click Health, a pioneering publisher of health education games for children with asthma and diabetes. The games were made available for Nintendo consoles and IBM PCs. Miller served as Chairman and CEO. Clinical trials of the company's games demonstrated significant effectiveness. In a clinical trial with pediatric diabetes patients at Stanford University Medical Center and Kaiser Permanente, children who played the company's diabetes game, Packy & Marlon, experienced a 77% reduction in urgent care visits over six months, compared to children in the control group who were given a standard video game to play. The company's anti-smoking games, Rex Ronan: Experimental Surgeon, is an interactive exhibit in the Health Oddysey Museum at the Centers for Disease Control headquarters in Atlanta, Georgia played by thousands of children each year as they tour the museum.
Unable to find significant interest in distribution of the effective games through health care providers, insurers, and government agencies, Click Health closed its doors in August 2001.

Bob Whitehead

There, with others, he developed a custom VCS development system, that integrated a debugger and required a minicomputer to run. It was used for most of Activision's VCS titles. He also developed a pioneering "venetian blinds" animation technique, an algorithim that horizontally reused and vertically interlaced sprites several times while rendering each frame, to give the illusion that the system had more than the maximum number of sprites allowed by the hardware.

前置きが長くなりましたが、本書のエッセンスの紹介になります。

Chapter1 Exploring The Genre
アドベンチャーゲームというジャンルの誕生から現在にいたるまでの「歴史」の概観。テキストベースのゲームから、3Dグラフィックを多用したシューティングゲームが登場するまでを読む。ゲームを構成する要素の抽出。ゲームをデザインする上での注意点の列挙。様々なゲームごとに備わる注意点。相違点や共通点なども書いてある。3Dグラフィックを織り込んだゲームを開発する上での注意点。コンピュータがゲーム内のステージを描画していくときの負担をすこしでも減らしていくために、どういう手法があるかの紹介もしてある。違う数のポリゴンで同じオブジェクトを用意する。3次元のオブジェクトを2次元で代用する。「霧」に隠れるオブジェクトの描画を省略するなどなど。

Chapter2 Unity Basics
Unityというソフトウェアでゲーム開発をするときの、概略がわかるようになっている。
ユーザーインターフェースの説明。操作感を体験するために、立方体をUnityで工作していく。
視点の操作、オブジェクトへの焦点の合わせ方、オブジェクトの移動、回転、縮小拡大の
操作の仕方も学習する。SceneView→アセットを編集したり、再配置をしたりする。
ProjectView→プロジェクトで使用可能なアセットのすべてが表示されている。
GameWindow→開発Sceneで、実際にGamePlayを試してみることができる。
Inspector→それぞれのAssetのパラメータ、コンポーネット、SceneやProjectの設定などを一覧して、操作することができる。
といったUnityのウィンドウのそれぞれの役割の解説もしている。3次元空間のオブジェクトの取り扱い方も扱う。メッシュにTextureをはりつけて、掲示板や、古代文明のピラミッドのようなものを作り上げていく。(Sampleはない。)

Chapter3 Scripting
JavaScriptというプログラミング言語を使用して、Unityで扱うオブジェクトを操作する基本を学ぶ。手始めに、前章であつかった立方体に「回転」「移動」という操作を加えるScriptを記述して
変数や、関数の考え方を理解する。まず「回転」の操作をするプログラミング。次に「回転」しながら「移動」させるプログラミングと進みます。「回転」のスピードが、ソフトウェアがインストールされている端末によってばらばらにならないために、「一定数のFrameRate」による回転から、「一定時間の間における「回転」に切り替える方法なども学びます。さらに、立方体をクリックするたびに、コンソール画面に「クリックされました」という表示がでるようにプログラミングをする。クリックされる立方体はそれ自体が、表示されている必要がないということを示すために、立方体の非表示の設定の仕方も学びます。さらに「State」「状態」「Conditional」「条件文」の基本的な使い方も書いてあります。

Chapter4 Creating Test Environment
Unityに内蔵されている「地形・形状」(Terrain)のEditorの使い方。平面の板に山脈をつくったり、湖や渓谷を造形する。RedRockのような上部が平面になっている地形の作り方も学ぶ。平面をへこませていったり、盛り上がらせていったりすることで、好みの地形を作り上げていくプロセスがわかります。作り上げたTerrainの全体を概観するためのNavigationの仕方も学びます。地面に生える樹木や草をTerrainに植え込むテクニック。そしてそれらが「風」になびくように描画させます。できあがったTerrain全体を覆うSkybox,つまり「空」の設定を操作する手順も学びます。ゲームプレイヤーが樹木を通過したりしないために、Colliderの設定もします。「自作」の「樹木」のようなAssetをUnityに取り込むための手順も書いてあります。最後に、できあがったTerrainで自然に影が生成しているようにするための様々な選択肢も学習します。

Chapter5 Navigation And Functionality
FirstPersonController Prefabを設定する。(ゲームの時の自機)Scriptを利用して、WASDキーを使用する操作設定を、独自に設定変更できるようにする。InputManagerの機能を利用します。
(ここでは、上下左右の矢印ボタンがWASDキーに取って代わるようにする。)FrameRateに基づく設定を、一定時間での更新に基づく設定に変更する。
MouseLook Script というScriptに変更を加える。Shiftキーや右マウスボタンを同時に押さないとLookの機能が発動しないようにして、プレー中、やたらに画面がぐらぐらするのを防ぐ。
「仮想」のボタンを設定する。プレイヤーの左右・奥手前の移動方向をその「仮想」的ボタンに割り振ることが可能。PCに実在するボタン以外への操作の割り振りができる。
操作の独自変更をより柔軟にするために、Javascript演算子を導入する。
プレイヤーの通り抜けができない壁の設定も学習する。
ゲームステージの空間を浮遊する「踏み板」(PlatForm)の導入。動く踏み板でプレイヤー
が移動する設定をする。「天井」を設定して、プレイヤーの移動範囲を制限する。
ステージ全体の周囲にもWallを設定することで、プレイヤーに「行き止まり」があるようにする。

Chapter6 Cursor Control
オペレーティングシステムのコードで出現するカーソルを非表示にする設定変更を行う。
具体的には、Navigatingという変数をもうけ、プレイヤーが何らかのボタンを押している
という入力を受け取ると、(つまり、移動中)カーソルが出ないというScriptを書く。
カーソルを、自分好みのテクスチャをつかったオリジナルなものに変更する。
オリジナルのカーソルは、非表示になっているOSのカーソルの位置情報を取得して、
その位置情報に、カーソルのスプライトが表示されるように、変数の設定を行う。
オブジェクトAにScriptA オブジェクトBにScriptB、オブジェクトCにScriptCという
関係だけでなく、オブジェクトAにもBにも、Cにも働きかけるScriptXを作り上げる。
カーソルに照準を当てられているかどうかで、オブジェクトの色が変化する仕掛けを
Scriptで作り出す。

Chapter7 ActionObjects
(このブログの筆者の「主観」も入る。この本は読者が3DCGを作り上げる修練をある程度積んでいることを前提にしている。ゲームエンジンというソフトウェアの真骨頂は「ずぶの素人」さんでもある程度の水準のゲーム開発ができるようになるということですが、この章に眼を通していると、やはりグラフィックに関連する分野横断の知識や経験は求められているなと思う。)
「宝箱」「岩」「花」というオブジェクトを登場させる。
「宝箱」には、蓋が開く。蓋が閉まる。というアニメーションを付加する。
「宝箱」にはさらに「鍵」のオブジェクトとの組み合わせで多彩なアニメーションを現出させる。
鍵を「宝箱」に差し込む。抜くといった動き。これを「宝箱」の「開け閉め」と結びつける。
「岩」のオブジェクトの扱い方には、「影」をうまいことつけるという演習が加わります。
「花」は、「咲く」「枯れる」「再び開花」といったアニメーションを付加する。
「音声」いわゆる「効果音」を組み込むやり方も学習できます。「宝箱」をあけるときに、
「がちゃん」という音がでるみたいな。
「宝箱」オブジェクトに「開いている」「閉まっている」というような「状態」の変数を設定
する。その「変数」の「値」によって、場面に応じた命令がScriptによってできるようにする。
アニメーションが付加されていないオブジェクトをUnityにインポートした後で、そのオブジェクトにアニメーションを付加する。すでにそろっているアニメーションのクリップをたしたり、引いたりするやり方も学習します。

Chapter8 Managing States
「宝箱」の「蓋」オブジェクト
0) 「施錠」されている。 「蓋」は閉じている。
1) 「鍵」は外れている。 「蓋」は閉じている。
2) 「鍵」は外れている。 「蓋」は開いている。
3通りの「状態」を用意する。

「鍵」のオブジェクト
0)プレイヤーの「カーソル・キー」の役割を果たす。
1)LockPlate(鍵穴の部分)に挿入されている状態。
2通りの「状態」を用意する。

「LockPlate」のオブジェクト
0)「鍵」が挿入されていない。
1)「鍵」が挿入されている。
2通りの「状態」を用意する。

3つのオブジェクトが、どういう状態になっているかという合計パターンは
3×2×2=12通り

たとえば 「宝箱」の「鍵」は外れている。 「LockPlate」に「鍵」は挿入されている。
「鍵」はLockPlateに入っている。

ほかには、「宝箱」の「蓋」は閉まっている。「鍵」は「施錠」されている。
「LockPlate」に「鍵」は挿入されていない。「鍵」のオブジェクトはカーソルの役割を
果たしている。

抽象的にまとめると、それぞれのオブジェクトにどういう「状態」があるのかを決めて、
その「状態」が、ほかのオブジェクトによって、どのように「切り替え」を起こすのか
という「約束事」をScriptとして書き上げるための考え方とCodingの手法を学習する。

Chapter9 Object Metadata
InteractorScriptを作り直します。あるオブジェクトに関連のある情報のすべて(MetaData)を保持することができるように。どのような「State」にあるObjectであれ、そのオブジェクトについて知っている必要のあることのすべての情報を保持するScriptを書き上げることによって、
「スマート」な「オブジェクト」を作ることができる。
「配列」という文法を用いることで、オブジェクトの内容を記述したDescription、ゲーム画面におけるLocation(ゲームシーンの中にあり、Pickできるかどうか?Inventoryの中にあるのかどうか?カーソルになっているかどうか?ゲームシーンの中で、Pickできないようになっているかどうか?ゲームシーンの中に登場しているかどうか?),そのオブジェクトがもつアニメーションのパターン、音声ファイル、そしてその他の属性を、整理統合することができる。オブジェクトの「状態」を「参照」することで
これらのオブジェクトの属性にアクセスできるようにする。

Chapter10 Message Text
UnityGUIの使い方を学習。2Dのメッセージテキストを画面表示できるようにする。GUISkinとGuiStyleもやります。GUIの形を整える方法です。メッセージテキストを表示させる「ラベル」
を画面に表示する方法。Scriptで、「位置」「縦の長さ」「横の長さ」を定義してメッセージが表示される「長方形」を出現させる。ゲーム上の空間を二つに分割する。あるオブジェクトとカーソルの距離が一定の距離より小さかったら、カーソルでオブジェクトの選択ができるようにする。そして、「選択」が可能であることをメッセージテキストとして表示する。その逆に、オブジェクトとカーソルの距離が、一定の数値より大きければ、そのオブジェクトの「選択」ができないということも、メッセージテキストとして表示する。つまり、カーソルとオブジェクトの距離によって、
適切なメッセージが表示されるような場合分けの手法を学習する。
表示されるメッセージテキストの長短に応じて、プレイヤーがそのテキストをすべて読めるように、テキストの表示時間を調整するScriptの仕方を学ぶ。

Chapter11 InventoryLogic
Layerという手法。複数のカメラを使い分けることで「アイテムリスト」が使用できるようにする。(InventoryScreen)この画面が、ゲームシーンの上に表示されるようにする。PCの特定のキーボードの打ち込み、またはゲーム画面左下のアイコンのクリックによって、プレイヤーが現在所持しているアイテムのリストが表示される。InventoryScreenが表示されている間、
ゲームシーンにおけるNavigation,MouseOver,アイテムの「選択」はできないように設定する。
プレイヤーが操作できるのはInventoryScreenの中に限定する。
InventoryScreenが表示されているとき、Jewelを出現させる。そしてそのJewelをPickすると
カーソルがJewelのカーソルに切り替わるようにする。

Chapter12 Managing The Inventory
プレイヤーが「取得」した「アイテム」の「管理画面」を作り込んでいく。3×3の魔方陣型の
アイテムリストに、ゲームで取得したアイテムを取得して、そのアイテムを「カーソル」にして、
そのカーソルを、空欄のリストに入れる。アイテムがはいっているリストをクリックすると、
そのアイテムをPickして、カーソルにすることができる。9個以上のアイテムの管理も可能に
するため、「アイテムリスト」は拡大可能。InventoryPanelの左右に→をつける。そしてその→をクリックして、残余のアイテムが表示されるようにする。
「アイテム合成」といわれているシステムの導入の仕方。CrowbarとGoldenSleeveというアイテムをInventoryPanelの中で、合成できる。CrowbarのカーソルをGoldenSleeveが入っている
アイテムのリストでクリックすると、Crowbar With GoldenSleeveという新手のアイテムが登場する。InventoryModeになっているときの画面の見やすさを考慮して、カーソルのサイズを調整するテクニックも学習します。

Chapter13 Finishing The Basic Functionality
オブジェクトをActive、Inactiveに切り替える手法。アクションオブジェクトとそうでないオブジェクトの区別を、カーソルのPickによって可能にするScripting.あるオブジェクトが、数回にわたって、Pickされるとき、ランダムにメッセージテキストが表示されるScript.3Dシーンのゲーム場面で取得したアイテムが2D画面のInventoryPanelで扱われるという切り替えの最中に
メッセージテキストが画面下部分に表示される。このとき、「みやすさ」「スムーズ」を追求する「調整」を行う。最後に、ChestLidの中に「手紙」を仕込む。ChestLidをOpenにすると、中の
「手紙」が登場する。その「手紙」オブジェクトのために、またReadingPanelが表示されるようにする。

Chapter14 Getting Down to Game
「宝箱」の「開け閉め」および、「宝箱」の「内側」に「収納」されている「アイテム」の
「取り出し」作用の設定。画面のスクロールによって映っているべきオブジェクトの一部が
「欠けている」状態を防ぐための手立ての学習。「エリクサー」という「魔法の薬」を
「枯れた花」にふりかけて、その「花」を再び「開花」させる。この一連のアニメーションを
動かすときに、パーティクルを出す設定の仕方。ゲームシーンを眺める「Camera」を複数
設定することで、画面ごとに一番、適切な「眺め」を実現する。
ゲームステージを完成形にもっていくため、Temple(寺院)のような立体モデルをUnityに取り込む。その周囲には冒険に必要なアイテムを集めるのに必要なShrine(神社)も配置する。
PCの描画処理の負担を減らすために、PlayerがTemple内部に入ったときにTerrainの位置を
調整するやり方も学習する。Templeのエントランス部分に風になびくカーテンのようなものを
設置する。その他、ホログラムやパーティクルを駆使してSFXな効果をステージの随所に仕込んでいく。その際、小さな滝があつらえてある池なども配置する。
最後に、所定の条件をクリアしないと、配置したTempleの中に入ることができないように
する仕掛けもScriptで設定する。(557文字)

Chapter15 A Maze and the Final Level
ゲームステージに「迷路」を設置する。「迷路」の「コース」はランダムに何度も変更することができるようにする。(いわゆる「ダンジョン無限生成」?」)。
この迷路にはとある「アイテム」が隠されているようにする。さらにTempleの中にある地下への
洞窟への入り口の作り込みも行う。そこにたどりつくとLevelChangeが実現する。
その洞窟への入り口のところで、プレイヤーが何をすべきか、「黙示」でわかるように、視覚的な「インテリア」を配置する。ゲームステージのクリアに必要な最後の場所をつくるために、
TreeGeneratorという機能を使う。(ここで、樹を復活させると「クリア」になる。)
この樹「Tree Of Life」が生み出す「果実」「Topi」が、地面に転がるというシーンを実現
するために、物理エンジンも使用する。
ここまできて、ようやくプレイヤーが、最初から最後まで遊べるゲームの「本体」ができあがったことになる。(408文字)

Chapter16 Menus And Levels
(画面上のカーソルを動かす)OR(PCのキーボードを打ち込む)の両方でゲーム上のボタン操作ができるようにする。項目別のメニュー場面の、表示・非表示の切り替えをFlagというプログラム手法を使って、実装します。
GUIBUTTON,GUILABEL,そしてスライダー(ノブを左右に動かして、BGMのボリュームなどを調節する。)を使って、メニュー画面を一つ一つ、作っていく。
本書のゲームを、一度、中断して再び、遊べるようにセーブ機能もつける。
ゲームの進行状態を規定する「変数」の値を配列にして、ファイルに保存して、再び配列の数値を
ゲームが「読み込む」という構造を作ります。
メニュー画面のカスタマイズをします。
ゲームの開発をどの時点が「完成」したと評価すべきかという「哲学的」問題について
論じます。
完成したゲームをどういう形式でプレーできるようにするかという問題についての検討。
WebPlayerで遊べるようにするのか、それともPCにインストールして、StandAloneで遊べるようにするのかという問題についての検討。(456文字)

(翻訳をしている筆者の主観。ここが読んでいて、一番参考になったような気がする。正直、
会社組織でもなんでもない、単なる個人でゲーム作りについてあれやこれやと片足を突っ込んでいる身としては、どうもこの3Dゲームというのは、敷居を高く感じられてならない。でも
ゲームの再開とか、セーブの仕方とか、ゲームプレイの条件設定とか、Creditの出方とか、
スタート画面の作り込みとか、およそ売り物にするゲームにはついてまわる部分のプログラミングというのは、応用がきくように思える。いままでも、この章であつかった部分のプログラミングについては文献を読んできたけど、ここまできれいにまとまっているのは初めて。そういう意味でも貴重。)

Chapter17 Beyond Basics
今回、本書で「完成」までもっていったゲームに、付加すべき機能をリストアップしている。
得点の表示
プレイヤーの生命ポイントの表示
ゲームを前に進めるために何をしたらいいのかのヒントが表示するシステムをどうやって
構築すべきか?
今回のゲームは「一人称アドベンチャーゲーム」だが、これをもし「三人称アドベンチャー」に作り替えるとしたら、どんな技術的問題をクリアする必要があるのかの問題点の提示。
キャラクターアニメーションについても言及。
オブジェクトと、プレイヤーがゲームの中で「対話」ができるようにするとした場合、
どのようなシステムでそれを実現したらよいのかについての検討もなされます。
iPhoneやAndroidOSの端末に、ゲームをインストールさせることをしようとした場合についての
諸注意。(本書は基本的にはUnityで作ったゲームをPCで遊ぶことを前提にしている。)
最後に、このゲームのデザイン・ストーリー・ゲームのメカニクス・グラフィックのコンセプト
などをまとめたドキュメントの見本が示されている。)
(448文字)

追記
ゲームは「産業革命」に突入した 任天堂・岩田社長の苦悩 :日本経済新聞

 大前氏は、この現象は広がりを見せていると指摘する。二次元のアクションゲームをプログラムを書かなくてもレゴブロックのようにパーツを組み合わせることで作れてしまう「GameSalad」や「Game Maker」といった優れたゲームエンジンが無料から数十ドルで使うことができる。しかも、この開発環境で作ったゲームは、スマートフォン用にリリースしたり、「HTML5」にも書き出せるため、自分の作ったゲームを世界中の多くの人に届けることも簡単にできる。

追記 その2
CG-ARTS教育リポート 日本と世界のCG教育のいまが見える

三宅氏は、京都大学で数学を専攻した。卒業後は大阪大学に進み、修士課程で物理学を専攻し、同大学の核物理研究センター(RCNP)や高エネルギー加速器研究所(KEK)で原子核物理学の実験的研究を行った。博士課程では東京大学工学系研究科に所属し、電子ネットワークの内部状態をリアルタイムに把握する研究を行っていた。

当時、日本のゲーム業界がどのような技術をもっているかといった情報は殆ど公開されておらず、論文もなかった。しかしゲーム会社には、さぞゲームAIの技術が蓄積されているだろうと想像して、三宅氏の経歴とはまったく畑違いだったゲーム業界に飛び込んだ。
ところが事前の予想に反して「日本のゲーム業界では、全般的にAI技術が蓄積されていない」という事実を知り、ショックを受けた。三宅氏は、自分が勘違いをしていたことに気がついたのだ。様々な論文を読み、調査を進めていくにつれて、きちんとした「ゲームAI」とよべる技術も、その研究も、日本の大学やゲーム会社には殆ど存在していないことが、わかってきたのだ。

この研究グループからは、現在のゲームAIに大きく影響を与えた人材が輩出されている。アメリカBungie社の「Halo2」(2004年)、「Halo3」(2007年)のゲームAI開発に参加し、複雑な振る舞いを見せる敵AIの意思決定手法を作り上げた、ダミアン・イスラ(Damian Isla)氏だ。また、同じMITメディアラボには、MITで研究を続けながら「F.E.A.R.」(Monolith Productions、2004年)の「ゴール指向型アクションプランニング」(GOAP, Goal-Oriented Action Planning)とよばれる、まるで本物の人間であるかのような印象を与える意思決定の動きを見せる敵AI技術を開発したジェフ・オリキン(Jeff Orikin)氏がいる。

追記 その3
ゲームロフト、「Yahoo!Mobage」でFPS『N.O.V.A. Elite』の提供開始 | Social Game Info

ゲームロフト は、「Yahoo!Mobage」で、『N.O.V.A. Elite』の提供を開始した。無料で遊ぶことができる。

本作は、本格FPSだ。ゲームには、4種類のマップが用意されており、最大12人でバトルを楽しむことができる。プレイヤーは、アーマーをパーツごとに選んだり、武器をアップグレードしたり、自分のシンボルをデザインしたりして、最強の装備をカスタマイズすることができる。

ゲームモードは、クイックプレイとカスタムプレイが用意されている。カスタムプレイでは、バトルロイヤルとチームバトルロイヤルが選択可能。マップとモード、プレイ時間やプレイヤー数も選択できる。クイックプレイではランダムにマップへ飛び、様々なプレイヤーと遊ぶことが可能だ。

本作は、FlashPlayerではなく、UnityWebPlayerを使っており、ブラウザゲームとは思えないほどのグラフィックと迫力満点のゲームになっている。

追記その4
Unityで楽々スマホ用3Dアプリ開発入門(2):UnityでAndroidの機能を拡張する2つの手法とは (1/3) - @IT