【原神游戏开发日志3】登录和注册有何区别？

本文主要是介绍【原神游戏开发日志3】登录和注册有何区别？，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

版权声明：

● 本文为“优梦创客”原创文章，您可以自由转载，但必须加入完整的版权声明
● 文章内容不得删减、修改、演绎
● 本文视频版本：见文末
● 相关学习资源：见文末
前言
● 这是我们原神游戏开发日记的第三期
● 在前一期的开发日记当中
● 分享了开发原神用户注册模块的过程
● 在本期将接着给大家分享开发登陆模块的过程
● 可能很多人会疑惑登录和注册功能逻辑不是差不多吗
○ 从开发者的角度来说
○ 注册是判读用户是否不存在
○ 登录是判读用户是否已经存在
● 这两者差别巨大
● 下面让我们一起来看下

登录和注册的区别

在这里插入图片描述

登录效果演示

● 首先加载热更程序集包括
○ 登录功能的基础代码
○ 实现等待游戏热更新完毕
在这里插入图片描述
● 登录画面中，输入一个已经注册过的用户
● 这时看到Unity调试控制台输出，队伍成员数量为0，准备创建队伍成员
● 这就表示服务器已经处理了这个用户的登录请求，客户端登录成功

普通开发者视角

在这里插入图片描述

● 先以普通开发者的视角，看下如何设计用户登录的过程
○ 用户点击登录按钮，UI层获取用户输入的账号密码
○ UI层把获取到的账号密码信息和用户登录请求，一起发送到客户端的用户服务模块
■ 用户服务模块：专门处理用户相关的每一个网络请求
○ 服务模块把用户登录请求转化为用户登录协议
○ 这个过程中底层框架处理这样一个工作
○ 把协议数据结构转化为字节流
○ 并且以字节流的形式发送到服务器
■ 字节流数据：是0101的一个二进制数据
○ 服务器无法直接识别需要反向转化到客户端发送的网络协议
○ 并且在服务器解析协议数据以后，就会得知客户端发过来的用户登录请求
○ 服务器再把有关用户的所有请求转发给用户服务模块
○ 未来用户服务模块可能会形成分布式架构的一个服务或进程
○ 所以我们的框架可扩展性是很强的
○ 如何处理接受的用户登录请求
■ 首先用户服务模块通常是不会包括用户信息数据的
■ 所以它要访问数据库，调取数据库中用户账号密码和UI层传入的账号密码进行对比，检测是否匹配
■ 这个过程中可以设置缓存层来优化数据访问的性能
■ 避免不停访问数据库造成不必要的开销

用户登录成功的情况
○ 如果传入的账号密码和数据库中的匹配正确，就需要给客户端一个登录响应消息，告知当前登录成功
○ 在客户端收到这个告知后，由用户服务模块对登录响应消息进行处理，同时会把用户信息保持在某个位置上
○ 保存了用户的信息，就会进入到下一个流程
○ 如果是首次登录会进入到选择旅行者的画面
○ 如果选择完成了，会进入游戏地图
用户登录失败的情况
○ 如果传入的账号密码不匹配，会传出一个失败的消息
○ 返回客户端显示给用户
○ 告知用户是哪个部分出现错误
● 所有这些底层工作，包括协议数据到字节流数据的转化，都是由网络框架负责完成
● 这部分内容已经在之前的课程中提到了，详情可见文末

存在问题

在这里插入图片描述
● 上述的开发流程还存在2个问题
a. 设计的细节度不够，无法落地形成代码
b. 丢失了一些关键流程和数据结构的考量
● 具体来说就是
○ 需要保存什么用户信息，即用户信息包括什么
○ 要把用户信息保存到哪里

要保存什么用户信息？

● 主要保存的用户信息有三点

用户
○ ID
○ 名称/密码
○ 玩家列表
■ 一个账号下可能存在多个游戏角色
● 原神并不支持创建多个玩家角色，但是依然可以把玩家列表作为一个拓展
玩家
○ ID
○ 角色列表
角色
○ ID
■ 原神当中玩家可以控制多个角色，并且安排到队伍中，里面每一个角色都应该有一个ID以及一个模板ID
○ 模板ID
■ 例如原神中的丘丘人，每个丘丘人个体上存在一些差异可能是坐标位置，但是他们的外观、攻击、防御力、最高血量等都是相同的。
■ 可以把这些相同的数据归类为一个模板数据，通过模板ID关联到角色模板数据
○ 所在地图
○ 所在位置

用户信息保存到哪里？

● 存储用户信息要存到四个
○ 协议中
■ 主要用于网络传输，是一个临时的存储位置
○ 数据库中
■ 主要当于服务器停止运行
■ 例如维护时，把用户数据存储在数据库中
■ 服务器重启后重新加载数据库中的用户数据
■ 由于服务器访问数据库速度慢，应当避免将数据存放在数据库中，而是存放在服务器内存中
○ 服务器内存
■ 数据存放在服务器内存中方便查取，即使不使用第三方缓存机制也比直接访问数据库速度快
○ 客户端内存
■ 为了便于客户端可以随时查询到用户数据，不需要每次查询都请求服务器
● 参考右侧的数据模型，可以知道
○ 协议是存储用户信息中的一个桥梁
○ 服务器内存中的用户数据可以通过协议发送到客户端
○ 让客户端同步获得服务器抓取的用户信息
○ 服务器内存的用户数据是从数据库中得到的

