Pacman дизайн игрового класса - PullRequest
0 голосов
/ 15 января 2009

Мне нужно написать многопользовательскую игру pacman на Java для университетского задания, и я до сих пор получаю отзывы о своем дизайне.

Итак, я пытаюсь использовать стиль MVC, и это то, что я набросал .

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

Кроме того, в большинстве учебных пособий, которые я видел по разработке простых игр, MVC вообще не упоминается, так что это тот случай, когда MVC не подходит для использования?

До сих пор я думал, что класс Game State будет основным источником хранения данных и будет использовать 2d-массив для хранения состояния игры, где находятся призраки, где pacman и т. д.

Класс Game будет основным классом контроллера, который будет содержать основной игровой цикл и контролировать все взаимодействия между данными ( игровое состояние ) и представлением (вероятно, GUI представление - я просто добавил текст, основанный в качестве примера).

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

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

Приветствия

Адам

Ответы [ 2 ]

2 голосов
/ 15 января 2009

Напротив: MVC на самом деле очень хорошая вещь для использования в этом типе проблемы, и среда Swing действительно хорошо справляется с ее поддержкой.

Возможно, вам следует сначала прочитать MVC . В качестве обзора вы будете пытаться отделить, как игра представлена ​​внутренне (модель), от того, как она нарисована (вид) и как это состояние должно измениться (контроллер).

Сначала подумайте обо всем, что вам нужно для моделирования текущего состояния игры. Наличие сущности, определяющей базовое поведение и делящей его на подклассы для PacMan и Ghost, как у вас, вероятно, является хорошим способом для начала, но вы, вероятно, захотите назвать свою карту GameBoard или тому подобное (присвоив вещам то же имя, что и библиотеке классы, как правило, плохая идея: вы не хотите путать это с java.util.Map). Чтобы завершить раздел модели, вы, вероятно, хотите объединить их в одном классе, который «знает» все состояние вашей игры. Поскольку это ваш класс GameState, вы, вероятно, хотите перерисовать стрелки.

Поскольку определение вида, скорее всего, будет довольно простым, вы можете пойти туда. Вы можете дать своему GameState метод draw (Graphics) и вызывать его из любого вашего вида (который вы решите позже). Это, в свою очередь, может делегировать каждый из ваших сущностей, которые, в свою очередь, могут делегировать его объекту Sprite или Image, который у них есть. Теперь ваша точка зрения, которая может быть JPanel или тому подобное, может просто вызвать draw (), используя свой собственный объект Graphics из своего метода paintComponent ().

Теперь вам все еще нужен контроллер, чтобы реально все происходило. Вероятно, это будет какой-то объект с KeyListener, подключенным к представлению, а также InputStream и OutputStream для обработки связи с другим игроком (вероятно, он также должен беспокоиться о синхронизации состояния игры). У него также должен быть таймер, чтобы он мог периодически указывать единицам обновления. Вам нужно решить, кто принимает решения о том, являются ли ходы законными: контролер может это сделать, GameState может или он может просто предоставить сущностям необходимую им информацию и позволить им сделать это самостоятельно.

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

1 голос
/ 15 января 2009

Я полностью согласен с Джеймсом и хотел бы добавить, что вы также можете убедиться, что этот ваш 2-мерный массив для игрового состояния может обрабатывать некоторые крайние случаи, такие как множественные призраки, занимающие плитку, пакман и призрак в та же самая плитка (в зависимости от того, как вы обрабатываете ее в своем коде), точки питания пакмана и т. д.

Хорошее планирование чаще всего делает лучшие программы, я рад видеть, что вы начали с диаграммы.

...