BYOW Checkoff Script
Nov 2024: This page is in draft form, and is subject to some minor changes.
Deadlines
Assignment | Tasks | Deliverable | Points | Due Date |
---|---|---|---|---|
Team Formation | - Task 0: Partnerships | Pre-Project Google Form | 5 | Mon, Nov 11 11:59pm PT |
Project 3A | - Task 1: Setup - Task 2: World Generation |
World Screenshots on Gradescope | 10 | Mon, Nov 18 11:59pm PT |
Mid-Project Google Form | 5 | |||
Project 3B | - Task 3: Main Menu - Task 4: Interactivity - Task 5: Saving and Loading - Task 6: Ambition Features |
Code on Gradescope (0 pts, but required for checkoff) |
0 | Tue, Nov 26 11:59pm PT |
Live Checkoff with TA (Checkoffs will happen Dec 2–6) |
100 | |||
Post-Project Google Form | 5 |
Checkoff Policies
Project 3 Demos will be conducted during lab sections.
Information about how to sign up for a checkoff time will be posted on Ed.
The code that you present during your demo should be the code that you submitted to the Project 3B assignment on Gradescope. In other words, the Project 3B due date (plus any extensions you requested) is the deadline for making any changes to your code. Even if your checkoff doesn’t happen until later, you can’t make any changes after your Project 3B due date.
The following is what the TA will exactly do when checking you off: we recommend you do a dry-run of this to ensure you didn’t miss anything. You can clone your repository in some random destination on your computer (like your home directory) if you want to follow along and simulate your checkoff.
Attendance
Both partners should be present in-person for the checkoff.
If one partner is sick, traveling, or has some other documented excuse, it’s okay if they join remotely over Zoom. It’s your responsibility to make sure that the remote partner is on call before the checkoff starts. We can’t wait for you to open a Zoom call after the checkoff slot has already started.
Setup
Designate one partner to be the presenter; this should be the partner who signed up for the demo slot. They should make sure to already have the following set up:
- IntelliJ open with your Project 3 code (doesn’t matter what class)
- The program running with the BYOW main menu displayed
- The state of your repo should be the commit containing the version of your project you want to demo. The code you demo should be the same as the code you submitted to Gradescope. If this is your most recent commit, just make sure your Git status is clean. If it is a past commit, you can get to this state by running
git switch --detach <commit id>
. (To get your repo back to normal, rungit switch main
.) - If you choose to demo a version of your project that is past the deadline (for a percentage penalty, per the syllabus), make sure to let the TA know.
- Your Git status should be clean (no changes to commit)
Checkoff Script
- The grader will ask for everyone’s class ID (fa24-s***)
- One partner should designate their laptop as the “check-in laptop”, and already have a terminal window in their
fa24-proj3-g***/proj3
. Their Git should be in a clean state (git status should be clean), IntelliJ should be open, and the Project 3 main menu should be running.- If any of these requirements are not fulfilled, you may not receive a grade for Proj3 checkoff.
- Run “git log” and make sure that the HEAD commit is a commit from before the deadline. Run “pwd”. Make sure the path matches that of the open IntelliJ window. The students may choose to demo a late commit for partial credit.
- Check for main menu with New Game/World, Load, and Quit options.
- Check that hitting “n” on the main menu lets player type in a seed.
- Check that typing numbers and hitting “s” starts the world.
- Check that the floor and walls are distinguishable.
- Check that there are at least 2 structures which can be considered hallways. (1 wide, kinda long)
- Check that the world contains a turning hallway. If the current world doesn’t have a turning hallway, ask the students to generate a world that has a turning hallway.
- Check that there are a few rectangular structures which can be considered rooms, which are connected via hallways
- Check WASD moves the player up, left, down, right.
- Check that moving into walls stops the player without errors.
- Check that typing in “:Q” in “world mode” stops the game. At this point, memorize how the state of the world looks like. You can ask the student to take a screenshot or take one yourself.
- After restarting the program, test the load/save feature: Check that pressing “L” on the main menu starts a world with no additional input.
- Check that the world layout is exactly the same as it was before closing the world.
- Check that the basic commands (WASD, etc.) still work.
- Quit and reload the world again, and make sure basic commands still work.
- Check that “q” alone in “world mode” doesn’t terminate the game.
- Generate 3-5 worlds and look for how varied they are. Select one tier based on how much variety you feel their worlds have.
- Full credit - each world generated looks significantly different and you feel like you’d see something new when you generate a new world
- 50% credit - the worlds are not identical, but there are only small shifts or changes which do not really change the experience of moving around the world (e.g. rooms are always in the same spot but just slightly different size)
- No credit - Worlds are identical most of the time or the changes in the room have no effect on the player experience/how they explore the world. (e.g. the world is the same each time, with only changes in the color of the floor)
- The grader will then ask you to show all the ambition points you’ve attempted, and will determine whether you receive full or half credit for those items.
- The grader will tell you which items you received/did not receive credit for. They will ask if you agree with your score: if you do not, you will be given the opportunity to request a regrade.
Point Allocation
They will then grade each requirement of the game. Each requirement can either be evaluated as full points, half points, or zero points.
Basic World Functionality (50 points total)
The TA will run your project and will check for the following features:
- The world has a main menu screen with a New World, Load, and Quit option (2 points)
- The TA will hit “n” or “N” (they may do either) and check that the world prompts for a seed (2 points)
- The TA should type in a few random numbers and hit “s” or “S” (they may do either) which should immediately start the world. The TA should also be able to see the numbers you are typing on the screen. (4 points)
At this point, the program should be running and there should be a visible world.
- World has visually distinct walls and floors (4 points)
- World has at least two hallways which are 1 tile wide (1 point)
- World has at least 1 hallway containing a turn in it. If current world doesn’t, ask students to generate a world that has a turning hallway. (1 point)
- World has some number of rooms that are connected via hallways (8 points)
The TA will now try the basic commands that should be available during gameplay.
- TA should hit the W, A, S, and D keys randomly and check the player movement is consistent with the key pressed (3 points)
- TA should move into a wall and make sure the player stops at the wall instead of moving into it (3 points)
- TA should type “:q” or “:Q” (they may do either) in “world mode” which should quit the world and close the program. TA should remember the world layout at this point (4 points)
The program is now closed, and we will test the load feature.
The TA will run the world again after it has been closed and the main menu should appear again.
- TA should hit “l” or “L” and the world should immediately start (4 points)
- TA should check that the world layout is exactly as it was before closing the world (3.5 points)
- TA will run through the basic commands again (listed above) to make sure the world still works (3.5 points)
- TA will quit and load again and make sure that the basic commands work (3.5 points).
- TA will check that “q” or “Q” alone in “world mode” does not quit the game (3.5 points).
Randomness (20 points total)
- The TA should close the world again and will begin testing to see if worlds are randomly generated.
- The student pair should’ve explained to the TA where they are making use of randomness and make mention of any pieces of their world which is consistent across all seeds
- TA should check that the use of randomness does not lead to a severe limitation on the variety of worlds (ie. randomly choosing a world layout from a finite set of worlds)
- The TA should open the world 3-5 times, making sure to use a different seed each time
- The TA will be looking for your world’s ability to generate variety in both world structure and player experience while exploring that world. What this means is when two different seeds are used to generate new worlds, these worlds should not feel identical (or close to identical).
The grading breakdown is as follows:
- 20 points TBD: The worlds are mainly random, as described by the above section.
- 10 points TBD: The worlds exhibit a few random elements, but generally look the same
- 0 points: The worlds contain no random elements.
Ambition Points (30 points total)
- The student should state and demonstrate the features that are in the Ambition category. You should be very explicit about how to “activate” or use that feature.
- The TA will write in the features the student successfully demonstrated and their point values based on the spec, awarding either Full, Half, or Zero credit for each item.