UE4でわかるゲームの作り方【ウォーキングシミュレータ編】

2019年3月16日 02:06

以下の記事は某ゲームメディアDFNGに向けて送ったものだが、確認の連絡から1カ月以上経っても公開に関する話がこない（原稿料は出るらしい）のでnote上で公開することにした。

読者の方々はゲームを作りたいと思ったことはないだろうか？幼少期からゲームをプレイしつづけて、その影響でゲーム開発に興味を持つのもそこまで珍しいことではないだろう。筆者もそのような人間の1人なのだが、プログラマーを目指して大学に入るもプログラミングにさっぱり適応できずにくすぶってしまう状態に陥った（プログラミングを学ぼうとする人がこうなるのはわりと”あるある”らしい）。

とはいえ、そんな筆者のような存在にとって救いの手がUnityやUnreal Engine 4（UE4）といったゲームエンジン（ゲーム開発支援ソフト）である。2010年代後半に入ると商用にも使われるゲームエンジンがほぼ機能制限なしの状態で個人利用できるようになり、インターネットを上手に使えば自分の目的に応じてノウハウを持つ様々な企業や個人による解説ブログを読むことができるようになった。

半ばツギハギのような状態でも素人がそれなりの形にまで持って行けるのはモチベーションに繋がるし、いちゲーマーとしても自分でゲームを開発することで普段プレイするゲームの仕組みを知ったり想像を巡らせられるようになる意義のある行為だと思う。そこで今回はゲームエンジンのUE4を用いて「ウォーキングシミュレータ」を自作することでゲーム開発の流れを実際に体験してみた。

手段と力量を見極めよう

自作ゲーム開発では「素人が作業量や製作期間がデカいゲームの開発を始めると確実に完成しない」と昔から言われている。独力である程度プログラミングを読んだり書いたりできる人ならともかく、そうでもない筆者のような人であればテンプレート（ひな形）が存在するジャンルで短いゲームを作るのがオススメである。そこで筆者はひな形として「ウォーキングシミュレータ」を選んだ。

ウォーキングシミュレータは誕生したばかりで正確な定義がない奇妙なジャンルだ。一見するとFPSゲーム（から銃を撤去したもの）のように見えるが、あえて言うと「ゲームの舞台が無人である」「誰かが残したドキュメント（日記やメモ、ボイスログ）を収集することで過去への思いを馳せる」という共通点があれば恐らくウォーキングシミュレータである。

例えば筆者がクリアまでプレイしたウォーキングシミュレータとして「Gone Home」「Firewatch」「TACOMA」があるのだが、Gone Homeは無人の家を探索しながら主人公の妹の日記に書かれた独白を聞き続ける。Firewatchはアメリカの国立自然公園を探索しながら無線機越しに顔の知らない上司と対話を続けて関係を深め、TACOMAは無人の人工衛星に残された乗組員の記録から何が起きたのかを探るといった内容である。これらのゲームの例から先述のような「無人」「話を聞く・文書を読む」といった共通点があることを察してもらえると思う。

筆者がウォーキングシミュレータを選んだ理由は「一人称視点だとプレイヤーの見た目を作る必要がなく、無人なので動くキャラクターを用意する必要がない」「FPSのテンプレートから銃を取り除けば移動操作のできあがり」という点、つまり作業量を極力抑えたいからだ。また、先述のウォーキングシミュレータの例のように、どんなに演出が貧弱であってもシステムとして最低限「文章を読む」「音声を聞く」さえ実現できればウォーキングシミュレータと呼べる代物になるだろう。

このように一人称視点で銃器を使わずに探索を楽しむ（FIREWATCH）

作業量を決めよう

ゲーム制作に個人で挑むとなれば作業量は極力抑えるのが賢い戦略だ。ゲームに必要な素材はなるべく使いまわし、プログラミングに疎くてもテンプレートを改造するなどして自分の実力の範囲で実装できるように考えるのが望ましい。筆者の場合はゲームの制作・プログラミングにUE4、3DCGモデルの制作にMagicaVoxelとBlender、音楽・音声にフリー素材とSofTalkを用いた。以降はそれぞれ制作の必要な順番に説明していきたい。

