Unityでインディゲームを作る!

Unityでのゲーム制作を目指し、それに関わる話題についてのブログ

Unity 2021 LTS 祝リリース! C#8対応で可能になった新しいswitch式について

 Unity 2021LTS版がリリースされました。多くの新機能があるのですが、今回はUnityが、C#8.0に対応したことで可能となった、新しいswitchの書き方についてです。

 なお、文とは"statement"を指しますが、この新しい構文は厳密にはstatement(文)ではなく"式"となります。

 

 マイクロソフト公式が、C#8.0の新機能について解説しており、今回の記事はここを参照しています。

 

switch文と言えば...

switch(input){

    case Animal.Dog :

        Console.WriteLine("Inu");

        break;

    case Animal.Cat :

        Console.WriteLine("Neko");

        break;

    default:

        Console.WriteLine("Doubutsu");

        break;

}

 という風に、現在となっては少し古びた、コード全体が縦長になってしまうような構文でした。しかし、C#8.0からは、もっとスッキリとした書き方が可能です。

 

 以下の例は、C#のコンソールアプリケーションにおいて書かれたもので、Animalというenumを入力し、その日本語名をstringで返すswitch式を含むstatic関数となります。

NewSwitchStatement_enum

 

NewSwitchStatement

構文としては、

public return-Type FunctionName (input-Type input) =>

    input switch{

       input-case => return-value,

       ///////////////

       _                 => return-value

}; ←コロンが必要

 となります。swicth文の中で指定された以外の入力については、旧switch文ではdefaultとしてまとめていましたが、新switchでは_(アンダースコア)がそれに置き換わります。

 =>が使われているようにラムダ式のような感じで、慣れるまでは違和感を感じるかなぁとは思いますが、旧構文と比べて明らかに分かりやすいコードになるので、こっちを使っていきたいですね。

 

MadeWithUnity探検隊! "Lost In Random" ランダム万歳!

Lost_In_Random

 ランダムが全てを支配する!?不思議な世界で大冒険!今回のMadeWithUnity探検隊は"Lost In Random"(ロスト・イン・ランダム)です。

※本記事の画像はゲームプレイのスクリーンショット、あるいは公式サイトの画像の引用となります。

 

 "クイーン"によって支配された"ランダム"という世界では、12歳になるとクイーンの黒いサイコロを振り、その目によって今後どこで生きていくかを決定づけられます。

LostInRandom_Even

 主人公のグースー(英語オリジナルでは"Even"つまり"偶数"から)とその姉、キースー(オリジナル名は"Odd"、つまり奇数から命名)は、ガラクタ集めで人々が働くワン・クラフトという町で暮らしていました。

LostInRandom_BlackDice

 姉は隠れるように12歳の誕生日を迎えますが、やはりクイーンの黒サイコロを振ることになり、結果シックストピアというクイーンの本拠地となる『夢のような』宮殿に連れ去られてしまいます。

 

 一年近く経ったある夜、不思議なゴーストに導かれ、グースーは姉を救うため世界を股に掛けた冒険に旅立つことに。そして、その道中で手足の生えた奇妙なサイコロ、"ダイシー"と出会い、二人で様々な困難に立ち向かうことになるのです。

LostInRandom_TwoTown

 ・・・というように、世界観は非常に面白いものとなっており、そのビジュアルやストーリーの一体感は、最近のUnityゲームの中でも特筆すべきものになっていると思います。15時間ほどでクリアしました。

 個人的には海外のアニメ作品である、アドベンチャータイムの作者が参加している、というのがプレイしてみようと思ったきっかけでした。同作品にも見られる、尖って奇妙なキャラクター達や、しかし丁寧なストーリーテリング、軽快なセリフ回しは本作でも健在で、その世界観は非常に楽しめました。が!しかし!

 

 残念なことにアクションゲームとしてはどうなのか、となると非常に惜しい、残念な出来と言わざるを得ません。3Dアクションゲームなのですが、まず単純に操作性があまり良くないです。

 そして肝心のランダム要素のある戦闘システムも、戦闘中にサイコロを振って、その目次第でバトル内容が変わる、というアイディア自体は面白いのですが、楽しいゲームプレイとなるまでには洗練されていません。

 

 いくつかの街やダンジョンを探索するゲームになっているのですが、その世界観や造形は良いもののアクションゲームのレベルデザインとしては、いろいろと至らない部分があります。慣れたら割と大丈夫なレベルではあるんですが。

 

 というわけで、3Dアクションゲーとしてではなく、アドベンチャーゲームとして、その世界観やキャラクターとストーリーを楽しむゲームだと思います。その点ではインディーゲームとして良くまとまっているし、素直に楽しめるゲームです。

 アクションゲームとしては期待していたモノを下回っていたので、かなり残念ではありました。しかし、それを補って上回る魅力があったのは間違いなく、合間の戦闘はもうミニゲームとして割り切ることで、最後まで楽しむことが出来ました。評価点数としては75~80点くらいでしょうか。

 

 以後、気になった点について書いてみたいと思います。

 

