接下来做些什么
整个游戏到此结束了，作为一个练习项目，它仍有许多要改进的地方。
交互方面的改进
回想一下平时使用计算机的情形，一个按钮在不可用时，会被灰化；当鼠标指向时会高亮，点击时会按压感；而我们的界面元素却不具备这些状态反馈。
从GameUI开始，一种改进方法是在WIDGET中增加state字段，由它指出控件当前处于什么状态，Render方法根据状态使用相应的纹理渲染，而状态的改变则由相应的鼠标消息提供。对于LevelUI，由于我们没有采用类似相应的设计（即抽象出Widget的概念），则四种类型的按钮（返回、前后翻页、关卡按钮）每个增加一个状态变量，会导致后期维护异常困难。因此在做这些工作之前，我们需要重新设计WIDGET的概念，让界面使用统一的元素。
别急，在动手之前回想一下通关方面。在我们首次实现游戏逻辑后，我想你也已经注意到了两个问题：
- 最后一个箱子在目标点时，并未显示为红色。
- 通关后程序立即载入下一关地图，突兀感极强。
针对第2个问题，在后来我们加入声音后，有了明显的改观，但更加成熟的做法是显示一个过关窗口，它位于当前地图之上，由用户确认后进入下一关，显然第1个问题迎刃而解。需要注意的，你要保证鼠标消息不能再次分发到GameUI上，否则在游戏已经胜利的画面，用户仍然可以点击重玩等按钮。
延续这个思路改进下去，程序会在交互性上有很大的提高。你可能热衷于重构，继续将交互改进下去，冥冥之中会有一些感觉，你在设计某种东西，它能分发消息、内置可交互的组件（按钮、窗口），恭喜你，发现了2D游戏UI框架这个概念，这也就是不要着急动手的原因。
关于资源
你可能没有留意，从第一次显示地图开始，我们就引入了资源的概念；并在模块的初始化方法中载入资源，但是却一直没有提供相应的释放接口，这里因为Easy2D在退出时会自动释放这些资源，但是显式的提供资源清理函数，在程序接口设计上，会有一个良好的接口对应关系。
你可能也发现了，随着模块的增加，由模块自己管理所需的资源并不一定是好的设计。试想一个图像资源在多个模块中使用的情形，多个副本的存在占用了更多可用的资源，因此设计一个资源管理方案也是良好的设计。它提供资源加载、访问、卸载等功能；比如对于游戏场景资源，加载后就一直存在；而对于关卡选择界面，退出后就卸载。