【问题标题】:Using a virtual machine inside of a game?在游戏中使用虚拟机?
【发布时间】:2011-07-11 12:05:53
【问题描述】:

我正处于制作 3D“机器人编程”游戏的设计阶段。灵感来自 Colobot、Robot Odyssey、Cholo 等游戏。

我希望游戏中的每个机器人都拥有自己的隔离环境/操作系统/虚拟机,就像他们在现实生活中一样。每个环境都应该被沙盒化,这样就机器人与游戏其余部分的交互方式而言,它是机器人的本地环境。

最初我打算按照“计算系统元素”一书中的描述来实现 HACK VM,但后来好奇是否有更好的解决方案来解决这种游戏风格的性能问题。

所以我的问题是:是否已经存在可以很好地满足我的目的的虚拟机架构?

附:使用的语言和游戏引擎尚未确定,但可能是 C# 或 smalltalk。

【问题讨论】:

  • 使用您实现本身的 Smalltalk VM,并让节点通过 IP 进行通信?
  • 我正在使用 smalltalk HydraVM 研究这个想法。我遇到了一些问题,然后忘记了整件事。我会看看我是否能弄清楚出了什么问题。
  • 好吧,我设法在 HydraVM 中并排加载了 11 个 smalltalk 图像……不幸的是,图像在尝试加载第 12 个时崩溃了。使用了 200 兆字节的内存。是时候研究缩小这些图像了。 :)
  • 我在考虑独立的虚拟机,每个虚拟机都在自己的进程中运行(或者,您可能可以运行 Hydra 以获得更好的 IO)。
  • 实际上,您使用了哪些资源来了解 Hydra VM?我从来没有使用过它的乐趣。

标签: smalltalk robot vm-implementation


【解决方案1】:

嗯.. 为每个机器人使用单独的图像有点过分 IMO。 我不知道您项目的要求,但为什么不使用自己的流程在同一图像中运行所有机器人? (要知道smalltalk支持绿色线程模型)。

关于 HydraVM:最初它是一个概念验证项目。令人惊讶的是,它运行良好且相当稳定。 但是对于进一步的开发,您需要一个真正需要这种架构的项目。 坦率地说,当时 smalltalk 语言级基础设施还没有准备好(我不会说它今天已经准备好了;) 因为要利用它,您需要更好的工具,例如远程调试、远程浏览、远程图像管理等。

听到您能够并行运行 11 个图像,我真的很惊讶。棒极了。因为我从未尝试运行超过 2 次 :) 这么多图像的问题是您需要不同的内存管理系统。而 Hydra 中使用的一个继承自 Squeak VM,并不真正适合这种设计。

【讨论】:

  • 所以我不知道使用单独的进程在同一图像中运行机器人是否适合我的游戏创意。问题是,我希望用户能够对机器人进行编程,即每个机器人都有一个底层的“操作系统”。理想情况下,他们可以用 smalltalk 对机器人进行编程,但任何脚本语言对我来说都可以。我认为进程不能在一个图像中工作的原因是,如果您为一个机器人编写脚本,则该脚本不应访问图像中的任何其他机器人,或者能够将游戏状态更改为超出本地状态对那个机器人来说是可能的。
猜你喜欢
  • 2012-07-17
  • 1970-01-01
  • 1970-01-01
  • 2015-11-26
  • 1970-01-01
  • 2011-09-28
  • 2016-10-09
  • 2012-07-27
  • 1970-01-01
相关资源
最近更新 更多