先月末の記事の中で、プログラムの知識がない人間でも
実データの作成を行うことがあると書きました。
例えばゲーム中のイベントシーンで、
キャラがどんなセリフを言うか、どう動くか、
カメラワークはどうするか、その他どういったタイミングで
そういう演出効果を入れるかといった具体的な指示は
プログラマが直接プログラムの中に書くのではなく、
別個のスクリプト（※１）によって管理されることが一般的です。
他にも、例えばシミュレーションゲームにおける
ユニットのパラメータなど、バランス調整にかかわる部分も
プログラムに埋め込むのではなく、
別個のテーブルファイル（※２）で管理します。
（※１）スクリプト--------------------
プログラムほどの専門知識がなくても書くことができる
平易な命令ファイル。記述規則と、それに対応した動作は
プログラム側で設定される。普通のテキストエディタで
作成できるものから、専用のツールで作成するものまで、
プロジェクトの都合に合わせて様々な種類がある。
----------------------------------------
（※２）テーブルファイル--------------------
スクリプト同様、専門知識がなくても書けるパラメータ指定ファイル。
中身は数字が羅列されているようなものが多く、
どの数字が何の意味を持つのかはプログラム側で設定されている。
これも普通のテキストで書かれているものから、
カンマ区切りのcsv（エクセル等で編集可能）になっているもの、
専用のツールで作成するものと、プロジェクト都合で形式は様々。
----------------------------------------
つまり、前述の記事でも書いた通り、プログラマが作るのは
データそのものではなく「データを動作させるための土台」なのです。
「Ａと記述したらＡ´の動作をする」と定義するのがプログラムで、
実際に「Ａ」と書くのがスクリプトだったりテーブルファイルです。
プログラマも仮動作させるために適当に「Ａ」を書くことはありますが、
ちゃんとした「Ａ」を記入するのは別の人が担うことが多いのです。
こうやって切り分けることの利点としては、
「プログラマ以外でもデータ作りに参加できて効率が上がる」ことや
「デバッグしやすくなる（バグが出にくくなる）」ことが挙げられます。
ちなみに、こうした切り分けを行わずに、プログラムソースの中に
直接「Ａ」を書いてしまうことも可能といえば可能です。
いえ、可能というよりは、むしろその方が
プログラマとしての作成負荷は軽くなります。
「このファイルのここをこういった意味の数値として参照しろ」と
定義するよりは、「数値はこうだ」と直接書いてしまった方が
面倒なことを考えずに済んで楽だからです。
こうしたことから、技術力や経験の低いプログラマほど
このような「決めうちプログラム」を作りがちになります。
しかし、こうした数値を直に定義するような手法は
「ハードコーディング」と呼ばれていて、一般論的には
「ダメなプログラミングの典型例」とされています。
なぜなら、ハードコーディングしてしまうと
・ 調整しようと思ってもプログラマ本人にしか手が出せない
・ 調整するたびにコンパイルしなおしになるので効率が悪い
・ いじるべき場所が複数に分散してしまうことがあり、忘れ易い
（→つまりバグを生みやすくなる）
・ 後で攻略本用のデータをまとめる際にすごく大変
といった弊害が生まれ、一言で言うと
「非常にチューニングがしづらい」環境になってしまうからです。
チューニングがしづらいとバランスが悪いゲームとなり、
バランスの悪さはすなわちデキの悪さに直結します。
とはいうものの、ありとあらゆるパラメータをすべて
外部参照できるようにするとなると、
（それは理想かもしれないけど）プログラマ側の負荷も
かなり重くなってしまいます。
そのため、現実には、頻繁に書き換える必要がある可能性が
高いものだけハードコーディングの対象から外し、
後は必要に応じてプログラマが対応する……
といった折衷的手法をとることもよくあります。
その際、どこまでをハードコーディングし、
どこからを調整できる項目として外部参照にするかといったことは、
プランナーやプログラマのセンスが問われる部分であり、
ここの勘所が悪いとプログラマに必要以上な負担をかけてしまったり、
後からの調整が難しいガチガチのプログラムになってしまったりします。
実データの作成を行うことがあると書きました。
例えばゲーム中のイベントシーンで、
キャラがどんなセリフを言うか、どう動くか、
カメラワークはどうするか、その他どういったタイミングで
そういう演出効果を入れるかといった具体的な指示は
プログラマが直接プログラムの中に書くのではなく、
別個のスクリプト（※１）によって管理されることが一般的です。
他にも、例えばシミュレーションゲームにおける
ユニットのパラメータなど、バランス調整にかかわる部分も
プログラムに埋め込むのではなく、
別個のテーブルファイル（※２）で管理します。
（※１）スクリプト--------------------
プログラムほどの専門知識がなくても書くことができる
平易な命令ファイル。記述規則と、それに対応した動作は
プログラム側で設定される。普通のテキストエディタで
作成できるものから、専用のツールで作成するものまで、
プロジェクトの都合に合わせて様々な種類がある。
----------------------------------------
（※２）テーブルファイル--------------------
スクリプト同様、専門知識がなくても書けるパラメータ指定ファイル。
中身は数字が羅列されているようなものが多く、
どの数字が何の意味を持つのかはプログラム側で設定されている。
これも普通のテキストで書かれているものから、
カンマ区切りのcsv（エクセル等で編集可能）になっているもの、
専用のツールで作成するものと、プロジェクト都合で形式は様々。
----------------------------------------
つまり、前述の記事でも書いた通り、プログラマが作るのは
データそのものではなく「データを動作させるための土台」なのです。
「Ａと記述したらＡ´の動作をする」と定義するのがプログラムで、
実際に「Ａ」と書くのがスクリプトだったりテーブルファイルです。
プログラマも仮動作させるために適当に「Ａ」を書くことはありますが、
ちゃんとした「Ａ」を記入するのは別の人が担うことが多いのです。
こうやって切り分けることの利点としては、
「プログラマ以外でもデータ作りに参加できて効率が上がる」ことや
「デバッグしやすくなる（バグが出にくくなる）」ことが挙げられます。
ちなみに、こうした切り分けを行わずに、プログラムソースの中に
直接「Ａ」を書いてしまうことも可能といえば可能です。
いえ、可能というよりは、むしろその方が
プログラマとしての作成負荷は軽くなります。
「このファイルのここをこういった意味の数値として参照しろ」と
定義するよりは、「数値はこうだ」と直接書いてしまった方が
面倒なことを考えずに済んで楽だからです。
こうしたことから、技術力や経験の低いプログラマほど
このような「決めうちプログラム」を作りがちになります。
しかし、こうした数値を直に定義するような手法は
「ハードコーディング」と呼ばれていて、一般論的には
「ダメなプログラミングの典型例」とされています。
なぜなら、ハードコーディングしてしまうと
・ 調整しようと思ってもプログラマ本人にしか手が出せない
・ 調整するたびにコンパイルしなおしになるので効率が悪い
・ いじるべき場所が複数に分散してしまうことがあり、忘れ易い
（→つまりバグを生みやすくなる）
・ 後で攻略本用のデータをまとめる際にすごく大変
といった弊害が生まれ、一言で言うと
「非常にチューニングがしづらい」環境になってしまうからです。
チューニングがしづらいとバランスが悪いゲームとなり、
バランスの悪さはすなわちデキの悪さに直結します。
とはいうものの、ありとあらゆるパラメータをすべて
外部参照できるようにするとなると、
（それは理想かもしれないけど）プログラマ側の負荷も
かなり重くなってしまいます。
そのため、現実には、頻繁に書き換える必要がある可能性が
高いものだけハードコーディングの対象から外し、
後は必要に応じてプログラマが対応する……
といった折衷的手法をとることもよくあります。
その際、どこまでをハードコーディングし、
どこからを調整できる項目として外部参照にするかといったことは、
プランナーやプログラマのセンスが問われる部分であり、
ここの勘所が悪いとプログラマに必要以上な負担をかけてしまったり、
後からの調整が難しいガチガチのプログラムになってしまったりします。