Ryzom其实很容易汉化,因为它先天就支持Unicode编码,并且在资源设计上也充分考虑到本地化的需求。
现在简单来说明一下怎么让Ryzom的内容(包括界面、输入、服务器数据)支持中文。

中文Ryzom的一次尝试
客户端中文支持
中文支持分为客户端和服务器两个方向,首先来说说客户端,客户端编译后的结果目录内容一般如下所示(详见在Win32上的编译教程),其中bin下的资源文件直接解压自官方提供的ryzom_client_open.7z文件,而exe和相关dll文件则可以是自己编译的结果。

首先,用记事本打开client_default.cfg,找到:
LanguageCode = "en"; // english
改为:
LanguageCode = "cn"; // chinese
这样,客户端启动后界面文字会自动取自相关的中文配置文件,而也会通知服务器使用中文内容。当然如果服务器还没有增加汉化文件时,很多对话框、标签里面的文字将会是无效的默认文本。
那么客户端中文界面配置文件在何处呢?打开你客户端的data目录,下面有个gamedev.bnp文件是不是,所有界面语言文件就在这个文件里面。使用bnp_make_r.exe工具可以解开这个文件(编译成功后该工具应该在code\nel\tools\misc\bnp_make目录下找到)。解开后会生成一个gamedev文件夹,里面有个en.uxt,复制它为cn.uxt,然后用记事本打开,里面每一项的值就表示各种界面的文字内容,也正是你需要翻译的东西,放心的翻译它吧,这个文件是unicode编码的。翻译好后,再用bnp_make工具对gamedev目录打包即可。当然,只要你愿意,你可以保留gamedev这个目录,因为客户端是优先读取磁盘文件的。
接着就是中文字体的问题,data\fonts目录下的字体默认是没有支持中文的(如果你打中文,会变成....),本来可以在gamedev的配置中设置字体,但我采用了更简便的办法,直接覆盖ryzom.ttf,比如上面的截屏就使用了微软雅黑字体文件来替换ryzom.ttf。
关于聊天框的中文输入,这个我没有测试过,但据群里的人说,字体这些都配置好了后,自然中文输入也就没有问题了。

