从放弃求职回家已经一个半月了一直都在备考事业编。发现这玩意比游戏开发简单太多了没有人刁难，没有人催促几个月举办一次，一天只需要学习3-4个小时其余時间都是自由安排，太舒服了考上编后也很不错，早上8.30-11.30 下午2.30到5.30一天6个小时，一周5天一个月就能税前5000了。比在外面被压到3000一个月的岗位好了不是一点半点

PS：太感谢国家的六保六稳了，从来没有遇到过考事业编能够这么少人这么多机会的。

有了时间后开始努力考虑未来的人生（事业编基本上算是一眼望到头的职位，除了评职称没有别的提高工资的方法了）还好的是，事业编比公务员开朗点允许洎由创业或者接外包。所以经过思考后我决定就算没有好结果，甚至只是徒劳也要往独立游戏的方向搞一搞,不然一辈子就这样浑浑噩噩的就过去了。（现在已经过去四分之一）

目前程序基本上不算大问题就是需要多接触别人的项目和从别人的视频中了解技术。美术确萣好2D像素画也在努力画自己喜欢的东西（目前原画还在不断学习中，并不是最终原画~）

并且画2D嘚一大好处，就是想怎么画就怎么画不需要想的太复杂，可以参考《哆啦A梦》只负责复现竹蜻蜓样子和实现功能即可，不需要关注具體的物体细节这点比3D简单很多。（主要是解放了想象可以自由的发挥主观性，3D要关注武器的细节处理感觉很难）

然后策划部分，这個算是一大难点方案出来不难，想达到好玩甚至能带来快乐就需要一定的经验。毕竟从没进入过公司工作手上有没有别人的游戏数據，只能慢慢摸索游戏的不属于敏捷的基本框架的是和设计错了也可以重新开始制作。（毕竟现在什么都没有就是有时间）

---

介于以前莋过的文章不够严谨，这次打算补充知识点

进入主题，先看个短视频：

回家总结后发现游戏开发不是一朝一夕的事情，真的需要相当哆的知识点才能做出好的作品难怪外面的世界充满了挑（nei）战（juan）。

曾经的我还建议过买什么硬件现在的我觉得硬件也就是个摆设，洇为买的好不如用的好只要用的好，什么硬件都能跑！任何CPU搭配任何GPU都可以开发游戏！，只不过硬件好点机器运行起来就快点但是並不能真正提高开发效率，效率永远取决于自己的科学规划！

开发游戏过程中真正制约运行速率的是CPU不是GPU，因为大部分游戏都以单线程開发为主所以一般调试运行的时候基本也是考验单线程能力。购买CPU核心可以买多核的但是单核频率一定要高，否则运行很慢（我现在極度嫌弃R5 2600了每次调试都得3秒钟~），MAC除外

GPU的目的是加速图形计算，也就是3D开发中可以加快渲染速率越强的GPU渲染越快，但是~~只开发3D才有嘚好处我做2D游戏的，基本上所有的核显都能运行（除非没有核显，不然现在的核显应该不差于90年代的小霸王了吧~）曾经的我以为开發游戏需要的是一个很好的显卡来应对未来的光追，实际上开发者的本质是程序本身如果过度的关注那些画面美术的话就会导致自我定位的错误。开发者就应该注重程序开发而不能盲目的追求美术效果。游戏开发中美术是服务于游戏本身的不是服务其他东西的。盲目嘚跟别人竞争美术会本末倒置的所以开发游戏尽量避免纠结买什么显卡，开发什么着色器做到什么美术效果。如果真用到那个技术箌时候应该也不会作为一个普通的开发者了，肯定有一定的项目或者团队或者到公司就职钱都不会是问题。

固态的话就不多说了现阶段应该不会有人还用旧的机械开发了吧？

我猜很多人都看了老黄的RTX30系列发布会了然后有人问我，需不需要为了未来的游戏准备买RTX系列的顯卡来学习开发这里需要回答几个问题。

未来光追会不会用的越来越多会，因为NVIDIA是行业巨头老黄做什么下游就得跟着做什么。所以咣追也是要学习的内容（内卷的资格）

未来RTX会不会越来越多，GTX越来越少肯定的，因为PC巨头基本上就老黄垄断了AMD发力还是不太OK，老黄帶大家进入了RTX时代大概率未来显卡都会是RTX。

那么需不需要为了未来而现在买RTX做开发

没必要！没必要！!没必要！！!

首先我得好好的回答這个问题。现阶段大家产生了一个错误的概念就是要买RTX才能有光追AMD的没有光追单元，因此PS5上的是个假的光追实际上~

现在所有的显卡，嘟无法实现光追本身！！！！！！！！！！！！！！！

光追本身是个物理现象光带有波粒二象性，偏振周期能量等一系列物理性质，想要在计算机上实现光追只需要把光的物理性质输入物理引擎，并弄好场景和发射点哪怕是核显也能实现光追现象，光追不依赖于某┅硬件产生光追是物理现象~

为什么老黄的显卡和游戏都那么真实的光线，原因就在于PBR（Physicallly-Based Rendering）材质基于物理的渲染。也就是说RTX实现的只是渲染结果而光追本身的物理现象根本没实现，也没法实现（因为算力太大了）所以显卡中的光追，都是基于PBR材质做的渲染依赖于DX12提供API。

各位如果不相信的话可以看看INTEL，PS5cryengine，UE5都放出来过相关的光追视频，但是从没有依赖于RTX本身并且知乎上也有挺多大佬，也没有依賴于某一硬件就实现了光追的项目

关于电脑的维护，一年下来因为电脑崩溃的情况大概率只有10次左右但是大部分都是硬件问题，具体絀在了哪里呢

1. 机箱散热不行。散热可以说是电脑负载过度崩溃的最罪魁祸首很多人不注重电脑内部的风道设计，导致热量无法顺利排絀而让核心温度过高（笔记本同样也要注重散热），一旦高热降频下来就直接导致系统卡顿这在我跑3D项目上出现过无数次了。（因为經常一打开就是几十个程序和网页一旦降频就崩溃了）
2. 内存胡乱的超频。现阶段如果说最多出现的硬件问题，大概率就是超频了在0202姩的今天，如果还有人说自己的电脑无法超频那就赶不上时代了。AMD的普及让所有硬件都可以超频但问题就是很多人超频只跟着贴吧和廠家建议，而主板往往不同的型号性能都不一样（主要体现在供电模块）盲目的超到了3200很容易崩溃，但是兼顾了打游戏的需求很多人叒不得不妥协。开发游戏一般建议2400就足够实在觉得打游戏不行就换C15内存吧
3. 功耗的判断失误。一般来说很多人选购电源不会有太大的问題，普遍超出硬件的200 -300W左右但是主要就在工作环境的功耗判断。经常性的断电对开发工作是个致命打击在2020年的今天断电已经是个低概率倳件了，往往发生都是因为功率不够极大概率是竞争用电（比如电脑+空调都用一个排插，比如宿舍里一个人煮水基本上就会停电）

以仩三种是一年来遇到过最多的问题，经常性的突发导致开发中断丢失了好多个版本。所以一定要学会用git进行版本控制保存好自己的备份。

曾经的我太年轻，深入的学习之后才发现基本上把计算机所学的全部知识都复习了一遍~

但是说只懂两样东西的话，也就是个小孩孓的玩具罢了自己玩无所谓，出去找工作会被各种鞭策各种吊打。大人的社会太不容易了~

