游戏开发工具与Game Virtual Machine 设想

http://www.cppblog.com/sunicdavy/archive/2009/08/26/94482.html

 

     游戏开发到现今，已经进入到一种固定模式与创意挣扎的阶段。Activision Blizzard 刚刚超过EA成为全球最大的游戏制造商，再看下我们周围的这些所谓的大作，无非就是版本号更高一些，画面更好一些，然后将其他游戏热门的创意进行大抄袭意外，几乎依然保留着最初版本的痕迹和基本玩法。然后，有一些开发者，依然坚持创建自己的游戏，按照自己的意图去设计全新的游戏，独立游戏概念就此出炉。

        说到独立游戏，其实可以被称作是“小游戏”，这些游戏为了快速实现游戏原型，一般都使用高级的游戏开发工具，比如说RPGMaker， GameMaker, ActionGameMaker等等。这些工具其实最早的鼻祖，在我认为，莫过于星际争霸的编辑器，一个完全不需要编程就可以实现游戏创意的工具。最近，星际争霸2介绍游戏编辑器的视频放了出来，世界瞬间震撼了。一个RTS游戏的编辑器，居然连射击游戏都可以制作，虽然在魔兽争霸3的编辑器中已经可以实现类似于跑跑卡丁车这类游戏。

       依然游戏很多开发者认为，那些开发工具都是为不会编程的玩家实现的。包括我在内，也是这样认为的，因为我们追求的目标并不一样，一个是追求游戏设计的乐趣，一个是追求代码编写的快乐以及高可定制性等。

       使用现成的游戏开发工具固然简单，但是学习的过程以及这些工具的限制，更恐怖的莫过于这些工具的BUG（类似于GameMaker中浮点数的精度问题）都让我重新考虑传统游戏开发。但同样我会面对更多的问题：

1. 一个好的基于Windows的引擎，最好是DX9硬件加速

2. 基于位图的字体，带编辑器的粒子，GUI以及控制系统组件

3. 轨迹控制，动画帧控制，可定制的多边形碰撞系统

4. 能使用脚本，更有类似于Unreal系列的对象脚本技术，支持脚本暂停，并可调试

5. 一个非常棒的开发环境以及能让所有组件都可以扩展的系统

也许是我要求很高，至今为止，没有哪个引擎能支持的那么好，又免费。顺便说下评价下几个C++图形引擎

HGE：

1. 使用DX8，很多DX9特性不能完全支持，例如很多DX9的API，HLSL等，虽然这些看似在2D里用处不大

2.低效的zip读取机制。zip的文件读取以及查找居然采用字符串比较，也就是attach的zip越多，查找速度越慢

3. 粒子系统带有编辑器，这点很不错，而且效果也还可以

4. 字体要提出批评，这点做的太差了

5. 原始版不支持unicode，使用hge社区里某大侠提供的unicode版本后，做国际化方便多了

6. 纯粹简单游戏引擎，做下猫猫狗狗的差不多，做复杂的格斗的话，很费力

 

SexFramework（Popcap游戏引擎）

1. 使用DDraw，古老而又稳定的技术，在植物对僵尸的游戏里，明显看到，当物体过多时，渲染速度急剧下降。当然这里我觉得应该是这个游戏大量使用flash造成的吧（猜测）

2. 支持后台加载，这点需要大量加分。看到很多Popcap游戏边播放动画边加载吧？

3. 支持专门的包读取，api有点像c风格io库

4. 因为商用，所以可以信赖，别忘记，还支持flash哦

 

IndieLib（可以在我的博客前面的文章找到）

1. 统一的C API，简洁，漂亮，便于与.net结合做编辑器

2. 硬件DX9加速，比HGE好多了，而且数学库清一色使用D3DX，更是快的一塌糊涂

3. 支持多边形碰撞检测，以及XML定制的动画帧

4.支持2d缩放，这个技术让游戏可以变的很酷

