複雑化
出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2021/06/06 20:25 UTC 版)
多く言われるのがゲームの複雑化である。実際にもこの「複雑化に伴う顧客減少」は、アーケードゲーム市場において80年代のシューティングゲームや90年代の対戦型格闘ゲームで既に見られた現象であった。任天堂もニンテンドーDSやWiiおよびその戦略に関するスピーチでこれらを例に採り上げたことがある。 内容の壮大さやストーリー性を重視している、やり込み要素が強いなど、ボリュームが多く、プレイに多くの時間がかかる作品。これらは見方を変えると「簡素に遊ぶことができない」作品となる（重たいゲーム）。 複雑化はシステムやストーリー要素以外にも、嗜好面におけるゲームデザインも該当する。これはある特定のアニメや漫画を題材とした、萌えなど特定の偏った嗜好を持つ一部のユーザーにのみをターゲットとしたなど、いわゆる「オタク向け」の作品がある。 これら「顧客を絞った」ゲームの増加による「ライト・カジュアルユーザー向け」もしくは「新規ユーザーの窓口」となる内容のゲーム作品が減少、およびそれに伴うコンシューマゲームへの「マニア・オタク向け」というイメージ形成によって、顧客離れや新規顧客の減少を招いたといわれている。 複雑化が加速した要因はいくつか存在するが、その1つとしてはゲームの高性能化によって開発コストの上昇などからメーカーがゲーム数を絞って製作し、その結果として確実な購入ターゲットが存在する（=利益が見込める）マニアを対象とした作品を重視していったことが上げられる。これら一人当たりで大きな消費活動を行うユーザーをターゲットとした商売は一元的に見れば利益の増加につながるものの、ゲームに限らずどのサブカルチャーにおいてもヘビーユーザーになるほど消費者人口全体からの割合は減少していく。その為に複雑化についていくことが出来なかった大多数の顧客が離れていってしまい、最終的にはユーザーの総数そのものが減少してしまうのである。 ダウンロード・インストール・アップデートなどでの長時間の拘束の問題も指摘されている。
※この「複雑化」の解説は、「ゲーム離れ」の解説の一部です。
「複雑化」を含む「ゲーム離れ」の記事については、「ゲーム離れ」の概要を参照ください。
複雑化
出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2020/11/19 07:07 UTC 版)
プロセッサの命令パイプラインは以下のような長さがある。 インテル P6マイクロアーキテクチャ（Pentium 3） - 11段 インテル NetBurstマイクロアーキテクチャ（Pentium 4） - 20段、Prescottは31段 インテル P6マイクロアーキテクチャ Yonah （Intel Core） - 13段 インテル Coreマイクロアーキテクチャ Merom （Intel Core 2） - 14段 インテル Nehalemマイクロアーキテクチャ（第1世代Core i） - 16段 インテル Sandy Bridgeマイクロアーキテクチャ（第2世代Core i） - 16段、μOp Cacheアクセス時は18段 ARM Cortex-A5 - 9段 ARM Cortex-A8 - 13段 ARM Cortex-A9 - 9〜12段 ARM Cortex-A15 - 15段（整数）、24段（浮動小数点数やNEON） Xelerator X10q - 1000段以上。 パイプラインステージが少ない実装では、一つのステージに一つの実行ユニットが対応しているが、一つの実行ユニットを細分化して次々に命令を送り込むスーパーパイプラインがある。たとえば、前節で示した3段のパイプラインそれぞれを2つに分割して6段として、Loadステージに注目すると、命令が供給されたらそれを途中までロードして次のLoadステージに供給する。同時に次の命令をロードする。その間、ふたつ目のLoadでは最初のLoadの続きを実行している。結果的に、2つの命令が同時にロードされていることになる。 パイプラインが長くなると、プログラム上の分岐が発生したときに不利であり、パイプライン全体をフラッシュする必要があるが、分岐予測によってある程度対処できる。分岐予測が不十分であれば、状況は悪化する。高性能計算などの特定分野では、滅多に分岐しないプログラムを書くことができ、パイプラインが長いほど性能向上が期待できる。分岐が頻繁に発生する場合、最も分岐しそうな方向の命令をパイプラインに供給することで、分岐予測の失敗によるパイプラインのフラッシュで生じる性能損失を低減できる。gcov などを使ってコード網羅率を分析する技法により、個々の条件分岐がどういう頻度で分岐するかを調べることができるが、そのような分析は最適化の最後の手段である。 実行コードに多数の条件分岐命令があると、パイプラインによるスループット向上は望めない。プロセッサが次に実行すべき命令を知ることができないため、条件分岐命令を実行して分岐先が決まるまで、パイプラインは空（バブル）になる。分岐先の計算が完了すると、次に実行すべき命令が決まり、パイプラインが再び機能するようになる。極端な場合、パイプラインの1ステージ以外全てのステージが空（バブル）になるなら、パイプラインのないプロセッサと性能に大差ない状況になり、むしろパイプラインのないプロセッサよりも性能は低下する（ステージ間のオーバーヘッドがあるため）。 命令パイプラインでは、プロセッサが読み込んだ命令は即座に実行されるわけではない。そのため、その時点のプログラムカウンタに非常に近い命令を書き換えても、既にその命令がプロセッサ内に取り込まれていて、効果を発揮しないことがある。キャッシュメモリがこの現象をさらに悪化させる。ただし、これが問題になるのは自己書き換えコードだけである。
※この「複雑化」の解説は、「命令パイプライン」の解説の一部です。
「複雑化」を含む「命令パイプライン」の記事については、「命令パイプライン」の概要を参照ください。
「複雑化」の例文・使い方・用例・文例
- 複雑化のページへのリンク
