「Unityではじめるゲームづくり」出版

unity3d GDwU

Unityではじめるゲームづくり　(DVD付) (ゲープロシリーズ)

Unityではじめるゲームづくり　(DVD付) (ゲープロシリーズ)

　このたび洋書 Game Development with Unity の日本語版「Unityではじめるゲームづくり」を出版することになりました。長らく「Unityゲーム開発(仮)」という名前で宣伝されていた本です。
Game Development with Unity, 1st Edition

Game Development with Unity, 1st Edition

　Unityは自宅で使う場合などは無償で使え、有償版も低価格なゲームエンジンです。この本は添付のDVDに入っているデータを使いながら、ステップbyステップでゲームを作りつつ、Unityの使い方と包括的なゲーム制作の知識を身につけることができる構成になっています。

　この本を翻訳した経緯は７月の「IGDA日本ゲーム開発セミナー Unity の実践と導入」でお話しさせていただきました（まとめはこれ）。元は社内セミナーで使用するための資料として訳していており、社内でも出版してはどうかという声があがっていたところに、IGDAのイベントで多くの人から出版を薦められたことで決心がつき、「ゲームエンジンアーキテクチャ」でお世話になったソフトバンク・クリエイティブさんに企画を持ち込ませていただき出版に至ることになりました。

　社内の勉強会は、Game Development with Unityを副読本として、その構成に沿ってスライド資料を作って進めていく形を取っています。今回の出版にあたりそのスライド資料もオマケとしてDVDに丸ごと入れることになっており、今はその添付資料をブラッシュアップしていっているところです。

　これがなかなかしんどいです……
　勉強会ではスライド＋操作説明でやってたところを、一応単独でも読める形にしないといけないですからね。元から合計800枚くらいあったんですが、これは最終的に1,000枚越えると思います。まあ、スライドなので１枚あたりの情報量も作業量も全然しれてるんですが……

　で、業務時間扱いの勉強会とは並行して、「放課後Unity倶楽部」という集まりも作られ、アフターファイブに会議室にPCを持ち寄ってみんなで実際にゲームを作ったりしてます。作ったものはそのまま社内フリーコンペに出品したりして、ずいぶん楽しませてもらいました。この活動は今でもやってますし、一段落したら勉強会も２周目を始めようと思っています。

　社内でさまざまなエンジンが検証される中で、Unityでは特にプロトタイピング性能に注目が集まり、有志でこの勉強会や倶楽部を立ち上げ、企画職、アーティストをメインターゲットに置いてやってきました。そういう経緯もあり、出版にあたっては、企画さんやアーティストさん（志望の学生さん含む）が本屋で本を見かけたときに「Unityゲーム開発…？ 俺には関係ない本だな」と思わないように、「Unityではじめてのゲームづくり」という名前をつけさせていただきました。

　また、社内でまだ Unity を触ったことがない企画さん、アーティストさんを捕まえて、原稿を渡してレビューして貰ってますので、「技術者じゃなくても読める」「ついでに自分の専門外の技術も少し覚えちゃえる」というのは、決して私たちの思い込みではないはずです！

　出版前なんで強気にいっときます！

ホントはスネてます

