Codemasters* 社が GRID Autosport* を PC からタブレット向けに最適化してポールポジションを獲得

2015年1月19日

OpenCL* によるゴッドレイの HDR レンダリング

この記事は、インテル® デベロッパー・ゾーンに掲載されている「Taking the Pole Position: Codemasters Leads the Pack in PC-to-Tablet Optimization with GRID Autosport*」の日本語参考訳です。

モバイルデバイス向けゲームは人気が高く、売り上げが良いことは周知の事実です。より高性能な PC や最新の各種ゲーム機などもあり、グラフィックスを多用し、ストーリー性に富んだエクスペリエンスを求めるハイエンドのゲーマーにとって最高の状況と言えるでしょう。

このような状況において、開発者はハイエンドとモバイルのどちらをターゲットにすべきでしょうか? 現時点では、PC とモバイルの両方に対応するのが最良の策と言えるでしょう。この先もずっと、PC とモバイルは共存し、互いに補完しあっていくことが予想されます。2014 年 6 月に発売された大人気の GRID Autosport* を含むレーシングカー・ゲームの GRID* シリーズを開発しているイギリスの Codemasters* では、このアプローチを採用しています。

GRID Autosport* で Codemasters* 社は、インテルと協力して第 4 世代インテル® Core™ プロセッサーの性能を最大限に利用し、インテルの最新のマルチコア SoC ファミリーの 4W のインテル® Atom™ プロセッサー (開発コード名: Bay Trail) ベースのタブレットを含む広範なモバイルデバイスで優れたパフォーマンスを実現しています。

「我々にとって、市場全体をカバーすることが重要でした。トップエンドまで対応できる総合的なグラフィックス・オプションを備えつつ、タブレットでも優れたエクスペリエンスを提供できるゲームを目指しました」と、イギリス・サウサムにある Codemasters* 本社のシニア・プログラマーである Richard Kettlewell 氏は述べています。

図 1 は、インテル® Atom™ プロセッサー・ベースのタブレット上でデフォルトのグラフィックス・オプションでゲームを実行した場合と、より高品質な第 4 世代インテル® Core™ プロセッサー・ベースのタブレット上でデフォルトのグラフィックス・オプションで実行した場合の比較です。

図 1: インテル® Atom™ プロセッサー・ベースのタブレット上で専用のデフォルト設定で実行した場合 (上) と第 4 世代インテル® Core™ プロセッサー・ベースのタブレット上でより高品質なデフォルト設定で実行した場合 (下)

この記事では、Kettlewell 氏とその同僚でプロデューサーの Toby Evan-Jones 氏が、第 4 世代インテル® Core™ プロセッサーで利用可能な新しい手法とアルゴリズムにより目標を達成した方法を紹介します。プログラマブル・ブレンディング、アダプティブ順不同半透明描画 (AOIT)、アダプティブ・ボリューメトリック・シャドウマップ (AVSM) に加え、主に高頻度のディテールのシェーダーを調整することで超低電圧タブレットへのスケールダウンを実現しました。さらに、Codemasters* 社では複数の DirectX* スワップチェーンを調整することでデュアルスクリーン・オプションを実装し、一方のスクリーンでレースを異なる角度から見れるようにして、リビングルームとオンラインの両方でタブレット向けのゲームオプションを拡張しました。

マルチコアの登場からモバイルの爆発的な増加まで

