OOP Pacman

[tromm82]

Hello, I'm trying to put together a simple javascript/dhtml implementation of Pacman in an oop style (as far as js will let me) but I've come up against the same problem I always do (kind of the point of the exercise). I end up with aggregated objects that need to query objects that they have no access to. I am obviously designing my code incorrectly - can anyone offer any advice. I will use the Pacman example (obviously not faithful to the origninal )

I basically have Agents (ghosts and the pacman) which share an interface but differ in their methods of altering their x and y properties.

A Renderer object is responsible for display and is handed a Map on instantiation which contains a TileList of Tiles. Tiles being either Wall or Passage implementations of the Tile interface.

The Main loop updates and gets the Agents' positions and hands them to the Renderer which then flips its rendering to reflect the new positions.

The problem comes when your Agents need to know whether they are allowed to move to a particular location - they need to have their own movement logic but are bound by the logic of the Map also. This more or less describes the general case of my recurring problem

Would I get the Agents to request a position and check it with the Map before allowing or denying? Seems a little long winded and un-encapsulated?

Thanks for any comments

tom

 

[DonQuichote]

I do not see why it is unencapsulated for any moving object to consult a map.

Just take a look at all the entities, without thinking about code but thinking about responsibilities.

[ul][li] There's a Pacman who must flee from ghosts and eat pills.[/li]
[li] There are Ghosts who must pursuit Pacman.[/li]
[/ul]

Both of these entities must be able to look around to do their job. The fact that there are also minor entities like walls does not change this fact, but only adds to it.

So they must have access to your Map. Now this Map object can grow way too big if you start implementing all necessary methods on it (like a distance calculator that lets Ghosts pick the best route, for instance). When this is the case, you can extract specialized classes to do specialized tasks. For instance, a MapQuery can hold all the queries for the map. But that is not a "hard right or wrong" situation. It is more the idea of responsibilities. You may say that it is Pacman's reponsibility to do his task, but you could also say that a GameEngine would have to control a non-intelligent Pacman. That is up to your personal taste and situation.

Good luck!

+++ Despite being wrong in every important aspect, that is a very good analogy +++
Hex (in Darwin's Watch)

 

[Craig0201]

I don't think they HAVE to have access to the Map. They do have to have access to Locations.

For your specific problem, I would have each Agent being responsible for holding their own Location. Now, a Location is part of a Map and could return a collection (or similar) of each adjacent Passage. Then you pass that collection back to your Agent.

That's then all nicely encapsulated with each object doing a specific job.

Your problem then becomes the finding of efficient routes for Ghosts. This is still relatively easy if you are happy with a simple distance comparison algorithm.

C

 

[Craig0201]

Just re-reading this and this caught my eye.....

"Seems a little long winded and un-encapsulated?"

It definitely IS encapsulated. Each item has a job. Long-winded.

With regard to long winded, OOP often requires more lines of code and joining together of data structures than under a different paradigm. It is, however, often easier to understand and reuse. As an example, you could easily adapt your Renderer, Map and Tiles to use in other tile based games by using interfaces and high level abstractions.

C