科技: 人物 企业 技术 IT业 TMT
科普: 自然 科学 科幻 宇宙 科学家
通信: 历史 技术 手机 词典 3G馆
索引: 分类 推荐 专题 热点 排行榜
互联网: 广告 营销 政务 游戏 google
新媒体: 社交 博客 学者 人物 传播学
新思想: 网站 新书 新知 新词 思想家
图书馆: 文化 商业 管理 经济 期刊
网络文化: 社会 红人 黑客 治理 亚文化
创业百科: VC 词典 指南 案例 创业史
前沿科技: 清洁 绿色 纳米 生物 环保
知识产权: 盗版 共享 学人 法规 著作
用户名: 密码: 注册 忘记密码?
    创建新词条
科技百科
  • 人气指数: 6196 次
  • 编辑次数: 1 次 历史版本
  • 更新时间: 2012-04-26
土土
土土
发短消息
相关词条
游戏机夕阳赛场
游戏机夕阳赛场
触屏控制方式优劣
触屏控制方式优劣
游戏硬件设备发展趋势
游戏硬件设备发展趋势
传统游戏机歧路
传统游戏机歧路
下一代Xbox
下一代Xbox
玩家触屏移动控制方式
玩家触屏移动控制方式
用户虚拟商品消费习惯
用户虚拟商品消费习惯
3DS和DSi外观对比
3DS和DSi外观对比
揭秘Kinect工作原理
揭秘Kinect工作原理
微软Kinect拆解图
微软Kinect拆解图
推荐词条
希拉里二度竞选
希拉里二度竞选
《互联网百科系列》
《互联网百科系列》
《黑客百科》
《黑客百科》
《网络舆情百科》
《网络舆情百科》
《网络治理百科》
《网络治理百科》
《硅谷百科》
《硅谷百科》
2017年特斯拉
2017年特斯拉
MIT黑客全纪录
MIT黑客全纪录
桑达尔·皮查伊
桑达尔·皮查伊
阿里双十一成交额
阿里双十一成交额
最新词条

热门标签

微博侠 数字营销2011年度总结 政务微博元年 2011微博十大事件 美国十大创业孵化器 盘点美国导师型创业孵化器 盘点导师型创业孵化器 TechStars 智能电视大战前夜 竞争型国企 公益型国企 2011央视经济年度人物 Rhianna Pratchett 莱恩娜·普莱契 Zynga与Facebook关系 Zynga盈利危机 2010年手机社交游戏行业分析报告 游戏奖励 主流手机游戏公司运营表现 主流手机游戏公司运营对比数据 创建游戏原型 正反馈现象 易用性设计增强游戏体验 易用性设计 《The Sims Social》社交亮 心理生理学与游戏 Kixeye Storm8 Storm8公司 女性玩家营销策略 休闲游戏的创新性 游戏运营的数据分析 社交游戏分析学常见术语 游戏运营数据解析 iPad风行美国校园 iPad终结传统教科书 游戏平衡性 成长类型及情感元素 鸿蒙国际 云骗钱 2011年政务微博报告 《2011年政务微博报告》 方正产业图谱 方正改制考 通信企业属公益型国企 善用玩家作弊行为 手机游戏传播 每用户平均收入 ARPU值 ARPU 游戏授权三面观 游戏设计所运用的化学原理 iOS应用人性化界面设计原则 硬核游戏 硬核社交游戏 生物测量法研究玩家 全球移动用户 用户研究三部曲 Tagged转型故事 Tagged Instagram火爆的3大原因 全球第四大社交网络Badoo Badoo 2011年最迅猛的20大创业公司 病毒式传播功能支持的游戏设计 病毒式传播功能 美国社交游戏虚拟商品收益 Flipboard改变阅读 盘点10大最难iPhone游戏 移动应用设计7大主流趋势 成功的设计文件十个要点 游戏设计文件 应用内置付费功能 内置付费功能 IAP功能 IAP IAP模式 游戏易用性测试 生理心理游戏评估 游戏化游戏 全美社交游戏规模 美国社交游戏市场 全球平板电脑出货量 Facebook虚拟商品收益 Facebook全球广告营收 Facebook广告营收 失败游戏设计的数宗罪名 休闲游戏设计要点 玩游戏可提高认知能力 玩游戏与认知能力 全球游戏广告 独立开发者提高工作效率的100个要点 Facebook亚洲用户 免费游戏的10种创收模式 人类大脑可下载 2012年最值得期待的20位硅谷企业家 做空中概股的幕后黑手 做空中概股幕后黑手 苹果2013营收 Playfish社交游戏架构

