Чи повинні актори в грі нести відповідальність за малювання себе?

Я дуже новачок у розробці ігор, але не в програмуванні.

Я (знову) граю з грою типу Pong, використовуючи canvasелемент JavaScript .

Я створив Paddleоб'єкт, який має такі властивості ...

• width
• height
• x
• y
• colour

У мене також є Pongоб'єкт, який має такі властивості, як ...

• width
• height
• backgroundColour
• draw().

В draw()даний час метод скидає canvasі саме тут виникло питання.

У разі , якщо Paddleоб'єкт є draw()метод відповідає за його креслення, або якщо draw()на Pongоб'єкті буде відповідати за розробку своїх акторів (я припускаю , що це правильний термін, будь ласка , поправте мене , якщо я неправильно).

Я подумав, що Paddleмалюнок буде вигідним малювати себе, оскільки я створюю два об'єкти, Playerі Enemy. Якщо б це було не в Pong-х draw(), я повинен був би написати подібний код двічі.

Яка тут найкраща практика?

Дякую.

Наявність акторів малювати себе не є гарним дизайном з двох основних причин:

1) він порушує принцип єдиної відповідальності , тому що ці актори, мабуть, мали іншу роботу, перш ніж ви внесли в них код візуалізації.

2) утруднює розширення; якщо кожен тип актора реалізує власний малюнок, і вам потрібно змінити спосіб малювання в цілому , можливо, вам доведеться змінити багато коду. Уникнення надмірного використання спадщини може певною мірою полегшити це, але не повністю.

Краще для вашого рендерінга обробляти креслення. Зрештою, саме це означає бути рендером. Метод малювання рендерінга повинен мати об'єкт "опис візуалізації", який містить все необхідне для рендерування речі. Посилання на (ймовірно, загальні) дані геометрії, конкретні екземпляри перетворень або властивості матеріалу, такі як колір та ін. Потім це малює, і не байдуже, яким повинен бути цей опис візуалізації.

Потім ваші актори можуть дотримуватися опису візуалізації, який вони створюють самі. Оскільки суб'єкти типово логічні типи обробки, вони можуть підштовхувати зміни стану до опису візуалізації за необхідності - наприклад, коли актор отримує шкоду, він може встановити колір опису візуалізації червоним, щоб вказати на це.

Тоді ви можете просто повторити кожного видимого актора, включити їх описи візуалізації в рендерінг, і дозволити це зробити своє (в основному, ви могли б ще більше узагальнити це).

Тут може бути корисною шаблон відвідувачів .

Ви можете зробити інтерфейс Renderer, який знає, як намалювати кожен об'єкт, і метод "намалювати себе" в кожному акторі, який визначає, який (конкретний) метод рендерінга викликати, наприклад

interface Renderer {
    void drawPaddle(Player owner, Rectangle position);
    // Note: the Renderer chooses the Color based on which player the paddle belongs to

    // Also drawBackground, drawBall etc.
}

interface Actor {
    void draw(Renderer renderer);
}

class Paddle implements Actor {
    void draw(Renderer renderer) {
        renderer.drawPaddle(this.owner, this.getBounds());
    }
}

Таким чином, досі легко перенести порт до іншої графічної бібліотеки чи фреймворку (я одного разу переніс гру з Swing / Java2D на LWJGL, і був дуже радий, що використав цю схему замість того, щоб проходити Graphics2Dнавколо.)

Є ще одна перевага: рендерінг може бути протестований окремо від будь-якого коду актора

У вашому прикладі ви хочете, щоб об'єкти Pong реалізували draw () та надавали себе.

Хоча ви не помітите жодних значних вигод у проекті такого розміру, загалом розділення логіки гри та їх візуального представлення (візуалізація) є гідною діяльністю.

Під цим я маю на увазі, що у вас є ігрові об'єкти, які можна оновити (), але вони не мають уявлення про те, як вони надаються, вони стосуються лише моделювання.

Тоді у вас буде клас PongRenderer (), який має посилання на об'єкт Pong, і він потім бере на себе візуалізацію класу Pong (), це може включати рендеринг Paddles або наявність класу PaddleRenderer, щоб піклуватися про нього.

Розділення проблем у цьому випадку є цілком природним, що означає, що ваші класи можуть бути менш роздутими, і простіше модифікувати спосіб рендерингу, більше не потрібно дотримуватися ієрархію, яку робить ваше моделювання.

Якщо вам потрібно було це зробити в Pong'draw (), вам не потрібно буде дублювати код - просто зателефонуйте на функцію Paddle' draw () для кожного з ваших весла. Тож у вашому Pongмалюнку () ви мали б

humanPaddle.draw();
compPaddle.draw();

Кожен об’єкт повинен містити власну функцію малювання, яку слід викликати кодом оновлення гри або кодом жеребкування. Подібно до

class X
{
  public void Draw( )
  {
     // Do something 
  } 
}

class Y
{
  public void Draw( )
   { // Do Something 
   } 
}

class Game
{
  X objX;
  Y objY;

  @Override
  public void OnDraw( )
  {
      objX.Draw( );
      objY.Draw( ); 
  } 
}

Це не код, а лише показ, як потрібно робити об’єкти малювання.