Category: Caio’s Status Reports

For this week, my tasks were to help with testing and finish the animations for the game. On Wednesday, all three of us met after class in techspark to conduct more tests of our entire system. I’m also recruiting some more friends to test our game during finals week for any last week improvements.

I worked on adding animations to the game, namely for when the player hits the arrows and they disappear (there should be a little boom after an arrow disappears) and for text that pops up indicating how precise the player was. The current implementation of animations is incredibly slow, since each animation rescales an image every time it is drawn on the screen. This becomes an issue when we have too many arrows on the screen at the same time. My plan to fix it is to have a few pre-loaded key frames for the boom animation that are played in sequence, instead of rescaling the same image every game frame. The text pop up animation has not been implemented yet, as I’m trying to get the boom to work first.

For this upcoming week, my goals are to finish the animations, make sure our display scales properly to the monitor we will use during the final demo, and work on the final deliverables. I’m also going to upload the latest version of the software to the RPi, but now that the major hiccups for that have been figured out, I anticipate that it will be a straightforward task.

For this week I had a number of small scale tasks to work on. First, I edited our Menu Screen code to support any number of songs instead of just 5. This allows players to add customized songs of their choice, and creates the possibility of a dedicated choreography maker app for Flex Dance if someone were to work on this project after our course is over.

Next, I worked alongside my teammates to plan our final presentation. This time I will be the one presenting so I also allocated some time tomorrow (Sunday, Apr 24th) to practice my presentation.

We also began the testing phase of our project. We focused mostly on latency, error rate, and coverage for our initial testing, and the results will be discussed further in the presentation. So far it seems most of our use-case and design requirements will be met and verified, although we’re already noticing that a few have not passed their tests (such as cost and size).

I started working on the Raspberry Pi as well. We are using the Raspberry Pi OS Lite for our operating system since it boots quickly, occupies little space in our SD card, and leaves less room for confusion sine it does not have a GUI for window management. I faced some issues when setting up Pygame in the Pi, which seemed to stem from our version of Pygame failing to recognize a video device. Fortunately our TA, Joseph, had some good suggestions and helped me fix the issue. We’ll have to work with an older version of Pygame when running the game on the Raspberry Pi, but other than that we will be fine.

Finally, we met on Friday and built our mat! Spandan and I worked on making the arrow platforms/buttons and sticking them to the bottom tarp layer. It is somewhat bland at the moment because it’s just a big piece of black tarp with smaller squares covered in more black tarp on top of it, but we plan to paint it during this upcoming week and the week of the demo.

In terms of my own schedule, I did not have time to add those animations I mentioned last week into the game since I did not anticipate that setting up the Pi would take so long and I also did not account for our mat-building meeting on Friday. I still would like to implement these, but they are not a priority. For this upcoming week, Spandan and I will integrate some new parts of her software into our game (she’s been working on adding sound effects, look at her report :D) and later in the week I’ll work on scaling our layout properly for the monitor we will be using for the demo.

This week I finalized all the necessary mechanics of our game. Now the entire game loop works: the player chooses a song in the menu screen, dances to that song, saves their high score if they placed in the score board, and then returns to the menu screen where they can select the next song to play.

In order to accomplish that, I first fixed the keyboard scaling in the high score screen (if you refer to my last week’s report, you can see the keyboard keys were out of place) and implemented the submit key. Now once a player inputs their name using the keyboard, they can choose “submit” and it will save their score on the high score file for that song. When the player sees that song again in the menu screen, their high score will appear on the high score table. We also decided, for the sake of simplicity, to only have five buttons in our mat. To accommodate for this, instead of using a sixth button for deleting characters, I added a delete key opposite to the submit key. Below is a progression of screens that illustrates how an empty high score table (meaning this song was never played before) would change after someone played the song.

The high score is saved to a file, so the next time I run the game, my high score will still be saved.

After finishing the save function, I changed how the text inside the grey rectangles is drawn to make sure it matched the screen resolution. Before, they were drawn to fixed x and y coordinates, so they were not flexible to different screen sizes. I don’t have a picture of how they were before I corrected them, but the correct scaling can be seen on the two menu screens above. I believe that now every graphical component in the game should scale properly to any screen size.

Finally, the last thing I did for the software this week was adding the pause menu interface. Now, when the player pauses in the pause screen, a pause menu pops up, explaining what each arrow will do if they step on them.

Other than working on the game, this week I also helped Tushhar with soldering wires onto our FSRs to build our mat. I accomplished all the goals I had for this week.

For the upcoming week, my individual work will be adding some flare to the game and setting up our Raspberry Pi. By flare I mean some simple animations that will play when the player steps on arrow and the ability to have more than five songs. We planned to have two different animations that will pop up: a little explosion where the arrow is located and a text indicating how well the player scored. These are not required for the game, but will improve the overall experience. Regarding the five song limitation, our game is currently hard coded to display five songs in the menu; I want to change that so that players can add however many songs they want. Lastly, I will setup our RPi because I’m sure an issue or two will arise, and I would love to have our demo use the RPi instead of a laptop (that was our original intention anyway).

As per our update schedule, my individual tasks this week were to add the pause function for the game and implement input in the high score screen. I was also supposed to work with Spandan to integrate our screens.

I implemented the pause functionality in the GameScreen, and now when the player presses (i.e. steps on) the pause button, the song stops and the arrows freeze in place. Once the player presses the pause button again, the song resumes and the arrows begin moving again. When the game is paused, the player also has other options. They can press the left arrow to restart this song, the down arrow to return to the main menu, and the right arrow to unpause (in addition to the pause button). One particularly tricky component of pausing a game like this is that I couldn’t simply stop updating the screen if the “is_paused” flag was True, since I still had to keep track of how long the game was paused for to make sure that arrows were still spawning in the right intervals. When I first implemented the pause function, if the game was paused for too long, every arrow left in the song would appear almost at the same time, since the game thought that the time to spawn those arrows had already passed. I spent some time fixing this, and now the pause function seems to work properly. It is only missing the visual menu that pops up when the game is paused, but this should be an easy addition since I only have to add it to the draw function.

I also began working on the input for the High Score screen to allow players to input their name using the arrows. So far, they can type their name and also delete characters, but the saving functionality has not been added yet, mostly because of an issue with how the keyboard was displayed. Currently, due to the difference in aspect ratio between my laptop screen and the mode screens we made in Figma, the Submit button does not fit the keyboard properly.

I’m currently working on changing how the keyboard is drawn to maintain the same aspect ratio as out model, independent of the screen’s aspect ratio (which is how the one above works). Below is the current look, but it is unfinished:

Unfortunately, Spandan was not feeling well this past week, so we did not have a chance to work together on integrating our screens. I did some work on my own, and now we can select a song in her main menu screen to play in my game screen. This upcoming week we will work some more on this, as some of the shapes and images on the screens are not sized up properly. During class on Wednesday, I also had the chance to help Tushhar test the FSRs with our plates.

Finally, I also did some small quality of life changes. As seen in the picture above, I have changed the text font on my screen to match that of the model screens we had. I also changed the choreography files to include how many segments there are in a measure for that specific song to allow for better customization and more song variety! Previously every song had 16 segments per measure, but that was somewhat restrictive.

For next week, I intend to add the pause menu interface, which shows the player what will happen depending on the arrow they step on, implement the submit button in the High Score screen, and add the files that keep track of High Scores. I also want to setup our RPi, but I am somewhat reluctant to do that since we don’t have the finished game yet. It will depend on how much progress Spandan and I make.

This week my goal was to work more on the Game Screen and start the High Score Screen. For the Game Screen, I worked on making it easier to integrate with Spandan’s Menu Screen, implemented our linear scale scoring, and removed the lives mechanic. The previous version of the Game Screen was essentially just a very improved version of my Pygame learning project, so it was not properly split within the Flex Dance files. This week I managed to split all the components from my screen and place them in their proper python files. Most of it went into the game_components.py file we had planned before. It now houses a Game Screen class, which contains all the methods necessary to run the game screen. A Game Screen object is initialized with a song tittle, which will come from Spandan’s Menu Screen. My hope is that integrating our different screens will be quite simple now, since our plan was to keep the main file as abstract as possible and have all the more involved functions in the game components file.

I also implemented the linear scoring scale and removed the lives mechanic from the Game Screen. Now the player receives a base amount of points ranging from 0 to 100 based on how close they were to hitting the arrow at the right time. These points are then multiplied by the current combo multiplier and added to the overall score. After doing this, I removed the lives mechanic as that will not be in the final game. Flex Dance is about trying to improve on your past scores, and not heavily punish players for missing arrows; this is part of being both user- and beginner-friendly. Finally, I also added a special encoding to the arrow sequence file to signal that the song is over. If a line contains a “1111”, it means we are done with the current song and should move on to the high score screen.

Then, I started working on the High Score screen. As of now, when the song ends, it moves to the High Score screen, passing the name of the song and the score that the player obtained. Currently, the screen draws the keyboard and the user can change the selected letter using the arrow keys:

Although I like how the screen is looking so far, the font is wrong, since I don’t have the correct font file yet, and the keys should not overlap.

During class time this week, I had the opportunity to test one of our mat’s squares with Tushhar. We had a little issue with a single step being detected as multiple key presses but we already solved that.

For this upcoming week, I want to work more on both the Game Screen and the High Score Screen. The Game Screen is still missing animations saying “Perfect”, “Great”, “Miss”, etc. when the arrows are clicked. Some aesthetics elements can also be improved, but I am not particularly worried about those at this moment. For the High Score Screen, I will finish the typing functionality and allow the player to save their scores. Also, during class time, Spandan and I will work on integrating our screens.

For this week, my goal was to polish the game screen and implement a combo mechanic we came up with.  I started by changing how “Flex Dance” was drawn on the screen. Before, it was an individual image, but now, I have added it onto the original background since it is static. Now the background image is a starry sky and the Flex Dance banner. This was more faithful to our screen mock-ups and can be seem on the screenshots later on the post.

Next, I implemented the combo mechanic. The game has a score multiplier which increases with the more arrows a player hits consecutively. For every ten arrows, the multiplier increases by 1, up to a maximum of 6 (we chose 6 because it is the number used by some other rhythm games). When a player scores an arrow correctly, they receive a number of points multiplied by the combo multiplier. The combo is tracked by a circular progress meter on the top right:

The color of the meter changes depending on the current value of the multiplier. In the example above, the arc is red for a multiplier of 1, but after scoring a few more arrows correctly, the meter fills up, the multiplier increases to 2, and the meter resets, now appearing blue.

I also made some small quality of life changes. The text font size now adapts according to the display size, the song icon was shifted up a bit, and pressing the ESC key will close the game.

I am somewhat behind schedule now unfortunately. I was supposed to have finished the game screen by this week. It is almost complete, but it is missing the linear scale scoring, the pop-text saying “Great”, “Perfect”, “Miss”, etc., the the fonts are not the final ones, and the arrows look stretched. The final game also does not have a lives mechanic, it just accumulates scores until the song ends.

For next week, I intend to finalize the game screen, making the change stated above, and start to work on the high score screen as well.

For this week, my task was mainly to work on the game screens for Flex Dance, i.e. the screen that shows the arrows coming up. I built upon my mini project from week one since it’s mechanics are somewhat reminiscent of the game screen mechanics.

First, I changed the arrow spawning logic to have the sequence not be random anymore, but instead pre-set from a data structure (call it the “choreography” structure) that I could edit within the code. It’s essentially a list of python dictionaries, each dictionary with an “arrows” key that stores a list of arrows and “timestamp” key that indicates how long after the song begins playing the arrows from that list should spawn.

Once I checked that the above was working properly, I changed the code to have the choreography be read from a file instead of hard-coded. The file also contains the duration of each bar in the song so that the timestamps can be extracted as well. Lines that begin with a ‘#’ sign are considered comments in the file; they were implemented to improve readability and credit song creators.

Finally, it was time to add a song and see if I could synchronize the song properly with when the arrows were supposed to appear. This was the trickier bit and I’m not fully satisfied with it yet. In particular, since I’m testing with a royalty-free song from the internet, there aren’t music sheets available for it, so it’s harder for me to pin down the exact beats. For next week, I plan to test the synchronization part using some well-known public domain song like “happy birthday”, since I’m pretty sure I can find music sheets for that and not be sued if I add the music file to a public GitHub.

I also made some more quality of life changes, such as putting the game in full screen (though I’m also having some trouble here because of 4K monitors being weird to work with), changing the screen design to look more like Flex Dance, and adding a song icon to the screen. Throughout this week, I decided we will not have our song track files inside zipped folders, since we would need to extract the files temporarily to work with them. Also, the memory gain from compressing .mp3, .jpg, and .txt files is too small for our scope in order for the compression to be meaningful (it was a gain of about 60 kB per song).

 

The current version of the game screen can be found here: Flex Dance Game Screen Test. For next week, I plan to keep working on the game screen. I want to synchronize the music properly, add a pause button, adjust the proportions of the icons on the layout, and group most of my current functionalities inside a GameScreen class to make the final code tidier. One issue that came up this week was that I noticed we forgot to decide who is making the High Score screen, so Spandan and I will figure that out.

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.

For this week, I had three tasks to work on. The first one was designing the code structure for our project, namely what files hold which classes, what each class does, how they interact together, etc. Below is an image of the diagram I drew of the code structure:

The mat.ino file will be uploaded to our Arduino and is responsible for interpreting user input (i.e. stepping on an arrow) and sending it through USB to the Raspberry Pi. The mat_event_handler.py file reads the USB port of the Raspberry Pi for information from the Arduino and sets off a pygame event according to the input, if there were any. The components.py file implements the basic classes (and their subclasses) that make the game: Screen and Button. A Screen object has its own drawing and updating methods to make it simple to draw and update the game through main.py. A Button object has a method that does something (change a screen, update the current screen, update the score, etc.) according to which input is pressed when the button is selected. The song_reader.py file implements a class to read our custom track files (a zipped archive containing an mp3 file with the song and a text file describing the arrows for that song). The constants.py file sets all the constants needed for the game, such as FPS, sounds, icons, and colors. Finally, the main.py file runs the main loop of the game, updating and drawing the screen using objects from the previous files.

My second task for this week was to help with the Design Review presentation. I worked on my four slides, which mostly had to do with testing and implementing the software. Notably, a proper block diagram of the drawing above was included in the slides.

My last task was to research the music file format used by traditional rhythm games such as Dance Dance Revolution and Guitar Hero to create our custom track file format. However, I did not manage to finish this part. The Design Review presentation took more time than I expected, so I am a little behind schedule now.

My goal for next week was to start implementing the game, but I will have to make time to research the file format as well. Since I scheduled four weeks to work on programming the base game, I believe I can definitely set aside a few hours to look up how those other games implement these files and get back on track. I’m very excited to start working on the game code!