As you know, Arcade 24TM (A24), the modern game company has been developing their new game design, PacMan in the Multiverse to provide die-hard PacMan players with something new. That version of the game adds various monsters and maze items.

However, A24 is aware that the Multiverse alone will not be sufficient to engage the die-hard players. So, while development on the Multiverse continues, A24 has engaged your team to develop an editor and test app for another variation of the game: PacMan in the TorusVerse. You will not be concerned with the changes for the Multiverse: TorusVerse will be developed based on the simple version. Then, A24 will deal with merging the MultiVerse and the TorusVerse at some point in the future.

2.1.1 Multiple levels/maps

1. A game of PacMan consists of multiple maps; all these maps are stored in a single folder (Game Folder).

2. Each map file in the Game Folder has the extension “.xml” and is stored in xml format.

3. The maps are a grid of tiles; each tile corresponds to one location in the game map.

4. These maps include the locations of all elements; the existing property file locations become irrelevant.

5. All and only map files with names starting with a number (1, 2, ...) are included in the game. Other files in the Game Folder are ignored.

6. Maps are played in ascending number order. No two maps can have the same number. The numbers do not need to be contiguous.

7. If PacMan successfully completes the last map, it wins the game; completing an earlier map will take PacMan to the next map.

2.1.2 Portals

1. A map can now contain pairs of portals.

2. Portals are represented by portal tiles on the map; two matching portal tiles in different locations are required.

3. Each pair is connected: if PacMan or a Monster moves onto one portal, it will be transported instantly to the other portal. (To go back it would need to move off the portal and then move back on.)

These portals can be used to create a torus effect, that is, to have creatures move off one side of the map and appear on the opposite side. They could also be used, for example, to give PacMan access to an area which is not otherwise accessible (like an isolated room) or a way to bypass pursuing monsters which would corner PacMan.

2.1.3 Autoplayer

The provided basecode supports an autoplayer setting and provides and autoplayer, however you are required to provide a smarter autoplayer with potential for further improvement.

1. The game should include an autoplayer setting.

2. If autoplayer is off, the game is played interactively by a human player in the usual way.

3. If autoplayer is on, the game is played automatically.

4. The autoplayer must be capable of completing the game (all levels) in the case that no monsters are present. Note that this needs to consider the presence of any portals.

   2.2 Application Capabilities

   The system you are to develop will support editing the maps in a game folder and playing the game (either all levels or one level) to test these maps.

   2.2.1 Start Up

   1. Starting the editor with a folder as an argument will start in Test Mode, that is, start playing the game levels in that folder.

   2. Starting the editor with an existing map as an argument will start in Edit Mode on that map.

   3. Starting the editor with no argument will start in Edit Mode with no current map.

   4. Autoplay mode will be set by the property file, that is, whether play is interactive or conducted

   The behaviour in test mode is independent of whether the application is in Autoplay mode by the autoplay will be determined by the property PacMa

   2.2.2 Edit and Test Mode

   1. Whenever a map is loaded or saved, level checking (see below) is applied. If a level is being saved, it should be saved no matter the result of level testing.

   2. Only saved and loaded maps can be tested, so level checking should occur (once) before any map is tested, including when a game folder is being tested. Failed level checking should result in the application returning to edit mode on the level which failed level checking.

   3. Game checking should occur before any game folder is tested; if game checking fails, the game should not be tested and the application should return to edit mode with no current map.

   4. If Test Mode is started with a game folder, all levels are played in sequence until PacMan is destroyed by a monster or wins the game by completing the last level. The application then returns to Edit Mode with no current map.

   5. If Test Mode is started with a specific level/map, that level is played until PacMan is destroyed by a monster or that level is completed. The application will return to Edit Mode on that map.

   2.2.3 Level Checking

   1. The application should be able to check the validity of a level according to a defined set of rules.
   2. The application should be designed to allow a developer to easily modify or add checks.
   3. Where a check fails, that failure should be reported to the log file in text format.
   4. The level checks required (for the current version) follow. The text in square brackets is an example of the format required for the log file message, with pairs of numbers in parentheses being grid coordinates with (1,1) at top left.

    
   

   3 Your Task 

    You are being provided with

   1. PacMan basecode: the same codebase used as a starting point for the Multiverse project.
   2. Tile editor: a codebase which can be used to create tile-based maps for PacMan. You should create a single application with the behaviour described above. You can refactor the code as you see fit, but should preserve the playing behaviour where new functionality does not apply. For example, a level with no portals should play out like it would with the PacMan basecode.