CIT 594 Assignment 6: Beeper Hunt Design Feedback
Spring 2004, David Matuszek

Please note:

Aldebaran (chosen by 3 groups)
  1. The purpose of each Class and Interface is clear.
  2. The MazeVertex Class provides useful methods such as setVisited() and getVisited().
  3. Having the Robot and the Beeper both extend MazeObject is helpful in that it makes us think about what properties they share as elements on the Maze.
  4. The whole design is very simple and easy to follow, also very flexible to add other useful methods for each class.

There are, however, unnecessary methods that need be removed and additional methods that need to be added.

Since there is a method, addEdge(Vertex start, Vertex end) in the Graph class, we can't find out how to know the given two vertexes which are connected to each other. The constructor of MazeVertex should have the information about what vertexes it is connected to, and provide getter and setter methods.

Since it already have the x-y coordinate in each vertex to show its location, we thought they didn't need to use the method, MazeVertex[][] getMazeMap(), to get a 2D array, use a vector or array(1D) is enough.

Indeed this design has a very good construction for the maze.

Using Mazevertex class and MazeObject class is a very good idea because we can move easily to the different MazeVertices and have information about what they contain ( we can obtain the whole Object Robot for example or null if there is nothing). It is a good idea to do an abstract class for MazeObject because Beeper and Robot have common functions.

Besides all the necessary methods are present like the one to compute the shortest path, the one to place the MazeObject in the Maze...

The graph Class allows us to define well the edge between the vertices.

We think it is the most practical design to implement this project.

It corresponds the most to the way we want to handle the problem.

The small drawback is that there is no direct connection between adjacent vertices (as we can see in certain design) but we can do this with graph.

But...Doesn't implement Observable; method die has no point.

Has well designed application components. We liked the well thought out inheritance hierarchies. Not quite sure how the sub-mazes can be created and implemented in this design. Overall a workable design.

The class Graph and interface Vertex are extended and implemented just once, so they are unnecessarily refactored.

This is a generally well-thought out design which makes good use of inheritance and polymorphism. Cons: Robot has too many public methods. For example, findClosestBeeper and collectBeeper should be private methods for the Robot, that are called by its takeTurn() method. Maze could probably be designed using less classes (currently there are 4: Graph, Vertex, MazeVertex, Maze). Overall, a few too many things have been specified, which leave the programmer handling the implementation less flexibility.

It feels like the Graph/Maze classes are trying to do too much work. This design would be easier to program if whatever is doing the visiting keeps track of what Vertices it has visited. That way, search algorithms are not restricted by the objects they search. Also, why do Vertices keep track of their own locations? Might it be easier for the Graph to just relate all of its child Vertices?

Every MazeObject has a getLifespan method, even though this just matters for Beepers. Likewise, why do Beepers have a takeTurn if only Robots move?

