ゲーム製作における当たり判定プログラム

うちの大学では、大学1年目の学生にXを使って、半期で簡単なゲームを作ることを目標にするというプログラムの授業がありました。使用言語はC/C++です。教える項目は、変数、条件分岐、繰り返し、クラスを教えて、研究室で作成した便利な描画機能を持った簡単なXのライブラリを使ってもらいゲームを作成するというものです。自分はこの授業の演習の時間の補助みたいな仕事をやっていました。
ただでさえ人数が多いのに、Xを用いたグラフィカルなゲーム作りまで半期でやらせるというのは、チャレンジングな内容だったと思います。自然とアウトプットは学生のやる気にかなり左右されるわけで、よく出来た人と、明らかに人に教えてもらい無理無理で作った人と２極化していたように思います(予めプログラムをやっていた人は除く)。
ゲーム作りというのは独創的な作業で、教科書に載っている答えなどありません。そもそも最初のゲームデザインの段階で、その後の方向性は大きく変わりますから、画一的に教えることは不可能です。自然と自習の時間のような感じになり、個別にわからない所を指導するという形になりました。
その中でも、共通して多かったのがキャラとキャラがぶつかったという当たり判定に関する話。例えば、自機が■で敵が●だとしたら、どうやって当たったかを調べればいいのか？という話です。自機の上下左右の端の座標と、●の外周が接している(含まれている)か、をif文でゴリゴリ書くというのがオーソドックスです。これ系の質問は色々な生徒から聞かれました。これについては一回質問に答えてピンと来る学生とそうじゃない学生がいたように思います。
授業を受けただけでは、当たり判定について何故わからないんだろう？と思っていましたが、ビジュアル言語ViscuitのWikiページに次のようなコラムが載っていて、目からうろこが落ちました。

で画面の表示が面白いのですが，当時のコンピュータにはキャラクタービデオRAMという仕掛けで文字を表示していました．これはコンピュータのメモリーのある番地と画面の場所とが1対1で対応していて，例えば，0xf300番地は左上の文字で，ここにアスキーコードを書くと画面にそのコードの文字が現れるというものでした．
これはプログラムから見ても大変便利で，例えばインベーダゲームを作ろうと思うと，ミサイルが進むときに何かに当たるかどうかというのは，ミサイルの進む先にあるメモリーを読んで，空白だったらそのまま進む，インベーダだったら爆発する，というように実に簡単に判定できるんです．
(中略)
ここでいう爆発のマークというのがミサイルからインベーダへのメッセージなんですが，そのメッセージが画面を通して送られている，というのがミソなんですね．こういうのを当時は「場を通じた通信」とか言ってました．

ところが，その後ビットマップディスプレイが登場して，ハードウェア的には同じようにメモリーと１ドットが対応しているので，画面に点がかかれているかどうかは分かるのですが，絵は複数の点で表現しますから，いろいろと調べないと画面に何がかかれているかというのは，メモリーからはすぐには分からなくなってしまいました．それで，こういった画面を通信の場として考えるようなプログラミングスタイルは廃れてしまって，普通にオブジェクト指向で作るようになったわけです．

過去のベーマガプログラム(1980年代)には、その座標にあるアスキー文字がが"●"であるか"■"であるか、を調べて条件分岐するプログラムがたくさんありました。PC-8001用のプログラムとかが顕著です。これは上で述べられている「場を通じた通信」です。ここでは、モニター＝当たり判定の場であるということです。便利であると同時に作られるプログラムはかなり直感的なものになります。
しかし、現在は当たり判定用のマップを別に持って画面描画とは別のところで処理するというのが一般的です。例えば、シューティングゲームアルゴリズムの本では、当たり判定の例として、▲の形のキャラクターを■の形とみなして判定していることが多いです。これは、画面上では▲の形であるものが、当たり判定マップでは■の形をしているということです。
頭のいい人なら、今まで挙げたようなことはなんとなくわかってしまうけど、ゲーム作りをさせるならきちんと概念として教えるべきだったのかな？と、今となっては思います(自分は補助だったので実際に教える立場ではなかったけど)。
ちなみに、ゲーム専門学校などでは、どういう授業をしているんですかね？