ゲームらしい動作とリアルな動作

 まずは操作性なのですが、あまり良くありません。世界観が重要なゲームではあるので、あまりに機敏に動きすぎてもダメだと理解はしてます。しかし、慣性が変に効くキャラクターの挙動は、どうしても操作しにくく感じてしまうのです。

 

 このゲームでプレイヤーが平常時に行う多くの動作は歩く、走る、パチンコで狙って撃つ、カメラを動かす、の4つになるかと思いますが、どれも操作に良くないクセがあります。

 リアルに寄せるのであれば、慣性が効いたり、予備動作がきちんしてることが大事ですが、世界観やストーリーを楽しませたいなら、そこはストレスの少ないゲーム的な快適な挙動で良くないか、と思ってしまいます。

 

カードを引き、サイコロを振れ!

 本来ならば目玉の一つになったであろう、カードとサイコロを絡めたランダム要素の強いバトルシステムについてです。前述していた通り、自分はこの要素についてかなり期待をしていました。

 しかし、実際にはアクションゲームとしても、カードゲームとしても微妙な出来。最低限は成り立っているけど、もうちょいなんとかならなかったのか、という感じです。

LostInRandom_CardDeck

 いろんなカードがあり、それが揃う度に戦闘での選択肢が広がっていく喜びはあるのですが・・・。

 

LostInRandom_BattleSystem

 バトルの基本的な流れとして・・・まず戦闘が開始すると手札がゼロの状態から始まります。敵にはクリスタルが付着しており、パチンコで撃つか、敵の攻撃をタイミングよく回避した時に発生する"ブリンク"で敵を通り抜けると地面に落ちます。

 そうしてクリスタルを集めるとカードが引けて、カードが手元にある状態でサイコロを振ると、出た目のコスト分だけカードからアイテムや武器を取り出せる、というものです。これを繰り返して全ての敵を撃破したら勝利となります。

 

 まずは単純に戦闘のテンポがあまり良くない、という部分。カードが揃うまではプレイヤーはチマチマと敵の体についてるクリスタルを狙い撃つか、敵の攻撃を待つか、ということになるんですが、その時間のつまらなさと言ったら!

 またサイコロを振った後のカードを選択する時間は自分以外の時間は全て止まってプレイヤーだけ自由に動けるのですが、しょうがないとは言え、アクションゲームとしてはテンポを悪くしてしまっています。そこはカードゲームでもあるので、避けられない仕様ではありますが。

 

 前述の通り、パチンコの操作性も良くはないし狙い撃つ気持ちよさも無く、場合によっては戦場が広くない場合も多いです。なので、自分に迫ってくる敵の小さな一部分をせかされるようにエイムして撃つ、というゲームプレイに面白味を見出すのは少し難しい。敵の攻撃を待つ、というのも受動的な行動であり、自発的な行動とは言えません。

 

 戦闘が始まった時点で数枚カードが手元にあり、サイコロを振るところからスタートすれば、もうちょっとテンポ感は良かったのかな、とは思いました。

 ただ、ダイシーが最初は1か2の目しか出せない、というゲーム展開上の都合などもあるので、そこらへんは難しい所です。

 

