Course Assessments

Week 4 & Week 5 — Alpha (40% total)

• Code submission: Friday Week 4: 14 August, 23:59 [Individual submission]
• Presentation: Throughout Week 5 (day/time will be announced in Canvas) [Individual presentation]
  • See the Canvas announcement for the schedule and an explanation of how it works.
• Reflection after Alpha: End of Week 5 [Individual submission]

Marking details

Week 8 & Week 9 — Beta (40% total)

• Code submission: Friday Week 8: 25 September, 23:59 [Group submission]
• Presentation: 28 September–2 October (day/time will be announced in Canvas) [Group presentation with an individual engineering component]
  • See the Canvas announcement for the schedule and an explanation of how it works.
• TEAMMATES contribution questionnaire: End of Week 9 [Individual submission]
  • The questionnaire will be released after the Beta presentations. Check your email.
  • You must complete the questionnaire. Failure to complete it will result in a deduction of 5 marks from your individual Beta mark.
• Reflection after Beta: End of Week 9 [Individual submission]

Marking details

Week 11 & Week 12 — Final (18% total)

• Code submission: Friday Week 11: 16 October, 23:59 [Group submission]
• Presentation: 19 October–23 October (day/time will be announced in Canvas) [Group presentation]
  • See the Canvas announcement for the schedule and an explanation of how it works.
• TEAMMATES contribution questionnaire: End of Week 12 [Individual submission]
  • The questionnaire will be released after the Beta presentations. Check your email.
  • You must complete the questionnaire. Failure to complete it will result in a deduction of 5 marks from your individual Beta mark.
• Reflection after Final: End of Week 12 [Individual submission]

---

Alpha Marking Details

Alpha will be marked out of 40 marks, with the following components:

1. [5 marks] Code Style:
   • This will be marked automatically by extracting your GitHub repo.
   • According to the Java Code Conventions specified for Alpha.
2. [2 marks] Git Etiquette:
   • This will be marked automatically based on your GitHub commits.
   • According to the Git Etiquette specified for Alpha.
3. [4 marks] Presentation Professionalism:
   • Turn on your camera (3 marks).
   • Introduce yourself and communicate professionally (1 mark).
4. [28 marks] Demo:
   • Functionality demonstrated (18 marks).
   • Engineering questions (5 marks).
   • Overall client impression (5 marks).
   • See the detailed rubric below.
5. [1 mark] Reflection:
   • You will use Co-Thinker for this. It will be released after everyone finishes their presentation.

Alpha Presentation Essentials

The Alpha presentation will take approximately ten minutes and will follow the same structure for every student.

See timetable

You need to complete the following preparation before your presentation:

• Ensure you have the latest version of Zoom.
• Ensure you have tested that another participant can take remote control during the Zoom call, as the client may need to run your app themselves if it crashes on their system. Refer to the official Zoom documentation and test this before your scheduled presentation. macOS users may need to complete additional permission steps.
• Make sure you have also already tested your mic and camera beforehand.
• Join the Zoom link 10–15 minutes before your scheduled presentation time. Don’t be late.
• Make sure your Zoom name is the same as your name as shown in Canvas.
• You will be moved to a breakout room to share your screen.
• Have both your application and the relevant source code ready to show. Do not use slides.

Presentation structure

1. Greeting and setup
   • Introduce yourself the client will share their screen.
2. Demonstration 1: the client plays — 2 minutes
   • The client takes control and plays oen round of the game.
   • You should remain silent while the client is playing unless the client asks you a direct question.
   • The client should be able to understand how to interact with the application without directions from you.
3. Demonstration 2: the student demonstrates — 2 minutes
   • You share the screen and demonstrate the application yourself playign another round of the game.
   • Talk while using the application and explain the relevant design decisions as they appear in the interaction.
   • Where practical, demonstrate a different intervention or outcome from the one seen in Demonstration 1.
4. Client clarification questions — 2 minutes
   • The marker remains in the role of an Insight Investigations client.
   • The client may ask you to clarify the scenario, player experience, or design decisions.
   • Answer for a non-technical client and focus on the product and its value rather than implementation details.
