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