文章连载更新中,可以提前领取素材进行预习,自学
素材领取:私信发送 领取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
策划准备:
编写策划文档,作用:便于项目管理。进度推动。多人协同开发。
要开发的游戏越大,要准备的文档越多。
文档是全部都写好了再做开发,还是边写策划边开发?
可以看出项目越大,敏捷开发的效率就越高, 大多数项目都是使用具备快速迭代的敏捷开发思想
所以策划并不是一次性写好的,而是边写边提交给技术和美术。
有需要时还会口头交流作为补充。
这种项目推进方式不仅在游戏行业适用,在其他行业也有类似的思想,比如影视动漫。
踏出游戏开发的第一步:
以本案例举例:整理策划文档“保护水晶不被怪物摧毁。共有42波怪物。怪物强度随着波数跌增”
42个怪物,1个水晶
就需要准备的美术素材怪物和水晶的模型。
我们需要准备多少个模型?
假如42个怪物的样子都不一样,就需要42个模型。
假如怪物都一样,那只需要准备一个模型。
如果等到模型齐全了再施工,明显是不符合敏捷开发思想的。
从设计上我们坚持42个怪物。通过配表设置怪物外观。
美术前期只需提供一个模型即可,表的内容根据美术的产出速度调整即可。
有了怪物之后,自然而然的会关联其他需要的材料,比如数值,血量,攻击力->做怪物的数值表
做好了怪物之后
接着往下制作做英雄人物,也是需要模型,数值
这时候就可以照搬/复用之前的方案。
在做着英雄功能的时候,自然会关联到技能系统,装备道具,升级方案等等。
到了这里,我们就打开了局面,剩下的功能模块会跟着经验的积累,越做越清晰。
最后项目如同抽丝剥茧一样。
最后资料里面附带常见的策划表,可以作为参考模板,积累案例经验。
美术有什么要求?可以参照文档里的《美术资源规范》。
文档定制了场景,特效,UI,模型(贴图,面数)(适合拥有美术部门团队)
大团队和小团队的管理差异建议
美术准备规范可以划分两种,资源归类管理,资源质量管理
我们会从玩法设计,手机硬件要求,运行效果这三个维度讲清楚美术资源的参考标准
哪些手机能够玩到我们的游戏?硬件要求
32种模型同时存在场景中。
32模型一样的怪,和32个怪模型各不相同的怪,内存占用是有大约内存占用是32倍。(模型越多对内存要求也就越高)
至少需要1.5G以上的运行内存(2016后的机子可以运行)
以下是一个模型的数据
怪物数量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配表,加载模型
商店功能和UI框架
加载商店UI。
点击购买按钮,发送消息给服务器
服务器处理过程->处理玩家金钱是否足够,背包是否已满,如果条件满足则把道具放到玩家背包里。
从商店购买道具之后,在背包中查看已有道具。
UI框架,控件初始化(Start),关闭(Close),差异化是控件的显示规则,按钮点击业务处理
比如商店显示道具的购买按钮,而背包不显示。
商店图片点击时,可以发送购买请求。
背包图片点击时,可以发送丢弃请求
每个功能都有各自的预制体和脚本
每有一个新的功能增加时,就添加一个预制和脚本,便于拓展
每个UI负责自己的显示内容,在此基础上可以拓展出N个面板,比如HelloWorldPanel
c点击购买->s判断金币数量,物品添加到玩家背包,返回购买结果->
C打开背包->根据配表ID,显示背包道具
购买的道具数据存放到角色的背包服务器的数据里
道具包含很多信息,信息传输的数据包的大小越小越好
考虑(并发,宽带流量,数据包反序列化消耗等)。
服务器只传物品ID,是为了减少通信数据包的大小
客户端可以对照物品表ID自取所需数据。
也因为如此,很多数功能都有ID索引取对应信息的设计
C点击穿戴->S计算穿戴装备属性->S通知属性,装备栏发生了变更->C根据数据刷新UI
商店->交互设计->道具数据设计
道具设计配表->穿戴装备
到这里讲解了基础功能的开发流程的核心,只要掌握了这些思想,很多功能都可以无限复用这套思想去迭代更多的功能。
合成系统,掉宝系统(快速带一带,给开发者积累案例经验)
讲解配表,思想,客户端只需要发送合成ID,合成材料读表
读表配属性,生成规则代码片段
递交材料任务,击杀怪物任务,2种
xxxxxxxxxxx
道具数据由服务器持有,防止用户作弊修改道具数量->数据安全的角度
为什么有些网游会存在外挂呢?
比如《冒险岛》(Maplestory)的全屏攻击,全屏捡取物品,锁血等。
steam上的PC的《绝地求生》,早期有道具透视外挂。
绝地求生
游戏的本身设计是场景里有各种补给道具,在设计上需要玩家地图探索获取。
后来出了作弊工具,玩家可以通过作弊手段查看游戏里每个道具的位置。
显然用了作弊工具的能更快获取更强大的道具,破坏了游戏平衡。
主要因为道具的数据和分布数据由客户端持有和计算,服务器不参与校验。
如何要防止这种作弊手段,就需要把道具的拾取逻辑由交给服务器计算,并且根据玩家的位置通知区域的道具信息。
那为什么会出现这样的设计呢?
开发时间因素:服务器校验数据需要更多的时间设计和编码。
改成防作弊的方案,则需要根据玩家的位置,告知道具信息。
玩家数量太多,则需要做优化处理(AOI)。
对比下来:数据安全的代价,花费更多开发时间,加大了服务器计算压力。加大了运营成本。
当时这款游戏玩法比较创新,制作组更在意玩法是否得到青睐。
制作组结合自身环境,选择了对于他们来说最优解的方案
《冒险岛》(Maplestory)的全屏打怪,捡物,主要是优先考虑承载人数,所以把大量的计算交给客户端
由客户端负责对消息传输和内存进的加密。即便用了很多加密手段,但始终很难杜绝外挂的出现。
但是即便如此:至今这两款游戏都还在运营。
数据安全要根据游戏的内容和开发时间去做考虑。
比如玩家的金币,钻石,需要付费获得的数值就一定要放在服务器。
其他的数值则需要结合实际情况去考虑。
基础属性,成长
人物属性配表
客户端和服务器的技能设计
技能,动作,攻击配表设计
Buff,Debuff系统
怪物AI
讲解行为树,各种怪物的AI差异
讲解:。。。。。。。。。。。。。。