无风的港湾

在做网站过程中，常常要修改网站模板，而模板受css控制。如果在用CSS设计布局时遇到BUG，请认真阅读以下内容，非常容易记忆的，不知道哪位高人把CSS BUG编成了*****了！看看好不好记住呢？
一、IE边框若显若无，须注意，定是高度设置已忘记；
二、浮动产生有缘故，若要父层包含住，紧跟浮动要清除，容器自然显其中；
三、三像素文本慢移不必慌，高度设置帮你忙；
四、兼容各个浏览须注意，默认设置行高可能是*****；
五、独立清除浮动须铭记，行高设无，高设零，设计效果兼浏览；
六、学布局须思路，路随布局原理自然直，轻松驾驭html，流水布局少hack，代码清爽，兼容好，友好引擎喜欢迎。
七、所有标签皆有源，只是默认各不同，span是无极，无极生两仪—内联和块级，img较特殊，但也遵法理，其他只是改造各不同，一个*号全归原，层叠样式理须多练习，万物皆规律。
八、图片链接排版须小心，图片链接文字链接若对齐，padding和vertical-align:middle要设定，虽差微细倒无妨。
九、IE浮动双边距，请用display：inline拘。
十、列表横向排版，列表代码须紧靠，空隙自消须铭记。

标签Tags：css, html, ie, 人, 代码, 兼容, 图片, 容器, 模板, 网站, 设计, 诫, 邪人邪语, 链接

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
(更多…)

标签Tags：cache, div, ie, mod, mysql, path, PHP, server, session, sql, 人, 代码, 兼容, 函数, 含义, 密码, 属性, 引入, 成功, 搜索, 操作系统, 数据, 数据库, 最快, 服务器构建&安全, 版本, 程序, 类, 系统, 表, 解决, 连接, 错误, 镜像, 页面

规则1，减少HTTP请求

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

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

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

规则3，添加Expires头

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

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

标签Tags：ajax, css, flash, javascript, js, server, url, web, 中国特色, 人, 图片, 方法, 更新, 服务器构建&安全, 浏览器, 组件, 网站, 表, 解决, 设计, 重定向, 页面

nternet Explorer, Firefox, Google Chrome, Opera 和 Safari之间的到底有啥区别，下面这几幅搞笑漫画或许能说明什么

Internet Explorer：没什么用，偶尔还真能派上用场

Firefox：坦白地说它面面俱到，但那些傻了吧唧的插件快把它搞的没法用了

Safari：非常的高效，但那些使用Safari的人总对其质量夸大其词

Chrome：就是一个快字

Opera：有些人非常喜欢，但大多数人认为Opera很2

标签Tags：firefox, google, 人, 区别, 搞笑, 浏览器, 网站建设, 说明

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

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

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

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

标签Tags：cache, ie, 人, 对象, 数据, 方法, 游戏开发, 类, 表, 解决, 设计, 连接

目前，我们的游戏服务器组是按多进程的方式设计的。强调多进程，是想提另外一点，我们每个进程上是单线程的。所以，我们在设计中，系统的复杂点在于进程间如何交换数据；而不需要考虑线程间的数据锁问题。

如果肆意的做进程间通讯，在进程数量不断增加后，会使系统混乱不可控。经过分析后，我决定做如下的限制：

如果一个进程需要和多个服务器做双向通讯，那么这个进程不能处理复杂的逻辑，而只是过滤和转发数据用。即，这样的一个进程 S ，只会把进程 A 发过来的数据转发到 B ；或把进程 B 发过来的数据转发到 A 。或者从一端发过来的数据，经过简单的协议分析后，可以分发到不同的地方。例如，把客户端发过来的数据包中的聊天信息分离处理，交到聊天进程处理。

有逻辑处理的进程上的数据流一定是单向的，它可以从多个数据源读取数据，但是处理后一定反馈到另外的地方，而不需要和数据源做逻辑上的交互。

每个进程尽可能的保持单个输入点，或是单个输出点。

所有费时的操作均发到独立的进程，以队列方式处理。

按功能和场景划分进程，单一服务和单一场景中不再分离出多个进程做负载均衡。 (更多…)

标签Tags：cache, 人, 分离, 数据, 数据库, 游戏, 游戏开发, 程序, 类, 系统, 设计, 连接

MMO 的 engine 中，需要解决的最重要的问题之一，就是如何把游戏世界中的状态改变消息正确的通知给需要知道这条信息的玩家。

通常，我们会设定每个玩家的 AOI ( Area Of Interest )。当一个对象发生改变时，它会把消息广播出去；那些 AOI 覆盖到它的玩家会收到这些广播消息。

