软件复用程度的级别可以按以下准则来衡量（级别从低到高）：
（1）函数：将那些重复或者类似的程序集中起来放在函数里，对外提供参数以利复用，是功能型的重用；
（2）实在类：将若干经常使用的函数集中起来，将函数的参数转化为类的成员变量，自定义构造和销毁函数，是资源型的重用；
（3）抽象类：使用纯虚函数对外提供接口，这些接口仅仅声明了基类的功能，而将实现拖延到子类中去，是强调可变性的资源型重用；
（4）包：将若干耦合度较大的类集中起来，统一地对外提供接口，是一种有机的资源型重用；
（5）模板：将变量的类型通用化，它是一种强调通用性的资源型重用，可以应用在上面四个层次上；
（6）组件：封装了数据和方法的可执行代码，上面五种都属于代码级的复用，而组件属于软件级的重用。
游戏一般规模都很大，保持结构清晰是首要的问题。我们知道大型系统一般都可以分为MVC三部分，实践证明这种结构行之有效。本人将之应用在游戏设计中总结出若干经验：
（1）将建模和交互两部分分开，建模阶段采用工厂模式，利用资源管理器统一创建、销毁和调度资源；
（2）交互包括显示和操纵两部分，其实可以统一由图形界面实现；
（3）逻辑使用脚本加解释器的方式实现，这样可以在游戏之外修改游戏；
（4）将场景作为游戏的基本单位，将物理系统和效果系统独立出来，场景可以透明使用和替换它们；
（5）针对应用自定义消息，开辟若干线程，使用线程消息机制来进行消息响应；
（6）注意类的粒度的问题，类之间的交互只好保持在同一级，这样有利于扩展和移植。
游戏设计最理想的情况就是美工做资源，设计师写脚本，然后运行一下可复用的引擎就把游戏搞出来了。虽然难度不小，但是可以冲着这个目标努力，最最关键的还是要有合理的体系结构。
从电子游戏的开发难度来看，它不亚于开发一个小型的操作系统，为什么这么说呢？首先在计算量方面，由于电子游戏是三维的，CPU计算量非常大；其次在资源管理方面，显卡和内存的使用要精打细算；第三，游戏中的对象之间的通信十分频繁，大部分消息的检测和响应都要自定义。实际上，开发电 子游戏的时候是要借鉴很多操作系统的思想的，比如基于多线程的消息系统，基于组件的窗口系统等。
从电子游戏的内容来看，它比操作系统更高级。传统的操作系统都是桌面式的，而电子游戏拥有自己的一个虚拟空间，甚至连它的GUI也是三维的。我们知道从无图形的DOS到有图形的Windows是一个很大的进步，而从平面到立体则是一个更大的进步。我个人认为在计算机方面，天才来自以下几个领域：网络黑客，操作系统开发者，再有就是游戏设计师。
其实电子游戏更应该叫虚拟环境，它的很多技术和思想都可以移植到专业的图形系统中去，实际上很多的虚拟战场系统就是基于类似的游戏开发的，所以我认为电子游戏绝对不是只有娱乐价值。可以这么说，如今的电子游戏既是应用系统，又是操作系统，它是一种技术含量很高的软件，应该得到程序员足够的尊重。
此次会议发生了如下一些趣事：参加了唐泽圣教授的颁奖仪式，跟石教英教授一起排队打饭，跟彭群生教授同桌吃饭，跟Ahmad Nasri楼外楼同桌聚餐，参观CAD&CG国家重点实验室，欣赏了西湖夜景。对几个老师印象比较深刻：齐东旭，鲍虎军，胡事民。收获了两本论文集：唐泽圣论文集和石教英论文集。总的感觉是长了见识，见到了许多图形系统的演示，并且认识了不少图形学方面的朋友。可以肯定的是：在图形学方面，浙江大学是国内最好的。总而言之一句话：虽然图形学是骗眼睛的，但是我热爱它。
完成Transformer 2.0之后，我已经静心思考了一段时间。我刚拜读了“四人帮”所著的《设计模式》一书，发现2.0中已经使用了其中的六种了，分别是Factory、Singleton、Chain、Command、Interpreter、Observer。其它的模式也基本上看得懂。接下来打算将State、Strategy应用到3.0中。三种类型的设计模式：创建型、结构型和行为型，我认为行为型最有用，因为游戏中一则对象多，二则通信频繁。为更好地解决该问题我将在3.0中借鉴经典的设计模式。State是状态机，可以用在游戏状态的切换上；Strategy是算法，可以用在物理系统的实现上。我的经验是：设计模式能够让你既优雅又高效地解决问题。