Posted on

Spandan’s Status Report for 03/26

This week was a productive week and I was able to make progress on my menu screen. My menu screen is able to do song selections based on the up/down key movement and can navigate to a new screen when the right key is clicked. This is shown in the attached picture:

The current colors are just placeholders. To facilitate a smoother code implementation, I took help from Caio and came up with the idea of keeping the rectangles constant and just revolving text and album images when up/down keys are clicked. This way I will not have to worry about varying the opacity of the rectangles themselves, which is a hard job to accomplish in Pygame. As you can see, though the rectangles have varying shades of grey, none of them are translucent.

Moving ahead, I need to resize the text and album covers and make them movable with the rectangles. Additionally, I want to give the rectangles varying opacity. I am not worried about moving the text and album covers as the code I have written to move the rectangles can also be applied to moving texts and images.

Overall, I am slightly behind the schedule but hope to accomplish the full menu screen by Monday.

Posted on

Team Status Report for 03/26

This week, our team primarily discussed the ethical consequences of our game and met mid week to double check the parts of our mat and create a plan to move ahead.
Based on the ethical discussions, some of the points we realized were that our mat is not suitable for people with walking disabilities or who cannot perform fast reflexes. Our mat could also cause physical injuries if it is too slippery as the user could slip and hurt themselves by clashing against a furniture piece. Lastly, while playing the game, there might be a lot of loud movements (such as the thuds of the player stepping swiftly on the different buttons of the mat) that are unsuitable for a living space such as an apartment. The noises could disturb the neighbors living beside and under the player’s unit.
On Wednesday, all three of us met at tech spark to look at the parts we received and create a plan of actions we needed to take. To ensure that any partial deliberate step would trigger a response from the buttons, we decided to create a “Z” shape for the first orientation of materials to put under each of the wooden squares for the buttons. This is shown in the diagram below that was drawn by Spandan that gives you an idea of how the wooden part of the button will be constructed:

After mutually agreeing on it’s dimensions, Tushhar began the process of laser-cutting the said Z shape. Meanwhile, Caio and Spandan worked on their respective screens of the game. Caio is almost done and just needs to figure out scaling of the background screen but the screen is functional. Spandan has figured out how to choose songs through the arrow keys and how to navigate to a new screen.

Overall, the team is right on schedule except the actual physical construction of the mat. The revised schedule is as below:

We will all meet early next week to begin the process for the mat which will go along the following steps:

  1. Lasercut Z shape and layer
  2. Steps after all materials are acquired:
    1. Figure out measurements for squares
      • Each square 12 inches by 12 inches
      • 0.5 inch gaps
    2. Measurements for Z shape for laser cutting (long lines instead of z shape)
      • 7.5 by 8 by 7.5
      • 1 inch side
    3. Figure circuit layout throughout the mat
    4. Length of wires and soldering
    5. Painting on the mat
    6. Attaching layers together
Posted on

Caio’s Status Report for 03/26

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.

Posted on

Tushhar’s Status Report for 03/26

For this week, I was unable to continue to test the Arduino program with the Python minigame as the Arduino Leonardo board we ordered has still not arrived. However, the materials for the mat arrived. Therefore, I was able to work on some of the things we need for that.

Upon discussing some points on what we need to do for the mat, one of the first steps that we need to get done is laser cutting the correct plate shape and size, as well as a Z shape for the FSR. I was able to take measurements and model it on Solidworks. The pictures below shows what I have been able to make so far.

The second picture is the Z shape. The following 3 pictures is the Z shape broken down into pieces so that it can be laser cut more easily without waste. This was an informed decision. Using a whole 1 ft by 1 ft board per Z shape would not only waste a lot of materials but also be expensive. Breaking it down eliminates this issue. Since this is a busy week for me, I wasn’t able to do more. However, I can make much more progress now with the mat materials here.

Next week, I am aim to laser cut the pieces in the picture above and test the configuration of the mat with the necessary layers just for one square. I will also make a layout for the wires in the circuit layer. Furthermore, I am hoping to test the Arduino file when the Arduino Leonardo arrives. Any other things I will do will depend on further discussions about building the mat with my team.

Posted on

Spandan’s report for 03/19

For this week, I primarily worked on three things, namely, ordering parts for construction of the game mat, understanding the ethical weights of our game, and lastly construction of the menu screen.

For the parts of the mat, I referred to our bill of materials and succeeded in ordering of most of the parts for our mat based on the two different orientations we are currently imagining our mat to use:

