I just came across an article with an extensive tutorial regarding LibGDX’s Actor class and its related classes and I was wondering if it’s something that most LibGDX game developers utilize in their games.
When do you use Actors; and, is using Actors in your game beneficial more often than not?
In my game, I’ve not been using any Actors… and I’ve been wondering if I should.
Thanks!
Actors are a scene2d thing, representing an object in the scenegraph. If you use scene2d, you’re using scene2d.Actor. Now Actors in general are cool, the sort you get from the likes of Akka or Kilim, but they don’t have a ton in common with scene2d actors unless you squint and tilt your head at it.
It’d be kinda neat to see an Actor system built off that lightweight thread library that’s been making the rounds here… any takers?
This scene2d thing is tickling my fancy now… 
…the way I’m doing things is creating my own classes/objects from Textures, Sprites, Bodies, Fixtures and manipulating everything manually (e.g. - position, rotation, collision etc.) — using scene2d and Actors sounds like I might have an easier time?
On the other hand, I’m a bit wary of using higher-level functionalities since I have this impression of losing flexibility in my coding/implementation when doing so…
You don’t lose much flexibility while using Actors, because you can just extend Actor/Image/Widht and make your own class. It does make your code a lot more clean and readable though.
Now I am tempted to refactor my code to use Actors
[spoiler]Am I using “refactor” correctly? hehehe.[/spoiler]
Since my first libgdx project, all of my entites were extending Image (Actor) class. But I found out combination of Image + EventListener is kinda break on HTML5 port so I go down a bit and extends Actor directly instead.
sVMhuiHm50I
You guys wanna use scene two deeeeeeee? Wanna use scene two deeeeeeee?
(disclaimer: I wrote scene2d 8)) I recently took a little break from Spine to start prototyping a game. I built it first in scene2d, then rebuilt it without. I have to say I prefer the codebase without scene2d for this particular game, which is an action type game (bunch of images fly around, you kill things, etc). For other games, eg board games, it may be a better fit. I felt that my code was getting messy as the prototype grew more complex. When I rewrote it I separate the model and view. In the model I have the player and a bunch of enemies, gravity, etc. These objects are all just POJOs and knows how to update based on delta time, hit detection, etc. Separate from all that I have the view, which uses the model objects to determine where the camera is, draw everything, and handle input events.
The tricky part when doing model-view separation is that often you need some view information for each object. Where does this get stored? If you keep the separation pure, you can’t put view stuff in the model. In this case you have to do some sort of look up the view object for each model object. I think it is better to break the separation by allowing the model object to have a single field that is for the view. This way the view easily has a reference to the data it needs for drawing and it doesn’t mess up your organization too much. If you want a little enforcement so you don’t accidentally make use of this view object in the model, you can make it of type Object.
One difference is it will be easier to snapshot the game’s state (if this is actually needed) when it is described using just POJOs. In this case you can make the view objects you have in your model transient, as long as the view can restore them solely from model information. This is very likely, but in some cases maybe you have view only state that you want to persist. Then you could actually serialize the view object, not all of it but enough to restore it later. Of course if you aren’t serializing game state none of this matters when choosing whether to use scene2d.
The rest isn’t really a big difference when using scene2d, just the model and view get mixed together. This is fine, just less organized. If scene2d is making your life easier, by all means, use it. See the overview for what it does at the most basic level. I have a feeling board games, something like Mahjong, would benefit from scene2d because they are pretty UI intensive. You also get more benefit from scene2d if using rotated or scaled groups of actors.
Note that nothing beats scene2d if you are building a UI, so definitely use it in that case. You can use it for menus, configuration dialogs, a HUD UI overlay on top of your game, etc. When using scene2d for your UI, the rest of your game can be built with or without scene2d.
[quote]Note that nothing beats scene2d if …
[/quote]
A CHALLENGE!
Building a UI toolkit is a huge PITA. Best of luck! 
No, thanks Nate. I am already happy with scene2d*
*) with some exceptions 
I’ll pass. But it would be nice to have a very lightweight actor framework that (at least optionally) is inherently single threaded.
Just want to note to readers, that Akka and Kilim have actually nothing in common with scene2d.Actor…
But sporingie is totally right, he just didn’t say it that explicit.
What I do is: I have a generic type of viewing an entity: It’s animated somehow, has some kinds of controlling types of the images (i.e. animations) and therefore (the view) needs to know more than only position, rotation and stuff. It needs to know whether the user currently presses a button to make the view animate a walking player.
I’ve solved the problem by simply allowing the view to have the controllers state-information. So the controller (which is responsible for processing key input) holds information about the player, i.e. whether the player moves, or not.
I finally completely seperate my POJO’s (model) with my view: I have .json’s telling about how my player works (which controller to use), how it should be drawn (view) and how it looks like (actually model, my sprites, but not saved into my POJO later on). When I load the entity I automatically already create the controller, which is completely decoupled from the view, but coupled to the model, create the model, which is decoupled from everything, and create the view, which is coupled to the model and the controller.
In my case I needed the mvc pattern (the decoupling of the view from the rest, i.e. my code works without view) for writing my networking code, so basically, yes, that’s taking a snapshot of my game state and sending it over to the client ;D just wanted to add that…
And just wanted to share my variation of the MVC pattern in games. I hope you like it.
About Actors actually (god, I’m derailing so badly): I think they’re a really cool Idea, but I just didn’t have the Idea to use them when I should have…
This sounds a bit strange. I think the controller shouldn’t have state. You can store this information in the model, and really it seems that is where it belongs. I store an enum that is what state the unit (player/enemy/etc) is in and the “state time” which is how long it has been in that state. That is enough for animation, eg if the unit is in the “walk” state then show the walk animation (looped) at the state time.
I don’t try to stick to strict MVC, as it generally is overkill. It’s easiest to not try to separate the view and controller. When a button is pressed, the model is updated to change the state, eg from idle to walking, and the view shows the right animation just by looking at the model.