玩家触屏移动控制方式 发表评论(0) 编辑词条

目录

玩家触屏移动控制方式编辑本段回目录

今天我花了很多的时间在触屏界面上尝试一款全新的游戏。这是一款迷宫游戏,其执行方式与《吃豆人》类似,但是内容却完全不同。

当我开始创造这款游戏的玩家精灵行为代码时,我知道自己将面对一个困难的决定,它与游戏的移动控制方式有关。

Danger Ranger(from spacemonsters)

Danger Ranger(from spacemonsters)

如果是在之前的游戏我便不会遇到这一问题,因为那时候我们可以用一种最基本的方式去处理移动问题。例如《Galactians》的控制便是简单的左右滑动;《Wizard Wars》是通过碰触去操纵游戏而《Danger Ranger》则是滑动手指去移动Ranger,操纵着他们向左或向右移动。但是在我的这款游戏中还有关于跳跃的内容。起初我只打算借用《Dragons》的移动代码,并且不想再添加其它内容了。但是考虑到这是一款迷宫游戏,如何让玩家更加自然地体验游戏也就变得更加重要。我不希望玩家在游戏中纠结该将手指置于哪里才能操纵角色的移动,因为我真的不喜欢采用半透明的虚拟方向键这种方法。我相信即使不使用这种方向键,我也能够有效地利用触屏界面。

但是我必须努力研究各种选择。

在开始阐述玩家移动设置之前,我想先列出我是如何创建并管理碰触代码。

function initTouch() {     if(checkForTouch()) {         if (document.body.addEventListener)         {             document.body.addEventListener(‘touchmove’, touchMove, false);             document.body.addEventListener(‘touchstart’, touchStart, false);             document.body.addEventListener(‘touchend’, touchEnd, false);         } else {             window.addEventListener(‘touchmove’, touchMove, false);             window.addEventListener(‘touchstart’, touchStart, false);             window.addEventListener(‘touchend’, touchEnd, false);         }     } else {         window.addEventListener(‘mousedown’, mouseDown, false);         window.addEventListener(‘mousemove’, mouseMove, false);         window.addEventListener(‘mouseup’, mouseUp, false);         write(“No touch capability.”);     } };   function checkForTouch() {     var d = document.createElement(“div”);     d.setAttribute(“ontouchmove”, “return;”);     return typeof d.ontouchmove == “function” ? true : false; };

我在此执行了一个基本的测试去判断触屏是否是一种有效的功能,如果不是的话我是否应该重新选择鼠标控制功能。如果你过去曾经在台式机上玩过我的游戏,你肯定都会看到一行“无碰触功能”的提示。

而这里的重点是,我们实现了通过碰触而开始游戏,移动角色并完成游戏的过程。这是一种非常强大的功能,让我们能够在控制游戏时能够拥有更多选择。

我们该如何利用这种碰触控制?

其实非常简单。我只需要在每次碰触事件发生时保存下碰触对象的坐标值即可。如下:

var touch = {}; function touchStart(event) {     var xy = getXY(event.touches[0]);     touch.startx = xy.x;     touch.starty = xy.y; };   function getXY(event) {     try    {         var xy = {};         xy.x = (event.pageX – (g.canvas.offsetParent ? g.canvas.parentNode.offsetLeft : 0));         xy.y = (event.pageY – (g.canvas.offsetParent ? g.canvas.parentNode.offsetTop : 0));         return xy;     }     catch (e)     {         write(“getXY: ” + e.message);     } };

我在try/catch中涵括了大部分的函数。并只是假装调用了touchStar()函数。

所以这些代码的意思也是一目了然。回到只列出横坐标和纵坐标参数的对象,在此我能够控制玩家的移动。你们应该会注意到我在这里使用了offsets以表明玩家的真正位置——因为我将文件中心的游戏场景边距设为“0px auto”以及320px的宽度。如果换成是桌面游戏这便是问题所在,但是因为在手机平台上我们是通过视口去处理显示器,所以就不会出现桌面游戏所面临的问题。

现在我已经获得了一些坐标值,所以我可以开始研究控制玩家的一些选择了。

我的这款迷宫游戏中布满了许多蜿蜒崎岖的道路,我希望玩家能够在此避开各种怪物并收集各种奖励而前进。当然不止这些内容了,不过因为想到玩家能够控制自己的角色移动我就有了继续前进的动力。

