Panada Master

Appearance

Solution 1 ​

目录

DANGER

IOS上有闪退问题.在Unity空项目中,可以在IOS上运行.排除原生不可运行的问题.应该是我们项目的问题,需要Unity开发优先解决

技术背景 ​

通过和策划梳理整体的游戏逻辑,通过技术视角目前我将开发内容分为几个相对独立的部分

  • TG的功能(Telegram mini app)
  • 游戏客户端(游戏框架)
  • 后台服务(API service)
  • 链上功能(暂时不考虑)

时间背景 ​

  • 时间节点1: 11月底 内侧版本
  • 时间节点2: 圣诞节之前12月中下旬 版本1.0

分析 ​

我根据目前摸索的业务架构,和时间节点,我个人觉得将整体的游戏逻辑移动到服务端是不现实的.原因如下:

  1. 游戏数值/逻辑版本过于超前，数值相互影响，服务端从零开始的工作量巨大
  2. Unity的内容更新将停滞，且需配合服务端进行逻辑修改/删除。
  3. 隐藏问题多，进度难以控制，时间紧迫。

因此，我们提出以下解决方案：

解决方案 ​

既然Unity的工作足以支撑第一波测试,那么我们选择继续使用Unity作为游戏的展示以及游戏逻辑的实现。

然后我们通过TG功能和服务端实现用户的登陆,同时可以维护用户的邀请关系,并且保存用户数据。

最后利用服务端对用户的游戏数据进行‘存档’(保证数据安全的情况)

当用户在不同设备上登陆之后,就可以拉用户的数据实现多设备同步

  1. 游戏框架：继续使用Unity作为前端展示和游戏逻辑（数值/掉落/玩法）的实现。 开发任务:继续完善游戏的逻辑闭环,修复问题
  2. 接入服务端：用于Unity存档用户数据，实现多设备同步。 开发任务: 开发后台服务
  3. Telegram mini app：与服务端搭配实现登陆/分享功能。 开发任务: TG bridge
  4. 数据加密 利用密码学对用户数据传输进行加解密 开发任务: 利用加密通讯进行加密通讯

结论 ​

  1. Unity端保证游戏逻辑的闭环,并且修复游戏问题,保证游戏的稳定性.
  2. 服务端辅助Unity,用于保存用户的数据.
  3. 数据加密保证我们的通讯能防止被篡改.
  4. TGBridge保证登陆和分享流程逻辑.

根据之前开会的日志,以及此方案实施,通过以下三点分析

1.我们有什么 ​

  • 游戏数值体系/游戏逻辑已经ready
  • Unity中开发进度 / 美术资源 / 特效效果
  • 目前的测试进度
  • 未来的开发进度

2.需要做什么 ​

INFO

”*“ 代表高优先级

  1. Telegram mini app相关
    • TG和Unity连调,解决Unity在TG中的兼容/优化问题*
    • TG和Unity的Bridge,解决Unity中需要TG的功能*
    • 开发加密通讯(安全通讯)*
    • TG Bot和TG App账号的申请、开发
  2. 后台相关
    • 后台基础架构*
    • 用户系统的开发 (用户信息)*
    • 邀请系统的开发 (邀请关系)*
    • 游戏数据系统的开发 (用户存档)*
    • 报表系统 (关键数据,总用户新增/日活)
    • 日志系统 (错误日志)
  3. 游戏相关
    • 游戏逻辑的完善 (闭环逻辑 / 增减功能)*
    • 配合服务端实现多设备同步*
    • 配合TG实现bridge和适配*
    • 配合后台实现自动化打包
  4. 运维相关
    • 服务端的部署
    • 游戏二进制包的存储和分发
    • 自动化部署
  5. TODO等待补充....

3.可能的卡点是什么 ​

  1. TG和Unity适配率低(尽可能保证95%的适配率,不在5%浪费过多时间)
  2. 后台工作量(前期拆分需求,设置看板)
  3. 加密通讯开发
  4. TODO等待补充....

4.排期 ​

任务名称时间(天)参与人员
TG Bridge / TG适配丹宁/ Yevin
Service API丹宁/ Yevin
API连调丹宁/ Yevin
安全通讯丹宁/ Yevin
整体测试所有相关人员
部署丹宁/ Yevin/ 运维人员

具体内容可以查看子目录内容

实施进度看板