Reference no: EM131470750

Introduction

The Final Project gives you the opportunity to apply the object-oriented software development skills you have acquired during the course to a significant but moderately-sized application. The following sections describe the general behavior of the application, the simulation, and the deliverable requirements for the project.

The final project for this class is a built upon your homeworks. You are going to create a very simple version of Asteroids, but with shapes.

Objectives

The objective is pretty simple. Create a keyboard driven video game, with you the player in the center of the screen.  Shapes will enter the screen and you will need to shoot them.  If any of the shapes collide with your ship your game will end.

What I will provide:

A template GUI to start with.

Trapping the keys and bound methods for them.  You can find this

Configuration

Configuration.json is the games overall configuration file.  Since this is a first attempt at such a project we may need to add additional parameters. You can use the ShapeParser as an example of how to parse this file.  I would recommend you add additional utility methods to the Extractor utility class if needed.  You may want to consider a singleton that stores all the configuration data.  It will help you not only with design but the ability to hardcode debug values in it instead of having to constantly modify the configuration.json.  The configuration file contains only best guesses as to what values to put in.  You should adjust them accordingly for development then pick ones that are realistic for final release.  Hint: By having slow speeds you can easily validate your game visually.

Below are the fields:

"game"- The main key for the file.  Not used for anything internally.

"framespersecond" - int - The number of framespersecond, or the overall game speed.  Use this value in Motion.java.  Replace the 'FRAMES_PER_SECOND' with a call to your Configuration managers method for framespersecond.

"shotspeed" - float - The speed at which your shots will travel.  Shots are not affected by friction.

"forwardthrust" - float - Each tap of the forward thrust increases the player's x/y speed by 1.  Remember in graphics 'up' is -y.  I will provide you with the algorithms for this.  Basically if the nose of the ship is at 0 degrees it's cos 0 degrees, sin 0 degrees or +1.0x, 0y.  If it's at 45degress, it's 1/sqrt(2),               -1/sqrt(2), and at 0 its 0,-1.  Again remember for y it's inverted.  I will double check to make sure this works.

"shapes" - float -  This is the number of shapes to start with.  You could use this or even create a random shape factory that creates a shape at some arbitrary condition or time.

"reversethrust" - float - This is the 'new' additional feature of ours versus classic Asteroids.  While you can rotate around and use forward thrust to slow, we'll also try this.  It's simply inverting the values of forward thrust and should be a line of code literally.

"friction" -  float - This is the speed at which the ship slows because of friction in encounters.  Try adjust accordingly.

"leftright" - float - The amount at which the player ship rotates left or right per key input.

"color" - integer - The ships color.

"borders" - String - This is how your ship will react when it hits the border, just like homework 3.  This will give you a new dimension to the game and comes at no additional work.  You may even want to consider additional 'border' options like 'Explode'.  That is if you ship touches the border it will be crushed.

Shapes

shapes.json is the games overall shape file.  You can use this to adjust your shapes initial location, speed, etc.  You may even want to consider writing a Shape factory that can generate random shapes indefinitely as an alternative.  This will give you unlimited play.

Everything in the original shapes.json will remain.  Additional parameters are:

"size" - string - "large", "medium", "small".  I would recommend you set all your initial shapes to 'large' but you don't have to if you do your code correctly.  The shapes when they are shot go from large to medium to small.  When small shapes are shot they disappear.

"score" - an integer - the initial score for the object.

"multiplier" - an integer - the score for the next object size.  Example: Say you create a 'large' square worth 10 points and multiplier of 10.  Then mediums are worth 100 and smalls would be worth 1000.

"children" - an integer - when a shape is shot it will break into smaller objects of the same type.  That number of smaller objects is determined by the 'children' value.

Controls

I have provide hooks in main.se450.keyboard to trap various keys.  You may add others as you wish.

The keys I have implemented are:

'Q' - Quits the game.

'Space' - Fire.  Only plays the sound.  You need to do the graphics and logic behind it.  I'll provide 'hitTest' methods for you by end of week so you can determine if a shot is hitting a shape (as well as a shape hitting your ship)

 'T' - Toggle. Toggles or (pauses/resumes) the game

