Rhythm Game
- What we did: the mechanics of a rhythm game in pair programming. It is a single system that runs according to time, like a giant QTE game. The system plays according to time, like a melody played note by note.
- How we did it: we used the frequency between notes (which is the time between my note and the previous note) to easily transcribe the music from sound software to our game. We did this because we wanted to make a system that was as independent as possible (e.g., not dependent on the UI) and to facilitate integration for GD/SD
- Biggest challenge: aligning this large system with the UI (tempo, speed, distance between notes, feedback, starting offset, etc...).
- What I liked: when we succeeded in visually representing in the UI the entire abstract system we had imagined using the famous formula v = d/t (d = Addition of all frequencies in our unit of distance and t = Addition of all note frequencies in time).
Process of the main mecha
Simplified UML Diagram
Architecture
- What we did : Class diagram to design the project architecture and think through the rhythm game mechanics system. I then simplified this diagram into a UML diagram.
- How we did it: We grafted our system onto our local multiplayer module and its state machine. We created a database for melodies (datatable and structure), managers (game manager, music manager, datatable manager) and controllers (music controller), added a new state (music state), and created a music world subsystem that runs the mechanics.
- What I liked: Moving on to the practical side after thinking through and laying out all the theory, to test the whole system.
Cameras
- What I did : top-down centered between players, camera bounds, switching cameras, transition, zoom/dezoom, shake, trigger
- How I did it: Camera World Subsystem
-
Top- Down : FollowTarget interface to center the camera between targets
-
Camera bounds : clamp player positions by checking whether a point is inside a polygon (concave or convex)
-
Camera Switch : A BP Camera that contains 3 camera positions and a main camera (render). When calling a camera: set a start pos/rot and a final pos/rot of the actor and/or of the main camera component (and reset the alpha to manage transitions), launch the lerp (set relative pos/rot for the component and world for the actor).
- What I liked : Iterate on this system to make it increasingly modular, functional, and optimized.
Centered Camera, Camera Bounds
Zoom, Trigger, Transitions, Shake
