模板
教程
環境
性能
功能
管理
簡單的游戲結構
MILY: 宋體; mso-ascii-font-family: 'Times New Roman'; mso-hansi-font-family: 'Times New Roman'">一般來說，最常用的游戲結構是這樣的：游戲開始后即進入一個循環，每次循環做三件事情：
1. 獲取玩家的輸入。
2. 更新游戲狀態。
3. 刷新屏幕。
理論上說，刷屏的頻率在24Hz以上，人的眼睛看到的就是動畫了。
這個例子游戲的主循環是這樣的：
public void run() {
Graphics g = getGraphics();
Thread currentThread = Thread.currentThread();
try {
while (currentThread == gameThread) {
long startTime = System.currentTimeMillis();
if (isShown()) {
if (isPlay) {
tick();
}
render(g);
}
long timeTake = System.currentTimeMillis() - startTime;
if (timeTake < MILLIS_PER_TICK) {
synchronized (this) {
wait(MILLIS_PER_TICK - timeTake);
}
} else {
currentThread.yield();
}
}
} catch (InterruptedException ex) {
// won't be thrown
}
}
說明：
1. 兩個thread。currentThread當然就是當前執行的這個線程，那么gameThread當然也就是運行這個run方法的線程（不然while一開始就不成立，游戲就沒法運行了^_^）。這里它們的作用是控制游戲的循環，當一開始運行時，currentThread==gameThread，循環下去；當游戲需要退出時，將gameThread（類成員）設置為null，那么循環結束，游戲就退出了。強制結束某個線程是很不好的方法，sun的標準庫里早就deprecate這個方法了。
2. tick方法：處理玩家的輸入以及游戲狀態的變更。
3. render方法：顧名思義，繪圖。這里MIDP2.0相對于1.0有很大的改進，后面說。
4. 幾個long型的time的用處。代碼看起來很直觀，就是考慮到tick和render方法執行時間可能不固定，用time加以計算，得到需要sleep的時間。這樣的結果就是游戲畫面以一個固定的延時刷新，FixedDelay。當然，還有另外一種控制方式，即固定頻率的刷新，FixedRate。
a) FixedDelay：固定延時的好處是畫面看起來總是很流暢，而且一定不會出現跳幀的現象。
b) FixedRate：在一種情況下和FixedDelay有差別，即tick和render方法消耗的時間比預設的時間（MILLIS_PER_TICK）還長。FixedDelay這時不再wait，直接繪制下一幅圖；而FixedRate就不能繪了，否則頻率不固定。它的選擇是不繪這一幅，而是直接進入下一個循環，更新游戲狀態，綜合計算時間，繪下一幅圖——于是產生了跳幀。
像CS或星際這樣的游戲，跳幀是必須的，因為聯機游戲必須保證各方的圖像顯示的同步，不固定刷新頻率會導致錯誤。而像仙劍之類的單機游戲倒是可以考慮用固定延時，因為不跳幀不會產生什么錯誤，同時也可以增加游戲畫面的流暢性。
繪圖：
private void render(Graphics g) {
// Set Background color to beige
g.setColor(0xF8DDBE);
g.fillRect(0, 0, width, height);
g.setColor(0x0000ff);
// LayerManager Paint Graphics
layerManager.paint(g, 0, 0);
flushGraphics();
}
在MIDP1.0里面，Canvas的繪圖只能寫在paint(Graphics g)方法里，因為一來g參數在此方法結束后就沒有意義了，保留它的副本沒有用處；二來此方法由平臺調用，而不是由Canvas這個線程調用。因此在MIDP里繪圖總是一件很痛苦的事情，特別是需要保證Canvas線程與調用paint的那個線程同步（J2me的Specification說的是，可以保證你repaint了以后，paint方法在之后的某個時刻被調用，但不能保證馬上就被調用，因為paint是個比較耗時的方法，它無法確定其他的paint是否及時完成了）。
在MIDP2.0里，有所改進了。首先是你可以通過GameCanvas的一個方法getGraphics來獲取那個g，然后這個g就永不失效了（當然是在這個GameCanvas的生命周期內）。當然，這個g和1.0里的還是有所區別。這個g實際上是畫在一塊緩沖“畫布”上，即內存里。完全畫好以后，再用flushGraphics刷到屏幕上。緩沖的好處是可以讓屏幕在畫時不顯得閃爍，很有用的東西。flushGraphics還有另外一個作用，就是強制輸出，以達到顯示的那個線程與游戲控制線程的同步（這也是為什么做時間協調時，要把顯示方法所消耗的時間也計算進來）。
Tick…………暫時先不討論。