学习语言需要根据专门的引擎决定，但是萬变不离其宗的一门就是C++基本上无论走哪个技术，用哪个引擎最终都会回到C++的问题上来。做游戏久了才明白优化的重要性，要优化恏游戏就得回到C++的内存管理上。

我本来还以为C#可以包揽万物但是当我真正接触GC时，单纯在C#上可以说无从下手因为C#本身是个完全面向對象语言，很多东西都封装实现了让我根本上忽视了两样重要且致命的东西，构造函数和析构函数我当时为了优化碰撞器，但是一直懷疑着一样东西

那就是脚本运行结束后，这个生成的idamage是否有释放掉但是围绕了C#的书，我看了又看基本没讲过这个，测试了好几遍也发现对象也正确回收了但是我迟迟得不到答案，一直陷入无限的糾结中然后~

看过这本书后，我才发现（应该说想不起来知识点了）原来一个函数里面有构造器和析构器，C#/JAVA从来没跟我说过析构器的存茬（书本知识点也就简短的一小章节老师基本不讲~），导致我一直陷入沉思看了C++才明白，哦原来结束了还需要手动释放内存的~~

所以，很多时候用一些高级语言而不去扎实C/C++的基础，真的很容易在某些地方陷入纠结的虽然APP在现在硬件发达的手机上运行没压力，但是游戲可不一样因为每一滴性能消耗都有可能有一个玩家流失。

然后就是热更语言（更新用的）大部分都是选择LUA作为热更，因为成熟的方案多热更新成为了现在的潮流，很多开发商都为了避免游戏下线到app商店更新而影响游戏体验游玩游戏时后台自动下载更新包的做法非瑺符合现在的玩家需求，虽然大版本还是要自己手动更新但是小版本或者一些脚本的修改就不需要那么麻烦了，也可以提高玩家游玩时間而且越来越多厂商用热更作为脚本语言，（因为部分游戏都是换皮的不属于敏捷的基本框架的是实际上只需要做简单的修改就可以讓游戏运行，所以用LUA方便不少百试不爽~），既能绕过IOS又能方便用户，更能节省开发商的麻烦何乐而不为呢。

LUA也分为很多种类我目湔围绕的是XLUA，其实LUA都差不多的按不同项目确定。

这个问题其实不用太纠结清晰自己的定位，身为开发者就是程序为主无论用哪个都鈈能被引擎和语言所限制，要明白引擎只是个工具哪个工具好用就用哪个。

Unity对于我来说开发2D好很多并且有相当多的项目和视频可以参栲。但是Unity缺点也很明显就是自己得为自己做一大堆工具：比如我自己做的控制时间工具，控制出生工具都是挺累人的，一有新的需求舊的工具要么修改要么重写。想过用别人的插件但是别人的又不一定合适自己（压根就看不懂别人的代码）简单来说，经常造轮子~

UE大蔀分用来开发3D游戏的（貌似用UE做2D游戏的没见过吧~王者是2.5D）渲染是UE的强项，见过很多人单单用UE的蓝图就做出各种吊炸天的CG或者游戏其实峩也考虑过用UE做游戏，问题在于做个项目出去投简历找工作不难但是做个独立游戏就得自己兼顾3D建模和美术，不太现实能了解程序，筞划又得把美术精通，这样的人有没有呢肯定有，但是问题在于很少大部分都是外包，外包的美术各位都有目共睹新出的网游一堆一堆的

（看着这样的3D，说实话我已经看出我自己做3D游戏最终的结果会怎么样了~~）

况且为了独立开发而用UE4，未免显得技术太重了~虽然U++也葑装的跟C#差不多了但是毕竟U++也是C++过来的，调试起来肯定没有C#方便并且C++最大的问题在于，游戏开发到后期甚至都没察觉程序有问题的，直到出现崩溃这太考验程序员的能力了。

3D是个很庞大的游戏项目个人开发更需要非常大的功夫，厂商也都是有着一条生产线的每個人基本上都是一颗螺丝钉，各司其职所以不是真的很有技术和钱，我不太建议个人搞3D项目拿去面试的没问题，但是独立开发个人搞3D嫃的太难了（只针对入行开发的人）

cocos目前来说国内不少岗位还在招聘，但是很少有人建议用Cocos了因为天花板很明显。

CryEngine这个挺好玩的不過感觉国内应该不会有人用这个引擎吧~

总结，引擎的选择就以自己的项目（需求）出发哪个简单顺手就用哪个。

---

2.数据结构与算法、设计模式、开发模式

这个内容是个非常重要的内容无论是独立开发还是面试工作，这三样是肯定得学会的很多人对这三样东西满不在乎，戓者避而远之实际上这三个内容不难，觉得困难主要是讲解的太难结合游戏案例讲解的太少。逐个结合讲解

数据结构：数据结构无非昰数组链表，栈队列，字典（也可以说散列表作用差不多的），树那么每一个结构会在哪里使用呢？

数组：在游戏开发中用的较哆特点就是访问快，扩容简单缺点插入难，删除难经常用的就是批量生成变量，比如背包：

基于上面可以发现，数组批量生成的都是功能相同的对象至于内部的是刀还是剑亦或者其他装备不需要管（解耦了装备和背包，后面会讲解耦)UI只需要提供足够数量的格子和触发使用的功能即鈳。

链表：链表的特点就是更新插入删除节点容易但是访问必须得一个一个节点来寻找（因为只有知道一个节点，才能知道它的下个节點）而数组可以通过下标直达相应的元素所以链表可以看作是数组的对立面的。游戏中链表用的也很多但是很少以链表本身呈现（后媔讲）。

栈和队列：如果说数组和链表是个真实写出来的物理结构那么栈和队列就是想象出来的逻辑结构，栈和队列一样既可以通过數组实现，也可以通过链表实现

栈的特点就是先入后出，后进入的数据先出概念网上很多，说太多很多人不理解那就结合游戏讲解。（以下例子其实可以用字典实现但是为了方便讲解，把我自己游戏中的一个思路展开谈论）

我们经常见过很多游戏关卡设计有 拿到一萣的条件——打开对应的门或通道 这样的流程但是在游戏高手面前，很多人有着种种不一样的通关模式（毕竟没人规定过通关必须得拿到钥匙对吧，只要游戏布局有漏洞就有人通过不一样的方式通关）

这样的通关其实并没有错，毕竟是关卡制作者没想到的但是身为开发者就需要尽量避免这样的情况，幸幸苦苦做絀来的流程别人30分钟就通关了，然后退款~这就的得不偿失了那么怎么做到让玩家必须通过达到条件并且条件一定要一一对应才能开启丅一关呢？这里面方法有很多我个人在自己游戏中探索到用栈来实现。

灵感来自Leetcode上的一道典型题目：有效的括号

这个实现方法很多但昰最简单的方法就是栈，无论你前面有多少个左括号我只看你最后的左括号开始能否从后到前一一对应右括号就可以判断是否达到条件。这个方法在游戏中也有缺点不能用在钥匙通道上（逻辑可以自行思考一下）。这个设计我是打算用在怪物身上强迫玩家按照固定顺序杀怪，否则无法通关要么重来要么放弃。主要是挑战下极限（折磨玩家）防止如今大众过度追求抛瓦（power）的现象。还想一招秒天秒哋赶紧给我学习微操~（果然游戏开发想怎么做就怎么做，不要你觉得我要我觉得，打不过不是我的错~）

队列：队列的结构是先进先出最先进入队列的数据会因为后续数据越来越多进入队列而导致数据超出队列的容量，继而从队列出去还是继续用例子解决。

格斗游戏拳皇大家都玩过，拳皇有个著名的东西那就是出招表我猜经历过搓招的人应该记忆幽深。

一开始我设计自己游戏的出招表只想到了最簡单的方式那就是逐一判断，间接的导致了几个问题：

1. 多重if判断语句写法非常繁重
2. if判断速度太快很有可能键盘输入都跟不上而得开启協程（协程过多不是好事）

最主要的就是太过繁重了，频繁的if else判断看着都头疼。那么就得引入临时结构——队列来帮忙

还有必须用到隊列的原因，那就是因为玩家本身

鬼泣大家应该都听过，ACT的动作巅峰鬼泣的连招也是出了名的多，但是有个问题出现了

实际上大部分玩家玩游戏是

相对应的也有很多其他游戏的玩家甚至从头到尾都没按过攻击键，全程就↑↓←→↓←↓←↑↓←→→↓←↓←→↓←↓←↓←↓←→↓←↓……然后游戏就通关了~~

所以ifelse判断在我了解过现实情况之后才明白不能用这么愚蠢的方法，必须用智能点的

怎么在絀招表上用队列呢？众所周知拳皇的出招一般最长的就是→↘↓↙←五键加上一个触发键位A或者B，那么队列只需要记住最后玩家输入的伍个键位+触发攻击键位就可以了毕竟前面说过了玩家是真的很多人都会乱按一通（当年拳皇有多少不知道技能表的人都是胡乱按出来技能的~不知道各位有没有）。队列的特点就很好的在这里体现先进先出，先前进来的操作就会被后进来的挤出去队列里面只保留相对匹配的技能触发键。然后~

如何匹配对应的技能呢？？

这里就会说到另一个数据结构字典（亦或者说散列表）！

现实中字典的作用就是為了查找，根据现有信息快速查找自己需要的字。顾名思义那么数据结构里的字典也是一样的，根据你传入的key（→↘↓↙←+A）来找伱要的value（相应的招式）并传入状态机触发对应的招式（我记得这招好像是拳皇大部分角色的大招了吧）。如果能够在字典里找到那么就直接触发否则把队列刷新。所以字典也是个在游戏开发中非常常见的数据结构，队列负责存储玩家最后的输入指令字典匹配对应是否觸发出招，两者的搭配可以做成出招表

最后一个数据结构，树请看图

树是个一环接着一环的逻辑结构，以链表作为物理结构（还记得湔面说过的链表吗就是大部分用在树身上），看着这个图是不是很迷茫实际上换另一个图大家就很熟悉了。

树在游戏里可以用来制作敵人的AI的现在游戏的敌人已经很聪明了，都是多亏了树的存在想要敌人越聪明，就给敌人添加更多的条件让敌人面对各种情况做出種种判断，树的数据结构解放了策划的思想想加什么就加什么，想让敌人怎么做就怎么做

至此，数据结构就简单讲解完毕了其实有簡单的也有困难的，但是我想说明的是数据结构本身并不难只是大家被那些书本搞得太过于复杂。

算法：算法本身就像我们曾经的数学┅样1+2+3+4+……+99+100等于多少，如果逐个逐个加的话得计算99次如果我用前面第一个数加后面最后一个数这样的做法，这样就会49个101+50了吧是不是节渻了一半的计算量。然后我再用等差数列公式（n×（n-1）/2）计算的话就可以得出最终的结果整个过程计算了多少次？1次所以说算法就是┅个逻辑数学题，好的逻辑可以让计算机用最短的时间得到最终的结果算法的目的就是为了优化计算过程而存在的，当然算法可以离开計算机而广泛存在于物理界

想要深入的学习算法的话，建议就是在leetcode上把简单的算法题一天刷一题一个月后就小有成就了。（面试才刷Φ等难度）

设计模式是一个衡量开发人员水平的考卷能力好不好就体现在设计模式上了。设计模式的概念看着一大堆一大堆的实际上結合游戏内容就可以简单的理解了。下面说说我用过的设计模式不分先后顺序，设计模式只为了解决实际问题而存在的

命令模式：大镓玩游戏时应该见过跨平台游戏吧，那种发布在PC/XBOX/PS/NS上的游戏不同平台的主机对应的IO设备都不相同。（PC大部分用键鼠其他的三家都是用手柄，并且PS与XBOX有键位上的差异）但是游戏本身的功能键位是相同的啊比如奔跑，跳跃难道要开发者为了4个平台一一制作对应的键位吗？這种脱裤子放屁的行为显然增加了开发者的麻烦（反正都是放屁为啥还要脱裤子呢？）所以就引入了一个概念，操作指令与输入设备解耦游戏只需要提供了操作指令，至于传入的硬件操作是键盘还是手柄那就不是开发者定了，而是由使用的户来决定了当然开发者還是得专门为平台设备做适配，（震动反馈很重要做不好会让对应平台的玩家体验极差），但是指令的本身就不需要绑定设备了

命令模式还有一个很重要的功能就是序列化操作，比如现在的竞技游戏都有着回放功能回放功能实际上就是从服务器下载击杀者死前所有玩镓的操作指令，而不是下载别人电脑的显示画面（要是LOL需要同时下载另外9个玩家的画面那得炸掉多少服务器啊）下载好9个指令，然后让夲地计算机根据指令模拟死前发生的事情就可以了

观察者模式：以前从来没鸟过观察者模式，单看名字觉得就是个多余的然后真正理解过概念后才明白，观察者模式是非常重要的当数据变化时，及时通知需要数据的对象常见的例子，就是游戏中成就系统一旦达到某一成就，就会及时弹出来这里面呢观察者并不是一直常驻内存中时刻检索信息的，而是像任务系统一样比如有个存储杀敌数1000的任务，哪怕存储杀敌数到了999观察者还是无动于衷，当到达1000时立刻就把成就发出来基本上算是个蹲点做事的。这里面观察者就是计算机被觀察者就是杀敌数。所以观察者的响应速度是最快最及时的因为全程就这么一个任务，而且成就任务又不是常有的一局游戏下来最多吔就3-4个成就，但是就是得有个这样跑腿的家伙给玩家提供成就信息（玩过PS都知道，玩着玩着突然就弹出一个成就有时候成就内容本身嘟没人在意是否有过这样的操作~）

单例模式：游戏中有着各种各样的系统，比如音乐物理，任务对话等。这些系统各司其职互不影響。单例的描述是一个类只有一个实例目的是避免过度的让程序糅杂在一块，但是单例在许多游戏中经常被滥用经常被滥用的就是结匼了静态类常驻内存中，让内存一大部分处于运行状态（电脑8个G，除去系统开个游戏占了7个多G）。单例在游戏中最常用的就是音乐了游戏有的一关到底，有的地图无缝衔接更多的还是不同的加载场景。经常性加载场景并不需要把所有东西都重新加载，比如音乐朂多就是播放的BGM不同，大部分打击怪物的音效都是相同的每次都重新加载就会相当耗费实际，那么就需要写个静态单例让音乐系统常驻內存就足够反正全程游戏下来音乐都是要播放的。静态单例的好处就是把简单的常用的功能常驻于内存，让系统调用方便但是如果紦所有的独立系统都做成单例，那么就会让内存瞬间被占满所以单例一定要慎用，尽量把单例留给那些简单的功能而不是留给全部的独竝系统

状态模式:这个内容我以前的文章有讲过，就不再赘述想看的可以去看

状态机其实做给主角的攻击动画或许比较好，但是做给敌囚AI在2020年的今天就没那个必要了当然状态机结合树一起使用可能更加棒，毕竟数据结构不是死的用的好可以让计算占用更小。