大規模チームによって作られたゲームのように舞台を屋敷や人口衛星にしてまるごと作るのは無理なので、舞台はいっそのこと一つの部屋ぐらいのスケールに限定してしまう。当初は舞台として「自分の部屋」を考えたが、学校の教室は同じものが大量に並んでいるので少ない素材を使いまわすことで作りやすいことに気が付いた。

舞台が決まれば、学校をテーマにした文書や音声を用意する必要があるのだが、多くの人はいきなり架空の人物と会話を即興で作りだせるほどキャラクター創作には慣れていない。そのため、筆者の中学時代の部活など個人的な思い出を元に話を作るように美術室を舞台にすることを決めた。舞台が決まれば個人的な思い出にフィクションを交えて美化したり、自分の記憶を元におおざっぱにゲームの舞台の地形を設計したりすることから始めよう。

UE4で地形を作ろう

ゲームのシステムが大事なのはもちろんだが、完成形を想像するためにも最初は舞台の地形を大まかに作ってみる。操作性はFPSのテンプレートをそのまま使い、ゲームの地形となるジオメトリ（ブロック）を適当に配置すればそれっぽくなる。UE4の開発元のEpicGamesはゲームシステムがあやふやな状態でいきなりグラフィックを作りこむと仕様変更の際に無駄な工程が発生することから、ゲームシステムがある程度できている状態で地形をおおざっぱに作ってゲームプレイを設計する手法「グレーボクシング（ホワイトボクシング）」を推奨している。個人開発でもグラフィックから作るタイプの人は陥りやすいので先にある程度ゲームプレイの内容の検討をつけると良いだろう。

以下の画像では図書室っぽい地形を作成し、机や本棚の代わりに白いボックスを配置することでイメージを膨らませている。

以上のステージをFPSのテンプレートでプレイしてみると以下のようになる。

この画像だけでも図書室だと言われれば部屋がどういう空間なのか想像できないだろうか？なお、この画像で使った図書室はボツになっている。

UE4でゲームシステムを作ろう

筆者としてはゲーム開発における一番の難関はゲームシステムのロジック作成だと考える。UE4には関数の機能を持つ”ノード”と呼ばれる四角形を線で繋ぐことでプログラムを作成する「ブループリント」というビジュアルプログラミングを利用することができ、プログラミングに弱い筆者としてはこれがUE4を採用した大きな理由だ。とはいえ、ブループリントを使うにもある程度のロジック作成能力が必要なので最低でもUE4公式のチュートリアルを一度は通して学習する必要はあるだろう。もし処理が分からなくて詰みそうになったらとにかくググりまくって調べよう。自分がわからないことは今までの誰かもわからなかったことだから、ほぼ必ず前例と解説があるはずだ。それでも分からなければSNSや公式フォーラムで質問をするのもアリだが、失礼のないように接することを心がけよう。

今回作成するウォーキングシミュレータはFPSの操作のうち「移動」「カメラ操作」が流用でき、自前で用意する必要があるのは「アイテムを使う」「画像を表示」「音声を再生・字幕を表示」の3つだ。これらの機能を使う流れは以下の順番のように考えると分かりやすいと思う。

必要な手順
1.カメラ（プレイヤーの目線）から光線（レイ）を発射
2.光線がぶつかるとアイテムが反応
3(a).画像を表示する
3(b).音声を再生しながら字幕を表示する

それでは順番に軽く説明しよう。

1.カメラ（プレイヤーの目線）から光線（レイ）を発射
2.光線がぶつかるとアイテムが反応
FPSゲームでアイテムを拾ったり銃器で弾を発射する場合、カメラ（プレイ画面の中心）から光線を発射し、対象にぶつかっているか・対象までの距離がどれぐらいかで処理を判定することがある（シューターによっては光線ではなく物理的に弾を発射して判定することも多い）。もちろんUE4にも光線で対象を判定する「LineTrace」機能があり、光線の開始・終了地点を指定すればOK。後はLineTraceByChannelに「光線がぶつかるとイベントが発生する」というインターフェース（具体的な処理ではなく、名前でパーツとパーツの処理をつなげる仕組み）を用意して、対象がインターフェースを持つアイテムであればイベントが発生するようにできる。

