Search Unity

ゲーム関連のイベントやオンラインで、時々「Unity で 2D のゲームを、PC とモバイル向けに作っているのですが、アセットの解像度はどのくらいにするのがいいのでしょうか?」という質問を受けます。この質問に関して、すべてのケースをカバーするシンプルな答えはありません。このブログ記事は、読者の皆さまがプロジェクトにおいて、最善の選択について考える助けとなるように書きました。

近年、私たちは Unity での 2D ゲーム制作に役立つ機能を多数開発しています。スプライトアトラス、2D 物理、Tilemap 機能(長方形、六角形、等角法)、スプラインベースの Sprite Shape2D アニメーションなどはそのほんの一例です。

Unity では、オブジェクトのサイズはピクセル単位で表記されていませんが、これが 2D ゲーム向けのアセットを製作するときに、アーティストを混乱させることがあります。アセットをどのくらいの大きさで作ればいいのかわからないのです。しかもゲーム開発の現場では、こうした質問をしても「時と場合による」という答えが返ってくるだけということがよくあります。しかし、ここではアセットの仕様決定をより簡単にするための考え方をいくつか示そうと思います。

注:このブログ記事の画像は、アーティストの Mikael Gustafsson が製作した 2D Forest Pack に収録されているアセットです。

ドット絵アーティストの方への注意:この記事で紹介しているヒントのほとんどは、ドット絵の場合にはあてはまりません。ドット絵アートのグラフィックの解像度はとても低く、またグラフィックをオリジナルのサイズの 2 倍、4 倍、8 倍、あるいはそれ以上の倍率で引き伸ばして使うと思います。つまり、オリジナルのアートでは 1 ピクセルでも、スクリーン上では 2×2、4×4、8×8 のピクセルとして表示されるということです。

そのため、一般的にドット絵アートでは、スクリーンの解像度に関してそれほど気にする必要はありません。しかし、アーティストは、元絵と表現したいフィール(伝統的なドット絵、ファミコン風、高解像度の「現代風」ドット絵など)を定めるところからスタートし、そしてアセットを 2 〜 3 倍に引き伸ばして使うものです。

Unity は Pixel Perfect ソリューションをパッケージとして配布しています。このパッケージには、カメラに搭載すると、アートをどのようなスクリーンで表示する場合でも、スクリーンのハードウェアレベルのピクセルグリッドに合わせてピクセルを表示し、はっきりした見た目を保つための複雑な調整を行ってくれるコンポーネントが含まれています。

Pixel Perfect パッケージの詳細情報は、GitHub の Pixel Perfect パッケージのドキュメンテーションページで見ることができます。

拡大するのではなく、縮小する

解像度の選択についてあれこれ考える前に、まず、アセットを製作するときは、実際にその解像度でゲームに取り込まないにしても、出来るだけ高い解像度でアセットを作るのが良いという事実を思い出しましょう。アート素材を縮小することは簡単ですが、クオリティを維持しながらそれを拡大するのは大変です。

ゲームのアート素材の一部を印刷する必要が出る、画面上である要素のサイズを大きくする必要が生じる、あとになって 4K 解像度モニター向けの「HD バージョン」を作る、といったシナリオも考慮しておきましょう。

これらの理由から、アートの製作担当になった場合は、実際に必要な解像度の 2 倍以上の解像度の作業ファイルを使うようにします。Unity に取り込むときはサイズを縮小して使うか、インポート時にサイズを縮小するようインポート設定で指定するようにします。

インポート設定では任意のアセットの最大解像度を 2 の累乗ピクセルの幅に制限することが可能

インポート設定では、最大サイズの指定のほか、プラットフォームに応じた圧縮設定を行うことができます。そのため、例えば PC ではアセットを特定の解像度で取り込み、ディスク領域の制限が厳しいモバイル端末ではその半分の解像度で取り込むという設定も可能です。

ヒント:Unity には、複数のスプライトを 1 つにまとめるスプライトアトラス機能があります。この機能は単にテクスチャーを格納するためのディスク領域を節約するだけではなく、プロジェクトのスプライトに最大サイズを個別に設定しなくても、一括でスプライトの最大サイズを指定できる手段を提供します。

プラットフォームに合わせた解像度を指定する

アセットのサイズを決めるとき、ゲームの配布先となるプラットフォームやデバイスについて考慮しましょう。ユーザーが使うデバイスやスクリーンの仕様は多岐にわたり、開発しているゲームの画面は様々な解像度やアスペクト比で表示されます。