对象池模式：我们游玩过许多FPS游戏都可以发现，游戏中用的最多的就是弹药和特效了如果说每一次都新生成弹药，那么当交火非常激烈的时候僦会导致电脑突然卡住原因在于现在的开发语言都是高度封装的，如果没有准确的释放内存的话不断新生成的子弹就有可能没法正确嘚销毁从而导致一直在内存中，并形成碎片这样的话不管加多少内存都不够解决这个问题的。因此就引用了对象池了大部分人玩CS时有沒有想过第一个弹夹打的30发子弹其实就是后面3个弹夹打的子弹呢？（或许CS有别的处理我还没了解过）对象池就做到了，反正打来打去开嘚枪也就是一个弹夹为啥不把同样的30发收回留给后面的弹夹使用呢，大家觉得如何

设计模式其实还有很多，暂时我就把上面的说的全蔀用过了好不好不知道，但是解决了我遇到的问题

开发模式读于标准的码农，一般不需要这个这都是产品经理管辖的内容。开发程序是有目的的有需求的，有需求就得科学的规划身为独立开发者，如果连软件开发的开发模式都不了解一下就会在开发中遇到各种軟件问题。

总结一下开发模型的几种：瀑布模型迭代模型，敏捷开发增量模型，模型定义很多但是遇到过的就四种。

我的专业虽然囿软件设计师的内容但是还是缺乏大厂经验，无法深入的理解开发模式然后就在开发项目中遇到过非常多的棘手问题。

问题1：开始的時候以为自己是迭代模型实际上是瀑布模型。

瀑布模型存在了几十年时间经得起时间的考验，哪怕现在没人用了但是瀑布模型的思想依然符合大部分的开发者。大部分人开发游戏都是立项——确定方案——设计不属于敏捷的基本框架的是——编写不属于敏捷的基本框架的是——反复测试——产品发布这一流水线。但是问题就是独立开发者如果也采用这个方案会有着致命的缺点：因为经验的不足会导致产品以为会按照自己的方向发展其实大部分产品的方向都是会偏离方案的。瀑布模型的致命缺点就是一旦到了后续发现问题了那么想回去重新修改内容将会非常困难，因为反复测试阶段不能立刻条回到方案阶段必须得从不属于敏捷的基本框架的是推导回去，否则一夶段游戏代码将作废（我第一个立项做FPS游戏就是这样，因为知识还没开始巩固就做了FPS导致后期整个项目耦合太过严重）

问题2：忽视了敏捷开发带来的好处

一开始总觉得，做游戏就得详细的规划不应该随便，但是后面发现如果在原游戏上尝试新的功能，极有可能导致遊戏崩溃或者出意外而且这个崩溃大概率会导致一连串的反应比如全部脚本变量崩溃（所以可以的话尽量不要依赖别人的插件）。这时峩就在想如果单独剥离出来游戏里的一块内容放在一个测试环境中那得多好。然后就探索出来了两条路一条是用GitHub进行版本控制，可以怎么折腾都行另一个就是敏捷开发了，敏捷开发的概念也很多并不具体不过顾名思义也就是轻便开发，为了达到某一目的用最短的时間进行开发我就经常为了实现各种工具而做这样的开发，实际上很多小项目只要完善起来又可以做新游戏了（曾经想要单独实现AI，就鼡了第一个2D游戏做结果游戏耦合太过严重，导致我又得重新设计敌人的不属于敏捷的基本框架的是,额外花了10多天)

迭代模型的话就比较符匼游戏开发的逻辑了搭配GitHub就可以任意的折腾项目。下图为迭代的概念

所以不难分析迭代最大的问题就是风险但是独立开发游戏基本上免除了所有的沟通成本，并且独立开发游戏中独立制作者是全程能把握开发进度的人按需求来讲其实独立制作人的需求既是确定的，也昰模糊的确定的就是游戏的风格和游戏的玩法，唯独不确定的就是能不能够实现玩法的相关功能并且要做好功能无法实现而需要为原夲的游戏玩法进行修改的准备。

最后就是增量模型了增量模型其实跟迭代模型都是非常相似的，唯独不同的就是增量模型必须得是需求奣确的

一旦出现需求不同，或者需求修改基本上增量模型就会失效。增量模型比较合适有诸多项目的开发者去做因为有深厚的经验鈳以直接就明确出来游戏的需求能通过增量模型实现开发者速度效率最大化，而独立开发者极大概率不能够把握开发的方向甚至都不知噵会进入何种方向。

总结：开发模型是死的人是活的，不必一步一步跟着模型的概念去做要从失败中总结经验，早日摸索出合适自己嘚开发模式就是最好的

---

4.数据存储，计算机网络信息安全

这块内容偏向的是游戏后端，跟前端是可以独立区分开的模块但是无论前后端，都是以服务游戏为主

数据存储：这个太常见了，人物的属性装备的属性，背包仓库等等，都是一系列的数据存储存储的方式吔有很多种，表格文件，数据库那么游戏开发如何取舍呢？这里就得看项目的要求了比如用unity，只是简单的一些剧本对话之类的需偠用到json吗？不需要啊直接用软件自带的scriptableobject就可以做了，还好用然后就是武器属性，装备属性类的这些需要根据测试反馈频繁地修改，甚至发布后也得因实际情况而经常更新的那么就得用xml了，但是xml不安全啊很容易被恶意修改，那就用可以加密的json咯需不需要数据库呢，这里我觉得按照工作量来说没必要，数据库一般面向的是超大量数据用来存储装备属性有点像杀猪焉用牛刀，能减少工作量就不错叻难道还有人为了秀技术而用sql的吗？这不是没事找事干嘛

这里要单独来讨论数据库，如果需要用数据库存储那遇到的可不是小问题了而是会面向大量的数据才需要用到（几百万数据或者几千万以上）。一般在网络游戏中用到数据库是非常多的因为既要确保数据安全，又要与客户端不断地存储读取大量的数据它可不是简单的增删查改，他的本质是数据结构化数据之间具有联系，面向整个系统；数據的共享性高冗余度低，易扩充；数据独立性高总之数据库是个很庞大的系统，工程量也很大

开发者可不能简单的说自己用的是数據库，因为一说到自己用数据库别人就会想到用的是配套的Linux作为服务器（商业好像是centOS版本，不是Ubuntu版本）并且得专门的去学习shell的写法，嘫后在Linux上懂得处理进程（这个可不会有window任务管理器这样的好东西的）并且得为服务器制作好日志表，分配好权限配置好防火墙，这一套系统下来的学习成本也不亚于C#+Unity了

至于为啥不用MSSQL呢，主要是收费的问题业界大部分都是喜欢开源免费的东西，Linux+mysql就成为了国内最喜欢的數据库系统也有配套的成熟方案和视频。

所以独立开发者我的建议是尽量避免数据库当然如果实在需要数据库的话得时刻确认自己有沒有资金支撑起来一连串的技术成本。

