文章连载更新中，可以提前领取素材进行预习，自学
素材领取：私信发送 领取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通知属性，装备栏发生了变更->C根据数据刷新UI

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

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

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

合成系统

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

野外地图怪物生成，攻城怪物生成

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

任务系统

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

道具掉落,道具拾取

xxxxxxxxxxx

防作弊设计

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

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

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

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

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

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

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

战斗系统

基础属性，成长
人物属性配表
客户端和服务器的技能设计
技能，动作，攻击配表设计
Buff,Debuff系统
怪物AI
讲解行为树，各种怪物的AI差异

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