それでは始めていきます。
まずは、開発環境の話から。

僕の環境はWindows7(64-bit)、Visual Studio 2017 Communityです。

以下、visual studioを使ってない人向け

MicroSoft Visual Studio 2017 ダウンロード
このリンク先のページからVisual Studio 2017のインストーラーをダウンロードしてきます。

そのインストーラーを起動すると以下のようなウィンドウが出てくるので左上の Visual Studio Community 2017 のインストールボタンを押します。

スクロールして中段あたりにあるC++によるゲーム開発にチェックを入れ、右側にあるWindows 10 SDKにもチェックを入れます。

その他インストールしたいものがあればチェックを入れて最後に右下のインストールボタンを押します。

インストールには大分時間がかかると思いますので、お茶でもすすりながら待ちましょう。

ちなみに、SDKとはSoftware Development Kitの略でソフトウェア開発のためのツールやデータ、技術文書などのことです。
Windows SDKの8.1以降ではDirectX SDKが統合されています。それ以前でDirectXを使う場合はDirectX SDKを別途インストールする必要があります。

インストールが終わったらVisual Studio 2017を起動します。

左上のファイル(F)から新規作成(N) → プロジェクト(P)を押して新しいプロジェクトを作成します。

ここでいうプロジェクトとは企画とかビジネス的なことではなく、プログラムファイルやそれらを動かすために必要なファイルなどをひとまとめにした単位のことです。

新しいプロジェクトを作成するウィンドウが出たら左側のVisual C++を展開してWin32をクリック、中央でWin32プロジェクトを選択します。

C++言語の勉強でコンソール画面に文字を表示させたりしたことがある人ならWin32コンソールアプリケーション(あるいは空のプロジェクト)でプロジェクトを作ったことがあるかもしれません。

右下のソリューションのディレクトリを作成のチェックを外し、名前をGameProgrammingとでもしておきましょう。

ソリューションとは複数のプロジェクトをまとめた単位だと思っといてください。

次にWin32アプリケーションウィザードが出てきます。
次へを押して設定画面に行き、アプリケーションの種類が、Windowsアプリケーションになっていることを確認し、空のプロジェクトにチェックを入れます。

最後に完了ボタンをクリックしてプロジェクトが作成されます。
次にこのプロジェクトにソースファイルを追加します。

右側のソリューションエクスプローラーにあるGameProgrammingの中にあるソースファイルを右クリックして追加をクリックし、さらに新しい項目をクリック

さて、それではコーディングを始めていきたいところですが、
その前にプロジェクトの設定をします。

VisualStudioのメニューバーからプロジェクト > プロパティをクリック

構成をDebugに変更し、
左側の構成プロパティからC/C++ > コード生成をクリックし、ランタイムライブラリをマルチスレッドデバッグ(/MTd)に変更

右下の適用ボタンを押したら今度は構成をReleaseに変更
ランタイムライブラリをマルチスレッド(/MT)に変更します。

これらの設定についての解説はMicrosoftの公式サイトをお読みください。
msdn.microsoft.com/ja-jp/library/2kzt1wy3.aspx

他にも変更する部分が出てくるかもしれませんが、その時になったら適宜説明していきます。とりあえず今はこれで適用ボタンを押した後OKボタンを押します。

これでプログラミングする準備が整いました。
早速やっていきたいのですが今回はここまでとします。

←前に戻る　　次へ進む→

3年の前期にあるゲームプログラミングの講義でDirectXを使ったゲームプログラミングをやらなくなってしまったので、代わりと言ってはなんですがこちらでやっていこうと思います（僕の備忘録を兼ねてます）。

講義のほうではC++とDirectX9を使っていましたが、どうせなら新しいこともやりたいのでDirectX11を使っていきます。そして、目標は簡単な2Dゲームエンジンの作成と縦スクロールシューティングゲームの完成を目指します。出来れば3Dもちゃんとやっていきたいと思います。

ここ最近UnityやUnreal Engineといった、高性能で誰でも簡単に、しかも無料で使えるゲームエンジンがいろいろあり、どんどん進化を続けています。おかげでゲーム開発の敷居が下がり、専門的な知識があまり必要なくなってきています。

つまり、そのようなゲームエンジンでは、描画や衝突判定など、どのゲーム開発でも共通するような部分は覆い隠され、ユーザーは小難しいことを気にすることなくゲーム作りに専念できるということです。

しかし、そういったコアな部分をどのようにプログラミングしていくのか全く知らないままゲームを作っていくというのは良くない気がします。

