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

http://www.skywind.me/resource/hcdsc.htm

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

Achievements and Gamerscore: Best Practices

—- By Jeff Sullivan, Developer Relations Manager, Microsoft Game Technology Group

— 翻译（参与先后）：skywind,cjx,ltt,fanlix,jericho

http://www.skywind.me/blog/archives/346

1. 成就为谁提供
2. 何时授予成就
3. 拓展玩家实践
4. 成就演示
5. 游戏演示
6. 内容回顾

Xbox 360的“玩家成就（achievements）”和“成就积分（gamerscore）”重新激起了玩家的游戏兴趣，玩家将更多的时间和精力投入到游戏中，不断尝试更高的难度设置。整个游戏行业，一夜之间涌现出各种业余的、专业的积分站点，开始讨论游戏成就，以及怎么获得更多的成就分。游戏设计者们也从中受益匪浅，有史以来第一次，他们可以分析玩家在多个游戏
中的表现。成千上万的人都在问这两个问题：“你的成就分是多少？你最喜欢的成就是什么？”

成就系统的价值和吸引力是无可否认的，关键是怎么充分利用它们来提高你的游戏品质。

Continue reading→

作 者：Sobeit Void
翻 译：skywind
原 文：http://www.gamedev.net/reference/articles/article2006.asp

内容摘要

今天我写这篇文章是因为我遇到许许多多开发者们在发布他们自己的静态/动态库的时候没有注意到以一种足够“Friendly”的风格来最大可能的减少开发时候碰到的麻烦。功能库的使用者们必须经常做出更多的无益修改，但是这些修改都是没有必要的，然而今天，这一切都将会结束！ 接下来的内容将仅针对VC++的类库做讨论，但是其中所涉及到的内容，同样适用于任何C++的编译器。

基本法则

我们从检查整合一个第三方库的所需要基本使用步凑开始，假定这个需要整合的第三方库的名字叫做“Useful”。

1. 拷贝 Useful的头文件和.lib文件到我们的机器中
2. 在我们的工程中 include这些 Useful的头文件
3. 将 Useful的.lib文件加入到连接项中
4. 如果 Useful是一个DLL，拷贝useful.dll到我们工程目录中或一个恰当位置（比如windows\system32）

如果所有的工作都顺利完成，我们的工程就可以愉快的使用 Useful了。有什么地方出错了呢？很多地方，真的。

不好的类库发布

让我们来一起检查这个典型的非常常见的类库发布包，看看我们将会碰到什么问题。 下面是 Useful 的打包发布状态：

• 头文件都位于 Useful\include。既然头文件很少有 debug/release版本，那么遵从微软的约定是很好的
• 库文件的两个版本位于Useful\lib\debug 和Useful\lib\release，他们都称为 Useful.lib。将库文件放置在 lib目录是另外一个 Microsoft的约定。
• 两个不同版本的DLL（debug/release）都称作 Useful.dll，他们位于Useful\bin\debug 和Useful\bin\release 两个目录。bin文件夹是另一个标准的目录用于编译器输出二进制结果。

现在我开始将Useful整合到我的工程中。Useful是非常 “useful”的，因为我在五个其他工程里面都使用了它。 注意：VC++中的工程配置就象和 makefile一样，实际上，它正是。

1. 我在编译器的 include search path中增加Useful\include 以便我可以直接在五个不同的工程中使用。万一我将 Useful 的目录移动到另一个地方的话（比如从c:\Useful 到d:\Useful），我仅需要更改编译器的 include 搜索路径就可以使我的五个工程毫无麻烦的找到这些头文件了，不错。

2. 对于连接类库来说，这里开始出现问题了。我想让我的 debug 代码连接 debug 版本的库文件，release 也一样。因为 debug/release 两个版本都称作 Useful.lib，我不能同事增加他们的目录到编译器的 library 搜索目录。编译器不能区分到底该连接哪个。所以唯一的解决方法就是写死c:\Useful\debug\lib 到我的 debug 工程配置中，以及c:\Useful\release\lib 到我的 release 工程配置中。

3. 不幸的是我必须移动 Useful 到一个其他的目录，看看我有多大一堆工作需要做。我不许更改我五个工程的 library 路径配置。如果你独自工作，这没有问题；如果你和以组开发者一起工作的话，看看将会发生什么。所有安装 Useful 在其他目录的（这样做并没有什么过错），当每个开发者从仓库中 checkout 代码的时候，所有工程的路径配置都必须更改。当他们 checkin 这些代码的时候，代码同步会检测到这些工程配置的修改情况，并且会对这些改动完成 checkin 操作，下一个工作者又必须在他 checkout 以后再次更改这些路径设置。听起来很好笑吧，几乎是很艰辛的。

4. 现在，同样的问题在使用DLL的时候出现了，系统再次无法检测哪个 dll 是 debug 哪个又是 release，所以我们无法将 Useful.dll 放到一个公共的路径中去。（实际上你能做到，如果你希望每次交换 debug/release 两个版本的DLL的话）所以我拷贝 Useful.dll 分别到我的 debug/release 目录中，所以系统可以找到最靠近我执行文件的那个 dll，但是这只能适用于一个项目，我需要在五个不同的工程中这么做。 现在，Useful 的开发者找到了一个主要的 BUG，发布了一个新版本的 Useful。我们就必须拷贝新的 DLL 到每个工程的输出目录。如果 Useful 发布到另外一个目录（比如c:\UsefulFixed 而不是c:\Useful），我们又必须每次为每个工程配置做一次更改。 通过这些，你可以发现这些问题将在一个项目的 Lifetime 中一直存在。类库更新了，安装目录更新了，所有的问题将会惯性的发生，我们可怜的开发者们将准备好每次应付这些问题的发生。

微软的解决方案

这里是微软如何完成他们的类库发布的，你可以在你自己的VC++目录中得到验证：

• 头文件被放置到Useful\include 文件夹，include 名称只是一个约定，不一定要遵守。
• 库文件被放置到Useful\lib。Debug 版本需要在名称后加一个 “_d”，所以我们在c:\Useful\lib 中分别得到Useful_d.lib 和Useful.lib 两个文件。

注意，该方法解决了连接问题。在我们的代码中你可以这样连接 Useful库：

#ifdef _DEBUG#pragma comment( lib, “Useful_d” )#else#pragma comment( lib, “Useful” )#endif

然后我们可以增加c:\Useful\lib 到我们编译器的 library 搜索目录。

Debug 版本的 DLL 同样增加一个 “_d”，我们得到 Useful_d.dll 和 Useful.dll 这两个都可以同时被放入一个普通的文件夹，尽管微软经常放到windows\system32 目录中去。这并不是一个很好的做法，除非是系统 DLL。作为开发，你不必这样做，因为开发者通常需要最安装新版本的 DLL。作为一个每天都使用他的用户，这将导致版本冲突最终导致 “DLL HELL”。

需要牢记的是，如果你需要发布一个应用程序，那么将你所需要的 DLL 放到你的本地文件夹里面。你可以使用一个叫做 “Dependency Walker” 的工具看看你需要哪些DLL。

最终结论

以上的更改对于一个类库的编译过程是很简单的同时不会影响到类库的开发。总之，给你的发布包一点微小的改变，你可以节约成千上万使用你类库的人的时间。