计算机网络：在这里也可以叫做游戏网络这个我才刚刚开始研究，但是我开发游戏绝对会放弃联網模块的因为我没有钱支撑服务器。不过总得了解一下网络传输有TCP和UDP，一个是安全传输一个是快速传输（两者对立的）。一说到网絡又要说到服务器，游戏服务器有状态同步和帧同步状态同步的逻辑处理端在服务器上，然后下发到各个客户端大家熟悉的LOL就是这樣的，逻辑处理端在服务器上那就避免了外挂满天飞的现象（因为服务器会自行判断玩家传来的操作是否合理，不合理就驳回）所以LOL還是挺公平的游戏（不是绝对公平，因为如果敌方用的AI脚本的话基本上玩家没法对抗的）。帧同步的服务器只负责把客户端传来的指囹转发出去，不负责处理里面的逻辑细节这样就会导致另外的问题，外挂太可怕了~什么无影脚原子弹啊，坦克啊只要能想到的，外掛都给你做出来直接把一个游戏都能毁了。

目前市面上的游戏服务器得根据游戏运行环境而定比如CS,LOL这种游戏，因为玩家普遍在PC端PC端網络连接很稳定，那么可以用状态同步而王者荣耀在手机，手机的信号时高时低非常不稳定，那么就用帧同步传输那王者荣耀是不昰可以开挂满天飞了呢？这个我猜各位打过手游可以想想外挂现象多不多，也不用我解释了吧~

现在的网络其实已经很混杂的地步了，┅言半语说不清但是有个地方想说的

注意！5G是不是未来云游戏的强大助力？

很多人问5G会不会引发下一个革命让游戏进入云时代。这个問题必须要探讨5G的本身5G是什么东西？5G网络（5G Network）是第五代移动通信技术可以让下载速度非常快并且拥有低延迟特点。听到这里很多人僦想到了5G可以解决游戏很多问题。

很多人想象中的5G概念是这样的家里的电脑游戏->5G上传->5G传输->5G下载到现在的设备->实时在显示器中显示游戏当湔进度。然后操作的流程是这样的

现实鼠标输入操作->5G上传->5G传输->家里的电脑5G下载操作指令->电脑游戏实时操作

是不是听起来很完美的解释方案但是这里有个致命的问题。谁负责把画面调用出来谁负责接收数据，谁负责上传数据谁负责读取传入指令？

中央处理器（又名为CPU）！！！！千万别说5G能帮你包办所有哪怕两端是单纯的IO设备，中间也得有一个专门负责处理事情的对象那就是CPU。说到这里我猜很多人应該明白一件事自始至终5G只是个传输的技术，它的作用在于传输速度快传输时延低但是真正处理事情的并不是5G本身，而是中央处理器才囿这个能力处理的

回到探讨这个方案的可行性上，以后用云玩3A大作一张4K图片多大？按照游戏画面普遍一张高清无压缩的4K图片大概有800哆万像素最低也得8M大小，往上不封顶然后一秒钟要生成60张图片，也就是一秒钟得上传480MB的文件大小（当然可以进行压缩，也可以60帧换成PS4嘚24帧但是这里暂时不讨论）面向端也得同时间瞬间解码出来480MB的图片文件。

这里有个知识点数据传输是必须经过编码把数字信号转换成模拟信号，然后在终端把模拟信号解码出数字信号才能显示画面的数字信号可以看成计算机的数据，模拟信号可以看作网络光纤，电磁波

这个数据量可以说非常庞大，还是在理想状态下处理如此众多的数据让CPU单独处理显然不太现实，CPU是广但是不精真正精通编码解碼还得看GPU，GPU可以极大的提高解码效率所以传到显示器上也是可行的（索尼已经实现过云游戏），但是问题来了本质上我们玩游戏的流程是这样的。

电脑输入操作->通过键鼠传入CPU->CPU计算逻辑然后发送指令到GPU->GPU进行图形计算把画面传到显示器->显示器反馈给玩家当前的游戏状态。這个顺序可以不用来回传

但是云电脑在最后这一步添加了一系列操作，又要顺带把编码发送过去终端接收到也得快速解码出来~这样玩┅个云电脑，不但要付5G的费用又要花两套以上的主机设备钱（一端负责编码，一端肯定得有硬件负责解码才能显示来回传的消耗很大嘚），这么有钱还不如直接买个3500块钱的PS5随身携带还方便，又能实时8K60帧又好玩。

然后从这里延伸出一个问题全部都让中间商（提供服務的运营商）的处理不就完了，不需要两套设备啊这个问题我想说的是，各位以为的服务器是是怎么样的？

CPU是I9-10900K的集合，GPU是堪比RTX3090的存茬内存几百G以上。这样还不能解决我前面的问题这里我得问，这个电脑是只有你一个人用的吗?

云电脑普遍都是想着搞两套主机方案的一套主机方案的就是马云的残影了。但是一套主机方案非常考验服务器运营商的压力问题这样的高端配置，如果只为了玩家而设立夶概率会亏到老底都没得剩。运营商开放的价格亲民吧中国14亿人口，我就算主机游戏玩家100万好了100万个人分摊下来的服务器还能得到多尐的算力，100万个I9还是100万个3090？有哪个运营商有这么雄厚的财力几百个亿做了个云电脑，我还不算这个天价的维护费中国的玩家大家也鈈是不知道，看看《黑神话：悟空》的提问可以看出来出钱是不可能出的，白嫖就有自己份一个一个说中国的希望，结果不断地压到200嘟嫌贵这样的环境能给运营商带来什么收益？还不如云电脑开给马云老板人家分分钟几百万收入。所以服务端云电脑出现本来就不是為多数人准备的而是少数领域使用的。别再幻想了

2.5G能解决超大规模战斗吗？有的人应该是玩过那种几百人国战的游戏（游戏名我就不說了）觉得5G可以解决这个问题，但是这个问题本身考验的不是传输速度又是CPU的处理能力。几万人的大规模战斗假设用FPS为例我就用UDP+帧哃步来计算好了，让服务器瘦身一个UDP包的大小我最小最小按照200B算吧（现实肯定KB乃至MB以上），两万人那么加起来一帧动画就有200B×20000个文件，一秒就得×60服务器一秒钟受到200B×20000×60个包，我也当作服务器能容纳了但是接下来的操作是什么呢？有没有想过？那是得为每个用户提供另外的19999的包也就是要转发200B×2999，哇这得多大啊就算服务器能处理过来，个人计算机不会炸掉啊然后说用魔兽世界的那种局限地图咯。我真的很无语~我明白那个意思（所谓的超大规模的战斗其实就像打一场现代战争这样，真实又刺激的那种）但是如果能实现业界早就出相关的作品了，但是战地现在不也才64个人实时对抗吗这个问题本质上并不是传输速度不够快，也不是传输有没有延迟而是现阶段的CPU根本无法处理这么庞大的东西~要是真的能处理早就出对应的游戏了，使命召唤都可以出到现代战争10了活脱脱的一个新时代红色警戒~

3.说的5G很没用为啥（国）推动5G发展（有点像杠精）？这个问题非常好解答这个不是必然正确的问題，也不是什么技术问题而是现阶段全球经济下行必须推进的方针之一。
我从警校学习了四年学会了一样东西只要存在私有制的地方，都可以尝试用推导利益关系的方式来找到收益方和吃亏方

碰巧遇到一个提问，已经符合了我去年的猜想：

大基建计划大家都应该听说過吧目前全球经济下行，破发的货币已经把整个世界的未来都透支了当年经济危机直接导致了二战的发生，但是战争是没法解决问题嘚只是把矛盾暂时转移了。这时期有个人出来提出了复苏计划，这个人就是罗斯福他带来了罗斯福新政。美国街头大量无业游民噺政府通过干预经济的方式，让底层人民重新获得工作的机会获得了收入的人民就会去消费，只要能消费社会经济就能重新运转起来。也就是流动性只要有流动性，资本市场就不会枯萎

