From Scalable Game Design wiki
Jump to navigation Jump to search


Description: Collisions deal with the event wherein two agents run into each other. An example of the collision pattern occurs in the gamelet Frogger, where it can happen that a moving truck hits a frog. The truck wants to continue driving to the right but the frog is in the way. The live frog needs to be replaced by a dead frog when this happens.

Real World Examples: "A bat collides with a ball sending the ball flying" "atoms collide with one another sometimes bonding together"

PseudoCode Let's do the Psuedocode for the above image where the truck collides with the frog. There are many ways to do this but the following is the most correct way

IF the truck sees a frog to its right, THEN the truck sends a message to the frog telling the frog it's been hit

IF the frog receives a message that its been hit THEN the frog replaces its image with a dead frog's image etc.

AgentSheets Code:

The Truck's Code:


The Frog's Code:


One way to program this effect is to make the truck agent check for a frog agent directly ahead, and, if it finds one, operate on it so as to replace the live frog with a dead one. Instead of using language or system specific representations to capture this behavior we employ a UML sequence diagram to illustrate the interaction between the truck and the frog. In this approach


the truck does everything: it detects the frog and determines what is done with it. If there are many different things the truck can hit, with different effects (for example if the truck hits a car, the car probably doesn’t turn into a dead frog), all of this has to be specified in the behavior for the truck. It seems more natural to make the frog deal with the consequences of being hit. A second approach


, that implements this idea, is for the frog to detect the approaching truck, and, if it detects one, to take the appropriate action, in this case turning itself into a dead frog. Now it’s the frog that’s doing everything: detecting the truck and taking action. If there are different things that can hit the frog, for example cars and buses as well as trucks, the frog has to be programmed to detect all of them.

The recommended approach is a kind of blending of the truck-centered and frog-centered approaches. It looks a little more complicated at first, but deals more naturally with situations in which several kinds of things may collide with several kinds of things.

The idea is that collision behavior is divided between the truck and the frog. The truck detects the frog (or anything else it may collide with) and sends a message (say, “impact”) to the frog. The frog then responds to this message by changing itself to a dead frog. This diagram shows the sequence of events: trucks sees frog, truck sends “impact” message to frog. The frog reacts by changing its look to dead frog, plays sound, and erases itself.


Games/Simulations that use this pattern