Authors: Khanjni Italiya, Jakob Johanson, Chahith Srikanth, Dana Van
This is a rhythm-based game where players hit notes in sync with the music using keyboard inputs to rack up points. The better your timing and accuracy, the higher your score. A dynamic ranking system evaluates your performance, rewarding precision and consistency. The ultimate goal? Master each track and aim for a perfect score. Most of us on the team have played rhythm games before and really enjoy that kind of gameplay, so we all agreed it would be a fun concept to work on. There are so many songs you can play with, and it's always super satisfying to hit a high score or push yourself on tracks you haven't tried before. It’s just a fun way to test your skills and have a good time. We will be using the Godot Game Engine which runs on C++.
You play the game using just two keyboard keys, and there’s a visual interface that shows the notes, menus, and how the game looks overall. The game lets you play along to different songs. It tracks your score, accuracy, and has a ranking system so you can see how well you did. There’s also a visual interface that shows the notes as they come, and we’re planning to add different songs or gimmicks to keep it fun and challenging.
FEATURES PLANNED includes: title screen, configurable keybinds, note speed, and other features (how many of these we can implement depends on how hard they are to do and time limitations). We will have a Song Selection Menu and an Actual Game phase which involves hitting notes by pressing 4 designated keys on a keyboard there will be notes that fly down from above or below (depending on settings) and we have to press the right key when the note aligns with perfect timing. Also, we will have a Ranking system in the gameplay which calculcates Score, Accuracy, and gives a Rank from P, A, B ,C ,D, F. If you miss too much, the game will end so there will be a sort of health bar system where missed notes decrement the bar but hit notes bring it back up; Game End screen; Chart Editor to implement a system where we make patterns for how the notes fly down and this will be unique to each song. We will most likely be doing a conductor system where one class keeps track of timing, time between beats, how long a beat is, etc and the rest of the game functions use this as a reference so everything is in sync. This point is going to be implemented based on complexity but Ideally It will be a 1v1 battle style gameplay where there will be an opponent which autoplays and have their own charted notes and them hitting notes also brings your bar down (but can't kill you it just brings the bar down to make it difficult). The character you play as and the character of the opponent will move left,right,up or down depending on your keyboard inputs to make the game feel responsive. There will also be a lot of graphical UI elements which Chahith will be handling as the main visionary.
Title Screen: The main logo is at the top center of the screen, with a parallax effect as you move your mouse. Buttons line the bottom of the screen with Play, Exit, and Credits that send you to different screens. A settings cog is in the top-left corner.
Credits: A "Credits" label is at the top of the screen, with our names listed out below it. Roles would be added if we decided to do that.
Settings: The top-left corner has a back button. The top row of the screen is the tabs for different categories of settings. On the right side is a scroll bar. In the center of the screen is a list of settings that can either have a slider, a button/checkbox, or whatever input is necessary.
Song Select: Top-left corner is a back button. The selectable songs are listed out, with the current highest rank displayed to the right of them. An arrow is to the left of the currently highlighted song.
Score: The results of the last gameplay section are displayed at the top center, with the score and rank for the performance displayed below. In the bottom-left corner is a Retry button and the bottom-right corner is an Exit button to return to Song Select.
Gameplay: This screen layout depends heavily on the exact style chosen for the note system, and we have yet to decide on our format and we plan to have many features and variations available. However, it will at least have a "health" bar, a running tally of your score, and the notes coming onto the screen from some direction.
In the UML diagram, the Control node is central, interacting with various game menus such as the Main Menu, Settings Menu, and Credits. The Control node accesses these menus to navigate through the game, adjust settings, and view credits. The Parallax system is linked to the Main Menu, creating a dynamic background effect as the player interacts with the menu, enhancing the overall visual experience. The Sprite 2D is associated with the Picker, allowing the player to visually select game elements or options, such as choosing songs or difficulty levels. The Button nodes are connected to the Button_Tween, which uses the Tween system to apply smooth animations to buttons when interacted with (e.g., when hovered over or clicked), ensuring a responsive and polished user interface. The Node2D serves as a container for the Bar and Note elements in the gameplay. The Bar is a key component that represents a timeline or track where notes will appear. The Bar manages the timing and flow of the notes, ensuring they appear at the right moment, while the Node2D manages the movement and positioning of the Bar and Note elements in the game world.
Update #1: We introduced a new Results class was added to manage everything related to the results screen—calculating scores, storing results, and determining final outcomes. Applying SRP and ISP, this keeps result logic separate from gameplay and UI code, avoiding unnecessary dependencies. By separating responsibilities, the code is easier to read, test, and reuse (e.g., exporting results, analytics, etc.).
Update #2: We also introduced a Conductor class as a central coordinator that manages high-level logic and interactions between other classes (like Game, Results, etc.), excluding the UI layer. This class is responsible only for orchestrating the game flow, not the logic of individual components. Applying SRP and DIP, this improves modularity and reduces coupling between classes. Each class focuses on its own task, and the Conductor becomes the single entry point for controlling the app’s execution, making the codebase easier to test and modify.
Update #3: We also introduced a Game class which encapsulates all gameplay logic (e.g., levels, rules, progression) and is triggered by the Conductor. This isolates gameplay concerns from other areas like UI or results handling. Applying SRP and OCP, gameplay logic is now self-contained, making the class easier to extend for future features (like new game modes) without changing existing code. It also simplifies unit testing by isolating game behavior.
Update #4: We also added and updated arrows between classes in our class diagram by having more and appropiate arrows between classes to explicitly show dependencies and associations between all relevant classes. Applying SRP, DIP, and ISP, by representing these relationships, the diagram better reflects how responsibilities are separated and how abstractions are used to reduce direct dependencies. By clarifying all dependencies visually, this leads to better modularity, easier testing, and simpler future extensions.
Update #5: We also introduced Chart, ChartView, NoteData, CmdInput, Song Select and RichTextField classes. We applied the Single Responsibility Principle (SRP) by separating concerns between data (NoteData), presentation (ChartView, RichTextField), and user input (CmdInput). The Dependency Inversion Principle (DIP) was also applied by ensuring higher-level components depend on abstractions, not concrete implementations. This clear separation makes the system more modular, easier to maintain, and test. Visual updates can be handled by ChartView without affecting the underlying data, and user inputs can be processed independently, improving flexibility and scalability as it also makes future extensions or replacements of components straightforward.
Using the Chart Editor
Instructions on installing and running your application
The project was tested and validated using a combination of automated unit tests with the GUT (Godot Unit Test) framework and manual testing in the Godot editor. With GUT also being able to detect unfreed objects, unit tests covered key functionality such as signal connections, input handling, and scene navigation logic by mocking methods like _change_scene to prevent actual scene changes. Mock scripts and input simulations were used to isolate and verify behaviors in scripts. Manual testing was also performed to confirm UI interactions and transitions worked as expected in the full scene environment.
Unit Testing for Chart Editor