项目描述：该项目由导师作为制作人发起，为面向海外市场的3V3 PVP手机游戏，参与者均导师指导的研究生。玩家争抢场地上的球并运至敌对方的球门以得分，并在运送过程中可以攻击敌方玩家阻碍运输且躲避敌人阻挠。该项目从2019.12.24开始开发，于2021..2.20取消，核心开发人数7人左右。
一．项目开发过程梳理
项目分为3个阶段：2019之前、2019.12-2020.9、2020.9-2021.2
开发前-2019之前：
几位师哥做出一款3方对战（2V2V2）的原型游戏，并在测试时感觉体验尚可。但因为是自己入学前的事情，自己并未参与。
基础开发2019.12-2020.9：
这段时期主要为前期准备时间，服务端和客户端的负责同学开发完可开始测试的基础结构时已是3月份。在此阶段，曾参与过老3方对战项目的师哥作为主策职责，自己则简单设计基本模块。此外，这一阶段美术组和策划组反复讨论游戏虚拟层设计并伴有学习性质地制作美术资源，但并未有决定性结果。
从五月份开始，开发进程提速，每周进行组会集体测试和讨论下一步设计内容。但负责开发的几位师哥均面临研三找工作和写论文的压力，项目进度仍旧迟缓。且绝大多数精力投入在最基本的结构设计问题上，包括服务器同步、碰撞问题和各种非机制bug
8月的后期版本
正式开发2020.9-2021.2
直到新的研一同学加入到项目组，之前师哥脱离项目组时，该项目才步入真正的高效开发。同时自己在项目组中作为主策职位，负责进度管理、关卡设计、核心机制设计、数值设计等一切机制层设计，并且配合美术工作在部分虚拟层方面进行设计商讨。
在过程中，自己首先将三方对战的方向，转为之后的3V3方向，并以运球得分为核心区分传统MOBA游戏。并以《荒野乱斗》的足球模式、传统球类游戏和以传统球类游戏为基础的电子游戏和桌面游戏为基础进行竞品分析和设计理念分析。
针对传、抢、运球的足球流程抽象化
通常来说，每一周都会出一个小版本进行集体测试，验证之前设计及为之后设计进行探讨。过程中，大家会进行讨论，自己会总结大家想法，提炼出可实行的方案并把对应设计文档发到讨论组中。在大家对设计文档探讨完后，再细化设计并拆解为具体需求，并且标注优先级及管理开发完成进度。由于是几人的小团队，需求书写的规范性追求不高，但高度注重清晰、易懂以降低程序同学的理解难度（尤其不断基于程序同学的反馈，需求书写的质量也逐渐提高）。
需求单
需求案例1
项目结束于2021.2，由导师决定推翻重做新的游戏。
在年前的版本测试中，由于体验不够有趣，自己同时对以《风暴英雄》为基础的moba游戏进行了针对该项目的详细分析，并针对该项目进行彻底的设计反思，并列出当前核心问题以及解决的方案。
在年后的讨论中，项目组对自己的分析颇为赞同，但对其中几项核心机制解决方案陷入争执。当时自己已将设计改成类似最近发行的《宝可梦：集合》，带有成长机制的多球+运球送分，但当时尚未有类似成功产品。因此导师决定以局内成长为核心元素，推翻重做一款全新的游戏。
最后一版核心机制设计重构文档
后期版本截图（仍无美术素材）
二．项目工作梳理
1， 整体体验方向设计：对整体体验进行方向性设计，竞品分析及项目规划
2， 版本规划：每个版本实现功能及功能优先级规划，以及追讨程序美术同学进度
3， 系统机制设计：包括物理碰撞方式设计、场景机制设计、胜利方式、战斗系统等等
4， 角色设计：设计角色的机制层（攻击、移动方式）
5， 地图设计：设计战斗使用的地图
6， 数值设计：设计及平衡游戏内所有数值，包括角色数值、系统机制相关数值等
7， 测试验证：除了测试设计可行性和程序完成度，
三．项目经验积累
以下是在项目中从失败和实践中获得的经验及教训。
1. 导致游戏失败的根本原因：核心设计理念存在问题
由于自己以传统球类游戏，和以球类游戏为基础设计的电子/桌面游戏为参考，忽略掉该类游戏不会聚焦于单个球员而以整支队伍为一个核心进行对抗的特征。即使在设计本游戏有意减少社交和团队合作的必要性，但仍旧该游戏基于传统单球制的设计理念使得合作是胜利的必要条件，有悖于该游戏手机平台且大众向的需求。并且还产生了设计方向和机制本质的冲突，并在解决该冲突中花费很大精力也未能很好地解决。
尽管在重构中意识到多球的必要性，但当时导师已作为制作人砍掉该项目。
2. 积累失败的根本：测试时未抱着严苛批判性态度
在测试时，自己总抱着“找出其中好玩地方”的态度，而非”像玩别人做的游戏时，使劲找出其中所有不满的地方”。尤其当别人提出问题时，自己下意识反应是对方应该再深入试试，而非自己的设计存在问题。尤其自己抱着从理论推及的玩法体验不至于太糟糕，且自己验证时感觉还可以的态度尤其加剧这种问题。就玩法而言，必须苛刻地、批判性地对待自己的设计，以自己的设计不成功为基础找出可取地方的态度来进行体验测试。
3. 缺乏关键词
关键词指代整个项目围绕着转的高抽象概念。例如《原神》是二次元向开放世界探险，其中重视角色的二次元是它从其他开放世界脱颖而出的根本（考虑到多平台）。《明日方舟》是二次元后启示录风塔防，重虚拟层设计且虚拟层设计的高度统一是它的强烈吸引点。在开发本作时，导师尽管不会对项目的设计进行限制，但也并没有给出指引的方向。同时自己在这其中，也只是以明确设计体验方向为基础设计，包括核心体验是”3V3运球对战”，且在仅针对如“易上手难精通“、”轻量化体验”、”鼓励团队协作但并不强求”等相对细碎的点而设计，并没有更高层次的的指导意义概念。
4. 不要只想着解决当下的问题，多思考更深层面的
在开发过程中，某个版本中发现高速度情况下，玩家可以突破阻碍直接运球得分（之前版本无法”高速度”且很难突破阻碍）。同时位移技能很有趣，提升速度具备战略价值。陷入设计难题的状态下，通过其他机制提升突破障碍运球得分的难度，并且足足加了好多机制，包含一个大的机制系统（防御塔系统）。
然而经过设计重构后发现，这个问题的本质是单球制造成的必然问题。同时本身没必要用单球制，所以去解决上述的问题最后被证明是走错了方向。也就是说，设计时不能只关注当下的问题，尤其遇到难题时，得往上一层思考是否出现了本质的错误或可进行根本性的调整。
5. 过程中领悟到的
a) 在设计时不需过于考虑程序及美术实现问题，尤其在自己没有熟悉到充足的程度。在不确定特定设计时可以提前问问确定实现可能性。
b) 在讨论设计时，尤其需要避免证明自己的设计是对的。始终以如何设计地更有趣为基础。尤其是当别人质疑自己的设计时，一定要以这个设计不是自己设计而是分享过来的基础进行探讨，不能夹杂任何个人情感。这点只能不断练习。
c) 避免在不停的小版本迭代更新时，忽略了大版本的需求和整体方向的指导。需要在一定更新后，回过头来看看现在的设计对比最初的设想有了哪些进展和偏差。如果出现偏差，偏差是让游戏更好玩的话就需要深入分析之前的设计存在哪些问题，并调整设计方案。如果没有明确让游戏更好玩，就得小心是否是多余设计。
6. 过程中练习的
a) 需求书写能力：配合着方便程序理解的流程图设计、关键节点的详细描述（例如大于等于还是大于）、文字精炼易懂且富有生动例子
b) 交流能力：包括探讨设计，问题回馈，催进度等等
c) 对战类数值设计：由于砍了项目时还未到真正的数值平衡阶段，进行的数值更多是影响体验的设计修改和最基本的平衡。
备注：
在该项目推翻重来后，又保持开发强度到5月份，做了一款局内rogue-like式成长的大乱斗吃鸡游戏。尽管该游戏的体验乐趣更强，但导师又决定先做几个可配合买量的小游戏。小游戏的开发进程远比预估的慢，持续到8月时，因为导师申请到重大项目而放低优先级。
在2-5月份的开发过程中，吸取了该项目的经验，并在很多方面有明显进展。但由于从moba类游戏转为类《弓箭手大作战》rogue式的PVP射击吃鸡，很多方面又是重新开始淌雷和实验。
新项目截图