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

点击观看视频版专题

游戏玩法

游戏目标：保护水晶不被怪物摧毁。共有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）。

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

《冒险岛》(Maplestory)的全屏打怪，捡物，主要是优先考虑承载人数，所以把大量的计算交给客户端
由客户端负责对消息传输和内存进的加密。即便用了很多加密手段，但始终很难杜绝外挂的出现。

但是即便如此：至今这两款游戏都还在运营。
数据安全要根据游戏的内容和开发时间去做考虑。
比如玩家的金币，钻石，需要付费获得的数值就一定要放在服务器。
其他的数值则需要结合实际情况去考虑。

战斗系统

基础属性，成长

属性设计

基础属性

穿戴装备重新计算属性并且派发数据

其他属性

更新最终属性

服务端派发数据

客户端更新属性UI

战斗系统-攻击设计

动作配表HeroAnimationCfg英雄动作配表.xlsx

基础控制器模板

不修改状态机设计，只覆盖每个状态的动画，这样就达到了状态统一，动作各异的效果

程序定死基础攻击速度为0.5秒，攻击帧以20-30帧为基调，所有的攻击动作都必须在这个基调上
否则会加大开发成本，需要为每个人物配攻击帧表
一般只有动作类游戏会为每个人物填写不同的攻击帧
（大多数商店资源都满足20-30帧攻击这个基调）

播放攻击动画

服务器通知其他客户端显示动画状态

攻速设计

战斗系统-技能设计

策划表，设计图，范围判定，伤害判定

服务器(客户都端)技能初始化

技能参数读表配置

客户端加载技能图标

玩家点击按钮显示技能施法距离和范围

玩家松开按钮时，把技能使用消失发给服务器

服务器计算技能逻辑

技能例子2

客户端显示技能特效

战斗系统-Buff系统

效果：眩晕。减速

服务器技能触发buff

BUFF生命周期

Buff结构

BUFF子类，眩晕，减速

广播给BUFF消息

客户端管理BUFF的显示


客户端BUFF生命周期管理

怪物AI
讲解行为树，各种怪物的AI差异

讲解：。。。。。。。。。。。。。。