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!
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.
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.
George’s Status Report for 4/16
49I did a lot of work on this capstone project last week (Week of April 3), and I had deadlines in 2 other classes this week, so this week I worked on this capstone project less than I typically do. That being said, I did make some progress this week:
- Fixed bug related to drums not being recognized sometimes
- Made preparations for playtesting next week
Earlier this week we were running into a serial message parsing issue with our gameplay code. I spent some time debugging this and I came to the conclusion that there was a mismatch between Stephen’s microcontroller serial code and my gameplay serial code. The issue was caused by an erroneous “\n” character being sent from the microcontroller. Once we removed the “\n” the issue fixed itself.
I also created a Google Form where people can sign up to playtest our game. We will be having multiple playtesting sessions next week. I will be present at all of these sessions because the game is being run on my computer.
I am on progress to meet the end of semester deadline. Our game is nearly complete; the remaining features are mainly cosmetic.
Next week I will conduct playtesting sessions, add some finishing touches to the gameplay GUI, and prepare for the final presentation.
George’s Status Report for 4/10
Here is a list of tasks that I completed this week:
- Designed main menu
- Created and added art to gameplay screen
- Created sounds for main menu and song selection menu
- Created song selection menu
- Added fading screen transition between song selection menu and gameplay
- Added hit indicators that show how the accuracy of a player’s hit
- Fixed small bugs with sound loading and image loading
I worked mainly on SongSelectionMode.cpp, Sound.cpp, PlayMode.cpp, and FadingScreenTransition.cpp this week.
Here is a video of the current state of the game:
As you can see from the video, there is an issue with the font rendering. The text is not being shaped correctly by Harfbuzz. It looks like the lowercase letters are placed at weird locations, which makes the text look a bit silly. I’ve known about this issue for a few weeks now but I have not had the time to go back and fix it. I’m hoping that I will have the time to fix it once we start playtesting, which will happen the week of April 19.
Here is a list of sounds that I’ve created to make the gameplay feel more polished:
Here is the main menu design. I used GIMP (a free image editing software) to create the background and arrange the menu together. I used Google Drawings to create the title text and button text.
This week I did not get to all of the tasks that I had originally planned for this week. I wanted to continue working on Windows compatibility, but after discussion with the Professor and our TA during the Interim Demo we decided to not pursue Windows compatibility because it was taking too long. For now, our game will only run on MacOS.
By the end of this week I would like to have our game in a completely playable state. We need to begin playtesting soon, so it is critical that that game is fully playable by the end of next week. This will give us 1 full week to do playtesting and add any final polishing touches. I am still on track to complete all of my goals before the end of the semester.
George’s Status Report for 4/2
This has been a very hectic week for me. The good news is that I have job offers on the table for after I graduate! The bad news is that I had a little less time to work on this project than I would have liked. I had job interviews on Wednesday and I’ve had a ton of phone calls and decision-making to do this week, which was pretty time consuming.
The game is now compiling on Windows. I met with my teammates last week and we all worked together to resolve the compilation problem. To get the game to compile on Windows, we had to comment out the Sound.cpp code, because the sound library that I am using, which claimed to work on Windows, does not work out-of-the-box on Windows.
The game is in a-playable state, but it is still pretty simple. The remainder of my work for this semester will be related to making the game more polished and fun to play.
Here are the tasks that I will be working on next week. This is a lot of work; I intend on working a little bit during Carnival. It is critical that the game takes shape ASAP so that we can playtest it after carnival.
- Get sound to work on Windows
- Add “Miss”, “Good”, and “Awesome” hit indicators to PlayMode
- Add health bar to gameplay scene
- Set up basic main menu and song selection menu so that Shreya and Stephen can work on them
Team Status Report for 3/26
Our project was scheduled to reach MVP this week. We’ve met this benchmark in some ways, but have fallen short in other ways.
An MVP is suppose to be the minimum viable version of our game. This means that game is supposed to be in a playable state, and that we could theoretically give the game to a friend and they could play it start to finish. Our game isn’t quite at this stage yet. Instead, this week we were able to successfully complete a tech demo of the entire pipeline of technologies: a signal can get sent from the drum, be received by the computer, and then displayed on the screen.
Here is a screenshot of the game:
Our project currently meets the MVP benchmark in the sense that “all of the technologies have been tested and they can interact with each other”. However, our project falls short because it is not yet an engaging video game experience. There is still a lot of aesthetic changes that need to be added to the game before it feels like a fun experience.
We ran into an unexpected challenges with integration this week. The game does not compile on Windows, which means that Shreya and Stephen cannot run the game on their computers yet. We need to divert some of our energy this week to fixing this before proceeding with other features of the game. As a result, the gantt chart has been updated. Here is a screenshot of our latest Gantt chart:
Our MVP deadline was pushed back by a week, which means that we are currently 1 week behind schedule. However, we incorporated 1 week of “slack time” in our schedule, so we are still on track to meet the end of semester deadline.
George’s Status Report for 3/26
We’ve hit a few roadblocks this week. My goals for this week were to figure out how to execute Shreya’s Python code from the cpp code, and debug some beatmap timing issues. I didn’t get to either of these. Instead, I worked on debugging some drum input issues and cross platform compilation issues so that we could reach MVP.
Drum Input Issues
Our MVP was scheduled to be completed by this week, but I unexpectedly encountered an issue with the drum input earlier this week. I reprioritized by tasks this week to ensure that we met the MVP. Here is the issue: the drum could connect to the game, but the inputs were being interpreted incorrectly. When the player holds the drum down, the game would think that the player is hitting the drum repeatedly. I debugged and resolved the issue.
Cross Platform Compilation Issues
The game currently does not compile on Windows. I currently am the main contributor to our gameplay code, and I use MacOS. However, we would like Stephen and Shreya to add features to the game as well. We tried to compile the game this week and we encountered many compilation issues on Windows, and I met with them to debug this. I think that I am going to need a solid 3 hours of debugging before I can figure out clearly why the game is not working on their machines.
More Files
I added some starter code for MainMenuMode.cpp, SongSelectionMode.cpp, and ScoreScreenMode.cpp.
My goals for next week are:
- Get the game to compile on Windows
- Look into executing Python from C++
George’s Status Report for 3/19
I’ve made lots of progress on this project since my previous update on 2/26.
Here’s a list of the major things I’ve added:
- Sound playback
- Font rendering
- More accurate calculation of score
- Reading beatmap data from JSON file
- Communication with drum peripheral
To keep everything organized, I’ve separated most of these changes into different files. Some changed files include Sound.cpp, DrumPeripheral.cpp, and Beatmap.cpp. Here is a diagram that shows how the gameplay code is structured:
Playing sounds
I used PortAudio for realtime audio playback, and I used a free library called libaudiodecoder that reads WAV and MP3 files. To play audio with PortAudio, we must write a special callback function that gets executed by PortAudio every time it needs more data to send send to the computer’s sound device. This function is called the “stream callback” and it is run in a separate thread from the main gameplay code. See Sound.cpp for more details.
Font rendering
If we were using a game engine, then this step would be trivial. However, because we are not using an engine, we need to write an interface for rendering fonts to an OpenGL window. Thankfully, I took Computer Game Programming last semester, and rendering fonts was one of our assignments, so I was already familiar with how to do this. I was able to re-use most of the code from that assignment when adding TextRenderer.cpp and TextRenderProgram.cpp.
One issue we currently have is that the fonts are not being shaped correctly. The positions of the letters look a little bit off. I think this is an issue with Harfbuzz, which is a library used for shaping text, but I haven’t spent enough time debugging this to know for sure. I’m going to put this issue aside for now, because it is not critical to the performance of our game, but after we reach MVP I would like to revisit it.
Communication with drum peripheral
I found a simple library called ‘serialib’ that does cross platform serial communication. It’s only 1 header file and 1 source file. The drums microcontroller and the player’s laptop are communicating using the RS-232 Communication Protocol. The drums microcontroller will send a 1-byte message to the player’s computer when one of the drums has a high output voltage. If no drums are being pressed, then no message is sent. See DrumPeripheral.hpp for more implementation details.
Here is a video of what the game currently looks like. In this example, the game plays a test audio file and a test beatmap. The beatmap notes are not synchronized to the music in this example.
Next steps
Next week we expect to reach MVP. In our gantt chart, we have our MVP scheduled to be completed by Monday. I think that I will need a couple extra days to reach MVP because I got delayed due to the linking issues earlier in the semester, and the font + sound code took a little longer than expected. My main tasks for next week will be:
- Figuring out how to run Python scripts from C++ so that the game can process song data at startup
- Verifying that the beatmap notes are synchronized to the music
After this next week, the game should be in a playable state. I’m expecting that this will be the final week where I am working on building the game framework. After this week, I can work on adding features that make the game look and feel fun to experience.