zoukankan      html  css  js  c++  java
  • 超便携电脑游戏设计最佳方案

    超便携电脑游戏设计最佳方案
    发布日期: 2007年8月14日 | 最后修改日期: 2007年9月12日
    当开发人员考虑到某些设计需求来确保为用户提供愉快的体验时,超便携电脑 (UMPC) 将拓展运行在 Microsoft Windows* XP 上的电脑游戏的市场。 大多数情况下,某个版本的游戏可以在 UMPC 和传统 PC 两种平台上运行。

    作者 Matt Gillespie、Michael Finkel 和 Victoria Bailey 

    1 介绍
    作为游戏开发人员使用的一个目标系统,超便携电脑 (UMPC) 平台变得越来越重要。 因为这些系统在 Microsoft Windows* XP Tablet PC Edition 上运行,所以不需要对现有游戏使用全操作系统端口,但是 UMPC 的外观尺寸需要在游戏设计中引起注意。 例如,UMPC 通常拥有一个分辨率为 800x480 或 1024x600 的触摸屏,这表示像素更小,宽高比更大。 另外,开发人员还必须提供传统键盘和鼠标用户交互操作的备用方案,通常不提供 CD-ROM 驱动器。

    本文档中有关支持电脑游戏在 UMPC 平台上成功运行的最佳方案,是基于当前市场上大量电脑游戏的分析得到的。 在 UMPC 平台上运行那些游戏后,可确定与该平台相关的优势和劣势,以及可为用户提供愉快体验的特定游戏设计因素。 分析中包括有关在 UMPC 上提供高质量游戏的设计注意事项,以及提供 UMPC 支持相关的常见问题,提供了每一种问题的最佳解决方案。
    2 屏幕尺寸注意事项
    因为 UMPC 屏幕比传统屏幕要小很多,所以必须更小心地处理图形元素的尺寸。 开发人员既要避免将按比例缩小的图形元素设计得过小,又要避免尺寸相同的其它元素占用太多的屏幕空间。 特别是,有时很难看清楚文本和图标,单击某些按钮或单位也很难奏效,一些游戏窗口不能完全适应屏幕的形状。
    2.1 文本和图标的尺寸
    问题:在通过端口连接到 UMPC 的游戏界面上,文本或图标可能会缩小为某个尺寸,在这种尺寸下很难看清楚这些文本或图标。 这是一个普遍存在的问题,一定要避免出现,因为如果不能读取或分辩文本和图标,这些文本和图标就变为无用。 如果文本在 15 英寸的屏幕上尺寸显示合理,当收缩到 5 到 7 英寸的屏幕上时,毫无疑问文本会变得过小。UMPC 的屏幕可能是 5 到 7 英寸。 除文本实际字体尺寸以外,聊天和其他文本窗口也会变得过小。 如果通过降低字体尺寸来提供较小的窗口尺寸,则会使阅读文本变得更难。

    最佳方案:理想情况下,一定要注意使用 UMPC 设计的游戏应尽少使用文本,另外还要在选择字体时考虑 UMPC 的屏幕尺寸。 同样,图标不应过分精细,以便即使在较小的 UMPC 屏幕上,也可以很容易地区分出差异明显的不同对象。 如果可以充分增大文本尺寸,调整游戏的其它元素,调整文本尺寸是一个很好的解决方案,即允许各个玩家自己决定文本的理想尺寸。
    2.2 按钮和其他元素的单击性能
    问题:与文本过小问题类似,按钮和其他可单击游戏元素增加了通过端口连接到 UMPC 的游戏的复杂性。 也就是说,当 UMPC 上的整个界面一定要小于对应的标准 PC 版本时,UMPC 界面上的实际按钮必须更大,才能够使用笔针或手指正确单击,而不是使用标准 PC 版本中比较精确的鼠标。 如图 1 所示,当多个按钮或其它元素聚集在一起时,这个问题尤为严重,这会导致用户选择所要选择元素之外的元素。 即使可以很小心地选择正确元素,也会令用户在体验时分心。


    图 1 在 20 英寸的 PC 监视器(左图)上,用户可以很容易地使用箭头光标确定并选择一张多米诺骨牌。 但是,当多米诺骨牌图像缩小后显示在 5 英寸的 UMPC 屏幕(右图)上时,用户很难选择单张骨牌,甚至无法识别每一骨牌上有多少点。

    最佳方案:文本和图标尺寸的问题,游戏开发人员应通过使用大而且独特的按钮或其它元素来避免其出现。 另外,这些元素之间还应有足够的空间,从而降低用户因疏忽而选择错误元素的可能性。 如果文本标签靠近按钮或其他元素,该标签应当位于与元素相关的可单击区域,这样单击更容易,而且不会占用额外的空间。
    2.3 游戏窗口尺寸
    问题:如果游戏窗口的尺寸固定,而不是通过自动调整来填满 UMPC 的整个屏幕,那么可能会突然看不见游戏中的某些部分。某些情况下,可能无法点击游戏中的某些部分,如图 2 所示。当玩家使用 UMPC 宽屏支持的 800x480 或 1024x600 分辨率时,这种情况变得更复杂,因为屏幕宽高比必须与多数电脑游戏机使用的标准 4:3 长宽比相匹配。


    图 2 在标准 PC(左图)上,用户能看见整个游戏区域,包括玩家界面中的信息部分。 如果游戏窗口修剪后与 UMPC 的较小尺寸和不同长宽比相适应(中图),那么游戏中的相关部分将会隐藏起来,此处用屏幕边缘的半透明部分表示。 如果游戏窗口缩小后与 UMPC 屏幕相适应(右图),则可以很容易地看见游戏中的所有部分,虽然有一定程度的视觉失真,还是可以接受的。

    最佳方案:对游戏开发人员来说,解决这个问题的关键是在开发 UMPC 的游戏界面时考虑使用 800x480 和 1024x600 分辨率,通过缩小整个游戏窗口来适应屏幕,也可重新排列界面以充分利用屏幕的宽向区域。 经过某些简单调整可以使游戏更具可玩性,即使是在截断的状态下也是如此。 例如,在某些情况下,提供滚动栏,允许手动或自动调整窗口足以使用户访问整个屏幕,并提供可接受的体验,特别是基于浏览器的游戏。
    3 触摸屏注意事项
    在 UMPC 上使用触摸屏而不是鼠标进一步增加了通过端口连接游戏的复杂性。 就多数的软件用途而言,触摸屏的作用就像一个鼠标,除了在用户拖动光标时不记录移动线性跟踪之外,在每次用户触摸屏幕时都会生成关于某个位置的一系列按钮按下事件。 不单击就不能移动光标以及左键单击与右键单击之间的关系,也会导致出现一些问题。
    3.1 触摸屏仅点击(Tap-Only )输入的准确解释
    问题:UMPC 游戏必须能够将用户提供的光标输入解释为一系列的点(对应于一系列的屏幕触摸点击操作),而不需要线性模式的移动(像控制光标的鼠标移动提供的那样)。 例如,尤其在移动用户透视图的游戏中往往会出现这种问题,所以光标总是出现在屏幕中央(这种情况在第一人称射击软件中常见)。 这种情况下,当玩家触摸屏幕时,光标可能在屏幕四处不规则地跳跃,而不是移动到用户触摸之处。

    最佳方案:如果在游戏中跟踪光标从 A 点到 B 点的移动,则一定能够解释 A 点的单击,然后解释 B 点的点击,不需要光标先在 A 点与 B 点之间移动。另外,需要将一个外部鼠标插到 UMPC 上,通常也能解决这个问题,但是从用户体验角度看,这个解决方案明显不是最理想的选择。
    3.2 准确的触摸屏映射
    当游戏在全屏模式下运行但没有完全占据整个屏幕(没有填满整个屏幕,或占据的面积大于整个屏幕)时,触摸屏幕可能会映射到错误的游戏。

    问题(游戏分辨率小于实际屏幕分辨率):当游戏认在全屏模式下以比实际屏幕低的分辨率下运行时,会在屏幕中央显示,屏幕四边都留有一定的空间(如 640x480 的窗口在 800x480 的屏幕上会靠近中央显示,或者 800x600 的窗口在 1024x600 的屏幕上会靠近中央显示,屏幕四边都显示黑色长条),当将整个触摸屏表面映射到了相对较小的显示区域时,该映射会发生错误。 错误映射(如图 3 中所示)会导致在界面上对用户交互操作做出不正确的响应,如按钮的可单击屏幕区域偏离了按钮的可视位置。

      图 3 当游戏窗口靠近屏幕中央显示且屏幕四边都显示黑色长条时,负责解释屏幕点击操作的游戏逻辑必须避免将整个实际屏幕区域映射到更小的游戏窗口。 这种错误映射会导致游戏将在一个位置(用黄色箭头表示)的屏幕点击操作解释为发生在另一个位置(用红色爆炸符号表示)。


    最佳方案:当映射逻辑认为黑色长条是屏幕的一部分(即使黑色长条没有用做游戏的一部分)时,游戏可靠近屏幕中央显示,而且屏幕四边都显示黑色长条,这种情况下不会导致错误地映射触摸屏。 通过这种调整,屏幕触摸会准确地映射到触摸位置。

    问题(游戏分辨率大于屏幕分辨率):当游戏窗口占据面积大于整个屏幕的竖向空间时,可能会错误地映射触摸屏的竖向,而不是横向,如图 4 中所示。这种情况通常会导致将触摸屏映射到整个游戏窗口,而不仅是可视部分。 此外,单击并不对应于用户要单击的游戏窗口区域。

      图 4 在实际屏幕上剪去游戏窗口的一部分(用半透明区域表示),也会导致游戏将在一个位置(用黄色箭头表示)的屏幕点击操作解释为发生在另一个位置(用红色爆炸符号表示),原因是游戏窗口与实际显示的不同形状之间的错误映射造成的。


    最佳方案:开发人员应当确保操作系统将触摸屏准确映射到屏幕的整个可视部分(包括游戏未使用的部分),但不包括游戏窗口中看不见的部分。开发人员的另一个解决方案是,在本机支持将 800x480 和 1024x600 屏幕分辨率作为用户配置选项。 某些情况下,如果游戏元素的最后尺寸失真可接受的话,游戏可通过自动伸展窗口来适应整个屏幕。
    3.3 悬停效果的备用方案
    问题:许多游戏都使用悬停功能来支持用户在游戏中将鼠标放在某个对象或某个位置之上(无需单击),从而触发可提供信息的动画或工具提示。 这个功能常用来为初级玩家提供说明,但是它与触摸屏不兼容,因为触摸屏不能在不单击情况下移动光标。

    最佳方案:由于悬停功能与当前 UMPC 硬件不兼容,所以开发人员应选择其他事件来触发动画或工具提示。 例如,当玩家到达与动画对象或工具提示对象相关的游戏比赛部分时,能够触发动画对象或工具提示对象。 另一种可能性是设计一个界面,借助某种手段临时将单击事件解释为鼠标悬停事件,如某个按钮可保持按下状态,以允许通过在触摸屏上触摸来移动光标,而不需要记录单击。
    3.4 调整右键单击功能
    问题:在典型的 UMPC 触摸屏上,用户在屏幕上通过按下单击执行右键单击的时间要长于左键单击,这可能会导致用户在想要右键单击时意外地左键单击。 而且,不能同时执行右键单击与左键单击。

    最佳方案:开发人员应提供其他用户交互操作来替换右键单击功能,如在屏幕上使用双击或可单击控件来代替右键单击。 或者,游戏开发人员可以只是要求使用外部鼠标或其他指针设备,虽然这种需求可能令用户在体验时分心。
    4 外观尺寸注意事项
    相对于标准 PC 来说,很多问题直接与 UMPC 外观尺寸中的硬件差异有关。例如,UMPC 与 PC 不一样,它可能拥有触摸屏、操纵杆、用户编程按钮和类似菜单按钮那样的专用按钮,但是它通常没有键盘或 CD-ROM 驱动器。 虽然可以添加键盘、CD-ROM 驱动器或其他外围设备,但是这样做会降低 UMPC 的便携性。 此外,不同型号的 UMPC 可能在设计中包括了不同的元素,这会导致与外观尺寸相关的限制因设备而异。 这种可变性通常要求开发人员按照核心要求,在设计游戏时将重点放在迁就玩家的最低硬件功能上。
    4.1 CD-ROM 驱动器
    问题:CD 是当前用来分发游戏的最流行方法。 除通过 CD 进行安装外,常常还需要磁盘作为验证游戏所有权一种手段,或者作为一种防盗措施,在需要时可通过 CD 动态加载内容,如视频片断。 因为 UMPC 上通常没有集成的 CD-ROM 驱动器,这种情况需要使用外部驱动器,因此影响了 UMPC 的便携性。此外,用户可能恰好没有外部 CD 驱动器。特别要说明的是,这个问题对以 Web 为主机、基于浏览器的游戏没有影响。

    最佳方案:使游戏可下载且可通过 Internet 进行安装,这是玩 UMPC 游戏时替代 CD 的一种理想方法。 这种分发模式现在已广泛使用,开发人员应当把 UMPC 的出现看作是对推广这种模式的一个更有力推动。 还应考虑使用证书或其他基于软件的方法来验证所有权,而不是要求实际提供 CD。 与其在游戏比赛期间需要时通过 CD 动态加载视频或其他内容,不如开发人员应考虑提供用来将内容存放在 UMPC 硬盘上的选项。
    4.2 限制不同命令输入的需要
    问题:相对于标准 PC 提供的整个键盘和鼠标而言,UMPC 的外观尺寸对输入有很多限制。 即使设计使用操纵杆在 PC 上运行的那些游戏,也可能需要使用多个按钮,其中包括典型的操纵杆控制器,这个控制器在 UMPC 中可能不提供。 另外,当在游戏中将键盘快捷键具体表现为主要游戏比赛组件时,UMPC 也会存在一些问题。 特别要说明的是,主要受鼠标驱动的游戏不受此部分所讲的外观尺寸限制的影响。

    最佳方案:相对于类似菜单选项快捷键那样的可选便利选项,开发人员可通过减少游戏比赛中实际需要的命令数来处理 UMPC 上的限制输入选项问题。 但是,更灵活的解决方案是创建屏幕按钮。 尤其是如果按钮是上下文相关的,且只在与按钮相关时才显示相关按钮,则这会针对输入要求提供开放式的解决方案。
    4.3 处理键盘要求
    问题:除发出命令外,许多游戏还使用键盘来输入,如命名人物、创建人物资料、保存游戏或支持在线游戏聊天功能。 例如,游戏一般都需要键盘在游戏会话开始时输入人物资料名,但在会话期间的其他任何时候都不需要使用键盘。 某些游戏还要求玩家使用键盘来命名保存的游戏。 很多情况下,屏幕上的键盘不会在游戏界面的顶部运行,所以不能解决这些问题。

    最佳方案:开发人员应明确设计游戏不与屏幕键盘冲突(例如,不默认为全屏模式),或只在需要时在显示的界面本身上提供屏幕键盘。 有一种简单方法可用来减少键盘输入的需要,即提供诸如人物资料名、保存游戏名等文本字符串的默认值,然后允许使用屏幕点击输入操作时选择这些值。 提供这些文本字符串的其他值也可通过以下方式完成:添加一个界面按钮,使用这个界面按钮可随机在开发人员创建的人物名单中选择新值。 根据玩家结束游戏时的屏幕捕获,加上日期与时间戳,也可以识别保存的游戏。 由于聊天功能通常不是游戏比赛中的核心内容,所以一般在 UMPC 会禁用这些功能,这对用户体验不会有什么负面影响。
    5 结论
    游戏开发人员及设计师在主流游戏产品中支持 UMPC 平台,他们提出了一组相互无关的设计注意事项,解决在开发过程中出现的一些常见问题。 本文档中描述的最佳方案为此提供了基础。 因为基于 Window 的 UMPC 运行完整版本的操作系统,它与单独操作环境的全端口相比较,通常需要更少的改进就能提供这种支持。 因此,经过不断的努力扩展了游戏市场,包括扩展了 UMPC 平台的部署战线,因此为游戏软件提供商提供了竞争优势。
    6 其他资源
    如果游戏开发人员及设计师考虑如何在其产品中最大程度地集成需要的 UMPC 平台,他们将会从以下资源中获益:


    查看本文的 PDF [PDF 192KB]
  • 相关阅读:
    图片数据增强
    Crowd Counting using Deep Recurrent Spatial-Aware Network (IJCAI2018)(人群密度)(待补)
    Crowd Counting by Adaptively Fusing Predictions from an Image Pyramid (BMVC2018)
    Top-Down Feedback for Crowd Counting Convolutional Neural Network (AAAI2018) (人群密度)
    [SANet] Scale Aggregation Network for Accurate and Efficient Crowd Counting (ECCV2018)(人群密度)
    Human Protein Atlas Image
    google
    AE(auto encoder)
    feature aggregate
    Arcgis Server api for javascript加载天地图(转)
  • 原文地址:https://www.cnblogs.com/godwar/p/1078147.html
Copyright © 2011-2022 走看看