适用于非休闲游戏的 MVC，还是其他设计模式？
使用 MVC 编写严肃的游戏会是良好的设计和明智的举动，还是有另一种设计模式在处理此类软件时更有意义。有人用MVC做过非休闲游戏吗？你的经历是什么？
我正在使用 Objective-c w/Cocoa 设计一个游戏引擎，除了极其基本的即创建全屏窗口并获取绘图上下文之外，它不会使用任何 Cocoa UI 组件。在我使用 3D 或 2D 之前做过的引擎工作中，大多数绘图软件与描述要绘制的内容等的软件非常相关。其原因往往是优化（或者可能只是糟糕的设计） 。
Would using MVC to write a serious game be good design and a smart move, or is there another Design Pattern that makes more sense when dealing with this kind of software. And has anyone done a non-casual game using MVC? What was your experience?
I'm designing a game engine in objective-c w/Cocoa and it won't use any of the Cocoa UI components, other than extremely basic i.e. create a full screen window and get drawing contexts. In engine work I've done before using 3D or 2D, most of the software that draws is very much married to the software that describes what to draw etc. The reason for this tends to be optimization (or it could just be bad design).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
抽象是一把双刃剑，它使开发更容易，但会损害性能。然而，由于漂亮的图形，许多现代游戏都受 GPU 限制。如果您认为这是真的，那么您在 CPU 上所做的事情的影响较小，因为您无论如何都会等待 GPU 渲染帧。然而，大多数独立项目都无法将漂亮的图形达到足够高的水平，因此您可能仍然需要小心。
这并不意味着你至少不能半途而废。事实上，现在大多数游戏都是以伪 MVC 风格完成的，特别是使用更新/绘制循环而不是简单的循环。基本上，您的所有游戏代码都位于与绘图代码不同的单独方法中。您的游戏代码更新游戏的状态，然后绘制代码呈现它。
如果您正在滚动自己的物理（或其他基于帧的）引擎，这尤其好，因为它允许您将 FPS 与更新周期分开。例如，您可以将游戏引擎编码为以 60 FPS 运行，并且如果需要，只需在绘制调用之间进行多次更新即可。
总而言之，您应该始终将游戏中的更新和绘制代码分开，这是一个简单的步骤，开销最小，提供了 MVC 的大部分简单性，而无需承担与完整 MVC 结构相关的成本。
Abstraction is a double edged sword, it makes development easier, but can hurt performance. However a lot of modern games are GPU bound due to the pretty graphics. If you think that is true than what you do on the CPU is of lesser consequence as you will be waiting on the GPU to render a frame anyway. However most solo projects don't get to the pretty graphics to a high enough level for this to be true, so you will likely still need to be somewhat careful.
This does not mean you can't at least go halfway. In fact most games are now done in a pseudo MVC style, specifically an Update/Draw cycle is used rather than a trivial loop. Basically you have all of your game code in a separate method than your drawing code. Your game code updates the state of the game, then the draw code renders it.
This is especially nice if you are rolling your own physics (or other frame based) engine, as it allows you to separate the FPS from your update cycles. For example you can code your game engine to run at 60 FPS, and simply update multiple times between draw calls if you need to.
To summarize, you should always separate your updating and drawing code in a game, it is a simple step with minimal overhead that provides a good portion of the simplicity of MVC without the costs often associated with complete MVC structures.
我假设您正在谈论角色扮演游戏。
将游戏引擎视为控制器和查看器的组合。
游戏引擎的设计输入是模型。
I'm assuming you're talking about a role-playing game.
Think of the game engine as a combination of the controller and the viewer.
The design input to the game engine is the model.