但是，在我们现在的游戏系统中，简单的 AOI 系统是不够用的。比如，类似 wow 中的盗贼隐身，明明已经离你很近，但是你的 client 却看不见他。诚然，我们可以在 client 判断这个逻辑，对盗贼不于显示，而 engine 依然广播盗贼移动的消息。对于不作弊的 client ，这是个简单的解决方案。但在理论上却提供了看见隐身人的可能性，所以，我期望有更好的方法让 engine 可以只将消息广播到那些必须接收这些消息的 client 。但是，在实现这个同时，又不能让底层 engine 牵扯太多逻辑信息。 (更多…)

标签Tags：ie, 人, 判断, 对象, 属性, 数据, 方法, 游戏, 游戏开发, 类, 系统, 解决

现在 MMO 中经济系统往往是设计的关键。可能是网络游戏发展的时间较短，并没有形成系统的理论的缘故，我所了解的网络游戏中都没有特别好的处理好经济系统中货币的控制和流通问题。

我们知道，货币只是一种经济活动中一种媒介，货币本身是没有价值的。但是，网络游戏中却很难体现这一点。系统对游戏直接的货币投放是不可控制的，虽然很多设计人员企图控制，但只是收效不同而已。大体上，大家都是用玩家的在线时间换取系统货币总量的增加，而用玩家自身的修炼回收掉货币。还有一小部分是用上税和赌博的形式回收掉。

云风正在设计的游戏很不一样，是基于国家间的贸易和战争而不是个人修炼的。强调一种政府的管理，而非玩家自发组成的团体。我更希望做出一个战略感的游戏，而不是强调团体战术或者个人战斗。 (更多…)

标签Tags：人, 工具, 方法, 游戏, 游戏开发, 系统, 自身, 设计

3d 游戏会用到大量的帖图，许多显卡要求贴图的尺寸必须是2的整数次方。这样，许多贴图的边角都会被浪费掉。尤其是大量无关的小贴图，我们通常想把他们合并在一张贴图上，尽量充满整个区域。

合并这些零碎贴图的算法，在学术上被称为排料问题。我尚未找到特别好的解决方法，所以这里就不展开写了。这里想讨论的是这些小贴图的管理。

我们现在的思路是，在engine 的比较上的层次，不用关心需要用的贴图在哪里，在哪张图片上的哪个区域。这样做，就不用局限于相关的图放在一张物理的图片上，可以由工具任意分割打包组合。固然，不相干的贴图过于零碎的逻辑贴图分散在不同的物理图片上，会降低效率。但这个问题就和内存分配器的实现中，内存碎片的问题一样，是不可避免但却可以有诸多方法来改善的。

其实 DirectX 本就充当了一个显存管理器的工作。我们做的只是在这种基于动态的管理模式上再加一层事前的开发期优化而已。

实现的方法很简单，用一个文本文件描述另一个图片文件的区域即可。engine 只需要把这个文件当作一个逻辑贴图打开解析。至于物理图片文件的管理，交给资源管理模块即可。

而这个文件的生成和管理，就得另写一个工具了。能写出优秀的图片自动组合工具固然好，如果没有也可以退而求其次，做一个可以给人像搭积木一样的拼图工具也可以。可以方便的让人来把零散的图片见缝插针的拼到一起，未尝不是一件趣事

标签Tags：人, 图片, 工具, 方法, 游戏, 游戏开发, 解决, 解决方法

游戏的 client 最文件数量最多，数据量最大的，往往是美术资源。（几乎所有的商业游戏都会在游戏发布时对资源文件打包，我们这里讨论的是开发期未打包的文件）当一个游戏的规模大到一定时，我们需要调动巨量的美术人力来制作这些资源。伴随着游戏规模和制作团队的扩大，设计资源文件的存放目录结构和文件命名规则往往成了项目一开始的头等大事。

2d 游戏这个问题稍微轻一点，3d 游戏更是有模型，贴图，骨骼等等的文件关联性在里面。这次我们的 3d 项目，让我又一次面对和思考这个问题。

如果公司有多个成熟的类似项目，整个美术的制作流程被流水线化了。那么久而久之，自然有一套目录结构和命名规则的规范可以遵守。但是由于项目的多变性，而技术的改良，这个规范也不是一成不变的。

这里说的技术，不能狭义的看成是 3d 渲染技术。关于资源的管理，复用等也是 3d engine 技术的一部分。
(更多…)

标签Tags：google, ie, 人, 搜索, 数据, 方法, 游戏, 游戏开发, 程序, 类, 解决, 设计, 链接