Individual Project
Individual Project
Introduction
The aim of this project is to develop the "Sudoku" game in Java, demonstrating its
execution in the in the PandionJ environment, using the Color and ColorImage classes
provided. To this end, three classes should be developed:
● a static SudokuAux class with useful functions and procedures for creating and
manipulation of boards and their visualization in an image;
● a SudokuBoard object class for the logic and state of the game;
● a class of Sudoku objects for managing the game, including loading and saving files.
The solution developed should make use of the ColorImage, ImageUtil, and Color
classes provided in the practical classes, and the Java String class. The use of other
classes is not allowed.
It is recommended that the project be developed in stages, as follows presented below.
It is not appropriate to move on to a later stage without having the previous one(s)
minimally functional.
Part 1: SudokuAux
Objective: To develop a static SudokuAux class with procedures and/or functions for
creating, manipulating, and visualizing the game board.
This class should have functions and/or procedures for:
1. Validate whether a 9x9 matrix of integers represents a valid Sudoku, where the value
zero represents an unplayed position.
2. Generate a game matrix given a valid complete solution (without zeros), changing it
so that part of the numbers in it are replaced by
zero. A percentage should be given which determines what proportion of positions to
be zeroed.
3. Produce a String with the contents of a matrix of integers.
{{1,2,3},{4,5,6}} → "1 2 3
4 5 6"
4. Produce a color image of the Sudoku board design from a matrix of 9x9 integers. It
may be useful to develop auxiliary procedures to parts of the objective (e.g. grid
drawing, number drawing).
5. Given an image resulting from (4), change the position of the image on the board,
providing a coordinate and the number to be placed.
6. Given an image resulting from (4), mark a line on the board with a red outline
outline (to signal that it is invalid), providing the index of the line.
7. Similar to (6), but for columns.
8. Given an image resulting from (4), mark the segment with a red outline
(to signal that it is invalid), providing the segment index. A segment corresponds to one
of the nine 3x3 squares.
Part 2: SudokuBoard
Objective: To develop a class of objects for manipulating the Sudoku game. This
class should have functions and/or procedures for:
1. Create a game by providing a matrix of 9x9 integers (to be validated).
2. Obtain the number that is in a coordinate, or zero if it is not filled in.
3. Make a move giving the coordinate and the value. A move that
overlaps with a number in the initial matrix. On the other hand, the move may result in
an invalid board.
4. Make a random move on one of the empty positions, only respecting the rule of
of not duplicating numbers in a segment.
5. Reset the board to its initial configuration.
6. Obtain the segments that are not valid for the Sudoku solution, i.e. that
contain repeated numbers.
7. Get the rows/columns that are not valid for the Sudoku solution, i.e. the ones
that contain repeated numbers.
8. Find out if the Sudoku has been completed.
9. Allow you to cancel moves with an undo mechanism, with enough memory for the
number of empty starting positions.
Part 3: Sudoku
Objective: To develop a class of objects to manage a Sudoku game, its loading and
saving to files. This class will be the one that controls the execution of the game,
coordinating changes to the board (SudokuBoard) and its visualization in an image.
Files
There are two types of files, described in the following table. Other forms of
representation can be used, as long as the same information is stored.
Complete Sudoku game, which will Current state of a Sudoku game, where
be used to generate different the initial board is also stored.
random games.
A Sudoku object should be created by providing the name of the file and a percentage
for the difficulty. The objects must have two attributes:
1. A SudokuBoard object with the current state of the game;
2. An image (ColorImage) representing the game's "screen", which changes as you play.
changes as moves are made.
There should be operations for:
1. making and canceling moves.
2. Saving the state of the game to a file (*.sudgame).
3. Load a game by providing the name of the previously saved file (*.sudgame). It is not
relevant whether the saved file corresponds to the Sudoku initially loaded.
Execution
To test the game in PandionJ, we recommend the approach illustrated in the following
code below.
Evaluation
In the project, the visual/aesthetic choices of the game will not be valued. The project
will initially be evaluated in functional terms, i.e. whether the functions and procedures
produce the expected results and the objects of the types of classes to be developed
have the expected behavior, regardless of how they are implemented.
This first assessment will result in a grade (A, B, C or D). Depending on the quality of
the code, a penalty may be applied, which implies a downgrade, e.g. functional
classification A with poor code quality is downgraded to B.