logo标签列表

哪些敏捷实践适用于游戏开发？

refactoringtddagile
10

最近我非常关注敏捷方法论。我在Martin Fowler的网站上读到的一些文章至少给我的印象是无可挑剔的，所以我想知道哪些敏捷实践最适合游戏开发，尤其是对于预算小、规模小且经验不足的团队项目（这里加粗是因为它真的很重要）。

像重构这样的概念看起来可以与小而经验不足的团队完美结合。"拥抱变化"的想法也与那些思路不断变化的经验不足的团队相融合。但是TDD等东西会有些棘手。

例如测试与Direct3D互动的类很难且不太优秀。这没有多大意义。

如果您能列出一些在游戏开发中有意义的实践，我将不胜感激，尤其是那些有助于艺术制作组织的实践。现实案例的引用也是另一个加分项。

提前感谢您。

编辑--

此外，我的团队由3个人组成：一名程序员、一名图形设计师和一名程序员/图形设计师的组合。我们没有客户，所以必须自己做出所有决策。

我在Fowler的一篇文章中读到，敏捷有点依赖于开发人员与客户之间的互动，但他还提到，不愿意遵循敏捷方法论的客户仍然可以通过敏捷开发得到良好的服务（这篇文章叫新方法论）。那么，这如何适用于我的情况呢？

结论--

我认为StackOverflow上的问题也可以帮助其他人，因此我会在这里总结一下我的想法。

  • 通过使用模拟对象，即使是难以测试的元素，例如图形界面及其与客户端类的关系，也可能是可管理的。

例如，不是让接口的每个客户端在许多条件下真正测试其使用（例如全屏/窗口模式切换，几乎影响游戏中的所有内容），而是可以针对一个看起来与原始类别行为相同的模拟进行测试，并额外测试该模拟对象与原始对象的一致性。

这样，慢部分（实际上打开窗口和其他东西）只在检查模拟对象的实现一致性时执行一次，其他所有操作都在模拟器上平稳运行。【感谢 Cameron】

  • 采用 BDD 思维方式 有助于缓解对单元完整测试的偏执追求，“取代”测试并规范化实际行为，而不是测试被挤压的单元，在许多情况下，让它们不经过测试（或者您更喜欢间接测试），以避免过多的一对一测试与单位（类，方法，变量等）的匹配，这会增加测试（现在是“规范化”）的脆弱性。【感谢 Kludge】

    • 1
    也许（部分？）与Direct3D交互的代码可以抽象成接口。然后，您可以创建一个实现该接口的虚拟Direct3D服务，用于测试目的。 - Cameron
    虽然图形相关的函数很难自动化测试，但这只是例外而不是规则，即使在游戏开发中也是如此。 - LarsH
    @Cameron 没错，有时候我会忘记可以模拟一些东西。我也不习惯这样做，但你说得对。谢谢。 @LarsH 我担心这可能只是美好的幻想。有时我害怕使用TDD开发每个不重要的软件部分，最后发现最重要的部分无法以这种方式完成。我非常警惕这一点。还有更多见解吗？ - Gui Prá
    不要测试与图形相关的函数。但是您仍然可以测试其他代码。例如人工智能、一些计算和物理、网络通信等。将图形抽象为单独的引擎也是一种方法。 - Ladislav Mrnka
    @Ladislav问题在于我引擎的80%将是图形，所以我的TDD/BDD/敏捷狂热会开始消退。我认为这些是很好的想法，但我希望在大部分开发过程中都能使用它们，而不仅仅在一些边角案例中使用。对于你新接触的东西要想真正掌握，最好多加使用。至少对我来说是这样。 - Gui Prá
    6个回答
    2
    我建议试用VersionOne（www.versionone.com）。 VersionOne适用于单项目小团队免费，并提供易于使用的工具，用于敏捷状态跟踪和项目规划。他们的网站还提供了各种敏捷开发方法的解释链接。
    敏捷开发有不同的风格；我推荐看看极限编程（XP）模型，作为一个很好的例子： http://www.extremeprogramming.org/map/project.html 敏捷开发与项目规划和需求跟踪一样重要，也关注实际编程实践。
    其想法是确保记录需要开发的游戏功能（作为“用户故事”），给出（非常粗略的）每个功能所需时间的估计，并确定哪些功能最重要。对于每次发布安排一小段时间，并安排在该时间内可以发布的最重要、最便宜的功能。这个系统确保稳步前进，保护您免受不断变化的优先级干扰，并确保您不会开发一个巨大的不起作用的代码库。
    关于测试驱动开发，我认为Cameron和Andrew Grimm的评论都很到位。如果抽象掉图形API调用等内容，则可以进行更多的单元测试。
    1

    你一定想要了解极限编程（XP），看看肯特·贝克的《极限编程 Explained：拥抱变化，第二版》

    不过最有用的事情是研究行为驱动开发，这基本上是正确地完成测试驱动开发。它将重点从测试转移到规范上。你不必太关心类做什么，而是程序表现出的行为。

    所以说你不打算使用TDD或BDD，那就是纯属疯言疯语。敏捷开发的核心概念之一是从测试/规范中开发软件。你必须摆脱测试/规范是在测试你的类的思维模式。那不是它们的真正用途。它们是用来描述应用程序应该表现出的行为，然后使用该测试/规范将该行为写入应用程序。

    你可以写出像这样的东西

    Describe Startup
  it "should display a welcome screen" do
    game = Game.new
    game.start
    game.output_buffer.should match("Welcome")
  end
