ITECH2000: Mobile Development Fundamentals - AppInventor App (Math Game) - IT/Computer Science Assignment Help

ASSIGNMENT TASK:

 

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. 

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. 

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.

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). 

Requirement

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 the inclusion of each option that opens the correct screen] 

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 

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] 

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 

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 

 

This ITECH2000: IT Assignment has been solved by our IT Experts at onlineassignmentbank. Our Assignment Writing Experts are efficient to provide a fresh solution to this question. We are serving more than 10000+ Students in Australia, UK & US by helping them to score HD in their academics. Our Experts are well trained to follow all marking rubrics & referencing style.