We are all poor college students who rarely go to the gym, so we thought it would be cool if we can experience being healthy and wealthy at the same time! Due to the recent hype with Pokemon GO!, the idea of Monopoly GO! just naturally came to us. We thought the concept was not only outstandingly interesting but also challenging for a Hackathon, which motivated us to build this mobile web game in less than 36 hours. The reason we want it to be mobile-based is pretty evident in that the users are playing this game outside while exploring their neighborhoods. We built it on the web since it's too much work to make a hybrid mobile app.

What it does

It allows users to enter a game room where a preset map is chosen. When all players reach the starting point, the game automatically begins by selecting the first user to roll a die by accelerating his/her phone in the z-direction. This player then receives a number 'n' and will be prompted to walk to that specific location 'n' units away (which is shown on the map), while GPS tracks the player's location. When the player arrives, he/she will either arrive at an already owned house by another player, his/her own house or a for-sale house. Based on these cases, he/she will either have to pay the rent, do nothing or choose whether to buy the house respectively. After this player finishes, the second player will be prompted to roll the dice. If the player's 'bank balance' becomes less than 0 when he/she has to rent another person's house, then the player loses and will be shut out from the game room. If all houses are bought, then the player with the highest net-asset wins.

How we built it

We first divided our work into primarily 2 sections: back-end and front. One of our teammates was solely in charge of setting up the database with node.js and mongodb, whereas the other two focused on UI, which includes manipulating google maps API, simulating dice roll with accelerometer and three.js, and designing overall logic of the game. We used github as a way to collaborate. After we are done our separate parts, we then had to piece the UI parts together and integrate the server side to our design logic.

Challenges we ran into

First of all we wanted to try something new, so we used a framework called semantic ui when none of us had any experience with it. Moreover we all knew bootstrap but since our goal is to learn, we did not end up using it either. We had a hard time building the rolling dice since it involved both accelerator and WebGL, and we have never acquainted ourselves with them either, making adjusting the parameters extremely difficult. We also encountered difficulties while integrating back-end with front-end due to the conflicts in logic, which involves graphics. Because we are dealing with graphics, it's easy to make a mistake, which causes memory leaks or infinite loops.

Accomplishments that we're proud of

We are proud of completing the basic structure of this project since the entire thing is a challenge for us from the beginning, as we almost thought it was impossible. Also we worked harmoniously throughout the Hackathon, which bonded us with each other more. Moreover not only were we unprecedentedly productive, but also we still managed to have fun during the events, with lots of swags.

What we learned

There's no doubt that we all learned something new, whether it's our first time dealing with WebGL or using semantics UI. These new areas of knowledge allowed us to learn even more in other fields. We also learned that sleep is important.

What's next for Monopoly GO!

There are a lot of features that we want to integrate but we didn't have time, so here are a few:

  1. Instead of making preset maps for users, we want the users to be able to draw their own maps which allows all users to play, instead of only those in the specific regions where we have defined the maps.
  2. The game design would be more complicated than this basic idea that we have. Afterwards we want the users to be able to sell their properties if they were to go bankrupt, and open up the houses to other players if the user does not decide to buy the property.
  3. We would like to have a live-chat between the users so they can communicate when they are at different ends of the neighborhood.
  4. In order to quicken the process and lessen the wait, we are planning on generating an algorithm such that the second player can start rolling the die before the first player reaches his/her property.
Share this project: