Stage / Actors model and Logic / rendering separation

Anything about development not directly related to libgdx, e.g. OpenGL, Android APIs etc.

Stage / Actors model and Logic / rendering separation

Postby bigstones » Sun Oct 23, 2011 7:01 pm

Hello,

I'm trying to learn some game design notions while experimenting with my first game. I'm using Libgdx.

While creating the architecture I ended up with a simple flat (no tree) stage and actors design. I read about some separation concerns but I said "next time", limiting to separate unit measures.

The rendering method in my actors is:
Code: Select all
public void render(SpriteBatch sb) {
   // draws nothing, I'm still using Box2DDebugRenderer
}


Then I added input and contact dispatchers, so that I can set listeners in the actors and be happy. It's really clean, but just having them logging the events increased quite a bit the logic time in the loop when bouncing, and I'm already scared of consuming precious milliseconds. Consider that, so far, I have a circle bouncing in a rectangle. So I stopped to think again about the design.

What are the alternatives to actors / stage model? I can figure that less structured ones have better performance and lower mantainability, but which are they?

Another concern of mine is about logic / rendering separation. I've read many pages about this and I understand it's supposed to allow efficiency by managing the order of drawings, it's easier to port the game to another platform (logic remains the same) but your renderer must know how to draw all your actors/bodies/anything.

Since I probably will not port my lame game, I haven't even decided what the actors will be (that is, I'd like to have them well organized to change gameplay when I like), and anyway SpriteBatch optimizes rendering for me... would it be ok for me now to have rendering in actors? or are there other considerations to make?

Thank you!
(ps: I really like this community and the lib!)
bigstones
 
Posts: 5
Joined: Sun Oct 23, 2011 5:40 pm

Re: Stage / Actors model and Logic / rendering separation

Postby NateS » Sun Oct 23, 2011 9:00 pm

Scene graphs force you to couple model and view. Look at MVC for a clean separation. Completely separate model means that your view can be ASCII, libgdx, or any other graphics layer without affecting your game logic.

You say logging slows you down? How are you logging? Gdx.app.log? Why are you logging?

I don't get what you mean by, can you render in actors? Of course, otherwise what is the point of having actors? :)
NateS
 
Posts: 1980
Joined: Fri Nov 12, 2010 11:08 am

Re: Stage / Actors model and Logic / rendering separation

Postby bigstones » Sun Oct 23, 2011 10:00 pm

Well even actors could have separated rendering. I've seen on this forum (don't ask me where exactly) someone suggesting something like:
Code: Select all
class SomeActor {
   //...
   public render() {
      renderer.renderSomeActor(x, y, speed, direction, state /* ... */);
   }
}


Anyway, if I don't use actors, what models are available?

About logging: I am measuring the time of a Box2D step() (not fixed). The world consists of a ChainShape (a rectangle) and a Circle bouncing in it. I set my ContactDispatcher as world's contact listener, so that it dispatches contacts to the two actors in the contact, and they log each event with Gdx.app.log. It's nothing hard I think, here it is (Entity is my actor):

Code: Select all
public class ContactDispatcher implements ContactListener {

   public enum ContactType {
      BEGIN, PRESOLVE, POSTSOLVE, END;
   }
   
   @Override
   public void beginContact(Contact contact) {
      handOver(contact, null, null, ContactType.BEGIN);
   }

   @Override
   public void endContact(Contact contact) {
      handOver(contact, null, null, ContactType.END);
   }

   @Override
   public void postSolve(Contact contact, ContactImpulse impulse) {
      handOver(contact, null, impulse, ContactType.POSTSOLVE);
   }

   @Override
   public void preSolve(Contact contact, Manifold oldManifold) {
      handOver(contact, oldManifold, null, ContactType.PRESOLVE);
   }
   
   private void handOver(Contact c, Manifold m, ContactImpulse i, ContactType t) {
      ((Entity)c.getFixtureA().getBody().getUserData()).handleContact(c, m, i, t);
      ((Entity)c.getFixtureB().getBody().getUserData()).handleContact(c, m, i, t);
      // is this heavier than I might think?
   }
   
