Frogger

This project is about maintaining and extending a re-implementation of a classic retro game Frogger. The original code is downloaded from the following GitHub repository. This version has never been completed, but at least it runs, once it is set up properly. More information about the original Frogger game and its history is available here.

Catalogue

• Test Environment & Build Script
• Screenshots
• Source File Structure
• High Level Class Diagram
• Maintenance
• Extension
• Arrangement
• Video
• Credits

Test Environment & Build Script

• IDE: IntelliJ

• Tested on:

  • Lab Machine in Room A32 of Computer Science Building
  • MacOS 10.14.6 with Java 10 and JavaFX 10.0.2

• Build Script:

  • Maven
    Step 1: Maven -> Lifecycle -> compile
    Step 2: import changes
    Step 3: Maven -> Plugins -> exec -> exec: java
    If see the following similar result, it means you run program with Maven Successfully.
    
    

  Note: When I followed the instruction Getting Started with JavaFX on the official website to set up configuration of Maven, there were some problems about version incompatibility. The console always displayed "Failed to execute plugin xxx" and "Error injecting: JavaFXCompileMojo". Hence, I found an alternative way to execute a program with Maven, which is using "exec-maven-plugin". For more information, please visit this webpage. If you fail to run the program with above steps, please use the normal running approach in IntelliJ, click Run -> Run 'Main()'.

Screenshots

Source File Structure

src
└── main
    ├── java
    |   └── org
    |       └── frogger
    |           ├── elementFactory
    |           ├── gameController
    |           ├── gameModel
    |           ├── gameView
    |           ├── gameSettings
    |           └── Main.java
    └── resources
        └── org
            └── frogger
                ├── css
                ├── image
                ├── font
                ├── music
                ├── FXML
                └── HighScoreList

High Level Class Diagram

Please note that it is not standard to include "Resources" folder in the class diagram, because it is not a class. However, in order to show Model-View-Controller pattern clearly, ".fxml" files and gameView package are put together to indicate the "View" part. Thanks for understanding !

Maintenance

• Basic part

  • Dividing all classes into packages

    • The whole project contains five packages, which are gameModel, gameView, gameController, gameSettings, elementsFactory. They are classified in order to control access and make researching.
    • MVC Design Pattern is applied to the first three packages. gameSettings contain some game settings, such as background, music, timer, etc. elementsFactory integrates the game elements with different parameters (speed, size ... ) and adds them to the game.
    
    

  • Renaming variables and methods

    • Some variables and methods are renamed to reveal their purpose and make them understandable.
    
    

  • Removing redundant code and comments

    • Some useless setters and getters are removed. For example, getMovement() is useless in Actor class.
    • The class MyStage is removed completely, because it only contains background music settings, which can be done inside a controller.
    • Some comments were probably used for debugging purpose. These "testing" comments are removed.
    
    

  • Making units of code shorter

    • Long methods are difficult to understand, so long methods are separated into sub-methods. For example, in Frog class, sub-methods of public void act(long now) are extracted to deal with the cases, such as game elements intersection, movement control, etc.
    • Large classes reduce cohesive and need to be divided into small classes. For example, Main.java is modified to trigger the starting page only. Adding elements to the game and controlling animation are put in other classes.
    • Lamda expression is applied to some methods involving keyboard events to simplify the code.
    • Long Parameter lists are inconsistent. In Frog.java, parameter and variable settings are simplified.
    
    

  • Identifying the coding style

    • The original code contains both K&R and Allman coding style, which makes code less structured. Hence, K&R style is identified and indentation is adjusted to make structure well-organized.
    
    

  • Fixing bugs

    • The visulisation of current score is improved.
    
    

• Advanced part

  • Applying Java properties

    • Encapsulation
      • Fields are encapsulated to retain private variables.
    • Inheritance
      • Game elemets such as Log, Obstacle are inherented from Actor to perform a set of actions. Some methods are pulled up to high level class.
      • WetTurtle is modified to be a subclass of Turtle to reduce redundant code.
      • GameEasyLevel, GameMediumLevel, GameHardLevel extends the properties from Game class to perform some similar game settings.
    • Polymorphism
      • Overriding is used between parent class and children classes to allow coding extension.
      • ElementsFactory class is applied to generate different elements using Polymorphism.
    • Abstraction
      • Game class is set to be abstract because it will not be instantiated.
      • Interface is used to group a set of methods to specify their purposes. Actor implements Components interface; elementsFactory implements Integrations interface. Using interface can help to couple architecture components loosely.
      
      

  • Applying design pattern

    • Singleton design pattern

      • Music class is designed to play and stop background music, which only needs one instantce.
      • HignScoreList class can be regarded as a "database" of the project. It reads the HighScoreList.txt file and updates the latest information. Duplicates will cause data corruption.
      
      

    • Factory design pattern

      • ElementsFactory class encapsulates the process of creating objects and hides the process of matching game level with corresponding parameters.
      • Game class hides the process of generating different game modes.
      
      

  • Junit

  • Javadoc

Extension

• Adding different game pages via Scene Builder
  

• Applying three game levels

  • The speed of game elements is adjusted.
  • Crocodiles and Zombies are added according to different game levels.
    

• Background Music

  • Background music is played when the program starts.
  • When switching to the "End Page", the background music is changed.
  
  

• Game settings

  • A button to pause the game
  • A button to quit the game
    If player clicks the button, a confirmation alert will be poped up.
  • Timer
    The time limit is set to 100 seconds. If time's up, the game finishes.
  • Displaying number of lives
  • Displaying current score
  
  

• High Score List

  • The game will document Top-10 players and their scores in a .txt file permanently.
  • The information will be updated automatically.
  
  

• Beautifying the UI

  • display.css file is used to change the font, size, color, button appearance.
  • Appearance of multiple game elements is changed.
  
  

• Applying MVC pattern

  • The controller accepts the inputs (button, keyboards, mouse) from the players and decides what to do with it.

  • The view displays the output on the screen with the help of .fxml files.

  • Each view is associated with a unique controller.

    Model	View	Controller
    Frog	StartingPage	StartingPageController
    Log	InfoPage	InfoPageController
    Obstacle	UserPage	UserPageController
    Turtle	HighScorePage	HighScorePageController
    Crocodile	EndPage	EndPageController
    Zombie	LevelPage	LevelPageController
    Habitat		GameController
    Digit		GameTimerController

Arrangement

• Version Control
  • GitLab is used to create different branches. Each branch indicates one stage of project maintenance.
  
  
• Gantt Chart

Video

https://youtu.be/456PU1yNJ3w

Credits

All media assets (images & music) are derived from the internet, and are ensured to be free to use for non-commercial use.

This project adopts MIT license.