群里的截图
到此为止,客户端的汉化支持工作就算完成。
服务器中文支持
如果你运行自己编译出来的服务器,找到ryzom\server\data_shard\language目录,下面即是服务器上各内容的语言文件。针对所有的_en.txt文件复制相应的_cn.txt文件,例如把faction_words_en.txt复制一份为faction_words_cn.txt,翻译里面的相关内容即可。注意里面有些列不能修改,例如name列,这是作为语言关键字查询的。
现在,在客户端通过修改client_default.cfg中的语言类型就能自由地在英语和中文之间切换啦!
by xpeng
在Windows上编译运行Ryzom客户端
英文链接:http://dev.ryzom.com/wiki/ryzom/RunClientOnWindows
假设你已经编译好了你自己的客户端(关于在Windows上编译服务器和客户端请参考:http://ryzomcn.5d6d.com/thread-19-1-1.html)。
客户端数据
代码库是不包含诸如纹理、3d模型这些客户端数据的,因此你需要下载它们:https://sourceforge.net/projects/ryzom/files/ryzom_client_open.7z/download
解压到一个目录中,例如c:\ryzom_client
这里面的客户端可以直接连接官方开源测试服务器,如果是你自己编译的客户端,你需要把代码路径code\ryzom\bin下的如下文件拷贝到这个目录中覆盖相同文件即可:
client_ryzom_r.exe
nel_drv_direct3d_win_r.dll
nel_drv_dsound_win_r.dll
nel_drv_fmod_win_r.dll
nel_drv_xaudio2_win_r.dll
连接服务器
默认情况下客户端是连接到open.ryzom.com:40916的,你需要在client.cfg中增加(或者修改)下面一行来连接到你自己的服务器:
StartupHost = "你的地址:40916";
客户端错误信息
如果出现连接错误,请参考http://dev.ryzom.com/wiki/ryzom/ClientConnectErrors解决问题。
|
Version 0.8.0,计划是2010年7月到期
|
本文档来自http://ryzomcn.5d6d.com/thread-8-1-1.html,和英文版http://dev.ryzom.com/projects/ryzom/roadmap保持同步
. 严格来说,官方现在有两个大型的项目在并行进行,一个是Nel引擎,一个就是Ryzom Core项目。这里重点明确一下这两个官方项目的目的和情况,以避免开发者和翻译人员常见的误区。
Nel引擎(http://dev.ryzom.com/wiki/nel)是一个独立的完整的多人在线虚拟系统解决方案,包含了从3D引擎到网络客户端、网络服务器的所有技术组件,一般在项目代码根目录中的nel、nelns、snowballs2、tool子目录是属于Nel的。其中snowballs2基本上是一个完整应用nel相关技术的MMODemo,研究nel可以从这个游戏demo入手。
Ryzom Core(http://dev.ryzom.com/)则是和Ryzom游戏相关的一个大型项目,请注意项目的名称是“Ryzom Core”而不是“Ryzom”,很多人认为既然Ryzom开源了就是官方Ryzom游戏所有的内容都公开,其实是不准确的。Ryzom的开源包含了开发出官方商业Ryzom游戏的基础代码(即Ryzom Core),还包含了开发商业Ryzom游戏使用的大部分资源(Asset),他并不包含现在官服上面的一些实际内容,比如任务内容、用户/账户数据库(这个都公开了还得了!)等等,但这对开源世界来说足够了。
因此研究Ryzom Core的主要目的并不是把Ryzom游戏改成什么样子,或者翻译成某种语言来运营(当然这是有些组织或者公司的事情),而是领悟它的技术、利用它的技术并融合进自己的技术来开发崭新的虚拟游戏系统。
基于这个原则,世界范围内已经出现了很多Ryzom相关的开源项目,我这里列举出sourceforge和google code上面的一些项目仅供参考,目的是在大家扩展Ryzom Core的时候不要重复造车。当然,也欢迎大家回帖补充其他的开源项目。
Dungeon Walker(http://sourceforge.net/projects/dungeonwalker/)是一个基于Ryzom Core的游戏Demo,刚刚开始没有多久。
Rally(http://sourceforge.net/projects/rally/ )是一个用Python写的安装程序,用于简化Ryzom的安装,比较早的项目,基本上已经停止更新了。
Atysian Translator(http://sourceforge.net/projects/atystranslator/)这个早期项目有点意思,是一个帮助翻译Atys四大种族自己语言的工具。
CEB(http://code.google.com/p/cebmtpchat/)是一个跨平台的聊天工具,支持Ryzom的聊天服务器,使用Qt开发。
object-viewer-qt(http://code.google.com/p/object-viewer-qt/)则是目前一个活跃度相当高的项目,它是Nel Object Viewer工具使用Qt4重写的版本,增加很多新的功能,并且当然是跨平台的。
georges-editor-qt(http://code.google.com/p/georges-editor-qt/)是对旧Georges Editor项目的Qt4重写版本,也是一个Ryzom Core的重要工具,使用Qt后界面就很漂亮了。
. Ryzom的开源着实让我震惊和激动了一把!
Ryzom Core项目现在基于GPL协议,开放了包括客户端、服务器全部源代码、编辑器全部源代码、游戏数据、美术资源等等,这是2009年到2010年开源社区的一件大事情,也是自由软件基金会最近很高优先级的项目。本来一直找不到好平台来做研究的CH系统(见CH大事记系列文章),现在又可以以Ryzom Core为基础得到一次巨大的发展机会,看来之后一段时间里我的生活又将是非常有趣的。另外一方面,Tao Project的梦想看来又找到了更多的支持和基础设施,毕竟站在巨人的肩上能看得更远,更避免了不断闭门造车!
在国内还找不到一个讨论Ryzom游戏设计的及其Nel引擎的地方(有一个QQ群,群号是69537392),我发现在中文社区其实有很多可以贡献的力量,不排除Ryzom发展出中文版的可能性,我也申请了一个专门研究RyzomCore的论坛(即Ryzom中
文开发论坛)来寻求众多的爱好者和开源游戏的拥护者一起构建该领域的中文社区氛围。
多说一点Ryzom开源这件事情,其实它是很有意义的。经历多年的自由软件运动之后,我们在操作系统、数据库、计算机网络、应用服务器等各个技术领域都取得了丰硕的成果。不过在计算机游戏领域,还没有什么大的进展。现在流行的MMORPG游戏Ryzom则为我们提供了一个宝贵的机会,我也希望我们能跟进国外的领先技术,第一时间将欧美最新的MMO游戏技术引入中国游戏社区,推动国内技术的发展。
现在流行的大型网络游戏都是由专有软件公司开发,所以网络游戏的发展也都是由专有软件公司控制,而不是用户。不过我们认为,既然用户能够参与现实社会的发展,那么也同样有权力参与网上虚拟社会的建设。玩家是游戏虚拟社会里的公民,网络游戏应该属于全体玩家,所以他们有权力和机会实现自己在虚拟社会里的梦想,这就需要有自由的网络游戏。自由软件基金会认为收购Ryzom游戏是一个高优先级的自由软件项目,所以决定资助此项目6万美金,并最终帮助筹集到20万欧元左右,能够买下Ryzom游戏,将其变成一个自由软件。Ryzom的官方网站为www.ryzom.com,现在已经有英、德、法、俄等国家的语言版本和社区,我希望也能产生中文的社区环境。
这篇文章摘自“免费打工仔”在www.gameres.com上的发言,虽然字数不多,但对几个引擎的评价却一语中的。
引擎设计与商业模式
包括我在内的很多朋友都喜欢看国外引擎的代码,并比较引擎之间的优劣。但是你会发现,每种引擎的设计都是于他开发者和用户及其相关,优秀的引擎不仅是设计上的优秀,更重要的是适应自身的商业(社区)模式。在这篇文章里我们着重讨论一下卡马克的Quake 3引擎,Epic的Unreal 3,开源界的Ogre3D图形引擎以及相应的Orz扩展框架。
一、Quake3=天才模式
在很早以前,我们只能接触这款游戏引擎的代码。可以说卡马克是中国游戏图形界的导师。我的很多前辈都是从这款引擎开始学起,并立志开发一款中国人自己的图形引擎。后面介绍的虚幻引擎和Ogre3D引擎都或多或少的被这款引擎所影响。
提起Quake3引擎就不能不了解id公司和他的天才程序员卡马克大神。约翰·卡马克被称为3D游戏之父,因为其开创性的把3D渲染运用到了实时技术中来。他是图形学界的牛顿,所有开发游戏的人的偶像之一(另外一个是宫本茂)。有一本书《Doom启示录》就是讲卡马克和他的id公司的故事。在这本书中,你会发现卡马克对于程序技术的痴迷胜过一起(甚至超过成 人录像带)。
所以Quake3以及其他id公司的图形引擎产品,(曾经)唯一的目的是开发出最棒最新的图形技术,把卡马克的天才发挥到极致。id是卡马克的公司,Quake3也是卡马克的引擎。如同乔布斯和苹果一样,任何人也无法漠视卡马克和Quake3之间的联系。
1 Quake3 极其重视效率,这样可以便于在硬件支持前实现未来的图形效果。
2 Quake3 代码短小精湛,卡马克对其不断优化。
3 Quake3 不如其他引擎注重模块化,卡马克一个人就能搞定。
4 Quake3 不需要重构,卡马克擅长在最短的时间内重写整个引擎。
5 Quake3 对使用者极其简单,但扩展很难。如果需要扩展,卡马克会重写一个引擎。
Quake3以及同系列的引擎,在游戏历史上的价值是无可厚非的。但是你会发现,如果要修改这个引擎,基本上要了解所有的代码。这些东西很紧密,如果你希望换一个图形场景管理算法,你会发现基本上要修改整个引擎。你可以很容易做出和《雷神之锤3》一样的游戏,但是很难把它修改成其他类型游戏。(你会理解当年要卡马克做RPG的时候甚至用辞职来威胁id管理层。)
国内有很多朋友企图模仿Quake3的结构来实现一款图形引擎或者游戏引擎,但大部分都失败了,另外的一部分也没有获得成功(挣扎中)。不是说Quake3引擎不好,是因为中国很难有类似的环境。Quake3的商业环境是,你需要一个靠技术来赚钱而不是靠产品的公司,另外还需要一个天才如卡马克一样的程序大师来驱动。基于这两点,可以说Quake3的成功是无法复制的。
二、Epic的Unreal 3引擎 = 商业模式
很多朋友都有Unreal 3引擎的代码,但我没有读过。我只是从一些看过Unreal 3的朋友的口中了解一些相关的信息。这些信息包括,
1 Unreal 3开发游戏,如果不是极其复杂,只需要脚本和编辑器就好了。它有极其强大的脚本和编辑器系统。(上海育碧的一些朋友说的)。
2 Unreal 3代码中有很多违反常规知识的地方,比如充斥着菱形继承(C++虚拟继承)。(一个看过代码的朋友说的)
3 Unreal 3代码写的很难看(一个开发类似Quake国产引擎的朋友说的)。
4 Unreal支持大量平台,图形效果非常好。
上面有很多条款我是没办法证实的,但是我们姑且就认为都是对的。
在《游戏人》中有一段描写Unreal诞生的故事,老板并不看好为《虚幻竞技场》重新开发一款引擎,因为已经有了一款卡马克的了。要超越卡马克的图形技术太困难了。但是他们发现自己在编辑器的功能上可以领先id公司很多。基本上从那往后的10年里,Unreal依靠这一点成为了最成功的商业引擎,在商业领域上击败了卡马克。
1 Unreal 3 具有强大的脚本和编辑器,这是为了给购买引擎的公司节约开发成本。
2 Unreal 3 有一些菱形继承和紧凑的代码。这是为了商业上的紧凑型,就算开放一部分源代码,你也需要得到另外的授权,你无法单独使用。(上面提及的朋友告诉我的)
3 Unreal 3目标是当前的,漂亮的图形效果,更多的平台支持,是最重要的。
这些因素代表了Unreal 3的成功,一些其他的商业引擎,比如GameBro也很注重编辑器,而不是更优秀代码质量。与其提供良好的结构,不如实现更多的效果。他们也都在各自的定位上获得了相应的成功。
三、Ogre3D图形引擎 = 开源模式
Ogre3D图形引擎(http://ogre3d.cn)是开源界最出名的图形引擎(没有之一),包括国内的《天龙八区》、《成吉思汗》等,以及国外的《火炬之光》商业作品都是使用这款图形引擎作为开发基础。和Ogre3D同期的开源游戏引擎,包括IrrLight等,都不如Ogre3D这般成功。
Ogre3D最重要的是从设计之初就目标开源社区,而不是商业或者技术。
Ogre3D 好的结构带来更多的功能,而反之则不能。 开源社区需要好的结构让更多的人来参与,而不需要商业引擎的工期,所以有充足的时间发展(十年甚至更多),而不争朝夕。
Ogre3D 采用插件化结构,这样做的好处是让一些社区开发者,不用了解和改变整个引擎,就能扩充其功能,同样开源的Quake3就很难达到这一点。
Ogre3D 只做图形引擎,不做其他部分。
这样做首先是利用了开源社区其他的成果,比如OIS或者CEGUI等良好的开源产品。更重要一点是因为不涉任何游戏逻辑部分,核心模块只有5M左右大小,功能性引擎之间可以组合使用,这样做可以让Ogre3D适应不同领域,不仅是游戏可以使用,在各种仿真领域都可以大展拳脚。同时期的IrrLight反而因为提供太多游戏相关的东西,虽然学期曲线较缓,但是应用领域反而被闲置了。
Ogre3D在技术细节上 实现了场景图中节点和内容分离,场景管理器因此可以作为插件使用,这是Ogre3D设计的初衷。
Ogre3D 因为运用了大量软件工程知识,导致在计算机运算比较差的环境下和其他引擎效率有一些差距。但因为开源引擎的持续性,随着硬件性能的提高,十年后的今天,这些问题已经不再存在。
Ogre3D 和其他开源产品一样,对开发者要求较高(和一些商业领域的产品比较而言),不过Ogre3D也因此吸引了众多开源开发者(黑客)的参与。
基于以上几点,Ogre3D在开源界得到了前所未有的成功,这种引擎开发模式,在商业领域反而不能成功。
四、Orz游戏开发框架 = 分布模式
Orz游戏开发框架(http://bbs.ogre3d.cn)是国内Ogre3D社区开发的游戏框架,他利用了Ogre3D拒绝开发图形之外代码的基础。提供了一系列开发工具以及对各种功能型引擎的粘合。不得不说Orz在游戏引擎中采用了一种极端取巧的办法。他把底层功能性引擎的开发交给了其他开源界的产品,专注于逻辑和接口的实现。相对于其他部分而言,这部分的代码很少会受到硬件升级的影响。所以可以用较少的精力,不断优化已有的代码。但Ogre3D社区内也同时存在诸多开发框架,包括比较出名的yake和Goof等。Orz凭什么能在这些框架中脱颖而出呢?
传统上软件开发的组织结构的基本问题是布洛克法则:“在延期的项目添加程序员只会延期更久”。普遍来讲,布洛克法则认为,随着开发人员数目的增加,项目的复杂程度和通讯成本按平方增加,而业绩仅以直线增加。在上面图中左面提供了一个传统开发合作模式的示意图,在这个结构中,因为每个程序员必须了解其他人员开发的模块接口,导致问题随开发者之间通讯路径的数目增加,而后者与开发者数目是平方关系(更准确地说,遵从公式N*(N – 1)/2,这里N是开发者的数目)。依照开源软件的经验,如果你有一个足够大的项目,需要足够多的人合作,你唯一的办法是尽量降低程序员之间的依赖性。
Orz提出一个理想的分布式开发模型。在这个模型中,我们定义了一个公共的知识库,里面定义了交互的规则(消息等信息),所有的程序员按照这里提供的约定完成自己的代码,完全没有和其他程序员的直接交互。在这种情况下,增加程序员的数量并不会导致过度增加开发者之间通讯的成本。
在一些需要确定性结果的程序中,比如科学计算程序,很难达到理想的分布式开发模型,这是因为程序员之间要紧密的配合才能得到一个肯定的结果。然而对于游戏程序而言,它的目的是带来娱乐性和未知现实的模拟,就如同生活一样,你根本不需要(也不可能)知道别人想了什么和做了什么。只要大家遵守相同的规则,那么就是一个不错的体系,甚至越不可预测的结果给人带来的惊喜和愉悦感越大。而这正是我们分布式开发所具有的,比如你写了一只狗,他写了一只猫,我们按照宠物的知识来通信,你根本不用确定它们是成为朋友还是进行战争。就算加入一个宠物猪进来,我们也能正确的和它沟通——只要他遵守规矩。
Orz的目的就是基于这种分布式开发模型而设计,这和它的梦想相一致。顶尖的黑客定义游戏规则,大家来遵守,成千上万的程序员和他们的代码来组成一个真正的虚拟世界。
Orz通过一系列工具和手段来接近这个目的,基于插件来组合程序员们的代码,提供消息系统和ID管理器来确定公共知识库。
Orz框架是一个可以完成商业产品的游戏开发框架,但却走的更远。它在保证足够运行效率的前提下,尽可能的增加结构的离散性质。所有的游戏内容都可以被定义成不同种类的实体,这些实体可以通过插件系统在运行期动态载入,它们通过“及其强大”的消息系统相互沟通协作。任何一个开发游戏实体的程序员,都不需要了解其他实体的逻辑。只要他们共同遵守一个消息体系,就可以在这个基础上进行协作。
但不得不说,这是一个没有经过证实的理想而已。是否能达到这个目标还让我们拭目以待。
综上所述,所有游戏引擎都需要放置在具体的商业环境中来评价其是否成功。你可以说Quake3写得太僵化,Unreal代码难看,Ogre3D运行速度不快,Orz只是一个东拼西凑的烂番茄。但是他们这些问题都是对他们所在领域的取舍。我认为,就如同人一样,如果排除环境而言,世界上并不存在绝对的完美。引擎也是如此,他们都是希望在各自的环境和条件下尽量完美。如果我们对这些客观的实时视而不见,那么对引擎的评价也是不公正的。
经过一段时间的重构,图形引擎和编辑器都有较大的进展,编辑器的集成度也进一步提高了。
采用了自然天气系统,这是调整到北半球经纬度和我国相近时候的场景,时间大概是早上七点左右:
这是早上6点左右:
这是凌晨3点左右:
虽然是夜晚,由于地形采用了normal map,在月光影响下的效果仍然显著,由于未加调整,过于强烈了些:
早晨的水面:
本来在水面之下也有效果,并且像God light这些效果非常漂亮,但由于不需要到水下去,因此就没有做这方面的工作了。

