Presentation Notes

Your presentation should be about 20 minutes long and can be done synchronously using Zoom (recommended) or recorded and combined into a single shared video. As if this were your Final Exam, each team member should clearly contribute during the presentation.

You are expected to practice delivering the presentation, including the specific order and values included when running your program, since it is not a lot of time to fit in everything asked of you below. Fixing small bugs (and tracking those bugs) you find as you practice using your app for the demo can still be helpful but, in some cases, it may be better to find a workaround that can be practiced and used during the demo instead. Your demo will be much better if it shows everyone's parts working together as a single program, launched once during the presentation, rather than multiple separate runs.

Functionality. Show off the features of your running program:

Run the program from the master branch through a planned series of steps/interactions that shows at least the following features:
choosing a game to play, playing a game, winning or losing a game, choosing a different game to play and starting that one
choosing different color themes and languages
if possible, playing two different games at the same time or saving a game and restarting from that point
any optional features implemented
anything else that makes your project unique and interesting
show an example of each kind of data file used by the program and describe which are essential (e.g., internal resources) and which can be user created (e.g., external or example data)
show three examples of making a change in a data file and then seeing that change reflected when the program is run
show a variety of tests (including both happy and sad paths for both the backend and frontend) and verify they all pass
Design.

Revisit the design from the original plan and compare it to your current version (as usual, focus on the behavior and communication between modules, not implementation details):

1. Run a game of texas hold em all the way through, then load in a new game at the end. Show how language/color preferences affect the game here too. 2 mins
3. Show error handling by attempting to raise by 50000 (more than player has)
4. Show how players can reach the raise limit in a round by raising 4 times
5. Continue to check/call until the game ends and a winner is chosen
6. Show the player profile screen, show that the data makes it into our firebase console.
2. Run a game of 5 card draw to show the discard feature 1 min.
4. Make it to the discard round and have each player discard "1,2,3" and show that they got their first three cards replaced
5. Show error handling by attempting to discard a player's entire hand ("1,2,3,4,5")
6. On the next round, have everyone but one player fold to show that win condition
3. Run a game of omaha with strategy players, show how the multiple workspaces feature works. Use the save and exit button.
6. Montana.
4. Generate a new XML file with the front end form, show that it can be loaded in.
8. Close/reopen the program at this point and show that you can both a) load in the custom game and b) load in the saved game state
5. Talk about the data files. Show how changing numbers in the rounds, using a bad xml file, and changing the bet manager changes play.
9. Change values in texasholdem.xml - could even add another round
10. Showcase bad xml file and show error handling
6. Run all the test cases, talk about them.
10. ActionTest - happy and sad paths

Revisit the design's goals: is it as flexible/open as you expected it to be and how have you closed the core parts of the code in a data driven way?
- good: `Round` objects make building a game round-by-round flexible
- good: many inheritance hierarchies at play (`WinManager` in Data, `PokerAction` in Engine, `SceneElement` in View), using reflection in the xml parser makes it easy to instantiate different objects from the same inheritance hierarchy and pass them to the engine so that we can use the strategy pattern
- lacking: game flow is largely hard-coded in `GameLogic`, could improve by encapsulating portions of the game in classes

describe two APIs in detail (one from the first presentation and a new one):
show the public methods for the API
how does it provide a service that is open for extension to support easily adding new features?
how does it support users (your team mates) to write readable, well design code?
how has it changed during the Sprints (if at all)?
1. ActionManager: public methods enable adding actions (following Decorator design pattern), providing service of collecting possible actions and handling user selection/input; provides service that can handle subclasses of PokerAction without modifying other code; was refactored for Complete by unifying how BetActions and CardActions handle user input (generic List of Objects)
2. GameDataInitializer: part of the data external API, has two public methods, loadNewGame and loadExistingGame. this API is important because it completely encapsulates the XML parser functionality into its own module, and no other APIs have to know how the parser works. this means that even if we decided to completely rewrite the parser to read from csv files or json data instead, no other code in the project would have to be changed. It supports good code because it is a very simple class, and each function has a very clear name. It is used when the user selects a new game from the list on the main page, and when the user decides to load in a previous game from a saved state.

show two Use Cases implemented in Java code in detail that show off how to use each of the APIs described above
1. Use Case #1: Showing the user available betting actions

In `GameLogic`:

pokerGame.getPossibleBetActionsForPlayer(PlayerInterface currentPlayer);

The `BetManager` determines which actions are available for `currentPlayer` and calls, for example:

actionManager.addAction("Fold");

`GameLogic` then takes the returned `ActionManager` object and sends the possible user actions to the View:

actionManager.getListOfUserActions();

2. Use Case #2:

describe two designs
one that has remained stable during the project
one that has changed significantly based on your deeper understanding of the project: how were those changes discussed and what trade-offs ultimately led to the changes
Team.
1. One that remained stable: the UI of the view (aka the components on the screen). Even though the view code/look of the game changed over the course of the project, the core functionality remained the same (status bar, player cards, community cards, etc.)
2. One that changed significantly: how we handle game logic. We started with `ActionPlay` in the view, but then refactored/moved most of the logic to `GameLogic` in the controller. These changes were discussed during a refactoring-specific meeting. The change had many benefits; we were able to separate the running of betting rounds from the view. One downside was that creating a controller package required a lot of methods for communicating between the controller and the view, although separating logic from the view is still a net positive.

