最近在尝试用MingW开发环境（主要是比较精简，配置也比VC强大）开发一款带物理效果的游戏引擎，起名为 Dyna Physics 引擎（后面简称DPE或者DP引擎），由于暂时不打算开放源代码所以采用内部版权和私人发布方法。在这里打算写一系列文章记录一下目前比较混乱的思路，希望能慢慢的理清头绪把代码给实现出来，同时为整个开发过程做一个文字性的记录。
Dyna Physics 引擎的组成
按照我目前的理解，一个游戏引擎是所有游戏的核心程序，其同样由一系列的代码组成，从直观的功能上它主要负责以下内容的工作：
- 读取和加载各种多媒体文件（图形、声音、3D模型等）
- 受到用户的预定输入而动态操纵一个图形化舞台（包括2D和3D）
- 对图形化舞台展示出的动态图片进行动态渲染（除锯齿、HDR等）
- 可以根据各种关卡的设置脚本实现游戏剧情（剧情触发、动画播放、背景音乐播放等）
- 多人游戏时，负责多个用户之间的同步和互动
因而，开发的过程中可以根据以上的功能需求而划分引擎代码的目录结构，从而方便各种资源的独立管理，免得代码过度耦合而在后续开发中由于较大的混乱导致难以继续。同时代码尽量实现模块化，采用C++的面向对象技术同时又不过度滥用C++的高级特性而导致后续开发工作难度的增加，尽量保持一切代码都“一看就懂“而不需要反复查询相关参考。
游戏引擎是否需要窗体控制用的Application Framework呢？如果说仅仅是开发一个面向用户的游戏程序，那么完全可以把整个窗口做成一个图形显示界面，但是如果一个引擎既想实现游戏展示，又想能够同时为场景编辑器、甚至自行开发的建模器重复使用，那么一个Application Framework是完全必要的，为了保持整个设计的精简、gcc可编译等需求，决定不采用MFC应用程序框架而自行开发一个简单的Framework。
后续的开发过程暂时决定将按照如下的计划进行下去：
- 根据功能需求，构建 Dyna Physics 引擎的代码目录结构
- 组建编译环境，准备基于 Makefile 的编译系统代码
- 构建 Application Framework 的代码体系
- 构建核心数据结构与基于Direct3D的图形显示引擎
- 测试实现各种高级渲染器（顶点、像素）
- 通过动态物标代理机制，对对象实现物理效果（偏微分方程）
- 实现 Dyna Scripting 脚本控制系统
- 实现多种建模软件、图形文件格式的加载支持
- 实现扩展插件架构接口
- 后续的基于引擎的各种应用开发（建模软件、关卡编辑器、特效制作、动画制作等）
Dyna Physics 代码目录的规划与编译配置
目前 Dyna Physics 已经完成了第一步的工作，目前代码目录结构解释如下：
| 序号 | 名称 | 功能 |
| 1 | Binary | 发布给用户的目录，存放二进制、多媒体文件以及剧情脚本 |
| 2 | Config | 代码配置文件存储 |
| 3 | Demo | 演示代码，用于接口游戏引擎，开发时用于调试引擎，后续应用用于存放游戏实现 |
| 4 | Document | 开发者手册、技术设计文档 |
| 5 | Engine | 引擎核心系统 |
| 6 | Formats | 各种多媒体文件格式的加载器 |
| 7 | Framework | 应用程序框架，窗口对象化系统 |
| 8 | Network | 网络通讯系统 |
| 9 | Physics | 物理效果坐标代理系统 |
| 10 | Plugins | 各种扩展插件代码存放目录 |
| 11 | Scripting | DPE 引擎动态脚本子系统代码 |
| 11 | Shaders | 存储后置效果处理的各种DSL顶点渲染器、像素渲染器代码 |
| 11 | GNUMakefile | 用于 GNU Make，MingW开发环境的编译脚本 |
| 11 | Makefile |
用于 Visual Studio 的 NMAKE 用编译脚本 |
目前暂时按照各种功能的需求和开发计划，创建了如上的目录体系结构（其中正体字是目录，斜体字是文件），如果以后遇到不合理的地方或者需要添加的功能，可以及时在其中进行各种添加。
开发中最重要的一点，就是保持整个过程的简单、明了、一看就懂，如果遇到某些需要重复劳动的工作，尽量封装到一个通用的库里面去以函数调用的方式实现处理。Dyna Physics 在开发过程中应当尽量兼顾尺寸和速度问题，同时在简单性面前，一切都要为简单妥协，因为简单是开发能够持续下去的根本。
编译的配置可以通过修改GNUMakefile（MingW编译器）和Makefile（VC编译器）来实现添加文件编译等配置需求，目前计划是我独自先尽量构建整个引擎的代码体系，一旦整个代码体系确立下来，其他开发者只要可以写代码的就可以加入各部分的优化、功能扩展等方面的工作，当然，一开始的开发过程中如果有参与者同样能有能力贡献可用的代码，也可以参与开发。
Application Framework的开发
DP引擎中，程序框架（Application Framework）的定义是如下的：为后续的开发提供基本的窗体管理、消息分配、窗口叠加以及各种专属控件、通用控件的创建提供面向对象的程序基础（C++封装）。
在现实世界中，Win32平台上有商业的MFC和WTL现成的封装，但是为了：
- 确保 Dyna Physics 每一部分的代码都是手写的、可控的；
- 将整个引擎基本构建在 Win32 API 的基础上以提高执行效率和必要的特有优化；
- 为后续的其他平台移植的可能性提供基础性保证；
DPE 中决定不使用那些商用AFX框架，从而把对VC编译器的依赖需求消除，可以增加使用开源编译器进行代码开发的可能。
在MFC框架中，由于Windows图形系统的消息机制，采用了消息地图（Message Map）和消息路径（Message Routing）实现了通过一个函数或对象管理所有消息，自动发布到对应的处理函数的方法，因而DPE的框架中也需要考虑采用类似的机制，但是尽量做到满足需求即可，从而降低整体复杂度。
评论 (0)
