测试驱动开发在游戏开发中是否可行?


23

作为获得Scrum认证的人,我在开发系统时倾向于采用敏捷方法,甚至使用Scrum框架中的某些画布来管理我的日常工作。

此外,我想知道TDD是否可行?

如果我相信这个GD问题,那么TDD在游戏开发中没有多大用处。
为什么在游戏架构中不更多地使用MVC和TDD?

我来自工业编程,其中预算很大的大型项目需要完美无缺地工作,因为如果不对代码进行彻底的内部和外部测试,可能会导致灾难性的情况。

另外,遵循Scrum规则鼓励您在工作中按时完成工作,同时Scrum中的每个动作都必须按时完成!因此,我同意当他们在上面链接的问题中说停止尝试构建系统并开始编写游戏时。Scrum所说的就是这样,首先不要尝试构建完美的系统:在Sprint末期使它正常工作。然后,如果需要,在第二个Sprint中工作时重构代码!

我知道,如果不是所有负责游戏开发的部门都使用Scrum,那么Scrum变得毫无用处。但是,让我们考虑一下所有部门都使用Scrum的情况……我认为TDD可以编写无错误的代码,尽管您不想编写“完美”的系统/游戏。

所以我的问题是:

TDD在游戏开发中是否可行?


除了您链接的问题之外,这个问题还会增加什么讨论?

我介绍了敏捷软件开发中项目管理的Scrum框架,并讨论了在Sprint期间Scrum向开发人员的要求,从而使TDD成为可行的选择。我想从Scrum的角度,而不是在TDD或MVC方面,让其他人对这个问题有所了解。我想了解从勋章的这一方面进行辩论时,TDD是如何不可行的,而不仅仅是将TDD本身视为独立的方法。
Will Marcouiller 2011年

@TDD ==自上而下的设计还是测试驱动的设计?我当时在想Top Down,从长远来看会给出一个可管理性的答案,但是随后看到另一个答案正在以一种我不理解的方式来解释TDD ...
James

@James:测试驱动开发。
混乱

@James:抱歉造成混乱!我不知道首字母缩略词的其他含义,因为我想到的是使用Scrum进行敏捷软件开发。
Will Marcouiller 2011年

Answers:


11

尽管许多游戏程序员尚未真正想到这个想法,或者对如何测试复杂的系统有很好的了解,但它当然是可行的。我承认自己很少使用它,除了易于测试的非游戏相关系统。

期望使用很多模拟对象。由于许多系统之间的联系紧密,因此很难测试其中的各个组件。

再加上很多事情无法彻底测试。例如,您如何测试驱动粒子系统?您如何测试动画系统是否正常工作?本质上很多东西都是可视的,至少对于我而言,如何进行适当的测试并不明显。

但是,有很多东西不一定是传统意义上的单元测试,而是作为特定功能的“测试”而存在的。诸如AI导航测试级别之类的事情相当普遍,但不一定是最容易自动化的事情。

游戏的某些方面可以(可能应该)为它们编写了单元测试。任何类型的通用“文件读取”系统都应进行测试。也许要对硬件(3d表面等)的初始化进行一些测试。也许有一些模拟服务器并测试您的客户端/服务器交互代码。像这样的东西。


9
这些对于存在自动化测试是很好的建议,但对于测试驱动的开发则根本不是。

1
有趣的意见,Tetrad!谢谢你的盐。您问如何测试视觉动画?至于3D系统,很难说,因为我还没有写过一款游戏,也许是在开发了一些小型游戏之后!此外,在2D模式下,我经常看到以矩阵表示的对象以及通过矩阵解析器在屏幕上渲染图像的方法。因此,我想确保在按了方向键之后,在结果矩阵的正确位置找到正确的信息可能是一个开始。我只是对游戏的视觉组件还不够了解,我肯定会在今年!=)
Will Marcouiller

经过一些编码后,我回来说我已经在本周回答了一个问题(这是我在GD上的第一个问题!=),该问题需要OOP概念的知识。OP希望将蛇移动到上Keys.DownKeys.Left等等。也就是说,游戏知道用户希望蛇去向何方,而蛇必须走到游戏告诉它去的地方,尽管只有蛇知道如何向不同的方向移动,因此也要在游戏中定位。恕我直言,这使该Snake课程成为可测试的课程!(待续...)
Will Marcouiller

它不仅可以测试,而且现在是TDD的不错的选择。可以说,在此2D游戏中,蛇在位置处以X和Y轴上Vector2.Zero的速度进行10.0f了初始化。第一个问题是:它是否位于其初始位置,以及如何对其进行测试?然后,您认为该Position财产应公开暴露。第二:如何使其移动?移动方法应该很好,所以您要为每个方向方法编写一个测试MoveDownMoveLeft依此类推。现在,去编写您的方法声明,看看测试是否报错。然后,重新验证蛇的位置
Will Marcouiller

