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

maimai_jp's blog

twitterでは書ききれないことなどをこちらに。

ゲーム開発を4年ぐらいやってきた中で読んだもののうち、面白かった技術書

http://d.hatena.ne.jp/mizchi/20130403/1364918070

ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー

@mizchiの雑記帳

カタ氏(@hotchemi)が意識高い記事書いてたので、自分もまとめてみる。
文系学部生がSIerに入社してから読んだ本メモ - ギークに憧れて http://hotchemi.hateblo.jp/entry/2013/04/01/000844

ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー

 

……という記事を見かけて、面白そうなので自分ものっかってみました。

時々tweetでオススメしたり何だりはしてましたが、どっかしらにまとめたいとは思ってましたので。

基本的なスタンスはプランナー(ゲームデザイナー)&プログラマ向け。

どうしても被るものは被りますんで、その辺りはマストなんだなー、と思っていただければよろしいかと。

 

スクリプト基礎知識

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

鉄板。鉄板中の鉄板。プランナーは特に。

プログラマであればコーディングルールとか最初に叩きこまれるんだろうと思います。でも、プランナーはもちろんスクリプター(=特定のゲームエンジン上で企画をスクリプトに落とし込む作業を専門で行う人)ですら、コーディングに配慮がない人が大多数を占めるんですよね。

原価を回収するためにゲーム開発がMMO/ソーシャル系が前提となっていくことは、既に起きつつある流れでしょう。そんな中で、ローンチしたら完了のゲームとは異なり、MMO/ソーシャル系はコードを延々と保守し続けることになっていきます。

そうなると、コードの制作者と保守の担当者がイコールにならないことも確率的に多くなるわけです。また、自分で書いたコードを数年後の忘れた頃に自分で保守することもあり得るでしょう。そのことを頭に入れて、「いつ誰が読んでもいい」=「リーダブル」なコードを書いてほしい……。既存のクソコードを保守し拡張し、時にはリファクタかける者からの切なる願いです。

 

オブジェクト指向でなぜつくるのか 第2版  知っておきたいOOP、設計、関数型言語の基礎知識

オブジェクト指向でなぜつくるのか 第2版 知っておきたいOOP、設計、関数型言語の基礎知識

こちらは主にプログラマ向けです。とはいえ、プランナーもLuaとかUnityのC#とか、当然のように使うことになりつつありますので、読んでおいて損はないでしょう。

最近はオブジェクト指向ではない言語の方が少ないので、もしかして歴史の教科書みたいな読み方をした方が面白いでしょうか。「継承」「多態性ポリモーフィズム)」「カプセル化」……本来、どんな思想でJavaに代表されるOOPオブジェクト指向プログラミング)へ則した仕様が策定されてきたか、それを知るのにいい本だと思います。

 

 

ゲームフロー概観

「レベルアップ」のゲームデザイン ―実戦で使えるゲーム作りのテクニック

「レベルアップ」のゲームデザイン ―実戦で使えるゲーム作りのテクニック

プランナー寄りのゲームデザイン本です。目的設定やUI策定からゲーム体験のフローまで、企画が制作当初から考慮すべき話題が数多く含まれています。

もっとも、ゲーム制作なんて答えのないものは千差万別ですから、若干著者の思想が入っている部分がどうしても出てしまっています。(QTEとか。)この本に書かれていることを全て守ればいいゲームになるかといえばそうではないでしょうし、逆にこの枠組みから外れたら面白くなくなるかといえばそれもまた違うでしょう。なので、その辺りは自分の好みを尊重しながら読んでいただければと思います。

 

オンラインゲームを支える技術  ??壮大なプレイ空間の舞台裏 (WEB+DB PRESS plus)

オンラインゲームを支える技術  ??壮大なプレイ空間の舞台裏 (WEB+DB PRESS plus)

こちらは若干レイヤーが下がって、プログラマとプランナーの中間ぐらいでしょうか。

MMOは本来、(マシンリソースなどの)コストと(制作上の)自由度との天秤で成り立ってます。ある行動を実装したい!と企画が言い出した時、それを実現するのがプログラマの本分です。しかし、それがそのままでは実現不可能な場合がままあります。

時には、その実現に必要なデータ通信量が膨大だったり、通信や描画の遅延がクオリティの許容範囲を超えたり、あるいはローンチから数年経過したMMOゆえにデータ構造を大改造しないと実現できないものは全検証が必要でコスト的に無理……なんてこともあるでしょう。

