Skip to content

Latest commit

 

History

History
14 lines (7 loc) · 4.18 KB

DESIGN.md

File metadata and controls

14 lines (7 loc) · 4.18 KB

Our project uses a firebase database to store all the information about the user and the different games that exist. In addition, we use firebase storage to store all the profile pictures that the different users updated. We decided to use firebase because we needed a database that each user can access and update when playing the game from different phones. We didn’t use the SQL database that we used in the IOS problem set because it was only saved on one particular phone, so only updates from one particular user can be stored. In addition, firebase allows us to store the photos that users set as their profile picture and then save the download URL in the user’s information. Furthermore, Firebase was beneficial because it allowed all of us to be able to view the database from several different computers when we were working separately. As none of us had used firebase in the past, we spent time watching YouTube videos and reading several examples in order to learn how to access and update information within Swift.

The design of our game required that we constantly keep track of a user’s location. To do this, we used Apple's Core Location library. This allowed us to ask the user to allow us to use their location when the app is open and allowed us to get the users location every minute. Each time the location was updated, the new location was sent to the database. This location is then checked whenever one user tries to kill another as you can only kill someone if you’re within 100 meters of them.

Because we relied on storing data in a database, changing this data and retrieving the data from multiple phones we had to use UIActivityViews to show the user when information was being retrieved from the database. This meant that we displaying a spinning loading wheel while the user was waiting. We also used completion handlers to stop the activity Views once data was successfully retrieved.

We also had to write an algorithm for determining everyone’s place on the leaderboard. This was slightly harder than expected because it involves keeping track of how many people are tied, and making sure that they have the same number on the leaderboard. For example, if John and Sarah both have 5 kills meaning they are tied for second place, the number 2 will appear next to both their names. Then, if Ben has 4 kills, meaning he is one place behind them, the number 4 will appear next to his name because there is no one in third place. In order to do this, we had several variables keeping track of how many people have the same number of kills, what their place is on the leaderboard, and how many kills these people have.

In the “alive” tab, we had to write an algorithm so that you are able to swipe on a cell in the tableview in order to “kill” someone. Furthermore, we had to compare the location of the “killer” and the person they kill to make sure they are in close enough proximity for it to count. We decided to have the kill functionality work like this because we wanted every user’s photo easily accessible so that people could look for a specific person to kill. In addition, the swipe to kill is much easier and faster for the user than having to tap through several view controllers.

In the “games” tab, we allow users to switch between games as well as create a new game. We decided to do this so that different friend groups or student organizations could have separate games. In order to do this, we had to create another collection within the database that has a list of all the games. We also needed to connect this collection to the user collection. We do this through a game id. Each user has a game id stored as a variable, which tells us which game they are currently playing in. The games collection stores more information about the game as well as the game id so that we can connect the two collections. This means the game id is a foreign key in the users table.

Lastly, we have pop up alerts that appear if you have been killed or if you are the winner of the game. In order to do this, we are constantly checking the database to see if you are the only alive player in the game (meaning you have won) or if your isAlive variable has changed from true to false (meaning you were killed).