For understanding the ethical responsibilities of our game and how it fits into solving a social problem, I utilized my human-computer interaction background and tried to empathize with the users of our game. I tried to understand the pros of using our game (fitness, mental and physical well-being) and where our game fell short (it is not suitable for people in wheelchairs for example).

Lastly, for the construction of the menu screen, I watched quite a few YouTube videos and referred to the actual Pygame documentation to understand how animations work in Pygame. We need animations to enable the scrolling effect for our users. Currently, my idea looks like this:

  • Have separate objects for album covers, texts, and rectangle containing this information
  • Have another class containing these three separate objects
  • construct a resize option that is dependent on “up” or “down” key press
  • Use this resize option to resize album cover, song and artist names, and rectangle containing this information to give the user the effect of scrolling

I still have to implement this and am currently in the stage of coding the above solution. For now, I am right on path and will hopefully complete this on time.

Posted on

Tushhar’s Status Report for 03/19

Since the last report, I was able to further test the sensors and work on Arduino communicating with Python.

In class, I was able to take some measurements with the help of my teammates. We tested the viability of bending the FSR into a Z shape. The circuit we used was similar to the one in the last status report.

The above image is a screenshot of the Serial Plotter from the Arduino during the measurements. The peaks represent taps by the foot on the FSR, while the plateau represents keeping the foot there for a period of time. The results seemed to be quite reliable. More details about the results are discussed in the team’s status report.

The next thing I worked on was the Arduino file which would relay the values from the FSR to the Python file. Caio showed me a really good resource which showed how analog values could be mapped on to keyboard buttons. Registering FSR hits as keyboard buttons would make integrating the game much easier. Using that file as a reference, I was able to write Arduino code that should work for our purposes. The code is in the following link.

https://github.com/CaioA1516/Capstone/blob/main/ardToRaspPi.ino

We were going to test it with 4 simple buttons and the minigame that Caio developed. However, we found out that Arduino Uno doesn’t use the Keyboard library. We have taken steps to solve that issue which is described in the team’s status report. Once the Arduino Leonardo with headers arrive, this code can be tested and modified accordingly.

The next week, I should be able to further work on this once the Arduino arrives. Furthermore, I will get very involved with the construction of our mat once the parts arrive. I believe I am one week behind schedule due to not having ordered materials for the mat earlier. However, there should still be time to make progress on that in the upcoming weeks.

Posted on

Team Status Report for 03/19

For the past two weeks, we did not do much work together other than ordering materials for the mat; we were all mostly working on our individual parts. We did, however, face a couple issues and made one change to our project.

The first issue was that Tushhar’s testing of the force-sensitive resistors showed that our initial idea of simply folding it into a Z shape hurt it’s sensitivity at any region after the first fold. Interestingly enough, further testing showed that folding each corner twice (so that the same side of the FSR faces up on all three sections) does not hurt the sensitivity of the areas after the first corner. Unfortunately, these double folds could be quite tolling on our FSRs and hurt our durability requirement. Should this prove to be the case eventually, we have changed our mat design to incorporate small, solid plates on top of each FSR so that we can lay the FSRs flat instead of folded and have the solid plate transfer force to the FSR when pressed anywhere. Furthermore, we have already tested the viability of such plates during testing. They provided reliable results as well.

The second issue was that when we were testing using an Arduino to double as a keyboard to simplify our input processing, we learned that the Arduino Uno we had for testing does not support the keyboard library. The good news is that the Arduino Leonardo that we first ordered should support the library, but the one we have at the moment is headerless, and thus not ideal for quick testing. Since we have a reasonable amount of budget left, we placed an order for a second Arduino Leonardo, but with headers this time.

As for the change, while Caio was implementing the song track parsing part of the game screen, we realized using a zipped archive to store a song’s data (MP3 file, icon file, and arrow sequence) was cumbersome. In order to work with these files in Python, we would have to extract them to a temporary location, and then delete the extracted versions after we were done operating on it. We compared the normal folder memory size to the zipped archive, and found a difference of only 30 kB. Each zip archive is around 4.28 Mb, which means that we need 4300 kB / 30 kB ~= 143 compressed songs to have enough saved space for an extra compressed song. Implementing that many songs is out of scope for our project, so we decided to drop the zipped archives for the sake of simplifying the file parsing process.

As noted in Caio’s report, we also forgot to decide who would implement the High Score screen, so we will discuss this on Monday. What we’ll likely do is assign Caio to work on the High Score screen since during the week of Mar 28th he does not have an individual task.

For this upcoming week, we hope to start making our (first) mat! We are all very excited, and by the next status report, we’ll have some pictures to brag about out hardware.

Posted on

Caio’s Status Report for 03/19

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.