Jump to content
  • Advertisement
Sign in to follow this  
Arjan B

Separating graphics, input, game logic etc.

This topic is 3842 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I'm kind of confused about how I should separate handling graphics, input, game logic etc. How separated should they be? Is it better to give objects that need to be drawn a reference to the graphics class as a member and a member function like Render()?
class Paddle {
  public:
    void Render() { m_refGraphics.Draw(m_sprPaddle); }
  private:
    Graphics m_refGraphics;
    Sprite   m_sprPaddle;
};



Or should I give the graphics class a member function to draw the object?
class Drawable {
  protected:
    m_sprite;
};

class Paddle : public Drawable {
};

class Graphics {
  public:
    void Draw(const Drawable&);
};



And how should I separate input from game logic? Should I have a HandleInput() function which reads input and stores it in an array that can be used by a GameLogic() function? These were some of the questions I had in mind but the whole way of keeping things separated is kind of vague to me. Maybe somebody could point me to some nice guidelines to follow or a link to a good article about this? Thank you in advance ^^.

Share this post


Link to post
Share on other sites
Advertisement
I would choose the second version. Because it does not make sence, that the paddle even knows that it can be rendered. Look at the MVC (model view controller) principle. The paddle is in the model. The graphics is in the view. The view draws what is in the model. So the graphics draw the paddle.

Share this post


Link to post
Share on other sites
Neither. Paddle is a game concept which should be independent of its representation. A game should be able to be run without drawing anything to the screen (though it might be hard to play if you can't see where the ball is).

Share this post


Link to post
Share on other sites
Quote:
Original post by Telastyn
Neither. Paddle is a game concept which should be independent of its representation. A game should be able to be run without drawing anything to the screen (though it might be hard to play if you can't see where the ball is).
Agreed, however, this is often easier said than done (cleanly, at least). I am working on a similar problem currently.
Definitely worth it it the end though, since you now have the flexibility of generating different "views" of the game: screen, network, AI, replay file, whatever.

Share this post


Link to post
Share on other sites
Quote:
Original post by Telastyn
Neither. Paddle is a game concept which should be independent of its representation. A game should be able to be run without drawing anything to the screen (though it might be hard to play if you can't see where the ball is).


But if I plan to make a game where you can see the paddle, how should I draw it?

Share this post


Link to post
Share on other sites
Something like this would work:

Game Objects -> Event/Messaging System -> Event/Message Listeners (eg: renderer)

Your renderer could be listening to update events for certain game objects and then render them. Your AI could also be listening for such events and reach to them. Network code could use the events to send data accross the network. And so on.

The difficult part now is designing your event system .

Share this post


Link to post
Share on other sites
But which part should know about which sprite to draw? The game object, the event system or the event listener?

Share this post


Link to post
Share on other sites
The game object would generate an event, the event would contain some data/parameters with details about the event (to describe the event, the sprite id could be part of this) and then the listeners would use the description of the event to handle it in some way.

There are, of course, many ways your original problem could be solved, this is only one way.

Share this post


Link to post
Share on other sites
My current approach is having a rendering system that's responsible for loading, drawing and managing images. Any game object that needs a visual representation receives a reference to this renderer object, so it can request the rendering system to create a sprite object (one, or multiple, or whatever) at a specified location, with a specified image. The rendering system then returns a handle to that sprite object, so the game object can manipulate their sprite: move it around, toggle it's visibility, select a different animation, remove it, whatever actions make sense. The renderer is responsible for drawing it, though. Since drawing happens in a single place, it's much easier to add optimizations there.

In other words, game objects tell the rendering system what to draw and where to do it, and they'll update that information from time to time. The rendering system is unaware of what and why it draws things, and game objects aren't cluttered with drawing functionality.


It may not be a perfect solution, but it works well for me so far. :)

Share this post


Link to post
Share on other sites
Quote:
Original post by Arjan B
But which part should know about which sprite to draw? The game object, the event system or the event listener?


The listener, sort of.

The game object is the paddle. It exists at X/Y on the playfield, is XxY dimensions, has X properties, is controlled by X player; it will contain a series of events (size changed, location changed).

When created, a sprite is also created that looks like a paddle and added to the scene. The events are then tied between the paddle and the sprite by the Game (which does the creation and knows about the game rules and the presentation). Paddle change location causes sprite change location (proportional based on the differences between the playfield game object and the visual area that is the playfield).

[note that a similar tying mechanism is used to make (arrow-up) move the game object paddle and other input]

At that point you're free to swap out the paddle or the sprite implementation without the other knowing about either.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!