IT牛人博客聚合

离上一次写 开发笔记 快有一个月了。当然，中间我们放了 10 天的长假。

项目的进展比较缓慢、主要是解决一些琐碎的技术问题，客户端的比较多，服务器这边就是节前的一些 bug 修改和功能完善。大部分工作都不是我自己在做。由于感到人手不足，小规模私下的做了一点点招聘工作。也算物色到一两个同学可以过来一起干的。好久没做招聘工作了，都不知道怎么开始谈。唉，我们这里条件不算好，要求还多，都不好意思开口。

可写的东西其实也不少。今天挑一点来记录一下。

话要说回 开发笔记第六篇 ，我谈过结构化数据的共享存储。这个模块细化其实有挺多工作要做。核心部分我自己完成了，没有用太多时间。然后，有位华南理工的同学想来实习。想到他们学校距离我们办公室仅有

查看全文: http://www.udpwork.com/item/6838.html

    今天看到这里给出了一个“星际争霸是 NP-hard 问题”的一个证明。具体地说，给定一个初始布局（包括地图、双方已有资源、双方已有建筑、双方已有兵力），判断其中一方是否能获胜，这个问题是 NP-hard 的。当然，考虑到即时战略游戏的复杂性，这个结论并不出人意料；真正有趣的，则是如何巧妙地利用游戏中的元素，构造出极其精巧的初始局面，从而转化成某个已知的 NP-complete 问题。下面是原文中给出的证明。这个证明有没有什么漏洞？你还能想到哪些别的证明方法？欢迎在下面留言一同分享。

    假设初始时有 A 、 B 两位玩家，他们分别位于两个孤

查看全文: http://www.udpwork.com/item/6748.html

今天很早就起床了，以至于到了办公室还不到 11 点。中饭前有一个多小时可以做各种杂事。

我把周末做的工作和蜗牛同步了一下信息，然后得到了几个新需求。主要就是还是需要在协议定义中加入 protobuf 中等价于 service 的东西。思索了一下，觉得有必要，就花了一个小时把特性加上。 C Binding API 方面还有一点疏漏的地方。大概是源于基于 Erlang 框架下的一些小困难。略微修改了下 C 接口协议就 OK 了。然后很 happy 的去食堂吃饭。

然后我暂时就可以转向 Client 方面的一些需求分析以及解决了。

在生成动画树的数据方面，我们的交换格式使用了某中文本中间格式，最终利用 protobuf 来做二进制持

查看全文: http://www.udpwork.com/item/6676.html

    这篇文章是漫话中文分词算法的续篇。在这里，我们将紧接着上一篇文章的内容继续探讨下去：如果计算机可以对一句话进行自动分词，它还能进一步整理句子的结构，甚至理解句子的意思吗？这两篇文章的关系十分紧密，因此，我把前一篇文章改名为了《漫话中文自动分词和语义识别（上）》，这篇文章自然就是它的下篇。我已经在很多不同的地方做过与这个话题有关的演讲了，在这里我想把它们写下来，和更多的人一同分享。

    什么叫做句法结构呢？让我们来看一些例子。“白天鹅在水中游”，这句话是有歧义的，它可能指的是“白天有一只鹅在水中游”，也可能指的是“有一只白天鹅在水中游”。不同

查看全文: http://www.udpwork.com/item/6654.html

社交游戏方兴未艾，我不相信未来就一定是发行商的天下。于是，打算抛砖引玉，利用自家产品积累的一些数据，建立一个模型（非常不完善，所以期待大家各种板砖）。模型要解决的问题是：给出一个预算（Budget），计算多久能够收回预算。地址：

http://www.magnetjoy.com/budget.html

目前的思路是，用预算，除以CPC（install，而非click，我们自己计算，在FB台湾，大概是0.3美金左右，FB自己的Ads CPC要考虑到Developer Dashboards中的Auth通过率），得到预算带来的直接安装用户数。结合我们自己的经验，发现一个普通的社交游戏，一般一个外界用户会带来X倍的自增长。姑且称为Org