end

    然后你就可以编写代码来实现它。你描述你想要的代码，然后你去编写它。这使你能够将代码分成小块，最重要的是当其他人接手你的代码时，他们可以运行测试并查看一切是否正常。当他们想要添加新功能时，他们使用相同的过程，所以现在当你回到代码时，你可以相信他们的代码也能正常工作。

    BDD真的应该取代TDD吗？我认为在一个给定的行为背后，有很多小单元在完成它们的工作，如果你不彻底地测试它们，改变它们可能会以一种你的测试无法捕捉到的高层次方式破坏一些东西。测试所有软件可能产生的各种行为应该是非常困难的，所以你可能无法做到足够彻底。但是我还是会好好阅读一下BDD。非常感谢！ - Gui Prá
    2
    BDD就是TDD。它只是一种不同的看待方式；它是TDD的进化版。你仍然会进行单元测试，但他们将其改名为BDD，因为语言传达行动的概念。使用所有测试词让人们想，“我必须编写测试以确保我的代码工作。”而不是想，“我需要描述我的程序应该做什么，并确保它能够工作。”查看有关BDD与TDD的这个视频。http://video.google.com/videoplay?docid=8135690990081075324# - Kludge
    1
    敏捷/精益方法，如Scrum、XP和看板自2003年以来已成功应用于游戏开发。
    有许多博客包括： http://blog.agilegamedevelopment.com/ 还有一本书。请参见上述博客中的书籍链接。
    0
    如果您有良好的模型视图控制器（MVC）分离，您应该能够在没有图形的情况下测试“业务逻辑”。例如，测试给定武器产生正确数量的伤害，不能穿墙，并具有给定的影响区域。
    0

    敏捷开发与游戏开发完全不兼容。它们是两种完全相反的方法。

    敏捷开发是关于开发灵活适应变化的业务需求，并将项目分解为清晰可管理的期限和工作单元。游戏开发则是经常性地并且戏剧性地改变业务需求，而不关心对开发的影响，并通过难以管理的期限和大量的工作来分解开发团队。

    这难道不是让敏捷方法论成为游戏开发的推荐吗？ - Gui Prá
    2
    我认为这条评论是一位游戏开发者试图讽刺，但因未能达成目的而被扣一分。 - ocodo
    1
    哇，你完全不知道你在说什么。 - Mike Bethany
    1
    +1，我觉得这挺有趣的。 - tster
    那么为什么一些一流的游戏工作室使用 Scrum？ - Ladislav Mrnka
    1
    对于某些人来说，+1 的讽刺意味可能太微妙了。 - Andy Morris
    0

    我不相信敏捷开发中有任何元素与游戏开发不兼容。你对测试图形函数的难度感到困惑；运行图形函数会生成一张图片，将图片与手动批准的“黄金样本”进行比较很容易（请参阅Approval Tests了解其中一种方法）。

    重构是一项很好的技术，但应该在单元测试的安全网络下完成。获得单元测试的最佳方法是以测试为先来开发您的代码，所以TDD是另一种你应该遵循的敏捷实践。如果搭配编程，所有这些都更好——重构、测试等等。你有足够的人员可以搭配编程。尝试一下，看看你运行测试特性的速度能快多少！

    我可能会尝试一下，但是比较图像是一件我很怀疑会奏效的事情。首先，有时您必须比较动画，这需要太多时间。此外，有时渲染的帧与预期的相同帧会因为浮点数差异而略有不同，例如。我认为这太不可靠和麻烦了。 - Gui Prá
    让人沮丧的是，当提出一种方法时，特殊情况被作为完全拒绝该方法的原因；在测试讨论中经常遇到这种情况。当然，有些情况下这种方法可能行不通。但是，采用这种方法可以涵盖更多的代码。在适当的情况下应用它，如果不适用，则寻找其他技术。 - Carl Manaster
    网页内容由stack overflow 提供, 点击上面的
    可以查看英文原文，
    原文链接