分类：技术

技术

游戏开发中的多语言文本管理

好久没写博客了，今天趁着还在排魔兽副本的功夫上来写一篇！

由于之前没有经验，这个项目在做的时候，在多语言文本管理这方面做得很差，到了后期字符串基本成了一个无法管理的状态，随便要改点什么字都需要在一个存了所有游戏文本的5000多行的巨大txt中搜索，极其不便；而且有相当多的字符串是已经在游戏中删除掉的废字符串，但却依然停留在文本文档中。所以我想要总结一下经验，参考一些其他游戏的做法，看看能否用更好的方式来解决这个问题。

首先第一个要解决的问题是，如何让程序自动对应不同版本的语言？在设计界面的时候一定要方方面面都把这个考虑进去，否则一定会出问题，比如显示中文刚刚好，显示英文却太长了。不过这不是本文的重点，更多的相关内容可以看这篇文章。我们需要用ID来管理所有文本，比如说我们有个英雄，英雄的ID是100，他的说明文字就可能是hero_100_description之类的。ID的这种命名方式对于程序来说没有意义，不管是hero_100_description还是GameStringS1293IU634EASD，对于程序都可以正常运行，但采用后者会让字符串的可读性相当差，因此最好由策划来手动为所有需要用到的文本ID进行命名——就像美术人员会为所有美术资产命名一样。这种命名的好处还能让你轻易地剔除掉已经不再使用的废字符串。

ID可以按照统一的模块来起名（横向的），也可以按照实际的程序结构来起名（纵向的），个人建议采用后者的方式。假如按照前者的话，我们有可能将所有的UI使用到的文字都写作一样的内容，比如都叫UI_Title_XXX，但实际上游戏并不需要同时加载所有UI的文本，每个界面要用到的都很有限，因此按照程序结构来划分会更科学一些，这需要与游戏程序一同进行设计。不过由于纯文本文件往往都很小，不像美术资产一样会占用大量内存，因此在确保没问题的情况下偷懒一下，在任何地方都加载所有文本也可能可以，这还是需要看程序方面的意见。

ID的名字在允许的情况下，为了可读性，可以起的尽量的长，这需要与程序一同设计。比如，UI_MainMenu_NewGameButton_Normal，就说明了这个文字是用于显示UI的，是在主菜单用到的，是“新游戏”按钮在默认情况下的文字，这种清晰易懂的名字无论是程序在代码中还是策划在文本管理中都会让工作轻松得多。

如果需要制作新内容的时候，策划可以先添加所有需要的文本及其ID，再让程序制作，流程上也会更顺畅一些。如果某个字符串没有填写，则直接在游戏中显示其ID，这样能在游戏中轻易地发现是哪个字符串忘写了。

当某些东西的结构固定时，甚至可以统一、批量地先由程序生成ID，再有策划进行填写——比如英雄有100个，每个英雄都有描述，程序就可以先把hero_001_description到hero_100_description直接做到游戏中——《星际争霸2》就是这么干的。

如果字符串需要换行，建议使用在单个string中加入诸如n的方法，而不是使用多个string，因为同一句话不同语言显示出来行数往往不一样，如果用多个string的话ID管理会变得相当混乱，很可能中文一共有5000个ID而英文却有5010个ID，具体多了哪10个就是个要命的事情。文本的样式管理应该和程序、美术一同进行设计，尽量把文本的样式也写进string中再由程序解析，比如：

<string><c value = “FF0000”>我是一个红色的文本</c></string>
<string><c value = “FF0000”>我是一个红色加粗的文本</c></string>
<string><size = 24><c value = “FF0000”>我是一个红色加粗的24磅的文本</c></size></string>

这样做法的好处是在保留一定可读性的前提下，修改文本样式不再需要程序的协助，能够大大降低开发过程中的沟通成本。实际上这也是《星际争霸2》的做法。

不过笔者认为，《星际争霸2》也有不值得学习的地方，就是其不同语言文本的文件结构。由于该游戏支持相当多的语言，因此他们的做法是把不同的语言文本完全分离在不同的文件中，比如中文文本都存在zhCN中，英文文本都存在enUS中等等，这样的问题就是在两个文件中，我们都要以“ID+String”的方式进行管理，无法确保ID的唯一性。因此相比之下我更倾向于《魔兽世界》插件或者《炉石传说》的结构，将不同语言的文本全都放在同一个文件中，这对于策划以及游戏翻译外包来说是都是相当舒服的事情，下面是例子：

《魔兽世界》插件的多语言（以Decursive为例子）：

