IT博客网-天堂的另一角-随笔分类-新技术推介

微软SideWinder Dual Strike入手实验手记

Addone — Mon, 10 Dec 2007 04:36:00 GMT

由于华硕的手柄发生可怕的橡胶老化现象，不得不重新购买一款手柄。第一次看到微软的SideWinder Dual Strike时，那种感觉可以用“惊艳“来形容——实在太怪异了，我喜欢！

很快我就入手了一个，价钱也不贵，和北通的差不多，做工和手感就相当值得赞叹了。本来一直喜欢北通的，可觉得那个质量跟微软、罗技什么的一比，就……还真想不通，不都是Made in China的么……
这款手柄的外形真的太吸引人了，于是我立即拿来测试游戏:P

首先是东方系列的弹幕纵轴射击游戏。我的天，根本没办法控制方向，红魔乡easy的第一关已经要死光了……难道是因为东方对手柄的精确度要求太高？我于是又试了下彩京1945，结果也差不多。看来不行，这款手柄的方向感太模糊了。注意，控制方向的不是左边那个圆圆的八向控制键，而是中间的双轴球。

然后试验一下3d动作游戏。我选了N64的赛尔达时之笛，终于找到方向感了……由于双轴球实际上不具备传统摇杆的“回中“功能，所以玩起来会感觉到角色的动作是连续的——缺点是你会发现让他停下来并不容易。由于特殊的双轴球设计，手柄具备了传统摇杆难以企及的细腻操作感，你可以轻松体验散步、走动、跑步等不同的操作（过去用一般的摇杆几乎只有“跑步“这一操作）。虽然功能键相对于N64来说显然不够，但要是不使用DPad，把八向控制键拿来模拟C按钮，那么玩起来的感觉还是相当不错的。

接着我拿鬼武者来试了一下……天哪，这个方向球简直疯了，要不就根本不动，要不就拼命乱动。在游戏里别说砍人了，就连想好好的走个路都做不到。这跟游戏本身的操作设定有关，为便于格斗，转向和前进键是分开的，这样不但无法发挥这款手柄的威力，反而会很容易造成主角拼命转圈停不下来的状况……

然后试下赛车吧，拿极品飞车试了下，据某网文说还不错，但实际的情况是……我左一拧，右一拧，帅气的跑车开得歪歪扭扭还不断打滑，偶尔还转上几个圈，好不容易才牛喘着憋到了终点。方向球的精度是一个原因，但最重要的问题则源于方向球不能自动“回中“。然后我想起来，在一定程度上来说，汽车的方向盘也具备“回中“功能，否则是不是也会不断转圈呢……

最后试了下格斗游戏，拿侍魂来实验，恩……结果可想而知了，用方向球来搓招？能出个旋风斩运气就不错了。话说回来，如果能用八向控制键的话，应该还是能用的。

总结一下，这款手柄的外形绝对是够酷的，手感也是不用说的。实际使用时，方向球在3d动作游戏里的表现可圈可点，但对于许多别的类型的游戏来说并不适合。

事实上，如果可以把八向控制键用作方向键，那么这款手柄完全可以适用于绝大多数游戏。而如果可以调节方向球的感应范围和精度，对于很多游戏的操作也都肯定可以胜任，例如射击和赛车。另外，手柄据说内置了振动功能，微软出品的振动手柄，效果总还是值得期待的吧？

幸运的是，微软提供的驱动带有所有这些功能，有了它，你就可以轻松设置这款手柄的各项功能，它也就真正成为了一款几乎适用所有游戏的超强超酷的振动手柄。甚至你还可以考虑把它拿来当鼠标用……

遗憾的是，微软并未提供这款手柄在XP下的驱动，而且对这款1999年出品的手柄的支持也早就结束了。即使是9x系统下的驱动，也已经很难找到了。这也就意味着……我买到的是一款不适用于绝大多数游戏的无振动的收藏观赏型手柄。

所以……我把它换成了罗技的极锋战斧（PS2）……仅存玉照数张留念。

参考链接

微软超酷游戏装备DualStrike体会篇

Addone 2007-12-10 12:36 发表评论

铁三角C601试用手记

Addone — Sun, 09 Dec 2007 04:34:00 GMT

之所以选择C601，是因为据说它的低频表现不错。见识过K14P之后，我便下定决心入手一个普通又廉价又还算物有所值的耳塞。由于有众多的高仿耳塞追捧，C601/C602的外形并不讨巧，看着没感觉。不过真正使用之后，其威力还是令人欣慰的。

C601和C602是完全一样的，区别只在于前者是0.4m线直插，适合配合线控使用；而后者是1.2m线弯插。试听时音源采用Sony PSP。

