dgui与游戏的区别

原文
问题是你是在做游戏还是在做其他应用,游戏和gui之间有一些重叠,但并没有太多,两者都是在屏幕上绘画并接受用户输入,但即使是这两件事,它们也往往做得很不一样.

GUI倾向于响应性.我知道,有人说"游戏必须更响应!!!"但让我说完:游戏倾向于*可预测性*.(当然也有一些异常.)

gui会尽快响应输入.如果能在一毫秒内响应按键,那就太好了!或,另一方面,如果需要200毫秒,不是那么好,但我可能仍可接受它.

游戏需要对输入做出严格反应.反应太快可能会打破游戏规则,物理世界不是无限精确的,设计时考虑到了某些限制.

可能会给一些玩家给予不公平的优势.反应太慢表明玩家会错过跳跃,并有缺乏控制的沮丧感觉.但是注意,如果是"可预测地"慢了,玩家们会习惯的,很多事情都是按游戏规则故意延迟的,只是不一致的慢才是"太慢".

因此,对游戏来说,在计时器上轮询输入是很常见的,而gui则等待事件的输入.

游戏和gui都要绘画,但是游戏倾向于一次绘画,显示随时间推移而变化的游戏世界,而gui倾向于一次绘画一个不同的东西,以响应用户输入或一些请求.
当然,一些gui会做类似游戏的大型动画,但这些都少;多数时候,绘画游戏来保持屏幕与游戏世界的状态同步,而大多数时候GUI是在等待事情,是空闲的.

这只是功能上的差异,其他东西也是非常不同的.游戏经常(但并不总是)尽量可预测的延迟音频,以保持a/v同步.GUI一般空闲,一般可延迟打开音频设备,直到需要它,然后在效果完成后立即关闭它.大多数游戏在一个大的多角色窗口中包含自身.

GUI一般使用几个包括临时单一用法窗口(如弹出菜单和工具)的不同角色.GUI需要实现各种游戏很少关心的输入模式:进程间拖放,复制和粘贴,UI自动化和可访问性API.
gui一般是个更大的合作整体的一部分,而不仅是它们自己.游戏只是想把它们得到的全局输入都带入自己独立的游戏世界,而游戏更可能关心操作杆和游戏句柄而不是gui.

库可同时帮助游戏和gui,但它不太可能是两者的完整解决方案.