深藏blue——各阶段问题回答的集合

深藏blue 团队 2023-06-11 22:34:42

选题
Q1：这类社交游戏有很多，是否用户只是喜欢别人玩这类游戏而不是自己会去玩呢？又或者你们面向的用户人群是那些呢？
Q2：如果只是供少量游玩，用户只是了解有这个平台而不去使用是否没有意义？
Q3：没有公司做是否是因为没有找到做的动力呢？
Q4：缺少技术基础，团队是否有相应的学习规划？
Q5：对推广有什么想法？
Q6：是否存在短寿命问题？是否有长期运营价值？
Q7：对场地的要求是否比较苛刻
Q8：在场地上是否会有推荐和安全性的评测
Q9：是否需要排除危险路段
概要设计
Q1：如何保存一个房间里面的玩家及玩家的游戏记录？
Q2：未来如果系统推广开来，使用人数不断增多，是否设想过检索数据的速度问题，是否考虑做哪些方面的改进？
α冲刺
Q1：后端的界面比较朴素，密码为明文不合理；
Q2：灵感商城有点意思，不过当下应更注重推广，而不是获利；
Q3：什么情况是属于没有准备？提示可以再具体明确一些。
Q4：多久刷一次位置？
Q5：后端管理有点简陋，应当考虑到用户人数较多时的管理。
β冲刺
Q1：标准下降是否合理？
Q2：类似之前团队的减量分配任务是否合理？你们团队是否有这样的现象？

选题

Q1：这类社交游戏有很多，是否用户只是喜欢别人玩这类游戏而不是自己会去玩呢？又或者你们面向的用户人群是那些呢？

这是一个可能存在的情况，但不一定适用于所有用户。有些用户可能确实更喜欢观察别人玩社交游戏而不是参与其中。他们可能认为通过观看别人的快乐、紧张和互动可以获得类似的体验，而无需承担直接参与游戏所面临的压力或不适感。此外，看别人玩游戏也可以帮助用户了解这款游戏的规则、玩法以及各种策略。但是也有很多用户会直接参与这类社交游戏，因为他们可能对互动和社交活动感兴趣，并且享受体验新的事物和结识新朋友的过程。在游戏中，玩家可以打破陌生感，建立联系，并掌握新的技能，这些也是许多人非常愿意尝试并积极参与的活动。因此，尽管有些人可能只是喜欢看别人玩社交游戏，但不能一概而论，不同的用户有不同的偏好和目的。

这类社交游戏的用户人群主要是喜欢在线互动和社交的年轻一代。
以下是我们这款游戏可能的目标用户群体：
- 活力充沛的年轻人：年轻人通常喜欢参加户外活动，并且健康的身体和足够的耐力能确保他们在进行跑步或藏匿时表现出色。而且年轻人更容易接受新事物，也更具有好奇心。
- 游戏爱好者：喜欢玩各种类型游戏的人，可能会特别喜欢这种有趣且规则简单的游戏。
- 社交动手能力比较强的人：这款共享位置捉迷藏小游戏，需要和其他人合作或对抗，所以，那些喜欢通过游戏与其他人互动和社交的人可能会比较喜欢这种游戏。此外，希望在游戏中结识新朋友或者加强与现有朋友的联系的人也可能会喜欢我们这款游戏。
- 比较喜欢放松和娱乐的人。因为我们这款游戏一般没有太高的竞争性，可以说是一款休闲小游戏。

Q2：如果只是供少量游玩，用户只是了解有这个平台而不去使用是否没有意义？

如果只有少量用户游玩你的平台，而这些用户仅仅只是知道平台的存在却没有去使用的话，这样的平台确实可能缺乏意义。因为平台的目的是提供服务并吸引用户，如果没有用户参与，则平台无法达到其目标。然而，这并不是说平台就毫无价值。即使只有少量用户了解平台，它们也可以成为平台进一步扩展和发展的基础。此外，平台在各方面都需要时间来建立品牌知名度、积累用户群、完善功能和优化用户体验，这样才能更好地吸引更多用户参与。因此，尽管当前的用户数量较少并且只是知道平台存在，但是仍然有价值继续尝试推广平台，增加用户数量和活跃度。

