英语原文共 6 页
2018年第22届系统理论，控制与计算国际会议（ICSTCC）
基于Android的分布式社交游戏系统的编程设计和面向对象开发范例
Sebastian Sbicirc;rnă, Liana Simona Sbicirc;rnă
摘要:本文阐述了开发基于android的在线回合制社交游戏应用程序的机制、编程设计选择和范例。详细介绍了编程过程中的每个步骤，并使用模型-视图-控制器体系结构模式解释了不同模块的底层实现概念和原因。在开发阶段的每个阶段，对软件工程设计选择进行比较和举例说明，给出了改进这种分布式服务背后的逻辑的建议。本文还简要介绍了使用在线云数据库（来自Google的Firebase）的使用情况，以便使用JSON格式实时处理玩家数据。
关键词:面向对象编程，Android, Java, MVC，开发范例，分布式系统，社交游戏
一、引言
在当今世界，技术在人们的生活中起着主导作用。现在，人类已经习惯了与生活在遥远的地方(有时是在地球的两端)的人们之间有同步的语言联系，而且，随着互联网的使用，人们也可以发短信或看到对方，这就有可能让他们觉得他们会在一起。
尽管有这些令人难以置信的机会，许多联系仍然在减弱，甚至正在失去。在一个理想的世界里，下一个步骤就是人们不仅仅是通过长时间的交谈来保持联系，而且甚至是通过仅仅需要几分钟的宝贵时间的活动。
我们思考的背后的想法是，通过使用大多数时间与用户的技术，并提供快速的用户设备交互[4]，可以很好地缓解“冷关系”。在这方面操作最多的工具是智能手机[5]。
这篇研究论文的目标是展示在创造一款游戏背后的理念和发现，这款游戏可以作为人与人之间的互动元素，而不是物理上的亲近;一款社交游戏旨在促进人与人之间的交流，而不是取代它。
二、产品描述
我们的应用程序旨在将棋盘游戏(如蛇和梯子)与社交游戏相结合，(如:2018年6月3日接收的文稿。
S. Sbicirc;rnă与哥本哈根奥尔堡大学的技术与设计技术学院（创新通信技术和创业学院的学生 - “ICTE”）合作，15 A.C. 丹麦MeyersVaelig;nge街。
L. S. Sbicirc;rnă是克拉约瓦大学科学系（化学系），克拉约瓦卡利奥斯布卡雷斯蒂街107号。 “真相还是挑战”，“我从来没有hellip;hellip;”)，即每一款游戏将有两名玩家，在不同的设备上玩游戏，当他们在棋盘上前进时，彼此交换图片、视频和信息。为此，我们使用与每个客户机通信的服务器，该服务器能够在必要时存储和交换数据。
为了保存所有关于用户和他们的游戏的信息，我们将他们保存在一个在线数据库中，这样就可以实时检索数据，从而让两个用户在玩游戏时不会有很大的数据交换延迟。对于这样一个数据库，有很多可能的解决方案，但是我们决定使用来自Google的Firebase[1]，因为它是一个基于云的解决方案，有一个在线平台，允许多个用户同时连接，以保存或检索信息[1]。由于我们的应用程序也需要存储照片，因此将在线数据库与“Firebase Storage”集成是一个适合我们实现的解决方案。我们的数据库结构的快照如图1所示。
图1。Firebase数据库web接口的快照，以JSON键值格式显示变量的结构和值
三、功能的实现
本章旨在详细介绍在应用程序实现中使用的与android兼容的核心思想和方法。本章将分为两个主要部分，分别对应于两个主要的开发阶段:“通用功能”实现阶段和“游戏性与测试”实现阶段。它们之间的主要区别在于编程任务的重点。
A.“一般特征”发展阶段
在下面的段落中，将介绍对游戏执行流程的指导性见解，以便本文的读者能够清楚地了解我们想要实现的编码方法。 应用程序的逻辑流应该以这种方式运行：
用户第一次启动应用程序或者应用程序从内存中删除并需要重新启动时，用户会看到一个登录屏幕，其中可以输入其电子邮件和密码以便在线连接到我们的数据库并检索其所有数据。在屏幕上，有一个“登录”，一个“创建帐户”和一个“忘记密码”按钮。如果用户还没有帐户，他/她可以按“创建帐户”进行注册，其中将要求他/她输入所需的用户名，有效的电子邮件和密码。然后，应用程序继续为每个新创建的播放器生成随机唯一UUID，以在数据库中拥有自己的空间。
然后将用户重定向到应用程序的主屏幕，也称为“游戏列表”屏幕。 在这里，用户可以以详细和有序的方式看到他正在玩的所有当前游戏。 通过查看每个游戏旁边按钮上的文字，人们总能知道他的回合已到达哪个游戏：如果它显示为“PLAY”，那么轮到他了;如果它显示为“VIEW”，则轮到他并不需要采取任何行动。无论按钮的状态如何，如果用户点击它，它将进入他点击的游戏，并且他可以执行某些动作，例如：滚动骰子，输入问题等，或者他可以看到电路板的状态（如图2所示）：每个玩家所在的位置，正在播放的当前现场牌，以及到目前为止在牌内的信息。 我们将在下一段中更多地讨论现场卡。
我们已经为游戏定义了五种类型的场卡：真相（Truth），挑战，（Dare）迷你游戏（Minigame），游戏玩法（ Gameplay）和通配符（Wildcard）。 每当玩家掷骰子并落在棋盘上的某个区域时，对话框弹出窗口将以“卡片”的形式出现。根据不同的领域，将显示不同的卡片布局。所有场地类型都允许玩家推迟其动作，但是在玩家决定采取行动之前，游戏将被暂停。在描述这些牌上的可能动作时，我们会将轮到它的玩家称为“当前玩家”，并将未轮到的玩家称为“其他玩家”：
一个真相卡片向当前玩家显示从数据库中提取的问题，并允许他回答问题或将其推迟到以后的日期。 另一个玩家也会看到当前的问题，如果当前玩家尚未回答问题，屏幕将显示“等待回答”。
一个挑战卡片向当前玩家显示从数据库中取出的一个挑战，并允许当前玩家发送他/她进行挑战的照片。照片仅保存到数据库中，直到dare标记为已完成，这样可确保用户看到了媒体。
一个游戏玩法卡让当前玩家有机会掷出一个6边骰子，并根据玩家掷出的骰子来激活一个特殊的游戏恩惠，例如前进场或与对手交换位置。Dialog活动中出现一个文本，告诉玩家自动激活的特殊效果的描述。
由于不同的迷你游戏之间存在差异，我们的每个迷你游戏需要实现不同的布局。举一个例子，对于“Rock-Paper-Scissors”迷你游戏，两个玩家在屏幕上都有三个按钮，对应于三个可用的选择:石头、石头和剪刀。在两个玩家做出决定后，屏幕会显示一个文本，指明每个玩家选择的内容，以及该玩家是否赢了/输了。获胜的玩家获得不同的游戏内好处，具体取决于所玩的迷你游戏。
一个通配符卡允许当前玩家键入他/她想要回答的问题，以及所需的答案类型：文本或照片。原则上，实现类似于结合在一起的Truth和Dare卡，区别在于，不是从我们的数据库中选择问题，而是玩家自己编写问题。
图2。 两个玩家之间游戏过程的典型屏幕，显示玩家的位置和标记;以及可用的不同领域：绿色 - 真相;红色 - 敢;蓝色 - 迷你游戏;黄色 - 游戏;紫色 - 通配符;
应用程序内部的游戏玩法的实现具有基于回合的方法，并且很大程度上取决于在数据库中保持游戏状态的四个变量：“isPlayer1Turn”，“hasPlayerRolledTheDice”，“isPlayer1AdditionalActionRequired”，以及“isPlayer2AdditionalActionRequired”。值得一提的是，基于回合制的游戏流程具有重要的转折点，这将影响到屏幕上显示的内容类型。
绘制了一个活动图，如图3所示，以显示我们的应用程序单个游戏轮次中涉及的各种活动。对于用户来说，回合的过程遵循直接的进展方式。
图3。 系统的体系结构图，基于模型 - 视图 - 控制器结构化方法
如果轮到设备所有者的话， 然后：
如果该玩家尚未掷骰子，那么当前玩家在回合的开始，需要在棋盘上前进。在这种情况下，一个半透明的窗口会出现在屏幕上方，文字“Roll”写在屏幕的中央。当用户点击它时，代码中的伪随机数生成器将生成从1到6的选择，结果将以图像的形式显示在屏幕上，骰子的正面有和滚动的数字一样多的点。如果用户再次点击屏幕，则玩家的令牌将在棋盘上前进到新位置，之后将有一个新的对应的字段卡出现。
如果该玩家已掷骰子，则当前玩家已经在棋盘上前进。在这种情况下，用户现在需要向当前场卡输入一些内容(通过回答问题、输入句子、按下按钮等)，但还没有这样做。
如果是轮到另一个玩家的话，那么当前玩家可以采取的行动是可视化棋盘，同时可视化正在运行的当前现场卡，到目前为止在其内部写入的信息，以及只有在请求时，可能在游戏中已在卡上执行一些额外的操作。
游戏以这种方式继续，直到其中一个玩家到达结束区域，两个玩家分别收到一个弹出对话框，显示“您赢了，恭喜！”或“您这次输了，但谢谢您的参与”。在两个玩家都关闭此弹出窗口后，游戏将从数据库和两个玩家的游戏列表中删除。任何两个玩家一次只能在数据库中进行一场游戏。
接下来，我们将描述组成应用程序代码的组件，这些组件与MVC（模型 - 视图 - 控制器）体系结构相关，大多数Android应用程序都是基于该体系结构设计的[2]。图4中的体系结构图展示了我们系统的总体组织和结构。
图4。 系统的体系结构图，基于模型 - 视图 - 控制器结构化方法
模型保存应用程序的数据和“业务逻辑”; View对象构造应用程序的用户界面; Controller对象包含“应用程序逻辑”，并将视图和模型对象链接在一起。控制器用于响应由用户界面触发的各种事件，并控制模型对象和视图对象之间的数据流。从这个意义上说，“在Android中，控制器类通常是类的子类（扩展）：Activity，Fragment或Service”[3]。由于这是一个基于服务的移动应用程序（利用Firebase数据库云解决方案），因此数据库已经在提供商方面进行了建模和部署，利用了更高的存储容量;客户端使用算法在本地处理特定数据，然后相应地将数据更新到数据库[7]。
1)模型对象描述
应用程序开发从为应用程序中的对象实现模型类开始。这些对象构成了我们面向对象编程方法的基础。例如:Board, Truth, Player, Field等等。
举一个例子，Player类是使用单例开发模式设计的，这意味着在应用程序的整个生命周期内只能有一个实例化的Player。这是为了确保玩家的个人数据可以从程序的任何部分进行全局访问，同时可以防止多个玩家在同一设备上同时登录。这影响了我们从数据库中与其他玩家的数据交互的选择，因为我们不是在本地存储与我们正在玩游戏的另一个特定玩家的所有数据，而是使用数据库来提取必要的信息，如果需要，检查其内容的更新。
在这里，我们将简要介绍为我们的应用开发的最重要的模型：
Player：用于在整个应用程序中保留所有必要的用户数据。这包括用户UUID，其名字，姓氏，电子邮件地址，游戏列表和游戏列表ID。
Game：class负责游戏数据初始化，以及为每个游戏实例化和初始化Board-specific对象。在这里，我们设置板内的哪些位置将是true、Dare、Minigame等类型。目前，板布局只有一种可能性，因为它已被硬编码，哪种类型的字段对应于板上的哪些位置。然而，进一步的发展将是为棋盘布局提供随机场类型生成器，以便每次在游戏棋盘上存在不同的场类型分布。
Board: 跟踪特定于游戏的棋盘中存在哪些字段，以及哪些位置包含哪些字段类型。
Field: 它是所有五种字段类型:true、Dare、Minigame、Gameplay和通配符的父类。它定义了每个字段类型中需要的两个重要方法的签名:getType()和getDrawableId()。方法()返回一个ID是独特的一个特定的字段类型,以确定特定领域的ID(例如,一个true的ID字段是1,而Dare的ID 是2)。getDrawableId（）根据Field的每个子类，存储“R.java”类中的ID，该类将其链接到“drawable”文件夹中的board字段图像，该文件夹将显示在屏幕上。
2）查看对象和布局描述
Android应用程序中的View对象本质上连接到定义该应用程序的用户界面的某些布局[6]。我们所有的布局都是使用Android正在使用的XML语言构建的[6]。我们游戏中的一些布局，在“一般功能”阶段结束时已经可用，它们是：
activity_login是我们用户界面中的第一个屏幕，用户将输入其电子邮件地址和密码以登录游戏数据库。如果用户没有帐户，他/她还可以通过按“创建帐户”按钮注册游戏，该按钮将用户发送到另一个屏幕，即：activity_registration。
activity_registration是用户在尝试在我们的游戏中注册时将看到的屏幕。用户需要输入所需的用户名，电子邮件和密码，之后他/她将自动被带到游戏列表屏幕。
activity_game_list和game_list_recycler_view形成主游戏屏幕，其中包含设备所有者当前正在玩的所有游戏的列表。列表中的每个游戏都具有标识符：参与游戏的其他玩家的用户名;用户名的初始值居中的方形图像，并根据该初始值填充颜色;以及一个“Play”或“View”按钮，取决于它在游戏中的位置。浮动的“ ”按钮提供了创建新游戏的方式，之后玩家被带到屏幕，该屏幕请求输入将加入游戏的朋友的用户名或电子邮件地址。
board_layout是用于定义游戏板对于玩家的所有游戏的外观的布局。它包含31个字段（包括“开始”和“完成”），为每个可能的字段使用不同的颜色和图像资源，并允许玩家选择的标记作为游戏玩法的一部分
资料编号：[5354]
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
