When OOP stinks and when you instead should leave a smell behind…

I just saw an interesting video blog post by the CTO of Devexpress entitled Pac-Man and Object-Oriented Programming, in which Julian talks about how we’ve been doing object-oriented programming for 20 years now (or even more than that if you come from the SmallTalk world) and how we, as OOP/OOD programmers and designers think about programming. He then quickly moves on to comparing that to a game of Pac-Man.


Now Pac-Man was a great video game developed by Namco in Japan back in 1979 and it was released in Europe and the US the year after. The game was an instant success, maybe because it was different from most of the other video games of the time, such as Space Invaders, Galaxy, and Asteroids, which was mainly shoot ‘em up games in which you should kill and/or destroy everything you saw (much unlike video games of today where we have 3D FPS games in which you walk around and kill/destroy everything you see… Oh, wait there isn’t that much of a difference, is there?). In Pac-Man you play this pie-chart looking character that walks around in a maze eating dots at the same time as you’re trying to avoid getting caught by one of the four colorful ghosts that are, for some reason, hunting you.


Whoops… Sorry! I got a bit nostalgic there for a moment and sort of strayed away from the topic. This blog post was supposed to be about object oriented programming and design and not about gaming. So let’s get back on track, shall we?


If you, as an OOP developer, would design the Pac-Man game today, how would you go about it? You should probably create a class for Pac-Man and another for the ghosts that hunts him. Well, they might actually be subclasses of a common character class since they do share some very basic logic such as they can’t walk through walls and other basic elements that you can think of. But they would still be 2 different classes. You might also have a Maze class that draws the actual maze and have some other logic like knowing which level you’re playing and such. The dots and power ups might also be different classes.


But the logic of the ghosts aren’t that easy. How will they go about to chase Pac-Man? They obviously need to know about his position but how do you calculate the closest path to get to him? The ghosts can’t go through a wall so you must calculate the nearest path around the maze. Doing that in every game cycle on a modern day computer is not such a big deal, but Pac-Man came out back in 1979 and the CPUs used at the time couldn’t do that and still produce a fast pacing game.


The solution Julian suggested was that maybe the ghosts in the game are like blood-hounds and Pac-Man is given away a scent as he moves around in the maze. The square in the maze Pac-Man just left gets a value that as Pac-Man moves on decreases in value until the scent has evaporated. This way the ghosts has no real knowledge about Pac-Man at all since they are just following a scent. The scent itself is now a property of the maze object and not of the ghost object. Julian called this anti-object oriented programming since the logic is not in the “real-world” object of the ghost (is that really a real-world object?). So by changing the logic of the ghost not to actually hunt Pac-Man but to follow a scent when they find it and also added some logic to the maze class, the anti-object, which you probably only used for drawing before.


I love this example since it’s an example of thinking-out-of-the-box when it comes to OOP and OOD. Instead of always trying very hard to make the classes as close to real-world objects as possible make a few changes and simplify the whole idea.


To be completely fair here, this is actually not how the AI of the ghosts in the original game was designed. If you’re interested I invite you to read the Pac-Man Dossier especially chapter 3 and chapter 4 that explains how the actual AI for the ghosts was created. But the fact that the actual design was different is beside the point. Julian showed a simple solution to a hard problem you might face when you’re doing object oriented design.


Have fun!

3 thoughts on “When OOP stinks and when you instead should leave a smell behind…”

  1. Anti-Object Programming? Pure BS.

    When a developer thinks more deeply about a problem he is not, ipso facto, rejecting OO. What you’ve described is the need for additional ‘real-world objects’ because the two class solution was insufficient to solve the problem. The Scent Mr DevExpress describes is simply another class that the desired solution requires. Mr DevExpress has a british accent and his has video good graphics but his ideas are cr*p.

    What Mr DevExpress did is fail to include the value of the Scent in each square of the maze. As he said, the value of the Scent would be reduced each turn. No Euclidian Geometry required. No anti-objects required.

    Some very smart people do OO. When someone who appears to be Tom Arnold on meth tells you OO doesn’t solve problems, you should stop and think.

  2. @Greg_H, I think you’re missing the point. Anti-objects are not going against OO development, it’s a method to solve hard problems by swapping computational foreground and background and are the inverse of what we are thinking is the real behaviour of the object. In this case, instead of putting the logic into the Ghost class it is put inside the Maze instead. It’s still OO programming but it doesn’t really do what we would consider to be the real logic of the “real-world” object.

    Let’s take another example, let’s say you want to write a program that simulates an air-bubble in some container of water. If we then would use the anti-object approach we would then put the logic in the water and not in the air-bubble.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>