狀態機源自編譯原理，聽起來學術氣息濃厚，實則是「分支選擇結構」的工程化落地。為何在遊戲開發中反復強調它？因為它是將複雜問題分解為可管理單元的最佳工具。再龐大的遊戲邏輯，拆解為有限狀態集合後，皆可逐個擊破。
以典型遊戲為例，可劃分為：Logo 展示、主選單、玩家操控、暫停選單、遊戲結束等頂層狀態。每個狀態內部可再細分子狀態，層層遞進直到邏輯單元足夠簡單。核心迴路往往採用 switch-case 分發：
public void gameLoop() {
switch(gameState) {
case GS_Logo: logic_Logo(); break;
case GS_MainMenu: logic_MainMenu(); break;
case GS_PlayerControl: logic_PlayerControl(); break;
case GS_PauseMenu: logic_PauseMenu(); break;
case GS_GameOver: endGame(); break;
}
}開發前繪製狀態轉換圖至關重要，它能直觀呈現狀態流轉邏輯，避免遺漏邊界條件（如 AI 狀態機中常見的「未處理所有可能狀態」錯誤）。簡單 AI 可心中構想，中等複雜度則必須落筆成圖。
「渲染」即 render，在 J2ME 中專指繪製操作。受限於 MIDP 架構，所有繪圖代碼必須置於 paint(Graphics g) 回調中。雖可用 MutableImage 雙緩衝離屏繪製再 drawImage 上螢幕，但多數手機硬件已原生支援雙緩衝（paint 參數直接來自後台緩衝），額外緩衝層反而浪費寶貴記憶體。
實戰中渲染同樣按狀態分派：gameLoop 根據幀計數器決定下一幀顯示內容，paint 僅負責提交繪圖指令。甚至可將邏輯與渲染合併於 paint，因其由 repaint() / serviceRepaints() 每幀強制觸發，省去額外執行緒。
分層渲染順序決定視覺遮擋關係：
專業引擎鮮用 MIDP Game API 的 Sprite/TiledLayer，多自研核心模組以獲極致效能與移植靈活性。初學者可借鑒 API 學習，切勿產生依賴。
進階渲染效果（Alpha 混合、粒子系統、光影）本質皆為像素級運算。早期機型受限於 CPU，僅能謹慎使用；隨硬體升級，這些技術逐漸成為標配。
場景不僅是視覺地圖，更承載物理層（碰撞）與事件層（觸發器）。主流採用 Tile 拼貼：二維陣列映射地圖格子，每格索引對應一張 Tile 圖片。為編輯便利，通常配套所見即所得地圖編輯器，輸出二進制地圖文件。
大地圖需實現卷軸：視螢幕為攝影機，僅繪製可視區域內的 Tile（含部分覆蓋的邊緣 Tile）。邏輯座標統一用地圖座標，渲染時轉屏幕座標：screenX = (mapX - camX) * tileW。此即自製簡易 TiledLayer 核心；商業引擎更進一步支援 2.5D 斜視角、脏矩形更新、視錐剔除等優化。
碰撞檢測查詢物理層陣列：計算角色下幀目標格子，若該格不可通過則阻攔移動。精度與資料量權衡下，地形碰撞常用格子級檢測；特殊物體則提升為角色實體參與精確碰撞。
角色涵蓋 NPC、主角、道具箱等一切場景實體。基礎數據結構含座標、速度、圖片引用；RPG 再擴充屬性表。繪製核心是幀序列動畫，由 AI 驅動狀態切換動作。
進階採用組合精靈（紙娃娃系統 Avatar）：將角色拆解為身體、武器、裝備等部件，運行時動態組裝，實現換裝/換武器。需專用編輯器維護部件掛點、層級、遮擋關係——工具鏈開發同樣是程序員核心職責。
角色碰撞採用幾何近似：RPG 用單一矩形包圍盒，格鬥需多矩形/圓形/三角形貼合動作幀。檢測時機為「角色移動時」，遍歷場景角色陣列做矩形相交測試。主角由玩家輸入驅動，其餘由 AI 邏輯控制（此處 AI 泛指行為腳本）。
場景與角色構成遊戲雙支柱，開發主線即：設計場景 → 設計角色 → 編寫 AI → 迭代打磨。
