C++ Only - Please don't copy and paste past answers

In this project, we will implement a program that simulates Langtons Ant. For explanation please read it on Wikipedia: https://en.wikipedia.org/wiki/Langton%27s_ant (Links to an external site.)Links to an external site.. Note that the Langtons Ant simulation can be considered as a cellular automaton, a model that has simple rules governing its replication or destruction.

Requirements

Langtons Ant Rule

The rule of Langtons Ant is very simple: the ant is placed onto the board that is filled with white spaces, and starts moving forward. For each step forward, the Langtons ant will follow 2 rules:

If the ant is on a white space, turn right 90 degrees and change the space to black.

If the ant is on a black space, turn left 90 degrees and change the space to white.

After that the ant moves to the next step and continue moving forward. The ant will follow these rules, and continue moving around the board, until the number of steps runs out.

Ant Class

The Ant class should contain all the information that includes:

The ants location

The ants orientation (the direction of the ant)

How do you keep track of the color of the boards spaces? How about the ants orientation?

How about class functions? Make sure only the class function can modify the variables of Ant class, which means outside program cannot directly change the variables inside the Ant class, and instead should call the functions inside Ant class to indirectly modify variables. You can determine whether you need to have a separate board class and how you should design it.

Langtons Ant Program

The ant starts at a user specified location on the board. For the initial direction of the ant, it can be either random, or fixed, or a choice from the user; it is up to your design decision. During each step, the program should print the board. If the space is occupied by an ant, no matter what the color of that square is, the program should print a * on that space; otherwise, if the space is white space, print a space character, and if the space is a black space, print a # character.

Below is an example printing output of a step of Langtons Ant with board of 5 rows and 5 columns: (Note that the space the ant is occupying is a white space)

Please consider edge cases before you start programming. For example, what happens when the Ant hits the corner or side of the board? The program cannot let the ant go out of bound or it is going to cause segmentation error. How to solve the edge case is up to your design decision, but it must be handled properly. Here are some of the actions past students have taken in these edge cases:

Skip the step forward step, make another turn and then continue on.

Wrap the board around so the ant will appear on the other side.

Turn the ant around and send it back to the board.

Important: When encountering edge cases, crashing the program, or quitting the program is not a proper solution and your grade will be deducted. No matter what happened, you cannot terminate the game before it reaches the designated step.

Menu

In this project, we are going to implement menu functions that can be reused in later programs. Menu functions are functions that prints menu options to the screen for the user, and after the user makes a choice, verify the users input, and return the value back to the program. The menu function should be easily changeable to fit whatever program you are writing.

Note: If you want to write a menu class instead of a menu function, that is fine too.

Below is the detail of the menu functions for this project:

When the program starts the menu should provide 2 options:

Start Langtons Ant simulation

Quit

If the user decided to quit, the program should quit. Otherwise, start the Langtons Ant simulation. After the simulation starts, the program should prompt user for all the information to run the simulation, including:

The number of rows for the board.

The number of columns for the board.

The number of steps during simulation.

The starting row of the ant.

The starting column of the ant.

After the simulation ended, the menu should provide user 2 choices: play again, or quit.

You can customize the menu, or how the program prompt use for inputs however you want, as long as all the above requirements are met. You can even make the simulation information prompts a menu, by providing an option menu for each information, allowing user to modify the data as they wish before starting simulation, but it is not a requirement.

Input Validation

Input validation is the testing for input that is supplied from outside source. (including human input)

Consider the following scenario: if the program request for an input of integer and the user instead input a character of t, it would cause the program to crash. But with an input validation, the error is caught, and the input is requested again, until the user input a correct type of data.

The requirement of input validation, is to make sure the program

does not crash from undesired input

request for input repeatedly until the correct data is inputted.

A good way of planning input validation is to first think about what kind of input is desired for each input in a program. For example, for choosing the starting row of the ant, what type of data is desired? Integer. What kind of integer? Depending on design, the desired integer can be positive, and not higher than the number of rows the board has.

If you would like to add more feature to your input validation, or add a limit to the integer inputs, you are free to do so, as long as it makes sense and does not affect program testing.

If you have any question, there will be a discussion section on Piazza.

Document (Design + Reflection)

You need to create your program design BEFORE you start coding. Your design needs to be included in your document.

Simply stated, program design is identifying the problem to be solved, modularizing and describing the structure of program, and making a test table to that fulfills the requirements of the program.

For test table, please include test plan, expected output, and actual output. The test plan should be robust. The expected output is based on the requirement. If your actual output deviates from your expected output, that usually means the program behavior is deviating from the requirements. Following is a Examples Test Plan.pdf

In your reflection, you should explain what design changes you made, how you solved some problems you encountered, and what you learned for this project. The TA will grade on how well your implementation matches your design.

Note: There are a lot of details that are not determined in the requirements. They are left for you to decide, as long as your program meets the requirements. For more questions or clarification, feel free to post a question on Piazza, or send an email to your grading TA.

Extra Credit (5%)

At the start of simulation, ask user would like to use a random starting location for the ant. If this option selected, you dont need to ask the user for starting location of the ant.

Note: If you are doing extra credit, you must tell the user at the beginning by printing a message, and make sure you provide the option for ants random starting location. Otherwise TA cannot grant you extra credit.

Transcribed image text