3(a).画像を表示する
手順1、2のLineTraceByChannelがアイテムに繋がると、アイテム側の処理を起こすことができる。画像を表示したい場合はウィジェット（UE4におけるUIの呼称）を作成し、アイテム側で指定した画像データをウィジェットに代入してから画面にウィジェットを表示させよう。なお、逆に画面から画像を消すための処理として筆者はクリック時に強制的に全UIを削除するようにした。この処理だと画像とは関係のない他のUIも巻き込んで削除してしまうので、もっとスマートな処理はぜひ自分で考えてみてほしい。

3(b).音声を再生しながら字幕を表示する
ブループリントの作り方はおおよそ手順2と同じだが、今度は「配列」「ループ処理」というなんだかプログラミングっぽい概念が必要になる。でも慌てないでほしい、これはただ単に「音声とテキストが入っているデータを繰り返し再生する」だけの処理だ。

ブループリントには名前の通り「Loop」というループ処理をしてくれる関数があるのだが、残念ながら音声データのようにループごとに時間の長さが異なる（当然だが喋る内容によって音声の時間の長さは変わる）処理には向いていないのだ。今回はループ毎に時間の長さを指定できる関数「Set Timer」を使おう。以下の図をざっくりと説明すると「音声データの数だけループを繰り返し、ループごとに音声を再生しテキストをUIに代入」「ループ回数が音声のデータ数を超えたらループ終了」となる。ブループリントが一見複雑そうでも説明を聞けばそこまで難しいことはしていないと分かっていただけるのではないだろうか。

なお、以上の図のブループリントは筆者が実際に作ったものよりも見やすくしたものであり一部機能を省略している。より具体的な機能、例えばアイテムを既に使用しているかやアイテムを見つけた数、音声が複数同時に再生されないようにする処理などを追加してみるとゲームとして活かせるシステムになるはずだ。

グラフィックの素材を作ろう

近年では誰でも無料で使える3DCGモデリングツールとして「Blender」の人気が高まっているが、一度でも手を出した経験があればBlenderを覚えるのは面倒くさいことを実感できると思う。そこで、今回仕様するのはボクセル系ツール「MagicaVoxel」だ。ボクセルとは立方体のブロックを用いた枠組みのことで、マインクラフトのようにブロック状の3DCGモデルを簡単に作ることができる。MagicaVoxelは日本での人気も高く、ググれば情報もいっぱい出てくるのでありがたい。今回は「MagicaVoxel」から「Blender」を経由して「UE4」に出力する手法を採用しており、これも検索すればいっぱい情報が出てくる。3DCGモデルの出力形式はそれぞれ違った方法があったり色味が異なったりするので自分の好みに合わせたモノを探してみよう。

BlenderではMagicaVoxelで作成した3DCGモデルの縮尺を調整（初期だと1ブロックあたり1mになので縮尺を100で割って1cm単位に変換）し、UVマップ展開をした後に出力したものをUE4に取り込もう。なお、3DCGモデルのUVマップ展開をしないで出力するとUE4側で物体が真っ黒になる現象が発生するので注意したい。以下の図ではボクセルでも椅子や机が良い感じに映っていたり、教卓と黒板のUV展開を忘れたせいで真っ黒になったりしていることが確認できる。

