理の世界

前回までの内容では決まったことだけを扱ってきました。
しかし決まったことをただやるだけなら動画で良いのです。
プレイヤーの操作に応じて展開が変わってこそゲームと言えるのではないでしょうか。

今回からはゲームをゲームとして動かすためのプログラミング入門編です。

今回は全体の概要を解説します。
現時点で理解できなくても構わないので、概要だけ覚えておきましょう。

●そもそもコンピュータプログラムとは？
   世の中には様々なソフトウェアプログラムがあるわけですが、
   それがどういった性質を持つものなのか、考えたことはあるでしょうか？

   画面も機能も操作方法も千差万別なプログラム群があっても、
   本質的には「コンピュータが何をすれば良いのか」を記述した台本(命令リスト)です。

   そしてソフトウェアは論理によって作られた存在です。
   ソフトウェアが扱うものには通常偶然やランダム等というものはなく、全ては必然に進みます。
   (実際にはソフトウェアを動かすハードウェアが完全ではないので本当の意味ではこれは成されていません)
   この論理による必然だけの世界を「理の世界」とでも呼ぶことにして、本章で扱っていきます。

   ソフトウェアにおけるバグとは人間が作った台本の誤りです。
   理の世界において全ては台本の通りに進みます。
   台本に誤りがあれば必然に「台本の通りに」間違っていき、これがいわゆる「バグ」なわけです。

●「プログラム」という概念
   プログラムがどのように構成されている(あるいは構成されるべき)かについては、
   色々な考え方が存在しており、統一された結論は示されていません。

   本章では筆者が使用している考え方を扱います。
   世の中にある考え方の中には互いに矛盾する関係になるものも多く、中途半端に混ぜると混乱の元になります。
   複数の考え方に触れる場合はそれぞれがどういう立場にあるものかを見失わないように注意してください。


   さて、筆者が使用しているのは「オブジェクト指向」から変化させた独自のもので「事象指向」と呼んでいます。
   この考え方では、プログラムは「事象」と「オブジェクト」によって構成されると解釈します。


   ここで「事象」とは「何らかの要求」や「何らかの現象」を示します。
   ゲームで言えば、例えば「新規ゲームの開始」「セーブデータのロード」といった「要求」、
   「キーが押された」「キーが放された」といった「現象」などが該当します。

   「事象」には至るべき「結果」が一つ以上定義されています。
   「事象」が生起(発生)した場合、それを処理するための担当者となる「オブジェクト」が指定されます。
   担当者となった「オブジェクト」は「事象」に定義されているいずれかの「結果」を実現しなければいけません。
   例えば「セーブデータのロード」事象の結果は
   「セーブデータの状態を再現してゲームを開始」するか、
   「セーブデータをロードせずに戻る」かのどちらかでなければいけません。
   「セーブデータのロード」事象の担当者になった「オブジェクト」はこのどちらかを実現しなければいけないのです。
   担当者がこのどちらも実現せずに事象を放置したとすれば、それは明確にバグであると言えます。
   担当者は事象に定義される「結果」を実現するために自分自身で処理する以外に以下のことを行うことができます。
      ●新しい「オブジェクト」を生成する
      ●自身が認識できる「オブジェクト」(自分自身を含む)を担当者として「事象」を生起する
      ●自身が管理する「オブジェクト」を消去する
   特に重要なのは「事象」の結果を実現するためにさらに「事象」を生起できる点です。
   プログラムは「事象」の連鎖によって構成される というのがこの考え方の肝です。

   また、担当者が事象に定義された結果をどれ一つとして実現できず、
   どうすることもできなくなった場合は「ギブアップ」することができます。
   事象が「ギブアップ」された場合は基本的にプログラムは異常終了されることになります。
   これはプログラムが定義されていない状態に陥ることは「最優先で避けるべき事態」であり、
   そのような状況に陥るぐらいならば異常終了してしまうべきという考え方です。


   「オブジェクト」とはプログラムを構成するあらゆる部品です。
   ゲームで言えば「キャラクター」や「アイテム」等はもちろん、
   「ウィンドウ」や「アニメーション」、果ては「計算式」等に至るまで、本当になんでもありです。

   「オブジェクト」には様々な種類(この種類のことを「型」と呼びます)があり、大きく以下に分類することができます。
      ●機械
         何らかの機能を持っているオブジェクトです。稼動状態を持つ場合もあります。
         処理できる「事象」も定義でき、対応可能な「事象」の担当者に任命することができます。
         最も多種多様な種類が存在します。
      ●データ
         何らかの単体、または複数のデータ集合です。
         そのデータが何の意味を持つのかは定義できますが、「事象」の担当者にはできません。
      ●規則
         何らかの規則やルールそのものです。
         別に対象を与えて規則やルールを「適用」したり、「事象」を間接的に扱ったりします。
         これは使い方が難しいので入門編では扱いません。

   また、「オブジェクト」は別の「オブジェクト」を自身の一部として組み込むことができます。
   自身の一部として組み込んだ「オブジェクト」は自身の裁量で自由に使うことが出来ます。
   これは 自身が機能を実現するために別の「オブジェクト」を使っても良い ということです。

   実際、ほとんどの「機械」分類の「オブジェクト」は中に別の「オブジェクト」を組み込んでおり、
   「オブジェクト」の全貌は木構造として表現することが可能です。
   この構造を辿っていくと通常、末端に行くほど小さな機能の「オブジェクト」になっていき、
   最終的に「データ」分類の「オブジェクト」に行き着きます。


   通常、プログラミング言語にはあらかじめそれなりの数の「型」が用意されていますが、
   多くの場合、自分で独自の「型」を定義することもできるようになっています。
   作ろうとしているプログラムの構成要素を適切に分解し、
   「型」として定義することにより開発やデバッグが劇的に楽になります。
   プログラミングの技術力とは概ね、 構成要素をどこまで適切に分解し、「型」として定義できるか に帰結します。
   なぜなら、同じ結果に辿り着くための構成はいくらでも存在し、その性能もいくらでも変化し得るからです。
   基本的に、プログラムの出来の評価としては以下のような軸があり、
   作るプログラムに求められる性質に応じてどれを重視するかを変更します。
   これはプログラミングで扱う技法には「どれかの軸を上げる代わりに他の軸を下げる」性質の技法が多数あり、
   そういった技法は重視項目かどうかで使うか使わないかを決める必要があるからです。

