Tag: team status report

This week, we made progress toward integrating the audio processing system with the game engine. We implemented a custom JSON parser in C++ to load beatmap data generated by our signal processing pipeline, enabling songs to be played as fully interactive game levels. We also added a result splash screen at the end of gameplay, which currently displays basic performance metrics and will later include more detailed graphs and stats.

In the editor, we refined key systems for waveform visualization and synchronization. We improved timeToPixel() and pixelToTime() mappings to ensure the playhead and note grid align accurately with audio playback. We also advanced snapping logic to quantize note timestamps based on BPM and introduced an alternative input method for placing notes at specific times and lanes, in addition to drag-and-drop.

On the signal processing side, we expanded rhythm extraction testing to voice and bowed instruments and addressed tempo estimation inconsistencies by using a fixed minimum note length of 0.1s. We also updated the JSON output to include lane mapping information for smoother integration.

Next week, we plan to connect the main menu to gameplay, polish the UI, and fully integrate all system components.

The team has all been progressing individually on their respective parts of the game over the past week. Michelle has been continuing work on the audio processing side, deciding to focus on perfecting the processing of monophonic piano pieces while Lucas and Yuhe are continuing work on the game itself. I’ve continued work on the core game loop, adding back many of the key features while implementing a JSON parser to turn processed audio into a game, and Yuhe has begun working on the in game beat map editor while also adding some neat visual tools to the game.

We haven’t had any major changes to our game’s design, other than the fact that the audio processing side will focus more on monophonic pieces than longer and more dense stuff. This will probably be our biggest challenge going forward in the coming weeks; as long as we are able to integrate the game itself and the beat map editor/menus, we should be able to devote more time and resources to figuring out more complex audio processing.

This week, we each made a lot of progress on our subsystems and started the integration process. Yuhe finished building a lightweight game engine that will much better suit our purposes than Unity, and implemented advanced UI components, a C++ to Python bridge, and a test in C++ for rhythm detection verification using SFML. Lucas worked on rewriting the gameplay code he wrote for Unity to work with the new engine, and was able to get a barebones version of the game working. Michelle worked on rhythm detection for monophonic time-varying tempo songs, which is quite accurate, and started testing fixed tempo multi-instrumental songs, which needs more work.

There have been no major design changes in the past week. The most significant risk at this time to the success of our project is probably the unpredictability of the audio that the user will upload. Our design will mitigate this risk by only allowing certain file types and sizes and surfacing a user error if no tempo can be detected (i.e. the user uploaded an audio file that is not a song).

Next steps include finishing the transition to the new game engine, refining the rhythm detection of multi-instrumental songs, and implementing an in-game beatmap editor. With integration off to a good start, the team is making solid progress towards the MVP.

As of right now, we still have:

• Michelle working on signal processing/turning audio files into json files containing each note and some basic info on the note
• Yuhe Working on the menus and UI of the game, as well as the in game beat map editor
• Lucas working on the core game loop

Similar to last week, our main challenge remains a consistent version control method – for now, we plan to continue progressing in each of our individual areas on our own and eventually integrating all of our code at a later time, while making sure to do some version control on our own sections. Thus, one of the bigger challenges further down the line could be ensuring that our game feels like a seamless and connected experience, which is something we’ll definitely have to dedicate some time to.

This week, our team focused on getting things set up for development, refining the game’s high-level architecture design, and making sure we’re all comfortable with the tools we’ll be using. We also had our recurring Zoom meeting on 2/7 to discuss our next steps, including implementing core game loop and basic UI in Unity, experimenting with note spawning, and most importantly preparing for our design review slides and presentation!

1. Yuhe worked on the game architecture, making sure Unity’s UI, game logic, and beat map system all fit together. She also explored Unity’s JSON handling and file I/O to ensure smooth beat map storage and retrieval.
2. Lucas focused on getting familiar with C# and Unity by working through tutorials and coding simple programs to test key game mechanics. He also researched how to best represent the game’s core data structures.
3. Michelle explored Python’s librosa library for beat detection, successfully analyzing tempo and beats for simple, fixed-tempo songs. She also started looking into Onset Strength as a way to measure intensity, which could influence gameplay elements like note density or animations.

One challenge we identified is handling tempo variations in more complex songs, which will require deeper understanding of audio analysis techniques. For the first month, we’ll focus on detecting beats in simple, steady-tempo music. Our next steps include starting game implementation in Unity, testing note spawning based on beat maps, and refining our design choices for the upcoming presentation. Solid progress so far, and we’re looking forward to seeing our first playable version take shape next week!