Skywind Inside

我的鼠标动作游戏 - Final Weapon

学习AS3的入门程序，前段时间学了两个星期的AS3，觉得挺有意思的，又画了两个星期写了这个WEB游戏：

http://www.joynb.net/resource/weapon/

自动地图生成算法

让MMO玩家每次进入副本都有全新的体验，百玩不厌！让部分地图制作从手工制作中解放出来，开发成本大大降低！！

运行地址：http://218.107.55.250:89/mazemap/cavemake.php

HASH 表优化试验

最近用纯C作了一个dict，根据试验，比 stl的 map快 2.3-2.5倍，比 hash_map快 1.3倍，主要用到的优化策略如下：

1. skiplist：
传统hash-bucket中，使用链表靠 next, 指针记录同一个 bucket中的各个节点，查找时候需要一个一个的搜索，而改进以后的 bucket节点，使用 next, next4, next8三级指针，分别指向后一个节点，后四个节点，后八个节点，如此保证链表有序的情况下，如果要搜索，就直接考虑 next8的值和当前值大小，如果小于当前值，直接跳过八个节点，如果大于那再一次判断 next4与next。如此有序链表的遍历速度提高了 8倍。

2. 双hash：
使用两次hash，开辟一个长度为 64的 LRU数组，记录最近访问过的节点，使用 hash2来定位 LRU数组的位置，当搜索发生时，首先根据 hash2在 LRU数组中查找是否最近访问过该节点，如果访问过就直接返回，如果没有访问过则继续用 hash1在 bucket中查找，如果查找到的话，就按照 hash2的值覆盖一下 LRU中该位置的数据。

再加上一些内存管理方面的优化，以及一些编码方式的改进，对 key/value分别取 string或 int，四种情况下，平均比 stl的 map快 2.3-2.5倍，比 hash_map快 1.3倍。

断点 C语言

看着那密密麻麻的反汇编，连眼睛红了都没有发现，
听到你说错误很难重现，人数还一点一点再往下减，

我转过我的脸，不和你争辩，
未释放指针肯定，非常的危险，

发誓从今天，不再用C语言，
我真想改用脚本重构好几遍，

我走在你后面，冲进二号会议室里面，
呼唤着版本不能随便顺延，

打开的源文件，设满很多断点，
只想在睡前让程序能够，撑到明天。

ASCII Art Algorithm

因为希望将图片转换成字符以后可以方便的帖到论坛或者BBS上，所以画时间写了这个算法。现有很多算法都是将一个点匹配成一个字符，这样转换工作只是简单的将点亮度查表后换成ASCII字符而已，但是其实这样做的效果并不十分好，首先80x25的字符屏幕就只能表示80x25个点，无法充分发挥单个字符的字形特点，而且图片很多精度和细节都丢失了。比如下面这个连接：

http://www.sebastian-r.de......

所以我的算法主要是匹配周围一部分点到ASCII字符，这样斜线能够顺利匹配成“/”，其他形状的东西也能够顺利按照字形特点进行匹配，因此同样80x25个点，但是后者所能够表达的像素点更多，细节度更加丰富：

上面的效果是作了误差扩散的，其实转换成ASCII字符时不做也可以，只是说希望转换前的局部/整体亮度等于转换后亮度，能量守恒一些而已。其实如果用同一种颜色的64个常见字符表达精度和细节度很高，对比度不高的图片还是比较困难的。

可以进一步优化的方法也有几种，其一是对照片作拉普拉斯变换，将噪声过滤掉再取出轮廓，这样转换出来的就是仅仅包含轮廓的对比度很高的图片了。或者将图片频谱中能量不高的，比较弱的频率去掉，留下能量高的频率，这样图片看起来更干净一些，只是后面这两种方法就无法保证实时渲染了。

牌上的花色－MUD中的玩家（Bartle玩家分类理论翻译）

游戏设计需要基础性理论，Richard A. Bartle，第一款MUD（被称为MUD1）的开发者，该文章起于1990年，经作者多次整理而成。在游戏设计“难有统一理论”的情况下，该文论点受到了决大多数开发者的一致接受和好评。可见基础性理论不但有利于我们的分析与设计，更重要的是大家能在同一层面上用同样的术语进行更有效的沟通：

http://www.joynb.net/resource/hcdsc.htm

最近在阅读 XBOX360 Live方面的文档，作为其中提及的一个重要概念“Bartle's player type”的论文，似乎影响了整个第四代Live的设计，恰巧最近我也在整理一些Live相关资料，就顺带将这个基础理论进行了翻译。