OOGASalad : Midpoint Demo

The best presentations come off as effortless. And it’s not because they are spontaneous. Quite the opposite, actually. They are meticulously prepared. — Veronika Riederle, Demodesk

This demo is intended to show your team's progress, justify your design choices, and get feedback by presenting your ideas in enough detail that other teams can comment on your work. It is also a chance to practice giving a public demo before the final.

To prepare for the demo, the master branch must be frozen, i.e., no new features should be added, for at least 12 hours prior to the start of class to prevent a last minute bug or commit crashing the project. Instead, focus on bug fixes, small refactorings that solidify your design, and building example game(s) to show off.

Submitting your Work

Use GIT to push any materials specifically for your presentation in the folder doc/presentation_midpoint to the master branch of the provided, shared, oogasalad_teamNN repository hosted in the course's Gitlab group.

Include any 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.

Specification

Team Requirements

Your presentation must be limited to 30 minutes with everyone from your team expected to be present and say something. Each team should have a primary spokes-person, i.e., a master of ceremonies, but each team member should have a chance to present.

Start by presenting your team's goals for the project, focusing on how you are managing the project regularly to ensure it is finished and everyone is contributing:

• what genre or game are you focusing on and what commonalities and differences have you identified
• what features (including optional ones) you are planning to work on
• what you prioritized accomplishing for each Sprint

Then present your team's design, focusing on the APIs and their behavior instead of implementation decisions and class state:

• describe your current design and framework goals: what is expected to be flexible/open and what is fixed/closed
• provide an overview of the project's core parts: what is each responsible for, how does it depend on other parts, what does it encapsulate, and how can new features be plugged in to it
• describe two APIs in detail:
  • what service does it provide?
  • how does it provide for extension?
  • how does it support users (your team mates) to write readable, well design code?
• describe two Use Cases in detail that show off how to use each of the APIs described above
• describe one alternative design considered and what trade-offs led to it not being chosen

Finally, present your project's current functionality, focusing on telling stories about how you are creating flexibility for game variations:

• run the program from the master branch through a planned series of steps/interactions (including showing how bad data or interactions are handled — if any are yet)
  NOTE, as each feature is shown, someone on the team should briefly describe how work they did over the past week relates to it
• show any data files that have been created and describe how they are used within your program (focus on the file content rather than the code that uses it)
• show a variety of JUnit and TestFX tests and discuss how comprehensively they cover the feature(s) and why you chose the values used in the tests

If you cannot attend the presentation, you are expected to record a video about your part of the project.

Individual Requirements

When you are not on the team presenting, you will provide feedback that is focused on the content rather than the quality of the presentation itself (e.g., things you did not understand, felt were incomplete, or ideas you had to improve their work). You are especially encouraged to share things you intend to borrow for your own team (from their project design or features to their presentation style or teamwork ideas).

After each presentation, a few people will be asked to share their feedback synchronously while the remainder of the feedback will be sent electronically.

Resources

Giving demos is a skill you can work on!

Good presentations are practiced, presenting features in a planned order and using specific input values, rather than just capturing a team meeting — you do not have a lot of time to fit in everything asked of you. Beyond that, here are some slides and exemplary professional demos to help you choose how to present your content:

• Slides with DOs and DONTs advice from my project course
• 7 Tips for Pulling Off a Great Demo Presentation from Lifesize
• 20 Outstanding Examples of Software Demos with explanations and tips (at the bottom)
• Older, longer, classic demos:
  • Introduction to the Wolfram Language, Stephen Wolfram, 2014
  • Original iPhone demo, Steve Jobs, Apple 2007
  • The Mother of All Demos, Douglas Engelbart, Xerox PARC demo 1968 and its lasting impact
  • Sketchpad demo, Ivan Sutherland, MIT PhD Thesis demo 1963 (the first interactive graphics program, non-procedural programming language, and object oriented software system)