如何组织游戏代码以适应MVC模式？ [英] How can you organize the code for a game to fit the MVC pattern?

问题描述

我是大学新生，攻读我的计算机科学学位......过去几年我编写了大量的课程，但最近我对组织代码，设计模式，语言差异的理论思考越来越深入了解等等。

I'm a freshman in college going for my computer science degree... I've programmed plenty the last several years but just lately I've been getting more into theoretical ideas about organizing code, design patterns, differences in languages, etc.

我有一个Java类，所以我放弃了我的C ++研究/开发，转而使用Java和JOGL（Java OpenGL）。太棒了！但这就是重点。

I have a Java class, so I've dropped my C++ research/development and moved into Java and JOGL (Java OpenGL). It's wonderful! But that's beside the point.

我想制作一款小型角色扮演游戏，但这个问题确实适用于任何类型的游戏。如何以结构化的方式组织游戏对象，如模型 - 视图 - 控制器模式？它看起来是一个惊人的模式，使用非常广泛并且很有意义，但我无法弄清楚如何实现它。

I want to make a small role-playing game, but this question really applies to any sort of game. How do you organize the game objects in a way that is structured, like the Model-View-Controller pattern? It looks to be an amazing pattern, very widely used and makes a lot of sense, but I'm having trouble figuring out how to implement it.

例如，我需要跟踪GL对象以绘制到屏幕。我必须有实现MouseListener，MouseMotionListener，MouseWheelListener和KeyListener（或者一个类，一个多功能一体的输入管理器）的类。而且我必须将我的游戏数据放在所有这些不同类可以访问和修改它的地方;如果有人按下键盘上的按钮，输入管理类需要以某种方式执行键映射到的操作;当需要绘制一个框架时，图形类需要找到一种方法来遍历所有不同的事物并将它们全部绘制出来。

For instance, I need to keep track of a GL object for drawing to the screen. I have to have classes that implement MouseListener, MouseMotionListener, MouseWheelListener, and KeyListener (or one class, an all-in-one input manager). And I have to put my game data somewhere where all these different classes can access and modify it; if someone presses a button on the keyboard, the input managing class needs to somehow perform the action that the key is mapped to; when a frame needs to be drawn, the graphics class needs to find a way to loop through all the different 'things' and draw them all.

我最大的问题， GUI;在哪里与它相关？它类似于输入，但并不完全，它需要设置和获取实际游戏模拟中的数据......如果我决定尝试添加网络，那就更复杂了（类似于GUI ）还需要访问大量的数据进行修改和阅读...

And my biggest issue, the GUI; where does it tie into it all? It's something like the input, but not quite, and it needs to both set and get pieces of data from the actual game simulation... And complicating it even MORE is if I decide to try and add networking, which (similar to the GUI) also needs to have access to a lot of the data for modifying and reading...

哦，我只是感到困惑。我不知道如何以面向对象的方式将所有这些工作结合在一起......编写明显符合模式的东西很容易，但当你发生大量事情时，所有事情都与一个游戏循环相关，相互修改和游戏数据等等......我甚至都不知道。也许我只是把它变成了一个比实际更大的交易。

Oh, I'm just all confused. I don't know how to make all this work together in an object-oriented fashion... It's easy enough writing things that clearly fit the patterns, but when you have tons of things happening all tied to one game loop, modifying each other and the game data and so on, ... I don't even know any more. Maybe I'm just making this a bigger deal than it actually is.

还有其他人有这种感觉吗？请提供一些明确的情况，以便我可以花更少的时间担心，不知道从哪里开始！

Has anyone else felt this way? Please offer some clarity to my situation so I can spend less time worrying and not knowing where to start!

-Ricket

