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，写好代码，做好设计，考虑语言支持，得从一开始就计划！