Present what your team and, you personally, learned from managing this project:

Contrast the completed project with where you planned it to be in your initial Wireframe and the initial planned priorities and Sprints with the reality of when things were implemented
- Completed project did not hit all goals we put in our original plan, but we were more focused on properly designing the core functionality
- Some features, like the controller, were implemented later than expected
- Networking was not successfully implemented, although firebase was used

Individually, share one thing each person learned from using the Agile/Scrum process to manage the project.
- Patrick: weekly presentations were an effective way of measuring our progress and collecting instant feedback
- Livia: it was helpful to manage a large project by breaking it down into sprints and focusing on a handful of featues at a time
- Rachel: it was helpful to be able to watch others presentations and decide what features of theirs could be cool to implement and what designs we would not want to implement
- Martha : I think the process of developing the view inherently follows an agile process because you have to take a step back after each new feature was added to see how it showed up on the screen and whether its functionality was as expected.
- Montana: Having to explain how our project worked to other teams really exposed what worked well and what didn't, and since it was stages it was really helpful for setting goals for the next week

show a timeline of at least four significant events (not including the Sprint deadlines) and how communication was handled for each (i.e., how each person was involved or learned about it later)
1. Planning meeting: the first weekend after the project was assigned. We all met on Zoom for a couple hours with ideas on how to structure our APIs. We also split up the components of the project
2. Integration of parts: the night before the Sprint 2 deadline, a representative from each part of the project attended a Zoom meeting. We went over what we needed from other components in order to integrate the back-end and front-end
3. Last minute bugs: the day of the Sprint 2 deadline, we realized that we had some left over bugs that needed to be ironed out before our presentation. We were able to divide up the work over slack so that everybody was in the loop about what was happening and we could get the pieces done in our own time throughout the day.
4. Refactoring the controller: we had a meeting that extended late into the night in order to move game logic from the view to a new controller package. Coding was done collaboratively using Code With Me and pair programming. The other team members were informed of the meeting's purpose/results on Slack

Individually, share one thing each person learned from trying to manage a large project yourselves.
- Patrick: integration early is key, and perhaps the most important part of the project
- Livia: distributing the workload evenly is very important, as it's easy to misjudge how long each feature is going to take
- Rachel: trying to find time to meet as a group when everyone has different times they are most productive can be difficult and compromises often have to be made (staying up later than usual)
- Martha: Even though we divided up the work for the project, in order to get the program completely working, we still needed to know general details about how their code work to connect everything.
- Montana: It's really important to be flexible and willing to work on parts of the project that may not come naturally to you to or be the most exciting

describe specific things the team actively worked to improve on during the project and one thing that could still be improved
- We tried to improve the distribution of work after the first week, with some team members picking up features that they initially were not assigned to
- One thing that could still be improved: If we had more time, we would have liked to implement features that replicate the experience of playing poker in real life. So we would have added an option to hide your cards and added a table setup for the game.

Individually, share one thing each person learned about creating a positive team culture.
- Patrick: spending at least a couple minutes of each meeting to check in on how people are doing
- Livia: being willing to help someone debug or figure out a design issue is a good way to support each other
- Rachel: being available to hop on zoom in the slack at a moment's notice can be very helpful
- Montana: especially at the end of the semester everyone has a lot going on so it's important to be flexible and supportive of your teammates
- Martha: Being realistic about what features or tasks are doable so tahat the rest of the teamwork can be planned around it.

revisit your Team Contract to assess what parts of the contract are still useful and what parts need to be updated (or if something new needs to be added)
- The parts about deadlines and communication were relevant throughout the project
- Clearer guidelines on testing code would have helped us keep on track

Individually, share one thing each person learned about how to communicate and solve problems collectively, especially ways to handle negative team situations.
- Patrick: spend more time listening than blaming
- Livia: disagreeing on design decisions is a productive conversation, as long as everyone's ideas are treated with respect
- Rachel: learned that solving problems is a lot easier when you are in constant communication throughout the project,
- Montana: don't wait until deadlines are approaching if you have a concern, ask about/bring it up as soon as you have an issue so that when you resolve it there's less stress involved
- Martha: Integrate all of our code earlier than the night is due so we can have more time to debug things.

As a reminder, this presentation should show evidence of thought and learning about the process of doing something uncertain and challenging: the planning, designing, and implementing of a complex team project. It is unrealistic to expect everything went perfectly so you should not try to present it as such. For example, it is certainly nice if parts of your API did not change during the project or if everything was completed on time and in the correct order, but it is unlikely and often more can be learned dealing with adversity. So please take this as an opportunity to reflect on what you learned (about both what went well and what went poorly) rather than trying to pretend it went much better than it did.

Put any materials specifically for your presentation in the folder doc/presentation4, either as code, images, UML diagrams, or written text, using Markdown, Javadoc or a wiki page on Gitlab. PowerPoint slides are discouraged because they are completely separate from the project and unlikely to be maintained even if they are added to the repository, but here are some tools to convert Markdown to a slide style format.