PLEASE WRITE THIS IN JAVA

This program consists of an overhead view of a text-based strategy combat simulator of orcs vs. elves. Initial positions of the armies will be read from a starting text file (using the prewritten Java classes that have provided). To make it easier to test specific cases the user will specify the name of the input file. After the starting positions have been read into the program it will run on a turn-by-turn basis. Each turn the state of the world will be displayed. After displaying the state the orcs and elves will move and then attack the members of the opposing forces. Movement will stop for an individual entity when: 1) the edge of the 'world' is reached 2) an obstacle is encountered (another entity) 3) there is an opposing entity an adjacent square (orcs and elves are in opposition). You need some sensible rules for handling special cases that arise during movement (e.g. don't move an entity more than once during a turn and multiple entities should not move into the same location during a turn).1 Casualties who have fallen unconscious (hit points reduced to zero or less) after combat will be removed at the end of the turn. The changes caused by movement and combat will be displayed during the following turn. Before moving onto the next turn the simulation pauses and waits until the user hits enter before moving onto the next turn. The simulation repeats the cycle for each turn until one of the end game conditions has occurred.

1 One approach: The entities at the top move and attack before the ones below them, entities to the left move and attack before those on the right.

Classes required:

You must use these starting classes. Except for the two File I/O classes you can modify these classes by adding new code but you cannot delete or otherwise modify existing code. You cannot make any modifications to the two File I/O classes. You must follow these requirements in order to get credit for this assignment.

Simulation: starting execution point. You can probably keep the main method very short and write your code elsewhere.

Entity: the soldiers in the simulation, an entity can be either an orc or an elf. The entities are distinguished by: appearance ('E' vs. 'O'), hit points or how much damage they can receive (10 for orcs, 15 for elves), damage inflicted when attacking an enemy (3 for orcs, 7 for elves). Damage inflicted on an opponent is deducted from the opponent's hit points.

FileContainer: a helper class for class FileInitialization. Do not modify the code or your mark may be affected.

FileInitialization reads the starting positions of elves and orcs from the file. Do not modify the code or your mark may be affected. Usage format: FileInitialization.read(); Example usage (because the method is static no instance should be created) Entity [][] aWorld = FileInitialization.read(); // Array 'aWorld' is now initialized with the positions specified in the text file.

GameStatus: tracks the state of the simulation (whether it's in debugging mode or not). The state of the flag (debugModeOn) will be determine if debugging messages appear or not. Some program features will require specific debugging messages to appear in order to make it clear to your marker that the feature is working correctly. That's why those features require that the user can toggle debugging mode in order to be awarded credit for said feature. An explicit clarification: The use of a debugging flag (or debugging flags if you decide to have different debugging messages appear under different situations) is the sole exception on the prohibition on the use of variable static class attributes. if (GameStatus.debugModeOn == True) System.out.println("<<< Debugging message >>>"); The following class is only nominally implemented. Likely much of the program will be written here. But make sure that you don't include all your code here! Attributes and methods must be logical to a class. World: contains simulated world in the form of a 1D array of references to Entity objects. Be cautions of implementing everything in this class! Some behaviours and attributes of the program will belong in other class definitions. For one example of illustrating how responsibilities are split between a container class and the objects it refers to you should watch the video from my lecture for the week of Feb. 7 - 13 specifically the "Doctor Who".. The next class can be useful for tracking locations in the 2D array. You can use it as you desire. However, your solution must still follow good programming conventions (e.g. clear self documenting code). If you don't use this class take care that your alternative for tracking locations is still an approach that follows good design principles. Location: a wrapper class that can store a (row/column) value. If you wish you can implement other classes but again your design must be logical and follow the good design principles that you have been taught. Starting data files: While you can change the contents of the starting file for testing make sure that it always remains 10 characters by 10 characters in size. Also make sure 'empty' locations are still filled with spaces! Tip: you can see spaces in your editor if you open a .txt file in Word and turn on formatting marks. Be aware that your markers may produce different versions of input files for testing purposes but all test files will conform to the basic requirements (10x10, valid characters will consist only of: 'O', 'E' or spaces). Your program should be able to properly handle anything that they come up with that is within these parameters. The position of a character in the text file will correspond to the position of an array of "Entity" in the simulated world. Each 'O' in the text file becomes an orcish fighter while the 'E' becomes an elven warrior. Both are instances of the Entity class each with a different values for attributes such as: hit points, appearance and damage. Empty spaces will become null elements in the array. Link to some sample data files. Program features (Features marked 'Debug must work first' require that debugging mode can be toggled and will require specific debugging messages to appear in order to be awarded credit for that feature. Output must be clear, correct and reasonably formatted). Program runs endlessly until an end game condition occurs (loop can be endless for credit for this feature, end game conditions are separate credits) with a prompt to hit enter at end of each turn. The user can toggle debugging mode along with appropriate message as the debugging state changes. The option to toggle will occur at the end of each turn. The user can type in 'd' or 'D' and enter to toggle debug mode after which the simulation proceeds to the next turn. Typing anything else (along with enter) will simply advance to the next turn. Displays the array with bounding lines around each element: above, below, left and right. (Debug must work first): Orcs move diagonally downward (to the right and down a row). Debugging messages must show the previous (row/column) and the destination (row/column) before and after the move for each entity. (Debug must work first): Elves move diagonally upward (to the left and up a row). Debugging messages must show the previous (row/column) and the destination (row/column) before and after the move for each entity. Boundary checking prevents orcs and elves from moving past the bounds of the array. Elves and orcs will only move onto empty squares. (Debug must work first): Entities only move if they are not adjacent to an enemy. Debugging messages must show the (row/column) of the entity that is constrained from moving and the (row/column) of the adjacent enemy opponent. (Debug must work first): Entities can attack members (clarification: entities only attack once per turn) of the opposing side (no marks if same side attacked). Debugging messages must show information about the entity doing the attacking: row, column and its appearance. Also the debugging messages must show information about the entity being attacked: row, column, appearance, its original hit points and the hit points after its been attacked. (Clarification: Entities stop moving when they are adjacent to an enemy because they are no in range to attack each other. An entity will attack one adjacent enemy). Unconscious entities (with zero or fewer hit points) removed at the end of the turn. (Clarification: unconscious entities don't get to attack back). Can determine when the orcs have won (there are no elves remaining but there's at least one orc), game ends with appropriate status message. Can determine when the elves have won (there are no orcs remaining but there's at least one elf), game ends with appropriate status message. Can determine when there is draw (no entities left), game ends with appropriate status message. (Debug must work first): Can determine when there is a ceasefire (no attacks have occurred for 10 successive turns), game ends with appropriate status message. The debugging message must display (and clearly label) the number of turns that have passed since an attack has occurred. Extra bonus features. You can be awarded a bonus mark (Bonus is where GPA > 4.0) for this assignment if you implement all of the above features correctly and completely as well as meeting style and documentation requirements (GPA = 4.3). This is highest grade that you can be awarded for this assignment. For students who want an additional challenge or an alternative way of earning your marks (i.e. completing the multi-media features instead of one of the features above) there are two additional features listed below. Because these last two features are an extra bonus you will need to learn how to use the necessary Java classes on your own. (This is an exception to the prohibition on using prewritten Java classes). However, if you use Java classes other than the ones provided by Oracle then you must do the following: Include the .java files for all classes.

NEED ASAP