1.2集成复杂性与模块化
首先，中间件包最重要的特性是其集成复杂性。好的库是高度模块化的，最小的侵入性，并且很容易插入到非常不同的代码库中。在Shor T，它们所作的假设非常少，并且与其他系统的实现细节是相当解耦的。一个好的库应该有合理的缺省值，或者需要非常有限的配置。 e该系统处于可测试的工作状态。集成工程师的经验水平可以在系统的可用性中起作用，因此最小集成是关键。这促进了快速评估 在循环中-当工程师有一个很长的集成周期时，它会留下苦涩的回味，但却发现库是不可取的。我的经验是两天。任何需要超过两天的事情 运行起来会浪费一周时间来完成它的运行，而且开发周期中没有足够的时间来尝试替代方案。
1.3内存管理
游戏开发商都知道小心，内存管理是一个稳定的产品的关键。中间件用于虚拟内存支持的PC系统，甚至那些高要求的技术 下一代游戏机可以满足，可能不适合过去的较为温和的内存预算。重要的是不仅要知道预期的内存预算，还要知道谁负责。 或者管理分配。
理想情况下，每个中间件库都有自己的内存管理方案，只需使用两个参数进行初始化：指向内存块及其大小的指针。中间件库作者是 对分配的大小、分配的流失率和内存管理算法最了解的人，最适合于在自己的分配池中防止碎片化。F urther，这样做的优点是在超出内存预算时显式地通知开发人员，而不是从跟踪的主堆中收集不理想的大量内存。 降低内存消耗可能是乏味的，也是有问题的。此外，这种方法往往会突出显示库资产被泄露的集成事故，因为当堆被释放时，它很快就会失败。 STED。一个可调整大小的堆有时是可取的，特别是当某些游戏级别需要转移内存特权来强调不同的系统时，尽管这个特性是相当罕见的。
如果没有一个由中间件库管理的完全隔离的堆，那么一个好的退路是，您需要为alloc()和free()提供缺少的两个函数，您可以 使用自己的函数重新编写弱声明的函数，或者最后，您可以从源代码编译库，并能够提供用于分配的#Definition宏。这些方法中没有一种产生pe。 r分配函数调用开销，因为它们由编译器或链接器解析。在此方法中，您可以选择将分配转发到主堆(不要！)，或者使用您选择的分配策略声明一个专用于子系统的特殊堆。有些中间件只提供一种注册分配回调的方法。它是一种普通的宠物 招惹不必要的浪费CPU周期，这是一个轻微的抱怨，我对其他的固体产品。
最糟糕的情况是，库中到处都是对新/malloc和DELETE/Free的直接调用。这并不提供简单的封装系统资源的方法，也没有简单的方法来封装系统的资源。 测量或限制其消费。
1.4大容量存储I/O访问
访问光媒体是非常缓慢的，寻求--即使是在硬盘上--可以主宰负载时间。而某些类型的中间件需要访问文件系统，特别是流的声音系统。 在后台加载游戏资产的音乐或异步流系统，大多数不需要直接访问物理媒体API。
撇开这些例外，中间件通常确实需要访问某些资产，但它永远不应该通过直接从底层系统API请求它们来做到这一点。一个好的中间件库提供 它是开发人员轻松重载文件和数据请求的显式钩子，这样它们就可以通过开发人员可能选择的任何自定义文件系统(例如wad或pack文件)进行连接。 存储数据或将文件请求重定向到不同的硬件。
最灵活的库根本不试图将数据作为文件或流来处理，而是专门处理大容量内存缓冲区，并将资源获取牢牢地掌握在开发人员的手中。 艾尔斯。这种方法简化了错误处理和加载时间优化，并且更快地部署到新的硬件上，并取得了可靠的结果。
最糟糕的中间件库(我在开放源代码中经常看到这种情况)假设POSIX文件系统总是可用的，或者类似的系统，并且直接依赖于C运行时库调用如下 作为文件和fopen()。
另一种试图解决文件系统抽象的错误尝试是，通过为用户提供的读取器/写入类提供抽象接口，对文件流进行了侵入性扩展。a派生于 这个接口的姿态是通过一个虚拟函数一次一个字节，甚至在固定大小的小块中捕获数据。这很难映射到真实世界的数据和性能特征，并且应该是 不惜一切代价避免。
1.5日志
在中间件库中，有时期望无法满足。一个好的库以统一的方式处理警告，并且可以将它们集成到你现有的日志系统。更好的库将有一些琐碎的详细设置，从嘈杂到绝对安静，最好是编译出字符串和错误检查e。 不折不扣的。冗长的设置会提供大量的数据细节，这让开发人员有一种信任感，即库已经正确集成，其文件也是Read适当。但是，如果您不能完全编译出这一点，那么它的代价是内存和CPU性能，这在最终发布版本中是不可接受的。一些中间件随版本和deb而来。 UG库就是因为这个原因。
最好的架构中间件产品有一个简单的方法来连接日志输出回调，这样日志就可以集成到游戏的现有报告系统中。小心所有的图书馆 Thely调用printf()，因为这个函数相对昂贵，甚至可能没有一个标准的输出管道连接，从而无法通知用户。
1.6错误处理
最好的中间件根本没有错误条件，因为它们总是工作的。我希望这样的事情存在。同时，回到地球上，错误是不可避免的，对它们的处理 在确定某些软件是否可以在您的项目环境中运行时，这是一个重要的特性。对于错误总是致命的，总是可以恢复的，或者 在中间的灰色地带。中间件库给您在这件事上没有选择，也没有办法覆盖错误的处理，倾向于降级。
正如控制台开发人员所知道的那样，修补游戏通常是不可能的，而一些bug实际上是不可能复制或跟踪的。有时需要采取“英勇的措施”来保证游戏中的无名氏。 即使某些子系统完全完全失败，也不会崩溃。每个软件都应该有一些能力通过处理程序转发严重的错误，在那里，在绝望的情况下。 你可以让声音系统安静下来，清除屏幕，在挂起之前打印“你赢了！”，或者至少重新启动。避免使用EXIT()、ABORT()甚至是裸露的ASSERT()调用。
1.7稳定性与性能一致性
中间件应该是稳定的。毕竟，开发人员自己不编写东西的主要原因是编写和调试它所需的时间。无法报告(并试图重新记录)的库 从常见的琐碎错误是脆弱的，并且经常会被开发人员诅咒。最好的中间件永远不会崩溃，不会修复垃圾输入或忽略它们，并且会留下大量的调试br。 程序员跟踪问题时要遵循的方法。顶级的工具和引擎可以在不完全崩溃的情况下维护严重的数据损坏和文件丢失，这可能最终导致弹劾。 在处理问题时，整个团队的进步。每个项目在性能方面都有不同的期望，所以你自己来判断什么是绝对可以接受的。但是，您所考虑的每个中间件库 可用的内存和CPU性能曲线也应该一致。一个稳定的帧内存占用是按时运送游戏的必要条件。偶尔的帧速率可以是H。 ARD的追踪，也严重降低了游戏体验。在任何情况下，当使用分析器进行测试时，好的中间件都应该是一块石头。
我最近参与的一个项目，单帧内存峰值为2MB和100 ms。跟踪它之后，它是由于一个小的改变，一个级别的脚本是如何写的。更一致的虚拟机器 Ne会限制它执行的指令数量，或者将执行限制在一个时间片上。一个更稳定的库可以更密切地监视它的内存使用情况。轶事证据是如此 在最坏的时候，你在这里所能得到的一切，直到你与个人经历发生冲突。四处打听。
1.8个自定义分析工具
每当考虑一个包包含，我印象深刻的工具，减少在项目结束时的不确定性。这些包括任何带有监控API的系统，或者更好的是，P 某种程度上来说，当内存紧张，CPU时间稀缺，没有人知道它要去哪里时，这就减少了游戏接近尾声的程序员的时间。能够立即拉动o UT工具，仪器的比赛的一部分，有助于迅速缩小搜索范围。获得可视性的内容通常是困难的，所以任何有助于你的中间件提供了巨大。
1.9客户支持
商业中间件通常提供集成专家、电话支持、直接电子邮件支持以及论坛或邮件列表。有时，这正是团队前进所需要的，尤指 当他们到达一个主要的绊脚石时。中间件的全部原因是降低风险和不确定性，而客户支持就是这样做的。没有期望支持的中间件是 没用的。我已经放弃了许多伟大和有希望的技术，仅仅是因为作者无法回答几个问题。
注意论坛和专门人员在电话或电子邮件中回答问题的快速响应时间，并准备在他们要求时向你发送集成代码。（这些都是 他最好有理由保持它的整洁。)
1.10对维修人员的要求
程序员是忙碌的，昂贵的资源。中间件需要花费大量的精力和精力来很好地集成到您的构建系统中，它将很快被踢到边缘。艾德 您只需向构建过程添加一个库，#包含一个头文件，并调用几个函数。Ta-da！它是集成的。
有时，中间件更具侵入性，需要设置各种#Definition宏来配置它。或者，它需要直接集成到您的项目中，并与您的游戏编译。 此外，一些中间件具有外部依赖项，必须存在这些依赖项才能进行编译。更糟糕的是，它可能需要在构建过程中引入一个新工具，而这个工具可能无法很好地与th一起工作。 e建立系统。交钥匙系统显然更好。我寻找GCC和MicrosoftVisualStudio项目文件附带的中间件，但它们具有非常基本的项目配置。这证明 我所关心的编译器可以处理代码，我可以丢弃项目文件，并在使用提供的项目文件进行初始构建后以自己的方式集成它们。
1.11源代码可用性
最后，您可能需要调试到您计划集成的中间件产品的源代码中。如果它是一个专有的、封闭的、没有源代码选项的、价格合理的产品， 寻找替代方案。虽然库中某些“行业机密”部分可能仅为二进制，但供应商知道源代码是需要的，并且通常会为其提供许可证。不给养的人 E源通常声称他们的客户支持消除了所需的内容。虽然这可能是真的，但当客户支持无法解决问题的时候，源代码就可以了，那就是我们 开始寻找替代者。同样，使用中间件的一个重要原因是它是经过验证和稳定的，所以源代码不应该是真正必要的。但是可用性仍然是很重要的 d有必要。
1.12源代码质量
拥有源代码并不总是意味着您有能力进行有意义的更改。最好的中间件有优秀的文档，这些文档是在每次新的代码删除时自动生成的。它W 我有一个熟悉且一致的大括号方案，函数和变量的某种命名约定，理想情况下，它将驻留在一个简短的名称空间中。
花点时间仔细阅读重要的头文件。检查是否#定义宏用于语言关键字或公共函数，如New、min和max，或者实际上，任何转义h范围的宏 会在其他地方引起问题。使用存档检查实用程序(如dumpbin(在Windows中)或nm(在Linux中)来验证中间件库定义的唯一导出符号在 一个一致的命名空间，以避免与其他库或您自己的代码发生冲突。
有问题的中间件将被#实用化语句所取代，将禁用错误，降低警告级别，等等。在头文件中的这些语句可能会损害 代码的质量，可能会导致一些文件通过包含它们而停止编译。
1.13平台可携性
某些类型的中间件可能与平台无关，但即使您有源代码，也可能存在隐藏的字节排序(Endianness)问题。检查文件和网络流手 每个平台都可以将数据设置为本机格式，而凌对Endian交换代码或者可能是不同的资产构建工具。
多线程在今天的游戏中非常常见。有些中间件库早于这一转变。确定如何处理线程锁定，代码是否是线程安全的，以及线程控件是否为eas。 用不同平台的接口覆盖。请注意，在线程环境中使用任何不使用线程的库本质上都可能是不安全的。因素 使库线程安全的时间，或者至少在任何时候将其使用限制在单个特定线程上。
另外，考虑一下你的游戏是否会在某个时候被移植到一个能力较差的硬件平台上。如果可能的话，确定这个中间件提供的哪些特性是唯一的，可以移植到 如果这个库不存在于低端平台，那么另一个库就特别困难了。
1.14牌照规定
我不是律师，这也不是法律建议。咨询自己的律师，回答具体问题，并亲自阅读每一张执照。还要注意的是，大多数出版商，甚至一些硬件制造商 对于在您开发的产品中允许使用什么开源许可证，制造商都有严格的规定。在集成一个开源许可证之前，通过他们的法律部门清除所有开放源码许可证。以下内容 是我告诉外行的意见。
我所知道的每一个开源许可证都会作为分发软件的结果而生效。这意味着，只要您不将软件分发到公司之外，您就可以使用 任何你喜欢的应用程序内部使用。在您的内部面向服务器技术或工具中可以随意使用任何开源代码，但不要计划分发这些程序。
公共领域代码是完全无害的。一旦你把代码拷贝到你的硬盘上，你就拥有了它，你对它所做的每一次修改都是你要保留的。当然，您可以将许可证更改为 否则，把它放回公共领域，或者保密。是你的。
麻省理工学院、Zlib等公司的许可证似乎或多或少地否认了你如何使用他们的软件的责任。他们不要求任何东西，除了信用条款，而且某些通知仍然存在。 他在编码。这不是限制零售使用的许可证。
LGPL许可证有一些规定，要求分发库的源代码(可能还包括您自己的应用程序的一部分)。在零售产品使用前仔细阅读。
如果将GPL许可证和许多其他类似的许可证集成到产品中，则需要在发行版上发布完整的代码。
通常，商业中间件许可证需要信用属性、启动屏幕、电影简介等。请注意遵守这些属性，并在适当的中间件作者帮助下给予信任。 让你的游戏发生。
1.15 预算
每个游戏都有不同的中间件预算。预计价格将从100美元到750000美元不等，这取决于你所看到的产品类型。伟大的中间件需要专业的注意 在细节上，当专业地使用库时，良好的支持是很重要的(但是通常会根据您的需求水平而花费更多的费用)。
在寻找一个花费了钱的图书馆时，要考虑的是每个座位、每个游戏、每个平台的成本，或者是否有维护许可证，比如每年。许多中间件公司都有特殊的 数字下载标题与零售标题的比率。此外，也要愿意打电话给您选择的中间件商店的帐户经理，并试图甜言蜜语他们到折扣。你可能是超级高手 如果这是你的第一个标题，他们非常清楚中间件往往会变得根深蒂固和昂贵的删除，所以这对他们是好的，让你上钩 红外产品。如果你有这样的杠杆，试着制定多个项目交易。
一些库(如Zlib)已经发展到
全文共5961字，剩余内容已隐藏，支付完成后下载完整资料
资料编号：[13719]，资料为PDF文档或Word文档，PDF文档可免费转换为Word
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