5. Engineering questions — 4 minutes
   • The marker will clearly switch from the client role to the lecturer/TA role.
   • Be ready to show the relevant prompts or source code while sharing your desktop. The lecturer/TA will select one or two questions from the following published bank, depending on the time available:
     1. Show where the LLM call leaves the JavaFX Application Thread by using a JavaFX Task, following the approach taught in class.
     2. Show how your Java code passes the conversation state from the earlier epoch to the later temporal version.
     3. Show the prompts you wrote for the two temporal versions and briefly describe them highlighting their differences.
     4. Show a part of your code that you are particularly proud of and briefly explain what it does.
     5. Show how your application moves from the investigation phase to the intervention-selection phase.
     6. Show one meaningful change you made to the starter code and briefly explain why it was needed for TimeMystery.

Alpha Demo Rubric — 28 marks

The two demonstrations and the follow-up questions provide evidence for the rubric below. The demonstrations do not need to expose every behaviour naturally: the student-led demonstration can be used to show required behaviour that did not occur while the client was playing.

Functionality demonstrated — 18 marks

The functionality mark assesses how completely and correctly your application implements and demonstrates all Alpha requirements explicitly written as must or must not in the project handout. The project handout is the single source of truth for these requirements.

Requirements described as recommendations, examples, or open design choices are not assessed as functionality requirements. Partial marks may be awarded where a compulsory requirement is implemented but incomplete, inconsistent, or affected by a defect.

Engineering questions — 5 marks

The lecturer/TA will select one or two questions from the published question bank. Marks are based on your ability to locate the relevant prompts or code and briefly explain what they do and why. Partial marks may be awarded for incomplete explanations or partially relevant evidence.

Overall client impression — 5 marks

This criterion concerns the client’s experience of the functioning product. Graphic polish is not required and is not assessed independently.

Marks	Descriptor
5	The application is immediately understandable and easy to use without coaching. The scenario and interactions form a highly coherent experience, and the student clearly relates thoughtful design decisions to the needs of Insight Investigations.
4	The application is easy to understand and use with only minor friction. The experience is coherent, and the student gives a clear explanation of its value.
3	The core experience is understandable and generally coherent, but there are some usability problems.
2	The intended experience can be identified, but substantial usability or coherence problems make parts of it difficult to complete or understand.
1	The application provides very limited evidence of an understandable, coherent client experience.
0	The application does not provide an understandable client experience, or the relevant evidence cannot be demonstrated.

---

Beta Marking Details

Beta will be marked out of 40 marks. Most marks are shared by the team, but the engineering questions, reflection and any team contribution modifier are individual.

1. [3 marks] Code Style — group mark
   • This will be marked automatically by extracting your team’s GitHub repository.
   • It will be assessed according to the Java Code Conventions specified for Beta.
2. [8 marks] Git Etiquette and Collaboration — group mark
   • This will be marked automatically from your team’s GitHub repository and commit history.
   • It will be assessed according to the Git Etiquette specified for Beta.
3. [3 marks] Presentation Professionalism and Team Dynamics — group mark
   • All team members have their cameras on, introduce themselves and communicate professionally.
   • The team presents as a coordinated group and uses the available time effectively.
   • All three members make a meaningful and reasonably balanced contribution to the presentation.
   • During the student-led demonstration, the team maintains continuous presentation rather than silently playing the game.
4. [25 marks] Demo
   • Functionality demonstrated: 15 marks — group mark.
   • Engineering questions: 5 marks — individual mark.
   • Overall client impression: 5 marks — group mark.
   • See the detailed rubric below.
5. [0 to -40 marks] Team Contribution Modifier — individual deduction
   • This modifier does not add marks. It may reduce an individual student’s Beta mark, potentially substantially.
   • We will consider the TEAMMATES contribution questionnaires, Git history and other available evidence of contribution and collaboration.
   • Poor evaluations from teammates may result in marks being deducted from your individual Beta mark. This includes evidence that you contributed too little, did not complete agreed responsibilities, communicated or collaborated poorly, or otherwise placed an unfair burden on the team.
   • Marks may also be deducted where one member does substantially too much and prevents the other members from contributing meaningfully.
6. [1 mark] Reflection — individual mark
   • You will use Co-Thinker. It will be released after all Beta presentations have finished.

Beta Presentation Essentials

The Beta presentation will take approximately 20 minutes and will follow the same structure for every team.

Beta presentations will be recorded for marking purposes. The recordings will not be made public in any way. Only lecturers and teaching assistants (TAs) may view them, and only if needed for marking.

Before the presentation:

• Follow the Alpha instructions for preparing Zoom, testing your microphone and camera, and enabling remote-control access.
• Join the Zoom link 5–10 minutes before your scheduled presentation time.
• Ensure that your Zoom name contains your team number.
• We recommend that all three team members present together in the same physical location. This makes it easier to coordinate speaking and operating the application, but it is not a requirement. You may present from separate locations, with each member joining Zoom individually. In that case, one member must operate and share the application during the team demonstration while the others explain what is happening on screen. This takes more coordination, so rehearse it beforehand.
• During the team demonstration, use one computer and one running instance of the application. Do not switch screen sharers or run separate copies for different speakers. You may switch screen sharers during the individual engineering questions so that each student can show code on their own computer.
• Have the application, prompts and relevant source code ready to show. Do not use slides.
• Test a clean clone of your repository on a different machine. The application must run on macOS; Valerio will use his own apiproxy.config file.

Presentation structure

1. Greeting and setup
   • Introduce the three team members. The client will share their screen.
2. Demonstration 1: the client plays — approximately 7 minutes
   • The client plays one round of the game and attempts to reach a successful verdict.
   • Remain silent while the client is playing unless the client asks a direct question.
   • The client should be able to understand how to use the application without coaching.
3. Demonstration 2: targeted team demonstration — approximately 7 minutes
   • Take back control and share the full desktop. Keep the same computer and running application instance throughout the team demonstration, even as different members speak.
   • Use the real application rather than slides, mock-ups or recorded video.
   • Demonstrate important functionality that did not arise naturally during the client’s round. This may include another verdict combination.
   • You must talk throughout this demonstration. This is a seven-minute presentation, not a silent playthrough. Extended or repeated periods of avoidable silence will lose presentation marks.
   • As you use the application, explain the theme, relevant scenario and interface decisions, important Beta functionality, and how these choices serve the needs of Insight Investigations. Do not merely describe which button you are clicking. Explain your design decisions.
   • All three members must speak for a meaningful and reasonably similar amount of time. Build on what teammates have said instead of repeating it.
4. Client clarification questions — approximately 2 minutes
   • The marker remains in the role of an Insight Investigations client.
   • Answer in non-technical language and focus on the experience and value of the product.
5. Individual engineering questions — approximately 4 minutes
   • The marker will clearly switch from the client role to the lecturer/TA role.
   • Each team member will be asked one different question from the published bank below.
   • The selected student must locate and explain the relevant prompts or source code without assistance from teammates. If the team is presenting remotely, that student may share their own screen for their question; the single-screen rule applies to the team demonstration, not to engineering questions.

Beta Demo Rubric — 25 marks

Functionality demonstrated — 15 marks

The functionality mark assesses how completely and correctly the application implements and demonstrates all Beta requirements explicitly written as must or must not in the project handout. The project handout is the single source of truth for these requirements.

Requirements described as recommendations, examples or open design choices are not independently assessed as compulsory functionality. Partial marks may be awarded where a compulsory requirement is implemented but incomplete, inconsistent or affected by a defect.

The client round does not need to expose every behaviour naturally. The targeted team demonstration and follow-up questions may be used to demonstrate required behaviour that did not occur during the client’s playthrough.

The application must distinguish all four verdict combinations specified in the project handout:

1. correct intervention with a correct, supported and coherent rationale;
2. correct intervention with an incorrect, unsupported or incoherent rationale;
3. incorrect intervention with a correct, supported and coherent rationale; and
4. incorrect intervention with an incorrect, unsupported or incoherent rationale.

Engineering questions — 5 marks individually

Every team member will answer one different question selected by the lecturer. Marks are awarded individually for locating relevant evidence in the team’s repository and explaining what the implementation does. A student is not required to have personally authored every line they are asked about, but every member is expected to understand the integrated team product.

The lecturer will select from the following published question bank:

1. How does your application keep information consistent across the three epochs?
2. How did you design the three NPC prompts, what are the key differences?
3. How does the game decide whether the player can proceed to an intervention?
4. How does your application evaluate the player’s written rationale (show prompt and Java code)?
5. How does replay work in your application?
6. How does the player travel between the three epoch rooms?
7. How did you design the room interface around the NPC, interactable and chat?
8. How does your application record which clues the player has discovered?
9. How does your application keep the GUI responsive while waiting for the LLM?
10. How are the four intervention outcomes implemented?

Marks	Descriptor
5	Independently locates highly relevant evidence and gives a clear, accurate explanation of the complete mechanism, including its purpose and an important edge case.
4	Locates relevant evidence and gives a substantially correct explanation, with only a minor omission or imprecision.
3	Demonstrates a sound general understanding, but the explanation or supporting evidence is incomplete.
2	Demonstrates partial understanding but cannot clearly trace the mechanism or connect it to the requirement.
1	Provides minimal relevant evidence or explanation and requires substantial prompting.
0	Cannot locate relevant evidence or explain the mechanism.

