福州网站设计软件,wordpress 文章时间,深圳网站建设开发,ppt模板包含哪些内容为期两个月的团队项目完成了#xff0c;我们的游戏也已经发布。在这个名叫KOFLive的小游戏里#xff0c;我们集成了五个真人角色#xff0c;每个角色有拳脚基本招数以及三个小招、一个大招#xff0c;硬值、防御、集气、双人对战、人机对战、练习模式等格斗游戏的Feature基…为期两个月的团队项目完成了我们的游戏也已经发布。在这个名叫KOFLive的小游戏里我们集成了五个真人角色每个角色有拳脚基本招数以及三个小招、一个大招硬值、防御、集气、双人对战、人机对战、练习模式等格斗游戏的Feature基本上全部实现并且做出了比较炫目的特效。无论从目前的下载量还是用户反馈来看游戏的效果都达到了我们的预期也算不枉这几个月的一番心血吧J除了这些整个项目的教训也是显然的。如果说阅读《梦断代码》使我们对软件难做有了感性认识自己亲自参与到一个软件工程项目中才让我们对这一点有了切身体会——不过只要群策群力规划得当一个软件项目总归不是难于登天的。我们愿意把我们做这个项目的经验教训与大家分享希望对软件开发人员能有一些小小的帮助。 项目的选择 一个好的项目方案是成功的关键——它不仅能让你的团队得到更多的用户更能让队员们在开发过程中充满动力——试想没人愿意为一个Hello World工程付出太大精力同样也没人愿意做一个根本不可能实现的功能这中间的平衡需要好好掌握。另外在选择项目时你提出的第一第二乃至第三方案都很有可能是别人已经做烂掉的东西这就要求我们在选择项目时要有足够的观察力并做足够的市场调研。 现在想想我们的队伍在项目选择上做的不够好一是对项目的选择规划重视程度不够表现在提出的备选方案太少全队六个人仅仅提出了三个方案以供筛选这是很不好的一点二是最终选择的项目链接请看这儿最重要的Feature实现起来难度太大。整个开发流程中我们对游戏的愿景可以说有三个阶段 一开始我们不想做太Trivial的项目更不想基于别人已经做烂了的技术去完成项目。所以我们选择了在这个游戏里加入图像处理的部分用户输入一张全身照片我们程序做图像分割再将分割出的身体各个部分拼接成人体拳打脚踢的各种动作。做的时候才发现别说拼接以现在的图像处理技术自动识别人体胳膊、腿等具体部位都很难何况在此基础上进行图像分割了 之后调整计划将目标锁定为识别人脸即识别出人脸并将其加载到游戏内置的人物模型上。这个也比较不现实因为游戏中大部分时间人物都是以侧脸呈现的即使我们实现了人脸识别并分割的技术将其加载到这样的一个模型里也比较难看这一阶段的博客请看这儿 这一阶段才是比较现实的做一个真人角色的搏击游戏当时我们定下的目标就是在去除人脸识别的前提下将游戏的手感做到最好。事实证明这是最合适的目标可以吸引大量用户我们的下载量和用户反馈证明了这一点又有适当的难度是我们努力拼搏四周可以达成的 所以程序员是天生的乐天派这个说法还是很符合实际情况的。另外我们组没有做过图像处理的组员在MSRA我们也需要做实习工作同时三名主力Dev还因为学分问题不得不选修清华姚班开的一门操作系统在这么繁重的压力下去实现一个图像处理界都没有研究透彻的Feature实在是不够现实。其实在项目开始之前我们不是没有就难度问题咨询过相关的专家不过可能是不愿打击一群毛头小伙的满腔热情J 他们并没有直接告诉我们这个技术的可行性。所以奉劝大家在选择项目时一定要有足够好的市场观察力肯花时间去好好调研并要清晰认识自身能力、时间、优先度等客观条件最好将每一步都仔细规划好做到大胆假设小心求证J 一个好的选题很重要不过我们当时没有注意到这一点做出选择不够慎重——这并不是说我们最终做出的项目没有吸引力只是如果我们当时能够计划的好一些开发过程中我们能少走很多弯路。从另一个角度来说上软件工程这门课最重要的是学会一整套正规的软件开发流程而并不是说实现一个多难的技术况且一个很难的技术也不一定是用户欢迎的对于一个学生团队选择项目不应当以开发者驱动而应当以用户市场驱动。 项目的执行 在Beta阶段开始的时候PM给每位组员发了封整体进度安排邮件邮件末尾说希望软件工程结课时我们能说出一句Were proud of each other现在快结课了我们认为每个人都值得小组其他成员的这一句话: Were proud of youJ 项目执行的两个阶段尤其是Beta阶段无论是PM/Dev/Designer/Tester的紧密配合还是目标改变后的紧急调整以及发布之前的紧密测试和应急计划我们都做到了一个良好软件开发团队应该做到的。 良好的设计架构和清晰的接口。我们的Dev们有着强大的单兵作战能力和丰富的工程经验他们设计了一整套高效的游戏支持机制整个工程有着清晰的层次架构 最底层的游戏引擎负责图片的透明化、放大缩小、去锯齿、渲染、翻转等操作并进行图片像素级的碰撞检测和音效支持。 中间一层是基于引擎的游戏运行逻辑层在这一层我们进行人物招数和状态转换的设计和加载实现攻防判定、血气管理、输入检测、AI机制、纠错机制等等。 最上一层负责整个游戏的流程判断启动、终止界面的加载、用户选择流程的分支等。 我们三个层次不同的功能模块之间定义好了完备清晰的借口极大提高了Dev分工合作的效率以及Designer设计招数和特效的效率并方便及时查错要知道设计游戏时游戏引擎在进行毫秒级的不断渲染Debug是很难通过IDE 设置断点来实 现的J如果可能我们也乐于开放自己的源代码供大家参考指正。 专业的招数设计和特效制作。我们的Designer中有拳皇游戏的骨灰级玩家对每个人物的状态转换和招数设计有着很好的设计这可是一个参数一个参数调试慢工出细活的过程^_^同时也有精通PS特效制作、研究过用户界面的同学制作出的效果十分炫目不信自己下载游戏看看吧J 大家分别发挥自己的特长进行充分的合作保证了游戏的质量和进度。 严密的发布前应急和测试。我们一直有一个理念发布日期定在那里我们要在此之前发布并且应当对用户负责不能让用户使用一个Bug很多的花架子。所以我们进行了清晰的进度规划大到周小到半天应当完成的进度十分明了。同时我们进行了有效的发布前规划 AI机制在发布周之前都没有涉及我们制定了应急机制在目标上降低需求做出一个让用户不能轻易打赢的AI版本即可 在实现机制上我们提前设计好了随机性的AI贪心算法并预留出了相关的接口。事实证明这套机制是行之有效的:我们的AI只用了周四一天的时间完成经过相关测试周五游戏就发布了。但AI效果非常好电脑出招很犀利有的角色甚至让玩家惊呼Bug ImbaJ 刚刚上手的玩家很难打赢这无疑能刺激用户接着玩下去^_^ 频繁的健壮性测试。每当有人要Check in一个新版本我们都规定他自己要进行近乎变态的测试长时间的乱序键盘输入检测。这一点在发布周执行地更频繁每当有人Check in一个修改比较大的版本我们都会组织两个人在电脑上打一打疯狂的敲击键盘J。事实证明这也是非常有效的我们大部分的Bug都是这样测试出来的并且我们保证在发布之前这些Bug都被及时修正。在Test Report中我们报出的可以发布的结果是切实有效真正对用户负责的。 发布前整流在临近发布前两天我们兵分两路PM和一个Dev进行发布的所有事项准备Branch一个发布版本用于制作安装包、测试、撰写说明文档、确定下载站点及统计方式等其他人员接着做之前的事情。这样保证我们发布时不会手忙脚乱出现各种意外情况。 这些措施的实施使我们提前两天发布了游戏 并且到现在没有收到用户反馈的任何健壮性问题我们保证了我们最一开始交付给用户的即是一个健壮合格的产品。 有效的时间管理。由于我们在确定实现的基本Feature时有过一些改变所以真正开发起来时间显得很紧张我们必须保证大家都能充分利用时间为此我们有以下机制 修改了Scrum的流程如果一个Daily Scrum没有讨论出真正必要的东西我们为什么又要花那么多时间呢所以我们规定每天的Scrum不一定必须大家聚在一块儿只需由PM调查每个人的进度并将每个人的进度通知其他人。PM应当对整个项目的进度有很好的了解当PM认为有必要大家在一块儿商讨时我们才会专门去会议室讨论清楚问题。在每次Scrum之前我们都提前确定了本次需要汇报给其他人的进度以及需要讨论好的问题确保会议时不会因为冷场而耽误整个组的时间。这样我们聚在一块儿的Scrum基本上两天一次。事实证明这是非常有效的沟通合作手段。 我们会充分考虑每个队员当前的时间安排毕竟有队员会在某个时间段因为组里面有deadline而时间很紧张我们会平衡每个人的负担将他的任务适当转移给其他的队员大家也都能做到互相体谅互相帮助。 总结尽管降低了难度但不借助外界引擎开发一个完整的游戏毕竟还是很有难度的。队员们在四周的开发流程中圆满完成了开发的任务交付给了用户一个负责任的产品。可以说我们在项目选择、计划阶段有考虑不周的地方但在真正的开发过程中我们的个人努力和团队合作是高质量高效率的。 回想这个KOFLive开发流程我们经历过计划大改的阵痛、成员意见的冲突、通宵工作的劳累也经历过目标实现的兴奋、初具雏形的喜悦、游戏发布的欣慰不管最终结果怎么样这样一个过程让我们真正了解了如何做软件更重要的是如何与他人合作说服他人以及被他人说服J 这是让我们感激彼此的重要原因。 最后上张合影 Were proud of each other! 转载于:https://www.cnblogs.com/MSRA_SE_TEAM/archive/2011/03/14/1984271.html
