Antiobjects
en.wikipedia.org
en.wikipedia.org
I used a similar method to the pacman solution to make a simulation of traffic. By modelling the road as well as the cars, I could measure the distance between cars by having the road remember when a car last passed over, and give that information to the next car that passes over. The simulation was enormously simpler by modelling the road and storing information in that, rather than just in the obvious objects - the cars.
In effect, cars left traces behind for the next cars to collect and process. Distances between cars could be calculated simply by knowing the times of transits and speeds of cars. Uncertainties needed to be taken into account, but the road could also contain pointers/references to the cars that had passed over.
In my case I distributed the simulation over 1024 processors and the messages were explicit. I find object-oriented programming largely to miss the point. As Alan Kay once said, the point was never the objects - it was always intended to be about the messages.
Of course, that's a religious argument, and probably better discussed elsewhere.
ADDED IN EDIT: I really ought to write up some of my experiences ...
When we model position of things in code, we often put the position within the thing being modeled - car, game character, window, etc. So you can do things like: aCar.position - but I think that might be conceptually wrong and have been thinking that for a long time but haven't had much chance to explore the idea.
The idea of putting the responsibility for (eg.) location of each object within the world into the world itself seems to fit better with reality, too. After all, in our physical reality there's rules that "the world" imposes on things within it. One big one is that only one physical object (atom or what-have-you) can exist in a given location in space at a given time. Having the location of an atom in space be stored in the atom itself would seemingly make it a lot more difficult to make sure that rule goes unbroken and, arguably, can't be how the universe works as we seemingly cannot "see" location encoded within physical objects in our universe (that I know of). Therefore the location of a thing is probably "stored" within the fabric of the universe itself...
Anyway... If you write up your experiences, please post them to HN - I'm betting they'd be interesting!
But of course, you can have this API and delegate the responsibility of calculating the position:
class Street {
has 'cars';
method add_car(){
$car = Car->new( street => $self );
$self->cars->add($car);
return $car;
}
}
class Car {
has 'street';
method position() {
$self->street->position_of($self)
}
}
(The deeper issue here is how consumers of Car are not coupling themselves to a particular position-calculation strategy. Change the storage of the position value from the Street to the Car, and consumers are none the wiser. This is the point of OOP.)
A simple example is an array. You don't ask an array element for the array's length or for the i-th array element; you model the container and let the container do that.
http://en.wikipedia.org/wiki/Stigmergy
http://en.wikipedia.org/wiki/Ant_colony_optimization
Also Sims had some "intelligence" embedded into objects instead of the agents:
http://www.gamedev.net/columns/events/coverage/feature.asp?f...
http://books.google.com/books?id=4xT3LgCPP5UC&pg=PA7&...
According to Luca the correct way to think about objects is not as the entities of the software model, but as the construction materials for the software model. He uses the analogy of making a physical model of the solar system. In your model the planets don't move themselves, they're moved by gears, tracks, and motors.
So it could be entirely appropriate to think of the pacman board being made up of tiles and those being true, properly understood, OOP objects.
I think he would say that "The metaphor of objects can go too far by making us try to create objects that are too much inspired by the real world." is exactly how not to think about OOP in the first place.
To get that from the scent-following, hill-climbing algorithm requires some work.
The specific case you mention is discussed in the paper on page 6 - http://www.cs.colorado.edu/~ralex/papers/PDF/OOPSLA06antiobj... It's well-written and makes for an interesting read. As someone interested in AI but without much skill I found this approach much more intuitive, though I wonder about the CPU efficiency of simulating a dynamic environment.
Will Larson also discusses these ideas in a very nuts-and-bolts manner, albeit briefly: http://lethain.com/entry/2007/jun/07/anti-objects-and-reflex...
On the contrary, the ghost object in this example still has to implement the hill climbing algorithm. It could go down the hill (as it would do if pac man got one of the super pellets), or it could ignore the hill altogether. I think this also implies that it could avoid collisions with other ghosts, or even avoid grouping with other ghosts by paying attention to their scent as well. Seems like it would be trivial for a tile to further provide the scent value for all interesting objects in the maze.
http://www.cracked.com/video_16019_video-game-pitch-meeting-...
The latter (limited) is easier if you use objects for the cars, the former (unlimited) is easier using antiobjects.
Of course, simulating the actual view of a driver, i.e., excluding things behind the vehicle etc., takes a lot more work.