第二章 編輯器的基本框架
一、幾個問題
前面說了很多編輯器之外的東西，真正要動手做編輯器了，也不能一股腦地就開始了，這之前必須要問自己幾個問題：
1、這個地圖編輯器有什麼基本功能？
2、導入導出文件格式？
A、3D地圖編輯器的基本功能
正如開篇所說，編輯器製作有兩種趨勢，其中一種是大而全的世界編輯器，這種方式可以帶給極大的成就感，正合很多新人的意，但是我覺得一開始給自己（特別是新人）設定一個龐大的計劃是件空洞而不現實的事情，一個編輯器越是大而全它的應用方向就越窄，越不利用拓展，使用就越費勁，問題BUG也就越集中，維護成本也就越高。
其實可以從小做起，先來分析基本需求：
所謂地圖編輯器，地圖編輯是其基礎功能，一般地圖都是在地形（平面）上面放置演員（把它叫作演員是不希望和OGRE的實體概念衝突），那麼我們就確定了我們兩個需求：地形編輯、演員管理。
那麼這兩個需求又引申出新的需求，地形不能是光模吧，演員不能永遠是編輯器預設的幾個模型吧，所以我們又需要實體、紋理加載與刪除的功能。加載之後的紋理和實體總應該有個地方可以瀏覽吧，不然怎麼選擇使用？
好了，因爲我們的目標暫時是做一個基本框架。所以我們暫時確定以下基本需求：
1、 添加刪除瀏覽實體、紋理
2、 地形編輯
3、 演員管理
除了基本需求外，我們還有另外一些編輯器本身的一些需求：
1、 菜單、工具欄、狀態欄。
2、 日誌管理。
日誌管理是一個很重要的東西，它得支持兩種方式，一種是導成文本，另一種是在編輯器裏面實時看到，爲什麼要提供這兩種東西呢，如果沒有文本，有時候掛的時候你看不到爲什麼掛，如果沒有實時地看到每次去看文本又很麻煩。
B、文件格式
導入導出文件格式是一個很糾結的問題，現在一般流行幾種方式：
1、 純二進制數據，優點是讀取速度非常快，幾乎無浪費數據，缺點是不易被修改，如果沒有工具基本上幾乎不可能被改動（當然你要約定某些字符串也是可以的），這種方法還有不少應用。
2、 自定義格式，類似於INI，優點是終於可能手動修改了，缺點是得花不少時間去寫解析模塊，應該是一種過渡解決方案，這種方案和上面那種有模糊的界定，區別在於這個擁有一個解析器。
3、 XML，現在應該是主流，優點是編輯修改很方式，手改也行，工具也很多，還不用寫解析器，TinyXML,RapidXML等都是不錯的解析器，缺點是效率低，在特定環境下會出現偶爾讀不出文件的情況（可能是解析器的問題）。
現在不少遊戲使用兩種1和3兩種方式結合的方法，在編輯時使用XML，結果用工具導成純二進制加密文件，我也打算使用這種方法：
編輯器配置文件（需要對窗體的開關狀態進行存儲）和生成的地圖使用XML。導入紋理、實體使用OGRE默認支持的格式。
本文來自CSDN博客，轉載請標明出處：http://blog.csdn.net/vickylh/archive/2010/05/19/5607183.aspx