CSCI 448 - Mobile Application Development

Spring 2023 - Assignment 2 - Tic-Tac-Toe

This assignment is due by Tuesday, March 14, 2023 by 11:59pm.

Global Thermonuclear War

For this assignment, you will implement a simple game such as Tic-Tac-Toe. Gameplay is not the focus of this assignment, but you must follow the technical requirements listed below.

The App is comprised of four screens:

  1. Welcome
  2. Game
  3. History
  4. Settings

The Welcome screen will load when the App is launched. The other three screens will be launched via buttons from the welcome screen. Information about the game will need to be passed from screen to screen for the life of the App using a proper View Model. Be sure to use a NavGraph to allow the user to navigate through the app forwards and backwards.

The App will need keep track of how many games have been won/lost/drawn and display this information to the user. As the user navigates between screens, the score should not reset (unless the user goes through the settings, see below). Speaking of settings, however the user chooses to play the game, settings need to be tracked and applied to every game that is played. This is where the View Model will come into use.

When you create this project, set the package to include <userName_A2> and name the app <userName>_A2 where userName is your name.

An example of the completed app is shown below:


Only Winning Move

Part I - Screen One: The Welcome Screen


The layout for the Welcome Screen is very simple. Display a screen to serve as an intro to the game. This could be as simple as text or as complex as an image.

There needs to be four buttons on the screen corresponding to the following actions:


Part II - Screen Two: The Settings Screen


The layout for the Settings Screen will correspond to the chosen settings. Present the user with options that make sense for your game. For Tic-Tac-Toe, you could allow the user to choose:

Additionally, there must be a button that will clear the scores and reset the game history.

You may add as many options as you like (colors, themes, dark mode, special messages, X & O piece choices, etc.). Have fun with it!


Part III - Screen Three: The History Screen


You will need to keep a record of all games played. The exact information stored will depend on the game you choose. For Tic-Tac-Toe, this could include:

We'll then display all of the games in a scrollable list. The exact layout is to your choosing, but all game information must be displayed for each record.


Part IV - Screen Four: The Game Screen


This is where the magic happens. You can decide what the layout for this screen should be. This is where the actual game play will take place. Let the user(s) play the game.

When the game is over, display a Toast to the user with the outcome. Update the game history with the game result. Finally, present the user with a button to play again.

Play Again should start a new game using the same gameplay options that were previously selected. This button will not be visible until the game is over.

With the example of Tic-Tac-Toe, the game will need some sort of 3x3 interface for the user to select where to play. Do not use simple text output for the pieces (literally "X" and "O") but instead use Images to spice up your game with exciting Drawables. Maybe instead of X vs O, it's the Rebels vs the Empire. If it is set for two players, then play alternates between X and O. If gameplay is set to one player, then after the user places an X, the computer should play. The computer can be VERY SIMPLE. Have the computer select a random free space to play. No need for complex AI that never loses (though you can add it if you like - here are some strategy tips).


Part V - Landscape Mode


Finally, create an appropriate landscape layout for when the screen is rotated (the game and options should all be accessible from either orientation). More importantly, you will need to save the state for when the screen is rotated. The user should have a seamless experience. This means: (1) options do not get reset (2) the score does not get reset (3) the game does not get reset. From the user's perspective, nothing should change and there's no way to cheat at the game.


Part XC - Extra Credit: Animation


For extra credit, animate the change of some UI state.


Part VI - Exit Interview


Be sure to include a README.txt file containing any comments, notes to run, etc. In addition, answer the following questions in yourREADME.txt:

  1. What difficulties did you encounter navigating between the various screens?
  2. How were all the components split and organized amongst the MVVM architecture? What lived where? What advantages did this framework provide? Challenges?
  3. If you completed the extra credit, what animation did you add and where is it present in the UI?

Grading Rubric


Your submission will be graded according to the following rubric.

Percentage Requirement Description
10% Welcome Screen layout appropriately created. Appropriate landscape layout created.
10% History Screen layout appropriately created. Appropriate landscape layout created..
10% Settings Screen layout appropriately created. Appropriate landscape layout created..
10% Game Screen layout appropriately created. Appropriate landscape layout created..
20% Proper navigation between all screens using a NavGraph.
5% State is not lost during rotation.
15% MVVM architecture used correctly.
5% Game settings are tracked, can be changed, and apply to games.
5% Game is properly playable. Score is kept.
5% Exit Interview questions from Part VI are answered and included in README.txt file.
5% Submission is complete, compiles and executes without error.
+2% UI Animation applied to state change.

Submission


Please ensure your project produces an app with the name userName_A2. When you are completed with the assignment zip together your full source code (the Android Studio project), and README.txt. Name the zip file, userName_A2.zip. Upload this file to Canvas under A2.

This assignment is due by Tuesday, March 14, 2023 by 11:59pm.