Unity2D项目-平台、解谜、战斗! 0.2 序言:团队在线协作方案、基线控制

各位看官老爷们,这里是RuaiRuai工作室,一个做单机游戏的兴趣作坊。

本文跟大家聊一下笔者团队中所使用的在线协作的诸多工具,以及使用这些工具的目的和所记录的内容,希望这些内容在大家团队工作中有所帮助。

文档管理

笔者团队中主要记录了以下文档:

游戏设计文档

  玩法及机制文档

  剧情文档

  关卡设计文档

  创意点文档

程序设计文档

  版本说明文档

  模块设计文档

  类说明文档

  文件头注释及内部注释

项目管理文档

  长期进度规划

  短期任务规划及任务分解

  bug列表

  会议记录文档

这些文档中,有些文档是需要随着进度的定期更新的,如关卡设计文档、版本说明文档等,这些文档一般有专人负责维护,在笔者的小团队中,一般是谁负责这个模块谁负责写该模块的文档;有些文档是实时更新的,比如bug列表、短期任务规划,一般来说这些文档是随着工作的推进随时可能更新的,而且任何团队成员都有可能对这些文档进行随时修改;还有些文档是一经编写、核验便在整个项目中不会变动或极少变动的,比如长期进度规划文档、软件需求规格说明书(游戏项目中比较少见)等,这些文档在整个项目中起到参照、引导方向的作用,故需要谨慎编写、反复核查。

根据这个分类,笔者团队中采用不同的方法管理这些文档:

对于需要定期更新的,文档名以及文档头会根据当前项目的版本号自行扩展文档版本号,采用版本迭代的方式进行管理,比如

当前项目的版本为0.1.2,那么相关玩法设计的文档可能为0.1.2.1\0.1.2.2等。主策划负责维护这个文档版本系列,并将以往的所有文档保存在文档管理工具中。

对于实时更新,任何人都可能编写的,我们采用在线文档的方式进行管理,一般这样的文档只需要一个文件即可。文档内容实时保持当前工作进度的最新进展,已经完成的任务项或是已经失去时效性的信息便会放在文档末尾的历史记录中留存。

对于一经编写,极少变动或者不会变动的文档,在团队公开文档中只需要留存一份只读文件即可,改写权在项目组的项目经理或组长手中。

在文档方面,不管使用使用何种管理工具,我们只要找到一种合理的方案就可以,笔者团队中使用群文件管理变动较少的文档,使用git版本控制管理与版本有关的文档,使用群在线文档管理实时更新文件。 

 

设计图管理

 在团队搭建伊始,大家都没有协作经验,只是简单地搜集了一下信息就决定使用ProcessOn来管理和协作各种设计图。在大佬的指导下,我们了解到了draw.io开源工具,我们才将所有的设计图搬运到了draw.io下面。

(英文不好的小伙伴记得切换中文界面噢,吹爆draw.io

 

版本控制

当然首推git,但是在使用git进行版本控制中我们也遇到了相当多的问题,比如.gitignore配置不正确导致的vs项目同步失败问题,美术资源导致的带宽过小问题,场景数据和prefab数据的merge问题。在此我们只是对每个遇到的问题做一个解决思路上的概括,不做过多的细节描述,对于上述问题的细节解决方案已经存在很多博客可以参考。

.gitignore配置不正确导致的vs项目同步失败问题

首先,.gitignore文件中记录了git在本地仓库文件夹中中不予追踪和同步的子文件夹、文件格式等一系列文件。而在unity中(默认使用vs进行C#开发),我们只需要对项目结构中的部分文件进行同步和版本控制,比如Assets文件夹下的资源文件和脚本文件、package文件夹下的资源包插件包等。其他的诸如vs本地化配置文件\文件夹等则不需要进行同步,这部分文件我们需要在.gitignore文件夹中指名,否则如果这些文件通过远程仓库进入了其他机器,会造成路径丢失、配置冲突等本地化问题。

在这里建议在github中搜索.gitignore,在官方给出的unity.gitignore中做一些针对自己项目的改动(如果不确定你在做什么,直接使用官方的.gitignore就好!)

 

 

 美术资源过大导致同步速度难以接受问题

用其他工具进行资源同步吧!我们没有做过多思考和调查,简单地使用一个群文件+版本号进行控制,当然这种随意的控制方式可能会有潜在的风险,希望有相关经验的朋友不吝赐教!

场景数据和prefab数据的merge问题

首先我们需要将unity的文件储存形式配置为可序列化而不是二进制文件,这样做就允许了git比对不同版本的场景\prefab数据文件的差异,从而进行自动merge操作,当无法自动merge时,便在序列化的文件中做出标记,指示我们进行手动merge。我们顺着这个思路,便可以将存在merge conflict的序列化文件以文本格式打开,像手动合并代码一样merge这些文件。

 

实时交流方案

我们是游戏团队所以当然开发了一套最先进的AR全息会议来实现实时交流啦

我在想批次.jpeg

 笔者团队经历了时长越2个月的线上协作,这段时间给笔者的最大感受就是:需要像问小朋友要作业一样问你的组员要成果...

确实,线上协作的距离感无可避免地带来了管理上的困难,这就需要项目负责人花很多心思在凝聚这个团队上,在保证团员的紧迫感和摸鱼带来的心理压力之间找到一个可以忍受的平衡(我是哲学家吗2333)。当然,团队管理并不是今天的主要话题,那么回到主线,在这种情况下如何进行有效的在线实时交流呢?

笔者团队采用的方案是不定期在线会议+每周工作汇报+1h内找必回制度,即

1. 根据工作进度和团队成员的状态不定期(约1~3天)开一次短会,主要是工作进度分享、工作任务分解、问题讨论、团队氛围建设(瞎b聊天)等内容。

2. 每周进行一次较为正式的定期会议,每个人口头汇报工作内容、工作状态、问题反馈等内容,并每周安排一名组员进行激动人心的游戏安利环节,同时安排另一名组员进行会议记录。

3. 1h内找必回制度,即在工作群中,若有相关工作的问题交流,对应模块的负责人必须在1h内予以接洽,否则进行惩罚(0.0我是被罚最多的)(是因为我负责模块最多啦)a

在这套方案的使用过程中,笔者认为所谓张弛有度还是可以保证的,即让队员有一个较为轻松愉快的讨论氛围,又不至于影响工作效率,或者说流于形式。当然,在具体实施管理交流方案中最重要的还是项目经理和项目成员的各方面能力和性格,所谓人定胜天。

 

小结

笔者本想通过本文介绍一些工具的使用方法和技术上的问题的阐述,没想到说着说着有感而发,逻辑就顺道了团队管理的经验上去,不过这也是我最想和大家分享得内容吧。本文我们介绍了笔者团队所应用的文档管理办法、设计图管理工具、git的使用经验和在线交流和团队管理经验,希望这些内容能够对已经阅读到这里的你有所帮助,特别是关于团队管理方面的心得。

感谢您阅读到这里!那么今天的分享就是这些,欢迎访问:

 

整个项目原型github地址:

 www.gitHub.com/yunshiyue/elementgame

 

最后,这里是RuaiRuai工作室,一个做单机游戏的兴趣作坊,希望你对我们的项目能提出各种意见和想法,也欢迎各种合作!

下期再见!

 

posted @ 2021-04-16 17:31  脸脸爱编程  阅读(500)  评论(1编辑  收藏  举报