《星際》、《魔獸》、《文明》……這些都是PC游戲玩家們耳熟能詳的名字，可以說以這些游戲為代表的戰略游戲是PC游戲的典型代表，戰略游戲的玩家也是眾多PC游戲類型裡忠誠度最高的玩家。戰略游戲分為回合制和即時戰略兩類，兩種戰略游戲都有數量眾多玩家，而後者更因為緊張激烈的游戲性逐漸壓倒了回合制戰略游戲，近幾年來，一直在戰略游戲中占統治地位。
在“J2ME平台上開發網絡即時戰略游戲”，這個話題在現今大多數J2ME 開發者聽來無異於天方夜譚。即時戰略游戲名字的“即時”兩個字決定了復雜的運算和數據交互、穩定快速的網絡連接要求、龐大的資源和繪制任務，我們都知道J2ME設備的資源和性能都極為有限，現有GPRS網絡業不盡如人意……這些似乎都成為了在J2ME上開發網絡即時戰略游戲不可逾越困難。
困難實實在在的擋在我們面前，但中國三億手機用戶中蘊藏的龐大的潛在即時戰略玩家促使我們去克服這些困難，只要還有一點可能，我們也要去尋找一條跨過這些障礙的道路。怎麼樣才能在手機上實現網絡即時戰略游戲呢？
從性能和用戶量考慮，我們選擇諾基亞的60系列作為初期的開發平台。
我們不考慮采用HTTP協議，雖然它是J2ME設備中普遍采用的協議，但其相對SOCKET的低效性和本身是無連接協議決定了它不適合即時戰略這種游戲形式。從上表可以看出建立連接的時間要高出連接後的數據傳送時間許多，HTTP協議需要花費許多額外開銷在建立連接上；HTTP平均的數據傳送時間也要比SOCKET高許多。我們測試了大部分的60機型（7650, 3650, 3660, 6600, N-GAGE, N-GAGE QD），所有測試的機型均支持socket。
從上表可以看出，socket連接數據往返一次的平均時間在1 ～ 2秒間，這對回合制的戰略游戲或許足夠，但對即時戰略游戲來說還是太長了。有什麼辦法能大幅壓縮數據傳送的時間呢？
我們可以從server和數據包協議考慮。
以上測試的服務器是用Serverlet寫的，而serverlet是構建在Web server上的，那麼這個數據裡包含的服務器反應和處理的時間就不容忽略了，為了獲得更快的響應和處理速度，我們必須重新設計和構建游戲的專用Server。傳送的數據包大小也是影響速度的一個關鍵。平時大家開發J2ME的網絡應用，習慣於用文本流來傳送數據，因為大多數應用Server端都是基於Web Server，而且采用文本表示信息非常直觀，也便於Server處理，但對於J2ME平台和gprs網絡來說，沒有經過壓縮的文本還是浪費了一些。
簡單考慮一下游戲服務器：一台主機應該能支撐一百到兩百名玩家同時在線；為了便於配置，Server應用應該是跨平台的，而客戶端也是J2ME的，因此Server的開發環境java當是首選；采用Java 1.4後新增的Java 異步通信功能，性能上也能達到我們的要求。
因為Server必須我們自己寫，所以沒有必要使用文本編碼協議，代之以字節流編碼。簡單估算一下，表示相同的信息，采用文本和字節編碼方式數據大小的比例大於4：1，而且數據本來以數字為主，省去了文本轉換的一大筆開銷。更小的數據相應的也帶來了更快的速度，另外，也為用戶節省了大筆昂貴的GPRS流量開支。
采取以上的措施後，我們再次測試了數據傳送的響應時間，平均小於1秒！也許在很多人看來，這個時間還是太長，達不到實時的要求，但應該知道，絕對的實時是不可能實現的，只要在策劃和開發中采用一些合理的策略，這小於1秒的延遲完全可以很好的掩蓋。
典型的PC即時戰略游戲如《星際》，在局域網對戰時實際上並不需要服務器的，對戰中的一台或多台客戶機充當了服務器的角色，即使是上戰網，戰網服務器完成的也只是社區管理的工作。在手機上實現不能采取這種結構：首先，通過GPRS網絡，兩部手機無法直接連接（不排除藍牙或紅外的互連，這不在我們的討論范圍內），只能通過服務器中轉；另外，手機的運算能力有限，為了游戲能良好的運行，必須把很多的運算轉移到資源相對更豐富的Server端，這和一般的CS結構中，盡量讓Client分擔Server的工作以使得Server能支撐更多的ClIEnt的做法背道而馳，也體現了J2ME網絡應用的特殊性吧：）
再簡單說一下整個系統的架構:
服務器按功能分為連接服務器、大廳服務器、游戲邏輯服務器、用戶管理服務器和日志服務器五種。視用戶的數量，如果數量很小，所有的服務器都可以置於一台主機中；隨著用戶量增多，各服務器可以移動到不同的主機中，通過調整各服務器主機的數量達到均衡負載。
