When to use actors in libgdx? What are cons and pros?

Question

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?

Vaccinia

I believe a lot of the libGDX examples pre-date the Stage+Actor support, so that may explain why they don't use it. – Pectoral

I got into a big mess using Stage for everything after imagining needing a lot of fixed position content and cells, ie tables. Tearing it down every frame become increasingly necessary and I ran into issues with libgdx pools of these resources becoming exhausted. So thanks for pointing out the benefits of RYO – Ryals

Answer 1

The main pros for Actors are Actions, Hit testing and touch events, and Groups of 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.

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.

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).

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.

Lumbricoid

You can use both Scene2D and box2d, although admittedly some things can get awkward. Generally though, it's perfectly possible and I'm actually doing it. For dynamic objects, you simply derive your actor's position from the physics model. This means of course that Actions are somewhat pointless, since motion only goes from physics to Actor, not vice versa. However, you still get input handling, an event system, camera handling and coordinate mapping for free. Actions can still be used for visual elements without a physics body (e.g. equipped items, effect sprites, etc.) – Michelle