博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
关于游戏引擎的选择——博客第一篇文章
阅读量:5142 次
发布时间:2019-06-13

本文共 2491 字,大约阅读时间需要 8 分钟。

绝对原创,转载请注明原作者lbird1992和博客地址http://www.cnblogs.com/lbird1992.

老实说,我自己搞游戏编程也有一年多了,接触的引擎也不少了,遇到的问题也不少。这篇文章我是不打算指明某个特定的引擎,第一没必要,第二也是为了防止出现打广告的嫌疑。当然,这篇文章针对的只是爱好者,那些大型的商业公司恐怕考虑的事情跟我所考虑的不一样。

有人说游戏引擎就好比汽车的发动机,一句话表明了游戏引擎的主要性。对于引擎的选择,当然是游戏开始制作前的重头戏。

从大的方面来看,游戏引擎无非分两种,自己写的和别人写的。(别拍我...)如果你是那种技术特别好,能力特别强的人,自己写出一个引擎来也不足为奇,所涉及的知识无外乎一些基本的操作系统知识,对素材的管理,还有图形学的一些知识。如果层级高一些的话,可能用到了诸如DirectX, openGL等等第三方API。尽管我把自己写引擎这事说得这么简单,如果让坐在电脑前,做为资深程序员的你自己写一套游戏引擎来,估计你也有一种想穿越去一个没有电脑这种东西的时代。

下面开始说别人写的,也是这篇文章的重点。之前说过,我不打算提任何引擎的名字,只是大概地说一下如果去选择适合自身的游戏引擎。现在网络上的游戏引擎,分类方式有很多,2D3D引擎或者是通用的,商用的或者是共享的或者是开源的,代码类的或者是可视化的,脚本的或者非脚本的,甚至可以按照支持的编程语言来分类。

首先,选择引擎的一个大前提是确定你的游戏画面。不得不承认,尽管编写游戏代码时,显示部分其实并没有占用太多时间,更多的是游戏的内容。但是对于游戏者,他们百分之九十以上的时间都通过你的游戏画面来感受你的游戏。首先是2D或者3D,这点应该是最先被确定的。如果你用了2D引擎,而且已经编写了很多的游戏,这个时候突然想把画面换成3D的,理论上你可以只修改画面引擎部分,但是这其实是在重新写另一个游戏,因为2D3D所涉及的不只是图像,还有控制,游戏内容的表现方式等等很多元素。

其次,对于我们这些业余的爱好者,选择引擎的时候,当然首选共享或者开源的。当然,有很多商业级引擎在不涉及商业利益的情况下,也是可以免费使用的,或者只能免费使用部分功能。对于商业的收费引擎,如果经济允许的话,当然是最好的解决方案。尽管免费、共享是互联网的终极目标,但是现阶段下,收费就意味着专业的代码和公式,专业的程序框架,专业的更新维护团队,专业的技术支持和一份专业而且细致的文档。这些是在任何情况下,开源或者共享引擎所无法达到的,即使你疯狂的使用Google之类的搜索引擎来汲取知识。

选择引擎的另一个决定性因素,是你的能力和你的定位。目前,据我所知,基本上没有一个人就打算做一个全新的游戏的。网络上有很多工作室性质的民间组织,也在制作自己的游戏,但是这些小组,分工也是非常明确的。对于美工和音效,甚至有时也算上策划,永远也不要期盼他们懂得游戏程序运行的机制,革命的分工不同,造成每个人的认知也不同。美工可能希望引擎有完成的素材打包、压缩的工具,音效也如此,策划可能希望有一个简单的对话录入工具等等,但是这种功能很齐全的引擎,恐怕很少有免费的版本,即使有,大部分也都是可视化的游戏引擎。这意味着小组里的程序员无法更深层次地去了解或者去针对特定的游戏来修改引擎的内核代码。甚至某些可视化游戏的代码,是只支持脚本的。尽管脚本语言的存在就说明它是合理的,但是不可否认,脚本语言的效率在同等情况下,确实比C\C++或者其他编译类语言慢很多。有统计说,脚本语言和C++语言的效率平均差了20倍左右。

这中间其实也牵扯到程序员的能力问题,如果你对大型工程或者说大量代码的驾驭能力不是很高的话,脚本可能确实是一种非常合适的解决办法,简单,易学。但是如果你的能力允许,为何又要放弃那些宝贵的效率呢。比如笔者本人,对美术和音乐实在是没什么造诣,我之前所写出的小游戏,素材也都是来自于其他的网络游戏,这样我不需要考虑素材的问题,甚至可以自己选择喜欢的素材格式。这样的情况下,我当然更喜欢使用C\C++,因为可以直接对内存进行操作,尽管编写代码时有少许的麻烦,但是更直接,而不会像一些引擎,只能使用特定的素材格式。

最后就是个人喜好问题。不同的游戏引擎,甚至不同语言的游戏引擎,它们地代码结构可能都是不同的,这都是根据作者对于游戏框架的理解决定的。既然引擎作者敢于将它们发布出来,就说明这些结构是有其优势的,至少也是中庸的,即不突出,但是也不会很垃圾。简而言之,就是存在即合理。有些代码框架,可能使编写代码更加简单,但是会损失部分游戏性能,另一些框架,就可能是以API形势来工作的,性能很高,但是编写代码或者维护代码框架的时候会很繁琐。这些都是不可避免的,如果某种引擎使用也简单,性能也很高,那么其他的引擎就没有存在的必要了。往往这个时候,就要看个人的取舍了,是完美主义者,还是追求高的工作效率。

挥挥洒洒写了这么多字,其实说的也很笼统,可能在选择引擎的时候,更多的情况是要先试用,然后再统一评判。这是我在这里博客的第一篇文章,写得也很仓促。笔者最近在搞网络游戏的编程,所以不是很悠闲。看看最近会不会有时间,如果可能,我还打算写一个系列,关于单机游戏编程的文章。不敢说是教程,可能只是把我的感悟写出来,算是给新人们一个提示而已。

如果想与我交流的话,可以PM我,也可以加我的QQ。我是十分喜欢找人交流的,这是一种提高自身的方式,不是么?

最后一句话,写了这么多,当然不想被当成别人的劳动果实,如果这篇文章有幸被读者您转载的话,请注明原作者lbird1992以及原文网址http://www.cnblogs.com/lbird1992。这句话没什么法律效力,只当是一种道德约束罢。

posted on
2012-11-19 22:08 阅读(
...) 评论(
...)

转载于:https://www.cnblogs.com/lbird1992/archive/2012/11/19/2778091.html

你可能感兴趣的文章
Swift,字典
查看>>
NodeJs通过async/await处理异步
查看>>
Beta 冲刺(5/7)
查看>>
网页编码
查看>>
术语抽取的程序(计算机专业术语的抽取 )java代写
查看>>
SpringMVC(九) RequestMapping请求参数
查看>>
线程简介
查看>>
我的算法学习之路
查看>>
机器学习中的相似性度量
查看>>
浏览器兼容
查看>>
SQL SERVER PIVOT与用法解释
查看>>
SQL Server数据库一直显示“正在还原”的解决方法
查看>>
机械硬盘设备硬件出现致命错误,导致请求失败资料怎样找回
查看>>
CSS3 transform 属性
查看>>
选择数组排序
查看>>
Step one : 熟悉HTML
查看>>
MVC模式(三层架构模式)
查看>>
XML解析【介绍、DOM、SAX详细说明、jaxp、dom4j、XPATH】
查看>>
day04_02 知识回顾、赋值运算符
查看>>
jQuery.load()事件使用方法详解
查看>>