前几天看了那小强的射击游戏,感慨很多啊,把那框架大体看了下,这几天忙着写几个算法练习题,么估得详细看那游戏里的技能与子弹的很多小的细节.
首先感觉再大的项目也是由细小部分组成的,所以对那些软件构成有了一点小的认识.十分庆幸.
他们将Bullet与Skill设计成抽象类,规定基本方法后,让二个人去实现它们的具体子类,分工明却点.便于集成.将Player类设计成具体子弹与技能的容器,符合实际,Game中存玩家,并控制游戏过程,与UI沟通.结构清晰.钦佩他们啊，呵呵。
感觉,应该是一个人写UI即MainFram类,Game类应该封装一个比如GetFramePic()之类的方法,其中绘制每一帧的画面,这样写MainFrame类的人,可以不去和Skill与Bullet,Player类去交互,去调用类Draw()方法,它只需与Game类交互,得到一个帧图象并显示,通过按键调用Game类的控制人物的方法即可,当然,为初始化人物中技能种类,那么写Skill与Bullet的二个人应该提供一个如xml文件,列出他们实现的类,让UI部分的人读xml文件动态生成类进行初始化子弹列表,这样,便与UI部分的独立性,也使技能与子弹种类的易扩展性大大提高,可以使写UI部分的人一心放在与用户交互的设计上,如增加各种信息,提供对话框让用户选择控制按键,及为各种技能分配独立按键信息等等,若有网络通信部分,他做的也很少,便于专一.
在其它方面,如具体绘画时,加个标志,如Player若没移动,就不用去绘制Player,通过一些算法控制,用户交互频繁时,刷新频率高些,用户控制活动少时,将低刷新频率.Game里那个单独更新数据的线程应与用户按键之间,以及显示之间能过算法有某种交互(还没想到具体应该咋做),以达到更好的效率.以有图片可以压缩,或采用较小的图,放大即可,在类中的绘画函数中,不用时手动Dispose掉那些gdi对象,因为子弹太多,等gc去做可能浪费较多的内存.