Team TwentyThreeFourty evaluated our teams’ design of “Oregon Trail” and found problems in the following areas: starting a new game, the Map Editor, the startup screens, and the main screen. We feel that we should address the concerns of TwentyThreeFourty individually, and provide any alternatives to their recommendations if what they recommend does not seem feasible for our design and implementation.
TwentyThreeFourty felt that Start New Game high accessibility would cause many accidental starts. In other words, a lack of warning mechanism will result in many players accidentally starting a new game. Adding a dialog prompting the user if they are sure they want to start a new game should not be difficult. In our design, the method in the Application Model that starts a new game can simply pop up this dialog box. If the user clicks okay, then the logic for creating a new game will be executed. If the user clicks cancel, then the logic will be instantly terminated.
The Map Editor indeed does show many usability problems, and these problems, unfortunately, were a result of trying to implement the editor. To improve the map editor, we will simply get rid of the sliders and spin buttons altogether. Instead, we will provide dialogs that pop-up when the user clicks on Add Fort, Add River, etc. In these dialogs, the user can input the specific mile markers for a feature and click okay for the game to accept. We will have the dialog specify how to do things such as add a range of items using hyphens (i.e. “20-40”) and add features at separate mile markers using commas (i.e. “1, 5, 70”).
We proposed this alternative design for the Map Editor simply because of time constraints. If there is more time to improve the Map Editor, we could implement a second alternative that is completely visual. The Map Editor will simply present 2000 squares in a logical linear order. The user can simply click on a square and specify if it should be a river, a mountain range, a fort, etc. This version would require more help documentation than the previous, but it solves the problem of the highly unreadable, text version of representing the map. Adding help documentation should not be a problem as we can simply implement a window with all the require information and a Help button in the Map Editor window. This alternative design also eases up correcting mistakes made during the editing process.
For the setup screens, the stricter grouping of text fields and radio buttons should be fairly easy to implement thanks to VisualWork’s GUI editor. We will simply arrange the fields better and add borders to emphasize the grouping. As for the confusion of the cancel button, we will remedy the situation by having the start-up screens have the default values needed already written in the text fields and the default radio button selected. Then, we will make cancel simply a cancel button that places the player back to the previous screen. These additions simply mean the deletion of the current code for cancel, and coding in the default values. Thankfully, making default values for text fields is not difficult. Therefore, these issues should be remedied fairly quickly and painlessly.
Finally, we will create a separate title screen instead of having the game start in the main screen. The title screen will have buttons for creating a new game and creating a new map, fixing the usability issues of the new game button not being very obvious as well as new users being confused by the start-up screen that asks for a map. This remedy, however, we feel to be somewhat drastic as we have to change the flow of our windows. Fortunately, it is easy to have the game start at the title screen instead of the main screen. Therefore, we just need to implement the sequence of screens one-by-one. In other words, the design will be very different and may require major changes to the implementation, but there is an easy starting place to make these changes.
We thank TwentyThreeFourty for bringing up these issues with our design and implementation of “Oregon Trail.” Fortunately, our design provides a way to fix these issues without needed a major overhaul in our code. At worst, we will only need very local overhauls of code, such as the new implementation of the title screen as well as the map editor. However, these changes should improve the product and expand the user base for future products.