Flex 和 Ogre

最近和赖爷聊了聊，于是决定看看网页游戏方面的资料。在赖爷的强烈推荐下，开始了我的Flash之旅。不过这其中的过程倒不是太顺利。因为我向来没有接触过网页游戏的开发领域，一开始仅仅会安装apache，放一个index页面上去，写一个“Hello World！”的页面。这已经让我狂喜不已。实际上这实在是有点可悲的，虽然早有研究一下的兴趣，可惜却只停留在高中阶段的认识。

 

记得那时会用FrontPage编辑静态网页，并和同学一起放到了免费的个人空间上面（好像是163的）。我已经不记得文件具体是如何上传的了，可能那段操作也是参考着资料而却完全不了解具体的含义。那个时候的天空总是很蓝，人也如此单纯……跑题了。

 

听了赖爷的“忽悠”，于是便答应他去帮他做一些接口封装上的事情。虽然我对此一无所知，但是我相信这是正确的事情。

 

Flex

 

我实在没有能力解释清楚Flex、Flash、AS之间的关系，因为我学东西一直都是先了解我最关心的内容开始的。不过一开始走了一些弯路，如果能够早些听赖爷的劝告或许能更快一些找到方向。最后我还是找了一本关于Flex3的电子书来看：《ActionScript3 CookBook 中文版》。凭着直觉很快就了解到想要了解的东西：一、如何显示一张图片；二、如何建立网络连接。

 

显示一张图片是所有图形库的最基础的功能，任何2D游戏引擎最基础的问题就是如何把图片显示出来（我说的图片一般都是Bitmap的位图文件，而不是指Flash中的矢量图形）。Flex提供的方式是使用一个Sprite类来让使用者控制。使用者可以任意设置Sprite的图片、位置等视觉上的属性，同时也可以继承Sprite类，来给它加入游戏的逻辑：比如跑、跳。

 

关于建立网络连接，倒是让我感叹了一下。非常简洁的代码：socket.connect(ip, port)，丝毫没有拖泥带水的感觉，就如同我写了非常久的C++代码之后，第一眼看到Python的“class ClassName(): def func(): print 'Hello World!'”的那时候的震撼感觉。但是，Python的很多模块都保留了C++时候的接口设计，特别是一些有历史渊源的扩展模块，可能为了移植方便或者保持习惯等方面的原因。比如Python的默认的socket的接口和C++几乎一样。

 

我认为脚本语言的趋势应该是让使用者写最少的代码、隐藏更多的细节，同时充分的考虑到了扩展性。这样对于一个刚刚入门的人来说，可以尽量降低他们的门槛，并且能更好的实现项目的快速原型开发。就好比C#，一切都是托管的。

 

目前我暂时还没有去实践Flex，但我觉得Flex是个不错的适合快速开发的语言，最好能不局限于Web开发。

 

关于网页游戏市场

 

早一两年前非常流行策略类游戏，而题材大多集中在武侠、三国上面。特别是在热血三国成功后，一夜之间出来无数的三国web游戏，然后大家一起死翘翘……呵呵，实际上他们其中一些比较有特色的产品，活的还是挺滋润的。这类策略类的游戏有个天生的弊病：老的服务器在游戏的分化的过程中会导致其中某一群玩家（可能是一个公会或者联盟）的势力变的无比强大，压制了其他玩家群体的发展，然后导致玩家的流失。而在这一群玩家称霸了服务器之后，因为没有了“绿叶”所以也开始流失。

 

还有一类比较受欢迎的类型，这类比较类似互联网发展初期的MUD。这是一种含有比较多的RPG游戏元素的玩法，也是符合长期发展的一个模式。玩家可以像RPG一样练功升级、体验游戏世界观、养成游戏角色。而且它又不需要像RPG那样一直操作，仅需要点鼠标。比较适合没有太多精力去练级，又喜欢体验和探索的玩家。

 

最近炒的比较火热的是SNS平台的应用开发。一般都是由互联网SNS网站提供用户数据接口，开发者个人或者小团队开发Flash游戏整合入SNS平台。国内比较火热的有人人网、校内网（也属于人人网）、开心网（开心001，不是人人网的开心网）、51社区，QQ社区也属于这类SNS，但是目前不提供开放平台。目前成功的案例就是开心农场，在多个平台上都有模仿并半成功的作品。这也是我比较看好的一个方向。

 

