如果从头开发新的 3d engine

云风 2011-04-11 15:57

最近闲了下来。断断续续的再想,如果业余时间弄一个开源项目玩儿,什么是比较好的题材,适合自己来做。想来想去,3d engine 是一个比较好的选择。以我来看,对外开源如果要吸引到足够的有经验的同学参加,必须项目有一定价值。要可以迅速的搭建工作环境并直接看到结果,这样才能有兴趣迭代做下去。起步必须自己一个人来做,东西得有个雏形。所以必须是自己比较熟悉的领域。

若论熟悉,其实游戏服务器的架构和实现,我这些年考虑的更多,也做的更多。但这个东西不适合做成开源项目。因为受众太小(不是每个人都有机会和意愿去架设网络游戏服务器的),而且它不能单独运行看到结果。没有玩家的游戏服务器是没有意义的。

3d engine 这些年也有在开发。但是公司不可能允许开源已有项目。如果想玩儿,从头做是唯一选择。而且重新开始有更多的乐趣,再造轮子原本就是程序员们的欢乐源泉之一。如果自娱是唯一目的的话,就不必过多考虑商业引擎必须考虑的问题。比如兼容更多的底层 3D API ,做全平台兼容,支持低端硬件等等。甚至于还要去考虑日后防外挂等无聊的问题。

昨天在 buzz 上提起 game engine 开发的话题,miloyip 同学立刻发了份他的一些想法。有很多的记录,想来也是思考多日。对于 engine 特性方面列的很全了。不过我的出发点不太一样。我更多的考虑的是,如果是做为一个开源项目,怎样可以以最小代价启动起来,让项目自然成长。也就是说,可以在质量和特性上有个高起点,但从一个很小的功能集合开始。而且,如果做这个,没有商业上的目的。所以,不必屈就于进度压力。不必为特别的需求必须去加上什么功能。一切以好玩为目的。只要写代码开心即可。

考虑了一晚上,我觉得如果动手做的话,大概是这样的。

Git 是最近我比较中意的 VCS 工具,如果比较 google code 和 github 的,我比较倾向后者。

开发语言,我希望是 C + Lua 的组合。因为这两个都是我最为熟悉的语言,使用起来最为得心应手。C++ 也很熟悉,某些方面 C++ 写起来要比 C 更方便。尤其是采用 D3D 的底层 API 的话,C 要麻烦的多。而且还有许多第三方组件也是 C++ 接口的。不过我用 C 搭建大的系统已经有多年的经验了,我相信我的经验可以弥补 C 语言的诸多不足。而 Lua 会是对 C 语言很好的一个补充。

Engine 的核心部分,可以以 C 语言写成的库提供,再由独立的 lua 封装层包装起来,二次开发在 Lua 中进行。如果需要在外层使用非 Lua 的接口,比如用 QT/C++ 开发工具,则可以在 Lua 层绕一下,或是再单独开发一个薄的 C++ 的粘合层。

不用太在意粘合层的性能,但需要把粘合层和核心库设计上隔离开。

3d api 可以暂时只支持 DX11 ,openGL 的支持待考虑。不过最好能留下余地。在代码编写上,初期的代码量不宜过大,做好至少一次重构的准备。所以第一期代码不需要面面俱到。这主要是因为我在 3d 领域方面经验不足。

构建工具采用 GNU Make ,这个工具我有比较多的使用经验,也更大众。不必要求所有开发人员都精通 GNU Make 的使用,整体的框架可以一个人先做好即可。

编译工具使用 gcc 。可以考虑兼容 VC 编译。

功能上,Audio/GUI/Input/Network 等都不是先期必要模块,一开始都不必设计和实现的。也不必去抽象窗口管理的部分。但需要搭建一个运行环境,有基本的窗口启动,简单的 GUI (不可定制),方便的 Log 输出。

工具是应该第二步考虑的事情。

至于 3d engine 将支持的特性,那个应该是逐步添加的事情。虽然说,新特性的添加方便于否和 engine 的基础设施的可扩展性很有关系。但,从一个小规模的项目开始,逐步重写和完善,我觉得是更实际的方式。

现在缺少的东西主要有这些:

不知道项目该用什么名字以及项目代号是什么。

对近年的 3d 技术发展没有细致了解,领域知识的缺乏导致很难很好的做基础设计。

还没有下决心开启项目。

[返回] [原文链接]