Skip to content

Latest commit

 

History

History
77 lines (51 loc) · 8.48 KB

F17_lab03.md

File metadata and controls

77 lines (51 loc) · 8.48 KB

Wei Tung Chen github: lleeoochen

Nicholas Duncan github: nduncan1014

Mentor: [email protected]

(a) (20 pts) A brief description of the project. Here, I’m looking for a short description: probably 1 sentence, 2-3 at most.

  • This is a remake of the original Pac-Man arcade game which involves moving a character through a maze of pellets whilst avoiding the enemy ghosts. The goal is to collect all of the pellets without losing all lives.

(b) (20 pts) a set of user stories (as a X I can Y so that Z) that describe what the current software in its current state can do.

  • As a player, I can press arrow keys so that pacman moves around the maze, and eat pellets, powerups and avoid ghosts. As a player, I can choose co-op mode to have two pacmans on screen.
  • As a player, I can choose versus mode, which allows users to control both pacman and ghosts. As a player I can enter in my score after a game finishes so that I can keep track of my high scores.
  • As a developer I can run the level editor and create a new level so that players can play on a new map.

(c) (20 pts) a brief assessment of whether the software runs or not. If it runs, briefly describe what it does,

  • The software runs. It launches a Java GUI window with a menu list. User can choose which game mode by pressing the corresponding key. There are game instructions located in the help menu as well.
  • Player moves the Pac-Man character with the up-down-left-right arrow keys. Score is tracked during gameplay and on conclusion a new window appears that contains a text field for entry of name.

(d) (20 pts) a set of user stories (at least 2, but you are encouraged to write up to 4 or more if you can, as many as you think is reasonable) about features that COULD be added to the software to make it more useful, fun, better, etc.

  • As a player, I can press a button so that the game window resizes. As a player, I can toggle a button to listen to Pacman music while playing the game.
  • As a ghost, I should be able to stay in the ghost house for a few seconds before coming out to haunt pacman so that the game feels more like the original.
  • As a ghost, I should equip a pacman tracker with an advanced machine-learning algorithm so that the game difficulty can be increased.
  • As a player, I can shop the pacman shop for changing character colors and special effects.
  • As a developer, I should play the game in debug mode, where pacman can’t die so that I can test level design and game mechanics.

(e) (20 pts) An assessment of the current quality of the README.md. What information could be added to make it easier for the next generation of folks maintaining this code to use the software, and/or maintain the software?

  • The quality of the README.md currently does explain how to run the program. It also contains tips for navigating the source code files.
  • However, it would be also nice to include a diagram of how classes are related to each other.

(f) (20 pts) An assessment of the current state of the build.xml file. Are there targets that need descriptions? Is there old legacy JWS stuff that needs to be removed? (More on this below).

  • The current state of the build.xml file is fine. Every target is well documented. It appears to have all essential targets implemented and ready to go.
  • The only thing is that several descriptions may need minor updates but overall it looks good.

(g) (20 pts) An assessment of the current “issues”. Are there enough issues that you could earn 1000 points by working on this project? Are the issues clear in terms of what the expectations are?

  • Currently, the total issue points only add up to 800 points. But we have spotted more issues that can potentially be added, which will be enough eventually. The past issues are clearly explained with expectations.

  • Potential "issues"

    • Things to Change for Pacman
    • PacMan.java -> Game.java
    • PacPlayer.java -> PacMan.java
    • GamePlayed.java -> GameInfo.java
    • Untrack args variable (not used) (Game.java)
    • Replace game mode selection with buttons (Board.java)
    • Create all characters under gameInit. No hard-coded characters outside the function. (Board.java)
    • Board.java is handling too many tasks outside of boards. Some should be moved to Game.java.
    • All custom configuration should NOT go into individual actor class. Those should go into either Game.java or gameInit() in Board.java.
    • For example, PACMAN and MSPACMAN should not appear in PacMan.java. File paths, colors, dimensions should be constants!

(h) (20 pts) A list of additional issues that you may have added, if any. For each, a link to the issue is good enough.

(i) (100 pts) Most important: an assessment of the actual code. Write a bit about how the code is organized. Are the purposes of the classes, and their methods clear? Is it obvious how the classes relate to one another? Is the code easy to read and understand? If you had to give someone else that was going to work on the code just “one screenful of text” to help that programmer get up to speed quickly, what information would you convey?

  • The PacMan.java file contains the main method of the game and is the heart of the game. It creates a PacMan object which sets up the frame and level for the game.
  • This class also allows command line arguments for testing purposes. This class appears to be initializing the game and running the main method.
  • The next important class of the game is the Board class. This class contains all of the main game logic such as PacMan’s movement, the ghosts movement and interactions, music, gamemodes, game states (intro/playing/paused/help), and collision detection. Essentially it contains all the important game features/logic. This class extends JPanel and gets added to the PacMan JFrame as a component. The purpose of this class appears to be running the game/ logic of the game. This class contains many methods, but it appears that most if not all of them come with thorough javadoc and the variable names appear to be descriptive. The next important class would be the Grid class. This class is used for map layout and has methods to load level data and spawn in random fruits. This class is utilized in the Board class to set up levels.
  • The board class draws its data from the GridData class which contains information like grid size, fruits locations, and other various data pertaining to the grid. The ghost class contains the code on the enemies. This class gets used in the board class as an array of ghosts which end up chasing the PacMan object. The next important class is the PacPlayer class. This class appears to control the actual PacMan object on the screen. It contains data such as lives, animation, movement, direction, and speed. This class gets utilized in the board class to make the player controllable PacMan character.
  • Next we have a leaderboard class. This class contains the code for the implementation of the leaderboard. It has methods that allow a player to see overall top scores and the top three scores for a specific player. This class gets utilized after the player dies so they can see the top scores.
  • The editor package consists of three classes - PacManLevelEditor, GridDataConversion, PacManLevelDisplay. These classes are all working together for creating and editing the game levels. These classes are useful in the grid class and the board class.

(j) (40 pts) Related to code quality, but factored out into a separate issue because it is so important: how is the test coverage? Are there JUnit tests at all? If so, how much of the project is covered by testing? Are there opportunities to expand test coverage, and if so, how would you go about it?

  • The test coverage is not enough. There are JUnit tests for GamePlayed.java and Leaderboard.java. However, none of the other classes have JUnit tests associated with them.
  • We can improve the JUnit tests coverage by testing individual functionality of all actor classes. For example, when resetPos() is called for PacPlayer instance, its position should changed back to the original one after the call. Additionally, it would be helpful to add tests to the board class as most of the game’s logic exists within that class.
  • Adding JUnit tests to the board class would be useful for debugging new content added to the game at a later time as most of the changes will have to be added to the board class at some point.
  • Tests to determine whether elements of the board such as ghosts and ghost location function properly would be helpful.