游戏架构 [英] Game Architecture

问题描述

我有一个关于XNA游戏我做的问题，但它也为未来的游戏的通用问题。我正在做的乒乓球比赛，我不知道到底是什么更新的地方，所以我会更好地解释我的意思。我有一个类游戏，球拍和球，例如，我想验证与屏幕限制或桨球之间碰撞，但我碰到过2的方法来做到这一点：

I have a question about a XNA game I'm making, but it is also a generic question for future games. I'm making a Pong game and I don't know exactly what to update where, so I'll explain better what I mean. I have a class Game, Paddle and Ball and, for example, I want to verify the collisions between the ball with the screen limits or the paddles, but I come across 2 approaches to do this:

更高层次的方法 - 使桨和球性和公众对Game.Update检查碰撞

Higher Level Approach - Make paddle and ball properties public and on the Game.Update check for collisions?

下一级的办法 - 我每次提供的信息，我需要（屏幕限制和桨叶信息），以球类（由参数，或者在通用公共静态类），并在Ball.Update我检查的碰撞？

Lower Level Approach- I supply every info I need (the screen limits and paddles info) to the ball class (by parameter, or in a Common public static class) and on the Ball.Update I check for collisions?

我想我在一个更通用的方法的问题是：

I guess my question in a more generic way is:

有没有对象需要知道如何更新和绘制自己，甚至具有某种方式提供给他们更高层次的依赖？

Does an object need to know how to update and draw itself, even having dependencies from higher levels that somehow are supplied to them?

或

最好在Game.Update或Game.Draw更高级别来处理它，或者使用管理，以简化code？

Is better to process it at higher levels in Game.Update or Game.Draw or using Managers to simplify code?

我觉得这是适用于每一个游戏的游戏逻辑模型的问题。我不知道如果我做了我的问题清楚，如果没有，随意问。

I think this is a game logic model question that applies to every game. I don't know if I made my question clear, if not, feel free to ask.

推荐答案

回答你的问题的困难之处是，你问的这两个：我现在应该怎么办，对傍和我应该怎么做之后，对一些通用的游戏。

The difficult part of answering your question is that you're asking both: "what should I do now, for Pong" and "what should I do later, on some generic game".

为了让你傍甚至不需要球和桨类，因为他们基本上只是位置。只要坚持这样的事情在你的游戏类：

To make Pong you don't even need Ball and Paddle classes, because they're basically just positions. Just stick something like this in your Game class:

Vector2 ballPosition, ballVelocity;
float leftPaddlePosition, rightPaddlePosition;

然后，只需更新和一切为了适合在游戏中的更新和绘图功能吸引他们你。很简单！

Then just update and draw them in whatever order suits you in your Game's Update and Draw functions. Easy!

不过，说你要创建多个球，和球有很多属性（位置，速度，旋转，颜色等）：你可能希望在球类或结构，你可以实例（同样适用于拨片）。你甚至可以将一些功能整合到这个类，他们是独立的（A 绘图函数是一个很好的例子）。

But, say you want to create multiple balls, and balls have many properties (position, velocity, rotation, colour, etc): You might want to make a Ball class or struct that you can instance (same goes for the paddles). You could even move some functions into that class where they are self-contained (a Draw function is a good example).

但保持设计理念是相同的 - 所有的对象到对象交互处理的（即：游戏）。发生在你的游戏类

But keep the design concept the same - all of the object-to-object interaction handling (ie: the gameplay) happens in your Game class.

这是一切就好了，如果你有两个或三个不同的游戏元素（或类）。

This is all just fine if you have two or three different gameplay elements (or classes).

但是让我们假设一个更复杂的游戏。让我们以基本乒乓球比赛，增加一些弹球元素，如辑阵球和玩家控制的鳍状肢。让我们添加从蛇的一些元素，比如我们有一个AI控制的蛇，以及，无论是球或蛇可以打一些皮卡对象。而良好的措施让我们说桨还可以拍摄激光器像太空侵略者和激光螺栓做取决于他们打什么不同的东西。

