java 什么时候在 libgdx 中使用 actor?什么是利弊?
声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow
原文地址: http://stackoverflow.com/questions/10619394/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
When to use actors in libgdx? What are cons and pros?
提问by Lord_JABA
I'm writing simple solar system simulator. This is my first libgdx project. I'm using a Stage and Actors for the main menu and is pretty handy especially touch events handling. But ... looking at the examples i see nobody uses actors in actual game logic. I wander if i should use actor as a parent of planet class or just write my own class tor that. The planets won't be touchable and they will be moved only between the frames so the third parameter of action MoveBy will have to be time between frames. That are the cons. What are the pros for using Actors?
我正在编写简单的太阳系模拟器。这是我的第一个 libgdx 项目。我在主菜单中使用 Stage 和 Actors,非常方便,尤其是触摸事件处理。但是……看看这些例子,我发现没有人在实际游戏逻辑中使用演员。我徘徊是否应该使用 actor 作为行星类的父类,或者只是编写我自己的类。行星是不可触摸的,它们只会在帧之间移动,因此动作 MoveBy 的第三个参数必须是帧之间的时间。这就是缺点。使用 Actor 的优点是什么?
回答by broken-e
The main pros for Actors are Actions, Hit testing and touch events, and Groups of Actors.
Actors 的主要优点是动作、命中测试和触摸事件,以及 Actors 组。
Actions make quick and easy tweening if your game logic needs that.
如果您的游戏逻辑需要,动作可以快速轻松地进行补间。
You can call stage.hit(x, y) at any time to return the first actor that returns true to whatever hit logic you wrote for it (usually checking bounds with x, y, width, height). return this actor or null to keep iterating through the actors' hit methods looking for a hit actor. Null is returned if no actor is hit.
您可以随时调用 stage.hit(x, y) 以返回第一个返回 true 的actor,该actor 会为您为其编写的任何命中逻辑返回 true(通常检查 x、y、width、height 的边界)。返回此actor 或null 以继续遍历actor 的hit 方法以寻找命中actor。如果没有演员被击中,则返回 Null。
Hit is used for the Stage's touch events. The actor's touch methods are passed local coordinates, and the Stage handles overlapping of objects, e.g. if an actor covers another actor such that the other actor shouldn't receive touchDown, return true on the covering actor to stop the calling of touchDown on actors "beneath". This also sets 'focus' on the actor that returns true so that Actor's touchUp will be called.
Hit 用于舞台的触摸事件。演员的触摸方法被传递局部坐标,舞台处理对象的重叠,例如,如果一个演员覆盖另一个演员以至于另一个演员不应该收到 touchDown,则在覆盖演员上返回 true 以停止对演员的 touchDown 调用“下面”。这也会将“焦点”设置为返回 true 的 actor,以便调用 Actor 的 touchUp。
You can group actors together to perform Actions, touch events, etc on the entire Group of Actors as a single unit.
您可以将演员分组在一起,以作为一个单元在整个演员组上执行动作、触摸事件等。
Some Cons: Actors require a stage which limits functionality somewhat. Many coders use other logic to determine game object state, rather than the scene2d Actions (e.g. box2d). If you use Actors for game objects, you will probably want two Stages, one for ui and one for game world. If you don't use them you'll probably be using your own SpriteBatch and Camera anyway though. And keep in mind that Actors only have an abstract Draw method so you will still need to create draw logic anyway. You'll probably keep a TextureRegion or Sprite as a private field for the Actor. If you want to use your own update logic, you can override the act(float delta) method to get the delta time (call super.act(delta) if you use Actions).
一些缺点:Actor 需要一个舞台,这在一定程度上限制了功能。许多编码人员使用其他逻辑来确定游戏对象状态,而不是scene2d Actions(例如box2d)。如果您将 Actor 用于游戏对象,您可能需要两个 Stage,一个用于 ui,另一个用于游戏世界。如果您不使用它们,无论如何您可能会使用您自己的 SpriteBatch 和相机。请记住,Actors 只有一个抽象的 Draw 方法,因此无论如何您仍然需要创建绘制逻辑。您可能会将 TextureRegion 或 Sprite 保留为 Actor 的私有字段。如果你想使用你自己的更新逻辑,你可以覆盖 act(float delta) 方法来获取 delta 时间(如果你使用 Actions 调用 super.act(delta))。
So if you have your own logic and won't use much of what Stage has to offer, save some resources and roll your own application-specific solution. If you can use some of the pros without limiting needed functionality then go for a second Stage for the game logic.
因此,如果您有自己的逻辑并且不会使用 Stage 提供的大部分功能,请节省一些资源并推出您自己的特定于应用程序的解决方案。如果您可以在不限制所需功能的情况下使用某些专业人士,那么请进行游戏逻辑的第二阶段。