Here is what you need to do:

 '1' - Starts the game.  You need to play your player in the center of the screen.  Then bring in the shapes from the borders.

 'B' - HyperSpace.  This one simply generates a random area within the boundaries for your ship to 'teleport' to.  Reentry is dangerous.  Use sparingly.  This method is a great candidate for TDD.

 'L' - Rotates the ship counter-clockwise the amount defined by the 'leftright' value.  Note, this is a continuous tapping at the moment.  I haven't investigated the capability of 'continuous' key input yet.

 'R' - Rotates the ship clockwise the amount defined by the 'leftright' value.

 'F' - Forward thrust.  The amount to increase the players speed in the direction of the ships nose. The value is based on the forwardthrust value in the json configuration file.

Optional:

 'R' - Reverse thrust.  The amount to reverse the players speed in the direction opposite the ships nose. The value is based on the reversethrust value in the json configuration file.

 'S' - Shield.  Protects the ship from being destroyed by Shapes or borders.  3 uses that last 5 seconds each.  When shield is on it should draw a circle around the ship for 5 seconds.  If the border value is Explode and the shield is on the ship can either explode, stop, or bounce back.  At this point its purely optional.

Sounds

I have provided 11 of the classic wav files.  You should at minimum implement bigexplosion, medium explosion, small explosion, and forward thrust.  I have implemented fire.wav as an example for you.  I have also provided the sound object to play the music for you.  You need to think about how you want to manage it.  You might not need to 'new' a sound object everytime you want to play it, you could probably create a Singleton that manages an instance each of all the sounds and just provide wrapper methods to the application to play the appropriate sound.  Optional sounds for saucers, slow and fast music are available that you could implement.  There currently isn't any 'enemy' ship, but if you get board you can create it.  Given this is the first time for this project the scope is not well understood.

Scoring

Per the values you set in your shapes.json file, use those values to update the JTextArea of the main GUI.  You need to think about how you want to do this.  You can have the main application become a 'ScoreObserver' or you could even override the JTextArea like I did JPanel and have it or implement a 'ScoreObserver'.  It would be easier that trying to pass around references everywhere.

Code Requirements

The application must be written in Java. Please use 1.8 or higher.

You should must write unit tests for at least two classes.

The application must use at least three different design patterns that we have discussed in class. You will be expected to demonstrate and explain the patterns in your final written description.

Report

Forty-five percent / 45% of your grade is based is based on your report, UML class diagrams and Javadocs. 15% is for the report, 15% for your class diagrams, and 15% for your Javadocs respectively.  Although no specific style guidelines are being enforced, the report must be presented in a neat, legible, and consistent format.

The written report should be structured as follows:

Title page with your name at the top.

Discussion of your solution. Give an overview of your solution, the challenges, and what areas you completed and what areas you did not.  Detail any needed setup such as configuration files, what keys you added or changed, and any other information need to use the application.

Discussion of patterns. Indicate the design patterns used in your project. Detail at least 3. For each pattern, note the specific problem in your project that the pattern solved. Also indicate the classes involved and briefly discuss the implementation of the pattern.  You may use the patterns such as Singleton, Observer, Factory.

UML Class diagram. Include the overall UML class diagram for your application. You only need to detail the important details.  Create high level classes and their dependencies.  Be sure to show multiplicity, important class relationships, utility classes, interfaces, etc. Show attributes and methods only if they are crucial to understanding the class relations.  Think of your audience as a business leader with some technical knowledge rather than an engineer implementing the design.Please do not use tools that automatically generate diagrams from your code.  They are unreadable.  Unreadable, bloated UML diagrams are worthless and will be graded accordingly.

Create Javadocs for the most important classes in your application.  Make sure that the javadocs can be navigated through a browser.  Create meaningful, concise information.

Deliverables

Submit a zip file of your project and report.  Place the report in your project folder at the top level, naming it Report.  For the project you must include any important libraries and configuration files that project depends on.  You do not need to include the bin folder.  Once you have these files in your project folder, right click on your project folder and Compress (Mac) or Send To Compressed (Windows).  Now take this zip file and submit it to D2L.  Any submission not conforming to this format will lose 5%.  It's time critical to alleviate any issues with project structures in order to get all the finals and final projects graded by the day grades are due.

Test your zip file by unzipping it into a fresh directory, import it into Eclipse and make sure everything works.  Projects will be graded accordingly if they cannot be unzipped and imported easily into Eclipse.

Attachment:- Assignment File.rar