# SE475 Design Journal - Week 9 ### 11/8 For the bugs-fixing phase this week, I was assigned an issue related to my part of the code. The random generation seemed to be producing too many shapes of the same time. Originally it relies on C#'s random number to determine the type, but now the division leader thought that this didn't feel like Tetris. The interesting part for me is how people would have different expectation and perception of what the goal of a project is. For me, delivering bugs-free code that serves the purpose of the code is good enough for me; for the division leader, its about recreating the game as close to the original as possible. I think it would also be important to communicate stuffs such as expectation and goals, perhaps even document it properly, at the planning stage of the project. The change was not that hard though. We decided to track the last 10 shape generated and make sure that the next shape has not been seen in those 10 shapes for more than 3 times. ### 11/9 After I submitted the PR, I got comments from the division leader that he thought it would be better to decrease the number of previous shapes that we are tracking from 10 to 7. I am not sure why he wanted that because reducing the number would make it more likely for a shape to repeats. I tried to express this to him but we didn't exactly reached a consensus. But since it wasn't really a bug and it did serve the purpose of preventing a shape from repeating itself too often, he approved it and we merged the code. Just a side note on this -- In typical game development process, it would be the level designers and testers that conduct several gametest sessions to find the best rate each shape generate. The programmer only needs to provide functionalities for them to tweek the probability. This also highlights the importance of defining clear goals for each role and identify non-goals in a project so that resources can be utilised more efficiently.