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标头开销可能会有些高,具体取决于您的目标,并且根据您的用例,您可能希望放弃字节序交换支持...但是出于设计考虑,这绝对至少值得一提。