Comp201: Principles of Object-Oriented Programming I
Spring 2007 -- BallSwarm -- the Evolution of Ballworld   

The Ballswarm code base is the latest version of a long evolution of the Ballworld system.   It introduces new features and capabilities aimed at enabling richer interactions and more accurate modeling.

BallSwarm is still in development and has not been fully tested for bugs and may have missing or incorrectly implemented or documented features!

Because of the increased complexity and "alpha" version nature of the code, extra credit is offered to any students who base their Comp201 final project on the BallSwarm code base.

The latest version of BallSwarm can be downloaded here:  BallSwarm.zip  (4/24/07)  NEW!!

Release notes:

• 4/19/07:  Initial release
• 4/24/07: Dynamic Configuration Panels added
  • See description below in the New Features section.
  • IStrategyFac class made public and configuration panel capability added.
  • IBallCreateAdapter modified to enable configuration panels.
  • New  buttons added to GUI
    • to directly add a strategy factory to the drop lists
    • to bring up the configuration dialog for the selected strategy
    • Configuration of dynamically composed strategies does work by creating a dialog with tabs for the different configuration panels.
    • Controller automatically creates null (no configuration available) factories for the previous written strategies that are loaded directly.
  • Two examples of strategy factories with configuration panels provided: CurveStrategyFac and ColorStrategyFac (just type in "Curve" or "Color" and click the "Add factory" button to load them).
  • Cross and inner product functionality moved to Point2DDouble class.

New Features  (not a complete or definitive list!)

BallSwarm is based off of the BallWar version of the Ballworld system and build from the features and capabilities from that level.

Decoupled Updating and Painting

BallSwarm runs with two separate timers for updating and painting the balls.    These timers send the appropriate IBallCmd through the dispatcher to tell each ball to update or paint.  

1. In general, updating is done more often than painting.  
2. The painting interval is defined as a unit of time and the update interval is defined as a fraction of the painting interval.  This allows the simulation to be sped up or down as a whole or to increase or decrease the number of updates per painting interval to increase/decrease computational accuracy.

Two-Stage Updating

BallSwarm utilizes a two-pass updating technique for increased accuracy:

Pass 1: All Balls calculate the changes to their velocities, etc but do not actually effect those changes.  Instead, each Ball has a set of IBallCmds (_updateCmdSet) that it accumulates.   All calculations for changes to the velocities are done at this time.

Pass 2: All Balls are told to execute the set of IBallCmds that it has stored from the first pass.  This will change the velocities and positions of the balls.   No calculations are done at this stage.

At the moment, there are no controls that enforce the adherence to the two-pass schema.   Code that updates the velocities immediately will compile and run but with possible unintended consequences.

Double-Precision Vector Information

All positions, velocities and other vector/point information in BallSwarm is now represented by double precision real numbers, not integers.    This allows for much more accurate calculations based on position and velocity. 

Instead of java.awt.Point, the BallSwarm system uses util.Point2DDouble, which is a sub-class of Point2D.Double but with increased functionality and ease of use.

Strategy-based Movement

Balls in BallSwarm use an IBallMoveStrategy to decouple the velocity of a Ball and the movement determined by that velocity.   Instead of directly changing the Ball's position based on its velocity, this behavior is delegated to a strategy.   Most of the time, the strategy does the normal translating of the position by the amount of the velocity (divided by the time slice value), but the strategy is free to do whatever it wishes instead. 

The IBallMoveStrategy holds the velocity of the Ball, not the Ball itself, thus decoupling it from the ball.

This feature is used when you want to control the movement of a ball, such as make if follow another ball or to freeze in position, independent of the forces on its velocity. 

Collision Detection as an  Update Strategy

Collision detection as implemented in the BallWar system has been disconnected.   Collisions are now implemented as updating behaviors between balls.   See, for instance, the AversionStrategy, SeparationStrategy, and OneSideWallStrategy classses.

Dynamic Configuration Panels

Configuration panels ala the Shape Calculator are instituted to enable run-time reconfiguration of the parameters affecting the update strategies.  An IStrategyFac is a factory that instantiates IUpdateStrategies plus can instantiate a JPanel that is used in an AConfigDlg dialog frame for configuring the factory.  The Accept and Cancel buttons from the dialog box are given to the factory to enable the desired behavior when accepting or canceling a configuration setting.  The Ok button on the dialog will click the Accept button as well and then close the dialog.  The Cancel button also closes the dialog box.

Factories can be set up such that the configuration either affects all strategies ever made by the factory, ala "switching" or only the next strategy made by the factory.   See CurveStrategyFac for an example of a factory whose configuration affects all strategies.   Changing the turn angle will affect all balls made with strategies from that instance of the factory.  Ttry this: create two instances of the factory by loading it twice into the system and see what happens.  See ColorStrategyFac for an example of a factory whose configuration only affects the next strategy that is made.  That is, each strategy made is independent of the factory after it is instantiated.

The BallControl controller class automatically wraps bare strategies that are loaded using the legacy code with a factory that provides an empty configuration panel.   It also automatically creates a factory for dynamically composed strategies (actually dynamically composed factories) that has a tabbed interface where the control panels for each of the composed factories are on their own tab.   The Accept and Cancel buttons will affect all the composed factories.   Note that the tab layout is due to the fact that the composition is technically a binary tree where only two factories are composed at any given point. 

More information coming soon!

Upcoming Enhancements  (coming who knows when?)

Targeted Behaviors

Instead of blinding interacting with all Balls via the dispatcher, using specialized criteria defined by ballwar.model.FilterCmd.IFilterCritera, only a ball could choose to only interact with a subset of the all the balls.  This would be very useful for behaviors such as limited scope of view (limited distance or forward facing for predators, for instance) or discriminating interaction (e.g. attracted only to same/opposite kind).   TargetedStrategy holds some unfinished code to implement this feature.

More features coming.   Suggestions are always welcome!

Last Revised Thursday, 03-Jun-2010 09:50:16 CDT

©2007 Stephen Wong and Dung Nguyen