Posted on

Lucas’ Status Report for 2/22

This week, I continued working on the main game while taking some additional time to focus on the design review.

I began implementing some more core features like using a JSON file to generate our beat maps as opposed to just having them place note blocks randomly, and began some of the work on the scoring system. Next week I aim to finish up with these two features and hopefully begin working on some more front end details, to make the game feel a bit more like a game for the time being.

I also made the slides for and presented the design review, which means I took some time outlining our project in a slideshow and doing a bit of presentation preparation. I’ll need to continue this a bit by writing up some of the design review’s written portion this week.

Posted on

Lucas’ Status Report for 2/15

Made progress on core game loop. Wrote some scripts controlling note blocks and note block destruction/timing, currently note blocks are only randomly generated. I’m on track and want to continue progressing on the game by allowing the generated beats to be controlled by a JSON file instead of random generation, and incorporate more accurate timing feedback and improve the UI. 

Posted on

Michelle’s Status Report for 2/15

This week I worked on building a verification process for determining beat alignment error. I created some songs as tests so that I know the ground truth of the tempo and beat timestamps for those songs with some math. Then, I compared this with what the beat tracking observed. I focused on tempo invariant songs. For most tempos, the beat alignment error fell within the acceptance criteria of 20ms. For tempos of about 120 BPM or greater, the beat alignment error was 21+ milliseconds. Further work is needed to finetune that.

I also created another method of testing to use for real songs where the exact tempo and beat alignments are unknown. I built a Python program extracts beat timestamps from an audio file then plays back the audio while playing a click sound at the observed beat timestamps. I initially used threading to play the song and the metronome clicks at the same time, but this introduced some lagging glitches in the song. I removed the threading and just played the generated metronome while separately playing the song myself, attempting to minimize human error in starting the song at the exact correct time. With this method, the timestamps sounded highly accurate and stayed on beat throughout.

The audio analysis portion of the project is on schedule. Next week, I want to see if I can find some way to reduce the beat alignment error for songs that are above 120 BPM.

Posted on

Yuhe’s Status Report for 2/8

This week, I focused on game architecture design and getting things set up for development. I spent a good chunk of time figuring out how to structure the project so everything runs smoothly and making sure Unity’s UI, game logic, and beat map system all fit together.

I went through some Unity 2D game tutorials, mostly on handling input, spawning objects (for the falling notes), and setting up animations. I also read up on how Unity handles JSON files since that’s how we’ll store beat maps. On the C# side, I checked out best practices for handling game logic and timing. I also played around with Unity’s file I/O to make sure we can load and save beat maps without issues.

I also set up a GitHub repo so we can track progress and keep things organized. Next up, I’ll start working on spawning notes based on the beat map data and getting a simple scoring system running. Overall, solid progress this week and I am excited to start developing the game!

Posted on

Lucas’ Status Report for 2/8

Familiarized myself with the tools we’ll be using to develop our game and learned some of the syntax of C#  – worked through beginner Unity tutorials, and began to code some simple programs that may resemble parts of the game. Did some research and brainstorming on how best to represent certain important data structures and parts of the game.

For next week, I’d like to have  a basic working and playable “draft”; something that incorporates some of the basic gameplay elements of the final game. I’d also like to begin on some sort of home/settings pages on top of the core game loop.

Posted on

Michelle’s Status Report for 2/8

This week I focused on getting familiar with the Librosa library and exploring its functions that will be relevant to our project. I was able to demonstrate tempo analysis and beat extraction working for songs with invariable tempo. I also started looking into ways to determine intensity, as that would be useful information for the game whether it affects number of notes or fun animations. Onset Strength may be a useful metric for intensity. Here are some notes from my exploration so far: https://docs.google.com/document/d/1x1v-kjtmkiGLtpr_eNxQ_WqPQmr7fqHTX-byE4wmWC8/edit?usp=sharing

I also completed a basic tutorial for Unity game engine, as I have never used it before. I created a working Flappy Bird game to get familiar with Unity and C#. This will be useful for when I start working on the game UI later on in the project timeline.

My progress is on schedule. Next week, I plan to further explore Onset Strength as a metric and figure out how to extract that from songs. I also want to look into how to analyze the tempo and beats of songs with variable tempo, for example most classical music.