我正在写一款iPhone游戏,我正在尝试编写一些需求文档。我之前从未写过要求所以我得到了软件要求一书。我还没有完成它,但我想到了一些问题,因为这本书是针对一个企业。我的主要问题是我是唯一参与这个游戏的人,我觉得需求文档的主要目的应该是在我深入设计或构建之前,尽可能多地概述游戏的工作原理。有没有人有关于如何解决这个问题的建议,如果我仍然试图模仿书中提供的模板,或者因为我既是唯一的开发者和产品所有者,我应该坚持游戏概念吗? / p>
答案 0 :(得分:4)
你是对的,传统的SRS文档并不能很好地适应游戏文档。游戏改为拥有一般的游戏设计文档。它通常是在游戏的任何工作开始之前创建的,并且它经常被编辑,因为开发过程是为了保持预期的最终结果和游戏细节。
虽然商业软件需求文档就像客户和开发人员之间关于生产什么的合同,但游戏设计文档更多的是从设计师到艺术家和程序员的具体需要开发的规范。
没有特定的布局可供使用。但是你应该考虑你为谁编写文档。在项目完成后,它是为了一个班级,为自己,为同行吗?根据您的受众群体,详细程度和所包含的内容会有所不同。格式本身非常灵活,只要它是连贯的。
Brenda Brathwaite在这个问题上有一个很好的blog entry,你可能会觉得有帮助。 该主题还有来自gamedev.net的半近期article。
答案 1 :(得分:2)
[可怜的雅各布,你刚读了一本关于这个主题的书,而且,总的来说,SO社区为你写了另外一本书,还有额外的链接,可能还有不同意见;-)]
虽然我不熟悉你在问题中提到的这本书,但我认为以下建议可能会帮助你们认真对待,但也会放松一点,关于所有要求的重要问题。
作为一个“团队一致”,特别重要,有点自相矛盾,你需要通过正式化要求。但是,您可能会发现Agile开发方法(以及需求收集)更合适,而不是过分强调表单。关于需求,这种方法的主要优点之一是灵活性,即理解虽然它们应该正式化(时间/精力有限),但应该允许需求(在限制范围内)作为迭代过程的一部分进行更改生产目标产品。
从广义上讲,这通常如下:
答案 2 :(得分:1)
您所描述的书籍专注于不同的受众群体,但所提供的一般概念具有价值。完全开发的需求文档并不像您想象的那么常见。不要让任何人认为你是一个“糟糕的开发者”,因为没有最详细的要求。
如果您需要与合作开发人员沟通需求,则需求文档可能更为重要。
如果您是唯一的开发者,我强烈建议您将您的工作花在设计和实施游戏上,而不是要求。如果您对所构建的内容有一个很好的了解,那么在构建它时让它流动。
文档可以帮助您。问题是什么是最有益的。也许设计决策比对您的要求更重要,但对其他人则不然。您可能希望列出人们要求的内容或您认为但无法立即实施的想法。有时候白板可以方便地勾画出事物,它不仅仅是与其他人合作的工具。
答案 3 :(得分:1)
这只是一种通用方法......
巩固这个概念......首先用简单的英语写出来(例如:游戏是第一人称射击游戏。你杀死僵尸并寻找宝藏。)
获取纸垫和铅笔,绘制游戏的一般流程和用户将遇到的主屏幕...主菜单,选项屏幕,帮助等。确保它有意义。
转到mockingbird这样的网站,为您的屏幕创建详细的线框...
打印出来并做一些纸张原型设计......即。将打印输出放在你面前并“点击”按钮......然后调出相应的屏幕......然后点击另一个按钮等。
一旦有意义,您可以尝试开始编写游戏代码。
答案 4 :(得分:0)
我个人认为你应该用自己的方式来做这件事。最常用的一个不符合您的要求。它们可能适用于常见的商业服务器应用程序,但不适用于游戏。而且,由于iPhone游戏是一种新趋势,您可能需要从不同的角度来看。您可能无法填写符合标准要求的文档,并且您可能有不同的新类型要求。
答案 5 :(得分:0)
只是一个建议......注册Google协作平台,并创建一个包含游戏,要求,技术方面,工作日志等文档的私人网站......您可以与精选人分享,并始终保持编辑历史。
我比Wiki更喜欢它,因为它更结构化,而且使用起来很简单。