自己对于游戏进程控制的感想

   这个暑假,在学习之余,也试着写了一个星期的2D的RPG游戏,由于只是为了体会游戏制作的流程,因此也就只是用简单的windows api来建构游戏引擎,也就是说所有的位图显

示都是selectobject进设备中的。但是为了保证屏幕不闪烁,我还是先准备了一个后备设备(HDC backbufferdc),为什么呢?因为可以将所有的需要渲染的内容全部都BitBlt到

这个后备设备中,然后再统一BitBlt到主设备中(HDC hdc),这样就可以在更新画面的时候不至于有内容的先后或屏幕的闪烁。
  如果要建立后备缓冲机制,必须先将后备设备与主设备进行匹配,可以用CreateCompatibleDC函数实现。
  在这里,我并不是想谈怎么建立后备缓冲机制,而是主要想说说关于2D游戏开发的一些特点,游戏开发不像其他软件的开发,其他软件的界面状态的控制不是重点,而游戏软件却基本把界面控制作为了重中之重。
  我在这个星期的游戏编写中主要体会如下:
  1.游戏过程中涉及很多状态,举RPG游戏为例,基本可以分为
    (1)行走状态画面
    (2)战斗状态画面
  其中(2)又可以分为比如攻击状态,防御状态,使用魔法状态等,而单从攻击状态又可以分出攻击的准备,攻击的进行,攻击的完成等...因此在游戏开发过程中,对于状态的分类把握应该很清楚,不仅因为在不同的状态要完成不同的操作,还因为游戏是在画面的不断的刷新中进行的,因此引导画面进行正确刷新的方法就应该是利用状态的变更来进行,举个例子说,角色要进行攻击,那就要先把游戏状态调整为攻击模式,并在该模式下完成相关操作,诸如人物的攻击动画,攻击的判定效果等,在攻击结束再将游戏状态调整到攻击结束,在这个状态我们可以判断对方是否战死,抑或对方部队是否全灭,然后再根据结果继续进行游戏状态的调整。因此界面状态的控制可以说贯穿整个游戏制作的全过程,我基本上是使用define来定义一些状态名称,如READY,ATTACK等,再用switch..case分支结构来进行游戏框架的搭建,同时要再着重一点,游戏过程是在不断刷新中进行的,while结构等循环结构一般是不能用来进行游戏框架的搭建的。
  2.游戏状态分类越细致,游戏就越容易控制,所以在进行游戏制作之前,必须在游戏文档中将游戏可能的状态变化罗列清楚,并且为每一个状态都确定好可能需要的输入数据与输出数据,这样就可以根据实际情况编写出相应的函数,这样,就可以避免在游戏制作过程中由于缺少数据而临时进行成员函数的编写或者参数的增加。
  3.最后是关于类的定义的一点感想,通常编写一个游戏,对于游戏中控制角色一般都写成一个类进行数据与操作的封装,可是如果要用它,又必须要先声明一个实体,那么在windows架构下,就必须定义一个全局的类对象,否则,由于它的局部性,在消息处理时很可能看不见它,可是游戏角色不止一个,过多的全局对象看起来总有些不舒服,那么我就

考虑定义一个游戏框架类,把所有需要的对象实体都定义成它的成员参数,由它统一操作,并控制游戏进程的进行。这样可以让游戏主程序界面看起来更清爽,游戏代码编写也更

集中。
  以上仅仅是我对2D游戏编写的一点感想,由于自己试着写的3D游戏都是用别人的引擎,自己一时也没有机会看到源代码,所以写的东西可能只能给初入行的人看看,虽然自己水平十分有限,但是我也希望能给比我更年轻的人一些帮助,当然,也希望大牛们能来我这里逛逛,给些意见,谢谢。

你可能感兴趣的:(游戏,windows,框架,api,文档,引擎)