GoAssignmentHelp
+61-283-206-023
+1-617-933-5480

An Adapted Version of Chain Reaction

1/10 APS106 2012 Project An adapted version of Chain Reaction The objectives of this project are twofold: (i) to strengthen your programming skills, and (ii) to provide you an opportunity to develop a complex project as a team. You are required to implement material covered in the APS106 course in a large C program that fulfills the requirements described below. Students will work together in teams, and students (even on different teams) are encouraged to learn from one another. However, each team is expected to develop its own project, and no teams should share code. The evaluation process at the end of term will include an automated and sophisticated comparison of codes that will identify instances of similarity. Such instances will be examined closely. Violations of the above rules will be dealt with in accordance with the University of Toronto’s Code of Behavior on Academic Matters. In case of ambiguities or errors in these instructions, we (the APS106 instructors) may clarify/modify them as the term progresses. IMPORTANT DATES ? March 5 -team registration ? April 9-11 -contest (optional) ? April 13 at 3:00 -submission deadline (report and code) PROJECT COORDINATOR: Babak Samareh (aps106ta@mie.utoronto.ca) -make sure you begin the subject line with “APS106”, as he’s going to get a lot of email. LOGISTICS Students will work in teams of 3-4 people. No exceptions. Teams may be composed of students from any of the five lecture sections of the course. Lists of team members (names and student numbers) must be submitted via email to project coordinator Babak Samareh by the end of the day, March 5. If you cannot find others with whom to work, or if two of you are looking for a third and/or a fourth member, you have two options: (i) send an email to Babak; he’ll connect you with others who are looking for group members (ii) and/or post a note on the website discussion board, in the Project forum. Note that you are responsible for finding a team. We’re happy to help, but...

APS106 2012 Project

An adapted version of Chain Reaction

The objectives of this project are twofold: (i) to strengthen your programming skills, and (ii) to provide you an opportunity to develop a complex project as a team. You are required to implement material covered in the APS106 course in a large C program that fulfills the requirements described below. Students will work together in teams, and students (even on different teams) are encouraged to learn from one another. However, each team is expected to develop its own project, and no teams should share code. The evaluation process at the end of term will include an automated and sophisticated comparison of codes that will identify instances of similarity. Such instances will be examined closely. Violations of the above rules will be dealt with in accordance with the University of Toronto’s Code of Behavior on Academic Matters. In case of ambiguities or errors in these instructions, we (the APS106 instructors) may clarify/modify them as the term progresses.

 

IMPORTANT DATES

March 5 - team registration

April 9-11 - contest (optional)

April 13 at 3:00 - submission deadline (report and code)

PROJECT COORDINATOR: Babak Samareh (aps106ta@mie.utoronto.ca) - make sure you begin the subject line with “APS106”, as he’s going to get a lot of email.

LOGISTICS

Students will work in teams of 3-4 people. No exceptions. Teams may be composed of students from any of the five lecture sections of the course. Lists of team members (names and student numbers) must be submitted via email to project coordinator Babak Samareh by the end of the day, March 5.

If you cannot find others with whom to work, or if two of you are looking for a third and/or a fourth member, you have two options:

(i) send an email to Babak; he’ll connect you with others who are looking for group members

(ii) and/or post a note on the website discussion board, in the Project forum.

Note that you are responsible for finding a team. We’re happy to help, but the sooner you let us know that you’re looking, the more quickly we can connect you to a group.

 

PROJECT DEFINITION

The project is to develop a text version of Chain Reaction, an online game you can play at:

http://www.clickmazes.com/chain/ixchain.htm

Your version of Chain Reaction will be text-based. The board will be a square grid of M rows x M columns, where M can vary between 3 and 9. The board will be filled with a combination of rectangles and circles, with their colors being red or blue. The aim is to cross off all the symbols by visiting them one a time ensuring each symbol matches the last either in shape or color (or both). Each position can be visited once only. At each turn you can move horizontally or vertically any distance. The start position is always at the top left corner of the board but the finish square could be anywhere. A sample board can look like this:

 

Image====

 

What’s your version going to look like? It’ll have to be a little different than the online version; here’s what we expect:

  • Your program will begin by asking a player whether they’ll provide an initial board (via a file), or whether they’d like your program to initialize a board randomly: 
  • If from a file, your program will ask for a file name and read the file. The specifications of the input file are in Appendix 1. Sample files will soon be available on the website, although your code is expected to read any valid input file
  • If a random initialization, your program will ask the player to specify the board size M x M. Your code will then randomly generate the initial board.
  • Once a board has been loaded or randomly generated, your program will then ask whether the user wants to play the game (Interactive Play), or whether the user wants to watch the computer to play the game (Computer Play).

 

INTERACTIVE PLAY

The following two pages provide details of the two play options. Your game does not need to look exactly as described, as long as the rules are followed.

 

If the user wants to play the game (Interactive Play), your program will display an initial board (read from a file or generated randomly) and ask the user to select a position on the board; for example, the board shown on page 2 might look something like this:

 

Insert Image

 