刚开始使用的时候，对其出色的中音表现颇为赞叹。试用一段时间之后，觉得它其实更接近K14P的表现，而不是MX550。

各频段的表现上，C601的中音表现相当不错，声音饱满，细节丰富，人声比较暖，用来听《香水有毒》之类的重人声的曲子相当有味道。高音也还算可以，但不够透亮。低音就比较令人奇怪了，看网上的评论都说C601的低频表现不俗，但实际效果却比K14P还惨：简直是完全没有低音！不过等煲开之后，它的低频就慢慢出来了，虽然还是比较混，但也还不输于K14P，用来试试《渡口》，里面的鼓点表现和K14P差不多，都烂得不行，只能听听回音了。这其实跟音源也有关系，如果使用的是“魅族”之类的超重低音MP3，也许会觉得低音刚刚好，虽然还是比较混。

C601的声场表现好得出乎意料之外。听Bandari的曲子的时候，那种开阔的感觉就已经很令人吃惊了，如果用来玩赛车游戏的话更是夸张，感觉车子就从旁边开过去一般，临场感非常不错。不知道为什么网上的评论很少提及这一点？

解析度方面，C601比标榜超高解析度的K14P还是要略输一筹。在《渡口》的后半段，当人声比较大而且乐器比较多的时候，声音显得有些杂。

总的来说，C601的效果还是相当不错的。出色的中音表现使得它非常适合用来听流行乐。高音虽略有不足，但宽阔的声场和细腻的质感使得它也可以胜任古典音乐。虽然低频方面的不足令它难以应付摇滚乐，但如果使用的是带有超重低音的播放器，不妨一试。其实我对这个倒不是很在意，因为个人更注重旋律感而不很喜欢太重的低音，感觉听多了很容易疲劳。如果是用来玩游戏的话，C601绝对值得一试。
总之，这款耳塞完全对得起其100元左右的身价。

Addone 2007-12-09 12:34 发表评论

绝配：PSP+K14P

Addone — Sun, 14 Jan 2007 14:03:00 GMT

前不久打算为PSP配一款价格偏低但音质不错的耳塞，据说PSP推力不够，森海赛尔MX500都推不好，因此颇有些为难。后来看到一篇高人的文章，说是推荐PSP用AKG的K14P。不过列举的那些理由对于我这样的菜鸟来说实在是太抽象了，鉴于推荐的程度比较高，于是抱着试一试的心情（XX广告？）跑去找了。
不料运气不好，市面上极少见到K14P的踪影，倒是K12P有不少。可惜K12P是偏重低音的耳塞，而我则单纯追求旋律的美感，完全无法接受。而且对于我来说，K12P的声音听久了也不舒服。眼看就要空手而归，这时却发现了漫步者的E200！这款耳塞实际上和K14P是完全一样的，（原因我就不想提了……），只是把等长线改成了长短线，换了个牌子而已。价格方面，自然还要便宜一些了，我立马兴高采烈地把它捡回家去了。

和PSP配合的实际效果嘛……没得说，和K14P宣传的一样：水晶般剔透的声音！可惜我只是菜鸟，不能像高手一样随心品评，只好拿众所周知的“渡口”来贻笑大方了。
和预料中一样，开场的鼓声毫无力度、下潜可言，对这款耳塞的重音还持有幻想的朋友可以绝望了。但是，它的声场表现确实非常出色，鼓声的定位非常准确，感觉就像在一个清幽的山谷中一般，你甚至还能听到四周的回声，非常动听惬意。很快，吉他响起，给人的感觉是非常贴近，擦弦声也非常真实。应该说，它的还原能力还是很不错的。人声的表现方面，感觉比较温暖，中高频没有出现明显的断层。最值得一提的是，即使在人声的音量很大的时候，吉他声、鼓点还能非常清晰地区分开来，足见K14P的超强解析能力。在歌曲的后半部分，各种乐器纷繁复杂，K14P依然游刃有余，对各种声音都表现得相当出色，丝毫不觉杂乱。这自然也跟PSP那种“干净”的音质有关了。在歌曲的最后，那段吉他声简直就像在耳畔弹起的一样，忧郁而动人，令人感动。
结论毫无疑问，K14P确实是一款超值的耳塞（百元左右），声场宽阔，定位准确，解析度很高。和PSP“干净”的声音配合起来，确实有如天籁之音。另一个推荐的理由是，K14P是一款低阻抗（17欧）的耳塞，用PSP听起来不会出现声音太小的问题。
这种搭配的缺点自然也非常明显，K14P基本上没有重音……即使套上海绵套，也没太大作用。喜欢听重低音的朋友千万别买错了。
另一个问题，耳塞的做工似乎有些问题，背面的漏音孔边缘很粗糙，戴久了耳朵会疼。解决方法：用海绵套就好了。

