import java.awt.image.BufferedImage;
import java.io.File;
import java.io.IOException;
import javax.imageio.ImageIO;
public class Player {
private int x;
private int y;
public Player(int x, int y) {
super();
this.x = x;
this.y = y;
}
public int getX() {
return x;
}
public void setX(int x) {
this.x = x;
}
public int getY() {
return y;
}
public void setY(int y) {
this.y = y;
}
public void performAction() {
}
public void setKey(char c, boolean b) {
}
public void die() {
try {
ImageIO.read(new File("C:/Users/G/Desktop/player-dead.png"));
} catch (IOException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
public BufferedImage getCurrentImage() {
return null;
}
}
Operations
A. Goals
In BuzzWord, the goal is start easy, and get gradually more difficult as the player gets into higher levels. Section 3.1.2 provides an example of the layout of the level selection screen.
B. Game Mode Selection
This game offers multiple modes (e.g., normal dictionary words, famous people, etc.). Game mode selection can be done from the home screen.
C. Game Play Logic
The game play consists of a target score that the player must reach at each level, and a time limit within which the player must do so. The exact time limit and target scores are decisions left to the game developers. While playing, the words guessed by the player are shown in a display, along with their scores. The total score is also displayed so that the player knows how far away s/he is from salvation!
The details of the user interface are provided in Section 3.1.3. A few additional things to note:
1) During gameplay, the player should have some option to restart the game (with a newly generated grid) without waiting for time to run out. The external interface decisions (e.g., an additional restart button) about this are left to the game developers.
2) When a game ends (at some level): a) All words that could have been guessed by the player, but weren’t, must be added to the display in a visually distinct manner (similar to how unguessed letters in the target word were displayed in Hangman in the second homework). b) The total possible score at that level should also be displayed. The idea is that the player should. c) The play button should get enabled again. This is how the player replay the same level after s/he fails to clear the level. d) An additional button must appear, clicking which should allow the player to move back to the level selection screen directly without going to the home screen.
Hardware Interfaces
The application should be runnable on any platform with Java, but required a keyboard and mouse.
Software Interfaces
BuzzWord will be developed as a JavaFX application. In addition to the application itself, we want to develop a simple framework that allows for easier development of similar word games using JavaFX. This interface must provide general methods of
1) Playing games inside an environment with a countdown timer.
2) Creating grids of different types of objects.
3) Creating dynamically updatable scoring mechanisms.
4) Any other functionality that you may think is general enough (i.e., applicable to other word games, not just BuzzWord).
For this interface, you can use the JFXFramework as a starting point, but you can also start based off JavaFX directly.
Communications Interfaces
BuzzWord is a local game, with no network requirements.
Product Functions
N/A
User Characteristics
The game should be as intuitive and user-friendly as possible. Use good UI design principles and fool proof designing to achieve this aim.
Constraints
N/A
Assumptions amp; Dependencies
N/A
Apportioning of Dependencies
N/A
Specific Requirements
The GUI controls should be neatly drawn, and carefully aligned and spaced.
External Interfaces
The GUI renderings provided in this section are approximate suggestions. The precise size, position and layout may be modified and refined by the developers during the implementation process.
Home Screen
Fig. 3.1: The home screen immediately after the application has started running. At this point, the user has not logged in, and therefore, s/he cannot start playing a game immediately.
Fig. 3.2: The home screen after player has logged in using the credentials for an existing player profile. Here, the “Create New Profile” button is no longer present, and two new buttons have appeared
Fig. 3.3: The game offers multiple modes of play such as English dictionary words, or specialized domains like scientific terms, names of places or famous people. Before starting to play, the player may not actively choose a game mode. Then, the mode in which the player was playing before exiting the application during the previous login will be implicitly selected. If the player is new, the English dictionary mode will be implicitly selected.
As you can see, in all three scenarios, the home screen always provides the user with the simple option of quitting the application by clicking on the cross on the top-right corner. In addition to clicking buttons that make the player move away from the home screen, there is one special scenario where the home screen is visible, but inactive. This is when the user clicks on the login button.
Fig. 3.4: User has clicked the login button, and the login screen pops up, disabling the home screen that is visible behind. At this stage, a simple key shortcut like Esc should remove the login screen (in case user does not want to log in after clicking the button) and return to the initial active home screen. Upon successful login, the home screen should be as shown in Fig. 3.2. An unsuccessful attempt should provide a useful message to the user and ask the user to enter the credentials again.
Note that in Fig. 3.4., even the cross on the top-right of the background screen should not be active.
The only options for the user are to either enter the credentials successfully, or press Esc to remove the login screen popup.
Level Selection Screen
Fig. 3.5: The level selection screen for player who has not yet cleared level 4 in the
“Famous People” game mode. This screen must display the locked and unlocked levels with some visual distinction. Only the unlocked levels must be clickable. It will usually be the case that a player has cleared different levels in different game modes. The level selection screen should use saved profile data to correctly display this screen.
Note that player can logout, go back to the home screen, or quit the application from this screen.
Once the player clicks the button to start play, s/he is taken to the level selection screen. This screen displays all the levels in the game (for the game mode chosen, even if the choice was implicit). Here, the developer must take care to ensure that the player does not have access to higher levels without having cleared the lower levels first. For example, if X has only cleared levels 1, 2 and 3, then only the levels 1, 2, 3, and 4 are accessible. Levels 5 and above should be locked or disabled in some other manner. The display choices are left to the designer. Fig. 3.5 shows how this may be done.
In Fig. 3.5, when a player clicks an unlocked level, s/he is immediately taken to the gameplay screen.
This is where the action happens! Keep in mind that the player may choose to practice on easier levels s/he has successfully completed before, which is why levels 1, 2 and 3 are also accessible in the level selection screen.
Gameplay Screen
Fig. 3.6: The gameplay screen shown here during active play. The player has guessed a few words already, as shown on the right, along with the scores. The total score is also displayed. Currently, with the countdown timer showing 40 seconds left, the player needs 35 more points to clear this fourth level. S/he is attempting to guess a word starting with “BU”. This is dynamically reflected in the letter grid as the player types.
Note that ALL paths are reflected in the grid. Finally, the play button at the bottom is disabled during gameplay. It was initially enabled. The player clicked the button and the countdown timer started.
Every level requires the player to identify valid words in the letter grid. That is, words that can be formed by connecting the letter nodes in an acyclic path. The minimum word length is 3 letters, and there is no maximum limit. The game has a scoring mechanism as described under “Operations”.
Functions
A. Validity Check: The application shall check for validity of profile credentials before allowing a user to start game play of any sort.
B. Sequence of Gameplay: The application shall not allow users to access unlocked levels in any format of the game.
C. Abnormal Situations: The application shall interpret a sudden attempt to quit while in active game as a mistake, and ask for confirmation from the user. Any other similar potentially errant behavior shall also be treated in a similar manner.
D. Feedback: The application shall provide appropriate feedback to the user. The exact nature of the feedback shall depend on the context, but typically this will be in the form of visual cues or sound, provided with the intention of making the application more enjoyable for the end user.
N/A
Logical Database Requirements
N/A
Design Constraints
A primary constraint in this application is fast rendering and dynamic update of several elements in the GUI. The program should run at high frame rates because higher frame rates mean that the player will feel the changes are instantaneous, thus improving gameplay experience.
Software System Attributes
At Professaur Inc., we are dedicated to the production of robust software meeting, and then exceeding, the client’s expectations. To achieve this goal, our applications are built with the following characteristics in mind:
Reliability
The program should be carefully planned, constructed and tested such that it behaves flawlessly for the end user. Bugs, including rendering problems, are unacceptable. In order to minimize these problems, all software will be carefully designed using UML diagrams and a Design to Test approach should be used for the Implementation Stage.
Availability
The games should be freely downloadable. Education already costs a lot. Having fun while trying to get a better education - that should remain free.
Security
Since this game requires user profiles, which may have sensitive personal information like email address, the design decisions should take extra care to ensure such information remains protected.
Extensibility
It is crucial that more levels, modes and play formats (e.g. multiplayer competitive formats) can be added to such applications. Data format decisions should carefully consider this aspect.
Portability
The game will target desktop Java applications.
Maintainability
N/A
Organizing the Specific Requirements
The application we are developing is simple enough to avoid using any special arrangement for organizing specific requirements, which already fit into the sections covered in this document, as per the IEEE-recommended SRS format.
UI designers and software engineers should work to keep the visual esthetics of the application above and beyond what clients generally expect. In short, strive to make your applications look and feel great!
Details of designing the interface controls, their layout, etc. are left to them.