第一种选择便是设置虚拟方向键。玩家将能够清楚地看到这一控制方法,并也会因此感觉到不自然。这种方向键总是设置在屏幕下方的角落里,从而玩家就必须憋屈地在一小块空间中控制游戏的进行。

我创造了一个简单的方向键,并将其设置在屏幕的右下方角落中。然后我编写了一些代码去追踪玩家会按压方向键的哪一边,随后在手机上加载游戏并更新游戏。

(注:我的横坐标/纵坐标检测代码非常简单。我只需要在屏幕上检查碰触事件是否被记录在与方向键图表相同的位置即可。)

总而言之,如果使用这种方法玩家就必须投入一半的时间着眼于方向键的操作,而没有多余的时间去观看自己的角色是如何在迷宫中移动。

所以我立刻就放弃了这一选择。

第二种选择便是在游戏屏幕的最上方,最右边,最下方以及最左边添加箭头图标。

这一理念听起来是合理的。因为我将让玩家碰触屏幕上一些较大的领域而朝上,右,下,左四个方向移动角色。

我将再次在手机上加载并更新游戏。

一开始这种设置是合理的。我能够顺利地移动角色并且在角色的移动过程中也拥有更多的灵活空间。

但是很快地我也感到厌烦了,因为当角色移动到屏幕下方时我的手指可能会遮住下面的空间,从而需要寻找其它更好的移动方式。

所以我也抛弃了这一方法。

第三种选择与第一种选择类似,但是却扩大了玩家的控制范围。

我尝试着关掉手机并去碰触屏幕,想象着自己在玩一款游戏,以此感受怎样的设置才是真正合理的。

当我在屏幕上移动着自己的手指时我意识到自己所追求的控制方式其实与第一种方法相类似。但是我希望方向键能够设置在我第一次碰触到屏幕的位置(游戏邦注:也就是用户可以自定义方向键的位置)。

所以我便开始着手创造一个续发事件,如下:

touchStar:记录方向键坐标的中心位置

touchMouve:让方向键处理器去处理事件并更新碰触对象的横坐标以及纵坐标

如此记录下来的方向键中心位置便是玩家的初始位置,而我接下来便需要思考如何将touchMove的坐标转变为玩家需要面对的新方向。

如下:

if (touch.newx > touch.startx) moveright;

但是这里也存在一些问题。

想象手指从初始位置的128,128点处开始向右移动。

随着touchMouve事件持续得到激活,横坐标的值将如预期那样开始往上增值(即129,130,131……)。而我也可以清楚地看到角色正在向右移动。

但是当我的拇指轻轻地碰触了屏幕时,我的纵坐标值也会从128开始往上攀升。

所以到底哪个方向才是对的?玩家是想要向右移动还是向下移动?

在这类型游戏中用户反馈和合理的碰触界面都至关重要。如果你不能处理好这些因素,也就等于扼杀了你自己的游戏,而你的玩家也将不再对游戏感兴趣。

我还对一个问题充满疑惑,也就是当角色沿着过道前行并碰触到一面墙时,他应该向右转还是向左转才能前往下一个通道。为了解决这个疑惑我玩了许多遍《吃豆人》,并在此获得了许多有价值的设计经验。并且为了能够创造出最合理的出口我也尝试着设置了touch.testx和touch.testy。并且这些代码也都能够有序地运行着。

游戏邦注:原文发表于2012年2月2日,所涉事件及数据以当时为准。(本文为游戏邦/gamerboom.com编译,作者:Mark )

Touch screen and player movement

Posted by Mark on February 2, 2012

Today I have spent a hopeless amount of time playing with the touch screen interface for a new game.

The game is a maze game, similar in many respects to Pac-Man in the way that it executes, but quite different in its content.

When I started to assemble the code for the player’s sprite behaviour I knew I was going to be faced with a tough decision regarding movement control.

In previous games this has never really been much of an issue since I’m generally dealing with movement in a fairly basic way. Galactians for example was a simple slide left and slide right affair. Wizard Wars was a touch-to-go-here game and Danger Ranger was a case of sliding your thumb or finger to turn the ranger to walk left or right. Everything else in that game was about jumping. In any case I’d taken the movement code from Dragons and not added much more to it.

But with this maze game it’s important to me that the whole thing feels natural. I really didn’t want the player to be concerned with where he has to put his finger in order to move. I really do loath the idea of semi-transparent virtual d-pads. It’s just that the touch screen interface can be used to great effect without them.

But, I had to explore all options.

Before I prattle on about the theory of implementing player movement let me show you how I set up and manage the touch code.

