当前位置： >
> 美团王兴：互联网让资源得到更好的利用
美团王兴：互联网让资源得到更好的利用
/&&日08:57&&来源： 新浪科技
　　美团网创始人兼CEO王兴
　　新浪科技讯1月18日上午消息，在极客公园创新大会上，美团网创始人兼CEO王兴在现场做了题为《资源的革命：互联网改变了商业的什么》的主题演讲。
　　王兴认为，互联网会彻底改变一切行业，但这种改变并非一定从最底层进行。用互联网的方法提升资源的使用率，将会带来很大的商业价值。
　　王兴以汽车为例，论述了互联网如何在重组资源中蕴藏巨大的商业机会。王兴称，根据调查，一辆汽车自从生产出来，95%时间处于闲置状态，2.5%时间是正常驾驶，还有部分时间是在找停车位或者是堵在路上。一辆车制造和消费过程中存在很大的资源浪费。而人们对汽车的需求很大程度上是更舒适快捷的从A点到达B点，因此现在开始流行了互联网互享经济。
　　互联网对汽车行业等的改变，并非只是要制造出互联网汽车，而是在导航路线、寻找停车场等这些层面上，与本身的技术无关。互联网能做的是在不能替代现实资源的情况下，提供辅助，让资源得到更好的利用。美团网就在做这样的事情。(天涯)
　　以下为演讲全文：
　　刚才听了Ray Kurzweil非常精彩的演讲，多数人知道他是从《奇点临界》这本书，但是今天我想跟大家介绍一本让我非常有收获的书，它的名字叫《资源革命》，这本书让我从另一个角度思考我们过去几年做美团网以及看互联网的很多事情。
　　美团是一家非常年轻的公司，到现在不到5年的时间，从这个角度回头看过去的4年发生了很多事情，我们经历很大的指数增长，去年做到460亿的交易规模，积累2亿多的手机用户，我们在很多细分领域做得不错，但是《资源革命》提供不同的角度让我思考这件事情。
　　给大家举一个电影院的例子，电影在过去几年经历非常快速的发展，票房每年百分之三十几年的发展，建了很多电影院，全国2013年底大概4600家，2014年全国变成5600家电影院，增加了22%的电影院，这是在资源供给。但是在资源需求这一端，从全国票房来看到2014年比2013年增长了36%。这两个差别是什么？差别背后是什么东西？
　　现在互联网美团可以很方便的定票，但是这背后有一个很重要的事情，就是整体的资源使用率提升了，供给增加22%，需求或者消费增加了36%，这里有很大的一点是资源的使用效率提升了。而资源的使用效率提升一个重要的前提，就是之前的资源使用率非常的低，大家可能不知道，全国的电影院虽然现在生意越来越好，但是总体的上座率只有15%左右。大家现在去看，除非是《变形金钢》最热闹的电影最黄金的时段诸位会买，但是电影院通常是空着的，全国算下来电影院的上座率只有15%，所以这里是有多么巨大的资源的浪费。
　　建一个电影院需要很大的空间，需要几层楼和设施以及幕布，资源投进去消耗很多，但是资源使用率非常低，全国电影平均上座率只有15%。经济学上这些事情之前的资源投入都是固定成本，多卖一张票、多去一个人看电影这个边际成本增加那一小部分是非常小的，所以我们能用各种方法，不管是美团还是别人来干，不管用互联网方法还是非互联网方法提升资源边界使用率，因为边际成本上升非常小，票价可以下降，但是总的产出可以增加很多。以电影为例，传统模式下面资源使用率非常低，所以如果你能够用各种方法包括互联网的方法大幅度提高资源使用率的话能够带来商业上的价值，对用户端的价值，对商户端的价值。
　　电影是比较小的例子，这里面15%的资源使用率已经让人非常惊讶、效率非常低。但是我想举一个更夸张的例子，汽车，过去一年、两年电动汽车非常火，过去几年北京的雾霾问题非常严重，PM2.5非常令人讨厌，而且PM2.5一部分大家认为是汽车尾气排放导致的，有些人认为如果能够把一部分汽车减少污染排放或者把内燃汽车变成电动车就可以解决很多问题，这当然是一部分。但是很有趣的是我们看整个汽车行业的时候有可能最大的变革机会并不在汽车本身，不在于它是烧油还是用电池，而是在另一个更宏观的层面，也就是资源使用率的层面。
　　中国没有数据，但是美国有数据，汽车使用率比电影院的使用率还要更低，按照美国的统计，一辆车生产出来消耗那么多钢材、橡胶、塑料、玻璃，是消耗多自然资源，生产过程中要消耗非常多的能源，产生非常多的污染。就算我们把所有的汽油车、柴油车都换车电动车，生产过程中还是消耗非常多的资源，所以换成电动车可能有改进，但是改进是相对有限，把汽车尾气排放污染换成了煤发电的污染。
　　但是这里有另外一个很大的机会，可能不是在最底层的发动机层面而是资源使用率的层面，美国的数据是一辆车从生产出来95%的时间被停车，只有5%在开，这5%里面再细分，只有2.5%是正常速度驾驶的，另外0.8%大概是在找停车位，这是差别很大的。正常驾驶的话你不用反复踩刹车、油门、加速，但是找车位的时间耗掉0.8%，另外0.5%是堵在路上的。所以总共只有不到5%，4%的使用率，真正有效使用的是2.5%，其中0.5和0.8%一个用于找停车位，一个用于堵在路上。这里有巨大的提升机会，举个例子，找停车位反复绕这个事情，如果人工智能、智能驾驶有很大的进展，它不是汽车科技的进展，它跟钢铁、发动机没有关系，但是如果人工智能自动驾驶有进展，你就不需要花费百分之零点几的时间找停车位，汽车可以少开很多路，可以少产生很多污染，不管汽油、柴油还是电池。
　　另外，如果车上交通堵塞都没有的话我们可以再节省百分之零点几，变革技术不是汽车本身的技术，跟轮胎、方向盘、发动机完全没有关系，它需要的是更高层面的组织形式。如果车都联网了，如果位置信息都在中央系统有了，大家可以调度每个红绿灯、十字路口的车流和车的速度就不会堵塞了。堵塞是因为每个人在独立做决策，如果你把决策汇集到系统，能够很好的调度整个车群，那么交通堵塞就会少很多。即使不需要换电池车，只要车均匀匀速行使，你可以更少时间达到目的地，但是你消耗的能源产生的污染就会非常多。这里最大的变革机会不是汽车技术的本身，而是组织形式，那种组织形式是有可能极大提升资源使用率的。
　　这多么可怕，一辆车95%的时间是停着的，如果这些都解决了，堵车的时间少了、停车的时间少了，但是还有95%的时间停在那里，所以人们也许不需要拥有这辆车，只需要拥有资源，才会有互联网上非常火的共享经济。一辆车造出来寿命是十来年的时间，95%都停在那里它不创造价值，所以从所有权和使用权分离的层面能够改变车的使用模式，另一个层面能够减少对资源的消耗。人们少数目的是为了拥有车进行炫耀，多数是舒适方便的从一个点到另外一个点。
　　这些事情它有可能发生，发生之后产生很大的商业价值、很大的社会价值，但是它并不是在最底层的方面。我刚才举了两个例子，一个是电影院的例子，一个是汽车的例子，这里面有很大的变革机会，而且似乎最大的变革机会并不在最底层的汽车技术那因。
　　这是我想讲的意思，我认为互联网它能带来巨大的价值，互联网可能会很根本的很彻底的改变所有行业，但是这个根本的彻底的改变望望不一定发生在最底层。就像大家讨论互联网汽车，可能最大的机会并不是在造车本身，并不是在造一辆更好的汽油车，也不是在把汽油车换成电动车，而是在怎么样自动驾驶，怎么样协同减少堵塞，怎么样用商业模式减少需要车的数量，让大家达到同样的目的需要更少的资源、需要更少的车。这里的数字大家可以看到机会是不一样的，所以互联网做得好了以后它会从根本上改变车这个行业，但并不是最底层的改变。
　　极客公园的活动，很多人认为极客喜欢科技，但是事情最大的价值可能并不见得在最底层的技术上面，因为一个时代的进步它需要科技的变革、需要新科技，可能需要新的商业模式、需要新的组织模式，而且有的时候新的商业模式和新的组织模式很可能比底层的新科技本身创造更大的价值。
　　我举另一个例子，我们从另一个角度理解这个事情，并不是你做的事情不底层就LOW了。科学方面分很多，有物理、化学、生物、社会学、经济学、心理学，如果你从最底层想的话这些事情都是回到物理上面，就那么几个基本的物理原理，如果足够大的计算机模型是不是就不需要化学了？因为你能准确计算出原子、点子的运动，因为化学是基于物理的，你只要知道底层的物理原理，你有足够大的计算能力就能够把化学反应计算出来。我们需要生物吗？除非你承认有超自然力量存在，否则某一个生物体就是化学的生化反应最后形成生物学，理论上确实是这样的，你把物理搞明白了，你把化学生化搞明白了，你有足够大的计算机，有无穷的计算能力，你确实能够把每一个动物体最高的行为做出来。有了个体的行为包括人的行为之后，你知道他的心理和生理之后我们还需要社会学吗？需要经济学吗？从某种角度来说不需要。你计算群体行为就有社会学、经济学了。但事实上人类社会并不是这么组织的，所以我们需要不同层面的东西，我们需要有人研究物理，需要有人研究化学、生物学、心理学、社会学、经济学各方面的东西，而且这些科学遇到的绝对挑战就是创造的价值不见得比解决最底层的问题更小。
　　今天我们在互联网上碰到类似的问题或者类似的机会，我始终相信互联网会改变一切，凡是一切没有被互联网改变的行业都即将被互联网改变，但是这个改变是根本、是彻底，但不一定是最底层的。例如互联网对农业的改变，互联网对食品、对餐饮的改变，互联网对汽车的改变，它并不是改变你种的稻子，或者改变餐饮不是改变菜的好坏，造车也是这样的。无数例子证明互联网会改变很多东西，这个改变是非常彻底、非常根本的，但是很可能不是从最底层的，而且它也不需要从最底层。
　　世界分成原子和信息两个部分，原子是物质单位，比特是信息单位，互联网一个是用移动比特代替移动原子，一个用移动比特辅助移动原子。信息本身就是目的，你看一个视频或者读一个电子书，你需要不的不是那些介质，你需要的是信息。以前印书需要伐木、造纸、印刷，把它输送到你的手里去。一开始出现的时候互联网卖书，亚马逊、当当它是用移动比特辅助移动原子，你不用跑到书店去买书了，你直接网上把书寄到后面就好了。进展到后面，你根本不需要那个书了，你有电子书以后可以把书传过来，代替了移动原子。
　　互联网还有很多方面，包括美团所从事的不是移动比特代替移动原子的事情，我们干的是移动比特辅助移动原子的事情。因为不管互联网如何发达、网速如何快、手机CPU如何高、屏幕如何好，它都不能代替你咀嚼一块牛肉或者按摩时候舒服的感觉。但是这里面有用移动比特辅助移动原子的机会，就像美团干的事情，例如电影院已经建好了，资源已经消耗了，我们怎么样让大家能省钱省心买到更便宜的票、看到更好的电影，你还需要去电影院。
　　在餐饮方面更是如此，如果电影的将来很有可能被网络视频部分替代的话，餐饮在很长时间是看不到的，因为你最终还是需要吃饭，这里面物质无法取代，信息无法取代物质。但是你可以用移动比特辅助移动原子，让大家找到更好的餐馆，知道点什么菜更好，得到更好的折扣或者更好的服务。或者另一方面改变移动原子的方向，像美团一开始帮你找餐馆，后面你不想出去可以外卖送过来。一个专门送外卖跑腿送食物的速度效率是高于你自己的，你自己开车坐地铁去一个地方可能很零散，不如用外卖的方式，一个更系统组织的方式把食物送到你面前。同样达成食物的消费者吃东西的人和食物在一起，换一个组织模式效率更高，对资源消耗率更少，总体资源使用率更高以后商业发生变化，互联网带来的变化很可能是规模非常大的非常彻底非常根本的变化，但是它不需要是最底层的变化，也可能不是最底层的变化。
　　这是今天我所分享的。
【】【】【】【】
「关键字」
& &（1）所有因使用生意场而引致之任何意外、疏忽、合约毁坏、诽谤、版权或知识 产权侵犯及其所造成的各种损失（包括因下载而感染电脑病毒），生意场概不负责，亦不承担任何法律责任。
& &（2）任何透过生意场网页而链接及得到之资讯、产品及服务，生意场概不负责，亦不负任何法律责任。
& &（3）生意场内所有内容并不反映任何生意场之意见及观点。
& &（4）生意场认为，一切网民在进入生意场主页及各层页面时已经仔细看过本条款并完全同意。 敬请谅解。
(生意场讯)比特币再次令香港投资者“损手烂脚”：香港一个比特币支付平台近日突然结业，估计近3000名比特币投资者随时可能血本无归。据悉，一批香港比特币投资者到访有关交易平台的办公室时，发现已人去楼空，疑涉及
热评文章排行
1 2 3 4 5 6 7 8 9
1 2 3 4 5 6 7 8 9
& 生意场 版权所有角色访问控制在列车移动补票系统中的应用_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
评价文档：
72页¥80.006页¥2.0012页免费7页¥3.001页¥0.503页¥2.003页¥1.006页免费20页5下载券4页免费
喜欢此文档的还喜欢167页免费7页1下载券124页免费43页免费9页5下载券
角色访问控制在列车移动补票系统中的应用|
把文档贴到Blog、BBS或个人站等：
普通尺寸(450*500pix)
较大尺寸(630*500pix)
你可能喜欢演示如何设置玩家触屏移动控制方式
发布时间： 16:47:19
作者：Mark
今天我花了很多的时间在触屏界面上尝试一款全新的游戏。这是一款迷宫游戏，其执行方式与《吃豆人》类似，但是内容却完全不同。
当我开始创造这款游戏的玩家精灵行为代码时，我知道自己将面对一个困难的决定，它与游戏的移动控制方式有关。
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);
window.addEventListener(‘touchmove’, touchMove, false);
window.addEventListener(‘touchstart’, touchStart, false);
window.addEventListener(‘touchend’, touchEnd, false);
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 typeof d.ontouchmove == “function” ? true : };
我在此执行了一个基本的测试去判断触屏是否是一种有效的功能，如果不是的话我是否应该重新选择鼠标控制功能。如果你过去曾经在台式机上玩过我的游戏，你肯定都会看到一行“无碰触功能”的提示。
而这里的重点是，我们实现了通过碰触而开始游戏，移动角色并完成游戏的过程。这是一种非常强大的功能，让我们能够在控制游戏时能够拥有更多选择。
我们该如何利用这种碰触控制？
其实非常简单。我只需要在每次碰触事件发生时保存下碰触对象的坐标值即可。如下：
var touch = {}; function touchStart(event) {
var xy = getXY(event.touches[0]);
touch.startx = xy.x;
touch.starty = xy.y; };
function getXY(event) {
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));
write(“getXY: ” + e.message);
我在try/catch中涵括了大部分的函数。并只是假装调用了touchStar()函数。
所以这些代码的意思也是一目了然。回到只列出横坐标和纵坐标参数的对象，在此我能够控制玩家的移动。你们应该会注意到我在这里使用了offsets以表明玩家的真正位置——因为我将文件中心的游戏场景边距设为“0px auto”以及320px的宽度。如果换成是桌面游戏这便是问题所在，但是因为在手机平台上我们是通过视口去处理显示器，所以就不会出现桌面游戏所面临的问题。
现在我已经获得了一些坐标值，所以我可以开始研究控制玩家的一些选择了。
我的这款迷宫游戏中布满了许多蜿蜒崎岖的道路，我希望玩家能够在此避开各种怪物并收集各种奖励而前进。当然不止这些内容了，不过因为想到玩家能够控制自己的角色移动我就有了继续前进的动力。
第一种选择便是设置虚拟方向键。玩家将能够清楚地看到这一控制方法，并也会因此感觉到不自然。这种方向键总是设置在屏幕下方的角落里，从而玩家就必须憋屈地在一小块空间中控制游戏的进行。
我创造了一个简单的方向键，并将其设置在屏幕的右下方角落中。然后我编写了一些代码去追踪玩家会按压方向键的哪一边，随后在手机上加载游戏并更新游戏。
（注：我的横坐标/纵坐标检测代码非常简单。我只需要在屏幕上检查碰触事件是否被记录在与方向键图表相同的位置即可。）
总而言之，如果使用这种方法玩家就必须投入一半的时间着眼于方向键的操作，而没有多余的时间去观看自己的角色是如何在迷宫中移动。
所以我立刻就放弃了这一选择。
第二种选择便是在游戏屏幕的最上方，最右边，最下方以及最左边添加箭头图标。
这一理念听起来是合理的。因为我将让玩家碰触屏幕上一些较大的领域而朝上，右，下，左四个方向移动角色。
我将再次在手机上加载并更新游戏。
一开始这种设置是合理的。我能够顺利地移动角色并且在角色的移动过程中也拥有更多的灵活空间。
但是很快地我也感到厌烦了，因为当角色移动到屏幕下方时我的手指可能会遮住下面的空间，从而需要寻找其它更好的移动方式。
所以我也抛弃了这一方法。
第三种选择与第一种选择类似，但是却扩大了玩家的控制范围。
我尝试着关掉手机并去碰触屏幕，想象着自己在玩一款游戏，以此感受怎样的设置才是真正合理的。
当我在屏幕上移动着自己的手指时我意识到自己所追求的控制方式其实与第一种方法相类似。但是我希望方向键能够设置在我第一次碰触到屏幕的位置（游戏邦注：也就是用户可以自定义方向键的位置）。
所以我便开始着手创造一个续发事件，如下：
touchStar：记录方向键坐标的中心位置
touchMouve：让方向键处理器去处理事件并更新碰触对象的横坐标以及纵坐标
如此记录下来的方向键中心位置便是玩家的初始位置，而我接下来便需要思考如何将touchMove的坐标转变为玩家需要面对的新方向。
if (touch.newx & touch.startx)
但是这里也存在一些问题。
想象手指从初始位置的128，128点处开始向右移动。
随着touchMouve事件持续得到激活，横坐标的值将如预期那样开始往上增值（即129，130，131……）。而我也可以清楚地看到角色正在向右移动。
但是当我的拇指轻轻地碰触了屏幕时，我的纵坐标值也会从128开始往上攀升。
所以到底哪个方向才是对的？玩家是想要向右移动还是向下移动？
在这类型游戏中用户反馈和合理的碰触界面都至关重要。如果你不能处理好这些因素，也就等于扼杀了你自己的游戏，而你的玩家也将不再对游戏感兴趣。
我还对一个问题充满疑惑，也就是当角色沿着过道前行并碰触到一面墙时，他应该向右转还是向左转才能前往下一个通道。为了解决这个疑惑我玩了许多遍《吃豆人》，并在此获得了许多有价值的设计经验。并且为了能够创造出最合理的出口我也尝试着设置了touch.testx和touch.testy。并且这些代码也都能够有序地运行着。
游戏邦注：原文发表于日，所涉事件及数据以当时为准。（本文为游戏邦/编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）
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 320 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.()
CopyRight Since 2010 GamerBoom All rights reserved &&闽ICP备&号-1