COMP 310 Spring 2010	Lec08:  To Infinity...and Beyond!

What's insufficient/wrong about our composition-based system as it stands?

• What is the difference between updating and painting?

  •  Do they need to be done at the same time, i.e. when the system repaints?

• What is fundamentally going on in collisions in terms of communications among objects?

  What is the dispatcher really doing?  Is there an implicit message involved?

  • How can we make an explicit message?

BallWar Demo

Changes in the BallWar system:

• True Model-View-Controller architecture

• Command-passing system (message passing)

  • Collision-detection and mass (radius) based rebounding behavior

  • External communications: useer-control, score-keeping

  • Ability to "kill" a ball (remove from dispatcher)

  • (not implemented in demo) Ability to separately paint and update.

• Strategy-based painting

Command-based Updating

Instead of merely telling the ball to perform an invariant update method (single method to move, paint, bounce, etc) with an invariant parameter (the Graphics object) being passed, the dispatcher sends out a variant command object that the ball invariantly executes.

A command to the ball to do something is defined as such:

package ballwar.model;

/**
 * Interface that represents commands sent through the dispatcher to process the balls
 * 
 */
public abstract interface IBallCmd {
  /**
	 * The method run by the ball's update method which is called when the ball is updated by the dispatcher.
	 * @param context The ball that is calling this method.   The context under which the command is to be run.
	 */
	public abstract void apply(Ball context);
}

Notice that the command is given a Ball object when it is executed, so that it knows what ball it is working on.

For instance, the dispatcher may send out a command to update the state:

_dispatcher.notifyAll(_updateStateCmd);

All the ball ever does is

  /**
   * The update method called by the main ball Dispatcher to notify all the balls to perform the given command.
   * The given command is executed.
   * @param o The Dispatcher that set the update request.
   * @param cmd The IBallCmd that will be run.
   */
  public void update(Observable o, Object cmd) {
    ((IBallCmd)cmd).apply(this);
  }

With this, a ball can be made to do whatever you want it to do, whenever you want it to do it!

Collisions

A ball can have access to the dispatcher, either because the dispatcher is available on its update call, or simply by providing the ball with a reference to it (possibly via a larger reference to an "environment" that provides the dispatcher and other services).

A collision is a communications between one ball and another.   To figure out what other balls any given ball has collided with, all it needs to do is to send out a command via the dispatcher to check the if the other balls are within collision distance to it, i.e. less than the sum of their radii.

Note to hard-core game programmers:  There are clearly more effecient methods of performing collision detection that one would use in performance-oriented systems.   The discussion about collision detection here should really be taken as an example of inter-object communications in a message-passing architecture.

Fundamentally, all a ball does is to send out a command to all other balls to process the collision(s):

Basic collision process performed by the collision command:

1. Make sure that the other ball is not yourself!    Remember that the dispatcher sends the command to everybody!

2. Are the two balls within collision distance?

   • If so, then proceed to calculate the effect of the collision on each other.

     1. You need make sure that when the other ball checks if it has collided with you, the collision computation and effects are not repeated.   You can accomplish this by being sure to explicitly move ("nudge") the two balls beyond collision distance after processing them. Other techniques involve trying to keep account of who has already collided with whom, but that, while efficient, can get very messy.

   • Otherwise, the command should end.   The dispatcher will send the command to the next ball to be processed.

Question:   How do the parameters necessary for the collision process get passed along when the dispatching process only allows one parameter to be passed and that parameter is the command itself?

© 2010 by Stephen Wong