[Week 14] Final project update – Ngoc and Maaz

This week, we started working individually on different parts of the game largely due to the nature of our virtually non-overlapping working hours (Maaz sleeps at 11 in morning which is when I wake up). Regardless, we sat together towards the end of the week to complete most of the functionalities of the game.

The code for the project can be found on the Github repository (which doesn’t have the latest code yet).

Demo & User testing #1

Demo

User testing #1

Processing

We started with coding the classes before integrating them. We started with the base classes like Item and Player which we then used to build the Level class and Game class. Maaz wrote the code for the Item class while I wrote the Player class and we tested the classes individually. After that, we had discussions on how to combine the two classes to start implementing the Level class, adjusting the base classes if necessary to get the classes to work together. Once Level was implemented, we then wrote a wrapper program (which will be cleaned up to make the Game class) to test all functions of Level.

Our main priority is to fully implement all the necessary game functions, especially the interactions between different classes as well as Processing – Arduino communication. Therefore, we used a lot of placeholders in the process (for example, though we had a list of sprites to use as items, we don’t have one for the player) as well as randomizations and default values (the items are appearing randomly and they all hold the same score for now). Using such placeholders and randomizations makes the game pretty easy for now (as can be seen in our user testing #1, where our player wins pretty quickly). We wanted to focus on having a version of the game that runs fully from start to finish. So far, we have managed to achieve this. For the rest of the project, we plan to make adjustments to existing functions in order to make the game more challenging. Some of the necessary adjustments include:

• Building a system of item values: as of now, all the items are worth the same value (for testing purposes). We plan to add an extra Value attribute to the Item class and vary the value given to each item.
• Changing frequency of appearance of items: right now, the items are added randomly. We plan to control which items will appear at which level (for example, Study away should only start appearing since sophomore year, and Capstone should only appear in senior year) and with different frequency (J-Term should only appear once per year, and it should have a higher value).
• Finishing up with the graphics: right now, the graphics are at a minimum to guide the user through all the functions of the game. We will sure be touching up the appearance of the game.

Arduino

Distance measuring sensor: We have been experimenting with this sensor ever since the start of the project. Please refer to previous posts for a detailed description.

https://intro.nyuadim.com/2021/04/19/final-project-progress-ngoc-and-maaz/ – Remote Control Testing

Potentiometer: We use the potentiometer to traverse the options on the screen, if available. The input value is mapped into the range of the number of available options, and the currently selected option is highlighted on the screen.

Button: The button is used in tandem with the potentiometer: while the potentiometer is used to traverse the option, the button is used to signify the actual selection of an option.

Tricolor LED: Initially, we planned on having 2 tricolored LEDs on the breadboard, each one of them corresponding to the two metrics of performance. However, with so many components on the breadboard, we ran out of pins to connect the two LEDs to. Also, it was hard to keep a track of which LED represented which performance. So we decided to have a single LED to show how good or bad the player was doing on the game. The LED would turn green if the player was doing well with regards to both academics and health, and it would turn red if the player did poorly in any of the two performances. In other cases, it would stay yellow. These signals were sent from Processing to Arduino to set the LED to the relevant color at that point in the game. This helped us to give an indication of the overall performance of the player.

Piezo buzzer: We decided to make the buzzer play a short sound whenever the player collided with any of the items. This was done by keeping a check within the checkCollision() method and sending a signal to Arduino to make the buzzer play a note. However, we noticed that it worked for almost all collisions except for a few, and we spent a lot of time trying to figure out why this problem occured. Even after trying out multiple different methods, it never gave perfect results, so we plan on working on it further in the coming week.

Graphics

Since our game was supposed to have items of 4 different categories, we realized that it was important to have enough items for all of them. The four categories are: academics – good, academics – bad, health – good, health – bad. We ended up making 19 different sprites using https://www.piskelapp.com/. This was a relatively hard process since getting the sprites to look good is always one of the most essential parts of making any game. Additionally, since the game is NYUAD-themed, it wasn’t possible to find relevant sprites on the internet and we had to make all of them on our own. All of the sprites are 100×100 pixels and most of the sprites have multiple frames; the Processing part of our game loops over all the frames to animate the sprites. This was a fun but tiring process, and below is a video of Maaz vibing to one of his favorite songs as he tries his luck with making some of the sprites.