ゲームがどのように動いているのか知っているのと知らないのでは、きっと大きな違いがあるはずです。難しいことはなるべく触れないようにしたいのは山々ですが、完全に知らないまま、というのはなんだか恰好悪いと思います。

結局は自己満足ですが、お付き合いいただけましたら幸いです。

次へ進む→

とりあえずリクナビで気になる企業にプレエントリーしまくってます。
明日リクナビのイベントで幕張メッセへ行く予定。あぁ…本番でもないのに緊張するぅぅぅ～。

自分に自信が持てません。大学で学んだことも今振り返れば大したことなかったのではとか考え始めてもうダメです。人生終わりムード全開です。

第3回ゼミではいつものように前週の振り返りとやったこと、今後の予定を確認し、自分がかかわるプロジェクトの進捗状況を仲間と共有しました。

自分はやることをまとめ、今後のスケジュールを立てたのでそれを発表、
現在は新機能のコーディング作業をしているはずです、たぶん。

どっかに精神と時の部屋ないかな～。

p.s.　その後（2017/4/4）、1週間ぐらい精神と時の部屋的な考える時間がありまして、就活終了宣言しました！

第５回のゼミについて振り返ります、が、今回自分の進捗よりもベイビーチームのフランス遠征振り返りに大きく時間が割かれました。

情報共有が上手くいってないとか、休憩の取り方や取らせ方が悪いとか、現場にいないと分からないことが多かったですが、はたから見ていて一番感じたことはリーダーの決断力が弱いのではないかな、ということです。

決断には２つの柱があると思います。

１つ目は選択肢を作ること

２つ目は選択肢を絞ること

です。

選択肢を作るというのは、何か決めなければいけないときに決めるための要素を集めることです。これはリーダーだけがやることではなく、メンバーが案を出し合ってより良い選択肢を見つけるものです。

選択肢を絞るというのは、出てきた選択肢から最も適切なものを選ぶことです。選ぶということは一見簡単なようで意外と難しいと思います。その場その時に合わせた案が時間がたつとうまくいかなくなることもあります。将来どうなるかわからないことに対してアイデアを出すのは未来を見通す力がないと難しいです。

リーダーはメンバーを引っ張り、プロジェクトの先頭に立つタイプと、メンバーをうまくまとめてプロジェクトを中から、もしくは後ろから押していくタイプがいます。

ベイビーチームのリーダーはどちらかというと後者な感じがします。みんなをまとめるタイプのひとはプロジェクトの進行を調整することがマストですが、時には「こうだ！」と、がっつり押しやる力も必要で、今のリーダーにはそのパワフルさが足りないな、と思います。だからこそとっつきやすい人ではあるのかもしれませんが。

あまり関係ない自分が思ったことをつらつら書いただけですが、これからもベイビーチームの成功を祈っています。もしかしたら自分もプログラマとして関わるようなこともあるかもですけどね。

多重化映像技術ワークショップの第3回と第4回をまとめて終わらせました。
他人の作った物を見るだけでも楽しいですが、それを自分でやってみるのはもっと楽しいです。

さて、今回はシェーダー、特にフラグメントシェーダーをもう少し詳しくやりました。フラグメントシェーダーとは表示する色や明るさ、合成や出力を司るものって感じですかね。

第3回ではフラグメントシェーダを使って画像のフェードアウトをやってみました。画像を2枚用意し、最終的な出力の画素値を時間が経つにつれて1枚目の画像の画素値から2枚目の画像の画素値に近づけていくものです。

ちなみに僕は梅干しが苦手です。

こちらがシェーダーのコードになります。

uTimeが経過時間で、時間が増えていくとcolorAからcolorBに近づいていく感じです。この時間の数値は板ポリにアタッチされたスクリプトから渡されているようです。

updateという関数は毎フレーム呼ばれる関数で、引数のdtはおそらく1フレームの経過時間(たぶんDeltaTimeの略)でしょうね。
this.timeに1フレーム毎の時間を足していって経過時間としています。

変数tにこの時間を保存。

このthis.timeが10になったら、つまり10秒たった場合0にリセット。

このスクリプト内にあるマテリアル（今回はシェーダーかな？）にuTimeという名前の変数として変数tを渡しているっぽいです。たったこれだけ。

初期化の部分はちょっと面倒なので割愛しますが、ざっくりいうと画像やシェーダーの定義、シェーダーで使う変数の定義とかやってるんじゃないかと思います。

第4回ではついに多重化の実装をしました。

具体的にどうやるかは書けませんが、シェーダーでちょちょいのちょいっと(笑)