5. 没有支持压缩包读取，但是从代码上看，加的话应该不困难

6. 没有粒子支持，即便有，也没有编辑器支持，就这点就很严重了

 

各位如果有的2d引擎库，也请推荐下

 

Game Virtual Machine

      之所以要提出这个概念，主要是建立在游戏的本质其实也是与网页很接近的。

       纵览网页的开发模型，不难看出这部分已经是很成熟的了。例如：ASP可以自动将你的标记过的代码编译成客户端或者服务器的版本。自动排版引擎的概念彻底推翻了微软以左上角像素的对象显示方式。一个网页，支持各种脚本扩展以及Flash这种RIA应用

      游戏，如果仅仅按照类型来做限定时，GameMaker，RPGMaker这类工具已经能将游戏开发的概念抽象成一些步骤以及参数。但问题是，要使用这些工具来制作一些并不常见的游戏类型时，可能见变得非常难，当然这点上，GameMaker要做的好一些，这个工具使用了很多类似于脚本图形化技术，说白了，底层仍然是它的脚本，只不过经过一层图形化工具的封装后给你使用而已。

     我所设想的GameVirtualMachine是这样的：

 

建立于游戏指令系统之上

       传统的游戏都是建立在虚拟机基础上，这样做的好处就是很灵活。但同时这也造成了程序员为了实现一些游戏中的逻辑关系，硬生生的使用OO这种概念来模拟另外一个概念。这样做导致了游戏代码难于理解。

        很现实的一个例子就是C++的反射问题。C#中将反射做到了编译器以及Runtime层，这让开发者们一门心思的进行程序设计，虽然有一些性能损失，但是对于很多C++项目不停不停的造反射这个轮子来说明显是值得的。

       这套指令系统有一些基本指令，这些基本指令类似于一个脚本系统基本的运算以及流程控制等等。

简化游戏逻辑编写

       建立在指令系统上的优点是很明显的。指令系统底层运行着游戏虚拟机，其可以对指令的运行进行控制以便实现，让精灵走到哪个位置，停一会再走到哪个位置的等一系列流程的操作。这些操作对于传统裸写游戏来说，不知道要写多少次计数器，计时器。

直观而简单的调试

        因为不使用脚本语言，调试变的异常简单，甚至于，玩家想知道游戏怎么运行的，只要打开一个GVM的调试器就可以看到诸如

              move_sprite_to   xxx, xxxx

              attack_enemy xxxx,xxx

可扩展性

      为了制作通用游戏，这套指令是可以被扩展的。例如精灵控制子集，地图控制子集等等

      指令集着眼的是对象，流程以及逻辑控制。而指令集的实现就是与底层API的交互过程。

      如果你说现在编辑器不能实现一个飞龙随机飞舞并由玩家控制吐火的逻辑时，你便可为这个游戏编写一些随机飞舞，吐火的指令，底层实现完全依赖于一些API。

      创建指令的目的，就是让游戏的操作变成一种组件开发的接口创建工程。让更多的玩家可以为游戏逻辑互相编写，共享代码

     创建指令的同时，你写的指令代码其实就是新的VM代码。GVM系统会将你的VM代码与其他VM代码一起在游戏中运行

编辑器可实现性

       游戏不难做，难做的编辑器。编辑器里最直接的功能就是需要UNDO/REDO，这可以让设计者在设计重新设计之间反复选择。因为所有操作都是基于指令的。

     其实所谓的编辑器，也就是一个脚本生成器。诸多的按钮，ComboBox等等其实都是低效的，但是对于不会编程，或者需要快速开发的玩家来说，GUI是唯一的选择。当然，如果在某些部分需要特殊逻辑时，就可以与指令混合编写

跨平台性

       VM的特性已经被广为使用。从浏览器到Android手机操作系统，乃至OS。因此，GVM也是可以跨平台的。只需要在每个平台下实现一些平台相关的模块就可以