开发 Unity3d 手机游戏的时候，不免要和第三方 SDK 打交道。于是总是需要实现自己的 AppController 来维护 SDK 的生命周期。

Unity3d 提供了一套插件机制，可以很方便地在项目中使用自己的 CustomAppController 继承并重写默认的 UnityAppController 的方法。

许多游戏引擎已经提供了原生的场景管理功能，例如 Cocos2d-x 的 CCDirector.replaceScene() 或者 Unity3d 的 Application.loadLevel() 。场景切换的本质是将原有的对象删除并从内存中释放，腾出空间然后加载新的场景资源。但这并不能满足当下的一些需求，简单的从将一个场景销毁，进入下一个场景，而想要点击返回的时候，回退到原来的界面，并不是简单重新加载一下原来的界面就可以了，还需要还原当时现场的一些关键状态（详细的需求见 Part I）。

所谓的关键状态就是，例如：
你在进入装备界面，默认显示所有装备（type = all），然后你点击界面上的分类按钮，按类型B（type = B）进行筛选。然后你从装备界面跳转到关卡界面（准备去相应的关卡打装备），打完后你想回到装备界面时，它还按类型 B 而不是默认 all 进行筛选。那么 type 就是一个关键状态。

在手机游戏中，场景指的是那些独占整个屏幕的模块；此外还有一些模块是浮动于场景之间的，类似于层，可以弹出和关闭。在 Part III 的 Mediator 部分，我描述了两种类型的视图组件（ViewComponent）：一种是 Scene；另一种是 Layer。在 Part I 中，我将这两种类型的 View 区别开来：NestMediator 和 SubNestMediator。由于我觉得这些 Mediators 是一种嵌套关系（类似 CCNode），所以在做场景恢复的时候，我认为等 Mediator 创建并加载 ViewComponent 后遍历子节点，逐层恢复就可以了。但这导致 Part II 中提到的 Mediators 相互引用，并且有大量场景切换和还原的逻辑被放在 NestMediator 中。

后来我重新审视了这个设计，发现虽然可行，但有太多不合理的地方。现将新的方案整理如下：将状态和场景树转移到 Contexts 中储存，使用 Commands 来处理 Mediator 和 ViewComponent 的注册与销毁，而场景实际切换过程交给 SceneManager 处理。

期待已久的 Part III 来了，不过这次的标题并没有 Cocos2d-js ——因为这两个月我换了工作，重心已经从 Cocos2d-js 转移到 Unity3d + ulua 了。

不过我并没有放弃 PureMVC，并且在新的项目实践中验证了这个框架强大的平台无关性。正如 PureMVC 的理念那样，这是一个纯粹的基于设计模式的框架，内部使用观察者模式构建的消息机制，并不依赖于平台的消息机制。

之所以这么晚才写 Part III 是因为我希望在新项目中多总结提炼一些值得思考的问题，现在是时候跟大家分享了。虽然本文使用 Lua 语言的举例子，但是框架思路本身是通用的。

在开发手机网游的过程中，为玩家建立一个用户中心，比起直接在游戏服务器上直接处理玩家登录，将会带来很多益处。用户中心负责管理独立于游戏数据的玩家帐号信息。并且一个玩家可以在多个服务器上甚至同一品牌下的多个游戏有不同的游戏帐号，当游戏服务器不断增加时，用户可以集中管理。同时这也符合单一职责原则。

此外，由于是手机网游，通常玩家不会愿意为注册帐号花太多时间。很多游戏引入了第三方平台 SDK，可以使用第三方帐号登录游戏；甚至支持直接产生临时帐号进行游客登录，等到玩家消费或认可游戏后再进行帐号绑定。我们要如何设计一个系统来支持这些功能呢？

更新于 2015/10/13： ulua 最新版已经直接支持 mac 调试：ulua怎么与ZeroBrane Studio联合调试？

ulua 是一款 unity3d 4.6/5.1 插件，能够使用 lua 语言进行 unity3d 游戏开发。但使用嵌入式脚本语言进行游戏开发带来便利的同时也对调试程序也带来了各种考验。

有幸找到 MobDebug ，一款用于远程调试 Lua 的神器。集服务端与客户端于一身，集成于多种 Lua IDE 中，例如 ZeroBrane Studio 。于是我打算尝试使用 ZeroBrane Studio 对运行中的 ulua 进行远程调试。

Lua 使用 table 来模拟各种数据结构，当然，也可以用它来模拟类（Class）。要实现类的模拟，我们需要找到一种方式来定义类，并从类创建实例，实现继承等。

正式工作两年了，就在上个月，我换了份新工作，也换了个环境。从 Cocos2d-x + js 转战 Unity3d + ulua，于是又有很多东西要重头学起。在小创业团队跟大公司还是有很多不一样的，需要接触并掌握更多的东西，例如参与产品发布之类的环节。所以近来一段时间研究了一下苹果开发者计划，理解了一下它的工作机制。

去年九月份写了一篇《使用 PureMVC 和 Cocos2d-js 构建游戏项目》，阐述了在 cocos2d-js 中使用 PureMVC 框架的想法，并在项目中试水后感觉效果也比较理想。但是整个框架中令我最不满意的两点就是直接在 Mediator 中处理层级和场景栈以及保存状态。

对于前者，官方的《PureMVC 最佳实践》一书里曾提到：

Page.28 虽然 Mediator 可以从 View 获取其他的 Mediator, 通过 API 访问、操作它们。但这样是很不好的, 它会导致 View 下成员的相互依赖, 这违反了“改变一个不影响其他”的目的。

之前设计的框架中处理层级的逻辑是在基类（NestMediator）中实现的。框架中的所有界面相关的 Mediator 子类都继承它。使用的操作也只涉及基类开放的 API 。而各个子类之间不再有其它的关联。但即使是这样，心里还是感觉不舒坦。

对于后者，使用 Mediator 保存状态以便出栈的时候恢复场景使用——这是当时感觉比较有创意的想法。但是后来仔细想想状态应该是属于 Model 层维护的东西才对啊。放在栈里的应该是数据，而不是 Mediator 。

当前的项目越做越复杂，一直找不到一个合适的契机进行重构，所以只能寄希望于新的项目了。正好近期公司有其它项目组准备启动新的游戏项目，也打算使用 Cocos2d-js + PureMVC 来进行开发，希望我能够提供个框架的 DEMO 。于是我正好借此机会将新想法融入到新的框架中。

cocos2d-jsList 是一个用来自动生成用于 cocos2d-js/cocos2d-html5 代码列表（jsList）的小工具。jsList 位于 project.json 中，用来指明 cocos2d-js 项目代码的加载顺序，详情可见官方文档。

由于众所周知的原因，要处理 cocos2d-js 的 js 依赖并不容易，很多项目依然使用最原始的方式进行开发，而不是使用模块化管理。所以还是需要手动维护 jsList 列表来处理代码依赖（例如类继承）。

为了减少一些工作量和手动处理带来的失误，于是我写了 cocos2d-jsList 这个小工具。

项目地址: https://github.com/mutoo/cocos2d-jsList

在之前的日志中，我分析了手游客户端登录模块的开发流程，指出了一些开发中常见的错误，以及对应的处理方法。随着游戏不断成长，玩家以及接入的第三方平台也会越来越多。游戏的服务器数量必然会随之增长。于是需要一套合理的架构来承载这些变化。