Overall client impression — 5 marks

This criterion concerns the client’s experience of the functioning team product rather than visual polish in isolation.

Marks	Descriptor
5	The application is immediately understandable, smooth and coherent. The mystery can realistically be investigated in the available time, and the team clearly relates thoughtful design decisions to the needs of Insight Investigations.
4	The application is easy to understand and use, with only minor friction. The mystery is coherent and the team clearly explains its value to the client.
3	The core experience is understandable and generally coherent, but some usability or pacing problems affect the client’s playthrough.
2	The intended experience can be identified, but substantial usability, pacing or coherence problems make it difficult to complete or understand.
1	The application provides very limited evidence of an understandable, coherent client experience.
0	The application does not provide an understandable, coherent client experience, or the relevant evidence cannot be demonstrated.

---

---

Final Marking Details

Final will be marked out of 18 marks. Most marks are shared by the team, but any team contribution modifier are individual.

1. [2 marks] Code Style — group mark
   • This will be marked automatically by extracting your team’s GitHub repository.
   • It will be assessed according to the Java Code Conventions specified for Final.
2. [4 marks] Git Etiquette and Collaboration — group mark
   • This will be marked automatically from your team’s GitHub repository and commit history.
   • It will be assessed according to the Git Etiquette specified for Final.
3. [3 marks] Presentation Professionalism and Team Dynamics — group mark
   • All team members have their cameras on, introduce themselves and communicate professionally.
   • The team presents as a coordinated group and uses the available time effectively.
   • All three members make a meaningful and reasonably balanced contribution to the presentation.
   • During the student-led demonstration, the team maintains continuous presentation rather than silently playing the game.
4. [8 marks] Overall impression and demo quality
5. [0 to -18 marks] Team Contribution Modifier — individual deduction
   • This modifier does not add marks. It may reduce an individual student’s Final mark, potentially substantially.
   • We will consider the TEAMMATES contribution questionnaires, Git history and other available evidence of contribution and collaboration.
   • Poor evaluations from teammates may result in marks being deducted from your individual Final mark. This includes evidence that you contributed too little, did not complete agreed responsibilities, communicated or collaborated poorly, or otherwise placed an unfair burden on the team.
   • Marks may also be deducted where one member does substantially too much and prevents the other members from contributing meaningfully.
6. [1 mark] Reflection — individual mark
   • You will use Co-Thinker. It will be released after all Beta presentations have finished.

Final Presentation Essentials

The Final presentation will take approximately 10 minutes and will follow the same structure for every team.

Final presentations will be recorded for marking purposes. The recordings will not be made public in any way. Only lecturers and teaching assistants (TAs) may view them, and only if needed for marking.

Before the presentation:

• Follow the Alpha instructions for preparing Zoom, testing your microphone and camera, and enabling remote-control access.
• Join the Zoom link 5–10 minutes before your scheduled presentation time.
• Ensure that your Zoom name contains your team number.
• We recommend that all three team members present together in the same physical location. This makes it easier to coordinate speaking and operating the application, but it is not a requirement. You may present from separate locations, with each member joining Zoom individually. In that case, one member must operate and share the application during the team demonstration while the others explain what is happening on screen. This takes more coordination, so rehearse it beforehand.
• Each team member has to speak during the demo
• During the team demonstration, use one computer and one running instance of the application. Do not switch screen sharers or run separate copies for different speakers. You may switch screen sharers during the individual engineering questions so that each student can show code on their own computer.
• Test a clean clone of your repository on a different machine.

Presentation structure

1. Greeting and setup
   • Introduce the three team members.
2. Demonstration: approximately 7 minutes
   • Share the full desktop. Keep the same computer and running application instance throughout the team demonstration, even as different members speak.
   • Use the real application rather than slides, mock-ups or recorded video.
   • You must talk throughout this demonstration. This is a seven-minute presentation, not a silent playthrough. Extended or repeated periods of avoidable silence will lose presentation marks.
   • As you use the application, explain the theme, relevant scenario and interface decisions, important functionality, and how these choices serve the needs of Insight Investigations. Do not merely describe which button you are clicking. Explain your design decisions.
   • Highlight what you have changed based on the Beta feedback
   • All three members must speak for a meaningful and reasonably similar amount of time. Build on what teammates have said instead of repeating it.