功能机时代的游戏开发

初入游戏行业时，从事BREW手机游戏开发，虽然至今想起来不堪回首，但也锻炼了对恶劣环境的忍受力，而且练就了一身能够从底层思考的架构思维。

BREW是高通自己搞的一套操作系统，非常封闭，可类比IOS，这个给当年BREW开发者带来了丰厚的利润。后来公司也搞过J2ME开发，往往才发布一个作品，第二天网上就出现了盗版安装包，倒是跟现在的Android有点像。

BREW开发在当时看来是有一定的技术门槛的：

只支持C语言开发，不支持C++

不支持全局变量

有包容量限制，利润最高的往往是低端版，包容量是100K，基本上就没法使用很多第三方库了，比如一个LUA脚本虚拟机就要80K

各机型对API接口实现的不一致，个个机型都有各自的适配问题，做游戏好一点，做软件那叫一个痛不欲生

屏幕分辨率千奇百怪，碎片程度堪比现在的Android

只有类似于GDI的图形API，没有功能强大的opengl es

要命的是图形载入接口支持的是BMP图片，配合100K包容量的神限制.......

无法联机调试，只能输出日志，配合机型适配问题........

没有游戏引擎，不是没有成熟的引擎，是没有引擎

性能嘛，CPU 100M频率算是很高的了，不过很奇怪的是从没遇到过内存用爆了的问题

得益于当年还没有经济危机后的通货膨胀，没有智能机爆发时代的浮躁与高薪挖脚，团队里面有不少名校毕业，能沉下心来做技术的牛人，对这些问题各显神通，倒是有了很多解决方案

自己改造编译器和插件模板，能勉强支持C++了，但还不能用静态和全局变量

再后来又改造了编译器和makefile生成模板，可以支持静态和全局变量了，但仍然不支持STL

不能用LUA，就自己写了一套类似汇编的脚本引擎，只有不到100行代码，这个还是一位前辈的毕业设计

机器适配问题嘛，无解，最后软件都用写游戏的方式写，完全放弃了使用系统控件

分辨率适配，大部分项目居然做到了一套代码适应不同的美术资源

自己写了好几套引擎，还写了配套工具，包含了动作精灵，地图编辑器，场景编辑器等等

当时我做的是

实现了一个简单的STL库

扩展图形GDI，自己写算法实现了alpha混合，缩放等图形API，并做了非常极致的优化

写了UI编辑器，但在当时未投入使用，后来在智能机时代发挥了很大作用