我不大喜欢听Rap之类偏重节奏的歌曲，而热衷于欣赏偏重表现旋律的歌曲和纯音乐。以前用劣质的耳塞听歌，总觉得意犹未尽，有些旋律根本就听不到（耳塞的解析度太低，被别的声音盖过去了）……K14P和我的口味倒是对上了，而且听K14P的声音还有一个大好处：声音很舒服，百听不厌，听久了也没有那种难受的感觉（用那种过于强调重音的耳塞的话，听久了拿掉耳塞会有一种“整个世界清静了”的感觉……）。
因此对我来说，PSP+K14P的确是绝配，在此强烈推荐那些和我有同样音乐喜好的朋友尝试。

Addone 2007-01-14 22:03 发表评论

一种新的软件设计开发方法——谈UCL技术

Addone — Thu, 09 Nov 2006 06:53:00 GMT

最近一段时间来，我都在忙于做一件“异想天开”的事情——寻找传说中的“银弹”。呵呵，听起来确实有些搞笑，但是我想我的确发现了什么。

引言

自Brooks预言“没有银弹”的数十年来，软件设计开发的理论和技术都有了相当大的改进，但也正如Brooks所言：没有银弹。
现在，我们拥有面向对象编程、UML建模、CMMI过程改进等各种理论和技术，然而所有这些充其量只能算得上铜质子弹，答案依然：没有银弹。

通用构件库（UCL）的基本构想

我所设计的是一个叫做“通用构件库（Universal Components Library）”的框架，设计灵感源自可视化构件库VCL、MVC三层架构以及Linux下一个基于Alsa的声音合成软件，而其理论基础则是分层数据流图。
这个框架贯穿整个软件的设计和开发过程，试图让设计和开发连成一气。虽然并非基于面向对象设计与编程，但也不排斥面向对象编程技术。除了大幅度提高代码重用性之外，这个框架也有助于提高软件的可维护性。在基于UCL的设计和开发过程中，还可以综合运用XP开发过程及CMMI过程以进一步改善整个过程。

UCL的目标和当初VB、Delphi的目标一样，让软件开发变得就像搭积木那么简单。使用类似VCL、MFC的东西的确可以提高开发效率，但无法从根本上实现这个目标。其原因可以归结为几点：

把“搭积木”理解为对整个系统进行可视化开发，而非对系统的各个模块进行分层搭建；
扩充性不足，自定义组件没有能获得和自带组件同等的地位，以至于不得不重复发明各种轮子；
独立于设计过程，无法将代码和设计进行对照。

UCL是一个抽象的库，只是一个框架而已，作用是把以VCL、MFC之类的具体组件组织起来，从而真正具备“搭建”的能力。由于本身就是个完全开放的框架，因此任何组件都是平等的，大家可以随心所欲地创建各种各样的专用UCL库。UCL框架使用UCL图作为设计和代码的中间媒介，数据流图可以直接转换为UCL图，代码可以由UCL图直接生成或“搭建”。
由于UCL组件和代码一一对应，因此UCL图是依赖于具体库的，例如使用VCL搭建的系统和使用MFC搭建的系统，即使其功能一致，UCL图也有可能不同。也就是说，想要应用UCL技术，就必须拥有要使用的具体库所对应的UCL库，例如UCL_VCL、UCL_MFC、UCL_Swing、UCL_QT等等，这也是为了实现真正的“搭建”所付出的代价。

UCL图是UCL设计思想的核心，其灵感来源于Linux下的一个声音合成软件。该软件提供了许多种类的声音处理模块，这些模块的外部接口都很简单，大都只有输入、输出接口而已。但是只需要将各种模块用音频流连接起来，理论上却可以合成出任意的声音。面向对象技术中的问题之一就是类的接口太多且没有标准，不便于掌握。如果可以每个组件只有几个接口，并且组件的分类比较科学，那么掌握起来就简单多了。
除了连接关系之外，为了适应自顶向下的分层设计的需要，UCL图还支持“组合”的关系。一个组件可以由一个或多个内部组件组合而成，嵌套层次不限。这样，一个复杂系统就可能最终分解为一系列仅具有一个输入接口和一个输出接口的简单组件。
UCL图除了能够充当设计和开发的中间媒介之外，还有另一个重要的作用。在分解为一系列UCL组件之后，整个系统的规模和工作量就可以快捷并准确地估计出来。

可见，UCL技术的优点在于：

使得软件的规模和工作量在前期设计就可以比较准确地估计；
使得设计和开发过程一气呵成；
提倡面向组件开发，在不增加代码复杂性的前提下，大大提高了可重用性；
使得软件更易于维护。
以下将分别讨论这些问题。

UCL解决的问题：前期设计

软件的前期设计，从来不是个简单的问题。我们在获得需求说明书之后，就需要将其转变为设计蓝图。过去的数据流、事务流、控制流分析方法更适用于模块内部的分析，而对于一个庞大的系统，则往往需要使用UML进行建模。
无论如何，建模过程总是繁杂的，而且最糟糕的是，和传统的工程设计不同，这种繁杂的软件设计往往跟最终的软件产品根本就是天壤之别。我们最后拥有的是一大堆跟最终代码几乎完全没关系的模型以及一大堆几乎丝毫看不出设计思想的代码。因此，对于一个稍微复杂的项目，我们对其规模和工作量都是难以准确估计的。
即使我们使用昂贵的工具来试图同步设计和产品代码，经常也只是徒劳而已，过高的设计成本和维护成本使得这种投资毫无意义。更多的公司选择了手工作坊式的开发方式，只是在开发过程中借助XP或CMMI来扳回一点面子。在项目完成后，再根据最终产品进行建模——当然，这已经不再是设计了，只能算是“文档化”罢了。

基于UCL的设计过程，并不是面向对象的设计过程，而是基于传统的分层数据流图，也就是说，整个设计过程是自顶向下的。本来，数据流图对于系统的架构描述并不清晰。但是，分层数据流图使得这样的架构描述至少可以达到“将就能用”的程度。更重要的是，由于最底层的数据流图和UCL图可以方便地对照，由UCL图作为设计和产品代码的中间媒介，从而将设计过程和开发过程连成一气。
实现UCL组件和数据流处理的一一对应，更重要的意义在于使得系统的规模和工作量将变得更直观、更准确，也更易于统计，而不像过去一样只能依靠项目负责人的经验判断。
而在购买或自行填充了UCL库之后，通过实现UCL组件和代码的一一对应，不仅可以实现建模和实现的互相参照，开发成本也可以大大降低。

以下是一个简单系统的功能需求说明、分层数据流图以及一个对应的UCL图，仅供参考：

UCL解决的问题：重用

重用，是件说起来容易做起来难的事情。利用面向对象技术，设计一个可重用构件的工作量大约是“一次性”构件的2~3倍。
这里的问题是通用性和专用构件的矛盾。人们在得到一个专用构件之后，在将其重用的过程中往往需要针对特定需求进行修改。不断的重用导致不断的修改，并催生了使这个构件日趋通用化的需求，最终专用构件变成了通用构件。但构件的通用性带来了高昂的维护成本，最终人们对其失去了兴趣，又开始重新开发专用构件。如是循环。
高昂的重用成本带来了昂贵的可重用构件，也就导致更多的人决定自行开发各种形态各异的轮子，最终这些轮子又陷入了成本高昂的重用泥沼中。

UCL组件和传统的构件很不相同，其特点如下：

关系简单，只有简单的“连接”和“组合”两种关系；
接口简单，只具备“输入”、“输出”等几个简单的接口；
处理简单，通常只执行很简单的处理，保证了低廉的开发成本和良好的可维护性，同时保证了可重用性。

通过两种简单的关系，我们就可以将各种简单的UCL组件“搭建”成具备复杂功能的复合组件，最终搭建成整个系统。也就是说，尽管UCL的设计过程是自顶向下的，但开发过程却是自底向上的，这就在保持低成本的同时兼顾了通用性，从而得以解决传统面向对象开发方法中的通用和专用的矛盾。

在具体的开发过程中，我们在得到UCL图之后，首先是实现图中的各个组件。这些组件的代码和组件一一对应，存放在代码库中，日后再次使用该组件时无需再次编写，由于组件的规模很小，可重用性就比传统的构件要高得多。
在所有的底层组件都有代码实现之后，借助专用的CASE工具，输入UCL图并连接代码库，即可直接生成完整的系统。

当然，以上是一个理想化的过程。其主要的一些应用问题如下（当然还有别的）：

如何输入UCL图？

我的目标是设计出一个类似那个声音合成软件的画图软件，这样就能以可视化的方式来拖拉各种组件并创建连接。但是作为一种简单的替代方案，我也设计出了一种脚本语言，用文本的方式来表达UCL图中所包含的所有元素。以下是一个脚本示例：

cnitblog.addone.AID3Tagger.Mp3FileListEditor

AddFileButton:JButton,title="添加文件",proc>OpenFileDialog.show;
OpenFileDialog:JFilteredFileChooser,multiSelection="true"/filterString=".mp3|MP3音乐文件",show>Mp3FileList.add(fileList:File[]);