查看全文: http://www.udpwork.com/item/6647.html

     据说，爱出题也是 Geek 的一种特征。这几天在做语言工程课的期末大作业时，再一次见识了汉语里各种诡异的语法规则，然后突然想到了这样一种好玩的题型，于是竟然暂时放下手中的作业，花时间编了几个这样的题目来（感谢 Geek 小美女 localhost_8080 的帮助）。

    下面的每一组词中，前五个词都具有某种共同的性质，这种性质是后面五个词都不具有的。你能猜出每组词所对应的那个性质吗？

      (1) 反复、高兴、磨蹭、说笑、许多 | 地震、动静、金黄、巨大、雕刻

&nb

查看全文: http://www.udpwork.com/item/6597.html

开始这个话题前，离上篇开发笔记已经有一周多了。我是打算一直把开发笔记写下去的，而开发过程中一定不会一帆风顺，各种技术的抉择，放弃，都可能有反复。公开记录这个历程，即是对思路的持久化，又是一种自我督促。不轻易陷入到技术细节中而丢失了产品开发进度。而且有一天，当我们的项目完成了后，我可以对所有人说，看，我们的东西就是这样一步步做出来的。每个点滴都凝聚了叫得上名字的开发人员这么多个月的心血。

技术方案的争议在我们几个人内部是很激烈的。让自己的想法说服每个人是很困难的。有下面这个话题，是源于我们未来的服务器的数据流到底是怎样的。

我希望数据和逻辑可以分离，有物理上独立的点可以存取数据。并且有单独的 agent 实体为每个外部连接服务。这

查看全文: http://www.udpwork.com/item/6532.html

这周我开始做场景模块。因为所有 PC 在 server 端采用独立的 agent 的方式工作。他们分离开，就需要有一个模块来沟通他们。在一期目标中，就是一个简单的场景服务。用来同步每个 agent 看到的世界。

这部分问题，前不久思考过 。需求归纳如下：

每个 agent 可以了解场景中发生的变化。

当 agent 进入场景时，需要获取整个世界的状态。

agent 进入场景时，需要可以查询到它离开时自己的状态。关于角色在场景中的位置信息由场景服务维护这一点，在 开发笔记1 中提到过。

大批量的数据同步对性能需求比较高。因为在 N 个角色场景中，同步量是 N*N 的。虽说，先设计接口，实现的优化在第二步。但是接口设计又决定了

查看全文: http://www.udpwork.com/item/6484.html

话接 开发笔记1 。我们将为每个玩家的接入提供一个 agent 服务。agent 相应玩家发送过来的数据包，然后给于反馈。

对于 agent 服务，是一个典型的包驱动模式。无论我们用 Erlang 框架，还是用 ZeroMQ 自己搭建的框架，agent 都会不会有太多的不同。它将利用一个单一的输入点获取输入，根据这些输入产生输出。这个输入点是由框架提供的。框架把 Agent 感兴趣的包发给它。

我们会有许多 agent ，在没有它感兴趣的包到来时，agent 处于挂起状态（而不是轮询输入点）。这样做可以大量节省 cpu 资源。怎样做的高效，就是框架的责任了，暂时我们不展开讨论框架的设计。

下面来看，一旦数据包进入 agent

查看全文: http://www.udpwork.com/item/6459.html

    下面大家将会看到的是一个极其简单而又极其复杂的“迷宫”，这无疑是我在本年度见到的最变态的谜题：从左边入口处的 2011 进去，在迷宫里转悠，最后变成 2012 从右边出来。你可以在迷宫里转圈，可以重复之前走过的路，但不能往回退着走。

      

    你能成功走出来吗？

 

 

 

 

 

 

 

 

 

 

 

 

 &nb

查看全文: http://www.udpwork.com/item/6436.html

    去年年初的时候，我曾经发布过某专业课期末作业研究过程中带来的一个有趣的副产品：汉字的字义网络图。不过，当时我是直接调用的 Mathematica 的相关函数，函数几乎不能调整参数，并且也无法处理边上权重不同的情况。最近在研究引力斥力绘图算法，突然想到把当时的数据重新画一张图。于是就有了汉字地图第二版（点击小图看大图）：

   

    还是简述一下整个图的制作方法吧。我们的基本依据就是，在全唐诗中，经常对偶的字往往都有非常密切的关系。于是，我们首先找出全唐诗中的对偶字：

   &n

查看全文: http://www.udpwork.com/item/6387.html

这篇很淡疼的文章来源于我在微博上的争论。需要列数据，字数限制不合适，所以单列一篇了。

昨天翻出了元帅同学的一篇旧文，游戏数值设计(1)：定义与目标 , 转发到微博上。我一向是喜欢看他吐槽的，这篇吐国内的 MMORPG 游戏策划分工的文章，深得我心。

我一直对国内 MMORPG 制作把设计人员分为 文案策划、系统策划、数值策划不以为然。文案拆分出去做倒还说得过去，这所谓系统策划和数值策划的拆分简直就是莫名其妙了。现代电子游戏从桌面游戏一路发展过来，怎样让玩家享受规则，一直是一个整体。如果一个人来设计一个游戏，那么脑子里必然要逐步形成这个游戏做出来是什么样子的，然后细化里面的细节，玩家在他设计的规则下怎么进行游戏。所谓数值设计，是这

查看全文: http://www.udpwork.com/item/6315.html

接上回，按照我们一期项目的需求，昨天我简单设计了数据库里的数据格式。数据库采用的是 Redis ，我把它看成一个远端的数据结构保存设备。它提供基本的 Key-Value 储存功能，没有层级表。如果需要两层结构，可以在 Value 里保存一组 Hashes 。

这是我第一次实战使用 Redis ，没有什么经验。不过类似的设施几年前自己实现过，区别不大。经过这几年，有了 Redis 这个开源项目，就不需要重造轮子了。但其模式还是比较熟悉的。也就是说，是按我历史经验来使用 Redis 。

一期项目需要比较简单，不打算把数据拆分到不同的数据服务器上。但为日后的拆分需求做好设计准备。以后有需要，可以按 Key 的前缀把数据分到不同的位置。

查看全文: http://www.udpwork.com/item/6307.html

折腾了好久，终于可以开始正式项目开发了。

之前的这段日子，我们陷落在公司的股权分配问题中，纠结于到底需要几个人到位才启动；更是反复讨论，到底应该做个怎样的游戏。林林总总，终于，在已经到位的几位同学的摩拳擦掌中，叮当决定自己挂帅开始干了。

就这么不到十个人，空旷的办公室，跟我们起先想像的情况不太一样。尤其是主策划还没有落定。我说，叮当，你好歹也是一资深游戏玩家，带了这么多年的游戏部，跟了这么多成功的项目，没吃过猪肉总见过猪跑吧，我就不相信你干着会比别人差。若不是我必须盯着程序实现这块，我都想自己做主策划了。不过有你干，我放心。

主策划的位置，咱们可以先空着，前期工作不能延。产品经理代理一下游戏主策划的位置也是创业公司必须的；正如

查看全文: http://www.udpwork.com/item/6297.html

    这是我前几天看到的一个视频。毫无疑问，它是我所见过的各种生命游戏构造中最神奇的一个：

      

    在 LifeWiki 中有一个词条详细介绍了这个构造：它叫做 OTCA metapixel ，是由 Brice Due 在 2005 至 2006 年间构造的。其中，每一个 metapixel 的大小为 2048 × 2048 ，周期为 35328 。

 

视频出处：http://www.youtube.com/watch?v=QtJ77qsLrpw

查看更多：

查看全文: http://www.udpwork.com/item/6280.html

由于在筹备做新的项目，所以关于网络游戏方面的讨论，在朋友圈子中多了许多。前几天和投资人吃饭，说起前几年盛大提出所谓免费游戏的策略转型，问道有没有可能在未来几年出现新的收费模式。从这个话题引开，饭桌上我跟叮当讨论了很久。

回想那一年，所谓免费游戏之风逐步侵蚀中国网络游戏市场之时，网易的开发团队起初是有所抵触的。我刚到杭州不久，远离广州的开发团队，静心思考了许多。所谓公平的游戏，我想我比大多数人都在乎。把玩游戏变成一个金钱投入的游戏，我是万般不愿意的。但我相信道具收费的方式有它内在的逻辑。实际上，在网易成熟的时间收费游戏，梦幻西游中，点卡交易系统早就存在，并良性运作了很久了。许多玩家已然在游戏中花掉了远远超过时间收费收取的金钱。

那

查看全文: http://www.udpwork.com/item/6101.html