Monodyee

这个屌丝很懒，什么也没留下！

热门标签

unity3D RPG 网络游戏开发精讲

作者：Monodyee | 2024-02-19 19:54:57

踩

unity3d rpg 网络游戏开发精讲

文章连载更新中，可以提前领取素材进行预习，自学
素材领取：私信发送领取RPG网络开发教材

点击观看视频版专题

UnityRPG网游开发专题

游戏玩法

游戏目标：保护水晶不被怪物摧毁。共有42波怪物。怪物强度随着波数加强
地图环境：周边有各种怪物，打倒之后都会随机掉落各种宝物，NPC和商店提供道具和装备支援

玩家之间需要把握好发育，防守，探索的时间和人员分配，良好的配合是致胜的关键

课程介绍

这门课适合哪些人学习

想向制作RPG类型游戏的个人或3-10以下的团队
课程是案例复盘讲解，用具体案例讲解整个游戏开发过程
涉及到项目管理，团队协同，编程技术栈等。

在时间安排上。占比最多的是程序设计和实现原理，开发思想。
为开发者指引方向，意识中形成开发版图。
为开发者指引方向，意识中形成开发版图。
为开发者指引方向，意识中形成开发版图。

具体细节和疑问也会开放专用的学习群补充。
没有展开的细节部分，大多都可以通过搜索引擎自行补充。

比如之前的《Unity开发战棋手游》专题
课程只提及了A星寻路的关键字，没有具体展开。
有开发者会疑惑？为什么不把A星的内容补充完整。
因为A星的原理，实现算法都可以在互联上查阅到很详细的文章，视频资料。

所以课程的学习方法是形成知识索引，需要用到时，再去展开细节深入学习。
这样的学习方法更能适应高速发展的游戏行业。

学完了能达到什么效果

课程内容包含了网游中80%常见功能
开发者对内容掌握90%以上
（独立开发者）在基础上打造属于个人的RPG游戏
（小团队）助力团队快速成型，把控项目开发进度。

掌握50%以上，公司初级开发岗（UI模块，基础功能），或者独立游戏开发都游刃有余。

比如：我们收到需求内容：制作背包，装备，合成系统，排行榜。需要多长时间完成？

把开发效率划分成4个阶段
开发效率对比：
没做过<有了解过<实现过类似案例<源码复用

效率差距原因：
没做过<有了解过 (功能设计时间)
有了解<实现过类似案例 (编码熟练度)
实现类似案例<复用源码(节省编码和代码测试时间，因为能够复用的代码一般都是验证测试过的)

课程包含了大量的常见功能设计，
这些案例的能够让开发快速积累经验
学完后开发效率能在2-4的阶段之间

课程目录

项目准备

策划准备，美术准备

基础系统

UI框架，NPC，道具，背包，商店，装备，任务系统
合成系统，角色选择，掉宝系统,
野外地图怪物生成，攻城怪物生成

战斗系统

基础属性，成长
客户端和服务器的技能设计
技能，动作，攻击配表设计
Buff,Debuff系统
怪物AI

同步设计精讲

位置同步，技能同步，特效同步，属性同步

社交系统

聊天，好友

副本系统

副本设计和实现

优化

AOI，美术相关的建议

正文

项目准备正文

视频讲解版
立项，策划准备，美术准备
U3D版本:unity2020.3.31f1c1
IDEA:visual studio 2019

策划准备:
编写策划文档，作用：便于项目管理。进度推动。多人协同开发。
要开发的游戏越大，要准备的文档越多。

文档是全部都写好了再做开发，还是边写策划边开发？

//假设项目组只有3个人,策划，美术，程序
在这里插入图片描述

可以看出项目越大，敏捷开发的效率就越高，大多数项目都是使用具备快速迭代的敏捷开发思想

所以策划并不是一次性写好的，而是边写边提交给技术和美术。
有需要时还会口头交流作为补充。

这种项目推进方式不仅在游戏行业适用，在其他行业也有类似的思想，比如影视动漫。