Q3：没有公司做是否是因为没有找到做的动力呢？

对于老师们提出的“没有公司做是否是因为没有找到做的动力”的问题，我们思考之后觉得，一是因为时间周期过短，这类游戏很快便会“过气”，在时间和成本的结合考虑下会导致一部分公司放弃，二是因为实际上共享位置捉迷藏是一个大范围地域的、需要奔跑的活动，而能符合这样条件的基本只有大学生，当投入与收入不成正比时，公司也会考虑放弃。而我们决定制作这样一个小项目，一是为了与当下热点结合，尝试制作一款热门的小程序，二是为了挑战一下自身和团队的极限，能否在限定的时间内掌握一门全新的技术领域，三则是考虑此次我们最大的目的是提高自身能力和团队协同开发能力，除了付出时间和精力外并没有付出额外的投入，因此我们决定制作这样一款小游戏。

Q4：缺少技术基础，团队是否有相应的学习规划？

团队成员都不具备小程序方面的技术基础和项目经历是我们一开始就明白的，也正因为如此，我们早在第一次团队项目合作时便提出了在初期便对成员的技术能力进行深入了解，根据项目内容进行列出所需要设涉及的技术，并通过每一个成员根据自身能力进行选择，利用前几次团队项目比较轻松的条件，从当下便开始学习了解，以便后续两次冲刺任务能够顺利进行。
团队技术分配大致如下：

项目技术	成员
小程序前端	052006130 222000235
小程序后端	222000429 222000434 222000433 222000129 222000131
web端	222000227 222000206
数据库接口设计	222000429 222000131
MyBatis	222000131
UI美工	222000129

Q5：对推广有什么想法？

面向目标用户群体进行宣传：因为这款小程序是一款多人在线游戏/社交游戏，所以主要的目标用户群体应该是年轻人和游戏爱好者。将小程序分享到社交媒体平台上，如微信、微博、抖音等社交媒体平台。可以在大学内部微信公众号或者校园交流群中宣传。
增加奖励机制：设计一些奖励机制，例如每邀请一个新用户加入游戏即可获得一定的奖励，可以吸引更多用户加入
发布更新内容：不断完善游戏内容和系统，增加新的地图、道具、任务等，保证用户体验。
合作推广：尝试与一些游戏或社交平台合作，例如与微信小游戏平台合作，在微信小游戏中推广，还有就是可以与其他APP或网站进行合作推广，可以通过互相放置广告、免费试用等方式来吸引更多用户。
用户推荐：鼓励现有用户向他们的朋友和同学推荐这个小程序，以便增加口碑效应和用户数量。
SEO优化：针对小程序相关的关键词进行SEO优化，提高小程序在搜索引擎中的排名。

Q6：是否存在短寿命问题？是否有长期运营价值？

对于大多数小程序来说，短寿命是一个普遍存在的问题，这也是许多开发者非常关注的问题。而针对我们这款游戏的情况，可能存在以下几个原因导致短寿命：

玩家流失：由于这款游戏主要是基于多人在线游戏的模式，如果玩家没有足够的社交活动和引导，很容易出现玩家流失的问题。
单调性：虽然这个抓人游戏很有趣，但是如果内容单一，没有太多变化和可玩性，用户可能会感到无聊和枯燥，从而失去兴趣。
竞品和模仿：市场上已经存在很多类似的游戏，并且容易被其他的开发团队模仿，这也会影响游戏的长期性。
技术更新：小程序技术在不断地更新和升级，如果我们的小程序不能及时跟进，可能会导致用户体验下降，从而损失用户。

针对以上问题，可以采取一些措施来延长小程序的生命周期：

