Это шаблон дизайна? Если да, то как его зовут?

Question

В настоящее время я разрабатываю RPG с поворотным (похожий на мошенник) на C++, и я создал аккуратную архитектуру в своем коде, которая похожа на какой-то шаблон дизайна, потому что я помню, что видел код, подобный этому, в некоторых других проектах. Я хочу знать, если это какой-то шаблон дизайна, на который я наткнулся, и если да, то как его зовут. Я намеренно применил некоторые шаблоны, такие как Factory и Singleton, в других частях программы, но следующее является грубым описанием другой части программы, которую я не знаю, если это шаблон или нет:

У меня есть базовый класс GameElement, который является корнем каждого объекта, который может появляться в игровом поле. Этот класс реализует базовое и сложное поведение при перемещении, обнаружении коллизий и т. Д., Что все подклассы наследуют, потому что это обычное поведение, независимо от типа элемента. Кроме того, он имеет 2 виртуальных метода, которые по умолчанию ничего не делают, но могут быть переопределены подклассами: handleCollision (GameElement * e) и handleTurn(). Метод handleCollision может быть переопределен, чтобы объекты знали, что делать, когда они сталкиваются с другим объектом (особенно с игроком), и метод handleTurn существует, чтобы объекты имели возможность делать все, что захотят, когда это это их очередь. До сих пор я создал несколько подклассов, а именно SolidElement, PushableElement, FighterElement (для игрока и врагов), PlayerElement (игрок), который наследует FighterElement и EnemyElement (корень всех зло), которое также наследует FighterElement.

Там же класс называется GameEngine, который инкапсулирует цикл игры (который также имеет цикл событий SDL) в методе запуска(). Это (довольно короткий) реализация этого метода:

void GameEngine::run() 
{ 
    SDL_Event evt; 

    while (running) { 
     handlePlayerCollisions(); 
     handleTurns(); 
     updateScreen(); 
     delay(); 

     SDL_PollEvent(&evt); 

     if (evt.type == SDL_KEYDOWN) 
      handleKeyInput(evt.key.keysym.sym); 
      continue; 
    } 
} 

В цикле игры, он вызывает handlePlayerCollisions который имеет петлю, которая проходит через весь GameElement * контейнер в текущей сцене, вызывая handleCollision (player) в каждом из них, так что если этот элемент сталкивается с игроком, в зависимости от типа элемента он может что-то сделать игроку, например, повреждать, блокировать свой путь, перемещаться (т. е. толкается) или что-либо еще, что класс реализовал в своем методе handleCollision в своем . Кроме того, вызывается метод handleTurns, который делает почти то же самое, что и handlePlayerCollisions, за исключением того, что он вызывает handleTurn в каждом элементе, чтобы они могли делать то, что им нравится. Другой метод называется updateScreen, который делает именно то, что говорит его имя. И последнее - это цикл событий SDL, используемый для обработки ввода ключа.

Если эта архитектура является своего рода образцом дизайна, и если бы я знал, какой шаблон был, мне было бы намного легче использовать его в других проектах, и для других людей потребовалось бы гораздо меньше времени, чтобы объяснить это другим людям Мне нужно или нужно.

Answer 1

Методы, которые вы описываете, это реализация «Template Method» (GoF) модель http://www.vincehuston.org/dp/template_method.html

Answer 2

Не совсем то, что у вас есть, но модель для многих тренажеров на основе OODA loop - наблюдать, сориентировать, решить, действовать - или вариант решения о смысле смысла. В игре или симуляторе с визуализацией вы помещаете рендеринг в каждый цикл цикла.

Для вашей игры handlePlayerCollisions() является частью этапа наблюдения - каждый компонент определяет, находится ли он на том же месте, что и игрок. Предположительно, handleTurns() имеет решения следовать или убегать от игрока, а также другие решения и действия. updateScreen отображает текущее состояние игры. Отделение от наблюдения и принятия решения позволяет симуляции вычислять все наблюдения из известного состояния, затем вычислять решения из известных наблюдений, а затем вычислять действия из этих решений означает, что вы не искажаете имитацию, так что последние сущности наблюдают результаты действий предыдущих объектов в тот же цикл. Но так как вы ограничены наблюдением только игрока и сосредоточены наблюдать, решать и действовать вместе, у вас нет этой гарантии (если updateScreen также включает в себя обновление состояния моделирования).

Независимо от того, являются ли сущности в играх одной глубокой иерархией, агрегации компонентов или концерты интеллектуального поведения - это еще одно обсуждение.