For this week, I had many small goals to work towards. First, there were tasks leftover from last week: deciding an operating system for the Raspberry Pi and researching how other DDR-like games encode their song tracks. For the OS, I was looking for a barebones Linux with a GUI good enough to run Pygame. I did not find exactly what I wanted, but I believe the Raspberry Pi OS (formerly Raspbian) will be the best. It boots quickly and runs python natively. It also has tons of documentation since it is the official OS distributed by Raspberry Pi. The other option I was considering was the Raspberry Pi OS Lite, but that is meant for headless setups with no visual interface, so unfortunately it does not fit our purposes. My one concern with using Raspberry PI OS is that if our game crashes, which won’t allow the user to turn off the Pi from the game, the user will be stuck in the desktop screen without an option to turn the system off aside from pulling the plug, which isn’t great for their experience.
I also did some research into how other rhythm games encode their tracks. During this search, I found a game called Stepmania, which is essentially a free DDR that allows users to create their own custom tracks. This was super helpful, since I could download one of those custom files and just inspect it through Notepad. The key part of this file was a bar-by-bar description of the notes in the song. Inspired by this format, I came up with the idea of writing a bar-by-bar description of the arrows, i.e. which arrow should be hit at that point in the bar. Although this means it will be arduous to create choreographies for songs, music sheets are widely available, so it should be easy enough to find where arrows should be. Combined with some more parameters about the song such as BPM, we can have our game predict when an arrow should be clicked, and make it appear soon enough that it reaches the top at the right time.
Furthermore, Spandan and I had a meeting to align which parts of the code each of us is working on. At this moment, our goal is to keep the meat of the game in the game_components.py so that we can work individually on the components for the screen each one of us is building. Then, main.py checks for pygame events, calls update functions, and draws the current screen.
Finally, I also worked on the Design Review Report deliverables. I took up the “summary” sections like abstract, introduction, and the actual summary, as well as the testing section. I haven’t finished all of these yet, but I hope to be done by Wednesday, regardless of whether the deadline changes or not.
I managed to catch up with my schedule this past week. Sadly no pictures for this week though 🙁 For the upcoming week, I will start working on my game components for the game screen, and given the chance, I plan to test how it runs in the Raspberry Pi. I have a Raspberry Pi 4 at home, so I might also do some testing during Spring Break.