そんな時、「何ならできるか」を知っていることは、プログラマにとってもプランナーにとっても助けになるはずです。ある程度の妥協をし、それ以外の部分で補うことで、没になりかけた企画が実現できるかもしれませんから。

また、こちらの前半部分で書かれているネットワークおよびゲーム技術の歴史は、是非コンピュータ工学系の学生に読んでいただきたい内容です。基本情報技術者試験のために文字列を丸暗記するよりも、よっぽど健全で有用ですので。

 

ゲームを動かす技術と発想

ゲームを動かす技術と発想

プログラマ向け。自分は名目上企画ではあるんですが、趣味で読んでみました。が、読んだ後だとブラックボックスなハードウェア部分についてぼんやりとながら「ゲームがどう動くか」をイメージできるのでオススメです。

ハードウェアの構成によって出せるスペックがどう異なるかといった話題があったり、msec(1/1000秒)以下の戦いが時系列で可視化してあったりと、生々しいデータがわかりやすく解説してある本です。

未だにリソース戦争が起こるようなモバイル開発の現場では特に活きる知識かもしれません。

 

 

ゲーム技術概観

Unity入門 ?高機能ゲームエンジンによるマルチプラットフォーム開発?

Unity入門 ?高機能ゲームエンジンによるマルチプラットフォーム開発?

既存のUnity本の中で随一のわかりやすさ。ちなみにこちらの著者は現在Unityの中の人になっています。

動くものを最小限の操作で実装し、フォームに一覧されたパラメータをいじることで様々な現象を発生させる。Unityで実現できるゲーム開発体験に即した流れで展開されます。

この本で知ることは、Unityで出来ることではあります。ですが、このUnityで出来ることは「現在のゲーム開発で知っておくべきこと」でもあります。

既存の開発現場では、ある技術が実装されるかどうかはプログラマ依存なのが現状です。一方でUnityは、既知のゲーム開発で必要だと思われる技術の大半が既に実装されており、最新のUnity4では既存に見られない技術の実装も導入されています。(ちなみにこちらの本が出版された頃はUnity3.3~3.4)この辺りはゲームエンジンの強みでしょうか。

何が実現できるかは、開発者自身の持つイメージに依存します。プランナーもプログラマも知らなければ、その技術は組み込まれません。逆にそのイメージさえあれば、弘法筆を選らばずとはよく言ったもので、たとえコモドール64だろうがExcelだろうが実現させてしまうのがプログラマです。

そのイメージを広げ、プログラマを死地に向かわせる素晴らしいゲーム体験を提供するためにも、Unityを触れておくことをオススメします。そのHello world!となる一歩はこちらの本で間違いないと思います。

ついでに。本とは関係ないですが、著者本人によるUnity解説動画もありますのでご紹介を。↓

iPhoneゲームを20分間で作る【メダルプッシャー編】

http://www.nicovideo.jp/watch/sm12948504

 

 

デザイン思想

誰のためのデザイン?―認知科学者のデザイン原論 (新曜社認知科学選書)

誰のためのデザイン?―認知科学者のデザイン原論 (新曜社認知科学選書)

現在、3Dのゲームが当然のようになってきていますが、2D時代の特性と比較して失われたことの一つに「全ての情報が画面上に表示できなくなった」というものがあります。

つい最近も流行ったブラウザゲームの脱出ゲームをイメージしてもらえるとわかりやすいでしょうか。アイテム、移動操作、配置物……全ての情報は画面上にあります。しかし、3Dのゲームはカメラ移動により視界が「自由に」変化しますし、情報をスプライトで表示すれば画面上の視界が狭まります。

こんな時、「アフォーダンス」を意識することは1つの武器になると思います。高確率で視界に入るものにアフォーダンスを意識し「水を向ける」ことで、自然とゴールへ迷うことなく向かったり、また必須となるようなアイテムをそこそこの時間で探し出せたりと、ゲーム体験を快適にしてくれるはずです。(静的なものだけではなく、強制的に視覚に入るようカットシーンを入れたり、カメラ自働調整を機能として導入したりするのも含めてデザインでしょうか。)

こちらの本は、認知心理学者である著者が様々なもののデザインや、そのデザインの評価について考察したものになっています。

レベルデザイナーの方はもちろん、マップや小物などがどことなく使いにくいなー……なんて思ったバトル・イベント担当の方が、どこが問題なのか評価・分析するツールとして、こちらの本で得られる知識が有用だと思います。