英语原文共 8 页，剩余内容已隐藏，支付完成后下载完整资料
2014年巴西电脑游戏和数字娱乐研讨会
移动HTML5多人游戏门户网站为例
摘要：本文主要关注有竞争力的实时多人游戏和游戏化的环境来研究移动HTML5游戏门户网站的设计和开发过程，来激励游戏间玩家的竞争力。这个项目涉及了几个复杂的元素，其中包括门户网站需要兼容最主要的移动和桌面浏览器和具备必需的游戏优化，目的是游戏在移动设备上可以拥有一个良好的性能。另一个重要元素是一个可访问的匹配服务，使开发人员能够轻松地集成他们的多人游戏门户，缓解他们创建创建和管理的比赛相关的逻辑，以及胜利和失败的逻辑的需求。为了进行个案研究，一共开发了四个不同类型的游戏，这些游戏都提供了对应的技术支持，同时收集与用户行为有关的几个指标。通对这些指标的分析可以让更好地了解玩家如何被门户网站吸引并且如何改善它。
开发过程和工具：移动计算
1. 介绍
本文详细介绍了称之为bighub的门户的发展，可访问http://bighub.me。
本文的写作动机--两个主要的原因：主要应用商店的停滞，这些应用商店的玩家主体已经确定，而在很长一段时间内没有改变。和html5游戏门户网站的持续增长，这对于游戏开发者来说提供了他们设计游戏视图和游戏模式的替代途径。
现在的许多试图将游戏发布到现有的应用程序商店的开发人员都受到这种停滞的影响:自从大玩家入驻并且他们的产品有一个更高的LTV（生命周期价值）以来，比LTV小的开发商，他们的UA（用户获取）价值高，这使得LTV小的开发商在竞争中需要相对努力。此外，苹果推广体系无法与大玩家为了推广自己的游戏所使用的许多现有的广告网络竞争。
移动网络是一个规避UA成本的吸引人的选择，因为它适合相对于APP的广告费用较低的网络广告成本.此外，移动门户网站与游戏产业相关，通常比一个单一的游戏有更多的增长潜力，特别是因为它们通常是由一个相当大的游戏目录构成的。图1显示了20大游戏门户网站和他们所拥有的庞大用户量，值得一提的是，超过一半游戏门户网址是兼容移动的。
Html5是一个兼容移动网络的技术，它允许开发者通过移动网络向用户提供丰富的内容，
换句话说，用户无需为了开始使用一个大的应用程序，而等待下载它，他们只需要通过移动浏览器打开它。
本文介绍了游戏的社交手机游戏化门户的发展。其在社交方面被定义为一个社会互动网络和个人关系网，这对于门户的范畴意味着玩家可以挑战他们的朋友和他们玩。这一发展的主体过程包括描述的以下6个部分：发现问题并提出解决方案，其中包括技术和市场问题和团队的解决办法；开发的方法，涵盖了开发团队如何进行项目开发；软件体系结构，基础设施开发和部署过程；分析，一般最后的产品分析及结论与未来工作。
图1.1 全球排名前20的游戏门户模型
2. 问题和建议的解决方案
据莫雷拉等，“在收购阶段解决开发者如何能够接触到用户，和获得玩家。它具备的功能，使游戏社会化和病毒化。在保留阶段关注如何保持游戏中的玩家，一旦，他们被吸引。具体而言，它涉及这样的功能，使游戏有粘性，或能使人成瘾，并且与游戏机制和在游戏化的动力学密切相关。最后阶段，货币化，根据移动游戏中使用的功能，以从他们的用户中获取收入。该项目应为玩家购买虚拟物品提供激励，“这个项目的主要目标是对异步响应方式的获取和保留。收购的问题是减轻推广介绍，由于与本地应用程序相比，移动网络的用户代理成本降低。
另一方面，存留的问题要求项目上的改变。作者认为游戏的保留部分必须经历一个周期的3个步骤，图2说明了这个周期：操作，奖励和扩展。在操作步骤，用户可以简单的操作，例如播放游戏会话，或在游戏中拜访好友。每一个操作都以得到奖励为结果，并在执行操作和获得足够的奖励后，玩家应有一个大的进展，称为扩展。在门户，行动被认为是玩家与另外一个玩家打一场的行为，在每场比赛后玩家的化身，收益经验和在获得足够的经验后，玩家将上升一个等级，也有可能被授予更高的等级。
社会互动是另一种提高玩家参与度的工具。基于这个目的，使用了社交网络脸谱网的功能，特别是喜好和分享的社交行动，这是一个玩家赢得比赛后所展现的。因为所有门户中的游戏都是实时的多人游戏，这是一种有效提高参与度和进行病毒式传播的方式。
除了先前设计的旨在处理一些异步响应方式方面问题的解决方案，也有一些相关的技术约束了与移动门户网站的交互。一些确定的问题是：
- 无论是宽高比还是分辨率，都需要在市场上大多数的移动设备良好运行
- 整个门户（所占内存）需要很小，所以它可以在通常不提供非常可靠的服务的移动运营商网络上快速下载
- 通常是游戏客户端和游戏服务器间的信息交换是一个相当大的延迟。这是移动运营商网络的不可靠性导致的
纵横比被定义为宽度和高度之间的几何比例。在移动应用程序，当两家相同的纵横比的设备有不同的大小时，开发人员通常可以使用一个相对比较简单的操作使他们的应用程序适应两个设备。然而，当这个问题在多个方面都有涉及时并不是很容易解决。
参与这个项目的团队以前有相当多游戏开发经验，并且在以前的情况下处理这一问题，解决方案是和Scaleform使用的方法类似的。
图2.1 游戏中的保留周期
在此类型的门户中数据优化是一个非功能性的要求。对于这个问题，该小组不能提出一个明确的解决方案，但它决定了普遍的做法应该是图像的一个频繁减少和优化。
延迟不是团队能够解决的一种问题，，因为它是一个用户网络基础设施的问题。该解决方案是设计所有的游戏，使他们不要求在比赛中的玩家之间有一个准确的的同步。
3.工具
在这一节中，分析在开发过程中所使用的工具和技术。这一分析分为：
- 原型法——用于原型测试和项目验证的工具
- 管理——用于团队管理和版本控制的工具
- 前端——客户端逻辑上的使用的技术和工具，包括适应性强的接口和指标跟踪
- 后台一服务器端逻辑上使用的技术和工具，包括客户端的通信和一个大厅系统，让玩家可以参与比赛。
- 游戏——创建多人游戏使用的技术和工具
3.1 原型法
在开始项目开发的任何步骤之前，项目页面以使用邮局协议为原型,当提高项目评估和规划时，这一步对于使整个团队的产品在视觉上一体化和并缩小空间是至关重要的。
因此，原型由以下页面组成：登录、主页、大堂、创建空间、游戏、社交活动，赢，输，平局和人物简介。这些页面的每一个由传输流实现。
3.2 管理
正如在发展方法论部分上所看到的，这个项目是在一个非常短的开发时间用分布式的方式开发的。鉴于这种情况，有必要使用灵活和有效的开发周期，以及一个直截了当的任务控制和版本控制解决方案。
至于团队管理，使用了Trello。Trello允许创建实体名片，这些名片可以有几个类别，如必须完成的任务，正在进行的任务或已完成的任务。这使得创建任务和项目进程的可视化更加可感。
所有的任务是通过使用一个变化的Scrum 来进行规划，而这一规划的结果是Trello上的各种任务卡，每一个都有自己的优先级。
用于此项目的版本控制技术是git,使用bitbucket来进行存储服务。在其他版本控制中选择了Git是因为它十分适合用一套灵活的方法进行分布式开发流程：分支的创建使团队致力实现于不同的特性，同时不影响现有的功能，并且产品部署也变成了一个足够简单的过程，它可以依据频繁变动的成分而确定。
这些技术的结合提供了一个非常灵活和动态的开发环境，这使更快速的生产和部署的功能的实现，同时也使团队能够快速响应报告中门户的问题。
3.3 前台
团队对于前台的开发没有先前的经验，因此在开发的过程中需要研究，测试和以一定频率改变技术和工具。在第一次迭代中，该团队选择使用Phone.JS作为html5框架和Angular.JS作为 MVVM（模型—视图视图模型）框架。Html5框架帮助实现界面流程、布局和用户页面的开发。另一方面，一个MVVM框架通过动态绑定和数据更新有助于用户界面响应和灵活的变化的动态网页的开发。
phone.js为每个移动平台一一即iOS、Android、黑莓和Windows Phone实现本地设备的移动接口，第一眼看来Angular.JS很有前途，似乎是一个不错的选择，它是由谷歌团队维护。然而，一旦前端开发人员发现对于Knockout.JS的文档编辑比Phone.JS更彻底，社会团体比Angular.JS更活跃。所以团队提出了变更为Knockout，并被接受。
该团队开发了门户网站的第一个版本，极具特色并且与第三方游戏的结合来使其有效。但经过一些性能测试，注意到它通过移动网络运营商加载初始页面的平均时间为1.32分钟，
这使产品不可行，因为大多数用户会退出门户网站在加载完它之前。于是团队对html5的其他框架做了一个简单的性能测试，并得到了几个加载时间，表现得最好的一个是jQueryMobile, 以平均0.2分钟加载一个网页，比phone.js快了近5倍。此外，该团队认为用与Phone.JS关联的非标准本地接口来创建一个的游戏化环境是不可能的，所以将html5框架变更为jQueryMobile。
通过框架提供的默认接口元素，利用jQueryMobile开发一个页面后，为了达到预期门户的外观和感觉，团队需要覆盖jQueryMobile大部分的本地组件。图3通过这些工具的变化和项目的里程碑说明了设计上的演变。
图3.1 开发过程中的界面演化
同时，前端负责跟踪分析数据。该团队与谷歌分析有广泛的以前项目经验，所以唯一的挑战是学习使用JavaScript的版本，但为了了解已经知道的用户行为，可以提取所有概念和主要指标。
3.4 后台
可扩展性是服务器基础设施中存在的主要问题之一。
为了保持门户的可扩展性，使用了云计算服务，这样一来，门户网站所需的计算能力将随项目成本的增加而增强。开发团队以前与谷歌应用引擎有团队经验，所以选择其作为这个项目的平台。
至于社会整合，为了实现使用的病毒化行动，将restFB集成在后端。
由于病毒化行为需要几次呼叫脸谱网服务，它会需要太多的带宽来从客户端发送这些呼叫，所以在服务器上集成它这样就可以节省在客户机上使用的大量带宽。
客户端和服务器之间的所有通信都是通过 Jersey API,一个RESTfuI应用程序接口使得所有小程序的生成过程对开发商来说是透明的，从而使开发商把重点放在功能的开发。
使用ChannelAPI来创建游戏室，谷歌应用程序引擎功能，这使得它可以打开一个被几个用户收听的接口。以下协议用于匹配在线用户：
玩家1在大堂页面中创建一个房间：创建了一个相关的通道，用户保持收听服务器发送的任何事件。
玩家2打开大堂：显示了等待挑战者的所有通道列表。
玩家1打开玩家2的房间：玩家2加入玩家1的频道并发送消息通知他已准备好比赛了。
这个过程结束后，玩家之间的游戏开始。
3.5 游戏
门户游戏开发的本能一要容易理解力学的游戏，允许快速连接，——导致选择无论是在下载大小和性能都提供了一个最小的引擎占用空间的轻量化技术。最初选择Cocos2d-JS作为游戏引擎，虽然它是一个非常强大和灵活的引擎，开发团队选择了 Phaser Engine——一个具备快速简单开发渠道的轻量级html5游戏引擎。这个选择主要是基于它的渠道与Flixel 引擎非常相似的事实,该团队以往有关于Flixel 引擎的经验。
鉴于所有的游戏都对多人比赛有相当大的关注，有必要使用在台式电脑浏览器和最主要的移动浏览器都运行良好同时还提供最低连接开销的通信技术。而团队最初选择Photon为网络逻辑是因为它的中间设备有良好的市场，截至本文的写作，该设备显示了它JavaScript变量文件的缺少。团队转而选择使用Nodejs ，因为它提供了一个有效的网络接口连接。游戏服务器托管在Heroku 网页寄存服务，它提供了一个从开发到调度的具有易于扩展的服务的便捷通道。
客户端浏览器和托管在Heroku上服务器之间的通信协议是通过网络接口连接建立的。给定多人游戏性质的游戏，服务器存储由几对客户端-服务器连接构成的几场比赛。一旦一场比赛的两个连接被切断，它被从服务器删除。
网络接口连接允许客户端和服务器之间的实时通信，所使用的通信协议包括信息交换与回应：客户端向与操作有关的服务器发送消息和一个包含与游戏有关的任何信息的数据包——如玩家的输入或动作和服务器处理客户端消息如何影响游戏的过程。在服务器上进行处理操作后，它发送回消息给客户端，根据游戏逻辑解释消息，使游戏重新开始并允许它再次发送消息到服务器。
4.开发方法
这个项目采用了Scrum中适合于团队局限性一套好的做法——即很短的开发时间的远程分布式工作流。所有项目干系人集思广益适合于他们局限性、开发方式和过程愿景的开发的替代品，生产过程得出了以下结论：
周三规划/会议：团队总是在周三亲自会面谈论他们做了什么和讨论下一个冲刺。
一天冲刺时间：团队中的每一个人需要做所有分配给他们的任务，整合到项目库，在一天结束时展现一个稳定的经测试的版本。小组的每个成员都可以自由决定他们工作的时间和如何完成工作，但星期六是选定的要完成工作的一天。
外包：提高团队对软件开发和减少项目管理成本的关注，所有与编程非直接相关的任务是外包的，包括艺术，游戏设计与制作。
该团队还决定使用Trello作为项目管理工具，主要是因为它的简单性。
<p
剩余内容已隐藏，支付完成后下载完整资料</p
资料编号：[150460]，资料为PDF文档或Word文档，PDF文档可免费转换为Word
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
