Posted on

Team Status Report for 02/19

For this week, our main focus as a group was working on the Design Review presentation. Working on the design review also helped us clarify further details about our design. We spent some time making diagrams and prototyping the look of the game screens. We discussed the GUI and the sensors in the mat in depth. For now, we have a good idea of what the GUI will look like. The sensors for the mat is something we have to test. We do have mitigation plans for if the sensors don’t work the way we want it to. Moreover, we received some of the materials we ordered and anticipate that we will receive the rest by Monday or Wednesday. On a smaller note, we also created a public GitHub in which we can share resources and keep our code centralized. We will add a link to the GitHub to the website later.

We still believe the biggest risk our project faces at this current time is procrastination or poor time management. By now, all three of us have experienced a minor delay in our schedule in some way. Our contingency plan remains the same: holding each other accountable and asking each other for help when necessary.

During this upcoming week, since we will be testing our sensors, we imagine that other issues might rise, particularly with how we envisioned our mat coverage. We have heard that the sensor we bought doesn’t seem to be bendable in the shape of a circle as we had hoped, but we will be testing it this week. Should the sensor prove to not meet our expectations, we have plans of laying it out in a ‘Z’ or ‘N’ shape instead of a circle over each square.

In terms of design, we had one major change to our mat this week. We decided to add one extra button on the top left (or top right, we haven’t figured out which) to act as a pause button, since pausing mid-game was a hassle with only the four arrows. Adding this extra button also helps because it can double as a confirm button in menus in which pausing is not necessary. This change, however, has incurred no updates to our schedule, since it simply involves buying more sensors and investing a couple more minutes into building the mat.

Posted on

Caio’s Status Report for 02/19

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!

 

Posted on

Team Status Report for 02/12

At this moment, we have not identified any technical risks pertaining to this week in particular. We believe that, for these semester-long projects, one major challenge that people face in the beginning is the false belief that “the deadline is still far away, we have a lot of time”, which leads to procrastination. There are two main ways to tackle this issue, namely each one of us committing to a personal schedule to complete our tasks and all of us making sure we help each other stay on track. In case procrastination becomes an issue, we can each put more effort into holding each other accountable, and as a last resort we have our buffer time allocated in the schedule.

There were no changes made to the project this week. We used our time to order some of the necessary parts we need for testing next week.  Particularly, we are hoping to see how well the 2 feet sensor performs compared to alternatives, and how it works with the Arduino. Moreover, a good amount of time was also spent getting familiar with Pygame.

For the upcoming week, we are mostly planning to allocate our time to the Design Review presentation. We will start preparing the content for the slides on Monday and work on building the presentation throughout the rest of the week.

Posted on

Caio’s Status Report for 02/12

For this week, my goal was to get familiar enough with the Pygame module through tutorials so that I would feel comfortable learning from the documentation by myself.
I went over both these tutorials on YouTube:

To test that I had actually learned from the tutorials, I made a mini Dance Dance Revolution-like game using Pygame. This game was useful both for honing my Pygame skills and understanding the structure of DDR-like games more. I added a couple screenshots of the game below (they are compressed so the resolution isn’t great). WordPress does not allow uploading zipped files, so the mini game files (code and assets) are available in my GitHub: Capstone Mini Game

Currently I am on schedule. My goal for next week is to design the libraries and the structure of our final code. I intended to make flowcharts and diagrams to show the code structure. Also, during this upcoming week, we will all be working on the Design Review presentation.