[G星计划]--项目开发总结
/6/23 16:35:01
第一轮:Dr.Mech
参加了为期7天的第一轮DEMO竞赛 , 最佳团队 , 总结一下开发过程中的一些要点 。
问题:
文章插图
关于项目时间安排 , 由于项目核心代码量并不算太多 , 所以前几天还是比较从容的 , 不过这也导致许多细节只能在最后一上午进行完善 , 仓促中不免发生一些遗漏 。
本次开发过程中 , 由于经验不足 , 没有系统的规划程序方面的安排 , 直接上手写代码 , 开发效率受到一定程度的影响 , 代码质量也不过关 。
目录结构混乱 , 之后的项目可参考下方:
由于unity项目资源众多(场景、脚本、模型、贴图、动画、着色器、音视频片段等) , 命名上缺乏统一的规范 , 这里最好用大驼峰命名法 , 同一资源类型用下划线+两位序号区分 。
文章插图
程序对美术进行相关的规格要求 , 产出的图片大多都是原图直接使用 , 这在一定程度上影响的项目的内存消耗 。美术相关要求可参考美术资源规范
程序对策划配置表没有开发相关工具 , 策划数值调试耽误部分时间 。由于时间问题 , 目前可采用开源工具进行处理 , 参考Unity开发中异步加载配置文件 , 像读取数据库一样读取配置信息
总结: 可适当增加需求分析阶段的时间安排 , 将需求功能认真划分 , 确定模块接口 , 有利于提高开发效率 。既然是团队工程开发 , 必然需要制定相关的开发规范 , 提前与策划制定好配置表的相关表项 , 与美术要求资源规范 , 要让美术和策划参与到游戏引擎的使用中 。程序开发应遵循迭代开发的模式 , 在白模阶段将核心玩法搞定 , 可与美术对接好相关资源文件规格 。给玩家适当的“勾引” , 游戏的巧妙之处 。第二轮:吃货探险家
第二轮历时14天 , 第二名也算满足了 , 我们组抽到的题目比较宽泛 , 由于之前接触的不多 , 所以对工作量预想并没有一个大致的概念 。
【[G星计划]--项目开发总结】问题: 时间方面 , 由于在项目评估方面经验不足 , 无法预估工作时间 , 我们花费了较长时间确定玩法 , 后来证明这段时间确实多有浪费 。在我的强烈要求下 , 我们制定了相关的程序规范和美术对接规范 , 这次的代码质量整体要高于上次 , 但是随着开发的演进 , 很多时候忽略了这些规范 , 导致后期项目结构仍有混乱的现象 , 美术资源方面也没有进行专门的检查 。项目分工严重偏差 , 由于并不是主程 , 说话的分量自然也…所以很多需求都由主程直接完成 , 导致其他程序略有闲置 , 虽然很感谢主程 , 但是在需求划分方面确实做的不够 。潜在威胁最终导致bug , 这次我们采取从csv读取配置的方式处理相关数值 , 中文部分有乱码我一直没在意 , 直到最后发现策划新填写的一版配置表出了问题 , 却为时已晚 。可参考csv用excel打开中文乱码 总结: 程序应当利用经验对策划的需求进行时间评估 , 保证规定时间能够完成增加对需求的明确分析 , 分工明确在替换模型时缺乏经验 , 一张一张对效率低下 , 应采用动态方式进行加载 , 可参考: 精灵更换图片脚本实现重新梳理unity开发流程 , 整理项目框架应注重UI交互 , 引导玩家而不是干扰玩家最后 , 跟优秀的人一起工作的好处就是 , 节省交流成本 。33天总结 多看 , 大神优秀代码 , 并学习超越 , 更新自我多问 , 向他人请教好的技巧、方法多总结 , 就是现在写的东西 , 这个做的还可以美术与策划需要是用unity进行一些调整性工作美术设计不应脱离所对应的游戏产品在视觉引导要有新意 , 符合游戏整体的设计理念 , ui与界面的融入 , 对用户的反馈(ux) , 主次关系要明确 。美术和程序应当具备评估策划需求时间花费的能力游戏制作需要目标明确 , 过程应当是快乐的 , 要坚持一些自己的想法 , 要检查设计理念 , 成员统一目标作品应注重完成度 , 注重打磨 , 音效、特效需要与画面相结合
- A*, A Star A星算法详解
- A星算法代码
- 四 GNSS原理与应用——卫星运动基本知识
- 世界卫星地图,找个超高清晰全球卫星地图!
- 行星胚胎忒伊亚为什么会是月球的前身呢?
- 三星980和980pro差多少
- 三星先行者计划是什么意思
- 三星e4和e5的区别
- 神星矢,星矢是神吗
- 【题解】卫星照片