2D遊戲中障礙物判定
TileMap
2.檢查這個拷貝與背景是否有碰撞
3.如果發現碰撞，運動停止。作出反應！
平滑TileMap
BitMask
不是用比較大的tile，使用一個圖片做背景，然後通過每個像素的檢查來識別碰撞。這種更細緻的處理，卻讓複雜度，和內存提高了很多。把每個像素想象成一個tile，然後實施一模一樣的算法。這個方案難以實施很大程度上是因爲斜坡的存在。對於動態場景也是適用的，比如可破壞的場景，不如憤怒的小鳥。向量
這種技術採用了向量數據（線或者多邊形）來判斷碰撞的邊緣。雖然實施起來很難，但由於物理引擎的大行其道，這個方案還是很受歡迎的。這個方案提供了bitmask的優點，但對於內存計算消耗不大，然後編輯圖層的方法也不相同。3D遊戲中的碰撞檢測
目前幾乎所有的3D程序的場景或者物體都是由許多三角形組成的。你需要記錄物體在上一幀的位置和當前幀的位置。
原理
首先，根據物體的運動規律或用戶的輸入計算物體在即將渲染的一幀（當前幀）時的位置（這時還不用考慮碰撞檢測的問題）然後，循環遍歷場景中每一個三角形。在循環過程中，作如下操作：1、找到當前三角形所在的平面，我們暫且稱之爲平面S。沿平面法線方向對它做一個平移d，表示物體和平面之間所能接近的距離。
2、判斷物體在上一幀和當前幀時的位置OldPosition、NewPosition與平面S的關係：如果上一幀在平面前，而當前幀在平面後，如下圖所示：
則進一步做3。
否則跳過3、4，做5。
3、因爲前後兩幀物體在平面的異側，說明物體穿過了平面S。但這時還不能說物體與三角形發生了碰撞，因爲平面是無邊界的,還需進一步判斷物體是否在三角形三條邊範圍之內穿過平面S。過三角形的三邊，做垂直於三角形的平面PS1,PS2,PS3。並且令它們的法線指向三角形的內部，如下圖所示：
爲了體現物體和三角形所能接近的最短距離，這三個平面也需要做一個平移L，只不過是沿着其法線負方向：
我們將依靠這三個平面來判斷物體是否是在三角形三邊所界定的範圍之內穿過平面S的。但是，如果三角形有很尖利的銳角，就會使其界定的區域過大，如figure4中所示。所以我們需要另外三個與它們平行的平面PS4,PS5,PS6 來削去產生的銳角(figure5)。產生這三個平面很容易，只需將PS1、PS2、PS3分別向它們的法線正方向平移到與之相對的頂點，再加上L。
現在，判斷物體位置是否在這六個平面之內，如果是，則做4，否則做5。
4、我們已經能夠確定物體與當前的三角形發生了碰撞，這時，修正當前幀的位置NewPosition，使物體的運動沿着與平面S平行的方向。
5、我們已經能夠確定物體與當前三角形沒有發生碰撞。使下一三角形成爲當前三角形，回到1。
當所有的三角形都遍歷了一次之後，物體的位置NewPosition就是經過碰撞檢測並修正了之後的。以該位置渲染物體和場景，並在下一幀之前，更新舊的位置爲當前幀的位置（OldPosition = NewPosition）。
總之，該算法的原理就是：給出一個三角形——判斷物體是否穿過了三角形所在的面——再判斷物體是否是在三角型內部穿過的。
高級碰撞技術
我們先假設碰撞沒有發生，然後更新物體的位置，如果發現發生了碰撞，我們將把物體移回原來的位置不允許它穿越邊界（或將物體銷燬或執行一些預防措施）。然而，這個假設太過簡單因爲我們無法得知物體原來的位置是否仍然有效。
但是我們的方法有缺陷，我們忘了在等式中加入時間。圖1告訴我們時間太重要了不能忘了它。即便物體在 t1 或 t2 時刻沒有發生碰撞，它仍有可能在 t 時刻穿過邊界（t1<t<t2）。這會在兩個連續幀中產生大幅度地跨越（就好象擊中了燃料室或其它類似的東西）。我們不得不找一個好的方法來解決這個問題。
我們可以把時間看成是第四維並將所有運算在4維空間中進行。然而這可能會讓運算變得十分複雜，所以我們會避開這些。我們還可以創建一個以 t1、t2時刻的物體爲起始點的實心體，然後用它來與牆進行測試（見圖2）
一個簡單的方法就是創建一個凸殼來罩住兩個不同時刻的物體。這種方法效率低下可能會明顯地降低你的遊戲速度。以其創建一個凸殼，還不如創建一個圍繞實心體的包圍盒。
判斷一個物體是否與場景中的其它物體相交。如果場景中有很多的物體，這個方法可能消耗很大。如果要判斷各物體與場景中其它物體是否相交，我們將不得不進行大概N選2次比較。
我們可以創建兩棵獨立的樹（每一棵對應一類物體），然後測試那些物體可能會碰撞的樹。我們甚至可以對環境進行約定讓一些碰撞物之間不發生碰撞――比如我們不需要在兩顆子彈之間進行判斷。現在在繼續之前，（經過改進之後）我們可以說處理過程變得更加清晰了。（另一個減少場景中成對的比較的方法就是建立八叉樹。
判斷一個物體的多邊形是否穿過了場景中的多邊形產生的運算量可能會很大。一個最簡單的碰撞檢測法就是用球形來近似地表示物體或物體的一部分，然後再判斷這些包圍球是否相交。這樣我們僅僅需要測試兩個球體中心的距離是否小於它們的半徑合（這表示發生了碰撞）。如果我們是用中心點距離的平方和半徑合的平方進行比較，那更好，這樣我們可以在計算距離時除去拙劣的開方運算。但是，簡單的運算也導致了精確度的降低（見圖3）。
我們僅僅是將這個不太精確的方法做爲我們的第一步。我們用一個大的球體代表整個對象，然後檢測它是否和其它的球體相交。如果檢測到發生了碰撞，那麼我們就要進一步提高精度，我們可以將大的球體分割成一系列小的球體，並檢查與各小球體是否發生碰撞。我們不斷地分割檢查直到得到滿意的近似值爲止。分層並分割的基本思想就是我們要儘可能達到適合需要的理想的情況。
用球體去近似地代表物體運算量很小，但在遊戲中的大多數物體是方的，我們應該用方盒來代表物體。開發者一直用包圍盒和這種遞歸的快速方法來加速光線追蹤算法。在實際中，這些算法已經以八叉和AABB（axis-aligned bounding boxes）的方式出現了。圖5展示了一個AABB和它裏面的物體。
座標軸平行（“Axis-aligned”）不僅指盒體與世界座標軸平行，同時也指盒體的每個面都和一條座標軸垂直。這樣一個基本信息就能減少轉換盒體時操作的次數。AABBs 在當今的許多遊戲中都得到了應用，開發者經常用它們作爲模型的包圍盒。再次指出，提高精度的同時也會降低速度。因爲 AABBs 總是與座標思平行，我們不能在旋轉物體的時候簡單地旋轉 AABBs --- 它們應該在每一幀都重新計算過。如果我們知道每個對象的內容，這個計算就不算困難並不會降低遊戲的速度。 然而，我們還面臨着精度的問題。假如我們有一個3D的細長剛性直棒，並且要在每一幀動畫中都重建它的AABB。我們可以看到每一幀中的包圍盒的都不一樣而且精度也會隨之改變。
平滑動畫
在遊戲中，通過增加確定的位移來改變某個事物的位置往往是不準確的，也會導致畫面不流暢。但是思考這種抖動產生的原因，我們可以受到很多啓發，我們是不是可以減少每次移動的距離，而增加移動的頻率來達到同樣的位置呢？這樣就可以大大降低畫面的違和感，而最高的頻率也就是和畫面繪製的頻率一致了，因此我們可以在每次繪製畫面的時候進行較小幅度的更新，而爲了擺脫兩次繪製之間的時間差的波動，我們需要計算時間差，更新幅度和時間差關聯起來。
戰爭迷霧
戰爭迷霧（Fogof War），在傳統意義上是指戰爭中由於對敵人情報不清楚而無法確認除友軍所在以外的大部分地區，敵人的分佈及活動情況。而目前在遊戲範圍內，尤其是即時戰略類遊戲中，這個詞語出現的頻率更高一些也更被多數人所熟悉。
從最初的即時戰略《沙丘2》開始，戰爭迷霧的概念開始被引入和正式提出。在沙丘中每一次新開始遊戲時，玩家只能觀察到自己基地及單位周圍極小的範圍，而絕大多數地圖區域均被黑色遮蓋。當他命令單位向黑暗區移動後，經過的區域會被自動打開，地圖變得可見，包括該區域的地形/敵人活動情況等等。這一經典模式也被絕大多數後來的即時策略遊戲繼承。
戰爭迷霧一般來說是“雙層”
第一層：地型黑霧（即連地理地形地貌都不可見只是黑色一片，地形迷霧實際上包含兩個含義：1.地形不可見 2.該區域尚沒有探索過
第二層：視野迷霧（即在友方單位不在的情況下，該區域視野丟失），這層迷霧就是暴雪設計的，單位視野也是包含其中，目前對於RTS來說單位視野是一個基礎屬性。
《命令與征服》之後，遊戲中的戰爭迷霧逐漸被普遍分割定義爲地圖層和單位層兩種，地圖層所包括的地形，由於很難改變或者根本不可能變化，在單位移開後仍然能保證其情報有效性，而單位層主要指該區域的活動單位之情況，由於不可能確保對方仍然停留，在我方情報源消失（如偵查單位移動開）之後，即會再次被遮蓋。對兩種層次的迷霧約定俗成，使用不同程度的黑色來區分，地圖層的黑色更深，而地圖層打開之後，遺留下的單位層迷霧相對更淡。以上這種戰爭迷霧形式相對更經典和受到普遍採用。
所謂的戰爭迷霧微操，就是利用戰爭迷霧在高坡以及樹林拐戰爭迷霧讓敵人丟失視野的路徑點角/樹林內部的隱藏特性來達到躲避敵方追擊的效果。比如坡上對坡下時，在坡上者未攻擊，也沒有任何能幫坡下者開視野的單位存在時，坡下是看不見坡上的。在即時戰略的發展中，另外出現了更多關於戰爭迷霧的變化及設計，比如將不同單位的打開迷霧的能力區分以體現不同價值，將戰爭迷霧的獲得能力與地形結合，站在高處能獲得更多視野，低處不能觀察高處。
地圖拼接與戰爭迷霧