3Dゲームにおけるゲームプレイとカメラの挙動について

 もうこれは3Dゲーム、特に3Dアクションゲームの宿命ですが、カメラの挙動についてです。このゲームはプレイヤーに求められるカメラ操作が、そのゲーム性に対してちょっと多すぎます。

 自分はキーボードマウスでこのゲームをプレイしたのですが、基本マウスはカメラ操作に有利なはずが、それでも道中、カメラ操作がかなり億劫になりました。(※環境によるとは思いますが、場合によってはカメラの感度は下げた方が良いです)

 前半にステルス・プレイをする部分があるのですが、カメラをかなり動かさないとダメ部分が多く、そこで少し酔いました。(慣れと感度調整でなんとか対応)

 

 このゲームのカメラ・システムはいわゆるTPS方式なのですが、プレイヤーに対してカメラがやや近いというのもあり、街中を見渡したり、歩き回る際にかなりカメラを動かさないといけません。カメラのある方向に走ると自動で動いてくれるわけでもなく、各街もけっこう入り組んでいるので、カメラ操作が意外と忙しいのです。

 

 このゲームの魅力の一つとして、各ロケーションは作り込まれてはいるので、その景色を見渡すという意味で視点を動かせるのは良いのですが、ゲームプレイと一致したカメラ・システムかというと微妙で、せめて街中などは見下ろし型の固定式カメラでも良かったのではないかと思ってしまいます。

 

LostInRandom_MannieDex

カードが好きすぎてカード屋そのものになった男

 また今作でのカードは、サブクエストをクリアしたり、マニー・デックスというカード屋から買うことで入手できます。買うためのお金は、敵を倒す、各地に置いてある陶器をパチンコで壊す、ダイシーが入り込むと金銭が得られるダストシュート?を見つける、サブクエストをクリア、で得ることが可能です。

 この中で陶器を探す、ということになるとカメラをグリグリ動かすことになるのですが、陶器自体が微妙に見にくいというのもあり、結構苦痛ではあります。上画像の左上にぼんやりと見えるのが、その陶器です。これが様々な場所に置かれているわけです。

 

 強いカードをなるべく早く手に入れたい!となると、この陶器探しをすることになるんですが、カメラ・システムと狭く入り組んだ環境デザインも相まって苦行になってしまっているんですよね。そこまで必死に探さなくても、最終的には全部のカードを最低必要数揃えるのには、余るくらいのお金があるので大丈夫なんですが。

 カメラを必死に動かして、背景に溶け込む壺を探すプレイってこのゲームに本当に必要かな、とは思ってしまいます。パチンコで狙って撃つ、が基本ゲームプレイとして組み込まれているので、それを活かそうとしたミニゲームではあると思うのですが。

 この陶器探しは特に今作の荒いカメラ・システムと噛み合わせが悪い部分になってしまっています。

 

 狭くてゴチャゴチャしたロケーションというのは、間違いなく雰囲気が出ます。しかし、ゲームプレイをする場として考慮、設計がされていないと、ただただ動きにくい"レベル"ですし、さらにカメラ・システムが適切でないと苦痛になる危険もあるということをつくづく考えさせられます。

 

 またカメラがオブジェクトと衝突して、その位置を自動で変えるシステムもかなり荒くて、衝突判定になるオブジェクトの選別も適当なため、無駄にカメラが動いてしまうという挙動もあり、インディゲームとは言え、昨今の3Dゲームのカメラとしては看過できない問題点もあります。

 とにかく3Dゲーム、3Dアクションゲームを作る以上はカメラ・システムというものにきちんと向き合うことが重要で、ゲーム性、ゲームプレイ、レベルデザインなど全てを考慮した適切なカメラの挙動を考えなければならないと改めて考えさせられました。

 

まとめ

LostInRandom_Singer

 というわけで、アクションゲームとしては文句がかなり出てきてしまう作品ではあるのですが、ストーリーに関してはもう一回プレイしてまた見たいと思える出来ですし、物語構造も王道で良くできた作品だと思います。

 単純なアニメ作品として出たら、そのアニメ見るで良くね?と言われてしまいそうですが、それだけにゲームプレイがより洗練されていたら・・・な惜しい作品です。

 

 ただし、そこら辺を我慢できる方でしたら、おススメは出来るゲームです。奇妙な世界観や魅力あるキャラクター達の掛け合いを楽しみたい方は、Steamセール時などに買ってみると良いかもしれません。(正規価格はちょい高め)

 ただ!最後の問題点ですが、EAのOriginをインストールする必要があるのです!これもめんどくさかった!

 

 という風にいくつか障壁ありますが、それを超えてプレイするだけの価値はあるとは思いますので、ぜひ!!

 