MoveDown方法调用之后!由于您知道该Position属性已经过全面测试,因此您可以依靠该成员!您可能会在这里猜到继续!;-)也就是说,视觉组件绝对不能测试,但是蛇应该看起来像蛇,这完全取决于您要在游戏中使用哪种蛇。画蛇的艺术家应该证明自己对蛇的绘画有足够的满足感,这当然不能通过TDD进行测试!但是它相对于其他对象的位置可以,并且代表这条蛇的类也可以。实际上,TDD
Will Marcouiller

11

因此,我认为TDD不适合作为游戏开发的基础。当然,自动化单元测试作为方法论的一部分,但是游戏开发的许多关键问题是主观的,并且无法通过机器测试来使测试成为开发的驱动力。您将如何编写脚本测试来确定游戏机制是否有趣?这个水平在视觉上很吸引人吗?即使是一个关卡,通常也要花费15分钟左右才能完成?TDD适合以下情况:可以根据对项目的符合性来量化项目的成熟度,而这并不是游戏开发。


3
当您说游戏开发不符合规范时,您是什么意思?我的观点是,当您要编写一款游戏时,您必须知道该编写哪种游戏。因此,规格,要求应写为特征等。让我们以Scrum中的Product Backlog为例。您知道必须在游戏中开发的用户故事,才能编写预期的游戏!然后,再举一个例子,您可能需要在格斗游戏中检测碰撞,这些碰撞是可以测试的!游戏的趣味性不仅仅在于故事,还在于编程,恕我直言。
Will Marcouiller 2011年

@Will Marcouiller:我的意思不是暗示我们没有规范或不能与他们衡量遵守,但有关项目有什么重要的是少可以比其他种类的发展被有效指定。您可以在规范中写“游戏应该很有趣”,但这不是具有技术意义的规范。您可以并且应该测试什么是可测试的,但是TDD的要点是测试不仅是过程的一部分,而且是过程的整个基础,是一种基本的心态,而且我不认为测试具有很高的适应性主观领域。
混乱

2
@Wal Marcouiller,我非常非常不同意游戏的乐趣在于故事。游戏中的所有乐趣都归结于游戏玩法,故事只是奖励。
AttackingHobo

1
@Will:不,他是说用户从游戏中获得的乐趣无法通过自动测试来确定,并且游戏中有很多东西只能通过将游戏交到消费者手中来进行测试。
DeadMG,2011年

1
@DeadMG:这比任何人都想要的要真实,但是我的观点(不一定是AttackingHobo的事实)涉及这样一个事实,即开发过程本身必须包含设计人员,生产人员以及开发人员和测试人员的测试,无法将其量化。测试,这与游戏所创造的体验质量,感觉和风格以及美学效果有关。告诉人们在开发如此重要的时候他们正在执行TDD基本上只是对他们说谎。
混乱

6

确切地说出您要问的内容有点困难,因为标题纯粹是关于TDD的,但是您似乎也将Scrum变成了问题不可或缺的一部分-而且据我所知,一个并不需要另一个。

如果我相信这个GD问题,那么TDD在游戏开发中没有多大用处。

那是正确的。我认为我从未听说过它在游戏行业中的实践中使用过。(但是后来我也从未听说过它是在游戏行业之外使用的,只是个人使用的。)

我来自工业编程,其中预算很大的大型项目需要完美无缺地工作,因为如果不对代码进行彻底的内部和外部测试,可能会导致灾难性的情况。

游戏不需要完美运行。因此,对代码正确性的重视程度大大降低。TDD不能保证代码的正确性,但是有些人认为它可以减少错误性。我还没有看到证明。

另外,遵循Scrum规则鼓励您在工作中按时完成工作,同时Scrum中的每个动作都必须按时完成!

我从来没有见过一种方法不鼓励会议到期日或采取没有时间限制的行动。问题在于,无论您使用哪种方法,估计软件的复杂性都非常困难。这并非不可能,但是准确估计它与该过程并没有多大关系。如果我的任务是添加新的GUI面板,或修复动画中的错误,或向角色添加新的统计信息,则使用Scrum根本不会加快速度,而使用TDD将会减慢任务速度(可能会在以后减少更多的维护任务)。他们当然不会使估算任务持续时间变得容易。

我认为TDD可以编写无错误的代码,尽管您不想编写“完美”的系统/游戏。

如果事实证明TDD可以比其他方法编写更好的代码,则可以。

有证据吗?行业可能会使用它的事实并不能证明。工业界以生产较差的代码(延迟交付)而闻名。没有大型TDD项目失败或迟到的例子,可能只是因为这是一种新方法,很少有人真正完成过这样的项目。(而且那些迟到的...可能仍在运行。)

TDD在游戏开发中是否可行?

可行吗?当然。有利?那还没有被证明。