## Title: Decursive |cffff00ff -Ace3-|r
## Notes: Afflictions display and cleaning for solo, group and raid with advanced filtering and priority system.
## Notes-frFR: Affichage et guérison des affections avec un système évolué de filtrage et de priorité.
## Notes-deDE: Anzeige und Reinigung von Gebrechen für Solo, Gruppe und Schlachtzug mit erweitertem Filter- und Prioritäten-System.
## Notes-esES: Afflictions display and cleaning for solo, group and raid with advanced filtering and priority system.
## Notes-esMX: Afflictions display and cleaning for solo, group and raid with advanced filtering and priority system.
## Notes-koKR: 쏠로, 파티, 공격대를 위한 고급화된 필터링과 시스템 우선권으로 고통들의 표시와 제거를 합니다.
## Notes-ruRU: Отображение и инструменты для развеивания дебаффов для одиночной игры, игры в группе и рейде, с развитой системой фильтрации и приоритетов.
## Notes-zhCN: 当单独、小队和团队时清除有害状态，并可使用高级过滤和优先等级系统。
## Notes-zhTW: 當單獨、小隊和團隊時清除有害狀態，並可使用高級過濾和優先等級系統。
## Notes-ptBR: Afflictions display and cleaning for solo, group and raid with advanced filtering and priority system.
## Notes-itIT: Afflictions display and cleaning for solo, group and raid with advanced filtering and priority system.

炉石传说的例子：

<Tag name=”FlavorText” enumID=”351″ type=”String”>
<enUS>Hogger is super powerful. If you kill him, it’s because he let you.</enUS>
<zhTW>霍格非常強。如果你殺死他，那是因為他讓你殺他。</zhTW>
<zhCN>霍格可是超级厉害的。如果你杀了他，只是因为他让你这么做的。</zhCN>
<ruRU>Дробитель ужасно сильный. Если вы убьете его, то это значит, что он вам поддался.</ruRU>
<ptBR>Hogger é superpoderoso. Se conseguir matá-lo, foi porque ele deixou.</ptBR>
<plPL>Wyżer jest supermocny. Jeśli go zabijesz, to tylko dlatego, że ci na to pozwolił.</plPL>
<koKR>들창코는 정말 강력합니다. 만약 처치했다면, 그가 봐줬기 때문입니다.</koKR>
<itIT>Boccalarga è potentissimo. Se lo uccidi è solo perché lui te lo ha permesso.</itIT>
<frFR>Lardeur est super fort. Si vous réussissez à le tuer, c’est uniquement parce qu’il vous aura laissé faire.</frFR>
<esMX>Hogger es muy poderoso. Si lo matas, es porque él así lo quiso.</esMX>
<esES>Hogger ya se ha cobrado más víctimas que el Cataclismo.</esES>
<deDE>Hogger ist so mächtig, dass Ihr ihn nur töten könnt, wenn er Euch lässt.</deDE>
</Tag>

不过这种做法也有一个难题，就是如果新加一个语种的话会影响到之前的所有结构，所以无论采取哪种结构，最好都有文本管理工具，而不是直接手写txt。但比起传统而常见的每个语言一个文件其中把所有系统需要的文本都丢进去，我更倾向于按照系统划分文本文件，然后把所有语言的丢进同一个文本中。当然了，这还是要看程序是如何设计的，以及游戏的过程中是否支持切换语言。

如果你有更好的做法，欢迎和我交流经验，我的博客地址是www.maniahero.com！

标签多语言, 字符串管理, 文本管理, 游戏开发

琐事技术

redbooth：让一切变得井井有条

最近我在使用redbooth来管理工作进度，这是一个非常好用的项目管理软件，基于网页，只有英文版，其官方网站是https://redbooth.com。

由于我经常会迷迷糊糊地记不得自己该干嘛，因此这个网站的帮助很大。

redbooth是以组织和项目驱动的。组织就像是一伙一起玩游戏的玩家组成的一个队伍，项目就是这群玩家们要去攻克的副本。用户可以在项目中创建任务并发布给每个成员，成员们可以在项目中添加文本记录或上传文件，还可以在项目中进行对话，对于小型团队来说该有的功能已经都有了，最重要的是其简单易懂，不像很多国产的高大上项目管理软件一样满页都是让人看不懂的装有名词，特别亲民，只要三五分钟就能学会怎么用。

用户可以直接分享项目内的文本，邀请其他用户加入，可是免费版一个项目最多只能有5个成员，但这对于小型团队来说也足够用了。

