.GAME FRAMEWORK

开始用.NET构建我们梦想中的游戏

  博客园 :: 首页 :: 博问 :: 闪存 :: 新随笔 :: 联系 :: 订阅 订阅 :: 管理 ::
呵呵,好像有个把礼拜没有更新进展了吧?其实不是没有新内容,而是为了把更多的抽象概念展现出来,在不停的进行开发和测试。

那么最近的进展包括哪些呢?
包括一个最简单的“角色思考调度器”(就是所谓的唤醒和呼吸啦),以及一个最简单的“动作调度器”。这两个东西目前的功能都是最基本的,也没有经过很多的优化,能够完成最基本的功能了。其中角色思考调度器则应该没有什么大的问题了,往里面添加了两个对象,进行了一些简单的测试。而动作调度器则没有经过什么测试,只是如果空转的话肯定没问题。不过这里我也看不到有大问题存在的地方,因为它们内部都是使用同样的DemoScheduleQueue来执行的,如果有问题的话,在思考角色调度器里面就应该会反映出来了。原始的DemoScheduleQueue确实有点问题,不过大家是没有机会看的了,目前更新的代码里面已经是没有问题的版本了。

现在整个程序一共会开6个Thread,其中两个不知道是什么,好像是VS自己开的,另外四个则包括一个主线程(用于处理窗口消息),一个主循环线程(用于游戏主循环处理),以及两个用于动作队列调度的线程。前面两个线程比较好理解,并且可以肯定他们是长期并行运行的。而后两个则不太好理解,这里给出一个简单的解释:

因为动作在可以执行之前首先需要经过一系列的检查以确定动作是否已经可以开始执行了,检查的内容包括,前项动作是否完成以及动作双方的数据是否已经到达。如果检查通过了,才会放到执行队列里面进行执行。换而言之,这个调度器分为两个阶段,第一个阶段用于检查等待队列,第二个阶段用于执行运行队列。可是光是这样完全没有必要使用两个线程啊,顶多新开一个线程就足够啦。嗯,我这里使用线程并不是期望并行处理的,事实上这两个线程之间甚至和主循环线程之间都是串行执行的。用线程的目的是提供一个分别限制着两个阶段的执行时间的机制,因为有可能某一个动作花费很多的时间,使得最后整个图像填充过程被延迟执行,出现了丢祯的现象——虽然目前的Demo直接用Winform不存在这个问题,但是如果万一以后用DX/OpenGL,那就必须得这样了(总不能到时候再来大改吧?)。

目前这个机制运行得非常好,大家可以放心。

最后呢,为了能够有更多的视觉效果,做了一个控制台。虽然由于目前还没有什么具体的动作完成了,所以也不可能有动作可以执行,但是看看效果总是可以的。(由于没有动作,因此这一次只是考虑尽快展现视觉效果,因此某些功能实际上还不正常,请见谅)

最后说说下一阶段的计划:

现在没有一个机制用于“选中”角色,因此跟角色相关的操作还是显得比较混乱。下一阶段计划就是做一个角色选中器,里面包含了控制台更新的功能。控制台更新的功能现在是有的,但是并不能够很好的工作,例如无法进行一次选中多个角色的操作。

其次要准备考虑一下碰撞检测方面的问题了。碰撞检测的代码应该是有的,但是是否有可能提高效率则是另外一个问题了。比如说:如果游戏里面一共有1k个对象,那么每个对象移动一下都需要和其它的999个对象进行检测,因此一共讲需要进行999k次检测。而我希望这样的过程能够被简化,被优化。这可是一笔不小的开支啊!

当完成上述内容之后,我想应该可以开始写一些具体的“动作”出来了。完成了动作就意味着整个游戏可以开始活动了。当然,我想应该只是有限度的活动。

P.S.: 代码已经在sf.net上面更新了。
有空我就把它移动到mikespook的ftp上面去。
posted on 2004-06-18 13:38  我们的游戏世界  阅读(2264)  评论(0编辑  收藏  举报