踏出游戏开发的第一步：
以本案例举例：整理策划文档“保护水晶不被怪物摧毁。共有42波怪物。怪物强度随着波数跌增”
42个怪物，1个水晶
就需要准备的美术素材怪物和水晶的模型。
我们需要准备多少个模型？
假如42个怪物的样子都不一样，就需要42个模型。
假如怪物都一样，那只需要准备一个模型。

如果等到模型齐全了再施工，明显是不符合敏捷开发思想的。
从设计上我们坚持42个怪物。通过配表设置怪物外观。
美术前期只需提供一个模型即可，表的内容根据美术的产出速度调整即可。

在这里插入图片描述

有了怪物之后，自然而然的会关联其他需要的材料，比如数值，血量，攻击力->做怪物的数值表
做好了怪物之后
接着往下制作做英雄人物，也是需要模型，数值
这时候就可以照搬/复用之前的方案。
在做着英雄功能的时候，自然会关联到技能系统，装备道具，升级方案等等。

到了这里，我们就打开了局面，剩下的功能模块会跟着经验的积累，越做越清晰。
最后项目如同抽丝剥茧一样。
最后资料里面附带常见的策划表，可以作为参考模板，积累案例经验。

在这里插入图片描述

美术准备：

美术有什么要求？可以参照文档里的《美术资源规范》。
文档定制了场景，特效，UI，模型（贴图，面数）（适合拥有美术部门团队）
大团队和小团队的管理差异建议

美术准备规范可以划分两种，资源归类管理，资源质量管理

我们会从玩法设计，手机硬件要求，运行效果这三个维度讲清楚美术资源的参考标准
　
　　
　　　
　　　　
　　　　　
　　　　　　
　　　　　　　
　在这里插入图片描述

哪些手机能够玩到我们的游戏？硬件要求

模型数量对内存的要求

32种模型同时存在场景中。
32模型一样的怪，和32个怪模型各不相同的怪，内存占用是有大约内存占用是32倍。（模型越多对内存要求也就越高）
至少需要1.5G以上的运行内存(2016后的机子可以运行)
以下是一个模型的数据
在这里插入图片描述

数量和面数对帧数的影响

在这里插入图片描述

在这里插入图片描述
高端机60-57帧：

在这里插入图片描述 !!
中端机60-55:

在这里插入图片描述

低端机:10fps
在这里插入图片描述

优化方向

怪物数量60->49帧
在这里插入图片描述
10个55帧

加载地形->28帧

地形优化->44帧

地形优化前的面数

优化后的面数

优化后2w3->4k8

建议:
到了这里对游戏性能，模型规范，设计玩法，目标用户，优化代价有了一定的！了解。

面向中，高端机型的机型>50帧（无需优化）
面向低端机型的机型<30帧（酌情考虑）
市场常见做法：
1：放弃硬件不达标的用户（不让玩）
2：提示用户得不到预期的体验（可以玩，但体验质量无法保证）
3：分批次扩大用户目标，第一个版本的用户目标（中，高）面向低端机型用户的优化放在以后版本，逐步扩大覆盖群体

在这里插入图片描述

到这里们就讲清楚了玩法设计，性能表现和模型参数的关系。

接下来讲资源归类管理。
模型，特效，装备道具图片
模型管理
在这里插入图片描述

读取策划表，为模型资源分配资源标签，用于程序读取
在这里插入图片描述

在这里插入图片描述

特效命名规则:
在这里插入图片描述

道具图片：出图尺寸-资源名规则->策划表的道具id=图片名
图片大小(512x512,如果超过了内存瓶颈（6g运存下降至4g），可以使用UNITY3D引擎压缩图片大小降低内存占用率)

在这里插入图片描述

通过上面的配置表，我们就制定好了怪物的属性，掉落信息等。

文章出现的代码图片，右下角有UNITYLOG的为客户端代码，否则是服务端代码
加载怪物属性
在这里插入图片描述

对于没有美术部门的团队，更多的是从unity资源商店获取素材资源，根据项目要求选择适合的资源。
比如：手游项目建议选择为手机平台制作的资源。
在这里插入图片描述