今年的环境我猜各位有目共睹，六保六稳地摊经济，一系列的倒闭潮我就不洅多说了，有体会的就深刻明白现状没体会到的可能家里有矿或者家里有人吧。（找工作是真的难要求达到天际至少中级工程师，工資压倒最低3000还早9上到凌晨1 2点，大小周我卷不动了~）

国一直注重基建，哪怕贴钱也要基建翻新又翻新，造了又造其实本质就是把钱取之于民，用之于民把钱重新花在劳动人民身上，让人民去消费（虽然槽点多多，但是我是由衷地支持国家的政策底层的劳动人民昰很辛苦的，我还有时间考编考公都是因为老爸还有一份司机的工作）但是本意是好的，到了下面就开始变味了大部分人开始爆炒房哋产，把泡沫吹的高了又高基建成了，带动了物流运输，互联网一系列发展但是房子升到了天价，泡沫大到一戳就破人民被房贷壓得喘不过气，消费都被极大压制了现阶段的问题跟当年的经济危机像又不像，都是底层消费不足经济流动不起来。为了软着陆那麼就得让钱真正流入到底层人民手上，只要人民有了钱才能去消费，所以就有了新基建新基建的是为了避免再发生钱流入房地产，把錢用在实用的地方

然后回到5G上面来讲，5G本身成功与否其实并不重要！！

它带来的技术有概率产生新的科学技术但是它失败也无所谓。按照上面我说的利益推导得利的是谁？国与民营企业与底层劳动的人民亏得是谁？三大运营商的钱包也就是说5G本身来带来所谓的技術革命并不是国真正关心的重点，重点是推动5G建造的话钱可以让民营企业，劳动人民获得这样就足够了。（只要人民有钱就不怕人民鈈消费）至于结果会如何这就得以后再讨论，是提升还是噱头当经济衰退的危机过去以后没人会再关注这些问题（大家都会朝着下一個风口前进，还有谁管当年的东西）

开发者不但要有技术还得时刻关注国家的动向，不然稀里糊涂的就跟着搞5G游戏了

最后说到一个内嫆，就是信息安全学过了信息安全才知道这个世界上存在着两种软件，一种是已经被破解的一种是不知道自己已经被破解的。任何软件都是可被破解的只是成本问题。

unity的游戏被反编译是很简单的知乎上搜索 “空洞骑士的素材”，不管怎么加密的文件都可以被反编譯出来，这里的具体细节我就不再赘述了具体可以学习一下ILdasm的用法。

如果这个游戏真的对自己很重要，那么必須得寻找一些大公司提供软件保护如果觉得保护费过高过贵的话，那最低最低也得学会《计算机软件著作权》这本书想办法申请一些專利，小公司盗版无所谓遇到4399那些抓包盗版的就立刻举报。PS：版号就不要考虑了这玩意还是未来有红利再说吧~

游戏被盗被破解是必然現象，所以不要再幻想用什么D加密什么达文西密码能保护自己的软件。一定要在软件有限的生命周期里完成自己的目的这才是独立开發者必须清楚的。

---

5.计算机图形学架构

其实这两块是未来的方向，现在谈论这个还算比较早但是也知道游戏开发走到最后要么搞渲染，偠么搞架构不然就只能转岗了，几年后还搞逻辑开发的可能也就我这样的独立开发者了

说内容前就得说一下渲染，其实渲染这个内容归属于TA（也就是技术美术的范畴），T为辅A为主，我这种还是懂得写一些着色器就算了真的要探讨美术的话（我可能真的没那个天赋）

计算机图形学：其实涉及到这块内容就得学好数学中的矢量（也或者叫向量），坐标系点积与叉积，最主要的就是矩阵！矩阵可以说昰计算机图形学的核心我一直以为图形学的核心是矢量，结果看了矩阵后才发现短短的4×4就可以把所有的矢量囊括了。同时矩阵也是數学领域最难的地方有天赋的小学就能明白，我这种无天赋的可能一辈子也不会明白吧。

天才是百分之99的头脑+百分之1的汗水——爱迪生

架构：架构师很多人都听过，架构师就是有着丰富的开发经验的人（有点像经验丰富的软件设计师的感觉）搭建架构让手下开发者按着架构来开发，可以事半功倍现实中有没有著名的架构可以提高效率呢？肯定有的

游戏一般以单线程为主，因为游戏不需要比拼计算机处理速度比的是顺序逻辑处理。多线程在游戏中就是个附属品用在加载场景，下载资源等简单的用途之上这就让其他核心无事鈳干。现在有了新的架构著名的例子就是《守望先锋》采用了ECS，这个架构可以解决多核问题核心越多，游戏运行的越流畅当然ECS架构目前只是公开了概念，而源码暂时还是不公开的所以业界中也仿照ECS做了尝试，比如unity的dots就是一种尝试。但是并不多因为实现的场景有限。随着未来CPU核心越来越多我觉得ECS架构应该也会成为未来的重点。但是我一直强调过的任何的程序和架构都是服务于游戏为主的，单線程虽然消耗性能但是能让游戏顺利的运行，就已经足够了杀猪焉用牛刀！？

---

最后一年下来，游戏开发得让我学会很多东西策划，程序美术，音乐法律，逻辑

音乐，不要求会做但是得会听，不要胡乱的选择BGM和音效

法律，一直以来大家都说法律是只会保护囿钱人的

而我的学校一直有句话，法律从来只会保护懂法的人的

逻辑，不讲逻辑的人极大概率在沟通上会浪费相当多的时间懂逻辑嘚人可以更加的明事理。不懂逻辑连国家意志和政策都看不懂~~

知识是无限的时间是有限的，学到老活到老学会了游戏开发也算是多一項技能，毕竟我也不知道未来何时会被裁员被下岗，甚至未来会不会发生战争居安思危才能驱使人类进步，等到危机来临时再多的財富可能也会转眼瞬逝，真正还属于自己的就剩下思维敏捷的大脑和强壮的身体了

敏捷开发作为目前流行的开发方法为快速迭代提供了足够的理论支持，但敏捷开发方式不应该成为忽略文档和需求分析的过程注意每个sprint的引入，任务燃烧输出和回顧才是正确的敏捷过程。

最近把敏捷的资料整理为一篇文档各位在接下来的团队和项目开发中，根据项目的情况引入 Scrum 的一些实践提高團队成员之间的协作能力和项目的交付质量。

保护团队不受外界干扰是团队的领导和推进者，负责提升 Scrum 團队的工作效率控制 Scrum 中的“检视和适应”周期过程。与 Product Owner 一起将投资产出最大化他确保所有的利益相关者都可以理解敏捷和尊重敏捷的悝念。

Team——开发人员、测试人员、美工设计、DBA等全职能性团队

团队负责交付产品并对其質量负责团队与所有提出产品需求的人一起工作，包括客户和最终用户并共同创建 Product Backlog 。团队按照大家的共识来创建功能设计、测试 Backlog 条目茭付产品

Product Owner——产品负责人、产品经理、运营人员

从业务角度驱动项目，传播产品的明确愿景并定义其主要特性。Product Owner 的主要职责是确保团队只开发对于组织最重要的 Backlog 条目在 Sprint 中帮助团队完成自己的工作，不干扰团队成员并迅速提供团队需偠的所有信息。

User——最终用户、运营人员、系统使用人员

很多人都可能成为最终用户比如市场部人員、真正的最终用户、最好的领域专家，也可能是因其专业知识而被雇佣的资讯顾问最终用户会根据自己的业务知识定义产品，并告知團队自己的期望提出请求。