However let's postulate a more complicated game. Let's take the basic pong game, add some pinball elements like mutli-ball and player-controlled flippers. Let's add some elements from Snake, say we have an AI-controlled "snake" as well as some pickup objects that either the balls or the snake can hit. And for good measure let's say the paddles can also shoot lasers like in Space Invaders and the laser bolts do different things depending on what they hit.

的天哪的是相互作用的巨大的混乱！我们该如​​何应对呢？我们不能把它所有的游戏！

Golly that is a huge mess of interaction! How are we going to cope with it? We can't put it all in Game!

简单！我们做一个接口（或抽象类或虚拟类），在我们的游戏世界每一个东西（或演员），将从中获得。下面是一个例子：

Simple! We make an interface (or an abstract class or a virtual class) that each "thing" (or "actor") in our game world will derive from. Here is an example:

interface IActor
{
    void LoadContent(ContentManager content);
    void UnloadContent();

    void Think(float seconds);
    void UpdatePhysics(float seconds);

    void Draw(SpriteBatch spriteBatch);

    void Touched(IActor by);

    Vector2 Position { get; }
    Rectangle BoundingBox { get; }
}

（这只是一个例子。没有的一真演员接口的，会为每场比赛的工作，你需要设计自己的。这就是为什么我不喜欢 DrawableGameComponent ）

(This is only an example. There is not "one true actor interface" that will work for every game, you will need to design your own. This is why I don't like DrawableGameComponent.)

有一个通用的接口让游戏只是说说演员 - 而不需要知道关于你的游戏的每一个类型。它只是剩下要做的通用型的东西 - 碰撞检测，绘制，更新，装卸等

Having a common interface allows Game to just talk about Actors - instead of needing to know about every single type in your game. It is just left to do the things common to every type - collision detection, drawing, updating, loading, unloading, etc.

一旦你的在的演员，你就可以开始担心特定类型的演员。例如，这可能是一种方法桨：

Once you're in the actor, you can start worrying about specific types of actor. For example, this might be a method in Paddle:

void Touched(IActor by)
{
    if(by is Ball)
         ((Ball)by).BounceOff(this.BoundingBox);
    if(by is Snake)
         ((Snake)by).Kill();
}

现在，我喜欢让球弹了桨，但它确实是一个品味问题。你可以做它周围的其他方法。

Now, I like to make the Ball bounced by the Paddle, but it is really a matter of taste. You could do it the other way around.

你到底应该能够坚守在一个大名单，你可以简单地通过游戏遍历所有的演员。

在实践中，你可能最终具有不同类型的演员性能或code简单起见的多个列表。这是正常 - 但一般尽量坚持到比赛的唯一原则，明知有关通用演员

In practice you might end up having multiple lists of actors of different types for performance or code simplicity reasons. This is ok - but in general try to stick to the principle of Game only knowing about generic actors.

演员可能还需要查询各种原因存在哪些其他演员。所以给每个演员到游戏的引用，使演员公众对游戏列表（没有必要是超级严格的关于公共/私有当你写的游戏code和它自己的内部code 。）

Actors also may want to query what other actors exist for various reasons. So give each actor a reference to Game, and make the list of actors public on Game (there's no need to be super-strict about public/private when you're writing gameplay code and it's your own internal code.)

现在，你甚至可以更进一步，并有多个接口。例如：一个用于渲染，一个用于脚本和AI，一个用于物理等，然后有一个可以组合成对象的多种实现

Now, you could even go a step further and have multiple interfaces. For example: one for rendering, one for scripting and AI, one for physics, etc. Then have multiple implementations that can be composed into objects.

这是中详细描述这篇文章。而且我得到了在一个简单的例子，这个答案。这是一个合适的下一个步骤，如果你开始发现你的单身男演员接口开始变成一个更抽象类的树。

This is described in detail in this article. And I've got a simple example in this answer. This is an appropriate next step if you start finding that your single actor interface is starting to turn into more of a "tree" of abstract classes.

这篇关于游戏架构的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！