作者：Andrea Magnorsky

不知道你是否知道，我是BatCat Games的创始人之一，而这句话的关键词便是“games”。实际上，我们在制作游戏时，总是会在产品和资源配置过程中添加一系列差异性，并且这种差异性不会对非游戏软件开发循环造成任何影响。

一开始，美术和动画是游戏中的关键，也就是视觉效果。从构建服务器术语来看，这便意味着：它既需要空间（用于内容创建）也需要图形卡（用于呈现视觉效果）。我们的理想解决方法便是在每个支持平台上设置一个虚拟机器，但是我们却发现没有一种虚拟软件（VirtualBox，VMWare等）能够有效地虚拟化图形卡，所以我们选择在一个非虚拟机器上运行服务器。

build system（from forexbanker）

我们的目标是在每次提交时都能建造出完整的游戏，工具等。市场中还有一系列工具能够帮助你做到这一点。举些例子来说吧：TeamCity，Jenkins，CruiseControl，Hudson等。

我们最终选择了TeamCity，因为这是我们最熟悉的一种工具，并且它也很容易操作，同时还是免费的！

我们的设置

我们的代码是基于XNA和monoGame（第三版本）。

我们有很多项目，包括游戏和引擎项目，工具，程序库以及内容生成器。这便意味着我们拥有不同的项目输出内容。就拿内容来说吧，我们对于真实的建造结果并不感兴趣，但是我们却想知道它是否完成了建造，并报告其中存在的错误（如果未完成建造的话）。

游戏和引擎项目属于一种解决方法，并拥有许多单位测试。我们需要建造的服务器不仅能够建造项目，同时还能运行项目并执行综合测试。最初我使用的是psake（游戏邦注：与PowerShell共同执行建造的工具），如果你想要的是一次点击建造的话，这便是一种很棒的方法，所以我便亲自进行了尝试，并发现设置测试组件是一个手动过程，而让psake与TeamCity进行交涉能够节省不少时间。所以我便直接通过TeamCity去运行建造，这是一个较为简单的过程，所以我必须支持这种解决方法。

如果这样做的话，设置每个步骤只需要花费我10至20分钟时间。虽然还有一些事物需要我去完善，但是最终结果是，在短时间内我将拥有全新的项目建造与报告。

这一过程中的一些缺陷：

1.我需要手动去改变任何建造类型，如此，目标测试组件便需要进行升级。

2.我们现在使用的是dropbox去传达建造内容，这是我们团队中一些成员非常喜欢的工具，因为他们能够获得一些全新的二进制文件，并需要选择何时进行升级（并不存在摩擦）。但是我更喜欢能够自动升级的工具。

结论

就像你们所看到的，服务器设置还不甚完善，还有许多需要改进的地方，但一开始便设置这些内容却是非常有帮助的。这能让我们获得一次点击建造，并基于一种有效的方法将我们的工具和产品传达给团队中的其他成员。

（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）

A build system for games

by Andrea Magnorsky

As you might or might not know, I am one of the founders of BatCat Games, the important word about that sentence is games . The fact that we make games put a series of differences into our production and deployment process that doesn’t generally affect non game software development cycles.

For a start art and animation are key in a game, so are visual effects. In build server terms, that generally means two things: It requires space(for content building) and quite probably a graphics card (for the visual effects). Our ideal solution would be to have a virtual machine per supported platform , but we found that none of the virtualization software (VirtualBox, VMWare, etc) virtualizes the graphics card reliably (if you found a way, please let me know) so we are running our server on a non virtual machine.

The objective is to build the whole game, tools, etc. at each commit. There are a series of tools available in the market at the moment that allows you to do just that. For example: TeamCity, Jenkins, CruiseControl, Hudson.. etc. There is a good comparison matrix here.

We chose TeamCity, mostly because we know it, we find it easy to use and it is free.

Our setup

Our code is based around XNA and monoGame (recently on version 3).

We have many projects: a game and engine project, a tool, a library and the content builder. This means we have a diverse project output. For example, in the case of the content, we are not interested in the actual build results (yet) however we are interested in knowing that it did build, and to report errors if it didn’t.

The game and engine project reside in one solution and have many unit tests. We need the build server to not only build the project and after that run the unit and integration tests. Initially I set this up using psake (a tool that does the build with PowerShell) this is a great solution if you want to have a one click build, so I gave it a try, I found that setting up the tests assemblies was a manual process and that to get psake to talk to TeamCity nicely it would take more time that I had. So I tried running the build directly from TeamCity, and it was easier and I didn’t loose to much flexibility so, I had to go for that solution (however is a decision I will revisit shortly).

Setting up each of the steps took me approximately 10~20 minutes if done this way. There are a few things that I want to improve on, however the end result is that in a very short time I can have a new project building and reporting.

Some of the disadvantages of the process as it is are:

1.If I want to change the build type I need to do it manually, in this case, the target test assemblies will need to be updated

2.At the moment we are using dropbox as our way to distribute the builds, it is a process some members of our team really like because they just get the new binaries and they can choose when to update (so that there is no friction). I would prefer if the tools would just auto-update, but this is working for the moment.

Summary

As you can see the server setup is not perfect, there is loads to improve on, but setting this up from early on has proven very helpful. It allows us to have a one click build and a functional way to deliver our tools and product to the people in our team.(source:gamasutra)