内容管道工具是否应该嵌入引擎中?


10

游戏引擎应该有多低?引擎中应嵌入多少内容管道?

超级引擎可能有用的一些用例:

  • 加载用户内容时,不需要用户打包其纹理,引擎将在加载时执行此操作。

  • 脚本请求的字体大小要比预先生成的字体大得多,引擎可以解析ttf文件广告以构建新的纹理图集。

  • 晕锻

当然,这些都不是免费的。这需要您的内容管道工具使用C ++编写。您需要对管道中使用的支持库进行编译以在设备上使用。它要求内容生成必须没有错误。而且通常会使您的引擎更大且笨拙。
还有哪些其他优点和缺点?
优点胜过缺点吗?

一些具体问题:

  • 引擎应该能够加载各种图像格式吗?仅TGA加载程序非常容易编写代码。

  • 音频格式呢?仅支持加载wav文件是否可行?周围的音乐文件通常很大。

  • 引擎是否应具有动态TTF解析和图集生成的能力?

  • 纹理包装。

Answers:


11

Noel Llopis的Games From Inside博客最近在“远程游戏编辑”帖子中谈到了这一点。开头段落:

我一直是游戏运行时间最少的粉丝。可以脱机或使用单独工具进行的任何操作均应超出运行时范围。这就使得游戏的体系结构和代码非常精简和简单

(无论您是否同意100%,本文都是与Noel大部分文章一样的强烈推荐读物。)

我相信这里的关键是保持引擎之外的复杂性。您仍然可以具有灵活性,但是在内容管道中却具有灵活性。而且您无需花费时间转换和移动数据即可获得更好的性能。

奇怪的是,尽管失去了一些引擎内编辑功能,但更好的性能可能会缩短迭代时间:如果您可以在一秒钟内加载游戏,尝试某些操作会更容易。

采用“ Unix哲学 ”的一些原则将帮助您保持工具链的灵活性:一个小的模块化管道。

我的个人哲学:尽可能多地脱机烘焙大量数据,但提供引擎支持以随时接收新的烘焙数据。(请注意,只有在方便时才需要使用此新数据:按下“刷新”按钮,开始下一个级别,然后过渡到新区域,无论如何。关键是找到最小化的最佳点迭代时间,同时将代码复杂度和编码工作降到最低。)

在我们公司,大多数面向美术师/设计师的工具都集中在UI问题上:易于处理单个资产或其批次等。有时它们只是像Photoshop或3DS Max这样的第三方工具。这些工具导出为中间格式(通常是xml,它引用源二进制数据,但并非总是如此)。中间格式由后端“数据制作”工具获取,该工具将其烘焙成对目标平台有用且快速加载的内容。

可移植性是通过添加其他后端数据制作工具或扩展现有的后端数据制作工具来实现的,这具有内容创建者不可见的附加优点。

现在,有了适当的增量数据,您可以在几秒钟内更改烘焙格式;您的引擎可以启动,工具也可以启动,然后这些将出现在您的资源系统中,并在方便时准备重新加载。

这些工具-尤其是后端数据制作工具-通常比引擎代码更加草率和错误。可以,因为它们更易于重构/重写,扩展和测试。您对它们的行为有规范,并且与某些引擎代码相比,对它们进行单元测试相当容易。

我对您的问题的看法:

引擎应该能够加载各种图像格式吗?仅TGA加载程序非常容易编写代码。

(此外:即使您在引擎上使用TGA解码器,也不要对其进行手动编码。您只是在问麻烦-大多数图像格式都有很多细微之处,而且很多工具不兼容完全符合可能未指定的格式。最好是找到现有的经过测试的图像处理库代码。)

我希望这里的工具可以从TGA转换为您的内部纹理格式,再加上元数据。

音频格式呢?仅支持加载wav文件是否可行?周围的音乐文件通常很大。

