Tetris Documentation

Please enjoy The Tetris Brief 

-Ellen E

Project 3 Phase 2 Implementation

For this phase, we had very strict deadlines and guidelines that were established to finish the project for the day immediately following the 28th after class.

A couple of things changed throughout the course of our design phase and through the implementation phase. We omitted the thought process of having two classes to use for the GameInput class and combined it into a single class.

We also thought that there should maybe be a mouseclick event to interact with the page on things that could not be inputted through the keyboard. This was omitted when we started implementing the project as we deemed it unnecessary to the overall design at that point and to some extent was deemed out of our use case for this project.

From our design phase, we each had our classes that we established to start working on. The GameScore class was established by Matthew as a Singleton. This piece was responsible for methods that manipulate the score of the game. The GameScore class also uses the Constant class to calculate scores, which he also established. Ola established a time frame for our project and initially put together some questions for implementation as well as implementing the InputDebouncer. I was set to establish the GameInput, but after some deliberation, I had trouble implementing it within the 24 hour time frame to finish the project on Friday. Ola helped implement this with use of Tetrino class.

A lot of this deliberation and class design was established through our discussion on our group slack page for Team Bravo Tetris. During implementing our design, we also decided against the click listener. A lot of the overall implementation in terms of architecture was established by Bryce, our team lead, as he helped guide us on pieces that deemed unnecessary or incoherent with our design.

This part of the project was finished in record time on Saturday within the 24 hour time frame established.

-Ellen E

Project 3 phase 2 implementation details

For the next phase, Ellen will implement GameInput and Matt will implement GameScore as documented in the class diagram.  Ola will oversee the implementation and make sure the implementation is completed in a timely fashion.  In addition, Ola will make sure the InputDebouncer and GameInput classes interact as described in the design diagram.

Please consider the following during implementation:
   
1. Does the design diagram give sufficient information to complete the implementation?
If not, what needs to change in order for that to happen?
Please submit any questions regarding design to the Slack channel or here.
   
2. What role does my implementation serve in the overall game design?
Since we are focused on input, our implementation is critical to the testing of the application. Because we are so critical to the success of the project we will have a condensed timeline for implementation.
   
 3.  Am I using all available resources to complete my implementation?
 If, at any time, you become stuck or don't believe what you are doing is correct, ask questions.
Also, the prototype provides most of the information necessary to develop your solution.

We will be following this timeline from here until completion.

The initial implementation should be completed no later than 29 October 2016 at 3 p.m. CST.
 Matt, please review your implementation and make any necessary changes by this time.
 Ellen, I will begin your implementation so you have something to reference.

I will code review at 3:15 p.m. CST on the aforementioned date.  I will message/post all changes, if any, that need to be made.
All subsequent changes are due by 7 p.m. CST on 29 October 2016.

Please note:
The changes we make will be based on our design not the overall implementation.  There's no telling what additions/subtractions will need to be made until integration testing takes place.

If this timeline doesn't work for you, please say something immediately.  If these times don't work, please say something immediately.  I will pick up as much slack as I can.

Project 3 - Tetris Initiation

Initially, we looked at the project as a whole and began by breaking down each part into components to start working through as individuals. These became the input, the input bouncer, and something to keep track of points as the game was being scored. For me, it was slightly overwhelming seeing the light at the end of the tunnel, but as we started breaking down each component things starting fitting into place.

When we started looking at each component, we first started playing the game to see the general layout and how the game was played (differences from other tetris games etc). For the input, we had to document each interaction that a user would have with the game and how the game reconciled these inputs. This included keystrokes, mouse, and sound. At later stages it also included how these things affected one another in the sense of how the game was played.

At later stages of our discussion, we were able to get some classes identified for each list of interaction and set a layout for our design with a series of established interconnected classes. A big part of this challenge was compiling and syncing everyone's ideas into a general format, but it came together and with some small commissions and additions a final design was established and ready to be implemented.

Project 2 - Implementation Phase

Immediately following the distribution of team projects and receiving our "Spin Design" implementation and having Matthew set up our project, Ola jumped on building the architecture for our methods. The design that we received was very detailed, but with a lot of loops and hard work an excellent draft came about. Working through the solution and a lot of back and forth discussion behind the scenes, we put together a main to test the methods established and had Bryce upload fixes. We corrected the bugs and errors and tried to work with the other group to correct any misunderstandings. Upon completion, we also saw that other designs had been uploaded and we were allowed access to view the implementation of our design as well as others. A note made after reviewing the other team's implementation was that interfaces were not a useful implementation to our bucket design, so we have set to notify them of our feedback. I look forward to going through other team's code and seeing their solutions. While some teams had unit tests that weren't a requirement for the design, we put together our tests in the main. After further analysis, we denoted that the main program would be sufficient.
-Ellen E

Perforce Project File Upload

Tonight, I have uploaded the Perforce shared project file to our team folder,  and created the three empty classes that we will be filling in. We still need to figure out the best way to split up the work load among us, but I figure it's better to start everyone off with the classes started rather than empty.

Project 2 Implementation Phase

Last night, at the end of lecture we met with our group that we are implementing the design of. We are going to be complementing the "Spin" customer specification. We are going to be going through Bryce, from our group, and Brian, of group 4, as our means of communication. We are all going to read through their documentation individually, and will set a time of when to decide how we are going to delegate the work out to each of us. This should happen within the next day or so, and I will be posting further details at that time.