ゲーム制作における、四本の柱について考えてみる!

 ゲーム制作において、もっとも重要と思われる四大要素を考えてみました。これらのクオリティを各々上げることが、一つのゲーム全体としての出来を良くするのではないか、という考察になります。

 

 これらは自分が今までプレイしてきたゲームから得た経験によって導き出されたものです。ゲームは多くの要素があり、それらが複雑に相関し合っていると思います。しかし、それら多くの要素が、この4つの領域に大別できるのではないか、というのが、自分の推察です。

 

ゲーム・デザイン

 ルールを作る、どんなゲーム性にするか、ゲーム・システム構築、仕様書作成。プレイヤーに何をさせるか、プレイヤーは何を楽しむのか。

 

 ゲーム制作というのは、まずここからがスタートになります。全ての土台になると同時に、製作過程のどの地点においても、その都度見直していかないといけない部分です。

 

レベル・デザイン

 プレイヤーにとって、向き合うべき課題とそれが行われる場を作る。遊びとして実際に消費されるコンテンツの制作、バランス調整。ゲームシステムとゲームプレイと各オブジェクトの全てが結びついた環境のデザイン。

 

 プレイヤーの遊び場となる空間とプレイヤーが向き合う対象物、課題の設計にかかわる部分になります。ゲームデザインがシステム設計だとすると、レベルデザインはそのシステムを基礎とするコンテンツを制作する工程です。

 

ソフトウェアとしてのビルド・クオリティ

 ソフトウェア設計やコーディング、安定性、バグ取り。基礎となるゲームエンジンを使いこなせるか、など。

 

 アナログ・ゲームと違い、ビデオゲームはデジタル・アプリケーション及び、ソフトウェアでもあります。遊び自体は本来はルールさえあれば、道具がなくとも成立するものです。しかし、特にビデオゲームはソフトウェアとして動かなければ、遊ぶことが出来ません。

 

 『遊び』としての面白さと、ソフトウェアとしての質は直接的な関係はないにせよ、ソフトウェアとしての問題があれば、当然プレイヤーのゲーム体験を大きく損ねてしまいます。

 ゲームとして面白いのに、急にフリーズしたり、セーブが消えたりしてしまえば、内容は良くてもダメなゲームとして判断されてしまうということです。

 

インタラクティブ要素(リニア要素)

 キャラクター、世界観、シナリオやストーリー、音楽など、遊びそのものやゲームの持つインタラクティブ性に直接的には関係ないが、感情移入、没入感を高めるもの。

 

 プレイヤーが直接的に介入、操作できない非インタラクティブな、リニアな要素を指します。ビデオゲームは学術的には、ソフトリアルタイム・インタラクティヴ・エージェントベース・コンピュータ・シミュレーションとされますが、実際にはインタラクティブではない要素も多く含んでいます。

 むしろ、ゲームによってはそういうゲーム製作者から一方的に提示される要素が重要である場合が多いですし、それがゲーム制作者の個性ともなります。

 

 しかし、最近ではマインクラフトを代表とする、プレイヤー自身のやりたいこと、作りたいものが最重要であるゲームの存在が非常に大きいです。

 そして、プレイヤーの選択によってストーリーが変化したり、ゲームプレイの状況や進行によって音楽やサウンドが変化する、Adaptive Audioが組み込まれるようになってきています。

 キャラメイクなどもプレイヤー自身がそのゲームのコンテンツ内部に介入できる重要な要素の一つです。

 

 ジャンルにもよると思いますが、インタラクティブな部分は増えて、非インタラクティブな要素は減るのかもしれませんが、それでもその重要性は少なくなる、ということは無いと思います。

 

まとめ

 ゲームを構成する多くの要素は、以上の四つのカテゴリーに分類できるのかなと思います。抜け落ちもあるでしょうが、自分の考え、理解を整理する上では良い試みでした。

 

Unity公式によるeBook "Optimize Your Mobile Game Performance" をザックリ翻訳してみた [LTS 2020]