每天redbooth还能根据你的设定向你的邮箱中发送尚未完成的任务列表，每个任务还能创建子任务——这样就能把一个大任务拆分成多个小任务，用户还可以按照多种方法排序、检索任务，还能够查阅甘特图。当一个任务乃至一个工程完成后，玩家还可以将其打包封档，以供日后查阅。

虽然只有英文版，但由于界面清晰友好，上手难度还算不高，而且国内访问速度也很快，redbooth还可以绑定dropbox、google的账户，这更使其如虎添翼。

对于任何团队，尤其是经验不足的新手团队来说，项目管理都是重中之重的，有了redbooth的帮助更容易把成员凝聚起来，一起推动项目木向前走。

标签 redbooth

技术游戏设计

视频游戏的时空设计

国庆放完假后工作了一周，这一周比较忙，今天放假了，所以有了较长的时间可以用于写作，再加上昨晚在去吃夜宵的路上讨论了一些话题，让我想要今天完成此文，很多内容也都是长久以来的积累，总结一下，谈谈我个人的理解。

在设计一款视频游戏时，游戏世界的时间尺度与空间尺度的设计是非常非常重要的，但我觉得很多游戏设计师并没有对这方面有着足够的重视。时间尺度和空间尺度是玩家理解游戏世界的最重要的方法，当我们需要从零开始设计一款游戏的时候，游戏世界的时间性和空间性是所有设计的基础，是所有其他机制运行的基石，甚至称其为游戏系统设计的原点也不为过。

好了，让我们从简单到复杂，开始看一下都有着什么样的设计吧！

几乎没有空间性+回合制时间性的游戏

虽然大部分的视频游戏都有着一定的空间规则，但并不是所有游戏都是如此。我们就从一个完全没有空间概念的游戏来开始探索游戏世界的空间设计吧。

我们来想象一下《万智牌》的种种区域——手牌区，坟场，战场等等。这些区域的位置并没有明确的规定，仅仅是一个概念。当战场上有数个生物的时候，这些生物是没有位置的区别的——游戏规则中并没有表明哪个生物站在前面，哪个生物站在后面，哪个生物大，哪个生物小，哪个生物的移动速度快，哪个生物的移动速度慢——实际上由于《万智牌》战场上的生物们完全没有空间性的设计，因此其实也是没有“移动”概念的。

《万智牌》只有牌库和坟场中的牌有顺序的概念，因而只有这两个区域是一维的空间，其他区域都是没有空间性的。

与之类似的是《仙剑奇侠传》或者《石器时代》这种回合制战斗游戏，双方的单位各站成一列，互相攻击，彼此的位置没有区别，而且同样的也没有“移动”、“射程”等其他依附于空间设计的概念。不过在以《石器时代》与《仙剑奇侠传》为代表的回合制游戏中，空间性到了稍微的加强，以《石器时代》为例，在10v10的战斗中，双方的10个人分成了前后5人的两排，这样就有了“行”和“列”的概念，比如回旋镖能够横着攻击所有一排上的敌方单位，而贯穿攻击能够攻击同处一列的前后排上的两个敌方单位，这样一来“射程”的概念就不再仅仅限于“单体”与“全体”了，而是借用了平面空间的规则，这是很大的进步。

可是在《石器时代》的战斗系统中依然没有“移动”的概念，双方2×5的区域是相互独立的，不相连接，而且由于每个玩家和自己的宠物都是宠前人后地站成一列，因而在战斗中玩家的位置依然是没有意义的。

中低密度二维空间+回合/即时制的游戏

走格子的二维空间回合制游戏（不管是格子是四边形的还是六边形的）几乎囊括了所有的战棋视频游戏（或者说是策略游戏），以及所有的传统棋类游戏与war game，从《英雄无敌》到《火焰纹章》，从《象棋》到《跳棋》，从《战争艺术》到《文明》。由于相当普遍，因此我就不再赘述这种游戏了。这类游戏也能给玩家带来非常强的策略性沉浸感，但往往由于游戏世界空间上的扩张，游戏规则更为复杂，游戏规则基本都是白盒的，玩家需要掌握所有规则后才能玩好游戏，因而教程繁琐，UI复杂，上手难度较高。几乎总是这样——越抽象的游戏学习成本越高，游戏规则越趋向于白盒。

低密度二维空间游戏就不再只是回合制的了，有些游戏也开始采用即时制，比如《俄罗斯方块》。

