ZWOLYA
Description:
Remote_Checkers is a game application which allows two players to play Checkers from two different locations. It requires a Server to be running, which can be started by either of the two players or a third party. When two players to connect to the server, a game session is created. The game is top-down and follows the standard rules and regulations of Checkers. Players will take turn making moves and trying to capture all of their opponent’s pieces. When a winner is decided, players can vote for a rematch, or go back to the main screen and connect to a new game.
Dev Notes:
CS-451, Software Engineering, is the last pre-requisite before senior design, and involves a term-long project done in small groups. We were required to make a networked Checkers application...and that was the entire given project description. Our professor wanted us to go through the whole industry development process, including gathering requirements from an imaginary customer and writing all the design documents ourselves. At the end of the term, we gave a presentation including a demo, the results of our test suite, and other information as if we were delivering to the customer.
We designed our game using sockets for the network component and Java Swing for the graphical interface. I was mainly responsible for the players' interactions with the client code. I chose to represent the board as an 8x8 array of Element enums, identifying the contents of each board space. When the client receives a message from the server, it parses it into either an updated board or text to be displayed, then refreshes the JPanel for the user. There's also code to flip the display of the board so that the user always sees their color checkers on the bottom of the screen, closest to them.
Now, the real lesson I learned from this project was to make sure to start out with a strong design. I personally didn't know much about socket networking, and the team member who did offered to write that part of the code, the Transcription class and the rest of the server (with the exception of the Checkers game logic). Because of this, he also ended up designing the entire system architecture to match in style. What this led to was a set of pretty class diagrams, but code that I would describe as "down the rabbit hole": lots of single-line methods that just called other single-line methods in a long chain before getting to the actual functionality. It was code that was hard to work on and even harder to debug. We powered through and finished the project as it was, but after the class ended, I went back and restructured a local copy of the entire project, just for my own exercise. I cut out more than half of the files and greatly simplified everything that was left. I had learned what the class was really trying to teach us, the importance of a good blueprint, and I made sure to prioritize the design phase of senior project when it came time for that, knowing that we'd be working with whatever we came up with for the whole year, if not beyond...