编辑：找到一个漂亮的图表，可以帮助我解决这个问题...来源:(小心，PS文件！） http://www.tucs.fi/publications/attachment.php?fname=TR553.ps.gz

Found a nice diagram that might help me figure this all out... Source: (beware, PS file!) http://www.tucs.fi/publications/attachment.php?fname=TR553.ps.gz

http://img10.imageshack.us/img10/6278/mvcdiagramgamesbl5 .png

Edit2：我也很喜欢这个家伙对他如何计划MVC游戏的解释： http://interactivesection.wordpress.com/2007/11/19/dum -de-dum-drum-my-first-mvc-game-development /

I also like this guy's explanation of how he planned his MVC game: http://interactivesection.wordpress.com/2007/11/19/dum-de-dum-drum-my-first-mvc-game-development/

Edit3：另一篇很棒的文章！
http://dewitters.koonsolo.com/gamemvc.html

Another great article! http://dewitters.koonsolo.com/gamemvc.html

推荐答案

它可能会帮助您将模型视为一种游戏API。如果游戏从一开始就没有用户界面，那么你的游戏会被减少到什么程度呢？你提到你的想法是一个RPG，所以在这种情况下，你可以想象拥有玩家角色，他/她的库存，法术，能力，NPC，甚至地图和战斗规则都是模型的一部分。它就像是Monopoly的规则和部分，没有最终游戏如何显示或者用户如何与之交互的具体细节。它就像Quake一样，是一组3D物体，通过一个水平线移动，计算出交叉点和碰撞，但没有渲染，阴影或声音效果。

It might help you to think of the Model as a kind of game API. What would your game be reduced to if there were no UI at all for the game ordained from the beginning? You mention that what you have in mind is an RPG, so in this case you can imagine having the player character, his/her inventory, spells, abilities, NPCs, and even things like the map and combat rules all being part of the model. It is like the rules and pieces of Monopoly without the specifics of how the final game displays that or how the user is going to interact with it. It is like Quake as an abstract set of 3D objects moving through a level with things like intersection and collision calculated but no rendering, shadows, or sound effects.

通过全部放置那些进入模型的游戏本身现在是UI不可知的。它可以连接到像Rogue游戏那样的ASCII文本界面，或者类似于Zork的命令行界面，或者基于Web或3D UI。根据游戏机制的不同，其中一些UI可能非常合适，但它们都是可能的。

By putting all of those into the model the game itself is now UI agnostic. It could be hooked to an ASCII text interface like Rogue games have, or a command line UI akin to Zork, or a web based, or 3D UI. Some of those UIs might be a terrible fit depending upon the game mechanics, but they would all be possible.

View层是UI依赖层。它反映了您使用的UI的具体选择，并将非常专注于该技术。它可能负责读取模型的状态并以3D，ASCII或图像和HTML为网页绘制它。它还负责显示玩家需要用来与游戏交互的任何控制机制。

The View layer is the UI dependent layer. It reflects the specific choice of UI you went with and will be very much dedicated to that technology. It might be responsible for reading the state of the model and drawing it in 3D, ASCII, or images and HTML for a web page. It is also responsible for displaying any control mechanisms the player needs to use to interact with the game.

Controller层是两者之间的粘合剂。它应该永远不会有任何实际的游戏逻辑，也不应该负责驱动View层。相反，它应该将在视图层中执行的操作（单击按钮，单击屏幕区域，操纵杆操作等）转换为对模型执行的操作。例如，丢弃一个项目，攻击一个NPC，等等。它还负责收集数据并进行任何转换或处理，以便View层更容易显示它。

The Controller layer is the glue between the two. It should never have any of the actual game logic in it, nor should it be responsible for driving the View layer. Instead it should translate actions taken in the View layer (clicking on buttons, clicking on areas of the screen, joystick actions, whatever) into actions taken on the model. For example, dropping an item, attacking an NPC, whatever. It is also responsible for gathering up data and doing any conversion or processing to make it easier for the View layer to display it.

现在，我描述它的方式上面就好像有一个非常独特的事件序列驱动游戏，这可能只适合网页游戏。那是因为这是我最近花费的时间。在不受用户请求驱动的游戏和服务器的响应（如用户机器上的游戏）中，您可能希望确保模型层很好地实现了Observer模式。例如，如果由于时间过去而在模型中发生操作，那么您可能不希望View层不断轮询模型以获取更新。相反，通过使用Observer模式，Model可以在模型对象发生变化时通知任何观察者。这可以反过来用于提示立即更新视图以反映更改。

Now, the way I've described it above is as though there is a very distinct event sequence driving the game that is probably only really appropriate for a web game. That's because that's what I've spent my time on lately. In a game which is not driven by a user's request and a server's response like the web (e.g. a game running on the user's machine) you would probably want to make sure that the Model layer implemented the Observer pattern well. For example, if actions take place in the Model because time is passing then you might not want to have the View layer constantly polling the Model for updates. Instead by using the Observer pattern the Model could notify any observers of changes to Model objects as they happen. That could in turn be used to prompt immediate update to the View to reflect the change.

然后，如果60秒的传球导致玩家的基地发生了一些修复，那么基地可能会影响维修并立即通知任何附属的观察员基地已更新。视图可以作为观察者附加，并注意它需要重新显示基础，因为它的状态已经改变。通知本身可能包含足够的信息来更新View，或者它可能需要转身并查阅模型才能更新，但结果将是相同的。

Then if 60 seconds passing resulted in some repairs happening for the player's base, the base could effect the repairs and immediately notify any Observers attached to it that the base has updated. The View could be attached as an Observer and note that it needs to re-display the base because its state has changed. The notification itself might have included enough information to update the View or it might have to turn around and consult the model in order to update, but the result will be the same.

这篇关于如何组织游戏代码以适应MVC模式？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！