Sprint One
The Ultimate Dungeon Crawler Game
Sprint One is the ultimate dungeon crawler game designed to provide an exciting and immersive experience for players. The game allows players to navigate through dungeons and defeat enemies in order to escape. In Sprint One, players will embark on a thrilling adventure filled with challenging puzzles, hidden powerups, and powerful adversaries. The game's simple yet engaging design ensures that each dungeon presents a unique set of obstacles, keeping players on their toes and encouraging strategic movement. Scroll down to see more!
Game Description
Sprint One is an action/adventure dungeon crawler where your main goal is to escape the dungeon. Achieve this by attacking varied enemies, gaining powerups that alter the gameplay in various ways, and reaching the end of the dungeon’s four rooms.
Our team’s development process began with setting each of our game scenes and adding the player, then transitioned to implementing a leaderboard and win/lose conditions, then room placement, player movement, enemy placement and movement, powerups, and finally player attacking. This was all done through the implementation of design patterns across five separate sprints. The biggest challenge was the implementation of the design patterns, as we were all new to these concepts, but we began by envisioning the program without them first, which led to us being able to easily understand the improvements they offer.
Our team strived to innovate the use of design patterns in the realm of video game development, and our game features robust movement, attack, leaderboard, and powerup systems, all of which heavily utilize design patterns in powerful, unique ways. Our most advanced system is our enemy system, which utilizes the factory design pattern. Our enemy implementation allows us to place and use any type of enemy we require and allows for the alteration of attributes on the fly, which we utilize with our time-freezing powerup, stopping all enemies in their path. We use this system by having differing enemies per room, all with unique attributes, such as speed and look. We can delete and add them with ease, allowing for an easy segway into our attack system.
Game Demonstration
Demonstration
Singleton Design Pattern
Strategy Pattern
-
Private static instance of the Leaderboard class named instance
-
Ensures only one instance of the Leaderboard class throughout the application
-
-
Constructor for the Leaderboard class is marked as private
-
Prevents the creation of new instances from outside the class
-
-
getinstance() method follows the Singleton pattern
-
Checks if the instance is null
-
If null, creates a new instance within a synchronized block
-
Ensures only one instance is created even in a multi-threaded environment
-
-
-
-
Public static method, getinstance()
-
The only way to access the Leaderboard instance
-
Used to retrieve the single instance of the Leaderboard class
-
-
Code ensures only one Leaderboard instance in the application
-
Provides a global point of access to that instance
-
Allows maintaining a single leaderboard object for tracking scores and other data in a thread-safe manner
-
-
Proper utilization of the strategy pattern in our code
-
Defines a family of algorithms
-
Each algorithm is encapsulated in different classes
-
Objects are made interchangeable
-
-
Main context class exists
-
Doesn't care about the specific algorithm implementation
-
Executes the selected algorithm
-
-
Strategy class is present
-
Interface containing the overall algorithm
-
Different strategies implement this interface
-
-
Concrete strategies classes exist
-
Implement the strategy interface
-
Define specific implementation details for each strategy
-
-
Our code includes an EntityMovement interface
-
Contains the changePos() method for entity position change
-
-
Unique strategies, player and enemies, implement the EntityMovement interface
-
Each has specific details for the changePos() method in their respective class
-
-
Classes reflect the strategy and concrete strategies of the strategy pattern
-
GameScreen class serves as the main context class
-
Utilizes the interface method to change the position of entities
-
-
The decorator pattern is a structural pattern focused on operations that enhance a target object's features or behaviors without altering its original class.
-
It involves creating wrapper classes to modify the object without directly manipulating its class.
-
Typically, there is a base decorator interface with concrete classes implementing the interface.
-
The code for powerups serves as a good example of the decorator pattern, employing wrapper classes to change player attributes without directly adding methods to the Player class.
-
Powerups, such as speed and health powerups, modify specific attributes of the player object.
-
All concrete Powerup classes implement an overall Powerup interface.
-
The powerups and their classes effectively modify player features without altering the player class, exemplifying the decorator pattern.
Decorator Pattern
Factory Pattern
-
The enemy implementation in our code follows the Factory Method Pattern.
-
We define the Enemy interface, outlining the necessary methods for the four types of enemies.
-
Each enemy type (enemy1–4) implements the methods of the Enemy interface and has a unique constructor to set variables, including distinctive attributes like movement speed.
-
The EnemyFactory class employs the createEnemy method, which uses a switch statement based on the enemy type's number to instantiate the corresponding Enemy type. This enhances the efficiency of instance creation.
-
In the GameScreen class, there's a method to initialize two enemies based on the current room.
-
Each enemy instantiation in the GameScreen class utilizes the EnemyFactory class's createEnemy method to select the required enemy type.
-
This setup ensures that two types of enemies are displayed per room, with their types changing on a room-by-room basis.
Observer Pattern
-
The implementation of the Observer pattern is evident in our Player and GameScreen classes.
-
The MovementObserver interface is defined, featuring an alertMovement method for receiving movement notifications.
-
The notifyPlayer method, within the GameScreen class, informs a player object (implementing the MovementObserver interface) about position changes by passing new X and Y coordinates through the alertMovement method.
-
The alertMovement method in the Player class updates the character's position based on the received coordinates, facilitating real-time character position updates when movement notifications are triggered.
-
This pattern is employed to notify the player of movement events, effectively separating movement and collision concerns from the observers, which are the players.
-
The Observer pattern is also utilized for player-enemy collision detection and management in the game.
-
The Collision class includes the checkCollision method, using the isColliding function to determine if the player collides with specified enemies.
-
Upon a collision, the player's health is decreased by 15.
-
The Player class implements the CollisionObserver interface, specifically the alertCollision method, to handle collision events.
-
The notifyHealth and alertCollision methods in the Collision class exemplify the Observer design pattern by managing collisions and health updates in separate structures.
-
In the Player class, the notifyHealth method acts as a notifier by invoking the alertCollision method of the player object, notifying it of a potential collision with an enemy.
-
This separation of tasks allows for flexibility, and the alertCollision method calculates the distance between the player and an enemy based on their coordinates, indicating a collision if the distance is less than 50 units in both x and y directions.
The Team
Aden is a 3rd-year Computational Media major with concentrations in Media and Games. At Georgia Tech, Aden is an active member of the Computational Media community and has developed numerous other games for a variety of classes and VGDev. For this particular project, Aden spearheaded the initial creation of the project (including its implementation, Git, GitHub page, and Trello board used in the organization of the team’s work), the configuration screen, character and enemy artwork, the groundwork for the score, and the player attacking functionality. He was solely responsible for making sure the project’s code followed programming standards through checkstyle and the tagging of each one of the project’s sprints through Git. Aden also refactored and structured the project implementation to adhere to a Model-View-ViewModel design pattern, contributed to integrating the Factory Design Pattern for overall enemy implementation, and developed a variety of JUnits to test the effectiveness of the project.
Owen is a 2nd-year Computer Science major specializing in Intelligence and Media. His role spans several aspects of the game. He took charge of implementing the player movement and simultaneously the UI as well. Owen continued work on the game's mechanics by creating the enemy AI. Another pivotal role was in the formatting of the endscreen leaderboard. His contribution involved not only formatting but also enhancing it with an array of statistics, presenting players with a comprehensive overview of their performance. Owen also created a variety of JUnits which tested many different areas of the project. These tests helped debug issues and confirm a quality game.
Tejaswini is a 2nd year Computer Science major with concentrations in Intelligence and People. At Tech, she’s an undergraduate researcher for the AVA Digital Human Lab, exploring the intersections of artificial intelligence, data analysis, and human-computer interaction. She’s also involved in Medical Robotics, DramaTech, Pride Alliance, Big Data Big Impact, Psi Upsilon, and Ballroom Competition Team, where she engages in hands-on projects, advocates for meaningful change, builds community, and helps put on theater productions and shows. As a part of this project, she worked on creating the initial case diagram, domain model, and scrum meeting plans. She also designed the launch screen and rooms, implemented distinct rooms in the game, and worked on player-enemy collisions. She wrote code that abided by the observer pattern, and made JUnits to test code functionality and efficiency.
Jason is a 3rd year Computer Engineering major with concentrations in Cybersecurity and Systems & Architecture. He is from Kildeer, IL and is involved with Georgia Tech VIP, Eta Kappa Nu, Greek Life, and the Georgia Tech Catholic Center on campus. Throughout the creation of the project, Jason assisted in developing robust endscreens that displayed a leaderboard of the top 5 scores with the attempt number and the time of the attempt. He also developed an intriguing scoring algorithm to provide an exciting and competitive gaming experience for users. He also contributed to the creation of enemies by implementing the Factory Design Pattern and overall interface for enemies. He also provided a variety of JUnits to test backend functionality of the game and certain edge cases.
Aditya is a 2nd year Computer Science major with concentrations in Information Internetworks and People. He is from Alpharetta, GA, and is involved in student campus engagement through SCPC (Student Center Programs Council), the student organization that plans many of the student events on campus for the diverse student base. In this project, Aditya took responsibility for the initial configuration of the game screen, including its foundational logic and UI; implementing the groundwork code of the player; as well as implementing the various exciting powerups throughout the game, which included the player-powerup collision logic. Additionally, he utilized various design patterns during the implementation of his responsibilities, including the strategy pattern and decorator pattern, as well as utilizing and maintaining SOLID and GRASP principles within the code. Outside of the main code, he held many responsibilities regarding documentation, including contributing to the several System Sequence Diagrams created and creating the Design Class Diagram representing the entire project code structure, as well as responsibilities for developing JUnits to test the various implementation details within the application.