关于文章中涉及的两个杜撰概念:
一、绘图器：众所周知，Java GUI以paint进行绘图，以repaint进行图像刷新，而完成repaint及paint这一连贯过程中所用到绘图组件，我将其称为绘图器。就我个人的体会，绘图器的调用时机应始终处于repaint之后paint之前，即通过repaint触发刷新后执行，当其中的具体逻辑完成其对应的图像绘制后，再通过统一接口将其图像插入paint中，为了匹配需要，绘图器应始终以接口方式实现。
二、监听器：这里所说的监听器，并不是特指某个Listener组件，而是包括Java游戏中所需的所有监听器集合。由于Java游戏中很可能会切换不同的游戏模式，而不同模式游戏中需要处理的鼠标或键盘事件也不尽相同。所以在Java游戏开发中，我们需要一个可替换的监听器集合，用以变更不同游戏模式下的不同监听事件，为了匹配需要，监听器应始终以接口方式实现。
正文，关于Java游戏开发中应始终坚持的10项基本原则：
1、始终保持画布的唯一性。
现实生活中，人类通过口腔及消化道摄取的营养物质可以被心、肝、脾、肺、肾等内脏吸收，却没有人会想给自己的心、肝、脾、肺、肾上也弄个嘴，因为一致性的功能实现只要有一个就足够了。但是，有时我们不经意的在游戏中add、remove不同panel或canvas以求转换画面的行为，无异于是想给游戏的心、肝、脾、肺、肾上装嘴的不智之举，切忌Java的GUI都是画出来的，重绘就好，没有切换组件的必要，否则费力不讨好。
2、始终以接口方式转换监听及处理图像绘制，务必将视图及逻辑层分开。
针对一些混合类型的游戏，比如SLG+AVG、RPG+STG，我们将面临不同模式下游戏的监听器及绘图器切换问题。
这时最简单的抉择莫过于为每一个游戏类型都订制一个对应的面板进行切换，这样虽表面上方省心，但却也是最费力而不讨好的，且不说闪烁问题需要单独解决，资源占用问题，光冗余代码就够人头痛了。
其次就是在一个面板中针对不同游戏类型使用switch判断以切换监听及绘图，事件数量少时固然可以，效率也不错，但稍微多一点恐怕就不那么简单，更多时则仅余郁闷，同样不建议使用。
就我个人所见，解决这一问题的最好方法莫过于沿用MVC模式，以接口方式构建绘图器及监听器，当游戏出现变更时，我们仅仅需要切换监听及绘图接口，就可以迅速转变游戏内容，而无需区别对待不同的实现，这样即避免了组件切换的闪烁及延迟，也精简了代码，更有利于开发时的模块划分。
3、始终以静态方式加载游戏常用资源，缓存常用对象，并及时释放无用资源。
即使历史发展到今天，Java依旧没有彻底摆脱其系统资源杀手的可憎面目，GC机制也导致我们无法适时地释放资源，new的越多，系统也变得越慢，这对于大量使用图形资源的游戏来讲尤其要命。所以我们要尽一切可能令常用资源静态化为唯一实例以避免反复调用，而将一些调用后不会再使用或很少使用的资源迅速 null以等待GC自动回收。否则，你将发现你的游戏距离内存溢出是那样的近……
4、始终以循环方式展开游戏，利用线程控制游戏流程，避免出现僵直现象。
事实上所谓的游戏开发，在某种程度上不过是由程序员制作出的一种夹杂着各类图形算法，用以适时地展示各种资源的幻灯程序；唯一的区别在于，普通幻灯程序中人机交互性较弱，而游戏的人机交互性较强罢了。
我们都知道，幻灯程序在展示中无论如何跳转展示页，也必然有其固定的begin与end页面，而且也势必能重复从头至尾顺序循环其begin与end，以此构成一个幻灯片。
实际上游戏制作也一样，无论游戏流程如何转变，游戏都会有也必然会有一个主流程，或者说一个主循环体，这样我们才能由游戏开始进行到游戏结束，而不是从一个结束到另一个结束，也就是说无论游戏中细节分支有多少，它的主流程处理及判定也必然是顺序的。针对这一特性，决定了我们应将游戏主体代码至于一个大的循环体之内，再利用线程控制循环体中的游戏进度，从而更好的顺应这一流程。简单的说，我们应将循环体中每一个使用到的绘图器都当作于flash中的一桢,而线程的各种控制当作时间轴,用以调节不同桢的播放速度及调用时机，以此完成各种不同的事件交互。
5、始终在处理复杂绘图时直接准备贴图而非由程序绘制。
我们都知道Java绘图事实上是GDI实现，因此其绘制复杂画面的效率也就可想而知。通常强况下，除非当前的效果非编程不能实现，或者其所造成的资源损耗确实微小到可以忽略不计，否则最好的方法就是用空间换效率，准备好图片直接贴上去吧，宁可增加些程序体积，也不要让玩家因等待的愤怒而问候你祖宗八辈。