Codemasters* 社は、プロセッサーの優れたグラフィックス・テクノロジー、CPU 性能、DirectX* API 向けインテル® Iris™ グラフィックス拡張を利用するべく取り組んでいます。その取り組みの成果として、昨年 GRID* 2 はイギリスのビデオゲーム・チャートの 1 位に輝きました (http://www.videogamer.com/xbox360/grid_2/news/uk_video_game_chart_grid_2_races_to_no_1_2.html (英語))。利用者の意見から、その要因は、煙パーティクルのシャドウとライティングの拡張、そして葉の透過処理の向上を含む 2 つのアルゴリズムであることが分かりました。AOIT および AVSM アルゴリズムは、第 4 世代インテル® Core™ プロセッサーの登場により、ゲーム内での利用が現実的になりました。

インテルと Codemasters* 社の出会いは数年前に遡ります。2000 年代半ば、デュアルコアおよびクアッドコア・プロセッサーへ移行する際、インテルは Codemasters* 社に技術サポートを提供し、マルチスレッド・コードの開発とテストを支援しました。これは、世界中のソフトウェア開発者が新しいチップ・アーキテクチャーの利点を利用できるようにするための取り組みの一環として行われました。その後、2013 年 5 月に発売された GRID* 2 で、インテルは Codemasters* 社と緊密に協力して、グラフィックスの最適化に取り組みました。そのときの様子を紹介したのが 2013 年 6 月のケーススタディーで、技術的な詳細は Kettlewell 氏とインテルのアプリケーション・エンジニアである Leigh Davies により、GDC 2014 において発表されました。

GDC 2014 における Richard Kettlewell 氏のプレゼンテーション (英語) は、こちらからご覧になれます。

**GRID Autosport* の新機能: プログラマブル・ブレンディングなど**

GRID Autosport* は、前バージョンで採用した AOIT と AVSM を拡張しています。省電力のタブレットとハイエンドの両方への対応に加え、GRID Autosport* には多くの新機能が追加されています。ここでは次の 3 つに注目します。

1 つ目は、PC をメイン・プラットフォームとし、PC 上でゲームが正しく表示され、効率良く動作するようにしています。PC のパフォーマンスは Codemasters* 社がターゲットとする各種ゲーム機をはるかに上回っており、ゲームプレイと売り上げに関しても急増しています。この傾向は、Codemasters* 社の社内データでも確認できます。「GRID* 2 の販売実績から、ゲーム機と比べて PC の売り上げが急増しているのに気付きました。」と Evan-Jones 氏は述べています。

PC の人気は、Codemasters* サーバーのオンライン・ゲームプレイのデータにも表れています。Steam* (PC ゲーマーが一般に使用するプラットフォーム) による Codemasters* サーバーへのオンラインゲーマーのアクセス数は、2012 年の第 1 四半期には 16% にすぎませんでした。1 年後、Steam* ゲーマーはオンライン・ゲームプレイ全体の 38% に増加し、この傾向は続いています。

2 つ目は、AOIT と AVSM に加えて、第 4 世代インテル® Core™ プロセッサーで利用可能なピクセルシェーダーの順序付けグラフィックス拡張によりプログラマブル・ブレンディングを初めて採用しています。この拡張を利用することで、色と明るさのブレンディングを細かく制御することができます。

3 つ目は、インテル® ワイヤレス・ディスプレイ (インテル® WiDi) を利用し、セカンドスクリーンでゲームを表示するオプションを追加しています。プライマリー・スクリーンにはプレーヤー視点の映像が表示され、セカンドスクリーンにはリーダーボードなどの追加情報を含むレース会場の観客視点の映像が表示されます。このセカンドスクリーンは、少し前に 10 億米ドルで YouTube に買収されるかもしれないと話題になった Twitch に代表される急成長のストリーム・ゲームプレイ市場への参入を含む、さまざまな可能性を広げます。Codemasters* 社によるセカンドスクリーン・オプションの実装方法は後述します。

より明るい光、より大きなハイダイナミック・レンジ

GRID Autosport* の設計と開発における主な目標は、これまでと同様に仮想空間でプレーヤーに魅力的かつ刺激的なエクスペリエンスを提供することでした。そのためには、ステアリングとトラクション、AI ベースの競争相手、時速 220km でヘアピンカーブを曲がるときの景色を含め、すべてをできるだけリアルにする必要がありました。

インテルの PixelSync (ゲームの特定のテクスチャー・サーフェスに対する読み取り/変更/書き込みを有効にする DirectX* 拡張) を利用することで、Codemasters* 社はリアルさを実現し、極めて重要なプレーヤーの没入感を得ることができました。このアプローチは、プログラマブル・ブレンディングを可能にし、特に車のフロントガラスから見える太陽光や投光照明において興味深い効果が得られます。GRID* 2 でこれらの光は、アーティストが求める明るさよりもはるかに暗くなっていました。「プログラマブル・ブレンディングは、シーンの残りの部分を暗くすることなく、太陽や照明の光を明るくすることができます」と Kettlewell 氏は指摘しています。

GDC のプレゼンテーションで、Kettlewell 氏と Davies は、プログラマブル・ブレンディング適用前と適用後のフロントガラスから見える太陽のイメージを紹介しました (図 3)。ハイダイナミック・レンジ (HDR) 値は対数的に R10G10B10A2 バックバッファーへエンコードされるため、エンコードされた値を固定関数でアルファ・ブレンディングしても意味がなく、半透明の背景の HDR 効果は得られません。この問題は、プログラマブル・ブレンディングにより線形空間でブレンドすることで解決できます。

図 3: フロントガラスから見た太陽のスクリーンショット – プログラマブル・ブレンディング適用前 (上) と適用後 (下)。出典: GDC 2014 における Kettlewell 氏と Davies によるプレゼンテーション資料 (スライド 27 と 28)。

AOIT と AVSM について

GRID* 2 と同様に、Codemasters* 社は GRID Autosport* でも AOIT と AVSM を採用しています。AOIT により、木々の葉やフェンスなどのレーストラック脇の半透明オブジェクトのレンダリングが向上しています。プログラマブル・ブレンディングと同様に、AOIT アルゴリズムもインテルの PixelSync を利用して特定のピクセルの読み取り/変更/書き込みの順序付けを行います。

Davies は OIT のサンプル実装を含む 2013 年 7 月のブログで、「ピクセルシェーダーの同期プリミティブで 2 つのピクセルをスクリーンの同じ位置にレンダリングする場合、1 つのシェーダーのみ実行することができます。どちらのシェーダーが実行されるかはフロントエンドに送られた順番によって決まり、1 つ目のシェーダーが実行を完了すると、もう一方のシェーダーが実行を再開します。」と述べています。(サンプルコードには、セットアップ、データの解決、レンダリングする UAV テクスチャーの説明は含まれません。2013 年の彼のブログにあるサンプル (https://software.intel.com/sites/default/files/managed/3d/a1/oit-pixelsynchronization.zip) が参考になるでしょう。)

void AOITSPInsertFragment(in float fragmentDepth,
                        in float  fragmentTrans,
                        in float3 fragmentColor,
                        inout ATSPNode nodeArray[AOIT_NODE_COUNT])
{
    int i, j;

    float  depth[AOIT_NODE_COUNT + 1];
    float  trans[AOIT_NODE_COUNT + 1];
    uint  color[AOIT_NODE_COUNT + 1];

    ///////////////////////////////////////////////////
    // AOIT データをアンパックする
    ///////////////////////////////////////////////////
    [unroll] for (i = 0; i < AOIT_NODE_COUNT; ++i) {
        depth[i] = nodeArray[i].depth;
        trans[i] = nodeArray[i].trans;
        color[i] = nodeArray[i].color;
    }

        // 挿入インデックスを見つける
    int index = 0;
    float prevTrans = 255;
    [unroll] for (i = 0; i < AOIT_NODE_COUNT; ++i) {
        if (fragmentDepth > depth[i]) {
            index++;
            prevTrans = trans[i];
        }
    }

    // 新しいフラグメントの領域を確保し、現在の曲線で新しいフラグメントを合成する
    // (新しいフラグメントを表すノードは除く)
    [unroll]for (i = AOIT_NODE_COUNT - 1; i >= 0; --i) {
        [flatten]if (index <= i) {
            depth[i + 1] = depth[i];
            trans[i + 1] = trans[i] * fragmentTrans;
            color[i + 1] = color[i];
        }
    }

    // 新しいフラグメントを挿入する
    const float newFragTrans = fragmentTrans * prevTrans;
    const uint  newFragColor = PackRGB(fragmentColor * (1 - fragmentTrans));
    [unroll]for (i = 0; i <= AOIT_NODE_COUNT; ++i) {
        [flatten]if (index == i) {
            depth[i] = fragmentDepth;
            trans[i] = newFragTrans;
            color[i] = newFragColor;
        }
    }

    // ノードが多い場合は処理をパックする
    [flatten]if (depth[AOIT_NODE_COUNT] != AOIT_EMPTY_NODE_DEPTH) {
        float3 toBeRemovedCol = UnpackRGB(color[AOIT_NODE_COUNT]);
        float3 toBeAccumulCol = UnpackRGB(color[AOIT_NODE_COUNT - 1]);
        color[AOIT_NODE_COUNT - 1] = PackRGB(toBeAccumulCol
                                          + toBeRemovedCol 
                                          * trans[AOIT_NODE_COUNT - 1] 
                                          * rcp(trans[AOIT_NODE_COUNT - 2]));
        trans[AOIT_NODE_COUNT - 1] = trans[AOIT_NODE_COUNT];
    }

// AOIT データをパックする
    [unroll] for (i = 0; i < AOIT_NODE_COUNT; ++i) {
        nodeArray[i].depth = depth[i];
        nodeArray[i].trans = trans[i];
        nodeArray[i].color = color[i];
    }
}

図 4: メインの AOIT コード

GDC で Kettlewell 氏と Davies は、タイル化されたメモリーアクセスによるメモリーの一貫性と全体のパフォーマンスの向上、マスク・テクスチャーによる使用帯域幅の軽減を含む OIT コード (図 5) に対するいくつかの最適化について述べました。

図 5: AOIT と AVSM でタイル化されたメモリーアクセスによりメモリーの一貫性を向上。出典: GDC 2014 における Kettlewell 氏と Davies によるプレゼンテーション資料 (スライド 17)。

元々、Codemasters* 社では OIT データ構造の読み書きを線形に行っていました。タイル化されたアクセスパターンに変更することで、フレームごとに 0.5 ミリ秒、合計フレーム時間の約 2% を短縮できました。タイル化されたメモリーを使用するというアイデアは、一般によく行われるテクスチャー・フォーマットを置換してメモリー・アクセス・パターンを最適化することからヒントを得ました。ピクセルに OIT データが含まれているかどうか示すフラグとして、クリアマスクを使用しています。これにより、指定された場所に OIT データが含まれているかどうか確認する際、多くの帯域幅を節約することができます。クリアマスクを使用する代わりに、OIT データを読み取り、初期化されているかどうか確認することができますが、この場合より大きなデータ構造を読み取る必要があります。

図 6 のコードは、AOIT でタイル化されたメモリーアクセスを実装します。

uint AOITAddrGenUAV(uint2 addr2D)
{
    uint2 dim;
    gAOITSPClearMaskUAV.GetDimensions(dim[0], dim[1]);
    return AOITAddrGen(addr2D, dim[0]);
}

uint AOITAddrGen(uint2 addr2D, uint surfaceWidth)
{
#ifdef AOIT_TILED_ADDRESSING

    surfaceWidth      = surfaceWidth >> 1U;
    uint2 tileAddr2D  = addr2D >> 1U;
    uint  tileAddr1D  = (tileAddr2D[0] + surfaceWidth * tileAddr2D[1]) << 2U;
    uint2 pixelAddr2D = addr2D & 0x1U;
    uint  pixelAddr1D = (pixelAddr2D[1] << 1U) + pixelAddr2D[0];

    return tileAddr1D | pixelAddr1D;
#else
    return addr2D[0] + surfaceWidth * addr2D[1];
#endif
}

図 6: AOIT でタイル化されたメモリーアクセスを実装するコード

半透明オブジェクトに差し込む光のシミュレーションには AVSM が使用されました。特に、車が発進し煙と埃が舞い上がるときの適用方法に注目してください。AVSM は AOIT と同様に動作しますが、ノードに色情報を格納する代わりに、シャドウマップの各ピクセルに透過曲線の圧縮された近似値と対応する光線を格納するため、煙と埃が舞い上がる様子をよりリアルに表現できます。削除するノードを決定するコードは、AOIT よりも複雑です。GDC プレゼンテーション資料から抜粋した図 7 のように、透過描画の下の領域をできるだけ変更しないようにします。

図 7: T透過描画と光源からの深度

図 8 に削除するノードを計算するコード例を示します。

void AVSMGenInsertFragment(in float fragmentDepth, 
in float  fragmentTrans, 
inout AVSMGenNode nodeArray[AVSM_NODE_COUNT])
{	
    int i, j;
    float  depth[AVSM_NODE_COUNT_CUT + 1];	
    float  trans[AVSM_NODE_COUNT_CUT + 1];	 

    /////////////////////////////////////////////////////
    // 単純にするため削除した AVSM データをアンパックする
		
    // 挿入インデックスを見つける
    int index = 0;
    float prevTrans = 1.0f;
    [unroll] for (i = 0; i < AVSM_NODE_COUNT_CUT; ++i) {
        if (fragmentDepth > depth[i]) {
            index++;
            prevTrans = trans[i];
        }
    }

    // 新しいフラグメントの領域を確保し、現在の曲線で新しいフラグメントを合成する
    // (新しいフラグメントを表すノードは除く)
    [unroll]for (i = AVSM_NODE_COUNT_CUT - 1; i >= 0; --i) {
        [flatten]if (index <= i) {
            depth[i + 1] = depth[i];
            trans[i + 1] = trans[i] * fragmentTrans;
        }
    }

    // 新しいフラグメントを挿入する
    [unroll]for (i = 0; i <= AVSM_NODE_COUNT_CUT; ++i) {
        [flatten]if (index == i) {
            depth[i] = fragmentDepth;
            trans[i] = fragmentTrans * prevTrans;
        }
    } 

    //  ノードが多い場合は処理をパックする
    [branch]if (depth[AVSM_NODE_COUNT_CUT] != AVSM_GEN_EMPTY_NODE_DEPTH) {
        // 削除できる可能性があるノードの合計数
        const int removalCandidateCount = (AVSM_NODE_COUNT_CUT + 1) - 1;
        const int startRemovalIdx = 1;

        float nodeUnderError[removalCandidateCount];
        [unroll]for (i = startRemovalIdx; i < removalCandidateCount; ++i) {
            nodeUnderError[i] = (depth[i] - depth[i - 1]) * (trans[i - 1] - trans[i]);
        }

        // 削除エラーが最も少ないノードを見つける
        int smallestErrorIdx = startRemovalIdx;
        float smallestError  = nodeUnderError[smallestErrorIdx];

        [unroll]for (i = startRemovalIdx + 1; i < removalCandidateCount; ++i) {
            [flatten]if (nodeUnderError[i] < smallestError) {
                smallestError = nodeUnderError[i];
                smallestErrorIdx = i;
            }
        }

        // ノードを削除する
        [unroll]for (i = startRemovalIdx; i < AVSM_NODE_COUNT_CUT; ++i) {
            [flatten]if (smallestErrorIdx <= i) {
                depth[i] = depth[i + 1];
            }
        }
        [unroll]for (i = startRemovalIdx - 1; i < AVSM_NODE_COUNT_CUT; ++i) {
            [flatten]if (smallestErrorIdx - 1 <= i) {
                trans[i] = trans[i + 1];
            }
        }
    }
    
    /////////////////////////////////////////////////
    // 単純にするため削除した AVSM データをパックする
}

図 8: 最も小さいエラーメトリクスの AVSM 計算

ほかのターゲット: タブレットバージョンの実装

第 4 世代インテル® Core™ プロセッサー向けの最適化は、Codemasters* チームが GRID Autosport* で行った取り組みの 1 つにすぎません。GRID Autosport* は、超低電圧版インテル® Atom™ プロセッサー・ベースのタブレットでも優れたエクスペリエンスを提供します。同じ実行ファイルで 4W ～ 300W の広範囲に対応できることは、時速 30km のゴーカートと時速 320km を超える F1 のどちらでも楽しめるレーストラックを設計するようなもので、驚異的と言えます。

タブレット対応バージョンの作成過程は、想定に反し、驚くべきものでした。Codemasters* チームは、最初に従来のアプローチに従って、ゲームの最小ハードウェア要件を緩和し、処理オーバーヘッドが大きいため排除しなければならない可能性のあるグラフィカル要素のリストを作成し、シャドウマップや環境マップのテクスチャー解像度を含むその他のスケーラブルな要素を減らしました。深度が大きいフィールドや最終処理のモーションブラーなどの効果を排除してみたところ、現在のピクセルシェーダーの多くが排除可能な冗長な作業を行っていることがすぐに明らかになりました。

既存のシェーダーを変更する代わりに、Codemasters* チームは別のアプローチを採用することにしました。通常の設定で反射マップを作成する最も単純なシェーダーを見つけ、それをメインスクリーンのレンダリングに適用することで、利用可能なデータで達成可能な効果のみを有効にしました。その結果、驚くべきことに、1 秒あたり 40 ～ 45 フレームの十分にプレイ可能なバージョンができました。

予想よりも良い結果が得られたため、各ビジュアル要素のゲームプレイへの影響と処理オーバーヘッドを考慮して、いくつかのビジュアル要素を戻すことになりました。必然的に、すべてのシーン要素が入れ替わり、レーストラック脇の観客や木々の 3D モデルが 2D のビルボードに変わったところもありましたが、排除リストにあったグラフィカル要素の多くは戻されました。ただし、ハイエンドバージョンの既存要素の多くは、より単純なものに変更されました。例えば、PC バージョンでは車が市街地を走り抜けるとき、ビルの動的な反射が車体に映りますが、タブレットバージョンでは静的な環境マップに変更されました。また、レース中の車を除くすべてのリアルタイム・シャドウが単純化されました。

このタブレット向けの設計から Codemasters* チームが学んだことは、最初にゲームから排除すべきオブジェクトについて考えるのは必ずしも最良のアプローチではないということです。Codemasters* 社では、主なモデルのほとんどのコードはそのまま残し、サーフェス・プロパティーをレンダリングするシェーダーを調整して高頻度のディテールを排除するだけで済みました。例えば、ゲームの多くのサーフェスで使用されているスペキュラー反射マップは、高解像度のデスクトップ・ディスプレイではその効果を確認できますが、10 インチのタブレットスクリーンでは、車のホイールを除く多くのオブジェクトでその効果を確認することは難しいでしょう。最終的に、スペキュラー反射マップは、ホイールと実際にその効果が確認できるオブジェクトでのみ有効にされました。道路のサーフェスやビルの窓のレンダリングが少しばかり鮮明でなくても、メインターゲットの普段ハイエンド PC でプレイしているゲーマーが、タブレットの小さな画面でその違いに気付く可能性は低いでしょう。しかし、PC バージョンで車の横にいた人がタブレットバージョンではいなくなっていたり、要素が削除されている場合は気付く可能性が高いでしょう。

多くのソフトウェアで言えることですが、ここで行った作業はさらなる利点をもたらします。Codemasters* 社では、タブレットバージョンで行ったシェーダーの改良により、ハイエンドシステムでも同じシェーダーを利用する反射マップの視覚効果とパフォーマンスが向上しました。コンピューティング・テクノロジーの基本機能は、時とともにより強力に、より安価になる傾向にあります。現在の一般的な PC 性能が、将来のタブレットや携帯端末で利用できるようになる可能性は高いため、中間層のゲームの保守とアップデートに取り組むだけでも将来的に意味があるでしょう。この事例から得られる教訓は、最適化への取り組みに終わりはないということです。

セカンドスクリーンとその有効活用

進化し続けるハードウェア性能とユーザーの嗜好に対応するため、Codemasters* 社は Miracast* を利用してデュアル・スクリーン・モード (図 9) を実装し、PC 画面には従来のドライバー視点の映像を表示し、セカンドスクリーンには TV で F1 レースを観戦するときのような観客視点の映像を表示しています。

図 9: Miracast* を利用してセカンドスクリーン (TV) に順位などの追加情報を含む観客視点の映像を表示可能

この機能は GRID Autosport* で実験的に追加されていますが、これにより Codemasters* 社はユーザーがこの機能をどのように利用しているのか理解し、携帯端末を TV に接続し同じイメージをより大きな画面で共有するという新たなシナリオに対応することができました。

ハイエンド・グラフィックス向けの最適化が最大の課題でしたが、Codemasters* 開発チームは、デュアルスクリーン機能の実装において他のいくつかの課題にも直面しました。その最も大きなものは、「フレームを表示するためのバッファー・コレクションである、複数の DirectX* スワップチェーンの作成でした」と Kettlewell 氏は振り返っています。MSDN では、「スワップチェーンを作成する場合は、すべてのスワップチェーンをウィンドウとして作成し、全画面表示に設定すると良いでしょう」としています。このアプローチは、ユーザー・エクスペリエンスの管理をより複雑にします。Codemasters* 社では、ほかのアプリケーションを表示したいユーザーもいることを考慮し、セカンドスクリーンの表示を強制するのではなく、ユーザーがゲームから選択できるようにオプションを提供したいと考えました。

当初、ゲームのエンジンに、ウィンドウループのコールバック関数で変更されるウィンドウのグローバルステートが格納されていることも問題になりました。ウィンドウの追加により、2 つの異なるディスプレイがこの関数を呼び出せるようになるため、グローバルステートで混乱が生じました。これは、追跡が非常に困難な問題です。Kettlewell 氏は次のように述べています。「複数のスワップチェーンは広くサポートされているものではありません。我々が使用しているソフトウェアでは問題が生じ、ベンダーによるドライバーのアップデートが必要になりました。全体を通して、セカンドスクリーンの追加作業は非常に困難でした。しかし、これは、2 つのスクリーンに異なるイメージを表示することが、いかに新しいアイデアであるかを示していると言えるでしょう。」

Miracast* のような新しいテクノロジーを採用することは、予想しない結果をもたらすことがあります。ゲームの発売から数日で、図 10 のようなイメージが Codemasters* 社のフォーラムに投稿されました。

図 10: HDMI* ケーブルによる従来のマルチモニターの一部としてセカンドスクリーンを利用した例

セカンドスクリーン機能に対する好意的な反応は、リビングルームにいてタブレット上で PC ゲームをプレイするといった新しい使用モデル向けのテクノロジーであっても、ゲーマーのエクスペリエンスを拡張するように考慮して実装すれば、ほかのプレーヤーにもメリットがあることを示しています。

Codemasters* 社にとって、さまざまなモバイル・ユースケースへの対応はこれまでにない新しいもので、タブレットのタッチスクリーンでゲームを操作する機能はリリースに間に合いませんでした。過去の GRID シリーズ作品はマウス操作をサポートしていないため、スクリーン上のイメージ座標からどの要素がクリック/タップされたか検出するための仕組みが既存のコードにはありませんでした。しかし、タッチ・ナビゲーションに対応したゲームが間もなくリリースされる予定です (図 11)。すでに、Davies により、Codemasters* チームがタッチ・ナビゲーションをテストする様子が撮影されています。「これは、GRID Autosport* のタブレット対応拡張の最後の 1 ピースと言えるでしょう。」と Evan-Jones 氏は述べています。

図 11: Davies により Codemasters* 社のオフィスで撮影された近日リリース予定のタッチ・ナビゲーション機能の動画

タッチはタブレット・エクスペリエンスを完全なものにするだけでなく、従来のタッチ対応のラップトップや Ultrabook™ デバイスで新しいプレイモードを可能にし、ユーザーが同じゲームを好みの入力コントロールで、どこでもプレイできるようにします。

どちらにも対応する

タブレットや携帯端末は、ハイテク業界によくある破壊的な技術革新なのでしょうか? そうであるかもしれませんし、そうでないかもしれません。確かなことは、PC からより小型の携帯端末に完全に乗り換えている人はほとんどいませんが、超低電圧の携帯端末は今後も注目され続けるでしょう。

「ハイエンド PC は非常に魅力的なセグメントですが、市場のほんの一部にすぎません。」と Kettlewell 氏は指摘しています。つまり、高性能で最先端の次世代 PC 向けにゲームを開発すべきか、それよりも性能の劣るタブレット向けにすべきかという問いに対する答えは 1 つです。両方をターゲットにすべきです。