Ogre

 

我在读大学的时候就已经听说过这个开源引擎，不过当时并没有仔细研究。工作后，慢慢通过学习和实践有了自己的一些想法，了解了3D引擎的一些设计思想，并且自己做了一些尝试。可惜那个时候没有更多的了解Ogre，直到真正去了解的时候才发现原来Ogre的很多设计理念和我的想法不谋而合。（虽然我并不是很喜欢完全的OO风格代码，因为完全C++的OO风格让人觉得比较繁琐并且不易修改）

 

关于Ogre，请访问http://www.ogre3d.cn获取中文资料。网上的教程也很多，不过比较详细的是一份《PRO OGRE 3D PROGRAMMING》的中文版资料。里面讲述了Ogre引擎的许多方面，也有教程和示例代码。如果你想要真正用来开发项目，那还需要一份Ogre API手册，这个在官方网站上可以下载的到。我现在用的是Python-Ogre，用脚本来写Ogre程序，感觉网上有足够的教程，获取起来也非常方便。（有机会我会专门介绍下这个环境的搭建）

 

Ogre有一个设计思想是：总是同时提供了“自动挡”和“手动挡”供使用者选择。所谓的“自动挡”指的是，当你不像去涉及到具体的编码细节的时候，你可以用一些Ogre默认的方式。比如Ogre提供了默认的显示配置对话框，当你的程序运行的时候，可以通过一个函数开启这个对话框，它会自动的记录配置到一个cfg文件，并且设置好硬件和窗口的初始状态。而如果你希望用手动挡的时候，你也可以通过接口来设置配置文件中的一些属性之后再启动硬件和窗口的初始化。这种同时具备多层次接口的方式，提高了原型开发的速度，也提高了新手学习的难度。

 

Ogre的材质系统让我印象非常深刻，它实现了一套类似DirectX的effect的机制，甚至功能更强！它提供了一种比较清爽干净的模式（不是卫生巾）：模型不用同时附带贴图信息和渲染方式信息，而只需要带材质信息；材质可以由专门的材质编辑器去编辑和管理，（可惜Ogre并未提供材质编辑器）。这点非常类似于现代的游戏机游戏上的方式：场景中有大量的材质，所有材质由材质编辑器编辑和管理，并提供给模型编辑器和场景编辑器去使用。而放到团队工作中则更具好处，大部分程序员不用太关心贴图和effect文件的管理细节，这些事情都交给了美术人员和专门编写着色器程序的一个程序员用材质编辑器搞定了。

 

MMO客户端构架

 

 

一开始我很纠结于游戏的整体框架，之前在公司的内部交流中有人介绍了一种叫做MVC的开源框架。这种模式提出把程序主模块拆分为“数据-逻辑-界面”，我本来希望这个框架能够应用在游戏的开发中，但是在经过和主讲人的讨论之后，我放弃了这个想法。原因是游戏场景模块和游戏界面模块有很大的不同，对于某些游戏逻辑来说，可能会和游戏场景模块非常频繁的交互，导致这两部分的模块相关性太大，以至于不适合做拆分。而MVC模式适合应用于一般应用软件的其中一个重要的原因是界面和逻辑模块相关度并不大，甚至大部分的情况下，和数据模块的相关性也不大，所有的刷新界面的操作都可以用有限的几个或者几十个消息定义出来。不过，我并没有说过不适合用在游戏界面上。在之后的交流中主讲人也比较同意我的这个说法。

 

于是我在考虑：

 

1 游戏场景模块是否应该属于一个给上层逻辑提供图形支持的模块，而并非是核心模块之一，虽然代码量可能很大。

2 游戏的核心交互模块为“游戏高层逻辑-游戏数据库-界面”，而把他们结合在一起的则是MVC模式。

3 游戏逻辑可以分成底层逻辑和高层逻辑，底层逻辑是各种管理器，比如NPC管理器、角色管理器等。搞成逻辑则是直接处理网络消息，玩法相关的逻辑，比如工会系统、主界面逻辑等。

 

恩，目前也正在考虑中。