1
不幸的是,TDD和Scrum仍然被误解了。对于现有项目而言,这都是正确的,它们既无助于加快错误纠正速度,也无济于事。Scrum是一个开发复杂系统的框架,就像一个游戏一样。Scrum鼓励从Sprint到另一个Sprint进行错误修复,以使它们永远不会积累。TDD将您置于用户一边。对于用户,我是指将使用您的代码的同事程序员。它迫使您思考如何使用它来使您的代码易于他人使用。因此,根据经验可以带来更好的设计。综上所述,您对主题有有趣的看法。
Will Marcouiller

1
强制错误不累积只会导致功能滑移-您无法神奇地产生更多时间。我的理解是Scrum并没有针对bug的任何特定方法。至于TDD强迫您考虑其他人将如何使用您的代码,这不是解决该问题的唯一方法。因此,它不一定更好,当然也不一定是最有效的利用时间。
Kylotan

1
仅供参考,Noel Llopis在其独立游戏中使用TDD,而他的老公司High Moon Studios则广泛使用它。没被引用,对不起。
tenpn 2011年

您有一些有趣的好点值得阅读!感谢您的贡献。尽管如此,我想补充一点,TDD是另一种方法,就像XP(极限编程)一样。是的,Scrum没有提供特定于错误的任何特定方法,而是投资于(开发人员)团队的自组织。Scrum不会告诉您如何做事,而只是告诉您应该做什么。团队的承诺是逐步完成必须完成的工作。Scrum只赌自组织的跨职能团队。由团队来决定如何开发和测试功能,等等
Will Marcouiller

(继续...)本周我已经回答了关于GD上的课程的第一个问题。OP希望了解如何在定向按键上使他的精灵移动。熟悉OOP概念后,我发现应该使用类来使用XNA开发我的第一个游戏。也就是说,我的Spacecraft类成为具有方法和属性的完全可测试的类。恕我直言,这种东西绝对可以使用TDD进行全面测试。假设您需要一艘太空飞船,然后针对每次完成一项测试所需的条件编写测试。
Will Marcouiller 2011年

4

对我的英语不好而感到抱歉,对我的观点持偏见也感到抱歉:我不是游戏设计师,而是编码员。

我认为这次讨论有些误解。我将以更通用的形式谈论TDD,即所谓的BDD。行为驱动开发不是测试项目的方法(测试类似于副作用)。 BDD是一种设计方式,是在整个生产过程中进行重构和软件设计的方式(请参见诸如KISS的座右铭,“保持质量”,“尽早测试,经常测试”),而不是一个单独的阶段。BDD与某些经典软件过程(例如瀑布过程)或某些其他迭代方法来制作软件相反。

另一点是,自动测试是针对那些可以由计算机自动测试的功能。没有测试游戏的乐趣,也没有测试图形用户界面的可用性。乐趣或可用性是其他工作的材料,而不是交互设计师,世界和水平d等软件开发的材料。就像艺术部分(建模,纹理等)适用于使用计算机作为创造力的工具的艺术家一样-显然,那些工作可以由同一人编写代码来完成,但这不是重点。可以测试物理学,可以测试优化算法,可以测试单个对象的行为(如前所述,带有模拟,存根和虚拟对象)

最后的想法是,恕我直言,不仅游戏设计而且整个编写代码都是一门艺术。


4

这是某人的案例研究,他认为TDD和gamedev可以很好地融合在一起:

http://powertwenty.com/kpd/downloads/TestDrivenDevelopmentInPython.pdf

诚然,这是Pygame中的一个小项目,但是它给出了可以用图形游戏测试哪些部分不能测试的想法。对于这种情况下的TDD可以完成多少工作,我感到很惊讶。


1
如果不与进行相同项目的对照组进行比较(以一种非常高级的语言克隆一个现有的琐碎的街机游戏),它不会说出TDD是否有效。只是说他使用了TDD。

3

不可以,测试驱动开发不适用于游戏开发。当然,您可以为要测试的某些部分编写测试,但是游戏开发过程与“测试驱动开发”完全不同,后者需要在开始进行开发之前具有确切的规范。

游戏启动时很少有确切的规格。如果这样做的话,它们在开发过程中总是会发生变化和发展。

游戏设计是一门艺术,您无法通过特定的测试来知道什么时候艺术是好还是完整。


您不认为在分析游戏本身,功能分析之类的东西时应该考虑娱乐因素吗?您可以设置一系列功能,一起使游戏玩起来有趣,然后可以测试此功能!我只是想提出不同的意见,以深入了解该主题和您提出的论点。感谢您的贡献!=)
Will Marcouiller 2011年

3
很多发展归结于微调小东西,看看它们有多有趣。除非将它们100%固定在石头上,否则您无法测试这些东西。完成后对系统的测试不是TDD,而是测试,而不是由测试驱动的开发。
AttackingHobo

2
如果您认为大多数现实世界项目在启动时都具有确切的规范,那么您可能没有从事很多现实世界项目。
BlueRaja-Danny Pflughoeft
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.