It would be helpful to further define the method getLifespan(), (e.g. specify # of rightTurns, leftTurns or a combination of both). In reference to the method die(), one must first check to make sure that the placement of the beeper is valid (e.g. not on top of another beeper, robot or in the same spot as one that recently disappeared).
Very detailed and complicated. It seems hard to construct mazes for proper future use.

 

Altair (not chosen)
The BeeperHunt constructor is doing too much non-instantiating work.

Some methods are not very intuitive, like Beeper.getTimeLeft and Beeper.incrementTime. Shouldn't Beepers be controlled by the model or the maze? We didn't understand why the Robot does setTimeLeft.

+ Maze implements Observer
+ very flexible/ few constraints
- Maze needs to keep track of the location of the Robot and the Beeper
Have a BeeperHunt constructor is not necessary.
Maze repaints after every move. Methods missing parameters, such as move() – move which way? UI appears to contain sufficient methods to build a maze properly.
Here again, the system for keeping track of walls could be more easily done by just tracking the edges. The beepers have a move method, they should though as they are placed and then collected. It seems inappropriate to me to have the Robot setting the time left in the game, shouldn't this be done by BeeperHunt?
This is also a design with very clear and general structure. However it seems that the class Cell is an isolated unit in the maze. It may be nice when drawing the maze but it may not be easy for robot to find the proper path.
I'm not sure what Cell getCell() is for within the Beeper and Robot classes.

I like the idea of assigning a new cell to a beeper as opposed to assigning a new beeper to a cell. I hadn't thought of it that way.

The design specifies the implementation for Maze data structure (Cell[][]) and Robot’s beepers (Beeper[]). Those implementations should probably be private.

The Robot is supposed to find the best path to move, but there are no public methods in Maze or Cell or Beeper to get Beeper locations in the Maze. (I guess the Beeper[] array would Beeper method “incrementTime()” probably should be something like “incrementAge()” or “decrementTime()”

Overall, this is a good design that should be able to achieve the desired results. However, there are a few things about it which seem to violate good OO design principles. For one, parameters which affect the entire game are handled by the individual game pieces. So for example, every time a move is executed, each piece has to update its own internal clock, which could lead to some redundant code at best, and some frustrating errors at worst. Also, there is no SubMaze class, so that a Maze class has to do two things: build SubMazes, and then put them together into a Maze.

 

Antares (chosen by 1 group)
Specification is not detailed enough to work with this design.

Has not provided a method to get the remaining lifetime of a beeper. No way to know when the beeper will disappear.

Has not provided constructors for Beeper, Maze, Submaze and Robot.

The design seems doable and is relatively easy to follow and understand. It is not too complicated, yet not too simplistic.

Robot has knowledge of Maze, which was a feature we were looking for in a potential design.

Mazeboard has the necessary directional constants to successfully create the game board.

Maze and Submaze don't have any public methods or constructors. This is confusing for a specification.

In the MazeBoard class, the value checking that isLegalSide and isLegalPosition do really should be private. Public methods should just automatically check for legal values and return or throw exceptions as necessary.

Instead of stay, step, and findPath, why not just give the Robot an advance method? That way, the Robot always does the right thing.

Some of the methods lack descriptions.

The strength of this design was also part of the main criticism. It is quite simply and effectively laid out, and has what seems to be only the most essential methods described, which leaves a great deal of flexibility to the programmers. However, this leads to some confusion where there is too little described. While the Beeper, BeeperHunt, Robot, and MazeBoard classes are well described, very little is said about the Maze, Submaze and TreeNode classes, which, considering the nature of the assignment, is far too vague. While only information of *what* a class does was necessary, not *how*, a little more information would have been more helpful than the one line provided for those 3 classes.

No point using TreeNode class.

Misses method to place walls.

SubMaze class useless.

In general this design appears to give control to beepers and robots.

The issue here is that the MazeBeard is seems to be mixing GUI and model components. It might be improved if several of these were moved out of MazeBoard into maze (i.e. the placeBeeper method).

One pretty cool feature that this design has is that SubMaze EXTENDS TreeNode. At first, this appears to be a mistake, but then one realizes that the relationship between submazes is a tree (or more properly a graph). Just as each “spot” in the maze has potentially 4 neighboring “spots”, each subMaze has potentially 4 neighbors as well. The only issue here is that there does not appear to be any way to set the neighbors of any TreeNode, as there are only getters for these values.

1. Not all of the classes provide constructor in this design.

2. In the constructor of the treeNode class, they didn't pass the four children of this node and didn't provide the setter methods for its children. The children of every nodes will never be set up and keep null.

A comprehensive list of fields, variables and methods is provided; Necessary methods of finding a path and constructing the maze are provided; How can GUI part provided by Dr. Dave be interpreted into the design is not shown.
There are no constructors for Beeper, Robot, and SubMaze. What parameters need to be passed to these objects? How is a Robot added to the Maze and how does it interact with the Maze to know what the shortest path is?

 

Arcturus (chosen by 2 groups)

+ It [the design] was generally complete, seemed very well though out, and appeared internally consistent.
+ We liked the design of methods for determining the best path. (Splitting them into two methods is an interesting, and we thought, useful way of thinking about the problem.)
The few criticisms we have were:
- We weren't thrilled with the extra GUI classes. That seemed a little confining.
- Does the Grid class really need to be abstract?

Good design because it contains adequate Vector methods to calculate path. Provide access to get the shortest path. Minor changes to add move method and getLocation from the beeper and the robot and also an Observer to notify the UI. Need to add getter and setter methods in grid and GridNode for the wall openings between the mazes and getter methods to the node references in GridNode.
The public constants are nice, but why are they in their own interface? Why not just put them in BeeperHunt or divide them among the other classes as appropriate?

Did you forget to include the Beeper class? You mention it, but I can't find its description.

Nice way to illustrate shortest path although it would be better if the shortest path was sent to the robot rather than the GUI and then the robot will notify the GUI of its movement. It would also be nice if calculation of the shortest path returns the actual Path object, rather than the Vector, so that the user can know for sure the type that they’re dealing with. Returning Collection requires the user to know what kind of object they need to cast the content of the Vector to. Cannot get location from the robot. Robot cannot move.

Good:
I interesting in the way to design the Maze, especially the GridNode class (maybe a bit hard to manipulate)

Bad:
No point doing a interface BeeperConstant, rather implement it in the concerned class
No action defined for Robot
No need to use an abstract class for Grid class

The robot does not know anything about the maze or beepers. We preferred a design where the robot would have this knowledge.
1. There is no obvious reason to have a interface class, BeeperConstants, containing only all constants.

2. There is no way to move the robot in this design. Thus, there should be a move method in the Robot class to move the robot.

It is hard to comprehend this entire design because a lot of methods have been made private. It is unclear on how the robot is going to navigate through the maze.
Wrong function of class: In the Maze class, designer provides methods pathToLocation() and shortestPath(), but these two should be the actions of the Robot instead of the Maze.

Not enough actions: Within the Robot class, there is not a method that tells us how the Robot will move and how the Robot will search for the best path.

Not enough classes: Could not find the beeper class, wondering how to get the information about the beepers.

Has a separate interface for BeeperHunt constants - not sure what benefit that provides. Has grid nodes with separately settable adjacency, gets into the possible situation described above - a node having a connection not reflected by the other, having a wall where the other doesn't. Adjacency and walls should set both nodes simultaneously imho.

Makes Robot a child of Object. Last semester I was dinged for treating cars and trucks separately, so maybe a design that treats beepers and robots as game pieces would be better.

Doesn't have a Beeper class described - though it is used as an input parameter in other methods.Hole in the design.

Doesn't seem to have a way to move robots or beepers, though does have a method to come up with a desired path vector but no method listed uses this vector.

Creates it's own Canvas class instead of using Dave's - a mistake I think.

Needs more on Drawing - more classes, methods.

Does make some attempt at GUI design with some panel classes listed.

For what it's worth, we also liked Arcturus and Rigel.

 

Betelgeuse (not chosen)
+ flexible design
- no method to seek the shortest path
- Maze needs to keep track of the location of the Robot and the Beeper
- uses too much methods in Node class to evaluate the connection between 2 nodes

Assumes (wrongly) the maze will be square in the Maze constructor (one int parameter for size).

Maze has a method to return an object stored at a given location, but no way to place one somewhere.

Handles x and y position values separately (should have a Position class and pair them up) but still workable.

Has methods to say if a node is connected in a given direction (left right, etc.), but doesn't return or provide direct access to the node with the connection. So you have to go by the x, y coordinate of the given node and go to the node with the y+1 value if there is a right connection. Different, but still workable - it's a two step process to search the tree. Doesn't have variables to set if the node has been visited, if it contains an item - just used to establish that there are connections (walls).

No way to reset a beeper timer, so forced to create a new one, but no obvious way to get rid of an existing one.

No way to set Beeper location (or place it in the maze) but a method to say what it is.

Robot is given the Maze to use in its constructor so it can place itself, but no reference to either beeper, except by going through the Maze cell by cell and polling to see if a beeper is there. No way for collect beeper to get rid of old one and generate a new one.

GUI data, classes etc. - none.
Reference to Dave';s Board class? No.
Any sort of Canvas? No.
Drawing routines? No.

Good start but adding in the parameters and some additional methods would make the design more concrete e.g. (method to remove beeper, check validity of beeper, etc.).
"Node" class has too many redundant methods like those set or get methods. It's not necessary to be public.
This is a pretty straightforward design. It creates a simple 20x20 maze and does the basic requirements of the assignment. However, there are two things missing from this design: the method for the robot to stay put in one position if it can't reach a beeper in time; and the GUI for the game is missing too.
Good design but the Maze object constructs a whole maze; there is no way to build submazes as per Dr. Dave's instructions. It is not clear how the getPosition method of the Beeper class works; how does the Beeper know where it is located? Is the Node a parameter passed to the Beeper object?
This has a nice set of classes, but the relationships between them are unclear and some essential methods are missing. For example, wouldn't Robot need a getPosition? Where does the GUI fit in?

This design has a number of problems:

  • Maze only has one constructor, which builds a square Maze; if a non-square maze were desired, no way to create it is provided.
  • Maze provides a method to return an Object at a given location; but which object? A node? A robot? A beeper? This could cause the programmer a lot of headaches with regard to casting.
  • Node provides a huge list of getters and setters for left, right, top, and bottom walls. It would be better design to provide ONE getter and setter, and feed it a parameter.
  • In the Beeper class, it is not clear if the reduceDuration and getDurationmethods are to see and set how many steps this beeper has already existed for (good idea), or to see and set how many steps it should exist for (bad idea).
  • In the Robot class, public int incrementBeeperCounter() seems like a bad idea. The Robot should move onto a spot and collect a Beeper if applicable, and handle it’s own beeperCount. Nobody outside of the Robot’s class should be able to modify this variable.

What if there is no object at a particular Cell? What would getElementAt() return? How do you know that there is a robot or beeper at that location?

The Node class has unnecessary methods for each side of the Node - it could do with just one method in which a side can be passed as an argument.

 

Capella (chosen by 3 groups)
+ good implementation for the wall and the connection between cells
- no method to compute the shortest path to a Beeper so it has to be implemented in the BeeperHunt class (not very handy)
- uses SubMaze class, which can get the problem harder

The "Capella" design is closer to our original design.

Maze is separated from SubMaze makes the design easier to implement.

It is simple and to the point, without redundant or abused methods

Solid design overall yet we do not like how the Node class sets and gets Beepers and Robots. It seems in order to move the Robot the setRobot method in the Node object in the SubMaze object in the Maze object must be called and this may prove difficult to implement
Capella has a brief scheme of necessary classes, yet is not well documented to show details of key methods of this program, such as how a robot can decide which beeper to pick Necessary parameters for some methods are missing. The relationship between GUI and other modeling part is not illustrated.
The structure is straightforward and with all classes we need to instantiate new objects for the program. Classes for building the maze (Node, SubMaze, Maze) together describe the concept that how to build a graph. And there are separate classes responsible for program control (BeeperHunt) and display (Dave's class Board).

It is not clear how maze construction occurs.
There seems to be no way to figure out how to connect two submazes, since it’s not possible to know which nodes are on the perimeter of a submaze without searching for nodes that have only one reference to another node.
There is also not a good way for the robot to get the beepers that currently exist on the board. Even though the array of beepers is passed in the robot constructor, once they expire those references are no longer valid.
Overall, this design is decent but perhaps its heavy reliance on the BeeperHunt class to control everything (instead of delegating certain tasks to Robot and Beeper) is likely to be error prone.

Redundant methods: Node class has setters and getters for both Robot and Beeper, which is not necessary. Setting and getting an Object would be enough.

Not enough methods: Robot class should provide the method to get it's location.

The setRobot() method in Node does not take in any arguments. Only two cells will have beepers, so why should 398 other cells have a Beeper object? Why would a Node class have a Robot object? Robot keeps moving, which adds unnecessary work of changing the Robot object of each cell as the robot moves.

BeeperHunt implements Observable, but who is the Observer?

This is a clean and clear design. Our one real complaint is that setting the Walls of a Node is harder than just setting the open neighboring Nodes and risks duplicating data.

 

Canopus (not chosen)

The overall design was simple and quite easy to follow (thanks!). The setup of the objects was very clear and would be easy to work with. It may have been helpful to have some more specification as to how the objects would interact once everything is set up. Favorite part of the design - boolean [][][4] walls (great idea!).

A maze implemented as an array of Pieces is not a very good implementation because it is difficult to represent an empty location.

Interactions between Maze, Beepers and Robot are not well defined.

This is a simple, straightforward design that makes use of the architecture of the GUI code posted for the assignment.

It's not clear how the Robot has full knowledge of the Maze. I want the entire Maze to be available to the Robot at once so that it can search it for the Beepers.

This specifies private variables even though it is a public specification.

Storing the maze as a three dimensional array seems like it could be confusing to the programmer. Moreover, since maze nodes may be neighbors, keeping information on each wall for each cell ends up storing duplicate data.

Too minimal. Game appears to set up the entire grid of mazes as there is no way to specify walls or submazes. No way to make robot move.

1. They didn't pass the maze to the Robot class and Beeper class so that the paint method won't work.

2. It seems that the getPath() in Robot class can't work, because the Robot class has no idea about what the maze looks like. It should passing the information about maze in the Robot's and Beeper's constructors, such as Robot(Board gameMaze).

Not enough information for design: missing important elements like Maze
Duplicate and modified info from Dr. Dave’s supplied GUI Code
Document format made it difficult to differentiate between methods and to know which comments applied to which methods.

Maze and Robot both need to hold copies of each other. The method of keeping track of walls seems complex, it would be easier to just define edges only between Cells whose connection is not blocked.
The main BeeperHunt class only initializes the maze, robot, and two beepers, and displays the GUI. What runs the game?
The Robot class could be improved if it had knowledge of where the beepers were in the maze.
The structure of this design is very clear and general. However, since the class Piece extends Observable, there may be a class implements Observable. And the code for building may be very long; this may result in a huge class BeeperHunt that is responsible for initializing a maze.

 

Deneb (not chosen)
+ Listeners to perform actions on the Maze when Robot and Beeper change.
- one wall per cell
- Beeper and Robot not explicitly described
The Maze seems to be doing way to much work in this design. For example, it calculates the distance between the Robot and the Beeper. I would rather see the Robot doing a search, calculating the distance between itself and the Beeper.

The purpose of RobotEvent and BeeperEvent classes is unclear.

Needs Robot and Beeper classes. Uses newly defined events and listeners, I think it would have made more sense to use Observable.

The event/listener architecture is really not necessary since this is a turn-based game.

The Robot should have knowledge about Maze, and the calculateDistance() method in Maze should be in Robot, it is the Robot who should know about its strategy to get to the beepers, not Maze.

Deneb This is a quite detailed design. But I can't figure out why listeners should exist because every action of the game occurs in order not by accident. And there are some classes such as class Location may be combined with other classes to make the design more straightforward.
1. The program could probably keep track of Robots and Beepers without having to implement RobotEvent/RobotListener and BeeperEvent/BeeperListener.
2. The Robot has a move() method, but does it have knowledge of the game's Maze?

Some of the variable names are ambiguous (FORWARD, BACKWARD, LEFT, RIGHT)
Missing main() method
Method names “isXxxxExist” are a bit strange, linguistically. Probably should be “xxxExists”

The event handling idea is interesting. I don't think that the description adequately expressed how all the different classes were going to work together. I suspect that if our group tried to implement this design, it would become rather complicated. A more classic approach (for example, an MVC design with Observer / Observable classes) might have been a simpler way to the same end.

This design employs interfaces that listen to events relevant to the Robot or the Beepers. However, it is not clear that one needs to know that the Robot moves up/down/etc., but that this info should be inherent in the method that moves the Robot and in the display class. In addition, the pseudo-code can be made more efficient by not calculating after every step what the next step should be, but rather, calculating the entire path to the Beeper in one step (or on one method). Finally, description of the Path class is missing.

 

Procyon (chosen by one group)
It resembles the plan we had created, and it doesn't have many of the problems described here about other designs. We particularly like how it offers us quite a bit of freedom ( it doesn't specify too much). That said, we do not see a way to decrement or set the lifetime of a Beeper. We also find the use of Board.setWall to be a cumbersome way to get the GameMaze into the Board for drawing.

Good: good construction with a lot of helpful methods
Bad: generate a random maze which can be very hard to code
Bad: Grid class seems to be quite similar as the Piece class

It's obvious that A LOT of work went into this design. The design has a lot of specifications, but having so many specs require the programmer to spend a great deal of time trying to figure out all the details of the entire program. While the guidance is appreciated, listing a large number of methods for some of the classes ends up decreasing the flexibility that the programmer has in implementing the program. Including the UML was a great idea!

Couldn't understand the function of the Grid class, especially the constructor.

Not enough methods: Beeper class only provides a method to get the information from the beeper. How can we change the lifetime of the object?

The GameMaze/StandardMaze/Grid system seems like too many classes doing too little work. Why not consolidate? Also, the maze seems to behaving as both a graph data structure and a two dimensional array.

1. The GameMaze and StandardMaze classes do not have helpful contents. These classes are sparsely described.
2. The GameModel and Robot classes could be restructured - there are better ways to design instead of passing GameModel object to Robot.

This design is thorough and well organized. Having the UML document does help.

A pretty design design description - like reading the sun java language pages.

Surprisingly, has a Piece class and Beeper and Robot classes, but the latter two are children of Object, not of Piece. Piece has to do with drawing something on the game board, while the other two classes just maintain the data for the beepers and robots. Piece is generic and doesn't seem to have anything about drawing a robot that looks different than a beeper. I think this is a hole in the design but fixable by having RobotPiece and a BeeperPiece classes added to the design to come up with different piece shapes. Or maybe just have Robot and Beeper extend Piece. And add class unique drawing info.

The main class is BeeperHunt - it extends javax.swing.JFrame, which is strange, since I don't think we can normally use swing. It tends to be incompatible with what Dave does. I think this should be changed to extend Frame. There is nothing in the description to say why JFrame was selected or what methods or advantages it may provide.

It explicitly calls out Dave's Board, which is good.

Has a GameMaze class that is confusing - sets up a double array of StdMaze, which seems to be a double array to begin with - a double array of a double array? May have meant to say a double array of Grid class.

Has a GameModel class which seems intended to be run as the game running thread, instead of BeeperHunt. Also has the game constants, instead of BeeperHunt. Don't think it's necessary to separate this from BeeperHunt in this fashion, but should be workable.

It's Grid connect method uses another Grid object as a parameter, so a connection can be made between the two simulatanously, which is good. May end up duplicating making connections as each of the grid locations are processed. No way to break a connection once made. But shouldn't be neccessary.

Has class StandardMaze - again issues with GameMaze need to be worked out.

Needs more GUI details, like panel classes, etc.

Needs more detail on drawing pieces since I think Dave's class only draws the walls of the Board.

Robot and Beeper data is public so no setter methods, but there are getter methods, not sure why.

Beeper and Robot motion is implicit in the gameturn methods, since public variables, the methods can be written to change locations as needed.

Too minimal. Need a method to calculate the distance. Robot move() method is undefined for the direction. Where the strategies come from is unknown. Robot has no method to collect the beeper.

 

Regulus (not chosen)

This design probably tends to use Model to control the whole program. It doesn't separate Robot and Beeper out. Not our taste.

It would be better if Robot and Beeper are independent objects.

Parameters like time need to be specified in the design.

The advance() method of the Model seems to compute the shortest path at every step - this may not always be necessary. Does not specify how exactly Beepers and Robots are implemented. It suggests a couple of approaches, but does not mention the tradeoffs.

Our main complaint with this design is that all of the model has to be coded into one class (the Model class). We preferred a Design with separate Robot, Beeper, and Maze classes. This was our second choice because it's a very clean design. Sparse, generally, we felt is good for versatility. This design was incredibly sparse, possibly a little too sparse.

Although it is stated that main function runs the application via an instance of BeeperHunt, one wonders how! There are no other methods except the constructor in BeeperHunt.

How the Robot and the Beepers are represented is not clear.

It appears that the entire maze is stored somehow by Node, but in order to get any information about the maze, one must step through the entire thing.

There no clear way to represent the graph in 2D space, so it is not possible to represent the maze in the GUI without major modification to the model.

Brilliant. Absolutely brilliant. This design was subtle without being esoteric; it was a study in elegance, like a fine symphony or a swooping falcon. If Isaac Newton came back to life and decided to write a BeeperHunt specification, it would probably be lot like this, if perhaps a bit wordier. We imagine that, in the future, when most traces of our civilization have long been buried under innumerable sands, poets will still sing odes to this BeeperHunt specification. Truly, the authors must be gods among men.
[Note: This review may be somewhat biased. :-)   --Dave]

- no Robot/Beeper class, more objective-oriented way should be simpler
- new Maze button --> hard to do
A clear overall architecture is built, and model/controller, observer/observable are well distinguished. How to build the maze is not shown.
The outline of the design is clear but it lacks the object of beepers and the Robot.

 

Rigel (chosen by one group)

There was a lot of creative use in this design. Having the nodes specified by a number that can be broken down into the rows and columns is a cool approach. While overall, the approach was interesting, there was some limitations for the programmer to deal with - mainly the lack of Beeper and Robot objects.

Good delegation of responsibility to Robot and Beeper and good separation of the GUI from the model components.

The design is a little hard to understand and appears a little disorganized in places, so it might be some work to figure out everything that’s going on. But by and large, the basics appear to be there.

Strange: labeling the vertices with a manually constructed name. Seems like there has to be a better way.

The purpose for naming the nodes is not clear. The location is enough. And besides, the name has to be decoded to location (row and column) and no method has been provided for that.

The class Vertex is used but not defined in the design.

Robot and Beeper could have a MazeCell variable to store the current position, rather than MazeCell having boolean variables hasRobot and hasBeeper.

The design is very clear and specific. However, representing the maze using Matrices might not be the most intuitive or efficient technique to implement.
Needs to place Robot and Beeper. "Adjacency" methods hard to understand.

Maze has a 2D Grid-like structure by nature, use only 1D array to store it and all the naming scheme makes it complex and against maze's natural structure. Use 2D array to store mazeCellList might be a better idea.

Piece extends Observable, there is no Observer defined in this design.

A very well thought out design. The setName method could be revised to give 0412 if row = 4 and column = 12, as opposed to 4012 for clarity sake;
Well thought out and detailed design. We liked the use of the Observer pattern which makes notifications of events much cleaner. Doesn't specify very clearly what class is responsible for advancing the robot and how this happens. Overall a workable design
Complicated because there’s too many different data structures it’s not clear the purpose of each.
For what it's worth, we also liked Arcturus and Rigel.

 

Shaula (not chosen)

The logic contained in the Walls class could just be implemented within the GameBoard class, since GameBoard appears to create the maze for the game.

The Display class looks to be handling game threads, which is not necessarily needed for this particular program.

There is no public method for the Robot to know how many turns a Beeper will last Walls class is strange. Unclear what constructor parameters should denote. Perhaps they were supposed to be boolean?

Strange mix of constant names: NORTH/TOP, SOUTH/BOTTOM, etc.

It's weird to let move() method in BeeperHunt class. Anyway, BeeperHunt can't not move.

Robot should know the maze.

The relationship between Walls, GamePiece, and GameBoard was confusing. We had trouble really figuring out how mazes are structured in the design.
Lacking listeners and inheritance. GUI is a lot of walls and then a game board with no way to specify submazes.
The GamePiece class has a misleading name. The mechanism by which the Robot gets the locations of the Beepers is unclear. BeeperHunt claims to place Beepers and Robot into the gameBoard, but there are no mechanisms for this placement to occur.
It's nice there are classes for controlling (BeeperHunt) and for viewing (Display), but there seems something overlaps in class GamePiece and class Wall.

The Robot constructor should get the entire maze, not just subrow and subcol.

Why do we need getRowLocation and getColLocation for Robot and Beeper? Why not just getLocation()?

RemoveBeeper() in Beeper class?

Walls not clearly indicated

Display part should be in BeeperHunter

 

Vega (chosen by one group)
It's really a very thorough and detailed design. However, we can't figure out the correlation between some classes like Square, Point, Radar, and Maze. Class Maze, class Square, class Point are all responsible mainly for drawing the walls, none for building the graph. Class Robot chose a new position based on its knowledge of its "host" Square's wall data and on the information about beepers at sight it gathers not based on the graph searching.

The documentation for the classes often describes implementation details that would be better left to the programmers. The Maze class combines elements of the model and the view - two parts that should be more distinct. The Radar class is not mentioned anywhere but in its definition. How does it interact? It doesn't seem to represent a part of the simulation as it has been described in the assignment.

Vega: The search() method is unclear and too general (better version would be to pass robot and beeper parameters). The separation between GUI and the movement robot would be tightly coupled if the method is implemented. Separation of Model/Controller by using Observer/Listener would be nice.
Square and Point seem like they could be consolidated into one class.

Why a separate Radar class? Why not hide this functionality in BeeperHunt?

Piece should implement, not extend, Observable.

Separate classes for Radar and for Point are not necessary.

The flow of the design is not immediately clear, and it is not elegant.

The main criticism of this design is that there isn't a clear division of labor - many tasks are split up among different classes. BeeperHunt starts the program, but is also a GUI class, as is the Maze, however everything observes the Robot to move the game forward. It may have been easier to implement if classes had more dedicated classes, such as GUI and running the game, rather than distributing various aspects of these tasks.

The other con with the design was that there seemed to be too many classes. We didn't see why there should be an Occupant Interface and an Abstract Piece class, both of which describe various move methods, which is fine for the Robot, but unnecessary for the Beeper. Perhaps both of those could have been merged together, describing only what is useful to both Robot and Beeper Also it seemed Point and Radar could have been part of other classes.

Beeper shouldn't implement Occupant since Beeper doesn't move.

The Board class used in Piece is not defined. There is no Observer for Piece in this design.

Creating a Maze is more complicated than described.

Class Radar is useless, Robot has full knowledge of the Maze.

Too complex: The design for this project should be simple and easy to follow, but this one is not.

Unclear structure: It looks like this design includes a GUI and Non-GUI part, but both of them are mixed up together. Also, from the design we do not know how to run the GUI with the Non-GUI part.

Vega has a lot of detail for all the stuff not involving drawing the screen - even to the point of too much, since I think there are some methods we wouldn't bother with. Has a lot of classes and methods spelled out for the part of the design not dealing with actually drawing the Canvas. Has a Maze class that could be intended for this but it extends panel not Canvas - not clear to me what was intended here. And I think Dave's Board class is more appropriate, and this isn't referenced.

Has a changeBeeper method talking about removing a Beeper, but has a moveBeeper method, that just changes the location of a beeper. I like the idea of just changing the position of a beeper, just like we change the position of a robot, then resetting the timer, and don't see a need to ever use a method that removes a beeper and creates a new one - no need for the memory and garbage collection issues. But not a big deal either way.

Has an Occupant interface with a method chooseNewPosition() that is supposed to move pieces, but no direct info on the existence of a separate Maze or other pieces so not sure how its supposed to work.

Has an abstract Piece class that implements Occupant. Occupant has a changePosition(Square newHost) method while Piece has Point moveTo (Square s) - seems redundant.

Robot constructor not given (there is an abstract Piece constructor but I suspect that's not good enough). Both Robot and Beeper have a paint method - first if common to both, should be in a parent class or interface, second, I think paint is more appropriate for a Canvas class.

Has Squares with individual wall settings - this leads to the potential situation that with two squares next to each other, the north one could have a South wall, while the south one doesn't have a North wall - which is an unacceptable situation. And no exception class has been created to be thrown when this situation exists. Best to use Dave's Board class and have it keep the wall info based on the node adjacency info.

Has a Point class to maintain x, y coordinates as paired values - I like this, I used something like this in my Turtle design - easier to have a method return a Point than to call two methods to get an x and y individually

Has a Radar class - this is confusing. It has a method to find the nearest beeper (the metaphor is a radar extending out from the robot position I think, and the Radar object is created with Square as a parameter (Square is the game grid position class, sometimes called node, or cell in other designs). So I guess a radar object is created using the Robot Square location, but this is unclear, and what a Radar object actual is is unclear (a tree with the input parameter node as the root? perhaps)

Has assumptions, like sub mazes being 4x4, in the descriptions, but the class or methods parameters don't force these assumptions to be followed, which is good where the assumptions are wrong.

GUI and Drawing classes, methods and data are lacking.