Separating game logic and rendering

Question

I know this has been asked before but I would like some things cleared up.

I understand that game logic and rendering should be separated but my problem is more or less how? For instance, should the renderer get ALL info from the sprite/object and use that to draw? Also should the renderer be a seperate class or member function. If it's a separate class should it be able to get the necessary info via public functions or should it be a friend of the class to draw it?

Also some clarification as to what the main object should contain, e.g, is it okay for the main class to have other sprites, shapes, fonts, and effect data? Or, should the renderer somehow contain or produce that data?

I'm asking this because I'm making a menu list class in SFML. And, although it technically works, I'm confused because it's implemented in a way that is considered by many to be bad. Thus, I would like to know as to how to implement it and fix it correctly because I have currently blended both the logic and rendering together.

class MenuList {
    private:
        bool m_visibility{ true };
        std::vector<std::pair<MenuItem, sf::Text>> m_items;
        sf::RenderWindow& m_window;
        SEL::EventManager& m_manager;
        sf::Font m_font;

        sf::RectangleShape m_highlighter;
        sf::Color m_highlightColor;

        sf::RectangleShape m_box;

        size_t m_size{ 0 };
        size_t m_rowSpacing;

        static const uint16_t indent;
    public:
        MenuList(sf::RenderWindow& window, SEL::EventManager& manager);
        ~MenuList();
        // get a certain option, no range checking
        MenuItem& operator[](size_t index);

        // get a certain option, with range checking
        // will report an error to the console if range is out of bounds
        MenuItem& getOption(size_t index);

        // update the menu
        void Update();

        // set the visibility of the menu
        void setVisibility(bool value);

        // get the visibility of the menu
        bool getVisibility() const;

        // add another option
        void addOption(const MenuItem& item);

        // add multiple options via a list { }
        void addOption(std::initializer_list<MenuItem> items);

        // remove an options index
        void removeOption(size_t index);

        // remove an option by name
        void removeOption(const sf::String& name);

        // resize the amount of submenus
        void resize(size_t size);

        // get the local position of the menubox
        sf::FloatRect getLocalBounds();

        // set the amount of spacing between each menu in pixels
        void setRowSpacing(size_t rowSpacing);

        // get the amount of spacing is in between each menu in pixels
        size_t getRowSpacing() const;

        //void addSeperator(size_t index, sf::PrimitiveType Type = sf::PrimitiveType::LinesStrip);

        // get the amount of sub menus
        size_t getMenuCount() const noexcept;

        // get the position of the menu, the top left
        const sf::Vector2f& getPosition() const noexcept;

        // move the menu to a completely new position, overides the previous position
        void setPosition(float x, float y);

        // move the menu to a completely new position, overides the previous position
        void setPosition(const sf::Vector2f& pos);

        void setOutlineThickness(size_t thickness);

        size_t getOutlineThickness() const;

        // reset the menu such as the size, menus, and box
        void reset();
    };

Answer 1

The idea is simple. You need to have a way to define an object on the screen. It should contain the information for the rendering (like textures, effects, etc.) and for the game logic (velocity, acceleration, etc.). The main game logic shouldn't touch the rendering parts and vice-versa. There are variables, which needs to be used by both systems (like the position of the object).

Your main class should not contain anything. Each part of the game should be isolated from each other. Sometimes a messaging system is used to let these parts communicate with each other.

In the updater method you should update the game logic variables. Move the character, do the path finding, etc. In the rendering method you need to use the textures and effects to render the character on the screen.

Answer 2

EDIT: @Bálint made a great point about my answer. This works best for 2D rendering frameworks (SDL, XNA, etc) and less so with working directly with things like DirectX/OpenGL, which require a much closer coupling of the WHAT, WHERE, and HOW that I list below.

Here is the paradigm I follow with how I organize my classes and what responsibilities each has:

• Renderer class
  • Static class that can be called by anyone
  • Has Render() method that given a texture and a set of parameters, will render the texture (X & Y coordinates, rotation, etc)
• Texture classes
  • WHAT you want to render (EX: The actual image data for a tree)
  • Has Render() method that will render the texture given a set of parameters (X & Y coordinates, rotation, etc)
• Sprite classes
  • Contains the Texture you wish to render for the Sprite
  • WHERE and HOW you want to render that texture (EX: The X & Y locations, rotation, etc)
  • Has Update() method to update the sprite's WHERE and HOW
  • Has Render() method to render the texture using the WHERE and HOW stored in the sprite

Here's an example of what your typical frame would look like:

• Sprite->Update()

  .. .. ..

• Sprite->Render()

  • Texture->Render(this->x, this->y, this->rotation)
    • Renderer->Render(this->texture, x, y, rotation)

Although some might view this as over complication, it helps separate out the logic and responsibilities of each class:

• Renderer knows how to render things given to it
• Texture knows how to render itself given location parameters
• Sprite knows how to update its state and how to render its texture using its state