ITECH2000 Mobile Development Fundamentals
Assessment Task 2 – AppInventor App (Math Game)
Overview
You will implement in AppInventor a multi-screen app, based on a given project specification. This app will use a range of components taught up to and including Week 7 of the course. You will also submit a brief report containing pseudocode and a description of how your solution utilises various concepts learned in class.
Timelines and Expectations
Percentage value of task: 20% (of final course mark)
Due date: 11:59pm, Sunday 13th September 2020 (Week 7) – after this date, you will receive a penalty
Cut-off date: 11:59pm, Sunday 20th September 2020 – after this date work will not be accepted
Minimum time expectation: 10 hours
Maximum time expectation: 30 hours – Most students should not require this much time.
Learning Outcomes Assessed
The following course learning outcomes are assessed by completing this assessment.
K1. Understand constructs typical of many programming languages such as: variables, expressions, assignment, sequence, selection, iteration, procedures, parameters, return values.
A1. Design, develop, test and debug mobile apps from a given textual program specification.
S1. Analyse the input, processing and output needs of small programming problems.
S2. Design code sequences to realise algorithms in a programming language.
S3. Design basic user interfaces and develop storyboards to convey designed interaction sequences.
S5. Develop test cases to ensure correct behaviour.
Assessment Details
This assignment contains two parts: an app and a brief report.
1. App Details
Your assignment is to develop an Android application, using MIT AppInventor, which consists of a simple but challenging addition game. The user is presented with 9 random numbers and a target number and must select 3 numbers or less to add up to the target within a time limit. Each time the user correctly adds up to the target number, the difficulty increases slightly with a larger target displayed and 9 new random numbers, while the time limit also resets. The game continues until the user does not reach the target (or exceeds it) using 3 numbers, or when the time limit runs out.
The application should contain a number of screens, which are described in the following sections. Note: Your app does not need to look identical to the provided screenshots. As long as you fulfil the requirements in a logical way that follows what you have learned this semester, you have free reign to design your interfaces as you like.
CRICOS Provider No. 00103D | RTO Code 4909
Screen 1: Menu
When the application is first opened, a menu should be displayed with options to view the rules of the game (“How To Play”), play a “Quick Game” (default game parameters), and to play a “Custom Game” (allow the user to modify some game parameters). Clicking on each entry in the menu should open the appropriate screen.
Screen 2: How to Play
When the user opens the “How to Play” screen, it should display the rules of the game. On Moodle, you have been provided with a text document howtoplay.txt, which contains the rules of the game. This text file should be imported into your AppInventor project, and this screen should load and display the text from the file at runtime.
This screen should also provide some way for the user to navigate back to the menu screen once they have finished reading the rules.
Screen 3: Quick Game
When the “Quick Game” option is selected from the menu, the app should open another screen that includes the game interface and mechanics. Figure 1 displays a rough outline of how the game is displayed to the user.
Figure 1. Examples and outline of the game screen. Note that two separate game screens are shown.
When the game starts, a set of 9 random numbers should be generated and displayed, as well as a random target number. In Round 1 of the game, the 9 random numbers should be between the range of 1 and 6. Note that it should be possible to add up to the target using 3 or less of the 9 randomly generated numbers, so you will have to think carefully and design your algorithm in such a way that this is always possible. For example, the first game screen shown in Figure 1 has a target of 7 – this could be achieved by adding up the numbers 5 and 2, or the numbers 4 and 3, or the numbers 4, 2 and 1. The second example has a target of 10, which could be achieved with the numbers 5 and 5, the numbers 6 and 4, or the numbers 6, 3 and 1. While these examples allows for multiple ways to reach the target, a game screen must have at least one way of reaching the target number using 3 or less values to be valid.
In addition, once the game has started a timer should also begin counting down from 10 seconds. It is recommended that you display the number of seconds that the user has left somehow in your interface and update this after every second passes.
To play the game, the user needs to click on the numbers to reach the target. The game should check whether the user has reached or exceeded the target after every click, and automatically load the next round if the target is reached or display the game over message if it is exceeded. You will need to keep track of how many times the user has clicked (remember: they can only use 3 numbers at most), and the running total of the numbers they have selected.
Every time the user reaches the total using three numbers or less, the timer should reset to 10 seconds and the difficulty of the game should increase. This happens by increasing the maximum value of the random numbers that can be generated (e.g. the numbers can get bigger each time the user wins a round). As a result, the target number should also get bigger. The new set of 9 random numbers should be displayed along with the new target.
During each round of the game, if the user selects three numbers and the target has not been reached (or it has been exceeded), then the player loses the game. Alternatively, if the timer reaches 0 the player also loses the game. At this point, an alert should tell the user that the game is over and display their “winning streak” (e.g. the number of targets they reached during the game). The user should have the option to play again (starting from the initial difficulty) or exit back to the menu.
Screen 4: Custom Game (Advanced Work)
Note: These tasks are more difficult and should be attempted last, only after you have Screen 3 completely working. If you do not complete Screen 4, it is still possible to achieve a high mark if your other screens are completed properly.
This screen presents the user with options to play a “custom game” by choosing certain rules for the game, to modify those explained in the specification for Screen 3. Specifically, the user should have the ability to set the following settings:
• Whether or not they want the timer to be active - if yes, the 10 second timer will count down, otherwise there will be no timer and the user has unlimited time to reach the target number;
• Whether or not they want the difficulty of the game to increase after each round – if yes, the randomly generated numbers will get slightly larger after each round, else the randomly generated numbers will not increase after each round.
• The minimum and maximum range for the random numbers to be generated from (the default values are 1 and 6) – this would allow the user to start the game with larger random numbers, which would also mean that the target number was larger.
It is important that this screen provides validation so that a game cannot be started with invalid options, for example empty values or a minimum value that is larger than the maximum.
Once the user has selected their preferred options for a custom game, they should click a button to start the game. At this point, Screen 3 should open and start the game according to the player’s custom rules. These rules should be applied for the duration of the game, i.e. after every round is won, and if the user chooses to play again after losing a game.
General Requirements for Coding
While your app should meet the functionality described above, you need to ensure that you demonstrate the concepts we have covered in ITECH2000 so far. To achieve full marks you will need to ensure that you have correctly made use of each of the following components or constructs somewhere in your app:
• a Notifier
• A CheckBox
• Labels
• TextBoxes
• Buttons
• A Clock and instants
• HorizontalArrangement, VerticalArrangement or TableArrangement (or all of them)
• The File component (reading from a file)
• The list construct
• A repetition construct
• A decision construct using a Boolean (AND or OR) expression
• Procedures that you have defined using the ‘to do’ or ‘to do … result’ blocks
Please read through all of the requirements before you commence work on the app, so you get a full sense of what is required to be done. It is recommended that you first model any events using pseudocode before commencing programming.
2. Brief Report
As well as completing the program described above in AppInventor, you are also required to submit a brief report that includes the following:
• A title page that includes your name and student ID number.
• Pseudocode describing the behaviour of three (3) events that your app will respond to, including the game logic when a user selects a number. Ensure that you clearly label your pseudocode so that it is clear what aspect you are modelling.
• For each of the design components/blocks listed in the previous section (General Requirements for Coding), you should describe in 2-3 sentences how you used this component in your solution and justify why. If you have used a component multiple times, please describe one example.
Getting Assistance and Clarification
If any part of the task is unclear to you, or you are not quite sure how to do some aspect of the task, you should either contact your lecturer directly (via email, or in person while you are in class), or else post a question to the Discussion Forum on Moodle. However, any questions posted to the forum on Moodle should not include anything that you plan to submit (such as screenshots of code you might want to submit).
Plagiarism
Plagiarism is the presentation of the expressed thought or work of another person as though it is one’s own without properly acknowledging that person. You must not allow other students to copy your work and must take care to safeguard against this happening. More information about the plagiarism policy and procedure for the university can be found at https://federation.edu.au/current-students/learningand-study/online-help-with/plagiarism
Submission
You must export your AppInventor project for submission. To do this, go to the “Projects” menu, and select “Export selected project (.aia) to my computer”. Rename the .aia file to include both your name and student ID number. App files submitted in any other format than .aia (e.g. apk) will not be accepted and you will receive zero marks.
You should also save your brief report as a PDF including both your name and student ID in the file name.
Upload these files to Moodle through the assignment link labelled “Submit Assignment 1”. This link will only become available after you have completed the “Declaration of Originality” form for the assignment, which requires you to accept the Student’s Statement. It is a legal declaration that the work was done by you, without any part of it being done by someone else.
Feedback
You can expect to receive your final mark and feedback comments within 2 weeks of the due date or the date which you submitted your work – whichever is later. You may be required to attend an interview with the marker to answer questions about your work; if this is the case, your mark will be withheld until you have attended.
Continue to the next page for the Marking Criteria/Rubric
Marking Criteria/Rubric
Student Name: ______________________ Student ID: ______________________
Requirement Marks Awarded
Screen 1: Menu
A menu screen is the first screen included in the application
All three options are included and clicking on them opens the correct screen
[0.5 marks each for inclusion of each option that opens the correct screen]
1
1.5
Screen 2: How to Play
Input/output elements included on this screen appropriate for requirements
Game instructions are loaded from File and displayed on the screen
Button exists that navigates back to menu screen
1
1
1
Screen 3: Quick Game
Input/output elements included on this screen are appropriate for requirements
Random numbers are generated correctly and displayed on screen
Target number is generated correctly and displayed on screen
Timer functionality works correctly
Appropriate event(s) handled when user selects numbers in the game screen
Game logic works correctly if the user “wins” a game round
[5 marks if works correctly; 2.5 marks if works with some issues; 0 marks if not implemented]
Game logic works correctly if the user “loses” a game round
[5 marks if works correctly; 2.5 marks if works with some issues; 0 marks if not implemented]
The user is prompted to play again or exit the game after losing with “Play again” and “Exit to menu” choices performing correctly
[1 mark for displaying the prompt; 1 mark if “Play again” works; 1 mark if “Exit to menu” works]
1
1
1
1
1
5
5
3
Screen 4: Custom Game
Input/output elements included on this screen appropriate for requirements
User can select option for timer / no timer
User can select option for increasing difficulty
User can input minimum and maximum number
Validation is implemented and is robust to invalid inputs
Custom settings are passed to Screen 3 and loaded correctly when the user starts the custom game
1
1
1
1
1
2
General Programming Requirements
[For each of the following criteria – full marks if included and no issues; half marks if included by some issues; no marks if not demonstrated in solution]
Has used TextBoxes, CheckBoxes, Labels, and Buttons appropriately (including using their action blocks and event blocks)
Has used the screen-changing mechanisms correctly and appropriately
Has used repetition construct(s) to repeat code sequences appropriately and in appropriate places
Has used decision constructs appropriately / in appropriate places
Has formed appropriate boolean and relational expressions
Has used the list construct for appropriate purposes and used its action blocks in an appropriate manner to manipulate/use lists.
Has formed procedures appropriately and in appropriate circumstances
Has used the File component appropriately to read a file
Has used the Clock component and “time instant” values appropriately
1
1
1
1
1
1
1
1
1
The names used for variables, components, procedures and their argument slots are appropriate and clearly communicate their purpose in the code 1
The app is designed to be robust and does not crash unexpectedly 2
Brief Report
Three (3) events are adequately modelled using pseudocode
[0.5 marks each for inclusion; subtract 0.25 marks for incomplete or difficult to follow pseudocode]
Examples and explanations are provided for each of the 12 components/concepts listed in the General Requirements for Coding section
[0.5 marks each for inclusion of all 13 elements; subtract 0.25 marks for incomplete or poor explanation; 0 marks for any that are not included at all]
1.5
6
Total: 50 marks
Total Course Marks: 20%
Feedback: