UEでゲームを開発しているSig(シグ)氏。フリーランスとしてゲーム関連の制作、3Dモデル・アニメーション・楽曲などの制作を手がける。また、『 CRI ADX2でつくるUnreal Engine 4サウンドエキスパンション 』『 Unreal Engine 4 アクションゲーム ブループリント入門 』も執筆している
講演の題材に挙げた作品『 Link: The Unleashed Nexus RH (以下、LinkRH)』は、疾走感と浮遊感を重視したゲームスタイルを特徴とする、ハイテンポな3Dアクションゲームです。過去作『 Link: The Unleashed Nexus 』のコンセプトとおおまかなストーリーを踏襲しながら、 4倍から5倍以上 のボリュームでフルリメイクした作品として開発が進められています。
講演時点では、『LinkRH』体験版のリリースに向けて注力していると話していた
開発のコアメンバーはSig氏のみで、モデリング・アニメーション・プログラム・設計・音楽まで担当。キャラクターのイラストやBGMの一部(弦楽器)演奏は、外部の方に協力してもらっている
インディーゲーム開発における精神論
本講演は、「インディーゲーム開発における精神論」『「しくじり」事例紹介(プロジェクト編)』『「しくじり」事例紹介(技術編)』の3章で構成されています。
第一章の導入として、「インディーゲーム開発における最大の恐怖とは?」という質問が会場に投げかけられました。
頑張って作ってきたゲームデザインの破綻。ちょっとしたケアレスミスから来る致命的なバグ。一緒に作ってきた仲間がいつの間にか蒸発し、チームが空中分解してしまうこと。これらも怖いものですが、一番怖いものは別にあるといいます。
それは、心が折れてしまうこと。
「甘えでは?」と思われることを懸念しつつも、究極的にはこれに尽きるとSig氏は言います。
プロジェクト上で発生したミスは、よっぽどのことがなければ原因の特定も可能で、それを取り除けば解決できます。しかし、モチベーションや生活の破綻という問題が起きてしまうと、開発を続けることすら困難になります。ミスを特定して直すこともできなくなり、「次回」というチャンスも失われてしまいます。
Sig氏は、心が折れることを「 致命的な単一障害点 (※)」と評しました。
※ 「そこが動かなくなると全体が動かなくなる」ような箇所を指す
モチベーションは無限ではない 「開発したいけどモチベーションがない、どうしよう……」と思ってしまう問題は、開発者としては往々にして「ある」ことであり、常にモチベーションと向き合う必要があるとSig氏は述べます。
ありがちな例として、「スケジュールを立てている間は、やる気があったり気持ちに余裕があったりするので、モチベーションを無限だと思いこんで、 行動力というコスト を無視しがち」を挙げています。
モチベーションが下がりがちな例として、実際のプロジェクト内にあるブループリントが表示されました。
「毎日こういうカラフルなスパゲッティを作っている」と語るSig氏。こうした状況を目の前にすると、検証やバグ取りをつい後回しにしてしまいがちです。また、アンリアルエンジンに 追加された新機能を勉強しなきゃと思いながら、なかなか勉強のやる気が出ないこともモチベーション不足のもうひとつの例として挙げています。
このような場合の対処法は、開発ペースの鈍化を防ぐことと、「気を病んで開発中止してしまうことを防ぐ」ことだと言います。 「やる気が出ない、自分は本当は創作がしたくないのかな」「自分は創作に向いていないのかな」などと思う前に、自分のモチベーションがどんな状態にあるか、観察してみてほしいとのこと。
今の状態を見つめ直してみて、自身に些細なことでも異常を感じたら、それをエラーとして受け取り、現状のモチベーションの状態を見極めることが大事だそうです。 複数の書籍からの受け売りであると前置きしたうえで、Sig氏は「脳にはノリノリの状態とイヤイヤの状態があり、状態によって脳内で分泌される物質の種類・量が違うようだ」と話しました。
ドーパミンは意欲や集中力をもたらし、ノルアドレナリンはストレスや注意力をもたらすそうです。 作業に学びがなかったり、難易度が合わなかったりした場合、ドーパミンの分泌量が減ることで集中力が長続きしなくなるそうです。
これらの脳内物質のバランスがほどよく取れている状態が「ノリノリ」で、「ストレス成分が適度にあったほうが良いのは、意外であり面白い」と結びました。 これらの脳科学とモチベーションのトピックを総括し、「 精神論とは、精神論ではない 」とSig氏は結論付けました。
モチベーションがないのは、何らかのエラーが脳に起きている「現象」であるため、ほとんどの場合は取り除けるものだと思っておくと、気がとても楽になると同氏は話します。
脳の「モード」を切り替える 脳の状態を把握することには、「自分の脳が デフォルトモードネットワーク になっているかがわかる」というメリットもあるそうです。 「デフォルトモードネットワーク」とは、休憩・休息を取っているときや、ぼーっとしているときに起こる脳の状態を指します。
重要なのは、デフォルトモードネットワーク時は、 脳内で情報整理も行っている こと。つまり、リラックス時や睡眠時など、休息と同時に 脳の問題解決能力が高まっている 状態といえるそう。
続いて、脳のモードの種類について説明がされました。脳のモードは次の3つに分類されるそうです。
休息時には、脳の休息や整理を行う デフォルトモードネットワーク 。
周りの変化に注意し、物事を感知する「 サリエンスネットワーク」 。
集中している状態の「 セントラルエグゼクティブネットワーク」 。
モードの遷移は自動で行われるとのことですが、自身が抱えている問題を用意したままデフォルトモードネットワークに移行できれば、行動指針が立てやすくなるだろうとSig氏は考えています。
Sig氏の場合は、作業中に起きた問題を言語化しておき、睡眠中に脳に自動的に解決させるという方法をオススメしていました。
モチベーション向上につながる2つの手法 講演では、モチベーション向上に関する具体的な手法を2つ提案されています。
まずひとつは、1日の開発を完了したとき、 寝る前に行動記録をつける こと。
記録を付けるために1日を振り返ると「今日は開発が進んだ」と実感を得やすく、モチベーションが上がりやすくなるのだそうです。開発ペースの把握にもつながるため、記録を参照することでマイルストーンを修正するのにも役立つとしています。
そして「究極のモチベーションをもたらすもの」「究極の尻叩き」として、 イベントへの出展 を挙げています。
イベントは、自分では動かせない締め切りが強制的に設定されているため、開発せざるを得ません。試遊も可能なイベントともなると、当日の朝までビルドを作り続けることも多いそうです。
また、自分の作品のことを知らない方が先入観のない感想をもらえたり、プレイヤーの反応を直接見られたりと、イベント出展のメリットは計り知れないといいます。自分が想像もしていない感想がもらえた例として、Sig氏の作品を試遊した小学生ほどの子どもから「なんでこのゲームはジャイロ操作が使えないの?」と指摘されたことを挙げ、衝撃を受けたと語っています。
しくじり事例紹介(プロジェクト編)
ゲーム外での心配事に対する備えを語ったあと、実際の開発事例の話に移ります。
Sig氏いわく「脆弱性だらけのプロジェクトで起こった、数々のしくじり」が紹介されました。
しくじり:思い描く作品に恋をしすぎた 最初に挙げたしくじりは、「思い描く作品に恋をしすぎた」こと。つまり、「妥協のない作品にしよう」としたのです。ゲーム開発においては誰しも思いがちなことで、規模を増やしすぎたり、要素に凝りすぎたりして、 作品自体が完成しなくなる 、いわゆる「エターナる(※)」パターンです。
※ 「永遠」「果てしない」を表す英単語である「eternal」を日本で動詞化した造語。制作者や開発者が、何らかの事情によりその制作を放棄してしまうこと。「エタる」と表現されることもある
Sig氏が『LinkRH』の開発に手を掛けるまでの過去作2作は、開発初心者だったこともあり、規模を大きくしすぎずボリュームを抑えることで完成していました。そして、満を持して臨んだ『LinkRH』開発。理想を完璧に体現した、「ぼくのかんがえたさいきょうのゲーム」は完成したのでしょうか?
残念ながら、 理想通りには完成しませんでした。
「人間の欲望は限りが無いので、どこかで妥協しないと、いつまで経っても完成しない」とSig氏。理想を積み上げると、改善点はいくらでも出てきてしまいます。
『LinkRH』の開発でも「この景観はコンセプトと違う」「この難易度デザインは望ましくない」とスクラップ&ビルドを繰り返し、没になったステージ数が2桁に到達しました。 これらのステージのために作成したギミックや敵キャラクター自体は再利用できますが、当然ながら、配置や景観は作り直しになってしまいます。 せっかくのステージデザインが無駄になってしまい、二度手間になってしまいました。
現在はステージ数や構成は固まったそうですが、次回作以降ではしっかりとフローを固め、ロスを出さないようにしたいとSig氏は語りました。
開発初期と終盤の技術的なギャップ により、作り直しを余儀なくされるパターンもあります。
同人ゲームやインディーゲームの開発を行う同業者との会話では、こういった事例はよく聞く話ではあるそうですが、Sig氏は「とうとう自分にも起こってしまったか」という気持ちだったそう。
画像左が『LinkRH』の旧キャラクターモデル、画像右が新キャラクターモデル。モデルのクオリティは上がったが……
これらの現象は、以下の工程をループして繰り返してしまうことにより起こるそうです。
クオリティに納得できなくなり、アセットを作り直す
アセットを組み込み、開発を続けるうちに技術力が上がっていく
また納得ができなくなり、新たな作り直しが発生する
新しいアセットと古いアセットが同じ画面に写っていると、画風の統一感がないように思えてしまい、更に気になってしまうとSig氏。
このループを抜け出すには、 思い切ってアセットを自分以外の人に発注する か、 開発終盤に一気に最終版のアセットを作ってしまう かしかないのでは、と述べながらもSig氏は次回以降のプロジェクトでも再び「作り直したい欲」に苛まれるだろうと述べました。
しくじり:アセットをほぼすべて自家製でまかなおうとした 「せっかく作るのだから」とオリジナリティを極めた作品を目指してしまい、すべてのアセットを自分で作ろうとした結果、膨大な時間と手間を掛けることになってしまったとSig氏。
「最終的にどこまで自分でアセットを用意し、どこに既存のアセットを組み込むのか」を『LinkRH』開発プロジェクトを例に考えます。 Sig氏の場合は、自作にするか、既製のアセットを使うかの判断を 自分がこだわりたいかどうかの哲学 に従って個別に行いました。
哲学度の低いもの 地面のテクスチャについては手元によいものがなく、かつPBR環境(※)の場合はマーケットプレイスのアセットをそのまま利用しても差し支えないのではとSig氏。 『LinkRH』では、 Adobe Substance 3D Painter のサブスクリプションで入手できるマテリアル素材などを組み合わせ、独自のものを作成しました。
※ フィジカルベースドレンダリングの略。現実のライティングなどを精密に再現したレンダリングで、写実性の高い作品を作るときなどに使われる
空の表現は、マーケットプレイスの既製アセット「 Ultra Dynamic Sky 」を編集して使用しています。 Sig氏はこのアセットを「天候や時間による空の変化を手軽につけられる」と評価しています。
亀裂表現のデカールにおいては、オリジナリティを出す理由はあまりないと感じたため、迷わずマーケットプレイスのアセットを導入。
「この世界は、こういう理由により、独特の空模様をしている」のような設定が独自にあるのであれば、自分で用意するのも手。既存のアセットでもテクスチャなどを編集して、オリジナリティを出すことは可能
哲学度が中程度のもの 『LinkRH』では、瓦礫などのステージ景観は自作、その他のエフェクトやポストプロセスエフェクトは自作と外部アセットの混合です。この理由は、瓦礫や石、草木などのアセットはそこまでゲームに影響を与えないため、既成のものを使用しても悪くはないだろうと考えたからです。
スキルなどに使われる、パーティクルや Niagara のエフェクトは、数値の調整や自作テクスチャの適用で改変が可能です。色を変えるだけなら比較的簡単なため、武器の残像などをキャラクターのイメージカラーに合わせて調整するだけでも、ゲームや世界観に馴染むとSig氏。
ポストプロセスエフェクトは、スキルエフェクトのようなその場に現れるエフェクトではなく、画面全体に掛ける視覚効果です。水中で視界が暗くなったり、歪んだりといった効果を実装することができます。 『LinkRH』では、マーケットプレイスから取得したポストプロセスのアセットを、テクスチャを変更して使用しているそうです。
哲学度が高いもの Sig氏はキャラクターモデルとそのアニメーション、立ち絵イラスト、ステージBGMをゲームの方向性や世界観、プレイヤーの第一印象を決める最重要アセットと位置づけました。 そのうえで、自分で用意できない場合は、外部のクリエイターに発注して自分だけのアセットを作ってもらうのも手だと話しました。
「自分で1から10まで管理して作っているものにゲストクリエイターのイラストや演奏などの他の人の手が入ると、 予想もしない化学変化が起こる 」とSig氏は話しています。 他の人の介入によって初めて意識した部分や、キャラクターたちの人間性が見え、とても面白い体験だったそうです。
サウンドエフェクトに関しても、用意した効果音素材をDAWで組み合わせたり、エフェクトを書けたりして自作しているそうです。
しくじり事例紹介(技術編)
技術的な「しくじり」の解説に入る前に、ここで開発の初期から現在までのプレイ画面の変遷をまとめた動画が紹介されました。
プロジェクト1日目。基本的なアクションを実装し、動作を確認
もう少し開発が進んだ頃。足場・地形・マテリアルを仮実装し、ステージ進行をテスト。キャラクターのモーションも最初期と比べて動きが増えている
開発中期。エフェクトを追加し、見た目は現在の『LinkRH』に近づいた。現在のバージョンよりアクションごとのエフェクトが派手で、Sig氏はこの頃のほうが外連味があって好きだったそう
現在の開発映像。アンリアルエンジンも5.0になった。エフェクトの改良や視認性の改善を行い現在の形に
「動画に既にしくじりの片鱗が見える」と話すSig氏。どのような「しくじり」があったのでしょうか。
しくじり:手当たり次第にレベルを作っていた 初期のレベルデザインでは、景観を大きく重視していました。しかし、ゲームとして動かしてみると、序盤ステージなのに足場がまばらで難しすぎたり、終盤ステージなのに力技で切り抜けられるようになっていたりと難易度曲線の設定がしっかりしていなかったことから、遊んでいてあまり面白くないという印象がありました。
これを解決するのが、「グレーボクシング(グレーボックス) 」や「モック 」と呼ばれる工程です。
この工程ではシンプルなキューブやメッシュなどで、ステージの難易度や設計などを大まかにデザイン していきます。このときに、敵なども合わせて配置します。Sig氏はこの工程を必要ないものと思っていた時期もあったそうですが、あるのとないのでは効率が大きく違うことを実感し、今では考えを改めたとのこと。
仮組みステージとして足場や壁をシンプルな素材で組む。空間上に直接メモを置いておくと、後々どのような意図で配置したのかが把握できて便利
仮組みが終わったら、完成版の地形メッシュに差し替えます。 アンリアルエンジンではステージ全体を3Dモデルとして出力できるため、まるごとモデリングツールに持っていき、見た目を上書きするというワークフローも有用だそうです。
また、Sig氏はレベルデザインの支援ツールを早いうちに作っておくと非常に役に立つと、3つの支援ツール実装例を話しました。
移動可能範囲をルーラーで可視化 「ルーラー」のブループリントは滞空スキルでどこまで飛ぶことができるか移動範囲を視覚化したものです。足場の配置に非常に役立ったとのこと。
緑色のリングがルーラー。本作では滞空時間によって機動性能が上がるため、性能に応じた到達可能地点が何重ものリングという形で視覚化されている
この他、テストプレイ中にキャラクターに追従して、その場からの距離を測ることができる機能も盛り込みました。
コンストラクション スクリプトで地面に埋まるのを事前回避 コンストラクション スクリプト は、配置したアクター(※)をエディター上で動的に機能を展開するのに便利だとSig氏。
※ オブジェクトやライトなど、エディターに配置できるもの全般のこと
例えば、こちらの目玉の形をした敵キャラクター「ゲイザー」はプレイヤーが踏むことで足場にできますが、踏みつけた際に下に下がる関係上、ある程度の高度がないと地面と干渉してしまいます。
そこで、コンストラクション スクリプトを使用し、ゲイザーの下方部一定範囲内に地面を感知した場合、特定の高さまで座標を修正しています。 これにより、キャラクターが地形に埋まるのを防ぎ、最低高度が保てるようになっています。
コンストラクション スクリプトはブループリントで記述でき、ビューポートでの編集中でも効果を発揮
Editor Utility Widgetでレベルデザインツールを自作 アンリアルエンジンには「 Editor Utility Widget 」という機能があり、これを使用することでエディター内にツールを作ることも可能です。 「Event Chain Editor」はSig氏がブループリントで独自に実装しています。
「某・RPGが作れるツール」のような操作性で、メッセージの表示や、一定時間待機などの簡単な命令を実行可能
メッセージなどの小イベントはレベルに自動的に配置されます。小イベントを選択している場合は表示するメッセージなどを編集可能です。 各イベント間で、自動的に「Event Chain」という参照関係が作られることにより、イベント同士が繋がり、順番に小イベントが実行されます。
Editor Utility Widgetは非常に奥深く、プロジェクトに合わせたカスタマイズが可能な強力なツールだとSig氏は語ります。
しくじり:ブループリントクラスの設計が明瞭ではない 本作はすべてブループリントでコードが書かれています。Sig氏いわく「自分はケアレスミスをしがち」とのことで、ちょっとしたミスや書式の誤りを気にしなくてよいブループリントは、まさに「もってこい」のツールだったそう。
キャラクターの挙動からステージのギミック、果ては敵の行動にいたるまで、すべてがブループリント製。UIやメニュー、アニメーション制御などもブループリントの連携
しかし、ブループリントをどこでどのように組んだらよいのかという感覚を掴むまでには、時間を要し、結果的に適切でないクラスの組み方になっていたこともあったそうです。
本プロジェクトのクラス構造 Sig氏はまず、本プロジェクトにおけるクラス構造の例を紹介。挙げられたのは敵キャラクターを担う「BP_Enemy」と名付けられたブループリントの継承関係です。
「BP_Enemy」は、敵キャラクターのHPや攻撃性能、アクションのステータスなどの基本情報を持った最上位クラスです。このクラスは、移動制御やプレイヤーの方を向く機能、ダメージリアクションなど非常に多くの機能を持っており、見た目を設定すれば敵キャラクターとしてそのまま使用することができます。
この「BP_Enemy」の機能を継承し、子クラスの「BP_Enemy_Gazer」やそれをさらに継承した強化タイプの「BP_Enemy_Gazer」、中ボスの「BP_Enemy_Angel」を作ります。
これらは、基本機能に専用の攻撃アクションを持つクラスであり、場合によっては基本クラスのダメージリアクションなどを上書きする場合もあります。
ほとんどの場合、同タイプのエネミーは同クラスで完結。変数で挙動を変化させ、強化バリエーションなどを作成
ボス格のエネミーは内部的に「エネミーレベル」という変数を持ち、これにより、同タイプのエネミーでも強弱をつけています。序盤や体験版に登場する敵はレベルを0にすることで攻撃の密度を薄くし、終盤に登場するエネミーはレベルを高くすることで、モーションキャンセルやコンボ攻撃を行うようにしています。
何でもできる「神クラス」を作ってはいけない クラスの間違った組み方により起きた弊害の具体例に入る前に、Sig氏はたくさんの機能を持った、神のようなクラスは 作らないほうがよい と述べました。
開発者の頭の中が吐き出されやすいインディー開発では、特に 神クラス が誕生しやすいとSig氏は語ります。なんでもできるクラスは便利ですが、メンテナンスがしづらく、致命的なエラーを呼ぶ可能性が大いにあります 。またSig氏は、システムに関わる機能を持つクラスは、しっかりと機能を覚えておけるよう、メモやドキュメントを残す ことを勧めました。
『LinkRH』開発プロジェクトでは、これらを疎かにしてしまった結果、以下のような事例が起こりました。
事例1:似た機能を持つサウンドマネージャークラスが複数存在した ステージ演出で、とあるBGMの再生のタイミングに違和感を覚えたSig氏。 そのため、レベルに配置していた「 BP_SoundManager 」のイベントを編集して、BGMが流れるタイミングを変えようとしました。
しかし、いくら数値や発生タイミングを変えても、BGMの流れるタイミングは変わりませんでした。
「おかしいな?」と思って調べると「BP_SoundManager」は 何もしていない ことがわかります。調査を続けたところ、同じレベルにあった「BP_BGMManager」がBGMを流していることが発覚しました。
そこで、徹底的にレベルのブループリントを調べた結果、なんと、「BP_SoundManager」と「BP_BGMManager」という似た名前で似た機能を持つクラスが なぜか 同時に存在 しており、それを開発者のSig氏自身も把握していませんでした。
このような現象が別の場面でも起きていました 。BGMが鳴るタイミングを変えようとし、今度は「BP_BGMManager」にアクセスして、タイミングを編集しようとしたSig氏。しかし、BGMの再生タイミングは変わりません。
調べてみるとこのステージでは「BP_LevelManager」が、ステージ進行やBGMの再生、演出などを担当していたのです。
クラスに担わせる機能範囲は明確に こうした事例を回避するために、フィーリングでクラスの役割を分担するのではなく、そのクラスの役割をしっかり把握し、 専属で 仕事をさせるのがベターだとSig氏は語ります。
例えば「BP_BGMManager」はBGMの再生関連のみを担当させ、「BP_SoundManager」はサウンド エフェクトのみを担当、「BP_LevelManager」はステージ進行の管理のみを担当させます。それぞれに固有の役割を持たせ、他のクラスは役割以上の部分には立ち入らないというルール決めが重要です。
それでも、処理の関係でやむを得ずルールを破る場合は、その旨をコメントに書いておくのが無難 とSig氏は語りました。
しくじり:アニメーションブループリントの設計 次は、キャラクターのアニメーションを管理する、 アニメーションブループリント でのしくじりです。
多くの開発者がこの設計に悩むことが多いそうですが、『LinkRH』でも例に漏れずかなり迷い、構造や構想が初期から変化して2度ほどアニメーションブループリントを作り直すことになったそうです。
本プロジェクトのアニメーションブループリント 本作におけるアニメーションブループリントは以下のように構成されています。
基本アニメーション :各部位のアニメーションをブレンドしているセクション。表情や瞬きなどを制御するモーフターゲットや首の向きのプロシージャルアニメーション(※)の制御なども追加
カットシーン用アニメーション :カットシーン、いわゆるムービーシーン用に、全てのアニメーションを決め打ちで上書きできるセクション
物理挙動制御 :後付けで髪や服などを揺らすための物理演算を行うセクション。Epic Games Japanのおかず(岡田和也)氏が提供している疑似物理プラグイン 「 Kawaii Physics 」を使用して実装
※ 規則的な動きのアニメーションを自動で生成すること。例えば「カメラと同じ方向に首を向ける」というプロシージャルアニメーションであれば、どの角度を向いても規則に則り、その方向に首を向けるアニメーションが自動で生成される
プレイヤーキャラクター用の最大構成。敵キャラクターなどは基本アニメーションと物理制御のみにするなどもう少し簡略化している
ここで、実際の動画と共に本作におけるアニメーションの解説がありました。
アクションアニメーションは基本的に「アニメーション モンタージュ」で制御。走行時の体制の崩れもアニメーションモンタージュとブレンドで表現
フェイシャルアニメーションは「体を動かす」「モーフターゲットが動くだけ」のアニメーションをブレンドし、表情を作り上げている
事例:キャラクターのボーン構造の変化によるずれ ブループリントアニメーション関連の具体的なしくじり事例として「キャラクターのボーン構造の変化によるずれ」をSig氏は挙げました。 本作ではモデルのリニューアルに伴い、キャラクターの頭身が変化したため、ボーン構造も変化 。そこで、全てのアニメーションおよびアニメーションブループリントを作り直したほうがよいと判断しました。
モーションの制作 工程の関係で、基本ポーズも思い切ってAポーズからTポーズに変更しました。 ポーズはTポーズに変えなくとも、無理やり同じ構造にすることは可能だったそうですが、今後のキャラクターやスキンバリエーションなどの追加を考えると、変更がベストだと判断したそうです。
「ボーンの構造を変えた際、アニメーションごと取り込み直さなかった」場合に起きた不具合もありました。 下記の1枚目は正しい画像、2枚目は不具合の画像です。髪の毛の部分に注目すると、少し位置がずれているように感じます。これは、髪の毛のボーンも移動してしまったために、アニメーション内の髪の座標もずれてしまったことにより起きました。
Sig氏は、「fbxファイルは再インポート時、マテリアルやボーン構造に変化があるとメッセージを出してくれるので、警告は必ずチェックするように」と指摘します。警告が出た状態のスケルタルメッシュは、アニメーションやマテリアルに処置をしないと、体がずれたりマテリアルがおかしくなったりする原因となります。
画面上に現れた「Unmatched Skeleton Joints」という警告。「Show Conflict」ボタンを押すと、現行のモデルとの差異が表示される。特にモデリングツールのエクスポート設定次第では結果が変わるため神経質にチェックするのがよいとSig氏。 現在も『LinkRH』における髪の毛の座標ずれは数か所残っており、修正対応に追われているとのこと
アニメーションブループリントは、どういう設計が自分のプロジェクトにマッチするのか分からないことも多いそうです。仕様を練った後も、演出などを実装する際に、急遽「こういう機能がほしい」と思うことも多々あるとのこと。
Sig氏は、ただドキュメントを読むだけではなく、何度か捨てる覚悟でまず作ってみることが良いと話しました。その際、テストキャラクターとして実装していることを忘れずに、あらゆる場所で差し替えができるように設計するとよいだろうと自身の考えを話しました。
しくじり:バージョンをまたぐ際に壁にぶつかる Sig氏いわく「少し仕方ないことではある」と前置きしたうえで、バージョン移行の際のトラブルを紹介しました。 アンリアルエンジンはかなりの頻度でアップデートされているため、ゲームを開発する場合は、ゲームエンジンのバージョンアップデート対応は必ず視野に入れる必要があるそう。
ほとんどの場合は問題なく移行でき、バージョン移行前のバックアップをとっておくくらいで問題ないことが多いと言います。
『LinkRH』はUE 4.15 の時代に開発が開始されたプロジェクトで、毎回ではないものの、かなりの数のバージョン移行を経験してきました。特に直近の4.27から5.0への更新では、移行タイミングでエラーが出てしまい、検証に多くの時間を要したとのこと。
Sig氏は「プラグインの影響でファイルの参照ができなかった という理由があるのではないか」と推測していましたが、最終的に海外フォーラムをしらみ潰しに見ながら、Visual Studioを使用して手動でビルドし、なんとか移行に成功したそうです。
上手に転んで、心が折れない開発を
ゲーム開発は手探りでやらなければならないことも多く、大なり小なりの「しくじり」はあるだろうとSig氏は話します。しかし、Sig氏は「極論ですが」と前置きしたうえで、心さえ折れなければ数々のエラーも修正していけると、前向きに考えているそう。
Sig氏は、この講演を見る開発者の方や、ゆくゆくは開発者になる人にも、「ぜひ、ともに心身を健康に保ち、快適で苦労いっぱいの開発をしていければいいな」と声をかけました。
今回紹介した失敗事例は、慣れていない方は特にやりがちなものが多いと話すSig氏。この講演を頭の片隅に入れていただき、「しくじり」を未然に防いでいただければ幸いだと語りました。
「心身に気をつけて、開発を続けていこう!」という、自身は月並みと評する言葉で本講演は締めくくられました。
『Link: The Unleashed Nexus RH』Steamストアページ 「LinkRH」インディーゲーム制作・しくじり事例紹介&よきゲーム開発生活を続けるには? | UNREAL FEST 2023 TOKYO 公式Webサイト
© 2014-2023 Reminisce © Mediascape Co., Ltd. / Reminisce
ゲームのタイムアタックを中心に、ストリーミングサイト・Twitchで活動をしているストリーマー。ゲームイベントの紹介記事など、WEBメディアでの活動実績もあるが、繰り出されるダジャレのクオリティには賛否両論がある。
https://www.twitch.tv/serenade_yuuki