Tushhar’s Status Report for 04/16

For this week, I spent most of my time working on the circuit layer of the mat. I was able to achieve all of my last week’s goals.

For many of the components I soldered, Caio and Spandan helped with gathering, planning and holding the components. Having an extra pair of hands really helped speed up the process. On Monday, we were able to solder and label the FSRs to appropriate length of wires based on where they are to be positioned. We also tested them individually to make sure they worked after soldering. On Wednesday, I was able to design the layout for the circuit. Its picture is shown below.

  • A5 to A1 refer to the analog pins that they will connected to on the Arduino.
  • The letters represent the following
    • U: Up FSRs
    • L: Left FSRs
    • R: Right FSRs
    • D: Down FSRs
    • P: Pause FSRs
  • The number 1 corresponds to the first pins for both FSRs in parallel (for corresponding arrow) and the number 2 corresponds to the second pins.

On Friday, we soldered female headers to the perfboard according to the layout above. The reason we decided on female headers instead of direct soldering is because the connections to the FSRs won’t be permanent and can be debugged/replaced more simply if need be. The perfboard was tested with buttons and works properly (similar to how it was tested on breadboard). Here is the picture of how the connections look.

I also learnt how to use the sewing machine in Techspark alongside Spandan from a nice person there. For the upcoming week, I am planning to attach male headers to the ends of FSR wires so they can be put into the female headers easily. With this the circuit layer of the mat should be good to go. I will also be working with Spandan to cut and sew the tarp for the mat. Rest of my effort will be put towards the final presentation.

 

Caio’s Status Report for 04/16

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 Menu Screen before I chose to dance to this song. Notice there are no high scores.
The Game Screen right before I finished dancing.
I can then input my name using our keyboard.
The Menu screen after I danced the song and got a high score. Notice that now my name appears with my score next to it.

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.

Pause menu interface

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).

Spandan’s Status Report for 04/10

This week I presented my menu screen at the interim demo that can successfully works with the circuits. My goals for this week were to work on displaying high scores with respect to each song and to integrate my screen with Caio’s. Unfortunately, I was struck with the flu so I was not able to meet with Caio and work. I felt much better today so I have started writing the code for displaying high scores but have not yet achieved visual results. On the other side, I tried learning sewing for the construction of our physical mat that my team plans to achieve this coming week.

Team’s Status Report for 04/10

This week our team performed the interim demo where we showed the integration of the circuit and software sides of our project. Our sensors successfully work with our menu and game screens.

One of the major decisions we took as a team was to discard the “Z” shape of our FSR’s primarily because they lose functionality over the folded region after a point of time. After some deliberation, we have decided to place the sensors in a parallel manner. Based on our testing, this structure is able to detect the footsteps in any orientation.

In terms of our schedule, all the laser cutting for the parts is completed. We are behind on integration of the menu/game screens but plan to have it completed by Tuesday. We will spend the upcoming week integrating our screens, combining the different layers of our mat, and building the circuits on a perfboard.

Caio’s Status Report for 04/10

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.

Fig. 1: Same image as last week. Notice that the keyboard keys are overlapping, and they shouldn’t be. Once I fixed the overlap, there was no space for the Submit key, which should go under all the other keys.

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:

Fig. 2: Current look of the keyboard screen. Selecting a letter will change the left-most empty character to the selected letter.

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.

Tushhar’s Status Report for 04/09

This week, I was able to properly demonstrate the Arduino and plate working in unison with the game in action for the Interim Demo. Before the demo, we made sure the plate replacing the button from last week worked properly. The following picture is taken from a video in action.

Rest of the work mentioned below has mostly been in conjunction with Caio. Upon moving on to the next step of soldering, we found that the Z shape FSR was unresponsive for the sections after the fold. This also resulted in many foot orientations not working. We decided to thoroughly test other possible options for the FSRs. Ultimately, we came to the choice of using the FSRs in parallel (both in arrangement and the circuit). In terms of response, this worked the best. The FSRs can also be cut from the 2ft length and still work properly. For the best results, the plates will be placed such that the FSRs are perpendicular to the the up arrows.

After this issue was dealt with, we soldered some of the FSRs to properly measured length of stranded wires. We also used heat shrinks to prevent the two open ends of soldered wires to touch each other and short circuit. After doing so, we tested the FSRs again to make sure that the heat from the soldering iron did not damage it.

For the next week, I aim to finish soldering rest of the FSRs. I will also try to secure a perfboard from IDeATe. If unable to do so, we will order some. I will design the layout for the perfboard connections and solder the circuit accordingly. With this, the circuit layer of the mat should be mostly complete.

Caio’s Status Report for 04/02

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.

Team Status Report for 04/02

For this week, we were each able to work on our individual tasks and then combine some subsystems to have it ready for our Interim demo.

Spandan worked on the menu screen and is almost finished with it. She also layered the Masonite plates with evafoam and worked with Tushhar to integrate a FSR to one of the plates. The Z-shape now has their corners cut off to let the FSR fold properly. The Z-shape also sandwiches the FSRs and is still responsive to footsteps. The plate is nice and firm to step on as well. This will be further demonstrated in the Interim demo.

On the other hand, Caio and Tushhar worked together to test and connect the plate to the game. The Arduino file was tested and modified to work properly with the game. One of the important issues we took care of was the button held down being read as several inputs together. This often messed up with the combo as even brief steps would register as multiple hits of the arrow button. This has been accounted for now. However, it may change if we consider adding holding down arrows as one of the game features.

According to our schedule, we will likely need at least 1 more week in the buffer period to construct the mat and make the pause screen + high score input screen. Caio and Spandan will also work on integrating their menu screen and game screen together.

Tushhar’s Status Report for 04/02

For this week, I was able to work further on the plates of the mat and have the Arduino communicate with the python program. This was especially the focus as it also allowed to have something ready to show for the interim demo.

I was able to laser cut the files from last week. We have decided to use Masonite as the material for our plate and Z shape. Furthermore, our discussion with the professor and TA helped me realize that ends of the Z-shape could be left open to allow the sensor to fold. The files for laser cutting will be adjusted accordingly.

Fortunately, the Arduino Leonardo with headers arrived at the start of the week. Not only did that allow me to test the Arduino program but also integrate it to Python programs with the help of Caio. The testing was first done with lever switches replicating the different arrows.

This testing helped me find out errors and fix my Arduino file. Once it was working on the Arduino Serial Monitor, we tried it out with Caio’s game screen and made further changes to the Arduino file including accounting for holding down the button and setting thresholds. The new file and picture of our testing is down below.

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

Lastly, Spandan and I were able to make one plate integrated with the FSR. We have tested it with Caio’s game screen and will have it ready for the Interim Demo. In terms of progress, a good amount of work was done this week. Since I wasn’t able to make the circuit layout this week, I plan to make it next week. I will also laser cut pieces for rest of the mat, as well as get started on soldering some FSRs.

Spandan’s Status Report for 04/02

This week was very productive. In a nutshell, I aided in the construction of the mat and mostly completed the menu screen.

For the mat, as my teammates worked on ensuring the circuit was compatible with our game screens, I added padding using EVA foam to each of the wooden squares that we will be using to make the buttons of the mat. I also aided in testing of the mat.

Additionally, as stated in my previous status report, I worked on the menu screen and have attained 90% of its completion. After taking help from our TA Joseph and fixing some bugs, I am able to make the rectangles transparent based on how far they’re in the menu selection. An image of the same is attached below:

The only thing remaining is displaying high scores based on the song selection but I plan to do it when both my menu screen and Caio’s game screens are integrated. For now, I am uptown speed with our timeline.