Localization要從第一天開始計劃

最近E3，微軟說能夠在任何region玩任何語言的遊戲了。換一個語言麼，聽起來沒有那麼複雜，其實操做起來還得是從軟件工程初期就好好計劃。

Windows在很長一段時間，你安裝完了，就不能換語言了。大學的時候用Ubuntu以爲，能隨時切換語言真方便，後來Mac也是。

最近趕上了一個問題，就某知名遊戲由於有多種版本的英文支持，好比英國英語和美國英語，有些用戶用美國英語的手機，想要玩英國英語的內容。原本沒啥大不了，可是估計涉及到一些文化版權習慣的東西，IP擁有方很是執着地要增長遊戲中更換語言的功能。

原本吧，遊戲的開發，語言是獨立於系統語言的。但是到了App時代，你們會假設不少東西，好比利用系統的語言做爲遊戲語言。這對於日語、韓語、德語國家可能不是個問題。可是法語分法國法語和加拿大法語，葡萄牙語也分葡萄牙葡萄牙和巴西葡萄牙，西班牙語就更種了。並且隨着時代的發展，人們在全球旅遊工做學習生活，徹底有可能我用英文的系統，但我玩三國志這種用中文吧。因此必需要地區和語言分開纔是好的解決方案。

Strings和Assets都是在load的時候根據語言選項選去的文件，其實咱們就set一個狀態字，而後安全的重啓就行。對於windows上的應用彷佛不難，但是蘋果不讓這麼作，你app的life cycle都已經在app delegate裏面定好了。

按理說，你們能夠把全部的遊戲update單獨拿出來，作一套lifecycle，再作一個state machine轉換。

不過這個遊戲因爲時間久遠，加上來來回回添加了不少分析和追蹤用戶行爲的組建，把整個app delegate的結構已經變得很是nasty。若是我重啓了主進程，沒有辦法安全的重置這些store啊，tracking啊的狀態字，他們在其它線程跑着。

試圖刪除root view而後從新創建，就發現不少遊戲寫的時候內存管理並特別理想。致使不少東西該handle該free的沒弄乾淨，重建了以後指針就亂了。

這就是App時代的軟件危機，首先你受制於人家定好的起承轉合，只是在填滿每個框架函數裏的內容。固然無論怎麼樣的結構，要作高質量代碼，還都是得獨立於app life cycle的本身的gameplay life cycle。再加上，蘋果iterate的速度比全部開發者都快，今年是iOS 10，你什麼都不作都會有不少classes broke。你再好的設計模式，發現接口和底層的類一直在變，也是讓人抓狂。不過好的遊戲，好比某賽車遊戲，從PC平臺移植而來，C++的部分很solid，圖形引擎數學會自動scale。而對於現代遊戲，有很是多的tracking，MTX store，note/alert，網絡傳輸，UI，這些都是在每一版iOS都在變，維護起來不可能輕鬆。什麼東西和人類end user打交道，就無法肯定恆久的解決方案，這些地方就得一年一年改。

 

Anyway，寫好代碼，作好設計，考慮語言支持，得從一開始就計劃！