无风的港湾

营销人员可能明白强势品牌的重要性，但却对游戏机制一无所知；程序员可能深谙强大游戏机制的意义所在，但对游戏机制的传达方式一窍不通。这样的营销人员和程序员都无法各自打造出成功的游戏。因为一款成功的游戏离不开跨领域的协调性，然而，我们经常见到情况就如上所述，游戏制作团队的成员往往只熟悉游戏设计中面向己方的专业知识，对其他学科的知识所知甚少。

此时游戏设计师的职责显得尤为关键把不同专业的观点融合为全面的设计构想。如果设计师做不到，结果就是，团队里的成员各忙各的，把时间和精力浪费在毫不相干的工作上。

游戏设计包含了几个层次的工作，且各个层次彼此不同，就如游戏的市场营销和用户界面，把这些毫不相干的层次组合起来，这看似一项艰难的任务。完成这项任务需要明白游戏设计交叉性的理论框架、形象化游戏设计方案的下滴（上滴）效应。

手机平台的两个支点

手机游戏带给玩家的融入感可能不如掌机游戏或电脑游戏那么强烈，但如果要深入研究游戏设计结构，简易的手机游戏却是个理想的探索起点。手机游戏开发之所以独特基于两点：能简则简，以量取胜。

能简则简。你可能已经听说过这么句话：一旦所有可删除的对象都被删除了，一个游戏就趋于完美了。手机平台检验了这个论断。即使是在今天这个iPhone的黎明时代，手机游戏开发者仍然不得不应对手机游戏需局限于128K空间的难题，而这128K包括了美工、代码、游戏数据、声音和其他所有游戏要素。

这种容量限制几乎足以令任何一种游戏设置寸步难行，但游戏还是顽强地活下来了，虽然硕果仅存的是些再简单不过的游戏。这些残存下来的游戏拥有高度精炼和清晰可辩的设计构架。

以量取胜。在时间相对紧凑的开发周期中，手机游戏设计师要同时开工好几个游戏，这几乎囊括所有你能想得到的游戏类型。

同时设计三四款不同的游戏，你有两个选择：要么是通过一个共同的工作期掌握所有游戏的设计进程，要么顶着令人抓狂的压力分别跟进所有游戏设计进度。以下是一些手机游戏设计的经验总结。 (更多…)

1、什么是Rsync

Rsync（remote synchronize）是一个远程数据同步工具，可通过LAN/WAN快速同步多台主机间的文件。Rsync使用所谓的“Rsync算法”来使本地和远程两个主机之间的文件达到同步，这个算法只传送两个文件的不同部分，而不是每次都整份传送，因此速度相当快。

  (更多…)

<?php
# $Id: js.class.php,v 0.1 p $

// 禁止直接访问该页面
if (basename($HTTP_SERVER_VARS['PHP_SELF']) == "js.class.php") {
     header("HTTP/1.0 404 Not Found");
}

# Purpose 封装了一些常用的Javascript代码，以便在PHP中快速调用

class JS{
     function JS(){}

     #返回上页
     # @param $step 返回的层数 默认为1
     function Back($step = -1){
         $msg = "history.go(".$step.");";
         JS::_Write($msg);
         JS::FreeResource();
         exit;
     }

    # 弹出警告的窗口
    # @param $msg 警告信息
     function Alert($msg){
         $msg = "alert(\"".$msg."\");";
         JS::_Write($msg);
     }

    # 写js
    # @param $msg
     function _Write($msg) {
         echo "<script language=\"javascript\">\n";
         echo $msg;
         echo "\n</SCRIPT>";
     }

     # 刷新当前页
     function Reload(){
         $msg = "location.reload();";
         JS::FreeResource();
         JS::_Write($msg);
         exit;
     }

     #刷新弹出父页
     function ReloadOpener(){
         $msg = "if (opener)     opener.location.reload();";
         JS::_Write($msg);
     }

     #跳转到url
     #@param $url 目标页
     function Goto($url){
         $msg = "location.href = ‘$url’;";
         JS::FreeResource();
         JS::_Write($msg);
         exit;
     }

     #关闭窗口
     function Close(){
         $msg = "window.close()";
         JS::FreeResource();
         JS::_Write($msg);
         exit;
     }

     #提交表单
     #@param $frm 表单名
     function Submit($frm){
         $msg = $frm.".submit();";
         JS::_Write($msg);
     }

    #关闭数据库连接
    function FreeResource(){
         // 数据库连接标志
         global $conn;
         if (is_resource($conn))
             @mysql_close($conn);
     }
}
?>

mysql my.cnf文件常见优化模块
[mysqld]
port = 3306
server-id = 1
socket = /tmp/mysql.sock

# 避免MySQL的外部锁定，减少出错几率增强稳定性。
skip-locking

# 禁止MySQL对外部连接进行DNS解析
skip-name-resolve

# 指定MySQL可能的连接数量
back_log = 256
(更多…)

正则表达式匹配，其中：

* ~ 为区分大小写匹配
* ~* 为不区分大小写匹配
* !~和!~*分别为区分大小写不匹配及不区分大小写不匹配
文件及目录匹配，其中：

* -f和!-f用来判断是否存在文件
* -d和!-d用来判断是否存在目录
* -e和!-e用来判断是否存在文件或目录
* -x和!-x用来判断文件是否可执行
flag标记有：

* last 相当于Apache里的[L]标记，表示完成rewrite
* break 终止匹配, 不再匹配后面的规则
* redirect 返回302临时重定向 地址栏会显示跳转后的地址
* permanent 返回301永久重定向 地址栏会显示跳转后的地址
一些可用的全局变量有，可以用做条件判断(待补全) (更多…)

/usr/local/bin/memcached -d -m 10 -u root -l 127.0.0.1 -p 11211 -c 256 -P /tmp/memcached.pid
memcached 的服务正式启动

Memcache::add — 添加一个值，如果已经存在，则返回false
Memcache::addServer — 添加一个可供使用的服务器地址
Memcache::close — 关闭一个Memcache对象
Memcache::connect — 创建一个Memcache对象
memcache_debug — 控制调试功能
Memcache::decrement — 对保存的某个key中的值进行减法操作
Memcache::delete — 删除一个key值
Memcache::flush — 清除所有缓存的数据
Memcache::get — 获取一个key值
Memcache::getExtendedStats — 获取进程池中所有进程的运行系统统计
Memcache::getServerStatus — 获取运行服务器的参数
Memcache::getStats — 返回服务器的一些运行统计信息
Memcache::getVersion — 返回运行的Memcache的版本信息
Memcache::increment — 对保存的某个key中的值进行加法操作
Memcache::pconnect — 创建一个Memcache的持久连接对象
Memcache::replace — R对一个已有的key进行覆写操作
Memcache::set — 添加一个值，如果已经存在，则覆写
Memcache::setCompressThreshold — 对大于某一大小的数据进行压缩
Memcache::setServerParams — 在运行时修改服务器的参数 (更多…)

规则1，减少HTTP请求

这是最重要的原则，如果14条规则里只能选一条，那就是它了。可以通过多种方法减少HTTP请求，例如合并图片，合并JS和CSS等等。这一点薄荷网有很多改进的余地，首先应该把现在的JS合并了。

规则2，使用内容发布网络

内容发布网络就是CDN了，但是CDN似乎挺贵的，目前还不适合薄荷网，不过可以考虑自己弄一个网通的静态资源服务器解决有中国特色的可恶的南北互通问题。

规则3，添加Expires头

这个没什么好说的，是个建网站的人都应该知道。目前薄荷网图片,css,js,flash过期时间设置了3年，可以说是永久了，：） Expires有个麻烦的地方是内容更新问题，Ruby on Rails这方面处理的非常棒，它是在文件名后面自动带了

资源文件的timestamp，完美解决。 (更多…)

周末一直在考虑怎样在游戏服务器中保存和管理那些有平面坐标的对象。希望能方便的查到每个对象附近的东西。以往用过的方法是给（平面）场景打上格子，然后再把每个对象放入相应的格子中。

这次又遇到这个问题，却不想用网格的方法来解决问题了。

原因主要是这么几点：一，用网格对于大场景特别消耗内存，而且不太适合做无限延展的场景。二，查询每个对象周围的东西时，不太方便。格子的粒度越小，速度越慢。

虽然这两个问题，都可以通过改进算法来回避。不过这次，我想尝试一下用四叉树解决这个问题。

用四叉树的话，内存占用量应该 O(n) 。如果定死了四叉树的扩展深度，可以推算出节点的最大可能消耗量。我想，如果只是为了解决 AOI 的计算，5 级深度已经足够。这样，大约预分配出 20 * n 个节点，几乎肯定够用了。

我希望场景是从坐标原点向四周无限延展开，没有什么具体的尺寸限制。所以，这次实现的时候对四叉树做了改造。第一级的划分是一个特例，它将平面分成四块，每一块都可以向某个方向无限延伸。
(更多…)

今天开始正式开始做数据服务器。在这点上，我希望一组服务器上所有的逻辑服务遇到的数据存取需求都通过一个单一的数据服务器完成。而且，写入数据是单向通讯的。即，逻辑服务器只提读写盘请求，而无须确认。写数据好说，读数据稍微难处理一点，我现在的方案是，数据服务器加载数据的部分只对位置服务器负责，把数据提交到位置服务器即可。位置服务器可以通过分析数据知道玩家的数据流应该流向哪台逻辑服务器。

以上逻辑是基于每个玩家有独立的数据的，而且一个玩家同时只存在于唯一一个场景。也就是说，当一组数据存活的时候，只唯一属于一台逻辑服务器。这样做的好处是，切换场景非常的简单，只是让玩家从一个场景退出，给数据服务器发出写盘指令，并发送所有数据。数据服务器写盘的同时也 cache 了这些数据，并向位置服务器提交新的位置，并把这些数据转发向位置服务器。位置服务器可以再转交给新的场景。

对于玩家登陆和登出的处理并没有特别之处，我们可以设立两个虚拟场景，一个负责登入，一个负责登出。每个新连接自动导入登入场景，这个场景负责发出加载指令（下面可以看到，甚至无须设置加载数据的协议）。然后再做一个自动的场景切换操作即可。而玩家登出，则是转入登出场景，这是一个黑洞，玩家的连接可以在这里安全的断掉。

当玩家不停的穿梭于各个场景之间时，为了避免频繁的数据转发，我们可以给玩家数据做一个赃标记。如果没有弄赃，实际的数据可以不被转发。这个标记的另一个意义在于，若数据没有弄赃，而数据服务器的 cache 中又没有数据时，就需要从外存加载了。其实这就是一个读请求。 (更多…)