我们在这里使用三种格式:跟踪音乐(.xm),ADPCM(.wav)和Speex(.spx)。这主要是因为我们使用的是手持设备,并且这些格式的解码非常轻巧。

引擎是否应具有动态TTF解析和图集生成的能力?纹理包装。

地图集是一个难题:请参阅您最近的问题的答案。脱机几乎总是值得的。

另外,您可以将每个字符的元数据制作成接近零加载代码的烘焙结构。

最后,您可以为mod社区清理并打包此管道与您的游戏。您始终可以添加更多源格式。在特定情况下,没有什么可以阻止您缩小内容创建工具与引擎之间的差距。希望您的数据烘焙代码和爬虫/传输代码可以重构为库,在某些情况下最终可能由内容创建者工具直接使用。但是我不一定要实现我的第一个目标……只要知道这将是一个最终目标,并让它对您的设计产生一点影响,并且首先争取成功。


作为更新,您可能需要考虑对纹理使用KTX文件格式。它的优点是主要是“读入struct在大多数GL用例中并 ”(从您的注释中听起来好像您是在针对GL),同时仍然保持灵活和定义明确。

对于完全烘焙的数据,KTX标头开销可能会有些高,具体取决于您的目标,并且根据您的用例,您可能希望放弃字节序交换支持...但是出于设计考虑,这绝对至少值得一提。


好东西,谢谢。我从未考虑过构建自己的易于加载的图像格式。是否已经建立了最小的纹理加载库。再一次,它基本上是具有宽度,高度和编码(即GL_RGB555)的字节流。
deft_code 2010年

1
不要过多地构建自己的图像格式,而不必将图像转换为DirectX,GL或您正在使用的任何格式。=)就图书馆而言:那里有一吨。对于工具,我倾向于只使用ImageMagick( imagemagick.org/script/index.php)库中的东西,甚至程序。经过测试。我相信其他人还会有很多其他建议;如果您在工具链中使用例如C#,那么很多东西已经内置到.NET库中了……
leander 2010年

1
“我相信其他人还会有很多其他建议” MFC!:)也许是OpenIL。我认为将资产烘焙为特定于平台的格式的要点之一是,随着您添加更多的源格式和更多的平台,组合的数量将会激增。将源资产转换为中间格式,然后将其转换为特定于平台的格式,将减少转换路线的数量。添加另一种源格式,只需将转换器写入中间格式即可。添加另一个平台,向该平台目标格式添加贝克。
克里斯·豪

1
我要补充一点,将复杂性保持在引擎之外并不一定意味着该引擎无法使用该功能。但是,将其保持分开是很容易与引擎分离的关键。我无法强调支持资产的热加载(即即时重新加载)有多么有用。不过,这也可能给您的系统带来很多复杂性,因此您需要确保它的构建方式使得游戏无需关心资产的来源。
dash-tom-bang 2010年

3

您的问题听起来很主观,在很大程度上取决于您的目标受众是谁。

让我们来解决您的font / ttf解析问题。如果您打算使用添加自己的字体的modders,那么您可能希望使导入过程尽可能少。如果要在内部向游戏添加很多字体/字体大小,也许您想要一个稍微复杂的工具,美术人员可以在稍加培训的情况下使用。如果您打算在内部执行一次操作,那么花费在制作合适的导入器上的时间可能会少于花时间为上述情况编写工具。

这实际上与其他所有因素有关。嵌入式工具值得您花很多时间在做某事并且想要减少由此带来的复杂性/错误时。您添加的每个附加限定符(即仅TGA纹理而不是例如PSD的导入)都会导致最终用户花费更多时间。

请记住,内容工具通常由技术含量较低的人使用(请参阅:艺术家)。就个人而言,我真的很喜欢Unity的工作方式,您可以在其中拖动源文件(psd,3ds,ttf,mp3,jpg,mov等),它将自动将其转换为内部格式。内部格式大部分对最终用户隐藏。当它检测到源文件更改时,它也会自动重新转换。但这是很多工作。

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.