对小团队的建议
资源归类规范建议。
由于资源的制作者不同，所以资源的规范和目录结构也不尽相同。
如果非要按照制定的规范去管理资源，是需要花费大量时间整理资源的。（生般硬套）
建议能够整理的尽量整理。

案例的方案是：捉大放小。
我们的案例会把所有的模型素材都整理到模型目录下，但是具体材质，图片的命名不作处理。

技术准备

具备UNITY基础，C#编程基础，多人开发管理工具的使用（SVN,Git)
客户端的理解=>框架设计,资源热更和管理,场景管理，UI管理(可回顾战棋专题)
服务端的理解=>框架设计,网络消息收发，网络协议设计，生成。（专题讲解链接）
最起码要能编写聊天室功能
在这里插入图片描述
也可以先跟着视频先跑一遍，学习课程的设计思想，回头再查漏补缺
比如资源热更管理，课程花了1个多小时讲了从热更的诞生到实现，
但在使用层面只有2步：资源打标签，调用资源加载的API
所以要根据自身需求灵活分配学习时间
建议：
1：想快速做出一款独立游戏，只需要知道怎么用（套方案）。
2：在职U3D开发，一直都是做基础模块，UI模块，想要在技术上查漏补缺，
则可以展开细节系统的学习。

基础系统

角色选择，NPC，道具，背包，商店，装备，UI框架，合成系统
任务系统，
野外地图怪物生成，攻城怪物生成
道具掉落,道具拾取

创建角色->加载场景->找到商店NPC->购买装备->打开背包->穿戴装备。
（登录->大厅->创建房间查看以往专题）->角色选择->加载场景,NPC，道具，背包，商店，装备，UI框架

c=客户端
s=服务器
创建角色逻辑(c显示可选择的人物->c选择人物->s广播->c锁定选择->s广播-> s判断选人结束->s广播开始游戏->c加载地图场景)

1:读策划表，显示可选英雄图标（根据英雄ID加载图片资源）
在这里插入图片描述

通过xls2Json生成数据和模型便于程序读取
在这里插入图片描述

在这里插入图片描述

通过AB工具给资源打了标签才能加载资源在这里插入图片描述
2:玩家点击英雄图标->定制协议->发送选角消息

服务器处理过程->存储玩家的选择数据,广播消息，所有客户端更新选角UI

在这里插入图片描述
为什么服务器要存储玩家的选定信息？玩家断线重连需要同步选定结果

客户端收到选角消息
在这里插入图片描述
当所有人都选择好角色后，服务器初始化数据，通知客户端

客户端收到开始游戏消息->显示加载UI并加载场景

同样的场景资源也打了资源标签
在这里插入图片描述
（资源管理）创建角色->加载场景->找到商店NPC->购买装备->打开背包->穿戴装备。

点击商店NPC，显示商店UI->选择购买装备->打开背包->穿戴装备->创建角色.
NPC功能->NPC怎么加载显示?怎么交互？->交互的内容是什么？
商店NPC->点击屏幕交互->打开商店UI
模板方法:XXNPC->点击屏幕交互->点击后打开XX功能…

客户端NPC怎么加载显示？根据地图的NPC配表，加载模型

在这里插入图片描述

点击交互

点击NPC后的处理逻辑，打开商店

商店功能和UI框架
加载商店UI。
在这里插入图片描述

商店UI展示逻辑
在这里插入图片描述

点击购买按钮，发送消息给服务器
在这里插入图片描述
服务器处理过程->处理玩家金钱是否足够，背包是否已满,如果条件满足则把道具放到玩家背包里。

从商店购买道具之后，在背包中查看已有道具。

UI框架，控件初始化（Start）,关闭(Close),差异化是控件的显示规则，按钮点击业务处理
比如商店显示道具的购买按钮，而背包不显示。
商店图片点击时，可以发送购买请求。
背包图片点击时，可以发送丢弃请求
在这里插入图片描述

在这里插入图片描述

每个功能都有各自的预制体和脚本
每有一个新的功能增加时，就添加一个预制和脚本，便于拓展

每个UI负责自己的显示内容，在此基础上可以拓展出N个面板，比如HelloWorldPanel

c点击购买->s判断金币数量,物品添加到玩家背包,返回购买结果->