第3回のおにぎりの画像を使ってやってみましたが、どうもうまく映らなかったので別の画像にしました。ネットから拾ってきたロックマンゼロのサントラ1と2のジャケットの画像です。(著作権的に問題があったら消します。)

ちょっとわかりにくいかもしれませんが、メガネの部分だけロックマンゼロ2のサントラのジャケット画像になってます。
そしてやっぱり実装中にソースの写し間違いが多発しました。
先輩からコード貰ってコピペした方が確実でしょうが、見ながら自分で書いたほうが理解は深まるはず、と信じています。

これで多重化映像技術について藤澤先輩からの引継ぎが終わりました。
これぐらいのすごいことをこれから自分ができるのか不安でしょうがないですが、頑張っていくしかないので頑張ります。

以上で多重化映像技術ワークショップ終了です。藤澤先輩ありがとうございました。

今日は藤澤先輩による多重化映像技術のワークショップで多重化の歴史やPlayCanvasについて教わりました。第1回と第2回を終わらせることができました。

予定では第4回か第5回まで続くようです。

今までこの目で見てきたExPixelやExField以前のものについても知ることができて、進化の歴史を感じました。

また、PlayCanvasを久しぶりに触りました。3年前期のゲームプログラミング以来でしょうか。

アカウント登録すればwebブラウザだけでゲームを作れるお手軽さ

第1回で多重化映像技術の歴史とPlayCanvasの基本操作、
第2回でJavaScriptとシェーダーの触りをやりました。と言っても画像をxz平面に広がる板ポリに張り付けて表示させるだけですがね。

少し前に適当に作ったおにぎりの画像を適当に選んだので画面サイズにあってませんが、とりあえず表示させることができたので良しとしてます。

以下、実行結果リンク
playcanv.as/b/bgUtlMLf/

JavaScriptも久しぶりでした。Unityでもちょっとやったんですけどねぇ。
先輩のコードを書き写しましたが、スペルミスがいろいろあってちゃんと実行できるまで時間かかりました。

シェーダーの話を聞いたことはありましたが実際に触ってみるのは実はこれが初めてです。今まで何やってたんだ俺…。

シェーダーのコードについては先輩の話を聞いて写しただけで詳しくやらなかったので、自分で何をやっているのか考えてみました。

まずは頂点シェーダー

vertexって頂点ってことですよね（Google翻訳で確認）。
たぶん板ポリの頂点を使うためのコードだと思います。では読んでいきます。

attributeは属性という意味（のはず）。変数の種類かな？
vec3は3次元ベクトル、aPositionは名前からして位置でしょう。3次元ベクトルのx,y,zを使ってる感じか。
vec2は2次元ベクトル、aUv0はUV座標（画像を張り付ける位置）かな。

uniformは制服？統一とかって意味もあるそうですがよくわかりません。
mat4はmatrix（行列）の略で4×4行列だと思います。
matrix_modelは板ポリゴンのモデル行列、matrix_viewProjectionはビュープロジェクション行列だな。

varying…?　わからん。直訳は「変化する」らしいですが…。
vUv0、またUV座標ですか。

で、void main(void)　C言語のmain関数っぽいと思いました。引数なし、と。
vUv0にaUv0を代入してgl_Positionにビュー行列とモデル行列をかけた位置情報を渡しているんですね。

gl_Positionというのは調べたところ組み込みの変数で、この変数に情報を渡さなければいけないそうです。

では次にフラグメントシェーダー
fragmentとは欠片とか断片とかって意味だったか。
色についてのシェーダーらしいですが、やはりよくわかりません。

中身を見てみます。

uniformまでは頂点シェーダーで出てきました。
sampler2Dとは何だろうか。おそらく画像データから色情報を抽出したものかなと思います。

で、main関数

4次元ベクトル型変数のcolorに画像の色情報を代入
gl_FragColorにそのcolor変数を代入してますね。

colorにはたぶんRGBAの4要素が入っていると思います。
gl_FragColorはやっぱり組み込み変数らしいですが、頂点シェーダーと違って、絶対必要というわけではないそうです。
ただ、普通は色情報を使うので基本的には使うことになる変数だということみたいです。

今までゲームエンジンを使って難しいことを全然考えずに画像を表示させてきましたが、見えないところでいろいろやってるんですねぇ。ゲームエンジンの便利さにかまけてこういったところを疎かにしてしまうのは良くないと思いました。（小波感）

次回はこのシェーダーの詳しい話と多重化のためのコードをやるそうです。
いやぁ楽しみですなぁ！