无风的港湾

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

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

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

手机平台的两个支点

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

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

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

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

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

标签Tags：代码, 对象, 工具, 技巧, 数据, 游戏, 游戏开发, 盈利, 程序, 类, 系统, 营销, 表, 解决, 设计, 鼠标

fhod 邪恶八进制
帝国备份王(Empirebak)简介
EmpireBak是一款完全免费、专门为Mysql大数据的备份与导入而设计的软件,系统采用分卷备份与导入,理论上可备份任何大小的数据库.
可在 http://www.phome.net/ebak2008os/ 下载到
默认账号密码为
admin  123456
登陆后先备份一次数据
备份时可选择备份到的目录。。默认有个safemod
当然也可以是别的..这里以safemod来说了
备份完毕后来到
管理备份目录
打包并下载
把开始备份到的数据可以先下回分析..当然数据库比较大的话可以省略这一步..因为我之前下载已经分析完毕了
(更多…)

标签Tags：2008, html, ie, mod, mysql, PHP, sql, web, webs, 密码, 成功, 数据, 数据库, 服务器构建&安全, 系统, 设计, 诫, 软件

(更多…)

标签Tags：apache2, code, iis6.0, include, mysql, path, PHP, PHP, php.ini, server, session, sql, url, web, 上传, 中文, 兼容, 初学者, 区别, 失败, 密码, 应用程序, 数据, 数据库, 方法, 版本, 程序, 网站, 网络编程, 解决, 解决方法, 设计, 诫, 邮件, 错误, 页面, 验证

一、 内存

　　在PHP中，填充一个字符串变量相当简单，这只需要一个语句”"即可，并且该字符串能够被自由地修改、拷贝和移动。而在C语言中，尽管你能够编写例如”char *str = “hello world “;”这样的一个简单的静态字符串;但是，却不能修改该字符串，因为它生存于程序空间内。为了创建一个可操纵的字符串，你必须分配一个内存块，并且通过一个函数(例如strdup())来复制其内容。

以下为引用的内容：

　　{

　　char *str;

　　str = strdup(“hello world”);

　　if (!str) {

　　fprintf(stderr， “Unable to allocate memory!”);

　　}

　　}

　　由于后面我们将分析的各种原因，传统型内存管理函数(例如malloc()，free()，strdup()，realloc()，calloc()，等等)几乎都不能直接为PHP源代码所使用。 (更多…)

标签Tags：ie, PHP, PHP, web, 代码, 函数, 应用程序, 扩展函数, 搜索, 操作系统, 方法, 源代码, 版本, 程序, 系统, 网络编程, 解决, 设计, 诫, 错误

AJAX bandwagon是个好去处。它带给你更快、更高效、更强动态的应用。但它也有自身的缺陷。

初一看，具备一些常识似乎就能避免这些缺陷，在一定程度上，的确如此。但从DHTML起源来看，AJAX应用程序充满了结构性差异。不论你在应用程序开发工作中掌握了多少常识，从别人犯的错误中吸取教训也是有好处的。我们称这些错误为“七宗死罪”，但它们不能代表全部的错误。

事实上，在你犯这些致命过失之前，你可能首先犯了一些较轻的错误。因此我们从这里着手。这是每个人都可能犯的错误。这些错误是多么普遍，通过Google搜索一下，你就可以发现大部分的错误。
(更多…)

标签Tags：ajax, dhtml, google, html, javascript, JavaScript&Ajax, url, 人, 应用程序, 搜索, 新手, 方法, 更新, 浏览器, 程序, 网络编程, 自身, 设计, 诫, 链接, 错误, 页面

在指南的开始，我们说过数据过滤在任何语言、任何平台上都是WEB应用安全的基石。这包含检验输入到应用的数据以及从应用输出的数据，而一个好的软件设计可以帮助开发人员做到：

确保数据过滤无法被绕过，确保不合法的信息不会影响合法的信息，并且识别数据的来源。

关于如何确保数据过滤无法被绕过有各种各样的观点，而其中的两种观点比其他更加通用并可提供更高级别的保障。
(更多…)

标签Tags：html, include, mod, PHP, PHP, PHP安全, url, web, 人, 代码, 判断, 数据, 方法, 程序, 类, 网络编程, 表单, 设计, 诫, 软件, 邮件, 重定向, 错误, 验证

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

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

规则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, 中国特色, 人, 图片, 方法, 更新, 服务器构建&安全, 浏览器, 组件, 网站, 表, 解决, 设计, 重定向, 页面

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

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

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

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

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

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

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

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

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

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

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

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

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