write by 九天雁翎(JTianLing) -- blog.csdn.net/vagrxie
为什么我们要从现成的游戏引擎学习开始
很多人问过我类似的问题，学习程序该从什么入手？怎么样开始编写一个游戏？实际上的游戏开发都是从OpenGL开始的吗？学了OpenGL后怎么开始做游戏？
这些问题可能很难有什么标准答案，不过个人认为，在学习一门编程语言后，开始真正的做一些东西是很重要的，并且，这些东西要上一定的规模，那种玩具式的开发虽然也能学到一些东西，但是因为其过于简单，会掩盖很多随着规模变大而碰到的问题，这样也就会让你无法获得真实开发中获得的经验及教训。经验，那是作为一个程序员最为宝贵的财富。
游戏的开发，很少有公司/个人会真的从零开始开发，得益于开源运动的努力，现在已经有很多开源的游戏引擎可以使用，从3D中最为著名的OGRE，irrlicht，2D的HGE。都是其中的佼佼者，从这些引擎的基础上开始自己的工作，会让你事半功倍，就像站在巨人的肩膀上，能看的更高，更远，更加专注于自己关心的游戏逻辑模块。诚然，假如需要真的对一款游戏引擎了解透彻，并掌握自己开发游戏引擎的技术，从零开发的经验是很重要的，但是对于大多数人来讲，即使是学习，先采取从上之下的学习方式，（即先学会使用一款引擎，然后再深入了解这个引擎的原理）也会轻松愉快很多。有了一定的对引擎的经验后，再去尝试开发自己的引擎，那会使你受益匪浅。假如一开始就做太大规模的尝试，很可能使得你有太强的挫败感，毕竟，这是游戏编写最难的部分，人都是需要先学会走路然后才学会跑的。
另外，我选择从2D引擎Orx开始，也是出于这样的考虑，虽然事实上，也许我对Irrlicht的使用经验比对orx的使用经验还要多。
Orx介绍（http://orx-project.org/）
Orx的LOGO，有点像我们常提及的orz。。。。。
Orx不是世界上最优秀的2D游戏引擎，也不是最流行的一个，事实上,Orx还有太多不成熟的地方，我也常常对这些地方感觉非常郁闷，由于Orx的小知名度，所以周边的模块开发，文档等也非常少，这样极大的限制了其传播，并且极大的限制了其发展。
但是，我还是很喜欢Orx,因为它很有特点。
Orx以配置为基础
以配置为基础，所以使得Orx非常的灵活，可以进行快速的开发，快速的实验，快速的调整，并且因为配置文件模块写的比较强大，你也很容易添加进自己的配置，这点我非常喜欢，我一直很喜欢一句话，lua之父说：只有当配置的使用足够的简单，人们才会乐于使用它。虽然此话是针对lua的，但是对于任何配置的使用都适用，Orx就有这样的特质。这也是Orx最大的特点。
虽然在初期，对于太多配置的理解会比对于一些代码的理解更加困难，但是掌握后的好处是无穷无尽的。
Orx是跨平台的
目前Orx直接支持的平台包含了所有流行的平台，包括了Windows,MacOS,Linux，还有IPhone,IPad。事实上，我当年就是在寻找一个合适的跨平台IPhone引擎时发现Orx的。（我前段时间的工作就是在IPhone平台上，所以比较关注）当然，即使对于IPhone平台来说，最优秀的2D引擎毋庸置疑的是Cocos2D for Iphone，Cocos2D for Iphone是我见过的支持特性最多的2D引擎，不仅仅针对IPhone平台，在所有的开源2D引擎中，它支持的特性都是堪称最多的，得益于IPhone开发的热门，其周边的工具也是非常的丰富，实际建立在Cocos2D for Iphone引擎上的游戏也是数以十计。但是，Cocos2D for IPhone是仅限Iphone平台的，并且使用的是Objective C语言开发。这是它的强项，也是其弱项。我希望有个跨平台的引擎，这样才能看到更多，并且易于协作，（在公司也是这样）在Windows下开发，然后在其他平台运行，这是很重要的，别的不说，就说Macos独霸的XCode，根本没有办法与在Windows下经历过多次残酷竞争并且胜出的Visual studio相比，再加上Visual assist和ViEmu两个插件，VS绝对是梦幻级的平台！
并且，虽然我也可以使用Objective C来开发，但是我更加熟悉的还是C++，所以我希望使用C++来开发，这样对于我来说，效率会更加高。
跨平台，对于很多只关注Windows平台的人来说是完全不考虑的，但是，其实，优势有太多太多。
Orx的协议非常自由
在外企的工作经验使我对协议非常敏感，不再像在国内企业时那样，只要是世界上最强大的，拿来就用，Orx的新版本（1.2)会使用Zlib协议，这是一个非常非常自由的协议，支持进行商业闭源的开发，并且也完全可以对Orx进行任何的闭源的修改。
Orx支持的特性比较多
Orx不是最强大的，但是支持的特性已经足够多了，可以很方便的做一些简单的游戏，其内嵌物理引擎Box2D，内嵌声音引擎，有很多有用的图形特效，比如缩放，翻转，移动，alpha值变化等，事实也提供了对addcolor和普通透明混合效果的支持。
Orx使用较为简单
Orx的使用很简单，不仅仅其以配置为基础（事实上我感觉这点在初期还比较麻烦），Orx的作者对Orx的定位是一款完整的游戏引擎，而不仅仅是一个图形引擎，在Orx中所有的东西都抽象成了Object，拥有统一的接口，并且可以方便的通过配置/代码来更改属性及效果。并且最最重要的是，Orx对于物理引擎的支持不是简单的外挂（如Cocos2D for Iphone)，而是内嵌，直接将Box2D与其Object绑定在一起，可以直接通过配置的设置，不用知道任何Box2D的东西，就能直接使用物理引擎。当然，事实上，知道其相关的物理概念还是很重要的，不然怎么知道配置什么啊？但是起码可以不使用任何Box2D的API。（目前仅提供一些基础的支持，不支持Joint这样稍微复杂一点的特性）目前个人使用感觉是，用Orx做物理相关的东西，那是非常的简单。但是，由于Orx对于图形动画的支持较弱，而且也没有一款动画编辑器支持，所以用来做复杂的动画（其实即使是简单的动画）会比较麻烦，需要非常多的手动配置。我正考虑为Orx做一款以Json为基础的动画编辑器以简化此过程。
Orx的开发者有丰富的经验，并且极为热心
我在Orx的论坛上，以及私下与Orx的开发者（目前Orx核心主要由iarwain开发）有很多的交流，他有着15年以上的程序编写经验，10年以上的游戏开发经验，并且一直是从事底层开发，现在任职于Ubisoft的加拿大蒙特利尔工作室，他的工作经验，使得Orx有着坚实的基础，良好的架构，特别值得一提的是其编码风格，注释详尽到几乎每行都有，我曾经询问过这个问题，因为通常来讲，推荐的注释的作用为解释代码的运行原理和作用（即Why？How？），而不是具体干了什么(what)，但是他认为，整个代码他就是分为两部分，一部分为逻辑，一部分为实现，逻辑由注释描述，实现由代码描述，方便他在不看代码的情况下就能方便的了解逻辑，进行全面的了解或者深入的调试。并且其提出，在他那里，有很多编程经验丰富的人尝试用这种风格来编码，从来没有人说这种风格不好的，最后都坚持使用了这种风格。当然，这仅是一家之言，他的个人看法，但是对比现在我工作中的几乎没有注释的代码，我还是感慨良多。
他经验丰富，最难得的是他非常热心，在论坛中，他知无不答，答无不尽，纠正了很多我对游戏开发的一些不对看法，也解释了很多Orx的设计，运行原理和思想，我受益良多。在私下的用steam的交流中，他也是给了我很多提示和解答，对我的帮助非常多。
最后
推荐有兴趣的人都去其网站看看，并了解了解，希望你也能像我一样喜欢上Orx,网址是http://orx-project.org/，在WIKI上有两个 教程 ，讲的还算比较详细，但是也有很多我认为遗漏的地方， API Doc 得益于iarwain的详尽注释风格，非常详细。事实上，我准备按照我的学习经验，自己组织一系列关于Orx的教程，并且，以开发一款完整的游戏为脉络，而不是以特性介绍为原则。会以Windows为平时的开发平台。
-----------------------------------------------------------------------------------------------------------------------------
关于极端详细的注释风格，我问过iarwain，这样的风格岂不是很影响开发效率？毕竟写代码时写那么详尽的注释总是个负担，但是他说他和他的朋友们都说从来没有这样的感觉，注释总是让他 们在调试时，在过了很久再回头来看时，可以忽略很多代码，而直达问题的关键。后来，我想了想，也许和他的工作内容有关吧，他常常进行的是底层的开发工作（如他所 言，low-level），所以可能相对来说代码量比较小，改动也比较小的，更多的时间是用于思考，而不是敲代码，而且，因为稳定，有可能需要回头看用过了很久的代码，所以这样的注释风格才适合他吧。呵呵，对于我这样的coder,常常敲无厘头，没难度，不用思考的逻辑代码，最多一周几千行C++代码的工作量，要是按那个规模注释，估计很难达到老板要求的速度了。
-----------------------------------------------------------------------------------------------------------------------------
这里贴一段iarwain自己的话来解释一下 LuckilyYu 的问题，以及iarwain自己对 Orx的目标，也同时作为一个额外的参考材料。其实并不是所有的引擎都只关心图形显示的。
其中Irrlicht作者将其归入Game Engines一类，个人对其有所了解，感觉应该在High level game libraries。其他还是比较赞同。
usually see 4 different kinds of game creation tools:
* Low level game libraries: Allegro, SDL, ClanLib, ...
* High level game libraries: IndieLib, Cocos2D, STK, ...
* Game engines: they're usually 3D ones: Panda3D, Irrlicht, Delta3D, ...
* Fully integrated game engines: Construct, Unreal, Unity, GameMaker, ...
I think orx is (or trying to be) part of the third list. You don't manage sprites, sound resources etc, in orx, you just have objects with properties and rules in a 3D world.
What it means in the end is that, as you said, there's a higher level of abstraction which usually leads to less low level control.
As everything is public in orx, and due to the plugin architecture, you could take control of the low level parts, even rendering if you needed 3D support.
Of course, it's not the philosophy of the engine and I'm trying hard to make things so that you wouldn't feel the need too much to do so.
Orx is the way it is because I don't like having to initialize in code a whole bunch of things and write 10 lines everytime I want to add a new sprite with a visual effect.
I'd rather just change some parameters in config and restart the program without changing a line of code, or even just reload the config file on-the-fly depending on the cases.
Of course, nothing's perfect and this aim isn't totally reached, but that's my current goal: having the least amount of code to write as possible.
原创文章作者保留版权 转载请注明原作者 并给出链接
write by 九天雁翎(JTianLing) -- blog.csdn.net/vagrxie