AddDirButton:JButton,title="添加文件夹",proc>OpenDirDialog.show;
OpenDirDialog:JFileChooser,selectionMode="directories",show>GetFilesInDirRecursively.proc(dir:File);
GetFilesInDirRecursively<static>,filterString=".mp3",proc>Mp3FileList.add(fileList:File[]);

RemoveFileButton:JButton,title="移除文件",proc>FileListBox.remove;
SourceEncodingBox:JComboBox,editable="false"/data="GBK|UTF-8|UTF-16-BE|UTF-16-LE",
proc>FileListBox.changeEncoding(encoding:String);

如何“真正地”实现UCL图到具体代码的转换？

这种转换的问题在于，对于UCL组件的属性应该如何转换？我目前的想法是，使用一个映射文件，将UCL组件和具体组件的属性映射关系保存在其中，例如：

version=0.1
type=java.swing

JButton.title=setText(String)
JFileChooser.multiSelection=setMultiSelectionEnabled(boolean)
JFileChooser.filterString=setFileFilter(Custom.FileFilter)
JFileChooser.selectionMode=setFileSelectionMode(Custom.FileSelectionMode)

_converter_.FileSelectionMode.source=String
_converter_.FileSelectionMode.target=int
_converter_.FileSelectionMode.rule=files|0|directories|1|files_and_directories|2

另外一个可供考虑的方法是，开发UCL组件来专门对属性进行处理。这样即可在目前的UCL框架中实现，无需增加新的特性。

如何使用UCL设计GUI界面？

不得不承认，这将是个很棘手的问题。对于java、.net来说，情况要好些，因为界面也是使用代码来构建的。但对于VB之类来说，由于界面是采用专用格式来保存，情况就麻烦得多了。而且，即使是java和.net，没有可视化的界面设计，也将是没有吸引力的解决方案。
我目前的想法有两个：一个是将具体的GUI组件包装为UCL组件，不过这样一来有可能会加大界面设计的工作量；一个是干脆完全将GUI部分从UCL中剔除出去，即这一部分使用传统的开发方法，但应该保证GUI组件和UCL组件能够彼此调用。

UCL解决的问题：维护

在传统的软件开发项目中，维护成本所占的比例是很大的。这里主要指的是由需求变更、BUG修改等引起的软件修改和更新工作。对于小的修补工作来说，每次修改的成本并不高，但是在多次修改之后，原有的代码往往就变得面目全非了。这时，如果再面对一个较大的需求变更，往往我们情愿重新开发，而不愿意再继续维护这个系统。
造成这种问题的原因有很多，一方面是因为无法从代码中看出设计，不得不求助于文档，这对于一些缺乏文档的项目来说是致命的；另一方面是，在修改之后没有及时地同步文档和模型，这种情况在发生若干次之后，这个项目离寿终正寝也不远了。

如前所述，UCL图是设计和实现之间的一座桥梁，对于解决这类维护问题应该是很有效的。修改工作和开发时一样，都只需对图进行操作，所有的设计都可一目了然。这种方式，有利于提高维护效率和降低维护成本。

总结和思考

由以上讨论可以看到，由于平滑连接了设计过程和实现过程，UCL技术具有许多独特的优点。作为一种全新的技术，UCL不仅仅是一个组件库的理论，更代表着全新的设计思想和开发方式。作为一个抽象的组件库，UCL更不是VCL、MFC等的替代品，而是这些具体库的包装者和使用者。
由这些理论可见，如果UCL技术能被证明可用于实际的商业开发中，目前的整个设计和开发方式都将发生巨大的改变。不过，由于理论是全新的，而且对开发语言具有依赖性，基于UCL的设计和开发过程更需要有一系列的CASE软件支持，这可能会带来一系列的问题，但更有可能形成一个巨大的商机。

不过很遗憾，尽管我已经在一些小软件中成功的应用了相关理论，但目前，各种应用问题还远没有得到完全解决。例如，问题1中所说的可视化设计器和脚本解析器，还都没有实现。而问题2、3的解决方法还需要进行深入讨论。这一切，都需要耗费大量的时间和精力。
好在，即使不能完全实现由UCL图向代码的转换，这个理论至少也能帮助我们在设计前期就对一个项目的规模和工作量进行更为准确的统计。

限于个人的时间、金钱和精力，我不得不暂时放弃UCL的相关思考。把东西扔在这里，只希望机缘巧合，居然能起抛砖引玉之效，那也不枉我连日的冥思苦想了。

Addone 2006-11-09 14:53 发表评论

程序员的游戏

Addone — Fri, 01 Sep 2006 17:41:00 GMT