不断优化游戏体验：不断更新和完善游戏内容和系统，增加新的地图、道具、任务等，保证用户体验。
增加社交活动：增加一些社交功能，例如添加好友、私信聊天等，帮助用户之间更好地交流和互动。
定期推出促销活动：设计一些奖励机制，例如每邀请一个新用户加入游戏即可获得一定奖励，可以吸引更多用户加入。
关注市场不断优化：我们还需要不断关注市场的变化和技术的更新，尽可能及时地进行升级和优化，从而延长小程序的生命周期。
切入特殊领域：加入特殊元素，如利用大学校园文化作为元素，创造出独特的氛围，以此来增强用户黏性和记忆点。

Q7：对场地的要求是否比较苛刻

针对于捉迷藏游戏来说，其实对于场地的要求并不严苛，只要是一个能活动得开得地方就可以进行捉迷藏游戏。由于是共享位置捉迷藏，所以只要要求用户不会进行类似于上下楼这种垂直面上的活动都可以玩这款小游戏。

Q8：在场地上是否会有推荐和安全性的评测

对于目前的计划来说，暂时没有这个想法。但如果后期所有基础功能都完成后，会考虑加上这个功能的实现。

Q9：是否需要排除危险路段

这是一个很好的想法，但由于目前对于我们团队的多方考量，这个功能会放到后续有条件实现的时候再实现。目前暂时没有这个想法。

概要设计

Q1：如何保存一个房间里面的玩家及玩家的游戏记录？

由于微信云数据库是非关系型数据库，因此我们对数据表设计做了以下修改：

①取消房间的概念，使用game_record【“游戏记录”集合】保存同一场游戏的公共信息，一条记录对应一场游戏。
字段包括：游戏记录id（_id），房主OpenID（creator_openid），同时游戏人数（player_count），游戏模式id（room_type_id），游戏开始时间（starttime，游戏开始时存入），游戏主题id（theme_id）

②使用user_record【“用户记录”集合】保存每个玩家个人的游戏记录，多条user_record记录对应一条game_record记录，这代表这多名玩家处在同一场游戏中。
字段包括：用户记录id（_id），准备状态（IsReady），玩家个人OpenId（open_id），对应的game_record集合中的游戏记录id（game_record_id），分配的身份（Identity，抓捕者/被抓捕者，游戏开始后更改），所处位置经纬度（latitude，longitude），选择的主题头像图片路径（playing_img_url），本条user_record的状态（status，为真值则说明本条用户记录有效，否则说明本条用户记录）

③用户用于登录小程序的基本个人信息，如昵称、头像、openId等信息被保存在user集合中，在创建user_record记录时，由前端获得当前用户的openID并查询user集合，获取他的头像、昵称、openID等个人信息用于创建用户记录。

为方便描述这两个表的使用情况，现将流程描述如下：

作为房主的玩家点击开始游戏后选择模式，此时后台会创建一条game_record游戏记录和一条房主本人的user_record用户记录，这条用户记录的game_record_id字段用game_record的_id字段填写，状态。
房主点击空位，分享一条包含房主的user_record记录中game_record_id的链接，邀请成员加入。
作为成员的玩家点击链接，等待资源加载完毕后，点击进入游戏，此时后台会创建一条该用户对应的user_record用户记录，它的game_record_id字段用链接中的game_record_id填写，同时该字段对应的game_record记录中的player_count会增加1。
作为成员的玩家点击准备，会修改user_record中对应的IsReady字段，选择头像会修改对应的playing_img_url……
房主开始游戏后，该game_record_id对应的所有用户的user_record记录的status状态字段置为false，说明房间已经开始游戏。

如何确定分享链接中游戏记录的有效性呢？我们通过链接中的game_record_id查询game_record集合，找到对应的记录中的房主openID，再用该openID去查询user_record，找到房主用户现在状态为true的记录，比较该条记录中的game_record_id和分享链接中的game_record_id，若相同，则有效，否则说明本场游戏已开始或已经结束。

Q2：未来如果系统推广开来，使用人数不断增多，是否设想过检索数据的速度问题，是否考虑做哪些方面的改进？

本次实践项目采用微信云开发，使用云开发提供的云数据库API对数据库进行访问，这些API中封装了查询优化等一系列功能，并且微信希望用户对后端云数据库的认知越低越好，因此我们仅通过尽量设计良好的数据库模型来提高检索效率。
参考链接如下浅析小程序云原生数据库的设计与应用
相关原文引用如下:

.....
云开发数据库设计与优化
.....
4.智能DBA
....
索引是数据库中非常重要的概念，用于加速数据库的查找。在小程序的场景下，我们希望将用户对于后端的数据库的认知降低到越少越好。于是实现了一系列查询优化的功能，比如自动建索引。
当我们的接入层和存储层发现用户有很多查询到后端都是全表扫描时，就会根据用户的query具体字段进行对应索引的添加工作。等到索引建立完成，用户就可以直接享受优化后的查询结果。重要的是，这一过程用户同样也是无感知的。

α冲刺

Q1：后端的界面比较朴素，密码为明文不合理；

后面经过学习以后，熟悉了后端框架的作用，界面变得更加丰富

Q2：灵感商城有点意思，不过当下应更注重推广，而不是获利；

是的，应该先把重心放在打磨产品

Q3：什么情况是属于没有准备？提示可以再具体明确一些。

玩家受邀请进入房间时默认为未准备状态，点击“准备”后为准备状态，再次点击可取消准备，在β阶段我们更新了这部分的页面设计，增加准备状态的显示，当玩家点击准备后，其头像的右下角会出现准备字样的小图标，能够更直观地显示当前房间的准备情况。

Q4：多久刷一次位置？

每秒刷新一次位置，更新数据库内的经纬度信息，通过监听数据库变化，将相应位置信息、头像图片等渲染至地图上显示。

Q5：后端管理有点简陋，应当考虑到用户人数较多时的管理。

使用element-ui对前端进行美化，vue框架可以之间引入element-ui，使用其中的控件和布局，可以大大优化用户的视觉体验。当用户人数较多时，可以设置分页，将所有的用户进行分页管理；还可以添加搜索功能，管理员可以通过id去查找想要查询的用户。

β冲刺

Q1：标准下降是否合理？

标准下降在时间较为充足的情况下是十分不合理的。当初我们小组做出这个决定是因为大致预估了一下距离beta冲刺剩余的时间以及完成最初项目需求分析时定下的功能还需要的时间，发现如果要完成所有当初预定的功能对于当时的我们而言几乎是不可能的，即使勉强完成了雏形，也会存在很多的bug与不完美，因此在团队协商之后，我们决定挑选其中更为重要、更具有特色的功能完成而舍弃一些附加的小功能。对于beta阶段标准的下降，我们觉得还是因为项目初期的规划与分析不足的原因，对此我们小组的成员深感抱歉，也在此次的冲刺之中得到了教训，在之后的项目中一定会进行合理的规划，而不是初期画大饼，后期降低标准。

Q2：类似之前团队的减量分配任务是否合理？你们团队是否有这样的现象？

在敏捷软件开发中，将大型项目拆分成小的可交付部分（称为“Sprint”），并在短时间内完成每个Sprint。减量式开发可以让团队更快地响应变化和反馈，并确保产品质量。在每个Sprint期间，团队会通过一系列计划、设计、控制、评审和演示流程来完成任务。
减量分配任务是一种常见的任务分配方式，许多团队会采用这种方法来合理安排每个人的工作负担，团队成员在减量分配任务时，通常会按照成员专业能力、工作量、优先级等因素进行任务分配。每个团队成员都应该对自己的任务负责，并确保在Sprint结尾前完成所有任务。通常情况下，减量分配任务是合理的。
然而，如果减量过度或不合理分配任务，则可能导致某些团队成员心理负担过大、效率低下甚至出现疲劳倦怠等问题，对整个团队的工作效率和成果都存在潜在的负面影响。因此，在实际应用中，需要根据具体情况综合考虑分配任务的合理性，平衡工作负担，并适时进行调整。
我们在团队中，也借鉴了这种方式，在分配任务时，按照成员专业能力、工作量、优先级等因素进行任务分配。每个团队成员都应该对自己的任务负责，以保证项目的高效执行和及时完成。

...全文