Optimize Your Mobile Game Performance

 Unityが公式に発行しているeBook"Optimize Your Mobile Game Performance"を読み解いていこう、という企画です。最初はメモ的なモノを想定していましたが、結果的には全部で13章に渡る内容をほぼ翻訳という形で記事にしてきました。

 モバイル・プラットフォームにおけるUnityゲーム、あるいはアプリケーションを快適に動作させるための最適化テクニックについてまとめた(電子)本で、直ぐにでも活用できる情報が満載です。

 LTSが出されたタイミングで新バージョンが発行されるので、現在はLTS2020版の内容となっています。LTS2021版が出たら、内容を更新する予定です。

 

 およそ一か月弱にわたって書いてきて、少し間を置きましたが、その推敲や校正も終わり、最低限読めるものにはなったのかな、と思います。本記事は、各章へのリンクをまとめたエントリーポイントのようなものです。

 これは個人的な翻訳であり、その内容について保証するものではありませんので、あくまで原文の英語を参照していただきますよう、お願いします。

 

 省いていた前書き(Introduction)と後書き(Conclusion)の翻訳も本記事でやってしまいます。各章の内容については、各リンクから移動してください。

 

Introduction

 iOSAndroid用アプリケーションの最適化は、開発サイクル全体を支える必須のプロセスです。モバイル・ハードウェアは日々進化を続けており、アート、ゲームデザイン、オーディオやマネタイズ戦略に渡るモバイルゲームの最適化は、プレイヤー体験を研ぎ澄ます上で重要な役割を担っています。

 

 iOSとAndoroid両方で、数百万人のアクティブ・プレイヤーを擁しています。もし、あなたのゲームが十分に最適化されているのであれば、プラットフォーム特化のストアからお墨付きを貰えるチャンスがあります。

 ゲームのローンチからその後に至るまで、成功の機会を最大化するために、あなたの目標は常に二つです。滑らかで没入感の強い体験を組み上げること、そして、幅広いモバイル機器上で動作させる、ということ。

 

 Unityのソフトウェア・エンジニア専門チームからの知識、アドバイスを組み上げたのが、このガイド(※本書)です。UnityのAccelerate Solutions games チームは、最高のゲームを立ち上げる手助けをするために、業界に渡る多くの開発者とパートナーになっています。本書でアウトライン化された手順に従い、モバイルの電力消費を減らしつつ、最良のパフォーマンスを得てください。

 

 本書で議論される多くの最適化は、追加的な複雑性を導入しかねないことに注意してください。これはつまり、余計なメンテナンスや潜在的なバグを生み出しうる、ということです。これら最良の実践を実装する際は、その時間と労働コストに対して得られるパフォーマンスとの間でバランスを取りましょう。

 

 Unityチームより、ハッピーな最適化を!!

 

本編

Profiling

Memory

Adaptive Performance

Programming And Code Architecture

Project Configuration

Assets

Graphics And GPU Optimization

User Interface

Audio

Animation

Physics

Workflow And Collaboration

Unity Integrated Success

 

Conclusion

 更なる最適化のための豆知識、最良の実践やニュースはUnity Blog#unitytipsタグ、Unity Community Forums、そしてUnity Learnで見つけることが出来ます。

 

 パフォーマンス最適化は長大なトピックです。モバイル・ハードウェアがその制限において、どのように運用されているのか理解しましょう。あなたの設計要件を満たす効率的な解決方法を見つけ出すために、あなたはUnityのクラスやコンポーネントアルゴリズムやデータ構造、目標となるプラットフォームの計測ツールをマスターする必要があります。

 もちろん、この本に書かれた、創造性に溢れる僅かながらの助言も。

 

最後に

 以上になります。なかなか大変ではありましたが、繰り返し読んでてタメになる本だったので良い経験でした。UnityはいくつかeBookを出していますので、また機会あれば本ブログで、何らかの形で取り扱ってみたいと思います。

 

細長ゴルドーをBlenderで作ってみた! [ カービィ Geometry Node ]

