Java代写:COMP3006 Runner

根据规则,代写Runner类游戏,类似超级玛丽。

Requirement

For this project you will be implementing a side-scrolling endless runner in the style of ​Super Mario Run​and ​Rayman Jungle Run​. This genre of game is referred to as an “endless runner” as the screen continuously scrolls from right to left and the player controls the main character mostly by jumping to avoid hazards like enemies, spikes, and bottomless pits. The player is usually also trying to collect treasure and power ups as well. The goal is to get experience with timers and animation in a video game.

Unlike previous projects you will be required to submit ​milestones​for this project. Each milestone will count as 20% of your grade. If you miss a milestone deadline, you will lose 20% of your grade ​whether or not your final submission is fully functional​.

  1. Milestone 1 - Your submission must include your essential classes, including the main character, levels, hazards, power ups, and your main canvas class. The classes must at least include the state (including accessors and mutators) and stubbed out methods for each class.

  2. Milestone 2 - Your submission must include an executable version of the program that displays a stationary level with all of the required visual elements on the screen. The level need not function or scroll but the main character should jump.

  3. Final Submission - Final submission; fully functioning game.

Let’s take a closer look.

The basic requirements that the game must meet include:

  • A shape or sprite that is used for the main character. This ​does not​need to be a complex shape or figure (as shown above) but can be a simple circle or rectangle.

  • The main character is at a fixed distance from the left side of the frame (typically about ¼-⅓ of the width of the frame).

  • The main character must be able to jump and is affected by gravity. This means that the character will return to the ground after jumping and can fall into bottomless pits.

  • The foreground of the levels must continuously scroll from right to left (this creates the illusion that the character is moving left to right).

  • The background of the levels must be stationary; i.e. each contains some items that do not scroll with the foreground.

  • The elapsed time for each level must be displayed somewhere on the screen (at least to 10th of a second).

  • The game must include at least two levels that are visually distinct, e.g. a day time level and a night time level.

  • There must be power-ups or treasure located on each level.

  • The game must calculate a score based on completion time and power ups/treasure collected.

  • Hazards must include both enemies/obstacles (like spikes) and bottomless pits (if the main character falls off of the bottom of the screen).

  • The player must have lives or health that is deducted when failing to navigate an obstacle or hazard.
    You ​are not​required to use images at all for this project; you can do everything with shapes, lines, and colors.

Basic Game Rules

  1. The main character must navigate from the beginning to the end of each level by jumping over hazards.

    • a. An ​intersection​between the main character’s bounding box and a hazard counts as “hitting” the hazard. How you handle this is up to you (e.g. the main character takes damage or “dies” instantly).

    • b. You may consider running into a solid wall to be the same as hitting a hazard. You may also decide to treat this differently (it is up to you).

    • c. Falling into a bottomless pit always constitutes “death” and the player must start over.

  2. Character jumping must make sense! The main character may jump or even double jump, but should not be able to jump forever.

  3. Players must have the option of jumping using either the mouse or a key on the keyboard for all controls. You will need to handle events from both (even simultaneously!).

  4. The elapsed time must be displayed on the screen somewhere. See System.currentTimeMillis() ​for ideas.

  5. Each level must include power ups (you can decide the effect) and/or treasure on each level for the player to collect.

  6. You must decide on an algorithm to calculate the player’s score after completing a level. Here are some things to consider:

    • a. Time to complete - shorter time is a better score.

    • b. Treasure collected.

    • c. Lives remaining - more lives is a better score.

  7. There must be at least two difficulty levels; higher difficulty scrolls the level faster. Remember that this does not mean creating a timer that updates more frequently, but instead determines how many pixels your level scrolls from frame to frame.

Graphical Requirements

  1. Each level must include at least two “layers.”

    • a. A stationary background with visual elements that are obvious (e.g. the sun in the mockup above).

    • b. A scrolling foreground; this will require that you animate the foreground so that it moves right to left (and the player appears to move left to right).

  2. A main character that jumps. You do not need to do anything special other than animating the character up and down when it jumps. A circle or rectangle is sufficient.

  3. At least two visually distinct levels, e.g. a “night” level and a “day” level or a “summer” level and a “winter” level.

Suggestions

  • Consider that a “level” can be created with a series of height/width attributes that define blocks for the main character to run across. You can easily draw the level as a series of rectangles. The trick is figuring out which part of the level to draw for each frame of animation.

  • Gravity determines how fast the character returns back to the ground beneath its feet when jumping or running off of a ledge. You may implement this as a constant change in the Y position for the character (you do not need to implement acceleration). Hint: the level object should know what height the “ground” is at any given point.

  • Start ​simple​and work your way up to the more complicated requirements. You will earn a far higher grade by submitting a working game that doesn’t implement the most advanced features (e.g. difficulty levels) than you will submitting a broken game. Keep in mind that extra credit features can more than compensate for core features that are missing.

  • In the spirit of starting simple, start with a flat level. Then add pits. Then add different heights.

Miscellaneous Requirements

  • Your program must be well-formatted according to standard conventions for Java as seen in the textbook and in class. You no longer earn points for well formatted code, but you can lose points!

  • Your program must be well-commented to explain what the code is doing. Code with no comments, or code whose comments are not correct will be penalized. You no longer earn points for commenting, but you can lose points for failing to do it!

  • Your submission must be a ZIP archive containing your Java source files and any supporting files.

  • Your submission must also include a file named “README.txt” describing how to run your program, any design decisions you made that you feel the need to explain, and anything else that you think will help us understand your project.

Extra Credit (not to exceed 20%)

You can get full points for accomplishing the requirements as described above. The following are some ideas for extra credit, up to a maximum of 20%.

  • Consider generating random levels; this can be tricky because the levels need to be “possible” so you can’t generate levels with chasms too wide to jump or walls too tall to vault. [up to 5%]

  • Consider enemies that do more than just sit in one spot, but jump up and down or actively chase the player. [up to 5%]

  • Consider “pushing” the main character towards the left side of the screen if it impacts a vertical wall. The character should “die” if it is pushed off of the left side of the screen. If it jumps over the wall, it should return to the normal fixed X location on the screen. [up to 5%]

  • Consider implementing power-ups that give the main character special abilities like a double jump or the ability to run through enemies. [up to 5%].

  • Consider allowing the player to control the speed at which the main character runs (forcing the level to scroll faster by holding the right arrow key, for example). [up to 10%]

  • Other ideas: document what you did clearly and prominently in your documentation. We’ll give you credit based on our assessment of how hard it was to do (but the total extra credit can never be more than 20%).