在此处复制并粘贴您的作业
[Please read all 3 pages of this document first] COSC1519 Introduction To Programming Assignment 2: Development of a Partially Complete Java Application [spec 2019.08.27; check Canvas→Assignments→Assignment 2 for updates] [The penalties for breaching academic integrity are severe - they include charges of academic misconduct, cancellation of results and exclusion from your course – Please see Academic Integrity page for further info - Do not even show your code to other students] Important: First, watch the demonstration of the gameplay shown during the week 6 lecture (27/08/2019). You are awarded marks for concisely and sensibly demonstrating concepts covered in lectures for meeting all requirement and constraints in section 2 of this document. If something is written, there are marks associated with it. Official clarifications will only be made via the relevant forums in Canvas→Discussions. 1. Background and basics: You are employed as a programmer by a game developer and, being a fan of programming, you are excited to give your new job your 100% or more. You learn that your first task on the job is to revive a game project named ‘AVIANIGHTMARE’ that has been abandoned by your predecessor who mysteriously disappeared without a trace. [Box art of game] The original programmer had demonstrated a nearly complete version of the game (27/8/2019 lecture demo) but the company only has an older set of the source files. Although this is an assignment, you must consider yourself as a professional programmer and Daryl and Gayan as your employers (i.e. the company). It is expected that you will need to independently investigate things such as what types of data some of the provided methods might need, etc. in the Java API Specification and other resources. As it is the case with real-world projects, not everything will be clear at various stages and you are expected to seek clarifications from Daryl or Gayan via the relevant Canvas→Discussion forums. Consider going to the consultation, remedial sessions and mentoring (see Canvas→Announcements for details). 103097121097110046119105106101115105110103104101064114109105116046101100117046097117 Page 1 of 3 https://www.rmit.edu.au/students/student-essentials/rights-and-responsibilities/academic-integrity https://rmit.instructure.com/courses/53308/external_tools/23547 file:///C:/Users/G/Desktop/Work/2017-S2/Java%20API%20Specification 2. Constraints, guidelines and requirements: Get the code in to Eclipse as shown in the 27/8/2019 lecture follow all of the requirements and guidelines below: 2.1) Assignment context specific constraints that you must follow: A) Any changes that you make and all code that you write must be restricted to the Enemy.java and Player.java files. B) You must not create new constructor methods. You must not change the definitions of any existing methods even in Enemy.java or Player.java (you can alter the bodies of methods in Enemy.java and Player.java, if you so wish). C) You are also awarded marks for placing only the relevant code in the relevant methods (use method names of the provided methods as a guidance). D) When a data structure is necessary, use only arrays (e.g. no array lists). E) Every method in Enemy.java and Player.java must have only one return statement and this statement must be the very last statement in the method block. 2.2) Object oriented design constraints that must be demonstrated: A) All member variables must be explicitly private and non-static. There should be no = (equals) signs where member variables are declared. All member variables must be explicitly initialised in the constructor. B) Whenever a method refers to a member variable, it must use this. (i.e. “this dot”, e.g. this.x). C) Aside from the main method in the GameManager, there should be no other main methods. D) You do not need to create methods in addition to those that are provided but if doing so, those methods must be private and not static. 2.3) General good coding practices that must be demonstrated: A) Your code must be formatted consistently (e.g. use Eclipse→Source menu→Format). Comments should not be formatted in to a vertical strip; add comments on a new line instead. B) Identifier names must follow common conventions demonstrated in the lectures and in the Java API specification. D) Add comments and explain in plain-English the purposes of segments of code that you have added. You must not comment every line. E) If you have any unresolved bugs, you must document these in the approximate locations within which they originate in your code. If you do not have bugs, you must explicitly say that there are none. Note: Being able to recognise bugs is a good thing. F) Do not use break, continue, static, System.exit… and similar statements. 2.4) Enemy.java requirements: Write code inside suitable existing methods to make the Enemy autonomously follow the Player, as explained in the 27/8/2019 lecture. In the originally provided code, all Enemy objects are created at the same coordinates; you must change this so that each Enemy object is created at the coordinates provided by GameManager at the time the Enemy object is created. The Enemy must access the Player’s coordinates via the provided GameManager reference and then follow the Player. Hint: Start by modifying the Enemy’s x and y coordinates so that it moves in some direction then change it to make it follow the Player. Near every segment of code that you have added, discuss the pros and cons of an alternative implementation (assume alternative implementation must also meet all functional requirements). E.g. what are the pros and cons of using a different set of object member variables. E.g. what are the pros and cons of making the Enemy follow the Player in a different way. 2.5) Player.java requirements: Write code inside suitable existing methods to make the Player autonomously avoid the Enemy objects, as explained in the 27/8/2019 lecture. In the originally provided code, the Player object is created at a fixed coordinate; you must change this so that the Player object is created at the coordinates provided by GameManager at the time the Player object is created. The Player must access the Enemy coordinates via the provided GameManager reference and then avoid all Enemy objects. Finally, make the necessary changes to display the player-dead.png as its image when the Player dies. Hint: Start by making the Player avoid just 1 Enemy object and then make it work for an arbitrary number of Enemy objects. Near every segment of code that you have added, discuss the pros and cons of an alternative implementation (assume alternative implementation must also meet all functional requirements). E.g. what are the pros and cons of using a different set of object member variables. E.g. what are the pros and cons of making the Player avoid the Enemy objects in a different way. When in doubt, you are required to ask either Daryl or Gayan via the relevant Canvas→Discussions forums. Clarifications will not be made via email as it is not equitable. 103097121097110046119105106101115105110103104101064114109105116046101100117046097117 Page 2 of 3 https://docs.oracle.com/javase/10/docs/api/index.html?overview-summary.html https://rmit.instructure.com/courses/53308/external_tools/23547 3. Deliveries and submissions: Your “employer” requires you to perform two deliveries of your work. There are three important dates/actions to remember. • Delivery 1 (3.75 marks): Submit Enemy.java and Player.java at the same time (together, in one go) via Canvas→Assignments→Assignment 2 Code then demo during your allocated practical in week 10, using your own computers. For this delivery, you will need to demonstrate 2.1, 2.2, 2.3 and 2.4. There is no need for 2.5 but the Player will need to move when controlled using arrow keys (this functionality is already provide) and the Enemy must follow the moving Player. Every student is given 3 minutes for the demo and you need to be able to answer the questions asked during the demo within this time to complete the demo. To be fair to all students, your instructor may stop your demonstration if you take too long. Note: Your GameManager.java, Stage.java will be replaced with the original files for marking. • Delivery 2 (2.5+3.75 marks): Submit Enemy.java and Player.java at the same time (together, in one go) via Canvas→Assignments→Assignment 2 Code at the end of week 11 and then demo that work during your allocated practical in week 12, using your own computers. For this delivery, you will need to demonstrate 2.1, 2.2, 2.3, 2.4 and 2.5. Every student is given 3 minutes for the demo and you need to be able to answer the questions asked during the demo within this time to complete the demo. To be fair to all students, your instructor may stop your demonstration if you take too long. Note: Your GameManager.java, Stage.java will be replaced with the original files for marking. A submission with a missing demonstration will not attract marks. It is fine if files are automatically renamed by Canvas when resubmitted. If your code has red dots (compilation errors), you will receive 0 for that delivery. If your code generates errors at run-time, a 50% penalty will be applied for that delivery. A late submissions will incur a 10% late penalty for each working day late; submissions will not be accepted after 5 working days from the deadline. If you wish to organise special consideration, please follow the instructions below: https://www.rmit.edu.au/students/student-essentials/assessment-and-exams/assessment/special-consideration 103097121097110046119105106101115105110103104101064114109105116046101100117046097117 Page 3 of 3 https://www.rmit.edu.au/students/student-essentials/assessment-and-exams/assessment/special-consideration