ゲームエンジニア養成読本

今回は、著者様から献本いただいたゲームエンジニア養成読本の感想です。

 

いやー、ダレ得なんですかね、この本?

ビジュアルスクリプトの話があるかと思えば、マルチスレッドジョブコントローラーのソースコードとか載ってるんですよ。頭おかしいでしょ?!(良い意味で)

かなりターゲットが絞られているところがすがすがしくて良いと思います。
これ一冊読めば、ノードベーススクリプトの実装部分が書けるという中身になっていますね。
鬼だ(とても良い意味で)

 

今は、ゲーム作りで先生をしているのですが、日々悩んでいるんですよ。
ゲーム会社のプログラマに、どうすれば学生が業界入れますかねぇとか聞くと、「ゲームエンジンでゲーム作れるだけでは、業界入れない。」とか、「C++ができなければだめだ。Unity使ってるんで触ることないけど。」とか聞く事が多いので、どうすればいいんだよとかよく考えます。「C++でのメモリ管理とか、できると強いんだろうけど、そんなコード書く機会可能性はほとんどないだろうし(どうせ、そういうの書くの好きで得意なおっさんが仕事取っちゃうでしょ)、それを強いるのって老害じゃないかなぁ」と思ってしまうんですよねぇ。

そういう意味では、この本は、スクウェア・エニックスの人たちが書いているだけあって(辞めている人もいるけど)、「現場では、この技術使っているんですよ」と感じられるところがとても良いですね。転職組の人たちが書いているので、「その会社独自の文化でしょ」という印象も薄められている感じも素敵。そして、FFのコーディングルールはこんななんだろうなとか想像するのも楽しい。

閑話及第。読み終わって、この本は、コンシューマゲームプログラマが身に着けておくべきスキルを把握するのに、とても良いように思いました。プログラマ志望者でも結構デバッグの仕方を知らない学生がいるので、「このぐらい覚えておけ」とか提示するのによさそうだなぁと思っています。

ちょうど今、マルチスレッド教えているから、この本の内容を宿題に出そうかなぁ

 

P.S. 参考文献に載っている「ゲームエンジン・アーキテクチャ」もよろしくね

広告

継続的レイトレ合宿

はじめに

このページはレイトレ合宿5‽のアドベントカレンダー2週目の記事です。
べ、別に、怖い人たちが記事を書く前に、さっさと済ませておこうなんてつもりじゃないんだからねっ!

概要

さて、本題に入りますが、レイトレ合宿では、レギュレーションが定められています。
例えば、一枚絵の場合には、次のようなルールになっています。

  • 何もインストールしていないまっさらなマシン上で動作するようにしてください。
  • 実行ファイルを叩いたら自動で始まるようにしてください。キーボード、マウスの操作を要求する作りにしないでください。
  • ネットワーク越しに何かをやるような動作をさせないでください。
  • おおよそ30秒毎に、レンダリングの途中経過をbmpかpngで連番(000.png, 001.png, …) で出力してください。
  • 4分33秒以内に自動で終了してください
  • マシンスペック:AWS(Microsoft Windows Server 2016 Base/Amazon Linux)

もーめんどくさいなぁ。
ルールに準拠するサンプル用意してくださいよ~

と思ってしまうのは、人の常ではないでしょうか?!

と言うことで用意したのが、imagirelab/raytracingcamp5 になります(Amazon Linux AMI 2017.03.1.20170617 x86_64 HVM GP2で動作確認済み)。
同じようなものは以前、用意したのですが、今年は一歩進めてCDですよ、CD。
CDといっても、Compact Disc 出はなくて、Continuous Delivery。そう、継続的デプロイです。
プログラムをGitHubに上げると、ビルドをしてzipして、すぐ配れるんですから。
それだけじゃなくて、プログラムを実行して、実行結果がホームページとして見れてしまうのですよ。

この環境を使えば、ローカルにビルド環境や実行環境がなくてもレイトレ合宿のプログラムができるのですよ。
そう。スマホからレイトレ合宿の開発が可能です!

中身

やっていることは、Travis CI をまわしてるだけです。

Travisフロー.png

ルートに.travis.ymlを置いて、あとは、pushされたときに自動実行していきます。

ビルドと実行に成功した後は、別のリポジトリにpushして、GitHubのgh-pages(リポジトリをホームページにする機能)を使って、公開します。ホームページのHTMLは、あらかじめ静的に用意しておきます。

フォルダ構成

使わないファイルを省くと、リポジトリのファイルは次のようになっています。srcフォルダ内が実際のレイトレのファイルで、sdkフォルダに外部のライブラリを格納しています。static フォルダは、ビルド結果のホームページの静的ファイルで、HTMLファイルを用意しています。ちなみにレイトレ自体は、Shirley御大の In One Weekend (週末レイトレーシング)の内容に少しだけ手を入れたものとなっております。