また、天井や床、壁などに色を貼り付ける「テクスチャ」も忘れてはいけない。筆者は好みでドット絵エディタ「Aseprite」を使って手打ちしたが、インターネットで検索すればフリー素材のテクスチャが出てくるので各自調整して使うとよいだろう。また、テクスチャはそのまま使うのではなくUE4で「マテリアル」に変換することでより細かい調整ができる。以下の図ではマテリアルエディタで「ベースカラー（テクスチャ画像）」に「メタリック（金属光沢）」「スペキュラ（光の反射）」「ラフネス（表面の粗さ）」「エミッシブカラー（発光）」「ノーマル（表面の凹凸）」の情報を付け加えている。近年のゲーム開発ではこのように物理的パラメータを調整することでテクスチャを管理しており、これを「Physics-Based Rendering（物理ベースレンダリング）」と言うそうだ。ここは調整次第でゲーム全体が面白い見た目になるのでついつい触ってしまう工程でもある。

また、空間に天井が出来るとディレクショナルライト（太陽光）が遮られて画面が暗くなってしまうのでライトの存在が欠かせない。しかし、このライトが中々の曲者であり、筆者も苦労した上に具体的な解決策はよくわからなかったので説明を省略させていただく。

サウンドを作ろう

筆者はサウンド作成スキルがないのでフリー素材サイトの効果音やBGMを利用した。ゲーム用の効果音サイトは検索すれば沢山出てくるため、必要な素材を見つけたら利用規約を正しく理解した上で使おう。

また、ウォーキングシミュレータにはボイスログ（音声による日記）が欠かせないのだが、筆者自身や知り合いが台詞の収録をするのは機材の費用や時間がかかって面倒だ。そこで、今回はゆっくりボイスが使えることで有名なフリーのテキスト読み上げソフト「SofTalk」を利用した。今回必要な機能は音声をwav形式で出力することなので、VOICEROIDやCeVIOといった商用のテキスト読み上げソフトを持っている場合は利用規約を守った上で利用してみると品質が向上するのではないだろうか。

画像・音声のネタを考えよう

以上の工程ではゲームシステムやグラフィックを中心に作成してきたが、ウォーキングシミュレータはストーリーが全てのゲームなので画像・音声のネタが最も重要である。例えば、筆者は漫画部に所属していたので通常のウォーキングシミュレータでは見られない漫画・イラストのようなドキュメントを置いてみたり、部活動のメンバーの視点を想像してボイスログを作成してみた。

なお、ネタ出しで注意したいのはゲームはフィクションなので現実に起きたことをありのままさらけ出す必要がないことである。筆者の場合は学生の頃の思い出であり、そのまま書き起こすと内輪ネタで他人には伝わりにくかったり当時の知り合いのプライベートを侵害してしまう可能性も十分にある。ゲームのストーリーはゲームプレイにとって都合がいい創作を心掛けるべきだ。

作ったゲームをプレイしてみよう

以上の工程が完了すればゲームとしての体裁が整ってプレイできるようになっているはずだ。以下の動画は実際に筆者が作成したウォーキングシミュレータの3分程度のプレイ動画である。

あまりプレイ時間のボリュームは確保できなかったが、ゲームの動作はいかにもウォーキングシミュレータのように見える。もっと時間をかけて画像・音声のネタを練れば意外とそれらしいストーリーを語れそうな予感さえある。もし自分だけでなく他人にも共有したいのであれば動画サイトやSNSでプレイ動画として公開したりitch.ioといったインディーゲーム専門サイトで体験版を配信してみるのも良いだろう。

これより、プログラムに慣れない人間でもUE4を用いることでウォーキングシミュレータを作る過程を紹介できた。ゲームを作りたい人のすべてがウォーキングシミュレータに興味を持っているとは十分承知しているし、ここで紹介したのはゲーム開発における様々なツール・手段ごく一部である。しかし、ゲームを作りたいけど作ったことがないという人は時々この記事を思い出して「プログラミングができなくてもジャンルを狙えば意外と作れる」ということを思い出してほしい。一人でも多くのゲーム開発を志す人の背中を後押しできれば幸いだ。

追記：ファイルをダウンロード可能にしました（2020年9月26日）

この記事で取り扱ったゲームをitch.ioでダウンロード可能にしました。制作途中で放棄したものなので独自に改善していただければと思います。

https://pasonco.itch.io/japanese-school-walking-simulator

支援していただけると、そのお金が私のゲーム購入資金となります