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
, but they don't have a ton in common with scene2d actors unless you squint and tilt your head at it.
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.
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.
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.
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.
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
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...