Cylinder-Gorudo

 3月に発売を控えた、カービィの新作ゲーム星のカービィ ディスカバリーのPVに登場し、ちょいと話題になった細長いゴルドーBlenderでササっと簡単に作ってみました。Blender 2.9から登場し、3.0にて更なる進化を遂げた新機能Geometry Nodeを利用してトゲを生やしています。

 

 ゴルドーとはカービィ作品ではお馴染みの敵キャラで、トゲトゲが付いた球体にカワイイ目が付いたお邪魔キャラ。今回、初の正式3Dカービィ作品ということで、それに対応する形で細長くなったようです。

 

 話を戻しますが、Blenderのデフォルト・プロジェクトとなるGeneralプロジェクトにはGeometry Nodeタブが準備されているので、そこを開けば、ジオメトリー・ノードを簡単に使い始めることが出来ます。

 

Geometry Node

 Geometry node(ジオメトリー・ノード)は、ノードを繋げることでメッシュを生成したり、コントロールしたりすることのできる機能です。

 地面に草木を生やしたり、飴の周りに砂糖をまぶすといったことは、以前ならパーティクル機能を利用して表現していましたが、この機能によって、より分かりやすく簡単に行えるようになりました。

 

ゴルドーの体を準備しよう

Cylinder_VertexGroup

 今回は鉄棒の表面にトゲを生やすということで、まずはシリンダーを追加し、角をBevel処理して丸めます。

 そして、ゴルドーの目をつける場所にはトゲを生やしたくないので、それ以外の面をVertex GroupにWeightを1.0として登録します。グループ名は"Body"としました。これで準備は完了です。

 

Geometry_Node_Editor

 次にジオメトリー・ノード・タブを開きます。画面下部にあるのがジオメトリーノード・エディター(上画像)です。対象となるオブジェクトを選択した状態で、newと書かれた+ボタンを押し、新しいジオメトリー・ノードを作成します。

 

Vertex Groupを入力として使いたい

GeometryNode_Group Input&Output

 ジオメトリー・ノードには、それぞれグループ入力とグループ出力が準備されています。そこに自分の使いたい入出力を追加できるので、先ほど準備したVertex Groupを利用するために、Boolean値の入力を設定します。(※float値としても指定できます)

Adding New Input to Group inputs

 以前はノードの変数入力欄にVertex Group名を直接書き込めたのですが、3.0でその機能は無くなってしまい、このようにInputとして追加する形になったようです。今後また変わるかもしれません。

GeometryNode_Modifier

 ジオメトリー・ノードを作成すると、ModifierプロパティにGeometry Nodeが表示され、設定した入力もそこに示されます。

 先ほど追加した入力は、Boolean値なのでデフォルトでは"0"と表示されていますが、横の十字のアイコンを押すと、上画面のように各パラメータが表示され、選択することができます。Vertex Groupは一番下のBodyなのでそれを選択します。

 これでジオメトリー・ノード上で、Vertex Groupをパラメータとして使うことが出来るようになりました。

 

表面上にトゲを生成する

Geometry Node_NeedlesOnCylinder

 ジオメトリー・ノードでは座標点のことをPoint(ポイント)と呼び、そこにメッシュを生成することになります。

 Distribute Points on Facesというノードがあり、つまり、表面上にポイントを配布する、という機能なのですが、そこにSelection端子があるので、InputsからVertex Groupを繋げます。すると、Vertex GroupでBodyグループとして指定した面でのみ、このノードでポイントが作られることになります。

 ここからInstance on Points、つまりポイント上に(メッシュを)生成する、という機能のノードに繋ぎ、primitive meshとして用意されているConeメッシュをinstance端子に繋ぎます。

 

 Set Materialノードでマテリアルを設定し、Translate Instancesノードで位置を調整すると・・・細長ゴルドーの完成です!

Cylinder-Gorudo

 Distribute Points on Facesでのポイント配布方式は、Random(ランダム)Poisson(ポアソン) diskと二種類の方式があり、ほどよくオブジェクトを離して設置したい時はPoisson diskを使います。

 

まとめ!

 というわけで、本物と直に比べるとパチモン感あふれるモノが出来てしまいましたが、細長ゴルドーをジオメトリー・ノードを使って再現することが出来ました。

 

 今回の初の3Dとなるカービィ新作は、『星の泉の物語』で育った自分としても、かなり興味深いタイトルとなっているので、是非とも遊びたいなと思います!