Разделяемая иерархия классов графического интерфейса и игровой логики?

Question

Я развиваю игру на Java и хочу, чтобы мой код разделялся в пакетах для hud/gui и логики игры, чтобы код можно было повторно использовать в каком-то другом проекте, и где объекты, которые будут нарисованы, вызовы методов из другого класса или классы (возможно, «контекст рендеринга», например, группа классов, только что сделанных для чертежа или что-то в этом роде), проблема в том, что я не могу найти лучший способ добиться этого, потому что я исследовал веб (также это форум) и шаблоны проектирования, но, несмотря на то, что некоторые выглядели интересными (например, Model-View-Controller), я не мог найти то, что мне подходит, и общий подход к решению этой проблемы.

Мне сказали, чтобы объекты были реализованы с помощью интерфейса с возможностью рисования, а в другом классе, вызываемом этими объектами, некоторый объект, который, например, реализует drawable и наследует от canvas, так что, если я захочу позже, измените методы рисования объектов или отображения для другого лучше, например, от awt до swing, чтобы иметь возможность просто переписывать эти классы и не нужно беспокоиться о моем коде объектов, любая помощь будет принята с благодарностью, спасибо заранее!

Answer 1

Что мне делать, как правило, вдоль линий:

Создать свои игровые объекты полностью независимы от всех вещей визуальных. Я собираюсь использовать шахматы в качестве примера. Каждая шахматная фигура наследует интерфейс «GamePiece» и знает, что это действительные ходы, какой «цвет» (не визуальный цвет, а какая «сторона» он включен) и т. Д. Но эти части не имеют никакого кода, связанного с рисованием самих себя. Никто. В основном делайте вид, будто играете в компьютер внутри компьютера, и вам не нужно рисовать его. Дизайн всей игры таким образом. Вам понадобится GameDirector, который управляет различными частями, GameBoard и абстрактными Игроками. Но все же, никакого визуального представления. Есть много возможностей в том, как именно вы создаете иерархию классов, но оставляете визуальные эффекты вне этого.

Вы связываете изменения состояния, поднимая события, это ключ. Поэтому, когда игрок движется, происходит событие. Когда GameDirector обнаруживает мат, появляется событие и т. Д.

Тогда у вас есть класс GameRender, содержащий GameDirector. Он прослушивает эти события и соответственно обновляет визуальную сцену (будь то простая 2D-вещь или сложная 3D-анимация). Этот класс может дополнительно иметь подкомпоненты, которые отвечают за предоставление подкомпонентов игры, но это не является абсолютно необходимым.