   /* Entity.handleContact() takes the event and reroutes it to the right method
     of the contact listener registered for the Entity, which will log the event. */
}


This way, on my LG Optimus One, I get about 0.4-0.6ms when the ball travels, and when it bounces I can pass 20ms.

If I disable the ContactDispatcher and hence logging, I get to a maximum of 3-4ms.

Take into account that I'm not an experienced programmer :)
bigstones
 
Posts: 5
Joined: Sun Oct 23, 2011 5:40 pm

Re: Stage / Actors model and Logic / rendering separation

Postby bigstones » Mon Oct 24, 2011 9:20 am

bigstones wrote:This way, on my LG Optimus One, I get about 0.4-0.6ms when the ball travels, and when it bounces I can pass 20ms.

If I disable the ContactDispatcher and hence logging, I get to a maximum of 3-4ms.


For the sake of completeness I also tried just commenting out the Gdx.app.log lines, and the maximum settles at something less than 5ms. And for the sake of completeness I specify that I was printing a log line for each of the 4 contact events, for both the actors (bounding rectangle and bouncing circle) (so 8 logs each contact).
bigstones
 
Posts: 5
Joined: Sun Oct 23, 2011 5:40 pm

Re: Stage / Actors model and Logic / rendering separation

Postby bach » Mon Oct 24, 2011 11:06 am

There are a lot of games that don't separate render logic from game logic. There's nothing inherently wrong with that approach.. However a lot of people consider the separation to be a nice design decision (myself included).

In my opinion don't try and mix a renderer approach with stage. That just sounds nasty.

If you want to keep game logic separate, create your own game logic objects and fall back on sprites/texture regions for your rendering. But whichever approach you take, you can get what you want..

Just my thoughts :)
Bach
bach
 
Posts: 713
Joined: Mon Mar 07, 2011 1:50 am

Re: Stage / Actors model and Logic / rendering separation

Postby bigstones » Tue Oct 25, 2011 7:58 pm

Thank you bach, I guess I'll go this way.

In the end I didn't even know there's such thing as a "renderer approach". That's the point... where do I find a simple but well organized and up-to-date overview of standard approaches to game design? (For example, I've read something about component based design)

It seems strange to me that I can't find such a basic and important thing.
bigstones
 
Posts: 5
Joined: Sun Oct 23, 2011 5:40 pm

Re: Stage / Actors model and Logic / rendering separation

Postby bach » Wed Oct 26, 2011 6:13 am

Hey,

It's true that these kind of tutorials aren't easy to find.. And most of this stuff is also better learned through experience than reading up :) However, to get you started here are a few links from my reading library:

http://t-machine.org/index.php/2007/09/03/entity-systems-are-the-future-of-mmog-development-part-1/
http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/
http://www.aurelienribon.com/blog/2011/04/logic-vs-render-separation-of-concerns/

Besides this, just read through lots and lots of code and pick up ideas/solutions you like. I guess there's really no right or wrong. Some things work for some stuff other times it just won't be appropriate.

Have fun! :)
Bach
bach
 
Posts: 713
Joined: Mon Mar 07, 2011 1:50 am

Re: Stage / Actors model and Logic / rendering separation

Postby Richard742 » Wed Dec 26, 2018 9:06 am

In your example you'd want to have the Pong objects implement draw() and render themselves.

Though you won't notice any significant gains in a project of this size, generally separating game logic and their visual representation (rendering) is a worthwhile activity.

By this I mean you'd have your game objects that can be update()'d but they have no idea of how they're rendered, they're concerned only with the simulation.

Then you'd have a PongRenderer() class that has a reference to a Pong object, and it then takes charge of rendering the Pong() class, this could involve rendering the Paddles, or having a PaddleRenderer class to take care of it lite blue.

The separation of concerns in this case is a fairly natural one meaning your classes can be less bloated, and it's easier to modify how things are rendered, it no longer has to follow the hierarchy that your simulation does.
Richard742
 
Posts: 1
Joined: Tue Dec 25, 2018 11:56 am


Return to General Development

Who is online

Users browsing this forum: No registered users and 1 guest

cron