CPSC 217: Assignment 1 (The Tam "Dungeon of Doom")

Due at 4 PM. For assignment due dates see the main schedule on the course webpage. The program must be written and run under python version 3.X and run on the computers in the tutorial labs.

Assignment difficulty

Students may find assignments more challenging than they first thought. It's best to start work as early as possible. Tips in the very first lecture were provided but here's two reminders: 1) work through the lecture and tutorial material before looking in detail at the assignments 2) start work as soon as possible. If you find you cannot complete an assignment before the due date then you will not be granted an extension.

Note: it is not sufficient to just implement a working program and expect full credit. You need to implement your solution in the correct way using good design principles and you apply the necessary concepts. Even if your program is fully working and the program is not designed or implemented as specified in the assignment description (e.g. poor variable names used, named constants not used when they should have employed etc.) then you will not be awarded full credit. For some assignments your grade may be greatly reduced. For example, in all the later assignments you need to employ functional decomposition and do so in a the proper specified manner. If you do not do this for these later assignments then your maximum assignment grade point could be as low as 1.0 GPA even with a fully working program. Although the earlier assignments will not have marking requirements which are quite as strict take care to read the specific details provided in each assignment which is provided under the "Marking and grading" section of each 'full' assignment. The marking of the mini-assignments will focus on program functionality unless otherwise specified.

New Concepts to be applied for the assignment

• Problem solving using branches and loops in Python.
• If you want credit for your work: Do not use any pre-created functions/methods unless you are given explicit permission to do so. [Generic list of allowable pre-created code in the form of python libraries]

Only new concepts that need to be applied in the assignment are listed, concepts previously applied in other assignments may need to used in the implementation of your solution.

Functional requirements (working features of your program, for the marks allocated for each feature see the marking spreadsheet):

Rooms of the dungeon (adventure area).

Write a text-based "choose your own" adventure game.¹ There will be three 'rooms' in the game world, within each room the player will see a number of choices with the program will reacting to the player's selection. The game will repeatedly run the game via a main loop (contains most of the instructions of the program) that runs until the game has been won.

Pseudo code design for the main loop

    Do while (game has not yet been won)

        #Instructions for playing the game (i.e. almost all of the program the program)

    End while

    #Display conclusion with a congratulatory message.

The goal of this game is to open the locked door inner to access the rest of the house. When the door has been unlocked the player can return to the entrance room and open the door to the rest of the house. When this occurs the main loop ends and a suitable congratulatory message should be displayed and the program ends.

Entrance room description