服务器内存（方式一）

● 用户数据放到服务器内存当中如何便于查询
● 要理解这个问题，需理解服务器与客户端通信模式
○ 通常来说一个服务器进程会同时跟多个客户端建立连接
○ 服务器为了获得所连接的客户端信息，需要根据连接信息来查询用户信息
○ 因此对于每一个客户端，服务器应当建立数据结构，来保存它跟客户端建立的连接
■ 应当保存每一个客户端的连接
■ 保存连接对应的用户信息
■ 为了方便通过用户的连接获取到信息，应当建立一个字典
● 字典是客户端跟服务器建立的连接，一般称为Section或者Socket
● 对应的值就是这个用户的信息
■ 当客户端发起一个请求的时候，服务器架构就会获取到客户端的连接信息
■ 然后通过连接信息，来访问对应的用户信息，如图中右下表格
■ 图中右侧数据模型表示服务器跟客户端之间的连接
● 一个服务器同时会和多个客户端建立连接
● 通过在服务器上面存储客户端的用户信息
● 就可以知道这个用户是谁和用户当前使用的玩家是谁
● 以及玩家当前控制的角色是谁
● 因此需要建立一个连接管理器来存储右下这张表

字典管理的缺点

● 每一次要访问用户信息时都需要访问一次字典
● 虽然字典根据键访问信息时效率很高，但并不是所有情况下都是一个O1级别的数据访问效率
● 还是存在开销，特别是在字典的键发送冲突时，这部分内容可以查考文末
● 因此这样的数据结构组织方式，仍然存在效率低下和代码不优雅的问题
● 这是存储用户信息的第一种方式

服务器内存（方式二）

● 第二种方式是把用户信息保存在建立的连接信息上
● 在C#语言中可以实现为一个类或者一个结构体，按照具体方便来实现
● 这种方式优点在于：
○ 用户信息作为连接信息的一个成员，连接信息可以看作一个类，用户信息则是一个字段
○ 当访问到连接信息就可以访问到用户信息，避免了字典查询的开销
○ 服务器的消息处理函数，默认包括了Session信息
○ 因此服务器处理一个请求，自然就能在请求处理代码当中获得Session信息从而取得用户信息
○ 方式二比起前面用字典管理用户连接更好
● 右侧网络游戏的服务器框架当中，网络数据来自于Socket通讯
● 可以自由的跟客户端进行连接
● 连接完后可以去跟客户端进行数据收发
● 并且客户端和服务器需要双向的处理发送和接收的数据
● Socket通讯、消息处理器、连接信息这三者之间的关系是怎样的，如何处理三者之间的关联
● 这个是作为主层架构师必须掌握的架构设计能力之一

● 图中这行代码是服务器处理用户登录请求的一行代码
○ 第一个参数是WebSocket（网络连接）
■ 可以方便我们和客户端双向数据收发
■ 同时在收到一个客户端请求，通过WebSocket中定义的Session（连接信息）类型
■ 获取到用户的会话信息，会话信息中存储的User信息就是用户信息
○ 第二个参数是客户端发出的用户请求
■ 大部分客户端请求的处理代码都是图中这样，因为框架是统一的
○ 所以开发原神游戏项目其中一个难点就是如何去合理的设计项目架构
○ 让我们可以直接通过这个Session，获取到登录成功的用户信息
○ 能够以尽量简洁高效的方式，完成扶持逻辑的编写

客户端内存

● 客户端中也需要保存用户信息，避免频繁访问服务器
● 在客户端中增加一个实体层，来存储用户信息
● 实体层的相关内容可以关注我，会在后续文章中分享给大家
● 首先看下客户端整体架构
○ 客户端最底层的是服务层
■ 用于发送请求到服务器，并且接收从服务器发回的响应信息
○ 中间层是实体层
■ 通俗上可以认为是对象层
● 用于管理游戏中会活动的、可以交互的对象，又可以称为实体
■ 在原神游戏开发的项目架构中，通过实体树来对游戏中实体分层管理
■ 这样可以让客户端在拥有巨大数量的实体的时候，进行方便的分类和管理
■ 除此之外实体层还能够支持ECS架构
■ 就是说实体跟实体的画面表现是可以分离的
○ 最高层是UI层
■ 我们的UI层面已经实现了基于MVVM的UI管理
■ 比使用MVC框架更精细的对UI进行控制
■ 并且可以更好地隔离游戏当中的数据以及数据的表现
■ 我们开发UI界面表现层的同学
■ 只需要完成UI功能的代码
■ 就能实现整个UI界面的表现