Pacman game class design.

Question

Hi Everyone,

I have to write a multiplayer pacman game in Java for a university assignment and I'm after some feedback for my design so far.

So I'm trying to go down an MVC style and this is what I've sketched out.

I've never designed anything using MVC, so my knowledge is really only from the pragmatic programmer and a short lecture so it's quite possible I'll have misunderstood or misinterpreted it slightly.

Also, most of the tutorials I've seen for designing simple games don't mention MVC at all so is this a case where MVC is not a good pattern to use?

My idea so far is that the Game State class would be the main source of data storage as it were, and would use a 2d array to store the state of the game, where the ghosts are, where pacman is etc.

The Game class would be the main controller class that would contain the main game loop and control all the interactions between the data (game state) and the view (probably a GUI representation - I just added text based really as an example).

After I've got the game working I'm going to have to split it out into client/server. It seems to me, by using this model, that it wouldn't be too hard to keep most of the the data and processing on the server and have the clients interact with the controller and draw their own views. I have no idea (yet) how this may effect the performance of the game over a network so I'll have to research into that further once the single player version is done.

Any tips or advice, based on my design so far, would be greatly appreciated - also bearing in mind that it will eventually have to be a multiplayer game.

Cheers,

Adam

Answer 1

On the contrary: MVC is actually a very good thing to use for this type of problem and the Swing framework does a really nice job at supporting it.

You should probably first read up on MVC. Just as an overview, you will be trying to separate how the game is represented internally (the model), from how it is drawn (the view) and how that state is to change (the controller).

First think about everything you need to model the current state of the game. Having an Entity that defines some basic behavior and subclassing it for the PacMan and Ghost like you do is probably a good way to start, but you'll probably want to call your Map a GameBoard or the like (giving things the same name as library classes is generally a bad idea: you don't want to confuse it with java.util.Map). To wrap up the model section, you probably want to wrap them all up in one class who 'knows' the entire state of your game. Since this is your GameState class, you probably want to redraw your arrows.

Since determining the view is likely to be fairly easy, you can go there. You can give your GameState a draw(Graphics) method and invoke this from whatever your view is (which you'll decide later). This might in turn delegate do each of your Entities, who might in turn delegate it to a Sprite or Image object that they have. Now your view, who's likely to be a JPanel or the like, can just call draw() using its own Graphics object from within its paintComponent() method.

Now you still need a controller to actually make stuff happen. This is likely to be some object with a KeyListener hooked into the view as well as an InputStream and an OutputStream to handle communication with the other player (it probably also needs to be the one to worry about synchronizing the game state). It also needs to also have a timer so that it can tell the units to update periodically. You do need to decide who makes the decisions on whether the moves are legal: the controller could do it, the GameState could, or it could just give the Entities the information they need and let them do it themselves.

Once you have all of these parts, you can wrap them up in one final class who knows everything and gets it all set up and such. There's a lot more that I'm glossing over and several more decisions that you have to make, but it should get you going.

Answer 2

Hi Adam,

I agree with James entirely, and would like to add that you might also want to make sure that this 2d array of yours for the game state can handle some edge cases like multiple ghosts occupying a tile, a pacman and ghost in the same tile (depending on how you handle it in your code), the pacman's food dots, etc.

Good planning more often than not makes the best programs, I'm glad to see you have started off with a diagram.