+--README.md // GitHubのリポジトリアクセス用
+--LICENSE // ライセンス表示
+--.travis.yml // TravisCIの設定ファイル
+--.gitignore // gitの対象ファイルの設定
+--src // レイトレのソースファイル
| +--main.cpp
| +--makefile
| +--my_rand.h
| +--raytracingcamp5.sln
| +--raytracingcamp5.vcxproj
| +--raytracingcamp5.vcxproj.filters
| +--renderer.cpp
| +--renderer.h
| +--RT_struct.h
+--static
| +--index.html// ビルド後のホームページのHTML
+--sdk
 +--stb // nothings/stb(1ファイルヘッダオンリーのライブラリ集)
   +--stb_image.h
   +--stb_image_write.h

.travis.yml

ビルドのかなめは、.travis.yml です。.travis.yml の最初は環境変数の設定になります。

language: cpp
env:
 global:
 - email=imagire@gmail.com
 - username=imagire
 - secure: "v6…(中略)…U="

今回は、C++を使うので、cppのコンテナを呼び出します。また、git用にメールアドレスや、ユーザー名を設定しておきます。

その後の、secureは、GitHubのパスワードを暗号化して書き込んでいます。具体的には、次の様に作ります。この文字列は、後から出てくる${GH_TOKEN}という文字列を実際に使用する際に、複合化されて呼び出されます。この暗号化の手順は次の通り。

  • GitHubの自分のプロフィールから、Personal access token を取得
  • sudo gem install travis でtravis CI Clientをインストール
  • travis encrypt -r (ユーザー名)/(リポジトリ名) GH_TOKEN=(取得したPersonal access tokens) でPersonal access tokenを暗号化
    • 例:travis encrypt -r imagirelab/raytracingcamp5 GH_TOKEN=c45cf01c53cf64b41869b3f070e64e7783d177ed

まぁ、でも、コンソールで行わないといけないので特にWindowsの人は面倒ですよね。travis CIの「setting」-「Environment Variables」で設定するという方法もあります。

traviscienv

.travis.ymlのその次の行からは、実行するコマンドです。「-」をつけて、実行する命令を並べていきます。今回は、gcc を makefile をつかってビルドしています。make dependで依存性を調べた後、makeでビルドします。ビルドファイルはa.outとしています。

実行ファイルができた後(レイトレ合宿5ではzipで提出するので)、実行ファイルをzipで固めた後、実行ファイルを実行しています。

script:
 # gcc のバージョンを確認してみる
 - g++ --version
 # build
 - cd src
 - mkdir bin
 - make clean
 - make depend
 - make
 - ls -lsaR # ファイルがビルドできたか確認
 # 実行
 - cd bin
 - zip -r raytracingcamp.zip ./ #zip を作る
 - ./a.out # プログラムの実行!

ここまでできたら、事後のプロセスということで、GitHubに結果を上げていきます。masterブランチのみの更新を対象として、プルリクでも呼び出しは更新に含めないというのが定番な設定のようなので、その設定を最初に行います。次に、あらかじめホームページ用のHTMLファイルを置いておいた「static」ディレクトリの中身をコピーしてきてから、gitに追加して、GitHubに上げています。GitHubのリポジトリは、ソースコードのリポジトリと別のリポジトリにしています。