这是因为计算机运算的速度相当之快，每秒成吨的计算次数相当于几万几亿个回合（相比之下《石器时代》一回合居然长达30秒），因而对于我们人类玩家来说感觉上就成了即时的。从这个意义上来说，回合制游戏也可以叫做“低密度一维时间性游戏”，即时制游戏也可以叫做“高密度一维时间性游戏”。不过这个叫法太绕嘴，相当掉书袋，而且业内已经有了普遍的叫法，所以注定只能是我个人的叫法（笑）。

除了《俄罗斯方块》以外，《太空侵略者》也是一个很好的例子，这游戏的时空规则非常奇怪，值得我们研究。

在《太空侵略者》中，敌人的排列明显是一个矩阵，也就是说是按照格子对齐的。然而，敌人和玩家化身的横向移动却是相当高密度的，并没有对齐到格子上。玩家的子弹和敌人的子弹在竖直方向上的飞行也是高密度的，然而敌人在竖直方向上的移动却是低密度的——每次敌人矩阵接触到屏幕边缘后，就突然下降整整一列，从一行上跳到下一行上。因而敌人的移动规则是不统一的，他们在横向移动上是高密度的，而在纵向移动上是低密度的。这一点相当值得注意，因而《太空侵略者》可以说是依然保留了很多传统低密度二维空间设计思路的即时游戏，我们不妨把它叫做“中密度二维空间游戏”，因为它明显地保留了从低密度空间性向高密度空间性过度时的不同特征。

除了《太空侵略者》以外，《打砖块》、《火箭车》等游戏也明显的保留有低密度空间与高密度空间相混合的痕迹。还有绝大多数的塔防游戏，也属此列，这是由于他们脱胎自RTS，而RTS的建筑建造大多是对齐至网格的低密度空间。

还有着另外一些游戏是值得注意的，比如《魔兽争霸》、《命令与征服》等早期RTS，以及《热血传奇》等早期网游。这些游戏值得注意的并不是空间性的变化，而是他们与《俄罗斯方块》一样，都是即时制的低密度空间性游戏。这些游戏让我们知道了即时的低密度二维空间游戏是完全有可能做成大型游戏甚至于网游的。

我们可以说自从视频游戏出现后，高密度的二维空间游戏就产生了（不信你想想1958年的《双人网球》，就是一款即时的高密度二维空间游戏），这也是得益于计算机成吨的运算速度，既然高速运算可以让时间尺度上密度高到人类无法察觉的程度，空间方面自然也是一样。

http://player.youku.com/player.php/sid/XMjQwMTgwODU2/v.swf

另类的奇葩：低密度三维空间游戏

这里我指的是三维空间的《俄罗斯方块》，虽然是三维游戏了，但却依然是低密度的。独立塔防游戏《White Laboratory》也有着这方面的倾向，这是因为所有传统塔防游戏都是即时的中密度二维空间游戏，而该游戏把建造塔防从传统的填格子进化成了搭积木。当然，UI上需要进行全面的革新以使得GUI能够为这种交互提供足够的支持。

低密度三维空间游戏还是有很大的创新空间的，我如此坚信着。

高密度二维/三维空间+即时游戏

有一些桌面战术游戏是需要用尺子来衡量距离的高密度二维空间回合游戏，这相当相当少见。也许《地牢围攻》可以在这种游戏中写上一笔。

高密度的2D/3D即时游戏很常见，绝大多数的动作游戏和射击游戏都是属于此范畴的，因此也不再赘述。虽然画面越来越逼真，空间的密度越来越大，然而某些设计规则还是通用的。想象一下《口袋妖怪》，当你在村子中走动的时候，一个房子只有3×4那么大，而当你进入房间之后却发现室内变成了6×8那么大的。想象一下《帝国时代》或者《魔兽争霸》中，一个炮塔的大小和一个步兵的大小差不多大。是的，很多设计都是失真的，然而玩起来不会觉得奇怪，这正是在设计游戏空间的时候的奇妙之处，因为我们设计游戏是为了提供玩家体验的，为此可以在相当程度上牺牲写实程度，只要能够使玩家获得更好的游戏体验。而如今很多游戏开发者迷失在了画面的写实与美丽中，忽视了游戏本身的可玩性以及UI交互的主要作用。

附：一些时空设计很特殊的游戏

《德军总部3D》：高密度二维空间的即时游戏，第一人称射击游戏的鼻祖。
《地牢围攻2》：高密度2.5D空间的即时游戏，但却可以暂停，因而在时间尺度上的设计极为独特。
《太空侵略者》：空间规则不统一的即时游戏，被我叫做“中密度”。

标签空间, 时间, 游戏世界