本文的目的在于介绍一类特殊的游戏：编程游戏。
这类游戏和大多数战略游戏一样，都提供了一个平台，各种不同的虚拟角色在其中进行角斗士般的竞技比赛。和传统游戏不同的是，玩家并不能直接操纵这些角色，而是通过编程的方式来创建角色，并将其加载到对战平台中，然后观看它们之间的精彩战斗。
无疑，这种游戏相当适合编程学习或者竞赛，正因如此，我将它们称为：程序员的游戏。下面将简要介绍三个非常有特色的编程游戏。

1. RoboCode（机器坦克仿真战斗）

图1 RoboCode IDE（图片来自IBM eveloperworks）

RoboCode无疑是这类游戏中最有影响力和代表性的。Robocode是一个很容易使用的机器人战斗仿真器，可以在所有支持Java2的平台上运行。开发者们可以创建自己的机器人，把它放到这个平台上，同其他开发者们创建的机器人对手在这个平面上进行战斗。由于在创建机器人的过程中需要加入用户自己独特的策略代码，因此在战场中你会见到以进攻为重点的机器人，同时也会有以防守为重点的机器人。玩家通过每一次的战斗经历,来了解对手机器人的长处,在不改变机器人自身特点的情况下，去吸收对手机器人的长处来不断的完善自己的机器人,才能使自己的机器人在战场中立于不败之地。可以说Robocode的诞生为智能系统的研究提供了一个很好的理论联系实际的实验平台。
每个Robocode参加者都要利用Java语言元素来创建自己的机器人。Robocode里有一些预先做好的机器人对手让你入门，但一旦您已经不再需要它们了，就可以把您自己创建的机器人加入到正在世界范围内形成的某个联盟里去和世界最强手对阵。
由于RoboCode本身采用Java开发，因此也是跨平台的，在Windows、Linux、Mac OS上都可以运行。

图2 RoboCode在我的Linux系统上运行

RoboCode的中文资料相对来说还是比较丰富的。以前还有个RoboCode中华联盟，不过很可惜，现在似乎已经关闭了。大部分的中文资料都可以在IBM的网站中找到。

2. DroidBattles （战机模拟格斗）

DroidBattles在国内的流行程度远不及RoboCode，这可能跟它迟迟没有推出Windows版本有关。不过，这无疑是一款相当有特色的编程游戏。DroidBattles将战斗蔓延到了太空，角色也变成了形态各异的太空战机。
DroidBattles同样提供了一个完整的IDE环境，非常便于编程和比赛。

图3 DroidBattles的IDE环境

和RoboCode不同，DroidBattles中的飞机配件要多得多，有CPU、引擎、转向装置、护盾等，当然还有各种各样的武器，每种配件都有5种级别，根据配件的种类和级别不同，其价格也有很大区别。由于比赛有着战机价格的限制，过于昂贵的战机将无法进入默认的比赛。因此，在编程之前，确定战机的类型并为其精心选配零件就相当重要了。
战机的程序需要使用一种汇编语言编制。程序是和所安装的配件直接相关的，程序可以通过战机装配的扫描仪、传感器获取战场信息，然后将指令输出到相应控制或武器配件。尽管使用的是汇编语言，但由于使用了配件机制，因此战机的程序其实并不难编写。战机的配置和编译环境都在同一个界面中完成。

图4 DroidBattles的战机装配开发界面

DroidBattles目前支持Linux、Windows两种平台。不过Windows版本仍然处于alpha测试阶段。
DroidBattles的资料及示例战机可以在官网找到。而且IDE中也自带了详尽的教程。

图5 DroidBattles的战斗场面

3. CoreWar （磁芯大战）

和其简单的界面相反，CoreWar有着相当悠久的历史，其最初是于1959在贝尔实验室诞生的，甚至计算机病毒的诞生也和这款游戏有关。磁芯大战运行在当时被称为Mars是一种简单的计算机上，它有固定的8000个内存单元，和约10来个指令。然后整个大战程序就是由这些指令完成。这款游戏在国外很流行，其知名度和地位也是非常高的。每年除了会举办各种大小赛事之外，还会组织周年纪念聚会。

图6 CoreWar的经典界面

CoreWar的战场是一个虚拟机。玩家需要运用许多高深的算法知识编写出自己的“战士”。和计算机病毒相似，战士们在虚拟机中或攻击敌人，或占据更多 “领地”（内存空间），或守护自己的“领地”。比赛以所占领土多少和存活能力强弱决定胜负。这其实就是病毒的雏形（当然似乎某些方面比病毒还厉害），每个程序为了在内存中保留自己，就必须不断地复制自己，传播自己，同时可以修复被其他程序攻击的部分，当然还进行着破坏。
CoreWar支持两种类汇编语言：CoreWar和RedCode。每种语言编写的战士都只能和同类的战士交战。由于相对来说比较专业一些，CoreWar“战士”的编写难度要比前两款游戏要大不少。

