Игровой дизайн способом OO

В одном конкретном движке, над которым я работал, мы отделили логику от графического представления, а затем создали объекты, которые посылали сообщения о том, что они хотят сделать. Мы сделали это для того, чтобы игры могли существовать на локальной машине или в сети и были неотличимы друг от друга с точки зрения кода. (Командный шаблон)

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

Мы активно использовали код, управляемый событиями (паттерн слушателя), и много-много таймеров.

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

Если я помню (а прошло уже 12 лет), у нас было абстрактное понятие сцен, поэтому игра представляла собой последовательность сцен. Когда сцена заканчивалась, наступало событие, которое обычно посылало команду завершить текущую сцену и начать другую.

Я пишу свои собственные движки (сырые и грязные), но предварительно собранный движок с приличной объектно-ориентированной моделью - это Ogre . Я бы рекомендовал взглянуть на него (это объектная модель / API). Назначение узлов - это немного забавно, но чем больше вы смотрите на это, тем лучше становится смысл. Он также очень хорошо задокументирован с множеством примеров рабочих игр.

Я сам научился парочке уловок.

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

Приложение: вам нужно хранить модель игры отдельно, но вы можете повторно разложить эту модель на столько классов, сколько потребуется.

Я не согласен с тем, что, поскольку у вас есть основной класс Game, вся логика должна выполняться в этом классе.

Чрезмерное упрощение, имитирующее ваш пример, чтобы подчеркнуть мою точку зрения:

mainloop:
  moveEntities()
  resolveCollisions()   [objects may "disappear"/explode here]
  drawEntities()        [drawing before or after cleanEntitites() ain't an issue, a dead entity won't draw itself]
  cleanDeadEntities()

Теперь у вас есть класс Bubble:

Bubble implements Drawable {

handle( Needle needle ) {
    if ( needle collide with us ) {
        exploded = true;
    }
}

draw (...) {
   if (!exploded) {
      draw();
     }
  }
}

Итак, конечно, есть основной цикл, который заботится о передаче сообщений между объектами, но логика, связанная со столкновением между пузырем и иглой, определенно отсутствует в основном классе Game.

Я почти уверен, что даже в вашем случае вся логика, связанная с движением, не происходит в основном классе.

Я не согласен с вашим утверждением, которое вы написали жирным шрифтом, что «вся логика происходит в основном классе».

Это просто неверно.

Что касается хорошего дизайна: если вы можете легко предоставить другой «вид» своей игры (например, мини-карту) и если вы можете легко закодировать «покадровый идеальный повторитель», тогда ваш дизайн вероятно, не так уж и плохо (то есть: записав только входные данные и время, в которое они произошли, вы сможете воссоздать игру именно так, как в нее играли. Именно так Age of Empires, Warcraft 3 и т. д. делают их повтор : записываются только вводимые пользователем данные и время, в которое они произошли [именно поэтому файлы воспроизведения обычно такие крошечные]).