after_success: # デプロイ
 - test "$TRAVIS_BRANCH" != "master" && exit 1 # マスターブランチが更新されたのでなければ無視
 - test "$TRAVIS_PULL_REQUEST" = "true" && exit 1 # プルリクで呼ばれた時にはデプロイしない
  # 静的なHTMLファイルを取ってくる 
  - cp ../../static/* . 
 # git に新しくpush
 - git config --global user.email "$email"
 - git config --global user.name "$username"
 - rm -rf .git
 - git init
 - git add --all
 - git commit -m "deploy commit from travis"
 - git push -f https://${GH_TOKEN}@github.com/imagirelab/rtc5.git master

サービス設定

GitHubの設定は、ソースコードが置いてあるリポジトリの設定の、「Integrations & services」でTravis CIを追加します。具体的な設定方法が詳しく知りたい方は、例えばこの記事を書いているのググった結果の一番最初にあった「さくらのナレッジ:GitHubと連携できる継続的インテグレーションツール「Travis CI」入門」などの入門記事がありますので、そちらを読まれると良いでしょう。

TravisCiIntegrations

また、実行結果の方のリポジトリ(imagirelab/rtc5)は、GitHub Pages の設定を行います。こちらは、GitHubのリポジトリの設定で、ホームページとして公開するブランチを指定すれば、ホームページのURLをもらえ、ブランチが更新されるたびに、ホームページが自動で更新されます。

TravisGhPages

さいごに

さぁ、このプロジェクトをforkして、srcの中身をあなたのレイトレに書き換えれば、あなたもレイトレ合宿に参加可能です。

諏訪湖で僕と握手!

モダンアジャイルの原則・実践について

Agile Japan 2017 小冊子である、「アジャイルの魂 2017」で執筆させてもらえることになりました。

本年は、ジョシュアさんが基調講演に来られるということで、モダンアジャイルのプラクティスについて書かせていただきました。

おかしなところがありましたら、教えていただけると嬉しいです。


はじめに

ここでは、私が勝手に図を訳して公開した、Industrial Logic社の「Modern Agile」の記事に書かれた十二の「モダンアジャイルの原則・実践」について見ていこうと思います。と、思案して何度か推敲したのですが、ジョシュアの言葉をストレートに皆に伝えるのが最も価値が高くなると考え、ブログ記事の部分的な勝手訳となりました。現在のモダンアジャイルは、公式サイト(http://modernagile.org/)で、洗練化されていますが、源流を覗く事で理解が深まれば幸いです。

この後の見出しの頭は、関係する次の原則(元は規律だった!)を表します(先頭が主要な原則)。

  • [最高]人々を最高に輝かせる
  • [安全]安全を必須条件にする
  • [高速]高速に実験&学習する
  • [継続]継続的に価値を届ける

 

[最高・安全]仕事の憲章化(Charter Your Work)

人々を最高に輝かせたいなら、その意味を定義する必要があります。アジャイル憲章は、明確なビジョン、ミッション、テスト可能な成果物を、プロダクトコミュニティが発見し、同じ立場で考えてもらうための軽量なプラクティスです。憲章の設置は、プロジェクトの最初に一度だけ行うものではありません:憲章の設置は継続的な試みです(アジャイル憲章は英語だと “ing”が付いています)。良い憲章はガードレールのようなものです。道を逸れるのを妨きます。 憲章の二人の専門家、エインズレイ・ニースとダイアナ・ラーセンは、著書「Liftoff:Launching Agile Teams&Projects(リンク先は第2版)」でこの重要なプラクティスについて述べています。

 

[高速・最高・安全]リーン・スタートアップの活用(Leverage Lean Startup)

大規模な組織、小規模なスタートアップ、またはその中間のソフトウェアを開発する場合でも、エリック・リースの古典的な「リーン・スタートアップ」の知識を活用するとよいでしょう。人々を最高に輝かせるために、エリックは、私たちの大部分が「不確実な状況下で活動してしまっている」ことを理解するのを助け、ユーザーが必要とするものを推測する事がいかに安全でないのかを明らかにしてくれます。 彼は、素早く簡素な実験や仮説の迅速な検証・無効化など、精緻なコードを作るための投資をしてしまう前に、何を作るべきなのかを発見するための、さまざまで有用な方法を提案してくれます。 もし、ユーザーが実際にソフトウェアを使用しているかどうか、利益を受けているかどうか、超すげーことになっているかどうかを、あなたが分かってないならDoneの定義を再定義する必要があります。 また、企業内でリーンをスケールするのに苦労しているなら、ジェズ・ハンブル、ジョアンヌ・モレスキー、バリー・オライリーの「リーンエンタープライズ――イノベーションを実現する創発的な組織づくり」を勉強するのがいいです。

 

[高速・最高]リーンUXの適用(Apply Lean UX)

リーン・スタートアップに密接に関係しているのがリーンUXです。リーンUXは、優れたユーザー体験を発見して作り出すための、迅速で低コストな分析主導のアプローチです。 私は、リーンUXコミュニティの代表者であるローラ・クラインの「機能の見せ掛け」テクニック(多くのリーンUX技術の一つ)を学びました。 リーンUXの詳細については、ジェフ・ゴーセルフとジョシュ・セイデンによる「Lean UX ―リーン思考によるユーザエクスペリエンス・デザイン」と、ローラ・クラインの「UX for Lean Startups: Faster, Smarter User Experience Research and Design」から学ぶことができます。

 

[高速・安全・継続]頻繁な協調と統合(Collaborate Integrate Frequently)

チーム内やチーム間でのコラボレーションと統合が貧弱だと、組織は危険にさらされます。これは、ソフトウェア開発における多くの問題の根本的な原因になっています。ソロワークは、知識サイロ(何かの仕組みを一人だけしか知らない)、より大きな欠陥、脆弱な問題の解決、より強い注意力の散漫と、より少ない規律(特に良いテストを書いたり、リファクタリングによる設計の改善に対する)を生み出す傾向があります。ペアリングとは、二人で一緒に仕事をし、ペアを定期的に交換することです。モブプログラミング(mobbing)は、三人以上で協力して、キーボード・マウスを「ドライブ」する人を定期的に交代する、開発に対するコミュニティアプローチです。ペアリングとモブプログラミングの両方が、学習のスピードを高め、価値のある結果を生み出す流れを加速し、重要なスキル・知識に対する危険な依存性を減らし、技術への容易な変更を可能にし、人々を最高に輝かせるものをもたらします。ディープソロの作業(深い単独作業)を可能にするチームもあります。彼らはコードレビューによる協調作業によって素早くマスターブランチに統合していきます。

 

[安全・高速]安全に失敗できる環境(Make it Safe to Fail)

あなたの会社に恐れの文化があるなら、どんなすばらしいプラクティスやプロセスもあなたを助けられません。最高の企業は、人々が実験、失敗、異議、そして彼ら自身が安全と感じる文化を育成します。デイブ・スノーデンは、小規模で安全な実験によって複雑なシステムに起きる大切な応答を得るのに役立つセーフフェイルプローブの利用を説きます。安全に失敗できる企業は、「学習する組織」です。 Etsy社は、その輝かしい例になります。最も最近入った新規社員の一人が、大切なCSSファイルを間違って削除してウェブサイトをダウンさせました。彼らは何をしたでしょうか? 彼らは、そのエンジニアに、重大な欠陥を発見した「三つ袖があるセーター賞」を与え、サイトをより柔軟性の高いデザインに修正しました。

 

[安全・継続]テストとリファクタリング(Test Refactor)

テストと設計はアジリティの本質です。モダンアジリストは、探索的テスト、自動テスト、(主に設計の活動であり、副次的にテストの活動でもある)テスト駆動開発や、いくつかの手動テストを実行します。Industrial Logic社でテストとリファクタリングの訓練・指導をしたモダンアジャイルコミュニティでの定量的な研究の一つでは、欠陥が八〇%以上減少しました。信頼できる高速で自動化されたソフトウェア動作チェックがあることは、プログラマが、コードの変更や欠陥の生成を恐れることが少なく高速に仕事ができるセイフティネットを持つことになります。リファクタリング(挙動を変えずに既存のコードの設計を改善する)は、設計が複雑になることを回避し、コードを簡単かつわかりやすく(したがって変更しやすく)する重要なプラクティスです。リファクタリングは「見直し」です。これは、ラテン語では再び見る(re-videre)を意味します。私たちはもっと学び、以前の作業の欠陥を発見し、コードの設計・読みやすさ・シンプルさを向上させるように努力することで見直しを行います。テストとリファクタリングは、共にチームのスピードに不可欠な存在であり、それゆえモダンアジャイルの重要な部分です。

 

[安全]人々への敬意と感謝(Respect Appreciate People)

安全の文化を確立するには、(役割、年齢、学歴、人種、性別によらない)心からの敬意と感謝が重要です。アンゼニア(Anzeneer)は、時間、お金、情報、評判、関係、健康を守り、人々を尊重します。コラボレーションアプリのSlackが、一ヶ月まるまるサービスにアクセスしなかったので、ある程度の金額を払い戻しましたというメールを送ってきた時、私は敬意と大事に思われていることを感じました。Alcoa社の前CEOであり、米国の財務長官であったポール・オニールは、組織が不断の卓越性を達成するためには、人々が何時でも誰にでも尊敬され感謝される文化を持たなければならないと述べました。Industrial Logic社では、DuePropsを使用して定期的に皆に感謝しています。

 

[安全・高速]非難しないふりかえりを指揮(Conduct Blameless Retrospectives)

セス・ゴーディンは、かつて「人々は失敗を恐れず、責任を恐れている」と言いました。ノーム・カースの二〇〇一年の古典的な本「Project Retrospectives: A Handbook for Team Reviews」に、「最初にふりかえりを試みたときに人々が最も露わにする恐れの1つは、儀式が非難と反論を撒き散らす否定的なグチのセッションになるというものです」とあります。ゆえに、ノルムは、ふりかえりの前に慣習的に読まれるかの有名な「ふりかえりのお約束」を定義しました:たとえどんなことに気付いたとしても、チーム全員が、その時点で知っていたことや彼(彼女)のスキル及び能力、利用可能なリソース、そしてその時の状況で最善を尽くしたのだと理解し、心の底から信じます。このお約束は、ふりかえりを学びに焦点を当てた安全な場になるように整えます。Etsy社のジョン・オルスポーは「Blameless Postmortems and a Just Culture」で、これについて書いています。エスター・ダービーとダイアナ・ラーセンは、「アジャイルレトロスペクティブズ 強いチームを育てる「ふりかえり」の手引き」という優れた本を書いています。

 

[継続]フローに集中(Focus on Flow)

モダンアジャイルは、タイムボックス(例えば、スプリントやイテレーション)による作業の連続的な流れを好みます。カンバンは連続フローを可能にします。カンバンボードを使用して、チームは作業をボード上で見える化し、重要な作業をボードに設けられた列を移すことでプルし、仕掛品を制限し、サービスの分類(緊急または正常な作業など)を補助し、ボトルネックを見える化して取り除き、開発中の価値を人々に流します。タイムボックス内でどれくらいの作業をするかを予測しようとする時間を費やしたり、ストーリーポイントの正確な値を考慮したり、魅力的なバーンダウンやバーンアップチャートを公開するために見栄えを良くしようとする必要はありません。これは、合理化されたアジャイル計画です。デイヴィッド・アンダーソンは、彼の極めて重要な著書「カンバン: ソフトウェア開発の変革」でそれを美しく表現しています。

 

[継続・高速・安全]継続的なデプロイとリリース(Deploy Release Continuously)

ケント・ベックはかつて、ティモシー・フィッツによる「不可能な一日五十回をやっている」という衝撃的なビデオを私に示しました(ああ、不運なインターネットプロバイダーはティモシーの素晴らしいビデオを失いましたが、彼はそれについてのブログを書きました)。ティモシーは、IMVU(リーン・スタートアップの発祥の地)が、一日に何回もプロダクション環境へ安全にデプロイすることによって、初期アジリストの想像をはるかに上回る継続的インテグレーション(CI)の実践をしていることを説明しました。CIのダイアルは十一に調整されました。継続的デプロイは、早期な速い実験(A / Bテスト等)を実現し、ユーザーが最も必要とするものをできるだけ迅速かつ安全に提供することを可能にします。これは、「コンセプトをキャッシュにする」までのサイクルを劇的に減らすので、私が好きな、リーンに影響を受けたプラクティスの1つです。ティモシー・フィッツは Industrial Logic社と一緒にCD(継続的デリバリー)のeラーニングコースを作成し、現在、モダンアジャイル・プラクティスに関する本を書いています。ジェズ・ハンブルとデイビッド・ファーレイは、このプラクティスの深い専門家であり、「継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化」の著者です。

 

[継続・安全]プロダクトコミュニティを形成(Form Product Communities)

適切な人がいなければ、人々を最高に輝かせるソフトウェアを作成することはできません。適切な人々は、プロダクトコミュニティを作り上げます。 デイビッド・シュマルツの言葉によれば、プロダクトコミュニティは「プロダクトに影響を与えたり、プロダクトに影響を受ける可能性のある人々」です。デービッドは、このようなコミュニティは「常に」あなたが思っているよりも大きく、ほとんどのプロダクトが直面する主な問題は「自分自身のコミュニティ意識の欠如」であると考えています。プロダクトコミュニティは、フロントエンド、バックエンド、ミドルウェア、およびUXチームに分かれておらず、独自のバックログを持ちます。プロダクトコミュニティはフルスタックであり、原始的なソリューションを、人々を最高に輝かせ、組織の成功に役立つ洗練されたプロダクトへと進化させる準備ができています。プロダクトコミュニティを形成することは、誰が何をどのようにすることが重要な結果を達成するのに不可欠であるのか認識するのに役立ちます。プロダクトコミュニティは、「憲章」において頻繁に定義付けと洗練化が行われます。

 

[継続・高速・安全]ソリューションを進化(Evolve Solutions)

ソリューションをすばやく進化させるには、人材とチームを組織して、何を構築し、協調し、統合し、開発し、リリースするのか計画する必要があります。モダンアジャイルな「お店」は、フィードバックからすばやく学ぶため、ユーザーにプロダクトや機能をすばやく提供します。「進化の設計」はこのような学習の鍵であり、ユーザーに価値をすばやく伝える最良の方法の一つです。また、プロダクトコミュニティ内やプロダクトコミュニティ間での協調と統合のリスクを明らかにし、修正するための非常に便利な方法です。

 

参考文献

Joshua Kerievsky, “Modern Agile”, https://www.industriallogic.com/blog/modern-agile/

今給黎 隆, 「モダンアジャイル」, http://www.slideshare.net/imagire/ss-64457130

CSP(認定スクラムプロフェッショナル)を取得しました

Takashi Imagire-ScrumAlliance_CSP_Certificate

認定スクラムプロフェッショナルとは、開発プロセスの1つであるスクラムに関して、実践をして、学んだことがまとめられ、深い知識があることを認定する資格です。研修やテストの受講で取得できる資格ではなく、認定スクラムマスターなどを取得した上で、今までの実践をドキュメントにまとめてレビューを受けなければなりません。

認定スクラムプロフェッショナルは、私が取得した時点で全世界で3738人、日本にいる人としては25人と、まだまだ少ない人数です。この段階で資格を取得できたことは、スクラムに関するアーリーアダプターとして他の方の参考になる人にならなければと身が引き締まる想いがします。

認定資格に関しては、資格を取得するために認定団体の収入になるポイント稼ぎをする必要があったり、「取らないと気になるけれど、取っても食べられない」という足の裏のご飯粒のような資格であることも確かでしょうし、資格を持っているからといって技能があるとは限らないなど、認定ビジネスの是非を含めていろいろなご意見があるかと思います。私にとっては、自分の周りの人で認定スクラムプロフェッショナルを持つ人が増えてきたというのもあるのですが、スクラムに関して、聞きかじりで導入して間違った運用をされているのを多く見るにつれ、適切な助言ができる存在になりたいと思い、資格の取得を決意しました。

この資格の取得には、今まで一緒に仕事をしてきた方々や、コミュニティなどでお会いした方々からのご協力、ご指導がなければ叶えられなかったものなので、こちらで改めて御礼をさせていただこうとおもいます。ありがとうございました。

また、認定スクラムプロフェッショナルを取得するにあたっては、伊藤さん(id:hageyahhoo)さんの「How to acquire CSP/「認定スクラムプロフェッショナル」の資格を取得する方法」を参考にさせていただきました。認定スクラムプロフェッショナルの資格取得は英語でやり取りされるため、日本語での情報は、申請をするにあたる敷居が下がり、心理的に大変楽に資格を申し込むことができました。ありがとうございました。

現在、認定スクラムマスター、認定プロダクトオーナー、認定スクラムディベロッパーを所持している方、もしくは取得を意識されている方は、実践することで取得できるこの上位資格を心に留めておいていただければと思います。

まだまだ未熟で、間違った発言などもあるかと思いますが、今後も資格の名に恥じないように学び、成長していきたいと考えております。これからもよろしくお願いいたします。

レイトレ合宿3?

皆様、レイトレ合宿ってご存知ですか?

絶滅危惧種(いい意味で)と思われているレイトレ人が一同に集まる会らしいです。

そんな会が来月の月末8/29(土)~8/30(日)に「レイトレ合宿3」という名前で開かれるらしいです。
私は残念ながら別の予定が入ってしまっていけないのですが、レイトレに興味がある人は参加してみてはいかがでしょうか?

という紹介だけでは悔しいので、ちょっとプログラムを組んでみました。

レイトレ合宿をみると、単純にレンダラを組めばいいのではなくて、レギュレーションに従って出力しないといけないとのことです。
特に次の2つは、時間がからむので少し厄介です。

  • おおよそ30秒毎に、レンダリングの途中経過をbmpかpngで連番(000.png, 001.png, …) で出力してください。
  • 15分以内に自動で終了してください。

ということで、30秒ごとにBMPを出力して、15分前には終わるレンダラを書いてみました(レンダラ自体の中身自体は、smallptや、eduptのほぼコピペです)。

https://github.com/t-pot/RayTraCamp3

逆に言えば、あとは「src/renderer/renderer.h」以下のレンダラを書き換えるだけで何とかなるので、レイトレ合宿に参加しやすいのではないでしょうか。

でも、こんな簡単なプログラムで、こんなきれいな絵が出るなんて、今の時代すごいね。

29

ゲームエンジン・アーキテクチャ第2版 も監修させていただきました

ゲームエンジン・アーキテクチャ 第2版が発売されました。
今回も、監修をさせていただきました。
といっても、元の訳がよくできているので、非常に短い時間で監修を行うことができました。
また、前回同様に湊さんにも行っていただいたので、安心して作業ができました。

見逃している間違いがありましたら、私の責任です。ごめんなさい。教えていただけると助かります。

ゲームエンジン・アーキテクチャ 第2版

変更された点についてですが、下に書き出してみました(全てを書き出したわけではないので、参考までに)。
第1版から第2版への変更は、5年たったということで、PS3(アンチャーテッド 黄金刀と消えた船団)世代からPS4(The Last of Us)世代へのアップデートが主ですが、将来の課題であったオーディオの項目も追加されています。また、C++11についてもページをとって説明されています。サンプルコードもそれに合わせてきちんと修正されてるのが素敵なところです。

個人的に良かったのは、第1章の最後。リソースに関するデータベース利用やwebの管理画面の話が追加されていて、ソーシャルゲームの人にとっては当然かと思いますが、コンシューマゲームだと、あまり導入が進んでいないところだと思うので、それが、ノーティドッグでは着実に導入されている点にさすがだなぁと感じました。

また、もうひとつは、++pじゃ無くてp++にノーティドックではコード標準を切り替えたというお話。おっさんプログラマは、(あえて読み難い)プレインクリメント演算子を使うように仕込まれてきたと思うので、この変更は以外に感じるのではないでしょうか(詳細は本文で!)。

他にも、キビバイトとか、知らないネタもあったので、第1版を買われた方も新たな気持ちで楽しめるのではないでしょうか。

本の値段は高いと感じられるかも知れません。しかし、私は、第1版が品切れになってから、若手に「とりあえずこれを読んでおけ」と指示する本がなくなって困った経験をもってますので、販売されている内にお買い求めいただくのが吉かと思います。
修正された項目は多いので、1つ1つが詳細に解説されているわけではないという点で過度な期待は禁物ですが、興味がある項目がありましたら、ぜひ、手にとってみてください!!

[非公式&適当] ゲームエンジン・アーキテクチャの第1版から第2版での変更点

  •  全体的な変更
    • 解説するゲームエンジンのベースが「アンチャーテッド」から、「アンチャーテッド+The Last of Us」に拡張
    • 主なターゲットがPS3, Xbox 360からPS4, Xbox Oneに変更
    • 画像など、最新の事例に差し替え
  • 第1章 イントロダクション
    • 「プレイヤー主導コンテンツ」について追加
    • エンジンの例として、DICEのFrostbite、CryENGINE、ソニーのPhyreEngine、Unity、プログラマではない人向け2Dゲームエンジンが追加
    • 「PS4のコアダンプ機能」について追加
    • UE4の3Dオーディオレンダリングエンジンの紹介の追加
    • 「リソースデータベース」について追加
    • 「Webベースのユーザーインターフェイス」について追加
  • 第2章:仕事用ツール
    • 複数スタートアップのデバッグについて間違い修正
  • 第3章 ゲームのためのソフトウェアエンジニアリングの基本
    • 「C++11」について追加
    • 「キビバイト」について追加
    • 「パイプライン、キャッシュおよび最適化」について追加
  • 第4章 ゲームのための3D計算
    • 「擬ベクトルと外積代数」について追加
    • 「quaternionの成分表記」について追加
    • 「デュアルクォータニオン」について追加
    • 「平面の方程式」について追加
    • 「gccのvector型」について追加
    • 「SSE組み込み命令を使ったコーディング」について追加
    • 「SSEドキュメント内の専門用語」について追加
    • 例として出したコードにconstを追加して改善
  • 第5章 エンジンサポートシステム
    • 「プレインクリメント演算子→ポストインクリメント演算子」推奨に変更
    • 独自仕様のコンテナクラス作成の利点に「並列データストラクチャのコントロール」を追加
    • 「UTF-32、 UTF-8」について追加
    • 「char vs wchar_t」について追加
    • 「WindowsのUnicode」情報の更新
    • 事例として、ノーティドッグのローカリゼーションツールについて追加
  • 第6章 リソースとファイルシステム
    • SSDについて追加
  • 第7章 ゲームループとリアルタイムシミュレーション
    • 「スクリーンティアリング」について追加
    • PS4、Xbox Oneについて追加
  • 第8章 ヒューマンインターフェイスデバイス(HID)
    • SIXAXISからデュアルショックに変更
  • 第9章 デバッグおよび開発のツール
    • Redisを使ったTTYチャンネルを管理について追加
  • 第10章 レンダリングエンジン
    • 「浮動小数点数深度バッファ」について追加
    • 「GPUの歴史の概要」にコンピュートシェーダ追加
    • 「PS4のシェーダリソーステーブル」について追加
    • 「OIT」について追加
    • バンプマッピング、ディスプレースメントについて追加
    • 「物理ベースのシェーディング」について追加
    • 「空のレンダリング順序」について追加
  • 第11章 アニメーションシステム
    • モーフターゲットの頂点数の増加について追加
    • 「リターゲット・ポーズ」について追加
    • 「PlayStation 2での最適化」を削除
    • 「自動アップデート」のツールについて追加
    • UE3からUE4の例に変更。(加算ブレンディングができない記述の削除)
    • IKの目標点に動的なオブジェクトを追加
  • 第12章 コリジョンと剛体力学
    • PhysXでAPEX情報について追加
    • PhysX、Havokでサポートプラットフォーム追加
    • Unrealエンジンの物理的マテリアルシステムについて追加
    • ノーティドッグでの弾丸処理について追加
    • 「高度な物理的要素」に、物理によるオーディオの合成、GPGPU追加
  • 第13章 オーディオ
    • 章自体が新規追加
  • 第14章 ゲームプレイシステムの概要
    • 「特別なオブジェクトのタイプ」について追加
  • 第15章 ランタイムのゲームプレイ基本システム
    • 「PlayGo」について追加
  • 第16章 まだやることがあるってこと?
    • 「オーディオ」について削除
    • 人工知能について修正

無料で継続的な出版の環境を作成してみました

無料な継続的出版システム t-ceremony を公開しました。(スライド資料)
画像

  • t-ceremony?

オライリーさんや技術評論社さんは、GitHubを使って、プルリクでの編集作業や即時の出版物の作成などができるようになってきます。
そのような Re:VIEW による出版物の作成を、Bitbucket と wercker を使って、無料で実現するための仕組みです。

  • 本を執筆する敷居を下げたい

先日、知り合いと「本書いてみたいね」と、いう雑談をしていました。
今までの経験から、ある程度、きちんと進めてから出版社に話を持っていくような形にしないと、立ち消えになりやすいと感じており、執筆環境を整えようかなぁと考えていました。
以前、本を書いた際はwordを使っていたりしたのですが、ページ数が増えると編集に難儀したり、複数人で作業することを考えると、どうしてもバージョン管理は欲しいと感じていました。
そのような中、別の人から、「Re:VIEWは、オライリーさんでも使っているし、いいんじゃない?」という情報を小耳にはさみました。
確かに、Re:VIEWは、マークアップ言語でシンプルにかけるので、執筆も編集も楽かなぁと思いました。

ただ、セットアップになかなか苦労しました。
自分の環境では、Re:VIEWの公式ドキュメントのクイックスタートガイドをそのままなぞるだけでは上手くいかず、いくつかのサイトをググって、解決の糸口を見つけることができました。
それが、私だけならいざ知らず、他の人も同じように環境を整えるのか!?
そして、自分はMBAで他の人はWindowsを使っていたりと、環境整備のサポートで自分に負荷がかかるのは目に見えていたので、頭を抱えていました。

こんな環境の構築は、環境設定に詳しいフルスタックエンジニアならいざ知らず、コンピュータに詳しくない人なら心が折れるなぁと、感じました。
環境構築の技術に詳しくないと執筆できないのは完全に間違っているので、何とか環境構築の仕組みを楽にして、もっと多くの人に執筆のための気持ちを持って欲しいというのが今回の動機です。

  • 継続的出版の仕組みを手軽にしたいと思った

で、実際にどうするかいろいろと探しました。
Macでの環境構築は調べれば解決方法が見つかりそうだなぁと感じたのですが、Windowsの方があまり情報を見かけませんでした。
もちろん、それほど難しくはないだろうなぁとは思いましたが、それを検証するのも面倒だし、何よりWindowsの環境がどんどん汚れていくのは嫌。
ということで、クラウドでできる方法はないかという考えにだんだんと流れていきました。

そんな中で見つけたのが「[ReVIEW Tips] DockerでRe:VIEW–Qiita」という記事でした。
メンテナーの高橋さんによる記事ですが、Re:VIEW用のDockerfileが公開されていて、中身を見ると比較的簡単なスクリプトで書いてあったので、これなら、ubuntuが動いている環境なら実行できると勝ちを確信できました。

後は、無料で使えるCI探しです。
リポジトリ管理は、無料でプライベートリポジトリが始められるBitbucketと決めていたので、Bitbucketが使えるCIを探しました。
CIのサービスは、プライベートリポジトリは有償なものが多く、「Magnum CI
と「wercker」を見つけられた中、werckerの方が情報が多そうだったので、
こちらを使ってみることにしました。

いざ使ってみると、ビルド時間の制限がきつかったり、ビルドもエラーを起こしたりと、いろいろとあったのですが、何とか解決できて、これで比較的楽に環境が作れるかなぁと喜んでいたのでした。

で、仲間内だけで盛り上がっていたのですが、「GitHub Kaigi」で、WEB+DB PRESS編集部の稲尾さんが、「GitHubで雑誌・書籍を作る」というタイトルで、盛り上がっていたので、公開してみることにしました。
(稲尾さんの記事は、環境よりも編集の運用に主眼が置かれていて、必見だと思います。)

  •  便利な執筆のツールと信じています

ということで、実際にリポジトリの中身を見ると、単なるwerckerの設定ファイルしかなく、技術的に優れているわけでもありません(というか、適当に作ったので、ひどいもんです)。
名前も偉そうに「t-ceremony」とつけさせていただきましたが、これはシステムを呼ぶ際に識別できるようにしておいた方が良いと考えたぐらいで、世界制覇とかたいそうな野望もありません。

どちらかというと、リポジトリの中身自体よりも、Slideshareに上げた資料を見ていただいて、設定方法を知っていただくことに価値があるのかなと、思っています。

今回使わせていただいているサービスも、いつ有償になるかわかりません。ただ、その際に他のシステムに移る時でも、今回の仕組みが役に立つのではと信じています。

もちろん、無償が素晴らしいというつもりは全くなくて、今回の物は、あくまでも導入を楽にするためのサービスで、本格的になってきたら、きちんと有償プランなどを検討しましょう。
また、各出版社、編集部でやり方があると思いますので、実際に本を出すときには、それぞれの出版社のやり方に沿うのがベストだと思います。

  • 最後に

執筆となると、どのようにして良いかわからない方も多いと思いますが、微力ながらも、そのような方へのサポートとなれば良いなと思っております。

これからもよろしくお願いいたします。

  •  注意

現時点では、Re:VIEW でスクリプトを実行できてしまうようですので、不特定多数の方によるmergeは避けていただくのが望ましいとのことです。