作者cppOrz (cppOrz)
看板C_and_CPP
标题Re: [问题]在写小游戏时遇到物件阶层设计的问题
时间Sun Nov 27 03:35:20 2005
※ 引述《linjack (嗯)》之铭言:
: 想法1: 只有 gamewindow 去 inherit library 中的 widget class(QWidget)
: 其他的 bricks / pad / ball 都是自己从头设计的 class
: 呼叫 pad 和 ball 的移动 method, 还有所有的
: collision detection 都写在 gamewindow 中去 handle
: 重绘事件通通交给 gamewindow 做, pad / ball / brick
: 是经由 gamewindow 的重绘才得以显现在视窗画面上.
: 想法2: 所有物件都去 inherit library 中的 widget class(QWidget)
: 使用者所输入的移动指令会直接去 call pad 继承自 widget class
: 而来的 move method, 同样 ball 的移动都是自己处理的
: 而 collision detection 只写在 ball 里面
: 我理想中的状况是, 这样写似乎 gamewindow 就不用处理重绘了
: 因为东西不是被画上去的, 而是每一个物件都是一个 widget
: 看起来想法二似乎比较好 ?
: 可否请板上大大指点一二呢 ? 感激不尽.
小程式的话其实怎麽做都可以啦
不过一般游戏的做法,都是自己处理重绘的部份
而且很重要的一点,计算(游戏的逻辑、资料处理、物理运动…等)和显示
(不管你是怎麽画)的处理,最好是分开的
在显示上,有部份的设计和 QWidget 现有的功能是重叠的,因此自己重做
可能会觉得有点浪费;换句话说,如果你对 QWidget 够熟,的确是可以最
大限度利用它现成的架构……
但是这样的缺点就是你会被绑在 QWidget 上。举个例子,假设有一天你需要
做大量的混色,或者你发现需要 60 fps 以上,才能保持流畅度,QWidget
不够快怎麽办?如果当初是用第一种想法(自己处理重绘),也许还有办法
简单移植(修改底层的成像核心);如果当初是用第二种,你大概会发现重写
还比较快!
--
※ 发信站: 批踢踢实业坊(ptt.cc)
◆ From: 59.120.214.120
1F:推 linjack:感谢回答 :-) 11/27 15:29