軸	概要
実行速度	処理をどの程度高速に行えるか。これが低いと処理落ちが起こりやすくなる。ゲームプログラムにおいては最も重要な軸。この軸を向上する技法にはその他の全ての軸を低下させる技法が多い。
メモリ効率	メモリをどの程度効率的に扱えるか。これが低いとメモリ消費が増大し、メモリ不足になりやすくなる。最近はPCのメモリ搭載量が大きくなり軽視されがちだが、 Windowsの32bitアプリケーションでは1プロセスあたり2GBまでしかメモリを使用できないため、メモリ不足でクラッシュするアプリケーションは増加傾向にある。この軸を向上する技法には難しいものが多く、特に保守性、可読性、安定性を低下させる技法が多い。
保守性	バグの発見や修正の容易さ。これが低いとバグの原因特定や修正が難しくなる。修正を繰り返してもバグがなくならないような場合、これが致命的に低い可能性がある。最近はPCの性能に余裕があるため、可読性、拡張性と合わせて重視項目として選ばれやすい。特性としては可読性、拡張性、安定性と連動しやすく、設計時点で大枠の値が決まる。
可読性	プログラムの理解のしやすさ。これが低いとプログラムの理解が難しくなる。自分で書いたコードがわからなくなるような場合、これが不足している可能性が高い。最近はPCの性能に余裕があるため、保守性、拡張性と合わせて重視項目として選ばれやすい。特性としては保守性、拡張性と連動しやすく、設計時点で大枠の値が決まる。
拡張性	プログラムの仕様変更、機能拡張のしやすさ。これが低いと仕様変更や機能拡張が難しくなり、一定水準に満たない場合、仕様変更や機能拡張時に保守性や可読性が低下するようになる。いじるほどプログラムがぐちゃぐちゃになっていく場合、これが不足している可能性が高い。設計時点で大枠の値が決まってしまうため、このような場合はプログラム全体を作り直した方が良い。最近はPCの性能に余裕があるため、保守性、可読性と合わせて重視項目として選ばれやすい。特性としては保守性、可読性と連動しやすく、設計時点で大枠の値が決まる。
安定性	プログラムの異常耐性。これが高いと異常が発生した時に影響を受けにくくなる。異常状態への対処は正規の処理手順よりも複雑な場合が多く、これを高めるには高い技術力が必要となる。この軸を向上させる技法は可読性を低下させる技法が多い。
セキュリティ	プログラムのセキュリティレベル。これが低いと細工した入力によって不正な操作が行われやすくなる。ネットワーク通信を扱うプログラムでは特に重要な軸。これを高めるには入力データの流れを正確に追う解析力や適切に穴を塞ぐ技術力が必要になる。この軸を考慮した場合、スクリプト言語によくある`eval`関数など、「できることが多すぎる機能」は非常に使いづらい。

[前へ] [目次へ] [次へ]

最終更新 2017/07/03