この記事を書いている段階では、PC 向けに配布する場合は、 「フル HD」(1920 x 1080 ピクセル、1080p)、と 1280 x 720(720p)の 2 つの解像度をサポートすれば、大部分のユーザーをカバーできるでしょう。ほとんどのユーザーはフル HD でプレイし、720p でプレイする人もそれなりにいます。4K モニター(3840 x 2160)や Mac の Retina モニター(最近の 15 インチ MacBook Pro の場合、最大解像度 3360 x 2100)を使うユーザーもいますが、少数派です。ここまでのピクセル数をカバーする必要はないでしょう。

スマートフォン向けの場合、解像度の範囲は相当広いです。古いデバイスの解像度は縦 720 ピクセル未満である一方、最新の機種には最大で 4K 解像度を表示するものもあります。

ヒント:Unity では上記の内容に関する統計情報を、お使いの Unity ID の Operate Dashboard に集約できる仕組みを提供しています。Analytics を有効にしたプロジェクトを選択し、Analytics > Market Insights の順に移動すると、収集した統計情報を参照できます。Steam でも、このページで紹介されている類似のサービスが提供されています。

Retina(Apple の登録商標)や最近の高 DPI スクリーンでは、ハードウェアが出せる解像度が非常に高い(4K など)ため、本来出せるよりも低い解像度をシミュレートして画面を表示しています(たいていは最大解像度の半分。4K の場合はフル HD をシミュレート)。しかし、そうなると画像やテキストは 2 倍のピクセルを使って表示されるので、非常にくっきりとした見た目になります。

注:ドット密度の単位に DPI(dots-per-inch)を使うメーカーと PPI(points-per-inch または pixels-per-inch)を使うメーカーがありますが、結局どちらもスクリーンの 1 インチの中に入るピクセルの数を表しています。従来、スクリーンは 72 DPIで、最近の高 DPI スクリーンはたいてい 144 DPI を実現しています。スマートフォンには 400 DPI 以上をうたっているものもありますが、これは相対的に小さなスクリーンに多数のピクセルを配置しているためです。いくつかの例をこちらで見ることができます。

これらのスクリーンを扱うとき、2 つのやり方があります。1 つ目は、4K 解像度をフル活用した体験を提供してしまうことです。この方法の欠点は、4K 対応アセットを製作しようとすると作業量がものすごく増えることです。この場合、マーケティング素材でアセットを前面に押し出していきましょう(「4K で描かれる美麗な世界を体験しよう」など)。PS4 Pro や Xbox One X など、4K 対応のコンソール機を持っているユーザーにとって、ハードの性能を限界まで引き出しているゲームは魅力的に映ります。

もう 1 つのやり方は、フル HD をカバーするようにゲームを設計することです。この場合は、高 DPI モニターを使っているユーザーは、高いスクリーン解像度の恩恵を受けることができず、フル HD 環境でゲームをプレイすることになります。理想的な状況とは言えませんが、ビルドのサイズを制御したいと考えている場合には良い方針と言えるでしょう。

ここでの結論は、(上記で紹介したような、市場シェアのデータに基づいて)想定される最大の解像度を選び、プロジェクト全体での指標に設定するべきであるということです。チームメンバーはその指標に基づいてアセットの製作における決定を下すことができるようになります。

Unity シーン内での計測

ここまでで言及したように、Unity ではピクセルではなく、「ユニット」と呼ばれる単位で距離やサイズを表現しています。一般的に、1 Unity ユニットを 1 メートルと考えることがグッドプラクティスです。このシナリオにおいて、たとえば平均的なヒューマノイドモデルは 1.7 から 1.8 ユニットの大きさになります。これは絶対的な考え方ではありませんが、物理演算を使ったゲームを正常に動かすときには役立つ考え方です。Unity の物理演算は、1 ユニットを 1 メートルとして扱う場合に最適化されているためです。同じことが 3D ライティングにもあてはまります。これはライトのパラメーターが、ライトが現実世界に近い振る舞いをするように設計されているためです。

2D ではスケールの問題の重要性は下がりますが、プロジェクトで物理演算を使う場合は、やはりスケールのことを考慮するほうがいいでしょう。Tilemap を使っている場合は、シンプルに取り回せるように、1 タイル = 1 ユニットになるようスケールを設定するのがいいでしょう。

