在两个单独的图形库上具有相同的游戏逻辑


11

什么样的编码理念/抽象/程序设计结构可以使游戏同时(单独)与2D和3D图形一起使用,而无需重新编码游戏逻辑?

我们正在讨论采用相同的代码,更改最少的内容(例如,将2D资产的文件名与3D资产的文件名交换),并可能为每个泛型/模板插入一些基类的专业化知识。

将其置于有意义的真实环境中:想象一个局域网多人游戏,其中有一个一流的,渴望性能的3D客户端,为玩家提供了一些非常好的游戏装备,而一个较不起眼的2D客户端有人在阁楼上发现的满是灰尘的盒子。但这仍然是同一游戏-记录了相同的事件(有人捡了一个硬币),使用了相同的网络协议,世界成比例,等等。

将其置于MVC上下文中:控制器完全相同(按“向上”键会将玩家加速设置为3.5单位/秒),视图完全不同(2D与3D),并且模型相同除了与图形直接相关的所有内容外(每5秒钟对环境进行一次碰撞检查,并且使用相同的算法。请注意,这意味着2D版本中的所有游戏对象都有一个Z坐标,但是只是被忽略或以其他方式显示给用户,例如,当播放器处于空中时,阴影会显示在最左端)。

之所以使这个主题如此吸引人,是因为它将迫使开发人员对他的数据的结构以及控件的流动方式有一个非常清晰的认识。请注意,这并不意味着使用诸如SDL,D3DX或OpenGL之类的图形库以外的任何东西。没有游戏引擎!

由于这是一个主要的理论问题,因此我将省略编程语言,但是如果您要举一个例子,则可以使用任何喜欢的语言,如果想全力以赴,则可以使用C ++;如果您愿意,可以使用Brainfuck。应对挑战(任何具体的答案以及任何抽象的答案都将受到赞赏!)。


我不确定这是否可行。如此多的游戏逻辑都使用矢量数学,您要么必须在转换为2D之前先在3D中做任何事情,要么要进行渲染,或者必须完全抽象出矢量库-这肯定是不切实际的?
tenpn

搜索术语“抽象层”并熟悉它,因为你们两个将一起工作一段时间。
zaratustra

Answers:


8

我认为,您所需要的全部(?)就是包裹图形库的抽象层;您将为要使用的每个库都需要一个新的库,并且每个库都需要具有完全相同的外部API。

考虑字符串的本地化:您无需调用(可能是定制构建的)本地化库,而是将字符串“ Inventory”硬编码到游戏中,该库将执行一些处理并返回适当的字符串,具体取决于游戏。

以同样的方式,所有对图形引擎的调用都将通过包装它的包装器进行。

在执行此操作时,您可以限制/限制可以给图形引擎提供的命令。以下是一些必不可少的内容:

  1. 在(位置)绘制(图形对象)
  2. 修改(图形对象)的(alpha,旋转等)属性
  3. 将(图形对象)移动到(位置)
  4. (级别名称/数据结构)的构建图

还有其他一些,在您进行项目时会发现。

如果使用的是严格类型的面向对象语言,则可以将上述命令称为包装程序将全部实现的接口。优选地,这些将是唯一不受保护/公开的方法。

现在,为每个图形库创建一个新的包装,并实现API。当给出在__处绘制__的命令时,您必须使用代码来创建精灵或模型,并将其绘制到您的环境中。这可能需要一些技巧,例如将每个子图形存储在散列中,以便在另一个时间可以通过给定的符号重新访问。

对于构建地图,最有效的方法是预先为每个图形引擎预先构建每个地图并进行查找。或者,您可以将地图存储在自己的自定义数据结构中,然后使用包装器从该数据结构中构建地图。

希望这可以帮助您入门=]


2

对于大型项目而言,使用足够接近MVC的范例来构建游戏体系结构以允许完全抽象显示代码是非常困难的。但是,似乎要创建一个同时支持2D和3D客户端的游戏,最大的障碍就是设计一款能够同时支持两个客户端的游戏。

必须以创建和支持两个客户端的全部意图开始您的游戏设计,并且将所有游戏功能限制在2D客户端认为有意义的位置可能是最安全的。

作为一个陷阱,例如,如果您不设计受限的功能集,则可能会创建一些级别,在这些级别中,重要信息或对象只能从特定角度看到。除非您的2D客户端明确支持对每个重要对象都具有可见性的视角,否则这对于具有360度查看自由度的3D客户端会很好,但是这会损害客户端的用户。

最好为2D客户端设置特定数量的视角(8个或16个左右),并开发所有内容以适合这些限制。不幸的是,如果您设计的关卡和对象只能从一组特定的角度进行查看,则在3D客户端中它看起来可能很奇怪。

在我看来,尝试进行旨在具有相同功能的2D和3D客户的游戏设计是一个错误的选择。我认为,更好地利用资源来设计非对称的游戏选项,并允许每个客户发挥自己的优势。例如,如果2D客户主要专注于游戏世界的战略级视角,而3D客户则用于战术级游戏玩法。


0

我认为您已经回答了您自己的问题:

将其置于MVC上下文中:控制器完全相同(按“向上”键会将玩家加速设置为3.5个/秒),视图完全不同(2D与3D),并且模型相同除了与图形直接相关的任何内容。

因此,通过在输入,游戏逻辑等与图形之间提供足够的抽象,您将解决此问题。

这基本上是MVC模型的重点,尤其是与桌面和Web应用程序有关时:可以有多个客户端访问和操作相同的数据(例如,Web界面,移动客户端和电子邮件的桌面客户端)。


0

如果您想简单,请保持简单:-编写游戏逻辑以移动对象。不要在其上存储任何与渲染相关的数据。-编写渲染器,使他们有机会查看游戏数据的状态并进行绘制。

您可以为此使用或多或少的复杂编程技术。您唯一需要的是一种获取“额外”数据的方法,每个数据需要渲染。最简单的方法是将零个额外数据要求!如果游戏对象是“向导”,请绘制一个向导。

如果需要更复杂的方法,请考虑多态性,内存模式,哈希表,void *指针等。不要过度设计它(大多数方法都是过度设计的)。

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.