George’s Status Report for 4/30
All of my time last week was dedicated to preparing for the presentation on Wednesday. I didn’t work on the game code at last week.
My team and I created the presentation slides on Sunday of last week. We took some time to practice the presentation together and I also took additional time to practice it alone. After the presentation on Wednesday, I had to focus on other classes because I had other end-of-semester deadlines.
This week I will be doing the following things:
- Create poster for public demo
- Work on final report
- Finish work on health bar
- Finish work on game death loop
We are on track to have a fully working version of Hit It! on Thursday. I’m looking forward to the TechSpark Showcase on Thursday and the demo on Friday!
Team Status for 4/30
This week, the team focused largely on the presentation and getting the testing done in time. From previous playtesting, we know that there are a few playability issues that we needed to solve. This was addressed in our presentation as well. However, some of the feedback we got was that more feedback in game visuals was needed, the beatmaps were not well synched with the audio files, and the drums were not recognizing hits.
We have been invited to present at TechSpark, meaning that we need to make all of our aesthetic improvements by Thursday. While we have finals coming up, one of our challenges will be balancing the workload with the final touches we have to make on the project as well as preparing the presentation and the poster as well as the video and the demos.
Overall, this next week will be dedicated to finishing up the project (the individual tasks are mentioned on our blog posts) and finishing up the course documentation by Thursday-Friday.
Shreya’s Update for 4/30
This week, I focused mostly on testing the beat map generator. I had two main goals for the beat map at the beginning of this project. The first was to have the beat map generator take less than the length of the audio file to analyze the audio file and output a beat map generator. To test that, I ended up making about 50 maps and then computing the time it took to test it. I put the graph on our team’s slides. I think that goal is fine.
The second one with the synchronization has been trickier. It’s pretty simple to get the number of beats down to make the game playable for our audience (one piece of feedback we got), but I’m still not super sure what’s happening with the synchronization. I have this idea to only compute the most apparent beats instead of all of them to improve synchronization, but that’s something I will be testing. Unfortunately, I have a few papers and exams due, so I will probably dedicate Monday to working on this problem. This all needs to be done by Thursday for the TechSpark demo. I also have a final Thursday evening so this will likely be done between Monday and Thursday
Stephen’s Status Report for 4/30
The last task I need to finish before the public demo is the completion of the central module for our project, which will isolate the ESP32 and supporting circuitry from the user while they play the game. I spent several hours trimming down some wire headers and soldering them to a general-purpose through-hole breadboard which will help reduce the over size of the circuitry and also fix the connections in place so they cannot be jostled loose. Currently, I’m about 70% of the way done with this soldering, and this video shows the current functionality of that board:
Other than this, all I need to do is 3D print a small housing for the board once I’ve finished soldering it. This box shouldn’t be very expensive compared to the drums, as it doesn’t need to withstand any significant forces, which permits the use of thin walls. I’m expecting this module to cost around ~$15 when printed.
Regarding where I am in regards to completing these tasks, I’m confident I’ll be able to wrap everything up every next week. Most of my classes finished up this recent week with their last exam or a final project, so I have little else to work on other than these tasks, as well as the final report due at the end of next week.
George’s Update for 4/23
This week I worked on the following things:
- Conducting playtesting sessions
- Fixing a new drum input bug that was discovered during playtesting
- Adding visual feedback to user input
- Changing colors of game lanes
- Preparing for the final presentation
This week we conducted 2 playtesting sessions on Wednesday. We had 8 people play our game and provide feedback to us on our feedback form. A lot of their feedback was related to the visuals of the game, and I had to make some tweaks based on their feedback. Here is what the game looks like now:
Next week we will be adding the finishing touches to the game and giving our final presentation to class on Zoom. I will be cleaning up the gameplay a little bit more, tweaking the main menu, and refining some of the colors.
Shreya’s Update for 4/23
This week, I was focused primarily on testing for the presentation and report for next week. I am running a script right now for the timing portions of my model about determining the average time it takes to run for certain lengths of times (one of my user requirements).
The second user requirement is harder to talk about. I have a few metrics that I I am considering which is comparison to a commonly known beat tracker without regarding false positives or negatives. This is because I included the melody tracking and the commonly used package does not. I was also considering submitting graphs of the areas in an audio file where the algorithm would place a beat to see if we can draw some comparisons for that. I have the wav files created, so having the intensity analysis graphs created should be pretty fast.
Lastly, I think we can incorporate the user feedback and the results we received from play testing.
I do actually have a bug currently in my code which suggests its outputting the wrong time stamps. I am working on trying to fix it, but I am unsure if I can get to it this week. I may have to look more into it next week and focus on the testing analysis for this weekend.
Team Status Report for 4/23
This week was primarily spent performing our testing and making any last minute improvements that would be needed going into the final presentation. Each of our group members spent time improving/testing their individual portions of the project, but we also had a user feedback session Wednesday night with CMU’s Game Creation Society so that we could get user input into the state of our game.
During this session, users play-tested the game in a fashion similar to how the final product would be used and gave their opinions on what they felt could be improved on. Some examples of feedback included user’s feeling specific drums were less responsive and that the scroll speed/note density of the game was too much for the average (or even experienced) rhythm gamer.
Receiving user feedback in this fashion was also needed for some of our specific use case requirement tests, such as the set-up time of the game, so we gathered that information as well so that it could be presented during the final presentation next week.
Following the final presentation next week, the majority of the changes we still need to make to our game are just improvements or to already implemented features (such as the game’s graphics and drum-game communication), many of which are aesthetic in nature. As such, we should be on pace to finish this project by the upcoming final demo.
Stephen’s Status Report for 4/23
The majority of this week was spent on finishing the 4 drum modules and starting my testing in preparation for the final presentation on Monday. The following video shows the current state of the drum setup:
The main takeaways from this demo are that all 4 drums have had their PCBs soldered, and are situated within the drum modules. Furthermore, the wooden bases and rubber pads on top of the modules have been placed as well (although I have opted to only secure the bases in place with tape for now in case I need to disassemble and repair anything inside).
One thing I’d like to highlight is that the rubber pads do not depress heavily when pressure is applied, which is important for maintaining a good “bounce” when the drums are hit by the user.
Additionally, the other primary task for this last week was performing the testing needing for out final presentation this upcoming week. Between the user feedback session we held on Wednesday and specification testing I’ve performed on my own, I have almost all the data I need for the report. To recap, the 4 categories of testing related to the drums are user set-up time, compactness, latency, and recognition accuracy.
The user-setup time and compactness tests had good results, however I did have some issues regarding drum recognition and latency. Regarding recognition, some of the drums were noticeably less responsive than others (which was feedback I received during our user testing session) and to remedy this I placed small paper squares in the main force bearing column of the drum.
These paper squares bring the sensor and rubber pad ever so closer together, which increased the sensitivity greatly.
Regarding the latency, the main issue I encountered was not with the latency itself, but with measuring the output, as the serial monitor I used to check for messages from the drum only outputs results every 60 ms or so, which means I can’t reliable use it to check for latency around the 30 ms mark. I’m going to try a similar test using an oscilloscope tomorrow in the hopes that this will provide better results, however if that doesn’t pan out we may need to use a full latency test from drum to program instead of measuring the drum and program latencies in isolation.
Regarding where I am in the project, I feel confident in my ability to finish the product before the final demo, as most of the remaining tasks I have are mainly aesthetic improvements, such as gluing the drum bases on firmly and printing a module for the ESP32 to be placed in to isolate it from the user. Everything regarding the functionality of these drums is working, although I may be able to make some marginal improvements, and both of those tasks I mentioned earlier will be tackled next week.
Team Status Report for 4/16
The semester is coming to a close! This week we worked on making additional improvements to the drums module, GUI, and beat tracking algorithm. We can now connect multiple drum modules to the computer at once rather than just 1 drum only. The beat tracking algorithm now more closely synchronizes with the music.
We will be conducting playtesting sessions next week. During these sessions, we will take measurements to validate our design requirements. Here is a breakdown of the items that we will measure:
- The time it takes for the user to take the drums out of the bag, connect to computer, open game
- Record average frames per second (FPS) while users play game
- Ask users to rate different aspects of the experience on a scale of 1 to 10
- GUI
- Ease of use
- Fun
We are currently on track to meet the end of semester deadline. We will be using most of our time next week to make aethestic improvements to the game, conduct testing sessions, and to prepare for the final presentation.