Hello, dear friend, you can consult us at any time if you have any questions, add WeChat: daixieit


IFN563 Project Specification


Preliminary design tasks

Weight: 30% (three 10% weekly submissions)

Due: Sundays in Week 2, 3, 4


Final design report and implementation

Weight: 70% (single submission)

Due: Sunday in Week 6 (5 September)


Overview

This assessment is individual work and all tasks are to be submitted via Blackboard. While you can discuss the assessment with your tutors and peers, your submissions must be your own original work.


The objective of this assessment is to gain practical experience with object-oriented software development through object modelling with design diagrams and applying standard software design principles and patterns. This understanding is to be demonstrated by creating and documenting an object-oriented design and implement it using C# for a larger real-world motivated problem.


Description

You are to provide a reusable framework for many two-player board games. To demonstrate that your framework can be easily adapted to different games, your design must accommodate all the following games in the same software:

● Reversi aka Othello. 8x8 board, the winner makes pieces of their colour constitute a majority of the pieces on the board at the end of the game. (Wikipedia)

● Gomoku aka Five in a Row. 15x15 board (you can use a smaller board if that helps the UI), the first player forms an unbroken chain of five pieces horizontally, vertically, or diagonally. (Wikipedia)

To demonstrate the feasibility and effectiveness of the design, you must implement one of the above games using C# that corresponds to your design.


Requirements

Your design should extract as much commonality as possible from the different games so that the framework is extensible and reusable for different games.

Your design should cater for different modes of play, including:

● Human vs Human

● Computer vs Human

With human players, the system must check the validity of moves as they are entered. With computer players, the system can randomly select a valid move.

Games should be able to be saved and restored from any state of play. Moves should be undoable and redoable. A game should be replayable from any position. This requirement applies to saved games as well (so the history of moves rather than just the current board state needs to be saved).

A good design of such software should be extensible to accommodate different user interfaces, for example, a graphical user interface (GUI) or a command-line interface (CLI), i.e. the user can choose which UI to play the game. However, your implementation only needs to provide a CLI user interface (see more comments on this below).

You should provide at least a primitive online help system (i.e. accessible within the running game, rather than an offline help document) to assist users with the available commands (also give some examples if they are not obvious to use).


Comments on requirements

The requirements are what you should aim to achieve in your project. Even if you are not able to implement all features, you should at least cover all requirements in your design. 

Some requirements may be vague and open to interpretation. As long as you clearly state any assumptions you make in your design report, we will accept reasonable interpretations.

The important aspect is that your design for the core structure and functionality of the two-player board game meets the requirements, in a clear and easily understandable way. You should steer your design towards a general framework and consider your implementation as a proof-of-concept of your design, rather than a fully featured, highly intelligent game-playing program. Be sure that your implementation must correspond to your design.

Your implementation must be a C# console application and provide a text-based command-line display (i.e. using either ASCII or Unicode on a command-line console interface) of the game as it is played. Some marks have been allocated for usability, so be sure that whatever interface you use, the commands are simple and clear. The screenshot shows a simple example of playing a game of Tic-tac-toe by two human players, displayed in Unicode.


Submissions

Please submit your assessment via the IFN563 Blackboard website under the “Assessment” section. There are three weekly submissions for the preliminary design tasks and one final submission for the final design report and implementation at the end of week 6.


Preliminary design tasks (total weight: 30% over three weeks)

The purpose of the preliminary design tasks is to provide checkpoints on your progress and give you an opportunity to receive feedback and improve the overall design of the project in the final design report.

The weekly design reports should record your design based on the project requirements. No implementation detail should be provided in these submissions. For each submission, you should only submit one PDF document up to two pages in length. Detail submission information will be released in Week 2, 3, 4 workshops on Blackboard.


Final design report and implementation (total weight: 70%)

For the final submission, you are to submit a design report in one PDF file and a ZIP file containing all your C# project files. The submission link will be available in Week 6.


Final design report

You should only submit one PDF document with no more than 10 pages in length (A4 page size with 2cm in margins on all sides; 12-point Times New Roman or 11-point Arial font or something equivalent, and in single space).

Your design report should include:

● a statement of completion (half page), clearly declaring the requirements that have and haven’t been implemented. This declaration must be complete and accurate, in order to receive marks for the “Fulfilment of requirements” in the marking criteria.

● an overview of your final design (one page). You should provide a summary of changes from the preliminary design including both what and why changes were made.

● detailed design documents (at most four pages), including a class diagram, two object diagrams and two sequence diagrams. You don’t need to provide CRC cards, because they should be reflected in your class diagram.

● identification and a brief justification of design principles and patterns that have been used (one or two pages). For each design pattern, you should indicate the participating classes (in design diagrams) and justify their use in your design with a few sentences.

● a brief document on how your program can be executed (at most one page).

● a short summary of classes/interfaces (one page) to be reused from existing libraries and frameworks. For example, if you use the Collections library, just list the classes you will use, without any further explanation.

In this project, you will be marked for the simplicity and elegance of design. It is in your best interest to make your design as neat, clear and understandable as possible. In general, your detailed design should speak for itself. Only include explanations of your design where your intentions may not be clear, but this should mostly be covered by the use and justification of design principles and patterns as requested above.


Implementation source code

You must submit a working implementation including full C# source code. You should zip all your project files and upload this ZIP file onto the IFN563 Blackboard website.

Your class implementations must be strictly faithful to the documented class designs in your final design report. You do not need to provide a user guide or tutorial, but in your design report, you must clearly document how your program can be executed. The submitted project files will be compiled and executed from Microsoft Visual Studio installed on QUT computers. You must make sure that your submitted code can be compiled and run properly from QUT computer labs (Microsoft Visual Studio 2019 with .NET Core). Uncompilable or inexecutable source code cannot be marked and will receive zero for implementation.

Plagiarism undermines academic integrity and is not tolerated at QUT. All submissions may be scanned for code plagiarism against online code repositories.