图7 众多的“战士”

或许是由于其悠久的历史，CoreWar支持的平台也相当多，从Amiga、早期的Macintosh、DOS，到Windows、Linux、Mac OS X都支持。另外，还有Java版本jMars可供下载。
另外，CoreWar有着相当丰富的赛事（称为Hill），包括世界顶级赛事KOTH（King of The Hill）以及许多世界级锦标赛。在官网和百科全书上，玩家可以找到各种教程及示例程序。

图8 CoreWar的交战场面

以上介绍的3款游戏都是相当有特色的经典编程游戏，有兴趣的编程初学者或者有经验的编程高手不妨试试。

参考链接：

RoboCode官方网站
RoboCode百科全书（Wiki；比赛）
RoboCode基地（机器人下载；教学；论坛；新闻）
文章：《IBM developerWorks：重锤痛击 Robocode！》
RoboCode中文资料（IBMdw中国）
DroidBattles官方网站
DroidBattles示例战机下载
CoreWar官方网站
CoreWar百科全书（丰富的CoreWar信息、教程及链接）
CoreWar名人堂（这些都是世界一流的计算科学家）
有关计算机病毒和CoreWar的一些相关介绍
文章：《CSDN：我的第一本磁芯大战书(My First Corewar Book) 第一章》
文章：《CSDN：磁芯大战(Core War)的语言Redcode教程》

Addone 2006-09-02 01:41 发表评论

一个有意思的测试

Addone — Tue, 27 Jun 2006 12:58:00 GMT

今天发现了一个测试网站，里面有个测试的主题为：你最合适什么专业？
似乎还算准，至少我的结果差不多吧……果然适合搞技术……

You scored as Engineering. You should be an Engineering major!

Engineering

83%

Linguistics

83%

Biology

75%

Philosophy

75%

English

75%

Sociology

75%

Mathematics

75%

Psychology

75%

Anthropology

75%

Dance

58%

Journalism

58%

Theater

58%

Chemistry

50%

Art

33%

What is your Perfect Major? (PLEASE RATE ME!!<3)
created with QuizFarm.com

测试是全英文的，有兴趣的朋友就点击上面的链接测一下试试吧。

在测完之后的结果页面中，有相应的HTML代码，贴到自己的网页上就可以在上面显示结果啦！

Addone 2006-06-27 20:58 发表评论

一时激动，买了PSP

Addone — Mon, 15 May 2006 11:39:00 GMT

趁着五一长假，决定买样东西，最后还是狠下心花了近2000银子把Sony的PSP掌上游戏机买了下来，总算圆了一年来的心愿。

PSP真的是个好东西，尤其让人兴奋的就是那个超大屏幕，真的是既威风又靓丽啊！玩了回游戏，感觉画面、音效绝对无可挑剔，操控性能也是相当的不错。感动ing~
接下来试试应用软件和模拟器，这回珍藏多年的GB Rom总算有出头之日了……呃？无法运行？？提示说数据错误？？？再试试其他的，电子阅读器，不行；日历，不行；PMP媒体播放器，不行……统统不行。怎么可能？？？？
到网上一查，完了，这个版本（2.5）的PSP是没指望了，Sony已经把运行自制软件的功能封杀了，以避免大家都玩盗版游戏。也就是说，在2.5及以上版本的PSP中，大家只能运行正版游戏及官方正式授权的第三方软件了。晕，典型的因噎废食，浪费了这么棒的设备……
PSP在硬件方面绝对是一流的，超小的体积，完善的功能，即使在上面另装个Linux系统都是完全可行的。可以说，从这几天的使用情况来看，PSP的确具有很大的潜力，如果对应的开发平台能再开放一些的话，真的称得上是具有革命意义的游戏机。可惜SCE（Sony电子娱乐）对此似乎完全没有预料到，以至于采取了一些过于猛烈且有害的手段。好在，从SCE最近提出的EDI计划看来，似乎情况有些转机了，真诚的希望Sony能制定一些更加合适的策略，让PSP可以一路走好，我不想花这么一大笔钱买块砖头啊……

现在，我能用PSP做的事情只有：

玩正版游戏（555，太贵了……）；
听歌（当mp3用）；
看电影（好在有转换软件，而且是在PC上运行，也不会被微软封杀；可惜没有Linux版本，而且速度好慢……）；
看网页（这个版本提供了浏览器，而且还比较好用^_^）；
看电子图书（得用浏览器打开，很是麻烦，还得先改成繁体，还得转UTF8编码……好羡慕那些能运行电子阅读器的低版本机器啊……）

我还希望PSP能具有的功能：

提供SDK及API手册，大家可以在上面自由开发软件──当然，Sony也完全可以通过这个东东来限制盗版；
运行Java程序的能力──这个，哈哈，我喜欢^_^；
其他的……不用了吧，有了这两个功能，其他的还会遥远吗？

Addone 2006-05-15 19:39 发表评论

使用Pyqt在Linux下开发GUI桌面应用

Addone — Sat, 01 Apr 2006 07:27:00 GMT

要在Linux下开发具有图形界面的桌面应用程序，我们有许多选择。当然，除了语言方面的考虑外，我们更多的是考虑窗口部件工具箱（以前称为控件库或组件库）的选择，这将在很大程度上影响我们的开发效率。

如果考虑到跨平台应用，选择Java的Swing可能非常合适。但是目前的swing尽管很强大也很灵活，我们始终还是会觉得有些不顺手：例如默认的界面不好看也不像本地程序，第三方皮肤又不好找；开发周期相对较长；执行速度相对慢些等等。
除了java之外，在Windows下，我们一般可以在MFC（VC）和VCL（Delphi）中作选择（当然还有别的）；在Linux下，我们可以选择QT或GTK。

QT具有相当不错的架构以及先进的事件处理机制，文档也很齐全，当然还少不了一个功能不错的可视化窗体设计器QtDesigner。著名的桌面环境KDE就是使用qt库进行开发的。

GTK的架构也不错，不过界面相对而言没有qt的那么炫目。gtk当然也有自己的可视化窗体设计器glade。另一个著名的桌面环境gnome就是使用gtk库进行开发的。另外，gtk也获得了广泛的商业支持。

就我个人而言，我更喜欢qt，桌面环境也更喜欢kde，因为界面确实很漂亮，看着养眼；执行效率也很不错。更重要的是，使用qt进行rad快速开发似乎更为方便。
可惜在linux下使用c++开发程序并非易事，至少你得先熟悉gnu版本的c/c++库才行。我虽然很希望能使用qt做出漂亮的gui桌面应用，但是面对c++本身的复杂以及完全陌生的函数库，我望而却步。
这时，我发现了python。这是一种很简单的脚本语言，其语言特性本身就十分简单易用。更惊人的是，这种语言还可以绑定到多种部件工具箱，包括GTK、QT、MFC、Swing等！而Pyqt就是python和qt部件库的结合。简单易用的python配合强大方便的qtdesigner，我找到了当年在windows下使用vb编程的感觉。

为了使用pyqt进行编程，首先是安装和配置系统环境。我的环境如下：Kubuntu Linux breezy（5.10）；python 2.4；qt 3.3；pyqt 3.14；KDE 3.5。
当然，这样还不够。我们当然可以使用记事本kate来编写代码，但是一款好用的IDE将能够使我们的开发工作事半功倍。我们可以选择KDevelop或者Eric。
KDevelop是KDE下老牌的IDE了，支持N多种语言的开发，其中也包括python，还自带了pyqt的示例程序。
不过，我还是选择了Eric。Eric是KDE下的python集成开发环境，本身就是用pyqt开发的（由此可以看出pyqt的强大……）。eric同样集成了版本管理系统、项目管理、重构等功能。和kdevelop相比，eric中的源代码分类功能更方便，py脚本、qt窗体、语言包等文件是分类管理的。除了任务窗格外，eric还集成了一个python的shell控制台窗格，显得更加适合开发pyqt程序。

一个简单的示例

下面实验一下，使用Eric 3.7来开发一个简单的Helloworld程序。
我们将要使用qtdesigner设计一个窗体，上面放置一个按钮和一个label，点击按钮时显示Hello World，再次点击时则隐藏。

首先我们需要建立一个新工程。
打开Eric后，选择Project->New，然后是填写工程信息。在Project Name栏中填写工程名称，Prog. Language选择Python，UI Type选择QT，Project Directory中选择工程的目录，其他的几项可填可不填，点击<确定>即可。

接下来Eric会询问新工程要使用什么版本控制系统，这里我们还没用到版本控制，就选<无>吧。

现在要新建一个窗体。在左边的工程浏览器切换到窗体标签页，在右键菜单中选择。

Eric会询问新窗体的类型，简单起见，我们选择

部件	属性	值
Form	name	helloForm
	caption	Pyqt示例
TextLabel	name	helloText
	text	Hello, world!
PushButton	name	showHelloButton
	text	打个招呼(&H)