Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (487)
Games in Android Showcase (110)
games submitted by our members
Games in WIP (553)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  LibGDX Actor - to use or not to use; or, *when* to use?  (Read 12445 times)
0 Members and 2 Guests are viewing this topic.
Offline heisenbergman

JGO Coder


Medals: 14


L___ o_ G___ a__ P___


« Posted 2013-05-14 02:23:12 »

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!

Offline sproingie

JGO Kernel


Medals: 202



« Reply #1 - Posted 2013-05-14 02:30:06 »

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?
Offline heisenbergman

JGO Coder


Medals: 14


L___ o_ G___ a__ P___


« Reply #2 - Posted 2013-05-14 03:24:21 »

This scene2d thing is tickling my fancy now... Tongue

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

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Jimmt
« League of Dukes »

JGO Kernel


Medals: 128
Projects: 4
Exp: 3 years



« Reply #3 - Posted 2013-05-14 03:36:16 »

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.
Offline heisenbergman

JGO Coder


Medals: 14


L___ o_ G___ a__ P___


« Reply #4 - Posted 2013-05-14 03:43:43 »

Now I am tempted to refactor my code to use Actors Tongue

Am I using "refactor" correctly? hehehe.

Offline ReBirth
« Reply #5 - Posted 2013-05-14 04:21:39 »

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.

Offline Nate

JGO Kernel


Medals: 145
Projects: 4
Exp: 14 years


Esoteric Software


« Reply #6 - Posted 2013-05-14 12:31:37 »

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.
<a href="http://www.youtube.com/v/sVMhuiHm50I?version=3&amp;hl=en_US&amp;start=" target="_blank">http://www.youtube.com/v/sVMhuiHm50I?version=3&amp;hl=en_US&amp;start=</a>
You guys wanna use scene two deeeeeeee? Wanna use scene two deeeeeeee?

(disclaimer: I wrote scene2d Cool) 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.

Offline ReBirth
« Reply #7 - Posted 2013-05-14 12:49:09 »

Quote
Note that nothing beats scene2d if ...
A CHALLENGE!


Offline Nate

JGO Kernel


Medals: 145
Projects: 4
Exp: 14 years


Esoteric Software


« Reply #8 - Posted 2013-05-14 13:02:56 »

Building a UI toolkit is a huge PITA. Best of luck! Smiley

Offline ReBirth
« Reply #9 - Posted 2013-05-14 13:05:51 »

No, thanks Nate. I am already happy with scene2d* Smiley

*) with some exceptions Wink

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Roquen
« Reply #10 - Posted 2013-05-15 15:40:48 »

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?
I'll pass.  But it would be nice to have a very lightweight actor framework that (at least optionally) is inherently single threaded.
Offline matheus23

JGO Kernel


Medals: 106
Projects: 3


You think about my Avatar right now!


« Reply #11 - Posted 2013-05-15 19:10:21 »

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.

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

See my:
    My development Blog:     | Or look at my RPG | Or simply my coding
http://matheusdev.tumblr.comRuins of Revenge  |      On Github
Offline Nate

JGO Kernel


Medals: 145
Projects: 4
Exp: 14 years


Esoteric Software


« Reply #12 - Posted 2013-05-15 19:25:23 »

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.

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.

Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

CopyableCougar4 (24 views)
2014-08-22 19:31:30

atombrot (34 views)
2014-08-19 09:29:53

Tekkerue (30 views)
2014-08-16 06:45:27

Tekkerue (28 views)
2014-08-16 06:22:17

Tekkerue (18 views)
2014-08-16 06:20:21

Tekkerue (27 views)
2014-08-16 06:12:11

Rayexar (65 views)
2014-08-11 02:49:23

BurntPizza (41 views)
2014-08-09 21:09:32

BurntPizza (33 views)
2014-08-08 02:01:56

Norakomi (42 views)
2014-08-06 19:49:38
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!