ユニットについて説明が終わったので、カメラの説明に移ります。Unity の 2D(Orthographic、平行投影)カメラには、Size(というパラメーターがあります。この値を倍にすると、カメラのフレームの縦方向に収まるユニットの数になります。

Orthographic カメラのインスペクター内の Size パラメーター

Size を 5 にすると、ビューポートの縦方向の長さは 10 Unity ユニットになります。横方向の長さは縦方向の長さに基づいて決められます。これは、ユーザーが見る画面のアスペクト比がわからないためです。ただし、簡単に計算することができます。一般的な PC や Android スマートフォンのスクリーンのアスペクト比は 16:9 なので、次のように計算できます。

10(縦方向のサイズ)x 16 / 9 = 17.7(横方向のサイズ)

これらの設定から、カメラのフレームの大きさはおおよそ 17.7 x 10 ユニットとわかります。画面のアスペクト比が一般的に 16:10 となる Mac の場合、この値は 16 x 10 になります。つまり、横方向の可視範囲がやや狭くなります。スクリーンのアスペクト比が 16:9 のスマートフォンを縦に持っている(アスペクト比が 9:16 になる)場合は、このカメラは5.6 x 10 ユニットの範囲しか表示しなくなります。

注:この記事ではアスペクト比の扱いについては触れません。さまざまなアスペクト比のスクリーンでプレイされるゲームを作ろうとする場合は、グラフィックのことだけではなく、アスペクト比が違うデバイスでプレイしてもプレイ感覚が変わらないように、ゲームプレイに膨大な量の調整をかける必要があります。例えば、横方向にスクロールするゲームを横に長いアスペクト比のスクリーンでプレイすると、次にやってくる障害物が見えやすくなってゲームは簡単になってしまいます。アスペクト比が大きく変わってもまともにプレイできるようにゲームを調整することが不可能なこともあり、対策として、フレーム画像や黒い帯をネガティブスペースに表示させて、ゲームプレイに関係する画像が見えないようにすることもよくあります。

ユニットあたりのピクセル数を設定する

グラフィックをスプライトとしてインポートしたとき、Unity は Pixels per Unit(PPU、1ユニットのピクセル数)というパラメーターを表示します。ここまでの内容でユニットについては十分に理解されたかと思いますので、PPU もはっきり理解できると思います。このパラメーターはゲームオブジェクトのスケールが 1,1,1 に設定されたときに、Unity シーンの 1 ユニットの中に収められるスプライト中のピクセルの数を表しています。

たとえば、218 x 175 ピクセルの岩のスプライトを使うときに、Pixels per Unit の値を 100 に設定すると、このスプライトをシーンにドラッグしたとき、そのゲームオブジェクトの大きさはデフォルトで 2.18 x 1.75 ユニットになります。これはフレームの縦方向の長さが 5 ユニットのカメラの場合、フレームの縦方向の長さの約 1/3 の高さのゲームオブジェクトができるということです。

上記の設定によって、5 個以上の岩をビューポートの縦方向に並べることができる

テスト解像度をフル HD とします。このとき、縦方向は 1080 ピクセルの解像度となり、岩の高さは画面の縦の長さの 1/5 未満になります(上の画像では、薄く表示した岩が 5 つ以上並んでいるのがわかります)。これは 175 ピクセルのグラフィックを 200 ピクセル以上に拡大しているということです。この状態だと、岩はややぼやけた状態で表示されることになります。

これを修正する方法はいくつかあります。半分程度のサイズに岩を縮小するカメラのフレームサイズを大きくして 10.8 にする(ズームアウトする)、または、スプライトの PPU の値を変更して、108 にする(画面上で岩を縮小するのと同じ効果)といった方法があります。

カメラの Size や PPU の値はどうやって決めればいいでしょうか?非常に簡単な方法があります。カメラの Size の値については、たとえばグラフィックを 100 PPU でインポートしている場合は、カメラの Size を 10.8 とする必要があります。これは 10.8 x 100 = 1080 だからです。この設定により、カメラフレームの高さが画面の高さにフィットします。反対に、カメラの Size が 5 と決まっていて、フル HD で縦方向に 10 Unity ユニットが入るようにするには、PPU の値は 1080 / 10 = 108 に設定します。この数値はカメラの Size の値が一定のとき、1 ユニットに収めるべきピクセルの数を示します。

ルールを作り、ルールを壊す

ゲームの開発中に、これらのワークフローを取り混ぜるのは危険であると覚えておいてください。あるシーンでグラフィックの解像度が低くなっているのに、それに気づかないという事態に陥ります。ガイドラインを確立しましょう。プロジェクトで使うアセットの大部分で PPU を統一し、カメラの Size の値も 1 つに定めておきます。

そうして開発を進めたところで、そのルールから逸脱したものを作りましょう。カメラをズームイン・アウトさせるために一時的にカメラの Size を変えるカットシーンを作ったり、テクスチャ―が巨大すぎて、背景の要素が大きくなりすぎ、そのために統一の PPU では扱えないということが起こることがあります。画面の大部分をカバーしつつ、インポートするスプライトのサイズを下げるために、そういう要素の PPU を下げることは許容されます。

ゲームをプレビューする

Unity で作業していると、ゲームビューの解像度がいくらで、ターゲットのプラットフォームでのアートの表示の正しいプレビューになっているのか気になるケースがあると思います。

このような場合に必要になるオプションの大部分は、ゲームビュー上部のスライダーの隣にあるドロップダウンの中に用意されています。

Low Res Aspect Ratios をオンにすると、Scale がデフォルトで 2 になることを確認してください。これは高 DPI スクリーンで DPI の低い環境をシミュレートするために、ピクセルを重ねて表示する必要があるためです

アスペクト比は横方向と縦方向の比率を固定するだけで、解像度はゲームビューのビューポートの解像度になります。つまり、モニターの解像度に依存することになります。そのため、アスペクト比を設定してスクリーン上で UI やオブジェクトの設定を行うことには意味がありますが、アートの見た目をチェックしても意味はありません。

アスペクト比を指定して、高 DPI スクリーンで作業している場合、Low Resolution Aspect Ratios(低解像度アスペクト比) チェックボックスがアクティブになります。このチェックをオンにすると、標準 DPI スクリーンの解像度をシミュレートした表示になります。

一方、Fixed resolutions(固定解像度)は、Unity が実際のサイズでウィンドウを描画するように強制します。この設定を有効にしたときは、プレビューの全体を見るためにゲームビューを広げたり最大化したりする必要が生じることがあります。Scale スライダーを使って、高解像度の画面をゲームビューウィンドウに収めて表示することができます。ただし、Scale が 1x 未満になっている場合は、リサンプリングされた結果が表示され、実際にその解像度で表示されるわけではありません。

こちらのビデオで、Retina スクリーン向けのサイズ設定の実用的な例を見ることができます。

ゲームビューの様々な使い方を解説する動画

また、独自の固定解像度やアスペクト比をドロップダウンに追加することもできます。

ヒント:エディターの表示だけを見て判断を下さないようにしましょう。どんなときでも、ゲームのビルドを作成(アートを表示するだけのものでもかまいません)して、ターゲットのデバイスやスクリーンでの見え方を確認してください。

補足

ここまでの内容から、アート素材の解像度、カメラのサイズ、そしてアプリやゲームの画面が表示されるスクリーンはすべてつながっています。また、それ 1 つですべてのケースをカバーできる、ピクセルサイズや PPU の設定はありません。ターゲットのプラットフォームについて調査し、解像度を決めて、ガイドラインを作成してチーム全体に周知しましょう。ここまで準備した上で、できるだけ高い解像度でアート素材を製作しましょう。あとで役に立つ場面がきっとあります。そして、必要な解像度にリサイズしてから Unity にインポートします。

最後にもう 1 つだけお伝えしたいことがあります。「ややぼやけた」という言葉を使って説明した部分が、絶対に修正しなければならないもののように思われたかもしれませんが、別に絶対的なルールというわけではありません。ゲーム中に解像度の足りないオブジェクトがあるかもしれません。特に、細かなディティールが多数表示されている場合、透過部分がフォグや雨の表現や、ポストプロセッシングのエフェクトと重なることがあります。さて、ここでゲームを普通の速度で遊んでみましょう。こうした画面の要素がリサンプリングされていることに気づいたでしょうか?

本気で違いがわからないなら、より高解像度のスプライトを表示するために追加の工数やディスク領域、あるいは追加の処理をかけるだけの価値はありません。名作ゲームにも妥協をした部分がたくさんあるのです!

#Unity2DChallenge

見た人を驚かせるような 2D アートを製作中ではありませんか?新しい 2D ツールに関心がありますか?
Unity が提供する、新しい 2D アニメーションツール、Tilemap、SpriteShape、Pixel Perfect パッケージ、または SVG インポーターを使って素晴らしい作品を作り上げ、Unity の 2D Challenge コンテストにぜひご参加ください。この記事を書いた私も審査員として参加します。みなさんの驚くようなアイデアに触れられることを楽しみにしています。

17 コメント

コメントの配信登録

コメント受付を終了しました。

  1. Excuse me but the camera size (Size property) is not half the size of the vertical viewing volume?
    You said it’s the total vertical size.
    Your words: ””telling you how many units this camera is framing on the vertical axis”’.
    Also your image of 5 Unit take all the vertical space… (it should take only it’s half part)
    Where am I wrong?

    1. Ciro Continisio

      11月 28, 2018 5:00 pm

      You are not wrong at all. The Size property is half the size, not the total. I made a mistake because of… reasons (it’s a long explanation) but I will amend the post now. Good one spotting it!

      The good news: even if the numbers are wrong, the whole reasoning behind it still stands!

  2. Oooooo

  3. We have answers for all those questions and even aspect ratios in this tool : https://assetstore.unity.com/packages/tools/sprite-management/integrator-tool-2d-25491

    Marek.

  4. This type of blog are super usefull! I have learned a lot even If I am 3D game maker. I would love to see a similar blog for making 3D Content in these days

    1. Ciro Continisio

      11月 20, 2018 11:19 am

      Thanks Adrian! What kind of 3D topic would you like being tackled?

  5. Why are we still having to manually add in resolutions… don’t you gather like a sh*tting ton of statistics, and could actually find the most common screen types/ resolutions and just make it easier to have those listed in a some usefully designed menu in the editor… where we can select them from most popular sizes by all the crap phone manufactures like scamsung crapple hauderp etc

  6. Why are we still having to manually add in resolutions… don’t you gather like a sh*tting ton of statistics, and could actually find the most common screen types/ resolutions and just make it easier to have those listed in a some usefully designed menu in the editor… where we can select them from most popular sizes by all the crap phone manufactures like scamsung crapple hauderp etc

    1. I don’t get your point… You are describing something that is already there! You have the MOST COMMON resolution in the aspect ration selector

  7. Strong oversights and limitations in Unity:

    1. first, you supply an awesome Vector class for SVG. We tested it today because we were investigating resolution-independent rendering. Everything went well until you decided to force everything to render to sprites and atlases.

    2. Your toolchain also ignores SVG/mesh/Vector style rendering, again causing problems with resolution independent rendering.

    It would be nice if Unity didn’t make the assumption that we wanted to use sprites. We do not. We wanted to use mesh data, sourced from SVG and were unable to easily do so, putting a hard limit on Unity’s usefulness.

    Instead we have to go back to 3D artwork and make it appear 2D instead.

    1. Ciro Continisio

      11月 19, 2018 9:47 pm

      You’re talking about the SVG Importer package as of 2018.2? Last time I tested it, it was turning SVGs into meshes and vertex colours, not Sprites. That’s why I’m confused by “force everything to render to sprites and atlases”.

    2. Let’s clarify, the VectorImporter could output 3 formats,
      Sprite (textureless): Uses vertex color to supply details, may still have texture for gradients

      Sprite (textured): The SVG is rendered into a texture and then a Sprite is created out of it. This sprite has a mesh that matches the outline and does not have use vertex color

      Texture2D: The SVG is rendered into a Texture2D. No Sprite is created.

      Does any of these output satisfy your needs? Are you expecting it to output a Mesh to be used with a MeshRenderer?

      1. I think the way flash used to work with vectors is the way its expected to work in unity.
        Zoom in all you want and still keep the sharp edges, this is not possible with a sprite or texture.

        So yes a 2d mesh generated from svg with a mesh render on top with a custom shader would be good.
        even better if the mesh could tesselate when getting closer to the camera to not show polygons but smooth lines.

  8. Posts like these a great. A bunch of this stuff I learned through trial and error, its nice to have them organized thoughtfully in one place. Would you consider adding “See Also” links in your documentation that links to blog posts like these?

    1. Note: we don’t even make 2D games, but a lot of this information still applies for 2D UI assets!

  9. Amazing news! When is expected to hit a release build or package?

    1. Hi JL!

      This is not a new feature and has been built-into Unity for a long time (Since 4.3!). No package needed. :)