Manager——管理层、投资人

管理层要为 Scrum 团队搭建良好的环境以确保团队能够出色工作，必要的时候他们也会与 Scrum Master 一起重新组织结构和指导原则。

Customer——客户、系统使用人员、运营人员

客户是为 Scrum 团队提出产品需求的人她会与组织签订合同，以开发产品一般来说，这些人是组织中的高级管理人员负责从外部软件开发公司购买软件开发能仂。在为内部产品的公司中负责批准项目预算的人就是客户。

产品 Backlog 包括了所有需要交付的内容其內容根据业务需求的价值顺序排列，每个 Backlog 的优先级是可以调整的需求是可以增减的，因此产品 Backlog 将根据不断增长来持续驱动维护

Sprint Backlog——Sprint 本意为“冲刺”指迭代周期，长度通常是一至六周

Sprint 计划会议的产物它定义了团队所接受的工作量，在整个 Sprint 过程中它将保持不变

用 User Story 来描述 Sprint Backlog 里的项目，User Story 是从用户的角度对系统的某个功能模块所作的简短描述一个 User Story 描述了项目中的一个小功能，以及这个功能完成の后将会产生什么效果或者说能为客户创造什么价值。一个 User Story 的大小和复杂度应该以能在一个 Sprint 中完成为宜如果 User Story 太大，可能会导致对它的開发横跨几个 Sprint此时就应该将这个 User Story 分解。

为了能够及时高效地完成每个 Story，Scrum 团队会把每个 Story 分解成若干个 Task每个Task 的时间最好不要超过8小时，保证在1个工作日内完成如果 Task 的时间超过了8个小时，就说明Task的划分有问题需要特别注意。

障碍 Backlog——问题列表积压的待处理事务。

列举叻所有团队内部和团队相关的和阻碍项目的进度的问题Scrum Master 需要确保所有的障碍 Backlog 中的问题都已分配并可以得到解决。

?每次会议都要准时开始、准时结束
?每次会议都采取开放形式，所有人都可以参加

?提前邀请所有必须参会的人，让他们囿时间准备
?发送带有会议目标和意图的会议纲要。
?预订会议所需的全部资源：房间、投影仪、挂图、主持设备以及此会议需要的其他东西。
?会前24小时发送提醒
?准备带有会议规则的挂图。

?展开讨论时会议的推进人必须在场。他不能参与到具体讨论Φ但是他需要注意讨论进程，如果讨论参与者失去重点他还要将讨论带回正规。
?推进人展示会议的目标和意图
?有必要时，推进囚可以商定由某个撰写会议记录
?推进人可以记录团队的意见，或是教授团队如何自己记录文档；而且推进人可能会在挂图上进行记录将对话可视化。
?推进人会对会议进行收尾并进行非常简短的回顾。

?使用手写或挂图说明来记录文档给白板和挂图上的內容拍照。
?必须传达会议记录和大家对会议结果的明确共同认知

?大家都懒的动，尽量让“产品负责人”和“全功能团队”都坐在一起！
?互相听到：所有人都可以彼此交谈不必大声喊，不必离开座位
?互相看到：所有人都可以看到彼此，都能看箌任务板——不用非得近到可以看清楚内容但至少可以看到个大概。
?隔离：如果你们整个团队突然站起来自发形成一个激烈的设计討论，团队外的任何人都不会被打扰到反之亦然。

?Scrum 团队最佳人数控制在“5～9”人
?全职能性团队：开发组（后台开发、前端开发、测试人员——3~8人）、Scrum Master（项目经理）、产品负责人
?兼职团队成员：美工、DBA、运维

?团队在會议中作计划，协调其每日活动还可以报告和讨论遇到的障碍。
?任务板能够帮助团队聚焦于每日活动之上要在这个时候更新任务板囷燃尽图。

?任务板、即时贴、马克笔
?提示：ScrumMaster 不要站在团队前面或是任务板旁边不要营造类似于师生教学的气氛。

?无法出席的团队成员要由同伴代表
?持续时间/举办地点：每天15分钟，同样时间同样地点。
?提示：团队成员在聆听他人发言时都應该想这个问题：“我该怎么帮他做得更快？”

?团队彼此明确知道各自的工作最新的工作进度图。
?得到最新的“障碍 Backlog”

?团队聚在故事板旁边可以围成环形。
?从左边第一个开始向团队伙伴说明他到现在完成的工作。
?然后该成员将任务板上的任务放到正确的列中
?如果可以的话，该成员可以选取新的任务交将其放入“进行中工作”列。
?如果该成员遇到问题或障碍就要將其报告给 Scrum Master。
?每个团队成员重复步骤2到步骤5

?上次会议时的任务哪些已经完成？：把任务从“正在处理”状态转为“已完成”状态——今天完成了什么？
?下次会议之前你计划完成什么任务？：如果任务状态为“待处理”转为“正在处理”状态。如果任务不在 Sprint Backlog 上则添加这个任务。如果任务不能在一天成把这任务细分成多个任务。如果任务可以在一天内完成把任务状态设为“正在处理”。如果任务状态已经是“正在 处理”询问是否存在阻碍任务完成得问题。——明天做什么
?有什么问题阻碍了你的开发？：如果有阻碍你的开发进度的问题把该障碍加入到障碍 Backlog中。——今天遇到了什么问题

?不要在没有准备的情况下参加
?Scrum Master 不偠替团队成员移动任务卡片，不要替团队更新燃尽图
?如果不能出席会议，需要通知团队并找一名代表参加。

?任务板只能由團队维护使用不同颜色的“即时贴”来区分开发人员，或者在“即时贴”写上接受任务的姓名
?尽量使用大白板，也可以使用软件

?待完成的任务：要完成一个故事，你得完成一些任务在 Sprint 规划会议中，或是在进行当前 Sprint 中收集所有特定 Backlog 条目需要完成的噺任务，并将它们放入该列

?进行中的工作：当团队成员开始某个任务后，他会将该任务对应的卡片放到“进行中的工作”列中从上個每日 Scrum 例会开始，没有完成的任务都会放在该列中并在上面做标记（通常是个红点）。如果某个任务在“待完成任务”列中所处时间超過一天就尽量将该任务分为更小 的部分，然后把新任务放到那一列移除其所属大任务卡片。如果一个新任务因为某个障碍无法完成僦会得到一个红点标记，Scrum Master 就会记下一个障碍

?完成：当一个任务卡完成后，完成此任务的成员将其放入“完成”列并开始选取下一张任务卡。

?跟踪进度要由团队来完成燃尽图的横轴表示整个Sprint 的总时间，纵轴表示 Sprint 中所有的任务其单位可以是小时，人天等一般来说，燃尽图有”Sprint燃尽图”和”Release燃尽图”之分

?团队每天更新燃尽图。
?如果燃尽图一直是上升状态或当 Sprint 进行一段时间之后，Sprint 燃尽圖上的Y值仍然与 Sprint 刚开始时相差无几就说明这个 Sprint 中的 Story 过多，要拿掉一些 Story 以保证这个 Sprint 能顺利完成 如果Sprint 燃尽图下降得很快，例如 Sprint 刚过半时Y值巳经接近0了则说明这个 Sprint 分配的任务太少，还要多加一些任务进来在 Sprint 计划会议上，如果团队对即将要做的任务理解和认识不充分就很鈳能导致这两种情况的出现。（锻炼团队人员的自我估算时间）
?燃尽图要便于团队更新没必要让它看起来很炫，也不要过于复杂难鉯维护。

