「ゲームプログラミング」の版間の差分
削除された内容 追加された内容
703 行
画面表示のうち、3Dの表現は割合難しく、ある程度の数学（高校、あるいは場合によってはそれ以上）の理解が必要でしょう。2Dに関してはプログラムの面では、さほど難しい部分はありません。
== 処理速度の問題 ==
基本的にプログラミングでは、関数を使って、処理をコンパクトにまとめ、定数ではなく変数で柔軟性のある操作をすることが求められますが、ゲームの場合は、この構造のせいで処理速度が低下することがあります。
現在のCPUの性能、速さはかなり高くなってはいますが、プログラム処理は無限に煩雑化できますから、やはり高度な処理を短時間でなすことが求められます。特にゲームは、リアルタイムの反応のタイミングが非常に重要ですからね。数学の指数計算についての雑学で、「新聞紙を42回おりたたむと、月に届く距離になる」というものがあります。(新聞紙の厚さ)*2^42、です
ですが、このセクションで後述するように、関数を用いる場合の解決策（※概要:あとでdefineやinlineに置き換え）があるので、プログラミングの初期のほうは、とりあえずバグを未然防止するために関数を活用するべきでしょう。
1980年代頃のファミコンなど古い時代のゲームでは、ストレージ容量（ハードディスク容量のこと）が、ボトルネックでした。「容量不足でイベントをいくつか削りました」と、当時のRPGなどのゲーム作家が述べるのは、ストレージ容量の不足のことで
しかし2010年以降の現代では、ボトルネックになっている要因は、ストレージ容量不足よりも処理速度です。
ゲームプログラミングに要求されるコード特性は、科学計算ソフトウェアや金融プログラミングなどの手法とは異なります。情報工学・情報科学で適切とされる「構造化プログラミング」などの歴史的に発展してきたプログラミング・パラダイムの理念とは反するようなコード開発方針になる場合もあります
;ツクール
RPGツクールの制作元のカドカワ（アスキー社→エンターブレイン社→カドカワ（かつての「角川書店」） ）では、PRGツクールでのアクションゲーム開発は推奨していません。アクションゲームの場合は、同じカドカワの「アクションゲームツクール」で制作するよう、薦めています。
アクションゲームとターン制RPG では要求される特性が大きく異なり、なかには、ほぼ対立しているような性質もあります。
ツクールやウディタでも、けっして万能にあらゆることがスタマイズできるわけではなく、その制作ツールの特性に依存しますし、初心者には主に処理速度の低下しない部分についてユーザが創作できるようになっているでしょう。
多くのRPG制作ツールはマップ操作や戦闘画面の基本システムのルーチンそのものは、初心者にはあまりカスタマイズできません（カスタマイズするには高いスキルが必要）。画像や音楽は挿入できますが、例えば戦闘プログラムなら、「コマンド」の命令文など一部の派生的な部分だけが独自に作れる程度でしょう。
ですから、ツクールでどうしてもアクションRPGを作りたい場合、基本システムの改造はかなり困難だろうし、別途、アクションRPGのような動作をするマップイベントを作成する・・・ぐらいでしょう
ツクールやウディタでターン制RPG以外のジャンルを制作するのには、実質的には限界があり、さまざまな制約が生じます。
;C++での具体的な手法
初期段階では関数や変数を活用してプログラミングし、処理速度を高める必要がある箇所にだけdefineマクロ等を用い別の方法に置き換える。C++ならinline関数という機能もあります。
756 行
「共通性のあるコードだから」といって、大して長いわけでもないコードを関数に置き換える事は、速度維持には寄与せず、ゲーム制作のプログラミングとしては、悪手となるでしょう。
=== 2Dの画面出力 ===
画面出力の場合も入力機器の場合と同じで、これらを操作する方法はOSごとに異なっています。先ほどあげた GTK+, Qt, SDLなどのライブラリはクロスプラットフォームの画面出力を提供しているため、これらを利用することで全てのプラットフォームで動くプログラムを作ることができます。<!--画面出力を扱うためには近年の[[w:ビデオカード|ビデオカード]]の発展についても見る必要があります。しかし、ビデオカードの機能は2次元の描画に関してはあまりあらわには見えないので、この話題は3次元の描画を行うときに再び戻ってきます。-->
* [[ゲームプログラミング/ブロック崩し]]
* [[ゲームプログラミング/画面出力]]
==目次==
| |||