背包->道具

在这里插入图片描述

C打开背包->根据配表ID,显示背包道具
购买的道具数据存放到角色的背包服务器的数据里
在这里插入图片描述

在这里插入图片描述

服务器收到请求
在这里插入图片描述

在这里插入图片描述

道具包含很多信息，信息传输的数据包的大小越小越好
考虑（并发，宽带流量，数据包反序列化消耗等）。
服务器只传物品ID，是为了减少通信数据包的大小
客户端可以对照物品表ID自取所需数据。
也因为如此，很多数功能都有ID索引取对应信息的设计

客户端拿到数据刷新UI组件
在这里插入图片描述

点击显示道具详细信息
在这里插入图片描述

点击显示道具按钮属性
在这里插入图片描述

在这里插入图片描述
道具数据变更->更新背包数据

客户端
在这里插入图片描述

道具逻辑
在这里插入图片描述
背包-道具完。

装备系统讲解

在这里插入图片描述

C点击穿戴->S把道具从背包放到装备栏~~S计算穿戴装备属性~~ ->~~2S通知属性~~ （战斗系统章节章节），装备栏发生了变更->C根据数据刷新UI

C点击脱下->S把道具从装备栏放到背包），~~S计算穿戴装备属性~~ ->~~S通知属性~~， 2C装备栏发生了变更->C根据数据刷新UI
在这里插入图片描述

在这里插入图片描述

脱下装备

服务器处理脱下装备过程

装备系统（完）

商店->交互设计->道具数据设计

道具设计配表->穿戴装备

到这里讲解了基础功能的开发流程的核心，只要掌握了这些思想，很多功能都可以无限复用这套思想去迭代更多的功能。
合成系统，掉宝系统（快速带一带，给开发者积累案例经验）

合成系统

讲解配表，思想，客户端只需要发送合成ID，合成材料读表

地图怪物生成

读表配属性，生成规则代码片段

在这里插入图片描述

在这里插入图片描述
服务器加载数据文件

生成怪物

发送数据包

多个怪物放到数据包里，可以减少发包频率，序列化耗时

客户端加载怪物

客户端实例化怪物，配置各种参数，大小，位置，模型，属性，血条显示等
在这里插入图片描述

进攻怪生成，根据配置编写生成规则，比如出现位置，生成时间，生成数量，频率等。
在这里插入图片描述

在这里插入图片描述

进攻怪逐个出现，会多次发包，60个进攻怪1分钟内陆续出现
也就是说1分钟要发60次通信包。
设计优化方向：3个一组，20次。6个一组，10次。
最终要根据实际情况在玩法和性能之间平衡。

任务系统

递交材料任务，击杀怪物任务，2种

道具掉落,道具拾取

xxxxxxxxxxx

防作弊设计

道具数据由服务器持有，防止用户作弊修改道具数量->数据安全的角度

为什么有些网游会存在外挂呢？
比如《冒险岛》(Maplestory)的全屏攻击，全屏捡取物品，锁血等。
steam上的PC的《绝地求生》,早期有道具透视外挂。
绝地求生
游戏的本身设计是场景里有各种补给道具，在设计上需要玩家地图探索获取。
后来出了作弊工具，玩家可以通过作弊手段查看游戏里每个道具的位置。
显然用了作弊工具的能更快获取更强大的道具，破坏了游戏平衡。

主要因为道具的数据和分布数据由客户端持有和计算，服务器不参与校验。
如何要防止这种作弊手段，就需要把道具的拾取逻辑由交给服务器计算,并且根据玩家的位置通知区域的道具信息。

那为什么会出现这样的设计呢？
开发时间因素：服务器校验数据需要更多的时间设计和编码。
改成防作弊的方案，则需要根据玩家的位置，告知道具信息。
玩家数量太多，则需要做优化处理（AOI）。

对比下来：数据安全的代价，花费更多开发时间，加大了服务器计算压力。加大了运营成本。
当时这款游戏玩法比较创新，制作组更在意玩法是否得到青睐。
制作组结合自身环境，选择了对于他们来说最优解的方案

在这里插入图片描述