CEDEC 
　　　　 ＿＿＿＿＿＿＿＿＿＿___
　　　／|：： ┌──────┐ ：：|
　　/.　 |：： ｜ 　　　　　　　　 ｜ ：：|
　　|....　|：： ｜　　　　　　　　　｜ ：：|
　　|....　|：： ｜　　　　　　　　　｜ ：：|
　　|....　|：： └──────┘ ：：|
　　＼_｜　　　 ┌────┐　　 .|　　　　 ∧∧
　　　　 ￣￣￣￣￣￣￣￣￣￣￣　　 　 ( 　＿)　　　　俺がCEDECに行かないことで
　　　　　　　　　　　　　／￣￣￣￣￣旦￣(_,　　 ）
　　　　　　　　　　　 ／　　　　　　　　　　　　　＼ 　｀
　　　　　　　　　　　|￣￣￣￣￣￣￣￣￣￣￣|、＿）
　　　　　　　　　　　 ￣|￣|￣￣￣￣￣￣|￣|￣

　　　　　|　　　　　　　　　　 .( (　|　|＼
　　　　　| )　　　　　　　　　 　) ) |　|　.|
　　　　　|＿＿＿＿＿＿＿＿(__|　.＼|　　　　　　　　俺の代わりに会社のだれかが一人、CEDECへ行ける
　　　 ／― 　　∧ ∧　　――-＼≒
　　／　　　 　 ( 　　　)　　　　　　　＼
　　|￣￣￣￣￣￣￣￣￣￣￣￣￣ |
　　|＿＿＿＿＿＿＿＿＿＿＿＿＿_|

　　　∧∧
　　（　 ･ω･）
　 ＿|　⊃／(＿＿_
／　└-(＿＿＿_／
￣￣￣￣￣￣￣
　　　　　　　　　　　　　　　　　　　　　　　　　　　　俺はそういうことに幸せを感じるんだ
　 ＜⌒／ヽ-、_＿_
／＜_/＿＿＿＿／


ショーに来てくださるお客様の笑顔が最優先ですよ！！（虚勢）

ゲームエンジン・アーキテクチャの目次を楽しむ

GEA

　ソフトバンククリエイティブの編集者の方からゲームエンジン・アーキテクチャの目次をいただきました。実はこれ、節レベルでリストアップされていて、目次だけでも２１ページあるという大作なのです。ゲームプログラムをしている人なら、どんな情報が載っているのか目次だけで想像がつくと思いますので、迷っている人は購入の判断材料に、もうすでに予約済みの方はこれ読んで楽しみを膨らませてください。

　なお、この目次PDFは再頒布可能だそうなので、こんな閑散とした個人ブログにのっけてもしょうがないと思いますから、是非ここから持って行って、興味のある人同士で共有してくださいませ。

　https://files.me.com/minahito/oppp7b

ゲームエンジン・アーキテクチャ (Professional game programming)

ゲームエンジン・アーキテクチャ (Professional game programming)

ゲームエンジン・アーキテクチャの日本語版が出版されます

GEA

Naughty Dog のエンジニア Jason Gregory が書いた技術書 Game Engine Architecture の日本語版が11月30日に発売される運びとなりました。
私も末席ながら訳本監修の一人という形で日本語版に関わらせていただきました。

ゲームエンジン・アーキテクチャ (Professional game programming)

ゲームエンジン・アーキテクチャ (Professional game programming)

ゲーム業界でご飯を食べているエンジニアの方や、ゲーム業界を目指している学生さんに是非お手にとっていただきたい良書となっています。知識を得る本としてもリファレンスとしても優れていて、ABC本の要素もあります。

初めてこの本を読んだとき、「いい本だなあ。こういう本を読めない英語力のない僕みたいなのがいけないんだよね。あっはっは」では済まされない何かを感じまして、絶対に日本語版が出なければならない、と思いました。

同じ想いを抱いた方がいらっしゃると思います。日本語版は、原著で「凄いことが書いてあるんだけど何となくしか分からんし確証が持てない！」と悶えたところがすべて我々の母国語、日本語になっています。 Game Engine Architecture が本来持っていたパフォーマンスを100％楽しめます。

自分の知らない知見を得るために、あるいは後輩に教えるためのリファレンスを得るために、多くの気付きを与えてくれると思います。

技術の進化がアジャイルを可能にした

Agile

「すくすくスクラム」の「振り返り会」*1に参加させていただいて、そこで出た話で、目から鱗が落ちる話があったので共有させてください。

    • -

エンジニアの間では計画ベース……いわゆるウォーターフォールプロセスモデルやその類似系に対する信奉がある。ウォーターフォールプロセスは間違っていたのか？

かつて、プログラマはパンチカードでソフトを入力していた。それからメインフレームの時代。プログラムの開発には現在とは比較にならないほど大変な時間がかかっていた。
プログラムを入力し、実行し、結果を受け取るまで一体どれくらい時間（あるいは日数）がかかっていたか？ そもそも開発環境の使用権自体が持ち回りだった。
このように、変更と試行に何日と要する状況では「事前に計画を可能な限り完全に行い、変更をゼロに近づける」計画ベースのプロセスが重要視されるのは必然。

しかし現在はパソコンの存在とマシンの高速化、高級言語の実用化、分散ビルドやスクリプティング技術によって、プログラムの変更と試行は圧倒的に短くなった。
技術革新によって変更コストが圧倒的に安くなったことで、アジャイルのような従来にない開発プロセスが可能になった。逆に従来の計画ベースの開発はその必然性を損ね始めた。

    • -

単にヨソからいただく開発環境の充実だけでなく、TDDとか組込スクリプトとか、変更コストを安くして、変更する勇気を持ちやすくするありとあらゆる取り組みが、アジャイル開発に繋がるんだなと思いました。

*1:飲み会ともいう

Naughty Dog が PS2 時代に使っていた Lisp は命令型スタイルの機械語変換

欧米か!

　Naughty Dog の Lisp 好きは有名な話ですが、 Playstation 2 に用いられていた Lisp は、今日僕らが想像するような VM の組み込みなどとは多少事情が異なるようです。 Wikipedia に Game Oriented Assembly Lisp として情報がまとまっていました。

*1:Naughty Dog の創業者の一人

*2:が、Lispは継続してます

サインアップ

Agile

　リーダーが仕事をメンバーに指名して割り振ることをサインイン、メンバーが貼り出された仕事から取って行くのをサインアップと言うらしい。
スクラム開発では、スプリントで達成すべき仕事をチームで片付けていく。そのため基本的な考えはサインアップになります。
　これはゲームの現場では大きな議論を起こすもののひとつだと思います。

  1. 描画系、サウンド系、システム系、人工知能、物理エンジン、コンピューティング、シェーダなど専門分野があまりにも多い。
  2. 企画とエンジニア、企画とアーティスト、アーティストとエンジニアが１対１などの少人数で結びつくことがこれまで多かった。
  3. 担当分野を決めてそこへの習熟度を高めたほうが、最終的に効率良く開発できる（個人単位の普請方式）と従来考えられている。
  4. ごく少人数で結託して、全体で把握されていないものにこっそりとトライすることで創造的なものが作れるという文化がある。*1


　こーゆーのどうするんじゃろう。
　Cross functionally チームが作れれば 1 と 2 は解決しそうな気がします。うまくやればアニメーションシステムと物理エンジンのエンジニアが同じチームに配置されませんし、密接に結びつく企画とエンジニアが同一チームに入ったうえでチームと共有されます。

　1 と 3 は似て非なるもの。 1 は専門性が高すぎてサインアップ体制を取りたくても難しいという話。 3 は積極的にサインインを活用するのでサインアップと反するという話です。

　Aさんなら１時間で済む仕事も、初めて取り組むBさんでは何時間かかるか分からない。そもそもそれ自体、現場でコードレビューをやってないという証拠なんですけども。

こうなると、プロダクトオーナーの選択に制約が入ります。あるスプリントでAさんの担当ぶんが飽和してしまって、重要だけど次のスプリントに見送るしかない。またBさんの手は空きっぱなしなので、さして重要でもないBさんの分野の仕事をスプリントに積まなければいけない。

　仕事の規模、優先度、依存関係に加えて、担当者という情報が一個増えてるので、結構大変です。

　難しい問題なので何ともいえませんけど、最近ひとつ重要な再発見をしたような気がするので報告します。"サインアップ方式は結構楽しい"です。把握してない事柄について、ソースそ読んで、情報を聴いて集めて、分析し、戦略を話し合って、協働して問題を解決する。忘れてましたがエンジニアは結構こういうこと好きだった。オープンソースが楽しいのもひとつはコレですよね。

　よっぽど極端なスケジュールが絡むと難しいけど、少なくともエンジニア側にはサインアップ方式を拒む理由はないなぁと思いました。

*1:方法論はともかく潰してはならないスピリットだと思う