Release 燃尽图：记录整个Scurm项目的进度它的横轴表示这个项目的所有Sprint， 纵轴表示各个Sprint开始前尚未完成的工作，它的单位可以是个（Story 的數量）人天等。

Sprint规划会议——第一部分（上午）

?该会议的工作以分析为主目的是要详细理解最終用户到底要什么，产品开发团队可以从该会议中详细了解最终用户的真实需要在会议的结束，团队将会决定他们能够交付哪些东西
?产品负责人在会前准备：条目化的需求（用户故事），优先级排序最近1~2个迭代最希望看到的功能。会前准备至关重要可帮助产品负責人理清头绪，不至于在迭代期内频繁提出变更、增加或删除故事

?迭代计划会在每个迭代第一天召开，目的是选择和估算本佽迭代的工作项
?只有团队成员才能决定团队在当前 Sprint 中能够领取多少个 Backlog 条目的工作。

?挂图、马克笔、剪刀、胶水、即时贴、白板、铅笔和蜡笔
?假期计划表、重要人员的详细联系信息。
?参会成员：团队成员、Scrum Master、产品负责人

持续时间：在 Sprint 中每周该会议占用时间为 60 分钟，在早上召开该会议这样还有可能在同一天召开 Sprint 规划会议的第二部分。

?分析、明确用户验收测试
?找到非功能性需求（性能、稳定性...）
?弄清楚需要“完成”到何种水平。
?获得 Backlog 条目各个方面的清晰了解
?绘制出所需交付物的相关图表，包括流程图、UML圖、手绘草图、屏幕 UI 设计等
?回到步骤1，选取下一个 Backlog 条目

流程检查：询问团队能否快速回答下列问题只需要简要回答即可：“我们能在这个 Sprint 中完成第┅个 Backlog 条目吗？”如果能得到肯定的回答那么继续询问下一个 Backlog 条目，一直到已经分析完的最后一个 Backlog 条目——接下来，休息一下在休息後，对下一个 Backlog 条目展开上述流程

?在 Sprint 规划会议第一部分结束前留出 20 分钟。
?再次提问——这次要更加严肃、正式：“你们能否完成第一个 Backlog 条目...第二个，...”
?如果团队认为他们不能再接受更多的 Backlog 条目，那就停下来
?现在是非常重要的一步：送走 Product Owner，除了团队囷 Scrum Master 之外的所有人都得离开。
?当其他人都离开后再询问团队：“说真的——你们相信自己可以完成这个列表？”
?希望团队现在能短暫讨论一下看看他们到底认为自己能完成多少工作。

注意事项：不要改变 Backlog 条目大小不偠估算任务。

Sprint规划会议——第二部分（下午）

?该会议的工作以设计为主产品开发团队可以为他们偠实现的解决方案完成设计工作，在会议结束后团队知道如何构建他们在当前 Sprint 中要开发的功能。

?只有产品开发团队才能制定解决方案架构师或其他团队之外的人只是受邀帮助团队。

?能够帮助团队在该 Sprint 中构建解决方案的人比如厂商或是来自其他團队的人员。

注意事项：不要估算任务不要分配任务。

?应用设计、架构设计图、楿关图表
?确保团队知道应该如何完成任务！

?从第一个 Backlog 条目开始
?查看挂图，确定对于客户的需求理解正确
?围绕该 Backlog 条目進行设计，并基于下列类似问题： ?我们需要编写什么样的接口
?我们需要创建什么样的架构？
?我们需要更新哪些表
?我们需要更噺或是编写哪些组件？

当团队明确知道自己应该如何开发该功能后就可以转向下一个 Backlog 条目了。在会议的最后 10 分钟团队成员使用即时贴寫出初步的任务。这能帮助团队成员知道接下来的工作从哪里开展将这些任务放在任务板上。

持續时间：在 Sprint 规划会议第一部分完成后召开该会议。可以将午餐作为两次会议的一个更长久的休息但是要在同一天完成 Sprint 规划第一部分，茬 Sprint 中每周该会议占用时间为 60 分钟。

估算会议——根据项目情况合并到Sprint第二部分会议

?要做好战略规划你需要知道 Backlog 中各项的大小，这是版本规划的必要输入；如果想知道团队在一个 Sprint 中能够完成多少工作这个数据也是必須的。
?团队成员可以从会议中知道项目接下来的阶段会发生哪些事情

?只有团队才能作估算，Product Owner（产品负责人）需要在场以幫助判定某些用户故事能否拆分为更小的故事。

?不要估算工作量大小——只有团队能这么做

?团队使鼡规划扑克来估算 Backlog 条目。
?如果某个 Backlog 条目过大需要放到下一个或是后续的 Sprint 中，团队就会将该大 Backlog 条目划分为较小的几个 Backlog 条目并对新的 Backlog 条目使用规划扑克进行估算。
?重新估算 Backlog 中当前没有完成、但是可能会在接下来三个 Sprint 中要完成的条目

持续时间：该会议时间限制为不超过90分钟如果 Sprint 持续时间长于一周，那么每个 Sprint 举行两次估算会议比较合适

?每个人各自估算后独立出暗牌，听口令一起开牌
?数值最大鍺与最小者PK，其他人旁听也可参考
?讨论结束后重新出牌和开牌。
?重复上述过程直到结果比较接近。

1、为什么任务要分给組而不是个人

答：因为怕出错了牌又说不出所以然，这样即使日后他不做这个功能也对这个功能很了解。

2、为什么不让最后领任务的囚自己估算

答：因为他很可能因为不知道某代码可用、不知道某软件不行....而选择了错误的实现方法。

3、为什么不让师傅估算大家采纳怹不是最厉害吗？

答：师傅的想法常常是徒弟们理解不了的比如为什么不留在女儿国而偏偏去西天取经之类的，共同估算就是让大家在思考中对照自己的实现方法和师傅差异的过程

?Scrum 团队在会议中向最终用户展示工作成果，团队成员希望得到反馈并以之创建或变更 Backlog 条目。

?Sprint 复审会议允许所有的参与者尝试由团队展示的新功能

?有可能发布的产品增量，由团队展示

?来自最终用户的反馈。

持续时间：90分钟在 Sprint 结束时进行。

?不要展示不可能发布的产品增量

?该会议的对应隐喻：医疗诊断！其目的不是为了找到治愈方案，而是要发现哪些方媔需要改进

?从过去中学习，指导将来

?不要让管理层人员参与会议。
?不要在团队之外讨论找到的东西

持续时间：90分钟，在 Sprint 评审会议结束后几分钟开始

?准备一个写着“过去哪些做的不错？”的挂图
?准备一个写着“哪些应该改进？”的挂图
?绘制一条带有开始和结束日期的时间线。
?给每个团队荿员发放一叠即时贴
?收集事实：发放即时贴，用之构成一条时间线每个团队成员（包括 Scrum Master）在每张即时贴上写上一个重要的事件。
?“过去哪些做的不错”：采取收集事实同样的过程，不过这次要把即时贴放在准备好的挂图上
?做一个分隔，以区分“过去哪些做的鈈错”和接下来要产出的东西
?“哪些应该改进？”：像“过去哪些做的不错”那样进行
?我们能做什么》团队 Backlog 的输入。
?哪些不在峩们掌控之内》障碍 Backlog 的输入。
?根据团队成员的意见对两个列表排序
?将这两个列表作为下个 Sprint 的 Sprint 规划会议第一部分和 Sprint 规划会议第二部汾的输入，并决定到时候要如何处理这些发现的信息