Building BB7K

I worked with Eric Bai on our CS246 final project based on the Monopoly game. This game option was new this year, and it is based on the University of Waterloo buildings, with some quirky campus references such as the DC Tim’s Line and Goose Nesting.

This project was one of the largest games that I had completed from beginning to end and I learned a lot along the way. I get the most experience from these projects because I work on the it from start to finish, from the architecture of the code, ensuring that it meets the given specifications, debugging, and finally creating a website to showcase it. This project also allowed me to gain a better understanding of the steps to launch a product, which will help me when planning future projects.

This project had gone very smoothly. One important consideration was to keep each other informed of any deviations from our initial plan. This wasn’t a big challenge for us because we planned out how the program would be organized before we implemented it. Furthermore, we usually didn’t work on the code at the same time which allowed us to message each other afterwards when we did stray from the plan. We also split up the work in a way such that there were few dependencies between us, and we didn’t need to understand each other’s exact implementation details to accomplish our own task.

Plan accordingly

The only problem that stuck out for me was right before the due date. We realized that creating the documentation¹ took a fair amount of work. However, we started working on this just hours before it was due, while also doing our final testing to make sure our game met the specifications. Instead, we should have finished the documentation the day before (without much time pressure), and dedicated the last few hours solely to testing.

The biggest lesson I learned from this project is to carefully consider the marking scheme at three critical moments in a project. These points are at the beginning of the project, somewhere in the middle, and a few days before the deadline. It is pretty obvious that a plan should be drawn up in the beginning. It is just as important re-examine the schedule towards the end so that the features that will be part of the release can be finalized.