Notice that in order to make this work without graphics, you can represent the shapes with uppercase characters (C = Circle, R = Rectangle) and colors as lowercase characters (r = Red, b = Blue), and the current position as *, although you can do this as you like. The game will always begin in the top left corner. Notice too that you’ll want to provide a player a way of exiting the game at any time.

When the player chooses the next position, your game will check its validity, clear the output console, and show the board again; for example, if the player enters 13 for the first row and third column, the next board will look like this:

 

Insert Image

 

where the X in position 11 shows that this cell has already been visited.

 

COMPUTER PLAY

  • As an alternative to interactive play, the user may request that the program play the game. In this case, he/she will simply watch as your program plays the game. There are many invalid paths available for any combination of shapes and colors. Please note that an invalid path is a valid set of moves that ends in a dead-end without visiting all the cells. The number of solutions depends on the configuration and can vary from 0 to a large number. So, in the computer play mode, the program should find all the invalid paths and solutions. If there is no solution, then it should inform the user with a message. If solutions exist, the program should walk the user through a step by step demo for each complete path. For example, your program may display something like this:Insertand after a couple of seconds delay, will clear the console and then show the following:
  • How to clear the console screen? This can be done by sending the clear screen command to the output console by issuing a system (“cls”); where the system function is in stdlib.h.
  • How to pause your program, so that a user can follow what’s happening with the computer play version? The C statement sleep(sec); can be used to pause your program. The int parameter to the sleep function gives the length of the pause, measured in seconds.

 

A FEW OTHER DETAILS

Marks will be awarded as follows:

Initialization

3

Game display

2

Interactive game

3

Log file output

1

Computer-play

3

Final report

3

  
 

15

 

The core of the software (initialization, game display, the interactive game, and writing a log file) will be judged both on whether or not it works properly, and on the details of implementation. Code that is difficult to read may be awarded fewer marks even if it works. We expect code to contain meaningful comments.

The code associated with computer-play (three marks) will be awarded one mark if it works at all, two marks if the approach to find all the paths is non-trivial, and three marks if a sophisticated approach has been implemented. Remember that these algorithms must be documented in the final report. Expectations for the final report (worth three marks) are specified in Appendix 4.

 

APPENDIX 1 -INPUT FILE SPECIFICATION

Your program must be capable of reading an input file. The first line of the file will specify the integer M that defines the size of the board: M rows x M columns. The remainder of the input file will specify the board.

The following is an example input file for the board illustrated on page 2:

3

Cr Rb Rr

Cb Rr Cb

Rb Cb Cr

You may assume that each line in the file ends with a simple newline character. When playing from an input file, the program should ask the user for an input filename.

The following lines of C can be used to read in a filename and then open the file:

 

Insert Images

APPENDIX 2 - LOG FILE SPECIFICATIONS

From top to bottom, a log file should contain:

the names and student numbers of the team members

the initial board, in the same format as in an input file (see Appendix 1)

if the game is interactive, a list of accepted moves. The list should begin with the string “START” on its own line, then “INTERACTIVE” on the next line, then the list of moves selected by user, and then the string “END”. The following illustrates the beginning of such a list, and corresponds to the solution of board illustrated on page 2:

START

INTERACTIVE

11, 13, 33, 23, 21, 31, 32, 12, 22

END

in the case of computer play, the list should begin with the string “START” on its own line, then “COMPUTER” on the next line, then list of all the valid paths found, then the total number of solutions and invalid paths on separate lines, and then the string “END”. The following illustrates the beginning of such a list:

APPENDIX 3 – END-OF-TERM CONTEST

An end-of-term contest will be run for those groups that have written a Computer Play version that attempts to find all the possible paths for a given board.

  • a contest input file will be posted on the course website by 9:00 am on April 9
  • teams will have the following day to use their programs to calculate all the possible paths
  • teams may then submit their program and one log file by 9:00 am on April 11 - submission instructions will be distributed closer to the contest date
  • a team that submits more than one log file will forfeit its chance to compete
  • the log file must be as specified in Appendix 2, or the entry will be deemed ineligible
  • the winning team will earn 2 bonus marks for the project; the five next best teams will earn 1 markcontest winners will be announced before April 1
  • contest winners will be announced before April 1 

APPENDIX 4 – FINAL SUBMISSION

  • A final report and C source code is due by 3:00 pm on April 13, according to the following guidelines:
  • The report will be graded considering both content and clarity, and will be no more than five pages long. Additional pages will be discarded, and not read. What to write? Think of it as a combination User and Technical Manual. Begin by describing how to run the code and play the game, as if someone was unaware of how to do that. Then provide details of the code: an overview of the overall structure, and of any interesting algorithms (e.g. how the computer play works and how it finds all the possible paths). Also provide specific information on how each team member contributed to the project.
  • Submission details will be provided closer to the due date.  If anything (electronic or hardcopy) is late, the entire project will be penalized at the rate of 20% per day.

Other Students are using our All Assignment Help with GoAssignmentHelp,
Are you the only one left Behind?

Order Now

GoAssignmentHelp
Rated 4.5/5 based on 25042 reviews
Copyright © 2010-2017 www.goassignmenthelp.com.au. All rights reserved.