课程设计中期报告模板.docx
《课程设计中期报告模板.docx》由会员分享，可在线阅读，更多相关《课程设计中期报告模板.docx（13页珍藏版）》请在冰豆网上搜索。
课程设计中期报告模板
新疆大学
信息科学与工程学院
《程序设计》课程设计中期报告
题目：
专业计算机科学与技术
学生姓名
学号
联系方式
班级计算机15-1班
组员姓名
联系方式
检查日期2016.7.29
新疆大学信息科学与工程学院
1.课程设计内容概述
1.1项目来源及开发目的和意义
（以下为范例）
曾经有一段时期，游戏开发程序员只是关心如何尽量多的开发出新的游戏并把它们推销给玩家。
那时候的游戏大多简单粗糙，游戏逻辑很类似，并且每款游戏的平均开发周期也要达到8到10个月以上，导致这样的原因一方面是由于技术的原因，另一方面则是因为几乎每一款游戏的代码都要从头开始编写，造成了大量的重复劳动。
逐渐的一些有经验的游戏开发者摸索出了一条可重复利用代码开发游戏的方法，这样既节省了开发游戏的时间和费用，又降低了技术难度。
于是就慢慢的产生了游戏引擎。
人们对于游戏引擎的概念也逐步的深入理解。
实际上游戏引擎也是一个程序，这个理解也就是对“封装性”的理解。
随着游戏软件的发展，越来越多的人开始想自己编写游戏，自己设计游戏的剧情和逻辑，但是由于技术难度和时间的问题，很多人都放弃了原有的想法。
对于游戏公司来说，越早推出一款新类型的游戏，人们就会先接受哪款游戏，这对于游戏公司的生存和发展是很关键的。
这对于一个具有渲染系统，物理系统，网络系统，对底层api封装良好，并且可以通过解释简单的脚本语言就能实现一个简单的游戏的游戏引擎需求是十分关键的。
通过这样一个游戏引擎只要是会简单脚本语言（例如lua，python）的人，都可以编写自己的游戏，实现自己的梦想。
对于游戏公司来说可以不必高薪聘请很多高级C++程序员，而仅需懂脚本语言的人，来编写游戏逻辑即可实现一款游戏。
1.2总体设计内容及方案
（以下为范例）
本项目主要任务是开发一套易于使用的跨平台的2D游戏引擎。
引擎提供一套灵活的API接口给用户使用，并对这些API进行一次脚本绑定的封装，给用户最方便的接口。
本引擎有3种使用方式：
1.纯脚本方式，仅仅通过编写脚本调用引擎的接口来完成游戏的制作。
适合于快速开发并且游戏仅通过基本接口即可完成制作的。
2.C++方式，直接调用引擎接口而不使用脚本的封装。
适合于习惯于使用C++开发游戏或者是对于性能要求苛刻的用户。
3.混合方式（推荐的方式），由于引擎支持扩展，对于引擎没有的功能用户可以使用C++自己编写扩展插件，并把一些关键算法实现在插件里（这要比使用脚本实现算法效率高很多），然后在脚本中使用引擎的接口和自己的插件的接口来完成游戏的制作。
灵活且不损失性能。
引擎的总体设计：
1.引擎的核心模块（core），本模块提供对引擎编写的最底层的支持，主要包括：
1）引擎实现了自己的RTTI（Run-TimeTypeIdentification运行时类型识别），从而实现了对引擎里所有继承自Object基类的类的对象的序列化的支持。
通过序列化实现把某个对象存盘再从硬盘读入形成一个实例或者是通过网络发送的支持。
这是引擎其他模块的基础。
2）从底层实现对智能指针的支持。
基类Object实现了对引用计数的支持，从而从根本上实现了对智能指针的友好的支持。
3）对文件系统的支持。
在底层就对对文件系统的访问进行了管理，使得访问zip包像访问OS的文件系统一样方便，并通过设置文件的搜索路径使得访问文件可以使用和操作系统无关的路径进行访问，通过设置写目录对文件的写权限进行了有效的控制。
4）其他的一些有效的工具类，包括数学库把一些常用的数学运算进行了包装提供给其他模块使用、字符串处理类把一些常用的转换操作格式化操作等进行了封装、线程库实现了平台无关的线程支持、动态库类实现了多个平台的动态库加载的支持，另外还有计时器类、异常处理、日志处理等。
2.其他模块建立在core模块基础之上，包括graphics（图形模块）抽象出了一些图形相关的接口，并以插件的方式针对DirectX和OpenGL两套底层图形库进行了不同的实现。
还有input模块和sound模块分别实现了对输入设备和音频的支持，输入设备包括键盘、鼠标、手柄等。
音频包括3D声效，背景音乐的播放等。
这些模块由同组的王磊来实现。
3.对脚本的绑定的实现方案。
引擎使用swig（SimplifiedWrapperandInterfaceGenerator）轻松实现由C/C++接口到脚本的绑定。
4.编辑器（editor模块），编辑器是本游戏引擎的一个集成开发环境，包括脚本的编写、调试，游戏场景的制作、游戏资源文件的制作等。
这是引擎中相对复杂的一个模块。
1.3本人所承担任务（模块）说明
（以下为范例）
本人在整个项目中的具体任务是上面提到的core模块和editor模块。
1.core模块：
1）RTTI的实现：
实现了一个ClassInfo类，里面存放了这个类相关的各种信息如：
类的名称、大小、这个类的创建函数的指针（用于动态创建一个对象）、基类的ClassInfo指针（用于分析继承关系）等。
每一个继承自Object类的子类都有一个ClassInfo的静态成员来记录这个类的信息，通常使用宏来实现。
2）序列化的实现：
使用设计模式的Visitor模式，Object类实现了一个accept函数接受Visitor参数，Visitor进入类的内部后对遍历到的类的成员进行操作，如遇到基本类型则直接按照其类型进行操作，如遇到继承自Object的子类的成员变量则进行递归操作。
根据Visitor的类型的不同其功能也不同，引擎提供三种Visitor：
a）XmlVisitor以Xml格式存取一个对象，特点：
可读性高。
b）BinVisitor以二进制的方式存取一个对象，特点：
效率高，无需由字符串解析，且占用的空间少。
可用于网络传输。
c）AttributeVisitor用于记录对象的属性，把运行时对象的所有属性记录下来，可以绑定到编辑器进行编辑。
3）智能指针的支持：
Object类继承自ReferenceCounted，记录当前的引用计数并实现了加减操作并负责对引用计数降为0是对象的释放。
Pointer类就是我们的智能指针类，它是一个模板类，在构造、拷贝、赋值运算、销毁时确保正确地对它所控制的Object类的指针进行增减引用计数操作。
4）文件系统：
使用了开源库PhysFS并进行了简单的接口包装。
2.editor模块：
使用开源的界面库wxWidgets2.8.9进行界面的开发，选择的理由：
1）开源、跨平台，符合我们引擎的设计初衷。
2）它不仅仅是一套界面库，还提供了一些其他的平台无关的类库。
3）它使用操作系统的原生控件。
4）众多的contrib库和辅助开发程序，并且有Code:
:
Blocks等IDE也是使用它来开发的。
编辑器的总体设计：
图1-1编辑器组成示意图
编辑器主要功能使用动态库的方式实现，并对外提供一套API接口，主程序通过调用此动态库来完成相应的功能，并且主程序提供编辑器的主要的UI框架与用户交互。
为什么不将两者合在一起实现呢？
这是因为我们的编辑器要支持扩展，支持扩展的代价就是要对外开放接口，而开发接口的最好的方法就是动态库。
这样第三方扩展插件便可以轻松地使用编辑器的接口来完成它的功能，但它也必须遵从一定的规范才能被编辑器的主程序识别并顺利地加载，这个规范就是：
插件一定要实现“插件接口”，编辑器内留出了多种支持的插件类型的接口，如：
调试器插件用于对脚本语言的调试、向导插件用于新建某一类型的文件、文件类型处理插件用于对特定类型的文件进行编辑（材质编辑、粒子编辑、UI编辑都属于这种类型）。
编辑过程中与用户的交互是无法避免的，如何把在编辑过程中用户触发的事件在编辑器和插件之间以及插件和插件之间传递需要由一个系统来处理——事件系统：
图1-2编辑器事件系统示意图
用户进行编辑操作时会触发编辑器内部的事件，事件进入编辑器的事件处理系统，处理系统根据其类型查找相应的EventSinks，然后依次调用注册的回调函数将消息分派下去处理。
这样一些插件就可以通过注册某些关心的事件的回调函数来响应用户操作。
要实现相同的功能还有另一种方式：
为每一个类型的事件写一个虚函数，由插件继承并实现此接口，利用C++的多态特性来实现。
相比较而言，我们的处理方式更加灵活，并且性能更好（因为多层次的继承C++的虚函数表会造成性能问题）。
调试器的实现：
调试有2种实现方式：
单进程使用线程调试和多进程使用进程间通信的方式。
方式一：
容易编码，但需要保证调试和运行能够“友好”地相处，我们的编辑器不满足这种条件，编辑器和游戏是两个不同的进程，并且编辑器本身也使用游戏的一些库，着非常容易造成资源的混乱。
方式二：
必须进行进程间的通信，进程间的通信又主要有三种方式：
管道、共享内存、套接字。
其中管道的方式不合适，因为被调试的游戏端行为难以控制其基本输入流和输出流很可能被游戏的输入输出扰乱。
而共享内存方式虽然效率高但难以编码并且受限于必须是同一主机的进程。
最终选用了套接字的方式，通过loopback来实现，不但编码方式符合习惯并且只要实现了单机的调试，只需要改变连接的主机名称即可实现远程调试甚至实现跨平台的调试。
1.4开发环境和开发工具
1.4.1开发语言
（以下为范例）
考虑到性能和代码的可维护性，引擎底层使用C++语言开发，上层提供给用户的开发接口可以是C++或者其他脚本语言如：
Lua、Python等。
1.4.2开发工具
（以下为范例）
（1）Windows下主要采用MicrosoftVisualStudio.NET2003开发,同时支持2005、2008。
（2）Linux下采用Code:
:
Blocks开发，版本8.02。
1.4.3开发环境
（以下为范例）
图形库：
在Windows平台下可以使用DirectX做为引擎的渲染插件，其它平台均使用OpenGL作为渲染插件。
界面库：
使用跨平台的wxWidgets做为引擎编辑器的开发库。
字体库：
FreeType，一套免费的高品质的跨平台的字体引擎。
图片编码解码库：
DevIL、FreeImage，用于存取各种格式的图片文件。
文件系统：
PhysFS，使用它做为IO的接口，可控制文件的访问，更安全，统一。
如果项目在开发过程中需要用到其它开源框架或中间件时，将会有条件的使用它们，在此不作赘述。
1.5项目原定进度安排
（以下为范例）
表1-1原定进度安排
序号
起止日期
工作内容
1
16年07月01日—07月15日
完成前期的设计工作
2
16年07月16日—07月30日
完成编辑器的Lua支持,包括编辑、编译、调试功能
3
16年08月01日—08月15日
完成编辑器的材质编辑功能
4
16年08月16日—08月25日
完成编辑器的UI编辑功能
5
16年08月26日—08月30日
测试，答辩
2.中期完成情况说明
2.1预定计划的执行情况
（以下为范例）
课程设计工作正在按开题报告预定的内容及进度安排进行，原计划的工作内容中的物理模块打算由内部支持改为外部扩展支持，原因是由于Box2D的使用有局限性，并不是对所有类型游戏都通用的，它只针对“横版”式的游戏有效，所以改为可选插件。
工作进度：
core编码基本完成，editor框架搭建完成，脚本的编辑功能完成，调试功能尚未完成（仍需2周左右时间）。
即：
总估计要延后2周左右。
2.2中期工作说明及成果汇报
（以下为范例）
编辑器已经完成的功能：
脚本代码的语法高亮显示、代码折叠、Undo/Redo功能、代码文件的编码自动检测等功能。
如下图：
右侧区域为代码编辑区域。
该部分的实现使用了一个开源的代码编辑控件Scintilla（http:
//www.scintilla.org/）的wxWidgets版本。
图2-1编辑器截图
下图为编辑器的浏览器的工程页，相关的配置数据是由一个Project类来管理，并由上面提到的XmlVisitor遍历后存储到project.xml文件中以便下次打开编辑器直接从文件反向序列化成Project对象。
图2-2编辑器工程管理页
下图为文件系统浏览器页，使用了core模块里的文件系统，把操作系统的真实目录映射到了引擎的逻辑目录，用户可以使用引擎的路径来访问这些文件，而无需关心操作系统是否区别大小写以及斜杠的方向等细节问题。
双击某种类型的文件则会查找编辑器里注册的MIMEHandler插件，把文件按照插件的方式打开编辑，如：
双击UI文件会打开UI编辑的界面，双击材质文件会打开材质的编辑界面。
图2-2编辑器文件系统页
对象属性编辑页，直接将一个继承自Object类的对象与一个控件关联，可以直接编辑修改其成员变量的值，而无需再编写任何UI代码。
这里用到了core模块的AttributeVisitor。
图2-3编辑器属性编辑页
插件扩展，下图中的工具栏以及菜单栏上的“Lua调试”菜单都是通过“调试器插件”扩展的，该插件继承自编辑器内部的抽象类EditorDebuggerPlugin并实现了虚函数来实现扩展的。
并且插件可以注册自己关心的事件的回调函数来完成对用户操作的响应，这依赖于编辑器内部的事件系统。
其他的材质编辑功能、UI编辑功能也将采用插件的方式实现。
图2-4Lua调试插件
2.3存在的困难与问题
（以下为范例）
（1）工程规模较大，编码时间不充裕
解决办法：
核心部分编码已经基本完成，调试功能也接近尾声，尽力争取时间完成粒子编辑、材质编辑、UI编辑这三大模块，细节问题延后处理。
（2）对于某些平台不熟悉
解决办法：
先做Windows和Linux平台的实现，对于不熟悉的Mac和PSP等平台推后做或暂时不做。
2.4如期完成预定任务的可能性分析
（以下为范例）
主要功能可以按期完成，引擎制作中的技术难题已经基本解决，（主要有：
插件方式支持扩展、引擎API导出到脚本使用、脚本语言的调试等），剩下的只是编码工作。
2.5后期工作安排
（以下为范例）
表2-1后期工作安排
序号
起止日期
工作内容
1
16年08月01日—08月15日
完成Lua调试功能
2
16年08月15日—08月25日
完成编辑器画布和粒子编辑功能
3
16年08月25日—08月30日
完成UI编辑功能
4
16年09月01日—09月05日
制作演示程序并完成文档以及最终的整合测试工作
升级会员 