**Project 3 Blog Post:**

# **Project 3 Blog Post:** :::info # Project 3 Information: Similar to the previous project, this project is also split up into 2 parts. However, unlike all previous projects, we weren't really starting from scratch. The codebase was there for the msot part and we were tasked with cleaning up the bugs. The task was to fix a game of Tetris to make it work and function as it should. This meant creating/setting the controls, fixing bugs with the blocks, creating blocks, implementing scoring, and much more. This project was structured in a very unique way which I honestly haven't encountered in any of my other classes. The entire class was split in two and we had two "divisions" ATARI and NINTENDO. Working with this large of a group was definitely an interesting experience for me as I was not familair with the group dyanmics for a team this large. <img src="https://i.imgur.com/7klK1lE.jpg" alt="drawing" width="200" align="center"/> ### Part A: The first part of the project consisted of us creating an intial project design where each group was given an overarching task. This task was then broken down once again within the groups. We had a division meeting on the first weekend where we assigned each team their roles and worked through what we wanted our game to have. We then had a team meeting as well where we split up the roles. We were assigned controls, so each member took about 1 or 2 controls that they were going to implement and we made another design doc within our own group where we described how certain controls could be implemented. ### Part B: For the second portion of the project, we were supposed to individually implement our assigned tasks, and then create pull requests which would be approved by two members of the Division (Blake and Zach). I was assigned R for restarting the game, as well as the shortcut controls information. Our group each got our stuff done one by one and we had a couple of meetings to help everyone debug their code if it wasn't working. We finally merged everything to main and did a final run which worked! <img src="https://i.imgur.com/C8j0OYC.jpg" alt="drawing" width="200" align="center"/> ::: :::danger # Problems during Part A: The first week of the project went pretty smoothly. Since it comprised mostly of assigning roles and creating a design document, we were able to get that portion done pretty quickly. However, my group did encounter one pretty big problem. ::: :::danger ### Problem #1: Because most of the game relied on the controls working, one of the other division members kept pushing us to start implementing controls during the design week. This was an issue because the entire purpose of that week was to simply design and we weren't supposed to implement yet. :::success ### Solution #1: We eventually ended up caving and began implementing our controls during the first week. We just felt it would be better not to start any conflicts and to just get the work done. Ultimately, we were glad we got our portion completed during the first week as it gave us a smaller workload for week 2 and we were able to help with other bugs in the project. ::: :::danger # Problems during the Part B: Similar to part A, there weren't any glaring issues/problems that we (as a group) encountered during the second week of the project. However, personally, I faced a couple of issues. ::: :::danger ### Problem #1: Since we were working with such a large group, I found it very difficult to keep up with everything that was going on with the project. During the first couple projects, I was in the know about almost every change or detail. This was very helpful as I knew exactly where others could need my help. Furthermore, with the smaller group, I also knew exactly where we were in terms of progress. However, with the larger group and most teams within working individually, I was pretty lost in terms of progress. :::success ### Solution #1: Since I was unable to attend the division meeting, I asked a teammate of mine who attended the meeting to catch me up to speed. They helped explain to me what was discussed in the meeting and also filled me in on the current progress. Furthermore, I began utilizing Teams more to ask any questions I had regarding the current state of the project. With these two changes, I was able to have a strong understanding of where we were in terms of progress and I was also able to help out a lot more squashing other bugs in the code. If I was still confused, I probably wouldn't have been able to help out the division with anything more than my assigned tasks. ::: :::danger ### Problem #2: With everything done, a teammate of mine was still having an issue with one of their assigned methods. It was pretty difficult to implement hard drop. With others being busy with other classes/assignments, I was the only one that was available to help. :::success ### Solution #2: Together, the teammate and I were able to figure out the issue and we eventually got it working. It was a very satisfactory feeling knowing that we finally got the function working. ::: :::info # Project 3 Debrief: Overall, this was definitely the most challenging project or assignment all quarter. The actual content wasn't necessarily difficult, but the team dynamic with an entire division of 15-20 people was definitely a unqiue experience. I am not accustomed to working with this large of a group, so I definitely faced issues with communication. However, this is a perfect simulation of the real world as development teams at large companies won't just comprise of 5-6 people. Rather, they may even span upto hundreds of people. Therefore, gaining the experience of working with a "large" team was definitely something that I needed exposure to. I hope to take the lessons I learned from this project about communication within a large group and apply to the real world when I start my first intership or job. :::