M16_lab02.md

Steven Fields: SElegans Will Bennett: MadRubicant

###a. This is a game that is meant to be an exact replica of Pokemon. You play as Professor Oak and walk with Pikachu around the map.

###b. As Professor Oak, I can walk around with the arrow keys, with my Pikachu following me. I can open secret paths and interact with legendary Pokemon.

###c. The game runs, and allows you to walk around the map and find different secret paths that you interact with.

###d.

1. We would like to add the ability to decribe maps in text files that allow easier map creation and diversification.
2. We would like to add the ability to walk into buildings.

###e. README.md is fairly extensive, it is descriptive about what each class does and how to run and play the game.

###f. The build.xml file is readable, but there is some legacy code that needs to be taken out and replaced.

###g.

1. Professor Oak's hair clips when walking along the top of the map towards the right. We believe this is a render order issue.
2. Add more buildings
3. More ways to play game
4. Add continuous background music
5. Walking along bottom of lake turns tiles to grass
6. Change characters
7. Add ability to walk inside buildings
8. Add ability to talk to sprites
9. Fix package structure
10. Add new map We think this is more than enough issues to add up to 1000 points. The issues seem to be mostly with adding new features, but the issues we added below address serious architectural concerns.

###h.

1. Professor Oak turns into Pikachu when he walks into him. Pikachu is cloned when Professor Oak walks on top of Pikachu, then off of him.
2. Tiles on the bottom and right aren't always rendered.
3. GameLogic is too big and needs to be broken up
4. The render engine and the game logic should be decoupled
5. Lots of unnecessary variables and classes
6. Large buildings dissapear when their center goes off screen
7. There are public static getters for public static variables

###i. The code is not organized well. Method names are often clear, but the methods are often too long and complicated. A lot of these methods should be factored out into other methods or put into other classes to be used there. There is numereous methods that are long chains of if else statements. More comments should be added for methods where it is not intuitive what is going on. As well, the classes are not decoupled well, so they rely on each other too much for new code to be written easily. Methods can also be turned into data for simpler code. Many, many methods rely entirely upon global side-effects. For an example, see the Texture constructor. It takes the tileset's name as a string, accesses the global variable renderer in GameMain, and gets the tile from that.

###j. There are no tests. We would probably test internally each method as we go, as we see fit.