TL;DR : 我正在从一个 GDD 替代工具转变为一个游戏系统映射工具(之间的依赖关系,比如游戏机制、内容、角色等),我希望能得到您的见解。
那么,您可能已经知道了我关于 GDD当下的状态的帖子了。
大致来说 : 是这样的,我因为围绕着需要一个 GDD 和如果需要它该怎么样的疑问陷入了迷uddle中。
- "设计圣经"已经过时了,所以不是简单的wiki吗?
- 应该使用何种工具,比如 Notion 或 Obsidian 啊?
- 是一种高层次的概要文件,还是要涵盖所有细节?
- 就避免它的产生了吗,因为它总是需要变化?
- 状态跟踪应该放入其中还是只包含设计元素?
这些问题都深深吸引了我,渐渐陷入这个迷uddle里。
随着深入,我决定尝试制造一个专门为游戏设计而创建的GDD 工具,即使它最初不能完美地捕捉一切,相比之下,在游戏设计上一直能不断成长,并不像像 Notion、Google 文档以及 Obsidian 等一般目的工具那样只是完成了手头工作。
不幸的是,我在途中发现,即使这些工具是通用目的的,它们也做得相当不错地创造了一个 GDD,尤其是当你试图保持它的高层次时 (但它们能很好地处理细节内容)。
另外,我还发现它们并没有能够很好地跟踪 游戏的系统 和这些系统 之间的联系。
这更是重要了,因为随着游戏越来越越大,并且具有越来越多的互相关联的系统,随着这些系统进行改变,这些系统都可能会受到打断。
最终的目的是,这种转变正是我最吸引我的一部分,因为相比之下,其他形式的媒体是 静止的 ,而游戏则是活生生、持续发展的 ; 在设计、实施甚至执行时都有着变化,因此,这我想要为此制造一个功能适同的工具来更细致地追踪其中的系统变化。
鉴于这一点,我现在正在从尝试制造一个 GDD 替代工具转变为制造一个追踪游戏系统设计的系统的工具,以及与 GDD 一起使用。
在我试验时,多个零件之间的联系都成了整个工事的骨干,因此这个转变看起来是最恰当的了。
工具的方式是捕捉每件内容作为一个实体 (角色、能力、游戏机制、物品等),同时让您能够直接将这些实体与彼此关联(以及一些其他可以选择的功能)。
如果您想看到实际的截图,请参见以下 Imgur 链接:
因此,我需要以下问题的答案:
-
一句话,经过上文的阅读并(或)查看截图,您对这个是什么的理解是?
-
您是否会在工作中使用这个工具?如果是,什么样的情况才会使这个必要?
-
这个工具适合哪些人?
-
这个工具能够展现一些有趣的特点,但添加 X 将让它更有用。如果这个是您的想法,则是什么 X?
评论 (0)