何時のゲームがと言う訳ではなく、ゲームを作る場合に
おいて、1つの画面で完結してるような構造物はないので、
基本的に、複数のシーンで構成されていることになってま
す。
マイコンとかの時代のBASICで処理する場合だと、CLS
で消して、バッファに先行読み込みで飽きておいたものを
描いて、それでシーンお切り替えをするなどですが、ゲー
ムエンジンの場合、そんな処理方法は存在しません。
また、BlenderのBGEも同様にそんな処理はしません。
基本的に、BGEを前提に書くと、こうした粗利は
【 シーンの構築をあらかじめ行っておく 】
ことで処理を可決させるわけですが、そうした場合に、
【 ゲーム自体の構造がしっかりと設計できている事 】
が前提になります。つまり、
【 何がどう移動するかと言う当たり前のツリー
構成とヒエラルキーが完成していないとどう
にもならない 】
わけです。現状において、ゲームについては、当た
り前にコ－ディングをこなったほうが出来る事は増
えるのですが、この処理に関しては、BGEだとコー
ディングなしで処理できるレベルの話なので、現在
の仕様とオッサンの昔話では相当温度差があるわけ
です。
とりあえず、オッサンの昔話レベルでも大丈夫な
ものとしては、プチコン辺りになるのですが、アレ
はBASICその物なので、考え方は全く同じです。
なので、
【 知ったかぶりだと即座にメッキが剥げる 】
と言ううそ発見器的な要素まであるので便利です。
まぁ、加速度センサーとか使った事のない機能が
あるので別としても、
【 互換性のある基本構文から組めないわけがない 】
ので、【 うそ発見器 】になるわけです。
あと、構文が簡単でBASICに近い物でいうと、LUA
がありますが、これはCやC++と連携して使う言語な
ので、単独では遅いため、そうしたモノを使う（組み
込みとの併用で重宝する言語です。）ような用途になっ
ていますが、構文を見るとBASICライクです。
ちなみに、BASICの知識で、今のPCで何か作ってみ
たいと思った場合だと、TinyBASICがそうですが、現在
熨斗世になっているんで、プチコンレベルで昔の処理と
は相当出来る事が違っています。
とりあえず、組み込み＋そのうえで処理から自分で
作ると言うアプローチの場合だと、処理が違うのです
が、オーサリングツールを使う場合だと少しよすが変
わってきます。