As you can see I perform a fairly basic test to see whether touch is supported as a function and if not fall back to mouse control. If you were to play any of my games on the desktop with diags switched on you’d see the line “No touch capability.” every time.

The point here is the level of control that we have over touch start, move and end. It’s pretty powerful and gives us a ton of options for controlling our games.

So how do we do anything with touch ?

It’s quite simple. Every time a touch event fires I store the co-ords in the touch object. Something like this..

I generally wrap most functions in try / catch. Just pretend I did that with the touchStart() function ;-)

So again it’s all fairly straight forward. Returning an object with just the x and y parameters I get some control over how to handle my player movement. Notice that I use the offsets to determine the true position since I’m positioning my game canvas in the centre of the document with margin: 0px auto and a width of 320px; On the desktop this is an issue. Generally on mobile it isn’t since I’m handling the display with the viewport.

So now I’ve got some co-ordinates and I can start to explore options for controlling the player.

The game itself is a maze crawling affair. I want my character to walk the maze avoid monsters and collecting goodies. There will be a little more to it than that but essentially this gives me something to go on when considering the player’s control of his character.

Option 1 is all about a virtual overlaid d-pad. You will have seen them. God awful things that just don’t feel natural at all. They’re generally plonked in the lower corner of the screen and you are forced to control your game in a small space.

I created a simple d-pad graphic and placed it in the lower right corner.

I then wrote some code to track which edge of the d-pad had been pressed, uploaded the game and hit the refresh on the phone.

( Note: my X/Y detection code is primitive. I’m checking the screen to see if the touch event was recorded at the same location as the location of the d-pad graphic. )

To cut a long story short I must have spent 50% of my time looking at the blessed d-pad and not even enjoying watching my character march around the maze.

I ditched this idea swiftly.

Option 2 saw me drawing thin arrow graphics at the top, right, bottom and left most edges of the game screen.

The theory was sound. I’d just let the player touch some fairly large areas of the screen in order to move the player up, right, down or left.

Again I uploaded and refreshed on the phone.

Initially it felt OK. I was able to smoothly move the character around and it felt pretty good having more than a couple of cm flexibility in the movement.

But I soon tired of having my hand obscuring the lower corners of the screen when the player character was down there and I was in need of some finer movement.

I ditched the idea.

Option 3 was actually fairly similar to option 1 but with greater scope.

I switched the phone off and just touched the screen. I played the imaginary game and tried to feel for what was right.

As I moved my thumb around I realised that the kind of control I was after was in fact quite similar to option 1. But I wanted the d-pad to be positioned based upon where I first tapped the screen. A kind of user-definable d-pad location.

So I set about creating a sequence that went something like:

touchStart: record the centre of the d-pad co-ordinates

touchMove: throw the event at a d-pad handler and update touch x and y

With the centre of the d-pad recorded as my origin I then needed to figure out how the co-ordinates of touchMove translated in to a new direction for the player.

Something like..

There are some complications here.

Imagine that the finger is swiping to the right from an origin of say 128,128.

As the touchMove event continues to fire the x is incrementing through 129, 130, 131 and this is great. I’m clearly looking to move to the right.

But then my thumb flicks up or down the slightest amount.

My y value is also incrementing 128,129,130,131…

So which is true ?

Does the player want to move right or down ?

I’m actually still working this bit out and will blog about it once I’ve got it working.

Overall the movement is fairly smooth just now and I’m working hard to make it as smooth as possible.

User feedback and a logical touch interface is vital in these games. If you mess this bit up you kill the entire game and your player will just go looking for something else to play.

Other things that I’m curious about are walking DOWN a corridor, effectively “hugging” the wall to turn RIGHT or LEFT at the next available exit.

To this end I’ve played Pac-Man quite a bit just lately and learned some valuable design lessons.

I’m also mucking about setting touch.testx and touch.testy in an attempt to sniff the wall for available exits.

Actually this code works pretty good right now.

When there is more to see I will return to this subject.

Thanks for listening to me waffle

Please feel free to share your own thoughts, ideas words of wisdom on the subject.(source:spacemonsters)

→如果您认为本词条还有待完善,请 编辑词条

词条内容仅供参考,如果您需要解决具体问题
(尤其在法律、医学等领域),建议您咨询相关领域专业人士。
0

标签: 玩家触屏移动控制方式

收藏到: Favorites  

同义词: 暂无同义词

关于本词条的评论 (共0条)发表评论>>

对词条发表评论

评论长度最大为200个字符。