The player begins the game in the entrance. The door that brought the person into the house is gone (it's a "one-way portal"). When the player is in this room the game will describe the list of possible actions:

• Try to open the door (result depends upon whether the door is locked)
• Go through the left entryway (takes the player to the pantry)
• Go through the right entryway (takes the player to the kitchen)

The selections in the menu should be logical and easy to understand: What the user needs to enter for options when choosing the above options need to be intuitive. E.g. selecting '1' for opening the door, '2' for going left and '3' for going right doesn't make it easy for the player to associate a menu selection with each action. Designing a program with such poor mappings may result in a lower grade. (For ideas on better mappings look at the output file: "output_normal_play.txt")

The player cannot open the inner door until it has been unlocked. The player can freely pass through either entryway with no conditions. Entering a non-existent selection will result in a suitable helpful error message (refer to the last section of the 'repetition' notes, the [usability heuristics] or rules of thumb for how to write good error messages) and the above options are displayed again. As long as the player remains in the room the program will repeatedly display the above menu options (using a loop) after the user enters a selection.

Pseudo code algorithm for the entranceway

Do while (player is in the entranceway)

Display options for entranceway

Get player's selection

Take appropriate action based upon the selection

End while

Pantry description

As shown in the above map the player can freely pass between the entrance and the pantry. When the player is in the pantry, the game will display the list of possible actions:

• Turn the silver lock to the left position
• Turn the silver lock to the right position
• Turn the silver lock to the center position
• Don't change the position! Return to entranceway

The program must show the current position of the lock e.g. "The silver lock is currently set to the right position.". The starting default is the 'left' position. (The unlocked position is 'right'). Similar to the entrance if the player enters an invalid selection in the pantry, a suitable helpful error message should be displayed and the list of options for the pantry will be shown again.  As long as the player remains in the room the program will repeatedly display the above menu options (using a loop) after each time the user enters a selection. The menu selections for choosing the action for this room need to be intuitive.

Pseudo code algorithm for the pantry

Do while (player is in the pantry)

Display options for pantry

Get player's selection

Take appropriate action based upon the selection

End while

Kitchen description

As shown in the above map the player can freely pass between the entrance and the kitchen. When the player is in the kitchen, the game will display the list of possible actions:

1. Turn the gold lock to the left position
2. Turn the gold lock to the right position
3. Turn the gold lock to the center position
4. Don't change the position! Return to entranceway

The program must show the current lock position e.g. "The gold lock is currently set to the center position." The starting default is the 'center' position. (The unlocked position is 'left'. Similar to the entrance if the player enters an invalid selection in the kitchen, a suitable  helpful error message should be displayed and then the list of options for the kitchen will be shown again.  As long as the player remains in the room the program will repeatedly display the above menu options (using a loop) after each time that the user enters a selection. The menu selections for choosing the action for this room need to be intuitive.

Pseudo code algorithm for the kitchen

Do while (player is in the kitchen)

Display options for kitchen

Get player's selection

Take appropriate action based upon the selection

End while

Sample program output:

A text file ["output_normal_play.txt"] shows sample execution of my solution with a normal play through (no erroneous selections). Another text file ["output_selection_invalid.txt"] illustrates what should happen when the player selects an option that isn't listed.

Overall program design: although you were just given design guides on different parts of the program here is all the pseudo-code for the entire program.

Do while (game has not yet been won)

Do while (player is in the entranceway)

Display options for entranceway

Get player's selection

Take appropriate action based upon the selection

End while

Do while (player is in the kitchen)

Display options for kitchen

Get player's selection

Take appropriate action based upon the selection

End while

Do while (player is in the pantry)

Display options for pantry

Get player's selection

Take appropriate action based upon the selection

End while

End while

Instructions that display conclusion with a congratulatory message.

In addition to grading on whether the above functionality was correctly implemented TAs will also look at style and documentation (non-functional assignment requirements):

Non -functional assignment requirements (style and documentation).

Programming style:

• Naming conventions: You should employ good naming conventions for identifiers (variables, constants) as covered in the "Intro to programming" section of the course. Also note there is a specific name that you should give to the file containing your program which is specified under the [marking and grading section].
• Named constants should be used as appropriate (and if they aren't  employed a penalty will be incurred).

	Yes do it this way!	No. Not this way!
	LEFT = 0 RIGHT = 1 CENTER = 2 if (silverLockPosition == RIGHT):	if (silverLockPosition == 0): #What does 0 stand for???

• The program code should have appropriate white space (specified in the "Intro to programming lecture') and alignment (specified throughout the lecture notes).
• Code is self documenting e.g. Clear expressions (e.g. mathematical, Boolean). Expressions should be clear and simple (break up or restructure complex expressions). Good variable names and the use of named constants are examples of writing self documenting code but specifying clear expressions is important enough to be included in a separate category.
• Error messages need to be clear and/or helpful (see the Usability Heuristics in the [Part III of the looping/repetition notes]).
• The menu selections for choosing the action for each room need to be intuitive (see "handling errors" part of the Usability Heuristics in the [Part III of the looping/repetition notes]).
• The program should not employ abnormal termination mechanisms e.g. something such as a 'break' instruction for loops or calls to the  'exit()', 'quit()' functions anywhere in the program.

Having at least one violation in one of the above categories will result in -0.1 penalty to marking. Multiple violations in one category still results in a single penalty (e.g. 3 bad variable names will still result in a -0.1 penalty). However violations between categories will result in cumulative penalties (e.g. a program that includes poor variable names, named constants weren't used when they should have been, menu options are non intuitive will receive a -0.3 penalty). A maximum penalty of -0.7 may be incurred for style.

Python documentation: This should be specified in the header of the program (very top of your program before any instructions). The basics of documentation were covered in the [last part of the "Intro to programming"] section of the course. Later lectures may specify additional information that needs to be provided in the documentation.

• Identifying information: All assignments should include contact information (full name, student ID number and tutorial section [Here's a Link if you don't know how to find this information]).
• Program version. (version date or version number).
  • Under the version you should specify which assignment features were implemented in that version as specified in the [last part of the "Intro to programming"] section of the course.
  • Each room should list the features of that room (from the assignment description) that were correctly implemented.
• Any program limitations or weaknesses

How to do determine 'how you did' on an assignment?

Program functionality (implementing working program features)

• Test your program: Because the [marking key] is posted ahead of time if you test your program thoroughly before submitting the final version then you should get a pretty clear idea of "how you will do".

Style and documentation (non-functional assignment requirements)

• Style and documentation requirements were introduced early in the semester in the  [last part of the "Intro to programming"] section of the course. Additional requirements may be added as new sections are covered (e.g. documenting functions that you write your yourself). Each assignment will specify these requirements specific [under the non -functional assignment requirements (style and documentation). ] to that graded component. Again you should refer to the [marking key] in order to determine how style and documentation will affect grading for a particular assignment.

Marking and grading

• What to submit (remote learning version): If your submission won't run using Python 3.x on any computer then it won't be awarded credit. It's up to you if you wish use the graphical program builder other than IDLE (or another development environment rather than a simple text editor) to write/run your programs but if you do you submit your program in the form of text ".py" file or files. Windows users: take care that you don't accidentally submit a shortcut to a file instead of the actual file. (Check the file name and compare the file size to your original file. Simply downloading the shortcut file as a test won't work because that shortcut will work on your computer but not on anyone else's machine and this may mean your work won't be graded.).

• Naming the file containing your program: You must save your program in a file called "doom1.py". Failing to use this exact name will affect your grade by the amount specified in the [marking key].

• Late assignments or components of assignments/Assignment extensions: Normally due dates are strict and extensions require documentation. Due to the likelihood of widespread Covid related illnesses late penalties will not be applied this semester. But if you do submit something after the due date/time then you should email your marker (TA in the tutorial that you are officially registered) so that person will know to look for it in D2L. Also if are submitting too many graded components late however this doesn't bode well for your performance in this course so you may be referred to the associate dean of undergraduate students (faculty of science) and she may contact you regarding your course work. 
• How you will be graded for full assignments. As mentioned, as well as being marked on whether "your program works" you will also be marked on non-functional requirements such as style and documentation. Like other full assignments, this one will include a separate [marking checklist]. Besides seeing your grade point in D2L you can also see the detailed feedback that your TA will enter for each student. You can access the grading sheet in D2L under Assessments->Dropbox and then clicking on the appropriate assignment link. If you still cannot find the grading sheet then here is a [help link]
• Questions or concerns about grades after they have been released: Assignments will be marked by your tutorial instructor (the "Teaching Assistant" or "TA") for your tutorial section. When you have questions about marking this is the first person that you should be directing your questions towards.  If you still have question after you have talked to your TA, then you can of course talk to your course (lecture) instructor but please indicate in your email that you first contacted your TA before going into your concerns.

Collaboration:

Assignments must reflect individual work; group work is not allowed in this class nor can you copy the work of others. Some "do nots" for your solution: don't publically post it, don't email it out, don't show it to other students.  For more detailed information as to what constitutes academic misconduct (i.e., cheating) for this course please read the following [link].

Method of submission:

You are to submit your assignment using D2L [help link]. Make sure that you [check the contents of your submitted files] (e.g., is the file okay or was it corrupted, is it the correct version etc.). It's your responsibility to do this! (Make sure that you submit your assignment with enough time before it comes due for you to do a check). If don't check and there were problems with the submission then you should not expect that you can "learn your lesson" and simply resubmit.

D2L configuration for this course

• Do not use compression utilities (such as zip) or archiving utilities (such as tar) otherwise your submission may not be marked. The space savings in D2L is not worth the extra time required by the marker to process each submission.
• How often can you submit: Multiple submissions are allowed for this assignment: You can (and really should) submit work as many times as you wish before the due date. However only the latest file submitted is the one that will be marked, everything else will be ignored (because it is not fair to your marker to sort through multiple versions of your files).
• What to submit: Python programs only (file name ends in .py)  Any other type of file will be rejected by D2L.

General use of pre-created Python libraries:

Unless otherwise told you are to write the code yourself and not use any pre-created functions (or methods). For most assignments the usual acceptable functions include: print(), input() and the 'conversion' functions such as int(), float(), str(). Look at the particular assignment description for a list of other functions/methods that you are allowed to use and still get credit in an assignment submission. If it's not listed then you should assume that you won't be able use the function and still be awarded credit.

^{1 Choose your own adventure. Rather than passively reading through a fixed story written by the author a choose your own adventure puts you in the role of the story's protagonist whereby you can determine the outcome of the story by choosing at various points the direction that will be taken by the story.}