Gomoku, also known as Gobang is a connect five strategy board game. Two players alternate turns placing blue and green pieces on a grid board to connect five.
Because the last team working on it tried to refactor everything in the code, we can’t run the newest version program to test for different stories. We can, however, run the older version, so that’s what our stories will be based off of.
- As a user, I can click on a circle and place a marker on it, another user (player 2) can also do the same in a different color in alternate turns.
- As a user, I can connect 5 in horizontal, vertical, and diagonal lines and the program recognizes that I have won.
- As a user, when someone wins in the game, all the pieces of the same winning color flash different colors infinitely and the console prints “Player _ has won!” so I know when someone has won.
The newer software does not compile, therefore we cannot run it. In the older software, two players can take turns clicking on the screen bubbles to place a stone of alternating colors on that space. When connect 5 occurs, then play stops and the winning player is rewarded with their stones flashing in different colors.
- As a user, I should be able to see who’s turn it is so I don’t have to second guess who’s playing or count the number of pieces on the board.
- Though we see some initial framework on having an intro page and/or a restart game button/page, that is not in the older version and it would be smart to implement so that the game doesn’t flash and run forever and you can get back to the initial starting point.
- As a user, I see a overwhelmingly large game board. We should limit the size of the playing board because right now if you placed the markers randomly, it would take forever to win the game.
- As a feature, we could add a CPU or a timer for the users to enhance the gameplay.
README.md is in a primitive state. It does not list the state of the software, version and change history. It does not contain pictures of what the running software looks like as well as features that have been added. It does not contain a section to make it easier to maintain the software. It also doesn’t contain a description on how to run the project. There could be better organization with defined sections talking about each of these topics. We could also add an FAQ.
The build.xml file seems up to date. While the build.xml contains code to build older files, the build file as a whole works.
The biggest first issue is that the newer refactored code does not compile properly. When running the older code, the User Interface is not user friendly, and the game does not allow the players to start a new game when someone wins. The issues are enough to earn 1000 points by working on this project. The issues are generally clear enough.
- Highlight spaces that you mouse over
- Add an intro page with start games and settings
- Limit the size of the playing board
In the old, working program, all the code is put into one class. Indentations are inconsistent toward the end of the file. There are comments, and the code is not too messy. They have consistent documentation throughout every method, so it is clear how the methods relate to each other. The old code no doubt needs to be refactored so that when the program is scaled up to add new features, the program is easier to maintain.
In the new, non-working program, the layout is a lot more intuitive because each class does a specific job. Indentations are inconsistent; sometimes there are spaces, other times there are tabs. The AllIDoIsWin.java class contains JUnit tests that test all the winning cases for the users. Its implementation runs different methods per user to check if p1 or p2 has connected 5 in a row. The Controller.class’ only usage is to get coordinates on the frame. While getting coordinates is necessary, having a class with 5 methods in it seems like an unnecessary wrapper class. The Viewer.java class gives us the impression that the last people who worked on it were trying to add a starting page for the game.
The test coverage is very limited and focuses only on making sure that if someone wins via connect 5, the method that catches it does. The tests can have expanded test coverage if it also caught moments where neither player wins, moments where a player blocks another, and other exceptions. Other test coverage should include making sure that the user can not add a stone where there is already one.