Sourceforge Project Approved!

Our project was approved by sourceforge so now we can make use of their facilities! The project homepage will be kept at http://oopuno.sourceforge.net.

Sourceforge Project

I put in a project request on sourceforge under the name OO Patterns UNO, and it will take about 2 days for the project to get approval. Hopefully they won't deny us, but if they do, I still have a CVS server we can use.

Solution to Spawning!

I thought of a way to solve the spawning problem!

Our spawner can simply create dead cells in the unoccupied points around any living cells. Then the world can iterate through the cell set so that each cell decides its own life or death. Then the world cycles and the job is done!

Conway Game World

I think the world can easily be represented as a set of Cells, and we can think about a layout or topography as just a rule for where a Cell is allowed to be placed. I don't like the idea of using any 2 dimensional lists, arrays, or the like, because that becomes a mess and is much harder to change later if it's in use.

Thinking about the features of a Cell, a Cell should probably have a Position. A Position could be a point in 2 or 3 dimensional space (or maybe additional dimensions as well in case I'm being short sighted). The important feature of a Position should be that it can calculate distance from another Position. Cells can use this distance to figure out who their neighbors are. Consider this code:

class Cell {

   ...

   public boolean isNeighbor(Cell c){
      /* this assumes the neigbor distance limit is 1 unit 
          as in Conway's Life */
      return (this.position().distanceTo(c.position()) <= 1.0)
   }

   public Position position(){
      return p;
   }

   private Position p;
}

Can also create subsets of our Game World's Cell set by filtering on Cell's isNeighbor(Cell) function, thereby just having to get the size of the subset to determine the number of neighbors.

And thinking about what the presentation will need to display the Game World, I think the model will need to have a query to get a copy of the Cell set.

Top Down Approach

I have two reasons for wanting to do a top-down approach.

1) By the building from top to bottom, it forces us to think more about what features our underlying model should have. This is the same principle behind test-driven design.

2) We have something executable that we can build, use, and demonstrate with, even if it doesn't provide full functionality at first. An executable provides us a structured way to examine the functionality and design of our program without having to turn to the source code, which is especially useful for dealing with customers who don't program or haven't already seen the source code.

Also, a top-down approach doesn't mean we ignore the model. As said above, top down will make us think about what we want our model to do. So, we can specify, or implement mock, objects to hold a foundation while we build the top. Then when we're satisfied with that layer, then we take a step down to implement our mock objects, and this becomes our new top layer, thus iterating the process. If we work in this way, we will have to think about the model a great deal, and we'll be thinking about it from the point of view of a client, which is what we want.

Meeting 2/10

In today's meeting, we mainly discussed the Game of Life project, including possible changes to anticipate, patterns to accommodate those changes, and general design issues.

We set an agenda to begin building the Game of Life program.

We scheduled our next meeting for the regular meeting time of Tuesday 3PM next week (Feb. 15th).

Conway Game of Life

I found a link (http://www.tech.org/~stuart/life/rules.html) for the rules for the game, and the game is so simple that I doubt we'll need much else.

I think we should write a use case for the usage of the program and then start with a top-down approach by implementing the GUI components first.

We should also investigate getting a project at sourceforge so that we have a common place to keep our code.

Weekly Meeting 2/02

Topics discussed: Programming Languages' Popularity

Reading for next week: Language Popularity, GoF Design Patterns Workbook

Next Meeting Time: Thursday, Feb. 10, 3PM